Globale Load-Balancing-Architekturen mit DNS-Routingrichtlinien

Last reviewed 2023-01-04 UTC

In diesem Dokument wird beschrieben, wie Sie mehrere regionale Load-Balancer mit DNS-Routingrichtlinien von Google kombinieren können, um globale Load-Balancing-Architekturen zu erstellen. Das Dokument richtet sich an Netzwerktechniker, Lösungsarchitekten und Betriebsexperten. Dabei werden Grundkenntnisse zu Google Compute Engine und Netzwerkkonzepten wie Load-Balancern und DNS-Lookups vorausgesetzt.

Einführung

Wenn Sie einen globalen Dienst erstellen, der als in mehreren Regionen ausgeführte Anwendung implementiert ist, können Sie die DNS-Routingrichtlinien zur Standortbestimmung verwenden, um einen globalen DNS-Endpunkt für Ihren regionalen Load-Balancer einzurichten. Bei diesem Ansatz erstellen Sie einen globalen Endpunkt, der Traffic an den nächstgelegenen lokalen Dienst weiterleitet.

Abhängig vom verwendeten Typ des Load-Balancers können Sie dies möglicherweise mit globalen proxybasierten Load-Balancing-Optionen erreichen. In einigen Anwendungsfällen müssen Sie jedoch Produkte für regionales Load-Balancing verwenden, z. B. wenn Ihr Dienst UDP-Traffic bereitstellt. Die DNS-Routingrichtlinien zur Standortbestimmung können auch bei der Bereitstellung eines einzigen DNS-Endpunkts für Hybridanwendungen helfen, die Google Cloud zusammen mit anderen Cloud-Dienstanbietern oder neben einer lokalen Bereitstellung verwenden.

Architektur

Das folgende Diagramm zeigt eine Beispielarchitektur, die drei regionale Load-Balancer in drei verschiedenen Regionen verwendet. Die Regionen werden mithilfe von DNS-Routingrichtlinien kombiniert.

Grafik: Architektur, in der Cloud DNS den Traffic je nach Standort des Clients an einen regionalen internen Load-Balancer weiterleitet

Das obige Diagramm zeigt, wie Clients in Oregon, Deutschland und Singapur DNS-Lookups zu Cloud DNS für www.example.com durchführen. Anfragen werden an regionale Load-Balancer weitergeleitet, die sich in der Nähe der jeweiligen Clients befinden, um eine Anwendung zu erreichen, die in drei verschiedenen Regionen gehostet wird.

Anwendungsfälle für DNS-Routingrichtlinien für die Standortbestimmung

In diesem Abschnitt werden die folgenden Anwendungsfälle für die Verwendung von DNS-Routingrichtlinien für die Standortbestimmung zum Erstellen eines globalen Dienstes aus mehreren regionalen Load-Balancern erläutert:

Ein global zugänglicher und global verteilter interner Dienst

Sie können einen global zugänglichen und global verteilten internen Dienst erstellen. Dazu kombinieren Sie mehrere regionale interne Load-Balancer mit DNS-Routingrichtlinien zur Standortbestimmung. Sie können entweder einen internen Passthrough-Network-Load-Balancer oder einen internen Application Load Balancer verwenden. Ohne DNS-Routingrichtlinien kann ein interner Application Load Balancer nur regionale Endpunkte verwenden. Mit einem internen Passthrough-Network-Load-Balancerr, der globalen Zugriff verwendet, können Sie Ihren Dienst global verfügbar machen. In diesem Fall können sich Back-Ends nur in einer einzigen Region befinden. Wenn Sie jedoch DNS-Routingrichtlinien verwenden, können Sie Back-Ends in mehreren Regionen haben.

Das folgende Diagramm zeigt diese Architektur:

Architektur für interne Clients, in denen Cloud DNS Traffic an die interne Passthrough-Network-Load-Balancer-Instanz sendet, die sich in der Region befindet, in der sich der Client befindet

Das obige Diagramm zeigt, wie interne Clients in mehreren Regionen service.corp.example.com mit Cloud DNS auflösen. Clients erhalten immer eine Antwort mit einer IP-Adresse, die zu einem internen Passthrough-Network-Load-Balancer gehört, der sich in der Region des Clients befindet. Der Load-Balancer verweist auf eine Anwendung in derselben Region. (In diesem Beispiel wird die Anwendung in Google Kubernetes Engine (GKE) ausgeführt. Dies ist jedoch nicht erforderlich.) Clients senden Anwendungstraffic an eine lokale Instanz der Anwendung, sie verwenden jedoch alle denselben service.corp.example.com-DNS-Endpunkt.

Sie können diese Konfiguration mit den folgenden Schritten erstellen:

  1. Sie erstellen die internen Load-Balancer in jeder Region. Wenn Sie einen internen Passthrough-Network-Load-Balancer verwenden, müssen Sie den globalen Zugriff aktivieren, damit Clients aus anderen Regionen eine Verbindung zum Dienst herstellen können.

  2. Sie erstellen eine DNS-Routingrichtlinie. In der Richtlinie legen Sie den Typ auf GEO und den Wert --routing-policy-data auf eine Liste von Zielregionen fest, die dem entsprechenden internen Load-Balancer zugeordnet sind. Mit dem folgenden Befehl können Sie die im Diagramm dargestellte Einrichtung erstellen:

    gcloud beta dns record-sets create service.corp.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \
    --enable-health-checking

