Esta página explica os conceitos sobre como os balanceadores de carga de rede de encaminhamento externo 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 acompanhamentoPER_CONNECTION, um pacote TCP com a flagSYNrepresenta 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_SESSIONe a afinidade de sessão forNONEouCLIENT_IP_PORT_PROTO, continue para o passo Identifique back-ends elegíveis. NoPER_SESSIONmodo de acompanhamento, um pacote TCP com o indicadorSYNrepresenta uma nova ligação apenas quando usa uma das opções de afinidade de sessão de 5 tuplos (NONEouCLIENT_IP_PORT_PROTO).
Se a afinidade de sessão configurada não suportar a monitorização de ligações para o protocolo do pacote, avance para o passo Identifique back-ends elegíveis. Para ver informações sobre os protocolos que são acompanháveis por ligações, consulte a tabela na secção Modo de acompanhamento de ligações.
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 o estado, o equilíbrio de carga ponderado e a configuração da política de comutação por falha.
A tabela seguinte descreve como a política de comutação por falha e o balanceamento de carga ponderado influenciam os back-ends elegíveis.
| Política de comutação por falha | Balanceamento de carga ponderado | Back-ends elegíveis |
|---|---|---|
| Consulte Nenhuma política de comutação por falha, equilíbrio de carga ponderado desativado | ||
| Consulte Nenhuma política de comutação por falha, equilíbrio de carga ponderado ativado | ||
| Consulte Política de comutação por falha configurada, equilíbrio de carga ponderado desativado | ||
| Consulte Política de comutação por falha configurada, equilíbrio de carga ponderado ativado |
Sem política de comutação por falha, balanceamento de carga ponderado desativado
O conjunto de back-ends elegíveis depende apenas das verificações de funcionamento:
Quando, pelo menos, um back-end está em bom estado, o conjunto de back-ends elegíveis consiste em todos os back-ends em bom estado.
Quando todos os back-ends estão em mau estado, o conjunto de back-ends elegíveis consiste em todos os back-ends.
Sem política de comutação por falha, balanceamento de carga ponderado ativado
O conjunto de back-ends elegíveis depende das verificações de funcionamento e dos pesos e consiste no primeiro dos seguintes que não esteja vazio:
- Todos os back-ends com peso diferente de zero e em bom estado de funcionamento
- Todos os back-ends em mau estado de funcionamento com peso diferente de zero
- Todos os back-ends com peso zero em bom estado de funcionamento
- Todos os back-ends em mau estado de funcionamento e com peso zero
Política de alternativa configurada, equilíbrio de carga ponderado desativado
O conjunto de back-ends elegíveis depende das verificações de funcionamento e da configuração da política de comutação por falha:
Quando, pelo menos, um back-end está em bom estado, o conjunto de back-ends elegíveis é definido da seguinte forma, usando a primeira condição que é 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 em caso de 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 consistem em todos os back-ends principais em bom estado de funcionamento.
- Os back-ends elegíveis consistem em 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, o conjunto de back-ends elegíveis é definido 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.
Política de comutação por falha configurada, equilíbrio de carga ponderado ativado
O conjunto de back-ends elegíveis depende das verificações de funcionamento, dos pesos e da configuração da política de comutação por falha:
Quando, pelo menos, um back-end está em bom estado e tem um peso diferente de zero, o conjunto de back-ends elegíveis é definido da seguinte forma, usando a primeira condição que é verdadeira desta lista ordenada:
- Se não existirem back-ends principais saudáveis com peso diferente de zero, os back-ends elegíveis são todos os back-ends de alternativa saudáveis com peso diferente de zero.
- Se não existirem back-ends de substituição saudáveis com peso diferente de zero, os back-ends elegíveis são todos os back-ends principais saudáveis com peso diferente de zero.
- Se a taxa de comutação por falha estiver definida como
0.0(o valor predefinido), os servidores de back-end elegíveis são todos os servidores de back-end principais com peso diferente de zero e em bom estado. - Se a relação entre o número de backends principais com peso diferente de zero e em bom estado de funcionamento, em comparação com o número total de backends principais, for superior ou igual à relação de comutação por falha configurada, os backends elegíveis consistem em todos os backends principais com peso diferente de zero e em bom estado de funcionamento.
- Os back-ends elegíveis consistem em todos os back-ends de comutação por falha saudáveis e com peso diferente de zero.
Quando não existem back-ends com peso diferente de zero em bom estado, o conjunto de back-ends elegíveis é definido 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 equilibrador de carga não estiver configurada para rejeitar novas ligações quando nenhum back-end estiver em bom estado, o conjunto de back-ends elegíveis é o primeiro dos seguintes que não estiver vazio:
- Todos os back-ends principais em mau estado de funcionamento com peso diferente de zero
- Todos os back-ends de substituição em mau estado de funcionamento com peso diferente de zero
- Todos os back-ends principais saudáveis e com peso zero
- Todos os back-ends saudáveis e sem peso de comutação por falha
- Todos os back-ends principais em mau estado de funcionamento e com peso zero
- Todos os back-ends em mau estado de funcionamento, sem ponderação para a comutação por falha
2.2 Selecione um back-end elegível
O balanceador de carga usa a aplicação de hash consistente para selecionar um back-end elegível. O balanceador de carga mantém hashes de back-ends elegíveis, mapeados para um círculo unitário. O equilíbrio de carga ponderado altera a forma como os backends elegíveis são mapeados para o círculo, de modo que os backends com ponderações mais elevadas têm maior probabilidade de serem selecionados, proporcionalmente às respetivas ponderações.
Quando processa um pacote para uma ligação que não está na tabela de acompanhamento de ligações, o balanceador 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 características dos pacotes usado para calcular o hash dos pacotes é definido pela definição de afinidade de sessão.
Se uma afinidade de sessão não for configurada explicitamente, a afinidade de sessão
NONEé a predefinição.Os dois exemplos seguintes mostram como o equilíbrio de carga ponderado afeta a seleção de um back-end elegível:
Se o serviço de back-end tiver dois back-ends elegíveis, o primeiro com um peso de
1e o segundo com um peso de4, o primeiro back-end elegível tem uma probabilidade de seleção de 20% (1÷(1+4)) e o segundo back-end elegível tem uma probabilidade de seleção de 80% (4÷(1+4)).Se o serviço de back-end tiver três back-ends elegíveis: o back-end elegível
acom peso0, o back-end elegívelbcom peso2e o back-end elegívelccom peso6, o back-endatem uma probabilidade de seleção de 0% (0÷(0+2+6)), o back-endbtem uma probabilidade de seleção de 25% (2÷(0+2+6)) e o back-endctem uma probabilidade de seleção de 75% (6÷(0+2+6)).
O balanceador de carga atribui novas ligações a back-ends elegíveis de uma forma que seja o mais consistente possível, mesmo que o número de back-ends elegíveis ou os respetivos pesos mudem. 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, nas seguintes situações:
Se o equilíbrio de carga ponderado não estiver configurado, quando o conjunto de backends elegíveis não muda.
Se o equilíbrio de carga ponderado estiver configurado, quando o conjunto de back-ends elegíveis não se altera e o peso de cada back-end elegível permanece constante.
O balanceador de carga distribui as possíveis novas ligações entre os back-ends elegíveis da forma mais equitativa possível:
Se o equilíbrio de carga ponderado não estiver configurado, são mapeadas aproximadamente
1/Nnovas ligações possíveis para cada back-end elegível, em queNé a contagem de back-ends elegíveis.Se o equilíbrio de carga ponderado estiver configurado, a proporção de novas ligações possíveis que são mapeadas para cada back-end elegível é aproximadamente: o peso de um back-end elegível dividido pela soma de todos os pesos de back-end elegíveis.
Se for adicionado ou removido um back-end elegível, ou se o respetivo peso for alterado, a hash consistente tem como objetivo minimizar a interrupção dos mapeamentos para os outros back-ends elegíveis. Ou seja, a maioria das ligações que são mapeadas para outros back-ends elegíveis continuam a ser mapeadas para o mesmo back-end elegível.
2.3 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 se a afinidade de sessão configurada suportar o acompanhamento de ligações para o protocolo do pacote.
Se a afinidade de sessão configurada não suportar a monitorização de ligações para o protocolo do pacote, ignore este passo.
Se a afinidade de sessão configurada suportar o acompanhamento de ligações para o protocolo do pacote, a entrada da tabela de acompanhamento de ligações criada mapeia as caraterísticas do pacote para o back-end selecionado. Os campos do cabeçalho do pacote usados para este mapeamento dependem do modo de acompanhamento de ligações e da afinidade de sessão que configurou.
Para obter informações sobre os protocolos que são rastreáveis por ligação com base nas suas escolhas de configuração e nas caraterísticas dos pacotes usadas para o hash, consulte a secção Modo de acompanhamento de ligações.
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 estar inativa durante 60 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
FINouRST. Qualquer ligação TCP nova transporta sempre o indicadorSYNe é 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 monitorização 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 de um NEG. Para mais informações, consulte o artigo Ative a drenagem 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 encaminhamento externo usam a afinidade de sessão para selecionar um back-end 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 encaminhamento externo 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 do cabeçalho IP e dos cabeçalhos TCP/UDP são usados para calcular o hash.
| Método de hash para seleção de back-end | Definição de afinidade de sessão1 |
|---|---|
|
Hash de 5 tuplos (consiste no endereço IP de origem, na porta de origem, no protocolo, no endereço IP de destino e na porta de destino) para pacotes não fragmentados que incluem informações de portas, como pacotes TCP e pacotes UDP não fragmentados OUHash de 3 tuplos (composto pelo 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 5 tuplos (consiste no endereço IP de origem, na porta de origem, no protocolo, no endereço IP de destino e na porta de destino) para pacotes não fragmentados que incluem informações de portas, como pacotes TCP e pacotes UDP não fragmentados OUHash de 3 tuplos (composto pelo 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 3 tuplos (consiste no endereço IP de origem, no endereço IP de destino e no protocolo) |
CLIENT_IP_PROTO |
| Hash de 2 tuplos (consiste no endereço IP de origem e no endereço IP de destino) |
CLIENT_IP |
session affinity em cada conjunto de destino.
2 Uma definição de afinidade de sessão de NONE não
significa que não existe afinidade de sessão. Significa que nenhuma opção de afinidade de sessão está configurada explicitamente.
A aplicação de hash é sempre realizada para selecionar um back-end. Uma definição de afinidade de sessão de NONE significa que o balanceador de carga usa um hash de 5 tuplos ou um hash de 3 tuplos para selecionar back-ends, o que é funcionalmente o mesmo comportamento que quando CLIENT_IP_PORT_PROTO está definido.
Para obter informações sobre como as diferentes definições de afinidade de sessão afetam os métodos de seleção de back-end e acompanhamento de ligações, consulte a tabela na secção Modo de acompanhamento de ligações.
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 equilibradores de carga de rede de encaminhamento externo. 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
Quando a monitorização de ligações é possível, a tabela de monitorização de ligações do balanceador de carga mapeia tuplos de ligações para back-ends selecionados anteriormente numa tabela de hash. O conjunto de caraterísticas dos pacotes que compõem cada tuplo de ligação depende do modo de acompanhamento de ligações e da afinidade de sessão.
Os balanceadores de carga de rede de encaminhamento externo suportam o acompanhamento de ligações com base no protocolo e nas opções de afinidade de sessão:
As ligações TCP são sempre rastreáveis, para todas as opções de afinidade de sessão.
As ligações UDP, ESP e GRE são rastreáveis por ligação para todas as opções de afinidade de sessão exceto para
NONE.Todos os outros protocolos, como o ICMP e o ICMPv6, não são rastreáveis por ligação.
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_SESSIONpode 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.
| Seleção de back-end através da afinidade de sessão | Modo de acompanhamento de ligações | ||
|---|---|---|---|
| Definição de afinidade de sessão | Método de hash para seleção de back-end | PER_CONNECTION (predefinição) |
PER_SESSION |
| Predefinição
( |
TCP e UDP não fragmentado: hash de 5 tuplos UDP fragmentado e todos os outros protocolos: hash de 3 tuplos |
|
|
| IP de cliente, IP de destino
( |
Todos os protocolos: hash de 2 tuplos |
|
|
| IP do cliente, IP de destino, protocolo
( |
Todos os protocolos: hash de 3 tuplos |
|
|
| IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo
( |
TCP e UDP não fragmentado: hash de 5 tuplos UDP fragmentado e todos os outros protocolos: hash de 3 tuplos |
|
|
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_PERSISTALWAYS_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.
| Opção de persistência da ligação em back-ends em mau estado de funcionamento | Modo de acompanhamento de ligações | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: as ligações persistem em back-ends não íntegros (todas as afinidades de sessão) Todos os outros protocolos: as ligações nunca persistem em back-ends não íntegros |
TCP: as ligações persistem em back-ends não íntegros se a afinidade de sessão for Todos os outros protocolos: as ligações nunca persistem em back-ends não íntegros |
NEVER_PERSIST |
Todos os protocolos: as ligações nunca persistem em back-ends em mau estado de funcionamento | |
ALWAYS_PERSIST |
TCP: as ligações persistem em back-ends não íntegros (todas as afinidades de sessão) ESP, GRE, UDP: as ligações persistem em back-ends não íntegros se a afinidade de sessão não for ICMP, ICMPv6: não aplicável porque não são rastreáveis por ligação Esta opção só deve ser usada para exemplos de utilização avançados. |
Não é possível fazer a configuração |
Comportamento de persistência da ligação TCP em back-ends em mau estado de funcionamento
Sempre que uma ligação TCP com monitorização de 5 tuplos persistir num back-end não saudável:
- Se o back-end não saudável continuar a responder a pacotes, a ligação continua até ser reposta ou fechada (pelo back-end não saudável ou pelo cliente).
- Se o back-end não saudável enviar um pacote de reposição de TCP (RST) ou não responder a pacotes, o cliente pode tentar novamente com uma nova ligação, o que permite ao equilibrador de carga selecionar um back-end diferente e saudável. Os pacotes TCP SYN selecionam sempre um back-end novo e em bom estado.
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
As entradas nas tabelas de acompanhamento de ligações expiram 60 segundos após o equilibrador de carga processar o último pacote que correspondeu à entrada. Não é possível modificar este valor de tempo limite de inatividade.
Balanceamento de carga ponderado
O balanceamento de carga ponderado para balanceadores de carga de rede de encaminhamento externo usa informações de ponderação comunicadas por uma verificação de funcionamento HTTP. O balanceamento de carga ponderado requer que configure todos os seguintes elementos:
- A política de localidade do balanceador de carga do serviço de back-end (
localityLbPolicy) tem de serWEIGHTED_MAGLEV. - O serviço de back-end tem de usar uma verificação de funcionamento de HTTP.
- As respostas de verificação de funcionamento de cada VM de back-end ou ponto final de back-end têm de conter um cabeçalho de resposta HTTP personalizado. O nome do campo do cabeçalho da resposta é
X-Load-Balancing-Endpoint-Weighte os valores de campo válidos variam de0a1000.
Se precisar de 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 pontos finais de back-end comuns possa fornecer informações de ponderação únicas para cada serviço de back-end:
- Use uma verificação de funcionamento de HTTP exclusiva para cada serviço de back-end. Por exemplo, use um
request-pathparâmetro de verificação de estado único. - Configure instâncias ou pontos finais de back-end para responder com informações de peso adequadas para cada verificação de estado.
Quando usa o balanceamento de carga ponderado, o balanceador de carga classifica as VMs ou os pontos finais de back-end, primeiro com base num peso superior a zero ou igual a zero e, em seguida, com base nas verificações de funcionamento. O estado da verificação de funcionamento é determinado pelos critérios de sucesso das verificações de funcionamento de HTTP, HTTPS e HTTP/2.
| Peso | Saudável ou pouco saudável | Classificação |
|---|---|---|
| Peso superior a zero | Em bom estado de funcionamento | Primeira escolha |
| Peso superior a zero | Em mau estado de funcionamento | Segunda escolha |
| O peso é igual a zero | Em bom estado de funcionamento | Terceira escolha |
| O peso é igual a zero | Em mau estado de funcionamento | Quarta (última) escolha |
Para mais informações sobre como o equilíbrio de carga ponderado influencia os back-ends que são back-ends elegíveis, consulte os passos Identifique back-ends elegíveis e Selecione um back-end elegível na secção Seleção de back-ends e acompanhamento de ligações.
O balanceamento de carga ponderado pode ser usado nos seguintes cenários:
Se algumas associações processarem mais dados do que outras ou algumas associações durarem mais tempo do que outras, a distribuição da carga de back-end pode ficar desigual. Ao sinalizar uma ponderação por instância mais baixa, uma instância com carga elevada pode reduzir a respetiva quota de novas ligações, ao mesmo tempo que continua a servir as ligações existentes.
Se um back-end estiver sobrecarregado e a atribuição de mais ligações puder interromper as ligações existentes, esses back-ends atribuem um peso zero a si próprios. Ao sinalizar um peso zero, uma instância de back-end deixa de processar novas ligações, mas continua a processar as existentes.
Se um back-end estiver a esgotar as ligações existentes antes da manutenção, atribui um peso zero a si próprio. Ao sinalizar um peso zero, a instância de back-end deixa de servir novas ligações, mas continua a servir as existentes.
Para mais informações, consulte o artigo Configure o equilíbrio de carga ponderado.
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 balanceadores de carga de rede de encaminhamento externo baseados em serviços de back-end podem processar pacotes UDP fragmentados e não fragmentados. Se a sua aplicação usar pacotes UDP fragmentados, tenha em atenção o seguinte:
- Os pacotes UDP podem ficar fragmentados antes de chegarem 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 nãoGoogle 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
UDPouL3_DEFAULTpor endereço IP com equilíbrio de carga e configure a regra de encaminhamento para aceitar tráfego em todas as portas. 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=ALLou use a API para definirallPortscomoTrue.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) ouCLIENT_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 comoPER_SESSIONpara que as entradas da tabela de acompanhamento de ligações sejam criadas através dos mesmos hashes de 2 ou 3 tuplos.
Failover
Pode configurar um Network Load Balancer de encaminhamento externo para distribuir as ligações entre instâncias de VMs ou pontos finais em back-ends primários (grupos de instâncias ou NEGs) e, em seguida, mudar, se necessário, para a utilização de back-ends de alternativa. A comutação por falha oferece outro método de aumentar a disponibilidade, ao mesmo tempo que lhe dá maior controlo sobre a forma de gerir a sua carga de trabalho quando os back-ends principais não estão em bom estado.
Por predefinição, quando adiciona um back-end ao serviço de back-end de um Network Load Balancer de encaminhamento externo, 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 Vista geral da comutação por falha para balanceadores de carga de rede de encaminhamento externo.
O que se segue?
- Para configurar um balanceador de carga de rede de passagem externo com um serviço de back-end apenas para tráfego TCP ou UDP (compatível com tráfego IPv4 e IPv6), consulte o artigo Configure um balanceador de carga de rede de passagem externo com um serviço de back-end.
- Para configurar um balanceador de carga de rede de encaminhamento direto externo para vários protocolos IP (compatível com tráfego IPv4 e IPv6), consulte o artigo Configure um balanceador de carga de rede de encaminhamento direto externo para vários protocolos IP.
- Para configurar um balanceador de carga de rede de encaminhamento externo com um back-end de NEG zonal, consulte o artigo Configure um balanceador de carga de rede de encaminhamento externo com NEGs zonais
- Para saber como fazer a transição de um balanceador de carga de rede de passagem externo de um back-end de conjunto de destino para um serviço de back-end regional, consulte o artigo Fazer a transição de um balanceador de carga de rede de passagem externo de um conjunto de destino para um serviço de back-end.