Distribuição de solicitações para balanceadores de carga de aplicativo externos

Neste documento, mostramos como os balanceadores de carga de aplicativo externos lidam com conexões, roteiam o 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 em conformidade e escalonáveis em todo o mundo 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 apenas de 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 das configurações de serviço de back-end, o protocolo usado pelos proxies do 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.0, HTTP/1.1, HTTP/2 ou HTTP/3.
  • 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 Google Cloud endereço IP externo do balanceador de carga. 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 de um proxy de encaminhamento).
    • Endereço IP de destino: o endereço IP do 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 como 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 rede VPC para rotear pacotes para os seguintes tipos de tráfego:

OGoogle Cloud usa rotas de sub-rede para sub-redes somente proxy para rotear pacotes para os 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.

término de TLS

A tabela a seguir resume como o término de TLS é processado 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 tiver retornado toda a resposta HTTP ao balanceador de carga dentro desse limite de tempo, os dados de resposta restantes serão descartados.
  • Para todos os outros tipos de back-end em um serviço de back-end: 30 segundos

Tempo limite de configuração da conexão

O tempo máximo permitido para o proxy estabelecer uma conexão com o back-end. Uma configuração bem-sucedida inclui a conclusão do handshake de três vias do TCP e, se o protocolo de back-end for HTTPS, a conclusão do handshake de TLS.

  • Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.
 4,5 segundos

Tempo limite de TLS do cliente

O tempo máximo que o proxy do balanceador de carga aguarda a conclusão do handshake de TLS.

  • Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.
 10 segundos
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.

  • Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.
 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.

  • Para balanceadores de carga de aplicativo externos regionais, o proxy do balanceador de carga é o software Envoy.
  • Para serviços de back-end: 10 minutos (600 segundos)

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 você 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 toda a resposta, 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. OGoogle Cloud também 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.

Os tempos limite de conexão do Websocket nem sempre são os mesmos que os tempos limite do serviço de back-end. O tempo limite da conexão WebSocket depende do tipo de balanceador de carga:

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.

OGoogle Cloud periodicamente reinicia ou altera o número de tarefas de software do Envoy em atendimento. Quanto maior o valor do tempo limite do serviço de back-end, maiores as chances de conexões TCP serem encerradas ou reiniciadas por tarefas do Envoy.

Os balanceadores de carga de aplicativo externos regionais usam o parâmetro routeAction.timeout configurado dos mapas de URL e ignoram o tempo limite do serviço de back-end. Quando routeAction.timeout não está configurado, o valor do tempo limite do serviço de back-end é usado. Quando routeAction.timeout é fornecido, o tempo limite do serviço de back-end é ignorado, e o valor de routeAction.timeout é usado como o tempo limite de solicitação e resposta.

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 de sinal de atividade HTTP do cliente representa o tempo limite de inatividade TCP das conexões TCP subjacentes. O tempo limite de sinal de atividade HTTP do cliente não se aplica aos WebSockets.

O valor padrão do 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 aplicativo 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 o parâmetro de tempo limite de keepalive de um proxy HTTP(S) de destino regional diretamente. Para atualizar o parâmetro de tempo limite do sinal de atividade de um proxy de destino regional, faça o seguinte:

  1. Crie um novo proxy de destino com as configurações de tempo limite pretendidas.
  2. Espelhe todas as outras configurações do proxy de destino atual no novo. Para proxies HTTPS de destino, isso inclui vincular todos os certificados SSL ou mapas de certificados ao novo proxy de destino.
  3. Atualize as regras de encaminhamento para apontar para o novo proxy de destino.
  4. 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 o recurso targetHttpsProxies.

Para um balanceador de carga de aplicativo externo regional, não é possível atualizar o parâmetro de tempo limite de keepalive de um proxy HTTP(S) de destino regional diretamente. Para atualizar o parâmetro de tempo limite do sinal de atividade de um proxy de destino regional, faça o seguinte:

  1. Crie um novo proxy de destino com as configurações de tempo limite pretendidas.
  2. Espelhe todas as outras configurações do proxy de destino atual no novo. Para proxies HTTPS de destino, isso inclui vincular todos os certificados SSL ou mapas de certificados ao novo proxy de destino.
  3. Atualize as regras de encaminhamento para apontar para o novo proxy de destino.
  4. 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 do Envoy envia um TCP FIN ao cliente para encerrar a conexão de maneira adequada.

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 inativas por pelo menos 10 minutos. Após esse 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 de maneira adequada.

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 (numRetries) é 1. O número máximo de novas tentativas que pode ser configurado usando a política é 25. O perTryTimeout máximo configurável é de 24 horas.

Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 serão repetidas uma vez.

As solicitações HTTP POST não são repetidas.

As solicitações repetidas geram apenas uma entrada de registro como resposta final.

