Cosa restituisce un bilanciatore del carico?

L'IP finale non è pubblicato. Il processo funziona in un modo in cui il client (un utente che colpisce il bilanciatore) crede di stare comunicando con il bilanciatore, mentre parla con un nodo reale.

In una spiegazione molto semplice , la maggior parte delle transazioni funziona in questo modo:

1. Un utente effettua una richiesta al servizio di bilanciamento del carico.
2. Il bilanciatore decide quale nodo è il più adatto (in base alla strategia che stai usando per il bilanciamento) e sceglie (cambia) l'IP di destinazione.
3. (Qui è dove avviene la magia.) Il nodo riceve una richiesta, accetta la connessione e risponde al bilanciatore.
4. Il bilanciatore cambia l'IP di risposta su quello virtuale, quello del bilanciatore e inoltra la risposta all'utente.
5. Voilà, l'utente riceve una risposta con l'IP della richiesta iniziale, anche se è stata effettivamente elaborata da qualche altra parte.

Tenere presente che la riscrittura dei pacchetti (la modifica dell'indirizzo IP nel passaggio 4) è molto importante. Senza di esso il client, ricevendo un pacchetto da un IP di cui non si fida, semplicemente scarterebbe la risposta.

Il sistema di bilanciamento lad funziona sul livello 4 OSI. Decapsula il pacchetto fino al numero di porta e poi dirige il pacchetto con una delle 3 modalità.

Il bilanciamento del carico può funzionare in modalità 3: 1. Routing diretto In questa modalità il tuo real server utilizza IP pubblico. Il bilanciatore riceve il pacchetto e decapsula fino al livello 4. Se nella regola di bilanciamento del carico corrisponde, verrà reindirizzato il pacchetto (senza modificarlo) a uno di realserver. Realserver ha un indirizzo alias uguale con l'indirizzo loadbalance, quindi quando realserver riceve il pacchetto con una destinazione xxx.xxx.xxx.xxx definisce quel pacchetto direttamente al suo indirizzo (alias). E poi la vera richiesta di risposta del server al cliente diretto (non attraverso loadbalance).

2. NAT In questa modalità il pacchetto reindirizza a realserver con la modifica dell'indirizzo di destinazione. L'indirizzo di destinazione verrà sostituito con l'indirizzo realserver (NAT). In questa modalità il tuo real server non ha bisogno di IP pubblico, può utilizzare la tua rete locale. E poi il pacchetto sarà la consegna nessun nuovo indirizzo di destinazione. Quando realserver riceve il pacchetto, risponderà all'indirizzo di richiesta del cliente tramite gateway (loadbalance). In questa modalità, il tuo loadbalance viene utilizzato come router e amp; come gateway del tuo realserver.

3. Tunnel In questa modalità il pacchetto verrà sintonizzato con il nuovo indirizzo src-dst (come vpn) per il pacchetto di consegna su realserver. quando il pacchetto viene ricevuto in realserver, realserver risponderà tramite pipe tunneled loadbalance. E poi loadbalance delivery reply ti real request source address.

Per HTTPS / SSL, loadbalance non lo elabora, processo di bilanciamento del carico fino al livello 4 OSI. Il livello 5 sopra sarà processato in realserver. Quindi l'hanshake TCP a 3 vie, SSL / HTTPS, è stato elaborato in realserver. Loadbalance only director of the packet.

Spero che la mia piccola spiegazione possa aiutare qualcosa.

Un bilanciamento del carico può essere un router o un proxy inverso:

LVS è lo standard di settore Layer 4 (basato sul routing) modulo di bilanciamento del carico per il kernel Linux. Viene utilizzato in vari sistemi di bilanciamento del carico commerciale tra cui Barracuda, Loadbalancer.org e Kemp Technologies. Barracuda e Loadbalancer.org utilizzano anche HAProxy per il bilanciamento del carico di livello 7 ( proxy inverso basato ).

Ps. Ho dimenticato che questo non mostra da dove vengo, che è ovviamente Loadbalancer.org