1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Tu crois que c’est bon parce qu’ASR est activé ? Que ton Recovery Services Vault est en place, et que t’as cliqué sur “Enable Replication” ?

La vérité, c’est que la réplication ne garantit ni la résilience, ni la réussite d’un failover.

Avant même de parler scripts, il faut poser les bonnes questions :

• Est-ce que mes disques sont nommés et structurés correctement pour faciliter un failover ?
• Est-ce que mes réseaux cibles sont prêts (NSG, ASG, subnets, IP statiques à conserver) ?
• Est-ce que j’ai prévu une stratégie claire de test régulier, sans impacter la prod ?
• Et surtout… est-ce que je sais revenir en arrière proprement après une bascule ?

👉 ASR, ce n’est pas juste un “backup temps réel”.
C’est un outil puissant, mais qui nécessite un vrai cadrage, une préparation réseau rigoureuse, et une orchestration soignée des VM, disques, IP et groupes d’accès.

Dans ce scénario, on va justement simuler une situation réelle, avec :

🔵 Des IP statiques à conserver pour faciliter l’accès (Bastion, supervision, ACLs…)
🔵 Une base de données Always-On entre az1 et az2 (latence critique)
🔵 Des VMs qui doivent impérativement rester dans la même zone que leur BDD
🔵 Et un ASR piloté de bout en bout, sans clics inutiles dans le portail

3. SCÉNARIO DE BASCULE

Tu viens de mettre en place une infrastructure soignée dans Azure pour une application critique.
Tout est aligné avec les bonnes pratiques :

🔵 Des VMs réparties intelligemment sur plusieurs zones de disponibilité (az1, az2, az3)
🔵 Une base de données SQL en Always-On, avec une réplication entre az1 (primaire) et az2 (secondaire)
🔵 Des IP statiques pour toutes les VMs, afin de ne rien casser côté Bastion, supervision, ou règles NSG/ASG
🔵 Une topologie réseau claire, structurée, maîtrisée.

⚠️ Mais très vite, la réalité t’a rattrapé.

Le problème n’est pas l’infrastructure, mais l’application

Après avoir fièrement réparti tes VMs applicatives sur les 3 zones (pour profiter de la résilience zonale), tu commences à recevoir des retours utilisateurs :

“L’appli rame quand je me connecte depuis certaines zones…”
“Des lenteurs sur l’export des fichiers…”
“Des délais anormaux sur certaines actions de la BDD…”

Tu testes, tu traces, tu mesures.
Et là, le diagnostic tombe : les VMs hébergeant le front et les services métiers ne sont pas dans la même zone que la base de données primaire.

La latence inter-zone, pourtant faible sur le papier, devient pénalisante dans un contexte transactionnel exigeant.

Tu en parles à l’éditeur de la solution métier qui confirme le point :
▶️ Les VMs doivent impérativement se trouver dans la même AZ que le nœud SQL principal pour garantir la performance attendue.

Ce qu’on va faire dans cet article

🎯 Simuler une bascule intelligente orchestrée avec Azure Site Recovery (ASR)

4. CHOIX D’ARCHITECTURE

Avant de foncer dans les scripts ou la configuration d’ASR, il est essentiel de poser les bons choix d’architecture.
Pourquoi ? Parce qu’un plan de continuité raté se joue souvent… dès le design.

Objectif visé : résister à une panne de zone

L’architecture retenue repose sur une logique simple et robuste :

✅ Deux Availability Zones bien distinctes :

• Zone 1 = zone primaire (là où tournent actuellement les VMs critiques)
• Zone 2 = zone secondaire, qui sert de cible de bascule en cas d’incident majeur

L’objectif est clair : pouvoir relancer rapidement et proprement les VMs critiques dans une autre zone si la principale devient indisponible.

Organisation des ressources

• 🔵 Un Resource Group source pour les VMs en production
• 🔵 Un Resource Group destination pour les VMs répliquées (en attente dans ASR)
• 🔵 Un Recovery Services Vault commun à tous les environnements de la souscription
• 🔵 Car Azure limite à 500 RSV par souscription, inutile d’en multiplier sans raison
• 🔵 Un compte de stockage dédié au cache ASR, privé et isolé dans un RG spécifique
• 🔵 Des Private Endpoints pour sécuriser les accès au Storage, au Vault, etc.

