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

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

O balanceamento de carga de rede distribui o tráfego entre 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 em back-ends regionais. É possível usar o balanceamento de carga de rede para balancear a carga do tráfego UDP, TCP e SSL em portas que não são compatíveis com balanceadores de carga do proxy TCP e balanceadores de carga proxy SSL.

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 atuam como VMs de back-end nos balanceadores de carga de rede precisam executar o ambiente convidado Linux, o ambiente convidado Windows (em inglês) ou outros processos com funcionalidade equivalente apropriados.

    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 vincular ao 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 se conecta 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 de rede (clique para ampliar)

Para informações sobre como os balanceadores de carga do Google Cloud diferem entre si, 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 usa um pool de destino para conter as instâncias de back-end entre as quais o tráfego é submetido ao balanceamento de carga.

Um balanceador de carga de rede equilibra o tráfego proveniente da Internet. Você não pode usá-lo para o tráfego de balanceamento de carga originado no Google Cloud entre suas instâncias.

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.

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 do 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

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, você associa essa regra de encaminhamento aos seus back-ends. 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 Google 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 Google 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 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 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.

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 Autoescalador 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 Escalonamento baseado na utilização de 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 segmentação correspondente.

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

Várias regras de encaminhamento

É possível configurar várias regras de encaminhamento externo regionais para o mesmo balanceador de carga de rede TCP/UDP externa. 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 porta diferentes ou protocolos diferentes usando o mesmo endereço IP externo para o mesmo pool de segmentação.

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 externo 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.

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 de esses intervalos de IP. 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 IP. 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 Usando pools de segmentação.

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