Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
Come posso risolvere i problemi di persistenza delle sessioni dell'Application Load Balancer?
Ho un Application Load Balancer che usa la persistenza delle sessioni basata sulla durata o sull'applicazione. Il bilanciatore del carico è configurato per instradare tutte le richieste di sessione utente alla stessa destinazione. Tuttavia, desidero che le richieste di sessione utente vengano instradate a destinazioni diverse.
Breve descrizione
Le sessioni persistenti utilizzano i cookie per aiutare il client a mantenere una connessione alla stessa destinazione per tutta la durata del cookie. Le sessioni persistenti configurano un bilanciatore del carico per associare le sessioni utente a una destinazione specifica. Ciò significa che tutte le richieste di un utente durante una sessione vengono inviate alla stessa destinazione. Tuttavia, questo presupposto sulla connessione può causare squilibri nel tempo.
Gli errori nelle sessioni persistenti possono essere dovuti ai motivi seguenti:
- 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 è terminata.
- La richiesta di sessione passa attraverso diversi bilanciatori del carico.
- Lo stato di integrità della destinazione è cambiato in non integro.
- Un servizio AWS ha disattivato la persistenza.
Nota: prima di iniziare, assicurati di leggere le sezioni relative ai requisiti e alle considerazioni in Sticky sessions for your Application Load Balancer.
Risoluzione
Persistenza delle sessioni basata sull'applicazione
-
Verifica la presenza di errori HTTP nel bilanciatore del carico. Per istruzioni, consulta Troubleshoot your Application Load Balancers.
-
Per verificare la presenza di cookie inseriti nell'istanza di backend o nel bilanciatore del carico, esegui un comando curl simile al seguente. Sostituisci il nome DNS con il nome del tuo bilanciatore del carico:
[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-EXAMPLE-ELB-1430759361.eu-central-1.elb.amazonaws.comNota: puoi anche installare l'utilità curl Linux sul sistema operativo Windows. Per ulteriori informazioni, consulta curl 8.10.1 for Windows sul sito web di curl.
L'output del comando curl sarà simile al seguente:
... < Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/ < Set-Cookie: AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/ ... -
Per verificare che la destinazione registrata abbia generato un cookie dell'applicazione, invia all'indirizzo IP dell'istanza una richiesta HTTP simile alla seguente:
[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168L'output del comando sarà simile al seguente:
... < Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/ ... -
Verifica che il nome del cookie generato dalla destinazione registrata sia il nome del cookie sul bilanciatore del carico indicato nei passaggi 2 e 3.
-
Quando la destinazione genera un cookie dell'applicazione e il bilanciatore del carico genera un cookie AWSALBAPP, controlla che il client invii entrambi i cookie nelle richieste successive. Se il client non include il cookie dell'applicazione o AWSELB, la persistenza ha esito negativo. Per verificare che il client invii sia il cookie dell'applicazione che il cookie AWSALBAPP, acquisisci un pacchetto sul client. Per recuperare le informazioni sui cookie nell'intestazione della richiesta, utilizza una delle opzioni seguenti:
tcpdump dal sito web tcpdump
Utilità Wireshark dal sito web Wireshark
Strumento di debug web del browserNota: se lavori con il Supporto AWS, crea un file HAR per acquisire queste informazioni. Poiché i file HAR possono acquisire informazioni sensibili, come nomi utente, password e chiavi, assicurati di rimuovere le informazioni sensibili dal file HAR.
-
Controlla l'istanza di backend a cui il bilanciatore del carico ha instradato la richiesta. Per utilizzare i metadati dell'istanza per visualizzare l'ID dell'istanza, esegui uno script simile al seguente:
<?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');echo "instance id = " . $instance_id . "\\xA";?> -
Per verificare se richieste dallo stesso utente vengono instradate a destinazioni registrate diverse, esamina i log di accesso di Elastic Load Balancing (ELB). Per istruzioni, consulta Access logs for your Application Load Balancer.
-
Esamina lo stato di integrità di tutte le destinazioni appartenenti al gruppo di destinazione in cui è attiva la persistenza per verificare che sia integro. Se lo stato di una destinazione diventa non integro, la persistenza si interrompe e il bilanciatore del carico non instrada le richieste a quella destinazione. Il bilanciatore del carico seleziona quindi automaticamente una nuova destinazione integra e stabilisce una sessione persistente. Il bilanciatore del carico continua a instradare le richieste alla nuova destinazione anche se lo stato è non integro. Per ulteriori informazioni sui controlli dell'integrità, consulta Health checks for Application Load Balancer target groups.
-
Verifica se vi sono servizi AWS, come Amazon Elastic Kubernetes Service (Amazon EKS), che potrebbero aver disattivato la persistenza nel bilanciatore del carico. Controlla la cronologia eventi di CloudTrail. Usa il nome API ModifyTargetGroupAttributes e l'attributo stickiness.enabled.
Persistenza delle sessioni basata sulla durata
-
Per verificare la presenza di un cookie AWSALB, esegui un comando curl simile al seguente. Assicurati di utilizzare il nome DNS del bilanciatore del carico:
[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.comL'output del comando curl sarà simile al seguente:
... < Set-Cookie: AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/ ...Nota: se nella risposta non è presente un cookie AWSALB, non vi è persistenza tra il client e l'istanza di backend.
-
Se il bilanciatore del carico ha generato un cookie AWSALB, controlla che il client invii questo cookie nelle richieste successive. Se il client non include il cookie AWSALB, la persistenza non funziona. Per verificare che il client invii il cookie AWSALB, acquisisci un pacchetto sul client. Per recuperare le informazioni sui cookie nell'intestazione della richiesta, utilizza una delle opzioni seguenti:
tcpdump dal sito web tcpdump
Utilità Wireshark dal sito web Wireshark
Strumento di debug web del browserNota: se lavori con il Supporto AWS, crea un file HAR per acquisire queste informazioni. Poiché i file HAR possono acquisire informazioni sensibili, come nomi utente, password e chiavi, assicurati di rimuovere le informazioni sensibili dal file HAR.
-
Controlla la durata configurata sul bilanciatore del carico. Se la scadenza del cookie è trascorsa, le sessioni del client non persisteranno più sulla destinazione registrata fino a quando non verrà emesso un nuovo cookie dal bilanciatore del carico.
-
Se la richiesta passa attraverso più bilanciatori del carico, verifica che la persistenza sia attivata su un solo bilanciatore del carico. Se più di un bilanciatore del carico genera un cookie, il bilanciatore del carico sostituisce il cookie originale e la persistenza ha esito negativo.
Per i Classic Load Balancer, consulta How can I troubleshoot the Classic Load Balancer session stickiness feature?
Informazioni correlate
Perché Elastic Load Balancing instrada in modo non equo il traffico del mio bilanciatore del carico?
Configure sticky sessions for your Classic Load Balancer
Come posso impostare gruppi target ponderati per il mio Application Load Balancer?
- Argomenti
- Networking & Content Delivery
- Lingua
- Italiano
