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
Google CloudOs 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 global
Os balanceadores de carga de aplicações externos globais são implementados por muitos proxies denominados Google Front Ends (GFEs). Não existe apenas um proxy. No nível Premium, o mesmo endereço IP externo global é anunciado a partir de vários pontos de presença, e os pedidos dos clientes são direcionados para o GFE mais próximo do cliente.
Consoante a localização dos seus clientes, vários GFEs podem iniciar ligações HTTP(S) aos seus back-ends. Os pacotes enviados a partir de GFEs têm endereços IP de origem do mesmo intervalo usado pelos verificadores de estado: 35.191.0.0/16 e 130.211.0.0/22.
Consoante a configuração do serviço de back-end, o protocolo usado por cada GFE para se ligar aos seus back-ends pode ser HTTP, HTTPS ou HTTP/2. Para ligações HTTP ou HTTPS, a versão HTTP usada é HTTP 1.1.
O HTTP keepalive está ativado por predefinição, conforme especificado na especificação HTTP 1.1. As sessões persistentes HTTP tentam usar eficientemente a mesma sessão TCP; no entanto, não existe garantia. O GFE usa um limite de tempo limite de manutenção ativo de HTTP do cliente de 610 segundos e um valor de limite de tempo limite de manutenção ativo da parte traseira predefinido de 600 segundos. Pode atualizar o limite de tempo limite de manutenção ativo HTTP do cliente, mas o valor do limite de tempo limite de manutenção ativo do back-end é fixo. Pode configurar o limite de tempo da solicitação e da resposta definindo o limite de tempo do serviço de back-end. Embora estejam estreitamente relacionados, um keepalive HTTP e um tempo limite de inatividade TCP não são a mesma coisa. Para mais informações, consulte as secções Tempos limite e novas tentativas.
Para garantir que o tráfego é equilibrado uniformemente, o equilibrador de carga pode fechar corretamente uma ligação TCP enviando um pacote FIN ACK após concluir uma resposta que incluiu um cabeçalho Connection: close, ou pode emitir uma frame HTTP/2 GOAWAY após concluir uma resposta. Este comportamento não interfere
com pedidos nem respostas ativos.
Os números de ligações HTTP e sessões TCP variam consoante o número de GFEs que se ligam, o número de clientes que se ligam aos GFEs, o protocolo para os back-ends e onde os back-ends são implementados.
Para mais informações, consulte o artigo Como funcionam os equilibradores de carga de aplicações externos no guia de soluções: otimizações da capacidade das aplicações com o equilíbrio de carga global.
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 Google Cloud 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 globais:Ligação 1, do cliente original ao balanceador de carga (GFE):
- 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 equilibrador de carga (GFE) à VM ou ao ponto final do back-end:
Endereço IP de origem: um endereço IP num dos intervalos especificados nas Regras de firewall.
Endereço IP de destino: o endereço IP interno da VM ou do contentor de back-end na rede VPC.
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
Google Cloud 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.
- Entre GFEs e back-ends de balanceadores de carga de aplicações externos globais e balanceadores de carga de aplicações clássicos. Para mais informações, consulte o artigo Caminhos entre os front-ends e os back-ends da Google.
Google Cloud 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, Google Cloud 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.
Portas abertas
Os GFEs têm várias portas abertas para suportar outros serviços Google que são executados na mesma arquitetura. Quando executa uma análise de portas, pode ver outras portas abertas para outros serviços Google em execução em GFEs.
Os balanceadores de carga baseados no GFE, ou seja, os balanceadores de carga de aplicações externos globais e os balanceadores de carga de aplicações clássicos, mostram sempre as portas 80 e 443 como abertas (juntamente com qualquer outra porta que tenha configurado nas regras de encaminhamento do balanceador de carga). No entanto, se não tiver configurado uma regra de encaminhamento para a porta 80 ou para a porta 443, todas as ligações enviadas para essas portas são recusadas. Por outro lado, os balanceadores de carga de aplicações externos regionais são implementados através de proxies Envoy e não mostram portas abertas adicionais durante uma análise.A execução de uma análise de portas no endereço IP de um equilibrador de carga baseado no GFE não é útil do ponto de vista da auditoria pelos seguintes motivos:
Uma análise de portas (por exemplo, com
nmap) geralmente não espera um pacote de resposta ou um pacote TCP RST quando realiza a sondagem TCP SYN. Os GFEs enviam pacotes SYN-ACK em resposta a sondagens SYN apenas para portas nas quais configurou uma regra de encaminhamento. Os GFEs só enviam pacotes para os seus back-ends em resposta a pacotes enviados para o endereço IP do seu equilibrador de carga e a porta de destino configurada na respetiva regra de encaminhamento. Os pacotes enviados para um endereço IP ou uma porta diferentes não são enviados para os seus back-ends.Os GFEs implementam funcionalidades de segurança, como o Google Cloud Armor. Com o Cloud Armor Standard, os GFEs oferecem proteção sempre ativada contra ataques DDoS volumétricos e baseados em protocolos e ataques SYN "flood". Esta proteção está disponível mesmo que não tenha configurado explicitamente o Cloud Armor. A cobrança só é feita se configurar políticas de segurança ou se se inscrever na Proteção gerida Plus.
Os pacotes enviados para o endereço IP do seu equilibrador de carga podem ser respondidos por qualquer GFE na frota da Google. No entanto, a análise de um endereço IP do equilibrador de carga e de uma combinação de porta de destino apenas interroga um único GFE por ligação TCP. O endereço IP do seu equilibrador de carga não está atribuído a um único dispositivo ou sistema. Assim, a análise do endereço IP de um equilibrador de carga baseado no GFE não analisa todos os GFEs na frota da Google.
Com isto em mente, seguem-se algumas formas mais eficazes de auditar a segurança das suas instâncias de back-end:
Um auditor de segurança deve inspecionar a configuração das regras de encaminhamento da configuração do equilibrador de carga. As regras de encaminhamento definem a porta de destino para a qual o balanceador de carga aceita pacotes e os encaminha para os back-ends. Para balanceadores de carga baseados no GFE, cada regra de encaminhamento externo só pode referenciar uma única porta TCP de destino. Para um balanceador de carga que usa a porta TCP 443, a porta UDP 443 é usada quando a ligação é atualizada para QUIC (HTTP/3).
Um auditor de segurança deve inspecionar a configuração das regras da firewall aplicáveis às VMs de back-end. As regras de firewall que define bloqueiam o tráfego das GFEs para as VMs de back-end, mas não bloqueiam o tráfego de entrada para as GFEs. Para ver as práticas recomendadas, consulte a secção de regras da firewall.
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 global | O TLS é terminado num GFE, que pode estar em qualquer parte do mundo. |
| Balanceador de carga de aplicações clássico | O TLS é terminado num GFE, que pode estar em qualquer parte do mundo. |
| 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 | ||
|---|---|---|---|---|
| Global | Clássico | Regional | ||
| 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. |
|
|||
| 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.)
|
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.)
|
|
|||
| Limite de tempo de inatividade da sessão QUIC
O período máximo durante o qual uma sessão QUIC pode ficar inativa entre o cliente (a jusante) e o GFE de um Application Load Balancer externo global ou um Application Load Balancer clássico. |
Para balanceadores de carga de aplicações externos globais e balanceadores de carga de aplicações clássicos: O tempo limite de inatividade da sessão QUIC é o mínimo do tempo limite de inatividade do cliente ou do tempo limite de inatividade do GFE (300 segundos). O limite de tempo de inatividade do GFE está fixado em 300 segundos. O limite de tempo de inatividade do cliente pode ser configurado. |
|||
1 Não configurável para back-ends de NEG sem servidor. Não configurável para contentores de back-end.
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,Google Cloud 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.
No caso dos equilibradores de carga de aplicações globais e clássicos, os GFEs impõem um limite de tempo limite do serviço de back-end máximo eficaz de 86,400 segundos (1 dia).
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:
Consola
Modifique o campo Timeout do serviço de back-end do balanceador de carga.
gcloud
Use o comando
gcloud compute backend-services update
para modificar o parâmetro --timeout do recurso
backend service.
API
Para um Application Load Balancer externo global ou um Application Load Balancer clássico, modifique o parâmetro timeoutSec para o recurso global backendServices.
Para um Application Load Balancer externo regional, modifique o parâmetro timeoutSec para o recurso
regionBackendServices.
| Modo do balanceador de carga | Valores predefinidos | Descrição do limite de tempo para websockets |
|---|---|---|
| Balanceador de carga de aplicações externo global | 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 configurado do balanceador de carga. As ligações são fechadas automaticamente após 24 horas (86 400 segundos). Este limite de 24 horas é fixo e substitui o tempo limite do serviço de back-end se for superior a 24 horas. As ligações websocket inativas são fechadas após o serviço de back-end exceder o tempo limite. Não recomendamos valores de tempo limite do serviço de back-end superiores a 24 horas (86 400 segundos) porque os GFEs são reiniciados periodicamente para atualizações de software e outra manutenção de rotina. Google Cloud O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção. Quanto maior for o valor do limite de tempo do serviço de back-end, maior é a probabilidade de o Google Cloudterminar as ligações TCP para manutenção. |
| Balanceador de carga de aplicações clássico | Limite de tempo do serviço de back-end: 30 segundos | As ligações WebSocket, quer estejam inativas ou ativas, são fechadas automaticamente após o serviço de back-end exceder o tempo limite. Não recomendamos valores de tempo limite do serviço de back-end superiores a 24 horas (86 400 segundos) porque os GFEs são reiniciados periodicamente para atualizações de software e outra manutenção de rotina. Google Cloud O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção. Quanto maior for o valor do limite de tempo do serviço de back-end, maior é a probabilidade de o Google Cloudterminar as ligações TCP para manutenção. |
| 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. Google Cloud 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 Application Load Balancer externo global ou um Application Load Balancer clássico: um Google Front End de primeira camada
- 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:
Consola
Modifique o campo Tempo limite de manutenção ativa de HTTP da configuração de front-end do balanceador de carga.
gcloud
Para balanceadores de carga de aplicações externos globais, use o comando
gcloud compute target-http-proxies update
ou o comando gcloud compute target-https-proxies update
para modificar o parâmetro --http-keep-alive-timeout-sec
do proxy HTTP de destino ou do recurso de proxy HTTPS de destino.
Para um Application Load Balancer externo regional, não pode atualizar diretamente o parâmetro de tempo limite de keepalive de um proxy HTTP(S) de destino regional. Para atualizar o parâmetro de tempo limite de keepalive de um proxy de destino regional, tem de fazer o seguinte:
- Crie um novo proxy de destino com as definições de tempo limite pretendidas.
- Refletir todas as outras definições do proxy de destino atual no novo. Para proxies HTTPS de destino, isto inclui a associação de quaisquer certificados SSL ou mapas de certificados ao novo proxy de destino.
- Atualize as regras de encaminhamento para apontarem para o novo proxy de destino.
- Eliminar o proxy de destino anterior.
API
Para balanceadores de carga de aplicações externos globais, modifique o parâmetro httpKeepAliveTimeoutSec para o recurso
targetHttpProxies ou o recurso
targetHttpsProxies.
Para um Application Load Balancer externo regional, não pode atualizar diretamente o parâmetro de tempo limite de keepalive de um proxy HTTP(S) de destino regional. Para atualizar o parâmetro de tempo limite de keepalive de um proxy de destino regional, tem de fazer o seguinte:
- Crie um novo proxy de destino com as definições de tempo limite pretendidas.
- Refletir todas as outras definições do proxy de destino atual no novo. Para proxies HTTPS de destino, isto inclui a associação de quaisquer certificados SSL ou mapas de certificados ao novo proxy de destino.
- Atualize as regras de encaminhamento para apontarem para o novo proxy de destino.
- Eliminar o proxy de destino anterior.
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 Application Load Balancer externo global ou um Application Load Balancer clássico, existe uma primeira ligação TCP entre o cliente (a jusante) e um GFE de primeira camada. Os GFEs da primeira camada ligam-se aos GFEs da segunda camada e, em seguida, os GFEs da segunda camada abrem uma segunda ligação TCP aos seus back-ends.
- 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; |
Limite de tempo de inatividade da sessão QUIC
O tempo limite de inatividade da sessão QUIC representa o tempo máximo que uma sessão QUIC pode ficar inativa entre o cliente e o GFE de um balanceador de carga de aplicações externo global ou um balanceador de carga de aplicações clássico.
O valor de limite de tempo de inatividade da sessão QUIC é definido como o mínimo do limite de tempo de inatividade do cliente ou do limite de tempo de inatividade do GFE (300 segundos). O limite de tempo de inatividade do GFE está fixado em 300 segundos. O limite de tempo de inatividade do cliente pode ser configurado.
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 global |
Configurável através de uma
política de repetição
no mapa de URLs. O número máximo de novas tentativas
( Se quiser desativar as novas tentativas, tem de definir explicitamente
Sem uma política de repetição, as solicitações sem êxito que não têm um corpo HTTP (por exemplo, solicitações Não são repetidos pedidos HTTP As solicitações repetidas só geram uma entrada de registo para a resposta final. |
| Balanceador de carga de aplicações clássico |
Não é possível alterar a política de repetição para repetições de ligação. Não são repetidos pedidos HTTP As solicitações HTTP O balanceador de carga tenta novamente um pedido As solicitações repetidas só geram uma entrada de registo para a resposta final. Para mais informações, consulte o artigo Registo e monitorização do balanceador de carga de aplicações externo. Os pedidos sem êxito fazem com que o balanceador de carga sintetize uma resposta HTTP |
| 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
( Sem uma política de repetição, as solicitações sem êxito que não tenham um corpo HTTP (por exemplo, solicitações Não são repetidos pedidos HTTP 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
Upgradee o cabeçalhoUpgradenã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 global
Antes de um front-end da Google (GFE) enviar pedidos para instâncias de back-end, o GFE estima que instâncias de back-end têm capacidade para receber pedidos. Esta estimativa de capacidade é feita de forma proativa e não ao mesmo tempo que os pedidos estão a chegar. Os GFEs recebem informações periódicas sobre a capacidade disponível e distribuem os pedidos recebidos em conformidade.
O que significa capacidade depende, em parte, do modo de equilíbrio. Para o modo RATE
mode, é relativamente simples: um GFE determina exatamente quantos pedidos pode
atribuir por segundo. UTILIZATIONO equilíbrio de carga baseado em conteúdo é mais complexo: o equilibrador de carga verifica a utilização atual das instâncias e, em seguida, estima uma carga de consulta que cada instância pode processar. Esta estimativa muda ao longo do tempo à medida que a utilização das instâncias e os padrões de tráfego mudam.
Ambos os fatores, a estimativa da capacidade e a atribuição proativa, influenciam a distribuição entre instâncias. Assim, o Cloud Load Balancing comporta-se de forma diferente de um simples balanceador de carga round-robin que distribui os pedidos exatamente 50:50 entre duas instâncias. Em alternativa,o Google Cloud equilíbrio de carga tenta otimizar a seleção de instâncias de back-end para cada pedido.
Para o balanceador de carga de aplicações externo global, o balanceamento de carga tem dois níveis. O modo de balanceamento determina a ponderação ou a fração do tráfego a enviar a cada back-end (grupo de instâncias ou NEG). Em seguida, a política de balanceamento de carga (LocalityLbPolicy) determina como o tráfego é distribuído às instâncias ou aos pontos finais no grupo. Para mais informações, consulte a política de localidade de equilíbrio de carga (documentação da API de serviço de back-end).
Para o Application Load Balancer clássico, o modo de balanceamento é usado para selecionar o back-end mais favorável (grupo de instâncias ou NEG). Em seguida, o tráfego é distribuído de forma rotativa entre as instâncias ou os pontos finais no back-end.
Como são distribuídos os pedidos
Os balanceadores de carga de aplicações externos baseados no GFE usam o seguinte processo para distribuir pedidos recebidos:
- Do cliente para o GFE de primeira camada. Os routers de limite anunciam o endereço IP externo da regra de encaminhamento nos limites da rede da Google.
Cada anúncio indica um salto seguinte para um sistema de equilíbrio de carga da camada 3 e da camada 4 (Maglev). Os sistemas Maglev encaminham o tráfego para um Google Front End (GFE) de primeira camada.
- Quando usa o nível Premium, a Google anuncia o endereço IP do seu balanceador de carga a partir de todos os pontos de presença a nível mundial. Cada endereço IP do balanceador de carga é de anycast global.
- Quando usa o nível padrão, a Google anuncia o endereço IP do seu equilibrador de carga a partir de pontos de presença associados à região da regra de encaminhamento. O balanceador de carga usa um endereço IP externo regional. A utilização de uma regra de encaminhamento de nível padrão limita-se a grupos de instâncias e back-ends de NEG zonais na mesma região que a regra de encaminhamento do equilibrador de carga.
- Do GFE de primeira camada para o GFE de segunda camada. A GFE de primeira camada
termina o TLS, se necessário, e, em seguida, encaminha o tráfego para GFEs de segunda camada
de acordo com o seguinte processo:
- Os GFEs de primeira camada analisam o mapa de URLs e selecionam um serviço de back-end ou um contentor de back-end.
- Para serviços de back-end com NEGs de Internet, os GFEs da primeira camada selecionam um gateway de encaminhamento externo da segunda camada localizado com o GFE da primeira camada. O gateway de encaminhamento envia pedidos para o ponto final do NEG da Internet. Isto conclui o processo de distribuição de pedidos para NEGs da Internet.
- Para serviços de back-end com NEGs sem servidor e NEGs Private Service Connect (PSC), e contentores de back-end de região única, os GFEs de primeira camada selecionam um GFE de segunda camada na região correspondente à região do NEG ou do contentor. Para contentores do Cloud Storage multirregionais, os GFEs da primeira camada selecionam GFEs da segunda camada na região do contentor ou numa região o mais próxima possível do contentor multirregional (definido pelo tempo de ida e volta da rede).
- Para serviços de back-end com grupos de instâncias,
NEGs zonais com
GCE_VM_IP_PORTpontos finais e NEGs híbridos, o sistema de gestão de capacidade da Google informa os GFEs da primeira camada sobre a capacidade usada e configurada para cada back-end. A capacidade configurada para um backend é definida pelo modo de balanceamento, pela capacidade alvo do modo de balanceamento e pelo escalador de capacidade.- Nível padrão: os GFEs da primeira camada selecionam um GFE da segunda camada na região que contém os back-ends.
- Nível Premium: os GFEs da primeira camada selecionam GFEs da segunda camada a partir de um conjunto de regiões aplicáveis. As regiões aplicáveis são todas as regiões onde foram configurados back-ends, excluindo as regiões com back-ends configurados com capacidade zero. Os GFEs de primeira camada selecionam o GFE de segunda camada mais próximo numa região aplicável (definida pelo tempo de resposta da rede). Se os back-ends estiverem configurados em duas ou mais regiões, os GFEs de primeira camada podem transferir pedidos para outras regiões aplicáveis se uma região de primeira escolha estiver cheia. A transferência para outras regiões é possível quando todos os backends na região de primeira escolha estão no limite da capacidade.
- As GFEs da segunda camada selecionam back-ends. Os GFEs de segunda camada estão localizados em
zonas de uma região. Usam o seguinte processo para selecionar um back-end:
- Para serviços de back-end com NEGs sem servidor, NEGs do Private Service Connect e contentores de back-end, os GFEs de segunda camada encaminham pedidos para os sistemas de produção da Google. Isto conclui o processo de distribuição de pedidos para estes backends.
Para serviços de back-end com grupos de instâncias, NEGs zonais com pontos finais e NEGs híbridos, os sistemas de sondagem de verificação de estado da Google informam os GFEs de segunda camada acerca do estado da verificação de estado das instâncias ou dos pontos finais de back-end.
GCE_VM_IP_PORTApenas nível Premium: se o GFE de segunda camada não tiver instâncias ou pontos finais de back-end em bom estado na respetiva região, pode enviar pedidos para outro GFE de segunda camada numa região aplicável diferente com back-ends configurados. A sobreposição entre GFEs de segunda camada em diferentes regiões não esgota todas as combinações possíveis de região para região. Se precisar de direcionar o tráfego para longe dos back-ends numa região específica, em vez de configurar os back-ends para falharem nas verificações de estado, defina o ajuste de capacidade do back-end como zero para que o GFE de primeira camada exclua a região durante o passo anterior.
Em seguida, a GFE de segunda camada direciona os pedidos para instâncias de back-end ou pontos finais em zonas dentro da respetiva região, conforme abordado no passo seguinte.
A segunda camada do GFE seleciona uma zona. Por predefinição, os GFEs de segunda camada usam o algoritmo
WATERFALL_BY_REGION, em que cada GFE de segunda camada prefere selecionar instâncias ou pontos finais de back-end na mesma zona que contém o GFE de segunda camada. Uma vez que aWATERFALL_BY_REGIONminimiza o tráfego entre zonas, a taxas de pedido baixas, cada GFE de segunda camada pode enviar pedidos exclusivamente para servidores de back-end na mesma zona que o próprio GFE de segunda camada.Apenas para equilibradores de carga de aplicações externos globais, é possível configurar GFEs de segunda camada para usar um dos seguintes algoritmos alternativos através de um
serviceLbPolicy:SPRAY_TO_REGION: os GFEs de segunda camada não preferem selecionar instâncias ou pontos finais de back-end na mesma zona que o GFE de segunda camada. As GFEs de segunda camada tentam distribuir o tráfego para todas as instâncias ou todos os pontos finais de back-end em todas as zonas da região. Isto pode levar a uma distribuição mais uniforme da carga à custa do aumento do tráfego entre zonas.WATERFALL_BY_ZONE: Os GFEs de segunda camada preferem fortemente selecionar instâncias ou pontos finais de back-end na mesma zona que o GFE de segunda camada. As GFEs de segunda camada só direcionam pedidos para back-ends em zonas diferentes depois de todos os back-ends na zona atual terem atingido as respetivas capacidades configuradas.
- A segunda camada do GFE seleciona instâncias ou pontos finais na zona. Por predefinição, um GFE de segunda camada distribui pedidos entre back-ends de forma rotativa. Apenas para balanceadores de carga de aplicações externos globais, pode alterar esta definição usando uma política de localidade de balanceamento de carga (
localityLbPolicy). A política de localidade de balanceamento de carga aplica-se apenas aos back-ends na zona selecionada abordada no passo anterior.
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.
| Produto | Opções de afinidade de sessão |
|---|---|
Tenha também em atenção:
|
|
| Classic Application Load Balancer |
|
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-affinitye--subsetting-policysão ambosNONE, 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 (
NONEeCLIENT_IP) - Afinidade de sessão baseada em cabeçalhos HTTP (
HEADER_FIELD) - Afinidade de sessão baseada em cookies (
GENERATED_COOKIE,HTTP_COOKIEeSTRONG_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
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. Google Cloud 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_HASHouMAGLEV. - O elemento
consistentHashdo 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
localityLbPolicydo serviço de back-end, useRING_HASHouMAGLEV. Se não definir explicitamente olocalityLbPolicy, o balanceador de carga usaMAGLEVcomo 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.secondspode ser definido para um valor entre0e315576000000(inclusive).consistentHash.httpCookie.ttl.nanospode ser definido para um valor entre0e999999999(inclusive). Uma vez que as unidades são nanosegundos,999999999significa.999999999segundos.
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
localityLbPolicydo serviço de back-end, useRING_HASHouMAGLEV. Se não definir explicitamente olocalityLbPolicy, o balanceador de carga usaMAGLEVcomo 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.
Todos os balanceadores de carga de aplicações, exceto os balanceadores de carga de aplicações clássicos, suportam a afinidade baseada em cookies com estado.
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.
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 balanceamentoRATEouCONNECTIONpara 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.