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 Trafficsteuerung in Abhängigkeit von bestimmten Kriterien wie Gewichtung, Standort oder Systemdiagnosen konfigurieren.

Cloud DNS unterstützt die folgenden Routingrichtlinien:

• Routingrichtlinie für gewichtetes Round-Robin
• Richtlinie für das Routing nach Standortbestimmung
• Geofencing-Routingrichtlinie
• Failover-Routingrichtlinie

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

Hinweis:Zum Zeitpunkt der Erstellung dieses Labs stehen sowohl die Failover-Richtlinie als auch die Unterstützung von Systemdiagnosen in der öffentlichen Vorschau zur Verfügung.

Failover-Routing-Richtlinie

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 IP-Adressen und Sicherungs-IP-Adressen für einen Ressourceneintrag konfigurieren. Im normalen Betrieb antwortet Cloud DNS auf Abfragen mit den IP-Adressen, die im primären Satz bereitgestellt wurden. Wenn alle IP-Adressen im primären Satz fehlschlagen (Systemdiagnosestatus wird in „Fehlerhaft“ geändert), beginnt Cloud DNS mit der Bereitstellung der IP-Adressen im Sicherungssatz.

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 ILBs erstellen, für die der globale Zugriff deaktiviert ist. Cloud DNS-Failover funktioniert jedoch nicht.

Systemdiagnosen

Die DNS-Routingrichtlinie hängt von nativen Unified-Systemdiagnosen(UHC) des internen Load-Balancers ab. Ein interner Load-Balancer gilt als fehlerfrei, wenn mindestens 20 % der Back-Ends fehlerfrei sind. Systemdiagnosen für interne TCP/UDP- und interne HTTP(S)-Load-Balancer liefern unterschiedliche Informationen. Für einen internen HTTP(S)-Load-Balancer liefert die UHC den Systemstatus aller Envoy-Proxys. Für einen internen TCP/UDP-Load-Balancer erhält Cloud DNS jedoch direkte Zustandssignale von den einzelnen Back-End-Instanzen. Details zu Systemdiagnosen finden Sie hier .

Inhalt

In diesem Codelab erstellen Sie eine Website, die in zwei Regionen ausgeführt wird, und verknüpfen damit eine Failover-DNS-Routingrichtlinie. Die Einrichtung umfasst Folgendes:

Aktive Ressourcen –

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

Sicherungsressourcen –

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

Die Einrichtung ist wie unten dargestellt:

Hinweis:Um dieses Codelab zu vereinfachen, verwenden wir in jeder der Regionen, die als aktive Gruppe und als Sicherungssatz der Failover-Routingrichtlinie konfiguriert sind, einen einzelnen Load-Balancer.

Aufgaben in diesem Lab

• So erstellen Sie eine Failover-Routingrichtlinie
• DNS-Failover auslösen
• Traffic an den Sicherungssatz weiterleiten

Voraussetzungen

• Grundkenntnisse in DNS
• Grundkenntnisse hinsichtlich der Google Compute Engine
• Grundkenntnisse zum internen L4-Load-Balancer

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 Projektteilnehmer. Es handelt sich um eine Zeichenfolge, die von Google APIs nicht verwendet wird. Sie können sie jederzeit aktualisieren.
• Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und ist unveränderlich. Sie kann nach dem Festlegen nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. ist Ihnen meist egal, was es ist. In den meisten Codelabs musst du dich auf die Projekt-ID beziehen, die üblicherweise als PROJECT_ID gekennzeichnet ist. Wenn Ihnen die generierte ID nicht gefällt, können Sie eine weitere zufällige ID erstellen. Alternativ können Sie einen eigenen verwenden und nachsehen, ob er verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information gibt es noch einen dritten Wert, die Projektnummer, die von manchen APIs verwendet wird. Weitere Informationen zu allen drei Werten finden Sie in der Dokumentation.

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

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie die Standardeinstellung Keine Organisation beibehalten. 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 in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/APIs verwenden zu können. Dieses Codelab sollte ohne großen Aufwand betrieben werden. Wenn Sie Ressourcen herunterfahren möchten, um über diese Anleitung hinaus keine Kosten zu verursachen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion von 300$.

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, 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 dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:

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

3. Google Cloud SDK-Version

Beim Verfassen dieses Artikels ist 401.0.0 die neueste Version des Google Cloud SDK. Alle Befehle in diesem Lab wurden mit der neuesten Version des Google Cloud SDK getestet. Achten Sie darauf, dass Cloud Shell die neueste SDK-Version verwendet, bevor Sie fortfahren.

SDK-Version prüfen

Verwenden Sie den Befehl gcloud version, um die SDK-Version zu prüfen. Führen Sie in Cloud Shell die folgenden Befehle aus:

Befehl

gcloud version | grep "Google Cloud SDK"

Ausgabebeispiel

Google Cloud SDK 401.0.0

Nächste Schritte

Achtung:Wählen Sie basierend auf der Ausgabe des Befehls gcloud version Option 1 oder 2 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, prüfen Sie, ob Cloud Shell richtig konfiguriert 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 dennoch ändern möchten, verwenden Sie den unten aufgeführten Befehl. Die Cloud Shell-Eingabeaufforderung ändert sich von (PROJECT_ID) in (YOUR-PROJECT-ID).

Optionaler Befehl

gcloud config set project [YOUR-PROJECT-ID]

Ausgabebeispiel

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 in Cloud Shell die folgenden Befehle 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 sind, überprüfen wir dies mit dem Befehl echo. Die Ausgabe für jeden Befehl sollte der Wert sein, den wir oben mit dem Befehl export konfiguriert haben. Führen Sie in Cloud Shell die folgenden Befehle aus:

Befehle

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

Alle erforderlichen Dienste aktivieren

Verwenden Sie den Befehl gcloud services enable, um die Compute API und die DNS API zu aktivieren. Führen Sie in Cloud Shell die folgenden Befehle 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 jetzt aktiviert sind, können Sie mit dem Befehl gcloud services list alle aktivierten APIs auflisten.

Befehl

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

Ausgabebeispiel

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 Befehl gcloud compute networks create, um das VPC-Netzwerk zu erstellen. Wir legen den Subnetzmodus als benutzerdefiniert fest, da wir im nächsten Schritt eigene Subnetze erstellen werden. Führen Sie in Cloud Shell die folgenden Befehle aus.

Befehl

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

Subnetze erstellen

Erstellen Sie mit dem Befehl gcloud compute networks subnets create zwei Subnetze, eines in REGION_1 und eines in REGION_2. Führen Sie in Cloud Shell die folgenden Befehle aus:

Subnetz REGION_1

Befehl

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

Subnetz REGION_2

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 von den VPC-Subnetzen und den IP-Bereichen der Systemdiagnose des Load-Balancers zulassen.

Darüber hinaus 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 in Cloud Shell die folgenden Befehle aus:

Traffic auf 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.

• Unsere Webserver-VMs müssen den Apache-Webserver herunterladen und installieren.
• Die Client-VM muss das dnsutils-Paket herunterladen und installieren, das wir für unsere Tests verwenden werden.

Jedes Cloud NAT-Gateway ist einem einzelnen VPC-Netzwerk, einer Region und einem Cloud Router zugeordnet. Bevor wir die NAT-Gateways erstellen, müssen Sie also in jeder Region Cloud Router 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 in Cloud Shell die folgenden Befehle aus.

Cloud Router „Region_1“

Befehle

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

Cloud Router „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 in Cloud Shell die folgenden Befehle aus.

NAT-Gateway 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 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 verwaltete 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 in Cloud Shell den folgenden Befehl 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 Webserver

Führen Sie in Cloud Shell den folgenden Befehl 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-Back-End-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 "us-west1" und eine für den Webserver "us-east4".

Instanzgruppe_1

Befehle

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

Instanzgruppe_2

Befehle

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

VMs zu Instanzgruppen hinzufügen

Fügen Sie die Instanzen mit dem Befehl gcloud compute instance-groups unmanaged add-instances den soeben erstellten Instanzgruppen hinzu. Webserver REGION_1 zur Instanzgruppe REGION_1 und Webserver REGION_2 zur Instanzgruppe REGION_2 hinzufügen

Instanzgruppe_1

Befehle

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

Instanzgruppe_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 prüfen. Wir installieren das dnsutils-Paket mit einem Startskript. Führen Sie in Cloud Shell die folgenden Befehle 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

Zum Erstellen des L4-ILB müssen wir eine Systemdiagnose, einen Back-End-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 und der Zielport ist Port 80. Führen Sie in Cloud Shell die folgenden Befehle aus:

Befehl

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

Back-End-Dienste konfigurieren

Verwenden Sie den Befehl gcloud compute backend-services create, um den Back-End-Dienst zu erstellen. Nachdem die Back-End-Dienste erstellt wurden, fügen wir mit dem Befehl gcloud compute backend-services add-backend die nicht verwalteten Instanzgruppen den Back-End-Diensten hinzu. Führen Sie in Cloud Shell die folgenden Befehle 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 in Cloud Shell die folgenden Befehle aus:

