Zwischen Google Cloud-Regionen migrieren: Stabile Umgebungen mit einer einzigen Region in Google Cloud entwerfen

Last reviewed 2024-12-08 UTC

In diesem Dokument erfahren Sie, wie Sie stabile Umgebungen mit einer einzigen Region in Google Cloud entwerfen. Dieses Dokument ist nützlich, wenn Sie eine Umgebung mit einer einzelnen Region migrieren möchten oder die Möglichkeit prüfen möchten, dies in Zukunft zu tun, und erfahren möchten, wie sie aussehen könnte.

Dieses Dokument ist Teil der folgenden Reihe:

In diesem Dokument erfahren Sie, wie Sie stabile Umgebungen mit einer einzelnen Region in Google Cloud entwerfen. Der Schwerpunkt liegt dabei auf den folgenden Architekturkomponenten:

In der Anleitung in diesem Dokument wird davon ausgegangen, dass Sie Umgebungen mit einer einzelnen Region entwerfen und implementieren. Wenn Sie derzeit eine Umgebung mit einer einzelnen Region verwenden, können Sie in Zukunft zu einer Umgebung mit mehreren Regionen migrieren. Wenn Sie eine zukünftige Migration und Weiterentwicklung Ihrer zonalen und Umgebungen mit einer einzelnen Region zu Umgebungen mit mehreren Regionen planen, lesen Sie den Hilfeartikel Zwischen Google Cloud-Regionen migrieren: Erste Schritte.

Attribute verschiedener Deployment-Archetypen

Google Cloud-Produkte werden in vielen Regionen und Zonen angeboten. Regionen sind unabhängige geografische Gebiete, die aus Zonen bestehen. Zonen und Regionen sind logische Abstraktionen zugrunde liegender physischer Ressourcen. Eine Region besteht aus drei oder mehr Zonen, die sich in drei oder mehr physischen Rechenzentren befinden. Die Regionen Mexiko, Osaka und Montreal haben drei Zonen, die sich in einem oder zwei physischen Rechenzentren befinden. In diesen Regionen wird derzeit auf mindestens drei physische Rechenzentren erweitert. Berücksichtigen Sie beim Entwerfen Ihrer Lösungen in Google Cloud die Informationen unter Speicherorte in der Cloud, SLAs der Google Cloud Platform und die entsprechende Google Cloud-Produktdokumentation.

Beim Entwerfen Ihrer Google Cloud-Umgebung können Sie zwischen den folgenden Bereitstellungsmustern wählen, die in absteigender Reihenfolge nach Zuverlässigkeit und Betriebsaufwand sortiert sind:

  • Zonal: Sie stellen Google Cloud-Ressourcen in einer einzelnen Zone innerhalb einer Region bereit und verwenden zonale Dienste, sofern verfügbar. Wenn zonale Dienste nicht verfügbar sind, verwenden Sie regionale Dienste.
  • Regional: Sie stellen Google Cloud-Ressourcen in mehreren Zonen innerhalb einer Region bereit und verwenden nach Möglichkeit regionale Dienste.
  • Multiregional: Sie stellen Google Cloud-Ressourcen in mehreren Zonen in verschiedenen Regionen bereit. Zonale Ressourcen werden in einer oder mehreren Zonen in jeder Region bereitgestellt.
  • Global: Sie stellen Google Cloud-Ressourcen in mehreren Zonen in verschiedenen Regionen weltweit bereit. Zonale Ressourcen werden in einer oder mehreren Zonen in jeder Region bereitgestellt.

Die oben genannten Bereitstellungsarchetypen haben unterschiedliche Zuverlässigkeitseigenschaften. Sie können sie verwenden, um die Zuverlässigkeitsgarantien zu bieten, die für Ihre Umgebung erforderlich sind. So ist es beispielsweise wahrscheinlicher, dass eine mehrregionale Umgebung einen regionalen Ausfall übersteht, als es bei einer Umgebung mit einer einzelnen Region oder Zone der Fall ist. Weitere Informationen zu den Zuverlässigkeitseigenschaften der einzelnen Bereitstellungsarchitekturen finden Sie unter Zuverlässigkeit durch Zonen und Regionen und im Leitfaden zur Zuverlässigkeit der Google Cloud-Infrastruktur.

Das Entwerfen, Implementieren und Ausführen einer Umgebung anhand dieser Deployment-Archetypen erfordert aufgrund der Kosten- und Komplexitätsattribute der einzelnen Archetypen unterschiedlichen Aufwand. So ist eine zonale Umgebung beispielsweise im Vergleich zu einer regionalen oder multiregionalen Umgebung möglicherweise kostengünstiger und einfacher zu entwerfen, zu implementieren und zu betreiben. Der potenzielle geringere Aufwand und die geringeren Kosten der zonalen Umgebung sind auf den zusätzlichen Overhead zurückzuführen, den Sie für die Koordination von Arbeitslasten, Daten und Prozessen in verschiedenen Regionen verwalten müssen.

In der folgenden Tabelle sind die Ressourcenverteilung, die Zuverlässigkeitseigenschaften und die Komplexität der einzelnen Bereitstellungsarchetypen zusammengefasst. Außerdem wird der Aufwand beschrieben, der für die Entwicklung und Implementierung einer Umgebung auf der Grundlage der einzelnen Architekturen erforderlich ist.

Name des Bereitstellungsarchetyps Ressourcenverteilung Hilfe beim Widerstehen Designkomplexität
Zonale Umgebung In einer einzelnen Zone Ressourcenfehler Erfordert Koordination innerhalb einer einzelnen Zone
Umgebung mit einer Region In mehreren Zonen in einer Region Ressourcenausfälle, zonale Ausfälle Erfordert die Koordination mehrerer Zonen in einer Region
Multiregionale Umgebung Mehrere Zonen, mehrere Regionen Ressourcenausfälle, zonale Ausfälle, regionale Ausfälle, mehrregionale Ausfälle Erfordert Koordination über mehrere Zonen und Regionen hinweg
Globale Umgebung In mehreren Zonen und Regionen weltweit Ressourcenausfälle, zonale Ausfälle, regionale Ausfälle, mehrregionale Ausfälle Erfordert Koordination über mehrere Zonen und Regionen hinweg

Weitere Informationen zu diesen und anderen Bereitstellungsmustern finden Sie unter Google Cloud-Bereitstellungsmuster.

Deployment-Archetypen für Ihre Umgebungen auswählen

So wählen Sie den Bereitstellungsarchetyp aus, der Ihren Anforderungen am besten entspricht:

  1. Definieren Sie die Fehlermodelle, gegen die Sie sich schützen möchten.
  2. Bewerten Sie die Bereitstellungsmuster, um zu ermitteln, welche am besten zu Ihren Anforderungen passt.

Fehlermodelle definieren

Berücksichtigen Sie bei der Definition von Fehlermodellen die folgenden Fragen:

  • Für welche Komponenten Ihrer Umgebung sind Ausfallmodelle erforderlich? Ausfallmodelle können auf alles angewendet werden, was Sie in Google Cloud bereitstellen oder bereitstellen. Ein Ausfallmodell kann auf eine einzelne Person oder auf alle Ressourcen in einer Zone oder Region angewendet werden. Wir empfehlen, ein Ausfallmodell auf alles anzuwenden, was für Sie einen Wert hat, z. B. Arbeitslasten, Daten, Prozesse und alle Google Cloud-Ressourcen.
  • Welche Anforderungen an Hochverfügbarkeit, Geschäftskontinuität und Notfallwiederherstellung gelten für diese Komponenten? Jede Komponente Ihrer Umgebung kann eigene Service Level Objectives (SLOs) haben, die die zulässigen Servicelevels für diese Komponente und die Anforderungen an die Notfallwiederherstellung definieren. Das Compute Engine-SLA gibt beispielsweise an, dass Sie Instanzen in mehreren Zonen innerhalb einer Region bereitstellen müssen, wenn Sie eine monatliche Verfügbarkeit von mehr als 99,5% erreichen möchten. Weitere Informationen finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
  • Wie viele Fehlermodelle müssen Sie definieren? In einer typischen Umgebung müssen nicht alle Komponenten dieselben Zuverlässigkeitsgarantien bieten. Wenn Sie Garantien für eine höhere Verfügbarkeit und eine stärkere Ausfallsicherheit bieten, müssen Sie in der Regel mehr Aufwand und Ressourcen aufwenden. Wenn Sie Ihre Ausfallmodelle definieren, empfehlen wir, mehrere Ausfallmodelle für jede Komponente und nicht nur eins für alle Komponenten zu definieren. Beispielsweise müssen geschäftskritische Arbeitslasten in der Regel eine höhere Zuverlässigkeit bieten, während für andere, weniger kritische Arbeitslasten geringere Zuverlässigkeitsgarantien akzeptabel sind.
  • Wie viele Ressourcen benötigen die Ausfallmodelle, um vor Ausfällen zu schützen? Um sich vor den von Ihnen definierten Ausfallmodellen zu schützen, investieren Sie Ressourcen wie Zeit und Kosten, die für die Entwicklung, Bereitstellung und Konfiguration von Schutzmechanismen und automatisierten Prozessen erforderlich sind. Wir empfehlen Ihnen, zu bewerten, wie viele Ressourcen Sie für jedes von Ihnen definierte Ausfallmodell benötigen.
  • Wie erkennen Sie, dass ein Fehler auftritt? Es ist wichtig, dass Sie erkennen können, ob ein Fehler auftritt oder kurz bevorsteht, damit Sie Maßnahmen zur Risikobewältigung, Wiederherstellung und Abgleich ergreifen können. Sie können beispielsweise Google Cloud Observability konfigurieren, um über Leistungseinbußen informiert zu werden.
  • Wie können Sie die von Ihnen definierten Fehlermodelle testen? Wenn Sie Ausfallmodelle definieren, sollten Sie darüber nachdenken, wie Sie jedes Modell kontinuierlich testen können, um sicherzustellen, dass es effektiv vor den Ausfällen schützt, auf die die Modelle ausgerichtet sind. Sie können beispielsweise Fehler in Ihre Umgebungen einfügen oder die Fähigkeit Ihrer Umgebungen bewerten, Fehler zu tolerieren, indem Sie Chaos Engineering verwenden.
  • Welche Auswirkungen erwarten Sie, wenn ein bestimmtes Ausfallmodell auftritt? Um die Auswirkungen eines Ausfalls auf Ihr Unternehmen zu verstehen, empfehlen wir, für jedes Ausfallmodell die Folgen jedes Ausfalls zu schätzen, für den das Modell entwickelt wurde. Dieses Verständnis ist nützlich, um Prioritäten und Wiederherstellungsreihenfolgen festzulegen, damit Sie und Ihre Prozesse zuerst die kritischsten Komponenten angehen.
  • Wie lange werden die Ausfälle in den von Ihnen definierten Ausfallmodellen voraussichtlich andauern? Die Dauer eines Ausfalls kann sich erheblich auf die Notfallmaßnahmen und Wiederherstellungspläne auswirken. Daher empfehlen wir Ihnen, bei der Definition von Fehlermodellen zu berücksichtigen, wie lange ein Ausfall dauern kann. Berücksichtigen Sie bei der Frage, wie lange ein Ausfall dauern kann, auch, wie viel Zeit es dauert, einen Ausfall zu erkennen, zu beheben und die ausgefallenen Ressourcen wiederherzustellen.

Weitere Informationen zu Ausfallmodellen und zur Erstellung eines zuverlässigen Notfallwiederherstellungsplans finden Sie unter Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur.

Deployment-Archetypen bewerten

Nachdem Sie die Fehlermodelle definiert haben, gegen die Sie sich schützen möchten, bewerten Sie die Bereitstellungsarchetypen, um zu ermitteln, welche Ihren Anforderungen am besten entspricht. Berücksichtigen Sie bei der Bewertung der Bereitstellungsmuster die folgenden Fragen:

  • Wie viele Bereitstellungsmuster benötigen Sie? Sie müssen nicht nur einen einzigen Deployment-Archetyp für alle Umgebungen auswählen. Stattdessen können Sie einen hybriden Ansatz implementieren, bei dem Sie mehrere Bereitstellungsmuster entsprechend den Zuverlässigkeitsgarantien auswählen, die Sie benötigen, um sich vor den von Ihnen definierten Ausfallmodellen zu schützen. Wenn Sie beispielsweise zwei Ausfallmodelle definiert haben, für die eine zonale und eine regionale Umgebung erforderlich sind, sollten Sie separate Bereitstellungsmuster auswählen, um sich vor jedem Ausfallmodell zu schützen. Wenn Sie mehrere Deployment-Archetypen auswählen, sollten Sie die potenziell zunehmende Komplexität des Entwerfens, Implementierens und Betreibens mehrerer Umgebungen berücksichtigen.
  • Wie viele Ressourcen benötigen Sie, um Umgebungen basierend auf den Bereitstellungsmustern zu entwerfen und zu implementieren? Das Entwerfen und Implementieren einer Umgebung erfordert Ressourcen und Aufwand. Wir empfehlen Ihnen, zu bewerten, wie viele Ressourcen Sie benötigen, um jede Umgebung basierend auf dem von Ihnen ausgewählten Archetyp zu entwerfen und zu implementieren. Wenn Sie ein vollständiges Verständnis dafür haben, wie viele Ressourcen Sie benötigen, können Sie einen Kompromiss zwischen den Zuverlässigkeitsgarantien der einzelnen Bereitstellungsarchetypen und den Kosten und der Komplexität des Designs, der Implementierung und der Betriebsumgebungen basierend auf diesen Archetypen finden.
  • Werden Sie eine Umgebung, die auf einem Bereitstellungsarchetyp basiert, in eine Umgebung migrieren, die auf einem anderen Archetyp basiert? Möglicherweise müssen Sie in Zukunft Arbeitslasten, Daten und Prozesse aus einer Google Cloud-Umgebung in eine andere migrieren. Sie können beispielsweise von einer zonalen Umgebung zu einer regionalen Umgebung migrieren.
  • Wie geschäftskritisch sind die Umgebungen, die Sie entwerfen und implementieren? Für geschäftskritische Umgebungen sind wahrscheinlich höhere Zuverlässigkeitsgarantien erforderlich. Sie können beispielsweise eine mehrregionale Umgebung für geschäftskritische Arbeitslasten, Daten und Prozesse entwerfen und implementieren und eine zonale oder regionale Umgebung für weniger kritische Arbeitslasten, Daten und Prozesse.
  • Benötigen Sie die Funktionen, die von bestimmten Bereitstellungsmustern für bestimmte Umgebungen angeboten werden? Abgesehen von den Zuverlässigkeitsgarantien der einzelnen Bereitstellungsarchetypen bieten die Archetypen auch unterschiedliche Skalierbarkeit, geografische Nähe, Latenz und Datenlokalisierungsgarantien. Wir empfehlen, diese Garantien zu berücksichtigen, wenn Sie die Deployment-Archetypen für Ihre Umgebungen auswählen.

Neben den technischen Aspekten der Ausfallmodi, die Sie anhand der vorherigen Anleitung definiert haben, empfehlen wir Ihnen, auch alle nicht funktionalen Anforderungen wie rechtliche, standortbezogene und souveränitätsbezogene Anforderungen zu berücksichtigen. Diese Anforderungen können die für Sie verfügbaren Optionen einschränken. Wenn Sie beispielsweise regulatorische Anforderungen erfüllen müssen, die die Verwendung einer bestimmten Region vorschreiben, müssen Sie entweder eine Umgebung mit einer einzelnen Region oder eine Zonen-Umgebung in dieser Region entwerfen und implementieren.

Google Cloud-Region für Ihre Umgebung auswählen

Wenn Sie mit dem Entwerfen Ihrer Umgebungen mit einer einzelnen Region beginnen, müssen Sie die Region ermitteln, die den Anforderungen der einzelnen Umgebungen am besten entspricht. In den folgenden Abschnitten werden diese beiden Kategorien von Auswahlkriterien beschrieben:

  • Funktionale Kriterien Diese Kriterien beziehen sich darauf, welche Google Cloud-Produkte in einer bestimmten Region angeboten werden und ob eine bestimmte Region Ihre Anforderungen an Latenz und geografische Nähe zu Nutzern und anderen Umgebungen außerhalb von Google Cloud erfüllt. Wenn Ihre Arbeitslasten und Daten beispielsweise Latenzanforderungen für Ihre Nutzer oder andere Umgebungen außerhalb von Google Cloud haben, müssen Sie möglicherweise die Region auswählen, die Ihren Nutzern oder anderen Umgebungen am nächsten ist, um diese Latenz zu minimieren.
  • Nicht funktionale Kriterien Diese Kriterien beziehen sich auf die Produktpreise, die mit bestimmten Regionen verknüpft sind, auf Anforderungen an den CO₂-Fußabdruck sowie auf obligatorische Anforderungen und Bestimmungen, die für Ihr Unternehmen gelten. Beispielsweise gelten für stark regulierte Märkte wie den Banken- und öffentlichen Sektor sehr strenge und spezifische Anforderungen an die Lokalisierung von Daten und Arbeitslasten sowie an die gemeinsame Nutzung der Cloud-Anbieterinfrastruktur mit anderen Kunden.

Wenn Sie jetzt eine bestimmte Google Cloud-Region auswählen, können Sie später zu anderen Regionen oder zu einer multiregionalen Umgebung migrieren. Wenn Sie eine zukünftige Migration in andere Regionen planen, lesen Sie den Hilfeartikel Zwischen Google Cloud-Regionen migrieren: Erste Schritte.

Funktionskriterien bewerten

Berücksichtigen Sie bei der Bewertung funktionaler Kriterien die folgenden Fragen:

  • Welche Anforderungen gelten für die geografische Nähe? Wenn Sie eine Google Cloud-Region auswählen, müssen Sie Ihre Arbeitslasten, Daten und Prozesse möglicherweise in der Nähe Ihrer Nutzer oder Ihrer Umgebungen außerhalb von Google Cloud platzieren, z. B. in Ihren lokalen Umgebungen. Wenn Sie beispielsweise eine Nutzerbasis ansprechen möchten, die sich in einem bestimmten geografischen Gebiet konzentriert, empfehlen wir Ihnen, eine Google Cloud-Region auszuwählen, die diesem geografischen Gebiet am nächsten liegt. Wenn Sie eine Google Cloud-Region auswählen, die Ihren Anforderungen an die geografische Nähe am besten entspricht, können Sie in Ihren Umgebungen eine geringere Latenz und kürzere Reaktionszeiten auf Anfragen von Nutzern und Umgebungen außerhalb von Google Cloud gewährleisten. Mit Tools wie dem Google Cloud-Latenzdashboard und inoffiziellen Tools wie GCPing und der Google Cloud-Regionsauswahl können Sie sich einen allgemeinen Überblick über die Latenzeigenschaften von Google Cloud-Regionen verschaffen. Wir empfehlen jedoch, eine umfassende Bewertung durchzuführen, um zu prüfen, ob die Latenzeigenschaften Ihren Anforderungen, Arbeitslasten, Daten und Prozessen entsprechen.
  • Welche der Regionen, die Sie verwenden möchten, bieten die Produkte, die Sie benötigen? Wir empfehlen Ihnen, die in den einzelnen Google Cloud-Regionen verfügbaren Produkte zu prüfen und herauszufinden, welche Regionen die Dienste bereitstellen, die Sie zum Entwerfen und Implementieren Ihrer Umgebungen benötigen. Weitere Informationen dazu, welche Produkte in den einzelnen Regionen verfügbar sind und wann sie eingeführt werden, finden Sie unter Cloud-Standorte. Außerdem sind bei einigen Produkten möglicherweise nicht alle Funktionen in allen Regionen verfügbar, in denen sie angeboten werden. Beispielsweise bieten die verfügbaren Regionen und Zonen für die Compute Engine bestimmte Maschinentypen in bestimmten Google Cloud-Regionen. Weitere Informationen zu den Funktionen der einzelnen Produkte in den einzelnen Regionen finden Sie in der Produktdokumentation.
  • Entsprechen die benötigten Ressourcen in jeder Google Cloud-Region den pro Region geltenden Kontingentlimits? Google Cloud legt mithilfe von Kontingenten fest, welchen Anteil einer freigegebenen Google Cloud-Ressource Sie nutzen können. Einige Kontingente sind global und gelten für Ihre Nutzung der Ressource überall in Google Cloud, während andere regional oder zonal sind und für Ihre Nutzung der Ressource in einer bestimmten Google Cloud-Region gelten. Die meisten Kontingente für die Compute Engine-Ressourcennutzung, z. B. die Anzahl der virtuellen Maschinen, die Sie erstellen können, sind beispielsweise regional. Weitere Informationen zu Kontingenten und zur Erhöhung von Kontingenten finden Sie unter Mit Kontingenten arbeiten.

Nicht funktionale Kriterien bewerten

Berücksichtigen Sie bei der Bewertung nicht funktionaler Kriterien die folgenden Fragen:

  • Legen Sie Wert auf einen geringen CO₂-Fußabdruck? Google Cloud investiert kontinuierlich in Nachhaltigkeit und in kohlenstofffreie Energie für Google Cloud-Regionen und verpflichtet sich zu CO2-freier Energie für alle Cloud-Regionen. Google Cloud-Regionen haben unterschiedliche CO2-Bilanzen. Informationen zum CO2-Fußabdruck der einzelnen Google Cloud-Regionen und dazu, wie Sie CO2-freie Energie in Ihre Standortstrategie einbinden, finden Sie unter CO2-freie Energie für Google Cloud-Regionen.
  • Müssen Ihre Umgebungen bestimmten Bestimmungen entsprechen? Regierungen sowie nationale und supranationale Rechtssubjekte regulieren bestimmte Märkte und Geschäftsbereiche wie das Bankwesen und den öffentlichen Sektor oft streng. Diese Bestimmungen können vorschreiben, dass Arbeitslasten, Daten und Prozesse nur in bestimmten geografischen Regionen gespeichert werden dürfen. Beispielsweise müssen Ihre Umgebungen möglicherweise Anforderungen an die Daten-, Betriebs- und Softwarehoheit erfüllen, um bestimmte Kontrollen und Transparenz für sensible Daten und Arbeitslasten zu gewährleisten, die in der Cloud ausgeführt werden. Wir empfehlen Ihnen, bei der Auswahl der Google Cloud-Regionen für Ihre Umgebungen Ihre aktuellen und anstehenden gesetzlichen Anforderungen zu berücksichtigen und die Google Cloud-Regionen auszuwählen, die Ihren gesetzlichen Anforderungen am besten entsprechen.

Umgebungen mit einer einzigen Region entwerfen und erstellen

So entwerfen Sie eine Umgebung mit einer einzelnen Region:

  1. Grundlage in Google Cloud erstellen
  2. Rechenressourcen bereitstellen und konfigurieren.
  3. Datenspeicherressourcen bereitstellen und konfigurieren.
  4. Datenanalyseressourcen bereitstellen und konfigurieren.

Berücksichtigen Sie beim Entwerfen Ihrer Umgebung die folgenden allgemeinen Designprinzipien:

  • Regionale Ressourcen bereitstellen Viele Google Cloud-Produkte unterstützen die Bereitstellung von Ressourcen in mehreren Zonen innerhalb einer Region. Wir empfehlen, nach Möglichkeit regionale statt zonale Ressourcen bereitzustellen. Theoretisch können Sie zonale Ressourcen in mehreren Zonen in einer Region bereitstellen und selbst verwalten, um eine höhere Zuverlässigkeit zu erzielen. Bei dieser Konfiguration können jedoch nicht alle Zuverlässigkeitsfunktionen der Google-Infrastruktur genutzt werden, die die Google Cloud-Dienste unterstützen.
  • Prüfen Sie, ob die Umgebungen mit den Annahmen des Ausfallmodells wie erwartet funktionieren. Wenn Sie die Umgebungen für eine einzelne Region entwerfen und implementieren, sollten Sie prüfen, ob diese Umgebungen die Anforderungen erfüllen, um vor den betroffenen Modellen zu schützen, bevor Sie diese Umgebungen als Teil Ihrer Produktionsumgebung hochstufen. Sie können beispielsweise Zonenausfälle simulieren, um zu prüfen, ob Ihre Umgebungen mit einer einzelnen Region mit minimalen Unterbrechungen funktionieren.

Allgemeine Designprinzipien für das Entwerfen zuverlässiger Umgebungen mit einer oder mehreren Regionen sowie Informationen darüber, wie Google eine bessere Zuverlässigkeit mit regionalen und multiregionalen Diensten erreicht, finden Sie unter Architektur der Notfallwiederherstellung für Cloud-Infrastrukturausfälle: Häufige Themen.

Grundlage in Google Cloud erstellen

Informationen zum Erstellen der Grundlage für Umgebungen mit einer einzelnen Region finden Sie unter Zu Google Cloud migrieren: Grundlage schaffen. Die Anleitung in diesem Dokument richtet sich an Nutzer, die eine Grundlage für die Migration von Arbeitslasten, Daten und Prozessen zu Google Cloud schaffen möchten. Sie ist aber auch für die Schaffung einer Grundlage für Umgebungen mit einer einzelnen Region geeignet. Lesen Sie dieses Dokument, nachdem Sie das gelesen haben.

Nachdem Sie die Grundlage in Google Cloud geschaffen haben, entwerfen und implementieren Sie Sicherheitskontrollen und -grenzen. Diese Sicherheitsmaßnahmen tragen dazu bei, dass Ihre Arbeitslasten, Daten und Prozesse in den jeweiligen Regionen verbleiben. Die Sicherheitsmaßnahmen tragen auch dazu bei, dass Ihre Ressourcen aufgrund von Fehlern, Fehlkonfigurationen oder schädlichen Angriffen nicht in andere Regionen gelangen.

Rechenressourcen bereitstellen und konfigurieren

Nachdem Sie die Grundlage für Ihre Umgebungen mit einer einzelnen Region geschaffen haben, stellen Sie Rechenressourcen bereit und konfigurieren sie. In den folgenden Abschnitten werden die Google Cloud-Computing-Produkte beschrieben, die regionale Bereitstellungen unterstützen.

Compute Engine

Compute Engine ist die Infrastructure-as-a-Service von Google Cloud. Sie verwendet die globale Infrastruktur von Google, um Kunden virtuelle Maschinen (und zugehörige Dienste) anzubieten.

Compute Engine-Ressourcen sind entweder zonal, z. B. virtuelle Maschinen oder zonale nichtflüchtige Speicher, regional, z. B. statische externe IP-Adressen, oder global, z. B. Snapshots von nichtflüchtigen Speichern. Weitere Informationen zu den zonalen, regionalen und globalen Ressourcen, die von der Compute Engine unterstützt werden, finden Sie unter Globale, regionale und zonale Ressourcen.

Um eine bessere Flexibilität und Ressourcenverwaltung physischer Ressourcen zu ermöglichen, werden Zonen in der Compute Engine von ihren physischen Ressourcen getrennt. Weitere Informationen zu dieser Abstraktion und ihren Auswirkungen finden Sie unter Zonen und Cluster.

So können Sie die Zuverlässigkeit Ihrer Umgebungen mit Compute Engine erhöhen:

  • Regionale verwaltete Instanzgruppen (MIGs) Virtuelle Compute Engine-Maschinen sind zonale Ressourcen und daher bei einem Zonenausfall nicht verfügbar. Um dieses Problem zu vermeiden, können Sie mit der Compute Engine regionale MIGs erstellen, mit denen virtuelle Maschinen automatisch in mehreren Zonen einer Region bereitgestellt werden, je nach Nachfrage und regionaler Verfügbarkeit. Wenn Ihre Arbeitslasten zustandsorientiert sind, können Sie auch regionale zustandsorientierte MIGs erstellen, um zustandsorientierte Daten und Konfigurationen beizubehalten. Regionale MIGs unterstützen die Simulation von Zonenausfällen. Informationen zum Simulieren eines zonalen Fehlers bei Verwendung einer regionalen MIG finden Sie unter Ausfall einer Zone für eine regionale MIG simulieren. Informationen zum Vergleich regionaler MIGs mit anderen Bereitstellungsoptionen finden Sie unter Compute Engine-Bereitstellungsstrategie für Ihre Arbeitslast auswählen.
  • Form der Zielverteilung. Bei regionalen MIGs werden virtuelle Maschinen gemäß der Zielverteilungsform verteilt. Damit sich die Verteilung der virtuellen Maschinen zwischen zwei Zonen in einer Region nicht um mehr als eine Einheit unterscheidet, empfehlen wir, beim Erstellen regionaler MIGs die Verteilungsform EVEN auszuwählen. Informationen zu den Unterschieden zwischen den Zielverteilungsformen finden Sie unter Vergleich der Formen.
  • Instanzvorlagen. Um die zu bereitzustellenden virtuellen Maschinen zu definieren, verwenden MIGs einen globalen Ressourcentyp namens Instanzvorlage. Obwohl Instanzvorlagen globale Ressourcen sind, können sie auf zonale oder regionale Ressourcen verweisen. Wenn Sie Instanzvorlagen erstellen, sollten Sie nach Möglichkeit auf regionale statt auf zonale Ressourcen verweisen. Wenn Sie zonale Ressourcen verwenden, sollten Sie die Auswirkungen dieser Nutzung bewerten. Wenn Sie beispielsweise eine Instanzvorlage erstellen, die auf ein nichtflüchtiges Speicher-Volume verweist, das nur in einer bestimmten Zone verfügbar ist, können Sie diese Vorlage in keiner anderen Zone verwenden, da das nichtflüchtige Speicher-Volume nicht in diesen anderen Zonen verfügbar ist.
  • 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. Um die Zuverlässigkeit und Flexibilität Ihrer Umgebungen zu erhöhen und die Verwaltungsanforderungen von selbst verwalteten Lösungen zu vermeiden, empfehlen wir Ihnen, Load Balancing und automatische Skalierung zu konfigurieren. Weitere Informationen zum Konfigurieren von Load Balancing und Skalierung für die Compute Engine finden Sie unter Load Balancing und Skalierung.
  • Ressourcenreservierungen konfigurieren Damit Ihre Umgebungen die erforderlichen Ressourcen haben, wenn Sie sie benötigen, empfehlen wir Ihnen, Ressourcenreservierungen zu konfigurieren, um die Kapazität für zonale Compute Engine-Ressourcen zu sichern. Wenn beispielsweise ein zonaler Ausfall auftritt, müssen Sie möglicherweise virtuelle Maschinen in einer anderen Zone bereitstellen, um die erforderliche Kapazität bereitzustellen und die aufgrund des Ausfalls nicht verfügbaren Kapazitäten zu kompensieren. Mit Ressourcenreservierungen sorgen Sie dafür, dass die Ressourcen für die Bereitstellung der zusätzlichen virtuellen Maschinen verfügbar sind.
  • Verwenden Sie zonale DNS-Namen. Um das Risiko von überregionalen Ausfällen zu verringern, empfehlen wir die Verwendung von zonalen DNS-Namen, um virtuelle Maschinen, die DNS-Namen in Ihren Umgebungen verwenden, eindeutig zu identifizieren. In Google Cloud werden standardmäßig zonale DNS-Namen für virtuelle Compute Engine-Maschinen 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 verwenden, die Sie später ändern können.
  • Wählen Sie die geeigneten Speicheroptionen aus. Die Compute Engine unterstützt mehrere Speicheroptionen für Ihre virtuellen Maschinen, z. B. nichtflüchtige Speicher-Volumes und lokale SSDs (Solid-State Drives):
    • Persistent Disk-Volumes sind auf mehrere physische Laufwerke verteilt und unabhängig von Ihren virtuellen Maschinen. Nichtflüchtige Speicher können zonal oder regional sein. Bei zonalen nichtflüchtigen Speichern werden Daten in einer einzelnen Zone gespeichert, während bei regionalen nichtflüchtigen Speichern Daten über zwei verschiedene Zonen repliziert werden. Wenn Sie Speicheroptionen für Ihre Umgebungen mit einer einzelnen Region auswählen, empfehlen wir Ihnen, regionale nichtflüchtige Speicher zu verwenden, da sie Failover-Optionen bei zonalen Ausfällen bieten. Weitere Informationen zum Reagieren auf zonale Fehler bei der Verwendung regionaler nichtflüchtiger Speicher finden Sie unter Hochverfügbarkeitsoptionen mit regionalen Persistent Disks und Failover für regionalen nichtflüchtigen Speicher.
    • Lokale SSDs haben einen hohen Durchsatz, speichern Daten aber nur, bis eine Instanz angehalten oder gelöscht wird. Daher eignen sich lokale SSDs ideal zum Speichern von temporären Daten, Caches und Daten, die Sie auf andere Weise rekonstruieren können. Nichtflüchtige Speicher sind langlebige Speichergeräte, auf die virtuelle Maschinen wie auf physische Laufwerke zugreifen können.
  • Mechanismen für den Datenschutz entwerfen und implementieren Beim Entwerfen Ihrer Umgebungen mit einer einzelnen Region empfehlen wir Ihnen, automatisierte Mechanismen zum Schutz Ihrer Daten einzurichten, falls es zu unerwünschten Ereignissen wie zonalen, regionalen oder multiregionalen Ausfällen oder vorsätzlichen Angriffen böswilliger Dritter kommt. Die Compute Engine bietet verschiedene Optionen zum Schutz Ihrer Daten. Sie können diese Datenoptionen als Bausteine verwenden, um Ihre Datenschutzprozesse zu entwerfen und umzusetzen.

GKE

Mit GKE können Sie containerisierte Arbeitslasten in Kubernetes bereitstellen, verwalten und skalieren. GKE basiert auf der Compute Engine. Daher gelten die Empfehlungen im vorherigen Abschnitt zur Compute Engine teilweise auch für GKE.

Um die Zuverlässigkeit Ihrer Umgebungen mit GKE zu erhöhen, sollten Sie die folgenden Designpunkte und GKE-Features berücksichtigen:

  • Verwenden Sie regionale GKE-Cluster, um die Verfügbarkeit zu erhöhen. GKE unterstützt je nach Clustertyp unterschiedliche Verfügbarkeitstypen für Ihre Cluster. GKE-Cluster können eine zonale oder regionale Steuerungsebene haben und Knoten, die in einer einzelnen Zone oder in mehreren Zonen innerhalb einer Region ausgeführt werden. Für verschiedene Clustertypen gelten auch unterschiedliche Service Level Agreements (SLAs). Um die Zuverlässigkeit Ihrer Umgebungen zu erhöhen, empfehlen wir die Verwendung regionaler Cluster. Wenn Sie die GKE Autopilot-Funktion verwenden, können Sie nur regionale Cluster bereitstellen.
  • Eine Multi-Cluster-Umgebung in Betracht ziehen Wenn Sie mehrere GKE-Cluster bereitstellen, können Sie die Flexibilität und Verfügbarkeit Ihrer Umgebung erhöhen. Die Komplexität steigt dadurch jedoch. Wenn Sie beispielsweise ein neues GKE-Feature verwenden müssen, das Sie nur beim Erstellen eines GKE-Clusters aktivieren können, können Sie Ausfallzeiten vermeiden und die Komplexität der Migration reduzieren. Fügen Sie dazu einen neuen {101 }GKE-Cluster Ihrer Multi-Cluster-Umgebung hinzu, stellen Sie Arbeitslasten im neuen Cluster bereit und löschen Sie den alten Cluster. Weitere Informationen zu den Vorteilen einer Multi-Cluster-GKE-Umgebung finden Sie unter Multi-Cluster-Anwendungsfälle. Um die Komplexität der Migration zu bewältigen, bietet Google Cloud die Flottenverwaltung, eine Reihe von Funktionen zur Verwaltung einer Gruppe von GKE-Clustern, ihrer Infrastruktur und der Arbeitslasten, die in diesen Clustern bereitgestellt werden.
  • Backup for GKE einrichten Sicherung für GKE ist ein regionaler Dienst zum Sichern der Arbeitslastkonfiguration und Volumes in einem Quell-GKE-Cluster und zum Wiederherstellen in einem Ziel-GKE-Cluster. Um die Arbeitslastkonfiguration und die Daten vor möglichen Verlusten zu schützen, empfehlen wir, Sicherung für GKE zu aktivieren und zu konfigurieren. Weitere Informationen finden Sie unter Backup for GKE – Übersicht.

Cloud Run

Cloud Run ist eine verwaltete Computing-Plattform zum Ausführen containerisierter Arbeitslasten. Cloud Run verwendet Dienste, um Ihnen die Infrastruktur zur Ausführung Ihrer Arbeitslasten zur Verfügung zu stellen. 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. Cloud Run wählt dann automatisch die Zonen innerhalb dieser Region aus, in denen Instanzen des Dienstes bereitgestellt werden sollen. Cloud Run verteilt den Traffic automatisch auf Dienstinstanzen und ist so konzipiert, dass die Auswirkungen eines Zonenausfalls erheblich gemildert werden.

VMware Engine

VMware Engine ist ein vollständig verwalteter Dienst, mit dem Sie die VMware-Plattform in Google Cloud ausführen können. Um die Zuverlässigkeit Ihrer Umgebungen mit VMware Engine zu erhöhen, empfehlen wir Folgendes:

  • Private VMware Engine-Clouds mit mehreren Knoten bereitstellen Die VMware Engine unterstützt die Bereitstellung isolierter VMware-Stacks, die als private Clouds bezeichnet werden. Alle Knoten, aus denen eine private Cloud besteht, befinden sich in derselben Region. Private Cloud-Knoten werden auf dedizierten, isolierten Bare-Metal-Hardware-Knoten ausgeführt und so konfiguriert, dass Single Points of Failure vermieden werden. Die VMware Engine unterstützt private Clouds mit nur einem Knoten. Wir empfehlen jedoch, sie nur für Proofs of Concept und Tests zu verwenden. Für Produktionsumgebungen empfehlen wir die standardmäßigen privaten Clouds mit mehreren Knoten.
  • Verteilte private VMware Engine-Clouds bereitstellen Eine gestreckte private Cloud ist eine Multi-Knoten-Private Cloud, deren Knoten auf die Zonen in einer Region verteilt sind. Eine gestreckte Private Cloud schützt Ihre Umgebung vor zonenspezifischen Ausfällen.

Weitere Informationen zu den Hochverfügbarkeits- und Redundanzfunktionen der VMware Engine finden Sie unter Verfügbarkeit und Redundanz.

Datenspeicherressourcen bereitstellen und konfigurieren

Nachdem Sie Rechenressourcen für Ihre Umgebungen mit einer einzelnen Region bereitgestellt und konfiguriert haben, stellen Sie Ressourcen zum Speichern und Verwalten von Daten bereit und konfigurieren sie. In den folgenden Abschnitten werden die Google Cloud-Datenspeicher- und ‑verwaltungsprodukte beschrieben, die regionale und multiregionale Konfigurationen unterstützen.

Cloud Storage

Cloud Storage ist ein Dienst, der Objekte, also unveränderliche Daten, in Buckets speichern soll, bei denen es sich um einfache Container für Ihre Daten handelt. Wenn Sie einen Bucket erstellen, wählen Sie den Bucket-Standorttyp aus, der Ihren Verfügbarkeits-, rechtlichen und anderen Anforderungen am besten entspricht. Für die verschiedenen Standorttypen gelten unterschiedliche Verfügbarkeitsgarantien. Damit Ihre Daten vor Fehlern und Ausfällen geschützt sind, macht Cloud Storage Ihre Daten in mindestens zwei Zonen für Buckets, die einen Standorttyp haben, redundant. In zwei Regionen für Buckets mit zwei Regionen. Für zwei oder mehr Regionen für Buckets, die einen multiregionalen Standorttyp haben. Wenn Sie beispielsweise einen Cloud Storage-Bucket verfügbar machen möchten, wenn es Zonenausfalle gibt, können Sie ihn mit einem regionalen Standorttyp bereitstellen.

Weitere Informationen zum Entwerfen von Notfallmechanismen für in Cloud Storage gespeicherte Daten und zur Reaktion von Cloud Storage auf zonale und regionale Ausfälle finden Sie unter Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Cloud Storage.

Filestore

Filestore bietet vollständig verwaltete Dateiserver in Google Cloud, die mit Compute Engine-Instanzen, GKE-Clustern und Ihren lokalen Maschinen verbunden werden können. Filestore bietet mehrere Dienststufen. Jede Stufe bietet einzigartige Verfügbarkeits-, Skalierbarkeits-, Leistungs-, Kapazitäts- und Datenwiederherstellungsfunktionen. Wenn Sie Filestore-Instanzen bereitstellen, empfehlen wir die Enterprise-Stufe, da sie eine hohe Verfügbarkeit und Datenredundanz über mehrere Zonen in einer Region unterstützt. Instanzen in anderen Stufen sind zonale Ressourcen.

Bigtable

Bigtable ist ein vollständig verwalteter, leistungsstarker und hoch skalierbarer Datenbankdienst für große analytische und operative Arbeitslasten. Bigtable-Instanzen sind zonal begrenzte Ressourcen. Um die Zuverlässigkeit Ihrer Instanzen zu erhöhen, können Sie Bigtable so konfigurieren, dass Daten in mehreren Zonen innerhalb derselben Region oder in mehreren Regionen repliziert werden. Wenn die Replikation aktiviert ist und es zu einer Störung kommt, leitet Bigtable Anfragen automatisch an andere verfügbare Instanzen weiter, in denen Sie Daten repliziert haben.

Weitere Informationen zur Funktionsweise der Replikation in Bigtable finden Sie unter Replikation und Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Bigtable.

Firestore

Firestore ist eine flexible, skalierbare Datenbank für die Mobil-, Web- und Serverentwicklung über Firebase und Google Cloud. Wenn Sie eine Firestore-Datenbank bereitstellen, wählen Sie den Speicherort aus. Standorte können entweder multiregional oder regional sein und bieten unterschiedliche Zuverlässigkeitsgarantien. Wenn eine Datenbank einen regionalen Speicherort hat, werden die Daten in verschiedenen Zonen innerhalb einer Region repliziert. Bei einer multiregionalen Datenbank werden Daten in mehreren Regionen repliziert.

Informationen zur Funktionsweise der Replikation in Firestore und zur Reaktion von Firestore auf zonale und regionale Ausfälle finden Sie unter Firestore-Standorte und Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Firestore.

Memorystore

Mit Memorystore können Sie skalierbare, sichere und hochverfügbare In-Memory-Datenspeicherdienste konfigurieren. Es unterstützt Daten-Backends für Redis, Memcached und Valkey.

Wenn Sie Memorystore for Redis-Instanzen bereitstellen, wählen Sie für diese Instanz eine Dienstebene aus. Memorystore for Redis unterstützt mehrere Instanzdienststufen. Jede Stufe bietet spezifische Verfügbarkeits-, Knotengrößen- und Bandbreitenfunktionen. Wenn Sie eine Memorystore for Redis-Instanz bereitstellen, empfehlen wir die Standardstufe oder die Standardstufe mit Lesereplikaten. Memorystore-Instanzen in diesen beiden Stufen replizieren Daten automatisch über mehrere Zonen in einer Region. Weitere Informationen dazu, wie Memorystore for Redis eine hohe Verfügbarkeit erreicht, finden Sie unter Hochverfügbarkeit für Memorystore for Redis.

Beachten Sie beim Bereitstellen von Memorystore for Memcached-Instanzen Folgendes:

  • Zonenauswahl. Wenn Sie Memorystore for Memcached-Instanzen bereitstellen, wählen Sie die Region aus, in der Sie die Instanz bereitstellen möchten. Anschließend können Sie entweder die Zonen innerhalb dieser Region auswählen, in denen Sie die Knoten dieser Instanz bereitstellen möchten, oder Memorystore for Memcached die Knoten automatisch auf die Zonen verteilen lassen. Um Instanzen optimal zu platzieren und Bereitstellungsprobleme wie das Platzieren aller Knoten in derselben Zone zu vermeiden, empfehlen wir, dass Sie Memorystore for Memcached die automatische Verteilung von Knoten auf Zonen innerhalb einer Region überlassen.
  • Zonenübergreifende Datenreplikation Bei Memorystore for Memcached-Instanzen werden keine Daten über Zonen oder Regionen hinweg repliziert. Weitere Informationen zur Funktionsweise von Memorystore for Memcached-Instanzen bei zonalen oder regionalen Ausfällen finden Sie unter Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Memorystore for Memcached.

Wenn Sie Memorystore for Valkey-Instanzen bereitstellen, wählen Sie Optionen für Verfügbarkeit und Zuverlässigkeit aus. Memorystore for Valkey unterstützt mehrere Konfigurationen, z. B. zonale und mehrzonige Instanzen. Weitere Informationen zur Verfügbarkeit und Zuverlässigkeit von Memorystore for Valkey finden Sie unter Memorystore for Valkey: Hochverfügbarkeit und Replikate.

Spanner

Spanner ist eine vollständig verwaltete relationale Datenbank mit unbegrenzter Skalierung, strikter Konsistenz und bis zu 99,999% Verfügbarkeit. Damit Sie Spanner verwenden können, müssen Sie Spanner-Instanzen bereitstellen. Beachten Sie beim Bereitstellen von Spanner-Instanzen Folgendes:

  • Instanzkonfiguration. Eine Instanzkonfiguration definiert die geografische Platzierung und Replikation der Datenbanken in einer Spanner-Instanz. Wenn Sie eine Spanner-Instanz erstellen, konfigurieren Sie sie entweder als regional oder als multiregional.
  • Replikation. Spanner unterstützt die automatische Replikation auf Byte-Ebene und die Erstellung von Replikaten gemäß Ihren Anforderungen an Verfügbarkeit, Zuverlässigkeit und Skalierbarkeit. Sie können Replikate auf Regionen und Umgebungen verteilen. Spanner-Instanzen mit einer regionalen Konfiguration verwalten ein nicht schreibgeschütztes Replikat für jede Zone innerhalb einer Region. Instanzen mit einer multiregionalen Konfiguration replizieren Daten in mehreren Zonen über mehrere Regionen hinweg.
  • Instanzen verschieben. Mit Spanner können Sie eine Instanz aus einer beliebigen Instanzkonfiguration in eine andere Instanzkonfiguration verschieben, ohne dass es zu Ausfallzeiten oder einer Unterbrechung der Transaktionsgarantien während des Verschiebens kommt.

Weitere Informationen zur Spanner-Replikation und zur Reaktion von Spanner auf zonale und regionale Ausfälle finden Sie unter Spanner-Replikation und Architektonische Notfallwiederherstellung für die Cloud-Infrastruktur: Ausfälle: Spanner.

Datenanalyseressourcen bereitstellen und konfigurieren

Nachdem Sie Datenspeicherressourcen für Ihre Umgebungen mit einer Region bereitgestellt und konfiguriert haben, stellen Sie Datenanalyseressourcen bereit und konfigurieren sie. In den folgenden Abschnitten werden die Google Cloud-Produkte für die Datenanalyse beschrieben, die regionale Konfigurationen unterstützen.

BigQuery

BigQuery ist ein vollständig verwaltetes Data Warehouse für Unternehmen, mit dem Sie Ihre Daten mit integrierten Features wie maschinellem Lernen, raumbezogenen Analysen und Business Intelligence verwalten und analysieren können.

Um den Zugriff auf Daten in BigQuery zu organisieren und zu steuern, stellen Sie Top-Level-Container bereit, die Datasets genannt werden. Beachten Sie beim Bereitstellen von BigQuery-Datasets Folgendes:

  • Dataset-Standort Um den BigQuery-Speicherort auszuwählen, an dem Sie Ihre Daten speichern möchten, konfigurieren Sie den Speicherort des Datasets. Ein Standort kann entweder regional oder multiregional sein. Für jeden Standorttyp speichert BigQuery Kopien Ihrer Daten in zwei verschiedenen Zonen am ausgewählten Standort. Sie können den Speicherort eines Datasets nach der Erstellung nicht mehr ändern.
  • Katastrophenplanung BigQuery ist ein regionaler Dienst, der Zonenausfalle automatisch für Computing und Daten verarbeitet. Es gibt jedoch bestimmte Szenarien, für die Sie selbst planen müssen, z. B. regionale Ausfälle. Wir empfehlen Ihnen, diese Szenarien beim Entwerfen Ihrer Umgebungen zu berücksichtigen.

Weitere Informationen zur Planung und zu den Funktionen der Notfallwiederherstellung in BigQuery finden Sie in der BigQuery-Dokumentation unter Zuverlässigkeit verstehen: Notfallwiederherstellung und unter Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: BigQuery.

Dataproc

Dataproc ist ein verwalteter Dienst, mit dem Sie Open-Source-Datentools für Batchverarbeitung, Abfragen, Streaming und maschinelles Lernen nutzen können. Dataproc basiert auf der Compute Engine. Die Empfehlungen im vorherigen Abschnitt zur Compute Engine gelten daher teilweise auch für Dataproc.

Wenn Sie Dataproc verwenden möchten, müssen Sie Dataproc-Cluster erstellen. Dataproc-Cluster sind zonale Ressourcen. Beachten Sie beim Erstellen von Dataproc-Clustern Folgendes:

  • Automatische Zonenplatzierung Wenn Sie einen Cluster erstellen, können Sie entweder die Zone innerhalb einer Region angeben, in der Sie die Knoten des Clusters bereitstellen möchten, oder die automatische Zonenplatzierung in Dataproc die Zone automatisch auswählen lassen. Wir empfehlen die automatische Zonenplatzierung, es sei denn, Sie müssen die Zonenplatzierung von Clusterknoten innerhalb der Region optimieren.
  • Modus für hohe Verfügbarkeit Wenn Sie einen Cluster erstellen, können Sie den Hochverfügbarkeitsmodus aktivieren. Sie können den Hochverfügbarkeitsmodus nicht aktivieren, nachdem Sie einen Cluster erstellt haben. Wir empfehlen, den Hochverfügbarkeitsmodus zu aktivieren, wenn der Cluster robust gegen den Ausfall eines einzelnen Koordinatorknotens oder gegen teilweise zonale Ausfälle sein soll. Dataproc-Cluster mit Hochverfügbarkeit sind zonale Ressourcen.

Weitere Informationen dazu, wie Dataproc auf zonale und regionale Ausfälle reagiert und wie Sie die Zuverlässigkeit Ihrer Dataproc-Cluster erhöhen, wenn Fehler auftreten, finden Sie unter.Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Dataproc eine

Dataflow

Dataflow ist ein vollständig verwalteter Dienst zum Ausführen von Streaming- und Batch-Datenverarbeitungspipelines. Zur Verwendung von Dataflow erstellen Sie Dataflow-Pipelines und Dataflow führt dann Jobs aus. Diese sind Instanzen dieser Pipelines auf Worker-Knoten. Da Jobs zonale Ressourcen sind, sollten Sie bei der Verwendung von Dataflow-Ressourcen Folgendes beachten:

  • Regionale Endpunkte Wenn Sie einen Job erstellen, müssen Sie in Dataflow einen regionalen Endpunkt konfigurieren. Wenn Sie einen regionalen Endpunkt für Ihren Job konfigurieren, beschränken Sie die Platzierung von Rechen- und Datenressourcen auf eine bestimmte Region.
  • Zonenbasierte Platzierung Dataflow verteilt Worker-Knoten je nach Jobtyp automatisch auf alle Zonen innerhalb einer Region oder auf die beste Zone innerhalb einer Region. Mit Dataflow können Sie die zonale Platzierung von Worker-Knoten überschreiben, indem Sie alle Worker-Knoten in derselben Zone innerhalb einer Region platzieren. Um Probleme durch Zonenausfalle zu vermeiden, empfehlen wir, die automatische Zonenplatzierung durch Dataflow zu verwenden, es sei denn, Sie müssen die Worker-Knoten in einer bestimmten Zone platzieren.

Weitere Informationen dazu, wie Dataproc auf zonale und regionale Ausfälle reagiert und wie Sie die Zuverlässigkeit Ihrer Dataproc-Cluster erhöhen, wenn Fehler auftreten, finden Sie unter.Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Dataflow eine

Pub/Sub

Pub/Sub ist ein asynchroner, skalierbarer Messaging-Dienst, der Dienste entkoppelt, die Nachrichten von Diensten erzeugen, die diese Nachrichten verarbeiten. Pub/Sub organisiert Nachrichten in Themen. Publisher (Dienste, die Nachrichten erstellen) senden Nachrichten an Themen und Abonnenten erhalten Nachrichten von Themen. Pub/Sub speichert jede Nachricht in einer einzelnen Region und repliziert sie in mindestens zwei Zonen innerhalb dieser Region. Weitere Informationen finden Sie unter Architekturübersicht von Pub/Sub.

Berücksichtigen Sie beim Konfigurieren Ihrer Pub/Sub-Umgebung Folgendes:

  • Globale und regionale Endpunkte Pub/Sub unterstützt globale und regionale Endpunkte zum Veröffentlichen von Nachrichten. Wenn ein Publisher eine Nachricht an den globalen Endpunkt sendet, wählt Pub/Sub automatisch die nächstgelegene Region aus, um diese Nachricht zu verarbeiten. Wenn ein Produzent eine Nachricht an einen regionalen Endpunkt sendet, verarbeitet Pub/Sub die Nachricht in dieser Region.
  • Richtlinien für die Speicherung von Nachrichten Mit Pub/Sub können Sie Richtlinien für den Nachrichtenspeicher konfigurieren, um einzuschränken, wo Pub/Sub Nachrichten verarbeitet und speichert, unabhängig vom Ursprung der Anfrage und dem Endpunkt, mit dem der Publisher die Nachricht veröffentlicht hat. Wir empfehlen, Speicherrichtlinien für Nachrichten zu konfigurieren, damit Nachrichten nicht Ihre Umgebung mit einer einzelnen Region verlassen.

Weitere Informationen dazu, wie Pub/Sub zonale und regionale Ausfälle handhabt, finden Sie unter Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Pub/Sub.

Arbeitslasten an Umgebungen mit nur einer Region anpassen

Wenn Sie die Bereitstellung und Konfiguration Ihrer Umgebungen abgeschlossen haben, müssen Sie überlegen, wie Sie Ihre Arbeitslasten widerstandsfähiger gegen zonale und regionale Ausfälle machen. Für jede Arbeitslast gelten eigene Verfügbarkeits- und Zuverlässigkeitsanforderungen sowie Eigenschaften. Es gibt jedoch einige Designprinzipien, die Sie anwenden können, sowie Strategien, mit denen Sie die Ausfallsicherheit im unwahrscheinlichen Fall von zonalen und regionalen Ausfällen verbessern können. Beachten Sie beim Entwerfen und Implementieren Ihrer Arbeitslasten Folgendes:

  • Implementieren Sie SRE-Praktiken und SRE-Grundsätze (Site Reliability Engineering). Automatisierung und umfassendes Monitoring sind Teil der Kernprinzipien von SRE. Google Cloud bietet die Tools und Dienstleistungen zur Implementierung von SRE, um die Resilienz und Zuverlässigkeit Ihrer Umgebungen zu erhöhen und den Aufwand zu reduzieren.
  • Entwicklung für Skalierbarkeit und Ausfallsicherheit. Wenn Sie Arbeitslasten für Cloud-Umgebungen entwerfen, sollten Sie Skalierbarkeit und Ausfallsicherheit als grundlegende Anforderungen betrachten, die Ihre Arbeitslasten erfüllen müssen. Weitere Informationen zu dieser Art von Design finden Sie unter Muster für skalierbare und robuste Anwendungen.
  • Design für die Wiederherstellung nach Ausfällen der Cloud-Infrastruktur Die Verfügbarkeitsgarantien von Google Cloud sind in den Google Cloud-Service Level Agreements definiert. Für den unwahrscheinlichen Fall eines zonalen oder regionalen Ausfalls empfehlen wir Ihnen, Ihre Arbeitslasten so zu gestalten, dass sie gegen zonale und regionale Ausfälle resistent sind.
  • Implementieren Sie Entlastungsfunktionen (Load Shedding) und Graduelle Fehlertoleranz. Bei Ausfällen der Cloud-Infrastruktur oder anderer Abhängigkeiten Ihrer Arbeitslasten empfehlen wir, Ihre Arbeitslasten so zu gestalten, dass sie ausfallsicher sind. Ihre Arbeitslasten sollten bestimmte und klar definierte Funktionalitätsebenen beibehalten, auch wenn Fehler auftreten (ordnungsgemäße Verschlechterung) und sie sollten einen Teil ihrer Last bewältigen können, während sie sich den Überlastungsbedingungen annähern (Load Shedding).
  • Planen Sie regelmäßige Wartungen. Wenn Sie Ihre Bereitstellungsprozesse und Ihre operativen Prozesse entwerfen, empfehlen wir Ihnen, auch alle Aktivitäten zu berücksichtigen, die Sie für die regelmäßige Wartung Ihrer Umgebungen ausführen müssen. Die regelmäßige Wartung sollte Aktivitäten wie das Anwenden von Updates und Konfigurationsänderungen auf Ihre Arbeitslasten und ihre Abhängigkeiten sowie die Auswirkungen dieser Aktivitäten auf die Verfügbarkeit Ihrer Umgebungen umfassen. Sie können beispielsweise eine Hostwartungsrichtlinie für Ihre Compute Engine-Instanzen konfigurieren.
  • Verwenden Sie einen testgetriebenen Entwicklungsansatz. Beim Entwerfen Ihrer Arbeitslasten empfehlen wir einen testgetriebenen Ansatz, um sicherzustellen, dass sich Ihre Arbeitslasten in jeder Hinsicht wie vorgesehen verhalten. So können Sie beispielsweise testen, ob Ihre Arbeitslasten und Ihre Cloud-Infrastruktur die erforderlichen funktionalen, nicht funktionalen und Sicherheitsanforderungen erfüllen.

Nächste Schritte

Beitragende

Autor: Marco Ferrari | Cloud Solutions Architect

Weitere Beitragende: