Zu Google Cloud migrieren: Best Practices zur Validierung eines Migrationsplans

Last reviewed 2023-11-29 UTC

In diesem Dokument werden die Best Practices für die Validierung des Plans zur Migration Ihrer Arbeitslasten zu Google Cloud beschrieben. In diesem Dokument werden nicht alle möglichen Best Practices für die Validierung eines Migrationsplans aufgeführt und es werden keine Garantien gegeben. Stattdessen können Sie damit Diskussionen über mögliche Änderungen und Verbesserungen Ihres Migrationsplans fördern.

Dieses Dokument bietet nützliche Informationen, wenn Sie von einer lokalen Umgebung, einer privaten Hostingumgebung oder einem anderen Cloud-Anbieter eine Migration zu Google Cloud vornehmen möchten. Das Dokument ist auch hilfreich, wenn Sie die Möglichkeit zur Migration in Betracht ziehen und sich ein Bild davon machen möchten.

Dieses Dokument ist Teil der folgenden mehrteiligen Reihe zur Migration zu Google Cloud:

Bewertung

Eine vollständige Bewertung Ihrer Arbeitslasten und Umgebungen trägt dazu bei, dass Sie Ihre Arbeitslasten und Umgebungen ganz genau verstehen. Mit diesen Informationen können Sie die Risiken minimieren, die während und nach der Migration zu Google Cloud auftreten.

Vollständige Bewertung vornehmen

Bevor Sie mit den Schritten nach der Bewertungsphase fortfahren, schließen Sie die Bewertung Ihrer Arbeitslasten und Umgebungen ab. Für eine vollständige Bewertung sollten Sie die folgenden Elemente berücksichtigen, die häufig übersehen werden:

  • Inventar: Prüfen Sie, ob das Inventar der zu migrierenden Arbeitslasten aktuell ist und Sie die Bewertung abgeschlossen haben. Überlegen Sie sich beispielsweise, wie aktuell und zuverlässig die Quelldaten für Ihre Bewertung sind und welche Lücken in den Daten bestehen können.

  • Ausfallzeiten: Prüfen Sie, welche Arbeitslasten eine Ausfallzeit in Kauf nehmen können und wie lange diese Ausfallzeiten maximal sein können. Die Migration von Arbeitslasten, bei denen keine oder fast keine Ausfallzeiten auftreten, ist schwieriger als die Migration von Arbeitslasten, für die Ausfallzeiten tragbar sind. Für eine Migration ohne Ausfallzeiten müssen Sie für jede zu migrierende Arbeitslast Redundanz entwerfen und implementieren. Außerdem müssen Sie diese redundanten Instanzen koordinieren.

    Wenn Sie beurteilen, wie viel Ausfallzeit eine Arbeitslast tolerieren kann, sollten Sie prüfen, ob der Geschäftsvorteil einer Migration ohne Ausfallzeiten die zusätzliche Komplexität der Migration erhöht. Vermeiden Sie nach Möglichkeit das Erstellen einer Anforderung ohne Ausfallzeit für eine Arbeitslast.

  • Clustering und Redundanz: Prüfen Sie, welche Arbeitslasten Clustering und Redundanz unterstützen. Wenn eine Arbeitslast Clustering und Redundanz unterstützt, können Sie mehrere Instanzen dieser Arbeitslast auch in verschiedenen Umgebungen wie der Quellumgebung und der Zielumgebung bereitstellen. Geclusterte und redundante Bereitstellungen können die Migration vereinfachen, da diese Arbeitslasten mit eingeschränktem Eingriff koordinieren.

  • Konfigurationsupdates: Prüfen Sie, wie Sie die Konfiguration Ihrer Arbeitslasten aktualisieren. Überlegen Sie sich beispielsweise, wie Sie Aktualisierungen für die Konfiguration der einzelnen zu migrierenden Arbeitslasten bereitstellen wollen. Diese Überlegungen sind für den Erfolg der Migration entscheidend, da Sie die Konfiguration Ihrer Arbeitslasten möglicherweise aktualisieren müssen, während Sie sie in die Zielumgebung migrieren.

  • Mehrere Bewertungsberichte generieren: Während der Bewertungsphase kann es hilfreich sein, mehrere Bewertungsberichte zu generieren, um verschiedene Szenarien zu berücksichtigen. Sie können beispielsweise Berichte erstellen, in denen unterschiedliche Lastprofile für Ihre Arbeitslasten berücksichtigt werden, z. B. zu Spitzenzeiten und außerhalb dieser Zeiten.

Die von Ihren Arbeitslasten unterstützten Fehlermodi bewerten

Wenn Sie wissen, wie sich Ihre Arbeitslasten unter außergewöhnlichen Umständen verhalten, können Sie dafür sorgen, dass sie keinen Bedingungen ausgesetzt sind, von denen sie sich nicht wiederherstellen können. Erfassen Sie im Rahmen der Bewertung Informationen zu Fehlermodi und deren Auswirkungen, die von Ihren Arbeitslasten unterstützt und automatisch angesprochen werden, und dazu, welche Fehlermodi Ihr Eingreifen erfordern. Sie können beispielsweise als Erstes Fragen zu möglichen Fehlermodi wie die folgenden stellen:

  • Was passiert, wenn eine Arbeitslast die Verbindung zum Netzwerk verliert?
  • Kann eine Arbeitslast nach der Beendigung ihre Arbeit an der Stelle fortsetzen?
  • Was passiert, wenn die Leistung einer Arbeitslast oder ihrer Abhängigkeiten unzureichend ist?
  • Was passiert, wenn in der Architektur zwei Arbeitslasten mit derselben Kennzeichnung vorhanden sind?
  • Was passiert, wenn eine geplante Aufgabe nicht ausgeführt wird?
  • Was passiert, wenn zwei Arbeitslasten dieselbe Anfrage verarbeiten?

Eine weitere Quelle für nicht unterstützte Fehlermodi ist möglicherweise der Migrationsplan selbst. Bestimmen Sie, ob Ihr Migrationsplan Schritte enthält, die vom Erfolg einer bestimmten Bedingung abhängen, und ob auch Störungen enthalten sind, wenn die Bedingung nicht erfüllt ist. Ein Plan mit diesen Bedingungen kann darauf hinweisen, dass der Plan selbst fehlschlägt oder einzelne Komponenten während der Migration fehlschlagen können.

Nachdem Sie diese Fehlermodi und ihre Auswirkungen bewertet haben, validieren Sie Ihre Ergebnisse in einer nicht kritischen Umgebung. Simulieren Sie dazu Fehler und fügen Sie Fehler ein, die diese Fehlermodi emulieren. Wenn eine Arbeitslast beispielsweise automatisch nach einem Netzwerkverbindungsverlust wiederhergestellt werden soll, validieren Sie die automatische Wiederherstellung, indem Sie die Unterbrechung der Konnektivität erzwingen und sie anschließend wiederherstellen.

Datenverarbeitungspipelines bewerten

Ihre Arbeitslastbewertung sollte folgende Fragen beantworten können:

  • Sind die Ressourcen für die Migration richtig dimensioniert?
  • Wie viel Zeit wird für die Migration der für Ihre Arbeitslasten erforderlichen Daten benötigt?
  • Kann die Zielumgebung das gesamte Datenvolumen bewältigen?
  • Wie verhalten sich Ihre Arbeitslasten, wenn sie Nachfragespitzen oder die Datenmenge, die sie in einem bestimmten Zeitfenster erzeugen, bewältigen müssen?
  • Gibt es Spitzen bei der Nachfrage oder Spitzen beim Datenvolumen, das von Ihren Arbeitslasten erzeugt wird, gibt es negative Auswirkungen, z. B. eine höhere Latenz oder Verzögerungen bei den Antworten?
  • Benötigen sie nach dem Start Ihrer Arbeitslasten Zeit, um die erwartete Leistung zu erhöhen?

Die Ergebnisse dieser Bewertung sind oft Modelle des Bedarfs, den Ihre Arbeitslasten erfüllen, und der Daten, die die Arbeitslasten in einem bestimmten Zeitfenster erzeugen. Wenn Sie Datenpunkte für die Erstellung solcher Modelle erfassen, sollten Sie beachten, dass diese Datenpunkte zwischen Spitzen- und Nicht-Spitzenzeitfenstern erheblich variieren können. Weitere Informationen dazu, wie und was überwacht werden soll, finden Sie im Buch "Site Reliability Engineering" unter Service Level Objectives.

Jede Arbeitslast, die migriert werden soll, kann aktualisiert und bereitgestellt werden

Während der Migration müssen Sie möglicherweise einige der Arbeitslasten aktualisieren, die Sie migrieren. Beispielsweise müssen Sie möglicherweise eine Fehlerkorrektur für ein Problem einführen oder eine kürzlich vorgenommene Änderung rückgängig machen, die ein Problem verursacht. Sorgen Sie für jede zu migrierende Arbeitslast dafür, dass Sie Änderungen anwenden und bereitstellen können. Wenn Sie beispielsweise eine Arbeitslast migrieren, für die Sie den Quellcode haben, müssen Sie sicherstellen, dass Sie auf diesen Quellcode zugreifen können und dass Sie den Quellcode je nach Bedarf erstellen, verpacken und bereitstellen können.

Ihre Migration kann Arbeitslasten enthalten, auf die Sie keine Änderungen anwenden und vorgenommen werden können, z. B. proprietäre Software. Refaktorieren Sie in diesem Szenario Ihren Migrationsplan, um zusätzlichen Aufwand zu berücksichtigen und die Probleme zu minimieren, die nach der Migration dieser Arbeitslasten auftreten können.

Netzwerkinfrastruktur bewerten

Eine funktionierende Netzwerkinfrastruktur ist für die Migration von grundlegender Bedeutung. Sie können die Netzwerkinfrastruktur als Teil Ihrer Migrationstools verwenden. Sie können beispielsweise Load-Balancer und DNS-Server verwenden, um Traffic gemäß Ihrem Migrationsplan weiterzuleiten.

Um Probleme während der Migration zu vermeiden, ist es wichtig, Ihre Netzwerkinfrastruktur zu bewerten und zu bewerten, inwieweit sie die Migration unterstützen kann. Beispielsweise können Sie sich zuerst Fragen zu Ihrer Load-Balancing-Infrastruktur stellen, z. B.:

  • Was geschieht, wenn Sie Ihre Load-Balancer neu konfigurieren?
  • Wie lange dauert es, bis die aktualisierte Konfiguration wirksam ist?
  • Was geschieht bei einer Migration ohne Ausfallzeiten, wenn Sie vor der aktualisierten Konfiguration eine Trafficspitze erhalten?

Nachdem Sie Fragen zu der Load-Balancing-Infrastruktur haben, sollten Sie sich folgende Fragen zu Ihrer DNS-Infrastruktur stellen:

  • Welche DNS-Einträge sollten Sie aktualisieren, damit sie auf die Zielumgebung verweisen, und wann sollten Sie sie aktualisieren?
  • Welche Clients verwenden diese DNS-Einträge?
  • Wie ist die Gültigkeitsdauer (Time to Live, TTL) konfiguriert, damit die DNS-Einträge aktualisiert werden?
  • Können Sie die DNS-Eintrags-TTL während der Migration auf ihr Minimum setzen?
  • Reagieren Ihre DNS-Clients auf die TTL der zu aktualisierenden DNS-Einträge? Haben Ihre Anwendungen beispielsweise clientseitiges DNS-Caching, das die für die Migration konfigurierte TTL ignoriert?

Planung der Migration

Eine sorgfältige Planung der Migration hilft Ihnen, Probleme während und nach der Migration zu vermeiden. Außerdem können Sie mithilfe von Planungen den Aufwand für unvorhergesehene Aufgaben vermeiden.

Rollback-Strategie für die einzelnen Schritte des Migrationsplans entwickeln

Während der Migration kann jeder Schritt des ausgeführten Migrationsplans zu unerwarteten Problemen führen. Bereiten Sie für jeden Schritt des Migrationsplans eine Rollback-Strategie vor, um sicherzustellen, dass Sie diese Probleme beheben können. So vermeiden Sie Zeitverluste:

  • Achten Sie darauf, dass Ihre Rollback-Strategien regelmäßig funktionieren, indem Sie jede Rollback-Strategie regelmäßig prüfen und testen.
  • Legen Sie eine maximal zulässige Ausführungszeit für jeden Migrationsschritt fest. Nach Ablauf dieser zulässigen Ausführungszeit beginnt das Team mit dem Rollback des Migrationsschritts.

Auch wenn Sie für jeden Schritt des Migrationsplans Rollback-Strategien haben, können einige dieser Schritte möglicherweise dennoch störend sein. Ein potenziell störender Schritt kann auch dann zu einer Art von Verlust führen, wenn Sie einen Rollback durchführen, z. B. zu einem Datenverlust. Prüfen Sie, welche Schritte des Migrationsplans möglicherweise störend sind.

Wenn Sie einen Schritt des Migrationsplans automatisiert haben, achten Sie darauf, dass Sie für jeden automatisierten Schritt ein geplantes Verfahren haben, wenn die Automatisierung fehlschlägt. Wie bei Rollback-Strategien sollten Sie jeden geplanten Vorgang regelmäßig prüfen und testen.

Wenn Sie im Rahmen der Migration Kommunikationskanäle einrichten, sollten Sie Back-up-Kanäle bereitstellen, mit denen Sie nach einem Fehler eine Wiederherstellung vornehmen können, um sicherzustellen, dass Sie nicht von Ihrer Umgebung gesperrt werden. Wenn Sie beispielsweise Partner Interconnect einrichten, können Sie während der Migration auch einen Sicherungszugriff über das öffentliche Internet einrichten, falls während der Bereitstellung und Konfiguration Probleme auftreten.

Graduelle Einführungen und Bereitstellungen planen

Um den Umfang der Probleme und Probleme zu reduzieren, die während der Migration auftreten können, vermeiden Sie umfangreiche Änderungen und entwerfen Sie Ihren Migrationsplan so, dass Änderungen schrittweise eingeführt werden. Planen Sie beispielsweise graduelle Bereitstellungen und Konfigurationsänderungen.

Wenn Sie schrittweise Rollouts planen, minimieren Sie die Anzahl und Größe dieser Änderungen, um das Risiko von unerwarteten Problemen zu verringern, die durch die Anwendung der Änderungen verursacht werden. Nachdem Sie Probleme bei der ersten kleinen Einführung ermittelt und behoben haben, können Sie die nachfolgenden Rollouts für ähnliche Änderungen in großem Maßstab vornehmen.

Entwicklungs- und Betriebsteams der Benachrichtigung

Um die Auswirkungen von Problemen während einer Migration zu reduzieren, benachrichtigen Sie die Teams, die für jede zu migrierende Arbeitslast verantwortlich sind. Informieren Sie auch die Teams, die für die Infrastruktur der Quell- und Zielumgebung verantwortlich sind.

Wenn Ihre Teams in verschiedenen Zeitzonen arbeiten, achten Sie auf Folgendes:

  • Ihre Teams decken diese Zeitzonen ordnungsgemäß ab und decken mehrere aufeinanderfolgende Verschiebungen ab, da sie möglicherweise nicht in einer einzigen Verschiebung Probleme lösen können.
  • Ihre Teams sind bereit, detaillierte Informationen zu den möglichen Problemen zu erfassen. Diese Sammlung bietet den Entwicklern bei der nächsten Verschiebung ein vollständiges Verständnis des Grunds und der Begründung.
  • Bestimmte Personen in Ihren Teams sind für eine bestimmte Verschiebung verantwortlich.

Proof-of-Concept-Ressourcen aus der Zielproduktionsumgebung entfernen

Im Rahmen der Bewertung haben Sie möglicherweise die Zielumgebung verwendet, um Tests und Proofs of Concept zu hosten. Entfernen Sie vor der Migration alle Ressourcen, die Sie während dieser Experimente und Proofs of Concept erstellt haben, aus dem Produktionsbereich der Zielumgebung.

Sie können Ressourcen in einem Nicht-Produktionsumgebungsbereich der Zielumgebung belassen, da die Migration dazu beitragen kann, Informationen zu Problemen zu erfassen, die während der Migration auftreten können. Zur Diagnose von Problemen, die sich nach der Migration auf Ihre Produktionsarbeitslasten auswirken, können Sie beispielsweise die Konfigurations- und Datenlogs der Produktionsarbeitslast mit den Konfigurations- und Datenlogs der Proofs of Concept und Tests vergleichen.

Nachdem Sie die Migration abgeschlossen und geprüft haben, ob die Zielumgebung wie erwartet funktioniert, können Sie die Ressourcen im Nicht-Produktionsbereich der Zielumgebung löschen.

Kriterien zum sicheren Deaktivieren der Quellumgebung definieren

Um zu vermeiden, dass die Kosten für die Ausführung von zwei Umgebungen auf unbestimmte Zeit anfallen, definieren Sie, welche Bedingungen erfüllt sein müssen, damit die Quellumgebung sicher deaktiviert werden kann. Beispiel:

  • Alle Arbeitslasten, einschließlich ihrer Sicherungen und Hochverfügbarkeitsmechanismen und Mechanismen zur Notfallwiederherstellung, werden erfolgreich in die Zielumgebung migriert.
  • Die in die Zielumgebung migrierten Daten sind konsistent, zugänglich und verwendbar.
  • Genauigkeit und Vollständigkeit der migrierten Daten erfüllen den definierten Standard.
  • Ressourcen, die in der Quellumgebung verbleiben, sind keine Abhängigkeiten für Arbeitslasten, die außerhalb des Migrationsbereichs liegen.
  • Die Leistung Ihrer Arbeitslasten in der Zielumgebung entspricht Ihren SLA-Zielen.
  • Ihre Monitoringsysteme melden, dass kein Netzwerkverkehr in der Quellumgebung vorhanden ist, der an die Zielumgebung weitergeleitet werden soll.
  • Nachdem die Arbeitslasten für einen von Ihnen definierten Zeitraum problemlos in der Zielumgebung ausgeführt werden, sind Sie sicher, dass Sie nicht mehr auf die Quellumgebung zurückgreifen können.

Vorgänge

Für eine effiziente Verwaltung der Quell- und Zielumgebung während der Migration müssen Sie auch Ihre operativen Prozesse entwickeln.

Umgebungen überwachen

Richten Sie Folgendes ein, um das Verhalten Ihrer Quell- und Zielumgebung zu beobachten und Probleme bei deren Auftreten zu diagnostizieren:

  • Ein Monitoringsystem zur Erfassung von Messwerten, die für Ihr Szenario nützlich sind.
  • Ein Logging-System, um den Ablauf zu beobachten, der von Ihren Arbeitslasten und anderen Komponenten Ihrer Umgebungen ausgeführt wird.
  • Ein Benachrichtigungssystem, das Sie benachrichtigt, bevor ein problematisches Ereignis auftritt.

Google Cloud Observability unterstützt integrierte Monitoring-, Logging- und Benachrichtigungsfunktionen für Ihre Google Cloud-Umgebung.

Da eine Arbeitslast und ihre Abhängigkeiten mehrere Umgebungen umfassen, müssen Sie möglicherweise mehrere Monitoring- und Benachrichtigungstools für verschiedene Umgebungen verwenden. Berücksichtigen Sie den Zeitpunkt, zu dem Sie die Monitoring- und Benachrichtigungsrichtlinien migrieren, die die Arbeitslasten unterstützen. Wenn Ihre Quellumgebung beispielsweise so konfiguriert ist, dass eine Benachrichtigung gesendet wird, wenn ein bestimmter Server ausgefallen ist, wird die Benachrichtigung ausgelöst, wenn Sie diesen Server absichtlich herunterfahren. Der Benachrichtigungstrigger wird erwartet, ist jedoch nicht hilfreich. Im Rahmen der Migration müssen Sie die Benachrichtigungen für die Quellumgebung kontinuierlich anpassen und für die Zielumgebung neu konfigurieren.

Migration verwalten

Zum Verwalten der Migration prüfen Sie die Leistung der Migration, um Informationen zu erfassen, die Sie nach Abschluss der Migration als Rückblick verwenden können. Nachdem Sie Informationen erfasst haben, können Sie damit die Migrationsleistung analysieren und Datenpunkte zu möglichen Verbesserungen Ihrer Umgebungen vorbereiten.

Wenn Sie beispielsweise mit der Planung der Migration beginnen möchten, sollten Sie sich folgende Fragen stellen:

  • Wie lange hat jeder Schritt des Migrationsplans gedauert?
  • Gab es einige Schritte des Migrationsplans, die mehr Zeit in Anspruch genommen haben als erwartet?
  • Gab es fehlende Schritte oder Prüfungen?
  • Sind während der Migration unerwünschte Ereignisse aufgetreten?

Nächste Schritte