Azure Site Recovery avec Hyper-V 3/3

Dernière étape de notre découverte d’Azure Site Recovery avec Hyper-V. A ce stade, nous avons une synchronisation de notre machine virtuelle. Plus précisément, c’est Hyper-V réplica qui se charge de maintenir une copie cohérente de notre machine virtuelle. Notre dernière étape, c’est de configurer la politique de Failover.

clip_image001

On peut disposer d’autant de Recovery Plan qu’on veut mais une machine virtuelle ne peut être liée qu’à un seul Recovery Plan. Dans mon cas, il ne concerne qu’une seule machine virtuelle.

clip_image002

Notre premier Recovery Plan est créé. Dans l’illustration ci-dessous, on constate qu’il n’a jamais été testé. C’est la faiblesse de tous nos plans de DRP. Ce qui est bien avec Azure Site Recovery, c’est qu’on peut le tester à blanc.

clip_image003

Dans le portail, lorsqu’on se positionne sur un Recovery Plan, on peut utiliser l’option « Test Failover ». L’objectif est de valider qu’Azure Site Recovery sera bien en mesure de reconstruire une machine virtuelle consistante sur un réseau Azure isolé. Nous pouvons donc le tester tant qu’on veut.

clip_image004

Attention tout de même, tous les scénarios d’implémentation ne proposent pas le même niveau de fonctionnalité. La page Technet Failover in Site Recovery documente clairement quels scénarios autorisent quels types de failover. Dans mon contexte (Hyper-V), le test Failover est bien possible. Pour le réaliser, il n’a besoin que d’une seule information : un VNET sur lequel associer la future interface réseau. Bien entendu, celui que j’ai sélectionné ne dispose ni d’Azure Gateway ou Peering. Il est donc totalement isolé.

clip_image005

Après, c’est un job en cours d’exécution. On n’a qu’à le suivre.

clip_image006

On note la notion de groupe, lorsqu’on a plusieurs VM dans une politique de failover, on peut décider l’ordre de remise en ligne. Logiquement dans ce groupe, mon contrôleur de domaine est le premier. Si j’avais d’autres machines virtuelles, je pourrais séquencer le redémarrage.

clip_image007

Avec un peu de patience, on arrive au résultat suivant :

clip_image008

Ce qu’il est intéressant de noter, c’est qu’entre l’initialisation de l’action et le démarrage de la machine virtuelle, il ne s’est écoulé trois minutes. Le temps de bascule a donc été très court. On considère que le test est concluant quand la machine virtuelle a bien réussi à démarrer. Nous avons été capable d’utiliser le dernier état consistant stocké dans Azure Site Recovery. On va clore le test.

clip_image009

 

Et indique quelques informations sur notre test avant de demander de faire le ménage.

clip_image010

Du point de vue du job, l’opération est totalement terminée.

clip_image011

Voilà pour le test. Mais tester à blanc, ça ne vaut pas grand-chose. Ce dont on a besoin c’est de valider qu’on est bien capable de reprendre le service dans Azure et de revenir On-Premises sans encombre. Pour cela, nous allons organiser un test de failover planifié. Cela signifie que sur notre hôte Hyper-V la machine virtuelle sera inactive. On va donc procéder cette fois à un « Planned Failover ».

clip_image012

Par rapport au Test Failover, cela se présente exactement de la même manière. La seule différence, c’est qu’on n’a pas à indiquer le VNET à utiliser, c’est une information qui a déjà été communiquée lors de la mise en place de la politique de réplication.

clip_image013

Par contre dans le Job, on voit bien une différence. Il commence par arrêter notre machine virtuelle et réaliser une dernière synchronisation delta vers Azure.

clip_image014

Entre l’initialisation de la bascule et la mise en ligne de la machine virtuelle, il ne s’est écoulé que cinq minutes. Pour un service de reprise sur incident As a service, c’est plutôt pas mal.

clip_image015

Logiquement, je devrais avoir une machine virtuelle dans la souscription. C’est effectivement le cas, elle a été provisionnée dans le groupe de ressources du même nom que la machine virtuelle basculée. C’est un des aspects qu’on ne maîtrise pas (au moment de la rédaction de ce billet).

clip_image016

Au passage sur mon hôte Hyper-V, ma machine virtuelle est bien arrêtée. Ce qui est intéressant, c’est que le groupe de ressource ne contient que les ressources machines virtuelles et interface réseau. C’est logique, le VHD a été restaurés dans le Storage Account asrstoragerestore01, celui que j’ai indiqué lors de la configuration d’Azure Site Recovery.

clip_image017

Note à ce niveau, ma machine virtuelle n’a qu’un seul disque OS, pas de disque de données. On-Premises, ce n’est pas un problème. Par contre dans Azure, ce n’est pas une bonne pratique. Avant de répliquer des machines virtuelles vers Azure, Quelques bonnes pratiques à respecter

  • Laisser le disque D:\ libre, on va en avoir besoin dans Azure
  • Utiliser obligatoirement des volumes de données VHD distincts pour héberger les données de vos applications

Techniquement, ma machine virtuelle est opérationnelle dans Azure. Mon planned Failover s’est déroulé sans problème, on va rebasculer On-Premises mais avant cela un bonus. Si on creuse un peu dans les menus, on va trouver une option qui va nous intéresser au plus haut point :

clip_image018

L’idée c’est qu’une fois la machine virtuelle répliquée vers Azure, on finalise complètement sa migration. La machine virtuelle n’est plus gérée par Azure Site Recovery. On peut donc utiliser Azure Site Recovery comme outil de migration. Ce sera le sujet d’un autre billet. Pour l’instant, nous allons valider la bascule avec un Commit. Cela signifie que l’on perd le contenu de nos Recovery Points. C’est logique. Par contre, cela signifie aussi qu’il faudra reconstruire le Recovery Point et repartir sur une réplication initiale. Donc à moins d’avoir de la bande passante à revendre, on ne va pas s’amuser à basculer les machines virtuelles entre On-Premises et Azure tous les matins.

clip_image019

Ici encore, l’opération de Commit est un job que l’on peut suivre.

clip_image020

A ce stade, on va repartir On-Premises en déclenchant de nouveau un « Planned Failover ». On notera que le Commit est maintenant grisé.

clip_image021

Le processus de failback ressemble beaucoup au process de failover à une exception.

clip_image022

 

On a le choix du scénario pour réaliser la bascule :

  • Minimiser le downtime
  • Réaliser un download full

Ce qui est intéressant c’est la case à cocher qui permet de recréer les machines virtuelles. On l’utilisera si on a perdu notre serveur Hyper-V. Juste un détail, dans ce sens de réplication, c’est du trafic descendant d’Azure, donc facturé. Le choix du full download n’est donc pas sans conséquences. Ça veut dire aussi qu’on peut utiliser ASR pour migrer d’un Datacenter à un autre, … Après, on connait, c’est un job comme un autre :

clip_image023

On-Premises, on peut suivre le processus dans notre console Hyper-V :

clip_image024

C’est presque fini.

clip_image025

Y a plus qu’à valider la migration. Cette opération de validation est nécessaire pour indiquer à l’agent Azure Site Recovery qu’il peut inverser le sens de réplication pour maintenant resynchroniser vers Azure.

clip_image026

 

En regardant plus précisément les détails du job de failback, on constate que le temps total d’opération a été de 48 minutes.

clip_image027

Cependant, le downtime du service est lui de 20 minutes. Dans la console Azure Site Recovery, on peut constater que le status du replicated Item est revenu à « On-premises ».

clip_image028

 

Sur notre serveur Hyper-V, on peut constater que le processus de synchronisation est de nouveau reparti vers Azure.

clip_image029

 

A noter qu’on recommence le processus de réplication depuis le début. C’est donc une réplication complète qui débute.

Voilà pour cette découverte d’Azure Site Recovery.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.