Services de sauvegarde
Une perte de données est ce que le personnel informatique redoute le plus. Pour éviter cela, la stratégie la plus efficace consiste à sauvegarder les volumes de stockage, les machines virtuelles, les bases de données et les autres systèmes qui stockent des données. Cela permettra ainsi de restaurer ces données. Les fournisseurs de services cloud proposent des services de sauvegarde à cet effet. En règle générale, ces services permettent de sauvegarder les données stockées localement et celles stockées dans le cloud. Ils permettent aussi de répliquer et disperser géographiquement les sauvegardes pour se protéger contre des événements susceptibles de provoquer une perte de données à l’échelle d’un centre de données ou d’une région du monde.
Le cloud public est un pourvoyeur de ressources fluides dans des volumes importants. Il ne s’agit pas simplement de gros conteneurs de stockage, mais de pools de stockage hautement scalables. Il est au moins aussi polyvalent, voire davantage dans certains cas, que les systèmes de stockage de sauvegardes et les lecteurs de bande qu’ils remplacent. Il permet aussi aux organisations de bénéficier des redondances, des basculements et des filets de sécurité que beaucoup n’auraient pas pu s’offrir à l’époque où toutes les ressources étaient acquises avec le fonds de roulement. Les options de stockage de cloud public remplissent une fonction dont les centres de données ont toujours eu désespérément besoin, mais qu’il était difficile d’obtenir jusqu’à récemment.
Services de sauvegarde basés sur le cloud
Ce qui caractérise les services de sauvegarde modernes proposés par les fournisseurs de services de cloud public (CSP) est la façon dont ils étendent l’infrastructure de leurs clients. Avant l’arrivée de ces services, la stratégie de sauvegarde classique d’une organisation comportait deux niveaux : la sauvegarde des volumes de données hébergeant les bases de données et la sauvegarde des images de machines virtuelles hébergeant des charges de travail critiques. La théorie appliquée à la sauvegarde était la suivante : lorsqu’une erreur système provoquait une panne, cet événement rendait le serveur indisponible. L’action à entreprendre immédiatement était alors de restaurer l’état du serveur à partir d’une image de sauvegarde.
L’infrastructure basée sur le cloud rend obsolète cette ancienne théorie de sauvegarde. Dans les systèmes modernes, les serveurs sont constitués de logiciels et non de composants matériels. Les serveurs virtuels sont hébergés par une infrastructure virtuelle basée sur l’hyperviseur, telle que VMware NSX, ou ils sont assemblés à partir de conteneurs et hébergés par des systèmes d’exploitation virtualisés. Dans les deux cas, les images logicielles des charges de travail pour les applications et les services sont continuellement gérées, mises à jour et sécurisées. En effet, les composants logiciels actifs sont eux-mêmes des réplicas de ces serveurs maîtres sécurisés. En ce qui concerne la conteneurisation, les produits des serveurs maîtres d’origine sont stockés dans des référentiels de conteneurs et sont assemblés automatiquement en fonction des besoins. Lorsqu’une panne matérielle rend indisponible un nœud de serveur, les serveurs qui sont hébergés par ce nœud ne sont indisponibles que pour un certain temps. L’infrastructure redirige simplement le trafic autour de ce nœud et fait de son mieux pour le remplacer pendant ce temps. Le gestionnaire d’infrastructure ne fait rien de plus que ce qu’il fait déjà dans le cadre d’une administration de système ordinaire.
Toutefois, comme pourrait le montrer une étude rapide des centres de données modernes, toutes les infrastructures modernes ne sont pas basées sur le cloud. Il existe encore des services qui sont hébergés sur des systèmes nus dans des centres de données locaux. Les réseaux client/serveur qui sont complétés par un middleware (intergiciel) sont encore nombreux. De plus, sur un système hybride où une partie conçue il y a quelques années est connectée à une autre partie conçue au siècle dernier, il est encore nécessaire de stocker suffisamment d’informations sur la composition du système afin de pouvoir le reconstruire en cas de sinistre, à l’aide d’une méthode pratique mais rapide, dans un nouvel emplacement et avec un impact minimal sur les niveaux de service. Avec les stratégies de sauvegarde modernes, le cloud public peut être choisi comme cet emplacement, même si les systèmes en cours de capture se trouvent en dehors du cloud.
Sauvegarde AWS
Au début de l’année 2019, Amazon Web Services a repensé son service de sauvegarde basé sur le cloud pour les environnements cloud hybrides des clients. Au cœur de la nouvelle sauvegarde AWS (dont la console basée sur le navigateur est montrée à la figure 2) se trouve un moteur de stratégie, similaire à l’arbitre des règles d’un pare-feu. Avec ce moteur, l’administrateur de sauvegarde écrit des règles qui spécifient ce qui suit :
Les ressources d’un système qui nécessitent une sauvegarde
La façon dont chaque sauvegarde doit être effectuée et à quelle fréquence
L’emplacement de stockage des images de sauvegarde
La façon dont l’intégrité des images de sauvegarde doit être supervisée (y compris la fréquence)
La durée de conservation des images de sauvegarde
Dans quelles circonstances la récupération et la restauration doivent avoir lieu
L’itinéraire complet qui englobe toutes les stratégies actives est appelé plan de sauvegarde. Ici, chaque règle fait référence aux ressources du cloud AWS qui nécessitent une sauvegarde d’après la valeur de leur étiquette, qui correspond à un nom arbitraire donné par l’administrateur. Pour inclure une ressource en tant que volume de stockage EBS dans un plan de sauvegarde, son administrateur doit uniquement attribuer à cette ressource un nom d’étiquette que la sauvegarde AWS reconnaîtra. De cette façon, l’administrateur ou le gestionnaire d’une ressource AWS n’a pas à utiliser la console de sauvegarde AWS uniquement pour établir une ressource sous la responsabilité du gestionnaire, dans le cadre d’un plan de sauvegarde existant.
![Figure 2 : console sauvegarde AWS. [Courtesy Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Figure 2 : Console de sauvegarde AWS [Fourni par Amazon]
Les ressources locales peuvent être incorporées dans un plan de sauvegarde à l’aide d’AWS Storage Gateway. Dans le cadre de la sauvegarde AWS, la passerelle de stockage agit comme un wrapper d’API autour des volumes de stockage physiques et des appareils, en les rendant accessibles aux services AWS.
À l’origine, Storage Gateway permettait la substitution de ressources de stockage physique existantes par leurs équivalents cloud à l’aide de la même interface. Par exemple, un volume iSCSI local pouvait être wrappé dans ce qu’AWS appelle un volume mis en cache. Ce wrapper rend le stockage cloud accessible aux applications locales existantes, sans que les clients aient à remanier ces applications. Les données fréquemment sollicitées pouvaient toujours être stockées sur le volume iSCSI comme dans un cache, permettant ainsi de réduire la durée de latence engendrée. Les modifications apportées récemment au contenu du volume de la passerelle peuvent aussi être stockées localement en tant que captures instantanées. Toutefois, Storage Gateway prend également en charge les volumes stockés, dans lesquels l’appareil local continue de conserver une copie locale complète du volume, que Storage Gateway se charge alors de faire apparaître dans le cloud. La nouvelle sauvegarde AWS tire parti de la permutation des rôles avec les volumes physiques de Storage Gateway. De cette façon, la copie locale devient la sauvegarde du volume basé sur le cloud, et une console de gestion des stratégies centralisée est ajoutée, avec des règles qui régissent la façon dont les deux réplicas doivent être conservés.
Concernant la reprise d’activité après sinistre, l’un des principaux avantages qu’offrent les fournisseurs de solutions cloud est la possibilité d’archiver rapidement les données critiques d’une organisation dans des emplacements distants afin d’obtenir une redondance géographique ou géoredondance. AWS exploite les centres de données cloud dans le plus grand nombre de zones de disponibilité possible pour tous les fournisseurs de solutions cloud. Il indique la capacité native des applications qu’il héberge à basculer automatiquement vers d’autres zones, et il étend cette fonctionnalité à la redondance des sauvegardes des données. Toutefois, les zones de basculement résident généralement dans une même région AWS. En cas de grave sinistre (que les compagnies d’assurance, et donc les gestionnaires de risques, prennent en compte), tel qu’une panne de réseau électrique, les zones de disponibilité qui sont adjacentes peuvent tout à fait subir de telles pannes.
Un développeur de logiciels, ou un opérateur informatique disposant d’une expérience en développement, peut écrire des stratégies personnalisées pour le routage de géoredondance propres à une organisation à l’aide du service de routage de bas niveau Route 53 d’AWS. Toutefois, cette technique nécessite beaucoup d’efforts. AWS a récemment proposé un service d’approche mieux exploitable appelé AWS Global Accelerator. Il s’agit d’un autre moteur de stratégie qui guide le trafic et dirige Itinéraire 53 en fonction de l’emplacement où les services et le stockage doivent être hébergés.1 Global Accelerator peut également être utilisé comme une sorte de « über-balancer » permettant la distribution de plusieurs sites pour les applications hébergées (et avec eux, des données critiques) dans des zones de disponibilités réparties.
Une autre façon de s’assurer que les données sauvegardées seront stockées dans une région distante (comme l’ont suggéré les techniciens Amazon) consiste à créer un bucket (un conteneur de sauvegarde à usage général AWS) comme destination de la sauvegarde initiale, puis à répliquer ce bucket dans un emplacement redondant situé dans la zone de disponibilité désignée. AWS propose une fonctionnalité de réplication inter-région sous la forme d’un service distinct.2 AWS fixe les tarifs de son service de sauvegarde en termes de volume, c’est-à-dire à la fois les gigaoctets stockés et les gigaoctets restaurés.
D’un point de vue architectural, la sauvegarde AWS est conçue pour servir de miroir aux ressources AWS. Pour intégrer des ressources locales au plan, vous devez d’abord utiliser un « double back-door » en convertissant les ressources locales en volumes AWS distants (distants du point de vue d’Amazon), puis en demandant à la sauvegarde d’interagir avec le wrapper de ces ressources locales.
Sauvegarde Azure
La Sauvegarde Azure peut également sauvegarder des ressources locales (serveurs et machines virtuelles), ainsi que des ressources hébergées dans Azure. Elle n’a pas pour but de modifier la stratégie de sauvegarde existante du centre de données, mais seulement de remplacer les disques locaux et les lecteurs de bande par le stockage cloud. L’emplacement cloud des fichiers et des volumes sauvegardés dans Azure est appelé coffre Recovery Services, dont la console basée sur le navigateur est illustrée à la figure 3. Pendant le processus d’installation de ce coffre via le portail Azure, l’administrateur télécharge et installe l’agent côté client appelé agent « Microsoft Azure Recovery Services » ou « MARS ». Dans Windows Server, MARS s’exécute comme une application, de façon très similaire à un module complémentaire System Center. (sinon, un administrateur peut préférer utiliser System Center Data Protection Manager, auquel la fonctionnalité MARS est déjà intégrée). L’administrateur localise les volumes et les services du réseau dont les données nécessitent une sauvegarde, puis MARS distribue ses agents aux adresses de serveur responsables de ces composants.
![Figure 3 : la console du coffre Azure Recovery Services. [Fourni par Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Figure 3 : Console du coffre Azure Recovery Services [Fourni par Microsoft]
Le modèle de distribution de la Sauvegarde Azure est basé sur des objectifs de niveau de service concernant la reprise d’activité. Ceux-ci fournissent des métriques permettant de déterminer la durée pendant laquelle une organisation peut résister à l’absence d’accès au moteur de son entreprise, ainsi que la quantité de données qu’elle peut perdre en cas d’incident. Ces objectifs (RPO, RTO et conservation) sont abordés dans la prochaine leçon relative à la reprise d’activité.
Le type de reprise d’activité qui concerne la sauvegarde Azure (par opposition à Azure Site Recovery, le service de reprise d’activité de Microsoft) est entièrement centré sur la réplication des données plutôt que sur la restauration du service. Par exemple, un client peut utiliser la Sauvegarde Azure pour produire des réplicas de fichiers d’images de machines virtuelles (VHD). Toutefois, la restauration d’un disque dur virtuel ne fait que reproduire le fichier image archivé dans le stockage local une fois de plus, et ne redémarre pas le serveur virtuel en fonction de ce disque dur virtuel.
La Sauvegarde Azure est facturée uniquement selon la quantité d’espace de stockage consommée par mois, sans frais supplémentaires pour les restaurations. Son modèle tarifaire de stockage dépend des options de redondance. À l’heure actuelle, Azure propose deux options de ce type : le stockage localement redondant (LRS), qui est le moins onéreux et qui réplique les données trois fois au sein d’un centre de données Azure, et le stockage géoredondant (GRS), qui réplique les données dans une région secondaire géographiquement distante de la région primaire.
Sauvegarde dans Google Cloud Storage
Google propose un grand nombre de niveaux de stockage Cloud Storage en fonction de la classe des données stockées (par exemple, pour les fichiers disponibles de manière permanente, pour le stockage de bloc des images de machines virtuelles ou pour le stockage d’objets des vidéos). Il ne commercialise pas explicitement un service de sauvegarde sous sa marque pour l’un de ces niveaux, mais vous pouvez très bien utiliser des services de stockage pour la sauvegarde et la récupération. Google suppose que les entreprises investissent dans le stockage cloud à des volumes élevés principalement pour leurs besoins en sauvegarde.
![Figure 4 : le contenu d’un compartiment de Stockage cloud Google. [Courtesy Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Figure 4 : Contenu d’un bucket Google Cloud Storage [Fourni par Google]
Comme AWS, Google désigne son conteneur de stockage à usage général sous le nom de bucket. La figure 4 montre une étape du processus d’importation des données à partir du stockage local dans un bucket Google Cloud Storage. Tout comme dans Azure, qui base son modèle de distribution sur trois paramètres clés, les paramètres de Google Cloud Storage sont les suivants :
Performances qui, dans ce contexte, est synonyme de disponibilité (c’est-à-dire à quelle vitesse les serveurs répondent à la requête de lecture des données des clients)
Conservation, qui fait référence une nouvelle fois à la durée de conservation des données stockées dans le cloud
Modèles d’accès, qui fait référence à l’accessibilité (la fréquence à laquelle le client s’attend à lire ou à rappeler les données stockées).
Lors de l’initialisation d’un bucket, le client Google Cloud Storage choisit sa classe de stockage, qui spécifie sa stratégie de réplication. Une fois que le bucket commence à être utilisé pour les sauvegardes, ce choix détermine le niveau de dispersion des données stockées. Google Cloud Storage propose trois options de géolocalisation :
Régionale : les données sont stockées dans une seule région du secteur de service de Google
Birégionale : les données sont répliquées dans deux secteurs de service
Multirégionale : les données sont distribuées de manière redondante sur plusieurs secteurs de service
Ensuite, Google Cloud Storage subdivise les classes de stockage de ses buckets en fonction de la fréquence à laquelle les utilisateurs y accéderont :
Standard/Haute disponibilité : données destinées à être facilement accessibles aux applications et aux utilisateurs
Coldline : permet au client d’échanger une partie des frais de stockage mensuels contre des frais d’accès et de transfert. Convient aux données qui ne seront consultées que quelques fois par an.
Nearline : option intermédiaire pour les données dont l’accès est prévu une fois par mois
Concernant la commercialisation de son infrastructure cloud l’approche de Google est de présenter ses services auprès des entreprises comme un type d’appliance qui ne se voit pas. Pour cette raison, le fait de présenter comme deux services distincts l’appliance même et la manière dont celle-ci s’utilise peut faire double emploi pour Google (ce serait comme vendre un four, puis vendre un abonnement à la cuisson comme valeur ajoutée).
De cette façon, l’organisation cliente de Google Cloud Storage sélectionne l’infrastructure dont elle a besoin pour les tâches qu’elle compte effectuer, et personnalise les paramètres de cette infrastructure, tels que les fonctionnalités de l’appliance (comme AWS et Azure, Google propose une appliance montable en rack pour les centres de données dans le but d’assurer un transfert rapide entre le stockage local et le stockage cloud). Ces fonctionnalités peuvent ensuite être modifiées en fonction de l’usage qui est fait de ce stockage. Supposons, par exemple, qu’une entreprise de production vidéo ait besoin d’une grande quantité de stockage de sauvegarde pour les versions d’un film en cours de montage. Pendant le montage, l’entreprise peut avoir besoin de récupérer les copies relativement souvent. Elle peut donc définir le bucket sur le stockage Standard dans le secteur Régional. Une fois que la vidéo est terminée et distribuée publiquement, il peut être encore nécessaire de conserver des copies à portée de la main l’année suivante, bien qu’elles ne fassent pas souvent l’objet d’un accès. Dans ce cas, le compartiment Standard peut être transféré vers un compartiment Coldline, avec un territoire birégional à des fins d’archivage et de sécurité.
Références
Amazon Web Services, Inc. Traffic management with AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. Présentation de la configuration de la réplicationhttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.