Migrieren von Workloads zu Azure-VMware-Lösung

Dieser Artikel enthält Anleitungen, mit denen Entscheidungsträger ihre Migrationsstrategie für Azure-VMware-Lösung definieren können, einschließlich Planung, Ausführung und Außerbetriebsetzungsphase.

Diagramm, das den Microsoft Cloud Adoption Framework Prozess für die einführung von Azure-VMware-Lösung zeigt.

Azure-VMware-Lösung bietet einen strukturierten Pfad zum Migrieren von VMware-basierten Workloads zu Azure mit minimaler Anwendungsänderung. Der Erfolg hängt von mehr als dem Verschieben virtueller Computer ab. Organisationen benötigen klare Migrationsrichtlinien, Arbeitsauslastungsbewertungskriterien, Validierungsstandards und Ausführungskontrollen, die Risiken reduzieren, die Betriebskontinuität beibehalten und langfristige Plattformziele unterstützen.

Empfehlung: Definieren Sie Ihre Migrationsstrategie, Den Workload-Bewertungsansatz, migrationssequenz und Validierungsanforderungen, bevor Sie Workloads zu Azure-VMware-Lösung migrieren.

1. Migrationsplanung

Bevor Sie etwas entwerfen, erstellen Sie ein klares Bild davon, was Sie migrieren, in welcher Reihenfolge und warum. Verwenden Sie die Cloud Adoption Framework Plan-Methodik, um Ihre Immobilie zu bewerten. Azure-VMware-Lösung passt am besten zu einem Rehost-Ansatz, bei dem Sie minimale Unterbrechungen und keine kurzfristige Modernisierung benötigen. Es ist nicht für jede Anwendung der richtige Ort, und in der Planungsphase treffen Sie diese Entscheidung.

1.1 Ermittlung und Inventar

Azure Migrate scannt Ihre lokale vSphere-Umgebung und erstellt einen Bestand an virtuellen Computern, deren Ressourcennutzung und deren Abhängigkeiten. Diese Daten informieren sowohl über die Größenanpassung (wie viele Hosts und welchen Hosttyp) als auch über die Wellenplanung (welche Workloads sich zusammen bewegen). Azure Migrate führt den Wechsel zu Azure-VMware-Lösung nicht durch. Es gibt Ihnen die Nachweise für die Größe und Reihenfolge des Projekts.

1.2 Migrationsstrategie

Azure-VMware-Lösung unterstützt in erster Linie den Rehost-Ansatz. Anwendungen, die ein Refactoring oder eine Neuausrichtung der Architektur benötigen, sind mit nativen Azure-Computingdiensten möglicherweise besser bedient. Notieren Sie diese Entscheidungen, sodass der Plan bewusste Entscheidungen anstelle von Standardeinstellungen widerspiegelt. Siehe Auswählen einer Cloudmigrationsstrategie.

1.3 Workload-Bewertung

Nicht jede Arbeitsauslastung ist ein gleichermaßen geeigneter Kandidat für Azure-VMware-Lösung. Bevor Sie Arbeitslasten den Migrationswellen zuordnen, bewerten Sie ihre technischen Anforderungen, betrieblichen Abhängigkeiten und ihre Plattformeignung. Mithilfe einer strukturierten Bewertung können Sie Risiken frühzeitig erkennen, die Eignung überprüfen und sicherstellen, dass Migrationspläne geschäftsprioritäten und keine Annahmen widerspiegeln.

1.3.1 Anforderungen

Bevor Sie einer Migrationswelle eine Arbeitsauslastung zuweisen, bewerten Sie die technischen, betrieblichen und geschäftlichen Anforderungen, die ihren Erfolg auf Azure-VMware-Lösung beeinflussen. Diese Bewertung hilft Ihnen, die Plattformeignung zu ermitteln, potenzielle Migrationsprobleme zu identifizieren und die erforderlichen Informationen für Größen-, Sequenzierungs- und Bereitschaftsentscheidungen bereitzustellen. Konzentrieren Sie sich bei der Bewertung der einzelnen Arbeitslasten auf Folgendes:

  • Leistungsanforderungen: Grundlegendes zu CPU-, Arbeitsspeicher-, Speicher-IOPS- und Netzwerkdurchsatzanforderungen. Ordnen Sie diese Anforderungen den Azure-VMware-Lösung Host-SKUs und vSAN-Speicherrichtlinien zu, einschließlich der RAID-Konfiguration und der FTT-Einstellungen (Failures to Tolerate).

  • Anwendungsabhängigkeiten: Ermitteln Sie, mit welchen Systemen die einzelnen Arbeitsauslastungen kommunizieren. Abhängigkeiten bestimmen die Planung ihrer Migrationswelle und ob abhängige Systeme zusammenkommen müssen.

  • Kompatibilitätsanforderungen: Vergewissern Sie sich, dass Gastbetriebssysteme und Drittanbietersoftware auf Azure-VMware-Lösung unterstützt werden. Die meisten Workloads, die lokal auf vSphere ausgeführt werden, laufen auf Azure-VMware-Lösung ohne Anpassungen, aber verlassen Sie sich nicht auf Annahmen, sondern validieren Sie dies, und stellen Sie sicher, dass Sie Ihre Rollbackstrategie für problematische Migrationen testen.

  • Netzwerkanforderungen: Dokumentieren Sie die Netzwerksegmente, IP-Adressen, DNS-Konfigurationen und Firewallregeln, die für jede Workload erforderlich sind. Identifizieren Sie Latenz-sensible Workloads, und stellen Sie sicher, dass die Netzwerkarchitektur optimiert ist, um ihre Anforderungen zu unterstützen.

1.3.2 Arbeitsauslastungsbehandlung

Die Workloadbewertung gibt an, was eine Workload benötigt. Die Behandlung der Workload bestimmt, welche Aktion ausgeführt werden soll. Entscheidungsträger sollten bewerten, ob jede Anwendung zu Azure-VMware-Lösung gehört, ob sie lokal bleiben soll oder ob Teile der Anwendung besser von Azure nativen Diensten bedient werden. Legen Sie für jede Arbeitsauslastung Folgendes fest:

  • Gibt an, ob die Workload dorthin gehört. Workloads, die bereits gut auf vSphere ausgeführt werden, sind natürliche Kandidaten, insbesondere solche ohne kurzfristigen Modernisierungsplan. Für eine Workload, die zur Außerbetriebnahme oder zum Ersatz durch eine SaaS-Lösung vorgesehen ist, sollten Sie abwägen, ob eine Migration einen Mehrwert bietet oder ob sie bis zum Ende ihrer Lebensdauer am bestehenden Ort verbleiben sollte.

  • Gibt an, ob jede Ebene dorthin gehört. Eine Workload hat häufig mehr als eine Ebene, z. B. ein Web-Front-End und eine Datenbank. Sie können die virtuellen Anwendungscomputer auf Azure-VMware-Lösung ausführen und diese mit Azure nativen Datendiensten wie Azure SQL-Datenbank verbinden. Diese Konfiguration bietet Ihnen verwaltete Datenbankvorteile neben Ihren VMware-Workloads und reduziert Ihre VMware-Host- und Lizenzkosten.

1.4 Migrationsbereitschaft

Legen Sie die Mindestanforderungen an Betrieb, Leistung, Sicherheit und Governance fest, die jede Arbeitslast erfüllen muss, bevor Sie sie für den Produktiveinsatz genehmigen.

Wenden Sie ein einheitliches Validierungsframework für jede Migrationswelle an. Das Rahmenwerk sollte die erforderlichen Prüfungen, Freigabekriterien und die Nachweise festlegen, die die Teams vor der Freigabe für die Umschaltung erbringen müssen. Überprüfen Sie mindestens Folgendes:

  • HCX-Replikationsstatus

  • NSX-Segment-Routing-Fähigkeit

  • ESXi-Hostzustand

  • Erreichbarkeit von Identitäts- und Authentifizierungsdiensten vom Zielsegment aus

  • Status unterstützender Dienste wie Backup und Überwachung

Entscheiden Sie, ob Teams vor der Migration grundlegende Leistungsmetriken aus der Quellumgebung erfassen müssen. Diese Messungen bieten einen Referenzpunkt für die Überprüfung der Leistung nach der Migration und die Identifizierung von Regressionen.

Vor der Übernahme müssen Teams ermitteln, ob externe DNS-Einträge, Lastenausgleichskonfigurationen, Anwendungsendpunkte oder andere Konnektivitätsabhängigkeiten Updates erfordern. Schließen Sie alle erforderlichen Änderungen im Wellen-Übernahmeplan ein, um das Risiko von Dienstunterbrechungen zu reduzieren.

1.5 Azure-VMware-Lösung Migrationssequenz

Die Migrationssequenz bestimmt, welche Arbeitslasten zuerst, dann als Zweites usw. in Azure-VMware-Lösung verschoben werden. Eine gute Wellenplanung reduziert Risiken und vermeidet unnötige Unterbrechungen.

  • Gruppieren nach Abhängigkeit: Verwenden Sie die Abhängigkeitsdaten aus der Ermittlung, um Gruppen virtueller Computer zu finden, die eng zusammenarbeiten, z. B. einen Anwendungsserver und seine Datenbank. Verschieben Sie sie in derselben Migrationswelle, damit der Datenverkehr nicht bei jeder Anfrage das Netzwerk durchqueren muss, wenn ein Teil noch on-premises verbleibt.

  • Vorhandene Regeln zuordnen: Dokumentieren Sie alle Affinitäts- oder Antiaffinitätsregeln aus Ihrer lokalen Umgebung, und planen Sie, wie sie reproduziert werden. Azure-VMware-Lösung Platzierungsrichtlinien erzwingen virtual-machine-to-host affinity, was für Lizenzierungseinschränkungen wie SQL Server und für strenge Leistungsanforderungen wichtig ist.

  • Sequenz nach Risiko: Beginnen Sie mit Workloads mit geringerem Risiko, z. B. Nicht-Produktionssystemen oder Anwendungen mit wenigen Abhängigkeiten. Ihr Team baut Vertrauen mit dem Prozess auf, bevor es geschäftskritische Anwendungen annimmt. Wechseln Sie zu Arbeitslasten mit höherer Komplexität, da die Erfahrung wächst.

  • Auf Netzwerk-Erweiterungspläne abstimmen: Richten Sie Ihre Reihenfolge an Ihrer lokalen Netzwerktopologie aus. Wenn mehrere Anwendungen ein Netzwerksegment gemeinsam nutzen, migrieren Sie sie in derselben Welle oder in aufeinander folgenden Wellen. Sie können das Segment dann umgehend auf ein systemeigenes Netzwerk von Azure-VMware-Lösung umstellen und die temporäre Erweiterung entfernen.

1.6 Migrationswerkzeuge

Verwenden Sie VMware HCX, um Workloads mit minimalen Unterbrechungen in Azure-VMware-Lösung zu verschieben. HCX Enterprise ist ohne zusätzliche Kosten enthalten und wird standardmäßig installiert, wodurch Optionen wie Replication Assisted vMotion und Mobility Optimized Networking verfügbar werden. Sie müssen HCX nicht verwenden, und Sie können auch physische Workloads mithilfe einer Partnermigrationslösung einbinden.

1.6.1 Migrationsansatz

vMotion verschiebt eine laufende Workload ohne Ausfallzeiten, und auf Generation 2 führt sie in der Regel schneller aus als Massenmethoden. Replikationsgestützte Migrationen und Massenmigrationen können unter Generation 2 derzeit langsamer ablaufen. Planen Sie daher längere Zeitfenster ein und terminieren Sie die Wellen entsprechend. Siehe Entwurfsüberlegungen für die Private Cloud der zweiten Generation von Azure-VMware-Lösung.

1.6.2 Governance für Netzwerkerweiterungen

Einige Teams behandeln die Netzwerkerweiterung als permanentes Design. Das ist es nicht. Lassen Sie Erweiterungen nur für das Migrationsfenster geöffnet. Die HCX-Netzwerkerweiterung erstreckt sich über ein lokales Netzwerk in Azure-VMware-Lösung auf Layer 2, wodurch Workloads ihre vorhandenen Adressen während der Verschiebung beibehalten können. Dieses Design vermeidet die Neukonfiguration von Anwendungen von vornherein und bringt Abwägungen mit sich, die ein Entscheidungsträger steuern muss.

  • Lokale Abhängigkeit. Ein erweitertes Netzwerk hält sein Gateway in der Regel lokal, sodass die Arbeitsauslastung nach dem Verschieben weiterhin vom Quellstandort abhängt.

  • Ineffizientes Routing. Der Datenverkehr kann zur lokalen Infrastruktur und wieder zurückgeleitet werden – ein Muster, das als Tromboning bezeichnet wird und zusätzliche Latenz sowie weitere Fehlerquellen verursacht.

Legen Sie eine feste Richtlinie fest. Erweitern Sie ein Netzwerk nur, wenn eine Workload ihre Adresse nicht ändern kann, und entfernen Sie jede Erweiterung, sobald ihre Workloads verschoben werden. Bewerten Sie zuerst Ihr lokales Netzwerk, damit Sie wissen, welche Segmente Erweiterung benötigen und wie lange. Diese Bewertung fließt sowohl in Ihren Wellenplan als auch in Ihren Zeitplan für die Erweiterung ein. Mobility Optimized Networking kann die Trombonierung in bestimmten Fällen reduzieren, also bestätigen Sie die unterstützten Konfigurationen, bevor Sie sie aktivieren. Siehe Konfigurieren der HCX-Netzwerkerweiterung.

2. Vorbereitung der Migration

Die folgende Bereitstellungssequenz spiegelt die Abhängigkeiten zwischen Phasen wider. Jeder Schritt geht davon aus, dass der vorherige Schritt abgeschlossen und überprüft wird.

  1. Plattform-Zielzone: Stellen Sie sicher, dass alle erforderlichen zentralen Netzwerk-, Identitäts-, Sicherheits- und Überwachungsdienste für die Integration in Azure VMware-Workloads bereit sind. Wenden Sie die Governance- und Sicherheitsgrundwerte über Azure Policy auf Ihre Verwaltungsgruppenhierarchie an, die Ihnen dabei helfen, Ihre Complianceanforderungen zu erreichen. Generation 2 wird in Ihrem virtuellen Netzwerk bereitgestellt, sodass eine Richtlinienbasis, die strenge Regeln für Netzwerksicherheitsgruppen oder Routentabellen erzwingt, die Bereitstellung blockieren kann. Entfernen Sie diese spezifischen Richtlinien vor der Bereitstellung aus dem virtuellen Netzwerk der privaten Cloud, und führen Sie sie anschließend erneut aus. Planen Sie diese Ausnahme in Ihren Basisplan, damit die Governance das Rollout nicht verzögert.

  2. Workload-Landing Zones: Ordnen Sie Ihre Workload-Landing Zones (Abonnements) der richtigen Verwaltungsgruppe zu, online oder intern („Corp“).

  3. IP-Adressbereiche: Reservieren Sie mindestens einen /22-Adressblock für die Private Cloud. Reservieren Sie bei Generation 2 außerdem zwei zusätzliche /24-Blöcke für HCX-Management und Uplink. Vergewissern Sie sich, dass keiner dieser Bereiche Ihren lokalen, Azure oder anderen Cloudadressraum überlappt. Sie können diese Bedingung nach der Bereitstellung nicht einfach korrigieren. Siehe Entwurfsüberlegungen der Generation 2.

  4. Kontingentanfrage: Fordern Sie das Kontingent frühzeitig an, da die Zuweisung bis zu fünf Werktage dauern kann. Planen Sie ausreichend Kapazität für Wachstum und Notfallwiederherstellung ein, z. B. N+1-Redundanz, also einen Host mehr, als die Workload benötigt. Bestätigen Sie die Portable VMware Cloud Foundation-Lizenz, die für neue Bereitstellungen erforderlich ist. Siehe Anforderungshostkontingent.

  5. Azure-VMware-Lösung Private Cloud-Bereitstellung: Stellen Sie die private Cloud der Generation 2 in ihrem Azure virtuellen Netzwerk bereit. Siehe Erstellen einer privaten Cloud der Generation 2.

  6. Netzwerk- und Identitätskonfiguration: Koppeln Sie das private Cloudnetzwerk mit Ihrem Hub und stellen Sie die On-Premises-Konnektivität her. Verbinden Sie vCenter Server mit Ihrer externen Identitätsquelle, damit Administratoren sich mit verwalteten Konten statt mit freigegebenen integrierten Anmeldeinformationen anmelden.

  7. Überwachung und Verwaltung: Leiten Sie Protokolle an Ihre Protokollverwaltungslösung weiter, und konfigurieren Sie Dienststatuswarnungen. Integrieren Sie virtuelle Gastcomputer über Azure Arc, damit Sie sie mit den gleichen Azure Tools steuern können, die Sie an anderer Stelle verwenden.

  8. HCX-Installation: Installieren Sie HCX, und testen Sie die Standort-zu-Standort-Konnektivität, bevor Sie die erste Welle starten.

3. Migrationsausführung

Definieren Sie, was "erledigt" vor jeder Welle bedeutet. Eine Welle ist abgeschlossen, wenn die Workload überprüft wird, die Netzwerkerweiterung entfernt wird und die Anwendung in ihrem dauerhaften Zustand fehlerfrei ist.

Definieren Sie Rollbackkriterien vor jeder Welle, und testen Sie den Rollbackpfad, bevor Sie Produktionssysteme migrieren. HCX unterstützt die Reversemigration, und der genaue Ansatz hängt vom verwendeten Migrationstyp ab. Zu den Kriterien für den Wellenerfolg gehören:

  1. Jeder virtuelle Computer in der Welle wird auf Azure-VMware-Lösung ausgeführt und hängt nicht mehr von der Netzwerkerweiterung für den Produktionsdatenverkehr ab.

  2. Jede Anwendung kann von den Benutzern und den abhängigen Systemen erreicht werden.

  3. Jeder virtuelle Computer wird in Ihren Überwachungstools ohne Warnungen oder Fehler angezeigt.

  4. Der Rollback wird nicht mehr benötigt und Sie können ihn formell abschließen.

  5. Die Anwendungsleistung stimmt mit der Basislinie überein oder schlägt sie.

  6. Die Workloads erfüllen Ihre Sicherheits- und Complianceanforderungen.

  7. Die Workload wurde erfolgreich in Sicherungs- und Notfallwiederherstellungslösungen integriert.

4. Migrationsbewertung und Außerbetriebnahme

Die Migration endet nicht, wenn Workloads in der Azure-VMware-Lösung hochgefahren werden. Validieren Sie, dass Workloads in ihrer neuen Umgebung ordnungsgemäß funktionieren, bestätigen Sie, dass vorübergehende Migrationsmaßnahmen zurückgenommen wurden, und nehmen Sie die Quellinfrastruktur formell außer Betrieb. Wenn Sie Ihre lokale Infrastruktur weiterhin beibehalten, kann dies zu unentdeckten und nicht dokumentierten Abhängigkeiten führen. Ein disziplinierter Evaluierungs- und Außerbetriebnahmeprozess stellt sicher, dass die Organisation die erwarteten Vorteile der Migration realisiert, ohne unnötige Betriebskosten oder Risiken zu tragen.

4.1 Produktionsbereitschaft nach dem Cutover

Legen Sie Kriterien für die Zeit nach der Umstellung fest, die bestätigen, dass sich der Workload wie erwartet verhält. Überprüfen Sie die Netzwerkreichbarkeit und Namensauflösung. Überprüfen Sie die Anwendungsfunktion und die Kommunikation mit abhängigen Systemen. Nachdem jede virtuelle Maschine verschoben wurde, vergewissern Sie sich, dass sie ordnungsgemäß startet, dass ihre Ressourcen dem Plan entsprechen und dass die richtige Speicherrichtlinie gilt. Vergleichen Sie die Performance mit dem Ausgangswert vor der Migration.

Legen Sie Ihre Paritätsrichtlinie fest. Die wichtigste Entscheidung ist, ob eine migrierte Workload die vollständige Parität mit dem lokalen Zustand erreichen muss, bevor Sie sie als produktionsbereit bezeichnen oder ob Sie temporäre Abweichungen zulassen. Viele Organisationen fordern eine sofortige Leistungsparität für kundenorientierte Systeme, gewähren aber internen Anwendungen einen kurzen Stabilisierungszeitraum mit einem festen Korrekturtermin.

4.2 Konnektivitätsüberprüfung

Überprüfen Sie die End-to-End-Konnektivität über Azure-VMware-Lösung, Azure, die lokale Umgebung, das Internet und die Namensauflösung hinweg. Führen Sie Anwendungsrauchtests aus, um zu bestätigen, dass die Arbeitsauslastung ihren Zweck erfüllt. Prüfen Sie, ob externe DNS-Einträge oder Load-Balancer-Einstellungen bei der Umstellung aktualisiert werden müssen.

Wenn Sie eine sekundäre Instanz von Azure-VMware-Lösung für die Notfallwiederherstellung erstellt haben, stellen Sie sicher, dass sie sowohl von der primären Instanz als auch von allen Clients oder unterstützenden Diensten erreicht werden kann, die eine Verbindung mit ihr herstellen müssen, wenn sie aktiviert ist.

4.3 Auflösung der Netzwerkerweiterung

Wenn alle Workloads auf einem erweiterten Segment verschoben wurden, entfernen Sie die HCX-Layer-2-Erweiterung und vergewissern Sie sich, dass das systemeigene Gateway der Azure-VMware-Lösung korrekt routet. Lassen Sie eine Erweiterung nicht länger installiert, als es für die Migration erforderlich ist.

4.4 Außerbetriebnahme-Quellumgebung

Das Außerbetriebsetzen veröffentlicht formal die Quellkapazität, Lizenzen und die betriebstechnische Abdeckung. Behandeln Sie sie als geregelte Übergabe statt als Bereinigungsaufgabe. Wenn Sie die Außerbetriebnahme überspringen, bezahlen Sie für die Leerlaufinfrastruktur und tragen Sicherheitsrisiken. Verwenden Sie Quell-Workloads nach der Migration in die Cloud außer Betrieb nehmen, um die Reihenfolge der Vorgänge, den Aufbewahrungszeitraum für Quellsicherungen, die Genehmigungen zum Herunterfahren der Quellsysteme und die Kriterien für die Rückgewinnung von Lizenzen und Hardware festzulegen.

Nächste Schritte

Arbeitslastentwurf:

  • Last updated on