Newsgroup: it.comp.os.linux.sys
Titolo: OCFS2 - Esperienze?

Avete mai usato il FS in oggetto, in produzione?
Ho un blockdevice ridondato che deve essere viso, simultaneamente, da almeno 5 nodi.
 
Affidabilità? Performance? Dovrò salvare sostanzialmente dei progetti GIT (quindi file anche molto piccoli) ed anche alcuni file grafici (svariati giga)
 
Ciò che vorrei ottenere è un mountpoint messo in /mnt/fscondiviso ed accessibile in simultanea (RW) da tutti i nodi.
 
Alternative migliori ? In sostanza mi serve un NFS ridondato.


 
Io ci ho provato qualche anno fa su linux debian lenny direi..
Ho dovuto abbandonare.
Non era stabile, ma avevo poco tempo per il debugging ...
 
-- Yena --

 Non era stabile, ma avevo poco tempo per il debugging ...
 
Uhm, strano però... Mi pare sia un FS piuttosto rinomato.

 almeno 5 nodi.
 
Cosa intendi per ridondato? Da come la interpreto, NFS dovrebbe gia` fare al 
caso tuo (hai un device X ridondato con DRBD o altro e dev'essere visto da N 
macchine)
 
Enrico

 macchine)
 
Uhm. Come gestisce i lock NFS? L'ho usato solo una volta e AFAIR non era molto "smart" per l'accesso concorrente. Cosa succede se due client mi scrivono lo stesso file nello stesso momento? I filesystem distribuiti dovrebbero essere progettati appositamente.

 Uhm. Come gestisce i lock NFS? L'ho usato solo una volta e AFAIR non era molto "smart" per l'accesso concorrente. Cosa succede se due client mi scrivono lo stesso file nello stesso momento? I filesystem distribuiti dovrebbero essere progettati appositamente.
 
Buona domanda, cosa succede?
In generale, il "problema" e` risolto senza soluzione.
 
bye,
 
-- 
 
piergiorgio

 In generale, il "problema" e` risolto senza soluzione.
 
LOL. Beh, darà qualche cenno di vita, non credo imploda.
Uno dei due riceve errore? Oppure il secondo che salva sovrascrive ciò che ha fatto il primo? Non c'è un lock in lettura?

 Uno dei due riceve errore? Oppure il secondo che salva sovrascrive ci� che ha fatto il primo? Non c'� un lock in lettura?
 
Se cerchi il reader(s)-writer(s) problem, troverai
informazioni sulla cosa e le varie soluzioni.
 
Una, per esempio, e` un lock globale, cioe` il
file e` locked, fino a chi ci scrive non lo chiude.
Un'altra e` averlo locked per le scritture, ma
disponibile a tutte le letture.
Un'altra e` avere un lock "locale" cioe` una
scrittura e` "atomica", ma diverse scritture
possono avvenire da soggetti diversi.
E cosi` via, non c'e` un soluzione che consenta
prestazioni e sicurezza contemporaneamente.
 
Alcuni FS distribuiti hanno file "immutabili",
che una volta creati, sono solo in lettura per
chiunque (o cancellabili).
Nota che nel caso di FS distribuiti, vi e` il
problema della latenza.
Dato che il FS e` *distribuito* (appunto), ogni
cambiamento deve essere sincronizzato fra i vari
nodi, il che e` un problema serio in caso di
scritture contemporanee da piu` soggetti.
 
NFS dovrebbe andare abbastanza bene, non saprei,
cosi` a braccio, cosa succede in caso di scritture
contemporanee. Non penso sia grave, cioe` non credo
NFS corrompa il FS sottostante.
 
bye,
 
-- 
 
piergiorgio

 NFS corrompa il FS sottostante.
 
Ecco, avevo perso di vista il problema principale: io non ho un FS sottostante.
E' proprio ciò che sto cercando di trovare. Ho un device a blocchi, che devo
rendere accessibile da molteplici nodi, in RW simultanea senza SPOF.
 
Trascurando il tipo di device a blocchi, devo prima trovare un FS, poi eventualmente esportare via rete tale FS (magari tramite NFS o protocollo analogo).
 
Il problema di NFS è che devo creare un cluster hot-standby (per evitare di mettere il culo davanti alle pedate), cosa che vorrei
evitare, oltre al fatto che mi si aggiungerebbe un ulteriore layer di complessità. (device a blocchi -> fs condiviso -> NFS -> client)
 
OCFS2 dovrebbe fare tutto da solo: è un FS, è distribuito, non necessita di esportazione in quanto tutti i client montano il FS localmente. In pratica, fa tutto lui a partire dallo stesso device a blocchi. (device a blocchi -> OCFS2+Client)

 piccoli) ed anche alcuni file grafici (svariati giga)
 
