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).
J'ai crée sur le bureau un dossier "test de replication" qui contient plusieurs fichiers text.
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).
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
