Google Cloud-Infrastrukturdienste werden an verschiedenen Standorten weltweit ausgeführt. Die Standorte sind in fehlerhafte Domains unterteilt, die als Regionen und Zonen bezeichnet werden. Dies sind die Grundbausteine für das Entwerfen einer zuverlässigen Infrastruktur für Ihre Cloudarbeitslasten.
Eine fehlerhafte Domain ist eine Ressource oder eine Gruppe von Ressourcen, die unabhängig von anderen Ressourcen ausfallen können. Eine eigenständige Compute Engine-VM ist ein Beispiel für eine Ressource, die eine fehlerhafte Domain ist. Eine Google Cloud-Region oder -Zone ist ein Beispiel für eine fehlerhafte Domain, die aus einer Gruppe von Ressourcen besteht. Wenn eine Anwendung redundant auf fehlerhafte Domains verteilt wird, kann sie eine höhere aggregierte Verfügbarkeit erreichen als von jeder fehlerhaften Domain.
In diesem Teil des Leitfadens zur Zuverlässigkeit der Google Cloud-Infrastruktur werden die Bausteine der Zuverlässigkeit in Google Cloud und deren Auswirkungen auf die Verfügbarkeit Ihrer Cloud-Ressourcen beschrieben.
Regionen und Zonen
Google Cloud-Regionen sind unabhängige geografische Standorte. Jede Google Cloud-Region enthält mehrere Zonen. Ein Ausfall in einer Zone wirkt sich wahrscheinlich nicht auf die Infrastruktur in den anderen Zonen aus. Ein globales Netzwerk-Backbone bietet eine Verbindung mit hoher Bandbreite und niedriger Latenz über alle Zonen und Regionen von Google Cloud hinweg.
Plattformverfügbarkeit
Die Google Cloud-Infrastruktur ist auf Fehlertoleranz und Wiederherstellung nach Fehlern ausgelegt. Google investiert kontinuierlich in innovative Ansätze, um die Zuverlässigkeit von Google Cloud zu erhalten und zu verbessern. Die folgenden Funktionen der Google Cloud-Infrastruktur bieten eine zuverlässige Plattform für Ihre Cloudarbeitslasten:
- Geografische getrennte Regionen, um die Auswirkungen von Naturkatastrophen und Regionsausfällen auf globale Dienste zu minimieren.
- Hardwareredundanz und -replikation, um Single Points of Failure zu vermeiden.
- Live-Migration von Ressourcen bei Wartungsereignissen Beispielsweise können Compute Engine-VMs während einer geplanten Infrastrukturwartung mithilfe der Live-Migration auf einen anderen Host in derselben Zone verschoben werden.
- Von Grund auf sichere Infrastrukturbasis für die physische Infrastruktur und Software, auf der Google Cloud ausgeführt wird, sowie operative Sicherheitskontrollen zum Schutz Ihrer Daten und Arbeitslasten. Weitere Informationen finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.
- Ein Hochleistungs-Backbonenetzwerk, das einen erweiterten softwarebasierten Netzwerkansatz (SDN) für die Netzwerkverwaltung verwendet, mit Edge-Caching-Diensten, um eine konsistente, gut skalierbare Leistung zu bieten.
- Kontinuierliche Monitorings und Berichte Sie können den Status der Google Cloud-Dienste an jedem Standort über das Google Cloud Service Health Dashboard aufrufen.
- Jährliche, unternehmensweite Ereignisse der Notfallwiederherstellung (Disaster Recovery Testing, DiRT), damit Google Cloud-Dienste und interne Geschäftsvorgänge während eines Notfalls weiterhin ausgeführt werden.
Die Google Cloud-Infrastruktur unterstützt die folgenden Zielverfügbarkeitsstufen für die meisten Kundenarbeitslasten:
| Bereitstellungsort | Verfügbarkeit (Uptime) % | Geschätzte maximale Ausfallzeit |
|---|---|---|
| Einzelne Zone | 3 Neunen: 99,9% | 43,2 Minuten in einem Monat mit 30 Tagen |
| Mehrere Zonen in einer Region | 4 Neunen: 99,99% | 4,3 Minuten in einem Monat mit 30 Tagen |
| Mehrere Regionen | 5 Neunen: 99,999% | 26 Sekunden in einem Monat mit 30 Tagen |
Die Verfügbarkeitsprozentsätze in der vorherigen Tabelle sind Ziele. Die Service Level Agreements (SLAs) zur Verfügbarkeit bestimmter Google Cloud-Dienste können von diesen Verfügbarkeitszielen abweichen. Das Verfügbarkeits-SLA für eine Bigtable-Instanz hängt beispielsweise von der Anzahl der Cluster und deren Verteilung auf Standorte ab sowie von der Routingrichtlinie, die Sie konfigurieren.
Das SLA zur Mindestverfügbarkeit für eine Bigtable-Instanz mit Clustern in drei oder mehr Regionen beträgt 99,999 %, wenn die Multi-Cluster-Routingrichtlinie konfiguriert ist. Wenn die Routingrichtlinie für einzelne Cluster konfiguriert ist, beträgt das SLA für Mindestverfügbarkeit jedoch 99,9%, unabhängig von der Anzahl der Cluster und deren Verteilung.
Die Diagramme in diesem Abschnitt zeigen Bigtable-Instanzen mit unterschiedlichen Clustergrößen und die sich daraus ergebenden Unterschiede in den Verfügbarkeits-SLAs.
Einzelner Cluster
Das folgende Diagramm zeigt eine Bigtable-Instanz mit einem einzigen Cluster mit einem SLA mit einer Mindestverfügbarkeit von 99,9%:
Mehrere Cluster
Das folgende Diagramm zeigt eine Multi-Cluster-Bigtable-Instanz in mehreren Zonen innerhalb einer Region mit Multi-Cluster-Routing (Mindestverfügbarkeit SLA: 99,99%):
Mehrere Cluster
Das folgende Diagramm zeigt eine Bigtable-Instanz mit mehreren Clustern in drei Regionen mit Multi-Cluster-Routing (Mindestverfügbarkeits-SLA: 99,999%):
Aggregierte Infrastrukturverfügbarkeit
Zum Ausführen Ihrer Anwendungen in Google Cloud verwenden Sie Infrastrukturressourcen wie VMs und Datenbanken. Diese Infrastrukturressourcen bilden zusammen den Infrastruktur-Stack Ihrer Anwendung.
Das folgende Diagramm zeigt ein Beispiel für einen Infrastruktur-Stack in Google Cloud und das SLA zur Verfügbarkeit pro Ressource im Stack:
Dieser Beispiel-Infrastruktur-Stack enthält die folgenden Google Cloud-Ressourcen:
- Ein regionaler externer Anwendungs-Load-Balancer empfängt und antwortet auf Nutzeranfragen.
- Eine regionale verwaltete Instanzgruppe (MIG) ist das Backend für den regionalen externen Anwendungs-Load-Balancer. Die MIG enthält zwei Compute Engine-VMs in verschiedenen Zonen. Jede VM hostet eine Instanz eines Webservers.
- Ein interner Load-Balancer übernimmt die Kommunikation zwischen dem Webserver und den Anwendungsserverinstanzen.
- Eine zweite regionale MIG ist das Backend für den internen Load-Balancer. Diese MIG hat zwei Compute Engine-VMs in verschiedenen Zonen. Jede VM hostet eine Instanz eines Anwendungsservers.
- Eine Cloud SQL-Instanz, die für hohe Verfügbarkeit konfiguriert ist, ist die Datenbank für die Anwendung. Die primäre Datenbankinstanz wird synchron in eine Standby-Datenbankinstanz repliziert.
Die aggregierte Verfügbarkeit, die Sie von einem Infrastruktur-Stack wie im vorherigen Beispiel erwarten können, hängt von den folgenden Faktoren ab:
Google Cloud-SLAs
Die SLAs der Google Cloud-Dienste, die Sie in Ihrem Infrastrukturpaket verwenden, wirken sich auf die Mindestverfügbarkeit aus, die Sie vom Stack erwarten können.
In den folgenden Tabellen werden die SLAs für einige Betriebszeiten für einige Dienste verglichen:
| Computing-Dienste | SLA für monatliche Betriebszeit | Geschätzte maximale Ausfallzeit in einem 30-Tage-Monat |
|---|---|---|
| Compute Engine-VM | 99,9 % | 43,2 Minuten |
| GKE Autopilot-Pods in mehreren Zonen | 99,9 % | 43,2 Minuten |
| Cloud Run-Dienst | 99,95 % | 21,6 Minuten |
| Datenbankdienste | SLA für monatliche Betriebszeit | Geschätzte maximale Ausfallzeit in einem 30-Tage-Monat |
|---|---|---|
| Cloud SQL for PostgreSQL-Instanz (Enterprise Edition) | 99,95 % | 21,6 Minuten |
| AlloyDB for PostgreSQL-Instanz | 99,99 % | 4,3 Minuten |
| Multiregionale Spanner-Instanz | 99,999 % | 26 Sekunden |
Die SLAs anderer Google Cloud-Dienste finden Sie unter Google Cloud Service Level Agreements.
Wie die vorherigen Tabellen zeigen, wirken sich die Google Cloud-Dienste, die Sie für jede Ebene Ihres Infrastruktur-Stacks auswählen, direkt auf die Gesamtlaufzeit aus, die Sie vom Infrastruktur-Stack erwarten können. Um die erwartete Verfügbarkeit einer Arbeitslast zu erhöhen, können Sie auf der Google Cloud-Ressource redundante Instanzen der Ressource bereitstellen, wie im nächsten Abschnitt beschrieben.
Ressourcenredundanz
Ressourcenredundanz bedeutet, dass zwei oder mehr identische Instanzen einer Ressource bereitgestellt und dieselbe Arbeitslast für alle Ressourcen in der Gruppe bereitgestellt wird. Wenn Sie beispielsweise die Webebene einer Anwendung hosten möchten, können Sie eine MIG mit mehreren identischen Compute Engine-VMs bereitstellen.
Wenn Sie eine Gruppe von Ressourcen redundant auf mehrere fehlerhafte Domains verteilen, z. B. zwei Google Cloud-Zonen, ist die Ressourcenverfügbarkeit, die Sie von dieser Gruppe erwarten können, höher als das SLA für die Verfügbarkeit jeder Ressource in der Gruppe. Diese höhere Verfügbarkeit ist darauf zurückzuführen, dass die Wahrscheinlichkeit, dass alle Ressourcen in der Gruppe gleichzeitig fehlschlagen, geringer ist als die Wahrscheinlichkeit, dass Ressourcen in einer einzelnen fehlerhaften Domain einen koordinierten Ausfall haben.
Wenn das Verfügbarkeits-SLA für eine Ressource beispielsweise 99,9 % beträgt, beträgt die Wahrscheinlichkeit, dass die Ressource fehlschlägt, 0,001 (1 minus das SLA). Wenn Sie eine Arbeitslast auf zwei Instanzen dieser Ressource verteilen, die in separaten Fehlerdomains bereitgestellt werden, beträgt die Wahrscheinlichkeit, dass beide Ressourcen gleichzeitig fehlschlagen, 0,000001 (d. h. 0,001 x 0,001). Diese Fehlerwahrscheinlichkeit entspricht einer theoretischen Verfügbarkeit von 99,9999 % für die Gruppe von zwei Ressourcen. Die tatsächliche erwartete Verfügbarkeit ist jedoch auf die Zielverfügbarkeit des Bereitstellungsstandorts beschränkt: 99,9 %, wenn sich die Ressourcen in einer einzelnen Google Cloud-Zone befinden. 99,99 % für eine Bereitstellung in mehreren Zonen und 99,999 %, wenn die redundanten Ressourcen auf mehrere Regionen verteilt sind.
Stacktiefe
Die Tiefe eines Infrastruktur-Stacks ist die Anzahl verschiedener Stufen (oder Ebenen) im Stack. Jede Stufe in einem Infrastruktur-Stack enthält Ressourcen, die eine eigene Funktion für die Anwendung bereitstellen. Die Mittelstufe in einem dreistufigen Stack kann beispielsweise Compute Engine-VMs oder einen GKE-Cluster zum Hosten von Anwendungsservern verwenden. Jede Stufe in einem Infrastruktur-Stack hat normalerweise eine enge Abhängigkeit von den zugehörigen Ebenen. Das bedeutet, dass der gesamte Stack nicht mehr verfügbar ist, wenn keine Stufe des Stacks verfügbar ist.
Sie können die erwartete aggregierte Verfügbarkeit eines n-stufigen Infrastruktur-Stacks mit der folgenden Formel berechnen:
Wenn beispielsweise jede Stufe in einem dreistufigen Stack für eine Verfügbarkeit von 99,9 % vorgesehen ist, beträgt die aggregierte Verfügbarkeit des Stacks etwa 99,7 % (0,999 x 0,999 x 0,999). Das bedeutet, dass die Gesamtverfügbarkeit eines mehrstufigen Stacks geringer ist als die Verfügbarkeit der Stufe, die die geringste Verfügbarkeit bietet.
Wenn die Anzahl der voneinander abhängigen Stufen in einem Stack zunimmt, nimmt die Verfügbarkeit des Stacks ab, wie in der folgenden Tabelle dargestellt. Jeder Beispiel-Stack in der Tabelle hat eine andere Anzahl von Ebenen. Für einen einfachen Vergleich wird vorausgesetzt, dass jede Stufe eine Verfügbarkeit von 99,9 % bietet.
| Stufe | Stack A | Stack B | Stack C |
|---|---|---|---|
| Frontend | 99,9 % | 99,9 % | 99,9 % |
| Anwendungsstufe | 99,9 % | 99,9 % | 99,9 % |
| Mittelstufe | – | 99,9 % | 99,9 % |
| Datenstufe | – | – | 99,9 % |
| Aggregatverfügbarkeit des Stacks | 99,8 % | 99,7 % | 99,6 % |
| Geschätzte maximale Ausfallzeit des Stacks in einem Monat von 30 Tagen | 86 Minuten | 130 Minuten | 173 Minuten |
Zusammenfassung der Überlegungen zum Design
Berücksichtigen Sie beim Entwerfen Ihrer Anwendungen die aggregierte Verfügbarkeit des Google Cloud-Infrastruktur-Stacks.
- Die Verfügbarkeit jeder Google Cloud-Ressource in Ihrem Infrastruktur-Stack wirkt sich auf die Gesamtverfügbarkeit des Stacks aus. Berücksichtigen Sie bei der Auswahl von Google Cloud-Diensten zum Erstellen Ihres Infrastruktur-Stacks das Verfügbarkeits-SLA der Dienste.
- Um die Verfügbarkeit der Funktion (z. B. Computing oder Datenbank) zu verbessern, können Sie redundante Instanzen der Ressource bereitstellen. Wenn Sie eine Architektur mit redundanten Ressourcen entwerfen, müssen Sie neben den Verfügbarkeitsvorteilen auch die potenziellen Auswirkungen auf die betriebliche Komplexität, Latenz und Kosten berücksichtigen.
- Die Anzahl der Ebenen in einem Infrastrukturstack (d. h. die Tiefe des Stacks) hat eine umgekehrte Beziehung zur aggregierten Verfügbarkeit des Stacks. Berücksichtigen Sie diese Beziehung, wenn Sie Ihren Stack entwerfen oder ändern.
Beispiele für Berechnungen der aggregierten Verfügbarkeit finden Sie in den folgenden Abschnitten:
- Beispielberechnung: Bereitstellung in einer einzelnen Zone
- Beispielberechnung: Bereitstellung in mehreren Zonen
- Beispielberechnung: Multiregionale Bereitstellung mit regionalem Load-Balancing
- Beispielberechnung: Multiregionale Bereitstellung mit globalem Load-Balancing
Standortbereiche
Der Standortbereich einer Google Cloud-Ressource bestimmt, inwiefern sich ein Infrastrukturausfall auf die Ressource auswirken kann. Die meisten Ressourcen, die Sie in Google Cloud bereitstellen, haben einen der folgenden Standortbereiche: zonal, regional, multiregional oder global.
Der Standortbereich einiger Ressourcentypen ist fest vorgegeben. Das heißt, Sie können den Standortbereich nicht auswählen oder ändern. VPC-Netzwerke (Virtual Private Cloud) sind beispielsweise globale Ressourcen und virtuelle Maschinen (VMs) von Compute Engine sind zonale Ressourcen. Bei bestimmten Ressourcen können Sie den Standortbereich auswählen, während Sie die Ressource bereitstellen. Wenn Sie beispielsweise einen GKE-Cluster (Google Kubernetes Engine) erstellen, können Sie einen zonalen oder regionalen GKE-Cluster erstellen.
In den folgenden Abschnitten werden Standortbereiche ausführlicher beschrieben.
Zonale Ressourcen
Zonale Ressourcen werden innerhalb einer einzelnen Zone in einer Google Cloud-Region bereitgestellt. Im Folgenden finden Sie Beispiele für zonale Ressourcen. Diese Liste ist nicht vollständig.
- Compute Engine-VMs
- Zonal verwaltete Instanzgruppen (MIGs)
- Zonale nichtflüchtige Speicher
- GKE-Cluster in einer Zone
- Filestore-Basis- und zonale Instanzen
- Dataflow-Jobs
- Cloud SQL-Instanzen
- Dataproc-Cluster in Compute Engine
Ein Ausfall in einer Zone kann sich auf die zonalen Ressourcen auswirken, die innerhalb dieser Zone bereitgestellt werden. Zonen sind so konzipiert, dass das Risiko gleichzeitiger Fehler mit anderen Zonen in der Region minimiert wird. Ein Ausfall in einer Zone wirkt sich normalerweise nicht auf die Ressourcen in den anderen Zonen in der Region aus. Außerdem führt ein Fehler in einer Zone nicht unbedingt dazu, dass die gesamte Infrastruktur in dieser Zone nicht verfügbar ist. Die Zone definiert lediglich die erwartete Grenze für die Auswirkungen eines Fehlers.
Zum Schutz von Anwendungen, die zonale Ressourcen verwenden, können Sie die Ressourcen auf mehrere Zonen oder Regionen verteilen oder replizieren. Weitere Informationen finden Sie unter Zuverlässige Infrastruktur für Ihre Arbeitslasten in Google Cloud entwerfen.
Regionale Ressourcen
Regionale Ressourcen werden redundant in mehreren Zonen innerhalb einer Region bereitgestellt. Im Folgenden finden Sie Beispiele für regionale Ressourcen. Diese Liste ist nicht vollständig.
- Regionale MIGs
- Regionale Cloud Storage-Buckets
- Regionale nichtflüchtige Speicher
- Regionale GKE-Cluster mit der Standardkonfiguration (mehrere Zonen)
- VPC-Subnetze
- Regionale externe Application Load Balancer
- Regionale Spanner-Instanzen
- Filestore Enterprise-Instanzen
- Cloud Run-Dienste
Regionale Ressourcen sind ausfallsicher gegenüber Vorfällen in einer bestimmten Zone. Ein Ausfall einer Region kann sich auf einige oder alle regionalen Ressourcen auswirken, die innerhalb dieser Region bereitgestellt werden. Solche Ausfälle können durch Naturkatastrophen oder umfangreiche Infrastrukturfehler verursacht werden.
Multiregionale Ressourcen
Multiregionale Ressourcen werden auf bestimmte Regionen verteilt. Die folgenden Beispiele zeigen multiregionale Ressourcen. Diese Liste ist nicht vollständig.
- Dual- und multiregionale Cloud Storage-Buckets
- Multiregionale Spanner-Instanzen
- Multi-Cluster-Bigtable-Instanzen (mehrere Regionen)
- Multiregionale Schlüsselbunde im Cloud Key Management Service
Eine vollständige Liste der Google-Dienste, die in multiregionalen Konfigurationen verfügbar sind, finden Sie unter verfügbare Produkte nach Standort.
Multiregionale Ressourcen sind ausfallsicher gegenüber Vorfällen in bestimmten Regionen und Zonen. Ein Infrastrukturausfall, der in mehreren Regionen auftritt, kann die Verfügbarkeit einiger oder aller multiregionalen Ressourcen beeinträchtigen, die in den betroffenen Regionen bereitgestellt werden.
Globale Ressourcen
Globale Ressourcen sind an allen Google Cloud-Standorten verfügbar. Im Folgenden finden Sie Beispiele für globale Ressourcen. Diese Liste ist nicht vollständig.
Projekten verknüpft und werden zu deren Bezahlung verwendet. Anleitungen und Best Practices zum Organisieren Ihrer Google Cloud-Ressourcen in Ordnern und Projekten finden Sie unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone auswählen.
VPC-Netzwerke, einschließlich zugehöriger Routen und Firewallregeln
Cloud DNS-Zonen
Globale externe Application Load Balancer
Globale Schlüsselbunde im Cloud Key Management Service
Pub/Sub-Themen
Secrets im Secret Manager
Eine vollständige Liste der global verfügbaren Google-Dienste finden Sie unter Globale Produkte.
Globale Ressourcen sind gegenüber zonalen und regionalen Vorfällen stabil. Diese Ressourcen sind nicht auf Infrastruktur in einer bestimmten Region angewiesen. Google Cloud verfügt über Systeme und Prozesse, die das Risiko globaler Infrastrukturausfälle minimieren. Google überwacht auch die Infrastruktur kontinuierlich und behebt globale Ausfälle schnell.
In der folgenden Tabelle wird die relative Ausfallsicherheit von zonalen, regionalen, multiregionalen und globalen Ressourcen gegenüber Anwendungs- und Infrastrukturproblemen zusammengefasst. Außerdem wird der Aufwand für die Einrichtung dieser Ressourcen sowie Empfehlungen zur Minderung der Auswirkungen von Ausfällen beschrieben.
| Ressourcenbereich | Robustheit | Empfehlungen zur Minderung der Auswirkungen von Infrastrukturausfällen |
|---|---|---|
| Zonal | Niedrig | Ressourcen redundant in mehreren Zonen oder Regionen bereitstellen |
| Regional | Mittel | Ressourcen redundant in mehreren Regionen bereitstellen |
| Multiregional oder global | Hoch | Änderungen sorgfältig verwalten und nach Möglichkeit tief greifende Fallback-Ressourcen einsetzen. Weitere Informationen finden Sie unter Empfehlungen zur Minderung des Risikos von Ausfällen globaler Ressourcen. |
Empfehlungen zur Bewältigung der Risiken von Ausfällen globaler Ressourcen
Um die Ausfallsicherheit globaler Ressourcen gegenüber Zonen- und Regionsausfällen zu nutzen, sollten Sie bestimmte globale Ressourcen in Ihrer Architektur verwenden. Google empfiehlt die folgenden Ansätze, um das Risiko von Ausfällen globaler Ressourcen zu verwalten:
Umfassende Verwaltung von Änderungen an globalen Ressourcen
Globale Ressourcen sind ausfallsicher gegenüber physischen Ausfällen. Die Konfiguration für solche Ressourcen ist global beschränkt. Das Einrichten und Konfigurieren einer einzelnen globalen Ressource ist daher einfacher als das Ausführen mehrerer regionaler Ressourcen. Ein kritischer Fehler in der Konfiguration einer globalen Ressource kann jedoch zu einem Single Point of Failure (SPOF) werden. Sie können beispielsweise einen globalen Load-Balancer als Frontend für eine geografisch verteilte Anwendung verwenden. Ein globaler Load-Balancer ist häufig eine gute Wahl für eine solche Anwendung. Ein Fehler in der Konfiguration des Load-Balancers kann jedoch dazu führen, dass er nicht in allen Regionen verfügbar ist. Sie müssen Konfigurationsänderungen an globalen Ressourcen sorgfältig verwalten, um dieses Risiko zu vermeiden. Weitere Informationen finden Sie unter Änderungen an globalen Ressourcen steuern.
Einsatz regionaler Ressourcen als Fallback mit gestaffelten Sicherheitsebenen
Bei Anwendungen mit außergewöhnlich hohen Verfügbarkeitsanforderungen können regionale gestaffelte Sicherheitsebenen als Fallbacks dazu beitragen, die Auswirkungen von Ausfällen globaler Ressourcen zu minimieren. Betrachten Sie das Beispiel einer geografisch verteilten Anwendung, die einen globalen Load-Balancer als Frontend hat. Damit die Anwendung auch dann Zugriff hat, wenn der globale Load-Balancer von einem globalen Ausfall betroffen ist, können Sie regionale Load-Balancer bereitstellen. Sie können die Clients so konfigurieren, dass sie den globalen Load-Balancer bevorzugen. Wenn der globale Load-Balancer jedoch nicht verfügbar ist, wird ein Failover auf den nächsten regionalen Load-Balancer durchgeführt.
Beispielarchitektur mit zonalen, regionalen und globalen Ressourcen
Ihre Cloud-Topologie kann eine Kombination aus zonalen, regionalen und globalen Ressourcen enthalten, wie im folgenden Diagramm dargestellt. Im folgenden Diagramm ist eine Beispielarchitektur für eine mehrstufige Anwendung dargestellt, die in Google Cloud bereitgestellt wird.
Wie im vorherigen Diagramm dargestellt, empfängt ein globaler externer HTTP/S-Load-Balancer Clientanfragen. Der Load-Balancer verteilt die Anfragen an das Backend, eine regionale MIG mit zwei Compute Engine-VMs. Die auf den VMs ausgeführte Anwendung schreibt Daten in eine Cloud SQL-Datenbank und liest daraus aus. Die Datenbank ist für HA konfiguriert. Die primäre Instanz und die Standby-Instanz der Datenbank werden in separaten Zonen bereitgestellt. Die primäre Datenbank wird synchron in die Standby-Datenbank repliziert. Darüber hinaus wird die Datenbank automatisch in einem multiregionalen Bucket in Cloud Storage gesichert.
In der folgenden Tabelle sind die Google Cloud-Ressourcen aus der vorherigen Architektur und die Robustheit jeder Ressource gegenüber Ausfällen von Zonen und Regionen zusammengefasst:
| Ressource | Widerstandsfähigkeit gegen Ausfälle |
|---|---|
| VPC-Netzwerk | VPC-Netzwerke und die damit verknüpften Routen und Firewallregeln sind globale Ressourcen. Sie sind gegen Zonen- und Regionsausfälle resistent. |
| Subnetze | VPC-Subnetze sind regionale Ressourcen. Sie sind gegen Zonenausfälle resistent. |
| Globaler externer HTTP(S)-Load-Balancer | Globale externe HTTP/S-Load-Balancer sind ausfallsicher gegenüber Ausfällen von Zonen und Regionen. |
| Regionale MIG | Regionale MIGs sind gegen Zonenausfälle resistent. |
| Compute Engine-VMs | Compute Engine-VMs sind zonale Ressourcen. Wenn ein Zonenausfall auftritt, sind die einzelnen Compute Engine-VMs möglicherweise betroffen. Die Anwendung kann jedoch weiterhin Anfragen verarbeiten, da das Backend für den Load-Balancer eine regionale MIG und keine eigenständige VM ist. |
| Cloud SQL-Instanzen | Die Cloud SQL-Bereitstellung in dieser Architektur ist für Hochverfügbarkeit konfiguriert. Das heißt, die Bereitstellung enthält ein Primär-Standby-Paar von Datenbankinstanzen. Die primäre Datenbank wird mithilfe regionaler nichtflüchtiger Speicher synchron in die Standby-Datenbank repliziert.
|
| Multiregionaler Cloud Storage-Bucket | Daten, die in multiregionalen Cloud Storage-Buckets gespeichert sind, sind gegen Ausfälle einzelner Regionen geschützt. |
| Nichtflüchtige Speicher | Nichtflüchtige Speicher können zonal oder regional sein. Regionale nichtflüchtige Speicher sind gegen Zonenausfälle resistent. Zur Vorbereitung auf die Wiederherstellung nach Regionsausfällen können Sie Snapshots von nichtflüchtigen Speichern planen und die Snapshots in einem Cloud Storage-Bucket mit mehreren Regionen speichern. |