Newsgroup: it.comp.os.linux.sys
Titolo: filesystem di rete... fault tolerant: PER ESPERTONI

ciao a tutti.
sto attualmente lavorando ad un progetto di una nuova infrastruttura, 
quindi ancora ampliamente modificabile. E' emersa una necessità, ovvero 
che certi filesystem siano sulla rete. come implementazione classica 
avevo scelto nfs, in quanto i filesystem non producono traffici 
particolarmente intensi, ma mi è stata sollevata la questione della 
tolleranza ai guasti. Sono il primo ad aver notato che molto spesso i 
filesystem montati via nfs, se si verificano problemi, non sono più 
accedibili dalle macchine che li montano...
e allora da qui la mia domanda, visto che sicuramente qualcuno avrà 
affrontato questo problema (davide bianchi? ;-))...
come fareste voi?
sono abbastanza svincolato dalla soluzione utilizzata a patto che non 
sia una cosa troppo sperimentale (è un ambiente in prod) e giri su linux 
(per il progetto usiamo redhat ent. 5.2).
grazie a tutti

 accedibili dalle macchine che li montano...
Sono spiacente di deluderti, ma non vi e' soluzione. Se hai un problema
sulla rete il filesystem te lo perdi. Ergo: invece di usare un
filesystem usa un altro sistema (http? ftp?) che non richiede una
connessione continua.
Davide
-- 
USER, n.: The word computer professionals use when they mean "idiot."
--Dave Barry, "Claw Your Way to the Top"

 
non mi sento deluso!
ma non mi è possibile...
che mi dici di afs... le premesse sembrano buone:
AFS' primary purpose is to serve files over the network in a robust, 
efficient, reliable and fault-tolerant way.
qualcuno lo ha mai usato?

 connessione continua.
Be', forse afs...ma forse e' un po' (!) overkill...

per i problemi sulla rete va bene, voglio solo evitare che il corllo 
della macchina che fornisce il filesystem possa essere causa di 
problemi... se la rete cade ho problemi molto + grossi da gestire e in 
questo caso il filesystem fault tolerant è irrilevante


Beh , Io metterei semplicemente il servizio nfs in cluster, se hai uno
storage esterno ti basta solo clusterizzare il servizio, se non lo hai
ti crei anche una risorsa disco con drbd.
Poi molto dipende anche dai client che dovranno accedere a queste
risorse, considera anche l'utilizzo di samba (sempre in cluster) per
la condivisione del filesystem che probabilmente ti creerà meno
problemi rispetto all'nfs in caso di fault di uno dei due nodi.

 che certi filesystem siano sulla rete.
E' un po' troppo vago. Cosa vuol dire che dei filesystem "siano sulla
rete"? Devi montarli come block device? Devi condividere dei file? A
seconda dell'utilizzo le soluzioni possono essere diverse.
bye!

 che mi dici di afs... le premesse sembrano buone:
Non uso fs di rete (a parte samba) da parecchio tempo, e AFS l'ho solo 
sentito nominare, ma so che dal kernel 2.6.29 (quello in lavorazione) 
dovrebbe essere incluso anche POHMELFS. Prova a dare un occhio anche a lui.
Non mi ricordo, inoltre, se fosse AFS o un altro, il fs di rete 
distribuito, che teneva una cache in giro per le varie macchine e si 
sincronizzava da solo quando tornava il collegamento col server.
Bye.

ho perplessità a mettere in cluster nfs perché secondo me non si 
risolve... se metto un vip e lo faccio ballare tra due nodi i client 
secondo me si incazzano comunque....

nel senso che è difficile da configurare???
in questo caso non lo vedo un grosso problema, basta configurarlo una volta

sono filesystem da montare... contengono i war delle web-applications 
condivise dai vari nodi tomcat in cluster...
anche i logdi log4j verrebbe scritti lì.
nfs mi è sempre andato bene ma vorrei che il fs fosse fault tolerant in 
caso di crash della macchina che lo rende disponibile. Un collasso della 
rete mi preoccupa per altre cose e in questo caso il fatto che il 
filesystem non sia + raggiungibile mi importa poco. vorrei solo che 
fosse solo + diuna macchina ad offrire il servizio e in caso di caduta 
di una macchina le macchine che montano il filesystem possono continuare 
ad accedere alla risorsa ridondata senza fare attività diremount (come 
faccio quando nfs si incrocchia).


