JP2004500660A5 - - Google Patents

Description

ネットワークストレージシステム

本発明は、ストレージの分野、および、特にローカル装置の使用を通してリモートストレージにアクセスすることを目的とする。

音楽、フィルムおよび写真の急速なデジタル化にともない、顧客の需要により、インターネットはデジタル媒体の全ての形式に対する最も好ましい移送機構になっている。インターネットを使用して、ユーザーは、彼（女）らの好きな映画、歌または個人的な思い出の品に対する即時の全世界に及ぶアクセスを有する。メディアコンテンツの製作者および所有者が全世界に及ぶ配布のための第一の方法としてますますインターネットを使用するにつれて、インターネットを通じて利用できるリッチメディアコンテンツの総計の量は極めて急速な割合で増加している。

インターネットを通じて利用できるリッチメディアオブジェクトの数が、指数的に増大しているだけでなく、本願明細書において一般にオブジェクトと称されるメディアのサイズもまた、劇的に増大している。中央値のウエブオブジェクトは、５キロバイト（ＫＢ）のサイズであるが、一方、リッチメディアオブジェクトのサイズは、１００ないし１００万倍大きい場合がある。例えば、高解像度デジタル写真は画像あたり平均で５００ＫＢに達する。デジタル音楽は曲あたり３ないし５メガバイト（「ＭＢ」）に達し、および、デジタル映画は大きさにおいて４ギガバイト（「ＧＢ」）まで達する場合がある。

パーソナルコンピュータ、デジタルカムコーダ、デジタルカメラおよびパーソナルデジタルオーディオプレーヤの数が増大するにつれて、インターネットを横断してメディアファイルを格納して、共有して、取り出すインターネット帯域幅に対する需要も増える。インターネットバックボーンの成長を支える、広帯域のデジタル加入者線（「ＤＳＬ」）、ケーブルモデムおよびデジタル放送衛星ネットワークの使用が人気を増すにつれて、インターネットをリッチメディアオブジェクトに対する主要な配信チャンネルとして使用する需要もまた、人気を増す。この発展は広帯域ネットワークの設置がリッチメディアデバイスの使用を駆動する良いサイクルを引き起こし、それは次にネットワーク帯域幅、その他の更なる改善に対する需要を創造する。

インターネットを横断するリッチメディアオブジェクトの分散は、これらのリッチメディアオブジェクトを格納するために増加した記憶容量に対するニーズを生成する。パーソナルメディアデバイスの数が増大し、および、ネットワーク帯域幅が拡大するにつれて、さまざまなＭＰ３ファイル、写真、フィルムおよびビデオクリップを格納することを必要とする記憶媒体の量もまた、増大する。また、より多くのストレージが直ちに利用できるようになるにつれて、より多くの人々がインターネットを使用して、彼（女）らのリッチメディアオブジェクト（例えば家族のデジタル写真）を分類し、格納し、およびそれにアクセスする。

現在まで、既定の事業ベンダからの従来のストレージソリューションだけが、リッチメディアリポジトリを導入するウェブサイト開発者に利用できた。インターネットの用途に、現在の既存のストレージ技術を採用することに関する１つの難題は、現在のおよび将来のスケーラビリティ要件を満たすことである。現在、大規模ストレージシステムは２、３ダースのテラバイトまで拡大するだけである。この量のストレージ空間は、十分な分量のリッチメディアオブジェクトを格納するのに不十分である。例えば、アメリカオンライン（「ＡＯＬ」）ユーザーのほんの１０パーセントが２本の１５分のビデオを個人ホームページ上に配置する場合、１ペタバイト（すなわち１０００テラバイト）のストレージが必要であろう。現在の事業ストレージシステムアーキテクチャは、このレベルの記憶容量をサポートすることができない。

インターネットの世界では、大容量記憶域を供給することに加えて、広域ネットワークを横切ってストレージに対する汎用アクセスを与えることもまた、きわめて重要である。それらのコンテンツサーバ、キャッシュサーバまたはストリームサーバの位置に関係なく、コンテンツプロバイダはリッチメディアオブジェクトの全てのストアに対して遍在するアクセスを提供することを理想的には好むであろう。ストレージエリアネットワークおよびネットワーク付加ストレージ技術を含む、現在の技術は、広域ネットワークに対する直接アクセスを提供しない。同じ大都市圏内に位置するサーバだけが、これらの種類のストレージシステムに直接アクセスすることができる。

インターネットユーザーが、数百人のユーザーの代わりに、何万またはさらに何百万ものユーザーに達するので、需要が増加するにつれて、大容量記憶における別の難題はメディアの配信を拡大する能力である。真のインターネットベースのストレージシステムは、世界中の全てからの何百万もの同時要求のピーク負荷を処理することが可能でなければならない。従来のストレージアーキテクチャは、サーバＣＰＵの速度に適合させるために最速の可能な応答時間から２、３百の同時要求をサポートするように設計されている。インターネットにとって、ストレージシステムは広域ネットワークの速度で文字通り何百万もの同時ダウンロードを処理することが可能でなければならない。したがって、これらの従来のストレージアーキテクチャは、この記憶装置が、広域ネットワークの待ち時間要件をはるかに超える非常に少ない同時トランザクションを処理するので、広域ネットワークと「インピーダンスマッチ」していない。加えて、これらの従来のストレージアーキテクチャは一般的に高価なディスクおよび高価な接続技術によって実施される。

リッチメディアオブジェクトのストレージに関する別の問題は、製品化までの時間である。製品化までの時間は、しばしば新しいリッチメディアウェブサイトに対する決定的な要件である。成長率は、月あたりテラバイトに達する。新しい容量をすばやくオンラインにもたらすことは、動きが速い市場において戦略的な利点になる。一般的に、従来のストレージソリューションによって、顧客が、完全に使用可能な複数テラバイトの記憶ユニットをコンテンツプロバイダサイトと統合するのに２ないし６ヵ月かかる。この始動時間は、迅速に増加しているビジネス需要を満たすのが遅くなることである。この需要を予想して大量の過剰設備を前もって建設しておくことは予測不可能な需要スパイクを処理する１つの戦術であるが、この方法は極端に高価である。

従来のストレージアーキテクチャは、データベースおよびファイルサーバアプリケーションに対して最適化されてきた。インターネットは、スケーラビリティ、地球規模のアクセス、ユーザーアカウントおよび迅速な配備を含む、記憶装置に関するまったく新しい群の需要を導入する。次の数年にわたってインターネットを通じて供給されるリッチメディアの爆発的増加によって、これは重要な局面に達しつつある。リッチコンテンツの来たるべき表題波は、さらに最も強力な事業ストレージアーキテクチャの能力にまさる。したがって、インターネットレディのリッチメディアストレージシステムを設計する新しい方法で新しいパラダイムを開発する需要がある。

ネットワークストレージシステムが、仮想ファイルシステム（「ＶＦＳ）、および、ストレージセンタを含む。このＶＦＳは、このネットワークストレージシステムのファイルを管理するためにファイルシステム情報を格納する。このストレージセンタは、ネットワークストレージシステムのファイルを格納する。ＶＦＳおよびストレージセンタは、クライアントが、ファイルシステム操作を遂行するためにＶＦＳにアクセスし、および、このクライアントがファイルをアップロード／ダウンロードするためにストレージセンタにアクセスするように、分離される。

一実施態様において、クライアントはストレージポートを通してネットワークストレージシステム（例えば仮想ファイルシステムおよびストレージセンタ）にアクセスする。このストレージポートは、ネットワークストレージシステムのクライアントのファイルへのアクセスを提供する。

一実施態様において、クライアントは、標準のＮＦＳまたはＣＩＦＳ操作を通して、ストレージポートをマウントして、ファイルシステム操作を実行し、かつローカルファイルシステム操作を発行することによってストレージポートにアクセスする。応答して、このストレージポートはローカルファイルシステム操作をネットワークストレージシステム操作に変換する。フェールオーバ状態の場合には、追加ストレージポートが、ネットワークストレージシステムにアクセスするようにクライアントにおいて構成されることができる。

一実施態様において、ストレージセンタは、複数の分散オブジェクトストレージマネージャ（ＤＯＳＭ）および複数の高機能ストレージノードを含むストレージクラスタを含む。ＤＯＳＭは、ストレージセンタにアクセスする要求を受け取る。この高機能ストレージノードは、ネットワークストレージシステムのファイルを格納して、ＤＯＳＭからのアクセス要求にサービスを提供する。このネットワークストレージシステムは、地理的に異なる場所における追加ストレージセンタを含む。一実施態様において、このネットワークストレージシステムは、異なるストレージセンタ内に格納されるファイルを含む、高機能ストレージノードに格納されるファイルに関するファイル情報をＤＯＳＭに保持するためにマルチキャストプロトコルを使用する。このストレージセンタは、ロードバランシング機構をさらに含む。このロードバランシング機構は、ストレージセンタにアクセスする需要に基づいてアクセス要求に対してＤＯＳＭを選択する。加えて、ＤＯＳＭは高機能ストレージノード内に格納されるファイルの少なくともサブセットをキャッシュに格納するためのデータキャッシュを含む。ストレージセンタにおけるロードバランシングの使用は、ＤＯＳＭのデータキャッシュ内の高需要のファイルに対してデータをキャッシュに格納することに結びつく。

（図面の簡単な説明）
図１は、本発明のストレージシステムに対する一実施態様を例示するブロック図である。
図２は、メディアストレージサービスとしてのネットワークストレージシステムの使用に対する一実施態様を例示する。
図３は、ストレージクラスタに対する一実施態様を例示するブロック図である。
図４は、ストレージクラスタ内のダウンロード操作に対する一実施態様を例示する流れ図である。
図５は、ネットワークストレージシステム内の認証に対する一実施態様を例示する流れ図である。
図６は、分散オブジェクトストレージマネージャ（「ＤＯＳＭ」）の一実施態様を例示する。
図７は、高機能ストレージノードに対する一実施態様を例示するブロック図である。
図８は、ストレージクラスタ内のアップロード要求を処理するための一実施態様を例示する流れ図である。
図９は、オブジェクトファイルの一意の指紋を生成するための一実施態様を例示する流れ図である。
図１０は、ストレージクラスタ内のデータをキャッシュに格納するための一実施態様を例示するブロック図である。
図１１は、ネットワークストレージシステムとともに用いられるＶＦＳを実装するための一実施態様を例示するブロック図である。
図１２は、データベースを有するファイルシステムを実装するためのサンプルデータベース表を例示する。
図１３Ａは、ＶＦＳ内でディレクトリ操作を実行するための一実施態様を例示する流れ図である。
図１３Ｂは、ＶＦＳ内でディレクトリ操作を実行するための一実施態様を例示する流れ図である。
図１４は、ネットワークストレージシステムの削除ファイル操作に対する一実施態様を例示する流れ図である。
図１５は、ストレージセンタの地理的多重化を例示する。
図１６は、ストレージセンタを複製するための一実施態様を例示するブロック図である。
図１７は、コンテンツ配信ネットワーク内のストレージセンタの使用に対する一実施態様を例示する。
図１８は、コンテンツ配信ネットワークによるストレージセンタの使用に対する一実施態様を例示する流れ図である。
図１９は、ネットワークストレージシステム内のストレージポートの使用に対する一実施態様を例示する。
図２０は、コンテンツを配信するためのストレージポートの使用に対する一実施態様を例示する流れ図である。
図２１ａは、ストレージポートデバイスに対する１つのハードウェア構成を例示する。
図２１ｂは、ソフトウェアでストレージポートを実装するための実施態様を例示する。
図２２は、ストレージポートに対する一実施態様を例示するブロック図である。
図２３は、ストレージポート内のファイルシステム変換に対する一実施態様を例示するブロック図である。
図２４は、ファイルシステム操作をローカルファイルシステムからネットワークストレージファイルシステムに変換するための一実施態様を例示する流れ図である。
図２５は、オブジェクトファイルをエンドユーザに直接ダウンロードするためにストレージポートを使用するための一実施態様を例示するブロック図である。
図２６は、オブジェクトファイルをエンドユーザに直接ダウンロードするための一実施態様を例示する流れ図である。
図２７は、ストレージセンタをクライアントの専有ファイルディレクトリシステムにインターフェースする一実施態様を例示するブロック図である。
図２８は、クライアントの専有ファイルシステムを使用してストレージセンタ内のオブジェクトファイルにアクセスするための一実施態様を例示する流れ図である。
図２９は、ストレージポートフェールオーバ構成に対する一実施態様を例示するブロック図である。
図３０は、ストレージポートフェールオーバプロセスに対する一実施態様を例示する流れ図である。
図３１は、ストレージノードフェールオーバ状態の後でマルチキャストプロトコルを使用するための一実施態様を例示する流れ図である。

ネットワークストレージシステム概要：
このネットワークストレージシステムは、リッチメディアコンテンツ所有者のストレージ要件を満たすように設計されている。リッチメディアオブジェクトは、一般的にウェブサイトと関連するフィルム、音楽または写真アルバムに必要なストレージの９０パーセントまでを代表する。このネットワークストレージシステムは、何ペタバイトものストレージをサポートし、かつ何百万ものユーザーをサポートするためにスケーラビリティを提供する分散処理システム技術を使用する。ユーザーは、高度にセキュアな「共有秘密」認証証明書技術を使用して、ネットワークストレージシステム内の、彼らのメディアオブジェクトにアクセスするだけである。このネットワークストレージシステムはまた、即座の拡張性を、それらの記憶容量を増やすことを望む任意のユーザーに提供する。また、このネットワークストレージシステムは、一実施態様において、それが最新の高密度ディスク技術を備えた標準規格品のＣＰＵから成るので、極めて費用効率が高い。

標準名称の必要上、本願明細書に使われるように、用語「クライアント」はオブジェクトファイルを格納するためにストレージシステムを使用する実体を指す。例えば、クライアントは、彼らのウェブサーバの外側に、彼らのウェブサイト上のコンテンツと関連するリッチメディアオブジェクトを配信することを望むウェブサイト所有者から成ることができる。また、標準名称の必要上、本願明細書に使われるように、用語「エンドユーザ」はオブジェクトの受け側を指す。例えば、エンドユーザはウェブブラウザを使用して、インターネットを横断してウェブサイトからオブジェクトをダウンロードするコンピュータユーザから成ることができる。また、この定義の下で、エンドユーザはまた、クライアントであることができる。

図１は、本発明のストレージシステムに対する一実施態様を例示するブロック図である。図１の実施態様に対して、このストレージシステムは制御パスおよびデータパスから成る。制御パスは仮想ファイルシステム（「ＶＦＳ」）５０から成り、および、データパスは分散ストレージクラスタ７０から成る。制御パスは、全てのディレクトリ操作を実施するのに用いられる。ＶＦＳは、部分的に、各リッチメディアオブジェクトに対するクライアント割当てファイル名およびネットワークストレージシステム割当て一意ファイル識別子を含む。この一意ファイル識別子は、記憶資源ロケータ（「ＳＲＬ」）内に埋め込まれる。

分散ストレージクラスタ７０は、このシステムに対するオブジェクトファイル（すなわち全てのクライアントデータ）を格納するのに用いられる。図１に示すように、ＶＦＳおよびストレージクラスタ７０は、オブジェクトファイルの物理ストレージとファイルシステム情報を連係するように、情報を伝達するために接続される。

図１に示すように、ファイルシステム制御部６０はＶＦＳ５０にディレクトリ操作要求を発行する。さらに詳細に後述されているように、ファイルシステム制御部６０は、ファイルシステム要求を、クライアントのローカルファイルシステムからネットワークストレージシステムと互換性があるファイルシステム要求に基本的に「変換する」ためにライブラリを使用するソフトウェアを備えることができる。他の実施態様では、ファイルシステム制御部６０はクライアントのシステム（例えばクライアントのアプリケーションまたはウェブサーバ）に接続されるストレージポートから成る。一般に、このストレージポートは、ハードウェアまたはソフトウェアのどちらかで実装され、ファイルシステムコマンドを、クライアントのローカルファイルシステム（例えばＮＦＳまたはＣＩＦＳ）からネットワークストレージシステムと互換性があるファイルシステム要求に変換する。一実施態様において、クライアントのファイルシステムをネットワークストレージシステムにインターフェースするために、クライアントは、ネットワークドライブとしてストレージポートをマウントしなければならないだけである。このストレージポートは、次いで、ネットワークストレージシステムに対する完全なアクセスを提供する。ストレージポートの詳細な考察は、後述される。

図１に示すように、オブジェクト受け側８０は、オブジェクト要求に応答して、ストレージクラスタ７０からダウンロードされるオブジェクトを受信する。オブジェクト受け側８０は、クライアントを含むことができ、または、オブジェクト受け側８０は一つ以上のエンドユーザから成ることができる。エンドユーザおよびクライアントの双方を含んで、オブジェクトをストレージクラスタ７０からオブジェクト受け側に転送するための実施態様を、さらに詳細に以下に記載する。