O protocolo WebSocket é compatível com o Ingress 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.

A tabela a seguir especifica os diferentes tipos de solicitações que são bloqueadas por balanceadores de carga de aplicativo externos para conformidade com HTTP/1.1.

Nesta tabela, indica uma solicitação bloqueada pelo balanceador de carga, e indica uma solicitação permitida pelo balanceador de carga.

Tipo de solicitação Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico Balanceador de carga de aplicativo externo regional
Não foi possível analisar a primeira linha da solicitação.
Um cabeçalho não tem o delimitador de dois pontos (:).
Cabeçalhos ou a primeira linha contêm caracteres inválidos.
O tamanho do conteúdo não é um número válido ou há vários cabeçalhos de tamanho de conteúdo.
Há várias chaves de codificação de transferência ou há valores de codificação de transferência não reconhecidos.
Há um corpo não fragmentado e sem comprimento de conteúdo especificado. 1
Não é possível analisar os blocos 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 que não pode ser analisado.

1 O proxy retorna uma resposta HTTP 411 para a solicitação, mas tenta analisar o corpo não fragmentado como uma solicitação subsequente. Se o corpo não fragmentado for uma solicitação HTTP válida, ele será analisado e enviado ao back-end.

Processamento de solicitações

A tabela a seguir especifica quais balanceadores de carga de aplicativo externos bloqueiam uma solicitação se ela atender a qualquer uma das condições listadas na primeira coluna da tabela.

Nesta tabela, indica uma solicitação bloqueada pelo balanceador de carga, e indica uma solicitação permitida pelo balanceador de carga.

Condição Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico Balanceador de carga de aplicativo externo regional
O tamanho total dos cabeçalhos da solicitação e URL de solicitação excede o limite de tamanho máximo de cabeçalhos da 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, e o cabeçalho Upgrade não é usado para ativar conexões WebSocket.
A versão do HTTP é desconhecida.

Processamento de respostas

A tabela a seguir especifica quais balanceadores de carga de aplicativo externos bloqueiam uma solicitação se ela atender a qualquer uma das condições listadas na primeira coluna da tabela.

Nesta tabela, indica uma solicitação bloqueada pelo balanceador de carga, e indica uma solicitação permitida pelo balanceador de carga.

Condição Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico Balanceador de carga de aplicativo externo regional
O tamanho total dos cabeçalhos de resposta excede o limite de tamanho máximo de cabeçalhos de resposta para o balanceador de carga.
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 de medição da 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:

afinidade da sessão

A afinidade da sessão, configurada no serviço de back-end dos balanceadores de carga de aplicativo, fornece uma tentativa de melhor esforço para enviar solicitações de um cliente específico ao mesmo back-end, desde que o número de instâncias ou endpoints de back-end íntegros permaneça constante e desde que a instância de back-end ou o endpoint selecionado anteriormente não esteja 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 de afinidade da sessão é discutido em mais detalhes.

Tabela:configurações de afinidade da sessão compatíveis
Produto Opções de afinidade da sessão

