JP4663718B2 - ブロックマップキャッシングおよびｖｆｓスタック可能なファイルシステムモジュールに基づく分散型のストレージアーキテクチャ - Google Patents

Description

本出願は、２００４年７月２１日付けで出願された米国仮出願第６０／５８９，５７８号、発明の名称「Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｔｏｒａｇｅ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｂａｓｅｄ ｏｎ Ｂｌｏｃｋ Ｍａｐ Ｃａｃｈｉｎｇ ａｎｄ ＶＦＳ Ｓｔａｃｋａｂｌｅ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｍｏｄｕｌｅｓ」、及び２００４年７月２３日付けで出願された仮出願第６０／５９０，４３１号、発明の明細「Ａ Ｓｃａｌａｂｌｅ Ｓｔｒｅａｍｉｎｇ Ｖｉｄｅｏ Ｓｅｒｖｅｒ Ｃｏｍｐｌｅｘ Ｂａｓｅｄ ｏｎ Ｔｉｅｒｅｄ Ｃａｃｈｉｎｇ」に優先権を主張するものであるが、この参照によってこれら全体が本明細書に組み込まれる。

本開示は、ビデオデータのストリーミング等のデータ配信のための分散型ストレージシステムに関するものである。

本明細書において開示される内容に関連する背景情報は、以下の引用文献に記載される。

Ｅ．Ｚａｄｏｋらの「Ｅｘｔｅｎｄｉｎｇ Ｆｉｌｅ Ｓｙｓｔｅｍｓ Ｕｓｉｎｇ Ｓｔａｃｋａｂｌｅ Ｔｅｍｐｌａｔｅｓ」（Ｐｒｏｃ．１９９９ ＵＳＥＮＩＸ Ａｎｎｕａｌ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆ．，Ｊｕｎｅ １９９９）、 Ｄ．Ｒｏｓｅｎｔｈａｌの「Ｅｖｏｌｖｉｎｇ ｔｈｅ Ｖｎｏｄｅ Ｉｎｔｅｒｆａｃｅ」（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｓｕｍｍｅｒ ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．１０７−１１７，Ｊｕｎｅ １９９０） Ａ．Ｄａｎらの「Ｂｕｆｆｅｒ Ｍａｎａｇｅｍｅｎｔ Ｐｏｌｉｃｙ ｆｏｒ ａｎ Ｏｎ−Ｄｅｍａｎｄ ｖｉｄｅｏ ｓｅｒｖｅｒ」（ＩＢＭ Ｒｅｓｅａｒｃｈ Ｒｅｐｏｒｔ ＲＣ １９３４７） Ａ．Ｄａｎらの「Ｂｕｆｆｅｒｉｎｇ ａｎｄ Ｃａｃｈｉｎｇ ｉｎ Ｌａｒｇｅ−ｓｃａｌｅ ｖｉｄｅｏ ｓｅｒｖｅｒｓ」（Ｐｒｏｃ．Ｃｏｍｐｃｏｎ，ｐｐ．２１７−２２４，Ｍａｒｃｈ １９９５）、及び、 Ｍ． Ｂａｒらの「Ｌｏｎｇ−ｔｅｒｍ Ｍｏｖｉｅ Ｐｏｐｕｌａｒｉｔｙ Ｍｏｄｅｌｓ ｉｎ Ｖｉｄｅｏ−ｏｎ−Ｄｅｍａｎｄ Ｓｙｓｔｅｍｓ」（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＣＭ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．３４９−３５７，Ｎｏｖｅｍｂｅｒ １９９７）

ビデオサーバの複合体で用いられる共有ストレージシステムは、キャッシュされたブロックマップの概念に基づくことができる。前記システムは、分散型ファイルシステムのオーバヘッドと複雑さを減らすと同時に、複数のビデオサーバによってサーバ複合体の共有ストレージプールからのアセットを協同してストーリミングできるようにしてもよい。前記システムは、アセットの共通プールがビデオサーバ上のローカルファイルのように見えるようにし、且つ、ユーザに意識させないで、ストリーミング読出しリクエストをファイバーチャネルストレージエリアネットワーク（ＳＡＮ）等のストレージエリアネットワーク（ＳＡＮ）を通じて前記ストレージデバイスに再誘導できるようにしてもよい。

さらに、高度に拡張可能なビデオサーバの複合体は、階層キャッシングの概念に基づいてことができる。前記システムは、多数のビデオサーバが分散型複合体中の共有ストレージプールからアセットを協力してストリームできるようにしてもよい。前記システムは、ストレージ帯域幅、ストレージ容量およびストリーミング帯域幅をエンドユーザーの要件に関連付けできるようにしてもよい。

１実施形態によれば、データストリーミング用の分散型ストレージシステムは、コントローラと、第１および第２のコンピュータと、第１および第２スイッチと、ストレージデバイスを含む。前記第１のコンピュータは、ローカルファイルシステムを含み、前記第１のストレージデバイス上にアセットファイルを格納するために前記ローカルファイルシステムを使用する。更に、前記第１のコンピュータは、アセットファイルが前記第１のストレージデバイスに格納される場所の境界に関する情報を含み、ブロックマップを作るプロセスを使用する。ブロックマップは、各アセットファイル用に作成する。

別の実施形態によれば、階層キャッシュシステムが、デジタルアセットのストリーミング用に使用される。このタイプのシステムの典型的な実装は、前記アセットを格納する３次キャッシュメモリと、３次キャッシュに連結した複数のビデオポンプとを含む。各ビデオポンプは、前記３次キャッシュメモリから前記アセットのコピーを受け取り１つ以上のストリームを発信する２次キャッシュメモリと、前記２次キャッシュメモリからの前記アセットのコピーを受け取り、複数のストリームを発信する１次キャッシュメモリとを含む。前記システムは、また、前記アセットをストリームするために、前記複数のビデオポンプのうちから１つのビデオポンプを選択するリソースコントローラを有する。

図１は、データのストリーミングが可能な分散型のストレージシステムの１実施形態を示すものである。図示されるように、前記システムは、コントローラ１０と、第１のコンピュータ１２および第２のコンピュータ１４と、第１及び第２のスイッチ１６および１８と、ストレージデバイス２０とを含む。前記第１のコンピュータ１２は、アセットファイルを前記第１のストレージデバイス２０上のローカルファイルシステムに格納するために使用可能なローカルファイルシステム１２Ｂを含む。更に、前記第１のコンピュータ１２は、プロセス１２Ａを使用して、各アセットファイルのためのブロックマップを作成する。ブロックマップは、前記第１のストレージデバイス２０中でのアセットファイルの格納場所の境界に関する情報を含む。

前記プロセス１２Ａは、前記第２のコンピュータ１４に連結した第２のストレージデバイス１４Ａ上に前記ブロックマップのコピーを格納する。図示するように、前記第２のコンピュータ１４は、また、前記第１のストレージデバイス２０に連結する。

更に、前記システムは仮想ファイルシステム１４Ｂを含み、これにより前記第２のコンピュータ１４が前記ストレージデバイス１４Ａに格納されているブロックマップのコピーを使用して、前記第１のストレージデバイス２０上にある前記アセットファイルにアクセスするのを可能にする。

前記第１のコンピュータがアセットファイルを保存するときに、ブロック配置アルゴリズムが前記第１のコンピュータ１２のローカルファイルシステムによって使用され、複数ローカルファイルシステムブロックが連続的に書き込まれる。更に、前記スイッチ１８は、前記第１のコンピュータ１２と、前記第２のコンピュータ１４と、前記ストレージデバイス２０の間で並行のノンブロッキングアクセスを提供する。前記プロセス１２Ａは、前記アセットファイルの位置へのポインタを含む「ヒントファイル」（後述）を作成する。

第１のストレージデバイス上に格納された第１のファイルからデータを読み込む方法は、ブロックマップを第２のファイルに格納する工程を含むものであるが、前記ブロックマップは論理ブロックアドレスのリストを含み、且つ前記リスト中の各論理ブロックアドレスは前記第１のファイルに保存するために使用されるセクタを識別する。この方法は、前記第１のファイルと関連する仮想ファイルからデータを読み込むためのシステムコールを発行する工程と、前記データと関連する論理ブロックアドレスを取り出す工程と、前記の関連論理ブロックアドレスを使用して前記第１のストレージデバイスからデータを読み込む工程とを含む。

前記の例示的システムの別の観点は、デジタルアセットのストリーミング用の階層キャッシュシステムに関係する。この種のシステムの典型的な実施形態では、アセットを格納する３次キャッシュメモリを含む。例えば、これは図１のストレージデバイス２０が可能である。更に、前記典型的なシステムは、前記３次キャッシュメモリに連結する１若しくはそれ以上のビデオポンプ（例えば第２のコンピュータ１４）を含む。ここで、ビデオポンプは、前記３次キャッシュメモリからの前記アセットのコピーを受け取り、１つ以上のストリームを出す２次キャッシュメモリ１４Ａ（第２のストレージデバイス）と、前記２次キャッシュメモリから前記アセットのコピーを受け取り複数のストリームを出す１次キャッシュメモリ１４Ｃと、前記複数のビデオポンプから前記アセットをストリームするビデオポンプを選択するリソースコントローラ（例えばコントローラ１０）とを含む。

分散型ストレージアーキテクチャ
図１Ａは、拡張可能なビデオサーバ複合体の例示を目的とした実施形態を示すものである。このような複合体は、リソースコントローラ１０と、若干のコンテンツライタ１２と（これの１つまたは複数が１若しくはそれ以上のファイルシステムを管理してもよい）、若干のビデオポンプ１４を含む。コンポーネントの一部または全てが、イーサネットおよびファイバーチャネルスイッチ１６および１８を通じて、相互接続してもよい。前記ファイバーチャネルスイッチ１８は、ビデオポンプ１４と、コンテンツライタ１２と、前記ストレージアレイ２０との間で並行のノンブロッキングアクセスを提供する。

コンテンツライタ１２は、外部ファイバーチャネルストレージアレイ２０からの１若しくはそれ以上のファイルシステムボリュームを管理する。前記ストレージ２０は、ローカルファイルシステムとして前記コンテンツライタ１２上に載置してもよい。前記システムは、前記複合体の他のいかなるコンポーネントも直接ファイルシステムを取り付けず、前記アーキテクチャによってビデオポンプ１４がそれがあたかもローカルの各ビデオポンプ上に取り付けられているかのように、前記ストレージ２０からストリームできるように構成してもよい。１若しくはそれ以上の前記ファイルシステムは、ＲＡＩＤストレージアレイ上に存在する単一のＬＵＮ（論理単位番号）を含む。

インジェスト、または、アセットのロードは前記コンテンツライタ１２によって実行される。インジェストされているアセットは、前記コンテンツライタのローカルファイルシステムに書き込まれる。前記リソースコントローラ１０は、ファイルシステム全体でのアセット配信を誘導し、アセットが前記ストレージアレイ間で均等に且つランダムにロードされることを確保する。

複合体中のコンテンツライタ１２の数ｃは、必要とされる合計インジェスト容量によって決定される。各コンテンツライタは固定された最大インジェスト容量を有するので、ｃは単に、前記複合体で所望される合計インジェスト容量を各コンテンツライタの容量で割った数である。

ビデオポンプ１４の数、ｖは、前記複合体から供給されるストリームの数によって決定されるもので、単に、所望されるストリーム合計数を各ビデオポンプの容量で割った数である。

ストレージアレイ２０の数、ｓは、（１）最大ストレージ容量要件、（２）特殊な、またはキャッシュされない、前記複合体のストリーミング必要条件、及び／又は（３）各アレイで利用可能な帯域幅によって決定される。任意の時間においてもっとも多量にロードされるアレイにかかる最大のロード率を高確率で決定するには統計技術を使用する。

ブロックマップキャッシング
共有ストレージアーキテクチャは、前記ビデオポンプ１４が前記コンテンツライタのローカルファイルシステムからストリームするのを可能にする。それは、ブロックマップ（ｂｍａｐ）キャッシング機構を使用して行われるが、これにより前記コンテンツライタ１２が前記ビデオポンプ１４にアセットデータブロックの場所を知らせることで可能になる。これにより、前記ビデオポンプ１４は、前記ファイバーチャネルスイッチ１８を通じて直接データブロックを読み込み、且つこれらからストリームできるようになる。前記システム中の１若しくはそれ以上のアセット用のブロックマップはそのアセットの存続期間の間、１若しくはそれ以上のビデオポンプ上のローカルファイルシステムでキャッシュされる。各々のビデオポンプで実行されるコンテンツｓｙｎｃｈｅｒプロセスは、前記ブロックマップキャッシュが前記コンテンツライタ１２上のアセットの状態と一致した状態にあることを確保する。前記ビデオポンプ上のアセット用のブロックマップおよびヒントファイルを常時キャッシュすることにより、コンテンツライタ障害の際にストリーミングの続行を可能にする。

ＢＣＦＳ（ブロックマップキャッシュシステム）と呼ばれる新規なファイルシステム層は、ストリーミングの間、アプリケーションに気づかれることなく、ブロックマップからアセットデータへのルックアップを実行する。前記アセットに加えて、ヒントファイルがストリーミングのために必要とされる。前記ヒントファイルは、前記インジェストプロセスの間、前記コンテンツライタのローカルストレージ上で生成されてもよい。前記ヒントファイルは、前記ｂｍａｐｓと一緒に前記ビデオポンプ１４に伝搬され、前記アセットの存続期間中、ローカルファイルシステムで同様に格納される。あるいは、前記ヒントファイルの前記ブロックマップはビデオポンプ１４に伝搬されてもよく、それにより、前記ファイルは前記アセットに対するのと同じ様式でアクセス可能になり、より少ないローカルストレージとネットワークリソースを必要とするが、アセットインジェストの間に前記ヒントファイルデータが必要とされる場合は追加の遅れの原因となる。

ブロックマップキャッシュファイルシステム（ＢＣＦＳ）
ＢＣＦＳは、トランスペアレントなインタフェースをユーザーレベルのアプリケーションに提供する、薄型ファイルシステム層で、これにより、３次ストレージ上のアセットを、まるでローカルにあるかのように、オープンし、そこからストリームすることを可能にする。

ＢＣＦＳは、ファイルストアではない。つまり、いかなるディスク上のデータ構造も実行しないことを意味する。これは、下にあるＵＦＳファイルシステムを使用して全アセットブロックとヒントファイルを維持する。

ＢＣＦＳは、スタック可能なｖｎｏｄｅインタフェースの概念に基づいてもよい（参照文献：Ｅ．Ｚａｄｏｋらの「Ｅｘｔｅｎｄｉｎｇ Ｆｉｌｅ Ｓｙｓｔｅｍｓ Ｕｓｉｎｇ Ｓｔａｃｋａｂｌｅ Ｔｅｍｐｌａｔｅｓ」（Ｐｒｏｃ．１９９９ ＵＳＥＮＩＸ Ａｎｎｕａｌ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆ．，Ｊｕｎｅ １９９９）。仮想ノードまたはｖｎｏｄｅは、前記ファイルシステムネームスペースに現れるオープンファイルやディレクトリのような構成要素を表すためにＵｎｉｘカーネル内で使用されるデータ構造であってもよい。前記ｖｎｏｄｅは、基礎にあるオペレーティングシステムの物理的特性とは独立していてもよい。前記ｖｎｏｄｅインタフェースは、より高レベルのモジュール用に、ｖｎｏｄｅｓ上のオペレーションを実行するための一定方法を提供する。前記仮想ファイルシステム（ＶＦＳ）は、前記ｖｎｏｄｅインタフェースを含む共通ファイルシステムコードを実行する。