In diesem Beispiel wird ein Eintrag mit einem TTL-Wert von 30 Sekunden erstellt, damit Clients die DNS-Einträge regelmäßig aktualisieren, wenn sich die Richtlinie ändert.

Wenn Sie DNS-Routingrichtlinien verwenden, erhält jeder Client eine DNS-Antwort, die die IP-Adresse des internen Load-Balancers in der Region enthält. Wenn sich der Client außerhalb einer Region befindet, in der interne Load-Balancer definiert sind, erhält er die IP-Adresse des internen Load-Balancers, der sich in der nächstgelegenen Region befindet.

DNS-Routingrichtlinien leiten den Traffic basierend auf der nächstgelegenen internen Load-Balancer-Region weiter. Wenn mehr als 80 % der Back-Ends in dieser Region fehlerhaft sind und Sie die Systemdiagnose mit geografischen DNS-Routingrichtlinien verwenden, erfolgt der Failover des Traffics über Regionen hinweg.

Wenn Sie kein Failover zwischen Regionen benötigen, können Sie den Befehl so ändern:

  • Entfernen Sie das Flag --enable-health-checking.
  • Ersetzen Sie den Namen der jeweiligen Weiterleitungsregel für den internen Load-Balancer durch seine IP-Adresse.

Ein globaler Endpunkt für einen externen Dienst, der TCP und UDP unterstützt

Sie können auch einen globalen DNS-Endpunkt für einen externen Dienst erstellen. Dazu kombinieren Sie mehrere regionale externe Load-Balancer mithilfe von DNS-Routingrichtlinien zur Standortbestimmung. Der häufigste Anwendungsfall ist die Verwendung eines externen Passthrough-Network-Load-Balancers für TCP-basierte oder UDP-basierte Anwendungen. Dieser Ansatz ist besonders nützlich für Anwendungen, die UDP verwenden, da in Google Cloud keine globale Load-Balancing-Option für UDP verfügbar ist.

Für Anwendungen mit TCP-Traffic, die vom externen Proxy-Network-Load-Balancer oder externen Application Load Balancer unterstützt werden, können Sie anstelle eines DNS-Endpunkts möglicherweise Instanzen dieser globalen Load Balancer verwenden. Diese Load-Balancer bieten regionsübergreifendes Load-Balancing mithilfe von anycast, das eine einzelne IP-Adresse als Frontend für alle Ihre Backend-Instanzen bereitstellt.

Die Verwendung der globalen Load-Balancing-Optionen bietet gegenüber dem DNS-Endpunkt folgende Vorteile:

  • Ein Failover erfolgt sofort. Ein Failover tritt auf, ohne dass sich der Traffic-Fluss auf Nutzerseite ändert.
  • Das Internetrouting bestimmt das Load-Balancing-Ziel. Internet-Routingprotokolle leiten den Traffic basierend auf dem kürzesten Pfad weiter, anstatt dass Cloud DNS einen Zielspeicherort auswählt.
  • Regionenübergreifendes Load-Balancing. Das globale Load-Balancing von Google unterstützt den regionenübergreifenden Failover. Im Gegensatz dazu gibt es keine Systemdiagnose mit DNS-Routingrichtlinien, wenn Sie einen externen Passthrough-Network-Load-Balancer verwenden.

Wir empfehlen daher, die globale Load-Balancing-Option von Google zu verwenden, wenn Ihre Anwendung TCP-basiert ist und von diesen Produkten unterstützt wird.

Das folgende Diagramm zeigt die Architektur mithilfe eines globalen DNS-Endpunkts:

Architektur für externe Clients, bei denen die Clients eine IP-Adresse für die interne Passthrough-Network-Load-Balancer-Instanz erhalten, die sich in der Region befindet, in der sich der Client befindet

Das obige Diagramm zeigt, wie externe Clients in mehreren Regionen www.example.com mit Cloud DNS auflösen. Clients erhalten eine Antwort mit einer IP-Adresse, die zu einem Netzwerk-TCP/UDP-Load-Balancer gehört, der sich in der Region des Clients befindet. Der Client kann dann eine Verbindung zu einer Anwendung herstellen, die in derselben Region ausgeführt wird. Jeder Client sendet Anwendungstraffic an eine lokale Instanz des Dienstes, sie verwenden jedoch alle denselben www.example.com-DNS-Endpunkt.

Sie können diese Konfiguration mit den folgenden Schritten erstellen:

  1. Sie erstellen die Netzwerk-TCP/UDP-Load-Balancer in jeder Region.

  2. Sie erstellen eine DNS-Routingrichtlinie. In der Richtlinie legen Sie den Typ auf GEO fest und für den Wert --routing-policy-data eine Liste von Zielregionen, die dem entsprechenden Netzwerk-TCP/UDP-Load-Balancer zugeordnet sind. Mit dem folgenden Befehl können Sie die im Diagramm dargestellte Einrichtung erstellen:

    gcloud dns record-sets create www.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"

