Übersicht über mehrere Zonen

Google Distributed Cloud (GDC) Air-gapped bietet Bereitstellungsfunktionen, die für Hochverfügbarkeit und Notfallwiederherstellung sorgen. Diese Funktion wird auf dieser Seite als Multi-Zone bezeichnet.

Mit mehreren Zonen können Sie nicht verbundene, geschäftskritische Arbeitslasten auf GDC ausführen und so Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR) ähnlich wie bei öffentlichen Hyperscale-Cloud-Anbietern erreichen. GDC bietet verwaltete Dienste und Infrastrukturdienste, die gegen lokale Fehler resistent sind. Bei einigen Diensten müssen Sie entscheiden, welches Maß an Resilienz für Ihre Arbeitslast erforderlich ist. Beispiele für Dienste, die mehrere Zonen unterstützen:

Eine umfassende Liste der Dienste, die Multizonenfunktionen bieten, finden Sie unter Unterstützte GDC-Dienste für Multizone.

GDC Multi-Zone bietet globale Ressourcenverwaltungsfunktionen, um die Verwaltung von Ressourcen in GDC-Zonen zu vereinfachen. Sie können alle GDC-Ressourcen und -Dienste, die in einem Universum verwaltet werden, mit Informationen zu Benachrichtigungen, Status, Nutzung, Logging, Monitoring und Abrechnung ansehen.

Für Multizonen-Universen in GDC sind globale Ressourcen und Hardwaresymmetrie erforderlich. Diese Symmetrie bedeutet, dass Hardware und Organisationen in allen Zonen gleich sein müssen und nicht unabhängig in einer bestimmten Zone geändert werden können.

Mit der Multi-Zone-Architektur erhalten Sie auch Bausteine, mit denen Sie Ihre Ziele für die Notfallwiederherstellung und Geschäftskontinuität erreichen können. Sie bietet drei Hauptfunktionen:

  • Kontinuierliche Steuerungsebenendienste: Im Falle einer zonalen Katastrophe sind kritische Funktionen, die zur Wiederherstellung einer Organisation und der zugehörigen Dienste erforderlich sind, bereits in einer anderen Zone vorhanden.

  • Ressourcen mit mehreren Zonen Beispiel: Asynchrone Speicherreplikation über GDC-Zonen hinweg.

  • Verwaltete Dienste für mehrere Zonen: Load Balancer bieten beispielsweise Multi-Zonen-Varianten, die von einem verwalteten Dienst gesteuert werden.

Was ist eine Zone?

Jede Zone kann je nach Standort eine unabhängige Katastrophendomain sein. Wenn sich beispielsweise zwei Zonen in einer Subduktionszone innerhalb von 1 km voneinander befinden, gehören sie zur selben Katastrophendomäne. Jede Zone ist eine vollständige Implementierung von GDC Air-Gapped – einer Hardware- und Softwarelösung, die jederzeit keine Verbindung zu Google Cloud erfordert. In einer Zone werden Infrastruktur, Dienste, APIs und Tools verwaltet, die eine lokale Steuerungsebene verwenden.

Eine GDC-Air-Gap-Zone besteht aus vier Schichten:

  • Hardware: Die zugrunde liegende Hardware und das von Google definierte Rack-Design.

  • Infrastruktur: Verwaltet die Hardware und bietet Abstraktionen, die es den Softwareschichten ermöglichen, ohne Bezug auf hardwarespezifische Konfigurationen ausgeführt zu werden.

  • Service Platform: Ein Framework zum Erstellen von Diensten in Distributed Cloud, das für Konsistenz zwischen verwalteten Diensten und Marketplace-Diensten sorgt.

  • Managed and Marketplace Services (Verwaltete Dienste und Marketplace-Dienste): Cloud-Dienste für Kunden, die auf GDC ausgeführt werden.

