Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Last reviewed 2024-11-20 UTC
Wenn Sie als Cloud Architect 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 Fehlerdomains können eine oder mehrere Google Cloud -Zonen oder -Regionen und sogar Ihre lokalen Rechenzentren oder Fehlerdomains bei anderen Cloud-Anbietern umfassen.
Das folgende Diagramm zeigt sechs Anwendungen, die in Google Cloudbereitgestellt werden.
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 ‑Funktionen. 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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-11-20 (UTC)."],[[["\u003cp\u003eThis guide defines six deployment archetypes—zonal, regional, multi-regional, global, hybrid, and multicloud—for applications in Google Cloud.\u003c/p\u003e\n"],["\u003cp\u003eA deployment archetype is a provider-independent model serving as the foundation for application-specific deployment architectures, dictating where an application can run across various failure domains.\u003c/p\u003e\n"],["\u003cp\u003eChoosing an appropriate deployment archetype involves evaluating trade-offs among factors like availability, cost, performance, and operational complexity based on specific application requirements.\u003c/p\u003e\n"],["\u003cp\u003eHybrid and multicloud archetypes are composite models that build upon basic archetypes like zonal, regional, multi-regional, or global.\u003c/p\u003e\n"],["\u003cp\u003eEach archetype has specific use cases and design considerations, including factors such as high availability, disaster recovery, latency, data residency, and cost optimization.\u003c/p\u003e\n"]]],[],null,["# Google Cloud deployment archetypes\n\nAs a cloud architect or decision maker, when you plan to deploy an application\nin Google Cloud, you need to choose a *deployment archetype* ^[1](#fn1)^ that's suitable\nfor your application. This guide describes six deployment\narchetypes---zonal, regional, multi-regional, global, hybrid, and\nmulticloud, and presents use cases and design considerations for each deployment\narchetype. The guide also provides a comparative analysis to help you choose the\ndeployment archetypes that meet your requirements for availability, cost,\nperformance, and operational efficiency.\n\nWhat is a deployment archetype?\n-------------------------------\n\nA deployment archetype is an abstract, provider-independent model that you use\nas the foundation to build application-specific *deployment architectures* that\nmeet your business and technical requirements. Each deployment archetype\nspecifies a combination of failure domains where an application can run. These\nfailure domains can be one or more\n[Google Cloud zones or regions](/architecture/infra-reliability-guide/building-blocks#regions_and_zones),\nand they can extend to include your on-premises data centers or failure domains\nin other cloud providers.\n\nThe following diagram shows six applications deployed in Google Cloud.\nEach application uses a deployment archetype that meets its specific\nrequirements.\n\nAs the preceding diagram shows, in an architecture that uses the hybrid or\nmulticloud deployment archetype, the cloud topology is based on one of the\n*basic* archetypes: zonal, regional, multi-regional, or global. In this sense,\nthe hybrid and multicloud deployment archetypes can be considered as *composite*\ndeployment archetypes that include one of the basic archetypes.\n| **Note:** Deployment archetypes are different from [location scopes](/architecture/infra-reliability-guide/building-blocks#location_scopes). The location scope of a Google Cloud resource defines its availability boundary. For example, the location scope of a Compute Engine VM is *zonal* . This means that if the Google Cloud zone in which a VM is provisioned has an outage, the availability of the VM is affected. However, by distributing VMs across multiple zones, you can build a highly available architecture that's based on the *regional* deployment archetype.\n\nChoosing a deployment archetype helps to simplify subsequent decisions regarding\nthe Google Cloud products and features that you should use. For example,\nfor a highly available containerized application, if you choose the regional\ndeployment archetype, then regional Google Kubernetes Engine (GKE) clusters are\nmore appropriate than zonal GKE clusters.\n\nWhen you choose a deployment archetype for an application, you need to consider\ntradeoffs between factors like availability, cost, and operational complexity.\nFor example, if an application serves users in multiple countries and needs high\navailability, you might choose the multi-regional deployment archetype. But for\nan internal application that's used by employees in a single geographical\nregion, you might prioritize cost over availability and, therefore, choose the\nregional deployment archetype.\n\nOverview of the deployment archetypes\n-------------------------------------\n\nThe following tabs provide definitions for the deployment archetypes and a\nsummary of the use cases and design considerations for each. \n\n### Zonal\n\nYour application runs within a single Google Cloud zone, as shown in\nthe following diagram:\n\n### Regional\n\nYour application runs independently in two or more zones within a single\nGoogle Cloud region, as shown in the following diagram:\n\n### Multi-regional\n\nYour application runs independently in multiple zones across two or more\nGoogle Cloud regions. You can use [DNS routing policies](/dns/docs/policies-overview#routing_policies) to route\nincoming traffic to the regional load balancers. The regional load balancers\nthen distribute the traffic to the zonal replicas of the application, as shown\nin the following diagram:\n\n### Global\n\nYour application runs across Google Cloud\nregions worldwide, either as a globally distributed (location-unaware) stack or\nas regionally isolated stacks. A global [anycast](https://wikipedia.org/wiki/Anycast) load\nbalancer distributes traffic to the region that's nearest to the user. Other\ncomponents of the application stack can also be global, such as the database,\ncache, and object store.\n\nThe following diagram shows the globally distributed variant of the global\ndeployment archetype. A global anycast load balancer forwards requests to an\napplication stack that's distributed across multiple regions and that uses a\nglobally replicated database.\n\nThe following diagram shows a variant of the global deployment archetype with\nregionally isolated application stacks. A global anycast load balancer forwards\nrequests to an application stack in one of the regions. All the application\nstacks use a single, globally replicated database.\n\n### Hybrid\n\nCertain parts of your application are deployed in Google Cloud,\nwhile other parts run on-premises, as shown in the following diagram. The\ntopology in Google Cloud can use the zonal, regional, multi-regional, or\nglobal deployment archetype.\n\n### Multicloud\n\nSome parts of your application are deployed in Google Cloud, and\nother parts are deployed in other cloud platforms, as shown in the following\ndiagram. The topology in each cloud platform can use the zonal, regional,\nmulti-regional, or global deployment archetype.\n\nContributors\n------------\n\nAuthor: [Kumar Dhanagopal](https://www.linkedin.com/in/kumardhanagopal) \\| Cross-Product Solution Developer\n\nOther contributors:\n\n- [Anna Berenberg](https://www.linkedin.com/in/annaberenberg) \\| Engineering Fellow\n- [Anshu Kak](https://www.linkedin.com/in/anshu-kak-26654a) \\| Distinguished Engineer\n- [Jeff Welsch](https://www.linkedin.com/in/jeffwelsch) \\| Director, Product Management\n- [Marwan Al Shawi](https://www.linkedin.com/in/marwanalshawi) \\| Partner Customer Engineer\n- [Sekou Page](https://www.linkedin.com/in/sekoupage) \\| Outbound Product Manager\n- [Steve McGhee](https://www.linkedin.com/in/stevemcghee) \\| Reliability Advocate\n- [Victor Moreno](https://www.linkedin.com/in/vimoreno) \\| Product Manager, Cloud Networking\n\n\u003cbr /\u003e\n\n*** ** * ** ***\n\n1. Anna Berenberg and Brad Calder, [Deployment Archetypes for Cloud Applications](https://dl.acm.org/doi/10.1145/3498336), ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 [↩](#fnref1)"]]
