In diesem Abschnitt des Leitfadens Archetypen für Bereitstellungen in Google Cloud wird der Archetyp für regionale Bereitstellungen beschrieben.
In einer Cloud-Architektur, die den Archetyp für regionale Bereitstellungen verwendet, werden Instanzen der Anwendung in zwei oder mehr Zonen innerhalb einer einzelnen Google Cloud-Region ausgeführt. Alle Anwendungsinstanzen verwenden ein zentral verwaltetes, gemeinsames Repository von Konfigurationsdateien. Anwendungsdaten werden synchron über alle Zonen in der Architektur hinweg repliziert.
Das folgende Diagramm zeigt die Cloud-Topologie für eine hochverfügbare Anwendung, die unabhängig in drei Zonen innerhalb einer Google Cloud-Region ausgeführt wird:
Das obige Diagramm zeigt eine Anwendung mit Frontend- und Backend-Komponenten, die in drei Zonen einer Google Cloud-Region unabhängig ausgeführt wird. Ein externer Load Balancer leitet Nutzeranfragen an eines der Front-Ends weiter. Ein interner Load Balancer leitet den Traffic von den Front-Ends an die Back-Ends weiter. Die Anwendung verwendet eine Datenbank, die über die Zonen hinweg repliziert wird. Wenn ein zonaler Ausfall auftritt, führt die Datenbank ein Failover auf ein Replikat in einer anderen Zone durch.
Die Topologie im vorherigen Diagramm ist gegen zonale Ausfälle resistent, jedoch nicht gegen regionale Ausfälle. Damit Sie nach einem regionalen Ausfall eine Wiederherstellung vornehmen können, müssen Sie ein passives Replikat der Anwendung in einer zweiten (Failover-)Region bereitgestellt haben, wie im folgenden Diagramm dargestellt:
Wenn ein Ausfall in der primären Region auftritt, müssen Sie die Datenbank in der Failover-Region hochstufen und die DNS-Routingrichtlinien den Traffic an den Load Balancer in der Failover-Region weiterleiten lassen.
Zur Optimierung der Kosten der Failover-Infrastruktur können Sie die Failover-Region mit einer geringeren Kapazität betreiben. Dazu stellen Sie weniger Ressourcen bereit.
Anwendungsfälle
In den folgenden Abschnitten finden Sie Beispiele für Anwendungsfälle, in denen sich der Archetyp für regionale Bereitstellungen eignet.
Hochverfügbare Anwendung mit Nutzern in einem geografischen Gebiet
Wir empfehlen den Archetyp der regionalen Bereitstellung für Anwendungen, die vor zonalen Ausfällen geschützt sein müssen, aber Ausfallzeiten aufgrund von regionalen Ausfällen tolerieren. Wenn ein Teil des Anwendungspakets fehlschlägt, wird die Anwendung weiterhin ausgeführt, sofern auf jeder Ebene mindestens eine funktionierende Komponente mit ausreichender Kapazität vorhanden ist. Wenn ein zonaler Ausfall auftritt, wird das Anwendungspaket in den anderen Zonen weiter ausgeführt.
Niedrige Latenz für Anwendungsnutzer
Wenn sich Nutzer einer Anwendung in einem geografischen Gebiet befinden, z. B. in einem einzelnen Land, kann die Auswahl des Archetyps für regionale Bereitstellungen dazu beitragen, die von Nutzern wahrgenommene Leistung der Anwendung zu verbessern. Sie können die Netzwerklatenz für Nutzeranfragen optimieren, indem Sie die Anwendung in der Google Cloud-Region bereitstellen, die Ihren Nutzern am nächsten ist.
Netzwerk mit niedriger Latenz zwischen Anwendungskomponenten
Eine Architektur mit einer einzigen Region eignet sich möglicherweise gut für Anwendungen wie Batch-Computing, die Netzwerkverbindungen mit niedriger Latenz und hoher Bandbreite an den Rechenknoten benötigen. Alle Ressourcen befinden sich in einer einzigen Google Cloud-Region, sodass der Netzwerktraffic zwischen den Ressourcen innerhalb der Region verbleibt. Die Netzwerklatenz zwischen den Ressourcen ist niedrig und es fallen keine regionenübergreifende Datenübertragungskosten an. Intraregionale Netzwerkkosten gelten weiterhin.
Einhaltung der Anforderungen hinsichtlich Datenstandort und Datenhoheit
Der Archetyp für regionale Bereitstellungen kann Ihnen helfen, regulatorische Anforderungen an den Datenstandort und die Betriebshoheit zu erfüllen. Beispiel: In einem Land in Europa müssen alle Nutzerdaten in Rechenzentren gespeichert und abgerufen werden, die sich physisch innerhalb des Landes befinden. Zur Erfüllung dieser Anforderung können Sie die Anwendung in einer Google Cloud-Region in Europa bereitstellen.
Designaspekte
Berücksichtigen Sie beim Erstellen einer Architektur, die auf dem Archetyp für regionale Bereitstellungen basiert, die folgenden Designfaktoren.
Ausfallzeiten bei regionalen Ausfällen
Wenn ein regionaler Ausfall auftritt, ist die Anwendung nicht verfügbar. Sie können Ausfallzeiten durch regionale Ausfälle reduzieren, indem Sie ein passives (Failover-)Replikat des Infrastruktur-Stacks in einer anderen Google Cloud-Region verwalten. Wenn ein Ausfall in der primären Region auftritt, können Sie den Stack in der Failover-Region aktivieren und DNS-Routingrichtlinien verwenden, um Traffic an den Load Balancer in der Failover-Region weiterzuleiten.
Kosten für redundante Ressourcen
Eine Architektur mit mehreren Zonen benötigt in der Regel mehr Cloud-Ressourcen als die Bereitstellung in einer einzelnen Zone. Berücksichtigen Sie beim Erstellen Ihrer Architektur die Kosten dieser Cloud-Ressourcen. Bei Anwendungen, die gegen zonale Ausfälle resistent sein müssen, kann der Verfügbarkeitsvorteil einer multizonalen Architektur möglicherweise die höheren Kosten aufwiegen.
Referenzarchitektur
Eine Referenzarchitektur, mit der Sie eine regionale Bereitstellung auf Compute Engine-VMs entwerfen können, finden Sie unter Regionale Bereitstellung in Compute Engine.