Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur

Dieser Artikel ist Teil einer Reihe zur Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloud. In diesem Teil wird der Ablauf zur Architekturplanung von Arbeitslasten mit Google Cloud und von Bausteinen diskutiert, die gegen Ausfälle der Cloud-Infrastruktur resistent sind.

Die Reihe besteht aus folgenden Teilen:

Einführung

Wenn Unternehmen ihre Arbeitslasten in die öffentliche Cloud verschieben, müssen ihre Kenntnisse der Entwicklung belastbarer, lokaler Systeme auf die Hyperscale-Infrastruktur von Cloud-Anbietern wie Google Cloud übertragen werden. In diesem Artikel werden Branchenstandards zur Notfallwiederherstellung wie RTO (Recovery Time Objective) und RPO (Recovery Point Objective) der Google Cloud-Infrastruktur zugeordnet.

Die Anleitung in diesem Dokument entspricht einem der Hauptgrundsätze von Google zum Erzielen einer extrem hohen Dienstverfügbarkeit: Auf Ausfälle vorbereitet zu sein. Google Cloud arbeitet zwar äußerst zuverlässig, doch Katastrophen kommen vor – Naturkatastrophen, Glasfaserkabelbrüche und komplexe, unvorhersehbare Infrastrukturausfälle – und diese Katastrophen führen zu Ausfällen. Die richtige Vorbereitung auf Ausfälle ermöglicht es Google Cloud-Kunden, Anwendungen zu erstellen, die bei diesen unvermeidlichen Ereignissen eine vorhersehbare Leistung erzielen. Dazu wenden Google Cloud-Produkte "integrierte" DR-Mechanismen an.

Die Notfallwiederherstellung ist ein breites Thema, das weit mehr umfasst als nur Infrastrukturausfälle, wie z. B. Software-Fehler oder Datenschäden, und Sie sollten einen umfassenden End-to-End-Plan haben. Der Schwerpunkt dieses Artikels liegt jedoch auf einem Teil eines DR-Plans: Wie werden Anwendungen entworfen, die gegen Ausfälle der Cloud-Infrastruktur resistent sind? Dieser Artikel behandelt folgende Themen:

  1. Die Google Cloud-Infrastruktur, wie sich Katastrophenereignisse als Ausfälle der Google Cloud manifestieren und wie die Google Cloud konzipiert ist, sodass die Häufigkeit und der Umfang von Ausfällen minimiert werden.
  2. Einen Leitfaden zur Architekturplanung, der ein Framework zum Kategorisieren und Entwerfen von Anwendungen basierend auf der gewünschten Zuverlässigkeit bietet.
  3. Eine detaillierte Liste ausgewählter Google Cloud-Produkte mit integrierten DR-Funktionen, die Sie in Ihrer Anwendung verwenden können.

Weitere Informationen zur allgemeinen DR-Planung und zur Verwendung von Google Cloud als Komponente in Ihrer lokalen DR-Strategie finden Sie im Leitfaden zur Planung der Notfallwiederherstellung. Die Hochverfügbarkeit ist zwar eng mit der Notfallwiederherstellung verbunden, wird in diesem Artikel jedoch nicht behandelt. Weitere Informationen zur Architektur für Hochverfügbarkeit finden Sie im Architektur-Framework von Google Cloud.

Ein Hinweis zur Terminologie: Dieser Artikel bezieht sich auf Verfügbarkeit, wenn es darum geht, dass ein Produkt im Laufe der Zeit sinnvoll aufgerufen und genutzt werden soll. Zuverlässigkeit hingegen bezieht sich auf eine Reihe von Attributen, einschließlich Verfügbarkeit, aber auch Langlebigkeit und Richtigkeit.

Wie Google Cloud auf Ausfallsicherheit setzt

Google-Rechenzentren

In traditionellen Rechenzentren wird die Verfügbarkeit einzelner Komponenten maximiert. In der Cloud ermöglicht die Skalierbarkeit es Betreibern wie Google, Dienste über viele Komponenten mithilfe von Virtualisierungstechnologien zu verteilen und so die Zuverlässigkeit herkömmlicher Komponenten zu übertreffen. Sie können mit Ihrer Denkweise der Zuverlässigkeitsarchitektur nun also von den unzähligen Details abrücken, um die Sie sich früher lokal Sorgen gemacht haben. Sie müssen sich nicht mehr um die verschiedenen Fehlermodi von Komponenten wie Kühlung oder Stromversorgung kümmern, sondern können mit den Google Cloud-Produkten und ihren angegebenen Zuverlässigkeitsmesswerten planen. Diese Messwerte spiegeln das aggregierte Ausfallrisiko der gesamten zugrunde liegenden Infrastruktur wider. So können Sie sich anstatt um die Infrastrukturverwaltung mehr um das Design, die Bereitstellung und den Betrieb von Anwendungen kümmern.

Google entwirft basierend auf der umfangreichen Erfahrung beim Aufbau und dem Betrieb moderner Rechenzentren seine Infrastruktur so, dass aggressive Verfügbarkeitsziele erreicht werden. Google ist bei Rechenzentren weltweit führend. Von der Stromversorgung über die Kühlung bis hin zu Netzwerken hat jede Rechenzentrumstechnologie ihre eigenen Redundanzen und Abhilfemaßnahmen, einschließlich FMEA-Pläne. Die Rechenzentren von Google sind so aufgebaut, dass sie diese vielen verschiedenen Risiken ausgleichen und den Kunden eine konsistente erwartete Verfügbarkeit der Google Cloud-Produkte bieten. Google nutzt seine Erfahrung, um die Verfügbarkeit der gesamten physischen und logischen Systemarchitektur zu modellieren, damit die Rechenzentren den Erwartungen entsprechen. Die Entwickler von Google setzen alles daran, dass diese Erwartungen erfüllt werden können. Die tatsächlich gemessene Verfügbarkeit übertrifft unsere Ziele in der Regel um einiges.

Durch die Zusammenfassung all dieser Rechenzentrumsrisiken und -maßnahmen in nutzerorientierte Produkte entlastet Google Cloud Sie von diesen Design- und Betriebsverantwortlichkeiten. Stattdessen können Sie sich auf die Zuverlässigkeit konzentrieren, die in Google Cloud-Regionen und -Zonen integriert wurde.

Regionen und Zonen

Google Cloud-Produkte werden in einer Vielzahl von Regionen und Zonen angeboten. Regionen sind physisch unabhängige geografische Gebiete, die drei oder mehr Zonen enthalten. Zonen stellen physische Computerressourcen innerhalb einer Region dar, die im Hinblick auf die physische und logische Infrastruktur einen hohen Grad an Unabhängigkeit haben. Sie bieten anderen Zonen in derselben Region Netzwerkverbindungen mit hoher Bandbreite und niedriger Latenz. Die Region asia-northeast1 in Japan enthält beispielsweise drei Zonen: asia-northeast1-a, asia-northeast1-b und asia-northeast1-c.

Google Cloud-Produkte sind in zonale Ressourcen, regionale Ressourcen oder multiregionale Ressourcen unterteilt.

Zonale Ressourcen werden in einer einzigen Zone gehostet. Eine Dienstunterbrechung in dieser Zone kann sich auf alle Ressourcen in dieser Zone auswirken. Beispielsweise wird eine Compute Engine-Instanz in einer einzelnen, angegebenen Zone ausgeführt. Wenn ein Hardwarefehler einen Ausfall in dieser Zone hervorruft, ist diese Compute Engine-Instanz während der Unterbrechung nicht verfügbar.

Regionale Ressourcen werden redundant in mehreren Zonen innerhalb einer Region bereitgestellt. Sie haben eine höhere Zuverlässigkeit als zonale Ressourcen.

Multiregionale Ressourcen werden innerhalb und zwischen den Regionen verteilt. Im Allgemeinen haben multiregionale Ressourcen eine höhere Zuverlässigkeit als regionale Ressourcen. Auf dieser Ebene müssen die Produkte jedoch Verfügbarkeit, Leistung und Ressourceneffizienz optimieren. Deshalb ist es wichtig, die Vor- und Nachteile der Verwendung eines multiregionalen Produkts zu verstehen. Diese Nachteile werden weiter unten in diesem Dokument produktspezifisch beschrieben.

Beispiele für zonale, regionale und multiregionale Google Cloud-Produkte

Wie Sie Zonen und Regionen nutzen, um Zuverlässigkeit zu erreichen

Google SREs verwalten und skalieren hochzuverlässige, globale Nutzerprodukte wie Gmail und die Google Suche mithilfe einer Vielzahl von Techniken und Technologien, die eine nahtlose Nutzung der Computing-Infrastruktur auf der ganzen Welt ermöglichen. Dies beinhaltet das Weiterleiten von Traffic von nicht verfügbaren Standorten mithilfe von globalem Load-Balancing, die Ausführung mehrerer Replikate an vielen Standorten auf der Welt und die Replikation von Daten zwischen Standorten. Diese Funktionen stehen Google Cloud-Kunden über Produkte wie Cloud Load Balancing, Google Kubernetes Engine und Cloud Spanner zur Verfügung.

Google Cloud entwirft im Allgemeinen Produkte, die die folgenden Verfügbarkeitsstufen für Zonen und Regionen ermöglichen:

Ressource Beispiele Ziele für das Verfügbarkeitsdesign Implizierte Ausfallzeiten
Zonal Compute Engine, Persistent Disk 99,9 % 8,75 Stunden/Jahr
Regional Regionaler Cloud Storage, replizierte Persistent Disk, regionale Google Kubernetes Engine 99,99 % 52 Minuten/Jahr

Vergleichen Sie die Ziele für das Verfügbarkeitsdesign von Google Cloud mit der für Sie akzeptablen Ausfallzeit, um die entsprechenden Google Cloud-Ressourcen zu ermitteln. Während sich herkömmliche Designs auf die Verbesserung der Verfügbarkeit auf Komponentenebene konzentrieren, um die resultierende Anwendungsverfügbarkeit zu verbessern, konzentrieren sich Cloud-Modelle stattdessen auf die Zusammensetzung von Komponenten, um dieses Ziel zu erreichen. Viele Produkte in Google Cloud verwenden diese Technik. Cloud Spanner bietet beispielsweise eine multiregionale Datenbank mit mehreren Regionen, um eine Verfügbarkeit von 99,999 % zu ermöglichen.

Die Zusammensetzung ist wichtig, da ohne sie die Verfügbarkeit Ihrer Anwendung nicht höher sein kann als die der von Ihnen verwendeten Google Cloud-Produkte. Außer Ihre Anwendung fällt nie aus, hat sie sogar eine geringere Verfügbarkeit als die zugrunde liegenden Google Cloud-Produkte. Der Rest dieses Abschnitts zeigt allgemein, wie Sie mit einer Zusammensetzung aus zonalen und regionalen Produkten eine höhere Anwendungsverfügbarkeit als mit einer einzelnen Zone oder Region erreichen können. Im nächsten Abschnitt finden Sie einen praktischen Leitfaden zum Anwenden dieser Prinzipien auf Ihre Anwendungen.

Planung für zonale Ausfallbereiche

Infrastrukturausfälle verursachen in der Regel Dienstausfälle in einer einzelnen Zone. Innerhalb einer Region sind Zonen darauf ausgelegt, das Risiko von korrelierten Ausfällen mit anderen Zonen zu minimieren. Eine Dienstunterbrechung in einer Zone wirkt sich normalerweise nicht auf den Dienst in einer anderen Zone in derselben Region aus. Ein Ausfall, der auf eine Zone begrenzt ist, bedeutet nicht unbedingt, dass die gesamte Zone nicht verfügbar ist. Er definiert lediglich die Grenzen des Vorfalls. Möglicherweise hat ein Zonenausfall keine spürbaren Auswirkungen auf Ihre Ressourcen in dieser Zone.

Dies kommt selten vor. Es ist jedoch wichtig anzumerken, dass mehrere Zonen irgendwann innerhalb einer einzigen Region einen korrelierenden Ausfall erfahren werden. Wenn zwei oder mehr Zonen ausfallen, wird die unten beschriebene Strategie für den regionalen Ausfallbereich angewendet.

