Esta página descreve os seguintes conceitos para ajudar você a entender melhor e personalizar como os balanceadores de carga de rede de passagem externa distribuem tráfego: afinidade da sessão, rastreamento de conexão, balanceamento de carga ponderado, esgotamento de conexão, fragmentação UDP e failover.
A maneira como os balanceadores de carga de rede de passagem externa distribuem novas conexões depende de você ter configurado o failover:
- Se você não tiver configurado o failover, um balanceador de carga de rede de passagem externa distribuirá novas conexões para as VMs de back-end íntegras se pelo menos uma VM de back-end estiver íntegra. Quando todas as VMs de back-end não estiverem íntegras, o balanceador de carga distribuirá novas conexões entre todos os back-ends como um último recurso. Nessa situação, o balanceador de carga roteia cada nova conexão para uma VM de back-end não íntegra.
- Se você tiver configurado o failover, um balanceador de carga de rede distribuirá
novas conexões entre VMs de back-end íntegras, de acordo com uma política de failover
que você configurar. Quando todas as VMs de back-end não estiverem íntegras,
será possível escolher um dos seguintes comportamentos:
- (Padrão) O balanceador de carga distribui o tráfego apenas para as VMs primárias. Isso é feito como último recurso. As VMs de backup são excluídas dessa distribuição de conexões mais recente.
- O balanceador de carga descarta o tráfego.
Para detalhes sobre como as conexões são distribuídas, consulte a próxima seção Seleção de back-end e rastreamento de conexão.
Para detalhes sobre o funcionamento do failover, consulte a seção Failover.
Seleção de back-ends e rastreamento de conexão
Os balanceadores de carga de rede usam seleção configurável de back-end e algoritmos de rastreamento de conexão para determinar como o tráfego é distribuído para as VMs de back-end.
Os balanceadores de carga de rede usam o algoritmo a seguir para distribuir pacotes entre as VMs de back-end (no pool ativo, se você tiver configurado o failover):
- Se o balanceador de carga tiver uma entrada na tabela de rastreamento de conexão correspondente às características de um pacote de entrada, o pacote será enviado ao back-end especificado pela entrada da tabela de rastreamento de conexão. O pacote é considerado como parte de uma conexão estabelecida anteriormente. Portanto, o pacote é enviado à VM de back-end que o balanceador de carga determinou e registrou anteriormente na tabela de rastreamento de conexão.
Quando o balanceador de carga recebe um pacote que não tem uma entrada de rastreamento de conexão, o balanceador de carga faz o seguinte:
O balanceador de carga seleciona um back-end. O balanceador de carga calcula um hash com base na afinidade da sessão configurada. Ele usa esse hash para selecionar um back-end entre aqueles que são íntegros (a menos que todos os back-ends não estejam íntegros, caso em que todos os back-ends são considerados desde que a política de failover não tenha sido configurada para descartar o tráfego nessa situação. A afinidade da sessão padrão,
NONE, usa os seguintes algoritmos de hash:- Para pacotes UDP não fragmentados e TCP, um hash de cinco tuplas do endereço IP de origem do pacote, porta de origem, endereço IP de destino, porta de destino e protocolo
- Para pacotes UDP fragmentados e todos os outros protocolos, um hash de três tuplas do endereço IP de origem do pacote, do endereço IP de destino e do protocolo
A seleção de back-end pode ser personalizada com o uso de um algoritmo de hash que usa menos informações. Para todas as opções compatíveis, consulte opções de afinidade da sessão.
Além disso, observe o seguinte:
Se você ativar o balanceamento de carga ponderado, a seleção de back-end baseada em hash será ponderada com base nos pesos informados por instâncias de back-end. Exemplo:
- Considere um serviço de back-end configurado com a afinidade de sessão definida como
NONEe uma regra de encaminhamento com protocoloUDP. Se houver duas instâncias de back-end íntegras com pesos 1 e 4, os back-ends receberão 20% e 80% dos pacotes UDP, respectivamente. - Considere um serviço de back-end que esteja configurado com afinidade de sessão
de três tuplas e rastreamento de conexão.
A afinidade da sessão é
CLIENT_IP_PROTO, e o modo de acompanhamento de conexão éPER_SESSION. Se houver três instâncias íntegras de back-end com pesos 0, 2 e 6, os back-ends receberão tráfego para 0%, 25% e 75% dos novos endereços IP de origem (os endereços IP de origem para os quais não houver entradas de tabela de rastreamento de conexão) respectivamente. O tráfego para conexões atuais vai para os back-ends atribuídos anteriormente. .
O balanceador de carga adiciona uma entrada à tabela de rastreamento de conexão. Essa entrada registra o back-end selecionado para a conexão do pacote, de modo que todos os pacotes futuros dessa conexão sejam enviados para o mesmo back-end. O uso do rastreamento de conexão depende do protocolo:
Pacotes TCP. O rastreamento de conexão está sempre ativado e não pode ser desativado. Por padrão, o rastreamento de conexão é de cinco tuplas, mas pode ser configurado para ser menor que cinco tuplas. Quando é de cinco tuplas, os pacotes TCP SYN são tratados de maneira diferente. Ao contrário dos pacotes não SYN, eles descartam qualquer entrada de rastreamento de conexão correspondente e sempre selecionam um novo back-end.
O rastreamento de conexão padrão de cinco tuplas é usado quando:- o modo de acompanhamento é
PER_CONNECTION(todas as afinidades da sessão), ou, - o modo de acompanhamento é
PER_SESSIONe a afinidade da sessão éNONE, ou, - o modo de acompanhamento é
PER_SESSIONe a afinidade da sessão éCLIENT_IP_PORT_PROTO.
- o modo de acompanhamento é
Pacotes UDP, ESP e GRE. O rastreamento de conexão é ativado somente se a afinidade da sessão estiver definida como algo diferente de
NONE.Pacotes ICMP e ICMPv6. Não é possível usar o rastreamento de conexão.
Para mais detalhes sobre quando o acompanhamento de conexão é ativado e qual método de acompanhamento é usado, consulte Modo de rastreamento de conexão.
Além disso, observe o seguinte:
- Uma entrada na tabela de rastreamento de conexão expira 60 segundos após o balanceador de carga processar o último pacote que corresponde à entrada. Para mais informações, consulte Tempo limite de inatividade.
- Dependendo do protocolo, o balanceador de carga pode remover entradas da tabela de rastreamento de conexão quando os back-ends não estiverem íntegros. Para detalhes e como personalizar esse comportamento, consulte Persistência de conexão em back-ends não íntegros.
Opções de afinidade de sessão
A afinidade de sessão controla a distribuição de novas conexões de clientes para as VMs de back-end do balanceador de carga. A afinidade da sessão é especificada para todo o serviço de back-end externo regional, não para cada back-end.
Os balanceadores de carga de rede de passagem externa são compatíveis com as seguintes opções de afinidade de sessão:
- Nenhum (
NONE). Hash de cinco tuplas do endereço IP de origem, porta de origem, protocolo, endereço IP de destino e porta de destino - IP do cliente, IP de destino (
CLIENT_IP). Hash de duas tuplas de endereço IP de origem e endereço IP de destino - IP do cliente, IP de destino, protocolo (
CLIENT_IP_PROTO). Hash de três tuplas do endereço IP de origem, do endereço IP de destino e do protocolo - IP do cliente, Porta do cliente, IP de destino, Porta de destino, Protocolo
(
CLIENT_IP_PORT_PROTO). Hash de cinco tuplas do endereço IP de origem, porta de origem, protocolo, endereço IP de destino e a porta de destino
Para saber como essas opções de afinidade de sessão afetam os métodos de rastreamento de conexão e seleção de back-end, consulte esta tabela.
Política de rastreamento da conexão
Esta seção descreve as configurações que controlam o comportamento de rastreamento de conexão de balanceadores de carga de rede de passagem externa. Uma política de rastreamento de conexão inclui as seguintes configurações:
Modo de rastreamento de conexão
A ativação do rastreamento de conexão depende apenas do protocolo do
tráfego com carga balanceada e das configurações de afinidade da sessão. O modo de rastreamento especifica
o algoritmo de rastreamento de conexão a ser usado quando o rastreamento de conexão está
ativado. Há dois modos de acompanhamento: PER_CONNECTION (padrão) e
PER_SESSION.
PER_CONNECTION(padrão). Esse é o modo de acompanhamento padrão. Com esse modo de rastreamento de conexão, o tráfego TCP é sempre rastreado por cinco tuplas, independentemente da configuração de afinidade da sessão. Para o tráfego UDP, ESP e GRE, o acompanhamento de conexão é ativado quando a afinidade de sessão selecionada não éNONE. Os pacotes UDP, ESP e GRE são rastreados usando os métodos de rastreamento descritos nesta tabela.PER_SESSION. Se a afinidade da sessão forCLIENT_IPouCLIENT_IP_PROTO, a configuração desse modo resultará em rastreamento de conexão de duas e três tuplas, respectivamente, para todos os protocolos, exceto ICMP que não é rastreável por conexão. Para outras configurações de afinidade da sessão, o modoPER_SESSIONse comporta de maneira idêntica ao modoPER_CONNECTION.
Para saber como esses modos de rastreamento funcionam com diferentes configurações de afinidade de sessão para cada protocolo, consulte a tabela a seguir.
| Seleção de back-end | Modo de rastreamento de conexão | ||
|---|---|---|---|
| Configuração de afinidade da sessão | Método de hash para seleção de back-end | PER_CONNECTION (padrão) |
PER_SESSION |
| Padrão: sem afinidade da sessão
( |
TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas |
|
|
| IP do cliente, IP de destino
( |
Todos os protocolos: hash de duas tuplas |
|
|
| IP do cliente, IP de destino, protocolo
( |
Todos os protocolos: hash de três tuplas |
|
|
| IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo
( |
TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas |
|
|
Para saber como alterar o modo de rastreamento de conexão, consulte Configurar uma política de rastreamento de conexão.
Persistência de conexão em back-ends não íntegros
As configurações de persistência de conexão controlam se uma conexão permanece em um endpoint ou VM de back-end selecionado depois que o back-end se torna não íntegro, desde que o back-end permaneça no grupo de back-end configurado do balanceador de carga (em um grupo de instâncias ou um NEG).
O comportamento descrito nesta seção não se aplica aos casos em que você remove uma instância de back-end de um grupo de instâncias, remove um endpoint de back-end do NEG ou remove o grupo de instâncias ou o NEG do serviço de back-end. Nesses casos, as conexões estabelecidas persistem apenas conforme descrito na diminuição de conexão.
As seguintes opções de persistência de conexão estão disponíveis:
DEFAULT_FOR_PROTOCOL(padrão)NEVER_PERSISTALWAYS_PERSIST
A tabela a seguir resume as opções de persistência de conexão e como as conexões persistem para diferentes protocolos, opções de afinidade da sessão e modos de rastreamento.
| Persistência de conexão em back-ends não íntegros | Modo de rastreamento de conexão | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão) Todos os outros protocolos: as conexões nunca permanecem em back-ends não íntegros |
TCP: conexões persistem em back-ends não íntegros se
a afinidade da sessão é Todos os outros protocolos: as conexões nunca persistem em back-ends não íntegros. |
NEVER_PERSIST |
Todos os protocolos: as conexões nunca permanecem em back-ends não íntegros | |
ALWAYS_PERSIST |
TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão) ESP, GRE, UDP: as conexões permanecem em back-ends não íntegros
se a afinidade da sessão não for ICMP, ICMPv6:não aplicável porque não é possível acompanhar a conexão. Essa opção só deve ser usada para casos de uso avançados. |
Não é possível configurar |
Comportamento de persistência de conexão TCP em back-ends não íntegros
Sempre que uma conexão TCP com rastreamento de cinco tuplas persiste em um back-end não íntegro:
- Se o back-end não íntegro continuar a responder aos pacotes, a conexão continuará até que seja redefinida ou fechada (pelo back-end não íntegro ou pelo cliente).
- Se o back-end não íntegro enviar um pacote de redefinição de TCP (RST) ou não responder aos pacotes, o cliente poderá tentar novamente com uma nova conexão, permitindo que o balanceador de carga selecione um back-end íntegro e diferente. Os pacotes TCP SYN sempre selecionam um back-end novo e íntegro.
Para saber como alterar o comportamento de persistência de conexão, consulte Configurar uma política de rastreamento de conexão.
Tempo limite de inatividade
As entradas nas tabelas de rastreamento de conexão expiram 60 segundos após o balanceador de carga processar o último pacote que corresponde à entrada. Esse valor de tempo limite de inatividade não pode ser modificado.
Balanceamento de carga ponderado
É possível configurar um balanceador de carga de rede para distribuir o tráfego entre as instâncias de back-end do balanceador com base nos pesos informados por uma verificação de integridade HTTP usando o balanceamento de carga ponderado.
O balanceamento de carga ponderado requer que você configure estes dois itens:
- Defina a política do balanceador de carga de localidade (
localityLbPolicy) do serviço de back-end comoWEIGHTED_MAGLEV. - Configure o serviço de back-end com uma verificação de integridade HTTP. As respostas
da verificação de integridade HTTP precisam conter um campo de cabeçalho de resposta HTTP personalizado
X-Load-Balancing-Endpoint-Weightpara especificar os pesos com valores de0a1000para cada instância de back-end.
Se você usa o mesmo back-end (grupo de instâncias ou NEG) para vários balanceadores de carga de rede
de passagem externa baseados em serviço de back-end que usam balanceamento de carga ponderado, recomendamos
usar um request-path exclusivo para cada verificação de integridade do serviço de back-end. Isso permite
que a instância de endpoint atribua diferentes pesos a diferentes
serviços de back-end. Para mais informações, consulte Critérios de sucesso para verificações de integridade HTTP, HTTPS e HTTP/2.
Para selecionar um back-end para uma nova conexão, os back-ends recebem uma ordem de prioridade estrita com base no peso e no status de integridade, conforme mostrado na tabela a seguir:
| Peso | Íntegro | Prioridade de seleção de back-end |
|---|---|---|
| Peso maior que zero | Sim | 4 |
| Peso maior que zero | Não | 3 |
| Peso igual a zero | Sim | 2 |
| Peso igual a zero | Não | 1 |
Apenas os back-ends de maior prioridade estão qualificados para seleção de back-end. Se todos os back-ends qualificados tiverem peso zero, o balanceador de carga distribuirá novas conexões entre todos os back-ends qualificados, tratando-os com o mesmo peso. Para ver exemplos de balanceamento de carga ponderado, consulte Seleção de back-end e rastreamento de conexão.
O balanceamento de carga ponderado pode ser usado nos seguintes cenários:
Se algumas conexões processarem mais dados do que outras ou se algumas conexões ficarem mais tempo do que outras, a distribuição da carga do back-end pode ficar desigual. Ao sinalizar um peso por instância mais baixo, uma instância com alta carga pode reduzir a participação de novas conexões, enquanto continua atendendo as conexões atuais.
Se um back-end estiver sobrecarregado e a atribuição de mais conexões puder interromper as conexões existentes, eles não atribuirão peso zero a si mesmo. Ao sinalizar o peso zero, uma instância de back-end deixa de fornecer novas conexões, mas continua a atender as atuais.
Se um back-end estiver drenando conexões existentes antes da manutenção, ele atribuirá zero peso a si mesmo. Ao sinalizar o peso zero, a instância de back-end deixa de atender novas conexões, mas continua a atender as atuais.
Para mais informações, consulte Configurar o balanceamento de carga ponderado.
Diminuição da conexão
A diminuição da conexão é um processo aplicado a conexões estabelecidas nos seguintes casos:
- Uma VM ou um endpoint é removido de um back-end (grupo de instâncias ou NEG).
- Um back-end remove uma VM ou um endpoint (por substituição, abandono, ao fazer upgrades ou reduzir em escala vertical).
- Um back-end é removido de um serviço de back-end.
Por padrão, a diminuição de conexão está desativada. Quando desativadas, as conexões estabelecidas são encerradas o mais rápido possível. Quando a diminuição da conexão estiver ativada, as conexões estabelecidas poderão persistir por um tempo limite configurável, após o qual a instância da VM de back-end será encerrada.
Para mais detalhes sobre como a diminuição da conexão é acionada e como ativá-la, consulte Como ativar a diminuição da conexão.
Fragmentação UDP
Os balanceadores de carga de rede de passagem externa baseados em serviço de back-end podem processar pacotes UDP fragmentados e não fragmentados. Se o aplicativo usar pacotes UDP fragmentados, lembre-se do seguinte:
- Os pacotes UDP podem se tornar fragmentados antes de chegar a uma rede VPC do Google Cloud.
- Google Cloud As redes VPC encaminham fragmentos UDP à medida que chegam, sem esperar que todos os fragmentos cheguem.
- As redes que não são doGoogle Cloud e os equipamentos de rede locais podem encaminhar fragmentos UDP assim que chegarem, atrasar pacotes UDP fragmentados até que todos os fragmentos tenham chegado ou descartar pacotes UDP fragmentados. Para ver mais detalhes, consulte a documentação da operadora ou equipamento de rede.
Se você espera pacotes UDP fragmentados e precisa encaminhá-los para os mesmos back-ends, use as seguintes regras de encaminhamento e parâmetros de configuração do serviço de back-end:
Configuração da regra de encaminhamento: use apenas uma regra de encaminhamento
UDPouL3_DEFAULTpor endereço IP com balanceamento de carga e configure a regra de encaminhamento para aceitar o tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento. Mesmo que os pacotes fragmentados (exceto o primeiro fragmento) não tenham uma porta de destino, a configuração da regra de encaminhamento para processar o tráfego para todas as portas também a configura para receber fragmentos UDP que não têm informações de porta. Para configurar todas as portas, use a Google Cloud CLI para definir--ports=ALLou use a API para definirallPortscomoTrueConfiguração do serviço de back-end: defina a afinidade da sessão do serviço de back-end como
CLIENT_IP(hash de duas tuplas) ouCLIENT_IP_PROTO(três tuplas) hash) para que o mesmo back-end seja selecionado para pacotes UDP que incluem informações de porta e fragmentos UDP (que não sejam o primeiro fragmento) sem informações de porta. Defina o modo de rastreamento de conexão do serviço de back-end comoPER_SESSIONpara que as entradas da tabela de rastreamento de conexão sejam criadas usando os mesmos hashes de duas ou três tuplas.
Failover
É possível configurar um balanceador de carga de rede de passagem externa para distribuir conexões entre instâncias de VM ou endpoints em back-ends primários (grupos de instâncias ou NEGs) e, em seguida, alternar, se necessário, para usar back-ends de failover. Com o failover, você garante um método para aumentar a disponibilidade e ter maior controle sobre como gerenciar a carga de trabalho quando os back-end principais não estiverem íntegras.
Por padrão, quando você adiciona um back-end a um serviço de back-end do balanceador de carga de rede externo, esse back-end é primário. Para designá-lo como back-end de failover, faça isso quando adicioná-lo ao serviço de back-end do balanceador de carga ou edite esse serviço posteriormente.
Para mais detalhes sobre como o failover funciona, consulte Visão geral do failover para balanceadores de carga de rede de passagem externa.
A seguir
- Para configurar um balanceador de carga de rede de passagem externa com um serviço de back-end somente para tráfego TCP ou UDP (compatível com tráfego IPv4 e IPv6), consulte Configurar um balanceador de carga de rede de passagem externa com um serviço de back-end.
- Para configurar um balanceador de carga de rede de passagem externa para vários protocolos IP (compatível com tráfego IPv4 e IPv6), consulte Configurar um balanceador de carga de rede de passagem externa para vários protocolos IP.
- Para configurar um balanceador de carga de rede de passagem externa com um back-end de NEG zonal, consulte Configurar um balanceador de carga de rede de passagem externa com NEGs zonais.
- Para saber como fazer a transição de um balanceador de carga de rede de passagem externa de um back-end de pool de destino para um serviço de back-end regional, consulteComo fazer a transição de um balanceador de carga de rede de passagem externa de um pool de destino para um serviço de back-end.