とハドゥープそしてカウチDBブログや関連ニュースでは、実際に機能する分散フォールト トレラント ストレージ (エンジン) について詳しく説明されています。
- CouchDB には実際には配布機能が組み込まれておらず、私の知る限り、エントリやデータベース全体を自動的に配布するための接着剤が欠けているだけです。
- Hadoop は非常に広く使用されているようです。少なくとも良い評判を得ていますが、それでも単一障害点があります。それは NameNode です。さらに、マウントできるのは FUSE 経由のみで、HDFS は実際には Hadoop の主な目的ではないと理解しています。
- グラスターFS共有なしの概念はありますが、最近いくつかの投稿を読んで、それほど安定していないという意見に至りました。
- 光沢専用のメタデータサーバーを使用しているため、単一障害点もあります。
- セフ選択されたプレーヤーのようですが、ホームページにはまだアルファ段階であると記載されています。
そこで疑問となるのが、どの分散ファイルシステムに次の機能セットがあるかということです (順不同)。
- POSIX互換
- ノードの追加/削除が簡単
- シェアードナッシングコンセプト
- 安価なハードウェア（AMD GeodeまたはVIA Edenクラスのプロセッサ）で動作します
- 認証/承認が組み込まれている
- ネットワークファイルシステム（異なるホストに同時にマウントできるようにしたい）
あった方がよい：
- ローカルでアクセス可能なファイル: ノードをダウンさせて、標準のローカルファイルシステム(ext3/xfs/その他)でパーティションをマウントし、ファイルにアクセスできます。
私はないホスト型アプリケーションを探しています。むしろ、各ハードウェア ボックスから 10 GB 程度のストレージを取得し、そのストレージをネットワークで利用でき、多数のホストに簡単にマウントできるようなものを探しています。
答え1
POSIX 要件を放棄する必要があると思います。それを実装しているシステムは非常に少なく、実際、NFS でさえ (ロックなどを考慮して) 実際には実装されておらず、冗長性もありません。
同期レプリケーションを使用するシステムは非常に遅くなります。非同期レプリケーション (または「最終的な一貫性」) を使用するシステムは POSIX ルールに違反し、「従来の」ファイルシステムのように動作しません。
答え2
残りのことについてはわかりませんが、あなたは「分散ストレージ エンジン」と「分散ファイル システム」を混同しているようです。これらは同じものではありません。同じものと間違えるべきではありませんし、同じものになることもありません。ファイル システムは、ハード ドライブ上の場所を追跡する方法です。Hadoop などのストレージ エンジンは、キーによって識別されるデータ チャンクを追跡する方法です。概念的には、大きな違いはありません。問題は、ファイル システムがストレージ エンジンに依存しているということです... 結局のところ、ブロック デバイスに書き込む方法が必要なのではないですか?
そんなことはすべてさておき、私はできる実稼働環境での分散ファイルシステムとしての ocfs2 の使用について説明します。細かい詳細を知りたくない場合は、次の行以降を読むのを止めてください。これはかなりクールですが、思ったよりもダウンタイムが長くなる可能性があります。
私たちは過去数年間、ocfs2 を実稼働環境で実行してきました。これは問題ありませんが、多くのアプリケーションには適していません。要件をよく検討して、それが何であるかを把握する必要があります。そうすると、思っていたよりもずっと多くの障害の許容範囲があることに気付くかもしれません。
たとえば、ocfs2 には、パーティションをマウントするクラスタ内の各マシンのジャーナルがあります。たとえば、4 台の Web マシンがあり、mkfs.ocfs2 を使用してパーティションを作成するときに、拡張の余地を残すために合計 6 台のマシンを指定するとします。これらの各ジャーナルはスペースを占有するため、ディスクに保存できるデータの量が減少します。ここで、マシンを 7 台に拡張する必要があるとします。その場合、全体クラスタをアンマウントし (つまり、すべての ocfs2 パーティションをアンマウントします)、空き領域がある場合は、tunefs.ocfs2 ユーティリティを使用して追加のジャーナルを作成します。その後、クラスタに 7 番目のマシンを追加し (ユーティリティを使用していない場合は、テキスト ファイルをクラスタの残りの部分に配布する必要があります)、すべてを元に戻し、7 台のマシンすべてにパーティションをマウントします。
私の言っている意味がおわかりですか? これは高可用性、つまり「常にオンライン」を意味するはずですが、実際にはダウンタイムが大量に発生します... また、ディスク領域が不足することは絶対に避けてください。ocfs2 を混雑させたときに何が起こるかは、見たくないはずです。
ocfs2 クラスターを管理する「推奨」方法であった evms は、clvmd と lvm2 に取って代わられ、絶滅の道をたどっていることに注意してください。(evms はもうおしまいです。) また、heartbeat はすぐにゾンビ プロジェクトに変わり、openais/pacemaker スタックに取って代わられるでしょう。(余談ですが、ocfs2 の初期クラスター構成を行うときに、heartbeat ではなく 'pcmk' をクラスター エンジンとして指定できます。いいえ、これは文書化されていません。)
参考までに、私たちは pacemaker によって管理される nfs に戻りました。これは、pacemaker が nfs 共有を別のマシンに移行するときに発生する数秒のダウンタイムや、いくつかの tcp パケットのドロップが、ocfs2 の使用時にマシンを追加するなどの基本的な共有ストレージ操作で発生していたダウンタイムの量と比較すると些細なことだからです。
答え3
あなたの要件を誤解しているかもしれませんが、http://en.wikipedia.org/wiki/List_of_file_systems#分散ファイルシステム