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

Breve descrição

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

Uma sessão persistente pode falhar se:

• O alvo registrado não gerar um cookie
• O cliente não retornar o cookie no cabeçalho da solicitação
• Os cookies não estiverem formatados corretamente
• A sessão baseada em duração for aprovada
• A solicitação de sessão está passando por vários balanceadores de carga
• O status de integridade alvo mudou para não íntegro
• Um serviço da AWS desabilitou a persistência

Observação: antes de começar, verifique e confirme a seção de requisitos e a seção considerações em Sessões persistentes para o Application Load Balancer.

Resolução

Sessão de persistência baseada em aplicação

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

2.    Para verificar se há cookies colocados na instância de backend ou no balanceador de carga, execute um comando curl semelhante ao seguinte:

Observação: substitua o nome DNS pelo nome do 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: O utilitário curl do Linux também pode ser instalado no sistema operacional Windows.

Exemplo de saída:

...

< 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 ao seguinte:

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

Exemplo de saída:

...

< Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/

...

4.    Verifique se o nome do cookie gerado pelo destino registrado é o mesmo que o cookie no balanceador de carga nas etapas 2 e 3.

5.    Se o destino gerou um cookie de aplicação e o balanceador de carga gerou um cookie AWSALBAPP, verifique e confirme se o cliente envia os dois cookies em solicitações subsequentes. Se o cliente não incluir a aplicação ou o cookie AWSELB, a persistência falhará. Para verificar se o cliente envia os cookies de aplicação e do AWSALBAPP, faça uma captura de pacote no cliente. Use o utilitário tcpdump ou Wireshark para análise ou use a ferramenta de depuração da web do navegador para recuperar as informações do cookie no cabeçalho da solicitação.

Observação: se você estiver trabalhando com o AWS Support, poderá coletar essas informações gerando um arquivo HAR. Os arquivos HAR podem capturar informações confidenciais, como nomes de usuário, senhas e chaves, portanto, certifique-se de remover qualquer informação confidencial de um arquivo HAR.

6.    Verifique para qual instância de backend o balanceador de carga encaminhou a solicitação. Você pode exibir o ID da instância usando os metadados da instância executando 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.    Analise seus logs de acesso do Elastic Load Balancing para verificar se as solicitações do mesmo usuário são encaminhadas para diferentes destinos registrados. Para obter instruções, consulte logs de acesso para o Application Load Balancer.

8.    Verifique o status de integridade de todos os destinos sob o grupo de destino em que a persistência está habilitada para saber se estão íntegros. Se o status de integridade do destino mudar para “não íntegro”, a persistência será interrompida e o balanceador de carga interromperá o roteamento de solicitações para esse destino. Um novo destino íntegro é selecionado automaticamente pelo balanceador de carga e estabelece uma sessão persistente. O balanceador de carga continua a encaminhar as solicitações para o novo destino, mesmo que o status de integridade seja “não íntegro”. Para obter mais informações sobre as verificações de integridade, consulte verificações de integridade para seus grupos de destino.

9.    Verifique se há serviços da AWS, por exemplo, Amazon Elastic Kubernetes Service (Amazon EKS), que possam ter desabilitado a persistência no balanceador de carga. Verifique os eventos View CloudTrail com o nome da API “ModifyTargetGroupAttributes” e o atributo “stickiness.enabled”.

Sessão de persistência baseada em duração

1.    Execute um comando semelhante ao seguinte com o nome DNS do balanceador de carga para verificar se há um cookie AWSALB na resposta:

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

Exemplo de saída:

...< 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 backend.

2.    Se o balanceador de carga gerar um cookie AWSALB, verfique e confirme se o cliente enviou 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 enviou o cookie AWSALB, faça uma captura de pacote no cliente. Use o utilitário tcpdump ou Wireshark para análise ou use a ferramenta de depuração da web do navegador para recuperar as informações do cookie no cabeçalho da solicitação.

Observação: se você estiver trabalhando com o AWS Support, poderá coletar essas informações gerando um arquivo HAR. Os arquivos HAR podem capturar informações confidenciais, como nomes de usuário, senhas e chaves, portanto, certifique-se de remover qualquer informação confidencial de um arquivo HAR.

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

4.    Se sua solicitação estiver passando por vários balanceadores de carga, verifique se a persistência está habilitada 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 persistência falhará.

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

---

Informações relacionadas

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

Configure sessões persistentes para o seu Classic Load Balancer

Como configuro grupos de destino com peso para o meu Application Load Balancer?