Peça a distribuição para balanceadores de carga de aplicações externos

Este documento explica detalhadamente como os balanceadores de carga de aplicações externos processam as ligações, encaminham o tráfego e mantêm a afinidade de sessão.

Como funcionam as associações

Cloud de ConfianceOs equilibradores de carga de aplicações externos da Google, globais e regionais, simplificam o encaminhamento através de proxies distribuídos (GFEs) ou sub-redes geridas pelo Envoy. Com tempos limite configuráveis, terminação de TLS e segurança integrada, garantem a entrega de aplicações compatível e escalável a nível mundial ou regional.

Ligações do balanceador de carga de aplicações externo regional

O balanceador de carga de aplicações externo regional é um serviço gerido implementado no proxy Envoy. O Application Load Balancer externo regional usa uma sub-rede partilhada denominada sub-rede apenas de proxy para aprovisionar um conjunto de endereços IP que a Google usa para executar proxies Envoy em seu nome. A flag --purpose para esta sub-rede apenas de proxy está definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga baseados no Envoy regionais numa determinada rede e região partilham esta sub-rede.

Os clientes usam o endereço IP e a porta do balanceador de carga para estabelecer ligação ao balanceador de carga. Os pedidos do cliente são direcionados para a sub-rede apenas de proxy na mesma região que o cliente. O equilibrador de carga termina os pedidos dos clientes e, em seguida, abre novas ligações da sub-rede apenas de proxy aos seus back-ends. Por conseguinte, os pacotes enviados a partir do equilibrador de carga têm endereços IP de origem da sub-rede apenas de proxy.

Consoante a configuração do serviço de back-end, o protocolo usado pelos proxies do Envoy para se ligarem aos seus back-ends pode ser HTTP, HTTPS ou HTTP/2. Se for HTTP ou HTTPS, a versão HTTP é HTTP 1.1. O keepalive de HTTP está ativado por predefinição, conforme especificado na especificação HTTP 1.1. O proxy Envoy define o limite de tempo limite de manutenção ativo do HTTP do cliente e o limite de tempo limite de manutenção ativo do back-end para um valor predefinido de 600 segundos cada. Pode atualizar o limite de tempo de permanência ativo HTTP do cliente, mas o valor do limite de tempo de permanência ativo do back-end é fixo. Pode configurar o limite de tempo do pedido/resposta definindo o limite de tempo do serviço de back-end. Para mais informações, consulte a secção Tempos limite e novas tentativas.

Comunicações do cliente com o balanceador de carga

• Os clientes podem comunicar com o balanceador de carga através do protocolo HTTP/1.0, HTTP/1.1, HTTP/2 ou HTTP/3.
• Quando o HTTPS é usado, os clientes modernos usam o HTTP/2 por predefinição. Isto é controlado no cliente e não no balanceador de carga HTTPS.
• Não pode desativar o HTTP/2 fazendo uma alteração de configuração no equilibrador de carga. No entanto, pode configurar alguns clientes para usarem o HTTP 1.1 em vez do HTTP/2. Por exemplo, com curl, use o parâmetro --http1.1.
• Os balanceadores de carga de aplicações externos suportam a resposta HTTP/1.1 100 Continue.

Para ver a lista completa de protocolos suportados pelas regras de encaminhamento do Application Load Balancer externo em cada modo, consulte as funcionalidades do balanceador de carga.

Endereços IP de origem para pacotes de clientes

O endereço IP de origem dos pacotes, conforme visto pelos back-ends, não é o Cloud de Confiance endereço IP externo do balanceador de carga. Por outras palavras, existem duas ligações TCP.

Para os balanceadores de carga de aplicações externos regionais:

• Ligação 1, do cliente original ao equilibrador de carga (sub-rede apenas de proxy):

  • Endereço IP de origem: o cliente original (ou o endereço IP externo se o cliente estiver atrás de um gateway NAT ou de um proxy de encaminhamento).
  • Endereço IP de destino: o endereço IP do seu equilibrador de carga.

• Ligação 2, do balanceador de carga (sub-rede apenas de proxy) à VM ou ao ponto final de back-end:

  • Endereço IP de origem: um endereço IP na sub-rede só de proxy que é partilhado entre todos os balanceadores de carga baseados no Envoy implementados na mesma região e rede que o balanceador de carga.

  • Endereço IP de destino: o endereço IP interno da VM ou do contentor de back-end na rede VPC.

