Regionsübergreifendes Failover für regionale externe Endpunkte mit Cloud DNS-Systemdiagnosen

1. Einführung

Der Dienst Cloud DNS bietet eine leistungsstarke, stabile und globale DNS-Lösung (Domain Name System), mit der Sie Zonen und Einträge veröffentlichen können, ohne eine selbstverwaltete DNS-Infrastruktur zu benötigen.

Cloud DNS unterstützt Systemdiagnosen und automatisierte Failover-Funktionen in den Routingrichtlinien für externe Endpunkte. Beachten Sie jedoch, dass Systemdiagnosen für diese externen Endpunkte ausschließlich in öffentlichen Zonen verfügbar sind und die Endpunkte selbst über das Internet öffentlich zugänglich sein müssen.

Lerninhalte

• So erstellen Sie einen regionalen externen Application Load Balancer mit einer nicht verwalteten Instanzgruppe.
• Cloud DNS-Systemdiagnosen für externes DNS-Routing konfigurieren
• Failover-Routingrichtlinie erstellen

Voraussetzungen

• Grundkenntnisse zu DNS.
• Grundlegende Kenntnisse zu Google Compute Engine
• Grundkenntnisse zum Application Load Balancer
• Ein Google Cloud-Projekt mit Inhaberberechtigungen
• Eine öffentliche Domain, die Ihnen gehört und für die Sie eine öffentliche Cloud DNS-Zone erstellen können.
• Die folgenden Organisationsrichtlinien werden derzeit im Google Cloud-Projekt nicht erzwungen: Shielded VMs und Internet Network Endpoint Groups.

HINWEIS:Sie müssen die Nameserver der öffentlichen Zone, die Sie in diesem Lab erstellen, bei Ihrem DNS-Anbieter aktualisieren, der Ihre Domain verwaltet.

2. Codelab-Topologie

In diesem Codelab verwenden Sie Cloud DNS-Systemdiagnosen für externe Endpunkte, um Traffic an einen regionalen externen Ersatz-Application Load Balancer umzuleiten, wenn das Backend des primären Load Balancers fehlerhaft wird.

Sie erstellen eine Website in zwei Regionen, die jeweils von einem externen Application Load Balancer bereitgestellt wird. Anschließend konfigurieren Sie Cloud DNS-Systemdiagnosen mit einer Failover-Routingrichtlinie.

3. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten Lernen einrichten

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. 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 sie jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen 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 Ihre Projekt-ID verweisen (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 Namen versuchen und sehen, 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: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten

Achtung:Eine Projekt-ID ist global eindeutig 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 nicht wiederverwendet 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 kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testzeitraum mit einem Guthaben von 300$ teilnehmen.

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.

4. Hinweis

APIs aktivieren

Prüfen Sie in Cloud Shell, ob Ihr Projekt eingerichtet ist, und konfigurieren Sie Variablen.

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]

# Define variables for regions and the domain
export REGION_A=us-central1
export REGION_B=us-west1
export DNS_ZONE=dnscodelab-zone
Export DNS_DOMAIN=gcp.<yourpublicdomain>.com
echo $projectid
echo $REGION_A
echo $REGION_B
echo $DNS_ZONE
echo $DNS_DOMAIN

Alle erforderlichen Dienste aktivieren

gcloud services enable compute.googleapis.com 
gcloud services enable dns.googleapis.com

5. Cloud Load Balancing-Infrastruktur erstellen

In diesem Abschnitt erstellen Sie die erforderlichen VPCs, Subnetze, Firewallregeln, VMs und nicht verwalteten Instanzgruppen in zwei verschiedenen Regionen, um die primären und Backup-Load-Balancer zu unterstützen.

VPC-Netzwerk

Über Cloud Shell

gcloud compute networks create external-lb-vpc --subnet-mode=custom

Erstellen Sie zwei Subnetze in REGION_A (primär) und REGION_B (Backup) zum Hosten der Backend-Webserver.

Subnetze erstellen

Über Cloud Shell

gcloud compute networks subnets create subnet-a --network=external-lb-vpc --region=$REGION_A --range=10.10.1.0/24

gcloud compute networks subnets create subnet-b --network=external-lb-vpc --region=$REGION_B --range=10.20.1.0/24

Erstellen Sie in jeder Region Nur-Proxy-Subnetze für den jeweiligen regionalen externen Application Load Balancer, der später erstellt wird.

Dieses dedizierte Nur-Proxy-Subnetz ist eine obligatorische Voraussetzung für alle Envoy-basierten regionalen Load-Balancer, die in derselben Region des VPC-Netzwerks „external-lb-vpc“ bereitgestellt werden. Diese Proxys beenden die Verbindung des Clients und stellen dann neue Verbindungen zu den Backend-Diensten her.

Über Cloud Shell

gcloud compute networks subnets create proxy-only-subnet-a \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_A \
--network=external-lb-vpc \
--range=10.129.0.0/23

gcloud compute networks subnets create proxy-only-subnet-b \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_B \
--network=external-lb-vpc \
--range=10.130.0.0/23

Netzwerk-Firewallregeln erstellen

fw-allow-health-check. Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und den gesamten TCP-Traffic von den Google Cloud-Systemen für Systemdiagnosen zulässt (in 130.211.0.0/22 und 35.191.0.0/16). In diesem Beispiel wird das Ziel-Tag „load-balanced-backend“ verwendet, um die VMs zu identifizieren, auf die die Firewallregel angewendet wird.

fw-allow-proxies. Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und TCP-Traffic über Port 80 von den verwalteten Proxys des regionalen externen Application Load Balancers zulässt. In diesem Beispiel wird das Ziel-Tag „load-balanced-backend“ verwendet, um die VMs zu identifizieren, auf die die Firewallregel angewendet wird.

Über Cloud Shell

gcloud compute firewall-rules create fw-allow-health-check \
    --network=external-lb-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
gcloud compute firewall-rules create fw-allow-proxies \
  --network=external-lb-vpc \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23,10.130.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80

Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, erstellen Sie eine Firewallregel, die:

• Gilt für alle VM-Instanzen, die über IAP zugänglich sein sollen.
• Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

Über Cloud Shell

gcloud compute firewall-rules create allow-ssh \
    --allow tcp:22 --network external-lb-vpc \
    --source-ranges 35.235.240.0/20  \
    --description "SSH with IAP" \
    --target-tags=allow-ssh

6. Cloud NAT und Cloud Router 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

Über Cloud Shell

gcloud compute routers create "$REGION_A-cloudrouter" \
--region $REGION_A --network=external-lb-vpc --asn=65501

gcloud compute routers create "$REGION_B-cloudrouter" \
--region $REGION_B --network=external-lb-vpc --asn=65501

NAT-Gateways erstellen

Über Cloud Shell

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

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

Backend-VMs und nicht verwaltete Instanzgruppen erstellen

VM in jeder Region erstellen und Webserver (z. B. Apache) installieren:

Über Cloud Shell

# Primary (Region A)
gcloud compute instances create vm-a \
--zone=$REGION_A-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-a \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--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://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_A Primary Backend |\
tee /var/www/html/index.html
systemctl restart apache2'


# Backup (Region B)
gcloud compute instances create vm-b \
--zone=$REGION_B-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-b \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--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://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_B Backup Backend |\
tee /var/www/html/index.html
systemctl restart apache2'

Erstellen Sie eine nicht verwaltete Instanzgruppe und fügen Sie ihr die VM-Instanz für jede Region hinzu:

Über Cloud Shell

# Primary (Region A)
gcloud compute instance-groups unmanaged create ig-a --zone=$REGION_A-a

gcloud compute instance-groups unmanaged add-instances ig-a --zone=$REGION_A-a --instances=vm-a

# Backup (Region B)
gcloud compute instance-groups unmanaged create ig-b --zone=$REGION_B-a

gcloud compute instance-groups unmanaged add-instances ig-b --zone=$REGION_B-a --instances=vm-b

7. Regionale externe Application Load Balancer konfigurieren

Sie konfigurieren einen vollständigen regionalen externen Application Load Balancer sowohl in REGION_A (primär) als auch in REGION_B (Ersatz).

Systemdiagnosen und Back-End-Dienste erstellen

Regionale externe Application Load Balancer basieren auf Envoy und erfordern die Konfiguration einer regionalen Systemdiagnose.

Erstellen Sie eine HTTP-Systemdiagnose (wird von den Load-Balancern verwendet, um den Zustand der Instanz zu prüfen):

In Cloud Shell

gcloud compute health-checks create http http-lb-hc-primary-region \
--port 80 \
--region=$REGION_A

​​gcloud compute health-checks create http http-lb-hc-backup-region \
--port 80 \
--region=$REGION_B

Erstellen Sie einen regionalen Back-End-Dienst und hängen Sie die Instanzgruppe in jeder Region an.**

In Cloud Shell

# Primary (Region A)
gcloud compute backend-services create be-svc-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-primary-region \
--health-checks-region=$REGION_A \
--region=$REGION_A

gcloud compute backend-services add-backend be-svc-a \
--instance-group=ig-a \
--instance-group-zone=$REGION_A-a \
--region=$REGION_A

# Backup (Region B)
gcloud compute backend-services create be-svc-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-backup-region \
--health-checks-region=$REGION_B \
--region=$REGION_B

gcloud compute backend-services add-backend be-svc-b --instance-group=ig-b --instance-group-zone=$REGION_B-a --region=$REGION_B

HINWEIS:Für ein produktionsbereites Design wird empfohlen, target-https-proxies, Port 443 und ein Zertifikat auf dem Load-Balancer zu verwenden.

Frontend-Komponenten erstellen

Erstellen Sie URL-Zuordnungen und Ziel-HTTP-Proxys in beiden Regionen:

In Cloud Shell

#Primary (Region A)
gcloud compute url-maps create url-map-a \
--default-service=be-svc-a \
--region=$REGION_A
gcloud compute target-http-proxies create http-proxy-a \
--url-map=url-map-a \
--url-map-region=$REGION_A \
--region=$REGION_A
#Backup (Region B)
gcloud compute url-maps create url-map-b \
--default-service=be-svc-b \
--region=$REGION_B

gcloud compute target-http-proxies create http-proxy-b \
--url-map=url-map-b \
--url-map-region=$REGION_B \
--region=$REGION_B

Reservieren Sie statische IP-Adressen (extern) für die Weiterleitungsregeln:

In Cloud Shell

# Primary IP (Region A)
gcloud compute addresses create rxlb-ip-a --region=$REGION_A

# Backup IP (Region B)
gcloud compute addresses create rxlb-ip-b --region=$REGION_B

Erstellen Sie die Weiterleitungsregeln für die beiden Load Balancer:

In Cloud Shell

# Primary (Region A)
gcloud compute forwarding-rules create http-fwd-rule-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_A \
--target-http-proxy-region=$REGION_A \
--address=rxlb-ip-a \
--target-http-proxy=http-proxy-a \
--ports=80

# Backup (Region B)
gcloud compute forwarding-rules create http-fwd-rule-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_B \
--target-http-proxy-region=$REGION_B \
--address=rxlb-ip-b \
--target-http-proxy=http-proxy-b \
--ports=80

Cloud DNS für Failover konfigurieren

Cloud DNS-Systemdiagnose für externe Endpunkte erstellen

Sie müssen eine dedizierte globale Systemdiagnose für die öffentlichen IP-Adressen des Load-Balancers erstellen. Dies unterscheidet sich von der internen Systemdiagnose des Load-Balancers.

Bestimmen Sie zuerst die externen IP-Adressen der Load-Balancer, um die Failover-Richtlinie zu konfigurieren, und exportieren Sie sie als Variable.

In Cloud Shell

PRIMARY_IP=$(gcloud compute addresses describe rxlb-ip-a --region=$REGION_A --format='get(address)')

BACKUP_IP=$(gcloud compute addresses describe rxlb-ip-b --region=$REGION_B --format='get(address)')

Hinweis: Falls gcloud beta nicht installiert ist, können Sie es mit den folgenden Befehlen installieren.

gcloud components update

gcloud components install beta

Erstellen Sie die globale DNS-Systemdiagnose (erfordert drei Quellregionen):

In Cloud Shell

gcloud beta compute health-checks create http dns-failover-health-check \
    --global \
    --source-regions=$REGION_A,$REGION_B,europe-west1 \
    --request-path=/ \
    --check-interval=30s \
    --port=80 \
    --enable-logging

Verwaltete öffentliche Zone und Failover-Routingrichtlinie erstellen

Erstellen Sie eine verwaltete öffentliche Zone (verwenden Sie die DNS-Domain, die Ihnen gehört):

In Cloud Shell

gcloud dns managed-zones create codelab-publiczone --dns-name=$DNS_DOMAIN --description="Codelab DNS Failover Zone"

Erstellen Sie den A-Eintrag mit einer Failover-Routingrichtlinie. Diese Richtlinie verweist auf die primäre IP-Adresse und verwendet die Systemdiagnose, um zu bestimmen, wann ein Failover zur Backup-IP-Adresse erfolgen soll.

Im folgenden Befehl werden die Namen der Load-Balancer-Weiterleitungsregeln verwendet, um auf die IP-Adressen für die Routingrichtlinie zu verweisen.

Hinweis: Ersetzen Sie den Datensatznamen „ codelab.gcp.axiszulu.com" with your actual domain name "codelab.gcp.<your public domain>.com"

gcloud beta dns record-sets create codelab.gcp.axiszulu.com. \
--type=A \
--ttl=5 \
--zone=codelab-publiczone \
--routing_policy_type=FAILOVER \
--routing-policy-primary-data=$PRIMARY_IP \
--routing-policy-backup-data-type=GEO \
--routing-policy-backup-item=location=$REGION_B,external_endpoints=$BACKUP_IP \
--health-check=dns-failover-health-check

8. Regionales Failover testen

1. Erste Validierung:Verwenden Sie ein Tool wie dig oder einen Webbrowser, um Ihre Domain abzufragen. Sie sollte in die primäre IP-Adresse ($PRIMARY_IP) aufgelöst werden und die Seite „Region A – Primäres Backend“ zurückgeben.

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <PRIMARY_IP>

Ausgabe des Browsers

2. Failover simulieren:Melden Sie sich bei der primären VM (vm-a) an und fahren Sie Apache herunter, um einen Ausfall zu simulieren:

In Cloud Shell

gcloud compute ssh vm-a --zone=$REGION_A-a --command="sudo systemctl stop apache2"

3. Fehlerstatus bestätigen:Warten Sie 2 bis 3 Minuten, bis die DNS-Systemdiagnose den primären Endpunkt als fehlerhaft markiert.

# check health status
gcloud compute backend-services get-health be-svc-a --region=${REGION_A}

Output:
backend: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instanceGroups/ig-a
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instances/vm-a
    ipAddress: 10.10.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

4. Failover validieren:Fragen Sie Ihre Domain noch einmal ab. Die Anfrage sollte jetzt zur Backup-IP ($BACKUP_IP) aufgelöst werden und die Seite „Region B – Backup-Backend“ zurückgeben.

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <BACKUP_IP>

Ausgabe des Browsers

5. Failback simulieren (optional): Stellen Sie eine SSH-Verbindung zur primären VM her und starten Sie Apache. Warten Sie, bis die DNS-Systemdiagnose den primären Endpunkt als fehlerfrei markiert. Der Traffic sollte automatisch an die primäre IP-Adresse zurückgeleitet werden.
6. Optional:Sie können das Cloud DNS-Systemdiagnose-Logging analysieren, indem Sie den folgenden Befehl in der Cloud Shell ausführen.

gcloud logging read "logName=projects/${projectid}/logs/compute.googleapis.com%2Fhealthchecks" \
--limit=10 \
--project=${projectid} \
--freshness=1d \
--format="table(timestamp:label=TIME, \
jsonPayload.healthCheckProbeResult.ipAddress:label=BACKEND_IP, \
jsonPayload.healthCheckProbeResult.previousDetailedHealthState:label=PREVIOUS_STATE, \
jsonPayload.healthCheckProbeResult.detailedHealthState:label=CURRENT_STATE, \
jsonPayload.healthCheckProbeResult.probeResultText:label=RESULT_TEXT)"

9. Bereinigungsschritte

Löschen Sie alle Komponenten, um weitere Gebühren zu vermeiden.

Über Cloud Shell

# Delete VMs
gcloud compute instances delete vm-a --zone=$REGION_A-a --quiet
gcloud compute instances delete vm-b --zone=$REGION_B-a --quiet
# Delete Load Balancer Components (Primary)
gcloud compute forwarding-rules delete http-fwd-rule-a --region=$REGION_A --quiet
gcloud compute target-http-proxies delete http-proxy-a --region=$REGION_A --quiet
gcloud compute url-maps delete url-map-a --region=$REGION_A --quiet
gcloud compute backend-services delete be-svc-a --region=$REGION_A --quiet
gcloud compute addresses delete rxlb-ip-a --region=$REGION_A --quiet
# Delete Load Balancer Components (Backup)
gcloud compute forwarding-rules delete http-fwd-rule-b --region=$REGION_B --quiet
gcloud compute target-http-proxies delete http-proxy-b --region=$REGION_B --quiet
gcloud compute url-maps delete url-map-b --region=$REGION_B --quiet
gcloud compute backend-services delete be-svc-b --region=$REGION_B --quiet
gcloud compute addresses delete rxlb-ip-b --region=$REGION_B --quiet
# Delete Instance Groups and LB Health Checks
gcloud compute instance-groups unmanaged delete ig-a --zone=$REGION_A-a --quiet
gcloud compute instance-groups unmanaged delete ig-b --zone=$REGION_B-a --quiet
gcloud compute health-checks delete http-lb-hc-primary-region --region=$REGION_A --quiet
gcloud compute health-checks delete http-lb-hc-backup-region --region=$REGION_B --quiet

# Delete Cloud DNS Records Zone and DNS Heath Checks
gcloud dns record-sets delete $DNS_DOMAIN --type=A --zone=codelab-publiczone --quiet
gcloud dns managed-zones delete codelab-publiczone --quiet

gcloud compute health-checks delete dns-failover-health-check --global --quiet

# Delete Cloud NAT and Cloud Routers
gcloud compute routers nats delete $REGION_A-nat-gw \
--router=$REGION_A-cloudrouter --region=$REGION_A --quiet

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

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

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


# Delete Subnets and Firewall Rules
gcloud compute firewall-rules delete fw-allow-health-check --quiet
gcloud compute firewall-rules delete fw-allow-proxies --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
gcloud compute networks subnets delete subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete subnet-b \
--region=$REGION_B --quiet
gcloud compute networks subnets delete proxy-only-subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete proxy-only-subnet-b \
--region=$REGION_B --quiet

gcloud compute networks delete external-lb-vpc --quiet

10. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs.

• Sie haben ein multiregionales Aktiv/Passiv-Failover mit Cloud DNS-Systemdiagnosen und einem regionalen externen Application Load Balancer erfolgreich konfiguriert und validiert.