Cosa restituisce un bilanciamento del carico?


12

Quando un utente raggiunge il bilanciamento del carico e il bilanciamento del carico determina a quale server Web inoltrare, cosa succede dopo? Il bilanciamento del carico inoltra la richiesta e tutti i suoi dati al server Web, riceve la risposta del server Web e la restituisce all'utente?

O è più simile a un reindirizzamento in cui il bilanciamento del carico restituisce letteralmente l'indirizzo IP del server selezionato al browser e il browser deve aprire una nuova connessione con il server specificato?

Il mio istinto dice che non sarebbe il secondo perché ciò implicherebbe che tutti gli indirizzi IP del web server sarebbero pubblici e ho pensato che per motivi di sicurezza è meglio esporre al pubblico solo gli indirizzi di bilanciamento del carico. Ma poi non sono esattamente sicuro perché se si abilita SSL terminationil bilanciamento del carico, non è necessario ripristinare nuovamente SSL con il server reindirizzato?


Risposte:


13

L'IP finale non è pubblicato. Il processo in realtà funziona in un modo in cui il client (un utente che colpisce il bilanciatore) crede di comunicare 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 bilanciamento del carico.
  2. Il bilanciatore decide quale nodo è il più adatto (in base alla strategia utilizzata per il bilanciamento) e sceglie (cambia) l'IP di destinazione.
  3. (È qui che accade la magia.) Il nodo riceve una richiesta, accetta la connessione e risponde al bilanciatore.
  4. Il bilanciamento cambia l'IP di risposta in virtuale, quello del bilanciatore e inoltra la risposta all'utente.
  5. Voilà, l'utente riceve la risposta con l'IP della richiesta iniziale, anche se in realtà è stato elaborato altrove.

Tieni 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, scarterebbe semplicemente la risposta.


4

Lad balancer funziona su OSI di livello 4. Decapsula il pacchetto fino al numero di porta e quindi dirige il pacchetto con una delle 3 modalità.

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

2. NAT In questa modalità il pacchetto reindirizza a realserver con l'indirizzo di destinazione in modifica. L'indirizzo di destinazione verrà sostituito con l'indirizzo del realserver (NAT). In questa modalità il tuo realserver non ha bisogno di IP pubblico, può usare la tua rete locale. E quindi il pacchetto non recapiterà alcun nuovo indirizzo di destinazione. Quando realserver riceve un pacchetto, esso risponderà all'indirizzo di richiesta del client tramite gateway (loadbalance). In questa modalità il tuo bilanciamento del carico viene utilizzato come router e come gateway del tuo realserver.

3. Tunnel In questa modalità il pacchetto sarà sintonizzato con il nuovo indirizzo src-dst (come vpn) al pacchetto di consegna al realserver. quando il pacchetto viene ricevuto in realserver, realserver risponderà tramite il tunneling al bilanciamento del carico. E quindi risposta di consegna del bilanciamento del carico per l'indirizzo di origine della richiesta reale.

Per HTTPS / SSL, il bilanciamento del carico non lo elabora, il processo di bilanciamento del carico fino all'OSI di livello 4. Il livello 5 sopra sarà processato in realserver. Quindi TCP 3 vie hanshake, SSL / HTTPS è stato processato in realserver. Loadbalance solo direttore del pacchetto.

Spero che la mia piccola spiegazione sarà di aiuto in qualcosa.


Sembra che tu stia parlando di LVS qui, ma non è necessariamente il modo in cui funziona il bilanciamento del carico http (s). Dai un'occhiata al haproxy per esempio. Questa app esegue il bilanciamento del carico in userland e offre anche una piacevole funzionalità di routing back-end.
Friek,

Nel mio datacenter utilizzo lvs per bilanciare il carico del servizio app https e funziona e funziona bene.
dek.tiram,

Scusa la mia ignoranza, ma che cos'è "lvs"? È un concorrente per haproxy?
smaili,

Haproxy usa anche lvs. Uso piranha che usa anche lvs per il processo centrale.
dek.tiram,

haproxy è un'applicazione autonoma e non richiede affatto lvs (non è nemmeno a conoscenza dell'esistenza di lvs). È possibile utilizzare lvs per bilanciare un cluster di nodi haproxy, anche se il carico su haproxy diventa troppo pesante.
Friek,

-1

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

LVS è il modulo di bilanciamento del carico Layer 4 (basato sul routing) standard del settore per il kernel Linux. È utilizzato in vari bilanciatori di carico commerciali tra cui Barracuda, Loadbalancer.org e Kemp Technologies. Barracuda e Loadbalancer.org usano anche HAProxy per il bilanciamento del carico di livello 7 ( basato su proxy inverso ).

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


1
quando si pubblicano collegamenti a risorse esterne ci si aspetta che divulghino affiliazione, vedere Come non essere uno spammer
moscerino
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.