Caminhos de planeamento de trajetos especiais

Cloud de Confiance usa trajetos especiais não definidos na sua rede VPC para encaminhar pacotes para os seguintes tipos de tráfego:

• Para verificações de funcionamento, exceto verificações de funcionamento do Envoy distribuído. Para mais informações, consulte Caminhos para verificações de estado.

Cloud de Confiance usa rotas de sub-rede para sub-redes apenas de proxy para encaminhar pacotes para os seguintes tipos de tráfego:

• Quando usar verificações de funcionamento do Envoy distribuídas.

Para equilibradores de carga de aplicações externos regionais, Cloud de Confiance usa proxies Envoy de código aberto para terminar os pedidos de clientes ao equilibrador de carga. O balanceador de carga termina a sessão TCP e abre uma nova sessão TCP a partir da sub-rede apenas de proxy da região para o seu back-end. As rotas definidas na sua rede VPC facilitam a comunicação dos proxies do Envoy para os seus back-ends e dos seus back-ends para os proxies do Envoy.

Rescisão de TLS

A tabela seguinte resume a forma como a terminação TLS é processada pelos balanceadores de carga de aplicações externos.

Modo do balanceador de carga	Rescisão de TLS
Balanceador de carga de aplicações externo regional	O TLS é terminado em proxies Envoy localizados numa sub-rede apenas de proxy numa região escolhida pelo utilizador. Use este modo de balanceador de carga se precisar de controlo geográfico sobre a região onde o TLS é terminado.

Limites de tempo e novas tentativas

Os balanceadores de carga de aplicações externos suportam os seguintes tipos de limites de tempo para tráfego HTTP ou HTTPS:

Tipo de limite de tempo e descrição	Valores predefinidos	Suporta valores de tempo limite personalizados
		Limite de tempo do serviço de back-end1 Um limite de tempo do pedido e da resposta. Representa o tempo máximo permitido entre o balanceador de carga enviar o primeiro byte de um pedido para o back-end e o back-end devolver o último byte da resposta HTTP ao balanceador de carga. Se o back-end não tiver devolvido a resposta HTTP completa ao equilibrador de carga dentro deste limite de tempo, os dados de resposta restantes são ignorados.	Para todos os outros tipos de back-end num serviço de back-end: 30 segundos
Limite de tempo de manutenção ativa do HTTP do cliente O período máximo durante o qual a ligação TCP entre um cliente e o proxy do balanceador de carga pode ficar inativa. (A mesma ligação TCP pode ser usada para vários pedidos HTTP.) Para balanceadores de carga de aplicações externos regionais, o proxy do balanceador de carga é o software Envoy.	610 segundos
Tempo limite de manutenção ativa do HTTP de back-end O tempo máximo que a ligação TCP entre o proxy do balanceador de carga e um back-end pode ficar inativa. (A mesma ligação TCP pode ser usada para vários pedidos HTTP.) Para balanceadores de carga de aplicações externos regionais, o proxy do balanceador de carga é o software Envoy.	Para serviços de back-end: 10 minutos (600 segundos)

Limite de tempo do serviço de back-end

O tempo limite do serviço de back-end configurável representa o tempo máximo que o balanceador de carga aguarda que o back-end processe um pedido HTTP e devolva a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor predefinido para o limite de tempo do serviço de back-end é de 30 segundos.

Por exemplo, se quiser transferir um ficheiro de 500 MB e o valor do limite de tempo do serviço de back-end for de 90 segundos, o equilibrador de carga espera que o back-end forneça o ficheiro completo de 500 MB no prazo de 90 segundos. É possível configurar o tempo limite do serviço de back-end para que seja insuficiente para o back-end enviar a respetiva resposta HTTP completa. Nesta situação, se o balanceador de carga tiver recebido, pelo menos, cabeçalhos de resposta HTTP do back-end, o balanceador de carga devolve os cabeçalhos de resposta completos e a maior parte do corpo da resposta que conseguiu obter dentro do tempo limite do serviço de back-end.

Recomendamos que defina o limite de tempo do serviço de back-end para o período mais longo que espera que o back-end precise para processar uma resposta HTTP. Se o software em execução no seu back-end precisar de mais tempo para processar um pedido HTTP e devolver a resposta completa, recomendamos que aumente o limite de tempo do serviço de back-end. Por exemplo, recomendamos que aumente o tempo limite se vir respostas com o código de estado HTTP 408 com erros jsonPayload.statusDetail client_timed_out.

O limite de tempo do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. No entanto, os valores mais elevados não são opções de configuração práticas. Além disso,Cloud de Confiance não garante que uma ligação TCP subjacente possa permanecer aberta durante todo o valor do limite de tempo do serviço de back-end. Os sistemas cliente têm de implementar uma lógica de repetição em vez de dependerem de uma ligação TCP para estarem abertos durante longos períodos.

Para configurar o limite de tempo do serviço de back-end, use um dos seguintes métodos:

Os limites de tempo limite da ligação WebSocket nem sempre são os mesmos que os limites de tempo limite do serviço de back-end. Os limites de tempo da ligação WebSocket dependem do tipo de balanceador de carga:

Modo do balanceador de carga	Valores predefinidos	Descrição do limite de tempo para websockets
Balanceador de carga de aplicações externo regional	Limite de tempo do serviço de back-end: 30 segundos	As ligações WebSocket ativas não usam o limite de tempo do serviço de back-end do balanceador de carga. As ligações websocket inativas são fechadas após o serviço de back-end exceder o tempo limite. Cloud de Confiance reinicia ou altera periodicamente o número de tarefas do software Envoy. Quanto maior for o valor de tempo limite do serviço de back-end, maior é a probabilidade de as tarefas do Envoy serem reiniciadas ou de as ligações TCP serem terminadas.

Os balanceadores de carga de aplicações externos regionais usam o parâmetro routeActions.timeout configurado dos mapas de URLs e ignoram o limite de tempo do serviço de back-end. Quando routeActions.timeout não está configurado, é usado o valor do limite de tempo do serviço de back-end. Quando routeActions.timeout é fornecido, o limite de tempo do serviço de back-end é ignorado e o valor de routeActions.timeout é usado como o limite de tempo do pedido e da resposta.

Tempo limite de keep-alive de HTTP do cliente

O tempo limite de manutenção ativa do HTTP do cliente representa o período máximo durante o qual uma ligação TCP pode estar inativa entre o cliente (a jusante) e um dos seguintes tipos de proxies:

• Para um balanceador de carga de aplicações externo regional: um proxy Envoy

O limite de tempo de inatividade do HTTP keepalive do cliente representa o limite de tempo de inatividade do TCP para as ligações TCP subjacentes. O limite de tempo limite de manutenção ativa de HTTP do cliente não se aplica a websockets.

O valor predefinido para o tempo limite de manutenção ativo do HTTP do cliente é de 610 segundos. Para balanceadores de carga de aplicações externos globais e regionais, pode configurar o limite de tempo limite de manutenção ativo de HTTP do cliente com um valor entre 5 e 1200 segundos.

Para configurar o limite de tempo limite de manutenção ativa de HTTP do cliente, use um dos seguintes métodos:

O limite de tempo limite de manutenção ativa do HTTP do cliente do equilibrador de carga tem de ser superior ao limite de tempo limite de manutenção ativa do HTTP (inativo do TCP) usado por clientes ou proxies a jusante. Se um cliente a jusante tiver um limite de tempo limite de manutenção ativo de HTTP (TCP inativo) superior ao limite de tempo limite de manutenção ativo de HTTP do cliente do balanceador de carga, é possível que ocorra uma condição de corrida. Do ponto de vista de um cliente a jusante, é permitido que uma ligação TCP estabelecida fique inativa durante mais tempo do que o permitido pelo equilibrador de carga. Isto significa que o cliente a jusante pode enviar pacotes depois de o equilibrador de carga considerar a ligação TCP fechada. Quando isso acontece, o balanceador de carga responde com um pacote de reposição de TCP (RST).

Quando o limite de tempo limite de manutenção HTTP do cliente expira, o GFE ou o proxy Envoy envia um TCP FIN ao cliente para fechar corretamente a ligação.

Limite de tempo de manutenção ativa de HTTP do back-end

Os balanceadores de carga de aplicações externos são proxies que usam, pelo menos, duas ligações TCP:

• Para um balanceador de carga de aplicações externo regional, existe uma primeira ligação TCP entre o cliente (a jusante) e um proxy do Envoy. Em seguida, o proxy Envoy abre uma segunda ligação TCP aos seus back-ends.

As ligações TCP secundárias do equilibrador de carga podem não ser fechadas após cada pedido. Podem permanecer abertas para processar vários pedidos e respostas HTTP. O tempo limite de manutenção ativa de HTTP do back-end define o tempo limite de inatividade de TCP entre o balanceador de carga e os seus back-ends. O limite de tempo limite de manutenção ativo HTTP do back-end não se aplica a websockets.

O limite de tempo limite de manutenção ativo do back-end é fixo em 10 minutos (600 segundos) e não pode ser alterado. Isto ajuda a garantir que o balanceador de carga mantém as ligações inativas durante, pelo menos, 10 minutos. Após este período, o balanceador de carga pode enviar pacotes de terminação para o back-end em qualquer altura.

O limite de tempo limite de manutenção ativo do back-end do equilibrador de carga tem de ser inferior ao limite de tempo limite de manutenção ativo usado pelo software em execução nos seus back-ends. Isto evita uma condição de corrida em que o sistema operativo dos seus back-ends pode fechar as ligações TCP com uma reposição de TCP (RST). Uma vez que o tempo limite de manutenção ativo do back-end para o equilibrador de carga não é configurável, tem de configurar o software de back-end para que o respetivo valor de tempo limite de manutenção ativo de HTTP (inativo de TCP) seja superior a 600 segundos.

Quando o limite de tempo de manutenção ativo do HTTP de back-end expira, o GFE ou o proxy do Envoy envia um TCP FIN para a VM de back-end para fechar corretamente a ligação.

A tabela seguinte apresenta as alterações necessárias para modificar os valores de tempo limite de manutenção ativa para software de servidor Web comum.

Software de servidor Web	Parâmetro	Predefinição	Definição recomendada
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Novas tentativas

O suporte para a lógica de repetição depende do modo do Application Load Balancer externo.

Modo do balanceador de carga

Lógica de repetição

Balanceador de carga de aplicações externo regional

Configurável através de uma política de repetiçãono mapa de URLs. O número predefinido de tentativas (numRetries) é 1. O número máximo de novas tentativas que podem ser configuradas através da política de novas tentativas é 25. O máximo configurável perTryTimeout é de 24 horas. Sem uma política de repetição, as solicitações sem êxito que não tenham um corpo HTTP (por exemplo, solicitações GET) que resultem em respostas HTTP 502, 503 ou 504 são repetidas uma vez. Não são repetidos pedidos HTTP POST. As solicitações repetidas só geram uma entrada de registo para a resposta final.

O protocolo WebSocket é suportado com o GKE Ingress.

Processamento ilegal de pedidos e respostas

O balanceador de carga bloqueia os pedidos do cliente e as respostas do back-end de chegarem ao back-end ou ao cliente, respetivamente, por vários motivos. Alguns motivos destinam-se estritamente à conformidade com HTTP/1.1 e outros destinam-se a evitar a transmissão de dados inesperados para ou a partir dos back-ends. Não é possível desativar nenhuma das verificações.

O balanceador de carga bloqueia os seguintes pedidos para conformidade com HTTP/1.1:

• Não consegue analisar a primeira linha do pedido.
• Um cabeçalho não tem o delimitador de dois pontos (:).
• Os cabeçalhos ou a primeira linha contêm carateres inválidos.
• O comprimento do conteúdo não é um número válido ou existem vários cabeçalhos de comprimento do conteúdo.
• Existem várias chaves de codificação de transferência ou existem valores de codificação de transferência não reconhecidos.
• Existe um corpo não dividido em blocos e não foi especificado o comprimento do conteúdo.
• Os fragmentos do corpo não são analisáveis. Este é o único caso em que alguns dados chegam ao back-end. O balanceador de carga fecha as ligações ao cliente e ao back-end quando recebe um fragmento não analisável.

Processamento de pedidos

O balanceador de carga bloqueia o pedido se alguma das seguintes afirmações for verdadeira:

• O tamanho total dos cabeçalhos de pedidos e do URL do pedido excede o limite do tamanho máximo do cabeçalho do pedido para equilibradores de carga de aplicações externos.
• O método de pedido não permite um corpo, mas o pedido tem um.
• O pedido contém um cabeçalho Upgrade e o cabeçalho Upgrade não é usado para ativar ligações WebSocket.
• A versão HTTP é desconhecida.

Processamento de respostas

O balanceador de carga bloqueia a resposta do back-end se alguma das seguintes condições for verdadeira:

• O tamanho total dos cabeçalhos de resposta excede o limite de tamanho máximo do cabeçalho de resposta para equilibradores de carga de aplicações externos.
• A versão HTTP é desconhecida.

Ao processar o pedido e a resposta, o balanceador de carga pode remover ou substituir os cabeçalhos hop-by-hop no HTTP/1.1 antes de os encaminhar para o destino pretendido.

Distribuição de tráfego

Quando adiciona um grupo de instâncias ou um NEG de back-end a um serviço de back-end, especifica um modo de balanceamento, que define um método de medição da carga do back-end e uma capacidade de destino. Os balanceadores de carga de aplicações externos suportam dois modos de balanceamento:

• RATE, por exemplo, grupos ou NEGs, é o número máximo alvo de pedidos (consultas) por segundo (RPS, QPS). O máximo de RPS/CPS alvo pode ser excedido se todos os back-ends estiverem na capacidade ou acima da mesma.

• UTILIZATION é a utilização do back-end das VMs num grupo de instâncias.

A forma como o tráfego é distribuído pelos back-ends depende do modo do balanceador de carga.

Balanceador de carga de aplicações externo regional

Para balanceadores de carga de aplicações externos regionais, a distribuição de tráfego baseia-se no modo de balanceamento de carga e na política de localidade do balanceamento de carga.

O modo de equilíbrio determina o peso e a fração do tráfego a enviar para cada grupo (grupo de instâncias ou NEG). A política de localidade do balanceamento de carga (LocalityLbPolicy) determina como os back-ends no grupo são balanceados de carga.

Quando um serviço de back-end recebe tráfego, primeiro direciona o tráfego para um back-end (grupo de instâncias ou NEG) de acordo com o modo de balanceamento do back-end. Depois de selecionar um back-end, o tráfego é distribuído entre instâncias ou pontos finais nesse grupo de back-end de acordo com a política de localidade de equilíbrio de carga.

Para mais informações, consulte o seguinte:

• Modos de equilíbrio
• Política de localidade de equilíbrio de carga (documentação da API de serviço de back-end regional).

Afinidade de sessão

A afinidade de sessão, configurada no serviço de back-end dos equilibradores de carga de aplicações, faz uma tentativa de melhor esforço para enviar pedidos de um cliente específico para o mesmo back-end, desde que o número de instâncias ou pontos finais de back-end em bom estado permaneça constante e que a instância ou o ponto final de back-end selecionado anteriormente não esteja no limite da capacidade. A capacidade alvo do modo de equilíbrio determina quando o back-end está na capacidade máxima.

A tabela seguinte descreve os diferentes tipos de opções de afinidade de sessão suportados para os diferentes equilibradores de carga de aplicações. Na secção que se segue, Tipos de afinidade de sessão, cada tipo de afinidade de sessão é abordado mais detalhadamente.

Tabela: definições de afinidade de sessão suportadas

Produto

Opções de afinidade de sessão

Balanceador de carga de aplicações externo regional

Nenhum (NONE) IP do cliente (CLIENT_IP) Cookie gerado (GENERATED_COOKIE) Campo de cabeçalho (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Afinidade baseada em cookies com estado (STRONG_COOKIE_AFFINITY) Tenha também em atenção: O valor predefinido eficaz da política de localidade de equilíbrio de carga (localityLbPolicy) muda de acordo com as definições de afinidade de sessão. Se a afinidade de sessão não estiver configurada, ou seja, se a afinidade de sessão permanecer no valor predefinido de NONE, o valor predefinido para localityLbPolicy é ROUND_ROBIN. Se a afinidade da sessão estiver definida para um valor diferente de NONE, o valor predefinido de localityLbPolicy é MAGLEV.

Tenha em atenção o seguinte quando configurar a afinidade de sessão:

• Não confie na afinidade de sessão para fins de autenticação ou segurança. A afinidade de sessão, exceto a afinidade de sessão baseada em cookies com estado, pode ser interrompida sempre que o número de back-ends de serviço e em bom estado for alterado. Para mais detalhes, consulte o artigo Perder a afinidade da sessão.

• Os valores predefinidos das flags --session-affinity e --subsetting-policy são ambos NONE, e só é possível definir um deles de cada vez para um valor diferente.

Tipos de afinidade de sessão

A afinidade de sessão para balanceadores de carga de aplicações externos pode ser classificada numa das seguintes categorias:

• Afinidade de sessão baseada em hash (NONE e CLIENT_IP)
• Afinidade de sessão baseada em cabeçalhos HTTP (HEADER_FIELD)
• Afinidade de sessão baseada em cookies (GENERATED_COOKIE, HTTP_COOKIE e STRONG_COOKIE_AFFINITY)

Afinidade de sessão baseada em hash

Para a afinidade de sessão baseada em hash, o balanceador de carga usa o algoritmo de hash consistente para selecionar um back-end elegível. A definição de afinidade de sessão determina os campos do cabeçalho IP que são usados para calcular o hash.

A afinidade de sessão baseada em hash pode ser dos seguintes tipos:

• Nenhum
• Afinidade de IP do cliente

Nenhum

Uma definição de afinidade de sessão de NONE não significa que não existe afinidade de sessão. Significa que não está configurada explicitamente nenhuma opção de afinidade de sessão.

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 para selecionar um back-end. O 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.

Uma afinidade de sessão de NONE é o valor predefinido.

Afinidade de IP do cliente

A afinidade de sessão do IP do cliente (CLIENT_IP) é um hash de 2 tuplos criado a partir dos endereços IP de origem e destino do pacote. A afinidade de IP do cliente encaminha todos os pedidos do mesmo endereço IP do cliente para o mesmo back-end, desde que esse back-end tenha capacidade e permaneça em bom estado.

Quando usa a afinidade de IP do cliente, tenha em atenção o seguinte:

• O endereço IP de destino do pacote só é igual ao endereço IP da regra de encaminhamento do balanceador de carga se o pacote for enviado diretamente para o balanceador de carga.
• O endereço IP de origem do pacote pode não corresponder a um endereço IP associado ao cliente original se o pacote for processado por um NAT intermédio ou um sistema de proxy antes de ser entregue a um equilibrador de carga. Cloud de Confiance Em situações em que muitos clientes partilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais ligações ou pedidos do que outras.

Afinidade de sessão baseada em cabeçalhos HTTP

Com a afinidade do campo de cabeçalho (HEADER_FIELD), os pedidos são encaminhados para os back-ends com base no valor do cabeçalho HTTP no campo consistentHash.httpHeaderName do serviço de back-end. Para distribuir pedidos por todos os back-ends disponíveis, cada cliente tem de usar um valor de cabeçalho HTTP diferente.

A afinidade do campo de cabeçalho é suportada quando as seguintes condições são verdadeiras:

• A política de localidade de balanceamento de carga é RING_HASH ou MAGLEV.
• O elemento consistentHash do serviço de back-end especifica o nome do cabeçalho HTTP (httpHeaderName).

Afinidade de sessão baseada em cookies

A afinidade de sessão baseada em cookies pode ser dos seguintes tipos:

• Afinidade de cookie gerado
• Afinidade de cookies HTTP
• Afinidade de sessão baseada em cookies com estado

Afinidade de cookie gerado

Quando usa a afinidade baseada em cookies gerados (GENERATED_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta ao pedido HTTP inicial.

O nome do cookie gerado varia consoante o tipo de equilibrador de carga.

Produto	Nome do cookie
Balanceadores de carga de aplicações externos globais	GCLB
Balanceadores de carga de aplicações clássicos	GCLB
Balanceadores de carga de aplicações externos regionais	GCILB

O atributo de caminho do cookie gerado é sempre uma barra (/), pelo que se aplica a todos os serviços de back-end no mesmo mapa de URLs, desde que os outros serviços de back-end também usem a afinidade de cookie gerado.

Pode configurar o valor do tempo de vida (TTL) do cookie entre 0 e 1,209,600 segundos (inclusive) através do parâmetro do serviço de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor TTL predefinido é 0.

Quando o cliente inclui o cookie de afinidade de sessão gerado no cabeçalho do pedido de pedidos HTTP, o equilibrador de carga direciona esses pedidos para a mesma instância ou ponto final de back-end, desde que o cookie de afinidade de sessão permaneça válido.Cookie Isto é feito através do mapeamento do valor do cookie para um índice que faz referência a uma instância específica do back-end ou a um ponto final, e garantindo que os requisitos de afinidade de sessão de cookies gerados são cumpridos.

Para usar a afinidade de cookies gerada, configure o seguinte modo de equilíbrio de carga e definições localityLbPolicy:

• Para grupos de instâncias de back-end, use o RATEmodo de balanceamento.
• Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se não definir explicitamente o localityLbPolicy, o balanceador de carga usa MAGLEV como predefinição implícita.

Para mais informações, consulte o artigo sobre perder a afinidade da sessão.

Afinidade de cookie HTTP

Quando usa a afinidade baseada em cookies HTTP (HTTP_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta ao pedido HTTP inicial. Especifica o nome, o caminho e o tempo de vida (TTL) do cookie.

Todos os balanceadores de carga de aplicações suportam a afinidade baseada em cookies HTTP.

Pode configurar os valores de TTL do cookie através de segundos, frações de segundo (como nanosegundos) ou ambos, segundos mais frações de segundo (como nanosegundos), usando os seguintes parâmetros do serviço de back-end e valores válidos:

• consistentHash.httpCookie.ttl.seconds pode ser definido para um valor entre 0 e 315576000000 (inclusive).
• consistentHash.httpCookie.ttl.nanos pode ser definido para um valor entre 0 e 999999999 (inclusive). Uma vez que as unidades são nanosegundos, 999999999 significa .999999999 segundos.

Se consistentHash.httpCookie.ttl.seconds e consistentHash.httpCookie.ttl.nanos não forem especificados, é usado o valor do parâmetro do serviço de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor TTL predefinido é 0.

Quando o cliente inclui o cookie de afinidade de sessão HTTP no cabeçalho do pedido de pedidos HTTP, o balanceador de carga direciona esses pedidos para a mesma instância ou ponto final de back-end, desde que o cookie de afinidade de sessão permaneça válido.Cookie Isto é feito através do mapeamento do valor do cookie para um índice que faz referência a uma instância específica do back-end ou a um ponto final, e garantindo que os requisitos de afinidade de sessão de cookies gerados são cumpridos.

Para usar a afinidade de cookies HTTP, configure o seguinte modo de equilíbrio de carga e definições localityLbPolicy:

• Para grupos de instâncias de back-end, use o RATEmodo de balanceamento.
• Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se não definir explicitamente o localityLbPolicy, o balanceador de carga usa MAGLEV como predefinição implícita.

Para mais informações, consulte o artigo sobre perder a afinidade da sessão.

Afinidade de sessão baseada em cookies com estado

Quando usa a afinidade baseada em cookies com estado (STRONG_COOKIE_AFFINITY), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta ao pedido HTTP inicial. Especifica o nome, o caminho e o tempo de vida (TTL) do cookie.

Os seguintes equilibradores de carga suportam a afinidade com base em cookies com estado:

• Balanceadores de carga de aplicações externos regionais
• Balanceadores de carga de aplicações internos regionais

Pode configurar os valores de TTL do cookie usando segundos, frações de segundo (como nanosegundos) ou ambos os segundos mais frações de segundo (como nanosegundos). A duração representada por strongSessionAffinityCookie.ttl não pode ser definida para um valor que represente mais de duas semanas (1 209 600 segundos).

O valor do cookie identifica uma instância ou um ponto final de back-end selecionado através da codificação da instância ou do ponto final selecionado no próprio valor. Enquanto o cookie for válido, se o cliente incluir o cookie de afinidade de sessão no cabeçalho do pedido Cookie de pedidos HTTP subsequentes, o balanceador de carga direciona esses pedidos para a instância ou o ponto final de back-end selecionado.

Ao contrário de outros métodos de afinidade de sessão:

• A afinidade baseada em cookies com estado não tem requisitos específicos para o modo de equilíbrio de carga nem para a política de localidade de equilíbrio de carga (localityLbPolicy).

• A afinidade baseada em cookies com estado não é afetada quando o dimensionamento automático adiciona uma nova instância a um grupo de instâncias gerido.

• A afinidade baseada em cookies com estado não é afetada quando o dimensionamento automático remove uma instância de um grupo de instâncias gerido, a menos que a instância selecionada seja removida.

• A afinidade baseada em cookies com estado não é afetada quando a autocorreção remove uma instância de um grupo de instâncias gerido a menos que a instância selecionada seja removida.

Para mais informações, consulte o artigo sobre perder a afinidade da sessão.

Significado de TTL zero para afinidades baseadas em cookies

Todas as afinidades de sessão baseadas em cookies, como a afinidade de cookie gerado, a afinidade de cookie HTTP e a afinidade baseada em cookies com estado, têm um atributo TTL.

Um TTL de zero segundos significa que o equilibrador de carga não atribui um Expiresatributo ao cookie. Neste caso, o cliente trata o cookie como um cookie de sessão. A definição de uma sessão varia consoante o cliente:

• Alguns clientes, como os navegadores de Internet, retêm o cookie durante toda a sessão de navegação. Isto significa que o cookie persiste em vários pedidos até que a aplicação seja fechada.

• Outros clientes tratam uma sessão como um único pedido HTTP, rejeitando o cookie imediatamente a seguir.

Perder a afinidade de sessão

Todas as opções de afinidade de sessão requerem o seguinte:

• A instância ou o ponto final do back-end selecionado tem de permanecer configurado como um back-end. A afinidade de sessão pode ser interrompida quando ocorre um dos seguintes eventos:
  • Remove a instância selecionada do respetivo grupo de instâncias.
  • O dimensionamento automático ou a autorreparação do grupo de instâncias geridas remove a instância selecionada do respetivo grupo de instâncias geridas.
  • Remove o ponto final selecionado do respetivo NEG.
  • Remove o grupo de instâncias ou o NEG que contém a instância ou o ponto final selecionado do serviço de back-end.
• A instância ou o ponto final do back-end selecionado tem de permanecer em bom estado. A afinidade de sessão pode ser interrompida quando a instância ou o ponto final selecionado falha nas verificações de estado.
• Para os balanceadores de carga de aplicações externos globais e os balanceadores de carga de aplicações clássicos, a afinidade de sessão pode ser interrompida se for usado um Google Front End (GFE) de primeira camada diferente para pedidos ou ligações subsequentes após a alteração no caminho de encaminhamento. Pode ser selecionada uma GFE de primeira camada diferente se o caminho de encaminhamento de um cliente na Internet para a Google mudar entre pedidos ou ligações.

Exceto para a afinidade de sessão baseada em cookies com estado, todas as opções de afinidade de sessão têm os seguintes requisitos adicionais:

• O grupo de instâncias ou o NEG que contém a instância ou o ponto final selecionado não pode estar cheio, conforme definido pela respetiva capacidade alvo. (Para grupos de instâncias geridas regionais, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio.) A afinidade de sessão pode ser interrompida quando o grupo de instâncias ou o NEG está cheio e outros grupos de instâncias ou NEGs não estão. Uma vez que a capacidade pode mudar de formas imprevisíveis quando usa o modo de balanceamento UTILIZATION, deve usar o modo de balanceamento RATE ou CONNECTION para minimizar as situações em que a afinidade de sessão pode ser interrompida.

• O número total de instâncias ou pontos finais de back-end configurados tem de permanecer constante. Quando ocorre, pelo menos, um dos seguintes eventos, o número de instâncias ou pontos finais de back-end configurados é alterado e a afinidade de sessão pode ser interrompida:

  • Adicionar novas instâncias ou pontos finais:

    • Adiciona instâncias a um grupo de instâncias existente no serviço de back-end.
    • O dimensionamento automático do grupo de instâncias geridas adiciona instâncias a um grupo de instâncias geridas no serviço de back-end.
    • Adiciona pontos finais a um NEG existente no serviço de back-end.
    • Adiciona grupos de instâncias ou NEGs não vazios ao serviço de back-end.

  • Remover qualquer instância ou ponto final, não apenas a instância ou o ponto final selecionado:

    • Remover qualquer instância de um back-end de grupo de instâncias.
    • O dimensionamento automático ou a autorreparação do grupo de instâncias geridas remove qualquer instância de um back-end do grupo de instâncias geridas.
    • Remover qualquer ponto final de um back-end do NEG.
    • Remova qualquer grupo de instâncias de back-end ou NEG existente e não vazio do serviço de back-end.

• O número total de instâncias ou pontos finais de back-end saudáveis tem de permanecer constante. Quando ocorre, pelo menos, um dos seguintes eventos, o número de instâncias ou pontos finais de back-end íntegros muda e a afinidade de sessão pode ser interrompida:

  • Qualquer instância ou ponto final passa na respetiva verificação de estado, passando de não saudável para saudável.
  • Qualquer instância ou ponto final falha na respetiva verificação de estado, passando de em bom estado para em mau estado ou tempo limite.