Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur

Dieser Artikel ist der sechste Teil einer Reihe, in der die Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloud behandelt wird. 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.

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 4 Std.

RPO 1 Std.

Stufe 2 35 % In der Regel regionale Anwendungen oder wichtige interne Anwendungen wie CRM oder ERP. RTO 4 Std.

RPO Null

RTO 24 Std.

RPO 4 Std.

Stufe 3

(am wenigsten wichtig)

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

RPO 24 Std.

RTO 28 Tage

RPO 24 Std.

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 Ja Ja Ja
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 (Beta) 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 zwei verschiedene verfügbarkeitsbezogene Konfigurationsoptionen für Nutzer-Datasets.

Konfiguration für eine Region

In einer Konfiguration für eine Region werden Daten redundant in zwei Zonen innerhalb einer Region gespeichert. In BigQuery geschriebene Daten werden zuerst in die primäre Zone geschrieben und dann asynchron in eine sekundäre Zone repliziert. Dies schützt vor Nichtverfügbarkeit einer einzelnen Zone innerhalb der Region. Daten, die in die primäre Zone geschrieben, aber zum Zeitpunkt eines Zonenausfalls nicht in die sekundäre Zone repliziert wurden, sind bis zum Beheben des Ausfalls nicht verfügbar. In dem unwahrscheinlichen Fall, dass eine Zone zerstört wird, können diese Daten dauerhaft verloren gehen.

Multiregionale Konfiguration (USA/EU)

Ähnlich wie bei der Konfiguration für eine einzelne Region werden Daten in der multiregionalen Konfiguration (USA/EU) redundant in zwei Zonen innerhalb einer Region gespeichert. Außerdem hält BigQuery eine zusätzliche Sicherungskopie der Daten in einer zweiten Region vor. Wenn in der primären Region ein Ausfall auftritt, werden Daten aus der sekundären Region bereitgestellt. Daten, die noch nicht repliziert wurden, sind erst wieder verfügbar, wenn die primäre Region wiederhergestellt wurde.


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 mehreren Regionen werden geschriebene Daten synchron in eine andere Zone innerhalb derselben Region und asynchron in eine andere Region oder Regionen repliziert. Siehe Georedundanz 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 betreffenden 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.

Regionsausfall: 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 anderen Zonen in derselben oder einer anderen Region, ohne dass eine Unterbrechung auftritt. Aktualisierungen von Cloud DNS-Einträgen werden synchron über Zonen in der Region repliziert, in der sie empfangen werden. Daher gibt es keinen Datenverlust.

Im Falle eines regionalen Ausfalls verarbeitet Cloud DNS weiterhin Anfragen aus anderen Regionen. Es ist möglich, dass die jüngsten 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 und speichert Inhalte auf viele Standorte im Google-Netzwerk, um die Bereitstellungslatenz für Clients zu reduzieren. Im Cache gespeicherte Inhalte werden auf Best-Effort-Basis bereitgestellt. Kann eine Anfrage nicht vom Cloud CDN-Cache verarbeitet werden, wird die Anfrage an die den Originalinhalt speichernden Ursprungsserver, beispielsweise ein Back-End-VM oder ein Cloud Storage-Bucket, weitergeleitet.

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 höhere Rate an Cache-Fehlern führt dazu, dass die Ursprungsserver höhere Volumen als das normale Traffic-Volumen verursachen, wenn die Caches gefüllt werden. Nachfolgende Anfragen werden aus den Caches bereitgestellt, die nicht vom Ausfall der Zone oder Region betroffen sind.

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