Et les Availability Sets dans tout ça ?

Initialement, on voulait garder les VMs dans la même zone, mais réparties sur plusieurs fault domains grâce aux Availability Sets.
Mais cette stratégie est incompatible avec la réservation de capacité proposée par ASR (Capacity Reservation Group)

Le choix final : VMSS en mode Flexible

Nous avons donc basculé sur une approche avec Virtual Machine Scale Sets (VMSS) en mode Flexible, pour plusieurs raisons :

• 🟢 Permettre la répartition sur plusieurs zones (mode max spreading)
• 🟢 Bénéficier du contrôle fin par zone (ex : --zone 1, --zone 2)
• 🟢 Gérer plus simplement les extensions, suppressions ou remplacements de VM
• 🟢 Assurer la compatibilité avec les groupes de réservation de capacité

4. PRÉPARATION DES VMs

Avant même de penser à activer ASR, il faut que ton infrastructure soit proprement préparée.

Et si tu veux éviter les mauvaises surprises en pleine bascule, cette étape n’est pas optionnelle :
➡️ VMSS Flex, zones bien réparties, disques renommés, IP statiques préservées…

Ce qu’on cherche à garantir

• Des VMs dans des VMSS Flex, pour pouvoir jouer finement sur la zone de chaque instance
• Une répartition cohérente : toutes les VMs d’un même front ou backend dans la même zone que la BDD primaire
• Des noms de disques explicites, qui embarquent l’info de la zone (ex : osdisk-az1, datadisk-az2), pour ne pas se perdre lors des bascules
• Une nomenclature claire et consistante, qui simplifiera la vie pendant les scripts ASR

Pour automatiser cette phase préparatoire, tu peux t’appuyer sur un script PowerShell partagé ici :
👉 Lien vers le script GitHub

5. INITIALISER LA RÉPLICATION AVEC ASR

Maintenant que les VMs sont prêtes et bien réparties, on passe à l’étape clé : initialiser la configuration d’Azure Site Recovery.

Mais attention :
👉 Ce n’est pas encore l’enregistrement des VMs, c’est la configuration de base de la réplication dans le Recovery Vault.
Une étape à faire une seule fois par environnement

Configuration initiale d’ASR

Cette configuration crée :

• la fabric ASR (abstraction de la région source)
• les containers de protection (source et destination)
• la policy de réplication
• et les mappings nécessaires au bon fonctionnement (aller / retour)

Exemple adapté à notre scénario (environnement PRD) :

$fabricLocation = "francecentral"
$rsv = "rsv-prod-app-01"
$rsvRg = "rg-bkp-prod-app-01"

