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

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

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

A seleção de back-end e o rastreamento de conexão trabalham juntos para balancear várias conexões em diferentes back-ends e rotear todos os pacotes de cada conexão para o mesmo back-end. Isso é feito com uma estratégia 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).

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

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

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, o balanceamento de carga ponderado e a configuração da política de failover.

A tabela a seguir descreve como a política de failover e o balanceamento de carga ponderado influenciam quais back-ends são qualificados.

Política de failover Balanceamento de carga ponderado Back-ends qualificados
Consulte Nenhuma política de failover, balanceamento de carga ponderado desativado.
Consulte Nenhuma política de failover, balanceamento de carga ponderado ativado.
Consulte Política de failover configurada, balanceamento de carga ponderado desativado
Consulte Política de failover configurada, balanceamento de carga ponderado ativado

Sem política de failover, balanceamento de carga ponderado desativado

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.

Nenhuma política de failover, balanceamento de carga ponderado ativado

O conjunto de back-ends qualificados depende das verificações de integridade e dos pesos e consiste no primeiro dos seguintes que não está vazio:

  • Todos os back-ends íntegros com peso diferente de zero
  • Todos os back-ends não íntegros e com peso diferente de zero
  • Todos os back-ends íntegros e com peso zero
  • Todos os back-ends não íntegros e com peso zero

Política de failover configurada, balanceamento de carga ponderado desativado

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 é definido da seguinte maneira, usando a primeira condição verdadeira desta lista ordenada:

    • 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 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, o conjunto de back-ends qualificados é definido da seguinte maneira:

    • Se a política de failover do balanceador de carga estiver configurada para descartar novas conexões quando nenhum back-end estiver íntegro, o conjunto de back-ends qualificados ficará vazio. O balanceador de carga descarta os pacotes de novas conexões.
    • Se a política de failover do balanceador de carga não estiver configurada para descartar novas conexões quando nenhum back-end estiver íntegro, as verificações de integridade não serão relevantes. Os back-ends qualificados são todos os back-ends principais.

Política de failover configurada, balanceamento de carga ponderado ativado

O conjunto de back-ends qualificados depende das verificações de integridade, dos pesos e da configuração da política de failover:

  • Quando pelo menos um back-end está íntegro e tem um peso diferente de zero, o conjunto de back-ends qualificados é definido da seguinte maneira, usando a primeira condição verdadeira desta lista ordenada:

    • Se não houver back-ends principais íntegros e com peso diferente de zero, os back-ends qualificados serão todos os back-ends de failover íntegros e com peso diferente de zero.
    • Se não houver back-ends de failover íntegros e com peso diferente de zero, os back-ends qualificados serão todos os back-ends principais íntegros e com peso diferente de zero.
    • Se a taxa de failover for definida como 0.0 (o valor padrão), os back-ends qualificados serão todos os back-ends primários íntegros e com peso diferente de zero.
    • Se a proporção do número de back-ends principais íntegros e com peso diferente de zero em comparação com o número total de back-ends principais for maior ou igual à proporção de failover configurada, os back-ends qualificados consistirão em todos os back-ends principais íntegros e com peso diferente de zero.
    • Os back-ends qualificados consistem em todos os back-ends de failover íntegros e com peso diferente de zero.
  • Quando não há back-ends íntegros e com peso diferente de zero, o conjunto de back-ends qualificados é definido da seguinte maneira:

    • Se a política de failover do balanceador de carga estiver configurada para descartar novas conexões quando nenhum back-end estiver íntegro, o conjunto de back-ends qualificados ficará vazio. O balanceador de carga descarta os pacotes de novas conexões.
    • Se a política de failover do balanceador de carga não estiver configurada para descartar novas conexões quando nenhum back-end estiver íntegro, o conjunto de back-ends qualificados será o primeiro dos seguintes que não estiver vazio:

      • Todos os back-ends primários não íntegros e com peso diferente de zero
      • Todos os back-ends de failover não íntegros e com peso diferente de zero
      • Todos os back-ends primários íntegros e com peso zero
      • Todos os back-ends de failover íntegros e com peso zero
      • Todos os back-ends primários não íntegros e com peso zero
      • Todos os back-ends de failover não íntegros e com peso zero