Eine Gruppe verbundener Air-Gap-Zonen wird als Universum bezeichnet. Wenn Sie fehlertolerante Anwendungen mit Hochverfügbarkeit bereitstellen möchten, die vor unerwarteten Ausfällen schützen, müssen Sie Ihre Anwendungen in mehreren Zonen eines Universums bereitstellen.

Was ist eine Region?

Eine Region ist eine Gruppierung von Zonen in einem Universum, die unseren definierten Latenzanforderungen entsprechen. Eine Zone ohne ausreichend nahe Peers wird als eigene Region betrachtet. Zonen in einer Region müssen mindestens 10 km voneinander entfernt sein, damit sie in vielen Compliance-Regimen als separate Katastrophendomänen gelten.

Regionen können Hunderte von Kilometern voneinander entfernt sein. Aus diesem Grund bietet GDC nur synchrone Dienste innerhalb von Regionen an. Asynchrone Dienste sind innerhalb und zwischen Regionen verfügbar.

Bei asynchronen Diensten erfolgt die Replikation im Hintergrund, was zu niedrigen, aber nicht null Recovery Point Objectives (RPO) führt. Asynchrone Dienste sind in der Regel auch bei Netzwerkpartitionen verfügbar.

Beispiele für GDC-Air-Gap-Asynchrondienste:

  • Blockspeicher
  • Objektspeicher

Zonen innerhalb einer einzelnen Region müssen die Latenzanforderungen erfüllen, die die Bereitstellung stark konsistenter Dienste ermöglichen. Bei synchronen Diensten erfolgt die Replikation sofort. So wird sichergestellt, dass jeder Schreibvorgang in mindestens zwei Zonen verfügbar ist. Dies ist der wichtigste Schritt, um ein RPO von null zu erreichen. Synchrone Dienste haben in der Regel eine höhere Latenz als nicht replizierte Dienste und sind bei Netzwerkpartitionen möglicherweise nicht verfügbar.

Beispiele für synchrone GDC-Dienste mit Air Gap:

  • NFS-Dateifreigaben
  • Objektspeicher

Was ist ein Universum?

Zonen mit direkter Netzwerkverbindung, unabhängig von Entfernung oder Latenz, und einer gemeinsamen Verwaltungs- und Steuerungsebene gehören zu einem Universum. Ein Universum kann maximal sechs Zonen haben.

Jedes Universum kann aus mehreren Zonen bestehen, die in miteinander verbundenen Regionen organisiert sind. Beispiel: Zwei Regionen im US-Bundesstaat Virginia und in Amsterdam (Niederlande) mit jeweils drei Zonen:

  • GDC Region 1 (Virginia)

    • Zone 1 (us-virginia1-a)
    • Zone 2 (us-virginia1-b)
    • Zone 3 (us-virginia1-c)

  • GDC-Region 2 (Niederlande)

    • Zone 1 (eu-ams1-a)
    • Zone 2 (eu-ams1-b)
    • Zone 3 (eu-ams1-c)

Das folgende Diagramm zeigt ein Beispiel für ein GDC-Universum.

Ein Universum besteht aus Zonen, die nach Regionen gruppiert sind.

Ein Universum kann 1 bis 6 Zonen und ein oder zwei Operationszentren haben.

Für Universen sind unabhängig von der Regionskonfiguration die folgenden automatischen Wiederherstellungsstrategien verfügbar:

  • Bei Universen mit zwei Zonen muss die Wiederherstellung manuell ausgelöst werden.
  • Bei Universen mit mindestens drei Zonen kann die Wiederherstellung automatisch ausgelöst werden.

Wende dich an deinen Operator, um weitere Informationen zu erhalten.

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 VM-Instanz, die sich innerhalb einer bestimmten Zone befindet. Weitere Informationen zur Verwaltung von zonalen Ressourcen in einem GDC-Universum finden Sie unter Management API-Server.

Globale Ressourcen

Globale Ressourcen sind Ressourcen, die in allen Zonen eines Universums bereitgestellt werden, z. B. Organisationen. Sie haben eine höhere Verfügbarkeit als zonale Ressourcen. Globale Ressourcen werden auf dem globalen Management API-Server bereitgestellt und dort verwaltet.

