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 Cloudkonzipieren 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 Cloudnoch nicht vertraut sind, erstellen Sie ein Konto, um die Leistung unserer Produkte in realen Szenarien auszuwerten. 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 mindestens drei Zonen, die in mindestens drei physischen Rechenzentren untergebracht sind. Die Regionen Stockholm, Osaka und Montreal haben drei Zonen, die sich in einem oder zwei physischen Rechenzentren befinden. Diese Regionen werden auf mindestens drei physische Rechenzentren erweitert. Berücksichtigen Sie beim Entwerfen Ihrer Lösungen inGoogle Clouddie Informationen unter Cloud-Standorte, Google Cloud Platform-SLAs 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 Cloudfinden Sie in unserem ISO/IEC 27001-Zertifikat. Unabhängig davon, ob es sich um ein eigenes oder ein geleastes Rechenzentrum handelt, wählt Google Cloud 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 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. Google Cloud bietet auch spezielle KI-Zonen mit GPUs und TPUs mit hoher Kapazität für KI- und ML-Arbeitslasten. Weitere Informationen finden Sie unter KI-Zonen.

Um sich vor dem Verlust einer ganzen Region aufgrund einer Naturkatastrophe zu schützen, sollten Sie einen Notfallwiederherstellungsplan haben und wissen, wie Sie Ihre Anwendung im unwahrscheinlichen Fall eines Verlusts Ihrer primären Region wiederherstellen 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 vonGoogle Cloudkönnen zonal, regional 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.

Zugehörige Standortdokumente

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 verwaltet, um redundant und innerhalb und über Regionen verteilt zu sein. 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 den regionalen Standorten einen oder mehrere multiregionale Standorte:

  • Artifact Registry
  • Assured Workloads
  • Backup und DR
  • BigQuery
  • Cloud EKM
  • Firestore
  • Cloud Healthcare API
  • Cloud HSM
  • Cloud KMS
  • Natural Language API
  • Cloud Storage
  • Container Registry
  • Document AI
  • Gemini Enterprise for Customer Experience
  • GKE Enterprise
  • Zahlungs-Gateway
  • Security Command Center
  • Sensitive Data Protection
  • Spanner
  • Speech-to-Text
  • Storage Transfer Service

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 von Grund auf für den globalen Betrieb entwickelt und führt rund um die Uhr Wartungsarbeiten und Upgrades durch, ohne dass Sie dadurch beeinträchtigt werden. 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 in mehreren Regionen.

Interne Dienste

Viele kundenorientierte Google Cloud Dienste werden von einer Reihe bewährter interner Dienste wie Spanner, Colossus, Borg und Chubby unterstützt.

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 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, dass bei einem Ausfall in einer einzelnen Region nur Kunden in dieser Region betroffen sind. Kunden mit Produkten in mehreren Regionen sind nicht betroffen. Google Cloud hat eine umfangreiche Architektur, um korrelierte Ausfälle in verschiedenen Regionen zu verhindern.

Alle Google Cloud Dienste basieren auf internen Kern-Tools, um grundlegende Dienste wie Netzwerkbetrieb (innerhalb und außerhalb von Rechenzentren), Zugriff auf Rechenzentren und Identitätsautorisierungssysteme bereitzustellen. 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 öffentlichen Website eine klare Anleitung dazu, wie Kunden ihre Anwendungen für das gewünschte Maß an Resilienz konzipieren können, insbesondere für häufig verwendete Google Cloud Produkte wie Compute Engine, BigQuery, Pub/Sub und andere Dienste.

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 der Google Cloud VM und des persistenten Datenträgers hängen von Compute Engine- und Cloud Storage-Diensten auf niedrigerer Ebene wie Borg und Colossus ab.
  • Google Cloud und Infrastrukturspeicherdienste wie Spanner, Bigtable und Cloud Storage hängen von Folgendem ab:
    • 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, bei denen Daten in mehreren Regionen verfügbar sein sollen
    • 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 Sie an bestimmten Terminen, z. B. Black Friday und Cyber Monday, erhöhte Verfügbarkeitsanforderungen haben, Google Cloud bietet ein Programm an, mit dem Sie Ihre spezifische Anwendung, die aufGoogle Cloud ausgeführt wird, prüfen und validieren können. Außerdem werden unerwartete Dienstabhängigkeiten zwischen Ihrer Anwendung und unseren Diensten ermittelt.

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

Die Datenlokalität für Google Cloud -Dienste unterliegt den Nutzungsbedingungen, einschließlich der dienstspezifischen Nutzungsbedingungen. 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.

Wenn Sie regionale oder zonale Speicherressourcen verwenden, empfehlen wir dringend, Daten zu Replikations- oder Snapshot-Zwecken in eine andere Region oder in eine multiregionale Speicherressource zu übertragen.

Hinweise zur Anwendungsbereitstellung

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

Verwenden Sie:

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 Spanner.
  • Verwenden Sie zonale oder regionale Ressourcen, speichern Sie Snapshot-Daten aber in einer multiregionalen Ressource wie Cloud Storage, Datastore, Firestore oder 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:

  • Verwenden Sie zonale oder regionale Ressourcen wie Compute Engine oder App Engine, stellen Sie Ihre Anwendung aber bei einem regionalen Fehler manuell oder automatisch in einer anderen Region bereit. Greifen Sie dabei auf Kopien Ihrer primären Daten zurück, wenn die Daten nicht bereits in einer verwalteten, multiregionalen Ressource vorhanden sind.

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

Hier erfahren Sie, wie Sie mit Google Cloud skalierbare und ausfallsichere Anwendungsarchitekturen mit Mustern und Verfahren erstellen, die sich allgemein auf jede Webanwendung anwenden lassen.

HTTPS-Load-Balancer erstellen

Konfigurieren Sie Compute Engine-Instanzen in verschiedenen Regionen und verwenden Sie HTTP-Load-Balancing, um den Traffic auf die Regionen zu verteilen. So erhöhen Sie die Verfügbarkeit in den Regionen und ermöglichen ein Failover im Falle eines Dienstausfalls.

Robuste Systeme konzipieren

Gestalten Sie Ihre Anwendung im Compute Engine-Dienst so, dass sie Ausfälle, Netzwerkstörungen und unerwartete Notfälle kompensieren kann.

Cassandra-Sicherungen und -Wiederherstellungen mit Cloud Storage

Erweitern Sie Ihre Cassandra-Installation um eine einfache Notfallwiederherstellung, indem Sie Ihre Daten in Cloud Storage sichern und von dort wiederherstellen.

Leitfaden zur Planung der Notfallwiederherstellung

Allgemeine Grundsätze für die Entwicklung und das Testen eines Notfallwiederherstellungsplans mit Google Cloud.