Unité 7.4 : Migration et basculement hybride

Introduction

La migration est l'unité où l'honnêteté de la plateforme est la plus déterminante, car la principale source de risque pour un projet réside dans une capacité supposée mais en réalité absente. IONOS CLOUD ne dispose d'aucun assistant natif d'importation OVF/OVA : il est impossible de diriger une console vers une exportation vSphere et d'obtenir une instance IONOS CLOUD opérationnelle. La migration est donc conçue, et non importée, et le travail de conception consiste à choisir le bon chemin technique pour chaque charge de travail, puis à séquencer ces chemins de manière à ce que l'activité ne soit jamais interrompue plus longtemps que ce qui a été convenu.

Cette unité s'articule autour de FinCorp, une entreprise allemande du secteur financier qui exploite un important parc VMware soumis aux obligations du RGPD et de l'BSI. Ce parc représente la plus importante utilisation unique de Private Cloud dédié dans l'ensemble du cours, et la conception de la migration s'appuie directement dessus : lorsque la cible est un VMware dédié, FinCorp peut conserver les VM en l'état et utiliser les outils natifs de VMware ; lorsque la cible est la surface standard d'IONOS CLOUD Public Cloud, les mêmes VM doivent être converties. Prendre la bonne décision à cet embranchement, charge de travail par charge de travail, constitue l'architecture.

1. Le cadre de disposition, appliqué honnêtement

Avant de choisir un outil, classez chaque charge de travail selon ce que vous comptez modifier. Le cadre de disposition (le modèle « R ») désigne les options réalistes pour un patrimoine de cette taille. La version honnête est réduite à trois, car les autres (conserver, mettre à la retraite, racheter) sont des décisions de ne pas migrer cette charge de travail du tout :

• Rehost (« lift and shift ») : déplacer la charge de travail en l'état, avec le même système d'exploitation et la même application, vers l'infrastructure cible. C'est le chemin le plus rapide, avec le risque applicatif le plus faible, mais aucun avantage de modernisation.
• Replatform (« lift and reshape ») : conserver l'application, mais remplacer un composant sous-jacent par un équivalent managé, par exemple en déplaçant une VM PostgreSQL auto-gérée vers Managed PostgreSQL. L'effort est modéré, cela supprime la charge opérationnelle, mais introduit une étape de migration des données.
• Refactor : modifier l'application elle-même, par exemple en décomposant un monolithe sur Managed Kubernetes. L'effort et le risque sont les plus élevés, et cette tâche est reportée à un programme dédié plutôt que d'être intégrée à une vague de bascule.

La décision de disposition est ce qui sélectionne le chemin d'infrastructure, et le point de divergence le plus déterminant est la plateforme cible. Un rehost vers un Private Cloud dédié conserve la VM intacte et native VMware, ce qui permet d'utiliser les outils de réplication VMware. Un rehost vers la surface standard d'IONOS CLOUD Public Cloud (Compute Engine) franchit une frontière d'hyperviseur : Private Cloud fonctionne sur VMware ESXi, tandis que la famille de produits Public Cloud fonctionne sur un substrat différent, basé sur KVM, et les deux familles ne sont pas interchangeables. C'est cette frontière, et non une préférence, qui fait que certains rehosts sont des tâches de conversion d'image et d'autres des tâches de réplication.

Un replatform comporte toujours une étape de données que le chemin d'infrastructure ne couvre pas. Convertir l'image disque d'une VM de base de données déplace la machine ; cela ne permet pas à IONOS CLOUD Managed PostgreSQL d'adopter ces données. Les données sont déplacées séparément, par déchargement et restauration (Section 4). Traitez chaque replatform comme deux migrations coordonnées : l'application environnante et les données sous-jacentes.

2. Les trois chemins d'infrastructure

Chaque disposition aboutit à l'un des trois chemins conçus. Ils diffèrent par ce qui est préservé, par les outils qui transportent les octets, et par la durée d'indisponibilité que représente le basculement.

2.1 Chemin 1 : Conversion et téléversement d'image

C'est le chemin à suivre lorsque la cible est la surface standard d'IONOS CLOUD Public Cloud et que la machine virtuelle doit franchir la frontière entre VMware et KVM. Il n'existe pas d'import natif OVF/OVA, la machine virtuelle est donc convertie en image amorçable puis téléversée, avant d'être provisionnée en tant qu'instance IONOS CLOUD.

