Search This Blog

dimanche 16 février 2014

Administration d'hyper-V replica

Bonsoir,

Dans cet article je vais vous montrer comment administrer Hyper-V replica, nous allons aborder les points suivants:


  • Vérification de l'état de réplication
  • Test de basculement 
  • Vérification de la réplication 
  • Basculement 
  • Réplication inversée 


Nous allons vérifier la réplication de ma VM CL 7, cette réplication à été crée lors de cette article "Réplication", je vais voir maintenant si tout est bien passé etc.

Ps : j’ai refait une réplication, car j’ai refait mon cluster vendredi

Pour vous remettre dans le contexte, voici le schéma d’architecture que j’ai utilisé afin de réaliser la réplication à partir d’un environnement clusterisé avec deux hyper-V (VH01 et VH02) sous Windows Server 2012 R2, vers un serveur en standalone qui est lui aussi en 2012 R2 (VH03).




On peut voir ici l’avancement de la réplication de ma VM CL7 sur le serveur VH03 externalisé :


La réplication finie ; nous allons voir l’état de la réplication avec les stats etc :

On peut voir ici plusieurs informations :
  •           Le mode de réplication
  •           Le serveur principal
  •           Le serveur qui reçoit "le réplica"
  •           L’intégrité de la réplication (voir si y’a pas de perte de données durant la réplication)
  •           Les states durant un temps données (ici 7 secondes)
  •           Les données qui restent à répliquer

Super résumé, qui peut être bien entendu enregistré afin de faire des consultations ou du dépannage si besoin.


Test du Replica "tes de basculement": 

Nous allons tester notre réplica pour vérifier qu'il est fonctionnel afin d’avoir une disponibilité en cas de crash du site central.

Hyper-V réplica propose plusieurs options lorsque vous cliquer droit sur la VM qui à été répliquée :



On retrouve les options suivantes :

  •           Basculement : cela permet de basculer le réplica en production en cas du crash du site central
  •           Test de basculement : cela permet de tester une VM dans un environnement isolé afin de tester les réplications des VMs
  •           Suspendre la réplication : comme son nom l’indique, c’est suspendre la réplication, c’est-à-dire ne plus recevoir les données qui vont correspondent aux modifications sur la VM qui se trouve dans le site central
  •           Etendre la réplication : Option qui va vous permettre de répliqué la VM vers un autre serveur réplica, donc vous aurez une double réplication et une double sécurité (exemple, réplication vers Windows Azur afin d’être sur du bon déroulement de son PRA en cas de problème)
  •           Afficher l’intégrité de la réplication : cette option permet d’afficher les states de la réplication et la quantité de données répliquées etc
  •           Supprimer la réplication : C’est pour supprimer la réplication 


Cliquez donc sur « test de basculement » et voici le résultat :

Ici, Hyper-V replica me demande de choisir un point de récupération, j’en au deux car lors du paramétrage de la réplication, j’ai choisi d’avoir deux points de récupration .


Je sélectionne le dernier , c’est-à-dire celui de 20 :55.

Je clique sur Test de basculement, et le test commence :



Vous pouvez le voir sur l’image, Hyper-V réplica prend un snapshot de la VM et la place dans un environnement de test afin qu’elle puisse être testée et explorée.

De toute manière, Hyper-V réplica travail avec les snpashots (point de contrôle sous Hyper-V ici) lorsque qu’il fait la première réplication vers le serveur secondaire.

On peut même faire un live Migration pendant que la VM est en train d’être répliquée…


On revient à notre test de réplication, une fois qu’on a déclenché le test de basculement, on aperçoit la création d’une VM « nom VM – test » comme ceci :



Essayons d’allumer la VM CL7 pour voir :

Voici l’erreur qu’on obtient : (pas d’inquiétude, c’est normal) analysons le message d’erreur :

Il nous dit qu’il peut pas démarrer la VM, car une réplication est en cours exécution, et ce qui est normal, car le déclenchement d’un PRA est vrai que si le site principal est DOWN donc les VM et serveurs primaires down également.


