Distribuição de tráfego para balanceadores de carga de rede de encaminhamento interno

Esta página explica os conceitos sobre como os balanceadores de carga de rede de encaminhamento interno distribuem o tráfego.

Seleção de back-end e acompanhamento de ligações

A seleção de back-end e o acompanhamento de ligações funcionam em conjunto para equilibrar várias ligações em diferentes back-ends e encaminhar todos os pacotes de cada ligação para o mesmo back-end. Isto é conseguido com uma estratégia de duas partes. Primeiro, é selecionado um back-end através da hash consistente. Em seguida, esta seleção é registada numa tabela de acompanhamento de associações.

Os passos seguintes captam o processo de seleção e acompanhamento da ligação de back-end.

1. Verifique se existe uma entrada na tabela de acompanhamento de associações para usar um back-end selecionado anteriormente

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

O balanceador de carga tenta fazer corresponder cada pacote com balanceamento de carga a uma entrada na respetiva tabela de acompanhamento de ligações através do seguinte processo:

• Se o pacote for um pacote TCP com o sinalizador SYN:

  • Se o modo de acompanhamento de ligações do equilibrador de carga for PER_CONNECTION, continue para o passo Identifique back-ends elegíveis. No modo de acompanhamento PER_CONNECTION, um pacote TCP com a flag SYN representa sempre uma nova ligação, independentemente da afinidade de sessão configurada.

  • Se o modo de monitorização de ligações do balanceador de carga for PER_SESSION e a afinidade de sessão for NONE ou CLIENT_IP_PORT_PROTO, continue para o passo Identifique back-ends elegíveis. No PER_SESSIONmodo de acompanhamento, um pacote TCP com o indicador SYN representa uma nova ligação apenas quando usa uma das opções de afinidade de sessão de 5 tuplos (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 acompanhamento de ligações existente. A tupla de associação (um conjunto de características dos pacotes) usada para comparar o pacote com as entradas da tabela de monitorização de associações existentes depende do modo de monitorização de associações e da afinidade de sessão que configurou. Para obter informações sobre a tupla de ligação usada para o acompanhamento de ligações, consulte a tabela na secção Modo de acompanhamento de ligações.

  • Se o pacote corresponder a uma entrada da tabela de acompanhamento de ligações, o equilibrador de carga envia o pacote para o back-end selecionado anteriormente.

  • Se o pacote não corresponder a uma entrada da tabela de acompanhamento de ligações, avance para o passo Identifique back-ends elegíveis.

  Para obter informações sobre durante quanto tempo uma entrada da tabela de acompanhamento de ligações persiste e em que condições persiste, consulte o passo Crie uma entrada da tabela de acompanhamento de ligações.

2. Selecione um back-end elegível para uma nova associação

Para uma nova ligação, o balanceador de carga usa o algoritmo de hash consistente para selecionar um back-end entre os back-ends elegíveis.

Os passos seguintes descrevem o processo de seleção de um back-end elegível para uma nova ligação e, em seguida, registam essa ligação numa tabela de acompanhamento de ligações.

2.1 Identifique back-ends elegíveis

Este passo modela que back-ends são candidatos a receber novas ligações, tendo em consideração a configuração da política de saúde e failover:

Sem política de alternativa

O conjunto de back-ends elegíveis depende apenas das verificações de funcionamento:

• Quando, pelo menos, um back-end está em bom estado de funcionamento, todos os back-ends elegíveis estão em bom estado de funcionamento.

• Quando todos os back-ends estão em mau estado, os back-ends elegíveis são todos os back-ends.

Política de alternativa configurada

O conjunto de back-ends elegíveis depende da configuração das verificações de funcionamento e da política de comutação por falha:

• Quando, pelo menos, um back-end está em bom estado, os back-ends elegíveis são definidos da seguinte forma, usando a primeira condição verdadeira desta lista ordenada:

  • Se não existirem back-ends principais em bom estado de funcionamento, os back-ends elegíveis são todos os back-ends de comutação por falha em bom estado de funcionamento.
  • Se não existirem back-ends de comutação por falha em bom estado de funcionamento, os back-ends elegíveis são todos os back-ends principais em bom estado de funcionamento.
  • Se a taxa de comutação por falha estiver definida como 0.0 (o valor predefinido), os back-ends elegíveis são todos os back-ends principais em bom estado.
  • Se a proporção do número de back-ends principais em bom estado de funcionamento em comparação com o número total de back-ends principais for superior ou igual à proporção de comutação por falha configurada, os back-ends elegíveis são todos os back-ends principais em bom estado de funcionamento.
  • Os back-ends elegíveis são todos os back-ends de comutação por falha em bom estado de funcionamento.

• Quando não existem back-ends em bom estado de funcionamento, os back-ends elegíveis são definidos da seguinte forma:

  • Se a política de comutação por falha do balanceador de carga estiver configurada para rejeitar novas ligações quando não existirem back-ends em bom estado, o conjunto de back-ends elegíveis está vazio. O balanceador de carga rejeita os pacotes de novas ligações.
  • Se a política de comutação por falha do balanceador de carga não estiver configurada para rejeitar novas ligações quando nenhum back-end estiver em bom estado, as verificações de funcionamento não são relevantes. Os backends elegíveis são todos os backends principais.

2.2 Ajuste os back-ends elegíveis para afinidade zonal

Este passo é ignorado se qualquer uma das seguintes afirmações for verdadeira:

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

Se a afinidade zonal estiver ativada, um cliente for compatível com a afinidade zonal e ocorrer uma correspondência zonal, as novas ligações do cliente são encaminhadas para um conjunto ajustado de back-ends elegíveis. Para mais informações, consulte o seguinte:

• Como ZONAL_AFFINITY_STAY_WITHIN_ZONE funciona

• Como funcionam o ZONAL_AFFINITY_SPILL_CROSS_ZONE e a taxa de transbordo

2.3 Selecione um back-end elegível

O balanceador de carga usa a hash consistente para selecionar um back-end elegível. O balanceador de carga mantém hashes dos back-ends elegíveis, mapeados para um círculo unitário. Quando processa um pacote para uma ligação que não está na tabela de monitorização de ligações, o equilibrador de carga calcula um hash das caraterísticas do pacote e mapeia esse hash para o mesmo círculo unitário, selecionando um back-end elegível na circunferência do círculo. O conjunto de caraterísticas dos pacotes usado para calcular o hash do pacote é definido pela definição de afinidade da sessão.

• Se uma afinidade de sessão não for configurada explicitamente, a afinidade de sessão NONE é a predefinição.

• O balanceador de carga atribui novas ligações a back-ends elegíveis de uma forma tão consistente quanto possível, mesmo que o número de back-ends elegíveis mude. As seguintes vantagens da hash consistente mostram como o equilibrador de carga seleciona back-ends elegíveis para possíveis novas ligações que não têm entradas na tabela de acompanhamento de ligações:

  • O balanceador de carga seleciona o mesmo back-end para todas as novas ligações possíveis que tenham características de pacotes idênticas, conforme definido pela afinidade de sessão, se o conjunto de back-ends elegíveis não mudar.

  • Quando é adicionado um novo back-end elegível, são mapeadas aproximadamente 1/N novas ligações possíveis para o back-end adicionado recentemente. Nesta situação, N é a quantidade de backends elegíveis depois de o novo backend ser adicionado.

  • Quando um back-end elegível é removido, aproximadamente 1/N novas ligações possíveis são mapeadas para um dos N-1 back-ends restantes. Nesta situação, N é a contagem de back-ends antes de o back-end elegível ser removido.

2.4 Crie uma entrada na tabela de acompanhamento de associações

Depois de selecionar um back-end, o balanceador de carga cria uma entrada na tabela de acompanhamento de ligações. A entrada da tabela de acompanhamento da ligação mapeia as caraterísticas dos pacotes para o back-end selecionado. Os campos de cabeçalho de pacotes usados para este mapeamento dependem do modo de acompanhamento de ligações e da afinidade de sessão que configurou.

O balanceador de carga remove as entradas da tabela de acompanhamento de ligações de acordo com as seguintes regras:

• Uma entrada da tabela de monitorização de ligações é removida após a ligação ficar inativa. A menos que configure um limite de tempo de inatividade personalizado, o equilibrador de carga usa um limite de tempo de inatividade predefinido de 600 segundos. Para mais informações, consulte a secção Limite de tempo de inatividade.

• As entradas da tabela de acompanhamento de associações não são removidas quando uma associação TCP é fechada com um pacote FIN ou RST. Qualquer ligação TCP nova transporta sempre o indicador SYN e é processada conforme descrito no passo Verifique se existe uma entrada na tabela de acompanhamento de ligações.

• Se for configurada uma política de comutação por falha e a definição de esgotamento de ligações na comutação por falha e na reversão estiver desativada, o equilibrador de carga remove todas as entradas na tabela de monitorização de ligações quando os back-ends elegíveis mudam de back-ends primários para back-ends de comutação por falha (comutação por falha) ou mudam de back-ends de comutação por falha para back-ends primários (reversão). Para mais informações, consulte o artigo Drenagem de ligações em caso de comutação por falha e recuperação.

• As entradas na tabela de acompanhamento de ligações podem ser removidas se um back-end ficar em mau estado. Este comportamento depende do modo de monitorização de ligações, do protocolo e da definição de persistência de ligações em back-ends não íntegros. Para mais informações, consulte o artigo Persistência da ligação em back-ends não íntegros.

• As entradas na tabela de acompanhamento de ligações são removidas após o limite de tempo de esgotamento de ligações que ocorre após um evento, como a eliminação de uma VM de back-end ou a remoção de uma VM de back-end de um grupo de instâncias ou um NEG. Para mais informações, consulte o artigo Ative a eliminação de ligações.

Afinidade de sessão

A afinidade de sessão controla a distribuição de novas ligações de clientes aos back-ends do balanceador de carga. Os equilibradores de carga de passagem internos usam a afinidade de sessão para selecionar um back-end a partir de um conjunto de back-ends elegíveis, conforme descrito nos passos Identificar back-ends elegíveis e Selecionar um back-end elegível na secção Seleção de back-ends e acompanhamento de ligações. Configura a afinidade de sessão no serviço de back-end e não em cada grupo de instâncias de back-end ou NEG.

Os balanceadores de carga de rede de encaminhamento interno suportam as seguintes definições de afinidade de sessão. Cada definição de afinidade de sessão usa a aplicação de hash consistente para selecionar um back-end elegível. A definição de afinidade de sessão determina que campos dos cabeçalhos de IP e da camada 4 são usados para calcular o hash.

Para saber como as diferentes definições de afinidade de sessão afetam a seleção de back-end e os métodos de acompanhamento de ligações, consulte a tabela na secção Modo de acompanhamento de ligações.

Afinidade de sessão e balanceador de carga de rede de passagem interna de salto seguinte

Quando um balanceador de carga de rede de passagem interno é 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 alternativa, o endereço IP de destino do pacote pode ser qualquer endereço IP que se enquadre no intervalo de destino da rota estática.

A seleção de um back-end elegível depende do cálculo de um hash das caraterísticas dos pacotes. Exceto para a afinidade de sessão CLIENT_IP_NO_DESTINATION (hash de 1 tuplo), 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 ligações possíveis que tenham características de pacotes idênticas, conforme definido pela afinidade de sessão, se o conjunto de back-ends elegíveis não mudar. Se 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 CLIENT_IP_NO_DESTINATIONafinidade de sessão.

Política de monitorização de ligações

Esta secção descreve as definições que controlam o comportamento de monitorização de ligações dos balanceadores de carga de encaminhamento interno. Uma política de acompanhamento de ligações inclui as seguintes definições:

• Modo de acompanhamento de ligações
• Persistência da ligação em back-ends em mau estado de funcionamento
• Limite de tempo de inatividade

Modo de acompanhamento de ligações

A tabela de monitorização de ligações do balanceador de carga mapeia tuplos de ligações para back-ends selecionados anteriormente numa tabela hash. O conjunto de caraterísticas dos pacotes que compõem cada tuplo de ligação é determinado pelo modo de acompanhamento de ligações e pela afinidade de sessão.

Os equilibradores de carga de passagem internos monitorizam as ligações para todos os protocolos que suportam.

O modo de acompanhamento de ligações refere-se à granularidade de cada tuplo de ligação na tabela de acompanhamento de ligações do equilibrador de carga. A tupla de ligação pode ser de 5 tuplas ou 3 tuplas (modo PER_CONNECTION) ou pode corresponder à definição de afinidade da sessão (modo PER_SESSION).

• PER_CONNECTION. Este é o modo de acompanhamento de ligações predefinido. Este modo de acompanhamento de ligações usa um hash de 5 tuplos ou um hash de 3 tuplos. Os pacotes não fragmentados que incluem informações de portas, como pacotes TCP e pacotes UDP não fragmentados, são monitorizados com hashes de 5 tuplos. Todos os outros pacotes são monitorizados com hashes de 3 tuplos.

• PER_SESSION. Este modo de acompanhamento de ligações usa um hash que consiste nas mesmas caraterísticas de pacotes usadas pelo hash de afinidade de sessão. Consoante a afinidade de sessão escolhida, PER_SESSION pode resultar em ligações que correspondem com mais frequência a uma entrada da tabela de acompanhamento de ligações existente, o que reduz a frequência com que um back-end tem de ser selecionado pelo hash de afinidade de sessão.

A tabela seguinte resume como o modo de acompanhamento de ligações e a afinidade de sessão funcionam em conjunto para encaminhar todos os pacotes de cada ligação para o mesmo back-end.

Para saber como alterar o modo de acompanhamento de ligações, consulte o artigo Configure uma política de acompanhamento de ligações.

Persistência da ligação em back-ends em mau estado de funcionamento

As definições de persistência da ligação controlam se uma ligação existente persiste numa VM ou num ponto final de back-end selecionado depois de esse back-end ficar em mau estado, desde que o back-end permaneça no grupo de back-end configurado do equilibrador de carga (num grupo de instâncias ou num NEG).

Estão disponíveis as seguintes opções de persistência de ligação:

• DEFAULT_FOR_PROTOCOL (predefinição)
• NEVER_PERSIST
• ALWAYS_PERSIST

A tabela seguinte resume as opções de persistência de ligação e como as ligações persistem para diferentes protocolos, opções de afinidade de sessão e modos de acompanhamento.

Para saber como alterar o comportamento de persistência da associação, consulte o artigo Configure uma política de acompanhamento de associações.

Limite de tempo de inatividade

Uma entrada da tabela de monitorização de ligações é removida após a ligação estar inativa durante um determinado período. A menos que configure um limite de tempo de inatividade personalizado, o balanceador de carga usa um valor predefinido de limite de tempo de inatividade de 600 segundos (10 minutos).

A tabela seguinte mostra os valores de tempo limite de inatividade configuráveis mínimo e máximo para diferentes combinações de afinidade de sessão e definições do modo de acompanhamento de ligações.

Para saber como alterar o valor do tempo limite de inatividade, consulte o artigo Configure uma política de acompanhamento de ligações.

Ligações para implementações de cliente único

Quando testar ligações ao endereço IP de um Network Load Balancer de encaminhamento interno que só tem um cliente, deve ter em atenção o seguinte:

• Se a VM cliente não for uma VM com balanceamento de carga, ou seja, também não for uma VM de back-end, as novas ligações são fornecidas às VMs de back-end em bom estado do balanceador de carga. No entanto, uma vez que todas as opções de afinidade de sessão dependem, pelo menos, do endereço IP do sistema cliente, as ligações do mesmo cliente podem ser distribuídas à mesma VM de back-end com mais frequência do que o esperado.

  Na prática, isto significa que não pode monitorizar com precisão a distribuição de tráfego através de um Network Load Balancer de encaminhamento interno estabelecendo ligação ao mesmo a partir de um único cliente. O número de clientes necessários para monitorizar a distribuição de tráfego varia consoante o tipo de balanceador de carga, o tipo de tráfego e o número de back-ends em bom estado.

• Se a VM do cliente também for uma VM de back-end do balanceador de carga, as ligações enviadas para o endereço IP da regra de encaminhamento do balanceador de carga são sempre respondidas pela mesma VM de back-end (que também é a VM do cliente). Isto acontece independentemente de a VM de back-end estar em bom estado. Isto acontece para todo o tráfego enviado para o endereço IP do balanceador de carga e não apenas para o tráfego no protocolo e nas portas especificados na regra de encaminhamento interno do balanceador de carga.

  Para mais informações, consulte o artigo sobre como enviar pedidos a partir de VMs com balanceamento de carga.

Drenagem da ligação

A eliminação gradual de ligações oferece uma quantidade configurável de tempo adicional para que as ligações estabelecidas persistam na tabela de acompanhamento de ligações do equilibrador de carga quando ocorre uma das seguintes ações:

• Uma instância de máquina virtual (VM) é removida de um grupo de instâncias de back-end (isto inclui o abandono de uma instância num grupo de instâncias geridas de back-end)
• Uma VM é parada ou eliminada (isto inclui ações automáticas, como atualizações incrementais ou redução de um grupo de instâncias geridas de back-end)
• Um ponto final é removido de um grupo de pontos finais de rede (NEG) de back-end

Por predefinição, a drenagem de ligações para as ações mencionadas acima está desativada. Para obter informações sobre como o esgotamento de ligações é acionado e como ativá-lo, consulte o artigo Ativar o esgotamento de ligações.

Fragmentação UDP

• Os pacotes UDP podem ficar fragmentados antes de chegarem 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 nãoTrusted Cloud e o equipamento de rede no local podem encaminhar fragmentos UDP à medida que chegam, atrasar pacotes UDP fragmentados até que todos os fragmentos tenham chegado ou rejeitar pacotes UDP fragmentados. Para ver detalhes, consulte a documentação do fornecedor de rede ou do equipamento de rede.

Se esperar pacotes UDP fragmentados e precisar de os encaminhar para os mesmos back-ends, use os seguintes parâmetros de configuração do serviço de back-end e da regra de encaminhamento:

• Configuração da regra de encaminhamento: use apenas uma 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.UDP Isto garante que todos os fragmentos chegam à mesma regra de encaminhamento. Embora 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 CLI Google Cloud 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 2 tuplos) ou CLIENT_IP_PROTO (hash de 3 tuplos) para que o mesmo back-end seja selecionado para pacotes UDP que incluem informações de portas e fragmentos UDP (exceto o primeiro fragmento) que não têm informações de portas. Defina o modo de acompanhamento de ligações do serviço de back-end como PER_SESSION para que as entradas da tabela de acompanhamento de ligações sejam criadas através dos mesmos hashes de 2 ou 3 tuplos.

Failover

Um balanceador de carga de encaminhamento interno permite-lhe designar alguns back-ends como back-ends de comutação por falha. Estes back-ends só são usados quando o número de VMs em bom estado nos grupos de instâncias do back-end principal tiver ficado abaixo de um limite configurável. Por predefinição, se todas as VMs principais e de ativação pós-falha não estiverem em bom estado, como último recurso, o balanceador de carga Trusted Cloud distribui novas ligações apenas entre todas as VMs principais.

Quando adiciona um back-end ao serviço de back-end de um Network Load Balancer de passagem interno, por predefinição, esse back-end é um back-end principal. Pode designar um back-end como um back-end de alternativa quando o adiciona ao serviço de back-end do equilibrador de carga ou editando o serviço de back-end mais tarde.

Para mais informações sobre como a comutação por falha é usada para a seleção de back-ends e o acompanhamento de ligações, consulte os passos Identifique back-ends elegíveis e Crie uma entrada na tabela de acompanhamento de ligações na secção Seleção de back-ends e acompanhamento de ligações.

Para mais informações sobre o funcionamento da comutação por falha, consulte o artigo Comutação por falha para balanceadores de carga de rede de passagem interna.

O que se segue?

• Para configurar e testar um balanceador de carga de rede de encaminhamento interno que usa a comutação por falha, consulte o artigo Configure a comutação por falha para balanceadores de carga de rede de encaminhamento interno.
• Para configurar e testar um balanceador de carga de rede de encaminhamento interno, consulte o artigo Configure um balanceador de carga de rede de encaminhamento interno.