Für jede Organisation gibt es globale und zonale Management API-Server.

Katastrophendomains

Eine Katastrophendomain stellt eine Sammlung von Ressourcen dar, die aufgrund der physischen Nähe der Ressourcen gleichzeitig betroffen sein können. Es handelt sich also um ein Konstrukt, das sich auf die Langlebigkeit bezieht und verwendet wird, um die Anforderungen an die Zonentrennung zu vereinfachen. Normalerweise entspricht eine einzelne Katastrophendomain einem einzelnen Campus.

In den meisten GDC-Universen gehören die Einrichtungen nicht Google, sondern wir arbeiten mit Colocation-Anbietern zusammen, die Rechenzentren mit Zugang zu einer robusten Infrastruktur, redundanter Stromversorgung und High-Speed-Konnektivität haben. Dieser Ansatz bietet optimale Leistung und Betriebszeit für Anwendungen und Dienste, die auf der Strategie und den Best Practices von Google für Hochverfügbarkeit und Notfallwiederherstellung basieren.

Wende dich an deinen Operator, um weitere Informationen zu den Spezifikationen für die Katastrophendomain für dein Universum zu erhalten.

Globale und zonale APIs

GDC Air-Gapped bietet zwei Ebenen von Management Plane-APIs zum Erstellen und Verwalten von globalen und zonenbezogenen Ressourcen: globale APIs und zonenbezogene APIs. Informationen dazu, wie diese API-Typen in einem GDC-Universum verwaltet werden, finden Sie in der Dokumentation zu globalen und zonenbasierten Management-API-Servern.

Sowohl globale als auch zonale APIs sind deklarative Kubernetes-APIs, die an verschiedenen Endpunkten bereitgestellt werden. GDC-Ressourcen werden in den API-Servern als benutzerdefinierte Kubernetes-Ressourcen dargestellt. Die globalen API-Server nutzen ein gemeinsames etcd-Cluster, das über Zonen verteilt ist, um eine hohe Konsistenz mit Fehlertoleranz zu bieten. Dies geht jedoch auf Kosten einer höheren Latenz und einer geringeren QPS (Abfragen pro Sekunde) im Vergleich zu den zonenbasierten API-Servern. In jeder Organisation stellt ein zonenbezogener Management-API-Server die zonenbezogene API für Administratoren und Entwickler zur Verwaltung zonenbezogener Ressourcen bereit. Ein globaler Management-API-Server stellt die globale API zur Verwaltung globaler Ressourcen bereit.

Weitere Informationen zu APIs in GDC finden Sie in der API-Übersicht.

gdcloud-Befehlszeile

Die gdcloud CLI bietet Möglichkeiten zur Interaktion mit der zonalen oder globalen API, um Ihre Ressourcen und deren Bereitstellung zu verwalten. Dazu gehören:

  • Mit der CLI in der zonalen oder globalen Console-URL anmelden
  • Zonales CLI-Flag für bestimmte Zonenaktionen verwenden

Die globale URL wird standardmäßig konfiguriert, wenn Sie die gcloud CLI initialisieren. Sie können Ihre gdcloud-Konfiguration aktualisieren, um zonale URLs festzulegen und sich darin anzumelden, um zonenspezifische Aufgaben auszuführen.

Ebenso bietet die gcloud CLI ein --zone-Flag, das Sie für viele Aufgaben zur Ressourcenverwaltung in verschiedenen Befehlsgruppen festlegen können. Wenn Sie in der globalen URL-Konfiguration angemeldet sind, werden Ihre CLI-Aktionen für globale Ressourcen auf alle Zonen angewendet, für die sie gelten.

Weitere Informationen zur Verwendung der gcloud CLI für zonale und globale Dienste finden Sie unter Ressourcen zonenübergreifend verwalten.

GDC-Konsole

Die GDC-Konsole für eine bestimmte Organisation ist in jeder Zone innerhalb desselben Universums verfügbar. Daher können Sie mit der GDC-Konsole alle globalen und zonenbezogenen Ressourcen innerhalb einer Organisation verwalten.

Die folgenden Funktionen für mehrere Zonen sind über die GDC Console verfügbar:

  • Mit einem voll qualifizierten Domainnamen (FQDN) navigieren: Sie können den globalen FQDN verwenden, um automatisch zum am besten geeigneten zonalen Konsolenendpunkt zu gelangen. Wenn der globale FQDN aus irgendeinem Grund nicht aufgelöst werden kann oder Sie eine Verbindung zu einer bestimmten Zone herstellen möchten, können Sie den zonalen FQDN verwenden, um zu einem bestimmten Konsolenendpunkt in einer Zielzone zu navigieren.

  • Erstellung von zonalen Ressourcen verwalten:Beim Erstellen einer zonalen Ressource ist eine Zonenauswahl verfügbar, mit der die Zone bestimmt wird, in der eine Ressource erstellt wird. Umgekehrt ist die Zonenauswahl nicht sichtbar, wenn Sie eine globale Ressource erstellen.

  • Vorhandene Ressourcen in verschiedenen Zonen ansehen:Auf verschiedenen Ressourcenseiten in der GDC-Konsole werden Ressourcen nach Zone angezeigt. Mit der Zonenauswahl können Sie Ressourcen aus der ausgewählten Zone aufrufen. Auf Ressourcen aus allen Zonen kann zugegriffen werden, indem Sie zu den globalen und zonalen GDC-Konsolen-URLs navigieren und die entsprechende Zone in der Auswahl auswählen. Es gibt jedoch keine aggregierte Ansicht von Ressourcen aus allen Zonen.

Weitere Informationen zum Verwalten von Ressourcen in mehreren Zonen in einem GDC-Universum mit der GDC-Konsole finden Sie unter Ressourcen zonenübergreifend verwalten.

GDC ist so konzipiert, dass es auch bei Fehlern weiter funktioniert. Wenn also ein Problem mit der zonalen Verbindung erkannt wird, wird in der GDC-Konsole ein dauerhaftes Banner angezeigt, in dem Sie darüber informiert werden, dass Sie möglicherweise keine Änderungen an globalen Ressourcen vornehmen können.

In der GDC-Konsole wird ein Banner angezeigt, das auf ein zonales Verbindungsproblem hinweist.

Ressourcencontainer

Eine Organisation definiert eine Sicherheitsgrenze für Ressourcen, die gemeinsam verwaltet werden sollen. Jede Organisation in GDC Air-Gapped bietet sowohl eine globale API als auch eine zonale API, um die Erstellung von globalen und zonalen Ressourcen innerhalb der Organisation zu ermöglichen. Beim Erstellen einer globalen Organisation ist der Betreiber für die Bereitstellung von Zonen und die Konfiguration von zonenbezogenen Einstellungen verantwortlich, z. B. für die Menge des Speichers und die Anzahl der physischen Server, die für Nutzerarbeitslasten verfügbar sind.

Wende dich an deinen Mobilfunkanbieter, um weitere Informationen zur Einrichtung der spezifischen Zone für deine Organisation zu erhalten.

Ein Projekt bietet eine logische Gruppierung von Dienstressourcen innerhalb einer Organisation und einen Lebenszyklus- und Richtlinienbereich für die Verwaltung von Ressourcen. Alle Projekte sind global und erstrecken sich standardmäßig über die Zonen, die Sie in Ihrem Universum konfiguriert haben.

Alle Dienstressourcen müssen zwar in einem Projekt erstellt werden, aber nicht alle Dienste sind global. Dienste, die nur auf Zonenebene unterstützt werden, müssen in den von Ihnen ausgewählten Zonen bereitgestellt und verwaltet werden. Weitere Informationen finden Sie in der entsprechenden Dokumentation zu einem Ressourcentyp.