2.2 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. O balanceamento de carga ponderado altera a forma como os back-ends qualificados são mapeados para o círculo, de modo que os back-ends com ponderações mais altas têm mais chances de serem selecionados, proporcionalmente às ponderações.

Ao processar um pacote para uma conexão que não está na tabela de rastreamento de conexões, 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.

  • Os dois exemplos a seguir mostram como o balanceamento de carga ponderado afeta a seleção de um back-end qualificado:

    • Se o serviço de back-end tiver dois back-ends qualificados, o primeiro com peso 1 e o segundo com peso 4, o primeiro back-end qualificado terá uma probabilidade de seleção de 20% (1÷(1+4)), e o segundo terá uma probabilidade de seleção de 80% (4÷(1+4)).

    • Se o serviço de back-end tiver três back-ends qualificados (a com peso 0, b com peso 2 e c com peso 6), o back-end a terá uma probabilidade de seleção de 0% (0÷(0+2+6)), o back-end b terá uma probabilidade de seleção de 25% (2÷(0+2+6)) e o back-end c terá uma probabilidade de seleção de 75% (6÷(0+2+6)).

  • 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 ou os pesos deles mudem. 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, nas seguintes situações:

      • Se o balanceamento de carga ponderado não estiver configurado, quando o conjunto de back-ends qualificados não mudar.

      • Se o balanceamento de carga ponderado estiver configurado, quando o conjunto de back-ends qualificados não mudar e o peso de cada back-end qualificado permanecer constante.

    • O balanceador de carga distribui possíveis novas conexões entre os back-ends qualificados da maneira mais justa possível:

      • Se o balanceamento de carga ponderado não estiver configurado, aproximadamente 1/N novas conexões possíveis serão mapeadas para cada back-end qualificado, em que N é a contagem de back-ends qualificados.

      • Se o balanceamento de carga ponderado estiver configurado, a proporção de possíveis novas conexões que mapeiam para cada back-end qualificado será aproximadamente: o peso de um back-end qualificado dividido pela soma de todos os pesos de back-end qualificados.

      • Se um back-end qualificado for adicionado, removido ou tiver a ponderação alterada, hashing consistente vai minimizar a interrupção dos mapeamentos para os outros back-ends qualificados. Ou seja, a maioria das conexões que mapeiam para outros back-ends qualificados continuará mapeando para o mesmo 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 de tabela de rastreamento de conexão se a afinidade da sessão configurada for compatível com o rastreamento de conexão para o protocolo do pacote.

  • Se a afinidade da sessão configurada não for compatível com o rastreamento de conexão para o protocolo do pacote, pule esta etapa.

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

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

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 por 60 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 da conexão em failover e failback estiver desativada, o balanceador de carga vai remover todas as entradas na tabela de rastreamento de conexão quando os back-ends qualificados mudarem de primário para back-ends de failover (failover) ou de failover para back-ends primários (failback). Para mais informações, consulte Diminuição da conexão no failover e no 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 externa 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 externa 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 TCP/UDP são usados para calcular o hash.

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

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

NONE2

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
1 Essas afinidades de sessão são compatíveis com balanceadores de carga de rede de passagem externa baseados em serviço de back-end. Os balanceadores de carga de rede de passagem externa baseados em pool de destino não usam serviços de back-end e oferecem suporte a menos opções de afinidade da sessão. Para balanceadores de carga de rede de passagem externa baseados em pool de destino, defina o parâmetro session affinity em cada pool de destino.

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

Para informações sobre 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.

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 externa. Uma política de rastreamento de conexão inclui as seguintes configurações:

Modo de rastreamento de conexão

Quando o rastreamento de conexões é possível, 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 pacote que compõem cada tupla de conexão depende do modo de rastreamento de conexão e da afinidade da sessão.

Os balanceadores de carga de rede de passagem externa são compatíveis com o rastreamento de conexão com base no protocolo e nas opções de afinidade de sessão:

  • As conexões TCP são sempre rastreáveis, para todas as opções de afinidade da sessão.

  • As conexões UDP, ESP e GRE podem ser rastreadas para todas as opções de afinidade de sessão, exceto NONE.

  • Todos os outros protocolos, como ICMP e ICMPv6, não podem ser rastreados por conexão.

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
Padrão

(NONE)

TCP e UDP não fragmentado: hash de cinco tuplas

UDP fragmentado e todos os outros protocolos: hash de três tuplas

  • TCP: rastreamento de conexão de cinco tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP: rastreamento de conexão de cinco tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, IP de destino

(CLIENT_IP)

Todos os protocolos: hash de duas tuplas
  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP, UDP, ESP, GRE: rastreamento de conexão de duas tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, IP de destino, protocolo

(CLIENT_IP_PROTO)

Todos os protocolos: hash de três tuplas
  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP, UDP, ESP, GRE: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo

(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 de cinco tuplas
  • Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado

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

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

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
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão)

Todos os outros protocolos: as conexões nunca permanecem 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

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

TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão)

ESP, GRE, UDP: as conexões permanecem em back-ends não íntegros se a afinidade da sessão não for NONE

ICMP, ICMPv6:não aplicável porque não é possível acompanhar a conexão.

Essa opção só deve ser usada para casos de uso avançados.

Não é possível configurar

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

Sempre que uma conexão TCP com rastreamento de cinco tuplas persiste em um back-end não íntegro:

  • 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 aos pacotes, o cliente poderá tentar novamente com uma nova conexão, permitindo que o balanceador de carga selecione um back-end íntegro e diferente. Os pacotes TCP SYN sempre selecionam um back-end novo e íntegro.

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

Tempo limite de inatividade

As entradas nas tabelas de rastreamento de conexão expiram 60 segundos após o balanceador de carga processar o último pacote que corresponde à entrada. Não é possível modificar esse valor de tempo limite ocioso.

Balanceamento de carga ponderado

O balanceamento de carga ponderado para balanceadores de carga de rede de passagem externa usa informações de peso informadas por uma verificação de integridade HTTP. O balanceamento de carga ponderado requer que você configure todos os itens a seguir:

  • A política de localidade do balanceador de carga do serviço de back-end (localityLbPolicy) precisa ser WEIGHTED_MAGLEV.
  • O serviço de back-end precisa usar uma verificação de integridade HTTP.
  • As respostas de verificação de integridade de cada VM de back-end ou endpoint de back-end precisam conter um cabeçalho de resposta HTTP personalizado. O nome do campo de cabeçalho da resposta é X-Load-Balancing-Endpoint-Weight, e os valores válidos variam de 0 a 1000.

Se você precisar usar o mesmo grupo de instâncias ou NEG como back-end para dois ou mais serviços de back-end, recomendamos a seguinte estratégia para que cada uma das instâncias ou endpoints de back-end comuns possa fornecer informações de peso exclusivas para cada serviço de back-end:

  • Use uma verificação de integridade HTTP exclusiva para cada serviço de back-end. Por exemplo, use um parâmetro exclusivo de verificação de integridade request-path.
  • Configure instâncias ou endpoints de back-end para responder com informações de peso adequadas para cada verificação de integridade.

Ao usar o balanceamento de carga ponderado, o balanceador de carga classifica as VMs ou os endpoints de back-end, primeiro com base em um peso maior ou igual a zero e depois com base nas verificações de integridade. O status da verificação de integridade é determinado pelos critérios de sucesso para verificações de integridade HTTP, HTTPS e HTTP/2.

Peso Saudável ou não saudável Classificar
Peso maior que zero Íntegro Primeira opção
Peso maior que zero Não íntegro Segunda escolha
Peso igual a zero Íntegro Terceira escolha
Peso igual a zero Não íntegro Quarta (última) opção

Para mais informações sobre como o balanceamento de carga ponderado influencia quais back-ends são qualificados, consulte as etapas Identificar back-ends qualificados e Selecionar um back-end qualificado na seção Seleção de back-end e rastreamento de conexão.

O balanceamento de carga ponderado pode ser usado nos seguintes cenários:

  • Se algumas conexões processarem mais dados do que outras ou se algumas conexões ficarem mais tempo do que outras, a distribuição da carga do back-end pode ficar desigual. Ao sinalizar um peso por instância mais baixo, uma instância com alta carga pode reduzir a participação de novas conexões, enquanto continua atendendo as conexões atuais.

  • Se um back-end estiver sobrecarregado e a atribuição de mais conexões puder interromper as conexões existentes, eles não atribuirão peso zero a si mesmo. Ao sinalizar o peso zero, uma instância de back-end deixa de fornecer novas conexões, mas continua a atender as atuais.

  • Se um back-end estiver drenando conexões existentes antes da manutenção, ele atribuirá zero peso a si mesmo. Ao sinalizar o peso zero, a instância de back-end deixa de atender novas conexões, mas continua a atender as atuais.

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

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 externa baseados em serviço de back-end podem processar pacotes UDP fragmentados e não fragmentados. Se o aplicativo usar pacotes UDP fragmentados, lembre-se do seguinte:

  • Os pacotes UDP podem se tornar fragmentados antes de chegar a uma rede VPC Google Cloud.
  • Google Cloud As redes VPC encaminham fragmentos UDP à medida que chegam (sem esperar que todos os fragmentos cheguem).
  • As redes que não são doGoogle Cloud e os equipamentos de rede locais podem encaminhar fragmentos UDP assim que chegarem, atrasar pacotes UDP fragmentados até que todos os fragmentos tenham chegado ou descartar pacotes UDP fragmentados. Para ver mais detalhes, consulte a documentação da operadora ou equipamento de rede.

Se você espera pacotes UDP fragmentados e precisa encaminhá-los para os mesmos back-ends, use as seguintes regras de encaminhamento e parâmetros de configuração do serviço de back-end:

  • Configuração da regra de encaminhamento: use apenas uma regra de encaminhamento UDP ou L3_DEFAULT por endereço IP com balanceamento de carga e configure a regra de encaminhamento para aceitar o tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento. Mesmo que os pacotes fragmentados (exceto o primeiro fragmento) não tenham uma porta de destino, a configuração da regra de encaminhamento para processar o tráfego para todas as portas também a configura para receber fragmentos UDP que não têm informações de porta. Para configurar todas as portas, use a Google Cloud CLI para definir --ports=ALL ou use a API para definir allPorts como True

  • Configuração do serviço de back-end: defina a afinidade da sessão do serviço de back-end como CLIENT_IP (hash de duas tuplas) ou CLIENT_IP_PROTO (três tuplas) hash) para que o mesmo back-end seja selecionado para pacotes UDP que incluem informações de porta e fragmentos UDP (que não sejam o primeiro fragmento) sem informações de porta. Defina o modo de rastreamento de conexão do serviço de back-end como PER_SESSION para que as entradas da tabela de rastreamento de conexão sejam criadas usando os mesmos hashes de duas ou três tuplas.

Failover

É possível configurar um balanceador de carga de rede de passagem externa para distribuir conexões entre instâncias de VM ou endpoints em back-ends primários (grupos de instâncias ou NEGs) e, em seguida, alternar, se necessário, para usar back-ends de failover. Com o failover, você garante um método para aumentar a disponibilidade e ter maior controle sobre como gerenciar a carga de trabalho quando os back-end principais não estiverem íntegras.

Por padrão, quando você adiciona um back-end a um serviço de back-end do balanceador de carga de rede externo, esse back-end é primário. Para designá-lo como back-end 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 Visão geral do failover para balanceadores de carga de rede de passagem externa.

A seguir