Regionen und Zonen

Compute Engine-Ressourcen werden weltweit an mehreren Standorten gehostet. Diese Standorte setzen sich aus Regionen und Zonen zusammen. Eine Region ist ein bestimmter Ort, an dem Sie Ihre Ressourcen hosten können. Regionen haben mindestens drei Zonen. Beispiel: Die Region us-west1 bezeichnet eine Region an der Westküste der USA mit drei Zonen: us-west1-a, us-west1-b und us-west1-c.

Ressourcen, die sich in einer Zone befinden, wie Instanzen virtueller Maschinen oder zonale nichtflüchtige Speicher, werden als zonale Ressourcen bezeichnet. Andere Ressourcen wie statische externe IP-Adressen sind regional. Regionale Ressourcen können von jeder Ressource in dieser Region unabhängig von der Zone genutzt werden, während zonale Ressourcen nur von anderen Ressourcen in derselben Zone genutzt werden können.

Wenn Sie beispielsweise einen zonalen nichtflüchtigen Speicher an eine Instanz anhängen möchten, müssen sich beide Ressourcen in derselben Zone befinden. Wenn Sie einer Instanz eine statische IP-Adresse zuweisen möchten, muss sich die Instanz in derselben Region wie die statische IP-Adresse befinden.

Wenn sich Ressourcen in verschiedenen Zonen in einer Region befinden, sind sie gegen die meisten Arten von Fehlern bei Infrastruktur- und Infrastruktursoftwarediensten geschützt. Das Anlegen von Ressourcen in unterschiedlichen Regionen sorgt für einen noch höheren Grad der Fehlerunabhängigkeit. Auf diese Weise können Sie zuverlässige Systeme mit Ressourcen konzipieren, die über verschiedene Fehlerdomains verteilt sind.

Nur bestimmte Ressourcen sind regions- oder zonenspezifisch. Andere Ressourcen wie Images sind globale Ressourcen, die von allen anderen Ressourcen an jedem Ort eingesetzt werden können. Weitere Informationen zu globalen, regionalen und zonalen Compute Engine-Ressourcen finden Sie unter Globale, regionale und zonale Ressourcen.

Zonen und Cluster

Compute Engine implementiert eine Abstraktionsebene zwischen Zonen und den physischen Clustern, auf denen die Zonen gehostet werden. Ein Cluster stellt eine bestimmte physische Infrastruktur dar, die sich in einem Rechenzentrum befindet. Jeder Cluster hat eigene unabhängige Strukturen für Software, Energieversorgung, Kühlung, Netzwerk und Sicherheit und umfasst einen großen Pool an Rechen- und Speicherressourcen.

Jede Zone wird in einem oder mehreren Clustern gehostet. Compute Engine ordnet eigenständig Zonen für jede Organisation Clustern zu. Beispiel: Die Zone us-central1-a für Ihre Organisation wird möglicherweise nicht demselben Cluster zugeordnet wie die Zone us-central1-a für eine andere Organisation.

Das Entkoppeln von Zonen und Clustern bietet Ihnen und Compute Engine viele Vorteile:

  • Compute Engine kann dafür sorgen, dass die Ressourcen in den Clustern einer Region gleichmäßig ausgelastet werden.
  • Die Liste der Zonen, aus denen Sie auswählen können, bleibt überschaubar, da Compute Engine im Laufe der Zeit immer mehr Cluster hinzufügt und die Regionen so erweitert.

Für die meisten Organisationen stellt Compute Engine sicher, dass für alle Projekte in einer Organisation Zonen konsistent zu Clustern zugeordnet sind. Werden die Netzwerke oder Dienste in den Projekten der Organisation über VPC-Netzwerk-Peering oder per Zugriff auf private Dienste freigegeben, sorgt Compute Engine dafür, dass alle Peer-Organisationen eine konsistente Zuordnung von Zonen zu Clustern haben. Beispielsweise kann Compute Engine für große SaaS-Anbieter eventuell keine konsistente Zuordnung für alle Peer-Organisationen bereitstellen. In diesen Fällen sorgt Compute Engine dafür, dass die Peer-Projekte eine konsistente Zuordnung von Zonen zu Clustern haben.

