Unité 7.4 : Migration et basculement hybride

Introduction

La migration est l'unité où l'honnêteté de la plateforme compte le plus, car la plus grande source de risque de projet est une capacité supposée mais non présente. IONOS Cloud n'a pas d'assistant d'importation OVF/OVA natif : vous ne pouvez pas pointer une console vers une exportation vSphere et avoir une instance IONOS en cours d'exécution qui apparaît. La migration est donc conçue, et non importée, et le travail de conception consiste à choisir le chemin conçu approprié pour chaque charge de travail et à mettre en séquence ces chemins afin que l'entreprise ne soit jamais hors ligne plus longtemps qu'elle ne l'a accepté.

Cette unité s'appuie sur FinCorp, la société financière allemande qui possède un grand estate VMware sous les obligations GDPR et BSI. L'estate est l'utilisation la plus importante de Private Cloud dédiés dans tout le cours, donc la conception de migration s'appuie directement sur celui-ci : lorsque la cible est un VMware dédié, FinCorp peut conserver les machines virtuelles intactes et utiliser les outils natifs de VMware ; lorsque la cible est la surface standard IONOS Public Cloud, les mêmes machines virtuelles doivent être converties. Trouver la bonne bifurcation, charge de travail par charge de travail, est l'architecture.

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

Avant de choisir un outil, classez chaque charge de travail en fonction de ce que vous avez l'intention de modifier. Le cadre de disposition (le modèle "R") nomme les options réalistes pour un patrimoine de cette taille. La version honnête est limitée à trois car les autres (conserver, retirer, racheter) sont des décisions de ne pas migrer cette charge de travail du tout :

• Rehéberger ("lift and shift") : déplacer la charge de travail telle quelle, même système d'exploitation et application, sur une infrastructure cible. Chemin le plus rapide, risque d'application le plus bas, aucun avantage de modernisation.
• Replateformer ("lift and reshape") : conserver l'application, mais remplacer un composant sous-jacent par un équivalent géré, par exemple en déplaçant un Managed PostgreSQL VM auto-géré sur un Managed PostgreSQL. Effort modeste, supprime les tâches opérationnelles, mais introduit une étape de migration des données.
• Refactoriser : modifier l'application elle-même, par exemple en décomposant un monolithe sur un Managed Kubernetes. Effort et risque les plus élevés, reporté à son propre programme plutôt qu'intégré dans une vague de basculement.

La décision de disposition est ce qui sélectionne le chemin d'infrastructure, et la fourche la plus lourde est la plateforme cible. Un rehébergement sur des Private Cloud dédiés conserve le VM entier et VMware-natif, il peut donc utiliser les outils de réplication VMware. Un rehébergement sur la surface standard IONOS Public Cloud (Compute Engine) franchit une limite de hyperviseur : Private Cloud exécute VMware ESXi, tandis que la famille de produits Public Cloud s'exécute sur un substrat différent, basé sur KVM, et les deux familles ne sont pas interchangeables. Cette limite, et non une préférence, est la raison pour laquelle certains rehébergements sont un travail de conversion d'image et d'autres sont un travail de réplication.

Un replatformation implique toujours une étape de données que le chemin d'infrastructure ne couvre pas. La conversion de l'image disque d'une base de données VM déplace la machine ; elle ne fait pas adopter ces données par IONOS Managed PostgreSQL. Les données sont déplacées séparément, par vidange et restauration (Section 4). Traitez chaque replatformation comme deux migrations coordonnées : l'application environnante et les données qui se trouvent en dessous.

2. Les trois parcours d'infrastructure

Chaque disposition se résout en l'un des trois parcours conçus. Ils diffèrent par ce qui est préservé, par l'outil qui transporte les octets et par le coût du temps d'arrêt de la coupure.

2.1 Parcours 1 : Conversion d'image et téléchargement

C'est le parcours lorsque la cible est la surface standard IONOS Public Cloud et que le VM doit traverser la frontière VMware-to-KVM. Il n'y a pas d'importation native OVF/OVA, donc le VM est converti en une image amorçable et téléchargé, puis provisionné en tant qu'instance IONOS.

