Sessioni basate su Application Load Balancer

Per impostazione predefinita, un Application Load Balancer esegue il routing di ogni richiesta in modo indipendente a una destinazione registrata in base all'algoritmo del load balancer scelto. Tuttavia, è possibile utilizzare la funzionalità sticky session (nota anche come affinità di sessione) per consentire al load balancer di associare una sessione utente a una destinazione specifica. Questo garantisce che durante la sessione tutte le richieste dell'utente siano inviate allo stesso target. Questa funzionalità è utile per i server che conservano le informazioni sullo stato al fine di fornire un'esperienza continua ai client. Per utilizzare sessioni permanenti, il client deve supportare i cookie.

Gli Application Load Balancer supportano sia i cookie basati sulla durata che i cookie basati sulle applicazioni. Le sessioni permanenti sono abilitate a livello di gruppo target. Puoi utilizzare una combinazione di viscosità basata sulla durata, adesività basata sull'applicazione e nessuna viscosità tra i tuoi gruppi target.

La chiave per la gestione delle sticky session consiste nel determinare per quanto tempo il tuo load balancer deve instradare costantemente la richiesta dell'utente verso lo stesso target. Se la tua applicazione ha un proprio cookie di sessione, puoi utilizzare la stickness basata sull'applicazione e il cookie della sessione del load balancer segue la durata specificata dal cookie della sessione dell'applicazione. Se la tua applicazione non ha un proprio cookie di sessione, puoi utilizzare la persistenza in base alla durata per generare un cookie della sessione del load balancer con una durata specificata dall'utente.

Il contenuto dei cookie generati dal load balancer viene crittografato utilizzando una chiave rotante. Non è possibile decrittografare o modificare i cookie generati dal load balancer.

Per entrambi i tipi di viscosità, Application Load Balancer ripristina la scadenza dei cookie generati dopo ogni richiesta. Se un cookie scade, la sessione non è più permanente e il client deve rimuovere il cookie dal suo archivio di cookie.

Requisiti

• Un load balancer HTTP/HTTPS.

• Almeno un'istanza integra in ciascuna zona di disponibilità.

Considerazioni

• Le sticky session non sono supportate se il load balancer tra zone è disabilitato. Il tentativo di abilitare le sticky session mentre il load balancer tra zone è disabilitato, non riuscirà.

• Per i cookie basati sulle applicazioni, i nomi dei cookie devono essere specificati individualmente per ciascun gruppo target. Tuttavia, per i cookie basati sulla durata,AWSALB è l'unico nome utilizzato in tutti i gruppi target.

• Se utilizzi più livelli di Application Load Balancer, puoi abilitare sessioni permanenti su tutti i livelli con cookie basati sull'applicazione. Tuttavia, con i cookie basati sulla durata, è possibile abilitare le sessioni permanenti solo su un livello, poichéAWSALB è l'unico nome disponibile.

• La viscosità basata sull'applicazione non funziona con gruppi target ponderati.

• Se hai un'azione diretta con più gruppi target e le sessioni permanenti sono abilitate per uno o più gruppi target, devi abilitare la permanenza a livello di gruppo target.

• WebSocketle connessioni sono intrinsecamente appiccicose. Se il client richiede un aggiornamento della connessione aWebSockets, la destinazione che restituisce un codice di stato HTTP 101 per accettare l'aggiornamento della connessione è la destinazione utilizzata nellaWebSockets connessione. Una volta completato l'WebSocketsaggiornamento, la viscosità basata sui cookie non viene utilizzata.

• Gli Application Load Balancer utilizzano l'Expiresattributo nell'intestazione del cookie anziché l'Max-Ageattributo.

• Application Load Balancer non supporta i valori dei cookie con codifica URL.

Persistenza basata sulla durata

La persistenza basata sulla durata indirizza le richieste allo stesso obiettivo in un gruppo target utilizzando un cookie generato dal load balancer (AWSALB). Il cookie viene utilizzato per mappare la sessione all'obiettivo. Se la tua applicazione non ha un proprio cookie di sessione, puoi specificare la durata della persistenza e gestire per quanto tempo il tuo load balancer deve instradare costantemente la richiesta dell'utente verso la stessa destinazione.

Quando un sistema di bilanciamento del carico riceve per la prima volta una richiesta da un client, la indirizza a un obiettivo (in base all'algoritmo scelto) e genera un cookie denominatoAWSALB. Codifica le informazioni sulla destinazione selezionata, crittografa il cookie e lo include nella risposta al client. Il cookie generato dal load balancer ha una propria scadenza di 7 giorni e non è configurabile.

Nelle richieste successive, il client deve includere ilAWSALB cookie. Quando il load balancer riceve una richiesta da un client che contiene il cookie, la rileva e indirizza la richiesta allo stesso obiettivo. Se il cookie è presente ma non può essere decodificato o se si riferisce a una destinazione di cui è stata annullata la registrazione o non integra, il sistema di bilanciamento del carico seleziona una nuova destinazione e aggiorna il cookie con le informazioni sulla nuova destinazione.

Con le richieste CORS (Condivisione delle risorse multiorigine), alcuni browser richiedonoSameSite=None; Secure l'abilitazione della persistenza. In questo caso, il load balancer genera un secondo cookie di sticknessAWSALBCORS, che include le stesse informazioni del cookie di stickiness originale più l'SameSiteattributo. I clienti ricevono entrambi i cookie.

Per abilitare la sticky basata sulla durata utilizzando la console

1. Aprire la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.

2. Nel pannello di navigazione, in Load balancing (Bilanciamento del carico) scegli Target Groups (Gruppi di destinazione).

3. Scegli il nome del gruppo di dettagli.

4. Nella scheda Dettagli del gruppo, nella sezione Attributi, scegli Modifica.

5. Nella pagina Edit attributes (Modifica attributi), procedere nel modo seguente:

   1. Seleziona Adesività.

   2. Per Tipo di viscosità, seleziona Cookie generato da Load Balancer.

   3. Per Stickiness duration (Durata persistenza), specificare un valore compreso tra 1 secondo e 7 giorni.

   4. Sceglie Save changes (Salva modifiche).

Per abilitare la viscosità basata sulla durata utilizzando lAWS CLI

Usa il modify-target-group-attributescomando con glistickiness.lb_cookie.duration_seconds attributistickiness.enabled and.

Utilizza il seguente comando per abilitare la durata.

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

L'output visualizzato dovrebbe essere simile al seguente esempio.

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

Adesività basata sull'applicazione

La viscosità basata sull'applicazione ti offre la flessibilità di impostare i tuoi criteri di permanenza in base al cliente. Quando si abilita la stickiness basata sull'applicazione, il load balancer indirizza la prima richiesta a un obiettivo all'interno del gruppo target in base all'algoritmo scelto. Il target dovrebbe impostare un cookie applicativo personalizzato che corrisponda al cookie configurato sul load balancer per abilitare la viscosità. Questo cookie personalizzato può includere uno qualsiasi degli attributi dei cookie richiesti dall'applicazione.

Quando Application Load Balancer riceve il cookie dell'applicazione personalizzato dalla destinazione, genera automaticamente un nuovo cookie dell'applicazione crittografato per acquisire informazioni sulla permanenza. Questo cookie dell'applicazione generato da un sistema di bilanciamento del carico acquisisce informazioni sulla viscosità per ogni gruppo target in cui è abilitata la viscosità basata sull'applicazione.

Il cookie dell'applicazione generato dal load balancer non copia gli attributi del cookie personalizzato impostato dal target. Ha una propria scadenza di 7 giorni che non è configurabile. Nella risposta al client, l'Application Load Balancer convalida solo il nome con cui il cookie personalizzato è stato configurato a livello di gruppo di destinazione e non il valore o l'attributo di scadenza del cookie personalizzato. Se il nome corrisponde, il load balancer invia entrambi i cookie, il cookie personalizzato impostato dal target e il cookie dell'applicazione generato dal load balancer, in risposta al client.

Nelle richieste successive, i clienti devono rispedire entrambi i cookie per mantenere la viscosità. Il load balancer decrittografa il cookie dell'applicazione e verifica se la durata di permanenza configurata è ancora valida. Quindi utilizza le informazioni contenute nel cookie per inviare la richiesta allo stesso target all'interno del gruppo di destinazione per mantenere la persistenza. Il load balancer invia inoltre il cookie dell'applicazione personalizzata alla destinazione senza ispezionarlo o modificarlo. Nelle risposte successive, la scadenza del cookie dell'applicazione generato dal load balancer e la durata della permanenza configurata sul load balancer vengono ripristinate. Per mantenere la viscosità tra cliente e destinatario, la scadenza del cookie e la durata della viscosità non devono trascorrere.

Se una destinazione non riesce o diventa non integra, il load balancer interrompe il routing delle richieste a quel target e sceglie una nuova destinazione integra in base all'algoritmo del load balancer scelto. Il load balancer tratta la sessione come bloccata sul nuovo target integri e continua a instradare le richieste verso il nuovo target, anche se il target non riuscito torna indietro.

Nelle richieste CORS (cross-origin resource sharing), per abilitare la permanenza, il load balancer aggiungeSameSite=None; Secure gli attributi al cookie dell'applicazione generato dal load balancer solo se la versione dell'agente utente è Chromium80 o superiore.

Poiché la maggior parte dei browser limita la dimensione dei cookie a 4K, il sistema di bilanciamento del carico suddivide i cookie delle applicazioni superiori a 4K in più cookie. Gli Application Load Balancer supportano cookie di dimensioni fino a 16.000 e possono quindi creare fino a 4 shard da inviare al client. Il nome del cookie dell'applicazione visualizzato dal client inizia con «AWSALBAPP-» e include un numero di frammento. Ad esempio, se la dimensione del cookie è 0-4K, il client vedeAWSALBAPP -0. Se la dimensione del cookie è 4-8k, il client vedeAWSALBAPP -0 eAWSALBAPP -1 e così via.

Per abilitare la viscosità basata sull'applicazione utilizzando la console

1. Aprire la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.

2. Nel pannello di navigazione, in Load balancing (Bilanciamento del carico) scegli Target Groups (Gruppi di destinazione).

3. Scegli il nome del gruppo di dettagli.

4. Nella scheda Dettagli del gruppo, nella sezione Attributi, scegli Modifica.

5. Nella pagina Edit attributes (Modifica attributi), procedere nel modo seguente:

   1. Seleziona Adesività.

   2. Per il tipo di viscosità, seleziona Cookie basato sull'applicazione.

   3. Per Stickiness duration (Durata persistenza), specificare un valore compreso tra 1 secondo e 7 giorni.

   4. Per il nome del cookie dell'app, inserisci un nome per il cookie basato sull'applicazione.

      Non utilizzareAWSALBAWSALBAPP, oAWSALBTG per il nome del cookie; sono riservati per l'utilizzo da parte del load balancer.

   5. Sceglie Save changes (Salva modifiche).

Per abilitare la viscosità basata sull'applicazione utilizzando ilAWS CLI

Usa il modify-target-group-attributescomando con i seguenti attributi:

• stickiness.enabled

• stickiness.type

• stickiness.app_cookie.cookie_name

• stickiness.app_cookie.duration_seconds

Utilizza il seguente comando per abilitare la stickness basata sull'applicazione.

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

L'output visualizzato dovrebbe essere simile al seguente esempio.

 
       {
            "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"
                },
                ...
            ]
        }  
            
            

Ribanciamento manuale

Quando si aumenta la scalabilità, se il numero di obiettivi aumenta notevolmente, esiste la possibilità di una distribuzione ineguale del carico a causa della viscosità. In questo scenario, puoi riequilibrare il carico sugli obiettivi utilizzando le due opzioni seguenti:

• Imposta una scadenza del cookie generato dall'applicazione che è precedente alla data e ora correnti. Ciò impedirà ai client di inviare il cookie all'Application Load Balancer, che riavvierà il processo di determinazione della persistenza.

• Imposta una durata molto breve sulla configurazione della viscosità basata sull'applicazione del sistema di bilanciamento del carico, ad esempio 1 secondo. Ciò forza l'Application Load Balancer a ristabilire la viscosità anche se il cookie impostato dal target non è scaduto.