前記ｖｎｏｄｅインタフェースは、スタッキングとして公知の概念をサポートするものであるが、ここでファイルシステム機能は、１つのｖｎｏｄｅインタフェース実装が別のものを呼び出すことを可能にすることによりモジュール化する。Ｖｎｏｄｅのスタッキングにより、複数のファイルシステム実装を存在させ、順番に各々を呼び出すことが可能になる。スタック可能なｖｎｏｄｅの実装において、前記スタックのあるレベルでのオペレーションは、前記スタック中のすぐ下位のレベルで、同じオペレーションを起動させてもよい。

図２は、ユーザーのｒｅａｄ（）呼び出しが、どのように、ＢＣＦＳによって取り扱われるＶＦＳのｒｅａｄ操作へと変換できるかを示す。ステップ１〜３は、ユーザープロセスが出した前記ｒｅａｄが、ＶＮＯＤＥ層にパスされて、ｂｃｆｓに出されるのを表す。ステップ４〜６では、ＶＮＯＤＥ層を通じて、再帰的なｒｅａｄを出すことにより、Ｂｃｆｓ＿ｒｅａｄがアセットのｂｍａｐファイルから前記ｂｍａｐを読み込む。次に、ＢＣＦＳは、前記ｂｍａｐを解釈して、前記３次ストレージデバイス上の所望データブロックの場所を決定する。ステップ７は、ｂｃｆｓが前記解釈済みｒｅａｄを３次ストレージに対して直接出し、結果を返すのを表す。

ＢＣＦＳを設計するにあたって下記の考慮点がある。
１．安定コードへの変更は最低限に抑える。
新規なファイルシステム層を導入することによって、ストリーミングアプリケーションは、修正なしに共有ヒントファイルおよびアセットにアクセス可能になる。
２．キャッシュされたブロックマップとヒントファイル用に永続的な格納を提供する。
これは、前記ブロックマップキャッシュのＲＡＭ要件を減らし、システム再起動を通じでブロックマップが持続されるようにし、３次ストレージ上のアセットの存続期間中、アセットブロックマップがビデオポンプ１４に保持されるのを可能にする。
３．ビデオポンプ１４とコンテンツライタ１２間のバッファキャッシュの一貫性。
未加工のメタデータの代わりにブロックマップを使用したアセットに共有アクセスを提供することにより、モードだけ共有された場合に起こるかもしれないキャッシュ一貫性の問題を回避することができる。
４．ビデオポンプ１４およびコンテンツライタ１２間のタイミング要件。
アクティブにインジェストしているコンテンツからストリームしている場合、ヒントファイルへの変更は、迅速に前記コンテンツライタから前記ビデオポンプに通知する必要がある。前記ヒントファイルデータがディスクに同期化するまで待機してから、それを読み込むことは許容外の遅延をもたらすことになる。

ＦＦＳファイルシステムは共有ファイルシステムにならないように実装してもよい。たとえば、これは、単一のサーバ読込みまたは書込みマウント済みストレージがあると仮定する。この仮定に基づくと、そのバッファキャッシュにｉｎｏｄｅおよび間接ブロックメタデータをキャッシュすることが可能になる。ファイルシステムメタデータがアセットファイルの書き込みまたは削除の結果として変更された場合、このキャッシュを他のサーバと同期化させるためのメカニズムは存在しない。アセットのメタデータがサーバＡでキャッシュされて、サーバＢが前記アセットに書き込むことにより前記メタデータを変更した場合、サーバＡは新規メタデータは認識しない。概念的にはバッファキャッシュ同期化をＦＦＳに加えることは可能であるが、そうすることにより前記ファイルシステムコンポーネントを複雑にし、潜在的に不安定にする。ブロックマップの伝搬は、全てのサーバにブロックマップの現在の状態を公開することによってキャッシュ一貫性の問題を回避する。この方法は、ｂｍａｐ通信のオーバーヘッドのために、汎用共用ファイルシステムではよく機能しない可能性がある点に注意する。しかし、下記の特徴：（１）アセット毎に単一のライター、（２）アセットは一度書き込まれ、何回もストリームされる、（３）アセットブロックサイズが大きいためにコンパクトなｂｍａｐ表示になる、を有するビデオポンプ複合体においてたいへん効率的である。

ＶＦＳスタックは、前記ＢＣＦＳ層を既存の下位層にマウントすることによって設定可能である。たとえば、ｍｏｕｎｔ−ｔ ｂｃｆｓ／ｌｏｃａｌｆｓ／ａｓｓｅｔｓ／ｃａｃｈｅにより、マウント位置「／ａｓｓｅｔｓ／ｃａｃｈｅ」でブロックキャッシュファイルシステム／ｌｏｃａｌｆｓをマウントする。「／ａｓｓｅｔｓ／ｃａｃｈｅ」中のファイルへの全アクセスは、前記ＢＣＦＳモジュールを通過して、前記ブロックマップおよびヒントファイルのコピーを含む下位ローカルファイルシステムにパスされる。前記ブロックマップファイルは、３次ストレージ上の遠隔ファイルの代理の役割をする。コンテンツｓｙｎｃｈｅｒプロセスは、ローカルブロックマップファイルが前記３次ストレージ上の実際のアセットファイルの名前と同じになるように（または任意に「．ｂｍａｐ」の拡張子を有する）設定する。

ＶＦＳ実装の１実施例として、この例示的ＶＦＳの実装では、前記ローカルファイルではなくてリモートストレージ上のアセットのリストを示す。これは汎用共用ファイルシステムのための重要な機能であるかもしれないが、ｂｃｆｓは、最小のオーバーヘッドでアセットへの共有アクセスを高効率で提供する事に関する問題を特に対処するために設計されている。分散型のディレクトリサービスを提供することは、前記ｂｍａｐファイル（または関係する構造）が前記共有ストレージ上のディレクトリエントリ及びｉｎｏｄｅを記載しているメタデータにアクセスするために十分な情報を必要とする場合がある。前記ビデオポンプ１４にこの情報を伝搬することは、キャッシュ一貫性を維持し、付加オーバーヘッドを加えるものをロックする準備が必要となる。より重要なことは、これらのメタデータアクセスが前記ストレージアレイ２０によるサービス用のアクセスのストリーミングと競争し、それによりストリーミングパフォーマンスの質を下げる可能性があることである。単純な１ｓのコマンドから生成されるｒｅａｄの急増によりストリーム配信に混乱を生じさせる場合がある。設計では、ストリーミングの間に、ＶＰによってストレージアレイ２０に出される唯一のリクエストは、前記ストリームデータ用のみであり、メタデータのためであることは一切ない。

ブロックマップ定義
このセクションでは実施形態によって、ブロックマップまたはｂｍａｐの用語が意味するものを説明する。図３に示すように、ディスクに格納されたアセットは、ブロックと呼ばれる一連の隣接するセクタを含む。ファイルシステムのブロック配置ポリシーによって、ブロックは隣接して配置または、ディスクのアドレス空間の全域でなんらかの方法で分散される。

ブロックは、その論理ブロックアドレス（ＬＢＡ）および長さによって完全に指定可能である。その場合、ブロックマップは一連のブロックであるが、ＬＢＡおよび長さがブロックを識別するために用いられる。

ディスクドライブから高いレベルの処理能力を達成するために、ブロックサイズは、大きなデータ転送でのシーク（ディスクヘッドをブロックの開始へ移動すること）と待ち時間（データが前記ディスクヘッドの下にくるまでプラッタが回転するのを待つ）のコストを清算するために大きい必要がある。ファイバーチャネルディスクドライブの現世代の場合、５１２Ｋから２ＭＢまでの範囲のブロックサイズにより、隣接するデータ上での駆動維持可能な処理能力の５０％〜８０％が提供される。

単一の３２ビットＬＢＡおよび１６ビット長は、ファイバーチャネルデバイス上のブロックを記載するのに十分であるので、アセットサイズのそのブロックマップのサイズに対する比率は最高で（ブロックサイズ／６）：１に等しい。
１．ブロックが前記ファイルシステムによって連続配置される場合は、ブロックマップのサイズは更に縮小可能である。

１ＭＢの連続ブロック配列に基づくと、アセットサイズおよびブロックマップサイズ間の比率は、１６７，０００：１であり、可能な限りＦＦＳがブロックを連続して配置するので通常更にずっと小さい。たとえば、１ＧＢのアセット用のブロックマップは、最高でも６ＫＢである。

前記ファイルシステムのブロックサイズは、前記ストレージアレイによって決定されず、むしろ、前記ビデオポンプ上で実行されるファイルシステムによって決定される。前記ストレージアレイは、論理ブロックアドレス（ＬＢＡ）を使って作動し、ここで、ＬＢＡによって参照される各ブロックは通常５１２バイト（デバイスの「セクターサイズ」）である。前記ファイルシステムは、ファイルシステムブロックサイズの単位でデータブロックのアドレス指定を行う。ＦＦＳ用の最大ファイルシステムブロックサイズは、６４Ｋである。これは、処理能力目標を達成するのに十分な大きさではないので、前記ファイルシステムブロックが確実に前記アセットブロックサイズの倍数単位で連続して配置されるように前記ファイルシステムのブロック配置アルゴリズムを修正してもよい。フラグメンテーションの問題を避けるために、単一のアセットブロックサイズを特定ファイルシステム中の全アセット用に使用してもよい。

ブロックマップファイル形式
このセクションは、ｂｍａｐファイルのサンプル形式を記載する。前記ｂｍａｐファイルは、ヘッダとその後にブロックディスクリプタのリストを含んでもよい。

ヘッダ
前記ｂｍａｐファイルヘッダは、バージョン番号および前記ストレージデバイスのＳＣＳＩ ターゲットおよびのＬＵＮ ＩＤを含んでもよい。

「ディスクスライス」は、ドライブを別々の領域または「スライス」に分割可能にするパーティションに類似するＦｒｅｅＢＳＤの概念である。スライスにより、サーバが複数のオペレーティングシステムをブートできるようになる。各々のＯＳは、別々のスライス中に存在する。１スライス内で、複数のパーティションが定義されてもよく、ここで各パーティションは、論理ディスクに相当する（「ａ：」、「ｂ：」、「ｃ：」…等）。３次ストレージをフォーマットする際、特定の定義済スライスとパーティションを使用してもよいが、前記スライスとパーティションは前記ｂｍａｐヘッダに入れて、ハードコーディングの仮定をさけ、３次ストレージ構成に柔軟性を持たせる。

ＬＵＮは、どのストレージアレイＲＡＩＤデバイスから読むべきかを識別するためにｂｃｆｓによって必要とされる可能性があるので、前記ｂｍａｐヘッダであってもよい。ストレージアレイＲＡＩＤデバイス内において、物理ドライブ間でストライプされるブロックは、ビデオポンプに対して集合的に１つ（またはそれ以上の）ＬＵＮとして表される。ビデオポンプは複数のＬＵＮｂを使用する場合があるので、前記ｂｍａｐヘッダのＬＵＮ ＩＤがどのＲＡＩＤデバイスから読み込むかを識別できると有益である。

ブロックディスクリプタ
ブロックディスクリプタは、ディスク上の単一の連続データブロックの位置とサイズを定義する。論理ブロックアドレス（ＬＢＡ）および、ｆｓ−ブロックサイズの倍数である長さが、ブロックの位置を定義する。

ＢＣＦＳを使用したアセットキャッシング
前記ｂｍａｐファイルはアセットがロードされる時にコンテンツライタ１２上に生成される。前記ビデオポンプ１４上のコンテンツｓｙｎｃｈｅｒは、／ａｓｓｅｔｓ／ｃａｃｈｅ上の前記ｂｍａｐファイルが前記コンテンツライタ上のファイルに対して最新であることを確保にする。ストリームがビデオポンプに割り当てられる際、あたかもアセットがローカルに格納されるかのように、前記ストリーミングサーバプロセスは前記アセットをオープンし、ファイルから読み込む。

前記ストリーミングアプリケーションがアセットデータ用にＶＯＰ＿ＲＥＡＤ読出しリクエストを生成すると、ｂｃｆｓ＿ｒｅａｄは次に前記ファイルからブロックマップおよびデバイス情報を読み込んで、前記アセットのデータが存在する論理ブロックアドレスを決定し、ｂｃｆｓ＿ｒｅａｄは、次に必要に応じて前記データ用に１若しくはそれ以上の読込みリクエストを出して復帰する。

アセットがコンテンツライタ１２から除去されたあと、ビデオポンプ１４上のコンテンツｓｙｎｃｈｅｒは／ａｓｓｅｔｓ／ｃａｃｈｅ／ａｓｓｅｔｎａｍｅ中の該当ｂｍａｐファイルを削除する。この時に、前記コンテンツｓｙｎｃｈｅｒは、２次ローカルディスクキャッシュから前記アセットも消す。

ＢＣＦＳを使用したヒントファイルキャッシング
ヒントファイルは、「トリックモード」（例えば早送り、巻戻し）を実行するためのアセットメタデータを含む。前記ヒントファイルは、アセットがストレージへロードされるときに、ソフトウェアによってビデオポンプ上に生成されてもよい。それらは、アセットの特定の場面へのポインタを含む。

ヒントファイルは、ｂｍａｐファイルと同様に取り扱われてもよい。前記ヒントファイルは、アセットがロードされる時に、前記コンテンツライタ上に生成されてもよい。ビデオポンプ上のコンテンツｓｙｎｃｈｅｒは、／ａｓｓｅｔｓ／ｃａｃｈｅ中にある前記ヒントファイルがコンテンツライタ上のファイルに対して最新であることを確保する。ストリームがビデオポンプに割り当てられると、前記ヒントファイルはローカルにキャッシュされているので、ストリーミングサーバは次に前記ヒントファイルを開き、これを使用することができる。

あるいは、アセットがインジェストされる際に、前記アセットのストリーミングの待ち時間要件が許可するならば、前記ヒントファイル用のブロックマップを前記ビデオポンプ上でキャッシュしてもよい。前記ヒントファイルデータ用の読出しリクエストは上記に説明されるａｓｓｅｔ ｒｅａｄと同様にｂｃｆｓによって処理されてもよい。

階層キャッシング
上述したように、前記マルチサーバ複合体のビデオポンプ１４は、３階層のコンテンツストレージおよびキャッシングを使用する。階層キャッシングの目的は、２つあるが、まず、アセットストレージ帯域幅からストリーミング帯域幅を切り離すことである。前記キャッシュの追加によって、「ホットスポット」またはアレイ間でのロードの不均衡を回避することができる。アセットの人気度にばらつきがあるため、キャッシングなしでは特定ストレージアレイから要求されるストリームの数が不均等になるのでロードの不均衡が容易に発生可能である。もう１つは、アセットの人気度の多様さを利用して、最も経済的なメディアタイプから、異なる人気度のアセットからのストリームを供給することにより、ストリーム毎のコストを減らすことである。たとえば、人気度が高い単一のアセットはＲＡＭから供給されるのが最も費用効率がよいのは、これのストレージ要件は低いが、帯域幅要件が高いからである。アクセスの頻度が低いコンテンツの大きなライブラリは、ストレージ容量が高いが帯域幅要件が低い安価な低速ハードドライブから供給されるのが最も費用効果が高い。階層キャッシングの実装により、現時点におけるアセットの人気度に基づいて最も経済的なメディアからアセットが動的および自動的に供給される。

１次システムは、最も人気がある比較的少数のアセットが供給されるローカルＲＡＭを含む。２次は、最も最近にアセットの全体がストリームされたものを格納する大型のローカルディスクキャッシュを含む。２次キャッシュは、複製およびファイルシステムを持たない未処理のブロック−レベルストレージであってもよい。１次および２次は、両方とも「格納及び転送」タイプのキャッシュである。３次は、適度なストリーミング容量を有する大型の長期ストレージであり、任意時にリクエストされる固有ストリームの最高数に略一致する必要がある。

