Newsgroup: it.comp.os.linux.sys
Titolo: Bilanciatore L7 in direct routing

Temo che la risposta sia negativa, ma c'è modo di bilanciare, in direct routing simile a LVS (ovvero con le risposte che vengono inviate direttamente dai worker al client senza transitare dal bilanciatore) più virtual host di apache/nginx/amicivari?
 
Esempio:
 
www.dominio1.it
 bilanciato tra server1,server2,serve3
www.dominiot2.com
 bilanciato tra server4,server5,server6
 
Vorrei evitare di dedicare un IP a ciascun dominio.
 
Senza DR basterebbe un reverse proxy ma a me le cose semplici non piacciono.

 
 
Proviamo con la maieutica, che m'� sempre piaciuta tantissimo:
 
1) SYN
2) SYN+ACK
3) ACK
4) HTTP REQUEST
5) HTTP REPLY
 
Il vhost lo conosci al punto 4.
Quindi, al punto 1, il SYN a chi lo mandi?

 Quindi, al punto 1, il SYN a chi lo mandi?
 
Per questo ho chiesto sul gruppo :)
Immaginavo non ci fosse soluzione.
 
Quindi: o mi faccio un proxy tradizionale, ed il traffico passa tutto dai bilanciatori, oppure assegno un IP a ciascun virtualhost, tutti gli IP stanno sui bilanciatori e con LVS bilancio in DR sui worker. Spreco IP ma non ho il traffico di risposta.

 Spreco IP ma non ho il traffico di risposta.
 
Puoi anche bilanciare dei proxy
O proxare dei bilanciatori :^)

 O proxare dei bilanciatori :^)
 
Vabbè che son masochista, ma non fino a questo punto.
Non posso bilanciare dei proxy, sposterebbe il problema dal bilanciatore al proxy, che per di più nella soluzione solo-bilanciatore non sarebbe nemmeno previsto quindi si complicherebbe solo la struttura aggiungendo inutili livelli.
 
Non posso nemmeno proxare dei bilanciatori:
 
la richiesta arriva sul proxy con ip 1.2.3.4, il proxy a questo punto riceve la richiesta HTTP per intero e la gira al bilanciatore, il quale contatta il worker etc etc.
A questo punto il worker deve rispondere, giocoforza, al bilanciatore in modo da inviare la risposta al proxy sorgente, il che esula da un DR altrimenti in DR il working risponderebbe al client, senza che quest'ultimo abbia però la connessione aperta (visto che l'ha fatta verso il proxy)
 

 Spreco IP ma non ho il traffico di risposta.
 
Consiglio scontato: IPv6 :P
 
Enrico

 connessione aperta (visto che l'ha fatta verso il proxy)
 
Una domanda, ch� forse stai dando per scontato che noi gi� lo si
sappia/intuisca: quale � il problema che vuoi risolvere usando DR al
posto di un proxy?
 
Non le prestazioni, mi pare di intuire...

 soluzione solo-bilanciatore 
 
C'è un buon motivo per usare LVS invece di reverse proxy, trattandosi di http?
Non è polemica, eh, chiedo solo per capire meglio lo scenario. :)

 Consiglio scontato: IPv6 :P
 
Se il cliente fosse solo IPv4, come la stragrande maggioranza delle ADSL attuali non arriverebbe al sito.

 Non le prestazioni, mi pare di intuire...
 
Ma in realtà è molto semplice: non voglio che il grosso del traffico (ovvere le risposte da parte del server del cliente) transitino nei miei bilanciatori.
questo perchè non voglio dover dimensionare i bilanciatori in base al traffico dei clienti. Una piccola VPS che bilancia in DR non avrebbe problemi a gestire milioni di richieste. La stessa VPS invece non riuscirebbe a gestire altrettante richieste compreso la risposta di ritorno.
 
Detto ciò:
 
ho una ventina di domini (di clienti diversi) che devono essere bilanciati su 2 o 2-3 macchine ciascuno (2-3 VPS per dominio) sia per ridondanza, sia per performance.
 
