28

非常に多くのオプションがあり、それらすべてをテストする時間はほとんどありません...誰かがビデオストリーミングとストレージ/エンコーディング用の分散ファイルシステムの経験があるのではないかと思います。

どこかに保存する必要のある巨大なビデオファイル（50GBから250GB）がたくさんあり、それらをmp4にエンコードして、いくつかのAdobeFMSサーバーからストリーミングすることができます。これをすべて処理する唯一の方法は分散ファイルシステムを使用することですが、問題はどれですか？

これまでの私の研究は私に教えてくれます：

  • 光沢：多くの大企業で使用されている成熟した実績のあるソリューションで、10Gを超えるファイルに最適なのはカーネルドライバーです。
  • Gluster：新しい、成熟度の低い、FUSEベース。つまり、インストールは簡単ですが、FUSEのオーバーヘッドのために遅くなる可能性があります。多数の小さなファイルを処理する方が良い〜1GB
  • MogileFS：小さなファイル〜MB専用のようですが、アクセスにHTTPを使用しますか？将来的にはFUSEバインディングの可能性があります。

これまでのところLustreが勝者のようですが、私が持っている特定のアプリケーションの実際の経験を聞きたいと思います。

また、Hadoop、Redhat GFS、Coda、Windows DFSがオプションとして聞こえるので、どんな経験でも歓迎します。誰かがベンチマークを持っているなら、共有してください。

いくつかの実際の経験の後、これは私が学んだことです：

  • 光沢：
    • パフォーマンス：驚くほど速い！Lusterは多くのストリームを提供でき、Lustreを介してファイルにアクセスしてもエンコード速度は影響を受けないと断言できます。
    • POXISの互換性：とても良いです！。光沢を使用するためにアプリケーションを変更する必要はありません。
    • レプリケーション、負荷分散、フェイルオーバー：非常に悪いです！。レプリケーションの負荷分散とフェイルオーバーについては、仮想IPやDRDBなどの他のソフトウェアに依存する必要があります。
    • インストール：最悪！単なる人間ではインストールできません。それを機能させるには、カーネル、光沢パッチ、および微調整の非常に特殊な組み合わせが必要です。また、現在の光沢パッチは通常、新しいハードウェア/ソフトウェアと互換性のない古いカーネルで機能します。
  • MogileFS：
    • パフォーマンス：小さなファイルには適していますが、中規模から大きなファイルには使用できません。これは主にHTTPオーバーヘッドが原因です。これは、すべてのファイルがbase64のすべてのデータをエンコードするHTTPリクエストを介して送受信され、各ファイルに33％のオーバーヘッドが追加されるためです。
    • POXIXとの互換性はありません。ほとんどのストリーミングサーバーとエンコードツールはMogileFSプロトコルを理解していないため、すべてのアプリケーションを変更して、ストリーミング/エンコードに使用できないmogilefを使用する必要があります。
    • レプリケーションとフェイルオーバーをすぐに使用でき、一度に複数のトラッカーにアクセスすることで、アプリケーションに負荷分散を実装できます。
    • インストールは比較的簡単で、すぐに使用できるパッケージがほとんどのディストリビューションに存在します。私が見つけた唯一の問題は、単一障害点を排除するためにデータベースのマスタースレーブを設定することでした。
      • Gluster：
    • パフォーマンス：ストリーミングには非常に悪い。10Gbpsネットワークで数Mbpsを超える速度に到達できません。大量の書き込みでクライアントとサーバーのCPUが急上昇します。ネットワークとI/Oの前にCPUが飽和しているため、エンコードは機能します。
    • POXIS：ほぼ互換性があります。私が使用するツールは、ディスク内の通常のフォルダーとしてglusterマウントにアクセスできますが、一部のエッジケースでは、問題が発生し始めます。glusterのメーリングリストを確認すると、多くの問題があることがわかります。
    • レプリケーション、フェイルオーバー、および負荷分散：最高です！彼らが実際に働いた場合。Glusterは非常に新しく、多くのバグとパフォーマンスの問題があります。
    • インストールが簡単すぎます。管理コマンドラインは素晴らしく、複数のサーバー間で複製、ストライプ、および分散されたボリュームを設定することは、これ以上簡単なことではありません。

最終結論：

残念ながら、結論は「単一の特効薬はない」です。

現在、ストレージとトランスコーディング用に複製されたボリュームにGluster3.2のメディアファイルがあります。サーバーの数が少ない限り、ジオレプリケーションやストライプボリュームは問題なく機能します。

メディアファイルをストリーミングするときは、DR：DBを介して2番目の光沢ボリュームに複製される光沢ボリュームにそれらをコピーします。次に、wowzaサーバーは光沢ボリュームからメディアファイルを読み取ります。

そして最後に、MogileFSを使用してWebアプリケーションサーバーでサムネイルを提供します。

4

5 に答える 5

5

GlusterFSは、これまでに大幅に改善されました。彼らは現在、大きなファイルに「きめ細かいロック」を提供しています。ここを参照してください：http ：//www.gluster.org/community/documentation/index.php/WhatsNew3.3 また、ビデオのフレームレートにも大きく依存します。4Kレートまで上がらない場合は、Glusterでストレージの問題を解決できます。スピードに対する大きな要求がある場合、したがって、Infinibandが参加することができます。

于 2012-10-02T12:36:16.243 に答える
2

Hadoop ファイルシステム (HDFS) を確認してください。その焦点は、非常に大きなファイルと並列タスク コンピューティング (map/reduce を使用) であり、待ち時間は長くなりますが、スループットは非常に高くなります。現在、Facebook や amazon.com などの大規模なインストールで使用されています。

于 2009-10-06T17:51:58.607 に答える
2

MogileFS は、そのようなことに最適です。クライアント ライブラリの品質は多少異なりますが、ほぼすべての言語を使用してアクセスする大規模な運用サイトがなければ、私は驚くでしょう。

HTTP は、実際にこのようなものに適したプロトコルです。機能豊富で効率的な HTTP クライアントを持っていないのは誰ですか?

于 2009-10-31T04:13:54.110 に答える
1

Map-reduceは、書き込み/読み取りの比率が90/10の場合には役立ちません。一定のファイルサイズは良いことであり、ファイルは小さいです。したがって、MogileFSはLustre / Glusterとして適切な代替手段のように思われます。つまり、キャッシュの状況は適切ではありません。

于 2009-11-03T08:59:21.937 に答える
1

指定されたシステムのうち、最も適しているのは MoglieFS です。

しかし、おそらく、特別なシステムがまったくなくてもやり遂げることができます。4 つの Adob​​eFMS サーバーがあるとします。

{video0.exmple.com,video1.exmple.com,video2.exmple.com,video3.exmple.com}.

次のような単純なスキームを使用して、これら 4 つのサーバー間ですべての動画を配信できます。

    /*
     *  pseudo code
     */

    $server_id = get_server_id(filename);
    ...
    ...
    int function get_server_id(filename) 
    { 
       return hash(filename) mod 4;
    }

動画をエンコードした後、アプリは

$server_id = get_server_id(file_name)
copy file_name to /mnt/$server_id/

クライアントはhttp://videoN.example.com/filename.mp4のようなものを使用してビデオにアクセスします。ここで、N は を使用してファイル名から計算されますget_server_id()。

光沢/光沢は、実際に探しているものではありません。Lustre FS はより成熟していますが、開発者はそのような FS 上のファイルを「キャッシュ」として扱うように求めています。つまり、ファイルはいつでも失われる可能性があります。

Luster/Gluster は HPC で使用することを目的としており、単一のストレージ サーバーがパフォーマンスのボトルネックになることなく、大量のデータに高速にアクセスできます。これらのシステムのもう 1 つのポイントは、それらが POSIX 準拠であることです。HPC/科学研究環境では、新しいクールで高速な FS をインストールしたため、通常、アプリを書き直すための時間はありません。

于 2009-09-01T01:16:15.067 に答える