High availability cluster con FreeBSD

Marco Ermini markoer a markoer.org
Gio 7 Ott 2004 15:34:46 CEST


<quota chi="Davide">
>> Il problema, come facevo notare, è che dicendo "http" non stai dicendo
>> nulla. Se devi mantenere delle sessioni utente lato server, ad esempio,
>> una semplice "alta affidabilità" non funziona, perché se "switchi" da
>> una
>> macchina all'altra l'utente si perde la sessione.
> Beh, io intendo 'alta affidabilità', non 'totale affidabilità'.
> Se qualche utente si perde una sessione è un problema, ma
> sopportabilissimo rispetto ad un servizio che va giu alle 18.30 di sera
> e risale su alle 8.00 dell'indomani mattina :)

Nel caso di applicativi http non ottieni "un po' più di affidabilità":
molto semplicemente non ti funziona un tubo... Pensa ad un ambiente in cui
hai più di due nodi: non funziona *applicativamente*. Se per un motivo
qualsiasi la sessione utente viene passata da un nodo all'altro perdi la
sessione - se non puoi passare da un nodo all'altro allora non hai alcuna
affidabilità, né alta né bassa :-)

Inoltre, tenere un nodo attivo ed uno off-line pronto a "subentrare" è uno
spreco di risorse. Questo va benissimo per server LDAP o db MySQL
read-only, o in generale se hai macchine che fanno più servizi. Pensa ad
un contesto con dei discreti carichi (per es. un sito web molto
visitato...) e devi installare delle macchine in modo dedicato per
sopperire a questo carico. Non puoi comprare due mega server AMD 64 bit o
Xeon o che so io, e tenerne uno off-line per alta affidabilità: dovrai
trovare una soluzione che bilanci il carico tra tante macchine,
eventualmente switchando via le sessioni dai nodi che vanno down.

IMHO (veramente, è la mia idea) per il mondo web, soluzioni come CARP,
hearthbeat ed ultra monkey sono veramente scarsine.

Quindi io definirei bene i requirements ;-)

Secondo me devi seguire il consiglio validissimo che ti ha dato una
persona che si vede che se ne intende ;-) di chiarirti bene il "cosa" vuoi
realizzare e quindi /dopo/ pensare alla parte tecnica. La parte tecnica è
estremamente affascinante per degli smanettoni come noi ;-) ma rischia di
essere la Sirena per Ulisse: poi ti dimentichi del viaggio che devi fare.
Non bisogna mai lasciare che questa "forza oscura" prenda il sopravvento
(più di tanto ;-)

Prima di smanettare... pensare! ;-)


[...]
> Per ora sto recuperando le macchine e informandomi su cosa usare,
> poi farò un bilancio di cosa usare e cosa no.

Sarebbe utile che dicessi che cosa vuoi bilanciare...


>> Io posso fornire la mia consulenza in materia se può essere
>> interessante,
>> ho una certa esperienza.
> Guarda che ti prendo a priori :)

Nessun problema. I consigli sono gratis ;-)


>> Non scarterei a priori gli strumenti che sono in genere associati al
>> clustering perché, anche se in genere sono associati ad applicativi
>> "number crunching" come sono stati qui chiamati (io preferirei chiamarli
>> "ad alta capacità di calcolo" per opposizione ad "alta affidabilità" o,
>> ancora meglio, "alta disponibilità"), sono comunque utili se devi fare
>> il deploy di una serie di server in parallelo.
> Ci sono situazioni dove tali architetture sono indispensabili e anche il
> bilanciamento di carico è oltremodo affascinante, ma per ora devo
> valutare se e come passare un cluster del tipo in oggetto da gnu/linux
> ad uno freebsd :)

Che tipo di cluster è? cosa clusterizza?

Io credo che se la soluzione attualmente impiegata è stile hearthbeat, in
qualche modo (carp, vrrp, ultra monkey o quello che vuoi) la puoi portare
anche su freebsd. Qui si tratta solo di smanettare ed il mio aiuto non ti
serve :-)

Se la cosa invece implica anche il bilanciamento del carico è molto più
interessante :-)


Ciao.
-- 
Marco Ermini
http://www.markoer.org
Dubium sapientiae initium. (Descartes)
root a human # mount -t life -o ro /dev/dna /genetic/research
<< This message is for the designated recipient only and may contain
privileged or confidential information. If you have received it in
error, please notify the sender immediately and delete the original.
Any other use of the email by you is prohibited. >>



Maggiori informazioni sulla lista esperti