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

Os balanceadores de carga de rede de passagem distribuem o tráfego de entrada entre as instâncias de back-end disponíveis. Este documento explica como o balanceador de carga seleciona back-ends, rastreia conexões e gerencia afinidade da sessão, balanceamento de carga ponderado e failover.

Entender como todos esses recursos funcionam juntos ajuda a otimizar a configuração de balanceamento de carga para um desempenho confiável e uma utilização eficiente de recursos. Esses mecanismos são cruciais para aplicativos que exigem persistência de sessão, permitindo que eles mantenham um comportamento consistente para cada interação do usuário.

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

A seleção de back-ends 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-ends e o rastreamento de conexão.

1. Verificar uma entrada na tabela de acompanhamento de conexões

O balanceador de carga determina se um pacote com carga balanceada pertence a uma conexão nova ou atual 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, independentemente 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, prossiga 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 da 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 de tabela de rastreamento de conexão atual. 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 da afinidade da sessã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 o enviará ao back-end selecionado anteriormente.

  • Se o pacote não corresponder a uma entrada da tabela de rastreamento de conexão, siga para a etapa Identificar back-ends qualificados.

  Para saber por quanto tempo uma entrada da tabela de rastreamento de conexão persiste e em quais condições, 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 hashing consistente para selecionar um back-end entre os qualificados.

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

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 do uso de failover pelo balanceador de carga.

