In diesem Abschnitt des Google Cloud Leitfadens für Bereitstellungsarchetypen wird der Archetyp für multiregionale Bereitstellungen beschrieben.
In einer Cloud-Architektur, die den Archetyp für multiregionale Bereitstellungen verwendet, wird die Anwendung in zwei oder mehr Google Cloud Regionenausgeführt. Anwendungsdaten werden über alle Regionen in der Architektur hinweg repliziert. Um eine schnelle und synchrone Replikation von Daten zu ermöglichen, befinden sich die Regionen in der Regel auf ein- und demselben Kontinent.
Das folgende Diagramm zeigt die Cloud-Topologie für eine Anwendung, die in zwei Google Cloud Regionen ausgeführt wird:
Das obige Diagramm zeigt zwei isolierte mehrschichtige Anwendungspakete, die unabhängig voneinander in zwei Google Cloud Regionen ausgeführt werden. In jeder Region wird die Anwendung in drei Zonen ausgeführt. Die Datenbanken in den beiden Regionen werden repliziert. Wenn die Arbeitslast ein niedriges Recovery Point Objective (RPO) hat oder eine strikte regionenübergreifende Datenkonsistenz erfordert, muss die Datenbankreplikation synchron erfolgen. Andernfalls können die Datenbanken asynchron repliziert werden. Nutzeranfragen werden mithilfe von DNS-Routingrichtlinien an regionale Load Balancer weitergeleitet. Kommt es in einer der beiden Regionen zu einem Ausfall, leitet DNS die Nutzeranfragen an den Load Balancer in der anderen Region weiter.
Anwendungsfälle
In den folgenden Abschnitten finden Sie Beispiel-Anwendungsfälle, in denen sich der Archetyp für multiregionale Bereitstellungen eignet.
Hochverfügbarkeit für geografisch verteilte Nutzer
Wir empfehlen eine multiregionale Bereitstellung für Anwendungen, die geschäftskritisch sind sowie eine Hochverfügbarkeit und Robustheit bei regionalen Ausfällen erfordern. Wenn eine Region aus irgendeinem Grund nicht verfügbar ist (auch bei einer großflächigen Störung durch eine Naturkatastrophe), kommt es für die Nutzer der Anwendung zu keiner Ausfallzeit. Der Traffic wird an die Anwendung in den anderen verfügbaren Regionen weitergeleitet. Wenn Daten synchron repliziert werden, liegt das Recovery Time Objective (RTO) fast bei null.
Niedrige Latenz für Anwendungsnutzer
Wenn sich Ihre Nutzer in einem bestimmten geografischen Gebiet befinden, z. B. auf einem Kontinent, können Sie mit einer multiregionalen Bereitstellung ein optimales Gleichgewicht zwischen Verfügbarkeit und Leistung erzielen. Wenn es in einer der Regionen zu einem Ausfall kommt, sendet der globale Load Balancer Anfragen, die aus dieser Region stammen, an eine andere Region. Nutzer bemerken keine erheblichen Leistungseinbußen, da sich die Regionen in einem geografischen Gebiet befinden.
Einhaltung der Anforderungen hinsichtlich Datenstandort und Datenhoheit
Der Archetyp für multiregionale 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. Sie können die Anwendung in Google Cloud Regionen in Europa bereitstellen und DNS mit einer Geofencing-Routingrichtlinie zum Weiterleiten von Traffic in die entsprechende Region verwenden.
Designaspekte
Wenn Sie redundante Ressourcen an verschiedenen Standorten bereitstellen und verwalten, kann das Volumen des standortübergreifenden Netzwerkverkehrs hoch sein. Außerdem speichern und replizieren Sie Daten in mehreren Regionen. Berücksichtigen Sie beim Erstellen einer Architektur, die den Archetyp für multiregionale Bereitstellungen verwendet, die potenziell höheren Kosten für Cloud-Ressourcen und den Netzwerktraffic sowie die Komplexität des Betriebs der Bereitstellung. Bei geschäftskritischen Anwendungen kann der Verfügbarkeitsvorteil einer multiregionalen Architektur die erhöhten Kosten und die betriebliche Komplexität möglicherweise aufwiegen.
Referenzarchitektur
Eine Referenzarchitektur, mit der Sie eine multiregionale Bereitstellung auf Compute Engine-VMs entwerfen können, finden Sie unter Multiregionale Bereitstellung in Compute Engine.