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:

Balanceamento de carga para apenas uma placa de rede (NIC) de back-end

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 integra dispositivos virtuais para que você não precise reconfigurar explicitamente seus clientes para enviar tráfego para cada dispositivo virtual. O exemplo neste guia de configuração envia todo o tráfego por meio de um conjunto de dispositivos virtuais de firewall com balanceamento de carga.

As etapas nesta seção descrevem 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 VMs de back-end
  • Uma rota estática personalizada
  • Uma VM 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 para os dispositivos de back-end da VM
    • 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

A topologia tem esta aparência:

Exemplo de NIC única de próximo salto para balanceamento de carga TCP/UDP interno (clique para ampliar)
Exemplo de NIC única 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 de dispositivo de firewall) 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 a um dos endereços IP da 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.
  • A instância do aplicativo realiza a conversão de endereço de rede de origem (SNAT, na sigla em inglês) para entregar pacotes ao grupo de instâncias na rede VPC production. No caso do tráfego de retorno, ela realiza a conversão de endereço de rede de destino (DNAT, na sigla em inglês) para entregar pacotes à instância de cliente na rede VPC testing.

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. Acesse a página "Redes VPC" no Console do Google Cloud.
    Acessar a página "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:
      • 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. Acesse a página "Redes VPC" no Console do Google Cloud.
    Acessar a página "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:
      • 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-subnet: uma regra de entrada aplicável a todos os destinos na rede testing, que autoriza o tráfego proveniente de intervalos 10.30.1.0/24. Essa regra permite que as instâncias de VM e os dispositivos de VM de terceiros na sub-rede testing-subnet se comuniquem.

  • fw-allow-production-subnet: uma regra de entrada aplicável a todos os destinos na rede production, que autoriza o tráfego proveniente de intervalos 10.50.1.0/24. Essa regra permite que as instâncias de VM e os dispositivos de VM de terceiros na sub-rede production-subnet se comuniquem.

  • fw-allow-testing-ssh: uma regra de entrada aplicável às instâncias de VM na rede VPC testing, que autoriza que qualquer endereço estabeleça conexão SSH de entrada com a porta TCP 22. É 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, que autoriza que qualquer endereço estabeleça conexão SSH de entrada com a porta TCP 22. 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 aplicável aos dispositivos de VM de terceiros com balanceamento de carga, que autoriza o tráfego proveniente de sistemas de verificação de integridade do Google Cloud (130.211.0.0/22 e 35.191.0.0/16). No exemplo, é usada a tag de destino allow-health-check para identificar as instâncias submetidas à regra.

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. Acesse a página "Firewall" no Console do Google Cloud.
    Acessar a página "Firewall"
  2. Clique em Criar regra de firewall e insira as seguintes informações para criar a regra que permite o tráfego de sub-rede:
    • Nome: fw-allow-testing-subnet
    • 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 IP de origem: 10.30.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 o tráfego de sub-rede:
    • Nome: fw-allow-production-subnet
    • 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 IP de origem: 10.50.1.0/24
    • Protocolos e portas: permitir todos
  5. Clique em Criar
  6. Clique em Criar regra de firewall novamente para criar a regra que permite conexões SSH de entrada:
    • Nome: 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 novamente para criar a regra que permite conexões SSH de entrada:
    • Nome: 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 pela terceira vez para criar uma regra que permita as verificações de integridade do Google Cloud:
    • 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: permitir todos
  11. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-testing-subnet para autorizar a comunicação com a sub-rede:

    gcloud compute firewall-rules create fw-allow-testing-subnet \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24 \
        --rules=tcp,udp,icmp
    
  2. Crie a regra de firewall fw-allow-production-subnet para permitir a comunicação a partir da sub-rede:

    gcloud compute firewall-rules create fw-allow-production-subnet \
        --network=production \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.50.1.0/24 \
        --rules=tcp,udp,icmp
    
  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,udp,icmp
    

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 \
        --region=us-west1 \
        --network-interface subnet=testing-subnet,address="" \
        --network-interface subnet=production-subnet \
        --tags=allow-ssh,allow-health-check \
        --image-family=debian-9 \
        --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 -H "Metadata-Flavor:Google" $md_net/0/gateway)"
        nic0_mask="$(curl -H "Metadata-Flavor:Google" $md_net/0/subnetmask)"
        nic1_gw="$(curl -H "Metadata-Flavor:Google" $md_net/1/gateway)"
        nic1_mask="$(curl -H "Metadata-Flavor:Google" $md_net/1/subnetmask)"
        nic1_addr="$(curl -H "Metadata-Flavor:Google" $md_net/1/ip)"
        # Start iptables:
        /sbin/iptables -t nat -F
        /sbin/iptables -t nat -A POSTROUTING \
        -s "$nic0_gw/$nic0_mask" \
        -d "$nic1_gw/$nic1_mask" \
        -o eth1 \
        -j SNAT \
        --to-source "$nic1_addr"
        /sbin/iptables-save
        # Use a web server to pass the health check for this example.
        # You should use a more complete test in production.
        apt-get update
        apt-get install apache2 -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 \
        --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 neste exemplo especifique o protocolo TCP, quando o balanceador de carga for o próximo salto de uma rota, os tráfegos TCP e UDP serão enviados aos back-ends do balanceador de carga.

  • 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 balanceador de carga e configurar um serviço de back-end

  1. Acesse a página "Balanceamento de carga" no Console do Google Cloud.
    Acessar a página "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 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.
  9. Clique em Analisar e finalizar. Verifique suas configurações.
  10. Clique em Criar.

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 um serviço de back-end interno na região us-west1.

    gcloud compute backend-services create ilb1 \
        --health-checks-region=us-west1 \
        --load-balancing-scheme=internal \
        --region=us-west1 \
        --health-checks=hc-http-80
    
  3. Adicione o grupo de instâncias que contém os dispositivos virtuais de terceiros como um back-end no serviço de back-end.

    gcloud compute backend-services add-backend ilb1 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
  4. Crie a regra de encaminhamento interna e conecte-a ao serviço de back-end para concluir a configuração do balanceador de carga. Lembre-se de que o protocolo (TCP) e a porta (80) do balanceador de carga interno não limitam as portas e protocolos que são encaminhados para as instâncias de back-end (os dispositivos virtuais de terceiros) quando o balanceador de carga é usado como o próximo salto de uma rota.

    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
    

Como criar a rota estática que define o balanceador de carga como o próximo salto

Quando você cria uma rota estática, não é possível usar next-hop-address para apontar para o endereço IP da regra de encaminhamento de um balanceador de carga. Isso ocorre porque, ao utilizar next-hop-address, o Google Cloud envia o tráfego para a instância de VM atribuída a esse endereço IP, e um balanceador de carga não é uma instância de VM. Como alternativa, se você quiser designar um balanceador de carga como próximo salto, use a sinalização next-hop-ilb, conforme demonstrado no exemplo.

Console

  1. Acesse a página "Rotas" no Console do Google Cloud.
    Acessar a página "Rotas"
  2. Clique em Criar rota.
  3. Como Nome da rota, digite "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. Certifique-se de que as tags não estejam especificadas, porque elas não são compatíveis com este recurso.
  7. Para o Próximo salto da rota, selecione Especificar um balanceador de carga TCP/UDP interno de regra de encaminhamento.
  8. Como região do próximo salto, selecione us-west1.
  9. Como nome da regra de encaminhamento, selecione fr-ilb1.
  10. Clique em Criar.

gcloud

Crie uma rota avançada com o próximo salto definido para a regra de encaminhamento do balanceador de carga e o intervalo de destino definido para a rota 10.50.1.0/24.

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

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-9 \
        --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. 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-9 \
        --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 NIC única

No teste, é feito o contato com o exemplo de VM de destino na rede VPC production a partir da VM cliente na rede VPC testing. O balanceador de carga é usado como próximo salto porque encaminha o pacote com destino 10.50.1.100 por meio do balanceador de carga, em vez de enviá-lo para o endereço IP do balanceador de carga.

No exemplo, o software iptables nas VMs de dispositivo de back-end íntegras do balanceador de carga faz o processamento de NAT do pacote.

  1. Conecte-se à instância da VM cliente.

    gcloud compute ssh testing-vm --zone=us-west1-a
    
  2. Faça uma solicitação da Web para o software do servidor da Web da instância de destino usando curl. A saída esperada é o conteúdo da página de índice na instância de destino (Page served from: destination-instance).

    curl http://10.50.1.100
    

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

É possível ampliar o exemplo ao fazer o balanceamento de carga para várias NICs de back-end, conforme descrito aqui.

Exemplo detalhado de várias NICs de próximo salto para balanceamento de carga TCP/UDP interno (clique para ampliar)
Exemplo detalhado de várias NICs de próximo salto para balanceamento de carga TCP/UDP interno (clique para ampliar)
  1. 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,udp,icmp
    
  2. Crie o novo modelo de instância.

    Para que essa configuração funcione perfeitamente com as verificações de integridade, configure o roteamento baseado em política para garantir que os pacotes de resposta de verificação de integridade de saída passem pela interface correta. As verificações de integridade usam endereços IP externos como origem das sondagens de verificação de integridade. Os sistemas operacionais convidados escolhem a NIC de saída com base no endereço IP de destino. Se tal endereço não pertencer ao intervalo da sub-rede, o padrão de NIC de saída será nic0. Nesse caso, configure uma tabela de roteamento separada para cada interface de rede com base na política.

    O roteamento de políticas com base na origem não funciona nos sistemas operacionais Windows e Mac.

    No modelo de VM de back-end, inclua o roteamento de políticas a seguir, em que 10.50.1.0/24 é a sub-rede com o balanceador de carga e eth1 da VM de várias NICs. O gateway padrão é 10.50.1.1:

    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-9 \
        --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")"
        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")"
        # 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 eth1 table rt-nic1
        ip route add 130.211.0.0/22 via $nic1_gw dev eth1 table rt-nic1
        # Start iptables:
        iptables -t nat -F
        iptables -t nat -A POSTROUTING \
        -s $nic0_gw/$nic0_mask \
        -d $nic1_gw/$nic1_mask \
        -o eth1 \
        -j SNAT \
        --to-source $nic1_addr
        iptables -t nat -A POSTROUTING \
        -s $nic1_gw/$nic1_mask \
        -d $nic0_gw/$nic0_mask \
        -o eth0 \
        -j SNAT \
        --to-source $nic0_addr
        iptables-save
        # Use a web server to pass the health check for this example.
        # You should use a more complete test in production.
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        echo "Example web page to pass health check" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    
  3. Atualize o grupo de instâncias.

    gcloud compute instance-groups managed set-instance-template \
        third-party-instance-group \
        --region us-west1 \
        --template=third-party-template-multinic
    
  4. Crie novamente o grupo de instâncias gerenciadas usando o novo modelo third-party-template-multinic.

    gcloud compute instance-groups managed rolling-action replace \
        third-party-instance-group \
        --region us-west1
    

    Aguarde alguns minutos até que as instâncias estejam prontas. Para verificar o progresso, use o comando list-instances.

    gcloud compute instance-groups managed list-instances \
        third-party-instance-group \
        --region us-west1
    

    A saída será como esta:

    NAME                             ZONE        STATUS   ACTION  INSTANCE_TEMPLATE              VERSION_NAME                        LAST_ERROR
    third-party-instance-group-5768  us-west1-a  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-4zf4  us-west1-b  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-f6lm  us-west1-c  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    
  5. Configure os recursos do balanceador de carga na rede VPC production.

    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
    
    gcloud compute backend-services add-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    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
    
    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 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
    

Limpar

  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