Replica Hyper-V v3 sur SSL en Workgroup

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…

image

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)

clip_image003 

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) Rire

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…”

clip_image005

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 Triste)

Dans notreenvironnement de test, nous utilisons descertificats générés parl’outilMakecert”.  Cet outil est disponibledans le cadre duSDKWindows”,que vous pouvez téléchargerà partir de http://go.microsoft.com/fwlink/?linkid=84091

Copiez l’utilitairemakecert.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é.

clip_image006

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)”.

clip_image008

 

Cliquez sur le bouton “Sélectionner le certificat puis sur “OK”

clip_image010

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”

clip_image012


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) –

clip_image014

Une fois ces champs renseignés, cliquez sur “OK”

 

clip_image016

Cliquez sur le bouton “Appliquez” pour achever cette configuration sur le premier serveur.


Un message d’avertissement vous rappellera l’importance du pare-feu.
clip_image017

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

clip_image019

Un assistant s’ouvre
clip_image021
Cliquez sur “Suivant”

Entrez le nom du serveur de réplication. (“HV2.domain.local” dans cet exemple)
clip_image023
Cliquez sur “Suivant”

Utilisez le bouton “Sélectionner le certificat…” afin de choisir le certificat du serveur principal
clip_image025

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.

clip_image026

Cliquez sur “Suivant”

clip_image028

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”

clip_image030

Choisissez un intervalle de réplication automatique (30 secondes, 5 minutes ou 30 minutes) puis cliquez sur “Suivant”

 

clip_image032

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)

clip_image034

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.
clip_image036

Cliquez sur “Terminer”

Un message vous informe du succès de l’opération.

clip_image038

 

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.

 

clip_image040 

 

Une fois la réplication initiale achevée, cette machine virtuelle répliquée dispose de plusieurs possibilités (via le menu contextuel)

clip_image042

 

·         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)

clip_image044

 

·         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:

clip_image046 

En espérant que ce petit article éclaire un tant soit peu votre lanterne de technicien égaré Sourire

Bien à vous,

Christophe

 

5 Commentaires

  1. Kali

    Bonjour,

    Un grand merci pour cet article, il correspond exactement à ce que je cherchais.

    Kali’

    Répondre
  2. victor

    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.

    Répondre
    1. WebMaster

      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

      Répondre
  3. toto974

    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é !

    Répondre
    1. CxMan (Auteur de l'article)

      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

      Répondre

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.