Azure Site Recovery avec Hyper-V 1/3

Azure Site Recovery est un composant intéressant de la plateforme Azure. Je le classe dans la catégorie des composants qui apportent un bénéfice immédiat à notre Datacenter. Pour les autres composants / scénarios d’usage, il faut un peu plus de travail pour pouvoir en bénéficier. Pour certains, l’adoption passera même par une phase de transformation, ce qui nécessite du temps. Azure Azure Site Recovery (ASR pour les intimes), on répond à une problématique immédiate, à savoir comment j’organise mon Plan de Reprise d’Activité.

Le sujet du PRA est vaste. Si on se limite aux problématique techniques, cela consiste à mettre à disposition des ressources (locaux, serveurs, réseau) qui ne seront utilisées qu’en cas de défaillance, autant dire le moins souvent possible. Différentes technologies liées à la virtualisation et au stockage forment la réponse technique. Le problème, c’est le coût de ce ticket d’entrée. Si on raisonne « On-Premises », cela implique de doubler ses infrastructures à commencer par son hébergement. Ce sont donc des mètres carrés à louer à prix d’or à un hébergeur.

ASR permet d’utiliser la plateforme Azure pour réaliser ce PRA avec pour avantage de ne provisionner la machine virtuelle que lorsque l’on déclenchera les opérations de reprise d’activité. D’un point de vue financier, c’est intéressant car on ne paie pas pour le compute des machines virtuelles répliquées car à ce stade, elle n’existent pas. Au moment de l’écriture de ce billet, il existe plusieurs scénarios pour ASR :

  • Répliquer des machines physiques Windows/Linux vers Azure
  • Répliquer des machines physiques Windows/Linux vers un site de repli
  • Répliquer des machines virtuelles VMWARE vers Azure
  • Répliquer des machines virtuelles VMWARE vers un site de repli VMWARE
  • Répliquer des machines virtuelles Hyper-V vers Azure
  • Répliquer des machines virtuelles Hyper-V vers un site repli Hyper-V
  • Répliquer des machines virtuelles Hyper-V gérées par SCVMM vers Azure
  • Répliquer des machines virtuelles Hyper-V gérées par SCVMM vers un site de repli avec SCVMM et Hyper-V
  • Répliquer des machines virtuelles Hyper-V & le stockage SAN vers un site de repli avec SCVMM et Hyper-V

Pour ce billet, on va se contenter du plus simple, à savoir répliquer une machine virtuelle Hyper-V. Derrière c’est la technologie Hyper-V Replica qui est à l’œuvre. L’objectif est d’avoir des snapshots consistants réalisés par l’hôte Hyper-V et une ou plusieurs versions consistantes de nos machines virtuelles prête à démarrer dans Azure en cas de défaillance de la machine virtuelle Hyper-V ou pire de l’hôte Hyper-V voilà pour l’introduction. Avant de rentrer dans la mise en œuvre, on va commander par les prérequis :

  • Une souscription Azure (en même temps, c’est logique)
  • Un groupe de ressources pour regrouper nos ressources
  • Un storage Account que nous allons dédier à Azure Site Recovery
  • Un Virtual Network & Subnets pour préparer l’hébergement de nos futures machines virtuelles
  • Un compte de stockage pour héberger nos futures machines virtuelles.

A noter que l’approche avec VMWARE ou les serveurs physique est quelque peu différente puisque cela ne repose pas sur Hyper-V-Replica mais sur la technologie InMage de la société Scout qui a été rachetée par Microsoft : InMage is now part of Microsoft

Ce premier billet de la série va se focaliser sur la mise en place des prérequis. Suivront deux autres billets :

Le service de DRP devant assurer un service de bout en bout, il est logique de regrouper tous ces éléments au sein d’un groupe de ressources. En plus, toutes ces ressources ont une caractéristique, elles ne sont pas liées à un projet en particulier mais mises à disposition pour un scénario donné. En regroupant ces ressources on a donc un coût pour toutes ces ressources que l’on va pouvoir ventiler en fonction des usages. Ce sera de la refacturation d’un service IT. J’ai donc créé un groupe de ressources auquel j’ai associé un Tag.

clip_image001

Lors de la création des services, le choix de la région Azure n’est pas anodin. Les futures machines virtuelles seront nécessairement dans la même région que l’instance du service ASR. J’ai donc retenu de créer mon Recovery Vault Service dans la région West Europe. Au passage, même si Azure Backup est maintenant intégré à Azure Site Recovery (depuis mai/juin 2016), je recommande de ne pas mutualiser les deux usages au sein d’une même instance du service. Les deux usages vont consommer du stockage, certainement beaucoup plus pour le backup que pour le DRP. En plus, une instance du service ne permet de sauvegarder que 50 machines virtuelles (avec l’agent Windows Server backup) ou 200 machines virtuelles IaaS Azure. Sachant qu’au sein d’une souscription on est limité qu’à 25 Recovery vault, on devrait pouvoir y arriver.

clip_image002

Mon instance du service Azure Site Recovery est rapidement provisionnée. Il reste encore un peu de configuration avant que le service soit totalement opérationnel.

clip_image003

Le service Azure Site Recovery est utilisable pour deux usages

  • Le DRP
  • La sauvegarde

Dans le cas présent, c’est le premier qui nous intéresse, nous allons donc suivre l’assistant « Site Recovery ».

clip_image004

Première question, le scénario. Dans notre cas, nous désirons :

  • Répliquer nos machines virtuelles vers Azure
  • Depuis un ou plusieurs hôtes Hyper-V (Windows Server 2012 R2 minimum)
  • Sans avoir besoin d’un SCVMM

clip_image005

Du point de vue Azure Site Recovery, nous allons déclarer nos serveurs Hyper-V (en installant un agent dessus), ces hôtes Hyper-V seront regroupés dans un Hyper-V Site que nous allons créer maintenant. La notion de site est importante car pour la mise en place de la protection des machines virtuelles, la politique s’appliquera à un site Hyper-V.

clip_image006

Notre site Hyper-V sera nommé « On-Premises ».

clip_image007

Nous retrouverons la notion de site Hyper-V ultérieurement lorsqu’on abordera la notion de politique de réplication. La même politique sera appliquée à tous les serveurs Hyper-V du site. Prochaine étape, associer notre serveur Hyper-V à ce site « On-Premises » :

clip_image008

L’association de notre serveur au site sera faite avec le fichier de « Vault Registration » mis à disposition en même temps que le binaire de l’installation de l’agent. Chaque serveur Hyper-V qui sera associé au site devra être enregistré individuellement avec son fichier de configuration propre.

clip_image009

Nous pouvons maintenant passer à l’installation de l’agent sur le serveur Hyper-V. Un point important, c’est que cet agent ne s’installe que sur socle Windows Server 2012 R2. Au moment de l’écriture de ce billet, l’agent n’était pas encore compatible avec Windows Server 2016. L’agent téléchargé est le Azure Site Recovery Provider. Il s’installe sur un serveur Windows Server 2012 R2 avec le rôle Hyper-V. Trois points intéressants à noter :

  • Possible de déployer cet agent sur une installation Core de Windows Server 2012 R2 (Top).
  • Pas de redémarrage nécessaire (donc mise en production en pleine journée)
  • Pas d’autre prérequis nécessaire

C’est un composant Microsoft, donc avec une stratégie de mise à jour Microsoft Update. Microsoft actualise le binaire régulièrement pour corriger des problèmes pour intégrer de nouvelles fonctionnalités. On va donc conserver la fonctionnalité activée.

clip_image010

C’est un processus d’installation comme un autre, avec un chemin d’installation proposé par défaut.

clip_image011

C’est maintenant que cela devient intéressant. C’est maintenant qu’on va enregistrer notre hôte Hyper-V auprès de notre Azure Site Recovery Vault.

clip_image012

Le processus d’inscription a besoin de trois informations :

  • La souscription Azure concernée
  • Le nom du Recovery Vault
  • Le site auquel notre serveur Hyper-V sera associé dans le Recovery Vault

Toutes ces informations sont contenues dans le fichier Vault Registration Key. A noter que ces informations seront enregistrées dans le registre du système d’exploitation. Si le serveur Hyper-V doit être associé à un autre Recovery Vault, il faudra supprimer ces informations du registre.

clip_image013

Un point intéressant. Le processus de réplication (reposant sur Hyper-V Replica dans notre scénario) va communiquer sur le port TCP 443 avec possibilité d’utiliser un Proxy avec authentification. Autre point, la communication est initiée par le serveur Hyper-V pas par Azure.

clip_image014

L’installation est maintenant terminée. Il faudra patienter quelques minutes pour que le serveur apparaisse dans le portail Azure.

clip_image015

De retour dans le portail Azure, on constate que notre serveur Hyper-V est maintenant associée au site.

clip_image016

