Test et exécution d’un basculement

Un plan de reprise après sinistre qui n’a jamais été testé n’est qu’une hypothèse. Le test de basculement vous permet de vérifier que vos VMs démarrent correctement, que les applications se lancent et que la connectivité réseau fonctionne dans la région cible, sans perturber l’environnement source ni interrompre la réplication en cours. De nombreuses organisations ne découvrent les lacunes de leur plan de reprise après sinistre qu’au moment où un sinistre réel survient, c’est-à-dire précisément lorsque les conséquences d’un plan défaillant sont les plus graves. Les tests de basculement réguliers constituent une exigence de conformité pour la plupart des cadres réglementaires.

ASR prend en charge trois types d’actions de basculement. Le test de basculement crée des copies des VMs ayant basculé dans un réseau isolé, dans lequel vous spécifiez le VNet cible, sans affecter la réplication ni l’environnement source. Le basculement planifié est utilisé pour les migrations ou opérations de maintenance planifiées : il synchronise d’abord les dernières modifications, puis arrête la source avant d’effectuer le basculement. Le basculement non planifié, utilisé lors d’un sinistre réel, bascule immédiatement depuis le dernier point de récupération sans attendre une synchronisation finale.

Pour exécuter un test de basculement dans le portail, sélectionnez l’élément protégé, cliquez sur Test de basculement, choisissez un point de récupération — le dernier point cohérent en cas d’incident, le dernier point cohérent avec l’application ou un moment précis —, puis sélectionnez un réseau virtuel cible, généralement un VNet de test isolé dédié. ASR démarre la VM dans la région cible à l’aide des disques de réplica. La VM de test apparaît à côté du réplica, mais elle est totalement indépendante : la production n’est pas affectée. Après le test, cliquez sur Nettoyer le test de basculement pour supprimer les VMs de test.

Lors du basculement, vous sélectionnez un point de récupération dans la fenêtre de rétention d’ASR. Les options sont les suivantes : Dernier (RPO le plus faible) — le point de récupération cohérent en cas d’incident le plus récent, ce qui réduit au minimum la perte de données. Dernier traité — le point traité le plus récemment, qui peut avoir quelques minutes de retard. Dernier cohérent avec l’application — le point de récupération cohérent avec l’application le plus récent ; il peut être plus ancien, mais garantit une récupération propre de l’application. Personnalisé — un point de récupération plus ancien précis, permettant de revenir à un état fiable antérieur à l’incident.

Un plan de récupération regroupe plusieurs VMs protégées et définit l’ordre et le calendrier de leur basculement. Vous pouvez spécifier quelles VMs démarrent en premier, par exemple les serveurs de base de données avant les serveurs d’application, ajouter des points d’approbation manuelle pour interrompre le basculement afin qu’une personne effectue une validation, et insérer des runbooks Azure Automation pour exécuter des scripts avant et après le basculement, par exemple pour mettre à jour les enregistrements DNS, configurer des répartiteurs de charge ou envoyer des notifications. Les plans de récupération peuvent être testés séparément au moyen d’un test de basculement.

Un test de basculement permet de mesurer votre RTO (objectif de délai de récupération) réel. Démarrez un chronomètre lorsque vous lancez le basculement et arrêtez-le lorsque l’application est entièrement opérationnelle et accessible aux utilisateurs. Un basculement Azure-à-Azure typique s’achève en 15 à 30 minutes pour une VM unique, mais les applications à plusieurs niveaux ayant des dépendances peuvent nécessiter davantage de temps. Documentez toutes les étapes qui ajoutent une durée imprévue, par exemple la propagation DNS ou le démarrage progressif de l’application, puis corrigez-les avant le test suivant.

Après un basculement planifié, par exemple lors d’une migration vers une nouvelle région, vous exécutez Commit pour finaliser le basculement. La validation arrête la réplication depuis la source et désigne les VMs cibles comme nouvelles VMs principales. Une fois la validation effectuée, vous pouvez activer la reprotection afin d’inverser le sens de la réplication et de faire de la région source d’origine la nouvelle cible de reprise après sinistre. Vous pourrez ainsi effectuer un retour vers la région d’origine une fois l’incident résolu.

Le retour arrière est le processus qui consiste à ramener les charges de travail vers la région d’origine après un sinistre ou une migration planifiée. Les étapes sont les suivantes : reprotéger les VMs ayant basculé, en inversant la réplication pour répliquer depuis la nouvelle VM principale vers la région d’origine, attendre la fin de la synchronisation initiale, puis effectuer un basculement planifié vers la région d’origine. Le retour arrière exige que l’infrastructure source d’origine soit toujours intacte ; si elle a été détruite, vous devrez peut-être reconstruire la zone d’atterrissage avant d’effectuer le retour.

Après un test de basculement, vous devez effectuer l’opération Nettoyer le test de basculement dans le portail afin de supprimer les VMs de test et leurs disques associés. Sans nettoyage, les VMs de test continuent de fonctionner et d’engendrer des coûts de calcul. Cette étape réinitialise également l’état de test de basculement de l’élément protégé, ce qui vous permet d’exécuter un autre test ultérieurement. L’automatisation du nettoyage, par exemple en le planifiant une heure après le début du test via un runbook Automation, évite que des VMs de test oubliées fonctionnent pendant plusieurs jours.

Chaque test de reprise après sinistre doit produire un rapport d’exercice de reprise après sinistre indiquant la date et le scénario testés, les points de récupération utilisés, les RTO et RPO obtenus, les problèmes découverts et les mesures correctives prises. Cette documentation répond aux exigences des auditeurs pour des cadres tels que ISO 27001 et SOC 2, qui imposent des tests réguliers de reprise après sinistre. Stockez les rapports d’exercice dans un emplacement sécurisé accessible aux équipes IT et de continuité d’activité.

La tarification d’Azure Site Recovery s’applique par instance protégée et par mois ; ces frais couvrent à la fois le service de réplication et l’orchestration. Vous payez également le stockage utilisé par les disques de réplica gérés dans la région cible et par le compte de stockage du cache pendant la réplication. Le transfert de données sortant entre les régions Azure pour le trafic de réplication est facturé aux tarifs de sortie habituels, contrairement à Azure Backup, pour lequel la sortie entre régions appairées est gratuite. Pour la réplication d’un environnement local vers Azure, les licences Windows Server des VMs Azure peuvent bénéficier de l’Azure Hybrid Benefit afin de réduire les coûts.

Dans cette leçon, vous avez appris que le test de basculement valide votre plan de reprise après sinistre dans un réseau isolé sans affecter la production, que les plans de récupération ordonnancent le basculement de plusieurs VMs avec des points d’approbation manuelle et des étapes de runbooks automatisés, et que le retour arrière ramène les charges de travail vers la région d’origine en inversant le sens de la réplication après un sinistre. Nous allons maintenant découvrir Azure CDN pour accélérer la diffusion mondiale de contenu.