図４および図５は、ストリーム配信が３つのキャッシュ階層全体でどのように分散可能であるかを示す。ストリーム配信のためにビデオポンプ１４をインテリジェントに選択することによって、前記リソースコントローラ１０は、１若しくはそれ以上のサーバに接続されたキャッシュ階層全体でこのストリーム配信に近づける。前記リソースコントローラ１０は、ビデオポンプ１４全体でストリームを配信することによって２次ディスクキャッシュの帯域幅限度が超過されないことを確保するために使用してもよく、各ビデオポンプがキャッシュ可能およびキャッシュ不可能なアセットのバランスの取れたミックスが配給されるようにする。前記リソースコントローラ１０は、１若しくはそれ以上のビデオポンプ１４と、それらに関連したビューワストリームの現在の特性を監視して、特定のアセットに関連した新規ビューワストリームをどのビデオポンプに割り当てるかを決定する。このような方法で、前記複合体の帯域幅リソースは、グローバルに最適化される。

図４において、ｕ_３は３次ストレージから読み込まれたアセット数であるが、そのためにちょうど１つのストリームが存在するものである。これらのアセット読取りの場合、ストリーム数ｎ３は３次階層から読み込まれたアセットの数に等しい。ｕ_２＋ｕ_１は、３次ストレージから読み込まれたアセット数でそのために複数のストリームが存在するものを表す。これらのストリームのために、前記２次キャッシュは帯域幅増幅器のような作用をするが、それは、前記２次キャッシュに入る各アセット読取りに対して、複数のビューワストリームが出てくるからである。前記の数、ｎ_２＋ｎ_３は、複数ビューワと一緒に２次キャッシュから出てくるストリームの数の合計を表す。ｎ_２は２次キャッシュから直接出るもので、１次キャッシュに転送されないビューワストリームの数である。２次キャッシュから出てくるビューワストリームは、前記２次キャッシュに入ってくるアセット読取りまたは同じアセットの他のビューワストリームと同期ではないのは、前記キャッシュ時間が各ビューワストリームを移動させるからである。前記１次キャッシュアルゴリズムは、高度にキャッシュ可能な、前記ｕ_２＋ｕ_１ストリーム中のサブセットｕ_１を選択し、これらのストリームを１次ＲＡＭキャッシュに誘導する。前記２次キャッシュと同様、１次キャッシュでは前記１次レベルでキャッシュされるストリームから複数のストリームが出る。数ｎ_１は、２次または３次ストレージからのいかなる追加Ｉ／Ｏ帯域幅も使用しない１次キャッシュから出てくるストリームの合計数である。前記サーバによって提供されるストリームの合計数は、ｎ_１＋ｎ_２＋ｎ_３である。３次ストレージから要求される合計帯域幅は、ｕ_１＋ｕ_２＋ｕ_３である。図５は、これらのパラメータをＩＰ２１６０ビデオポンプ用の標準値に関連付けるものであるが、この標準値はビデオの人気度に関連付けられたｚｉｐｆｉａｎのアセット人気分布によって予測されるものであり、Ｍ． Ｂａｒらによる、「Ｌｏｎｇ−ｔｅｒｍ Ｍｏｖｉｅ Ｐｏｐｕｌａｒｉｔｙ Ｍｏｄｅｌｓ ｉｎ Ｖｉｄｅｏ−ｏｎ−Ｄｅｍａｎｄ Ｓｙｓｔｅｍｓ」（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＣＭ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ．３４９−３５７，Ｎｏｖｅｍｂｅｒ １９９７）に開示されるものであるが、参照によって本明細書に組み込まれる。

前記２次ローカルディスクキャッシュ増幅効果に加えて、３次ストレージからのアセット読込みは、以前にすでに読み込まれて２次キャッシュにまだ存在するため、必要でない可能性がある。これがどれ程頻繁に起こるかは、３次キャッシュの合計ストレージサイズに対する２次キャッシュの合計サイズの比率によって決定することができる。この比率は、ディスクキャッシュヒット率（ＤＨＣＲ）と呼んでもよい。

１次ＲＡＭキャッシュ
このセクションでは、１次ＲＡＭキャッシングのアルゴリズムの可能な１実装を概説する。このアルゴリズムについては、拡張可能なサーバ複合体をサポートするためにどのように前記１次キャッシュが他のキャッシュ階層と連動して作動するかを示すためにここで説明する。

インターバルキャッシングは、サーバ処理能力を向上させるために能率的にキャッシュ可能な一時的に関連付けられストリームのセグメントを識別するバッファ管理手段である。前記アルゴリズムは、Ａ．Ｄａｎらの「Ｂｕｆｆｅｒ Ｍａｎａｇｅｍｅｎｔ Ｐｏｌｉｃｙ ｆｏｒ ａｎ Ｏｎ−Ｄｅｍａｎｄ ｖｉｄｅｏ ｓｅｒｖｅｒ」（ＩＢＭ Ｒｅｓｅａｒｃｈ Ｒｅｐｏｒｔ ＲＣ １９３４７）において記載されるもので、参照によって本明細書に組み込まれる。サーバコストの削減に関連するアルゴリズム処理能力は、Ａ．Ｄａｎらの「Ｂｕｆｆｅｒｉｎｇ ａｎｄ Ｃａｃｈｉｎｇ ｉｎ Ｌａｒｇｅ−ｓｃａｌｅ ｖｉｄｅｏ ｓｅｒｖｅｒｓ」（Ｐｒｏｃ．Ｃｏｍｐｃｏｎ，ｐｐ．２１７−２２４，Ｍａｒｃｈ １９９５）において記載されるが、参照によって本明細書に組み込まれる。インターバルは、同じアセットに対する、時間がオーバーラップする一対の連続したストリームリクエストとして定義可能である。インターバルキャッシングによって、前記１対の後方のストリームはキャッシュから提供可能になるが、その際、即時キャッシュ要件は、ストリーム開始時間のオフセットによって表されるデータサイズに等しい。前記ストリームの開始時間が近い場合、大きな節約となる。これは、インターバルキャッシングアルゴリズムによって、全てのインターバルのソートされたリストが維持され、最小のキャッシュ要件でインターバルのセットにキャッシュが割り当てられることにより達成される。

図６は、インターバルキャッシングの１例を示す。ストリームＡは、時間０に前記サーバから要求される。少し時間が経過した後で、且つストリームＡが完了する前に、ストリームＢが要求される。ストリームＡおよびＢは同じアセットを再生しているので、インターバルが形成される。前記オーバーラップＡによって表されるデータ量は計算され、前記インターバルは、インターバルのソートされたリストに挿入される。前記インターバルのために十分なキャッシュメモリがある場合は、そのインターバルに割り当てられ、前記ストリームＢの陰影部分はすべてキャッシュから供給される。

静的アセット複製と比較すると、インターバルキャッシングはキャッシュメモリをより効率的に利用し、事前にアセットの人気度を把握する必要も手動のアセット複製も必要としない。トリックモードのストリームは、前記トリックモードによって呼び出される可変インターバル関係のため、１次キャッシングには関与しないが、要求されたデータが偶然１次キャッシュにある場合は、１次キャッシュヒットから益をえることができる。

２次ローカルディスクキャッシュ
前記２次キャッシュの目的は、アセットが外部ストレージ２０から読み込まれる際にこれらのアセット全てをキャッシュすることにより、アセットストレージ帯域幅をストリーミング帯域幅から切り離すことである。それは、複製およびファイルシステムを有さない未加工のブロックレベルストレージとして管理される大型ローカルドライブアレイを含んでもよい。それは、「格納及び転送」タイプのキャッシュでもよく、すなわち、前記キャッシュコンテンツは前記ブロックが読み込まれるにつれて書き込まれ、前記保存操作は、外部ストレージからのデータフローに影響を与えないものである。ＩＰ２１６０メディアサーバ（Ｍｉｄｓｔｒｅａｍ Ｔｅｃｈｎｏｌｏｇｉｅｓ）において、たとえば、前記２次キャッシュは、前記内部ドライブ・アレイの一部に内在する。

