REL 13: Comment planifier la reprise après sinistre (DR) ?

La mise en place de sauvegardes et de composants de charge de travail redondants constitue le début de votre stratégie de DR. RTO et RPO sont vos objectifs pour la restauration de la disponibilité. Définissez-les en fonction des besoins de l'entreprise. Mettez en œuvre une stratégie pour atteindre ces objectifs, en particulier en tenant compte de l'emplacement et de la fonction des données et des ressources de charge de travail.

Ressources

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)
What Is AWS Backup?
Remediating Noncompliant AWS Resources by AWS Config Rules
AWS Systems Manager Automation
AWS CloudFormation: Detect Drift on an Entire CloudFormation Stack
Amazon RDS: Cross-region backup copy
RDS: Replicating a Read Replica Across Regions
S3: Cross-Region Replication
Route 53: Configuring DNS Failover
CloudEndure Disaster Recovery
How do I implement an Infrastructure Configuration Management solution on AWS?
CloudEndure Disaster Recovery to AWS
AWS Marketplace: products that can be used for disaster recovery
APN Partner: partners that can help with disaster recovery

Bonnes pratiques:

• Définition des objectifs de reprise pour les temps d'arrêt et les pertes de données: La charge de travail est associée à une durée maximale d'interruption admissible (RTO) et à un objectif de point de récupération (RPO).

• Utilisation de stratégies de reprise définies pour répondre aux objectifs de reprise: Une stratégie de DR a été définie pour répondre aux objectifs.

• Test de validation de la mise en œuvre de la DR: Testez régulièrement le basculement vers la région de DR pour vous assurer que les objectifs RTO et RPO sont bien atteints.

• Gestion de l'écart de configuration au niveau du site ou de la région de DR: S'assurer que l'infrastructure, les données et la configuration sont conformes aux besoins du site ou de la région de RD. Par exemple, vérifiez que les AMI et les quotas de service sont à jour.

• Automatisation de la reprise: Utilisez AWS ou des outils tiers pour automatiser la reprise du système et acheminer le trafic vers le site ou la région de DR.

Plan d'amélioration

Définition des objectifs de reprise pour les temps d'arrêt et les pertes de données

Établissement de catégories de besoin pour vos charges de travail: Identifiez le principal moteur de l'activité et les charges de travail des facilitateurs. Identifiez les charges de travail qui sont des outils visibles uniquement en interne et des charges de travail visibles en externe. Identifiez l'impact commercial des temps d'arrêt pour chaque charge de travail. Créez cinq catégories ou moins et affinez la plage de vos objectifs de temps de récupération (RTO) et de point de récupération (RPO).

• Identifiez les charges de travail essentielles à vos missions d'entreprise, notamment celles qui favorisent et facilitent généralement le plus l'obtention d'un bon chiffre d'affaires.
• Identifiez les charges de travail d'entreprise les plus importantes, notamment ce sont généralement les outils de rapport et de modification de l'exécution des applications (comme les systèmes de gestion du contenu).
• Identifiez les charges de travail qui ne favorisent pas vos activités et dont les données pourraient être difficiles à recréer (comme les systèmes de test avec des données nettoyées).
• Identifiez les charges de travail qui ne favorisent pas vos activités et dont les données sont moins difficiles, voire faciles à recréer (comme les environnements de développement).
• Identification d'autres catégories en fonction de vos besoins

Utilisation de stratégies de reprise définies pour répondre aux objectifs de reprise

Définition des stratégies pour atteindre l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) pour chaque catégorie: Vous devez choisir l'une des stratégies suivantes si une stratégie sur plusieurs régions est nécessaire pour votre charge de travail. Elles sont répertoriées par ordre croissant de complexité et ordre décroissant de RTO et RPO. La sauvegarde et la restauration dans une autre région AWS peuvent rassurer davantage que les données seront disponibles lorsque cela est nécessaire. Cependant, pour les autres stratégies, vous devez évaluer leur complexité potentielle et leur coût par rapport à ce que vous pouvez réaliser à l'aide de plusieurs zones de disponibilité au sein d'une région AWS.
AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)
Amazon RDS: Cross-region backup copy
RDS: Replicating a Read Replica Across Regions
S3: Cross-Region Replication

