Regionen und Zonen

Bestimmte Compute Engine-Ressourcen befinden sich in Regionen oder Zonen. Eine Region ist ein spezifischer geografischer Ort, an dem Sie Ihre Ressourcen ausführen können. Jede Region hat eine oder mehrere Zonen, die meisten Regionen haben drei oder mehr Zonen. Zum Beispiel bezeichnet die Region us-central1 eine Region in der Mitte der USA, die die Zonen us-central1-a, us-central1-b, us-central1-c und us-central1-f umfasst.

Ressourcen wie Instanzen oder nichtflüchtige Speicher, die sich in einer Zone befinden, werden als zonale Ressourcen bezeichnet. Andere Ressourcen wie statische externe IP-Adressen zählen zur Region. 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.

Speicher und Instanzen sind Beispiele für zonale Ressourcen. Beide Ressourcen müssen sich in derselben Zone befinden, um einen Speicher zu einer Instanz hinzuzufügen. Wenn Sie einer Instanz eine statische IP-Adresse zuweisen möchten, muss sich die Instanz ebenfalls in der gleichen Region wie die statische IP-Adresse befinden.

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.

In der nachstehenden Tabelle sind die Regionen und die jeweils zugehörigen Zonen aufgeführt. Eine vollständige Beschreibung der in einzelnen Zonen verfügbaren Maschinentypen und Funktionen finden Sie im Abschnitt Verfügbare Regionen und Zonen.

Region Zonen Standort
asia-east1 a, b, c Bezirk Changhua, Taiwan
asia-northeast1 a, b, c Tokio, 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
northamerica-northeast1 a, b, c Montréal, Québec, Kanada
southamerica-east1 a, b, c 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 am Laufen zu halten. Und 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 entwickeln.
Geringere Netzwerklatenz
Zur Verringerung der Netzwerklatenz sollten Sie eine Region oder Zone wählen, die sich in der Nähe Ihres Point of Service 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 Regionen 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 für mehrere Zonen in mehreren Regionen.

Verfügbare Regionen und Zonen

In der folgenden Tabelle werden die Region, deren Lage, die verfügbaren Zonen in dieser Region sowie die in dieser Region verfügbaren Funktionen 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
  • Verfügbare CPU-Plattformen:
    • Intel Xeon E5 v2 (Ivy Bridge) (Standard)
    • Intel Xeon E5 v4 (Broadwell)
    • Intel Xeon (Skylake)
  • Bis zu 96-vCPU-Maschinentypen bei Verwendung der Skylake-Plattform
  • Lokale SSDs
asia-northeast1 Tokio Tokio, Japan
  • asia-northeast1-a
  • asia-northeast1-b
  • asia-northeast1-c
asia-south1 Mumbai Mumbai, Indien
  • asia-south1-a
  • asia-south1-b
  • asia-south1-c
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-b
  • europe-west2-c
europe-west3 Frankfurt Frankfurt, Deutschland
  • europe-west3-a
  • europe-west3-b
    europe-west3-c
europe-west4 Niederlande Eemshaven, Niederlande
  • europe-west4-a
  • europe-west4-b
  • europe-west4-c
northamerica-northeast1 Montreal Montréal, Québec, Kanada
  • northamerica-northeast1-a
  • northamerica-northeast1-b
  • northamerica-northeast1-c
southamerica-east1 São Paulo 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

2018 wird Google die folgenden neuen Regionen einführen:

2019 wird Google die folgenden neuen Regionen einführen:

  • Zürich (Schweiz)
  • Osaka (Japan)

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 ihre Dauer hängen von vielen Faktoren ab, doch diese dürfte bei den meisten Anwendungen und Arbeitslasten ohne spürbare Folgen bleiben.

  • Beenden und neu starten

    Die 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

Durch aktuelle Verbesserungen der Virtualisierungstechnologie in Compute Engine ist es jetzt nicht mehr erforderlich, eine bestehende Zone außer Betrieb zu nehmen, um eine grundlegende Aktualisierung der Infrastruktur (Stromversorgung, Kühlung, Netzwerkstruktur, Server etc.) 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. Es ist auch empfehlenswert, Ihre Ressourcen regionenübergreifend zu hosten. Dies kann beispielsweise sinnvoll sein, wenn Sicherungsinstanzen in europe-east1 gehostet werden und das unwahrscheinliche Szenario eintritt, dass die Region europe-west1 ausfällt. Weitere Tipps zur Entwicklung von Systemen für verbesserte Verfügbarkeit finden Sie unter Robuste Systeme entwickeln.

Weitere Informationen

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

Feedback geben zu...

Compute Engine-Dokumentation