L'exigence technique non négociable est le jeu de pilotes invités. Les instances IONOS CLOUD Public Cloud amorcent sur KVM et nécessitent les pilotes KVM VirtIO ; une image ne contenant que les pilotes paravirtualisés de VMware ne s'amorcera pas correctement ou fonctionnera sans performance disque et réseau. Pour les invités Windows, IONOS CLOUD fournit une image ISO contenant les pilotes VirtIO pertinents, que vous montez en tant que lecteur CD-ROM et installez avant ou pendant le basculement. La séquence pratique consiste à installer les pilotes VirtIO dans la machine virtuelle source tant qu'elle est encore en cours d'exécution sur VMware (afin que l'image convertie les contienne déjà), à convertir le disque virtuel dans un format téléchargeable pris en charge, à le téléverser, puis à provisionner une instance à partir de l'image téléversée. Le mode firmware est important : un invité installé sous UEFI doit être provisionné pour amorcer en UEFI sur la cible, et un invité installé sous BIOS legacy doit amorcer en BIOS ; un désaccord produit une image non amorçable et constitue l'échec évitable le plus courant sur ce chemin.

Le chemin 1 est intrinsèquement un basculement hors ligne pour la charge de travail convertie : la source est arrêtée pour obtenir un état disque cohérent, convertie, téléversée, puis amorcée sur la cible. L'indisponibilité couvre la conversion et le téléversement, ce qui varie en fonction de la taille du disque et de la bande passante de la liaison, ce qui en fait le chemin avec la fenêtre de basculement la plus longue et la moins prévisible. C'est le bon chemin pour les charges de travail modernisées sur la surface Public Cloud, et le mauvais chemin pour un parc important que l'on souhaite simplement conserver intact.

2.2 Chemin 2 : Réplication native VMware vers Private Cloud dédié

Lorsque la cible est un Private Cloud dédié, la machine virtuelle ne quitte jamais VMware, la migration reste donc dans les outils natifs de VMware et la fenêtre de basculement se réduit. L'outil fourni par IONOS CLOUD à cet effet est VMware Cloud Director Availability (VCDA).

VCDA est une offre Disaster-Recovery-as-a-Service qui protège les vApps et les machines virtuelles par réplication asynchrone, les migre, effectue le basculement et le basculement inverse, et est déployée entre le vCenter sur site du client et le Private Cloud IONOS CLOUD. Dans un Private Cloud IONOS CLOUD, l'appliance côté cloud est provisionnée automatiquement, et le client déploie une appliance de réplication correspondante sur site dans le vCenter local ; les deux sont ensuite appairées. La version déployée est VCDA 4.7.x. L'appliance sur site atteint l'appliance cloud via l'IP publique du Private Cloud sur le port TCP 55443. Sur le plan commercial, c'est la propriété décisive : seules les machines virtuelles protégées sont facturées, à 50 EUR par machine virtuelle et par mois pour VCDA Protection, et la fonctionnalité de migration elle-même est gratuite. Un parc important peut donc être migré avec VCDA sans frais de migration par machine virtuelle, en ne payant que pour les machines virtuelles maintenues sous protection DR continue par la suite.

Le modèle de réplication est ce qui rend le basculement court. VCDA réplique de manière asynchrone pendant que la source continue de fonctionner, les données sont donc préparées sur la cible avant toute indisponibilité. Le basculement est un failover : la source est mise en quiescence, le delta final est répliqué, et la machine virtuelle est allumée sur le site IONOS CLOUD Private Cloud. Comme VCDA effectue également un basculement inverse, le basculement dispose d'un retour arrière défini : si la validation échoue, on bascule la machine virtuelle en arrière vers le site sur site encore intact. C'est la raison la plus importante pour laquelle un grand parc VMware cible le Private Cloud plutôt que le chemin de conversion : les machines virtuelles restent intactes, la fenêtre de basculement par machine virtuelle est de quelques minutes plutôt que de quelques heures, et le retour arrière est intégré au même outil.

Deux points de réseau gouvernent la qualité du basculement :

• Extension de couche 2. Pour permettre aux machines virtuelles migrées de conserver leurs adresses IP existantes lors d'un basculement progressif, NSX-T fournit un VPN L2, qui étend un segment de couche 2 entre le réseau sur site et un segment NSX dans le Private Cloud. Les segments NSX sont des domaines virtuels de couche 2, de sorte qu'un segment étendu permet à une machine virtuelle migrée de se situer dans le même domaine de diffusion qu'elle avait sur site pendant que ses pairs sont encore en cours de déplacement. C'est ce qui évite de réadresser chaque machine virtuelle le premier jour et permet à un cluster de dépendances de se déplacer par étapes.
• Mobilité intra-cluster uniquement. Une fois les machines virtuelles en cours d'exécution dans le Private Cloud, vMotion peut les déplacer en direct entre les hôtes au sein du cluster (par exemple pour équilibrer la charge ou pour vidanger un hôte). vMotion est uniquement intra-cluster. Ce n'est pas un mécanisme de migration inter-sites et ne déplace pas une machine virtuelle en cours d'exécution de sur site vers IONOS CLOUD ; ce déplacement inter-sites est le rôle de VCDA, et c'est une opération de réplication puis de basculement, et non un déplacement inter-sites en direct. Ne concevez pas un basculement autour du déplacement de machines virtuelles en cours d'exécution entre sites sans indisponibilité ; cette capacité n'existe pas.

2.3 Chemin 3 : Sauvegarde et restauration

Le troisième chemin traite la migration comme une récupération : sauvegarder la charge de travail depuis la source et la restaurer sur la cible. C'est le plus lent à basculer car il est séquentiel (une sauvegarde complète, puis une restauration complète) et hors ligne pendant toute la durée, mais c'est le plus universellement applicable et ne nécessite aucune liaison en direct entre les sites. Utilisez-le pour les charges de travail où ni un chemin de réplication VMware propre ni une conversion d'image ne sont justifiés : serveurs à faible taux de modification, systèmes d'archivage, ou tout ce où une longue fenêtre de maintenance est acceptable et où la simplicité opérationnelle prime sur la vitesse de basculement. C'est aussi le repli naturel lorsque la conversion du chemin 1 s'avère non amorçable et que le calendrier ne permet pas une seconde tentative.

2.4 Choix entre les chemins

Le tableau suivant compare les trois chemins sur les dimensions qui déterminent réellement la décision.

La règle qui en découle : une machine virtuelle destinée à un VMware dédié emprunte le chemin 2 par défaut, car c'est le seul chemin qui conserve la machine virtuelle intacte et offre un basculement court et réversible. Une machine virtuelle modernisée sur la surface Public Cloud emprunte le chemin 1 et accepte le travail de conversion et la fenêtre plus longue. Le chemin 3 est le repli pour la longue traîne où aucun chemin spécialisé ne justifie sa complexité.

3. Planification des vagues et basculement hybride

Un parc d'infrastructure de grande envergure n'est jamais basculé d'un seul coup. Il est décomposé en vagues, et l'unité d'une vague est un cluster de dépendances : un ensemble de VM qui communiquent entre elles et qui doivent soit migrer ensemble, soit rester accessibles à travers la frontière pendant qu'ils sont séparés. Diviser une application très communicante à travers la frontière entre les sites locaux et le cloud au milieu d'une vague transforme chaque appel interne en aller-retour sur le lien hybride. C'est donc le cluster de dépendances, et non la VM individuelle, qui constitue l'atome de planification.

Ordonnez les vagues afin d'éliminer les risques tôt et de gérer proprement les dépendances :

1. Vague pilote : un petit cluster de dépendances autonome et de faible criticité. Son objectif est de valider de bout en bout le chemin choisi (conversion ou appariement VCDA, le lien hybride, les portes de validation) avant que tout élément important ne soit déplacé.
2. Vagues de feuilles de dépendance : les systèmes sur lesquels d'autres dépendent, mais qui dépendent peu d'autres éléments eux-mêmes, sont déplacés avant leurs consommateurs, afin que les consommateurs ne pointent jamais vers quelque chose qui n'est pas encore arrivé à travers la frontière.
3. La vague des bases de données : séquencée délibérément par rapport à ses applications (section 4), car il s'agit d'une opération de vidage/restauration et donc d'un basculement rigide, et non d'un transfert progressif.
4. Les vagues des applications et des points d'accès : les consommateurs, déplacés une fois que leurs données et leurs dépendances sont déjà en place.

Tout au long de la migration, le parc est hybride, de sorte que le lien entre le site local et IONOS CLOUD est porteur, et non accessoire. Deux éléments du Module 3 le supportent : un VPN Gateway (IKEv2/WireGuard, HA actif-passif sur une IP publique partagée) pour la connectivité chiffrée de site à site, et Cross-Connect pour un interconnect privé à bande passante plus élevée lorsque le volume de migration ou le trafic résiduel à travers la frontière le justifie. Pour les VM qui atterrissent dans un Private Cloud dédié, le VPN L2 NSX-T de la section 2.2 est l'extension au niveau du segment qui permet à un cluster de dépendances de s'étendre sur les deux sites sans réadressage. Dimensionnez ces liens pour le mouvement de données de la migration, et non seulement pour le trafic en régime permanent ; un lien sous-dimensionné est la cause la plus fréquente d'une vague qui dépasse sa fenêtre de temps.

Chaque vague se termine par une porte de validation avant que le trafic ne soit basculé : confirmez que la charge de travail démarre, que l'application répond sur ses points d'accès, que les données sont intactes et à jour, et que les systèmes dépendants peuvent toujours y accéder à travers la frontière restante. Ce n'est qu'après le passage de la porte que vous basculez le trafic, généralement en redirigeant le DNS (Unité 3.7), ce qui oriente les nouvelles connexions vers le point d'accès migré tandis que l'ancien se vide.

Si une porte échoue, la position de retour arrière diffère selon le chemin et doit être conçue à l'avance :

• Chemin 2 (VCDA) : le basculement inverse ramène la VM vers le site local intact. C'est le retour arrière le plus propre et une autre raison pour laquelle les charges de travail ciblées sur VMware présentent le risque le plus faible.
• Chemin 1 et Chemin 3 : la VM source a été arrêtée mais pas détruite, de sorte que le retour arrière consiste à rallumer la source (et à rediriger le DNS). Conservez la source intacte et intouchée jusqu'à ce que la porte soit passée ; ne décommissionnez pas une source dans la même vague qui la migre.
• Les Snapshots constituent un retour arrière au sein de la cible, et non un retour arrière inter-sites. Un snapshot au niveau de la VM sur la cible (qu'il s'agisse d'un snapshot vSphere de Private Cloud ou d'un snapshot Block Storage d'IONOS CLOUD) vous permet de ramener une VM fraîchement migrée à son état d'arrivée si une modification après basculement échoue. Il est local à la région et au niveau de la VM, et il n'est pas cohérent au niveau de la base de données : un snapshot d'une VM de base de données en cours d'exécution peut capturer un état de transaction en cours qui ne se restaure pas proprement. Les Snapshots protègent l'étape de basculement ; ils ne remplacent pas le vidage/restauration de la vague des bases de données.

4. La vague des bases de données : Dump et restauration

Les bases de données sont la vague qui fait le plus souvent échouer un plan autrement solide, car l'instinct est de les migrer comme n'importe quelle VM. Pour les charges de travail en cours de replatforming sur les bases de données managées d'IONOS CLOUD, cet instinct est erroné : il n'existe aucune bascule native basée sur la réplication depuis une base de données source vers IONOS CLOUD Managed PostgreSQL, MariaDB ou MongoDB. Le chemin de migration pris en charge est le dump et la restauration. Vous exportez un dump logique depuis la source, puis vous le chargez dans le cluster managé cible.

Cela façonne la vague de trois manières. Premièrement, il s'agit d'une bascule définitive avec une interruption réelle : pour effectuer un dump cohérent, vous arrêtez les écritures à la source, effectuez le dump, restaurez, et validez avant de reprendre les écritures sur la cible. La fenêtre temporelle est proportionnelle au volume de données, si bien que la vague des bases de données reçoit la fenêtre de maintenance la plus généreuse du plan. Deuxièmement, le repli est la source elle-même : gardez la base de données source en ligne et autoritaire jusqu'à ce que la cible restaurée passe sa porte de validation, puis modifiez la chaîne de connexion de l'application. Troisièmement, une instantané côté cible n'est pas le filet de sécurité ici. Étant donné que les instantanés ne sont pas cohérents au niveau de la base de données, le dump est l'artefact de migration autoritaire et la source est le repli autoritaire. Planifiez la vague des bases de données de sorte que sa fenêtre de dump/restauration soit alignée avec, et idéalement précède, la bascule des applications qui en dépendent, afin que ces applications arrivent sur une base de données déjà peuplée et validée.

Résumé de la décision

Utilisez la disposition pour sélectionner le chemin d'infrastructure, la plateforme cible pour la confirmer, et le tableau ci-dessous comme grille d'évaluation synthétique.

Contraintes strictes à appliquer à chaque vague : il n'existe pas d'import natif OVF/OVA (la conversion est réalisée par ingénierie) ; vMotion est intra-cluster uniquement et ne constitue pas un déplacement inter-sites ; la migration des bases de données se fait uniquement par dump/restore ; et les instantanés sont au niveau de la VM, locaux à la région, et non cohérents au niveau de la base de données. Pour FinCorp, le parc VMware important se résout proprement : la majorité du parc est rehostée vers un Private Cloud dédié via VCDA (VM entières, migration gratuite, bascule inverse en cas d'échec, VPN NSX-T L2 maintenant les adresses stables à travers les vagues phasées), les bases de données désignées pour les services managés sont replatformées par dump/restore dans leur propre vague horodatée, et seules les charges de travail explicitement modernisées empruntent le chemin de conversion d'image vers la surface Public Cloud.

Résumé

La migration vers IONOS CLOUD est conçue, et non simplement importée : en l'absence d'import natif OVF/OVA, l'architecture consiste à choisir, pour chaque charge de travail, l'une des trois approches honnêtes (conversion et téléversement d'image vers la surface Public Cloud KVM, réplication VCDA vers VMware dédié, ou sauvegarde/restauration), à les séquencer par cluster de dépendances en vagues sur un lien hybride dimensionné, et à contrôler chaque vague par une validation et un retour arrière spécifique à la voie choisie. La vague des bases de données constitue une bascule rigoureuse à part entière par déchargement et restauration, et les instantanés servent de filet de sécurité au niveau de la VM pour l'étape de bascule, sans pour autant la remplacer.

Points clés :

• Il n'existe pas d'import natif OVF/OVA ; la migration est conçue pour chaque charge de travail, et la plateforme cible (VMware ou KVM) détermine la voie à suivre.
• VCDA 4.7.x est la voie native VMware vers le Private Cloud dédié : réplication asynchrone, migration gratuite, bascule et bascule inverse, avec une facturation à 50 EUR par VM par mois uniquement pour les VM protégées ; l'appliance cloud est accessible sur le port TCP 55443.
• Le VPN L2 NSX-T étend un segment de couche 2 entre les sites afin que les vagues progressives conservent leurs adresses IP ; vMotion est limité à l'intérieur d'un cluster et ne constitue jamais un déplacement en direct entre sites.
• La voie de conversion d'image nécessite les pilotes KVM VirtIO et un firmware UEFI/BIOS correspondant, et constitue une bascule hors ligne dont l'échelle dépend de la taille des disques et de la bande passante du lien.
• Les bases de données sont migrées par déchargement et restauration avec une fenêtre de bascule rigoureuse ; la source reste autoritaire jusqu'à ce que la cible soit validée, et les instantanés ne sont pas cohérents au niveau de la base de données.

Terminologie importante :

• VCDA (VMware Cloud Director Availability) : outil DRaaS natif VMware fourni par IONOS CLOUD pour la réplication, la migration, la bascule et la bascule inverse de VM entre un vCenter sur site et le Private Cloud IONOS CLOUD ; version 4.7.x, migration gratuite, protection par VM facturée séparément.
• NSX-T L2 VPN : extension de couche 2 qui étend un segment NSX entre les sites afin que les VM migrées conservent leurs adresses lors d'une bascule progressive.
• Disposition : décision par charge de travail (relogement, replatforming, refactoring) qui sélectionne la voie de migration de l'infrastructure.
• Vague : cluster de dépendances de charges de travail migrées ensemble, avec une porte de validation et un retour arrière défini à son terme.

Lectures complémentaires

• Unité 4.4 : Private Cloud (Dedicated VMware) - la plateforme cible pour le chemin de migration natif VMware
• Unité 5.3 : Bases de données relationnelles - modes de réplication et chemin de migration par déchargement/restauration pour la vague des bases de données
• Unité 3.6 : Connectivité hybride - VPN Gateway et Cross-Connect, les liens qui assurent la bascule hybride
• Unité 7.1 : Résilience et continuité d'activité - bascule DNS orchestrée par le client et les stratégies de récupération sur lesquelles elle s'appuie