Zuverlässige Infrastruktur für Ihre Arbeitslasten in Google Cloud entwerfen

Bereitstellung in einer Zone

Das folgende Diagramm zeigt eine Anwendungsarchitektur mit einer einzelnen Zone, die in jeder Stufe Redundanz bietet, um eine höhere Verfügbarkeit der Funktionen zu erreichen, die von jeder Komponente ausgeführt werden:

Wie im vorherigen Diagramm dargestellt, enthält diese Beispielarchitektur die folgenden Komponenten:

• Ein regionaler externer HTTP/S-Load-Balancer, der Nutzeranfragen empfängt und darauf reagiert.
• Eine zonal verwaltete Instanzgruppe (MIG) als Backend für den HTTP/S-Load-Balancer. Die MIG hat zwei Compute Engine-VMs. Jede VM hostet eine Instanz eines Webservers.
• Ein interner Load-Balancer, der die Kommunikation zwischen dem Webserver und den Anwendungsserverinstanzen übernimmt
• Eine zweite zonale MIG als Backend für den internen Load-Balancer. Diese MIG enthält zwei Compute Engine-VMs. Jede VM hostet eine Instanz eines Anwendungsservers.
• Eine Cloud SQL-Datenbankinstanz (Enterprise-Version), in die die Anwendung Daten schreibt und aus der sie liest. Die Datenbank wird manuell in eine zweite Cloud SQL-Datenbankinstanz in derselben Zone repliziert.

Aggregierte Verfügbarkeit: Bereitstellung in einer Zone

Die folgende Tabelle zeigt die Verfügbarkeit der einzelnen Ebenen im vorherigen Architekturdiagramm der einzelnen Zone:

Sie können von den in der vorherigen Tabelle aufgeführten Google Cloud-Infrastrukturressourcen profitieren, um die folgende aggregierte Verfügbarkeit und die geschätzte maximale Ausfallzeit pro Monat bereitzustellen:

• Aggregatverfügbarkeit: 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73 %
• Geschätzte maximale Ausfallzeit pro Monat: ca. 1 Stunde und 57 Minuten

Bei dieser Berechnung werden nur die Infrastrukturressourcen berücksichtigt, die im vorherigen Architekturdiagramm dargestellt sind. Um die Verfügbarkeit einer Anwendung in Google Cloud zu bewerten, müssen Sie auch weitere Faktoren berücksichtigen:

• Das interne Design der Anwendung.
• Die DevOps-Prozesse und -Tools, die zum Erstellen, Bereitstellen und Verwalten der Anwendung, ihrer Abhängigkeiten und der Google Cloud-Infrastruktur verwendet werden

Weitere Informationen finden Sie unter Faktoren, die sich auf die Zuverlässigkeit von Anwendungen auswirken.

Auswirkungen von Ausfällen und Anleitungen zur Wiederherstellung

Wenn eine Komponente in einer Bereitstellung mit einer einzelnen Zone ausfällt, kann die Anwendung Anfragen verarbeiten, wenn jede Stufe mindestens eine funktionierende Komponente mit ausreichender Kapazität enthält. Wenn beispielsweise eine Webserverinstanz ausfällt, leitet der Load-Balancer Nutzeranfragen an die anderen Webserverinstanzen weiter. Wenn eine VM, die einen Webserver oder eine Anwendungsserverinstanz hostet, abstürzt, sorgt die MIG dafür, dass automatisch eine neue VM erstellt wird. Wenn die Datenbank abstürzt, müssen Sie die zweite Datenbank manuell aktivieren und die Anwendungsserverinstanzen aktualisieren, um eine Verbindung zur Datenbank herzustellen.

Ein Zonenausfall oder ein Ausfall der Region wirkt sich auf die Compute Engine-VMs und die Cloud SQL-Datenbankinstanzen in einer Bereitstellung in einer einzelnen Zone aus. Ein Zonenausfall hat keinen Einfluss auf den Load-Balancer in dieser Architektur, da es sich um eine regionale Ressource handelt. Der Load-Balancer kann den Traffic jedoch nicht verteilen, da keine Back-Ends verfügbar sind. Wenn ein Zonenausfall auftritt, müssen Sie warten, bis Google den Ausfall behoben hat, und dann prüfen, ob die Anwendung wie erwartet funktioniert.

Im nächsten Abschnitt wird ein Architekturansatz beschrieben, mit dem Sie Ressourcen auf mehrere Zonen verteilen können. Dadurch wird die Ausfallsicherheit der Anwendung bei Zonenausfällen verbessert.

Bereitstellung in mehreren Zonen

Wenn bei einer Bereitstellung in einer einzelnen Zone ein Zonenausfall auftritt, kann die Anwendung möglicherweise keine Anfragen verarbeiten, bis das Problem behoben ist. Damit die Ausfallsicherheit Ihrer Anwendung gegen Zonenausfälle verbessert wird, können Sie mehrere Instanzen zonaler Ressourcen (z. B. Compute Engine-VMs) in zwei oder mehr Zonen bereitstellen. Für Dienste, die regionsbezogene Ressourcen unterstützen (z. B. Cloud Storage-Buckets), können Sie regionale Ressourcen bereitstellen.

Das folgende Diagramm zeigt eine hochverfügbare zonenübergreifende Architektur, bei der die Komponenten in jeder Stufe des Anwendungspakets auf zwei Zonen verteilt sind:

Wie im vorherigen Diagramm dargestellt, enthält diese Beispielarchitektur die folgenden Komponenten:

• Ein regionaler externer HTTP/S-Load-Balancer empfängt und antwortet auf Nutzeranfragen.
• Eine regionale MIG ist das Backend für den HTTP/S-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 TCP-Load-Balancer. Diese MIG hat zwei Compute Engine-VMs in verschiedenen Zonen. Jede VM hostet eine Instanz eines Anwendungsservers.
• Eine Cloud SQL-Instanz (Enterprise-Version), die für HA konfiguriert ist, ist die Datenbank für die Anwendung. Die primäre Datenbankinstanz wird synchron in eine Standby-Datenbankinstanz repliziert.

Aggregierte Verfügbarkeit: Bereitstellung in mehreren Zonen

Die folgende Tabelle zeigt die Verfügbarkeit der einzelnen Ebenen im vorherigen Dual-Zonen-Architekturdiagramm:

Sie können von den in der vorherigen Tabelle aufgeführten Google Cloud-Infrastrukturressourcen profitieren, um die folgende aggregierte Verfügbarkeit und die geschätzte maximale Ausfallzeit pro Monat bereitzustellen:

• Aggregatverfügbarkeit: 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
• Geschätzte maximale Ausfallzeit pro Monat: ca. 39 Minuten

Bei dieser Berechnung werden nur die Infrastrukturressourcen berücksichtigt, die im vorherigen Architekturdiagramm dargestellt sind. Um die Verfügbarkeit einer Anwendung in Google Cloud zu bewerten, müssen Sie auch weitere Faktoren berücksichtigen:

• Das interne Design der Anwendung.
• Die DevOps-Prozesse und -Tools, die zum Erstellen, Bereitstellen und Verwalten der Anwendung, ihrer Abhängigkeiten und der Google Cloud-Infrastruktur verwendet werden

Weitere Informationen finden Sie unter Faktoren, die sich auf die Zuverlässigkeit von Anwendungen auswirken.

Auswirkungen von Ausfällen und Anleitungen zur Wiederherstellung

Wenn bei einer Bereitstellung mit zwei Zonen eine Komponente ausfällt, kann die Anwendung Anfragen verarbeiten, wenn mindestens eine funktionierende Komponente mit ausreichender Kapazität in jeder Stufe vorhanden ist. Wenn beispielsweise eine Webserverinstanz ausfällt, leitet der Load-Balancer Nutzeranfragen an die Webserverinstanz in der anderen Zone weiter. Wenn eine VM, die einen Webserver oder eine Anwendungsserverinstanz hostet, abstürzt, sorgt die MIG dafür, dass automatisch eine neue VM erstellt wird. Wenn die primäre Cloud SQL-Datenbank abstürzt, führt Cloud SQL automatisch ein Failover auf die Standby-Datenbankinstanz aus.

