Archives de catégorie : ASR

Azure Site Recovery for Azure Virtual machines (Preview)

I’ve been a big fan of Azure Site Recovery service. The product has evolved a lot since initial release (only capable to orchestrate a failover between two on-premises sites), introducing replication of on-premises workloads to Azure and many more features. Until theses last days, we had to comply with some limitations (Max 64 disks of 1Tb each per protected workload) and a major scenario we could not address. Note that Larger disk sizes just been announced in preview, up to 4Tb per Disk.

Since introduction of ASR replication capabilities (for Hyper-V, VMware or physical), we were not able to protect an Azure Virtual machine with Azure Site Recovery. ASR Team, just announced a preview of Azure Site Recovery for Azure Virtual machines. That was one of the top customer requests about Azure Site Recovery. Introduction of this new Azure Site capability allow to respond to the following scenarios:

  • Can survive to a major Azure Region failure by replicating virtual machines to another region
  • Migrate virtual machines between Azure regions
  • Comply with regulations requesting a Disaster Recovery strategy
  • Ability to clone an application based on Virtual Machines to validate

Feature is now available for public preview. Let’s see how to protect an Azure Virtual machine and develop a Disaster Recovery Plan. Note that even if this preview is available in the Azure portal, it’s still a preview. For example, support for PowerShell and CLI is not yet available.

Prerequisites

  • An instance of the Azure Recovery Site service: We will need to have an instance of the service in the Azure region in which we want to replicate with. This can be strange. If you remember Azure backup limitations, Azure Backup instance service must be in the same region as virtual machines we wish to protect.
  • A resource group in the target Azure region to store
  • A virtual network (and subnet) to connect the future Network interface. It’s not mandatory if you plan to establish RDP between two paired Azure regions (Azure virtual Network span between paired Azure regions).
  • A storage account created in the target Azure region to store virtual machines
  • A storage account created in the source Azure region to cache content to be replicated to the Target storage account
  • An availability set depending of the destination Azure region if protected workloads in the source Azure regions are linked to an existing availability set.

 

Setup

This blog post aim to describe the setup Itself, but also:

  • The Failover of an Azure Virtual machine to the target Azure Region
  • The Rollback of an Azure Virtual machine to its initial Azure region

Enabling and managing this new feature is so simple and very attractive from a financial point of view (no extra-cost for compute), that would be a crime to do not use it.

If you know the Azure Site Recovery portal experience, you should discover Azure as a source of a protected workload. Note that service is now in preview. For this blog post, I will be having a workload to protect located in Central US Azure region. My goal is to use the West Europe Azure region for DRP plan.

clip_image001

Azure Site Recovery service instance cannot be in the same Azure region as workloads to be protected. It’s logic. On this first stage, we only select the source Azure region, the deployment model and the resource group containing the workloads you wish to protect. Azure Site Recovery instance must depend of the same Azure subscription (and of course Azure environment). While writing this blog-post, it was not yet possible to protect workloads from different subscriptions. That’s a scenario that Azure CSP vendors are waiting to offer services. At this stage UX experience does not change so much from protecting other workloads:

clip_image002

That’s here that many UX changes are introduced. For this blog post, I choose to select a target Azure region that is not paired with the source Azure Region. We are not limited to the paired Azure regions. Azure Site Recovery portal make some proposal for some resources:

clip_image003

 

If you click on the « Customize » link in the upper part of the UX, you will be able to change proposal for required resources:

  • A resource Group in the target Azure region
  • A virtual Network in the Target Azure region

 

For each Virtual machine to protect we can customize:

  • The Storage account to be used to store VHD to be used by future replicated virtual machines
  • The Storage account to be used for ASR cache purpose

 

For these two storage Accounts, you don’t need more than a Local Redundant Storage.

clip_image004

 

If your virtual machines to be protected is linked to an Availability set, you will need to select an availability Set in the destination Azure region to offer the same SLA for your virtual machine.

Each Azure Virtual machine to be protected must be associated to a replication Policy.

