Multiregionales Failover mit Cloud DNS-Routingrichtlinien und Systemdiagnosen für den internen TCP/UDP-Load-Balancer

1. Einführung

Zuletzt aktualisiert: 22.09.2022

Was ist eine DNS-Routingrichtlinie?

Mit Cloud DNS-Routingrichtlinien können Nutzer die DNS-basierte Traffic-Steuerung anhand bestimmter Kriterien wie Gewichtung, geografischer Standort oder Systemdiagnosen konfigurieren.

Cloud DNS unterstützt die folgenden Routingrichtlinien:

• Routingrichtlinie für gewichtetes Round Robin
• Routingrichtlinie für Standortbestimmung
• Geofencing-Routingrichtlinie
• Failover-Routingrichtlinie

In diesem Lab konfigurieren und testen Sie die Failover-Routingrichtlinie.

Hinweis:Zum Zeitpunkt der Erstellung dieses Labs sind sowohl die Failover-Richtlinie als auch die Unterstützung für Systemdiagnosen in der öffentlichen Vorschau verfügbar.

Failover-Routingrichtlinie

Cloud DNS unterstützt Systemdiagnosen für interne TCP/UDP-Load-Balancer, für die der globale Zugriff aktiviert ist. Mit einer Failover-Routingrichtlinie können Sie primäre und Backup-IPs für einen Ressourcendatensatz konfigurieren. Im Normalbetrieb antwortet Cloud DNS auf Anfragen mit den im primären Satz bereitgestellten IP-Adressen. Wenn alle IP-Adressen im primären Satz fehlschlagen (der Systemzustand ändert sich zu „fehlerhaft“), beginnt Cloud DNS, die IP-Adressen im Backup-Satz bereitzustellen.

Hinweis:Damit Cloud DNS wie erwartet mit Systemdiagnosen funktioniert, muss der globale Zugriff auf dem Load Balancer aktiviert sein. Nutzer können Routingrichtlinien für interne Load Balancer erstellen, für die der globale Zugriff deaktiviert ist. Cloud DNS-Failover funktioniert jedoch nicht.

Systemdiagnosen

Die DNS-Routingrichtlinie hängt von den einheitlichen Systemdiagnosen(Unified Health Checks, UHC) des nativen internen Load Balancers ab. Ein Internal Load Balancer gilt als fehlerfrei, wenn mindestens 20 % der Back-Ends fehlerfrei sind. Systemdiagnosen für interne TCP/UDP- und HTTP(S)-Load-Balancer liefern unterschiedliche Informationen. Bei einem internen HTTP(S)-Load-Balancer stellt UHC den Gesundheitsstatus aller Envoy-Proxys bereit. Bei einem internen TCP/UDP-Load-Balancer erhält Cloud DNS direkte Gesundheitssignale von den einzelnen Backend-Instanzen. Weitere Informationen zu Health Checks

Umfang

In diesem Codelab erstellen Sie eine Website, die in zwei Regionen ausgeführt wird, und weisen ihr eine Failover-DNS-Routingrichtlinie zu. Der Testaufbau umfasst:

Aktive Ressourcen –

• Interner L4-Load-Balancer in REGION_1
• Eine VM, auf der der Apache-Webserver in REGION_1 ausgeführt wird

Sicherungsressourcen –

• Interner L4-Load-Balancer in REGION_2
• Eine VM, auf der der Apache-Webserver in REGION_2 ausgeführt wird

Die Einrichtung erfolgt wie unten dargestellt:

Hinweis:Um dieses Codelab zu vereinfachen, verwenden wir in jeder Region einen einzelnen Load Balancer, der als aktives und Backup-Set der Failover-Routingrichtlinie konfiguriert ist.

Lerninhalte

• Failover-Routingrichtlinie erstellen
• DNS-Failover auslösen
• Traffic langsam an die Sicherungsgruppe weiterleiten

Voraussetzungen

• Grundlegende DNS-Kenntnisse
• Grundkenntnisse hinsichtlich der Google Compute Engine
• Grundkenntnisse des internen L4-Load-Balancers

2. Einrichtung und Anforderungen

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

• Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können ihn jederzeit aktualisieren.
• Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und ist unveränderlich (kann nach der Festlegung nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (sie wird in der Regel als PROJECT_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie es mit einem eigenen versuchen und sehen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten

Achtung:Eine Projekt-ID muss global eindeutig sein und kann nach der Auswahl nicht mehr von anderen verwendet werden. Sie sind der einzige Nutzer dieser ID. Auch wenn ein Projekt gelöscht wird, kann die ID nie wieder verwendet werden.

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie den Standardspeicherort auf Keine Organisation belassen. Wenn Sie ein Google Workspace-Konto verwenden, wählen Sie einen Standort aus, der für Ihre Organisation sinnvoll ist.

2. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs sollte keine oder nur geringe Kosten verursachen. Wenn Sie Ressourcen herunterfahren möchten, damit Ihnen nach Abschluss dieser Anleitung keine Kosten mehr in Rechnung gestellt werden, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neue Nutzer von Google Cloud kommen für das Programm für kostenlose Testversionen mit einem Guthaben von 300$ infrage.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

3. Google Cloud SDK-Version

Zum Zeitpunkt der Erstellung dieses Dokuments ist 401.0.0 die aktuelle Google Cloud SDK-Version. Alle Befehle in diesem Lab wurden mit der neuesten Version des Google Cloud SDK getestet. Prüfen Sie, ob in Cloud Shell die neueste Version des SDK verwendet wird, bevor Sie fortfahren.

SDK-Version prüfen

Prüfen Sie die SDK-Version mit dem Befehl gcloud version. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehl

gcloud version | grep "Google Cloud SDK"

Beispielausgabe

Google Cloud SDK 401.0.0

Nächste Schritte

Achtung:Wählen Sie Option 1 oder 2 basierend auf der Ausgabe des Befehls gcloud version aus.

1. Wenn die SDK-Version 401.0.0 oder höher ist, fahren Sie mit dem nächsten Abschnitt fort.
2. Wenn die SDK-Version niedriger als 401.0.0 ist, führen Sie den unten aufgeführten Befehl aus, um das SDK zu aktualisieren.

Optionaler Befehl

sudo apt-get update && sudo apt-get install google-cloud-sdk

4. Hinweis

Bevor Sie mit der Bereitstellung der oben beschriebenen Architektur beginnen, sollten Sie prüfen, ob die Cloud Shell richtig konfiguriert ist und alle erforderlichen APIs aktiviert sind.

Projekt-ID einrichten

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist. Wenn Ihre Cloud Shell-Eingabeaufforderung wie die Ausgabe unten aussieht und Sie die Projekt-ID nicht ändern möchten, können Sie mit dem nächsten Schritt (Umgebungsvariablen festlegen) fortfahren.

USER@cloudshell:~ (PROJECT_ID)$

Wenn Sie die Projekt-ID trotzdem ändern möchten, verwenden Sie den unten aufgeführten Befehl. Die Cloud Shell-Eingabeaufforderung ändert sich von (PROJECT_ID) zu (YOUR-PROJECT-ID).

Optionaler Befehl

gcloud config set project [YOUR-PROJECT-ID]

Beispielausgabe

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

Umgebungsvariablen festlegen

Umgebungsvariablen festlegen

Wir verwenden den Befehl export, um die Umgebungsvariablen festzulegen. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehle

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

Hinweis:In diesem Lab verwenden wir die Regionen „us-west1“ und „us-east4“. Die Rechenkapazität kann in einer Zone begrenzt sein. Wenn beim Erstellen der VMs Kapazitätsfehler auftreten, verwenden Sie eine andere Region/Zone. Eine Liste der verfügbaren Regionen und Zonen finden Sie hier.

Bestätigen

Nachdem die Umgebungsvariablen festgelegt wurden, können wir sie mit dem Befehl echo überprüfen. Die Ausgabe für jeden Befehl sollte der Wert sein, den wir oben mit dem Befehl export konfiguriert haben. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehle

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

Alle erforderlichen Dienste aktivieren

Aktivieren Sie die Compute API und die DNS API mit dem Befehl gcloud services enable. Führen Sie die folgenden Befehle in Cloud Shell aus.

Compute API aktivieren

Befehl

gcloud services enable compute.googleapis.com

DNS API aktivieren

Befehl

gcloud services enable dns.googleapis.com

Bestätigen

Nachdem die Dienste aktiviert wurden, können wir mit dem Befehl gcloud services list alle aktivierten APIs auflisten.

Befehl

gcloud services list | grep -E 'compute|dns'

Beispielausgabe

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. VPC-Netzwerk, Subnetze und Firewallregeln erstellen

In diesem Abschnitt erstellen wir das VPC-Netzwerk, zwei Subnetze (eines in jeder Region) und die erforderlichen Firewallregeln.

VPC-Netzwerk erstellen

Verwenden Sie den gcloud compute networks create-Befehl, um das VPC-Netzwerk zu erstellen. Wir legen den Subnetzmodus auf „Benutzerdefiniert“ fest, da wir im nächsten Schritt eigene Subnetze erstellen. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehl

gcloud compute networks create my-vpc --subnet-mode custom

Subnetze erstellen

Verwenden Sie den Befehl gcloud compute networks subnets create, um zwei Subnetze zu erstellen, eines in REGION_1 und eines in REGION_2. Führen Sie die folgenden Befehle in Cloud Shell aus.

REGION_1-Subnetz

Befehl

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

REGION_2-Subnetz

Befehl

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

Firewallregeln erstellen

Sie müssen Traffic auf Port 80 aus den VPC-Subnetzen und aus den IP-Bereichen der Systemdiagnose des Load-Balancers zulassen.

Außerdem müssen Sie eine Firewallregel erstellen, um SSH-Traffic auf den Client-VMs zuzulassen.

Verwenden Sie den Befehl gcloud compute firewall-rules create, um die Firewallregeln zu erstellen. Führen Sie die folgenden Befehle in Cloud Shell aus.

Traffic über Port 80 zulassen

Befehl

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

SSH-Traffic auf der Client-VM zulassen

Befehl

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Cloud NAT erstellen

Sie benötigen Cloud NAT-Gateways in beiden Regionen, damit die privaten VMs Pakete aus dem Internet herunterladen und installieren können.

• Auf unseren Webserver-VMs muss der Apache-Webserver heruntergeladen und installiert werden.
• Die Client-VM muss das dnsutils-Paket herunterladen und installieren, das wir für unsere Tests verwenden.

Jedes Cloud NAT-Gateway ist einem einzelnen VPC-Netzwerk, einer Region und einem Cloud Router zugeordnet. Bevor wir die NAT-Gateways erstellen, müssen wir also Cloud Router in jeder Region erstellen.

Cloud Router erstellen

Verwenden Sie den Befehl gcloud compute routers create, um Cloud Router in den Regionen „us-west1“ und „us-east4“ zu erstellen. Führen Sie die folgenden Befehle in Cloud Shell aus.

Region_1 Cloud Router

Befehle

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

Cloud Router für Region 2

Befehle

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

NAT-Gateways erstellen

Verwenden Sie den Befehl gcloud compute routers nat create, um die NAT-Gateways in den Regionen „us-west1“ und „us-east4“ zu erstellen. Führen Sie die folgenden Befehle in Cloud Shell aus.

NAT-Gateway für Region 1

Befehle

gcloud compute routers nats create "${REGION_1}-nat-gw" \
--router="${REGION_1}-cloudrouter" \
--router-region=$REGION_1 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

NAT-Gateway für Region 2

Befehle

gcloud compute routers nats create "${REGION_2}-nat-gw" \
--router="${REGION_2}-cloudrouter" \
--router-region=$REGION_2 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

7. Compute Engine-VMs erstellen

In diesem Abschnitt erstellen Sie die Webserver, nicht verwalteten Instanzgruppen für die Webserver und die Client-VM.

Hinweis:In diesem Lab verwenden wir die Regionen „us-west1“ und „us-east4“. Die Rechenkapazität kann in einer Zone begrenzt sein. Wenn beim Erstellen der VMs Kapazitätsfehler auftreten, verwenden Sie eine andere Region/Zone. Eine Liste der verfügbaren Regionen und Zonen finden Sie hier.

Webserver-VMs erstellen

Verwenden Sie den Befehl gcloud compute instances create, um die Webserver zu erstellen. Wir müssen zwei Webserver erstellen, einen in REGION_1 und einen in REGION_2. Wir verwenden Startskripts, um Apache auf den Webservern zu installieren und zu konfigurieren.

REGION_1 Webserver

Führen Sie den folgenden Befehl in Cloud Shell aus.

Befehl

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

REGION_2 Web Server

Führen Sie den folgenden Befehl in Cloud Shell aus.

Befehl

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Nicht verwaltete Instanzgruppen erstellen

In diesem Abschnitt erstellen wir zwei nicht verwaltete Instanzgruppen. Wir verwenden diese Instanzgruppen im nächsten Abschnitt, um die ILB-Backend-Dienste zu konfigurieren. Nachdem die Instanzgruppen erstellt wurden, fügen wir die Webserver-VMs zu diesen Instanzgruppen hinzu.

Nicht verwaltete Instanzgruppen erstellen

Erstellen Sie mit dem Befehl gcloud compute instance-groups unmanaged create zwei nicht verwaltete Instanzgruppen, eine für den Webserver in „us-west1“ und eine für den Webserver in „us-east4“.

Instanzgruppe für Region 1

Befehle

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Instanzgruppe für Region 2

Befehle

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

VMs zu den Instanzgruppen hinzufügen

Verwenden Sie den Befehl gcloud compute instance-groups unmanaged add-instances, um die Instanzen den gerade erstellten Instanzgruppen hinzuzufügen. Fügen Sie den Webserver für REGION_1 der Instanzgruppe für REGION_1 und den Webserver für REGION_2 der Instanzgruppe für REGION_2 hinzu.

Instanzgruppe für Region 1

Befehle

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Instanzgruppe für Region 2

Befehle

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

Client-VM erstellen

Wir verwenden diese VM, um Tests auszuführen und unsere DNS-Konfiguration zu überprüfen. Wir verwenden ein Startskript, um das dnsutils-Paket zu installieren. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehl

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. Interne L4-Load-Balancer erstellen

Um den ILB der Schicht 4 zu erstellen, müssen wir eine Systemdiagnose, einen Backend-Dienst und eine Weiterleitungsregel erstellen.

Systemdiagnose erstellen

Verwenden Sie den Befehl gcloud compute health-checks create, um die Systemdiagnose zu erstellen. Wir erstellen eine einfache HTTP-Systemdiagnose. Der Zielport ist Port 80. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehl

gcloud compute health-checks create http http-hc --port 80

Backend-Dienste konfigurieren

Verwenden Sie den Befehl gcloud compute backend-services create, um den Backend-Dienst zu erstellen. Nachdem die Back-End-Dienste erstellt wurden, fügen wir ihnen mit dem Befehl gcloud compute backend-services add-backend die nicht verwalteten Instanzgruppen hinzu. Führen Sie die folgenden Befehle in Cloud Shell aus.

Back-End-Dienst erstellen

Befehle

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

Back-End hinzufügen

Befehl

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

Weiterleitungsregeln erstellen

Verwenden Sie den Befehl gcloud compute forwarding-rules create, um die Weiterleitungsregeln in beiden Regionen zu erstellen. Führen Sie die folgenden Befehle in Cloud Shell aus.

Weiterleitungsregel für REGION_1

Befehle

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

Weiterleitungsregel für REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. DNS konfigurieren

In diesem Abschnitt erstellen wir die private Zone und einen DNS-Datensatz mit der Failover-Routingrichtlinie.

Private DNS-Zone erstellen

Verwenden Sie den Befehl gcloud dns managed-zones create, um eine private Zone für „example.com“ zu erstellen. Wir verwenden diese Zone, um einen Ressourcendatensatz mit Failover-Routingrichtlinie zu erstellen. Führen Sie den folgenden Befehl in Cloud Shell aus.

Befehle

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc 

DNS-Eintrag mit Failover-Routingrichtlinie erstellen

Verwenden Sie den Befehl gcloud dns record-sets create, um einen DNS-Eintrag mit der Failover-Routingrichtlinie zu erstellen. Das primäre Ziel ist der Load-Balancer in REGION_1. Cloud DNS unterstützt nur geobasierte Sicherungsziele. Das Sicherungsset ist eine Geolocation-Richtlinie mit dem Load Balancer REGION_2 als Ziel für REGION_1 und REGION_2. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehl

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

Beispielausgabe

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. DNS-Auflösung testen

Bevor wir das Failover-Setup testen, notieren wir uns die IP-Adressen für beide internen Load-Balancer. Führen Sie die folgenden Befehle in Cloud Shell aus.

Befehl

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

Beispielausgabe

In diesem Beispiel hat us-west1-ilb die IP-Adresse 10.1.0.4 und us-east4-ilb die IP-Adresse 10.2.0.3.

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

Wir melden uns jetzt bei der Client-Instanz an und testen die DNS-Auflösung. Rufen Sie in der Webkonsole „Compute Engine | VM-Instanzen“ auf.

Klicken Sie auf die Schaltfläche „SSH“, um sich über die Konsole bei der Clientinstanz anzumelden.

Verwenden Sie nun in der Client-VM den Befehl dig, um den Domainnamen failover.example.com aufzulösen.

Die Schleife ist so konfiguriert, dass der Befehl zehnmal mit einem Ruhemodus-Timer von 6 Sekunden ausgeführt wird.

Befehl

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Da die TTL für den DNS-Eintrag auf 5 Sekunden festgelegt ist, wurde ein Sleep-Timer von 6 Sekunden hinzugefügt. Der Sleep-Timer sorgt dafür, dass Sie für jede DNS-Anfrage eine nicht im Cache gespeicherte DNS-Antwort erhalten. Die Ausführung dieses Befehls dauert etwa eine Minute.

In der Ausgabe sehen Sie die IP-Adresse des Load-Balancers im primären Satz des Ressourceneintrags. In unserer Konfiguration ist das die IP-Adresse des Load-Balancers in der Region „us-west1“.

11. Failover testen

Wir simulieren ein Failover, indem wir das Netzwerktag von der REGION_1-VM entfernen. Dadurch wird der Zugriff auf Port 80 blockiert und die Systemdiagnosen schlagen fehl.

Netzwerktag entfernen

Verwenden Sie den Befehl gcloud compute instances remove-tags, um das Netzwerk-Tag von der VM zu entfernen. Führen Sie den folgenden Befehl in Cloud Shell aus.

Befehl

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

Die Systemdiagnose schlägt in 10 Sekunden fehl. Führen Sie den DNS-Auflösungstest noch einmal aus.

DNS-Auflösung

Führen Sie auf der Clientinstanz den folgenden Befehl aus:

Befehl

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

In der Ausgabe sehen Sie die IP-Adresse des Load-Balancers im Backup-Set des Ressourceneintrags. In unserem Setup ist das die IP-Adresse des Load-Balancers in der Region „us-east4“.

12. Traffic-Trichterung testen

Standardmäßig gibt die Failover-Richtlinie die IP-Adresse des primären Endpunkts für alle DNS-Anfragen zurück und nur die Backup-IPs, wenn die Systemdiagnosen des primären Endpunkts fehlschlagen. Mit Cloud DNS können Nutzer das Trickle Ratio konfigurieren. Dadurch kann Cloud DNS einen Teil des Traffics an die Backup-Ziele senden, auch wenn die primären Ziele fehlerfrei sind. Das Verhältnis muss ein Wert zwischen 0 und 1 sein. Der Standardwert ist 0.

Um das zu testen, fügen wir dem Webserver REGION_1 das Netzwerk-Tag wieder hinzu.

Netzwerk-Tag hinzufügen

Fügen Sie das Tag der Webserver-VM wieder hinzu, um HTTP-Traffic zur VM in der primären Region zuzulassen. Führen Sie in Cloud Shell den folgenden Befehl aus.

Befehl

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

Die Systemdiagnosen werden in 10 Sekunden bestanden.

Prüfen Sie, ob die DNS-Auflösung auf den primären Load-Balancer verweist. In unserer Konfiguration ist das die IP-Adresse des Load Balancers in der Region „us-west1“.

Führen Sie auf der Clientinstanz den folgenden Befehl aus:

Befehl

dig +short failover.example.com

DNS-Eintrag aktualisieren

Wir ändern jetzt den DNS-Eintrag für failover.example.com, um 30% des Traffics an den Backup-Satz weiterzuleiten, auch wenn der primäre Satz fehlerfrei ist. Führen Sie den folgenden Befehl in Cloud Shell aus.

Befehl

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

DNS-Auflösung

Führen Sie den folgenden Befehl auf der Client-VM aus. Sie werden feststellen, dass der DNS-Eintrag failover.example.com zu etwa 70% der Zeit in die IP-Adresse des primären Load-Balancers und zu etwa 30% der Zeit in die IP-Adresse des Backup-Load-Balancers aufgelöst wird.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. Bereinigungsschritte

Führen Sie die folgenden Befehle in Cloud Shell aus, um die in diesem Lab verwendeten Ressourcen zu bereinigen:

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

gcloud compute routers nats delete $REGION_1-nat-gw \
--router=$REGION_1-cloudrouter --region=$REGION_1 --quiet

gcloud compute routers nats delete $REGION_2-nat-gw \
--router=$REGION_2-cloudrouter --region=$REGION_2 --quiet

gcloud compute routers delete $REGION_1-cloudrouter \
--region=$REGION_1 --quiet

gcloud compute routers delete $REGION_2-cloudrouter \
--region=$REGION_2 --quiet

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. Glückwunsch

Sie haben die Cloud DNS-Failover-Routingrichtlinie erfolgreich bereitgestellt und getestet.

Behandelte Themen

• Cloud DNS-Failover-Routingrichtlinie konfigurieren
• DNS-Failover testen
• Traffic auf Backup-Set verteilen

Nächste Schritte

• Versuchen Sie, mehrere IP-Adressen für aktive und Backup-Sets einzurichten.
• Mehrere Backend-VMs zu nicht verwalteten Instanzgruppen hinzufügen
• Richten Sie mehrere Load Balancer in verschiedenen Regionen für die Geolocation-Richtlinie im Backup-Set ein.

Weitere Informationen

https://cloud.google.com/dns/docs/zones/manage-routing-policies