Diese Seite wurde von der Cloud Translation API übersetzt.

Geografie und Regionen

Google Cloud-Produkte werden von bestimmten regionalen Ausfalldomains bereitgestellt und von Service Level Agreements uneingeschränkt unterstützt, damit Sie Ihre Anwendungsarchitektur innerhalb der Struktur von Google Cloud konzipieren können.

Google Cloud-Infrastrukturdienste sind an Standorten in Nordamerika, Südamerika, Europa, Asien, dem Nahen Osten und Australien verfügbar. Diese Standorte sind in Regionen und Zonen aufgeteilt. Sie können wählen, wo Sie Ihre Anwendungen positionieren möchten, damit Ihre Ansprüche an die Latenz, Verfügbarkeit und Lebensdauer erfüllt werden.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten

Regionen und Zonen

Regionen sind unabhängige geografische Gebiete, die aus Zonen bestehen. Zonen und Regionen sind logische Abstraktionen zugrunde liegender physischer Ressourcen. Eine Region besteht aus drei oder mehr Zonen, die sich in drei oder mehr physischen Rechenzentren befinden. Die Regionen Mexiko, Osaka und Montreal haben drei Zonen, die sich in einem oder zwei physischen Rechenzentren befinden. In diesen Regionen wird derzeit auf mindestens drei physische Rechenzentren erweitert. Berücksichtigen Sie beim Entwerfen Ihrer Lösungen in Google Cloud die Informationen unter Speicherorte in der Cloud, SLAs der Google Cloud Platform und die entsprechende Google Cloud-Produktdokumentation.

Diese Rechenzentren können Eigentum von Google sein und auf der Google Cloud-Standortseite aufgeführt sein. Sie können auch von Drittanbietern von Rechenzentren gemietet werden. Eine vollständige Liste der Rechenzentrumsstandorte für Google Cloud finden Sie in unserem ISO/IEC 27001-Zertifikat. Google Cloud wählt unabhängig davon, ob es sich um ein eigenes oder ein geleastes Rechenzentrum handelt, die Rechenzentren aus und gestaltet seine Infrastruktur so, dass sie ein einheitliches Niveau an Leistung, Sicherheit und Zuverlässigkeit bietet.

Eine Zone ist ein Bereitstellungsbereich für Google Cloud-Ressourcen innerhalb einer Region. Zonen sollten als einzelne Fehlerdomain in einer Region gesehen werden. Stellen Sie Ihre Anwendungen in mehreren Zonen einer Region bereit, damit sie fehlertolerant, hochverfügbar und vor unerwarteten Ausfällen geschützt sind.

Für den Schutz vor dem Verlust einer ganzen Region in Katastrophenfällen ist ein Plan zur Notfallwiederherstellung erforderlich. Dabei muss festgelegt werden, wie Sie Ihre Anwendung im unwahrscheinlichen Fall, dass Ihre Hauptregion verloren geht, andernorts betreiben können. Siehe Hinweise zur Anwendungsbereitstellung für weitere Informationen.

Weitere Informationen zu den jeweiligen Ressourcen, die an den einzelnen Standorten verfügbar sind, finden Sie unter Cloud-Standorte.

Die Dienste und Ressourcen von Google Cloud können zonal oder regional sein oder von Google in mehreren Regionen verwaltet werden. Weitere Informationen dazu, was diese Optionen für Ihre Daten bedeuten, finden Sie unter Geografisches Datenmanagement.

Google Cloud möchte in jeder "Region für allgemeine Zwecke" mindestens drei Verfügbarkeitszonen (physisch und logisch unterschiedliche Zonen) anbieten.

Zonale Ressourcen

Zonale Ressourcen arbeiten innerhalb einer einzigen Zone. Zonale Ausfälle können sich auf einige oder alle Ressourcen in dieser Zone auswirken. Ein Beispiel für eine zonale Ressource ist eine Compute Engine-VM-Instanz, die sich innerhalb einer bestimmten Zone befindet.

Regionale Ressourcen

Regionale Ressourcen werden redundant in mehreren Zonen einer Region bereitgestellt. Dazu gehören z. B. App Engine-Anwendungen oder regionale verwaltete Instanzgruppen. Sie haben eine höhere Verfügbarkeit als zonale Ressourcen.

