Como soluciono problemas de persistência da sessão do Application Load Balancer?

6 minuto de leitura
0

Eu tenho um Application Load Balancer que usa sessões de persistência baseadas em duração ou sessões de persistência baseadas em aplicações. O balanceador de carga está configurado para rotear todas as solicitações de sessão do usuário para o mesmo destino. No entanto, quero que as solicitações de sessão do usuário sejam roteadas para destinos diferentes.

Breve descrição

As sessões persistentes usam cookies para ajudar o cliente a manter uma conexão com o mesmo destino durante a vida útil de um cookie. As sessões persistentes configuram um balanceador de carga para vincular as sessões do usuário a um destino específico. Isso significa que todas as solicitações de um usuário durante uma sessão são enviadas para o mesmo destino. No entanto, essa suposição sobre a conexão pode causar desequilíbrios ao longo do tempo.

Uma sessão persistente pode falhar pelos seguintes motivos:

  • O destino registrado não gerou um cookie.
  • O cliente não retornou o cookie no cabeçalho da solicitação.
  • Os cookies não estão formatados corretamente.
  • A sessão baseada na duração acabou.
  • A solicitação de sessão passa por vários balanceadores de carga.
  • O status de saúde alvo foi alterado para insalubre.
  • Um serviço da AWS desativou a aderência.

Observação: antes de começar, verifique as seções de requisitos e considerações nas sessões persistentes do seu Application Load Balancer.

Resolução

Fixação da sessão baseada em aplicações

  1. Verifique se há erros de HTTP com seu balanceador de carga. Para obter instruções, consulte Solucionar problemas dos seus Application Load Balancers.

  2. Para verificar se há cookies colocados na instância de back-end ou no balanceador de carga, execute um comando curl semelhante ao seguinte. Substitua o nome do DNS pelo nome do seu balanceador de carga:

    [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-EXAMPLE-ELB-1430759361.eu-central-1.elb.amazonaws.com

    Observação: você também pode instalar o utilitário curl do Linux no sistema operacional (SO) Windows. Para obter mais informações, consulte curl 8.10.1 para Windows no site curl.

    A saída do comando curl é semelhante à seguinte:

    ...
    < Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
    
    < Set-Cookie:
    
    AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
    
    ...
  3. Para verificar se o destino registrado gerou um cookie de aplicação, envie uma solicitação HTTP para o endereço IP da instância semelhante à seguinte:

    [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168

    A saída desse comando é semelhante ao seguinte:

    ...
    < Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/
    
    ...
  4. Verifique se o nome do cookie gerado pelo destino registrado é o nome do cookie no balanceador de carga das etapas 2 e 3.

  5. Quando o destino gera um cookie de aplicação e o balanceador de carga gera um cookie AWSALBAPP, verifique se o cliente envia os dois cookies nas solicitações subsequentes. Se o cliente não incluir a aplicação ou o cookie AWSELB, a aderência falhará. Para verificar se o cliente envia a aplicação e o cookie AWSALBAPP, faça uma captura de pacote no cliente. Para recuperar as informações do cookie no cabeçalho da solicitação, use uma das seguintes opções:

    tcpdump do site tcpdump
    Utilitário Wireshark do site Wireshark
    Ferramenta de depuração para navegador da web

    Observação: se você estiver trabalhando com o AWS Support, crie um arquivo HAR para coletar essas informações. Como os arquivos HAR podem capturar informações confidenciais, como nomes de usuário, senhas e chaves, certifique-se de remover as informações confidenciais de um arquivo HAR.

  6. Verifique a instância de back-end para a qual o balanceador de carga roteou a solicitação. Para usar os metadados da instância para exibir o ID da instância, execute um script semelhante ao seguinte:

    <?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');echo "instance id = " . $instance_id . "\\xA";?>
  7. Para verificar se as solicitações do mesmo usuário são roteadas para diferentes destinos registrados, revise seus logs de acesso do Elastic Load Balancing (ELB). Para obter instruções, consulte Logs de acesso do seu Application Load Balancer.

  8. Verifique se o estado de integridade de todos os destinos do grupo de destino em que a persistência está ativada é saudável. Se o status de integridade do destino mudar para insalubre, a persistência será interrompida e o balanceador de carga não roteará as solicitações para esse destino. Uma nova meta íntegra será, então, selecionada automaticamente pelo balanceador de carga e estabelecerá uma sessão persistente. O balanceador de carga continua roteando solicitações para o novo destino, mesmo que o status de integridade não seja íntegro. Para obter mais informações sobre verificações de integridade, consulte Verificações de integridade para grupos de destino do Application Load Balancer.

  9. Verifique se há serviços da AWS, como o Amazon Elastic Kubernetes Service (Amazon EKS), que possam ter desativado a persistência do seu balanceador de carga. Confira o Histórico de eventos do CloudTrail. Use o nome da API ModifyTargetGroupAttributes e o atributo stickiness.enabled.

Persistência da sessão com base na duração

  1. Para verificar se há um cookie AWSALB, execute um comando curl semelhante ao seguinte. Certifique-se de usar o nome do DNS do balanceador de carga:

    [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

    A saída do comando curl é semelhante à seguinte:

    ...
    < Set-Cookie: AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
    ...

    Observação: se não houver um cookie AWSALB na resposta, não haverá persistência entre o cliente e a instância de back-end.

  2. Se o balanceador de carga gerou um cookie AWSALB, verifique se o cliente envia esse cookie em solicitações subsequentes. Se o cliente não incluir o cookie AWSALB, a persistência não funcionará. Para verificar se o cliente envia o cookie AWSALB, faça uma captura de pacote no cliente. Para recuperar as informações do cookie no cabeçalho da solicitação, use uma das seguintes opções:

    tcpdump do site tcpdump
    Utilitário Wireshark do site Wireshark
    Ferramenta de depuração para navegador da web

    Observação: se você estiver trabalhando com o AWS Support, crie um arquivo HAR para coletar essas informações. Como os arquivos HAR podem capturar informações confidenciais, como nomes de usuário, senhas e chaves, certifique-se de remover as informações confidenciais de um arquivo HAR.

  3. Verifique a duração configurada no balanceador de carga. Se a validade do cookie expirar, as sessões do cliente não persistirão mais no destino registrado até que um novo cookie seja emitido pelo balanceador de carga.

  4. Se sua solicitação passar por vários balanceadores de carga, verifique se a persistência está ativada em apenas um balanceador de carga. Se mais de um balanceador de carga gerar um cookie, o balanceador de carga substituirá o cookie original e a aderência falhará.

Para Classic Load Balancers, consulte Como posso solucionar problemas com o atributo de persistência da sessão do Classic Load Balancer?

Informações relacionadas

Por que o Elastic Load Balancing roteia o tráfego de um balanceador de carga de forma desigual?

Configure sessões persistentes para seu Classic Load Balancer

Como configurar grupos de destino ponderados para meu Application Load Balancer?

AWS OFICIAL
AWS OFICIALAtualizada há 4 meses