Archives de catégorie : Azure Site Recovery

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)