Soluzione 1:
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, no?
A parte questo, posso parla dell'uso di ocfs2 come filesystem distribuito in un ambiente di produzione. Se non vuoi i dettagli grintosi, smetti di leggere dopo questa riga:è piuttosto interessante, ma potrebbe 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 esaminare le tue esigenze e capire quali sono:potresti scoprire di avere molta più libertà per i difetti di quanto pensavi di avere.
Ad esempio, ocfs2 ha un journal per ogni macchina nel cluster che monterà la partizione. Quindi diciamo che hai 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. Ciascuno di questi journal occupa spazio, il che riduce la quantità di dati che è possibile archiviare sui dischi. Ora, supponiamo che tu debba ridimensionare a sette macchine. In quella situazione, devi smontare l'intero cluster (ovvero smontare tutte le partizioni ocfs2) e utilizzare l'utilità tunefs.ocfs2 per creare un journal aggiuntivo, a condizione che ci sia spazio disponibile. 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 tutti e sette macchine.
Capito quello che intendo? Dovrebbe essere ad alta disponibilità, che dovrebbe significare "sempre online", ma proprio lì hai un sacco di tempi di inattività ... e Dio non voglia che tu sia affollato per lo spazio su disco. NON vuoi vedere cosa succede quando affolli ocfs2.
Tieni presente che evms, che era il modo "preferito" per gestire i cluster ocfs2, ha fatto la fine dell'uccello dodo a favore di clvmd e lvm2. (E buona liberazione per evms.) 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 gestito da pacemaker, perché i pochi secondi di inattività o alcuni pacchetti tcp persi mentre il pacemaker migra una condivisione nfs su un'altra macchina è banale rispetto alla quantità di tempo di inattività che stavamo vedendo per base operazioni di archiviazione condivise come l'aggiunta di macchine quando si utilizza ocfs2.
Soluzione 2:
Penso che dovrai abbandonare il requisito POSIX, pochissimi sistemi lo implementano - in effetti anche NFS non lo fa davvero (pensa ai blocchi ecc.) E questo non ha ridondanza.
Qualsiasi sistema che utilizza la replica sincrona sarà glacialmente lento; qualsiasi sistema che abbia una replica asincrona (o "coerenza finale") violerà le regole POSIX e non si comporterà come un filesystem "convenzionale".
Soluzione 3:
Potrei fraintendere le tue esigenze, ma hai guardato http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems
Soluzione 4:
Giusto per buttare qui i miei 0,02€:OpenAFS non può fare quello che vuoi?
Soluzione 5:
Dai un'occhiata a chirp http://www.cse.nd.edu/~ccl/software/chirp/ e a parrot http://www.cse.nd.edu/~ccl/software/parrot/