Um balanceador de carga de rede de passagem externo é um balanceador de carga regional de camada 4. Os balanceadores de carga de rede distribuem o tráfego TCP e UDP entre instâncias de máquina virtual (VM) de back-end na mesma região em uma rede de nuvem privada virtual (VPC). Um balanceador de carga de rede de passagem externa pode receber tráfego de qualquer um dos seguintes:
- Qualquer cliente na Internet
- VMs do Google Cloud com IPs externos
- VMs do Google Cloud que têm acesso à Internet por meio do Cloud NAT ou NAT baseada em instância
Dependendo da configuração da regra de encaminhamento, cada balanceador de carga baseado em pool de destino é compatível com um dos seguintes tipos de tráfego de protocolo:
- TCP
- UDP
- TCP e UDP
O escopo do balanceador de carga é 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.
Os balanceadores de carga de rede de passagem externa são compatíveis com todas as portas. É possível usar um balanceador de carga de rede de passagem externa para balancear a carga do tráfego TCP ou 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 balanceador de carga de rede para encaminhar solicitações para ele, encerrando o TLS nos seus próprios back-ends.
Se você estiver criando aplicativos no GKE, recomendamos usar o controlador de serviços do GKE integrado, que implanta balanceadores de carga do Google Cloud em nome dos usuários do GKE. Isso é o mesmo que a arquitetura de balanceamento de carga independente, exceto pelo fato de o ciclo de vida dela ser totalmente automatizado e controlado pelo GKE. Para ver mais detalhes, consulte Expor apps usando serviços.
Arquitetura
O balanceador de carga é composto de vários componentes de configuração. Um único balanceador de carga pode ter o seguinte:
- Um pool de destino
- Várias regras de encaminhamento
Um balanceador de carga de rede de passagem externa 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 é uma passagem, portanto, seus back-ends recebem a solicitação original do cliente. O balanceador de carga de rede de passagem externa não faz o descarregamento ou o proxy do Transport Layer Security (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 é transmitido a partir dos pontos de presença globais do Google, mas os back-ends 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 destinos 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 as instâncias,
consulte a seção Algoritmo de distribuição de carga.
Os balanceadores de carga de rede de passagem externos 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 de passagem externos precisam executar o ambiente convidado Linux, o ambiente convidado Windows ou outros processos apropriado com capacidade 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).
Os balanceadores de carga de rede são compatíveis com o autoescalador do Compute Engine, que permite que os usuários realizem escalonamento automático nos grupos de instâncias de 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 de passagem externa baseados em pool de destino são compatíveis com os seguintes protocolos para cada regra de encaminhamento: TCP ou UDP. Se você quiser que o balanceador de carga encaminhe todo o tráfego de protocolo IP, use um balanceador de carga de rede baseado em serviço de back-end.
Várias regras de encaminhamento
É possível configurar várias regras de encaminhamento externo regionais para o mesmo balanceador de carga de rede de passagem 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 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.
Os balanceadores de carga de rede de passagem externa dependem de 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.
Regras de firewall
As verificações de integridade para balanceadores de carga de rede de passagem externa são enviadas destes intervalos de IP. Será necessário criar regras de firewall de permissão de entrada para autorizar o tráfego desses intervalos.
Os balanceadores de carga de rede são balanceadores 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 de firewall para balanceadores de carga de rede de passagem externa.
Endereços IP para pacotes de solicitação e retorno
Quando uma VM de back-end recebe um pacote com carga balanceada de um cliente, a origem e o destino do pacote são os seguintes:
- Origem: o endereço IP externo associado a uma VM do Google Cloud ou um endereço IP roteável pela Internet de um sistema que se conecta ao balanceador de carga.
- Destino: o endereço IP da regra de encaminhamento do balanceador de carga.
Como o balanceador de carga é um balanceador de carga de transmissão, e não um proxy, os pacotes chegam carregando o endereço IP de destino da regra de encaminhamento do balanceador de carga. O software em execução nas VMs de back-end precisa ser configurado para fazer o seguinte:
- Detectar (vincular) o endereço IP da regra de encaminhamento do balanceador de carga ou qualquer endereço
IP (
0.0.0.0ou::). - Se o protocolo da regra de encaminhamento do balanceador de carga suportar portas: detectar em (vincular) uma porta incluída na regra de encaminhamento do balanceador de carga
Os pacotes de retorno são enviados diretamente das VMs de back-end do balanceador de carga para o cliente. Os endereços IP de origem e de destino do pacote de retorno dependem do protocolo:
- O TCP é orientado por conexão. Assim, as VMs de back-end respondem com pacotes cujos endereços IP de origem correspondam ao endereço IP da regra de encaminhamento para que o cliente possa associar os pacotes de resposta à conexão TCP apropriada.
- O UDP não tem conexão. Portanto, as VMs de back-end podem enviar pacotes de resposta com endereços IP de origem que correspondam ao endereço IP da regra de encaminhamento ou a qualquer endereço IP atribuído à VM. Na prática, a maioria dos clientes espera que a resposta seja do mesmo endereço IP que enviou os pacotes.
Nesta tabela, há um resumo das origens e dos destinos dos pacotes de resposta:
| Tipo de tráfego | Origem | Destino |
|---|---|---|
| TCP | O endereço IP da regra de encaminhamento do balanceador de carga | A origem do pacote solicitante |
| UDP | Na maioria dos casos de uso, o endereço IP da regra de encaminhamento do balanceador de carga † | A origem do pacote solicitante |
† Quando uma VM tem um endereço IP externo ou quando você está usando o Cloud NAT, também é possível definir o endereço IP de origem do pacote de resposta como o endereço IPv4 interno principal da VM de dados. O Google Cloud ou o Cloud NAT altera o endereço IP de origem do pacote de resposta para o endereço IPv4 externo da placa de rede (NIC, na sigla em inglês) ou o endereço IPv4 externo do Cloud NAT a fim de enviar o pacote de resposta para o endereço IP externo do cliente. Não usar o endereço IP da regra de encaminhamento como uma origem é um cenário avançado, porque o cliente recebe um pacote de resposta de um endereço IP externo que não corresponde ao endereço IP a que ele enviou um pacote de solicitação.
Caminho de retorno
O Google Cloud usa rotas especiais não definidas em sua rede VPC para verificações de integridade. Saiba mais em Caminhos de retorno do balanceador de carga.
Arquitetura da VPC compartilhada
A tabela a seguir resume os componentes da VPC compartilhada para balanceadores de carga de rede de passagem externa:
| 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
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:
- os pacotes não fragmentados são processados normalmente em todas as configurações;
- 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, o que causa atraso ou podem descartar fragmentos. O Google Cloud não espera por todos os fragmentos porque encaminha cada fragmento assim o recebe.
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 a afinidade da sessão de pools de destino estiver definida como
Se você espera pacotes UDP fragmentados, faça o seguinte:
- Defina afinidade da sessão como
NONE,CLIENT_IP_PROTOouCLIENT_IP.- Definir a afinidade da sessão como
NONEindica 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_PROTOouCLIENT_IPsignifica 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.
- Definir a afinidade da sessão como
- 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.
Limitações
- Os balanceadores de carga de rede de passagem externos não dão suporte ao peering de rede VPC.
A seguir
- O Google Cloud Armor é compatível com proteção avançada contra DDoS de rede para balanceadores de carga de rede de passagem externa. Para mais informações, consulte Configurar proteção avançada contra DDoS da rede.
- Para configurar um balanceador de carga de rede de passagem externa e distribuir o tráfego por um conjunto de instâncias do Apache, consulte Configurar um balanceador de carga de rede de passagem externa com pools de destino.
- Para saber como os balanceadores de carga de rede de passagem externa funcionam com serviços de back-end regionais em vez de pools de destino, consulte: