[Azure] Azure Site Recovery avec ARM - Partie 2

Voici donc la deuxième partie de l’implémentation de Azure Site Recovery avec ARM:

• 1er article: Mise en place de la solution Azure Site Recovery
• 2ème article: Replication des VMs et Failover/Failback

Réplication des premières VMs

Maintenant que l’infrastructure est prête sur Azure, nous allons pouvoir répliquer les VMs/Applications. Choisissez de où vous souhaitez répliquer les VMs (On-Premises pour moi) et sélectionnez le site Hyper-V que vous avez créé dans le premier article :

Sélectionnez le compte de stockage que vous avez créé au début pour stocker les réplications, mais aussi le réseau que vous avez créé et le sous-réseau associé :

Sélectionnez enfin les VMs que vous souhaitez protéger avec la réplication :

Choisissez le type d’OS ainsi que le disque OS. Choisissez enfin les disques que vous souhaitez répliquer :

Appliquez la police créée précédemment :

La réplication commence :

Depuis la console Hyper-V, vous pouvez voir que la réplication a commencé :

Modification de la VM avant Failover

Avant de tester le failover, il faut choisir la taille de la VM qui sera déployée et aussi, paramétrer le réseau. En effet, vous pouvez décider de faire tourner la VM sur une taille plus petite en mode dégradé. Et ici, étant donné que mon application a été mal codé et que j’ai une IP fixe dans le code, je vais réattribuer la même IP que dans mon réseau local actuel à cette VM. Si vous ne précisez rien, le DHCP prendra la première IP disponible dans le pool :

Test du Failover

Il est maintenant temps de tester le failover. J’ai éteint mon infrastructure, et donc, plus personne ne peut travailler. Dans la console Azure, sur votre réplication de votre application, cliquez sur Unplanned Failover pour dire que votre application doit être déployé sur Azure.

Choisissez le point de sauvegarde que vous souhaitez restaurer. Je n’ai pas synchronisé les derniers changements car mon infrastructure n’est plus disponible, et j’aurai donc perdu dans mon cas, maximum 15 minutes de données (délai de réplication des VMs vers Azure) :

Le déploiement de ma VM sur Azure est en cours :

10 minutes plus tard, ma VM a été déployé dans Azure :

VNet Peering

J’ai créé un VNet Peering entre le réseau qui contient mon DC et mon réseau ASR. Vous pouvez retrouver la procédure pour faire ceci ici. Vous pouvez également automatiser cette partie.

Test de mon application

En me connectant sur mon DC sur Azure, je peux voir que je ping directement la nouvelle machine ASR (grâce au network peering) et que je peux accéder au site web :

Et en rajoutant un NLB et en créant une règle NAT, sur le port de l’application, vers la VM qui vient d’être déployé, mes utilisateurs peuvent continuer à travailler, juste en faisant pointer votre DNS, vers la nouvelle IP public du NLB :

Maintenant que votre application est fonctionnelle, il faut faire un Commit du failover :

Failback

Votre datacenter est de nouveau opérationnel, il faut donc rapatrier les données avec les changements qu’il y a eu. Pour faire ceci, cliquez sur Planned Failover :

Vous souhaitez faire le failover de Azure vers votre Datacenter. Si vous avez perdu vos données, vous pouvez décider de créer une nouvelle VM dans votre datacenter, sur un hôte bien précis :

Une fois que le failback est terminé, vous devriez avoir ceci :

Cliquez sur Commit pour valider le changement vers votre datacenter :

Le dernier delta est envoyé :

Enfin, le failback est terminé :

Pour terminer, il faut réactiver la réplication de la VM vers Azure. Cliquez sur Reverse replicate :

Si je refais le test, depuis ma VM qui est sur Azure, vers la même IP qui est dans mon datacenter, vous pouvez voir que maintenant, je passe de nouveau par mon VPN S2S et que le site Web n’a pas changé :

Pour aller plus loin

Si vous souhaitez aller plus loin, ici nous avons fait le failover pour une seule VM. Vous pouvez créer un groupe de VM, dans la partie Recovery Plan pour faire un failover sur plusieurs VM d’un seul coup :

Vous pouvez également gérer directement les paramètres de l’infrastructure ASR dans la console Azure, sans passer par le Step-By-Step :)

Conclusion

Cette fonctionnalité est très intéressante pour les sociétés qui ont des applications business critiques pour faire tourner l’entreprise. Même en mode dégradé, les employés peuvent continuer à travailler et donc, faire perdre un minimum d’argent à la société. Ne vous en passez donc pas :)