L'exigence technique non négociable est l'ensemble de pilotes invité. Les instances IONOS Public Cloud démarrent sur KVM et nécessitent des pilotes KVM VirtIO ; une image qui ne transporte que les pilotes paravirtuels VMware ne démarre pas correctement ou s'exécute sans performances de disque et de réseau. Pour les invités Windows, IONOS fournit une image ISO contenant les pilotes VirtIO pertinents, que vous montez en tant que lecteur de CD-ROM et installez avant ou pendant la coupure. La séquence pratique consiste à installer des pilotes VirtIO dans la source VM tandis qu'elle est toujours en cours d'exécution sur VMware (de sorte que l'image convertie contienne déjà ceux-ci), à convertir le disque virtuel en un format de téléchargement pris en charge, à le télécharger et à provisionner une instance à partir de l'image téléchargée. Le mode de firmware est important : un invité installé sous UEFI doit être provisionné pour démarrer UEFI sur la cible, et un invité installé sous BIOS legacy doit démarrer BIOS ; une erreur de correspondance produit une image non amorçable et est la défaillance la plus courante et évitable sur ce parcours.

Le Parcours 1 est inhérentement une coupure hors ligne pour la charge de travail convertie : la source est arrêtée pour prendre un état de disque cohérent, convertie, téléchargée et démarrée sur la cible. Le temps d'arrêt s'étend sur la conversion et le téléchargement, qui évolue avec la taille du disque et la bande passante du lien, il s'agit donc du parcours avec la plus grande et la moins prévisible fenêtre de coupure. C'est le bon parcours pour les charges de travail qui sont modernisées sur la surface Public Cloud, et le mauvais parcours pour un grand domaine que vous souhaitez simplement conserver intact.

2.2 Parcours 2 : Réplication native VMware dans le Private Cloud dédié

Lorsque la cible est le Private Cloud dédié, le VM ne quitte jamais VMware, donc la migration reste à l'intérieur de l'outil VMware-native et la fenêtre de coupure s'effondre. L'outil que IONOS fournit pour cela est VMware Cloud Director Availability (VCDA).

VCDA est une offre de Disaster-Recovery-as-a-Service qui protège les vApps et les machines virtuelles avec une réplication asynchrone, les migre, effectue une bascule automatique et inverse la bascule automatique, déployée entre le vCenter sur site du client et le Private Cloud d'IONOS. Dans un Private Cloud d'IONOS, l'appliance cloud est auto-provisionnée, et le client déploie une appliance de réplication sur site correspondante dans le vCenter local ; les deux sont ensuite appariées. La version déployée est VCDA 4.7.x. L'appliance sur site atteint l'appliance cloud via le IP public du Private Cloud sur le port TCP 55443. Commercialement, c'est la propriété décisive : seuls les VM protégés sont facturés, à 50 EUR par VM par mois pour la protection VCDA, et la fonctionnalité de migration elle-même est gratuite. Un grand domaine peut donc être migré avec VCDA sans frais de migration par VM, en ne payant que pour les VM qu'il conserve sous protection DR continue par la suite.

Le modèle de réplication est ce qui rend la fenêtre de coupure courte. VCDA réplique de manière asynchrone tandis que la source continue de s'exécuter, donc les données sont mises en cache sur la cible avant toute interruption. La coupure est une bascule automatique : la source est mise en veille, la dernière delta réplique, et le VM est mis sous tension sur le site Private Cloud d'IONOS. Puisque VCDA effectue également une bascule automatique inverse, la coupure a un rollback défini : si la validation échoue, échouer le VM à nouveau sur le site sur site toujours intact. C'est la raison la plus importante pour laquelle un grand domaine VMware cible le Private Cloud plutôt que le parcours de conversion : les VM restent intactes, la fenêtre de coupure par VM est de quelques minutes plutôt que d'heures, et le rollback est intégré dans le même outil.

