Newsgroup: it.comp.os.linux.sys
Titolo: Http load balancer

Ciao a tutti,
 
 
mi appresto ad installare un load balancer http e l'occhio è caduto su 
HAProxy: qualcuno di voi l'ha usato? Va bene? C'è altro?
 
 
Ciao e grazie,
  Void

 HAProxy: qualcuno di voi l'ha usato? Va bene? C'è altro?
 
Io l'ho usato per un rapido test su macchine virtuali (1GB RAM)
Sinceramente, non mi è sembrato un granchè stabile. Niente-niente che aumenta il carico (fatto con ab ed alcune centinaia di richieste simultanee), a collassare era il bilanciatore invece dei worker.
 
Varnish mi è sembrato più stabile. (ma di molto poi)

 HAProxy: qualcuno di voi l'ha usato? Va bene? C'ï¿œ altro?
 
Assecondo varnish.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 Varnish mi è sembrato più stabile. (ma di molto poi)
 
Grazie ad entrambi, ma Varnish non è più cache che load balancer? Le pagine 
generate sarebbero praticamente tutte dinamiche e con URI sempre diversi.
 
Ho trovato questo confronto:
 
http://blog.exceliance.fr/2012/07/04/haproxy-and-varnish-comparison/
 
 
Non ho mai provato nessuno dei due, ma stando a quanto scritto nel documento 
Varnish fornirebbe solo un "basic load-balancing" (che non so cosa 
significhi) e sarebbe più incentrato sul caching.
 
Cosa ne dite?
 
 
Ciao,
  Void

 significhi) e sarebbe piï¿œ incentrato sul caching.
 
Innanzitutto pensa che in un sito dinamico abbiamo praticamente sempre
oltre al 50% delle risorse statiche (immagini, fogli di stile, ecc.).
Dinamici sono solo i contenuti.
 
Varnish fa comunque bilanciamento a livello applicativo, ed ï¿œ un
balancer a tutti gli effetti, tra l'altro molto efficiente dal momento
che puï¿œ bilanciare in base anche al contenuto della pagina.
Il linguaggio VCL ti consente di bilanciare nel modo che desideri, senza
praticamente limiti.


 praticamente limiti.
 
Ochèi... nel frattempo mi sono imbattuto anche in Pound:
 
http://www.debian-
 
administration.org/article/249/Simple_webserver_load_balancing_with_pound
 
 
Per caso l'avete provato? Se sì come lo avete trovato rispetto agli altri 
due?
 
 
Ciao e rigrazie,
  Void :-)

 due?
 
Mura abbondantemente prima.
Ma se i requisiti non sono estremi, fa il suo.
 

 HAProxy: qualcuno di voi l'ha usato? Va bene? C'è altro?
 
Dipende come e cosa vuoi bilanciare e come al solito le soluzioni possono 
essere varie: tra i parametri ci sono quante macchine hai e se accetti 
single points of failure.
 
Io spesso uso, ad esempio, ipvs ridondato in HA che manda a diverse 
istanze di varnish che mandano al cluster di backend...
 
"one size does not fit all".
 
 

 ipvs ridondato in HA
 
Come?
 
(no, non dirmi corosync ed amici vari che non ci ho mai capito nulla)

 (no, non dirmi corosync ed amici vari che non ci ho mai capito nulla)
 
corosync o heartbeat per spostare l'IP su un nodo funzionante (è semplice 
da fare).
 
mon (con alcuni suoi script di alert autoconfezionati) per aggiornare le 
regole di ipvs.
 


In caso di down dei realserver, dici?
Perchè non ldirectord gestito da heartbeat invece, che in linea di
massima fa tutto lui?!?
 

 da fare).
 
Ah ok, scusa, hai scritto HA, io pensavo in bilanciamento.
ipvs in HA (hot+standby) allora si può fare anche con ucarp e 3 (tre) righe di configurazione.

 HAProxy: qualcuno di voi l'ha usato? Va bene? C'è altro?
 
Io lo uso e mi ci trovo decisamente bene.
E' un reverse proxy puramente bilanciante, come anche pound che utilizzavo in precedenza, no caching.

 Sinceramente, non mi è sembrato un granchè stabile. Niente-niente che aumenta il carico (fatto con ab ed alcune centinaia di richieste simultanee)
 
Io mi farei qualche domanda, fossi in te. :)
 
"A new record of 108000 HTTP requests processed per second was broken, and a new record of 40000 forwarded HTTP requests per second was broken too."
 
http://haproxy.1wt.eu/10g.html
 
 

 Io mi farei qualche domanda, fossi in te. :)
 
tutto può essere ma considerato che si configura in maniera relativamente semplice, ho usato 3 worker ed 1 ha-proxy.
Niente-niente che aumentava il carico, ha-proxy collassava per poi tornare reattivo non appena il carico scendeva.
 
Stesso server con varnish ha retto senza batter ciglio 8-10 volte tanto. (stesso ab eseguito da 8 nodi in conteporanea)
(e con la prima configurazione che ho trovato su google)
 
Poi ammetto che non ho approfondito, era giusto un test.
La prossima volta lo testerò in maniera migliore, per certi versi, è veramente ben fatto (sopratutto per la parte di reportistica che serve a me)

 praticamente limiti.
 
Così su due piedi, però, non mi pare permetta di bilanciare in base alle connessioni attive sui worker, ovvero: se ho 2 nodi ed il primo ha 10 connessioni attive, ulteriori 10 utenti dovrebbero andare sul nodo2 invece che roundrobin o simili.
 
Si potrebbe fare una cosa simile usando il sistema di pooling che in base al carico sul worker (preso magari da server-status di apache), simula un nodo down ma mi pare un po overkill (ha-proxy, ad esempio, fa da solo)

 massima fa tutto lui?!?
 
Solo perchè mi trovo bene così: nulla contro ldirectord che non ho mai 
usato in produzione (ma testerò asap).

 Io lo uso e mi ci trovo decisamente bene.
 
Grazie ancora a tutti quanti! Intanto provo HAProxy e poi darò un'occhiata 
anche a Varnish.
 
 
Ciao,
  Void
 


Ok, ma non necessario in quanto LVS include funzionalità per questo scopo.
In pratica, consente di creare un nodo "hot standby".
Al link seguente prova a cercare "standby" e "backup":
http://red.ht/XpNWaE
 
 

 Meglio un balancer orientato al caching come Varnish o HAProxy?
 
Dipende cosa devi fare, se ti serve una cache oppure no.

 Dipende cosa devi fare, se ti serve una cache oppure no.
 
Attualmente l'esigenza � quella di suddividere il carico di un server un
po appesantito su due macchine e trovare qualcosa per bilanciare.
 
Quindi cosi' a sboccio direi HAProxy, per� � anche vero che il 75% dei
contenuti � comunque statico.
 
Quindi il busillis rimane.
 
A meno che non decida di utilizzare un servizio esterno come una CDN per
cachare i contenuti statici, ma questo ancora non lo so'.
 
-- 
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.

 cachare i contenuti statici, ma questo ancora non lo so'.
 
Ma se metti una cache tu, intanto vedi se la differenza di load �
significativa o no, e almeno hai una idea di quali sarebbero i vantaggi
dati dalla CDN.
Che a quel punto puoi usare per ragioni "altre": minori latenze,
distribuzione grografica, risparmio di banda, protezione da DDoS, ecc.
Perch�, dal punto di vista del carico, la cache locale d� gli stessi
effetti...
 
 

 L'open poster ha portato a conclusione il suo progetto?
 
Quasi, con il solo HAProxy: al momento è ancora in fase di test applicativo, 
ovvero è configurato e bilancia, ma sono state necessarie alcune modifiche 
agli applicativi che non erano pensati per questo (non mi sono occupato di 
questo quindi non saprei darti molti dettagli).
 
