分散ストレージファイルシステム - すぐに使用できる製品はどれですか?

解決策 1:

残りの人と話すことはできませんが、「分散ストレージエンジン」と「分散ファイルシステム」を混同しているようです。それらは同じものではありません。同じものと間違われるべきではありません。決して同じものになることはありません。ファイルシステムは、ハードドライブのどこにあるのかを追跡する方法です。 Hadoop のようなストレージエンジンは、キーによって識別されるデータのチャンクを追跡する方法です。概念的には、それほど違いはありません。問題は、ファイルシステムがストレージエンジンに依存していることです...結局のところ、ブロックデバイスに書き込む方法が必要ですよね?

それはさておき、私はできます 本番環境での分散ファイルシステムとしての ocfs2 の使用について話します。ざらざらした詳細が必要ない場合は、次の行で読むのをやめてください。ちょっとクールですが、思ったよりもダウンタイムが長くなる可能性があります。

過去数年間、実稼働環境で ocfs2 を実行してきました。それは問題ありませんが、多くのアプリケーションには適していません。要件を実際に見て、それが何であるかを理解する必要があります。自分が思っていたよりも、障害に対する自由度がはるかに高いことに気付くかもしれません。

例として、ocfs2 には、パーティションをマウントしようとしているクラスター内の各マシンのジャーナルがあります。たとえば、4 台の Web マシンがあり、mkfs.ocfs2 を使用してそのパーティションを作成するときに、拡張の余地を与えるために合計 6 台のマシンがあると指定します。これらの各ジャーナルはスペースを占有するため、ディスクに保存できるデータの量が減少します。ここで、7 台のマシンにスケーリングする必要があるとします。そのような状況では、全体を削除する必要がありますクラスターを作成 (つまり、すべての ocfs2 パーティションをアンマウント) し、tunefs.ocfs2 ユーティリティを使用して追加のジャーナルを作成します (使用可能なスペースがある場合)。その後、7 台目のマシンをクラスタに追加し (ユーティリティを使用しない限り、残りのクラスタにテキストファイルを配布する必要があります)、すべてを元に戻し、7 台すべてにパーティションをマウントします。マシン。

私が何を意味するか分かりますか？それは「常にオンライン」を意味する高可用性であるはずですが、そこにはたくさんのダウンタイムがあります...そして、ディスクスペースが混雑していることを神は禁じています. ocfs2 を混雑させたときに何が起こるか見たくありません。

ocfs2 クラスターを管理するための「推奨される」方法であった evms は、clvmd と lvm2 を支持してドードー鳥の道を進んだことに注意してください。 (そして evms には良いことです。) また、openais/pacemaker スタックを支持して、heartbeat はすぐにゾンビプロジェクトに変わります。 (余談:ocfs2 の初期クラスター構成を行う場合、ハートビートではなく、クラスターエンジンとして 'pcmk' を指定できます。いいえ、これは文書化されていません。)

価値のあることとして、Pacemaker によって管理される nfs に戻りました。Pacemaker が nfs 共有を別のマシンに移行する際の数秒のダウンタイムまたはいくつかの tcp パケットのドロップは、基本的な場合に見られたダウンタイムの量と比較して取るに足らないものであるためです。 ocfs2 使用時のマシンの追加などの共有ストレージ操作。

解決策 2:

POSIX 要件を放棄する必要があると思います。それを実装しているシステムはほとんどありません。実際、NFS でさえ実際には実装しておらず (ロックなどを考えてください)、冗長性がありません。

同期レプリケーションを使用するシステムは、氷のように遅くなります。非同期レプリケーション (または「結果整合性」) を備えたシステムは、POSIX 規則に違反し、「従来の」ファイルシステムのようには動作しません。

解決策 3:

あなたの要件を誤解しているかもしれませんが、http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

を見たことがありますか?

解決策 4:

ここに私の €0.02 を投入します:OpenAFS はあなたが望むことを行うことができませんか?

解決策 5: