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

Abstract

【解決手段】 分散型ストレージアーキテクチャおよび階層キャッシングシステムが、ビデオオンデマンドまたはストリーミングメディアアプリケーションにおいて利用される。分散型のストレージアーキテクチャの例示の実施形態は、ブロックマップキャッシングおよび仮想ファイルシステムスタック可能なファイルシステムモジュールに基づくもので、コントローラと、第1のコンピュータおよび第2のコンピュータと、第１および第２のスイッチと、ストレージデバイスを含む。前記第1のコンピュータは、ローカルファイルシステムを含み、これを使用してアセットファイルを前記第1のストレージデバイス上のローカルファイルシステムに格納する。前記第1のコンピュータは、各アセットファイル用にブロックマップを作るためにプロセスを使用するものであるが、前記ブロックマップはアセットファイルが前記第1のストレージデバイスに格納される場所の境界に関する情報を含む。
【選択図】 図１

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (50)

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. 請求項１５記載の仮想ファイルシステムにおいて、前記第１および第２のファイルシステムのタイプは同一のものである。
28. 第１のストレージデバイスに格納された第１のファイルからデータを読み込む方法であって、
    ブロックマップを第２のファイルに格納する工程であって、前記ブロックマップは論理ブロックアドレスのリストを有し、且つ前記リスト中の少なくとも１つの論理ブロックアドレスは前記第１のファイルにデータを格納するために使用されるセクタを識別するものである、前記格納する工程と、
    前記第１のファイルと関連付けられた仮想ファイルからデータを読み込むためのシステムコールを発行する工程と、
    前記データと関連付けられた論理ブロックアドレスを取り出す工程と、
    前記関連した論理ブロックアドレスを使用して前記第１のストレージデバイスからデータを読み込む工程と、
    を有する方法。
29. 請求項２８記載の方法において、この方法は、さらに、前記第１のファイルが前記第１のストレージデバイスに格納される時に、前記ブロックマップを作成する工程を有するものである。
30. 請求項２８記載の方法において、この方法は、さらに、前記第１のファイルへのポインタを有するヒントファイルを作成する工程を有する。
31. 請求項２８記載の方法において、前記第２のファイルは第２のストレージデバイスに格納されるものである。
32. 請求項３１記載の方法において、この方法は、さらに、前記第１のストレージデバイスを第１のコンピュータおよび第２のコンピュータに連結させる工程と、前記第２のストレージデバイスを前記第２のコンピュータに連結させる工程とを有するものである。
33. 請求項２８記載の方法において、前記リストは、さらに、各論理ブロックアドレスに関連付けられたブロック長を有し、前記ブロック長は前記識別されたセクタに続く連続セクタの計数を表すものである。
34. 請求項３３記載の方法において、この方法は、さらに、関連したブロック長を取り出す工程を有し、前記データブロックは前記取り出された論理ブロックアドレスおよび前記関連したブロック長によって識別される論理記憶領域に含まれるものである。
35. コンピュータ可読命令を有するコンピュータ可読媒体であって、
    前記命令は、ブロックマップを第２ファイルに格納する工程であって、前記ブロックマップは論理ブロックアドレスのリストを有し、且つ前記リスト中の少なくとも１つの論理ブロックアドレスは第１のファイルにデータを格納するために使用されるセクタを識別するものである、前記格納する工程と、
    前記第１のファイルに関連した仮想ファイルからデータを読み込むためのシステムコールを発行する工程と
    前記データに関連付けられた論理ブロックアドレスを取り出す工程と、
    前記関連付けられた論理ブロックアドレスを使用して、第１のストレージデバイスからデータを読み込む工程とのためのものである、
    コンピュータ可読媒体。
36. 請求項３５記載のコンピュータ可読媒体において、このコンピュータ可読媒体は、さらに、前記第１のファイルが前記第１のストレージデバイスに格納される際に前記ブロックマップを作成するためのコンピュータ可読命令を有するものである。
37. 請求項３５記載のコンピュータ可読媒体において、このコンピュータ可読媒体は、さらに、前記第１のファイルへのポインタを有するヒントファイルを作成するためのコンピュータ可読命令を有するものである。
38. 請求項３５記載のコンピュータ可読媒体において、前記第２のファイルは第２のストレージデバイスに格納されるものである。
39. 請求項３５記載のコンピュータ可読媒体において、前記リストは、さらに、各論理ブロックアドレスに関連付けられたブロック長を有し、前記ブロック長は前記識別されたセクタに続く連続セクタの計数を表すものである。
40. 請求項３９記載のコンピュータ可読媒体において、このコンピュータ可読媒体は、さらに、関連したブロック長を取り出す工程のためのコンピュータ可読命令を有し、前記データブロックは、前記取り出された論理ブロックアドレスおよび前記関連したブロック長によって識別される論理記憶領域に含まれるものである。
41. 階層キャッシュシステムであって、
    デジタルアセットを格納可能な３次キャッシュメモリと、
    前記３次キャッシュメモリに連結された複数のサーバとを有し、
    １若しくはそれ以上のサーバは、前記３次キャッシュメモリからのアセットのコピーを受け取り、ストリームを出すことができる２次キャッシュメモリと、
    前記２次キャッシュメモリからのアセットのコピーを受け取り、複数のストリームを出すことができる１次キャッシュメモリと、
    を有する階層キャッシュシステム。
42. 請求項４１記載の階層キャッシュシステムにおいて、前記複数のサーバは複数のビデオポンプを有するものである。
43. 請求項４１記載の階層キャッシュシステムにおいて、この階層キャッシュシステムは、さらに、前記アセットをストリームするために前記複数のビデオポンプの内から１ビデオポンプを選択することができるリソースコントローラをさらに有するものである。
44. 請求項４１記載の階層キャッシュシステムにおいて、前記３次キャッシュメモリはディスクストレージを有するものである。
45. 請求項４１記載の階層キャッシュシステムにおいて、前記３次キャッシュメモリはディスクアレイを有するものである。
46. 請求項４１記載の階層キャッシュシステムにおいて、前記２次キャッシュメモリはディスクストレージを有するものである。
47. 請求項４１記載の階層キャッシュシステムにおいて、前記１次キャッシュメモリはランダムアクセスメモリ（ＲＡＭ）を有するものである。
48. ３次キャッシュと複数のサーバとを有する階層キャッシュシステム中のアセットをストリームするための方法であって、前記サーバの各々は前記３次キャッシュに連結され、１次キャッシュおよび２次キャッシュを含むものであり、
    前記複数のサーバの内で、前記３次キャッシュから前記アセットをストリームさせている最後のサーバと、前記最後のサーバの第１次および第２次キャッシュからのアセットのストリーム計数とを決定する工程と、
    前記計数が予め定められたしきい値未満の場合は、前記最後のサーバから前記アセットをストリームさせる工程と、
    そうでない場合は、最大の使用可能なストリーミング帯域幅を有するサーバから前記アセットをストリームさせる工程と
    を有するものである方法。
49. 請求項４８記載の方法において、前記サーバはビデオポンプとして構成されるものである。
50. 請求項４８記載の方法を実行するためのコンピュータ可読命令を有するコンピュータ可読媒体。

Images