Ca déménage

Le plus important dans un déménagement de Data Center qu’il soit de OnPrem vers/depuis le Cloud Public et/ou de OnPrem vers le OnPrem, ce sont les données, les applications et leur accessibilité par les utilisateurs internes et externes. Un des intérêts d’un déménagement de Data Center et d’en profiter pour le rendre plus moderne, plus agile, plus véloce afin d’y héberger les applications modernes à base de container à côté des applications existantes.

Dans cet article, je ne vais pas couvrir les applications fonctionnant directement sur des serveurs physiques, c’est un périmètre que je ne couvre pas habituellement chez mes clients, et il ne représente qu’un faible pourcentage d’application, environs moins de 10%. En revanche, je vais traiter celles s’exécutant sur des environnements virtualisés, ce qui représente environs pus de 90% des applications. La majorité des clients dispose d’hyperviseurs vSphere, certains peuvent encore avoir un peu d’Hyper-V ou de KVM mais c’est vraiment très rare.

Un des avantages apportés par la virtualisation des serveurs et la faculté de représenter une machine physique et de tout ce qu’elle contient (système d’exploitation, Applications, configurations, données, …) dans des machines virtuelles (VMs) qui sont stockées dans des fichiers. Le déménagement de ces VMs, consiste donc à copier ces fichiers vers la nouvelle destination. Pour accéder aux VMs copiées, il faut les connectés à un réseau si possible sans avoir à modifier le plan d’adressage IP initial car c’est un travail fastidieux et risqué, en effet certaines applications n’ont pas été conçues pour prendre en compte ce type de changement. Pour simplifier cela, il faut virtualiser le réseau et ainsi être capable de reproduire à la destination ce qu’il y avait sur le site initial permettant d’éviter le changement d’adressage IP de tous les serveurs et des applications. A noter qu’il n’est pas nécessaire de virtualiser le réseau à source seule à la destination suffit. Une autre méthode aurait été de reproduire physiquement et à l’identique le réseau à la destination, même si cela est possible dans un déménagement de OnPrem vers OnPrem, c’est impossible à réaliser dans un déménagement vers le Cloud Public. Vous l’aurez compris, appliquer la virtualisation au réseau comme cela a été fait aux serveurs physiques permet d’être complément découplé de l’infrastructure physique et être libre de choisir le fournisseurs matériel et/ou hébergeurs.

La première étape du déménagement consiste à avoir un environnement de destination virtualisé à minima l’hyperviseur et le réseau pour recevoir les VMs, il faut ensuite les transférer, nous avons vu que les VMs étaient des fichiers et qu’il suffisait de les copier sur la destination. C’est aussi simple que ça, cependant pour avoir un état cohérent des données, la copie devra se faire à froid, c’est-à-dire VMs éteintes, cela engendra une indisponibilité d’accès aux applications durant toute la durée de la copie. Une fois terminée et les VMs associées aux bons réseaux il faut les démarrer à la destination. Les copies vont être longues et donc l’indisponibilité le sera aussi car il y aura une grosse volumétrie de données. Une autre méthode consiste à utiliser des outils de réplication qui vont répliquer les VMs pendant leur fonctionnement, et seulement une fois la réplication terminée arrêter les VMs à la source, finir de répliquer les résidus puis démarrer les VMs à la destination. Ces deux méthodes manuelles peuvent convenir pour des petits environnements mais pas s’il y a des centaines ou des milliers VMs, ça devient rapidement fastidieux. Pour encore simplifier ce processus, il est possible de tout orchestrer en utilisant un outil tel que VMware HCX que je vais décrire et qui permet de répondre à certaines questions importantes, comment faire un déménagement si mes applications ne me permettent pas d’indisponibilité ? Comment je fais si je veux un déménagement séquentiel ? Ou encore comment tout préparer et le faire à un moment précis ?

VMware HCX offre différents types de migration :

• Bulk Migration : Pour des migrations massives de VMs, elles se feront en parallèle par lots.
• Mobility Groups : pour migrer des VMs regroupées par thématique.
• vMotion Migration : pour déplacer des VMs de façon unitaire.
• OS Assisted Migration : Pour migrer des VMs non vSphere donc soit KVM ou Hyper-v

En plus des types de migration, il y a des fonctionnalités réseau intéressantes dans le cadre de migration :

• Interconnect : déploie un virtuel interconnecte réseau sécurisé entre les appliances HCX de part et d’autre pour plus de sécurité/
• Wan Optimization : Permet de réduire la quantité de donnée qui transite entre les sites via des mécanisme de déduplication et de compression.
• Network Extension : Permet d’étendre le niveau 2 du réseau entre les sites et garder ainsi le même plan d’adressage de part et d’autre.
• Application Path Resiliency : Permet de multiplier les chemins de communication entre les sites et de ne plus utiliser ceux qui ont subis une défaillance.
• Mobility Optimized Networking (MON) : Permet utiliser la gateway la plus proche (donc sur le même site) pour les applications qui souhaitent atteindre un réseau différent.

D’autres cas d’usages sont offerts par VMware HCX :

• Upgrade des versions vSphere : pour migrer des VMs hébergées sur une version de vSphere et aller vers un hyperviseur de version différente.
• Workload Rebalancing : Déplacer les workload entre différents Cloud en fonction de la disponibilité des ressources et/ou de la saisonabilité des coûts.
• Business continuity and Protection : pour protéger des workloads sur un autre site et bénéficier des avantages réseau. Ça peut aussi être couplé à SRM (Site Recovery Manager).

Revenons sur le sujet initial du déménagement avec d’autres points importants d’actualité émanent des demandes croissantes d’aller vers le Cloud Public, ces demandent amènent ces questions, comment je fais pour déménager vers un Cloud Public sans avoir à transformer mes VMs ? Comment faire si demain je décide de changer de Cloud Public et ainsi éviter d’être verrouillé ?

Pour être le plus indépendant possible il faut avoir un format de VMs multi-cloud, c’est-à-dire un format de VM qui est disponible dans les data center OnPrem mais aussi chez la quasi-totalité des hyperscalers tels que Alibaba Cloud, Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud Infrastructure, OVH, …, et ce avec une présence géographique locale et/ou globale. C’est le cas des VMs utilisées par VMware, en effet les hyperscaler ont décidé de proposer à leurs clients d’utiliser leur hyperviseur et/ou l’hyperviseur développé VMware que les clients on l’habitudes d’utiliser. Cette décision n’est pas anodyne car elle permet de simplifier drastiquement les migrations en éliminant la nécessité de transformation et ainsi consommer plus rapidement leurs ressources. Les plus gros d’entres-eux proposent même le SDDC VMware complet en y ajoutant la virtualisation du réseau et du stockage couplé à VMware HCX pour encore plus accélérer encore plus la migration. Les clients ont ainsi plus de liberté de choisir leur fournisseur de Cloud qu’il soit OnPrem ou Public.

En résumé, le plus important dans un déménagement est d’avoir une destination qui soit le plus virtualisé possible, virtualisation des serveurs, du réseau (sécurité incluse) et du stockage. Avoir un orchestrateur qui va simplifier la migration et de choisir un format de VM qui soit multi-cloud pour éviter d’être verrouillé avec un hyperscaler.