Distribuição de tráfego para balanceadores de carga de rede de passagem externa

Nesta página, explicamos conceitos sobre como os balanceadores de carga de rede de passagem externa distribuem o tráfego.

Seleção de back-ends e rastreamento de conexão

A seleção de back-end e o rastreamento de conexão trabalham juntos para balancear várias conexões em diferentes back-ends e rotear todos os pacotes de cada conexão para o mesmo back-end. Isso é feito com uma estratégia em duas partes. Primeiro, um back-end é selecionado usando hashing consistente. Em seguida, essa seleção é registrada em uma tabela de rastreamento de conexão.

As etapas a seguir descrevem a seleção de back-end e o rastreamento de conexão.

1. Verificar uma entrada da tabela de rastreamento de conexão

O balanceador de carga determina se um pacote balanceado pertence a uma nova conexão ou a uma conexão existente usando o seguinte processo:

Pacote TCP com a flag SYN:
- Se o modo de rastreamento de conexão do balanceador de carga for PER_CONNECTION, continue para a etapa Identificar back-ends qualificados. No modo de rastreamento PER_CONNECTION, um pacote TCP com a flag SYN sempre representa uma nova conexão, independente da afinidade da sessão configurada.
- Se o modo de rastreamento de conexão do balanceador de carga for PER_SESSION e a afinidade da sessão for NONE ou CLIENT_IP_PORT_PROTO, continue para a etapa Identificar back-ends qualificados. No modo de rastreamento PER_SESSION, um pacote TCP com a flag SYN representa uma nova conexão somente ao usar uma das opções de afinidade de sessão de cinco tuplas (NONE ou CLIENT_IP_PORT_PROTO).

Rastreamento de conexão não compatível: se a afinidade da sessão configurada não for compatível com o rastreamento de conexão para o protocolo do pacote, continue para a etapa Identificar back-ends qualificados. Para saber quais protocolos podem ser rastreados, consulte a tabela na seção Modo de rastreamento de conexão.

Todos os outros pacotes: o balanceador de carga verifica se o pacote corresponde a uma entrada da tabela de rastreamento de conexão existente. A granularidade do hash de pacote usado para verificar uma entrada da tabela de rastreamento de conexão depende do modo de rastreamento de conexão e dafinidade da sessãoão configurados. Para mais informações, consulte a tabela na seção Modo de rastreamento de conexão.
- Se o pacote corresponder a uma entrada da tabela de rastreamento de conexão, o balanceador de carga enviará o pacote ao back-end selecionado anteriormente.
- Se o pacote não corresponder a uma entrada da tabela de rastreamento de conexão, continue para a etapa Identificar back-ends qualificados.
Para saber por quanto tempo e em quais condições uma entrada da tabela de rastreamento de conexão persiste, consulte a etapa Gerenciar entradas da tabela de rastreamento de conexão.

2. Etapas de seleção de back-end

Para uma nova conexão, o balanceador de carga usa hash consistente para selecionar um back-end entre os back-ends qualificados.

As etapas a seguir descrevem o processo para selecionar um back-end qualificado para uma nova conexão e registrar essa conexão em uma tabela de rastreamento de conexões.

2.1 Identificar back-ends qualificados

Os back-ends qualificados são aqueles que podem receber novas conexões. A tabela a seguir define o conjunto de back-ends qualificados, dependendo se você configurou uma política de failover e se o balanceamento de carga ponderado está ativado.

