Como configurar o balanceamento de carga TCP/UDP interno para dispositivos de terceiros

Neste guia, há um exemplo que ensina a configurar um balanceador de carga TCP/UDP interno do Google Cloud para ser o próximo salto. Antes de seguir este guia, conheça bem os seguintes tópicos:

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 do Compute

Para mais informações, consulte estes guias:

Como configurar balanceadores de carga TCP/UDP internos como próximos saltos com back-ends comuns

Neste guia, você verá como usar um balanceador de carga TCP/UDP interno como o próximo salto de uma rota estática personalizada para integrar dispositivos virtuais escalonados horizontalmente.

A solução discutida neste guia cria VMs de dispositivo que executam o Debian Linux e iptables. As VMs de exemplo não executam nenhuma filtragem de pacotes, mas é possível adicionar essa funcionalidade modificando a configuração iptables 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 personalizadas
  • Duas VMs cliente para testar conexões
  • os seguintes componentes do balanceador de carga TCP/UDP interno:
    • 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 topologia tem esta aparência:

Exemplo detalhado de várias NICs de próximo salto para balanceamento de carga TCP/UDP interno
Exemplo detalhado de várias NICs de próximo salto para balanceamento de carga TCP/UDP interno (clique para ampliar)

O diagrama mostra alguns dos recursos que o exemplo cria:

  • Instâncias de aplicativo (no caso, VMs que executam software iptables) por trás de um balanceador de carga TCP/UDP interno (fr-ilb1, no 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 personalizada 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 personalizada 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 da sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • 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 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 da sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • 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 personalizadas:

    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 Firewall.

    Acessar o 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: IP ranges
    • Intervalos de IPs 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: IP ranges
    • Intervalos de IPs 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 destino: allow-ssh
    • Filtro de origem: IP ranges
    • Intervalos de IP 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 destino: allow-ssh
    • Filtro de origem: IP ranges
    • Intervalos de IP 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 destino: allow-health-check
    • Filtro de origem: IP ranges
    • Intervalos de IP 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 destino: allow-health-check
    • Filtro de origem: IP ranges
    • Intervalos de IP 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

Veja nas etapas abaixo como criar um modelo de instância e um grupo de instâncias regionais gerenciadas usando o software iptables como um dispositivo virtual de terceiros.

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 Cloud.

gcloud

  1. 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 \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --can-ip-forward \
        --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
        # Read VM network configuration:
        md_vm="http://169.254.169.254/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
        ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
        sleep 1
        ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
        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.
        apt-get update
        apt-get install apache2 -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 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 TCP/UDP 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 balanceamento de carga TCP/UDP interno.

  • 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

Criar o primeiro balanceador de carga

  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 Balanceamento de carga TCP, clique em Iniciar configuração.

  4. Em Somente voltado para a Internet ou interno, selecione Apenas entre minhas VMs.

  5. Clique em Continuar.

  6. Defina o Nome como ilb1.

  7. Clique em Configuração de back-end e faça as alterações a seguir:

    1. Região: us-west1
    2. Rede: testing
    3. Em Back-ends, na seção Novo item, selecione o grupo de instâncias third-party-instance-group e clique em Concluído.
    4. Em Verificação de integridade, escolha Criar outra verificação de integridade, insira as informações a seguir e clique em Salvar e continuar:
      • Nome: hc-http-80
      • Protocolo: HTTP
      • Porta: 80
      • Protocolo de proxy: NONE
      • Caminho da solicitação: / Ao usar o Console do 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.
    5. 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.
  8. Clique em Configuração do front-end. Na seção Novo IP do front-end e porta, faça as seguintes alterações:

    1. Name: 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.
  9. Clique em Analisar e finalizar. Verifique suas configurações.

  10. Clique em Criar.

Criar o segundo balanceador de carga

  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 Balanceamento de carga TCP, clique em Iniciar configuração.

  4. Em Somente voltado para a Internet ou interno, selecione Apenas entre minhas VMs.

  5. Clique em Continuar.

  6. Defina o Nome como ilb2.

  7. Clique em Configuração de back-end e faça as alterações a seguir:

    1. Região: us-west1
    2. Rede: production
    3. Em Back-ends, na seção Novo item, selecione o grupo de instâncias third-party-instance-group e clique em Concluído.
    4. Em Verificação de integridade, selecione hc-http-80.
    5. 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.
  8. Clique em Configuração do front-end. Na seção Novo IP do front-end e porta, faça as seguintes alterações:

    1. Name: fr-ilb2
    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:
      • 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.
  9. Clique em Analisar e finalizar. Verifique suas configurações.

  10. Clique em Criar.

  11. 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 personalizadas mostradas next-hop-ilb.

Console

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

    Acessar a página "Rotas".

Crie a primeira rota

  1. Clique em Criar rota.
  2. Como Nome da rota, insira ilb-nhop-dest-10-50-1.
  3. Selecione a rede testing.
  4. Como Intervalo de IP de destino, digite 10.50.1.0/24.
  5. Em Próximo salto da rota, selecione Especificar um balanceador de carga TCP/UDP interno de regra de encaminhamento.
  6. Como região do próximo salto, selecione us-west1.
  7. Como nome da regra de encaminhamento, selecione fr-ilb1.
  8. 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 um balanceador de carga TCP/UDP interno de regra de encaminhamento.
  6. Como região do próximo salto, selecione us-west1.
  7. Como nome da regra de encaminhamento, selecione fr-ilb2.
  8. Clique em Criar.

gcloud

Crie rotas avançadas 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.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=fr-ilb1 \
    --next-hop-ilb-region=us-west1
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-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=testing-subnet \
        --private-network-ip 10.30.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        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. Neste exemplo, a 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-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=production-subnet \
        --private-network-ip 10.50.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        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.100
    
    exit
    
  3. Teste a conectividade a partir da VM production.

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

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 TCP/UDP internos atuais, é 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 da Configuração de 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 do balanceador de carga TCP/UDP interno foi criada em 22 de junho de 2021 ou após essa data.
  • A rota estática personalizada 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 TCP/UDP interno não usa a configuração de afinidade de sessão NONE.

Converta uma rota de balanceador de carga TCP/UDP interno do próximo salto atual para usar hash simétrico seguindo estas etapas:

  • Verificar se o serviço de back-end do balanceador de carga TCP/UDP interno não usa a configuração de afinidade da 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 personalizada 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 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