Regionale Ressourcen sind so konzipiert, dass sie Zonenausfälle tolerieren, indem sie einen Dienst aus mehreren Zonen bereitstellen. Wenn eine der Zonen, die eine regionale Ressource unterstützen, unterbrochen wird, stellt sich die Ressource automatisch selbst aus einer anderen Zone zur Verfügung. Lesen Sie die Beschreibung der Produktfähigkeiten im Anhang für weitere Einzelheiten sorgfältig durch.

Google Cloud bietet nur ein paar zonale Ressourcen, nämlich virtuelle Compute Engine-Maschinen (VMs) und Persistent Disk. Wenn Sie zonale Ressourcen verwenden möchten, müssen Sie Ihre eigene Ressourcenzusammensetzung durchführen, indem Sie Failover und Wiederherstellung zwischen zonalen Ressourcen, die sich in mehreren Zonen befinden, entwerfen, bauen und testen. Zu den Strategien gehören:

  • Schnelles Routing Ihres Traffics zu virtuellen Maschinen in einer anderen Zone mithilfe von Cloud Load Balancing, wenn bei einer Systemdiagnose Probleme in einer Zone festgestellt werden.
  • Mit Compute Engine-Instanzvorlagen und/oder verwalteten Instanzgruppen identische VM-Instanzen in mehreren Zonen ausführen und skalieren.
  • Mit einer regionalen Persistent Disk Daten synchron in einer anderen Zone innerhalb einer Region replizieren. Weitere Informationen finden Sie unter Hochverfügbarkeitsoptionen mit regionalen Persistent Disks.

Planung für regionale Ausfallbereiche

Ein regionaler Ausfall ist eine Dienstunterbrechung, die sich auf mehrere Zonen in einer einzelnen Region auswirkt. Es handelt sich um größere, weniger häufige Ausfälle, die durch Naturkatastrophen oder umfangreiche Infrastrukturausfälle verursacht werden können.

Bei einem regionalen Produkt, das auf eine Verfügbarkeit von 99,99 % ausgelegt ist, kann ein Ausfall immer noch zu fast einer Stunde Ausfallzeit pro Jahr bei einem bestimmten Produkt führen. Daher müssen Ihre kritischen Anwendungen möglicherweise über einen Plan zur Notfallwiederherstellung für mehrere Regionen verfügen, wenn diese Ausfallzeit inakzeptabel ist.

Multiregionale Ressourcen sind so konzipiert, dass sie regionale Ausfälle tolerieren, indem sie Dienste aus mehreren Regionen bereitstellen. Wie oben beschrieben wird bei multiregionalen Produkten ein Kompromiss zwischen Latenzzeit, Konsistenz und Kosten eingegangen. Der häufigste Kompromiss besteht zwischen der synchronen und asynchronen Datenreplikation. Die asynchrone Replikation bietet eine geringere Latenzzeit auf Kosten des Risikos eines Datenverlusts während eines Ausfalls. Sehen Sie sich daher für weitere Informationen die Beschreibung der Produktfunktion im Anhang an.

Wenn Sie regionale Ressourcen nutzen und gegenüber regionalen Ausfällen widerstandsfähig bleiben möchten, müssen Sie Ihre eigene Ressourcenzusammensetzung vornehmen, indem Sie Failover und Wiederherstellung zwischen regionalen Ressourcen, die sich in mehreren Regionen befinden, entwerfen, bauen und testen. Zusätzlich zu den zonalen Strategien oben, die Sie auch regionenübergreifend anwenden können, empfehlen wir Folgendes:

  • Regionale Ressourcen sollten Daten in eine sekundäre Region, in einen multi-regionalen Speicher wie Cloud Storage oder eine Hybrid-Cloud wie Anthos replizieren.
  • Nachdem Sie eine regionale Ausfallminderung eingerichtet haben, testen Sie diese regelmäßig. Nichts ist schlimmer, als zu glauben, man sei gegen einen Ausfall einer einzelnen Region resistent, nur um im Fall der Fälle festzustellen, dass das nicht stimmt.

Google Cloud-Ansatz zu Ausfallsicherheit und Verfügbarkeit

Google Cloud übertrifft regelmäßig die eigenen Verfügbarkeitsziele. Sie sollten jedoch nicht davon ausgehen, dass diese bisherige starke Leistung die Mindestverfügbarkeit darstellt, für die Sie entwickeln können. Stattdessen sollten Sie Google Cloud-Abhängigkeiten auswählen, deren vorgesehene Ziele die beabsichtigte Zuverlässigkeit Ihrer Anwendung übersteigen, sodass die Summe der Ausfallzeit Ihrer Anwendung und von Google Cloud das gewünschte Ergebnis liefert.

Ein gut konzipiertes System kann die folgende Frage beantworten: "Was geschieht, wenn eine Zone oder Region 1, 5, 10 oder 30 Minuten ausfällt?" Dies sollte auf vielen Ebenen betrachtet werden, einschließlich:

  • Wie erleben meine Kunden einen Ausfall?
  • Wie erkenne ich, dass ein Ausfall vorliegt?
  • Was passiert mit meiner Anwendung während eines Ausfalls?
  • Was passiert mit meinen Daten während eines Ausfalls?
  • Was passiert mit anderen Anwendungen bei einem Ausfall (aufgrund von gegenseitigen Abhängigkeiten)?
  • Was muss ich tun, um die Wiederherstellung nach einem Ausfall zu gewährleisten? Wer erledigt sie?
  • Wer muss innerhalb eines bestimmten Zeitraums über einen Ausfall informiert werden?

Detaillierte Anleitung zur Entwicklung der Notfallwiederherstellung für Anwendungen in Google Cloud

In den vorherigen Abschnitten wurde beschrieben, wie Google eine Cloud-Infrastruktur erstellt. Außerdem wurden einige Ansätze für den Umgang mit zonalen und regionalen Ausfällen beschrieben.

Dieser Abschnitt hilft Ihnen bei der Entwicklung eines Frameworks für die Anwendung des Zusammensetzungsprinzips auf Ihre Anwendungen, basierend auf den von Ihnen gewünschten Zuverlässigkeitswerten.

Kundenanwendungen in Google Cloud, die auf Ziele der Notfallwiederherstellung wie RTO und RPO abzielen, müssen so konzipiert werden, dass geschäftskritische Vorgänge gemäß RTO/RPO nur von Komponenten der Datenebene abhängig sind, die für für die kontinuierliche Verarbeitung von Vorgängen für den Dienst verantwortlich sind. Das bedeutet, dass geschäftskritische Vorgänge des Kunden nicht von den Vorgängen der Verwaltungsebene abhängen, die den Konfigurationsstatus verwalten und die Konfiguration an die Steuerungsebene und die Datenebene übertragen.

Beispielsweise sollten Google Cloud-Kunden, die einen RTO für geschäftskritische Vorgänge erreichen möchten, nicht von einer VM-Erstellungs-API oder der Aktualisierung einer Identitäts- und Zugriffsverwaltungsberechtigung abhängig sein.

Schritt 1: Vorhandene Anforderungen erfassen

Der erste Schritt besteht darin, die Verfügbarkeitsanforderungen für Ihre Anwendungen festzulegen. Die meisten Unternehmen haben bereits gewisse Design-Leitlinien in diesem Bereich, die intern entwickelt oder von Vorschriften oder anderen rechtlichen Erfordernissen abgeleitet worden sein können. Diese Design-Leitlinien werden normalerweise in zwei Messwerte unterteilt: "Recovery Time Objective (RTO)" und "Recovery Point Objective" (RPO). Aus geschäftlicher Sicht bedeutet RTO: "Wie schnell bin ich nach einem Notfall wieder einsatzbereit?". RPO bedeutet demnach: "Wie viele Daten darf ich im Falle eines Notfalls verlieren?".

Eine Skala, die die Zeit anzeigt. Das Ereignis befindet sich in der Mitte. Ganz links steht das RPO mit den Worten: "Diese Schreibvorgänge sind verloren gegangen.". Rechts sehen Sie RTO mit dem Hinweis: "Normaler Dienst wird fortgesetzt.".

In der Vergangenheit wurden von Unternehmen RTO- und RPO-Anforderungen für eine Vielzahl von Notfällen von Komponentenausfällen bis hin zu Erdbeben festgelegt. Dies war in lokalen Umgebungen sinnvoll, in der Planer die RTO-/RPO-Anforderungen über den gesamten Software- und Hardwarebereich abbilden mussten. In der Cloud müssen Sie Ihre Anforderungen nicht mehr derart genau bestimmen, da der Anbieter dies übernimmt. Stattdessen können Sie Ihre RTO- und RPO-Anforderungen in Bezug auf den Umfang des Verlusts (ganze Zonen oder Regionen) definieren, ohne die zugrunde liegenden Gründe anzugeben. Für Google Cloud vereinfacht dies Ihre Anforderungen auf 3 Szenarien: einen zonalen Ausfall, einen regionalen Ausfall oder den äußerst unwahrscheinlichen Ausfall mehrerer Regionen.

In dem Wissen, dass nicht jede Anwendung gleich kritisch ist, kategorisieren die meisten Kunden ihre Anwendungen in Kritikalitätsstufen, auf die eine bestimmte RTO/RPO-Anforderung angewendet werden kann. Zusammengenommen vereinfachen RTO/RPO und die Anwendungskritikalität die Erstellung einer bestimmten Anwendung durch Beantwortung der folgenden Fragen:

  1. Muss die Anwendung in mehreren Zonen in derselben Region oder in mehreren Zonen in mehreren Regionen ausgeführt werden?
  2. Von welchen Google Cloud-Produkten darf die Anwendung abhängen?

Dies ist ein Beispiel für das Ergebnis der Anforderungserhebung:

RTO und RPO nach Anwendungskritikalität für die Beispielfirma Co:

Anwendungskritikalität % der Apps Beispiel-Apps Zonenausfall Regionsausfall
Stufe 1

(am wichtigsten)

5 % In der Regel globale oder kundenseitige Anwendungen wie Echtzeitzahlungen und E-Commerce-Verkäuferseiten. RTO Null

RPO Null

RTO Null

RPO Null

Preisstufe 2 35 % In der Regel regionale Anwendungen oder wichtige interne Anwendungen wie CRM oder ERP. RTO 15 Minuten

RPO 15 Minuten

RTO 1 Stunde

RPO 1 Stunde

Stufe 3

(am wenigsten wichtig)

60 % In der Regel Team- oder Abteilungsanwendungen wie Backoffice, Abwesenheitsbuchungen, interne Reisen, Buchhaltung und Personalwesen. RTO 1 Stunde

RPO 1 Stunde

RTO 12 Std.

RPO 24 Stunden

Schritt 2: Funktionszuordnung von verfügbaren Produkten

Im zweiten Schritt werden die Robustheitsfunktionen von Google Cloud-Produkten erläutert, die Ihre Anwendungen verwenden werden. Die meisten Unternehmen prüfen die relevanten Produktinformationen und fügen dann Anleitungen hinzu, wie sie ihre Architekturen modifizieren können, um Lücken zwischen den Produktfunktionen und ihren Robustheitsanforderungen zu schließen. In diesem Abschnitt werden einige gängige Bereiche und Empfehlungen zu Daten- und Anwendungseinschränkungen in diesem Bereich beschrieben.

Wie bereits erwähnt, bieten DR-fähige Produkte von Google im Allgemeinen zwei Arten von Ausfallbereichen: regionale und zonale. Partielle Ausfälle sollten für die Notfallwiederherstellung auf die gleiche Weise geplant werden wie ein Komplettausfall. Daraus ergibt sich eine erste Gesamtmatrix, welche Produkte standardmäßig für jedes Szenario geeignet sind:

Allgemeine Produktfunktionen von Google Cloud
(siehe Anhang für spezifische Produktfunktionen)

