Řešení 1:
Nemohu mluvit se zbytkem, ale zdá se, že jste zmateni mezi „distribuovaným úložištěm“ a „distribuovaným souborovým systémem“. Nejsou totéž, neměly by být zaměňovány za stejnou věc a nikdy nebudou stejné. Souborový systém je způsob, jak sledovat, kde jsou věci umístěny na pevném disku. Úložný modul, jako je hadoop, je způsob, jak sledovat množství dat identifikovaných klíčem. Koncepčně žádný velký rozdíl. Problém je v tom, že souborový systém je závislostí úložiště... koneckonců potřebuje způsob, jak zapisovat do blokového zařízení, ne?
To vše kromě toho můžu mluvit o použití ocfs2 jako distribuovaného souborového systému v produkčním prostředí. Pokud nechcete znát drsné detaily, přestaňte číst po tomto řádku:Je to docela cool, ale může to znamenat více prostojů, než si myslíte.
Posledních pár let jsme provozovali ocfs2 v produkčním prostředí. Je to v pořádku, ale pro mnoho aplikací to není skvělé. Měli byste se opravdu podívat na své požadavky a zjistit, jaké jsou - možná zjistíte, že máte mnohem větší prostor pro chyby, než jste si mysleli.
Například ocfs2 má žurnál pro každý počítač v clusteru, který připojí oddíl. Řekněme tedy, že máte čtyři webové stroje, a když vytvoříte tento oddíl pomocí mkfs.ocfs2, určíte, že bude celkem šest strojů, abyste měli prostor pro růst. Každý z těchto žurnálů zabírá místo, což snižuje množství dat, která můžete uložit na disky. Nyní řekněme, že potřebujete škálovat na sedm strojů. V takové situaci musíte odstranit celý cluster (tj. odpojte všechny oddíly ocfs2) a použijte obslužný program tunefs.ocfs2 k vytvoření dalšího žurnálu za předpokladu, že je k dispozici místo. Teprve potom můžete přidat sedmý počítač do clusteru (což vyžaduje distribuci textového souboru do zbytku clusteru, pokud nepoužíváte nástroj), vše vrátit zpět a poté připojit oddíl na všech sedm stroje.
Víš co myslím? Má to být vysoká dostupnost, což má znamenat 'vždy online', ale právě tam máte spoustu výpadků... a nedej bože, že máte narváno místo na disku. NECHCETE vidět, co se stane, když naplníte ocfs2.
Mějte na paměti, že evms, které bývalo „preferovaným“ způsobem správy clusterů ocfs2, se vydalo cestou ptáka dodo ve prospěch clvmd a lvm2. (A dobré řešení pro evms.) Heartbeat se také rychle změní v zombie projekt ve prospěch openais/pacemaker stacku. (Ostatně:Když provádíte počáteční konfiguraci clusteru pro ocfs2, můžete zadat 'pcmk' jako jádro clusteru na rozdíl od prezenčního signálu. Ne, toto není zdokumentováno.)
Za to, co stojí za to, jsme se vrátili k nfs spravovaným kardiostimulátorem, protože několik sekund výpadku nebo několik zahozených tcp paketů při migraci kardiostimulátoru sdílení nfs na jiný počítač je triviální ve srovnání s množstvím prostojů, které jsme viděli u základních operace sdíleného úložiště, jako je přidávání počítačů při použití ocfs2.
Řešení 2:
Myslím, že se budete muset vzdát požadavku POSIX, jen velmi málo systémů to implementuje - ve skutečnosti ani NFS ve skutečnosti ne (think locks atd.) a to nemá žádnou redundanci.
Každý systém, který používá synchronní replikaci, bude ledově pomalý; každý systém, který má asynchronní replikaci (nebo "případnou konzistenci") poruší pravidla POSIX a nebude se chovat jako "konvenční" souborový systém.
Řešení 3:
Možná nerozumím vašim požadavkům, ale podívali jste se na http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems
Řešení 4:
Jen abych sem vhodil mých 0,02 €:nemůže OpenAFS dělat, co chcete?
Řešení 5:
Podívejte se na chirp http://www.cse.nd.edu/~ccl/software/chirp/ a papoušek http://www.cse.nd.edu/~ccl/software/parrot/