Configure um balanceador de carga de rede de encaminhamento interno para dispositivos de terceiros

No Google Cloud, pode integrar aparelhos de terceiros de forma altamente disponível e dimensionada. Para o fazer, configure uma rota estática e defina o respetivo salto seguinte para o Google Cloud Network Load Balancer de passagem interna. Isto permite que o equilibrador de carga equilibre a carga do tráfego para um prefixo de destino para um conjunto de dispositivos de VM de terceiros com verificação de estado.

Este guia usa um exemplo para ensinar a configurar um balanceador de carga de rede de passagem interno para ser um próximo salto. Antes de seguir este guia, familiarize-se com o seguinte:

• Conceitos do balanceador de carga de rede de encaminhamento interno
• Balanceadores de carga de rede de encaminhamento interno como saltos seguintes

Nota: estas instruções não são válidas para balanceadores de carga de rede de encaminhamento interno criados pelo GKE. Para criar um serviço de balanceador de carga interno com o GKE, consulte o artigo Usar um balanceador de carga de rede de encaminhamento direto interno.

Autorizações

Para seguir este guia, tem de criar instâncias e modificar uma rede num projeto. Deve ser proprietário ou editor do projeto, ou ter todas as seguintes funções do IAM do Compute Engine:

Tarefa	Função necessária
Crie redes, sub-redes e componentes do balanceador de carga	Administrador da rede
Adicione e remova regras de firewall	Administrador de segurança
Crie instâncias	Administrador de instâncias do Compute

Para mais informações, consulte os seguintes guias:

• Controlo de acesso
• Condições do IAM

Configurar balanceadores de carga de rede de passagem internos como saltos seguintes com back-ends comuns

Este guia mostra como usar um Network Load Balancer de encaminhamento interno como o próximo salto para uma rota estática de modo a integrar dispositivos virtuais dimensionados.

A solução abordada neste guia cria VMs de dispositivos que executam o Debian Linux. As VMs de exemplo não realizam qualquer filtragem de pacotes, mas pode adicionar essa funcionalidade modificando a configuração de rede deste exemplo ou usando um software de filtragem ou encaminhamento de pacotes diferente.

Os passos nesta secção descrevem como configurar os seguintes recursos:

• Exemplo de redes VPC e sub-redes personalizadas
• Google Cloud Regras de firewall que permitem ligações recebidas a máquinas virtuais (VMs) de dispositivos de back-end
• Rotas estáticas
• Duas VMs de cliente para testar as ligações
• Os seguintes componentes do balanceador de carga de rede de encaminhamento interno:
  • VMs de back-end num grupo de instâncias geridas (GIG)
  • Uma verificação de funcionamento para as VMs de back-end
  • Um serviço de back-end interno na região us-west1 para gerir a distribuição de ligações entre as VMs de back-end
  • Uma regra de encaminhamento interna e um endereço IP interno para o front-end do balanceador de carga

Este exemplo mostra o equilíbrio de carga para várias NICs de back-end, conforme descrito em Equilíbrio de carga para várias NICs.

A topologia tem o seguinte aspeto:

Exemplo detalhado de vários NICs de próximo salto para o balanceador de carga de rede de passagem interna (clique para aumentar).

O diagrama mostra alguns dos recursos que o exemplo cria:

• Instâncias de aplicações atrás de um balanceador de carga de rede de encaminhamento interno (fr-ilb1, neste exemplo). As instâncias da aplicação só têm endereços IP internos.
• Cada instância da aplicação tem a flag can-ip-forward ativada. Sem esta flag, uma VM do Compute Engine só pode transmitir um pacote se o endereço IP de origem do pacote corresponder ao endereço IP interno da VM, a um endereço IP de um intervalo de IPs de alias ou a um endereço IP de uma regra de encaminhamento que seja resolvido para a VM. A flag can-ip-forward altera este comportamento para que a VM possa transmitir pacotes com qualquer endereço IP de origem.
• Uma rota estática com o destino 10.50.1.0/24 e o salto seguinte definidos para a regra de encaminhamento do balanceador de carga, fr-ilb1.

O diagrama também mostra o fluxo de tráfego:

• A rede de VPC testing tem uma rota estática para o tráfego destinado à sub-rede 10.50.1.0/24. Este trajeto direciona o tráfego para o balanceador de carga.
• O balanceador de carga encaminha o tráfego para uma das instâncias da aplicação com base na afinidade de sessão configurada. (A afinidade de sessão só afeta o tráfego TCP.)

Para ver exemplos de utilização adicionais, consulte o artigo Balanceadores de carga de TCP/UDP internos como saltos seguintes.

Configurar as redes, a região e as sub-redes

Este exemplo usa as seguintes redes VPC, região e sub-redes:

• Redes: este exemplo requer duas redes, cada uma com, pelo menos, uma sub-rede. Cada VM de dispositivo de terceiros de back-end tem de ter, pelo menos, duas interfaces de rede, uma em cada rede VPC. As redes neste exemplo são redes VPC no modo personalizado denominadas testing e production. A rede testing neste exemplo contém o cliente e o balanceador de carga. A rede production contém a VM de destino.

• Região: as sub-redes estão localizadas na região us-west1. As sub-redes têm de estar na mesma região, porque as instâncias de VM são recursos zonais.

• Sub-redes: as sub-redes testing-subnet e production-subnet usam os intervalos de endereços IP principais 10.30.1.0/24 e 10.50.1.0/24, respetivamente.

Nota: pode alterar o nome das redes, a região e os parâmetros das sub-redes. No entanto, os passos seguintes neste guia usam os parâmetros das redes, da região e das sub-redes, conforme descrito anteriormente.

Para criar as redes e as sub-redes de exemplo, siga estes passos.

Consola

Crie a rede testing e o testing-subnet:

1. Na Google Cloud consola, aceda à página Redes VPC.

   Aceda a redes de VPC

2. Clique em Criar rede de VPC.

3. Introduza um Nome de testing.

4. Na secção Subnets (Sub-redes):

   • Defina o Subnet creation mode (Modo de criação de sub-rede) como Custom (Personalizado).
   • Na secção Nova sub-rede, introduza as seguintes informações:
     • Nome: testing-subnet
     • Região: us-west1
     • Intervalo de endereços IP: 10.30.1.0/24
     • Clique em Concluído.

5. Clique em Criar.

Crie a rede production e o production-subnet:

1. Na Google Cloud consola, aceda à página Redes VPC.

   Aceda a redes de VPC

2. Clique em Criar rede de VPC.

3. Introduza um Nome de production.

4. Na secção Subnets (Sub-redes):

   • Defina o Subnet creation mode (Modo de criação de sub-rede) como Custom (Personalizado).
   • Na secção Nova sub-rede, introduza as seguintes informações:
     • Nome: production-subnet
     • Região: us-west1
     • Intervalo de endereços IP: 10.50.1.0/24
     • Clique em Concluído.

5. Clique em Criar.

gcloud

1. Crie as redes VPC no modo personalizado:

   gcloud compute networks create testing --subnet-mode=custom
   

   gcloud compute networks create production --subnet-mode=custom
   

2. Crie sub-redes nas redes testing e production na região us-west1:

   gcloud compute networks subnets create testing-subnet \
       --network=testing \
       --range=10.30.1.0/24 \
       --region=us-west1
   

   gcloud compute networks subnets create production-subnet \
       --network=production \
       --range=10.50.1.0/24 \
       --region=us-west1
   

Configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

• fw-allow-testing-from-both: Uma regra de entrada, aplicável a todos os alvos na rede testing. Esta regra permite o tráfego de origens nos intervalos de endereços IP 10.30.1.0/24 e 10.50.1.0/24. Estes dois intervalos abrangem os endereços IP internos principais das VMs em ambas as redes.

• fw-allow-production-from-both: Uma regra de entrada, aplicável a todos os alvos na rede production. Esta regra permite o tráfego de origens nos intervalos de endereços IP 10.30.1.0/24 e 10.50.1.0/24. Estes dois intervalos abrangem os endereços IP internos principais das VMs em ambas as redes.

• fw-allow-testing-ssh: Uma regra de entrada aplicada às instâncias de VM na rede VPC testing. Esta regra permite a conetividade SSH recebida na porta TCP 22 a partir de qualquer endereço. Pode escolher um intervalo de IPs de origem mais restritivo para esta regra. Por exemplo, pode especificar os intervalos de IPs dos sistemas a partir dos quais planeia iniciar sessões SSH. Este exemplo usa a etiqueta de destino allow-ssh para identificar as VMs às quais a regra de firewall se aplica.

• fw-allow-production-ssh: Uma regra de entrada aplicada às instâncias de VM na rede VPC production. Esta regra permite a conetividade SSH recebida na porta TCP 22 a partir de qualquer endereço. Tal como na regra fw-allow-testing-ssh pode escolher um intervalo de IPs de origem mais restritivo para esta regra.

• fw-allow-health-check: Uma regra de entrada para as VMs do dispositivo de terceiros que estão a ser balanceadas por carga. Esta regra permite o tráfego dos sistemas de verificação de saúde (130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a etiqueta de destino allow-health-check para identificar as instâncias às quais deve ser aplicada.Google Cloud

• fw-allow-production-health-check: uma regra de entrada para as VMs do dispositivo de terceiros que estão a ser balanceadas por carga. Esta regra permite o tráfego dos sistemas de verificação de saúde (130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a etiqueta de destino allow-health-check para identificar as instâncias às quais deve ser aplicada.Google Cloud

Sem estas regras de firewall, a regra de negação predefinida de entrada bloqueia o tráfego de entrada para as instâncias de back-end. Tem de criar uma regra de firewall para permitir verificações de estado dos intervalos de IP dos sistemas de sondagem Google Cloud . Consulte os intervalos de IPs de sondagem para mais informações.

Consola

1. Na Google Cloud consola, aceda à página Políticas de firewall.

   Aceder a Políticas de firewall

2. Clique em Criar regra de firewall e introduza as seguintes informações para criar a regra que permite que as VMs de teste recebam pacotes das sub-redes de teste e de produção:

   • Nome: fw-allow-testing-from-both
   • Rede: testing
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Alvos: todas as instâncias na rede
   • Filtro de origem: intervalos IPv4
   • Intervalos IPv4 de origem: 10.30.1.0/24, 10.50.1.0/24
   • Protocolos e portas: permitir tudo

3. Clique em Criar.

4. Clique em Criar regra de firewall e introduza as seguintes informações para criar a regra que permite que as VMs de produção recebam pacotes das sub-redes de teste e de produção:

   • Nome: fw-allow-production-from-both
   • Rede: production
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Alvos: todas as instâncias na rede
   • Filtro de origem: intervalos IPv4
   • Intervalos IPv4 de origem: 10.30.1.0/24, 10.50.1.0/24
   • Protocolos e portas: permitir tudo

5. Clique em Criar.

6. Clique em Criar regra de firewall para criar a regra que permite ligações SSH de entrada no ambiente de teste:

   • Nome: fw-allow-testing-ssh
   • Rede: testing
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Objetivos: etiquetas de objetivo especificadas
   • Etiquetas de segmentação: allow-ssh
   • Filtro de origem: intervalos IPv4
   • Intervalos IPv4 de origem: 0.0.0.0/0
   • Protocolos e portas: escolha Protocolos e portas especificados e escreva: tcp:22

7. Clique em Criar.

8. Clique em Criar regra de firewall para criar a regra que permite ligações SSH de entrada no ambiente de produção:

   • Nome: fw-allow-production-ssh
   • Rede: production
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Objetivos: etiquetas de objetivo especificadas
   • Etiquetas de segmentação: allow-ssh
   • Filtro de origem: intervalos IPv4
   • Intervalos IPv4 de origem: 0.0.0.0/0
   • Protocolos e portas: escolha Protocolos e portas especificados e escreva: tcp:22

9. Clique em Criar.

10. Clique em Criar regra de firewall para criar a regra que permite Google Cloud verificações de funcionamento no ambiente de testes:

    • Nome: fw-allow-health-check
    • Rede: testing
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Objetivos: etiquetas de objetivo especificadas
    • Etiquetas de segmentação: allow-health-check
    • Filtro de origem: intervalos IPv4
    • Intervalos de IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas: tcp

11. Clique em Criar.

12. Clique em Criar regra de firewall para criar a regra que permite Google Cloud verificações de funcionamento no ambiente de produção:

    • Nome: fw-allow-production-health-check
    • Rede: production
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Objetivos: etiquetas de objetivo especificadas
    • Etiquetas de segmentação: allow-health-check
    • Filtro de origem: intervalos IPv4
    • Intervalos de IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas: tcp

13. Clique em Criar.

gcloud

1. Crie a regra de firewall fw-allow-testing-subnet para permitir que as VMs de teste recebam pacotes das sub-redes testing e production:

   gcloud compute firewall-rules create fw-allow-testing-from-both \
       --network=testing \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.30.1.0/24,10.50.1.0/24 \
       --rules=all
   

2. Crie a regra de firewall fw-allow-production-subnet para permitir que as VMs de produção recebam pacotes das sub-redes testing e production:

   gcloud compute firewall-rules create fw-allow-production-from-both \
       --network=production \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.30.1.0/24,10.50.1.0/24 \
       --rules=all
   

3. Crie a regra de firewall fw-allow-testing-ssh para permitir a conetividade SSH a VMs com a etiqueta de rede allow-ssh. Quando omite source-ranges, Google Cloud interpreta a regra como qualquer origem.

   gcloud compute firewall-rules create fw-allow-testing-ssh \
       --network=testing \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

4. Crie a regra de firewall fw-allow-production-ssh para permitir a conetividade SSH a VMs com a etiqueta de rede allow-ssh.

   gcloud compute firewall-rules create fw-allow-production-ssh \
       --network=production \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

5. Crie a regra fw-allow-health-check para permitir Google Cloud verificações de funcionamento às VMs do dispositivo de terceiros na rede testing.

   gcloud compute firewall-rules create fw-allow-testing-health-check \
       --network=testing \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-health-check \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp
   

6. Crie a regra da firewall fw-allow-production-health-check para permitir Google Cloud verificações de funcionamento às VMs do dispositivo de terceiros na rede production.

   gcloud compute firewall-rules create fw-allow-production-health-check \
       --network=production \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-health-check \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp
   

Criar os dispositivos virtuais de terceiros

Os passos seguintes demonstram como criar um modelo de instância e um grupo de instâncias regional gerido com mais do que uma interface de rede. Este grupo de instâncias é usado como o dispositivo virtual de terceiros para este exemplo.

Nota: em alternativa, pode criar um grupo de instâncias não gerido se, por exemplo, o software de terceiros que está a usar exigir uma configuração individual em cada VM membro do grupo.

Consola

Tem de usar gcloud para este passo porque tem de criar um modelo de instância com mais do que uma interface de rede. Atualmente, a Google Cloud consola não suporta a criação de modelos de instâncias com mais do que uma interface de rede.

gcloud

1. Crie um ficheiro local denominado config.sh e insira o seguinte conteúdo:

   #!/bin/bash
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
   # Read VM network configuration:
   md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
   md_net="$md_vm/network-interfaces"
   nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
   nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
   nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
   nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
   nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
   nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
   nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
   nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
   # Source based policy routing for nic1
   echo "100 rt-nic1" >> /etc/iproute2/rt_tables
   sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
   sleep 1
   sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
   sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
   # Use a web server to pass the health check for this example.
   # You should use a more complete test in production.
   sudo apt-get update
   sudo apt-get install apache2 -y
   sudo a2ensite default-ssl
   sudo a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html
   sudo systemctl restart apache2

2. Crie um modelo de instância para os seus dispositivos virtuais de terceiros. O modelo de instância tem de incluir a flag --can-ip-forward para que as instâncias de VM criadas a partir do modelo possam encaminhar pacotes de outras instâncias nas redes testing e production.

   gcloud compute instance-templates create third-party-template-multinic \
       --region=us-west1 \
       --network-interface subnet=testing-subnet,address="" \
       --network-interface subnet=production-subnet \
       --tags=allow-ssh,allow-health-check,my-network-tag \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --can-ip-forward \
       --metadata=startup-script="$(< config.sh)"
   

3. Crie um grupo de instâncias geridas para os seus dispositivos virtuais de terceiros. Este comando cria um grupo de instâncias gerido regional, que pode ser dimensionado automaticamente, em us-west1.

   gcloud compute instance-groups managed create third-party-instance-group \
       --region=us-west1 \
       --template=third-party-template-multinic \
       --size=3
   

Criar os recursos de balanceamento de carga

Estes passos configuram todos os componentes do balanceador de carga de rede de encaminhamento interno, começando pela verificação de estado e pelo serviço de back-end e, em seguida, pelos componentes de front-end:

• Verificação de saúde. Neste exemplo, a verificação de funcionamento de HTTP verifica uma resposta HTTP 200 (OK). Para mais informações, consulte a secção Verificação de estado.

• Serviço de back-end. Embora o serviço de back-end deste exemplo especifique o protocolo TCP, quando o balanceador de carga é o próximo salto para uma rota,Google Cloud encaminha o tráfego para todos os protocolos (TCP, UDP e ICMP).

• Regra de encaminhamento. Embora esta regra de encaminhamento de exemplo especifique a porta 80 do TCP, quando o balanceador de carga é o próximo salto para uma rota, o tráfego em qualquer porta TCP ou UDP é enviado para os back-ends do balanceador de carga.

• Endereço IP interno. O exemplo especifica um endereço IP interno, 10.30.1.99, para a regra de encaminhamento.

Consola

Inicie a configuração

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda ao balanceamento de carga

2. Clique em Criar equilibrador de carga.
3. Para Tipo de balanceador de carga, selecione Balanceador de carga de rede (TCP/UDP/SSL) e clique em Seguinte.
4. Para Proxy ou passagem, selecione Passagem do balanceador de carga e clique em Seguinte.
5. Para Público ou interno, selecione Interno e clique em Seguinte.
6. Clique em Configurar.

Crie o primeiro balanceador de carga

1. No campo Nome do equilibrador de carga, introduza ilb1.
2. Na lista Região, selecione us-west1.
3. Na lista Rede, selecione testing.
4. Clique em Configuração de back-end e faça o seguinte:
   1. Na lista Verificação de funcionamento, clique em Criar uma verificação de funcionamento e, em seguida, introduza as seguintes informações:
      • Nome: hc-http-80
      • Protocolo: HTTP
      • Porta: 80
      • Protocolo proxy: NONE
      • Pedido: / tenha em atenção que, quando usa a consola para criar o balanceador de carga, a verificação de funcionamento é global. Google Cloud Se quiser criar uma verificação de funcionamento regional, use gcloud ou a API.
   2. Clique em Criar.
   3. Na secção Novo back-end, selecione o grupo de instâncias third-party-instance-group e clique em Concluído.
   4. Na lista Afinidade de sessão, selecione IP do cliente.
   5. Verifique se existe uma marca de verificação azul junto a Configuração de back-end antes de continuar. Se não o fez, reveja este passo.
5. Clique em Configuração do front-end. Na secção Novo IP e porta de front-end, faça as seguintes alterações:
   1. Nome: fr-ilb1
   2. Subnetwork: testing-subnet
   3. Em IP interno, escolha Reservar um endereço IP interno estático, introduza as seguintes informações e clique em Reservar:
      • Nome: ip-ilb
      • Endereço IP estático: deixar-me escolher
      • Endereço IP personalizado: 10.30.1.99
   4. Portas: escolha Única e introduza 80 para o Número da porta. Lembre-se de que a escolha de um protocolo e uma porta para o balanceador de carga não limita os protocolos e as portas que são usados quando o balanceador de carga é o próximo salto de um trajeto.
   5. Antes de continuar, verifique se existe uma marca de verificação azul junto a Configuração do frontend. Se não o fez, reveja este passo.
6. Clique em Rever e finalizar. Verifique as definições.
7. Clique em Criar.

Inicie a configuração

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda ao balanceamento de carga

2. Clique em Criar equilibrador de carga.
3. Para Tipo de balanceador de carga, selecione Balanceador de carga de rede (TCP/UDP/SSL) e clique em Seguinte.
4. Para Proxy ou passagem, selecione Passagem do balanceador de carga e clique em Seguinte.
5. Para Público ou interno, selecione Interno e clique em Seguinte.
6. Clique em Configurar.

Crie o segundo balanceador de carga

1. Defina o Nome como ilb2.
2. Defina a Região como us-west1.
3. Defina a Rede como production.
4. Clique em Configuração de back-end e faça as seguintes alterações:
   1. Para Back-ends, na secção Novo item, selecione o third-party-instance-groupgrupo de instâncias e clique em Concluído.
   2. Para Verificação de funcionamento, selecione hc-http-80.
   3. Para Afinidade de sessão, selecione IP do cliente.
   4. Verifique se existe uma marca de verificação azul junto a Configuração de back-end antes de continuar. Se não o fez, reveja este passo.
5. Clique em Configuração do front-end. Na secção Novo IP e porta de front-end, faça as seguintes alterações:
   1. Nome: fr-ilb2
   2. Subnetwork: production-subnet
   3. Em IP interno, escolha Reservar um endereço IP interno estático, introduza as seguintes informações e, de seguida, clique em Reservar:
      • Nome: ip-ilb2
      • Endereço IP estático: deixar-me escolher
      • Endereço IP personalizado: 10.50.1.99
   4. Portas: escolha Única e introduza 80 para o Número da porta. Lembre-se de que a escolha de um protocolo e uma porta para o balanceador de carga não limita os protocolos e as portas que são usados quando o balanceador de carga é o próximo salto de um trajeto.
   5. Antes de continuar, verifique se existe uma marca de verificação azul junto a Configuração do frontend. Se não o fez, reveja este passo.
6. Clique em Rever e finalizar. Verifique as definições.

7. Clique em Criar.

8. Configure os recursos do balanceador de carga na rede VPC production.

gcloud

1. Crie uma nova verificação de funcionamento de HTTP para testar a conetividade TCP às VMs na porta 80.

   gcloud compute health-checks create http hc-http-80 \
       --region=us-west1 \
       --port=80
   

2. Crie dois serviços de back-end internos na região us-west1.

   gcloud compute backend-services create ilb1 \
       --load-balancing-scheme=internal \
       --health-checks-region=us-west1 \
       --health-checks=hc-http-80 \
       --region=us-west1 \
       --network=testing \
       --session-affinity=CLIENT_IP
   

   gcloud compute backend-services create ilb2 \
       --load-balancing-scheme=internal \
       --health-checks-region=us-west1 \
       --health-checks=hc-http-80 \
       --region=us-west1 \
       --network=production \
       --session-affinity=CLIENT_IP
   

3. Adicione os grupos de instâncias que contêm os dispositivos virtuais de terceiros como back-ends nos serviços de back-end.

   gcloud compute backend-services add-backend ilb1 \
       --instance-group=third-party-instance-group \
       --instance-group-region=us-west1 \
       --region=us-west1
   

   gcloud compute backend-services add-backend ilb2 \
       --instance-group=third-party-instance-group \
       --instance-group-region=us-west1 \
       --region=us-west1
   

4. Crie as regras de encaminhamento interno e associe-as aos serviços de back-end para concluir a configuração do balanceador de carga. Tenha em atenção que o protocolo (TCP) e a porta (80) dos balanceadores de carga não limitam as portas e os protocolos que são encaminhados para as instâncias de back-end (os dispositivos virtuais de terceiros) quando os balanceadores de carga são usados como os próximos saltos das rotas.

   gcloud compute forwarding-rules create fr-ilb1 \
       --load-balancing-scheme=internal \
       --ports=80 \
       --network=testing \
       --subnet=testing-subnet \
       --region=us-west1 \
       --backend-service=ilb1 \
       --address=10.30.1.99
   

   gcloud compute forwarding-rules create fr-ilb2 \
       --load-balancing-scheme=internal \
       --ports=80 \
       --network=production \
       --subnet=production-subnet \
       --region=us-west1 \
       --backend-service=ilb2 \
       --address=10.50.1.99
   

Criar as rotas estáticas que definem os balanceadores de carga como os saltos seguintes

Crie duas rotas estáticas que usem um equilibrador de carga de salto seguinte.

Consola

Crie o primeiro trajeto

Nota: quando define o balanceador de carga como o próximo salto, a utilização de etiquetas de instância no trajeto não é suportada na Google Cloud consola. Em alternativa, use a CLI gcloud ou a API.

1. Na Google Cloud consola, aceda à página Rotas.

   Aceda a Trajetos

2. Clique em Criar trajeto.

3. Para o Nome da rota, introduza ilb-nhop-dest-10-50-1.

4. Selecione a rede testing.

5. Para o Intervalo de IPs de destino, introduza 10.50.1.0/24.

6. Para Etiquetas de instância, introduza my-network-tag.

7. Para o Próximo salto da rota, selecione Especificar uma regra de encaminhamento do balanceador de carga de TCP/UDP interno.

   Para especificar o endereço IP do balanceador de carga como o próximo salto, use a CLI gcloud ou a API.

8. Especifique o nome da regra de encaminhamento. Para o nome da regra de encaminhamento, selecione fr-ilb1.

9. Clique em Criar.

Crie o segundo trajeto

1. Clique em Criar trajeto.
2. Para o Nome da rota, introduza ilb-nhop-dest-10-30-1.
3. Selecione a rede testing.
4. Para o Intervalo de IPs de destino, introduza 10.30.1.0/24.

5. Para o Próximo salto da rota, selecione Especificar uma regra de encaminhamento do balanceador de carga de TCP/UDP interno.

   Para especificar o endereço IP do balanceador de carga como o próximo salto, use a CLI gcloud ou a API.

6. Para o nome da regra de encaminhamento, selecione fr-ilb2.

7. Clique em Criar.

gcloud

Crie rotas estáticas com o próximo salto definido para a regra de encaminhamento de cada balanceador de carga e cada intervalo de destino definido em conformidade.

Para a flag --next-hop-ilb, pode especificar um nome de regra de encaminhamento ou o endereço IP da regra de encaminhamento. Um endereço IP de regra de encaminhamento do próximo salto pode estar localizado na mesma rede VPC que contém a rota ou numa rede VPC em intercâmbio. Para mais informações, consulte o artigo Projeto e rede do próximo salto.

No exemplo, a primeira rota usa o endereço IP 10.30.1.99, enquanto a segunda rota usa o nome da regra de encaminhamento fr-ilb12.

Nota: não pode selecionar o seguinte na opção --next-hop-ilb:

• Regra de encaminhamento com L3_DEFAULT.
• Endereço IPv4 interno estático com --purpose SHARED_LOADBALANCER_VIP.

Opcionalmente, pode especificar uma ou mais etiquetas de instância na rota. A rota pode aplicar-se a VMs específicas se especificar etiquetas de rede na rota. Se não especificar nenhuma etiqueta de rede, a rota aplica-se a todas as VMs na rede VPC. Neste exemplo, a rota usa my-network-tag para a etiqueta de rede da rota.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

Criar a instância de VM testing

Este exemplo cria uma instância de VM com o endereço IP 10.30.1.100 na testing-subnet (10.30.1.0/24) na rede VPC testing.

gcloud

1. Crie o testing-vm executando o seguinte comando.

   gcloud compute instances create testing-vm \
       --zone=us-west1-a \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --tags=allow-ssh,my-network-tag \
       --subnet=testing-subnet \
       --private-network-ip 10.30.1.100 \
       --metadata=startup-script='#! /bin/bash
       sudo apt-get update
       sudo apt-get install apache2 -y
       sudo a2ensite default-ssl
       sudo a2enmod ssl
       vm_hostname="$(curl -H "Metadata-Flavor:Google" \
       http://metadata.google.internal/computeMetadata/v1/instance/name)"
       echo "Page served from: $vm_hostname" | \
       tee /var/www/html/index.html
       sudo systemctl restart apache2'
   

Criar a instância de VM production

Este exemplo cria uma instância de VM com o endereço IP 10.50.1.100 na production-subnet (10.50.1.0/24) na rede VPC production.

gcloud

O production-vm pode estar em qualquer zona na mesma região que o equilibrador de carga e pode usar qualquer sub-rede nessa região. Neste exemplo, production-vm está no fuso horário us-west1-a.

1. Crie o production-vm executando o seguinte comando.

   gcloud compute instances create production-vm \
       --zone=us-west1-a \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --tags=allow-ssh \
       --subnet=production-subnet \
       --private-network-ip 10.50.1.100 \
       --metadata=startup-script='#! /bin/bash
       sudo apt-get update
       sudo apt-get install apache2 -y
       sudo a2ensite default-ssl
       sudo a2enmod ssl
       vm_hostname="$(curl -H "Metadata-Flavor:Google" \
       http://metadata.google.internal/computeMetadata/v1/instance/name)"
       echo "Page served from: $vm_hostname" | \
       tee /var/www/html/index.html
       sudo systemctl restart apache2'
   

Testar o balanceamento de carga numa implementação com várias NICs

1. Verifique o estado dos back-ends do balanceador de carga.

   gcloud compute backend-services get-health ilb1 --region us-west1
   

   gcloud compute backend-services get-health ilb2 --region us-west1
   

2. Teste a conetividade a partir da VM testing.

   gcloud compute ssh testing-vm --zone=us-west1-a
   

   curl http://10.50.1.99
   

   exit
   

3. Teste a conetividade a partir da VM production.

   gcloud compute ssh production-vm --zone=us-west1-a
   

   curl http://10.30.1.99
   

   exit
   

Ativar a aplicação de hash simétrica

Ao calcular o hash mapeado para a instância de back-end, o balanceador de carga Google Cloud ignora a direção dos endereços IP e das portas. O valor hash consistente calculado de um pacote TCP/UDP é o mesmo, independentemente da direção de origem do pacote. Isto chama-se hash simétrico.

Nota: a aplicação de hash simétrica é ativada automaticamente nos equilibradores de carga de rede de encaminhamento interno criados recentemente. Não tem de a ativar.

Para ativar este comportamento de hash nos balanceadores de carga de rede de encaminhamento interno existentes, tem de recriar a regra de encaminhamento e a rota de próximo salto.

Para mais informações, consulte o artigo Hash simétrico.

Elimine e volte a criar as regras de encaminhamento

Consola

Elimine a regra de encaminhamento e crie uma nova

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. Clique no seu be-ilb equilibrador de carga e clique em Editar.

3. Clique em Configuração do front-end.

4. Passe o cursor do rato sobre a regra de encaminhamento e, de seguida, clique em Eliminar para a remover.

5. Clique em Adicionar IP e porta do front-end.

6. Na secção Novo IP e porta de front-end, faça as seguintes alterações:

   1. Nome: FORWARDING_RULE_NAME
   2. Subnetwork: SUBNET_NAME
   3. Em IP interno, selecione IP_ADDRESS
   4. Portas: PORT_NUMBER ou ALL.
   5. Clique em Concluído.
   6. Antes de continuar, verifique se existe uma marca de verificação azul junto a Configuração do frontend. Se não o fez, reveja este passo.

7. Clique em Rever e finalizar. Verifique as definições.

8. Clique em Criar.

gcloud

1. Elimine as regras de encaminhamento existentes.

   gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
       --region=REGION
   

2. Crie regras de encaminhamento de substituição com o mesmo nome.

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
       --load-balancing-scheme=internal \
       --ports=PORT_NUMBER or `ALL` \
       --network=NETWORK_NAME \
       --subnet=SUBNET_NAME \
       --region=REGION \
       --backend-service=BACKEND_SERVICE_NAME \
       --address=IP_ADDRESS
   

Quando o SNAT não é necessário

Conforme demonstrado no exemplo anterior, a tradução de endereços de rede de origem (SNAT) não é necessária quando todas as seguintes condições são verdadeiras:

• A regra de encaminhamento do balanceador de carga de rede de passagem interno foi criada a 22 de junho de 2021 ou após esta data.
• A rota estática que faz referência à regra de encaminhamento foi criada a 22 de junho de 2021 ou após essa data.
• O serviço de back-end do Network Load Balancer de passagem interno não usa a definição de afinidade de sessão NONE.

Pode converter uma rota de encaminhamento interno de encaminhamento direto do Network Load Balancer existente para usar a hash simétrica seguindo estes passos:

• Certifique-se de que o serviço de back-end do balanceador de carga de passagem interno não usa a NONE definição de afinidade de sessão

• Crie uma regra de encaminhamento de substituição que faça referência ao mesmo serviço de back-end. A regra de encaminhamento de substituição usa um endereço IP diferente.

• Crie uma rota estática de substituição que faça referência à nova regra de encaminhamento. Certifique-se de que este trajeto de substituição tem uma prioridade mais elevada do que o trajeto existente.

• Elimine a rota existente de prioridade inferior (que faz referência à regra de encaminhamento anterior) e, em seguida, elimine a regra de encaminhamento anterior.

Limpeza

1. Na configuração do balanceador de carga, remova o back-end dos serviços de back-end.

   gcloud compute backend-services remove-backend ilb1 \
       --instance-group=third-party-instance-group \
       --instance-group-region=us-west1 \
       --region=us-west1
   

   gcloud compute backend-services remove-backend ilb2 \
       --instance-group=third-party-instance-group \
       --instance-group-region=us-west1 \
       --region=us-west1
   

2. Elimine os trajetos.

   gcloud compute routes delete ilb-nhop-dest-10-50-1
   

   gcloud compute routes delete ilb-nhop-dest-10-30-1
   

3. Nas configurações do balanceador de carga, elimine as regras de encaminhamento.

   gcloud compute forwarding-rules delete fr-ilb1 \
       --region=us-west1
   

   gcloud compute forwarding-rules delete fr-ilb2 \
       --region=us-west1
   

4. Nas configurações do balanceador de carga, elimine os serviços de back-end.

   gcloud compute backend-services delete ilb1 \
       --region=us-west1
   

   gcloud compute backend-services delete ilb2 \
       --region=us-west1
   

5. Nas configurações do balanceador de carga, elimine a verificação de funcionamento.

   gcloud compute health-checks delete hc-http-80 \
       --region=us-west1
   

   Se usou a Google Cloud consola, a verificação do estado é global. Por conseguinte, o comando é o seguinte:

   gcloud compute health-checks delete hc-http-80 \
        --global
   

6. Elimine o grupo de instâncias gerido.

   gcloud compute instance-groups managed delete third-party-instance-group \
       --region=us-west1
   

7. Elimine os modelos de instância.

   gcloud compute instance-templates delete third-party-template
   

   gcloud compute instance-templates delete third-party-template-multinic
   

8. Elimine as instâncias de teste e produção.

   gcloud compute instances delete testing-vm \
       --zone=us-west1-a
   

   gcloud compute instances delete production-vm \
       --zone=us-west1-a
   

O que se segue?

• Vista geral do balanceador de carga de rede de encaminhamento interno
• Failover para balanceadores de carga de rede de encaminhamento interno
• Configure balanceadores de carga de rede de passagem interna com back-ends de grupos de instâncias de VM
• Registo e monitorização do balanceador de carga de rede de encaminhamento interno
• Balanceadores de carga de passagem internos e redes ligadas
• Resolução de problemas de equilibradores de carga de passagem internos
• Limpe a configuração do equilibrador de carga