Algumas ou todas as informações nesta página podem não se aplicar à nuvem confiável da S3NS.

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 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 de 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 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 atual, o balanceador de carga usa a tabela de rastreamento de conexão para identificar o back-end selecionado anteriormente para essa conexão.

O balanceador de carga tenta corresponder 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 ao usar uma das opções de afinidade da sessão de cinco tuplas (NONE ou CLIENT_IP_PORT_PROTO).
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 de pacote) usada para comparar o pacote com as entradas da tabela de rastreamento de conexão depende do modo de rastreamento de conexão e da afinidade de sessão configurados. Para saber qual tupla de conexão é usada para o acompanhamento de conexão, consulte a tabela na seção Modo de acompanhamento 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 informações sobre por quanto tempo uma entrada da tabela de rastreamento de conexão persiste e em quais condições ela persiste, consulte a etapa Criar uma entrada da tabela de rastreamento de conexão.

2. Selecionar 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 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:

Sem política de failover: o conjunto de back-ends qualificados depende apenas das verificações de integridade:
- 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.
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 consiste em todos os back-ends íntegros no pool ativo.
  - O pool ativo pode consistir em todos os back-ends primários íntegros ou em todos os back-ends de failover íntegros. A participação no pool ativo é determinada pela proporção de failover configurada, o número de back-ends principais íntegros e o 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 íntegro, o pool ativo consistirá em todos os back-ends principais íntegros.
- Quando não há back-ends íntegros e a política de failover do balanceador de carga está configurada para descartar novas conexões, o conjunto de back-ends qualificados fica vazio. O balanceador de carga descarta os pacotes da conexão.
- Quando não há back-ends íntegros 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 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:

2.3 Selecionar 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 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 do pacote usado para calcular o hash é 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á a padrão.
O balanceador de carga atribui novas conexões a back-ends qualificados de maneira o mais consistente 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 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.
- Quando um novo back-end qualificado é adicionado, aproximadamente 1/N possíveis novas conexões são mapeadas para ele. 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 novas conexões possíveis 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ões. 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.

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 é fechada com um pacote FIN ou RST. Qualquer nova conexão TCP sempre transmite 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 configuração de diminuição de conexão no 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 failback. Para mais informações, consulte Diminuição da conexão em 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 a exclusão de uma VM de back-end ou a remoção de 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 internos 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. Afinidade da sessão é configurada 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 dos cabeçalhos 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 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	`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 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`²

¹ Uma configuração de 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 foi configurada explicitamente.

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

² CLIENT_IP_NO_DESTINATION é um hash de uma tupla baseado 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 da sessão e passagem do balanceador de carga interno de rede.

Para saber como as diferentes configurações afinidade da sessão afetam os métodos de rastreamento de conexão e seleção de back-end, 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 balanceador de carga de rede de passagem interna de próximo salto, o balanceador de carga 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 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.

Se o número de VMs de back-end configuradas e íntegras for constante (quando o failover não estiver configurado ou quando estiver configurado, mas não ocorrerem eventos de failover ou failback), 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.
- 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. Pacotes enviados do mesmo cliente, usando o mesmo endereço IP de origem, mas endereços IP de destino diferentes, podem ser encaminhados para VMs de back-end diferentes.

Política de rastreamento da conexão

Nesta seção, descrevemos 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 do pacote que compõem 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 cinco ou três tuplas (modo PER_CONNECTION) ou pode corresponder à configuração de afinidade de sessão (modo PER_SESSION).

PER_CONNECTION. Esse é o modo padrão de acompanhamento de conexão. Esse modo usa um hash de cinco tuplas ou de três tuplas. 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 3 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 da sessão escolhida, PER_SESSION pode resultar em conexões que correspondem com mais frequência a uma entrada de tabela de rastreamento de conexão existente, 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 afinidade da sessão funcionam 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 fica 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 selecionada de persistência de conexão em back-ends não íntegros. Os pacotes subsequentes das conexões cujas entradas foram 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 da tabela de rastreamento de conexão de substituição permanecem válidas de acordo com as mesmas condições de qualquer outra entrada da tabela de rastreamento de conexão. Se o back-end não íntegro voltar a ficar íntegro, esse evento não fará 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 esteja 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 for uma VM com balanceamento de carga, ou seja, se ela não for também uma VM de back-end, as novas conexões serão entregues às VMs de back-end íntegras do balanceador de carga. No entanto, como todas as opções de afinidade de sessão dependem de pelo menos o 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 você espera.

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 independentemente 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 nas 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 período configurável adicional para que as conexões estabelecidas persistam na tabela de rastreamento de conexão do balanceador de carga quando uma das seguintes açõ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 para as ações mencionadas está 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 rede VPC Trusted Cloud.
Trusted Cloud As redes VPC encaminham fragmentos UDP à medida que chegam (sem esperar que todos os fragmentos cheguem).
As redes que não são doTrusted 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, oTrusted Cloud distribuirá 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 na seleção de back-end e no 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.