Configurar um balanceador de carga de rede de passagem interna para dispositivos de terceiros

No Google Cloud, é possível integrar dispositivos de terceiros de maneira altamente disponível e escalonada horizontalmente. Para fazer isso, configure uma rota estática e defina o próximo salto dela como o balanceador de carga de rede de passagem interno do Google Cloud. Isso permite que o balanceador de carga faça o balanceamento de carga do tráfego para um prefixo de destino de um conjunto de dispositivos de VM de terceiros com verificação de integridade.

Neste guia, usamos um exemplo para ensinar como configurar um balanceador de carga de rede de passagem interna para ser um próximo salto. Antes de seguir este guia, familiarize-se com os itens abaixo:

Permissões

Para seguir este guia, você precisa criar instâncias e modificar uma rede em um projeto. É necessário ser proprietário ou editor de um projeto ou ter todos os papéis do IAM do Compute Engine a seguir:

Tarefa Papel necessário
Criar redes, sub-redes e componentes do balanceador de carga Administrador de rede
Adicionar e remover regras de firewall Administrador de segurança
Criar instâncias Administrador da instância da computação

Para mais informações, consulte estes guias:

Como configurar balanceadores de carga de rede de passagem interna como próximos saltos com back-ends comuns

Neste guia, você aprenderá a usar um balanceador de carga de rede de passagem interno como o próximo salto de uma rota estática para integrar dispositivos virtuais escalonados horizontalmente.

A solução discutida neste guia cria VMs de dispositivo que executam o Debian Linux. As VMs de exemplo não executam nenhuma filtragem de pacotes, mas é possível adicionar essa funcionalidade modificando a configuração de rede deste exemplo ou usando uma filtragem de pacote ou software de roteamento diferentes.

As etapas nesta seção contêm a descrição de como configurar os seguintes recursos:

  • Amostras de redes VPC e sub-redes personalizadas
  • Regras de firewall do Google Cloud que permitem conexões de entrada para máquinas virtuais (VMs) do dispositivo de back-end
  • Rotas estáticas
  • Duas VMs cliente para testar conexões
  • Os componentes do balanceador de carga de rede de passagem interna a seguir:
    • VMs de back-end em um grupo de instâncias gerenciadas
    • Uma verificação de integridade do serviço de back-end
    • Um serviço de back-end interno na região us-west1 para gerenciar a distribuição de conexõ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 balanceamento de carga para várias NICs de back-end, conforme descrito aqui.

A aparência da topologia é a seguinte:

Exemplo detalhado de várias NICs de próximo salto para o balanceador de carga de rede de passagem interno.
Exemplo detalhado de várias NICs de próximo salto para o balanceador de carga de rede de passagem interno (clique para ampliar).

O diagrama mostra alguns dos recursos que o exemplo cria:

  • Instâncias de aplicativo atrás de um balanceador de carga de rede de passagem interna (fr-ilb1, neste exemplo). As instâncias do aplicativo têm apenas endereços IP internos.
  • Cada instância de aplicativo tem a sinalização can-ip-forward ativada. Sem essa sinalização, uma VM do Compute Engine poderá transmitir um pacote somente 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 IP do alias ou a um endereço IP de uma regra de encaminhamento resolvida para a VM. A sinalização can-ip-forward muda esse comportamento para que a VM consiga transmitir pacotes com qualquer endereço IP de origem.
  • Uma rota estática com o destino 10.50.1.0/24 e próximo salto definido como a regra de encaminhamento do balanceador de carga, fr-ilb1.

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

  • A rede VPC testing tem uma rota estática para o tráfego que é destinado à sub-rede 10.50.1.0/24. Essa rota direciona o tráfego para o balanceador de carga.
  • O balanceador de carga encaminha o tráfego para uma das instâncias de aplicativo com base na afinidade da sessão configurada. A afinidade da sessão afeta apenas o tráfego TCP.

Para outros casos de uso, consulte as informações sobre balanceadores de carga TCP/UDP internos como próximos saltos.

Como configurar as redes, a região e as sub-redes

