Über Google Cloud-Regionen migrieren: Stabile Umgebungen mit einer Region in Google Cloud entwerfen

Last reviewed 2023-12-08 UTC

In diesem Dokument erfahren Sie, wie Sie robuste Umgebungen mit einer einzigen Region in Google Cloud entwerfen. Dieses Dokument bietet nützliche Informationen, wenn Sie eine Umgebung mit einer einzigen Region migrieren möchten oder wenn Sie die Möglichkeit möchten, dies in Zukunft zu tun und sich einen Überblick über den Aufbau dieser Umgebung zu verschaffen.

Dieses Dokument ist Teil der folgenden Reihe:

Dieses Dokument enthält eine Anleitung zum Entwerfen robuster Umgebungen mit einer einzigen Region in Google Cloud. Es konzentriert sich auf die folgenden Architekturkomponenten:

In der Anleitung in diesem Dokument wird davon ausgegangen, dass Sie Umgebungen mit einer einzigen Region entwerfen und implementieren. Wenn Sie jetzt eine Umgebung mit einer einzelnen Region verwenden, können Sie in Zukunft zu einer Umgebung mit mehreren Regionen migrieren. Wenn Sie eine zukünftige Migration und Weiterentwicklung Ihrer zonalen und einzelnen Regionsumgebungen in multiregionale Umgebungen planen, finden Sie weitere Informationen unter Migration zwischen Google Cloud-Regionen: Erste Schritte.

Attribute verschiedener Deployment-Archetypen

Google Cloud stellt Dienste aus verschiedenen Regionen der Welt bereit. Jede Region ist ein physisch unabhängiger geografischer Bereich, der aus Bereitstellungsbereichen besteht, die als Zonen bezeichnet werden. Weitere Informationen zu Google Cloud-Regionen und -Zonen finden Sie unter Geografie und Standorte.

Beim Entwerfen Ihrer Google Cloud-Umgebung können Sie zwischen den folgenden Deployment-Archetypen wählen, die in der Reihenfolge der Zuverlässigkeit und des operativen Aufwands dargestellt werden:

  • Zonaler Archetyp: Sie stellen Google Cloud-Ressourcen in einer einzelnen Zone innerhalb einer Region und zonalen Diensten bereit, in denen sie verfügbar sind. Wenn keine zonalen Dienste verfügbar sind, verwenden Sie regionale Dienste.
  • Archetyp für einzelne Region: Sie stellen Google Cloud-Ressourcen in mehreren Zonen innerhalb einer Region bereit und verwenden nach Möglichkeit regionale Dienste.
  • Archetyp für mehrere Regionen: Sie stellen Google Cloud-Ressourcen in mehreren Zonen in verschiedenen Regionen bereit. Zonale Ressourcen werden in einer oder mehreren Zonen der jeweiligen Region bereitgestellt.

Die vorherigen Deployment-Archetypen haben unterschiedliche Zuverlässigkeitsattribute. Sie können sie verwenden, um die für Ihre Umgebung erforderlichen Zuverlässigkeitsgarantien bereitzustellen. Eine Umgebung mit mehreren Regionen hat beispielsweise eine höhere Wahrscheinlichkeit, einen regionalen Ausfall zu überstehen im Vergleich zu einer Einzelregion oder zonalen Umgebung. Weitere Informationen zu den Zuverlässigkeitsattributen der einzelnen Architekturarchetypen finden Sie unter Wie Sie Zonen und Regionen nutzen, um Zuverlässigkeit zu erreichen und im Leitfaden zur Zuverlässigkeit der Cloud-Infrastruktur.

Das Entwerfen, Implementieren und Ausführen einer Umgebung anhand dieser Deployment-Archetypen erfordert aufgrund der Kosten- und Komplexitätsattribute der einzelnen Archetypen unterschiedlichen Aufwand. Eine zonale Umgebung kann beispielsweise im Vergleich zu einer regionalen oder einer multiregionalen Umgebung kostengünstiger und einfacher zu entwerfen, zu implementieren und zu betreiben sein. Der potenziell niedrigere Aufwand und die Kosten der zonalen Umgebung sind auf den zusätzlichen Overhead zurückzuführen, den Sie zum Koordinieren von Arbeitslasten, Daten und Prozessen in verschiedenen Regionen benötigen.

In der folgenden Tabelle sind die Ressourcenverteilung, die Zuverlässigkeitsattribute und die Komplexität der einzelnen Architekturarchetypen zusammengefasst. Außerdem wird beschrieben, wie viel Aufwand für das Entwerfen und Implementieren einer solchen Umgebung erforderlich ist.

Architekturname für Architektur Ressourcenverteilung Hilft gegen Widerstandsfähigkeit Komplexität entwerfen
Zonale Umgebung In einer einzelnen Zone Ressourcenfehler Erfordert eine Koordination innerhalb einer einzelnen Zone
Umgebung für eine einzelne Region Mehrere Zonen in einer Region Ressourcenausfälle, zonale Ausfälle Erfordert Koordination über mehrere Zonen in einer einzelnen Region
Multiregionale Umgebung Über mehrere Zonen in mehreren Regionen Ressourcenausfälle, zonale Ausfälle, regionale Ausfälle, multiregionale Ausfälle Erfordert Koordination über mehrere Zonen in mehreren Regionen

Deployment-Archetypen für Ihre Umgebungen auswählen

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

  1. Definieren Sie die Fehlermodelle, vor denen Sie sich schützen möchten.
  2. Prüfen Sie die Archetypen der Bereitstellung, um festzustellen, welche Ihren Anforderungen am besten entsprechen.

Fehlermodelle definieren

Definieren Sie bei der Definition von Fehlermodellen die folgenden Fragen:

  • Welche Komponenten Ihrer Umgebung benötigen Fehlermodelle? Fehlermodelle können auf alles angewendet werden, das Sie in Google Cloud bereitstellen oder bereitstellen. Ein Fehlermodell kann auf eine einzelne Person oder ein Fehlermodell auf alle Ressourcen in einer ganzen Zone oder Region angewendet werden. Wir empfehlen Ihnen, ein Fehlermodell auf alle Elemente anzuwenden, die Ihnen einen Mehrwert bieten, z. B. Arbeitslasten, Daten, Prozesse und jede Google Cloud-Ressource.
  • Wie hoch sind Ihre Hochverfügbarkeits-, Geschäftskontinuitäts- und Notfallwiederherstellungsanforderungen 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, sowie eigene Notfallwiederherstellungsanforderungen. eine Das Compute Engine SLA gibt beispielsweise an, dass Sie, wenn Sie mehr als 99,5% der monatlichen Betriebszeit erreichen müssen, Instanzen in mehreren Zonen in einer einzelnen Region bereitstellen müssen. eine 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 die gleichen Zuverlässigkeitsgarantien bieten. Wenn Sie Garantien für eine höhere Verfügbarkeit und Ausfallsicherheit bieten, müssen Sie in der Regel mehr Aufwand und Ressourcen investieren. Wenn Sie Ihre Fehlermodelle definieren, empfehlen wir einen Ansatz, bei dem Sie mehrere Fehlermodelle für jede Komponente und nicht nur eines für alle Komponenten definieren. Beispielsweise müssen geschäftskritische Arbeitslasten in der Regel eine höhere Zuverlässigkeit bieten, obwohl es akzeptabel ist, weniger zuverlässige Zuverlässigkeitsgarantien für andere, weniger kritische Arbeitslasten zu bieten.
  • Wie viele Ressourcen benötigen die Fehlermodelle, um sie vor Ausfällen zu schützen? Damit Sie die von Ihnen definierten Fehlermodelle nicht schützen, müssen Sie Ressourcen wie Zeit und Kosten für die Entwicklung, Bereitstellung und Konfiguration von Schutzmechanismen und automatisierten Prozessen einsetzen. Wir empfehlen Ihnen, zu beurteilen, wie viele Ressourcen Sie vor jedem von Ihnen definierten Fehlermodell schützen müssen.
  • Wie erkennen Sie, dass ein Fehler auftritt? Es ist wichtig, zu erkennen, dass ein Fehler vorliegt oder bald auftreten wird, damit Sie die Prozesse zur Schadensminderung, Wiederherstellung und zum Abgleich starten 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? Bei der Definition von Fehlermodellen empfehlen wir, wie Sie jedes Modell kontinuierlich testen, um sicherzustellen, dass es effektiv vor den Fehlern schützt, auf die die Modelle abzielen. Sie können beispielsweise Fehler in Ihre Umgebungen einfügen oder die Fähigkeit Ihrer Umgebungen bewerten, Fehler zu tolerieren, indem Sie Chaos Engineering verwenden.
  • Welche Auswirkungen haben Sie, wenn ein bestimmtes Fehlermodell auftritt? Um die Auswirkungen eines Fehlers auf Ihr Unternehmen zu verstehen, empfehlen wir für jedes Fehlermodell, die Auswirkungen jedes Fehlers zu schätzen, auf dem das Modell basiert. Dieses Verständnis ist hilfreich, um Prioritäten und Wiederherstellungsreihenfolgen festzulegen, damit Sie und Ihre Prozesse zuerst die wichtigsten Komponenten handhaben.
  • Wie lange dauern die Fehler in den von Ihnen definierten Fehlermodellen? Die Dauer eines Fehlers kann sich erheblich auf die Risikominderung und Wiederherstellungspläne auswirken. Wenn Sie Fehlermodelle definieren, sollten Sie daher berücksichtigen, wie lange ein Fehler dauern kann. Wenn Sie berücksichtigen, wie lange ein Fehler dauern kann, berücksichtigen Sie auch, wie lange es dauert, einen Fehler zu identifizieren, den Fehler abzugleichen und die fehlgeschlagenen Ressourcen wiederherzustellen.

Weitere Überlegungen zu Fehlermodellen und zum Entwerfen eines zuverlässigen Notfallwiederherstellungsplans finden Sie unter Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur.

Deployment-Archetypen bewerten

Nachdem Sie die Fehlermodelle definiert haben, vor denen Sie sich schützen können, bewerten Sie die Deployment-Archetypen, um festzustellen, was am besten Ihren Anforderungen entspricht. Denken Sie über die folgenden Fragen nach, wenn Sie die Archetypen der Bereitstellung bewerten:

  • Wie viele Deployment-Archetypen benötigen Sie? Sie müssen nicht nur einen Architekturarchetyp für alle Umgebungen auswählen. Stattdessen können Sie einen hybriden Ansatz implementieren, bei dem Sie mehrere Deployment-Archetypen gemäß den Zuverlässigkeitsgarantien auswählen, die Sie benötigen, um vor den von Ihnen definierten Fehlermodellen zu schützen. Wenn Sie beispielsweise zwei Fehlermodelle definiert haben – eines mit einer zonalen Umgebung und eines mit einer regionalen Umgebung –, sollten Sie separate Deployment-Archetypen zum Schutz vor jedem Fehlermodell auswählen. Wenn Sie mehrere Deployment-Archetypen auswählen, empfehlen wir, die potenziell zunehmende Komplexität des Entwerfens, Implementierens und Betreibens mehrerer Umgebungen zu bewerten.
  • Wie viele Ressourcen müssen Sie anhand der Deployment-Archetypen entwerfen und implementieren? Das Entwerfen und Implementieren jeder Art von Umgebung erfordert Ressourcen und Aufwand. Wir empfehlen Ihnen, auf der Grundlage des ausgewählten Archetyps zu beurteilen, wie viele Ressourcen Sie benötigen, um jede Umgebung 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 Architekturarchetypen und den Kosten und der Komplexität des Designs, der Implementierung und der Betriebsumgebungen basierend auf diesen Archetypen finden.
  • Erwarten Sie, dass Sie eine Umgebung basierend auf einem Architekturarchetyp auf eine Umgebung basierend auf einem anderen Archetyp migrieren? In Zukunft können Arbeitslasten, Daten und Prozesse von einer Google Cloud-Umgebung in eine andere Google Cloud-Umgebung migriert werden. Sie können beispielsweise von einer zonalen Umgebung zu einer regionalen Umgebung migrieren.
  • Wie geschäftskritisch sind die Umgebungen, die Sie entwerfen und implementieren? Geschäftskritische Umgebungen erfordern wahrscheinlich mehr Zuverlässigkeitsgarantien. Sie können beispielsweise eine multiregionale Umgebung für geschäftskritische Arbeitslasten, Daten und Prozesse entwerfen und implementieren und eine zonale oder regionale Umgebung für weniger kritische Arbeitslasten, Daten und Prozesse.
  • Benötigen Sie die Features, die von bestimmten Architekturarchetypen für bestimmte Umgebungen angeboten werden? Abgesehen von den Zuverlässigkeitsgarantien der einzelnen Architekturarchetypen bieten die Archetypen auch unterschiedliche Skalierbarkeit, geografische Nähe, Latenz und Datenlokalisierungsgarantien. Wir empfehlen, diese Garantien zu berücksichtigen, wenn Sie die Deployment-Archetypen für Ihre Umgebungen auswählen.

Zusätzlich zu den technischen Aspekten der Fehlermodi, die Sie nach der vorherigen Anleitung definiert haben, empfehlen wir Ihnen, alle nicht funktionalen Anforderungen wie Vorschriften, Lokalität und Souveränität zu berücksichtigen. Diese Optionen können die verfügbaren Optionen einschränken. Wenn Sie beispielsweise regulatorische Anforderungen erfüllen müssen, die die Nutzung einer bestimmten Region erfordern, müssen Sie entweder eine Umgebung mit einer einzigen Region oder eine zonale Umgebung in dieser Region entwerfen und implementieren.

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

Wenn Sie Ihre Umgebung für eine einzelne Region entwerfen, müssen Sie die Region ermitteln, die den Anforderungen jeder Umgebung am besten entspricht. In den folgenden Abschnitten werden diese beiden Kategorien von Auswahlkriterien beschrieben:

  • Funktionskriterien. Diese Kriterien bestimmen, welche Google Cloud-Produkte eine bestimmte Region bietet und ob eine bestimmte Region Ihre Latenz und die geografische Nähe zu Nutzern und anderen Umgebungen außerhalb von Google Cloud erfüllt. Wenn Ihre Arbeitslasten und Daten beispielsweise Latenzanforderungen für Ihre Nutzer oder andere Umgebungen außerhalb von Google Cloud haben, müssen Sie möglicherweise die Region auswählen, die Ihren Nutzern oder anderen Umgebungen am nächsten ist, um diese Latenz zu minimieren.
  • Nicht funktionale Kriterien: Diese Kriterien beziehen sich auf die Produktpreise, die mit bestimmten Regionen verbunden sind, sowie mit den Anforderungen an die CO2-Bilanz und den erforderlichen Anforderungen und Vorschriften, die für Ihr Unternehmen gelten. Stark regulierte Märkte wie Banken und der öffentliche Sektor haben beispielsweise sehr strenge und spezifische Anforderungen in Bezug auf Daten- und Arbeitslastlokalität und die gemeinsame Nutzung der Cloud-Anbieter-Infrastruktur mit anderen Kunden.

Wenn Sie jetzt eine bestimmte Google Cloud-Region auswählen, können Sie in Zukunft zu verschiedenen Regionen oder zu einer Umgebung mit mehreren Regionen migrieren. Wenn Sie eine zukünftige Migration in andere Regionen in Betracht ziehen möchten, finden Sie weitere Informationen unter Migration zwischen Google Cloud-Regionen: Erste Schritte.

Funktionskriterien bewerten

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

  • Welche Anforderungen gelten für die geografische Nähe? Wenn Sie eine Google Cloud-Region auswählen, müssen Sie möglicherweise Ihre Arbeitslasten, Daten und Prozesse in der Nähe Ihrer Nutzer oder Ihrer Umgebungen außerhalb von Google Cloud platzieren, z. B. in Ihren lokalen Umgebungen. Wenn Sie beispielsweise auf eine Nutzerbasis abzielen, die sich in einem bestimmten geografischen Gebiet befindet, empfehlen wir, 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 Ihre Umgebungen eine geringere Latenz und niedrigere Reaktionszeiten für Anfragen Ihrer Nutzer und Ihrer Umgebungen außerhalb von Google Cloud garantieren. Tools wieGoogle Cloud-Latenz-Dashboard und inoffizielle Tools wieGCP undGoogle Cloud-Regionsauswahl bietet eine allgemeine Übersicht über die Latenzmerkmale von Google Cloud-Regionen. Wir empfehlen Ihnen jedoch, eine umfassende Bewertung durchzuführen, um zu beurteilen, ob die Latenzattribute Ihren Anforderungen, Arbeitslasten, Daten und Prozessen entsprechen.
  • In welchen Regionen möchten Sie die benötigten Produkte anbieten? Wir empfehlen Ihnen, die in den einzelnen Google Cloud-Regionen verfügbaren Produkte und die Regionen zu bewerten, in denen die Dienste bereitgestellt werden, die Sie zum Entwerfen und Implementieren Ihrer Umgebungen benötigen. Weitere Informationen dazu, welche Produkte in den einzelnen Regionen verfügbar sind, und zu deren Verfügbarkeitszeiträumen finden Sie unter Cloudstandorte. Außerdem bieten einige Produkte möglicherweise nicht alle Features in jeder Region, in der sie verfügbar sind. Die verfügbaren Regionen und Zonen für Compute Engine bieten beispielsweise bestimmte Maschinentypen in bestimmten Google Cloud-Regionen. Weitere Informationen zu den Features der einzelnen Produkte in den einzelnen Regionen finden Sie in der Produktdokumentation.
  • Sind die Ressourcen, die Sie in den einzelnen Google Cloud-Regionen benötigen, innerhalb der Kontingentlimits pro Region? Google Cloud legt mithilfe von Kontingenten fest, welchen Anteil einer freigegebenen Google Cloud-Ressource Sie nutzen können. Einige Kontingente sind global und gelten für Ihre Nutzung der Ressource überall in Google Cloud, während andere regional oder zonal sind und für Ihre Nutzung der Ressource in einer bestimmten Google Cloud-Region gelten. Die meisten Kontingente für die Nutzung von Compute Engine-Ressourcen, z. B. die Anzahl der virtuellen Maschinen, die Sie erstellen können, sind beispielsweise regional. Weitere Informationen zu Kontingenten und deren Erhöhung finden Sie unter Mit Kontingenten arbeiten.

Nicht funktionale Kriterien bewerten

Berücksichtigen Sie die folgenden Fragen, um nicht funktionale Kriterien zu bewerten:

  • Möchten Sie eine geringe CO2-Bilanz? Google Cloud investiert kontinuierlich in Nachhaltigkeit und in kohlenstofffreie Energie für Google Cloud-Regionen und verpflichtet sich zu CO2-freier Energie für alle Cloud-Regionen Google Cloud-Regionen haben unterschiedliche CO2-Bilanzen. Informationen zur CO2-Bilanz jeder Google Cloud-Region und zur Einbindung von CO2-freier Energie in Ihre Standortstrategie finden Sie unter CO2-freie Energie für Google Cloud-Regionen.
  • Müssen Ihre Umgebungen bestimmten Vorschriften entsprechen? Behörden und nationale und supranationale Einrichtungen regeln häufig bestimmte Märkte und Geschäftsbereiche, z. B. Banken und öffentliche Sektoren. Diese Vorschriften können vorschreiben, dass sich Arbeitslasten, Daten und Prozesse nur in bestimmten geografischen Regionen befinden. 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, Ihre aktuellen und zukünftigen regulatorischen Anforderungen zu bewerten, wenn Sie die Google Cloud-Regionen für Ihre Umgebungen auswählen und die Google Cloud-Regionen auswählen, die Ihren regulatorischen Anforderungen am besten entsprechen.

Umgebungen mit einer einzigen Region entwerfen und erstellen

So entwerfen Sie eine Umgebung für eine einzelne Region:

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

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

  • Regionale Ressourcen bereitstellen. Viele Google Cloud-Produkte unterstützen die Bereitstellung von Ressourcen in mehreren Zonen in einer Region. Wir empfehlen, wenn möglich regionale Ressourcen anstelle von zonalen Ressourcen bereitzustellen. Theoretisch können Sie zonale Ressourcen in mehreren Zonen einer Region bereitstellen und selbst verwalten, um eine höhere Zuverlässigkeit zu erreichen. Diese Konfiguration würde jedoch nicht vollständig von den Zuverlässigkeitsfunktionen der Google-Infrastruktur profitieren, die den Google Cloud-Diensten zugrunde liegt.
  • Prüfen Sie, ob die Umgebungen erwartungsgemäß mit den Annahmen des Fehlermodells 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 einzigen Region mit minimalen Störungen überstehen können.

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

Grundlage in Google Cloud erstellen

Informationen zum Aufbau der Grundlage für Ihre Umgebungen mit einer einzelnen Region finden Sie unter Migration zu Google Cloud: Grundlage aufbauen. Die Anleitung in diesem Dokument zielt darauf ab, eine Grundlage für die Migration von Arbeitslasten, Daten und Prozessen zu Google Cloud zu schaffen. Sie soll aber auch als Grundlage für Ihre Umgebungen mit einer einzigen Region dienen. Lesen Sie dieses Dokument, nachdem Sie das gelesen haben.

Nachdem Sie Ihre Grundlage in Google Cloud aufgebaut haben, entwerfen und implementieren Sie Sicherheitskontrollen und -grenzen. Diese Sicherheitsmaßnahmen tragen dazu bei, dass Ihre Arbeitslasten, Daten und Prozesse in der jeweiligen Region bleiben. Durch die Sicherheitsmaßnahmen wird außerdem sichergestellt, dass Ihre Ressourcen aufgrund von Programmfehlern, Fehlkonfigurationen oder böswilligen Angriffen nicht in andere Regionen gelangen.

Rechenressourcen bereitstellen und konfigurieren

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

Compute Engine

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

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

Für eine bessere Flexibilität und Ressourcenverwaltung von physischen Ressourcen entkoppelt Compute Engine Zonen von ihren physischen Ressourcen. Weitere Informationen zu dieser Abstraktion und den möglichen Auswirkungen finden Sie unter Zonen und Cluster.

Beachten Sie Folgendes, um die Zuverlässigkeit Ihrer Umgebungen zu erhöhen, die Compute Engine verwenden:

  • Regional verwaltete Instanzgruppen (MIGs) Virtuelle Compute Engine-Maschinen sind zonale Ressourcen, also sind sie bei einem zonalen Ausfall nicht verfügbar. Zur Behebung dieses Problems können Sie in Compute Engine regionale MIGs erstellen, die virtuelle Maschinen in mehreren Zonen automatisch entsprechend der Nachfrage und der regionalen Verfügbarkeit bereitstellen. Wenn Ihre Arbeitslasten zustandsorientiert sind, können Sie auch regionale zustandsorientierte MIGs erstellen, um zustandsorientierte Daten und Konfigurationen beizubehalten. Regionale MIGs unterstützen die Simulation von Zonenausfällen. Informationen zum Simulieren eines Zonenausfalls bei einer regionalen MIG finden Sie unter Zonenausfall 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. Regionale MIGs verteilen virtuelle Maschinen gemäß der Zielverteilungsform. Damit die Verteilung der virtuellen Maschinen nicht um mehr als eine Einheit zwischen zwei Zonen in einer Region unterscheidet, empfehlen wir Ihnen, beim Erstellen regionaler MIGs die Verteilungsform EVEN auszuwählen. Informationen zu den Unterschieden zwischen den Zielverteilungsformen finden Sie unter Vergleich der Formen.
  • Instanzvorlagen. Zum Definieren der bereitzustellenden virtuellen Maschinen verwenden MIGs einen globalen Ressourcentyp namens Instanzvorlagen. Obwohl Instanzvorlagen globale Ressourcen sind, können sie auf zonale oder regionale Ressourcen verweisen. Beim Erstellen von Instanzvorlagen empfehlen wir, wenn möglich auf regionale Ressourcen zu verweisen. Wenn Sie zonale Ressourcen verwenden, empfehlen wir, die Auswirkungen ihrer Verwendung zu bewerten. Wenn Sie beispielsweise eine Instanzvorlage erstellen, die auf ein nichtflüchtiges Speicher-Volume verweist, das nur in einer bestimmten Zone verfügbar ist, können Sie diese Vorlage in keiner anderen Zone verwenden, da das nichtflüchtige Speicher-Volume nicht in diesen anderen Zonen verfügbar ist.
  • Load-Balancing und Skalierung konfigurieren. Compute Engine unterstützt Load-Balancing-Traffic zwischen Compute Engine-Instanzen und Autoscaling, um virtuelle Maschinen nach Bedarf automatisch in MIGs hinzuzufügen oder zu entfernen. Zur Erhöhung der Zuverlässigkeit und Flexibilität Ihrer Umgebungen und zur Vermeidung des Verwaltungsaufwands für selbstverwaltete Lösungen empfehlen wir die Konfiguration von Load-Balancing und Autoscaling. 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 bei Bedarf die erforderlichen Ressourcen haben, empfehlen wir, Ressourcenreservierungen zu konfigurieren, um Kapazität für zonale Compute Engine zu gewährleisten. Ressourcen finden. Bei einem zonalen Ausfall müssen Sie beispielsweise virtuelle Maschinen in einer anderen Zone bereitstellen, um die erforderliche Kapazität für diejenigen bereitzustellen, die aufgrund des Ausfalls nicht verfügbar sind. Durch Ressourcenreservierungen stellen Sie sicher, dass die Ressourcen verfügbar sind, um die zusätzlichen virtuellen Maschinen bereitzustellen.
  • Zonale DNS-Namen verwenden Um das Risiko regionsübergreifender Ausfälle zu minimieren, empfehlen wir die Verwendung von zonalen DNS-Namen, um virtuelle Maschinen, die DNS-Namen in Ihren Umgebungen verwenden, eindeutig zu identifizieren. Google Cloud verwendet standardmäßig zonale DNS-Namen für virtuelle Compute Engine-Maschinen. Weitere Informationen zur Funktionsweise des internen DNS von Compute Engine finden Sie unter Internes DNS. Wir empfehlen Ihnen, zonale DNS-Namen als Konfigurationsparameter zu verwenden, die Sie in Zukunft ändern können, um eine zukünftige Migration zwischen Regionen zu erleichtern und Ihre Konfiguration besser zu pflegen.
  • Geeignete Speicheroptionen auswählen Compute Engine unterstützt mehrere Speicheroptionen für Ihre virtuellen Maschinen, z. B. nichtflüchtige Speicher-Volumes und lokale Solid-State-Laufwerke (SSDs):
    • Nichtflüchtige Speicher-Volumes sind auf mehrere physische Laufwerke verteilt und befinden sich unabhängig von Ihren virtuellen Maschinen. Nichtflüchtige Speicher können zonal oder regional sein. Zonale nichtflüchtige Speicher speichern Daten in einer einzelnen Zone, während regionale nichtflüchtige Speicher Daten in zwei verschiedenen Zonen replizieren. Bei der Auswahl von Speicheroptionen für Ihre Umgebungen mit einer einzelnen Region empfehlen wir die Verwendung von regionalen nichtflüchtigen Speichern, da diese Ihnen Failover-Optionen bieten, wenn zonale Fehler auftreten. 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 jedoch nur Daten, bis eine Instanz angehalten oder gelöscht wird. Daher eignen sich lokale SSds ideal, um temporäre Daten, Caches und Daten zu speichern, die von anderen Mitteln rekonstruiert werden können. Nichtflüchtige Speicher sind robuste Speichergeräte, auf die virtuelle Maschinen wie physische Laufwerke zugreifen können.
  • Mechanismen zum Datenschutz entwickeln und implementieren. Beim Entwerfen Ihrer Umgebungen mit einer einzelnen Region empfehlen wir die Implementierung automatisierter Mechanismen, um Ihre Daten zu schützen, wenn es negative Ereignisse gibt, z. B. zonale, regionale oder multiregionale Ausfälle oder böswillige Angriffe von böswilligen Dritten. Compute Engine bietet mehrere Optionen zum Schutz Ihrer Daten. Sie können diese Datenoptionsfunktionen als Bausteine zum Entwerfen und Implementieren Ihrer Datenschutzprozesse verwenden.

GKE

GKE unterstützt Sie beim Bereitstellen, Verwalten und Skalieren von Containerarbeitslasten auf Kubernetes. GKE baut auf Compute Engine auf, sodass die Empfehlungen im vorherigen Abschnitt zu Compute Engine teilweise für GKE gelten.

Beachten Sie die folgenden Designpunkte und GKE-Features, um die Zuverlässigkeit Ihrer Umgebungen zu erhöhen, die GKE verwenden:

  • Verwenden Sie regionale GKE-Cluster, um die Verfügbarkeit zu erhöhen. GKE unterstützt verschiedene Verfügbarkeitstypen für Ihre Cluster, je nach erforderlichem Clustertyp. GKE-Cluster können eine zonale oder regionale Steuerungsebene haben und Knoten haben, die in einer einzelnen Zone oder in mehreren Zonen innerhalb einer Region ausgeführt werden. Verschiedene Clustertypen bieten auch unterschiedliche Service Level Agreements (SLAs). Zur Erhöhung der Zuverlässigkeit Ihrer Umgebungen empfehlen wir die Auswahl regionaler Cluster. Wenn Sie das GKE Autopilot-Feature verwenden, können Sie nur regionale Cluster bereitstellen.
  • Multi-Cluster-Umgebung in Betracht ziehen. Durch das Deployment mehrerer GKE-Cluster können Sie die Flexibilität und die Verfügbarkeitsattribute Ihrer Umgebung erhöhen, allerdings mit zunehmender Komplexität. 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 Container zu Google Cloud migrieren: Zu einer Multi-Cluster-GKE-Umgebung migrieren. Zur leichteren Verwaltung der Migration bietet Google Cloud die Flottenverwaltung, eine Reihe von Funktionen zum Verwalten einer Gruppe von GKE-Clustern, deren Infrastruktur. und die Arbeitslasten, die in diesen Clustern bereitgestellt werden.
  • Backup for GKE einrichten Backup for GKE ist ein regionaler Dienst, um Arbeitslasten und Volumes in einem GKE-Quellcluster zu sichern und in einem GKE-Zielcluster wiederherzustellen. Um die Arbeitslastkonfiguration und die Daten vor möglichen Verlusten zu schützen, empfehlen wir Ihnen, 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 von containerisierten Arbeitslasten. Cloud Run verwendet Dienste, um Ihnen die Infrastruktur zum Ausführen Ihrer Arbeitslasten bereitzustellen. Cloud Run-Dienste sind regionale Ressourcen und die Dienste werden über mehrere Zonen in der Region repliziert, in der sie sich befinden. Beim Bereitstellen eines Cloud Run-Dienstes können Sie eine Region auswählen. Anschließend wählt Cloud Run automatisch die Zonen innerhalb dieser Region aus, in denen Instanzen des Dienstes bereitgestellt werden. Cloud Run verteilt den Traffic automatisch auf Dienstinstanzen und verringert die Auswirkungen eines Zonenausfalls erheblich.

VMware Engine

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

  • VMware Engine Private Clouds mit mehreren Knoten bereitstellen VMware Engine unterstützt die Bereitstellung isolierter VMware-Stacks namens private Clouds. 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 sind so konfiguriert, dass Single Points of Failure beseitigt werden. VMware Engine unterstützt private Clouds mit einem einzelnen Knoten. Wir empfehlen jedoch, für private Proofs of Concept und Tests nur private Clouds mit einem einzelnen Knoten zu verwenden. Für Produktionsumgebungen empfehlen wir die Verwendung der Standard-Clouds mit mehreren Knoten.
  • Erweiterte 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 gestreckte 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 in einer einzelnen Region bereitgestellt und konfiguriert haben, stellen Sie Ressourcen zum Speichern und Verwalten von Daten bereit. In den folgenden Abschnitten werden die Datenspeicher- und Verwaltungsprodukte von Google Cloud 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ügbarkeitsanforderungen, behördlichen und anderen Anforderungen am besten entspricht. Für 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üssen, wenn Zonenausfälle auftreten, können Sie ihn mit einem Standorttyp in der Region bereitstellen.

Weitere Informationen zum Entwerfen von Notfallwiederherstellungsmechanismen für in Cloud Storage gespeicherte Daten und dazu, wie Cloud Storage auf zonale und regionale Ausfälle reagiert, finden Sie unter:Architektur der Notfallwiederherstellung für Ausfälle der Cloud-Infrastruktur entwickeln: Cloud Storage eine

Filestore

Filestore bietet vollständig verwaltete Dateiserver in Google Cloud, die mit Compute Engine-Instanzen, GKE-Clustern und Ihren lokalen Computern verbunden werden können. Filestore bietet mehrere Dienststufen. Jede Stufe bietet einzigartige Funktionen, Skalierbarkeit, Leistung, Kapazität und Datenwiederherstellung. Beim Bereitstellen von Filestore-Instanzen empfehlen wir die Auswahl der Unternehmensstufe, da diese eine hohe Verfügbarkeit und Datenredundanz über mehrere Zonen in einer Region unterstützt. }. Instanzen, die sich in anderen Stufen befinden, 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. Zur Erhöhung der Zuverlässigkeit Ihrer Instanzen können Sie Bigtable so konfigurieren, dass Daten über mehrere Zonen in derselben Region oder in mehreren Regionen repliziert werden. Wenn die Replikation aktiviert ist und ein Ausfall auftritt, führt Bigtable automatisch Anfragen an andere verfügbare Instanzen aus, auf 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 ihren Standort aus. Standorte können entweder multiregional oder regional sein und unterschiedliche Zuverlässigkeitsgarantien bieten. Wenn eine Datenbank einen regionalen Standort hat, repliziert sie Daten in verschiedenen Zonen innerhalb einer Region. Eine multiregionale Datenbank repliziert Daten in mehr als einer Region.

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 und Memcached.

Wenn Sie Memorystore for Redis-Instanzen bereitstellen, wählen Sie eine Dienststufe für diese Instanz aus. Memorystore for Redis unterstützt mehrere Instanzdienststufen. Jede Stufe bietet besondere Funktionen in Bezug auf Verfügbarkeit, Knotengröße und Bandbreite. Wenn Sie eine Memorystore for Redis-Instanz bereitstellen, empfehlen wir Ihnen, eine Standardstufe oder eine Standardstufe mit Lesereplikaten auszuwählen. Memorystore-Instanzen in diesen beiden Stufen replizieren Daten automatisch in mehreren 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 in der Region auswählen, in der Sie die Knoten dieser Instanz bereitstellen möchten, oder Memorystore for Memcached verteilt die Knoten automatisch auf die Zonen. Um Instanzen optimal zu platzieren und Bereitstellungsprobleme wie das Platzieren aller Knoten in derselben Zone zu vermeiden, empfehlen wir, dass Memorystore for Memcached Knoten automatisch auf Zonen innerhalb einer Region verteilt.
  • Datenreplikation über Zonen: Memorystore for Memcached-Instanzen replizieren keine Daten über Zonen oder Regionen hinweg. 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.

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 einzigen Region bereitgestellt und konfiguriert haben, stellen Sie Datenanalyseressourcen bereit und konfigurieren sie. In den folgenden Abschnitten werden die Datenanalyseprodukte von Google Cloud 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.

Zum Organisieren und Steuern des Zugriffs auf Daten in BigQuery stellen Sie Container auf oberster Ebene bereit, die als Datasets bezeichnet werden. Beachten Sie beim Bereitstellen von BigQuery-Datasets Folgendes:

  • Dataset-Standort Zum Auswählen des BigQuery-Speicherorts, an dem Sie Ihre Daten speichern möchten, konfigurieren Sie den Dataset-Speicherort. Ein Standort kann entweder regional oder multiregional sein. Bei beiden Standorttypen speichert BigQuery Kopien Ihrer Daten in zwei verschiedenen Zonen innerhalb des ausgewählten Standorts. Sie können den Dataset-Speicherort nach dem Erstellen eines Datasets nicht mehr ändern.
  • Katastrophenplanung BigQuery ist ein regionaler Dienst und verarbeitet zonale Fehler automatisch, für Computing und für Daten. Es gibt jedoch bestimmte Szenarien, die Sie selbst planen müssen, z. B. regionale Ausfälle. Wir empfehlen, diese Szenarien beim Entwerfen Ihrer Umgebungen zu berücksichtigen.

Weitere Informationen zur Planung und 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 Compute Engine, sodass die Empfehlungen im vorherigen Abschnitt zu Compute Engine auch für Dataproc gelten.

Zur Verwendung von Dataproc erstellen Sie Dataproc-Cluster. 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 dieAutomatische Zonenplatzierung in Dataproc die Zone automatisch auswählen lassen. Wir empfehlen die Verwendung der automatischen 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 nach dem Erstellen eines Clusters nicht mehr aktivieren. Es wird empfohlen, den Hochverfügbarkeitsmodus zu aktivieren, wenn der Cluster gegen den Ausfall eines einzelnen Koordinatorknotens stabil sein muss oder teilweise zonale Ausfälle auftreten müssen. 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 berücksichtigen:

  • Regionale Endpunkte Wenn Sie einen Job erstellen, müssen Sie in Dataflow einen regionalen Endpunkt konfigurieren. Durch das Konfigurieren eines regionalen Endpunkts für Ihren Job beschränken Sie die Platzierung von Computing- und Datenressourcen auf eine bestimmte Region.
  • Zonale Platzierung. Dataflow verteilt Worker-Knoten automatisch je nach Jobtyp entweder 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. Dazu platzieren Sie alle Worker-Knoten in derselben Zone innerhalb einer Region. Um die durch zonale Ausfälle verursachten Probleme zu minimieren, empfehlen wir Ihnen, Dataflow die beste Zonenplatzierung automatisch 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: 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 in der Architekturübersicht über Pub/Sub.

Beachten 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, die diese Nachricht verarbeiten soll. Wenn ein Ersteller 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 Ihnen, Nachrichtenspeicherrichtlinien zu konfigurieren, um sicherzustellen, dass Nachrichten Ihre Umgebung mit einer einzigen 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 berücksichtigen, wie Sie Ihre Arbeitslasten widerstandsfähiger gegenüber zonalen und regionalen Ausfällen machen können. Für jede Arbeitslast gelten eigene Verfügbarkeits- und Zuverlässigkeitsanforderungen sowie Eigenschaften. Es gibt jedoch einige Designprinzipien, die Sie anwenden können, sowie Strategien, mit denen Sie die Ausfallsicherheit im unwahrscheinlichen Fall von zonalen und regionalen Ausfällen verbessern können. Beachten Sie beim Entwerfen und Implementieren Ihrer Arbeitslasten Folgendes:

  • Implementieren Sie Site Reliability Engineering (SRE)-Praktiken und -Prinzipien. Automatisierung und umfassendes Monitoring sind Teil der Kernprinzipien von SRE. Google Cloud bietet die Tools und die professionellen Dienste für die Implementierung von SRE, um die Ausfallsicherheit und Zuverlässigkeit Ihrer Umgebungen zu erhöhen und den Arbeitsaufwand zu reduzieren.
  • Entwicklung für Skalierbarkeit und Ausfallsicherheit. Wenn Sie Arbeitslasten in Cloud-Umgebungen entwerfen, empfehlen wir Ihnen, die Skalierbarkeit und Ausfallsicherheit als inhärente Anforderungen zu betrachten, die Ihre Arbeitslasten berücksichtigen müssen. Weitere Informationen zu dieser Art von Design finden Sie unter Muster für skalierbare und robuste Anwendungen.
  • Planen Sie die Wiederherstellung nach Ausfällen der Cloud-Infrastruktur. Die Google Cloud-Verfügbarkeitsgarantien werden durch die Google Cloud-Service Level Agreements definiert. Im unwahrscheinlichen Fall eines zonalen oder regionalen Ausfalls empfehlen wir, Ihre Arbeitslasten so zu gestalten, dass sie zonalen und regionalen Ausfällen gegenüber resistent sind.
  • Implementieren Sie Load Shedding und graduelle Fehlertoleranz. Bei Fehlern in der Cloud-Infrastruktur oder Fehlern in anderen Abhängigkeiten Ihrer Arbeitslasten empfehlen wir Ihnen, Ihre Arbeitslasten so zu gestalten, dass sie stabil sind. Ihre Arbeitslasten sollten bestimmte und klar definierte Funktionalitätsebenen beibehalten, auch wenn Fehler auftreten (ordnungsgemäße Verschlechterung) und sie sollten einen Teil ihrer Last bewältigen können, während sie sich den Überlastungsbedingungen annähern (Load Shedding).
  • Planen Sie eine regelmäßige Wartung. Wenn Sie Ihr 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 Aktualisierungen und Konfigurationsänderungen auf Ihre Arbeitslasten und deren Abhängigkeiten umfassen und wie sich diese Aktivitäten auf die Verfügbarkeit Ihrer Umgebungen auswirken können. Sie können beispielsweise eine Hostwartungsrichtlinie für Ihre Compute Engine-Instanzen konfigurieren.
  • Testbasierten Entwicklungsansatz verfolgen Beim Entwerfen Ihrer Arbeitslasten empfehlen wir einen testbasierten Entwicklungsansatz, damit Ihre Arbeitslasten aus allen Winkeln wie vorgesehen funktionieren. Beispielsweise können Sie testen, ob Ihre Arbeitslasten und die Cloud-Infrastruktur die erforderlichen funktionalen, nicht funktionalen und Sicherheitsanforderungen erfüllen.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende:

Melden Sie sich auf LinkedIn an, um nicht öffentliche LinkedIn-Profile zu sehen.