Newsgroup: it.comp.os.linux.sys
Titolo: Bilanciatore in HA

Supponiamo di avere due macchine geograficamente distanti
e su subnet differenti fuori dal mio controllo.
Esempio:
10.0.0.1
172.16.0.2
Ho la necessitï¿œ di fare un bilanciatore in HA usando
due piccole VPS, una per ciascun IP. (mi va bene anche
un hot-standby)
Non ci sarebbe alcun problema a farlo se entrambe le
macchine fossero parte della stessa subnet, basterebbe
usare heartbeat e ruotare l'ip virtuale sulle 2 macchine
in base alla VPS attiva in un dato momento.
Avendo subnet differenti, non ho IP in comune, quindi niente
IP virtuale che gira tra i nodi.
Non posso nemmeno usare un roundrobin DNS che punti verso entrambi
i bilanciatori, perchï¿œ cosï¿œ facendo, se uno dei due nodi dovesse
morire, il 50% di richieste fallirebbe.
Dietro i bilanciatori ci sono altre VPS con una VPN tra di loro quindi
gli ip son tutti locali e tutte le VPS raggiungono direttamente quelle
vicine.
Il problema ï¿œ il frontend, come diavolo lo metto in HA ? O meglio, come
gestisco il takeover o il guasto di un nodo facendo si che le richieste
vengano dirottate sul bilanciatore attivo ?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 172.16.0.2
[...]
Francamente non so se ho capito qualcosa o meno, sia perchï¿œ trovo la tua
descrizione parecchio confusa, sia perchï¿œ ï¿œ priva di alcuni dettagli
importanti sul meccanismo che usi per il bilanciamento che sono
indispensabili per pianificare quanto chiedi.
Comunque...
Di norma, liddove c'ï¿œ la necessitï¿œ di eseguire failover su scala
geografica uso anycast su IGP: l'IP del servizio lo piazzo su una /32
attestata in loopback e lo annuncio via OSPF (o altro IGP) da entrambi i
nodi, avendo ovviamente l'accortezza di usare per il nodo di fallback
una metrica molto alta. Se il nodo attivo "muore", cessa di annunciare e
la rotta per l'IP del servizio va verso il fallback.
Ovviamente, perï¿œ, questo richiede di avere il controllo
dell'infrastruttura di routing e richiede che i due sistemi appartengano
allo stesso AS.
Nel caso ciï¿œ non sia vero, puoi comunque utilizzare approcci simili con
qualche complicazione all'intorno, come l'uso di tunnel in cui veicolare
il traffico di bilanciamento e gli annunci IGP.
Oppure ricorri a meccanismi di failover basati sul DNS (se si riscontra
che il "master" ï¿œ giï¿œ si genera un DNS update e si sposta il servizio
sul fallback).
-- 
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/

 sul fallback).
Non posso aggiornare i dns, sarebbe un bel casino, inoltre ci son di
mezzo le varie cache e dovrei lavorare con TTL bassissimi. Ed anche con
TTL bassissimi, avrei un fallback nell'ordine di minuti. E' comunque 
troppo. In tutti questi minuti, il nodo morto continuerebbe ad essere
presente in roundrobin DNS pertanto il 50% delle richieste sarebbero
comunque inviate li, ed è proprio il problema che voglio evitare.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 comunque inviate li, ed è proprio il problema che voglio evitare.
In tal caso ti direi che stai partendo dal lato sbagliato del problema:
prima si stabiliscono i requisiti, poi si stabilisce l'architettura per
soddisfarli.
Fare le cose al contrario significa -nella migliore delle ipotesi-
ottenere delle porcherie.


 ottenere delle porcherie.
I requisiti già li ho: rendere HA su scala geografica un server NFS.
I dati vengono già replicati, non è quello il problema. Il problema
è la ridondanza non potendo agire sul routing (sarebbe troppo semplice
in caso contrario, non mi divertirei... )


 i 2 IP separati?
Buona parte dei dati si, ogni pochi secondi.
Ma sto sperimentando unison e forse proverò un qualche filesystem
distribuito. I dati da sincronizzare sono davvero pochi.
Un altra parte dei dati viene sincronizzata a livello applicativo (chi
scrive, scrive due volte, su ambo i server, ad esempio gli script PHP)


 I requisiti giï¿œ li ho: rendere HA su scala geografica un server NFS.
Allora GlusterFS al posto di NFS potrebbe essere una soluzione, per
dirne una...


 dirne una...
E' uno dei test. Ma GlusterFS mi permette di replicare i dati,
io come punto ad una macchina piuttosto che ad un altra?
E' proprio quello il problema.


 io come punto ad una macchina piuttosto che ad un altra?
Se utilizzi il client di gluster per eseguire il mount della share
(attraverso fuse) in realtï¿œ il mount di una share replicata porta
all'accesso contemporaneo a tutti i server che esportano tale share.
Nel caso in cui uno dei due "vada giï¿œ", tutto rimane fruibile dal server
sopravvissuto.
Se segui questa strada, occhio a studiare molto bene sia Gluster che lo
storico relativo agli ultimi mesi della ML relativa, perchï¿œ ci sono
svariate pitfall che ï¿œ opportuno evitare in fase di pianificazione (a
partire dalla versione di Gluster da installare).


 partire dalla versione di Gluster da installare).
Ok, vado a vedere.
La versione di squeeze non va bene?
Comunque sia, ï¿œ affidabile come prodotto o ï¿œ un esperimento accademico?
Si puï¿œ usare in produzione su link geografici (non xDSL per intenderci)?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la


 partire dalla versione di Gluster da installare).
Umh, dando uno sguardo ai vari tutorial, sembra che sia la
configurazione dei client e replicare i dati. Ovvero il client si
collega a tutti i server e li "governa" replicando i dati qua e la.
Mi potrebbe stare anche bene, ma sembra una porcata. In caso di più
client, se uno avesse una configurazione non perfettamente identica
a tutti gli altri, ci si ritroverebbe con un cluster che funziona in
maniera differente in base a chi si collega.
Verosimilmente il numero di client è superiore a quello dei server,
pertanto è più facile cannare la configurazione dei client che quella
dei server storage.


 Si può usare in produzione su link geografici (non xDSL per intenderci)?
Con criterio. Dipende da cosa t'aspetti di farci.
Studia! ;-)


 Con criterio. Dipende da cosa t'aspetti di farci.
Pensavo di replicare tutto l'archivio di google, in
modo da farmi una cache locale :)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 maniera differente in base a chi si collega.
Ni.
Studia! :-D


 Studia! :-D
Ok, ok, anche la configurazione dei client va lasciata
sul server, sarà il server stesso a 'sparare' la configurazione
del client direttamente al client non appena quest'ultimo si collega.
Ecco, così allora è una figata da paura, non ci si può sbagliare. :)


 Ecco, così allora è una figata da paura, non ci si può sbagliare. :)
Spettacolare glusterfs.
Per ora mi sto dando alla pazza gioia a suon di test.
Ho creato 4 nodi, nodo1+nodo2 in replica, nodo3+nodo4 in replica
e poi replica1 + replica2 in distribuzione.
In questo modo ho l'equivalente di un raid10 ma distribuito in giro
per il mondo.
E' corretto usare questa configurazione ?
volume replica1
   type cluster/replicate
   subvolumes storage1 storage2
end-volume
volume replica2
   type cluster/replicate
   subvolumes storage2 storage4
end-volume
volume distribute
   type cluster/distribute
   subvolumes replica1 replica2
end-volume
Leggevo pareri discordanti in merito al cluster/distribute,
alcuni suggeriscono di usare il "distributed replicated volume"
(va da se che son tutti smanettamenti vari, farò prove approfondite
in futuro. Chiedo solo conferma per la strada corretta da seguire)


 
e che cosa succede se l'applicativo scrive su uno solo dei nodi perchï¿œ
l'altro nodo ï¿œ giï¿œ ? Come risincronizzi i dati ?
 Giovanni

 E' corretto usare questa configurazione ?
Come al solito, dipende.

 E' corretto usare questa configurazione ?
Se sta bene a te, sì. Ma io che ne so?
Occhio che cmq "distribute" *non* è un RAID0: scrive "semplicemente" i
*file* un po' di qui e un po' di là. Nessuno striping (che esiste pure,
ma non ha senso).


 ma non ha senso).
Mi sta bene un brutale distribute.
Vorrei provare a configurare il tutto per avere un RAID1 via rete
mediante il replicate, dopo di che, aggregare due volumi in replicate
in un volume distribute.
Però vedo che la versione 3.2 ha fatta passi avanti in maniera
sensibile ed include un tool di autoconfigurazione e reportistica,
quindi vedrò di lavorare sulla 3.2 ricompilata piuttosto che la 3.0
presente in squeeze. (il problema è che vuole un amd64 ed al momento
ho solo VPS a 32bit)


 ho solo VPS a 32bit)
Bada di studiare bene lo stato di "stabilità" della 3.2 prima di
pentirtene. C'è chi ha bestemmiato parecchio attorno alla scelta di
"partire" con le versioni più recenti, AFAIR...


 "partire" con le versioni più recenti, AFAIR...
Io sono tra quelli.
Già il fatto di non poterla installare su una i386 per le prove
mi fa incacchiare.
La 3.0 ero riuscito a farla funzionare in pochi minuti, ma sinceramente
non ho trovato alcun tool che mi permettesse di sapere lo status dei
vari storage server, e potrebbe far comodo per il monitoraggio (snmp etc)
Sinceramente sulla 3.0 non avrei idea di come verificare se il nodo X
stia funzionando oppure no.
Tra l'altro, non c'è più la documentazione online. Parla solo della 3.2
ed il supercomandofactotum "glusterfs"


 mi fa incacchiare.
Scusate, ma c'è modo di compilare la 3.1 o la 3.2 su i386?
Sicuramente si, visto che ci sono i pacchetti in sid, ma come
diavolo si fa? E' da ieri che ci provo, o non compila perchè
mancano alcuni include per amd64 oppure compila e poi non parte
perchè mancano delle librerie dinamiche.