Política de failover	Balanceamento de carga ponderado	Back-ends qualificados
		Quando nenhuma política de failover é configurada e o balanceamento de carga ponderado está desativado, todos os back-ends configurados são principais. O conjunto de back-ends qualificados é definido da seguinte maneira: Quando pelo menos um back-end está íntegro, o conjunto de back-ends qualificados consiste em todos os back-ends íntegros. Quando nenhum back-end está íntegro, o conjunto de back-ends qualificados consiste em todos os back-ends.
		Quando nenhuma política de failover é configurada e o balanceamento de carga ponderado está ativado, os back-ends qualificados são aqueles que vêm do primeiro dos seguintes conjuntos que não está vazio: Todos os back-ends íntegros com peso diferente de zero Todos os back-ends não íntegros com peso diferente de zero Todos os back-ends íntegros com peso zero Todos os back-ends não íntegros com peso zero
		Quando uma política de failover é configurada e o balanceamento de carga ponderado é desativado, o balanceador de carga usa informações de verificação de integridade e configuração de política de failover para definir o conjunto de back-ends qualificados: Quando pelo menos um back-end (primário ou de failover) está íntegro, os back-ends qualificados são aqueles que vêm do primeiro dos seguintes conjuntos que não está vazio: Se não houver back-ends principais íntegros, os back-ends qualificados serão todos os back-ends de failover íntegros. Se não houver back-ends de failover íntegros, os back-ends qualificados serão todos os back-ends primários íntegros. Se a proporção de failover for definida como `0.0` (o valor padrão), os back-ends qualificados serão todos os back-ends principais íntegros. Se a proporção do número de back-ends principais íntegros em comparação com o número total de back-ends principais for maior ou igual à proporção de failover configurada, os back-ends qualificados consistirão em todos os back-ends principais íntegros. Os back-ends qualificados consistem em todos os back-ends de failover íntegros. Quando não há back-ends íntegros (principal e de failover), o conjunto de back-ends qualificados depende exclusivamente da configuração da política de failover: Se a política de failover estiver configurada para descartar novas conexões quando todos os back-ends primários e de failover não estiverem íntegros, o conjunto de back-ends qualificados ficará vazio. Como consequência, o balanceador de carga descarta pacotes de novas conexões. Se a política de failover não estiver configurada para descartar novas conexões quando todos os back-ends primários e de failover estiverem não íntegros, os back-ends qualificados serão todos os back-ends primários não íntegros.
		Quando uma política de failover é configurada e o balanceamento de carga ponderado é ativado, o balanceador usa informações de peso e de verificação de integridade, além da configuração da política de failover, para definir o conjunto de back-ends qualificados: Quando pelo menos um back-end com peso diferente de zero (primário ou de failover) está íntegro, os back-ends qualificados são aqueles que vêm do primeiro dos seguintes conjuntos que não está vazio: Se o conjunto de back-ends principais íntegros com peso diferente de zero estiver vazio, os back-ends qualificados serão todos os back-ends de failover íntegros com peso diferente de zero. Se o conjunto de back-ends de failover íntegros com peso diferente de zero estiver vazio, os back-ends qualificados serão todos os back-ends principais íntegros com peso diferente de zero. Se a proporção de failover for definida como `0.0` (o valor padrão), os back-ends qualificados serão todos os back-ends principais íntegros com peso diferente de zero. Se a proporção do número de back-ends principais íntegros com peso diferente de zero em comparação com o número total de back-ends principais for maior ou igual à proporção de failover configurada, os back-ends qualificados consistirão em todos os back-ends principais íntegros com peso diferente de zero. Os back-ends qualificados consistem em todos os back-ends de failover íntegros com peso diferente de zero. Quando não há back-ends íntegros com peso diferente de zero (principal e de failover), o conjunto de back-ends qualificados depende da configuração da política de failover: Se a política de failover estiver configurada para descartar novas conexões quando não houver back-ends primários e de failover íntegros e com peso diferente de zero, o conjunto de back-ends qualificados ficará vazio. Como consequência, o balanceador de carga descarta pacotes de novas conexões. Se a política de failover não estiver configurada para descartar novas conexões quando não houver back-ends primários e de failover íntegros e com peso diferente de zero, os back-ends qualificados serão aqueles que vierem do primeiro dos seguintes conjuntos que não estiver vazio: Todos os back-ends principais não íntegros com peso diferente de zero Todos os back-ends de failover não íntegros com peso diferente de zero Todos os back-ends primários íntegros com peso zero Todos os back-ends de failover íntegros com peso zero Todos os back-ends principais não íntegros com peso zero Todos os back-ends de failover não íntegros com peso zero

2.2 Selecione um back-end qualificado

O balanceador de carga mantém hashes de back-ends qualificados, com cada hash de back-end mapeado para um círculo unitário. O balanceamento de carga ponderado altera a forma como os back-ends qualificados são mapeados para o círculo, de modo que os back-ends com pesos maiores têm mais chances de serem selecionados, proporcionalmente aos respectivos pesos.

Ao processar um pacote para uma conexão que não está na tabela de rastreamento de conexão, o balanceador de carga calcula um hash das características do pacote e o mapeia para o mesmo círculo unitário, selecionando um back-end qualificado na circunferência do círculo. O conjunto de características de pacote usado para calcular o hash do pacote é definido pela configuração de afinidade de sessão. Por exemplo, quando a afinidade da sessão selecionada resulta em um hash de seleção de back-end de duas ou três tuplas, todas as conexões TCP de um endereço IP de origem são mapeadas para o mesmo back-end qualificado.

