(57)【要約】クライアントをサーバから分離するための装置及び方法は、クライアントとサーバとの間にファイルスイッチ又はファイルスイッチコンピュータとも呼ばれるガラス張りのネットワークノードを置くことにより、コンピュータネットワーク内に提供される。このようなファイルスイッチの使用は、ファイル転送の待ち時間の短縮のほか、拡張可能なミラーリング、ストライピング、スピルオーバー、及び、他の機能を可能にする。【選択図】図１
2005502096.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークシステムにおけるネットワークファイルプロトコル・トランザクションを統合する方法であって、
第１のクライアントコンピュータにより開始される第１のトランザクションに属する第１のメッセージの、第１のファイルプロトコルヘッダと第１のデータとを含む第１のフレームを受信する段階と、
前記第１のファイルプロトコルヘッダの情報に基づいて、前記第１のトランザクションの処理に参加する第１の組のファイルサーバを選択する段階と、
前記第１のファイルプロトコルヘッダから得られる第２のファイルプロトコルヘッダと前記第１のデータの一部分とを含む第２のフレームを、前記第１の組のファイルサーバの第１のサーバに送る段階と、
を含むことを特徴とする方法。
【請求項２】
第３のファイルプロトコルヘッダを含む第３のフレームを前記第１のサーバから受信する段階と、
前記第３のファイルプロトコルヘッダから得られる第４のファイルプロトコルヘッダを含む第４のフレームを、前記第１のクライアントコンピュータに送る段階と、
を更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のファイルプロトコルヘッダから得られる第３のファイルプロトコルヘッダと前記第１のデータの一部分とを含む第３のフレームを、前記第１の組のファイルサーバの第２のサーバに送る段階、
を更に含むことを特徴とする請求項１に記載の方法。
【請求項４】
第４のファイルプロトコルヘッダを含む第４のフレームを前記第１のサーバから受信する段階と、
第５のファイルプロトコルヘッダを含む第５のフレームを前記第２のサーバから受信する段階と、
前記第４のファイルプロトコルヘッダから、及び、前記第５のファイルプロトコルヘッダから得られる応答ファイルプロトコルヘッダを作成する段階と、
前記応答ファイルプロトコルヘッダを含む第６のフレームを前記第１のクライアントコンピュータに送る段階と、
を更に含むことを特徴とする請求項３に記載の方法。
【請求項５】
ネットワークシステムにおけるネットワークファイルプロトコル・トランザクションを統合する方法であって、
第１のクライアントコンピュータにより開始される第１のトランザクションに属する第１のメッセージの、第１のファイルプロトコルヘッダと第１のデータとを含む第１のフレームを受信する段階と、
前記第１のファイルプロトコルヘッダの情報に基づいて、前記第１のトランザクションの処理に参加する第１の組のファイルサーバを選択する段階と、
前記第１のファイルプロトコルヘッダから得られる第２のファイルプロトコルヘッダと前記第１のデータの一部分とを含む第２のフレームを、前記第１の組のファイルサーバの第１のサーバに送る段階と、
前記第１のメッセージの、第２のデータを含む第３のフレームを受信する段階と、
第３のファイルプロトコルヘッダと前記第２のデータの一部分とを含む第４のフレームを、前記第１の組のファイルサーバの第２のサーバに送る段階と、
を含むことを特徴とする方法。
【請求項６】
第４のファイルプロトコルヘッダを含む第５のフレームを前記第１のサーバから受信する段階と、
第５のファイルプロトコルヘッダを含む第６のフレームを前記第２のサーバから受信する段階と、
前記第４のファイルプロトコルヘッダから、及び、前記第５のファイルプロトコルヘッダから得られる第６のファイルプロトコルヘッダを含む第７のフレームを前記第１のクライアントコンピュータに送る段階と、
を更に含むことを特徴とする請求項５に記載の方法。
【請求項７】
修正された第１のファイルプロトコルヘッダと前記第１のデータの一部分とを含む第５のフレームを、前記第１の組のファイルサーバの第３のサーバに送る段階と、
ファイルプロトコルヘッダと前記第２のデータの一部分とを含む第６のフレームを、前記第１の組のファイルサーバの第４のサーバに送る段階と、
を更に含むことを特徴とする請求項５に記載の方法。
【請求項８】
ネットワークシステムにおけるネットワークファイルプロトコル・トランザクションを統合する方法であって、
第１のクライアントコンピュータにより開始された第１のトランザクションに属し、第１のファイルプロトコルヘッダを含む第１のフレームを受信する段階と、
前記第１のファイルプロトコルヘッダの情報に基づいて、前記第１のトランザクションの処理に参加する第１の組のファイルサーバを選択する段階と、
修正された第１のファイルプロトコルヘッダを含む第２のフレームを、前記第１の組のファイルサーバの第１のサーバに送る段階と、
修正された第１のファイルプロトコルヘッダを含む第３のフレームを、前記第１の組のファイルサーバの第２のサーバに送る段階と、
を含むことを特徴とする方法。
【請求項９】
第２のファイルプロトコルヘッダと第１のデータとを含む第４のフレームを前記第１のサーバから受信する段階と、
第３のファイルプロトコルヘッダと第２のデータとを含む第５のフレームを前記第２のサーバから受信する段階と、
前記第２のファイルプロトコルヘッダの情報と前記第３のファイルプロトコルヘッダの情報とに基づいて、応答ファイルプロトコルヘッダを作成する段階と、
前記応答ファイルプロトコルヘッダと前記第１のデータの一部分とを含む第６のフレームを、前記第１のクライアントコンピュータに送る段階と、
を更に含むことを特徴とする請求項６に記載の方法。
【請求項１０】
ネットワークファイルプロトコル・トランザクションを切り替えて統合することによりファイルシステムを統合する方法。
【請求項１１】
複数のファイルシステムのネームスペースを統合し、それらを単一ネームスペースとして呈示する段階と、
複数のファイルシステムのディレクトリを、それらを単一ディレクトリとして呈示することにより統合する段階と、
複数のファイルシステムのファイルオブジェクトを、それらを単一ファイルオブジェクトとして呈示することにより統合する段階と、
複数のファイルシステムにおけるファイルのファイルデータを、それを単一ファイルのデータとして呈示することにより統合する段階と、
を含むことを特徴とする、ファイルシステムを統合する方法。
【請求項１２】
統合ファイルシステムのための同時性解決機構を実施するために、前記複数のファイルシステムの各々に設けられた同時性解決機構を統合する段階、
を更に含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
複数のファイルシステムのネームスペースを統合し、それらを単一ネームスペースとして呈示する段階と、
複数のファイルシステムのディレクトリを、それらを単一ディレクトリとして呈示することにより統合する段階と、
複数のファイルシステムのファイルオブジェクトを、それらを単一ファイルオブジェクトとして呈示することにより統合する段階と、
複数のファイルシステムにおけるファイルのファイルデータを、それを単一ファイルのデータとして呈示することにより統合する段階と、
を含むことを特徴とする、ネットワーク・ストレージ・システムにおけるファイルを記憶する方法。
【請求項１４】
スイッチがサーバに対してクライアントとして見えるようにスイッチを実装する段階と、
スイッチがクライアントに対してサーバとして見えるようにスイッチを実装する段階と、
前記スイッチ間で調停するために、複数のクライアント間で調停するサーバの能力を使用する段階と、
を含むことを特徴とする、クライアント／サーバ・プロトコルを切り替えるスイッチを拡張する方法。
【請求項１５】
複数の同時クライアントからの要求を調停するサーバの能力をもたらすクライアント／サーバ・ネットワークプロトコルの下で機能し、前記ネットワークプロトコルのクライアント側を実行するクライアントと前記ネットワークプロトコルのサーバ側を実行するサーバとを含むストレージネットワークを拡張する方法であって、
各々がクライアントと通信する時はネットワークプロトコルのサーバ側を形成し、サーバと対話する時はネットワークプロトコルのクライアント側を形成する複数のスイッチを、クライアントとサーバとの間に挿入する段階と、
前記スイッチ間で調停するために、複数の同時クライアント間で調停するサーバの能力を使用する段階と、
を含むことを特徴とする方法。
【請求項１６】
複数のクライアントコンピュータと複数のサーバコンピュータとを含むコンピュータネットワークにおいて、複数のクライアントコンピュータのうちの少なくとも１つと複数のサーバコンピュータのうちの少なくとも１つとの間で相互接続された、ファイルを切り替えて統合する装置であって、
ファイルスイッチコンピュータが、
データとファイルプロトコルヘッダとを第１のメッセージフレームに含むメッセージを受信し、
前記ファイルプロトコルヘッダに基づき、かつ前記メッセージのデータから独立した方法で、少なくとも１つのどのネットワークノードに前記メッセージを転送するべきかを判断し、
前記判断に基づく方法で、修正されたファイルプロトコルヘッダを導出し、
前記修正されたファイルプロトコルヘッダと前記メッセージデータとを転送する、
ことを特徴とする装置。
【請求項１７】
複数の同時メッセージが前記ファイルスイッチコンピュータにより受信された時には、この同時メッセージの１つだけが、成功する要求をもたらすことを特徴とする請求項１６に記載の装置。
【請求項１８】
複数のクライアントコンピュータと複数のサーバコンピュータとを含むコンピュータネットワークにおいて、少なくとも１つのクライアントコンピュータと少なくとも１つのサーバコンピュータとの間でファイル切替及びファイル統合機能性を提供する装置であって、
前記少なくとも１つのサーバコンピュータに対してはクライアントコンピュータ、及び、前記少なくとも１つのクライアントコンピュータに対してはサーバコンピュータとして見える、
ことを特徴とする装置。
【請求項１９】
複数のクライアントコンピュータと、
複数のサーバコンピュータと、
クライアントコンピュータからのファイルメッセージを複数のサーバコンピュータに切り替えることができる少なくとも１つのファイルスイッチと、
を含むことを特徴とする、ネットワーク化されたファイルデータを処理するための交換ファイルシステム。
【請求項２０】
複数のクライアントコンピュータと、
複数のサーバコンピュータと、
複数のサーバからのファイルメッセージをクライアントコンピュータに統合することができる少なくとも１つのファイルスイッチと、
を含むことを特徴とする、ネットワーク化されたファイルデータを処理するための交換ファイルシステム。
【請求項２１】
複数のサーバ、ファイルスイッチ、及び、複数のクライアントを含むコンピュータネットワークにおいて、
第１のファイルスイッチが、ファイルヘッダをその第１のパケットに含むファイルプロトコルメッセージをクライアントから受信し、
前記第１のファイルスイッチは、前記ファイルヘッダを解析し、
前記第１のファイルスイッチは、複数のメッセージ処理規則に従って、前記メッセージを複数のサーバ間で分割する方法を判断する、
ことを含む方法に従って複数のサーバ間で作成されて維持されることを特徴とするファイルディレクトリ。
【請求項２２】
前記ネットワークは、複数のスイッチを更に含むことを特徴とする請求項２１に記載の方法に従って作成されて維持されたファイルディレクトリ。
【請求項２３】
前記メッセージ処理規則は、第２のファイルスイッチにより共用されることを特徴とする請求項２２に記載の方法に従って作成されて維持されたファイルディレクトリ。
【請求項２４】
前記複数のメッセージ処理規則は、少なくとも１つのファイルサーバから受信したファイルメッセージを通じて、前記第１及び第２ファイルスイッチにおいて更新されることを特徴とする請求項２３に記載のファイルディレクトリ。
【請求項２５】
ネットワーク使用データを供給する装置であって、
複数のクライアントコンピュータと複数のサーバコンピュータとを含むコンピュータネットワークにおいて、前記クライアントコンピュータと前記サーバコンピュータとの間でファイルを統合するための、クライアント及びサーバコンピュータ間でファイルメッセージを切り替えながら使用データを収集する装置、
を含むことを特徴とする装置。
【請求項２６】
ファイルを統合するための複数の規則は、前記使用データから得られることを特徴とする請求項２５に記載の装置。
【請求項２７】
ファイルを統合するための複数の規則を含み、
前記複数の規則に対する少なくとも１つの変更は、前記使用データから得られる、
ことを特徴とする請求項２５に記載の装置。
【請求項２８】
前記少なくとも１つの変更は、前記ネットワーク内の第２の統合装置において反映されることを特徴とする請求項２７に記載の装置。
【請求項２９】
各々が複数の規則に従ってファイルを統合する複数のファイルアグリゲータを含むネットワークにおいて、複数のファイルアグリゲータ内で規則を変更する方法であって、
第１のアグリゲータにおいて規則を変更する段階と、
前記第１のアグリゲータが、残りの複数のファイルアグリゲータに前記規則の変更を転送する段階と、
前記残りの複数のファイルアグリゲータにおいて前記規則を更新する段階と、
を含むことを特徴とする方法。
【請求項３０】
サーバ及びクライアントを有する複数のネットワーク参加者を含み、ファイルトランザクションがこのネットワーク参加者間に流れるコンピュータネットワークにおいて、複数のネットワーク参加者間の単一トランザクションの切替及び統合を提供する装置。
【請求項３１】
ヘッダを有するトランザクションを交換する複数のネットワークノードを含むコンピュータネットワークにおいて、トランザクションヘッダ内に含まれた情報に基づく方法で、ファイルプロトコル・トランザクションを他のネットワークノード間で切り替えるネットワークノード。
【請求項３２】
ネットワークの複数のサーバを統合するための装置であって、
ネットワークプロトコル・トランザクションを統合する手段、
を含むことを特徴とする装置。
【請求項３３】
ネットワーククライアントを複数のネットワークサーバに接続するための装置であって、
ネットワークファイルを切り替える手段、
を含むことを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００１年１月１１日出願の「ファイル切替及び交換ファイルシステム」という名称の米国特許仮出願第６０／２６１，１５３号に基づく優先権を主張する。当該出願の開示内容は、引用により本明細書に組み込まれる。
【０００２】
本発明は、一般に、ストレージネットワークの分野に関し、更に詳しくは、ファイル切替システム及び交換ファイルシステムに関する。
【背景技術】
【０００３】
コンピュータネットワーキングの誕生以来、ストレージへのアクセスは、最も重要なネットワークアプリケーションのうちの１つになっている。その理由は簡単であり、つまり、種々のネットワークの目的は、過去及び現在もデータ及びコンテンツを共用することであり、共用する価値があるデータの大部分は、何らかの形態のストレージ上にある。
【０００４】
各種ネットワーク内のストレージアプリケーションの重要性にも拘わらず、その有益性は、各種ネットワークによって提供される不十分な帯域幅によって最近まで大きく制限されてきた。１００メガビット／秒（Ｍｂｐｓ）（既存ローカル・エリア・ネットワークにおける最も一般的な最大速度、「高速イーサネット」としても公知である）においてさえも、ネットワークからのデータへのアクセスは、ローカルにコンピュータに取り付けられたハードディスクからの読取りよりも数倍時間が掛かる。こういう理由から、従来、ネットワークコンピュータ（ワークステーション又はアプリケーションサーバ、「クライアント」といわれることが多い）によってアクセスされるデータの大半は、ローカルストレージ上にあり、共用されたデータのみがネットワークサーバ上に置かれてきた。
【０００５】
しかし、ギガビットネットワーク技術の導入が、ゲームのルールを変えつつある。単一の「ギガビットイーサネット」又は「ＦｉｂｒｅＣｈａｎｎｅｌ」接続は、最大２４０メガバイト／秒（ＭＢ／ｓ）の合計速度でデータを搬送することができ、この速度は、大半のローカルに取り付けられたストレージ装置の性能よりも遥かに大きい。これは、ギガビットネットワークでは、ローカルストレージよりも遥かに高速にネットワークを通じてデータにアクセスすることができることを意味する。その結果、有益なデータの大部分はネットワークに移されているという基本的傾向の始まりに現在到達したところである。
【０００６】
ストレージネットワーク
テラバイトのデータをネットワーク上に記憶し、そのデータを何万何十万というユーザに対してアクセス可能にする能力は、非常に魅力的である。同時に、このような量のデータ及び使用負荷を適切に処理することができるストレージシステム及びネットワークシステムを作ることは、簡単なことではない。その結果、ストレージネットワーキング（このようなシステムの設計、構築、及び、管理を取り扱う専門分野）は、コンピュータネットワーキングの個別の特化された分野として急速に認識されてきている。
【０００７】
ストレージネットワーキングという分野の紹介は、「ＩｎｆｏＳｔｏｒ」マガジンの１９９８年２月号（ペン・ウェル・コーポレーション出版）のマイケル・ピーターソン著「ストレージ・エリア・ネットワークの導入」、及び、マーク・ファーレー著「ストレージネットワークの構築」（２０００年１月、マグローヒル出版、ＩＳＢＮ００７２１２０５０９）に見出すことができる。ストレージ・ネットワーク・アーキテクチャの卓越した概要については、「オースペックス・ストレージ・アーキテクチャ・ガイド」（第２版、２００１年、オースペックス・システムズ・インコーポレーテッド出版）を参照することができる。この分野に関する完全な背景とそのビジネス上の意味、及び、現行技術の比較分析については、ロバート・Ｍ・モンターグ他著の「システム・エリア・ネットワーク：データセンタにおける次世代スケール」（２００１年７月２６日、「Ｄａｉｎ  Ｒａｕｓｃｈｅｒ  Ｗｅｓｓｅｌｓ  Ｅｑｕｉｔｙ  Ｃａｐｉｔａｌ  Ｍａｒｋｅｔｓ」出版）を参照することができる。
【０００８】
ストレージネットワーキングの重要な将来的な見込みは、莫大な量の情報及びコンテンツの地理的に分散したユーザ間での共用を可能にするネットワークシステムの供給にある。このような将来的な見込みを達成するためには、ストレージ・ネットワーク・システムは、公衆電話システムの有効性に比する高度な有効性を実現しながら、極めて拡張可能でなければならない。更に、この規模のいかなるシステムも、効果的に管理することができるように設計されるべきである。
【０００９】
一般に、ストレージサービスをネットワークに供給するには、「ネットワークディスク」及び「ネットワークファイル」という２つの異なる方法がある。第１の手法では、ネットワーククライアントは、固定サイズのデータブロックのアレーとして一般的にアドレス可能な「生」ストレージリソースにアクセスすることができる。第２の手法では、クライアントは、ファイル・システム・サービスにアクセスするための「ＮＦＳ」及び「ＣＩＦＳ」のようなプロトコルが与えられる。「ＮＦＳ」プロトコルは、Ｂ・キャラハン他著「ＮＦＳバージョン３プロトコル仕様」（ＲＦＣ  １８１３）（１９９５年６月、ザ・インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）出版）で説明されている。「ＣＩＦＳ」プロトコルは、ジム・ノートン他著「ＣＩＦＳプロトコルバージョン、ＣＩＦＳ仕様０．９」（２００１年３月、ストレージ・ネットワーキング・インダストリー・アソシエーション（ＳＮＩＡ）出版）で説明されている。これらのプロトコルは、一般的に、セキュリティ、階層的ディレクトリ、個々の指定ファイルを作成する、開く、及び、閉じる能力、及び、このようなファイル内のデータへのアクセスを提供する。大部分のシステムにおいて、クライアントは、各ファイルを個別の拡張可能なバイトのアレーとして閲覧することができる。また、ファイル・アクセス・プロトコルは、複数のクライアントによる同じファイルへの同時アクセスを仲介する能力を提供する。
【００１０】
「ネットワークディスク」手法は、「ＳＡＮ」（システム・エリア・ネットワーク）として公知のストレージ・ネットワーキング・アーキテクチャの基盤であり、「ネットワークファイル」手法は、「ＮＡＳ」（ネットワーク・アタッチド・ストレージ）及び分散ファイルシステムを含むいくつかのアーキテクチャの中核である。
【００１１】
現在、利用可能なアーキテクチャのいずれも、ストレージネットワーキングの将来的な見込みを適切に実現することはできない。システム・エリア・ネットワークは、比較的良好に拡張している。しかし、「ＳＡＮ」内のデータの共用は、以下で説明する理由から極めて困難である。また、更に以下で説明する「ＮＡＳ」及び分散ファイルシステムは、データ共用においては素晴らしいが、性能及び帯域に関しては、拡張が非常に難しいことが判明している。これらの限界のために、両形式のシステムは、管理するのが非常に厄介である。その結果、今日では、１つのストレージ管理者は、８０ギガバイトに過ぎないデータの管理も容易でないという課題に直面しており、テラバイトシステムの管理の経費及び複雑さは天文学的である。
【００１２】
ストレージネットワーキングの初期のアプリケーションは、オンライン取引処理、データマイニング、及び、顧客データなどのようなデータベースストレージが中心であった。これらのアプリケーションにおいては、「ＳＡＮ」は、依然として最も一般的なアーキテクチャである。電子メール、文書リポジトリー、ＣＡＤ／ＣＡＭ、デジタル静止画像及びデジタル映像生成、ストリーミング高解像度（ＨＤＴＶ）ビデオ、ＸＭＬベース「ソフト構造」データ、及び、他の多くのものなど、今日のアプリケーションは、ますますファイルベース化している。その結果、高性能で高い利用可能性を有するネットワーク・ファイル・サービスが、ますます重要になりつつある。
【００１３】
ファイルシステム拡張に対する利用可能な手法
全てのファイルシステムの主たる機能は、ストレージリソースへのアクセスの共用を可能することである。事実、ファイルシステムは、元々、複数のアプリケーション及び複数のユーザ間の当時高価であったストレージの共用を容易にするために作り出されたものである。その結果、ファイルシステムは、ネットワークサービスとして呈示される時、データ共用の問題に対する完全かつ成熟した解決策となる。
【００１４】
その反面で、ファイルシステムは、複雑かつ非常に処理集中的であり、このため実質的には、高速ネットワークでファイルサービスを行うあらゆるコンピュータに対する性能上の要件が厳しくなる。何百何千ものユーザに種々のファイルを同時に供給するには、莫大な量の処理力、メモリ、及び、バス帯域幅が必要である。
【００１５】
この問題の重要性かつ大きさのために、過去１５年間に亘り幾つかの異なる手法が試行されてきた。ネットワーク・ファイル・システム構築に関連した重要な問題の卓越した概要、及び、様々なファイル・システム・アーキテクチャは、ジョン・ヘンリー・ハートマン著「シマウマ模様ネットワーク・ファイル・システム」（１９９４年、カリフォルニア大学バークレー校大学院で提出された博士論文）に見出すことができる。公知の有効な手法の各々は、一般的に、シングル・ボックス・ソリューション、クラスター・ファイル・システム、及び、分散ファイルシステムという３つの広義の部類のいずれかに該当する。
【００１６】
図１７は、現在有効な、一般的に使用されているネットワーク・ファイル・システムの典型的な応用を示す。このシステムは、多数のクライアントワークステーション１７０１と幾つかのアプリケーションサーバ１７０２とを接続する、様々なファイルサーバに接続されたローカル・エリア・ネットワーク１７００から成る。ファイルサーバは、一般的に、１７０３及び１７０４のような独立型サーバ、及び、共用ストレージ１７０７を有するクラスター１７１０として構成された１７０５及び１７０６のようなファイルサーバを含む。サーバ１７０５及び１７０６は、高速で低待ち時間のイントラクラスター接続１７０９を通じて互いに接続されており、また、一般的に、１７０８のような光（ＦｉｂｒｅＣｈａｎｎｅｌ）相互接続を使用して、「ＳＡＮ」を通じて共用ストレージ１７０７に接続されている。更に、クライアント１７０１、アプリケーションサーバ１７０２、及び、ファイルサーバ１７０３〜１７０６は、適切なソフトウエアサービスが上述のマシンの全てにインストールされた分散ファイルシステムの一部であるように構成することができる。
【００１７】
シングル・ボックス・ソリューション
シングル・ボックス・ソリューションは、ファイルサーバの性能向上という問題に対する単純かつ直接的な手法を提供する。これまで、ファイル供給には最高速の有効なコンピュータが使用された。これらのコンピュータでさえも不十分となった時には、サーバの能力を拡張するために特化アーキテクチャが構築された。１個のプロセッサでは不十分になった場合には、更なるプロセッサが増設され、標準的なバス帯域幅が不十分になった場合には、更なるバス又は特別設計の更に広範囲なバスが導入される、等々が行われた。
【００１８】
このような手法の結果、ハイエンド・ファイル・サーバは、実質的に、あらゆる関連経費及び複雑性を伴う大規模多重処理スーパーコンピュータになっている。シングル・ボックス・ソリューションの例は、「ＥＭＣ  Ｃｅｌｅｒａ／Ｓｙｍｍｅｔｒｉｘ」、「ＳＧＩ  Ｏｒｉｇｉｎ」、「ＨＰ  Ｓｕｐｅｒｄｏｍｅ」、「Ｉｎｔｅｌ  Ｐａｒａｇｏｎ」、及び、「ＩＢＭ  ＳＰ」であり、これらの商標は、本明細書において認知されている。
【００１９】
しかし、高性能多重処理ファイルサーバは、直ぐにそれらのストレージサブシステムの性能限界に入ってしまう。この問題解決の手法は、複数のハードディスク及び並列に作動するデータ経路間の負荷を拡張することである。「ＲＡＩＤ」と、「Ｃｒａｙ  Ｔ３Ｅ  Ｉ／Ｏ」システム及び「ＰＶＦＳ」のようなパラレルファイルシステムとは、この手法の結果として登場したものである。「ＲＡＩＤ」は、Ｄ・パターソン他著「廉価なディスクの冗長なアレー（ＲＡＩＤ）の場合」（データ管理に関する「ＡＣＭ  ＳＩＧＭＯＤ」会議講演論文集、１０９〜１１６ページ、１９９８年６月１日〜３日、米国イリノイ州シカゴ開催、米国計算機学会インコーポレーテッド）で説明されている。「Ｃｒａｙ  Ｔ３Ｅ  Ｉ／Ｏ」システムは、国立エネルギ研究科学計算センター（ＮＥＲＳＣ）発行の「ＮＥＲＳＣ指導書：Ｃｒａｙ  Ｔ３Ｅに関するＩ／Ｏ」の第８章「ディスクストライピング」に説明されている。「ＰＶＦＳ」は、フィリップ・Ｈ・カーンズ他著「ＰＶＦＳ：リナックスクラスターのパラレルファイルシステム」（第４回年次リナックスショーケース及び会議講演論文集、３１７〜３２７ページ、２０００年１０月、米国ジョージア州アトランタ開催、「ＵＳＥＮＩＸ」アソシエーション）で説明されている。
【００２０】
シングル・ボックス・ソリューションには、幾つかの重大な問題がある。第１に、極めて高度に複雑であり、かつ性能要件を満足するために特製シリコンを開発する必要があるために、シングル・ボックス・ソリューションは、極めて経費が掛かる。更に悪いことに、この開発サイクルは非常に長く、一般的に市販されるまでには、ソフトウエア技術やプロトコルのような多くの重要な面において「時勢に取り残される」ことは事実上確実である。ストレージ要件はほぼ毎年実質的に倍増していることから、これらのボックスは、顧客がコスト高をなんとか減らすその前に早々と時代遅れになる場合が多い。
【００２１】
クラスター・ファイル・システム
ボックス内でサーバアーキテクチャを拡張することに代わる方法は、「ＨＩＰＰＩ」又は「ＦｉｂｒｅＣｈａｎｎｅｌ」のような高速相互接続でストレージの同じプールにアクセスする複数のサーバをまとめることである。その結果として登場したのが、多くの点で多重処理スーパーコンピュータと類似の作動をするが、市販の構成品から組み立てることができるコンピュータの「クラスター」である。
【００２２】
クラスター内の全てのコンピュータは、同じ組のハードディスクにアクセスすることから、それらの各々のファイル・システム・ソフトウエアは、ストレージスペースのアクセス及び割り当てを調整する際には、クラスター内の他のソフトウエアと協働しなければならない。この問題に取り組む最も簡単な方法は、ストレージプールを区分化してクラスター内の異なるコンピュータ間で分割することであり、この手法は、「ウィンドウズクラスター化技術−概説」（２０００年１１月、マイクロソフト・コーポレーション）で説明されている「ウィンドウズ」クラスター化で実行されている。更に高度な手法を取ると、「ＰＶＦＳ」（上述のカームズ他を参照）、「Ｔｉｇｅｒｓｈａｒｋ」、「ＧＦＳ」、「ＶＥＲＩＴＡＳ  ＳＡＮｐｏｉｎｔ  Ｆｏｕｎｄａｔｉｏｎ」、「ｘＦＳ」、及び、「Ｆｒａｎｇｉｐａｎｉ」のような特化されたクラスター・ファイル・システムをもたらす。「Ｔｉｇｅｒｓｈａｒｋ」は、ロジャー・Ｌ・ハスキン及びフランク・Ｂ・シュマック共著「タイガーシャークファイルシステム」（ＩＥＥＥ１９９６年度春季ＣＯＭＰＣＯＮ講演論文集、１９９６年２月、米国カリフォルニア州サンタ・クララ開催）で説明されている。「ＧＦＳ」は、スティーブン・ソルティス他著「グローバル・ファイル・システム」（マス・ストレージ・システム及び技術に関する第５回ＮＡＳＡゴダード・スペース・フライト・センター会議講演論文集、１９９６年９月１７日〜１９日、米国メリーランド州カレッジパーク開催）、及び、スティーブン・ソルティス他著「ＩＲＩＸ用共用ディスク・ファイル・システムの設計及び性能」（マス・ストレージ・システムに関する第１５回ＩＥＥＥシンポジウムの協力を得て行われたマスストレージ及び技術に関する第６回ＮＡＳＡゴダード・スペース・フライト・センター会議、１９９８年３月２３日〜２６日）で説明されている。「ＶＥＲＩＴＡＳ  ＳＡＮｐｏｉｎｔ  Ｆｏｕｎｄａｔｉｏｎ」は、「ＶＥＲＩＴＡＳ  ＳＡＮｐｏｉｎｔ  Ｆｏｕｎｄａｔｉｏｎスイート（ｔｍ）及びＳＡＮｐｏｉｎｔ  Ｆｏｕｎｄａｔｉｏｎ（ｔｍ）スイートＨＡ：クラスター環境向けの新ＶＥＲＩＴＡＳボリューム管理及びファイルシステム技術」（２００１年９月、ＶＥＲＩＴＡＳ・ソフトウエア・コーポレーション）で説明されている。「ｘＦＳ」は、トーマス・Ｅ・アンダーソン他著「サーバレス・ネットワーク・ファイル・システム」（オペレーティングシステムの諸原理に関する第１５回シンポジウム、１９９５年１２月、米国計算機学会インコーポレーテッド）で説明されている。「Ｆｒａｎｇｉｐａｎｉ」は、チャンドラモハン・Ａ・テッカース他著「Ｆｒａｎｇｉｐａｎｉ：拡張可能な分散ファイルシステム」（オペレーティングシステムの諸原理に関する第１６回ＡＣＭシンポジウム講演論文集、１９９７年１０月、米国計算機学会インコーポレーテッド）で説明されている。クラスター・ファイル・システムの利点、及び、重要な問題及び問題解決の手法については、ケネス・Ｗ・プレスラン他著「リナックス・クラスター・ファイル・システムにおける拡張可能性及び故障回復」（第４回年次リナックスショーケース及び会議講演論文集、２０００年１０月１０日〜���４日、米国ジョージア州アトランタ開催）、クリス・スタクティス著「ＳＡＮベースのファイルシステムの共用の利点」（「ＩｎｆｏＳｔｏｒ」マガジン２０００年７月号、ペン・ウェル・コーポレーション）、及び、カイ・ファング他著「階層的チェックポイント処理及び単一Ｉ／Ｏスペースを伴うＳＳＩクラスターの設計」（ＩＥＥＥコンカレンシー、６０〜６９ページ、１９９９年１月〜３月）で説明されている。
【００２３】
上述のファイルシステムの全てにおける主たる課題は、クラスター内の全てのメンバー間でのストレージへのアクセスを頻繁に同期及び調整する必要性から生じるものである。これには、異なるファイル及び他の共用メタデータ（データを記述するデータ）へのディスクスペースの割り当てを制御する集中型ロックマネージャ及び／又はファイルマネージャが必要である。これらの要素は、たちまち、約１６個のノードを超えてクラスター・ファイル・システムを拡張するのを妨げる障害になる。
【００２４】
この問題を緩和するために、幾つかのデザインにより、ファイルマネージャ機能性のかなりの部分がストレージサブシステム又はクライアントソフトウエアのいずれかに移行している。この手法の例は、「Ｚｅｂｒａ」（上述のハートマンを参照）、「Ｓｗｉｆｔ」、及び、「ＮＡＳＤ」である。「Ｓｗｉｆｔ」は、ルイス・フェリップ・カブレラ及びダレル・Ｄ・Ｅ・ロング共著「Ｓｗｉｆｔ：大オブジェクトのためのストレージアーキテクチャ」（マス・ストレージ・システムに関する第１１回ＩＥＥＥシンポジウム講演論文集、１２３〜１２８ページ、１９９１年１０月）、及び、Ｄ．Ｄ．Ｅ．ロング他著「Ｓｗｉｆｔ／ＲＡＩＤ：分散ＲＡＩＤシステム」（コンピューティングシステム第７巻、３３３〜３５９ページ、１９９４年夏）で説明されている。「ＮＡＳＤ」は、ガース・Ａ・ギブソン他著「ＮＡＳＤ拡張可能ストレージシステム」（１９９９年６月、ＵＳＥＮＩＸ９９、イクストリーム・リナックス・ワークショップ、米国カリフォルニア州モンテレー開催）、及び、ガース・Ａ・ギブソン他著「ネットワーク・アタッチド・セキュア・ディスクによるファイルサーバ拡張」（コンピュータシステムの測定及びモデル化に関するＡＣＭ国際会議（シグメトリクス９７）講演論文集、１９９７年、米国計算機学会インコーポレーテッド）で説明されている。これらの手法は、いずれも本出願作成の時点では商業化には成功していないが、入手可能なデータによると、これまでのクラスター・ファイル・システムよりも良好に拡張することが示唆されている。
【００２５】
集中型リソース調整への依存は、拡張可能性を厳しく制限するクラスター・ファイル・システムの主な弱点である。部分的にこの問題を緩和する種々の解決策により、ストレージサブシステムの特注機能性及び特化されたクライアント側ソフトウエアを含む他の問題が引き起こされる。これらの手法のいずれかが商業化された場合、独自仕様のストレージサブシステムを使用する種々の要件が、導入及び価格の両方にかなりの悪影響を及ぼすことになり、一方、システムにアクセスする全てのクライアントにインストールしなければならない独自仕様のクライアント側ソフトウエアに依存する必要性により、システムは、壊れやすくてセキュリティ上の侵害を受けやすくなり、配備及びサポートが困難なものになる。
【００２６】
分散ファイルシステム
シングル・ボックス・ソリューション及びクラスター・ファイル・システムのいずれも、重大な拡張可能性上の限界を呈する固く結合したシステムである。分散ファイルシステムの構築は、単一ファイルシステムとしてアクセス及び管理することができる統合されたシステム内の何百ものファイルサーバを結びつけようとする手法である。分散ファイルシステムの例は、「アンドリュー・ファイル・システム」及びその派生物である「ＡＦＳ及びＣｏｄａ」、「Ｔｒｉｃｏｒｄ」、及び、「マイクロソフト分散ファイルシステムＤＦＳ」である。「ＡＦＳ及びＣｏｄａ」は、「分散計算環境におけるＡＦＳファイルシステム」（１９９６年５月１日、トランサーク・コーポレーション）、及び、エドワード・Ｒ・ザヤス著「ＡＦＳ−３プログラマ用資料：アーキテクチャ概要」（トランサーク・コーポレーション、１９９１年９月２日バージョン１．０、文書番号ＦＳ−００−Ｄ１６０）で説明されている。「Ｔｒｉｃｏｒｄ」は、２０００年２月２２日にフレイに付与された「分散計算環境におけるストライプド・ネットワーク・ファイル・システムにおける分散ファイルマッピング」という名称の米国特許第６，０２９，１６８号で説明されている。「マイクロソフトＤＦＳ」は、「分散ファイルシステム：物理的ストレージの論理的見解：白書」（１９９９年、マイクロソフト・コーポレーション）で説明されている。
【００２７】
分散ファイルシステムは、広範な地理的位置に配置することができるファイルサーバの緩く結合された集まりである。分散ファイルシステムにより、ファイルネームスペースに関して統合された視野が得られ、クライアントは、当該のファイルがシステムのどこにあるのかに関係なく、ファイルにアクセスすることができる。更に、システム管理者は、ファイルを１つのサーバから別のサーバにガラス張りで移動し、また、システムの部分的故障発生時の利用可能性を上げるために、複数のサーバに亘ってファイルを複製することができる。
【００２８】
分散ファイルシステムには、ストレージ容量に関して優れた拡張可能性がある。オフラインに移動することなく新しいサーバを既存システムに追加するのが簡単である。更に、分散ファイルシステムにより、異なる地理的位置にあるストレージを接続して単一の密着したシステムにすることができる。
【００２９】
利用可能な分散ファイルシステムに関する主な問題は、性能の拡張がストレージ容量の拡張ほど良好でないということである。システム内のサーバ個数がいかに多くても、個々のファイルの各々は、正確に１つのサーバ上にある。従って、分散ファイルシステムが１つのクライアント（ワークステーション又はアプリケーションサーバ）に供給することができる性能は、利用される個別のファイルサーバの性能によって制限され、この性能は、関与するサーバ個数が多い点を考慮すると、非常に高性能なマシンにはなりそうもない。
【００３０】
商業レベルの環境において大きな影響を与える別の問題は、大部分の分散ファイルシステムでは、ファイルシステムにアクセスする全てのクライアントの各々にインストールし、かつ適切に構成しなければならない特化されたクライアント側ソフトウエアが必要であるということである。これは、バージョン改訂及びサポート上の大きな問題を作り出す傾向がある。
【００３１】
更に、分散ファイルシステムは、「ホットスポッティング」に非常に弱い。ホットスポッティングは、単一サーバ上にある個別のファイル又は小さな組のファイルに対する要求が短期間に劇的に増加した時に発生し、その結果、多数のユーザが激しい性能低下に見舞われる。
【００３２】
分散ファイルシステムに関する更なる別の問題は、管理容易性が低い点である。分散ファイルシステムの大部分の状況は、システムがオンライン上にある間に管理することができるが、これらのシステムの混成かつ分散された性質は、あらゆる管理作業の真の自動化を実質的に除外する。その結果、分散ファイルシステムの管理には、多くの高度な労働力が必要とされる。
【００３３】
まとめ
ネットワーク・ファイル・システムの拡張に対する多くの手法が過去１５年間に亘り行われてきたが、いずれも、ストレージネットワーキングの高性能、高拡張可能性、及び、簡単な管理に関する将来的見込みの達成には成功していない。上述のシステムを分析すると、これらの限界の全ては、小さな組の根本的な欠陥に帰することができ、すなわち、全ての利用可能なシステムには、以下の問題の少なくとも１つがあることがわかる。
【００３４】
１．１つのファイルに１つのサーバ。単一ファイルに対する要求を処理する際に複数のファイルサーバを利用することはできないために、任意の単一クライアントが利用可能な処理能力が厳しく制限され、システムは、全ての利用可能な処理リソースに亘る負荷の均衡を取ることができない。
２．集中型アービトレーション及びメタデータ管理。ストレージへのアクセスを調停する必要性と、それを管理するのに使用される共用データ構造とは、システムの拡張可能性を厳しく制限する障害を作り出す。
３．独自仕様のクライアント側ソフトウエア。複数の異なるオペレーティングシステムを実行する全てのクライアントマシンに亘って、重要なソフトウエア部分を購入、インストール、設定、及び、サポートする必要性は、導入に当たり深刻な障壁を作り出す。
【００３５】
層７スイッチング
「ＩＰ」ネットワークにおいては、拡張可能性に関する種々の問題は、一般的にスイッチングを通じて解決される。近年では、インテリジェント層７スイッチを使用して、別のネットワークサービス、すなわち、ウェブサイトにおける拡張可能性に関する問題を極めてうまく解決している。特に、アルテオン・ウェブ・システムズは、「コンテンツ・インテリジェント・スイッチングによる次世代ウェブインフラストラクチャの拡張：白書」（２０００年４月、アルテオン・ウェブ・システムズ・インコーポレーテッド）で説明されているウェブスイッチという概念を開拓した。ウェブスイッチは、何百もの商品「ＨＴＴＰ」サーバを単一高性能仮想ウェブサーバに統合することにより、高トラヒックウェブサイトを拡張するのに使用される。
【００３６】
ウェブスイッチは、「ＴＣＰ」接続及びこれらの接続上の「ＨＴＴＰ」プロトコルトランザクション全体を追跡して切り替え、それらを、ネットワーク層２及び３で作動して個々のネットワークパケットを切り替える「イーサネット」及び「ＩＰ」スイッチと区別することにより作動する。「ＨＴＴＰ」トランザクションを識別して切り替えることにより、ウェブスイッチは、負荷を複数の「ＨＴＴＰ」サーバ間で配分し、同時に、個々のクライアントのセッションの連続性と、ショッピングカートや「ＨＴＴＰ」インタフェースを通じた電子メールアカウントへのアクセスなどのようなそれに関連した状態を確保する。
【００３７】
ウェブスイッチを使用すると、極めて拡張可能であることが実証されたネットワークシステムをもたらす。一例として、「ｗｗｗ．ｈｏｔｍａｉｌ．ｃｏｍ」は、「ＩＰ」ネットワーク内で互い結合された何百もの商品ＰＣベースのウェブサーバから構築されたシステムを用いて、６０００万人を超えるアクティブユーザに使用されている。
【００３８】
残念ながら、利用可能な技術には幾つかの根本的な制限があるために、ウェブスイッチは、ネットワーク・ファイル・システムの拡張に使用することはできない。第１に、ウェブスイッチは、個々のプロトコルの各々を通じたトランザクションを単一サーバに誘導し、これは、高い統合的性能及び／又は有効性を個々のクライアントへ供給するのと並行して複数のサーバを使用することを排除する。第２に、「ＨＴＴＰ」トランザクションは、任意の利用可能なサーバに方向付けることができるが、ファイルプロトコル・トランザクションは、そのファイルが存在する特定のサーバに経路指定されなければならない。第３に、「ＨＴＴＰ」トランザクションと異なり、ファイルプロトコルでは、一般的に、調整された方法で追跡して切り替えなければならない複数のレベルのネスト化されたトランザクション（例えば、接続、ログイン、マウント、ファイルオープン、ロック）が使用される。最後に、操作するオブジェクトに対してアトミックである「ＨＴＴＰ」と異なり、ファイルプロトコルのセマンティクスでは、ディレクトリ、ファイルオブジェクト、及び、データの様々な面を複数のユーザが独立かつ同時にアクセスして修正する能力が必要とされる。
【００３９】
【特許文献１】
米国特許仮出願第６０／２６１，１５３号
【特許文献２】
米国特許第６，０２９，１６８号
【非特許文献１】
マイケル・ピーターソン著  「ストレージ・エリア・ネットワークの導入」  ペン・ウェル・コーポレーション出版  「ＩｎｆｏＳｔｏｒ」マガジンの１９９８年２月号
【非特許文献２】
マーク・ファーレー著  「ストレージネットワークの構築」  マグローヒル出版（ＩＳＢＮ００７２１２０５０９）  ２０００年１月
【非特許文献３】
「オースペックス・ストレージ・アーキテクチャ・ガイド」（第２版  オースペックス・システムズ・インコーポレーテッド出版  ２００１年
【非特許文献４】
ロバート・Ｍ・モンターグ他著  「システム・エリア・ネットワーク：データセンタにおける次世代スケール」「Ｄａｉｎ  Ｒａｕｓｃｈｅｒ  Ｗｅｓｓｅｌｓ  Ｅｑｕｉｔｙ  Ｃａｐｉｔａｌ  Ｍａｒｋｅｔｓ」出版  ２００１年７月２６日
【非特許文献５】
Ｂ・キャラハン他著  「ＮＦＳバージョン３プロトコル仕様」（ＲＦＣ  １８１３）  ザ・インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）出版  １９９５年６月
【非特許文献６】
ジム・ノートン他著  「ＣＩＦＳプロトコルバージョン、ＣＩＦＳ仕様０．９」  ストレージ・ネットワーキング・インダストリー・アソシエーション（ＳＮＩＡ）出版  ２００１年３月
【非特許文献７】
Ｄ・パターソン他著  「廉価なディスクの冗長なアレー（ＲＡＩＤ）の場合」（データ管理に関する「ＡＣＭ  ＳＩＧＭＯＤ」会議講演論文集  １０９〜１１６ページ  米国イリノイ州シカゴ開催  米国計算機学会インコーポレーテッド  １９９８年６月１日〜３日
【非特許文献８】
「ＮＥＲＳＣ指導書：Ｃｒａｙ  Ｔ３Ｅに関するＩ／Ｏ」の第８章「ディスクストライピング」  国立エネルギ研究科学計算センター（ＮＥＲＳＣ）発行
【非特許文献９】
フィリップ・Ｈ・カーンズ他著  「ＰＶＦＳ：リナックスクラスターのパラレルファイルシステム」  第４回年次リナックスショーケース及び会議講演論文集  ３１７〜３２７ページ  米国ジョージア州アトランタ開催  「ＵＳＥＮＩＸ」アソシエーション  ２０００年１０月
【非特許文献１０】
「ウィンドウズクラスター化技術−概説」  マイクロソフト・コーポレーション  ２０００年１１月
【非特許文献１１】
ロジャー・Ｌ・ハスキン及びフランク・Ｂ・シュマック共著  「タイガーシャークファイルシステム」  ＩＥＥＥ１９９６年度春季ＣＯＭＰＣＯＮ講演論文集  米国カリフォルニア州サンタ・クララ開催  １９９６年２月
【非特許文献１２】
スティーブン・ソルティス他著  「グローバル・ファイル・システム」  マス・ストレージ・システム及び技術に関する第５回ＮＡＳＡゴダード・スペース・フライト・センター会議講演論文集  米国メリーランド州カレッジパーク開催  １９９６年９月１７日〜１９日
【非特許文献１３】
スティーブン・ソルティス他著  「ＩＲＩＸ用共用ディスク・ファイル・システムの設計及び性能」  マス・ストレージ・システムに関する第１５回ＩＥＥＥシンポジウムの協力を得て行われたマスストレージ及び技術に関する第６回ＮＡＳＡゴダード・スペース・フライト・センター会議  １９９８年３月２３日〜２６日
【非特許文献１４】
「ＶＥＲＩＴＡＳ  ＳＡＮｐｏｉｎｔ  Ｆｏｕｎｄａｔｉｏｎスイート（ｔｍ）及びＳＡＮｐｏｉｎｔ  Ｆｏｕｎｄａｔｉｏｎ（ｔｍ）スイートＨＡ：クラスター環境向けの新ＶＥＲＩＴＡＳボリューム管理及びファイルシステム技術」  ＶＥＲＩＴＡＳ・ソフトウエア・コーポレーション  ２００１年９月
【非特許文献１５】
トーマス・Ｅ・アンダーソン他著  「サーバレス・ネットワーク・ファイル・システム」  オペレーティングシステムの諸原理に関する第１５回シンポジウム  米国計算機学会インコーポレーテッド  １９９５年１２月
【非特許文献１６】
チャンドラモハン・Ａ・テッカース他著  「Ｆｒａｎｇｉｐａｎｉ：拡張可能な分散ファイルシステム」  オペレーティングシステムの諸原理に関する第１６回ＡＣＭシンポジウム講演論文集  米国計算機学会インコーポレーテッド  １９９７年１０月
【非特許文献１７】
ケネス・Ｗ・プレスラン他著  「リナックス・クラスター・ファイル・システムにおける拡張可能性及び故障回復」  第４回年次リナックスショーケース及び会議講演論文集  米国ジョージア州アトランタ開催  ２０００年１０月１０日〜１４日
【非特許文献１８】
クリス・スタクティス著  「ＳＡＮベースのファイルシステムの共用の利点」  ペン・ウェル・コーポレーション  「ＩｎｆｏＳｔｏｒ」マガジン２０００年７月号
【非特許文献１９】
カイ・ファング他著  「階層的チェックポイント処理及び単一Ｉ／Ｏスペースを伴うＳＳＩクラスターの設計」  ＩＥＥＥコンカレンシー  ６０〜６９ページ  １９９９年１月〜３月
【非特許文献２０】
ルイス・フェリップ・カブレラ及びダレル・Ｄ・Ｅ・ロング共著  「Ｓｗｉｆｔ：大オブジェクトのためのストレージアーキテクチャ」  マス・ストレージ・システムに関する第１１回ＩＥＥＥシンポジウム講演論文集  １２３〜１２８ページ  １９９１年１０月
【非特許文献２１】
Ｄ．Ｄ．Ｅ．ロング他著  「Ｓｗｉｆｔ／ＲＡＩＤ：分散ＲＡＩＤシステム」  コンピューティングシステム第７巻  ３３３〜３５９ページ  １９９４年夏
【非特許文献２２】
ガース・Ａ・ギブソン他著  「ＮＡＳＤ拡張可能ストレージシステム」  ＵＳＥＮＩＸ９９  イクストリーム・リナックス・ワークショップ  米国カリフォルニア州モンテレー開催  １９９９年６月
【非特許文献２３】
ガース・Ａ・ギブソン他著  「ネットワーク・アタッチド・セキュア・ディスクによるファイルサーバ拡張」  コンピュータシステムの測定及びモデル化に関するＡＣＭ国際会議（シグメトリクス９７）講演論文集  米国計算機学会インコーポレーテッド  １９９７年
【非特許文献２４】
「分散計算環境におけるＡＦＳファイルシステム」  トランサーク・コーポレーション  １９９６年５月１日
【非特許文献２５】
エドワード・Ｒ・ザヤス著  「ＡＦＳ−３プログラマ用資料：アーキテクチャ概要」  トランサーク・コーポレーション  文書番号ＦＳ−００−Ｄ１６０  １９９１年９月２日バージョン１．０
【非特許文献２６】
「分散ファイルシステム：物理的ストレージの論理的見解：白書」  マイクロソフト・コーポレーション  １９９９年
【発明の開示】
【発明が解決しようとする課題】
【００４０】
結論
ギガビットネットワーク・インフラストラクチャの大量導入により、ストレージネットワーキングは、ネットワーク上でのコンテンツの配信及び管理に急速に重要になりつつある。これを達成するためには、ストレージネットワークは、何十万人ものユーザ間でのデータの共用を容易にし、ストレージ容量、性能、及び、アクセス帯域幅において極めて良好に拡張することができ、非常に高度な有効性をもたらし、かつ、管理しやすいものでなければならない。電子メール、ストリーミングビデオコンテンツ、文書リポジトリー、及び、他のソフト構造データのような新しいアプリケーションでは、これらの特性がファイルへのアクセスを提供するネットワークサービスにより達成されることがますます要求される。
【００４１】
ネットワーク・ファイル・システムの拡張に対する既存の手法は、これらの要件のうちの１つ又は別の面の解決には成功している。しかし、ストレージネットワーキングがその将来的見込みを達成する上で必要とされる全ての特性をもたらすことができる現在利用可能なシステムは存在しない。
【課題を解決するための手段】
【００４２】
ネットワークにおいては、従って、ファイルスイッチ、ファイルスイッチコンピュータ、又は、ファイルアグリゲータとも呼ばれるネットワークノードをクライアントとサーバとの間に置くことにより、クライアントをサーバと分離することが有利である。このようなファイルスイッチを使用すると、本発明の様々な態様を有利に実行することができる。
【００４３】
本発明の１つの態様は、多重フレームファイルプロトコル要求の第１のネットワークフレームを受信し、その要求のファイルプロトコルヘッダを検査し、要求の残りのフレームを転送する方法と場所を判断し、その後に、この判断に基づいて受信時にそれらのフレームの各々を転送することにより、ネットワーク・プロトコル・トラヒックを切り替えるネットワークノードである。
【００４４】
本発明の別の態様は、プロトコル要求を受信し、ファイルプロトコルヘッダを検査し、それらのヘッダにある情報に基づいてそれらの要求を複数の独立ファイルサーバに転送することにより、ネットワーククライアントにより開始されたネットワークファイルプロトコル・トランザクションを切り替えるネットワークノードである。
【００４５】
本発明の別の態様は、プロトコル要求を受信し、ファイルプロトコルヘッダを検査して複数のファイルプロトコル・トランザクションを異なる独立したファイルサーバで開始し、それらのサーバからの応答を統合し、統合された結果を用いてクライアントトランザクションを完了することにより、ネットワーククライアントにより開始されたネットワークファイルプロトコル・トランザクションを統合するネットワークノードである。
【００４６】
本発明の別の態様は、クライアントと対話しながらネットワークファイルプロトコル内でサーバとして機能し、それぞれのファイルプロトコルヘッダ内に含まれた情報に基づいて複数のファイルサーバ間でそれらのクライアントから受信した要求を切り替え、そのサーバと対話しながらそのネットワークファイルプロトコル内のクライアントとして機能することにより、ネットワークファイルプロトコル・トランザクションを切り替えるネットワークノードである。
【００４７】
本発明の別の態様は、ネットワークファイルプロトコル要求をクライアントから受信し、場合により、これらの要求が開始するトランザクションをファイルサーバ間で切り替えるか又は統合することにより、異なる独立したファイルサーバ上にある複数のファイルを統合してネットワーククライアントに対して単一ファイルとして呈示するネットワークノードである。
【００４８】
本発明の別の態様は、ネットワークファイルプロトコル要求を受信して開始することにより、異なる独立したファイルサーバ上にある複数のファイルを統合してネットワーククライアントに対して単一ファイルとして呈示するネットワークノードである。
【００４９】
本発明の別の態様は、ディレクトリコンテンツの連結を達成するために、クライアントにより開始されたネットワークファイルプロトコルのディレクトリ一覧トランザクションをサーバ間で切り替え、選択が行われる時点でネットワークノード内で利用可能なデータのみを使用して、統合されたディレクトリに属する個々のファイルが存在すべきサーバを選択することにより、異なる独立したファイルサーバ上にあるディレクトリを統合してネットワーククライアントに対して単一ディレクトリとして呈示するネットワークノードである。
【００５０】
本発明の別の態様は、トランザクションに含まれたファイルシステム経路及びスイッチング判断が為されている時点でネットワークノード内で利用可能な情報のみを用いて、クライアントにより開始されたファイルプロトコル・トランザクションをサーバ間で切り替えることにより、複数の独立したファイルサーバのネームスペースを統合して、それらをネットワーククライアントに対して単一の明確なネームスペースとして呈示するネットワークノードである。
【００５１】
本発明の別の態様は、同じエンティティー上で試行された複数の同時トランザクションのうちの１つのみが成功することができるように、統合されたトランザクションの結果を決定論的方法で統合することにより、同じファイルシステムエンティティーを目標とする他のネットワークファイルプロトコル・トランザクションに対して統合されたネットワークファイルプロトコル・トランザクションのアトミックな挙動を達成するネットワークノードである。
【００５２】
本発明の別の態様は、同じファイルを目標にしてネットワーククライアントにより開始されたネットワークファイルプロトコル・トランザクションを切り替えて統合することにより、複数の独立したファイルサーバの性能及びストレージ容量を統合するネットワークノードである。
【００５３】
本発明の別の態様は、トランザクションが持っているファイルデータが一組の独立したファイルサーバ上に複製されるように、ネットワーククライアントにより開始されたファイル書込トランザクションを統合し、クライアントにより開始されたファイル読取りトランザクションをその組から利用可能なファイルサーバに切り替えることにより、ネットワークファイルサービスの有効性を伸ばすネットワークノードである。
【００５４】
本発明の別の態様は、複数の独立したファイルシステムを統合して単一ネットワークファイルシステムとしてネットワーククライアントに呈示し、単一ファイルとしてクライアントに呈示されたファイルのコンテンツが複数の独立したファイルサーバ間で配分されるようなネットワークノードである。
【００５５】
本発明の別の態様は、配分決定が行われる時点でノード内で利用可能な情報のみに基づいて個々のファイルをファイルシステム間で配分することにより、複数の独立したファイルシステムを統合して単一ファイルシステムとしてネットワーククライアントに呈示するネットワークノードである。
【００５６】
本発明の別の態様は、異なる独立したファイルサーバ上にある複数のファイルを統合して単一ファイルとしてネットワーククライアントに呈示し、特定の統合パラメータが、ファイル作成が要求された時に所定の組の規則及びポリシーから選択された規則及びポリシーから判断されるようなネットワークノードである。
【００５７】
本発明の別の態様は、ネットワークシステム内のネットワークファイルプロトコル・トランザクションを統合する方法であって、本方法は、第１のクライアントコンピュータにより開始される第１のトランザクションに属する第１のメッセージの、第１のファイルプロトコルヘッダと第１のデータとを含む第１のフレームを受信する段階と、第１のファイルプロトコルヘッダ内の情報に基づいて、第１のトランザクションの処理に参加するために第１の組のファイルサーバを選択する段階と、第１のファイルプロトコルヘッダから引き出された第２のファイルプロトコルヘッダと第１のデータの一部分とを含む第２のフレームを第１の組のファイルサーバの第１のサーバに送る段階とを含む。
【００５８】
本発明の更に別の態様は、ネットワークシステム内のネットワークファイルプロトコル・トランザクションを統合する方法であって、本方法は、第１のクライアントコンピュータにより開始された第１のトランザクションに属する第１のメッセージの、第１のファイルプロトコルヘッダと第１のデータとを含む第１のフレームを受信する段階と、第１のファイルプロトコルヘッダ内の情報に基づいて、第１のトランザクションの処理に参加するために第１の組のファイルサーバを選択する段階と、第１のファイルプロトコルヘッダから引き出された第２のファイルプロトコルヘッダと第１のデータの一部分とを含む第２のフレームを第１の組のファイルサーバの第１のサーバに送る段階と、第２のデータを含む、第１のメッセージの第３のフレームを受信する段階と、第３のファイルプロトコルヘッダと第２のデータの一部分とを含む第４のフレームを第１の組のファイルサーバの第２のサーバに送る段階とを含む。
【００５９】
本発明の更に別の態様は、ネットワークシステム内のネットワークファイルプロトコル・トランザクションを統合する方法であって、本方法は、第１のクライアントコンピュータにより開始された第１のトランザクションに属する第１のメッセージの、第１のファイルプロトコルヘッダを含む第１のフレームを受信する段階と、第１のファイルプロトコルヘッダ内の情報に基づいて、第１のトランザクションの処理に参加するために第１の組のファイルサーバを選択する段階と、修正された第１のファイルプロトコルヘッダを含む第２のフレームを第１の組のファイルサーバの第１のサーバに送る段階と、修正された第１のファイルプロトコルヘッダを含む第３のフレームを第１の組のファイルサーバの第２のサーバに送る段階とを含む。
【００６０】
本発明の更に別の態様は、ネットワークファイルプロトコル・トランザクションを切り替えて統合することによりファイルシステムを統合する方法である。
【００６１】
本発明の別の態様は、ファイルシステムを統合する方法であって、本方法は、複数のファイルシステムのネームスペースを統合して単一ネームスペースとして呈示する段階と、複数のファイルシステムのディレクトリを単一ディレクトリとして呈示することにより統合する段階と、複数のファイルシステムのファイルオブジェクトを単一ファイルオブジェクトとして呈示することにより統合する段階と、複数のファイルシステム内のファイルのファイルデータを単一ファイルのデータとして呈示することにより統合する段階とを含む。
【００６２】
本発明の更に別の態様は、ネットワーク・ストレージ・システムにファイルを記憶する方法であって、本方法は、複数のファイルシステムのネームスペースを統合して単一ネームスペースとして呈示する段階と、複数のファイルシステムのディレクトリを単一ディレクトリとして呈示することにより統合する段階と、複数のファイルシステムのファイルオブジェクトを単一ファイルオブジェクトとして呈示することにより統合する段階と、複数のファイルシステム内のファイルのファイルデータを単一ファイルのデータとして呈示することにより統合する段階とを含む。
【００６３】
本発明の別の態様は、クライアント／サーバ・プロトコルを切り替えるスイッチを拡張する方法であって、本方法は、サーバに対してクライアントとして見えるようにスイッチを実施する段階と、クライアントに対してサーバとして見えるようにスイッチを実施する段階と、スイッチ間で調停するために複数のクライアント間で調停するサーバの能力を用いる段階とを含む。
【００６４】
本発明の更に別の態様は、複数の同時クライアントからの要求を調停するサーバの能力を提供するクライアント／サーバ・ネットワークプロトコルに基づいて機能する、ネットワークプロトコルのクライアント側を実施するクライアントとネットワークプロトコルのサーバ側を実施するサーバとを備えたストレージネットワークを拡張する方法であって、本方法は、各々がクライアントと通信する時はネットワークプロトコルのサーバ側を提供し、サーバと対話する時はネットワークプロトコルのクライアント側を提供する複数のスイッチをクライアントとサーバとの間に挿入する段階と、スイッチ間で調停するために複数の同時クライアント間で調停するサーバの能力を用いる段階とを含む。
【００６５】
本発明の更に別の態様は、複数のクライアントコンピュータと複数のサーバコンピュータとを含むコンピュータネットワークにおけるファイルを切り替えて統合する装置であって、本装置は、複数のクライアントコンピュータのうちの少なくとも１つと、複数のサーバコンピュータの少なくとも１つとの間で相互接続され、ファイルスイッチコンピュータは、データとファイルプロトコルヘッダとを第１のメッセージフレームに含むメッセージを受信し、ファイルプロトコルヘッダに基づき、かつメッセージデータから独立した方法で、少なくとも１つのネットワークノードのうちのどれにメッセージを転送すべきか判断し、判断に基づく方法で、修正されたファイルプロトコルヘッダを導出し、修正されたファイルプロトコルヘッダとメッセージデータとを転送する。代替的に、複数の同時メッセージが前記ファイルスイッチコンピュータにより受信された時、この同時メッセージの１つのみが、成功した要求となることができる。
【００６６】
本発明の別の態様は、複数のクライアントコンピュータと複数のサーバコンピュータとを含むコンピュータネットワークにおけるファイルを切り替えて統合する装置であって、本装置は、少なくとも１つのクライアントコンピュータと、少なくとも１つのサーバコンピュータとの間でファイル切替及びファイル統合の機能性を提供し、その少なくとも１つのサーバコンピュータに対してはクライアントコンピュータとして、その少なくとも１つのクライアントコンピュータに対してはサーバコンピュータとして見える。
【００６７】
本発明の別の態様は、ネットワーク化されたファイルデータを取り扱うための交換ファイルシステムであって、本システムは、複数のクライアントコンピュータと、複数のサーバコンピュータと、ファイルメッセージをクライアントコンピュータから複数のサーバコンピュータに切り替えることができる少なくとも１つのファイルスイッチとを含む。
【００６８】
本発明の更に別の態様は、ネットワーク化されたファイルデータを取り扱うための交換ファイルシステムであって、本システムは、複数のクライアントコンピュータと、複数のサーバコンピュータと、ファイルメッセージを複数のサーバからクライアントコンピュータに統合することができる少なくとも１つのファイルスイッチとを含む。
【００６９】
本発明の別の態様は、複数のサーバと、ファイルスイッチと、複数のクライアントとを含むコンピュータネットワークにおいて、処理に従って複数のサーバ間で作成かつ維持されたファイルディレクトリであり、本ファイルディレクトリは、ファイル・プロトコル・メッセージをクライアントから受信する第１のファイルスイッチを含み、該メッセージは、メッセージの第１のパケットにファイルヘッダを含み、該第１のファイルスイッチは、ファイルヘッダを分析し、複数のメッセージ取り扱い規則に従って、メッセージを複数のサーバ間で分割する方法を判断する。代替的に、ネットワークは、複数のスイッチを更に含むことができ、メッセージ取り扱い規則は、第２のファイルスイッチにより共用することができるか、又は、複数のメッセージ取り扱い規則は、少なくとも１つのファイルサーバから受信したファイルメッセージを通じて前記第１及び第２のファイルスイッチにおいて更新することができる。
【００７０】
本発明の更に別の態様は、ネットワーク使用データを供給する装置であって、本装置は、複数のクライアントコンピュータと複数のサーバコンピュータとを含むコンピュータネットワークにおいて、クライアントコンピュータとサーバコンピュータとの間でファイルメッセージを切り替えながら使用データを収集する、クライアントコンピュータとサーバコンピュータとの間でファイルを統合するための装置を含む。代替的に、ファイルを統合するための複数の規則は、使用データから引き出することができるか、又は、装置が、ファイルを統合するための複数の規則を含むことができ、複数の規則の少なくとも１つの変更は、使用データから引き出すことができる。更に代替的には、この少なくとも１つの変更は、ネットワーク内の第２の統合装置に反映させることができる。
【００７１】
本発明の別の態様は、各々が複数の規則に従ってファイルを統合する複数のファイルアグリゲータを含むネットワークにおいて、複数のファイルアグリゲータ内で規則を変更する方法であって、本方法は、規則の変更を残りの複数のファイルアグリゲータに転送する第１のアグリゲータにおいて規則を変更する段階と、残りの複数のファイルアグリゲータにおいて規則を更新する段階とを含む。
【００７２】
本発明の更に別の態様は、サーバとクライアントとを含む複数のネットワーク参加者を有してファイルトランザクションがネットワーク参加者間で流れるようなコンピュータネットワークにおける、複数のネットワーク参加者間で単一トランザクションの切替及び統合をもたらす装置である。
【００７３】
本発明の更に別の態様は、ヘッダを有するトランザクションを交換する複数のネットワークノードを備えたコンピュータネットワークにおける、トランザクションヘッダ内に含まれた情報に基づく方法で他のネットワークノード間でファイルプロトコル・トランザクションを切り替えるネットワークノードである。
【００７４】
本発明の更に別の態様は、ネットワークプロトコル・トランザクションを統合するための手段を備えた、ネットワーク内の複数のサーバを統合するための装置である。
【００７５】
本発明の更に別の態様は、ネットワークファイルを切り替えるための手段を備えた、ネットワーククライアントを複数のネットワークサーバに接続するための装置である。
【００７６】
更に、本発明のシステムの特徴及びレイアウトの有利な組み合わせが、以下のように与えられる。すなわち、全てがネットワーク内の単一サーバ名の下で特定された複数のファイルスイッチを含むアーキテクチャ、名称分解機構及びグループコントローラ機構の組み合わせを通じて負荷平衡を行う方法及びシステム、名称分解機構及びグループコントローラ機構の組み合わせを通じてネットワーク機能フェイルオーバーを行う方法及びシステム、ファイルスイッチと複数のファイルサーバとを備えたネットワークファイルシステム、ファイルスイッチが同期機構及びファイルサーバにより供給されたプロトコルのみを使用してファイルサーバへのアクセスを同期化する、複数のファイルスイッチと複数のファイルサーバとを備えたシステム、スイッチがクライアント又はサーバのいずれかに対してキャッシュ機能を提供する交換ファイルシステム、メンバークライアント及びサーバが機能する上で市販ソフトウエアのみが必要とされる、ネットワーク内の交換ファイルシステム、単一ファイルサーバとして管理された交換ファイルシステム、容量及び帯域幅を独立して拡張することができる交換ファイルシステム、及び、便宜的ロック機能性を提供し、ファイルのローカルコピーをゲートウェイトポロジーにおけるキャッシュとして維持する間ファイルをオープン状態に保つ方法及びシステムである。
【００７７】
本発明の更に他の有利な用途には、請求書作成及びサービス品質（ＱｏＳ）のような使用追跡機能性、適応ストレージ管理、暗号化及び安全な公衆ストレージ用途を可能にする安全な遠隔ストレージ、トリプルミラー及びオンラインスナップショットのような高度なストレージ能力、バックアップウィンドウ及び確実な段階的故障復帰が不要なジャーナル処理バックアップ、及び、廉価なグローバルストレージが含まれる。
【００７８】
本発明の上述の特徴及び利点、及び、更に別の特徴及び利点は、以下の図面に関連した本発明の好ましい実施形態の以下の詳細説明の結果、更に明確に理解されるであろう。
【発明を実施するための最良の形態】
【００７９】
以下の説明は、本発明が関係する技術分野の当業者が本発明を製造して使用することができるように提供され、本発明を実施するために本発明者が現在想定する最良の態様を示している。しかし、ファイルスイッチ、交換ファイルシステム、及び、その作動機構を提供するために本発明の基本原理が具体的に本明細書で定められたので、様々な変更が当業者には容易に明らかであろう。そのような変更のいずれか又は全て、均等物、及び、代替物は、本発明の精神及び範囲に含まれるように意図されている。
【００８０】
はじめに
従来技術の説明において、拡張可能性及び管理容易性を厳しく制限する利用可能なシステムに関する３つの大きな問題を特定した。これら３つの問題の全ての発生源は、例外なく、利用可能なシステムがクライアント／サーバアーキテクチャに基づくものであるという事実に到達することができる。トポロジーの違いにも拘わらず、これらのシステムの全てにおいて、クライアントは、実際のファイルアクセス時にはサーバと直接対話する。その結果、利用可能なシステムにより必要とされるいかなる特化された機能性も、クライアント側又はサーバ側で実行されなければならない。大部分のシステムにおいては、このために、結果的にシステムのクライアント側及びサーバ側の両方で独自仕様のソフトウエアが必要とされ、数多くの保守及び導入上の問題が引き起こされている。
【００８１】
更に、利用可能なシステムは、多くのクライアント及び多くのサーバを含むので、システムには、それらの間での対話を調停するために、具体的にはメタデータ、ディレクトリ、及び、ロッキングを処理する際に特別な機能性が必要である。このような機能性は、最終的には、個別のサーバに搭載されるか、又は、クラスター化の場合によくあるように、サーバのグループ間の固い結合が必要とされ、いずれの場合にも、アービトレーションが大きな障害になってシステムの拡張可能性を制限する。
【００８２】
本発明は、これまでのクライアント／サーバモデルではなくて、３層のアーキテクチャを実施することにより上述の問題の全てを排除するものである。本明細書で交換ファイルシステムと呼ぶこのアーキテクチャにおいては、ネットワーク・ファイル・クライアントとネットワーク・ファイル・サーバとの間のシステム内に、ファイルスイッチと呼ぶ中間ノードが導入される。
【００８３】
システムへのファイルスイッチの導入により、クライアントとサーバを分離することができ、その結果、クライアント及びサーバ間の１対１の関係が排除される。その結果、クライアントは、もはや、所定のファイルを処理する特定のサーバがどれか、又は、ファイルが単一サーバにより取り扱われるのか又は複数のサーバ間で配分されるのかさえも意識していない。これは、アーキテクチャ及びシステムの能力に大きな影響を及ぼす。
【００８４】
第１に、このアーキテクチャにより、クライアントにはガラス張りの方法で複数のサーバのストレージ容量を統合することができる。第２に、これらのサーバ間でのファイルの配分、及び、並行して行うことができる複数のサーバ上への個々のファイルのストライピングの両方を行うことにより、これらのサーバの性能を統合することができる。第３に、個々のファイルを複数のサーバ上に同時に映し出すことができ、その結果、データの利用可能性が高まり、ここでもまた、クライアントにはガラス張りのものとなる。第４に、システム内のファイルサーバを効果的に単一仮想ネットワーク・ファイル・システムに統合することにより、ファイルスイッチは、システム全体の管理を単一ファイルサーバができるのとほぼ同じくらい簡単に管理することができる程度まで大幅に簡素化する。
【００８５】
更に、交換ファイルシステムでは、クライアントは、ファイル、ディレクトリ、及び、データがファイルサーバ間で配分される特定の処理から実質的に隔離されていることから、交換ファイルシステムが作動中にいつでもその処理を変更することが可能である。これは、ストレージ、性能、及び、アクセスを最適化するために使用パターンを追跡してデータ配分を調節することができる、適応自己調節ネットワークファイルシステムを構築する基盤を成すことから極めて重要である。
【００８６】
最後に、ファイルスイッチは、クライアント及びサーバ上で既にサポートされている標準的なネットワークファイル及び他のプロトコルで作動することができる。このことは、商業レベルのシステムにおいて種々の大きな実際的な利点を有し、広範囲の既に利用可能なファイルサーバ、「ＮＡＳ」装置、及び、クライアントを使用して、次世代の非常に拡張可能で有効性があり管理が容易なファイルシステムを構築することができる。
【００８７】
ファイルスイッチ
ファイルスイッチは、少なくとも１つのネットワークインタフェース、及び、少なくとも１つのＣＰＵ及びメモリを有する計算装置である。ファイルスイッチのハードウエアアーキテクチャは、最小限の待ち時間で大容量のネットワークトラヒックを処理する上で最適化されることが好ましい。このスイッチは、ギガビット又はそれ以上の「イーサネット」インタフェースのような複数の高速ネットワークインタフェースを装備していることが好ましい。
【００８８】
大部分の普及しているネットワークファイルプロトコルが「ＩＰ」規格に基づくものであることから、ファイルスイッチは、「ＴＣＰ」及び「ＵＤＰ  ＩＰ」ネットワークプロトコル、及び、適切な場合には、「ＩＰ」スタック（例えば、ＡＲＰ）の他のプロトコルをサポートすることが好ましい。ファイルスイッチは、「ＮＦＳ」及び「ＣＩＦＳ」のような複数の業界標準ネットワークファイルプロトコルをサポートすることが好ましい。
【００８９】
図１は、ファイルスイッチを含む本発明のネットワーク構成を示す。この構成では、ファイルスイッチ１００は、２つの異なるネットワークインタフェース、つまり、接続１０９を通じてクライアントネットワーク１１１に接続するためのネットワークインタフェースと、接続１１０及び１１４、及び、図示する他の類似の接続を通じてファイル・サーバ・ネットワークに接続するためのネットワークインタフェースとで実行される。簡素化するために、ファイルスイッチは、ファイルサーバ１０１〜１０７の各々に直接接続された状態で図示されている。実際は、１つ又はそれ以上の一般的に利用可能な層２スイッチがこれらの接続を実施するために使用されることが好ましい。
【００９０】
ＰＣ又はワークステーション１１２のようなクライアント及びアプリケーションサーバ１１３は、「ＮＦＳ」又は「ＣＩＦＳ」プロトコルを使用してファイルスイッチ１００と通信することによりファイルサービスを要求する。スイッチ１００は、接続１０９上の適切なネットワークファイルプロトコルのサーバ側を実施することが好ましい。このスイッチは、更に、好ましくは同じネットワークファイルプロトコルのクライアント側を実施することにより、ファイルサーバ１０１〜１０７と対話する。従って、ファイルスイッチ１００の存在は、その結果、クライアント及びサーバの両方にガラス張りの状態であることが好ましい。
【００９１】
更に、ファイルスイッチは、ファイルサーバ１０１〜１０７の発見及び設定、スイッチの自己設定、及び、本明細書で説明する他の目的のために、クライアントとして又はサーバとして、「ＤＨＣＰ」、「ＤＮＳ」、又は、「ＷＩＮＳ」のような他の「ＩＰ」プロトコルを実施してもよい。
【００９２】
ファイルスイッチが、クライアント側１０９とサーバ側１１０及び１１４との両方で業界標準プロトコルを実施するということにより、ファイルサーバ１０１〜１０７が標準的な市販のファイルサーバつまり「ＮＡＳ」装置であり、クライアント１１２及び１１３が標準的な市販コンピュータであるような環境において機能することができる。このようにして、他の任意のネットワークノード上でインストール及び維持されなければならないいかなる独自仕様のソフトウエアをも必要とすることなく、ファイルスイッチの利点を利用することができる。
【００９３】
ファイルスイッチの主な機能性は、３つの大きな部類、すなわち、トランザクション処理（トランザクション切替及びトランザクション統合を含む）、ファイルシステム統合（ファイルシステムオブジェクト及びファイルデータの統合を含む）、及び、複数のファイルスイッチを互いに結合するための様々な機構（負荷平衡、設定共用、フェイルオーバー、及び、管理統合）を含むスイッチ統合に分けることができる。
【００９４】
ファイルスイッチの機能性は、ソフトウエア、ハードウエア、又は、適切な場合には、ソフトウエア及びハードウエアの任意の組合せで実施することができる。
【００９５】
トランザクション処理
ファイルスイッチの一般的な作動は、ログイン、ツリー接続／マウント、ファイルオープン、及び、ファイル読取り／書込みなどのようなファイルプロトコル要求をクライアント１１２及び１１３から受信すること、及び、ファイルサーバ１０１〜１０７のうちの１つ又はそれ以上にこれらの要求を転送する又は切り換えることを伴う。
【００９６】
ネットワークファイルプロトコルは、一般的に、トランザクションに基づいている。図２は、ネットワークファイルプロトコル内の一般的なファイル書込トランザクションを示す。トランザクション２０８は、２つのメッセージ、つまり書込要求２０５及び書込応答２０６から成る。書込要求２０５は、多重ネットワークフレーム２０１〜２０４から成り、ヘッダがファイル処理やオフセットなどのような要求の様々なパラメータを指定する第１のネットワークフレーム２０１の始めに位置するヘッダ２００と、ファイルに書き込まれることになる、ペイロードとよく言われるユーザデータとを含む。本発明の例では、ペイロードは、多重フレーム２０１〜２０４に及んでいる。
【００９７】
トランザクション２０８は、一般的に以下のように進行する。クライアントは、「ＴＣＰ」のようなプロトコルを通じてサーバに接続され、その接続を使用してプロトコルヘッダ２００及びペイロードを送ることにより要求２０５を発行する。「ＴＣＰ」プロトコルスタックは、要求を多重ネットワークフレーム２０１〜２０４に分割し、それらの各々をアドレス情報でプレフィックス変換してサーバに順次送信する。
【００９８】
サーバ上の「ＴＣＰ」プロトコルスタックは、フレーム２０１〜２０４が到着する度にそれらを受け取る。サーバは、メッセージ２０５全体を受信するまで待機した後に、ヘッダ２００のコンテンツを解釈し、データペイロードを適正なファイルに書き込むことにより、この場合はファイル書込みである要求された作業を実行する。完了すると、サーバは、要求された作業の結果を示す応答ヘッダ２０７を形成し、クライアントに送信するためにローカル「ＴＣＰ」プロトコルスタックに提出する。これに応答して、「ＴＣＰ」プロトコルスタックは、ヘッダ２０７を含むネットワークフレーム２０６を形成してクライアントに送る。クライアントは、ヘッダ２０７を受信するとトランザクションの結果を検査する。トランザクションは、これで完了となる。
【００９９】
メッセージ切替
利用可能なファイルサーバと異なり、本発明のファイルスイッチは、大部分のファイルプロトコル・トランザクションに関して中間ノードである。これは、スイッチは、内部的にはそれらのトランザクションを取り扱わないが、その代わりに、２０５のような要求を検査し、任意選択的に２００のような要求ヘッダを修正し、メッセージをファイルサーバに転送することを意味する。このために、好ましくは、ファイルスイッチは、サーバにメッセージを転送する前に、２０５のようなメッセージの全てのフレームを受信するまで待機しない。これにより、ファイルスイッチは、２０８のような多重フレームファイルプロトコル・トランザクションに容認できない待ち時間を導入することを回避することができる。
【０１００】
図３は、ファイルスイッチが、書込要求２０５のような多重フレームトランザクションメッセージを処理する様子を示す。要求ヘッダ２００を含む第１のフレーム２０１を受信すると、スイッチ１００は、このフレームが新しいメッセージの始まりを示すと認識し、ヘッダ２００を検査してメッセージ全体をファイルサーバのいずれに転送すべきかを判断する。次に、ファイルスイッチは、ヘッダ２００を目標ファイルサーバにより予期されるような修正された要求情報を含む新しいヘッダ３００と入れ換えて、ヘッダ３００を有するフレーム２０１を選択されたファイルサーバに転送する。
【０１０１】
メッセージ２０５からの残りのフレーム２０２〜２０４は、引き続き、１つずつスイッチに到着する。２０３のような各フレームが到着すると、スイッチは、このフレームがメッセージ２０５に属することを認識し、フレーム２０１を処理中に行った判断を用いてそれを転送する。転送する処理では、適切なアドレス及び他の情報を有するフレームと共に移動する低レベルプロトコルヘッダを修正することを必要とする場合がある。
【０１０２】
スイッチの仕事の大半は、転送の判断を行うことに関係し、第１フレーム２０１が受信された時にメッセージ当たり一度だけ発生するので、メッセージの残りのフレームは、ワイヤスピードで、かつ、ファイルサーバが以前のフレームを受信するのと同時に容易に処理することができ、その結果、大きな待ち時間が回避される。
【０１０３】
トランザクション切替
図４は、ファイルスイッチが完全なファイルプロトコル・トランザクションを図１に示す環境内で切り替える好ましい方法を示す。クライアント（図示せず）は、好ましくは「ＴＣＰ」を通じてファイルスイッチ１００に接続され、実際に、ファイルスイッチ１００をファイルサーバと見ている。クライアントは、ファイルスイッチにアドレス指定された書込要求２０５を発行することにより、書込トランザクションを開始する。このメッセージの第１フレーム２０１を受信すると、ファイルスイッチは、要求を識別する全情報、付随するファイルハンドル、及び、ペイロード以外の要求の他の全パラメータを有する。
【０１０４】
この時点で、スイッチは、どのファイルサーバが適切なファイルを有し、従ってクライアントの要求を処理すべきかを判断する状態にある。本発明の例においては、スイッチは、接続１１４（図示せず）の右側のファイルサーバが適正なファイルサーバであると判断する。スイッチは、以前にそのファイルサーバとの接続を確立しており、実際に、サーバは、このスイッチが本物のクライアントであると考える。ここで、スイッチは、ファイルサーバが失敗せずに要求を実行することができるように、要求のパラメータを修正する方法を判断する。次に、スイッチは、本明細書で説明するように残りのトランザクションを処理するのに十分な方法でその状態を更新し、修正されたヘッダ３００を有するフレーム２０１を接続１１４を通じてファイルサーバに転送して、上述したように残りの要求メッセージの切り替えに向う。
【０１０５】
完全な要求２０５を受信すると、ファイルサーバは、接続１０９を通じて接続されたクライアントがファイルスイッチから本来要求されたアクションを実行し、応答ヘッダ４００を含むトランザクション応答２０６を形成して、その応答をファイルサーバが要求２０５の発信者であると考えているファイルスイッチ１００に返送する。
【０１０６】
ファイルスイッチは、トランザクション応答２０６を受信すると、それが以前に切り替えられた要求２０５と同じトランザクションに属すると認識する。次に、スイッチは、トランザクション応答ヘッダ４００を検査し、接続１０９上のクライアントが修正された結果を本来の要求２０５に対する有効な応答として受け入れるように、そのヘッダを修正する方法を判断する。
【０１０７】
最後に、スイッチは、修正されたヘッダ２０７を有する修正された応答２０６を本来のクライアントに送信する。クライアントは、その応答を受信すると、スイッチ１００が要求されたファイルシステム作業を実行することによりクライアントのために要求２０５に対応したと考える。
【０１０８】
本明細書で説明する機構により、ファイルスイッチは、クライアントに対してガラス張りな方法でその機構に接続されたファイルサーバのうちの１つ又はそれ以上にファイルプロトコル・トランザクションを任せることができる。この本発明の機構の限界は、スイッチが同じクライアントから来る異なるトランザクションを異なるファイルサーバに向けることができるが、個々のトランザクションの各々は、単一ファイルサーバにしか任せることができないということである。
【０１０９】
トランザクション統合
図５は、ファイルスイッチがクライアントから受信した単一トランザクションを１つよりも多いファイルサーバに任せ、従って、そのトランザクションを処理する際にそれらのサーバの挙動を統合し、単一ファイルサーバの挙動の結果として本来のクライアントに呈示することができる好ましい処理を示す。
【０１１０】
接続１１４を通じてスイッチに接続されたファイルサーバ１０１と、接続１１０を通じてスイッチに接続されたファイルサーバ１０７とに並行して要求を処理させることによりクライアントにより高い統合性能を供給するために、スイッチ１００がこれら２つのファイルサーバの間でファイルのデータをストライピングする場合を考える。
【０１１１】
図４の例のように、クライアントは、接続１０９を通じてスイッチ１００に接続され、好ましくは、スイッチに対する「ＴＣＰ」接続を既に確立しており、そのスイッチをファイルサーバであると考えている。従って、クライアントは、書込要求２０５をスイッチに発行することにより、ファイル書込トランザクションを開始する。先の例のように、スイッチは、メッセージ２０５の第１フレーム２０１を受信すると、そのトランザクションを処理する方法を判断する状態にある。
【０１１２】
先の例と異なり、スイッチは、２つの個別のファイルサーバ（図２３の１０１及び１０７など）を目標とした２つのトランザクションに分割することにより、トランザクションを処理する。要求ヘッダ２００を検査すると、スイッチは、目的を達成するのに十分な方法でその状態を更新し、ヘッダ２００を修正されたヘッダ５００と入れ換えてフレーム２０１をファイルサーバ１０１に転送する。フレーム２０２を受信すると、スイッチは、そのフレームを同じサーバ１０１に転送し、本来のクライアント要求２０５のデータペイロードの一部分のみを持つ新しい要求５０１をそのサーバに対して実質的に作成する。
【０１１３】
次のフレーム２０３を受信すると、スイッチは、新しい要求ヘッダ５０４を形成してフレーム２０３に挿入し、そのフレームをファイルサーバ１０７に転送する。本来の要求２０４の最終フレームを受信すると、スイッチは、それをファイルサーバ１０７にも転送し、本来のクライアント要求２０５のデータペイロードの残りを持つ新しい要求５０５をそのサーバに対して実質的に作成する。
【０１１４】
２つのファイルサーバ１０１及び１０７は、この時点で別々のファイル書込要求を受信しており、その各々は、その適切なファイルに対するものであり、書き込まれるデータの適切な部分を有する。サーバは、この時点で要求された書込み作業を並行して実行し、それぞれの応答５０２及び５０６を、サーバが要求５０１及び５０５の発信者と考えているスイッチに提出する。本発明の処理では、サーバ１０１及び１０７が互いに対話したり、又は、相手の存在を意識することさえも決して要求されないことに注意すべきである。
【０１１５】
ファイルサーバ１０１及び１０７からそれぞれ要求５０２及び５０６を受信すると、ファイルスイッチ１０１は、スイッチが提出した両方の書込要求の結果を知っており、従って、そのトランザクションの統合結果を含む応答２０６を本来のクライアントに対して形成する状態にある。スイッチは、ヘッダ２０６及び２０７に含まれたデータを使用して応答ヘッダ２０７を形成し、ヘッダ２０７をフレーム２０６内の本来のクライアントに送ることによりこれを達成する。クライアントは、その本来の要求２０５の結果を含む応答２０６を受信する。この時点でトランザクションは完了する。
【０１１６】
上述の機構により、２つの革新的な結果が可能になる。第１に、ファイルスイッチは、異なるファイルサーバ上にあるファイル又はディレクトリのような一組のファイルシステムのエンティティーを統合し、この組をクライアントに単一の密接したエンティティーとして呈示することができ、その結果、完全なファイルシステムを統合するための基盤が形成される。
【０１１７】
第２に、この機構により、スイッチは、要求された作業を並行して実行することができる複数のファイルサーバ間で、個々の読取り及び書込みネットワークファイル・トランザクションを分割又は複製することができる。このようにして、本発明は、各クライアントが利用可能な個々のファイルサーバの性能よりも何倍も高い統合性能を各クライアントに供給する能力と共に、ファイルスイッチ及びファイルサーバを含むネットワーク上にパラレルファイルシステムの均等物を形成する基盤を設定する。
【０１１８】
本発明が関係する当業者は、本明細書で説明する機構の作動はまた、２０２のようなヘッダが追加されるネットワークフレームを、各々がデータの一部分を持つ多重フレームに分割することが有利であり得ることを要求する場合があることを容易に認識するであろう。このようなフレーム分割、接合、及び、他の再組立は、ファイルスイッチの最適な作動を得るために他の場所では必要とされる場合があるが、本発明の作動の論理を決して変更するものではない。
【０１１９】
ヘッダの導出は、以下のいずれかを含むことができることに注意すべきである。すなわち、ヘッダ内の経路又はファイル名を修正する段階、他方の側が予期する識別情報を見出すように（ファイルスイッチは、クライアントに１つのファイルハンドルを与え、同時に複数の異なるハンドルをメンバーファイル毎に１つ受信することになる）、接続ＩＤ又はファイルハンドル（それぞれ、「ＣＩＦＳ」プロトコルにおいて定義されるような「ＴＩＤ」及び「ＦＩＤ」フィールド）のような識別情報を変更する段階、及び、ペイロードの長さを変更する段階（例えば、ストライピングの時、ペイロードの一部分は１つのサーバに行き、残りは別のサーバに行くことができ、従って、スイッチは、それがそれぞれの部分のみの読取り／書込みを行うことになることをサーバの各々に知らせる必要があることになる）である。
【０１２０】
更に、２つのフレームが統合された場合、ヘッダの導出は、更に以下を伴う場合がある。すなわち、応答したサーバの各々により読み込まれた／書き込まれたバイト数を合計して、その和をクライアントに返送する段階（スイッチは、サーバから受信した全てのデータを送ることになるため）、状態を統合する段階（この技術は、同時処理及びデータ無しトランザクションでも使用することができる、本明細書の他の場所で説明）、及び、サーバの各々により戻された状態に基づく方法でファイルスイッチがクライアントに送る必要がある状態を判断する段階である。
【０１２１】
ネットワーク・ファイル・システムの統合
ファイルスイッチの１つの目的は、従来のサーバにより行われるファイル・システム・サービスを統合して、利用可能性が個々のファイルサーバの各々よりも何倍も高い単一で大規模の非常に高性能なネットワーク・ファイル・システムとしてネットワーククライアントに呈示することである。
【０１２２】
この目的を達成するために、ファイルスイッチは、スイッチに接続されたクライアントがその作動を単一ネットワーク・ファイル・サーバの作動と区別することはできないような方法で、１つ又はそれ以上のネットワークファイルプロトコルの全ての作業を統合することが好ましい。これには、スイッチが、一般的なネットワークファイルプロトコル、特に、ファイルシステムネームスペース、ディレクトリ、ファイルオブジェクト、及び、ファイル内に含まれたデータにより露出された全てのエンティティーを統合することが必要である。
【０１２３】
規則に基づく統合
ファイルスイッチがファイルシステム統合を達成するために使用する種々の機構は、スイッチ上に規定された一組の規則及びポリシーで推進させることができるように実施されることが好ましい。
【０１２４】
規則に基づく統合を望ましいものにする幾つかの理由がある。第１に、ストレージ管理者は、異なる組及び／又は形式のファイルに対して異なる統合方法を指定することができ、その結果、システムの特性が、異なるデータに対して意図された使用及び特定のアクセスパターンに調節される。第２に、ファイルスイッチは、通常の作動中に外部装置を調べる必要性を排除することにより、より決定論的タイミングで作動することができる。
【０１２５】
更に、規則に基づく作動により、複数のファイルスイッチは、変更があった場合にその組の規則及びポリシーを同期させるために以外にはスイッチが互いに対話する必要もなく、統合されて同じ組のサーバの前に置くことができる。同じ組のファイルサーバを統合するスイッチ間のこの緩い結合により、必要な時にはいつでもスイッチを単に追加することによって桁違いの大きさにアクセス帯域幅を拡張することができる。
【０１２６】
最後に、ファイルスイッチは、内部的に使用パターンを追跡する絶好の状態にあるので、システム管理者により指定されたポリシー及び観察された使用パターンに従って自動的に統合規則を調節することができる。その結果、ファイルスイッチは、全体としてネットワーク・ストレージ・システムの円滑かつ適応する挙動を達成するために、ファイルスイッチが統合するサーバ間で大きなゆとりをもってファイル及びデータの配分を最適化することができる。
【０１２７】
ネームスペース統合
本発明のファイルスイッチは、共通のファイルシステムネームスペースの下で複数のファイルサーバを統合するように構成することができる。
【０１２８】
図６は、本発明のファイルスイッチによる規則に基づくネームスペース統合を示す。ネームスペース統合の規則は、経路対応の表として規定されることが好ましい。第１のコラムは、クライアントが見ることができる名称を指定し、第２のコラムは、サーバの名称及び任意選択的にファイルが実際にあるそのサーバ上のシェア又はマウントポイントを指定する。ファイルスイッチ１００は、３つのファイルサーバ６０８、６０９、及び、６１０に接続されている。ファイルスイッチ内に搭載されている（又は、そうでなければ、ファイルスイッチがアクセス可能な）ものは、３つの規則６０５、６０６、及び、６０７を指定する規則表６０４である。ネットワーククライアントにより開始されたファイルオープンのような着信ファイル要求の経路名６０１、６０２、及び、６０３は、第１コラムの名称マッピング規則と比較される（この比較は、重なり合う経路名を特定することができるように、最長の符合プレフィックスに対して最初に行われることが好ましい）。符合部分があった場合には、ファイル基本経路の符合部分が第２コラムの名称と置き換えられて、要求は、処理のために新しい経路に転送される。ファイルが目標サーバ上で開かれると、このファイルに関係する全ての更なるトランザクションは、そのサーバに切り替えられる。
【０１２９】
例えば、規則６０５は、共通ネームスペースの「＼ＥＮＧ」サブツリーがサーバ６０８にマッピングされるように指定する。ファイル６０１は、この規則に適合しており、従って、それが修正された経路で到着するサーバ６０８に切り換えられることになる。しかし、規則６０６は、「＼ＥＮＧ」サブツリー内のサブツリー、すなわち、「＼ＥＮＧ＼ＳＷ」が異なるサーバ、つまりサーバ６０９にマッピングされるように指定する。ファイル６０２は、この規則を満足し、従って、サーバ６０９に切り替えられ、修正された経路でファイルがそのサーバに到着する。更に、規則６０７は、「＼ＡＣＣＴ」サブツリーがサーバ６１０にマッピングされるように指定する。この規則は、たとえこのファイルが「＼ＡＣＣＴ」サブツリーのサブディレクトリ内にあったとしても、ファイル６０３の切り換えを推進することになる（プレフィックス符合のために）。
【０１３０】
基本経路に加えて、他のネームスペースマッピング規則が考慮される。例えば、規則は、所定の拡張を伴う（及び、任意選択的に所定のサブツリーの下での）全てのファイル特定のサーバに切り替えられるように指定することができる。例えば、規則（＊．ｍｐｅｇ--＞＼＼ｓｒｖ３＼ｄｉｒ６）により、全ての「ＭＰＥＧ」ファイルは、これらのファイルが論理ネームスペースのどこにあろうと、サーバ６１０上のサブディレクトリ「ｄｉｒ６」に送られる。
【０１３１】
尚、マッピングは、ファイルスイッチ上で構成されかつ実行される。クライアントは、マッピングを知る必要はなく、実際には知るすべがなく、マッピングが変更された場合に再構成される必要はない。
複数のファイルサーバのネームスペースを共通のネームスペースに統合することにより、ファイルスイッチは、いかなる独自仕様のクライアント側ソフトウエアを必要とすることもなく、利用可能な分散ファイルシステムが行う内容と類似の機能を達成する。
【０１３２】
ディレクトリ統合
先の節で上述したネームスペース統合は、ファイルを異なるサーバ間で配分し、新しいサーバを既存のシステムに追加する簡単な方法である。しかし、この技術だけでは、複数のファイルサーバのストレージ容量を滑らかに統合するには不十分である場合がある。例えば、ネームスペース統合だけでは、統合されたファイルシステム上でどれだけの空きディスクスペースがあるのか知ることができないであろう。
【０１３３】
ディレクトリが異なればマッピング先のサーバも異なることから、余裕不足のために「＼ＥＮＧ」サブツリーで記憶することができない恐れがあるファイルは、異なるサーバにある「＼ＥＮＧ＼ＳＷ」サブツリーで問題なく記憶することができる。従って、全体としてのシステムが多くの利用可能なストレージスペースを有する時でさえも、ネームスペース内の特定場所の特定のファイル操作は、大規模な人手の介入がなければ問題なく実行することはできないであろう。
【０１３４】
ディレクトリ統合は、同じ統合されたディレクトリ内にあるファイルを異なるサーバ間で配分することを可能にすることにより上述の問題を解決する。これにより、結合されたネームスペースの全てのディレクトリのファイルは、確実に利用可能な空きディスクスペースの全てを共用することができる。
【０１３５】
図７は、ファイルスイッチによるディレクトリ統合を示す。スイッチ１００は、３つのファイルサーバ７０４、７０５、及び、７０６に接続されており、それらのサーバ上でディレクトリを統合するように構成される。新しいファイルを作成するトランザクションがクライアントにより開始された時、スイッチは、どのサーバが特定のファイルを作成するべきかを判断し、そのトランザクション及びこのファイルに関係する他の全てのファイルをそのサーバに切り替える。既存のファイルを開く要求がクライアントにより開始された時は常に、スイッチは、そのファイルがどのサーバ上にあるかを判断し、そのトランザクション及びこのファイルに関係する他の全てのトランザクションを適切なサーバに切り替える。本発明の例では、ファイル７０１は、最終的にサーバ７０４上にあり、ファイル７０１と同じディレクトリ「ＥＮＧ」内にあるファイル７０２は、最終的にサーバ７０５上にあり、やはり同じディレクトリ内にあるファイル７０３は、最終的にサーバ７０６上にある。
【０１３６】
上述のディレクトリ統合では、この機構が作動するディレクトリが全てのサーバ上にあると仮定している。これを確実に行う１つの方法は、そのサーバ上の所定のディレクトリ内でファイルを作成する第１の要求を受信した時は常にファイルスイッチに中間的なディレクトリを作成させることであり、これと同じ結果を保証する別の方法は、スイッチに全てのサーバ間でディレクトリ（ただしファイルではない）を複製させることである。同じ結果を達成する更に別の方法は、スイッチに全てのサーバに対するディレクトリ作成トランザクションを統合させることであり、これにより、クライアントがディレクトリを作成するように要求した時は常に、それが全てのサーバ上で同時に作成されることが保証される。当業者は、同じ結果を達成する種々の他の方法を容易に認識することができる。
【０１３７】
クライアントが統合されたディレクトリ内のファイルを列挙するトランザクションを開始した時は常に、ファイルスイッチは、そのトランザクションを統合し、実質的に、異なる関連ファイルサーバ上の対応するメンバーディレクトリを並行に列挙させる。次に、スイッチは、この列挙の結果を連結し、重複する名称（複数の場所に存在するサブディレクトリなど）を排除し、その結果をクライアントに提出する。
【０１３８】
上述の機構の重要な部分は、スイッチが、統合されたディレクトリ内にある各ファイルに対して目標ファイルサーバを選択する特有な方法である。この結果を達成することができる１つの本発明の技術は、以下の通りである。新しいファイルを作成しなければならない時、ファイルスイッチは、無作為に又はそのサーバで利用可能なディスクスペースの量に基づいて目標ファイルサーバを選択し、ファイル作成トランザクションをそのサーバに切り替える。既存のファイルを開くトランザクションが開始された時、ファイルスイッチは、このファイルの開かれている要求を全てのサーバに並行して提出することにより、そのトランザクションを統合し、ファイルを問題なく開くサーバを選択する。
【０１３９】
同じ結果を達成する別の方法は、ファイルオープン要求及びファイル作成要求内で利用可能な情報を用いるハッシュのような計算アルゴリズムに基づいてファイルサーバを選択することである。例えば、ハッシュアルゴリズムを用いて、名称が常に独自であるファイル名称に基づいて有限な組からサーバを選択することができる。この方法は、新しいファイルを作成する時及び既存のファイルを開く時には同じように作動し、ファイルオープン要求を提出する時にはサーバ上に不要な負荷を作成しないという利点を有する。
【０１４０】
更に別の可能な機構について以下に説明する。
ディレクトリ統合は、ネームスペース統合による規定に従って、ファイルシステムの一部に関して行うことができる。例えば、次の規則、
＼＼ｚｘ＼ｍａｒｋｅｔｉｎｇ＼ａｒｔ＼＊  ――＞  ＼＼ｓｒｖｌ＼ｄｉｒｌ  （Ａ）
＼＼ｓｒｖ２＼ｄｉｒ２  （Ｎ）
＼＼ｓｒｖ３＼ｄｉｒ３  （Ｎ）
＼＼ｓｒｖ４＼ｄｉｒ４  （Ｎ）
は、「ｍａｒｋｅｔｉｎｇ＼ａｒｔ」ディレクトリの下でのファイルが、「＼＼ｓｒｖ１」上に最初に記憶されることになるように指定する。「＼＼ｓｒｖ１」が満杯になった時、新しいファイルは、「＼＼ｓｒｖ２」上に記憶される。「＼＼ｓｒｖ２」が満杯になった時、新しいファイルは、「＼＼ｓｒｖ３」上に記憶される。「＼＼ｓｒｖ３」が満杯になった時には、管理者は、更に別のファイルサーバを追加することができる。
【０１４１】
この機構の可能な実施法は、この規則に含まれる各ファイルサーバに対して状態データを維持することである。可能な状態は、満杯（Ｆ）、活性（Ａ）、及び、新規（Ｎ）である。
【０１４２】
この例においては、任意の与えられた時間において、サーバ１つのみが活性状態である（上表の＼＼ｓｒｌ１）。新しいファイルは、そのサーバ上で作成される。活性サーバが満杯になった時（好ましくは容量の１０パーセント以内）、そのサーバは、満杯状態に移行して、別のサーバが新規から活性の状態に移行する。管理者が新しい空のサーバを追加した時は、そのサーバは新規の状態になる。
【０１４３】
ファイルスイッチは、状態移行を自動的に行う。しばらく時間が経つと、上述の規則は、以下のようになるであろう。
＼＼ｚｘ＼ｍａｒｋｅｔｉｎｇ＼ａｒｔ＼＊  ――＞  ＼＼ｓｒｖ１＼ｄｉｒ１  （Ｆ）
＼＼ｓｒｖ２＼ｄｉｒ２  （Ｆ）
＼＼ｓｒｖ３＼ｄｉｒ３  （Ａ）
＼＼ｓｒｖ４＼ｄｉｒ４  （Ｎ）
【０１４４】
ファイルオープン要求が到着した時、ファイルスイッチは、まず、現在活性な装置上でそのファイルを開こうとする（最近作成されたファイルの方が頻繁にアクセスされる可能性があるため）。ファイルがそこになかった場合、オープン要求を全てのサーバに提出してより古いファイルを見つけることができる。このファイルは、装置の１つのみにあり、スイッチは、このファイルと共に更に別の作業をその装置に転送することになる。
関連技術の当業者は、ディレクトリ統合において目標ファイルサーバの明確な選択を達成するために数多くの他の機構を利用することができることを認識するであろう。
【０１４５】
ファイル統合
ファイルのコンテンツを複数のファイルサーバ間でストライピング及び／又はミラーリングすることができるために、ファイルスイッチは、異なるサーバ上にある複数のファイルを統合してクライアントに単一ファイルとして提示することができるべきである。この節では、ファイル内にあるデータを統合する方法と比較しながら、ファイルスイッチがファイルオブジェクトを統合する方法について説明する。データ統合は、本明細書の他の節で説明されている。
【０１４６】
図８は、ファイルスイッチによるファイルオブジェクト統合の本発明の手法を示す。ファイルスイッチ１００は、接続１０９を通じて接続されたクライアントから、ファイルオープン要求８０１を受信する。スイッチは、統合されたファイルのインスタンスがあるファイルサーバの部分集合、この例においては、ファイルアレー８００として集合的に識別されるサーバ１０１、１０２、１０３、及び、１０４を判断する。次に、スイッチは、適切に修正されたファイルオープン要求８０２、８０３、８０４、及び、８０５をファイルアレー８００のサーバに並行して提出する。サーバ１０１〜１０４は、それぞれのファイルオープン要求８０２を８０５を通じて受信し、並行して検査し、プロトコルに従ってスイッチに返答するが、各々は、スイッチがそのサーバ上にある個別ファイルに対するそのクライアントであると考える。スイッチは、全ての応答をファイルサーバから回収し、各々がファイルアレー８００のサーバ１０１〜１０４の１つにある、統合されたファイルを備えたメンバーファイルに関する情報データでその状態を更新し、トランザクション結果を統合して本来のクライアントに提出する。
【０１４７】
その結果、クライアントは、この時点で、ファイル（この例においては「ＦＩＬＥ１」）に対して、それがあたかも単一ファイルサーバ上にある真のファイルであるかのように様々なトランザクションを開始することができる。スイッチは、異なるトランザクションを異なる方法で統合する。読取及び書込トランザクションに関する作業については、本明細書の他の節で説明する。同時性関連の要求及び問題に関するファイルスイッチの作動について、以下の節で説明する。
【０１４８】
大部分の商業レベルのファイルシステムにおいては、ファイルオブジェクトは、作成日、最終修正日、サイズ、ディスク使用量、アクセス制御リスト（ＡＣＬ）、セキュリティ記述子、バックアップ／アーカイブ指標、及び、更にはユーザ定義のプロパティーのような、豊富な属性の組を有する名前付きエンティティーである。ファイルオブジェクトを適切に統合するために、ファイルスイッチは、異なる統合方法を異なる属性に適用しなければならない。こういう理由で、ファイルオブジェクト統合に関する本発明の手法は、この説明を特定のファイルシステム及びネットワークファイルプロトコルに限定することがないように一般的に説明し、当業者は、この説明からその内容を特定のネットワークファイルプロトコルに適用することができるであろう。
【０１４９】
一般に、ファイルスイッチ内で属性関連のトランザクションを処理する好ましい方法は、属性のいかなる要求された修正をも統合されたファイルを備えたメンバーファイルの組の全てのファイルに適用し、要求された時にできるだけ少数のメンバーファイルからそれらの属性の値を読み取ることである。特定の属性が統合される実際の方法は、特定の属性のセマンティクスにより異なる。
例えば、統合の作成日は、そのファイルの第１の記憶されたインスタンスの作成日としてもよく、最終修正日は、ファイルのインスタンスのうちの少なくとも１つが修正された最新の日付／時間としてもよい。統合ファイルサイズを判断するアルゴリズムは、ファイルがストライピング及び／又はミラーリングされる方法に基づくことが好ましく、例えば、ストライピングされるがミラーリングされないファイルについては、ファイルサイズは、全てのメンバーファイルのサイズの和と規定することができ、ストライピング及びミラーリングの両方が行われるファイルについては、ファイルサイズは、単一鏡像からのメンバーファイルのみの和と規定することができる。更に別の例として、このようなファイルのディスク使用は、全てのストライプ及びミラーメンバーファイルのディスク使用属性の和と規定することができる。
【０１５０】
当業者は、上記及び他のファイル属性を多くの異なる明確な方法で統合することができ、その全てが本発明のファイルスイッチにおいて良好に機能することができることを認識することができる。
【０１５１】
同時性機構の統合
ファイルサーバ及びネットワークファイルプロトコルは、複数のクライアントにより同時にアクセスされるように設計されることから、一般的に、同時性の処理を非常に良くサポートする。例えば、「ＣＩＦＳ」ネットワークファイルプロトコルにより、排他的ファイルオープンを要求することができ、これは、２つのクライアントがオープンを同時に要求した場合、その要求の１つのみが問題なく処理されることになることを意味する。
【０１５２】
単一ファイルサーバの場合、このサポートは、オペレーティングシステム同期オブジェクトを使用してファイルサーバ内で実行されることが多い。これは、複数のクライアントからのアクセスを同じコンピュータ内で直列化することができる単一サーバについて良好に機能する。しかし、従来技術の節で説明したように、この手法をクラスター構成の複数のサーバに拡張すると、障害となる問題が生じる。こういう理由から、本発明は、好ましくは同時性を処理するための異なる機構を使用する。
【０１５３】
同時性の問題：一例
図１９は、本発明の統合ファイルシステムにおける同時アクセスを示す。システム１９０８は、２つのファイルスイッチ１００及び１９０６、ファイルサーバ１０１〜１０６、及び、ファイルサーバ及びファイルスイッチを接続するのに使用される層２スイッチ１９０７から成る。
【０１５４】
この例において、２つのクライアントは、排他的ファイルオープン要求を同時に送る。第１のクライアント、つまりクライアントＡは、ファイルスイッチ１００に接続されて、排他的ファイルオープン要求８０１をファイルスイッチに送り、第２のクライアント、つまり、クライアントＢは、ファイルスイッチ１９０６に接続されて、排他的ファイルオープン要求をファイルスイッチに送る。この例においては、要求されたファイルは、各々がファイルサーバ１０１〜１０４（この４つのサーバがこのファイルに対してファイルアレー８００を形成する）の１つにある４つファイルから統合される。
【０１５５】
両方のファイルスイッチは、要求を同時に処理し、着信要求８０１及び１９０１をファイルアレー８００の４つのサーバの各々に切り替えることによりそれを処理しようと試みる。ファイルスイッチ１００は、要求８０２〜８０５をそれぞれファイルサーバ１０１〜１０４に送る。ファイルスイッチ１９０６は、要求１９０２〜１９０５をそれぞれファイルサーバ１０１〜１０４に送る。２つのスイッチは、要求を同時に発行したかもしれないが、要求は、何らかの順番でファイルの各々に到着する。この例においては、ファイルサーバ１０１、１０３、及び、１０４は、対応する要求、すなわち、要求１９０２、１９０４、及び、１９０５をファイルスイッチ１９０６から受信する前に、要求８０２、８０４、及び、８０５をそれぞれ受信する。ファイルサーバ１０２は、それが要求８０３をファイルスイッチ１００から受信する前に、要求１９０３をファイルスイッチ１９０６から受信する。当業者は、他の順序と、２つよりも多いクライアント、２つよりも多いスイッチ、及び、別の個数のファイルサーバを伴う類似の状況とが明らかであることを容易に認識するであろう。
【０１５６】
上述の要求到着順序に基づいて、ファイルサーバ１０１、１０３、及び、１０４は、ファイルスイッチ１００から来るオープン要求８０２、８０４、及び、８０５を満足させ、ファイルスイッチ１９０６からの要求１９０２、１９０４、及び、１９０５を拒否する。ファイルサーバ１０２は、ファイルスイッチ１９０６からの要求１９０３を満足させ、ファイルスイッチ１００からの要求８０３を拒否する。その結果、ファイルスイッチの立場からすれば、両方の統合されたトランザクションは、そのいずれもがメンバーファイルの４つ全てを開くことに成功しないので失敗することになり、また、それぞれのクライアント要求８０１及び１９０１にも失敗することになる。この筋書きは、明らかに、１つのクライアントが成功して他の全ては失敗すべきであると定める排他的オープン要求のセマンティクスに違反する。
【０１５７】
当業者は、この状況が、クライアントの競合するリソース（すなわち、統合されたファイル）が利用可能であってクライアントの１つに容易に付与することができるが、どのクライアントもそれを取得すること（すなわち、ファイルを開くこと）ができないという古典的なデッドロック問題であることを認識するであろう。
【０１５８】
同時アクセスを処理するためのアルゴリズム
本発明は、このような場合において、同じ統合されたファイルを目標とする１９０１のような他のネットワークファイルプロトコル・トランザクションに対して、８０１のような統合されたネットワークファイルプロトコル・トランザクションの適正なセマンティックな挙動を達成する。本発明は、同じファイル又は他のファイルシステムエンティティー上で試行された複数の同時トランザクションの１つのみが成功するように、トランザクションの各々の結果を決定論的方法で統合することによりこれを行う。
【０１５９】
図９は、この結果を達成するためのアルゴリズムを示す。アルゴリズムの第１段階９０１において、ファイルスイッチは、統合されたトランザクションの要求を全て目標サーバに対して発行し、それらの応答を回収する。段階９０２において、スイッチは、全ての要求が成功であることを示すかどうかを検査する。そうである場合には、アルゴリズムは問題なく完了する（例えば、ファイルは問題になく開かれる）。
【０１６０】
要求の少なくとも１つが失敗を示した場合、アルゴリズムは、段階９０３に進み、そこで、ファイルスイッチは、要求の全てが失敗したのか検査する。そうである場合は、アルゴリズムは完了し、ファイルスイッチは、統合されたトランザクションに失敗する（すなわち、ファイルをこの時点では開くことはできない）。要求の少なくとも１つが成功したことを示す（すなわち、スイッチが目標サーバの少なくとも１つでファイルを問題なく開くことができた）場合、アルゴリズムは段階９０４に進む。この段階において、スイッチは、第１のサーバ（この例においてはサーバ１０１）のトランザクションの結果が成功したことを示すか検査する。成功したことを示さなかった場合、スイッチは、段階９０７に進み、そこで、成功した全てのメンバートランザクションを取り消し（すなわち、メンバーファイルを閉じ）、統合されたトランザクションに失敗する。
【０１６１】
段階９０４から「ＹＥＳ」の方に進んだ（すなわち、スイッチが、問題なく第１のサーバ１０１上のメンバーファイルを開いた）場合、アルゴリズムは、段階９０５及び９０６に進み、そこで、スイッチは、全てが成功するまで全ての失敗したメンバートランザクションを再試行し、全てが成功した時点で、統合されたトランザクションを問題なく完了する。
【０１６２】
図９に示すアルゴリズムは、それが同時トランザクションの全てに適用された時、これらのトランザクションの１つが成功して他の全ては失敗し、従って、適正なアトミックな挙動が達成されることを保証する。尚、ファイルスイッチの各々は、他のスイッチから同じファイルを目標とするトランザクションによって受信された特定の結果に関する情報がなくても、トランザクションから受信した結果に基づいてそのトランザクションを再試行するか又は取り消すかを判断することができる。当業者は、このアルゴリズムは任意数のスイッチ及び任意数のクライアントに拡張されることを容易に認識するであろう。更に、単一のファイルスイッチは、同じアルゴリズムを使用してそれ自体のクライアントの２つからの競合する要求を調停することができ、その結果、この種の作業に関して他の内部的な同期が不要となることが好ましい。
【０１６３】
従って、本発明は、以下の段階及び機構により、統合ファイルシステム内での同時性をサポートするための１つの可能な機構を形成する。
１．本明細書で説明するように着信トランザクションを切り替える段階。
２．ファイルサーバの各々で実行されるネットワークファイルプロトコルにより供給される同時性解決機構を使用する段階。
３．全ての競合するトランザクションに対して決定論的な反応を生成することができる（すなわち、競合するトランザクションの１つのみが成功する）図９に示すようなアルゴリズムを準備し、同時に各スイッチが他の競合するトランザクションの結果を必要とせずに、そのようなアルゴリズム及びそれ自体のトランザクションの結果に基づいてアクションを起こす段階。
【０１６４】
当業者は、単一のファイルスイッチが、そのスイッチに接続されたクライアントからの競合する要求の適切な処理を確実に行うためにこの態様を使用することができるということを含め、本発明のこの態様が容易に任意の数のファイルスイッチに適応可能であることを容易に認識するであろう。更に、当業者は、本発明の精神から逸脱することなく、図９に示すアルゴリズム以外のアルゴリズムを使用してこの結果を達成することができることを容易に認識するであろう。
【０１６５】
暗黙的ロック
ネットワークファイルプロトコルは、一般的に、同じファイル及びファイル内の同じ領域に書き込もうとする複数のクライアントを同期させるために、ファイルレベルのロック及びバイト範囲のロックを提供する。ロックが全てのクライアントにより矛盾することなく使用された時、矛盾したデータが同じファイルの異なるミラーに書き込まれるのを回避するための更に別の同期化は不要であるが、全てのファイルクライアントアプリケーションが、矛盾なくロック機構を使用するとは限らない。
【０１６６】
複数のファイルクライアントにより同時に複数のファイルサーバに書き込まれたファイルデータの一貫性を確保し、同じファイルの全てのミラーコピーが確実に同一データを含むようにする機構は、以下の機構である。ファイルスイッチがファイル書込要求を受信した時、要求しているクライアントは、要求された領域に関して完全なファイルロック（排他的ライター又は排他的オプロック）又はバイト範囲のロックを既に取得しているのか検査する。取得していない場合、ファイルスイッチは、クライアントが書き込むように要求したファイルの領域に関するバイト範囲のロックを発行した後、書込み作業を行い、その領域のロックを解除して、そのクライアントに対するファイル書込トランザクションを完了する。
この機構がファイルスイッチにより矛盾なく使用された時に、全てのファイルスイッチにより同じ組のファイルサーバにアクセスする複数のファイルスイッチの場合は、任意の単一ファイルサーバにより維持される一貫性に比するレベルでのファイルデータの一貫性が保証される。
【０１６７】
予約ファイル
ロックをサポートしないネットワークプロトコルに関連して頻繁に使用される更に別の機構は、ファイルサーバ上に「予約」ファイルを作成することである。この機構を用いて、２つ又はそれ以上のクライアントが所定のファイルＡに対して目標とするトランザクションの実行を試みる場合（１回に１つのクライアントのみにより実行すべきであるように）、各々のクライアントは、まず、公知の名称及び位置（例えば、ファイルＡと同じディレクトリ内のファイルＬＯＣＫ）で「予約」ファイルを作成しようとすることになる。それらは、排他的セマンティクスを有するファイル作成要求、すなわち、もしそのファイルを作成すれば成功となり、ファイルが既に存在していた場合には失敗となる要求を使用して予約ファイルを作成しようとする。
【０１６８】
従って、両方のクライアントが目標とするトランザクションを実行しようとした場合、各々のクライアントは、まず、予約ファイルを作成しようとする。クライアントの一方が成功し、目標とするトランザクションを続けることになる。他方のクライアントは、そのファイルが既に存在しているために予約ファイルの作成に失敗することになり、目標とするトランザクションを実行しない。その代わりに、定期的に予約ファイルを作成しようとする。予約ファイルが存在する限り、これらの試行は失敗する。第１のクライアントが目標とするトランザクションを完了した時、それは予約ファイルを削除することになる。その後、予約ファイルを作成しようとする他方のクライアントの次の試行が成功することになり、目標とするトランザクションで進行する。
【０１６９】
ファイルスイッチは、図９に示すアルゴリズムのみを使用しても簡単に取り消すことができない作業を実行する必要がある時に、予約ファイルを作成する同じ機構を使用することができる。尚、メンバーファイルが存在する同じディレクトリにおいてロックファイルを作成し、競合しているトランザクションにより目標にされたファイルの派生物であるファイル名を有することができる。このようにして、同期化が複数のファイルサーバ間で配分されるので、集中した「ロック」又は同期化の権限は存在しない。
【０１７０】
当業者は、予約ファイル機構が本発明の精神を逸脱しない範囲に保ちながら図９に示すアルゴリズムを更に発展したものであること、また、そのアルゴリズムの他の変形例及び拡張例をファイルスイッチと共に有利に使用することができることを容易に認識するであろう。
【０１７１】
便宜的ロック（オプロック）の統合
ネットワークプロトコルと共に頻繁に使用される別の機構は、便宜的ロック（オプロック、同じくコールバックともいう）である。オプロックはクライアント側キャッシュを可能にすることから（データの完全性、一貫性、及び、適時性を保持しながら）、オプロックを使用すると、一般的にクライアントが経験する性能が上がる。
【０１７２】
ファイルスイッチは、メンバーファイルに対してオプロックを統合し、それがクライアントに呈示する統合ファイルに対してオプロックを行うことが好ましい。これを行うために、ファイルスイッチは、メンバーファイルの各々に対してオプロックを要求する。すなわち、全てのオプロックが付与された場合（すなわち、ファイルスイッチが全てのメンバーファイルに対してオプロックを保持する）、ファイルスイッチは、オプロックをクライアントに付与する。メンバーファイルの１つがファイルスイッチに付与したオプロックを破壊した場合、スイッチは、そのクライアントに対して付与したオプロックを破壊する。（クライアントがオプロックを要求していなかった場合、スイッチは、それがもはや特定のファイルに対するオプロックを保持しておらず、そのようなオプロックに関してその後のクライアントの要求を却下することになることをその状態において単に気付くことができる。）次に、スイッチは、好ましくは、そのオプロックを破壊するのに必要な全てのアクション（このファイルに対するあらゆるキャッシュデータを再度書き込んで破棄するなど）を完了したことをクライアントが認めるのを待ち、オプロックを最初に破ったファイルサーバに対してオプロック破壊完了を受入れる。ファイルスイッチがサーバからのオプロック破壊要求に応答する方法は、クライアントがスイッチに応答したのと同じであることが好ましい（例えば、オプロック破壊了解、又は、ファイルが閉じた）。
【０１７３】
クライアントがスイッチからのオプロック破壊要求を処理している間に、別のファイルサーバが同じファイル対して付与したオプロックを破壊しようとした場合、ファイルスイッチは、これが発生したことをメモリに保持する。クライアントがオプロック破壊を完了した時、スイッチは、付与したオプロックを破壊するように要求した全てのサーバに対して応答する。ファイルスイッチは、このファイルに対するオプロックがもはや付与されないことをその状態において気付き、他のファイルサーバが同じファイルに対してオプロックを破壊しようとした場合、クライアントがもはやオプロックを保持していないので（また、その結果、いかなるデータ又は範囲ロックもキャッシュしていないはずである）、ファイルスイッチは、直ちにオプロック破壊を受入れることができる。
【０１７４】
この関連技術の当業者には明らかなように、上述の機構を使用して、ネットワークファイルプロトコルにより形成された様々な形式のオプロックを処理し、また、オプロックを完全に破壊するか又は単に格下げすることもできる（「ＣＩＦＳ」プロトコルにおける排他的オプロックからレベルＩＩオプロックへの格下げ要求など）。
【０１７５】
当業者はまた、この機構が同じ組のファイルサーバを用いて複数のファイルスイッチの同時作業を更に可能にするものであることを認識するであろう。
【０１７６】
同時性機構の統合のまとめ
当業者は、他のアルゴリズムを導入して同じ結果を達成し、統合されたトランザクションに関して一貫したアトミックな挙動を確保することができることを認識するであろう。同様に、当業者は、同じ手法をロックや作成などのような他のファイルトランザクション形式に適用することができることを容易に認識するであろう。
【０１７７】
実際には、本発明は、ファイルスイッチ自身の間の直接的な対話及び通信、従って結合を必要とせずに、複数の独立したファイルスイッチのクライアント間での同期化を実行するために、ネットワークファイルプロトコルにより供給された既存の同期化機構を統合する。更に、個々のファイルスイッチの各々は、そのスイッチに接続されている複数のクライアントにより要求されたトランザクションを同期するためにこれらの機構を更に使用することができる。
【０１７８】
データ統合
複数のサーバ間でファイルオブジェクトを統合し、かつ同時の環境でこれを安全に行う能力は、ファイルスイッチが、統合されたファイルのデータを複数のサーバ上に配分し、それによって並行作業及び高い利用可能性の両方を達成することを可能にする。同じ処理は、メンバーファイルのコンテンツをネットワーククライアントに呈示する単一ファイルに統合するファイルスイッチとして見ることができる。
【０１７９】
大部分のネットワークファイルプロトコルは、ファイルデータをバイトの連続アレーとして表す。これは、個々のファイルの各々に対するデータを配分するのに必要な技術が、ハードディスクのアレーに対するデータを配分するのに必要な技術と異なるものではないことを意味する。当業者は、従来技術の節で説明したように、ストライピング、ミラーリング、及び、全て他の「ＲＡＩＤ」の変形を含むこれを行う全ての方法が、個々のファイルのデータの配分にも同様に革新的に適用することができることを認識するであろう。
【０１８０】
以下で説明する図１０〜図１２は、それぞれ、本発明により実施されるミラーリング、ストライピング、及び、スピルオーバーを示す。これらの機構は、従来から存在するものであるから、クライアント及びサーバという表現は不要であると思われる。ただし、これらの機構は、ローカルマシン、一般的にはクライアント上で行われるＡＰＩ機能ではなく、むしろファイルスイッチにおいて行われるファイルプロトコル・トランザクションの切り換え（これらの図の各々においては矢印で表現される）に基づいて本発明により実行されることが分る。
【０１８１】
ミラーリング
図１０は、交換ファイルシステムにおけるミラーリングを通じたデータ統合を示す。この例において、ファイルスイッチ（図示せず）は、好ましくは全てが異なるファイルサーバ上にあるメンバーファイル１００１、１００２、１００３、及び、１００４を、クライアントに呈示される単一の統合ファイル１０００に統合する。メンバーファイル１００１〜１００４は、スイッチが統合ファイル１０００のコンテンツとして呈示する同一データを含む。
【０１８２】
クライアントがファイルオープントランザクションを開始した時、スイッチは、そのトランザクション（図８に図示）を統合して、好ましくは全てのメンバーファイル１００１〜１００４を開く。クライアントがファイル読取トランザクションを開始した時、ファイルスイッチは、好ましくは無作為にメンバーファイルがあるファイルサーバの１つを選択し、読取トランザクションをそのサーバに切り替える。そのサーバは、読取トランザクションを実行してその応答をスイッチに戻す。スイッチは、その応答をクライアントに転送し、その結果、クライアントにより要求された読取トランザクションが完了となる。この機構では、複数のクライアントが同じファイル１０００を読み取ろうとした場合、スイッチは、クライアントのトランザクションを異なるメンバーサーバに無作為に方向付けすることになる。従って、スイッチは、これらのファイルサーバ間の負荷の均衡を保ち、更に、クライアントは、ファイル１０００が単一サーバ上に記憶される状況と比較すると、最大４倍の性能の増加（この例において）を経験することができる。
【０１８３】
クライアントがファイル書込トランザクションを開始した時、スイッチは、ユーザデータをメンバートランザクションに複製することによりトランザクションを統合する。その結果、全てのメンバーファイル１００１〜１００４は、同じデータにより同時に更新される。全てのメンバートランザクションが並行に実行されることから、これは、単一サーバに記憶されたファイルと比較すると、書込の統合ファイルの性能を大幅に劣化させるものではない。
【０１８４】
最後に、クライアントがクローズトランザクションを開始した時、スイッチは、オープントランザクションと類似の方法でそれを統合し、全てのメンバーファイルを閉じる。
【０１８５】
ファイルミラーリングの１つの他の重要な利点は、上述のトランザクションが、たとえメンバーファイルサーバのうちの１つ又はそれ以上が利用不可能になったとしても問題なく完了することができるということである。オープン、書込み、及び、クローズのトランザクションは、全ての利用可能なサーバに切り替えられ、読取トランザクションは、利用可能なサーバのいずれか１つに切り替えられることになる。このようにして、メンバーファイルのうちの少なくとも１つがオンライン上にある限り、全体としてのファイルシステム、及び、特に統合ファイル１０００は、全てのクライアントに利用可能な状態である。
【０１８６】
ストライピング
図１１は、ファイルスイッチによるストライピングを通じた交換ファイルシステムにおけるデータ統合を示す。この例において、ファイルスイッチ（図示せず）は、好ましくは全てが異なるファイルサーバ上にあるメンバーファイル１１０１、１１０２、１１０３、及び、１１０４を、クライアントに呈示される単一の統合ファイル１１００に統合する。この場合のメンバーファイル１１０１〜１１０４は、スイッチが連続した統合ファイル１１００として呈示する異なった重なり合わないストライプを含む。
【０１８７】
クライアントがファイルオープントランザクションを開始した時、スイッチは、そのトランザクションを統合し（図８に示すように）、メンバーファイル１１０１〜１１０４を開く。クライアントがファイル読取トランザクションを開始した時、スイッチは、以下の段階を実行することにより、このトランザクションを統合する。最初は、ストライプサイズと、要求された開始オフセット及び要求されたトランザクションサイズとに基づいて、どのメンバーサーバがトランザクションに関与することになるか、また、どの開始オフセットでどれだけのデータをメンバーファイルの各々が読み取るべきかを判断する段階である。次に、スイッチは、メンバートランザクションを選択されたサーバに発行し、そのデータが正しい再構成された順序でクライアントに到着することを保証することによりその結果を統合する。クライアントは、応答用の統合ヘッダと、それに続いて要求した全てのデータとを正しい順序で受信する。
【０１８８】
当業者は、データが読取トランザクションの場合のように組み立てる代わりに図５に示すように配分される点を除き、この場合の書込トランザクションが、上述の読取トランザクションと類似の方法で実行されることを認識するであろう。
【０１８９】
最後に、クライアントがクローズトランザクションを開始した時、スイッチは、オープントランザクションと類似の方法でそのトランザクションを統合し、全てのメンバーファイルを閉じる。
【０１９０】
ストライピングによるデータ統合の場合には、読取トランザクション及び書込トランザクションの両方は、より少量のデータのための対応する読取及び書込トランザクションを複数のメンバーサーバに並行して提出することにより統合される。これは、ファイルスイッチが個々のクライアントの各々に供給することができる性能のそれぞれの増加、及び、複数のクライアントが同じファイルにアクセスする場合の優秀な負荷均衡化をもたらす。更に、複数の研究でこれまで示されているように、ストライピングは、ホットスポッティングの問題を解決する傾向がある。
【０１９１】
スピルオーバー
図１２は、スピルオーバーを通じたデータ統合を示す。スピルオーバー機構は、好ましくは本明細書で説明する他の機構のうちの１つ又はそれ以上と共に、ストレージ容量を統合するのに使用されることが好ましい。スピルオーバーは、統合ファイルに対するメンバーサーバのうちの１つ又はそれ以上がファイルの開いている間に予想外にディスクスペースを使い切った場合に特に有益である。図は、好ましくは異なるファイルサーバにある２つのメンバーファイル１２０１及び１２０２を備えた統合ファイル１２００を示す。図からわかるように、統合ファイル１２００の区域１、２、３、及び、４は、メンバーファイル１２０１内にあり、残りの区域５及び６は、メンバーファイル１２０２内にある。
【０１９２】
スピルオーバーは、目標ファイルサーバがディスクスペースを使い切るか又は使い切ったことを、ファイルスイッチがデータをファイル内に書き込む処理において突然発見した時に発生する。このような場合に、書込トランザクションで失敗するのではなく、スイッチは、別のサーバ上で新しいメンバーファイルを開き、その中に書込みを継続することを選択することができる。２つのファイルのコンテンツは、共通の連続バイトアレーを呈示するために自明の方法で連結される。当業者は、スピルオーバー機構を第２のファイルにも同じく適用することができ、システム内の全てのディスク容量を必要な場合に完全に利用することができるように、任意に長いメンバーファイルのチェーンを作成することを認識するであろう。
【０１９３】
ファイルスイッチは、ファイルトランザクションをスピルオーバーファイルに以下のように切り替える。オープン及びクローズトランザクションについては、ファイルスイッチは、全てのメンバーファイルがそれぞれ開くか又は閉じるように、トランザクションをメンバーファイルがある（すなわち、ファイル１２００のデータの任意の部分を含む）全てのサーバに切り替えることが好ましい。読取及び書込トランザクションについては、ファイルスイッチは、開始オフセット及び読取／書込が為されるペイロードの長さを見て、トランザクションを以下のように切り替える。
【０１９４】
（ａ）ペイロードが第１のメンバーファイル（例えば、ファイル１２００からのセグメント１及び２）内に完全に適合する場合、ファイルスイッチは、トランザクションを第１のサーバに切り替える。
（ｂ）ペイロードがスピルオーバー（第２及びそれ以降の）メンバーファイル（例えば、メンバーファイル１２０２の始めに記憶されたファイル１２００からのセグメント５）のうちの１つの中に完全に適合する場合、ファイルスイッチは、トランザクションをそのメンバーファイルがあるサーバに切り替える。スイッチはまた、統合されたファイル内のメンバーファイルの開始オフセットをそのトランザクションの開始オフセットから差し引くことにより、トランザクションのパラメータを修正する。本発明の例においては、セグメント５は、ファイル１２０２のオフセット０にあり、従って、４つのセグメントが要求から差し引かれるべきであり、ファイル１２０２から第１のセグメントを読み取る要求をもたらす。
（ｃ）ペイロードが複数のメンバーファイル（例えば、ファイル１２００からのセグメント４及び５）に亘る場合、ファイルスイッチは、要求の一部分がある全てのサーバにトランザクションを複製し、各トランザクションの開始オフセット及び長さを修正する。応答を受信すると、ファイルスイッチは、データを正しい順序で再構成し（ストライピングに対して行われる方法と同様に）、それをクライアントに返送する。
【０１９５】
スピルオーバー機構が機能するために、ファイルスイッチは、好ましくは、メンバーファイル１２０１を開いた後に、（ａ）メンバーファイル１２０２が存在すること、（ｂ）ファイル１２０２が存在する目標サーバ、及び、（ｃ）このファイルに対するスピルオーバーチェーン内に他のいずれかのメンバーファイルがあるか否かを教えることができるべきである。これを達成する１つの方法は、メンバーファイルの各々と共に記憶された付加的なメタデータを使用することである。
【０１９６】
この手法を用いて、ファイルスイッチは、ファイル作成時に小さな固定サイズのデータブロックを全てのメンバーファイルの各々の始めに予約し、そのブロックをクライアントから見えないようにする。ファイルがスピルオーバーされる必要がある時に、このメタデータブロックを使用して、名前と次のメンバーファイルがあるサーバ、及び、スピルオーバーチェーン内のファイルの総数を記憶することができる。
【０１９７】
上述の機構が実施された場合、同じメタデータブロックを使用して、スイッチがメンバーをより都合よく見つけるように助けることになる情報を記憶することにより、ストライピング及びミラーリングされたメンバーファイルの組へのアクセスを最適化することができる。
【０１９８】
代替的に、内在的なメンバーファイルサーバがカスタムデータをファイルと結びつけるための他の機構（例えば、ストリーム又は拡張された属性）をサポートする場合、代わりにそれらの機構の１つを使用してメタデータブロックを記憶することができる。
【０１９９】
上述の説明に対しては、ファイルのメタデータは、所定のファイルのコンテンツがファイルサーバ上に記憶される方法に関する情報を含むデータ構造として形成することができる。例えば、このデータ構造は、スピルオーバーセグメントの数、各セグメントのサイズ、及び、各セグメントがあるファイルサーバの識別（名前など）を含むことができる。別の例として、データ構造はまた、ストライプの数、ストライプサイズ、及び、ミラーの数などのような、その所定のファイルを統合するために使用される統合パラメータを含むことができる。
【０２００】
データ統合のまとめ
当業者は、本節で説明した機構を同じファイルに対して同時に有益に適用することができることを容易に認識するであろう。例えば、ミラーリング及びストライピングを組み合わせて、単一ファイルの性能及び利用可能性の両方を向上させることができ、更に、いくつかのファイルサーバがストレージスペースを使い切った場合に、スピルオーバーを同じファイルに追加することができる。更に、当業者は、他のデータ統合技術、例えば「ＲＡＩＤ４」及び「ＲＡＩＤ５」を本明細書で説明する機構に加えて又はその代わりにファイルスイッチに実装することができることを認識するであろう。
【０２０１】
ファイルサーバの故障
複数のファイルサーバに配分及び／又は複製されたファイルのコンテンツを保持する能力は、ファイルサーバの故障の場合に本発明がデータの高い利用可能性を提供することを可能にする。
【０２０２】
故障は、（ａ）ファイルスイッチが定期的にサーバに送るハートビートに応答しないファイルサーバ、（ｂ）接続が落ちたファイルサーバ接続、又は、（ｃ）ファイルサーバからファイルスイッチによって要求された作動が時間切れになることにより発見される。好ましくは、故障を発見したスイッチは、同じファイルサーバに接続された任意の他のスイッチに、特定のサーバがもはや利用可能ではなく、要求をそこに送るべきではないと通知することができる。
【０２０３】
ファイルサーバの組に記憶された全てのファイルが少なくとも１つのミラーコピーを有する限り、記憶されたファイルデータの損失はない。全てのファイルスイッチは、単にそのミラーコピーを使用してファイルの読取りを開始する。そのファイルサーバが回復するまでの性能の劣化及び冗長度の悪化の可能性と共に作動は継続される。Ｍを管理者により規則内で構成されたミラーコピーの数とすると、最大Ｍ−１までのファイルサーバは、ファイルデータの損失なく故障することができる。
【０２０４】
以前に故障したファイルサーバが作動可能状態まで回復してサーバの組に復帰した時、ファイルスイッチは、それに対してファイルシステム同期化を開始し、新しいサーバ上のファイルシステムが残りのサーバと完全に同期化された状態で、このファイルサーバは、通常の作動を再開する。
【０２０５】
この同期化は、コンプリート（新たに初期化されたファイルシステムから開始）、又は、インクリメンタル（以前の状態から開始、ファイル日付及びサイズに基づく）とすることができる。同期化は、ファイルシステムをクライアントに利用不可能な状態にすることなく実行され、同期化処理がファイルサーバ及びスイッチに掛ける負荷は、ネットワーク・ファイル・システムがクライアントに十分に利用可能な状態のままであるように、管理者が設定可能であるようにしてもよい。
【０２０６】
統合規則
本発明の１つ利点は、性能、ストレージ利用、及び、目標とするデータ利用可能性レベルの間の最適な均衡を達成するために、ファイルスイッチが、ストライピング、ミラーリング、及び、他のデータ統合技術の異なる組み合わせを使用する異なる方法で異なるファイルを統合することができるように、ファイル単位でファイルデータを統合する事実に由来する。
【０２０７】
「ＲＡＩＤ」又はパラレルファイルシステムの場合のようなブロック装置に適用された時のストライピング、ミラーリング、及び、他のデータ統合技術の効果は、単一の解決策はファイル及びアクセスパターンの全ての種類に適合することができないという事実により、大幅に低下される可能性があることは公知である。その一例として、ストリーミングビデオは、ストリーミングデータが通常大きなセグメントで読み取られていることから、多数の装置に亘って非常に効果的にストライピングすることができる。スペクトルの反対側では、「ＨＴＭＬ」ファイルは、一般的にわずかに数キロバイトの大きさであり、ストライピングに適した目標ではない。
【０２０８】
本発明は、ファイルの異なる形式及び／又は組に対し、異なるデータ統合パラメータを用いてファイルスイッチを設定する統合規則を利用する。
【０２０９】
図１３は、データ統合規則の構文を示すものであり、このような規則の例を与えている。好ましい構文１３００は、各ファイルの経路（統合されたネームスペースでの位置）及び形式（ファイル拡張子／サフィックスにより認識）に基づいて所定の組のファイルに対して選択された一組の統合パラメータ、つまり、ミラーの数、ストライプの数、及び、ストライプのサイズを規定する。
【０２１０】
規則１３０１は、ファイルシステムのどこかに位置する「ＭＰＥＧ」ファイルに関する一般的なパラメータを示す。この規則は、任意のファイル経路と、ファイル名の拡張子が「ＭＰＥＧ」であるファイルのみに対して選択され、２でミラーリング、３２でストライピング、及び、１６ＫＢのストライプサイズを規定する。この規則を用いて、いかなる「ＭＰＥＧ」ファイルも一度ミラーリング処理され（データの２つのコピーがシステムで存在することになる）、３２個のファイルサーバに亘って１６キロバイトのファイルストライプでストライピングされることになる。
【０２１１】
規則１３０２は、ファイルシステムのどこかに位置する「ＨＴＭＬ」ファイルに関する一般的なパラメータを示す。この規則は、任意のファイル経路と、ファイル名の拡張子が「ＨＴＭＬ」であるファイルのみに対して選択され、６４でミラーリングを規定し、ストライピングはない。この規則を用いて、いかなる「ＨＴＭＬ」ファイルも６４個のファイルサーバ上でミラーリング処理されることになり、これにより、多数のクライアントにより同時に読み取られた時に負荷平衡が可能となる（これは、「ＨＴＴＰ」サーバ上の「ＨＴＭＬ」ファイルに対しては一般的なアクセスパターンである）。
【０２１２】
規則１３０３は、ファイルシステムのどこかに位置する「マイクロソフトワード」ファイルに関する一般的なパラメータを示す。この規則は、任意のファイルと、ファイル名の拡張子が「ＤＯＣ」であるファイルのみに対して選択され、３でミラーリング、８でストライピング、及び、８ＫＢのストライプサイズを規定する。この規則を用いて、いかなる文書ファイルも２度ミラーリング処理され（利用可能性の向上を目指してデータの３つのコピーがシステム内で存在することになる）、８個のファイルサーバに亘って８キロバイトのファイルストライプでストライピングされることになる。大半のこのような文書は、一般的に３２ＫＢから１００ＫＢまでのファイルサイズを有することから、この規則により、個々のクライアントの各々について中庸な（例えば、４Ｘ）性能向上が得られ、各ファイルが合計２４個のファイルサーバに亘って分散されていることから、過剰なストレージスペースを浪費することなく、ホットスポッティングの確率が大幅に低減される。
【０２１３】
規則１３０４は、各々のサイズは小さいが貴重な知的財産権を含むソフトウエアソースコードファイルに関する目標とする統合パラメータの組を示す。この規則は、統合されたネームスペースの「＼ＣＯＤＥＢＡＳＥ」サブツリー内の任意のファイルに適用され、４でミラーリングを規定し、ストライピングはない。これにより、何百ものファイルがバッチ処理で読み取られている場合の使用パターンであるプログラム編集及び構築中の中庸な性能向上（例えば、４Ｘ）が得られ、また、サーバ故障によるデータ損失に対する優れた保護を提供する。
【０２１４】
最後に、規則１３０５は、「＼ＣＯＤＥＢＡＳＥ」サブツリー内でのストレージスペースの使用を最適化する規則１３０４の変形例である。この規則は、ソースコードディレクトリが、編集処理の副産物であり失われた場合には簡単に再構成することができる中間オブジェクトコードファイル（「ＯＢＪ」のファイル拡張子を伴う）を含むことが多いという事実を認識する。この規則は、規則１３０４の例外、つまり、ファイル名の拡張子「ＯＢＪ」を有する「＼ＣＯＤＥＢＡＳＥ」サブツリー内のいかなるファイルもミラーリング及びストライピングされないということを規定する。規則１３０４及び１３０５は、共に使用された時には、ソフトウエアエンジニアリング部門に対して最適なストレージ特性を容易にもたらすことができる。
【０２１５】
この節では、ファイルスイッチの目標とする挙動、すなわち、複数の独立したファイルサーバを単一の高度に拡張可能な交換ファイルシステムに統合する能力を達成するのに使用される本発明の様々な機構、アルゴリズム、及び、他の要素を説明した。
【０２１６】
以上の説明の多くでは例としてファイルオープン及びファイル書込トランザクション要求が使用されたが、当業者は、これらの説明内容が、本発明の精神から逸脱することなく、他のネットワークファイルプロトコルトランザクションに応用されて簡単に適応させることができることを容易に認識するであろう。
【０２１７】
例えば、ファイル書込トランザクションについて説明したトランザクション統合手法は、ファイル読取トランザクションについては、トランザクション応答メッセージが通常は多重フレームを含むと同時に、要求メッセージが通常は単一のフレームであることを認識しながら、ファイル読取トランザクションに簡単に適応させることができる。ファイルサーバは、読取トランザクションをどのファイルサーバに切り替える必要があるかを判断し、次に、要求をそれらのサーバ（各々について修正されたヘッダを含む）に送ることにより要求を処理することが好ましい。ファイルスイッチは、まずトランザクションの切替先であるファイルサーバの各々から受信した第１フレームにある応答ヘッダを解釈することにより、各々のファイルサーバからの応答を処理することが好ましい。次に、ファイルスイッチは、統合された応答ヘッダを作成し、好ましくはデータの一部分を付してクライアントに返送する。ファイルスイッチがファイルサーバから更に多くのデータフレームを受信すると、更に別のデータフレームがファイルスイッチによりクライアントに送られ、ファイルスイッチは、それがクライアントに送るデータの正しい順番を保証する。また、ファイルスイッチはファイルプロトコル・トランザクションの大半を切り替えるが、ファイルスイッチが単独で全てを処理するクライアントが開始したトランザクションがあってもよいことを認識することが重要である。例えば、このようなトランザクションは、「ＣＩＦＳ  ＳＭＢ-ＥＣＨＯ」及び「ＳＭＢ-ＮＥＧＯＴＩＡＴＥ-ＰＲＯＴＣＯＬ」トランザクションを含むことができ、これらは、ファイルサーバとの即時の対話を必要としないことがある。更に、ファイルスイッチは、独自のトランザクション（必ずしもクライアント要求のトランザクションに応答したものとは限らない）を生成してファイルサーバに提出してもよく、このようなトランザクションは、「ＣＩＦＳ  ＳＭＢ-ＥＣＨＯ」要求やその他を含んでもよい。更に、ファイルスイッチは、ファイル作業（読取／書込など）を、それらに対するクライアント要求を有することなく実行するために、ファイルプロトコル・トランザクションをファイルサーバと共に開始してもよく、１つのこのような例は、ファイルスイッチがファイルを記憶するファイルサーバの数が変わった時にファイルを移動させる（すなわち、読み取って新しい位置に書き込む）ことであろう。
【０２１８】
ファイルスイッチの統合法
更に多くのクライアントが同じファイルスイッチに接続されてネットワークファイルサービスを要求すると、単一のファイルスイッチが障害となってファイルサーバへのアクセスが制限される可能性がある。本発明の１つの特に貴重な態様は、ファイルサーバにアクセスするのに利用可能な統合帯域幅を上げるためにファイルスイッチを統合する能力である。
図１４は、更に別のファイルスイッチ１４００及び１４０１が追加されてファイルスイッチ１００と統合されるネットワークアプリケーションを示す。ファイルスイッチ１００、１４００、及び、１４０１は、層２スイッチ１４０２を使用して個別の「アップリンク」ネットワークポートを通じて互いに接続され、複数の入力及び出力ポートを有する統合されたスイッチ１４０３が形成されることが好ましい。代替的に、スイッチ１００、１４００、及び、１４０１は、フロント側接続１０９、１４０４、及び、１４０５を通じて、又は、サーバ側接続１１４を通じて互いに通信することができる。ファイルスイッチの各々は、サーバ１０１〜１０７の各々に接続されており、これらの接続は、層２スイッチ（図示せず）を通じて容易に為されることが好ましい。
【０２１９】
統合されたファイルスイッチ１４０３は、ファイルサーバ１００〜１０７と共に仮想ファイルサーバ１０８を形成する。クライアントワークステーション１１２及びクライアントアプリケーションサーバ１１３は、ネットワーク１１１及び接続１０９、１４０４、及び、１４０５のうちの１つ又はそれ以上を通じて仮想ファイルサーバ１０８に接続されている。クライアント１１２及びアプリケーションサーバ１１３の立場からは、仮想ファイルサーバ１０８は、接続１０９、１４０４、及び、１４０５を通じてアクセス可能な複数のネットワークポートを有する。当業者は、他のファイルスイッチ統合構成が可能であり、これには、以下に限定されるものではないが、異なる個数のファイルスイッチ、ファイルサーバ、及び、ファイルクライアントを伴う構成が含まれることを認識するであろう。
【０２２０】
全てのファイルスイッチ１００、１４００、及び、１４０１は、同じファイルをクライアントに呈示する。クライアント１１２は、ファイルスイッチのいずれにも接続することができ、同じファイルにアクセスすることができることになる。ファイルスイッチがファイルサーバ１０１〜１０７にはクライアントとして見えることから、ファイルサーバが直接に接続されたクライアントに提供する同期化機構は、複数のスイッチ間のアクセスを同期化するように確かに機能する。
【０２２１】
グループ１４０３の全てのスイッチは、同じ組のファイルサーバに接続されている。各々のファイルサーバの立場からは、各々のファイルスイッチは、ネットワークファイルプロトコルファイルの共用及びロック規則を十分に準拠する別のクライアントである。その結果、切り替えられているファイルトランザクションに対しては、ファイルスイッチ間でいかなる対話又は同期化も行われる必要はない。
【０２２２】
同期化は、スイッチのクライアントにより要求されたネットワークファイル・トランザクションを扱う処理において直接的にスイッチ間の対話を必要とせずに、スイッチの各々とサーバの各々との間で行われる。これにより、制限されない数のスイッチが、クラスターファイルシステムで観察されたものと類似の障害を引き起こすことなく、ファイルサーバの組を共用することができる。当業者は、共用、ロック、及び、便宜的ロックなどの機構は、この３層アーキテクチャにおいても引き続き機能することを認識するであろう。
【０２２３】
設定の共用
複数のスイッチが同じ組のファイルサーバ及びそれらのサーバにより呈示された同じ組のファイルシステムにアクセスした時に使用されることが好ましい１つの機構は、設定の共用である。データの完全性及び適正な作動を保証するために、統合されたスイッチ１４０３内の全てのスイッチ１００、１４００、及び、１４０１は、それらの設定の同期化を維持し、それらは、全て、同じ統合規則を使用して同じ順序にある同じ組のファイルサーバを知っており、同じ方法でファイルシステム統合を行う。ファイルスイッチは、起動時、及び／又は、設定が変わった時に限り、そのような設定情報を交換する。この作業はクライアント要求トランザクションの実行の過程で行われないので、それは障害とはならない。
【０２２４】
統合されたスイッチ１４０３においてこのような共用を準備する１つの方法は、この例においては、グループコントローラとしてのスイッチ１４０１である。システム管理者により行われたものなどの設定の変更は、グループコントローラスイッチ１４０１上に限って行われることが好ましく、グループコントローラは、設定を残りのスイッチ１００及び１４００に配分する。スイッチ１００及び１４０１は、更に、定期的又は起動された時に、設定情報をグループコントローラ１４０１に要求することができる。当業者は、設定をグループ内の全てのスイッチ間で共用する数多くの他の方法が可能であることを容易に認識するであろう。
【０２２５】
負荷平衡
本発明により提供される別の有利な機構は、負荷平衡である。統合されたファイルスイッチ内の全てのファイルスイッチは、同じ組のファイルへのアクセスを提供することから、任意のクライアントをスイッチのいずれかに接続することができる。これにより、全てのクライアントが同じスイッチに接続されないように、クライアントをスイッチ間で配分することができる。これは、各々のクライアントが特定のファイルスイッチを使用するように手作業で構成することにより、又は、各々のクライアントが統合されたファイルスイッチ１４０３に接続しようとした時に自動的にクライアントを配分することにより達成することができる。
【０２２６】
どの特定のスイッチが所定のクライアントに使用されることになるかの選択は、クライアントがスイッチに接続した時に発生する。この関連は、クライアント接続の持続時間中には変わらないことが好ましい。
【０２２７】
負荷配分は、好ましくは、名前（クライアントに対するサーバ名として設定）と特定ファイルスイッチの「ＩＰ」アドレスとの間でマッピングを行う「ＤＮＳ」又は「ＷＩＮＳ」などのネーム解決サービスを通じて行われることが好ましい。
【０２２８】
１つの可能な機構は、グループ１４０３に個別の「ＤＮＳ」サブドメイン（例えば、「ｚｘｌ．ｚｆｏｒｃｅ．ｃｏｍ」）を割り当てることである。ファイルスイッチ１４０１は、グループコントローラとして構成されるが、そのサブドメインの「ＤＮＳ」サーバとしても機能する。サブドメインは、「ａｄｍｉｎ．ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」と「ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」という２つのホスト名を含むことが好ましい。「ａｄｍｉｎ．ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」という名は管理に使用され、ホスト名「ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」は、ファイル供給に使用される（すなわち、これは、クライアントの接続先の名である）。グループコントローラは、常に、「ａｄｍｉｎ．ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」ホストをそれ自体に決定する。グループコントローラは、異なるクライアントが最終的に異なるスイッチ上にあるように、尋ねられるたびに「ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」ホスト名をそのグループの異なるスイッチに決定する。この配分は、無作為でも又は総当り式であってもよく、また、現在の接続ユーザ数及び／又は各スイッチの最近の負荷（ファイルスイッチは、自らの負荷率を定期的にグループコントローラ１４０１に報告することができるので）に基づくものとすることができる。スイッチの各々はまた、サブドメイン内に独自の名（例えば、「ｓｗｉｔｃｈ３．ｚｘｌ．ｚ−ｆｏｒｃｅ．ｃｏｍ」）を有してもよい。
【０２２９】
負荷平衡の別の機構は、各々のファイルスイッチが異なるサーバ名及び「ＩＰ」アドレスを有することである。システム管理者は、異なるグループのクライアントを構成し、異なるファイルスイッチに接続するか（例えば、会社構造に基づいて）、又は、第三者ロードバランサー又は「ＲＲＤＮＳ」などの総当り式「ＤＮＳ」を使用することができる。
【０２３０】
同じグループに属するファイルスイッチにより使用することができる更に別の機構は、同じサーバ名（例えば、「ＣＩＦＳ」サーバ名）を有するスイッチを構成し、その名を個々のホスト名ではなくグループ名として登録させることである。クライアントがその名への接続を確立しようとした時、応答することができるファイルスイッチがクライアント接続を得ることになる。一般的に、これは最小負荷のスイッチであるから、この機構も負荷平衡に使用することができる。
【０２３１】
当業者は、負荷平衡を達成するために他の機構を使用することができることを認識するであろう。また、当業者は、負荷平衡が行われたフロントエンドをファイルスイッチのバックエンド上の独立した接続と組み合わせると、単にファイルスイッチをグループ１４０３に追加することにより、ネットワーク・ファイル・システムの帯域幅の実際的に無制限の拡張が可能になることを認識するであろう。また、このような場合、ファイルスイッチの接続先であるファイルサーバの数を必要に応じて増加し、目標とする総合的な性能を達成することができる。
【０２３２】
フェイルオーバー
本発明により提供される別の機能は、グループ１４０３に参加するファイルスイッチ間のフェイルオーバーである。
【０２３３】
グループコントローラ１４０３は、ハートビート信号を各々に定期的に送ることによりグループ内の全てのファイルスイッチをモニタする。スイッチが所定数の時間切れ再試行の後でも応答しない場合、グループコントローラは、スイッチに故障が発生したと考える。次に、グループコントローラは、故障の発生したスイッチと対話していたクライアントが故障の発生したスイッチの代わりに稼動中のスイッチに到達できることになるように、故障が発生したスイッチの「ＩＰ」アドレスをグループ内の別のスイッチに割り当てることが好ましい。
【０２３４】
このフェイルオーバー機構では、スイッチ故障の場合には、クライアントと故障の発生したスイッチとの間の全ての接続は、あらゆる未処理トランザクションが失われるのと同様に失われることになる。しかし、クライアントは、この状態を示す適切な表示を受信することになる（通常、未処理コマンドの時間切れ、及び／又は、データ送信試行時の「ＴＣＰ」接続リセット）。システムを作動する大半のクライアントは、最小のユーザ介入か、又は、ユーザ介入なしで新しく割り当てられたスイッチに再接続されることになる。
【０２３５】
上述の負荷平衡の節で説明した方法により、グループコントローラが負荷平衡を行う統合されたスイッチについては、故障の発生したスイッチのクライアントは、異なるスイッチに再接続され、そのグループの負荷は均一に維持される。外部の負荷平衡方法が使用された時は、全てのクライアントは、グループコントローラが故障の発生したスイッチの「ＩＰ」アドレス（及び、ホスト名）を引き受けるように選択するスイッチに再接続されることになる。
【０２３６】
スイッチがグループに復帰した時、それは、新しい「ＩＰ」アドレスに割り当てられることが好ましい（現在の接続は、引き継いだスイッチ上の古い「ＩＰ」アドレスに対して存在する場合があるため）。グループコントローラは、グループの平衡が得られるまで新しいクライアント接続をそのスイッチに方向付けする。更に、グループコントローラは、グループ内の他のスイッチが非活性なクライアント接続（もしあれば）のいくつかを落とすように要求することができ、それによってそれらのユーザが活性になった時にはいつでも新たに回復したスイッチに再接続することができる。
【０２３７】
グループコントローラのスイッチに故障が発生する場合に、別のスイッチがバックアップ・グループ・コントローラとして予め指定される（又は、そのように選択される）場合があり、それがこの状態を検出してグループコントローラの役割を引き継ぐことになる。バックアップ・グループ・コントローラは、次に、グループ内の他の全てのスイッチに通知することが好ましく、それによってそれらがバックアップ・グループ・コントローラからのグループ管理機能の要求を開始することができる。また、バックアップ・グループ・コントローラは、グループ内の別のスイッチに（もし存在すれば）、バックアップ・グループ・コントローラの役割を割り当てることができる。グループコントローラの役割は、元のスイッチが作動回復すると元のスイッチに戻される。
【０２３８】
別の可能な故障は、ケーブル又は１４０２などの層２スイッチの故障である。このような故障を処理するために、交換ファイルシステム内のネットワークインフラストラクチャ、すなわち、層２（Ｌ２）スイッチ及びケーブル配線には、「ＩＰ」ネットワーク用の標準的なメッシュ方法を使用して冗長性を持たせることができる。ファイルスイッチは、完全に冗長な配線構成を可能にするために予備ポートを有することが好ましい。
【０２３９】
Ｌ２スイッチ又はファイルサーバまでのケーブルの故障は、接続が冗長でない場合は、そのファイルサーバの故障と同等のものであるが、それ以外の場合は無視することができる（設定によって管理上の警告を送る場合を除く）。クライアント（ＬＡＮ側）までのＬ２スイッチ又はケーブルの故障は、クライアントがファイルスイッチに到達することができないためにファイルスイッチの故障と類似のものである。Ｌ２スイッチ１４０２又はファイルスイッチ間のアップリンク上のケーブルの故障は、スイッチ間の通信をフロント又はバック側ポートを通じて得ることができる限りは故障と見なされない。
当業者は、帯域幅統合、負荷平衡、及び、フェイルオーバーの組み合わせにより、高性能な高利用可能性ネットワーク・ファイル・システムが可能になることを認識するであろう。
【０２４０】
ファイル・スイッチ・アーキテクチャ
図２０は、ファイルスイッチの好ましいアーキテクチャを示す。ファイルスイッチ２０００のアーキテクチャは、３つの平面、つまり、データ平面２００１、制御平面２００２、及び、アプリケーション及びサービス平面２００３に分割されることが好ましい。
データ平面２００１は、フロント側ネットワークインタフェース２００２、バック側ネットワークインタフェース２００３、フロント側「ＴＣＰ／ＩＰ」プロトコルスタック２００４、バック側「ＴＣＰ／ＩＰ」プロトコルスタック２００５、及び、高速経路ハンドラー２００６を含む。制御平面２００２は、ネットワーク・プロトコル・サーバ側ハンドラー２００７、ネットワークプロトコルクライアント側ハンドラー２００８、及び、ファイルシステムアグリゲータ２００９を含む。アプリケーション及びサービス平面２００３は、高度なサービス（いくつか挙げると、使用法追跡及び適応ストレージ管理など）に関する様々なハンドラー２０１０を含む。
【０２４１】
クライアントコンピュータから来るファイルプロトコル・トランザクションの要求は、ネットワークインタフェース２００２上に受信される。「ＴＣＰ」スタック２００４は、「ＴＣＰ／ＩＰ」プロトコルを処理し、クライアンとの確実な接続及び適正なデータの順番を保証する。この要求は、高速経路トランザクション（読取及び書込など）として指定することができるネットワークファイルプロトコルトランザクションに対してトランザクション切り替えを行う高速経路ハンドラー２００６により更に処理することができる。代替的に、低速経路トランザクション（ファイル削除など）として指定することができるトランザクションについては、この要求は、ネットワークファイルプロトコルのサーバ側を処理して要求をファイルシステムアグリゲータ２００９に転送するサーバ側ハンドラー２００７により更に処理することができる。
【０２４２】
高速経路トランザクションは、高速経路ハンドラー２００６により切り替えられ、高速経路ハンドラー２００６は、更に、バック側「ＴＣＰ」プロトコルスタック２００５を通じてトランザクションメッセージを送る。バック側「ＴＣＰ」プロトコルスタック２００５により、サーバは、サーバを目的地とした任意のメッセージの全ての部分を適切な順序で、かつデータの損失及び複写なく確実に受信する。バック側「ＴＣＰ」プロトコルスタック２００５は、バック側ネットワークインタフェース２００３を通じてフレームをファイルサーバに送信する。高速経路ハンドラー２００６は、切り替えられているネットワークファイルプロトコルの一部分を理解して実行する必要があるであろう。高速経路ハンドラー２００６は、完全なトランザクションメッセージが到着するのを待つことなく、直ちに「ＴＣＰ」スタックのいずれかから受信した各々のフレームを処理することが好ましい。
【０２４３】
低速経路トランザクションのネットワークプロトコル要求は、サーバ側ハンドラー２００７により復号化され、サーバ側ハンドラー２００７は、ネットワークファイルプロトコルのサーバ側を実行する（すなわち、通常「ＣＩＦＳ」、「ＮＦＳ」、又は、類似のサーバに送られる要求を理解する）ことが好ましい。要求は、更に、ファイルシステムアグリゲータ２００９により処理され、ファイルシステムアグリゲータ２００９は、トランザクション切替及び統合を行う。次に、ファイルシステムアグリゲータ２００９は、クライアント側ハンドラー２００８を使用して要求をファイルサーバに送り、クライアント側ハンドラー２００８は、ネットワークファイルプロトコルのクライアント側を実行する（すなわち、一般的にネットワーク・プロトコル・クライアントにより出されたネットワークファイルプロトコル要求を出す）。低速経路トランザクションを処理するこの方法の利点の１つは、ファイルシステムアグリゲータを、切り替えられている特定のネットワークファイルプロトコル（及び、その特定のバージョン）からほとんど独立したものとすることができ、詳細の大半は、サーバ側ハンドラー２００７及びクライアント側ハンドラー２００８により処理することができるということである。
【０２４４】
サーバからのネットワークプロトコル応答は、上述の順番の逆の順番で処理される。
管理、スイッチ間の設定の同期化、データ移送、及び、その他などの高度な機能は、アプリケーション及びサービス平面２００３における別のハンドラー２０１０として実施されることが好ましい。
【０２４５】
当業者は、このアーキテクチャの様々な変形例が、本発明の精神から逸脱することなく、本発明のファイルスイッチに対して良好に機能することができることを容易に認識するであろう。例えば、より多くのネットワークインタフェース２００２及び２００３を追加することができ、また、２つのネットワークインタフェースは、クライアントトラヒック及びサーバトラヒックを「ＴＣＰ」プロトコルスタックにより分離することができる単一のネットワークインタフェースと置き換えることができる。「ＴＣＰ」プロトコルスタック２００４及び２００５は、互いに融合させることができる（多くの従来のコンピュータアーキテクチャでは、複数のネットワークアダプタを処理する単一「ＴＣＰ／ＩＰ」プロトコルスタックがある）。
【０２４６】
更に、複数のネットワークファイルプロトコル又はその異なるバージョンを処理するために、複数のサーバ側ハンドラー２００７を追加することができる。同様に、ファイルサーバとの対話時に複数のネットワークプロトコル又はその複数のバージョンを処理するために、複数のクライアント側ハンドラー２００８を追加することができる。
【０２４７】
「ＤＨＣＰ」、「ＤＮＳ」、負荷平衡、コマンドライン管理及び／又はウェブベースの管理、及び、「ＳＮＭＰ」などの様々な他のサービスを上述のアーキテクチャに追加することができる。
【０２４８】
上述のアーキテクチャの実施は、多くの可能な方法で準備することができる。例えば、ネットワークインタフェースは、ハードウエアにおいて実施することができ、残りのデータ平面及び２つの残りの平面は、ソフトウエアにおいて完全に実施される。代替的に、データ平面は、ハードウエアにおいて実施することができ（例えば、「フィールドプログラマブル・ゲートアレー」、「アプリケーション特異集積回路、スイッチ・ファブリック、及び、ネットワークプロセッサなどを使用して）、制御平面及びアプリケーション平面は、ソフトウエアにおいて実施することができる。それに加えて、制御平面は、更に、ハードウエアにおいて実施又は加速することができる。更に、残りの平面の機能性（セットアップ、初期化、及び、他の低速機能など）をソフトウエアにおいて維持しながら、加速された機能をハードウエアにおいて提供することにより、特定の平面（例えば、データ平面又は制御平面）の一部分を実施することは有利であろう。
【０２４９】
図２１は、ファイルスイッチを実施するための第１の可能なハードウエアアーキテクチャを示す。この例においては、ファイルスイッチの実施は、汎用コンピュータハードウエアに基づいている。ファイルスイッチ２１００は、プロセッサ２１０１、メモリ２１０２、周辺相互接続バス２１０４、及び、１つ又はそれ以上のネットワーク・インタフェース・カード２１０３を含むことが好ましい。
【０２５０】
図２２は、ファイルスイッチを実施するための別の可能なハードウエアアーキテクチャを示す。この例においては、ファイルスイッチの実施は、ネットワークスイッチに一般的なハードウエアアーキテクチャに基づいている。スイッチ２２００は、プロセッサ２２０１、メモリ２２０２、スイッチ・ファブリック２２０３、複数のフロント側ネットワークインタフェース２２０４、及び、複数のバック側ネットワークインタフェース２２０５を含むことが好ましい。
【０２５１】
当業者は、ファイルスイッチを実施するための様々な他のアーキテクチャが可能であることを容易に認識するであろう。更に、ファイルスイッチを実施する際に行われる特定の選択の大部分（上述のものなど）は、好ましくは、ファイルスイッチの性能及びコスト目標によって推進されるが、全ての様々な実施は本発明の精神の範囲に含まれる。
【０２５２】
交換ファイルシステム
本発明の別の態様は、交換ファイルシステムである。交換ファイルシステムは、単に、１つ又はそれ以上のファイルスイッチ及び１つ又はそれ以上のファイルサーバを含むネットワークと定義することができる。
【０２５３】
交換ファイルシステムは、ファイルをディスクストレージを共用するための方法として露出するので、ファイルシステムである。また、交換ファイルシステムは、ネットワークファイルプロトコルを通じてネットワーク・ファイル・システムサービスを行う、つまり、ファイルスイッチがネットワーク・ファイル・サーバとして機能し、かつファイルスイッチのグループが単一ファイルサーバとして見えるので、ネットワーク・ファイル・システムである。
【０２５４】
交換ファイルシステムは、複数のファイルサーバのネームスペースを統合するので分散ファイルシステムである。また、単一ネットワークファイルクライアントの要求を満足させるために複数のファイルサーバを並行に利用することができるので並行ファイルシステムである。
従って、交換ファイルシステムは、新しい形式の分散並行ネットワークファイルシステムである。
【０２５５】
図１５は、その多くの構成及びアプリケーションを含む交換ファイルシステムを示す。この例示的な交換ファイルシステムは、以下の要素、つまり、ファイルサーバの２つのアレー（「ＮＡＳ」アレーともいう）１５１０及び１５１１に接続され、また、ネームスペースだけにより統合する（ファイル統合を行わない）一般的にアーカイブ及び他のプレファイルスイッチコンテンツを含むレガシーファイルサーバ１５１３に接続された、グループ１５０９に統合されたファイルスイッチ１５０８から成る。また、ファイルスイッチグループ１５０９は、「ＮＡＳ」アレー１５１５に接続され、また、層２スイッチ１５１２を通じてグループ１５０９に接続されたファイルスイッチグループによりもたらされた別の交換ファイルシステムのネームスペースを統合する。
【０２５６】
グループ１５０９のサービスは、クライアント１５０６、管理ワークステーション１５０７、及び、大都市圏ネットワーク１５０４への接続から成るネットワーク１５０５に提供される。大都市圏ネットワーク１５０４は、遠隔ＬＡＮ１５００及びそのクライアント１５０１に対してグループ１５０９により利用可能にされるファイルサービスをもたらす。これらのサービスへのアクセスを向上させるために、遠隔ＬＡＮ１５００はまた、グループ１５０９のゲートウェイとして機能して「ＮＡＳ」アレー１５０３に対してローカルにファイルをキャッシュするファイルスイッチ１５０２を含む。
【０２５７】
トポロジー
交換ファイルシステムは、ファイルシステム統合の多くの組合せを提供し、異なるトポロジーをサポートする。
【０２５８】
利用可能なトポロジーの１つは、仮想化である。仮想化においては、交換ファイルシステムは、他のサーバ上のファイルを更に統合することなく単一ファイルサーバ１５１３により露出されたネームスペースを統合する。これに関して利用可能な機構の１つは、本明細書で説明するネームスペース統合技術である。仮想化は、既存のファイルサーバを交換ファイルシステムのクライアントに利用可能にし、論理ネームスペースに含めることを可能にする。これは、交換ファイルシステム（ＳＦＳ）の導入を容易にし、導入に向けた漸進的な手法を提供する。
【０２５９】
別の利用可能なトポロジーは、「ＮＡＳ」アレーである。交換ファイルシステムは、「ＮＡＳ」アレーとして指定された、好ましくは同様の容量及び性能特性を有する一組のファイルサーバ１５１０を有することができる。「ＳＦＳ」に参加するファイルスイッチは、上述のディレクトリ、ファイルオブジェクト、及び、データ統合機構を使用して、ファイルを「ＮＡＳ」アレー内のファイルサーバに亘って配分する。「ＮＡＳ」アレーにより、高性能及び高利用可能性が得られる。複数の「ＮＡＳ」アレーを同じ「ＳＦＳ」において構成することができ、そのネームスペースは、仮想化されたファイルサーバと共に統合されて統一ネームスペースを呈示することができる。
【０２６０】
更に別の利用可能なトポロジーは、カスケードである。カスケード処理された構成においては、１つ又はそれ以上の交換ファイルシステムを別の交換ファイルシステム内で接続することができ、実質的にこの他の交換ファイルシステムにおけるファイルサーバの役割を果たす。この例において、ファイルスイッチ１５１４及び「ＮＡＳ」アレー１５１５は、小規模交換ファイルシステムを備え、この交換ファイルシステムは、グループ１５０９により呈示された交換ファイルシステムのネームスペースにおいて統合される。ファイルスイッチ１５１４は、ファイルスイッチ１５０９に対してはファイルサーバとして見えることから、後者は、仮想化されたサーバ１５１３と同じ方法で、前者により提供されたネームスペースを統合することができる。当業者は、スイッチ１５１４及び「ＮＡＳ」アレー１５１５を備えた交換ファイルシステムの複数のインスタンスが存在してもよく、グループ１５０９内のスイッチがデータ統合やディレクトリ統合などを含め通常のファイルサーバを統合することができる任意の及び全ての方法で、グループ１５０９内のスイッチにより統合されてもよいことを容易に認識するであろう。
【０２６１】
１つの他のトポロジーは、ゲートウェイである。好ましくは独自の「ＮＡＳ」アレー１５０３を有するファイルスイッチ１５０２は、スイッチにローカルに接続されたクライアントへのゲートウェイとして機能し、また、グループ１５０９により利用可能にされたファイルサービスへのアクセスを提供する。このトポロジーの利点は、「ＭＡＮ」１５０４などの１５０９と１５０２との間の接続が、ローカルネットワーク１５００及び１５０５よりも低い帯域幅を有することができるということである。ゲートウェイというトポロジーにより、通常はグループ１５０９により露出されたファイルシステム上にあるゲートウェイスイッチ１５０２は、「ＮＡＳ」アレーファイル上でローカルにキャッシュすることができる。スイッチ１５０２は、１５０９に対して単に別のクライアントとして見えることから、スイッチ１５０２がキャッシュを提供するのに、全てのロック、オプロック、及び、他のクライアントセマンティクスを利用することができる。
【０２６２】
例えば、クライアント１５０１がファイルオープントランザクションをファイルスイッチ１５０２に要求した時、ファイルスイッチ１５０２は、トランザクションをグループ１５０９内のファイルスイッチ１５０８の１つに転送する。トランザクションが問題なく完了した場合、スイッチ１５０２は、要求されたファイルの排他的ロック又は便宜的ロックを取得してファイルをローカル「ＮＡＳ」アレー１５０３にコピーすることができる。たとえクライアント１５０１がファイルを閉じたとしても、スイッチ１５０２は、ロックを維持するためにファイルを依然としてグループ１５０９上で開いた状態に保つことができる。クライアント１５０１（又は、１５００「ＬＡＮ」上の別のクライアント）が同じファイルに対してオープンを要求した場合、スイッチ１５０２は、グループ１５０９と対話することなく（また、より低速のネットワーク１５０４を通じたいかなる通信もなく）、その要求を満足させることができる。１５０２がキャッシュされたファイルを維持する限り、更に別のいかなる読取及び書込要求も、より低速のネットワーク１５０４及びグループ１５０９にアクセスすることなく「ＮＡＳ」アレー上でローカルに満足させることができる。
【０２６３】
クライアント１５０６が次に同じファイルに対してオープンを要求した場合、グループ１５０９は、スイッチ１５０２により維持されている便宜的ロックを破壊しようと試みることができ、このような場合、スイッチ１５０２は、１５０９に全てのキャッシュ済みの変更内容を再度書込み、ローカルにファイルをキャッシュするのを停止することになる。当業者は、ファイルシステム及びファイルデータへの最適なアクセスを提供する一方で、キャッシュのコヒーレンシーを維持する他の機構も可能であることを認識するであろう。ゲートウェイトポロジーは、「ストレージ・サービス・プロバイダ（ＳＳＰ）」会社により提供されるストレージユーティリティのような遠隔ストレージへのアクセスを可能にし、相互接続への帯域幅要件を低減する一方で、高性能データアクセスを維持する。このトポロジーはまた、ローカルキャッシュを伴う地球規模の分散ファイルシステムを可能にする。
【０２６４】
クライアントから見た交換ファイルシステム
１５０６などのネットワーク・プロトコル・クライアントの立場からは、交換ファイルシステムは、複数のネットワークインタフェースを伴う単一ファイルサーバとして見える。図１６は、交換ファイルシステムと単一ファイルサーバとの間の類似性を示す。ネットワーククライアントは、インタフェース１６０３を通じて単一ファイルサーバ１６０１に接続されるように、インタフェース１６０２を通じて交換ファイルシステム１６００に接続される。
【０２６５】
交換ファイルシステムは、単一のネームスペースを提供することが好ましい。これによって、ネットワーク・プロトコル・クライアントは、「ＣＩＦＳ」及び「ＮＦＳ」プロトコルなどのファイルサーバにアクセスするための広く標準化されたネットワークファイルプロトコルを使用する標準的なクライアント・ソフトウエアを用いることができる。標準的なファイル・クライアント・ソフトウエアの交換ファイルシステムにアクセスする能力は、導入を簡素化し、また、交換ファイルシステム機構及びトポロジーの変更を全てのクライアントに対してガラス張りの状態で実行することを可能にする。
【０２６６】
管理者から見た交換ファイルシステム
管理者から見た交換ファイルシステムは、ある程度まで、クライアントから見たものと類似である。大半の作動については、管理者は、まるで単一の高容量、高性能、かつ、利用可能性の高いファイルサーバ１６０１であるかのように交換ファイルシステム１６００を見る。管理及び再構成という目的のためには、それは、単一のファイルサーバとして見えることが好ましい。ファイルスイッチは、単一の「ＣＩＦＳ」又は「ＮＦＳ」ファイルサーバがするように、同じファイルサーバ管理プロトコル（「ＭＳＲＡＰ」など）をサポートすることが好ましい。交換ファイルシステムは、それらのクライアントに対して、統合されたネームスペースにおける共用／マウントポイントを露出するように構成することができる。
【０２６７】
管理者は、個々のファイルサーバ（仮想化トポロジーを使用して）と新しい「ＮＡＳ」アレーとを追加し、同じく既存の「ＮＡＳ」アレーに対して複数のファイルサーバを追加又は除去することができる。管理者が１つ又はそれ以上のファイルサーバを既存の「ＮＡＳ」アレーに追加する場合、ファイルスイッチは、新たに追加されたサーバを発見し、好ましくは管理者の要求があり次第、新たに追加されたサーバを含め、全てのサーバに亘ってファイル及びデータを再配分することができ、従って、ファイルシステムの容量及び性能が拡張される。管理者が１つ又はそれ以上のファイルサーバを「ＮＡＳ」アレーから除外したいと思った場合、ファイルスイッチが指定されたサーバを解放する（「ＮＡＳ」アレーに残るファイルサーバにファイルを再配分することによって）ように要求することができる。その処理が完了すると、ファイルスイッチは、選択されたファイルサーバが解放され、データ損失なく除外することができることを管理者に通知する。
【０２６８】
交換ファイルシステムは、仕事を多くのファイルスイッチ及びファイルサーバ間で配分することによって高い有用性をもたらす。ファイルサーバ又はファイルスイッチに故障が発生しても、一般的にデータの損失又はアクセスの損失は引き起こされない。管理者は、故障の通知を受けることができ、故障の発生した構成要素を交換又は補修する。
交換ファイルシステムは、アクセスパターンを追跡し、統計学的情報を管理者に報告することができることが好ましい。この情報に基づいて、管理者は、「ＮＡＳ」アレー及びファイルスイッチを追加又は再構成することにより、及び、ファイルスイッチに対する統合規則を変更することにより、交換ファイルシステムの性能及びストレージ容量使用を調整することができる。
【０２６９】
「ＳＦＳ」における拡張
従来技術によるソリューションと異なり、交換ファイルシステムは、固有の制限なく複数の方向に独立して拡張する。
【０２７０】
「ＳＦＳ」は、より多くのファイルサーバを「ＮＡＳ」アレーに追加し、ファイルを全てのファイルサーバに亘って配分することにより容量及び性能を拡張する。それは、接続されたグループにより多くのファイルスイッチを追加することによりアクセス帯域幅を拡張して同じ組のファイルサーバにアクセスし、より広いアクセス経路（複数のネットワーク接続）をもたらす。
【０２７１】
「ＳＦＳ」はまた、カスケードされたファイルスイッチ（又は、交換ファイルシステム）及びゲートウェイファイルスイッチを追加することにより、拡張して地理的に分布する。
【０２７２】
利用可能性に関する問題
交換ファイルシステムは、利用可能性の高いファイルサービスをネットワーククライアントに提供する。データ及びアクセス損失を伴わないファイルサーバ及びファイルスイッチの故障については、本明細書で既に説明している。
【０２７３】
高い利用可能性を得るための別の機構は、遠隔非同期ミラーリングである。ファイルスイッチ（又は、ファイルスイッチのグループ）はまた、ファイルトランザクションを受信して処理すると、ファイルシステムを修正する（ファイル作成、書込み、及び、削除などのような）トランザクションを待ち行列に入れ、非同期に遠隔位置に送ることができ、そこで、別の交換ファイルシステム又は通常のファイルサーバは、交換ファイルシステム（又は、その一部分）のミラーを維持することができる。トランザクションが非同期に遠隔サイトに送られるという事実により、ローカルクライアントは、遅延なく作業を継続することができ、一方、ファイルシステムは、壊滅的なネットワークサイト故障の場合のデータ損失を最小限に抑えるために遠隔コピーと同期化される。
【０２７４】
高度な能力
使用法追跡
ファイルスイッチは、ファイルクライアントとファイルサーバとの間の全てのプロトコルトランザクションを処理する。ファイルスイッチは、３層アーキテクチャの中間位置にあり、その結果、様々なファイル使用法情報を回収することができる状態にある。このような情報の例には、（ａ）ログイン及びログアウト回数、及び、ログイン時間、（ｂ）アクセスしたファイル数、（ｃ）読み取られたデータ量及び書き込まれたデータ量、（ｄ）好ましくはトランザクション形式により内訳表示されたネットワークファイルプロトコル・トランザクション数、（ｅ）所定のユーザによりアクセスされた区域又はサブツリー、及び、（ｆ）所定のユーザ、ユーザのグループ、又は、全てのユーザから所定のファイル及びディレクトリへのアクセス回数が含まれる。
【０２７５】
ファイルスイッチは、この情報を回収し、それをネットワーク管理者、ユーザ、又は、何らかの形態の自動化コンピューティングシステムに対して利用可能にする。
【０２７６】
本発明の１つの態様は、１つ又はそれ以上のファイルスイッチが使用法情報を回収してこの情報を請求書作成システムに送るファイルサービス請求書作成システムである。情報の回収は、以下の段階を含むことが好ましい。
【０２７７】
１．グループ内のファイルスイッチの各々は、使用法情報を回収してグループコントローラとして機能するファイルスイッチに定期的に報告する。
２．グループコントローラは、定期的にこの情報を請求書作成アプリケーションに送る（自動的又は要求があり次第）。
３．請求書作成アプリケーションは、この情報の一部又は全てを用いて、明細書、及び、必要に応じて所定期間の請求書を作成する。明細書は、ファイルサービスにアクセスしたユーザ数、アクセスされたファイル数、実行された読取、書込、及び、他のトランザクション数、及び、読取及び／又は書込されたバイト数を提供することが好ましい。明細書はまた、行われた特定のファイルアクセス、アクセスが行われた時間、及び、転送されたデータ量を記載する電話料金請求書と類似の書式で作成することができる。
【０２７８】
本発明の別の態様は、ネットワーク・プロトコル・クライアントへの保証されたサービス品質、及び、異なるネットワーククライアント間の優先順位を提供するシステムである。本システムは、以下を備えることが好ましい。
【０２７９】
１．好ましくはファイルスイッチのメモリ内にある設定データ。設定データは、ユーザ、ユーザのグループ、ファイル及び／又はファイルのグループに適用されるネットワークアクセス限界値（トランザクション／秒、及び／又は、交換されるデータ量／秒）を指定する。設定データは、好ましくは、指定されたユーザのために作業を要求するネットワーククライアント間で適用されることになる優先順位を更に指定し、各ユーザ又はユーザのグループには、優先順位レベルが割り当てられることが好ましい。設定データは、ファイルスイッチのメモリ内にあってもよいし、又は、「活性ディレクトリ」又は「ＬＤＡＰ」などの外部サービスから取得してもよい。
２．ネットワークファイルプロトコル・トランザクションの処理中、ファイルスイッチは、優先順位の高いトランザクションが優先順位の低いトランザクションよりも前に実施される同じ機構を使用するなどにより、より高い優先順位レベルを有するユーザのためにトランザクションを要求するクライアントに優先順位を与える。
３．ファイルスイッチは、更に、各々のクライアントからのトランザクション／秒、及び、読取及び書込データ量／秒を測定する。クライアントが設定データにおいて指定された限界値（そのためにトランザクションが要求されるクライアント又はユーザに対する）を超えた場合、ファイルスイッチは、トランザクション及びデータ交換の割合が指定された限界値内に収まるようにトランザクションの実施を遅らせる。従って、接続されたクライアントの各々の限界値の合計がスイッチ（又は、スイッチのグループ）及びスイッチに接続されたファイルサーバの容量を超えないように設定データが適切に指定されている場合、各々のクライアントが保証された最小トランザクション又はデータ交換速度を確実に得るようにすることが可能である。
４．この機構の修正は、スイッチ及び／又はファイルサーバに掛かる負荷がシステムの制限値に近づいた場合に限り、ファイルスイッチが限界値を課すことを開始するためのものである。
５．更に別の修正は、ファイルシステムにログインすることができるユーザ数を制限するためである。ログインしたユーザの各々について設定された限界値の合計がファイルシステム（ファイルスイッチ及びファイルサーバ）の容量を超えた場合、新しいユーザは、接続／ログインが拒否されることになる。
【０２８０】
当業者は、使用法追跡情報の他の有利な用途があり、それが本明細書で説明するものから容易に得られることを認識するであろう。
【０２８１】
適応ストレージ管理
ファイルスイッチはまた、個々のファイル及びファイルグループへのアクセスに関する情報を回収することができる。回収される情報には、読取のためにファイルにアクセスする最新の日付、ファイルが修正された最新の日付、ファイルに同時にアクセスするネットワーククライアントの数、ファイルに関して要求されたファイル作業の形式及び頻度、及び、主要なアクセスパターン（連続、無作為、及び、何らかの連続性を伴う無作為などのような）を挙げることができる。情報は、更に、ファイル形式（拡張子）単位、及び／又は、ファイルシステム内のルート経路単位で統合することができる。
【０２８２】
この情報に基づいて、ファイルシステム内のサブシステムは、所定のファイル又はファイルの組をファイルサーバ上で配分すべき異なる方法を判断することができる。その判断は、特定のファイルに対するものか、又は、統合規則（本明細書で説明するものなど）を導出することによるものか、又は、既存の統合規則の統合パラメータの修正とすることができる。ファイルスイッチは、新しい規則を新しく作成されたファイルに限り使用することができ、新しい規則に従って既存のファイルを再配分することができる。
【０２８３】
回収されたアクセス情報に基づいて新しい規則を判断するという作業は、この情報に基づいて行動する管理者により、又は、回収したアクセス情報に対して分析を行って新しい規則を判断する物理的に分離した自動システムにより、スイッチ上で行うことができる。
【０２８４】
ファイルスイッチのこの機能により、ストレージネットワークの効率が向上する。それは、より少ないコピー数とこのようなファイルにより使用される容量を最適化する統合機構とを用いて、古くてめったに使用されないファイルを保持することを可能にする。それは、新しく頻繁にアクセスされるファイルが、より多くのファイルサーバ間に配分され、並行してアクセスすることができる多数のコピーを有し、ファイルサーバに掛かる負荷を最適化してクライアントに対するアクセス性能を向上させる統合パラメータを有することを可能にする。
【０２８５】
この機能はまた、このファイルの組に関して回収されたアクセスパターンに依存して、最善の適用可能統合規則で異なるファイルの組を最適化することを可能にする。例えば、データベースファイルは、排他的アクセスのために頻繁にオープン状態とし（すなわち、単一のネットワーククライアントにより）、無作為な位置でアクセスすることができ、低いミラー数（例えば、２）及びストライプサイズが大きくて低いストライプ数がこのファイル形式に最適であろう。「ＭＰＥＧ」ムービーなどのビデオストリーミングファイルについては、一般的なアクセスパターンは、そのファイルの異なる区域から同時に順番に読み取る複数の同時読取装置としてもよい。このようなファイルについては、更に良好な統合パラメータセットは、高いミラーコピー数、高いストライプ数、及び、比較的小さいストライプサイズを含むことができる。
【０２８６】
更に、ファイルサーバのストレージ容量の現在の利用量及びその相対的な負荷は、回収された情報に含めることができる。この情報は、ストレージ容量のより良い利用法及びファイルサーバに掛かる更に均一な負荷を達成するために、ファイルスイッチが使用し、ファイルサーバ間のファイル配分を変更することができる。
【０２８７】
既存の階層的ストレージ管理システムと異なり、このシステムは、新しく頻繁にアクセスされるファイルと同じ形式のストレージ上に古くて頻繁にアクセスされないファイルを保持すると同時に、古くて頻繁にアクセスされないファイルを記憶するコストを低減し、新しく頻繁にアクセスされるファイルに対するアクセス帯域幅を最適化する。
【０２８８】
この特徴の重要な要素は、アクセスデータの自動回収、ファイル記憶方法を変更する決断、及び、この決断の実施である。一組として、これらは、ファイルスイッチ及びファイルサーバが、最適又はほぼ最適な利用法を伴うストレージネットワークを提供し、同時にシステムの管理コストを低減することを可能にする。これらの利点の全ては、ネットワーククライアント及びネットワークサーバ上に追加のソフトウエアをインストールして維持する必要もなく得ることができる。
【０２８９】
安全な遠隔ストレージ
ネットワーククライアントとネットワークサーバとの間にデータパス上のファイルスイッチを有する別の利点は、ファイルスイッチが、ファイルに読取られている及び書き込まれているデータを修正することができるということである。
【０２９０】
例えば、図１５のファイルスイッチ１５０２は、１つ又はそれ以上の暗号化キーで構成することができる。クライアント１５０１は、ファイル書込トランザクションを要求すると、ファイルスイッチ１５０は、データが最終的には「ＮＡＳ」アレー１５１０上に暗号化された状態で記憶されるようにトランザクションのペイロードを暗号化する（尚、読取及び書込要求のトランザクションペイロードとは、ファイルのコンテンツを表すデータである）。クライアント１５０１がファイル読取トランザクションを要求した時、ファイルスイッチ１５０１は、各々のトランザクションの応答データを受信すると、トランザクションのペイロードを暗号解読し、トランザクションを予期するクライアント１５０１にペイロードを転送する。好ましい暗号化技術は、「データ暗号化規格（ＤＥＳ）」などの対称キー暗号化である。
【０２９１】
その結果、クライアントは、まるでネットワーク１５００にローカルに取り付けられた単一ファイルサーバ上のファイルシステムにアクセスしたかのようにファイルシステムにアクセスすることができ、一方、データは、実際には「ＮＡＳ」アレー上の暗号化された状態で記憶されている。尚、これは、クライアント１５０１、ファイルスイッチ１５０８、及び、「ＮＡＳ」アレー１５１０にはガラス張りの状態で行われる。
【０２９２】
この暗号化の方法、及び、この暗号化を行う装置及びシステムの１つの利点は、組織（例えば、企業）が、ストレージを他の組織（例えば、ストレージ・サービス・プロバイダ又はストレージユーティリティ）に外部委託することができるということである。ファイルコンテンツを暗号化することができるので、企業に属するデータの秘密のセキュリティを高めることができ、また、ストレージユーティリティの導入が容易になる可能性がある。尚、暗号化キーは、好ましくは企業の敷地内にあるファイルスイッチ１５０２内でのみ構成され、その企業のみが物理的にそれにアクセスすることができることが好ましく、その結果、暗号化キーのセキュリティを保証することができる。同時に、ファイルシステムの論理構造は無傷であることから、ストレージユーティリティは、障害なしにデータを管理、バックアップ、及び、回復することができる。
【０２９３】
更に、ファイルスイッチは、同じ又は異なる暗号化キーを使用してファイル名及びディレクトリ名を暗号化することができる。ファイル名及びディレクトリ名は、顧客名などの秘密情報を含む可能性があることから、これにより更にセキュリティが高まることになる。
【０２９４】
ファイルスイッチ１５０２は、複数の暗号化キー（異なるユーザグループに対する異なるキーなど）を含みかつ使用すると同時に、ファイルスイッチ１５０２の代わりに、全てが好ましくは同じ暗号化キーで構成された複数のスイッチ（ファイルスイッチのグループ）を有することが可能である。更に、ファイルスイッチは、データの暗号化及び暗号解読を加速する特化されたハードウエアを利用することができる。当業者は、他のトポロジー及び暗号化アルゴリズムが本発明の精神から逸脱することなく可能であることを認識するであろう。
【０２９５】
スナップショット
スナップショットは、任意の瞬間的な時間での任意のファイル、ファイルシステムの一部分、又は、ファイルシステム全体のビューである。スナップショットは、スナップショットが為された時から除去又は改変されたデータを取得する能力及び多くの他の用途を提供するバックアップとして、バックアップの供給源として（従って、生データではなく、データの定常な変更のないコピーからのバックアップを可能にする）使用することができる。
【０２９６】
本発明はまた、交換ファイルシステムにおけるファイルのスナップショットを作成するための機構を提供する。これを達成する１つの方法は、全てのファイルに対してミラーを有することである。簡素化のために、交換ファイルシステム内の全てのファイルは、ストライピングされず、３部のコピーにミラーリングされると仮定する。スナップショットを撮るために、ファイルスイッチは、ここで全てのファイルが２部のみにミラーリングされているとみなされ、第３のコピーが手付かず（凍結）で残るように内部的に統合規則を変更しなければならない。ファイルの読取又は修正を要求するクライアントは、２つのコピーのみにアクセスすることができることになる。スナップショットの読取を要求するクライアントは、第３のコピーにアクセスすることができることになる。このようにして、たとえクライアントがファイル（最初の２つのファイル）を修正し続けることができるとしても、第３のコピーは、規則が変更された時点の状態のままで残る。
【０２９７】
上述のように規則を変更する前に、スイッチは、任意の現在未処理のトランザクションが完了するのを待って、新たに要求されたトランザクションを（実施せずに）待ち行列に入れることが好ましい。全ての未処理トランザクションが完了すると、ファイルスイッチは、規則を変更し、待ち行列に入れられたトランザクションの実施を開始する。この機構により、更に、スナップショットの一貫性が保証される（すなわち、スナップショット内の全てのファイルが正確に同じ時間現在のバージョンを確実に有するようになる）。
【０２９８】
グループ内の複数のファイルスイッチは、同じ組のサーバに接続されて複数のクライアントによりアクセスされている複数のファイルスイッチの場合でさえも、スナップショットを一貫したものとするように、規則修正の瞬間を同期化することができる。
【０２９９】
ジャーナル処理バックアップ
本発明の別の態様は、ジャーナル処理を通じてファイルシステムデータをバックアップするシステムである。ジャーナル処理バックアップは、ファイルシステムのファイルの配分先ファイルサーバ（一次ファイルサーバ）に加えて、二次ファイルサーバ（又は、別の交換ファイルシステム）にも接続されているジャーナル処理ファイルスイッチにより行われる。
【０３００】
ジャーナル処理ファイルスイッチは、ファイルシステムを修正する（ファイル作成、ファイルへのデータ書込み、ディレクトリ削除などのような）破壊的トランザクションと、ファイルシステムを改変しない（ファイル読取、ディレクトリ列挙、既存ファイルのオープンなどのような）非破壊的トランザクションとを区別する。
【０３０１】
ファイルクライアントが破壊的トランザクションを要求した時、ジャーナル処理ファイルスイッチは、トランザクションをその組の一次ファイルサーバに切り替え（非ジャーナル処理ファイルスイッチと同様に）、更に、トランザクションを二次ファイルサーバに送る。ジャーナル処理ファイルスイッチがトランザクション応答を一次サーバから受信した時、そのクライアントのトランザクションを完了し、二次ファイルサーバに関するトランザクションは、その後に完了することができる。ファイルクライアントが非破壊的トランザクションを要求した時、ジャーナル処理ファイルスイッチは、二次ファイルサーバを巻き込みことなく、その組の一次ファイルサーバのみにトランザクションを切り替える。
【０３０２】
その結果、ファイルシステムを変更する全ての作業は、二次ファイルサーバに送られ、それで、二次ファイルサーバ上のファイルシステムは、その組の一次ファイルサーバ上に記憶されたファイルシステムをミラーリングする。これにより、破壊的な故障（一次サーバのその組全体の物理的な破壊など）の場合は、特に二次サーバが物理的に遠隔位置に記憶されている場合にデータの冗長性が高まる。
【０３０３】
尚、二次サーバの方が低速であり、低帯域幅で高い待ち時間のネットワークを通じてファイルスイッチに接続されている場合があるが、ファイルスイッチは、二次サーバがトランザクションを完了するまでトランザクションの完了を送らせないことから、クライアントが利用可能な性能には影響がない。実際に破壊的なのはファイルシステムトランザクションの一部分にすぎないので、トランザクションの大部分は、二次サーバには負荷を課すものではない。より高い帯域幅が二次サーバに必要とされた場合には、カスケード処理された交換ファイルシステムと入れ換えることができる（本明細書で説明するように）。
【０３０４】
代替的に、ジャーナル処理ファイルスイッチ（又は、ジャーナル処理ファイルスイッチ及び二次サーバ間に挿入された別個の装置）は、二次サーバ上で実施するのではなく、ログファイルに破壊的トランザクションを記憶することができる。各々のトランザクションは、時間、トランザクションパラメータ（ファイル名など）の完全な組、及び、ペイロードと共に二次ファイルサーバ上に記録される。このログを使用して、故障（アプリケーションによるデータ書込間違い又は書込先ファイル間違い）の原因を判断し、ファイルを回復したり、又は、任意の瞬間でのファイルシステムのビューを取得することができる。例えば、特化されたソフトウエアを使用して目標とする瞬間を指定し、通常のファイルクライアントにその指定された時間現在のファイルシステムのビューを呈示することができる。
【０３０５】
地球規模のストレージ
ファイルスイッチ１５０２、そのクライアント１５０１、及び、その取り付けられたファイルサーバ１５０３により図１５に示されたファイルスイッチのゲートウェイトポロジーは、地球規模の分散ストレージシステムを可能にするように拡張することができる。これを行うために、ファイルスイッチ１５０２は、グループ１５０９から取得された遠隔ファイルをキャッシュするだけでなく、他のファイルを「ＮＡＳ」アレー１５０３又は別の「ＮＡＳ」アレー上に記憶することが好ましい。
【０３０６】
図１８は、地球規模分散型の交換ファイルシステムを示す。サイト１８１０、１８２０、及び、１８３０は、広域ネットワーク１８００を通じて接続されている。サイトの各々は、それぞれ、独自のネットワーク１８１２、１８２２、及び、１８３２を有する。また、各々のサイトネットワークは、それぞれ、ファイルスイッチ１８１１、１８２１、及び、１８３１、及び、ファイルサーバアレー１８１３、１８２３、及び、１８３３で構成されたローカル交換ファイルシステムを有する。ファイルスイッチ１８１１、１８２１、及び、１８３１は、ファイルスイッチ１５０２に関して説明したゲートウェイ能力を有することが好ましい。
【０３０７】
ファイルクライアントについては、ファイルスイッチの各々は、それぞれのファイルサーバアレー上に記憶されたファイルシステムへのアクセスを提供する。時に、ファイルクライアント１８１４は、クライアントのファイルスイッチ１８１１に直接取り付けられたファイルサーバアレー１８１３上に位置しない遠隔ファイルを要求する場合がある。この場合、スイッチ１８１１は、ゲートウェイとして機能し、要求されたファイルを含むサイト上のファイルスイッチ１８２１にトランザクションを転送する。スイッチ１８１１は、まるでそのスイッチのローカルネットワーク１８２２に取り付けられたファイルクライアントにより要求されたかのように、要求されたトランザクションを実施する。発信側のファイルスイッチ１８１１は、応答を受信すると、要求しているクライアント１８１４にそれを戻す。
【０３０８】
ファイルスイッチ１８１１は、アクセス帯域幅を広げてネットワーク１８１２からそのファイルまでのクライアントのアクセス待ち時間を短縮するために、ファイルスイッチ１８１２から取得されたファイルをキャッシュすることが好ましい。ファイルが閉じられるとすぐに、又は、その後で、又は、スイッチ１８１２から要求があり次第、スイッチ１８１１は、ローカルにキャッシュした変更内容を更新する。これを行うために、それは、ファイル書込トランザクションをスイッチ１８２１に対して生成してファイルを閉じることになり、その結果、ファイルアレー１８２３は、この時点で、クライアント１８１４により修正される場合もあるが、ファイルの最新バージョンを有することになる。尚、スイッチ１８２１は、そのローカルクライアント１８２４からの同じファイルを開く要求があり次第、このような更新を要求することができる。
【０３０９】
このキャッシュ及び更新要求機構は、「ＣＩＦＳ」ファイルプロトコルにあるものなどの便宜的ロック（オプロック）セマンティクスを使用して実施されることが好ましい。オプロックセマンティクスは、クライアント側キャッシュをネットワーク１８２２上で可能にするために既にファイルスイッチ１８２１によりサポートされているはずであり、それによってスイッチ間のキャッシュ及び更新のための特別なプロトコルは不要である。同じファイル（例えば、ファイルアレー１８２３上にあるファイル）は、複数のクライアントのいずれによってもキャッシュすることはできないが、全てのサイトからの複数のクライアントから同時に開くことができる。
【０３１０】
サイトの種類、地理上の位置、及び、トラヒック量に依存して、サイト１８１０、１８２０、及び、１８３０は、１８００などの広域ネットワークを通じて、また、大都市圏ネットワーク、Ｘ．２５、又は、専用接続を通じて接続することができる。サイトのうちの任意の２つの間の多重接続が利用可能とすることができる。そのトポロジーは、「ＩＰ」ネットワークによりサポートされているいかなるトポロジーにも拡張することができる。より多くの又は少ないサイトが、地球規模のストレージシステムに参加することができる。
【０３１１】
尚、遠隔ファイルは、ソフトウエアがファイルを捜してクライアントにそれを供給することができることが必要な特別なソフトウエアをクライアント上にインストール及び維持する必要もなく、クライアント１８１２にガラス張りの状態で提供される。クライアント１８１４は、仮に同じサイト１８１０上に記憶されたファイルを要求した場合にするであろう同じ方法で、その結果を要求及び解釈する。
【０３１２】
以上、様々な好ましい実施形態を詳細に説明してきたが、当業者は、本発明の新しい教示内容及び利点から実質的に逸脱することなく、例示的な実施形態の多くの変更が可能であることを容易に認めるであろう。例えば、本発明のファイルスイッチ／アグリゲータは、サーバの物理的なアーキテクチャ内にネットワークインタフェースユニットを備えたファイルサーバに一体化した方法で実施することができる。更に、本発明の形態のファイル統合は、ネットワークのクライアント及びサーバメンバー上に、ネットワークノードのオペレーティングシステムと互換性のあるソフトウエアドライバの形態でその機能性をインストールすることにより達成することができる。上記及び他の変更は、本発明の定義に含まれるように意図されており、本発明は、特許請求の範囲によってのみ限定されるべきである。
【図面の簡単な説明】
【０３１３】
【図１】コンピュータネットワークにおけるファイルスイッチを示す図である。
【図２】ネットワークファイルプロトコルにおけるトランザクションを示す図である。
【図３】ファイルスイッチにおけるメッセージ切替を示す図である。
【図４】ファイルスイッチによるトランザクション切替を示す図である。
【図５】ファイルスイッチによるトランザクション統合を示す図である。
【図６】ファイルスイッチによるネームスペース統合を示す図である。
【図７】ファイルスイッチによるディレクトリ統合を示す図である。
【図８】ファイルスイッチによるファイルオブジェクト統合を示す図である。
【図９】ファイル統合における同時性を処理する方法を示す図である。
【図１０】ミラーリングを通じたデータ統合を示す図である。
【図１１】ストライピングを通じたデータ統合を示す図である。
【図１２】スピルオーバーを通じたデータ統合を示す図である。
【図１３】データ統合規則を示す図である。
【図１４】ファイルスイッチの統合を示す図である。
【図１５】交換ファイルシステムを示す図である。
【図１６】交換ファイルシステムをクライアント側から見た図である。
【図１７】分散ファイルシステム及びクラスターファイルシステムを含む従来技術によるストレージネットワークを示す図である。
【図１８】ファイルスイッチを使用するグローバルストレージを示す図である。
【図１９】統合されたファイルシステムにおける同時アクセスを示す図である。
【図２０】好ましいファイルスイッチアーキテクチャを示すブロック図である。
【図２１】ファイルスイッチのための汎用コンピュータハードウエアアーキテクチャを示す図である。
【図２２】ファイルスイッチのための汎用スイッチハードウエアアーキテクチャを示す図である。
【図１】
2005502096.tif 000003
【図２】
2005502096.tif 000004
【図３】
2005502096.tif 000005
【図４】
2005502096.tif 000006
【図５】
2005502096.tif 000007
【図６】
2005502096.tif 000008
【図７】
2005502096.tif 000009
【図８】
2005502096.tif 000010
【図９】
2005502096.tif 000011
【図１３】
2005502096.tif 000012
【図１４】
2005502096.tif 000013
【図１５】
2005502096.tif 000014
【図１６】
2005502096.tif 000015
【図１７】
2005502096.tif 000016
【図１８】
2005502096.tif 000017
【図１９】
2005502096.tif 000018
【図２０】
2005502096.tif 000019
【図２２】
2005502096.tif 000020
【国際公開パンフレット】
2005502096.tif 000021
2005502096.tif 000022
2005502096.tif 000023
2005502096.tif 000024
2005502096.tif 000025
2005502096.tif 000026
2005502096.tif 000027
2005502096.tif 000028
2005502096.tif 000029
2005502096.tif 000030
2005502096.tif 000031
2005502096.tif 000032
2005502096.tif 000033
2005502096.tif 000034
2005502096.tif 000035
2005502096.tif 000036
2005502096.tif 000037
2005502096.tif 000038
2005502096.tif 000039
2005502096.tif 000040
2005502096.tif 000041
2005502096.tif 000042
2005502096.tif 000043
2005502096.tif 000044
2005502096.tif 000045
2005502096.tif 000046
2005502096.tif 000047
2005502096.tif 000048
2005502096.tif 000049
2005502096.tif 000050
2005502096.tif 000051
2005502096.tif 000052
2005502096.tif 000053
2005502096.tif 000054
2005502096.tif 000055
2005502096.tif 000056
2005502096.tif 000057
2005502096.tif 000058
2005502096.tif 000059
2005502096.tif 000060
2005502096.tif 000061
2005502096.tif 000062
2005502096.tif 000063
2005502096.tif 000064
2005502096.tif 000065
2005502096.tif 000066
2005502096.tif 000067
2005502096.tif 000068
2005502096.tif 000069
2005502096.tif 000070
2005502096.tif 000071
2005502096.tif 000072
2005502096.tif 000073
2005502096.tif 000074
2005502096.tif 000075
2005502096.tif 000076
2005502096.tif 000077
2005502096.tif 000078
2005502096.tif 000079
2005502096.tif 000080
2005502096.tif 000081
2005502096.tif 000082
2005502096.tif 000083
2005502096.tif 000084
2005502096.tif 000085
2005502096.tif 000086
2005502096.tif 000087
2005502096.tif 000088
2005502096.tif 000089
2005502096.tif 000090
2005502096.tif 000091
2005502096.tif 000092
2005502096.tif 000093
2005502096.tif 000094
2005502096.tif 000095
2005502096.tif 000096
2005502096.tif 000097
2005502096.tif 000098
2005502096.tif 000099
2005502096.tif 000100
2005502096.tif 000101
【国際公開パンフレット（コレクトバージョン）】
2005502096.tif 000102
【国際調査報告】
2005502096.tif 000103
2005502096.tif 000104
2005502096.tif 000105
2005502096.tif 000106
2005502096.tif 000107
2005502096.tif 000108