Sessões adesivas do Application Load Balancer - Elastic Load Balancing

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Sessões adesivas do Application Load Balancer

Por padrão, um Application Load Balancer roteia cada solicitação independentemente para um destino registrado com base no algoritmo de balanceamento de carga escolhido. No entanto, você pode usar o recurso sticky session (também conhecida como afinidade de sessão) para permitir que o load balancer vincule a sessão de um usuário a um destino específico. Isso garante que todas as solicitações do usuário durante a sessão sejam enviadas para o mesmo destino. Esse recurso é útil para servidores que mantêm as informações de estado em ordem para fornecer uma experiência contínua aos clientes. Para usar sticky sessions, o cliente deve oferecer suporte a cookies.

Os Application Load Balancers suportam cookies baseados em duração e cookies baseados em aplicativos. O segredo para o gerenciamento de sticky sessions é determinar por quanto tempo o load balancer deve rotear consistentemente a solicitação do usuário para o mesmo destino. As sessões sticky são habilitadas no nível do grupo de destino. Você pode usar uma combinação de viscosidade baseada em duração, viscosidade baseada em aplicativos e nenhuma aderência em todos os seus grupos-alvo.

O conteúdo dos cookies gerados pelo load balancer é criptografado usando uma chave giratória. Não é possível descriptografar nem modificar cookies gerados do load balancer.

Para ambos os tipos de aderência, o Application Load Balancer redefine a expiração dos cookies gerados após cada solicitação. Se um cookie expirar, a sessão não será mais sticky e o cliente deve remover o cookie do armazenamento de cookies.

Requirements

  • Um load balancer HTTP/HTTPS.

  • Pelo menos uma instância íntegra em cada Zona de disponibilidade.

Considerations

  • Para cookies baseados em aplicativos, os nomes de cookies precisam ser especificados individualmente para cada grupo-alvo. No entanto, para cookies baseados em duração,AWSALBé o único nome usado em todos os grupos-alvo.

  • Se você estiver usando várias camadas de Application Load Balancers, poderá habilitar sticky sessions em todas as camadas com cookies baseados em aplicativos. No entanto, com cookies baseados em duração, você pode ativar sessões adesivas somente em uma camada, porqueAWSALBé o único nome disponível.

  • A aderência baseada em aplicativos não funciona com grupos-alvo ponderados.

  • Se você tiver umAção para frenteCom vários grupos de destino, e sticky sessions estiverem habilitadas para um ou mais grupos de destino, você deve habilitar a perdurabilidade no nível do grupo de destino.

  • As conexões WebSocket são inerentemente perduráveis. Se o cliente solicitar uma atualização de conexão para WebSockets, o destino que retornará o código de status HTTP 101 para aceitar o upgrade da conexão será o destino usado na conexão do WebSockets. Após o término do upgrade do WebSockets, a perdurabilidade baseada em cookies não será usada.

  • Application Load Balancers usam aExpiresNo cabeçalho do cookie em vez doMax-Ageatributo.

  • Os balanceadores de carga do aplicativo não oferecem suporte a valores de cookie codificados por URL.

Viscosidade baseada em duração

A perdurabilidade roteia solicitações para o mesmo destino em um grupo de destino usando um cookie gerado por um load balancer (AWSALB). O cookie é usado para mapear a sessão para o destino. Se seu aplicativo não tiver seu próprio cookie de sessão, você poderá especificar sua própria duração de perdurabilidade e gerenciar por quanto tempo o load balancer deve rotear consistentemente a solicitação do usuário para o mesmo destino.

Quando um load balancer recebe uma solicitação de um cliente pela primeira vez, ele roteia a solicitação para um destino (com base no algoritmo escolhido) e gera um cookie chamadoAWSALB. Ele codifica informações sobre o destino selecionado, criptografa o cookie e inclui o cookie na resposta ao cliente. O cookie gerado pelo balanceador de carga tem sua própria expiração de 7 dias, o que não é configurável.

Em solicitações subsequentes, o cliente deve incluir oAWSALBCookie. Quando o load balancer recebe uma solicitação de um cliente contendo o cookie, ele o detecta e roteia a solicitação para o mesmo destino. Se o cookie estiver presente, mas não puder ser decodificado, ou se ele se referir a um destino que foi cancelado ou não está íntegro, o load balancer selecionará um novo destino e atualizará o cookie com informações sobre o novo destino.

Com solicitações de compartilhamento de recursos de origem cruzada (CORS), alguns navegadores exigemSameSite=None; Securepara permitir a aderência. Nesse caso, o balanceador de carga gera um segundo cookie de aderência,AWSALBCORS, que inclui as mesmas informações que o cookie de perdurabilidade original, além doSameSiteatributo. Os clientes recebem ambos os cookies.

Para habilitar a perdurabilidade usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, emBalanceamento de carga, escolhaGrupos de destino.

  3. Escolha o nome do grupo de destino para abrir sua página de detalhes.

  4. NoDetalhes do grupo doguia, na guiaAtributos.seção, selecioneEdite.

  5. Na página Editar atributos, faça o seguinte:

    1. SelectStickiness.

    2. para oTipo de pertensão, selecioneCookie gerado pelo load balancer.

    3. Em Duração da perdurabilidade, especifique um valor entre um segundo e sete dias.

    4. Selecione Save changes.

Para habilitar a perdurabilidade usando aAWS CLI

Use o comando modify-target-group-attributes com os atributos stickiness.enabled e stickiness.lb_cookie.duration_seconds.

Use o seguinte comando para habilitar a perdurabilidade.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

Sua saída deve ser similar ao seguinte exemplo.

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.lb_cookie.duration_seconds", "Value": "86500" }, ... ] }

Advisidade baseada no aplicativo

A aderência baseada em aplicativos oferece a flexibilidade de definir seus próprios critérios para a aderência do alvo do cliente. Quando você habilita a aderência baseada em aplicativos, o balanceador de carga roteia a primeira solicitação para um destino dentro do grupo de destino com base no algoritmo escolhido. Espera-se que o destino defina um cookie de aplicativo personalizado que corresponda ao cookie configurado no balanceador de carga para permitir a aderência. Este cookie personalizado pode incluir qualquer um dos atributos de cookie exigidos pelo aplicativo.

Quando o Application Load Balancer recebe o cookie de aplicativo personalizado do destino, ele gera automaticamente um novo cookie de aplicativo criptografado para capturar informações de aderência. Esse cookie de aplicativo gerado por balanceador de carga captura informações de aderência para cada grupo-alvo que tem a aderência baseada em aplicativos ativada.

O cookie de aplicativo gerado pelo balanceador de carga não copia os atributos do cookie personalizado definido pelo destino. Tem seu próprio vencimento de 7 dias, o que não é configurável. Na resposta ao cliente, o Application Load Balancer valida apenas o nome com o qual o cookie personalizado foi configurado no nível do grupo de destino e não o valor ou o atributo de expiração do cookie personalizado. Contanto que o nome corresponda, o balanceador de carga envia ambos os cookies, o cookie personalizado definido pelo destino e o cookie do aplicativo gerado pelo balanceador de carga, na resposta ao cliente.

Em solicitações subsequentes, os clientes precisam enviar os dois cookies de volta para manter a aderência. O balanceador de carga descriptografa o cookie do aplicativo e verifica se a duração configurada da aderência ainda é válida. Em seguida, ele usa as informações no cookie para enviar a solicitação para o mesmo destino dentro do grupo de destino para manter a perdurabilidade. O balanceador de carga também faz o proxy do cookie de aplicativo personalizado para o destino sem inspecioná-lo ou modificá-lo. Nas respostas subsequentes, a expiração do cookie de aplicativo gerado pelo balanceador de carga e a duração da aderência configurada no balanceador de carga são redefinidas. Para manter a aderência entre o cliente e o alvo, a expiração do cookie e a duração da viscosidade não devem decorrer.

Se um destino falhar ou ficar não ficar íntegro, o load balancer interromperá o roteamento de solicitações para esse destino e escolherá um novo destino íntegro com base no algoritmo de balanceamento de carga escolhido. O load balancer trata a sessão agora como “grudada” ao novo destino íntegro e continua a rotear solicitações para o novo destino íntegro, mesmo se o destino falhado voltar.

Com solicitações CORS (compartilhamento de recursos de origem cruzada), para habilitar a perdurabilidade, o load balancer adicionaSameSite=None; Secureatributos ao cookie de aplicativo gerado pelo balanceador de carga somente se a versão user-agent for Chromium80 ou superior.

Como a maioria dos navegadores restringe os cookies a 4K em tamanho, o load balancer fragmenta os cookies de aplicativos maiores do que 4K em vários cookies. Os Application Load Balancers suportam cookies de até 16K de tamanho e, portanto, podem criar até 4 fragmentos enviados para o cliente. O nome do cookie do aplicativo que o cliente vê começa com “AWSALBAPP-” e inclui um número de fragmento. Por exemplo, se o tamanho do cookie for 0-4K, o cliente verá AWSALBAPP-0. Se o tamanho do cookie for 4-8k, o cliente verá AWSALBAPP-0 e AWSALBAPP-1, e assim por diante.

Para habilitar a perdurabilidade baseada na aplicação usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, emBalanceamento de carga, escolhaGrupos de destino.

  3. Escolha o nome do grupo de destino para abrir sua página de detalhes.

  4. NoDetalhes do grupo doguia, na guiaAtributos.seção, selecioneEdite.

  5. Na página Editar atributos, faça o seguinte:

    1. SelectStickiness.

    2. para oTipo de pertensão, selecioneCookie baseado em aplicativos.

    3. Em Duração da perdurabilidade, especifique um valor entre um segundo e sete dias.

    4. para oNome do cookie do aplicativo, insira um nome para seu cookie baseado na aplicação.

      Não useAWSALB,AWSALBAPP, ouAWSALBTGPara o nome do cookie; eles são reservados para uso pelo load balancer.

    5. Selecione Save changes.

Para habilitar a perdurabilidade baseada na aplicação usando aAWS CLI

Usar aModificy-target-group-attributesComando com os seguintes atributos:

  • stickiness.enabled

  • stickiness.type

  • stickiness.app_cookie.cookie_name

  • stickiness.app_cookie.duration_seconds

Use o seguinte comando para habilitar a perdurabilidade baseada em aplicativos.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds Value=time-in-seconds

Sua saída deve ser similar ao seguinte exemplo.

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.app_cookie.cookie_name", "Value": "MyCookie" }, { "Key": "stickiness.type", "Value": "app_cookie" }, { "Key": "stickiness.app_cookie.duration_seconds", "Value": "86500" }, ... ] }

Rebalanceamento manual

Ao aumentar a escala, se o número de alvos aumentar consideravelmente, há potencial para distribuição desigual da carga devido à aderência. Nesse cenário, você pode reequilibrar a carga em seus destinos usando as duas opções a seguir:

  • Defina uma expiração no cookie gerado pelo aplicativo que é anterior à data e hora atuais. Isso impedirá que os clientes enviem o cookie para o Application Load Balancer, que reiniciará o processo de estabelecer a aderência.

  • Defina uma duração muito curta na configuração de aderência baseada em aplicativos do balanceador de carga, por exemplo, 1 segundo. Isso força o Application Load Balancer a restabelecer a aderência mesmo que o cookie definido pelo destino não tenha expirado.