Services de reprise d’activité après sinistre
La récupération des données sauvegardées est, pour des raisons évidentes, une fonctionnalité standard des services de sauvegarde. Toutefois, un sinistre ne se limite pas à des pertes de données. Une panne qui entraîne l’indisponibilité des serveurs d’une organisation, qu’ils soient réels ou virtuels, sur site ou dans le cloud, a un impact négatif et parfois même catastrophique sur l’organisation. L’objectif d’un service de reprise d’activité après sinistre consiste à fournir une sauvegarde non seulement des données et des ressources individuelles, mais aussi des systèmes entiers, de sorte que si ces systèmes cessent de fonctionner ou sont mis hors connexion, le service puisse être repris en redirigeant le trafic vers des réplicas de secours, prêts à accepter la charge.
La reprise d’activité après sinistre est le domaine où le cloud public prend toute sa valeur. Il s’agit de bien plus qu’un énorme lecteur de bande. Comme les ressources cloud sont virtuelles, des réplicas peuvent être lancés au pied levé pour remplacer des ressources qui disparaissent soudainement. Les réplicas peuvent même être hébergés dans d’autres parties du monde que les systèmes qu’ils reflètent, afin de contourner des pannes touchant une zone entière. En comparant cela aux coûts de la gestion des réplicas physiques des systèmes informatiques physiques (et en essayant de le faire dans des emplacements géographiquement différents), la valeur du cloud apparaît pour assurer la continuité de ces systèmes.
Les principaux fournisseurs de cloud proposent une reprise d’activité en tant que service (DRaaS), mais ces services doivent être planifiés et configurés délibérément pour fournir la prise en charge du basculement souhaitée par les clients. Par conséquent, commençons par examiner les objectifs et les métriques à prendre en compte dans cette planification.
Objectifs et métriques
En cas de sinistre, une organisation et ses clients peuvent perdre l’accès à plusieurs classes de ressources numériques simultanément, dont les plus importantes sont :
Les bases de données et les magasins de données, qui en plus d’enregistrer des informations essentielles sur les clients, les produits et/ou les services en stock, maintiennent l’état actif des transactions et des processus métier pour l’organisation tout entière
Les données en bloc, notamment les documents, les fichiers multimédias et d’autres enregistrements sauvegardés, qui sont les produits des applications que les gens utilisent
Les communications et la connectivité avec les personnes et les services professionnels, comprenant ainsi la substance de toutes les activités professionnelles pouvant être menées
Les applications qui représentent la vitrine de l’organisation pour les clients et les usagers, ainsi que ses propres parties prenantes
La reprise d’activité après sinistre est présentée aux clients sous la forme d’un service unique, mais le processus de récupération de chacune de ces classes est distinct des autres. Dans l’ère client/serveur, de nombreuses organisations menaient leurs activités quotidiennes sur des ordinateurs personnels. Si un PC tombait en panne et qu’une image de sauvegarde existait dans le stockage local du PC, théoriquement, elle pouvait être restaurée sur un nouveau PC et le travail pouvait se poursuivre. Avec les premiers PC en réseau connectés par des systèmes d’exploitation LAN et un câble Ethernet, il était possible de restaurer chaque PC du réseau à partir d’une image sauvegardée et le réseau lui-même pouvait recommencer à fonctionner.
Le cloud ne fonctionne pas de cette façon. Même une machine virtuelle qui agit en tant que serveur pour les applications d’une organisation n’encapsule aucune partie du travail qu’il effectue dans son intégralité. Les services de sauvegarde constituent un réseau de sécurité pour les données en bloc et, dans une certaine mesure, les bases de données et les données transactionnelles. Toutefois, chacune de ces entités est un composant indépendant, de sorte que la restauration des fonctions d’entreprise pendant un sinistre nécessite le rétablissement de la plupart des fonctionnalités de chacun de ces composants à partir d’un emplacement sécurisé.
Par conséquent, le processus de reprise d’activité après sinistre nécessite la coordination de toutes les procédures mises en œuvre pour rétablir le fonctionnement intégral d’une organisation. De plus, la nature de l’activité qui est effectuée au cours de cette période prend encore plus d’importance du fait de l’existence même du sinistre. Un événement capable d’interrompre le fonctionnement d’une infrastructure essentielle a probablement endommagé d’autres fonctions de l’entreprise : l’entreposage, l’expédition, la fabrication ou la livraison. De façon similaire, l’activité en cours de restauration ne peut pas être une reprise transparente de l’activité qui était menée avant le sinistre.
Ce qui regroupe collectivement ces procédures, c’est la présence d’objectifs de niveau de service communs et clairement définis. Les services de reprise d’activité AWS et Azure, ainsi que les services tiers basés sur Google Cloud, reconnaissent les éléments suivants :
Objectif de point de récupération (RPO) – Quantité de données minimale autorisée qui doit être restituée aux clients pour le service en fonction des ressources sauvegardées pour être considérée comme récupérée. À l’inverse, cette quantité peut être considérée comme la perte de données maximale acceptable, exprimée sous la forme d’un pourcentage soustrait de 100.
Objectif de délai de récupération (RTO) – Durée maximale autorisée pour qu’un processus de restauration soit mis en place, laquelle peut également être considérée comme une mesure du temps d’arrêt que l’organisation peut se permettre de subir.
Période de conservation – Durée maximale autorisée de conservation d’un jeu de sauvegarde avant qu’il doive être actualisé et remplacé.
Les objectifs RPO et RTO peuvent être perçus comme équilibrés entre eux, de sorte qu’un client pourra décider d’autoriser des temps de récupération plus longs pour atteindre des points de récupération plus élevés. Si le délai de récupération est un problème pour un client en raison de la bande passante disponible ou du risque de temps d’arrêt, ce client peut ne pas être en mesure d’atteindre un RPO élevé.
Un conseiller en matière de risques professionnels ou un conseiller en matière de continuité des activités est susceptible d’insister sur l’utilisation de ces trois variables lors de la formulation d’une stratégie de reprise d’activité après sinistre. Les objectifs RTO et RPO figurent au premier plan dans la plupart des rapports d’analyse de l’impact professionnel (BIA). Il s’agit de variables essentielles pour l’évaluation par les conseillers des pertes potentielles résultant d’un sinistre. Certains conseillers utilisent une variable d’agrégation appelée objectif de niveau de service (SLO), bien qu’une formule unique pour la réalisation de l’objectif SLO n’ait toujours pas été élaborée. Les fournisseurs de cloud peuvent spécifier leurs niveaux de service à l’aide d’une terminologie que les conseillers en matière de risques reconnaissent et apprécient. Cela aide les deux parties à collaborer, ce qui est souvent la façon dont les organisations finissent par choisir les fournisseurs de solutions de reprise d’activité après sinistre.
Méthodologies et procédures
La leçon précédente a abordé la forme la plus élémentaire de récupération d’un système informatique, impliquant des sauvegardes des fichiers pertinents, des volumes de stockage et des images de machines virtuelles. Bien que cette option continue à être présentée comme une option de service de reprise d’activité après sinistre, dans la pratique, elle s’applique à un nombre réduit d’organisations, essentiellement parce que les objectifs RTO ne peuvent pas être gérés de manière adéquate.
Les services professionnels de reprise d’activité proposent différentes méthodologies de déploiement et de gestion, dont certaines impliquent la maintenance des services avant un sinistre. Ces méthodologies sont résumées ci-dessous. Ces trois méthodologies sont basées sur les disparités entre les options de sauvegarde abordées dans la leçon précédente, et elles s’appliquent de façon égale à tous les fournisseurs de services. Un client qui souhaite activer un de ces modes de récupération choisira les classes de réplication, de géolocalisation et de stockage les plus adaptées à ce mode.
Veilleuse
Avec cette méthodologie (figure 5), il existe un espace pour un centre de données de secours complet. Ici, certains services et applications de base, ainsi que les données qui les prennent en charge, sont conservés dans un cluster de basculement qui peut être « activé » au moment où un sinistre survient, souvent automatiquement. Entre-temps, les serveurs virtuels sont déployés avec seulement les fonctionnalités de base requises pour les maintenir actifs s’ils ne doivent jamais être appelés. Ces serveurs mis de côté peuvent être dotés de fonctionnalités de messagerie et web permettant des communications avec les clients ainsi qu’au sein de l’organisation. L’activation d’un mode de récupération de type veilleuse peut nécessiter une synchronisation continue des magasins de données volatiles, tels que les bases de données transactionnelles et les volumes d’e-mails.
Figure 5 : Composants actifs et passifs d’un scénario de récupération de type veilleuse.
Secours semi-automatique
Dans ce mode de récupération, illustré à la figure 6, des réplicas exécutés en continu de tous les services et applications système et de toutes les données d’entreprise critiques sont conservés dans au moins une géolocalisation distincte. L’accès à ce réplica complet est court-circuité par le routeur actif jusqu’à ce que la survenue d’un sinistre déclenche une règle qui remplace l’adresse du réseau actif par celle de la route de contournement.
Figure 6 : Scénario de récupération de secours semi-automatique avec certains composants de l’espace de noms de secours pleinement opérationnels.
Serveur de secours
Dans ce scénario (figure 7), au moins deux réplicas complets de tous les services et applications s’exécutent à tout moment, avec une synchronisation complète et continue des données entre eux. Un routeur maître sert d’équilibreur de charge général et distribue les demandes entre tous les emplacements de serveur, dans des proportions à peu près égales. La survenue d’un sinistre déclenche un processus de type pare-feu dans le cadre duquel l’adresse du système affecté est supprimée de la table de routage.
Figure 7 : Avec le serveur de secours, tous les composants de l’espace de noms de ce qui aurait normalement été l’espace de secours de réserve sont actifs, pleinement opérationnels et traitent les réplicas des données principales en temps réel.
Applications natives cloud
Une organisation peut théoriquement choisir un service de reprise d’activité après sinistre d’un fournisseur comme réseau de sécurité pour des services hébergés par un autre fournisseur. En d’autres termes, à condition que le personnel informatique y porte suffisamment d’attention, l’infrastructure d’un fournisseur de cloud (par exemple, Google) peut servir de destination de basculement pour une procédure de secours semi-automatique hébergée dans l’infrastructure d’un autre fournisseur de cloud (comme Azure). Ce type de configuration peut être nécessaire pour des raisons de comptabilité ou si des ressources de calcul au sein d’une entreprise sont gérées par des départements distincts dans différentes parties du monde.
Pour le moment, la présence d’une infrastructure conteneurisée dans le centre de données local, ainsi que dans le cloud, peut avoir un impact significatif sur toutes ces méthodologies de reprise d’activité après sinistre. Une application native cloud, développée exclusivement pour être utilisée sur une plateforme de cloud public, ou sur une plateforme qui fonctionne comme elle (par exemple, Microsoft Azure Stack), distribue les fonctions vers plusieurs conteneurs de réplicas, dont certains ou la totalité peuvent fonctionner simultanément. La raison n’est pas tant d’activer une nouvelle classe de scénario de reprise d’activité après sinistre que de distribuer les charges de travail entre les processeurs.
Un autre aspect des architectures natives cloud est la capacité qu’ont les bases de données dont le contenu est déjà répliqué automatiquement d’être contactées par le biais d’une adresse réseau dont le mappage est exclusif à l’application concernée. (En d’autres termes, bien qu’elle utilise le protocole Internet, son adresse n’est pas un emplacement sur l’Internet grand public.) De cette façon, au cours d’un sinistre, si certains nœuds attachés à la base de données cessent de fonctionner, un grand nombre de nœuds continueront de fonctionner et d’autres remplaceront les nœuds indisponibles. Il ne s’agit peut-être pas encore d’une reprise d’activité intégrée, mais cela s’apparente sans aucun doute à une résistance aux sinistres.
Reprise d’activité en tant que service (DRaaS)
Pour un fournisseur de cloud public, la reprise d’activité après sinistre est un moyen d’exploiter ses services de sauvegarde et de transfert de données de base. Chacun des principaux fournisseurs de cloud met en œuvre une stratégie différente pour faciliter la reprise d’activité après sinistre en plus de ses services de sauvegarde.
AWS CloudEndure
La migration de service fait référence au déplacement des charges de travail virtuelles à partir d’une infrastructure locale privée vers une infrastructure de cloud public. Ce déplacement est nécessaire pour permettre à certains services de reprise d’activité qui fonctionnent dans le cloud public d’atteindre leurs objectifs de basculement et de récupération en quelques minutes après un sinistre.
En janvier 2019, Amazon a acquis le service de migration de service privé CloudEndure, qui utilisait déjà AWS comme fournisseur d’infrastructure. Depuis lors, Amazon a intégré CloudEndure dans sa gamme de services principale, offrant ainsi gratuitement la migration de service à ses clients. À présent, AWS implémente la migration de service comme un moyen d’activer rapidement un processus de secours semi-automatique ou un processus de serveur de secours. AWS ne facture pas à ses clients le processus de migration, mais facture en revanche les ressources redondantes provisionnées pour chaque scénario de reprise d’activité. Néanmoins, l’absence de frais supplémentaires fait de CloudEndure un concurrent immédiat d’une multitude de services tiers de reprise d’activité après sinistre.
Azure Site Recovery
Le service de reprise d’activité après sinistre de Microsoft, Azure Site Recovery, est un déploiement géré d’une méthode de récupération de secours semi-automatique pour les environnements basés sur des machines virtuelles et pour les serveurs physiques (locaux) exécutant Linux ou Windows. Les machines virtuelles sont répliquées activement dans une région secondaire (figure 9.8), vers laquelle un basculement peut être initié d’un simple clic. Des frais mensuels sont facturés aux clients (actuellement environ 25 $) pour chaque serveur ou machine virtuelle qu’Azure Site Recovery protège.
Figure 8 : Scénario de basculement mis en œuvre avec Azure Site Recovery.
Reprise d’activité après sinistre Google Cloud
Comme pour la sauvegarde, Google n’offre pas de service spécifique pour la reprise d’activité après sinistre. Au lieu de cela, le groupe met à la disposition de ses clients les outils et les ressources nécessaires pour le stockage et le transfert de données, et fournit des conseils sur la meilleure façon de les utiliser dans divers scénarios de reprise d’activité après sinistre.
Comme Google offre des options de stockage Coldline et y applique une remise, GCP est applicable à un large éventail de scénarios. Coldline est une option intéressante pour les organisations qui gèrent des volumes importants de données en bloc. Les disques magnétiques rotatifs deviennent des supports peu pratiques pour les fichiers multimédias dont la taille moyenne peut atteindre des dizaines de gigaoctets. Les composants de stockage NAS (Network-Attached Storage) fournissent une solution d’accessibilité et de gestion pour les organisations qui créent des contenus multimédias, mais uniquement au niveau local. Ils présentent une redondance interne, mais ils ne sont pas résistants aux sinistres. Et un scénario de reprise d’activité après sinistre comme les trois scénarios schématisés précédemment ne serait pas pratique (ni même peut-être abordable) pour cette classe de clients. Coldline propose au client au moins un moyen viable d’atteindre un niveau nominal de garantie de continuité de l’activité.