Migration zwischen Google Cloud-Regionen: Resiliente Umgebungen mit einer Region in Google Cloud

Last reviewed 2024-12-08 UTC

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

Dieses Dokument ist Teil der folgenden Reihe:

In diesem Dokument erfahren Sie, wie Sie robuste Umgebungen mit einer einzelnen Region in Google Cloudentwerfen. 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 Umgebungen und Ihrer 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.

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 für die Zuverlässigkeitsgarantien zu sorgen, die für Ihre Umgebung erforderlich sind. So ist es beispielsweise wahrscheinlicher, dass eine Umgebung mit mehreren Regionen einen regionalen Ausfall übersteht, als es bei einer Umgebung mit einer einzelnen Region oder einer zonalen Umgebung der Fall ist. Weitere Informationen zu den Zuverlässigkeitseigenschaften der einzelnen Bereitstellungsarchetypen finden Sie unter Wie Sie Zonen und Regionen nutzen, um Zuverlässigkeit zu erreichen und im Leitfaden zur Zuverlässigkeit derGoogle Cloud-

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 kann eine zonale Umgebung im Vergleich zu einer regionalen oder multiregionalen Umgebung beispielsweise kostengünstiger und einfacher zu entwerfen, zu implementieren und zu betreiben sein. Der potenzielle geringere Aufwand und die geringeren Kosten der zonalen Umgebung sind auf den zusätzlichen Aufwand 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 Grundlage der einzelnen Architekturen erforderlich ist.

Name des Bereitstellungsarchetyps Ressourcenverteilung Hilfe beim Vermeiden von Designkomplexität
Zonale Umgebung In einer einzelnen Zone Ressourcenausfälle Erfordert Koordination innerhalb einer einzelnen Zone
Umgebung mit einer Region In mehreren Zonen in einer Region Ressourcenausfälle, zonale Ausfälle Erfordert die Koordination über mehrere Zonen in einer Region
Multiregionale Umgebung Über mehrere Zonen, über mehrere Regionen Ressourcenausfälle, zonale Ausfälle, regionale Ausfälle, multiregionale Ausfälle Erfordert Koordination über mehrere Zonen und Regionen hinweg
Globale Umgebung Über mehrere Zonen, über mehrere Regionen weltweit Ressourcenausfälle, zonale Ausfälle, regionale Ausfälle, multiregionale 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. Werten Sie die Bereitstellungsarchetypen aus, um zu ermitteln, welcher 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 Fehlermodelle erforderlich? Fehlermodelle können auf alles angewendet werden, was Sie inGoogle Cloudbereitstellen oder implementieren. Ein Fehlermodell kann auf eine einzelne Person oder auf alle Ressourcen in einer Zone oder Region angewendet werden. Wir empfehlen, ein Fehlermodell 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 Service-Levels für diese Komponente definieren, und eigene Anforderungen an die Notfallwiederherstellung. 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, sind in der Regel mehr Aufwand und Ressourcen nötig. Wenn Sie Ihre Fehlermodelle definieren, empfehlen wir, mehrere Fehlermodelle 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 Fehlermodelle, um vor Ausfällen zu schützen? Um sich vor den von Ihnen definierten Fehlermodellen 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, auszuwerten, wie viele Ressourcen Sie für jedes von Ihnen definierte Fehlermodell benötigen.
  • Wie erkennen Sie, dass ein Ausfall 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 zum 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 Fehlermodelle 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 auswerten, Fehler zu tolerieren, indem Sie Chaos Engineering verwenden.
  • Welche Auswirkungen erwarten Sie, wenn ein bestimmtes Fehlermodell auftritt? Um die Auswirkungen eines Ausfalls auf Ihr Unternehmen zu verstehen, empfehlen wir, für jedes Fehlermodell 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 Fehlermodellen voraussichtlich andauern? Die Dauer eines Ausfalls kann sich stark 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 Fehler zu erkennen, zu beheben und die ausgefallenen Ressourcen wiederherzustellen.

Weitere Informationen zu Fehlermodellen und zur Erstellung eines zuverlässigen Notfallwiederherstellungsplans finden Sie unter Architektonische 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, welcher Ihren Anforderungen am besten entspricht. Berücksichtigen Sie bei der Bewertung der Bereitstellungsarchetypen die folgenden Fragen:

  • Wie viele Bereitstellungsarchetypen benötigen Sie? Sie müssen nicht nur einen Bereitstellungsarchetyp für alle Umgebungen auswählen. Stattdessen können Sie einen hybriden Ansatz implementieren, bei dem Sie mehrere Bereitstellungsarchetypen entsprechend den Zuverlässigkeitsgarantien auswählen, die Sie benötigen, um sich vor den von Ihnen definierten Fehlermodellen zu schützen. Wenn Sie beispielsweise zwei Fehlermodelle definiert haben, für die eine zonale und eine regionale Umgebung erforderlich sind, sollten Sie separate Bereitstellungsarchetypen auswählen, um sich vor jedem Fehlermodell zu schützen. Wenn Sie mehrere Bereitstellungsarchetypen 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 Bereitstellungsarchetypen 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 einerGoogle Cloud -Umgebung in eine andere Google Cloud-Umgebung 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 multiregionale Umgebung für geschäftskritische Arbeitslasten, Daten und Prozesse und eine zonale oder regionale Umgebung für weniger kritische Arbeitslasten, Daten und Prozesse entwerfen und implementieren.
  • Benötigen Sie die Funktionen, die bestimmte Bereitstellungsarchetypen für bestimmte Umgebungen bieten? 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 Bereitstellungsarchetypen für Ihre Umgebungen auswählen.

Neben den technischen Aspekten der Fehlermodi, die Sie anhand der vorherigen Anleitung definiert haben, empfehlen wir Ihnen, auch alle nicht funktionalen Anforderungen wie regulatorische, 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 zonale 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, welcheGoogle 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 Clouderfüllt. Wenn Ihre Arbeitslasten und Daten beispielsweise Latenzanforderungen für Ihre Nutzer oder andere Umgebungen außerhalb von Google Cloudhaben, 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 den Ort 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 vonGoogle Cloudplatzieren, 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 Cloudgewä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 vonGoogle 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. Die verfügbaren Regionen und Zonen für Compute Engine bieten beispielsweise bestimmte Maschinentypen in bestimmtenGoogle 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? Bei Google Cloud werden Kontingente verwendet, um festzulegen, welcher Anteil einer freigegebenen Google Cloud -Ressource genutzt werden kann. Einige Kontingente sind global und gelten für Ihre Nutzung der Ressource überall inGoogle 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:

  • Wünschen Sie sich einen geringen CO2-Fußabdruck? Google Cloudinvestiert 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 Entitäten 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 derGoogle Cloud -Regionen für Ihre Umgebungen Ihre aktuellen und anstehenden gesetzlichen Anforderungen zu berücksichtigen und dieGoogle 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 Cloudschaffen
  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 erreichen. Bei dieser Konfiguration können jedoch nicht alle Zuverlässigkeitsfunktionen der Google-Infrastruktur genutzt werden, die die Dienste von Google Cloud unterstützen.
  • Prüfen, ob die Umgebungen mit den Annahmen des Fehlermodells 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 zonale Ausfä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

Informationen zum Erstellen der Grundlage für Umgebungen mit einer einzelnen Region finden Sie unter Zu Google Cloudmigrieren: Grundlage planen und erstellen. Die Anleitung in diesem Dokument richtet sich an Nutzer, die eine Grundlage für die Migration von Arbeitslasten, Daten und Prozessen zu Google Cloudschaffen 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 Cloudgeschaffen 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 nicht aufgrund von Fehlern, Fehlkonfigurationen oder schädlichen Angriffen in andere Regionen gelangen.

Rechenressourcen bereitstellen und konfigurieren

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

Compute Engine

Die Compute Engine ist die Infrastructure as a Service (IaaS) 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. nichtflüchtige Speicher-Snapshots. Weitere Informationen zu den zonalen, regionalen und globalen Ressourcen, die von Compute Engine unterstützt werden, finden Sie unter Globale, regionale und zonale Ressourcen.

Um die Flexibilität und Ressourcenverwaltung physischer Ressourcen zu verbessern, werden Zonen in 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 zonalen Ausfall nicht verfügbar. Um dieses Problem zu vermeiden, können Sie mit 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 zonalen Ausfällen. Informationen zum Simulieren eines zonalen Ausfalls 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 mit der Bezeichnung 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 auswerten. 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. 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 Autoscaling zu konfigurieren. Weitere Informationen zum Konfigurieren des Load Balancing und der Skalierung für 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.

  • Zonale DNS-Namen verwenden. 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 von 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.

  • Geeignete Speicheroptionen auswählen. Die Compute Engine unterstützt mehrere Speicheroptionen für Ihre virtuellen Maschinen, z. B. nichtflüchtige Speicher-Volumes und lokale SSDs (Solid State Drives):

    • Nichtflüchtige Speicher-Volumes sind auf mehrere physische Laufwerke verteilt und unabhängig von Ihren virtuellen Maschinen. Nichtflüchtige Speicher können zonal oder regional sein. Auf zonalen nichtflüchtigen Speichern werden Daten in einer einzelnen Zone gespeichert, während regionale nichtflüchtige Speicher Daten über zwei verschiedene Zonen replizieren. 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 so lange, 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. 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 zu 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:

  • Regionale GKE-Cluster verwenden, 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 und Knoten haben, die in einer einzelnen Zone oder in mehreren Zonen innerhalb einer Region ausgeführt werden. Für verschiedene Clustertypen werden auch unterschiedliche Service Level Agreements (SLAs) angeboten. 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 Clouddie 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 Backup for 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, Backup for 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 für die 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 inGoogle Cloudausfü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. 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. 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.
  • Erweiterte private VMware Engine-Clouds bereitstellen. Eine erweiterte private Cloud ist eine private Cloud mit mehreren Knoten, deren Knoten auf die Zonen in einer Region verteilt sind. Eine erweiterte private Cloud schützt Ihre Umgebung vor zonalen Ausfällen.

Weitere Informationen zu den Hochverfügbarkeits- und Redundanzfunktionen von 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- Produkte für Datenspeicherung und ‑verwaltung 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-, regulatorischen 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 dazu, wie Cloud Storage auf zonale und regionale Ausfälle reagiert, 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 zonale 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 von 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 Standort aus. Standorte können entweder multiregional oder regional sein und bieten unterschiedliche Zuverlässigkeitsgarantien. Wenn eine Datenbank einen regionalen Standort 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. Die Lösung 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 Dienststufe 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 der 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 die Knoten automatisch von Memorystore for Memcached in Zonen innerhalb einer Region verteilen lassen.
  • 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 einzelnen Region bereitgestellt und konfiguriert haben, können Sie Datenanalyseressourcen bereitstellen und konfigurieren. 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-Ort auszuwählen, an dem Sie Ihre Daten speichern möchten, konfigurieren Sie den Standort 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 Standort eines Datasets nach der Erstellung nicht mehr ändern.
  • Katastrophenplanung BigQuery ist ein regionaler Dienst, der zonale Ausfalle 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 den Features der BigQuery-Notfallwiederherstellung 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.
  • Zonale 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 zonale Ausfälle zu vermeiden, empfehlen wir, die automatische Zonenplatzierung von Dataflow auswählen zu lassen, 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 Producer 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 Ihre Umgebung mit einer einzelnen Region nicht 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:

  • Implementierung von 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 professionellen Dienstleistungen zur Implementierung von SRE, um die Robustheit 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 Robustheit als grundlegende Anforderungen betrachten, die Ihre Arbeitslasten erfüllen müssen. Weitere Informationen zu dieser Art von Design finden Sie unter Skalierbare und robuste Anwendungen erstellen.
  • Entwicklung für die Wiederherstellung nach Ausfällen der Cloud-Infrastruktur Die Verfügbarkeitsgarantien vonGoogle 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 für zonale und regionale Ausfälle gewappnet sind.
  • Implementierung von Entlastungsfunktionen (Load Shedding) und gradueller 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 regelmäßiger 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 das Prüfen der Auswirkungen dieser Aktivitäten auf die Verfügbarkeit Ihrer Umgebungen umfassen. Sie können beispielsweise eine Hostwartungsrichtlinie für Ihre Compute Engine-Instanzen konfigurieren.
  • Verwendung eines testgesteuerten Entwicklungsansatzes. Beim Entwerfen Ihrer Arbeitslasten empfehlen wir einen testgesteuerten 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 sicherheitsbezogenen Anforderungen erfüllen.

Nächste Schritte

Beitragende

Autor: Marco Ferrari | Cloud Solutions Architect

Weitere Beitragende: