REL13-BP02 Utiliser des stratégies de rétablissement définies pour atteindre les objectifs de rétablissement

Déterminez une stratégie de reprise après sinistre qui répond aux exigences de récupération pour cette charge de travail.

Le choix d'une stratégie de reprise après sinistre est un compromis entre la réduction des temps d'arrêt et des pertes de données (RTOetRPO) et le coût et la complexité de la mise en œuvre de la stratégie. Évitez de mettre en œuvre une stratégie plus stricte que nécessaire, car cela entraînerait des coûts inutiles.

Par exemple, dans le schéma suivant, l'entreprise a déterminé le montant maximal autorisé RTO ainsi que la limite de ce qu'elle peut dépenser pour sa stratégie de rétablissement du service. Compte tenu des objectifs de l'entreprise, les stratégies de reprise après sinistre (éclairage pilote ou veille chaude) satisferont à la fois aux critères RTO et aux critères de coût.

Figure 18 : Choix d'une stratégie de reprise après sinistre basée sur RTO le coût

Pour en savoir plus, consultez Plan de continuité des activités (BCP).

Passez en revue les modèles de mise en œuvre de la stratégie de reprise après sinistre sélectionnée.

Cette étape consiste à comprendre comment mettre en œuvre la stratégie sélectionnée. Les stratégies sont expliquées en utilisant Régions AWS le site principal et le site de rétablissement. Cependant, vous pouvez également choisir d’utiliser des zones de disponibilité dans une seule région comme stratégie de reprise après sinistre, ce qui permet d’exploiter des éléments de plusieurs de ces stratégies.

Dans les étapes suivantes, vous pouvez appliquer la stratégie à votre charge de travail spécifique.

Sauvegarde et restauration 

La sauvegarde et la restauration constituent la stratégie la moins complexe à mettre en œuvre, mais elles nécessiteront plus de temps et d'efforts pour restaurer la charge de travail, ce qui se traduira par une augmentation RTO de RPO Il est recommandé de toujours effectuer des sauvegardes de vos données et de les copier sur un autre site (tel qu'un autre Région AWS).

Figure 19 : architecture de sauvegarde et de restauration

Pour plus de détails sur cette stratégie, voir Disaster Recovery (DR) Architecture on AWS, partie II : Backup and Restore with Rapid Recovery.

Veilleuse

L’approche de veilleuse, vous permet de répliquer vos données depuis la région principale vers la région de reprise. Les ressources principales utilisées pour l’infrastructure de charge de travail sont déployées dans la région de reprise, mais des ressources supplémentaires et toutes les dépendances sont toujours nécessaires pour en faire une pile fonctionnelle. Par exemple, dans la figure 20, aucune instance de calcul n’est déployée.

Figure 20 : architecture avec environnement en veille

Pour plus de détails sur cette stratégie, voir Disaster Recovery (DR) Architecture on AWS, Part III : Pilot Light and Warm Standby.

Secours semi-automatique

L’approche du secours semi-automatique consiste à s’assurer qu’il existe une copie réduite verticalement, mais entièrement fonctionnelle, de votre environnement de production dans une autre région. Cette approche étend le concept d’environnement en veille et réduit le temps de récupération, car votre charge de travail reste active dans une autre région. Si la région de reprise est déployée à pleine capacité, on parle de veille permanente.

Figure 21 : Architecture de secours à chaud

L’utilisation du secours à chaud ou de l’environnement en veille nécessite une augmentation verticale des ressources dans la région de reprise. Pour vérifier que la capacité est disponible en cas de besoin, envisagez de l'utiliser pour les réservations de capacité pour les EC2 instances. Si vous l'utilisez AWS Lambda, la simultanéité provisionnée peut fournir des environnements d'exécution prêts à répondre immédiatement aux appels de votre fonction.

Pour plus de détails sur cette stratégie, voir Disaster Recovery (DR) Architecture on AWS, Part III : Pilot Light and Warm Standby.

Multisite actif/actif

Vous pouvez exécuter votre charge de travail simultanément dans plusieurs régions dans le cadre d’une stratégie multisite active/active. Une stratégie multisite actif/actif dessert le trafic de toutes les régions dans lesquelles il est déployé. Les clients peuvent sélectionner cette stratégie pour des raisons autres que la reprise après sinistre. Elle peut être utilisée pour augmenter la disponibilité ou lors du déploiement d’une charge de travail auprès d’une audience mondiale (pour rapprocher le point de terminaison des utilisateurs et/ou déployer des piles localisées pour l’audience de cette région). Dans le cadre d'une stratégie de reprise après sinistre, si la charge de travail ne peut pas être prise en charge dans l' Régions AWS une des régions où elle est déployée, cette région est évacuée et les autres régions sont utilisées pour maintenir la disponibilité. La stratégie de reprise après sinistre multisite actif/actif est la plus complexe sur le plan opérationnel et ne doit être sélectionnée que lorsque les besoins de l’entreprise l’exigent.

Figure 22 : architecture multisite de type actif/actif

Pour plus de détails sur cette stratégie, voir Architecture de reprise après sinistre (DR) sur AWS, partie IV : actif/actif multisite.

AWS Elastic Disaster Recovery

Si vous envisagez d'adopter une stratégie de veille ou de veille chaude pour la reprise après sinistre, vous AWS Elastic Disaster Recovery pourriez proposer une autre approche offrant de meilleurs avantages. Elastic Disaster Recovery peut proposer un RPO RTO objectif similaire à celui du mode veille à chaud, tout en conservant l'approche peu coûteuse de la veilleuse. Elastic Disaster Recovery réplique vos données de votre région principale vers votre région de reprise, en utilisant une protection continue des données pour obtenir un résultat RPO mesuré en secondes et un RTO résultat mesurable en minutes. Seules les ressources nécessaires à la réplication des données sont déployées dans la région de reprise, ce qui permet de limiter les coûts, à l’instar de la stratégie de l’environnement de veille. En cas d’utilisation de Elastic Disaster Recovery, le service coordonne et orchestre la récupération des ressources informatiques lorsqu’elle est initiée dans le cadre d’un basculement ou d’une opération.

Figure 23 : AWS Elastic Disaster Recovery architecture

Pratiques supplémentaires de protection des données

Avec toutes les stratégies, vous devez également vous prémunir contre les catastrophes liées aux données La réplication continue des données vous protège contre certains types de catastrophes, mais elle peut ne pas vous protéger contre la corruption ou la destruction des données, sauf si votre stratégie inclut également le versionnement des données stockées ou des options de point-in-time restauration. Vous devez également sauvegarder les données répliquées sur le site de restauration pour créer point-in-time des sauvegardes en plus des répliques.

Utilisation de plusieurs zones de disponibilité (AZs) au sein d'une seule Région AWS

Lorsque vous en utilisez plusieurs AZs au sein d'une même région, votre implémentation de DR utilise plusieurs éléments des stratégies ci-dessus. Vous devez d'abord créer une architecture à haute disponibilité (HA) en utilisant plusieurs, AZs comme le montre la Figure 23. Cette architecture utilise une approche active/active multisite, car les EC2instances Amazon et Elastic Load Balancer disposent de ressources déployées dans le cadre de AZs multiples demandes de traitement actif. L'architecture utilise également le mode hot standby : en cas de défaillance de l'RDSinstance Amazon principale (ou de l'AZ lui-même), l'instance de secours est promue en instance principale.

Figure 24 : architecture de multi-AZ

En plus de cette architecture haute disponibilité, vous devez ajouter des sauvegardes de toutes les données requises pour exécuter votre charge de travail. Cela est particulièrement important pour les données limitées à une seule zone, telles que les EBSvolumes Amazon ou les clusters Amazon Redshift. Si une zone de disponibilité tombe en panne, vous devrez restaurer ces données dans une autre zone de disponibilité. Dans la mesure du possible, vous devez également copier les sauvegardes de données vers un autre Région AWS afin de renforcer la protection.

Une approche alternative moins courante à une seule région, la DR multi-AZ, est illustrée dans le billet de blog intitulé « Création d'applications hautement résilientes à l'aide d'Amazon Application Recovery Controller, partie 1 : pile à région unique ». Ici, la stratégie consiste à maintenir le plus d'isolement possible entre les AZs deux, comme le fonctionnement des régions. Avec cette stratégie alternative, vous pouvez choisir une approche active/active ou active/passive.

Évaluez les ressources de votre charge de travail et déterminez quelle sera leur configuration dans la région de reprise avant le basculement (pendant le fonctionnement normal).

Pour l'infrastructure et les AWS ressources, utilisez l'infrastructure sous forme de code AWS CloudFormationou des outils tiers tels que Hashicorp Terraform. Pour effectuer un déploiement sur plusieurs comptes et régions en une seule opération, vous pouvez utiliser AWS CloudFormation StackSets. Pour les stratégies « Multisite actif/actif » et « Veille permanente », l’infrastructure déployée dans la région de reprise dispose des mêmes ressources que la région principale. Pour les stratégies « Environnement en veille » et « Secours à chaud », l’infrastructure déployée nécessitera des actions supplémentaires pour être prête pour la production. À l'aide de CloudFormation paramètres et d'une logique conditionnelle, vous pouvez contrôler si une pile déployée est active ou en attente à l'aide d'un seul modèle. En utilisant Elastic Disaster Recovery, le service répliquera et orchestrera la restauration des configurations d’applications et des ressources informatiques.

Toutes les stratégies de reprise après sinistre nécessitent que les sources de données soient sauvegardées dans la région de restauration Région AWS, puis que ces sauvegardes soient copiées dans la région de restauration. AWS Backupfournit une vue centralisée dans laquelle vous pouvez configurer, planifier et surveiller les sauvegardes de ces ressources. Pour Pilot Light, Warm Standby et Multisite active/active, vous devez également répliquer les données de la région principale vers les ressources de données de la région de restauration, telles que les instances de base de données Amazon Relational Database Service (Amazon) ou les RDS tables Amazon DynamoDB. Ces ressources de données sont donc actives et prêtes à répondre aux demandes dans la région de reprise.

Pour en savoir plus sur le fonctionnement AWS des services dans les différentes régions, consultez cette série de blogs sur la création d'une application multirégionale avec des AWS services.

Déterminez et mettez en œuvre la manière dont vous préparerez votre région de reprise pour le basculement en cas de besoin (lors d’un sinistre).

Pour la stratégie multisite actif/actif, le basculement consiste à évacuer une région et à s’appuyer sur les régions actives restantes. En général, ces régions sont prêtes à accepter du trafic. Pour les stratégies Pilot Light et Warm Standby, vos actions de restauration devront déployer les ressources manquantes, telles que les EC2 instances de la Figure 20, ainsi que toutes les autres ressources manquantes.

Pour toutes les stratégies ci-dessus, vous devrez peut-être promouvoir les instances en lecture seule des bases de données au rang d’instances principales en lecture/écriture.

Pour la sauvegarde et la restauration, la restauration des données à partir d'une sauvegarde crée des ressources pour ces données, telles que des EBS volumes, des instances de base de données et des tables RDS DynamoDB. Vous devez également restaurer l’infrastructure et déployer le code. Vous pouvez l'utiliser AWS Backup pour restaurer les données dans la région de restauration. Pour plus d’informations, consultez REL09-BP01 Identifiez et sauvegardez toutes les données qui doivent être sauvegardées, ou reproduisez les données à partir des sources. La reconstruction de l'infrastructure inclut la création de ressources telles que des EC2 instances en plus de l'Amazon Virtual Private Cloud (AmazonVPC), des sous-réseaux et des groupes de sécurité nécessaires. Vous pouvez automatiser une grande partie du processus de restauration. Pour savoir comment procéder, consultez ce billet de blog.

Déterminez et mettez en œuvre la manière dont vous redirigerez le trafic vers le basculement en cas de besoin (lors d’un sinistre).

Cette opération de basculement peut être lancée automatiquement ou manuellement. Le basculement lancé automatiquement sur la base de la surveillance de l’état ou d’alarmes doit être utilisé avec prudence, car un basculement inutile (fausse alerte) entraînerait des coûts tels que l’indisponibilité et la perte de données. Le basculement manuel est donc souvent utilisé. Dans ce cas, nous vous conseillons tout de même d’automatiser les étapes de basculement, de sorte que vous n’ayez à appuyer que sur un bouton pour lancer le basculement.

Il existe plusieurs options de gestion du trafic à prendre en compte lors de l'utilisation AWS des services. L’une des options consiste à utiliser Amazon Route 53. À l'aide d'Amazon Route 53, vous pouvez associer plusieurs points de terminaison IP dans un ou plusieurs points de terminaison Régions AWS à un nom de domaine Route 53. Pour implémenter le basculement initié manuellement, vous pouvez utiliser Amazon Application Recovery Controller, qui fournit un plan de données hautement disponible API pour rediriger le trafic vers la région de restauration. Lors de la mise en œuvre du basculement, utilisez les opérations du plan de données et évitez celles du plan de contrôle, comme décrit dans REL11-BP04 S'appuyer sur le plan de données et non sur le plan de contrôle lors de la restauration.

Pour en savoir plus à ce sujet et sur d’autres options, consultez cette section du livre blanc sur la reprise après sinistre.

Élaborez un plan pour déterminer la façon dont votre charge de travail se rétablira.

Failback consiste à renvoyer l’exploitation de la charge de travail à la région principale, après qu’un événement de sinistre s’est atténué. La mise en service de l’infrastructure et du code dans la région principale suit généralement les mêmes étapes que celles utilisées initialement. Elle s’appuie notamment sur l’infrastructure en tant que code et les pipelines de déploiement de code. Le défi posé par failback consiste à restaurer les magasins de données et à garantir leur cohérence avec la région de reprise en cours d’exécution.

En cas de panne, les bases de données de la région de restauration sont actives et contiennent les up-to-date données. L'objectif est alors de resynchroniser la région de restauration vers la région principale, en s'assurant que c'est up-to-date le cas.

Certains AWS services le feront automatiquement. Si vous utilisez des tables globales Amazon DynamoDB, même si la table de la région principale devenait indisponible, DynamoDB reprendrait la propagation de toutes les écritures en attente lorsqu’elle se reconnecterait. Si vous utilisez Amazon Aurora Global Database et que vous utilisez un basculement planifié géré, la topologie de réplication existante de la base de données globale Aurora est conservée. Par conséquent, l’ancienne instance en lecture/écriture de la région principale deviendra un réplica et recevra les mises à jour de la région de reprise.

Dans les cas où cela n’est pas automatique, vous devrez rétablir la base de données dans la région principale en tant que réplica de la base de données dans la région de reprise. Dans de nombreux cas, cela implique la suppression de l’ancienne base de données principale et la création de nouveaux réplicas.

Après un basculement, si vous pouvez poursuivre l’exécution dans la région de reprise, envisagez d’en faire la nouvelle région principale. Vous devriez alors suivre toutes les étapes ci-dessus pour convertir l’ancienne région principale en région de reprise. Certaines organisations effectuent une rotation planifiée, en échangeant périodiquement leurs régions principale et de reprise (par exemple tous les trois mois).

Toutes les étapes nécessaires au basculement et au rétablissement doivent être conservées dans un playbook accessible à tous les membres de l’équipe et révisé périodiquement.

En utilisant Elastic Disaster Recovery, le service permettra d’orchestrer et d’automatiser le processus de failback. Pour en savoir plus, consultez la section Réalisation d’un failback.