Migration de datacentres à chaud, “We did it!”

Temps de lecture estimé : 5 minute(s)

Sortir de versions qui ne sont plus supportées, faire une extension de datacentre, remplacer un datacentre, mettre en place des Disaster Recovery, les cas d’utilisation qui demandent des mouvements de workloads entre différents datacentres sont nombreux. Et il n’a jamais été aussi simple et rapide de passer de la côte Ouest a la côte Est ou d’Amsterdam à Limbourg. En quelques clics les workloads se retrouvent envoyés via les tunnels sécurisés de HCX entre différents datacentres.

Pour donner quelques chiffres, il a fallu 5 semaines à un client pour bouger 300TB de VMs, incluant la planification, l’installation, la réplication et la bascule. En un jour, ce client est monté à 23TB de données transférées, soit 1TB/heure entre deux datacentres en Allemagne. Un autre client a bougé de son datacentre plus de 200TB, répartis sur 750 VMs, sans downtime.

Il y a encore un an, personne n’aurait jamais imaginé ces mouvements à chaud. Le concept même de déplacement des workloads entre deux datacentres était un fantasme, le faire à chaud était juste chimérique.

 

Le déplacement des workloads repose sur la technologie VMware, HCX, à destination de la plateforme Private Cloud. Cette technologie, en plus de gérer le déplacement sécurisé des workloads, permet une transition transparente en assurant une connexion réseau entre le datacentre source et le datacentre de destination via un L2 étendu, un stretched network. La machine virtuelle qui est envoyée dans Private Cloud à chaud ne perd donc aucune connectivité avec les autres machines avec lesquelles elle fonctionne en conditions nominales.

HCX  utilise 3 appliances, une pour gérer le transfert des machines virtuelles d’un datacentre à l’autre, la Cloud Gateway (CGW), une qui fonctionne de pair avec la CGW, le WAN Accelerator, et une qui sert au stretched network (L2C). Ces appliances sont déployées automatiquement côté Private Cloud, et nécessitent une  quatrième appliance côté on premise pour piloter le déploiement et la configuration de ces trois éléments indispensables.

Note : La CGW apparaît aussi dans l’inventaire comme un host enregistré.

 

Pour résumer, deux  tunnels minimum vont se monter entre le datacentre source et le datacentre de destination, le Private Cloud OVH. Un tunnel entre les CGW pour le transfert des VMs, et un tunnel entre les L2C qui va créer le stretched network dans le cas d’un besoin d’extension d’un sous-réseau. Il va de soi qu’il est possible de déployer plusieurs L2C, en fonction du nombre de réseaux à étendre.

 

Une fois l’architecture on premise déployée, on peut voir un dashboard qui va résumer les possibilités de migration, et disposer d’un historique.

Il y a plusieurs façons de bouger les machines virtuelles, une migration « à chaud », une migration dite « tiède » et une migration « à froid ».

La migration à chaud est de loin la plus impressionnante. En quelques clics, une machine virtuelle se retrouve dans le datacentre de destination sans perdre son état, sa connectivité et son contexte. Le procédé est assimilable au vMotion, bien connu des utilisateurs VMware, cette méthode porte le nom vMotion Migration. Le principe est que le stockage de la VM est envoyé sur le datacentre de destination, une fois que le stockage de la VM est complètement synchronisé, c’est au tour de la mémoire et du CPU de se faire synchroniser et au datacentre de destination de prendre le relai. La limitation de cette méthode est la séquentialisation du procédé qui peut impacter les workloads répartis sur plusieurs VMs et nécessitent  une latence faible entre les VMs. Lorsque la VM aura migré, la latence entre les datacenters va se faire ressentir :

C’est donc avec la “Bulk Migration” que nous allons adresser cette problématique, en rajoutant en plus, des fonctionnalités d’aide à la migration contrôlée. L’objectif de cette migration est de synchroniser une ou un ensemble de VMs avec le datacentre de destination pendant qu’elles sont encore sur le datacentre source, et de maintenir cette synchronisation dans le temps. La bascule de la totalité des VMs aura lieu sur une période choisie par l’administrateur à l’origine de cette migration, sur un créneau horaire le plus favorable à la bascule, qui passera par une extinction de la VM sur le datacentre source et un démarrage de la VM sur le datacenter de destination. En plus de maîtriser le créneau de bascule, il est possible de customiser la VM (mise à jour des VMware Tools, upgrade du matériel virtuel, etc). Comme l’ensemble des VMs bouge en même temps, plus de questions à se poser sur la latence dans le stretched network.

 

 

La dernière méthode de bascule est disruptive pour les machines de production, et donc plutôt destinée à la migration des templates, des archives, des backups. Elle se fait à froid, VM éteinte, et va donc simplement synchroniser les données et basculer automatiquement quand toutes les données sont arrivées sur le datacentre de destination.

Nous avons une expérience de plus de 3 ans sur de la migration sécurisée de workloads, d’abord sur les datacentres de vCloud Air, puis sur les datacentres propres à OVH. Durant cette période nous avons migré des exabytes de données dans le monde entier.

HCX est un outil qui a été désigné pour répondre à plusieurs problématiques liées à la migration, aussi bien sur le maintien en opérationnel des machines virtuelles pendant leur transfert, sur le besoin de basculer des groupes des VMs ainsi que la connexion réseau entre les différents datacentres, et il faut y associer un travail d’architecture. En effet, une migration se prépare en amont, avec un sizing suffisant du datacentre  de destination, qu’on peut adapter dans le temps sur Private Cloud OVH. Il faut aussi travailler sur une estimation du temps de bascule et sur la stratégie de bascule associée aux différents workloads du datacentre source. Pour le reste, ce n’est que l’histoire de quelques clics dans HCX.