Este exemplo usa as seguintes redes, regiões e sub-redes de VPC:

  • Redes: o exemplo requer duas redes, cada uma com pelo menos uma sub-rede. Cada VM de dispositivo de terceiros de back-end precisa ter pelo menos duas interfaces de rede, uma em cada rede VPC. As redes no exemplo são redes VPC de modo personalizado denominadas testing e production. A rede testing no 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 precisam 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, respectivamente, os intervalos de endereços IP principais 10.30.1.0/24 e 10.50.1.0/24.

Para criar as redes e sub-redes de exemplo, siga estas etapas.

Console

Crie a rede testing e a sub-rede testing-subnet:

  1. No Console do Google Cloud, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Informe um Nome de testing.

  4. Na seção Sub-redes:

    • Defina o Modo de criação de sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • Name: 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 a sub-rede production-subnet:

  1. No Console do Google Cloud, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Informe um Nome de production.

  4. Na seção Sub-redes:

    • Defina o Modo de criação de sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • Name: 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 de 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
    

Como 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 destinos na rede testing. Essa regra permite o tráfego de origens nos intervalos de endereços IP 10.30.1.0/24 e 10.50.1.0/24. Esses dois intervalos abrangem os endereços IP internos principais das VMs nas duas redes.

  • fw-allow-production-from-both: uma regra de entrada, aplicável a todos os destinos na rede production. Essa regra permite o tráfego de origens nos intervalos de endereços IP 10.30.1.0/24 e 10.50.1.0/24. Esses dois intervalos abrangem os endereços IP internos principais das VMs nas duas redes.

  • fw-allow-testing-ssh: uma regra de entrada aplicável às instâncias de VM na rede VPC testing. Essa regra permite a conectividade SSH de entrada na porta TCP 22 de qualquer endereço. É possível escolher um intervalo de IP de origem mais restritivo nessa regra. Por exemplo, especifique os intervalos de IP dos sistemas em que você planeja iniciar sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh para identificar as VMs às quais a regra de firewall se aplica.

  • fw-allow-production-ssh: uma regra de entrada aplicável às instâncias de VM na rede VPC production. Essa regra permite a conectividade SSH de entrada na porta TCP 22 de qualquer endereço. Assim como na regra fw-allow-testing-ssh, é possível escolher aqui um intervalo de IPs de origem mais restrito.

  • fw-allow-health-check: uma regra de entrada para as VMs de dispositivos de terceiros com balanceamento de carga. Essa regra permite o tráfego dos sistemas de verificação de integridade do Google Cloud (130.211.0.0/22 e 35.191.0.0/16). Neste exemplo, usamos a tag de destino allow-health-check para identificar as instâncias às quais ele precisa se aplicar.

  • fw-allow-production-health-check: uma regra de entrada para as VMs de dispositivos de terceiros com balanceamento de carga. Essa regra permite o tráfego dos sistemas de verificação de integridade do Google Cloud (130.211.0.0/22 e 35.191.0.0/16). Neste exemplo, usamos a tag de destino allow-health-check para identificar as instâncias às quais ele precisa se aplicar.

Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end. Crie uma regra de firewall para autorizar as verificações de integridade provenientes de intervalos de IPs dos sistemas de sondagem do Google Cloud. Consulte os intervalos de IP de sondagem para mais informações.

Console

  1. No Console do Google Cloud, acesse a página políticas de Firewall.

    Acesse as políticas de firewall

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

    • Name: fw-allow-testing-from-both
    • Rede: testing
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: 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 todos
  3. Clique em Criar.

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

    • Name: fw-allow-production-from-both
    • Rede: production
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: 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 todos
  5. Clique em Criar.

  6. Clique em Criar regra de firewall para criar uma regra que permita conexões SSH de entrada no ambiente de teste:

    • Name: fw-allow-testing-ssh
    • Rede: testing
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-ssh
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 0.0.0.0/0
    • Protocolos e portas: escolha os protocolos e portas especificados e digite: tcp:22
  7. Clique em Criar.

  8. Clique em Criar regra de firewall para criar uma regra que permita conexões SSH de entrada no ambiente de produção:

    • Name: fw-allow-production-ssh
    • Rede: production
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-ssh
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 0.0.0.0/0
    • Protocolos e portas: escolha os protocolos e portas especificados e digite: tcp:22
  9. Clique em Criar.

  10. Clique em Criar regra de firewall para criar uma regra que permita as verificações de integridade do Google Cloud no ambiente de teste:

    • Name: fw-allow-health-check
    • Rede: testing
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-health-check
    • Filtro de origem: intervalos IPv4
    • Intervalos 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 uma regra que permita as verificações de integridade do Google Cloud no ambiente de produção:

    • Name: fw-allow-production-health-check
    • Rede: production
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-health-check
    • Filtro de origem: intervalos IPv4
    • Intervalos 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 autorizar a conexão SSH com VMs que tenham a tag de rede allow-ssh. Se você omitir source-ranges, o Google Cloud interpretará que a regra autoriza a conexão proveniente de 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 que permita a conectividade SSH para VMs com a tag 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 autorizar verificações de integridade do Google Cloud em VMs de 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 de firewall fw-allow-production-health-check para autorizar verificações de integridade do Google Cloud em VMs de 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
    

Como criar os dispositivos virtuais de terceiros

As etapas a seguir demonstram como criar um modelo de instância e um grupo de instâncias regionais gerenciadas com mais de uma interface de rede. Esse grupo de instâncias é usado como o dispositivo virtual de terceiros neste exemplo.

Console

É necessário usar a gcloud nesta etapa porque você precisa criar um modelo de instância com mais de uma interface de rede. No momento, não é possível criar modelos de instância com mais de uma interface de rede no console do Google Cloud.

gcloud

  1. Crie um arquivo local chamado 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 seus dispositivos virtuais de terceiros. O modelo precisa incluir a sinalização --can-ip-forward para que as instâncias de VM criadas a partir dele 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 gerenciadas para seus dispositivos virtuais de terceiros. Esse comando cria um grupo de instâncias gerenciadas regionais que podem ser escalonadas automaticamente em us-west1.

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

Como criar os recursos de balanceamento de carga

Estas etapas configuram todos os componentes do balanceador de carga de rede de passagem interno, começando com verificação de integridade e serviço de back-end e, em seguida, componentes de front-end:

  • Verificação de integridade: neste exemplo, a verificação de integridade de HTTP verifica uma resposta HTTP 200 (OK). Para mais informações, consulte a seção sobre verificações de integridade da visão geral do balanceador de carga de rede interno de passagem.

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

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

  • Endereço IP interno: no exemplo, é especificado o endereço IP interno 10.30.1.99 para a regra de encaminhamento.

Console

Iniciar a configuração

  1. No console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Criar balanceador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de rede (TCP/UDP/SSL) e clique em Próxima.
  4. Em Proxy ou passagem, selecione Balanceador de carga de passagem e clique em Próxima.
  5. Em Voltado ao público ou interno, selecione Interno e clique em Próxima.
  6. Clique em Configurar.

Criar o primeiro balanceador de carga

  1. Defina o Nome como ilb1.
  2. Defina a Região como us-west1.
  3. Defina o Rede para testing.
  4. Clique em Configuração de back-end e faça as alterações a seguir:
    1. Em Back-ends, na seção Novo item, selecione o grupo de instâncias third-party-instance-group e clique em Concluído.
    2. Em Verificação de integridade, escolha Criar outra verificação de integridade, insira as informações a seguir e clique em Salvar e continuar:
      • Name: hc-http-80
      • Protocolo: HTTP
      • Porta: 80
      • Protocolo de proxy: NONE
      • Caminho da solicitação: / Ao usar o console do Google Cloud para criar o balanceador de carga, a verificação de integridade será global. Se você quiser criar uma verificação de integridade regional, use gcloud ou a API.
    3. Em Afinidade da sessão, selecione IP do cliente.
    4. Verifique se há uma marca de seleção azul ao lado de Configuração do back-end antes de continuar. Revise esta etapa se não houver marca.
  5. Clique em Configuração de front-end. Na seção Novo IP de front-end e porta, faça as seguintes alterações:
    1. Nome: fr-ilb1
    2. Sub-rede: testing-subnet
    3. Em IP interno, escolha Reservar um endereço IP interno estático, insira as informações a seguir e clique em Reservar:
      • Nome: ip-ilb
      • Endereço IP estático: Quero escolher
      • Endereço IP personalizado: 10.30.1.99
    4. Portas: escolha Individual e insira 80 no Número da porta. Lembre-se de que a escolha de um protocolo e porta para o balanceador de carga não limita os protocolos e portas usados quando o balanceador de carga é o próximo salto de uma rota.
    5. Verifique se há uma marca de seleção azul ao lado de Configuração do front-end antes de continuar. Revise esta etapa se não houver marca.
  6. Clique em Analisar e finalizar. Verifique suas configurações.
  7. Clique em Criar.

Iniciar a configuração

  1. No console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Criar balanceador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de rede (TCP/UDP/SSL) e clique em Próxima.
  4. Em Proxy ou passagem, selecione Balanceador de carga de passagem e clique em Próxima.
  5. Em Voltado ao público ou interno, selecione Interno e clique em Próxima.
  6. Clique em Configurar.

Criar o segundo balanceador de carga

  1. Defina o Nome como ilb2.
  2. Defina a Região como us-west1.
  3. Defina o Rede para production.
  4. Clique em Configuração de back-end e faça as alterações a seguir:
    1. Em Back-ends, na seção Novo item, selecione o grupo de instâncias third-party-instance-group e clique em Concluído.
    2. Em Verificação de integridade, selecione hc-http-80.
    3. Em Afinidade da sessão, selecione IP do cliente.
    4. Verifique se há uma marca de seleção azul ao lado de Configuração do back-end antes de continuar. Revise esta etapa se não houver marca.
  5. Clique em Configuração de front-end. Na seção Novo IP de front-end e porta, faça as seguintes alterações:
    1. Nome: fr-ilb2
    2. Sub-rede: production-subnet
    3. Em IP interno, escolha Reservar um endereço IP interno estático, insira as informações a seguir e clique em Reservar:
      • Name: ip-ilb2
      • Endereço IP estático: Quero escolher
      • Endereço IP personalizado: 10.50.1.99
    4. Portas: escolha Individual e insira 80 no Número da porta. Lembre-se de que a escolha de um protocolo e porta para o balanceador de carga não limita os protocolos e portas usados quando o balanceador de carga é o próximo salto de uma rota.
    5. Verifique se há uma marca de seleção azul ao lado de Configuração do front-end antes de continuar. Revise esta etapa se não houver marca.
  6. Clique em Analisar e finalizar. Verifique suas configuraçõ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 integridade HTTP para testar a conectividade TCP com as 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 dos 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 conecte-as aos serviços de back-end para concluir a configuração do balanceador de carga. Lembre-se de que o protocolo (TCP) e a porta (80) dos balanceadores de carga não limitam as portas e protocolos que são encaminhados para as instâncias de back-end (os dispositivos virtuais de terceiros) quando a carga Os balanceadores são usados como próximos saltos de 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
    

Como criar as rotas estáticas que definem os balanceadores de carga como os próximos saltos

Crie duas rotas estáticas que usam um balanceador de carga de próximo salto.

Console

Crie a primeira rota

  1. No Console do Google Cloud, acesse a página Rotas.

    Acessar a página Rotas

  2. Clique em Criar rota.

  3. Como Nome da rota, insira ilb-nhop-dest-10-50-1.

  4. Selecione a rede testing.

  5. Como Intervalo de IP de destino, digite 10.50.1.0/24.

  6. Em Tags da instância, insira my-network-tag.

  7. Em Próximo salto da rota, selecione Especificar uma regra de encaminhamento do balanceador de carga 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. Como nome da regra de encaminhamento, selecione fr-ilb1.

  9. Clique em Criar.

Crie a segunda rota

  1. Clique em Criar rota.
  2. Como Nome da rota, insira ilb-nhop-dest-10-30-1.
  3. Selecione a rede testing.
  4. Como Intervalo de IP de destino, digite 10.30.1.0/24.
  5. Em Próximo salto da rota, selecione Especificar uma regra de encaminhamento do balanceador de carga 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. Como 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 conforme necessário.

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

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

Se quiser, você pode especificar uma ou mais tags de instância na rota. A rota pode ser aplicada a VMs específicas se você especificar tags de rede na rota. Se você não especificar nenhuma tag de rede, a rota será aplicada a todas as VMs na rede VPC. Neste exemplo, a rota usa my-network-tag para a tag 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

Como criar a instância de VM testing

No exemplo abaixo, é criada uma instância de VM com o endereço IP 10.30.1.100 na sub-rede testing-subnet (10.30.1.0/24), na rede VPC testing.

gcloud

  1. Execute o comando a seguir para criar testing-vm.

    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'
    

Como criar a instância de VM production

No exemplo abaixo, é criada uma instância de VM com o endereço IP 10.50.1.100 na sub-rede production-subnet (10.50.1.0/24), na rede VPC production.

gcloud

A production-vm pode estar em qualquer zona na mesma região do balanceador de carga. Além disso, ela pode usar qualquer sub-rede nessa região. No exemplo, production-vm está na zona us-west1-a.

  1. Execute o comando a seguir para criar production-vm.

    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'
    

Como testar o balanceamento de carga em uma implantação de várias NICs

  1. Verifique a integridade 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 conectividade a partir da VM testing.

    gcloud compute ssh testing-vm --zone=us-west1-a
    
    curl http://10.50.1.99
    
    exit
    
  3. Teste a conectividade a partir da VM production.

    gcloud compute ssh production-vm --zone=us-west1-a
    
    curl http://10.30.1.99
    
    exit
    

Como ativar o hash simétrico

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

Para ativar esse comportamento de hash em balanceadores de carga de rede de passagem internos, é necessário recriar a regra de encaminhamento e a rota de próximo salto.

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

Excluir e recriar as regras de encaminhamento

Console

Excluir sua regra de encaminhamento e criar uma nova

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique no balanceador de carga be-ilb e em Editar.

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

  4. Mantenha o ponteiro do mouse sobre a regra de encaminhamento e clique em Excluir para removê-lo.

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

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

    1. Name: FORWARDING_RULE_NAME
    2. Sub-rede: SUBNET_NAME
    3. Em IP interno, selecione IP_ADDRESS
    4. Portas: PORT_NUMBER ou ALL.
    5. Clique em Concluído.
    6. Verifique se há uma marca de seleção azul ao lado de Configuração do front-end antes de continuar. Revise esta etapa se não houver marca.
  7. Clique em Analisar e finalizar. Verifique suas configurações.

  8. Clique em Criar.

gcloud

  1. Exclua as regras de encaminhamento atuais.

    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 conversão de endereços de rede de origem (SNAT) não é necessária quando todos os itens a seguir são verdadeiros:

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

Converta uma rota de balanceador de carga de rede de passagem interno do próximo salto para usar hash simétrico seguindo estas etapas:

  • Verifique se o serviço de back-end do balanceador de carga de rede de passagem interna não usa a configuração de afinidade de sessão NONE.

  • 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 fazendo referência à nova regra de encaminhamento. Verifique se essa rota de substituição tem uma prioridade mais alta do que a rota atual.

  • Exclua a rota existente de menor prioridade (referenciando a regra de encaminhamento anterior) e exclua a regra de encaminhamento anterior.

Limpeza

  1. Nas configurações 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. Exclua as rotas.

    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, exclua 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, exclua 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, exclua a verificação de integridade.

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

    Se você usar o console do Google Cloud, a verificação de integridade será global. Portanto, o comando é o seguinte:

    gcloud compute health-checks delete hc-http-80 \
         --global
    
  6. Exclua o grupo de instâncias gerenciadas.

    gcloud compute instance-groups managed delete third-party-instance-group \
        --region=us-west1
    
  7. Exclua os modelos de instância.

    gcloud compute instance-templates delete third-party-template
    
    gcloud compute instance-templates delete third-party-template-multinic
    
  8. Exclua 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
    

A seguir