Come posso risolvere i problemi di persistenza della sessione di Application Load Balancer?

Ultimo aggiornamento: 16/08/2022

Ho un Application Load Balancer che utilizza sessioni con persistenza basata sulla durata o sessioni con persistenza basata sull'applicazione. Il bilanciatore del carico è configurato per instradare tutte le richieste di sessione utente alla stessa destinazione. Tuttavia, le richieste di sessione utente vengono instradate verso destinazioni differenti.

Breve descrizione

Le sessioni permanenti utilizzano i cookie per consentire al client di mantenere una connessione con la stessa istanza per tutta la durata di un cookie. L'utilizzo di sessioni permanenti configura un bilanciatore del carico per associare le sessioni utente a un'istanza specifica. Questo significa che tutte le richieste di un utente durante una sessione vengono inviate alla stessa istanza. Tuttavia, questa ipotesi sulla connessione può causare squilibri nel tempo.

Una sessione permanente può riportare un errore se:

  • La destinazione registrata non ha generato un cookie
  • Il client non ha restituito il cookie nell'intestazione della richiesta
  • I cookie non sono formattati correttamente
  • La sessione basata sulla durata è stata superata
  • La richiesta della sessione sta passando attraverso più bilanciatori del carico
  • Lo stato dell'integrità della destinazione è cambiato in non integra
  • Un servizio AWS ha disabilitato la persistenza

Nota: prima di iniziare, assicurati di ripassare la sezione relativa ai requisiti e alle considerazioni in Sessioni permanenti per il tuo Application Load Balancer.

Risoluzione

Persistenza della sessione basata sull'applicazione

1.    Verifica la presenza di errori HTTP con il bilanciatore del carico Per istruzioni, vedi Risoluzione dei problemi relativi agli Application Load Balancer.

2.    Per verificare la presenza di cookie posizionati sull'istanza di back-end o sul bilanciatore del carico, esegui un comando curl simile al seguente:

Nota: sostituisci il nome DNS con il nome del bilanciatore del carico.

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

Nota: la utility curl di Linux può essere installata anche sul sistema operativo Windows.

Output di esempio:

...

< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/

< Set-Cookie:

AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

3.    Per verificare che la destinazione registrata abbia generato un cookie dell'applicazione, invia una richiesta HTTP all'indirizzo IP dell'istanza simile al seguente:

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

Output di esempio:

...

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

...

4.    Verifica che il nome del cookie generato dalla destinazione registrata corrisponda al nome del cookie sul bilanciatore del carico nei passaggi 2 e 3.

5.    Se la destinazione ha generato un cookie dell'applicazione e il bilanciatore del carico ha generato un cookie AWSALBAPP, assicurati che il client invii entrambi i cookie nelle richieste successive. Se il client non riesce a includere l'applicazione o il cookie AWSELB, la persistenza non riesce. Per verificare che il client invii sia i cookie dell'applicazione che quelli di AWSALBAPP, devi eseguire un'acquisizione di pacchetti sul client. Utilizza l'utility tcpdump o Wireshark per l'analisi oppure utilizza lo strumento di debug del browser Web per recuperare le informazioni sui cookie nell'intestazione della richiesta.

Nota: se lavori con il supporto AWS, puoi raccogliere queste informazioni generando un file HAR. I file HAR possono acquisire informazioni sensibili, come nomi utente, password e chiavi, quindi assicurati di rimuovere tutte le informazioni di questo genere da un file HAR.

6.    Controlla a quale istanza di back-end è stata instradata la richiesta dal bilanciatore del carico. Puoi visualizzare l'ID dei metadati dell'istanza eseguendo uno script simile a quello riportato di seguito:

<?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');
echo "instance id = " . $instance_id . "\\xA";
?>

7.    Esamina i log di accesso di Elastic Load Balancing per verificare se le richieste dello stesso utente vengono instradate verso destinazioni registrate differenti. Per istruzioni, consulta i log di accesso per il tuo Application Load Balancer.

8.    Verifica che lo stato dell'integrità di tutte le destinazioni nel gruppo di destinazione in cui è abilitata la persistenza sia "integra". Se lo stato dell'integrità della destinazione cambia in "non integra", la persistenza si interrompe e il load balancer interrompe l'instradamento delle richieste a quella destinazione. Una nuova destinazione integra viene quindi selezionata automaticamente dal load balancer che stabilisce una sessione permanente. Il load balancer continua a instradare le richieste alla nuova destinazione anche se lo stato è "non integra". Per ulteriori informazioni sui controlli dell'integrità, consulta Controlli dell'integrità per i gruppi di destinazione.

9.    Verifica la presenza di eventuali servizi AWS, ad esempio Amazon Elastic Kubernetes Service (Amazon EKS), che potrebbero aver disabilitato la persistenza nel tuo bilanciatore del carico. Controlla gli eventi View CloudTrail con il nome API «ModifyTargetGroupAttributes» e l'attributo “stickiness.enabled”.

Persistenza della sessione in base alla durata

1.    Esegui un comando simile a quello riportato di seguito con il nome DNS del bilanciatore del carico per verificare la presenza di un cookie AWSALB nella risposta:

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

Output di esempio:

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

Nota: se non è presente un cookie AWSALB nella risposta, tra il client e l'istanza di backend.non esiste alcuna persistenza.

2.    Se il bilanciatore del carico ha generato un cookie AWSALB, assicurati che il client invii questo cookie nelle richieste successive. Se il client non riesce a includere il cookie AWSALB, la persistenza non riesce. Per verificare che il client invii il cookie AWSALB, esegui un'acquisizione di pacchetti sul client. Utilizza l'utility tcpdump o Wireshark per l'analisi oppure utilizza lo strumento di debug del browser Web per recuperare le informazioni sui cookie nell'intestazione della richiesta.

Nota: se lavori con il supporto AWS, puoi raccogliere queste informazioni generando un file HAR. I file HAR possono acquisire informazioni sensibili, come nomi utente, password e chiavi, quindi assicurati di rimuovere tutte le informazioni di questo genere da un file HAR.

3.    Verifica la durata configurata sul bilanciatore del carico. Se la scadenza del cookie è passata, le sessioni client non si atterranno più alla destinazione registrata fino a quando il bilanciatore del carico non emette un nuovo cookie.

4.    Se la tua richiesta passa attraverso più bilanciatori del carico, verifica che la persistenza sia abilitata su un solo bilanciatore. Se più bilanciatori del carico generano un cookie, il bilanciatore del carico sostituisce il cookie originale e la persistenza non riesce.

Per i Classic Load Balancer, vedi Come posso risolvere i problemi relativi alla funzionalità di persistenza della sessione con Classic Load Balancer?