Nachdem Sie diese Richtlinie angewendet haben, erhält jeder Client, der DNS-Anfragen sendet, eine DNS-Antwort mit der IP-Adresse des externen Passthrough-Network-Load-Balancers in der Region, die diesem Client am nächsten ist.

Der globale Endpunkt www.example.com kann nicht für das automatische Failover für den Traffic zwischen Regionen verwendet werden, da bei der Verwendung eines externen Passthrough-Network-Load-Balancers keine Systemdiagnose durchgeführt wird. Es liegt in Ihrer Verantwortung, ein Failover durch Änderung der DNS-Einträge manuell auszulösen.

Ein weiterer Anwendungsfall, den Sie mit diesem Ansatz berücksichtigen können, ist, dass Sie eine Anwendung haben, die HTTP(S) mit Regionalitätsanforderungen für Ihre Daten verwendet, Sie aber Daten weiterhin mit einem globalen Endpunkt bereitstellen möchten. Sie können dieses Szenario implementieren, indem Sie mehrere regionale externe Application-Load-Balancer-Instanzen unter Verwendung von DNS-Routingrichtlinien zur Standortbestimmung kombinieren. Wenn Sie keine Regionalitätsanforderungen haben, können Sie einen globalen externen Application Load Balancer verwenden.

Ein globaler DNS-Endpunkt für einen Hybriddienst

In einigen Fällen können Sie einen einzelnen Endpunkt für eine Hybridanwendung mithilfe von DNS-Routingrichtlinien zur Standortbestimmung angeben.

Das folgende Diagramm zeigt diese Architektur:

Architektur für ein Hybridszenario, bei dem Cloud DNS Traffic an die interne Passthrough-Network-Load-Balancer-Instanz für Clients in Asien und den USA und an lokale Load Balancer für Clients in Europa sendet

Das obige Diagramm zeigt, wie externe Clients in mehreren Regionen www.example.com mit Cloud DNS auflösen. Cloud DNS verweist Internetnutzer in Asien und den USA an eine IP-Adresse, die zu einem Netzwerk-TCP/UDP-Load-Balancer gehört, der sich in einer Region in ihrer Nähe befindet. Die Anwendung, auf die der Load-Balancer verweist, wird in GKE in derselben Region ausgeführt. Für Internetnutzer in Europa gibt Cloud DNS eine IP-Adresse zurück, die auf einen Load-Balancer in einem lokalen europäischen Rechenzentrum verweist, wobei die Anwendung in GKE auf VMware gehostet wird. (In diesem Beispiel werden die Anwendungen auf GKE on VMware und GKE ausgeführt. Dies ist jedoch nicht erforderlich.)

Sie können diese Konfiguration mit den folgenden Schritten erstellen:

  1. Sie erstellen die Netzwerk-TCP/UDP-Load-Balancer und den lokalen Load-Balancer in jeder Region.

  2. Sie erstellen eine DNS-Routingrichtlinie. In der Richtlinie legen Sie den Typ auf GEO fest und für den Wert --routing-policy-data eine Liste von Zielregionen, die dem entsprechenden Netzwerk-TCP/UDP-Load-Balancer zugeordnet sind. Mit dem folgenden Befehl können Sie die im Diagramm dargestellte Einrichtung erstellen:

    gcloud dns record-sets create www.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"

Wenn Sie das Flag --routing-policy-data festlegen, kann Cloud DNS unterschiedliche IP-Adressen basierend auf der nächstgelegenen Google Cloud-Region zurückgeben. Sie können den Traffic jedoch nicht basierend auf dem Land oder der Region des Clients weiterleiten. Im obigen Beispiel werden die meisten Nutzer an eine Region oder an das lokale Rechenzentrum auf ihrem Kontinent geleitet. Der Algorithmus, den Cloud DNS verwendet, um die nächstgelegene Google Cloud-Region zu bestimmen, stimmt jedoch möglicherweise nicht mit bestimmten Länder- oder geografischen Grenzen überein. Daher können Sie für Compliance-Anwendungsfälle keine DNS-Routingrichtlinien zur Standortbestimmung verwenden.

Andere Anwendungsfälle, die einen höheren Detaillierungsgrad als den in diesem Beispiel gezeigten Detaillierungsgrad erfordern, sind mit diesem hybriden Ansatz nicht möglich. Wenn Sie beispielsweise ein lokales Rechenzentrum in einem Land haben, in dem es keine Google Cloud-Region gibt, ist es nicht möglich, lokalen Traffic für Nutzer aus diesem Land oder dieser Region zu senden – Sie können den Load-Balancer nur so konfigurieren, dass IP-Adressen basierend auf der nächstgelegen Google Cloud-Region zurückgegeben werden. Wenn Sie den Traffic basierend auf dem genauen geografischen Standort oder Land einschränken oder weiterleiten möchten, können Sie einen Drittanbieter mit einem DNS-basierten globalen Server-Load-Balancing-Dienst (GSLB) verwenden.

Nächste Schritte