Wenn Sie als Cloud-Architekt oder Entscheidungsträger eine Anwendung in Google Cloud bereitstellen möchten, müssen Sie einen Bereitstellungs-Archetyp1 auswählen, der für Ihre Anwendung geeignet ist. In dieser Anleitung werden sechs Archetypen für unterschiedliche Bereitstellungen beschrieben: zonal, regional, multiregional, global, hybrid und Multi-Cloud. Außerdem werden Anwendungsfälle und Designaspekte für jeden Bereitstellungs-Archetyp beschrieben. Dieser Leitfaden bietet auch eine Vergleichsanalyse, die Ihnen dabei hilft, den für Ihre Anforderungen an Verfügbarkeit, Kosten, Leistung und operative Effizienz geeigneten Bereitstellungs-Archetyp auszuwählen.
Was ist ein Bereitstellungs-Archetyp?
Ein Bereitstellungs-Archetyp ist ein abstraktes, anbieterunabhängiges Modell, das Sie als Grundlage für die Erstellung anwendungsspezifischer Bereitstellungsarchitekturen verwenden, die Ihre geschäftlichen und technischen Anforderungen erfüllen. Jeder Bereitstellungs-Archetyp gibt eine Kombination aus fehlerhaften Domains an, in denen eine Anwendung ausgeführt werden kann. Diese fehlerhaften Domains können eine oder mehrere Google Cloud-Zonen oder -Regionen und sogar Ihre lokalen Rechenzentren oder fehlerhaften Domains bei anderen Cloud-Anbietern umfassen.
Das folgende Diagramm zeigt sechs in Google Cloud bereitgestellte Anwendungen. Jede Anwendung verwendet einen Bereitstellungs-Archetyp, der die spezifischen Anforderungen erfüllt.
Wie das obige Diagramm zeigt, basiert die Cloud-Topologie in einer Architektur mit dem Archetyp für hybride oder Multi-Cloud-Bereitstellungen auf einem der grundlegenden Archetypen: zonal, regional, multiregional oder global. In diesem Sinne können die Archetypen für hybride und Multi-Cloud-Bereitstellungen als zusammengesetzte Archetypen betrachtet werden, die einen der grundlegenden Archetypen enthalten.
Die Auswahl eines Bereitstellungs-Archetyps vereinfacht nachfolgende Entscheidungen in Bezug auf zu verwendende Google Cloud-Produkte und -Features. Wenn Sie beispielsweise bei einer hochverfügbaren containerisierten Anwendung den Archetyp für regionale Bereitstellungen auswählen, sind regionale GKE-Cluster (Google Kubernetes Engine) besser geeignet als zonale GKE-Cluster.
Wenn Sie einen Bereitstellungs-Archetyp für eine Anwendung auswählen, müssen Sie Kompromisse zwischen Faktoren wie Verfügbarkeit, Kosten und operative Komplexität berücksichtigen. Wenn eine Anwendung beispielsweise Nutzer in mehreren Ländern bedient und Hochverfügbarkeit benötigt, wählen Sie den Archetyp für multiregionale Bereitstellungen. Bei einer internen Anwendung, die von Mitarbeitern in einer einzelnen geografischen Region verwendet wird, priorisieren Sie jedoch möglicherweise die Kosten gegenüber der Verfügbarkeit und wählen daher den Archetyp für regionale Bereitstellungen.
Übersicht über Bereitstellungs-Archetypen
Die folgenden Tabs enthalten Definitionen der Bereitstellungs-Archetypen und eine Zusammenfassung der Anwendungsfälle sowie Designaspekte.
Zonal
Ihre Anwendung wird in einer einzelnen Google Cloud-Zone ausgeführt, wie im folgenden Diagramm dargestellt:
Anwendungsfälle |
|
---|---|
Designaspekte |
|
Weitere Informationen | Weitere Informationen finden Sie in den folgenden Abschnitten: |
Regional
Ihre Anwendung wird unabhängig in zwei oder mehr Zonen innerhalb einer einzelnen Google Cloud-Region ausgeführt, wie im folgenden Diagramm dargestellt:
Anwendungsfälle |
|
---|---|
Designaspekte |
|
Weitere Informationen | Weitere Informationen finden Sie in den folgenden Abschnitten: |
Multiregional
Ihre Anwendung wird unabhängig in mehreren Zonen in zwei oder mehr Google Cloud-Regionen ausgeführt. Sie können DNS-Routingrichtlinien verwenden, um eingehenden Traffic an die regionalen Load Balancer weiterzuleiten. Die regionalen Load Balancer verteilen den Traffic dann auf die zonalen Replikate der Anwendung, wie im folgenden Diagramm dargestellt:
Anwendungsfälle |
|
---|---|
Designaspekte |
|
Weitere Informationen | Weitere Informationen finden Sie in den folgenden Abschnitten: |
Global
Ihre Anwendung wird weltweit in Google Cloud-Regionen ausgeführt, entweder als global verteiltes (standortunabhängiges) Paket oder als regional isolierte Pakete. Ein globaler Anycast-Load-Balancer verteilt den Traffic auf die Region, die dem Nutzer am nächsten ist. Andere Komponenten des Anwendungspakets können ebenfalls global sein, wie z. B. die Datenbank, der Cache und der Objektspeicher.
Das folgende Diagramm zeigt die global verteilte Variante des Archetyps für globale Bereitstellungen. Ein globaler Anycast-Load-Balancer leitet Anfragen an ein Anwendungspaket weiter, das auf mehrere Regionen verteilt ist und eine global replizierte Datenbank verwendet.
Das folgende Diagramm zeigt eine Variante des Archetyps für globale Bereitstellungen mit regional isolierten Anwendungspaketen. Ein globaler Anycast-Load-Balancer leitet Anfragen an ein Anwendungspaket in einer der Regionen weiter. Alle Anwendungspakete verwenden eine einzige global replizierte Datenbank.
Anwendungsfälle |
|
---|---|
Designaspekte | Kosten für die regionenübergreifende Datenübertragung und Datenreplikation. |
Weitere Informationen | Weitere Informationen finden Sie in den folgenden Abschnitten: |
Hybrid
Bestimmte Teile Ihrer Anwendung werden in Google Cloud bereitgestellt, während andere lokal ausgeführt werden. Dies ist im folgenden Diagramm dargestellt. Die Topologie in Google Cloud kann den Archetyp für zonale, regionale, multiregionale oder globale Bereitstellungen verwenden.
Anwendungsfälle |
|
---|---|
Designaspekte |
|
Weitere Informationen | Weitere Informationen finden Sie in den folgenden Abschnitten: |
Multi-Cloud
Einige Teile Ihrer Anwendung werden in Google Cloud und andere auf anderen Cloud-Plattformen bereitgestellt, wie im folgenden Diagramm dargestellt. Die Topologie auf jeder Cloud-Plattform kann den Archetyp für zonale, regionale, multiregionale oder globale Bereitstellungen verwenden.
Anwendungsfälle |
|
---|---|
Designaspekte |
|
Weitere Informationen | Weitere Informationen finden Sie in den folgenden Abschnitten: |
Beitragende
Autor: Kumar Dhanagopal | Cross-product Solution Developer
Weitere Beitragende:
- Anna Berenberg | Engineering Fellow
- Anshu Kak | Distinguished Engineer
- Jeff Welsch | Director, Produktmanagement
- Marwan Al Shawi | Partner Customer Engineer
- Sekou Page | Outbound Product Manager
- Steve McGhee | Reliability Advocate
- Victor Moreno | Product Manager, Cloud Networking
-
Anna Berenberg und Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Band 55, Ausgabe 3, Artikelnr.: 61, Seiten 1-48 ↩