Visão geral do balanceamento de carga de rede TCP/UDP externo baseado em pool de destino

O balanceamento de carga de rede TCP/UDP externo do Google Cloud, chamado de balanceamento de carga de rede, é um balanceador de carga regional sem proxy.

O balanceamento de carga de rede distribui o tráfego TCP ou UDP entre as instâncias de máquina virtual (VM, na sigla em inglês) de back-end na mesma região em uma rede de nuvem particular virtual (VPC). Um balanceador de carga de rede pode receber tráfego de:

  • qualquer cliente na Internet;
  • VMs do Google Cloud com IPs externos
  • VMs do Google Cloud que têm acesso à Internet pela Cloud NAT ou pela NAT baseada em instância.

Cada balanceador de carga de rede é compatível com tráfego TCP ou UDP (não ambos).

O escopo de um balanceador de carga de rede é regional, e não global. Isso significa que todas as instâncias de back-end de um balanceador de carga de rede precisam estar localizadas na mesma região. É possível colocar back-ends em qualquer zona da região.

O balanceador de carga de rede é compatível com todas as portas. Você pode usá-lo para balancear a carga do tráfego TCP e UDP. Como se trata de balanceador de carga de passagem, seus próprios back-ends encerram a conexão TCP com balanceamento de carga ou os pacotes UDP. Por exemplo, você pode executar um servidor da Web HTTPS nos back-ends e usar um balanceamento de carga de rede para encaminhar solicitações para ele, encerrando o TLS nos seus próprios back-ends.

Arquitetura

O balanceador de carga é composto de vários componentes de configuração. Um único balanceador de carga pode ter o seguinte:

Um balanceador de carga de rede sempre tem um pool de destino. Várias regras de encaminhamento podem fazer referência ao pool de destino.

O pool de destino é um back-end do balanceador de carga. Ele especifica as instâncias de back-end entre as quais o tráfego é balanceado. Cada regra de encaminhamento é um front-end do balanceador de carga. Lembre-se de que há limites para o número de regras de encaminhamento e pools de destino por projeto.

Os balanceadores de carga de rede equilibram a carga nos sistemas com base nos dados do protocolo IP de entrada, como endereço, porta e tipo de protocolo.

O balanceador de carga de rede é de passagem, portanto, seus back-ends recebem a solicitação original do cliente. O balanceador de carga de rede não descarrega nem usa proxy TLS. O tráfego é encaminhado diretamente para suas VMs.

Ao criar uma regra de encaminhamento para o balanceador de carga, você recebe um endereço IP virtual (VIP, na sigla em inglês) efêmero ou reserva um VIP proveniente de um bloco de rede regional.

Em seguida, associe essa regra de encaminhamento aos seus pools de destino. O VIP é anycasted com base nos pontos de presença globais do Google, mas os back-ends de um balanceador de carga de rede são regionais. O balanceador de carga não pode ter back-ends que abrangem várias regiões.

É possível usar os firewalls do Google Cloud para controlar ou filtrar o acesso às VMs de back-end.

O balanceador de carga de rede examina as portas de origem e de destino, o endereço IP e o protocolo para determinar como encaminhar pacotes. Para o tráfego TCP, é possível modificar o comportamento de encaminhamento do balanceador de carga configurando a afinidade da sessão. O balanceador de carga de rede encaminha os pacotes para a primeira interface de rede (nic0) das instâncias no pool de destino.

O balanceador de carga preserva os endereços IP de origem dos pacotes de entrada. O endereço IP de destino dos pacotes de entrada é o endereço IP externo regional associado à regra de encaminhamento do balanceador de carga.

Algoritmo de distribuição de carga

Por padrão, para distribuir o tráfego a instâncias, o valor de afinidade da sessão é definido como NONE. O Cloud Load Balancing escolhe uma instância com base em um hash do IP e da porta de origem, do IP e da porta de destino e do protocolo. Isso significa que as conexões TCP de entrada são distribuídas entre as instâncias e que cada conexão pode seguir para uma instância diferente. Todos os pacotes de uma conexão são direcionados para a mesma instância até a conexão ser encerrada. As conexões estabelecidas não são consideradas no processo de balanceamento de carga.

Seja qual for a configuração de afinidade da sessão, todos os pacotes de uma conexão são direcionados para a instância escolhida até que a conexão seja encerrada. Uma conexão atual não tem impacto nas decisões de balanceamento de carga para novas conexões de entrada. Isso poderá resultar em um desequilíbrio entre os back-ends se houver conexões TCP de longa duração em uso.

Opte por uma configuração diferente de afinidade da sessão se várias conexões de um cliente precisam seguir para a mesma instância.

Pools de destino

Um recurso de pool de destino define um grupo de instâncias que receberá o tráfego de entrada das regras de encaminhamento. Quando uma regra de encaminhamento direciona o tráfego para um pool de destino, o Cloud Load Balancing escolhe uma instância desses pools de destino com base em um hash do IP e da porta de origem e do IP e da porta de destino. Cada pool de destino opera em uma única região e distribui o tráfego para a primeira interface de rede (nic0) da instância de back-end. Para mais informações sobre como o tráfego é distribuído para instâncias, consulte a seção Carregar algoritmo de distribuição neste tópico.

Os balanceadores de carga de rede não são proxies. As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. O balanceador de carga preserva os endereços IP de origem dos pacotes. O endereço IP de destino dos pacotes de entrada é o endereço IP externo regional associado à regra de encaminhamento do balanceador de carga. Consequentemente:

  • As instâncias que participam como VMs de back-end para balanceadores de carga de rede precisam executar o ambiente convidado Linux, o ambiente convidado Windows apropriado ou outros processos com funcionalidade equivalente.

    O ambiente do sistema operacional convidado (ou um processo equivalente) é responsável por configurar as rotas locais em cada VM de back-end. Essas rotas permitem que a VM aceite pacotes que tenham um destino que corresponda ao endereço IP da regra de encaminhamento do balanceador de carga.

  • Nas instâncias de back-end que aceitam tráfego com carga balanceada, configure o software para vinculação com o endereço IP associado à regra de encaminhamento do balanceador de carga (ou a qualquer endereço IP, 0.0.0.0/0).

O balanceamento de carga da rede é compatível com o Escalonador automático do Cloud Load Balancing, que permite aos usuários realizar o escalonamento automático nos grupos de instâncias em um pool de destino com base na utilização de back-end. Para mais informações, consulte Como fazer o escalonamento baseado no uso da CPU.

Se você quer que o pool de destino contenha uma única instância de VM, use o recurso Encaminhamento de protocolo.

Os pools de destino só podem ser usados com regras de encaminhamento que processem tráfego TCP e UDP. Para todos os outros protocolos, crie uma instância de destino. Crie um pool de destino para usá-lo com uma regra de encaminhamento. Cada projeto pode ter até 50 pools de destino.

Regras de encaminhamento

As regras de encaminhamento funcionam em conjunto com os pools de destino para dar suporte ao balanceamento de carga. Para usar o balanceamento de carga, você precisa criar uma regra de encaminhamento que direcione o tráfego para pools de destino específicos. Não é possível equilibrar a carga do seu tráfego sem uma regra de encaminhamento.

Cada regra de encaminhamento corresponde a um determinado endereço IP, protocolo e, opcionalmente, intervalo de portas a um único pool de destino. Quando o tráfego é enviado para um endereço IP externo que é exibido por uma regra de encaminhamento, a regra de encaminhamento direciona esse tráfego para o pool de destino correspondente.

Se você estiver balanceando a carga de pacotes UDP que provavelmente estarão fragmentados antes de chegar à rede VPC do Google Cloud, consulte Balanceamento de carga e pacotes UDP fragmentados.

Os balanceadores de carga de rede baseados em pool de destino são compatíveis com os seguintes protocolos para cada regra de encaminhamento: TCP ou UDP. Se você quiser configurar um balanceador de carga de rede para encaminhar todo o tráfego de protocolo IP, use um balanceamento de carga de rede baseado em serviço de back-end.

Várias regras de encaminhamento

É possível configurar várias regras de encaminhamento externas regionais para o mesmo balanceador de carga de rede TCP/UDP externo. Opcionalmente, cada regra de encaminhamento pode ter um endereço IP externo regional diferente ou várias regras de encaminhamento podem ter o mesmo endereço IP externo regional.

A configuração de várias regras de encaminhamento externo regionais pode ser útil nestes casos de uso:

  • Você precisa configurar mais de um endereço IP externo para o mesmo pool de destino.
  • Você precisa configurar intervalos de portas diferentes ou protocolos diferentes usando o mesmo endereço IP externo para o mesmo pool de destino.

Ao usar várias regras de encaminhamento, configure o software em execução nas suas VMs de back-end para que ele seja vinculado a todos os endereços IP necessários. Isso é necessário porque o endereço IP de destino dos pacotes entregues por meio do balanceador de carga é o endereço IP externo regional associado à respectiva regra de encaminhamento externa regional.

Verificações de integridade

As verificações de integridade garantem que o Compute Engine encaminhe novas conexões somente para instâncias que estiverem ativas e prontas para recebê-las. O Compute Engine envia solicitações de verificação de integridade para cada instância na frequência especificada. Quando uma instância excede o número permitido de falhas na verificação de integridade, ela não é mais considerada uma instância qualificada para receber novo tráfego.

Para permitir o desligamento otimizado e o fechamento de conexões TCP, as conexões atuais não são ativamente encerradas. No entanto, não há garantia de que as conexões atuais com um back-end não íntegro permaneçam estáveis por longos períodos. Se possível, inicie um processo de encerramento otimizado assim que possível para o back-end não íntegro.

O verificador de integridade continua consultando as instâncias não íntegras e retorna uma instância ao pool quando ocorre o número especificado de verificações bem-sucedidas. Se todas as instâncias estiverem marcadas como UNHEALTHY, o balanceador de carga direcionará o novo tráfego para todas as instâncias atuais.

O balanceamento de carga da rede depende das verificações de integridade de HTTP legadas para determinar a integridade da instância. Mesmo que seu serviço não use HTTP, execute um servidor da Web básico em cada instância que o sistema de verificação de integridade pode consultar.

As verificações de integridade HTTPS legadas não são compatíveis com balanceadores de carga de rede e não podem ser usadas com a maioria dos outros tipos de balanceadores de carga.

Caminho de retorno

O Google Cloud usa rotas especiais não definidas em sua rede VPC para verificações de integridade. Para mais informações, consulte Caminhos de retorno do balanceador de carga.

Regras de firewall

As verificações de integridade para balanceadores de carga de rede são enviadas desses intervalos de IPs. Será necessário criar regras de firewall de permissão de entrada para autorizar o tráfego desses intervalos.

O balanceamento de carga da rede é um balanceador de carga de passagem, ou seja, as regras de firewall precisam permitir o tráfego dos endereços IP de origem do cliente. Se o serviço estiver aberto para a Internet, será mais fácil permitir o tráfego de todos os intervalos de IPs. Se você quiser restringir o acesso para que apenas alguns endereços IP de origem sejam permitidos, é possível configurar regras de firewall para impor essa restrição, mas é necessário permitir o acesso dos intervalos de IP de verificação de integridade.

Para ver um exemplo de regra de firewall e um exemplo de configuração, consulte Regras para balanceamento de carga de rede.

Arquitetura da VPC compartilhada

A tabela a seguir resume os componentes da VPC compartilhada para o balanceamento de carga de rede:

Endereço IP Regra de encaminhamento Componentes de back-end
Um endereço IP externo regional precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga. Uma regra de encaminhamento externo regional precisa ser definida no mesmo projeto que as instâncias no pool de destino (o projeto de serviço). O pool de destino precisa ser definido no mesmo projeto e na mesma região em que as instâncias no pool de destino existirem. As verificações de integridade associadas ao pool de destino também precisam ser definidas no mesmo projeto.

Distribuição de tráfego

A maneira como um balanceador de carga de rede baseado no pool de destino distribui novas conexões depende de como a afinidade da sessão foi configurada.

Afinidade da sessão

A afinidade de sessão controla o método de hash usado para distribuir novas conexões de clientes para as VMs de back-end do balanceador de carga. Os balanceadores de carga da rede com base no pool de destino usam o parâmetro sessionAffinity para configurar a afinidade da sessão.

Para mais informações, consulte Como usar pools de destino.

Balanceamento de carga e pacotes UDP fragmentados

No balanceamento de carga dos pacotes UDP, é importante lembrar que:

  1. os pacotes não fragmentados são processados normalmente em todas as configurações;
  2. Os pacotes UDP podem se tornar fragmentados antes de entrar em contato com o Google Cloud. As redes intermediárias aguardam a chegada de todos os fragmentos para encaminhá-los, causando demoras ou perdendo fragmentos. O Google Cloud não espera por todos os fragmentos; ele encaminha cada fragmento assim que ele chega.
  3. Como os fragmentos UDP subsequentes não contêm a porta de destino, podem ocorrer problemas nestas situações:

    • Se a afinidade da sessão de pools de destino estiver definida como NONE (afinidade de cinco tuplas), os fragmentos subsequentes poderão ser eliminados porque o balanceador de carga não pode calcular o hash de cinco tuplas.
    • Se houver mais de uma regra de encaminhamento UDP para o mesmo endereço IP com carga balanceada, os fragmentos subsequentes poderão chegar à regra de encaminhamento incorreta.

Se você espera pacotes UDP fragmentados, faça o seguinte:

  • Defina afinidade da sessão como NONE, CLIENT_IP_PROTO ou CLIENT_IP.
    • Definir a afinidade da sessão como NONE indica que a manutenção da afinidade não é necessária. Portanto, o balanceador de carga usa um hash de cinco tuplas para selecionar um back-end para pacotes não fragmentados, mas um hash de três tuplas para pacotes fragmentados.
    • Definir a afinidade da sessão como CLIENT_IP_PROTO ou CLIENT_IP significa que as portas de origem e de destino não são usadas para gerar hash. Portanto, o mesmo hash é calculado para pacotes fragmentados e não fragmentados.
  • Use somente uma regra de encaminhamento UDP por endereço IP com carga balanceada. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento.

Com essas configurações, os fragmentos UDP do mesmo pacote são encaminhados para a mesma instância para serem remontados.

Como usar instâncias de destino como back-ends

Se você estiver usando instâncias de destino como back-ends para o balanceador de carga de rede e espera pacotes UDP fragmentados, use apenas uma regra de encaminhamento UDP por endereço IP com carga balanceada. e configure a regra de encaminhamento para aceitar o tráfego em todas as portas 0-65535. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento, mesmo que não tenham a mesma porta de destino.

A seguir