Deux points de réseau régissent la propreté de l'atterrissage de la coupure :

• Extension de la couche 2. Pour permettre aux VM migrées de conserver leurs adresses IP existantes pendant une coupure progressive, NSX-T fournit une extension L2 VPN, 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, donc un segment étendu permet à une VM migrée de se situer sur le même domaine de diffusion qu'elle avait sur site tandis que ses pairs sont encore en cours de déplacement. C'est ce qui évite de réadresser chaque VM le premier jour et permet à une dépendance Cluster de se déplacer par étapes.
• Mobilité intra-Cluster uniquement. Une fois que les VM sont 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 drainer un hôte). vMotion est uniquement intra-Cluster. Ce n'est pas un mécanisme de migration de site croisé et ne déplace pas une VM en cours d'exécution d'un site sur site sans interruption ; ce mouvement de site croisé est l'occupation de VCDA, et c'est une opération de réplication, puis de bascule automatique, et non un déplacement en direct de site croisé. Ne concevez pas une coupure autour du déplacement de VM en cours d'exécution entre les sites sans interruption ; cette capacité n'est pas présente.

2.3 Parcours 3 : Sauvegarde et restauration

Le troisième parcours traite la migration comme une récupération : sauvegarder la charge de travail à partir de la source et la restaurer sur la cible. C'est le plus lent pour la coupure parce qu'il est séquentiel (une sauvegarde complète, puis une restauration complète) et hors ligne pour la durée, mais c'est le plus universellement applicable et ne nécessite pas de lien 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 n'est justifié : des serveurs à faible taux de modification, des systèmes d'archivage ou tout ce qui nécessite une longue fenêtre de maintenance et où la simplicité opérationnelle l'emporte sur la vitesse de coupure. C'est également le recours naturel lorsque une conversion de parcours 1 s'avère non amorçable et que le calendrier ne permet pas une deuxième tentative.

2.4 Choix entre les parcours

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

La règle qui suit : une VM VM destinée à un VMware dédié prend le Parcours 2 par défaut, car c'est le seul parcours qui garde la VM intacte et offre une coupure courte et réversible. Une VM VM étant modernisée sur la surface Public Cloud prend le Parcours 1 et accepte le travail de conversion et la fenêtre plus longue. Le Parcours 3 est le recours pour la longue queue où aucun parcours spécialisé ne justifie sa complexité.

3. Planification des vagues et basculement hybride

Un grand domaine n'est jamais basculé d'un seul coup. Il est décomposé en vagues, et l'unité d'une vague est une dépendance Cluster : un ensemble de machines virtuelles qui communiquent entre elles et doivent être déplacées ensemble ou rester accessibles à travers la limite pendant qu'elles sont divisées. Diviser une application bavarde à travers la limite sur site/hybride en milieu de vague transforme chaque appel interne en un aller-retour sur le lien hybride, donc la dépendance Cluster, et non l'individu VM, est l'atome de planification.

Ordonnez les vagues pour retirer les risques tôt et les dépendances de manière propre :

1. Vague pilote : une petite dépendance Cluster autonome et à faible criticité. Son but est de valider le chemin choisi de bout en bout (conversion ou appariement VCDA, le lien hybride, les portes de validation) avant que quelque chose d'important ne soit déplacé.
2. Vagues de dépendance-feuille : les systèmes dont d'autres dépendent, mais qui dépendent de peu eux-mêmes, sont déplacés avant leurs consommateurs, de sorte que les consommateurs ne pointent jamais à travers la limite vers quelque chose qui n'est pas encore arrivé.
3. La vague de base de données : séquencée délibérément par rapport à ses applications (Section 4), car il s'agit d'un dump/restore et donc d'un basculement dur, et non d'un filet.
4. Les vagues d'application et de bordure : les consommateurs sont déplacés une fois que leurs données et dépendances sont déjà en place.

Pendant la migration, le domaine est hybride, donc le lien entre le site sur site et IONOS est porteur de charge, et non accessoire. Deux constructeurs de Module 3 le supportent : un VPN Gateway (IKEv2/WireGuard, HA actif-passif sur un IP public partagé) pour une connectivité de site à site chiffrée, et Cross-Connect pour une interconnexion privée à plus grande bande passante où la migration Volume ou le trafic résiduel transfrontalier le justifie. Pour les machines virtuelles atterrissant dans des Private Cloud dédiés, le segment de niveau NSX-T L2 VPN de la Section 2.2 est l'extension de niveau de segment qui permet à une dépendance Cluster de s'étendre sur les deux sites sans réadressage. Dimensionnez ces liens pour le déplacement de données de migration, et non seulement pour le trafic à l'état stable ; un lien sous-dimensionné est la cause la plus courante d'une vague qui dépasse sa fenêtre.

Chaque vague se termine à une porte de validation avant que le trafic ne soit déplacé : confirmez que la charge de travail démarre, que l'application répond sur ses points de terminaison, que les données sont intactes et à jour, et que les systèmes dépendants peuvent toujours y accéder à travers la limite restante. Seulement après le passage de la porte, vous pouvez déplacer le trafic, généralement en repointant DNS (Unité 3.7), qui dirige les nouvelles connexions vers le point de terminaison migré tandis que l'ancien se vide.

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

• Chemin 2 (VCDA) : le retour de défaillance ramène le VM au site sur site intact. C'est le rollback le plus propre et une autre raison pour laquelle les charges de travail ciblées VMware sont à faible risque.
• Chemin 1 et Chemin 3 : la source VM a été arrêtée mais non détruite, donc le rollback est pour réactiver la source (et re-déplacer DNS). Conservez la source intacte et non modifiée jusqu'à ce que la porte passe ; ne décommissionnez pas une source dans la même vague qui la migre.
• Les instantanés sont un rollback intra-cible, et non un rollback trans-site. Un instantané Snapshot au niveau VM sur la cible (que ce soit un instantané vSphere Snapshot Private Cloud ou un instantané IONOS Block Storage Snapshot) vous permet de restaurer un VM fraîchement migré à son état d'arrivée si une modification post-basculement se passe mal. Il est local à la région et au niveau VM, et, de manière critique, il n'est pas cohérent avec la base de données : un instantané d'une base de données VM en cours d'exécution peut capturer un état de transaction en vol qui ne se restaure pas proprement. Les instantanés protègent l'étape de basculement ; ils ne remplacent pas le dump/restore de la vague de base de données.

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

Les bases de données sont la vague qui brise le plus souvent un plan autrement solide, car l'instinct est de les migrer comme n'importe quel autre VM. Pour les charges de travail qui sont replatformées sur les bases de données gérées par IONOS, cet instinct est erroné : il n'y a pas de basculement natif basé sur la réplication d'une base de données source vers IONOS Managed PostgreSQL, MariaDB, ou MongoDB. Le chemin de migration pris en charge est le dump et la restauration. Vous exportez un dump logique à partir de la source, puis le chargez dans la base de données gérée cible Cluster.

Cela façonne la vague de trois manières. Premièrement, il s'agit d'un basculement dur avec un temps d'arrêt réel : pour prendre un dump cohérent, vous arrêtez les écritures à la source, effectuez un dump, restaurez, et validez avant de reprendre les écritures contre la cible. La fenêtre s'étend avec la taille des données Volume, donc la vague de bases de données obtient la fenêtre de maintenance la plus généreuse dans le plan. Deuxièmement, la restauration 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 commutuez la chaîne de connexion de l'application. Troisièmement, un Snapshot du côté de la cible n'est pas le filet de sécurité ici. Puisque les instantanés ne sont pas cohérents avec la base de données, le dump est l'artefact de migration autoritaire et la source est la restauration autoritaire. Séquencez la vague de bases de données de telle sorte que sa fenêtre dump/restore soit alignée avec, et idéalement précède, le basculement des applications qui en dépendent, afin que ces applications arrivent à 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 rubrique à glance.

Contraintes strictes à respecter dans chaque vague : il n'y a pas d'importation native OVF/OVA (la conversion est ingénieriée) ; vMotion est uniquement intra-Cluster et n'est pas un déplacement inter-sites ; la migration de base de données se fait uniquement par dump/restore ; et les instantanés sont au niveau VM, locaux à la région, et ne sont pas cohérents avec la base de données. Pour FinCorp, le grand parc VMware se résout de manière propre : la majeure partie du parc est réhébergée dans des serveurs dédiés Private Cloud via VCDA (machines virtuelles entières, migration gratuite, annulation de basculement, NSX-T L2 VPN pour maintenir les adresses stables tout au long des vagues progressives), les bases de données prévues pour les services gérés sont remises à niveau via dump/restore dans leur propre vague, et seuls les workloads explicitement modernisés prennent le chemin de conversion d'image sur la surface Public Cloud.

Résumé

La migration vers IONOS Cloud est conçue, et non importée : sans importation native OVF/OVA, l'architecture choisit l'un des trois chemins honnêtes par charge de travail (conversion d'image et téléchargement sur la surface KVM Public Cloud, réplication VCDA dans des VMware dédiés, ou sauvegarde/restore), les séquençant par dépendance Cluster en vagues sur un lien hybride dimensionné, et contrôlant chaque vague avec une validation et un rollback spécifique au chemin. La vague de base de données est sa propre coupure dure par dump et restore, et les instantanés sont un filet de sécurité au niveau VM pour l'étape de coupure plutôt qu'un substitut à celle-ci.

Points clés :

• Il n'y a pas d'importation native OVF/OVA ; la migration est conçue par charge de travail, et la plateforme cible (VMware vs KVM) sélectionne le chemin.
• VCDA 4.7.x est le chemin natif VMware dans des Private Cloud dédiés : réplication asynchrone, migration gratuite, basculement et rebasculement, avec seulement des VM protégées facturées à 50 EUR par VM par mois ; l'appliance cloud est accessible sur TCP 55443.
• NSX-T L2 VPN étend un segment de couche 2 sur des sites afin que les vagues phasées conservent leurs adresses IP ; vMotion est intra-Cluster uniquement et jamais un déplacement en direct entre sites.
• Le chemin de conversion d'image nécessite des pilotes KVM VirtIO et un firmware UEFI/BIOS correspondant, et constitue une coupure hors ligne dimensionnée par la taille du disque et la bande passante du lien.
• Les bases de données migrent par dump et restore avec une fenêtre de coupure dure ; la source reste autoritaire jusqu'à ce que la cible valide, et les instantanés ne sont pas cohérents avec la base de données.

Terminologie importante :

• VCDA (VMware Cloud Director Availability) : l'outil DRaaS natif VMware que IONOS fournit pour la réplication, la migration, le basculement et le rebasculement de VM entre vCenter sur site et IONOS Private Cloud ; version 4.7.x, migration gratuite, protection par VM facturée séparément.
• NSX-T L2 VPN : une extension de couche 2 qui étend un segment NSX entre des sites afin que les VM migrées conservent leurs adresses pendant une coupure phasée.
• Disposition : la décision par charge de travail (rehost, replatform, refactor) qui sélectionne le chemin de migration d'infrastructure.
• Vague : une dépendance Cluster de charges de travail migrées ensemble, avec une porte de validation et un rollback défini à sa fin.

Lecture supplémentaire

• Unité 4.4 : Private Cloud (Serveurs dédiés VMware) - la plateforme cible pour le chemin de migration natif VMware
• Unité 5.3 : Bases de données relationnelles - modes de réplication et le chemin de migration dump/restore pour la vague de bases de données
• Unité 3.6 : Connectivité hybride - VPN Gateway et Cross-Connect, les liens qui assurent la coupure hybride
• Unité 7.1 : Résilience et continuité des activités - basculement DNS orchestré par le client et les stratégies de récupération sur lesquelles cela se base