File system di archiviazione distribuito - Quale / Esiste un prodotto pronto per l'uso?

Con Hadoop e CouchDB dappertutto in Blog e notizie correlate, cos'è un motore di archiviazione (motore) tollerante ai guasti distribuito che funziona davvero.

• CouchDB in realtà non ha alcuna funzione di distribuzione integrata, per quanto ne sappia manca semplicemente la colla per distribuire automagicamente voci o addirittura interi database.
• Hadoop sembra essere molto usato - almeno ottiene una buona stampa, ma ha ancora un singolo punto di errore: il NameNode. Inoltre, è montabile solo tramite FUSE, capisco che HDFS non è in realtà l'obiettivo principale di Hadoop
• GlusterFS non ha un concetto condiviso, ma ultimamente ho letto diversi post che mi portano a ritenere che non sia così stabile
• Lustre ha anche un singolo punto di errore in quanto utilizza un server di metadati dedicato
• Ceph sembra essere il giocatore preferito, ma la homepage afferma che è ancora nelle sue fasi alfa.

Quindi la domanda è quale file system distribuito abbia il seguente set di funzionalità (nessun ordine particolare):

• POSIX-compatibili
• facile aggiunta / rimozione di nodi
• concetto di nulla condiviso
• funziona su hardware economico (processori AMD Geode o VIA Eden)
• autenticazione / autorizzazione integrata
• un file system di rete (vorrei poterlo montare contemporaneamente su host diversi)

Bello avere:

• file accessibili localmente: posso prendere un nodo giù montare la partizione con un file system locale standard (ext3 / xfs / qualunque ...) e comunque accedere ai file

Sto Non alla ricerca di applicazioni in hosting, piuttosto qualcosa che mi permetterà di prendere dire 10GB di ciascuna delle nostre caselle di hardware e avere quel archiviazione disponibile nella nostra rete, facilmente montabile su un gran numero di ospiti.

Penso che dovrete abbandonare il requisito POSIX, pochissimi sistemi lo implementano - in realtà anche NFS non lo fa davvero (pensa ai blocchi ecc.) E non ha ridondanza.

Qualsiasi sistema che utilizza la replica sincrona sarà glacialmente lento; qualsiasi sistema che abbia una replica asincrona (o "eventuale coerenza") violerà le regole POSIX e non si comporterà come un filesystem "convenzionale".

Non posso parlare con il resto, ma sembra che tu sia confuso tra un "motore di archiviazione distribuito" e un "file system distribuito". Non sono la stessa cosa, non dovrebbero essere scambiati per la stessa cosa e non saranno mai la stessa cosa. Un filesystem è un modo per tenere traccia di dove si trovano le cose su un disco rigido. Un motore di archiviazione come hadoop è un modo per tenere traccia di un blocco di dati identificato da una chiave. Concettualmente, non molta differenza. Il problema è che un filesystem è una dipendenza di un motore di archiviazione ... dopo tutto, ha bisogno di un modo per scrivere su un dispositivo a blocchi, vero?

A parte questo, posso parlare dell'uso di ocfs2 come filesystem distribuito in un ambiente di produzione. Se non vuoi i dettagli grintosi, smetti di leggere dopo questa riga: è abbastanza bello, ma può significare più tempi di inattività di quanto pensi.

Abbiamo eseguito ocfs2 in un ambiente di produzione negli ultimi due anni. Va bene, ma non è eccezionale per molte applicazioni. Dovresti davvero guardare alle tue esigenze e capire quali sono - potresti scoprire che hai molto più spazio per i guasti di quanto pensassi.

Ad esempio, ocfs2 ha un journal per ogni macchina nel cluster che monterà la partizione. Quindi supponiamo che tu abbia quattro macchine web e quando crei quella partizione usando mkfs.ocfs2, specifichi che ci saranno sei macchine in totale per darti un po 'di spazio per crescere. Ognuna di queste riviste occupa spazio, il che riduce la quantità di dati che è possibile archiviare sui dischi. Ora, supponiamo che sia necessario ridimensionare a sette macchine. In quella situazione, devi abbattere l' interocluster (ovvero smontare tutte le partizioni ocfs2) e utilizzare l'utilità tunefs.ocfs2 per creare un journal aggiuntivo, a condizione che sia disponibile spazio. Quindi e solo allora puoi aggiungere la settima macchina al cluster (che richiede di distribuire un file di testo al resto del cluster a meno che tu non stia utilizzando un'utilità), ripristinare tutto e quindi montare la partizione su tutte e sette macchinari.

Capito quello che intendo? Dovrebbe essere un'alta disponibilità, che dovrebbe significare "sempre online", ma proprio lì hai un sacco di downtime ... e dio ti proibisca di essere affollato per lo spazio su disco. NON vuoi vedere cosa succede quando affollate ocfs2.

Tieni presente che evms, che era il modo 'preferito' per gestire i cluster ocfs2, ha fatto la strada dell'uccello dodo a favore di clvmd e lvm2. (E buona manovra per gli evm.) Inoltre, il battito cardiaco si trasformerà rapidamente in un progetto di zombi a favore dello stack openais / pacemaker. (A parte: quando si esegue la configurazione iniziale del cluster per ocfs2, è possibile specificare 'pcmk' come motore del cluster anziché heartbeat. No, questo non è documentato.)

Per quello che vale, siamo tornati a nfs gestiti da pacemaker, perché i pochi secondi di downtime o alcuni pacchetti tcp rilasciati mentre pacemaker migra una condivisione nfs su un'altra macchina è banale rispetto alla quantità di downtime che stavamo vedendo per base operazioni di archiviazione condivisa come l'aggiunta di macchine quando si utilizza ocfs2.

Potrei fraintendere le tue esigenze, ma hai guardato http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Solo per buttare qui i miei € 0,02: OpenAFS non può fare quello che vuoi?

Dai un'occhiata a chirp http://www.cse.nd.edu/~ccl/software/chirp/ e parrot http://www.cse.nd.edu/~ccl/software/parrot/

Che ne dici di Xtreemfs ? la versione 1.4 (novembre 2012) è considerata Qualità di produzione.

È compatibile con POSIX e presenta un'eccezionale tolleranza automatica ai guasti.

Lustre consente di memorizzare più metadati in configurazione attiva / passiva per ridondanza, quindi nessun singolo punto di errore.

OCFS2 potrebbe anche valere la pena di essere visto.

Si noti che l'eliminazione dei requisiti per l'accesso simultaneo a più reti consente di passare a qualcosa come iSCSI o anche cifs o nfs. Il rovescio della medaglia è che devi "ritagliare" pezzi del tuo uberArray in morsi per ogni server che ha bisogno di spazio.

A meno che non sia per scopi accademici / di sviluppo, questo tipo di cose dovrebbe essere affrontato a partire dai requisiti generali per il progetto. La maggior parte dei filesystem distribuiti non è abbastanza matura per una distribuzione seria - per esempio, cosa fai se tutto si sfalda. Se è per scopi accademici / di sviluppo, questa è in realtà una buona cosa in quanto potresti imparare molto e correggere molti bug.

Il commento che chiede se hai davvero bisogno della semantica POSIX è un buon inizio. La semantica "filesystem" non POSIX può essere molto più flessibile, portando a sistemi molto più affidabili.

Se questa è un'applicazione legacy, mi chiedo davvero perché un moderno filesystem distribuito possa essere considerato la soluzione migliore.

Non fraintendetemi: sono giocattoli incredibilmente divertenti. Non vorrei essere responsabile di una complessa soluzione interdipendente che non è comunemente usata e sarebbe molto difficile da risolvere quando si sfalda.

Hai davvero, assolutamente positivamente bisogno della semantica POSIX? La vita diventa molto più semplice se puoi usare un archivio dati personalizzato. Abbiamo un archivio dati scritto internamente che è effettivamente un archivio di valori-chiave distribuito molto grande. Si memorizza un file in esso e si ottiene un token indietro. Se vuoi che il file venga restituito, dagli il token che ti è stato dato in precedenza. È distribuito, non è condiviso nulla, i dati vengono replicati tre volte, i nodi possono essere aggiunti e rimossi a piacimento, sia server di archiviazione che server di controllo.

Lustre ha anche un singolo punto di errore in quanto utilizza un server di metadati dedicato

Lustre è progettato per supportare il failover e un MDS / MDT / OSS può avere un numero di indirizzi a cui può essere contattato, il battito cardiaco può essere utilizzato per migrare il servizio.

Essere consapevoli del fatto che alcune versioni recenti hanno avuto problemi in cui lo smontaggio sembra funzionare ma ci sono ancora dati in volo sul disco, tuttavia la protezione a doppio montaggio avrebbe dovuto aiutare (a parte i problemi interessanti che ha avuto) ...

Ti consiglio di utilizzare MooseFS (tollerante ai guasti, ridimensionamento, file system distribuito in rete). È conforme a POSIX e dalla versione 1.6 MooseFS offre un'autenticazione / autorizzazione semplice, simile a NFS. Vedi anche i requisiti hardware .