Visão geral do balanceamento de carga de rede TCP/UDP externo

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 entre as instâncias de máquina virtual (VM, na sigla em inglês) na mesma região em uma rede de nuvem privada virtual (VPC, na sigla em inglês). Um balanceador de carga de rede direciona o tráfego TCP ou UDP por back-ends regionais.

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.

Para mais informações sobre as portas compatíveis, consulte o resumo dos balanceadores de carga do Google Cloud.

O balanceamento de carga da rede tem as seguintes características:

  • O balanceamento de carga da rede é um serviço gerenciado.
  • O balanceamento de carga da rede é implementado usando a rede virtual Andromeda e o Google Maglev.
  • 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 termo do setor para isso é retorno direto do servidor.
  • O balanceador de carga preserva os endereços IP de origem dos pacotes.
  • O endereço IP de destino dos pacotes é 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).

No diagrama a seguir, mostramos usuários na Califórnia, em Nova York e em Singapura. Todos eles estão se conectando aos recursos de back-end, que são myapp, test e travel. Quando um usuário em Singapura conecta-se ao back-end do Oeste dos EUA, o tráfego de entrada está mais próximo de Singapura, porque o intervalo é anycasted. A partir desse ponto, o tráfego é encaminhado para o back-end regional.

Três back-ends regionais e três regras de encaminhamento (clique para ampliar)
Exemplo de balanceamento de carga da rede (clique para ampliar)

Para informações sobre as diferenças entre os balanceadores de carga do Google Cloud, consulte os documentos a seguir:

Protocolos, esquema e escopo

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

Um balanceador de carga de rede equilibra o tráfego proveniente da Internet.

O escopo de um balanceador de carga de rede é regional, e não global. Isso significa que um balanceador de carga de rede não pode abranger várias regiões. Em uma única região, o balanceador de carga atende a todas as zonas.

Casos de uso

Use o balanceamento de carga da rede nas seguintes circunstâncias:

  • Você precisa fazer o balanceamento de carga do tráfego UDP ou de uma porta TCP que não é compatível com outros balanceadores de carga.
  • É aceitável que o tráfego SSL seja descriptografado por seus back-ends, no lugar do balanceador de carga. O balanceador de carga de rede não pode executar essa tarefa. Quando os back-ends descriptografam o tráfego SSL, há uma carga de CPU maior nas VMs.
  • O gerenciamento automático dos certificados SSL do balanceador de carga é aceitável para você. Os certificados SSL gerenciados pelo Google estão disponíveis apenas para balanceamento de carga HTTP(S) e balanceamento de carga de proxy SSL.
  • Você precisa encaminhar os pacotes originais sem proxy.
  • Você tem uma configuração atual que usa um balanceador de carga de passagem e quer migrá-lo sem alterações.

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.

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. 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 pools de destino só podem ser usados com regras de encaminhamento que tratem o 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.

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

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.

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.

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. As conexões atuais não são ativamente encerradas, o que permite que as instâncias sejam encerradas normalmente e fechem as conexões TCP.

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.

Afinidade da sessão

O balanceamento de carga da rede não usa afinidade da sessão de serviços de back-end. Em vez disso, os balanceadores de carga de rede usam pools de destino para afinidade da sessão.

Para mais informações, consulte o parâmetro sessionAffinity em 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 CLIENT_IP_PROTO ou CLIENT_IP. Não use NONE (hash de cinco tuplas). Como CLIENT_IP_PROTO e CLIENT_IP não usam a porta de destino para hash, eles podem calcular o mesmo hash para fragmentos subsequentes e para o primeiro fragmento.
  • 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.

A seguir