このネットワークストレージシステムは、インターネットベースのメディアストレージサービスとしての用途に対するアプリケーションを有する。このアプリケーションに対して、ネットワークストレージシステムは、リッチメディアコンテンツ所有者および配信ネットワークによって使われるインターネットインフラストラクチャの不可欠な部分である。図２は、メディアストレージサービスとしてのネットワークストレージシステムの使用に対する一実施態様を例示する。一般に、ストレージサービス１３０は、クライアント（例えばウェブサイトを運営する会社）の全ディレクトリのリッチオブジェクトの単一の調和した世界的なイメージを提供する。この実施態様に対して、エンドユーザ１００はネットワークを通してコンテンツ発信元サーバ１２０およびストレージサービス１３０の双方に接続される。例えば、エンドユーザ１００はインターネット経由でコンテンツ発信元サーバ１２０およびストレージサービス１３０に接続されることができる。ストレージサービス１３０は、サーバ１４０およびデータストア１５０のような、処理およびネットワーク機能を含む。ストレージサービス１３０およびコンテンツ発信元サーバ１２０は、ファイルディレクトリ操作およびオブジェクトファイル操作を実施するために通信する。データストア１５０、ストレージサービス１３０の一部は、図２のマルチメディアファイル１６０、１７０および１８０として例示するリッチメディアデータファイルのような、大きいデータファイルを格納する。一実施態様において、データストア１５０は高機能ストレージノードのクラスタから成る。

一実施態様において、ストレージサービスは標準インターネットハイパーテキスト転送プロトコル（「ＨＴＴＰ」）および汎用資源ロケータ（「ＵＲＬ」）経由で、エンドユーザコンピュータ１００上で動作するウェブサーバ（例えばコンテンツ発信元サーバ１２０）およびブラウザ（例えばマイクロソフトエクスプローラまたはネットスケープナビゲータ）と通信する。ＨＴＴＰの使用が本願明細書に記述されるとはいえ、任意の転送プロトコルが本発明の趣旨または有効範囲から逸脱せずに使われることができる。図２の構成に対して、エンドユーザコンピュータ１００を通して、エンドユーザはハイパーテキストマークアップ言語（「ＨＴＭＬ」）ファイルを取得するためにコンテンツ発信元サーバ１２０に対してハイパーテキスト転送プロトコル（「ＨＴＴＰ」）要求を生成する。加えて、それらのテキストファイルと関連する大きいデータオブジェクトを取得するために、エンドユーザは、エンドユーザコンピュータ１００を通してストレージサービス１３０に対してＨＴＴＰ要求を生成する。例えば、エンドユーザは、来るべきフィルムを記述するテキストのような、リッチオブジェクトを記述する数キロバイトのテキストデータをコンテンツ発信元サーバ１２０からダウンロードすることができる。ユーザーが来るべきフィルムからフィルム断片をダウンロードするためにＵＲＬ上で「クリックする」と、ＨＴＴＰ要求がストレージサービス１３０に対して生成され、および、ストレージサービス１３０がエンドユーザコンピュータ１００にフィルム断片をダウンロードする。図２のネットワーク構成は、コンテンツ発信元サーバ１２０からストレージサービス１３０にリッチオブジェクトのストレージをオフロードすることを可能にする。この構成は、リッチオブジェクトを格納して、管理して、エンドユーザに供給するために必要なコンテンツ発信元サーバのサイズおよび複雑性を大いに減らす。

分散ストレージクラスタ：
一実施態様において、ストレージクラスタは何百ものＣＰＵのスループットおよび何千ものディスクドライブのストレージを利用する分散処理システム技術を活用する。図３は、ストレージクラスタに対する一実施態様を例示するブロック図である。ストレージクラスタ３００は、記憶資源ロケータ（「ＳＲＬ」）を含むアップロード、ダウンロードおよび削除操作を受信する。ＳＲＬは、その時クライアントファイルを一意的に識別するのに用いられる。図３に示すように、ストレージクラスタは分散オブジェクトストレージマネージャ（「ＤＯＳＭ」）３２０および高機能ストレージノード３４０から成る。「ｎ」台の分散オブジェクトストレージマネージャ３２０があり、ここで「ｎ」は１を超える任意の整数値である。同様に、高機能ストレージノード３４０構成要素に対して「ｎ」個の高機能ストレージノードがある（すなわちここで「ｎ」は、また、１を超える任意の整数値である）。

図３に示すように、ファイルアップロードおよびダウンロード操作がロードバランシング機構３１０に入力される。一実施態様において、ロードバランシング機構３１０はレイヤー４（「Ｌ４」）スイッチである。一般に、Ｌ４スイッチはＴＣＰおよびＵＤＰトラフィックに効果的に優先順位をつけることが可能である。加えて、ロードバランシング機能を組み込むＬ４スイッチは、ＨＴＴＰセッションに対する要求を、サーバのような、複数の資源に分散する。この実施態様に対して、ロードバランシング機構３１０はアップロードおよびダウンロード要求をＤＯＳＭ可用性に基づいて複数のＤＯＳＭのうちの１つに分配する。Ｌ４スイッチのロードバランシング機能は、現在商業的に入手可能である。

各ＤＯＳＭは、何百もの同時ダウンロードトランザクションを独立に処理する。以下に記載する一実施態様において、各ＤＯＳＭは頻繁にアクセスされるファイルオブジェクトを格納するためにローカル高速ディスクキャッシュを有する。各ＤＯＳＭは、ストレージシステムの動的に生成されたマップを有する。このマップは、高機能ストレージノードアドレスとオブジェクト指紋との間の対応を識別する。一実施態様において、ＤＯＳＭは別々のアカウントシステムおよび監視システムによって集められる全ての使用および性能データを記録する。

ＤＯＳＭ３２０は、相互接続機構３３０経由で高機能ストレージノード３４０と通信する。相互接続機構３３０は、全てのＤＯＳＭ３２０がいつでもすべての高機能ストレージノードと通信することを確実にするために高速高帯域機構から成る。一実施態様において、ＤＯＳＭ３２０は、分散オブジェクトストレージプロトコル（「ＤＯＳＰ」）と名付けられたプロトコル経由で相互接続機構を通じて高機能ストレージノードと通信する。効果的に、ＤＯＳＰは１つの大きなストレージクラスタに何百もの高機能ストレージノードをリンクする。下記に詳しく述べる通り、ＤＯＳＰはマルチキャストプロトコル、同じく、ポイントツーポイントプロトコルから成る。

一般に、高機能ストレージノード３４０は持続的なストアをオブジェクトまたはファイルに提供する。この高機能ストレージノードは、何千もの高密度ディスクドライブを含む。この高機能ストレージノードは、図７の考察とともにさらに詳細に以下に記載する。

一実施態様において、このネットワークストレージシステムは要求を処理するために記憶資源ロケータ（「ＳＲＬ」）を使用する。一実施態様において、このネットワークストレージシステムはＳＲＬに対して以下のフォーマットを使用する：
ｈｔｔｐ：／／＜ストレージクラスタ＞／＜コード化された要求＞／＜デジタル署名＞／＜任意の顧客ｕｒｉ、
ここで、
「ストレージクラスタ」フィールドは、ストレージセンタＤＳＭプールの名前またはＩＰアドレスを含み、
「コード化された要求」フィールドは、ｂａｓｅ６４コード化されたオペコードおよび引数を備え、
「デジタル署名」フィールドは、以下の式に由来する証明書から成る：
ｍｄ５（共有秘密＋ｍｄ５（共有秘密＋コード化された要求））、および、
「任意の顧客ｕｒｉ」フィールドはネットワークストレージシステムクライアントによってＳＲＬに加えられる任意の情報を含む。例えば、任意の顧客ｕｒｉフィールドは、ブラウザがコンテンツを適切なプラグインに送信することを可能にするためにダウンロードされるファイルのファイル名および拡張子を含むことができる。

一実施態様において、「コード化された要求」フィールドはｂａｓｅ６４エンコーディングを使用してコード化される。表１に示すように、このコード化された要求はＵＲＬタイプフィールド、バージョンフィールドおよびタイプ／バージョン特有ペイロードフィールドから成る。

一実施態様において、タイプ／バージョン特有ペイロードフィールドはアカウンティング情報、オペコードおよびオペコード従属の引数リストを含む一連の『／』で区切られたフィールドから成る。表２は、タイプ／バージョン特有ペイロードフィールドに対する一実施態様を示す。

表３は、アクセス法フィールドに対する２つのアクセス法タイプを含む。

表４は、オペコードフィールドに対する使用可能なコードを含む。

図４は、ストレージクラスタ内のダウンロード操作に対する一実施態様を例示する流れ図である。標準名称の必要上、ダウンロード操作の「受け側」はダウンロード操作に対するファイルの行き先である。ストレージクラスタは、一意ファイル識別子（例えばＳＲＬ）を含むダウンロード要求を受信する（ブロック４００、図４）。ストレージクラスタがダウンロード要求を受信すると、Ｌ４スイッチのようなロードバランシング機構３１０（図３）が、利用できるＤＯＳＭを選択する（ブロック４１０、図４）。ＤＯＳＭは、証明書およびコード化された要求を抽出するためにＳＲＬを解析する（ブロック４１５、図４）。コード化された要求から、証明書が算出され、および、算出された証明書がＳＲＬ証明書と比較される。ＳＲＬが認証しない場合、エラーメッセージが受け側に送信される（ブロック４２０および４２５、図４）。代わりとして、ＳＲＬが認証する場合、ＤＯＳＭはＳＲＬによって識別されるオブジェクトが対応するＤＯＳＭのデータキャッシュ内に存在するかどうか判定する（ブロック４２０および４３０、図４）。データオブジェクトがキャッシュに格納されている場合、オブジェクトは（例えば、ＨＴＴＰプロトコルを使用してインターネット経由で）ストレージクラスタから受け側まで送信される（ブロック４３０および４９５、図４）。このオブジェクトがＤＯＳＭでキャッシュに格納されていない場合、ＤＯＳＭは高機能ストレージノードのうちの１つの中でオブジェクトの位置を識別することを試みる（ブロック４３０および４４０、図４）。

ＤＯＳＭがオブジェクトの位置（例えば、オブジェクトファイルがＤＯＳＭルックアップテーブルのエントリである）を知っており、および、ストレージノードが読取り可能な場合、その時、ＤＯＳＭはオブジェクトを格納するストレージノードとの接続を達成し、かつ、ストレージクラスタから受け側までオブジェクトを送信する（ブロック４４２、４３５および４９５、図４）。代わりとして、ＤＯＳＭが高機能ストレージノード内のオブジェクトのストレージ位置を知らない場合、ＤＯＳＭはオブジェクトの場所を突き止めるために高機能ストレージノードに対して要求をブロードキャストする（ブロック４４０および４５０、図４）。各高機能ストレージノードは、オブジェクトがそのディスクドライブのうちの１つに格納されているかどうか判定する（ブロック４６０、図４）。オブジェクトファイルが高機能ストレージノードのうちの１つに位置する場合、要求されたオブジェクトを格納する高機能ストレージノードは分散オブジェクトストレージマネージャの全てに識別情報をブロードキャストする（ブロック４６２および４７０、図４）。例えば、高機能ストレージノード３４０の高機能ストレージノード「１」が要求されたオブジェクトをディスク「３」内に格納する場合、高機能ストレージノード「１」は、オブジェクトファイルが高機能ストレージノード「１」のディスク「３」内に位置する全ての「ｎ」台のＤＯＳＭに、ブロードキャストする。全てのＤＯＳＭが、ファイル識別情報を取得するためにバスをスヌープする。高機能ストレージノードのブロードキャストに応答して、各ＤＯＳＭは適切なファイル識別情報によってそのルックアップテーブルまたはファイルシステムディレクトリを更新する。

ＤＯＳＭがオブジェクトの場所を突き止めるために高機能ストレージノードに要求をブロードキャストし、および、オブジェクトが要求から場所を突き止められない場合、ＤＯＳＭはオブジェクトに対してストレージノードを個別に問い合わせるために高機能ストレージノードとのポイントツーポイント接続を確立する（ブロック４６２および４６４、図４）。全ての高機能ストレージノードが問い合わせられ、または、オブジェクトが場所を突き止められるまで、このプロセスは繰り返される。オブジェクトが高機能ストレージノードのうちの１つに位置する場合、要求されたオブジェクトを格納する高機能ストレージノードは分散オブジェクトストレージマネージャの全てに識別情報をブロードキャストする（ブロック４６６および４７０、図４）。代わりとして、オブジェクトが高機能ストレージノードのうちの１つに位置しない場合、フェールオーバ手続きが異なるストレージセンタの中でオブジェクトの場所を突き止めるために実行される（ブロック４６６および４６８、図４）。

高機能ストレージノードが場所を突き止められると、ＤＯＳＭは高機能ストレージノードとの接続を達成して、要求されたオブジェクトを有するファイルをオープンする。ストレージノードが読取り可能な（すなわち、ＤＯＳＭがストレージノードから首尾よくファイルを読み込む）場合、オブジェクトは高機能ストレージノードからネットワーク経由で（例えば、インターネットを通じてＨＴＴＰプロトコルを使用して）受け側まで送信される。オブジェクトファイルが読取り可能でない場合、フェールオーバ手続きが異なるストレージノードおよび／またはストレージセンタ内のオブジェクトを取得するために実行され、および、ＤＯＳＭは新しいストレージノードとの接続を達成する（ブロック４４２、４６８および４３５、図４）。その後に、オブジェクトはストレージクラスタから受け側まで送信される（ブロック４９５、図４）。

一実施態様において、ネットワークストレージシステムに対するアクセスは、有効な認証証明書を必要とする。ＣＤＮを利用する一実施態様において、この証明書はオブジェクトファイルの一意ユーザファイル名および各クライアントアカウントに割り当てられるセキュアなキーに基づく。他の実施態様において、ネットワークストレージシステムは完全なＨＴＴＰＳおよびＳＳＬプロトコルをクライアント／エンドユーザとネットワークストレージシステムとの間のセキュアな通信に対してサポートする。

図５は、ネットワークストレージシステム内の認証のための一実施態様を例示する流れ図である。要求を認証するために、ネットワークストレージシステムはクライアント識別、ＳＲＬ証明書、および、クライアントファイル名、または、オブジェクト指紋を抽出するためにＳＲＬを復号化する（ブロック５００、図５）。ネットワークストレージシステム（すなわち仮想ファイルシステムまたはストレージクラスタ）は、要求によって識別されるクライアントに対応する「秘密」またはセキュアなキーを抽出する。一般に、「秘密」またはセキュアなキーはネットワークストレージシステム内の操作を認証するためにクライアントによって与えられるパスワードである。セキュアなキーおよびオブジェクト指紋を使用して、ネットワークストレージシステムは算出された証明書を生成する（ブロック５２０、図５）。一実施態様において、ネットワークストレージシステムは以下の式に従って要求に対する算出された証明書を生成する：
ＭＤ５ハッシュ（セキュアなキー＋ＭＤ５ハッシュ（セキュアなキー＋コード化されたＳＲＬ））

上記のように、第１のＭＤ５ハッシュ計算が第１の結果を取得するためにオブジェクト指紋およびセキュアなキーに関して実行され、および、第２のＭＤ５ハッシュ計算が算出された証明書を取得するために第１の結果およびセキュアなキーに関して実行される。ネットワークストレージシステムは、算出された証明書をＳＲＬ証明書（すなわちＳＲＬ要求によって送信される証明書）と比較する（ブロック５３０、図５）。証明書が合致する場合、その時、ＳＲＬは認証され、および、要求は実行される（ブロック５４０および５６０、図５）。代わりとして、算出された証明書がＳＲＬ証明書に合致しない場合、ネットワークストレージシステムは要求側にエラーメッセージを生成する（ブロック５４０および５５０、図５）。

図６は、分散オブジェクトストレージマネージャ（「ＤＯＳＭ」）の一実施態様を例示する。この実施態様に対して、各ＤＯＳＭのプロセスおよび機能はコンピュータ、例えばサーバ６００上に実行用のソフトウェアで実装される。他の実施態様において、分散オブジェクトストレージマネージャ３２０は一台以上のコンピュータ上のハードウェアおよびソフトウェアの組合せで実装されることができる。各ＤＯＳＭは、高機能ストレージノード３４０内に格納されるオブジェクトファイルの位置を識別するファイルルックアップテーブルを保持する。図６の表６１０は、ＤＯＳＭファイルルックアップテーブルに対する一実施態様を例示する。この実施態様に対して、表の各エントリは高機能ストレージノード内に格納される対応するオブジェクトファイルを識別する。具体的には、各エントリはファイル識別、ＩＰアドレスおよびディスク識別を含む。ファイル識別は、また、本願明細書においてオブジェクト指紋とも称され、オブジェクトファイルのコンテンツに関するＭＤ５ハッシュ計算を実行することによって導き出される。このＭＤ５ハッシュ計算の結果は、１２８ビットストリングである。この実施態様に対して、ＤＯＳＭファイルルックアップテーブルは、ファイル識別カラム内に、ファイル指定「ＭＤ５」によって、１２８ビットストリングを格納する。ＤＯＳＭファイルルックアップテーブルの第２のカラムは、オブジェクトファイルを格納する高機能ストレージノードのＩＰアドレス（例えば「１０．３．１００．１」）を格納する。第３のカラムは、ディスクＩＤと呼ばれ、オブジェクトファイルを格納する高機能ストレージノード上の特定のディスクドライブを識別する整数値を格納する。ルックアップテーブルが最大容量にある一実施態様において、ＤＯＳＭは受信される新しいエントリとＤＯＳＭルックアップテーブル内の既存のエントリを置換するために最長時間未使用法（「ＬＲＵ」）キャッシュアルゴリズムを使用する。