Multiregionale Ressourcen

Mehrere Google Cloud-Dienste werden von Google so verwaltet, dass sie redundant innerhalb einer Region und in mehreren Regionen verteilt werden. Diese Dienste optimieren die Verfügbarkeit, die Leistung und die Ressourceneffizienz. Daraus ergibt sich, dass diese Dienste eine Abwägung zwischen Latenz- und Konsistenzmodell erfordern. Diese Abwägungen werden produktspezifisch dokumentiert.

Die folgenden Dienste haben zusätzlich zu regionalen Standorten einen oder mehrere multiregionale Standorte:

Artifact Registry
Bigtable
Schutz sensibler Daten
Cloud Healthcare API
Cloud KMS
Container Registry
Spanner
Cloud Storage
Database Migration Service
Datastore
Firestore

Diese multiregionalen Dienste sind so konzipiert, dass sie nach dem Ausfall einer einzelnen Region weiter funktionieren.

Weitere Informationen finden Sie unter Produktverfügbarkeit nach Standort und in der Dokumentation zu den einzelnen Produkten.

Globale Dienste

Google Cloud wurde für die globale Nutzung neu entwickelt. Dafür werden rund um die Uhr Wartungsarbeiten und Upgrades ausgeführt, von denen Sie aber nicht betroffen sind. Unser globales Backbone bietet hohe Flexibilität für Load-Balancing und reduziert die Latenz für Endnutzer durch Verbindungen in Ihrer Nähe. Unsere globale Cloud-Verwaltungsebene vereinfacht die Verwaltung von Entwicklungen für mehrere Regionen.

Interne Dienste

Viele der Google Cloud-Dienste für Kunden bestehen aus einem Set bewährter interner Dienste wie Spanner, Colossus, Borg und Chubby, die diesen zugrunde liegen und sie unterstützen.

Diese internen Dienste werden entweder global für mehrere Regionen über Load-Balancing verteilt oder sind jeweils einer Region zugeordnet, in der sie verfügbar sind. Bei Diensten mit Load-Balancing über mehrere Regionen stellen wir die Updates schrittweise Region für Region bereit. Dadurch können wir Probleme erkennen und beheben, ohne die Nutzung der Dienste zu beeinträchtigen. Keiner dieser internen Dienste ist auf ein einzelnes logisches Rechenzentrum oder auf eine einzelne Region beschränkt.

Global Internal Services können in den folgenden Cloud-Regionen ausgeführt oder repliziert werden:

Amerika

southamerica-west1
us-central1
us-east1
us-east4
us-west1
us-west4

Europa

europe-north1
europe-west1
europe-west4

Asien

asia-east1
asia-southeast1

Dienstabhängigkeiten

Im Allgemeinen gilt für Google Cloud-Dienste, wenn eine einzelne Region ausfällt, dass nur Kunden innerhalb dieser Region betroffen sind. Kunden mit Produkten in mehreren Regionen sind nicht betroffen. Google Cloud bietet eine umfassende Architektur mit dem Ziel, korrelierte Fehler in verschiedenen Regionen zu vermeiden.

Alle Google Cloud-Dienste nutzen wichtige interne Tools, um grundlegende Dienste bereitzustellen, z. B. Netzwerkdienste (in und außerhalb von Rechenzentren), Zugriff auf Rechenzentren und Identitätsautorisierungssysteme. Diese Tools sind robust gegenüber regionalen Ausfällen, und zwar mit dem Ziel, dass eine Region nicht betroffen ist, wenn andere Regionen nicht mehr verfügbar sind.

Google Cloud bietet auf unserer öffentliche Website klare Anweisungen dazu, wie Kunden ihre Anwendungen für die gewünschte Robustheit entwerfen sollten, insbesondere bei häufig verwendeten Google Cloud-Produkten wie Compute Engine, BigQuery, Pub/Sub und anderen Diensten.

Die unten aufgeführten Hauptabhängigkeiten beginnen mit Abhängigkeiten, die für alle Dienste gemeinsam sind. Dabei gilt, dass sich die Implementierungsdetails niedrigerer Ebene ändern können.

