Arbeitslasten entwerfen

In diesem Dokument wird beschrieben, wie Sie Arbeitslasten so entwerfen, dass die Auswirkungen einer zukünftigen Erweiterung und Migration von Arbeitslasten in andere Google Cloud Regionen oder die Auswirkungen einer Migration von Arbeitslasten über Regionen hinweg minimiert werden. Dieses Dokument ist nützlich, wenn Sie eine dieser Aktivitäten planen oder die Möglichkeiten dafür in der Zukunft abwägen und herausfinden möchten, wie die Arbeit aussehen könnte.

Dieses Dokument ist Teil der folgenden Reihe:

Die Hinweise in dieser Reihe sind auch nützlich, wenn Sie keine Migration über Regionen hinweg oder eine Erweiterung auf mehrere Regionen im Voraus geplant haben. In diesem Fall müssen Sie möglicherweise zusätzlichen Aufwand für die Vorbereitung der Infrastruktur, Arbeitslasten und Daten für die regionsübergreifende Migration und die Ausweitung auf mehrere Regionen aufwenden.

Dieses Dokument hilft Ihnen bei Folgendem:

  1. Landing Zone vorbereiten
  2. Arbeitslasten für eine regionsübergreifende Migration vorbereiten
  3. Rechenressourcen vorbereiten
  4. Datenspeicherressourcen vorbereiten
  5. Außerbetriebnahme der Quellumgebung vorbereiten

Landing Zone vorbereiten

In diesem Abschnitt geht es um die Überlegungen, die Sie beim Erweitern einer Landingpage (auch Cloud-Grundlage genannt) bei der Migration zwischen Regionen berücksichtigen müssen.

Der erste Schritt besteht darin, die verschiedenen Aspekte einer vorhandenen Landing Zone neu zu bewerten. Bevor Sie eine Arbeitslast migrieren können, muss bereits eine Landing Zone vorhanden sein. Obwohl Sie möglicherweise bereits eine Landing Zone für die Region eingerichtet haben, in der die Arbeitslasten gehostet werden, unterstützt sie möglicherweise nicht die Bereitstellung von Arbeitslasten in einer anderen Region. Daher muss sie auf die Zielregion erweitert werden. Einige Landing Zones, die bereits vorhanden sind, haben möglicherweise ein Design, das eine andere Region unterstützen kann, ohne die Landing Zone zu überarbeiten (z. B. Identitäts- und Zugriffsverwaltung oder Ressourcenverwaltung). Zusätzliche Faktoren wie Netzwerk oder Daten erfordern jedoch möglicherweise eine gewisse Planung der Erweiterung. Bei der Neubewertung sollten die wichtigsten Anforderungen Ihrer Arbeitslasten berücksichtigt werden, damit Sie eine generische Grundlage schaffen können, die später während der Migration spezialisiert werden kann.

Überlegungen für Unternehmen

In Bezug auf Branchen- und behördliche Standards, Vorschriften und Zertifizierungen kann das Verschieben von Arbeitslasten in eine andere Region unterschiedliche Anforderungen haben. Arbeitslasten, die in Google-Regionen ausgeführt werden und sich in verschiedenen Ländern befinden, müssen die Gesetze und Bestimmungen des jeweiligen Landes einhalten. Darüber hinaus können unterschiedliche Branchenstandards spezielle Anforderungen an Arbeitslasten haben, die im Ausland ausgeführt werden (insbesondere in Bezug auf die Sicherheit). Da Google Cloud -Regionen darauf ausgelegt sind, Ressourcen in einem einzelnen Land auszuführen, werden manchmal Arbeitslasten von einer anderen Google-Region in dieses Land migriert, um bestimmte Vorschriften einzuhalten. Wenn Sie diese Migrationen im Land durchführen, ist es wichtig, die lokal ausgeführten Daten neu zu bewerten, um zu prüfen, ob die neue Region die Migration Ihrer Daten zu Google Cloudzulässt.

Identitäts- und Zugriffsverwaltung