Stavo riflettendo su questo punto. Tralasciando il discorso dei file grafici 
(che, in teoria, potrebbero finire anche loro in un repository Git), da come 
la descrivi sembrerebbe che tutti useranno contemporaneamente lo stesso 
repository Git presente sul device condiviso, ovvero sulla macchina X c'e` 
un repository Git a cui tutti accederanno contemporaneamente e 
indistintamente. Dato che una situazione del genere mi fa ribrezzo al solo 
pensiero (Git non e` nato per essere usato cosi`), perche` non esporti i 
repository via http e poi tutti coloro che devono usarli si connettono 
tramite questo protocollo? Qua trovi maggiori informazioni: 
https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#public-repositories
 
 
Enrico

 tramite questo protocollo? Qua trovi maggiori informazioni: 
 
Aspetta, forse mi sono espresso male.
Era per indicare la tipologia di file, non il workflow.
Normalmente su git ci va del codice, ed è questo il mio caso, quindi moltissimi file di piccole dimensioni. Non delle ISO per intenderci.
I file grafici erano per indicare esattamente l'opposto, ovvero file di grosse dimensioni (che a dire il vero sono anch'esse su git, almeno in parte)
 
So bene che git non si usa in modalità centralizzata simil-svn (non saprei nemmeno come fare) ed infatti non lo usiamo in questo modo. Era solo per indicare la tipologia di file: tantissimi file di piccole dimensioni. Circa 1TB di progetti tra PHP+HTML+CSS e circa 800GB di file di grosse dimensoni (nell'ordine delle centinaia di mega o giga: 200M-3G)


 
OCFS2 non è un filesystem distribuito, è un cluster-aware filesystem 
(come GFS). Sono 2 cose molto diverse
 
Lustre è un filesystem distribuito
 
P.S. Mi sa che ti ho scritto via email, per errore

 P.S. Mi sa che ti ho scritto via email, per errore
 
si, ma nessun problema.

 Hai ragione. A me serve un qualcosa di analogo ad OCFS2
 
Secondo me no.
 

 Secondo me no.
 
e secondo te cosa potrebbe fare al caso mio?

 ed infatti non lo usiamo in questo modo.
 
Probabile, ma da quello che ho capito e` proprio la modalita` che volete 
implementare :)
 
Enrico

 implementare :)
 
Mica vero. Avrei lo stesso, identico, problema nel caso volessi ridondare qualunque servizio in modalità active-active dove due o più nodi devo accedere allo stesso FS.
 
Io non so che FS usare, non avendone mai usato uno clustered.
Più semplicemente: se avessi 14 webserver che devono pescare gli stessi dati e volessi fare bilanciamento dello storage? NFS non va bene (è active-passive causa lock), quindi che si può usare?


 
L'ho fatto di nuovo, sulla nuova versione di Thunderbird adesso il tasto 
"Reply" risponde via mail anzichč fare il followup...
 
:|


 
GlusterFS ?
 
-- Yena --

 GlusterFS ?
 
No, GlusterFS poi è ottimizzato per file grossi, ho indicato GIT come esempio proprio perche' ho 1TB di file piccolissimi.

 No, GlusterFS poi è ottimizzato per file grossi, ho indicato GIT come esempio proprio perche' ho 1TB di file piccolissimi.
 
E poi GlusterFS vuole molteplici device a blocchi sui quali fa ridondanza, non penso sia saggio implementare GlusterFS ed usare un singolo brick.


 
Costa parecchio ma e' il leader indiscusso per quello che devi fare tu: 
GPFS.
 
http://www.redbooks.ibm.com/abstracts/sg247844.html?Open
 
 
Ciao
 
Ale
 

 
 
Il problema di usarlo con lenny era il kernel, bacato in un punto
critico per gli accessi contemporanei ad un block device.
 
Upgradare ad un kernel piů recente (>2.6.32) risolveva.

 Ho un blockdevice ridondato che deve essere viso, simultaneamente, da almeno 5 nodi.
 
Funziona molto bene dal kernel 2.6.32 in avanti: se non hai una SAN devi 
avere l'unica accortezza di usare un device DRBD sotto al FS con 
protocollo C (sincrono) e configurato come multi-master (anche all'avvio 
delle macchine) nel drbd.conf con una interfaccia GbE dedicata per ogni 
macchina (il throughput potrebbe essere alto).
Le performance sono ottime, anche su molti file piccoli (GFS2 mi andava 
peggio con quella tipologia di dati).
Sull'affidabilità non so dirti, non ho avuto occasione di fargli un fsck 
in condizioni critiche (sgrat, sgrat.... ;P).
 
Ciao,
 
 
-- 
Fr3ddie
fr3...@fr3ddie.it
 
 
«Un amico è uno che sa tutto di te e, nonostante questo, ti stima»
Elbert Hubbard