前記２次ローカルディスクキャッシュは、構造の点で１次インターバルキャッシュに類似するものでもよい。前記ビデオポンプが、キャッシュされたストリームに対してＲＥＡＤを出すと、すなわち、前記ストリームが外部ストレージから要求されると、前記ブロックは、前記２次キャッシュ中の割当ブロックにコピーされ、ディスク上のファイルのブロックを前記キャッシュブロックにマップするハッシュテーブルエントリが生成される。前記ビデオポンプがＲＥＡＤを出す前に、前記ブロックがローカルディスクキャッシュに存在するかどうかを見るために前記ハッシュテーブルを確認してもよい。もしそうならば、前記ブロックは３次ディスクデバイスの代わりに前記キャッシュブロックから読み込まれる。

リソースコントローラのオペレーション
前記ストリームサービスリクエストを処理するためにビデオポンプ１４を選択する際、前記リソースコントローラ１０は前記アセットをすでにキャッシュに有する可能性が最も高いサーバを検索するが、前記複合体中のリソースの最適な利用を行うために前記複合体中の別のサーバにリクエストを送る場合がある。たとえば、単一の非常に人気があるアセットが１ビデオポンプの１次ＲＡＭキャッシュから供給され、このアセットを要求しているビューワストリームの数が、前記ビデオポンプの帯域幅ストリーミング容量を飽和させているとする。この場合、前記ビデオポンプは、３次外部ストレージインタフェースまたは内部２次ディスクドライブを利用しないので、結果として、これらの階層から発せられる大域ストリーム・ロードのよい高いパーセンテージは前記複合体の他のビデオポンプ１４に置かれることになる。ビデオポンプ上の２次ローカルキャッシュディスク帯域幅には限度があるので、他のビデオポンプ１４上にキャッシュされたストリームの結果として生じた増加は、これらの２次ディスク帯域幅を上回り、実質的に前記複合体がサポートできるストリームの数を制限する可能性がある。前記複合体の全体としての処理能力を最大にするために、図５において示されるような比率で、キャッシュ可及びキャッシュ不可のアセットのバランスのとれたミックスが、各ビデオポンプで維持される必要がある。

前記リソースコントローラ１０によって使用される比較的単純な１アルゴリズムによって効果的にこのバランスを維持することができる。各ビデオッポンプの動的キャッシュ状態を記載する前記リソースコントローラおよびビデオポンプ１４間の通信を最小にするために、且つ、そのような情報を格納しなければならないことを避けるために、前記リソースコントローラは、要求されたアセットごとに１エントリを有するテーブルを格納し、どのビデオポンプが前記アセットからのビューワストリームを供給したかを示す。短い時間間隔で配置されたストリームにおいてキャッシュは最も能率的なので、最後にアセットを供給したビデオポンプ１４に新規のストリームを誘導するとキャッシュの有効利用になる。更に、前記リソースコントローラは、各ビデオポンプで現在有効なストリーム数のカウントを維持する。このカウントが設定されたしきい値を上回ると、前記ストリームは最少のストリーミング帯域幅ロードを有するビデオポンプに誘導される。このメカニズムにより、人気度が高いアセットがビデオポンプ１４全体で分配されるのが確保され、人気度が高い任意のアセットにおいても過剰な数のストリームが１つのビデオポンプで処理されないようにする。これは、ビデオポンプ１４全体のストリーミングロードも分散する。

要約すると、前記ストリームロード平衡化アルゴリズムの例示的実装では、以下のステップを含む。
１．ストリームリクエストが、リソースコントローラ１０にとどく。
２．前記リソースコントローラ１０は、どのビデオポンプ１４が最後に該当アセットを配信したかを判定する。
３．どのビデオポンプ１４も前記アセットを配信していない場合は、前記リソースコントローラ１０は最も使用可能なストリーミング帯域幅を有するビデオポンプに、前記リクエストを誘導する。
４．そうではなく、ビデオポンプ１４が見つかった場合は、前記リソースコントローラ１０は、前記ビデオポンプ上のこのアセットの現在有効な計数が定義済みのしきい値未満であるかどうかを確認する。

ａ．前記しきい値を上回らない場合、前記リソースコントローラ１０は最後のビデオポンプに前記リクエストを誘導する。または、
ｂ．前記しきい値を上回った場合、前記コントローラ１０は、最も使用可能なストリーミング帯域幅を有するビデオポンプに前記リクエストを誘導する。

結論
請求項は、本明細書において開示された例示の実施形態に限定されるものではない。
たとえば、ブロックマップキャッシング及びＶＦＳスタック可能ファイルシステムモジュールに基づく分散型のストレージアーキテクチャ、更に、階層キャッシングに基づく拡張可能なストリーミングビデオ・サーバ複合体の前述の開示では、コンテンツライタ、ビデオポンプ、コントローラなどの用語が使用されるが、それらは本出願の保護範囲を制限するためであると、または本明細書で記載される前記システム、デバイスおよび方法は開示された前述の特定の方法および装置に限定されることを意味すると、解釈されるべきではない。さらに、当業者によって理解されるように、本明細書で開示される多くの発明の観点は、ストリーミングメディアまたはビデオ・オン・デマンド以外の目的のために使用されるコンピュータシステムにおいても適用可能である。同様に、本発明は、上述されたような、ＶＦＳスタック可能ファイルシステムモジュールおよび／またはブロックマップを使用するシステム、または、特定タイプのコンピュータ、プロセッサ、スイッチ、ストレージデバイス、メモリ、アルゴリズム、その他を使用したシステムに限定されるものではない。前記コンテンツライタ、ビデオポンプ、リソースコントローラ等は、基本的にはプログラム可能なコンピュータであり、本明細書で開示された発明の概念から逸脱することなしに様々な形式を取り得るものである。デジタル処理、ネットワークおよびストレージ機能の急速なコスト低下により、前記システムの発明のオペレーションを変更することなしに、例えば、特定機能用の処理と格納を本明細書で記載された機能要素の１つから別の機能要素に移すことが容易に可能である。多くの場合、本明細書において記載されている実装箇所（すなわち機能要素）は、単に設計者の好みであって、厳密な必要条件ではない。したがって、それらが明白に限定されない限り、保護の範囲が上述された特定の実施形態に限定されるべきものではない。

図１は、分散型ストレージ複合体の１実施形態を概略的に図示する。 図１Ａは、図１において示されるシステムのマルチサーバ配置の１つを概略的に図示する。 図２は、ブロックキャッシュファイルシステム（ＢＣＦＳ）の読取り操作の１例を図示する。 図３は、典型的なブロックマップを図示する。 図４は、１次および２次キャッシュの増幅効果の１例を図示する。 図５は、キャッシュ階層間のストリーム配信の１例を図示する。 図６は、インターバルキャッシングの１例を図示する。

Claims (34)

1. アセットファイルからデータをストリーミングするための分散型ストレージシステムであって、
   前記分散型ストレージシステムは、
   第１のストレージデバイスと、
   該第１のストレージデバイスに結合され、前記アセットファイルを前記第１のストレージデバイスに書き込み、前記アセットファイル用の第１のブロックマップを前記第１のストレージデバイスに書き込み、及び前記アセットファイルに関連付けられたヒントファイルを前記第１のストレージデバイスに書き込み、該ヒントファイル用の第２のブロックマップを前記第１のストレージデバイスに書き込むように構成された前記第１のコンピュータであって、前記ヒントファイルは前記アセットファイル中の位置へのポインターを少なくとも１つ有するものである、第１のコンピュータと、 第２のストレージデバイスと、 前記第１のストレージデバイス、前記第１のコンピュータ及び前記第２のストレージデバイスに結合された複数の第２のコンピュータと、
   前記第１のコンピュータ及び前記第２のコンピュータに結合され、前記アセットファイルに対するストリーミングのリクエストを受け取り、複数の前記第２のコンピュータのうちの１つを選択し、前記第２のコンピュータのうちの該選択された１つに前記ストリーミングのリクエストを送信するように構成されたリソースコントローラと、
   を有し、
   前記第１のコンピュータは前記第１及び第２のブロックマップのコピーを前記第２のストレージデバイスに格納するよう更に構成され、
   各前記第２のコンピュータは、前記第１及び第２のブロックマップのコピーを前記第１のストレージデバイス上の対応するアセットファイルの名前及び対応するヒントファイルの名前に関連するように設定するよう構成され、
   各前記第２のコンピュータは、前記第１及び第２のブロックマップの前記コピーを用いて、前記第１のストレージデバイス上の前記アセットファイルにアクセスするよう構成された仮想ファイルシステムを有し、
   前記仮想ファイルシステムは、スタック可能な仮想ノードインターフェース及び少なくとも１つの仮想ノードを有する、
   ことを特徴とする分散型ストレージシステム。
