Indice del forum www.zeroshell.net
Distribuzione Linux ZeroShell
 
 FAQFAQ   CercaCerca  GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo  Log inLog in   Messaggi privatiMessaggi privati 

load-balancer http con gestione "session affinity"

 
Nuovo argomento   Rispondi    Indice del forum -> Suggerimento nuove funzionalità
Precedente :: Successivo  
Autore Messaggio
sherpa



Registrato: 23/06/09 21:38
Messaggi: 1

MessaggioInviato: Mar Giu 23, 2009 10:01 pm    Oggetto: load-balancer http con gestione "session affinity" Rispondi citando

La funzione netbalancer di ZS al momento consente solo la strategia round-robin, che ne' limita molto l'utilizzo come load-balancer http per siti web.

Purtroppo, molti siti web hanno la necessita' di mantenere "sticky sessions", cioe', una volta autenticato, un client deve sempre essere instradato verso lo stesso server per la durata della sessione utente.

Le soluzioni adottate per garantire "sticky sessions" sono in genere queste:

1) source IP
Quando un client fa la prima richiesta, gli viene assegnato un server (quello con minor carico). Tutte le successive richieste da parte di quel client (identificato tramite il suo source IP) vengono instradate al medesimo server. Dopo un certo timeout senza ricevere richiest, l'associazione client-server viene eliminata
Pro: trasparente
Contro: nel caso ci sia un proxy o NAT tra i clients ed il load-balancer, il bilanciamento sara' nullo

2) Cooky injection
Quando un client fa la prima richiesta, il load-balancer genera un ID univoco e lo invia come cookie http al client.
Ad ogni successiva richiesta, il load-balancer ricevera' dal client il cookie con l'ID univoco e sapra' quindi a quale server instradarlo.

3) SSL
Nel caso di connessione SSL, la richiesta del client contiene gia' un ID univoco che lo identifica e quindi puo' essere ispezionata per mantenere l'associazione con un determinato server

Ci sarebbero poi da implementare strategie piu' sofisticate per determinare il carico di un server, in modo da instradare i clients in modo piu' efficiente rispetto ad un semplice round-robin. In genere, si puoì usare:
- numero di sessioni "sticky" per server
- CPU load di ciascun server (richiede un daemon o SMNP in esecuzione su ciascun server

Anche la funzione di watchdog e' importante. Potrebbe essere implementata anche come un semplice ping o http get ogni qualche secondo verso ciascun server.


Il load-balancing attualmente richiede apparati piuttosto costosi e credo che ZS possa essere un'ottima alternativa.
Top
Profilo Invia messaggio privato
martino87r



Registrato: 22/06/08 22:44
Messaggi: 67

MessaggioInviato: Ven Giu 26, 2009 12:15 am    Oggetto: Rispondi citando

Quello di cui parli e' un load balancer specifico per HTTP. Ovviamente c'e' un motivo se gli apparati che bilanciano le connessioni dei datacenter sono cosi' costosi... Il motivo e' proprio quello che hai scritto tu, cioe' non basta un round robin per bilanciare correttamente server su traffico HTTP(s) e sopratutto mantenere in ordine le connsessioni TCP.

Comunque l'anno scorso mi sembra di aver letto un articolo della Red hat che spiegava come implementare sia load balancing sia fault tollerance per server farm su connessioni TCP per protocollo HTTP, credo che cercando bene sul sito della red hat riesci a trovarlo.

Per quanto ZS, non mi sembra una feature vitale per il momento oltreche' molto complessa da implementare...
Vediamo cosa ne pensa Fulvio
Top
Profilo Invia messaggio privato
s.borrelli



Registrato: 09/02/09 17:37
Messaggi: 8

MessaggioInviato: Ven Ago 07, 2009 10:24 am    Oggetto: Rispondi citando

capisco che la feature non è vitale...però condivido quello che dice sherpa.
Ho valutato diversi apparati che dovrebbero fare bilanciamento per i WS e tutti sono molto costosi.
Avere una feature del genere su zeroshell per me sarebbe una figata immensa (personalmente avrei diverse aziende anche molto grandi che lo userebbero senza pensarci troppo sopra).

Quello che va detto è che questa funzione generalmente non spetta al firewall ma ad hw dedicato messo tra il firewall e la batteria di server.

Inoltre aggiungo che la sola CPU non è un parametro sufficientemente indicativo per stabilire qual'è il server più scarico.
Spesso, sopratutto nelle reti di backend, quello che fa la differenza oltre alla CPU è la memoria disponibile.

Application center della microsoft (che gestisce affinity), ad esempio, basa i suoi calcoli esclusivamente sull'uso della scheda di rete....e questo, purtroppo, lo rende troppo spesso un banalissimo round-robin con in più gestione dell'affinity perchè quasi mai il collo di bottiglia è la rete.
Top
Profilo Invia messaggio privato
Renzo



Registrato: 27/09/09 02:33
Messaggi: 1

MessaggioInviato: Dom Set 27, 2009 2:55 am    Oggetto: load balancer Rispondi citando

Permettetemi di dissentire, la cosa che la rende rara nel campo delle distro open surce è proprio la gestione del carico di rete.

Ipcop non lo fa, untangle lo fa a pagamento, e gli apparati hardware che lo fanno (con limitazioni fisiche sulle wan gestite) costano dai 300 euro in su.

Mi sono avvicinato a zeroshell solo per questa implementazione, (sono rimasto bloccato nel lavoro per un giorno grazie a telecom, e ho passato due ore per riconfigurare l'accesso con fastweb!!)
(gestisco ordini, disponibilità prodotti 3 volte al giorno via web applications) non ditemi che non è importante, è ciò che, sopratutto nel campo small business, la rende quasi unica.
(In futuro la gestione del failover della wan assumerà la stessa importanza del gruppo di continuità !!)
Spero che lo sviluppo di questa parte venga tenuto in attenta considerazione.

Complimenti a tutti.

Renzo
Top
Profilo Invia messaggio privato
frankuzzo



Registrato: 14/12/16 11:09
Messaggi: 1

MessaggioInviato: Mer Dic 14, 2016 11:23 am    Oggetto: Rispondi citando

Aggiungo una considerazione, spero sia utile. ZS gestisce il load balancing utilizzando semplicemente la funzione nexthop di linux. Nel mio caso ho:

root@netbalancer ~> ip ro sh
default
nexthop via 192.168.0.1 dev ETH00 weight 10
nexthop via 10.32.128.1 dev ETH01 weight 4
[...]


In pratica il default via è già comprensivo di entrambi i percorsi, con il peso specificato (10 connessioni su ETH00 e 4 su ETH01, a regime significa circa il 70% del traffico su ETH00 e il 30% su ETH01). Cercando la funzione nexhop, c'è scritto che:
"On Linux Kernel >= 4.4 Hash-based multipath routing has been introduced, which in many ways is better than the pre 3.6 behaviour (N.b: in kernel pre 3.6 era attivo il caching delle rotte, poi disattivato fino al kernel 4.4). It is flow-based, taking a hash of the source and destination IPs (ports are ignored) to keep the path steady for individual connections."

Quindi le scelte di routing vengono cachate (ZS3.6 viene con un kernel 4.4.13) e non dovresti avere il problema che pacchetti appartenenti alla stessa connessione o alla stessa coppia client-server prendano strade differenti.

F.
Top
Profilo Invia messaggio privato
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> Suggerimento nuove funzionalità Tutti i fusi orari sono GMT + 1 ora
Pagina 1 di 1

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi


Powered by phpBB © 2001, 2005 phpBB Group
phpbb.it