図６に示すように、ＤＯＳＭはまたデータキャッシュ６２０を含む。一般に、データキャッシュ６２０は、ＤＯＳＭが、ダウンロード要求に応答して受け側に直接データを能率化することを可能にするために、オブジェクト（すなわちクライアントデータ）を格納する。ダウンロード要求中にキャッシュミスの場合には、オブジェクトが高機能ストレージノードから受け側まで転送される時、オブジェクトは、また、データキャッシュ６２０内にも格納される。ＤＯＳＭファイルルックアップテーブルに類似して、データキャッシュ６２０はデータキャッシュが一杯である時、新しいデータオブジェクトと既存のエントリを置換するために最長時間未使用法（「ＬＲＵ」）キャッシュアルゴリズムを使用する。

ＤＯＳＭはまた、状態表６３０を保持する。一般に、状態表６３０は高機能ストレージノード３４０の全体的な容量および健康に関する情報を格納することによってシステムの状態を提供する。一実施態様において、状態表は、高機能ストレージノードから、対応する高機能ストレージノードについての情報を取得するためにマルチキャストプロトコルを使用して作成される。状態情報は、高機能ストレージノード上のディスクが健常かどうか、どれくらいのスペースがディスク上にあるか、などを示す。一実施態様において、図６に示すように、状態表６３０は、ストレージノードの読み書き状態、ストレージノードの健康状態（故障したノードの識別を含む）、および、利用できる記憶容量および毎秒の入出力（「Ｉ／Ｏ」）操作の数を含む、ストレージノードの現在の負荷、を格納する。ＤＯＳＭは、アップロード操作において、新しいオブジェクトファイルのストレージ用の適切な高機能ストレージノードを選択するために状態情報を使用する。例えば、ＤＯＳＭは、ストレージノードの負荷均衡を保つために毎秒の入出力（「Ｉ／Ｏ」）操作数に関する情報を使用する。ＤＯＳＭはまた、新しいオブジェクトファイルを格納する高機能ストレージノードを選択するために利用できる記憶容量に関する情報を使用する。

図７は、高機能ストレージノードに対する一実施態様を例示するブロック図である。この実施態様に対して、高機能ストレージノードは、本願明細書に記述される機能を実行するソフトウェアを含む、コンピュータ上に実装される。高機能ストレージノード７００は、１個以上の中央処理ユニット（「ＣＰＵ」）から成る処理コア７１０を含む。一実施態様において、処理コア７１０は２個のＣＰＵを備える。高機能ストレージノード７００はまた、図７の中で７３０とラベルを貼られた揮発性メモリを含む。メモリ７３０は、処理コア７１０によって実行される命令、同じくこの高機能ストレージノードによって使われるデータを格納するのに用いられる。高機能ストレージノード７００は、この高機能ストレージノードを、相互接続機構３３０経由で複数の分散オブジェクトストレージマネージャ３２０にインターフェースするネットワークインターフェース７２０をさらに含む。高機能ストレージノード７００の要素は、コンピュータ移送機構７５０（例えば周辺構成要素相互接続（「ＰＣＩ」）バス、プロセッサバス、など）経由で通信する。コンピュータ移送機構７５０は、周辺構成要素相互接続（「ＰＣＩ」）バスまたは業界標準協会（「ＩＳＡ」）バスのような、一つ以上のコンピュータバスの広いカテゴリを代表することを目的とされる。

高機能ストレージノード７００は、オブジェクトファイルを格納するために複数のディスクドライブ７４０をさらに含む。図７に示すように、「ｎ」が１を超える整数値であるように、高機能ストレージノード内のディスクの数は、「ｎ」として表される。一実施態様において、処理コア７１０はＩＳＡプロトコルを使用してディスクドライブ７４０と通信する。しかし、標準コンピュータシリアルインターフェース（「ＳＣＳＩ」）プロトコルを含んで、ディスクドライブにアクセスするために用いられる任意のプロトコルが、本発明の趣旨または有効範囲から逸脱せずに使われることができる。

高機能ストレージノードは、それが格納するオブジェクトファイルを識別する情報を含む。一実施態様において、オブジェクトファイルを識別する情報は、高機能ストレージノードのファイルシステムディレクトリ内に格納される。他の実施態様では、オブジェクトファイルを識別する情報は、キャッシュに格納される。表５は、高機能ストレージノード内にオブジェクトファイルの識別をキャッシュに格納するために例証エントリを例示する。

表５は、ファイル識別子およびディスク識別子を含む。ファイル識別子またはファイルＩＤは、オブジェクトファイルに対応する一意のファイルハンドラを格納する。一実施態様において、この一意のファイルハンドラはオブジェクトファイルのコンテンツ上でＭＤ５ハッシュ関数を実行することから取得されるオブジェクト指紋である。表５の第１の例証エントリに対して、この一意のファイルハンドラは「ｆｉｌｅ１．ＭＤ５」と表される。第２のカラムは、ディスクＩＤとラベルを貼られ、オブジェクトファイルを格納する高機能ストレージノード上の特定のディスクドライブを識別する。表５の第２の例証エントリに対して、オブジェクトファイル「ｆｉｌｅ６．ＭＤ５」は、高機能ストレージノード上の第２のディスクドライブに格納される。高機能ストレージノードの最初のスタートアップに、高機能ストレージノードはファイル識別表を作成する。

ストレージクラスタはまた、アップロード要求を処理する。図８は、ストレージクラスタ内のアップロード要求を処理するための一実施態様を例示する流れ図である。標準名称の必要上、本願明細書に使われるように、「送信側」は、アップロード操作に対するオブジェクトファイルの送信側を指す。ストレージクラスタがアップロード要求を受信する場合、ロードバランシング機構３２０（図３）はアップロード要求を処理するために、利用できるＤＯＳＭを選択する（ブロック８０５および８１０、図８）。ＶＦＳは、ファイル識別（例えば、ストレージシステムノード）、および、新しいオブジェクトファイルに対する適切なディレクトリを作成する（ブロック８０５、図８）。選択されたＤＯＳＭは、証明書、オブジェクトファイル、同じくクライアントおよびディレクトリ情報を抽出するためにアップロード要求を解析する（ブロック８２０、図８）。アップロード要求が認証しない場合、ＤＯＳＭはエラーメッセージを送信側に送信する（ブロック８３５、図８）。代わりとして、アップロード要求が認証する場合、ＤＯＳＭはオブジェクトファイルを格納するために少なくとも一つの高機能ストレージノードを選択する（ブロック８４０、図８）。一実施態様において、アップロード操作はオブジェクトファイルを２つのストレージノード内に格納する。故障が１つの高機能ストレージノードで生じる場合、オブジェクトファイルの「ミラーリング」がオブジェクトに対するアクセス可能性を確実にする。オブジェクトファイルを「ミラーリングする」ための一実施態様において、ネットワークストレージシステムは異なる地理学的位置（例えば異なるストレージセンタ）にオブジェクトファイルを格納する。地理的に異なるストレージセンタへのアクセスが、オブジェクトファイルがアップロードされる時に利用できない場合、その時、ファイルの追加コピーがローカルストレージセンタに格納される。

一実施態様において、ＤＯＳＭは新しいオブジェクトを格納する最も適切な高機能ストレージノードを選択するために状態表（図６）を用いる。説明のため、この選択された高機能ストレージノードは本願明細書において「行き先高機能ストレージノード」と呼ばれる。ＤＯＳＭは、行き先高機能ストレージノードとの接続を確立する（ブロック８５０、図８）。一実施態様において、ＤＯＳＭは行き先送信元ノードとのＤＯＳＰポイントツーポイント接続を確立する。オブジェクトファイルは、次いで行き先高機能ストレージノードへ転送される（ブロック８６０、図８）。加えて、ファイルを高機能ストレージノードへ転送した後に、ＤＯＳＭはＤＯＳＰポイントツーポイントプロトコルの一部としてステータスメッセージを受信する。このステータスメッセージは、転送動作が成功したかどうか示す。

一実施態様において、行き先高機能ストレージノードはオブジェクトファイルに対する一意の指紋を生成する（ブロック８７０、図８）。具体的には、行き先高機能ストレージノードはオブジェクトファイルのコンテンツのＭＤ５ハッシュを計算する。高機能ストレージノードはまた、オブジェクトファイルを確認する。ＤＯＳＭで成功した状態を受信したあと、ＤＯＳＭは仮想ファイルシステム（「ＶＦＳ」）に対する接続を確立する。ＤＯＳＭは、ファイル情報（例えば１２８ｂｉｔ．ＭＤ５一意のオブジェクト指紋、ファイルサイズ、など）、ディレクトリ情報（例えばフォルダＩＤ、親フォルダＩＤ、など）、同じくクライアント情報およびメタデータを伝達する（ブロック８８０、図８）。ＶＦＳは、アップロードを確認することを試みる。ＶＦＳがアップロードを確認しない場合、エラーメッセージがアップロード要求の送信側に送信される（ブロック８９０および８３５、図８）。ＶＦＳがアップロードを確認する場合、確認がＤＯＳＭに送信される。次に、ＤＯＳＭは送信側にアップロードを確認する（ブロック８９５、図８）。また、ストレージシステムはネットワークストレージシステムに対してファイルを一意的に識別するファイルハンドラを送信側に戻す。

アップロード要求の送信側がエンドユーザである場合、ＤＯＳＭはエンドユーザをクライアントにリダイレクトする。例えば、ＤＯＭはクライアントのウェブサイトでエンドユーザを所定のＵＲＬにリダイレクトすることができる。他の実施態様では、送信側がストレージポートである場合、ＤＯＳＭはストレージシステムノード（すなわちストレージシステムの用途にだけ使用されるハンドラ）および一意のオブジェクトファイル指紋を送信する。

上で議論したように、アップロード操作の一部として、ネットワークストレージシステムはオブジェクトファイルの一意の指紋を生成する。図９は、オブジェクトファイルの一意の指紋を生成するための一実施態様を例示する流れ図である。まず、行き先高機能ストレージノードがオブジェクトファイルのコンテンツを有する一時ファイルを作成する（ブロック９００、図９）。ＭＤ５ハッシュ計算が、一時ファイルのコンテンツに関して実行される（ブロック９１０、図９）。ＤＯＳＭは、ＭＤ５ハッシュ操作から生成された一意の指紋が、ネットワークストレージシステム内に現在存在するかどうか判定する（ブロック９２０、図９）。この指紋が現在存在する場合、オブジェクトのコンテンツを保持する一時ファイルは削除される（ブロック９３０および９４０、図９）。また、既存の指紋ファイルと関連する参照カウントが、増加される（ブロック９５０、図９）。参照カウントの使用は、削除操作の考察に関連してさらに詳細に以下に記載する。一時ファイルから生成される指紋が存在しない場合、一時ファイルはパーマネントファイルに変換され、および、一意の指紋がストレージクラスタ内のファイルを識別するのに用いられる（ブロック９６０、図９）。

仮想ファイルシステム：
一実施態様において、ディレクトリ操作が仮想ファイルシステム（「ＶＦＳ」）の中で実行される。図１１は、ネットワークストレージシステムとともに用いられるＶＦＳを実装するための一実施態様を例示するブロック図である。一般に、ＶＦＳはネットワークストレージシステムを保持するための制御パスである。各オブジェクトファイルに対して、ＶＦＳは顧客に割り当てられたファイル名および一意のネットワークストレージシステムファイル識別子を含む顧客ファイルディレクトリを保持する。上で論じられた一実施態様において、この一意のネットワークストレージシステムファイル識別子は、オブジェクトファイルのコンテンツに関するＭＤ５ハッシュ計算を実行することで取得される１２８ビットデジタル指紋から成る。図１１に示すように、ＶＦＳは分散ディレクトリマネージャ（ＤＤＭ）１１１０および分散ディレクトリ１１２０から成る。「ｎ」個のＤＤＭおよび「ｎ」個の分散ディレクトリがあり、ここで「ｎ」は、１以上の任意の整数を表す。一実施態様において、各クライアントは分散ディレクトリにマップされる。

ＤＤＭは、共通ディレクトリ操作、例えば「ファイルを開く」、「ファイルを移動する」、「ファイルを削除する」、「フォルダを開く」、「フォルダを移動する」、および「フォルダを作成する」をサポートする。図１１の矢印は、複数ディレクトリ要求および操作を表す。この要求は、ストレージポートまたはウエブストアを経て、エンドユーザまたはクライアントから生じることができる。一実施態様では、ＶＦＳに対する要求は、ＨＴＴＰ要求を使用して搬送されて、拡張マークアップ言語（「ＸＭＬ」）を使用してコード化される。ＶＦＳがＸＭＬコード化された要求によってＨＴＴＰプロトコルを使用して記述されるとはいえ、任意のタイプの要求フォーマットによる任意のネットワークプロトコルが本発明の趣旨または有効範囲から逸脱せずに使われることができる。

一実施態様において、ＶＦＳはこのファイルシステムを実装するためにデータベースを使用する。データベース実装に対して、各ディレクトリ操作要求はデータベース操作に変換される。代わりとして、ＶＦＳはローカルファイルシステム（すなわち、ＶＦＳに対してローカルのファイルシステム）を使用してファイルシステムを実装することができる。ファイルシステム実施態様に対して、ファイルはデータベース実装で格納される情報を格納するために生成される。また、ＤＤＭは分散ディレクトリ内のファイルの位置決めをするルックアップテーブルを含む。このファイルまたはデータベーステーブルが、遠隔ストレージセンタ内に複製される。

このネットワークストレージファイルシステムは、ディレクトリまたはフォルダ（この後フォルダと称する）内に配置されるファイルから成る。大部分のファイルシステムに類似して、ネットワークストレージファイルシステムは階層ファイルシステムである。階層ファイルシステムにおいて、ディレクトリまたはフォルダは、ルートまたはベースフォルダから始めて、階層で配置される。追加フォルダまたは下位フォルダが、次いでルートフォルダの下に配置される。このファイルシステムは、下位フォルダの追加階層が他の下位フォルダの下に含まれるように、いかなる数の階層をも備えることができる。本願明細書において用いられる標準名称の必要上、フォルダに対する親フォルダは、フォルダまたはディレクトリの階層内のフォルダより上に配置されるフォルダである。

図１２は、データベースを有するファイルシステムを実装するためのサンプルデータベース表を例示する。このデータベース実施態様に対して、ＶＦＳは顧客表１２００、フォルダ表１２１０およびファイル表１２２０を保持する。顧客表１２００は、「顧客ＩＤ」、「顧客名」および「顧客予約フィールド」に対するフィールドを含む。顧客ＩＤは、クライアントを一意的に識別するのに用いられるネットワークストレージシステム識別子である。顧客名は、顧客と関連する実名である。顧客表１２００内の第１の例証エントリに対して、「顧客Ａ」は顧客ＩＤ「１」を有する。顧客予約フィールドは、クライアント用に確保されるストレージを提供する。

フォルダ表１２１０は「顧客ＩＤ」、「フォルダＩＤ」、「フォルダ親ＩＤ」および「メタデータ」に対するフィールドを含む。この実施態様に対して、フォルダ表内の各エントリはネットワークストレージファイルシステム内のフォルダに対応する。顧客ＩＤ、顧客表内に格納される同じ顧客ＩＤは、クライアントを一意的に識別する。フォルダ表１２１０の例証エントリに対して、顧客ＩＤ「３」は、このフォルダが、「顧客Ｃ」に割り当てられたことを識別する。フォルダＩＤは、そのエントリに対する特定のフォルダを識別する。例えば、フォルダ表１２１０内の第１のエントリは識別「２」によって識別されるフォルダのためにある。第３のカラムは、「フォルダ親ＩＤ」とラベルをつけられ、データベースエントリまたは行に対応するフォルダに対する親フォルダを識別する。例えば、フォルダ表１２１０内の第２のエントリは表１２１０の第１のエントリに対する下位フォルダである（すなわち、フォルダ「１００」はフォルダ「２」の下の次の階層的なレベルにある）。フォルダ表１２１０内の第１のエントリはフォルダ親ＩＤに対する値を有しないことに留意されたい。これは、フォルダ「２」がルートフォルダであることを示す。

このファイル表は、ネットワークストレージファイルシステム内に格納される各オブジェクトファイルに対するエントリを含む。例証ファイル表１２２０は、「顧客ＩＤ」、「ファイルハンドラ」、「フォルダＩＤ」、「フォルダ親ＩＤ」、および、「メタデータ」に対するカラムまたはフィールドを含む。再び、顧客ＩＤはファイルを所有する顧客を識別する。ファイル表１２２０に示されるエントリは、顧客Ｃによって格納されるファイルのためにある。ファイルハンドラフィールドは、ネットワークファイルシステムがファイルを一意的に識別するために使用する指紋を格納する。ネットワークファイルシステムが、ファイルを識別するために３２バイト１６進キャラクタシーケンスを格納するとはいえ、説明のために、ファイル表１２２０に対するファイルハンドラエントリは「５２．ＭＤ５」、「５５．ＭＤ５」、「９９．ＭＤ５」および「６７．ＭＤ５」として示される。フォルダＩＤフィールドは、ファイルを含むフォルダを識別する。例えば、ファイル「５５．ＭＤ５」に対応する、ファイル表１２２０内の第１のエントリは、フォルダ１００内に編成されるかまたは格納される。フォルダ親ＩＤは、ファイルを格納するフォルダに対する親フォルダを識別する。「５２．ＭＤ５」を含むフォルダ１００は、親フォルダ「２」を有する。

図１３Ａおよび１３Ｂは、ＶＦＳ内のディレクトリ操作を実行するための一実施態様を例示する流れ図である。ＤＤＭがディレクトリ操作要求を受信するときに、ＤＤＭは証明書、操作可能コード、同じく操作可能コードに対応する引数、を抽出するために要求を解析する（ブロック１３００および１３１０、図１３Ａ）。操作可能コードは、要求されたディレクトリ操作を指定する。証明書および要求に含まれる情報を使用して、ＤＤＭは要求を認証する。要求が認証しない場合、ＤＤＭは要求側にエラーメッセージを送信する（ブロック１３２０および１３３０、図１３Ａ）。代わりとして、要求が認証する場合、ＤＤＭは操作可能コードを解析し、かつオープン操作を実行するフォルダを含む引数を抽出する。（ブロック１３２０および１３３０、図１３Ａ）。

一般に、操作が「フォルダをオープンする」操作に対する場合、ＤＤＭは引数によって識別されるフォルダ内に含まれる全ての下位フォルダおよびファイルを戻す。具体的には、ＤＤＭは、適切な分散ディレクトリから、「フォルダをオープンする」要求の引数と確認されるフォルダに対応するファイルおよびフォルダ表を抽出する（ブロック１３４０および１３４５、図１３Ａ）。具体的には、ＤＤＭは要求による引数と確認されるフォルダに対応する全てのファイルおよび下位フォルダを抽出する。図１２の例証を使用して、「フォルダをオープンする」要求が引数「フォルダＩＤ＝２」および「顧客ＩＤ＝３」を含む場合、ＤＤＭは、分散ディレクトリ内のフォルダ表から、フォルダＩＤ１００および２５１を抽出する（すなわち、フォルダ１００および２５１はルートフォルダ２の下位フォルダである）。「フォルダをオープンする」要求が引数「フォルダＩＤ＝１００」を含む場合、その時、ＤＤＭはファイル表からファイルハンドラ「５２．ＭＤ５」および「５５．ＭＤ５」を抽出する。

ディレクトリ要求の操作可能コードが、「フォルダをオープンする」要求に続く「ファイルをオープンする」操作に対する場合、その時、ファイル情報がファイルに対する認証証明書およびＳＲＬを構成するために、ファイル表（すなわちファイルハンドラ）およびクライアント表（すなわちクライアント識別）から取得される。上記例に対して、「ファイルをオープンする」操作による引数がファイル「５２．ＭＤ５」を指定した場合、ファイルおよびクライアント情報が「５２．ＭＤ５」ファイルに対するＳＲＬを構成するために取得される。

ディレクトリ要求の操作可能コードが「フォルダを移動する」操作に対する場合、データベース操作がフォルダの新しい位置を反映するためにファイルおよびフォルダ表内のエントリを修正するように実行される。「フォルダを移動する」操作は、引数として、フォルダに対する新しい行き先を含む。図１２の例証を使用して、「フォルダを移動する」操作が、フォルダＩＤ１６６をフォルダＩＤ２５１の下位フォルダからルートフォルダ２の直接下に動かすことを指定した場合、その時、フォルダ表１２１０の第４のエントリ上の親フォルダＩＤは、「２５１」から「２」に修正される。また、ファイル表１２２０に対して、第３のおよび第４のエントリに対する親フォルダＩＤが「２５１」から「２」に修正される。

ディレクトリ操作が「フォルダを作成する」操作である場合、新しいエントリまたは行がフォルダ表に対して生成される（ブロック１３６０および１３６５、図１３Ａ）。「フォルダを作成する」操作は、引数として親フォルダを含む。下記のように、クライアントのフォルダ名はネットワークストレージシステムフォルダ識別に変換される。図１２の例証を使用して、要求側が下位フォルダ１６６の下に新しいフォルダを作成することを望む場合、その時、ＤＤＭはフォルダに対して新しいフォルダ識別を割り当て、かつ、フォルダ親ＩＤ１６６によってフォルダ表１２１０に対する新しい行またはエントリを入力する。
ディレクトリ操作が「ファイルを移動する」操作である場合、データベース操作がファイルの新しい位置を反映するためにファイル表のエントリを修正するように実行される（ブロック１３７０および１３７５、図１３Ａ）。「ファイルを移動する」操作は、ディレクトリ要求の引数としてファイルに対する新しい行き先を含む。図１２のサンプルデータベース表に対して、「ファイルを移動する」操作がフォルダ１００からフォルダ１６６にファイル「５２．ＭＤ５」を移動することを指定する場合、ファイル表１２２０の第１のエントリに対するフォルダＩＤおよびフォルダ親ＩＤフィールドは、それぞれ、「１６６」および「２５１」に修正される。

図１３Ａのブロック１３９０に示すように、データベース表から抽出される引数は、要求側に戻される。一実施態様において、ＤＤＭからの応答はファイル（すなわち、ＳＲＬの形の）および／またはディレクトリのリストを有するＸＭＬコード化された文書を含む。例えば、「フォルダをオープンする」要求に応答して、ＶＦＳは対象フォルダの下に配置されるファイルおよび下位フォルダに対してファイルおよびフォルダＩＤを戻す。

図１３Ｂは、ＶＦＳの追加ファイルシステム操作を例示する図１３Ａの流れ図の続きである。操作可能コードが「フォルダを削除する」操作である場合、対応するフォルダエントリがフォルダ表から削除される（ブロック１３７２および１３７４、図１３Ｂ）。操作可能コードが「ファイルを削除する」操作を指定する場合、この操作で識別されるファイルエントリが、そのファイル表から削除される（ブロック１３７６および１３７８、図１３Ｂ）。「ファイルを作成する」操作に対して、ＶＦＳはファイル表内に新しいファイルに対するエントリを加える（ブロック１３８６および１３８８、図１３Ｂ）。操作可能コードが「フォルダを更新する」操作を指定する場合、フォルダエントリに対して対応するフォルダ表内のクライアントメタデータが更新される（ブロック１３８６および１３８８、図１３Ｂ）。「ファイルを更新する」操作に対して、ＶＦＳは対応するファイルエントリに対して表内のクライアントメタデータを更新する（ブロック１３９２および１３９４、図１３Ｂ）。適切なデータベース操作を実行したあと、操作に対する引数が要求側に戻される（ブロック１３９６、図１３Ｂ）。

一実施態様において、ネットワークストレージシステムは既存のファイルをアップロードして、削除することを管理するために参照カウントを使用する。一般に、新しいファイルが、ネットワークストレージシステムにアップロードされる、または、ファイル要求が、既存のファイルをアップロードするために受信される場合、参照カウントは、１だけ増やされる。逆に、ファイル要求がファイルを削除するために受信される場合、参照カウントは１だけ減らされる。ネットワークストレージシステムは、参照カウントがゼロである時オブジェクトファイルを削除するために参照カウントを使用する。例えば、クライアントは、「私のファイル」と名付けられたオブジェクトファイルをアップロードするために第１の要求を送信することができる。アップロード操作が完了したあと、「私のファイル」に対する参照カウントは１である。その後に、クライアントは「私のファイル」をアップロードするために第２の要求を送信することができる。「私のファイル」の第２のコピーを格納する代わりに、ネットワークストレージシステムは「私のファイル」の参照カウントを「２」に増加させる。この例に関して、クライアントは次いで、「私のファイル」を削除するために第１の要求を送信することができる。この要求に応答して、ネットワークストレージシステムは「私のファイル」を削除しない。その代わりに、ネットワークストレージシステムは参照カウントを「１」に減らす。その後に、クライアントが「私のファイル」を削除するために第２の要求を送信する場合、参照カウントは「０」に減らされ、および、ネットワークストレージシステムは「私のファイル」を削除する。

図１４は、ネットワークストレージシステムの削除ファイル操作に対する一実施態様を例示する流れ図である。ＶＦＳが削除要求を受信する場合、ＤＤＭは妥当性確認チェックを実行する（ブロック１４００および１４０５、図１４）。削除要求が有効でない場合、エラーメッセージが要求側に送信される（ブロック１４１０および１４１５、図１４）。要求が認証される場合、ＤＤＭはファイルハンドラ（すなわちＭＤ５ファイルハンドラ）をデータベース内のファイル表から抽出する（ブロック１４２０、図１４）。ＤＤＭは、データベース内のファイル表から、ファイル識別を削除する（ブロック１４５０、図１４）。加えて、ＤＤＭは削除ＳＲＬを構成して、この削除ＳＲＬをストレージクラスタに送信する（ブロック１４６０、図１４）。削除操作に応答して、ストレージクラスタは対応するファイルに対する参照カウントを抽出する。参照カウントが１より大きい場合、ストレージクラスタは１だけ参照カウントを減らす（ブロック１４３０および１４４０、図１４）。代わりとして、参照カウントが１である場合、ストレージクラスタは参照カウントをゼロに減らして、適切な高機能ストレージノード内の、ＳＲＬによって識別されるファイルを削除する（ブロック１４７０、図１４）。

ダイナミックデータキャッシング：
図１０は、ストレージクラスタ内のデータをキャッシュに格納するための一実施態様を例示するブロック図である。図１０に示すように、「ｎ」台のＤＯＳＭが、ある。各々のＤＯＳＭ（すなわちＤＯＳＭ１、ＤＯＳＭ２、ＤＯＳＭ３．．．ＤＯＳＭ「ｎ」）は、対応するデータキャッシュ（すなわちデータキャッシュ１、データキャッシュ２、データキャッシュ３．．．データキャッシュ「ｎ」）を含む。ネットワークストレージシステムファイルアップロードおよびダウンロード操作が、ロードバランシング機構３１０によって受信される（また、図３も参照）。ロードバランシング能力を有するＬ４スイッチのような、スイッチが、資源のプールの間に資源を割り当てる。ネットワークストレージシステムに対して、ロードバランシング機構３１０は「ｎ」台のＤＯＳＭの間に要求を効率的に割り当てる。一実施態様において、ＤＯＳＭが、オブジェクトを高機能ストレージノードから行き先に転送する時、このオブジェクトは対応するＤＯＳＭのデータキャッシュ内に格納される。オブジェクトが、最長時間未使用法（「ＬＲＵ」）キャッシュポリシー経由でより最近要求されたオブジェクトを格納するためにデータキャッシュから削除される。

ネットワークストレージシステム内のＤＯＳＭのロードバランシングは、高需要のオブジェクトの「自動」キャッシングを可能にする。従来技術システムにおいて、精巧な機構が高需要のデータを識別するために使用される。これらの決定機構に基づいて、高需要のニーズを満たそうとして、データがキャッシュに格納される。例えば、オブジェクトが、映画スタジオがそのウェブサイトを通じて、新しく公開されたかやがて公開されるフィルムのビデオプレビューを提供する時、高需要である可能性がある。この例に関して、映画スタジオはメディアリッチオブジェクト、「新フィルムプレビュー」を配信するためにネットワークストレージシステムを使用する。エンドユーザが映画スタジオのウェブサイトのＵＲＬ上で「クリックする」場合、「新フィルムプレビュー」がエンドユーザに利用できることになる。この例に対して、この映画がきわめて人気があるならば、映画スタジオクライアントがそのウェブサイトを通して「新フィルムプレビュー」を提供する時、多くのエンドユーザが、リッチオブジェクト、「新フィルムプレビュー」をダウンロードすることを試みるかもしれない。

オブジェクト「新フィルムプレビュー」をダウンロードする最初の要求に対して、ロードバランシング機構３１０は要求を管理するためにＤＯＳＭを選択する。この例に関して、ロードバランシング機構３１０は要求を満たすためにＤＯＳＭ１を選択する。ＤＯＳＭ１が現在オブジェクトをそのデータキャッシュ内に格納していない場合、ＤＯＳＭ１は適切な高機能ストレージノードからオブジェクトを取得する。オブジェクトが最初の要求を満たすために配信されるにつれて、オブジェクトはＤＯＳＭ１データキャッシュ１内に格納される。この例に関して、ストレージクラスタが「新フィルムプレビュー」オブジェクトに対する第２の要求を受信し、および、ロードバランシング機構３１０が、可用性に基づいて、要求を処理するためにＤＯＳＭ３を選択する。再び、ＤＯＳＭ３が現在オブジェクトをそのデータキャッシュ内に格納していない場合、ＤＯＳＭ３は適切な高機能ストレージノードからオブジェクトを取得し、かつオブジェクトを要求側へ転送し、同じく、データキャッシュ３内にオブジェクトを格納する。同様に、この例に関して、追加要求が「新フィルムプレビュー」オブジェクトをダウンロードするためにストレージクラスタになされる。利用可能資源に基づいて、２つの別々の要求に対して、ロードバランシング機構３１０は２つの要求を処理するためにＤＯＳＭ２およびＤＯＳＭ「ｎ」を選択する。再び、ＤＯＳＭ２およびＤＯＳＭ「ｎ」が現在オブジェクトをそれらのデータキャッシュ内に格納していない場合、両方のＤＯＳＭが適切な高機能ストレージノードから「新フィルムプレビュー」オブジェクトを取得し、新フィルムプレビューを要求側へ転送し、ならびに、オブジェクトおよびそれらのそれぞれのデータキャッシュ（すなわちデータキャッシュ２およびデータキャッシュ「ｎ」）を格納する。以前の例証で示したように、オブジェクトが高需要である場合、ＤＯＳＭデータキャッシュの各々のストレージに対して、異なるＤＯＳＭを選択するロードバランシング機構を使用して、ストレージクラスタは高需要オブジェクトのコピーをフェッチする。したがって、ＤＯＳＭ資源の分散は高度に要求されたオブジェクトに対する高速アクセスに結びつく。

図１０の例証に示すように、各データキャッシュはそれぞれのＤＯＳＭで処理される要求に従い潜在的に異なるオブジェクトを格納する。例えば、「新フィルムプレビュー」オブジェクトに加えて、データキャッシュ１は「写真Ｙ」および「小塊Ｘ」を格納し、データキャッシュ２は、「Ａｄ５」および「ビデオ断片８」を格納し、データキャッシュ３は、「写真Ｚ」および「広告１０」を格納し、および、データキャッシュ「ｎ」は「小塊Ａ」および「ビデオ断片２」を格納する。

ストレージセンタの地理的多重化：
ネットワークストレージシステムは、大量数の同時ダウンロードトランザクションをサポートするために最適化される。ネットワークストレージシステムは、全てのファイルオブジェクトの単一の仮想ディレクトリに依存する。インターネット上の任意の場所から、クライアントは彼らの専用ファイルシステムの正確な同じビューを見る。したがって、ネットワークストレージシステムは世界的にユーザーと同一に見える単一のオブジェクトの同時ダウンロードをサポートする。一実施態様では、ネットワークストレージシステムはストレージリポジトリまたはストレージセンタとともに複数の大陸にわたる。ストレージセンタ間の自動地理的ロードバランシングが、全ての要求が最も近いストレージセンタに向けられることを確実にする。しかし、フェールオーバおよび性能の向上を提供するために、ストレージクラスタおよびＶＦＳを含んで、ストレージセンタが複製される。複数場所にわたる物理的な多重化は、トラフィックマネジメントサービスを含む。トラフィックマネジメントサービスは、地理学的位置の間のユーザートランザクションの地理的ロードバランシングを提供する。

図１５は、ストレージセンタの地理的多重化を例示する。この例に関して、北アメリカストレージセンタ１５１０、アジアストレージセンタ１５３０および欧州ストレージセンタ１５２０がある。図１５の例証に示すように、北米のクライアントおよびエンドユーザは、北アメリカストレージセンタ１５１０を通してストレージセンタに対する最適アクセスを有する。また、ヨーロッパのクライアントおよびエンドユーザは欧州ストレージセンタ１５２０に対する最適アクセスを有する。同様に、アジアのクライアントおよびエンドユーザはアジアストレージセンタ１５３０である最適アクセスを有する。この構成において、ストレージセンタは最大帯域幅をオブジェクトの配信に対して提供するために広域ネットワークに接続される。特定のストレージセンタが要求によってオーバーロードされる場合、新しい要求は次の最も近いストレージセンタに自動的に変更される。全てのオブジェクトが、１００パーセント災害保護を提供するために地理的にミラーリングされる。また、地理的に異なるストレージセンタへのアクセスが、ファイルが格納される時に利用できない場合、その時、ファイルの追加コピーがローカルストレージセンタに格納される（すなわち、オブジェクトファイルはローカルにミラーリングされる）。

ネットワークストレージシステム内の構成要素は、自動リカバリによって完全に冗長である。したがって、このシステムは極めて高いレベルのサービスアベイラビリティをサポートする。

各地理的ストレージセンタに対するダウンロード要求は、最速の可能な応答時間をもたらすためにＤＯＳＭ全体に連続的に分散される。加えて、一実施態様において、地球規模のロードバランシングシステムが、全てのストレージセンタにわたる全世界の負荷が、いかなる「ホットスポット」も除去して、一過性需要スパイクを軽減するために均一に分散されることを確実にする。ストレージシステムは、ネットワークそれ自体よりはるかにすばやく動作し、したがって、無視してよい遅延を全体的なファイル移動時間にもたらす。したがって、個々のオブジェクトダウンロードに対するより悪い場合の経過時間は、主としてオブジェクトを転送するのに用いられる広域ネットワークの速度で決定される。

ネットワークストレージシステム内の全ての構成要素が複製され、故障の場合には完全な回復性を提供するために冗長である。一実施態様において、各ストレージセンタは連続的なネットワークアクセスを確実にするために複数のネットワークバックボーンプロバイダに付属する。全てのファイルおよび制御パスディレクトリ構造は、いかなる起こりうるデータの損失も防ぐためにアップロードの時に地理的に複製される。さらに詳細に以下に記載さているように、このシステムはネットワークストレージ多重化プロトコルの使用を通して異なるストレージセンタの間の可干渉性を維持する。

図１６は、ストレージセンタを複製するための一実施態様を例示するブロック図である。この例に関して、１５１０および１５２０とラベルをつけられた２つのストレージセンタが示される。しかし、ネットワークストレージシステムの分散アーキテクチャに基づいて、いかなる数のストレージセンタも複製されることができる。ストレージクラスタに対して、ストレージセンタ１５１０および１５２０は両方ともロードバランシング機構３２０、分散オブジェクトストレージマネージャ（「ＤＯＳＭ」）３２０、相互接続機構３３０および高機能ストレージノード３４０を含む。ストレージセンタ１５１０は、ストレージセンタ１５２０と同じオブジェクトファイルを格納する。例えば、「オブジェクトファイル１」がストレージノード１０ストレージセンタ１５１０内に格納される場合、「オブジェクトファイル１」はストレージセンタ１５２０内のストレージノード「１」内に格納される。制御パスに対して、ストレージセンタおよび１５１０および１５２０は仮想ファイルシステム（「ＶＦＳ）５０を含む。同様に、ストレージセンタ１５１０内のＶＦＳは、ストレージセンタ１５２０内のＶＦＳと同じディレクトリ情報を格納する。したがって、ストレージセンタが複製される。ＶＦＳおよびストレージクラスタが同じ地理的「ストレージセンタ」内に示されるとはいえ、ＶＦＳおよびストレージクラスタは地理的に異なる場所に位置することができる。

この例に関して、ストレージクラスタ１５１０（すなわち、ストレージノード１、ストレージノード２．．．ストレージノード「ｎ」）内の高機能ストレージノードは、それぞれ、インターネットプロトコル（「ＩＰ」）アドレスＩＰ ａｄｄｒ_１、ＩＰ ａｄｄｒ_２およびＩＰ ａｄｄｒ_ｎ経由でアクセスされる。したがって、ＤＯＳＭがストレージセンタ１５１０内の高機能ストレージノードと通信する場合、ＤＯＳＭは、特定の高機能ストレージノードにアクセスするためにこれらのＩＰアドレスを使用する。ストレージセンタ１５２０は、それぞれ、ＩＰアドレスＩＰ ａｄｄｒ_１’、ＩＰ ａｄｄｒ_２’およびＩＰ ａｄｄｒ_ｎ’によってアドレスされるストレージノード（すなわちストレージノード１、ストレージノード２、．．．ストレージノード「ｎ」）を含む。したがって、ストレージセンタ１５２０の中で、ＤＯＳＭがストレージノードと通信する場合、ＤＯＳＭは、相互接続機構３３０を横断してＩＰ ａｄｄｒを使用する。ストレージセンタの多重化がＩＰ／ＴＣＰネットワークプロトコルを使用して記述されるとはいえ、任意のネットワークプロトコルおよび対応するアドレシング法がストレージセンタを複製するのに用いられることができる。

図１６に示すようにストレージセンタ１５１０の分散オブジェクトストレージマネージャ、または、ストレージセンタ１５２０の相互接続機構に接続される。同様に、ストレージセンタ１５２０の分散オブジェクトストレージマネージャはストレージセンタ１５１０の相互接続機構に接続される。この構成に基づいて、ストレージセンタ１５１０の分散オブジェクトストレージマネージャはストレージセンタ１５２０の高機能ストレージノードにアクセスする。同様に、ストレージセンタ１５２０の分散オブジェクトストレージマネージャはストレージセンタ１５１０の高機能ストレージノードにアクセスする。上で議論したように、各ＤＯＳＭはＩＰアドレスにファイルを相関させるルックアップテーブルを保持する（図６を参照）。例えば、ダウンロード要求で指定されるファイルがストレージセンタ１５１０のストレージノード１上に存在する場合、ＤＯＳＭルックアップテーブルのエントリはＩＰ ａｄｄｒ_１を指定する。同様に、ストレージセンタ１５２０の中で、ファイルがストレージノード１内に存在する場合、ＤＯＳＭルックアップテーブルに対するエントリはＩＰ ａｄｄｒ_１’を指定する。

このストレージセンタアーキテクチャは、「動的」フェールオーバをサポートする。ストレージノードまたはストレージノード上のディスクドライブによってファイルへのアクセスが得がたくなる場合、ＤＯＳＭは複製されたストレージセンタからファイルを取得することができる。一実施態様において、「動的」フェールオーバを実行するために、マッピングがストレージセンタ１５１０の高機能ストレージノードとストレージセンタ１５２０の高機能ストレージノードとの間に格納される。下の表６は、図１６の構成の例に対するマッピングを示す。

この例に関して、ＩＰ ａｄｄｒ_１はＩＰ ａｄｄｒ_１’にマップする。故障がストレージセンタ１５１０内のストレージノード１にある場合、その時、ストレージセンタ１５１０のＤＯＳＭはＩＰ ａｄｄｒ_１’を使用してストレージセンタ１５２０のストレージノード１にアクセスする。一実施態様において、ストレージセンタ間のＩＰマッピングは、マップされる２つのＩＰアドレス間のサブネットアドレス部分を修正することによって実施される。例えば、ＩＰ ａｄｄｒ_１が１０．３．１００．１である場合、ＩＰ ａｄｄｒ_１’は、必要に応じて、アドレスのサブネット部分を変更することによって導き出される（例えば１０．１０．１００．１）。

ＶＦＳ内に格納されるディレクトリ情報は、類似した方法でストレージセンタ１５１０と１５２０の間で複製される。したがって、ストレージセンタ１５１０の分散ディレクトリ内に故障が生じる場合、ＩＰアドレスマッピングを使用して、ストレージセンタ１５１０内の分散ディレクトリマネージャはストレージセンタ１５２０内の複製された分散ディレクトリにアクセスする。

一実施態様において、フェールオーバモードに対する地理的アプリケーションをさらに実行するために、１つのディスクが故障する場合、ＤＯＳＭは異なるストレージセンタにおける同じノード内のファイルを識別することを試みる。ストレージノードが実施不可能になる場合、ＤＯＳＭはＤＯＳＭファイルルックアップテーブル内のエントリをクリアして、遠隔ストレージセンタにおけるファイルの場所を突き止めることを試みる。例えば、ストレージセンタ１５１０内のストレージノード「１」のディスク「２」が故障する場合、ＤＯＳＭ３２０は、ストレージセンタ１５２０の中で、ストレージノード「１」、ディスク「２」内のファイルの場所を突き止めることを試みる。ファイルがストレージセンタ１５２０の中で、ストレージノード「１」、ディスク２内に位置しない場合、ＤＯＳＭは、マルチキャストプロトコルを用いて、ローカルに（すなわち、ストレージセンタ１５１０の中で）ファイルの場所を突き止めること試みる。ファイルがローカルに位置しない場合、マルチキャストプロトコルを使用して、ＤＯＳＭは遠隔ストレージセンタ（例えばストレージセンタ１５２０）におけるファイルの場所を突き止めることを試みる。

ネットワークストレージシステムへのアクセス：
ネットワークストレージシステムは、コンテンツ配信ネットワークに用いられるアプリケーションを有する。一般に、コンテンツ所有者およびプロバイダはしばしばコンテンツ配信ネットワークのサービスを使用する。コンテンツ配信ネットワークは、共通にアクセスされたリッチメディアオブジェクトの配信を最適化することを試みる。リッチメディアオブジェクトの配信を最大化するために、コンテンツ配信ネットワークは広域ネットワークの端でローカルキャッシュを使用する。

ネットワークストレージシステムは、基本的なコンテンツをコンテンツ発信元ウェブサイトに提供することによってコンテンツ配信ネットワークを補足するアプリケーションを有する。一実施態様において、コンテンツ配信ネットワークにおける各キャッシュは、所望のオブジェクトの場所を突き止めるために、コンテンツ配信ネットワークがコンテンツ所有者の／プロバイダのウェブサイトにアクセスする必要性を除去するように、地理的に最も近いストレージセンタに直接アクセスする。

図１７は、コンテンツ配信ネットワークにおけるストレージセンタの使用に対する一実施態様を例示する。図１７の例証に対して、コンテンツ配信ネットワーク１７００はコンテンツ発信元ウェブサーバ１７２０にネットワーク（例えばインターネット）を通じて接続されるエンドユーザコンピュータ１７４０を含む。コンテンツ発信元ウェブサーバ１７２０は、ウェブサイトを実行するかまたはホストをつとめる。ウェブサイトは、エンドユーザが、コンテンツ、例えばリッチメディアオブジェクトを選択することを可能にする。コンテンツ配信ネットワークは、（「ＣＤＮ」）サーバ１７３０を含む。ＣＤＮサーバ１７３０は、コンテンツ発信元ウェブサーバ１７２０によってウェブサイト上に公開されるコンテンツを配信する。具体的には、エンドユーザコンピュータ１７４０は、エンドユーザへの、ウェブサイトと関連するリッチメディアオブジェクトを含む、コンテンツの配信を最大化するためにＣＤＮサーバ１７３０に接続される。ＣＤＮにおいて、ＣＤＮサーバ１７３０はウェブサイト１７３０と関連するコンテンツの一部をキャッシュに格納する。

図示の必要上、広域ネットワーク１７５０は、衛星通信ネットワーク１７６０、ワイアレス通信ネットワーク１７７０および光ファイバネットワーク１７８０を含むように、示される。図１７にて図示したように、ＣＤＮサーバ１７３０は広域ネットワーク１７５０の端の近くに位置する。広域ネットワーク１７５０の近くのＣＤＮサーバ１７３０の位置は、ＣＤＮサーバ１７３０でキャッシュに格納されるオブジェクトの配信を最適化する。この実施態様に対して、一つ以上のストレージセンタ（複数のストレージセンタ）１７１０がＣＤＮサーバ１７３０に接続される。ＣＤＮサーバ１７３０でのキャッシュミスの場合には、ＣＤＮサーバ１７３０はストレージセンタ（複数のストレージセンタ）１７１０からコンテンツ（例えばオブジェクトファイル）を取得する。エンドユーザコンピュータ１７４０によって要求されるコンテンツがＣＤＮサーバ１７３０に位置しない場合には、この構成によってＣＤＮサーバ１７３０がより遅いコンテンツ発信元ウェブサーバ１７２０をバイパスすることができる。それゆえに、所望のコンテンツがローカルキャッシュ内に位置しない場合、ストレージセンタ（複数のストレージセンタ）１７１０はＣＤＮへのインターネットを通してのコンテンツのルーティングを最適化する。

図１８は、コンテンツ配信ネットワークによるストレージセンタの使用に対する一実施態様を例示する流れ図である。エンドユーザは、エンドユーザコンピュータを通して、コンテンツ発信元ウェブサーバにＨＴＴＰ要求を生成する（ブロック１８００、図１８）。ユーザー要求に応答して、コンテンツ発信元サーバは埋め込みファイルＵＲＬを有するＨＴＭＬをエンドユーザコンピュータに戻す（ブロック１８１０、図１８）。埋め込みファイルＵＲＬは、ＣＤＮサーバに格納されるリッチメディアオブジェクトを識別する。リッチメディアオブジェクトを取得するために、エンドユーザコンピュータはコンテンツ配信ネットワーク（例えばＣＤＮサーバ１７３０）に対してＨＴＴＰファイル要求を生成する（ブロック１８２０、図１８）。このＵＲＬによって識別されるファイルがＣＤＮサーバサイトのキャッシュ内に位置する場合、ＣＤＮサーバはファイルをエンドユーザコンピュータに配信する（ブロック１８２５および１８５０、図１８）。代わりとして、ファイルがＣＤＮサーバサイトのキャッシュに格納されていない場合、ＣＤＮサーバはストレージセンタに対してＨＴＴＰファイル要求を生成する（ブロック１８２５および１８３０、図１８）。一実施態様において、ＨＴＴＰファイル要求は、ファイルを一意的に識別するために、ネットワークストレージシステムのＳＲＬを含む。ＣＤＮサーバの要求に応答して、ストレージセンタはＣＤＮキャッシュにファイルをダウンロードする（ブロック１８４０、図１８）。ＣＤＮサーバは、ファイルをエンドユーザコンピュータに配信する（ブロック１８５０、図１８）。

ネットワークストレージシステムへのアクセス：
ネットワークストレージシステムにアクセスするために複数の方法がある。一実施態様において、クライアントは「ストレージポート」を使用する。ストレージポートは、標準ファイルシステムインターフェース（例えばネットワークファイルシステム（「ＮＦＳ」）またはマイクロソフトＮＴ ＣＩＦＳ）を通してネットワークストレージシステムへのアクセスを提供する。ストレージポートは、異なるアプリケーションに対してさまざまな方法でクライアントによってリッチメディアオブジェクトの配信を最適化するように構成されることができる。一実施態様において、ストレージポートはクライアントサイトにおいてクライアントサイトからネットワークストレージシステムまで途切れのない統合を提供するように構成される。別の実施態様において、ウェブサイトからリッチメディアオブジェクトトラフィックをさらにオフロードするために、ネットワークストレージシステムから直接にエンドユーザにファイルをダウンロードするファイルシステムマネージャとして、ストレージポートが使われることができる。他の実施態様では、ネットワークストレージシステムは専用ファイル構造に直接インターフェースされることができる。

１．ストレージポートアクセス：
ストレージポートデバイスは、ネットワークストレージシステムに透過的なゲートウェイ接続を提供する。１つのアプリケーションにおいて、ストレージポートデバイスはクライアントサイトに設置され、かつローカルエリアネットワーク（ＬＡＮ）接続を通じて標準のＮＦＳまたはＣＩＦＳプロトコル経由でローカルのウェブサーバにインターフェースする。具体的には、一実施態様において、ユーザーはクライアントネットワーク上に記憶装置としてストレージポートをマウントする。この構成において、ストレージポートはストレージセンタでの記憶容量を有する仮想ＮＦＳまたはＣＩＦＳファイルシステムをユーザーに効果的に提供する（すなわち、ユーザーに何百テラバイトもの記憶容量を提供する）。一実施態様において、ストレージポートデバイスはほぼ１．７５インチだけのラック高さを占める。さらに詳細に以下に記載するように、複数のストレージポートが総計のスループットを向上するために単一のクライアントサイトに設置されることができる。

図１９は、ネットワークストレージシステム内のストレージポートの使用に対する一実施態様を例示する。エンドユーザ１９００は、広域ネットワーク１９２０を通じてクライアントサイト１９１０と通信する。エンドユーザコンピュータ１９００は、クライアントのウェブサイトを通してアクセスされるファイルに対する要求（例えばＨＴＴＰ要求）を生成する。コンテンツウェブサーバ１９２５は、クライアントサイト１９１０に位置し、リッチメディアオブジェクトをダウンロードする要求を含む、クライアントェブサイトに対する要求を処理する。コンテンツウェブサーバ１９２５は、複数のウェブサーバおよび／またはアプリケーションサーバのような、ウェブサイトを実施するのに用いられる広いカテゴリのコンピュータおよびソフトウェアを表すことを目的とされ、および、任意のハードウェア／ソフトウェア構成が本発明の趣旨または有効範囲から逸脱せずに使われることができる。

コンテンツウェブサーバ１９２５は、ネットワーク、例えばクライアントサイト１９１０のローカルエリアネットワークを通じてストレージポート１９３０に接続される。具体的には、コンテンツウェブサーバ１９２５は「ローカルの」ファイルシステムのフォーマットに従ってファイルおよびディレクトリ操作要求を生成する。ここで使用しているように、「ローカルの」ファイルシステムはクライアントサイトで使用される一つ以上のファイルシステムまたはファイル構造を意味する。例えば、コンテンツウェブサーバ１９２５はファイルおよびディレクトリ操作に対してＮＦＳまたはマイクロソフトＮＴ ＣＩＦＳ要求を生成することができる。ストレージポート１９３０をコンテンツウェブサーバ１９２５にインターフェースするために、ストレージポート１９３０が記憶装置としてマウントされる。一実施態様において、１つのディレクトリがオブジェクトファイルに対してマウントされ、および、第２のディレクトリがＳＲＬに対してマウントされる。図１９に示すように、ストレージポート１９３０はファイルおよびディレクトリ操作を実施するためにストレージセンタ１９５０と通信する。

図２０は、コンテンツを配信するためにストレージポートの使用に対する一実施態様を例示する流れ図である。クライアントサイトは、エンドユーザコンピュータからＵＲＬファイル要求を受信する（ブロック２０１０、図２０）。ＵＲＬは、クライアントのウェブサイトと関連するオブジェクトファイルを識別する。エンドユーザのＵＲＬファイル要求に応答して、クライアントサイト（例えばコンテンツウェブサーバ）はオブジェクトファイルに対するローカルファイルシステム要求を生成する（ブロック２０２０、図２０）。ローカルファイルシステム要求は、ストレージポートによって受信される。ストレージポートは、オブジェクトファイルおよびディレクトリ情報の双方を格納するキャッシュを含む。オブジェクトファイルがストレージポート内にローカル的に格納されている場合、ストレージポートはデータキャッシュからオブジェクトファイルを取り出して、ローカルファイルシステム要求に応答してコンテンツウェブサーバにオブジェクトファイルを戻す（ブロック２０３０、２０４０および２０７０、図２０）。代わりとして、ストレージポートがオブジェクトファイルのコピーをそのデータキャッシュ内に格納していない場合、ストレージポートはストレージセンタからオブジェクトファイルを要求する（ブロック２０３０および２０５０、図２０）。ローカルファイルシステム要求に応答して、ストレージセンタはストレージポートにオブジェクトファイルをダウンロードし、および、オブジェクトファイルはコンテンツウェブサーバに戻される（ブロック２０６０および２０７０、図２０）。その後に、コンテンツウェブサーバはＵＲＬファイル要求に応答してオブジェクトファイルをエンドユーザに配信する（ブロック２０８０、図２０）。

ストレージポートは、ハードウェアまたはソフトウェアのいずれかで実装されることができる。図２１ａは、ストレージポートデバイスに対する１つのハードウェア構成を例示する。図２１ａに示すように、コンテンツウェブサーバ２１００が、ローカルエリアネットワークのような、通信リンク２１２０を通じてストレージポート２１１０と通信する。ストレージポート２１１０は、ストレージセンタ２１３０とのファイルおよびディレクトリ操作を実施する。

図２１ｂは、ソフトウェアでストレージポートを実装するための実施態様を例示する。一実施態様において、ネットワークストレージシステムはライブラリ呼出を通してまたはアプリケーションプログラムインタフェース（「ＡＰＩ」）呼出を通してアクセスされる。これらの実施態様に対して、このソフトウェアはクライアントのローカルファイルシステムとネットワークストレージファイルシステムとの間の変換を提供する。上で議論したように、ストレージセンタ２１６０はＶＦＳおよび高機能ストレージクラスタの機能を実行するためのコンピュータ上で動作するソフトウェアを含む。このソフトウェアは、外部ソフトウェアのインターフェースを可能にするためにエントリポイント（すなわちＡＰＩ）を含む。部分的には、ここで記述されるように、ストレージセンタソフトウェア上のＡＰＩは、クライアントがファイルおよびディレクトリ操作を実施することを可能にする。図２１ｂに示すように、コンテンツウェブサーバ２１４０は、クライアントサイトを操作するソフトウェアに加えて、ネットワークストレージセンタのＡＰＩを呼び出すソフトウェアを実行する。したがって、この実施態様に対して、コンテンツウェブサーバ２１４０は遠隔プログラムコールを通して広域ネットワーク２１８０を通じてネットワークストレージシステムファイルおよびディレクトリ操作を実行する。

ストレージシステムライブラリ呼出２１５５として示される、別の実施態様において、カスタマイズされたネットワークストレージシステムライブラリが一まとまりのファイルシステム操作を含む。例えば、１つのライブラリ関数が、ライブラリ関数の使用を通してストレージセンタにオブジェクトファイルダウンロードを要求するために、ソフトウェアが（例えば、コンテンツウェブサーバ２１４０上の）クライアントで動作することを可能にすることができる。この例に関してファイルダウンロード操作を実行するために、クライアントソフトウェアはファイルダウンロード機能を呼び出し、かつ関数呼出しに対して引数としてＳＲＬを渡す。関数のライブラリは、ネットワークストレージシステムに直接アクセスするためにクライアントソフトウェアをインターフェースする付加手段を提供する。

図２２は、ストレージポートに対する一実施態様を例示するブロック図である。図２２に示すように、ストレージポート２２００は処理コア２２１０、メモリ２２３０、ストレージポートデータストア２２４０、および、ネットワークインターフェース（複数のインターフェース）２２２０を含む。これらの構成要素は、一つ以上のバス（例えばＩＳＡ、ＰＣＩまたはマイクロプロセッサバス）を含むことができるバストランスポート２２５０経由で、接続される。処理コア２２１０は、一つ以上の中央処理ユニット（「ＣＰＵ」）を含む。一実施態様において、ストレージポートは２台のＣＰＵを含む。メモリ２３３０は、デバイスの操作中に本願明細書に記述されるストレージポートの機能を実行するソフトウェアを格納するのに用いられる。ストレージポートデータストア２２４０は、ファイルシステム情報（すなわちディレクトリキャッシュ）およびオブジェクトファイル（すなわちデータキャッシュ）を部分的に、キャッシュに格納するために使われる、一台以上のハードディスクドライブ（すなわち、「ｎ」台のハードディスクドライブ、ここで「ｎ」は１以上の任意の数）を含む。「ｎ」枚のネットワークインターフェースカードを含むネットワークインターフェース（複数のインターフェース）２２２０が、ストレージポート２２００をクライアントデバイス（例えばコンテンツウェブサーバ）に接続する。加えて、フェールオーバアーキテクチャをサポートするために、ネットワークインターフェースカードが一つ以上のストレージポートを共に接続するのに用いられる。一実施態様において、ストレージポートは３枚のネットワークインターフェースカードを含む。

図２３は、ストレージポート内のファイルシステム変換に対する一実施態様を例示するブロック図である。ネットワークストレージシステムは、ネットワークストレージシステムに対して一意の「ファイルハンドラ」を発行する。一実施態様において、対応するファイルに対して、ネットワークストレージシステムファイルハンドラは、ａ）クライアント識別、ｂ）親ディレクトリ、ｃ）メタデータ、および、ｄ）一意のデジタル指紋（すなわち１２８ビットＭＤ５識別）を識別する。一般に、ファイルシステム変換ソフトウェア２３００はローカルファイルシステム操作をネットワークストレージシステムファイルシステム操作に変換する。一実施態様において、この機能を実行するために、このソフトウェアはファイルシステムトランスレータ２３２０およびストレージシステムアクセスプロセス２３３０を含む。ファイルシステムトランスレータ２３２０は、ローカルファイルシステムインターセプト２３４０およびストレージシステムカーネルプロセス２３５０を含む。

操作中に、クライアントのサイトで実行しているオペレーティングシステムソフトウェアを含むことができるローカルクライアントファイルシステム２３１０は、ローカルファイルシステム操作を発行する。例えば、ファイルをオープンするために、ＵＮＩＸまたはマイクロソフトＮＴに従って、クライアントソフトウェアは要求を発行することができる。ファイルオープン操作は、ローカルファイルシステム内のファイルを識別するファイル記述子を含む。一般的に、ファイルシステム呼出しはオペレーティングシステムカーネル（図２３の２３６０とラベルをつけられた）によって処理される。オペレーティングシステムカーネルソフトウェアは、「アイノード」に対するファイル記述子とディレクトリとの間のマッピングを保持する。アイノードは、システムに、システム内のファイルデータに対する物理的なポインタ（例えばハードディスクドライブに格納されるファイルに対するポインタ）を提供する。

図２３の実施態様に対して、ローカルクライアントファイルシステム２３１０がファイルシステム操作を発行する場合、ローカルファイルシステムインターセプト２３４０は、呼出しを「トラップし」、またはインターセプトし、かつストレージシステムカーネルプロセス２３５０に実行のスレッドを渡す。一実施態様において、ローカルファイルシステムインターセプト２３４０は、カーネギーメロン大学で開発されたＣＯＤＡソフトウェアを備える。一般に、ＣＯＤＡは一種の分散ファイルシステムである。ＣＯＤＡソフトウェアによって提供される機能の一部は、基本的なファイルシステムをエクスポートする。具体的には、ＣＯＤＡは、一般的に、メモリのユーザー部分にアクセス可能なアプリケーションプログラムに対して、カーネルレベルで実行されるファイルシステム操作をエクスポートする。ファイルシステム変換がローカルファイルシステム操作をインターセプトするためにＣＯＤＡを使用して記述されるとはいえ、ファイルシステム呼出しをインターセプトする任意のソフトウェアが本発明の趣旨または有効範囲に逸脱せずに使われることができる。

一般に、ストレージシステムカーネルプロセス２３５０は、ローカルファイルシステム記述子とストレージハンドラとの間のマッピングを提供するためにオペレーティングシステムカーネル２３６０内のストレージに対するネットワークストレージシステムファイルハンドラ（本願明細書において「ストレージハンドラ」と称する）を取得する。したがって、ファイル記述子はローカルファイルシステム内のファイルおよびディレクトリを識別するハンドルを提供し、および、ストレージハンドラはネットワークストレージシステム内のファイルおよびディレクトリを識別するハンドルを提供する。

ローカルファイルシステム記述子とストレージハンドラとの間のマッピングを維持するために、ストレージシステムカーネルプロセス２３５０はストレージシステムアクセスプロセス２３３０からネットワークストレージファイルシステム情報を取得する。具体的には、ストレージシステムカーネルプロセス２３５０はストレージシステムアクセスプロセス２３３０からストレージハンドラおよびディレクトリ情報を取得する。図２３に示すように、ストレージシステムアクセスプロセス２３３０はディレクトリキャッシュ２３７０からディレクトリおよびストレージハンドラ情報を取得する。代わりとして、ディレクトリおよびストレージハンドラ情報がストレージポートでキャッシュに格納されない場合、ストレージシステムアクセスプロセス２３３０は、ディレクトリ情報およびストレージハンドラを取得するためにネットワークストレージシステム（すなわちＶＦＳ）に問い合わせる。したがって、変換システム２３００はクライアントのローカルファイルシステムとネットワークストレージファイルシステムとの間のマッピングを提供する。

図２４は、ファイルシステム操作をローカルファイルシステムからネットワークストレージファイルシステムに変換するための一実施態様を例示する流れ図である。このプロセスは、ローカルファイルシステム要求を発行するクライアントによって開始される（ブロック２４００、図２４）。ローカルファイルシステム要求は、オペレーティングシステムカーネルによって受信され、かつ、ファイルシステムトランスレータにディスパッチされる（図２３）。例えば、ファイルシステム操作がファイル「ｆｏｏ．ｔｘｔ」に対するオープンファイル操作である場合、オペレーティングシステムカーネルはファイルシステムトランスレータに引数としてファイル名「ｆｏｏ．ｔｘｔ」を有するオープンファイル操作をディスパッチする。ファイルシステム操作がフォルダ「ｄｉｒ１」に対する「フォルダをオープンする」操作である場合、オペレーティングシステムカーネルは引数としてフォルダ名「ｄｉｒ１」を有するオープンフォルダ操作をディスパッチする。

このプロセスは、充分なディレクトリ情報がストレージポートディレクトリキャッシュ内にあるかどうか判定する（ブロック２４３０、図２４）。上記の「フォルダをオープンする」例証に対して、全ての下位フォルダおよびファイルに対するストレージハンドラがディレクトリキャッシュ内に格納されていない場合、追加ディレクトリ情報が要求を満たす必要がある。「ファイルをオープンする」例証に対して、ストレージポートが最近初期化され、したがって、ファイルに関する情報を含まない場合、ファイル（例えば「ｆｏｏ．ｔｅｘｔ」）上の追加ディレクトリ情報がファイルをオープンするために必要である。

充分なディレクトリ情報が、ディレクトリキャッシュ内にあり、および、ファイルシステム操作がデータを取り出す必要がない（すなわち、ファイルシステム操作が「ファイルをオープンする」操作でない）かまたはディレクトリ情報を更新する必要がない場合、その時、ディレクトリキャッシュからの適切なディレクトリ情報が、ローカルファイルシステム操作に応答して取り出され、かつ戻される（ブロック２４３０および２４３５、図１２）（ブロック２４３５および２４３７、図２４）。上記の「フォルダをオープンする」例証に対して、対象フォルダ内の全ての下位フォルダおよびファイルに対するストレージハンドラがディレクトリキャッシュから取り出され、ストレージハンドラおよび対応するファイル識別子がオペレーティングシステムカーネル内に格納され、ならびに、ファイル識別子がローカルファイルシステムに戻される。

追加ディレクトリ情報が必要な（すなわち、情報がストレージポートディレクトリキャッシュ内にない）場合、要求が追加ディレクトリ情報のためにＶＦＳに対して生成される（ブロック２０７０、図２４）。一実施態様において、ストレージポートはＸＭＬコード化された要求を生成する。「フォルダをオープンする」例証に対して、ストレージノードおよび対応するファイル識別子がディレクトリキャッシュ内に格納されていない場合、ストレージポートは対象フォルダ（すなわち「フォルダをオープンする」要求の対象であるフォルダ）内のファイルおよび下位フォルダに対するファイルおよびフォルダ情報を抽出するためにＸＭＬコード化された「フォルダをオープンする」要求を生成する。一実施態様において、フォルダ情報に対する要求に応答して、ＶＦＳは名前、フォルダ識別、クライアントメタデータ、アップロードＳＲＬおよび親フォルダ識別を返す。ファイル情報に対する要求に応答して、ＶＦＳは名前、ファイル識別、クライアントメタデータ、ダウンロードＳＲＬおよび親フォルダ識別を返す。一実施態様において、クライアントメタデータフィールドは、ローカルファイルシステム（例えばＵＮＩＸ、Ｍｉｃｒｏｓｏｆｔ ＷｉｎｄｏｗｓまたはＮＴなど用の情報）に使用される状態情報を追跡して、保持するのに用いられる。追加ディレクトリ情報を取得することに加えて、クライアントローカルファイルシステムコマンドがディレクトリ操作（すなわち、「フォルダを移動する」、「フォルダを削除する」、など）である場合、ＶＦＳに対するＸＭＬ要求がＶＦＳ内のディレクトリ操作を実行するために生成される。ディレクトリ情報は、ディレクトリキャッシュ内に受信されて、格納される（ブロック２４８０、図２４）。

ファイルシステム操作が（例えばファイルをオープンする、ファイルを読取るなど）ファイルデータを必要とする場合、ストレージポートはこのファイルがデータキャッシュ内に位置するかどうか判定する（ブロック２４４０、図１２）。ファイルがデータキャッシュ内に格納される場合、ファイルまたは適切な部分がストレージポートからクライアント要求側まで転送される（ブロック２０９０、図１２）。代わりとして、ファイルがデータキャッシュ内にない場合、ストレージポートはストレージクラスタに対してファイルダウンロード要求を生成する（ブロック２０５０、図２４）。ストレージクラスタ要求に応答して、ストレージポートはオブジェクトファイルを受信して、その後データキャッシュ内にいれる（ブロック２０６０、図１２）。オブジェクトは次いで、ストレージポートからクライアント要求側に転送される（ブロック２０９０、図１２）。

２．エンドユーザネットワークストレージシステムアクセス方式：
別の実施態様において、ストレージポートはエンドユーザに直接またはＣＤＮパートナーを通してファイルダウンロードをサポートする。一実施態様において、ＳＲＬはウェブページＨＴＭＬに直接埋め込まれて、エンドユーザに送信される。これは、ストレージセンタからエンドユーザブラウザに直接にオブジェクトを転送することに結びつく。図２５は、エンドユーザにオブジェクトファイルを直接ダウンロードするためにストレージポートを使用するための一実施態様を例示するブロック図である。この構成に対して、エンドユーザコンピュータ２６１０はクライアントサイト２６２０およびストレージセンタ２６５０と通信する。クライアントサイト２６２０は、ウェブサイトを保持する。この実施態様に対して、クライアントサイト２６２０はコンテンツウェブサーバ２６３０を通してウェブサイトを保持する。しかし、遠隔ウェブサイトホスティングを含んで、任意の構成のサーバが本発明の趣旨または有効範囲を逸脱させずに使われることができる。

コンテンツウェブサーバ２６３０はストレージポート２６４０と通信し、および、次に、ストレージポート２６４０はストレージセンタ２６５０と通信する。図２５にて図示したように、エンドユーザコンピュータ２６１０を通して、エンドユーザはクライアントサイト２６２０に対するＵＲＬ要求を生成して、代わりに、一つ以上の埋め込みＳＲＬを有するＨＴＭＬを受信する。埋め込みＳＲＬを使用して、エンドユーザコンピュータ２６１０は、広域ネットワーク２６６０を通じてストレージセンタ２６５０に直接ＳＲＬ要求を生成する。応答して、ストレージセンタ２６５０はエンドユーザコンピュータ２６１０に直接オブジェクトファイルを供給する。

図２６は、エンドユーザにオブジェクトファイルを直接ダウンロードするための一実施態様を例示する流れ図である。クライアントサイト（例えばコンテンツウェブサーバ）は、ファイル（複数のファイル）に対応するＳＲＬ（複数のＳＲＬ）に対してローカルファイルシステム要求を生成する（ブロック２７００、図２６）。ファイル（複数のファイル）は、クライアントがウェブページ内に埋め込むことを望むコンテンツを含む。一実施態様において、ストレージポートはコンテンツウェブサーバからの要求に応答してＳＲＬ（複数のＳＲＬ）を動的に生成する（ブロック２７１０、図２６）。一実施態様において、タイムアウトパラメータがＳＲＬ（複数のＳＲＬ）に加えられる（ブロック２７２０、図２６）。このタイムアウトパラメータは、クライアントが、ＳＲＬが有効な期間（すなわちエンドユーザがファイルにアクセスすることができる期間）を指定することを可能にする。一実施態様では、タイムアウトパラメータは秒の粒度によって期間を指定する。

ＳＲＬ（複数のＳＲＬ）は、クライアントのウェブページのＨＴＭＬに埋め込まれる（ブロック２７３０、図２６）。エンドユーザは、クライアントサイトにウェブページ要求を発行する（ブロック２７４０、図２６）。コンテンツウェブサーバは、次いで埋め込みＳＲＬ（複数のＳＲＬ）を有する要求されたＨＴＭＬをダウンロードする（ブロック２７４５、図２６）。埋め込みＳＲＬによって、エンドユーザはストレージセンタに対してＨＴＴＰ要求を生成する（ブロック２７５０、図２６）。ＳＲＬ（複数のＳＲＬ）がストレージセンタで認証しない場合、ストレージセンタはエラーメッセージをエンドユーザに送信する（ブロック２７５５、図２６）。ＳＲＬ（複数のＳＲＬ）が認証する場合、タイムアウトパラメータが、ファイルアクセスが有効かどうか判定するために調べられる（ブロック２７６０、図２６）。ＳＲＬが有効でない（すなわち、タイムアウトパラメータが範囲の外にある）場合、操作は中断される（ブロック２７６０、図２６）。ＳＲＬが指定された時間範囲内にある場合、ストレージセンタはエンドユーザにオブジェクトファイルをダウンロードする（ブロック２７７０、図２６）。

ストレージポート２６４０は、ファイルシステムキャッシュとして作用する。この実施態様に対して、ストレージポートは、標準のＮＦＳまたはＣＩＦＳディレクトリフォーマットで格納されるクライアントのＳＲＬファイルを含む。各ＮＦＳまたはＣＩＦＳファイルは対応するＳＲＬを含み、および、このＳＲＬは一意のファイル識別子およびＳＲＬ認証証明書を含む。

一実施態様において、ＳＲＬをエンドユーザに配信するために、ネットワークファイルシステムは、オブジェクトファイルに対するディレクトリに加えて、オブジェクトファイルディレクトリをシャドウする、第２のディレクトリを利用する。クライアントは、シャドウファイルを取得するために第２のディレクトリを使用する。シャドウファイルは、ネットワークストレージシステムのオブジェクトファイルを識別するＳＲＬを含む。一実施態様において、ウェブページＨＴＭＬにＳＲＬを埋め込むために、クライアントは対応するオブジェクトファイルに対してシャドウファイルのコンテンツを読み込む。一実施態様において、シャドウファイルがアップロード操作中に生成される。クライアントは、第２のディレクトリをマウントすることによってシャドウファイルにアクセスすることができる。例えば、ファイル「ｆｏｏ．ｔｅｘｔ」に対して、クライアントは以下のディレクトリファイル名を指定することができる：
ｓｔｏｒａｇｅｆｉｌｅｓｙｓｔｅｍ：／ｅｘｐｏｒｔ／ｄｉｒ／ｆｏｏ．ｔｅｘｔ。
クライアントは、オブジェクトファイル「ｆｏｏ．ｔｅｘｔ」のコンテンツにアクセスするためにこのディレクトリおよびファイル名を使用する。例証ファイル「ｆｏｏ．ｔｅｘｔ」に対してＳＲＬを取得するために、クライアントは、以下のディレクトリ例のような、異なるディレクトリをマウントする：
ｓｔｏｒａｇｅｆｉｌｅｓｙｓｔｅｍ：／ＳＲＬ／ｄｉｒ／ｆｏｏ．ｔｅｘｔ、
ここで、ＳＲＬファイルは、一意のファイル識別子およびファイル「ｆｏｏ．ｔｅｘｔ」に対するＳＲＬ認証証明書を含む。ＳＲＬをエンドユーザに配信するために、クライアントは対応するオブジェクトファイルに対してシャドウファイルのコンテンツを読み込んで、ユーザーにＳＲＬを発行する。

３．クライアント専用ファイルシステムディレクトリ：
本発明のネットワークストレージシステムはまた、ストレージシステムにアクセスするために既存の専用ファイルディレクトリを使用してサポートする。この実施態様に対して、ネットワークストレージシステム顧客（例えばクライアント）はネットワークストレージシステムのファイルシステムと連動して専用のファイル構造を使用することを望むかもしれない。他の実施態様では、ネットワークストレージシステムのクライアントはＮＦＳまたはＣＩＦＳを使用して追跡されるその情報を越えて、追加情報を追跡するためにファイルシステムを開発することを望むことができる。

図２７は、クライアントの専有ファイルディレクトリシステムにストレージセンタをインターフェースする一実施態様を例示するブロック図である。一実施態様において、クライアントサイト２８２０のストレージポートは、専用ファイルマネージャ２８４０によって置換される。この実施態様に対して、専用ファイルマネージャ２８４０は、アップロードの時にユーザファイルに割り当てられる一意のファイル識別を使用して、同じくファイルシステム操作を認証する共有秘密を使用して、オブジェクトファイルに対するＳＲＬを生成する。図２７に示すように、クライアントサイト２８２０で動作する、コンテンツウェブサーバ２８３０は専用ファイルマネージャ２８４０に対してファイルシステム要求を生成する。次に、専用ファイルマネージャ２８４０が要求の対象であるオブジェクトファイルに対応するＳＲＬを発行する。一実施態様において、クライアントは、クライアントがストレージセンタにファイルをアップロードする時に専用の一意のＩＤを供給する。別の実施態様において、ファイルをダウンロードする要求において、クライアントはストレージセンタによって戻されるオブジェクト指紋を利用する。

図２７に示すように、エンドユーザは、エンドユーザコンピュータ２８１０を通して、クライアントのウェブサイトに対してＵＲＬ要求を生成する。次に、クライアントサイト２８２０は埋め込みＳＲＬを有するＨＴＭＬを返す。埋め込みＳＲＬによって、エンドユーザコンピュータ２８１０は、広域ネットワーク２８６０を通じて、ストレージセンタ２８５０に対してＳＲＬ要求を生成する。次に、ストレージセンタ２８５０はＳＲＬによって識別されるオブジェクトファイルを供給する。

図２８は、クライアントの専用ファイルシステムを使用してストレージセンタ内のオブジェクトファイルにアクセスするための一実施態様を例示する流れ図である。エンドユーザは、クライアントェブサイトにＵＲＬ要求を発行する（ブロック２９００、図２８）。応答して、クライアント（例えばコンテンツウェブサーバ）はファイルマネージャにファイル位置要求を生成する（ブロック２９１０、図２８）。一般に、ファイルマネージャはクライアントの専用ファイルシステム内のファイルに対応するＳＲＬを発行する要求にサービスを提供する。クライアントは、ネットワークストレージシステムと連携して任意のタイプのファイルシステムを使用することができる。必要な全ては、クライアントの専用ファイルシステムがクライアントの専用ファイルシステムによって管理されるファイルに対するＳＲＬを発行することである。ファイルマネージャは、ＨＴＭＬと関連するファイルに対するＳＲＬを取り出して、ファイルをコンテンツウェブサーバに配信する（ブロック２９２０、図２８）。コンテンツウェブサーバは、次いで埋め込みＳＲＬを有するＨＴＭＬをエンドユーザに送信する（ブロック２９３０、図２８）。その後に、エンドユーザはＳＲＬを有するストレージセンタに対してＨＴＴＰ要求を生成する（ブロック２９４０、図２８）。ＳＲＬが認証しない場合、ストレージセンタはユーザーにエラーメッセージを発行する。代わりとして、ＳＲＬが認証する場合、ストレージセンタはファイルを識別するためにクライアント供給一意ファイルＩＤに関するＭＤ５ハッシュを生成する（ブロック２９４７、図２８）。ストレージセンタは、その後にエンドユーザにオブジェクトファイルをダウンロードする（ブロック２９５０、図２８）。

クライアントの専有ファイルシステムアクセス方式に対して、クライアントは一意のファイル名とＳＲＬとの間のマッピングを保持する。一実施態様において、この一意のファイル名はＭＤ５ハッシュ操作から取得されないが、しかし、一意のファイル名である。したがって、ネットワークストレージシステムは、オブジェクトファイルのコンテンツおよびクライアント一意ファイル名に由来する、ＭＤ５ファイル名の間を区別する技法を利用する。一実施態様において、これらの２つのタイプのファイル名を区別するために、ネットワークストレージシステムは異なるストレージ指紋識別子を割り当てる。オブジェクトファイルのコンテンツに関するＭＤ５ハッシュ操作によって生成されるファイル名に対して、ファイルは「１２８ｂｉｔｓ．ＭＤ５」と指定される。顧客の一意のファイル名を識別するために、ファイルは「ＭＤ５．ＵＦＩＤ」に指定される（すなわち、ここで「ＭＤ５」がクライアントの一意のファイル名である）。この記法によって、ネットワークストレージシステムがｔｗｐタイプのファイル識別子を区別することを可能にして、顧客が一意のファイル名を指定するだけでネットワークストレージシステムとインターフェースすることができる。

フェールオーバアーキテクチャ：
一実施態様において、ストレージポートはフェールオーバまたはフェールセーフアーキテクチャをサポートする。図２９は、ストレージポートフェールオーバ構成に対する一実施態様を例示するブロック図である。説明のために、図２９は２個のストレージポートを備えたフェールオーバ構成を例示する。しかし、このストレージポートフェールオーバ構成は任意の「２Ｎ」個のフェールオーバ構成まで拡張されることができる。この実施態様に対して、このフェールオーバ構成は能動ストレージポート３０１０および受動ストレージポート３０２０を含む。各ストレージポートは、複数のネットワークインターフェースカードを含む。能動ストレージポート３０１０および受動ストレージポート３０２０の双方は、それぞれ、ネットワークインターフェースカード３０４５および３０２５を通して、広域ネットワーク３０６５を通じてストレージセンタ（複数のストレージセンタ）へ通信する。能動ストレージポート３０１０および受動ストレージポート３０２０はまた、それぞれ、ネットワークインターフェースカード３０５０および３０３５経由でクライアントサイトネットワークへ通信する。図２９に示すように、クライアントはＩＰ Ａｄｄｒを使用してクライアントサイトネットワーク３０６０を通じて能動ストレージポート３０１０にアクセスする。

図２９の実施態様に対して、第３のネットワークインターフェースカードがフェールオーバ監視のためにデバイスの間で通信するように能動ストレージポート３０１０（３０５５）および受動ストレージポート３０２０（３０３０）双方の上に含まれる。能動ストレージポート３０１０は、クライアントサイトで現在のストレージポートとして動作する。受動ストレージポート３０２０は、能動ストレージポート３０１０の健康を監視する。具体的には、能動ストレージポート３０１０は能動ストレージポート３０２０の健康（例えばＣＰＵ、ハードディスクドライブ、などの健康）を確認するために絶えずプロセスを実行する健康監視３０７０を含む。この実施態様に対して、受動ストレージポート３０２０は健康状態に対して能動ストレージポート３０１０を問い合わせる。フェールオーバ状態の根拠となる状態が能動ストレージポート３０１０内に生じる場合、受動ストレージポート３０２０が能動ストレージポートになる（すなわち、受動ストレージポートはストレージセンタ（複数のストレージセンタ）にクライアントサイトをインターフェースするのに用いられる）。

一実施態様において、フェールオーバをサポートするために、１つのＩＰアドレスがＮＦＳ／ＣＩＦＳエクスポートに対して使われる。この実施態様に対して、標準ＩＰ切替え方式が利用されることができる。具体的には、フェールオーバ状態が生じる場合、受動ストレージポート３０２０は能動ストレージポート３０１０のＩＰアドレスを引き受ける。健康監視３０７０および３０８０は、能動および受動プロセスの双方を含み、それで、フェールオーバ状態が生じる場合、受動ストレージポートは能動ストレージポートプロセスを実行することができる。

図３０は、ストレージポートフェールオーバプロセスに対する一実施態様を例示する流れ図である。ストレージポートフェールオーバが生じる場合、新しいストレージポートはそのディレクトリキャッシュ内に何のディレクトリ情報も、またはそのデータキャッシュ内に何のオブジェクトも含まない。したがってフェールオーバ操作の後で、ファイルが開いており、および、ストレージポートが読取りファイル要求を受信する場合、新しいストレージポートはファイルオープン操作を実行しなければならない（ブロック３１３０および３１４０、図３０）。ストレージポートがファイル識別情報（例えばＳＲＬ）を受信したあと、ストレージポートは、読取りファイル要求に応答してオブジェクトデータのブロックを送信するために、オブジェクトファイルを取得するためにストレージセンタに対する要求を生成する。

フェールオーバ状態の後、ファイルが要求され（ブロック３１２０、図３０）、または、オープンファイル操作が必要な場合、ストレージポートはファイル識別情報を取得するためにＶＦＳに対してＸＭＬを生成する（ブロック３１５０、図３０）。応答して、ＶＦＳはファイル識別情報を返す（ブロック３１６０、図３０）。ファイル識別情報によって、ストレージポートはそのディレクトリキャッシュを更新する（ブロック３１７０、図３０）。ファイル識別情報（例えばＳＲＬ）によって、ストレージポートはオブジェクトファイルに対してストレージセンタに要求を生成する（ブロック３１８０、図３０）。応答して、ストレージセンタはオブジェクトファイルを配信し、および、ストレージポートはそのデータキャッシュを更新する（ブロック３１９０、図３０）。ストレージセンタダウンロード操作がストレージポートに対する読出し要求に応答してある場合、読出し要求は、読出し要求で指定されるようにデータを配信する。

ネットワークストレージシステム動的フェールオーバ：
一実施態様において、ストレージノードはそれらのそれぞれのノードの健康を監視する（例えばハードディスクドライブ、プロセッサ、ネットワークアクセス、などを監視する）。ストレージノードの健康が、ストレージノードは動作をやめるべきであると要求する場合、その時、ストレージクラスタはフェールオーバ操作を実行する。一実施態様において、フェールオーバ操作で、ストレージノードは、故障した状態をＤＯＳＭに報告し、および、ＤＯＳＭはそれらの状態表を更新する。これが生じる場合、ＤＯＳＭは異なるストレージノード（すなわちローカルにまたは遠隔にのどちらか）における複製されたファイルの場所を突き止めることを試みる。

図３１は、ストレージノードフェールオーバ状態の後でマルチキャストプロトコルを使用するための一実施態様を例示する流れ図である。ストレージノードが故障する場合、ＤＯＳＭが更新し、およびそれらの状態表が、このストレージノードがもはや使用中でないことを示す（ブロック３２１０および３２２０、図３１）。ＤＯＳＭが故障したストレージノードに以前格納されたファイルに対するファイル要求を受信する場合、その時、ダウンロード要求を受信したＤＯＳＭが、ストレージノードにマルチキャストプロトコル要求を発行する（ブロック３２２５および３２３０、図３１）。一実施態様において、ＤＯＳＭはローカルストレージノード（すなわちそのストレージセンタに位置するストレージノード）にマルチキャストプロトコル要求を発行することができる。

マルチキャスト要求を受信する各ストレージノードは、それが要求されたオブジェクトファイルを含むかどうか判定する（ブロック３２４０、図３１）。ストレージノードのいずれもがこのオブジェクトファイルを含まない場合、その時、ＤＯＳＭは遠隔ストレージ位置で別のマルチキャストプロトコル要求を発行することができる（ブロック３２４５および３２４７、図３１）。再び、遠隔ストレージセンタで、各ストレージノードはそれが要求されたオブジェクトファイルを含むかどうか判定する（ブロック３２４０、図３１）。別の実施態様において、ＤＯＳＭがマルチキャストプロトコルを使用してファイルの場所を突き止めない場合、ＤＯＳＭはＤＯＳＰポイントツーポイントプロトコルを使用して個々のストレージノードを問い合わせることができる。

ストレージノードが要求されたオブジェクトファイルの場所を突き止める場合、ストレージノードはマルチキャストプロトコルを使用してファイル識別情報をブロードキャストする（ブロック３２５０、図３１）。各ＤＯＳＭは、ファイル識別情報を受信するために、マルチキャストプロトコルを用いてスヌープする（ブロック３２６０、図３１）。図３１のプロセス実施態様にて図示したように、マルチキャストプロトコルが、フェールオーバ状態の場合にはＤＯＳＭ内のファイル位置情報に同期させるのに用いられることができる。

マルチキャストプロトコル：
本発明のマルチキャストプロトコルは、ファイル情報のメンテナンスを分散ストレージシステムの中でサポートする。ネットワークストレージシステムが複数のストレージノードから成るので、マルチキャストプロトコルがファイル情報を追跡して、ネットワークストレージシステムの全体にわたってファイル情報に同期させるのに用いられる。ファイルおよびディレクトリ情報のトラッキングおよび保守は、地理的に異なるストレージセンタの全体にわたって情報を保持することを含む。一実施態様において、マルチキャストプロトコルはＤＯＳＭ内のキャッシュ情報に同期させる。例えば、新しいオブジェクトファイルがロードされる場合、マルチキャストプロトコルは新しいオブジェクトファイルにアクセスするために必要な情報を取得するためにネットワークストレージシステム内の全てのＤＯＳＭに対する手段を提供する。加えて、削除ファイルまたは更新ファイル操作を含んで、若干のファイル操作はＤＯＳＭルックアップテーブルを更新することを必要とする。また、ストレージノードが故障する、および、フェールオーバ条件が実行される場合、マルチキャストプロトコルは、ファイルが複製されたストレージノードでファイルの場所を突き止めるための手段をＤＯＳＭに提供する。

分散オブジェクトストレージプロトコル（ＤＯＳＰ）：
一実施態様において、ＤＯＳＰはデーモン／マスタサービスおよびマルチキャストベースの監視通信を含む。デーモンとマスタ構成要素との間の通信は、一組の「要求パケット」および「応答パケット」を通して達成される。要求パケットは、三大下位構成要素：要求のタイプを指定するオペコード、あとに続くデータについての情報を提供するＣ＋＋特有の構成経由で実装されるヘッダ、および、もしあれば送信されるデータから成る。

各操作は、関連したオペレーションコードおよび一対の構成：要求の発行に対するものおよび戻り値に対する第２の別々の構成を有する。一旦受信器が受信して、要求を処理する（データを送信した、ファイルを削除したなど）と、それは、次いで要求の状態（成功、失敗、など）および任意の必要戻り値を示す適切な「アウト構成」からなる応答を送信する。現在、ＤＯＳＰによってサポートされる６つのサービス操作：ヌル、ファイルを格納する、ファイルを取り出す、ファイル範囲を取り出す、ファイルを削除する、および、コンテンツを得る、がある。

ヌルオペレーションは、プロトコルの将来の修正を作成して、マスタ／デーモン要求／応答対話の基本的機能を試験する枠組みを提供する。

ファイルが格納する準備のできている場合、ＤＯＳＭクライアントは要求ＩＤを送信し、要求ヘッダが続く。それは、次いでデータを一連のチャンクでｄｏｓｄに送信し、チャンクのそれぞれが、読み込まれる次のチャンクのサイズを与えるＤｏｓｄＳｔｏｒｅＨｅａｄｅｒおよびこれが送信される最後のパケットであるかどうか示すフィールドの後にある。

ファイルがストレージクラスタから取り出されている場合、ＤＯＳＭクライアントは要求ＩＤを送信し、要求構成が続く。ＤＯＳＤは、最初にデータのサイズ、要求されるデータおよび最後に操作の戻り値とともにアウト構成を送信することによって応答する。

コンテンツを得る操作は、文字ベースのストリームとしてストレージノードのコンテンツを取得するのに用いられる。「イン構成」の後は、ｄｏｓｄに渡され、ｄｏｓｄは、最初にｍｄ５ｈａｓｈ／ｎｏｄｅ＆ｄｉｓｋ結合のストリームの長さを戻し、データのストリームが続き、「アウト構成」が最後に来る。

ＤＯＳＰは、伸長可能な枠組みを任意の新しいサービスまたは付加機能に提供する。基本的に３つのステップが、新しい機能を加えることにある：新しい１対のイン／アウト構成を定義するステップ、新しいオペコードを割り当てて、ＤＯＳＭクライアント内にハンドラを実装するステップ、および、ｄｏｓｄに対してサービスハンドラを追加するステップ。

システムについての情報の収集を容易にするために、ＤＯＳＰは、いくつかのマルチキャストベースのサービスを提供する。一実施態様において、これらのサービスは非マルチキャスト態様のプロトコルにきわめて類似した方法で作用する。具体的には、要求は３つの部分：オペコード、要求イン構成、および、任意の追加データ、から成る。

応答は、戻り値および要求を満たすことを必要とするその他の戻り値を含む応答構成から成る。データがストリームされる場合、サイズフィールドがデータに先行し、データがあとに続いて、次いでアウト構成があとに続く。

マルチキャストトラフィックがポイントツーポイントｄｏｓｍ／ｄｏｓｄトラフィックから完全に別々のポート上に生じるので、マルチキャストイン／アウト構成はマルチキャストに特有でない。これは、ＤＯＳＭが全ｄｏｓｄストレージクラスタを問い合わせるかまたは同じ要求／応答構成およびそれらの関連した操作可能シーケンスによって個々の機械を問い合わせることを可能にする。

ＤＯＳＭのジョブのうちの１つは、クラスタ内のノードの現在の状態を監視することである。いくつかのツールが、このタスクを容易にするためにある。主として、さまざまなｄｏｓデーモンが、特定のマルチキャストポートおよびグループ上のハートビートをマルチキャストする。ＤＯＳＭは、所定のストレージノード上で特定のディスクまたはディスクの全てを問い合わせるオプションを含む。「ディスク状態を得る」機能は、ディスクあたり１つのエントリを有する値およびディスク状態値のアレイ（オンライン、オフライン、ダウン）を戻す。「ディスク状態を得る」機能は、所定のノード上の特定のディスクまたはディスクの全てを問い合わせるオプションを含む。「ディスク状態を得る」は、戻り値およびディスク統計情報のアレイ、統計値あたり１つのアレイ（空いているバイト、利用できるバイト、使用されるアイノード、利用できるアイノード、発行済の操作の数）を含み、ディスクあたり１つのエントリを有する。ＤＯＳＰは、ロードバランシング機能を含む。

ＤＯＳＰは、ハートビート機能を含む。これは、マルチキャスト方法経由でシステム全体の追跡機能を提供することに加えてハートビートに対して特定の機械を問い合わせることを可能にする。

本発明が特定の例示的な実施態様に関して記述されたとはいえ、さまざまな変更態様および修正が本発明の趣旨と範囲から逸脱することなく、当業者によってなされるであろうことが理解されるであろう。

本発明のストレージシステムに対する一実施態様を例示するブロック図である。 メディアストレージサービスとしてのネットワークストレージシステムの使用に対する一実施態様を例示する。 ストレージクラスタに対する一実施態様を例示するブロック図である。 ストレージクラスタ内のダウンロード操作に対する一実施態様を例示する流れ図である。 ネットワークストレージシステム内の認証に対する一実施態様を例示する流れ図である。 分散オブジェクトストレージマネージャ（「ＤＯＳＭ」）の一実施態様を例示する。 高機能ストレージノードに対する一実施態様を例示するブロック図である。 ストレージクラスタ内のアップロード要求を処理するための一実施態様を例示する流れ図である。 オブジェクトファイルの一意の指紋を生成するための一実施態様を例示する流れ図である。 ストレージクラスタ内のデータをキャッシュに格納するための一実施態様を例示するブロック図である。 ネットワークストレージシステムとともに用いられるＶＦＳを実装するための一実施態様を例示するブロック図である。 データベースを有するファイルシステムを実装するためのサンプルデータベース表を例示する。 ＶＦＳ内でディレクトリ操作を実行するための一実施態様を例示する流れ図である。 ＶＦＳ内でディレクトリ操作を実行するための一実施態様を例示する流れ図である。 ネットワークストレージシステムの削除ファイル操作に対する一実施態様を例示する流れ図である。 ストレージセンタの地理的多重化を例示する。 ストレージセンタを複製するための一実施態様を例示するブロック図である。 コンテンツ配信ネットワーク内のストレージセンタの使用に対する一実施態様を例示する。 コンテンツ配信ネットワークによるストレージセンタの使用に対する一実施態様を例示する流れ図である。 ネットワークストレージシステム内のストレージポートの使用に対する一実施態様を例示する。 コンテンツを配信するためのストレージポートの使用に対する一実施態様を例示する流れ図である。 図２１ａは、ストレージポートデバイスに対する１つのハードウェア構成を例示する。 図２１ｂは、ソフトウェアでストレージポートを実装するための実施態様を例示する。 ストレージポートに対する一実施態様を例示するブロック図である。 ストレージポート内のファイルシステム変換に対する一実施態様を例示するブロック図である。 ファイルシステム操作をローカルファイルシステムからネットワークストレージファイルシステムに変換するための一実施態様を例示する流れ図である。 オブジェクトファイルをエンドユーザに直接ダウンロードするためにストレージポートを使用するための一実施態様を例示するブロック図である。 オブジェクトファイルをエンドユーザに直接ダウンロードするための一実施態様を例示する流れ図である。 ストレージセンタをクライアントの専有ファイルディレクトリシステムにインターフェースする一実施態様を例示するブロック図である。 クライアントの専有ファイルシステムを使用してストレージセンタ内のオブジェクトファイルにアクセスするための一実施態様を例示する流れ図である。 ストレージポートフェールオーバ構成に対する一実施態様を例示するブロック図である。 ストレージポートフェールオーバプロセスに対する一実施態様を例示する流れ図である。 ストレージノードフェールオーバ状態の後でマルチキャストプロトコルを使用するための一実施態様を例示する流れ図である。

符号の説明

５０ 仮想ファイルシステム（ＶＦＳ）
９０ ネットワークストレージシステム
１３０ ストレージサービス
３００ ストレージクラスタ
６００ ＤＯＳＭサーバ
７００ 高機能ストレージノード
１７１０ ストレージセンタ
１７３０ ＣＤＮサーバ
２２００ ストレージポート
２３００ 変換システム

Claims (23)

1. ネットワークストレージシステムであって、
   単一のファイルシステムに対してファイルシステム情報を格納するための仮想ファイルシステム（「ＶＦＳ」）であって、前記ネットワークストレージシステムのクライアントが、前記単一ファイルシステムの複数のファイルを管理するためにネットワークを通じて前記ＶＦＳにアクセスし、そして、前記クライアントが前記単一ファイルシステム内のファイルにアクセスするために前記ＶＦＳから記憶資源ロケータ（「ＳＲＬ」）を受信する、前記ＶＦＳと、
   お互い、前記クライアント、および前記ＶＦＳから地理的に異なる場所に位置し、かつ、広域公衆アクセスネットワークを通して前記クライアントに接続される、複数のストレージセンタにおいて、各々が、前記単一ファイルシステムに対して複数のファイルを格納するための、前記複数のストレージセンタであって、前記ネットワークストレージシステムの前記クライアントが、前記広域公衆アクセスネットワークを通じて前記ファイルをダウンロードするために前記広域公衆アクセスネットワークを通じて前記ストレージセンタのうちの１つに前記受信されたＳＲＬを送信し、そして、前記ＳＲＬが、前記広域公衆アクセスネットワークを通じて前記ストレージセンタのうちの１つにアクセスするためにストレージセンタに対する公衆アクセスネットワークアドレス、および前記ストレージセンタのうちの１つに格納される前記ファイルを一意的に識別するために前記ファイルの前記コンテンツと関連する一意の識別子を含む、前記ストレージセンタとを備える、前記ネットワークストレージシステム。
2. クライアントにおいて、前記仮想ファイルシステムおよび前記ストレージセンタにアクセスするためのストレージポートであって、クライアントファイルシステム要求を、前記単一ファイルシステム内の前記ファイルを識別する前記ファイル識別子を含むファイルシステム要求に変換する、前記ストレージポートをさらに備える、請求項１記載のネットワークストレージシステム。
3. 前記ストレージポートのフェールオーバ状態の場合には、前記仮想ファイルシステムおよび前記ストレージセンタにアクセスするための少なくとも一つの追加ストレージポートをさらに備える、請求項２記載のネットワークストレージシステム。
4. 各ストレージセンタが、
   前記ストレージセンタにアクセスする要求を受信するための複数の分散オブジェクトストレージマネージャ（「ＤＯＳＭ」）と、
   前記ＤＯＳＭからのアクセス要求にサービスを提供するために前記ネットワークストレージシステムのファイルを格納するための、各高機能ノードがプロセッサコアおよび複数の記憶装置を含む、複数の高機能ストレージノードを備える、ストレージクラスタとを備える、請求項１記載のネットワークストレージシステム。
5. 前記高機能ストレージノード内に格納されるファイルに関するファイル情報を前記ＤＯＳＭに保持するためのマルチキャストプロトコルをさらに備える、請求項４記載のネットワークストレージシステム。
6. 前記ＤＯＳＭが、前記高機能ノード内に格納されるファイルの少なくともサブセットをキャッシュに格納するためのデータキャッシュをさらに備える、請求項４記載のネットワークストレージシステム。
7. 前記ストレージセンタにアクセスする需要に基づいて、アクセス要求に対するＤＯＳＭを選択するための、かつ、前記ＤＯＳＭの前記データキャッシュ内の高需要のファイルに対するデータをキャッシュに格納するための、ロードバランシング機構をさらに備える、請求項６記載のネットワークストレージシステム。
8. 故障が前記ストレージセンタの別の一つで生じる場合には、異なるストレージセンタからのアクセス要求にサービスを提供するための、動的フェールオーバ機構をさらに備える、請求項２記載のネットワークストレージシステム。
9. 前記ネットワークストレージシステムに接続されるコンテンツ配信ネットワークをさらに備える、請求項１記載のネットワークストレージシステム。
10. 前記ファイル識別子が、前記ファイルの前記コンテンツに由来するデジタル指紋を含む、請求項１記載のネットワークストレージシステム。
11. ファイルをネットワークストレージシステム内に格納するための方法であって、前記方法が、
    ファイルシステム情報を単一ファイルシステムに対する仮想ファイルシステム（「ＶＦＳ」内に格納するステップと、
    前記ネットワークストレージシステム内のファイルにアクセスするために前記ＶＦＳにおいてクライアントからの要求を受信するステップと、
    前記クライアントからの前記要求に応答して、前記ＶＦＳにおいて記憶資源ロケータ（ＳＲＬ）を生成するステップと、
    複数のストレージセンタ内の前記単一ファイルシステムに対して複数のファイルを格納するステップであって、前記ストレージセンタが、お互い、から地理的に異なる場所に位置する、前記ステップと、
    前記ストレージセンタを、広域公衆アクセスネットワークを通して前記クライアントに接続するステップと、
    広域公衆アクセスネットワークを通じて、前記クライアントから前記ストレージセンタのうちの１つまで、前記ＶＦＳから受信される前記ＳＲＬを送信するステップであって、前記ＳＲＬが、前記広域公衆アクセスネットワークを通じてストレージセンタにアクセスするための情報を備え、かつ、前記ストレージセンタのうちの１つに格納される前記ファイルを一意的に識別するために前記ファイルのコンテンツと関連する一意のファイル識別子を備える、前記ステップと、前記広域公衆アクセスネットワークを通じて、前記クライアントに識別される前記ストレージセンタから前記ＳＲＬによって識別される前記ファイルをダウンロードするステップとを含む、前記方法。
12. クライアントにおいて、ストレージポートを使用して前記仮想ファイルシステムおよび前記ストレージセンタにアクセスするステップであって、前記ストレージポートが、クライアントファイルシステム要求を、前記単一ファイルシステム内の前記ファイルを識別する前記ファイル識別子を含むファイルシステム要求に変換する、前記ステップをさらに含む、請求項１１記載の方法。
13. 少なくとも一つの追加ストレージポートから前記ストレージポートのフェールオーバ状態の場合には、前記仮想ファイルシステムおよび前記ストレージセンタをさらに含む、請求項１１記載の方法。
14. 前記ストレージセンタから前記ファイルをダウンロードするステップが、
    前記ストレージセンタへのアクセスに対する要求を受信するステップと、
    複数の分散オブジェクトストレージマネージャ（ＤＯＳＭ）のうちの１つを前記要求にサービスを提供するために選択するステップと、
    前記要求にサービスを提供するために選択される前記ＤＯＳＭから高機能ストレージノードにアクセスするステップであって、各高機能ノードがプロセッサコアおよび複数の記憶装置を含む、前記ステップとを含む、請求項１１記載の方法。
15. 前記高機能ストレージノード内に格納されるファイルを要求するファイル情報を前記ＤＯＳＭＳに保持するためにマルチキャストプロトコルからコマンドを発行するステップをさらに含む、請求項１４記載の方法。
16. 前記ＤＯＳＭにおける前記高機能ノード内に格納されるファイルの少なくともサブセットをキャッシュに格納するステップをさらに含む、請求項１４記載の方法。
17. 前記ストレージセンタにアクセスする需要に基づいてダウンロード要求に対してＤＯＳＭを選択するステップと、
    前記ＤＯＳＭ内の高需要のファイルに対するデータをキャッシュに格納するステップとをさらに含む、請求項１４記載の方法。
18. 故障が前記ストレージセンタで生じる場合には、異なるストレージセンタからのアクセス要求にサービスを提供するステップをさらに含む、請求項１１記載の方法。
19. コンテンツ配信ネットワークから前記ストレージセンタにアクセスするステップをさらに含む、請求項１１記載の方法。
20. 前記ファイル識別子が、前記ファイルの前記コンテンツに由来するデジタル指紋を含む、請求項１１記載の方法。
21. ネットワークストレージシステムであって、
    単一ファイルシステムに対してファイルシステム情報を格納するための仮想ファイルシステム（「ＶＦＳ」）であって、前記ネットワークストレージシステムのクライアントが、前記単一ファイルシステムの複数のファイルを管理するためにネットワークを通じて前記ＶＦＳにアクセスし、そして、前記クライアントが前記単一ファイルシステム内のファイルにアクセスするために前記ＶＦＳから記憶資源ロケータ（「ＳＲＬ」）を受信する、前記ＶＦＳと、
    広域公衆アクセスネットワークを通して前記クライアントに接続され、前記単一ファイルシステムに対して複数のファイルを格納するための、ストレージセンタであって、前記ネットワークストレージシステムの前記クライアントが、前記広域公衆アクセスネットワークを通じてファイルをダウンロードするために前記公衆アクセスネットワークを通じて前記ストレージセンタに前記受信されたＳＲＬを送信し、そして、前記ＳＲＬが前記広域公衆アクセスネットワークを通じて前記ストレージセンタにアクセスするための情報を備え、かつ、前記ストレージセンタに格納される前記ファイルを一意的に識別するために前記ファイルの前記コンテンツと関連する一意のファイル識別子を備える、前記ストレージセンタとを備える、前記ネットワークストレージシステム。
22. 前記ファイル識別子が、前記ファイルの前記コンテンツに由来するデジタル指紋を含む、請求項２１記載のネットワークストレージシステム。
23. 前記ＳＲＬが制御パスを通じて前記ＶＦＳから受信され、および、前記ファイルがデータパスを通じて前記ストレージセンタからダウンロードされる、請求項１記載のネットワークストレージシステム。