2. 請求項１記載の分散型ストレージシステムにおいて、前記第１のブロックマップは、前記第１のストレージデバイス中の前記アセットファイルが格納されている場所の最初および最後の位置に関する情報を含むものである。
3. 請求項１記載の分散型ストレージシステムにおいて、前記第１のストレージデバイスは、前記第１のコンピュータが前記アセットファイルを格納するときに複数ローカルファイルシステムブロックを連続的に書き込むブロック配置アルゴリズムを有するものである。
4. 請求項１記載の分散型ストレージシステムにおいて、さらに、前記第１のコンピュータと前記第２のコンピュータと前記第１のストレージデバイスとに結合され、前記第１のコンピュータと、前記第２のコンピュータと、前記第１のストレージデバイスとの間で並行のノンブロッキングアクセスを提供するように構成されたスイッチを有するものである。
5. 請求項１記載の分散型ストレージシステムにおいて、前記第１のコンピュータは、前記ヒントファイルを作成するように構成されたものである。
6. 請求項１記載の分散型ストレージシステムにおいて、前記第１のストレージデバイスは前記アセットファイルを格納するための３次ストレージメカニズムを有し、
   前記第２のストレージデバイスは、前記アセットファイルのコピーを前記第１のストレージデバイスの前記３次ストレージメカニズムから受け取り１又は複数のストリーミングを行うための２次ストレージメカニズムを有し、
   各前記第２のコンピュータは、前記第２のストレージデバイスの前記２次ストレージメカニズムから前記アセットファイルのコピーを受け取り複数のストリーミングを行うための１次ストレージメカニズムとを有するものである。
7. 請求項６記載の分散型ストレージシステムにおいて、前記１次ストレージメカニズムはランダムアクセスメモリ（ＲＡＭ）を有し、
   前記２次ストレージメカニズムはディスクストレージを有するものである。
8. 請求項１記載の分散型ストレージシステムにおいて、前記リソースコントローラは、前記第２コンピュータを監視し、この監視に基づいて前記第２コンピュータのうちの１つを選択するようにさらに構成されているものである。
9. 請求項１記載の分散型ストレージシステムにおいて、前記リソースコントローラは、前記第２のコンピュータのうちのどれが前記アセットファイルのストリームを前記第２コンピュータのなかのどのコンピュータよりももっと最近に開始したかを判定するようにさらに構成され、
   前記リソースコントローラは、前記判定に基づき前記第１のコンピュータのうちの前記１つを選択するよう構成されるものである。
10. 請求項１記載の分散型ストレージシステムにおいて、
    前記第１のブロックマップは、前記アセットファイルが前記第１のストレージデバイス中に格納されている場所の最初および最後の位置に関する情報を含み、
    前記第１のコンピュータは、前記ヒントファイルを作成するように更に構成されたものである。
11. 請求項１０記載の分散型ストレージシステムにおいて、前記第１のストレージデバイスは３次ストレージメカニズムを有し、
    前記第２のストレージデバイスは２次ストレージメカニズムを有し、
    各前記第２のコンピュータは１次ストレージメカニズムを有し、
    前記１次ストレージメカニズムはランダムアクセスメモリ（ＲＡＭ）を有し、
    前記２次ストレージメカニズムはディスクストレージを有するもので
    ある。
12. 請求項１０記載の分散型ストレージシステムにおいて、前記第１のブロックマップは、論理ブロックアドレスのリストを更に有し、
    前記リスト中の少なくとも１つの論理ブロックアドレスは前記アセットファイルにデータを格納するために使用されたセクタを識別し、
    各前記第２のコンピュータは、前記データに関連付けられた前記論理ブロックアドレスを読み出すよう構成され、
    各前記第２のコンピュータの前記仮想ファイルシステムは、前記関連付けられた論理ブロックアドレスを用いて、前記第１のストレージデバイス上の前記アセットファイルにアクセスするものである。
13. 請求項１１記載の分散型ストレージシステムにおいて、この分散型ストレージシステムは、さらに、
    前記第１のコンピュータと前記第２のコンピュータと前記第１のストレージデバイスとに結合され、前記第１のコンピュータと、前記第２のコンピュータと、前記第１のストレージデバイスとの間で並行のノンブロッキングアクセスを提供するように構成されたスイッチ、
    を有するものである。
14. 分散型ストレージシステムの第１のストレージデバイスに格納されたアセットファイルからデータを読み込む方法であって、
    前記分散型ストレージシステムは、第１のコンピュータと、第２のストレージデバイスと、複数の第２のコンピュータと、リソースコントローラと、を更に有し、
    各前記第２のコンピュータは、スタック可能な仮想ノードインターフェース及び少なくとも１つの仮想ノードを有する仮想ファイルシステムを有し、
    前記方法は、
    前記第１のコンピュータが前記アセットファイル用の第１のブロックマップを前記第１のストレージデバイスに書き込む工程と、
    前記アセットファイルに関連するヒントファイルを前記第１のストレージデバイスに書き込む工程であって、前記ヒントファイルは前記アセットファイル中の位置への少なくとも１つのポインターを有する、書き込み工程と、
    前記第１のコンピュータが前記ヒントファイル用の第２のブロックを前記第１のストレージデバイスに書き込む工程と、
    前記第１のコンピュータが前記第１及び第２のブロックマップのコピーを前記第２のストレージデバイスに書き込む工程と、
    各前記第２のコンピュータが前記第２ストレージデバイス上の前記第１及び第２のブロックマップの前記コピーの名前を前記第１のストレージデバイス上の対応するアセットファイルの名前及びヒントファイルの名前に関連するように設定する、書き込み工程と、
    前記リソースコントローラが前記アセットファイルからのデータに対するリクエストを受け取る工程と、
    前記リソースコントローラが、前記第２のコンピュータのうちの１つを選択する工程と、
    前記リソースコントローラが前記リクエストを前記第２のコンピュータのうちの前記選択された１つに送信する工程と、
    前記第２のコンピュータのうちの前記選択された１つが前記第１のコンピュータにおいてシステムコールを発行する工程と、
    前記第２のコンピュータのうちの前記選択された１つが前記第１及び第２のブロックマップの前記コピーを用い、前記アセットファイルを読み出す工程と、
    を有する方法。
15. 請求項１４記載の方法において、この方法は、さらに、
    前記アセットファイルが前記第１のストレージデバイスに格納されるときに、前記第１のコンピュータは、前記第１のブロックマップを作成する工程、
    を有するものである。
16. 請求項１４記載の方法において、この方法は、さらに、
    前記第１のコンピュータは、前記ヒントファイルを作成する工程、
    を有する。
17. 請求項１４記載の方法において、
    前記リソースコントローラは、前記第２のコンピュータを監視し、前記リソースコントローラは前記監視に基づいて前記第２のコンピュータのうちの１つを選択する工程、
    をさらに有するものである。
18. 請求項１７記載の方法において、この方法は、さらに、
    前記スイッチは、前記第１のストレージデバイスを前記第１のコンピュータおよび前記第２のコンピュータに連結させる工程、
    を有するものである。
19. 請求項１４記載の方法において、
    前記第１のブロックマップは、論理ブロックアドレスのリストを有するものであり、
    前記リスト中の少なくとも１つの論理ブロックアドレスは前記アセットファイルに前記データを格納するために使用されたセクタを識別するものであり、
    前記方法は、
    前記第２のコンピュータのうちの前記選択された１つが、前記データに関連する前記論理ブロックアドレスを読み出す工程、
    を更に有し、
    前記第２のコンピュータのうちの前記選択された１つの前記仮想ファイルシステムは、前記関連付けられた論理ブロックアドレスを更に用いて前記アセットファイルを読み出す。
20. 請求項１９記載の方法において、
    前記リストは、各論理ブロックアドレスに関連したブロック長を有し、
    前記ブロック長は、前記識別されたセクタに続く連続セクタの総数を表すものであり、
    前記の方法は、さらに、
    前記第２のコンピュータのうちの前記選択された１つが、関連したブロック長を取り出す工程、
    を有し、
    前記データは前記取り出された論理ブロックアドレスおよび前記関連したブロック長によって識別される論理記憶領域に含まれ、
    前記第２のコンピュータのうちの前記選択された１つの前記仮想ファイルシステムは、前記関連したブロック長を更に用いて前記アセットファイルを読み出すものである。
21. コンピュータ可読命令を有するコンピュータ可読媒体であって、
    第１のストレージデバイスと、第１のコンピュータと、第２のストレージデバイスと、複数の第２のコンピュータと、リソースコントローラと、を有する分散型ストレージシステムにより読み込まれると、
    前記第１のコンピュータがアセットファイル用の第１のブロックマップを第１のファイルシステムに書き込む命令と、
    前記アセットファイルに関連するヒントファイルを前記第１のファイルシステムに書き込む命令であって、前記ヒントファイルは前記アセットファイル中の位置への少なくとも１つのポインターを有するものである、書き込み命令と、
    前記第１のコンピュータが前記ヒントファイル用の第２のブロックマップを前記第１のファイルシステムに書き込む命令と、
    前記第１のコンピュータが前記第１及び第２のブロックマップのコピーを第２のファイルシステムに書き込む命令と、
    各前記第２のコンピュータが前記第２ファイルシステム上の前記第１及び第２のブロックマップの前記コピーの名前を、前記第１のファイルシステム上の対応するアセットファイル及びヒントファイルの名前に関連するように設定する命令と、
    前記リソースコントローラが前記アセットファイルのデータに対するリクエストを受け取る命令と、
    前記リソースコントローラが前記複数の第２のコンピュータのうちの１つを選択する命令と、
    前記リソースコントローラが前記リクエストを前記複数の第２のコンピュータのうちの前記選択された１つに送信する命令と、
    前記複数の第２のコンピュータのうちの前記選択された１つに、前記第１のファイルシステムにおけるシステムコールを発行させる命令と、
    前記コンピュータのうちの前記選択された１つの前記仮想ファイルシステムに、前記第１及び第２のブロックマップのコピーを使用して前記アセットファイルを読み込むようにさせる命令と、
    を実行し、
    前記仮想ファイルシステムはスタック可能な仮想ノードインターフェースと少なくとも１つの仮想ノードを有する、
    コンピュータ可読媒体。
22. 請求項２１記載のコンピュータ可読媒体において、
    このコンピュータ可読媒体は、さらに、
    前記アセットファイルが前記第１のファイルシステムに格納される際に前記第１のコンピュータが前記第１のブロックマップを作成するためのコンピュータ可読命令、
    を有するものである。
23. 請求項２１記載のコンピュータ可読媒体において、このコンピュータ可読媒体は、さらに、第１のコンピュータが前記ヒントファイルを作成するためのコンピュータ可読命令、
    を更に有する請求項２１に記載のコンピュータ可読媒体。
24. 請求項２１記載のコンピュータ可読媒体において、
    前記リソースコントローラによって、前記複数のコンピュータを監視するコンピュータ可読命令、
    を更に有し、
    前記複数のコンピュータのうちの１つの選択は、前記監視に基づく。
25. 請求項２１記載のコンピュータ可読媒体において、
    前記第１のブロックマップは、論理ブロックアドレスのリストを有するものであり、
    前記リスト中の少なくとも１つの論理ブロックアドレスは前記アセットファイル中の前記データを格納するために使用されたセクタを識別し、
    前記コンピュータ可読媒体は、
    前記複数のコンピュータのうちの選択された１つを、前記データに関連付けられた論理ブロックアドレスを読み出すように構成するコンピュータ可読命令、
    を更に有し、
    前記複数のコンピュータのうちの選択された１つの仮想ファイルシステムは、前記関連付けられた論理ブロックアドレスを更に用いて前記アセットファイルを取り出す。
26. 請求項２５記載のコンピュータ可読媒体において、このコンピュータ可読媒体は、さらに、
    前記第２のコンピュータのうちの前記選択された１つが、各論理ブロックアドレスに関連したブロック長を取り出すコンピュータ可読命令、
    を更に有し、
    前記データは、前記取り出された論理ブロックアドレスおよび前記関連したブロック長によって識別される論理記憶領域に含まれ、
    前記複数のコンピュータのうちの選択された１つの前記仮想ファイルシステムは、前記関連付けられたブロック長を更に用いて前記アセットファイルを読み出す。
27. 階層キャッシュシステムであって、
    デジタルアセットと、前記デジタルアセット用の第１のブロックマップと、前記デジタルアセット用のヒントファイルと前記ヒントファイル用の第２のブロックマップとを格納するように構成された第１のキャッシュメモリであって、前記ヒントファイルは、前記デジタルアセット内の位置への少なくとも１つのポインターを有する、第１のキャッシュメモリと、
    前記第１及び第２のブロックマップのコピーを格納するように構成された第２のキャッシュメモリと、
    前記第２のキャッシュメモリ上の前記第１及び第２のブロックマップのコピーの名前が、前記第１のキャッシュメモリ上にある対応するデジタルアセットの名前及びヒントファイルの名前に関連するように設定するコンテンツ同期化（ｓｙｎｃｈｅｒ）手段と、
    前記第１と第２のキャッシュメモリに連結された複数のコンピュータであって、前記複数のコンピュータのそれぞれは前記第１及び第２のブロックマップの前記コピーを使用して、前記第１のキャッシュメモリ上の前記デジタルアセットを読み込むように構成された仮想ファイルシステムを有し、前記仮想ファイルシステムはスタック可能な仮想ノードインターフェースと少なくとも1つの仮想ノードを有す、複数のコンピュータ、
    前記複数のコンピュータのうちの１つを選択し、前記デジタルアセットに対するリクエストを前記複数のコンピュータのうちの選択された１つに送信するように構成されたリソースコントローラと、
    を有する階層キャッシュシステム。
28. 請求項２７記載の階層キャッシュシステムにおいて、前記複数のコンピュータのそれぞれはビデオポンプを有するものである。
29. 請求項２８記載の階層キャッシュシステムにおいて、
    前記リソースコントローラは、前記複数のコンピュータを監視するように更に構成され、
    前記リソースコントローラは、前記監視に基づいて前記複数のコンピュータのうちの１つを選択するように構成されている。
30. 請求項２７記載の階層キャッシュシステムにおいて、
    前記リソースコントローラは、前記複数のコンピュータのうちのどれが前記デジタルアセットのストリームを前記複数のコンピュータのなかのどのコンピュータよりももっと最近に開始したかを判定するようにさらに構成され、
    前記リソースコントローラは、前記監視に基づき前記複数のコンピュータのうちの１つを選択するよう構成される。
31. 請求項２７記載の階層キャッシュシステムにおいて、前記第１のキャッシュメモリはディスクアレイを有するものである。
32. 請求項２７記載の階層キャッシュシステムにおいて、前記第２のキャッシュメモリはディスクストレージを有するものである。
33. 請求項２７記載の階層キャッシュシステムにおいて、前記第２のキャッシュメモリはランダムアクセスメモリ（ＲＡＭ）を有するものである。
34. 請求項２７記載の階層キャッシュシステムにおいて、前記第１のブロックマップは、前記デジタルアセットが前記第１のキャッシュメモリに格納されている場所の最初及び最後の位置に関する情報を含むものである。

Images