Allgemeine Abhängigkeiten für alle Dienste

Identitätsdatenebene zur Authentifizierung und Autorisierung
Interne Dienste für Logging, Metadatenspeicherung und Workflowverwaltung
Der Zugriff auf Google Cloud APIs hängt von DNS, global verteilten Load-Balancern und Points of Presence (PoPs) ab.
Die Konfiguration globaler Ressourcen: IAM-Richtlinien, globale Firewallregeln, globale Load-Balancer-Konfigurationen und Pub/Sub-Themen werden z. B. in replizierten Datenbanken gespeichert.
Wenn Google Cloud-Dienste Anfragen an vom Kunden kontrollierte Endpunkte senden, z. B. wenn Cloud EKM Kundenschlüsseln abruft oder Pub/Sub Nachrichten zustellt, brauchen diese Anfragen unsere globale Netzwerkinfrastruktur, um auf diese von Kunden kontrollierten Endpunkte zuzugreifen.

Dienste mit zusätzlichen Abhängigkeiten

Compute Engine-Dienste
- Die Datenebenen von Google Cloud VM und Persistent Disk hängen von den unteren Compute Engine- und Cloud Storage-Diensten wie Borg und Colossus ab.
Die Speicherdienste von Google Cloud und Infrastruktur wie Spanner, Bigtable und Cloud Storage sind abhängig von:
- Verschlüsselungs- und Schlüsselverwaltungsinfrastruktur für Kunden (Cloud KMS/Cloud EKM) und interner Infrastruktur für Google-Schlüssel
- Interne Dienste für Logging und Auditing des Datenzugriffs
- Interne Datenreplikationsdienste, in denen Daten voraussichtlich in mehreren Regionen verfügbar sein werden
- Explizit konfigurierte Sicherungen und Replikation in anderen Regionen hängen vom regionenübergreifenden Netzwerk ab
Messaging-Dienste
- Pub/Sub benötigt unsere globale Netzwerkinfrastruktur für den Zugriff auf von Kunden kontrollierte Endpunkte
Netzwerkdienste
- Globales Load-Balancing, DNS und Failover zwischen Regionen hängen von der physischen Netzwerkinfrastruktur ab.
- Das Verhindern von DDos-Angriffen und Ähnlichem hängt von der untergeordneten Compute Engine-Infrastruktur ab.
Verwaltete und gehostete Dienste wie GKE und Cloud SQL
- Abhängig von Compute Engine und entweder Container Registry oder Artifact Registry für VM-Images.
Unabhängige Infrastruktur auf niedrigerer Ebene
- Unsere interne Steuerungsebene auf Clusterebene, einschließlich Borg und Netzwerk-Fabrics
- Speicher auf Clusterebene, z. B. Colossus
- Verschlüsselungs- und Schlüsselverwaltungsinfrastruktur

Verfügbarkeit und Stabilität aufrechterhalten und verbessern

Site Reliability Engineering (SRE) ist die interne Organisation von Google für Verfügbarkeit, Latenz, Leistung und Kapazität. Ausfälle und die Nichtverfügbarkeit von Diensten werden der Bereitstellung von neuem Code oder Änderungen an der Umgebung zugeordnet. Durch die Verwendung von Branchen-Best-Practices wird von SRE der Bedarf an neuen Software-Releases minimiert und die Umgebung sicher gehalten. Dabei wird berücksichtigt, dass erforderliche Änderungen zu Ausfallzeiten führen können.

Stabile Dienste zusammen mit Kunden aufbauen

Wenn Sie geschäftskritische Anforderungen haben und Stabilität sowie Notfallwiederherstellung aufbauen müssen, können Sie in Zusammenarbeit mit unseren SRE/CRE- und PSO-Teams Anwendungen entwickeln, die mehrere Regionen und Zonen verbinden. Diese Teams bieten auch eine Unterstützung für die Entwicklung von Hochverfügbarkeitssystemen.

