In diesem Abschnitt des Leitfadens für die Archetypen für Bereitstellungen in Google Cloud wird der multiregionale Deployment-Archetyp beschrieben.
In einer Cloud-Architektur, die den Archetyp für multiregionale Bereitstellungen verwendet, wird die Anwendung in zwei oder mehr Google Cloud-Regionen ausgefü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 starke regionenübergreifende Konsistenz von Daten erfordert, muss die Datenbankreplikation synchron sein. Andernfalls können die Datenbanken asynchron repliziert werden. Nutzeranfragen werden mithilfe einer DNS-Routingrichtlinie 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 und eine hohe Verfügbarkeit und Robustheit bei Ausfällen in der Region erfordern. Wenn eine Region aus irgendeinem Grund nicht mehr verfügbar ist (auch bei großflächigen Störungen aufgrund einer Naturkatastrophe), kommt es bei den Nutzern der Anwendung zu keinen Ausfallzeiten. Der Traffic wird an die Anwendung in den anderen verfügbaren Regionen weitergeleitet. Wenn Daten synchron repliziert werden, liegt das Recovery Time Objective (RTO) nahe null.
Niedrige Latenz für Anwendungsnutzer
Wenn sich Ihre Nutzer in einem bestimmten geografischen Gebiet befinden, z. B. auf einem Kontinent, können Sie ein multiregionales Deployment verwenden, um ein optimales Gleichgewicht zwischen Verfügbarkeit und Leistung zu erzielen. Wenn eine der Regionen ausfällt, sendet der globale Load-Balancer Anfragen, die aus dieser Region stammen, an eine andere Region. Nutzer nehmen keine erheblichen Auswirkungen auf die Leistung wahr, da sich die Regionen innerhalb eines geografischen Bereichs 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 mehreren Standorten bereitstellen und verwalten, kann das Volumen des regionenübergreifenden Netzwerktraffics 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.