Newsgroup: it.comp.os.linux.sys
Titolo: Re: Cluster FS

 GlusterFS? AFS? GFS? What else?
 
Mai messi in produzione però dalle prove che ho fatto e da quello che ho letto:
 
- per GFS serve un'infrastruttura per il lock manager, GFS1 è molto 
lento per piccoli file (ad esempio mail server) con GFS2 hanno risolto 
in parte ma non totalmente. Ti serve una infrastuttura cluster stile 
RedHat, che potrebbe complicarti la vita
 
- GlusterFS è un "nuovo" proggetto che da poco è stato integrato anche 
da RedHat. Ha alcuni aspetti che mi piacciono parecchio: il filesystem 
di base può essere un comune ext3/4, cosa non da poco in caso di 
casini. Dovrebbe scalare bene sia con file piccoli che grandi (per i 
piccoli usa un db). Può fare sia stripe, sia mirroring. Molto facile da 
implementare a mio avviso. RedHat lo propone, per esempio, come fs per 
lo storage di macchine virtuali.
 
- AFS non ho esperienze dirette ma viene usato ad esempio per fs 
distribuiti anche geograficamente. I client possono essere 
multipiattafroma (ossia Windows può accederci direttamente).
 
Se ti serve un fs locale andrei di GlusterFS, altrimenti AFS. Si si è 
capito GFS non mi piace proprio :-)
 
I miei 2 cents.
 

 lo storage di macchine virtuali.
 
Mi chiedo come sia possibile usarlo per storage di VM.
GlusterFS è interessantissimo, ma ad oggi ha un *piccolissimo* difetto: fa il lock di un file intero quando lo deve ricostruire. Quindi se hai il crash
di un nodo ed ospiti immagini di VM, quando fai ripartire il nodo lui fa il resync lockando tutta l'immagine. Se è 50GB aspetti mezzora prima che l'immagine sia in sync e quindi unlockata.
 
Per file piccoli è una figata, l'ho usato per alcuni test e mi è sembrato portentoso. Bisogna però capire bene come funziona il meccanismo di mount
lato client, perchè dalle mie prove, il client punta sempre e solo ad un nodo,
se tale nodo è down in client non riesce a montare il volume.
Se invece il nodo muore quando il client è già montato, il fallback sul nodo clone è trasparente.

 Se invece il nodo muore quando il client è già montato, il fallback sul nodo clone è trasparente.
 
Quindi se ho capito bene non c'è bisogno di DRDB ??
 
-- Yena --

 GlusterFS? AFS? GFS? What else?
 
 
OCFS2 (Oracle cluster Filesystem)
IBM GPFS
 
prova a vedere se GPFS di IBM è free... non mi ricordo. Da noi, laddove GFS 
si schianta, IBM GPFS non fa una grinza.
 
ocfs2 lo trovi in tutte le distro.
 
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 Quindi se ho capito bene non c'è bisogno di DRDB ??
 
Ovviamente DRDB non serve, GlusterFS è un filesystem distribuito e funziona decisamente bene. Forse è ancora un po troppo acerbo per essere usato in produzione (dipende dal contesto) ma secondo me quando han risolto questi due "bug", diventa un ottimo prodotto

 Per file piccoli è una figata, l'ho usato per alcuni test e mi è sembrato portentoso. 
 
mi autoquoto e riconfermo quanto scritto: 
 
UNA FIGATA PAZZESCA. 
 
Su una LAN 100mbit non ottimizzata (niente jumbo frames), nic della mutua, nessuna opzione di mount lato client ne altro, computer desktop usati come server e poca ram, riesco a saturare per tutto il tempo i 100mbit nel trasferire file di 100MB. 
 
Ho fatto un ciclo in 'dd' che crea 1000 file da 100mb e saturo la LAN. 
Voglio riprovarlo con delle nic gigabit.

 Voglio riprovarlo con delle nic gigabit.
 
Mi sa che abbiamo idee molto differenti per cos'è un file piccolo.

 Mi sa che abbiamo idee molto differenti per cos'è un file piccolo.
 
