JP2004500660A - ネットワーク記憶システム - Google Patents

Abstract

ネットワーク記憶システムは、以下を含む：仮想ファイル・システム（「ＶＦＳ）（ネットワーク記憶システムのファイルおよびファイルを格納する記憶装置センターを管理するために）。ＶＦＳおよび記憶装置センターは切り離される。そうすると、クライアントはファイルシステム・オペレーションを伝導するためにＶＦＳにアクセスする。そして、クライアントはアップロード／ダウンロード・ファイルに記憶装置センターにアクセスする。クライアントは、一つ以上の記憶装置ポートでネットワーク記憶システムにアクセスする。記憶装置センターは、以下を含む：複数の知的記憶装置ノードを含む複数の分散オブジェクト記憶装置管理者（ＤＯＳＭｓ）および記憶装置は、集まる。ネットワーク記憶システムは、地理的に異種の場所で追加記憶機構センターを含む。ネットワーク記憶システムは知的記憶装置ノードに格納されるファイルに関して、ファイル情報をＤＯＳＭｓに維持するためにマルチキャスト・プロトコルを使用する。そして、異種の記憶装置センターに格納されるファイルを含む。

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. 請求項２１に記載の記憶装置センター、そこにおいて、：更なる前記ＳＲＬは、以下を有する：タイムアウト・パラメータ、そして、前記リクエストが前記タイムアウト・パラメータによる妥当であるかどうか決定するための前記記憶装置センター。

Images