(57)【要約】【課題】複数のキャッシュメモリに格納するデータの版数を管理できるようにした。【解決手段】第１のアクセス制御装置２０ａは、所定ブロックの更新要求を受けたとき、所定ブロックの最新データが第１のアクセス制御装置２０ａのキャッシュメモリ２１に記憶されていない場合に、最新データが自装置のキャッシュメモリ２１に記憶された第２のアクセス制御装置２０ｂから、最新データに付加されたバージョン番号を取得する。さらに、第１のアクセス制御装置２０ａは、所定ブロックを更新する更新データを第１のアクセス制御装置２０ａのキャッシュメモリに格納するとともに、更新データに対して、第２のアクセス制御装置２０ｂから取得したバージョン番号を基に、新たなバージョン番号を付加する。【選択図】図１
2013222373.tif 000002
【特許請求の範囲】
【請求項１】
ファイルが格納される記憶装置と、
前記記憶装置に対するアクセスをそれぞれ制御するととともに、前記記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリをそれぞれ備える複数のアクセス制御装置と、
を有し、
前記複数のアクセス制御装置のうちの第１のアクセス制御装置は、
所定ブロックの更新要求を受けたとき、当該所定ブロックの最新データが当該第１のアクセス制御装置のキャッシュメモリに記憶されていない場合に、前記複数のアクセス制御装置のうち、前記最新データが自装置のキャッシュメモリに記憶された第２のアクセス制御装置から、当該最新データに付加されたバージョン番号を取得し、
前記所定ブロックを更新する更新データを前記第１のアクセス制御装置のキャッシュメモリに格納するとともに、当該更新データに対して、前記第２のアクセス制御装置から取得したバージョン番号を基に、新たなバージョン番号を付加する、
ことを特徴とするストレージシステム。
【請求項２】
前記第２のアクセス制御装置は、前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に通知するとともに、当該最新データをバージョン番号とともに所定の不揮発性記憶装置に追記した後、前記第１のアクセス制御装置に対して前記所定ブロックの更新を許可することを特徴とする請求項１記載のストレージシステム。
【請求項３】
前記複数のアクセス制御装置は、不揮発性のローカル記憶装置をそれぞれ備え、
前記第２のアクセス制御装置は、
前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に通知するとともに、当該最新データおよび当該最新データのバージョン番号を、当該第２のアクセス制御装置が備える前記ローカル記憶装置に追記した後、前記第１のアクセス制御装置に対して前記所定ブロックの更新を許可し、
前記最新データおよび当該最新データのバージョン番号を前記ローカル記憶装置に追記したタイミングと非同期に、当該ローカル記憶装置に追記した前記最新データを前記記憶装置に追記する、
ことを特徴とする請求項２記載のストレージシステム。
【請求項４】
前記複数のアクセス制御装置の１つが異常停止した場合、異常停止したアクセス制御装置が復旧した後、前記複数のアクセス制御装置のうちの所定のアクセス制御装置は、すべてのアクセス制御装置の前記ローカル記憶装置に記憶された、ブロックごとのバージョン番号に基づき、最新のバージョン番号に対応付けられたデータをバージョン番号とともに当該所定のアクセス制御装置のキャッシュメモリおよび前記ローカル記憶装置に格納して、前記ストレージシステムの運用を再開させることを特徴とする請求項３記載のストレージシステム。
【請求項５】
前記第２のアクセス制御装置は、前記第１のアクセス制御装置からの通知要求に応じて前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に送信した後、前記第１のアクセス制御装置からデータ更新の許可を求めるための許可依頼を受信したとき、前記最新データおよび当該最新データのバージョン番号を当該第２のアクセス制御装置が備える前記ローカル記憶装置に追記し、受信した前記許可依頼に対してデータ更新を許可するための応答を送信することを特徴とする請求項３または４記載のストレージシステム。
【請求項６】
前記第１のアクセス制御装置は、
前記所定ブロックの前記最新データがキャッシュメモリに格納されているかを示すステータス情報と、キャッシュメモリに格納されている前記所定ブロックのデータに付加されたバージョン番号とを通知するように要求するための通知要求をブロードキャストし、
前記通知要求に応じて返信された前記ステータス情報に基づいて、前記最新データが自装置のキャッシュメモリに記憶されたアクセス制御装置を判別するとともに、前記通知要求に応じて返信されたバージョン番号に基づいて、前記更新データに付加する新たなバージョン番号を決定する、
ことを特徴とする請求項２〜４のいずれか１項に記載のストレージシステム。
【請求項７】
前記通知要求を受信した各アクセス制御装置は、当該通知要求に対する応答情報をブロードキャストし、
前記通知要求を受信したすべてのアクセス制御装置から前記第１のアクセス制御装置に対して正常応答が出力された場合に、前記第１のアクセス制御装置を除くすべてのアクセス制御装置において、前記所定ブロックについてのデータ更新およびデータ参照が禁止される、
ことを特徴とする請求項６記載のストレージシステム。
【請求項８】
記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリを備えるコンピュータに、
所定ブロックの更新要求を受けたとき、当該所定ブロックの最新データが前記コンピュータのキャッシュメモリに記憶されていない場合に、それぞれキャッシュメモリを備える他の複数のコンピュータのうち、前記最新データが自装置のキャッシュメモリに記憶された他のコンピュータから、当該最新データに付加されたバージョン番号を取得し、
前記所定ブロックを更新する更新データを前記コンピュータのキャッシュメモリに格納するとともに、当該更新データに対して、前記他のコンピュータから取得したバージョン番号を基に、新たなバージョン番号を付加する、
処理を実行させるキャッシュ制御プログラム。
【請求項９】
ファイルが格納される記憶装置と、前記記憶装置に対するアクセスをそれぞれ制御するととともに、前記記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリをそれぞれ備える複数のアクセス制御装置と、を有するストレージシステムにおけるキャッシュ制御方法であって、
前記複数のアクセス制御装置のうちの第１のアクセス制御装置が、
所定ブロックの更新要求を受けたとき、当該所定ブロックの最新データが当該第１のアクセス制御装置のキャッシュメモリに記憶されていない場合に、前記複数のアクセス制御装置のうち、前記最新データが自装置のキャッシュメモリに記憶された第２のアクセス制御装置から、当該最新データに付加されたバージョン番号を取得し、
前記所定ブロックを更新する更新データを前記第１のアクセス制御装置のキャッシュメモリに格納するとともに、当該更新データに対して、前記第２のアクセス制御装置から取得したバージョン番号を基に、新たなバージョン番号を付加する、
ことを特徴とするキャッシュ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージシステム、キャッシュ制御プログラムおよびキャッシュ制御方法に関する。
【背景技術】
【０００２】
近年、ファイルシステムの一種として、ログ構造化ファイルシステムが注目されている。ログ構造化ファイルシステムでは、ファイルを分割したブロックのデータが更新される際、更新後のデータは、更新前のデータとは別の記憶領域に格納されて、更新前のデータは上書きされない。このような処理により、データ更新時に障害が発生してデータが壊れる事態を回避する、あるいは、スナップショットをとることを可能にするといった効果が得られる。
【０００３】
一方、複数のサーバにキャッシュ領域を分散して配置することで分散キャッシュが構成されたストレージシステムがある。分散キャッシュでは、例えば、複数のキャッシュ領域間でデータの整合性がとられるように、データの参照や更新の処理が制御される。
【０００４】
なお、分散キャッシュに関連する技術の例としては、ファイルサーバがブロックごとのバージョン情報を記憶し、キャッシュ領域をそれぞれ備える複数のクライアントが、自装置にキャッシュされたデータが最新かをファイルサーバに問い合わせることを可能にしたものがある。
【０００５】
また、データベースの管理方法の例としては、更新前後のデータを保持しておくマルチバージョン方式を使用してデータベースを管理するものがある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−２０４００８号公報
【特許文献２】特開平７−３１９７５０号公報
【特許文献３】特開２００２―２７８８１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、分散キャッシュを使用したシステムにおいては、複数のクライアントは、それぞれのキャッシュ領域に格納するデータの版数を管理する機能を備えていない。このため、分散キャッシュを使用したシステムでは、ログ構造化ファイルシステムのように、更新されるたびにデータを残しておくことができない。
【０００８】
１つの側面では、本発明は、複数のキャッシュメモリに格納するデータの版数を管理できるようにしたストレージシステム、キャッシュ制御プログラムおよびキャッシュ制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
１つの案では、ファイルが格納される記憶装置と、記憶装置に対するアクセスをそれぞれ制御するととともに、記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリをそれぞれ備える複数のアクセス制御装置と、を有するストレージシステムが提供される。このストレージシステムにおいて、複数のアクセス制御装置のうちの第１のアクセス制御装置は、所定ブロックの更新要求を受けたとき、所定ブロックの最新データが第１のアクセス制御装置のキャッシュメモリに記憶されていない場合に、複数のアクセス制御装置のうち、最新データが自装置のキャッシュメモリに記憶された第２のアクセス制御装置から、最新データに付加されたバージョン番号を取得する。さらに、第１のアクセス制御装置は、所定ブロックを更新する更新データを第１のアクセス制御装置のキャッシュメモリに格納するとともに、更新データに対して、第２のアクセス制御装置から取得したバージョン番号を基に、新たなバージョン番号を付加する。
【００１０】
また、１つの案では、記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリを備えるコンピュータに、上記の第１のアクセス制御装置と同様の処理を実行させるキャッシュ制御プログラムが提供される。
【００１１】
さらに、１つの案では、上記のストレージシステムにおけるキャッシュ制御方法が提供される。
【発明の効果】
【００１２】
１態様によれば、ストレージシステム、キャッシュ制御プログラムおよびキャッシュ制御方法において、複数のキャッシュメモリに格納するデータの版数を管理できる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態に係るストレージシステムの構成例およびその動作例を示す図である。
【図２】第２の実施の形態に係るストレージシステムの全体構成例を示す図である。
【図３】フロントエンドのハードウェア構成例を示す図である。
【図４】フロントエンドが備える処理機能の構成例を示すブロック図である。
【図５】内部キャッシュおよびオフコアキャッシュを用いたキャッシュ制御の例について説明するための図である。
【図６】ファイル管理部によるファイル管理のためのデータベース構造の例を示す図である。
【図７】ステータスが「Ｍｏｄｉｆｉｅｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
【図８】ステータスが「Ｓｈａｒｅｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
【図９】更新を行うフロントエンドのステータスが「Ｓｈａｒｅｄ」である場合の処理例を示すシーケンス図である。
【図１０】ステータスが「Ｉｎｖａｌｉｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
【図１１】ステータスが「Ｉｎｖａｌｉｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
【図１２】参照を行うフロントエンドのステータスが「Ｉｎｖａｌｉｄ」である場合の処理例を示すシーケンス図である。
【図１３】更新を行うフロントエンドのステータスが「Ｉｎｖａｌｉｄ」である場合の処理例を示すシーケンス図である。
【図１４】ファイル管理部による応答処理手順の例を示すフローチャートである。
【図１５】ファイル管理部による応答処理手順の例を示すフローチャートである。
【図１６】ステータスの遷移例を示す図である。
【図１７】オフコアキャッシュからバックエンドへの書き出し処理例を示すフローチャートである。
【図１８】代表サーバのファイル管理部によるデータ復旧処理手順の例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るストレージシステムの構成例およびその動作例を示す図である。図１に示すストレージシステムは、記憶装置１０と、複数のアクセス制御装置２０ａ，２０ｂ，・・・とを備える。記憶装置１０と、複数のアクセス制御装置２０ａ，２０ｂ，・・・とは、ネットワークを介して互いに接続されている。なお、アクセス制御装置は、任意の数だけ設けることができる。
【００１５】
記憶装置１０には、ファイルが格納される。アクセス制御装置２０ａ，２０ｂ，・・・は、それぞれ、記憶装置１０に対するアクセスを制御する。また、アクセス制御装置２０ａ，２０ｂ，・・・のそれぞれは、キャッシュメモリ２１を備える。キャッシュメモリ２１には、記憶装置１０に格納するファイルが、例えば一定長のブロック単位で一時的に記憶される。
【００１６】
なお、アクセス制御装置２０ａ，２０ｂ，・・・のそれぞれは、ローカル記憶装置２２を備えていてもよい。キャッシュメモリ２１は揮発性の記憶装置であるのに対し、ローカル記憶装置２２は不揮発性の記憶装置である。
【００１７】
このストレージシステム１においては、記憶装置１０に格納されるファイルは、ログ構造化ファイルシステムを用いて管理される。記憶装置１０に格納されたファイルのブロックが更新される際は、更新後のブロックのデータが、更新前のブロックのデータとは異なる記憶領域に格納され、更新前のブロックは上書きされない。
【００１８】
一方、アクセス制御装置２０ａ，２０ｂ，・・・のそれぞれは、ブロックのデータにバージョン番号を付加してキャッシュメモリ２１に格納する。バージョン番号は、ブロックのデータが更新されるたびに新たな値に変更される。下記に示す処理により、アクセス制御装置２０ａ，２０ｂ，・・・のそれぞれは、ブロックの最新データがどのアクセス制御装置のキャッシュメモリ２１に格納されている場合でも、ブロックのデータを更新する際に正しいバージョン番号を生成して付加することが可能になっている。
【００１９】
以下、アクセス制御装置２０ａが、図示しないユーザ端末装置などからの要求に応じて、所定ブロックを更新する際の処理例について説明する。
まず、所定ブロックの最新データが、アクセス制御装置２０ｂのキャッシュメモリ２１に格納されているが、アクセス制御装置２０ａのキャッシュメモリ２１には格納されていないものとする。この時点での最新データには、バージョン番号として「ｖｅｒｓｉｏｎ＃１」が付加されている。
【００２０】
この状態から、アクセス制御装置２０ａが所定ブロックのデータを更新する際には、次のような処理が行われる。アクセス制御装置２０ａは、最新データを保持しているアクセス制御装置２０ｂから、最新データに付加されたバージョン番号「ｖｅｒｓｉｏｎ＃１」を取得する（矢印Ａに対応）。次に、アクセス制御装置２０ａは、所定ブロックについての新たな更新データを、アクセス制御装置２０ａのキャッシュメモリ２１に格納する。これとともに、アクセス制御装置２０ａは、アクセス制御装置２０ｂから取得したバージョン番号に基づいて、新たなバージョン番号「ｖｅｒｓｉｏｎ＃２」を生成し、新たな更新データに新たなバージョン番号「ｖｅｒｓｉｏｎ＃２」を付加する。
【００２１】
このような処理により、アクセス制御装置２０ａは、新たな更新データに対して正しいバージョン番号を付加することができる。従って、アクセス制御装置２０ａは、自装置のキャッシュメモリ２１に格納されているデータの版数を管理できる。ストレージシステム１の全体で考えると、各アクセス制御装置に分散して配置されたキャッシュメモリ２１に格納される、同じブロックについてのデータの版数を、正しく管理することができる。従って、分散キャッシュを使用したシステムにおいて、ファイルの管理にログ構造化ファイルシステムを用いることができるようになる。
【００２２】
なお、アクセス制御装置２０ｂは、アクセス制御装置２０ａに上記の所定ブロックのデータの更新を許可する前に、「ｖｅｒｓｉｏｎ＃１」のデータを不揮発性の記憶装置に追記することが望ましい。これにより、アクセス制御装置２０ａによって更新される前のデータを確実に保存しておくことができる。また、記録の方法を追記とすることで、さらに古いバージョン番号が付加された同じブロックのデータが不揮発性の記憶装置に記憶されていた場合に、そのデータを残しておくことができる。
【００２３】
ここで、キャッシュメモリ２１内のデータを追記する際の格納先は、記憶装置１０とすることができる。しかしながら、アクセス制御装置２０ｂは、例えば、キャッシュメモリ２１内のデータをまずローカル記憶装置２２に追記するようにしてもよい（矢印Ｂに対応）。そして、アクセス制御装置２０ｂは、ローカル記憶装置２２に格納したデータおよびバージョン番号を、ローカル記憶装置２２への格納タイミングとは非同期の任意のタイミングで、記憶装置１０に追記する（矢印Ｃに対応）。
【００２４】
これにより、データの追記を、データを記憶装置１０に追記するよりも高速に実行できる。このため、アクセス制御装置２０ａに対してデータの更新を許可するまでの時間を短縮することもできる。
【００２５】
〔第２の実施の形態〕
図２は、第２の実施の形態に係るストレージシステムの全体構成例を示す図である。図２に示すストレージシステム１００は、バックエンド２００と、複数のフロントエンド３００ａ〜３００ｃと、複数のクライアント４００ａ〜４００ｅとを備える。
【００２６】
バックエンド２００は、複数のクライアント４００ａ〜４００ｅに対して大容量の不揮発性の記憶領域を提供する。図２の例では、このような記憶領域が記憶装置２０１によって実現される。また、バックエンド２００は、記憶装置２０１に対するデータの読み書きを制御するデータ格納サーバ２０２を備える。このようなバックエンド２００は、例えば、オブジェクトストレージを構成する。
【００２７】
データ格納サーバ２０２は、記憶装置２０１に記憶されるデータを、ログ構造化ファイルシステムを用いて管理する。データ格納サーバ２０２は、記憶装置２０１に格納されたファイルの更新が要求された際に、更新前のファイルを上書きせずに、更新後のファイルを記憶装置２０１に追記する。このようなファイル管理方法により、データ格納サーバ２０２は、例えば、任意の更新時点でのファイルのスナップショットを出力することが可能になっている。
【００２８】
なお、以下の説明では、データ格納サーバ２０２を通じて記憶装置２０１にデータを格納することを、「バックエンド２００にデータを格納する」と記述する。また、データ格納サーバ２０２を通じて記憶装置２０１からデータを読み出すことを、「バックエンド２００からデータを読み出す」と記述する。
【００２９】
複数のフロントエンド３００ａ〜３００ｃは、ネットワーク１１０を介してバックエンド２００のデータ格納サーバ２０２と接続されている。また、フロントエンド同士は、ネットワーク１１０を介して互いに通信可能になっている。なお、バックエンド２００に接続されるフロントエンドの数は、任意に選択可能である。
【００３０】
また、フロントエンド３００ａ〜３００ｃのそれぞれには、１つ以上のクライアントが接続される。図２では例として、フロントエンド３００ａにクライアント４００ａ，４００ｂが接続され、フロントエンド３００ｂにクライアント４００ｃが接続され、フロントエンド３００ｃにクライアント４００ｄ，４００ｅが接続されている。
【００３１】
フロントエンド３００ａ〜３００ｃのそれぞれは、図１に示したアクセス制御装置の一例であり、クライアントに対して、バックエンド２００へのインタフェースを提供するサーバ装置である。フロントエンド３００ａ〜３００ｃのそれぞれは、クライアントからの要求に応じて、バックエンド２００に対するデータの格納、およびバックエンド２００からのデータの読み出しを制御する。
【００３２】
クライアント４００ａ〜４００ｅのそれぞれは、バックエンド２００にアクセスするためにユーザによって使用されるユーザ端末装置である。
図３は、フロントエンドのハードウェア構成例を示す図である。この図３では、例としてフロントエンド３００ａについて説明するが、フロントエンド３００ｂ，３００ｃも、同様のハードウェア構成によって実現される。
【００３３】
フロントエンド３００ａは、図３に示すようなコンピュータとして実現することができる。フロントエンド３００ａは、ＣＰＵ（Central Processing Unit）３０１によって装置全体が制御されている。ＣＰＵ３０１には、バス３０８を介して、ＲＡＭ（Random Access Memory）３０２と複数の周辺機器が接続されている。
【００３４】
ＲＡＭ３０２は、フロントエンド３００の主記憶装置として使用される。ＲＡＭ３０２には、ＣＰＵ３０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ３０２には、ＣＰＵ３０１による処理に必要な各種データが格納される。
【００３５】
バス３０８に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）３０３、グラフィック処理装置３０４、入力インタフェース３０５、光学ドライブ装置３０６および通信インタフェース３０７がある。
【００３６】
ＨＤＤ３０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ３０３は、フロントエンド３００の二次記憶装置として使用される。ＨＤＤ３０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、ＳＳＤ（Solid State Disk）などの他の種類の不揮発性記憶装置を使用することもできる。
【００３７】
グラフィック処理装置３０４には、モニタ３０４ａが接続されている。グラフィック処理装置３０４は、ＣＰＵ３０１からの命令に従って、画像をモニタ３０４ａに表示させる。なお、モニタ３０４ａは、例えば、液晶ディスプレイである。
【００３８】
入力インタフェース３０５には、キーボード３０５ａ、マウス３０５ｂなどの入力装置が接続されている。入力インタフェース３０５は、入力装置からの出力信号をＣＰＵ３０１に送信する。
【００３９】
光学ドライブ装置３０６は、レーザ光などを利用して、光ディスク３０６ａに記録されたデータの読み取りを行う。光ディスク３０６ａは、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク３０６ａには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）などがある。
【００４０】
通信インタフェース３０７は、ネットワークを通じて、バックエンド２００のデータ格納サーバ２０２や、クライアント４００ａ〜４００ｅなどの他の装置との間でデータを送受信する。
【００４１】
以上のハードウェア構成により、本実施の形態のフロントエンド３００ａ〜３００ｃが実現される。なお、データ格納サーバ２０２およびクライアントについても、図３に示したようなコンピュータとして実現することができる。
【００４２】
ところで、フロントエンド３００ａ〜３００ｃのそれぞれは、バックエンド２００に格納すべきデータまたは格納するデータを自装置内のメモリにキャッシュする機能を備える。キャッシュデータが複数のフロントエンド３００ａ〜３００ｃに分散して配置されることから、フロントエンド３００ａ〜３００ｃのそれぞれは、他のフロントエンドとの間でキャッシュコヒーレンシが保たれるような分散キャッシュファイルシステムを用いて、キャッシュデータを管理する必要がある。
【００４３】
キャッシュコヒーレンシが保たれるように分散キャッシュを管理する方法としては、例えば、複数のノードでほぼ同時にキャッシュデータの更新が発生した場合に、先にキャッシュデータを更新したノードにおける更新後のキャッシュデータがバックエンドに反映されて、そのノードでの更新の権利が剥奪された後、次のノードに更新の権利が付与されるようにする方法がある。
【００４４】
しかしながら、本実施の形態では、ログ構造化ファイルシステムを用いてバックエンド２００のデータが管理される。このため、本実施の形態のストレージシステム１００では、更新が発生するたびに、更新後のキャッシュデータが上書きされずに残っている必要がある。上記の分散キャッシュの管理方法は、このような機能が実装されていないため、ログ構造化ファイルシステムにそのまま適用することはできない。
【００４５】
また、上記の分散キャッシュの管理方法では、キャッシュデータが更新されるたびに更新後のキャッシュデータがバックエンド２００に格納される。このような方法では、更新されたキャッシュデータがバックエンド２００に格納されるまで、そのキャッシュデータを新たに更新する処理を実行できない。このため、キャッシュデータに対する多くの更新要求が発生した場合には、すべての更新要求に対する応答を返すまでに長い時間がかかってしまう。特に、オブジェクトストレージの応答性能は高いとは言えないため、バックエンド２００がオブジェクトストレージである場合には、応答速度の低下が顕著になるという問題がある。
【００４６】
なお、マルチプロセッサシステムにおけるキャッシュコヒーレンシプロトコルであるＭＳＩプロトコルでは、先に更新したプロセッサが、更新後のキャッシュデータを次に更新するプロセッサに直接送信することにより、主記憶への書き出しによるオーバヘッドの発生を回避する方法も採用されている。しかしながら、ＭＳＩプロトコルも、更新が発生するごとにキャッシュデータを残すことができないため、ログ構造化ファイルシステムにそのまま適用することはできない。
【００４７】
以上のような問題に対し、本実施の形態のフロントエンド３００ａ〜３００ｃは、更新が発生するごとにキャッシュデータを残すことが可能であり、なおかつ、キャッシュデータの更新に要する時間が短縮された分散キャッシュファイルシステムを備える。
【００４８】
図４は、フロントエンドが備える処理機能の構成例を示すブロック図である。なお、図４では、例としてフロントエンド３００ａについて説明するが、フロントエンド３００ｂ，３００ｃも、同様の処理機能を備える。
【００４９】
フロントエンド３００ａは、アプリケーション処理部３１０およびファイル管理部３２０を備える。
アプリケーション処理部３１０は、例えば、フロントエンド３００ａのＣＰＵ３０１が、所定のアプリケーションプログラムを実行することによって実現される。アプリケーションプログラムとしては、例えば、データベースにアクセスするためのプログラムなどがある。
【００５０】
アプリケーション処理部３１０は、クライアントからデータの書き込み要求を受けると、ファイル管理部３２０に対してデータの更新を要求する。また、アプリケーション処理部３１０は、クライアントからデータの読み出し要求を受けると、ファイル管理部３２０に対してデータの参照を要求し、ファイル管理部３２０から返信されたデータをクライアントに送信する。
【００５１】
ファイル管理部３２０は、例えば、フロントエンド３００ａのＣＰＵ３０１が、ＯＳプログラムを実行することによって実現される。ファイル管理部３２０は、バックエンド２００に格納されるデータを管理するファイルシステムとして機能する。ファイル管理部３２０は、アプリケーション処理部３１０に対して、ファイルにアクセスするためのＡＰＩ（Application Program Interface）を提供する。
【００５２】
ファイル管理部３２０は、ファイルを「ｉｎｏｄｅ番号」と呼ばれる識別情報によって識別する。また、ファイル管理部３２０は、ファイルを一定サイズのブロックに分割し、ファイルの格納領域をブロックごとに管理する。
【００５３】
また、フロントエンド３００ａのＲＡＭ３０２には、内部キャッシュ３３１の領域が確保され、フロントエンド３００ａのＨＤＤ３０３には、オフコアキャッシュ３３２の領域が確保される。ファイル管理部３２０は、内部キャッシュ３３１およびオフコアキャッシュ３３２の各領域を使用して、分散キャッシュファイルシステムを用いたキャッシュ機能を実現する。
【００５４】
ファイル管理部３２０は、アプリケーション処理部３１０からブロックの更新要求を受けると、更新データをまず内部キャッシュ３３１に格納した後、オフコアキャッシュ３３２に格納する。オフコアキャッシュ３３２は、内部キャッシュ３３１に格納された更新データを不揮発化して、異常発生時に復旧できるようにするためのログボリュームとして機能する。さらに、ファイル管理部３２０は、オフコアキャッシュ３３２に格納した更新データを、オフコアキャッシュ３３２への格納タイミングとは非同期に、バックエンド２００に格納する。
【００５５】
ファイル管理部３２０は、「Ｍｏｄｉｆｉｅｄ」、「Ｓｈａｒｅｄ」および「Ｉｎｖａｌｉｄ」という３つのステータスによって各ブロックの状態を管理する。各ステータスは、次のように定義される。
【００５６】
Ｍｏｄｉｆｉｅｄ：最新の更新データが、自装置の内部キャッシュ３３１に格納されているが、自装置のオフコアキャッシュ３３２には格納されていない状態を示す。フロントエンドは、他のフロントエンドから当該ブロックに対する更新要求または参照要求を受けたとき、他のフロントエンドに対して更新または参照を許可する前に、当該ブロックの最新データを自装置のオフコアキャッシュ３３２にも格納しなくてはならない。
【００５７】
Ｓｈａｒｅｄ：最新の更新データが、自装置の内部キャッシュ３３１およびオフコアキャッシュ３３２の両方に格納されている状態を示す。また、複数のフロントエンドにおいて、同一のブロックのステータスが「Ｓｈａｒｅｄ」になることも許容される。
【００５８】
Ｉｎｖａｌｉｄ：自装置の内部キャッシュ３３１およびオフコアキャッシュ３３２に、最新の更新データが格納されていない状態を示す。
また、ファイル管理部３２０は、ブロックのデータを更新するたびに、更新後のデータに新たなバージョン番号を付加する。ファイル管理部３２０は、他のフロントエンドからの要求に応じて、自装置が保持している更新データの最新のバージョン番号を通知する機能を備える。
【００５９】
ここで、図５は、内部キャッシュおよびオフコアキャッシュを用いたキャッシュ制御の例について説明するための図である。この図５では、例として、ｉｎｏｄｅ番号「ｉｎｏｄｅ＃ｘ」およびブロック番号「ｂｌｏｃｋ＃ｙ」で識別されるブロックについての、フロントエンド３００ａ，３００ｂでの更新処理を示す。なお、以下の説明では、ｉｎｏｄｅ番号「ｉｎｏｄｅ＃ｘ」およびブロック番号「ｂｌｏｃｋ＃ｙ」で識別されるブロックを「ブロックＸＹ」と呼ぶ。
【００６０】
図５では、まず、フロントエンド３００ａにおいて、ブロックＸＹが更新されたものとする。このとき、フロントエンド３００ａのファイル管理部３２０は、ブロックＸＹの更新データをフロントエンド３００ａの内部キャッシュ３３１に格納し、ブロックＸＹのステータスを「Ｍｏｄｉｆｉｅｄ」にする。これとともに、フロントエンド３００ａのファイル管理部３２０は、ブロックＸＹについての最新のバージョン番号として例えば「ｖｅｒｓｉｏｎ＃１」を生成し、生成した「ｖｅｒｓｉｏｎ＃１」を更新データに対応付けて内部キャッシュ３３１に格納する。
【００６１】
次に、フロントエンド３００ｂにおいて、同じブロックＸＹについての更新要求が発生したものとする。フロントエンド３００ｂのファイル管理部３２０は、少なくとも、自装置がブロックＸＹの最新データを保持していない場合（すなわち、ブロックＸＹのステータスが「Ｉｎｖａｌｉｄ」の場合）には、ステータスおよびバージョン番号の通知要求をネットワーク１１０上にブロードキャストする。通知要求を受けた他のフロントエンドのファイル管理部３２０は、自装置におけるブロックＸＹのステータスおよびバージョン番号を、ブロードキャストによって返信する。
【００６２】
フロントエンド３００ｂのファイル管理部３２０は、通知要求に応じて返信された情報に基づいて、ブロックＸＹの最新データを保持するフロントエンドと、ブロックＸＹの最新のバージョン番号とを認識する。図５の例では、フロントエンド３００ｂのファイル管理部３２０は、ブロックＸＹの最新データがフロントエンド３００ａで保持されており、そのバージョン番号が「ｖｅｒｓｉｏｎ＃１」であると認識する。そして、フロントエンド３００ｂのファイル管理部３２０は、フロントエンド３００ａに対して、ブロックＸＹの更新要求を送信する。
【００６３】
フロントエンド３００ａのファイル管理部３２０は、ブロックＸＹの更新要求を受けたとき、ブロックＸＹのステータスが「Ｍｏｄｉｆｉｅｄ」だった場合には、内部キャッシュ３３１に格納されたブロックＸＹの最新データを、そのバージョン番号とともにオフコアキャッシュ３３２にコピーする。そして、フロントエンド３００ａのファイル管理部３２０は、最新データおよびバージョン番号のコピーが完了した後、ブロックＸＹのステータスを「Ｉｎｖａｌｉｄ」に変更するとともに、フロントエンド３００ｂに応答を送信して、ブロックＸＹの更新を許可する。
【００６４】
ここで、フロントエンド３００ａの内部キャッシュ３３１に格納されていたブロックＸＹの最新データが、オフコアキャッシュ３３２にも格納された後に、ブロックＸＹのステータスが変更されることで、キャッシュコヒーレンシを保つことができる。これとともに、ブロックＸＹの最新データがバージョン番号とともにオフコアキャッシュ３３２に格納された後に、他のフロントエンド３００ｂにおけるブロックＸＹの更新が許可されることで、他のフロントエンド３００ｂにおいてブロックＸＹが更新される前に、更新前のデータがバージョン番号とともに不揮発の状態で確実に保存される。
【００６５】
また、フロントエンド３００ａのファイル管理部３２０は、オフコアキャッシュ３３２に同じブロックＸＹの古いバージョンの更新データが格納されている場合には、内部キャッシュ３３１内の最新データを、古いバージョンの更新データに上書きせずに、オフコアキャッシュ３３２に追記する。これにより、以前の更新データも不揮発性記録媒体に確実に残されるようになる。
【００６６】
図５の例では、フロントエンド３００ａのオフコアキャッシュ３３２に、「ｖｅｒｓｉｏｎ＃１」より古い「ｖｅｒｓｉｏｎ＃０」が付加された更新データがすでに格納されている。この場合、フロントエンド３００ａのオフコアキャッシュ３３２には、「ｖｅｒｓｉｏｎ＃０」の更新データとは別の領域に、「ｖｅｒｓｉｏｎ＃１」の更新データが格納される。
【００６７】
さらに、オフコアキャッシュ３３２はフロントエンド３００ａにローカルに接続された記憶装置であるため、オフコアキャッシュ３３２へのデータの書き込み速度は、バックエンド２００への書き込み速度より速い。フロントエンド３００ａのファイル管理部３２０は、内部キャッシュ３３１にのみ格納されていた最新データを、バックエンド２００ではなくオフコアキャッシュ３３２に格納した段階で、他のフロントエンド３００ｂにおける同じブロックの更新を許可する。これにより、他のフロントエンド３００ｂでブロックＸＹの更新が許可されるまでの時間が短縮される。換言すると、ブロックの更新を要求されてから更新を完了するまでのフロントエンド３００ｂにおける処理時間が短縮され、フロントエンド３００ｂの応答速度が向上する。
【００６８】
フロントエンド３００ｂのファイル管理部３２０は、更新要求に対する応答をフロントエンド３００ａから受信すると、ブロックＸＹの新たな更新データを内部キャッシュ３３１に格納することで、ブロックＸＹを更新する。このとき、フロントエンド３００ｂのファイル管理部３２０は、新たなバージョン番号「ｖｅｒｓｉｏｎ＃２」を生成して、更新データに対応付けて内部キャッシュ３３１に格納する。
【００６９】
前述のように、フロントエンド３００ｂのファイル管理部３２０は、ブロックＸＹについての更新直前のバージョン番号「ｖｅｒｓｉｏｎ＃１」を、フロントエンド３００ａから取得済みである。このため、フロントエンド３００ｂのファイル管理部３２０は、ブロックＸＹの新たな更新データに対して付加するべき新たなバージョン番号を判別することができる。このように、新たな更新データに新たなバージョン番号が付加されることで、ストレージシステム１００内に構築された分散キャッシュにおいて、同じブロックの更新データが世代別に判別可能な状態で蓄積されるようになる。
【００７０】
以上の処理により、フロントエンド３００ａのオフコアキャッシュ３３２には、ブロックＸＹの更新データとして、「ｖｅｒｓｉｏｎ＃０」の更新データと「ｖｅｒｓｉｏｎ＃１」の更新データとが蓄積される。フロントエンド３００ａのファイル管理部３２０は、任意のタイミングで、オフコアキャッシュ３３２に蓄積された「ｖｅｒｓｉｏｎ＃０」および「ｖｅｒｓｉｏｎ＃１」の各更新データを、バックエンド２００に追記する。
【００７１】
また、フロントエンド３００ｂのファイル管理部３２０は、例えば、他のフロントエンドにおいてブロックＸＹの更新が発生した場合などに、内部キャッシュ３３１に格納された「ｖｅｒｓｉｏｎ＃２」の更新データを、オフコアキャッシュ３３２にコピーする。さらに、フロントエンド３００ｂのファイル管理部３２０は、その後の任意のタイミングで、オフコアキャッシュ３３２に格納された「ｖｅｒｓｉｏｎ＃２」の更新データを、バックエンド２００に追記する。
【００７２】
このように、各フロントエンドのオフコアキャッシュ３３２に格納された世代別の更新データは、バックエンド２００にそれぞれ格納される。従って、各フロントエンドは、バックエンド２００に格納するデータをログ構造化ファイルシステムによって管理することができる。
【００７３】
図６は、ファイル管理部によるファイル管理のためのデータベース構造の例を示す図である。各フロントエンドのファイル管理部３２０は、自装置にキャッシュされるファイルを、図６に示すようなデータベース構造を用いて管理する。
【００７４】
スーパブロック３４１には、例えば、ファイルシステムに含まれるｉｎｏｄｅ３４２の数など、ファイルシステムに関する基本的な情報が記述されている。また、スーパブロック３４１には、先頭のｉｎｏｄｅ３４２のＲＡＭ３０２上の位置を示すポインタが記述され、このポインタによって先頭のｉｎｏｄｅ３４２が特定される。
【００７５】
ｉｎｏｄｅ３４２には、例えば、ｉｎｏｄｅ番号、ファイル属性、ブロック情報ポインタおよびｉｎｏｄｅポインタが記述されている。
ｉｎｏｄｅ番号は、ファイルを識別するための情報である。従って、ｉｎｏｄｅ３４２は、ファイルごとに生成される。ファイル属性は、ファイルの属性を示す。ブロック情報ポインタは、ｉｎｏｄｅ番号に対応するブロック情報３４３のＲＡＭ３０２上の位置を示すポインタである。ｉｎｏｄｅポインタは、他のｉｎｏｄｅのＲＡＭ３０２上の位置を示すポインタである。ｉｎｏｄｅポインタにより、２つのｉｎｏｄｅ３４２がリスト構造によって連結される。
【００７６】
ブロック情報３４３には、ファイルを分割して得られる各ブロックに関する情報が記述される。ブロック情報３４３には、例えば、ブロック番号、キャッシュ情報ポインタおよびブロック情報ポインタが記述されている。
【００７７】
ブロック番号は、ブロックを識別するための情報である。キャッシュ情報ポインタは、ブロックに対応するキャッシュ情報のＲＡＭ３０２上の位置を示すポインタである。ブロック情報ポインタは、ファイルが複数のブロックに分割されている場合に、同じファイルに属する他のブロックに対応するブロック情報３４３のＲＡＭ３０２上の位置を示すポインタである。
【００７８】
キャッシュ情報３４４は、ｉｎｏｄｅ番号およびブロック番号によって識別されるブロックのデータ３４５に関する情報が記述される。キャッシュ情報３４４には、例えば、ステータス、バージョン番号、ロックフラグ、データポインタ、キャッシュ情報ポインタおよびオフコアキャッシュ情報が記述されている。
【００７９】
ステータスは、前述した「Ｍｏｄｉｆｉｅｄ」、「Ｓｈａｒｅｄ」、「Ｉｎｖａｌｉｄ」のいずれかを示す。バージョン番号は、前述したように、更新のたびにデータ３４５に新たに付加される情報である。ロックフラグは、対応するブロックの参照または更新が可能な状態になっているか否かを示すフラグ情報である。ロックフラグは、参照または更新が可能である場合に「０」に設定され、可能でない場合に「１」に設定される。
【００８０】
データポインタは、対応するデータ３４５のＲＡＭ３０２上の位置を示すポインタである。データポインタにより、キャッシュ情報３４４は、ＲＡＭ３０２上の対応するデータ３４５と１対１で関連付けられる。
【００８１】
また、ｉｎｏｄｅ番号およびブロック番号によって識別されるブロックについて、異なるバージョン番号を有する複数のデータ３４５がＲＡＭ３０２に格納されている場合には、キャッシュ情報３４４もＲＡＭ３０２に複数格納される。キャッシュ情報ポインタは、他のバージョン番号を有するデータ３４５に対応するキャッシュ情報のＲＡＭ３０２上の位置を示すポインタである。キャッシュ情報ポインタにより、２つのキャッシュ情報３４４がリスト構造によって連結される。
【００８２】
オフコアキャッシュ情報は、対応するデータ３４５がオフコアキャッシュ３３２にも格納されている場合に、対応するデータ３４５のオフコアキャッシュ３３２における位置を示すポインタである。
【００８３】
なお、同一ブロックについての複数のキャッシュ情報３４４が格納されている場合、そのブロックについての有効なステータスおよびロックフラグは、最も新しいバージョン番号を含むキャッシュ情報３４４に記述されたステータスおよびロックフラグとなる。
【００８４】
また、上記のｉｎｏｄｅ３４２、ブロック情報３４３およびキャッシュ情報３４４に記述される情報と同等の情報は、オフコアキャッシュ３３２にも格納される。これにより、フロントエンドが異常停止した場合などにも、上記情報をオフコアキャッシュ３３２から復元することができる。ただし、オフコアキャッシュ３３２においては、上記情報の内容は図６と異なる構造で記録されてもよい。また、オフコアキャッシュ３３２では、上記情報のうち、ｉｎｏｄｅポインタ、ブロック情報ポインタ、キャッシュ情報ポインタおよびキャッシュ情報ポインタは、ＲＡＭ３０２上の位置ではなくＨＤＤ３０３上の位置を示すように変換される。
【００８５】
次に、各フロントエンドのファイル管理部３２０の処理について、フローチャートを用いて説明する。また、必要に応じて、複数のフロントエンドのファイル管理部３２０の処理例を示すシーケンス図も記載する。
【００８６】
以下の図７〜図１３では、アプリケーション処理部３１０からブロックに対するＩ／Ｏ（In/Out）要求が出力されたときのファイル管理部３２０の処理について、自装置における対象ブロックのステータスごとに場合分けして説明する。
【００８７】
図７は、ステータスが「Ｍｏｄｉｆｉｅｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
［ステップＳ１１］ファイル管理部３２０は、ブロックのロックフラグが「１」であるかを判定する。ロックフラグが「１」である場合、ファイル管理部３２０は、ステップＳ１２の処理を実行する。一方、ロックフラグが「０」である場合、ファイル管理部３２０は、ステップＳ１３の処理を実行する。
【００８８】
［ステップＳ１２］ロックフラグが「１」である場合、対応するブロックについての更新および参照が禁止されている。このため、ファイル管理部３２０は、所定時間後に、要求されたＩ／Ｏ処理をリトライする。なお、所定時間後には、対象ブロックのステータスが変更されている可能性があるため、ファイル管理部３２０は、対象ブロックのステータスに応じた処理をリトライする。
【００８９】
［ステップＳ１３］ファイル管理部３２０は、ブロックのロックフラグを「１」に変更し、他のフロントエンドからのブロックの更新および参照を禁止する。
［ステップＳ１４］ファイル管理部３２０は、Ｉ／Ｏ処理を実行する。参照が要求されていた場合、ファイル管理部３２０は、内部キャッシュ３３１から、ブロックの最新データをアプリケーション処理部３１０に読み出す。一方、更新が要求されていた場合、ファイル管理部３２０は、アプリケーション処理部３１０から受け取った新たな更新データを内部キャッシュ３３１に格納して、ブロックを更新する。
【００９０】
なお、ステップＳ１４でブロックを更新する場合には、ファイル管理部３２０は、内部キャッシュ３３１に格納されている最新のバージョン番号が付加された更新データを、新たな更新データによって上書きしてよい。この場合、異なるフロントエンドにおいてブロックが更新されるごとに、新たなバージョン番号が付加された更新データが保存されていく。
【００９１】
ただし、他の例として、ステップＳ１４でブロックを更新する場合でも、ファイル管理部３２０は、新たな更新データに新たなバージョン番号を付加し、新たな更新データおよび新たなバージョン番号を内部キャッシュ３３１に追記してもよい。この場合、更新が行われるフロントエンドの位置に関係なく、ブロックが更新されるごとに、新たなバージョン番号が付加された更新データが保存されていく。
【００９２】
［ステップＳ１５］ファイル管理部３２０は、ブロックのロックフラグを「０」に変更し、ロック状態を解除する。
図８は、ステータスが「Ｓｈａｒｅｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
【００９３】
［ステップＳ２１］ファイル管理部３２０は、ブロックのロックフラグが「１」であるかを判定する。ロックフラグが「１」である場合、ファイル管理部３２０は、ステップＳ２２の処理を実行する。一方、ロックフラグが「０」である場合、ファイル管理部３２０は、ステップＳ２３の処理を実行する。
【００９４】
［ステップＳ２２］ファイル管理部３２０は、図７のステップＳ１２と同様の手順で、所定時間後に、要求されたＩ／Ｏ処理をリトライする。
［ステップＳ２３］要求された処理が参照である場合、ファイル管理部３２０は、ステップＳ２４の処理を実行する。一方、要求された処理が更新である場合、ファイル管理部３２０は、ステップＳ２７の処理を実行する。
【００９５】
［ステップＳ２４］ファイル管理部３２０は、ブロックのロックフラグを「１」に変更し、他のフロントエンドからのブロックの更新および参照を禁止する。
［ステップＳ２５］ファイル管理部３２０は、内部キャッシュ３３１から、ブロックの最新データをアプリケーション処理部３１０に読み出す。
【００９６】
［ステップＳ２６］ファイル管理部３２０は、ブロックのロックフラグを「０」に変更し、ロック状態を解除する。
［ステップＳ２７］ファイル管理部３２０は、ステータスおよびバージョン情報の通知要求を他のフロントエンドにブロードキャストする。
【００９７】
［ステップＳ２８］ファイル管理部３２０は、他のフロントエンドからの、通知要求に対する応答を受信する。受信した応答の中にＮＧ応答があった場合、ファイル管理部３２０は、更新対象のブロックにロックがかけられ、そのブロックの参照および更新が禁止されていると判断する。この場合、ステップＳ２２に移り、ファイル管理部３２０は、更新処理をリトライする。一方、受信した応答の中にＮＧ応答がなかった場合、ファイル管理部３２０は、ステップＳ２９の処理を実行する。
【００９８】
［ステップＳ２９］ステップＳ２８で、受信した応答の中にＮＧ応答がなかった場合、ファイル管理部３２０は、更新対象のブロックについてロックを獲得したと判断する。この場合、ファイル管理部３２０は、ブロックのロックフラグを「１」に変更し、他のフロントエンドからのブロックの更新および参照を禁止する。
【００９９】
［ステップＳ３０］ファイル管理部３２０は、ステップＳ２８で他のフロントエンドから受信した応答に基づき、他のフロントエンドにおける更新対象ブロックについてのステータスをチェックする。他のフロントエンドのステータスがすべて「Ｉｎｖａｌｉｄ」である場合、ファイル管理部３２０は、ステップＳ３２の処理を実行する。一方、他のフロントエンドの中に１つでもステータスが「Ｓｈａｒｅｄ」であるものがある場合、ファイル管理部３２０は、ステップＳ３１の処理を実行する。
【０１００】
［ステップＳ３１］ステータスが「Ｓｈａｒｅｄ」であるフロントエンドは、更新対象ブロックの最新データを保持している。このため、ファイル管理部３２０は、ステータスが「Ｓｈａｒｅｄ」のフロントエンドに対してパージ要求を送信して、ステータスを「Ｉｎｖａｌｉｄ」に変更させる。
【０１０１】
［ステップＳ３２］ファイル管理部３２０は、更新対象ブロックの最新のバージョン番号をインクリメントして、新たなバージョン番号を生成する。また、ファイル管理部３２０は、更新対象のブロックのステータスを「Ｍｏｄｉｆｉｅｄ」に変更する。
【０１０２】
［ステップＳ３３］ファイル管理部３２０は、アプリケーション処理部３１０から受け取った、新たな更新データを、生成した新たなバージョン番号とともに内部キャッシュ３３１に追記する。これにより、ブロックのデータが更新される。
【０１０３】
［ステップＳ３４］ファイル管理部３２０は、他のフロントエンドにおける対象ブロックの参照および更新の禁止状態を解除するためのロック解除要求をブロードキャストする。また、ファイル管理部３２０は、ロックフラグを「０」に変更する。
【０１０４】
図９は、更新を行うフロントエンドのステータスが「Ｓｈａｒｅｄ」である場合の処理例を示すシーケンス図である。図９では例として、初期状態における更新対象ブロックのステータスが、フロントエンド３００ａ，３００ｂで「Ｓｈａｒｅｄ」であり、フロントエンド３００ｃで「Ｉｎｖａｌｉｄ」であったものとする。
【０１０５】
［ステップＳ４１］フロントエンド３００ａのファイル管理部３２０は、アプリケーション処理部３１０からブロックの更新要求を受け付ける。
［ステップＳ４２］フロントエンド３００ａのファイル管理部３２０は、ステータスおよびバージョン情報の通知要求を他のフロントエンドにブロードキャストする（図８のステップＳ２７に対応）。
【０１０６】
［ステップＳ４３］フロントエンド３００ｂのファイル管理部３２０は、通知要求に対する応答をブロードキャストする。フロントエンド３００ｂから送信される応答情報には、ステータスとして「Ｓｈａｒｅｄ」が設定されているとともに、ブロックの現時点での最新バージョン番号が設定されている。
【０１０７】
［ステップＳ４４］フロントエンド３００ｃのファイル管理部３２０は、通知要求に対する応答をブロードキャストする。フロントエンド３００ｃから送信される応答情報には、ステータスとして「Ｉｎｖａｌｉｄ」が設定されているとともに、フロントエンド３００ｃが保持するデータに付加されたバージョン番号のうちの最新のバージョン番号が設定されている。
【０１０８】
なお、ステップＳ４３，Ｓ４４は、逆の順序で実行される場合も、あるいは同時に実行される場合もある。
また、後に説明するように、通知要求を受信したフロントエンドは、対象ブロックについてロック状態でない場合（ロックフラグが「０」である場合）には、正常な応答情報をブロードキャストする。一方、通知要求を受信したフロントエンドは、対象ブロックについてロック状態である場合（ロックフラグが「１」である場合）には、ＮＧの応答情報をブロードキャストする。
【０１０９】
応答情報がブロードキャストされることから、応答情報を送信したフロントエンドは、他のフロントエンドが送信した応答情報を受信できる。正常な応答情報を送信したフロントエンドは、他のフロントエンドからＮＧの応答情報を受信しない場合に、ロック状態に遷移する。従って、通知要求を受信したすべてのフロントエンドから正常な応答情報が返信された場合には、通知要求の送信元フロントエンドがロックを獲得するだけでなく、他のフロントエンドもロック状態になり、参照や更新の排他制御が容易に実行される。
【０１１０】
［ステップＳ４５］応答情報を受信したフロントエンド３００ａのファイル管理部３２０は、ＮＧ応答を受信しなかったと判断すると、ステータスが「Ｓｈａｒｅｄ」であるフロントエンド３００ｂに対してパージ要求を送信する（図８のステップＳ３１）。
【０１１１】
［ステップＳ４６］パージ要求を受信したフロントエンド３００ｂのファイル管理部３２０は、対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に変更する。
［ステップＳ４７］フロントエンド３００ａのファイル管理部３２０は、更新対象ブロックの最新のバージョン番号をインクリメントして、新たなバージョン番号を生成する。また、ファイル管理部３２０は、更新対象のブロックのステータスを「Ｍｏｄｉｆｉｅｄ」に変更する（図８のステップＳ３２に対応）。
【０１１２】
［ステップＳ４８］フロントエンド３００ａのファイル管理部３２０は、新たな更新データを、生成した新たなバージョン番号とともに内部キャッシュ３３１に追記する（図８のステップＳ３３に対応）。
【０１１３】
このように、フロントエンド３００ａは、ステータスが「Ｓｈａｒｅｄ」であるフロントエンド３００ｂにパージ要求を送信した後に、ステップＳ４７，Ｓ４８のブロック更新処理を実行する。これにより、キャッシュコヒーレンシを保つことができる。
【０１１４】
［ステップＳ４９］フロントエンド３００ａのファイル管理部３２０は、ロック解除要求をブロードキャストする（図８のステップＳ３４に対応）。
次に、図１０，図１１は、ステータスが「Ｉｎｖａｌｉｄ」である場合のファイル管理部の処理手順の例を示すフローチャートである。
【０１１５】
［ステップＳ６１］ファイル管理部３２０は、ブロックのロックフラグが「１」であるかを判定する。ロックフラグが「１」である場合、ファイル管理部３２０は、ステップＳ６２の処理を実行する。一方、ロックフラグが「０」である場合、ファイル管理部３２０は、ステップＳ６３の処理を実行する。
【０１１６】
［ステップＳ６２］ファイル管理部３２０は、図７のステップＳ１２と同様の手順で、所定時間後に、要求されたＩ／Ｏ処理をリトライする。
［ステップＳ６３］ファイル管理部３２０は、ステータスおよびバージョン情報の通知要求を他のフロントエンドにブロードキャストする。
【０１１７】
［ステップＳ６４］ファイル管理部３２０は、他のフロントエンドからの、通知要求に対する応答を受信する。受信した応答の中にＮＧ応答があった場合、ファイル管理部３２０は、更新対象のブロックにロックがかけられ、そのブロックの参照および更新が禁止されていると判断する。この場合、ステップＳ６２に移り、ファイル管理部３２０は、更新処理をリトライする。一方、受信した応答の中にＮＧ応答がなかった場合、ファイル管理部３２０は、ステップＳ６５の処理を実行する。
【０１１８】
［ステップＳ６５］ステップＳ６４で、受信した応答の中にＮＧ応答がなかった場合、ファイル管理部３２０は、更新対象のブロックについてロックを獲得したと判断して、ブロックのロックフラグを「１」に変更する。
【０１１９】
［ステップＳ６６］ファイル管理部３２０は、ステップＳ６４で他のフロントエンドから受信した応答に基づき、他のフロントエンドにおける更新対象ブロックについてのステータスをチェックする。他のフロントエンドのステータスがすべて「Ｉｎｖａｌｉｄ」である場合、ファイル管理部３２０は、ステップＳ６７の処理を実行する。一方、他のフロントエンドの中に１つでもステータスが「Ｓｈａｒｅｄ」または「Ｍｏｄｉｆｉｅｄ」であるものがある場合、ファイル管理部３２０は、図１１のステップＳ８１の処理を実行する。
【０１２０】
［ステップＳ６７］要求された処理が参照である場合、ファイル管理部３２０は、ステップＳ６８の処理を実行する。一方、要求された処理が更新である場合、ファイル管理部３２０は、ステップＳ７１の処理を実行する。
【０１２１】
［ステップＳ６８］ファイル管理部３２０は、ブロックの最新データおよびそれに付加されたバージョン番号を、バックエンド２００から取得する。ファイル管理部３２０は、取得した最新データおよびバージョン番号を、オフコアキャッシュ３３２に格納し、さらに内部キャッシュ３３１にも格納する。
【０１２２】
［ステップＳ６９］ファイル管理部３２０は、参照対象のブロックのステータスを「Ｓｈａｒｅｄ」に変更する。
［ステップＳ７０］ファイル管理部３２０は、ステップＳ６８で内部キャッシュ３３１に格納した最新データを、アプリケーション処理部３１０に読み出す。
【０１２３】
［ステップＳ７１］ファイル管理部３２０は、ブロックの最新のバージョン番号をバックエンド２００から取得する。
［ステップＳ７２］ファイル管理部３２０は、取得したバージョン番号をインクリメントして、新たなバージョン番号を生成する。また、ファイル管理部３２０は、更新対象のブロックのステータスを「Ｍｏｄｉｆｉｅｄ」に変更する。
【０１２４】
［ステップＳ７３］ファイル管理部３２０は、アプリケーション処理部３１０から受け取った、新たな更新データを、生成した新たなバージョン番号とともに内部キャッシュ３３１に追記する。これにより、ブロックのデータが更新される。
【０１２５】
［ステップＳ７４］ファイル管理部３２０は、ロック解除要求をブロードキャストするとともに、ブロックのロックフラグを「０」に変更して、ロック状態を解除する。
［ステップＳ８１］要求された処理が参照である場合、ファイル管理部３２０は、ステップＳ８２の処理を実行する。一方、要求された処理が更新である場合、ファイル管理部３２０は、ステップＳ８５の処理を実行する。
【０１２６】
［ステップＳ８２］ファイル管理部３２０は、ステータスが「Ｍｏｄｉｆｉｅｄ」または「Ｓｈａｒｅｄ」である他のフロントエンドに対して、参照要求を送信する。ファイル管理部３２０は、参照要求に対する応答として、ブロックの最新データとこれに付加されたバージョン番号とを受信する。
【０１２７】
［ステップＳ８３］ファイル管理部３２０は、ブロックのステータスを「Ｓｈａｒｅｄ」に変更する。
［ステップＳ８４］ファイル管理部３２０は、ステップＳ８２で受信したデータおよびバージョン番号を、オフコアキャッシュ３３２に追記し、さらに内部キャッシュ３３１にも追記する。そして、ファイル管理部３２０は、内部キャッシュ３３１に格納したデータをアプリケーション処理部３１０に読み出す。
【０１２８】
なお、ステップＳ８２では、ファイル管理部３２０は、参照要求に対する応答としてブロックの最新データのみを受信してもよい。この場合、ステップＳ８４では、ファイル管理部３２０は、ステップＳ６４で受信した応答情報から最新のバージョン番号を認識する。
【０１２９】
［ステップＳ８５］ファイル管理部３２０は、ステータスが「Ｍｏｄｉｆｉｅｄ」である他のフロントエンド、およびステータスが「Ｓｈａｒｅｄ」である他のフロントエンドのすべてに対して、更新要求を送信する。ファイル管理部３２０は、更新要求に対する応答として、ブロック更新前における最新のバージョン番号とを受信する。
【０１３０】
［ステップＳ８６］ファイル管理部３２０は、バージョン番号をインクリメントして、新たなバージョン番号を生成する。また、ファイル管理部３２０は、更新対象のブロックのステータスを「Ｍｏｄｉｆｉｅｄ」に変更する。
【０１３１】
なお、ステップＳ８５において、ファイル管理部３２０が更新要求に対する応答として受信する情報には、バージョン番号が含まれていなくてもよい。この場合、ステップＳ８６では、ファイル管理部３２０は、ステップＳ６４で受信した応答情報から更新前の最新のバージョン番号を認識する。また、ステップＳ８５では、ファイル管理部３２０は、更新要求の代わりにパージ要求を送信してもよい。
【０１３２】
［ステップＳ８６］ファイル管理部３２０は、アプリケーション処理部３１０から受け取った、新たな更新データを、生成した新たなバージョン番号とともに内部キャッシュ３３１に追記する。これにより、ブロックのデータが更新される。
【０１３３】
図１２は、参照を行うフロントエンドのステータスが「Ｉｎｖａｌｉｄ」である場合の処理例を示すシーケンス図である。図１２では例として、初期状態における参照対象ブロックのステータスが、フロントエンド３００ａ，３００ｃで「Ｉｎｖａｌｉｄ」であり、フロントエンド３００ｂで「Ｍｏｄｉｆｉｅｄ」であったものとする。
【０１３４】
［ステップＳ９１］フロントエンド３００ａのファイル管理部３２０は、アプリケーション処理部３１０からブロックの参照要求を受け付ける。
［ステップＳ９２］フロントエンド３００ａのファイル管理部３２０は、ステータスおよびバージョン情報の通知要求を他のフロントエンドにブロードキャストする（図１０のステップＳ６３に対応）。
【０１３５】
［ステップＳ９３］フロントエンド３００ｂのファイル管理部３２０は、通知要求に対する応答をブロードキャストする。フロントエンド３００ｂから送信される応答情報には、ステータスとして「Ｍｏｄｉｆｉｅｄ」が設定されているとともに、ブロックの現時点での最新バージョン番号が設定されている。
【０１３６】
［ステップＳ９４］フロントエンド３００ｃのファイル管理部３２０は、通知要求に対する応答をブロードキャストする。フロントエンド３００ｃから送信される応答情報には、ステータスとして「Ｉｎｖａｌｉｄ」が設定されている。また、フロントエンド３００ｃが参照対象のブロックについての古いバージョン番号のデータを保持している場合には、送信される応答情報には、フロントエンド３００が保持しているデータに付加されたバージョン番号のうちの最新のバージョン番号が設定されている。
【０１３７】
なお、ステップＳ９３，Ｓ９４は、逆の順序で実行される場合も、あるいは同時に実行される場合もある。
また、フロントエンド３００ｂ，３００ｃの両方から正常な応答情報が送信されることで、フロントエンド３００ｂ，３００ｃはロック状態になる。
【０１３８】
［ステップＳ９５］応答情報を受信したフロントエンド３００ａのファイル管理部３２０は、ＮＧ応答を受信しなかったと判断すると、ステータスが「Ｍｏｄｉｆｉｅｄ」であるフロントエンド３００ｂに対して参照要求を送信する（図１１のステップＳ８２に対応）。参照要求は、対象ブロックの参照を許可するように依頼する役割を果たす。
【０１３９】
［ステップＳ９６］参照要求を受信したフロントエンド３００ｂのファイル管理部３２０は、内部キャッシュ３３１に格納された、ブロックの最新データおよびそのバージョン番号を、オフコアキャッシュ３３２に追記する。そして、フロントエンド３００ｂのファイル管理部３２０は、ブロックのステータスを「Ｍｏｄｉｆｉｅｄ」から「Ｓｈａｒｅｄ」に変更する。
【０１４０】
［ステップＳ９７］フロントエンド３００ｂのファイル管理部３２０は、ブロックの最新データとこれに付加されたバージョン番号とを、フロントエンド３００ａに送信する。
［ステップＳ９８］フロントエンド３００ａのファイル管理部３２０は、ブロックのステータスを「Ｓｈａｒｅｄ」に変更する（図１１のステップＳ８３に対応）。
【０１４１】
［ステップＳ９９］フロントエンド３００ａのファイル管理部３２０は、受信したデータおよびバージョン番号を、オフコアキャッシュ３３２に追記し、さらに内部キャッシュ３３１にも追記する。そして、ファイル管理部３２０は、内部キャッシュ３３１に格納したデータをアプリケーション処理部３１０に読み出す（図１１のステップＳ８４に対応）。
【０１４２】
［ステップＳ１００］フロントエンド３００ａのファイル管理部３２０は、ロック解除要求をブロードキャストする（図１０のステップＳ７４に対応）。
以上の図１２の処理では、参照要求を受けたフロントエンド３００ｂは、内部キャッシュ３３１に格納された最新データおよびバージョン番号を、バックエンド２００に追記する代わりに、オフコアキャッシュ３３２に追記する。そして、フロントエンド３００ｂは、オフコアキャッシュ３３２への追記が完了すると、フロントエンド３００ａに応答する。
【０１４３】
このように、ステータスが「Ｍｏｄｉｆｉｅｄ」のフロントエンド３００ｂは、バックエンド２００より高速にアクセス可能なオフコアキャッシュ３３２への追記を契機として、ステータスを「Ｓｈａｒｅｄ」に変更するとともにデータをフロントエンド３００ａに送信する。これにより、フロントエンド３００ａ，３００ｂとの間でキャッシュコヒーレンシが保たれるとともに、フロントエンド３００ａがデータの参照に要する時間を短縮することができる。
【０１４４】
なお、初期状態におけるフロントエンド３００ｂのステータスが「Ｓｈａｒｅｄ」であった場合には、図１２は次のように変形される。
ステップＳ９３において、フロントエンド３００ｂは、ステータスとして「Ｓｈａｒｅｄ」が設定された応答情報をブロードキャストする。また、フロントエンド３００ｂのステータスが「Ｓｈａｒｅｄ」の場合、ブロックの最新データは、フロントエンド３００ｂの内部キャッシュ３３１とオフコアキャッシュ３３２の両方に格納されている。このため、フロントエンド３００ａからの参照要求を受信したフロントエンド３００ｂは、ステップＳ９６の処理をスキップして、ステップＳ９７の処理を実行する。
【０１４５】
図１３は、更新を行うフロントエンドのステータスが「Ｉｎｖａｌｉｄ」である場合の処理例を示すシーケンス図である。図１３では例として、初期状態における参照対象ブロックのステータスが、フロントエンド３００ａ，３００ｃで「Ｉｎｖａｌｉｄ」であり、フロントエンド３００ｂで「Ｍｏｄｉｆｉｅｄ」であったものとする。
【０１４６】
［ステップＳ１１１］フロントエンド３００ａのファイル管理部３２０は、アプリケーション処理部３１０からブロックの更新要求を受け付ける。
［ステップＳ１１２］フロントエンド３００ａのファイル管理部３２０は、ステータスおよびバージョン情報の通知要求を他のフロントエンドにブロードキャストする（図１０のステップＳ６３に対応）。
【０１４７】
［ステップＳ１１３］フロントエンド３００ｂのファイル管理部３２０は、通知要求に対する応答をブロードキャストする。フロントエンド３００ｂから送信される応答情報には、ステータスとして「Ｍｏｄｉｆｉｅｄ」が設定されているとともに、ブロックの現時点での最新バージョン番号が設定されている。
【０１４８】
［ステップＳ１１４］フロントエンド３００ｃのファイル管理部３２０は、通知要求に対する応答をブロードキャストする。フロントエンド３００ｃから送信される応答情報には、ステータスとして「Ｉｎｖａｌｉｄ」が設定されているとともに、フロントエンド３００ｃが保持するデータに付加されたバージョン番号のうちの最新のバージョン番号が設定されている。
【０１４９】
なお、ステップＳ１１３，Ｓ１１４は、逆の順序で実行される場合も、あるいは同時に実行される場合もある。
また、フロントエンド３００ｂ，３００ｃの両方から正常な応答情報が送信されることで、フロントエンド３００ｂ，３００ｃはロック状態になる。
【０１５０】
［ステップＳ１１５］応答情報を受信したフロントエンド３００ａのファイル管理部３２０は、ＮＧ応答を受信しなかったと判断すると、ステータスが「Ｍｏｄｉｆｉｅｄ」であるフロントエンド３００ｂに対して更新要求を送信する（図１１のステップＳ８５に対応）。更新要求は、対象ブロックの更新を許可するように依頼する役割を果たす。
【０１５１】
［ステップＳ１１６］更新要求を受信したフロントエンド３００ｂのファイル管理部３２０は、内部キャッシュ３３１に格納された、ブロックの最新データおよびそのバージョン番号を、オフコアキャッシュ３３２に追記する。そして、フロントエンド３００ｂのファイル管理部３２０は、対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に変更する。
【０１５２】
［ステップＳ１１７］フロントエンド３００ｂのファイル管理部３２０は、更新要求の応答として、最新のバージョン番号をフロントエンド３００ａに送信する。このときに送信される応答情報は、フロントエンド３００ａに対してブロックの更新を許可することを意味する。
【０１５３】
［ステップＳ１１８］フロントエンド３００ａのファイル管理部３２０は、更新対象ブロックの最新のバージョン番号をインクリメントして、新たなバージョン番号を生成する。また、ファイル管理部３２０は、更新対象のブロックのステータスを「Ｍｏｄｉｆｉｅｄ」に変更する（図１１のステップＳ８６に対応）。
【０１５４】
［ステップＳ１１９］フロントエンド３００ａのファイル管理部３２０は、新たな更新データを、生成した新たなバージョン番号とともに内部キャッシュ３３１に追記する（図１１のステップＳ８７に対応）。
【０１５５】
このように、フロントエンド３００ａは、ステータスが「Ｍｏｄｉｆｉｅｄ」であるフロントエンド３００ｂに更新要求を送信した後に、ステップＳ１１８，Ｓ１１９のブロック更新処理を実行する。これにより、キャッシュコヒーレンシを保つことができる。
【０１５６】
［ステップＳ１２０］フロントエンド３００ａのファイル管理部３２０は、ロック解除要求をブロードキャストする（図１０のステップＳ７４に対応）。
以上の図１３の処理では、更新要求を受けたフロントエンド３００ｂは、内部キャッシュ３３１に格納された最新データおよびバージョン番号を、バックエンド２００に追記する代わりに、オフコアキャッシュ３３２に追記する。そして、フロントエンド３００ｂは、オフコアキャッシュ３３２への追記が完了すると、フロントエンド３００ａに応答して、ブロックの更新を許可する。
【０１５７】
このように、ステータスが「Ｍｏｄｉｆｉｅｄ」のフロントエンド３００ｂは、バックエンド２００より高速にアクセス可能なオフコアキャッシュ３３２への追記を契機として、フロントエンド３００ａに対してブロックの更新を許可する。これにより、フロントエンド３００ａ，３００ｂとの間でキャッシュコヒーレンシが保たれるとともに、フロントエンド３００ａがデータを更新できるようになるまでの時間を短縮することができる。
【０１５８】
なお、初期状態におけるフロントエンド３００ｂのステータスが「Ｓｈａｒｅｄ」であった場合には、図１３は次のように変形される。
ステップＳ１１３において、フロントエンド３００ｂは、ステータスとして「Ｓｈａｒｅｄ」が設定された応答情報をブロードキャストする。また、フロントエンド３００ｂのステータスが「Ｓｈａｒｅｄ」の場合、ブロックの最新データは、フロントエンド３００ｂの内部キャッシュ３３１とオフコアキャッシュ３３２の両方に格納されている。このため、ステップＳ１１６において、フロントエンド３００ｂは、最新データをオフコアキャッシュ３３２に追記する処理をスキップする。
【０１５９】
次に、図１４，図１５は、ファイル管理部による応答処理手順の例を示すフローチャートである。なお、ここでは例として、フロントエンド３００ａが備えるファイル管理部３２０の処理について説明する。
【０１６０】
［ステップＳ１３１］フロントエンド３００ａのファイル管理部３２０は、他のフロントエンドからブロードキャストされた通知要求を受信すると、ステップＳ１３２以後の処理を実行する。なお、受信した通知要求には、処理対象のブロックを識別するためのｉｎｏｄｅ番号およびブロック番号が設定されている。
【０１６１】
［ステップＳ１３２］ファイル管理部３２０は、対象ブロックのロックフラグが「１」である場合には、ステップＳ１３３の処理を実行する。一方、ファイル管理部３２０は、ロックフラグが「０」である場合には、ステップＳ１３４の処理を実行する。
【０１６２】
［ステップＳ１３３］ファイル管理部３２０は、ＮＧの応答情報をブロードキャストして、処理を終了する。
［ステップＳ１３４］ファイル管理部３２０は、ロックフラグを「１」に変更する。
【０１６３】
［ステップＳ１３５］ファイル管理部３２０は、フロントエンド３００ａにおける対象ブロックのステータスと、フロントエンド３００ａが保持するブロックの最新データのバージョン番号とを設定した応答情報を、ブロードキャストする。
【０１６４】
［ステップＳ１３６］ブロードキャストされた通信要求を受信した他のフロントエンドから応答情報がブロードキャストされた場合、フロントエンド３００ａは、その応答情報を受信する。ファイル管理部３２０は、受信した応答情報の中にＮＧの応答情報があった場合には、ステップＳ１３７の処理を実行する。一方、ファイル管理部３２０は、受信した応答情報の中にＮＧの応答情報がなかった場合には、図１５のステップＳ１３８の処理を実行する。
【０１６５】
なお、ファイル管理部３２０は、他のフロントエンドからの応答情報を、ステップＳ１３１からステップＳ１３５までの期間にも受信する場合がある。ファイル管理部３２０は、ステップＳ１３１からステップＳ１３５までの期間にＮＧの応答情報を受信した場合には、その時点でステップＳ１３７の処理を開始する。
【０１６６】
［ステップＳ１３７］ファイル管理部３２０は、対象ブロックについて、他のフロントエンドにおいてロック状態になっている判断して、ロックフラグを「０」に戻す。なお、ロックフラグがすでに「０」になっていた場合には、その値が維持される。
【０１６７】
前述のように、通知要求を送信したフロントエンドは、すべての送信先のフロントエンドから正常な応答情報を受信することで、ロックを獲得したと判断する。一方、通知要求を受信した各フロントエンドも、他のフロントエンドから返信された応答情報を監視し、それらの応答情報の中にＮＧの応答情報が含まれていなければ、ロックフラグを「１」にする。ロックフラグを「１」にすることで、フロントエンドは、通知要求の送信元のフロントエンド以外からの対象ブロックについての処理要求を受け付けない状態に遷移する。
【０１６８】
また、各フロントエンドは、返信された応答情報の中にＮＧの応答情報が含まれている場合には、通知要求の送信元のフロントエンドには、参照や更新の権限が与えられていないと判断して、処理を強制的に終了する。
【０１６９】
このように、ブロードキャストされた通知要求に対する応答情報に基づいてロック状態にするか否かを判定することで、参照や更新の排他制御を容易に実行することができる。
［ステップＳ１３８］ファイル管理部３２０は、通知要求を送信したフロントエンドからの参照要求を受信したかを判定する。ファイル管理部３２０は、参照要求を一定時間内に受信した場合、ステップＳ１４２の処理を実行する。一方、ファイル管理部３２０は、参照要求を一定時間内に受信しなかった場合、ステップＳ１３９の処理を実行する。
【０１７０】
［ステップＳ１３９］ファイル管理部３２０は、通知要求を送信したフロントエンドからの更新要求を受信したかを判定する。ファイル管理部３２０は、更新要求を一定時間内に受信した場合、ステップＳ１４６の処理を実行する。一方、ファイル管理部３２０は、更新要求を一定時間内に受信しなかった場合、ステップＳ１４０の処理を実行する。
【０１７１】
［ステップＳ１４０］ファイル管理部３２０は、通知要求を送信したフロントエンドからのパージ要求を受信したかを判定する。ファイル管理部３２０は、パージ要求を一定時間内に受信した場合、ステップＳ１５０の処理を実行する。一方、ファイル管理部３２０は、パージ要求を一定時間内に受信しなかった場合、ステップＳ１４１の処理を実行する。
【０１７２】
［ステップＳ１４１］ファイル管理部３２０は、通知要求を送信したフロントエンドからのロック解除要求を受信したかを判定する。ファイル管理部３２０は、ロック解除要求を一定時間内に受信した場合、ステップＳ１５１の処理を実行する。一方、ファイル管理部３２０は、ロック解除要求を一定時間内に受信しなかった場合、ステップＳ１３８の処理を実行する。
【０１７３】
従って、ファイル管理部３２０は、ステップＳ１３８〜Ｓ１４１の判定処理を一定時間ごとに繰り返す。
［ステップＳ１４２］参照要求を受信した場合、ファイル管理部３２０は、対象ブロックのステータスをチェックする。ファイル管理部３２０は、ステータスが「Ｍｏｄｉｆｉｅｄ」である場合、ステップＳ１４３の処理を実行する。一方、ファイル管理部３２０は、ステータスが「Ｓｈａｒｅｄ」である場合、ステップＳ１４５の処理を実行する。
【０１７４】
［ステップＳ１４３］ファイル管理部３２０は、内部キャッシュ３３１に格納された、ブロックの最新データおよびそのバージョン番号を、オフコアキャッシュ３３２に追記する。
【０１７５】
［ステップＳ１４４］ファイル管理部３２０は、対象ブロックのステータスを「Ｓｈａｒｅｄ」に変更する。
［ステップＳ１４５］ファイル管理部３２０は、ブロックの最新データおよびバージョン番号を内部キャッシュ３３１から読み出し、読み出した各データを設定した応答情報を、参照要求に送信元のフロントエンドに送信する。
【０１７６】
［ステップＳ１４６］更新要求を受信した場合、ファイル管理部３２０は、対象ブロックのステータスをチェックする。ファイル管理部３２０は、ステータスが「Ｍｏｄｉｆｉｅｄ」である場合、ステップＳ１４７の処理を実行する。一方、ファイル管理部３２０は、ステータスが「Ｓｈａｒｅｄ」である場合、ステップＳ１４８の処理を実行する。
【０１７７】
［ステップＳ１４７］ファイル管理部３２０は、内部キャッシュ３３１に格納された、ブロックの最新データおよびそのバージョン番号を、オフコアキャッシュ３３２に追記する。
【０１７８】
［ステップＳ１４８］ファイル管理部３２０は、対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に変更する。
［ステップＳ１４９］ファイル管理部３２０は、ブロックの最新データに付加されているバージョン番号を応答情報に設定し、この応答情報を、参照要求に送信元のフロントエンドに送信する。
【０１７９】
［ステップＳ１５０］パージ要求を受信した場合、ファイル管理部３２０は、対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に変更する。
［ステップＳ１５１］ロック解除要求を受信した場合、ファイル管理部３２０は、対象ブロックに対応付けられたロックフラグを「０」に変更して、処理を終了する。
【０１８０】
図１６は、ステータスの遷移例を示す図である。図１６では例として、２つのフロントエンドＡ，Ｂでブロックの参照または更新が発生した場合の、各フロントエンドＡ，Ｂにおけるステータスの変化の仕方を示す。
【０１８１】
図１６において、「Ｍ」は「Ｍｏｄｉｆｉｅｄ」を示し、「Ｓ」は「Ｓｈａｒｅｄ」を示し、「Ｉ」は「Ｉｎｖａｌｉｄ」を示す。また、例えば「（Ａ，Ｂ）＝（Ｉ，Ｓ）」は、フロントエンドＡのステータスが「Ｉｎｖａｌｉｄｅ」であり、フロントエンドＢのステータスが「Ｓｈａｒｅｄ」であることを示す。さらに、「Ａ−ｒ」は、フロントエンドＡでブロックが参照されたことを示し、「Ａ−ｗ」は、フロントエンドＡでブロックが更新されたことを示す。
【０１８２】
（Ａ，Ｂ）＝（Ｉ，Ｉ）の状態で、フロントエンドＡでブロックが参照されると、（Ａ，Ｂ）＝（Ｓ，Ｉ）に遷移する。（Ａ，Ｂ）＝（Ｉ，Ｉ）の状態で、フロントエンドＢでブロックが参照されると、（Ａ，Ｂ）＝（Ｉ，Ｓ）に遷移する。（Ａ，Ｂ）＝（Ｉ，Ｉ）の状態で、フロントエンドＡでブロックが更新されると、（Ａ，Ｂ）＝（Ｍ，Ｉ）に遷移する。（Ａ，Ｂ）＝（Ｉ，Ｉ）の状態で、フロントエンドＢでブロックが更新されると、（Ａ，Ｂ）＝（Ｉ，Ｍ）に遷移する。
【０１８３】
（Ａ，Ｂ）＝（Ｉ，Ｓ）の状態で、フロントエンドＡでブロックが参照されると、（Ａ，Ｂ）＝（Ｓ，Ｓ）に遷移する。（Ａ，Ｂ）＝（Ｉ，Ｓ）の状態で、フロントエンドＡでブロックが更新されると、（Ａ，Ｂ）＝（Ｍ，Ｉ）に遷移する。（Ａ，Ｂ）＝（Ｉ，Ｓ）の状態で、フロントエンドＢでブロックが更新されると、（Ａ，Ｂ）＝（Ｉ，Ｍ）に遷移する。なお、（Ａ，Ｂ）＝（Ｉ，Ｓ）の状態で、フロントエンドＢでブロックが参照されても、ステータスは変化しない。
【０１８４】
（Ａ，Ｂ）＝（Ｓ，Ｉ）の状態で、フロントエンドＢでブロックが参照されると、（Ａ，Ｂ）＝（Ｓ，Ｓ）に遷移する。（Ａ，Ｂ）＝（Ｓ，Ｉ）の状態で、フロントエンドＢでブロックが更新されると、（Ａ，Ｂ）＝（Ｉ，Ｍ）に遷移する。（Ａ，Ｂ）＝（Ｓ，Ｉ）の状態で、フロントエンドＡでブロックが更新されると、（Ａ，Ｂ）＝（Ｍ，Ｉ）に遷移する。なお、（Ａ，Ｂ）＝（Ｓ，Ｉ）の状態で、フロントエンドＡでブロックが参照されても、ステータスは変化しない。
【０１８５】
（Ａ，Ｂ）＝（Ｉ，Ｍ）の状態で、フロントエンドＡでブロックが参照されると、（Ａ，Ｂ）＝（Ｓ，Ｓ）に遷移する。（Ａ，Ｂ）＝（Ｉ，Ｍ）の状態で、フロントエンドＡでブロックが更新されると、（Ａ，Ｂ）＝（Ｍ，Ｉ）に遷移する。なお、（Ａ，Ｂ）＝（Ｉ，Ｍ）の状態では、フロントエンドＢでブロックが参照されても、ステータスは変化しない。
【０１８６】
（Ａ，Ｂ）＝（Ｍ，Ｉ）の状態で、フロントエンドＢでブロックが参照されると、（Ａ，Ｂ）＝（Ｓ，Ｓ）に遷移する。（Ａ，Ｂ）＝（Ｍ，Ｉ）の状態で、フロントエンドＢでブロックが更新されると、（Ａ，Ｂ）＝（Ｉ，Ｍ）に遷移する。なお、（Ａ，Ｂ）＝（Ｍ，Ｉ）の状態では、フロントエンドＡでブロックが参照されても、あるいはフロントエンドＡでブロックが更新されても、ステータスは変化しない。
【０１８７】
（Ａ，Ｂ）＝（Ｓ，Ｓ）の状態で、フロントエンドＡでブロックが更新されると、（Ａ，Ｂ）＝（Ｍ，Ｉ）に遷移する。（Ａ，Ｂ）＝（Ｓ，Ｓ）の状態で、フロントエンドＢでブロックが更新されると、（Ａ，Ｂ）＝（Ｉ，Ｍ）に遷移する。なお、（Ａ，Ｂ）＝（Ｓ，Ｓ）の状態では、フロントエンドＡ，Ｂのどちらでブロックが参照されても、ステータスは変化しない。
【０１８８】
以上のようにステータスが遷移することで、フロントエンドＡ，Ｂの間でキャッシュコヒーレンシが保たれる。
図１７は、オフコアキャッシュからバックエンドへの書き出し処理例を示すフローチャートである。各フロントエンドのファイル管理部３２０は、オフコアキャッシュ３３２へのデータおよびバージョン番号の追記のタイミングとは非同期に、次のステップＳ１６１の処理を実行する。
【０１８９】
［ステップＳ１６１］ファイル管理部３２０は、オフコアキャッシュ３３２に格納されたデータおよびバージョン番号を、ブロックに関係なく、格納された順番で読み出し、読み出したデータおよびバージョン番号をバックエンド２００に追記する。なお、バックエンド２００におけるデータおよびバージョン番号の格納領域は、ログ構造化ファイルシステムで決められた方法で決定される。
【０１９０】
このような手順で、各フロントエンドのオフコアキャッシュに格納されたデータおよびバージョン番号は、バックエンド２００に格納される。バックエンド２００に対するデータの書き込み速度は、オフコアキャッシュ３３２に対するデータの書き込み速度と比較して、大幅に遅い場合がある。しかしながら、各フロントエンドは、内部キャッシュ３３１に格納したデータおよびバージョン番号を、バックエンド２００に直接格納せずに、オフコアキャッシュ３３２に格納する。このため、バックエンド２００に対するデータの書き込み速度は、各フロントエンドにおけるブロックのデータの更新や参照の速度に影響を与えない。従って、各フロントエンドにおけるデータの更新や参照の性能を向上させることができる。
【０１９１】
さらに、オフコアキャッシュ３３２はバックエンド２００の記憶領域と同様に不揮発性の記憶領域であるので、トラブルの発生によってブロックのデータおよびバージョン番号が失われる確率は、内部キャッシュ３３１のデータおよびバージョン番号をバックエンド２００に直接格納する場合と同等に低くなる。
【０１９２】
次に、フロントエンドが異常停止した場合のデータ復旧処理について説明する。フロントエンドが異常停止した場合、異常停止したフロントエンドの内部キャッシュ３３１に記憶された情報は失われる。そこで、異常停止したフロントエンドが再起動した後、各フロントエンドのオフコアキャッシュ３３２に記憶された情報を基に、キャッシュのデータを復旧する。
【０１９３】
図１８は、代表サーバのファイル管理部によるデータ復旧処理手順の例を示すフローチャートである。
ストレージシステム１００に含まれるフロントエンドのいずれか１つは、フロントエンドの異常停止が発生した場合にデータ復旧の制御を行う代表サーバに、あらかじめ決められている。ストレージシステム１００内の少なくとも１つのフロントエンドが異常停止した場合、異常停止したフロントエンドが再起動した後、代表サーバであるフロントエンドは、図１８に示す処理を実行する。なお、図１８では例として、１つのブロックについての処理を示すが、実際には、すべてのブロックについて図１８の処理が実行される。
【０１９４】
［ステップＳ１７１］ファイル管理部３２０は、オフコアキャッシュ３３２からブロックのバージョン番号を読み込み、最新のバージョン番号を判別する。なお、代表サーバ以外の各フロントエンドのファイル管理部３２０も、同様に、オフコアキャッシュ３３２からブロックのバージョン番号を読み込み、最新のバージョン番号を判別する。代表サーバ以外の各フロントエンドのファイル管理部３２０は、最新のバージョン番号を判別した後、通知要求を監視する状態になる。
【０１９５】
［ステップＳ１７２］ファイル管理部３２０は、通知要求をブロードキャストする。
［ステップＳ１７３］ファイル管理部３２０は、他のフロントエンドから、通知要求に対する応答情報を受信し、受信した応答情報から、他のフロントエンドのそれぞれが保持する最新データのバージョン番号を認識する。
【０１９６】
［ステップＳ１７４］ファイル管理部３２０は、ステップＳ１７１で判別した最新のバージョン番号と、ステップＳ１７３で他のクライアントから受信したバージョン番号とから、自装置が最新データを保持しているかを判定する。ファイル管理部３２０は、自装置が最新データを保持している場合、ステップＳ１７５の処理を実行する。一方、ファイル管理部３２０は、自装置が最新データを保持していない場合、ステップ１７７の処理を実行する。
【０１９７】
［ステップＳ１７５］ファイル管理部３２０は、他のすべてのフロントエンドに対してパージ要求を送信し、送信先のフロントエンドにおける対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に設定させる。
【０１９８】
［ステップＳ１７６］ファイル管理部３２０は、自装置のオフコアキャッシュ３３２に格納された最新データおよびそのバージョン番号を、内部キャッシュ３３１に格納するとともに、対象ブロックのステータスを「Ｓｈａｒｅｄ」に設定する。これによりデータ復旧処理が完了し、ストレージシステム１００の運用が再開される。
【０１９９】
［ステップＳ１７７］ファイル管理部３２０は、最新データを保持しているフロントエンドに対して、対象ブロックのステータスを「Ｓｈａｒｅｄ」にするように要求する。
［ステップＳ１７８］ファイル管理部３２０は、他のフロントエンドのうち、最新データを保持していないフロントエンドに対して、パージ要求を送信し、送信先のフロントエンドにおける対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に設定させる。
【０２００】
［ステップＳ１７９］ファイル管理部３２０は、自装置の対象ブロックのステータスを「Ｉｎｖａｌｉｄ」に設定する。これによりデータ復旧処理が完了し、ストレージシステム１００の運用が再開される。
【０２０１】
以上の図１８の処理によれば、代表サーバは、バックエンド２００からデータおよびバージョン番号を書き戻さずに、各フロントエンドのオフコアキャッシュに格納されたデータおよびバージョン情報を基に、キャッシュのデータを復旧させることができる。従って、短時間でストレージシステム１００の運用を再開させることができる。
【０２０２】
なお、上記の各実施の形態に示したアクセス制御装置、フロントエンド、データ格納サーバおよびクライアントのそれぞれの処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０２０３】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０２０４】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０２０５】
以上の各実施の形態に関し、さらに以下の付記を開示する。
（付記１）  ファイルが格納される記憶装置と、
前記記憶装置に対するアクセスをそれぞれ制御するととともに、前記記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリをそれぞれ備える複数のアクセス制御装置と、
を有し、
前記複数のアクセス制御装置のうちの第１のアクセス制御装置は、
所定ブロックの更新要求を受けたとき、当該所定ブロックの最新データが当該第１のアクセス制御装置のキャッシュメモリに記憶されていない場合に、前記複数のアクセス制御装置のうち、前記最新データが自装置のキャッシュメモリに記憶された第２のアクセス制御装置から、当該最新データに付加されたバージョン番号を取得し、
前記所定ブロックを更新する更新データを前記第１のアクセス制御装置のキャッシュメモリに格納するとともに、当該更新データに対して、前記第２のアクセス制御装置から取得したバージョン番号を基に、新たなバージョン番号を付加する、
ことを特徴とするストレージシステム。
【０２０６】
（付記２）  前記第２のアクセス制御装置は、前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に通知するとともに、当該最新データをバージョン番号とともに所定の不揮発性記憶装置に追記した後、前記第１のアクセス制御装置に対して前記所定ブロックの更新を許可することを特徴とする付記１記載のストレージシステム。
【０２０７】
（付記３）  前記複数のアクセス制御装置は、不揮発性のローカル記憶装置をそれぞれ備え、
前記第２のアクセス制御装置は、
前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に通知するとともに、当該最新データおよび当該最新データのバージョン番号を、当該第２のアクセス制御装置が備える前記ローカル記憶装置に追記した後、前記第１のアクセス制御装置に対して前記所定ブロックの更新を許可し、
前記最新データおよび当該最新データのバージョン番号を前記ローカル記憶装置に追記したタイミングと非同期に、当該ローカル記憶装置に追記した前記最新データを前記記憶装置に追記する、
ことを特徴とする付記２記載のストレージシステム。
【０２０８】
（付記４）  前記複数のアクセス制御装置の１つが異常停止した場合、異常停止したアクセス制御装置が復旧した後、前記複数のアクセス制御装置のうちの所定のアクセス制御装置は、すべてのアクセス制御装置の前記ローカル記憶装置に記憶された、ブロックごとのバージョン番号に基づき、最新のバージョン番号に対応付けられたデータをバージョン番号とともに当該所定のアクセス制御装置のキャッシュメモリおよび前記ローカル記憶装置に格納して、前記ストレージシステムの運用を再開させることを特徴とする付記３記載のストレージシステム。
【０２０９】
（付記５）  前記第２のアクセス制御装置は、前記第１のアクセス制御装置からの通知要求に応じて前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に送信した後、前記第１のアクセス制御装置からデータ更新の許可を求めるための許可依頼を受信したとき、前記最新データおよび当該最新データのバージョン番号を当該第２のアクセス制御装置が備える前記ローカル記憶装置に追記し、受信した前記許可依頼に対してデータ更新を許可するための応答を送信することを特徴とする付記３または４記載のストレージシステム。
【０２１０】
（付記６）  前記第１のアクセス制御装置は、
前記所定ブロックの前記最新データがキャッシュメモリに格納されているかを示すステータス情報と、キャッシュメモリに格納されている前記所定ブロックのデータに付加されたバージョン番号とを通知するように要求するための通知要求をブロードキャストし、
前記通知要求に応じて返信された前記ステータス情報に基づいて、前記最新データが自装置のキャッシュメモリに記憶されたアクセス制御装置を判別するとともに、前記通知要求に応じて返信されたバージョン番号に基づいて、前記更新データに付加する新たなバージョン番号を決定する、
ことを特徴とする付記２〜４のいずれか１つに記載のストレージシステム。
【０２１１】
（付記７）  前記通知要求を受信した各アクセス制御装置は、当該通知要求に対する応答情報をブロードキャストし、
前記通知要求を受信したすべてのアクセス制御装置から前記第１のアクセス制御装置に対して正常応答が出力された場合に、前記第１のアクセス制御装置を除くすべてのアクセス制御装置において、前記所定ブロックについてのデータ更新およびデータ参照が禁止される、
ことを特徴とする付記６記載のストレージシステム。
【０２１２】
（付記８）  記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリを備えるコンピュータに、
所定ブロックの更新要求を受けたとき、当該所定ブロックの最新データが前記コンピュータのキャッシュメモリに記憶されていない場合に、それぞれキャッシュメモリを備える他の複数のコンピュータのうち、前記最新データが自装置のキャッシュメモリに記憶された他のコンピュータから、当該最新データに付加されたバージョン番号を取得し、
前記所定ブロックを更新する更新データを前記コンピュータのキャッシュメモリに格納するとともに、当該更新データに対して、前記他のコンピュータから取得したバージョン番号を基に、新たなバージョン番号を付加する、
処理を実行させるキャッシュ制御プログラム。
【０２１３】
（付記９）  前記コンピュータに、
前記他の複数のコンピュータのいずれかが前記所定ブロックの更新要求を受け、かつ、当該所定ブロックの前記最新データが前記コンピュータのキャッシュメモリに記憶されている場合に、前記最新データに付加されたバージョン番号を、更新要求を受けた他のコンピュータに通知するとともに、当該最新データをバージョン番号とともに所定の不揮発性記憶装置に追記した後、前記更新要求を受けた他のコンピュータに対して前記所定ブロックの更新を許可する、
処理をさらに実行させることを特徴とする付記８記載のキャッシュ制御プログラム。
【０２１４】
（付記１０）  前記コンピュータおよび前記他の複数のコンピュータは、不揮発性のローカル記憶装置をそれぞれ備え、
前記更新要求を受けた他のコンピュータに対して前記所定ブロックの更新を許可する処理では、前記最新データに付加されたバージョン番号を前記更新要求を受けた他のコンピュータに通知するとともに、当該最新データおよび当該最新データのバージョン番号を前記コンピュータの前記ローカル記憶装置に追記した後、前記更新要求を受けた他のコンピュータに対して前記所定ブロックの更新を許可し、
前記コンピュータに、
前記最新データおよび当該最新データのバージョン番号を前記コンピュータの前記ローカル記憶装置に追記したタイミングと非同期に、当該ローカル記憶装置に追記した前記最新データを前記記憶装置に追記する、
処理をさらに実行させることを特徴とする付記９記載のキャッシュ制御プログラム。
【０２１５】
（付記１１）  前記コンピュータに、
前記他の複数のコンピュータの１つが異常停止した場合、異常停止した他のコンピュータが復旧した後、前記コンピュータおよび前記他の複数のコンピュータのそれぞれの前記ローカル記憶装置に記憶された、ブロックごとのバージョン番号に基づき、最新のバージョン番号に対応付けられたデータをバージョン番号とともに前記コンピュータのキャッシュメモリおよび前記ローカル記憶装置に格納して、前記コンピュータおよび前記他の複数のコンピュータを含むストレージシステムの運用を再開させる、
処理をさらに実行させることを特徴とする付記１０記載のキャッシュ制御プログラム。
【０２１６】
（付記１２）  前記更新要求を受けた他のコンピュータに対して前記所定ブロックの更新を許可する処理では、前記更新要求を受けた他のコンピュータからの通知要求に応じて前記最新データに付加されたバージョン番号を返信した後、前記更新要求を受けた他のコンピュータからデータ更新の許可を求めるための許可依頼を受信したとき、前記最新データおよび当該最新データのバージョン番号を前記コンピュータの前記ローカル記憶装置に追記し、受信した前記許可依頼に対してデータ更新を許可するための応答を送信する、
ことを特徴とする付記１０または１１記載のキャッシュ制御プログラム。
【０２１７】
（付記１３）  前記コンピュータに、
前記所定ブロックの前記最新データがキャッシュメモリに格納されているかを示すステータス情報と、キャッシュメモリに格納されている前記所定ブロックのデータに付加されたバージョン番号とを通知するように要求するための通知要求をブロードキャストする、
処理をさらに実行させ、
前記コンピュータが新たなバージョン番号を付加する処理では、前記通知要求に応じて返信された前記ステータス情報に基づいて、前記最新データが自装置のキャッシュメモリに記憶された前記他のコンピュータを判別するとともに、前記通知要求に応じて返信されたバージョン番号に基づいて、前記更新データに付加する新たなバージョン番号を決定する、
ことを特徴とする付記９〜１１のいずれか１つに記載のキャッシュ制御プログラム。
【０２１８】
（付記１４）  前記コンピュータに、
前記他の複数のコンピュータのいずれかからブロードキャストされた前記通知要求を受信したとき、当該通知要求に対する応答情報をブロードキャストし、
前記通知要求を受信したすべての他のコンピュータから正常応答が出力された場合に、前記コンピュータにおける前記所定ブロックについてのデータ更新およびデータ参照を禁止する、
処理をさらに実行させることを特徴とする付記１３記載のキャッシュ制御プログラム。
【０２１９】
（付記１５）  ファイルが格納される記憶装置と、前記記憶装置に対するアクセスをそれぞれ制御するととともに、前記記憶装置に格納するファイルがブロック単位で一時的に記憶されるキャッシュメモリをそれぞれ備える複数のアクセス制御装置と、を有するストレージシステムにおけるキャッシュ制御方法であって、
前記複数のアクセス制御装置のうちの第１のアクセス制御装置が、
所定ブロックの更新要求を受けたとき、当該所定ブロックの最新データが当該第１のアクセス制御装置のキャッシュメモリに記憶されていない場合に、前記複数のアクセス制御装置のうち、前記最新データが自装置のキャッシュメモリに記憶された第２のアクセス制御装置から、当該最新データに付加されたバージョン番号を取得し、
前記所定ブロックを更新する更新データを前記第１のアクセス制御装置のキャッシュメモリに格納するとともに、当該更新データに対して、前記第２のアクセス制御装置から取得したバージョン番号を基に、新たなバージョン番号を付加する、
ことを特徴とするキャッシュ制御方法。
【０２２０】
（付記１６）  前記第２のアクセス制御装置が、前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に通知するとともに、当該最新データをバージョン番号とともに所定の不揮発性記憶装置に追記した後に、前記第１のアクセス制御装置に対して前記所定ブロックの更新を許可する、
処理を含むことを特徴とする付記１５記載のキャッシュ制御方法。
【０２２１】
（付記１７）  前記複数のアクセス制御装置は、不揮発性のローカル記憶装置をそれぞれ備え、
前記第２のアクセス制御装置が前記第１のアクセス制御装置に更新を許可する処理では、前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に通知するとともに、当該最新データおよび当該最新データのバージョン番号を、当該第２のアクセス制御装置が備える前記ローカル記憶装置に追記した後に、前記第１のアクセス制御装置に対して前記所定ブロックの更新を許可し、
さらに、前記第２のアクセス制御装置が、前記最新データおよび当該最新データのバージョン番号を前記ローカル記憶装置に追記したタイミングと非同期に、当該ローカル記憶装置に追記した前記最新データを前記記憶装置に追記する処理を含むことを特徴とする付記１６記載のキャッシュ制御方法。
【０２２２】
（付記１８）  前記複数のアクセス制御装置の１つが異常停止し、異常停止したアクセス制御装置が復旧した後に、前記複数のアクセス制御装置のうちの所定のアクセス制御装置が、すべてのアクセス制御装置の前記ローカル記憶装置に記憶された、ブロックごとのバージョン番号に基づき、最新のバージョン番号に対応付けられたデータをバージョン番号とともに当該所定のアクセス制御装置のキャッシュメモリおよび前記ローカル記憶装置に格納して、前記ストレージシステムの運用を再開させる、
処理を含むことを特徴とする付記１７記載のキャッシュ制御方法。
【０２２３】
（付記１９）  前記第２のアクセス制御装置が前記第１のアクセス制御装置に更新を許可する処理では、前記第１のアクセス制御装置からの通知要求に応じて前記最新データに付加されたバージョン番号を前記第１のアクセス制御装置に送信した後、前記第１のアクセス制御装置からデータ更新の許可を求めるための許可依頼を受信したとき、前記最新データおよび当該最新データのバージョン番号を前記第２のアクセス制御装置が備える前記ローカル記憶装置に追記し、受信した前記許可依頼に対してデータ更新を許可するための応答を送信することを特徴とする付記１７または１８記載のキャッシュ制御方法。
【０２２４】
（付記２０）  前記第１のアクセス制御装置が、前記所定ブロックの前記最新データがキャッシュメモリに格納されているかを示すステータス情報と、キャッシュメモリに格納されている前記所定ブロックのデータに付加されたバージョン番号とを通知するように要求するための通知要求をブロードキャストする、
処理をさらに含み、
前記第１のアクセス制御装置が新たなバージョン番号を付加する処理では、前記通知要求に応じて返信された前記ステータス情報に基づいて、前記最新データが自装置のキャッシュメモリに記憶されたアクセス制御装置を判別するとともに、前記通知要求に応じて返信されたバージョン番号に基づいて、前記更新データに付加する新たなバージョン番号を決定する、
ことを特徴とする付記１６〜１８のいずれか１つに記載のキャッシュ制御方法。
【符号の説明】
【０２２５】
１  ストレージシステム
１０  記憶装置
２０ａ，２０ｂ  アクセス制御装置
２１  キャッシュメモリ
２２  ローカル記憶装置
【図１】
2013222373.tif 000003
【図２】
2013222373.tif 000004
【図３】
2013222373.tif 000005
【図４】
2013222373.tif 000006
【図５】
2013222373.tif 000007
【図６】
2013222373.tif 000008
【図７】
2013222373.tif 000009
【図８】
2013222373.tif 000010
【図９】
2013222373.tif 000011
【図１０】
2013222373.tif 000012
【図１１】
2013222373.tif 000013
【図１２】
2013222373.tif 000014
【図１３】
2013222373.tif 000015
【図１４】
2013222373.tif 000016
【図１５】
2013222373.tif 000017
【図１６】
2013222373.tif 000018
【図１７】
2013222373.tif 000019
【図１８】
2013222373.tif 000020