Configure um balanceador de carga de rede de passagem interno como salto seguinte (com etiquetas)

Este tutorial usa um exemplo para mostrar como implementar um Network Load Balancer de encaminhamento interno como o próximo salto para o qual os pacotes são encaminhados ao longo do caminho para o respetivo destino final. Use etiquetas de rede para configurar as instâncias de cliente específicas às quais a rota se aplica.

Este guia pressupõe que está familiarizado com o funcionamento de um balanceador de carga de rede de encaminhamento interno, os respetivos componentes relacionados, como regras de firewall e verificações de funcionamento, e como os balanceadores de carga de rede de encaminhamento interno são usados como próximos saltos para encaminhar pacotes numa rota.

Com a funcionalidade de encaminhamento interno do Network Load Balancer como passo seguinte, pode integrar dispositivos de terceiros de forma altamente disponível e expandida. Para o fazer, tem de configurar uma rota estática personalizada e definir o salto seguinte para o equilibrador de carga, que distribui o tráfego para o prefixo de destino para o conjunto de dispositivos de VM de terceiros verificados quanto ao estado. Tem várias opções quando seleciona os seus próximos saltos para suportar a elevada disponibilidade destes dispositivos de terceiros:

• Especifique um endereço IP como o próximo salto: use o endereço IP interno associado à regra de encaminhamento como o próximo salto. O endereço IP virtual deste equilibrador de carga pode ser aprendido entre pares sem ter de exportar a rota personalizada através dos respetivos pares.
• Use etiquetas de rede: pode especificar uma etiqueta de rede para que a rota de encaminhamento interno do balanceador de carga de rede como próximo passo apenas se aplique a instâncias de cliente que tenham sido configuradas com a etiqueta. Isto permite-lhe selecionar que instâncias de cliente são preenchidas com que balanceador de carga de rede de encaminhamento interno etiquetado como rota de próximo salto e que conjunto de dispositivos para encaminhar o seu tráfego. Não precisa de separar as diferentes instâncias de cliente em VPCs separadas, cada uma a apontar para o respetivo Network Load Balancer de passagem interno preferencial que serve de front-end a um conjunto de dispositivos. Os encaminhamentos etiquetados não são exportados nem importados através da interligação de redes VPC.
• Configure várias rotas para o mesmo prefixo de destino: com as etiquetas, pode especificar várias rotas para o mesmo destino com diferentes balanceadores de carga internos como saltos seguintes. Embora o ECMP não seja suportado (mesmo prefixo de destino, mesmas etiquetas, saltos seguintes diferentes), pode usar etiquetas diferentes ou prioridades diferentes para estas mesmas rotas de destino.

Vista geral da configuração

Os grupos de instâncias geridos que usam VMs com uma única NIC são definidos em diferentes regiões, com instâncias do Linux configuradas para traduzir SNAT todo o tráfego de saída para a Internet (fluxo de tráfego de saída norte-sul). A comutação por falha regional é acionada manualmente. Este tutorial também demonstra a conetividade leste-oeste com hash simétrico através de um Network Load Balancer de passagem interno como próximo salto.

Os passos nesta secção descrevem como configurar o seguinte:

1. Exemplos de redes VPC com sub-redes personalizadas
2. Regras de firewall que permitem ligações recebidas a VMs de back-end
3. Grupos de instâncias geridas de back-end que implementam gateways de NAT
4. VMs de cliente para testar ligações
5. Os seguintes componentes do balanceador de carga de rede de encaminhamento interno:
   • Uma verificação de funcionamento para o serviço de back-end
   • Um serviço de back-end interno
   • Uma regra de encaminhamento interna e um endereço IP para o front-end do balanceador de carga

A arquitetura para este exemplo tem o seguinte aspeto:

Balanceador de carga de rede de passagem interna como configuração do próximo salto (clique para aumentar)

À medida que segue os passos neste tutorial, substitua REGION_A e REGION_B pelas respetivas regiões que quer usar para este exemplo.

Crie as redes e as sub-redes de VPC

1. Crie uma rede de VPC denominada hub-vpc.

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