Alle Google Cloud-Produkte Regionale Google Cloud-Produkte mit automatischer Replikation über Zonen hinweg Multiregionale oder globale Google Cloud-Produkte mit automatischer Replikation über Regionen hinweg
Ausfall einer Komponente in einer Zone Abgedeckt* Abgedeckt Abgedeckt
Zonenausfall Nicht abgedeckt Abgedeckt Abgedeckt
Regionsausfall Nicht abgedeckt Nicht abgedeckt Abgedeckt

* Alle Google Cloud-Produkte sind gegenüber Komponentenausfällen stabil, außer in speziellen Fällen, die in der Produktdokumentation aufgeführt sind. Es handelt sich in der Regel um Szenarien, in denen das Produkt einen direkten Zugriff oder eine statische Zuordnung zu einer besonderen Hardware wie Speicher oder Solid State Disks (SSD) bietet.

So schränkt RPO die Produktauswahl ein

Bei den meisten Cloud-Bereitstellungen ist die Datenintegrität der architektonisch bedeutendste Aspekt, der für einen Dienst in Betracht gezogen werden muss. Zumindest einige Anwendungen haben eine RPO-Anforderung von Null, was bedeutet, dass es bei einem Ausfall keinen Datenverlust geben sollte. Dies erfordert in der Regel, dass Daten synchron in eine andere Zone oder Region repliziert werden. Die synchrone Replikation geht Kompromisse in Bezug auf Kosten und Latenz ein. Während viele Google Cloud-Produkte die synchrone Replikation über Zonen hinweg anbieten, ermöglichen nur wenige die regionenübergreifende Replikation. Diese Kompromisse in Bezug auf Kosten und Komplexität bedeuten, dass es nicht ungewöhnlich ist, dass verschiedene Arten von Daten innerhalb einer Anwendung unterschiedliche RPO-Werte haben.

Bei Daten mit einem RPO-Wert größer als null können Anwendungen die asynchrone Replikation nutzen. Eine asynchrone Replikation ist akzeptabel, wenn verloren gegangene Daten einfach neu erstellt oder bei Bedarf aus einer goldenen Datenquelle wiederhergestellt werden können. Sie kann auch eine vernünftige Wahl sein, wenn geringer Datenverlust im Kontext erwarteter zonaler und regionaler Ausfallzeiten ein akzeptabler Kompromiss ist. Es ist auch von Bedeutung, dass während eines vorübergehenden Ausfalls Daten, die an den betroffenen Standort geschrieben, aber noch nicht an einen anderen Standort repliziert wurden, im Allgemeinen verfügbar werden, nachdem der Ausfall behoben ist. Das bedeutet, dass das Risiko eines dauerhaften Datenverlusts geringer ist als das Risiko, während eines Ausfalls den Datenzugriff zu verlieren.

Schlüsselaktionen: Stellen Sie fest, ob Sie definitiv RPO Null benötigen, und wenn ja, ob dies für eine Teilmenge Ihrer Daten ausreicht. Hierdurch erweitert sich das Spektrum der Ihnen zur Verfügung stehenden DR-fähigen Dienste. In Google Cloud bedeutet das Erreichen von RPO Null, dass Sie für Ihre Anwendung vorwiegend regionale Produkte verwenden, die standardmäßig gegenüber Ausfällen auf Zonen-, nicht aber auf Regionsebene ausfallsicher sind.

So schränkt RTO die Produktauswahl ein

Einer der Hauptvorteile von Cloud-Computing ist die Möglichkeit, Infrastruktur nach Bedarf bereitzustellen. Dies entspricht jedoch nicht der sofortigen Bereitstellung. Der RTO-Wert für Ihre Anwendung muss die kombinierte RTO der Google Cloud-Produkte, die Ihre Anwendung nutzt, sowie alle Maßnahmen berücksichtigen, die Ihre Ingenieure oder SREs (Site Reliability Engineers) ergreifen müssen, um Ihre VMs oder Anwendungskomponenten neu zu starten. Ein in Minuten gemessener RTO-Wert heißt, dass eine Anwendung entworfen wird, die sich nach einem Notfall ohne menschliches Eingreifen oder mit minimalen Schritten wie dem Drücken eines Knopfes für ein Failover automatisch wiederherstellt. Die Kosten und Komplexität eines solchen Systems waren in der Vergangenheit sehr hoch, aber Google Cloud-Produkte wie Load-Balancer und Instanzgruppen machen dieses Design wesentlich kostengünstiger und nutzerfreundlicher. Daher sollten Sie für die meisten Anwendungen einen automatischen Failover und die automatische Wiederherstellung in Betracht ziehen. Die Entwicklung eines Systems für diese Art von "heißem Failover" über Regionen hinweg ist sowohl kompliziert als auch kostspielig. Diese Funktion kann nur von einem sehr kleinen Teil kritischer Dienste genutzt werden.

Die meisten Anwendungen werden einen RTO-Wert zwischen einer Stunde und einem Tag haben, was ein "warmes Failover" in einem Notfallwiederherstellungsszenario ermöglicht. Dabei werden einige Komponenten der Anwendung die ganze Zeit im Standby-Modus laufen (wie z. B. Datenbanken), während andere im Falle eines tatsächlichen Notfalls horizontal skaliert werden (scale out), wie z. B. Webserver. Bei diesen Anwendungen sollten Sie für die Scale-Out-Ereignisse unbedingt eine Automatisierung in Betracht ziehen. Dienste mit einem RTO-Wert über einen Tag haben die niedrigste Kritikalität und können häufig aus einer Sicherung wiederhergestellt oder von Grund auf neu erstellt werden.

Schlüsselaktionen: Legen Sie fest, ob für einen regionalen Failover wirklich ein RTO von (fast) null erforderlich ist. Ist dies der Fall, sollten Sie dies nur für einen Teil Ihrer Dienste anwenden. Dadurch ändern sich die Kosten für den Betrieb und die Wartung Ihres Dienstes.

Schritt 3: Eigene Referenzarchitekturen und -anleitungen entwickeln

Der letzte empfohlene Schritt besteht darin, eigene unternehmensspezifische Architekturmuster zu entwickeln, die Ihren Teams dabei helfen, den Ansatz der Notfallwiederherstellung zu standardisieren. Die meisten Google Cloud-Kunden erstellen einen Leitfaden für ihre Entwicklerteams, der ihre individuellen Erwartungen an die geschäftliche Robustheit mit den beiden Hauptkategorien von Ausfallszenarien in Google Cloud in Einklang bringt. Auf diese Weise können Teams leicht erkennen, welche DR-fähigen Produkte für die einzelnen Kritikalitätsstufen geeignet sind.

Produktrichtlinien erstellen

Betrachtet man die RTO/RPO-Beispieltabelle von oben noch einmal, so erhält man einen hypothetischen Leitfaden, der auflistet, welche Produkte standardmäßig für jede Kritikalitätsstufe zugelassen wären. Beachten Sie, dass Sie in Fällen, in denen bestimmte Produkte standardmäßig als ungeeignet identifiziert wurden, jederzeit Ihre eigenen Replikations- und Failover-Mechanismen hinzufügen können, um eine zonen- oder regionenübergreifende Synchronisierung zu ermöglichen. Dies ginge jedoch über den Rahmen dieses Artikels hinaus. Die Tabellen enthalten außerdem Links zu weiteren Informationen über die einzelnen Produkte, damit Sie ihre Funktionen in Bezug auf die Verwaltung von Zonen- oder Regionsausfällen besser verstehen können.

Beispiele für Architekturmuster für die Beispielorganisation "Co" – Zonenausfallrobustheit

Google Cloud-Produkt Erfüllt das Produkt die Anforderungen an Zonenausfälle für die Beispielorganisation (mit entsprechender Produktkonfiguration)?
Stufe 1 Stufe 2 Stufe 3
Compute Engine Nein Nein Nein
Dataflow Nein Nein Nein
BigQuery Nein Nein Ja
Google Kubernetes Engine Ja Ja Ja
Cloud Storage Ja Ja Ja
Cloud SQL Nein Ja Ja
Cloud Spanner Ja Ja Ja
Cloud Load Balancing Ja Ja Ja

Diese Tabelle basiert nur auf den oben gezeigten hypothetischen Stufen.

Architekturmuster für die Beispielorganisation "Co" – Regionsausfallrobustheit

Google Cloud-Produkt Erfüllt das Produkt die Anforderungen an Regionsausfälle für die Beispielorganisation (mit entsprechender Produktkonfiguration)?
Stufe 1 Stufe 2 Stufe 3
Compute Engine Ja Ja Ja
Dataflow Nein Nein Nein
BigQuery Nein Nein Ja
Google Kubernetes Engine Ja Ja Ja
Cloud Storage Nein Nein Nein
Cloud SQL Ja Ja Ja
Cloud Spanner Ja Ja Ja
Cloud Load Balancing Ja Ja Ja

Diese Tabelle basiert nur auf den oben gezeigten hypothetischen Stufen.

Anhand der folgenden Abschnitten werden einige Referenzarchitekturen für jede der hypothetischen Anwendungskritikalitätsstufen durchlaufen, um zu zeigen, wie diese Produkte eingesetzt würden. Dabei handelt es sich bewusst um Beschreibungen auf hohem Niveau, um die wichtigsten architektonischen Entscheidungen zu veranschaulichen. Sie sind nicht repräsentativ für einen vollständigen Lösungsentwurf.

Beispielarchitektur für Stufe 3

Anwendungskritikalität Zonenausfall Regionsausfall
Stufe 3
(niedrigste Priorität)
RTO 12 Stunden
RPO 24 Stunden
RTO 28 Tage
RPO 24 Stunden

Beispiel einer Architektur der Stufe 3 mit Google Cloud-Produkten

(Ausgegraute Symbole zeigen an, dass die Infrastruktur für die Wiederherstellung aktiviert werden muss.)

Diese Architektur beschreibt eine herkömmliche Client-/Server-Anwendung: Interne Nutzer stellen eine Verbindung zu einer Anwendung her, die auf einer Compute-Instanz läuft, die von einer Datenbank für nichtflüchtigen Speicher unterstützt wird.

Beachten Sie, dass von dieser Architektur bessere RTO- und RPO-Werte unterstützt werden, als dies erforderlich ist. Sie sollten jedoch auch das Entfernen zusätzlicher manueller Schritte in Betracht ziehen, sollten sich diese als teuer oder unzuverlässig herausstellen. Die Wiederherstellung einer Datenbank aus einer Nachtsicherung kann z. B. einen RPO-Wert von 24 Stunden unterstützen. Insbesondere wenn mehrere Dienste gleichzeitig betroffen sind, wäre hierfür jedoch in der Regel eine Fachkraft (z. B. ein Datenbankadministrator) erforderlich, die möglicherweise nicht verfügbar ist. Mit der On-Demand-Infrastruktur von Google Cloud können Sie diese Funktion aufbauen, ohne große Kompromisse bei den Kosten einzugehen. Daher verwendet diese Architektur Cloud SQL HA anstelle einer manuellen Sicherungs-/Wiederherstellungsfunktion bei zonalen Ausfällen.

Wichtige Architekturentscheidungen für den Ausfall einer Zone – RTO von 12 Stunden und RPO von 24 Stunden:

  • Ein interner Load-Balancer wird verwendet, um den Nutzern einen skalierbaren Zugriffspunkt zur Verfügung zu stellen, der ein automatisches Failover auf eine andere Zone ermöglicht. Auch wenn der RTO-Wert 12 Stunden beträgt, können manuelle Änderungen an IP-Adressen oder sogar DNS-Aktualisierungen länger dauern als erwartet.
  • Eine regional verwaltete Instanzgruppe wird mit mehreren Zonen, aber minimalen Ressourcen konfiguriert. Dadurch werden Kosten optimiert, gleichzeitig können virtuelle Maschinen in der Sicherungszone jedoch schnell horizontal skaliert werden.
  • Eine Cloud SQL-Konfiguration für Hochverfügbarkeit bietet automatisches Failover in eine andere Zone. Datenbanken sind im Vergleich zu den virtuellen Maschinen in Compute Engine erheblich schwieriger zu erstellen und wiederherzustellen.