REGION_1-Weiterleitungsregel

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 Richtlinie für das Failover-Routing.

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 Ressourceneintrag mit einer Failover-Routingrichtlinie zu erstellen. Führen Sie in Cloud Shell den folgenden Befehl 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. Der Sicherungssatz ist eine Richtlinie zur Standortbestimmung mit dem Load-Balancer REGION_2 als Ziel sowohl für REGION_1 als auch für REGION_2. Führen Sie in Cloud Shell die folgenden Befehle 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

Ausgabebeispiel

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

Notieren Sie sich die IP-Adressen der beiden internen Load-Balancer, bevor Sie die Failover-Einrichtung testen. Führen Sie in Cloud Shell die folgenden Befehle aus.

Befehl

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

Ausgabebeispiel

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

Jetzt melden wir uns in der Clientinstanz an und testen die DNS-Auflösung. Gehen Sie in der Webkonsole zu "Compute Engine | VM-Instanzen“

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

Da wir uns nun auf der Client-VM befinden, können Sie den Befehl dig verwenden, 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 im DNS-Eintrag auf 5 Sekunden festgelegt ist, wurde ein Ruhemodus-Timer von 6 Sekunden hinzugefügt. Der Ruhemodus-Timer sorgt dafür, dass Sie für jede DNS-Anfrage eine nicht zwischengespeicherte DNS-Antwort erhalten. Die Ausführung dieses Befehls dauert ungefähr eine Minute.

In der Ausgabe sehen Sie die IP-Adresse des Load-Balancers im primären Satz des Ressourceneintrags. In unserem Setup ist dies die IP-Adresse des Load-Balancers in der Region us-west1.

11. Failover testen

Wir simulieren einen Failover, indem wir das Netzwerk-Tag aus der VM REGION_1 entfernen. Dadurch wird der Zugriff auf Port 80 blockiert und die Systemdiagnosen schlagen fehl.

Netzwerk-Tag entfernen

Verwenden Sie den Befehl gcloud compute instances remove-tags, um das Netzwerk-Tag von der VM zu entfernen. Führen Sie in Cloud Shell den folgenden Befehl 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 Test der DNS-Auflösung noch einmal aus.

DNS-Auflösung

Führen Sie auf der Clientinstanz 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 Sicherungssatz des Ressourceneintrags. In unserem Setup ist dies die IP-Adresse des Load-Balancers in der Region us-east4.

12. Traffic-Ausgleich testen

Standardmäßig wird bei der Failover-Richtlinie die IP-Adresse des primären Endpunkts für alle DNS-Anfragen zurückgegeben. Die Sicherungs-IP-Adressen werden nur zurückgegeben, wenn die primäre IP-Adresse bei der Systemdiagnose nicht besteht. Mit Cloud DNS können Nutzer die Trickle-Ratio konfigurieren. Dadurch kann Cloud DNS einen Teil des Traffics an die Sicherungsziele 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 dies zu testen, fügen wir das Netzwerk-Tag wieder dem Webserver REGION_1 hinzu.

Netzwerk-Tag hinzufügen

Fügen Sie das Tag wieder der Webserver-VM 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 sind in 10 Sekunden erfolgreich.

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

Führen Sie auf der Clientinstanz folgenden Befehl aus:

Befehl

dig +short failover.example.com

DNS-Eintrag aktualisieren

Nun ändern wir den DNS-Eintrag für failover.example.com so, dass 30% des Traffics an den Sicherungssatz weitergeleitet werden, auch wenn die primäre Instanz fehlerfrei ist. Führen Sie in Cloud Shell den folgenden Befehl 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 auf der Client-VM den folgenden Befehl aus. Sie werden feststellen, dass der DNS-Eintrag failover.example.com ungefähr in die IP-Adresse des primären Load-Balancers aufgelöst wird. In 70% der Fälle zur IP-Adresse des Back-up-Load-Balancers in 30% aller Fälle.

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

13. Bereinigungsschritte

Führen Sie die folgenden Befehle über 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 an den Sicherungssatz weiterleiten

Was liegt als Nächstes an?

• Versuchen Sie, mehrere IP-Adressen für aktive und Sicherungssätze einzurichten.
• Nicht verwalteten Instanzgruppen mehrere Back-End-VMs hinzufügen
• Richten Sie für die Richtlinie zur Standortbestimmung im Sicherungssatz mehrere Load-Balancer in verschiedenen Regionen ein.

Weitere Informationen

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