2. Crie uma sub-rede em hub-vpc em REGION_A.

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

3. Crie uma sub-rede em hub-vpc em region B.

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

4. Crie uma rede de VPC denominada spoke1-vpc.

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

5. Crie uma sub-rede em spoke1-vpc.

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

6. Crie uma rede de VPC denominada spoke2-vpc.

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

7. Crie uma sub-rede em spoke2-vpc.

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

Configure regras de firewall

1. Configure as seguintes regras de firewall para permitir que o tráfego TCP, UDP e ICMP alcance as instâncias a partir dos intervalos de origem especificados.

   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. Crie uma regra de firewall para permitir que os verificadores de funcionamento acedam a instâncias em hub-vpc.

   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. Crie regras de firewall para permitir o acesso SSH para instâncias em todas as sub-redes. Se preferir usar o Identity-Aware Proxy para o encaminhamento TCP (recomendado), siga estes passos para ativar o SSH.

   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
   

Configure o intercâmbio da rede da VPC

1. Crie uma interligação de hub-vpc para 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. Crie uma interligação de spoke1-vpc para 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. Crie uma interligação de hub-vpc para 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. Crie uma interligação de spoke2-vpc para hub-vpc.

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

Crie VMs de gateway de NAT e recursos de balanceamento de carga na região A

Crie o back-end do grupo de instâncias geridas em REGION_A. Em seguida, crie os recursos de balanceamento de carga e as rotas de próximo salto.

Crie um grupo de instâncias geridas

1. Crie um modelo de instância para implementar um gateway de NAT em region A.

   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. Crie o grupo de instâncias em REGION_A.

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

Crie o balanceador de carga

Siga os passos abaixo para criar um balanceador de carga no REGION_A.

1. Crie uma verificação de funcionamento.

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

2. Crie o serviço de back-end.

   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. Adicione o grupo de instâncias gerido como um back-end.

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

4. Crie a regra de encaminhamento.

   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
   

Crie as rotas do próximo salto

Crie o balanceador de carga de passagem interno como rotas de salto seguinte com a etiqueta de rede predefinida 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

Teste a conetividade

Crie instâncias de cliente para testar a conetividade.

1. Crie uma instância de cliente de teste em 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. Crie uma instância de cliente de teste em 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'
   

Valide os fluxos de tráfego norte-sul e este-oeste

1. Certifique-se de que as VMs da gateway NAT estão em execução e anote os endereços IP externos atribuídos:

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

2. Confirme se o balanceador de carga está em bom estado e se as rotas foram criadas conforme esperado:

   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. Verifique se as rotas do balanceador de carga de rede de encaminhamento interno como salto seguinte são adicionadas às VPCs spoke com a prioridade esperada e segmentando o endereço IP do balanceador de carga de rede de encaminhamento interno:

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

4. Aceda à Google Cloud consola e estabeleça ligações SSH às VMs do gateway NAT em separadores diferentes.

5. Inicie o tcpdump em cada uma dessas sessões SSH com o seguinte comando:

   sudo tcpdump -n net 192.168.0.0/16
   

6. Aceda à Google Cloud consola e estabeleça uma nova ligação SSH à VM spoke1-client. Em seguida, use o seguinte comando para enviar um ping para o spoke2-client endereço IP interno.

   ping SPOKE2_CLIENT_INTERNAL_IP
   

7. Mude para as janelas SSH do gateway NAT e verifique se consegue ver os pacotes ICMP da seguinte forma:

   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
   

   Deve conseguir enviar um ping com êxito para a VM do cliente, o que demonstra o seguinte:

   • O tráfego leste-oeste está ativado através dos gateways NAT. Tenha em atenção que o intercâmbio transitivo não é suportado entre VPCs spoke.
   • A aplicação de hash simétrica está ativada e a funcionar conforme esperado, uma vez que os clientes podem comunicar através dos respetivos endereços IP de origem, sem necessitar de tradução SNAT.
   • Todos os protocolos são suportados com o balanceador de carga de rede de passagem interna como próximo salto.

8. Pare as saídas do tcpdump nas VMs do gateway de NAT e observe as iptables estatísticas:

   watch sudo iptables -t nat -nvL
   

9. Volte para a VM spoke1-client e execute o seguinte comando várias vezes. O resultado apresenta o endereço IP de origem público que está a ser usado para estabelecer ligação ao Website.

   curl ifconfig.io
   

   Deve ver os endereços IP de ambas as VMs da gateway NAT apresentados como endereços IP de origem. Isto demonstra que o balanceador de carga de encaminhamento interno está a distribuir o tráfego com base na afinidade predefinida (hash de 5 tuplos).

10. Volte à VM da gateway NAT para confirmar que os contadores de pacotes aumentaram.

    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
    

Crie VMs de gateway de NAT e recursos de balanceamento de carga na região B

Crie o back-end do grupo de instâncias geridas em region B. Em seguida, crie os recursos de balanceamento de carga e as rotas de próximo salto.

Crie um grupo de instâncias geridas

1. Crie um modelo de instância para implementar um gateway de NAT em region B.

   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. Crie o grupo de instâncias em region B.

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

Crie o balanceador de carga

Execute os passos seguintes para criar um balanceador de carga na região B.

1. Crie o serviço de back-end.

   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. Adicione o grupo de instâncias gerido como um back-end.

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

3. Crie a regra de encaminhamento.

   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
   

Crie as rotas do próximo salto

Crie o balanceador de carga de passagem interno como rotas de salto seguinte com a etiqueta de rede predefinida 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

Valide a comutação por falha regional

1. Certifique-se de que as VMs da gateway NAT estão em execução e anote os IPs externos atribuídos:

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

2. Confirme se o balanceador de carga está em bom estado e se as rotas foram criadas conforme esperado:

   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. Verifique se as rotas do balanceador de carga de rede de encaminhamento interno como salto seguinte são adicionadas às VPCs spoke com a prioridade esperada e segmentando o endereço IP do balanceador de carga de rede de encaminhamento interno:

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

4. Já pode validar a comutação por falha regional eliminando as rotas de prioridade elevada e tomando nota do que acontece. Mude para a spoke1-client VM e execute o seguinte comando para enviar um pedido curl a cada segundo. Este comando também comunica o endereço IP externo que está a ser usado:

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

   Apenas devem ser apresentados os endereços IP externos atribuídos aos gateways NAT em region A, porque é a rota de alta prioridade. Deixe o comando curl em execução e mude para o Cloud Shell para eliminar a rota para o Network Load Balancer de passagem interno em region A para verificar o resultado:

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

   Em region B, são apresentados os endereços IP externos atribuídos às VMs da gateway NAT, provavelmente com um tempo de inatividade mínimo, o que demonstra que a comutação por falha regional foi bem-sucedida.

Nota: um trajeto não é removido automaticamente, mesmo que todos os back-ends estejam em mau estado. Considere usar funções do Cloud Run para automatizar este processo.

Limpe os recursos

1. Remova o balanceador de carga de passagem interno como rotas de próximo salto:

   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. Remova os recursos e os back-ends do balanceador de carga de rede de encaminhamento interno:

   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. Elimine as VMs cliente:

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

4. Elimine as interligações de redes VPC, as regras de firewall, as sub-redes e as 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
   

O que se segue?

• Consulte Conceitos de comutação por falha para equilibradores de carga de rede de passagem interna para ver informações importantes sobre a comutação por falha.
• Consulte o artigo Registo e monitorização do balanceador de carga de rede de encaminhamento interno para obter informações sobre a configuração do registo e da monitorização do balanceador de carga de rede de encaminhamento interno.
• Consulte o artigo Balanceadores de carga de rede de encaminhamento interno e redes ligadas para ver informações sobre o acesso a balanceadores de carga de rede de encaminhamento interno a partir de redes de pares ligadas à sua rede VPC.
• Consulte o artigo Resolva problemas de balanceadores de carga de rede de encaminhamento interno para ver informações sobre como resolver problemas com o balanceador de carga de rede de encaminhamento interno.