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

Nesta página, explicamos conceitos sobre como os balanceadores de carga de rede de passagem interna 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).

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

Política de failover	Back-ends qualificados
	Quando nenhuma política de failover é configurada, todos os back-ends configurados são primários. 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 uma política de failover é configurada, 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.

2.2 Ajustar back-ends qualificados para afinidade zonal

Essa etapa será ignorada se uma das seguintes condições for verdadeira:

• A afinidade zonal está desativada
• O cliente é incompatível com a afinidade zonal
• Uma correspondência zonal com a zona de um cliente compatível não acontece

Se a afinidade zonal estiver ativada, um cliente for compatível com ela e houver uma correspondência zonal, as novas conexões do cliente serão encaminhadas para um conjunto ajustado de back-ends qualificados. Para ver mais informações, consulte os seguintes tópicos:

• Como o ZONAL_AFFINITY_STAY_WITHIN_ZONE funciona

• Como a ZONAL_AFFINITY_SPILL_CROSS_ZONE e a proporção de spillover funcionam

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

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

  • O balanceador de carga sempre seleciona o mesmo back-end qualificado para uma conexão e, de modo 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, se o conjunto de back-ends qualificados não mudar.

  • Se um back-end qualificado for adicionado ou removido, o 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):

  • Quando um back-end qualificado é adicionado, aproximadamente 1/N novas conexões são mapeadas para ele. Nessa situação, N é a contagem de back-ends depois que o novo back-end é adicionado.

  • Quando um back-end qualificado é removido, aproximadamente 1/N novas conexões são mapeadas para um dos N-1 back-ends restantes. Nessa situação, N é a contagem de back-ends antes da remoção do back-end qualificado.

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

Depois de selecionar um back-end, o balanceador de carga cria uma entrada na tabela de rastreamento de conexão. A entrada da tabela de rastreamento de conexão mapeia as características do pacote para o back-end selecionado. Os campos de cabeçalho de pacote usados para esse mapeamento dependem do modo de rastreamento de conexão e da afinidade da sessão configurados.

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 inativas são removidas: uma entrada da tabela de rastreamento de conexão é removida depois que a conexão fica inativa. A menos que você configure um tempo limite de inatividade personalizado, o balanceador de carga usará um tempo limite de inatividade padrão de 600 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 interna 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 interna 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
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^1 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 uma tupla (consiste apenas no IP de origem)	CLIENT_IP_NO_DESTINATION

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

Afinidade de sessão e próximo salto do balanceador de carga

Quando um balanceador de carga de rede de passagem interna é um próximo salto de uma rota estática, o endereço IP de destino não se limita ao endereço IP da regra de encaminhamento do balanceador de carga. Em vez disso, o endereço IP de destino do pacote pode ser qualquer endereço IP que se encaixe no intervalo de destino da rota estática.

Selecionar um back-end qualificado depende do cálculo de um hash de características do pacote. Exceto a afinidade da sessão CLIENT_IP_NO_DESTINATION (hash de uma tupla), o hash depende, em parte, do endereço IP de destino do pacote.

O balanceador de carga seleciona o mesmo back-end para todas as novas conexões possíveis que têm características de pacote idênticas, conforme definido pela afinidade da sessão, se o conjunto de back-ends qualificados não mudar. Se você precisar que a mesma VM de back-end processe todos os pacotes de um cliente, com base apenas no endereço IP de origem, independentemente dos endereços IP de destino, use a afinidade da sessão CLIENT_IP_NO_DESTINATION.

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 como o balanceador de carga cria entradas na tabela de rastreamento de conexões. Os balanceadores de carga de rede de passagem interna rastreiam conexões para todos os protocolos compatíveis e para todas as opções afinidade da sessão.

O modo de rastreamento de conexão, 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
		Ao usar o modo de rastreamento PER_CONNECTION (padrão)	Ao usar o modo de acompanhamento PER_SESSION
NONE (padrão) OU 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 fragmentado e todos os outros protocolos:rastreamento de conexão ativado, hash de três tuplas	TCP e UDP não fragmentado:rastreamento de conexão ativado, hash de cinco tuplas UDP fragmentado e todos os outros protocolos:rastreamento de conexão ativado, hash de três tuplas
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 fragmentado e todos os outros protocolos:rastreamento de conexão ativado, hash de três tuplas	Todos os protocolos:rastreamento de conexão ativado, hash de três tuplas
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 fragmentado e todos os outros protocolos:rastreamento de conexão ativado, hash de três tuplas	Todos os protocolos:rastreamento de conexão ativado, hash de duas tuplas
CLIENT_IP_NO_DESTINATION	Todos os protocolos:hash de uma tupla	TCP e UDP não fragmentado:rastreamento de conexão ativado, hash de cinco tuplas UDP fragmentado e todos os outros protocolos:rastreamento de conexão ativado, hash de três tuplas	Todos os protocolos:rastreamento de conexão ativado, hash de uma tupla

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 uma VM ou endpoint 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
	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, UDP:as conexões permanecem em back-ends não íntegros (todas as afinidades de sessã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

Uma entrada da tabela de rastreamento de conexão é removida depois que a conexão fica inativa por um determinado período. A menos que você configure um tempo limite de inatividade personalizado, o balanceador de carga usará um valor padrão de 600 segundos (10 minutos).

A tabela a seguir mostra os valores mínimo e máximo configuráveis de tempo limite de inatividade para diferentes combinações de afinidade da sessão e configurações de modo de rastreamento de conexão.

afinidade da sessão	Modo de rastreamento de conexão	Tempo limite de inatividade padrão	Tempo limite mínimo de inatividade configurável	Tempo limite máximo de inatividade configurável
Qualquer tupla de conexão	PER_CONNECTION	600 segundos	60 segundos	600 segundos
1 tupla (CLIENT_IP_NO_DESTINATION) Dupla (CLIENT_IP) Tupla de três elementos (CLIENT_IP_PROTO)	PER_SESSION	600 segundos	60 segundos	57.600 segundos
5 tuplas (NONE, CLIENT_IP_PORT_PROTO)	PER_SESSION	600 segundos	60 segundos	600 segundos

Para saber como alterar o valor do tempo limite de inatividade, consulte Configurar uma política de rastreamento de conexão.

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.

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

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)	Todos os protocolos: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 os principais e de failover. Para mais informações, consulte a etapa Gerenciar entradas da tabela de rastreamento de conexões.
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 para falhar nas verificações de integridade, para que os back-ends qualificados possam ser back-ends de failover íntegros. 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 interna 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 interna 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 UDP por regra de encaminhamento por endereço IP com balanceamento de carga e configure a regra de encaminhamento para aceitar 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 interna 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 pelo menos do 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 interna 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 e testar um balanceador de carga de rede de passagem interna que usa failover, consulte Configurar failover para balanceadores de carga de rede de passagem interna.
• Para configurar e testar um balanceador de carga de rede de passagem interna, consulte Configurar um balanceador de carga de rede de passagem interna.