Azure Site Recovery avec Hyper-V 2/3

La mise en place étant maintenant terminée, passons à la mise en place de la politique de réplication. Celle-ci va concerner un site Hyper-V donc tous les serveurs Hyper-V qui y sont associés. Conclusion, si on veut plusieurs politiques, il faudra plusieurs groupes et donc répartir nos Hyper-V au sein de ces groupes.

clip_image001

La destination, c’est Azure (en même temps, on s’en serait douté). Plus précisément, la destination sera une souscription Azure (qui peut être différente de celle d’Azure Site Recovery), pour un mode de déploiement donné et un Storage Account. Voilà un premier point d’attention. Considérons les limites d’un Storage Account Standard avec ses 20000 IOPS de 8K et le fait que nos machines virtuelles seront composées d’au moins deux disques VHD. Sachant qu’un VHD ne peut pas consommer plus de 500 IOPS, combien de machines virtuelles puis-je placer dans un même Storage Account? La limite sera de vingt. Donc si on a plus de vingt disques VHD, il faudra plusieurs Storage Accounts et donc plusieurs politiques de réplication. Cette règle est importante car nos IOPS sont capés dans Azure. A noter qu’il n’y a pas de contrainte pour le Virtual Network. Il est possible d’appliquer une configuration générique pour toutes les machines virtuelles à répliquer ou de l’individualiser par machine virtuelle. Depuis peu, cette individualisation nous permet par exemple d’exclure des volumes des machines virtuelles à protéger.

clip_image002

Au passage, puisque la fonctionnalité Azure Storage Encryption est passée GA il y a quelques jours autant la configurer maintenant. Activée avant la réplication, tous les données stockées seront automatiquement chiffrées. Autant en profiter, c’est gratuit.

clip_image003

Passons aux machines virtuelles. L’assistant nous liste toutes les machines virtuelles hébergées sur les hôtes Hyper-V composant notre site Hyper-V. Y a qu’à faire son marché et sélectionner la ou les machines virtuelles qui nous intéressent.

clip_image004

 

A noter que si nous déplaçons une machine virtuelle sur l’hôte Hyper-V (ou cluster), il faudra un peu de temps avant de la voir apparaitre dans cette liste. Pour chaque machine virtuelle, on doit préciser le système d’exploitation et identifier le disque OS. Le système d’exploitation est nécessaire car dans Azure, le coût d’une machine virtuelle n’est pas le même entre Linux et Windows.

clip_image005

A ce stade, on peut constater un point important à prendre en considération. Ma machine virtuelle est composée d’un unique disque OS, sans aucun disque de données. Avec Azure, c’est Mal. Mal car sur ce disque OS, nous bénéficions d’un coup de boost avec un cache en lecture/écriture. Le problème, c’est que ce cache utilise la mémoire de l’hôte Hyper-V dans Azure. En cas de crash de ce dernier, on risque que les données de notre disque OS ne soient plus cohérentes. Derrière, le risque, c’est que notre machine virtuelle ne démarre plus. My two cents, corrigez ces points avant d’entamer la réplication, on évite des manipulations compliquées dans Azure. Ceci dit, notre politique de réplication est terminée.

clip_image006

 

Dans ma configuration, la réplication commence immédiatement en cliquant sur le bouton « Enable replication ».

clip_image007

 

C’est aussi maintenant qu’on commence à découvrir les contraintes d’Azure Site Recovery. Histoire de vous éviter des déconvenues, en voilà une liste (non exhaustive) :

  • Pas de prise en charge des disques SCSI et donc du contrôleur qui va avec dans nos machines virtuelles
  • Pas de prise en charge des disques VHDX partagés (pas cool, super comme fonctionnalité)
  • Pas de prise en charge des disques connectés à un contrôleur Fiber Channel virtuel
  • Pas de volume VHD de plus de 1To : Can’t recover VMs in Azure with volumes greater than 1TB? Use Storage Spaces!
  • Les volumes VHDX dynamiques seront convertis en VHD de taille fixe
  • Pas plus de 16 volumes VHD par machine virtuelle
  • Une seule adresse IP par interface réseau (donc bye bye les clusters)
  • Pour Linux, la configuration en DHCP doit être réalisée manuellement avant la mise en protection
  • Le Storage Spaces est bien utilisable mais attention, les VSS-Based Snapshots ne sont pas supportés à ce jour pour Hyper-V
  • L’utilisation de Storage Spaces n’est pas possible dans les scénarios VMWARE & serveurs physique

Pour chaque mise en place de la production d’une machine virtuelle, nous allons avoir des Jobs. Ce qui est intéressant, c’est de suivre l’activation de la protection et la finalisation de la protection (donc fin du processus de réplication initial). Dans mon cas, à peu près 40 minutes pour réaliser l’opération. D’un point de vue réseau, c’est à peu près 10Go uploadés à un rythme de 32Mb/Seconde. Normalement, ma connexion Fibre devrait me permettre d’aller plus vite. Le problème, c’est Azure. Je ne peux pas aller plus vite que lui, surtout si je n’utilise pas de connexion VPN site à site / ExpressRoute permettant de garantir la bande passante et la latence

clip_image008

 

Dans la console Azure Site Recovery, chaque machine virtuelle protégées et un Replicated Item dont on peut suivre l’état de synchronisation.

clip_image009

 

Après, il est aussi possible de suivre l’avancement des opérations en PowerShell comme illustré ci-dessous pour la réplication initiale :

clip_image010

Par contre, attention les commandes PowerShell ne sont pas disponibles pour tous les scénarios. Par exemple, au moment de l’écriture de ce billet, il n’est pas encore possible de les utiliser pour les scénarios VMWARE et serveurs physiques. Pendant la réplication, j’ai observé ce qui se passe sur mon hôte Hyper-V. Premier constat, c’est Hyper-V Replica qui est à la manœuvre. On ne constate dans l’illustration ci-dessous :

clip_image011

 

Par expérience, je sais que cela consomme des IOPS et du CPU (compression). Donc si je parallélise trop de machines virtuelles en même temps, je vais juste assassiner mon stockage. Donc avant de vous lancer dans la protection de l’intégralité des machines virtuelles hébergées sur votre hôte Hyper-V, je vous conseille de revoir vos inputs du capacity planning. La réplication initiale des machines virtuelles consomme bien plus d’IOPS que les réplications delta opérées après. Du point de vue réseau, une rapide analyse dans le moniteur de ressources de mon Hyper-V ont mis en évidence les flux réseau. Je sais que c’est de l’Hyper-V réplica, donc du HTTPS sur le port 443. Une rapide recherche avec mon vieil ami NETSTAT -ano | FindStr « :443 » m’identifie bien des flux TCP en cours pour le processus identifié avec l’ID 5184.

clip_image012

 

Avec un « Get-Process », on retrouve le processus en question. On constate qu’il consomme aussi beaucoup de CPU.

clip_image013

 

Au terme du processus de réplication initiale, la consommation CPU / IOPS va se réduire car on passe en mode de réplication Delta. Le truc ici, c’est de toujours être capable de répliquer nos snapshots vers Azure plus vite que nous ne les accumulons. Sinon, ça ne va pas le faire. Dans mon cas à moi, la protection de ma petite machine virtuelle a nécessité près de quarante minutes.

clip_image014

 

Note machine virtuelle est maintenant protégée. Prochaine étape, on va faire fumer la connexion Internet pour basculer la machine virtuelle vers Azure pour ensuite la ramener sur son Hyper-V.

­

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!

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.