C’è stato un tempo in cui i dinosauri vagavano sulla terra; gli esseri umani hanno iniziato a lavorare con strumenti come le rocce e i bilanciatori di carico di livello 4 basati su DSR.
All’epoca, questi strumenti erano utili perché permettevano di raggiungere i server e anche perché era facile assicurarsi che al server delle applicazioni venisse presentato l’indirizzo IP effettivo del cliente.
Un bilanciatore di carico si colloca tra il client e l’applicazione, quindi guardando indietro dall’applicazione, chi è il mittente? Il cliente (sì, grazie) o il bilanciatore di carico?
È stato abbastanza facile e hai avuto a disposizione alcune scelte.
Modalità DSR – Direct Server Return.
- Il client si connette al bilanciatore di carico.
- Il bilanciatore di carico lo invia all’applicazione con l’IP di origine del cliente.
- L’applicazione invierà quindi una risposta direttamente al cliente. Probabilmente noterà che l’IP di origine è un IP esterno, quindi instraderà la risposta verso il gateway, saltando così il bilanciatore di carico sulla risposta.
Ai dinosauri piaceva questo approccio perché utilizzava meno risorse per l’infrastruttura e l’applicazione riceveva il vero IP del cliente.
L’aspetto negativo è che devi eseguire una configurazione di rete speciale sul server dell’app e sulla grande rivelazione… Il bilanciatore di carico non riceve o vede la risposta, quindi qualsiasi SSL o passaggio di contenuti è fuori dalla finestra.
L’altro svantaggio è che il LB non ha idea di come si stia comportando il server dell’app, quindi è più difficile bilanciare il carico sui server che, con ogni probabilità, hanno prestazioni migliori. L’ADC utilizzerebbe i server che rispondono più velocemente o che hanno meno connessioni. (L’uomo dell’età della pietra può installare un agente sul server delle app per ottenere questo dato) oppure l’ADC potrebbe utilizzare SNMP per ottenere questo dato.
In ogni caso, questa configurazione ha funzionato bene per molti anni, come il cavallo e il carro, e in effetti ci sono ancora situazioni in cui questa è l’opzione migliore, come le corse delle bighe o alcuni protocolli più antichi, per esempio.
Il prossimo è:
Modalità gateway
- Il client si connette al bilanciatore di carico
- Il bilanciatore di carico lo invierà all’App Server con l’IP di origine del client.
- L’applicazione invierà quindi una risposta direttamente al cliente, MA ATTRAVERSO il bilanciatore di carico perché hai cambiato il gateway predefinito dell’App Server con quello del bilanciatore di carico. Ciò significa che il bilanciatore di carico riceverà la risposta.
Per certi versi è molto meglio, ma TUTTO il traffico esterno dal server delle app, come gli aggiornamenti software, passa attraverso il bilanciatore di carico, per cui si crea confusione.
Questo era più comune quando i bilanciatori di carico avevano l’aspetto di switch e tutto era collegato direttamente con collegamenti di rete ad alta velocità e stringhe.
L’uomo impara a coltivare e a utilizzare il bilanciamento del carico basato su proxy
In questo periodo, le reti e le velocità della CPU diventavano più veloci e abbiamo iniziato a vedere l’approccio Proxy.
Abbiamo deciso di fare chiarezza e di iniziare a utilizzare il bilanciatore di carico come IP di origine piuttosto che ingannare il server delle applicazioni. Lo abbiamo fatto per molte ragioni, tra cui le prestazioni TCP, la sicurezza e la possibilità di fornire servizi aggiuntivi al bilanciatore di carico.
Ma questo allontanamento dalla raccolta dei cacciatori comportava un prezzo e una sfida non indifferenti.
Come si invia l’IP del client al server delle applicazioni?
Fortunatamente, il buon vecchio HTTP aveva un’ottima risposta, a patto che si utilizzasse l’HTTP.
X_Forwarded_For Header – ti permette di inserire l’IP del cliente nell’header e poi di inviarlo.
Non ti spiegherò nei dettagli perché è piuttosto semplice, ma ti basti sapere che è un’intestazione che chiunque può impostare facilmente. Inoltre, può diventare complesso. Ad esempio, cosa succede se al bilanciatore di carico viene già inviato un IP X_Forwareded_For? Dovrebbe utilizzare quello o utilizzare l’IP sorgente e modificarlo? In genere è possibile configurare questi aspetti su un LB decente, ma tutti hanno considerazioni sulla sicurezza, ecc.
In ogni caso, il 99% delle volte, ogni volta che un’applicazione web ha bisogno del sorgente, è così che lo ottiene (Nota: il 99% delle statistiche sono inventate)
E gli altri protocolli?
Alcuni hanno alcuni hack specifici per il protocollo, ma non c’è nulla di generico che sia più ampiamente adottato.
Questo fino a quando non è stato proposto e adottato il Protocollo Proxy.
Spiegazione del protocollo proxy
Il protocollo proxy risolve questo problema aggiungendo un’intestazione alla richiesta inoltrata che contiene i dettagli della connessione del cliente originale.
Esistono già due versioni di questo protocollo.
- Protocollo Proxy v1: Utilizza un formato di testo semplice e leggibile dall’uomo.
- Protocollo Proxy v2: Utilizza un formato binario, più efficiente e in grado di supportare funzionalità aggiuntive come IPv6 e indirizzi socket Unix.
L’aspetto diverso è che la maggior parte dei server applicativi si romperanno se li abiliti senza averli configurati per accettarli. Questo perché il protocollo proxy aggiunge letteralmente i dettagli richiesti all’inizio dei dati.
Tuttavia, l’adozione sta crescendo e molti fornitori ora supportano questa soluzione.
È ottimo per il proxying DNS, ad esempio.
Come per X_Forwardard_For, ci sono ancora alcune decisioni da prendere:
Ad esempio, cosa vuoi che faccia il bilanciatore di carico se ti viene presentata un’intestazione di protocollo proxy? Rimuoverla e impostarne una nuova o mantenerla? Se non ti aspetti l’invio di un’intestazione, è meglio ignorarla e creare la propria, ma queste decisioni devono essere prese in considerazione.
Il protocollo proxy è un modo semplice per ottenere l’IP del client ed è ora ampiamente supportato, quindi vai avanti e divertiti.
Torno a pensare all’alta disponibilità nel cloud, Ciao!
