Wie unter Plattformverfügbarkeit beschrieben, ist die Google Cloud-Infrastruktur auf eine Zielverfügbarkeit von 99,9% für eine Arbeitslast ausgelegt, die in einer einzelnen Zone bereitgestellt wird. Die Zielverfügbarkeit beträgt 99,99% für eine Bereitstellung in mehreren Zonen und 99,999% für eine Bereitstellung in mehreren Regionen. Dieser Teil des Google Cloud-Infrastrukturzuverlässigkeitsleitfadens enthält Bereitstellungsanleitungen, Beispielarchitekturen und Designtechniken, mit denen Sie Ihre Arbeitslasten vor Ausfällen auf Ressourcen-, Zonen- und Regionenebene schützen können.
Single Points of Failure vermeiden
Anwendungen bestehen in der Regel aus mehreren abhängigen Komponenten, die jeweils eine bestimmte Funktion ausführen sollen. Diese Komponenten werden in der Regel anhand der von ihnen ausgeführten Funktion und ihrer Beziehung zu den anderen Komponenten in Schichten gruppiert. Eine Content-Serving-Anwendung kann beispielsweise drei Ebenen haben: eine Webebene mit einem Load Balancer und Webservern, eine Anwendungsebene mit einem Cluster von Anwendungsservern und eine Datenebene für die Persistenz. Wenn eine Komponente dieses Anwendungspakets von einer einzelnen Infrastrukturressource abhängt, kann sich ein Ausfall dieser Ressource auf die Verfügbarkeit des gesamten Stacks auswirken. Wenn beispielsweise die Anwendungsebene auf einer einzelnen VM ausgeführt wird und die VM abstürzt, ist der gesamte Stack praktisch nicht verfügbar. Eine solche Komponente ist ein Single Point of Failure (SPOF).
Ein Anwendungs-Stack kann mehr als einen SPOF haben. Sehen Sie sich den mehrstufigen Anwendungs-Stack an, das im folgenden Diagramm dargestellt ist:
Wie im vorherigen Diagramm dargestellt, enthält diese Beispielarchitektur einen einzelnen Load-Balancer, zwei Webserver, einen einzelnen Anwendungsserver und eine einzelne Datenbank. Der Load-Balancer, der Anwendungsserver und die Datenbank in diesem Beispiel sind SPOFs. Ein Fehler einer dieser Komponenten kann dazu führen, dass Nutzeranfragen an die Anwendung fehlschlagen.
Wenn Sie die SPOFs aus Ihrem Anwendungs-Stack entfernen möchten, verteilen Sie Ressourcen auf Standorte und stellen Sie redundante Ressourcen bereit.
Ressourcen verteilen und Redundanz schaffen
Je nach Zuverlässigkeitsanforderungen Ihrer Anwendung können Sie aus den folgenden Bereitstellungsarchitekturen auswählen:
| Architektur | Arbeitslastempfehlung |
|---|---|
| Mehrere Regionen | Arbeitslasten, die geschäftskritisch sind und für die eine hohe Verfügbarkeit wichtig ist, wie Anwendungen für den Einzelhandel und soziale Medien. |
| Mehrere Zonen | Arbeitslasten, die Widerstandsfähigkeit gegen Zonenausfälle benötigen, aber eine gewisse Ausfallzeit tolerieren können, die durch Regionsausfälle verursacht wird. |
| Einzelne Zone | Arbeitslasten, die Ausfallzeiten tolerieren oder bei Bedarf an einem anderen Speicherort mit minimalem Aufwand bereitgestellt werden können. |
Kosten, Latenz und Betrieb
Wenn Sie eine verteilte Architektur mit redundanten Ressourcen entwerfen, müssen Sie neben den Verfügbarkeitsanforderungen der Anwendung auch die Auswirkungen auf die Betriebskomplexität, Latenz und Kosten berücksichtigen.
In einer verteilten Architektur stellen Sie eine höhere Anzahl von Ressourcen bereit und verwalten sie. Das Volumen des standortübergreifenden Netzwerktraffics ist höher. Außerdem speichern und replizieren Sie mehr Daten. Infolgedessen sind die Kosten Ihrer Cloud-Ressourcen in einer verteilten Architektur höher und der Betrieb solcher Bereitstellungen ist komplexer. Bei geschäftskritischen Anwendungen kann der Verfügbarkeitsvorteil einer verteilten Architektur die höheren Kosten und die betriebliche Komplexität überwiegen.
Für Anwendungen, die nicht geschäftskritisch sind, ist die hohe Verfügbarkeit einer verteilten Architektur möglicherweise nicht unerlässlich. Bestimmte Anwendungen haben andere Anforderungen, die wichtiger als die Verfügbarkeit sind. Beispielsweise benötigen Batch-Computing-Anwendungen Netzwerkverbindungen mit niedriger Latenz und hoher Bandbreite zwischen den VMs. Eine Architektur mit einer einzelnen Zone eignet sich möglicherweise für solche Anwendungen und kann außerdem dazu beitragen, die Kosten für Datenübermittlung zu reduzieren.
Deployment-Architekturen
In diesem Abschnitt werden die folgenden Architekturoptionen vorgestellt, mit denen Sie eine Infrastruktur für Ihre Arbeitslasten in Google Cloud erstellen können:
- Bereitstellung in einer Zone
- Bereitstellung in mehreren Zonen
- Multiregionale Bereitstellung mit regionalem Load-Balancing
- Multiregionale Bereitstellung mit globalem Load-Balancing
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 Edition), 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:
| Ressource | SLA |
|---|---|
| Externer Load-Balancer | 99,99 % |
| Webebene: Compute Engine-VMs in einer einzelnen Zone | 99,9 % |
| Internes Load-Balancing-Modul | 99,99 % |
| Anwendungsebene: Compute Engine-VMs in einer einzelnen Zone | 99,9 % |
| Cloud SQL-Instanz (Enterprise Edition) | 99,95 % |
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 Edition), 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.
Aggregierte Verfügbarkeit: Bereitstellung in mehreren Zonen
Die folgende Tabelle zeigt die Verfügbarkeit der einzelnen Ebenen im vorherigen Dual-Zonen-Architekturdiagramm:
| Ressource | 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 % |
| Cloud SQL-Instanz (Enterprise Edition) | 99,95 % |
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:
- 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%
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%.
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.
- 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%
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%.
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.