Failover	Back-ends qualificados
	Quando o recurso de balanceamento de carga de failover está desativado, todos os back-ends configurados são back-ends principais. O conjunto de back-ends qualificados é definido da seguinte maneira: Quando pelo menos um back-end é í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 o recurso de balanceamento de carga de failover está ativado, 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 (principal 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 principais í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 serão 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 (primários 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 vai ficar vazio. Consequentemente, 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 não estiverem í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 alguma 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 roteadas 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 funcionam ZONAL_AFFINITY_SPILL_CROSS_ZONE e a proporção de spillover

2.3 Selecionar 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 de pacote é definido pela configuração de afinidade da sessão. Por exemplo, quando a afinidade da sessão selecionada resulta em um hash de seleção de back-end de 2 ou 3 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 da sessão NONE será o 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 afinidade da 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 tentar 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 vai 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 pacotes 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 5 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 após a adição do novo back-end.

  • 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 de 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 que você configurou.

Para informações sobre 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 inativas são removidas: uma entrada da tabela de rastreamento de conexão é removida após um determinado período se nenhum novo pacote de entrada for processado pelo balanceador de carga. 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.

• As entradas são removidas quando as tabelas de rastreamento de conexão do cliente estão cheias: as tabelas de rastreamento de conexão para balanceadores de carga de rede de passagem interna são implementadas em sistemas do cliente, como um host que executa uma instância de VM, um host que alimenta um anexo da VLAN ou um host que executa um túnel de VPN do Cloud VPN. Quando a tabela de rastreamento de conexão de um cliente está cheia, ela remove as entradas das conexões menos usadas recentemente.

• Conexões TCP fechadas: as entradas da tabela de rastreamento de conexões TCP não são removidas quando uma conexão TCP é fechada com um pacote FIN ou RST. Elas podem ser removidas posteriormente 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 na tabela de rastreamento de conexão.

• Quando as conexões não persistem no failover: quando pelo menos um back-end de failover está configurado e a configuração de diminuição da conexão no failover está desativada, o balanceador de carga remove todas as entradas na tabela de rastreamento de conexão depois que o conjunto de back-ends qualificados alterna entre back-ends primários e de failover, sujeito às seguintes regras:

  • O balanceador de carga não remove proativamente as entradas da tabela de rastreamento de conexão no momento em que o conjunto de back-ends qualificados alterna entre back-ends primários e de failover. Em vez disso, o balanceador de carga remove cada entrada da tabela de rastreamento de conexão quando um próximo pacote da conexão chega, desde que o conjunto de back-ends qualificados não tenha sido revertido.

  • Se o conjunto de back-ends qualificados alternar entre back-ends primários e de failover e voltar (por exemplo, de primário para failover e depois voltar para primário) e nenhum pacote para a conexão chegar entre os eventos de alternância, a entrada da tabela de rastreamento de conexão será mantida, a menos que outro motivo ou evento remova a entrada da tabela de rastreamento de conexão.

  Para mais informações, consulte Diminuição da conexão em caso de failover.

• Quando as conexões não persistem em back-ends não íntegros: quando a persistência de conexão em back-ends não íntegros está desativada para o protocolo do pacote, o balanceador de carga remove as entradas da tabela de rastreamento de conexão em back-ends não íntegros de acordo com as seguintes regras:

  • O balanceador de carga não remove proativamente as entradas da tabela de rastreamento de conexão para um back-end selecionado anteriormente no momento em que o back-end se torna não íntegro. Em vez disso, o balanceador de carga remove uma entrada da tabela de rastreamento de conexão quando um próximo pacote da conexão chega, desde que o back-end selecionado anteriormente permaneça não íntegro. Os pacotes subsequentes da conexão são tratados como uma nova conexão, porque o balanceador de carga seleciona um novo back-end qualificado e cria uma nova entrada na tabela de rastreamento de conexão.

  • Se um back-end selecionado anteriormente mudar de íntegro para não íntegro e, em seguida, voltar a ser íntegro, e nenhum pacote para a conexão chegar enquanto o back-end selecionado anteriormente não estiver íntegro, a entrada da tabela de rastreamento de conexão será mantida, a menos que outro motivo ou evento remova a entrada da tabela de rastreamento de conexão.

• 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 de diminuição da conexão configurável. A contagem para o tempo limite começa quando o comando para remover (abandonar), parar ou excluir um back-end é recebido (incluindo comandos de exclusão que são o resultado da redução de um grupo gerenciado de instâncias). 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.

Configure a afinidade da sessão no serviço de back-end, não em cada grupo de instâncias de back-end ou NEG. A afinidade da sessão determina quais cabeçalhos de IP e da camada 4 são usados para calcular um hash de características de pacotes. 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 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 pacotes UDP não fragmentados) OU Hash de três tuplas (composto por 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 no endereço IP de origem e no 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 é definido.

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

Quando um balanceador de carga de rede de passagem interna é o 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 ajuste ao intervalo de destino da rota estática.

A seleção de um back-end qualificado depende do cálculo de um hash das características do pacote. Exceto a afinidade da sessão CLIENT_IP_NO_DESTINATION (hash de 1 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

Nesta seção, descrevemos 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ão. 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 rastreamento de conexão padrão e mais granular. Cada conexão é definida como um hash de 5 tuplas ou um hash de 3 tuplas de características de pacote, dependendo se as informações de porta estão presentes no pacote. Os pacotes não fragmentados que incluem informações de porta (como pacotes TCP e pacotes UDP não fragmentados) são rastreados com hashes de cinco tuplas. Todos os outros pacotes são rastreados com hashes de 3 tuplas.

• 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 pacotes 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, protocolo e afinidade da sessão.

afinidade da sessão	Hash de pacote para seleção de back-end	Hash de pacotes para rastreamento de conexão
		Ao usar o modo de rastreamento PER_CONNECTION (padrão)	Ao usar o modo de rastreamento 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 podem persistir em uma VM de back-end selecionada anteriormente se ela se tornar não íntegra. A persistência de conexão em back-ends não íntegros exige que a VM de back-end permaneça como membro de um grupo de instâncias com balanceamento de carga ou NEG.

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 descreve o comportamento da persistência de conexão em back-ends não íntegros, dependendo da opção de persistência de conexão em back-ends não íntegros, do modo de rastreamento de conexão, da afinidade da sessã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 rastreamento PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP, SCTP (todas as afinidades de sessão): as conexões permanecem em back-ends não íntegros, sujeitas aos outros eventos e regras na etapa gerenciar entradas da tabela de rastreamento de conexão. Todos os outros protocolos:as conexões não persistem em back-ends não íntegros	TCP, SCTP (afinidades da sessão NONE e CLIENT_IP_PORT_PROTO): as conexões persistem em back-ends não íntegros, sujeitas aos outros eventos e regras na etapa gerenciar entradas da tabela de rastreamento de conexão. TCP, SCTP (todas as outras afinidades da sessão) e todos os outros protocolos:as conexões não permanecem em back-ends não íntegros
NEVER_PERSIST	Todos os protocolos:as conexões não persistem em back-ends não íntegros
ALWAYS_PERSIST Essa opção só deve ser usada para casos de uso avançados.	Todos os protocolos (todas as afinidades da sessão): as conexões permanecem em back-ends não íntegros, sujeitos aos outros eventos e regras na etapa Gerenciar entradas da tabela de rastreamento de conexão	Não é possível configurar

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 acompanhamento 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 rastreamento 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 5 tuplas para conexões TCP, lembre-se dos seguintes comportamentos:

• Se o back-end não íntegro continuar respondendo aos pacotes, a conexão vai continuar até ser 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 (RST) TCP 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 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 configurações de afinidade da sessão e modo de rastreamento de conexão.

afinidade da sessão	Modo de rastreamento de conexão	Tempo limite de inatividade padrão	Tempo limite de inatividade mínimo configurável	Tempo limite de inatividade máximo configurável
Qualquer tupla de conexão	PER_CONNECTION	600 segundos	60 segundos	600 segundos
1 tupla (CLIENT_IP_NO_DESTINATION) Tupla de dois elementos (CLIENT_IP) 3 tuplas (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 da conexão oferece um período mínimo configurável para que as conexões atuais persistam na tabela de rastreamento de conexão 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 graduais ou redução de escala 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 da 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 recurso de failover permite que você influencie o conjunto de back-ends qualificados classificando grupos de instâncias de back-end ou NEGs e os endpoints deles da seguinte maneira:

• Os back-ends principais são VMs ou endpoints em um grupo de instâncias ou NEG configurado como um grupo de back-end principal.
• Os back-ends de failover são VMs ou endpoints em um grupo de instâncias ou NEG configurado como um grupo de back-ends de failover.

Por padrão, quando você adiciona um grupo de instâncias ou NEG a um serviço de back-end, o grupo de instâncias ou NEG é um grupo de back-end principal. É possível adicionar até 50 grupos de back-end principais e 50 grupos de back-end de failover a um serviço de back-end.

Para ativar o recurso de failover, configure o serviço de back-end do balanceador de carga com o seguinte:

• Pelo menos um grupo de back-end principal não vazio
• Pelo menos um grupo de back-end de failover não vazio

Quando o failover está ativado, os seguintes fatores determinam o conjunto de back-ends qualificados:

• O estado de integridade de cada back-end
• A proporção de failover na política de failover
• A configuração descartar tráfego se os back-ends não estiverem íntegros na política de failover.

Observação: um balanceador de carga com o recurso de failover ativado não significa que os back-ends qualificados são sempre de failover. O recurso de failover requer back-ends principais e de failover, e o balanceador de carga alterna os back-ends qualificados de acordo com a configuração da política de failover.

Política de failover

É possível ajustar as seguintes configurações na política de failover de um serviço de back-end. A política de failover só é relevante se o failover estiver ativado.

• 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 não estiverem íntegros funcionam em conjunto com outros fatores para controlar o conjunto de back-ends qualificados.
• Diminuição 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 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, incluindo esses dois valores. Se você não especificar uma proporção de failover,o Google Cloud usará um valor padrão de 0.0. É uma prática recomendada definir a proporção de failover como um número que funcione para seu caso de uso, em vez de confiar nesse padrão.

Diminuição da conexão em failover

A diminuição 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 primários e de failover.

A diminuição da conexão em failover é ativada por padrão. A tabela a seguir resume se as conexões persistem, dependendo da opção de diminuição da 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, desde que haja 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.
Desativado	Todos os protocolos:as conexões não persistem quando o conjunto de back-ends qualificados alterna entre back-ends principais e de failover.

Desativar a diminuição da conexão em failover é útil para os seguintes cenários:

• Como aplicar patches em VMs de back-end. Antes da correção, é possível configurar back-ends principais íntegros para falhar nas verificações de integridade. Assim, os back-ends qualificados podem ser back-ends de failover íntegros. Ao desativar o encerramento de conexões durante o failover, o balanceador de carga remove as entradas da tabela de rastreamento de conexões, aplica as etapas de seleção de back-end aos pacotes subsequentes e os entrega a um back-end qualificado diferente. O back-end diferente fecha a conexão com uma redefinição de TCP, para que as VMs do 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 não tenha mais de uma VM ou endpoint de membro, desativar a diminuição da conexão no failover reduzirá a possibilidade de inconsistências de dados.

Para saber como desativar a diminuição da conexão no failover, consulte Definir uma política de failover.

Práticas recomendadas e orientações

Para otimizar um balanceador de carga de rede de passagem interna, siga 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.

Como lidar com a fragmentação de 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 regra de encaminhamento e parâmetros de configurações de 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 do cliente não for um back-end do balanceador de carga: as novas conexões serão processadas conforme descrito nas etapas de 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 da sessão.

  Lembre-se de que 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 o esperado. 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: as novas conexões não serã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.