100M non è un file piccolo.
Ho detto di aver provato con file da 100M, se con 100M è stato portentoso ,figuriamoci con file piccoli.
 
Con 10M la sincronizzazione non si nota, dura circa 1 secondo scarso.
Pensa che miracoli può fare in ambito mail...
 
devo provare a cancellare un file direttamente da un nodo e vedere se il client riesce ad accedervi uguale usando l'altro. In teoria si, e dovrebbe approfittarne per sincronizzare. Poi lo cancello dall'altro lato e dovrebbe andare uguale.


 
Qualcuno ha provato a metterci sopra delle
VirtualMachines KVM o OpenvZ ?
 
 
-- Yena --

 VirtualMachines KVM o OpenvZ ?
 
Non ho provato, ma per come lavora, è un suicidio.
Prova a fare la sincronizzazione di un file da 100GB poi mi dici.
Mentre sincronizza (e ci pensa il client a gestire le operazioni, non il server) il file non è usabile pertanto la VM non potrà funzionare.

 devo provare a cancellare un file direttamente da un nodo e vedere se il client riesce ad accedervi uguale usando l'altro. In teoria si, e dovrebbe approfittarne per sincronizzare. Poi lo cancello dall'altro lato e dovrebbe andare uguale.
 
 
Funziona.
Ho creato dei file, una ventina.
Poi dallo storage1 ne ho cancellato uno brutalmente, senza passare dal client.
Dal client ho provato a leggere il file, gluster ha risincronizzato il file leggendolo dallo storage2.
 
Viceversa idem.

 ocfs2 lo trovi in tutte le distro.
 
Però richiede uno storage distribuito.
 
-- 
ValeRyo 
 
 


L'esatto contrario, semmai O:-)
 
 
-- 
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/
 

 L'esatto contrario, semmai O:-)
 
Uh? Aiutami a capire...
 
-- 
ValeRyo 
 
 

 ha scritto nel messaggio
news:jm1fjh$q2p$
1...@alix.livenet.it
 

"Però richiede uno storage condiviso."
 
-- 
ValeRyo
 
 
 

 Uh? Aiutami a capire...
 
OCFS2 è un filesistem che consente accesso concorrente allo stesso block
device.
 
Tipo: hai una SAN che esporta una LUN e vuoi usare un filesystem su
quella LUN da 5 macchine contemporaneamente.
 
Uno storage distribuito è l'esatto opposto: lì astrai un filesystem
realizzato attraverso il merge di N risorse poste in luoghi diversi.
GlusterFS è di questo tipo. O Lustre. O AFS. O (MS)DFS...


 GlusterFS è di questo tipo. O Lustre. O AFS. O (MS)DFS...
 
In realtà a me serve più una cosa stile OCFS2 perché le macchine
sono nello stesso datacenter, vorrei solo ridondarle.
Però GlusterFS mi attira per la ridondanza geografica.
 
Troppa carne a cuocere e poco tempo per dei test soddisfacenti.
 
-- 
ValeRyo 
 
 

 Però GlusterFS mi attira per la ridondanza geografica.
 
Naaaaaaaaaaaaaaa, lascia stare la ridondanza geografica.
Dimenticatela con Gluster. Ho provato anche quelle e salvo
punto-punto dedicate, le performance sono orrende.
 
La geo-replication, invece, è un disaster recovery fatto in automatico
con rsync. Non puoi (non dovresti) accedere al lato remoto in condizioni
normali ma solo in caso di disastro.

 condizioni normali ma solo in caso di disastro.
 
E cos'ha in piů di un rsync liscio?
 
-- 
ValeRyo 
 
 

 E cos'ha in più di un rsync liscio?
 
L'rsync di GlusterFS? Non ne ho idea, me lo sto chiedendo anche io.

 quindi uscivo su internet normalmente.
 
Ma il problema è sulla scrittura in locale o sulla performance in remoto?
Perché se in locale va veloce e il problema è che in remoto i dati
arrivano dopo un po' non è un problema, l'importante è che prima o poi
arrivino.
Se invece la scrittura remota lenta mi rallenta anche la scrittura locale
(come il protocollo C del drbd, se hai presente) allora non va bene.
 
