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 doTrusted 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 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.Trusted Cloud Em outras palavras, há duas conexões TCP:
Para os balanceadores de carga de aplicativo externos regionais: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
OTrusted 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.
OTrusted 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 Trusted 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.
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 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 | ||
|---|---|---|---|---|
| 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.
|
|
|||
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, oTrusted 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.
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 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 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. Trusted 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 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 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; |
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 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 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:
|
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 Trusted 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.
Os seguintes balanceadores de carga são compatíveis com a afinidade com estado baseada em cookies:
- Balanceadores de carga de aplicativo externos regionais
- Balanceadores de carga de aplicativo internos regionais
É 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.