Arbeitslasten entwerfen

Last reviewed 2024-07-24 UTC

In diesem Dokument erfahren Sie, wie Sie Arbeitslasten so gestalten, dass die Auswirkungen einer zukünftigen Erweiterung und Migration von Arbeitslasten in andere Google Cloud Regionen oder die Auswirkungen einer Migration von Arbeitslasten zwischen Regionen minimiert werden. Dieses Dokument ist nützlich, wenn Sie eine dieser Aktivitäten planen oder die Möglichkeit prüfen möchten, dies in Zukunft zu tun, und erfahren möchten, wie die Arbeit aussehen könnte.

Dieses Dokument ist Teil der folgenden Reihe:

Die Anleitung in dieser Reihe ist auch nützlich, wenn Sie keine Migration über Regionen hinweg oder keine Erweiterung auf mehrere Regionen im Voraus geplant haben. In diesem Fall müssen Sie möglicherweise zusätzlichen Aufwand betreiben, um Ihre Infrastruktur, Arbeitslasten und Daten für die Migration zwischen Regionen und die Erweiterung auf mehrere Regionen vorzubereiten.

In diesem Dokument wird Folgendes erläutert:

  1. Landing Zone vorbereiten
  2. Arbeitslasten für die Migration zwischen Regionen vorbereiten
  3. Computing-Ressourcen vorbereiten
  4. Datenspeicherressourcen vorbereiten
  5. Außerbetriebnahme der Quellumgebung vorbereiten

Landing Zone vorbereiten

In diesem Abschnitt geht es um die Überlegungen, die Sie beim Migrieren über Regionen hinweg anstellen müssen, um eine Landing Zone (auch Cloud Foundation genannt) zu erweitern.

Im ersten Schritt müssen Sie die verschiedenen Aspekte einer vorhandenen Landingzone neu bewerten. Bevor Sie eine Arbeitslast migrieren können, muss bereits eine Landing Zone vorhanden sein. Auch wenn Sie bereits eine Landing Zone für die Region haben, in der die Arbeitslasten gehostet werden, unterstützt die Landing Zone möglicherweise nicht die Bereitstellung von Arbeitslasten in einer anderen Region. Sie muss daher auf die Zielregion erweitert werden. Einige bereits vorhandene Landing Zones haben möglicherweise ein Design, das eine weitere Region ohne wesentliche Überarbeitung der Landing Zone unterstützen kann (z. B. Identitäts- und Zugriffsverwaltung oder Ressourcenverwaltung). Es gibt jedoch zusätzliche Faktoren wie Netzwerk oder Daten, die eine Planung für die Erweiterung erforderlich machen. Bei der Neubewertung sollten die wichtigsten Anforderungen Ihrer Arbeitslasten berücksichtigt werden, damit Sie eine allgemeine Grundlage schaffen können, die später während der Migration angepasst werden kann.

Überlegungen für Unternehmen

Bei Aspekten wie Branchen- und staatlichen Standards, Vorschriften und Zertifizierungen können für die Migration von Arbeitslasten in eine andere Region unterschiedliche Anforderungen gelten. Für Arbeitslasten, die in Google-Regionen ausgeführt werden, die sich physisch in verschiedenen Ländern befinden, gelten die Gesetze und Vorschriften des jeweiligen Landes. Außerdem können für Arbeitslasten, die im Ausland ausgeführt werden, je nach Branche unterschiedliche Anforderungen gelten, insbesondere in Bezug auf die Sicherheit. Da Google Cloud -Regionen für die Ausführung von Ressourcen in einem einzelnen Land konzipiert sind, werden Arbeitslasten manchmal aus einer anderen Google-Region in dieses Land migriert, um bestimmte Vorschriften einzuhalten. Bei diesen Migrationen im selben Land ist es wichtig, die lokal ausgeführten Daten noch einmal zu prüfen, um festzustellen, ob die Migration Ihrer Daten zu Google Cloudin der neuen Region zulässig ist.

Identitäts- und Zugriffsverwaltung

Wenn Sie eine Migration planen, müssen Sie wahrscheinlich nicht viele Änderungen an Identität und Zugriff für Regionen planen, die bereits auf Google Cloudsind. Identitätsentscheidungen für Google Cloud und den Zugriff auf Ressourcen basieren in der Regel auf der Art der Ressourcen und nicht auf der Region, in der die Ressourcen ausgeführt werden. Hier sind einige Überlegungen, die Sie anstellen sollten:

  • Zusammensetzung von Teams: In einigen Unternehmen sind verschiedene Teams für die Verwaltung unterschiedlicher Ressourcen zuständig. Wenn eine Arbeitslast in eine andere Region migriert wird, kann es aufgrund der Änderung der Ressourcenstruktur sein, dass ein anderes Team am besten für bestimmte Ressourcen verantwortlich ist. In diesem Fall sollten die Zugriffe entsprechend angepasst werden.
  • Namenskonventionen: Namenskonventionen haben zwar möglicherweise keine technischen Auswirkungen auf die Funktionen, aber es kann erforderlich sein, sie zu berücksichtigen, 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. Compute Engine-VMs, deren Namen mit der Region als Präfix beginnen, z. B. europe-west1-backend-1. Um Verwirrung zu vermeiden oder schlimmer noch Pipelines zu unterbrechen, die auf einer bestimmten Namenskonvention beruhen, ist es wichtig, die Namen während des Migrationsprozesses an die neue Region anzupassen.

Konnektivität und Netzwerke

Ihr Netzwerkdesign wirkt sich auf mehrere Aspekte der Migration aus. Daher ist es wichtig, sich damit zu befassen, bevor Sie die Migration von Arbeitslasten planen.

Die lokale Verbindung mit Google Cloud ist einer der Faktoren, die Sie bei der Migration neu bewerten müssen, da sie regionsspezifisch sein kann. Ein Beispiel für diesen Faktor ist Cloud Interconnect, das über einen VLAN-Anhang mit Google Cloud in bestimmten Regionen verbunden ist. Sie müssen die Region ändern, in der der VLAN-Anhang verbunden ist, bevor Sie diese Region schließen, um Traffic zwischen Regionen zu vermeiden. Ein weiterer Faktor ist, dass Sie bei Verwendung von Partner Interconnect durch die Migration der Region einen anderen physischen Standort auswählen können, an dem Sie Ihre VLAN-Anhänge mit Google Cloudverbinden. Diese Überlegung ist auch relevant, wenn Sie Cloud VPN verwenden und sich entscheiden, Subnetzadressen bei der Migration zu ändern: Sie müssen Ihre Router neu konfigurieren, um das neue Netzwerk zu berücksichtigen.

Während Virtual Private Clouds (VPCs) auf Google Cloud globale Ressourcen sind, sind einzelne Subnetze immer an eine Region gebunden. Das bedeutet, dass Sie nach der Migration nicht dasselbe Subnetz für die Arbeitslasten verwenden können. Da sich Subnetze nicht überlappen können, sollten Sie eine neue VPC erstellen, um dieselben Adressen beizubehalten. Dieser Prozess wird vereinfacht, wenn Sie Cloud DNS verwenden, da Funktionen wie DNS-Peering genutzt werden können, um Traffic für die migrierten Arbeitslasten weiterzuleiten, bevor die alte Region geschlossen wird.

Weitere Informationen zum Aufbau einer Grundlage für Google Cloudfinden Sie unter Zu Google Cloudmigrieren: Grundlage planen und erstellen.

Arbeitslasten für die Migration zwischen Regionen vorbereiten

Unabhängig davon, ob Sie Ihre Infrastruktur auf Google Cloud einrichten und später zu einer anderen Region migrieren möchten oder ob Sie bereits auf Google Cloudsind und zu einer anderen Region migrieren müssen, müssen Sie dafür sorgen, dass Ihre Arbeitslasten auf möglichst einfache Weise migriert werden können, um den Aufwand zu reduzieren und Risiken zu minimieren. Damit alle Arbeitslasten in einem Zustand sind, der eine Migration ermöglicht, empfehlen wir Ihnen, so vorzugehen:

  • Bevorzugen Sie Netzwerkdesigns, die sich leicht replizieren lassen und nur lose an die spezifische Netzwerktopologie gekoppelt 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-IPs von VMs entkoppeln können.
  • Produkte einrichten, die multiregionale oder globale Konfigurationen unterstützen Bei Produkten, die eine Konfiguration mit mehreren Regionen unterstützen, ist die Migration in eine andere Region in der Regel einfacher.
  • Verwaltete Dienste mit verwalteten regionenübergreifenden Replikaten für Daten in Betracht ziehen: Wie in den folgenden Abschnitten dieses Dokuments beschrieben, können Sie bei einigen verwalteten Diensten ein Replikat in einer anderen Region erstellen, in der Regel zu Sicherungs- oder Hochverfügbarkeitszwecken. Diese Funktion kann wichtig sein, um Daten von einer Region in eine andere zu migrieren.

Einige Google Cloud Dienste sind für die Unterstützung von Bereitstellungen in mehreren Regionen oder globalen Bereitstellungen konzipiert. Sie müssen diese Dienste nicht migrieren, aber möglicherweise einige Konfigurationen anpassen.

Computing-Ressourcen vorbereiten

In diesem Abschnitt finden Sie einen Überblick über die Rechenressourcen auf Google Cloud und Designprinzipien zur Vorbereitung auf eine Migration in eine andere Region.

Dieses Dokument bezieht sich auf die folgenden Google Cloud Computing-Produkte:

Compute Engine

Compute Engine ist der Dienst von Google Cloud, der Kunden VMs zur Verfügung stellt.

Wenn Sie Compute Engine-Ressourcen von einer Region in eine andere migrieren möchten, müssen Sie neben den Netzwerkaspekten auch andere Faktoren berücksichtigen.

Wir empfehlen Folgendes:

  • Compute-Ressourcen 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 während der Migration die Maschinenserie ä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 ausgeweitet werden. In einigen neuen Regionen sind möglicherweise keine Dienste wie Cloud Run oder Cloud GPU verfügbar. Prüfen Sie daher vor der Migration, ob alle von Ihnen benötigten Computing-Dienste in der Zielregion verfügbar sind.
  • Load-Balancing und Skalierung konfigurieren: Compute Engine unterstützt das Load-Balancing von Traffic zwischen Compute Engine-Instanzen und das Autoscaling, um je nach Bedarf automatisch virtuelle Maschinen zu MIGs hinzuzufügen oder daraus zu entfernen. Wir empfehlen Ihnen, Load Balancing und Autoscaling zu konfigurieren, um die Zuverlässigkeit und Flexibilität Ihrer Umgebungen zu erhöhen und die Verwaltungsanforderungen von selbst verwalteten Lösungen zu vermeiden. Weitere Informationen zum Konfigurieren des Load Balancing und der Skalierung für Compute Engine finden Sie unter Load Balancing und Skalierung.
  • Zonale DNS-Namen verwenden: Damit das Risiko von überregionalen Ausfällen verringert wird, empfehlen wir die Verwendung von zonalen DNS-Namen, um virtuelle Maschinen, die DNS-Namen in Ihren Umgebungen verwenden, eindeutig zu identifizieren. Google Cloud verwendet standardmäßig zonale DNS-Namen für virtuelle Compute Engine-Maschinen. Weitere Informationen zur Funktionsweise des internen DNS von Compute Engine finden Sie unter Übersicht über das interne DNS. Um eine zukünftige Migration zwischen Regionen zu erleichtern und Ihre Konfiguration wartungsfreundlicher zu gestalten, empfehlen wir, zonale DNS-Namen als Konfigurationsparameter zu verwenden, die Sie später ändern können.
  • Dieselbe Vorlage für verwaltete Instanzgruppen (MIGs) verwenden: Mit Compute Engine können Sie regionale MIGs erstellen, mit denen virtuelle Maschinen automatisch in mehreren Zonen einer Region bereitgestellt werden. Wenn Sie in Ihrer alten Region eine Vorlage 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.

Um Ihre GKE-Arbeitslasten für eine Migration vorzubereiten, sollten Sie die folgenden Designpunkte und GKE-Features berücksichtigen:

  • Cloud Service Mesh: Eine verwaltete Implementierung von Istio Mesh. Wenn Sie Cloud Service Mesh für Ihren Cluster verwenden, haben Sie mehr Kontrolle über den Netzwerkverkehr in den Cluster. Eines der wichtigsten Features von Cloud Service Mesh ist, dass Sie ein Service Mesh zwischen zwei Clustern erstellen können. Mit dieser Funktion können Sie die Migration von einer Region in eine andere planen, indem Sie den GKE-Cluster in der neuen Region erstellen und dem Service Mesh hinzufügen. Mit diesem Ansatz können Sie mit der Bereitstellung von Arbeitslasten im neuen Cluster beginnen und den Traffic schrittweise dorthin weiterleiten. So können Sie die neue Bereitstellung testen und haben gleichzeitig die Möglichkeit, durch Bearbeiten des Mesh-Routings ein Rollback durchzuführen.
  • Config Sync: Ein GitOps-Dienst, der auf einem Open-Source-Kern basiert und mit dem Clusterbetreiber und Plattformadministratoren Konfigurationen aus einer einzigen Quelle bereitstellen können. Config Sync kann einen oder mehrere Cluster unterstützen. So können Sie eine einzige „Source of Truth“ verwenden, um die Cluster zu konfigurieren. Mit dieser Config Sync-Funktion können Sie die Konfiguration des vorhandenen Clusters auf den Cluster für die neue Region replizieren und möglicherweise eine bestimmte Ressource für die Region anpassen.
  • Sicherung für GKE: Mit diesem Feature können Sie die persistenten Daten Ihres Clusters 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 in mehreren Zonen 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. Mit dieser Funktion können Sie die Arbeitslast dann 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 Google Cloud an Standorten ausgeführt, die vSphere, vCenter, vSAN, NSX-T, HCX und die entsprechenden Tools umfassen.

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

Bei der Planung der Migration sollten Sie auch DNS und Lastenausgleich in Compute Engine-Umgebungen berücksichtigen. VMware Engine verwendet Google Cloud DNS, einen verwalteten DNS-Hostingdienst, der autoritatives DNS-Hosting für das öffentliche Internet, private Zonen für VPC-Netzwerke sowie DNS-Weiterleitung und ‑Peering zur Verwaltung der Namensauflösung in VPC-Netzwerken bietet. Ihr
Migrationsplan kann das Testen von multiregionalem Load-Balancing und DNS-Konfigurationen unterstützen.

Datenspeicherressourcen vorbereiten

In diesem Abschnitt finden Sie einen Überblick über die Datenspeicherressourcen inGoogle Cloud und die Grundlagen für die Vorbereitung einer Migration in eine andere Region.

Wenn die Daten bereits auf Google Cloud vorhanden sind, wird die Migration vereinfacht, da dies bedeutet, dass eine Lösung zum Hosten der Daten ohne Transformation vorhanden ist oder auf Google Cloudgehostet werden kann.

Die Möglichkeit, Datenbankdaten in eine andere Region zu kopieren und die Daten an einem anderen Ort wiederherzustellen, ist ein gängiges Muster bei der Notfallwiederherstellung (Disaster Recovery, DR). Aus diesem Grund basieren einige der in diesem Dokument beschriebenen Muster auf DR-Mechanismen wie der Sicherung und Wiederherstellung von Datenbanken.

In diesem Dokument werden die folgenden verwalteten Dienste beschrieben:

In diesem Dokument wird davon ausgegangen, dass die von Ihnen verwendeten Speicherlösungen regionale Instanzen sind, die sich am selben Standort wie die Computeressourcen befinden.

Cloud Storage

Cloud Storage bietet den Storage Transfer Service, mit dem die Übertragung von Dateien aus verschiedenen Systemen zu Cloud Storage automatisiert wird. Sie kann verwendet werden, um Daten zur Sicherung in eine andere Region zu replizieren, und auch für die Migration von Region zu Region.

Cloud SQL

Cloud SQL bietet einen Dienst für relationale Datenbanken 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 das Sichern und Wiederherstellen von Cloud SQL-Instanzen. Außerdem können Sie damit das zweite Replikat in der anderen Region zum Hauptreplikat hochstufen. Mit dieser Funktion können Sie ein Lesereplikat in der zweiten Region erstellen und es dann zum Hauptreplikat hochstufen, sobald Sie die Arbeitslasten migriert haben. Im Allgemeinen vereinfachen verwaltete Dienste für Datenbanken die Datenreplikation, sodass es einfacher ist, während der Migration ein Replikat in der neuen Region zu erstellen.

Eine weitere Möglichkeit zur Migration ist die Verwendung des Database Migration Service, mit dem Sie SQL-Datenbanken aus verschiedenen Quellen zu Google Cloudmigrieren können. Zu den unterstützten Quellen gehört auch eine andere Cloud SQL-Instanz. Die einzige Einschränkung besteht darin, dass Sie zu einer anderen Region, aber nicht zu einem anderen Projekt migrieren können.

Filestore

Wie bereits 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 diesem Feature können Sie eine Migration von einer Region in eine andere durchführen.

Bigtable

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

Wie bei Filestore unterstützt Bigtable außerdem Sicherungen und Wiederherstellungen. Wie bei Filestore kann diese Funktion verwendet werden, um die Migration durchzuführen, indem eine Sicherung erstellt und in einer anderen Instanz in der neuen Region wiederhergestellt wird.

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

Firestore

Firestore-Standorte sind möglicherweise an das Vorhandensein von App Engine in Ihrem Projekt gebunden. In einigen Szenarien wird die Firestore-Instanz dadurch zu einer multiregionalen Instanz. In diesen Migrationsszenarien muss auch App Engine berücksichtigt werden, um die richtige Lösung für Firestore zu entwickeln. Wenn Sie bereits eine App Engine-Anwendung mit dem Standort us-central oder
europe-west haben, wird Ihre Firestore-Datenbank als multiregional eingestuft.

Wenn Sie einen regionalen Standort haben und zu einem anderen Standort migrieren möchten, können Sie mit dem verwalteten Export- und Importdienst Firestore-Entitäten mithilfe eines Cloud Storage-Bucket importieren und exportieren. Mit dieser Methode können Sie Instanzen von einer Region in eine andere verschieben. Die andere Option ist die Verwendung der Funktion zum Sichern und Wiederherstellen von Firestore. Diese Option ist kostengünstiger und einfacher als der Import und Export.

Außerbetriebnahme der Quellumgebung vorbereiten

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

Auf hoher Ebene sollten Sie Folgendes berücksichtigen, bevor Sie die Quellumgebung außer Betrieb nehmen:

  • Tests für die neue Umgebung: Bevor Sie den Traffic von der alten in die neue Umgebung umleiten, können Sie Tests durchführen, um die Richtigkeit der Anwendungen zu validieren. Neben den klassischen Unit- und Integrationstests, die für neu migrierte Anwendungen durchgeführt werden können, gibt es verschiedene Teststrategien. Die neue Umgebung kann als neue Version der Software betrachtet werden. Die Migration des Traffics kann mit gängigen Mustern wie A/B-Tests implementiert werden, die zur Validierung verwendet werden. Eine weitere Möglichkeit besteht darin, den eingehenden Traffic in der Quellumgebung und in der neuen Umgebung zu replizieren, um zu prüfen, ob die Funktionen erhalten bleiben.
  • Planung von Ausfallzeiten: Wenn Sie eine Migrationsstrategie wie Blue-Green auswählen, bei der Sie den Traffic von einer Umgebung in eine andere umleiten, sollten Sie geplante Ausfallzeiten in Betracht ziehen. Während der Ausfallzeit kann die Umstellung besser überwacht werden, um unvorhersehbare Fehler auf Clientseite zu vermeiden.
  • Rollback: Je nach den Strategien, die für die Migration des Traffics verwendet werden, kann es erforderlich sein, bei Fehlern oder Fehlkonfigurationen der neuen Umgebung ein Rollback durchzuführen. Damit Sie die Umgebung zurücksetzen können, benötigen Sie eine Monitoring-Infrastruktur, mit der Sie den Status der neuen Umgebung erkennen können.

Dienste in der ersten Region können erst heruntergefahren werden, nachdem Sie in der neuen Region umfangreiche Tests durchgeführt und die neue Region fehlerfrei in Betrieb genommen haben. Wir empfehlen, Back-ups der ersten Region für eine begrenzte Zeit aufzubewahren, bis Sie sicher sind, dass es in der neu migrierten Region keine Probleme gibt.

Sie sollten auch überlegen, ob Sie die alte Region zu einem Standort für die Notfallwiederherstellung hochstufen möchten, sofern noch keine Lösung vorhanden ist. Dieser Ansatz erfordert zusätzliches Design, um sicherzustellen, dass die Website zuverlässig ist. Weitere Informationen zur richtigen Konzeption und Planung der Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.

Weitere Informationen

Beitragende

Autor: Valerio Ponza | Technical Solution Consultant

Weitere Beitragende: