Plans de reprise et basculement automatisé

Un Recovery Plan dans Azure Site Recovery est une séquence structurée et ordonnée d’étapes qui orchestre le basculement de plusieurs VMs simultanément. Plutôt que de basculer chaque VM individuellement, un Recovery Plan les regroupe en groupes qui basculent dans l’ordre — ce qui garantit que l’infrastructure (base de données, intergiciel, interface web) démarre dans le bon ordre, comme lors du déploiement initial.

Pour créer un Recovery Plan, vous sélectionnez le site source (région Primary) et le site cible (région secondaire), puis vous ajoutez les VMs à inclure. L’assistant du plan crée automatiquement un groupe par défaut, mais vous pouvez en ajouter d’autres pour contrôler la séquence de basculement. Les VMs d’un même groupe basculent simultanément ; les groupes s’exécutent dans l’ordre de leur numéro.

Pour une application classique à trois niveaux, le Recovery Plan doit comporter trois groupes :

• Groupe 1 — VMs du niveau base de données (elles doivent démarrer en premier)
• Groupe 2 — VMs du niveau application/intergiciel
• Groupe 3 — VMs de l’interface web (elles démarrent en dernier)

Chaque groupe attend que le groupe précédent ait terminé son basculement avec succès avant de démarrer. Cela reproduit l’ordre de démarrage correct et empêche les VMs du niveau web de démarrer avant que la base de données soit prête à accepter les connexions.

Les Recovery Plans prennent en charge des actions Pre et des actions postérieures à chaque limite entre groupes. Il peut s’agir des éléments suivants :

• Actions manuelles — mettre le basculement en pause et attendre la confirmation d’une personne (par exemple, « Vérifier que la base de données est prête »)
• Runbooks Azure Automation — exécuter automatiquement un script (par exemple, mettre à jour les enregistrements DNS ou désactiver le mode maintenance)

L’utilisation de runbooks Automation permet un basculement entièrement automatisé, sans intervention humaine, pour les charges de travail de niveau 1.

Azure Site Recovery prend en charge deux types de basculement :

• Basculement planifié — lancé avant un événement connu (par exemple, une maintenance du centre de données). La VM Primary est arrêtée proprement, les données sont synchronisées, puis la VM secondaire démarre. Aucune perte de données.
• Basculement non planifié — déclenché pendant un sinistre réel. La VM Primary peut être indisponible ; ASR utilise donc le point de contrôle de réplication le plus récent. Une perte de données est possible selon le RPO.

Après un basculement, les VMs récupérées dans la région secondaire sont dans un état de Commit en attente. Vous devez Commit le basculement pour confirmer que le site secondaire est désormais le site actif et que vous ne souhaitez pas revenir en arrière. Une fois le Commit effectué, vous pouvez configurer la réplication inversée pour protéger le site secondaire, puis effectuer ultérieurement un retour arrière vers la région Primary lorsque celle-ci aura été restaurée.

Après avoir effectué le Commit d’un basculement, les éléments répliqués dans la région Primary d’origine ne sont plus répliqués activement. Pour rétablir la protection, vous devez réactiver la protection des éléments : cela inverse le sens de la réplication afin que la nouvelle région Primary (anciennement secondaire) réplique vers la région Primary d’origine. Le rétablissement de la protection prend du temps et doit être lancé dès que la région Primary d’origine est de nouveau disponible.

Chaque étape d’un plan de récupération contribue au RTO total. Les éléments qui consomment généralement du temps sont notamment :

• temps de démarrage des VMs (2 à 5 minutes par VM)
• temps de préparation de l’application (initialisation du pool de connexions à la base de données, mise en cache)
• propagation du DNS après des modifications d’adresses IP
• temps d’attente pour l’approbation manuelle

Mesurez chaque étape lors des basculements de test et additionnez-les pour calculer votre RTO réel par rapport à votre objectif.

Après un basculement, les VMs de la région secondaire ont des adresses IP différentes. Pour les applications qui exposent un nom DNS public, vous devez mettre à jour le DNS afin qu’il pointe vers les nouvelles adresses IP. Utilisez un runbook d’automatisation Azure comme action postérieure au basculement pour mettre à jour Azure DNS ou l’état de santé des points de terminaison de Traffic Manager afin de rediriger automatiquement le trafic — ce qui évite une étape manuelle susceptible de retarder votre RTO.

Pendant un basculement, la vue Jobs du portail Azure dans le coffre Recovery Services affiche en temps réel la progression de chaque étape du plan de récupération. Vous pouvez voir quel groupe est en cours d’exécution, quelles VMs ont démarré correctement et si des scripts ou des actions manuelles sont en attente. La surveillance de cette vue permet à l’équipe de récupération d’intervenir rapidement en cas d’échec d’une étape.

Principales bonnes pratiques pour les plans de récupération :

• Gardez les groupes de petite taille (5 à 10 VMs) afin de limiter l’étendue de l’impact en cas d’échec d’un groupe
• Utilisez des runbooks d’automatisation plutôt que des actions manuelles chaque fois que possible afin de réduire le RTO
• Documentez le temps de démarrage prévu pour chaque groupe afin de pouvoir calculer le RTO
• Exécutez un basculement de test au moins une fois par trimestre pour valider le plan
• Examinez et mettez à jour le plan chaque fois que de nouvelles VMs sont ajoutées ou que l’architecture de l’application change

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris qu’un plan de récupération orchestre le basculement ordonné de plusieurs VMs, avec des actions avant et après chaque groupe ; qu’un basculement imprévu utilise le dernier point de contrôle de réplication, tandis qu’un basculement planifié n’entraîne aucune perte de données ; et qu’après un basculement, vous devez valider et reprotéger les ressources afin de rétablir la protection DR. Nous allons maintenant voir comment tester les plans DR sans affecter la production.