Balanceador de carga de aplicativo externo regional
  • Nenhum (NONE)
  • IP do cliente (CLIENT_IP)
  • Cookie gerado (GENERATED_COOKIE)
  • Campo de cabeçalho (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Afinidade com estado baseada em cookie (STRONG_COOKIE_AFFINITY)

Outras observações:

  • O valor padrão efetivo da política de localidade de balanceamento de carga (localityLbPolicy) muda de acordo com as configurações de afinidade da sessão. Se a afinidade da sessão não estiver configurada, ou seja, se a afinidade da sessão permanecer com o valor padrão de NONE, o valor padrão de localityLbPolicy será ROUND_ROBIN. Se a afinidade da sessão for definida como um valor diferente de NONE, o valor padrão de localityLbPolicy será MAGLEV.

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-affinity e --subsetting-policy são NONE, 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 com base em hash (NONE, CLIENT_IP)
  • Afinidade da sessão baseada em cabeçalho HTTP (HEADER_FIELD)
  • Afinidade da sessão com base em cookies (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Afinidade da sessão com base em hash

Para afinidade da sessão baseada em hash, o balanceador de carga usa o algoritmo de hashing 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.

A 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 de afinidade da sessão está explicitamente configurada.

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 cinco 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 base nos 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ó será 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 sistema NAT ou proxy intermediário antes de ser entregue a um balanceador de carga do 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 de campo de cabeçalho (HEADER_FIELD), as solicitações são roteadas 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_HASH ou MAGLEV.
  • O consistentHash do serviço de back-end especifica o nome do cabeçalho HTTP (httpHeaderName).

A afinidade da sessão com base em cookies pode ser dos seguintes tipos:

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 (/). Portanto, 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 de TTL padrão será 0.

Quando o cliente inclui o cookie de afinidade da sessão gerado no cabeçalho da solicitação Cookie das solicitações HTTP, o balanceador de carga direciona essas solicitações para a mesma instância de back-end ou endpoint, desde que o cookie de afinidade da sessão permaneça válido. Para isso, o valor do cookie é mapeado para um índice que faz referência a uma instância de back-end ou um endpoint específico, e os requisitos de afinidade da sessão do cookie gerado são atendidos.

Para usar a afinidade de cookie gerado, defina as seguintes configurações de modo de balanceamento e localityLbPolicy:

  • Para grupos de instâncias de back-end, use o modo de balanceamento RATE.
  • Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se você não definir explicitamente o localityLbPolicy, o balanceador de carga usará MAGLEV como um padrão implícito.

Para mais informações, consulte Perda de afinidade da sessão.

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. Especifique o nome, o caminho e o time to live (TTL) do cookie.

Todos os balanceadores de carga de aplicativo são compatíveis com a afinidade baseada em cookies HTTP.

É possível configurar os valores de TTL do cookie usando segundos, frações de segundo (como nanossegundos) ou segundos mais frações de segundo (como nanossegundos) usando os seguintes parâmetros de serviço de back-end e valores válidos:

  • consistentHash.httpCookie.ttl.seconds pode ser definido como um valor entre 0 e 315576000000 (incluso).
  • consistentHash.httpCookie.ttl.nanos pode ser definido como um valor entre 0 e 999999999 (incluso). Como as unidades são nanossegundos, 999999999 significa .999999999 segundos.

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

Quando o cliente inclui o cookie de afinidade da sessão HTTP no cabeçalho da solicitação Cookie das solicitações HTTP, o balanceador de carga direciona essas solicitações para a mesma instância de back-end ou endpoint, desde que o cookie de afinidade da sessão permaneça válido. Para isso, o valor do cookie é mapeado para um índice que faz referência a uma instância de back-end ou um endpoint específico, e os requisitos de afinidade da sessão do cookie gerado são atendidos.

Para usar a afinidade de cookie HTTP, defina as seguintes configurações de modo de balanceamento e localityLbPolicy:

  • Para grupos de instâncias de back-end, use o modo de balanceamento RATE.
  • Para o localityLbPolicy do serviço de back-end, use RING_HASH ou MAGLEV. Se você não definir explicitamente o localityLbPolicy, o balanceador de carga usará MAGLEV como um padrão implícito.

Para mais informações, consulte Perda de afinidade da sessão.

Afinidade da sessão com estado baseada em cookies

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 o time to live (TTL) do cookie.

Os seguintes balanceadores de carga dão suporte à 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 segundo (como nanossegundos) ou segundos mais frações de segundo (como nanossegundos). 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 de back-end ou um endpoint 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 de afinidade da sessão no cabeçalho da solicitação Cookie das solicitações HTTP subsequentes, o balanceador de carga vai direcionar essas solicitações para a instância de back-end ou o endpoint selecionado.

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

  • A afinidade com estado baseada em cookie 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 de afinidade da sessão.

Significado de TTL zero para afinidades baseadas em cookies

Todas as afinidades da 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 de afinidade da sessão exigem o seguinte:

  • A instância de back-end ou o endpoint 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 gerenciado de instâncias remove a instância selecionada do grupo.
    • Você remove o endpoint selecionado do NEG.
    • Remover 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 de back-end ou o endpoint selecionado precisa permanecer íntegro. A afinidade da 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, a 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 alteração no caminho de roteamento. Um GFE de primeira camada diferente poderá ser selecionado se o caminho de roteamento de um cliente na Internet para o Google mudar entre solicitações ou conexões.
Exceto para a afinidade da sessão baseada em cookie com estado, todas as opções de afinidade da sessão têm os seguintes requisitos adicionais:

  • 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 de destino. 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 NEG está cheio e outros grupos de instâncias ou NEGs não estão. Como a capacidade pode mudar de maneiras imprevisíveis ao usar o modo de balanceamento UTILIZATION, use o modo de balanceamento RATE ou CONNECTION para 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 eventos a seguir 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:

      • Adicionar instâncias a um grupo de instâncias atual no serviço de back-end.
      • O escalonamento automático do grupo gerenciado de instâncias adiciona instâncias a um grupo gerenciado de instâncias no serviço de back-end.
      • Adicione 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:

      • Remover qualquer instância de um back-end de grupo de instâncias.
      • O escalonamento automático ou a recuperação automática do grupo gerenciado de instâncias remove qualquer instância de um back-end de grupo gerenciado de instâncias.
      • Remover qualquer endpoint de um back-end de NEG.
      • Remova qualquer grupo de instâncias de back-end ou NEG 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 eventos a seguir 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, passando 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 atingindo o tempo limite.