Einheit 7.4: Migration und Hybrid-Übernahme

Einführung

Die Migration ist die Einheit, in der die Ehrlichkeit der Plattform am meisten zählt, da die größte Quelle des Projektrisikos eine angenommene, aber nicht vorhandene Fähigkeit ist. IONOS Cloud verfügt über keinen nativen OVF/OVA-Import-Assistenten: Sie können nicht einfach eine Konsole auf eine vSphere-Exportierung zeigen und erwarten, dass eine laufende IONOS-Instanz erscheint. Die Migration wird daher konstruiert und nicht importiert, und die Konstruktionsarbeit besteht darin, den richtigen konstruierten Pfad pro Workload auszuwählen und diese Pfade so zu sequenzieren, dass das Unternehmen nie länger als vereinbart offline ist.

Diese Einheit konzentriert sich auf FinCorp, das deutsche Finanzdienstleistungsunternehmen, das einen großen VMware-Bestand unter GDPR- und BSI-Vorschriften besitzt. Der Bestand ist der größte einzelne Einsatz von dedizierten Private Cloud im gesamten Kurs, sodass die Migrationskonstruktion direkt darauf basiert: Wenn das Ziel dedizierte VMware-Instanzen sind, kann FinCorp die virtuellen Maschinen (VMs) unverändert lassen und VMware-native Werkzeuge verwenden; wenn das Ziel die Standard-IONOS-Public Cloud-Oberfläche ist, müssen die gleichen VMs konvertiert werden. Die richtige Entscheidung bei dieser Aufteilung, Workload für Workload, ist die Architektur.

1. Der Disposition-Rahmen, Ehrlich Angewendet

Bevor Sie ein Werkzeug auswählen, klassifizieren Sie jedes Workload anhand dessen, was Sie ändern möchten. Der Disposition-Rahmen (das "R"-Modell) nennt die realistischen Optionen für ein Anwesen dieser Größe. Die ehrliche Version ist auf drei Optionen beschränkt, da die anderen (beibehalten, außer Betrieb nehmen, erneut kaufen) Entscheidungen sind, die Workload überhaupt nicht zu migrieren:

• Rehost ("lift and shift"): Verschieben Sie das Workload unverändert, mit dem gleichen Betriebssystem und der gleichen Anwendung, auf die Ziel-Infrastruktur. Schnellster Weg, geringstes Anwendungsrisiko, kein Modernisierungsvorteil.
• Replatform ("lift and reshape"): Behalten Sie die Anwendung bei, aber ersetzen Sie eine zugrunde liegende Komponente durch eine gemanagte Äquivalent, zum Beispiel indem Sie eine selbst-Managed PostgreSQL-VM auf Managed PostgreSQL verschieben. Mäßiger Aufwand, entfernt operativen Aufwand, aber führt einen Daten-Migrations-Schritt ein.
• Refaktor: Ändern Sie die Anwendung selbst, zum Beispiel indem Sie einen Monolithen auf Managed Kubernetes zerlegen. Höchster Aufwand und Risiko, auf ein eigenes Programm verzögert, anstatt in eine Umstellungs-Welle einbezogen zu werden.

Die Disposition-Entscheidung wählt den Infrastruktur-Pfad aus, und die einzige tragende Gabelung ist die Ziel-Plattform. Ein Rehost in dedizierte Private Cloud hält die VM ganz und VMware-nativ, so dass es die VMware-Replikations-Tooling verwenden kann. Ein Rehost auf die Standard-IONOS-Public Cloud-Oberfläche (Compute Engine) überquert eine Hypervisor-Grenze: Private Cloud läuft VMware ESXi, während die Public Cloud-Produktfamilie ein anderes, KVM-basiertes Substrat läuft, und die beiden Familien sind nicht austauschbar. Diese Grenze, nicht eine Vorliebe, ist der Grund, warum einige Rehosts ein Image-Konvertierungs-Job und andere ein Replikations-Job sind.

Ein Replatform trägt immer einen Daten-Schritt, den der Infrastruktur-Pfad nicht abdeckt. Die Konvertierung eines Datenbank-VM-Disk-Images verschiebt die Maschine; es macht IONOS-Managed PostgreSQL nicht dazu, diese Daten zu übernehmen. Die Daten werden separat verschoben, durch Dump und Wiederherstellung (Abschnitt 4). Behandeln Sie jedes Replatform als zwei koordinierte Migrationen: die umgebende Anwendung und die Daten darunter.

2. Die drei Infrastrukturpfade

Jede Disposition wird zu einem von drei konstruierten Pfaden aufgelöst. Sie unterscheiden sich in dem, was erhalten bleibt, welches Tool die Bytes überträgt und wie viel Downtime der Umstellung kostet.

2.1 Pfad 1: Bildkonvertierung und Upload

Dies ist der Pfad, wenn das Ziel die Standard-IONOS Public Cloud-Oberfläche ist und die VM die VMware-zu-KVM-Grenze überqueren muss. Es gibt keine native OVF/OVA-Importierung, daher wird die VM in ein bootfähiges Bild konvertiert und hochgeladen, dann als IONOS-Instanz bereitgestellt.

Die nicht verhandelbare technische Anforderung ist der Gast-Treiber-Satz. IONOS Public Cloud-Instanzen booten auf KVM und erfordern KVM-VirtIO-Treiber; ein Bild, das nur VMware-Paravirtual-Treiber enthält, bootet nicht korrekt oder läuft ohne Festplatten- und Netzwerkleistung. Für Windows-Gäste stellt IONOS ein ISO-Bild bereit, das die relevanten VirtIO-Treiber enthält, das Sie als CD-ROM-Laufwerk einhängen und vor oder während der Umstellung installieren können. Die praktische Sequenz besteht darin, VirtIO-Treiber in die Quell-VM zu installieren, während sie noch auf VMware läuft (damit das konvertierte Bild sie bereits enthält), die virtuelle Festplatte in ein unterstütztes Upload-Format zu konvertieren, es hochzuladen und eine Instanz aus dem hochgeladenen Bild bereitzustellen. Der Firmware-Modus ist wichtig: Ein Gast, der unter UEFI installiert wurde, muss auf dem Ziel auf UEFI booten, und ein Gast, der unter Legacy-BIOS installiert wurde, muss auf BIOS booten; eine Fehlkonfiguration ergibt ein nicht bootfähiges Bild und ist der häufigste vermeidbare Fehler auf diesem Pfad.

Pfad 1 ist von Natur aus eine Offline-Umstellung für die konvertierte Workload: Die Quelle wird heruntergefahren, um einen konsistenten Festplattenzustand zu übernehmen, konvertiert, hochgeladen und auf dem Ziel gestartet. Die Downtime umfasst die Konvertierung und den Upload, die sich mit der Festplattengröße und der Link-Bandbreite skalieren, sodass es der Pfad mit dem größten und am wenigsten vorhersehbaren Umstellungsfenster ist. Es ist der richtige Pfad für Workloads, die auf die Public Cloud-Oberfläche modernisiert werden sollen, und der falsche Pfad für ein großes Anwesen, das Sie einfach als Ganzes erhalten möchten.

2.2 Pfad 2: VMware-Native Replikation in dediziertes Private Cloud

Wenn das Ziel dediziertes Private Cloud ist, verlässt die VM nie VMware, sodass die Migration innerhalb von VMware-nativen Tooling bleibt und das Umstellungsfenster zusammenbricht. Das Tool, das IONOS für diesen Zweck 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, migriert, Failover durchführt und Failover rückgängig macht, das zwischen dem Kunden-vCenter und dem IONOS-Private Cloud bereitgestellt wird. In einem IONOS-Private Cloud wird die Cloud-Seite-Appliance automatisch bereitgestellt, und der Kunde bereitstellt eine entsprechende On-Premises-Replikations-Appliance im lokalen vCenter; die beiden werden dann gepaart. Die bereitgestellte Version ist VCDA 4.7.x. Die On-Premises-Appliance erreicht die Cloud-Appliance über die öffentliche IP des Private Cloud auf TCP-Port 55443. Kommerziell ist dies die entscheidende Eigenschaft: Nur geschützte VMs werden berechnet, zu 50 EUR pro VM pro Monat für VCDA-Schutz, und die Migration selbst ist kostenlos. Ein großes Anwesen kann daher mit VCDA migriert werden, ohne dass pro VM eine Migrationsgebühr anfällt, und nur für VMs, die danach weiterhin unter DR-Schutz stehen, wird eine Gebühr erhoben.

Das Replikationsmodell ist es, was das Umstellungsfenster kurz macht. VCDA repliziert asynchron, während die Quelle weiterhin läuft, sodass die Daten auf dem Ziel vor jeder Ausfallzeit gestaged werden. Die Umstellung ist ein Failover: Die Quelle wird stillgelegt, die endgültige Differenz repliziert und die VM wird am IONOS-Private Cloud-Standort gestartet. Da VCDA auch ein Reverse-Failover durchführt, hat die Umstellung eine definierte Rückgängigstellung: Wenn die Validierung fehlschlägt, kann die VM auf die noch intakte On-Premises-Seite zurückgesetzt werden. Dies ist der wichtigste Grund, warum ein großes VMware-Anwesen auf Private Cloud und nicht auf den Konvertierungspfad abzielt: Die VMs bleiben unverändert, das Umstellungsfenster pro VM beträgt nur noch Minuten anstelle von Stunden, und die Rückgängigstellung ist in das gleiche Tool integriert.

Zwei Netzwerkpunkte bestimmen, wie sauber die Umstellung abläuft:

• Layer-2-Erweiterung. Um migrierten VMs ihre bestehenden IP-Adressen während einer phasenweisen Umstellung beizubehalten, bietet NSX-T eine L2-VPN, die ein Layer-2-Segment zwischen dem On-Premises-Netzwerk und einem NSX-Segment im Private Cloud erstreckt. NSX-Segmente sind virtuelle Layer-2-Domänen, sodass ein erweitertes Segment es einer migrierten VM ermöglicht, auf der gleichen Broadcast-Domäne zu sitzen, die sie On-Premises hatte, während ihre Peers noch verschoben werden. Dies vermeidet die Neukonfiguration jeder VM am ersten Tag und ermöglicht es einer Abhängigkeit, Cluster, in Stufen zu migrieren.
• In-Cluster-Mobilität nur. Sobald VMs im Private Cloud laufen, kann vMotion sie live zwischen Hosts innerhalb des Cluster (zum Beispiel, um die Last zu balancieren oder einen Host zu entlasten) verschieben. vMotion ist nur innerhalb des Cluster möglich. Es ist kein Mechanismus für die Migration zwischen Standorten und verschiebt keine laufende VM von On-Premises in die IONOS; diese Standortüberschreitende Bewegung ist VCDA's Aufgabe, und es handelt sich um eine Replikation-und-Failover-Operation, nicht um eine Live-Standortüberschreitung. Entwerfen Sie keine Umstellung, die auf der Verschiebung laufender VMs zwischen Standorten ohne Ausfallzeit basiert; 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. Es ist der langsamste, um die Umstellung durchzuführen, da es sequenziell (eine vollständige Sicherung, dann eine vollständige Wiederherstellung) und offline für die Dauer ist, aber es ist der universell anwendbarste und benötigt keine direkte Verbindung zwischen den Standorten. Verwenden Sie es für Workloads, bei denen weder ein sauberer VMware-Replikationspfad noch eine Bildkonvertierung gerechtfertigt ist: Server mit geringer Änderungsrate, Archivsysteme oder alles, bei dem ein langer Wartungsfenster akzeptabel ist und die betriebliche Einfachheit Vorrang vor der Umstellungsgeschwindigkeit hat. Es ist auch der natürliche Rückfall, wenn ein Pfad-1-Konvertierung nicht bootfähig ist und der Zeitplan keinen zweiten Versuch zulässt.

2.4 Auswahl zwischen den Pfaden

Das Folgende vergleicht die drei Pfade in den Dimensionen, die tatsächlich die Entscheidung beeinflussen.

Die Regel, die folgt: Eine VM, die auf dediziertes VMware abzielt, nimmt Pfad 2 standardmäßig, da es der einzige Pfad ist, der die VM unverändert lässt und ein kurzes, umkehrbares Umstellungsfenster bietet. Eine VM, die auf die Public Cloud-Oberfläche modernisiert wird, nimmt Pfad 1 und akzeptiert die Konvertierungsarbeit und das längere Fenster. Pfad 3 ist der Rückfall für den langen Schwanz, bei dem keiner der speziellen Pfade seine Komplexität rechtfertigt.

3. Wellenplanung und Hybrid-Übernahme

Ein großes Anwesen wird nie auf einmal übernommen. Es wird in Wellen unterteilt, und die Einheit einer Welle ist eine Abhängigkeit Cluster: eine Menge von virtuellen Maschinen, die miteinander kommunizieren und zusammen verschoben oder über die Grenze hinweg erreichbar bleiben müssen, während sie geteilt werden. Das Teilen einer kommunikativen Anwendung über die Grenze zwischen dem lokalen Rechenzentrum und der Cloud während einer Welle verwandelt jeden internen Aufruf in eine Rundreise über den Hybrid-Link, sodass die Abhängigkeit Cluster, nicht die einzelne VM, die Planungsatom ist.

Ordnen Sie die Wellen, um das Risiko früh zu mindern und die Abhängigkeiten sauber zu beenden:

1. Pilotwelle: eine kleine, selbstenthaltene, niedrigkritische Abhängigkeit Cluster. Ihr Zweck ist es, den gewählten Pfad von Anfang bis Ende zu validieren (Konvertierung oder VCDA-Paarung, Hybrid-Link, Validierungstore), bevor etwas Wichtiges verschoben wird.
2. Abhängigkeits-Blatt-Wellen: Systeme, die andere Systeme abhängig sind, aber selbst von wenig abhängig sind, werden vor ihren Konsumenten verschoben, sodass die Konsumenten nie über die Grenze hinweg auf etwas zeigen, das noch nicht angekommen ist.
3. Die Datenbankwelle: sequenziell relativ zu ihren Anwendungen (Abschnitt 4), da es sich um ein Dump/Restore handelt und daher ein harter Übergang und kein allmählicher Übergang ist.
4. Die Anwendungs- und Rand-Wellen: die Konsumenten, die verschoben werden, sobald ihre Daten und Abhängigkeiten bereits vorhanden sind.

Während der Migration ist das Anwesen hybrid, sodass der Link zwischen dem lokalen Rechenzentrum und IONOS lasttragend und nicht nebensächlich ist. Zwei Konstrukte aus Modul 3 tragen es: ein VPN Gateway (IKEv2/WireGuard, aktives-passives Hochverfügbarkeit auf einem gemeinsamen öffentlichen IP) für verschlüsselte Site-to-Site-Konnektivität und Cross-Connect für eine höhere Bandbreite private Interconnect, wenn die Migration Volume oder der verbleibende grenzüberschreitende Datenverkehr es rechtfertigt. Für virtuelle Maschinen, die in dedizierte Private Cloud gelangen, ist die NSX-T L2 VPN von Abschnitt 2.2 die Segment-Erweiterung, die es einer Abhängigkeit Cluster ermöglicht, beide Standorte ohne Neukonfiguration zu umfassen. Dimensionieren Sie diese Links für die Datenbewegung der Migration, nicht nur für den regulären Datenverkehr; ein unterschätzter Link ist die häufigste Ursache dafür, dass eine Welle ihr Zeitfenster überläuft.

Jede Welle endet an einem Validierungstor vor dem Datenverkehr verschoben wird: Bestätigen Sie, dass die Workload bootet, die Anwendung auf ihren Endpunkten antwortet, die Daten intakt und aktuell sind und abhängige Systeme sie immer noch über die verbleibende Grenze hinweg erreichen können. Erst nachdem das Tor erfolgreich ist, schalten Sie den Datenverkehr um, typischerweise durch Umleiten von DNS (Einheit 3.7), das neue Verbindungen zum migrierten Endpunkt leitet, während der alte abläuft.

Wenn ein Tor fehlschlägt, unterscheidet sich die Rollback-Position je nach Pfad und muss im Voraus geplant werden:

• Pfad 2 (VCDA): ein umgekehrter Failover kehrt die VM zum intakten lokalen Rechenzentrum zurück. Dies ist die sauberste Rollback und ein weiterer Grund, warum VMware-Ziel-Workloads das geringste Risiko haben.
• Pfad 1 und Pfad 3: die Quell-VM wurde heruntergefahren, aber nicht zerstört, sodass die Rollback auf das erneute Hochfahren der Quelle zurückgeht (und erneutes Umleiten von DNS). Halten Sie die Quelle intakt und unverändert, bis das Tor erfolgreich ist; decommissionieren Sie keine Quelle in der gleichen Welle, die sie migriert.
• Snapshots sind eine Rollback innerhalb des Ziels, nicht eine zwischen den Standorten. Ein VM-Level-Snapshot auf dem Ziel (entweder ein Private Cloud vSphere Snapshot oder ein IONOS Block Storage Snapshot) ermöglicht es Ihnen, eine frisch migrierte VM auf ihren Zustand vor dem Übergang zurückzusetzen, wenn eine Änderung nach dem Übergang schiefgeht. Es ist region-lokal und VM-Level, und kritisch ist es nicht database-konsistent: ein Snapshot einer laufenden Datenbank-VM kann einen in-flight-Transaktionszustand erfassen, der sich nicht sauber wiederherstellt. Snapshots schützen den Übergangsschritt; sie ersetzen die Dump/Restore der Datenbankwelle nicht.

4. Die Datenbankwelle: Dump und Wiederherstellung

Datenbanken sind die Welle, die am häufigsten einen ansonsten solide geplanten Prozess durchbricht, weil der Instinkt ist, sie wie jedes andere Produkt zu migrieren. Für Workloads, die auf IONOS gemanagte Datenbanken umgestellt werden, ist dieser Instinkt jedoch falsch: Es gibt keinen nativen, replikationsbasierten Umstieg von einer Quelldatenbank in IONOS VM, Managed PostgreSQL, MariaDB oder MongoDB. Der unterstützte Migrationspfad ist Dump und Wiederherstellung. Sie exportieren einen logischen Dump aus der Quelle und laden ihn dann in die Ziel-gemanagte Cluster.

Dies prägt die Welle auf drei Arten. Erstens ist es ein harter Umstieg mit echtem Ausfall: Um einen konsistenten Dump zu erstellen, stoppen Sie die Schreibvorgänge an der Quelle, dumpen, stellen wieder her und validieren, bevor Sie die Schreibvorgänge gegen die Ziel-Datenbank wieder aufnehmen. Das Fenster skaliert mit den Daten Volume, sodass die Datenbankwelle das großzügigste Wartungsfenster im Plan erhält. Zweitens ist die Rückgängigstellung die Quelle selbst: Halten Sie die Quelldatenbank online und autoritativ, bis die wiederhergestellte Ziel-Datenbank ihre Validierungsschleuse passiert, und schalten Sie dann die Verbindungsz Zeichenfolge der Anwendung um. Drittens ist ein Ziel-seitiger Snapshot hier kein Sicherheitsnetz. Da Snapshots nicht datenbankkonsistent sind, ist der Dump das autoritative Migrationsartefakt und die Quelle ist die autoritative Rückgängigstellung. Sequenzieren Sie die Datenbankwelle so, dass ihr Dump/Wiederherstellungs-Fenster mit dem Umstieg der Anwendungen, die von ihr abhängen, übereinstimmt und idealerweise diesem vorausgeht, sodass diese Anwendungen auf eine bereits bevölkerte und validierte Datenbank treffen.

Entscheidungszusammenfassung

Verwenden Sie die Disposition, um den Infrastrukturpfad auszuwählen, die Zielplattform, um ihn zu bestätigen, und die folgende Tabelle als Übersichtsrubrik.

Harte Einschränkungen, die in jede Welle einbezogen werden müssen: Es gibt keine native OVF/OVA-Importierung (die Konvertierung ist technisch umgesetzt); vMotion ist nur innerhalb von Cluster und keine Standortübergreifende Verschiebung; die Datenbankmigration erfolgt nur durch Dump/Restore; und Snapshots sind auf VM-Ebene, regionale und nicht Datenbank-konsistent. Für FinCorp wird der große VMware-Bestand sauber aufgelöst: Der Großteil des Bestands wird in dedizierte Private Cloud-Server via VCDA (ganze virtuelle Maschinen, kostenlose Migration, Reverse-Failover-Rollback, NSX-T L2 VPN, um die Adressen über phasenweise Wellen hinweg stabil zu halten) rehostet, die für gemanagte Dienste vorgesehenen Datenbanken werden über Dump/Restore in ihrem eigenen Fenster replattformiert, und nur die explizit modernisierten Workloads nehmen den Bildkonvertierungspfad auf die Public Cloud-Oberfläche.

Zusammenfassung

Die Migration in die IONOS Cloud ist konstruiert und nicht importiert: Da es keine native OVF/OVA-Importierung gibt, wählt die Architektur einen von drei ehrlichen Wegen pro Workload (Bildkonvertierung und Upload auf die KVM Public Cloud-Oberfläche, VCDA-Replikation in dedizierte VMware oder Sicherung/Wiederherstellung), sequenziert sie nach Abhängigkeit Cluster in Wellen über einen dimensionierten Hybrid-Link und steuert jede Welle mit Validierung und einem pfadspezifischen Rollback. Die Datenbankwelle ist ein harter Umstellungsprozess durch Dump und Wiederherstellung, und Snapshots sind ein VM-Level-Sicherheitsnetz für den Umstellungsprozess und kein Ersatz dafür.

Wichtige Punkte:

• Es gibt keine native OVF/OVA-Importierung; die Migration ist pro Workload konstruiert, und die Zielplattform (VMware vs KVM) wählt den Weg.
• VCDA 4.7.x ist der VMware-native Pfad in dedizierte Private Cloud: asynchrone Replikation, kostenlose Migration, Failover und Reverse-Failover, wobei nur geschützte VMs mit 50 EUR pro VM pro Monat berechnet werden; das Cloud-Gerät ist über TCP 55443 erreichbar.
• NSX-T L2 VPN erweitert ein Layer-2-Segment über Standorte, sodass phasenweise Wellen ihre IP-Adressen beibehalten; vMotion ist nur innerhalb von Cluster und nie ein Live-Umzug zwischen Standorten.
• Der Bildkonvertierungspfad erfordert KVM VirtIO-Treiber und passende UEFI/BIOS-Firmware und ist ein Offline-Umstellungsprozess, der durch die Größe der Festplatte und die Linkbandbreite skaliert wird.
• Datenbanken migrieren durch Dump und Wiederherstellung mit einem harten Umstellungsfenster; die Quelle bleibt autoritativ, bis das Ziel validiert wird, und Snapshots sind nicht datenbankkonsistent.

Wichtige Begriffe:

• VCDA (VMware Cloud Director Availability): das VMware-native DRaaS-Tool, das IONOS für die Replikation, Migration, Failover und Reverse-Failover von VMs zwischen lokalen vCenter und IONOS Private Cloud bereitstellt; Version 4.7.x, kostenlose Migration, Schutz pro VM separat berechnet.
• NSX-T L2 VPN: eine Layer-2-Erweiterung, die ein NSX-Segment zwischen Standorten erweitert, sodass migrierte VMs ihre Adressen während eines phasenweisen Umstellungsprozesses beibehalten.
• Disposition: die Entscheidung pro Workload (Rehost, Replatform, Refactor), die den Infrastruktur-Migrationspfad auswählt.
• Welle: eine Abhängigkeit Cluster von Workloads, die zusammen migriert werden, mit einem Validierungstor 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/Wiederherstellungs-Migrationspfad für die Datenbankwelle
• Einheit 3.6: Hybrid-Konnektivität - VPN Gateway und Cross-Connect, die Verbindungen, die den Hybrid-Übergang tragen
• Einheit 7.1: Widerstandsfähigkeit und Geschäftskontinuität - kundenseitig orchestriertes DNS-Failover und die Wiederherstellungsstrategien, auf denen dies aufbaut