we can customize the following parameters:

  • Retention policy for the recovery points
  • Frequency for app-consistent snapshot

clip_image005

 

Initial configuration is now over. We can enable replication.

clip_image006

 

Once replication is enabled we can follow the Azure Site Recovery Jobs. Bellow we have all jobs related to the setup of the protection of your Azure virtual machine.

clip_image007

 

If we take a closer look at the jobs related to replication, we will discover that ASR deploy a virtual machine extension in our workload.

clip_image008

 

Watch out, it’s not because initial replication is considered as enabled that its completed. Initial replication will take some times.

clip_image009

 

In my case (standard Windows Virtual machine without any data disks), initial replication took around fifty minutes.

clip_image010

Once initial replication is terminated, we can consider that our workloads is protected.

clip_image011

 

If we take a closer look at virtual machine information page, we discover two type of recovery points:

  • Crash-consistent
  • App-Consistent

 

In DRP situation, we can choose to prefer RTO versus RPO.

clip_image012

If you are familiar with Azure SQL, you should be familiar with that map. Now I have an Azure Virtual machine located in Central US Azure region with a replica in East US Azure region.

clip_image013

 

Now you have a DRP, you can test it. Microsoft recommendation is to perform a test failover from times to times to validate our DRP plan. You can choose to ignore the recommendation is you wish but that’s a good idea to test a DRP.

clip_image014

 

We can select the recovery point using:

  • The latest recovery point (for a lowest RPO)
  • The latest processed (for the best recovery time)
  • The last app-consistent

 

For this test, recommendation is to select a dedicated Virtual Network that is not connected to the source Virtual Network (Virtual Network Gateway or Peering). In the jobs, we can track the progress.

clip_image015

 

At this stage of the test we have two virtual machines running: The original and the test. Because the second one is connected to an isolated network you can check the health of the application and validate the DR plan.

clip_image016

 

Test is now complete we can cleanup used resources.

clip_image017

 

Our workload is now protected. Let’s see how to initiate a « clean failover ».

 

The « Clean Failover »

We will be considering that failover is initiated manually. In fact, using Log Analytics we can:

  • Detect an unhealthy virtual machine and initiate a single failover
  • Detect a major outage in Azure Activity and initiate a complete relocation

 

When initiating the failover process, we need decide if fast service recovery is more important than full service restauration.

clip_image018

 

Because we have both App-Consistent snapshots and Recovery points (up to 24 hours with the default policy), custom recovery point allows us to choose a specific version of my application. That’s great because, nowadays, applications are distributed among many servers. In DR situation, we will need to restore many servers.

clip_image019

 

In Azure Site Recovery Jobs view we can notice that failover was initiated.

clip_image020

 

If we look at the details, we see that the virtual machine located in the source Azure region was shutdown properly and a new virtual machine was provisioned in the target Azure region. In my case, complete failover operation took five minutes and a half (I choose to minimize the Recovery Point objective).

clip_image021

 

Once terminated Job appear as completed in the Azure Site Recovery Jobs view. From a virtual machine point of view we now have two virtual machines but only the one located in the target Azure region is running.

clip_image022

 

Once failover is completed we need to commit the operation. Once commit is performed we select another recovery point.

clip_image023

 

The clean Rollback

Rollback process is named « re-protect ». In fact, it’s the same process but we switched the target and source parameters.

clip_image024

 

By default, ASR will use the same parameters but you can override them if necessary.

clip_image025

 

It’s a little bit longer than on the protection phase, but remain an acceptable

clip_image026

 

Disable replication

That’s the bonus. When failover is committed, you have the choice to disable replication. This option was designed to move a workload from an Azure region to another.

 

Additional readings

To have more information about the feature, I would recommend the following readings :

 

Conclusion

What to say. Even if it’s a preview, it’s almost feature complete (CLI & PowerShell support are missing, just like Managed disks). Once feature will be Generally Available, we will have first-class Disaster Recovery service we cannot not implement.

 

BenoitS – Simple and Secure by design but Business compliant (with disruptive flag enabled)

 

Azure Site Recovery avec Hyper-V 3/3

Dernière étape de notre découverte d’Azure Site Recovery avec Hyper-V. A ce stade, nous avons une synchronisation de notre machine virtuelle. Plus précisément, c’est Hyper-V réplica qui se charge de maintenir une copie cohérente de notre machine virtuelle. Notre dernière étape, c’est de configurer la politique de Failover.

clip_image001

On peut disposer d’autant de Recovery Plan qu’on veut mais une machine virtuelle ne peut être liée qu’à un seul Recovery Plan. Dans mon cas, il ne concerne qu’une seule machine virtuelle.

clip_image002

Notre premier Recovery Plan est créé. Dans l’illustration ci-dessous, on constate qu’il n’a jamais été testé. C’est la faiblesse de tous nos plans de DRP. Ce qui est bien avec Azure Site Recovery, c’est qu’on peut le tester à blanc.

clip_image003

Dans le portail, lorsqu’on se positionne sur un Recovery Plan, on peut utiliser l’option « Test Failover ». L’objectif est de valider qu’Azure Site Recovery sera bien en mesure de reconstruire une machine virtuelle consistante sur un réseau Azure isolé. Nous pouvons donc le tester tant qu’on veut.

clip_image004

Attention tout de même, tous les scénarios d’implémentation ne proposent pas le même niveau de fonctionnalité. La page Technet Failover in Site Recovery documente clairement quels scénarios autorisent quels types de failover. Dans mon contexte (Hyper-V), le test Failover est bien possible. Pour le réaliser, il n’a besoin que d’une seule information : un VNET sur lequel associer la future interface réseau. Bien entendu, celui que j’ai sélectionné ne dispose ni d’Azure Gateway ou Peering. Il est donc totalement isolé.

clip_image005

Après, c’est un job en cours d’exécution. On n’a qu’à le suivre.

clip_image006

On note la notion de groupe, lorsqu’on a plusieurs VM dans une politique de failover, on peut décider l’ordre de remise en ligne. Logiquement dans ce groupe, mon contrôleur de domaine est le premier. Si j’avais d’autres machines virtuelles, je pourrais séquencer le redémarrage.

clip_image007

Avec un peu de patience, on arrive au résultat suivant :

clip_image008

Ce qu’il est intéressant de noter, c’est qu’entre l’initialisation de l’action et le démarrage de la machine virtuelle, il ne s’est écoulé trois minutes. Le temps de bascule a donc été très court. On considère que le test est concluant quand la machine virtuelle a bien réussi à démarrer. Nous avons été capable d’utiliser le dernier état consistant stocké dans Azure Site Recovery. On va clore le test.

clip_image009

 

Et indique quelques informations sur notre test avant de demander de faire le ménage.

clip_image010

Du point de vue du job, l’opération est totalement terminée.

clip_image011

Voilà pour le test. Mais tester à blanc, ça ne vaut pas grand-chose. Ce dont on a besoin c’est de valider qu’on est bien capable de reprendre le service dans Azure et de revenir On-Premises sans encombre. Pour cela, nous allons organiser un test de failover planifié. Cela signifie que sur notre hôte Hyper-V la machine virtuelle sera inactive. On va donc procéder cette fois à un « Planned Failover ».

clip_image012

Par rapport au Test Failover, cela se présente exactement de la même manière. La seule différence, c’est qu’on n’a pas à indiquer le VNET à utiliser, c’est une information qui a déjà été communiquée lors de la mise en place de la politique de réplication.

clip_image013

Par contre dans le Job, on voit bien une différence. Il commence par arrêter notre machine virtuelle et réaliser une dernière synchronisation delta vers Azure.

clip_image014

Entre l’initialisation de la bascule et la mise en ligne de la machine virtuelle, il ne s’est écoulé que cinq minutes. Pour un service de reprise sur incident As a service, c’est plutôt pas mal.

clip_image015

Logiquement, je devrais avoir une machine virtuelle dans la souscription. C’est effectivement le cas, elle a été provisionnée dans le groupe de ressources du même nom que la machine virtuelle basculée. C’est un des aspects qu’on ne maîtrise pas (au moment de la rédaction de ce billet).

clip_image016

Au passage sur mon hôte Hyper-V, ma machine virtuelle est bien arrêtée. Ce qui est intéressant, c’est que le groupe de ressource ne contient que les ressources machines virtuelles et interface réseau. C’est logique, le VHD a été restaurés dans le Storage Account asrstoragerestore01, celui que j’ai indiqué lors de la configuration d’Azure Site Recovery.

clip_image017

Note à ce niveau, ma machine virtuelle n’a qu’un seul disque OS, pas de disque de données. On-Premises, ce n’est pas un problème. Par contre dans Azure, ce n’est pas une bonne pratique. Avant de répliquer des machines virtuelles vers Azure, Quelques bonnes pratiques à respecter

  • Laisser le disque D:\ libre, on va en avoir besoin dans Azure
  • Utiliser obligatoirement des volumes de données VHD distincts pour héberger les données de vos applications

Techniquement, ma machine virtuelle est opérationnelle dans Azure. Mon planned Failover s’est déroulé sans problème, on va rebasculer On-Premises mais avant cela un bonus. Si on creuse un peu dans les menus, on va trouver une option qui va nous intéresser au plus haut point :

clip_image018

L’idée c’est qu’une fois la machine virtuelle répliquée vers Azure, on finalise complètement sa migration. La machine virtuelle n’est plus gérée par Azure Site Recovery. On peut donc utiliser Azure Site Recovery comme outil de migration. Ce sera le sujet d’un autre billet. Pour l’instant, nous allons valider la bascule avec un Commit. Cela signifie que l’on perd le contenu de nos Recovery Points. C’est logique. Par contre, cela signifie aussi qu’il faudra reconstruire le Recovery Point et repartir sur une réplication initiale. Donc à moins d’avoir de la bande passante à revendre, on ne va pas s’amuser à basculer les machines virtuelles entre On-Premises et Azure tous les matins.

clip_image019

Ici encore, l’opération de Commit est un job que l’on peut suivre.

clip_image020

A ce stade, on va repartir On-Premises en déclenchant de nouveau un « Planned Failover ». On notera que le Commit est maintenant grisé.

clip_image021

Le processus de failback ressemble beaucoup au process de failover à une exception.

clip_image022

 

On a le choix du scénario pour réaliser la bascule :

  • Minimiser le downtime
  • Réaliser un download full

Ce qui est intéressant c’est la case à cocher qui permet de recréer les machines virtuelles. On l’utilisera si on a perdu notre serveur Hyper-V. Juste un détail, dans ce sens de réplication, c’est du trafic descendant d’Azure, donc facturé. Le choix du full download n’est donc pas sans conséquences. Ça veut dire aussi qu’on peut utiliser ASR pour migrer d’un Datacenter à un autre, … Après, on connait, c’est un job comme un autre :

clip_image023

On-Premises, on peut suivre le processus dans notre console Hyper-V :

clip_image024

C’est presque fini.

clip_image025

Y a plus qu’à valider la migration. Cette opération de validation est nécessaire pour indiquer à l’agent Azure Site Recovery qu’il peut inverser le sens de réplication pour maintenant resynchroniser vers Azure.

clip_image026

 

En regardant plus précisément les détails du job de failback, on constate que le temps total d’opération a été de 48 minutes.

clip_image027

Cependant, le downtime du service est lui de 20 minutes. Dans la console Azure Site Recovery, on peut constater que le status du replicated Item est revenu à « On-premises ».

clip_image028

 

Sur notre serveur Hyper-V, on peut constater que le processus de synchronisation est de nouveau reparti vers Azure.

clip_image029

 

A noter qu’on recommence le processus de réplication depuis le début. C’est donc une réplication complète qui débute.

Voilà pour cette découverte d’Azure Site Recovery.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

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)

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)