Region und Zone auswählen

Sie wählen aus, in welcher Region oder Zone Ihre Ressourcen gehostet werden. Dadurch wird gesteuert, wo Ihre Daten gespeichert und verwendet werden. Die Auswahl einer Region und Zone ist aus folgenden Gründen wichtig:

Fehlerbehandlung
Verteilen Sie Ihre Ressourcen über mehrere Zonen und Regionen, um Ausfälle abzufangen. Google entwickelt Zonen so, dass sie unabhängig voneinander sind: Eine Zone verfügt in der Regel über Strom, Kühlung, ein Netzwerk und Steuerungsebenen, die von anderen Zonen isoliert sind. So wirken sich die meisten auftretenden Einzelfehler nur auf eine einzige Zone aus. Wenn eine Zone nicht mehr verfügbar ist, können Sie den Traffic in eine andere Zone in derselben Region verlagern, um Ihre Dienste weiter bereitzustellen. Falls in einer Region Störungen auftreten, sollten in einer anderen Region Sicherungsdienste betriebsbereit sein. Weitere Informationen über die Verteilung Ihrer Ressourcen und die Entwicklung eines robusten Systems finden Sie unter Robuste Systeme konzipieren.
Geringere Netzwerklatenz
Wenn Sie die Netzwerklatenz verringern möchten, sollten Sie eine Region oder Zone auswählen, die sich in der Nähe Ihres Bereitstellungsorts befindet. Wenn Sie beispielsweise vor allem Kunden an der Ostküste der USA haben, sollten Sie möglichst eine Primärregion und -zone wählen, die sich in der Nähe dieses Bereichs befinden. Ihre Sicherungsregion und -zone sollten ebenfalls in der Nähe sein.

Region oder Zone identifizieren

Jede Region in Compute Engine enthält eine Reihe von Zonen. Jeder Zonenname besteht aus zwei Teilen, die jede Zone im Detail beschreiben. Der erste Teil des Zonennamens ist die Region und der zweite Teil des Namens beschreibt die Zone innerhalb der Region:

  • Region

    Regionen sind Sammlungen von Zonen. Zonen verfügen über Netzwerkverbindungen mit hoher Bandbreite und geringer Latenz zu anderen Zonen in derselben Region. Zum Bereitstellen fehlertoleranter Anwendungen mit hoher Verfügbarkeit empfiehlt Google, die Anwendungen in mehreren Zonen und mehreren Regionen bereitzustellen. Dies dient als Schutzmaßnahme gegen unerwartete Ausfälle von Komponenten in einer einzelnen Zone oder Region.

    Wählen Sie Regionen, die für Ihr Szenario sinnvoll sind. Wenn Sie z. B. nur Kunden in den USA haben oder Ihre Daten in den USA gespeichert werden müssen, ist es sinnvoll, Ihre Ressourcen in Zonen der Region us-central1 oder us-east1 zu speichern.

  • Zone

    Eine Zone ist ein isolierter Ort innerhalb einer Region. Der vollständig qualifizierte Name für eine Zone setzt sich aus <region>-<zone> zusammen. Der vollständig qualifizierte Name für Zone a in der Region us-central1 ist beispielsweise us-central1-a.

    Je nachdem, wie weit Sie Ihre Ressourcen verteilen möchten, erstellen Sie zum Zweck der Redundanz Instanzen in mehreren Zonen mehrerer Regionen.

Verfügbare Regionen und Zonen

In der folgenden sortierbaren Tabelle können Sie verschiedene Optionen auswählen, um zu sehen, wo Ressourcen verfügbar sind. Sie können beispielsweise im Drop-down-Menü Standort auswählen die Option Europe und im Drop-down-Menü Maschinentyp auswählen die Option M2 auswählen, um eine Liste der Zonen anzeigen zu lassen, in denen M2-Maschinen in Europa verfügbar sind.

Jede Zone unterstützt eine Kombination der Plattformen Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake und Cascade Lake sowie die AMD EPYC Rome-Plattform. Wenn Sie eine Instanz in einer Zone erstellen, verwendet die Instanz den in dieser Zone unterstützten Standardprozessor. Beispiel: Sie erstellen eine Instanz in der Zone us-central1-a. Ihre Instanz verwendet dann standardmäßig einen Haswell-Prozessor, sofern Sie keine andere Option angeben.

Alternativ können Sie Ihre gewünschte CPU-Plattform auswählen. Weitere Informationen finden Sie unter Minimale CPU-Plattform für VM-Instanzen angeben.

Zonen Speicherort Maschinentypen CPUs Ressourcen
asia-east1-a Changhua County, Taiwan, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east1-b Changhua County, Taiwan, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east1-c Changhua County, Taiwan, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east2-a
asia-east2-b
asia-east2-c
Hongkong, APAC E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-a Tokio, Japan, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-northeast1-b Tokio, Japan, APAC E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-c Tokio, Japan, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
Osaka, Japan, APAC E2, N1 Skylake
asia-northeast3-a
asia-northeast3-b
asia-northeast3-c
Seoul, Südkorea, APAC E2, N1, C2 Skylake
asia-south1-a Mumbai, Indien, APAC E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-south1-b Mumbai, Indien, APAC E2, N1, M2, M1 Broadwell, Skylake GPUs
asia-south1-c Mumbai, Indien, APAC E2, N1, M1 Broadwell, Skylake
asia-southeast1-a Jurong West, Singapur, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
asia-southeast1-b Jurong West, Singapur, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-southeast1-c Jurong West, Singapur, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-southeast2-a
asia-southeast2-b
asia-southeast2-c
Jakarta, Indonesien, APAC E2, N1 Skylake
australia-southeast1-a Sydney, Australien, APAC E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake
australia-southeast1-b Sydney, Australien, APAC E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake GPUs
australia-southeast1-c Sydney, Australien, APAC E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
europe-north1-a Hamina, Finnland, Europa E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake
europe-north1-b Hamina, Finnland, Europa E2, N1, C2 Broadwell, Skylake
europe-north1-c Hamina, Finnland, Europa E2, N1, C2 M1 Broadwell, Skylake
europe-west1-b St. Ghislain, Belgien, Europa E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west1-c St. Ghislain, Belgien, Europa E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
europe-west1-d St. Ghislain, Belgien, Europa E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west2-a London, England, Europa E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west2-b London, England, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west2-c London, England, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-a Frankfurt, Deutschland, Europa E2, N2, N1, M1, M2, C2 Broadwell, Skylake, Cascade Lake
europe-west3-b Frankfurt, Deutschland, Europa E2, N2, N1, M1, M2, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west3-c Frankfurt, Deutschland, Europa E2, N1, M1 Broadwell, Skylake
europe-west4-a Eemshaven, Niederlande, Europa E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west4-b Eemshaven, Niederlande, Europa E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west4-c Eemshaven, Niederlande, Europa E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west6-a
europe-west6-b
europe-west6-c
Zürich, Schweiz, Europa E2, N1 Skylake
northamerica-northeast1-a Montreal, Québec, Nordamerika E2, N2, N1 Broadwell, Skylake, Cascade Lake GPUs
northamerica-northeast1-b Montreal, Québec, Nordamerika E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
northamerica-northeast1-c Montreal, Québec, Nordamerika E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
southamerica-east1-a Osasco, São Paulo, Brasilien, Südamerika E2, N2, N1 Broadwell, Skylake, Cascade Lake
southamerica-east1-b Osasco, São Paulo, Brasilien, Südamerika E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
southamerica-east1-c Osasco, São Paulo, Brasilien, Südamerika E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-central1-a Council Bluffs, Iowa, Nordamerika E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-central1-b Council Bluffs, Iowa, Nordamerika E2, N2, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake GPUs
us-central1-c Council Bluffs, Iowa, Nordamerika E2, N2, N2D, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-central1-f Council Bluffs, Iowa, Nordamerika E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-b Moncks Corner, South Carolina, Nordamerika E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-c Moncks Corner, South Carolina, Nordamerika E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-d Moncks Corner, South Carolina, Nordamerika E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-a Ashburn, Virginia, Nordamerika E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-b Ashburn, Virginia, Nordamerika E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-c Ashburn, Virginia, Nordamerika E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west1-a The Dalles, Oregon, Nordamerika E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west1-b The Dalles, Oregon, Nordamerika E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-west1-c The Dalles, Oregon, Nordamerika E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
us-west2-a Los Angeles, Kalifornien, Nordamerika E2, N1, M2, C2 Broadwell, Skylake, Cascade Lake
us-west2-b Los Angeles, Kalifornien, Nordamerika E2, N1, M1 Broadwell, Skylake GPUs
us-west2-c Los Angeles, Kalifornien, Nordamerika E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west3-a
us-west3-b
us-west3-c
Salt Lake City, Utah, Nordamerika E2, N1 Skylake
us-west4-a
us-west4-b
us-west4-c
Las Vegas, Nevada, Nordamerika E2, N2, N1 Skylake, Cascade Lake

Angekündigte Regionen

2021 wird Google die folgenden neuen Regionen einführen:

  • Warschau, Polen

Transparente Wartung

Google führt regelmäßig Wartungsarbeiten an der Infrastruktur durch. Dabei werden aktuelle Software-Patches eingespielt, Routinetests durchgeführt und vorbeugende Wartungsaufgaben ausgeführt. Es wird insgesamt sichergestellt, dass die Google-Infrastruktur so schnell und effizient arbeitet, wie es Google möglich ist.

Standardmäßig werden alle Instanzen so konfiguriert, dass diese Wartungsarbeiten für Ihre Anwendungen und Arbeiten erkennbar sind. Google verwendet eine Kombination aus Innovationen in Rechenzentren, operativen Best Practices und Technologien für die Live-Migration, um laufende Wartungsprozesse außerhalb aktiver VM-Instanzen durchzuführen. Ihre Instanz wird weiterhin in derselben Zone ausgeführt, ohne dass Sie etwas unternehmen müssen.

Standardmäßig sind alle virtuellen Maschinen auf Live-Migration eingestellt. Sie können Ihre VMs jedoch auch so einrichten, dass sie beendet und neu gestartet werden. Diese beiden Optionen unterscheiden sich so:

  • Live-Migration

    Compute Engine migriert automatisch Ihre laufende Instanz. Der Migrationsprozess wird sich in einem gewissen Umfang auf die Gast-Performance auswirken, aber Ihre Instanz bleibt während des gesamten Migrationsprozesses online. Die tatsächliche Auswirkung auf die Gast-Performance und die Dauer hängen von vielen Faktoren ab, doch dürften sich für die meisten Anwendungen und Arbeitslasten keine spürbaren Folgen ergeben. Weitere Informationen finden Sie unter Live-Migration.

  • Beenden und neu starten

    Compute Engine gibt Ihrer Instanz automatisch das Signal zum Herunterfahren, wartet dann eine kurze Zeit, bis die Instanz sauber heruntergefahren ist, und startet sie unabhängig vom Wartungsereignis neu.

Weitere Informationen darüber, wie Sie die oben genannten Optionen für Ihre Instanzen einstellen können, finden Sie unter Zeitplanoptionen für Instanzen festlegen.

Zonen verwerfen

Es ist nie erforderlich, eine bestehende Zone außer Betrieb zu nehmen, um eine grundlegende Aktualisierung der Infrastruktur (Stromversorgung, Kühlung, Netzwerkstruktur, Server usw.) durchzuführen. Infrastrukturaktualisierungen kommen nur selten vor. Zonen bleiben in der Regel drei bis fünf Jahre in Betrieb, bevor eine Aktualisierung nötig wird. Solche Aktualisierungen sollten für den Kunden transparent sein.

Falls es doch einmal nötig werden sollte, eine Zone außer Betrieb zu nehmen, werden die Nutzer von Compute Engine rechtzeitig im Voraus über den Zeitpunkt der Außerbetriebnahme informiert, sodass genug Zeit bleibt, die betroffenen VM-Instanzen und Arbeitslasten zu verlagern.

Kontingente

Für bestimmte Ressourcen wie statische IP-Adressen, Images, Firewallregeln und VPC-Netzwerke sind Kontingentgrenzen pro Projekt und Kontingentgrenzen pro Region definiert. Wenn Sie diese Ressourcen erstellen, wird dies auf Ihr Gesamtkontingent für das Projekt bzw. auf Ihr Gesamtkontingent für die Region angerechnet. Wird eine der betroffenen Kontingentgrenzen überschritten, können Sie keine weiteren Ressourcen des gleichen Typs in dem Projekt oder der Region hinzufügen.

Eine umfassende Liste der Kontingente für Ihr Projekt finden Sie auf der Seite Kontingente in der Google Cloud Console.

Wenn Ihr Kontingent für globale Zielpools beispielsweise 50 Pools beträgt und Sie 25 Zielpools in beispiel-region-1 und 25 Zielpools in beispiel-region-2 erstellen, ist Ihr projektbezogenes Kontingent damit ausgeschöpft. Sie können dann erst weitere Zielpools in Regionen innerhalb Ihres Projekts erstellen, nachdem Sie weiteren Speicherplatz freigegeben haben. Wenn Sie mit einem Kontingent von 7 reservierten IP-Adressen pro Region arbeiten, können Sie in einer einzigen Region höchstens 7 IP-Adressen reservieren. Sobald dieses Limit erreicht ist, müssen Sie entweder IP-Adressen in einer neuen Region reservieren oder einige der reservierten IP-Adressen freigeben.

Tipps

Folgende Punkte sollten Sie bei der Auswahl von Zonen beachten:

  • Bei der Kommunikation innerhalb von Regionen und der regionenübergreifenden Kommunikation entstehen unterschiedliche Kosten.

    Im Allgemeinen ist die Kommunikation innerhalb von Regionen kostengünstiger und schneller als die regionenübergreifende Kommunikation.

  • Zonenübergreifende Redundanz für wichtige Systeme einplanen.

    Es ist nicht auszuschließen, dass in Ihren Instanzen unerwartete Fehler auftreten. Sie sollten wichtige Systeme in mehreren Zonen und Regionen duplizieren, um die Auswirkungen solcher potenziellen Ereignisse abzumildern.

    Wenn Sie zum Beispiel Instanzen in den Zonen europe-west1-b und europe-west1-c hosten und europe-west1-b ausfällt, sind Ihre Instanzen in Zone europe-west1-c weiterhin verfügbar. Wenn Sie jedoch alle Instanzen in europe-west1-b hosten, können Sie bei einem Ausfall von europe-west1-b auf keine Ihrer Instanzen zugreifen. Außerdem können Sie Ihre Ressourcen in verschiedenen Regionen hosten. Beispiel: Für den unwahrscheinlichen Fall, dass es in der Region europe-west1 zu einem Ausfall kommt, kann es sinnvoll sein, Sicherungsinstanzen in einer Zone in der Region europe-west3 zu hosten. Weitere Tipps zur Entwicklung von Systemen für verbesserte Verfügbarkeit finden Sie unter Robuste Systeme konzipieren.

Weitere Informationen