Se uma afinidade da sessão não for configurada explicitamente, a afinidade de sessão NONE será a padrão.

O hash consistente garante que o balanceador de carga atribua novas conexões a back-ends qualificados de maneira a minimizar interrupções de mapeamento, mesmo que o número de back-ends qualificados ou seus pesos mudem.
- O balanceador de carga sempre seleciona o mesmo back-end qualificado para uma conexão e, de maneira mais geral, sempre seleciona o mesmo back-end qualificado para todos os pacotes com características idênticas, conforme definido pela configuração de afinidade de sessão, nas seguintes situações:
  - Se o balanceamento de carga ponderado não estiver configurado, quando o conjunto de back-ends qualificados não mudar.
  - Se o balanceamento de carga ponderado estiver configurado, quando o conjunto de back-ends qualificados não mudar e o peso de cada back-end qualificado permanecer constante.
- Se um back-end qualificado for adicionado, removido ou tiver o peso alterado, hashing consistente vai minimizar a interrupção dos mapeamentos para os outros back-ends qualificados. Ou seja, a maioria das conexões que são mapeadas para outros back-ends qualificados continuará sendo mapeada para o mesmo back-end qualificado.
Além disso, o hashing consistente garante que o balanceador de carga distribua novas conexões entre os back-ends qualificados da maneira mais justa possível. Para todos os hashes de pacote possíveis, conforme definido pela configuração de afinidade da sessão (e, mais especificamente, para todas as conexões possíveis quando a afinidade da sessão resulta em um hash de cinco tuplas para seleção de back-end):
- Se o balanceamento de carga ponderado não estiver configurado, aproximadamente 1/N hashes de pacote possíveis serão mapeados para cada back-end qualificado, em que N é a contagem de back-ends qualificados.
- Se o balanceamento de carga ponderado estiver configurado, a proporção de hashes de pacotes possíveis que mapeiam para cada back-end qualificado será aproximadamente: o peso de um back-end qualificado dividido pela soma de todos os pesos de back-end qualificados.
Os dois exemplos a seguir mostram como o balanceamento de carga ponderado afeta as probabilidades de seleção de cada back-end qualificado:
- Se o serviço de back-end tiver dois back-ends qualificados, o primeiro com peso 1 e o segundo com peso 4, o primeiro back-end qualificado terá uma probabilidade de seleção de 20% (1&div;(1+4)), e o segundo terá uma probabilidade de seleção de 80% (4&div;(1+4)).
- Se o serviço de back-end tiver três back-ends qualificados (back-end a com peso 0, back-end b com peso 2 e back-end c com peso 6), o back-end a terá uma probabilidade de seleção de 0% (0&div;(0+2+6)), o back-end b terá uma probabilidade de seleção de 25% (2&div;(0+2+6)) e o back-end c terá uma probabilidade de seleção de 75% (6&div;(0+2+6)).

2.3 Criar uma entrada de tabela de rastreamento de conexão

Depois de selecionar um back-end, o balanceador de carga cria uma entrada de tabela de rastreamento de conexão se a afinidade da sessão configurada for compatível com o rastreamento de conexão para o protocolo do pacote.

Se a afinidade da sessão configurada não for compatível com o rastreamento de conexão para o protocolo do pacote, pule esta etapa.
Se a afinidade da sessão configurada for compatível com o rastreamento de conexão para o protocolo do pacote, a entrada da tabela de rastreamento de conexão criada mapeará as características do pacote para o back-end selecionado. Os campos de cabeçalho do pacote usados para esse mapeamento dependem do modo de rastreamento de conexão e da afinidade da sessão configurados.

Para informações sobre quais protocolos podem ser rastreados com base nas suas escolhas de configuração e quais características de pacote são usadas para o hash na tabela de rastreamento de conexão, consulte a tabela na seção Modo de rastreamento de conexão.

3. Gerenciar entradas da tabela de rastreamento de conexão

O balanceador de carga gerencia as entradas da tabela de rastreamento de conexão de acordo com os seguintes eventos e regras:

As entradas ociosas são removidas: uma entrada da tabela de rastreamento de conexão é removida depois que a conexão fica ociosa por 60 segundos. Para mais informações, consulte Tempo limite de inatividade.

