FileSystem Distribuiti LinuxTrent - 07/07/2011

Cos'è un filesystem distribuito ? Un file system distribuito (in inglese, Distributed File System, o DFS) è un particolare file system che permette la memorizzazioni di files e risorse in dispositivi di archiviazione distribuiti in una rete informatica. A differenza di un comune file system locale, i dati non vengono letti o archiviati su di un dispositivo locale, ma, attraverso un meccanismo client-server, su dispositivi remoti, collegati in maniera trasparente alla propria gerarchia di file. (fonte Wikipedia)

Alcuni esempi di filesystem distribuiti o NFS (file system di rete) o AFS o MooseFS o GlusterFS

NFS Sviluppato da Sun Microsystem (1985) Utilizza il sistema di RPC (Remote Procedure Call) La versione 2 prevedeva solo l'uso del protocollo di rete UDP Il sistema di locking e controllo quota avviene con delle RPC separate Con la versione 3 viene introdotta la possibilità di usare TCP Con la versione 4 di fatto diventa un file system distribuito client-server stateful

NFS... continua Alcune considerazioni: personalmente NON l'ho mai installato alcuni sistemisti con cui ho parlato mi dicono che NON è semplicissimo da installare/configurare altri sistemisti che l'hanno provato mi segnalano che NFS non lavora bene con file di grosse dimensioni

AFS Sviluppato inizialmente dalla Carnegie Mellon University e' stato poi implementato da Transarc(IBM), OpenAFS e Arla Utilizza Kerberos IV per l'autenticazione La struttura prevede diversi servizi per la gestione delle autenticazioni, acl, volume management, file service e backup/restore Multipiattaforma Unix, Linux, Windows, MacOS Access Control List "estese" a livello di directory Creazione e gestione gruppi per username Repliche Volumi, Volumi di Backup Migrazione Volumi "trasparente" all'utenza

AFS... continua Alcune considerazioni: anche questo NON l'ho provato ma ho iniziato quantomento a leggere la documentazione ! pensato principalmente per gestire la geo-replicazionione l'ho scartato a priori per i seguenti motivi: o troppa roba da configurare (kerberos, ldap, pam...) o cercando in rete pareri sulle performance, tra svariati forum, NON ho trovato valori che giustificassero lo sforzo per un'installazione di prova.

MooseFS Questo l'ho provato con mano :-) l'installazione è relativamente semplice: o scaricare i sorgenti o "generare" i pacchetti per la propria distribuzione (es. debian) o installare i pacchetti appena generati sui vari server interessati Gli "oggetti" che compongono un sistema MooseFS sono: o un master server (questo è un single point of failure) o uno o più chunk server o metalogger server (utilizzato come backup server in caso di arresto del master server) o client, sul quale vengono montati i volumi condivisi

MooseFS... continua Alcune caratteristiche interessanti: a differenza di NFS e AFS, questo tipo di filesystem distribuito si appoggia a FUSE (file system in user space) con delle prestazioni "teoriche" inferiori ma che al lato pratico NON "impegnano eccessivamente" l'intero sistema durante un grosso carico di I/O su disco rendendolo in definita più performante di altre soluzioni il sistema ha una certa tolleranza ai guasti o avendo N chunk server (dove N > 1), in caso di guasto di un chunk server l'intero sistema continua a funzionare senza che i client si accorgano di nulla (questo su carta.... NON ho avuto modo di testarlo personalmente) o configurando opportunamente CARP (Common Address Redundancy Protocol) è possibile gestire un eventual fail-over del server master

MooseFS... continua Alcune caratteristiche interessanti: supporta una sorta di snapshot (NON si tratta delle snapshot di LVM !) ha una propria gestione, configurabile, del "cestino" (es. decido di mantenere una copia del file X o della cartella Y quando viene cancellato fino a N giorni) il sistema è scalabile sia in performance che in termini di spazio disco (basta aggiungere nuovi chunk server) le prestazioni sono simili a quelle di GlusterFS

MooseFS... continua Cosa NON mi è piaciuto di questo giochino, che comunque reputo un'ottimo strumento: utilizza una serie di file per la gestione dei METADATA relativi ai file presenti all'interno del filesystem (questi vanno backuppati e ripristinati in caso di problemi con il master, in realtà viene fatto in automatico dal logserver) la cartella in cui vengono memorizzati fisicamente i file è suddivisa in sottocartelle gestite direttamente da MooseFS... risulta pertanto difficile risalire ad un singolo file senza passare attraverso il "sistema" MooseFS è necessario appoggiarsi a sistemi esterni (es. CARP o Heartbeat) per gestire il ripristino del funzionamento del sistema dovuto a eventuali blocchi del server master

MooseFS... continua Cosa invece mi è piaciuto di questo giochino: semplice da configurare (4 file in croce !) anche se pveperf (Proxmox) mi dice che il valore di FSYNC è una schifezza e NON dovrei utilizzare MooseFS per metterci i dischi virtuali delle mie macchine virtuali... a conti fatti le macchine virtuali girano abbastanza bene (anche grazie all'uso intensivo della cache) l'uso di CPU e RAM lato client non è eccessivo gestisce le snapshot a livello di filesystem distribuito (con GlusterFS la cosa va gestita in modo "diverso" !)

MooseFS... continua gestisce un "cestino" configurabile per poter recuperare eventuali file cancellati MooseFS utilizza il concetto dei "goal" che mi consente di mantenere N copie di uno stesso file o di una cartella "mirrorati" su diversi server.... il numero di goal può essere un numero dispari (es. file pippo.txt per il quale voglio mantenere 3 copie, 1 copia per ogni server MooseFS)

GlusterFS GlusterFS è un file system distribuito in grado di scalare fino a molti petabytes ed è in grado di gestire migliaia di client. Anche GlusterFS gira in userspace appoggiandosi a FUSE... vale quanto detto per MooseFS. E' presente nei repository di Debian... consigliato assolutamente scaricare i pacchetti aggiornati per Debian direttamente dal sito Esiste la versione "comunity" e una versione commerciale che "ingloba" glusterfs con un'interfaccia Web da cui è possibile monitorare e configurare l'intero sistema.

GlusterFS... alcuni CONTRO NON esiste un software che mi permetta di "montare direttamente" il cluster da un client Windows. Le alternative sono: utilizzare come client un server Linux e configurare Samba per rendere disponibile il cluster a Windows GlusterFS può "interfacciarsi" direttamente con NFS forse esiste qualche modo per montare un cluster NFS direttamente in un client Windows... qualche idea ?

GlusterFS... alcuni CONTRO NON gestisce nessun tipo di snapshot a livello di cluster, la gestione dei backup dei file contenuti in GlusterFS va di conseguenza "ragionata". Proposta 1 (valida solo per volumi replicati): installo LVM su ogni peer del cluster stoppo eventuali servizi (lato client connesso al cluster) che potrebbero alterare il contenuto dei file presenti nel cluster stesso lancio una snapshot su di un peer qualsiasi riavvio i servizi (lato client connesso al cluster) lancio il backup andando a leggere i dati direttamente dalla snapshot distruggo la snapshot

GlusterFS... alcuni CONTRO Proposta 2: sfrutto la funzionalità di "Geo-replication" presente in GlusterFS per replicare in modo asincrono i dati su di un server esterno lancio una snapshot sul server esterno tramite LVM lancio il backup andando a leggere i dati direttamente dalla snapshot distruggo la snapshot

GlusterFS...continua Installare e configurare GlusterFS è estremamente semplice (almeno a partire dalle ultime versioni !!): - installare GlusterFS su ogni server peer - installare GlusterFS su ogni client che dovrà accedere ai dati resi disponibili dal cluster - definire quali saranno i server che entreranno a far parte del cluster - creare i volumi da un qualsiasi nodo del cluster (peer) - montare il cluster (tramite un semplice comando mount) sui client interessati

GlusterFS... alcuni PRO Tutti i server che compongono il cluster hanno gli stessi "poteri", non esiste potenzialmente un single point of failure Quanto scritto sopra è "verino" :-P dipende dal tipo di volume che andremo a gestire quando un peer NON è più disponibile (si pianta, esplode, si guasta la scheda di rete...) tutti i client connessi al cluster NON hanno più accesso al filesystem per N secondi (parametro configurabile) dopodiche il filesystem risulta nuovamente accessibile continua -->

GlusterFS... alcuni PRO ? quando un peer ritorna ad essere disponbile, ogni file modificato durante la "mancanza" del peer risulta non modificabile fino a che GlusterFS non allinea le varie versioni dei file.... se i file sono di dimensioni consistenti potrebbe essere un problema (es. KVM ?!? :-P ) Parlando con uno degli sviluppatori di GlusterFS, alla domanda "Is this type of behavior normal ?" la risposta è stata: No, that happens because Gluster's self heal is a blocking operation. We are working on a non-blocking self heal, we are hoping to ship it in early September 2011.

GlusterFS - tipologie di volumi REPLICATED: questo tipo di volume mi garantisce che tutti i file resteranno accessibili, in modo completamente trasparente, a fronte di un guasto di un peer: ho bisogno di 2 server da utilizzare come peer sul sito della comunity Gluster consigliano di utilizzare dischi della stessa dimensione su entrambe i nodi (eventualmente sfruttando LVM per dimensionare i logical volume opportunamente) simile ad un RAID1 o forse più a DRDB ?!?

GlusterFS - tipologie di volumi DISTRIBUTED: i file vengono sparsi a caso sui vari peer ho bisogno di 2 o più server da utilizzare come peer sul sito della comunity Gluster consigliano di utilizzare dischi della stessa dimensione su entrambe i nodi (eventualmente sfruttando LVM per dimensionare i logical volume opportunamente) CONTRO: se un peer non è più disponibile (es. guasto) l'intero volume risulta inaccessibile PRO - avrò maggiore spazio disco a disposizione (la somma degli N nodi)

GlusterFS - tipologie di volumi STRIPED: i file vengono divisi in strisce/pezzi e vengono sparsi a caso sui vari peer ho bisogno di 2 o più server da utilizzare come peer sul sito della comunity Gluster consigliano di utilizzare dischi della stessa dimensione su entrambe i nodi (eventualmente sfruttando LVM per dimensionare i logical volume opportunamente) CONTRO: se un peer non è più disponibile (es. guasto) l'intero volume risulta inaccessibile PRO - avrò maggiore spazio disco a disposizione (la somma degli N nodi) PRO - migliori prestazioni, sia in lettura che scrittura, su file di grosse dimensioni

GlusterFS - tipologie di volumi DISTRIBUTED REPLICATED: combina i pregi delle due soluzioni ho bisogno di almeno 4 server da utilizzare come peer (ogni successiva espansione richiede un numero di server PARI) PRO: se un peer non è più disponibile (es. guasto) il volume resta accessibile PRO - avrò maggiore spazio disco a disposizione (la somma degli N nodi / 2) PRO - migliori prestazioni, sia in lettura che scrittura

GlusterFS - tipologie di volumi DISTRIBUTED STRIPED: combina i pregi delle due soluzioni ma in questo caso anche i difetti ho bisogno di almeno 4 server da utilizzare come peer (ogni successiva espansione richiede un numero di server multiplo del valore utilizzato come stripe) CONTRO: se un peer non è più disponibile (es. guasto) il volume non è accessibile dai client PRO - avrò maggiore spazio disco a disposizione PRO - migliori prestazioni, sia in lettura che scrittura su file di grosse dimensioni

GlusterFS - Installazione Pacchetti necessari: aptitute install nfs-common aptitute install python dpkg -i ULTIMAVERSIONEDISPONIBILE.deb Moduli che devono essere caricati nel Kernel a runtime fuse (modprobe fuse e aggiungere fuse al file /etc/modules)

GlusterFS DEMO

GlusterFS - altre funzionalità interessanti Geo-Replication Easily Accessible Usage Quotas Advanced Monitoring Tools

ALCUNI STRUMENTI UTILI PER CAPIRE IL REALE CARICO DEI VOSTRI SERVER: atsar -d (per capire il "carico" sui dischi) vnstat -i ethX -l (per monitorare al volo il carico sulle schede di rete) iftop (per monitorare il traffico di rete) htop (per monitorare al volo il "carico" a livello di CPU) hdparm, dbench, iozone (per il monitoraggio delle prestazioni disco) ALCUNE NOTE RELATIVE A PROXMOX: - utilizzare SOLO file RAW, i file QCOW2 hanno prestazioni inferiori se utilizzati con GlusterFS - aggiungere cache=writeback per i dischi (altrimenti qemu NON riesce a far partire la macchina virtuale... sembra dipenda da una limitazione di FUSE)

Link utili / curiosi ! interview-with-glusters-anand-babu-periasamy