Balanceadores de carga TCP/UDP internos como próximos saltos

O balanceamento de carga TCP/UDP interno é regional. Com ele, é possível executar e escalonar os serviços por trás de um endereço IP de balanceamento de carga interno. Use um balanceador de carga TCP/UDP interno como o próximo salto a que os pacotes são encaminhados ao longo do caminho até o destino final. Para fazer isso, defina o balanceador de carga como o próximo salto em uma rota estática personalizada.

Antes de analisar as informações desta página, você já deve estar familiarizado com os conceitos do seguinte:

Um próximo salto do balanceador de carga TCP/UDP interno é útil nos seguintes casos:

  • Para balancear a carga do tráfego em várias VMs que estão funcionando como VMs de gateway ou de roteador.

  • Para usar dispositivos virtuais de gateway como o próximo salto de uma rota padrão. Com essa configuração, as instâncias de máquina virtual (VM) na rede de nuvem privada virtual (VPC) enviam tráfego para a Internet por meio de um conjunto de VMs de gateway virtual com balanceamento de carga.

  • Para enviar tráfego por meio de vários balanceadores de carga em duas ou mais direções usando o mesmo conjunto de gateways de multi-NIC ou VMs de roteador como back-ends. Para isso, é preciso criar um balanceador de carga para usar como o próximo salto de uma rota estática personalizada em cada rede VPC. Cada balanceador de carga TCP/UDP interno opera em uma única rede VPC, distribuindo o tráfego para as interfaces de rede das VMs de back-end dessa rede.

Arquitetura

No diagrama a seguir, um grupo de instâncias de VM de VMs de roteador serve como back-end para dois balanceadores de carga diferentes. O primeiro balanceamento de carga TCP/UDP interno envia pacotes para nic0 das VMs de back-end e o segundo balanceamento de carga TCP/UDP interno envia pacotes para nic1 nos mesmos back-ends.

Balanceamento de carga para várias NICs (clique para ampliar)
Balanceamento de carga para várias NICs (clique para ampliar)

Benefícios do uso do balanceador de carga TCP/UDP interno como próximo salto

Quando o balanceador de carga for o próximo salto de uma rota estática, nenhuma configuração especial será necessária nos sistemas operacionais convidados das VMs cliente da rede VPC em que a rota está definida. As VMs do cliente enviam pacotes aos back-ends do balanceador de carga por meio de roteamento de rede VPC de maneira bump-in-the-wire.

O uso de um balanceador de carga TCP/UDP interno como próximo salto de uma rota estática garante os mesmos benefícios desse tipo de balanceamento. A verificação de integridade do balanceador de carga garante que novas conexões sejam roteadas para VMs de back-end íntegras. Usar um grupo de instâncias gerenciadas como back-end, possibilita configurar o escalonamento automático para aumentar ou diminuir o conjunto de VMs com base na demanda de serviço.

Especificações

Veja a seguir especificações para o uso de balanceadores de carga TCP/UDP internos como próximos saltos.

Rotas

Crie uma rota estática personalizada para transmitir TCP, UDP e outro tráfego de protocolo a um balanceador de carga TCP/UDP interno, em que o balanceador de carga é o próximo salto da rota estática para criar um anexo da VLAN de monitoramento. Ela pode ser um prefixo CIDR externo (publicamente roteável) ou um prefixo CIDR interno, desde que ele não entre em conflito com uma rota de sub-rede. Por exemplo, é possível substituir a rota padrão (0.0.0.0/0) por uma que direcione o tráfego para VMs de back-end de terceiros no processamento de pacotes.

Opções para especificar o próximo salto

Há duas opções para especificar o balanceador de carga como o próximo salto.

Opção de especificação Rede do próximo salto Pode ser exportado para redes com peering
Nome da regra de encaminhamento e região do balanceador de carga O balanceador de carga e a rota do próximo salto precisam estar na mesma rede VPC Sim, exportando rotas personalizadas (aplicável a rotas sem tags)
Endereço IP interno da regra de encaminhamento O balanceador de carga de próximo salto pode estar na mesma rede VPC que a rota ou em uma rede VPC com peering. Sim, sempre exportado (exceto para rotas com tags)

Afinidade da sessão do IP cliente

A afinidade da sessão do IP cliente é uma opção de afinidade de sessão disponível. É uma afinidade de duas tuplas que usa o endereço IP de origem e o de destino como entradas para uma função de hash.

Ao usar um balanceador de carga TCP/UDP interno sozinho, o endereço IP de destino é o endereço IP da regra de encaminhamento do balanceador de carga. A afinidade da sessão do IP cliente nesse contexto indica que as conexões de um cliente com um endereço IP de origem constante serão entregues à mesma VM de back-end se ela estiver em condições íntegras.

Por outro lado, ao usar um balanceador de carga TCP/UDP interno como próximo salto de uma rota estática, o endereço IP de destino varia, porque as VMs de back-end do balanceador de carga processam e encaminham pacotes para destinos diferentes. Usar a afinidade da sessão do IP cliente nesse contexto não faz com que os pacotes sejam processados pela mesma VM de back-end, mesmo se o cliente tiver um endereço IP de origem constante.

Intervalo de destino

O destino de uma rota estática personalizada não pode ser igual ou mais específico do que uma rota de sub-rede. Observe que mais específico significa que a máscara de sub-rede é mais longa. Essa regra se aplica a todas as rotas estáticas personalizadas, incluindo quando o próximo salto é um balanceador de carga TCP/UDP interno. Por exemplo, suponha que a rota de sub-rede seja 10.140.0.0/20. O destino de uma rota estática personalizada não pode ser o mesmo (10.140.0.0/20) e não pode ser mais específico, como em 10.140.0.0/22.

Mesma região e rede VPC

Rotas estáticas personalizadas que usam balanceadores de carga TCP/UDP internos como próximos saltos estão limitadas ao seguinte:

  • Uma única rede VPC. O balanceador de carga e a rota estática personalizada precisam estar na mesma rede VPC.

  • Uma única região ou todas as regiões. A menos que você configure o acesso global, a rota estática personalizada ficará disponível apenas para recursos que estiverem na mesma região que o balanceador de carga. Essa restrição regional é aplicada mesmo que a própria rota faça parte da tabela de roteamento de toda a rede VPC. Se o acesso global for ativado, a rota estática personalizada ficará disponível para os recursos em qualquer região.

Como divulgar a rota estática personalizada

Para anunciar o prefixo (destino) da rota estática personalizada, use uma divulgação de rota personalizada do Cloud Router. O escopo da divulgação de rota depende da configuração de acesso global do balanceador de carga, da seguinte maneira:

  • Quando o acesso global é desativado, o balanceador de carga TCP/UDP interno fica disponível apenas para VMs, túneis do Cloud VPN e anexos do Cloud Interconnect (VLANs) que estão na mesma região que o balanceador de carga. Consequentemente, uma divulgação de rota personalizada para o prefixo de uma rota estática personalizada só faz sentido se o Cloud Router e o balanceador de carga estiverem na mesma região.

  • Quando o acesso global está ativado, o balanceador de carga TCP/UDP interno fica disponível para VMs, túneis do Cloud VPN e anexos do Cloud Interconnect (VLANs) que estão em qualquer região. Com o roteamento dinâmico global, os sistemas locais podem usar a rota estática personalizada de qualquer região conectada.

A tabela a seguir resume a acessibilidade do balanceador de carga.

Acesso global Modo de roteamento dinâmico da rede VPC Acesso do balanceador de carga
Desativado Regional Acessível por roteadores na mesma região
Desativado Global Acessível por roteadores na mesma região
Ativada Regional Acessível por todos os roteadores em qualquer região
Ativada Global Acessível por todos os roteadores em qualquer região

Para mais informações, consulte Balanceamento de carga TCP/UDP interno e redes conectadas.

Ordem de operações

É preciso criar um balanceador de carga TCP/UDP interno antes de criar uma rota estática personalizada que o use como próximo salto. O balanceador de carga precisa existir antes da criação da rota. Se você tentar criar uma rota que se refere a um balanceador de carga que não existe, o Google Cloud retornará um erro.

Para especificar o próximo salto interno de um balanceador de carga TCP/UDP, use o nome da regra de encaminhamento e a região do balanceador de carga ou o endereço IP interno associado à regra de encaminhamento.

Depois de criar uma rota com um próximo salto que se refere a um balanceador de carga TCP/UDP interno, não é possível excluir o balanceador de carga, a menos que a rota seja excluída antes. Especificamente, não é possível excluir uma regra de encaminhamento interna até que nenhuma rota estática personalizada use essa regra de encaminhamento como próximo salto.

Requisitos de back-end

  • É preciso configurar todas as VMs de back-end do balanceador de carga TCP/UDP interno para permitir o encaminhamento de IP (--can-ip-forward = True). Para mais informações, consulte Considerações sobre roteamento baseado em instância ou balanceador de carga.

  • Balanceadores de carga TCP/UDP interno com nós do Google Kubernetes Engine (GKE) como back-ends não podem ser usados como próximo salto de rotas estáticas personalizadas. O software dos nós só pode rotear o tráfego para os pods se o destino corresponder a um endereço IP gerenciado pelo cluster, não a um destino arbitrário.

Processamento de TCP, UDP e outros tráfegos de protocolo

Quando um balanceador de carga TCP/UDP interno é implantado como um próximo salto, o Google Cloud encaminha todo o tráfego em todas as portas para as VMs de back-end, independentemente do seguinte:

  • O protocolo e a configuração de porta da regra de encaminhamento
  • Configuração de protocolo do serviço de back-end

O balanceador de carga TCP/UDP interno, que é o próximo salto da rota, oferece suporte perfeitamente ao encaminhamento de todo o tráfego para protocolos compatíveis com as redes VPC do Google Cloud (como TCP, UDP e ICMP).

Outras considerações

  • Quando nenhum back-end é íntegro. Quando todos os back-ends de um balanceador de carga TCP/UDP interno falharem nas verificações de integridade, as rotas que usam esse próximo salto ainda estarão em vigor. Os pacotes processados pela rota são enviados para um dos back-ends do balanceador de carga do próximo salto, de acordo com a distribuição de tráfego.

  • Não é possível usar regras de encaminhamento que usam um endereço IP interno comum (--purpose=SHARED_LOADBALANCER_VIP). O balanceador de carga TCP/UDP interno de próximo salto e as regras de encaminhamento do balanceador de carga TCP/UDP interno com um endereço IP comum são recursos mutuamente exclusivos. Um balanceador de carga TCP/UDP interno de próximo salto precisa usar um endereço IP exclusivo da regra de encaminhamento do balanceador de carga para que apenas um serviço de back-end (um balanceador de carga) seja referenciado sem ambiguidade. É possível que as regras de encaminhamento que usam um endereço IP interno comum se refiram a diferentes serviços de back-end (diferentes balanceadores de carga TCP/UDP internos).

  • Mesmo destino e vários balanceadores de carga TCP/UDP internos de próximo salto. Se você criar duas ou mais rotas estáticas personalizadas com o mesmo destino usando os próximos saltos do balanceador de carga TCP/UDP interno, o Google Cloud nunca distribuirá o tráfego entre os próximos saltos do balanceador de carga usando ECMP. Se as rotas tiverem prioridades exclusivas, o Google Cloud usará o balanceador de carga TCP/UDP interno de próximo salto na rota com a prioridade mais alta. Se as rotas tiverem as mesmas prioridades, o Google Cloud ainda selecionará apenas um balanceador de carga TCP/UDP interno de próximo salto. Nesse caso, conforme ilustrado no diagrama abaixo, o Google Cloud usa um algoritmo interno determinístico para selecionar uma única regra de encaminhamento de próximo salto (forwarding-rule-a), ignorando outras rotas com a mesma prioridade.

    Mesmo destino, próximos saltos do balanceador de carga TCP/UDP interno diferentes
    Mesmo destino, próximos saltos do balanceador de carga TCP/UDP interno diferentes
  • Vários destinos e o mesmo balanceador de carga TCP/UDP interno do próximo salto.

    Com tags: se você usa tags de rede, é possível utilizar o mesmo balanceador de carga TCP/UDP interno de próximo salto para várias rotas estáticas personalizadas com o mesmo destino e prioridade.

    Sem tags: sem tags de rede, não é possível criar várias rotas estáticas personalizadas com a mesma combinação de destino, prioridade e próximo salto do balanceador de carga TCP/UDP interno. Por exemplo, route-x, route-y e route-z podem ser criados, mas route-x-copy não pode ser criado.

    Exemplos de rotas sem tag usando um próximo salto do balanceador de carga TCP/UDP interno comum
    Exemplos de rotas sem tag usando um próximo salto do balanceador de carga TCP/UDP interno comum
  • Tags de rede. É possível especificar tags de rede para que a rota do próximo salto se aplique apenas às instâncias do cliente que foram configuradas com a tag. Isso permite selecionar quais instâncias de clientes serão preenchidas com qual rota de próximo salto com tag e qual conjunto de dispositivos para o qual o tráfego será roteado.

    Você não precisa separar as diferentes instâncias de cliente em redes VPC separadas, cada uma apontando para o balanceador de carga TCP/UDP interno preferido de front-end de um conjunto de dispositivos.

    .
  • Várias rotas para o mesmo prefixo de destino. Com as tags, é possível especificar várias rotas para o mesmo destino com diferentes balanceadores de carga internos como próximos saltos. É possível usar tags ou prioridades diferentes para essas mesmas rotas de destino.

Casos de uso

Balanceadores de carga TCP/UDP internos podem ser usados como próximo salto em várias implantações e topologias.

Para cada exemplo, observe as seguintes diretrizes:

  • Cada interface de VM precisa estar em uma rede VPC separada.

  • Não é possível usar VMs de back-end ou balanceadores de carga para encaminhar o tráfego entre sub-redes na mesma rede VPC. Isso acontece porque não é possível modificar as rotas das sub-redes.

  • O balanceador de carga TCP/UDP interno é de passagem e definido por software. os pacotes são entregues às VMs de back-end sem alterações nas informações de origem ou destino (endereços ou endereços e portas).

    O roteamento, a filtragem de pacotes, o proxy e a conversão de endereços são responsabilidades das VMs de dispositivos virtuais que servem como back-ends para o balanceador de carga TCP/UDP interno.

Balanceador de carga TCP/UDP interno como o próximo salto para um gateway NAT

Neste caso de uso, é feito o balanceamento de carga do tráfego de VMs internas para várias instâncias de gateway NAT que encaminham esse tráfego para a Internet.

Caso de uso de NAT (clique para ampliar)
Caso de uso de NAT (clique para ampliar)

Hub and spoke: troca de rotas de próximo salto usando peering de rede VPC

Além de trocar rotas de sub-redes, é possível configurar o peering de rede VPC para exportar e importar rotas estáticas e dinâmicas personalizadas. As rotas estáticas personalizadas que têm um próximo salto do gateway de Internet padrão são excluídas. Rotas estáticas personalizadas que usam balanceadores de carga TCP/UDP internos de próximo salto estão incluídas.

Para configurar uma topologia hub and spoke com os dispositivos virtuais de firewall do próximo salto localizados na rede VPC hub, faça o seguinte:

  • Na rede VPC hub, crie um balanceador de carga TCP/UDP interno com dispositivos virtuais de firewall como back-ends.
  • Na rede VPC hub, crie uma rota estática personalizada e defina o próximo salto como o balanceador de carga TCP/UDP interno.
  • Conecte a rede VPC hub a cada uma das redes VPC spoke usando peering de rede VPC.
  • Para cada peering, configure a rede hub para exportar as rotas personalizadas e a rede spoke correspondente para importar rotas personalizadas. A rota com o próximo salto do balanceador de carga é uma das rotas que a rede hub exporta.

Sujeito à ordem de roteamento, o balanceador de carga do dispositivo de firewall do próximo salto da rede VPC hub está disponível nas redes spoke:

  • para clientes na mesma região que o balanceador de carga, se o acesso global estiver desativado
  • para clientes em todas as regiões, se o acesso global estiver ativado, de acordo com a ordem de roteamento.
Hub and spoke (clique para ampliar)
Hub and spoke (clique para ampliar)

Balanceamento de carga para várias NICs

No caso de uso a seguir, as VMs de back-end são instâncias virtuais de dispositivos (por exemplo, inspeção de pacotes, roteamento ou VMs de gateway) com NICs em várias redes VPC. Essas instâncias de dispositivo virtual podem ser soluções comerciais de terceiros ou soluções criadas por você. Os dispositivos virtuais são VMs do Compute Engine com várias NICs.

Neste exemplo, vemos um único conjunto de dispositivos virtuais de back-end em um grupo de instâncias de VMs gerenciadas.

Na rede VPC testing, o balanceador de carga TCP/UDP interno tem uma regra de encaminhamento chamada fr-ilb1. No exemplo, esse balanceador de carga distribui o tráfego para a interface nic0.

Na rede VPC production, outro balanceador de carga TCP/UDP interno tem uma regra de encaminhamento chamada fr-ilb2. Esse balanceador de carga distribui o tráfego para uma interface diferente, nic1 neste exemplo.

Tráfego com balanceamento de carga de várias NICs (clique para ampliar)
Tráfego com balanceamento de carga de várias NICs (clique para ampliar)

Para ver uma configuração detalhada, consulte Balanceamento de carga para várias NICs de back-end.

Hash simétrico

No exemplo anterior, não usamos a conversão de endereços de rede de origem (SNAT, na sigla em inglês). O SNAT não é necessário porque o Google Cloud usa hash simétrico. Isso significa que, quando os pacotes pertencem ao mesmo fluxo, o Google Cloud calcula o mesmo hash. Em outras palavras, o hash não muda quando o endereço IP de origem:porta é trocado pelo endereço IP de destino:porta.

Observações:

  • O hash simétrico é ativado automaticamente quando você cria a regra de encaminhamento do balanceador de carga interno TCP/UDP a partir de 22 de junho de 2021.

  • Para ativar o hash simétrico em balanceadores de carga TCP/UDP internos existentes, é necessário recriar a regra de encaminhamento e a rota do próximo salto, conforme descrito em Como ativar o hash simétrico ,

  • O hash simétrico é compatível apenas com balanceamento de carga TCP/UDP interno.

  • O hash simétrico é compatível com os seguintes tipos de afinidade de sessão para os protocolos TCP e UDP:

    • IP do cliente (2 tuplas)
    • IP e protocolo do cliente (3 tuplas)
    • IP, protocolo e porta do cliente (5 tuplas)
  • É possível usar o SNAT se seu caso de uso exigir por algum motivo.

A seguir