Wenn Sie eine Migration planen, müssen Sie für Regionen, die sich bereits in Google Cloudbefinden, wahrscheinlich nicht viele Identitäts- und Zugriffsänderungen einplanen. Identitätsentscheidungen zu Google Cloud und der Zugriff auf Ressourcen beruhen in der Regel auf der Art der Ressourcen und nicht nach der Region, in der die Ressourcen ausgeführt werden. Dabei sind folgende Punkte zu berücksichtigen:

  • Design von Teams: Einige Unternehmen haben unterschiedliche Teams für die Verwaltung verschiedener Ressourcen. Wenn eine Arbeitslast in eine andere Region migriert wird, ist aufgrund einer Änderung der Struktur der Ressourcen möglicherweise ein anderes Team der beste Kandidat, um für bestimmte Ressourcen verantwortlich zu sein. In diesem Fall sollten die Zugriffe entsprechend angepasst werden.
  • Namenskonventionen: Auch wenn Namenskonventionen keine technischen Auswirkungen auf die Funktionalitäten haben, können einige Überlegungen erforderlich sein, wenn Ressourcen mit Namenskonventionen definiert sind, die sich auf die jeweilige Region beziehen. Ein typisches Beispiel ist, wenn bereits mehrere replizierte Regionen vorhanden sind, z. B. virtuelle Compute Engine-Maschinen (VMs), die mit der Region als Präfix benannt sind, z. B. europe-west1-backend-1. Während des Migrationsprozesses ist es wichtig, die Namen entsprechend der neuen Region zu ändern, um Verwirrung oder, noch schlimmer, Pipelines, die auf einer bestimmten Namenskonvention basieren, zu vermeiden.

Konnektivität und Netzwerke

Ihr Netzwerkdesign wirkt sich auf mehrere Aspekte der Migration aus. Daher ist es wichtig, dass Sie sich mit diesem Design befassen, bevor Sie das Verschieben von Arbeitslasten planen.

Beachten Sie, dass die lokale Verbindung mit Google Cloud einer der Faktoren ist, die Sie bei der Migration neu bewerten müssen, da sie regionsspezifisch konzipiert werden kann. Ein Beispiel für diesen Faktor ist Cloud Interconnect, das über einen VLAN-Anhang mit bestimmten Regionen Google Cloud verbunden ist. Sie müssen die Region ändern, mit der der VLAN-Anhang verbunden ist, bevor Sie diese Region schließen, um Traffic zwischen Regionen zu vermeiden. Wenn Sie Partner Interconnect verwenden, kann Ihnen die Migration der Region außerdem dabei helfen, einen anderen physischen Standort für die Verbindung Ihrer VLAN-Anhänge mit Google Cloudauszuwählen. Dies ist auch relevant, wenn Sie ein Cloud VPN verwenden und bei der Migration die Subnetzadressen ändern möchten: Sie müssen Ihre Router neu konfigurieren, um das neue Netzwerk widerzuspiegeln.

Während Virtual Private Clouds (VPCs) in Google Cloud globale Ressourcen sind, sind einzelne Subnetze immer an eine Region gebunden. Daher können Sie nach der Migration nicht dasselbe Subnetz für die Arbeitslasten verwenden. Da sich die IP-Adressen von Subnetzen nicht überschneiden dürfen, sollten Sie eine neue VPC erstellen, um die Adressen beizubehalten. Dieser Vorgang wird vereinfacht, wenn Sie Cloud DNS verwenden, das Funktionen wie DNS-Peering nutzen kann, um den Traffic für die migrierten Arbeitslasten weiterzuleiten, bevor die alte Region verworfen wird.

Weitere Informationen zum Erstellen einer Grundlage für Google Cloudfinden Sie unter Migrieren zu Google Cloud: Grundlage planen und aufbauen.

Arbeitslasten für eine regionsübergreifende Migration vorbereiten

Unabhängig davon, ob Sie Ihre Infrastruktur in Google Cloud einrichten und später in eine andere Region migrieren möchten oder Sie sich bereits bei Google Cloudbefinden und in eine andere Region migrieren müssen, müssen Sie dafür sorgen, dass Ihre Arbeitslasten so einfach wie möglich migriert werden können, um den Aufwand zu reduzieren und Risiken zu minimieren. Damit Sie dafür sorgen können, dass sich alle Arbeitslasten in einem Status befinden, der einen Pfad zur Migration zulässt, empfehlen wir den folgenden Ansatz:

  • Bevorzugen Sie Netzwerkdesigns, die einfach replizierbar und lose über die spezifische Netzwerktopologie verknüpft sind. Google Cloud bietet verschiedene Produkte, mit denen Sie Ihre aktuelle Netzwerkkonfiguration von den Ressourcen entkoppeln können, die dieses Netzwerk verwenden. Ein Beispiel für ein solches Produkt ist Cloud DNS, mit dem Sie interne Subnetz-IP-Adressen von VMs entkoppeln können.
  • Produkte einrichten, die multiregionale oder globale Konfigurationen unterstützen Produkte, die eine Konfiguration unterstützen, die mehr als eine Region umfasst, vereinfachen in der Regel deren Migration in eine andere Region.
  • Verwaltete Dienste mit verwalteten regionsübergreifenden Replikaten für Daten in Betracht ziehen Wie in den folgenden Abschnitten dieses Dokuments beschrieben, können Sie mit einigen verwalteten Diensten ein Replikat in einer anderen Region erstellen. Dies geschieht normalerweise zu Sicherungszwecken oder zur Hochverfügbarkeit. Diese Funktion kann wichtig sein, um Daten von einer Region in eine andere zu migrieren.

Einige Google Cloud -Dienste unterstützen Bereitstellungen in mehreren Regionen oder globale Bereitstellung. Sie müssen diese Dienste nicht migrieren, müssen aber möglicherweise einige Konfigurationen anpassen.

Rechenressourcen vorbereiten

Dieser Abschnitt bietet einen Überblick über die Rechenressourcen in Google Cloud und die Designprinzipien zur Vorbereitung einer Migration in eine andere Region.

In diesem Dokument geht es um die folgenden Google Cloud Computing-Produkte:

Compute Engine

Compute Engine ist der Dienst von Google Cloud, der Kunden VMs bereitstellt.

Für die Migration von Compute Engine-Ressourcen von einer Region zu einer anderen müssen Sie neben den Netzwerkaspekten auch verschiedene Faktoren berücksichtigen.

Wir empfehlen Folgendes:

  • Rechenressourcen prüfen: Eine der ersten Einschränkungen, die beim Ändern der Hostingregion einer VM auftreten können, ist die Verfügbarkeit der CPU-Plattform in der neuen Zielregion. Wenn Sie eine Maschinenserie während der Migration ändern müssen, prüfen Sie, ob das Betriebssystem Ihrer aktuellen VM für die Serie unterstützt wird. Im Allgemeinen kann dieses Problem auf jeden Google Cloud -Computing-Dienst ausgedehnt werden (einige neue Regionen haben möglicherweise keine Dienste wie Cloud Run oder Cloud GPU). Prüfen Sie daher vor dem Planen der Migration, ob alle erforderlichen Computing-Dienste in der Zielregion verfügbar sind.
  • Load-Balancing und Skalierung konfigurieren: Compute Engine unterstützt Load-Balancing-Traffic zwischen Compute Engine-Instanzen und Autoscaling, um virtuelle Maschinen je nach Bedarf automatisch zu MIGs hinzuzufügen oder daraus zu entfernen. Wir empfehlen, Load-Balancing und Autoscaling zu konfigurieren, um die Zuverlässigkeit und Flexibilität Ihrer Umgebungen zu erhöhen und den Verwaltungsaufwand für selbstverwaltete Lösungen zu vermeiden. Weitere Informationen zum Konfigurieren des Load-Balancings und der Skalierung für Compute Engine finden Sie unter Load-Balancing und Skalierung.
  • Zonale DNS-Namen verwenden: Um das Risiko von überregionalen Ausfällen zu verringern, empfehlen wir, zonale DNS-Namen zu verwenden, um virtuelle Maschinen mithilfe von DNS-Namen in Ihren Umgebungen eindeutig zu identifizieren. Google Cloud verwendet standardmäßig zonale DNS-Namen für Compute Engine-VMs. Weitere Informationen zur Funktionsweise des internen Compute Engine-DNS finden Sie unter Übersicht über das interne DNS. Wir empfehlen Ihnen, zonale DNS-Namen als Konfigurationsparameter in Betracht zu ziehen, die Sie in Zukunft ändern können, um eine zukünftige Migration über Regionen hinweg zu ermöglichen und Ihre Konfiguration besser zu verwalten.
  • Gleiche Vorlage für verwaltete Instanzgruppen (MIGs) verwenden: Mit Compute Engine können Sie regionale MIGs erstellen, die virtuelle Maschinen automatisch in mehreren Zonen einer Region automatisch bereitstellen. Wenn Sie eine Vorlage in der alten Region verwenden, können Sie dieselbe Vorlage verwenden, um die MIGs in der neuen Region bereitzustellen.

GKE

Mit Google Kubernetes Engine (GKE) können Sie containerisierte Arbeitslasten in Kubernetes bereitstellen, verwalten und skalieren.

Berücksichtigen Sie bei der Vorbereitung Ihrer GKE-Arbeitslasten für eine Migration die folgenden Designpunkte und GKE-Features:

  • Cloud Service Mesh: Eine verwaltete Implementierung des Istio-Mesh-Netzwerks. Wenn Sie das Cloud Service Mesh für Ihren Cluster verwenden, haben Sie mehr Kontrolle über den Netzwerktraffic zum Cluster. Eines der Hauptmerkmale von Cloud Service Mesh besteht darin, dass Sie ein Service Mesh zwischen zwei Clustern erstellen können. Mit diesem Feature können Sie die Migration von einer Region zu einer anderen planen. Dazu erstellen Sie den GKE-Cluster in der neuen Region und fügen ihn dem Service Mesh hinzu. Mit diesem Ansatz können Sie mit der Bereitstellung von Arbeitslasten im neuen Cluster beginnen und den Traffic schrittweise an diese weiterleiten. So können Sie die neue Bereitstellung testen und haben gleichzeitig die Möglichkeit, durch Bearbeitung des Mesh-Routings ein Rollback durchzuführen.
  • Config Sync: Ein GitOps-Dienst, der auf einem Open-Source-Kern basiert, mit dem Clusterbetreiber und Plattformadministratoren Konfigurationen aus einer einzigen Quelle bereitstellen können. Config Sync kann einen oder mehrere Cluster unterstützen, sodass Sie eine Single Source of Truth für die Konfiguration der Cluster verwenden können. Mit dieser Config Sync-Funktion können Sie die Konfiguration des vorhandenen Clusters für die neue Region im Cluster replizieren und möglicherweise eine bestimmte Ressource für die Region anpassen.
  • Sicherung für GKE: Mit diesem Feature können Sie die nichtflüchtigen Clusterdaten regelmäßig sichern und die Daten im selben oder in einem neuen Cluster wiederherstellen.

Cloud Run

Cloud Run bietet einen einfachen Ansatz zum Bereitstellen von Containern auf Google Cloud. Cloud Run-Dienste sind regionale Ressourcen und werden über mehrere Zonen in der Region repliziert, in der sie sich befinden. Wenn Sie einen Cloud Run-Dienst bereitstellen, können Sie eine Region auswählen, in der die Instanz bereitgestellt werden soll, und dann mit diesem Feature die Arbeitslast in einer anderen Region bereitstellen.

VMware Engine

Google Cloud VMware Engine ist ein vollständig verwalteter Dienst, mit dem Sie die VMware-Plattform in Google Cloudausführen können. Die VMware-Umgebung wird nativ auf derGoogle Cloud Bare-Metal-Infrastruktur an Google Cloud Standorten wie vSphere, vCenter, vSAN, NSX-T, HCX und entsprechenden Tools ausgeführt.

Wenn Sie VMware Engine-Instanzen in eine andere Region migrieren möchten, sollten Sie Ihre private Cloud in der neuen Region erstellen und die Instanzen dann mit den VMware-Tools verschieben.