Pensavo a far puntare tutti i domini ad un VIP dei miei bilanciatori. A livello bilanciatore, come bilancio dominio1 tra server1,server2,server3 e dominio2 tra server4,5,6 ? E' quello che cerco di risolvere, SENZA mettermi in mezzo al traffico di risposta.
 
L'unica soluzione è dedicare un VIP a ciascun dominio e bilanciare in base ad esso, questa soluzione però è poco scalabile e spreca un totale di IP.
 
Se IPv6 fosse diffuso non ci sarebbe problema, ma ad oggi non si può settare un dominio solo in v6.

 Non è polemica, eh, chiedo solo per capire meglio lo scenario. :)
 
Come scritto a Skull, vorrei evitare di ritrovarmi in mezzo al traffico di risposta, come avverrebbe in caso proxy. Questo perchè se il cliente facesse 1 milione di visite, i miei proxy dovrebbero essere dimensionati per supportare 1 milione di visite.
 
LVS in DR no. Il DR occupa pochissime risorse ed il grosso del traffico, quello che mi stenderebbe le macchine, ovvero le risposte, non transiterebbero da me ma tra worker e client
 
Altro fattore, ma forse facilmente risolvibile: con LVS riesco a generare con poche righe di script delle statistiche di uso di ciascun worker e di ciascun servizio, con un proxy forse no. E riesco (fondamentale) a dare priorità ai worker, ad esempio inserendo nuovi nodi a prorità superiore facendo aumenticamente isolare i nodi vecchi prima di rimuoverli.
 
insomma, è più flessibile e facilmente gestibile.

 compreso la risposta di ritorno.
 
 
In pratica, tu vorresti la botte piena e la moglie ubriaca... :-P
 
 
Due hint, poi la chiudo:
 
1) non sottovalutare le performance che puoi cavare da un proxy ben
scritto (varnish se ti puoi permettere di fare caching e https non �
indispensabile, altrimenti nginx): un proxy http � tutto
store-n-forward, liddove il limite prestazionale di un sito web sono CPU
e accesso al disco. Avr� bisogno di pi� RAM di LVS, questo s�, ma nulla
che oggid� sia considerabile come "eccessivamente oneroso".
 
2) se vuoi poter scalare a numeri assurdi, bilanciare in network un pool
di reverse proxy ti pu� portare a diverse decine di Gb di throughput...
 
 
 
-- 
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/
 

 di reverse proxy ti può portare a diverse decine di Gb di throughput...
 
A sto punto, a che mi servono i proxy?
LVS in NAT non basta? Il proxy implica il transito del traffico su se stesso. LVS in NAT idem, ma almeno ho una infrastruttura meno complessa senza bilanciare dei proxy che a loro volta proxano su un pool di worker.

 proxy che a loro volta proxano su un pool di worker.
 
Un proxy tratta l'informazione a livello applicativo, e pertanto pu�
decidere a chi deve mandare cosa in funzione di cosa gli viene richiesto.
LVS, indipendentemente dal setup, no; conosce solo porte e IP.
 
Ergo il senso di un setup di quel genere �: bilancio gli utenti finali
attraverso proxy per la massima flessibilit� di
configurazione/filtraggio/caching/sarcazzocosa e per far scalare i proxy
uso un network balancer, che ha un footprint molto pi� snello.
 
 
Incidentalmente (ma non casualmente) � in pratica anche il setup che si
usa per proteggere un sito da DDoS (unito a un altro po' di contromisure):
http://goo.gl/x7ohK
 


 LVS, indipendentemente dal setup, no; conosce solo porte e IP.
 
Non devo fare strane configurazioni a livello applicativo, devo solo poter bilanciare dei server. Bilanciare in base agli IP o in base ad altro non mi cambia, basta che la richiesta venga bilanciata. I punti fondamentali per me sono quelli indicati sopra. Con LVS si fanno, con un proxy sinceramente non so.

 Non devo fare strane configurazioni a livello applicativo, devo solo poter bilanciare dei server.
 
Chiaro.
E se vuoi farlo sulla base del vhost richiesto *devi* farlo a livello
applicativo. Fine del thread.


ovvero con le risposte che vengono inviate direttamente dai worker al client senza transitare dal bilanciatore) pi� virtual host di apache/nginx/amicivari?
 
Se sei disposto a spendere soldi, la risposta � si.
Vari appliance commerciali hanno la possibilit� di fare bilanciamento L7 
ed http(s) � ovviamente il protocollo che meglio digeriscono.
 


Ma *non* lo fanno "con le risposte che vengono inviate direttamente dai
worker al client senza transitare dal bilanciatore"...



 
E questo chi lo dice scusa?
Ad esempio, gli F5 chiamano questa funzionalit� DSR (direct server return)


Ah, � ovvio (spero) che se fai una configurazione del genere non puoi 
gestire l'offloading SSL sul bilanciatore.


Non credo che tu la possa usare con inspect a livello applicativo. Ma
Ammetto che li conosco praticamente niente, ma se lo fanno, voglio
sapere come fanno a girare attorno al problema di cui sopra, perch� a me
di soluzioni non ne vengono in mente...



 
Il concetto di VIP (accoppiata ip:porta) � svincolato dal concetto di 
POOL (uno o pi� insiemi, non abbligatoriamente disgiunti, di 
real-servers); il collante � (o meglio pu� essere, valgono comunque 
tutti i metodi standard) una IRULE, ossia una regola custom di analisi 
del protocollo applicativo. All'interno della IRULE posso dirgli che se 
la richiesta � per un determinato url il pool � POOL1, se � per un altro 
url il pool � POOL2 ecc ecc...
 
Quello che non mi ricordo, ed ora non posso verificarlo, � se questa 
cosa funzioni anche con SSL; ossia se il bilanciatore, anche in modalit� 
DSR, sia disposto a decriptare il pacchetto, valutare la IRULE, e poi 
mandarlo (ovviamente criptato) al real-server.

 di soluzioni non ne vengono in mente...
 
Già, non vengono in mente soluzioni nemmeno a me.

 mandarlo (ovviamente criptato) al real-server.
 
 
Non � quello il punto che contestavo.
 
Il punto � l'impossibilit� di distribuire le richieste tra i worker a
fronte del contenuto di un *header*, quando la sessione non di ritorno
non transita attraverso il bilanciatore.
 
Come detto in testa al thread:
 
�
1) SYN
2) SYN+ACK
3) ACK
4) HTTP REQUEST
5) HTTP REPLY
 
Il vhost lo conosci al punto 4.
Quindi, al punto 1, il SYN a chi lo mandi?
�
 
 
L'unica soluzione � che il bilanciatore termini *lui* la sessione TCP,
in modo da arrivare fino alla fase 4 e decidere il real-server designato
solo a quel punto, per poi instaurare una sessione TCP con il realserver
e rigirargli la richiesta[1].
 
Ma affinch� il traffico di ritorno vada direttamente al client che ha
fatto la richiesta e non transiti attraverso il bilanciatore,
quest'ultimo deve necessariamente instaurare una sessione TCP con il
realserver spoofando l'IP sorgente del client originario. Cosa
fattibile, ma poich� la sessione TCP cos� instaurata avr� sequence e ack
number (tralasciando il resto delle possibili opzioni TCP) diversi da
quella tra il client e il bilanciatore, il bilanciatore *deve* essere
lungo la linea del traffico di ritorno per operare le riscritture del
caso, o il tutto semplicemente non funzionerebbe[2].
 
 
 
 
[1] in altre parole, funge da proxy
 
[2] o, per dirla breve: ringraziando il cielo il blind spoofing con TCP
non funziona pi� da un pezzo


 url il pool è POOL2 ecc ecc...
 
Non mi capacito di come possa funzionare.
Io setto, a livello DNS, 
pippo.it
 per farlo arrivare su un VIP del bilanciatore.
Faccio questo per X domini, quindi sul bilanciatore arriveranno X richieste di domini diversi.
 
Ora, l'unico modo per differenziare la richiesta in base al dominio è mettersi in ascolto sulla 80/tcp e far iniziare il dialogo da parte del client, fino a ricevere l'header Host della richiesta HTTP. Una volta che il client ha inviato tutti i suoi header, si siede ed aspetta, nella stessa connessione, una risposta.
 
Supponiamo di girare la richiesta ad un worker (e qui già si pone la domanda: come giri una richiesta già connessa senza terminarla?) e di voler far rispondere direttamente a lui. La richiesta del worker non potrebbe mai tornare come risposta nella sessione aperta dal client, visto che il client è in attesa da altre parti, quindi ciò che voglio fare io non è possibile tecnicamente e non vedo come il prodotto da te indicato possa farlo.


 
E infatti hai assolutamente ragione!!!
Effettivamente a logica non c'� modo di fare bilanciamento L7 usando il 
direct-routing...sorry per l'inesattezza.

 
www.dominiot2.com
 bilanciato tra server4,server5,server6
 
con Perl bastano <120 righe di codice \ò/
http://goo.gl/PuD3c
 
 
rc.name
 
-----BEGIN PGP SIGNATURE-----
Version: null
 
iD8DBQFQQJ0EWVOoL214ZeERAhUKAJkBDwv3lUXGXjZfzgMsezenxw7BbwCgnryK
aloP2hzew+XBSrA+nFMX+Qo=
=vZ8q
-----END PGP SIGNATURE-----
 

 
http://goo.gl/PuD3c
 
 
Puoi spiegarne il funzionamento? Non vedo in che modo possa funzionare.
 
Bada bene, qui si parla di bilanciare un virtualhost, quindi il bilanciatore deve terminare la sessione HTTP, non bilanciare un IP (che è molto più facile)

 rimosso in automatico dal proxy senza il mio intervento e che sia possibile bilanciare, proprio come fa LVS, in modo tale che il nodo con meno richieste sia quello prioritario.
 
Sembra che NGINX consenta di fare questa cosa tramite il modulo upstream.
Vuole un peso e non bilancia in automatico, cosa per me preferibile, ma il problema è un altro: come diavolo monitoro i worker usando nginx?
Ho la necessità di sapere, in tempo reale, quali worker sono in uso e quante richieste stan gestendo ciascuno di essi. Ovviamente non posso connettermi ai singoli worker.
 
C'è la possibilità di usare una sorta di url '/server-status' ?

 C'è la possibilità di usare una sorta di url '/server-status' ?
 
Munin, Monit, il monitor interno (location /monitor {upstream_status on;})
 
Enrico

 Munin, Monit, il monitor interno (location /monitor {upstream_status on;})
 
Ok, ho detto una mezza cazzata, il monitor interno come te l'ho proposto era 
solo un esempio ad una richiesta simile trovata su internet. In risposta a 
quella richiesta, pero`, vengono citati il modulo 
ngx_http_stub_status_module e questo link: 
http://github.com/cep21/healthcheck_nginx_upstreams
 . Prova a dargli 
un'occhiata, soprattutto al modulo che sembrerebbe quello piu` adatto alla 
tua richiesta
 
Enrico

 tua richiesta
 
healthcheck_nginx_upstreams proprio no, io non devo verificare se il worker è attivo o meno, ma verificare quante richieste sta servendo in modo da capire se è saturo oppure no.
 
ngx_http_stub_status_module mi pare dia statistiche non sul singolo worker ma sul bilanciatore.

 ma sul bilanciatore.
 
Se per bilanciatore intendi il path che nginx redireziona, allora direi che 
funziona in quel modo. In questo caso pero` non saprei piu` che dirti, 
quello che trovo e` molto generico e scende poco nel dettaglio. A questo 
punto ti rinnovo il consiglio di provare ad usare Monit o Munin oppure di 
provare a vedere se Lighttpd oltre a fare quello che ti serve implementa un 
sistema di statistiche migliore (qua trovi delle informazioni sul modulo in 
questione: 
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModStatus
 
). In ogni caso, tieni presente che tutti e due i web server esportano le 
statistiche in RRD, che potrebbero essere piu` dettagliate rispetto a quello 
che ti mostrano i vari mod_stats in questione
 
Enrico
P.S. e` interessante notare che un paio di ricerche hanno portato anche a 
risultati come questo: 
http://serverfault.com/questions/404564/what-
 
webserver-to-use-for-a-hentai-website-nginx-or-apache?rq=1

 webserver-to-use-for-a-hentai-website-nginx-or-apache?rq=1
 
Di questo non ne vedo il nesso. Mi sfugge qualcosa?
Il webserver dei worker *deve* essere apache, il software che caricano i clienti non lo realizzo io e non posso forzarli a cambiare tutte le regole di rewrite e/o rimuovere i file .htaccess adattandoli ad nginx.
 
Il frontend può essere qualunque cosa, purchè mi permetta di avere statistiche in realtime sull'utilizzo dei worker.

 
 
è già stata scartata la soluzione haproxy? (eventualmente in accoppiata a TPROXY)
 
rimuove in automatico i nodi morti, ti permette di bilanciare in base al carico di lavoro attuale (che lui conosce), e attraverso un socket di controllo ti permette di fare parecchie cose.
 
l'ho usato in produzione su una serie di server, e per poter bilanciare anche in base al carico CPU/query dei server (e non solo al numero di richieste) ho scritto questo: 
https://github.com/ssasso/lbwwd
 
praticamente polla i server e in base al risultato cambia al volo la priorità del server nel bilanciatore.
 
ciao,
stefano

 praticamente polla i server e in base al risultato cambia al volo la priorità del server nel bilanciatore.
 
 
moooooooooolto interessante

 moooooooooolto interessante
 
haproxy è *la* risposta.
fa esattamente quello che serve a me e per di più ha delle statistiche leggibile in formato CSV: 
http://127.0.0.1/haproxy?stats;csv
 

 Di questo non ne vedo il nesso. Mi sfugge qualcosa?
 
Nulla, piu` che altro mi aveva fatto incuriosire la richiesta di mettere su 
un'infrastruttura web per un sito hentai. Per quanto riguarda la tua 
richiesta, l'unica che mi viene in mente e` loggare tutto il traffico di 
nginx su redis e poi estrarre i dati da li. Ma rimane un sistema non 
realtime, anche se puoi effettuare un polling basso
 
Enrico

 realtime, anche se puoi effettuare un polling basso
 
Ma con haproxy dovrei aver risolto. fa tutto in realtime ed esporta le statistiche in csv.

 Ma con haproxy dovrei aver risolto. fa tutto in realtime ed esporta le statistiche in csv.
 
Per me haproxy è un mostro. Le puoi vedere anche in html direttamente, quelle stats, eh.

 Le puoi vedere anche in html direttamente, quelle stats, eh.
 
Impossibili da parsare. Personalmente non mi interessa leggere le statistiche, lo deve fare un mio software, quindi meglio un CSV. Se io non le leggo, tanto meglio, ho altro da fare. :)
 

 In senso positivo 
 
Positivo.
 

 Positivo.
 
L'altro giorno ho fatto un rapido test con una istanza di haproxy e dietro un singolo worker. Usando siege e 200 connessioni contemporanee, lui parte a raffica, le richieste vanno a buon fine, poi collassa improvvisamente.
Ciò che fa strano è che collassa, oltre ad apache del backend, haproxy rendendo impossibile anche l'accesso alle statistiche.
 
Resta collassato 15 secondi poi si riprende.
Ora, premesso che 200 connessioni contemporanee ad una pagina contenente un phpinfo, su una VPS da 512M di ram e senza alacuna ottimizzazione sono impossibili da gestire, ciò che non capiso è come mai mi debba collassare il bilanciatore.

 
 
ulimit?


 ulimit?
 
sai che non ci ho guardato minimamente? però, se fosse un problema del genere, nei log dovrei avere una mezza corrispondenza...