分散ストレージファイルシステム-すぐに使用できる製品はどれですか？
Hadoop と CouchDB を使用すると、ブログや関連ニュースのすべてで、実際に機能する分散フォールトトレラントストレージ（エンジン）とは何ですか。
- CouchDBには実際には配布機能が組み込まれていません。私の知る限り、エントリを自動的に配布するための接着剤や、データベース全体でさえ機能していません。
- Hadoopは非常に広く使用されているようです-少なくともそれは良い評判を得ますが、それでもNameNodeという単一の障害があります。さらに、それはFuse経由でのみマウント可能です。HDFSは実際にはHadoopの主な目的ではないことを理解しています
- GlusterFS は何も共有しないという概念を持っていますが、最近、私はいくつかの投稿を読んで、それほど安定していないという意見を導きました
- Lustre は、専用のメタデータサーバーを使用するため、単一障害点もあります。
- Ceph は最適なプレーヤーのようですが、ホームページにはまだアルファ段階にあると記載されています。
したがって、問題は、どの分散ファイルシステムに次の機能セットがあるかです（特定の順序はありません）。
- POSIX互換
- ノードの簡単な追加/削除
- シェアードナッシングのコンセプト
- 安価なハードウェア（AMD GeodeまたはVIA Edenクラスプロセッサ）で実行されます）
- 認証/承認ビルトイン
- ネットワークファイルシステム（異なるホストに同時にマウントできるようにしたい）
あった方がよい：
- ローカルでアクセス可能なファイル：ノードをダウンさせて、標準のローカルファイルシステム（ext3/xfs/whatever ...）でパーティションをマウントし、ファイルにアクセスできます。
私はではありませんホストされているアプリケーションを探しています。むしろ、たとえば各ハードウェアボックスの10GBを取得し、そのストレージを複数のホストに簡単にマウントできるネットワーク。
私はあなたがPOSIX要件を放棄する必要があると思います、それを実装しているシステムはほとんどありません-実際、NFSでも実際には（ロックなどを考えていません）冗長性はありません。
同期レプリケーションを使用するシステムは、氷河期に遅くなるでしょう。非同期複製（または「結果整合性」）を持つシステムは、POSIXルールに違反し、「従来の」ファイルシステムのようには動作しません。
残りはお話しできませんが、「分散ストレージエンジン」と「分散ファイルシステム」の間で混乱しているようです。それらは同じものではなく、同じものと間違えられるべきではありません、そしてそれらは決して同じものになることはありません。ファイルシステムは、ハードドライブ上のどこにあるかを追跡する方法です。 hadoopのようなストレージエンジンは、キーによって識別されるデータのチャンクを追跡する方法です。概念的には、それほど大きな違いはありません。問題は、ファイルシステムがストレージエンジンに依存していることです...結局のところ、ブロックデバイスに書き込む方法が必要ではないでしょうか。
それはさておき、私は できる 本番環境での分散ファイルシステムとしてのocfs2の使用について説明します。ざらざらした詳細が必要ない場合は、この行の後で読むのをやめてください。それはちょっとクールですが、思ったよりもダウンタイムが長くなる可能性があります。
私たちは過去2年間、運用環境でocfs2を実行しています。大丈夫ですが、多くのアプリケーションには適していません。あなたは本当にあなたの要件を見て、それが何であるかを理解する必要があります-あなたはあなたが思ったよりもはるかに多くのフォールトに対して寛容性があることに気付くかもしれません。
例として、ocfs2には、パーティションをマウントするクラスター内の各マシンのジャーナルがあります。たとえば、4台のWebマシンがあり、mkfs.ocfs2を使用してそのパーティションを作成する場合、合計6台のマシンが存在することを指定して、拡張する余地を確保します。これらのジャーナルはそれぞれ領域を占有するため、ディスクに保存できるデータの量が減少します。ここで、7台のマシンにスケーリングする必要があるとしましょう。そのような状況では、あなたは 全体 クラスター（つまり、すべてのocfs2パーティションをアンマウント）し、tunefs.ocfs2ユーティリティを使用して追加のジャーナルを作成します（利用可能なスペースがある場合）。その後、7番目のマシンをクラスターに追加し（ユーティリティを使用している場合を除き、テキストファイルをクラスターの残りの部分に配布する必要があります）、すべてを再起動し、7つすべてにパーティションをマウントします。マシン。
どういう意味？それは「常にオンライン」を意味するはずの高可用性であるはずですが、そこにはたくさんのダウンタイムがあります...そして、ディスク領域が混雑していることを禁じています。 ocfs2に群がったときに何が起こるかを知りたくありません。
Ocfs2クラスターを管理するための「推奨」方法であったevmsは、cldodとlvm2を支持してdodo birdの道を進んだことを覚えておいてください。 （そしてevmsへの良いリダンダンス。）また、ハートビートはすぐにゾンビプロジェクトに変わり、openais/pacemakerスタックを支持します。 （余談：ocfs2の初期クラスター構成を行う場合、ハートビートではなく「pcmk」をクラスターエンジンとして指定できます。いいえ、これは文書化されていません。）
価値があるのは、ペースメーカーがnfs共有を別のマシンに移行するときに数秒間のダウンタイムまたはいくつかのTCPパケットがドロップするため、ペースメーカーが管理するNFSに戻ったからです。 ocfs2使用時のマシンの追加などの共有ストレージ操作。
ここに私の€0.02を投げるだけです： OpenAFS したいことはできませんか？
私はあなたの要件を誤解しているかもしれませんが、あなたは http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems を見ましたか？
Xtreemfs はどうですか？バージョン1.4（2012年11月）は製品品質と見なされます。
POSIX互換で、優れた自動フォールトトレランスを備えています。
Lustreでは、冗長性のためにアクティブ/パッシブ構成で複数のメタデータストアを使用できるため、単一障害点はありません。
OCFS2も一見の価値があります。
複数の同時ネットワークアクセスの要件を取り除くことで、iSCSIやcifsやnfsなどに切り替えることができることに注意してください。欠点は、スペースを必要とするサーバーごとに、uberArrayの一部をバイトに「切り分ける」必要があることです。
アカデミック/開発を目的としない限り、プロジェクトの全体的な要件から始めて、この種のアプローチを行う必要があります。ほとんどの分散ファイルシステムは、本格的な導入には十分に成熟していません。たとえば、全体が不安定になった場合はどうしますか。アカデミック/開発を目的とする場合は、多くのことを学び、多くのバグを修正できるため、これは実際には良いことです。
POSIXセマンティクスが本当に必要かどうかを質問するコメントは、良いスタートです。非POSIXの「ファイルシステム」セマンティクスは、はるかに柔軟になり、システムの信頼性が大幅に向上します。
これがレガシーアプリケーションである場合、なぜ最新の分散ファイルシステムが最適なソリューションであると考えられるのか疑問に思います。
誤解しないでください。これらは驚くほど楽しいおもちゃです。私は、一般的に使用されていない複雑な相互依存ソリューションの責任を負いたくないだけなのです。
本当に、ポジティブにPOSIXセマンティクスが必要ですか？カスタムデータストアを使用できれば、人生はずっと楽になります。非常に大規模な分散Key-Valueストアである、内部的に書き込まれたデータストアがあります。その中にファイルを保存し、トークンを取り戻します。ファイルを元に戻したい場合は、前に与えたトークンを与えます。分散され、何も共有されず、データは3回複製され、ノードはストレージサーバーと制御サーバーの両方で自由に追加および削除できます。
Lustreは、専用のメタデータサーバーを使用するため、単一障害点もあります。
Lustreはフェイルオーバーをサポートするように設計されており、MDS/MDT/OSSは、接続可能な多数のアドレスを持つことができ、ハートビートを使用してサービスを移行できます。
最近の一部のバージョンでは、マウント解除が機能しているように見える問題がありましたが、まだディスクに転送中のデータがあります。