Das folgende Diagramm zeigt die gleiche Architektur wie das vorherige Diagramm und die Auswirkungen eines Zonenausfalls auf die Verfügbarkeit der Anwendung:

Wenn im obigen Diagramm ein Ausfall in einer der Zonen auftritt, ist der Load-Balancer in dieser Architektur nicht betroffen, da es sich um eine regionale Ressource handelt. Ein Zonenausfall kann sich auf einzelne Compute Engine-VMs und eine der Cloud SQL-Datenbankinstanzen auswirken. Die Anwendung bleibt jedoch verfügbar und reaktionsfähig, da sich die VMs in regionalen MIGs befinden und die Cloud SQL-Datenbank für hohe Verfügbarkeit konfiguriert ist. Die MIGs sorgen dafür, dass neue VMs automatisch erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten. Wenn die primäre Cloud SQL-Datenbankinstanz von einem Zonenausfall betroffen ist, führt Cloud SQL ein Failover automatisch zur Standby-Instanz in der anderen Zone aus. Nachdem Google den Ausfall behoben hat, müssen Sie prüfen, ob die Anwendung in allen Zonen, in denen sie bereitgestellt wird, wie erwartet ausgeführt wird.

Wenn beide Zonen in dieser Architektur einen Ausfall haben, ist die Anwendung nicht verfügbar. Der Load-Balancer ist weiterhin verfügbar, sofern kein Ausfall der gesamten Region auftritt. Der Load-Balancer kann den Traffic jedoch nicht verteilen, da keine Back-Ends verfügbar sind. Wenn ein Ausfall einer Zone oder eine Region auftritt, müssen Sie warten, bis Google den Ausfall behoben hat, und dann überprüfen, ob die Anwendung wie erwartet funktioniert.

In den nächsten Abschnitten werden Architekturoptionen vorgestellt, mit denen Sie Ihre Anwendung vor Mehrzonen- und Regionsausfällen schützen können.

Multiregionale Bereitstellung mit regionalem Load-Balancing

Wenn in einer Bereitstellung mit einer oder mehreren Zonen ein Ausfall der Region auftritt, kann die Anwendung erst Anfragen verarbeiten, wenn das Problem behoben ist. Zum Schutz Ihrer Anwendung vor Regionsausfällen können Sie die Google Cloud-Ressourcen auf zwei oder mehr Regionen verteilen.

Das folgende Diagramm zeigt eine hochverfügbare regionenübergreifende Architektur, bei der die Komponenten in jeder Stufe des Anwendungs-Stacks auf mehrere Regionen verteilt sind:

Wie im vorherigen Diagramm dargestellt, enthält diese Beispielarchitektur die folgenden Komponenten:

• Eine öffentliche Cloud DNS-Zone mit einer Routingrichtlinie, die Traffic an zwei Google Cloud-Regionen weiterleitet.
• Ein regionaler externer HTTP/S-Load-Balancer in jeder Region, um Nutzeranfragen zu empfangen und zu beantworten.
• Das Backend für jeden regionalen HTTP/S-Load-Balancer ist eine regionale MIG. Jede MIG enthält zwei Compute Engine-VMs in verschiedenen Zonen. Jede dieser VMs hostet eine Instanz eines Webservers.
• Ein interner Load-Balancer in jeder Region übernimmt die Kommunikation zwischen den Webserverinstanzen und den Anwendungsserverinstanzen.
• Ein zweites Paar regionaler MIGs ist das Backend für die internen Load-Balancer. Jede dieser MIGs enthält zwei Compute Engine-VMs in verschiedenen Zonen. Jede VM hostet eine Instanz eines Anwendungsservers.
• Die Anwendung schreibt Daten in eine multiregionale Spanner-Instanz und liest daraus. Die multiregionale Konfiguration, die in dieser Architektur verwendet wird (eur5), enthält vier nicht schreibgeschützte Replikate. Die nicht schreibgeschützten Replikate werden gleichmäßig über zwei Regionen und in separaten Zonen bereitgestellt. Die multiregionale Spanner-Konfiguration enthält auch ein Zeugenreplikat in einer dritten Region.

Aggregierte Verfügbarkeit: Bereitstellung in mehreren Regionen mit regionalem Load Balancing

Bei der multiregionalen Bereitstellung, die im vorherigen Diagramm dargestellt wird, werden die Load-Balancer und die VMs redundant in zwei Regionen bereitgestellt. Die DNS-Zone ist eine globale Ressource und die Spanner-Instanz ist eine multiregionale Ressource.

Um die aggregierte Verfügbarkeit der Google Cloud-Infrastruktur zu berechnen, die in dieser Architektur gezeigt wird, müssen wir zuerst die aggregierte Verfügbarkeit der Ressourcen in den einzelnen Regionen berechnen und dann die Ressourcen berücksichtigen, die sich über mehrere Regionen erstrecken. Gehen Sie dazu so vor:

1. Berechnen Sie die aggregierte Verfügbarkeit der Infrastrukturressourcen pro Region, das heißt, ohne die DNS- und Datenbankressourcen:

   Ressource und SLA	SLA
   Externer Load-Balancer	99,99 %
   Webebene: Compute Engine-VMs in separaten Zonen	99,99 %
   Internes Load-Balancing-Modul	99,99 %
   Anwendungsebene: Compute Engine-VMs in separaten Zonen	99,99 %

   Aggregierte Verfügbarkeit pro Region: 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96%

2. Berechnen Sie die aggregierte Verfügbarkeit der Infrastrukturressourcen unter Berücksichtigung der dualregionalen Redundanz der Load-Balancer und der Compute Engine-VMs.

   Die theoretische Verfügbarkeit beträgt 1–(1-0,9996)(1–0,9996) = 99,999984%. Die tatsächliche erwartete Verfügbarkeit ist jedoch auf die Zielverfügbarkeit für multiregionale Bereitstellungen beschränkt, also 99,999%.

3. Berechnen Sie die aggregierte Verfügbarkeit aller Infrastrukturressourcen, einschließlich der Cloud DNS- und Spanner-Ressourcen:

   • Aggregatverfügbarkeit: 0,99999 x 1 x 0,99999 = 99,998%
   • Geschätzte maximale Ausfallzeit pro Monat: ca. 52 Sekunden

Bei dieser Berechnung werden nur die Infrastrukturressourcen berücksichtigt, die im vorherigen Architekturdiagramm dargestellt sind. Um die Verfügbarkeit einer Anwendung in Google Cloud zu bewerten, müssen Sie auch weitere Faktoren berücksichtigen:

• Das interne Design der Anwendung.
• Die DevOps-Prozesse und -Tools, die zum Erstellen, Bereitstellen und Verwalten der Anwendung, ihrer Abhängigkeiten und der Google Cloud-Infrastruktur verwendet werden

Weitere Informationen finden Sie unter Faktoren, die sich auf die Zuverlässigkeit von Anwendungen auswirken.

Auswirkungen von Ausfällen und Anleitungen zur Wiederherstellung

Wenn eine Komponente in dieser multiregionalen Bereitstellung fehlschlägt, aber mindestens eine funktionierende Komponente mit ausreichender Kapazität in jeder Stufe vorhanden ist, funktioniert die Anwendung weiter. Wenn beispielsweise eine Webserverinstanz ausfällt, leitet der regionale externe HTTP/S-Load-Balancer Nutzeranfragen an die anderen Webserverinstanzen in der Region weiter. Wenn eine der Anwendungsserverinstanzen abstürzt, senden die internen Load-Balancer ebenfalls Anfragen an die anderen Anwendungsserverinstanzen. Wenn eine der VMs abstürzt, sorgen die MIGs dafür, dass neue VMs automatisch erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten.

Ein Ausfall in einer einzelnen Zone wirkt sich nicht auf die Load-Balancer aus, da sie regionale Ressourcen und gegenüber Zonenausfällen ausfallsicher sind. Ein Zonenausfall kann sich auf einzelne Compute Engine-VMs auswirken. Die Webserver- und Anwendungsserverinstanzen bleiben jedoch verfügbar, da die VMs Teil regionaler MIGs sind. Die MIGs sorgen dafür, dass neue VMs automatisch erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten. Die Spanner-Instanz in dieser Architektur verwendet eine Konfiguration mit mehreren Regionen, die gegen Zonenausfälle resistent ist.

Informationen zur Funktionsweise von multiregionalen Replikationen in Spanner finden Sie unter Regionale und multiregionale Konfigurationen und Multi-regionale Spanner-Konfigurationen einfach erklärt:

Das folgende Diagramm zeigt dieselbe multiregionale Architektur wie im vorherigen Diagramm und die Auswirkungen eines Ausfalls in einer Region auf die Verfügbarkeit der Anwendung:

Wie im vorherigen Diagramm dargestellt, bleibt die Anwendung auch dann verfügbar, wenn ein Ausfall in beiden Zonen einer Region auftritt, da ein unabhängiger Anwendungs-Stack in jeder Region bereitgestellt wird. Die DNS-Zone leitet Nutzeranfragen in die Region weiter, die vom Ausfall nicht betroffen ist. Die multiregionale Spanner-Instanz ist anfällig für Regionsausfälle. Nachdem Google den Ausfall behoben hat, müssen Sie prüfen, ob die Anwendung in der Region mit dem Ausfall ausgeführt wird.

Wenn zwei der Regionen in dieser Architektur Ausfälle haben, ist die Anwendung nicht verfügbar. Warten Sie, bis Google die Ausfälle behoben hat. Prüfen Sie dann, ob die Anwendung in allen Regionen, in denen sie bereitgestellt wird, wie erwartet ausgeführt wird.

Für multiregionale Bereitstellungen können Sie anstelle von regionalen Load-Balancern auch einen globalen Load-Balancer verwenden. Im nächsten Abschnitt wird eine multiregionale Bereitstellungsarchitektur vorgestellt, die einen globalen Load-Balancer verwendet und die Vorteile und Risiken dieses Ansatzes beschreibt.

Multiregionale Bereitstellung mit globalem Load-Balancing

Das folgende Diagramm zeigt eine alternative Bereitstellung mit mehreren Regionen, die einen globalen Load-Balancer anstelle von regionalen Load-Balancern verwendet:

Wie im vorherigen Diagramm dargestellt, verwendet diese Architektur einen globalen externen HTTP/S-Load-Balancer (mit aktiviertem Cloud CDN), um Nutzeranfragen zu empfangen und zu beantworten. Jede Weiterleitungsregel des Load-Balancers verwendet eine einzelne externe IP-Adresse. Sie müssen nicht für jede Region einen separaten DNS-Eintrag konfigurieren. Die Back-Ends für den globalen externen HTTP/S-Load-Balancer sind zwei regionale MIGs. Der Load-Balancer leitet Anfragen an die Region weiter, die den Nutzern am nächsten ist.

Alle anderen Komponenten in dieser Architektur sind mit der Architektur identisch, die unter Multiregionale Bereitstellung mit regionalem Load-Balancing gezeigt wird.

Vorteile und Risiken des globalen Load-Balancing für multiregionale Bereitstellungen

Für das Load-Balancing von externem Traffic zu einer Anwendung, die auf mehrere Regionen verteilt ist, können Sie entweder einen globalen Load-Balancer oder mehrere regionale Load-Balancer verwenden.

Die Architektur eines globalen Load-Balancer bietet folgende Vorteile:

• Sie müssen nur einen einzigen Load-Balancer verwalten.
• Globale Load-Balancer verwenden eine einzelne Anycast-IP-Adresse, um das Load-Balancing in Google Cloud-Regionen bereitzustellen.
• Globale Load-Balancer sind gegen Regionsausfälle resistent und bieten automatisches regionenübergreifendes Failover.
• Globale Load-Balancer unterstützen die folgenden Features, mit denen die Zuverlässigkeit Ihrer Bereitstellungen verbessert werden kann:
  • Edge-Caching mit Cloud CDN
  • Die Möglichkeit, langlebige Cloud Storage-Buckets als Back-Ends zu verwenden
  • Google Cloud Armor-Sicherheitsrichtlinien

Nachfolgend sind die Risiken einer Architektur aufgeführt, die einen globalen Load-Balancer verwendet:

• Eine fehlerhafte Änderung der Konfiguration des globalen Load-Balancer kann dazu führen, dass die Anwendung für Nutzer nicht mehr verfügbar ist. Wenn Sie beispielsweise beim Frontend des globalen Load-Balancers eine Weiterleitungsregel versehentlich löschen, erhält der Load-Balancer keine Nutzeranfragen mehr. Die Auswirkungen dieses Risikos sind bei einer Architektur mit mehreren Regionen und regionalen Load Balancern geringer. Selbst wenn der regionale Load Balancer in einer der Regionen von einem Konfigurationsfehler betroffen ist, arbeiten die Load Balancer in den anderen Regionen weiter.
• Ein Infrastrukturausfall, der globale Ressourcen betrifft, kann dazu führen, dass der globale Load Balancer nicht mehr verfügbar ist.

Um diese Risiken zu vermindern, müssen Sie Änderungen am globalen Load-Balancer sorgfältig verwalten und möglichst gestaffelte Fallbacks verwenden. Weitere Informationen finden Sie unter Empfehlungen zur Bewältigung der Risiken von Ausfällen globaler Ressourcen.

Aggregierte Verfügbarkeit: Bereitstellung in mehreren Regionen mit globalem Load Balancing

Bei der multiregionalen Bereitstellung, die im vorherigen Diagramm dargestellt ist, werden die VMs und die internen Load-Balancer redundant auf zwei Regionen verteilt. Der externe Load-Balancer ist eine globale Ressource und die Spanner-Instanz ist eine multiregionale Ressource.

Um die aggregierte Verfügbarkeit dieser Bereitstellung zu berechnen, berechnen wir zuerst die aggregierte Verfügbarkeit der Ressourcen in jeder Region und berücksichtigen dann die Ressourcen, die sich über mehrere Regionen erstrecken.

1. Berechnen Sie die aggregierte Verfügbarkeit der Infrastrukturressourcen pro Region, ohne den externen Load-Balancer und die Datenbank:

   Ressource	SLA
   Webebene: Compute Engine-VMs in separaten Zonen	99,99 %
   Internes Load-Balancing-Modul	99,99 %
   Anwendungsebene: Compute Engine-VMs in separaten Zonen	99,99 %

   Aggregatverfügbarkeit pro Region: 0,9999 x 0,9999 x 0,9999 = 99,97%

2. Berechnen Sie die aggregierte Verfügbarkeit der Infrastrukturressourcen unter Berücksichtigung der dualregionalen Redundanz des internen Load Balancers und der Compute Engine-VMs.

   Die theoretische Verfügbarkeit beträgt 1–(1-0,9997)(1–0,9997) = 99,999991%. Die tatsächliche erwartete Verfügbarkeit ist jedoch auf die Zielverfügbarkeit für multiregionale Bereitstellungen beschränkt, also 99,999%.

3. Berechnen Sie die aggregierte Verfügbarkeit aller Infrastrukturressourcen, einschließlich des globalen Load Balancers und der Spanner-Ressourcen:

   • Aggregatverfügbarkeit: 0,99999 x 0,9999 x 0,99999 = 99,988%
   • Geschätzte maximale Ausfallzeit pro Monat: ca. 5 Minuten und 11 Sekunden

Bei dieser Berechnung werden nur die Infrastrukturressourcen berücksichtigt, die im vorherigen Architekturdiagramm dargestellt sind. Um die Verfügbarkeit einer Anwendung in Google Cloud zu bewerten, müssen Sie auch weitere Faktoren berücksichtigen:

• Das interne Design der Anwendung.
• Die DevOps-Prozesse und -Tools, die zum Erstellen, Bereitstellen und Verwalten der Anwendung, ihrer Abhängigkeiten und der Google Cloud-Infrastruktur verwendet werden

Weitere Informationen finden Sie unter Faktoren, die sich auf die Zuverlässigkeit von Anwendungen auswirken.

Auswirkungen von Ausfällen und Anleitungen zur Wiederherstellung

Wenn eine Komponente in dieser Architektur ausfällt, funktioniert die Anwendung weiterhin, wenn mindestens eine funktionsfähige Komponente mit ausreichender Kapazität auf jeder Stufe vorhanden ist. Fällt eine Webserverinstanz aus, leitet der globale externe HTTP/S-Load-Balancer Nutzeranfragen an die anderen Webserverinstanzen weiter. Wenn eine Anwendungsserverinstanz abstürzt, senden die internen Load-Balancer die Anfragen an die anderen Anwendungsserverinstanzen. Wenn eine der VMs abstürzt, sorgen die MIGs dafür, dass neue VMs automatisch erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten.

Wenn ein Ausfall in einer der Zonen in einer beliebigen Region auftritt, ist der Load-Balancer nicht betroffen. Der globale externe HTTP/S-Load-Balancer ist gegen Ausfälle von Zonen und Regionen resistent. Die internen Load-Balancer sind regionale Ressourcen. Sie sind ausfallsicher gegenüber Zonenausfällen. Ein Zonenausfall kann sich auf einzelne Compute Engine-VMs auswirken. Die Webserver- und Anwendungsserverinstanzen bleiben jedoch verfügbar, da die VMs Teil regionaler MIGs sind. Die MIGs sorgen dafür, dass neue VMs automatisch erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten. Die Spanner-Instanz in dieser Architektur verwendet eine Konfiguration mit mehreren Regionen, die gegen Zonenausfälle resistent ist.

Das folgende Diagramm zeigt dieselbe multiregionale Architektur wie im vorherigen Diagramm und die Auswirkungen eines Ausfalls in einer Region auf die Verfügbarkeit der Anwendung:

Wie im vorherigen Diagramm dargestellt, bleibt die Anwendung auch dann verfügbar, wenn ein Ausfall in beiden Zonen einer Region auftritt, da ein unabhängiger Anwendungs-Stack in jeder Region bereitgestellt wird. Der globale externe HTTP/S-Load-Balancer leitet Nutzeranfragen an die Anwendung in der Region weiter, die nicht vom Ausfall betroffen ist. Die multiregionale Spanner-Instanz ist anfällig für Regionsausfälle. Nachdem Google den Ausfall behoben hat, müssen Sie prüfen, ob die Anwendung in der Region, in der der Ausfall aufgetreten ist, wie erwartet ausgeführt wird.

Informationen zur Funktionsweise von multiregionalen Replikationen in Spanner finden Sie unter Regionale und multiregionale Konfigurationen und Multi-regionale Spanner-Konfigurationen einfach erklärt:

Wenn zwei der Regionen in dieser Architektur Ausfälle haben, ist die Anwendung nicht verfügbar. Der globale externe HTTP/S-Load-Balancer ist verfügbar, kann aber keinen Traffic verteilen, da keine Back-Ends verfügbar sind. Warten Sie, bis Google die Ausfälle behoben hat. Prüfen Sie dann, ob die Anwendung in allen Regionen, in denen sie bereitgestellt wird, wie erwartet ausgeführt wird.

Multiregionale Bereitstellungen können für hohe Verfügbarkeit Ihrer wichtigsten Geschäftsanwendungen sorgen. Damit die Geschäftskontinuität während Fehlerereignissen gewährleistet ist, müssen Sie neben der Bereitstellung der Anwendung in mehreren Regionen weitere Schritte ausführen. Sie müssen beispielsweise eine Kapazitätsplanung durchführen, um dafür zu sorgen, dass entweder genügend Kapazität in allen Regionen reserviert ist oder die Risiken, die mit einem Notfall-Autoscaling verbunden sind, akzeptiert werden. Darüber hinaus müssen Sie operative Verfahren für DR-Tests, die Verwaltung von Vorfällen, die Prüfung des Status einer Anwendung nach Vorfällen und die Durchführung von Rückblicken implementieren.