DNS und Load-Balancing in Compute Engine-Umgebungen sollten bei der Planung der Migration ebenfalls berücksichtigt werden. VMware Engine verwendet Google Cloud DNS, einen verwalteten DNS-Hostingdienst, der autoritatives DNS-Hosting bereitstellt, das im öffentlichen Internet veröffentlicht wird, private Zonen, die in VPC-Netzwerken sichtbar sind, sowie DNS-Weiterleitung und Peering zur Verwaltung der Namensauflösung in VPC-Netzwerken. Ihr
-Migrationsplan unterstützt das Testen von multiregionalem Load-Balancing und DNS-Konfigurationen.

Datenspeicherressourcen vorbereiten

Dieser Abschnitt bietet einen Überblick über die Datenspeicherressourcen aufGoogle Cloud und die Grundlagen zur Vorbereitung einer Migration in eine andere Region.

Das Vorhandensein der Daten, die bereits in Google Cloud vorhanden sind, vereinfacht die Migration, da sie impliziert, dass eine Lösung zum Hosten der Daten ohne Transformation vorhanden ist oder auf Google Cloudgehostet werden kann.

Die Fähigkeit, Datenbankdaten in eine andere Region zu kopieren und an anderer Stelle wiederherzustellen, ist ein gängiges Muster in der Notfallwiederherstellung. Aus diesem Grund basieren einige der in diesem Dokument beschriebenen Muster auf DR-Mechanismen wie der Datenbanksicherung und -wiederherstellung.

Die folgenden verwalteten Dienste werden in diesem Dokument beschrieben:

In diesem Dokument wird davon ausgegangen, dass die von Ihnen verwendeten Speicherlösungen regionale Instanzen sind, die sich zusammen mit Rechenressourcen befinden.

Cloud Storage

Cloud Storage bietet den Storage Transfer Service, der die Übertragung von Dateien aus verschiedenen Systemen zu Cloud Storage automatisiert. Es kann verwendet werden, um Daten zu Sicherungszwecken in einer anderen Region zu replizieren, und auch für die Migration von Region zu Region.

Cloud SQL

Cloud SQL bietet einen relationalen Datenbankdienst zum Hosten verschiedener Datenbanktypen. Cloud SQL bietet eine regionenübergreifende Replikationsfunktion, mit der Instanzdaten in einer anderen Region repliziert werden können. Dieses Feature ist ein gängiges Muster für die Sicherung und Wiederherstellung von Cloud SQL-Instanzen, ermöglicht aber auch das Hochstufen des zweiten Replikats in der anderen Region zum Hauptreplikat. Mit dieser Funktion können Sie ein Lesereplikat in der zweiten Region erstellen und es nach der Migration der Arbeitslasten zum Hauptreplikat hochstufen. Im Allgemeinen vereinfachen verwaltete Dienste bei Datenbanken den Prozess der Datenreplikation, um das Erstellen eines Replikats in der neuen Region während der Migration zu vereinfachen.

Eine weitere Möglichkeit für die Migration ist der Database Migration Service, mit dem Sie SQL-Datenbanken von verschiedenen Quellen zu Google Cloudmigrieren können. Zu den unterstützten Quellen gehört auch eine weitere Cloud SQL-Instanz, mit der einzigen Einschränkung, dass Sie in eine andere Region migrieren können, jedoch nicht in ein anderes Projekt.

Filestore

Wie weiter oben in diesem Dokument erläutert, können Sie mit der Sicherungs- und Wiederherstellungsfunktion von Filestore eine Sicherung einer Dateifreigabe erstellen, die in einer anderen Region wiederhergestellt werden kann. Mit dieser Funktion kann eine Migration von einer Region zu einer Region durchgeführt werden.

Bigtable

Wie Cloud SQL unterstützt Bigtable die Replikation. Mit dieser Funktion können Sie das beschriebene Muster replizieren. Prüfen Sie in der Bigtable-Standortliste, ob der Dienst in der Zielregion verfügbar ist.

Darüber hinaus unterstützt Bigtable, wie bei Filestore, die Sicherung und Wiederherstellung. Diese Funktion kann wie bei Filestore verwendet werden, um die Migration zu implementieren. Dazu wird eine Sicherung erstellt und in einer anderen Instanz der neuen Region wiederhergestellt.

Die letzte Option ist das Exportieren von Tabellen, z. B. in Cloud Storage. Bei diesen Exporten werden Daten in einem anderen Dienst gehostet und die Daten können dann in die Instanz in der Region importiert werden.

Firestore

Firestore-Standorte können an das Vorhandensein von App Engine in Ihrem Projekt gebunden sein, was in einigen Szenarien dazu führt, dass die Firestore-Instanz multiregional ist. Bei diesen Migrationsszenarien muss auch App Engine berücksichtigt werden, um die richtige Lösung für Firestore zu entwerfen. Wenn Sie bereits eine App Engine-Anwendung mit dem Standort us-central oder
europe-west haben, gilt Ihre Firestore-Datenbank sogar als multiregional.

Wenn Sie einen regionalen Standort haben und zu einem anderen Standort migrieren möchten, können Sie Firestore-Entitäten mit dem verwalteten Export- und Importdienst mithilfe eines Cloud Storage-Buckets importieren und exportieren. Diese Methode kann verwendet werden, um Instanzen von einer Region in eine andere zu verschieben. Die andere Möglichkeit ist die Verwendung des Firestore-Features Sicherung und Wiederherstellung. Diese Option ist kostengünstiger und einfacher als das Importieren und Exportieren.

Außerbetriebnahme der Quellumgebung vorbereiten

Sie müssen sich vorbereiten, bevor Sie die Quellumgebung außer Betrieb nehmen und zur neuen Umgebung wechseln.

Vor der Außerbetriebnahme der Quellumgebung sollten Sie Folgendes berücksichtigen:

  • Neue Umgebungstests: Bevor Sie den Traffic von der alten Umgebung auf die neue Umgebung umstellen, können Sie Tests durchführen, um die Richtigkeit der Anwendungen zu prüfen. Neben den klassischen Einheiten- und Integrationstests, die für neu migrierte Anwendungen durchgeführt werden können, gibt es andere Teststrategien. Die neue Umgebung kann als neue Version der Software behandelt werden und die Migration des Traffics kann mit gängigen Mustern wie A/B-Tests implementiert werden, die für die Validierung verwendet werden. Ein weiterer Ansatz besteht darin, den eingehenden Traffic in der Quellumgebung und in der neuen Umgebung zu replizieren, um zu prüfen, ob Funktionen erhalten bleiben.
  • Ruhezeitplanung: Wenn Sie eine Migrationsstrategie wie Blau/Grün auswählen, bei der Sie den Traffic von einer Umgebung zu einer anderen umleiten, sollten Sie die Verwendung geplanter Ausfallzeiten in Betracht ziehen. Die Ausfallzeit ermöglicht es, den Übergang besser zu überwachen und unvorhersehbare Fehler auf Clientseite zu vermeiden.
  • Rollback: Abhängig von den Strategien, die für die Migration des Traffics angewendet wurden, kann es erforderlich sein, im Falle von Fehlern oder Fehlkonfigurationen der neuen Umgebung ein Rollback zu implementieren. Für ein Rollback der Umgebung benötigen Sie eine Monitoring-Infrastruktur, die den Status der neuen Umgebung erkennt.

Sie können Dienste in der ersten Region nur beenden, nachdem Sie erweiterte Tests in der neuen Region durchgeführt und den Dienst in der neuen Region fehlerfrei aktiviert haben. Wir empfehlen, Sicherungen der ersten Region für einen begrenzten Zeitraum aufzubewahren, bis Sie sicher sind, dass in der neu migrierten Region keine Probleme auftreten.

Sie sollten auch überlegen, ob Sie die alte Region zu einem Notfallwiederherstellungsstandort hochstufen möchten, sofern noch keine Lösung vorhanden ist. Dieser Ansatz erfordert zusätzliches Design, damit die Website zuverlässig ist. Weitere Informationen zur korrekten Entwicklung und Planung der Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.

Weitere Informationen

Beitragende

Autor: Valerio Ponza | Technical Solution Consultant

Weitere Beitragende: