Arbeitslasten entwerfen

Last reviewed 2024-07-24 UTC

In diesem Dokument erfahren Sie, 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 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 erfahren Sie Folgendes:

  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 hauptsächlich um die Überlegungen, die Sie bei der Erweiterung einer Landing Zone (auch Cloud Foundation genannt) bei einer Migration zwischen Regionen berücksichtigen müssen.

Im ersten Schritt sollten Sie die verschiedenen Aspekte einer vorhandenen Landingpage noch einmal bewerten. Bevor Sie eine Arbeitslast migrieren können, muss bereits eine Landing Zone vorhanden sein. Möglicherweise haben Sie bereits eine Landing Zone für die Region eingerichtet, in der die Arbeitslasten gehostet werden. Diese Landing Zone unterstützt jedoch 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 andere Region ohne größere Überarbeitung der Landing Zone unterstützen kann (z. B. Identitäts- und Zugriffsverwaltung oder Ressourcenverwaltung). Zusätzliche Faktoren wie Netzwerk oder Daten können jedoch eine gewisse Planung für die Erweiterung erfordern. 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 spezialisiert 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 Bestimmungen dieses Landes. Darüber hinaus können verschiedene Branchenstandards besondere Anforderungen an Arbeitslasten stellen, die im Ausland ausgeführt werden (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 Bestimmungen einzuhalten. Wenn Sie diese Migrationen innerhalb des Landes durchführen, ist es wichtig, die lokal ausgeführten Daten noch einmal zu bewerten, um zu prüfen, ob die neue Region die Migration Ihrer Daten zu Google Cloud zulässt.

Identitäts- und Zugriffsverwaltung

Wenn Sie eine Migration planen, müssen Sie wahrscheinlich nicht viele Änderungen an Identitäten und Zugriffen für Regionen planen, die bereits in Google Cloud sind. Entscheidungen zur Identität in Google Cloud und zum Zugriff auf Ressourcen basieren in der Regel auf der Art der Ressourcen und nicht auf der Region, in der sie ausgeführt werden. Folgende Aspekte sollten Sie dabei berücksichtigen:

  • Teamstruktur: Einige Unternehmen sind so strukturiert, dass verschiedene Teams für verschiedene Ressourcen zuständig sind. Wenn eine Arbeitslast aufgrund einer Änderung der Ressourcenstruktur in eine andere Region migriert wird, ist möglicherweise ein anderes Team für bestimmte Ressourcen am besten geeignet. In diesem Fall sollten die Zugriffe entsprechend angepasst werden.
  • Namenskonventionen: Auch wenn Namenskonventionen keine technischen Auswirkungen auf die Funktionen haben, sollten Sie einige Aspekte 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 (virtuelle Maschinen), die mit der Region als Präfix benannt sind, z. B. europe-west1-backend-1. Um Verwirrung oder, schlimmer noch, Fehler bei Pipelines zu vermeiden, die auf einer bestimmten Benennungskonvention beruhen, ist es wichtig, während der Migration die Namen an die neue Region anzupassen.

Konnektivität und Netzwerke

Das Netzwerkdesign wirkt sich auf mehrere Aspekte der Migration aus. Daher ist es wichtig, dieses Design zu berücksichtigen, bevor Sie die Migration von Arbeitslasten planen.

Die On-Premises-Verbindung mit Google Cloud ist einer der Faktoren, die Sie bei der Migration noch einmal bewerten müssen, da sie regionsspezifisch gestaltet werden kann. Ein Beispiel für diesen Faktor ist Cloud Interconnect, das über einen VLAN-Anhang mit bestimmten Regionen mit Google Cloud 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. Wenn Sie Partner Interconnect verwenden, können Sie durch die Migration der Region einen anderen physischen Standort auswählen, über den Sie Ihre VLAN-Anhänge mit Google Cloud verbinden. Dies gilt auch, wenn Sie ein Cloud VPN verwenden und die Subnetzadressen während der Migration ändern möchten: Sie müssen Ihre Router so neu konfigurieren, dass sie dem neuen Netzwerk entsprechen.

Virtual Private Clouds (VPCs) in Google Cloud sind globale Ressourcen. Einzelne Subnetze sind jedoch 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 überschneiden dürfen, sollten Sie ein neues VPC erstellen, um dieselben Adressen beizubehalten. Dieser Vorgang wird vereinfacht, wenn Sie Cloud DNS verwenden. Mit Funktionen wie DNS-Peering können Sie den Traffic für die migrierten Arbeitslasten weiterleiten, bevor Sie die alte Region schließen.

Weitere Informationen zum Erstellen einer Grundlage in Google Cloud finden Sie unter Zu Google Cloud migrieren: Grundlage schaffen.

Arbeitslasten für die Migration zwischen Regionen vorbereiten

Unabhängig davon, ob Sie Ihre Infrastruktur in Google Cloud einrichten und später in eine andere Region migrieren möchten, oder ob Sie bereits Google Cloud nutzen und in eine andere 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 sich in einem Zustand befinden, der eine Migration ermöglicht, empfehlen wir Folgendes:

  • Nutzen Sie Netzwerkdesigns, die sich leicht replizieren lassen und nur lose mit der spezifischen Netzwerktopologie verbunden sind. Google Cloud bietet verschiedene Produkte, mit denen Sie Ihre aktuelle Netzwerkkonfiguration von den Ressourcen trennen können, die dieses Netzwerk nutzen. 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 Replikas 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 mehrere Regionen oder eine globale Bereitstellung konzipiert. Sie müssen diese Dienste nicht migrieren, aber möglicherweise einige Konfigurationen anpassen.

Computing-Ressourcen vorbereiten

In diesem Abschnitt erhalten Sie einen Überblick über die Rechenressourcen in Google Cloud und Designprinzipien, die Sie auf eine Migration in eine andere Region vorbereiten.

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

Compute Engine

Die Compute Engine ist der Google Cloud-Dienst, über den Kunden VMs zur Verfügung gestellt werden.

Wenn Sie Compute Engine-Ressourcen von einer Region in eine andere migrieren möchten, müssen Sie neben den Netzwerkaspekten auch verschiedene andere 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 während der Migration eine Maschinenreihe ändern müssen, prüfen Sie, ob das Betriebssystem Ihrer aktuellen VM für die Reihe unterstützt wird. Im Allgemeinen kann dieses Problem auf jeden Google Cloud-Rechendienst 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 Planung der Migration, ob alle erforderlichen Rechendienste in der Zielregion verfügbar sind.
  • Load Balancing und Skalierung konfigurieren: Die 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, Load Balancing und automatische Skalierung zu konfigurieren, um die Zuverlässigkeit und Flexibilität Ihrer Umgebungen zu erhöhen und die Verwaltungsanforderungen selbst verwalteter Lösungen zu vermeiden. Weitere Informationen zum Konfigurieren von Load Balancing und Skalierung für die Compute Engine finden Sie unter Load Balancing und Skalierung.
  • Zonale DNS-Namen verwenden: Um das Risiko von überregionalen Ausfällen zu verringern, empfehlen wir die Verwendung von zonalen DNS-Namen, um virtuelle Maschinen mit DNS-Namen in Ihren Umgebungen eindeutig zu identifizieren. In Google Cloud werden standardmäßig zonale DNS-Namen für Compute Engine-VMs verwendet. Weitere Informationen zur Funktionsweise des internen DNS der Compute Engine finden Sie unter Internes DNS. Um eine zukünftige Migration zwischen Regionen zu erleichtern und Ihre Konfiguration wartungsfreundlicher zu gestalten, empfehlen wir, zonale DNS-Namen als Konfigurationsparameter zu betrachten, die Sie später ändern können.
  • Gleiche Vorlage für verwaltete Instanzgruppen (MIGs) verwenden: Mit der Compute Engine können Sie regionale MIGs erstellen, die automatisch virtuelle Maschinen in mehreren Zonen in einer Region bereitstellen. 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 der Google Kubernetes Engine (GKE) können Sie containerisierte Arbeitslasten in Kubernetes bereitstellen, verwalten und skalieren.

Berücksichtigen Sie die folgenden Designpunkte und GKE-Features, um Ihre GKE-Arbeitslasten auf eine Migration vorzubereiten:

  • 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. Eine der Hauptfunktionen von Cloud Service Mesh ist die Möglichkeit, ein Service Mesh zwischen zwei Clustern zu erstellen. 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 Arbeitslasten im neuen Cluster bereitstellen und den Traffic nach und nach dorthin weiterleiten. So können Sie die neue Bereitstellung testen und bei Bedarf durch Bearbeiten des Mesh-Routings ein Rollback ausführen.
  • Config Sync: Ein GitOps-Dienst, der auf einem Open-Source-Kern basiert und es Clusterbetreibern und Plattformadministratoren ermöglicht, Konfigurationen aus einer einzigen Quelle bereitzustellen. Config Sync kann einen oder mehrere Cluster unterstützen. So können Sie die Cluster mit einer einzigen „Source of Truth“ konfigurieren. Mit dieser Config Sync-Funktion können Sie die Konfiguration des vorhandenen Clusters im Cluster für die neue Region replizieren und gegebenenfalls eine bestimmte Ressource für die Region anpassen.
  • Sicherung für GKE: Mit dieser Funktion können Sie die nichtflüchtigen Daten Ihres Clusters regelmäßig sichern und in demselben Cluster oder in einem neuen Cluster wiederherstellen.

Cloud Run

Cloud Run bietet einen einfachen Ansatz zum Bereitstellen von Containern in 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 für die Bereitstellung der Instanz auswählen und dann mit dieser Funktion 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 Cloud ausführen können. Die VMware-Umgebung wird nativ in der Bare-Metal-Infrastruktur von Google Cloud an Google Cloud-Standorten ausgeführt, einschließlich vSphere, vCenter, vSAN, NSX-T, HCX und zugehöriger Tools.

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

Bei der Planung Ihrer Migration sollten Sie auch DNS und Load Balancing in Compute Engine-Umgebungen berücksichtigen. VMware Engine verwendet Google Cloud DNS. Das ist ein verwalteter DNS-Hostingdienst, der autoritatives DNS-Hosting bereitstellt, das im öffentlichen Internet veröffentlicht wird, private Zonen, die für VPC-Netzwerke sichtbar sind, sowie DNS-Weiterleitung und -Peering zur Verwaltung der Namensauflösung in VPC-Netzwerken. 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 in Google Cloud und die Grundlagen zur Vorbereitung auf eine Migration in eine andere Region.

Wenn die Daten bereits in Google Cloud vorhanden sind, wird die Migration vereinfacht, da es eine Lösung gibt, um sie ohne Transformation zu hosten, oder eine solche Lösung in Google Cloud gehostet werden kann.

Die Möglichkeit, Datenbankdaten in eine andere Region zu kopieren und die Daten an anderer Stelle wiederherzustellen, ist ein gängiges Muster bei der Notfallwiederherstellung (Disaster Recovery, DR). Aus diesem Grund basieren einige der in diesem Dokument beschriebenen Muster auf Notfallwiederherstellungsmechanismen wie Datenbanksicherung und ‑wiederherstellung.

In diesem Dokument werden die folgenden verwalteten Dienste beschrieben:

In diesem Dokument wird davon ausgegangen, dass Sie regionale Instanzen als Speicherlösungen verwenden, die sich an derselben Stelle wie die Compute-Ressourcen befinden.

Cloud Storage

Cloud Storage bietet den Storage Transfer Service, mit dem die Übertragung von Dateien aus verschiedenen Systemen in Cloud Storage automatisiert wird. Sie können damit Daten zur Sicherung in einer anderen Region replizieren und auch für die Migration zwischen Regionen verwenden.

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. Diese Funktion ist ein gängiges Muster für die Sicherung und Wiederherstellung von Cloud SQL-Instanzen. Sie können damit aber auch das zweite Replikat in der anderen Region zum Hauptreplikat machen. 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. Verwaltete Dienste vereinfachen im Allgemeinen die Datenreplizierung für Datenbanken, sodass während der Migration leichter ein Replikat in der neuen Region erstellt werden kann.

Eine weitere Möglichkeit ist der Database Migration Service, mit dem Sie SQL-Datenbanken aus verschiedenen Quellen zu Google Cloud migrieren können. Zu den unterstützten Quellen gehört auch eine andere Cloud SQL-Instanz. Die einzige Einschränkung besteht darin, dass Sie nur 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 dieser Funktion können Sie eine Migration zwischen Regionen ausführen.

Bigtable

Wie bei Cloud SQL unterstützt Bigtable die Replikation. Mit dieser Funktion können Sie dasselbe Muster wie oben beschrieben replizieren. Sehen Sie in der Liste der Bigtable-Standorte nach, ob der Dienst in der Zielregion verfügbar ist.

Wie bei Filestore unterstützt Bigtable auch die Sicherung und Wiederherstellung. Diese Funktion kann wie bei Filestore verwendet werden, um die Migration durch Erstellen einer Sicherung und Wiederherstellen in einer anderen Instanz in der neuen Region zu implementieren.

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

Firestore

Firestore-Standorte sind möglicherweise an die App Engine in Ihrem Projekt gebunden. In einigen Fällen muss die Firestore-Instanz dann multiregional sein. Bei diesen Migrationsszenarien müssen Sie auch die App Engine berücksichtigen, 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, wird Ihre Firestore-Datenbank als multiregional eingestuft.

Wenn Sie einen regionalen Speicherort haben und zu einem anderen 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 Möglichkeit besteht darin, die Sicherungs- und Wiederherstellungsfunktion von Firestore zu verwenden. Diese Option ist kostengünstiger und einfacher als Import und Export.

Außerbetriebnahme der Quellumgebung vorbereiten

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

Bevor Sie die Quellumgebung außer Betrieb nehmen, sollten Sie Folgendes berücksichtigen:

  • Tests in der neuen Umgebung: Bevor Sie den Traffic von der alten Umgebung in die neue umleiten, können Sie Tests durchführen, um die Richtigkeit der Anwendungen zu überprüfen. 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 behandelt werden und die Migration des Traffics kann mit gängigen Mustern wie A/B-Tests implementiert werden, die zur Validierung verwendet werden. Ein weiterer Ansatz besteht darin, den eingehenden Traffic in der Quell- und in der neuen Umgebung zu replizieren, um zu prüfen, ob Funktionen erhalten bleiben.
  • Planung der Ausfallzeit: Wenn Sie eine Migrationsstrategie wie Blue-Green auswählen, bei der der Traffic von einer Umgebung in eine andere umgeleitet wird, sollten Sie eine geplante Ausfallzeit einplanen. Während der Ausfallzeit kann die Umstellung besser überwacht und unvorhersehbare Fehler auf der Clientseite vermieden werden.
  • Rollback: Je nach den Strategien für die Migration des Traffics kann es bei Fehlern oder einer Fehlkonfiguration der neuen Umgebung erforderlich sein, ein Rollback durchzuführen. Damit Sie die Umgebung zurücksetzen können, benötigen Sie eine Monitoring-Infrastruktur, um den Status der neuen Umgebung zu erkennen.

Dienste in der ersten Region können erst heruntergefahren werden, nachdem Sie erweiterte Tests in der neuen Region durchgeführt und die neue Region ohne Fehler gestartet haben. Wir empfehlen, Sicherungen 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 einer Notfallwiederherstellungswebsite machen möchten, sofern noch keine Lösung vorhanden ist. Bei diesem Ansatz ist zusätzliches Design erforderlich, um die Zuverlässigkeit der Website zu gewährleisten. Weitere Informationen zum richtigen Entwerfen und Planen der Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.

Weitere Informationen

Beitragende

Autor: Valerio Ponza | Technical Solutions Consultant

Weitere Beitragende: