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 gateway a que os pacotes serã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.

Essa configuração é útil nos casos a seguir:

  • Para balancear a carga do tráfego em várias VMs que estão funcionando como dispositivos de tradução de endereços de rede virtual (NAT, na sigla em inglês).

  • Para que um balanceador de carga funcione como o próximo salto de uma rota padrão. Quando as instâncias de máquina virtual (VM) na rede de nuvem privada virtual (VPC) enviam tráfego para a Internet, o tráfego é roteado por meio de dispositivos virtuais de gateway 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 VMs com várias NICs que os 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.

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

No diagrama anterior, um grupo de instâncias de VM serve como back-end para dois balanceadores de carga diferentes. Este caso de uso é chamado balanceadores de carga TCP/UDP internos como próximos saltos com back-ends comuns porque a carga de várias NICs (nic0 e nic1, neste caso) nas VMs de back-end está sendo balanceada. Essa implantação é permitida porque o balanceamento de carga TCP/UDP interno é compatível com o de qualquer interface nas instâncias de VM de back-end (não apenas a interface principal, nic0).

Por outro lado, dois conjuntos de instâncias de VM podem servir como back-ends para dois balanceadores de carga diferentes. Quando os tráfegos de entrada e saída têm perfis diferentes, é possível usar dois conjuntos de back-end. Esse caso de uso é chamado de balanceadores de carga TCP/UDP internos como próximos saltos com back-ends diferentes porque somente as cargas nas interfaces principais (nic0) nas VMs de back-end são balanceadas. Veja essa configuração no diagrama abaixo:

Balanceamento de carga para NICs individuais (clique para ampliar)
Balanceamento de carga para NICs individuais (clique para ampliar)

Crie uma rota estática personalizada para transmitir o tráfego TCP e UDP a um balanceador de carga TCP/UDP interno que seja o próximo salto dessa rota. Ela pode ser a rota padrão (0.0.0.0/0), 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.

Para usar a rota estática personalizada, as instâncias de VM em cada rede VPC precisam estar na mesma região que o balanceador de carga associado.

Se um Cloud Router estiver na mesma região que um balanceador de carga, é possível divulgar essa rota para outras redes conectadas usando divulgações de rota personalizada do Cloud Router. Para mais informações, consulte Balanceamento de carga TCP/UDP interno e redes conectadas.

Veja mais informações em:

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, não é preciso usar configurações explícitas nos clientes para enviar tráfego para o balanceador de carga ou para cada instância de VM de back-end. É possível integrar essas instâncias pelo modo 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.

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 a mesma (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.

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, em vez do 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

  • É necessário configurar todas as VMs de back-end do balanceamento 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 em 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 TCP e UDP 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 processa apenas o tráfego TCP e UDP e ignora todo o outro tráfego, como o ICMP. O tráfego que não usa o protocolo TCP ou UDP é tratado pela próxima rota mais específica na rede VPC. As rotas para tráfego não TCP e não UDP têm as seguintes características:

  • Eles não têm um balanceador de carga TCP/UDP interno como o próximo salto.
  • Eles são escolhidos de acordo com a ordem de roteamento.

Por exemplo, suponha que você tenha as seguintes rotas na sua rede VPC:

  • Destino: 1.1.1.1/32, próximo salto: balanceador de carga TCP/UDP interno
  • Destino: 1.0.0.0/8, próximo salto: gateway de Internet padrão

Para clientes localizados na mesma região que o balanceador de carga (ou em qualquer região quando o acesso global está ativado), o tráfego TCP e UDP destinado a 1.1.1.1/32 usa a rota com o próximo salto do balanceador de carga TCP/UDP interno.

Para tráfego não TCP e não UDP (como pings ICMP), a rota 1.0.0.0/8 é usada.

Outras especificações

  • Não é possível usar tags de rede em uma rota estática personalizada se ela tiver um balanceador de carga TCP/UDP interno como próximo salto.

  • Não é possível criar várias rotas estáticas personalizadas com a mesma prioridade, destino e próximo salto do balanceador de carga TCP/UDP interno. Por conta disso, cada rota estática personalizada com o mesmo balanceador de carga como próximo salto precisa ter pelo menos um destino ou uma prioridade exclusivos.

  • Se você tiver diferentes balanceadores de carga TCP/UDP internos como os próximos saltos para várias rotas com o mesmo destino e prioridade, o Google Cloud não distribuirá o tráfego entre os balanceadores de carga. Em vez disso, o Google Cloud escolhe apenas um dos balanceadores de carga como o próximo salto para todo o tráfego que corresponda ao destino e ignora os outros balanceadores de carga.

  • Quando você usa um balanceador de carga TCP/UDP interno como o próximo salto para uma rota estática personalizada, não é possível usar a sinalização --purpose=SHARED_LOADBALANCER_VIP com o endereço IP da regra de encaminhamento interno. Isso ocorre porque o endereço IP interno compartilhado pode referenciar indiretamente mais de um serviço de back-end.

Para mais informações, consulte Visão geral de rotas.

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. O NAT e o proxy são executados apenas pelas VMs de back-end, os dispositivos virtuais de firewall.

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 usam tags de rede ou que têm um próximo salto do gateway de Internet padrão são excluí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.

O balanceador de carga do dispositivo de firewall do próximo salto da rede VPC hub pode ser usado em cada rede spoke, 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, instâncias de firewall ou gateways NAT) com NICs em várias redes VPC. As instâncias de firewall e os gateways NAT podem ser fornecidos por terceiros como dispositivos virtuais. 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 de cada dispositivo virtual, mas poderia ser qualquer NIC.

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.

Balanceador de carga TCP/UDP interno como o próximo salto com uma única NIC

Como no caso de uso anterior, as VMs de back-end são instâncias virtuais de dispositivos (por exemplo, instâncias de firewall ou gateways NAT) com NICs em várias redes VPC.

Nos exemplos a seguir vemos dois conjuntos de dispositivos virtuais de back-end em dois grupos de instâncias de VM gerenciadas.

Os back-ends são resumidos da seguinte maneira:

Instâncias de balanceamento de carga do tráfego testingproduction Instâncias de balanceamento de carga do tráfego productiontesting
fw-instance-a
fw-instance-b
fw-instance-c
fw-instance-d
fw-instance-e
fw-instance-f

Na direção testingproduction, o tráfego tem origem na rede VPC testing. Na rede testing, o balanceador de carga TCP/UDP interno tem uma regra de encaminhamento chamada fr-ilb1. Neste exemplo são usados balanceadores de carga TCP/UDP internos com serviços de back-end que não têm um parâmetro network especificado. Ou seja, cada balanceador de carga só distribui o tráfego para a interface de rede principal de cada VM de back-end.

Tráfego com balanceamento de carga de NIC única (<code>testing</code>–<code>production</code>) (clique para ampliar)
Tráfego com balanceamento de carga de NIC única (testing-para-production) (clique para ampliar)

Na direção productiontesting, o tráfego tem origem na rede VPC production. Na rede production, outro balanceador de carga TCP/UDP interno tem uma regra de encaminhamento chamada fr-ilb2. É importante reforçar que neste exemplo são usados balanceadores de carga TCP/UDP internos com serviços de back-end que não têm um parâmetro network especificado. Ou seja, cada balanceador de carga só distribui o tráfego para a interface de rede principal de cada VM de back-end. Como cada dispositivo virtual pode ter apenas uma nic0, esta implantação requer dois conjuntos de dispositivos virtuais: o primeiro para balanceamento de carga de testingproduction e o segundo para balanceamento de carga de productiontesting.

Tráfego com balanceamento de carga de NIC única (<code>production</code>–<code>testing</code>) (clique para ampliar)
Tráfego com balanceamento de carga de NIC única (production-to-testing) (clique para ampliar)

A seguir