Einheit 7.4: Migration und Hybrid-Cutover

Einführung

Migration ist die Einheit, in der die Ehrlichkeit der Plattform am meisten zählt, denn die größte Quelle für Projektrisiken ist eine Fähigkeit, die angenommen, aber nicht vorhanden ist. IONOS CLOUD verfügt über keinen nativen OVF/OVA-Import-Assistenten: Sie können eine Konsole nicht einfach auf einen vSphere-Export zeigen und daraufhin eine laufende IONOS CLOUD Instanz erwarten. Migration wird daher konstruiert, nicht importiert, und die Entwurfsarbeit besteht darin, den richtigen konstruierten Pfad pro Workload zu wählen und diese Pfade so zu sequenzieren, dass das Unternehmen nie länger offline ist, als es vereinbart hat.

Diese Einheit basiert auf FinCorp, einem deutschen Finanzdienstleistungsunternehmen, das einen großen VMware-Bestand unter DSGVO- und BSI-Pflichten betreibt. Der Bestand ist die größte einzelne Nutzung von dedizierter Private Cloud im gesamten Kurs, daher stützt sich das Migrationsdesign direkt darauf: Wenn das Ziel dedizierter VMware ist, kann FinCorp VMs als Ganzes beibehalten und VMware-native Werkzeuge nutzen; wenn das Ziel die Standard-IONOS CLOUD Public Cloud-Oberfläche ist, müssen dieselben VMs konvertiert werden. Diese Verzweigung Workload für Workload richtig zu treffen, ist die Architektur.

1. Das Disposition Framework, ehrlich angewendet

Bevor Sie ein Tool auswählen, klassifizieren Sie jede Workload danach, was Sie ändern möchten. Das Disposition Framework (das „R"-Modell) benennt die realistischen Optionen für eine Infrastruktur dieser Größe. Die ehrliche Version ist auf drei Optionen beschränkt, da die anderen (retain, retire, repurchase) Entscheidungen sind, diese Workload überhaupt nicht zu migrieren:

• Rehost („lift and shift"): Verschieben Sie die Workload im Ist-Zustand, mit demselben Betriebssystem und derselben Anwendung, auf die Zielinfrastruktur. Schnellster Weg, geringstes Anwendungsrisiko, kein Modernisierungsnutzen.
• Replatform („lift and reshape"): Behalten Sie die Anwendung bei, ersetzen aber eine zugrunde liegende Komponente durch ein verwaltetes Äquivalent, beispielsweise durch das Verschieben einer selbst verwalteten PostgreSQL-VM auf Managed PostgreSQL. Mäßiger Aufwand, beseitigt operativen Aufwand, führt aber zu einem Datenmigrationsschritt.
• Refactor: Ändern Sie die Anwendung selbst, beispielsweise durch die Zerlegung eines Monolithen auf Managed Kubernetes. Höchster Aufwand und Risiko, wird in ein eigenes Programm verschoben, statt in eine Cutover-Welle integriert zu werden.

Die Dispositionsentscheidung bestimmt den Infrastrukturpfad, und der wichtigste Verzweigungspunkt ist die Zielpattform. Ein Rehost in eine dedizierte Private Cloud hält die VM intakt und VMware-nativ, sodass VMware-Replikatoren verwendet werden können. Ein Rehost auf die Standard-IONOS CLOUD Public Cloud-Oberfläche (Compute Engine) überschreitet eine Hypervisor-Grenze: Private Cloud läuft auf VMware ESXi, während die Public Cloud-Produktfamilie ein anderes, KVM-basiertes Substrat nutzt, und die beiden Familien sind nicht austauschbar. Diese Grenze, nicht eine Präferenz, ist der Grund, warum einige Rehosts eine Bildkonvertierungsaufgabe und andere eine Replikationsaufgabe sind.

Ein Replatform enthält immer einen Datenschritt, den der Infrastrukturpfad nicht abdeckt. Die Konvertierung des Datenträgerbildes einer Datenbank-VM verschiebt die Maschine; sie lässt IONOS CLOUD Managed PostgreSQL diese Daten nicht übernehmen. Die Daten werden separat verschoben, durch Dump und Restore (Abschnitt 4). Behandeln Sie jedes Replatform als zwei koordinierte Migrationen: die umgebende Anwendung und die darunterliegenden Daten.

2. Die drei Infrastrukturpfade

Jede Disposition führt zu einem von drei konzipierten Pfaden. Sie unterscheiden sich darin, was erhalten bleibt, welches Tooling die Daten überträgt und wie viel Ausfallzeit der Wechsel verursacht.

2.1 Pfad 1: Bildkonvertierung und Upload

Dies ist der Pfad, wenn das Ziel die Standard-IONOS CLOUD Public Cloud-Oberfläche ist und die VM die Grenze von VMware zu KVM überschreiten muss. Es gibt keinen nativen OVF/OVA-Import, daher wird die VM in ein startfähiges Image konvertiert und hochgeladen, dann als IONOS CLOUD-Instanz provisioniert.

Die unverzichtbare technische Voraussetzung ist der Satz an Gasttreibern. IONOS CLOUD Public Cloud-Instanzen starten auf KVM und benötigen KVM VirtIO-Treiber; ein Image, das nur die paravirtualisierten Treiber von VMware enthält, startet nicht korrekt oder läuft ohne Disk- und Netzwerkperformance. Für Windows-Gäste stellt IONOS CLOUD ein ISO-Image mit den relevanten VirtIO-Treibern bereit, das als CD-ROM-Laufwerk eingebunden und vor oder während des Wechsels installiert wird. Die praktische Abfolge besteht darin, die VirtIO-Treiber in die Quell-VM zu installieren, während sie noch auf VMware läuft (damit das konvertierte Image sie bereits enthält), die virtuelle Festplatte in ein unterstütztes, uploadfähiges Format zu konvertieren, sie hochzuladen und eine Instanz aus dem hochgeladenen Image zu provisionieren. Der Firmwaremodus ist entscheidend: Ein Gast, der unter UEFI installiert wurde, muss auf dem Ziel mit UEFI gestartet werden, und ein Gast, der unter Legacy BIOS installiert wurde, muss mit BIOS starten; eine Diskrepanz führt zu einem nicht startfähigen Image und ist der häufigste vermeidbare Fehler auf diesem Pfad.

Pfad 1 ist inhärent ein Offline-Wechsel für die konvertierte Workload: Die Quelle wird heruntergefahren, um einen konsistenten Disk-Zustand zu erfassen, konvertiert, hochgeladen und auf dem Ziel gestartet. Die Ausfallzeit umfasst die Konvertierung und den Upload, was sich mit der Disk-Größe und der Link-Bandbreite skaliert, weshalb dies der Pfad mit dem größten und am wenigsten vorhersehbaren Wechselzeitfenster ist. Er ist der richtige Pfad für Workloads, die auf der Public Cloud-Oberfläche modernisiert werden, und der falsche Pfad für einen großen Bestand, den man einfach als Ganzes erhalten möchte.

2.2 Pfad 2: VMware-native Replikation in die dedizierte Private Cloud

Wenn das Ziel die dedizierte Private Cloud ist, verlässt die VM nie VMware, sodass die Migration innerhalb der VMware-nativen Tooling bleibt und das Wechselzeitfenster zusammenfällt. Das Tool, das IONOS CLOUD dafür bereitstellt, ist VMware Cloud Director Availability (VCDA).

VCDA ist ein Disaster-Recovery-as-a-Service-Angebot, das vApps und virtuelle Maschinen mit asynchroner Replikation schützt, sie migriert, Failover durchführt und Failover rückgängig macht, deployed zwischen dem On-Premises-vCenter des Kunden und der IONOS CLOUD Private Cloud. In einer IONOS CLOUD Private Cloud wird die Cloud-seitige Appliance automatisch provisioniert, und der Kunde deployt eine passende On-Premises-Replikationsappliance in das lokale vCenter; die beiden werden dann gekoppelt. Die deployed Version ist VCDA 4.7.x. Die On-Premises-Appliance erreicht die Cloud-Appliance über die öffentliche IP der Private Cloud auf TCP-Port 55443. Kommerziell ist dies die entscheidende Eigenschaft: Nur geschützte VMs werden abgerechnet, zu 50 EUR pro VM pro Monat für VCDA Protection, und die Migrationsfunktion selbst ist kostenlos. Ein großer Bestand kann daher mit VCDA ohne pro-VM-Migrationsgebühr migriert werden, wobei nur für VMs gezahlt wird, die danach unter laufendem DR-Schutz bleiben.

Das Replikationsmodell ist der Grund, warum der Wechsel kurz ausfällt. VCDA repliziert asynchron, während die Quelle weiterläuft, sodass die Daten vor jeder Störung auf dem Ziel vorliegen. Der Wechsel ist ein Failover: Die Quelle wird quiesced, die letzte Delta-Replikation erfolgt, und die VM wird am IONOS CLOUD Private Cloud-Standort gestartet. Da VCDA auch Reverse Failover durchführt, hat der Wechsel einen definierten Rollback: Wenn die Validierung fehlschlägt, wird die VM zum noch intakten On-Premises-Standort zurückgefahren. Dies ist der wichtigste Grund, warum ein großer VMware-Bestand die Private Cloud anstatt des Konvertierungspfads als Ziel wählt: Die VMs bleiben ganz, das pro-VM-Wechselzeitfenster beträgt Minuten statt Stunden, und der Rollback ist in dasselbe Tool integriert.

Zwei Netzwerkaspekte bestimmen, wie sauber der Wechsel gelingt:

• Layer 2-Erweiterung. Um migrierten VMs zu ermöglichen, ihre bestehenden IP-Adressen während eines gestaffelten Wechsels beizubehalten, bietet NSX-T ein L2 VPN, das ein Layer 2-Segment zwischen dem On-Premises-Netzwerk und einem NSX-Segment in der Private Cloud verlängert. NSX-Segmente sind virtuelle Layer 2-Domänen, sodass ein erweitertes Segment eine migrierte VM in derselben Broadcast-Domain positionieren kann, die sie on-premises hatte, während ihre Peers noch verschoben werden. Dies vermeidet die Neuadressierung jeder VM am ersten Tag und ermöglicht es, ein Abhängigkeitscluster in Etappen zu verschieben.
• Nur Intra-Cluster-Mobilität. Sobald VMs in der Private Cloud laufen, kann vMotion sie live zwischen Hosts innerhalb des Clusters verschieben (zum Beispiel, um Last zu verteilen oder einen Host zu leeren). vMotion ist nur intra-cluster. Es ist kein Cross-Site-Migrationsmechanismus und verschiebt keine laufende VM von On-Premises in die IONOS CLOUD; diese Cross-Site-Bewegung ist die Aufgabe von VCDA, und es handelt sich um eine Repliziere-dann-Failover-Operation, nicht um eine live Cross-Site-Bewegung. Planen Sie keinen Wechsel um das Verschieben laufender VMs über Standorte hinweg ohne Ausfallzeit; diese Fähigkeit ist nicht vorhanden.

2.3 Pfad 3: Sicherung und Wiederherstellung

Der dritte Pfad behandelt die Migration als Wiederherstellung: Die Workload wird von der Quelle gesichert und auf dem Ziel wiederhergestellt. Er ist der langsamste beim Wechsel, weil er sequenziell ist (eine vollständige Sicherung, dann eine vollständige Wiederherstellung) und für die Dauer offline ist, aber er ist am universellsten anwendbar und benötigt keine Live-Verbindung zwischen den Standorten. Verwenden Sie ihn für Workloads, bei denen weder ein sauberer VMware-Replikationspfad noch eine Bildkonvertierung gerechtfertigt sind: Server mit niedriger Änderungsrate, Archivsysteme oder alles, bei dem ein langes Wartungsfenster akzeptabel ist und operative Einfachheit die Wechselgeschwindigkeit übertrifft. Es ist auch der natürliche Fallback, wenn sich eine Pfad 1-Konvertierung als nicht startfähig erweist und der Zeitplan keinen zweiten Versuch zulässt.

2.4 Auswahl zwischen den Pfaden

Die folgende Tabelle vergleicht die drei Pfade anhand der Dimensionen, die die Entscheidung tatsächlich steuern.

Die daraus folgende Regel: Eine VM, die zur dedizierten VMware-Infrastruktur bestimmt ist, nimmt standardmäßig Pfad 2, weil es der einzige Pfad ist, der die VM ganz erhält und einen kurzen, reversiblen Wechsel bietet. Eine VM, die auf der Public Cloud-Oberfläche modernisiert wird, nimmt Pfad 1 und akzeptiert die Konvertierungsarbeit und das längere Zeitfenster. Pfad 3 ist der Fallback für den langen Schwanz, bei dem keiner der spezialisierten Pfade seine Komplexität rechtfertigt.

3. Wellenplanung und Hybrid-Cutover

Ein großes Systemumfeld wird nie auf einmal umgestellt. Es wird in Wellen zerlegt, und die Einheit einer Welle ist ein Abhängigkeitscluster: eine Gruppe von VMs, die miteinander kommunizieren und entweder gemeinsam migriert werden müssen oder während der Aufteilung über die Grenze hinweg erreichbar bleiben müssen. Die Aufteilung einer kommunikationsintensiven Anwendung über die Grenze zwischen On-Premises und Cloud mitten in einer Welle verwandelt jeden internen Aufruf in eine Hin- und Rückreise über die Hybridverbindung. Daher ist das Abhängigkeitscluster, nicht die einzelne VM, die Planungseinheit.

Ordnen Sie die Wellen so an, dass Risiken frühzeitig abgebaut und Abhängigkeiten sauber aufgelöst werden:

1. Pilotwelle: ein kleines, eigenständiges Abhängigkeitscluster mit niedriger Kritikalität. Ihr Zweck ist es, den gewählten Pfad von Anfang bis Ende zu validieren (Konvertierung oder VCDA-Paarung, die Hybridverbindung, die Validierungsgates), bevor etwas Wichtiges migriert wird.
2. Abhängigkeits-Blattwellen: Systeme, von denen andere abhängen, die aber selbst kaum Abhängigkeiten haben, werden vor ihren Konsumenten migriert. So zeigen Konsumenten nie über die Grenze hinweg auf etwas, das noch nicht angekommen ist.
3. Die Datenbankwelle: wird bewusst relativ zu ihren Anwendungen sequenziert (Abschnitt 4), da es sich um Dump/Restore handelt und somit um einen harten Cutover, nicht um einen schrittweisen Übergang.
4. Die Anwendungs- und Edge-Wellen: die Konsumenten, die erst dann migriert werden, wenn ihre Daten und Abhängigkeiten bereits an Ort und Stelle sind.

Während der gesamten Migration ist das Systemumfeld hybrid, daher ist die Verbindung zwischen dem On-Premises-Standort und IONOS CLOUD tragend und nicht nur ein Nebenaspekt. Zwei Konstrukte aus Modul 3 tragen sie: ein VPN Gateway (IKEv2/WireGuard, Active-Passive-HA auf einer gemeinsamen öffentlichen IP) für verschlüsselte Site-to-Site-Verbindungen und Cross-Connect für eine privatere Interconnect-Verbindung mit höherer Bandbreite, falls das Migrationsvolumen oder der verbleibende grenzüberschreitende Verkehr dies rechtfertigt. Für VMs, die in dedizierte Private Cloud gelandet sind, ist der NSX-T L2 VPN aus Abschnitt 2.2 die segmentweise Erweiterung, die es einem Abhängigkeitscluster ermöglicht, beide Standorte zu spannen, ohne die Adressierung zu ändern. Dimensionieren Sie diese Verbindungen für die Datenbewegung der Migration, nicht nur für den Normalbetrieb; eine zu klein dimensionierte Verbindung ist die häufigste Ursache dafür, dass eine Welle ihr Zeitfenster überschreitet.

Jede Welle endet an einem Validierungsgate, bevor der Verkehr umgeleitet wird: Stellen Sie sicher, dass die Workload startet, die Anwendung auf ihren Endpunkten antwortet, die Daten intakt und aktuell sind und abhängige Systeme sie über die verbleibende Grenze noch erreichen können. Erst nach dem Bestehen des Gates wird der Verkehr umgeleitet, typischerweise durch das Umstellen von DNS (Einheit 3.7), was neue Verbindungen zum migrierten Endpunkt steuert, während der alte Endpunkt abgewickelt wird.

Falls ein Gate fehlschlägt, unterscheidet sich die Rückrollposition je nach Pfad und muss im Voraus geplant werden:

• Pfad 2 (VCDA): Ein Reverse-Failover bringt die VM auf den intakten On-Premises-Standort zurück. Dies ist der sauberste Rollback und ein weiterer Grund, warum Workloads mit VMware-Ziel das geringste Risiko haben.
• Pfad 1 und Pfad 3: Die Quell-VM wurde heruntergefahren, aber nicht gelöscht, daher besteht der Rollback darin, die Quelle wieder hochzufahren (und DNS erneut umzustellen). Halten Sie die Quelle intakt und unberührt, bis das Gate bestanden ist; stilllegen Sie eine Quelle nicht in derselben Welle, in der sie migriert wird.
• Snapshots sind ein Rollback innerhalb des Ziels, nicht ein Rollback über Standorte hinweg. Ein VM-Ebene-Snapshot am Ziel (sei es ein Private Cloud vSphere Snapshot oder ein IONOS CLOUD Block Storage Snapshot) ermöglicht es, eine frisch migrierte VM in ihren gerade angekommenen Zustand zurückzurollen, falls eine Änderung nach dem Cutover schiefgeht. Er ist regionsspezifisch und auf VM-Ebene, und entscheidend ist, dass er nicht datenbankkonsistent ist: Ein Snapshot einer laufenden Datenbank-VM kann einen in Bearbeitung befindlichen Transaktionszustand erfassen, der sich nicht sauber wiederherstellen lässt. Snapshots schützen den Cutover-Schritt; sie ersetzen nicht das Dump/Restore der Datenbankwelle.

4. Die Datenbankwelle: Dump und Restore

Datenbanken sind die Welle, die einen ansonsten soliden Plan am häufigsten zunichtemacht, da der instinktive Ansatz darin besteht, sie wie jede andere VM zu migrieren. Für Workloads, die auf verwaltete Datenbanken in IONOS CLOUD replattformiert werden, ist dieser Instinkt falsch: Es gibt keinen nativen, replikationsbasierten Cutover von einer Quelldatenbank in IONOS CLOUD Managed PostgreSQL, MariaDB oder MongoDB. Der unterstützte Migrationspfad ist Dump und Restore. Sie exportieren einen logischen Dump von der Quelle und laden ihn anschließend in das Ziel-Verwaltete-Cluster.

Dies formt die Welle auf drei Arten. Erstens handelt es sich um einen harten Cutover mit echtem Ausfallzeitraum: Um einen konsistenten Dump zu erstellen, werden Schreibvorgänge an der Quelle gestoppt, der Dump erstellt, wiederhergestellt und validiert, bevor Schreibvorgänge an das Ziel wieder aufgenommen werden. Das Zeitfenster skaliert mit dem Datenvolumen, weshalb die Datenbankwelle das großzügigste Wartungsfenster im Plan erhält. Zweitens ist der Rollback die Quelle selbst: Die Quelldatenbank bleibt online und autoritativ, bis das wiederhergestellte Ziel seine Validierungsschranke durchläuft. Anschließend wird die Verbindungszeichenfolge der Anwendung umgestellt. Drittens ist ein Snapshot auf der Zielseite hier nicht das Sicherheitsnetz. Da Snapshots nicht datenbankkonsistent sind, ist der Dump das autoritative Migrationsartefakt und die Quelle der autoritative Rollback. Sequenzieren Sie die Datenbankwelle so, dass ihr Dump/Restore-Fenster mit dem Cutover der darauf angewiesenen Anwendungen übereinstimmt und idealerweise diesem vorausgeht, damit diese Anwendungen auf eine Datenbank treffen, die bereits befüllt und validiert ist.

Zusammenfassung der Entscheidung

Verwenden Sie die Disposition, um den Infrastrukturpfad auszuwählen, die Zielplattform, um diesen zu bestätigen, und die folgende Tabelle als übersichtliches Bewertungsschema.

Harte Einschränkungen, die in jede Welle einfließen: Es gibt keinen nativen OVF/OVA-Import (die Konvertierung wird technisch umgesetzt); vMotion ist nur intra-cluster und keine Standortübergreifende Verschiebung; die Datenbankmigration erfolgt ausschließlich per Dump/Restore; und Snapshots sind VM-Ebene, regionlokal und nicht datenbankkonsistent. Für FinCorp löst sich der große VMware-Bestand sauber auf: Der Großteil des Bestands wird per VCDA in die dedizierte Private Cloud rehostet (ganze VMs, kostenlose Migration, Reverse-Failover-Rollback, NSX-T L2 VPN zur Adressstabilisierung über phasenweise Wellen hinweg), die für Managed Services vorgesehenen Datenbanken werden per Dump/Restore in ihrer eigenen, zeitlich abgegrenzten Welle replatformt, und nur die explizit modernisierten Workloads nehmen den Imagekonvertierungspfad auf die Public-Cloud-Oberfläche.

Zusammenfassung

Die Migration in IONOS CLOUD ist ein konstruierter Prozess, keine einfache Importierung: Da kein nativer OVF/OVA-Import vorhanden ist, wählt die Architektur für jede Arbeitslast einen von drei ehrlichen Pfaden (Bilddateikonvertierung und Upload auf die KVM Public Cloud-Oberfläche, VCDA-Replikation in dedizierte VMware-Umgebungen oder Sicherung/Wiederherstellung), ordnet diese nach Abhängigkeitsclustern in Wellen über einer dimensionierten Hybridverbindung an und steuert jede Welle durch Validierung und einen pfadspezifischen Rollback. Die Datenbankwelle ist ein eigenständiger harter Cutover per Dump und Wiederherstellung, und Snapshots sind ein sicherheitsrelevantes Netz auf VM-Ebene für den Cutover-Schritt, aber kein Ersatz dafür.

Wichtige Punkte:

• Es gibt keinen nativen OVF/OVA-Import; die Migration wird pro Arbeitslast konstruiert, und die Zielpattform (VMware vs. KVM) bestimmt den Pfad.
• VCDA 4.7.x ist der VMware-native Pfad in die dedizierte Private Cloud: asynchrone Replikation, kostenlose Migration, Failover und Reverse Failover, wobei nur geschützte VMs mit 50 EUR pro VM und Monat abgerechnet werden; das Cloud-Appliance wird über TCP 55443 erreicht.
• NSX-T L2 VPN erweitert ein Layer-2-Segment über mehrere Standorte hinweg, sodass gestaffelte Wellen ihre IP-Adressen beibehalten; vMotion ist nur intra-cluster möglich und niemals ein Live-Transfer zwischen Standorten.
• Der Pfad der Bilddateikonvertierung erfordert KVM VirtIO-Treiber und passende UEFI/BIOS-Firmware und ist ein Offline-Cutover, der sich nach Festplattengröße und Linkbandbreite skaliert.
• Datenbanken werden per Dump und Wiederherstellung mit einem harten Cutover-Fenster migriert; die Quelle bleibt autoritativ, bis das Ziel validiert ist, und Snapshots sind nicht datenbankkonsistent.

Wichtige Begriffe:

• VCDA (VMware Cloud Director Availability): Das VMware-native DRaaS-Tool, das IONOS CLOUD bereitstellt, um VMs zwischen dem On-Premises-vCenter und IONOS CLOUD Private Cloud zu replizieren, zu migrieren, zu failovern und das Failover rückgängig zu machen; Version 4.7.x, kostenlose Migration, pro-VM-Schutz wird separat abgerechnet.
• NSX-T L2 VPN: Eine Layer-2-Erweiterung, die ein NSX-Segment zwischen Standorten dehnt, sodass migrierte VMs ihre Adressen während eines gestaffelten Cutovers beibehalten.
• Disposition: Die pro Arbeitslast getroffene Entscheidung (Rehosting, Replatforming, Refactoring), die den Infrastruktur-Migrationspfad auswählt.
• Welle: Ein Abhängigkeitscluster von Arbeitslasten, die zusammen migriert werden, mit einem Validierungsgate und einem definierten Rollback am Ende.

Weitere Lektüre

• Einheit 4.4: Private Cloud (Dedicated VMware) - die Zielplattform für den VMware-nativen Migrationspfad
• Einheit 5.3: Relationale Datenbanken - Replikationsmodi und der Dump/Restore-Migrationspfad für die Datenbankwelle
• Einheit 3.6: Hybrid Connectivity - VPN Gateway und Cross-Connect, die Verbindungen, die den hybriden Cutover tragen
• Einheit 7.1: Resilience and Business Continuity - vom Kunden orchestriertes DNS-Failover und die Wiederherstellungsstrategien, auf denen dies aufbaut