Wichtige Architekturentscheidungen für den Ausfall einer Region – RTO von 28 Tagen und RPO von 24 Stunden:

  • Ein Load-Balancer würde nur im Falle eines regionalen Ausfalls in Region 2 erstellt werden. Cloud DNS wird verwendet, um eine orchestrierte, aber manuelle regionale Failover-Funktion bereitzustellen, da die Infrastruktur in Region 2 nur im Falle eines Regionsausfalls verfügbar wäre.
  • Eine neue verwaltete Instanzgruppe würde nur im Falle eines regionalen Ausfalls erstellt werden. Dies optimiert Kosten und wird wahrscheinlich aufgrund der kurzen Dauer der meisten regionalen Ausfälle nicht aufgerufen. Beachten Sie bitte, dass das Diagramm der Einfachheit halber nicht das Kopieren der benötigten Compute Engine-Bilder und auch nicht die zugehörigen Tools zeigt, die für die erneute Bereitstellung benötigt werden.
  • Eine neue Cloud SQL-Instanz würde neu erstellt und die Daten aus einer Sicherung wiederhergestellt werden. Auch hier ist das Risiko eines erweiterten Ausfalls in einer Region extrem niedrig. Es handelt sich hier also um einen weiteren Kompromiss zur Kostenoptimierung.
  • Zum Speichern dieser Sicherungen wird multiregionaler Cloud Storage verwendet. Dies ermöglicht automatische zonale und regionale Robustheit innerhalb des RTO- und RPO-Werts.

Beispielarchitektur für Stufe 2

Anwendungskritikalität Zonenausfall Regionsausfall
Stufe 2 RTO 4 Stunden
RPO null
RTO 24 Stunden
RPO 4 Stunden

Beispiel einer Architektur der Stufe 2 mit Google Cloud-Produkten

Diese Architektur beschreibt ein Data Warehouse mit internen Nutzern, die eine Verbindung zu einer Visualisierungsebene für die Compute-Instanz und einer Datenaufnahme- und Transformationsebene herstellen, die das Back-End-Data Warehouse füllt.

Einige Einzelkomponenten dieser Architektur unterstützen den RPO-Wert, der für ihre Stufe erforderlich ist, nicht direkt. Aufgrund der gemeinsamen Nutzung erfüllt der Dienst insgesamt jedoch den RPO-Wert. Da Dataflow ein zonales Produkt ist, sollten Sie sich in diesem Fall an die Empfehlungen für Hochverfügbarkeitsdesigns halten, um Datenverluste während eines Zonenausfalls zu vermeiden. Die Cloud Storage-Ebene ist jedoch die goldene Quelle dieser Daten und unterstützt einen RPO-Wert von null. Alle verlorenen Daten können also im Falle eines Ausfalls in Zone A über Zone B wieder in BigQuery aufgenommen werden.

Wichtige Architekturentscheidungen für den Ausfall einer Zone – RTO von 4 Stunden und RPO von null:

  • Ein Load-Balancer wird verwendet, um den Nutzern einen skalierbaren Zugriffspunkt zur Verfügung zu stellen, der ein automatisches Failover auf eine andere Zone ermöglicht. Auch wenn der RTO-Wert 4 Stunden beträgt, können manuelle Änderungen an IP-Adressen oder sogar DNS-Aktualisierungen länger dauern als erwartet.
  • Eine regional verwaltete Instanzgruppe für die Computing-Ebene der Datenvisualisierung wird mit mehreren Zonen, aber minimalen Ressourcen konfiguriert. Dadurch werden Kosten optimiert, gleichzeitig können virtuelle Maschinen jedoch schnell horizontal skaliert werden.
  • Regionaler Cloud Storage wird als Staging-Ebene für die erste Datenaufnahme verwendet und bietet automatische Zonenausfallsicherheit.
  • Mit Dataflow werden Daten aus Cloud Storage extrahiert und vor dem Laden in BigQuery transformiert. Bei einem Zonenausfall handelt es sich um einen zustandslosen Prozess, der in einer anderen Zone neu gestartet werden kann.
  • BigQuery stellt das Data-Warehouse-Back-End für das Front-End der Datenvisualisierung bereit. Im Falle eines Zonenausfalls werden alle verlorenen Daten wieder aus Cloud Storage aufgenommen.

Wichtige Architekturentscheidungen für den Ausfall einer Region – RTO von 24 Stunden und RPO von 4 Stunden:

  • Ein Load-Balancer in jeder Region wird verwendet, um Nutzern einen skalierbaren Zugriffspunkt bereitzustellen. Cloud DNS wird verwendet, um eine orchestrierte, aber manuelle regionale Failover-Funktion bereitzustellen, da die Infrastruktur in Region 2 nur im Falle eines Regionsausfalls verfügbar wäre.
  • Eine regional verwaltete Instanzgruppe für die Computing-Ebene der Datenvisualisierung wird mit mehreren Zonen, aber minimalen Ressourcen konfiguriert. Dies ist nur möglich, wenn der Load-Balancer neu konfiguriert wurde, erfordert aber ansonsten keinen manuellen Eingriff.
  • Regionaler Cloud Storage wird als Staging-Ebene für die erste Datenaufnahme verwendet. Diese wird gleichzeitig in beide Regionen geladen, um die RPO-Anforderungen zu erfüllen.
  • Mit Dataflow werden Daten aus Cloud Storage extrahiert und vor dem Laden in BigQuery transformiert. Im Falle eines Regionsausfalls würde BigQuery die aktuellen Daten aus Cloud Storage erhalten.
  • BigQuery stellt das Data Warehouse-Back-End bereit. Im Normalbetrieb würde es unregelmäßig aktualisiert werden. Im Falle eines Regionsausfalls werden die neuesten Daten über Dataflow aus Cloud Storage wieder aufgenommen.

Beispielarchitektur für Stufe 1

Anwendungskritikalität Zonenausfall Regionsausfall
Stufe 1
(am wichtigsten)
RTO null
RPO null
RTO 4 Stunden
RPO 1 Stunde

Beispiel einer Architektur der Stufe 1 mit Google Cloud-Produkten

Diese Architektur beschreibt eine Back-End-Infrastruktur für mobile Apps, die externe Nutzer mit einer Reihe von Mikrodiensten verbindet, die in Google Kubernetes Engine ausgeführt werden. Cloud Spanner stellt die Back-End-Datenspeicherebene für Echtzeitdaten bereit und Verlaufsdaten werden in jeder Region in einen BigQuery-Data Lake gestreamt.

Auch hier unterstützen einige Einzelkomponenten dieser Architektur den RPO-Wert, der für ihre Stufe erforderlich ist, nicht direkt. Aufgrund der gemeinsamen Nutzung erfüllt der Dienst insgesamt jedoch den RPO-Wert. In diesem Fall wird BigQuery für Analyseabfragen verwendet. Jede Region wird gleichzeitig aus Cloud Spanner gespeist.

Wichtige Architekturentscheidungen für den Ausfall einer Zone – RTO von null und RPO von null:

  • Ein Load-Balancer wird verwendet, um den Nutzern einen skalierbaren Zugriffspunkt zur Verfügung zu stellen, der ein automatisches Failover auf eine andere Zone ermöglicht.
  • Für die Anwendungsebene, die mit mehreren Zonen konfiguriert ist, wird ein regionaler Google Kubernetes Engine-Cluster verwendet. Dadurch wird das RTO von null in jeder Region erreicht.
  • Cloud Spanner mit mehreren Regionen wird als Datenpersistenzebene verwendet und bietet automatische Zonendatenstabilität und Transaktionskonsistenz.
  • BigQuery bietet die Analysefunktion für die Anwendung. Jede Region wird unabhängig von Cloud Spanner mit Daten versorgt und die Anwendung greift unabhängig darauf zu.

Wichtige Architekturentscheidungen für den Ausfall einer Region – RTO von 4 Stunden und RPO von 1 Stunde:

  • Ein Load-Balancer wird verwendet, um den Nutzern einen skalierbaren Zugriffspunkt zur Verfügung zu stellen, der ein automatisches Failover in eine andere Region ermöglicht.
  • Für die Anwendungsebene, die mit mehreren Zonen konfiguriert ist, wird ein regionaler Google Kubernetes Engine-Cluster verwendet. Bei einem Ausfall der Region wird der Cluster in der alternativen Region automatisch skaliert, um die zusätzliche Verarbeitungslast zu übernehmen.
  • Cloud Spanner mit mehreren Regionen wird als Datenpersistenzebene verwendet und bietet automatische regionale Datenstabilität und Transaktionskonsistenz. Dies ist die Schlüsselkomponente zum Erreichen des regionenübergreifenden RPO von 1 Stunde.
  • BigQuery bietet die Analysefunktion für die Anwendung. Jede Region wird unabhängig von Cloud Spanner mit Daten versorgt und die Anwendung greift unabhängig darauf zu. Diese Architektur kompensiert die BigQuery-Komponente, sodass sie den Anforderungen der Gesamtanwendung entspricht.

Anhang: Produktreferenz

In diesem Abschnitt werden die Architektur und die DR-Funktionen der Google Cloud-Produkte beschrieben, die am häufigsten in Kundenanwendungen verwendet werden und die leicht zur Erfüllung Ihrer DR-Anforderungen genutzt werden können.

Häufige Themen

Viele Google Cloud-Produkte bieten regionale oder multiregionale Konfigurationen. Regionale Produkte sind widerstandsfähig gegen Zonenausfälle und multiregionale und globale Produkte sind widerstandsfähig gegen regionale Ausfälle. Im Allgemeinen bedeutet dies, dass Ihre Anwendung während eines Ausfalls nur minimale Unterbrechungen erfährt. Google erreicht diese Ergebnisse durch einige gemeinsame Architekturansätze, die die oben beschriebenen Leitlinien spiegeln.

  • Redundante Bereitstellung: Die Anwendungs-Back-Ends und der Datenspeicher werden über mehrere Zonen innerhalb einer Region und mehrere Regionen innerhalb eines multiregionalen Standorts bereitgestellt.
  • Datenreplikation: Produkte verwenden eine synchrone oder asynchrone Replikation über die redundanten Standorte hinweg.

    • Synchrone Replikation bedeutet, dass Ihre Anwendung bei einem API-Aufruf zum Erstellen oder Ändern von Daten, die vom Produkt gespeichert werden, erst dann eine erfolgreiche Antwort erhält, wenn das Produkt die Daten an mehrere Standorte geschrieben hat. Die synchrone Replikation sorgt dafür, dass Sie während eines Ausfalls der Google Cloud-Infrastruktur auf Ihre Daten zugreifen können, da sämtliche Ihrer Daten an einem der verfügbaren Back-End-Standorte zugänglich sind.

      Obwohl diese Technik den maximalen Schutz Ihrer Daten gewährleistet, kann sie im Hinblick auf Latenz und Leistung mit Kompromissen einhergehen. Bei Produkten mit mehreren Regionen, die die synchrone Replikation verwenden, wird dieser Kompromiss am deutlichsten – in der Regel in der Größenordnung von 10 oder 100 Millisekunden zusätzlicher Latenzzeit.

    • Asynchrone Replikation bedeutet, dass Ihre Anwendung bei einem API-Aufruf zum Erstellen oder Ändern von Daten, die vom Produkt gespeichert werden, eine erfolgreiche Antwort erhält, sobald das Produkt die Daten an einen einzigen Standort geschrieben hat. Im Anschluss an Ihre Schreibanfrage repliziert das Produkt Ihre Daten an weitere Standorte.

      Dieses Verfahren bietet eine geringere Latenz und einen höheren Durchsatz bei der API als die synchrone Replikation, allerdings auf Kosten des Schutzes Ihrer Daten. Wenn der Standort, an dem Sie Daten geschrieben haben, einen Ausfall erfährt, bevor die Replikation abgeschlossen wurde, haben Sie keinen Zugriff mehr auf diese Daten, bis der Standortausfall behoben wurde.

  • Ausfälle mit Load-Balancing verwalten: Google Cloud verwendet Software-Load-Balancing, um Anfragen an die entsprechenden Anwendungs-Back-Ends weiterzuleiten. Im Vergleich zu anderen Ansätzen wie dem DNS-Load-Balancing verkürzt dieser Ansatz die Systemantwortzeit auf einen Ausfall. Wenn ein Google Cloud-Standortausfall auftritt, erkennt der Load-Balancer schnell, dass das an diesem Standort bereitgestellte Back-End fehlerhaft ist, und leitet alle Anfragen an ein Back-End an einem anderen Speicherort weiter. Dadurch kann das Produkt die Anfragen Ihrer Anwendung während eines Standortausfalls weiter verarbeiten. Sobald der Standortausfall behoben wurde, erkennt der Load-Balancer die Verfügbarkeit der Produkt-Back-Ends an diesem Standort und leitet den Traffic noch einmal dorthin.

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-Instanzen sind zonale Ressourcen, d. h. dass im Falle eines Zonenausfalls standardmäßig keine Instanzen verfügbar sind. Compute Engine bietet verwaltete Instanzgruppen (Managed Instance Groups, MIGs), die automatisch zusätzliche VMs aus vorkonfigurierten Instanzvorlagen hochskalieren können, sowohl innerhalb einer einzigen Zone als auch über mehrere Zonen innerhalb einer Region hinweg. MIGs sind ideal für Anwendungen, die Widerstandsfähigkeit gegen Zonenverlust erfordern und zustandslos sind, aber Konfiguration und Ressourcenplanung erfordern. Mit mehreren regionalen MIGs können Sie regionale Ausfallsicherheit für zustandslose Anwendungen erreichen.