Ici, il spécifie bien que le démarrage de la VM sera possible qu’après un basculement (c’est-à-dire que la VM source, doit être éteinte



Démarrage de la VM de test: 

On voit que la VM de test est opérationnel et cela montre bien la bonne santé et le bon déroulement de la réplication :




Vérification :

Sur la VM source, je vais créer un dossier avec plusieurs fichiers dedans, et nous allons voir que dans 30 secondes ils seront répliqués vers la VM réplica (j’ai choisi un intervalle de 30 secondes de réplication) .

Pour cela, on va d’abord arrêter le test de basculement comme ceci :



Confirmation :



Une fois le test arrêté, nous allons refaire un test de basculement afin de vérifier que les données ont bien étaient  répliquées depuis le serveur primaire (les données ici sont des fichiers que j’ai créé pour l’occasion).

J'ai crée sur le bureau un dossier  "test de replication" qui contient plusieurs fichiers text.

Résultat :


On voit que sur le serveur réplica, les fichiers ont bien été répliqués :



Voici la source  sur le serveur primaire :



Déclenchement d’un PRA :

Nous allons arrêter le test de basculement, et arrêter la VM qui se trouve sur le serveur primaire. Et nous allons voir comment faire déclenchement de PRA suite à un crash d’un site principal.

Arrêt de la VM  sur le site central :



On va sur le serveur secondaire celui qui reçoit la réplication « VH03 » et clique droit sur la VM et on fait « Basculement » :



On choisit le dernier point de récupération : (ici, je choisi le dernier à 23h 21):


La VM démarre automatiquement toute seule :


La VM est opérationnel et reprend l’état d’origine, au pire, vous perdez que 30 secondes de données, ce qui est impressionnant !

Allons voir dans le journal des événements afin de vérifier le bon déroulement du basculement.


Voici le log qui m’indique que mon basculement s’est plutôt bien passé :



Avec le basculement, on peut même choisir les paramètres TCP/IP que la VM aura une fois qu’on a effectué le basculement.


Ça se paramètre dans les paramètres de la VM sur le serveur primaire.

Voici les paramètres TCP/IP que la VM aura automatiquement lors d’un basculement :


Par contre comme on a basculé, il n’y plus de réplication entre le serveur primaire et secondaire, voici l’événement qui nous prévient sur cette situation, il nous dit qu’il y’a eu un basculement sur le serveur de réplication  et donc cette VM n'est plus répliquée:



Inversement de la réplication :

On peut également avec Hyper-V réplica, inverser la réplication, c’est-à-dire que le serveur « VH03 » qui était secondaire au début, va se retrouver primaire et l’architecture clusterisé sera vue comme serveur secondaire.

On clique droit sur la VM,  réplication et ensuite « inverser la réplication » :


Un assistant va s’ouvrir afin de nous guider pour réalisation l’opération :



Cliquez sur suivant :

Ici, je choisi directement le CNO (Cluster Name Object) de mon cluster Hyper-V avec le rôle Replica broker.

(Ici ce broker était serveur primaire au début, et maintenant il se retrouve serveur secondaire, car je fais de la réplication inversée).

Cliquez sur suivant.



Hyper-V réplica vérifie que le serveur à assez de ressource mémoire RAM et CPU pour pouvoir absorber la VM:


Spécification du type d’authentification (ici je choisi kerberos via http) :

Cliquez sur suivant.


Choix de la fréquence de réplication (tout dépend des besoins en terme de disponibilité en cas de crash) : (ici je choisi 30 secondes dans le cadre ce lab)


Cliquez sur suivant :



Choix ici des points de récupération et de la fréquence de copie VSS :

Cliquez sur suivant.



Choix de la méthode d’envoi (réplication) : et la date et l’heur de réplication, j’ai choisi de démarrer la réplication directement à l’issu de cet assistant.






Un résumé qui vous fait un récap des options que vous avez choisi pour l’inversion de réplications :



L’Hyper-V replica mouline ….. (et met en place la replication de la VM vers le cluster)

Le réplica commence à être envoyé vers le cluster:

Ici on voit la réception du réplica par l’un des nœuds du cluster géré je rappel avec Hyper-V réplica Broker car on est dans un cluster Hyper-V :



Vérification de l’état et de l’intégrité de la réplication :

On voit que le serveur primaire est le serveur VH03, et que la VM CL7 à bien eté repliquée :


Regardons également les states et l’intégrité de la réplication:

Tout est bon.


Et voila c'est la fin :)

Avec cet article, vous allez pouvoir mettre en place une architecture redondante et qui permet la reprise d'activité en cas de problème (sinistre, tremblement de terre, incendie) sur le site principale.

Vous pouvez également inverser les réplications des VMs en cas d’erreur etc.

Bonne réplication :)

@bientôt Seyfallah Tagrerout 














< >