JP5006395B2 - 分散ファイルシステムのためのトランスコーディング - Google Patents

Description

本発明の実施形態は、一般に、電子データ記憶システムに関し、特に、スケーラブルなデータ記憶システムに関する。

今日の情報集約的環境においては、膨大な量のデジタルデータを記憶する必要のある、多くの企業およびその他の団体が存在する。それらには、ネットワークで結ばれた何千人もの従業員によって共有される企業内情報を記憶する大企業などの事業体、何百万もの製品に関する情報を記憶するオンライン販売業者、ならびに、大規模な所蔵文献を有する図書館および教育機関が含まれる。大規模データ記憶システムの使用に対する最近のニーズは、放送テレビジョンの番組編成市場にある。そのような業務は、テレビ番組の作成、編集、および放送のための古いアナログ技術から、全デジタルの手法へと推移しつつある。コンテンツ（コマーシャルなど）自体がデジタルビデオファイルの形式で記憶されるのみでなく、放送のための準備における番組およびコマーシャルの編集およびシーケンシング（ｓｅｑｕｅｎｃｉｎｇ）も、強力なコンピュータシステムを使用してデジタル処理される。データ記憶システム内に記憶されてもよいその他のタイプのデジタルコンテンツとしては、地震予知のための地震探査データ、および地図作成のための衛星画像データが挙げられる。

解決する課題

記憶システムの全体的コストの低減を支援するために、分散アーキテクチャが使用される。何百もの小さな、比較的低コストの大容量の生産ディスクドライブ（現在では、各ディスクドライブユニットが１００Ｇバイト以上の容量を有する）が一緒にネットワーク接続されて、とても大きな総記憶容量に到達するようになるかもしれない。しかし、記憶容量のこの分散は、システム内で正常なアクセスを妨げる障害が発生する可能性も増加させる。そのような障害は、システムハードウェア内（例えば、ケーブル、コネクタ、ファン、電源、またはディスクドライブユニット）だけでなく、ソフトウェア内（特定のクライアントアプリケーションプログラムにおけるバグなど）も含む、さまざまな異なる場所で発生する可能性がある。所与のアクセスへのサービスを、他の場合ならばそのアクセスを阻止していたであろうディスク障害にもかかわらず提供するために（例えば、要求されたデータを利用可能にするために）、記憶システムは、ＲＡＩＤ（ｒｅｄｕｎｄａｎｔ ａｒｒａｙ ｏｆ ｉｎｅｘｐｅｎｓｉｖｅ ｄｉｓｋｓ）の形式で、冗長性を実装している。システムは、さらに、代替ドライブ内へ故障したディスクドライブのコンテンツを再構築することも可能にする。

記憶されたオーディオ／ビデオコンテンツに関して、記憶用のハードウェアから切り離されたトランスコーディング用のハードウェアが、オーディオ／ビデオコンテンツをトランスコードするために使用される。そのような外部のトランスコーディング用のハードウェアは、記憶用のシステムとトランスコーディング用のシステムとの間でオーディオ／ビデオデータを移動する際のボトルネックとなり、結果として性能が不足することになる。

本発明は、限定ではなく、例として、添付の図面の図中に示されている。

以下の説明では、本発明のいくつかの実施形態の十分な理解を提供するために、特定のシステム、構成要素、方法、およびその他の例などの、多数の具体的な詳細を記載する。しかし、本発明の少なくとも一部の実施形態は、具体的に詳細に記載されたものなしに実施されてもよいということは、当業者にとって明らかであろう。他の場合には、本発明を不必要に不明瞭にするのを回避するために、周知の構成要素または方法は、詳細には説明していないか、または単純なブロック図形式で示している。したがって、記載されている具体的な詳細は、例示にすぎない。特定の実装は、それらの例示された詳細に記載されたものとは異なっていてもよく、そして依然として本発明の趣旨および範囲内であると考えられるものであればよい。

本発明の実施形態は、以下で説明するさまざまな動作を含む。それらの動作は、ハードウェア構成要素、ソフトウェア、ファームウェア、またはそれらの組み合わせによって実行されてもよい。本明細書で使用する場合、「と結合される（ｃｏｕｐｌｅｄ ｔｏ）」という用語は、直接結合されること、または、１つ以上の介在する構成要素を介して間接的に結合されることを意味してもよい。本明細書に記載する、さまざまなバスで提供されるいかなる信号も、その他の信号と時分割多重化されても（ｔｉｍｅ ｍｕｌｔｉｐｌｅｘｅｄ）、１つ以上の共通バスで提供されてもよい。さらに、回路部品またはブロック間の相互接続は、バスとして、または単一信号線として示される場合がある。バスのそれぞれは、あるいは、１つ以上の単一信号線であってもよく、単一信号線のそれぞれは、あるいは、バスであってもよい。

特定の実施形態は、機械読み取り可能な媒体上に記憶された命令を含んでもよい、コンピュータプログラム製品として実装されてもよい。それらの命令は、記述されている動作を実行するための、汎用または専用プロセッサをプログラムするために使用されてもよい。機械読み取り可能な媒体は、マシン（例えば、コンピュータ）による読み出しが可能な形態（例えば、ソフトウェア、処理アプリケーション）で情報を記憶または伝送するための任意の機構を含む。機械読み取り可能な媒体としては、以下に限定されないが、磁気記憶媒体（例えば、フロッピー（商標登録）ディスケット）、光記憶媒体（例えば、ＣＤ−ＲＯＭ）、光磁気記憶媒体、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラム可能メモリ（例えば、ＥＰＲＯＭおよびＥＥＰＲＯＭ）、フラッシュメモリ、電子的、光学的、音響的、またはその他の形態の伝搬信号（例えば、搬送波、赤外線信号、デジタル信号など）、あるいは、電子的命令を記憶するのに好適な別のタイプの媒体が挙げられる。

さらに、一部の実施形態は、機械読み取り可能な媒体が、２つ以上のコンピュータシステムに記憶され、および／または、２つ以上のコンピュータシステムによって実行される、分散コンピューティング環境内で実施されてもよい。その上、コンピュータシステム間で転送される情報は、コンピュータシステムを接続する通信媒体を介して、受け取っても送り出しても（プルまたはプッシュ）よい。

方法および装置の実施形態では、データ記憶システムに結合された１つ以上のアプリケーションに、ファイルへの変更または新しいファイルの追加を通知する場合について説明される。一実施形態では、分散ファイルシステムの通知システムは、１つ以上のアプリケーションと通信を行う。

図１は、ビデオ処理環境の一部として使用されているデータ記憶システム１００の一実施形態を示す。しかし、以下に記載するデータ記憶システム１００ならびにその構成要素または特徴は、あるいは、その他のタイプの適用例（例えば、図書館、地震探査データ処理センター、販売業者の製品カタログ、中央企業情報保管など）において使用されてもよいということに留意すべきである。データ記憶システム１００は、データ保護、ならびに、ハードウェアおよびソフトウェアの耐障害性と復旧とを提供する。

データ記憶システム１００は、メディアサーバ１０２とコンテンツライブラリ１０４とを含む。メディアサーバ１０２、１０６、１０８は、サーバマシンのネットワーク上で実行されている複数のソフトウェア構成要素から構成されていてもよい。サーバマシンは、データを記憶する回転磁気ディスクドライブなどの大容量記憶装置を含むコンテンツライブラリ１０４と通信を行う。サーバマシンは、ファイルの作成、書き込み、または読み出しの要求を受け入れ、そして、コンテンツライブラリ１０４内の１つ以上のディスクドライブ内にデータを転送するプロセス、または要求された読み出しデータをそれらのディスクドライブから配信するプロセスを管理する。サーバマシンは、どのファイルがどのドライブに記憶されているかを追跡記録する。ファイルへのアクセス要求、すなわち、作成、書き込み、または読み出しの要求は、通常、サーバネットワークに接続されたクライアントマシン上で実行されるクライアントのアプリケーションプログラムと呼ばれるものから受信される。例えば、アプリケーションプログラムは、（システム内にデジタルビデオファイルとして記憶された）特定のビデオクリップを必要とするテレビジョンスタジオのワークステーション上で実行されているビデオ編集アプリケーションであってもよい。

ビデオデータは、例えばＭｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）フォーマットの形態の圧縮を使用したとしても、大容量である。したがって、そのような環境のためのデータ記憶システムは、少なくとも数十テラバイト、またはそれよりも大きな記憶容量を提供するように設計される。さらに、高速データ通信リンクが、ネットワークのサーバマシンを接続するために使用され、そして場合によっては特定のクライアントマシンと接続するためにも使用されて、データ記憶システム１００へのアクセスのために１００Ｇｂ／秒以上の共有総帯域幅を提供する。記憶システムは、さらに、複数のクライアントによるアクセスを同時に提供することが可能である。

データ記憶システム１００は、さまざまな異なる形態のクライアントマシンを使用してアクセスされてもよい。例えば、図１に示すように、メディア処理の「インジェスト」段階１１０では、標準的なデジタルビデオカメラ、テープレコーダ、および衛星フィードをインタフェースとしてもよい、メディアサーバ１０２によって、コンテンツファイル（この例では、ＭＰＥＧおよび高品位（ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ）（ＨＤ）を含むさまざまなタイプのデジタルメディアファイル）が要求されてもよい。代替として、クライアントマシンは、インターネットなどの遠隔ネットワーク上にあってもよい。「プロダクション」段階１１２においては、記憶されたファイルが、閲覧１１６、編集１１８、およびアーカイブ１２０のために、クライアントマシンにストリーミングされてもよい。変更されたファイルは、次に、「プレイアウト」段階１１４の間に、配信のために、メディアサーバ１０６、１０８に、または遠隔ネットワーク１２４を介して直接、送信されてもよい。

データ記憶システム１００は、同時クライアントアクセスの数が増加するにつれて、または総記憶容量の要求が増加するにつれて拡張することが特に容易であると判明しうるアーキテクチャを有する、比較的高性能、高可用性の記憶サブシステムを提供する。メディアサーバ１０２、１０６、１０８（図１におけるような）とコンテンツゲートウェイ（図示せず）との追加は、さまざまな送信元からのデータが１つの高性能／高可用性システムに集約され、それにより、企業が管理しなければならない記憶ユニットの総数を減らすことを可能にする。さまざまなタイプの作業負荷（さまざまなサイズのファイル、およびさまざまなクライアント負荷を含む）の処理が可能であることに加えて、システムの一実施形態は、自動負荷バランス、高速ネットワークスイッチング相互接続、データキャッシング、およびデータ複製を含む特徴を有してもよい。一実施形態によれば、データ記憶システム１００は、性能において、比較的小規模な、すなわち６６テラバイト未満のシステム上での２０Ｇｂ／秒から、より大規模な、すなわち１ペタバイトを超えるシステムの場合の数百Ｇｂ／秒を超える性能のものまで、必要に応じて拡張する。直接接続されたクライアントにとって、これは、現在のところ、最小６０メガバイト／秒の実効転送速度ということになり、コンテンツゲートウェイに接続されたクライアントにとっては、最小４０メガバイト／秒ということになる。そのような数は、当然ながら、データ記憶システム１００の現在の能力の例にすぎず、請求される本発明の範囲全体を限定することを意図するものではない。

一実施形態によれば、データ記憶システム１００は、停止しないで動作するように設計されていてもよく、そして、記憶装置と、クライアントと、その構成要素間のネットワーキング帯域幅との拡張を、進行中のアクセスをシャットダウン、あるいは、それらのアクセスに影響を及ぼすことなく行うことを可能にする。データ記憶システム１００は、好ましくは、十分な冗長性を有しているため、一箇所だけが障害となるような点（ｓｉｎｇｌｅ ｐｏｉｎｔ ｏｆ ｆａｉｌｕｒｅ）が存在しない。コンテンツライブラリ１０４内に記憶されたデータは複数の複製を有しており、したがって、大容量記憶ユニット（例えば、ディスクドライブユニット）、さらにはサーバ全体が損なわれてもデータを失うことはない。本発明の異なる実施形態では、例えば、ディスクドライブ障害の場合のデータ複製は、比較的高速であり、データ記憶システム１００全体としての顕著な性能低下を引き起こすことはないと考えられる。一般的なＲＡＩＤシステムとは異なり、データ記憶システム１００の交換されたドライブユニットは、先の（故障した）ドライブと同じデータを含まなくてもよい。その理由は、ドライブの交換が実際に発生するまでには、再複製プロセスが、故障したドライブから、システム１００の他のドライブ上への、データの再複製をすでに開始しているからである。

大容量記憶ユニットの障害に加えて、データ記憶システム１００は、任意のより大きな構成要素、または、さらには、構成要素全体（例えば、メタデータサーバ、コンテンツサーバ、およびネットワークスイッチ）の障害からの保護を提供できるかもしれない。以下で説明するように、それぞれのエンクロージャまたはラック内に配置された、サーバの３つ以上のグループを有するシステムなどのより大規模なシステムでは、データ記憶システム１００は、エンクロージャまたはラック全体の障害の場合でも動作を継続する。

次に、図２を参照すると、本発明の一実施形態による、複数のクライアントに接続されたデータ記憶システム２００のシステムアーキテクチャが示されている。システム２００内に記憶されている複数のファイルについてのメタデータをそれぞれが記憶する複数のメタデータサーバマシン２０２を、システム２００は有する。そのようなマシン内で実行されているソフトウェアは、メタデータサーバ２０２またはコンテンツディレクタ２０２と呼ばれる。メタデータサーバ２０２は、システム２００の動作の管理を担当し、そして、クライアント２０４および２０６にとっての最初の接点である。スマートクライアント２０４およびレガシークライアント２０６という、２つのタイプのクライアントが示されていることに留意されたい。

スマートクライアント２０４は、システム２００の専用ネットワークプロトコルの知識を有し、そして、システム２００のネットワーキングファブリック（ここでは、Ｇｂイーサネット（商標登録）スイッチ２０８）の背後にあるコンテンツサーバ２１０と直接通信することが可能である。スイッチ２０８は、図２に示されているように、コンテンツサーバ２１０とメタデータサーバ２０２との間の選択的ブリッジとして働く。

もう一方のタイプのクライアントは、現在のファイルシステムドライバ（ＦＳＤ）がインストールされていない、またはシステム２００のために現在提供されているソフトウェア開発キット（ＳＤＫ）を使用しない、レガシークライアント２０６である。レガシークライアント２０６は、システム２００専用ではないオープンネットワーキングプロトコルを介して、図示されているように、プロキシまたはコンテンツゲートウェイ２１２を経由して、「イーサネット」スイッチ２０８の背後にあるコンテンツサーバ２１０と間接的に通信を行う。コンテンツゲートウェイ２１２は、コンテンツライブラリブリッジ２１２とも呼ばれてもよい。

ファイルシステムドライバすなわちＦＳＤは、システム２００にアクセスするための標準的なファイルシステムインタフェースを提供するクライアントマシン上にインストールされるソフトウェアである。他方、ソフトウェア開発キットすなわちＳＤＫは、ソフトウェア開発者がシステム２００に、アプリケーションプログラムから直接アクセスすることを可能にする。この選択肢は、さらに、以下で説明する複製因子（ｒｅｐｌｉｃａｔｉｏｎ ｆａｃｔｏｒ）の設定などの、システム固有の関数を、クライアントマシンのユーザが利用することを可能にする。

システム２００では、ファイルは、通常、記憶される際にスライスに分割される。言い換えると、ファイルの部分は、コンテンツサーバ内に置かれたさまざまなディスクドライブにわたって散在させられる。現在の一実施形態では、スライスは、固定サイズが好ましく、従来のディスクブロックよりもはるかに大きく、それにより、大規模データファイル（例えば、現在では、大規模なビデオおよびオーディオメディアファイルに好適な、８Ｍバイト）に対してより良い性能を持たせることを可能にする。さらに、ファイルは、ハードウェア障害から保護するために、さまざまなコンテンツサーバ内のさまざまなドライブにわたって、システム２００内で複製される。これは、一時点における任意の１つのドライブの障害によって、記憶されたファイルがシステム２００によって再構成されることが不可能になることはないことを意味し、その理由は、ファイルのいかなる紛失したスライスも、他のドライブ内で依然として見つけることが可能だからである。複製は、さらに、ファイルをより多くのサーバからアクセス可能にすることによって、読み出し性能の向上を支援する。どのファイルがどこに記憶されているか（または、ファイルのスライスがどこに記憶されているか）を追跡記録するために、システム２００は、作成されて書き込まれたファイルのファイル名と、そのスライスとの間のマッピングを含むメタデータ（ファイルに関する情報）の知識を有する、メタデータサーバプログラムを有する。

メタデータサーバ２０２は、コンテンツサーバ２１０のうちのどれが、実際のコンテンツまたはデータを記憶のために受信するのに利用可能であるかを決定する。メタデータサーバ２０２は、さらに、負荷バランスを取るように機能し、これはすなわち、帯域幅の制限や特定のコンテンツサーバがいっぱいになっているかにより、コンテンツサーバ２１０のうちのどれが新しいデータを記憶するために使用されるべきで、どれが使用されるべきでないかの決定を行うことである。データ可用性およびデータ保護を支援するために、ファイルシステムメタデータは、複数回複製されてもよい。例えば、少なくとも２つのコピーが、各メタデータサーバ２０２上に（そして、例えば、各ハードディスクドライブユニット上に１つ）記憶されてもよい。メタデータの複数のチェックポイントが、定期的に取られるべきである。システム２００のほとんどの実施形態において、全体的なシステムの動作への影響が最小であるように、チェックポイントが発生するためには数分の時間しか必要とされないことが期待される。

通常の動作では、すべてのファイルアクセスは、メタデータサーバ２０２を介して開始または終了する。メタデータサーバ２０２は、例えば、ファイルオープン要求に対して、読み出しまたは書き込み動作のために利用可能なコンテンツサーバ２１０のリストを返すことによって応答する。それ以降は、そのファイルについてのクライアント通信（例えば、読み出し、書き込み）は、メタデータサーバ２０２ではなく、コンテンツサーバ２１０に向けられる。ＳＤＫおよびＦＳＤは、当然、それらの動作の詳細がクライアント２０４、２０６からは見えないようにする。上述のように、メタデータサーバ２０２は、ファイルおよびスライスの配置を制御して、コンテンツサーバのバランスのとれた利用を提供する。

別の実施形態によれば、システム２００のコンフィギュレーションおよび監視のための、例えば、独立したラックマウント式サーバマシン上のシステムマネージャ（図示せず）がさらに提供されてもよい。

システム２００のさまざまな構成要素間の、すなわち、コンテンツサーバ２１０とメタデータサーバ２０２との間の接続は、ネットワーク相互接続の障害の場合に、必要な冗長性を提供しなければならない。

図３Ａは、比較的小規模なデータ記憶システム３００の物理的ネットワークトポロジを示す。図３Ｂは、データ記憶システム３００の論理的ネットワークトポロジを示す。接続は、「イーサネット」規格によって享受される広範な業界から支持され、かつ、技術的にも成熟しているという利点を活用する、システム３００全体にわたるＧｂ「イーサネット」であることが好ましい。そのような利点は、より低いハードウェアコストですみ、より広範な技術要員によって熟知され、アプリケーション層におけるより迅速に導入できるという利点をもたらすことが期待される。ＯＣＬシステムのさまざまなサーバ間の通信は、現在のインターネットプロトコル（ＩＰ）ネットワーキング技術を使用することが好ましい。しかし、その他のネットワークスイッチング相互接続が、サーバ間でのパケットのスイッチングに必要とされる速度をそれらが提供することができるのであれば、代わりに使用されてもよい。

ネットワークスイッチ３０２が、自動的にネットワークを複数のセグメントに分割し、セグメント間の高速な選択的ブリッジとして働き、ネットワーク帯域幅に関して他のコンピュータのペアと競合しないように複数のコンピュータのペアの同時接続をサポートする。ネットワークスイッチ３０２は、これを各宛先アドレスとそのポートとのテーブルを維持することによって達成する。スイッチ３０２は、パケットを受信したら、パケット内のヘッダ情報から宛先アドレスを読み出し、送信元ポートと宛先ポートとの間で一時的な接続を確立し、パケットをその接続上で送信し、そして、次に、接続を終了してもよい。

スイッチ３０２は、コンピュータのペア間で複数の一時的なクロスオーバケーブル接続を確立していると考えることができる。スイッチ内の高速電子回路が、送信側コンピュータからの１つのケーブルの端（送信元ポート）を、受信側コンピュータに至る別のケーブルの端（宛先ポート）に、パケットごとに自動的に接続する。複数のこのような接続が、同時に発生してもよい。

図３Ａおよび図３Ｂのトポロジ例では、システム３００のさまざまな構成要素間の接続を提供するために、マルチＧｂ「イーサネット」スイッチ３０２、３０４、３０６が使用されている。図３Ａおよび図３Ｂは、４０Ｇｂ／秒の帯域幅をクライアントが利用することを可能にする、１Ｇｂ「イーサネット」３０４、３０６および１０Ｇｂ「イーサネット」３０２スイッチを示す。しかし、将来はさらに高速のスイッチが使用されてもよいため、これらは本発明の範囲を限定することを意図するものではない。図３Ａおよび図３Ｂのトポロジ例は、サブネットＡ ３０８およびサブネットＢ ３１０という２つのサブネットを有し、サブネットＡ ３０８およびサブネットＢ ３１０にはコンテンツサーバ３１２が配置されている。各コンテンツサーバは一対（２つ）のネットワークインタフェースを有し、１つはサブネットＡ ３０８への、そしてもう１つはサブネットＢ ３１０へのネットワークインタフェースであり、それにより、各コンテンツサーバは、サブネット３０８または３１０のいずれを介してもアクセス可能になっている。サブネットケーブル３１４が、コンテンツサーバ３１２を一対（２つ）のスイッチ３０４、３０６に接続し、各スイッチは、それぞれのサブネットに接続するポートを有する。サブネットケーブル３１４は、例えば、カテゴリ６ケーブルであってもよい。これらの１Ｇｂ「イーサネット」スイッチ３０４、３０６のそれぞれは、１０Ｇｂ「イーサネット」スイッチ３０２への２回線１０Ｇｂ「イーサネット」接続を有し、１０Ｇｂ「イーサネット」スイッチ３０２は、さらに、クライアントマシンのネットワーク３１６に接続されている。

一実施形態によれば、レガシークライアント３３０は、１０Ｇｂ「イーサネット」スイッチ３０２および１Ｇｂ「イーサネット」スイッチ３０４を介して、ゲートウェイサーバ３２８と通信する。ゲートウェイサーバ３２８は、レガシークライアント３３０のためのプロキシとして働き、１ＧｂＥスイッチ３０６を介してコンテンツサーバ３１２と通信する。

この例では、３つのコンテンツディレクタ３１８、３２０、３２２が存在し、それぞれのコンテンツディレクタは、１Ｇｂ「イーサネット」スイッチ３０４、３０６に、別個のインタフェースで接続されている。言い換えると、各１Ｇｂ「イーサネット」スイッチ３０４、３０６は、３つのコンテンツディレクタ３１８、３２０、３２２のそれぞれへ少なくとも１つ接続する。さらに、ネットワーキング配置は、プライベートリング１ ３２４およびプライベートリング２ ３２６と呼ばれる２つのプライベートネットワークが存在し、各プライベートネットワークは３つのノードとしてコンテンツディレクタ３１８、３２０、３２２を備えている。上記のプライベートネットワークは、専用のサブネットを意味しており、プライベートリングネットワークに限定されないということを、当業者は認識するであろう。コンテンツディレクタ３１８、３２０、３２２は、リングネットワークトポロジを使用して相互に接続され、２つのリングネットワークは冗長性を提供する。コンテンツディレクタ３１８、３２０、３２２およびコンテンツサーバ３１２は、メッシュネットワークのトポロジで接続されることが好ましい（ドナルド・クレイグ（Ｄｏｎａｌｄ Ｃｒａｉｇ）らによる「Ｌｏｇｉｃａｌ ａｎｄ Ｐｈｙｓｉｃａｌ Ｎｅｔｗｏｒｋ Ｔｏｐｏｌｏｇｙ ａｓ Ｐａｒｔ ｏｆ Ｓｃａｌａｂｌｅ Ｓｗｉｔｃｈｉｎｇ Ｒｅｄｕｎｄａｎｃｙ ａｎｄ Ｓｃａｌａｂｌｅ Ｉｎｔｅｒｎａｌ ａｎｄ Ｃｌｉｅｎｔ Ｂａｎｄｗｉｄｔｈ Ｓｔｒａｔｅｇｙ」と題された米国特許出願−Ｐ０２０を参照されたい）。図３Ａの実施形態の物理的実装の例は、各コンテンツサーバ３１２を別個のサーバブレードとして実装し、すべてのサーバブレードを同じエンクロージャまたはラックの内部に実装するものである。「イーサネット」スイッチ３０２、３０４、３０６、および３つのコンテンツディレクタ３１８、３２０、３２２も、同じラック内に配置されてもよい。本発明は、当然、単一のラックの実施形態には限定されない。コンテンツサーバ、コンテンツディレクタ、およびスイッチで満たされた追加のラックが、システム３００を拡張するために追加されてもよい。

次に、図４を参照すると、システム２００のソフトウェアアーキテクチャの例４００が示されている。システム２００は、複数のクライアントマシンユーザからシステム２００の複雑さを隠すための、メタデータサーバマシン４０２、４０４、コンテンツサーバマシン４０６、４０８、およびクライアントマシン４１０内で実行される、分散ファイルシステムプログラムを有している。言い換えると、ユーザは、この場合はオーディオおよび／またはビデオ情報の記憶および取り出しを、クライアントプログラムを介して要求してもよく、ファイルシステムは、システム２００を、ユーザから１つの単純な記憶リポジトリとして見えるようにする。ファイルの作成、書き込み、または読み出しの要求は、ネットワーク接続されたクライアント４１０から、メタデータサーバ４０２、４０４によって受信される。ファイルシステムのソフトウェア、または、この場合は、そのソフトウェアのメタデータサーバ部分は、受信した完全なファイル名を、対応するスライスハンドルに変換し、スライスハンドルは、特定のファイルの構成スライスが記憶されている、または作成されるべき、コンテンツサーバ内の位置を指す。記憶される実際のコンテンツまたはデータは、クライアント４１０によって直接、コンテンツサーバ４０６、４０８に提示される。同様に、コンテンツサーバ４０６、４０８からの読み出し動作は、クライアント４１０によってコンテンツサーバ４０６、４０８に直接要求される。

各コンテンツサーバマシン４０６、４０８は、例えば回転磁気ディスクドライブユニットなどのローカル大容量記憶ユニットを１つ以上有してもよく、そして、その１つ以上のドライブ上への特定のスライスのマッピングを管理する。その上、好ましい実施形態では、複製動作はスライスレベルで制御される。コンテンツサーバ４０６、４０８は、クライアントを関与させずに、スライスの複製を達成し、スライスの書き込みの検証をお互いに取得するために、相互に通信を行う。

その上、ファイルシステムは、複数のサーバ間に分散させられているため、ファイルシステムは、それが存在している各サーバ（それがコンテンツサーバ４０６、４０８であれ、クライアント４１０であれ、メタデータサーバ４０２、４０４であれ）の処理能力を使用してもよい。図４の実施形態に関連して以下で説明するように、記憶容量を増加させるためにコンテンツサーバを追加すると、システム内のネットワークインタフェースの総数は自動的に増加し、これは、システム内のデータにアクセスするために利用可能な帯域幅も自動的に増加することを意味している。さらに、各コンテンツサーバ内の中央処理ユニットおよび関連するメインメモリの存在により、全体としてのシステムの処理能力も増加する。そのような拡張要素（スケーリング・ファクター、scaling factor）は、より多くの記憶装置（ストレージ）およびより多くのクライアントが追加されるにつれて、システムの処理能力および帯域幅は比例的に増加し、システムがより大きくなるにつれて動きが取れなくなることはないということが保証されることを意味している。

メタデータサーバ４０２、４０４は、非アクティブなバックアップユニットであるのとは対照的に、システム２００のアクティブなメンバーであると考えられてもよい。クライアントの負荷がメタデータサーバ４０２、４０４間に分散させられるため、これが、システム２００がより多くのクライアントに対処できるように拡張することを可能にする。クライアント負荷がさらに増加するにつれて、追加のメタデータサーバが追加されてもよい。

本発明の一実施形態によれば、複製の量（「複製因子」とも呼ばれる）は、各ファイルと個別に関連付けられる。ファイル内のすべてのスライスは、同じ複製因子を共有することが好ましい。この複製因子は、ユーザによって動的に変更されてもよい。例えば、ファイルを開くための、システムのアプリケーションプログラミングインタフェース（ＡＰＩ）関数は、複製因子を指定する引数を含んでもよい。冗長性および性能対記憶コストのこのきめの細かい制御は、ユーザが、各ファイルについて別個に決定を行うことと、ファイル内に記憶されているデータの変化する価値を反映するようにそれらの決定を時間とともに変更することと、を可能にする。例えば、システム２００が、放送されるべき一連のコマーシャルと生番組部分とを作成するために使用される場合、スポーツの試合でハーフタイムの中断が始まった最初のコマーシャルは、特に高価なコマーシャルである可能性がある。したがって、ユーザは、そのようなコマーシャルファイルについての複製因子を、コマーシャルのプレイアウトの後まで一時的に増加させ、そして次に、コマーシャルが放送されたら、複製因子を適切なレベルに戻るように減少させることを望むかもしれない。

本発明の別の実施形態によれば、システム２００内のコンテンツサーバ４０６、４０８は、グループにまとめられる。グループは、スライスの複製の位置について決定を行うために使用される。例えば、物理的に同じ装置ラックまたはエンクロージャ内にあるコンテンツサーバ４０６、４０８のすべてが、１つのグループ内に配置されてもよい。ユーザは、したがって、エンクロージャ内のサーバマシンの配線によって、コンテンツサーバ４０６、４０８の間の物理的関係をシステム２００に示してもよい。スライスの複製は、次に、２つの複製がコンテンツサーバの同じグループ内にあることがないように散在させられる。これは、システム２００が、ラック全体を含む可能性があるハードウェア障害に対する耐性を有することを可能にする。

スライスの複製は、コンテンツサーバ４０６、４０８の間で内部的に処理されることが好ましい。クライアント４１０は、したがって、それらのファイルの複数のコピーを書き込む追加の帯域幅を費やすことは要求されない。本発明の一実施形態によれば、システム２００は、書き込まれているファイルについての実際の複製因子よりも少ない数の複製の書き込みの確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を、クライアント４１０が要求することができる確認応答方式を提供する。例えば、複製因子は数百であってもよく、その結果、何百もの複製についての確認応答を待つことにより、クライアントの処理に大幅な遅延がもたらされる。これは、クライアント４１０が、書き込みの速さとファイルデータの保護レベルの確実性とをトレードオフすることになるかもしれない。速度に敏感なクライアント４１０は、ほんの少しの複製のみが作成された後の確認応答を要求してもよい。対照的に、機密性の高い、または価値の高いデータを書き込むクライアント４１０は、指定された数の複製がすべて作成された後にのみ、コンテンツサーバによって確認応答が提供されることを要求してもよい。

本発明の一実施形態によれば、ファイルは、システム２００内に記憶される際に、スライスに分割される。好ましい場合、スライスは、一般的なＲＡＩＤまたはストレージエリアネットワーク（ＳＡＮ）システム内で使用される従来のディスクブロックまたはストライプとは対照的な、インテリジェントなオブジェクトであると考えることができる。インテリジェンスは、少なくとも２つの特徴に由来する。第１に、各スライスは、ファイル（そのファイルのデータをそのスライスが保持する）に関する情報を含んでいてもよい。これによりスライスは自己の位置が（ｓｅｌｆ−ｌｏｃａｔｉｎｇ）決められる。第２に、各スライスは、チェックサム情報を保持してもよく、これによりスライスは自己検証（ｓｅｌｆ−ｖａｌｉｄａｔｉｎｇ）する。従来のファイルシステムでは、（ハードウェアまたはその他の障害により）ファイルデータの位置を示すメタデータが失われた場合、ファイルデータは、ファイルの断片を継ぎ合わせるための骨の折れる手作業によってのみ、回復することが可能である。本発明の一実施形態によれば、システム２００は、スライス自体の中に記憶されたファイル情報を使用して、自動的にファイルを継ぎ合わせることが可能である。これは、システム２００における複製機構に加えて、追加の保護を提供する。従来のブロックまたはストライプとは異なり、スライスは、集中型データ構造における破損によって失われることはありえない。

ファイルコンテンツ情報に加えて、スライスは、スライス作成の瞬間に作成されてもよいチェックサム情報も保持する。このチェックサム情報は、スライスとともに存在するように命じられ、そして、スライスが複製される際に、スライスとともにシステム全体にわたって運ばれる。チェックサム情報は、すべての複雑な電子システム内に一般に存在するランダムなハードウェアエラーによってスライス内のデータが破損してはいないことの検証を提供する。コンテンツサーバ４０６、４０８は、それらの中に記憶されているすべてのスライスについて、読み出しとチェックサム計算の実行とを継続的に行うことが好ましい。これは、データの破損をアクティブに検査すること（ａｃｔｉｖｅｌｙ ｃｈｅｃｋｉｎｇ）とも呼ばれる。これは、スライスデータがクライアントによって要求される前に事前の警告を提供するタイプのバックグラウンド検査活動であり、したがって、ファイル読み出しの間にエラーが発生する可能性は減少し、そして、他の場合ならばスライスの複製が破損したままになっている可能性がある時間の量を減少させる。

図５は、一実施形態による、分散ファイルシステム内のトランスコーディングシステムを示すブロック図である。クライアント５０２は、トランスコードマネージャ５０４を有してもよい。トランスコードマネージャ５０４は、分散ファイルシステム５００へファイルをトランスコードする要求を生成するように構成される。分散ファイルシステム５００は、ファイルの各部分を異なる物理的記憶位置にわたって記憶する。一実施形態によれば、物理的記憶位置の割り当ては、コンテンツサーバ５１０、５１２、および５１４を含んでもよい。分散ファイルシステム５００は、スイッチ５０６、コンテンツディレクタ５０８、およびコンテンツサーバ５１０、５１２、５１４を含む。各コンテンツサーバは、ファイルの少なくとも一部を、第１のフォーマットから第２のフォーマットにトランスコードするように構成されてもよい。例えば、ファイルのオーディオ／ビデオコンテンツは、高解像度フォーマットから低解像度フォーマットに変換されてもよい。各コンテンツサーバ５１０、５１２、５１４は、それぞれ、処理ユニット５１６、５２０、５２４と、ハードドライブまたはメモリなどのコンテンツ記憶装置５１８、５２２、５２６とを含んでもよい。

別の実施形態によれば、コンテンツサーバ５１０は、コンテンツサーバ５１２上に存在するファイルの一部をトランスコードするために、コンテンツサーバ５１２にアクセスしてもよい。コンテンツサーバ５１０は、したがって、クライアント５０２のためのトランスコーディングクライアントとして動作してもよい。

各コンテンツサーバの処理ユニットは、トランスコーディングプロセスが、コンテンツサーバの主要な役割である記憶装置としての機能を提供することを妨げない限り、トランスコーディングを実行するために使用されてもよい。処理ユニットが、トランスコーディングプロセスによって酷使されていないことを確実にするために、各コンテンツサーバは、独立した論理部分に区分けされてもよい。例えば、コンテンツサーバの第１の独立した論理部分は、記憶装置としての機能の処理のためにのみ使用されてもよい。コンテンツサーバの第２の独立した論理部分は、トランスコーディング機能の処理のために使用されてもよい。その他の論理部分は、セキュリティなどの、さらなる機能を処理するために使用されてもよい。コンテンツサーバは多くの方法で区分けされてもよいということを、当業者は認識するであろう。

図６は、一実施形態による、分散ファイルシステム内のコンテンツをトランスコードするための方法を示すフロー図である。６０２において、ファイルをトランスコードする要求が、分散ファイルシステムによって受信される。一実施形態によれば、クライアントのトランスコードマネージャが、ファイルをトランスコードする要求を生成する。分散ファイルシステムは、複数の異なる物理的記憶位置にわたってファイルの各部分を割り当てて記憶する。

６０４において、ファイルは、物理的記憶位置のうちの少なくとも１つの処理ユニットを使用して、第１のフォーマットから第２のフォーマットにトランスコードされる。別の実施形態によれば、１つのコンテンツサーバが、分散ファイルシステムの別の第２のコンテンツサーバに、ファイルの一部をトランスコードするためにアクセスしてもよい。１つのコンテンツサーバが、その自らの処理ユニット上で、または、他のコンテンツサーバの他の処理ユニット上でファイルをトランスコードするトランスコーディングクライアントとして動作してもよい。トランスコードされたファイルは、ファイル分散システム内に記憶されてもよい。一実施形態によれば、コンテンツサーバの第１の独立した論理部分が、セキュリティ機能を処理するために区分けされてもよい。コンテンツサーバの第２の独立した論理部分が、トランスコーディング機能を処理するために区分けされてもよい。

６０６において、分散ファイルシステムは、トランスコードされたファイルをクライアントに送信する。

以上の明細書において、本発明を、その特定の例示的実施形態を参照して説明してきた。しかし、それに対するさまざまな修正および変更が、添付の特許請求の範囲に記載された本発明のより広範な趣旨および範囲を逸脱することなく行われてもよいということは明白であろう。明細書および図面は、したがって、限定的な意味ではなく、例示的な意味であるとみなされるべきである。

ビデオ処理環境の一部として使用されている、本発明の一実施形態による、データ記憶システムを示す。 一実施形態による、データ記憶システムのシステムアーキテクチャを示す。 データ記憶システムの一実施形態のネットワークトポロジを示す。 データ記憶システムの一実施形態のネットワークトポロジを示す。 一実施形態による、データ記憶システムのソフトウェアアーキテクチャを示す。 一実施形態による、分散ファイルシステム内のトランスコーディングシステムを示すブロック図である。 一実施形態による、分散ファイルシステム内のコンテンツをトランスコードするための方法を示すフロー図である。

Claims (21)

1. 分散ファイルシステムのファイルをトランスコードするための方法であって、
   前記分散ファイルシステムが、前記ファイルの部分を複数の異なる物理的記憶位置にわたって記憶するステップであって、前記ファイルの部分が前記ファイルに関連付けられた複数のファイルスライスを含み、各ファイルスライスが、前記複数のファイルスライスから前記ファイルに自動的に継ぎ合わせるために前記分散ファイルシステムにより使用される自己の位置情報を格納しているステップと、
   前記ファイルをトランスコードする要求を受信するステップと、
   前記ファイルの前記部分を異なる物理的記憶位置に移動させずに、前記ファイルの前記部分を、第１のフォーマットから第２のフォーマットにトランスコードするステップであって、前記ファイルの前記部分のそれぞれは、前記部分が置かれている前記物理的記憶位置の処理ユニットを使用してトランスコードされるステップとを含むことを特徴とする方法。
2. 前記第２のフォーマットを有する前記ファイルを、前記ファイル分散システム内に記憶するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記要求を、クライアントから受信するステップと、
   前記トランスコードされたファイルを前記クライアントに送信するステップとをさらに含むことを特徴とする請求項１に記載の方法。
4. 前記要求を、前記クライアントのトランスコードマネージャから受信するステップをさらに含むことを特徴とする請求項３に記載の方法。
5. 前記ファイル分散システムは、
   スイッチと、
   前記スイッチに結合されたコンテンツディレクタと、
   前記コンテンツディレクタに結合された複数のコンテンツサーバであって、ファイルの各部分を記憶する複数のコンテンツサーバとを含むことを特徴とする請求項１に記載の方法。
6. 少なくとも１つの物理的記憶位置は、少なくとも１つのコンテンツサーバを含むことを特徴とする請求項５に記載の方法。
7. 各コンテンツサーバは、
   コンテンツ記憶装置と、
   前記コンテンツ記憶装置に結合された処理ユニットとをさらに含むことを特徴とする請求項６に記載の方法。
8. 第１のコンテンツサーバは、前記ファイルの部分をトランスコードするために、第２のコンテンツサーバにアクセスすることを特徴とする請求項６に記載の方法。
9. 記憶機能を処理するための前記コンテンツサーバの第１の独立した論理部分を区分するものであることを特徴とする請求項５に記載の方法。
10. トランスコーディング機能を処理するための前記コンテンツサーバの第２の独立した論理部分を区分するものであることを特徴とする請求項９に記載の方法。
11. ファイルの部分を複数の異なる物理的記憶位置にわたって記憶する分散ファイルシステムであって、前記ファイルの部分が前記ファイルに関連付けられた複数のファイルスライスを含み、各ファイルスライスが、前記複数のファイルスライスから前記ファイルに自動的に継ぎ合わせる合わせるために前記分散ファイルシステムにより使用される自己の位置情報を格納している分散ファイルシステムを含む装置であって、
    各物理的記憶位置は、前記ファイルをトランスコードする要求を受信し、前記ファイルの前記部分を異なる物理的記憶位置に移動させずに、前記ファイルの前記部分を、第１のフォーマットから第２のフォーマットにトランスコードするように構成され、前記ファイルの前記部分のそれぞれは、前記部分が置かれている前記物理的記憶位置の処理ユニットを使用してトランスコードされることを特徴とする装置。
12. 各物理的記憶位置は、前記物理的記憶位置のうちの少なくとも１つの処理ユニットを使用してトランスコードするように構成されることを特徴とする請求項１１に記載の装置。
13. 前記ファイル分散システムは、
    スイッチと、
    前記スイッチに結合されたコンテンツディレクタと、
    前記コンテンツディレクタに結合された複数のコンテンツサーバであって、前記ファイルの部分を記憶する複数のコンテンツサーバとをさらに備えることを特徴とする請求項１１に記載の装置。
14. 前記分散ファイルシステムに結合されたクライアントであって、前記分散ファイルシステムへの前記ファイルをトランスコードする要求を生成するように構成されたトランスコードマネージャを有するクライアントをさらに備えることを特徴とする請求項１１に記載の装置。
15. 各コンテンツサーバは、
    コンテンツ記憶装置と、
    前記コンテンツ記憶装置に結合された処理ユニットとをさらに含むことを特徴とする請求項１３に記載の装置。
16. 第１のコンテンツサーバは、前記ファイルの部分をトランスコードするために、第２のコンテンツサーバにアクセスすることを特徴とする請求項１３に記載の装置。
17. 記憶機能を処理するための前記コンテンツサーバの第１の独立した論理部分を区分することを特徴とする請求項１３に記載の装置。
18. トランスコーディング機能を処理するための前記コンテンツサーバの第２の独立した論理部分を区分することをさらに含むことを特徴とする、請求項１７に記載の装置。
19. 分散ファイルシステムのファイルをトランスコードするための方法を実行するためのマシンによって実行可能な命令のプログラムを具体的に組み込んだ前記マシンによって読み取り可能なプログラム記憶装置であって、前記方法は、
    前記分散ファイルシステムが、前記ファイルの部分を複数の異なる物理的記憶位置にわたって記憶するステップであって、前記ファイルの部分が前記ファイルに関連付けられた複数のファイルスライスを含み、各ファイルスライスが、前記複数のファイルスライスから前記ファイルに自動的に継ぎ合わせるために前記分散ファイルシステムにより使用される自己の位置情報を格納しているステップと、
    前記ファイルをトランスコードする要求を受信するステップと、
    前記ファイルの前記部分を異なる物理的記憶位置に移動させずに、前記ファイルの前記部分を、第１のフォーマットから第２のフォーマットにトランスコードするステップであって、前記ファイルの前記部分のそれぞれは、前記部分が置かれている前記物理的記憶位置の処理ユニットを使用してトランスコードされるステップとを含むことを特徴とするプログラム記憶装置。
20. 前記第２のフォーマットを有する前記ファイルを、前記ファイル分散システム内に記憶するステップをさらに備えることを特徴とする請求項１９に記載の方法。
21. 前記要求をクライアントから受信するステップと、
    前記トランスコードされたファイルを前記クライアントに送信するステップとをさらに備えることを特徴とする請求項１９に記載の方法。

Images