Newsgroup: it.comp.os.linux.sys
Titolo: Bilanciamento del carico apache

Salve a tutti.
Per scopi di test ho installato e configurato 4 macchine per fare dei test di bilanciamento del carico.
Leggendo qua e la ho trovato e installato una soluzione funzionante ( 2 macchine a fare da load balancer in HA e due server apache che gestiscono le richieste ). Per mettere in piedi tutto ho utilizzato questa guida 
http://logicsupport.com/blog/?p=481
, solo che da quello che vedo il progetto ultramonkey è un pò datato. Ora visto che ili tutto al momento funziona potrebbe anche restare così, ma vorrei sapere se avete qualche cosa da consigliare per installare qualche cosa di più mantenuto o recente. 
Grazie a tutti

 per installare qualche cosa di più mantenuto o recente.
Personalmente, uso reverse proxy pound in HA con heartbeat.

Grazie dell'info. Ci dò un occhiata :)


Ultramonkey è solamente un aggregato (organizzato) di tool, sostanzialmente.
ldirectord, lvs, heartbeat etc sono i "veri tool" che vai ad utilizzare,
e sono tutti progetti mantenuti e la cui implementazione viene
periodicamente aggiornata, quindi -IMHO- vai tranquillo...
(se proprio vogliamo dirla tutta il bilanciamento con LVS e ldirectord
su IPv6 fa ancora un po' pena, ma non è necessariamente un problema per
chiunque, e se devi bilanciare solo HTTP tantovale usare per il
bilanciamento un reverse-proxy, che ti dà anche ulteriori vantaggi, come
il caching...)
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

Grazie mille skull della risposta.
Sono effettivamente tentato dalla soluzione di usare solo un reverse-proxy appunto per la questione caching... ;) 



Si ma leggiti bene la documentazione.
L'applicazione WEB deve essere scritta o adattata, se vuoi che il caching 
funzioni bene.


+N!


 Sono effettivamente tentato dalla soluzione di usare solo un reverse-proxy appunto per la questione caching... ;) 
Nel caso ti intressi il caching, non usare pound, allora.

ciao,
come load balancer / caching ho trovato ma purtroppo non ancora provato 
questo
https://www.varnish-cache.org/
mi sembra molto interessante, di dovrebbe poter trovare il modo di 
usare la cache anche con applicazioni scritte non molto bene da questo 
punto di vista.
spero di poterlo sperimentare al piu' presto
-- 
Tinto

 di vista.
Lo ho in produzione per alcuni siti da tempo, assolutamente consigliato.
Ma il punto di CtRiX rimane assolutamente valido...


 Ma il punto di CtRiX rimane assolutamente valido...
lo so bene purtroppo... ben pochi "webmaster" si preoccupano di mettere 
gli header di controllo della cache nei siti che fanno e fra quei pochi 
molti si limitano a fare tutto il possibile perche' niente sia 
recuperato dalla cache.
Alla fine mi e' sempre toccato togliere qualsiasi caching sul reverse 
proxy che avevo tempo fa. Pero' varnish dovrebbe prevedere dei comandi 
che brutalmente svuotano tutta la cache, e metterli in cron ogni 5 
minuti penso/spero che potrebbe fare al caso mio. Rudimentale ma sempre 
meno che non "cachare" mai nulla, credo.
-- 
Tinto

 Lo ho in produzione per alcuni siti da tempo, assolutamente consigliato.
scusa se approfitto di te... che tipo di topologia usi con Varnish?
Mi spiego meglio (provo):
|router ISP| --> |Box con firewall (iptables?)| --> |Box con Varnish| 
--> |webservers|
oppure
|router ISP| --> |Box con firewall (iptables?) + Varnish| --> 
|webservers|
o ancora
|router ISP| --> |Box con Varnish| --> |webservers|
-- 
Tinto


La prima, l'ultima e anche
|router ISP| --> |IPVS+heartbeat+ldirectord| --> N * |Varnish+webserver|
:-P
La seconda no solo perchè se devo far fare da firewall alla macchina
varnish non ha molto senso usarci iptables: dato che fungendo da proxy e
non da router non veicola traffico, è di fatto un bastion-host di per sè
stesso...
(il discorso ovviamente cambia se ci sono altri servizi oltre a
http/https da veicolare, ma non ne ho)


 stesso...
gia... e' quel che penso anche io e, quando posso, cerco di fare le 
cose piu' semplici possibili.
A proposito, se ho capito bene dalla documentazione con varnish riesco 
a far lavorare piu' siti con un solo IP pubblico vero?
-- 
Tinto


volendo sì, senza problemi.


 volendo sě, senza problemi.
Cosa che comunque si fa anche con apache liscio.
(meglio precisare...)
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

Grazie della risposta :)
Per la web App non penso ci siano problemi a scriverla, visto che devo scriverla io 

 (meglio precisare...)
si' conosco i virtual host di apache ;)
ma se usi un bilanciatore a livello 3/4 (come LVS, pulse/piranha) e hai 
piu' di un pool di webserver (es alcuni con apache, altri con 
tomcat....) sei costretto a usare piu' IP per mandare le richieste sul 
pool opportuno.
Varnish operando a livello 7 dovrebbe superare questo limite.
-- 
Tinto



No, il mio consiglio era "leggi la documentazione".
E non credo che tu lo abbia fatto.
Il grosso problema di varnish (che non è un problema suo, intendiamoci, è 
dei programmatori) è che di default NON FA CACHE delle richieste che 
contengono dei cookie.
Questo perchè un cookie di solito annuncia la presenza di una sessione ed 
una sessione implica una personalizzazione dei contenuti o del 
tracciamento, lato server, su base utente.
Cosa vuol dire ?
Che se tu sei il tipico webmaster che programma in PHP (e non c'è niente 
di male) che fa un session_start() all'inizio di ogni script, varnish ti 
darà parecchi grattacapi.
Per carità, non c'è niente di male a fare session_start() sempre: va 
benissimo ma è un approccio che non scala.
Però ogni volta che fai un session_start() o che setti un cookie, Varnish 
passerà la richiesta in maniera trasparente, come se non ci fosse.
Ribadisco quindi il concetto iniziale:
- leggiti la documentazione di varnish e programma la parte web con 
accortezza.
Sempre per la cronaca, perchè a me piace fare la punta al pene ed 
ultimamente il mio livello polemico è alle stelle (sarà il caldo): Varnish 
non si cacha solo le pagine HTML ma può cachare anche le immagini, i 
fogli di stile, gli script e quant'altro gli passi attraverso.
Il che implica che svuotare la cache ogni 5 minuti non solo è indice di 
una progettazione alla cazzo dell'applicazione (cosa usi a fare una cache 
se la svuoti TUTTA, anche per gli elementi immutabili).
E' anche indice di non aver capito una mazza sull'utilizzo di varnish.
Sei sempre in tempo a non cadere nell'errore quindi sgombra la tua mente 
da queste idee balzane, giovane padawan.
Max

 si' conosco i virtual host di apache ;)
Non avevo dubbi, ma cerco sempre di pensare 'ai posteri'.
Leggendo il thread sembrava che varnish fosse necessario
all'uopo.


 da queste idee balzane, giovane padawan.
giovane... magari! ;)
-- 
Tinto

 polemica mondiale a tutti i livelli aziendali.
Per questo ci sono gli headers fatti apposta.
Per le pagine dinamiche si fa in modo che durino poco. Questa è la prassi.
Per le risorse statiche si fa in modo che durino tanto. Tendenzialmente 
almeno un mese. Se cambi sul server un foglio di stile Valgrind se ne 
accorge.
Il tutto, ovviamente, si può far convivere facilmente con le esigenze 
aziendali e se proprio chi deve aspettare non vuole farlo, le modalità 
per rendere i dati accessibili sono Nmila. 
A cominciare da filtri sull'IP sorgente a nomi host diversi, alla 
presenza di cookie etccc...
Ma ranzare la cache ogni 5 minuti è una porcata e cercare di 
giustificarlo con esigenze aziendali vuol dire cominciare bene l'opera, 
ponendo il deretano davanti alla pedata.

 almeno un mese. Se cambi sul server un foglio di stile Valgrind se ne
ops ... s/Valgrind/Varnish/gis

 Ma ranzare la cache ogni 5 minuti è una porcata 
domanda secca: e' una porcata piu' grande che eliminare del tutto ogni 
traccia di cache? :)
-- 
Tinto

 traccia di cache? :)
Se le pagine sono HTML statico abbi pazienza ma:
1) non hai bisogno di cache perchè ogni webserver semi-moderno gestisce 
carichi piuttosto considerevoli di roba statica
2) abbi pazienza ma a meno che tu non abbia istruito apache all'uopo, se 
sono puri file HTML non hai bisogno di cache che ci pensa apache a dirlo 
al client.
Trai tu le tue conclusioni.
P.S.: usare wireshark per leggere gli headers delle richieste e delle 
risposte è come sparare ad una mosca con un cannone. Hint: firebug.

 risposte è come sparare ad una mosca con un cannone. Hint: firebug.
installato, grazie!
-- 
Tinto