【手続補正書】
【提出日】平成18年2月13日(2006.2.13)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【書類名】明細書
【発明の名称】データ処理システム及び記憶システム
【特許請求の範囲】
【請求項１】
オリジナルデータが記憶された記憶媒体へアクセスするための第一のディスクコントローラを有するマスター記憶システムと、
前記マスター記憶システムとネットワークを介して接続され、前記オリジナルデータをコピーしたデータが記憶された記憶媒体へアクセスするための第二のディスクコントローラを有するセカンダリー記憶システムと、
前記マスター記憶システムに接続され、前記オリジナルデータに対応するデータの位置を識別するためのデータ構造を保持するプライマリー処理機構と、
前記プライマリー処理機構とネットワークを介して接続された少なくとも二つのアプリケーションサーバと、
を備えたデータ処理システムであって、
前記第一及び第二のディスクコントローラは、前記アプリケーションサーバから発行されるＩ／Ｏリクエストを受信し、ブロックレベルＩ／Ｏで前記オリジナルデータを記憶するものであり、
前記オリジナルデータが変更された場合に、
前記プライマリー処理機構は、データが変更されたことを書き込み又は変更されたデータを識別するためのデータ構造を変更し、前記サーバアプリケーションへ前記データ構造が変更したことを通知し、
前記マスター記憶システムで複製される前記変更されたデータのコピーと、前記データ構造のコピーとを、マスター記憶システムからセカンダリー記憶システムへ送る
ことを特徴とするデータ処理システム。
【請求項２】
オリジナルデータを記憶するための第一の記憶装置を含み、前記オリジナルデータの位置を識別する第一のデータ構造を保持する第一のデータセンタと、
前記オリジナルデータの少なくとも一部をコピーしたデータを記憶するための第二の記憶装置を含み、前記コピーしたデータの位置を識別する第二のデータ構造を保持する第二のデータセンタと、
を備え、
前記オリジナルデータが、前記第一の記憶装置に書き込まれ又は変更された場合に、前記第一のデータセンタでは前記オリジナルデータの書き込み又は変更が反映されるように前記第一のデータ構造が変更され、
前記第一の記憶装置が、書き込み又は変更されたデータと書き込み又は変更された第一のデータ構造とを第二の記憶装置に伝達し、かつ、前記第一のデータセンタが書き込み又は変更されたデータと書き込み又は変更された第一のデータ構造とを第二のデータセンタに通知する
ことを特徴とするデータ処理システム。
【請求項３】
請求項２に記載のデータ処理システムであって、
前記第二のセンタへ通知された前記第一のデータ構造は、ファイルレベルＩ／Ｏフォーマットである
ことを特徴とするデータ処理システム。
【請求項４】
請求項３に記載のデータ処理システムであって、
前記第二の記憶装置へ伝達された前記書き込み又は変更されたデータは、ファイルレベルＩ／Ｏフォーマットである
ことを特徴とするデータ処理システム。
【請求項５】
請求項４に記載のデータ処理システムであって、
前記第一の記憶装置と第二の記憶装置は磁気媒体である
ことを特徴とするデータ処理システム。
【請求項６】
請求項４に記載のデータ処理システムであって、
前記第一の記憶装置と第二の記憶装置はディスク装置である
ことを特徴とするデータ処理システム。
【請求項７】
データイメージを記憶するローカルデータ記憶装置と、
前記データイメージの複製を記憶する複数のリモートデータ記憶装置と、
前記ローカルデータ記憶装置と前記リモートデータ記憶装置へのファイルレベルＩ／Ｏアクセスリクエストを受信するコンテンツマネージャが実行するファイルシステムと、    
前記データイメージと前記複製されたデータイメージへアクセスするブロックレベルＩ／Ｏアクセスと、
を備えることで、
前記データイメージが変更された場合に、ブロックレベルＩ／Ｏを使用して、前記複数のリモートデータ記憶装置へ変更された前記データイメージの複製データイメージを転送する
ことを特徴とする記憶システム。
【請求項８】
請求項７記載の記憶システムであって、
前記複数のリモート記憶装置の夫々は、複製されたデータイメージに含まれるデータにアクセスするための少なくとも１台のサーバプロセッサーに結合されている
ことを特徴とする記憶システム。
【請求項９】
請求項７記載の記憶システムであって、
前記ローカルデータ記憶装置は、前記データイメージを記憶する記憶媒体と、前記記憶媒体にアクセスするための第一のディスクコントローラとを含む
ことを特徴とする記憶システム。
【請求項１０】
請求項９記載の記憶システムであって、
前記リモートデータ記憶装置は、前記複製されたデータイメージを記憶する記憶媒体と、前記記憶媒体にアクセスするための第二のディスクコントローラをと含む
ことを特徴とする記憶システム。
【請求項１１】
請求項９記載の記憶システムであって、
前記第一のディスクコントローラは、データイメージを変更するために、ファイルレベルＩ／Ｏリクエストを受信し、ブロックレベルＩ／Ｏリクエストに変換する
ことを特徴とする記憶システム。
【請求項１２】
請求項１１記載の記憶システムであって、
前記第一のディスクコントローラは、前記データイメージを変更するためのファイルレベルＩ／Ｏリクエストに対し、変更されるイメージデータを前記リモートデータ記憶装置に複製するため、リモートコピープロセスを有する
ことを特徴とする記憶システム。
【請求項１３】
請求項１２記載の記憶システムであって、
前記データイメージのデータの位置を識別するためのコンテンツマネージャを有し、
前記データイメージは前記コンテンツマネージャにより保持される少なくとも一つのデータ構造を含む
ことを特徴とする記憶システム。
【請求項１４】
請求項１３記載の記憶システムであって、
前記コンテンツマネージャは、前記ローカルデータ記憶装置にデータイメージの変更の位置を知らせるためにデータ構造を変更することを特徴とする記憶システム。
【請求項１５】
請求項１４記載の記憶システムであって、
前記複数のリモート記憶装置の夫々と前記コンテンツマネージャに接続される少なくとも一台のアプリケーションサーバを有し、前記データイメージが変更された場合には、前記コンテンツマネージャが変更された前記データ構造を前記アプリケーションサーバに転送する
ことを特徴とする記憶システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般にデータ処理システム及び記憶システムに係わり、特にプライマリー記憶システムから数台のセカンダリー記憶システムへブロックレベルのＩ／Ｏデータを転送することが可能なデータ処理システム及び記憶システムに関する。ファイルシステムの形式のデータロケーション情報は、別個にセカンダリー記憶システムのユーザに転送される。
【０００２】
【従来の技術】
昨今のように大型の記憶システムが利用出来るようになり、またインターネットを経由してこのような記憶システムに容易にアクセスできるようになると、例えば、エンタテインメントや教育の両面で、リアルタイムでビデオを見るなどのアプリケーションへの要求が出てくる。例えば、通信媒体としてのインターネットの利用により、ビデオファイルを事実上世界中のどこにでも転送することが可能になる。しかしながら、多くのユーザがさらに大きい記憶システムを利用できるようにすると、それに付随して問題が起こる。それは少なくとも多くのユーザがほぼ同時に同じファイルにアクセスしようとした時に当然発生する、ボトルネックの結果として起こる性能低下である。
【０００３】
一つの解決方法は、異なった場所に複数のデータセンタを設置し、ユーザからのアクセス負荷を分散させることである。これにより複数のユーザは多くの場所の一箇所で（ビデオ）ファイルにアクセスすることが出来る。ビデオファイル（映画）における映画スタジオのようなプライマリーロケーションは、ファイルを全てのデータセンタに配布することが出来る。
【０００４】
しかしながら、ビデオファイルは通常はオペレイティングシステムのファイルシステムで管理される。ビデオサーバのようにオペレイティングシステム上で稼働しているアプリケーションは、ビデオをアクセスの便宜上ファイルとして取り扱う。一般に、ビデオファイルの転送には、ＴＣＰ／ＩＰネットワークを経由して一つのサーバから他のサーバへファイルをコピーするために「ファイルトランスファープロトコル−Ｆｉｌｅ  ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ」（ＦＴＰ）のようなファイルレベルのＩ／Ｏを使用する。このプロトコルは、データがファイルシステム上に記憶されていることを想定している。
【０００５】
しかしながら、ファイルに基づくデータ転送方法は、しばしばファイルシステムの大きなオーバヘッドによる、低いデータ転送速度になる欠点がある。ファイルシステムとしては、論理「ボリューム」が、通常は多数のディスクデバイスによる、記憶空間の予め定められた部分にマップする、論理ファイル管理システムがしばしば用いられる。ファイルの読み出し、および／あるいは書き込みには、ファイルシステムは、また、ファイルのメタデータ、しばしばボリューム上のどこにファイルが記憶されているかを識別するファイルを記述している情報、およびファイル名、サイズ、最後にアクセスされた時刻等の関連属性、を読み書きする。メタデータは、また、ボリューム上にも記憶されるので、ファイル上で読み出しおよび／あるいは書き込み動作を伴うメタデータ動作は、ＣＰＵの能力とＩ／Ｏのバンド幅を低下させる。これがファイル転送に基づく転送速度が低い理由である。
【０００６】
ファイル配布サービスを提供することができるサービスがある。ＡｋａｍａｉとＤｉｇｉｔａｌ  Ｉｓｌａｎｄはこのようなサービスのいくつかの例であり、上述のようなファイルベースのデータ転送方法を通常は用いるので、さきに説明した問題の影響を受ける。ブロックレベルのデータ転送を提供するリモートコピー方法もある。この転送方法は米国特許５，７４２，７９２に記述されている。しかしながら、用いられている転送方法はファイルシステムを使用するアプリケーションに用いるようには構成されていない。このことは、たとえデータコピーが行なわれたとしても、アプリケーションやファイルシステムは転送されたデータを処理できない、ことを意味する。
【０００７】
【発明が解決しようとする課題】
本発明はプライマリーあるいはマスター記憶システムから多数のセカンダリー記憶システムに配布されたデータの複数のコピーを持つデータ処理システム又は記憶システムに対するものである。本発明は、記憶システム間でのデータ転送にはブロックレベルＩ／Ｏを用いさせながら、サーバ上で実行しているアプリケーションに、記憶システムに対してファイルレベルＩ／Ｏアクセスをさせることができる、システムと方法と提供する。
【０００８】
【課題を解決するための手段】
本発明のデータ処理システムでは、オリジナルデータが記憶された記憶媒体へアクセスするための第一のディスクコントローラを有するマスター記憶システムと、前記マスター記憶システムとネットワークを介して接続され、前記オリジナルデータをコピーしたデータが記憶された記憶媒体へアクセスするための第二のディスクコントローラを有するセカンダリー記憶システムと、前記マスター記憶システムに接続され、前記オリジナルデータに対応するデータの位置を識別するためのデータ構造を保持するプライマリー処理機構と、前記プライマリー処理機構とネットワークを介して接続された少なくとも二つのアプリケーションサーバと、を備えたデータ処理システムであって、前記第一及び第二のディスクコントローラは、前記アプリケーションサーバから発行されるＩ／Ｏリクエストを受信し、ブロックレベルＩ／Ｏで前記オリジナルデータを記憶するものであり、前記オリジナルデータが変更された場合に、前記プライマリー処理機構は、データが変更されたことを書き込み又は変更されたデータを識別するためのデータ構造を変更し、前記サーバアプリケーションへ前記データ構造が変更したことを通知し、前記マスター記憶システムで複製される前記変更されたデータのコピーと、前記データ構造のコピーとを、マスター記憶システムからセカンダリー記憶システムへ送ることを特徴とする。
【０００９】
アプリケーションサーバは、プライマリー処理機構とネットワークにより相互に交信可能に接続され、セカンダリー記憶システムに対してもネットワークを介して接続される。マスター記憶システムに保持されているオリジナルデータは、セカンダリー記憶システムにミラーされる。マスター記憶システムとセカンダリー記憶システムは、ネットワークを経由して接続される。
【００１０】
また、本発明のデータ処理システムは、オリジナルデータを記憶するための第一の記憶装置を含み、前記オリジナルデータの位置を識別する第一のデータ構造を保持する第一のデータセンタと、前記オリジナルデータの少なくとも一部をコピーしたデータを記憶するための第二の記憶装置を含み、前記コピーしたデータの位置を識別する第二のデータ構造を保持する第二のデータセンタと、を備え、前記オリジナルデータが、前記第一の記憶装置に書き込まれ又は変更された場合に、前記第一のデータセンタでは前記オリジナルデータの書き込み又は変更が反映されるように前記第一のデータ構造が変更され、前記第一の記憶装置が、書き込み又は変更されたデータと書き込み又は変更された第一のデータ構造とを第二の記憶装置に伝達し、かつ、前記第一のデータセンタが書き込み又は変更されたデータと書き込み又は変更された第一のデータ構造とを第二のデータセンタに通知することを特徴とする。
【００１１】
データへの変更（削除、変更など）は、記憶媒体上で変更されたファイルと変更された位置を識別するために、データ構造への変更によって反映される。変更されたデータと対応するデータ構造は、ネットワーク上のデータ通信を通して、第一のデータセンタ上で実行するリモートコピー処理により、第二のデータセンタでも利用可能になる。第二のデータセンタが保持する（ミラー化された）データに対する変更をアプリケーションサーバが知ることが出来るように、第一のデータセンタにあるコンテンツマネージャのデータ構造とアプリケーションサーバは同期化される。
【００１２】
さらに本発明の記憶システムは、データイメージを記憶するローカルデータ記憶装置と、前記データイメージの複製を記憶する複数のリモートデータ記憶装置と、前記ローカルデータ記憶装置と前記リモートデータ記憶装置へのファイルレベルＩ／Ｏアクセスリクエストを受信するコンテンツマネージャが実行するファイルシステムと、前記データイメージと前記複製されたデータイメージへアクセスするブロックレベルＩ／Ｏアクセスと、を備えることで、前記データイメージが変更された場合に、ブロックレベルＩ／Ｏを使用して、前記複数のリモートデータ記憶装置へ変更された前記データイメージの複製データイメージを転送することを特徴とする。
【００１３】
アプリケーション処理はファイルレベルＩ／Ｏリクエストを行う一方、記憶装置により制御される記憶媒体へのアクセスは、ブロックレベルＩ／Ｏを用いる。
【００１４】
【発明の実施の形態】
本発明によると、プライマリー又はマスターデータセンタ（第一のデータセンタ）は、プライマリー処理機構とデータのマスターコピーが保持されている記憶システム（マスター記憶システム、第一の記憶装置、ローカルデータ記憶装置）とを含んでいる。データにはデータの場所を識別するデータ構造（ディレクトリリストやｉノードリストなど）が記憶されている。定期的に、データに対しデータの変更（削除や修正など）が行われる。変更は、データを含んでいる記憶媒体の以前には未使用のエリアに書き込まれる。データの変更が終わると、変更したデータの場所を識別するためにデータ構造の修正が行われる。
【００１５】
つぎに、変更したデータとデータ構造はリモートコピーキュー上に置かれる。リモートコピープロセスは、最後のスキャンの後に行われた変更をみるために、定期的にリモートコピーキューをスキャンし、もし変更されたデータが見つかると、変更されたデータは、関連する修正されたデータ構造とともに、１台ないしはそれ以上のセカンダリー記憶システム（第二の記憶装置、リモートデータ記憶装置）にコピーされ、セカンダリー記憶システムに結合されたアプリケーションサーバで利用できるようになる。
【００１６】
プライマリー処理機構は、変更されたデータとそれに伴う修正されたデータ構造がセカンダリー記憶システムに受け取られたとことを確認すると、アプリケーションサーバにメッセージを送る。アプリケーションサーバがメッセージを受け取ると、データが変更されたことを告示する。
アプリケーションサーバは、関連した記憶装置から修正されたデータ構造を検索し、古い（変更されていない）データではなく更新されたデータが使用されるようにする。
【００１７】
システム構成
図を見てみると、図１は、本発明を用いた、基本的なデータプロセシングシステム１０の説明である。
【００１８】
図１が示すように、データプロセシングシステム１０は、ここではデータセンタ１２Ａと１２Ｎで示される、複数のデータセンタを含むことができる。
【００１９】
プライマリーデータセンタ１２Ａは、マネージメントコンソール１４、コンテンツマネージャ１６を含み、アプリケーションサーバ１８と記憶システム２２Ａを含んでも含まなくてもよい。データセンタ１２Ｎのような他のデータセンタ１２は、それぞれが記憶システム２２Ｎを含むアプリケーションサーバである。
【００２０】
マネージメントコンソール１４、コンテンツサーバ１６およびデータセンタ１２Ａのアプリケーションサーバ１８は、例えばローカルエリアネットワーク（ＬＡＮ―１）を経由して、記憶システム２２Ａと接続する。
【００２１】
同様に、データセンタ１２Ｎのアプリケーションサーバ１８は、ＬＡＮ接続により関連する記憶装置２２Ｎに接続する。以下に詳細を説明するように、各記憶システム２２Ａと２２Ｎは、ブロックＩ／Ｏを実行するためのディスクコントローラ２４、とリモートコピー（ＲＣ）プロセス２６、２８を含む。
【００２２】
さらに、各ディスクコントローラは、以下に説明するペアテーブル３０と呼ばれるデータ構造を保持している。
【００２３】
ディスクコントローラ２４は、記憶媒体３４と３６に結合し、その１個ないしはそれ以上の「ボリューム」が、記憶媒体３４と３６を使う磁気ディスク記憶ユニットに位置づけされている、「論理」記憶装置を優先的に実行する。このような論理記憶装置は、記憶媒体にアクセスするためにブロックレベルＩ／Ｏを用いるデータセンタ１２のサーバ（例えば、アプリケーションサーバ１８やコンテンツマネージャ１６など）からのＩ／Ｏリクエストに応答しやすくする。（従来技術と同様に、例えばサーバ１８上で実行する、アプリケーション処理は、サーバのファイルシステムにファイルレベルＩ／Ｏリクエストを発行する。順に、ファイルシステムは、記憶システム２４にブロックレベルＩ／Ｏリクエストとしてリクエストを発行する。記憶システムは必ずしもデータ構造を理解するわけではないが、ブロックレベルで変更される部分は認識することが出来る。本発明によれば、これにより、データセンタ１２Ａの記憶システム２４は、これらの変更を他のデータセンタ１２へ送ることが出来る。）
【００２４】
マスターボリューム３４は、システムの全てのデータのマスターコピーを受け取り保持する。
【００２５】
ＲＣプロセス２８を使用して、データセンタ１２Ａのディスクコントローラ２４は、そのデータと、そのデータに対するその後の変更を、他のデータセンタ１２の複製されたボリューム３６にコピーする。このようにして、複製されたボリューム３６はマスターボリューム３４のデータをミラーする。
【００２６】
記憶媒体３４と３６へのアクセスを開始させるブロックレベルＩ／Ｏのリクエストを受け取るため、論理記憶装置が、記憶システム２２のディスクコントローラ２４によって実施される。
【００２７】
コンテンツマネージャ１６は、記憶媒体上のファイルにアクセスするためにブロックレベルＩ／Ｏに変換する、ファイルシステムに対してファイルレベルＩ／Ｏリクエストを用いて、ファイルを探し出すために必要なデータ構造を保持する。
【００２８】
マネージメントコンソール１４は、記憶システム２２の記憶媒体上へのファイルの配置を含めて、システム１０を構成する手段を提供する。
【００２９】
図１が示すように、アプリケーションサーバ１８は、コンテンツマネージャに、ローカルエリアネットワーク（ＬＡＮ２）接続、あるいはインターネットのようなワイドエリアネットワーク（ＷＡＮ１）接続により、通信可能に接続されていることに注意が必要である。
【００３０】
記憶システム２２は、別個に、インターネットあるいは他のネットワーク接続でよいワイドエリアネットワーク（ＷＡＮ２）を用いて、相互に接続される。マスターボリューム３４上に保持されているデータイメージに変更が加えられると、これらの変更は記憶装置の使用されていないエリアに書き込まれる。
【００３１】
つぎに、そのデータを探し出すためにファイルシステムにより用いられている各種のファイル構造が修正され、そして修正されたファイル構造も記憶装置に書き込まれる。得られたデータイメージやファイル構造の変更は、後で、記憶システム２２ＡからのブロックＩ／Ｏレベルにおける複製されたボリューム３６に対する記憶媒体３４から、他の記憶システム２２ＢにＷＡＮ２接続を用いてコピーされる。
【００３２】
また、その変更されたデータに対して必要なパスは、ファイルレベルＩ／Ｏフォーマットで、ＬＡＮ２とＷＡＮ１のコミュニケーションパスを用いて、コンテンツマネージャ１６からアプリケーションサーバ１８に送られる。（コンテンツマネージャは、ＬＡＮとＷＡＮ１を経由して、メッセージをアプリケーションサーバへ送り、そしてメッセージはアプリケーションサーバのメモリーにあるキャッシュデータをフラッシュ（言い換えると、無効にする）するために用いられ、その結果アプリケーションサーバは、セカンダリー記憶システムでは新しいデータの代わりに旧いデータを使用することが無い。）
【００３３】
さらに 図１が示すように、マネージメントコンソールは、コンフィギュレーションマネージャプロセス１４ａ、ファイル更新プロセス１４ｂ、コンフィギュレーション変更プロセス１４ｃ、および更新ファイルチェックプログラム１４ｄを実行する、あるいは実行することが可能である。これらのプロセスは、見て分かるように、ファイルレベルＩ／Ｏアクセスのために、ファイル構造を構成したり変更したりするための、以下で説明する他の機能を遂行するとともに、グローバルマウントポイントテーブル１４ｅを管理し保持する。
【００３４】
コンテンツマネージャ１６はアプリケーションプロセス、マスターファイルシステム、記憶システム２２Ａ上の各ファイル記憶装置を記述するメタデータを保持するように動作するマウントクライアント、ローカルマウントポイントテーブル、および更新されたｉノードリストを実行する（あるいは実行することが出来る）。
【００３５】
アプリケーションサーバは、それぞれアプリケーション、クライアントファイルシステム、記憶システム２２のデータにファイルレベルＩ／Ｏアクセスをするためのメタデータやローカルマウントポイントテーブルを使用するように動作するマウントクライアントを実行する。
【００３６】
特定のシステムアーキテクチャは、代表的なものであって、この分野で熟練した人にとって、他のシステム設計が使用できると言うことは明らかである。たとえば、アプリケーションは、記憶システム２２により保持されているデータにアクセスするようにファイルサーバを通して動作するアプリケーションサーバ上で実行してもよい。もしそうであるならば、ファイルサーバ上で、記憶システム上のファイルを読むようにアプリケーションサーバは実行されるので、アプリケーションサーバはクライアントファイルシステムをインストールする必要がない。
【００３７】
テーブル
上記に示すように、マネージメントコンソール１４、コンテンツマネージャ１６、およびアプリケーションサーバ１８は、本発明を実施するに際し、各種のデータ構造やテーブルを保持する。これらのテーブルの説明を以下に示す。
【００３８】
グローバルマウントポイントテーブル
グローバルマウントポイントテーブル１４ｅはマネージメントコンソール１４により保持され、システム構成の情報を含んでいる。
図２はグローバルマウントポイントテーブルの例を示す。図２が示すように、テーブルは、列４０に構成名（例えば、ＣＯＮＦ１、．．．、ＣＯＮＦｍ）を含む。各構成においては、コラム４２に表示されるマウントポイント（／ｍｎｔ１、．．．、ｍｎｔｍ）とマスターファイルシステムのサーバ名（コラム４４）がある。
コラム４６、４８と５０は、それぞれマスターファイルシステムにより管理されるファイルを使用するサーバ、ボリュームのリスト、およびサーバとボリュームの間のマッピングを記載している。
マウントポイントは、どこにサーバがボリュームをマウントするかを識別するために使用される。マッピングは、サーバがどのボリュームを使用するかを示す。記憶システムとボリュームの識別子は記憶システムでのボリュームを指定する。
ファイルのいくつかのセットは特定のデータセンタへコピーされ、ファイルの他のセットは他のデータセンタへコピーされるような場合がある。これが多くの構成がある理由である。各構成は、互いに異なっている、それぞれのデータセットを識別する。
【００３９】
ローカルマウントポイントテーブル
図３に示されるのがローカルマウントポイントテーブルであり、その一つはコンテンツマネージャ１６にあり、システムの各アプリケーションサーバ１６にある。ローカルマウントポイントテーブルは、どのボリュームをユニット（コンテンツマネージャまたはサーバ）がマウントするかについての情報を含んでいる。
図３に示すように、サーバＢ１は記憶システムＢとボリュームＢ１により指定されたボリュームをディレクトリ／ｍｎｔ１にマウントする。ローカルマウントポイントテーブルはコンフィギュレーションマネージャプロセス１４ａにより生成され、配布される。
【００４０】
ペアテーブル
ペアテーブル３０はディスクコントローラ２４により管理され、どのボリュームが他のどのボリュームによりミラーされているか、また、どのボリュームがどの記憶システムと関連しているかというような情報を含んでいる。ペアテーブルの構造と内容の例を 図４に示す。図では、ペアテーブル３０'は、コラム５６、５９と６０のそれぞれが、ペアの名称、ペアの名称に関連したプライマリーボリュームの識別、１つないしはそれ以上のセカンダリーボリュームを含むことを示している。ペアの名称は、基本的にはグローバルマウントポイントテーブルの構成名に対応している。
【００４１】
ボリューム
プライマリーボリュームはオリジナルファイルを含むボリュームであり、コンテンツマネージャ１６のマスターファイルシステムプロセスにより管理される。セカンダリーボリュームはプライマリーボリュームをミラーし、プライマリーボリュームのデータの複製を保持する。セカンダリーボリュームはアプリケーションサーバにより使用される。
【００４２】
ディレクトリリスト
ディレクトリリストはテーブルであって、ファイルシステムの各ディレクトリに一つ存在するものである。ディレクトリリストは、ディレクトリの各ファイルを、ファイルの各々のｉノード番号とともに識別する情報を含んでいる。
図５はディレクトリリストの例であって、例とするディレクトリａｂｃが、ファイル１、ファイル２、．．．、ファイルｎのファイルと、関連するｉノード番号の１、２、．．．、ｎを識別することを示している。
【００４３】
Ｉノードインフォメーション
ファイルレベルのシステムにおいては一般的であるが、ｉノードはファイルシステムの各ファイルに対して存在し、ファイルに関連する属性だけでなく、対応する記憶媒体３４または３６上のファイルを探し出すための情報も含んでいる。
図６は、代表的なｉノード情報を示す図であって、ファイルがｉノード番号１０を持ち、ファイル属性がファイルが最後に修正されたときのデータ、ファイルサイズ、「新ファイル」フラッグ、ディレクトリのリスト（「Ｄｉｒｅｃｔ」）のエントリーを含むことを示している。新ファイルフラッグはマスターファイルシステムで使用され、ファイルがオープンされたときにファイルが存在するか否かを示す。
【００４４】
ディレクトリエントリー
ディレクトリエントリー（例えば、Ｄｉｒｅｃｔ１、Ｄｉｒｅｃｔ２など）は、記憶システム上でファイルを形成する各種のボリュームデータの位置を識別する。各ディレクトリエントリーは、それに関連して、その位置がファイルの現在のｉノードにより使用されているか否かを示す「新」フラグを持つ。このフラグに関する詳細を以下に説明する。
例えば、このように、ｉノード番号１０を持つファイルは、１２／３１／０５に最新の更新がされ、大きさが１００ＭＢで、その構成部分は記憶システムＡのボリュームＡ１にあるブロック１、２、．．．、ｎにある。
図７Ａと図７Ｂは、ファイルをボリュームに記憶させる際の、ファイル、ディレクトリリスト、およびｉノード情報の間の関係について図示している。
図７Ａは、ファイルは容易にビデオファイルや他のファイルであってもよいのだが、テキストを含んでいるファイルを説明する。
図７Ｂは、「ファイル３」というファイル名を持つファイルが「１０」のｉノードを持つことを示している。番号１０のｉノードは、ファイルを構成するデータのパーツが記憶媒体上、すなわち記憶システムＡのボリュームＡ１にある。
【００４５】
更新されたｉノードリスト
更新されたｉノードリストは、最後のファイル更新がされた後で、どのファイルが更新あるいは生成されたかの情報を含むテーブルである。更新されたファイルに関連するｉノードもこのテーブルに含まれている。
図８は更新されたｉノードリストの例である。ファイルネームコラムは、ファイルを識別し、「新ｉノード番号」は（更新された）ファイルに割り当てられたｉノードを識別する。
【００４６】
利用可能なブロックリスト
利用可能なブロックリストは、各マスターボリューム４３のどのロケーションが使用され、どのロケーションが使用可能かの情報を含むテーブルである。
図９は利用可能なブロックリストの例である。この例では、記憶システムＡのボリュームＡ１のブロック１の利用可能フラグ（Ｎｏ／Ｙｅｓ）はＮｏである。これは、このロケーションが何らかのファイルあるいはメタデータを記憶するために使用されていることを意味する。一方、同じボリュームのブロック３は、新しいファイルあるいは更新されたファイルを記憶するために使用可能である。
【００４７】
利用可能なｉノードリスト
利用可能なブロックリストと同様に、利用可能なｉノードリストは、どのｉノード番号が使用され、どれが利用可能であるかを識別するテーブルである。
図１０はリストの例である。ｉノード番号の利用可能フラグがＹｅｓの場合は、そのｉノード番号は利用可能である。それがＮｏの場合は、ｉノード番号はファイルを識別するために使用されている。
【００４８】
開かれたｉノードリスト
開かれたｉノードリストは、どのファイルがアプリケーションにより現在使用されている（すなわち、開かれている）かの情報を含んでいるテーブルである。
図１１はそのようなリストの例である。リストは、開かれたファイルの識別子としてのファイル記述子を含んでいる。
いくつかのファイルシステムと同様に、アプリケーションがファイルを開くと、ファイルシステムはファイル記述子をファイルオープンに対して割り当てる。その後は、アプリケーションは、ファイルが開かれている間は、このファイル記述子を使用する。この例では、ファイル記述子１はｉノード番号４を持つ関連したファイルにより使用されている。一方、ファイル記述子３はどのアプリケーションによっても使用されていないので、従って、使用可能である。
【００４９】
マネージメントコンソール
マネージメントコンソールは、たとえば、システムを構成し、そして時刻に合わせファイル更新を提供するシステムアドミニストレータに対する、グラフィックユーザインタフェース（ＧＵＩ）を提供するプロセッサーユニットである。たとえファイルがコンテンツマネージャにより更新されても、その内容は、マネージメントコンソールからタイミングを伝えなくては、アプリケーションサーバには見えない。
【００５０】
ＧＵＩ
マネージメントコンソール１４は、一つの（例えば、システムアドミニストレータ）構成変更が、マネージメントコンソール上でマウントポイントアップデート処理を実行するための、ＧＵＩコールになるように、グラフィックユーザインタフェース（ＧＵＩ：図示なし）を駆動するように動作する。
さらに、ＧＵＩは時刻を指定したファイルの更新の手段を、システムアドミニストレータに提供することが出来る。アドミニストレータは構成名を指定することが出来、そしてＯＫボタンを押すことでコンテンツマネージャにタイミングを指示できる。どのファイルが、指定の構成のために更新されたかを容易に理解させるために、ＧＵＩスクリーン（図示されず）は更新されたファイルのリストを提供することが出来る。ＧＵＩにより呼び出されると、更新ファイルチェックプログラム１４ｄ（図１）はこのリストを提供する。
【００５１】
ファイル更新プロセス
上記に示されたように、このプロセスはコンフィギュレーションマネージャプロセス１４ａのＧＵＩにより呼ばれる。ファイル更新プロセス（１４ｂ）は、アプリケーションサーバ１８に送られるべき更新されたファイルの識別を要求するために、コンテンツマネージャ１６と交信する。
図１２はファイル更新プロセス１４ａが取るステップを示している。それはコンテンツマネージャ上で実行しているマスターファイルシステムに対して、ファイル更新メッセージを送る（ステップ９０）。次に、マスターファイルシステムからの完了メッセージを待つ（ステップ９２）。
【００５２】
Ｃｏｎｆｉｇ変更プログラム
このプログラムは、コンフィギュレーションマネージャプロセス１４ａのＧＵＩにより呼ばれ、ＧＵＩを介して、システムアドミニストレータからの入力情報に基づいて、グローバルマウントポイントテーブル１４ｅ（図２）、ペアテーブル３０（図４）およびローカルマウントポイントテーブル（図３）を生成する。
【００５３】
図１３は、Ｃｏｎｆｉｇ変更プログラムの動作の説明である。
ステップ１０１では、ＧＵＩからの入力は、その入力に基づいてグローバルマウントポイントテーブルでの変更を有効にするために受信される。つぎに、ステップ１０２では、各アプリケーションサーバ１８について、サーバがコンテンツマネージャやアプリケーションサーバを含んでいるグローバルマウントポイントテーブルに基づいて、サーバに対して新しいローカルマウントポイントテーブルを生成する。各サーバについて、Ｃｏｎｆｉｇ変更プログラムは、新しいローカルマウントポイントテーブルをシステム１０のサーバ１８に送る（ステップ１０３）。
ステップ１０４では、Ｃｏｎｆｉｇ変更プログラムは、サーバの全てから完了メッセージが来るのを待つ。
つぎに、ステップ１０５では、グローバルマウントポイントテーブルに基づいて新しいペアテーブルが生成される。
ステップ１０６では、Ｃｏｎｆｉｇ変更プログラムは、新しいペアテーブルを記憶システム２２Ａ（図１）へ送る。
Ｃｏｎｆｉｇ変更プロセスは、ステップ１０７では、記憶システムからの完了メッセージを待ち、そしてそれを受け取ると、ステップ１０８で処理を完了させる。
【００５４】
更新ファイルチェックプログラム
更新ファイルチェックプログラム１４ｄは、最後のファイル更新が行われてから、どのファイルが更新されたかをチェックするために、コンフィギュレーションマネージャのＧＵＩに呼び出される。
図１４は動作のシーケンスを示しており、コンテンツマネージャ１６のマスターファイルシステムに対し、マウントポイントを付けてチェックメッセージを送るステップ１２０で始まる。
マスターファイルシステムは、次に、更新ファイルチェックプログラムがステップ１２２で待っているマウントポイントのもとでの更新されたファイルのリストを返送する。リストが受け取られると（ステップ１２４）、リストはＧＵＩのディスプレー（図示なし）に表示される。
【００５５】
コンテンツマネージャ
コンテンツマネージャ１６は、基本的にはファイルを更新するためにサーバを動作させる。ファイルが生成、更新あるいは削除されると、ディレクトリリスト、利用可能なブロックリスト、ｉノード情報、および利用可能なｉノードリストを含むコンテンツマネージャにより維持されるメタデータも、変更される。
【００５６】
アプリケーションサーバ１８により保持されているクライアントファイルシステムは、マスターファイルシステムと共にディレクトリリストとｉノード情報を共有する。共有のｉノード情報はマスターファイルシステムによって変更されず、たとえリクエストがファイルの修正であっても、単に新しいｉノードが生成されるだけである。また、すでにファイルにより使用されているブロック上のデータも変更されない。
マスターファイルシステムは、マスターファイルシステムとクライアントファイルシステムとの間に不整合が生じないように、ディレクトリリストをアトミックに変更する。
【００５７】
マスターファイルシステム
コンテンツマネージャ１６上で実行するマスターファイルシステムプロセスは、マスターボリューム３４においてファイルを生成し、更新し、削除するように動作する。説明したように、各マスターボリュームは複数の複製されたボリューム３６によりミラーされる。
マスターボリュームの更新は、ディスクコントローラ２４で実行中のリモートコピープロセス２８により（上記で示したように時間ベースで）、アプリケーションサーバ１８のクライアントファイルシステムで読み出して使用するために、複製されたボリューム３６にコピーされる。それにより、マスターボリューム３４上に保持されているデータと複製されたボリューム３６に保持されているデータの間の整合性が維持される。
マスターファイルシステムプロセスを用いるアプリケーションは、７つのタイプのファイルレベルＩ／Ｏリクエストを作成する：すなわち、オープン、書き込み、読み出し、クローズ、削除、チェック、そして更新である。最後の２つのタイプはコンフィギュレーションマネージャによってのみ使用される。
【００５８】
図１５は、受け取った各種のＩ／Ｏリクエストを取り扱う際の、マスターファイルシステムの動作のステップを説明するものである。最初は（ステップ１３０）、プロセスはアプリケーションからのリクエストを待つ。リクエストを受け取ると、ステップ１３２ではタイプ（例えば、そのリクエストはファイルをオープンするのか、クローズするのか、書き込むのかなど）によりチェックされる。
つぎに、リクエストのタイプが決まると、マスターファイルシステムプロセスは、リクエストのタイプに従い、７種類の手順１３３の一つを呼び出す。
【００５９】
オープン手順
オープン手順１３３ａは、ファイルの使用を開始するときに、アプリケーションにより呼び出される。
図１６は用いられるステップを示す。
考慮すべき三つのケースがある：すなわち、新しいファイルの生成（ケースａ）と、現存のファイルへのデータ書き込みで、最後のファイル更新のあと初めてファイルが開かれる（ケースｂ）と、現存のファイルへのデータ書き込みで、最後のファイル更新のあとファイルが開かれるのは２回目かそれ以上である（ケースｃ）。
最初のケースと次の二つのケースとを区別するために、ファイルに対応したｉノード情報（図６）の新しいファイルフラグが使用される。第２のケースと第３のケースを区別するためには、更新されたｉノードリスト（図８）を参照する。更新されたｉノードリストは、最後のファイル更新のあとで開かれたｉノードを識別する。
第２のケースでは、マスターファイルシステムは、ファイルの現在のｉノードを変更せず、むしろファイルに対する新しいｉノードを生成する。
第３のケースでは、マスターファイルシステムは、ｉノードはマスターファイルシステムのみが所有するという理由で、更新されたｉノードリストのｉノードのみを使用する。
【００６０】
図１６を参照すると、ステップ１４２では、オープン手順は、チェックしてリクエストされたファイルが新しいかどうかを決める。そうであるなら、ステップ１４２ａに進み、そうでないなら、ステップ１４２ｂに進む。
ステップ１４２ａは、ファイルに対して、利用可能なｉノードのリスト（図１０）から新しいｉノード番号を割り当てることになる。
つぎに、ステップ１４３ａでは、手順は、利用可能なｉノードリストから選択したｉノード番号を使って、新しいｉノードを生成し、利用可能なブロックリストにあるいくつかの利用可能なブロックを使用して、ボリューム上にｉノード情報を記憶する。
つぎに、ステップ１４４ａでは、オープン手順は、ｉノードの属性フィールドやそのｉノード番号を初期化し、生成の日付を付け、その大きさやダイレクトエントリーのリストを識別する。
ステップ１４５ａでは、新しいファイルフラグはＹｅｓに設定される。これで、最後のファイル更新の後に生成されたものとしてファイルを識別する。
手順は、以下に議論するステップ１５０と１５２に進む。もしリクエストされたファイルが新しくない場合は、手順はステップ１４２を離れてステップ１４２ｂに進み、リクエストされたファイルが更新されたｉノードリストにあるかどうかをチェックする。もしそうであるなら、手順はステップ１４３ｃに進み、新しいｉノード番号が、利用可能なｉノードリストから、ファイルに割り当てられる。
【００６１】
図１７Ａと図１７Ｂは、ファイル（「ファイル３」オリジナルｉノード番号は１０）の修正と、新しいｉノード番号（「１１」）をファイル３に割り当てることと、ファイルを収容しているディレクトリ（「ａｂｃ１／ｄｅｆ／」）の修正の概略を説明している。
【００６２】
図１６に戻り、もしリクエストされたファイルが更新されたｉノードリストに無かったら、ステップ１４３ｂは新しいｉノード番号を割り当てる。つぎに、ステップ１４４ｂでは、オープン手順は、新しいｉノード番号で新しいｉノードを生成する。
つぎに、ステップ１４５ｂでは、オープン手順は、記憶システムのボリュームまたはキャッシュメモリーからファイルの現在のｉノードを得る。
つぎに、ステップ１４６ｂでは、手順は、現在のｉノード情報の内容を新しいｉノード情報にコピーする。
これにステップ１４７ｂが続いて、そこで新しいファイルフラグが新しいｉノードにおいて「Ｎｏ」に設定される。
ステップ１４８ｂでは、各ディレクトリ（ｄｉｒｅｃｔ）エントリ−のフラグが、ｉノードの中で「Ｎｏ」に設定される。このエントリーは、ディレクトリエントリーで指定されたブロックはファイルの現在のｉノードで使用されていることを知らせる。手順は、それ後ステップ１５０と１５２に進む。
ステップ１５０では、手順は、ファイルハンドルを開かれたｉノードリストからファイルオープンへ割り当てる。
ステップ１５２では、手順は、参考用として使用するためにファイルハンドルをアプリケーションへ戻し、ステップ１５４で終了する。
【００６３】
書き込み手順
書き込み手順１３３ｂは、ファイルにデータを書き込むために呼び出され、そうするためのステップは図１８で説明される。考慮の必要がある三つのケースがある：すなわち、ファイルの終わりを越えてのデータ書き込みの場合（ケースａ）、ファイルのオーバライトで、書き込まれるべきブロックが最後のファイル更新の後で割り当てられた場合（ケースｂ）、ファイルのオーバライトで、書き込まれるべきブロックがアプリケーションサーバ上のクライアントファイルシステムにより共有されている場合（ケースｃ）である。
ケースａでは、コンテンツマネージャ１６上で動作しているマスターファイルシステム（図１）は、ファイルに新しいブロックを割り当てる。ケースｂである第２のケースでは、マスターファイルシステムは、ファイルに新しいブロックを割り当てて、共有リソースへのデータ書き込みを防いでいる。ケースｂでは、ブロックは、マスターファイルシステムだけが使用するので、ブロックはオーバライトされる。
【００６４】
図１８を参照すると、書き込み手順はステップ１６０から始まり、リクエストで指定されたオフセットがファイルの終わりを越えているか否かを見るためのチェックをする。もし越えているなら、ステップ１６２ａに進む。もし越えていないなら、手順はステップ１６２ｂに進む。一般には、オフセットはファイルの先頭からのアドレスである。
ステップ１６２ａでは、書き込み手順は、利用可能なブロックリスト（図９）から新しいブロック番号を割り当てる。つぎに、ステップ１６３ａでは、新しいディレクトリエントリーが、ファイルのｉノードの終わりにブロック番号とともに追加される。また、ダイレクトエントリーのフラグが「Ｙｅｓ」に設定され、ステップ１６３ａは終了する。下記で論議されるステップ１７０と１７２に進む。
一方、もし、ステップ１６０での判定が不成立である場合は、ステップ１６２ｂに進み、書き込まれるファイルのｉノードからのアドレスに対応するダイレクトエントリーの選択を行う。
つぎに、ステップ１６３ｂでは、ダイレクトエントリーについてフラグのチェックが行われる。もしそれが「Ｙｅｓ」であったら、ステップ１６４ｂに進み、もしそうでないなら、ステップ１６４ｃに進む。
ステップ１６４ｂでは、手順はダイレクトエントリーからブロック番号を得て、ステップ１７０、１７２に進む。
もしステップ１６４ｃがステップ１６２ｂに続くのであれば、手順は、リクエストされたファイルに割り当てるために、利用可能なブロックリスト（図９）から新しいブロック番号を選択する。
【００６５】
図１７Ａと図１７Ｂは、どのようにしてファイルが修正されるかも説明している。この図では、ディレクトリ「ｄｉｒｅｃｔ２」は、ファイルに追加される新しいデータ（「Ｍａｒｓ」）を記憶するために、新しいロケーションＡ／Ａ１／２０を識別するように修正される（図１７Ａ参照）。
ステップ１６５ｃでは、ｉノードのダイレクトエントリーのブロック番号は、新しいブロック番号に変更され、次のステップ１６６ｃで、新しいダイレクトエントリーのフラグを「Ｙｅｓ」に設定する。
ステップ１７０では、データは、ブロック番号で指定された場所に書き込まれ、ステップ１７２では、完了メッセージが、Ｉ／Ｏ書き込みリクエストが作成するアプリケーションに返される。つぎに、手順はステップ１７４で終了する。
【００６６】
読み出し手順
読み出し手順１３３ｃは、ファイルからデータを読み出すために呼び出されるもので、  図１９で説明される。ファイル上の読み出し動作は、共有リソースの変更を何も要求しない。このため、この手順は、ファイルのｉノードに従い、リクエストで特定されたデータを単に読み出す。このようにして、図１９が示すように、ステップ１８０は、ファイルのｉノードからアプリケーションが特定したアドレスに対応するダイレクトエントリーを取り出す。
つぎに、ステップ１８３では、データが、ダイレクトエントリーのブロック番号で指定された場所から読み出される。つぎに、ステップ１８４では、データは要求しているアプリケーションに送られ、手順はステップ１８８で終了する。
【００６７】
クローズ手順
この手順は、ファイルの使用を完了させるために呼び出されるもので、図２０で説明される。クローズ手順１３３ｄはステップ１９１から開始され、使用されたｉノードとそのファイル名を更新されたｉノードリストに追加する。これに続くステップ１９２では、前にアプリケーションによる使用のために割り当てたファイルハンドルの割り当て取り消しを行う。開かれたｉノードリストのファイルハンドルのエントリーはＹｅｓに設定される。クローズ手順１３３ｄはステップ１９３で完了する。
【００６８】
削除手順
図２１に示されるこの手順は、存在するファイルを削除するために呼び出される。削除手順１３３ｅがマスターファイルシステムにより呼び出されたときに、削除しようとしているファイルが、その時点で１ないしはそれ以上のアプリケーションサーバ１８により使用されている可能性がある。ファイルを削除することは、マスターファイルシステム（コンテンツマネージャ１６上で実行中）とクライアントファイルシステム（アプリケーションサーバ１８上で実行中）とが共有しているいくつかのリソースを動作させることになる。したがって、マスターファイルシステムがこのような共有リソースを変更できる前に、アプリケーションサーバ１８上で稼働中のアプリケーションがこのようなデータの削除を認識するように、マスターファイルシステムとクライアントファイルシステムとの間である種の同期化をしておく必要がある。
【００６９】
図２１を参照すると、ステップ２０１と２０２は、ディレクトリリストからファイルのエントリーを消去し、ディレクトリリストを含むブロックをキャッシュメモリーから記憶システムへフラッシュすることを含んでいる。これは、エントリーのサイズが小さくて１セグメントに収まるので、同期化は無しに行うことが出来る。セグメントとは、ディスクドライブの読み書きするデータの単位である。したがって、この操作はアトミックである。
【００７０】
クライアントファイルシステムの挙動として三つのケースがある。もしクライアントファイルシステムがファイルを使用している場合は、ファイルに割り当てられたファイルのｉノード情報とブロックはまだ消去されていないので、ファイルに対するＩ／Ｏを継続することが可能である。もしクライアントファイルシステムがファイルを使用していなくても、ファイルあるいはファイルのｉノードを持つディレクトリリストが、クライアントファイルシステムのメモリーにキャッシュされている場合には、クライアントファイルシステムはまだファイルを読み出すことが出来る。もしクライアントファイルシステムがファイルを使用しておらず、ディレクトリリストとファイルのｉノードをキャッシュしていない場合は、クライアントファイルシステムはファイルをそれ以上使用することは出来ない。
このようにして、ステップ２０３では、マスターファイルシステムは、修正されたエントリーを持つブロックが記憶システムの全てに到達するまで待つ。それを行うには、マスターファイルシステムは、ブロックが存在する特定のペアのステータスをチェックするために記憶システムのインターフェイスを使用する。このリクエストでペアの名称が特定される。
【００７１】
ステップ２０４では、無効メッセージが、各クライアントファイルシステムに、ファイルのｉノード番号を付けて送られ、続いて、すべてのクライアントファイルシステムから完了メッセージが来るのを待つ（ステップ２０５）。予定した全ての完了メッセージを受信すると、マスターファイルシステムは、どのクライアントファイルシステムも消去するファイルを使っていないこと、どのクライアントファイルシステムもファイルのｉノード情報を持っていないこと、およびクライアントファイルシステムのすべてがステップ２０１で修正された新しいディレクトリリストを読み出すことを確認する。ステップ２０６では、マスターファイルシステムは、ファイルのために使われていた全てのブロックの割り当てを取り消す。つぎに、ステップ２０７では、ファイルのｉノードが消去され、ｉノードに使用されていたブロックは割り当てを解除される。ステップ２０８では、完了メッセージがファイルの消去を要求していたアプリケーションに送られ、手順はステップ２０９で終了する。
【００７２】
チェック手順
図２２に示される手順は、コンフィギュレーションマネージャプロセス１４ａ（データセンタ１２Ａのマネージメントコンソール１４上で実行；図１）が、更新されたｉノードリストを得るために使用される。ステップ２１１で開始し、マウントポイントがコンフィギュレーションマネージャから取り出される。ステップ２１２では、マスターファイルシステムは、マウントポイントより下に記憶されていて、更新されたｉノードリストにあるファイルのリストを、コンフィギュレーションマネージャに送る。手順は、ステップ２１３で終了する。
【００７３】
更新手順
この手順は、コンフィギュレーションマネージャが、更新されたｉノードリストにあるファイルを更新するために使用され、図２３に示されている。まず、ディレクトリリストが変更され、その結果アプリケーションサーバは更新されたファイルの新しいｉノードを使用することが出来る。その後、全てのクライアントファイルシステムは、更新されたファイルのディレクトリリストとｉノードに対応する、それらのキャッシュデータを無効にするように指示される。このステップ無しでは、クライアントファイルシステムが、更新されたファイルの、古くなったディレクトリリストとｉノードを使い続ける可能性がある。最後に、マスターファイルシステムは、更新されたファイルの古くなったｉノードに関連した情報の割り当てを取り消し、その情報を消去する。
【００７４】
図２３を参照すると、ステップ２２１では、更新されたｉノードリストにある新しいファイルに対して、対応するディレクトリリストにエントリーが追加される。更新されたｉノードリストの更新されたファイルに関して、対応するディレクトリリストのエントリーのｉノード番号が、新しいｉノード番号に変更される。
ステップ２２２では、修正されたディレクトリリストを持つブロックは、キャッシュメモリーから記憶システムへフラッシュされ、ステップ２２３では、ブロックが全ての記憶システムに届くことが出来るように、待ちが挿入される。
つぎに、ステップ２２４では、無効メッセージが、各クライアントファイルシステムに、更新されたファイルのｉノード番号をつけて送られる。
ステップ２２５では、手順は、全てのクライアントファイルシステムから完了メッセージが来るのを待つ。
ステップ２２６では、更新されたファイルの古いｉノードでのみ使用されていたブロックの全ての割り当てを取り消す。
ステップ２２７では、古いｉノードは削除され、古いｉノードによって使用されていた全てのブロックは、割り当てが取り消される。
つぎに、ステップ２２８では、更新されたｉノードリストは消去され、手順はステップ２２９で終了する。
【００７５】
マウントクライアント
コンテンツマネージャ１６のマウントクライアントプロセスは、ローカルマウントポイントテーブルに従って、特定のディレクトリに新しいボリュームをマウントする機能を持つ。このテーブルは、各サーバに記憶されるので、サーバがリブートする時には、マウントクライアントは、ボリュームをマウントするためにローカルマウントポイントテーブルを使用する。リブート後、コンフィギュレーションマネージャはシステムの構成を変更する。この場合、コンフィギュレーションマネージャ上のマウントポイント更新プログラムは、各サーバに対しローカルマウントポイントテーブルを作成し、それをサーバに送る。したがって、マウントクライアントは、新しいローカルマウントポイントテーブルに従って、ボリュームをマウントし、アンマウントする。
【００７６】
図２４はマウントクライアントプロセスのシーケンスを示しており、マネージメントコンソール１４で実行するコンフィギュレーションマネージャ１４ａから、新しいローカルマウントポイントテーブルが来るのを待つ、ステップ２３１で始まる。つぎに、テーブルの各マウントポイントについて、ボリュームは指定されたディレクトリにマウントされる（ステップ２３２）。ステップ２３３では、サーバ上のマウントした各ボリュームについて、もしローカルマウントポイントテーブルにボリュームに対するエントリーがない場合は、ボリュームはアンマウントされ、ステップ２３４では、完了メッセージがマウントポイントアップデートプログラムに送られ、そして手順はステップ２３１に戻り、新しい変更を待つ。
【００７７】
アプリケーションサーバ
アプリケーションサーバ１８は、例えばビデオサーバなどの、アプリケーションを実行するサーバである。アプリケーションは、記憶システム２２に記憶されているファイルを、クライアントファイルシステムを通して使用する。本発明では、アプリケーションはファイルを修正することなく、単に読み出すだけ、としている。
【００７８】
クライアントファイルシステム
クライアントファイルは、記憶システム２２からファイルを探し出し、読み出すために用いられる、サーバ１８で実行するプロセスであり、マスターファイルシステムと交信する必要はない。したがって、クライアントファイルシステムプロセスは、アプリケーションに対して、ファイルを開く、ファイルを読み出す、ファイルを閉じる、およびキャッシュデータを無効にするためのインターフェイスを提供する。無効化のインターフェイスはマスターファイルシステムだけが使用する。
【００７９】
図２５は、クライアントファイルシステムプロセスが、クライアントファイルシステムのサーバ１８上で稼働するアプリケーションからのリクエストを引き受けるのに行うステップを示している。図２５が示すように、クライアントファイルシステムは、ステップ２４１において、アプリケーションからのリクエストを待つ。リクエストを受け取ると、プロセスは、ステップ２４２で、リクエストのタイプに応じて、手順（オープン、読み出す、クローズ、または無効）の一つを呼び出す。
【００８０】
オープン手順
アプリケーションがファイルを使い始めるときには、オープン手順が呼び出される。 図２６は、ステップ２５１で始まるオープン動作のステップを示している。このステップでは、開くファイルのｉノード番号をディレクトリリストから取り出す。
つぎに、ステップ２５２では、ｉノード番号に対応するｉノード情報が、記憶システムあるいはキャッシュメモリーから読み出される。ステップ２５３では、ファイルハンドルが、開かれたｉノードリストから、このファイルオープンのために割り当てられ、ステップ２５６でアプリケーションへ返される。ステップ２５７で手順は終了する。
【００８１】
読み出し手順
この読み出し手順は、ファイルの読み出しであり、そのステップは、基本的には、図１９に示すマスターファイルシステムの読み出し動作により行われる、読み出し動作に用いられるものと同じである。
【００８２】
クローズ手順
この手順は、アプリケーションがファイルの使用を終了するときに呼び出される。  図２７は、ファイルハンドルの割り当て取り消しだけを含む、手順の主なステップを示している。
【００８３】
無効手順
この手順は、マスターサーバにより更新されたキャッシュデータを無効にするために、コンテンツマネージャ１６（図１）のマスターファイルシステムにより呼び出される。無効にした後は、クライアントファイルシステムは、ファイルシステムを実行しているアプリケーションが必要とする場合は、更新されたディレクトリリスト、新しいｉノードなどを読み出す。
【００８４】
図２８に使用されるステップを示す。最初に、手順は、リクエストにより指定されたｉノードをどのアプリケーションも使わなくなるまで待つ（ステップ２６１）。
つぎに、ステップ２６２では、手順は、中にｉノードのエントリーがあるディレクトリリストとｉノード自身とファイルに割り当てられたブロックを含む、キャッシュされたデータを無効にし、ステップ２６３では、完了メッセージをマスターファイルシステムに送り、ステップ２６４で完了する。
【００８５】
マウントクライアント
マウントクライアントは、ローカルマウントポイントテーブルに従って、特定のディレクトリに新しいボリュームをマウントする。マウントクライアントプロセスで用いられるステップは、基本的にはマスターファイルシステムで用いられるものと同じであり、したがって図２４で示されている。
【００８６】
記憶システム
記憶システム２２は、論理記憶装置の技術を用いており、したがって、図１に示すように、マスターボリューム３４や複製されたボリューム３６を含む複数のボリュームで構成される。
各記憶システムは、少なくとも１台のディスクコントローラ２４と、ディスクコントローラとボリュームの間のＩ／Ｏパスを含んでいる。マスターボリュームは、オリジナルファイルを保有するボリュームであり、マスターファイルシステムにより管理される。
複製されたボリュームは、それぞれがマスターボリュームの複製であり、アプリケーションサーバにより使用される。
ディスクコントローラでは、ブロックＩ／Ｏプロセスとリモートコピープロセスの二つの処理が実行されている。ブロックＩ／Ｏプロセスは、サーバからのＩ／Ｏリクエストを処理する仕事をする。
リモートコピープロセスは、マスターボリュームからデータを少なくとも１個の複製されたボリュームにコピーする仕事をする。マスターボリュームと複製されたボリュームは、同じ記憶システムにあること、あるいは異なった記憶システムにある事が出来る。同じ記憶システムの場合は、データは内部のＩ／Ｏパス経由でコピーされる。異なった記憶システムの場合には、データは記憶システム間のＷＡＮネットワークを経由してコピーされる。
ペアテーブルは、どのボリュームがどのボリュームに複製されたのかを示す。
【００８７】
ブロックＩ／Ｏプロセス
図２９は、ブロックＩ／Ｏプロセス２６のステップを示す。ステップ２７１では、ブロックＩ／ＯプロセスはサーバからのＩ／Ｏリクエストを待つ。
リクエストを受け取ると、プロセスはステップ２７２でタイプをチェックする。リクエストには、データ読み出しとデータ書き込みの、二つのタイプがある。もしリクエストが読み出しであれば、ステップ２７３は読み出し手順を呼び出し、もしそれが書き込みリクエストであれば、書き込み手順が呼び出される。手順は、次にステップ２７１に戻り、次のリクエストを待つ。
【００８８】
図３０は読み出し手順を示す。まず、手順は、ブロックＩ／Ｏプロセスがデータを読み出す場所を得る（ステップ２８１）。サーバからのＩ／Ｏリクエストはこのような種類の情報を含んでいる。例えば、ＳＣＳＩプロトコルの読み出しコマンドは、ＳＣＳＩターゲットＩＤ、ＬＵＮ、オフセットおよびデータのサイズを含んでいる。この場合、場所は、ＳＣＳＩターゲットＩＤ、ＬＵＮ、オフセットおよびサイズによって指定される。手順は、次にその場所からデータを読み出し（ステップ２８２）、それをサーバに完了メッセージを付けて送る（ステップ２８３）。
【００８９】
図３１は、ブロックＩ／Ｏプロセスによって呼び出される書き込み手順の図である。ステップ２９１から始まり、プロセスは送られたデータが書き込まれる場所を知る。次に、データをその場所に書き込み（ステップ２９２）、続いてステップ２９３で、完了メッセージを返す。次に、その位置がペアテーブル（図４）のいずれかのボリュームに関係づけられるかを判定するために、ステップ２９４でチェックが行われる。もし関係づけ出来ない場合は、手順はステップ２９８で終了する。しかし、もし関係づけ出来る場合は、どのペアにその位置が属するかを識別するために、手順はステップ２９５へ進む。ステップ２９６では、このＩ／Ｏに対するリモートコピー（ＲＣ）リクエストが生成される。 図３２はＲＣリクエストの構造の例である。
【００９０】
図３２が示すように、ＲＣリクエストは、４つの行、すなわちプライマリー、セカンダリー、アドレス、およびサイズを持っている。プライマリーは、ペアのプライマリーボリューム情報を識別する。セカンダリーは、ペアのセカンダリーボリューム情報である。アドレスは、データが書き込まれたアドレスである。サイズは、書き込まれたデータのサイズである。
【００９１】
図３１に戻り、ステップ２９７では、手順は、ＲＣリクエストのリストであるＲＣキューにＲＣリクエストを挿入する。リモートコピープロセスは、このＲＣキューを使って、どのデータをどの位置にコピーする必要があるのかを知る。図３３は、多数のＲＣリクエストを示しているＲＣキューの例を示す。
【００９２】
リモートコピープロセス
リモートコピープロセスは図３４で示されており、プライマリー記憶システムから来るデータがあるかどうかを確定するためのステップ３０１から始まる。もしデータがあるなら、受信手順を呼び出すためにステップ３０１ａに進む。もしデータがないなら、プロセスはステップ３０２に行く。これは、セカンダリー記憶システムで実行しているリモートコピープロセスがプライマリー記憶システムから更新されたデータを受け取るケースである。
【００９３】
ステップ３０２では、ＲＣキューに保留されているＲＣリクエストがあるかどうかを判定する。もしあるなら、ステップ３０２ａで送信手順を呼び出す。もしないなら、ステップ３０３に進む。これは、プライマリー記憶システムで実行しているリモートコピープロセスがセカンダリー記憶システムに更新されたデータを送るケースである。
【００９４】
ステップ３０３では、ＲＣキューがペアテーブルの構成を変えるリクエストを持っているかどうかを知るためにチェックする。もし持っているなら、ステップ３０３ａでリクエストに従ってテーブルを変更する。もし持っていなければ、ステップ３０４に進む。これは、コンフィギュレーションマネージャがリクエストを送り、リモートコピープロセスがテーブルを再構成するケースである。
【００９５】
ステップ３０４では、ペアのステータスチェックのリクエストがあるか、ＲＣキューのチェックが行われる。もしあるなら、ステップ３０４ａはステータス手順を呼びだし、もしないなら、ステップ３０１へ戻る。これは、マスターファイルシステムが、更新されたデータの全てがセカンダリー記憶システムの全てに届いているかを知ることを希望するケースである。
【００９６】
ＲＣプロセスのステップ３０２ａで呼び出される送信手順は、図３５で示される。ステップ３１１では、手順は、ＲＣリクエストをＲＣキューから取り出し、プライマリーボリュームからリクエストにより特定された位置からリクエストされた対応するデータを読み出し（ステップ３１２）、そのデータをセカンダリーボリュームの識別子と位置とともに指定された記憶システムに送る（ステップ３１３）。
【００９７】
図３６は受信手順を示す。呼び出されると、ステップ３２１で、読み出し手順は、セカンダリーボリュームの識別子と受信したデータを書き込むアドレスとを得る。つぎに、ステップ３２２では、データをその位置に書き込む。最後に、ステップ３２３では、完了メッセージがプライマリー記憶システムに送られる。
【００９８】
図３７は、リモートコピープロセスのステップ３０４ａで呼び出されるステータス手順を示す。呼び出されると、手順は、ステップ３３１で、ＲＣキューにおいて特定のペアに対するＲＣリクエストがあるかどうかを知るためにチェックを行う。もしこのようなリクエストが存在するならば、手順は、ステップ３３２で、そのペアに対する全てのリクエストが完了するまで待ち、次に、ステップ３３３では、サーバに完了メッセージを返す。もし、ステップ３３１で、ＲＣキューに特定のペアに対するＲＣリクエストが無いと判断された場合は、手順は単に完了メッセージをサーバに送る。
【００９９】
結論
要約すると、サーバがデータを共有し、単にデータを読み出したりする、多くのクラスターサーバおよび分散されたクラスターサーバの間でデータを分散および共有するための装置と方法が開示された。このようなサーバの例は、ＷＥＢサーバ、ビデオサーバおよびコンテンツディストリビューションサーバである。
【０１００】
【発明の効果】
プライマリーデータセンタの記憶システムはファイルを自分から他のデータセンタの記憶システムにブロックレベル転送を用いてコピーするので、ファイルシステムの助けを必要としない。これにより、ＣＰＵ負荷またはサーバのＩ／Ｏバンド幅は無駄にされないので、データ転送速度を制約せず、また高めることが出来る。
【０１０１】
【図面の簡単な説明】
【 図１】本発明を利用するために構成された、プライマリー記憶システムと複数のセカンダリー記憶システムを含む、代表的なデータ処理システムのブロックダイアグラムである。
【図２】プライマリー記憶システムとセカンダリー記憶システム上のファイルの位置を識別するために、図１のデータ処理システムのコンテンツマネージャにより管理されるデータ構造の一部を形成する、グローバルマウントポイントテーブルの説明である。
【図３】それぞれのペアがプライマリー記憶システムの記憶エリアであり、１ないしはそれ以上のセカンダリー記憶システムの記憶エリアである、記憶エリアのペアを識別するのに用いられるペアテーブルの説明である。
【図４】セカンダリー記憶システムに使用されるであろうローカルマウントポイントテーブルの説明である。
【図５】どのファイルがディレクトリにあるかを識別する情報を持っている、特定のディレクトリに対するディレクトリリストの説明である。
【図６】ファイルに関連する特定のファイルと属性の場所を識別する、ｉノードリストの例である。
【図７Ａ】図５のディレクトリリストと図６のｉノードリストとの間の関係の図による説明である。
【図７Ｂ】図５のディレクトリリストと図６のｉノードリストとの間の関係の図による説明である。
【図８】更新されたｉノードリストの説明である。
【図９】利用可能なブロックリストを示す。
【図１０】利用可能なｉノードリストを示す。
【図１１】開かれたｉノードリストを示す。
【図１２】ファイル更新シーケンスを説明するフロー図である。
【図１３】システム構成を変更するためのステップのフロー図である。
【図１４】ファイル更新チェックの主要なステップを説明するフロー図である。
【図１５】ファイルオペレーション手順を呼び出すための、マスターファイルシステムでの主要なステップを示す。
【図１６】マスターファイルシステムにより呼び出された、オープン手順を説明するフロー図である。
【図１７Ａ】オープン手順でファイルを修正する際に使用される、利用可能なｉノードリストから新しいｉノードを選択する事についての説明である。
【図１７Ｂ】オープン手順でファイルを修正する際に使用される、利用可能なｉノードリストから新しいｉノードを選択する事についての説明である。
【図１８】マスターファイルシステムにより呼び出された、書き込み手順を説明するフロー図である。
【図１９】マスターファイルシステムにより呼び出された、読み出し手順を説明するフロー図である。
【図２０】マスターファイルシステムにより呼び出された、クローズ手順を説明するフロー図である。
【図２１】マスターファイルシステムにより呼び出された、削除手順を説明するフロー図である。
【図２２】マスターファイルシステムにより呼び出された、チェック手順を説明するフロー図である。
【図２３】ｉノードリストを更新するために、マスターファイルシステムにより呼び出された、更新手順を説明するフロー図である。
【図２４】特定のディレクトリに新しいボリュームをマウントするために、マウントクライアントプロセスによりとられるシーケンスを説明する。
【図２５】ファイルシステム手順を呼び出すためにクライアントファイルシステムプロセスにより取られるシーケンスステップを示す。
【図２６】クライアントファイルシステムプロセスのオープン手順に対する呼び出しにより取られるステップを説明する。
【図２７】クライアントファイルシステムプロセスのクローズ手順に対する呼び出しにより取られるステップを説明する。
【図２８】クライアントファイルシステムプロセスの無効化手順に対する呼び出しにより取られるステップを説明する。
【図２９】図１の記憶システムにより実行されるブロックＩ／Ｏプロセスの処理手順のステップを示す。
【図３０】 図２９のブロックＩ／Ｏプロセスにより呼び出される際の、読み出し手順の動作を説明する。
【図３１】図２９のブロックＩ／Ｏプロセスにより呼び出される際の、書き込み手順の動作を説明する。
【図３２】書き込み手順によりなされるであろうリモートコピー（ＲＣ）リクエストの説明である。
【図３３】図１の記憶システムにより用いられる可能性のあるリモートコピーキューの例である。
【図３４】リモートコピープロセスにしたがって、図１の記憶システムにより取られるステップを説明する。
【図３５】図３４のリモートコピープロセスにより呼び出される送信手順のステップを示す。
【図３６】図３４のリモートコピープロセスにより呼び出される受信手順のステップを示す。
【図３７】図３４のリモートコピープロセスにより呼び出されるステータス手順のステップを示す。
【０１０２】
【符号の説明】
１４・・・マネージメントコンソール、１４ａ・・・コンフィギュレーションマネージャ、１４ｂ・・・ファイル更新プロセス、１４ｃ・・・コンフィグ変更プロセス、１４ｄ・・・更新ファイルチェックプログラム、１４ｅ・・・グローバルマウントポイントテーブル、１６・・・コンテンツマネージャ、１６ａ・・・アプリケーション、１６ｂ・・・マスターファイルシステム、１６ｃ・・・マウントクライアント、１６ｄ・・・メタデータ、１６ｅ・・・ローカルマウントポイントテーブル、１６ｆ・・・更新されたｉノードリスト、１８ｂ・・・クライアントファイルシステム、１８ｃ・・・マウントクライアント、１８ｄ・・・メタデータ、１８ｅ・・・ローカルマウントポイントテーブル、２２Ａ…記憶システムＡ、２４・・・ディスクコントローラ、２６・・・ブロックＩ／Ｏプロセス、２８・・・リモートコピープロセス、３０・・・ペアテーブル、３４・・・マスターボリューム、３６・・・複製されたボリューム