Veilleuse et secours à chaud

Lorsque votre exigence de RTO est plus stricte que quelques heures, Backup and Restore ne suffit pas. Les deux niveaux de DR suivants, Pilot Light et Warm Standby, maintiennent en permanence une partie ou la totalité de votre infrastructure en fonctionnement dans la région de DR, ce qui réduit considérablement le temps de récupération. Ces deux stratégies impliquent de maintenir continuellement un environnement de DR et d’utiliser le basculement des contrôles d’état de Route 53 pour rediriger le trafic lors d’un sinistre. Elles se distinguent par la quantité de l’environnement de DR qui fonctionne réellement.

Avec la stratégie Pilot Light, vous ne maintenez en fonctionnement dans la région de DR que le cœur critique de votre système, généralement uniquement le niveau de base de données avec une réplication continue. Les serveurs d’application ne sont PAS en fonctionnement ; à la place, vous conservez des AMI, des modèles de lancement ou une infrastructure sous forme de code préconfigurés permettant de les lancer rapidement. Imaginez une veilleuse à gaz qui brûle très faiblement et peut allumer la flamme complète en quelques minutes lorsque cela est nécessaire. Le RTO est généralement de 30 à 60 minutes.

Lorsque la région primaire tombe en panne et que le basculement Pilot Light est déclenché : Step 1 — Promouvez le réplica en lecture RDS de la région de DR en base de données primaire autonome. Step 2 — Lancez les instances EC2 à partir de l’AMI ou du modèle de lancement préconfiguré. Step 3 — Créez ou activez l’Application Load Balancer et enregistrez les nouvelles instances EC2. Step 4 — Mettez à jour la configuration de l’application afin qu’elle pointe vers le point de terminaison de la base de données promue. Step 5 — Le contrôle d’état de Route 53 termine le basculement DNS. Durée totale : 30 à 60 minutes.

Avec la stratégie Warm Standby, une version complète mais réduite de votre environnement de production fonctionne en continu dans la région de DR. Tous les niveaux de l’application sont actifs — serveurs Web, serveurs d’application et base de données — mais avec une capacité réduite (par exemple, 2 instances au lieu de 20). Lors du basculement, vous augmentez la capacité de l’environnement de DR pour l’adapter à la charge de production. Route 53 bascule automatiquement le trafic au moyen du basculement fondé sur les contrôles d’état. Le RTO est généralement inférieur à 15 minutes. Warm Standby est le niveau de DR le plus utilisé pour les applications critiques pour l’activité.

Aurora Global Database est la technologie de base de données idéale pour la DR Warm Standby. Le cluster de la région secondaire fonctionne en permanence, reçoit continuellement la réplication (décalage <1 seconde) et peut être promu au rang de primaire en moins d’une minute, bien plus rapidement que la promotion d’un réplica en lecture RDS (qui nécessite d’arrêter la réplication et d’appliquer le décalage restant). Aurora Global Database constitue donc le choix recommandé lorsque votre exigence de RTO se mesure en minutes plutôt qu’en dizaines de minutes.

Pilot Light et Warm Standby s’appuient tous deux sur le routage de basculement Route 53 pour rediriger automatiquement le trafic. Configurez un enregistrement Primary pointant vers l’ALB ou le point de terminaison de votre région de production, avec un contrôle d’état associé. Configurez un enregistrement Secondary pointant vers le point de terminaison de votre région de DR. Lorsque Route 53 détecte que le contrôle d’état primaire a échoué pendant la durée définie, il cesse de renvoyer l’enregistrement primaire et ne fournit plus que l’enregistrement secondaire, le tout dans la limite de la période TTL DNS.

Pour que Warm Standby atteigne son objectif de RTO, l’environnement de DR doit être préparé à l’avance : il doit être entièrement configuré et testé afin que la seule action requise lors du basculement soit d’augmenter sa capacité. Cela signifie que les connexions aux bases de données sont établies et mises en cache, que les fichiers de configuration de l’application font référence aux points de terminaison de la région de DR, que les instances EC2 sont en service derrière l’ALB (même en petit nombre) et que les contrôles d’état réussissent. Effectuez chaque mois des exercices de DR au cours desquels vous simulez un basculement afin de vous assurer que l’environnement reste synchronisé avec la configuration de production.

Maintenir votre environnement de DR synchronisé avec la production constitue le défi opérationnel le plus difficile. Si vous configurez manuellement la production et oubliez de mettre à jour la DR, votre environnement de DR pourrait ne pas fonctionner correctement lors d’un véritable sinistre. La solution consiste à utiliser l’infrastructure sous forme de code (IaC), avec les mêmes modèles déployés dans les deux régions. Utilisez AWS CloudFormation StackSets ou Terraform avec plusieurs espaces de travail pour déployer une infrastructure identique dans les deux régions à partir d’une base de code unique. Cela élimine la dérive de configuration.

La différence de coût entre les deux stratégies est importante. Pilot Light vous coûte uniquement le réplica de base de données (généralement 50 à 100 % du coût de la base de données primaire) ainsi qu’un réseau minimal dans la région de DR. Les serveurs d’application étant arrêtés, aucun coût EC2 n’est engendré. Warm Standby ajoute le coût d’exécution d’instances EC2 à capacité réduite, d’un ALB et, éventuellement, d’un cluster de cache plus petit, soit généralement 15 à 30 % du coût total de l’environnement de production. La question est de savoir si le RTO plus rapide de Warm Standby justifie ce coût récurrent supérieur.

Après la restauration de la région Primary, vous devez prévoir un plan de rétablissement pour y revenir. Le rétablissement est souvent la partie la plus délicate de la DR : pendant la panne, la région DR a peut-être traité de nouvelles données qu’il faut synchroniser à nouveau avec la région Primary. Pour les bases de données, vous devrez peut-être configurer une réplication inverse ou resynchroniser les données de la région DR vers la région Primary. Pour Route 53, vous réactivez l’enregistrement Primary avec son contrôle d’état. Planifiez et testez toujours votre procédure de rétablissement avec autant de soin que le basculement lui-même.

Choisissez Pilot Light lorsque votre RTO autorise 30 à 60 minutes et que vous souhaitez réduire les coûts de DR. Le principal risque est le temps nécessaire pour lancer et configurer les serveurs d’application pendant une catastrophe, sous pression. Choisissez Warm Standby lorsque votre RTO exige une récupération en moins de 15 minutes, lorsque votre application est suffisamment complexe pour que son lancement à partir de zéro pendant une catastrophe soit risqué, ou lorsque votre engagement de SLA envers vos clients exige une récupération plus rapide. Pour la plupart des charges de production d’importance moyenne, Warm Standby offre le meilleur équilibre.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Pilot Light conserve uniquement la base de données en fonctionnement dans la région DR et lance les serveurs d’application lors du basculement, que Warm Standby exécute un environnement complet aux capacités réduites qui augmente sa capacité lors du basculement, et que l’infrastructure en tant que code empêche la dérive de configuration entre les environnements Primary et DR. Planifiez et testez toujours les procédures de rétablissement, tout comme celles de basculement. Nous allons maintenant étudier le mode actif-actif sur plusieurs sites avec DynamoDB Global Tables et Route 53.