Este documento aborda as complexidades de como os balanceadores de carga de aplicativo externos processam conexões, encaminham tráfego e mantêm a afinidade da sessão.
Como funcionam as conexões
Os balanceadores de carga de aplicativo externos doGoogle Cloud(globais e regionais) simplificam o roteamento usando proxies distribuídos (GFEs) ou sub-redes gerenciadas pelo Envoy. Com tempos limite configuráveis, término de TLS e segurança integrada, eles garantem a entrega de aplicativos compatível e escalonável no mundo todo ou em regiões específicas.
Conexões do balanceador de carga de aplicativo externo global
Os balanceadores de carga de aplicativo externos globais são implementados por muitos proxies chamados Google Front Ends (GFEs). Não existe apenas um proxy. No nível Premium, o mesmo endereço IP externo global é divulgado a partir de vários pontos de presença, e as solicitações do cliente são direcionadas para o GFE mais próximo do cliente.
Dependendo de onde seus clientes estão, vários GFEs podem iniciar conexões
HTTP(S) com os back-ends. Os pacotes enviados de GFEs têm endereços IP de origem
do mesmo intervalo usado pelas sondagens de verificação de integridade: 35.191.0.0/16 e
130.211.0.0/22.
Dependendo da configuração do serviço de back-end, o protocolo usado por cada GFE para se conectar aos back-ends pode ser HTTP, HTTPS ou HTTP/2. Para conexões HTTP ou HTTPS, a versão HTTP usada é HTTP 1.1.
O sinal de atividade HTTP está ativado por padrão, conforme a especificação HTTP 1.1. Os sinais de atividade HTTP tentam usar de forma eficiente a mesma sessão TCP. No entanto, não há garantias. O GFE usa um tempo limite do sinal de atividade HTTP do cliente de 610 segundos e um valor padrão do tempo limite de sinal de atividade do back-end de 600 segundos. É possível atualizar o tempo limite do sinal de atividade HTTP do cliente, mas o valor do tempo limite do sinal de atividade do back-end é fixo. É possível configurar o tempo limite de solicitação e resposta definindo o tempo limite do serviço de back-end. Embora estejam estreitamente relacionados, um sinal de atividade HTTP e um tempo limite de inatividade do TCP não são a mesma coisa. Para mais informações, consulte Tempos limite e novas tentativas.
Para garantir que o tráfego tenha a carga balanceada uniformemente, o balanceador de carga pode fechar
uma conexão TCP enviando um pacote FIN ACK depois de concluir uma
resposta que inclui um cabeçalho Connection: close ou pode emitir um frame
HTTP/2 GOAWAY depois de concluir uma resposta. Esse comportamento não interfere
em solicitações ou respostas ativas.
Os números de conexões HTTP e sessões TCP variam de acordo com o número de GFEs conectados, o número de clientes que se conectam aos GFEs, o protocolo aos back-ends e onde os back-ends são implantados.
Para mais informações, consulte Como funcionam os balanceadores de carga de aplicativo externos no guia de soluções: otimizações de capacidade de aplicativos com balanceamento de carga global.
Conexões externas regionais do balanceador de carga de aplicativo
O balanceador de carga de aplicativo externo regional é um serviço gerenciado implementado no proxy Envoy.
O balanceador de carga de aplicativo externo regional usa uma sub-rede compartilhada chamada sub-rede somente proxy para
provisionar um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu
nome. A sinalização --purpose dessa sub-rede somente proxy está definida como
REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga regionais baseados no
Envoy em uma rede
e região específicas compartilham essa sub-rede.
Os clientes usam o endereço IP e a porta do balanceador de carga para se conectar ao balanceador de carga. As solicitações do cliente são direcionadas para a sub-rede somente proxy na mesma região do cliente. O balanceador de carga encerra solicitações de clientes e depois abre novas conexões da sub-rede somente proxy para os back-ends. Portanto, os pacotes enviados do balanceador de carga têm endereços IP de origem da sub-rede somente proxy.
Dependendo da configuração do serviço de back-end, o protocolo usado por cada Envoy para se conectar aos back-ends pode ser HTTP, HTTPS ou HTTP/2. Se HTTP ou HTTPS, a versão HTTP é HTTP 1.1. O sinal de atividade HTTP está ativado por padrão, conforme a especificação HTTP 1.1. O proxy Envoy define o tempo limite do sinal de atividade HTTP do cliente e o tempo limite do sinal de atividade do back-end como um valor padrão de 600 segundos cada. É possível atualizar o tempo limite do sinal de atividade HTTP do cliente, mas o valor do tempo limite do sinal de atividade do back-end é fixo. É possível configurar o tempo limite da solicitação/resposta definindo o tempo limite do serviço de back-end. Saiba mais em Tempos limite e novas tentativas.
Comunicações do cliente com o balanceador de carga
- Os clientes podem se comunicar com o balanceador de carga usando o protocolo HTTP 1.1 ou HTTP/2.
- Quando HTTPS é usado, o padrão dos clientes modernos é HTTP/2. Isso é controlado no cliente, não no balanceador de carga HTTPS.
- Não é possível desativar o HTTP/2 alterando a configuração no balanceador de
carga. No entanto, é possível configurar alguns clientes para usar HTTP 1.1 em vez de
HTTP/2. Por exemplo, com
curl, use o parâmetro--http1.1. - Os balanceadores de carga de aplicativo externos são compatíveis com a resposta
HTTP/1.1 100 Continue.
Confira a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceador de carga de aplicativo em cada modo em Recursos do balanceador de carga.
Endereços IP de origem para pacotes de clientes
O endereço IP de origem dos pacotes, como visto pelos back-ends, não é o endereço IP externo do balanceador de carga.Google Cloud Em outras palavras, há duas conexões TCP:
Para os balanceadores de carga de aplicativo externos globais:Conexão 1, do cliente original para o balanceador de carga (GFE):
- Endereço IP de origem: o cliente original (ou endereço IP externo se o cliente estiver atrás de um gateway NAT ou um proxy de encaminhamento).
- Endereço IP de destino: o endereço IP do seu balanceador de carga.
Conexão 2, do balanceador de carga (GFE) para o endpoint ou VM de back-end:
Endereço IP de origem: um endereço IP em um dos intervalos especificados nas regras de firewall.
Endereço IP de destino: o endereço IP interno da VM ou contêiner de back-end na rede VPC.
Conexão 1, do cliente original para o balanceador de carga (sub-rede somente proxy):
- Endereço IP de origem: o cliente original (ou endereço IP externo se o cliente estiver atrás de um gateway NAT ou um proxy de encaminhamento).
- Endereço IP de destino: o endereço IP do seu balanceador de carga.
Conexão 2, do balanceador de carga (sub-rede somente proxy) para o endpoint ou a VM de back-end:
Endereço IP de origem: um endereço IP na sub-rede somente proxy compartilhado entre todos os balanceadores de carga baseados em Envoy implantados na mesma região e rede que o balanceador de carga.
Endereço IP de destino: o endereço IP interno da VM ou contêiner de back-end na rede VPC.
Caminhos de roteamento especiais
OGoogle Cloud usa rotas especiais não definidas na sua rede VPC para rotear pacotes dos seguintes tipos de tráfego:
- Para verificações de integridade, exceto verificações de integridade distribuídas do Envoy. Para mais informações, consulte Caminhos para verificações de integridade.
- Entre GFEs e back-ends de balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos. Para mais informações, consulte Caminhos entre o Google Front Ends e os back-ends.
OGoogle Cloud usa rotas de sub-rede para sub-redes somente proxy para rotear pacotes dos seguintes tipos de tráfego:
- Ao usar verificações de integridade distribuídas do Envoy.
Para balanceadores de carga de aplicativo externos regionais,o Google Cloud usa proxies Envoy de código aberto para encerrar solicitações de clientes ao balanceador de carga. O balanceador de carga encerra a sessão TCP e abre uma nova sessão da sub-rede somente proxy da região para o back-end. As rotas definidas na sua rede VPC facilitam a comunicação dos proxies Envoy para seus back-ends e vice-versa.
Portas abertas
Os GFEs têm várias portas abertas para oferecer suporte a outros serviços do Google, executados na mesma arquitetura. Ao executar uma verificação de portas, é possível ver outras portas abertas para outros serviços do Google em execução nos GFEs.
Os balanceadores de carga baseados no GFE (balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos) sempre mostram as portas 80 e 443 como abertas (com qualquer outra porta que você tenha configurado nas regras de encaminhamento do balanceador de carga). No entanto, se você não tiver configurado uma regra de encaminhamento para a porta 80 ou 443, todas as conexões enviadas para essas portas serão recusadas. Por outro lado, os balanceadores de carga de aplicativo externos regionais são implementados usando proxies Envoy e não mostram portas abertas extras durante uma verificação.Executar uma verificação de porta no endereço IP de um balanceador de carga baseado no GFE não é útil do ponto de vista de auditoria pelos seguintes motivos:
Uma verificação de porta (por exemplo, com
nmap) geralmente não espera nenhum pacote de resposta ou um pacote TCP RST ao realizar a sondagem de TCP SYN. Os GFEs enviam pacotes SYN-ACK em resposta a sondagens SYN apenas para portas em que você configurou uma regra de encaminhamento. Os GFEs só enviam pacotes para os back-ends em resposta aos enviados para o endereço IP do balanceador de carga e para a porta de destino configurada na regra de encaminhamento. Os pacotes enviados para um endereço IP ou uma porta diferente não são enviados para os back-ends.Os GFEs implementam recursos 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 protocolo e inundações de SYN. Essa proteção está disponível mesmo que você não tenha configurado explicitamente o Cloud Armor. Você só vai receber cobranças se configurar políticas de segurança ou se inscrever no Managed Protection Plus.
Os pacotes enviados para o endereço IP do balanceador de carga podem ser respondidos por qualquer GFE na frota do Google. No entanto, a verificação de uma combinação de endereço IP e porta de destino do balanceador de carga interroga apenas um único GFE por conexão TCP. O endereço IP do seu balanceador de carga não é atribuído a um único dispositivo ou sistema. Portanto, a verificação do endereço IP de um balanceador de carga baseado em GFE não verifica todos os GFEs na frota do Google.
Com isso em mente, veja a seguir algumas maneiras mais eficazes de auditar a segurança das instâncias de back-end:
Um auditor de segurança precisa inspecionar a configuração das regras de encaminhamento para a configuração do balanceador 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 em 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 conexão recebe upgrade para QUIC (HTTP/3).
Um auditor de segurança deve inspecionar a configuração da regra de firewall aplicável às VMs de back-end. As regras de firewall definidas bloqueiam o tráfego dos GFEs para as VMs de back-end, mas não bloqueiam o tráfego de entrada para os GFEs. Para ver as práticas recomendadas, consulte a seção de regras de firewall.
término de TLS
A tabela a seguir resume como término de TLS é processada pelos balanceadores de carga de aplicativo externos.
| Modo balanceador de carga | término de TLS |
|---|---|
| Balanceador de carga de aplicativo externo global | O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo. |
| Balanceador de carga de aplicativo clássico | O TLS é encerrado em um GFE, que pode estar em qualquer lugar do mundo. |
| Balanceador de carga de aplicativo externo regional | O TLS é encerrado nos proxies do Envoy localizados em uma sub-rede apenas de proxy em uma região escolhida pelo usuário. Use esse modo de balanceador de carga se você precisar de controle geográfico sobre a região em que o TLS é encerrado. |
Tempo limite e tentativas
Os balanceadores de carga de aplicativo externos são compatíveis com os seguintes tipos de tempo limite para tráfego HTTP ou HTTPS:
| Tipo e descrição de tempo limite | Valores padrão | Compatível com valores de tempo limite personalizados | ||
|---|---|---|---|---|
| Global | Clássico | Regional | ||
| Tempo limite do serviço de back-end1
Tempo limite de solicitação e resposta. Representa o tempo máximo permitido entre o momento em que o balanceador de carga envia o primeiro byte de uma solicitação para o back-end e o momento em que o back-end retorna o último byte da resposta HTTP para o balanceador de carga. Se o back-end não retornar toda a resposta HTTP ao balanceador de carga dentro desse limite de tempo, os dados de resposta restantes serão descartados. |
|
|||
| Tempo limite do sinal de atividade HTTP do cliente
O tempo máximo que a conexão TCP entre um cliente e o proxy do balanceador de carga pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.
|
610 segundos | |||
| Tempo limite do sinal de atividade HTTP do back-end
O tempo máximo que a conexão TCP entre o proxy do balanceador de carga e um back-end pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.
|
|
|||
| Tempo limite de inatividade da sessão QUIC
O tempo máximo que uma sessão QUIC pode ficar inativa entre o cliente (downstream) e o GFE de um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico. |
Para balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo clássicos: O tempo limite de inatividade da sessão QUIC é o mínimo de um destes: tempo limite de inatividade do cliente ou tempo limite de inatividade do GFE (300 segundos). O tempo limite de inatividade do GFE é fixo em 300 segundos. O tempo limite de inatividade do cliente pode ser configurado. |
|||
1Não configurável para back-ends de NEG sem servidor. Não é configurável para buckets de back-end.
Tempo limite 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 até o back-end processar uma solicitação HTTP e retornar a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor padrão do tempo limite do serviço de back-end é de 30 segundos.
Por exemplo, se você quiser fazer o download de um arquivo de 500 MB e o valor do tempo limite do serviço de back-end for de 90 segundos, o balanceador de carga aguardará o back-end enviar todo o arquivo de 500 MB em até 90 segundos. É possível configurar o tempo limite do serviço de back-end como insuficiente para que o back-end envie a resposta HTTP completa. Nessa situação, se o balanceador de carga tiver recebido do back-end pelo menos os cabeçalhos de resposta HTTP, ele retornará os cabeçalhos completos e o máximo possível do corpo de resposta dentro do tempo limite do serviço de back-end.
Recomendamos que você defina o tempo limite do serviço de back-end como o período mais longo que espera ser necessário para o back-end processar uma resposta HTTP.
Se o software em execução no back-end precisar de mais tempo para processar uma solicitação HTTP
e retornar a resposta inteira, recomendamos que você aumente o
tempo limite do serviço de back-end.
Por exemplo, recomendamos que você aumente o
tempo limite se receber respostas de código de status HTTP 408 com
erros jsonPayload.statusDetail client_timed_out.
O tempo limite do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. Valores maiores não são opções de configuração possíveis. Além disso, oGoogle Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end.
No caso dos balanceadores de carga de aplicativo globais e clássicos, os GFEs impõem um tempo limite máximo efetivo do serviço de back-end de 86,400 segundos (1 dia).
Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.
Para configurar o tempo limite do serviço de back-end, use um dos seguintes métodos:
Console
Modifique o campo Tempo limite 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 de serviço de back-end.
API
Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, modifique o parâmetro timeoutSec para o recurso backendServices global.
Para um balanceador de carga de aplicativo externo regional, modifique o parâmetro timeoutSec
para o
recurso regionBackendServices.
| Modo balanceador de carga | Valores padrão | Descrição do tempo limite para websockets |
|---|---|---|
| Balanceador de carga de aplicativo externo global | Tempo limite do serviço de back-end: 30 segundos | As conexões WebSocket ativas não usam o tempo limite configurado do serviço de back-end do balanceador de carga. As conexões são fechadas automaticamente após 24 horas (86.400 segundos). Esse limite de 24 horas é fixo e substitui o tempo limite do serviço de back-end se ele for maior que 24 horas. As conexões WebSocket inativas são fechadas após o tempo limite do serviço de back-end. Não recomendamos valores de tempo limite do serviço de back-end maiores que 24 horas (86.400 segundos) porque o Google Cloud reinicia periodicamente os GFEs para atualizações de software e outras manutenções de rotina. O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção. Quanto maior for o valor de tempo limite do serviço de back-end, maior será a probabilidade de o Google Cloudencerrar as conexões TCP para manutenção. |
| Balanceador de carga de aplicativo clássico | Tempo limite do serviço de back-end: 30 segundos | As conexões WebSocket, sejam elas inativas ou ativas, são fechadas automaticamente após o tempo limite do serviço de back-end. Não recomendamos valores de tempo limite do serviço de back-end maiores que 24 horas (86.400 segundos) porque o Google Cloud reinicia periodicamente os GFEs para atualizações de software e outras manutenções de rotina. O valor de tempo limite do serviço de back-end não atrasa as atividades de manutenção. Quanto maior for o valor de tempo limite do serviço de back-end, maior será a probabilidade de o Google Cloudencerrar as conexões TCP para manutenção. |
| Balanceador de carga de aplicativo externo regional | Tempo limite do serviço de back-end: 30 segundos | As conexões WebSocket ativas não usam o tempo limite do serviço de back-end do balanceador de carga. As conexões WebSocket inativas são fechadas após o tempo limite do serviço de back-end. Google Cloud reinicia ou muda periodicamente o número de tarefas de software do Envoy em atendimento. Quanto maior for o valor do tempo limite do serviço de back-end, mais provável será que as tarefas do Envoy sejam reiniciadas ou encerrem as conexões TCP. |
Os balanceadores de carga de aplicativo externos regionais usam o parâmetro
routeActions.timeout
configurado dos mapas de URL e ignoram o tempo limite do serviço de back-end. Quando
routeActions.timeout não está configurado, o valor do tempo limite do serviço de back-end é usado. Quando routeActions.timeout é fornecido,
o tempo limite do serviço de back-end é ignorado, e o valor de
routeActions.timeout é usado como o tempo limite de solicitação e resposta
em vez disso.
Tempo limite do sinal de atividade HTTP do cliente
O tempo limite do sinal de atividade HTTP do cliente representa a quantidade máxima de tempo que uma conexão TCP pode ficar ociosa entre o cliente (downstream) e um dos seguintes tipos de proxies:
- Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico: um front-end do Google de primeira camada
- Para um balanceador de carga de aplicativo externo regional: um proxy Envoy
O tempo limite do sinal de atividade HTTP do cliente representa o tempo limite de inatividade TCP das conexões TCP subjacentes. O tempo limite do sinal de atividade HTTP do cliente não se aplica a WebSockets.
O valor padrão para o tempo limite do sinal de atividade HTTP do cliente é de 610 segundos. Para balanceadores de carga de aplicativo externos globais e regionais, é possível configurar o tempo limite do sinal de atividade HTTP do cliente com um valor entre 5 e 1.200 segundos.
Para configurar o tempo limite do sinal de atividade HTTP do cliente, use um dos seguintes métodos:
Console
Modifique o campo Tempo limite do sinal de atividade HTTP da configuração de front-end do balanceador de carga.
gcloud
Para balanceadores de carga de rede de passagem 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 balanceador de carga de aplicativo externo regional, não é possível atualizar diretamente o parâmetro de tempo limite de sinal de atividade de um proxy HTTP(S) de destino regional. Para atualizar o parâmetro de tempo limite do sinal de atividade de um proxy de destino regional, faça o seguinte:
- Crie um novo proxy de destino com as configurações de tempo limite desejadas.
- Espelhe todas as outras configurações do proxy de destino atual no novo. Para proxies HTTPS de destino, isso inclui vincular certificados SSL ou mapas de certificados ao novo proxy de destino.
- Atualize as regras de encaminhamento para apontar para o novo proxy de destino.
- Exclua o proxy de destino anterior.
API
Para balanceadores de carga de aplicativo externos globais, modifique o parâmetro httpKeepAliveTimeoutSec para o recurso
targetHttpProxies ou
targetHttpsProxies.
Para um balanceador de carga de aplicativo externo regional, não é possível atualizar diretamente o parâmetro de tempo limite de sinal de atividade de um proxy HTTP(S) de destino regional. Para atualizar o parâmetro de tempo limite do sinal de atividade de um proxy de destino regional, faça o seguinte:
- Crie um novo proxy de destino com as configurações de tempo limite desejadas.
- Espelhe todas as outras configurações do proxy de destino atual no novo. Para proxies HTTPS de destino, isso inclui vincular certificados SSL ou mapas de certificados ao novo proxy de destino.
- Atualize as regras de encaminhamento para apontar para o novo proxy de destino.
- Exclua o proxy de destino anterior.
O tempo limite do sinal de atividade do cliente HTTP do balanceador de carga precisa ser maior que o tempo limite do sinal de atividade HTTP (TCP inativo) usado por clientes downstream ou proxies. Se um cliente downstream tiver o tempo limite do sinal de atividade HTTP (TCP inativo) maior do que o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga, ocorrerá uma possível disputa. Da perspectiva de um cliente downstream, uma conexão TCP estabelecida pode ficar inativa por mais tempo do que o balanceador de carga permite. Isso significa que o cliente downstream pode enviar pacotes depois que o balanceador de carga considerar a conexão TCP encerrada. Quando isso acontece, o balanceador de carga responde com um pacote de redefinição (RST) TCP.
Quando o tempo limite do sinal de atividade HTTP do cliente expira, o GFE ou o proxy Envoy envia um TCP FIN ao cliente para fechar a conexão normalmente.
Tempo limite do sinal de atividade HTTP do back-end
Os balanceadores de carga de aplicativo externos são proxies que usam pelo menos duas conexões TCP:
- Para um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico, há uma primeira conexão TCP entre o cliente (downstream) e um GFE de primeira camada. Os GFEs de primeira camada se conectam a GFEs de segunda camada e, em seguida, os GFEs de segunda camada abrem uma segunda conexão TCP com os back-ends.
- Para um balanceador de carga de aplicativo externo regional, há uma primeira conexão TCP entre o cliente (downstream) e um proxy Envoy. Em seguida, o proxy Envoy abre uma segunda conexão TCP com os back-ends.
As conexões TCP secundárias do balanceador de carga talvez não sejam encerradas após cada solicitação. Elas podem permanecer abertas para lidar com várias solicitações e respostas HTTP. O tempo limite do sinal de atividade HTTP do back-end define o tempo limite de inatividade do TCP entre o balanceador de carga e os back-ends. O tempo limite do sinal de atividade HTTP de back-end não se aplica a websockets.
O tempo limite do sinal de atividade do back-end é fixado em 10 minutos (600 segundos) e não pode ser alterado. Isso ajuda a garantir que o balanceador de carga mantenha as conexões ociosas por pelo menos 10 minutos. Depois desse período, o balanceador de carga pode enviar pacotes de encerramento para o back-end a qualquer momento.
O tempo limite do sinal de atividade do back-end do balanceador de carga precisa ser menor que o tempo limite do sinal de atividade usado pelo software em execução nos back-ends. Isso evita uma disputa em que o sistema operacional dos back-ends pode encerrar conexões TCP com uma redefinição (RST) TCP. Como o tempo limite do sinal de atividade do back-end do balanceador de carga não é configurável, é necessário configurar o software do back-end para que o valor de tempo limite do sinal de atividade HTTP (TCP inativo) seja maior que 600 segundos.
Quando o tempo limite do sinal de atividade HTTP do back-end expira, o GFE ou o proxy Envoy envia um TCP FIN para a VM de back-end para fechar a conexão normalmente.
A tabela a seguir lista as alterações necessárias para modificar os valores de tempo limite do sinal de atividade para software servidor da Web comum.
| Software servidor da Web | Parâmetro | Configuração padrão | Configuração recomendada |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
Tempo limite de inatividade da sessão QUIC
O tempo limite de inatividade da sessão QUIC representa o tempo máximo que essa sessão pode ficar inativa entre o cliente e o GFE de um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico.
O valor do tempo limite de inatividade da sessão QUIC é definido como o mínimo de um destes: tempo limite de inatividade do cliente ou tempo limite de inatividade do cliente do GFE (300 segundos). O tempo limite de inatividade do GFE é fixo em 300 segundos. O tempo limite de inatividade do cliente pode ser configurado.
Novas tentativas
A compatibilidade com a lógica de repetição depende do modo do balanceador de carga de aplicativo externo.
| Modo balanceador de carga | Lógica de repetição |
|---|---|
| Balanceador de carga de aplicativo externo global |
Configurável usando uma política de repetição no mapa de URL. O número máximo de novas tentativas ( Se você quiser desativar as novas tentativas, defina explicitamente
Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações As solicitações HTTP As solicitações repetidas geram apenas uma entrada de registro como resposta final. |
| Balanceador de carga de aplicativo clássico |
Não é possível alterar a política de novas tentativas de conexão. As solicitações HTTP As solicitações HTTP O balanceador de carga repetirá uma solicitação As solicitações repetidas geram apenas uma entrada de registro como resposta final. Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga de aplicativo externo. Solicitações malsucedidas resultam em um balanceador de carga sintetizando uma
resposta HTTP |
| Balanceador de carga de aplicativo externo regional |
Configurável usando uma política de nova tentativa no mapa de URL. O número padrão de novas tentativas ( Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações As solicitações HTTP As solicitações repetidas geram apenas uma entrada de registro como resposta final. |
O protocolo WebSocket é suportado pela Entrada do GKE.
Tratamento de solicitações e respostas inválidas
O balanceador de carga bloqueia a chegada de solicitações de cliente e respostas de back-end no back-end ou no cliente, respectivamente, por alguns motivos. Alguns deles referem-se estritamente à conformidade com HTTP/1.1 e outros servem para evitar a passagem de dados inesperados para ou de back-ends. Nenhuma das verificações pode ser desativada.
O balanceador de carga bloqueia as seguintes solicitações por conformidade HTTP/1.1:
- Não é possível analisar a primeira linha da solicitação.
- Falta o delimitador de dois-pontos (
:) em um cabeçalho. - Cabeçalhos ou a primeira linha contêm caracteres inválidos.
- O comprimento do conteúdo não é um número válido ou há vários cabeçalhos com comprimentos de conteúdo.
- Há várias chaves de codificação de transferência ou valores de codificação de transferência não reconhecidos.
- Há um corpo não fragmentado e sem comprimento de conteúdo especificado.
- Não é possível analisar os fragmentos do corpo. Esse é o único caso em que alguns dados chegam ao back-end. O balanceador de carga fecha as conexões com o cliente e o back-end quando recebe um bloco não analisável.
Processamento de solicitações
O balanceador de carga bloqueará a solicitação se alguma das seguintes condições for verdadeira:
- O tamanho total dos cabeçalhos de solicitação e URL de solicitação excede o limite de tamanho máximo de cabeçalhos de solicitação para balanceadores de carga de aplicativo externos.
- O método de solicitação não permite corpo, mas a solicitação tem um.
- A solicitação contém um cabeçalho
Upgrade, mas ele não é usado para permitir conexões WebSocket.Upgrade - A versão do HTTP é desconhecida.
Processamento de respostas
O balanceador de carga bloqueará 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 de cabeçalhos de resposta para balanceadores de carga de aplicativo externos.
- A versão do HTTP é desconhecida.
Ao processar a solicitação e a resposta, o balanceador de carga pode remover ou substituir cabeçalhos hop-by-hop em HTTP/1.1 antes de encaminhá-los ao destino pretendido.
Distribuição de tráfego
Ao adicionar um grupo de instâncias de back-end ou NEG a um serviço de back-end, você especifica um modo de balanceamento, que define um método para medir a carga de back-end e uma capacidade de destino. Os balanceadores de carga de aplicativo externos são compatíveis com dois modos de balanceamento:
RATE, para grupos de instâncias ou NEGs, é o número máximo de solicitações (consultas) por segundo (RPS, QPS). O RPS/QPS máximo do destino pode ser excedido se todos os back-ends atingirem ou ultrapassarem a capacidade.UTILIZATIONé o uso de back-ends de VMs em um grupo de instâncias.
A distribuição do tráfego entre back-ends depende do modo do balanceador de carga.
Balanceador de carga de aplicativo externo global
Antes de um Google Front End (GFE) enviar solicitações a instâncias de back-end, o GFE avalia quais delas têm capacidade para receber solicitações. Essa estimativa de capacidade é feita proativamente, e não ao mesmo tempo que as solicitações chegam. Os GFEs recebem informações periódicas sobre a capacidade disponível e distribuem as solicitações recebidas de acordo.
O significado de capacidade depende, em parte, do modo de balanceamento. Quanto ao modo
RATE, é relativamente simples: um GFE determina exatamente quantas solicitações ele pode
atribuir por segundo. O balanceamento de carga baseado em UTILIZATION é mais complexo: o balanceador
de carga verifica o uso atual das instâncias e, em seguida, calcula uma carga de
consulta que cada instância pode processar. Essa estimativa muda ao longo do tempo à medida que o uso da
instância e os padrões de tráfego mudam.
Ambos os fatores (a estimativa de capacidade e a atribuição proativa) influenciam a distribuição entre as instâncias. Assim, o Cloud Load Balancing se comporta de maneira diferente de um balanceador de carga round-robin simples que distribui as solicitações exatamente meio a meio entre duas instâncias. Em vez disso,o balanceamento de carga do Google Cloud tenta otimizar a seleção de instância de back-end para cada solicitação.
Para o balanceador de carga de aplicativo externo global, o balanceamento de carga é de duas camadas. O modo de
balanceamento determina a ponderação ou fração de tráfego que precisa ser enviada para 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 para as instâncias ou
endpoints no grupo. Para mais informações, consulte a política de localidade de
balanceamento de carga (documentação da API
Backend Service).
Para o balanceador de carga clássico do aplicativo, o modo de balanceamento é usado para selecionar o back-end mais favorável (grupo de instâncias ou NEG). O tráfego é distribuído em estilo round-robin entre instâncias ou endpoints no back-end.
Como as solicitações são distribuídas
Balanceadores de carga de aplicativo externos baseados no GFE usam o seguinte processo para distribuir solicitações recebidas:
- Do cliente para o GFE de primeira camada. Os roteadores de borda divulgam o endereço IP externo da regra de encaminhamento nas bordas da rede do Google.
Cada anúncio lista um próximo salto para um sistema de balanceamento de carga de camada 3 e camada 4 (Maglev). Os sistemas Maglev encaminham o tráfego para um Google Front End (GFE) de primeira camada.
- Ao usar o nível Premium, o Google divulga o endereço IP do seu balanceador de carga de todos os pontos de presença em todo o mundo. Cada endereço IP do balanceador de carga é anycast global.
- Ao usar o nível Standard, o Google divulga o endereço IP do balanceador de carga de pontos de presença associados à região da regra de encaminhamento. O balanceador de carga usa um endereço IP externo regional. Ao usar uma regra de encaminhamento de nível Standard, você se limita a grupo de instâncias e back-ends de NEG zonal na mesma região da regra de encaminhamento do balanceador de carga.
- Do GFE de primeira camada para o GFE de segunda camada. O GFE de primeira camada encerra o TLS, se necessário, e depois encaminha o tráfego para os GFEs de segunda camada de acordo com este processo:
- Os GFEs de primeira camada analisam o mapa de URLs e selecionam um serviço ou bucket de back-end.
- Para serviços de back-end com NEGs da Internet, os GFEs de primeira camada selecionam um gateway de encaminhamento externo de segunda camada que está em colocation com o GFE de primeira camada. O gateway de encaminhamento envia solicitações para o endpoint do NEG na Internet. Isso conclui o processo de distribuição de solicitações para NEGs da Internet.
- Para serviços de back-end com NEGs sem servidor e NEGs do Private Service Connect (PSC) e buckets de back-end de região única, os GFEs de primeira camada selecionam um GFE de segunda camada na região correspondente àquela do NEG ou bucket. Para buckets multirregionais do Cloud Storage, os GFEs de primeira camada selecionam GFEs de segunda camada na região do bucket ou em uma região o mais próxima possível do bucket multirregional (definido pelo tempo de retorno da rede).
- Para serviços de back-end com grupos de instâncias, NEGs zonais com endpoints
GCE_VM_IP_PORTe NEGs híbridos, o sistema de gerenciamento de capacidade do Google informa aos GFEs de primeira camada a capacidade usada e configurada de cada back-end. A capacidade configurada de um back-end é definida pelo modo de balanceamento, a capacidade desejada do modo de balanceamento e o escalonador de capacidade.- Nível Standard:os GFEs de primeira camada selecionam um GFE de segunda camada na região que contém os back-ends.
- Nível Premium:os GFEs de primeira camada selecionam GFEs de segunda camada de um conjunto de regiões aplicáveis. As regiões aplicáveis são todas aquelas em que os back-ends foram configurados, exceto as regiões com back-ends configurados com capacidade zero. Os GFEs de primeira camada selecionam o GFE de segunda camada mais próximo em uma região aplicável (definido pelo tempo de retorno da rede). Se os back-ends estiverem configurados em duas ou mais regiões, os GFEs de primeira camada poderão distribuir solicitações para outras regiões aplicáveis se uma região de primeira escolha estiver cheia. A distribuição para outras regiões é possível quando todos os back-ends na região de primeira escolha estão no limite da capacidade.
- Os GFEs de segunda camada selecionam back-ends. Os GFEs de segunda camada estão localizados em zonas de uma região. Eles 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 buckets de back-end, os GFEs de segunda camada encaminham solicitações para os sistemas de produção do Google. Isso conclui o processo de distribuição de solicitações para esses back-ends.
Para serviços de back-end com grupos de instâncias, NEGs zonais com endpoints
GCE_VM_IP_PORTe NEGs híbridos, os sistemas de sondagem de verificação de integridade do Google informam aos GFEs de segunda camada sobre o status da verificação de integridade dos endpoints ou das instâncias de back-end.Somente nível Premium: se o GFE de segunda camada não tiver endpoints ou instâncias de back-end íntegros na região, ele poderá enviar solicitações para outro GFE de segunda camada em uma região aplicável diferente com back-ends configurados. A distribuição entre GFEs de segunda camada em diferentes regiões não esgota todas as combinações possíveis entre regiões. Se você precisar direcionar o tráfego para longe dos back-ends em uma região específica, em vez de configurar os back-ends para que falhem nas verificações de integridade, defina o escalonador de capacidade do back-end como zero para que o GFE de primeira camada exclua a região durante a etapa anterior.
Em seguida, o GFE de segunda camada direciona as solicitações para endpoints ou instâncias de back-end em zonas dentro da região dele, conforme discutido na próxima etapa.
O GFE de segunda camada seleciona uma zona. Por padrão, os GFEs de segunda camada usam o algoritmo
WATERFALL_BY_REGION, em que cada GFE de segunda camada prefere selecionar endpoints ou instâncias de back-end na mesma zona que contém o GFE de segunda camada. ComoWATERFALL_BY_REGIONminimiza o tráfego entre zonas, com baixas taxas de solicitação, cada GFE de segunda camada pode enviar solicitações exclusivamente para back-ends na mesma zona que o próprio GFE de segunda camada.Somente para balanceadores de carga de aplicativo globais externos, os GFEs de segunda camada podem ser configurados para que usem um dos seguintes algoritmos alternativos com um
serviceLbPolicy:SPRAY_TO_REGION: os GFEs de segunda camada não preferem selecionar endpoints ou instâncias de back-end na mesma zona que o GFE de segunda camada. Os GFEs de segunda camada tentam distribuir o tráfego para todos os endpoints ou instâncias de back-end em todas as zonas da região. Isso pode levar a uma distribuição mais uniforme da carga, à custa do aumento do tráfego entre as zonas.WATERFALL_BY_ZONE: os GFEs de segunda camada preferem expressamente selecionar instâncias de back-end ou endpoints na mesma zona que o GFE de segunda camada. Os GFEs de segunda camada só direcionam solicitações para back-ends em zonas diferentes depois que todos os back-ends na zona atual atingirem as capacidades configuradas.
- O GFE de segunda camada seleciona instâncias ou endpoints dentro da zona. Por padrão, um GFE de segunda camada distribui solicitações entre back-ends de maneira round-robin. Somente para balanceadores de carga de aplicativo externos globais, é possível alterar isso usando uma política de localidade de balanceamento de carga (
localityLbPolicy). Essa política se aplica apenas aos back-ends dentro da zona selecionada discutida na etapa anterior.
Balanceador de carga de aplicativo externo regional
Para balanceadores de carga de aplicativo externos regionais, a distribuição de tráfego é baseada no modo de balanceamento de carga e na política de localidade do balanceamento de carga.
O modo de balanceamento determina a ponderação e fração do tráfego que precisa ser enviada para
cada back-end (grupo de instâncias ou NEG). A política de localidade do balanceamento de carga
(LocalityLbPolicy) determina como os back-ends do grupo são balanceados por carga.
Quando um serviço de back-end recebe tráfego, ele direciona primeiro o tráfego para um back-end (grupo de instâncias ou NEG ) de acordo com o modo de balanceamento do back-end. Depois que um back-end é selecionado, o tráfego é distribuído entre as instâncias ou os endpoints do grupo, de acordo com a política de localidade do balanceamento de carga.
Para ver mais informações, consulte os seguintes tópicos:
- Modos de balanceamento
- Política de localidade do balanceamento de carga (documentação da API de serviço de back-end regional).
afinidade da sessão
A afinidade de sessão, configurada no serviço de back-end dos balanceadores de carga de aplicativo, oferece uma tentativa de melhor esforço para enviar solicitações de um cliente específico para o mesmo back-end enquanto o número de instâncias ou endpoints de back-end íntegros permanecer constante e enquanto a instância ou o endpoint de back-end selecionado anteriormente não estiver atingindo a capacidade. A capacidade de destino do modo de balanceamento determina quando o back-end está no limite.
A tabela a seguir descreve os diferentes tipos de opções de afinidade da sessão compatíveis com os diferentes balanceadores de carga de aplicativo. Na seção a seguir, Tipos de afinidade da sessão, cada tipo é discutido em mais detalhes.
| Produto | Opções de afinidade de sessão |
|---|---|
Outras observações:
|
|
| Balanceador de carga de aplicativo clássico |
|
Lembre-se do seguinte ao configurar a afinidade da sessão:
Não confie na afinidade da sessão para fins de autenticação ou segurança. A afinidade da sessão, exceto a afinidade da sessão baseada em cookie com estado, pode ser interrompida sempre que o número de back-ends de exibição e íntegros muda. Para mais detalhes, consulte Perda de afinidade da sessão.
Os valores padrão das sinalizações
--session-affinitye--subsetting-policysãoNONE, e apenas um por vez pode ser definido como um valor diferente.
Tipos de afinidade da sessão
A afinidade da sessão para balanceadores de carga de aplicativo externos pode ser classificada em uma das seguintes categorias:- Afinidade da sessão baseada em hash (
NONE,CLIENT_IP) - Afinidade da sessão baseada em cabeçalho HTTP (
HEADER_FIELD) - Afinidade da sessão baseada em cookie (
GENERATED_COOKIE,HTTP_COOKIE,STRONG_COOKIE_AFFINITY)
Afinidade da sessão baseada em hash
Para a afinidade da sessão baseada em hash, o balanceador de carga usa o algoritmo de hash consistente para selecionar um back-end qualificado. A configuração de afinidade da sessão determina quais campos do cabeçalho IP são usados para calcular o hash.
Afinidade da sessão baseada em hash pode ser dos seguintes tipos:
Nenhum
Uma configuração de afinidade da sessão de NONE não significa que não há afinidade da sessão. Isso significa que nenhuma opção afinidade da sessão foi configurada explicitamente.
O hash é sempre realizado para selecionar um back-end. Uma configuração de afinidade da sessão de
NONE significa que o balanceador de carga usa um hash de cinco tuplas para selecionar um back-end. O hash de 5 tuplas 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 da sessão de NONE é o valor padrão.
Afinidade de IP do cliente
A afinidade da sessão IP do cliente (CLIENT_IP) é um hash de duas tuplas criado com os endereços IP de origem e destino do pacote. A afinidade de IP do cliente encaminha
todas as solicitações do mesmo endereço IP do cliente para o mesmo back-end, desde que
esse back-end tenha capacidade e se mantenha íntegro.
Ao usar a afinidade de IP do cliente, lembre-se do 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 ou sistema de proxy intermediário antes de ser entregue a um balanceador de carga Google Cloud . Em situações em que muitos clientes compartilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais conexões ou solicitações do que outras.
Afinidade da sessão baseada em cabeçalho HTTP
Com a afinidade do campo de cabeçalho (HEADER_FIELD), as solicitações são encaminhadas para os back-ends com base no valor do cabeçalho HTTP no campo consistentHash.httpHeaderName do serviço de back-end. Para distribuir solicitações em todos os back-ends disponíveis, cada cliente precisa usar um valor de cabeçalho HTTP diferente.
A afinidade do campo de cabeçalho é aceita quando as seguintes condições são verdadeiras:
- A política de localidade do balanceamento de carga é
RING_HASHouMAGLEV. - O
consistentHashdo serviço de back-end especifica o nome do cabeçalho HTTP (httpHeaderName).
Afinidade da sessão baseada em cookie
Afinidade da sessão baseada em cookies pode ser dos seguintes tipos:
- Afinidade de cookie gerado
- Afinidade de cookie HTTP
- Afinidade da sessão com estado baseada em cookie
Afinidade de cookie gerado
Quando você usa a afinidade baseada em cookie gerado (GENERATED_COOKIE), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial.
O nome do cookie gerado varia de acordo com o tipo de balanceador de carga.
| Produto | Nome do cookie |
|---|---|
| Balanceadores de carga de aplicativos externos globais | GCLB |
| Balanceadores de carga de aplicativo clássicos | GCLB |
| Balanceadores de carga de aplicativo externos regionais | GCILB |
O atributo de caminho do cookie gerado é sempre uma barra (/), então ele se aplica a todos os serviços de back-end no mesmo mapa de URL, desde que os outros serviços de back-end também usem a afinidade de cookie gerado.
É possível configurar o valor de time to live (TTL) do cookie entre 0 e
1,209,600 segundos (inclusive) usando o parâmetro de serviço
de back-end affinityCookieTtlSec. Se affinityCookieTtlSec não for especificado, o valor padrão de TTL será 0.
Quando o cliente inclui o cookie afinidade da sessão gerado no cabeçalho de solicitação Cookie
de solicitações HTTP, o balanceador de carga direciona essas
solicitações para a mesma instância ou endpoint de back-end, desde que o cookie de
afinidade de sessão permaneça válido. Isso é feito mapeando o valor do cookie para um
índice que faz referência a uma instância de back-end ou um endpoint específico
e garantindo que os requisitos afinidade da sessão do cookie gerado
sejam atendidos.
Para usar a afinidade de cookie gerado, configure o seguinte modo de balanceamento e as configurações de localityLbPolicy:
- Para grupos de instâncias de back-end, use o modo de balanceamento
RATE. - Para o
localityLbPolicydo serviço de back-end, useRING_HASHouMAGLEV. Se você não definir explicitamente olocalityLbPolicy, o balanceador de carga usaráMAGLEVcomo um padrão implícito.
Para mais informações, consulte perda da afinidade de sessão.
Afinidade de cookie HTTP
Quando você usa a afinidade baseada em cookie HTTP (HTTP_COOKIE), o balanceador de carga
inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação
HTTP inicial. Você especifica o nome, o caminho e o time to live (TTL) do cookie.
Todos os balanceadores de carga de aplicativo oferecem suporte à afinidade baseada em cookies HTTP.
É possível configurar os valores de TTL do cookie usando segundos, frações de segundo (como nanossegundos) ou ambos (segundos mais frações de segundo, como nanossegundos) usando os seguintes parâmetros e valores válidos do serviço de back-end:
consistentHash.httpCookie.ttl.secondspode ser definido como um valor entre0e315576000000(inclusive).consistentHash.httpCookie.ttl.nanospode ser definido como um valor entre0e999999999(inclusive). Como as unidades são nanossegundos,999999999significa.999999999segundos.
Se consistentHash.httpCookie.ttl.seconds e consistentHash.httpCookie.ttl.nanos não forem especificados, o valor do parâmetro affinityCookieTtlSec do serviço de back-end será usado. Se affinityCookieTtlSec não for especificado, o valor padrão de TTL será 0.
Quando o cliente inclui o cookie afinidade da sessão HTTP no cabeçalho de solicitação Cookie
de solicitações HTTP, o balanceador de carga direciona essas
solicitações para a mesma instância ou endpoint de back-end, desde que o cookie de
afinidade de sessão permaneça válido. Isso é feito mapeando o valor do cookie para um
índice que faz referência a uma instância de back-end ou um endpoint específico
e garantindo que os requisitos afinidade da sessão do cookie gerado
sejam atendidos.
Para usar a afinidade de cookie HTTP, configure o seguinte modo de balanceamento
e as configurações de localityLbPolicy:
- Para grupos de instâncias de back-end, use o modo de balanceamento
RATE. - Para o
localityLbPolicydo serviço de back-end, useRING_HASHouMAGLEV. Se você não definir explicitamente olocalityLbPolicy, o balanceador de carga usaráMAGLEVcomo um padrão implícito.
Para mais informações, consulte perda da afinidade de sessão.
Afinidade da sessão com estado baseada em cookie
Quando você usa a afinidade baseada em cookie com estado (STRONG_COOKIE_AFFINITY), o balanceador de carga inclui um cookie HTTP no cabeçalho Set-Cookie em resposta à solicitação HTTP inicial. Você especifica o nome, o caminho e time to live (TTL) do
cookie.
Todos os balanceadores de carga de aplicativo, exceto os clássicos, oferecem suporte à afinidade com estado baseada em cookies.
É possível configurar os valores de TTL do cookie usando segundos, frações de um segundo (como nanossegundos) ou ambos.
A duração representada por strongSessionAffinityCookie.ttl não pode ser definida como um valor que represente mais de duas semanas (1.209.600 segundos).
O valor do cookie identifica uma instância ou um endpoint de back-end selecionado
codificando a instância ou o endpoint selecionado no próprio valor. Enquanto o cookie for válido, se o cliente incluir o cookie afinidade da sessão no cabeçalho de solicitação Cookie de solicitações HTTP subsequentes, o balanceador de carga vai direcionar essas solicitações para a instância ou o endpoint de back-end selecionado.
Ao contrário de outros métodos de afinidade da sessão:
A afinidade baseada em cookie com estado não tem requisitos específicos para o modo de balanceamento ou para a política de localidade de balanceamento de carga (
localityLbPolicy).A afinidade com estado baseada em cookies não é afetada quando o escalonamento automático adiciona uma nova instância a um grupo gerenciado de instâncias.
A afinidade com estado baseada em cookies não é afetada quando o escalonamento automático remove uma instância de um grupo gerenciado de instâncias, a menos que a instância selecionada seja removida.
A afinidade com estado baseada em cookies não é afetada quando a recuperação automática remove uma instância de um grupo gerenciado de instâncias a menos que a instância selecionada seja removida.
Para mais informações, consulte perda da afinidade de sessão.
Significado de TTL zero para afinidades baseadas em cookies
Todas as afinidades de sessão baseadas em cookie, como afinidade de cookie gerado, afinidade de cookie HTTP e afinidade baseada em cookie com estado, têm um atributo TTL.
Um TTL de zero segundos significa que o balanceador de carga não atribui um atributo Expires ao cookie. Nesse caso, o cliente trata o cookie como um cookie de
sessão. A definição de uma sessão varia de acordo com o cliente:
Alguns clientes, como navegadores da Web, retêm o cookie durante toda a sessão de navegação. Isso significa que o cookie persiste em várias solicitações até que o aplicativo seja fechado.
Outros clientes tratam uma sessão como uma única solicitação HTTP, descartando o cookie imediatamente depois.
Perda da afinidade da sessão
Todas as opções afinidade da sessão exigem o seguinte:
- A instância ou o endpoint de back-end selecionado precisa permanecer configurado como um
back-end. A afinidade da sessão pode ser interrompida quando um dos seguintes eventos ocorre:
- Remova a instância selecionada do grupo de instâncias.
- O escalonamento automático ou a recuperação automática do grupo de instâncias gerenciadas remove a instância selecionada do grupo.
- Você remove o endpoint selecionado do NEG.
- Remova do serviço de back-end o grupo de instâncias ou o NEG que contém a instância ou o endpoint selecionado.
- A instância ou o endpoint de back-end selecionado precisa permanecer íntegro. A afinidade de sessão pode ser interrompida quando a instância ou o endpoint selecionado falha nas verificações de integridade.
- Para balanceadores de carga de aplicativo externos globais e clássicos, afinidade da sessão pode ser interrompida se um Google Front End (GFE) de primeira camada diferente for usado para solicitações ou conexões subsequentes após a mudança no caminho de roteamento. Um GFE de primeira camada diferente pode ser selecionado se o caminho de roteamento de um cliente na Internet para o Google mudar entre solicitações ou conexões.
O grupo de instâncias ou NEG que contém a instância ou o endpoint selecionado não pode estar cheio, conforme definido pela capacidade desejada. Para grupos gerenciados de instâncias regionais, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio. A afinidade da 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. Como o nível de ocupação pode mudar de maneiras imprevisíveis ao usar o modo de balanceamento
UTILIZATION, use o modoRATEouCONNECTIONpara minimizar situações em que a afinidade da sessão pode ser interrompida.O número total de instâncias ou endpoints de back-end configurados precisa permanecer constante. Quando pelo menos um dos seguintes eventos ocorre, o número de instâncias ou endpoints de back-end configurados muda, e a afinidade da sessão pode ser interrompida:
Adicionar novas instâncias ou endpoints:
- Você adiciona instâncias a um grupo de instâncias atual no serviço de back-end.
- O escalonamento automático de grupos gerenciados de instâncias adiciona instâncias a um grupo gerenciado de instâncias no serviço de back-end.
- Você adiciona endpoints a um NEG atual no serviço de back-end.
- Adicione grupos de instâncias ou NEGs não vazios ao serviço de back-end.
Remover qualquer instância ou endpoint, não apenas a instância ou o endpoint selecionado:
- Você remove qualquer instância de um back-end de grupo de instâncias.
- O escalonamento automático ou a recuperação automática de um grupo de instâncias gerenciadas remove qualquer instância de um back-end grupo gerenciado de instâncias.
- Você remove qualquer endpoint de um back-end de 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 endpoints de back-end íntegros precisa permanecer constante. Quando pelo menos um dos seguintes eventos ocorre, o número de instâncias ou endpoints de back-end íntegros muda, e a afinidade da sessão pode ser interrompida:
- Qualquer instância ou endpoint passa na verificação de integridade, fazendo a transição de não íntegro para íntegro.
- Qualquer instância ou endpoint falha na verificação de integridade, passando de íntegro para não íntegro ou tempo limite.