Per bilanciare bilancia secondo le ACL impostate, ma non abbiamo ancora 
fatto test di carico per verificare se effettivamente i tempi vengono 
ridotti.
 
 
Ciao,
  Void

 contenuti è comunque statico.
 
Se il 75% è statico, allora cacha senza pietà. Sui worker ti ritroveresti con il 25% di load e basta.
 
Poi dipende da quanti accessi al secondo hai, se, ad esempio, fossero 10/sec già mettendo una cache con ttl impostato a 1, avresti 1/10 di accessi sui worker e praticamente nessun delay quando vengono modificati i file dai clienti.

 L'open poster ha portato a conclusione il suo progetto?
 
Il caching è una cosa.
Il load balancing un'altra. 
Il fatto che un prodotto che fa caching possa anche bilanciare viene 
praticamente gratis ma devi chiederti, di base, cosa ti serve.
 
Per rispondere alla domanda devi analizzare il problema, capirlo ed in base 
ai numeri che ottieni prendere le decisioni opportune.
 
Hai problemi di I/O su disco ?
Hai problemi di I/O su rete ?
Hai problemi di CPU satura ?
Se sono problemi di CPU, chi genera il carico ?
 
Comincia da qui e la risposta viene fuori da sola.
 

 In generale dico, tanto per sapere a cosa vado incontro.
 
Tutta roba microsoft, quindi in alcuni casi è stato necessario sfrondare le 
cose più proprietarie e sostituirle con tecnologie più standard.
 
 
Ciao,
  Void

 servizio di CDN piuttosto che un sistema di cache in casa...
 
 
Dipende da diversi fattori: avere la cache in casa consente un tuning
fine che per alcune realt� � assai utile.
 
Per quel che vale, ho alcune installazioni che usano CDN per proxare un
proxy/cache locale :-P
 

 potrebbe essere nel taglio di banda che ho :-O
 
Potrebbe essere la banda o il server mysql che schioppa e rallenta tutto 
il server web.
 
Le stesse analisi dovresti farle anche su quella macchina, non solo sul 
Webserver.
 
Comunque, giusto per approfondire: il sintomo del problema qual'è ?
 

 Mi metto a monitorare...
 
Eh si, ti conviene.
 
Se fosse la banda, come prima cosa, ti conviene "sminchiettare" con gli 
headers che Apache/Nginx/sarcazzo fornisce (tipo mod_expires per apache) 
e fare in modo che almeno i files statici il client se li cachi per un 
po'.
 
Si ottiene di solito una discreta diminuzione di banda utilizzata.
 
Varnish con wordpress è un PITA e te lo sconsiglio, a meno che tu non 
voglia perderci tanto tempo.
In breve, Varnish è un grandissimo prodotto ma va configurato ed adattato 
al sito e viceversa...

 al sito e viceversa...
 
Un po troppo pignolo per le webapplication attuali.
Secondo me, da mettere davanti a wordpress, meglio nginx.

 Secondo me, da mettere davanti a wordpress, meglio nginx.
 
Non è Varnish il responsabile.
Lui giustamente cerca di seguire le RFC.
 
Il vero problema è che le "webapplication" moderne le scrivono gente che 
l'HTTP non sa nemmeno cosa sia. Basta sapere l'HTML e JQuery.
 
 

 wordpress.
 
Se hai bisogno di far funzionare Varnish su piattaforme "complicate" 
basta che tu mi faccia un fischio... ho un pò di esperienza in merito.

 basta che tu mi faccia un fischio... ho un pò di esperienza in merito.
 
Non è il riuscirci o meno, ma il tempo che bisogna perderci.
Poi non discuto il fatto che abbia ragione Varnish, ma se ci si sta chiedendo
se è necessario un bilanciatore o una cache, significa che la cache non è
poi così fondamentale ed in tal caso, tanto vale non stare ad impazzire.
 
Nel senso: se ti serve principalmente una cache te ne accorgi da vari fattori, non te lo domandi.
 
Non so se rendo l'idea.

 fattori, non te lo domandi.
 
Se ti fai una domanda del genere o non conosci la differenza o non 
conosci il problema che hai.
 
Max

 conosci il problema che hai.
 
Esattamente, quindi presumo che nginx possa andare più che bene.
Si configura con 3 righe e te ne dimentichi.
Varnish è un po overkill in questo caso, imho.

 Varnish è un po overkill in questo caso, imho.
 
Permettimi, ma suggerire nginx per risolvere un problema sconosciuto mi pare 
una cazzata.
 

 una cazzata.
 
Allora lighttpd! (non ho letto il resto del thread)
 
Sennò bzFlag.


Ti sbagli: si chiama marketing.
 

 Ti sbagli: si chiama marketing.
 
hehe! :-D
 

 una cazzata.
 
Non ho suggerito nginx per un problema sconosciuto.
Serviva un bilanciatore, nginx bilancia. *forse* può servire una cache. nginx fa anche da cache.
 
Se lo scopo è bilanciare soltanto, ci sono soluzioni migliori.
Se lo scopo è fare solo da cache, ci sono soluzioni migliori (varnish, ad esempio)
 
Ma almeno per iniziare nginx può fare al caso e si configura in 3 righe.
 

 Ma almeno per iniziare nginx pu� fare al caso e si configura in 3 righe.
 
...e varnish anche.
 
Quindi la differenza tra i due dove sarebbe?
 
Avessi detto "nginx supporta anche HTTPS, varnish no" avresti portato
una ragione oggettiva.[1]
 
Ma detta come l'hai detta suona un po' da boutade senza motivazioni sensate.
 
 
[1] sia chiaro: ci sono certamente diverse altre cose che varnish non fa
e nginx s�[2], e che possono portare a ritenere nginx una soluzione pi�
flessibile di varnish
 
[2] anzi, casomai "il problema" con nginx � trovare qualcosa che *non*
fa... :-D)
 
 

 Quindi la differenza tra i due dove sarebbe?
 
Il tempo necessario ad una corretta configurazione in caso di web application complesse. nginx è indubbiamente molto più plug&play di varnish.

 Il tempo necessario ad una corretta configurazione in caso di web application complesse. nginx ï¿œ indubbiamente molto piï¿œ plug&play di varnish.
 
E' piï¿œ semplice sempre quel che si conosce.
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 E' piï¿œ semplice sempre quel che si conosce.
 
Non in questo caso, sfido a configurare varnish con poche righe quando devi proxare wordpress, joomla e drupal, tutto in una volta.
 
Non che sia impossibile, ma di certo richiede più tempo rispetto nginx e se lo scopo è verificare se un proxy/bilanciatore possa ridurre il carico, io il tentativo lo farei prima con nginx, senza perdere troppo tempo, poi in produzione metto varnish configurato a modo.

 fa... :-D)
 
Vero, piu` che altro il problema in alcuni casi non e` cosa fa, ma come lo 
fa. Per dire, ora non ne ricordo dettagliatamente il motivo, ma mi sono 
ritrovato a sostituire nginx con lighttpd perche` quest'ultimo mi veniva 
piu` comodo nel gestire i CGI
 
Enrico

 devi proxare wordpress, joomla e drupal, tutto in una volta.
 
Lo fai in 5 minuti se conosci varnish.
Se poi vuoi robe esotiche ci metti qualche ora, esattamente come con nginx.


 Come bilanciatore allora perchï¿½ non HAProxy?
 
Perchè HAProxy non mi pare faccia da cache. Il mio concetto era prendere due piccioni con una fava. Poi, nemmeno io userei nginx in questo caso [1], era solo per fare un rapido test e verificare di quanto il worker viene alleggerito senza stare ad impazzire in configurazioni varie.
 
[1] o meglio, forse userei nginx+varnish, usando nginx come terminatore SSL che proxa verso varnish.