Configurar um balanceador de carga de rede de passagem interna como próximo salto (com tags)

Neste tutorial, você verá um exemplo de como implantar um balanceador de carga rede de passagem interno como o próximo salto para onde os pacotes serão encaminhados ao longo do caminho para o destino final. Use tags de rede para configurar as instâncias de cliente específicas às quais a rota se aplica.

Para este guia, é necessário ter familiaridade com o funcionamento de um balanceador de carga de rede de passagem interno, além de componentes relacionados, como regras de firewall e verificações de integridade, e como os balanceadores de carga de rede de passagem internos são usados como próximos saltos para encaminhar pacotes em uma rota.

Com o balanceador de carga de rede de passagem interno como recurso de próximo salto, é possível integrar dispositivos de terceiros de maneira altamente disponível e escalonada horizontalmente. Para fazer isso, você precisa configurar uma rota estática personalizada e definir o próximo salto para o balanceador de carga, que distribuirá o tráfego para o prefixo de destino como o pool de VMs de terceiros verificadas pela integridade aparelhos. Você tem várias opções ao selecionar seus próximos saltos para oferecer compatibilidade com a alta disponibilidade destes dispositivos de terceiros:

• Especificar um endereço IP como próximo salto: use o endereço IP interno associado à regra de encaminhamento como o próximo salto. É possível aprender o endereço IP virtual desse balanceador de carga entre pares sem precisar exportar a rota personalizada por meio de pares.
• Usar tags de rede: é possível especificar uma tag de rede para que o balanceador de carga de rede de passagem interno como rota do próximo salto se aplique apenas a instâncias de cliente que foram configuradas com a tag. Isso permite que você selecione quais instâncias de cliente serão preenchidas com qual balanceador de carga de rede de passagem interno com tag como próximo trajeto de salto e qual conjunto de dispositivos para rotear seu tráfego. Você não precisa separar as diferentes instâncias de cliente em VPCs separadas, cada uma apontando para o balanceador de carga de rede de passagem interno preferido de front-end de um conjunto de dispositivos. As rotas com tags não são exportadas nem importadas por meio do peering de rede VPC.
• Configurar várias rotas para o mesmo prefixo de destino: com as tags, você pode especificar várias rotas para o mesmo destino com diferentes balanceadores de carga internos como próximos saltos. Embora o ECMP não seja compatível (mesmo prefixo de destino, tags iguais, próximos saltos), você pode usar tags ou prioridades diferentes para essas mesmas rotas de destino.

Visão geral da configuração

Os grupos de instâncias gerenciadas que usam VMs com uma única NIC são definidos em regiões diferentes. As instâncias do Linux são configuradas para traduzir o tráfego de saída para a Internet (fluxo de tráfego de saída norte-sul). O failover regional é acionado manualmente. Neste tutorial, você também demonstra a conectividade leste-oeste com hash simétrico usando um balanceador de carga de rede de passagem interno como próximo salto.

Nas etapas desta seção, veja como configurar o seguinte:

1. Exemplos de redes VPC com sub-redes personalizadas
2. Regras de firewall que permitem conexões de entrada com VMs de back-end
3. Grupos de instâncias gerenciadas de back-end que implantam gateways NAT
4. VMs de cliente para testar as conexões
5. Os componentes do balanceador de carga de rede de passagem interna a seguir:
   • uma verificação de integridade do 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 deste exemplo é a seguinte:

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

.

À medida que segue as etapas neste tutorial, substitua REGION_A e REGION_B pelas respectivas regiões que você quer usar neste exemplo.

Criar as redes e sub-redes VPC

1. Crie uma rede VPC chamada 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 VPC chamada 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 VPC chamada 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
   

Configurar regras de firewall

1. Configure as regras de firewall a seguir para permitir que o tráfego TCP, UDP e ICMP alcancem instâncias 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 as sondagens de verificação de integridade acessem 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 de instâncias em todas as sub-redes. Se você preferir usar o Identity-Aware Proxy para encaminhamento de TCP (recomendado), siga estas etapas 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
   

Configurar o peering de rede VPC

1. Crie um peering 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 um peering 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 um peering 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 um peering 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
   

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

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

Criar um grupo de instâncias gerenciadas

1. Crie um modelo de instância para implantar um gateway 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
   

Criar o balanceador de carga

Siga as etapas a seguir para criar um balanceador de carga em REGION_A.

1. Crie uma verificação de integridade.

   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 gerenciadas como o 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
   

Criar as próximas rotas de salto

Crie o balanceador de carga de rede de passagem interna como rotas de próximo salto com a tag de rede ilbanh-region-a predefinida.

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

Testar a conectividade

Crie instâncias de clientes para testar a conectividade.

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'
   

Validar fluxos de tráfego norte-sul e leste-oeste

1. Verifique se as VMs do 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á íntegro e as rotas foram criadas conforme o 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 o balanceador de carga de rede de passagem interna como rotas de próximo salto foram adicionados às VPCs spoke com a prioridade esperada e segmentando o endereço IP do balanceador de carga de rede de passagem interna:

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

4. Acesse o Console do Google Cloud e estabeleça conexões SSH com as VMs de gateway NAT em diferentes guias.

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

   sudo tcpdump -n net 192.168.0.0/16
   

6. Acesse o Console do Google Cloud e estabeleça uma nova conexão SSH com a VM spoke1-client. Em seguida, use o seguinte comando para dar um ping no endereço IP interno spoke2-client.

   ping SPOKE2_CLIENT_INTERNAL_IP
   

7. Alterne para as janelas SSH do gateway NAT e verifique se você consegue ver os pacotes ICMP da seguinte maneira:

   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
   

   Você vai poder fazer um ping na VM cliente, o que demonstra o seguinte:

   • O tráfego leste-oeste é ativado pelos gateways NAT. O peering transitivo não é compatível entre VPCs spoke.
   • A hash simétrica está ativada e funcionando como esperado, já que os clientes podem se comunicar usando os endereços IP de origem, sem exigir tradução de SNAT.
   • Todos os protocolos são compatíveis com o balanceador de carga de rede de passagem interna como próximo salto.

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

   watch sudo iptables -t nat -nvL
   

9. Volte para a VM spoke1-client e execute o comando a seguir várias vezes. A saída exibe o endereço IP de origem pública que está sendo usado para se conectar ao site.

   curl ifconfig.io
   

   Você verá os endereços IP das duas VMs do gateway NAT exibidos como endereços IP de origem. Isso demonstra que o balanceador de carga de rede de passagem interno está distribuindo o tráfego com base na afinidade padrão (hash de 5 tuplas).

10. Volte para a VM do gateway NAT para confirmar se 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
    

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

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

Criar um grupo de instâncias gerenciadas

1. Crie um modelo de instância para implantar um gateway 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
   

Criar o balanceador de carga

Siga as etapas a seguir 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 gerenciadas como o 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
   

Criar as próximas rotas de salto

Crie o balanceador de carga de rede de passagem interna como rotas de próximo salto com a tag de rede ilbanh-region-a predefinida.

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

Validar failover regional

1. Verifique se as VMs do 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á íntegro e se as rotas estão criadas conforme o 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 o balanceador de carga de rede de passagem interna como rotas de próximo salto foram adicionados às VPCs spoke com a prioridade esperada e segmentando o endereço IP do balanceador de carga de rede de passagem interna:

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

4. Agora é possível validar o failover regional excluindo as rotas de alta prioridade e anotando o que acontece. Alterne para a VM spoke1-client e execute o seguinte comando para enviar uma solicitação curl a cada segundo. Esse comando também informa o endereço IP externo que está sendo usado:

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

   Somente os endereços IP externos atribuídos aos gateways NAT em region A precisam ser exibidos, porque essa é a rota de alta prioridade. Deixe o comando curl em execução e mude para o Cloud Shell para excluir a rota ao balanceador de carga de rede de passagem interno em region A para verificar o resultado:

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

   Em region B, os endereços IP externos atribuídos às VMs do gateway NAT aparecem, provavelmente com tempo de inatividade mínimo, o que demonstra que o failover regional foi bem-sucedido.

Observação: uma rota não é removida automaticamente, mesmo que todos os back-ends não estejam íntegros. Considere usar o Cloud Functions para automatizar esse processo.

Limpar recursos

1. Remova o balanceador de carga de rede de passagem interna como rotas do 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 back-ends do balanceador de carga de rede interno de passagem:

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

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

4. Exclua os peerings de rede 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
   

A seguir

• Para informações importantes sobre failover, consulte Conceitos de failover para balanceadores de carga de rede de passagem interna.
• Para informações sobre como configurar o Logging e o Monitoring para balanceadores de carga de rede de passagem interna, consulte esta página.
• Para informações sobre como acessar balanceadores de carga de rede de passagem interna por redes de peering conectadas à rede VPC, consulte esta página.
• Para informações sobre como resolver problemas com o balanceador de carga de rede de passagem interna, consulte esta página.