• Sauvegarde et restauration (RPO en heures, RTO en 24 heures ou moins: Sauvegardez vos données et applications dans la région de DR. Restaurez ces données si nécessaire aux fins de DR.
• Pilot Light (RPO en minutes, RTO en heures): Maintenez une version minimale d'un environnement exécutant toujours les éléments principaux les plus critiques de votre système dans la région de DR. Lorsque vient le moment de la reprise, vous pouvez rapidement mettre en service un environnement de production à grande échelle autour du cœur critique.
• Warm Standby (RPO en secondes, RTO en minutes): Tenez à jour une version réduite d'un environnement entièrement fonctionnel en cours d'exécution dans la région de DR. Les systèmes stratégiques sont entièrement dupliqués et sont toujours opérationnels, mais avec une flotte réduite. Lorsque vient le moment de la reprise, le système est rapidement mis à l'échelle pour gérer la charge de production.
• Actif-actif multirégion (RPO correspond à zéro seconde ou éventuellement à une seconde, RTO en secondes): Votre charge de travail est déployée vers plusieurs régions AWS d'où elle traite activement le trafic. Pour que cette stratégie fonctionne, vous devez synchroniser les utilisateurs et les données entre les régions que vous utilisez. Lorsque vient le moment de la reprise, utilisez des services tels qu'Amazon Route 53 ou AWS Global Accelerator pour acheminer le trafic utilisateur là où votre charge de travail est saine.
  AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
  Build a serverless multi-region, active-active backend solution in an hour
  Multi-region serverless backend — reloaded

Test de validation de la mise en œuvre de la DR

Préparez vos charges de travail pour la reprise. Testez régulièrement vos chemins de reprise.: Le calcul orienté récupération (ROC) identifie les caractéristiques des systèmes qui améliorent la reprise. Ces caractéristiques sont les suivantes : isolation et redondance, capacité de l'ensemble du système à réduire les modifications, capacité à surveiller et déterminer l'état de santé, capacité à fournir des diagnostics, reprise automatique, conception modulaire et capacité à redémarrer. Entraînez votre chemin de reprise pour vous assurer qu'elle peut s'effectuer au moment et à l'état spécifiés. Utilisez vos runbooks au cours de cette reprise pour documenter les problèmes et trouver des solutions pour les résoudre avant le prochain test.
The Berkeley/Stanford recovery-oriented computing project

Utilisation de CloudEndure Disaster Recovery pour implémenter et tester votre stratégie de DR
Testing the Disaster Recovery Solution with CloudEndure
CloudEndure Disaster Recovery
CloudEndure Disaster Recovery to AWS

Gestion de l'écart de configuration au niveau du site ou de la région de DR

Assurez-vous que vos pipelines de diffusion assurent effectivement cette diffusion au niveau de votre site principal ainsi qu'au niveau de vos sites de sauvegarde.: Les pipelines de diffusion pour le déploiement d'applications en production doivent être distribués à tous les emplacements spécifiés de la stratégie de DR, y compris les environnements de développement et de test.

Activer AWS Config pour suivre les emplacements d'écart potentiels: Utilisez les règles AWS Config pour créer des systèmes qui appliquent vos stratégies de DR et génèrent des alertes lorsqu'elles détectent un écart.
Remediating Noncompliant AWS Resources by AWS Config Rules
AWS Systems Manager Automation

Utilisation d'AWS CloudFormation pour le déploiement de votre infrastructure: AWS CloudFormation peut détecter l'écart entre ce que vos modèles CloudFormation spécifient et ce qui est réellement déployé.
AWS CloudFormation: Detect Drift on an Entire CloudFormation Stack

Automatisation de la reprise

Automatisation des chemins de reprise: Pour les temps de reprise courts, le jugement et les actions de l'humain ne peuvent pas être utilisés pour des scénarios à haute disponibilité. Le système doit absolument reprendre automatiquement, quelle que soit la situation.

• Utilisation CloudEndure Disaster Recovery pour le basculement et la restauration automatisés: CloudEndure Disaster Recovery réplique en continu vos machines (notamment le système d'exploitation, la configuration d'état du système, les bases de données, les applications et les fichiers) dans une zone intermédiaire économique de votre compte AWS cible et de votre région préférée. En cas de sinistre, vous pouvez demander à CloudEndure Disaster Recovery de lancer automatiquement des milliers de vos machines dans leur état entièrement mis en service en quelques minutes.
  Performing a Disaster Recovery Failover and Failback
  CloudEndure Disaster Recovery