Mise en œuvre d’un Réplica Hyper-V v3 sur SSL en Workgroup
Cet article a pour objectif d’illustrer la mise en œuvre d’une réplication de machine virtuelle avec des serveur Hyper-V (v3 / Win2012R2). Cette opération n’est pas très compliquée dès lors que les hôtes Hyper-V appartiennent à un domaine Active Directory. En effet, dans ce cas, il suffira d’utiliser l’authentification Kerberos du domaine.
A mon avis, mais cela n’engage que moi, l’intégration des hôtes Hyper-V à un domaine, ne me parait pas une approche adaptée à toutes les situations (Multiplication des domaines, petites organisations, sous-traitance, etc.) – Ensuite, l’usage d’une infrastructure de clé publique (PKI) n’est pas encore très répandue, surtout au sein des PME de taille modeste. Pour ces différentes raisons, l’atelier proposé ici, portera sur l’usage de l’outil “makecert” afin de générer les certificats appropriés sans recourir à une infrastructure complexe.
C’est quoi un replica Hyper-V ?
Un Replica Hyper-V a pour but de suivre l’activité et l’évolution (opérations d’écriture) d’une machine virtuelle hébergée sur un hyperviseur primaire, puis reproduit ces modifications sur le serveur de réplication au travers un réseau LAN ou WAN. La connexion réseau entre les deux serveurs utilise le protocole http (authentification Kerberos) ou https (authentification basée sur des certificats pour le chiffrement). Hyper-V Replica est étroitement lié à la notion de clustering avec basculement intégrée dans Windows Server 2012, et il fournit une réplication presque sans faille à travers différents scénarios de migration dans les serveurs principaux et de réplication. Cela permet de stocker des disques durs virtuels dans des emplacements géographiquement distincts afin de permettre un plan de reprise en cas de sinistre ou d’autres raisons telles qu’une maintenance lourde, déménagement de serveurs, etc…
Dans ce cas d’étude, nous avons mettre en œuvre une réplication Hyper-V sous Windows Server 2012 R2 avec SSL (via HTTPS):
On considère que vous avez installé préalablement les 2 ordinateurs physiques avec le rôle Hyper-V. Dans cet exemple, nous avons deux hyperviseurs en “workgroup” respectivement nommés HV1 et HV2. (Note:, Le premier est une édition standard de Windows Server 2012 R2 et le second est une version Hyper-V Server 2012R2 (Core), mais ce n’est pas une obligation)
– En premier lieu, il faut ouvrir les règles appropriées du pare-feu. En l’occurrence celle liée trafic HTTPS sur les 2 machines HyperV (Ces règles sont prédéfinies)
Pour un serveur “core”, vous pouvez soit utiliser l’administration du pare-feu à distance, soit entrer les commandes suivantes dans ‘l’invite de commande du serveur :
netsh advfirewall firewall add rule name=”Ecouteur HTTPS de replica Hyper-V (TCP-In)” dir=in protocol=TCP localport=443 action=allow
Vous pouvez également vérifier / afficher les règles relatives à Hyper-V via la commande
netsh advfirewall firewall show rule name=all dir=in | find “Nom ” | find “Hyper-V”
ou bien en Powershell (v4)
PS D:\> Show-NetFirewallRule | where {$_.enabled -eq ‘true’ -AND $_.direction -eq ‘inbound’ -AND $_.displayname -like “*Hyper-V*”} | select displayname
DisplayName
———–
Clients de gestion Microsoft Hyper-V – WMI (DCOM-In)
Clients de gestion Microsoft Hyper-V – WMI (TCP-In)
Clients de gestion Microsoft Hyper-V – WMI (Async-In)
Hyper-V – WMI (DCOM entrant)
Hyper-V – WMI (TCP entrant)
Hyper-V – WMI (Async entrant)
Hyper-V (RPC-EPMAP)
Hyper-V (RPC)
Hyper-V (MIG-TCP entrant)
Hyper-V (REMOTE_DESKTOP_TCP_IN)
Écouteur HTTP de réplica Hyper-V (Tcp-In)
Écouteur HTTPS de réplica Hyper-V (TCP-In)
Dans cet environnement autonome, il est souhaitable d’ajouter également un suffixe DNS pour chacun de ces hyperviseurs. Pour cela, vous pouvez passer par les “propriétés système avancés” de l’ordinateur, onglet “Nom de l’ordinateur”, bouton “Modifier”, puis bouton “Autres…”
Pour le serveur core, vous pouvez soit utiliser l’administration du pare-feu à distance, soit entrer les commandes suivantes dans ‘l’invite de commande du serveur :
D:\>netdom COMPUTERNAME HV2 /Add:HV2.domain.local
HV2.domain.local a été ajouté
en tant que nom secondaire de l’ordinateur.
L’opération s’est bien déroulée.
D:\>netdom COMPUTERNAME HV2 /MakePrimary:HV2.domain.local
HV2.domain.local a été transformé
en nom principal de l’ordinateur. Vous devez redémarrer l’ordinateur pour que
cette modification de nom prenne effet. Si vous ne le faites pas, l’ordinateur
risque de ne pas pouvoir authentifier les utilisateurs et les autres
ordinateurs, ni être authentifié par les autres ordinateurs de la forêt. Le
nouveau nom spécifié a été supprimé de la liste des noms secondaires de
l’ordinateur. Le nom principal de l’ordinateur sera défini sur le nouveau nom
spécifié après le redémarrage.
L’opération s’est bien déroulée.
Ces entrées (avec les adresse IP correspondantes) devront être renseignées auprès de votre serveur DNS interne (ou dans les fichiers HOSTS de chaque machine si vous ne disposez d’aucune infrastructure DNS )
Dans notreenvironnement de test, nous utilisons descertificats générés parl’outil“Makecert”. Cet outil est disponibledans le cadre du “SDKWindows”,que vous pouvez téléchargerà partir de http://go.microsoft.com/fwlink/?linkid=84091
Copiez l’utilitaire“makecert.exe” vers le serveur principalHV1 etle serveur de réplicationHV2
–SurHV1 nous allons créer une autoritédecertification racineauto-signéepour ce testen exécutant lacommande suivante à partird’une invite decommande élevée:
C:\Temp>makecert -pe -n “CN=PrimaryTestRootCA” -ss root -sr LocalMachine -sky signature -r “PrimaryTestRootCA.cer”
Succeeded
Créez ensuite un nouveaucertificat signé par leprécédent représentant l’autoritédecertification racine,en exécutantla commande suivanteà partir d’uneinvite de commande élevée. (Vous devez fournir lenom de domaine complet FQDN du serveur principal):
C:\Temp>makecert -pe -n “CN=HV1.domain.local” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “PrimaryTestRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 TestCertHV1.cer
Succeeded
Normalement, deux certificatsont été créés dans le dossier où“makecert” a été exécuté.
Copiez le certificat de cette autoritédecertification racine “PrimaryTestRootCA” vers un dossier du serveur HV2.
– Réitérez ces opérations sur le serveur HV2 (Vous devez créer une nouvelle autoritédecertification racine pour cette opération) – Exécutez les commandes suivantes à partird’une invite decommande élevée:
C:\Temp>makecert -pe -n “CN=ReplicaTestRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaTestRootCA.cer”
Succeeded
C:\Temp>makecert -pe -n “CN=HV2.domain.local” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “ReplicaTestRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 TestCertHV2.cer
Succeeded
Echange / importation des autorités racines de confiance entre les 2 serveurs:
Importez le certificat de l’autoritédecertification racine du serveur principal HV1 “PrimaryTestRootCA” dans le magasin des racines de confiance de ce serveur à partird’une invite decommande élevée:
D:\Temp>certutil -addstore -f Root PrimaryTestRootCA.cer
Root “Autorités de certification racines de confiance”
La signature correspond à la clé publique
Le certificat “PrimaryTestRootCA” a été ajouté au magasin.
CertUtil: -addstore La commande s’est terminée correctement.
Copiez le certificat de l’autoritédecertification racine “ReplicaTestRootCA” de ce réplica vers un dossier du serveur HV1 puis l’importer vers le magasin des racines de confiance via la commande suivante:
C:\Temp>certutil -addstore -f Root ReplicaTestRootCA.cer
Root “Autorités de certification racines de confiance”
La signature correspond à la clé publique
Le certificat “ReplicaTestRootCA” a été ajouté au magasin.
CertUtil: -addstore La commande s’est terminée correctement.
Par défaut, un contrôle de révocation de certificats est nécessaire; Toutefois, ces certificats générés pour les tests ne prennent pas en charge les contrôles de révocation. Vous devez donc désactiver ce contrôle en modifiant le Registre sur chacun des serveurs avec la commande suivante:
C:\> reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
L’opération a réussi.
Activation la réplication sur le serveur principal
Ouvrez la console “Gestionnaire Hyper-V” du serveur principal “HV1” puis choisissez l’option générale “Paramètres Hyper-V”. Sélectionnez la rubrique “Configuration de la réplication”. Cochez la case “Activer ce ordinateur en tant que serveur de réplication” ainsi que la case “Utiliser l’authentification basée sur les certificats (HTTPS)”.
Cliquez sur le bouton “Sélectionner le certificat“ puis sur “OK”
Note : Seuls les certificats éligibles sont proposés. Si aucun certificat n’est affiché, vérifiez que les opérations précédentes ce sont bien déroulées. Consultez les magasins de certificats via “MMC … Certificats … Ordinateur”, magasin “personnel” ainsi que le magasin des “Autorités de certification racines de confiance”
Sélectionnez ensuite l’option “Autoriser la réplication à partir des serveurs spécifiés” puis sur le bouton “Ajouter”
Indiquez le nom du second serveur “HV2.domain.local”, vérifiez l’emplacement du dossier de stockage des machines virtuelles pour ce serveur, et indiquez un nom pour le groupe de confiance. (Cette notion de “Trust Group” est un simple “marquage” qui peut être utilisé, par exemple, par les sociétés qui mutualisent l’hébergement de plusieurs clients, afin de distinguer plus facilement et éviter des confusions entre les réplications de machines virtuelles appartenant à des clients différents) –
Une fois ces champs renseignés, cliquez sur “OK”
Cliquez sur le bouton “Appliquez” pour achever cette configuration sur le premier serveur.
Un message d’avertissement vous rappellera l’importance du pare-feu.
Réitérez ces opérations sur le second serveur (en remplaçant les valeurs par HV1)
L’activation de la réplication Hyper-V sur un serveur “Core” est délicate (possible ?) en ligne de commande. Il est donc préférable d’effectuer ces opérations via une connexion à distance du “Gestionnaire Hyper-V”.
Pour tester la réplication, sélectionnez une machine virtuelle sur le serveur principal puis utilisez le menu contextuel “Activer la réplication”
Un assistant s’ouvre
Cliquez sur “Suivant”
Entrez le nom du serveur de réplication. (“HV2.domain.local” dans cet exemple)
Cliquez sur “Suivant”
Utilisez le bouton “Sélectionner le certificat…” afin de choisir le certificat du serveur principal
Si le message d’avertissement suivant apparait, vérifier que la résolution du nom est correcte. Au besoin renseignez le DNS ou les fichiers “hosts” de chaque serveur avec les adresses IP adéquates.
Cliquez sur “Suivant”
Dans le cas où la machine virtuelle utiliserait plusieurs disques durs, cet écran permet d’exclure des disques durs virtuels qui ne seront PAS répliqués vers le serveur de réplication. Comme l’indique le message, les disques éventuellement exclus induisent un risque de perte de fiabilité sur la machine virtuelle répliquée.
Cliquez sur “Suivant”
Choisissez un intervalle de réplication automatique (30 secondes, 5 minutes ou 30 minutes) puis cliquez sur “Suivant”
Vous avez la possibilité de configurer des points de récupération automatiques, ou conserver uniquement le dernier (par défaut). Cliquez sur “Suivant”
L’écran suivant permet de définir la méthode de réplication initiale. Par défaut, la copie sera effectuée via le réseau. Ce choix n’est pas acceptable dès lors qu’une liaison WAN est utilisée entre les serveurs. Dans ce cas, vous pourrez opter pour 2 solutions :
· Exporter la machine virtuelle vers un support externe (vous importerez ensuite cette configuration sur le serveur de destination)
· Choisir une machine virtuelle existante sur le serveur de destination (idéalement une restauration de cette VM ou similaire)
La réplication initiale peut être démarrée immédiatement à l’issue de cet assistant ou planifier à l’heure de votre choix. Cliquez sur “Suivant”
Le dernier écran vous affiche un résumé des paramètres retenus.
Cliquez sur “Terminer”
Un message vous informe du succès de l’opération.
Dans cet exemple, la réplication initiale commence immédiatement (via le port HTTP 443 en utilisant les certificats) – Si la machine virtuelle ne dispose pas d’au moins une capture instantanée (Dorénavant appelés “Points de contrôle”), la réplication en génère automatiquement un.
Une fois la réplication initiale achevée, cette machine virtuelle répliquée dispose de plusieurs possibilités (via le menu contextuel)
· Basculement planifié : La bascule s’effectuera après un arrêt propre de cette machine virtuelle puis mise à jour de la réplique. Par défaut, la machine virtuelle répliquée sera automatiquement démarrée après le basculement)
· Suspendre la réplication : Met la réplication en pause
· Afficher l’intégrité de la réplication… : Permet de contrôler l’état de la réplication
· Supprimer la réplication : Permet d’abandonner la réplication de cette machine virtuelle
De la même manière, coté serveur de réplication, la machine virtuelle (désactivée) dispose de plusieurs possibilités (via le menu contextuel)
· Basculement … : En cas d’urgence, la restauration se fait à partir des répliques présentes sur ce serveur)
· Test de basculement : Permet de s’assurer que la bascule est opérationnelle. Un point de contrôle et un nouvelle machine virtuelle (suffixée par “- Test”) sont automatiquement générés.
· Suspendre la réplication : Met la réplication en pause
· Etendre la réplication… : Cette nouveauté W2012R2 permet d’étendre une réplication existante vers d’autres serveurs (typiquement vers un site de secours). Un assistant vous proposera une configuration similaire à cet atelier.
· Afficher l’intégrité de la réplication… : Permet de contrôler l’état de la réplication
· Supprimer la réplication : Permet d’abandonner la réplication de cette machine virtuelle
Note : Le serveur de réplication dispose d’un dossier spécifique “Hyper-V Replica” situé sous l’emplacement de stockage indiqué lors de la configuration de la réplication.
Exemple de rapport d’intégrité d’une réplication:
En espérant que ce petit article éclaire un tant soit peu votre lanterne de technicien égaré
Bien à vous,
Christophe
Bonjour,
Un grand merci pour cet article, il correspond exactement à ce que je cherchais.
Kali’
Bonjour,
Je sais que l’article date un peu, beaucoup, […] ok ! très longtemps.
Cet article correspond entièrement à mes recherches.
J’ai tout de même une question concernant le scénario suivant:
si HV1 tombe en panne alors sur on bascule manuellement sur HV2
On répare HV1 et redeviens disponible.
Comment fait-on pour rebasculer sur HV1 toutes modifications apportées sur la VM de HV2.
certes on fais la manipulations inverse, mais du coup HV1 deviens secondaire et n’est plus principale. Hors HV2 est un serveur de secoure donc on ne peut pas se permettre que HV2 devienne principale.
si vous avez une idée, je remercie par avance
Victor.
Bonjour Victor,
Je n’ai plus cette maquette sous la main pour vérifier, mais il me semble qu’après un basculement vers un replica, il est normalement possible de faire une “réplication inverse” (menu contextuel des VM répliquées) vers le HV1 primaire restauré (sous réserve de reconfiguration, VM arretées et firewall acceptant les connexions entrantes) – et parfois le points de controle posent aussi des soucis 🙁
Voir un petit résumé (en anglais) ici http://www.virtualizationadmin.com/kbase/VirtualizationTips/ServerVirtualization/MicrosoftHyper-VTips/General/what-hyper-v-reverse-replication.html
ou des explications plus officielles sur https://technet.microsoft.com/fr-fr/library/dn641212(v=ws.11).aspx
Bonne continuation
Bonjour, merci pour ce super article. Comme Victor : réplication bidirectionnelle. Comment mets-on en oeuvre ? vos liens de juillet 2017 sont déjà morts ou ne donnent rien de précis. Un complément pas a pas serait apprécié !
Bonjour,
Désolé pour la réponse tardive mais le sujet (article) est pour le moins “poussiéreux” et je n’ai pas franchement retravaillé ce sujet récemment.
Pour des détails pas à pas, je conseille les articles et bouquins de David Lachari (http://danstoncloud.com/becloud/) mais ils datent aussi :-(…
Bonne continuation