.\ASR_init.ps1 `
  -fabricLocation $fabricLocation `
  -recoveryServiceVaultName $rsv `
  -recoveryServiceVaultResourceGroupName $rsvRg

Scripts disponibles sur GitHub

Le script complet ASR_init.ps1 est disponible ici :
👉 GitHub – Script d’initialisation ASR

6. ENREGISTRER UNE VM À PROTÉGER AVEC ASR

Après avoir préparé l’environnement et initialisé ASR, il est temps de protéger réellement vos VMs

Ajout d’une VM à ASR

$vmName = "vm-app-prod-01"
$fabricLocation = "westeurope"
$resourceGroupSourceName = "rg-app-prod"
$resourceGroupDestName = "rg-asr-prod"
$recoveryVnetName = "vnet-prod"
$recoveryVnetResourceGroupName = "rg-network-prod"
$recoveryVnetSubnetName = "subnet-app"
$vmssDestName = "vmss-asr-zone2"
$recoveryZone = "2"
$storageReplication = "stprodwesteuropeasrcache01"
$recoveryServiceVaultName = "rsv-prod-app-01"
$recoveryServiceVaultResourceGroupName = "rg-bkp-prod"
$testNetworkName = "vnet-asr-test"
$testNetworkResourceGroupName = "rg-network-prod"
$testSubnetName = "subnet-asr-test"
$testNetworkSecurityGroupName = "nsg-asr-failover-test"
$reservationGroupName = "crg-prod-az2"

.\ASR_add_vm.ps1 `
  -vmName $vmName `
  -fabricLocation $fabricLocation `
  -resourceGroupSourceName $resourceGroupSourceName `
  -resourceGroupDestName $resourceGroupDestName `
  -recoveryVnetName $recoveryVnetName `
  -recoveryVnetResourceGroupName $recoveryVnetResourceGroupName `
  -recoveryVnetSubnetName $recoveryVnetSubnetName `
  -vmssDestName $vmssDestName `
  -storageReplication $storageReplication `
  -recoveryServiceVaultName $recoveryServiceVaultName `
  -recoveryServiceVaultResourceGroupName $recoveryServiceVaultResourceGroupName `
  -testNetworkName $testNetworkName `
  -testNetworkResourceGroupName $testNetworkResourceGroupName `
  -testSubnetName $testSubnetName `
  -testNetworkSecurityGroupName $testNetworkSecurityGroupName `
  -reservationGroupName $reservationGroupName

Validation

Une fois exécuté, le message suivant doit apparaître :

Item protection declared

Ensuite, vérifiez que le job Azure ASR est bien en succès, et que la machine apparaît dans les Replicated items

En cas de lenteur ou d’erreur

Il arrive parfois que la réplication initiale reste bloquée en « Waiting for initial replication ». Dans ce cas, vous pouvez la relancer via un script complémentaire :

$vmName = "vm-app-prod-01"
$rgSource = "rg-app-prod"
$rgDest = "rg-asr-prod"
$rsvVault = "rsv-prod-app-01"
$rsvRg = "rg-bkp-prod"
$asrFabricName = "asr-prod-westeurope-fabric"
$asrProtectionContainer = "prod-1-weu-source-container"
$recoveryVnetName = "vnet-prod"
$recoveryVnetRg = "rg-network-prod"
$recoveryVnetSubnet = "subnet-app"
$testNetworkName = "vnet-asr-test"
$testNetworkRg = "rg-network-prod"
$testSubnetName = "subnet-asr-test"
$testNSG = "nsg-asr-failover-test"
$storageReplication = "stprodwesteuropeasrcache01"
$recoveryZone = "2"
$reservationGroupName = "crg-prod-az2"

.\ASR_post_add_vm.ps1 `
  -vmName $vmName `
  -resourceGroupSourceName $rgSource `
  -resourceGroupDestName $rgDest `
  -recoveryServiceVaultName $rsvVault `
  -recoveryServiceVaultResourceGroupName $rsvRg `
  -asrFabricName $asrFabricName `
  -asrProtectionContainer $asrProtectionContainer `
  -recoveryVnetName $recoveryVnetName `
  -recoveryVnetResourceGroupName $recoveryVnetRg `
  -recoveryVnetSubnetName $recoveryVnetSubnet `
  -testNetworkName $testNetworkName `
  -testNetworkResourceGroupName $testNetworkRg `
  -testSubnetName $testSubnetName `
  -testNetworkSecurityGroupName $testNSG `
  -storageReplication $storageReplication `
  -recoveryZone $recoveryZone `
  -AddToCapacityReservationGroup `
  -reservationGroupName $reservationGroupName

Scripts disponibles sur GitHub

• Le script complet ASR_add_vm.ps1 est disponible ici :
  👉 GitHub – Script add vm

• Le script complet ASR_post_add_vm.ps1 est disponible ici :
  👉 GitHub – Script Post add

6. CONFIGURER UN PLAN DE RECUPERATION

Maintenant que les machines sont protégées, il est temps de préparer leur orchestration en cas de bascule réelle ou de test. C’est là que les Recovery Plans entrent en jeu.

Un Recovery Plan dans ASR permet de :

• Grouper plusieurs machines dans un scénario de failover cohérent
• Définir des étapes personnalisées : ordres de démarrage, scripts d’automatisation, actions manuelles
• Industrialiser le processus de reprise et le rendre opérationnel en quelques clics

Création du plan via le portail Azure

1. Accédez à votre Recovery Services Vault
2. Naviguez dans Recovery Plans > + Recovery Plan
3. Nommez votre plan, par exemple rp-prd-app-mainzone1
4. Paramétrez la configuration :
   • Region : France Central
   • ✅ Cochez l’option :
     “Select this box if you would like to failover machines across zones within the same region”
   • Source Zone : 1
   • Target Zone : 2
5. Ajoutez les machines via Select items

Personnalisation et post-actions

En cliquant sur Customize, vous pouvez organiser les machines en sous-groupes, ajouter des scripts d’initialisation (pré-actions), ou des opérations de finalisation (post-actions)

👉 Dans notre cas :

• Pas de sous-groupes nécessaires pour l’instant, toutes les VMs de l’environnement sont dans le même groupe.
• Une post-action manuelle a été ajoutée pour répliquer la configuration des ASGs (Application Security Groups) sur les cartes réseau secondaires après bascule

Script utilisé : ASR_One_NIC_ASGs_Transfert.ps1
Ce script synchronise les ASG entre une carte réseau source et une carte réseau répliquée.
Il est utilisé par deux variantes :

• ASR_Online_FailoverTransfertASGs.ps1
• ASR_Offline_FailoverTransfertASG.ps1

7. SIMULER SANS TOUT CASSER ( LE TEST FAILOVER)

Réaliser un Test Failover, c’est la seule façon sérieuse de s’assurer que le plan de reprise fonctionne avant qu’une vraie panne ne survienne. Et c’est souvent l’étape la plus négligée…

🎯 Pourquoi le faire ?

• Tester la cohérence de la réplication
• Vérifier que les VMs redémarrent correctement (disques, ASG, IP…)
• Valider la connectivité dans un réseau isolé
• Et surtout : il doit être fait au moins une fois tous les 180 jours
  • 👉 C’est même une bonne pratique Microsoft officielle : lien vers la doc

Étapes à suivre

• Aller dans Azure Site Recovery, onglet Recovery Plan (ou directement depuis la VM)
• Cliquer sur « Test Failover »
• Sélectionner le Recovery Point (le plus récent, ou un point personnalisé)
• Choisir un réseau de test isolé (ex: vnet-test-failover)
• Lancer le test

Ce qu’Azure fait en coulisse

• Des machines temporaires sont créées dans la zone de destination, avec le suffixe -test
• Elles sont hébergées dans les VMSS préparés à l’avance, et connectées au VNet de test
• Chaque VM a une IP dynamique et une NIC attachée à un NSG bloquant tout trafic sortant

Cela permet d’éviter tout contact accidentel avec les vraies bases, DC, ou services en production

✅ Les VMs d’origine ne sont pas arrêtées : la production continue normalement

Où voir le statut ?

Le suivi du test en cours est disponible dans :
« Site Recovery jobs » → onglet actif

🧪 Une fois le test terminé, les VMs apparaissent avec le statut :
Cleanup test failover pending

Vérifications importantes à faire

Réappliquer les ASGs pendant le test

Il est essentiel de répliquer la configuration des Application Security Groups sur les nouvelles NIC.

Utilisez ce script pendant le test :
ASR_Online_FailoverTransfertASGs.ps1

.\ASR_Online_FailoverTransfertASGs.ps1 `
  -sid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
  -RgPrimaire "rg-source" `
  -RgSecondaire "rg-replica"

Nettoyer proprement après test

Une fois les vérifications faites :

1. Retourner dans le Recovery Plan
2. Cliquer sur « Cleanup test failover »
3. ✅ Cocher la case : « Supprimer les ressources de test » pour libérer le compute
4. 📝 Documenter ce que vous avez observé, corrigé, ou appris

8. FAILOVER

Quand la zone primaire est à terre, ou que la panne s’éternise, il faut trancher.
👉 C’est le moment de déclencher un vrai failover

Avant de basculer : ce qu’il faut valider

Un failover est toujours déclenché manuellement
Il s’agit d’un choix métier et technique, avec des critères à vérifier :

• La zone actuelle est indisponible depuis un certain temps
• Microsoft confirme la panne (→ status.azure.com)
• La DSI valide la bascule (ex : cellule de crise activée)
• Les backups (VM ou fichiers) sont suffisants pour restaurer si besoin
• On souhaite tester les procédures PRA jusqu’au bout

Déclenchement du Failover

1. Aller dans le Recovery Services Vault concerné
2. Sélectionner votre Recovery Plan (ou la VM concernée).
3. Cliquer sur Failover, puis :
   • Choisir le bon Recovery Point :
     • Low RTO → redémarrage rapide, mais risque de perte de données
     • Lowest RPO → dernières données transférées (plus lent)
     • Latest app-consistent → cohérence entre disques (important pour bases de données)
       👉 Voir doc App Consistency
4. Cocher l’option « failover across zones »
   • Source Zone → Zone 1
   • Target Zone → Zone 2

📈 L’état d’avancement est visible dans l’onglet Site Recovery Jobs

Particularités techniques à gérer après la bascule

1. Nouvelle machine créée

• La VM répliquée démarre avec le méme nom
• Les disques sont les mêmes que ceux de la VM source

2. Les ASGs ne sont pas restaurés automatiquement

Les Application Security Groups appliqués sur la NIC d’origine ne sont pas copiés sur la nouvelle NIC.

3. Utilisation du script de restauration

Nous utilisons ce script post-bascule :

.\ASR_Offline_FailoverTransfertASG.ps1 `
  -sid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
  -CustomFilePath "C:\exports-asr\rg-app-prod" `
  -RgDestination "rg-app-prod-backup"

Ce script :

• Lit les fichiers JSON exportés régulièrement (via Get_Vms_ASR_LB_Settings.ps1)
• Applique les ASG et les Backend Pools sur les nouvelles NICs

📂 Les fichiers JSON sont disponibles dans le Storage Account associé à chaque environnement

Vérifications post-bascule (checklist)

✅ Licensing : vérifier que chaque VM est bien configurée en Windows Server avec Azure Hybrid Benefits = Yes

Ce paramètre n’est pas automatiquement conservé. À ajuster manuellement via le portail Azure.

✅ Load Balancers : s’assurer que les VMs répliquées sont bien rattachées aux Backend Pools

✅ ASG & NSG : confirmés via les scripts ci-dessus

Terminer le Failover avec « Commit »

Une fois la situation stabilisée :

1. Retourner dans le Recovery Plan ou la VM
2. Cliquer sur Commit
3. Confirmer la suppression des snapshots temporaires

📌 Tant que le Commit n’est pas fait, la machine source reste disponible pour un failback.

9. REPROTECT

Une fois la bascule effectuée, les VM répliquées ne sont plus protégées. Elles sont opérationnelles, mais sans réplication active vers une autre zone.
➡️ Il est donc impératif de les reprotéger, pour retrouver une architecture PRA fonctionnelle

Étapes de finalisation après failover

Après avoir basculé vers la zone de secours, plusieurs actions sont possibles :

Pourquoi éviter le bouton « Reprotect » dans le portail

Bien que fonctionnelle, la reprotection via le portail présente plusieurs limitations importantes :

• 🔴 Ne renomme pas correctement les disques répliqués
• 🔴 Ne configure pas les paramètres avancés de réseau pour les prochains failovers
• 🔴 Ne permet pas de gérer la réservation de capacité

💡 Pour un comportement maîtrisé et reproductible, utilisez le script PowerShell ASR_reprotect.ps1

Script PowerShell pour reprotéger les VM

Voici un exemple de commande à exécuter pour chaque VM à reprotéger :

$vmName = "vm-prod-app-001"
$vmssDest = "vmss-prod-zone1"

$fabricLocation = "francecentral"
$rgSource = "rg-dr-zone2"
$rgDest = "rg-prod-zone1"
$recoveryVnetName = "vnet-prod"
$recoveryVnetRg = "rg-network-prod"
$recoveryVnetSubnet = "subnet-app"
$storageReplication = "storageasrcache"
$rsvVault = "asr-vault-global"
$rsvRg = "rg-asr"
$testNetworkName = "vnet-test-failover"
$testNetworkRg = "rg-network-test"
$testSubnetName = "subnet-test-failover"
$testNSG = "nsg-test-recovery"

.\ASR_reprotect.ps1 `
  -vmName $vmName `
  -fabricLocation $fabricLocation `
  -vmssDestName $vmssDest `
  -recoveryServiceVaultName $rsvVault `
  -recoveryServiceVaultResourceGroupName $rsvRg `
  -resourceGroupDestName $rgDest `
  -resourceGroupSourceName $rgSource `
  -storageReplication $storageReplication `
  -recoveryVnetName $recoveryVnetName `
  -recoveryVnetResourceGroupName $recoveryVnetRg `
  -recoveryVnetSubnetName $recoveryVnetSubnet `
  -testNetworkName $testNetworkName `
  -testNetworkResourceGroupName $testNetworkRg `
  -testSubnetName $testSubnetName `
  -testNetworkSecurityGroupName $testNSG

Si l’environnement est en production, pensez à ajouter :

  -capacityReservationGroupDest "crg-prod-zone1"

10. RESERVATION DE CAPACITE

Dans Azure, la Reservation de Capacité (Capacity Reservation) permet de réserver à l’avance des ressources de calcul (VM, CPU, RAM) dans une zone de disponibilité spécifique, sans encore les consommer.
💡 L’idée ? En cas de basculement, vous avez la certitude que vos VM pourront redémarrer dans la zone de secours sans risquer une saturation de capacité Azure

Une analogie simple

Imaginez un grand restaurant un samedi soir
Si vous arrivez sans réservation… vous risquez d’attendre (ou de ne jamais être servi).
Si vous avez réservé une table à l’avance, même vide, elle vous attendra.
➡️ C’est exactement le rôle d’une Capacity Reservation dans Azure.

Vous “bloquez une table” (ressources CPU/RAM dans une zone), pour pouvoir y “installer vos clients” (vos VM) en cas d’incident

Pourquoi ne pas le faire partout ?

👉 Réserver des ressources a un coût, car Azure vous garantit leur disponibilité, même si vous ne les utilisez pas immédiatement
👉 C’est pourquoi nous limitons cette stratégie aux environnements de production, où la criticité des services justifie cet investissement

Mise en œuvre dans notre architecture

Dans notre scénario :

• Le scale set de destination (zone de secours) est associé à une Capacity Reservation
• En cas de bascule, les VM sont recréées dans un environnement déjà prêt, avec capacité garantie
• Une fois la bascule faite, on libère la réservation dans la zone source (devenue inactive) pour optimiser les coûts

PROCHAIN ARTICLE

Maintenant que tu vois tout ce que permet ASR quand c’est bien pensé, on va revenir sur un point souvent négligé : le coffre

Pas juste sa création, mais sa place dans une vraie stratégie de sauvegarde à l’échelle d’une entreprise.
Dans le prochain article, on parlera des Recovery Services Vaults (RSV). Trop souvent multipliés sans logique, ils deviennent vite ingérables.

👉 On verra comment bien les organiser, comment imposer les bons tags, et comment garder une gouvernance claire sans freiner les autres équipes

📎 Pour aller plus loin (docs Microsoft) :

• Activer la réplication ASR entre zones (Azure-to-Azure)
• Effectuer un test de bascule de zone avec Azure Site Recovery (DR Drill)
• Comprendre et exécuter un Failover / Failback (expérience modernisée)
• Différences entre les points de récupération crash-consistent et app-consistent (FAQ officielle)
• Architecture de réplication Azure-to-Azure avec app-consistency
• Réservation de capacité Azure – Présentation complète
• Cmdlets PowerShell pour gérer Azure Site Recovery
• Github pour les script powershell

Younes Djebbouri

Architecte Cloud Azure & DevOps. Passionné par la sécurité, la résilience et les bonnes pratiques d'architecture.

Suivre sur LinkedIn →