IAM

Die folgenden IAM-Dienste (Identity and Access Management) müssen als globale Ressourcen konfiguriert werden:

  • Identitätsanbieter (IdP) für die Authentifizierung
  • Rollenbasierte Zugriffssteuerung
  • Dienstidentitäten

Jede IAM-Konfiguration umfasst alle Zonen in einem Universum.

Authentifizierung

Sie müssen einen IdP mit Ihrer Organisation verbinden. Verwenden Sie dazu die globale Ressource IdentityProviderConfig. Mit dieser Ressource wird sichergestellt, dass Sie für alle Zonen im Universum denselben IdP verwenden, um eine Verbindung zu Ihrer Organisation herzustellen.

Weitere Informationen finden Sie unter Mit einem Identitätsanbieter verbinden.

Zugriff

Jedem Nutzer oder jeder Gruppe muss eine globale IAMRoleBinding-Ressource zugewiesen werden, um Zugriff auf die globalen und zonenbasierten Management-API-Server und Kubernetes-Cluster in jeder Zone der Organisation zu erhalten.

  • Global Management API-Serverzugriff:IAMRoleBinding wird als ClusterRoleBinding oder RoleBinding an einen vordefinierten ClusterRole auf dem globalen API-Server weitergegeben.

  • Zugriff auf den zonalen Management API-Server:IAMRoleBinding wird als ClusterRoleBinding oder RoleBinding auf den zonalen Management API-Server übertragen.

  • Kubernetes-Clusterzugriff:IAMRoleBinding wird als ProjectRole und ProjectRoleBinding an Kubernetes-Namespaces im Management API-Server und in Kubernetes-Clustern weitergegeben, die dem Projekt entsprechen, in dem sich ProjectRole und ProjectRoleBinding befinden.RoleRoleBinding

Weitere Informationen finden Sie unter Zugriff gewähren und widerrufen.

Dienstidentität

Dienstkonten sind Nutzerhauptkonten, die von Arbeitslasten und Diensten verwendet werden, um Ressourcen programmatisch zu nutzen und sicher auf Microservices zuzugreifen. Sie sind eine spezielle Art von Identität, die von einer Anwendung oder Arbeitslast und nicht von einer Person verwendet wird. Ähnlich wie bei einem Nutzerkonto können Dienstkonten Berechtigungen und Rollen zugewiesen werden. Sie können sich jedoch nicht wie ein menschlicher Nutzer anmelden. Die Funktion für Dienstidentitäten ist in der globalen Ressource ProjectServiceAccount enthalten.

Weitere Informationen finden Sie unter Mit Dienstkonten authentifizieren.

Netzwerk

Sie können die folgenden Netzwerkdienste für Ihre GDC-Zonen konfigurieren:

  • Anycast-Dienste
  • Load Balancing
  • Projektnetzwerkrichtlinien
  • DNS

Konfigurieren Sie Ihre globalen und zonenbasierten Netzwerkdienste, um den zonenübergreifenden und zoneninternen Netzwerk-Traffic in Ihrer GDC-Umgebung zu verwalten.

Anycast-Dienste

Multizone bietet Anycast-Netzwerkdienste, um Hochverfügbarkeit für Ressourcen aus mehreren Zonen zu ermöglichen. Ebenso werden DCI-Optionen (Data Center Interconnection) als vollständiges Mesh implementiert, um mehrere GDC-Zonen (Google Data Center) mit Air Gap zu verbinden. So kann GDC an mehreren Standorten Notfallschutz für mehrere Zonen bieten und gleichzeitig die Anforderung erfüllen, dass die Verbindung zu jeder Google-Infrastruktur vollständig getrennt wird.

Anycast-Dienste werden durch eindeutige /32-IPv4-Präfixe dargestellt, die über das Border Gateway Protocol (BGP) für Kundeneinrichtungen bereitgestellt werden. So wird die Erreichbarkeit von jedem verbundenen Netzwerk aus sichergestellt. Jeder Anycast-Dienst ist zwar von allen Zonen im GDC-Netzwerk mit Air Gap aus zugänglich, der tatsächliche Endpunkt, an den der Traffic weitergeleitet wird, hängt jedoch von Faktoren wie Nähe und Zonenvorzug basierend auf Ihrer benutzerdefinierten Routingrichtlinie ab.

Die Traffic-Bereitstellung wird optimiert, indem der Traffic an die nächstgelegene verfügbare Dienstinstanz weitergeleitet wird, immer innerhalb derselben Zone wie die Kundenverbindung. Das verringert nicht nur die Latenz, sondern verbessert auch die Gesamtleistung und Reaktionsfähigkeit des Dienstes. Wenn ein Anycast-Dienst beispielsweise in Zone 1, Zone 2 und Zone 3 bereitgestellt wird, wird eine Kundenanfrage aus Zone 2 in der Regel an die Dienstinstanz in Zone 2 weitergeleitet, da dies die nächstgelegene und damit effizienteste Option ist.

Der Anycast-Bereich ist zwar weltweit zugänglich, wird aber nur Kunden aus den spezifischen Zonen bereitgestellt, in denen der Dienst aktiv bereitgestellt wird. Bei dieser Zugriffskonfiguration wäre ein in Zone 1 bereitgestellter Dienst nur für Kunden verfügbar, die mit Zone 1 verbunden sind, nicht für Kunden, die mit anderen Zonen verbunden sind.

Außerdem wird in GDC ein System zur Zonenpräferenz implementiert, bei dem Zonen bei der Erstellung unabhängig vom Zonennamen ein numerischer Wert zugewiesen wird, der die Kundenattraktivität bestimmt. Wenn ein Anycast-Dienst beispielsweise in Zonen mit den numerischen Werten 1, 2 und 3 bereitgestellt wird, wird der Kundentraffic in der Regel auf die Zone mit dem niedrigsten Wert gelenkt, bevor die anderen Zonen als bevorzugter Standort infrage kommen. Dieses System bietet ein gewisses Maß an Vorhersagbarkeit und Kontrolle über Trafficmuster, enthält aber auch integrierte Failover-Mechanismen. Im Falle eines Ausfalls oder einer Störung, die sich auf die bevorzugte Zone auswirkt, würde das System den Traffic automatisch in eine andere Zone verlagern, um eine unterbrechungsfreie Dienstverfügbarkeit zu gewährleisten.

In einer Multi-Zone-Konfiguration ist für den Zugriff auf Dienste in einer bestimmten Zone eine Interconnect-Verbindung von Ihrem Netzwerk zu dieser Zone erforderlich. Für eine konsistente Bereitstellung in mehreren Zonen müssen die in jeder Zone in Ihrem Universum erstellten Interconnects hinsichtlich Kapazität und Konfiguration identisch sein. Für jede Zone, auf die Sie zugreifen möchten, muss eine entsprechende Interconnect-Verbindung vorhanden sein, wobei diese Interconnect-Verbindungen identisch sein müssen.

Wende dich an deinen Mobilfunkanbieter, um weitere Informationen zu erhalten.

Load Balancing

GDC bietet einen L4-Passthrough-Load-Balancer für Kubernetes- und VM-Arbeitslasten. Dieser Load-Balancer bietet die folgenden Konfigurationen:

  • Entweder TCP- oder UDP-Protokoll.
  • Es gibt keinen Proxy zwischen der Arbeitslast und dem Client.
  • Dediziertes Load-Balancing für bestimmte Zonen oder global für alle Zonen.
  • Interner Netzwerkverkehr innerhalb Ihrer Organisation oder externer Netzwerkverkehr zwischen Organisationen.

Das folgende Diagramm veranschaulicht die Komponenten eines externen Passthrough-L4-Load-Balancers in einer GDC-Umgebung:

Ein externer Passthrough-L4-Load-Balancer in einem GDC-Universum.

Der Load Balancer kann so konfiguriert werden, dass er in einer einzelnen Zone oder global für alle Zonen funktioniert.

Weitere Informationen zum Load-Balancing in GDC finden Sie unter Load-Balancer verwalten.

Projektnetzwerkrichtlinien

In Projektnetzwerkrichtlinien werden Regeln für die Datenübertragung in ein Projekt oder aus einem Projekt definiert. Da Projekte eine globale Ressource sind, müssen Sie die Netzwerkrichtlinien eines Projekts auch global definieren, um zonenübergreifenden Netzwerkverkehr für die Dienste und Arbeitslasten innerhalb eines Projekts zu ermöglichen.

Weitere Informationen finden Sie unter Projektnetzwerkrichtlinien konfigurieren.

DNS

DNS-Dienste (Domain Name System) sind global und erstrecken sich über mehrere Zonen. Wenn eine DNS-Dienstinstanz in einer Zone nicht mehr erreichbar ist, werden Clients nahtlos von einer anderen DNS-Dienstinstanz in einer anderen Zone bedient.

Jede Organisation in einer Zone enthält drei globale autoritative DNS-Server:

  • Globaler interner Server der Infrastruktur:Der autoritative Server, der die DNS-Anfragen im VPC-Netzwerk (Virtual Private Cloud) der Infrastruktur auflöst. Auf diesem Server werden nur Infrastrukturarbeitslasten verwaltet. Nutzer-Workloads interagieren nicht mit dieser Komponente. Alle internen Bereitstellungen der globalen Infrastruktur für eine Organisation in allen Zonen sind über eine Anycast-IP-Adresse zugänglich.

  • Globaler interner Kundenserver:Der autoritative Server, der DNS-Anfragen im VPC-Netzwerk (Virtual Private Cloud) des Kunden auflöst. Dieser Server verwaltet nur Nutzerarbeitslasten wie einen Pod in einem Kubernetes-Cluster oder eine VM und löst alle DNS-Anfragen auf, die von diesen Nutzerarbeitslasten stammen. Alle globalen internen Kundenbereitstellungen für eine Organisation in allen Zonen sind über eine Anycast-IP-Adresse zugänglich. Da sich VPCs über Zonen erstrecken, kann eine Anfrage zur Auflösung eines globalen vollqualifizierten Domainnamens (FQDN) aus einer Zone in einer beliebigen der fehlerfreien Zonen landen.

  • Globaler externer Kundenserver:Der autoritative Server, der die DNS-Anfragen auflöst, die aus dem Netzwerk des Kunden stammen. Alle globalen externen Kundenbereitstellungen für eine Organisation in allen Zonen sind über eine Anycast-IP-Adresse zugänglich.

Sie können eine Verbindung zu GDC über ein dediziertes externes Netzwerk oder ein gemeinsames externes Netzwerk herstellen. Diese Netzwerktypen bestimmen, wie GDC Ihre DNS-Anfragen auflöst.

Ein dediziertes externes Netzwerk stellt eine direkte Verbindung zum globalen externen DNS-Server des Kunden her, der die Anfrage auflöst. Alternativ kann ein gemeinsames externes Netzwerk mit dem Stamm Ihrer DNS-Hierarchie verbunden werden. Dieser Root-Server stellt den Nameserver-Eintrag (NS) der Anfrage für die entsprechende DNS-Zone für den globalen externen DNS-Server des Kunden bereit. Ihr DNS-Resolver löst die Anfrage dann rekursiv auf.

GDC bietet DNS-Auflösung für internen und externen Traffic sowohl global als auch innerhalb einer einzelnen Zone.

Anfragen, die aus Ihrem externen Netzwerk stammen, werden von Ihrem DNS-Resolver weitergeleitet. Ebenso stammen interne DNS-Anfragen von Ihren Arbeitslasten in einem GDC-Universum.

DNS-Anfragen haben das folgende FQDN-Format:

  • Globale DNS-Anfragen:SERVICE_NAME.ORG_NAME.SUFFIX, z. B. service-1.org-1.google.com.
  • Zonale DNS-Anfragen:SERVICE_NAME.ORG_NAME.ZONE_NAME.SUFFIX, z. B. service-1.org-1.zone-1.google.com.

Weitere Informationen zum Konfigurieren von Netzwerken in einem GDC-Universum finden Sie unter Netzwerkübersicht.

Speicher

Ab Version 1.14.4 können in Universen mit mehreren Zonen replizierte Speicherressourcen wie Volumes und Buckets im asynchronen Modus für Notfallwiederherstellungsszenarien verwendet werden. Diese Speicherressourcenoptionen ermöglichen die asynchrone Datenreplikation zwischen zwei beliebigen Zonen im selben Universum. Die asynchrone Replikation erfolgt im Hintergrund und bietet im Falle einer Katastrophe ein niedriges, aber nicht null RPO. Alle replizierten Daten sind online und sofort zugänglich. Möglicherweise ist jedoch ein manuelles Failover-Verfahren erforderlich, um das Schreiben in die sekundäre Zone zu ermöglichen.

  • Asynchrone Blockreplikation:Bietet asynchron replizierte Volumes (PVs), die die Blockäquivalenz zwischen dem primären und dem sekundären Volume aufrechterhalten. Aufgrund der Asynchronität spiegelt das sekundäre Volume den Zustand des primären Volumes zu einem bestimmten Zeitpunkt in der Vergangenheit wider (RPO ungleich null). Das sekundäre Volume kann nicht bereitgestellt werden, solange es das Ziel der Replikation ist. Es ist ein manueller Eingriff erforderlich, um die Beziehung zu beenden und Schreibvorgänge zu ermöglichen.

  • Asynchrone Bucket-Replikation:Replizierte Buckets werden zonenübergreifend gekoppelt, wodurch eine bidirektionale Datenreplikationsbeziehung entsteht. Objektdaten, die mit dieser Funktion in primäre oder sekundäre Zonen-Buckets geschrieben werden, werden in die andere Zone kopiert. Da die Daten asynchron kopiert werden, enthalten die Buckets zu einem bestimmten Zeitpunkt möglicherweise nicht dieselben Objektversionen. Sie werden jedoch schließlich konsistent, wenn keine zusätzlichen Änderungen vorgenommen werden. Im Gegensatz zur Volumereplikation sind replizierte Buckets während Zonenteilungen beschreibbar. Bei jedem Schreibvorgang in ein Objekt wird eine andere Version erstellt. Die neueste Version in einer der beiden Zonen ist der endgültige Zustand, nachdem die Verbindung wiederhergestellt wurde.

Anforderungen an die Latenz

Damit Sie GDC-Zonenstandorte für aktuelle und zukünftige Funktionen planen können, basieren die Latenzanforderungen auf Google Cloud. So können Sie GDC-Standorte mit Air Gap auswählen und wissen, ob sich diese Zonen in derselben Region befinden.

Latenzanforderungen für mehrere Zonen.

Die maximal unterstützte Latenz beträgt weniger als 1 ms Umlaufzeit (Round Trip Time, RTT) auf der physischen Schicht zwischen zwei Zonen in einer Region. Da für die Berechnung der Latenz auf der physischen Ebene spezielle Geräte erforderlich sind, die in den meisten Fällen nicht verfügbar sind, kann sie durch Messen der Glasfaserlänge zwischen zwei Zonen angenähert werden.

Eine Faserlänge für Zonen in einer Region von 50 km auf dem primären Pfad und 100 km auf dem sekundären Pfad unterstützt regionale Dienste. In einem Ringnetzwerk darf jede Glasfaserleitung maximal 50 km lang sein.

Wenden Sie sich an Ihren Mobilfunkanbieter, um weitere Informationen zu Ihren spezifischen Latenzanforderungen zu erhalten.

Nächste Schritte