Esta página foi traduzida pela API Cloud Translation.

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

Nesta página, explicamos 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 equilibrar várias conexões em diferentes back-ends e encaminhar todos os pacotes de cada conexão para o mesmo back-end. Isso é feito com uma estratégia de duas partes. Primeiro, um back-end é selecionado usando hashing consistente. Em seguida, essa seleção é gravada em uma tabela de rastreamento de conexão.

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

1. Verifique se há uma entrada na tabela de rastreamento de conexões para usar um back-end selecionado anteriormente.

Para uma conexão existente, o balanceador de carga usa a tabela de rastreamento de conexões para identificar o back-end selecionado anteriormente para essa conexão.

O balanceador de carga tenta associar cada pacote com carga balanceada a uma entrada na tabela de rastreamento de conexão usando o seguinte processo:

Se o pacote for 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, 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 quando uma das opções de afinidade da sessão de cinco tuplas (NONE ou CLIENT_IP_PORT_PROTO) é usada.
Para todos os outros pacotes, o balanceador de carga verifica se o pacote corresponde a uma entrada da tabela de rastreamento de conexão. A tupla de conexão (um conjunto de características do pacote) usada para comparar o pacote com as entradas da tabela de rastreamento de conexão existentes depende do modo de rastreamento de conexão e da afinidade de sessão configurada. Para informações sobre qual tupla de conexão é usada para o rastreamento de conexão, 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 para o 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 informações sobre por quanto tempo uma entrada de tabela de rastreamento de conexão permanece e sob quais condições, consulte a etapa Criar uma entrada de tabela de rastreamento de conexão.

2. Selecione um back-end qualificado para uma nova conexão.

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

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ões.

2.1 Identificar back-ends qualificados.

Esta etapa modela quais back-ends são candidatos a receber novas conexões, considerando a integridade e a configuração da política de failover:

Nenhuma política de failover: o conjunto de back-ends qualificados depende apenas de verificações de integridade:
- Quando pelo menos um back-end está íntegro, o conjunto de back-ends elegíveis 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.
Política de failover configurada: o conjunto de back-ends qualificados depende das verificações de integridade e da configuração da política de failover:
- Quando pelo menos um back-end está íntegro, o conjunto de back-ends qualificados é composto por todos os back-ends íntegros no pool ativo.
  - O pool ativo pode consistir em todos os back-ends principais íntegros ou em todos os back-ends de failover íntegros. A associação ao pool ativo é determinada pela proporção de failover configurada, pelo número de back-ends principais íntegros e pelo número total de back-ends principais.
  - Apesar da proporção de failover, se não houver back-ends de failover íntegros, mas houver pelo menos um back-end principal, o pool ativo será composto por todos os back-ends principais.
- Quando não há back-ends íntegros e a política de failover do balanceador de carga está configurada para descartar novas conexões, nessa situação, o conjunto de back-ends qualificados fica vazio. O balanceador de carga descarta os pacotes da conexão.
- Quando não há back-ends saudáveis e a política de failover do balanceador de carga não está configurada para descartar novas conexões, as verificações de integridade não são relevantes. Os back-ends qualificados consistem em todos os back-ends principais.

2.2 Selecione um back-end qualificado.

O balanceador de carga usa hash consistente para selecionar um back-end qualificado. O balanceador de carga mantém hashes de back-ends qualificados, mapeados 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 mapeia esse hash para o mesmo círculo de unidade, selecionando um back-end qualificado na circunferência do círculo. O conjunto de características do pacote usado para calcular o hash do pacote é definido pela configuração de afinidade de sessão.

Se uma afinidade da sessão não for configurada explicitamente, a afinidade de sessão NONE será o padrão.
O balanceador de carga atribui novas conexões a back-ends qualificados de maneira tão consistente quanto possível, mesmo que o número de back-ends qualificados mude. Os benefícios a seguir do hashing consistente mostram como o balanceador de carga seleciona back-ends qualificados para possíveis novas conexões que não têm entradas de tabela de rastreamento de conexão:
- O balanceador de carga seleciona o mesmo back-end para todas as novas conexões possíveis que tenham características de pacote idênticas, conforme definido pela afinidade da sessão, se o conjunto de back-ends qualificados não mudar.
- Quando um novo back-end qualificado é adicionado, aproximadamente 1/N possíveis novas conexões são mapeadas para o back-end recém-adicionado. Nessa situação, N é a contagem de back-ends qualificados após a adição do novo back-end.
- Quando um back-end qualificado é removido, aproximadamente 1/N possíveis 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.3 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ões. A entrada da tabela de rastreamento de conexão mapeia as características do pacote para o back-end selecionado. Os campos do cabeçalho do pacote usados para esse mapeamento dependem do modo de rastreamento de conexão e da afinidade da sessão configurados.

