JP5004975B2

JP5004975B2 - データ記憶システム

Info

Publication number: JP5004975B2
Application number: JP2008558418A
Authority: JP
Inventors: ハーシャダスワニガセカラ−モホッティ，ドン; エムクレイグ，ドナルド; ミタル，アレクサンドルー; デイヴィス，クリストファー; エドワードハウエ，ジョン
Original assignee: ハーモニックインコーポレイテッド
Priority date: 2006-03-08
Filing date: 2007-03-03
Publication date: 2012-08-22
Anticipated expiration: 2027-03-03
Also published as: EP1994722A1; WO2007103552A1; WO2007103552B1; JP2009529193A; US20070226224A1

Description

本発明の実施形態は、一般に、高い容量、性能、およびデータ可用性を有する電子データ記憶システムに関し、特に、記憶容量およびクライアントを追加することに関してスケーラブルな電子データ記憶システムに関する。その他の実施形態も説明され特許請求される。

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

メディアサーバと呼ばれる強力なデータ記憶システムが、カリフォルニア州サニーヴェール（Ｓｕｎｎｙｖａｌｅ，Ｃａｌｉｆｏｒｎｉａ）のオムネオン・ビデオネットワークス（ＯｍｎｅｏｎＶｉｄｅｏＮｅｔｗｏｒｋｓ）（本特許出願の譲受人）によって提供されている。メディアサーバは、サーバマシンのネットワーク上で実行されている複数のソフトウェア構成要素から構成される。サーバマシンは、データを記憶する回転磁気ディスクドライブなどの大容量記憶装置を有する。サーバは、ファイルの作成、書き込み、または読み出しの要求を受け入れ、そして、１つ以上のディスクドライブ内にデータを転送するプロセス、または要求された読み出しデータをそれらのディスクドライブから送り出すプロセスを管理する。サーバは、どのファイルがどのドライブに記憶されているかを追跡記録する。ファイルへのアクセス要求、すなわち、作成、書き込み、または読み出しの要求は、通常、サーバネットワークに接続されたクライアントマシン上で実行されていてもよいクライアントアプリケーションプログラムと呼ばれるものから受信される。例えば、アプリケーションプログラムは、（システム内にデジタルビデオファイルとして記憶された）特定のビデオクリップを必要とする、テレビジョンスタジオのワークステーション上で実行されているビデオ編集アプリケーションであってもよい。

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

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

記憶システムは、さらに、複雑なハードウェアおよびソフトウェアの交換を行う必要なしに、より大きなデータ記憶の要求、および増加するクライアント負荷に対処するために、容易に拡張するように、スケーラブルでなければならない。

本発明の実施形態は、限定のためではなく、例として、同様の参照符は同様の要素を示す添付の図面の図中に示されている。本開示における、本発明の「一（ａｎ）」実施形態への言及は、必ずしも同じ実施形態への言及とは限らず、そしてそれらは、少なくとも１つを意味していることに留意すべきである。

本発明の一実施形態は、容量、性能、およびデータ可用性の厳しい要求を、よりスケーラブルなアーキテクチャを使用して、より良く達成することが可能なデータ記憶システムである。図１は、ビデオおよびオーディオ情報処理環境の一部としての、そのような記憶システムを示す。しかし、以下に記載するデータ記憶システムならびにその構成要素または特徴は、代わりに、その他のタイプの適用例（例えば、図書館、地震探査データ処理センター、販売業者の製品カタログ、中央企業情報記憶など）において使用されてもよいということに留意すべきである。オムネオンコンテンツライブラリ（Ｏｍｎｉｏｎｃｏｎｔｅｎｔｌｉｂｒａｒｙ）（ＯＣＬ）システムとも呼ばれる、記憶システム１０２は、データ保護、ならびに、ハードウェアおよびソフトウェアの耐障害性と復旧とを提供する。

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

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

本発明の一実施形態は、停止することなく動作するために設計されたＯＣＬシステムであって、記憶装置と、クライアントと、その構成要素間のネットワーキング帯域幅との拡張を、進行中のアクセスをシャットダウン、あるいは、それらのアクセスに影響を及ぼすことなく行うことが可能になるシステムである。ＯＣＬシステムは、障害となるただ１つの点（ｓｉｎｇｌｅｐｏｉｎｔｏｆｆａｉｌｕｒｅ）が存在しないように、十分な冗長性を有することが好ましい。ＯＣＬシステム内に記憶されたデータは複数の複製を有し、したがって、大容量記憶ユニット（例えば、ディスクドライブユニット）、さらにはサーバ全体が損なわれても、データを失うことはない。一般的なＲＡＩＤシステムとは異なり、ＯＣＬシステムの交換されたドライブユニットは、先の（故障した）ドライブと同じデータを含む必要はない。その理由は、ドライブの交換が実際に発生するまでには、関連するデータ（故障したドライブに記憶されていたファイルスライス）は、ファイルの作成時に始まったファイル複製のプロセスによって、すでに他の場所に保存されているからである。ファイルは、ハードウェア障害から保護するために、さまざまなドライブにわたって、システム内に複製される。これは、一時点における任意の１つのドライブの障害が、記憶されたファイルがシステムによって再構成されることが不可能なることはないことを意味し、その理由は、ファイルのいかなる失われたスライスも、他のドライブ内で依然として見つけることが可能だからである。複製は、さらに、ファイルをより多くのサーバからアクセス可能にすることによって、読み出し性能の向上を支援する。

どのファイルがどこに記憶されているか（または、ファイルのスライスがどこに記憶されているか）を追跡記録するために、ＯＣＬシステムは、新たに作成されたまたは以前に記憶されたファイルのファイル名と、そのスライスと、スライスを実際に含むシステムの記憶要素の識別情報との間のマッピングを含むメタデータ（ファイルに関する情報）の知識を有するメタデータサーバプログラムを有する。

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

次に、図２を参照すると、本発明の一実施形態による、複数のクライアントに接続されたデータ記憶システムのシステムアーキテクチャが示されている。システムは複数のメタデータサーバマシンを有し、各メタデータサーバマシンは、システム内に記憶されている複数のファイルについてのメタデータを記憶する。そのようなマシン内で実行されているソフトウェアは、メタデータサーバ２０４と呼ばれる。メタデータサーバは、ＯＣＬシステムの動作の管理を担当してもよく、そして、クライアントにとっての最初の接点である。スマートクライアント２０８およびレガシークライアント２１０という、２つのタイプのクライアントが示されていることに留意されたい。スマートクライアントは、システムの現在のインタフェースの知識を有し、システムのシステム相互接続２１４（ここでは、Ｇｂイーサネット（登録商標）ネットワーキングスイッチを含む）に直接接続することが可能である。システム相互接続は、図示されているように、複数のコンテンツサーバ２１６およびメタデータサーバ２０４の間の選択的ブリッジとして働いてもよい。もう一方のタイプのクライアントは、現在のファイルシステムドライバ（ＦＳＤ）がインストールされていない、または、ＯＣＬシステムのために現在提供されているソフトウェア開発キット（ＳＤＫ）を使用しない、レガシークライアントである。レガシークライアントは、ＯＣＬシステム専用ではない一般的なファイルシステムインタフェースを使用して、図示されているようにプロキシまたはコンテンツゲートウェイ２１９を介して、システム相互接続２１４と間接的に通信を行う。

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

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

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

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

図２には示していないが、ＯＣＬシステムのコンフィギュレーションおよび監視を担当する、例えば、独立したラックマウント式サーバマシン上で動作するシステムマネージャがさらに提供されてもよい。

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

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

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

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

冗長なサブネットは、メタデータおよびコンテンツサーバへの確実な接続性を提供する。システム内の障害耐性の向上を提供するために、システムは、そのようなネットワークトポロジの知識、例えば、メタデータサーバおよびコンテンツサーバによりそれらが接続されている冗長サブネットの知識を用いる。

この例では、３つのメタデータサーバが存在し、それぞれのメタデータサーバは、１Ｇｂ「イーサネット」スイッチに、別個のインタフェースで接続されている。言い換えると、各１Ｇｂ「イーサネット」スイッチは、３つのメタデータサーバのそれぞれへ少なくとも１つ接続している。さらに、ネットワーキング配置は、プライベートリング１およびプライベートリング２と呼ばれる２つのプライベートネットワークが存在し、各プライベートネットワークは３つのメタデータサーバをそのノードとして備えている。メタデータサーバは互いに、リングネットワークのトポロジを用いて接続され、２つのリングネットワークは冗長性を提供する。メタデータサーバおよびコンテンツサーバは、メッシュネットワークのトポロジで接続されることが好ましい（本出願の一部であるかのように、参照により本明細書に援用される、ＡｄｒｉａｎＳｆａｒｔｉらによる「ＮｅｔｗｏｒｋＴｏｐｏｌｏｇｙｆｏｒａＳｃａｌａｂｌｅＤａｔａＳｔｏｒａｇｅＳｙｓｔｅｍ」と題された米国特許出願−Ｐ０２０を参照されたい）。図３の実施形態の物理的実装の例は、各コンテンツサーバを別個のサーバブレード内に実装し、すべてのサーバブレードを同じエンクロージャまたはラックの内部に実装するものである。「イーサネット」スイッチおよび３つのメタデータサーバも、同じラック内に配置されてもよい。本発明は、当然、１ラックの実施形態には限定されない。コンテンツサーバ、メタデータサーバ、およびスイッチで満たされた追加のラックが、ＯＣＬシステムを拡張するために追加されてもよい。より一般的には、システムのコンテンツサーバマシンは、グループにまとめられてもよく、各グループ内のメンバーは、電源、モデルタイプ、および特定のスイッチングトポロジへの接続性などの何らかの共通の設置パラメータ（ｉｎｓｔａｌｌａｔｉｏｎｐａｒａｍｅｔｅｒｓ）を共有する。例えば、一つのグループ分けにおいては、各グループは、同じラック内にあり、かつ、同じ電源を共有するすべてのサーバブレードを含む。

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

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

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

図４をさらに参照すると、メタデータサーバは、非アクティブなバックアップユニットであるのとは対照的に、システムのアクティブなメンバーであると考えられる。言い換えると、ＯＣＬシステムのメタデータサーバは、同時にアクティブになり、そしてそれらは、意思決定において協働する。例えば、コンテンツサーバが故障した場合、各スライスに対して要求されている複製因子を維持するために、そのコンテンツサーバ上に記憶されていたコンテンツは、残っているコンテンツサーバから複製される。複製プロセスは、メタデータサーバによって管理される。複製プロセスは、メタデータサーバ間に等しく分配され、そして、各メタデータサーバが複製プロセスのその部分を担当する。クライアントの負荷はメタデータサーバ間に分散させられるため、これによりシステムがより多くのクライアントに対処できるように拡張することを可能にする。クライアント負荷がさらに増加するにつれて、追加のメタデータサーバが追加されてもよい。

複数のメタデータサーバによる協働処理の例は、コンテンツサーバ上に記憶されたスライス情報の整合性の検証である。メタデータサーバは、スライス記憶の、そのメタデータサーバのビューとコンテンツサーバのビューとの間のあらゆる違いを調整することを担当する。それらのビューは、より数の少ないディスクを持つコンテンツサーバがシステムに再び加えられる場合や、あるいは、より早い使用時から、異なっている可能性がある。何十万ものスライスが１つのコンテンツサーバ上に記憶されてもよいため、それらのビューの違いを調整するためのオーバヘッドは、かなり大きくなる可能性がある。それらのビューのあらゆる違いが調整されるまで、コンテンツサーバの準備は確立されないため、スライスビューのあらゆる違いを調整するための時間を最小にすることにより、即座にメリットが得られる。複数のメタデータサーバが、そのようなコンテンツサーバによってサポートされるデータファブリックの部分を分割し、さまざまなパーティションを並行して同時に調整する。この並行処理の間にメタデータサーバが故障した場合は、残りのメタデータサーバがすべての未処理の調整を完了するように分割を再調整する。メタデータサーバのスライスのビューのあらゆる変化が、すべてのアクティブなメタデータサーバ間で動的に共有される。

別の例は、１つまたは複数のコンテンツサーバがデータファブリックをもはやサポートできなくなった場合に、大規模な再複製を共同で処理することである。大規模な再複製は、ネットワークオーバヘッドと処理オーバヘッドが加わることを意味する。これらの場合、メタデータサーバは、このオーバヘッドが、利用可能なメタデータサーバおよび対応するネットワーク接続間に散在させることができるように、再複製する領域を動的に分割して、データファブリックおよび対応するデータファイル内の対応する「壊れた部分」をインテリジェントに修復する。

別の例は、１つまたは複数のコンテンツサーバがデータファブリックをもはやサポートできないということを共同で確認することである。場合によっては、コンテンツサーバは、完全にアクセス不可能ではないが部分的にアクセス不可能になることがある。例えば、組み込まれたネットワーク冗長性のため、スイッチの構成要素が故障する場合がある。これは、すべてではないが一部のメタデータサーバが、１つまたは複数のコンテンツサーバを監視するための連絡が行えないという結果になる可能性がある。コンテンツサーバが少なくとも１つのメタデータサーバにアクセスできる場合には、関連するデータの分割された一部は再複製される必要はない。大規模な再複製は、かなりの処理オーバヘッドを生じさせる可能性があるため、メタデータサーバにとって、不必要な再複製を回避することは重要である。これを達成するために、メタデータサーバは、ネットワーク内のアクティブなコンテンツサーバのそれらのビューを交換する。１つのメタデータサーバが、特定のコンテンツサーバをもはや監視することができない場合、そのメタデータサーバは、大規模な再複製の開始を決定する前には他のメタデータサーバと協議する。

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

メタデータサーバによる協働の別の例では、複製因子の減少が指定された場合に発生する。それらの場合、負荷のバランスを取ることとデータ可用性とネットワーク経路とに従ってどの位置を解除するかを決定するために、データファブリックのグローバルビューが使用される。

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

グループの数と複製の数とは独立した値であり、いずれかが他方に依存することはない。スライスの複製の数がグループの数よりも少ない場合、複製はそのより少ない数のグループ間に散在させられることが好ましい。スライスの複製の数がグループの数よりも多い場合、一部の複製は、同じグループ内に配置されるが、同じコンテンツサーバ上に配置されることはない。したがって、使用されるグループの数は、複製の数およびグループの数の両方の上限まで、最大化されることが好ましい。

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

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

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

本発明の一実施形態は、上述の動作のうちの一部を実行するように１つ以上のプロセッサをプログラムする命令が記憶された機械で読み取り可能な媒体であってもよい。他の実施形態では、それらの動作のうちの一部は、ハードウェアロジックを含む特定のハードウェア構成要素によって実行されてもよい。それらの動作は、代わりに、プログラムされたコンピュータ構成要素とカスタム化されたハードウェア構成要素との任意の組み合わせによって実行されてもよい。

機械読み取り可能な媒体は、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、およびインターネット上の伝送に限定されない、マシン（例えば、コンピュータ）による読み出しが可能な形態で情報を記憶または伝送するための任意の機構を含んでもよい。

本発明は、上述の特定の実施形態に限定されない。例えば、ＯＣＬシステムは、大容量記憶ユニットとして回転磁気ディスクドライブのみを使用する現在のバージョンを用いて説明したが、磁気ディスクドライブの代替が、システムに必要な速度、記憶容量、およびコストの要求をそれらが満たす限り可能である。したがって、その他の実施形態が特許請求の範囲に含まれる。

ビデオ処理環境の一部として使用されている、本発明の一実施形態による、データ記憶システムを示す。本発明の一実施形態による、データ記憶システムのシステムアーキテクチャを示す。データ記憶システムの一実施形態のネットワークトポロジを示す。本発明の一実施形態による、データ記憶システムのソフトウェアアーキテクチャを示す。

Claims

クライアントマシンからアクセスされることが可能なデータ記憶システムであって、
複数のメタデータサーバマシンであって、各メタデータサーバマシンは、データ記憶システム内に記憶されている複数のファイルについてのメタデータを記憶するように構成される複数のメタデータサーバマシンと、
複数のグループとして配備された複数のコンテンツサーバマシンであって、各グループはそれぞれの１つ以上の前記コンテンツサーバマシンを有し、前記コンテンツサーバマシンのそれぞれは、前記ファイルのスライスを前記メタデータによって示された位置において記憶するように構成される複数のコンテンツサーバマシンと、
前記メタデータサーバマシンおよびコンテンツサーバマシンが通信可能に結合されたシステム相互接続ハードウェアと、
前記メタデータサーバマシン、前記コンテンツサーバマシンおよび前記クライアントマシンの中で実行される分散ファイルシステムであって、前記ファイルのそれぞれを、前記コンテンツサーバマシンのうちの２つ以上および前記グループのうちの２つ以上にわたって散在させるように構成される分散ファイルシステムとを備え、
各ファイルのスライスは、自己の位置を定めることができるファイル情報を含むことを特徴とするデータ記憶システム。
前記サーバマシンは、１つ以上の共通の設置パラメータを有することに基づいてグループ分けされ、前記共通の設置パラメータは、ａ）同じ電源を共有すること、ｂ）同じハードディスクドライブモデルタイプを有すること、およびｃ）前記システム相互接続ハードウェア内の同じパケットスイッチに接続されていることを表すパラメータのいずれかであることを特徴とする請求項１に記載のデータ記憶システム。
前記データ記憶システムが、ストレージ、クライアント、要素間のネットワーク帯域を、進行中のアクセスをシャットダウンすることなく、または進行中のアクセスに影響を与えることなく拡張できるように構成されていることを特徴とする請求項２に記載のデータ記憶システム。
前記ファイルの１つ以上のスライスの複製が作成され、前記ファイルおよびそれらのスライスの複製は、所定の複製数に対して可能な限り多くのグループ内に前記スライスの複製が存在するように、前記コンテンツサーバマシンにわたって散在させられることを特徴とする請求項３に記載のデータ記憶システム。
前記分散ファイルシステムは、前記ファイルの前記スライスを複製することについての、クライアントによって指定された数の確認応答を受け入れることを特徴とする請求項１に記載のデータ記憶システム。
前記分散ファイルシステムは、
ａ）第１の確認応答レベルであって、前記第１の確認応答レベルのために、前記分散ファイルシステムは、前記ファイルが一組の回数分の複製が作成される前に、複製の確認応答をクライアントに提供する第１の確認応答レベルと、
ｂ）第２の確認応答レベルであって、前記第２の確認応答レベルのために、前記分散ファイルシステムは、前記ファイルが前記一組の回数分だけ複製が作成された後にのみ、複製の確認応答をクライアントに提供する第２の確認応答レベルとを受け入れることを特徴とする請求項１に記載のデータ記憶システム。
前記システム相互接続ハードウェアは２つの独立したサブネットに分割され、その結果により、前記メタデータサーバマシンおよびコンテンツサーバマシンは、１つのサブネット内での接続が失われたことを検出して、残りのサブネットを利用することによって動作を継続することが可能であることを特徴とする請求項１に記載のデータ記憶システム。
データ記憶システムを動作させるための方法であって、
前記データ記憶システムが、複数のメタデータサーバマシンであって、各メタデータサーバマシンは、前記データ記憶システム内に記憶されている複数のファイルについてのメタデータを記憶するように構成される複数のメタデータサーバマシンと、複数のグループとして分類された複数のコンテンツサーバマシンであって、各グループがそれぞれの１つ以上の前記コンテンツサーバマシンを有し、前記コンテンツサーバマシンのそれぞれは、前記ファイルのスライスを前記メタデータによって示された位置において記憶するように構成される複数のコンテンツサーバマシンと、前記メタデータサーバマシンおよびコンテンツサーバマシンが通信可能に結合されたシステム相互接続ハードウェアと、前記メタデータサーバマシン、前記コンテンツサーバマシンおよび前記クライアントマシンの中で実行される分散ファイルシステムであって、前記ファイルのそれぞれを、前記コンテンツサーバマシンのうちの２つ以上および前記グループのうちの２つ以上にわたって散在させるように構成される分散ファイルシステムとを備え、各ファイルのスライスは、自己の位置を定めることができるファイル情報を含み
前記方法は、
ファイルを作成するための第１のクライアント要求を受信して、前記ファイルのスライスが前記分散ファイルシステム内のどこに記憶されているかまたは記憶されるであろうかを示すファイルハンドルを応答するステップと、
前記ファイルのスライスを作成するための前記ファイルハンドルを含む第２のクライアント要求を受信して、異なるグループの複数のコンテンツサーバマシンの識別情報を応答するステップと、
前記ファイルについてのさまざまな複製因子を指定する複数のクライアント要求を受信して、さまざまなグループにわたってスライスの複製を散在させることにより、前記スライスの複製の数および位置を変更することによって応答するステップとを含むことを特徴とする方法。
コンピュータで実行されることによりデータ記憶システムを実現させるコンピュータプログラム命令の１つ以上のシーケンスが記憶された機械読み取り可能な媒体であって、
前記データ記憶システムが、複数のメタデータサーバマシンであって、各メタデータサーバマシンが、前記データ記憶システム内に記憶されている複数のファイルについてのメタデータを記憶するように構成される複数のメタデータサーバマシンと、複数のグループとして分類された複数のコンテンツサーバマシンであって、各グループがそれぞれの１つ以上の前記コンテンツサーバマシンを有し、前記コンテンツサーバマシンのそれぞれは、前記ファイルのスライスを前記メタデータによって示された位置において記憶するように構成される複数のコンテンツサーバマシンと、前記メタデータサーバマシンおよびコンテンツサーバマシンが通信可能に結合されたシステム相互接続ハードウェアと、前記メタデータサーバマシン、前記コンテンツサーバマシンおよび前記クライアントマシンの中で実行される分散ファイルシステムであって、前記ファイルのそれぞれを、前記コンテンツサーバマシンのうちの２つ以上および前記グループのうちの２つ以上にわたって散在させるように構成される分散ファイルシステムとを備え、各ファイルのスライスは、自己の位置を定めることができるファイル情報を含み、
前記データ記憶システムに、
ファイルを作成するための第１のクライアント要求を受信し、前記ファイルのスライスが前記データ記憶システム内のどこに記憶されているかまたは記憶されるであろうかを示すファイルハンドルを使用して応答する機能と、
前記ファイルのスライスを作成するための前記ファイルハンドルを含む第２のクライアント要求を受信し、異なるグループの複数のコンテンツサーバマシンの識別情報を使用して応答する機能と、
前記ファイルについてのさまざまな複製因子を指定する複数のクライアント要求を受信し、さまざまなグループにわたってスライス複製を散在させることにより、前記スライス複製の数および位置を変更することによって応答する機能を実現させるためのコンピュータプログラム命令の１つ以上のシーケンスが記憶された機械読み取り可能な媒体。