Re: [ml] Load Balncing Predictor

On 8/29/06, Daniele Besana <daniele@xxxxxxxx> wrote:
> On Tue, 2006-08-22 at 17:58 +0200, Marco Ermini wrote:
> > On 8/22/06, Luigi Molinaro <luigi@xxxxxxxxxxxx> wrote:
> > > Ciao,
> > >         sto per mettere in piedi un bilanciatore Hardware (Foundry ServerOn
> > > XL).
> > [...]
> > >         Volevo chiedere alla ml se ha qualche suggerimento/consiglio sulla
> > > sicurezza di questi tipi di apparati, come accorgimenti sulla parte di
> > > switching, tuning delle connessioni, sessioni eccetera.
> > [...]
> >
> > Correggetemi se sbaglio, ma mi pare off topic...
>
> IMHO la sicurezza di apparati come bilanciatori non e' off-topic su una
> mailing list di sicurezza, anzi e' un argomento poco trattato proprio
> perche' il load balancing e' un argomento di nicchia :-)

La sicurezza sì, tutto il resto, no :-)

E francamente, non ci vedo così tanto una "nicchia". Sono router come
tanti altri, gli accorgimenti per mettere in sicurezza un Cisco CSS
sono gli stessi per mettere in sicurezza un Cisco 7500 - IMHO


[...]
> Di solito le soluzioni hw dedicate (prodotti come Nortel Alteon, F5,
> Radware) forniscono una metrica di HASH degli indirizzi IP che
> garantisce una forma naturale di persistenza (finche' l'IP sorgente
> resta quello) mentre per avere forme piu' advanced di persistenza si
> possono usare parametri applicativi come i cookie HTTP o l'SSLID di
> HTTPS, indipendentemente dalla matrica di selezione del server che si
> utilizza.

"Di solito" questi router forniscono diversi algoritmi, e sei libero
di scegliere quale e come usare :-)

Sono d'accordo che sia un campo abbastanza particolare e non molto
diffuso, e sicuramente interessante, ma questa discussione è off topic
qua.

In ogni caso, noi abbiamo avuto una lunga sequela di problemi con i
Cisco CSS, e abbiamo avuto delle patch fatte sviluppare apposta per
noi, dato che la nostra stickiness si basa non sull'IP - nella nostra
architettura abbiamo solo pochi IP sorgente - ma su specifici header
HTTP.

Un consiglio (off topic, ma spero interessante) che posso dare è di
considerare assai poco "naturali" queste "persistenze" e scendere nel
dettaglio, per quanto possibile, per capire come funzionano queste
"macchinette". Consideratele assai poco "black box" perché *danno*
problemi. Soprattutto quando avete un /sacco/ di utenti, il tipo di
algoritmo e di hashing usato è cruciale, perché può significare
facilmente saturare la memoria dell'apparato o renderlo lentissimo.
Siamo stati costretti più di una volta ad usare il software haproxy
per "alleggerire" il carico a queste appliances... prendetelo come un
alatro suggerimento, haproxy è Open Source e funziona bene ;-)


> > E comunque, generalmente il solution architect dell'applicazione
> > dovrebbe già avere in mente qualcosa... e non lasciare ai "meri"
> > deployer scelte del genere ;-)
>
> Nelle realta' che ho visto io il solution architect mi sa che era in
> vacanza... :-) ...visto che alla fine il bilanciatore viene visto come
> apparato di rete con cui gli sviluppatori non vogliono avere a che fare.

Va bene finché non avete tanti utenti... la mancanza di pianificazione
e di progettazione diventa evidente, purtroppo, sempre agli stadi più
avanzati del progetto ;-)


Cordiali saluti
--
Marco Ermini
Dubium sapientiae initium. (Descartes)
root@human # mount -t life -o ro /dev/dna /genetic/research
http://www.markoer.org/ - https://www.linkedin.com/in/marcoermini