Wenn die Verfügbarkeitsanforderungen für bestimmte Zeitpunkte wie Black Friday/Cyber Monday erhöht sind, bietet Google Cloud ein Programm an, mit dem Sie Ihre spezifische Anwendung, die auf Google Cloud ausgeführt wird, prüfen und validieren sowie unerwartete Dienstabhängigkeiten zwischen Ihrer Anwendung und unseren Diensten ermitteln können.

Points of Presence (POPs)

Google betreibt ein globales Netzwerk von Peering-Points of Presence. Dies bedeutet, dass der Traffic des Kunden innerhalb des Google-Netzwerks übertragen werden kann, bis er sich in der Nähe seines Ziels befindet. Dies ermöglicht Nutzern eine bessere Nutzererfahrung und eine höhere Sicherheit. Weitere Informationen finden Sie unter Edge-Netzwerkstandorte.

Geografisches Datenmanagement

Der Aufbewahrungsort der Daten für Google Cloud-Dienste ist in den Nutzungsbedingungen einschließlich der dienstspezifischen Nutzungsbedingungen geregelt. Google weiß, dass jeder Kunde eigene Anforderungen an Sicherheit und Compliance hat. Das Google Cloud-Vertriebsteam kann Ihnen dabei helfen, Ihre Anforderungen zu erfüllen.

Bei der Verwendung regionaler oder zonaler Speicherressourcen wird für die Notfallwiederherstellung dringend empfohlen, dass Sie Ihre Daten in eine andere Region replizieren oder Snapshots in multiregionalen Speicherressourcen erstellen.

Hinweise zur Anwendungsbereitstellung

Für hochverfügbare Dienste und Anwendungen, die durch einen Ausfall einzelner Zonen nicht beeinträchtigt werden

Verwenden Sie:

Regionale Ressourcen wie App Engine-Anwendungen, regionale verwaltete Instanzgruppen oder verwaltete multiregionale Ressourcen wie Cloud Storage, Datastore, Firestore oder Cloud Spanner.
Zonale Ressourcen wie virtuelle Compute Engine-Maschinen, wobei Sie Ihre eigene Rechner- und Speicherredundanz in den Zonen und Regionen verwalten.

Zum Aufbau geeigneter Anwendungen für die Notfallwiederherstellung, die einem weitreichenden Verlust ganzer Regionen standhalten können,

Verwenden Sie für Daten:

Verwenden Sie verwaltete, multiregionale Speicherdienste wie Cloud Storage, Datastore, Firestore oder Cloud Spanner.
Verwenden Sie zonale oder regionale Ressourcen, aber erstellen Sie Snapshots von Daten in einer multiregionalen Ressource wie Cloud Storage, Datastore, Firestore oder Cloud Spanner.
Nutzen Sie zonale oder regionale Ressourcen, aber verwalten Sie Ihre eigene Datenreplikation für eine oder mehrere andere Regionen.

Verwenden Sie für das Computing:

Zonale oder regionale Ressourcen wie Compute Engine oder App Engine, aber starten Sie Ihre Anwendung beim Ausfall einer Region manuell oder automatisch in einer anderen Region. Verweisen Sie dabei auf Kopien Ihrer Primärdaten, falls sich die Daten nicht bereits in einer multiregionalen verwalteten Ressource befinden.

Weitere Informationen zu Dienstabhängigkeiten erhalten Sie von unseren Vertriebsmitarbeitern.

Weitere Lösungen und Anleitungen

Die folgenden Lösungen und Anleitungen bieten eine Orientierung, um sicherzustellen, dass Ihre Anwendung hochverfügbar ist und Ausfälle aushalten kann:

Skalierbare und robuste Anwendungen erstellen

Erstellen Sie mit Google Cloud skalierbare und robuste Anwendungsarchitekturen. Die hier vorgestellten Schemas und Verfahren gelten allgemein für jede Webanwendung.

HTTPS-Load-Balancer erstellen

Konfigurieren Sie Compute-Engine-Instanzen in verschiedenen Regionen und nutzen Sie einen HTTP-Lastenausgleich, um den Traffic auf die Regionen zu verteilen und die Verfügbarkeit in den Regionen zu steigern sowie um im Falle eines Dienstausfalls eine Ausfallsicherung zu haben.