O balanceador de carga remove entradas da tabela de rastreamento de conexão de acordo com as seguintes regras:

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 usa um tempo limite de inatividade padrão de 600 segundos. Para mais informações, consulte Tempo limite de inatividade.
As entradas da tabela de rastreamento de conexão não são removidas quando uma conexão TCP é encerrada com um pacote FIN ou RST. Qualquer conexão TCP nova sempre carrega a flag SYN e é processada conforme descrito na etapa Verificar uma entrada da tabela de rastreamento de conexão.
Se uma política de failover estiver configurada e a diminuição de conexão na configuração de failover e failback estiver desativada, o balanceador de carga vai remover todas as entradas na tabela de rastreamento de conexão quando o pool ativo mudar durante o failover ou o failback. Para mais informações, consulte Diminuição da conexão no failover e failback.
As entradas na tabela de rastreamento de conexão podem ser removidas se um back-end não estiver íntegro. Esse comportamento depende do modo de rastreamento de conexão, do protocolo e da configuração de persistência de conexão em back-ends não íntegros. Para mais informações, consulte Persistência de conexão em back-ends não íntegros.
As entradas na tabela de rastreamento de conexão são removidas após o tempo limite de diminuição da conexão que ocorre após um evento, como excluir uma VM de back-end ou remover uma VM de back-end de um grupo de instâncias ou NEG. Para mais informações, consulte Ativar a diminuição da conexão.

afinidade da sessão

A afinidade de sessão controla a distribuição de novas conexões de clientes para os back-ends do balanceador de carga. Os balanceadores de carga de rede de passagem interno usam a afinidade da sessão para selecionar um back-end de um conjunto de back-ends qualificados, conforme descrito nas etapas Identificar back-ends qualificados e Selecionar um back-end qualificado na seção Seleção de back-end e rastreamento de conexão. Você configura a afinidade da sessão no serviço de back-end, não em cada grupo de instâncias de back-end ou NEG.

Os balanceadores de carga de rede de passagem interna são compatíveis com as seguintes configurações afinidade da sessão. Cada configuração afinidade da sessão usa hash consistente para selecionar um back-end qualificado. A configuração de afinidade da sessão determina quais campos do cabeçalho IP e da camada 4 são usados para calcular o hash.

Método de hash para seleção de back-end	Configuração de afinidade da sessão
Hash de cinco tuplas (consiste no 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, como 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`¹
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, como 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	`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`²

¹ Uma configuração afinidade da sessão de NONE não significa que não há afinidade da sessão. Isso significa que nenhuma opção afinidade da sessão está configurada explicitamente.

A hash é sempre realizada para selecionar um back-end. E uma configuração de afinidade de sessão de NONE significa que o balanceador de carga usa um hash de cinco ou três tuplas para selecionar back-ends, ou seja, o mesmo comportamento que quando CLIENT_IP_PORT_PROTO é definido.

² CLIENT_IP_NO_DESTINATION é um hash de uma tupla com base apenas no endereço IP de origem de cada pacote recebido. Essa configuração pode ser útil em situações em que você precisa que a mesma VM de back-end processe todos os pacotes de um cliente com base apenas no endereço IP de origem do pacote, sem considerar o endereço IP de destino do pacote. Essas situações geralmente surgem quando um balanceador de carga de rede de passagem interna é um próximo salto para uma rota estática. Para mais detalhes, consulte Afinidade de sessão e balanceador de carga de rede de passagem interna de próximo salto.

Para saber como as diferentes configurações afinidade da sessão afetam os métodos de seleção de back-end e rastreamento de conexão, consulte a tabela na seção Modo de rastreamento de conexão.

Afinidade da sessão e passagem do balanceador de carga interno de rede

Quando você configura uma rota estática para usar um próximo salto de balanceador de carga de rede de passagem interna, o balanceador usa o mesmo método de seleção de back-end e rastreamento de conexão. A seleção de back-end ainda é feita calculando um hash de acordo com a afinidade de sessão configurada. Exceto a afinidade da sessão CLIENT_IP_NO_DESTINATION (hash de uma tupla), o hash de seleção do back-end depende, em parte, do endereço IP de destino do pacote.

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 é limitado 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.

Se o número de VMs de back-end configuradas e íntegras for constante (quando o failover não estiver configurado ou quando o failover estiver configurado, mas nenhum evento de failover ou failback ocorrer), o balanceador de carga vai se comportar da seguinte maneira:

Se houver apenas uma VM de back-end configurada e íntegra (no pool ativo, se o failover estiver configurado), não importa qual afinidade da sessão você usar, porque todos os hashes são mapeados para a VM de back-end.
Se houver duas ou mais VMs de back-end configuradas e íntegras (no pool ativo, se o failover estiver configurado), sua escolha de afinidade da sessão será importante:
- 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 do pacote, independentemente dos endereços IP de destino do pacote, use a afinidade da sessão CLIENT_IP_NO_DESTINATION. Dependendo dos padrões de tráfego, algumas VMs de back-end podem receber mais pacotes ou mais conexões do que outras VMs de back-end.
- Se você usar uma opção de afinidade da sessão que não seja CLIENT_IP_NO_DESTINATION, o balanceador de carga vai selecionar uma VM de back-end com base em informações que incluam pelo menos ambos o endereço IP de origem e o endereço IP de destino do pacote. Os pacotes enviados pelo mesmo cliente, usando o mesmo endereço IP de origem, mas diferentes endereços IP de destino, podem ser roteados para diferentes VMs de back-end.

Política de rastreamento da conexão

Esta seção descreve as configurações que controlam o comportamento de rastreamento de conexão dos balanceadores de carga de rede de passagem interna. Uma política de rastreamento de conexão inclui as seguintes configurações:

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

A tabela de rastreamento de conexões do balanceador de carga mapeia tuplas de conexão para back-ends selecionados anteriormente em uma tabela hash. O conjunto de características de pacotes que compõe cada tupla de conexão é determinado pelo modo de rastreamento de conexão e afinidade da sessão.

Os balanceadores de carga de rede de passagem interna rastreiam conexões para todos os protocolos compatíveis.

O modo de rastreamento de conexão se refere à granularidade de cada tupla de conexão na tabela de rastreamento de conexão do balanceador de carga. A tupla de conexão pode ser de 5 ou 3 tuplas (modo PER_CONNECTION) ou pode corresponder à configuração de afinidade da sessão (modo PER_SESSION).

PER_CONNECTION. Esse é o modo de rastreamento de conexão padrão. Esse modo de rastreamento de conexão usa um hash de cinco ou três tuplas. Os 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 três tuplas.
PER_SESSION. Esse modo de rastreamento de conexão usa um hash que consiste nas mesmas características de pacote usadas pelo hash de afinidade da sessão. Dependendo da afinidade de sessão escolhida, PER_SESSION pode resultar em conexões que correspondem com mais frequência a uma entrada da tabela de rastreamento de conexões, reduzindo a frequência com que um back-end precisa ser selecionado pelo hash de afinidade da sessão.

A tabela a seguir resume como o modo de rastreamento de conexão e a afinidade da sessão trabalham juntos para rotear todos os pacotes de cada conexão para o mesmo back-end.

Seleção de back-end usando afinidade da sessão		Modo de rastreamento de conexão
Configuração de afinidade da sessão	Método de hash para seleção de back-end	`PER_CONNECTION` (padrão)	`PER_SESSION`
`NONE`	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: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas
`CLIENT_IP_NO_DESTINATION`	Todos os protocolos: hash de uma tupla	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	Todos os protocolos: hash de uma tupla
`CLIENT_IP`	Todos os protocolos: hash de duas tuplas	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	Todos os protocolos: hash de duas tuplas
`CLIENT_IP_PROTO`	Todos os protocolos: hash de três tuplas	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	Todos os protocolos: hash de três tuplas
`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: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas	TCP e UDP não fragmentado: hash de cinco tuplas UDP fragmentado e todos os outros protocolos: hash de três tuplas

Para saber como alterar o modo de rastreamento de conexão, consulte Configurar uma política de rastreamento de conexão.

Persistência de conexão em back-ends não íntegros

As configurações de persistência de conexão controlam se uma conexão permanece em um endpoint ou VM de back-end selecionado depois que o back-end se torna não íntegro, desde que o back-end permaneça no grupo de back-end configurado do balanceador de carga (em um grupo de instâncias ou um NEG).

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 as opções de persistência de conexão e como as conexões persistem para diferentes protocolos, opções de afinidade da sessão e modos de rastreamento.

Persistência de conexão em back-ends não íntegros	Modo de rastreamento de conexão
Persistência de conexão em back-ends não íntegros	`PER_CONNECTION`	`PER_SESSION`
`DEFAULT_FOR_PROTOCOL`	TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão) UDP: as conexões nunca persistem em back-ends não íntegros	TCP: conexões persistem em back-ends não íntegros se a afinidade da sessão é `NONE` ou `CLIENT_IP_PORT_PROTO` UDP: as conexões nunca persistem em back-ends não íntegros
`NEVER_PERSIST`	TCP, UDP: as conexões nunca persistem em back-ends não íntegros
`ALWAYS_PERSIST`	TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão) Essa opção só deve ser usada para casos de uso avançados.	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.

Observação: quando um back-end se torna não íntegro, o balanceador de carga remove as entradas da tabela de rastreamento de conexão de acordo com o protocolo de pacote e a opção de persistência de conexão em back-ends não íntegros selecionada. Os pacotes subsequentes para as conexões com entradas removidas são tratados como novas conexões. O balanceador de carga cria uma entrada de tabela de rastreamento de conexão de substituição, depois de selecionar um back-end qualificado, para cada conexão. As entradas de tabela de rastreamento de conexão de substituição permanecem válidas de acordo com as mesmas condições de qualquer outra entrada de tabela de rastreamento de conexão. Se o back-end não íntegro voltar a ser íntegro, esse evento sozinho não faz com que as entradas da tabela de rastreamento de conexão de substituição sejam removidas, a menos que o evento acione um failback e a diminuição da conexão em failover e failback seja desativada.

Tempo limite de inatividade

Por padrão, uma entrada na tabela de rastreamento de conexão expira 600 segundos após o balanceador de carga processar o último pacote que correspondeu à entrada. Esse valor de tempo limite padrão inativo pode ser modificado somente quando o rastreamento de conexão for menor que cinco tuplas, ou seja, quando a afinidade de sessão estiver configurada como CLIENT_IP ou CLIENT_IP_PROTO: e o modo de acompanhamento é PER_SESSION).

O valor máximo do tempo limite de inatividade configurável é de 57.600 segundos (16 horas).

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

Conexões para implantações de cliente único

Ao testar conexões com o endereço IP de um balanceador de carga de rede de passagem interna que tem apenas um cliente, lembre-se do seguinte:

Se a VM cliente não estiver sendo balanceada de carga, ou seja, se não for também uma VM de back-end, novas conexões serão enviadas às VMs de back-end íntegras do balanceador de carga. No entanto, como todas as opções de afinidade de sessão dependem pelo menos do endereço IP do sistema do cliente, as conexões do mesmo cliente podem ser distribuídas para a mesma VM de back-end com mais frequência do que o esperado.

Na prática, isso quer dizer é que não é possível monitorar com precisão a distribuição de tráfego por meio de um balanceador de carga de rede de passagem interno que se conecta de um único cliente. O número necessário de clientes para monitorar a distribuição de tráfego varia de acordo com o tipo do balanceador de carga, o tipo de tráfego e o número de back-ends íntegros.
Se a VM cliente também for uma VM de back-end do balanceador de carga, as conexões enviadas ao endereço IP da regra de encaminhamento do balanceador de carga serão sempre respondidas pela mesma VM de back-end, que também é a VM cliente. Isso acontece independente de a VM de back-end estar íntegra. Isso acontece para todo o tráfego enviado ao endereço IP do balanceador de carga, não apenas o tráfego no protocolo e as portas especificadas na regra de encaminhamento interno do balanceador de carga.

Para mais informações, consulte Como enviar solicitações a partir de VMs submetidas a balanceamento de carga.

Diminuição da conexão

A diminuição de conexão oferece um tempo adicional configurável para que as conexões estabelecidas persistam na tabela de rastreamento de conexões do balanceador de carga quando uma das seguintes ações ocorrer:

Uma instância de máquina virtual (VM) é removida de um grupo de instâncias de back-end, incluindo o abandono de 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 de back-end (NEG)

Por padrão, a diminuição de conexão para as ações mencionadas acima fica desativada. Para saber como a diminuição da conexão é acionada e como ativá-la, consulte Como ativar a diminuição da conexão.

Fragmentação UDP

Os balanceadores de carga de rede de passagem 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 Google Cloud rede VPC.
Google Cloud As redes VPC encaminham fragmentos UDP à medida que chegam, sem esperar que todos os fragmentos cheguem.
As redes que não sãoGoogle 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.

Failover

Um balanceador de carga de rede de passagem interna permite designar alguns back-ends como back-ends de failover. Esses back-ends só são usados quando o número de VMs íntegras nos grupos de instâncias de back-end primários está abaixo de um limite configurável. Por padrão, se todas as VMs primárias e de failover não estiverem íntegras, como um último recurso, Google Cloud distribui novas conexões somente entre todas as VMs primárias.

Ao adicionar um back-end a um serviço de back-end do balanceador de carga de rede de passagem interno, por padrão, ele é um back-end primário. Para designar um back-end como sendo de failover, faça isso quando adicioná-lo ao serviço de back-end do balanceador de carga ou edite esse serviço posteriormente.

Para mais informações sobre como o failover é usado para seleção de back-end e rastreamento de conexão, consulte as etapas Identificar back-ends qualificados e Criar uma entrada de tabela de rastreamento de conexão na seção Seleção de back-end e rastreamento de conexão.

Para mais informações sobre como o failover funciona, consulte Failover para balanceadores de carga de rede de passagem interna.

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.