Passons à l’étape suivante avec la configuration du Target. Lors de la bascule d’une machine virtuelle vers Azure, il faut pouvoir provisionner une machine virtuelle, cela implique :

  • Une souscription (qui peut être différente de celle hébergeant notre instance Azure Site Recovery)
  • Un mode de déploiement (aujourd’hui, on ne pense plus qu’en ARM)
  • Un Storage Account pour héberger les VHD (qui n’existent pas encore)
  • Un Virtual Network sur lequel on viendra connecter les interfaces des machines virtuelles

Tous les prérequis existant avant d’en arriver là, ça va tout de suite plus vite.

clip_image017

Le compte de stockage sera utilisé pour stocker les versions consistantes des machines virtuelles répliquées. Le Virtual Network sera lui utilisé pour reconnecter les machines virtuelles lors de la bascule. Un point à noter, si on a plusieurs Virtual Network, il faudra donc autant d’instances du service ASR.

Avec Hyper-V, la fréquence de réplication peut être configurée selon trois possibilités:

  • 30 secondes
  • 5 minutes
  • 15 Minutes

Dans le cas d’un contrôleur de domaine, on devrait pouvoir se contenter de 15 minutes. Le paramètre suivant détermine le nombre de recovery points consistants que l’on va conserver pour la reprise d’activité. Il est possible d’en conserver jusqu’à 24. Une configuration à 0 indique qu’on ne conserve que le dernier point de recovery dans Azure. Attention, ce paramètre va directement influer sur le stockage et donc sur la facture.

La notion de App-Consistent snapshot fait référence aux snapshots Hyper-V. Il existe deux type de snapshots. Le snapshot standard se contente de faire un cliché instantané de la machine virtuelle puis fonctionne en mode incrémentiel. Le second type (App-Consistent) travaille au niveau applicatif (Volume Shadow Copy). A ce niveau, on s’assure que l’application est dans un état compatible avec l’opération de snapshot. D’un point de vue RDP, c’est intéressant car on s’assure de pouvoir travailler à un niveau plus fin. Techniquement, il est possible de configurer jusqu’à douze App-Consistent snapshot par heure. Le hic, c’est que ce type de snapshot est consommateur en espace disque sur l’hôte Hyper-V et aussi en CPU. Vouloir plusieurs App-Consistent snapshot par heure est techniquement possible après, ce qui va nous limiter, c’est la capacité à les uploader vers Azure, et avoir terminé l’opération avant que les prochains snapshots ne se déclenchent. Pour rappel, c’est un nombre de Snapshots par heure que l’on configure. Pour cette raison, on recommande de toujours configurer le App-Consistent snapshot avec une valeur inférieure au nombre de recovery points.

Le dernier paramètre permet de spécifier le nombre de snapshots de la machine virtuelle qui seront réalisés sur l’hôte Hyper-V. Il est possible de réaliser jusqu’à 12 snapshots par heure.

clip_image018

Notre mise en place des prérequis est maintenant terminée.

clip_image019

Terminée oui, enfin presque. Avant de poursuivre, un passage par la case Capacity Planning s’impose.

clip_image020

On peut utiliser l’outil dans une version Quick ou Detailled. On a quelques inputs à fournir et l’outil nous indique en sortie quelques éléments intéressants. Le premier d’entre eux est la bande passante nécessaire pour répliquer les machines virtuelles. A noter que l’outil distingue la bande passante nécessaire pour la réplication initiale des réplications delta suivantes. Pour ce calcul, l’outil prend en compte une contrainte : la fenêtre de temps allouée pour réaliser la réplication initiale. Certes, on peut augmenter la taille de la fenêtre pour réduire la bande passante nécessaire mais il faudra bien faire passer la réplication initiale. Au moment de l’écriture de ce billet, il n’est pas encore possible d’utiliser le service Import/Export d’Azure pour envoyer des disques dur avec le contenu de notre première réplication initiale. Cependant, ce type de fonctionnalité est dans les cartons : Support for offline replication data transfer from on premise to Azure.

clip_image021

Maintenant qu’on est informé des conséquences réseau, il faut aussi se soucier des conséquences sur notre hôte de virtualisation. Réaliser des snapshots, c’est bien mais encore faut-il avoir la place de les stocker et avoir les IOPS pour les générer. Pour la réplication delta, le point d’attention sera de valider qu’on sera bien capable de répliquer ce contenu via la connectivité Internet. Au début avec quelques machines virtuelles, ça passe. Avec le temps, on ne ajoute de plus en plus jusqu’à ne plus être en mesure de répliquer tout le contenu dans un seul cycle de réplication.

Voilà pour les prérequis. Prochaine étape, on configurera la réplication.

­

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!

Les derniers articles par Benoit (tout voir)

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.