Come funzionano i cookie con i bilanciatori del carico non persistenti

Abbiamo un'applicazione Drupal che utilizza sso per accedere agli utenti.

Stiamo utilizzando i bilanciatori di carico classici (ELB) di AWS, AWS ci sta dicendo che sull'ELB non esiste persistenza di sessione.

Quello che sto cercando di capire è come funzionano i cookie senza persistenza sui classici sistemi di bilanciamento del carico.

esempio.com DNS è puntato sull'ELB. Ci sono 2 server nel pool Server1 e Server2

Ciò che vogliamo che accada è se un utente accede alla propria home page su http://example.com/user/12345/server 1, se non è già registrato, viene reindirizzato alla pagina sso http://example.com/user/login/sso, effettua automaticamente il login e ottiene un cookie SESS<hexnumber>e quindi reindirizzato ahttp://example.com/user/12345/

Non è consentito aggiungere alcun server di sessioni (redis) qual è la garanzia che rimarranno sul server 1 per entrambi i reindirizzamenti.

Per quanto ne so ad ogni hit di "esempio.com", l'utente potrebbe finire sul server 1 o sul server 2.

La mia domanda:

Se ricevono il cookie su server1 e quindi vengono reindirizzati a server2 come farà server2 a sapere che un cookie è già assegnato a quell'utente su server1?

Mi sembra di pensare in cerchio. Quando in passato abbiamo lavorato su questo tipo di installazione utilizzando LB senza persistenza di sessione, abbiamo utilizzato un server redis per contenere le sessioni e ogni richiesta avrebbe esaminato il server redis per le informazioni sulla sessione.

Un cookie è impostato nel browser, non in un server. È limitato a un dominio e, facoltativamente, a un percorso specifico nell'URL, quindi finché entrambi i server sono accessibili dallo stesso dominio, il cookie sarà presente.

Se un cookie punta a una sessione, è necessario che sia server1 che server2 abbiano accesso a quella sessione in qualche modo. Se le sessioni non possono essere condivise tra i server, è necessario forzare un utente a persistere su un server specifico. Questo può essere facilmente realizzato con DNS e un po 'di magia di riscrittura degli URL:

• www.example.com punta a entrambi i server.
• www1.example.com punta solo a server1
• www2.example.com punta solo a server2

Utilizzando una serie di semplici regole di riscrittura (ish) e un cookie, l'utente può quindi essere bloccato su un determinato server, garantendo che la sua sessione persista.

Ecco qualche dettaglio in più.

DNS:

• esempio.com A 1.1.1.1, A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

Riscrivi le regole:

• cookie di persistenza: "backend"
• connessione iniziale: "backend" non definito, impostare "backend" su www1 o www2, a seconda del server che ha risposto e reindirizzare a quel server. Il cookie deve essere impostato sul dominio "esempio.com", in questo modo verrà caricato sia su www1 che su www2
• Se viene definito "backend", assicurarsi che il suo valore corrisponda all'istanza del server e, se necessario, reindirizzare.
• Assicurarsi che il cookie di sessione sia definito nel nome di dominio completo del server, ovvero www1.example.com o www2.example.com

La logica di riscrittura deve essere definita nel server Web stesso. Tutti i moderni server Web hanno linguaggi di riscrittura molto caratteristici che sono totalmente in grado di implementare questa funzionalità.

Se non è possibile utilizzare un database di gestione delle sessioni come Elasticache Redis (Redis per sole sessioni non dovrebbe costare più di $ 15 al mese), l'opzione successiva successiva è abilitare le sessioni permanenti sull'ELB;

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Ciò costringerà gli utenti a passare allo stesso nodo back-end durante la sessione. Un "cookie generato dal bilanciamento del carico" con una durata di 900 secondi dovrebbe essere abbastanza buono, ma puoi modificarlo.