No.
Abbi l'accortezza di condividere /var/lib/nfs tra i due nodi 
(simlinkandolo ad una directory del filesystem condiviso) e i client non 
si accorgono nemmeno del failover.
Vedi
http://www.linux-ha.org/DRBD/NFS
-- 
http://bofhskull.wordpress.com/

 problemi...
Scusi la domanda esimio... come pensi di evitare problemi se la macchina
che rende disponibile il filesystem crolla (e non e' un cluster)? Cosa
dovrebbe fare il povero tapino che vuole scrivere su quel filesystem?
Dove se li mette i bytes?
Io comincerei a pensare ad un sistema per EVITARE del tutto i filesystem
montati da remoto. RSync per prelevare eventuali differenze di files di
configurazione, aggiornamenti off-line di file di uso, database
replicati e/o transazioni multiple e cosi' via.
Davide

 filesystem non sia + raggiungibile mi importa poco.
Ho fatto una cosa simile molto di recente.
Due macchine connesse allo storage esportano le LUN via iscsi sulla rete.
Le LUN esportate vengono accedute tramite multipath (quindi se cade una 
delle macchine che fanno da gateway iSCSI/FC sei protetto) e sopra vi ho 
messo GFS per consentire a tutti i nodi che hanno bisogno della LUN di 
montare il filesystem RW.
Non è molto complicato da fare, hai tutto già incluso in RH5 (sulla 4 hai 
bisogno della Cluster Suite e di GFS) ed è molto affidabile essendo tutto 
ridondato.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 faccio quando nfs si incrocchia).
In alternativa, filesystem distinti e replicati, con il meccanismo che
preferisci...
bye!

è proprio quello che dovrebbe fare afs... non ho mai visto nfs 
clusterizzato perché imho non funziona...

controllo grazie del suggerimento, verifico

 accedibili dalle macchine che li montano...
Non sono un espertone, ma posso dirti che io uso con molta 
soddisfazzione sshfs -o reconnect.
My 2 cents..  :-)
Ste

 che mi dici di afs... le premesse sembrano buone:
Mi pare che la tua domanda richieda risposte abbastanza scontate.
NFS non va bene da quel punto di vista. Anche quando montato in
montato in modalità soft da problemi (ha dei parametri di timeout, ma
in definitiva, quel che stavi scrivendo a un certo punto lo perdi
inesorabilmente... in più devi aspettare i timeout), se lo monti in
modalità hard rischi addirittura di inchiodare i client (il mount
point non lo smonti più, un operazione di scrittura non esce più, e
peggio di peggio, l'init 6 o init 0 falliranno lo smontaggio e dovrai
fare un reset del client).
La soluzione è quella che stai dicendo tu: AFS o comunque un
filesystem di rete che abbia quelle caratteristiche. AFS consente di
lavorare offline e sincronizzare tutto quando si va online.
I problemi da capire sono:
1) il codice disponibile per linux è abbastanza maturo? Non lo so, ma
credo che i problemi insiti in NFS ti causerebbero comunque più noie
di qualsiasi potenziale problema a livello di codice di AFS... non so
se mi sono spiegato bene. NFS sarà esente da bug, ma all'atto pratico
ti creerà più problemi di un software con eventuali bug (anche
eventuali security issue, mi permetto di dire)
2) nel tuo progetto il gioco vale la candela? AFS è complesso. NFS non
lo devi nemmeno tirare su: scrivi 4 ca$$ate in exports, lanci il
demone ed e vai.
A me era venuto il pensierino di tirare su AFS per uso domestico, ma
(ti dico la verità) ho soprasseduto e sto usando NFS e Samba.

 anche i logdi log4j verrebbe scritti lì.
oddio... i log di log4j si attivano IMHO solo in caso di debugging.
Non forniscono informazioni di auditing se non ricordo male, sono
abbastanza criptici...
insomma, se ne perdi un po' chi vuoi che pianga?

 sincronizzava da solo quando tornava il collegamento col server.
Si è senz'altro AFS.
Durante un giorno di ordinaria follia mi venne in mente di tirarlo su
per la mia rete domestica.
Alla fine feci prevalere il buon senso e lasciai perdere, prima ancora
di cominciare.


Confermo. Sia con DRBD (anche se lo switch da un nodo all'altro non è 
velocissimo) sia con storage condiviso, è in piedi da 4 anni 
ininterrotti ed ha subito alcuni switch per cause previste ed impreviste.
Angelo