-- 
ValeRyo 
 
 

 (come il protocollo C del drbd, se hai presente) allora non va bene.
 
Su gluster, a differenza di drbd, è il client che gestisce il tutto, e non i server.
Pertanto, il client una volta montato il volume si scarica la configurazione e sa già cosa scrivere e dove. Quando scrivi un file da 100MB, lui lo scrive simultaneamente sia sul server1, sia sul server2, se il server2 è lento il client aspetta, aspetta, aspetta ed aspetta fino alla ricezione di un "OK! Va tutto alla grande". A forza di aspettare, le scritture successive rallentano.

 di aspettare, le scritture successive rallentano.
 
Quindi si comporta come il protocollo C di DRDB: ok solo quando
tutti hanno scritto tutto su disco (o almeno nella cache locale).
E quando usi il client nfs? Lui che ne sa di dove scrivere cosa?
Non dovrebbe essere il server ad occuparsi della replica, dello
striping o di quel che è configurato?
-- 
ValeRyo
 
 

 striping o di quel che è configurato?
 
Su GlusterFS è il client che coordina, su questo son sicuro.
Quando usi NFS anzichè il suo client nativo, sinceramente non so
chi sia a coordinare. Bella domanda.

 chi sia a coordinare. Bella domanda.
 
Leggendo la documentazione (che devono *decisamente* migliorare,
IMHO è troppo confusa) mi sembra di capire che il client nativo si
connette a tutti i brick e li usa direttamente secondo la configurazione
indicata dal server, mentre se usi il client NFS è il server a fare la
replica.
 
Ho trovato questa pagina che parla d'altro ma potrebbe essere d'aiuto:
http://gluster.org/community/documentation//index.php/NFS_Replication_and_Virtual_IP_Migration
 
 
-- 
ValeRyo
 
 

 replica.
 
In tal caso allora dovrebbe essere più performante l'NFS rispetto al client nativo.
Eppure, stando alla documentazione, il client nativo è consigliato perchè migliore in termini di performance.
 
Ora tocca a te fare un po di prove :) Io non ho hardware di ripiego con schede gigabit, i computer delle prove attuali sono vecchi e non hanno slot pciexpress ed io ho non ho schede gigabit pci.

 hanno slot pciexpress ed io ho non ho schede gigabit pci.
 
Ancora non so se mettermi a fare prove pratiche con questo fs... non
vorrei perder tempo inutilmente :-/
 
-- 
ValeRyo 
 
 

 vorrei perder tempo inutilmente :-/
 
Non è tempo perso inutilmente, è tempo che fai risparmiare a me :)

 client faccia da client, senza che quest'ultimo gestisca uno storage.
 
Quoto.
Anche a me non piace l'idea che siano i client ad agire.
Perň in questo contesto avrebbe il suo senso.
 
A meno che in lettura il client vada in giro per server e in scrittura
scriva solo su uno che poi replica. Dalla documentazione non si
capisce :-(
 
-- 
ValeRyo 
 
 

 capisce :-(
 
Da quel che ho capito, fa tutto il client, ovvero il client si connette ad uno dei server (quello usato per il mount), scarica la configurazione, poi fa tutto lui. Ci pensa il client a decidere cosa leggere e da quale server e sempre il client pensa a replicare i dati sui server in accordo con la configurazione.

 Da quel che ho capito, fa tutto il client, ovvero il client si connette ad uno dei server (quello usato per il mount), scarica la configurazione, poi fa tutto lui. Ci pensa il client a decidere cosa leggere e da quale server e sempre il client pensa a replicare i dati sui server in accordo con la configurazione.
 
Comunque sarebbe da fare un raffronto prestazionale con OpenStack.
La configurazione consigliata di OpenStack è con 3 repliche, quindi GlusterFS è sicuramente più economico. Ma le prestazioni come sono di OpenStack?
 
Qualcuno l'ha usato?