perché nessun esempio di bilanciamento del carico software bilanciamento orizzontale ssl?

Ho un sacco di domande riguardo a SSL, sessioni locali e bilanciamento del carico che sembrano essere interconnessi, quindi mi scuso in anticipo per la lunghezza di questa domanda.

Ho un sito Web che utilizza sessioni basate su file. La natura del sito è che la maggior parte è http, ma alcune sezioni sono ssl. Attualmente, a causa delle sessioni basate su file, è necessario che qualsiasi richiesta ssl raggiunga lo stesso server delle precedenti richieste http.

A causa dei limiti di tempo, voglio fare la cosa più semplice possibile per bilanciare il carico di traffico http e ssl aumentato.

Sembra che ci siano 2 opzioni per gli algoritmi di bilanciamento del carico appiccicoso:

• basato su ip
• basato sui cookie

La soluzione basata su ip probabilmente funzionerà, ma l'algoritmo di hashing cambierà potenzialmente il server a cui un utente va quando un server si arresta o viene aggiunto, il che è indesiderabile con l'attuale configurazione della sessione basata su file. Suppongo anche che sia tecnicamente possibile per un utente cambiare legittimamente ips durante la navigazione di un sito Web.

L'algoritmo basato sui cookie sembra migliore, ma l'incapacità di ispezionare i cookie quando crittografati da ssl sembra presentare i propri problemi.

Ho cercato su Google esempi su come caricare il bilanciamento del carico SSL e non riesco a trovare alcun esempio esplicito di configurazioni in grado di eseguire il bilanciamento del carico basato sui cookie E che può gestire un aumento del carico SSL aggiungendo un altro decodificatore SSL.

La maggior parte degli esempi espliciti che ho visto hanno il decoder ssl (di solito hardware, apache_mod_ssl o nginx) che si trova tra il client browser e il bilanciamento del carico. Gli esempi di solito sembrano avere qualcosa del genere (modificato da http://haproxy.1wt.eu/download/1.3/doc/architecture.txt ):

      192.168.1.1 192.168.1.11-192.168.1.14
 ------- + ----------- + ----- + ----- + ----- +
        | | | | |       
     + - + - + + - + - + + - + - + + - + - + + - + - +    
     | LB1 | | A | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + --- +    
     apache 4 server web economici
     mod_ssl
     HAProxy 

La parte di decodifica ssl nell'esempio sopra sembra essere un potenziale collo di bottiglia che non è scalabile orizzontalmente.

Ho guardato haproxy, e sembra avere un'opzione 'mode tcp' che consentirebbe qualcosa del genere, che ti permetterebbe di avere più decodificatori ssl:

              HAProxy
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

Tuttavia, in una tale configurazione, sembra che perderai l'ip del client perché haproxy non sta decodificando l'sl: https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -per

Ho anche esaminato nginx e non vedo esempi espliciti di decodificatori ssl scalabili orizzontalmente. Sembrano esserci molti esempi di persone che hanno nginx come potenziale collo di bottiglia. E almeno questo collegamento sembra suggerire che nginx non ha nemmeno l'opzione di installazione simile a quella di un alproxy in cui si perderebbe l'ip dicendo che nginx "non supporta il passaggio trasparente delle connessioni TCP a un backend" Come passare Apache Traffico SSL tramite proxy nginx? .

Domande:

• Perché non sembrano esserci più esempi di configurazioni che aggiungono più decoder ssl per gestire l'aumento del traffico?
• È perché la fase di decodifica ssl è solo un collo di bottiglia teorico e, praticamente parlando, un decodificatore sarà essenzialmente sufficiente tranne che per i siti con traffico ridicolo?
• Un'altra possibile soluzione che viene in mente è forse che chiunque abbia esigenze così elevate in ssl ha anche un archivio di sessioni centralizzato, quindi non importa quale server web colpisce il client su richieste sequenziali. Quindi è possibile abilitare mod_ssl o equivalente su ogni server web.
• La soluzione haproxy citata sopra sembra funzionare (oltre al problema dell'IP client), ma qualcuno ha trovato una soluzione appiccicosa di bilanciamento del carico basata su cookie che funzionerebbe aumentando il numero di decodificatori mantenendo l'IP client, o forse tecnicamente no possibile (poiché è necessario decodificare la richiesta per ottenere l'IP client, nel qual caso è presente un collo di bottiglia del decodificatore).

Supponendo che tutto ciò che ho detto sia vero, queste sembrano essere le mie opzioni:

• usa l'hash dell'ip (male per gli utenti che potenzialmente cambiano legittimamente ips e per gli scenari di aggiunta e rilascio del server)
• usa nginx o mod_ssl come primo programma toccando la richiesta ssl, questo sarà un potenziale collo di bottiglia di decodifica ssl
• usa haproxy come primo programma toccando la richiesta ssl, ottenendo la scalabilità orizzontale ssl, ma live senza ips registrati a livello di server web per richieste ssl (probabilmente temporaneamente ok)
• a lungo termine, passare a un archivio di sessioni mobile o centralizzato, rendendo superflue le sessioni appiccicose

La "cosa più semplice", in tutta serietà, è passare a un archivio di sessioni centralizzato. Devi configurare tutto questo impianto idraulico con bilanciamento del carico, haproxy, SSL e tutto il resto, quando ogni bit di codice di gestione delle sessioni che abbia mai visto rende quasi banale collegare diversi motori di archiviazione, quindi un po 'di codice e pochissima complessità extra risolve tutti i tuoi problemi.

womble ha ragione sull'archivio di sessioni condivise che rende le cose molto più semplici. Oltre alla sua risposta, posso espandere un po 'le parti di bilanciamento del carico della domanda:

Perché non sembrano esserci più esempi di configurazioni che aggiungono più decoder ssl per gestire l'aumento del traffico?

I moderni PC multi-core possono eseguire diverse migliaia di transazioni SSL al secondo. E se questo diventa un collo di bottiglia, un'appliance dedicata di F5 , Citrix, Cisco o simili può essere ancora più veloce. Quindi la maggior parte dei siti non supera mai una buona soluzione SSL e bilanciamento del carico per singolo dispositivo.

Supponendo che tutto ciò che ho detto sia vero, queste sembrano essere le mie opzioni:

Ci sono opzioni per ridimensionare la decrittazione SSL in orizzontale, se ne hai bisogno.

L'approccio comune è utilizzare DNS Round Robin per coppie di acceleratori SSL altamente disponibili, ovvero pubblicare più indirizzi IP per il dominio, ogni indirizzo IP che punta a una coppia di acceleratori SSL.

In questo caso, potresti preoccuparti del timeout del TTL DNS nel mezzo di una sessione utente, portando l'utente su un altro server delle applicazioni. Questo non dovrebbe essere un evento comune, ma potrebbe accadere. Un archivio di sessioni condivise è la soluzione comune, ma può essere gestito in altri modi.

Ad esempio, è possibile separare la decrittografia SSL dal bilanciamento del server delle applicazioni. La gestione SSL richiede più CPU rispetto al bilanciamento del carico di base, quindi un singolo bilanciamento del carico dovrebbe essere in grado di saturare un paio di acceleratori SSL. Come questo:

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

Come accennato all'inizio, un archivio di sessioni condivise semplifica molte cose ed è quasi certamente una soluzione a lungo termine migliore rispetto a mettere molta complessità nel livello SSL / bilanciamento del carico.

È divertente rispondere a domande di 2 anni come questa quando i prodotti si sono evoluti. Al momento haproxy supporta il protocollo PROXY, che gli consente di passare l'IP del client all'hop successivo anche in modalità TCP pura. Supporta anche SSL nativo, così come l'adesività SSL se si desidera utilizzarlo come primo livello di fronte a una farm SSL (possibilmente realizzata da server haproxy). Quindi sembra che la tua richiesta fosse un po 'in anticipo e che le implementazioni abbiano raggiunto :-)

Sono d'accordo con womble e Jesper qui. Il percorso più semplice / migliore è correggere il codice. Ovviamente come amministratori di sistema spesso non abbiamo questa opzione, ma anche in quel caso ci sono abbastanza trucchi che puoi fare per ottenere hardware moderno relativamente economico da scalare abbastanza lontano anche se non veramente in orizzontale.

Volevo solo postare un commento su dove ti preoccupi di perdere il client-ip. In una qualsiasi delle principali soluzioni L7 / proxy puoi inserire un'intestazione X-Forwarded-For (o qualunque cosa tu voglia) nella richiesta. Quindi sul server Web back-end che riceve la richiesta è possibile modificare il formato del file di registro per registrare quel valore nello stesso spazio nel file utilizzato per registrare l'ip client layer3. In questo modo qualsiasi software di analisi dei registri non vede la differenza (né lo fai durante la coda).

Ci sono compromessi in tutto e non abbiamo sentito abbastanza della tua configurazione da sapere, ma con il trio che non puoi sbagliare di ha-proxy, nginx e vernice là fuori è probabilmente una buona idea spostare il tuo bilanciamento del carico a uno strumento di livello proxy. Ciò risolverà il tuo problema ssl e ti offrirà una serie di nuove opzioni come la memorizzazione nella cache, la commutazione dei contenuti e la manipolazione delle intestazioni.

Alcuni pensieri casuali;)

Innanzitutto, scatta la persona che ha deciso di utilizzare i dati della sessione basata su file. Non è possibile che la lettura / scrittura di dati da un file system sia più veloce di un semplice ritorno alla fonte per estrarre i dati necessari. Si tratta del peggior modo di procedere.

Personalmente non ho mai visto una situazione in cui l'archiviazione dei dati in una sessione era meglio del semplice estrazione diretta dal database, se necessario. Detto questo, ho visto dove l'uso di memcache o strategie di cache simili possono aiutare un sito a scalare a milioni di utenti, ma questo non è nemmeno nello stesso parco palla dell'uso delle sessioni.

In secondo luogo, hai appena trovato il motivo numero uno per non utilizzare affatto le sessioni: il bilanciamento del carico. Cordiali saluti - Sticky non significa bloccato. Anche con le sessioni Sticky attivate, si esegue la possibilità molto reale che l'utente venga trasferito su un altro server durante l'utilizzo dell'app. Questo accadrà nei momenti più inopportuni. Sticky significa solo che il bilanciamento del carico proverà a reinserire l'utente sul server da cui ha iniziato, ma non è affatto una garanzia.

Questo punto di solito porta le persone a memorizzare la sessione nel database ... Che credo sia un completo fallimento . Perché la sessione funzioni, deve essere caricata e scritta su ogni richiesta di pagina. Quando è archiviato in un database (necessario per server con bilanciamento del carico), sono necessarie due query sul server: la prima per ottenere i dati, la seconda per scrivere eventuali aggiornamenti.

La parte fallita è che le persone di solito usano le sessioni in modo da non dover tornare al database per estrarre cose come il nome degli utenti ... Ma se la pagina deve interrogare il database per caricare una sessione, allora ... beh, dovresti essere in grado di vedere il problema logico qui.

Solo è peggio con le sessioni ... perché il loro elaboratore di pagine deve riscrivere i dati della sessione nel database alla fine del ciclo di vita della pagina ... nel caso qualcosa fosse cambiato. Il che significa invece di una query per estrarre il nome di quell'utente che ne si ottiene con due. Per ogni singolo caricamento della pagina. Inoltre significa serializzare e deserializzare i dati che hanno il loro impatto sulle prestazioni.

Il mio punto è: la sessione è malvagia e di solito stai meglio senza di essa. I siti a basso traffico che funzionano solo su un server Web non necessitano del miglioramento delle prestazioni che può verificarsi; e i siti ad alto traffico in esecuzione in una Web farm sono limitati nel ridimensionamento a causa di essa.

Anziché utilizzare Haproxy sul fronte, è possibile utilizzare DNS round robin per eseguire un bilanciamento approssimativo tra più decodificatori SSL, quindi passarlo a haproxy per il corretto bilanciamento del carico.