3

非常に大きなサイズ (現実的には最大約 100 TB) に拡張する必要がある分散ファイル システムが必要です。ファイルサイズはほとんどが 10 ～ 1500 KB の範囲ですが、一部のファイルは約 250 MB でピークになる場合があります。

私は、GFS のようなシステムにバックアップ用の冗長性が組み込まれているという考えが非常に気に入っています。これにより、統計的に、ファイルの損失は過去のものになります。

いくつかの要件があります。

  • オープンソース
  • SPOF なし
  • 自動ファイル複製 (つまり、RAID は不要)
  • マネージド クライアント アクセス
  • ファイルのフラットな名前空間 - できれば
  • 組み込みのバージョニング / 遅延削除
  • 実証済みの導入

ほとんどの要件を満たしているため、MogileFS を真剣に検討しました。管理されたクライアントはありませんが、Java クライアントのポートを行うのはかなり簡単です。ただし、バージョン管理は組み込まれていません。バージョン管理がなければ、MogileFS に組み込まれているファイル レプリケーション以外に、通常のバックアップを行う必要があります。

基本的に、あるべきではない多くのファイルを突然パージするプログラミングエラーから保護する必要があります。MogileFS は X 個のデバイスにファイルを複製することで、ディスクとマシンのエラーから私を守ってくれますが、不当な削除を行った場合は救われません。

削除操作が実際に Y 日後まで有効にならないように指定できるようにしたいと考えています。削除は論理的に行われますが、実際に削除されるまで Y 日間ファイルの状態を復元できます。また、MogileFS には、書き込み中にディスクの破損をチェックする機能がありませんが、追加することもできます。

私たちは Microsoft ショップ (Windows、.NET、MSSQL) であるため、メンテナンスを容易にするためにコア部分を Windows で実行するのが最適であり、ストレージ ノードはライセンスのために *nix (またはその組み合わせ) を実行します。

自分でロールアップすることを検討する前に、何か提案はありますか? HadoopFS、OpenAFS、Lustre、GFS もチェックアウトしましたが、どちらも私の要件に一致していないようです。

4

3 に答える 3

1

これを独自のサーバーでホストする必要がありますか? 必要なものの多くは、Amazon S3 によって提供されます。遅延削除機能は、削除を SimpleDB テーブルに記録し、ガベージ コレクション パスを定期的に実行して、必要に応じてファイルを消去することで実装できます。

単一のインターネット接続に依存している場合でも、単一障害点が存在します。そしてもちろん、Amazon 自体が障害点であると考えることもできますが、規模が大きいため、障害率は常にはるかに低くなります。

また、その他の利点である任意の容量に拡張できることも理解していただければ幸いです。IT スタッフが故障したディスクやシステムを交換する必要はありません。ディスク容量と帯域幅が安くなるにつれて、使用コストは継続的に低下します (購入したディスクの価値は減価償却されます)。

ハイブリッド アプローチを採用して、S3 を安全なバックエンド アーカイブとして使用し、「ホット」データをローカルにキャッシュして、使用モデルに最適なキャッシュ戦略を見つけることも可能です。これにより、特にデータの変更頻度が低い場合に、帯域幅の使用量が大幅に削減され、I/O が改善されます。

欠点:

  • S3 上のファイルは不変であり、完全に置き換えるか削除することしかできません。これはキャッシングには適していますが、大きなファイルに小さな変更を加える場合の効率にはあまり適していません。
  • 遅延と帯域幅は、ネットワーク接続のものです。キャッシュはこれを改善するのに役立ちますが、同じレベルのパフォーマンスを得ることはできません。

バージョニングもカスタム ソリューションですが、SimpleDB と S3 を使用して実装し、ファイルの一連のリビジョンを追跡できます。全体として、これが適切かどうかはユースケースに大きく依存します。

于 2008-11-28T16:12:40.293 に答える
0

信頼できるファイル システム上でソース管理システムを実行してみてください。問題は、タイムアウト後に古いチェックインを消去する方法になります。DAV_SVN を使用して Apache サーバーをセットアップすると、DAV インターフェイスを介して行われた各変更がコミットされます。あなたが説明した大きなファイルサイズでこれがどれだけうまくスケーリングされるかはわかりません。

于 2008-11-28T15:52:15.123 に答える
0

@tweakt
私もS3を広く検討しましたが、長期的には満足できるものではないと思います. ファイル ACL ではなく、アプリケーション層を通じて安全に保存する必要があるファイルがたくさんあります。これは S3 を介して行うこともできますが、ファイル ストレージを少し制御できません。さらに、ファイル操作を行うときのレイテンシーの形で大きなマイナス面もあります。最初の保存 (非同期で行うこともできます) だけでなく、後でファイルを読み取って操作を実行する必要がある場合も同様です。

SPOF に関しては、それは実際には問題ではありません。データセンターへの冗長接続はありますが、SPOF は必要ありませんが、S3 で発生したわずかなダウンタイムは許容範囲内です。

無制限のスケーラビリティとメンテナンスの必要がないことは、間違いなく利点です。

ハイブリッドアプローチについて。S3 から直接ホストする場合 - いずれにせよすべてをローカルに保存する場合 (および S3 をバックアップとして使用する場合) を除き、S3 + CloudFront を追加すると帯域幅の価格が高すぎます (CloudFront は必要になるため)。全国からお客様がいらっしゃいます。）現在、ヨーロッパのデータセンターからすべてをホストしており、低予算の CDN 機能のために米国に独自のリバース イカをセットアップしています。

ドメインに大きく依存していますが、可変性は私たちにとって問題ではありません。ファイルを置き換える (つまり、キー X が新しいコンテンツを取得する) ことはありますが、ファイルにマイナーな変更を加えることは決してありません。すべてのファイルはブロブです。

于 2008-11-28T16:46:47.090 に答える