Ti ascolto.
E bentornati.
Nel video di oggi parleremo delle sessioni appiccicose.
Prima di approfondire questo argomento, analizziamo una sfida tipica.
In genere, in una configurazione basata su un bilanciatore di carico, il traffico degli utenti viene distribuito tra più server
di backend.
Ad esempio, supponiamo che la prima richiesta fatta da un utente vada al server uno.
La seconda richiesta che fa, potrebbe andare al server due e così via.
Così il traffico viene distribuito.
Lo stesso vale per l'utente.
Tre.
Se le richieste successive vengono indirizzate a server diversi, anche le informazioni sulla sessione
vengono perse.
Ad esempio, supponiamo che vi rechiate in una banca.
Avete qualche problema.
Siete andati in banca, avete spiegato l'intero problema a una persona, una persona che ora è in grado di farlo.
A vi ha chiesto di venire domani per applicare una soluzione adeguata.
Ora, domani siete andati e la persona non c'era.
Che cosa è successo?
Ora siete andati da una persona.
B, ora la persona B non conosce realmente il vostro problema.
Quindi, ancora una volta, si deve spiegare l'intero problema alla persona B. Questo è ciò che accade realmente anche nella configurazione
basata sul bilanciatore di carico.
In genere, per i siti web statici non si tratta di un grosso problema, perché si tratta di siti web statici.
Entrambi i server hanno lo stesso set di pagine per i siti web dinamici.
Diventa davvero un problema.
Uno dei modi per risolvere questo problema è la sessione adesiva.
Quindi, la sessione appiccicosa si riferisce a una caratteristica di molti bilanciatori di carico per indirizzare la richiesta di una particolare
sessione alla stessa macchina fisica che ha servito la prima richiesta di quella sessione.
Quindi un utente, la prima richiesta che ha fatto è andata al server uno.
Ora la successiva richiesta di richiesta a tre richieste per tutte le richieste che farà.
Tutte le richieste verranno inviate al server stesso.
Sempre facendo l'esempio di una banca, siete andati in banca il primo giorno, avete incontrato la persona A il secondo giorno, avete incontrato
la persona A il secondo giorno, avete incontrato la persona A. Quindi state incontrando la stessa persona in banca e lui è a conoscenza
di tutti i vostri problemi in corso e di tutti i vostri problemi passati.
Così sarà in grado di aiutarvi in modo molto più efficiente.
È qui che entra in gioco anche la sessione adesiva.
Ora, le sessioni appiccicose sono supportate anche dal lato dei bilanciamenti di carico.
Parliamo quindi prima del bilanciatore di carico delle applicazioni.
Quindi, per impostazione predefinita, l'applicazione bilancia il carico di ogni richiesta in modo indipendente verso una destinazione registrata,
in base a un algoritmo di bilanciamento del carico scelto.
È molto simile a quanto discusso nella prima diapositiva: la richiesta potrebbe andare prima
al server uno, poi al server due e così via.
Tuttavia, in caso di necessità, è possibile utilizzare una funzione di sessione appiccicosa per consentire al bilanciatore
di carico di legare la sessione di un utente a un obiettivo specifico.
Ora, se vedete che avete un browser web, un browser web, due browser web, uno fa una richiesta, uno o due sono tre
al bilanciatore di carico, il bilanciatore di carico dirigerà.
Tutte le richieste sono una o due sono tre alla stessa istanza EC due.
Ora questa impostazione è applicabile dopo che la sessione appiccicosa è stata attivata.
Altrimenti il bilanciatore di carico potrebbe indirizzare la richiesta r uno a e.
c2122e.
c2232, e, c23 e così via.
Quindi facciamo una cosa.
Andiamo avanti e approfondiamo.
Per la configurazione di oggi, ho a disposizione due bilanciatori di carico.
Uno è il bilanciatore di carico delle applicazioni e l'altro è il bilanciatore di carico classico e vedremo
come abilitare le sessioni appiccicose.
Per prima cosa, esploriamo il bilanciatore di carico delle applicazioni.
A questo punto non si ha più l'abilitazione di una sessione appiccicosa.
Procediamo con la copia di questo.
Ora, prima di procedere all'esplorazione di questo aspetto, lasciate che vi mostri anche le istanze.
Quindi ci sono due EC, due istanze che eseguono Engine X e il bilanciatore di carico, sia il classico
che l'applicazione sono associati a queste due istanze.
Quindi, procedo a incollare l'URL del bilanciatore di carico dell'applicazione.
Per prima cosa, è andato all'istanza EC due, la numero due, che ha un sito web di classe pagina a.
Se aggiorno la pagina, si passa a quella del sito web, che è facile da usare.
Una rinfrescata.
Ora è passato al sito web due.
Quindi il classico stato di bilanciamento del carico in cui più richieste vengono indirizzate a server diversi.
Ora diciamo che non lo vogliamo veramente.
Quindi possiamo abilitare le sessioni appiccicose.
Tuttavia, prima di abilitare le sessioni appiccicose.
Vi mostrerò le esatte intestazioni di risposta di HTTP.
Queste sono tutte le intestazioni di risposta.
Ora ne terremo nota e controlleremo le intestazioni di risposta dopo che la sessione appiccicosa è
stata attivata.
Ora, all'interno del bilanciatore di carico, in particolare per il bilanciatore di carico delle applicazioni, andiamo
al gruppo di destinazione associato al nostro ALB.
Esiste un solo gruppo target associato.
Procediamo con la modifica degli attributi del gruppo di destinazione e abbiamo un'opzione di adesività.
Abilitiamo l'appiccicosità.
E ora chiede la durata dell'adesività, che può andare da un secondo a sette giorni.
È inoltre possibile selezionare le cose di conseguenza.
Permettetemi di dire che l'appiccicosità è di un giorno.
Quindi procedo e salvo la modifica.
Quindi, ora che abbiamo le sessioni appiccicose, abilitiamo la richiesta a una specifica istanza EC due solo per la durata
della nostra sessione appiccicosa.
Andiamo avanti e esploriamo questo aspetto.
Lasciate che aggiorni la pagina.
Il sito web sarà due.
Rinfresciamo di nuovo.
Di nuovo, sito web due, aggiorniamo per la terza volta il sito web due, per la quarta volta il sito web due e per la quinta volta
il sito web due.
Ecco cosa ci permettono di fare le sessioni appiccicose.
Ora, in modo analogo, facciamo di nuovo una richiesta di chiamata.
Ora si possono vedere le intestazioni di risposta tra la prima e la seconda.
Uno degli elementi aggiuntivi che vengono aggiunti è un biscotto.
Il nome del cookie è un più AILBHE e poi ci sono le informazioni relative al cookie.
Quindi, una volta abilitate le sessioni appiccicose, è necessario aggiungere anche un cookie.
Il cookie è qualcosa che il browser web invia al bilanciatore di carico.
Il bilanciatore di carico leggerà il cookie e identificherà che l'utente è stato indirizzato all'istanza EC due
uno.
Quindi, una volta letto di nuovo il cookie, indirizzerà l'utente alla stessa istanza EC due.
È così che il bilanciatore di carico sa che un cliente specifico deve essere indirizzato a una griglia di server specifica.
Ora, per quanto riguarda il bilanciatore di carico delle applicazioni, è possibile impostare la sessione appiccicosa a livello di gruppo
di destinazione.
Tuttavia, per il bilanciatore di carico classico, si può procedere.
E abilitare l'appiccicosità.
Quindi attualmente l'adesività è disabilitata.
Si può procedere ad abilitare l'appiccicosità anche qui.
Come per il bilanciatore di carico delle applicazioni, è possibile specificare il periodo di scadenza.
Quindi rivediamo rapidamente il flusso di lavoro.
Quindi, ogni volta che un client effettua una richiesta al bilanciatore di carico, quest'ultimo crea un cookie.
Quindi, in questo caso, l'obiettivo del cookie è uguale a EC due uno.
Quindi la richiesta viene indirizzata a EC due e il cookie viene rinviato al client.
Ora il client, quando effettua la prossima richiesta al bilanciatore di carico, deve inviare il cookie che gli
è stato inviato dal bilanciatore di carico.
Dopo che il client ha rinviato il cookie al bilanciatore di carico.
Il bilanciatore di carico è in grado di capire che questo cookie è stato associato all'EC due e anche la seconda
richiesta sarà inviata all'EC.
Due uno.
Se il cookie non viene realmente inviato di nuovo, dipende dall'algoritmo utilizzato.
Se il cookie non viene realmente inviato, il bilanciatore di carico elastico potrebbe non saperlo e potrebbe indirizzare
la richiesta anche all'istanza EC due.
Questo è il flusso di lavoro di alto livello su uno dei modi in cui vengono stabilite le sessioni appiccicose.
Esaminiamo ora rapidamente i vantaggi delle sessioni appiccicose.
Il primo è che quando si utilizzano le sessioni appiccicose, i server non hanno bisogno di scambiare i dati della sessione,
riducendo così al minimo il trasferimento dei dati.
In caso contrario, è necessario scambiare i dati di sessione tra tutti i server, in modo che possano ricordare cosa l'utente
è venuto a cercare esattamente.
In secondo luogo, le sessioni appiccicose possono consentire un migliore utilizzo della cache RAM e quindi una migliore reattività.
Analizziamo ora alcuni degli svantaggi.
Il primo è che con le sessioni sticky, il bilanciamento del carico complessivo del traffico tra i server può essere influenzato.
Molto importante.
Parte seconda Ricordate che può accadere che uno specifico server sia sovraccarico se accumula troppe sessioni o
se specifiche sessioni appiccicose richiedono un numero elevato di risorse.
Quindi, se dieci utenti sono indirizzati all'istanza EC2, una sessione diciamo appiccicosa è abilitata per
tre giorni di durata.
Tuttavia, se tutti i dieci server sono diretti all'istanza EC due uno, l'istanza EC due due è
completamente vuota.
Non ci sono sessioni o non ci sono affatto connessioni.
E ora cosa succederà?
L'istanza EC due uno è sovraccarica perché tutti gli utenti che avevano il cookie esistente vengono indirizzati
all'istanza EC due uno.
Questo può essere uno svantaggio delle sessioni appiccicose.
Ottimo.
Si tratta quindi di una panoramica di alto livello sulle basi delle sessioni appiccicose e con questo concludiamo
il video di oggi.