Conexões TCP fechadas: as entradas da tabela de rastreamento de conexões para conexões TCP não são removidas quando uma conexão TCP é fechada com um pacote FIN ou RST. Elas podem ser removidas mais tarde como uma entrada inativa. Cada nova conexão TCP sempre carrega a flag SYN e está sujeita ao processamento descrito na etapa Verificar uma entrada da tabela de rastreamento de conexão.
Diminuição da conexão em failover: quando pelo menos um back-end de failover é configurado e a configuração de diminuição da conexão em failover está desativada, o balanceador de carga remove todas as entradas na tabela de rastreamento de conexão quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover. Para mais informações, consulte Diminuição da conexão na failover.
Persistência de conexão em back-ends não íntegros: as entradas na tabela de rastreamento de conexão podem ser removidas se um back-end ficar não íntegro. Esse comportamento depende de fatores descritos em Persistência de conexão em back-ends não íntegros.
- Quando uma entrada da tabela de rastreamento de conexão é removida porque um back-end selecionado anteriormente muda de íntegro para não íntegro, os pacotes subsequentes da conexão são tratados como se pertencessem a uma nova conexão. Depois de selecionar um novo back-end qualificado para os pacotes subsequentes, o balanceador de carga cria uma entrada de tabela de rastreamento de conexão substituta.
- Uma entrada de tabela de rastreamento de conexão substituta se comporta exatamente como qualquer outra entrada de tabela de rastreamento de conexão e está sujeita aos eventos e regras desta etapa.
- Se o back-end selecionado anteriormente voltar a ficar íntegro, a mudança na verificação de integridade não fará com que a entrada da tabela de rastreamento de conexão de substituição seja removida. Uma exceção ocorre quando pelo menos um back-end de failover é configurado e a configuração de diminuição da conexão em failover está desativada. Se a mudança no estado de verificação de integridade de um back-end selecionado anteriormente coincidir com o conjunto de back-ends qualificados alternando entre back-ends primários e de failover, as entradas da tabela de rastreamento de conexão serão removidas.
Diminuição da conexão para back-ends removidos, interrompidos ou excluídos: se a diminuição da conexão para back-ends removidos, interrompidos ou excluídos estiver ativada, as entradas da tabela de rastreamento de conexão serão removidas após um tempo limite configurável de diminuição da conexão. A contagem para o tempo limite começa quando o comando para remover, parar ou excluir um back-end é recebido. Se a diminuição da conexão para back-ends removidos, interrompidos ou excluídos estiver desativada, as entradas da tabela de rastreamento de conexão serão removidas quando o comando para remover, interromper ou excluir um back-end for recebido. Para mais informações, consulte Ativar a diminuição da conexão.

afinidade da sessão

A configuração de afinidade da sessão de um balanceador de carga de rede de passagem externa define o hash de pacote para seleção de back-end e, com base no modo de rastreamento de conexão, o hash de pacote para rastreamento de conexão.

Afinidade da sessão é configurada no serviço de back-end, não em cada grupo de instâncias ou NEG de back-end. A afinidade da sessão determina quais cabeçalhos IP e da Camada 4 são usados para calcular um hash das características do pacote. O hash das características do pacote é usado nas etapas de seleção de back-end.

Os balanceadores de carga de rede de passagem externa são compatíveis com as seguintes configurações afinidade da sessão.

Método de hash para seleção de back-end Configuração de afinidade da sessão

Método de hash para seleção de back-end	Configuração de afinidade da sessão
Hash de cinco tuplas (consiste em endereço IP de origem, porta de origem, protocolo, endereço IP de destino e porta de destino) para pacotes não fragmentados que incluem informações de porta (pacotes TCP e UDP não fragmentados) OU Hash de três tuplas (consiste em endereço IP de origem, endereço IP de destino e protocolo) para pacotes UDP fragmentados e pacotes de todos os outros protocolos	`NONE`¹ OU `CLIENT_IP_PORT_PROTO`
Hash de três tuplas (consiste em endereço IP de origem, endereço IP de destino e protocolo)	`CLIENT_IP_PROTO`
Hash de duas tuplas (consiste em endereço IP de origem e endereço IP de destino)	`CLIENT_IP`

Hash de cinco tuplas (consiste em endereço IP de origem, porta de origem, protocolo, endereço IP de destino e porta de destino) para pacotes não fragmentados que incluem informações de porta (pacotes TCP e UDP não fragmentados)

Hash de três tuplas (consiste em endereço IP de origem, endereço IP de destino e protocolo) para pacotes UDP fragmentados e pacotes de todos os outros protocolos

NONE¹
OU
CLIENT_IP_PORT_PROTO

Hash de três tuplas
(consiste em endereço IP de origem, endereço IP de destino e protocolo) CLIENT_IP_PROTO

Hash de duas tuplas
(consiste em endereço IP de origem e endereço IP de destino) CLIENT_IP

¹ A afinidade da sessão NONE não indica que não há afinidade da sessão. Em vez disso, significa que a afinidade da sessão é feita com um hash de cinco tuplas ou um hash de três tuplas de características de pacote, funcionalmente o mesmo comportamento de quando CLIENT_IP_PORT_PROTO está definido.

Política de rastreamento da conexão

Esta seção descreve as configurações na política de rastreamento de conexão do balanceador de carga:

Modo de rastreamento de conexão
Persistência de conexão em back-ends não íntegros
Tempo limite de inatividade

Modo de rastreamento de conexão

Nesta seção, descrevemos quando e como o balanceador de carga cria entradas na tabela de rastreamento de conexão. Os balanceadores de carga de rede de passagem externa são compatíveis com o rastreamento de conexão com base no protocolo e na afinidade da sessão:

As conexões TCP são sempre rastreáveis, para todas as opções de afinidade da sessão.
As conexões UDP, ESP e GRE podem ser rastreadas para todas as opções de afinidade de sessão, exceto NONE.
Todos os outros protocolos, como ICMP e ICMPv6, não podem ser rastreados por conexão.

Quando o rastreamento de conexão é possível, o modo, o protocolo e a afinidade da sessão determinam o conjunto de características de pacote usadas para criar o hash de pacote em cada entrada da tabela de rastreamento de conexão.

O modo de rastreamento de conexão pode ser um dos seguintes:

PER_CONNECTION. Esse é o modo de acompanhamento de conexão padrão e mais granular. Cada conexão é definida como um hash de cinco tuplas ou um hash de três tuplas de características do pacote, dependendo se as informações da porta estão presentes no pacote. Pacotes não fragmentados que incluem informações de porta (como pacotes TCP e UDP não fragmentados) são rastreados com hashes de cinco tuplas. Todos os outros pacotes são rastreados com hashes de tupla tripla.
PER_SESSION. Esse modo de rastreamento de conexão menos granular usa um hash que corresponde ao hash de afinidade da sessão. Dependendo da afinidade de sessão escolhida, o modo de rastreamento PER_SESSION pode tratar várias conexões distintas como uma única conexão para fins de rastreamento. Isso reduz a frequência com que uma conexão é considerada nova e sujeita às etapas de seleção de back-end.

A tabela a seguir resume:

Os hashes de pacote usados para seleção de back-end; e
Os hashes de pacote usados para o rastreamento de conexão, com base no modo de rastreamento de conexão, no protocolo e na afinidade da sessão.

afinidade da sessão	Hash de pacote para seleção de back-end	Hash de pacote para rastreamento de conexão
afinidade da sessão	Hash de pacote para seleção de back-end	Ao usar o modo de rastreamento `PER_CONNECTION` (padrão)	Ao usar o modo de acompanhamento `PER_SESSION`
`NONE` (padrão)	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos:hash de três tuplas	TCP:rastreamento de conexão ativado, hash de cinco tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP:rastreamento de conexão ativado, hash de cinco tuplas Todos os outros protocolos: rastreamento de conexão desativado
`CLIENT_IP_PORT_PROTO`	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos:hash de três tuplas	TCP e UDP não fragmentado:rastreamento de conexão ativado, hash de cinco tuplas UDP, ESP e GRE fragmentados:rastreamento de conexão ativado, hash de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP e UDP não fragmentado:rastreamento de conexão ativado, hash de cinco tuplas UDP, ESP e GRE fragmentados:rastreamento de conexão ativado, hash de três tuplas Todos os outros protocolos: rastreamento de conexão desativado
`CLIENT_IP_PROTO`	Todos os protocolos: hash de três tuplas	TCP e UDP não fragmentado:rastreamento de conexão ativado, hash de cinco tuplas UDP, ESP e GRE fragmentados:rastreamento de conexão ativado, hash de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP, UDP, ESP, GRE:rastreamento de conexão ativado, hash de três tuplas Todos os outros protocolos: rastreamento de conexão desativado
`CLIENT_IP`	Todos os protocolos: hash de duas tuplas	TCP e UDP não fragmentado:rastreamento de conexão ativado, hash de cinco tuplas UDP, ESP e GRE fragmentados:rastreamento de conexão ativado, hash de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP, UDP, ESP, GRE:rastreamento de conexão ativado, hash de duas tuplas Todos os outros protocolos: rastreamento de conexão desativado

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

A persistência de conexão em back-ends não íntegros controla se as conexões existentes persistem em um endpoint ou VM de back-end selecionado anteriormente depois que o back-end se torna não íntegro, desde que ele permaneça em um grupo de instâncias ou NEG com balanceamento de carga.

As seguintes opções de persistência de conexão estão disponíveis:

DEFAULT_FOR_PROTOCOL (padrão)
NEVER_PERSIST
ALWAYS_PERSIST

A tabela a seguir resume se as conexões persistem com base em back-ends não íntegros, dependendo da opção de persistência de conexão, da afinidade da sessão, do modo de rastreamento de conexão e do protocolo.

Persistência de conexão em back-ends não íntegros	Comportamento de persistência de conexão em back-ends não íntegros
Persistência de conexão em back-ends não íntegros	Ao usar o modo de rastreamento `PER_CONNECTION` (padrão)	Ao usar o modo de acompanhamento `PER_SESSION`
`DEFAULT_FOR_PROTOCOL`	TCP:as conexões persistem em back-ends não íntegros (todas as afinidades da sessão) Todos os outros protocolos:as conexões nunca persistem em back-ends não íntegros	TCP:as conexões persistem em back-ends não íntegros se a afinidade da sessão for `NONE` ou `CLIENT_IP_PORT_PROTO` 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` Essa opção só deve ser usada para casos de uso avançados.	TCP:as conexões persistem em back-ends não íntegros (todas as afinidades da sessão) ESP, GRE, UDP:as conexões persistem em back-ends não íntegros se a afinidade da sessão não for `NONE` Todos os outros protocolos:não aplicável porque não é possível acompanhar a conexão.	Não é possível configurar

Quando a persistência de conexão em back-ends não íntegros se aplica ao tráfego, cada conexão persiste enquanto houver uma entrada correspondente na tabela de rastreamento de conexão. Para mais informações, consulte a etapa Gerenciar entradas da tabela de rastreamento de conexões.

Para saber como alterar o comportamento de persistência de conexão, consulte Configurar uma política de rastreamento de conexão.

Comportamento de persistência de conexão TCP em back-ends não íntegros

O balanceador de carga usa o rastreamento de conexão de hash de cinco tuplas para conexões TCP nestas situações:

Ao usar o modo de acompanhamento PER_CONNECTION (todas as afinidades da sessão) ou
Ao usar o modo de acompanhamento PER_SESSION, e a afinidade da sessão é NONE ou CLIENT_IP_PORT_PROTO.

Quando o balanceador de carga usa um rastreamento de conexão de hash de cinco tuplas para conexões TCP, lembre-se dos seguintes comportamentos:

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 a pacotes, o cliente poderá tentar novamente com uma nova conexão, permitindo que o balanceador de carga selecione um back-end qualificado diferente. Os pacotes TCP SYN são tratados como novas conexões na etapa Identificar back-ends qualificados.

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. Não é possível modificar esse valor de tempo limite ocioso.

Diminuição da conexão para back-ends removidos, interrompidos ou excluídos

A diminuição de conexão oferece um período mínimo configurável para que as conexões atuais persistam na tabela de rastreamento de conexões do balanceador de carga quando uma das seguintes situações ocorre:

Uma instância de máquina virtual (VM) é removida de um grupo de instâncias de back-end (isso inclui abandonar uma instância em um grupo gerenciado de instâncias de back-end)
Uma VM é interrompida ou excluída (isso inclui ações automáticas, como atualizações contínuas ou redução vertical de um grupo gerenciado de instâncias de back-end).
Um endpoint é removido de um grupo de endpoints de rede (NEG) de back-end.

Por padrão, a diminuição de conexão quando os back-ends são removidos, interrompidos ou excluídos está desativada. Para mais informações, consulte Como ativar a diminuição da conexão.

Balanceamento de carga ponderado

O balanceamento de carga ponderado influencia quais back-ends são qualificados nas Etapas de seleção de back-end. Cada VM ou endpoint de back-end informa seu peso ao balanceador de carga usando uma verificação de integridade HTTP e um cabeçalho de resposta personalizado. Para usar o balanceamento de carga ponderado, configure o seguinte no serviço de back-end do balanceador de carga:

A política de localidade (localityLbPolicy) precisa ser definida como WEIGHTED_MAGLEV.
A verificação de integridade precisa ser HTTP e enviar um cabeçalho de resposta especial:
- O nome do campo do cabeçalho de resposta precisa ser X-Load-Balancing-Endpoint-Weight.
- Os valores dos campos do cabeçalho da resposta podem variar de 0 a 1000, inclusive.

Para mais informações, consulte Configurar o balanceamento de carga ponderado.

Considerações sobre o balanceamento de carga ponderado

O balanceamento de carga ponderado é útil nos seguintes cenários, que permitem que um back-end continue processando as conexões atuais:

O balanceamento de carga ponderado permite que um back-end que está processando conexões de longa duração ou que envolvem grandes quantidades de dados informe ao balanceador de carga para reduzir o número de novas conexões recebidas.
O balanceamento de carga ponderado permite que um back-end sobrecarregado ou em manutenção se remova dos back-ends qualificados para novas conexões. Para isso, o back-end sobrecarregado envia o cabeçalho de resposta X-Load-Balancing-Endpoint-Weight: 0 e pode continuar a passar ou falhar na verificação de integridade do balanceador de carga. Isso funciona porque todos os back-ends com peso diferente de zero (independente do estado de verificação de integridade) são back-ends preferíveis e qualificados na etapa Identificar back-ends qualificados.

Tenha em mente o seguinte ao usar o balanceamento de carga:

Se os back-ends qualificados mudarem os pesos com frequência, o balanceamento de carga ponderado poderá ser prejudicial à afinidade da sessão. Para mais informações, consulte a etapa Selecionar um back-end qualificado.
Se você usar o mesmo grupo de instâncias ou NEG como back-end de dois ou mais serviços de back-end do balanceador de carga, poderá informar um peso exclusivo para cada serviço de back-end usando a seguinte estratégia:
- Use uma verificação de integridade HTTP exclusiva para cada serviço de back-end. Cada verificação de integridade pode usar uma porta de destino ou um parâmetro request-path exclusivo.
- Configure instâncias ou endpoints de back-end para responder com informações de peso adequadas para cada verificação de integridade.

Failover

O failover permite influenciar o conjunto de back-ends qualificados para novas conexões classificando cada grupo de instâncias de back-end ou NEG como principal ou de failover.

Por padrão, quando você adiciona um grupo de instâncias ou um NEG a um serviço de back-end, as VMs ou os endpoints membros são back-ends principais, e o grupo de instâncias ou o NEG é um grupo de back-end principal. Com o failover, é possível adicionar um grupo de back-end de failover (grupo de instâncias ou NEG) cujas VMs ou endpoints membros são back-ends de failover:

O failover exige que um serviço de back-end tenha pelo menos um grupo de back-end principal e um grupo de back-end de failover.
É possível adicionar até 50 grupos de back-end primários e 50 grupos de back-end de failover a um serviço de back-end.

Com o failover, os seguintes fatores determinam o conjunto de back-ends qualificados:

O estado de integridade de cada back-end
A proporção de failover que você configurou
A configuração Descartar tráfego se os back-ends não estiverem íntegros
Se você está usando o failover por conta própria ou em conjunto com o balanceamento de carga ponderado

Política de failover

Quando um serviço de back-end tem pelo menos um grupo de back-end principal e um de failover, é possível ajustar as seguintes configurações na política de failover:

Proporção de failover: um número entre 0.0 e 1.0, inclusive.
Descartar o tráfego se os back-ends não estiverem íntegros: um booleano que determina o comportamento de último recurso do balanceador de carga. A proporção de failover e a configuração Descartar tráfego se os back-ends estiverem não íntegros funcionam juntas com outros fatores para controlar o conjunto de back-ends qualificados.
Descarga da conexão em failover: um booleano que controla se as conexões persistem em back-ends selecionados anteriormente quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover.

Proporção de failover

A proporção de failover configurada determina quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover. A proporção pode ser um número entre 0.0 e 1.0, inclusive. Se você não especificar uma proporção de failover, Google Cloud usará um valor padrão de 0.0. É uma prática recomendada definir a proporção de failover como um número apropriado ao seu caso de uso em vez de depender desse padrão.

Diminuição da conexão em failover

O diminuimento da conexão no failover controla se uma conexão permanece em um endpoint ou VM de back-end selecionado anteriormente quando o conjunto de back-ends qualificados alterna entre back-ends principais e de failover.

A diminuição da conexão no failover é ativada por padrão. A tabela a seguir resume se as conexões persistem, dependendo da opção de descarga de conexão em failover e do protocolo:

Opção de diminuição da conexão em failover	Comportamento quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover
Ativado (padrão)	Protocolos que podem ser rastreados por conexão:as conexões persistem enquanto houver uma entrada correspondente na tabela de rastreamento de conexão, quando o conjunto de back-ends qualificados alterna entre back-ends principais e de failover. Para mais informações, consulte a etapa Gerenciar entradas da tabela de rastreamento de conexões. Protocolos que não podem ser rastreados por conexão:as conexões não persistem quando o conjunto de back-ends qualificados alterna entre back-ends principais e de failover. Para saber quais protocolos podem ser rastreados, consulte a tabela na seção Modo de rastreamento de conexão.
Desativado	Todos os protocolos:as conexões não persistem quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover

Opção de diminuição da conexão em failover

Comportamento quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover

Ativado (padrão)

Protocolos que podem ser rastreados por conexão:as conexões persistem enquanto houver uma entrada correspondente na tabela de rastreamento de conexão, quando o conjunto de back-ends qualificados alterna entre back-ends principais e de failover. Para mais informações, consulte a etapa Gerenciar entradas da tabela de rastreamento de conexões.
Protocolos que não podem ser rastreados por conexão:as conexões não persistem quando o conjunto de back-ends qualificados alterna entre back-ends principais e de failover.

Para saber quais protocolos podem ser rastreados, consulte a tabela na seção Modo de rastreamento de conexão.

Desativado

Todos os protocolos:as conexões não persistem quando o conjunto de back-ends qualificados alterna entre back-ends primários e de failover

A desativação da diminuição de conexão no failover e no failback é útil nestes cenários:

Patches de VMs de back-end. Antes da aplicação de patches, é possível configurar back-ends principais íntegros com peso diferente de zero para falhar nas verificações de integridade ou definir os pesos como zero. Assim, os back-ends qualificados podem ser back-ends de failover íntegros com peso diferente de zero. Ao desativar a diminuição de conexão no failover e no failback, o balanceador de carga remove as entradas da tabela de rastreamento de conexão, aplicando as etapas de seleção de back-end aos pacotes subsequentes e entregando-os a um back-end qualificado diferente. O back-end diferente fecha a conexão com uma redefinição de TCP para que as VMs de cliente possam estabelecer rapidamente uma nova conexão com o balanceador de carga.
VM de back-end única para consistência de dados. Se você precisar garantir que o conjunto de back-ends qualificados tenha apenas uma VM ou endpoint membro, desative a diminuição de conexão no failover e no failback para reduzir a possibilidade de inconsistências de dados.

Para saber como desativar a diminuição da conexão no failover e no failback, consulte Desativar a diminuição da conexão no failover e no failback.

Práticas recomendadas e orientações

É possível otimizar o balanceador de carga de rede de passagem externa seguindo estas diretrizes operacionais. As seções a seguir fornecem requisitos técnicos para gerenciar pacotes UDP fragmentados e práticas recomendadas para testar a distribuição de carga de um único cliente.

Processar a 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 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 UDP ou L3_DEFAULT por 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=ALL ou use a API para definir allPorts como True
Configuraçã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) ou CLIENT_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 como PER_SESSION para que as entradas da tabela de rastreamento de conexão sejam criadas usando os mesmos hashes de duas ou três tuplas.

Como testar de um único cliente

Ao testar um balanceador de carga de rede de passagem externa de um único cliente, lembre-se do seguinte:

Se a VM cliente não for um back-end do balanceador de carga: novas conexões serão processadas conforme descrito nas etapas Seleção de back-end e rastreamento de conexão. Na etapa Selecionar um back-end qualificado, o balanceador de carga cria um hash de características de pacote de acordo com a afinidade de sessão.

Todas as opções de afinidade da sessão dependem de pelo menos o endereço IP do cliente. As conexões do mesmo cliente podem ser distribuídas para o mesmo back-end qualificado com mais frequência do que você imagina. Consequentemente, não é possível modelar com precisão a distribuição geral de novas conexões conectando-se a um balanceador de carga de rede de passagem externa de um único cliente.
Se a VM cliente também for uma VM de back-end do balanceador de carga: novas conexões não são processadas pelo balanceador de carga. Os pacotes de saída com o endereço IP de destino da regra de encaminhamento do balanceador de carga são roteados localmente no SO convidado do cliente devido à presença de uma rota local para a regra de encaminhamento.

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.