Anwendungen mit zustandsorientierten Arbeitslasten können weiterhin zustandsorientierte MIGs verwenden, für die jedoch zusätzliche Kapazitäten erforderlich sind, da sie nicht horizontal skaliert werden können. In beiden Szenarien ist es wichtig, Compute Engine-Instanzvorlagen und MIGs im Vorfeld ordnungsgemäß zu konfigurieren und zu testen, um sicherzustellen, dass die Failover-Funktionen für andere Zonen funktionieren. Weitere Informationen finden Sie im Abschnitt Architekturmuster.

Netzwerk für Compute Engine

Informationen zu Hochverfügbarkeitskonfigurationen für Interconnect-Verbindungen finden Sie in den folgenden Dokumenten:

Sie können externe IP-Adressen im globalen oder regionalen Modus bereitstellen. Dies wirkt sich auf ihre Verfügbarkeit aus, wenn ein regionaler Ausfall auftritt.

Ausfallsicherheit von Cloud Load Balancing

Load-Balancer sind ein sehr wichtiger Bestandteil der meisten hochverfügbaren Anwendungen. Google Cloud bietet sowohl regionale als auch globale Load-Balancer. In beiden Fällen ist es wichtig zu verstehen, dass die Ausfallsicherheit der gesamten Anwendung nicht nur vom gewählten Load-Balancer, sondern auch von der Redundanz Ihrer Back-End-Dienste abhängt.

In der folgenden Tabelle wird die Ausfallsicherheit des Load-Balancers basierend auf der Verteilung oder dem Bereich des Load-Balancers zusammengefasst.

Load-Balancer-Bereich Architektur Stabil bei zonalem Ausfall Stabil bei regionalem Ausfall
Global Jeder Load-Balancer ist auf alle Regionen verteilt.
Regional Jeder Load-Balancer ist auf mehrere Zonen in der Region verteilt. Ein Ausfall in einer bestimmten Region wirkt sich auf die regionalen Load-Balancer in dieser Region aus.

Weitere Informationen zur Auswahl eines Load-Balancers finden Sie in der Dokumentation zu Cloud Load Balancing.

Dataproc

Dataproc bietet Funktionen für Streaming- und Batch-Datenverarbeitung. Dataproc ist als regionale Steuerungsebene konzipiert, die den Nutzern die Verwaltung von Dataproc-Clustern ermöglicht. Die Steuerungsebene ist nicht von einer einzelnen Zone in einer bestimmten Region abhängig. Daher behalten Sie während eines Zonenausfalls Zugriff auf die Dataproc APIs, einschließlich der Möglichkeit, neue Cluster zu erstellen.

Cluster werden in Compute Engine ausgeführt. Da es sich bei dem Cluster um eine zonale Ressource handelt, führt ein zonaler Ausfall dazu, dass der Cluster nicht verfügbar ist oder zerstört wird. Dataproc macht keinen automatischen Snapshot des Cluster-Status, sodass ein Zonenausfall zu einem Verlust der zu verarbeitenden Daten führen könnte. Dataproc speichert Nutzerdaten innerhalb des Dienstes nicht dauerhaft. Nutzer können ihre Pipelines so konfigurieren, dass Ergebnisse in viele Datenspeicher geschrieben werden. Sie sollten die Architektur des Datenspeichers berücksichtigen und ein Produkt wählen, das die erforderliche Ausfallsicherheit bietet.

Wenn es in einer Zone zu einem Ausfall kommt, können Sie eine neue Instanz des Clusters in einer anderen Zone erstellen. Dazu können Sie entweder eine andere Zone auswählen oder die automatische Platzierung in Dataproc verwenden, um automatisch eine verfügbare Zone auszuwählen. Sobald der Cluster verfügbar ist, kann die Datenverarbeitung fortgesetzt werden. Sie können einen Cluster auch mit aktiviertem Hochverfügbarkeitsmodus ausführen, wodurch die Wahrscheinlichkeit verringert wird, dass sich ein teilweiser Zonenausfall auf einen Master-Knoten und damit auf den gesamten Cluster auswirkt.

Dataflow

Dataflow ist der vollständig verwaltete und serverlose Datenverarbeitungsdienst von Google Cloud für Streaming- und Batchpipelines. Dataflow-Jobs sind zonal. In der Standardkonfiguration werden Zwischenberechnungsergebnisse während eines zonalen Ausfalls nicht aufbewahrt. Ein typischer Wiederherstellungsansatz für solche standardmäßigen Dataflow-Pipelines ist ein Neustart von Jobs in einer anderen Zone oder Region und die erneute Verarbeitung der Eingabedaten.

Dataflow-Pipelines für Hochverfügbarkeit aufbauen

Bei einem Ausfall einer Zone oder Region können Sie Datenverluste vermeiden, indem Sie dasselbe Abo beim Pub/Sub-Thema wiederverwenden. Im Rahmen der einmaligen Garantie von Dataflow bestätigt Dataflow die Nachrichten in Pub/Sub nur dann, wenn sie am Ziel beibehalten wurden oder wenn eine Nachricht einen Gruppierungs-/Zeitfenstervorgang durchlaufen hat und im dauerhaften Pipeline-Zustand von Dataflow gespeichert wurde. Wenn keine Gruppierungs-/Zeitfenstervorgänge vorhanden sind, führt ein Failover zu einem anderen Dataflow-Job in einer anderen Zone oder Region durch die Wiederverwendung des Abos zu keinem Datenverlust in den Pipeline-Ausgabedaten.

Wenn die Pipeline Gruppierung oder Zeitfenster verwendet, können Sie die Suchfunktion der Pub/Sub- oder Wiederholungsfunktion von Kafka nach einem zonalen oder regionalen Ausfall verwenden, um Datenelemente neu zu verarbeiten, um zu den gleichen Berechnungsergebnissen zu gelangen. Der Datenverlust der Pipeline-Ausgaben kann auf bis zu null Elemente minimiert werden, wenn die von der Pipeline verwendete Geschäftslogik nicht auf Daten von vor dem Ausfall beruht. Wenn die Geschäftslogik der Pipeline auf Daten basiert, die vor dem Ausfall verarbeitet wurden (z. B. wenn lange fließende Fenster verwendet werden oder wenn in einem globalen Zeitfenster immer höhere Zählerstände gespeichert werden), bietet Dataflow eine Snapshot-Funktion (derzeit als Vorschau-Version), die eine Snapshot-Sicherung des Zustands einer Pipeline ermöglicht.

BigQuery

BigQuery ist ein serverloses, höchst skalierbares und kostengünstiges Cloud Data Warehouse, das speziell für geschäftliche Agilität konzipiert ist. BigQuery unterstützt die folgenden Standorttypen für Nutzer-Datasets:

  • Eine Region: ein bestimmter geografischer Standort, z. B. Iowa (us-central1) oder Montreal (northamerica-northeast1).
  • Mehrere Regionen: ein großes geografisches Gebiet, das zwei oder mehr geografische Orte enthält, z. B. die USA (US) oder Europa (EU).

In beiden Fällen werden die Daten redundant in zwei Zonen innerhalb des ausgewählten Standorts gespeichert. In BigQuery geschriebene Daten werden sowohl in die primäre als auch in die sekundäre Zone geschrieben. Dies hilft bei Nichtverfügbarkeit einer einzelnen Zone innerhalb der Region oder Multiregion.

Google Kubernetes Engine

Google Kubernetes Engine (GKE) bietet einen verwalteten Kubernetes-Dienst, indem die Bereitstellung containerisierter Anwendungen in Google Cloud optimiert wird. Sie können zwischen regionalen oder zonalen Cluster-Topologien wählen.

  • Beim Erstellen eines zonalen Clusters stellt GKE eine Maschine der Steuerungsebene in der ausgewählten Zone sowie Worker-Maschinen (Knoten) innerhalb derselben Zone bereit.
  • Für regionale Cluster stellt GKE drei Maschinen der Steuerungsebene in drei verschiedenen Zonen innerhalb der ausgewählten Region bereit. Standardmäßig sind Knoten über drei Zonen hinweg verteilt. Sie können aber auch einen regionalen Cluster erstellen, bei dem die Knoten nur in einer Zone bereitgestellt werden.
  • Cluster mit mehreren Zonen ähneln zonalen Clustern, da sie eine Master-Maschine enthalten, aber zusätzlich die Möglichkeit bieten, Knoten über mehrere Zonen hinweg zu verteilen.

Zonaler Ausfall: Verwenden Sie regionale Cluster, um zonale Ausfälle zu vermeiden. Die Steuerungsebene und die Knoten werden auf drei verschiedene Zonen innerhalb einer Region verteilt. Ein Zonenausfall hat keinen Einfluss auf die Steuerungsebene und Worker-Knoten, die in den anderen beiden Zonen bereitgestellt werden.

Regionaler Ausfall: Die Risikominderung eines regionalen Ausfalls erfordert die Bereitstellung in mehreren Regionen. Obwohl die multiregionale Topologie derzeit nicht als integrierte Produktfunktion angeboten wird, stellt sie einen Ansatz dar, der bereits von zahlreichen GKE-Kunden verfolgt wird und manuell implementiert werden kann. Sie können mehrere regionale Cluster erstellen, um Ihre Arbeitslasten über mehrere Regionen hinweg zu replizieren, und den Traffic zu diesen Clustern mithilfe von Multi-Cluster-Ingress steuern.

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) bietet skalierbare und hochverfügbare kryptografische Schlüsselressourcenverwaltung. Cloud KMS speichert alle Daten und Metadaten in Cloud Spanner-Datenbanken, die eine hohe Datenlanglebigkeit und -verfügbarkeit mit synchroner Replikation bieten.

Cloud KMS-Ressourcen können in einer einzelnen Region, in mehreren Regionen oder weltweit erstellt werden.

Im Falle eines Zonenausfalls verarbeitet Cloud KMS weiterhin ohne Unterbrechung Anfragen aus einer anderen Zone in derselben oder einer anderen Region. Da die Daten synchron repliziert werden, treten weder Datenverlust noch Datenschäden auf. Wenn der Zonenausfall behoben wurde, wird die vollständige Redundanz wiederhergestellt.

Bei einem regionalen Ausfall sind die regionalen Ressourcen in dieser Region offline, bis die Region wieder verfügbar ist. Beachten Sie, dass auch innerhalb einer Region mindestens drei Replikate in separaten Zonen verwaltet werden. Wenn eine höhere Verfügbarkeit erforderlich ist, sollten die Ressourcen in einer multiregionalen oder globalen Konfiguration gespeichert werden. Multiregionale und globale Konfigurationen sind so konzipiert, dass sie auch bei einem regionalen Ausfall verfügbar bleiben, indem Daten in mehr als einer Region georedundant gespeichert und bereitgestellt werden.

Cloud Identity

Cloud Identity-Dienste sind auf mehrere Regionen verteilt und verwenden dynamisches Load-Balancing. In Cloud Identity können Nutzer keinen Ressourcenbereich auswählen. Wenn eine bestimmte Zone oder Region ausfällt, wird der Traffic automatisch auf andere Zonen oder Regionen verteilt.

Nichtflüchtige Daten werden in mehreren Regionen gespiegelt, wobei in den meisten Fällen eine synchrone Replikation erfolgt. Aus Leistungsgründen werden einige wenige Systeme, wie z. B. Caches oder Änderungen, die eine große Anzahl von Entitäten betreffen, asynchron über Regionen hinweg repliziert. Wenn die primäre Region ausfällt, in der die aktuellsten Daten gespeichert sind, stellt Cloud Identity veraltete Daten von einem anderen Speicherort bereit, bis die primäre Region wieder verfügbar ist.

Persistent Disk

Persistent Disks sind in zonalen und regionalen Konfigurationen verfügbar.

Zonale Persistent Disks werden in einer einzigen Zone gehostet. Wenn die Zone der Disk nicht verfügbar ist, ist die Persistent Disk nicht verfügbar, bis der Zonenausfall behoben wurde.

Regionale Persistent Disks ermöglichen die synchrone Replikation von Daten zwischen zwei Zonen in einer Region. Bei einem Ausfall in der Zone Ihrer virtuellen Maschine können Sie erzwingen, dass eine regionale Persistent Disk an eine VM-Instanz in der sekundären Zone der Disk angehängt wird. Hierfür müssen Sie entweder eine weitere VM-Instanz in dieser Zone starten oder Sie verwalten eine VM-Instanz mit Hot-Standby in dieser Zone.

Cloud Storage

Cloud Storage bietet einen global einheitlichen, skalierbaren und höchst langlebigen Objektspeicher. Cloud Storage-Buckets können in einer einzelnen Region, in zwei Regionen oder in mehreren Regionen innerhalb eines Kontinents erstellt werden.

Wenn es bei einer Zone zu einem Ausfall kommt, werden Daten in der nicht verfügbaren Zone automatisch und transparent von einem anderen Ort in der Region bereitgestellt. Daten und Metadaten werden zonenübergreifend beginnend mit dem ersten Schreibvorgang redundant gespeichert. Wenn eine Zone nicht mehr verfügbar ist, gehen keine Schreibvorgänge verloren.

Bei einem regionalen Ausfall sind die regionalen Buckets in dieser Region offline, bis die Region wieder verfügbar ist.

Wenn eine höhere Verfügbarkeit erforderlich ist, sollten die Daten in einer Konfiguration mit zwei oder mehreren Regionen gespeichert werden. Cloud Storage verwendet Cloud Load Balancing, um Buckets mit zwei oder mehr Regionen aus verschiedenen Regionen bereitzustellen. Bei einem regionalen Ausfall wird die Bereitstellung nicht unterbrochen.

Bei Cloud Storage-Konfigurationen mit zwei oder mehr Regionen werden geschriebene Daten synchron in eine andere Zone innerhalb derselben Region und asynchron in eine andere Region oder andere Regionen repliziert. Weitere Informationen finden Sie unter Bucket-Standorte in der Cloud Storage-Dokumentation.

Während eines regionalen Ausfalls wurden Daten, die kürzlich in die betroffene Region geschrieben wurden, möglicherweise nicht in andere Regionen repliziert. Daher kann auf Daten während des Ausfalls möglicherweise nicht zugegriffen werden und sie könnten im Falle einer physischen Zerstörung der Daten in der betroffenen Region verloren gehen.

Container Registry

Die Container Registry bietet eine skalierbare, gehostete Docker Registry-Implementierung, die Docker-Container-Images sicher und privat speichert. Die Container Registry implementiert die HTTP Docker Registry API.

Die Container Registry ist ein globaler Dienst, der Image-Metadaten standardmäßig synchron und redundant über mehrere Zonen und Regionen hinweg speichert. Container-Images werden in multiregionalen Cloud Storage-Buckets gespeichert. Mit dieser Speicherstrategie bietet die Container Registry in allen Fällen eine zonale Ausfallsicherheit und eine regionale Ausfallsicherheit für alle Daten, die von Cloud Storage asynchron in mehrere Regionen repliziert wurden.

Pub/Sub

Pub/Sub ist ein Messaging-Dienst für Anwendungsintegration und Streaminganalysen. Pub/Sub-Themen sind global, d. h. sie sind von jedem Google Cloud-Standort aus sichtbar und zugänglich. Jede Nachricht wird jedoch in einer einzelnen Google Cloud-Region gespeichert, die dem Publisher am nächsten liegt und von der Richtlinie für Ressourcenstandorte zugelassen ist. Bei einem Thema können Nachrichten also in verschiedenen Regionen innerhalb von Google Cloud gespeichert sein. Die Pub/Sub-Nachrichtenspeicherrichtlinie kann die Regionen einschränken, in denen Nachrichten gespeichert werden.

Zonaler Ausfall: Wenn eine Pub/Sub-Nachricht veröffentlicht wird, wird sie synchron in mindestens zwei Zonen innerhalb der Region geschrieben. Wenn also eine einzelne Zone nicht mehr verfügbar ist, hat dies für Kunden keine sichtbaren Auswirkungen.

Regionaler Ausfall: Während eines regionalen Ausfalls sind die in der Region gespeicherten Nachrichten nicht zugänglich. Verwaltungsvorgänge wie das Erstellen und Löschen von Themen und Abos sind multiregional und ausfallsicher gegen den Ausfall einer einzelnen Google Cloud-Region. Veröffentlichungsvorgänge sind auch gegen regionale Ausfälle resistent, wenn Folgendes zutrifft:

  • mindestens eine Region, die von der Nachrichtenspeicherrichtlinie zugelassen wurde, ist verfügbar (standardmäßig schränkt Pub/Sub den Nachrichtenspeicherort nicht ein)
  • Ihre Anwendung den globalen Endpunkt (pubsub.googleapis.com) oder mehrere regionale Endpunkte verwendet und
  • der veröffentlichende Client sich nicht in der betroffenen Region befindet

Wenn Ihre Anwendung auf die Nachrichtenreihenfolge angewiesen ist, lesen Sie die detaillierten Empfehlungen vom Pub/Sub-Team. Garantien zur Nachrichtenreihenfolge werden pro Region bereitgestellt und können bei der Verwendung eines globalen Endpunkts beeinträchtigt werden.

Cloud Composer

Cloud Composer ist die verwaltete Apache Airflow-Implementierung von Google Cloud. Cloud Composer ist als regionale Steuerungsebene konzipiert, mit der Nutzer Cloud Composer-Cluster verwalten können. Die Steuerungsebene ist nicht von einer einzelnen Zone in einer bestimmten Region abhängig. Daher behalten Sie während eines Zonenausfalls Zugriff auf die Cloud Composer APIs, einschließlich der Möglichkeit, neue Cluster zu erstellen.

Cluster werden in Google Kubernetes Engine ausgeführt. Da es sich bei dem Cluster um eine zonale Ressource handelt, führt ein zonaler Ausfall dazu, dass der Cluster nicht verfügbar ist oder zerstört wird. Workflows, die zum Zeitpunkt des Ausfalls ausgeführt werden, können vor dem Abschluss beendet werden. Dies bedeutet, dass der Ausfall zu einem Zustandsverlust von teilweise ausgeführten Workflows führt, einschließlich aller externen Aktionen, für deren Ausführung der Workflow vom Nutzer konfiguriert wurde. Je nach Workflow können hierdurch Inkonsistenzen entstehen, z. B. wenn der Workflow inmitten einer mehrstufigen Ausführung zum Ändern externer Datenspeicher anhält. Daher sollten Sie beim Entwerfen Ihres Airflow-Workflows den Wiederherstellungsprozess berücksichtigen. Hierzu zählt auch, wie Sie teilweise nicht ausgeführte Workflow-Zustände erkennen, partielle Datenänderungen reparieren können und so weiter.

Während eines Zonenausfalls können Sie festlegen, dass mit Cloud Composer eine neue Instanz des Clusters in einer anderen Zone gestartet wird. Sobald der Cluster verfügbar ist, kann der Workflow fortgesetzt werden. Abhängig von Ihren Einstellungen können Sie einen inaktiven Replikatcluster in einer anderen Zone ausführen und bei einem Zonenausfall zu diesem Replikat wechseln.

Cloud SQL

Cloud SQL ist ein vollständig verwalteter relationaler Datenbankdienst für MySQL, PostgreSQL und SQL Server. Cloud SQL verwendet zum Ausführen der Datenbanksoftware verwaltete virtuelle Compute Engine-Maschinen. Der Dienst bietet eine Konfiguration für Hochverfügbarkeit für die regionale Redundanz und schützt die Datenbank vor Zonenausfällen. Regionenübergreifende Replikate können bereitgestellt werden, um die Datenbank vor dem Ausfall einer Region zu schützen. Da das Produkt auch eine zonale Option bietet, die gegenüber dem Ausfall einer Zone oder Region nicht ausfallsicher ist, sollten Sie die Hochverfügbarkeitskonfiguration, regionenübergreifende Replikate oder beide Optionen nur mit Bedacht auswählen.

Zonenausfall: Mit der Option für Hochverfügbarkeit erstellen Sie eine primäre und eine Standby-VM-Instanz in zwei separaten Zonen innerhalb einer Region. Während des normalen Betriebs verarbeitet die primäre VM-Instanz alle Anfragen und schreibt die Datenbankdateien in eine regionale Persistent Disk, die synchron in die primäre Zone und in die Standby-Zonen repliziert wird. Wenn ein Zonenausfall die primäre Instanz betrifft, initiiert Cloud SQL einen Failover, bei dem die Persistent Disk an die Standby-VM angehängt und der Traffic umgeleitet wird.

Während dieses Vorgangs muss die Datenbank initialisiert werden, was die Verarbeitung aller Transaktionen einschließt, die in das Transaktionslog geschrieben, aber nicht auf die Datenbank angewendet wurden. Die Anzahl und der Typ der nicht verarbeiteten Transaktionen können die RTO-Zeit erhöhen. Aktuellste Schreibvorgänge können zu einem Rückstau unverarbeiteter Transaktionen führen. Die RTO-Zeit wird am stärksten beeinflusst durch (a) eine hohe aktuelle Schreibaktivität und (b) kürzliche Änderungen an Datenbankschemas.

Wenn der Zonenausfall behoben wurde, können Sie manuell einen Failback-Vorgang auslösen, um die Bereitstellung in der primären Zone fortzusetzen.

Weitere Informationen zur Hochverfügbarkeit finden Sie in der Dokumentation zu Cloud SQL für Hochverfügbarkeit.

Regionaler Ausfall: Mit der Option regionenübergreifendes Replikat schützen Sie Ihre Datenbank vor regionalen Ausfällen, indem Sie Lesereplikate Ihrer primären Instanz in anderen Regionen erstellen. Bei der regionenübergreifenden Replikation wird die asynchrone Replikation verwendet. Dies ermöglicht es der primären Instanz, einen Commit für Transaktionen durchzuführen, bevor diese per Commit auf Replikate festgelegt werden. Der Zeitunterschied zwischen dem Commit einer Transaktion auf der primären Instanz und dem Commit einer Transaktion auf dem Replikat wird als "Replikationsverzögerung" bezeichnet (was per Monitoring überwacht werden kann). Bei diesem Messwert werden sowohl Transaktionen berücksichtigt, die noch nicht von der primären Instanz an Replikate gesendet wurden, als auch Transaktionen, die vom Replikat empfangen, aber noch nicht verarbeitet wurden. Transaktionen, die nicht an das Replikat gesendet wurden, sind auch bei einem regionalen Ausfall nicht verfügbar. Transaktionen, die vom Replikat empfangen, aber nicht verarbeitet wurden, wirken sich wie unten beschrieben auf die Wiederherstellungszeit aus.

Cloud SQL empfiehlt daher, Ihre Arbeitslast mit einer Konfiguration zu testen, die ein Replikat enthält, um eine Begrenzung für "sichere Transaktionen pro Sekunde (TPS)" festzulegen. Diese entspricht dem höchsten kontinuierlichen TPS-Wert, der keine Replikationsverzögerung verursacht. Wenn Ihre Arbeitslast die sichere TPS-Begrenzung überschreitet, nimmt die Replikationsverzögerung zu, was sich negativ auf die RPO- und RTO-Werte auswirkt. Als allgemeine Richtlinie sollten Sie keine kleinen Instanzkonfigurationen verwenden (d. h. weniger als 2 vCPU-Kerne, Laufwerke kleiner als 100 GB oder PD-HDD), da diese zu Replikationsverzögerungen führen können.

Bei einem regionalen Ausfall müssen Sie entscheiden, ob ein Lesereplikat manuell hochgestuft werden soll. Es handelt sich deshalb um einen manuellen Vorgang, da das Hochstufen zu einer Split-Brain-Situation führen kann, in der das hochgestufte Replikat neue Transaktionen akzeptiert, obwohl es die primäre Instanz zum Zeitpunkt des Hochstufens verzögert hat. Dies kann zu Problemen führen, wenn der regionale Ausfall behoben ist, und Sie müssen die Transaktionen abgleichen, die nie von den Primär- zu den Replikat-Instanzen weitergegeben wurden. Wenn dies für Ihre Anforderungen problematisch ist, können Sie eine regionenübergreifende synchrone Replikationsdatenbank wie Cloud Spanner in Betracht ziehen.

Sobald der Vorgang vom Nutzer ausgelöst wird, folgt die Hochstufung ähnlichen Schritten wie die Aktivierung einer Standby-Instanz in der Hochverfügbarkeitskonfiguration: Das Lesereplikat muss das Transaktionslog verarbeiten und der Load-Balancer muss den Traffic umleiten. Die Verarbeitung des Transaktionslogs bestimmt die gesamte Wiederherstellungszeit.

Weitere Informationen zur Option für regionenübergreifende Replikate finden Sie in der Dokumentation zu regionenübergreifenden Replikaten in Cloud SQL.

Cloud Logging

Cloud Logging besteht aus zwei Hauptteilen: dem Logs Router und dem Cloud Logging-Speicher.

Der Logs Router verarbeitet Streaming-Logereignisse und leitet die Logs an den Cloud Storage-, Pub/Sub-, BigQuery- oder Cloud Logging-Speicher weiter.

Der Cloud Logging-Speicher ist ein Dienst zum Speichern, Abfragen und Verwalten der Compliance für Logs. Er unterstützt viele Nutzer und Workflows, einschließlich Entwicklung, Compliance, Fehlerbehebung und proaktive Benachrichtigungen.

Logs Router und eingehende Logs: Während eines Zonenausfalls leitet die Cloud Logging API Logs an andere Zonen in der Region weiter. Normalerweise werden Logs, die vom Logs Router an Cloud Logging, BigQuery oder Pub/Sub weitergeleitet werden, so schnell wie möglich an ihren Zielort geschrieben, während an Cloud Storage gesendete Logs zwischengespeichert und stündlich in Batches geschrieben werden.

Logeinträge: Im Falle eines zonalen oder regionalen Ausfalls werden Logeinträge, die in der betroffenen Zone oder Region zwischengespeichert und nicht in das Exportziel geschrieben wurden, unzugänglich. Logbasierte Messwerte werden auch in Logs Router berechnet und unterliegen denselben Einschränkungen. Nach der Übermittlung an den ausgewählten Logexportort werden Logs gemäß dem Zieldienst repliziert. Logs, die in den Cloud Logging-Speicher exportiert werden, werden synchron über zwei Zonen in einer Region repliziert. Informationen zum Replikationsverhalten anderer Zieltypen finden Sie im entsprechenden Abschnitt in diesem Artikel. Beachten Sie, dass in Cloud Storage exportierte Logs stündlich zusammengefasst und geschrieben werden. Daher empfehlen wir die Verwendung von Cloud Logging-Speicher, BigQuery oder Pub/Sub, um die durch einen Ausfall beeinträchtigte Datenmenge zu minimieren.

Log-Metadaten: Metadaten wie Senken- und Ausschlusskonfigurationen werden global gespeichert, aber regional im Cache gespeichert, sodass bei einem Ausfall die regionalen Log Router-Instanzen funktionieren würden. Ausfälle einzelner Regionen haben keine Auswirkungen außerhalb der Region.

Cloud Spanner

Cloud Spanner ist eine skalierbare, hochverfügbare, versionsübergreifende, synchron replizierte und strikt konsistente Datenbank mit relationaler Semantik.

Regionale Cloud Spanner-Instanzen replizieren Daten synchron in drei Zonen einer Region. Ein Schreibvorgang in eine regionale Cloud Spanner-Instanz wird synchron an alle drei Replikate gesendet und dem Client nach mindestens zwei Replikaten (Mehrheitsquorum von 2 aus 3) übergeben. Dadurch wird Cloud Spanner beständig gegenüber einem Ausfall einer Zone. Dazu wird Zugriff auf alle Daten bereitgestellt, da die neuesten Schreibvorgänge beibehalten wurden und ein Mehrheitsquorum für Schreibvorgänge weiterhin mit zwei Replikaten erreicht werden kann.

Multiregionale Cloud Spanner-Instanzen enthalten ein Schreibquorum, das Daten synchron über fünf Zonen in drei Regionen repliziert (zwei Lese-/Schreibreplikate jeweils in der Standard-Leader-Region und einer anderen Region; ein Replikat in der Zeugenregion). Ein Schreibvorgang in eine multiregionale Cloud Spanner-Instanz wird bestätigt, wenn mindestens drei Replikate (Mehrheitsquorum von 3 aus 5) den Schreibvorgang festgeschrieben haben. Wenn eine Zone oder Region ausfällt, hat Cloud Spanner Zugriff auf alle Daten (einschließlich der neuesten Schreibvorgänge) und verarbeitet Lese-/Schreibanfragen, da die Daten in mindestens drei Zonen in zwei Regionen gespeichert werden, wenn der Schreibvorgang für den Client bestätigt wird.

Weitere Informationen zu diesen Konfigurationen finden Sie in der Dokumentation zu Cloud Spanner. Weitere Informationen zur Funktionsweise der Cloud Spanner-Replikation finden Sie in der Dokumentation zur Replikation.

Cloud DNS

Cloud DNS ist ein stabiles, globales Hochleistungs-Domain Name System, der Ihre Domainnamen kostengünstig im globalen DNS veröffentlicht.

Bei einem Zonenausfall verarbeitet Cloud DNS weiterhin Anfragen aus einer anderen Zone in derselben oder einer anderen Region, ohne dass eine Unterbrechung auftritt. Aktualisierungen von Cloud DNS-Einträgen werden synchron über Zonen in der Region hinweg repliziert, in der sie empfangen sind. Daher gibt es keinen Datenverlust.

Im Falle eines regionalen Ausfalls verarbeitet Cloud DNS weiterhin Anfragen aus anderen Regionen. Es ist möglich, dass sehr neue Aktualisierungen von Cloud DNS-Einträgen nicht verfügbar sind, da Aktualisierungen zuerst in einer einzelnen Region verarbeitet werden, bevor sie asynchron in andere Regionen repliziert werden.

Cloud CDN

Cloud CDN verteilt Inhalte und speichert Inhalte im Cache an vielen Standorten im Google-Netzwerk, um die Bereitstellungslatenz für Clients zu reduzieren. Im Cache gespeicherte Inhalte werden auf Best-Effort-Basis bereitgestellt. Wenn eine Anfrage nicht vom Cloud CDN-Cache verarbeitet werden kann, wird die Anfrage an Ursprungsserver wie Back-End-VMs oder Cloud Storage-Buckets weitergeleitet, wo der ursprüngliche Inhalt gespeichert ist.

Wenn eine Zone oder Region ausfällt, sind die Caches an den betroffenen Standorten nicht verfügbar. Eingehende Anfragen werden an verfügbare Google Edge-Standorte und -Caches weitergeleitet. Wenn diese alternativen Caches die Anfrage nicht verarbeiten können, leiten sie die Anfrage an einen verfügbaren Ursprungsserver weiter. Wenn der Server die Anfrage mit aktuellen Daten verarbeiten kann, kommt es zu keinem Verlust von Inhalten. Eine erhöhte Rate von Cache-Fehlern führt dazu, dass beim Ursprungsserver höhere Traffic-Volumen als normalerweise auftreten, wenn die Caches gefüllt werden. Nachfolgende Anfragen werden über die Caches verarbeitet, die nicht vom Ausfall der Zone oder Region betroffen sind.

Weitere Informationen zu Cloud CDN und zum Cache-Verhalten finden Sie in der Cloud CDN-Dokumentation.

Cloud Functions

Cloud Functions ist eine zustandslose Rechenumgebung, in der Kunden ihren Funktionscode in der Infrastruktur von Google ausführen können. Cloud Functions ist ein regionales Angebot, d. h., Kunden können die Region auswählen, nicht jedoch die Zonen, aus denen eine Region besteht. Daten und Traffic werden automatisch auf Zonen in einer Region verteilt. Funktionen werden automatisch skaliert, um eingehenden Traffic zu verarbeiten, und nach Bedarf auf verschiedene Zonen verteilt. Jede Zone hat einen Planer, der dieses Autoscaling pro Zone bereitstellt. Außerdem wird die Auslastung anderer Zonen erkannt und zusätzliche Kapazitäten innerhalb von Zonen werden bereitgestellt, um Zonenausfälle kompensieren zu können.

Zonaler Ausfall: Cloud Functions speichert Metadaten sowie die bereitgestellte Funktion. Diese Daten werden regional gespeichert und synchron geschrieben. Die Cloud Functions Admin API gibt den API-Aufruf erst zurück, wenn die Daten an ein Quorum innerhalb einer Region übertragen wurden. Da die Daten regional gespeichert sind, sind die Vorgänge der Datenebene ebenfalls nicht von zonalen Ausfällen betroffen. Der Traffic wird bei einem Zonenausfall automatisch an andere Zonen weitergeleitet.

Regionaler Ausfall: Kunden wählen die Google Cloud-Region aus, in der sie ihre Funktion erstellen möchten. Daten werden nie über Regionen hinweg repliziert. Kunden-Traffic wird von Cloud Functions nie an eine andere Region weitergeleitet. Bei einem regionalen Ausfall wird Cloud Functions wieder verfügbar, sobald der Ausfall behoben ist. Kunden wird empfohlen, sie in mehreren Regionen bereitzustellen und Cloud Load Balancing zu verwenden, um bei Bedarf eine höhere Verfügbarkeit zu erreichen.

Cloud Run

Cloud Run ist eine zustandslose Rechenumgebung, in der Kunden ihren containerisierten Code in der Infrastruktur von Google ausführen können. Cloud Run ist ein regionales Angebot, d. h., Kunden können die Region auswählen, nicht jedoch die Zonen, aus denen eine Region besteht. Daten und Traffic werden automatisch auf Zonen in einer Region verteilt. Containerinstanzen werden automatisch skaliert, um eingehenden Traffic zu verarbeiten, und werden nach Bedarf auf die Zonen verteilt. Jede Zone hat einen Planer, der dieses Autoscaling pro Zone bereitstellt. Außerdem wird die Auslastung anderer Zonen erkannt und zusätzliche Kapazitäten innerhalb von Zonen werden bereitgestellt, um Zonenausfälle kompensieren zu können.

Zonaler Ausfall: Cloud Run speichert Metadaten sowie den bereitgestellten Container. Diese Daten werden regional gespeichert und synchron geschrieben. Die Cloud Run Admin API gibt den API-Aufruf erst zurück, wenn die Daten an ein Quorum innerhalb einer Region übertragen wurden. Da die Daten regional gespeichert sind, sind die Vorgänge der Datenebene ebenfalls nicht von zonalen Ausfällen betroffen. Der Traffic wird bei einem Zonenausfall automatisch an andere Zonen weitergeleitet.

Regionaler Ausfall: Kunden wählen die Google Cloud-Region aus, in der sie ihren Cloud Run-Dienst erstellen möchten. Daten werden nie über Regionen hinweg repliziert. Kunden-Traffic wird von Cloud Run nie an eine andere Region weitergeleitet. Bei einem regionalen Ausfall wird Cloud Run wieder verfügbar, sobald der Ausfall behoben ist. Kunden wird empfohlen, sie in mehreren Regionen bereitzustellen und Cloud Load Balancing zu verwenden, um bei Bedarf eine höhere Verfügbarkeit zu erreichen.

HA VPN

HA VPN (Hochverfügbarkeit) ist ein stabiles Cloud VPN-Angebot, mit dem Sie Ihren Traffic von Ihrer lokalen privaten Cloud, einer anderen Virtual Private Cloud oder einem anderen Netzwerk des Cloud-Dienstanbieters sicher mit Google Cloud Virtual Private Cloud (VPC) verschlüsseln können.

Gateways von HA VPN haben zwei Schnittstellen, die jeweils eine IP-Adresse aus separaten IP-Adresspools haben, die sowohl logisch als auch physisch über verschiedene PoPs und Cluster verteilt sind, um eine optimale Redundanz zu gewährleisten.

Zonaler Ausfall: Bei einem zonalen Ausfall kann eine Schnittstelle die Verbindung verlieren, der Traffic wird jedoch über dynamisches Routing mit dem Border Gateway Protocol (BGP) an die andere Schnittstelle weitergeleitet.

Regionaler Ausfall: Bei einem regionalen Ausfall kann die Verbindung zwischen beiden Schnittstellen für kurze Zeit unterbrochen werden.

Cloud NAT

Cloud NAT (Netzwerkadressübersetzung) ist ein verteilter, softwarebasierter verwalteter Dienst, der bestimmten Ressourcen ohne externe IP-Adressen ausgehende Verbindungen zum Internet ermöglicht. Cloud NAT basiert nicht auf Proxy-VMs oder -Appliances. Cloud NAT konfiguriert stattdessen die Andromeda-Software, die Ihr VPC-Netzwerk unterstützt, um SNAT (Source Network Address Translation) oder NAT (Network Address Translation) für VMs ohne externe IP-Adressen zu ermöglichen. Cloud NAT bietet auch Destination Network Address Translation (Ziel-NAT oder DNAT) für etablierte eingehende Antwortpakete.

Weitere Informationen zur Funktionalität von Cloud NAT finden Sie in der Dokumentation.

Zonaler Ausfall: Cloud NAT ist zonalen Ausfällen standhalten, da die Steuerungsebene und die Netzwerkdatenebene in mehreren Zonen innerhalb einer Region redundant sind.

Regionaler Ausfall: Cloud NAT ist ein regionales Produkt und kann daher einem regionalen Ausfall nicht standhalten.

Cloud Load Balancing

Google Cloud Load Balancing ist ein regionaler Pass-Through-Load-Balancer, der den Traffic zwischen VM-Instanzen in derselben Region ausgleicht.

  • Der interne TCP/UDP-Load-Balancer und der interne HTTP(S)-Load-Balancer verteilen den internen TCP-, UDP- und HTTP(S)-Traffic.

  • Der externe HTTP(S)-Load-Balancer verteilt den externen TCP-, UDP-, ICMP- und ESP-Traffic. Unterstützung für ESP und ICMP befindet sich in der Vorschau.

Bei einem Zonenausfall verteilt Cloud Load Balancing weiterhin neue Verbindungen auf Back-End-Instanzen in anderen verfügbaren Zonen. Vorhandene Verbindungen zu VM-Instanzen in der fehlgeschlagenen Zone werden gemäß der benutzerdefinierten Richtlinie für das Verbindungs-Tracking per Drain beendet. Mit dieser Richtlinie wird sichergestellt, dass Verbindungen zu fehlerhaften Back-Ends und Verbindungsausgleichskonfigurationen nicht erhalten bleiben.

Da Cloud Load Balancing ein regionales Produkt ist, ist es nicht anfällig für regionale Ausfälle.

Cloud Interconnect

Cloud Interconnect bietet Kunden über RFC 1918 Zugriff auf Google Cloud-Netzwerke von ihren lokalen Rechenzentren über physische Kabel, die mit Google Peering Edge verbunden sind.

Cloud Interconnect bietet Kunden ein SLA von 99,9 %, wenn sie Verbindungen zu zwei EADs (Edge Availability Domains) in einer Metropolregion bereitstellen. Ein SLA von 99,99 % ist verfügbar, wenn der Kunde mit globalem Routing Verbindungen in zwei EADs in zwei Metropolregionen in zwei Regionen bereitstellt. Weitere Informationen finden Sie unter Topologie für nicht kritische Anwendungen im Überblick und Topologie für Anwendungen auf Produktionsebene.

Cloud Interconnect ist unabhängig von der Computing-Zone und bietet Hochverfügbarkeit in Form von EADs. Bei einem EAD-Fehler wird die BGP-Sitzung für diese EAD unterbrochen und der Traffic wird zur anderen EAD geleitet.

Bei einem regionalen Ausfall werden die BGP-Sitzungen in dieser Region unterbrochen und der Traffic auf die Ressourcen in der Arbeitsregion übertragen. Dies gilt, wenn das globale Routing aktiviert ist.

Secret Manager

Secret Manager ist ein Produkt für die Verwaltung von Secrets und Anmeldedaten für Google Cloud. Mit Secret Manager können Sie den Zugriff auf Secrets einfach prüfen und einschränken, Secrets im Ruhezustand verschlüsseln und dafür sorgen, dass vertrauliche Informationen in Google Cloud gesichert sind.

Secret Manager-Ressourcen werden normalerweise mit der automatischen Replikationsrichtlinie erstellt (empfohlen), wodurch sie global repliziert werden. Wenn Ihre Organisation Richtlinien hat, die eine globale Replikation von Secret-Daten nicht zulassen, können Secret Manager-Ressourcen mit nutzerverwalteten Replikationsrichtlinien erstellt werden, in denen eine oder mehrere Regionen als Replikationsziel für ein Secret ausgewählt werden.

Zonenausfall: Bei einem Zonenausfall verarbeitet Secret Manager weiterhin Anfragen aus einer anderen Zone in derselben oder einer anderen Region ohne Unterbrechung. In jeder Region verwaltet Secret Manager immer mindestens zwei Replikate in separaten Zonen (in den meisten Regionen drei Replikate). Wenn der Zonenausfall behoben wurde, wird die vollständige Redundanz wiederhergestellt.

Regionaler Ausfall: Bei einem regionalen Ausfall verarbeitet Secret Manager weiterhin Anfragen aus einer anderen Region ohne Unterbrechung, vorausgesetzt, die Daten wurden in mehrere Regionen repliziert (entweder durch automatische Replikation oder durch eine vom Nutzer verwaltete Replikation in mehr als einer Region). Wenn der regionale Ausfall behoben wurde, wird die vollständige Redundanz wiederhergestellt.

Cloud Healthcare API

Die Cloud Healthcare API, ein Dienst zum Speichern und Verwalten von Gesundheitsdaten, bietet Hochverfügbarkeit und bietet Schutz vor zonalen und regionalen Ausfällen, je nach ausgewählter Konfiguration.

Regionale Konfiguration: Die Cloud Healthcare API bietet in der Standardkonfiguration Schutz vor Zonenausfällen. Der Dienst wird in drei Zonen einer Region bereitgestellt, wobei die Daten dreifach in verschiedene Zonen innerhalb der Region gespeichert werden. Bei einem Zonenausfall, der sich entweder auf die Dienstebene oder auf die Datenebene auswirkt, übernehmen die verbleibenden Zonen ohne Unterbrechung. Die einzige Ausnahme ist die Suchfunktion, bei der eine kleine Datenmenge, die wenige Minuten vor dem zonalen Ausfall indexiert wurde, in Search l (zugrunde liegende Daten, die als „Source of Truth“ verwendet werden) möglicherweise nicht verfügbar ist. Wenn bei einer regionalen Konfiguration eine ganze Region ausfällt, in der sich der Dienst befindet, ist der Dienst erst wieder verfügbar, wenn die Region wieder online ist. Im unvorhergesehenen Fall einer physischen Zerstörung einer ganzen Region gehen die in dieser Region gespeicherten Daten verloren.

Multiregionale Konfiguration: In der multiregionalen Konfiguration wird die Cloud Healthcare API in drei Zonen bereitgestellt, die zu drei verschiedenen Regionen gehören. Außerdem werden Daten in drei Regionen repliziert. Dies schützt vor Dienstverlust bei einem Ausfall der gesamten Region, da die verbleibenden Regionen automatisch übernehmen würden (es gilt die gleiche Ausnahme für die Suchfunktionalität wie bei der regionalen Konfiguration). Strukturierte Daten wie FHIR werden zwar synchron über mehrere Regionen hinweg repliziert und sind daher bei einem Ausfall der gesamten Region vor Datenverlust geschützt, jedoch werden in Google Storage-Buckets gespeicherte Daten wie DICOM- und Dictation- oder große HL7v2/FHIR-Objekte asynchron über mehrere Regionen hinweg repliziert. Dies bedeutet, dass bei einer physischen Zerstörung einer Region einige Daten verloren gehen, die in den letzten 48 Stunden geschrieben wurden.

Cloud Bigtable

Cloud Bigtable ist ein vollständig verwalteter, leistungsstarker NoSQL-Datenbankdienst für große analytische und operative Arbeitslasten.

Bigtable-Replikation – Übersicht

Bigtable bietet ein flexibles und vollständig konfigurierbares Replikationsfeature, mit dem Sie die Verfügbarkeit und Langlebigkeit Ihrer Daten erhöhen können. Dazu kopieren Sie sie in Cluster in mehreren Regionen oder mehrere Zonen innerhalb derselben Region. Bigtable kann auch automatischen Failover für Ihre Anfragen bereitstellen, wenn Sie die Replikation verwenden.

Wenn Sie multizonale oder multiregionale Konfigurationen mit Multi-Cluster-Routing verwenden, leitet Bigtable bei einem zonalen oder regionalen Ausfall automatisch den Traffic um und verarbeitet Anfragen vom nächstgelegenen verfügbaren Cluster Da Bigtable-Replikation asynchron ist und Eventual Consistency bietet, können sehr aktuelle Änderungen an Daten am Standort des Ausfalls nicht verfügbar sein, wenn sie noch nicht an andere Standorte repliziert wurden.

Hinweise zur Leistung

Wenn die Anforderungen für CPU-Ressourcen die verfügbare Knotenkapazität überschreiten, priorisiert Bigtable immer die Verarbeitung eingehender Anfragen gegenüber Replikationstraffic.

Weitere Informationen zur Verwendung der Bigtable-Replikation mit Ihrer Arbeitslast finden Sie unter Cloud Bigtable-Replikation – Übersicht und Beispiele für Replikationseinstellungen.

Bigtable-Knoten werden sowohl für die Verarbeitung eingehender Anfragen als auch für die Replikation von Daten aus anderen Clustern verwendet. Sie müssen nicht nur genügend Knoten pro Cluster verwalten, sondern auch dafür sorgen, dass Ihre Anwendungen das richtige Schemadesign verwenden, um Hotspots zu vermeiden. Hotspots können zu einer übermäßigen oder unausgeglichenen CPU-Nutzung und einer höheren Replikationslatenz führen.

Weitere Informationen zum Entwerfen Ihres Anwendungsschemas, um die Leistung und Effizienz von Bigtable zu maximieren, finden Sie unter Best Practices für das Schemadesign.

Monitoring

Cloud Bigtable bietet mehrere Möglichkeiten, die Replikationslatenz Ihrer Instanzen und Cluster mithilfe der in der Google Cloud Console verfügbaren Diagramme zur Replikation visuell zu überwachen.

Außerdem können Sie mit der Cloud Monitoring API die Messwerte der Bigtable-Replikation programmatisch überwachen.