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

In diesem Dokument erfahren Sie, wie Sie stabile Umgebungen mit einer Region fürGoogle 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 wird erläutert, wie Sie stabile Umgebungen mit einer 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 Umwandlung Ihrer zonalen und einzelnen Regionen zu multiregionalen Umgebungen in Betracht ziehen, finden Sie weitere Informationen unter Migration zwischen Google Cloud Regionen: Erste Schritte.

Attribute verschiedener Deployment-Archetypen

Google Cloud -Produkte werden in vielen Regionen und Zonen bereitgestellt.

Wenn Sie Ihre Google Cloud -Umgebung entwerfen, können Sie zwischen den folgenden Bereitstellungsarchetypen wählen, die nach Erhöhung der Zuverlässigkeit und des operativen Aufwands vorgestellt werden:

  • Zonal: Sie stellen Google Cloud Ressourcen in einer einzelnen Zone innerhalb einer Region bereit und verwenden zonale Dienste, wo sie verfügbar sind. Wenn zonale Dienste nicht verfügbar sind, verwenden Sie regionale Dienste.
  • Regional: Sie stellen Google CloudRessourcen 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 jedes Bereitstellungsarchetyps finden Sie unter Mit Zonen und Regionen Zuverlässigkeit erreichen und im Google Cloud Leitfaden zur Zuverlässigkeit der Infrastruktur.

Das Entwerfen, Implementieren und Betreiben einer Umgebung auf der Grundlage dieser Bereitstellungsarchetypen erfordert aufgrund der Kosten- und Komplexitätseigenschaften der einzelnen Bereitstellungsarchetypen einen 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 werden 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 Bereitstellungs-Archetyps 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 Umwelt Über mehrere Zonen, 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 Bereitstellungsarchetypen finden Sie unter Google Cloud Bereitstellungsarchetypen.

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 unterGoogle Cloudbereitstellen oder bereitstellen. Ein Fehlermodell kann auf eine einzelne Person oder auf alle Ressourcen in einer Zone oder Region angewendet werden. Wir empfehlen, ein Fehlermodell auf alle Ressourcen anzuwenden, die einen Mehrwert bieten, z. B. Arbeitslasten, Daten, Prozesse und alle Ressourcen Google Cloud.
  • 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 Ihre 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 genau wissen, wie viele Ressourcen Sie benötigen, können Sie die Kompromisse zwischen den Zuverlässigkeitsgarantien, die jeder Bereitstellungsarchetyp bietet, und den Kosten und der Komplexität der Entwicklung, Implementierung und Ausführung von Umgebungen auf Grundlage dieser Archetypen abwägen.
  • Möchten Sie eine Umgebung, die auf einem Bereitstellungsarchetyp basiert, in eine Umgebung mit einem anderen Archetyp migrieren? In Zukunft können Sie Arbeitslasten, Daten und Prozesse von 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 Features, die von bestimmten Bereitstellungsarchetypen für bestimmte Umgebungen angeboten werden? Abgesehen von den Zuverlässigkeitsgarantien, die jeder Bereitstellungsarchetyp bietet, bieten die Archetypen auch unterschiedliche Garantien hinsichtlich Skalierbarkeit, geografischer Nähe, Latenz und Datenlokalität. 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.

Wählen Sie eine Google Cloud Region für Ihre Umgebung aus

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. Bei diesen Kriterien geht es darum, welcheGoogle Cloud Produkte eine bestimmte Region anbietet und ob eine bestimmte Region Ihrer Latenz und geografischen Nähe zu Nutzern und anderen Umgebungen außerhalb von Google Cloudentspricht. 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 in Zukunft in andere Regionen oder zu einer multiregionalen Umgebung migrieren. Falls Sie eine künftige Migration in andere Regionen in Betracht ziehen, finden Sie weitere Informationen unter Migration zwischen Google Cloud Regionen: 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. Ihrer lokalen Umgebungen. Wenn Sie beispielsweise eine Nutzerbasis ansprechen möchten, die sich in einem bestimmten geografischen Gebiet befindet, sollten Sie eine Google Cloud Region auswählen, die sich in der Nähe dieses geografischen Gebiets befindet. Wenn Sie eine Google Cloud Region auswählen, die Ihren Anforderungen an die geografische Nähe am besten entspricht, können Ihre Umgebungen eine geringere Latenz und kürzere Reaktionszeiten auf Anfragen von Nutzern und von Umgebungen außerhalb von Google Cloudgarantieren. Mit Tools wie dem Google Cloud Latenz-Dashboard und inoffiziellen Tools wie GCPing und der Google Cloud Regionsauswahl können Sie sich einen groben Ü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 zu prüfen, 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 zu ihrem Verfügbarkeitszeitraum 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 Compute Engine bestimmte Maschinentypen in bestimmtenGoogle Cloud Regionen. Weitere Informationen zu den Funktionen der einzelnen Produkte in den einzelnen Regionen finden Sie in der Produktdokumentation.
  • Befinden sich die Ressourcen, die Sie in den einzelnen Google Cloud Regionen benötigen, innerhalb der Kontingentlimits pro Region? Google Cloud Mithilfe von Kontingenten wird der Anteil einer gemeinsam genutzten Google Cloud Ressource beschränkt, der verwendet werden kann. Einige Kontingente sind global und gelten für die Nutzung der Ressource überall inGoogle Cloud, während andere regional oder zonal sind und für die Nutzung der Ressource in einer bestimmten Google Cloud -Region gelten. Beispielsweise sind die meisten Kontingente für die Ressourcennutzung der Compute Engine regional, z. B. die Anzahl der virtuellen Maschinen, die Sie erstellen können. Weitere Informationen zu Kontingenten und deren Erhöhung finden Sie unter Mit Kontingenten arbeiten.

