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. Jede Region hat eine oder mehrere Zonen, die meisten Regionen haben drei oder mehr Zonen. Die Region us-west1 bezeichnet zum Beispiel 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 zonaler nichtflüchtiger Speicher, werden als zonale Ressourcen bezeichnet. Andere Ressourcen wie statische externe IP-Adressen sind regional. Regionale Ressourcen können von allen Ressourcen in der Region unabhängig von der Zone genutzt werden, während zonale Ressourcen nur von anderen Ressourcen in der gleichen 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 ist 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. Bei Organisationen mit Projekten, die VPC-Netzwerk-Peering oder Zugriff auf private Dienste zum Freigeben von Netzwerken und Diensten für andere Organisationen verwenden, sorgt Compute Engine dafür, dass für alle diese Peer-Organisationen Zonen konsistent Clustern zugeordnet sind. 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.

Standorte

In der folgenden Tabelle sind die Standorte aller Compute Engine-Regionen und die zugehörigen Zonen aufgeführt. Eine vollständige Beschreibung der in einzelnen Zonen verfügbaren Maschinentypen und Features finden Sie im Abschnitt Verfügbare Regionen und Zonen.

Region Zonen Standort
asia-east1 a, b, c Bezirk Changhua, Taiwan
asia-east2 a, b, c Hongkong
asia-northeast1 a, b, c Tokio, Japan
asia-northeast2 a, b, c Osaka, Japan
asia-south1 a, b, c Mumbai, Indien
asia-southeast1 a, b, c Jurong West, Singapur
australia-southeast1 a, b, c Sydney, Australien
europe-north1 a, b, c Hamina, Finnland
europe-west1 b, c, d St. Ghislain, Belgien
europe-west2 a, b, c London, England, Großbritannien
europe-west3 a, b, c Frankfurt, Deutschland
europe-west4 a, b, c Eemshaven, Niederlande
europe-west6 a, b, c Zürich, Schweiz
northamerica-northeast1 a, b, c Montréal, Québec, Kanada
southamerica-east1 a, b, c Osasco (São Paulo), Brasilien
us-central1 a, b, c, f Council Bluffs, Iowa, USA
us-east1 b, c, d Moncks Corner, South Carolina, USA
us-east4 a, b, c Ashburn, Nord Virginia, USA
us-west1 a, b, c The Dalles, Oregon, USA
us-west2 a, b, c Los Angeles, Kalifornien, USA

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 zum Beispiel nur Kunden in den USA haben oder spezielle Anforderungen, die es erforderlich machen, dass sich Ihre Daten in den USA befinden, ist es sinnvoll, Ihre Ressourcen in den 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 besteht aus <region>-<zone>. Beispiel: Der vollständig qualifizierte Name für Zone a in der Region us-central1 lautet 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 Tabelle werden die Region, ihr Standort, die verfügbaren Zonen in dieser Region sowie die in dieser Region verfügbaren Features aufgelistet.

Jede Zone unterstützt eine Kombination der Plattformen Ivy Bridge, Sandy Bridge, Haswell, Broadwell und Skylake. Wenn Sie eine Instanz in der Zone erstellen, verwendet die Instanz den in dieser Zone unterstützten Standardprozessor. Wenn Sie beispielsweise eine Instanz in der Zone us-central1-a erstellen, wird die Instanz einen Sandy-Bridge-Prozessor verwenden.

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

Name der Region Beschreibung der Region Standort Zonen Merkmale
asia-east1 Taiwan Bezirk Changhua, Taiwan asia-east1-a
asia-east1-b
asia-east1-c
asia-east2 Hongkong Hongkong
  • asia-east2-a
  • asia-east2-b
  • asia-east2-c
asia-northeast1 Tokio Tokio, Japan asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-northeast2 Osaka Osaka, Japan
  • asia-northeast2-a
  • asia-northeast2-b
  • asia-northeast2-c
asia-south1 Mumbai Mumbai, Indien
  • asia-south1-a
  • asia-south1-c
asia-south1-b
asia-southeast1 Singapur Jurong West, Singapur
  • asia-southeast1-a
  • asia-southeast1-b
  • asia-southeast1-c
australia-southeast1 Sydney Sydney, Australien
  • australia-southeast1-a
  • australia-southeast1-b
  • australia-southeast1-c
europe-north1 Irland Hamina, Finnland
  • europe-north1-a
  • europe-north1-b
  • europe-north1-c
europe-west1 Belgien St. Ghislain, Belgien europe-west1-b
europe-west1-c
europe-west1-d
europe-west2 London London, England, Großbritannien
  • europe-west2-a
  • europe-west2-c
europe-west2-b
europe-west3 Frankfurt Frankfurt, Deutschland
  • europe-west3-a
  • europe-west3-b
    europe-west3-c
europe-west4 Moldau Eemshaven, Niederlande
  • europe-west4-a
  • europe-west4-b
  • europe-west4-c
europe-west6 Zürich Zürich, Schweiz
  • europe-west6-a
  • europe-west6-b
  • europe-west6-c
northamerica-northeast1 Montréal Montréal, Québec, Kanada
  • northamerica-northeast1-a
  • northamerica-northeast1-b
  • northamerica-northeast1-c
southamerica-east1 Osasco Osasco, São Paulo, Brasilien
  • southamerica-east1-a
southamerica-east1-b
southamerica-east1-c
us-central1 Iowa Council Bluffs, Iowa, USA us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-east1 South Carolina Moncks Corner, South Carolina, USA us-east1-b
    us-east1-c
    us-east1-d
us-east4 Nord Virginia Ashburn, Virginia, USA
  • us-east4-a
  • us-east4-b
  • us-east4-c
us-west1 Oregon The Dalles, Oregon, USA us-west1-a
us-west1-b
us-west1-c
us-west2 Los Angeles Los Angeles, Kalifornien, USA us-west2-a
us-west2-b
us-west2-c

Angekündigte Regionen

2019 und 2020 wird Google die folgenden Regionen einführen:

  • Zürich (Schweiz) Gestartet!
  • Osaka (Japan) Gestartet!
  • Seoul, Südkorea
  • Salt Lake City, Utah, USA
  • Las Vegas, Nevada, USA
  • Jakarta, Indonesien

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.

Für alle virtuellen Maschinen wird standardmäßig die Live-Migration aktiviert. Sie können Ihre virtuellen Maschinen jedoch auch so einstellen, dass sie beendet und neu gestartet werden. Diese beiden Optionen unterscheiden sich wie folgt:

  • 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.

Außerbetriebnahme von Zonen

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, die für Ihr Projekt gelten, finden Sie auf der Seite Kontingente der Google Cloud Platform 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 diese Grenze 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 können. 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 in europe-west1-b ein unerwarteter Fehler auftritt, sind Ihre Instanzen in der Zone europe-west1-c weiterhin verfügbar. Wenn Sie jedoch alle Instanzen in europe-west1-b hosten, können Sie auf keine der Instanzen zugreifen, wenn europe-west1-b offline geht. Außerdem können Sie Ihre Ressourcen in verschiedenen Regionen hosten. In dem unwahrscheinlichen Fall, dass in der Region europe-west1 ein Fehler auftritt, können Sie beispielsweise Sicherungsinstanzen in einer Zone in der Region europe-west3 hosten. Weitere Tipps zum Konzipieren von Systemen für bessere Verfügbarkeit finden Sie unter Robuste Systeme konzipieren.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

dieser Seite
Feedback zur Dokumentation
Compute Engine-Dokumentation
Feedback zum Produkt