Zu Google Cloud migrieren: Best Practices zur Validierung eines Migrationsplans

Last reviewed 2025-05-05 UTC

In diesem Dokument werden die Best Practices für die Validierung des Plans zur Migration Ihrer Arbeitslasten zu Google Cloudbeschrieben. 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 eine Migration von einer lokalen Umgebung, einer privaten Hostingumgebung oder einem anderen Cloudanbieter zu Google Cloudplanen. 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 zuGoogle 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 Cloudauftreten.

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:Ermitteln Sie die Arbeitslasten, die Ausfallzeiten verkraften können. Legen Sie fest, wann diese Ausfallzeiten auftreten können und wie lange sie dauern dürfen, um Unterbrechungen zu minimieren, z. B. am späten Abend oder am Wochenende. 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 erstellen:Während der Bewertungsphase kann es sinnvoll sein, mehrere Bewertungsberichte zu erstellen, um verschiedenen Szenarien Rechnung zu tragen. So können Sie beispielsweise Berichte erstellen, in denen unterschiedliche Lastprofile für Ihre Arbeitslasten berücksichtigt werden, z. B. Zeiten mit hoher und niedriger Nachfrage.

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 Nachricht 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. vorhandene und vorgefertigte 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) für die DNS-Einträge konfiguriert, die Sie aktualisieren möchten?
  • Können Sie die DNS-Eintrags-TTL vor der Migration auf den Mindestwert in Sekunden setzen?
  • Berücksichtigen Ihre DNS-Clients und Vermittler die TTL der DNS-Einträge, die Sie aktualisieren möchten? Haben Ihre Anwendungen beispielsweise clientseitiges DNS-Caching, das die für die Migration konfigurierte TTL ignoriert? Die DNS-Auflösung umfasst mehrere Caching-Ebenen. Verwenden Sie Google Public DNS, um Probleme mit dem DNS Ihres Internetanbieters zu vermeiden.
  • 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?
  • Stellen Sie fest, dass auch nach Abschluss der Migration Traffic an Ihre Quellumgebung gesendet wird?

Proof of Concept erstellen

Ein Proof of Concept (PoC) ist eine kleine, vorläufige Implementierung eines geplanten Migrationsprojekts. Damit werden die Machbarkeit, Funktionalität und potenziellen Vorteile des Projekts geprüft, bevor Sie sich für eine vollständige Implementierung entscheiden. Mit einem POC können Sie feststellen, ob die Migrationsarbeitslasten in der Zielumgebung richtig funktionieren.

Definieren Sie zuerst den Umfang und die spezifischen Erfolgskriterien für den POC. Ihre Erfolgskriterien können Messwerte wie die vollständige Kompatibilität der Zielarbeitslast, minimale Migrationsausfallzeiten und spezifische Leistungsanforderungen umfassen.

Nachdem Sie Ihre Erfolgskriterien festgelegt haben, testen und validieren Sie Ihren POC. Dokumentieren Sie im Migrationsplan Ihre Ergebnisse, die aufgetretenen Herausforderungen und mögliche Lösungen für diese Herausforderungen.

Erstellen Sie einen Proof of Concept, wenn Sie die folgenden Bereiche untersuchen möchten:

  • Migrationsdurchführbarkeit prüfen:Prüfen Sie, ob Ihre Anwendungen, Arbeitslasten und Daten in Google Cloudwie erwartet funktionieren.
  • Ausfallzeiten schätzen und Rollback planen:Messen Sie die Ausfallzeiten, die für die Migration Ihrer Arbeitslasten und die Datenübertragung erforderlich sind. Rollback-Szenarien validieren
  • Migrationsplan optimieren:Berücksichtigen Sie die folgenden Punkte, um Ihren Plan zu optimieren, bevor Sie sich für eine umfassende Migration entscheiden:
    • Den besten Migrationsansatz ermitteln
    • Ermitteln Sie, welche Modernisierungs- oder Refactoring-Maßnahmen für Ihre Arbeitslast erforderlich sind.
    • Potenzielle Risiken oder Probleme bei der Migration identifizieren
    • Testen Sie die Migration.
  • Sicherheits- und Compliance-Validierung durchführen:Achten Sie darauf, dass die Sicherheitsrichtlinien, die IAM-Rollen (Identity and Access Management) und die Compliance-Anforderungen für Ihre Migration den Anforderungen Ihrer Organisation entsprechen.
  • Vertrauen und Zustimmung der Stakeholder aufbauen:Tragen Sie dazu bei, dass die Stakeholder zufrieden sind. Ein erfolgreicher POC schafft Vertrauen in den Migrationsplan, da er Führungskräften und technischen Teams konkrete Vorteile aufzeigt.
  • Kosten und Optimierungsmöglichkeiten schätzen:Schätzen Sie die Kosten, die mit der Migration verbunden sind. Prüfen Sie Optimierungsmöglichkeiten, z. B. durch Testen verschiedener Zielumgebungsgrößen und Migrationstools.

Mehrere Machbarkeitsstudien durchführen. Passen Sie die Zielarbeitslasten und den Migrationsplan an, bis Sie einen POC erstellen, der Ihre Erfolgskriterien erfüllt.

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.

Modernisierung und Anpassung Ihrer Arbeitslasten planen

Wenn Sie die Migration zu Google Cloudplanen, sollten Sie bedenken, dass die Migration und Integration Ihrer Arbeitslasten Zeit in Anspruch nimmt und möglicherweise Herausforderungen mit sich bringt. Erstellen Sie ein Übersichts dokument, in dem die allgemeine Architektur Ihrer Arbeitslasten beschrieben wird. Es sollte Informationen zu den folgenden Themen enthalten:

  • Abhängigkeiten von externen Systemen und Middleware von Drittanbietern, z. B. für Speicher, Messaging und Hosting.
  • Mechanismen zum Authentifizieren und Autorisieren von Arbeitslasten.
  • Prozesse für die Integration in IAM.
  • Anforderungen an die Laufzeitumgebung.
  • Interaktionen mit Speicherebenenoptionen wie Cloud Storage und Google Cloud -Datenbanken.
  • Anforderungen an Ihr Datenübertragungsvolumen und Ihre Bandbreite.
  • Änderungen an Ihrem Anwendungscode, die Sie während der Migration vornehmen.
  • Optionen für die Integration in Google Cloud Observability

Möglicherweise müssen Sie Ihre Arbeitslasten modernisieren, z. B. durch die Integration vonGoogle Cloud -Bibliotheken für Authentifizierung, Autorisierung, Speicher und Observability. Die Modernisierung von Legacy-Bibliotheken kann Aufwand erfordern. Planen Sie genügend Zeit ein, um Ihre Arbeitslasten gründlich zu testen.

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 und Sie das Follow-the-Sun-Betriebsmodell verwenden, 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 nutzbar.
  • 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.

Planen Sie, alle Dokumente und Dashboards zu aktualisieren.

Nach der Migration sollten Sie Ihre Produktions-Runbooks, Ihre Supportdokumente und Ihre Monitoring-Dashboards umfassend aktualisieren. Die Änderungen, die Sie an Ihrer Dokumentation vornehmen müssen, können Folgendes umfassen:

  • Architekturdiagramme:Aktualisieren Sie Ihre Architekturdiagramme, um die Google Cloud Architektur widerzuspiegeln, insbesondere wenn Sie Ihre Arbeitslasten modernisieren und umgestalten.
  • Verbindung und Authentifizierung:Aktualisieren Sie Ihre Dokumentation zu Authentifizierungsmethoden wie IAM und Netzwerkkonfigurationen, um die Google Cloud Architektur widerzuspiegeln.
  • Sicherheit:Aktualisieren Sie Ihre Dokumentation zuGoogle Cloud -Sicherheitsfunktionen, einschließlich der Verschlüsselung von inaktiven Daten und Daten bei der Übertragung sowie IAM-basierter Zugriffssteuerung.
  • Wartung und Skalierung:Aktualisieren Sie Ihre Runbooks für den Produktionsbetrieb in Bezug auf Wartungsfenster für verwaltete Dienste, vertikale und horizontale Skalierungsverfahren sowie Best Practices für die Leistungsoptimierung.
  • Hochverfügbarkeit und Failover:Aktualisieren Sie Ihre Dokumentation für Hochverfügbarkeitskonfigurationen, regionale und zonale Synchronisierungsaspekte sowie Failover-Mechanismen.
  • Sicherung und Wiederherstellung:Aktualisieren Sie Ihre Sicherungs- und Wiederherstellungsprozesse, damit sie mit den Prozessen übereinstimmen, die von Google Cloud und dem Backup- und DR-Dienst unterstützt werden. Dazu gehören automatische Sicherungen, die Möglichkeit zur Wiederherstellung zu einem bestimmten Zeitpunkt sowie Export- und Importverfahren.
  • Notfallwiederherstellung:Aktualisieren Sie Ihren Notfallwiederherstellungsplan und Ihre Verfahren, um sie an die Notfallwiederherstellungsfunktionen von Google Cloud anzupassen, und testen Sie dann die aktualisierten Verfahren.
  • Monitoring und Logging:Integrieren Sie Google Cloud Observability in Ihre Monitoring-Dashboards und Benachrichtigungssysteme. Aktualisieren Sie Ihre Dokumentation zu Cloud-Kontingenten und geben Sie an, wie Logs, Messwerte und Benachrichtigungen zu interpretieren sind.

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 IhreGoogle 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

Beitragende

Autor: Marco Ferrari | Cloud Solutions Architect

Weiterer Beitragender: Alex Cârciu | Solutions Architect