Nicht funktionale Kriterien bewerten

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

  • Mögen Sie eine niedrige CO2-Bilanz? Google Cloudinvestiert kontinuierlich in Nachhaltigkeit und in CO2-freie Energie für Google Cloud Regionen und engagiert sich für CO2-freie Energie in allen Cloud-Regionen. Google Cloud Regionen haben unterschiedliche CO2-Bilanzen. Informationen zur CO2-Bilanz jeder Google Cloud Region und dazu, wie Sie CO2-freie Energie in Ihre Standortstrategie einbeziehen können, 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 zukünftigen gesetzlichen Anforderungen zu prüfen und dieGoogle Cloud -Regionen auszuwählen, die Ihren regulatorischen Anforderungen am besten entsprechen.

Umgebungen mit einer einzigen Region entwerfen und erstellen

So entwerfen Sie eine Umgebung mit einer einzelnen Region:

  1. Bauen Sie Ihr Fundament auf Google Cloud.
  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. Diese Konfiguration würde jedoch nicht vollständig von allen Zuverlässigkeitsfeatures der Google-Infrastruktur profitieren, die den Diensten Google Cloud zugrunde liegt.
  • 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.

Grundlagen schaffen auf Google Cloud

Informationen zum Aufbau einer Grundlage für Umgebungen mit einer einzelnen Region finden Sie unter Migrieren zu Google Cloud: Grundlage planen und erstellen. Die Anleitung in diesem Dokument zielt darauf ab, eine Grundlage für die Migration von Arbeitslasten, Daten und Prozessen zu Google Cloudzu schaffen. Sie gilt aber auch, um die Grundlage für Ihre auf eine Region beschränkte Umgebungen zu schaffen. Lesen Sie dieses Dokument, nachdem Sie das gelesen haben.

Nachdem Sie die Grundlage auf Google Cloudaufgebaut 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 die Computing-ProdukteGoogle Cloud beschrieben, die regionale Bereitstellungen unterstützen.

Compute Engine

Compute Engine ist die IaaS-Lösung (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. 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 Zonenausfall für eine regionale MIG simulieren. Informationen dazu, wie regionale MIGs im Vergleich zu anderen Bereitstellungsoptionen abschneiden, finden Sie unter Compute Engine-Bereitstellungsstrategie für 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 überregionaler Ausfälle zu verringern, empfehlen wir, zonale DNS-Namen zu verwenden, um virtuelle Maschinen, die in Ihren Umgebungen DNS-Namen verwenden, eindeutig zu identifizieren. Google Cloud verwendet standardmäßig zonale DNS-Namen für Compute Engine-VMs. Weitere Informationen zur Funktionsweise des internen Compute Engine-DNS finden Sie unter 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. Compute Engine unterstützt mehrere Speicheroptionen für Ihre virtuellen Maschinen, z. B. Persistent Disk-Volumes und lokale Solid State Drives (SSDs):

    • 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. Google Cloudbietet die Flottenverwaltung, mit der Sie eine Gruppe von GKE-Clustern, deren Infrastruktur und die in diesen Clustern bereitgestellten Arbeitslasten verwalten können, um die Komplexität der Migration zu vereinfachen.

  • 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 zur 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 stellt vollständig verwaltete Dateiserver unter Google Cloud bereit, 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 Auswahl der Enterprise-Stufe, da diese Hochverfügbarkeit und Datenredundanz über mehrere Zonen in einer Region hinweg unterstützt. Instanzen auf 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 mobile, Web- und Serverentwicklung von 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. Es unterstützt Daten-Back-Ends 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 Hochverfü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 zur Verfügbarkeit und Zuverlässigkeit aus. Memorystore for Valkey unterstützt mehrere Konfigurationen, z. B. zonale und multizonale 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 Datenanalyseprodukte 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 gehören zu den Kernprinzipien von SRE. Google Cloud bietet die Tools und die professionellen Dienste zur Implementierung von SRE, um die Ausfallsicherheit 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.
  • Wiederherstellung nach Ausfällen der Cloud-Infrastruktur berücksichtigen. Google Cloud Verfügbarkeitsgarantien sind in den Google Cloud Service Level Agreements definiert. Für den unwahrscheinlichen Fall, dass ein zonaler oder regionaler Ausfall auftritt, empfehlen wir, Ihre Arbeitslasten so zu gestalten, dass sie zonalen und regionalen Ausfällen standhalten.
  • 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: