Internen Passthrough-Network-Load-Balancer als nächsten Hop einrichten (mit Tags)

In dieser Anleitung wird anhand eines Beispiels gezeigt, wie Sie einen internen Passthrough-Network-Load-Balancer als nächsten Hop bereitstellen, an den Pakete entlang des Pfads zu ihrem endgültigen Ziel weitergeleitet werden. Mit Netzwerk-Tags können Sie die spezifischen Clientinstanzen konfigurieren, für die die Route gilt.

In dieser Anleitung wird davon ausgegangen, dass Sie mit der Funktionsweise eines internen Passthrough-Network-Load-Balancers, den zugehörigen Komponenten wie Firewallregeln und Systemdiagnosen sowie mit der Verwendung interner Passthrough-Network-Load-Balancer als nächste Hops zum Weiterleiten von Paketen auf einer Route vertraut sind.

Durch die Verwendung interner Passthrough-Network-Load-Balancer als nächste Hops können Sie Appliances von Drittanbietern auf hochverfügbare, horizontal skalierte Weise einbinden. Dazu müssen Sie eine benutzerdefinierte statische Route konfigurieren und als nächsten Hop den Load-Balancer festlegen, der den Traffic für das Zielpräfix auf den Pool der Drittanbieter-VM-Appliances mit Systemdiagnose verteilt. Sie haben mehrere Möglichkeiten, um Ihre nächsten Hops auszuwählen, um die Hochverfügbarkeit dieser Drittanbieter-Appliances zu unterstützen:

• IP-Adresse als nächsten Hop angeben: Verwenden Sie die interne IP-Adresse, die der Weiterleitungsregel zugeordnet ist, als nächsten Hop. Die virtuelle IP-Adresse dieses Load-Balancers kann über Peers erkannt werden, ohne die benutzerdefinierte Route über seine Peers exportieren zu müssen.
• Netzwerk-Tags verwenden: Sie können ein Netzwerk-Tag angeben, damit die Route für den internen Passthrough-Network-Load-Balancer als nächster Hop nur für Clientinstanzen gilt, die mit dem Tag konfiguriert wurden. Dadurch können Sie auswählen, welche Clientinstanzen mit welcher getaggten Route für den internen Passthrough-Network-Load-Balancer als nächster Hop gefüllt werden und an welche Appliances Ihr Traffic weitergeleitet werden soll. Sie müssen die verschiedenen Clientinstanzen nicht in separate VPCs unterteilen, die jeweils auf ihre bevorzugten internen Passthrough-Network-Load-Balancer mit einer Reihe von Appliances als Frontend verweisen. Getaggte Routen werden nicht über VPC-Netzwerk-Peering exportiert oder importiert.
• Mehrere Routen für dasselbe Zielpräfix konfigurieren: Mit Tags können Sie mehrere Routen zum selben Ziel mit unterschiedlichen internen Load-Balancern als nächste Hops angeben. Obwohl ECMP nicht unterstützt wird (gleiches Zielpräfix, dieselben Tags, unterschiedliche nächste Hops), können Sie verschiedene Tags oder unterschiedliche Prioritäten für dieselben Zielrouten verwenden.

Einrichtung: Übersicht

Verwaltete Instanzgruppen, die VMs mit einer einzelnen NIC verwenden, sind in verschiedenen Regionen definiert, wobei Linux-Instanzen dafür konfiguriert sind, für den gesamten ausgehenden Traffic zum Internet (ausgehender Nord-Süd-Traffic-Fluss) eine SNAT-Übersetzung durchzuführen. Regionaler Failover wird manuell ausgelöst. In dieser Anleitung wird auch Ost-West-Konnektivität mit symmetrischem Hashing mit einem internen Passthrough-Network-Load-Balancer als nächstem Hop veranschaulicht.

Die Schritte in diesem Abschnitt zeigen, wie Sie folgende Elemente konfigurieren:

1. Beispiele für VPC-Netzwerke mit benutzerdefinierten Subnetzen
2. Firewall-Regeln, die eingehende Verbindung zu Backend-VMs ermöglichen
3. Vom Backend verwaltete Instanzgruppen, die NAT-Gateways bereitstellen
4. Client-VMs zum Testen von Verbindungen
5. Die folgenden Komponenten eines internen Passthrough-Network-Load-Balancers:
   • Eine Systemdiagnose für den Backend-Dienst
   • Einen internen Backend-Dienst
   • Eine interne Weiterleitungsregel und eine IP-Adresse für das Frontend des Load-Balancers

Die Architektur dieses Beispiels sieht so aus:

Konfiguration des internen Passthrough-Network-Load-Balancers als nächster Hop (zum Vergrößern klicken)

Wenn Sie die Schritte in dieser Anleitung ausführen, ersetzen Sie REGION_A und REGION_B durch die entsprechenden Regionen, die Sie für dieses Beispiel verwenden möchten.

VPC-Netzwerke und Subnetze erstellen

1. Erstellen Sie ein VPC-Netzwerk mit dem Namen hub-vpc.

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

2. Erstellen Sie ein Subnetz in hub-vpc in REGION_A.

   gcloud compute networks subnets create hub-subnet-a \
       --network hub-vpc \
       --range 10.0.0.0/24 \
       --region REGION_A
   

3. Erstellen Sie ein Subnetz in hub-vpc in region B.

   gcloud compute networks subnets create hub-subnet-b \
       --network hub-vpc \
       --range 10.0.1.0/24 \
       --region REGION_B
   

4. Erstellen Sie ein VPC-Netzwerk mit dem Namen spoke1-vpc.

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

5. Erstellen Sie ein Subnetz in spoke1-vpc.

   gcloud compute networks subnets create spoke1-subnet1 \
       --network spoke1-vpc \
       --range 192.168.0.0/24 \
       --region REGION_A
   

6. Erstellen Sie ein VPC-Netzwerk mit dem Namen spoke2-vpc.

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

7. Erstellen Sie ein Subnetz in spoke2-vpc.

   gcloud compute networks subnets create spoke2-subnet1 \
       --network spoke2-vpc \
       --range 192.168.1.0/24 \
       --region REGION_A
   

Firewallregeln konfigurieren

1. Konfigurieren Sie die folgenden Firewallregeln, um zuzulassen, dass TCP-, UDP- und ICMP-Traffic Instanzen aus den angegebenen Quellbereichen erreicht.

   gcloud compute firewall-rules create hub-vpc-web-ping-dns \
       --network hub-vpc \
       --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

   gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \
       --network spoke1-vpc \
       --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

   gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \
       --network spoke2-vpc \
       --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,10.0.1.0/24,192.168.0.0/24,192.168.1.0/24
   

2. Erstellen Sie eine Firewallregel, damit Systemdiagnose-Prober auf Instanzen in hub-vpc zugreifen können.

   gcloud compute firewall-rules create hub-vpc-health-checks \
       --network hub-vpc \
       --allow tcp:80 \
       --target-tags natgw \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

3. Erstellen Sie Firewallregeln, um den SSH-Zugriff für Instanzen in allen Subnetzen zuzulassen. Wenn Sie Identity-Aware Proxy für die TCP-Weiterleitung bevorzugen (empfohlen), folgen Sie dieser Anleitung, um SSH zu aktivieren.

   gcloud compute firewall-rules create hub-vpc-allow-ssh \
       --network hub-vpc \
       --allow tcp:22
   

   gcloud compute firewall-rules create spoke1-vpc-allow-ssh \
       --network spoke1-vpc \
       --allow tcp:22
   

   gcloud compute firewall-rules create spoke2-vpc-allow-ssh \
       --network spoke2-vpc \
       --allow tcp:22
   

VPC-Netzwerk-Peering konfigurieren

1. Erstellen Sie ein Peering von hub-vpc zu spoke1-vpc.

   gcloud compute networks peerings create hub-to-spoke1 \
       --network hub-vpc \
       --peer-network spoke1-vpc \
       --peer-project PROJECT_ID \
       --export-custom-routes
       

2. Erstellen Sie ein Peering von spoke1-vpc zu hub-vpc.

   gcloud compute networks peerings create spoke1-to-hub \
       --network spoke1-vpc \
       --peer-network hub-vpc \
       --peer-project PROJECT_ID \
       --import-custom-routes
   

3. Erstellen Sie ein Peering von hub-vpc zu spoke2-vpc.

   gcloud compute networks peerings create hub-to-spoke2 \
       --network hub-vpc \
       --peer-network spoke2-vpc \
       --peer-project PROJECT_ID \
       --export-custom-routes
   

4. Erstellen Sie ein Peering von spoke2-vpc zu hub-vpc.

   gcloud compute networks peerings create spoke2-to-hub \
       --network spoke2-vpc \
       --peer-network hub-vpc \
       --peer-project PROJECT_ID \
       --import-custom-routes
   

NAT-Gateway-VMs und Load-Balancing-Ressourcen in Region A erstellen

Erstellen Sie das Backend der verwalteten Instanzgruppe in REGION_A. Erstellen Sie dann die Load-Balancing-Ressourcen und die Routen für den nächsten Hop.

Verwaltete Instanzgruppe erstellen

1. Erstellen Sie eine Instanzvorlage, um ein NAT-Gateway in region A bereitzustellen.

   gcloud compute instance-templates create hub-natgw-region-a-template \
       --network hub-vpc \
       --subnet hub-subnet-a \
       --region REGION_A \
       --machine-type n1-standard-2 \
       --can-ip-forward \
       --tags natgw \
       --metadata startup-script='#! /bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
   # iptables configuration
   iptables -t nat -F
   sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
   iptables-save
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   apt-get update
   apt-get install apache2 tcpdump -y
   a2ensite default-ssl
   a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html \
   systemctl restart apache2'
   

2. Erstellen Sie die Instanzgruppe in REGION_A.

   gcloud compute instance-groups managed create hub-natgw-region-a-mig \
       --region REGION_A \
       --size=2 \
       --template=hub-natgw-region-a-template
   

Load-Balancer erstellen

Führen Sie die folgenden Schritte aus, um einen Load-Balancer in REGION_A zu erstellen.

1. Erstellen Sie eine Systemdiagnose.

   gcloud compute health-checks create http natgw-ilbnhop-health-check \
       --port=80
   

2. Erstellen Sie den Backend-Dienst.

   gcloud compute backend-services create hub-natgw-region-a-be \
       --load-balancing-scheme=internal \
       --protocol tcp \
       --region REGION_A\
       --health-checks=natgw-ilbnhop-health-check
   

3. Fügen Sie die verwaltete Instanzgruppe als Backend hinzu.

   gcloud compute backend-services add-backend hub-natgw-region-a-be \
       --instance-group=hub-natgw-region-a-mig \
       --instance-group-region=REGION_A
   

4. Erstellen Sie die Weiterleitungsregel.

   gcloud compute forwarding-rules create hub-natgw-region-a \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet-a \
       --address=10.0.0.10 \
       --ip-protocol=TCP \
       --ports=all \
       --allow-global-access \
       --backend-service=hub-natgw-region-a-be \
       --backend-service-region=REGION_A
   

Routen für den nächsten Hop erstellen

Erstellen Sie die Routen für den internen Passthrough-Network-Load-Balancer als nächster Hop mit dem vordefinierten Netzwerk-Tag ilbanh-region-a.

gcloud compute routes create spoke1-natgw-region-a \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

gcloud compute routes create spoke2-natgw-region-a \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.0.10 \
    --tags=ilbanh-region-a \
    --priority 800

Verbindung testen

Erstellen Sie Clientinstanzen, um die Verbindung zu testen.

1. Erstellen Sie eine Testclientinstanz in spoke1-vpc.

   gcloud compute instances create spoke1-client \
       --subnet=spoke1-subnet1 --no-address --zone ZONE_A \
       --tags=ilbanh-region-a \
       --metadata startup-script='#! /bin/bash
   apt-get update
   apt-get install tcpdump -y'
   

2. Erstellen Sie eine Testclientinstanz in spoke2-vpc.

   gcloud compute instances create spoke2-client \
       --subnet=spoke2-subnet1 --no-address --zone ZONE_A \
       --tags=ilbanh-region-a \
       --metadata startup-script='#! /bin/bash
   apt-get update
   apt-get install tcpdump -y'
   

Nord-Süd- und Ost-West-Traffic-Flüsse validieren

1. Prüfen Sie, ob die NAT-Gateway-VMs ausgeführt werden, und schreiben Sie die zugewiesenen externen IP-Adressen auf:

   gcloud compute instances list --filter="status:RUNNING AND name~natgw"
   

2. Prüfen Sie, ob der Load-Balancer fehlerfrei ist und die Routen wie erwartet erstellt wurden:

   gcloud compute backend-services get-health hub-natgw-region-a-be --region REGION_A
   

   backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/instanceGroups/hub-natgw-region-a-mig
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
       forwardingRuleIp: 10.0.0.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-b/instances/<INSTANCE_NAME>
       ipAddress: 10.0.0.5
       port: 80
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-central1/forwardingRules/hub-natgw-region-a
       forwardingRuleIp: 10.0.0.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-central1-f/instances/<INSTANCE_NAME>
       ipAddress: 10.0.0.6
       port: 80
     kind: compute#backendServiceGroupHealth
   

3. Prüfen Sie, ob die Routen für den internen Passthrough-Network-Load-Balancer als nächster Hop den Spoke-VPCs mit der erwarteten Priorität hinzugefügt wurden und ob auf die IP-Adresse des internen Passthrough-Network-Load-Balancers abgezielt wird:

   gcloud compute routes list --filter="name~natgw"
   

4. Rufen Sie die Google Cloud Console auf und stellen Sie auf verschiedenen Tabs SSH-Verbindungen zu den NAT-Gateway-VMs her.

5. Starten Sie in jeder dieser SSH-Sitzungen tcpdump mit dem folgenden Befehl:

   sudo tcpdump -n net 192.168.0.0/16
   

6. Rufen Sie die Google Cloud Console auf und stellen Sie eine neue SSH-Verbindung zur spoke1-client-VM her. Verwenden Sie dann den folgenden Befehl, um die interne IP-Adresse spoke2-client zu pingen.

   ping SPOKE2_CLIENT_INTERNAL_IP
   

7. Wechseln Sie zu den NAT-Gateway-SSH-Fenstern und prüfen Sie, ob Sie die ICMP-Pakete sehen können:

   16:51:28.411260 IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1684, seq 492, length 64
   16:51:28.411676 IP 192.168.1.2 > 192.168.0.2: ICMP echo reply, id 1684, seq 492, length 64
   

   Sie sollten in der Lage sein, die Client-VM erfolgreich zu pingen, was Folgendes zeigt:

   • Ost-West-Traffic wird über die NAT-Gateways ermöglicht. Beachten Sie, dass transaktives Peering nicht zwischen Spoke-VPCs unterstützt wird.
   • Symmetrisches Hashing ist aktiviert und funktioniert wie erwartet, da die Clients über ihre Quell-IP-Adressen kommunizieren können, ohne SNAT-Übersetzung zu erfordern.
   • Alle Protokolle werden mit dem internen Passthrough-Network-Load-Balancer als nächster Hop unterstützt.

8. Beenden Sie die tcpdump-Ausgaben auf den NAT-Gateway-VMs und beobachten Sie die iptables-Statistiken:

   watch sudo iptables -t nat -nvL
   

9. Wechseln Sie zur spoke1-client-VM und führen Sie den folgenden Befehl mehrmals aus. Die Ausgabe zeigt die öffentliche Quell-IP-Adresse, die für die Verbindung zur Website verwendet wird.

   curl ifconfig.io
   

   Die IP-Adressen beider NAT-Gateway-VMs sollten als Quell-IP-Adressen angezeigt werden. Dies zeigt, dass der interne Passthrough-Network-Load-Balancer den Traffic anhand der Standardaffinität (5-Tupel-Hashing) verteilt.

10. Wechseln Sie zur NAT-Gateway-VM, um zu prüfen, ob die Paketzähler erhöht wurden.

    Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
      105 11442 MASQUERADE  all  --  *      *       0.0.0.0/0           !192.168.0.0/16
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    

NAT-Gateway-VMs und Load-Balancing-Ressourcen in Region B erstellen

Erstellen Sie das Backend der verwalteten Instanzgruppe in region B. Erstellen Sie dann die Load-Balancing-Ressourcen und die Routen für den nächsten Hop.

Verwaltete Instanzgruppe erstellen

1. Erstellen Sie eine Instanzvorlage, um ein NAT-Gateway in region B bereitzustellen.

   gcloud compute instance-templates create hub-natgw-region-b-template \
       --network hub-vpc \
       --subnet hub-subnet-b --region REGION_B \
       --machine-type n1-standard-2 --can-ip-forward \
       --tags natgw \
       --metadata startup-script='#! /bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
   # iptables configuration
   iptables -t nat -F
   sudo iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -j MASQUERADE
   iptables-save
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   apt-get update
   apt-get install apache2 tcpdump -y
   a2ensite default-ssl
   a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html \
   systemctl restart apache2'
   

2. Erstellen Sie die Instanzgruppe in region B.

   gcloud compute instance-groups managed create hub-natgw-region-b-mig \
       --region REGION_B \
       --size=2 \
       --template=hub-natgw-region-b-template
   

Load-Balancer erstellen

Führen Sie die folgenden Schritte aus, um einen Load-Balancer in Region B zu erstellen.

1. Erstellen Sie den Backend-Dienst.

   gcloud compute backend-services create hub-natgw-region-b-be \
       --load-balancing-scheme=internal \
       --protocol tcp \
       --region REGION_B\
       --health-checks=natgw-ilbnhop-health-check
   

2. Fügen Sie die verwaltete Instanzgruppe als Backend hinzu.

   gcloud compute backend-services add-backend hub-natgw-region-b-be \
       --instance-group=hub-natgw-region-b-mig \
       --instance-group-region=REGION_B
   

3. Erstellen Sie die Weiterleitungsregel.

   gcloud compute forwarding-rules create hub-natgw-region-b \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet-b \
       --address=10.0.1.10 \
       --ip-protocol=TCP \
       --ports=all \
       --allow-global-access \
       --backend-service=hub-natgw-region-b-be \
       --backend-service-region=REGION_B
   

Routen für den nächsten Hop erstellen

Erstellen Sie die Routen für den internen Passthrough-Network-Load-Balancer als nächster Hop mit dem vordefinierten Netzwerk-Tag ilbanh-region-a.

gcloud compute routes create spoke1-natgw-region-b \
    --network=spoke1-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

gcloud compute routes create spoke2-natgw-region-b \
    --network=spoke2-vpc \
    --destination-range=0.0.0.0/0 \
    --next-hop-ilb=10.0.1.10 \
    --tags=ilbanh-region-a \
    --priority 900

Regionalen Failover validieren

1. Prüfen Sie, ob die NAT-Gateway-VMs ausgeführt werden, und schreiben Sie die zugewiesenen externen IP-Adressen auf:

   gcloud compute instances list --filter="status:RUNNING AND name~natgw"
   

2. Bestätigen Sie, dass der Load-Balancer fehlerfrei ist und dass die Routen wie erwartet erstellt werden:

   gcloud compute backend-services get-health hub-natgw-region-b-be --region REGION_B
   

   backend: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/instanceGroups/hub-natgw-region-b-mig
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
       forwardingRuleIp: 10.0.1.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-a/instances/<INSTANCE_NAME>
       ipAddress: 10.0.1.3
       port: 80
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/regions/us-west2/forwardingRules/hub-natgw-region-b
       forwardingRuleIp: 10.0.1.10
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/<PROJECT_ID>/zones/us-west2-b/instances/<INSTANCE_NAME>
       ipAddress: 10.0.1.2
       port: 80
     kind: compute#backendServiceGroupHealth
   

3. Prüfen Sie, ob die Routen für den internen Passthrough-Network-Load-Balancer als nächster Hop den Spoke-VPCs mit der erwarteten Priorität hinzugefügt wurden und ob auf die IP-Adresse des internen Passthrough-Network-Load-Balancers abgezielt wird:

   gcloud compute routes list --filter="name~natgw"
   

4. Sie können jetzt regionalen Failover validieren, indem Sie die Routen mit hoher Priorität löschen und sich notieren, was geschieht. Wechseln Sie zur spoke1-client-VM und führen Sie den folgenden Befehl aus, um jede Sekunde eine curl-Anfrage zu senden. Mit diesem Befehl wird auch die verwendete externe IP-Adresse gemeldet:

   while true; do echo -n `date` && echo -n ' - ' && curl ifconfig.io --connect-timeout 1; done
   

   Es sollten nur die externen IP-Adressen angezeigt werden, die den NAT-Gateways in region A zugewiesen sind, da es sich um eine Route mit hoher Priorität handelt. Lassen Sie den Befehl curl weiter ausführen und wechseln Sie zu Cloud Shell, um die Route zum internen Passthrough-Network-Load-Balancer in region A zu löschen, um das Ergebnis zu prüfen:

   gcloud -q compute routes delete spoke1-natgw-region-a
   

   In region B werden die externen IP-Adressen angezeigt, die den NAT-Gateway-VMs zugewiesen sind (wahrscheinlich mit minimaler Ausfallzeit). Dies zeigt, dass der regionale Failover erfolgreich war.

Hinweis: Eine Route wird nicht automatisch entfernt, selbst wenn alle Back-Ends fehlerhaft sind. Mit Cloud Run Functions können Sie diesen Prozess automatisieren.

Ressourcen bereinigen

1. Entfernen Sie die Routen für den internen Passthrough-Network-Load-Balancer als nächster Hop:

   gcloud -q compute routes delete spoke1-natgw-region-b
   
   gcloud -q compute routes delete spoke2-natgw-region-a
   
   gcloud -q compute routes delete spoke2-natgw-region-b
   

2. Entfernen Sie die Ressourcen und Back-Ends des internen Passthrough-Network-Load-Balancers:

   gcloud -q compute forwarding-rules delete hub-natgw-region-a \
     --region REGION_A
   
   gcloud -q compute backend-services delete hub-natgw-region-a-be \
     --region REGION_A
   
   gcloud -q compute instance-groups managed delete hub-natgw-region-a-mig \
     --region REGION_A
   
   gcloud -q compute instance-templates delete hub-natgw-region-a-template
   
   gcloud -q compute forwarding-rules delete hub-natgw-region-b \
     --region REGION_B
   
   gcloud -q compute backend-services delete hub-natgw-region-b-be \
     --region REGION_B
   
   gcloud -q compute instance-groups managed delete hub-natgw-region-b-mig \
     --region REGION_B
   
   gcloud -q compute instance-templates delete hub-natgw-region-b-template
   
   gcloud -q compute health-checks delete natgw-ilbnhop-health-check
   

3. Löschen Sie die Client-VMs:

   gcloud -q compute instances delete spoke1-client \
     --zone=ZONE_A
   
   gcloud -q compute instances delete spoke2-client \
     --zone=ZONE_A
   

4. Löschen Sie die VPC-Netzwerk-Peerings, Firewallregeln, Subnetze und VPCs:

   gcloud -q compute networks peerings delete spoke2-to-hub \
     --network spoke2-vpc
   
   gcloud -q compute networks peerings delete spoke1-to-hub \
     --network spoke1-vpc
   
   gcloud -q compute networks peerings delete hub-to-spoke1 \
     --network hub-vpc
   
   gcloud -q compute networks peerings delete hub-to-spoke2 \
     --network hub-vpc
   
   gcloud -q compute firewall-rules delete spoke2-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete spoke1-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete hub-vpc-web-ping-dns
   
   gcloud -q compute firewall-rules delete hub-vpc-health-checks
   
   gcloud -q compute firewall-rules delete hub-vpc-allow-ssh
   
   gcloud -q compute firewall-rules delete spoke1-vpc-allow-ssh
   
   gcloud -q compute firewall-rules delete spoke2-vpc-allow-ssh
   
   gcloud -q compute networks subnets delete spoke1-subnet1 \
     --region REGION_A
   
   gcloud -q compute networks subnets delete spoke2-subnet1 \
     --region REGION_A
   
   gcloud -q compute networks subnets delete hub-subnet-a \
     --region REGION_A
   
   gcloud -q compute networks subnets delete hub-subnet-b \
     --region REGION_B
   
   gcloud -q compute networks delete spoke1-vpc
   
   gcloud -q compute networks delete spoke2-vpc
   
   gcloud -q compute networks delete hub-vpc
   

Nächste Schritte

• Wichtige Informationen zum Failover finden Sie unter Failover-Konzepte für interne Passthrough-Network-Load-Balancer.
• Informationen zum Konfigurieren von Logging und Monitoring für interne Passthrough-Network-Load-Balancer finden Sie unter Logging und Monitoring für interne Passthrough-Network-Load-Balancer.
• Informationen zum Zugriff auf interne Passthrough-Network-Load-Balancer von Peer-Netzwerken, die mit Ihrem VPC-Netzwerk verbunden sind, finden Sie unter Interne Passthrough-Network-Load-Balancer und verbundene Netzwerke.
• Informationen zum Beheben von Problemen mit dem internen Passthrough-Network-Load-Balancer finden Sie unter Fehlerbehebung bei internen Passthrough-Network-Load-Balancern.