特許 6589500 情報処理端末、共有ファイルシステム、共有ファイル方法および共有ファイルプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6589500

(24)【登録日】2019年9月27日

(45)【発行日】2019年10月16日

(54)【発明の名称】情報処理端末、共有ファイルシステム、共有ファイル方法および共有ファイルプログラム

(51)【国際特許分類】

   G06F 16/172 20190101AFI20191007BHJP

   G06F 16/11 20190101ALI20191007BHJP

   G06F 16/182 20190101ALI20191007BHJP

   G06F 3/06 20060101ALI20191007BHJP

【ＦＩ】

   G06F16/172

   G06F16/11

   G06F16/182

   G06F3/06 301Z

【請求項の数】7

【全頁数】24

(21)【出願番号】特願2015-184912(P2015-184912)

(22)【出願日】2015年9月18日

(65)【公開番号】特開2017-59105(P2017-59105A)

(43)【公開日】2017年3月23日

【審査請求日】2018年8月9日

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100124154

【弁理士】

【氏名又は名称】下坂 直樹

(72)【発明者】

【氏名】青野 寛

【審査官】 早川 学

(56)【参考文献】

【文献】 特開２００６−２９３５９３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １６／００−１６／９５８

Ｇ０６Ｆ ３／０６

(57)【特許請求の範囲】

【請求項1】

共有ファイルシステムに接続可能な、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、前記キャッシュデータを、前記ペアリングする端末のキャッシュメモリ領域に書き込むよう指示し、
外部ネットワークに対し、自端末のキャッシュメモリ領域の空き容量を示す情報をブロードキャスト送信する、
情報処理端末。

【請求項2】

前記ペアリングする端末から、前記ファイル単位毎にキャッシュデータを受信すると、当該キャッシュデータを、自端末の前記キャッシュメモリ領域内に書き込む、
請求項１に記載の情報処理端末。

【請求項3】

前記外部ネットワークから、他端末のキャッシュメモリ領域の空き容量を示す情報を受信し、当該情報を基に、前記ペアリングする端末を決定する
請求項１または２に記載の情報処理端末。

【請求項4】

情報処理端末から共有ファイルシステムサーバへのデータ入出力量を検知し、前記データ入出力量が所定の閾値を越える場合、前記情報処理端末から前記共有ファイルシステムサーバへのデータの入出力を調整する、
請求項１乃至３のいずれかに記載の情報処理端末。

【請求項5】

請求項１乃至４のいずれかに記載の情報処理端末を複数と、
前記情報処理端末の各々がデータファイルを共有するための共有ファイルシステムサーバと、
を備える共有ファイルシステム。

【請求項6】

共有ファイルシステムに接続可能な、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、
前記キャッシュデータを、前記ペアリングする端末のキャッシュメモリ領域に書き込むよう指示し、
外部ネットワークに対し、自端末のキャッシュメモリ領域の空き容量を示す情報をブロードキャスト送信する、
共有ファイル方法。

【請求項7】

共有ファイルシステムに接続可能な、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、
前記キャッシュデータを、前記ペアリングする端末のキャッシュメモリ領域に書き込むよう指示し、
外部ネットワークに対し、自端末のキャッシュメモリ領域の空き容量を示す情報をブロードキャスト送信する、
機能をコンピュータに実行させる共有ファイルプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、クライアント端末側から共有ファイル（ストレージ）に対するデータの読み出しおよび書き込みを管理することができる情報処理端末等に関する。

【背景技術】

【0002】

近年、ストレージサーバ等において、記憶装置としてＨＤＤ（Hard Disc Drive）の代わりにＳＳＤ（Solid State Drive）を搭載しているもの、又はその両方を搭載しているものがある。この場合、多くはＯＳ（operation system）格納用には高速で小容量のＳＳＤを使い、データ格納用には低速だが低価格かつ大容量のＨＤＤを用いる。可能な限り最速のシステムを構築しようとすると、データ格納用に最速のＳＳＤを使用すればよいが、大容量ＳＳＤは高価である。

【0003】

このため、低速で大容量のＨＤＤデータドライブのキャッシュとして、高速で小容量のＳＳＤを利用する手法が用いられている。例えば、ストレージのデータ最適配置機能や、Linux（リナックス；登録商標）のbcasheなどがこれにあたる。

【0004】

しかしながら、この手法では、キャッシュ（ＳＳＤ等）から安定したストレージ（ＨＤＤ等）までの距離が遠い場合、突発的に大量に発生するＩＯ（Input/Output）キャッシュとしては適切に動作しないことがある。また、クライアント端末が非常に多い場合、キャッシュ内の記憶領域がすぐに飽和して性能低下を招きやすい。

【0005】

さらに、データ更新が多いシステムで使用する場合には、共有ファイルシステム間のキャッシュコヒーレンシを保つため頻繁にキャッシュフラッシュを行う必要があり、これはＩＯ性能の低下を招く要因となっていた。具体的例としては、この手法を用いて高性能コンピューティング（単位時間当たりの計算量が非常に多い計算処理）を実行する場合、低いＩＯ性能が起因し、途中の計算結果を一時格納する記憶領域（チェックポイントファイル）としては、高い性能を発揮しない。

【0006】

この問題を解消するため、複数のクライアント端末に処理を分散させるストレージシステムが開発されている。当該クライアント端末の各々は高速ＩＯ可能なキャッシュ（ＳＤＤ）を備えている。

【0007】

このようなストレージシステムにおいて、リモートコピー時にバッファのデータ洩れを防ぐためにＩＯ制限を実行する技術が開示されている（特許文献１）。

【0008】

また、このようなストレージシステムにおいて、シン・プロビジョニング機能と高可用性を両立させるための技術が開示されている（特許文献２）。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２００７−１８２３６号公報

【特許文献2】特開２００９−２３０７４２号公報

【発明の概要】

【発明が解決しようとする課題】

【0010】

特許文献１および２の技術では、クライアント端末間でキャッシュを相互に利用するためにペアリング機構を設ける。しかしながらクライアント端末のペアは自動に検出されるものではなく、そのペアリングに手間を要していた。更に、ペアリングの単位はディスク単位であり、小規模なタスクを実現するには頻繁なペアリング処理が必要となっていた。

【0011】

本発明は、上記の問題点を解決するべくなされた。本発明は、共有ストレージシステムにおいて、適切なペアリング処理を自動で行い、キャッシュ書き込み時の信頼性が高い情報処理端末等を提供することを主たる目的とする。

【課題を解決するための手段】

【0012】

上記の課題を解決するために、本発明の第１の特徴は、共有するファイルシステムに接続可能な、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、キャッシュデータを、ペアリングする端末のキャッシュメモリ領域に書き込むよう指示する、
情報処理端末である。

【0013】

本発明の第２の特徴は、上記の情報処理端末を複数と、
情報処理端末の各々がデータファイルを共有するための共有ファイルシステムサーバと、を備える共有ファイルシステムである。

【0014】

本発明の第３の特徴は、共有するファイルシステムに接続可能な、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、
キャッシュデータを、ペアリングする端末のキャッシュメモリ領域に書き込むよう指示する、
共有ファイル方法である。

【0015】

本発明の第４の特徴は、共有するファイルシステムに接続可能な、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、
キャッシュデータを、ペアリングする端末のキャッシュメモリ領域に書き込むよう指示する
機能をコンピュータに実行させる共有ファイルプログラムである。

【発明の効果】

【0016】

本発明によれば、共有ストレージシステムにおいて、適切なペアリング処理を自動で行い、キャッシュ書き込み時の信頼性が高い情報処理端末等を提供することができる。

【図面の簡単な説明】

【0017】

【図1】本発明の第１の実施形態に係る共用ファイルシステムの構成例を示す図である。

【図2】キャッシュ統計情報のデータ構成例を示す図である。

【図3】キャッシュ統計情報記憶部内のキャッシュ統計情報のデータ構成例を示す図である。

【図4】キャッシュデータファイルのディレクトリ構造を表す図である。

【図5】キャッシュ内におけるキャッシュデータファイルの構造を表す図である。

【図6】ＩＯリクエスト処理の動作を示すフローチャートである。

【図7】共有ファイルへの書き込み処理の動作を示すフローチャートである。

【図8】キャッシュ統計情報の送出処理の動作を示すフローチャートである。

【図9】キャッシュ統計情報の収集処理の動作を示すフローチャートである。

【図10】送信側のキャッシュのペアリング処理の動作を示すフローチャートである。

【図11】受信側のキャッシュのペアリング処理の動作を示すフローチャートである。

【図12】ペアリング先への書き込み処理の動作を示すフローチャートである。

【図13】キャッシュデータの無効化処理の動作を示すフローチャートである。

【図14】キャッシュのフラッシュ処理の動作を示すフローチャートである。

【図15】キャッシュのペアリング解除処理の動作を示すフローチャートである。

【図16】受信側におけるキャッシュのペアリング解除処理の動作を示すフローチャートである。

【図17】ファイルの読み込み処理の動作を示すフローチャートである。

【図18】強制キャッシュフラッシュ処理の動作を示すフローチャートである。

【図19】ファイルのクローズ処理の動作を示すフローチャートである。

【図20】本発明の第２の実施形態に係るＩＯ端末の構成例を示す図である。

【図21】情報処理装置の内部構成例を示す図である。

【発明を実施するための形態】

【0018】

次に図面を参照して、本発明の実施形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。ただし、図面は本発明の実施形態における構成を模式的に表している。更に以下に記載される本発明の実施形態は一例であり、その本質を同一とする範囲において適宜変更可能である。

【0019】

＜本発明の第１の実施形態＞
バースト性の高いＩＯ処理には、共有ファイルシステムであっても、個々のＩＯ端末は、データを共有する必要がないものも多い（特に中間ファイル等）。このため、このようなファイルについては、可能な限りＩＯ端末内で閉じて処理をし、最終的な結果を共有ファイルシステムに書き戻す手法が用いられる（ステージング、デステージング等）。本発明の第１の実施形態においては、このようなＩＯ処理を自動化する。これは、大容量で安価なＳＳＤ等の高速キャッシュメモリを用いた、低レイテンシで且つ広帯域における、ローカルファイルシステム内でのＩＯ処理、即ち、共有ファイルシステムへのＩＯ帯域とローカルファイルシステムのＩＯ帯域とを可能な限り等しくすることにより、実現できる。

【0020】

（共有ファイルシステム）
本発明の第１の実施形態に係る共有ファイルシステム１００について図１を参照して説明する。第１の実施形態に係る共有ファイルシステム１００は、図１に示すように、複数のＩＯ端末（情報処理端末）１，２，３と、共有ファイルシステムサーバ（以下、「共有ＦＳサーバ」と記載）４とを備え、各ＩＯ端末１〜３および共有ＦＳサーバ４間はネットワーク５で接続され、データ通信可能となっている。

【0021】

共有ＦＳサーバ４は、ＩＯ端末１〜３間で共有するデータファイルを管理するファイルシステム機能を備える。共有ＦＳサーバ４は、共有ファイルを格納する記憶装置である共有ファイル部４ａを備える。

【0022】

ＩＯ端末１〜３は同じ構成を備える。ＩＯ端末２は、ＩＯキャッシュ部２５を備える。ＩＯ端末３は、ＩＯキャッシュ部３５を備える。尚、以下においては、便宜上、自端末はＩＯ端末１、他端末はＩＯ端末２，３として説明する。

【0023】

（ＩＯ端末）
ＩＯ端末１〜３のＯＳは、図１に示すようにユーザ領域（アプリケーション領域）、カーネル領域、ハードウェア領域から構成される。ユーザ領域は、各ＩＯ端末１〜３のユーザが各々の仕様に応じて変更可能な領域である。カーネル領域は、全てのＩＯ端末１〜３が共通して備えるＯＳの管理部であり、具体的には、ＩＯ端末１〜３のリソースを管理し、ハードウェア領域内のハードウェア資源とユーザ領域内のソフトウェアコンポーネント（アプリケーションプログラム等）との間のセッション、トランザクション等のデータのやりとりを管理する。例えば、動作中のプログラムの実行状態を管理し、ハードウェア資源を管理してアプリケーションプログラムがハードウェア機能を利用する機構を提供する。

【0024】

ユーザ領域には、アプリケーション部１１、入出力ライブラリ部１２、ＩＯキャッシュ部１５が存在する。カーネル領域には、アプリケーション仮想ファイルシステム部（以下、「ＡＰ仮想ＦＳ部」と記載）１３、ユーザファイルシステム制御部（以下、「ユーザＦＳ制御部」と記載）１４、ＩＯ仮想ファイルシステム部（以下、「ＩＯ仮想ＦＳ部」と記載）１６、ローカルファイルシステム部（以下、「ローカルＦＳ部」と記載）１６１および共有ファイルシステムクライアント制御部（以下、「共有ＦＳクライアント制御部」と記載）１６２が存在する。ハードウェア領域には、ＳＤＤ１７およびネットワーク接続部１８が存在する。

【0025】

先ず、ユーザ領域の各部について説明する。

【0026】

ＩＯキャッシュ部１５は、キャッシュ（ＳＳＤ１７）および共有ＦＳサーバ４に対するＩＯ制御を実行するための機構であり、ＩＯ処理用のキャッシュデータファイルを作成する。ＩＯキャッシュ部１５は、ＩＯキャッシュ制御部１５１およびデータ流量制御部１５２を備える。

【0027】

ＩＯキャッシュ制御部１５１は、ペアリング部１５４を備える。ペアリング部１５４は、キャッシュデータファイルの複製を持たせるためのペアリング先ＩＯ端末を選出し、選出されたＩＯ端末との間でペアリング処理およびペアリング解除処理等を行う。

【0028】

ＩＯキャッシュ制御部１５１はネットワーク接続部１８にアクセス可能であり、ネットワーク５を経由して、他のＩＯ端末２，３が備えるＩＯキャッシュ部２５、３５とデータ通信する。

【0029】

ＩＯキャッシュ制御部１５１は、データ流量制御部１５２と接続されている。

【0030】

データ流量制御部１５２は、ＩＯ仮想ＦＳ部１６を経由して、共有ＦＳクライアント制御部１６２にＩＯリクエストを行う。

【0031】

データ流量制御部１５２は、定期的に自身（ＩＯ端末１）のキャッシュ統計情報を、ネットワーク接続部１８を介して、他のＩＯ端末２，３に通知する。尚、通知したキャッシュ統計情報は、キャッシュ統計情報記憶部１５３に格納される。

【0032】

また、データ流量制御部１５２は、ネットワーク接続部１８を介して、他のＩＯ端末２，３からキャッシュ統計情報を収集し、収集したキャッシュ統計情報をキャッシュ統計情報記憶部１５３に格納する。

【0033】

自ＩＯ端末１および他ＩＯ端末２,３が発行するキャッシュ統計情報は、図２に示すように、「ＩＰ（internet protocol）アドレス」、「キャッシュ空き容量」、「共有ＦＳデータ流量」、「更新時刻」をデータ項目として有する。「ＩＰアドレス」は、ＩＯ端末１〜３を識別可能なＩＰアドレスである。「キャッシュ空き容量」は当該ＩＰアドレスを有するＩＯ端末１〜３のＳＳＤ１７の空き容量を示す。「共有ＦＳデータ流量」は共有ＦＳサーバ４に対する各ＩＯ端末１〜３からのデータ流量を、共有ＦＳサーバ４が毎秒処理できるＩ／Ｏアクセスの数（IOPS）と、毎秒のデータ量（MByte/s）とで計測した値である。「更新時刻」は共有ＦＳサーバ４にてデータの更新処理が行われた時刻のタイムスタンプである。

【0034】

キャッシュ統計情報記憶部１５３内には、図３に示すように、自ＩＯ端末１のキャッシュ統計情報と共に、他のＩＯ端末２，３のキャッシュ統計情報が格納される。ＩＯ端末１〜３は、「ＩＰアドレス」を識別子として判別される。

【0035】

アプリケーション部１１は、ユーザが実行するアプリケーションプログラムを格納する。アプリケーションプログラムは図示しないＣＰＵ（Central Processing Unit）によって適宜演算実行される。詳細は後述する。

【0036】

尚、アプリケーションプログラムには多くの場合キャッシュデータファイル（ＳＤＤ１７）や共有ファイル部４ａへのＩＯ処理（ファイルのオープン処理およびクローズ処理）が含まれる。

【0037】

入出力ライブラリ部１２は、アプリケーションプログラムに含まれるＩＯ処理を実行するために必要な関数を格納するデータファイルである。

【0038】

次にカーネル領域の各部について説明する。

【0039】

ＩＯ仮想ＦＳ部１６は、ＩＯ処理を実行するための仮想ファイルシステムである。ＩＯ仮想ＦＳ部１６は、ローカルＦＳ部１６１および共有ＦＳクライアント制御部１６２と接続され、これらを透過的に利用する。

【0040】

ローカルＦＳ部１６１にはＳＳＤ１７が直接接続されている。これにより、高速かつ低レイテンシのストレージアクセスが可能となる。

【0041】

共有ＦＳクライアント制御部１６２は、ネットワーク接続部１８を介し、ネットワーク５上の、共有ＦＳサーバ４とデータ通信する。

【0042】

ローカルＦＳ部１６１は、キャッシュ（ＳＳＤ１７）内部におけるデータファイルのディレクトリを構築し、当該ディレクトリ構造を保持する。当該ディレクトリ構造の一例を図４に示す。

【0043】

図４に示すディレクトリ構造においては、ルートディレクトリをルートとし、その下位にディレクトリａ、ディレクトリｂ、…、ディレクトリＮと、Ｎ個のサブディレクトリを有する。各サブディレクトリは、各々、キャッシュデータファイルを備える。あるデータに対するディレクトリＮは、アクセス集中を避けるため、ハッシュ関数f（ｘ）（ｘ＝ローカルＦＳのファイルハンドル値）を用いて１〜Ｎのいずれかに決定される。

【0044】

キャッシュ（ＳＳＤ１７）内部のデータファイル構造を図５に示す。当該データファイル構造は、データ項目として、「ペア識別子」、「マスタバックアップフラグ」、「ブロック番号」、「キャッシュデータ」、「更新フラグ」および「更新時間」を備える。

【0045】

「ペア識別子」は、ペアリング先を識別可能な識別子（ペア識別子）であり、例えば、ＩＰ（Internet Protocol）アドレスである。「マスタ／バックアップフラグ」はペア識別子に紐付られたデータが、マスタ（自ＩＯ端末の保持する）データか、バックアップ（ペアリング先として保持する）データかを示すフラグである。「ブロック番号」は、キャッシュデータが格納されるブロック番号である。「キャッシュデータ」は、ＳＳＤ１７にキャッシュされたデータ本体である。

【0046】

「更新フラグ」は、データの状態を示すフラグである。更新フラグには「MODIFIED(更新状態：データが最新に更新されている)」、「SHARED(共有：共有ＦＳサーバ１７内の共有ファイル部４ａのデータと同期している)」、「INVALID(無効)」、「NO FILE（データが存在しない）」の４種類がある。「更新時間」は、更新された時刻のタイムスタンプである。

【0047】

共有ＦＳクライアント制御部１６２は、共有ＦＳサーバ４のファイルシステムにアクセスする権利を制御するための機構である。

【0048】

ＡＰ仮想ＦＳ部１３は、アプリケーション使用時に使用する仮想ファイルシステムである。

【0049】

ユーザＦＳ制御部１４は、ユーザ空間で稼働するプログラムとしてファイルシステムを実装するための機構（フレームワーク）であり、具体的にはＦＵＳＥ（Filesystem in USErspace）等である。

【0050】

次にハードウェア領域の各部について説明する。

【0051】

ＳＳＤ１７は、高速ＩＯ可能な半導体メモリである、ＩＯ端末１〜３側のキャッシュメモリとして使用する。

【0052】

ネットワーク接続部１８は、自ＩＯ端末１を、他ＩＯ端末２，３および共有ＦＳサーバ４と、ネットワーク５を介して通信接続するためのインターフェースである。

【0053】

（共有ファイルシステムの動作）
次に共有ファイルシステム１００における各ＩＯ端末１〜３の動作について説明する。ＩＯ端末１〜３の主な動作としては、（１）ＩＯリクエストの処理、（２）共有ファイルへの書き込み処理、（３）キャッシュ統計情報の送出および収集処理、（４）キャッシュのペアリング処理、（５）ペアリング先への書き込み処理、（６）キャッシュデータの無効化処理、（７）キャッシュのフラッシュ処理、（８）キャッシュのペアリング解除処理、（９）ファイルの読み込み処理、（１０）ファイルのクローズ処理がある。以下、これらの処理について図面を参照し、詳細に説明する。

【0054】

（１．ＩＯリクエストの処理）
ＩＯリクエストの処理について、図６のフローチャートを参照して説明する。

【0055】

まず、ステップＡ１において、アプリケーション部１１が備えるアプリケーションプログラムがＣＰＵ（不図示）によって実行されると、当該プログラムの記述に含まれるＩＯリクエスト処理が読み出される。この結果、ＣＰＵは、当該プログラムの実行必要なデータファイルのオープン処理を行う。ＣＰＵは、入出力ライブラリ部１２内のopen関数を参照し、openシステムコールを呼び出す。

【0056】

ステップＡ２において、ＡＰ仮想ＦＳ部１３は、オープン処理するデータファイルのパス名を用いて、ファイルシステムの選択を行う。このとき、キャッシュファイルシステム用のアクセスパスが指定されていた場合に、ユーザＦＳ制御部１４を介して、ユーザ空間に実装されているＩＯキャッシュ部１５を呼び出す。

【0057】

ステップＡ３において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、キャッシュデータファイルを作成し、その際に、ＩＯ仮想ＦＳ部１６に、ローカルＦＳ部１６１を選択させる。

【0058】

ステップＡ４において、ＩＯ仮想ＦＳ部１６は、ＳＳＤ１７内にキャッシュデータを保存するための、キャッシュデータファイルを作成する。このとき、ＩＯ仮想ＦＳ部１６は、作成したファイルを一意に識別するためのファイルハンドル識別子を、ＩＯキャッシュ部１５を介して、ＡＰ仮想ＦＳ部１３に返す。

【0059】

以上で、ＩＯリクエスト処理を終了する。

【0060】

（２．共有ファイルへの書き込み処理）
共有ファイルへの書き込み処理について、図７のフローチャートを参照して説明する。

【0061】

ステップＢ１において、アプリケーション部１１に格納されるアプリケーションプログラムの記述に従い、ＣＰＵは、入出力ライブラリ部１２内のwrite関数を参照し、writeシステムコールを呼び出す。

【0062】

ステップＢ２において、ＡＰ仮想ＦＳ部１３は、上記のオープン処理で取得したファイルハンドル識別子を基に、ファイルシステムを選択する。

【0063】

ステップＢ３において、ＡＰ仮想ＦＳ部１３は、ファイルハンドル識別子が、キャッシュファイルシステム用のファイルハンドルを示していた場合に、ユーザＦＳ制御部１４を介して、ユーザ領域に実装されているＩＯキャッシュ部１５を呼び出す。

【0064】

ステップＢ３において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１が備えるペアリング部１５４は、自ＩＯ端末１に、既にペアリングしている他のＩＯ端末２，３が存在するか確認する。既にペアリングしている他のＩＯ端末２，３が存在する場合、処理はステップＢ５に進められる。既にペアリングしている他のＩＯ端末２，３が存在しない場合、処理はステップＢ４に進められる。

【0065】

ステップＢ４において、ペアリング部１５４は、自ＩＯ端末１と他のＩＯ端末２，３との間で、ペアリング処理を行う。ペアリング処理の詳細は後述する。

【0066】

ステップＢ５において、ＩＯ仮想ＦＳ部１６は、キャッシュデータファイルをローカルのＳＳＤ１７へ書き込むため、ＩＯキャッシュ部１５にキャッシュデータファイル書き込みを依頼する。ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、ＩＯ仮想ＦＳ部１６を介して、ローカルＦＳ部１６１を経由し、ＳＳＤ１７に対しデータを書き込む。書き込まれるデータ形式は、図５に示すデータファイル構造の形式で実行される。尚、当該書き込みが、ＳＳＤ１７内に既存のキャッシュデータに対する更新であれば、当該キャッシュデータファイル（図５参照）のブロックの更新フラグを「MODIFIED(更新状態：データが最新に更新されている)」に変更する。

【0067】

ステップＢ６において、キャッシュデータファイルの書き込み処理と同時に、ＩＯキャッシュ部１５は、当該キャッシュデータファイルのペア識別子を参照し、当該ペア識別子に対応する他のＩＯ端末２，３（ペアリング先）に対しても同じキャッシュデータを送信し、ペアリング先のＳＤＤ１７にも書き込みを依頼する。このペアリング先での書き込み処理の詳細は後述する。

【0068】

ステップＢ７において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、自ＩＯ端末１のキャッシュ統計情報（図２参照）を更新する。

【0069】

ステップＢ８において、ＩＯキャッシュ制御部１５１は、ペアリング先の書き込み処理完了を確認する（書き込みの同期を取る）。この書き込み処理の完了は、ペアリング先から書き込み処理完了通知を受信することで確定する。尚、更新処理が多いプログラムの場合は、所定時間の経過によって確定してもよい。

【0070】

以上により、共有ファイルへの書き込み処理を終了する。

【0071】

（３．キャッシュ統計情報の送出および収集処理）
キャッシュ統計情報の送出処理について図８のフローチャートを参照して説明する。

【0072】

ステップＣ１において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、自ＩＯ端末１のキャッシュ統計情報（図２参照）を作成し、ネットワーク接続部１８を経由して、ネットワーク５へブロードキャスト送信する。

【0073】

ステップＣ２において、ＩＯキャッシュ制御部１５１は、その後所定時間待機し、所定時間の経過を確認すると（ステップＣ３）、自ＩＯ端末１のキャッシュ統計情報を再度作成し、ネットワーク接続部１８を経由して、ネットワーク５へブロードキャスト送信する。

【0074】

以上により、キャッシュ統計情報の送出処理を終了する。

【0075】

次に、キャッシュ統計情報の収集処理について図９のフローチャートを参照して説明する。

【0076】

ステップＣ４において、自ＩＯ端末１のＩＯキャッシュ部１５は、他のＩＯ端末２，３からのキャッシュ統計情報を受信まで待機状態をとる。キャッシュ統計情報を受信したら、処理はステップＣ５に進められる。キャッシュ統計情報を受信しない場合、ステップＣ４の待機状態が継続される。

【0077】

ステップＣ５において、ＩＯキャッシュ部１５は、他のＩＯ端末２，３からのキャッシュ統計情報を取得する。

【0078】

ステップＣ６において、ＩＯキャッシュ部１５は、取得したキャッシュ統計情報で、キャッシュ統計情報記憶部１５３内のキャッシュ統計情報テーブル（図３参照）を更新する。尚、キャッシュ統計情報記憶部１５３内のキャッシュ統計情報は、ペアリング先の決定処理において利用される。

【0079】

以上により、キャッシュ統計情報の収集処理を終了する。

【0080】

（４．キャッシュのペアリング処理）
送信側（以下の説明においては自ＩＯ端末１）におけるキャッシュのペアリング処理について、図１０のフローチャートを参照して説明する。

【0081】

ステップＤ１において、ペアリング処理の送信側である自ＩＯ端末１のＩＯキャッシュ部１５は、キャッシュ統計情報記憶部１５３内のキャッシュ統計情報の検索およびペアリング先の選択を行う。具体的には、ＩＯキャッシュ制御部１５１のペアリング部１５４は、データ流量制御部１５２に最適なペアリング先の選択を依頼する。依頼を受けたデータ流量制御部１５２は、キャッシュ統計情報記憶部１５３に格納される他のＩＯ端末２，３のキャッシュ統計情報（図３）を参照し、キャッシュ空き容量が多く、かつ、共有ファイルシステムのデータ流量値が少ないＩＯ端末（ここではＩＯ端末２とする）を選ぶ。

【0082】

ステップＤ２において、ペアリング部１５４は、選択したＩＯ端末２に対して、ペアリング処理リクエストを送信する。ステップＤ３において、選択したＩＯ端末２からペアリング処理リクエストの結果を受信したペアリング部１５４は、当該結果がペアリング受け入れ許可か、又は、受け入れ不許可化を判断する（ステップＤ４）。当該結果がペアリング受け入れ許可であれば、処理はステップＤ５に進められる。当該結果がペアリング受け入れ不許可であれば、処理はステップＤ１に戻され、別のペアリング候補のＩＯ端末が再選択される。

【0083】

ステップＤ５において、ペアリング部１５４は、ペアリングが成立したとして、ペアリング先のＩＯ端末２の識別子（ＩＰアドレス）を一時記憶する。図５に示すキャッシュデータファイルのペア識別子として格納してもよい。ペアリング成立後は、キャッシュデータ送受信時にデータ送信元を精査する必要がなくなる。

【0084】

以上により、送信側におけるキャッシュのペアリング処理を終了する。

【0085】

次に、受信側（以下の説明においては他ＩＯ端末２）におけるキャッシュのペアリング処理について、図１１のフローチャートを参照して説明する。

【0086】

ステップＤ６において、ペアリング処理の受信側であるＩＯ端末２は、ペアリング要求の受信待機状態において、ペアリング要求を受信したか否かを判断する。ペアリング要求を受信すると、処理はステップＤ７に進められる。ペアリング要求を受信しない場合、ステップＤ６において待機状態を続ける。

【0087】

ステップＤ７において、ＩＯキャッシュ制御部１５１のペアリング部１５４は、キャッシュ統計情報記憶部１５３を参照し、自身（即ちＩＯ端末２）のキャッシュ統計情報を基に、他にペアリングしているＩＯ端末がないか、キャッシュ空き容量は十分にあるか等を調査する。

【0088】

ステップＤ８において、調査の結果を基に、ペアリング部１５４は、ペアリングの受け入れ許可ができるか否かを判断する。ペアリングの受け入れ許可ができる場合は、処理はステップＤ１０に進められる。ペアリングの受け入れ許可ができない場合は、処理はステップＤ９に進められる。

【0089】

ステップＤ９において、ペアリング部１５４は、ペアリング要求元のＩＯ端末１に対し、ペアリング受け入れ不許可通知を送信する。

【0090】

ステップＤ１０において、ペアリング部１５４は、ペアリング要求元のＩＯ端末１に対し、ペアリング受け入れ許可通知を送信する。

【0091】

ステップＤ１１において、ペアリング部１５４は、ペアリング用のキャッシュファイルをオープン（open）にする。このオープン処理は、ＩＯリクエスト処理（図６参照）におけるステップＡ３のキャッシュデータファイルの作成処理から実行される。更に、ペアリング部１５４はペアリング元であるＩＯ端末１のＩＰアドレスと、キャッシュデータファイルをオープン（open）にした時刻（参照時刻）とを一時記憶する。図５に示すキャッシュデータファイルのペア識別子として格納してもよい。

【0092】

以上により、受信側におけるキャッシュのペアリング処理を終了する。

【0093】

（５．ペアリング先への書き込み処理）
次に、ペアリング先への書き込み処理について、図１２のフローチャートを参照して説明する。

【0094】

ステップＤ２１において、ＩＯ端末１のペアリング先であるＩＯ端末２は、キャッシュデータの待機状態をとる。キャッシュデータを受信すると、処理はステップＤ２２に進められる。キャッシュデータを受信しない間は、Ｄ２１の待機状態が継続される。

【0095】

ステップＤ２２において、ＩＯキャッシュ制御部１５１は、当該キャッシュデータの送信元がペアリングを許可したＩＯ端末１か否かを判断する。具体的には、ＩＯキャッシュ制御部１５１は、送信元ＩＰアドレスとペアリング部１５４において一時記憶されるＩＰアドレスとを比較し、これらが一致するか否かで判断する。送信元がペアリングを許可したＩＯ端末であると判断された場合、処理はステップＤ２４に進められる。送信元がペアリングを許可したＩＯ端末ではないと判断された場合、処理はＤ２３に進められる。

【0096】

ステップＤ２３において、ＩＯキャッシュ制御部１５１は、キャッシュデータの送信元に対し、ネットワーク接続部１８を経由し、書き込み不可の通知を送信する。

【0097】

ステップＤ２４において、ＩＯキャッシュ制御部１５１は、受信側ペアリング処理（図１１のステップＤ１１参照）において、ペアリングを許可したＩＯ端末１のためにオープン処理したファイルのペア識別子（図５参照）を用いて、ペアリング用のキャッシュデータファイルを検索し、検索されたキャッシュデータファイル(ＳＳＤ１７)にキャッシュデータの書き込みを行う。

【0098】

ステップＤ２５において、ＩＯキャッシュ制御部１５１は、キャッシュデータの書き込みが完了すると、キャッシュデータ送信元のＩＯ端末１に対し、ネットワーク接続部１８を経由し、書き込み完了通知を送信する。

【0099】

ステップＤ２６において、ＩＯキャッシュ制御部１５１は、更新したキャッシュブロックのメタデータを、ネットワーク接続部１８を介して、ネットワーク５上にブロードキャスト送信する。

【0100】

以上により、ペアリング先への書き込み処理を終了する。

【0101】

尚、メタデータのブロードキャスト送信は、ネットワーク５上の全てのＩＯ端末に自身（ＩＯ端末２）がペアリング先（ＩＯ端末１）のキャッシュデータを保持していることを周知するために行う。メタデータには、自ＩＯ端末２の識別子、ペアリング先ＩＯ端末１の識別子、キャッシュデータを保持している範囲（ブロック番号やブロック数等）が含まれる。

【0102】

また、メタデータを受信した他のＩＯ端末（例えばＩＯ端末３）は、自身のＳＳＤ１７内に同じキャッシュデータファイルを保持しているかチェックし、保持している場合は、キャッシュデータファイル内の該当ブロックの更新フラグを「INVALID（無効）」に変更する。これは、無用なキャッシュデータファイルを他のＩＯ端末３が保持することや、他のＩＯ端末３が誤って上位のアプリケーション等にこのデータを送信することを防止するためである。

【0103】

（６．キャッシュデータの無効化処理）
キャッシュデータは、整合性を保つため、ペアリング後は、マスタ側のＩＯ端末１およびバックアップ側のＩＯ端末２のみで保持しておく必要がある。キャッシュデータを、マスタ側およびバックアップ側以外の他のＩＯ端末（ＩＯ端末３とする）で保持している場合は、そのデータをネットワーク５上の上位のアプリケーション等に返却しないよう、無効化する必要がある。

【0104】

キャッシュデータの無効化処理について、図１３のフローチャートを参照して説明する。

【0105】

ステップＥ１において、ＩＯ端末（ＩＯ端末２とする）のＩＯキャッシュ部１５は、更新されたキャッシュブロックのメタデータを受信したか否かを判断する。メタデータを受信した場合、処理はステップＥ２に進められる。メタデータを受信しない間は、処理はステップＥ１に戻され待機状態が継続される。

【0106】

ステップＥ２において、受信したメタデータを基に、メタデータに記載されたキャッシュデータの範囲を自ＩＯ端末２に保持しているか、キャッシュ統計情報記憶部１５３内を調査する。調査の結果、メタデータに記載されたキャッシュデータの範囲を自ＩＯ端末２に保持している場合、処理はステップＥ３に進められる。自ＩＯ端末２では保持していない場合、この処理は一端終了し、再度ステップＥ１の待機状態に戻される。

【0107】

ステップＥ３において、キャッシュデータの送信元（ＩＰアドレス）がペアリング先であるマスタ側ＩＯ端末（ＩＯ端末１とする）か否かを判断する。キャッシュデータの送信元がペアリング先であれば、書き込み処理中のキャッシュデータであり、問題は発生しないと判断できるからである。この場合、処理は一旦終了され、再度ステップＥ１の待機状態に戻される。キャッシュデータの送信元がペアリング先でなければ、処理はステップＥ４に進められる。

【0108】

ステップＥ４において、ＩＯキャッシュ部１５は、キャッシュ統計情報記憶部１５３に格納される、ペアリングされていないＩＯ端末（例えばＩＯ端末３）のキャッシュデータを無効化する。具体的には、ＩＯキャッシュ部１５は、キャッシュデータファイル（図５参照）の該当キャッシュデータの更新フラグを「INVALID（無効）」に変更する。この処理は、キャッシュデータファイル内の該当するブロック全てにおいて行われる。

【0109】

以上により、キャッシュデータの無効化処理を終了する。

【0110】

（７．キャッシュのフラッシュ処理）
次に、キャッシュのフラッシュ処理について、図１４のフローチャートを参照して説明する。尚、キャッシュフラッシュ処理は、ＩＯ端末１上の独立したプロセスとして適宜（例えば、所定間隔毎）に作動する。

【0111】

ステップＦ１において、ＩＯキャッシュ部１５は、更新されたブロックの検索を行う。具体的に、ＩＯキャッシュ部１５は、キャッシュファイルデータ（図５参照）の更新フラグが「MODIFIED(更新状態：データが最新に更新されている)」となっているブロックを検索し、キャッシュフラッシュ対象ブロックとして選択する。

【0112】

ステップＦ２において、ＩＯキャッシュ部１５のデータ流量制御部１５２は、ＭＲＵ（Maximum Receive unit）アルゴリズムを用いて、キャッシュフラッシュ対象ブロックのペア識別子（図５参照）と同一のＩＰアドレスを有するキャッシュ統計情報（図３参照）のレコードから、共有ＦＳデータ流量を確認し、所定の閾値を超えるＩＯリクエストが出ているかを確認する（ステップＦ３）。所定の閾値を超えるＩＯリクエストが出ている場合、処理はステップＦ４に進められる。所定の閾値を超えるＩＯリクエストが出ていない場合、処理はステップＦ６に進められる。

【0113】

ステップＦ４において、データ流量制御部１５２は、キャッシュ空き容量が所定の閾値以下となったか否かを判断する。キャッシュ空き容量が所定の閾値以下である場合、処理はステップＦ６に進められる。キャッシュ空き容量が所定の閾値以下ではない場合、処理はＦ５に進められる。

【0114】

ステップＦ６において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、ネットワーク接続部１８を経由して、共有ＦＳサーバ４へキャッシュデータを渡す。共有ＦＳサーバ４は、当該キャッシュデータを共有ファイル部４ａに書き込む。この時、ＩＯキャッシュ制御部１５１は、ＩＯ仮想ＦＳ部１６を介して、ＳＳＤ１７内のキャッシュデータファイル（図５参照）の「更新時刻」に、書き込みされた時刻を設定し、「更新フラグ」を「SHARED(共有：共有ＦＳサーバ１７内の共有ファイル部４ａのデータと同期している)」に設定する。これは、キャッシュ（ＳＳＤ１７）と共有ファイルサーバ４とが、同じデータを保持していることを意味する。

【0115】

ステップＦ５において、閾値を超えるＩＯリクエストもなく、キャッシュ空き容量も未だ充分にある場合、または、共有ＦＳサーバへのフラッシュ処理が終了した場合、所定時間の待機後、処理はステップＦ２のデータ残量確認処理に戻される。

【0116】

以上により、キャッシュのフラッシュ処理を終了する。

【0117】

（８．キャッシュのペアリング解除処理）
次に、キャッシュのペアリング解除を要求する送信側ＩＯ端末（以下の説明においてはＩＯ端末２として説明する）における処理について、図１５のフローチャートを参照して説明する。

【0118】

まずステップＧ１において、自ＩＯ端末２のＩＯキャッシュ部１５は、待機状態を一定時間取る。この待機状態は、あるアプリケーションプログラムの動作中に、ボトルネックとなっていたＩＯ処理の混雑が、ペアリング処理により緩和された、又は、アプリケーションプログラムが終了したと判断可能な時間であり、例えば数秒〜数時間等である。一定時間の待機状態が終了すると処理はステップＧ２に進められる。

【0119】

ステップＧ２において、ＩＯキャッシュ部１５は、現在オープン（open）しているキャッシュデータファイルの参照時刻をペアリング部１５４から取得する（図１１におけるステップＤ１１参照）。

【0120】

ステップＧ３において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、取得した参照時刻と、システムから取得した現在時刻とを比較して、予め設定された規定時間を経過したかを判断する。規定時間を経過した場合処理はステップＧ４に進められる。規定時間を経過しない場合処理はＧ１に戻される。

【0121】

ステップＧ４において、ＩＯキャッシュ制御部１５１のペアリング部１５４は、ペアリング解除要求を、ペアリング先のＩＯ端末１に送信する。

【0122】

ステップＧ５において、ペアリング部１５４は、ペアリング先のＩＯ端末１からペアリング解除完了の通知を待つ。

【0123】

ステップＧ６において、ペアリング部１５４は、ペアリング解除完了の通知を受信後、このキャッシュデータファイルのclose処理を行う。

【0124】

以上により、キャッシュのペアリング解除要求の送信側ＩＯ端末２における処理を終了する。

【0125】

次に、キャッシュのペアリング解除の受信側ＩＯ端末（以下、ＩＯ端末１として説明する）における処理について、図１６のフローチャートを参照して説明する。

【0126】

ステップＧ７において、ペアリング解除処理の受信側ＩＯ端末１は、ペアリング解除要求の受信待ち状態となる。この状態において、ペアリング解除要求を受信すると処理はステップＧ８に進められる。ペアリング解除要求を受信するまではステップＧ７の受信待ち状態を継続させる。

【0127】

ステップＧ８において、ペアリング解除要求を受信すると、ペアリング解除処理の受信側ＩＯ端末１は、現在オープンしているキャッシュデータファイルのクローズ（close）処理を行う。

【0128】

ステップＧ９において、クローズ処理が完了すると、ペアリング部１５４は、ペアリング解除完了の通知を、解除要求の送信側ＩＯ端末２に返信する。

【0129】

以上により、キャッシュのペアリング解除の受信側ＩＯ端末１における処理を終了する。

【0130】

（９．ファイルの読み込み処理）
次に、ファイルの読み込み処理について、図１７のフローチャートを参照して説明する。

【0131】

ステップＨ１において、アプリケーション部１１（図１参照）内のアプリケーションプログラムの記載に基づき、ＣＰＵは、入出力ライブラリ部１２により提供されるread関数内でreadシステムコールを呼び出す。

【0132】

ステップＨ２において、ＡＰ仮想ＦＳ部１３は、オープン処理で取得したファイルハンドル識別子（図６のステップＡ４参照）を基に、ファイルシステムの選択を行う。このとき、ファイルハンドル識別子が、キャッシュＦＳ用のファイルハンドルを示していた場合に、ＡＰ仮想ＦＳ部１３は、ユーザＦＳ制御部１４を経由して、ユーザ領域上に実装されているＩＯキャッシュ部１５を呼び出す。

【0133】

ステップＨ３において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、ローカルＦＳ部１６１上にあるキャッシュファイルを検索して、キャッシュファイル内の各ブロックの更新フラグをチェックする。このときに、更新フラグが「MODIFIED(更新状態：データが最新に更新されている)」または「SHARED(共有：共有ＦＳサーバ１７内の共有ファイル部４ａのデータと同期している)」となっていれば、そのままキャッシュデータを上位のアプリケーション等に返却する（ステップＨ７）。もし更新フラグが「NO FILE（キャッシュファイルが存在しない）」、または、「INVALID（無効）」となっている場合は、処理はステップＨ４に進められる。

【0134】

ステップＨ４において、ＩＯキャッシュ部１５は、有効なデータを得るために、他の全てのＩＯ端末２，３に対し強制フラッシュ要求を出す。まず、ＩＯキャッシュ部１５は、更新フラグが「NO FILE」または「INVALID（無効）」となっているブロックのメタデータを、ネットワーク接続部１８を経由して、ブロードキャスト送信する。このメタデータには、キャッシュファイル名、ブロック番号、ブロック数等が含まれる。他の全てのＩＯ端末２，３は、このフラッシュ要求を受信すると、自ＩＯ端末２，３において強制フラッシュ処理を行う。この処理の詳細は後述する。

【0135】

ステップＨ５において、強制フラッシュ処理が終了し、所望のデータが共有ＦＳサーバ４に更新されると、ＩＯキャッシュ部１５は、強制フラッシュされた所望のデータを、ネットワーク接続部１８を介して、共有ＦＳサーバ４から読み込み、取得する。

【0136】

ステップＨ６において、ＩＯ仮想ＦＳ部１６は、取得したデータをキャッシュデータとしてＳＳＤ１７に書き込む。

【0137】

次にステップＨ４の強制フラッシュ処理について、図１８のフローチャートを参照して説明する。

【0138】

ステップＨ８において、ＩＯ端末２，３のＩＯキャッシュ部１５は、フラッシュ要求を受信する。このフラッシュ要求はメタデータ、又はメタデータを含むデータである。

【0139】

ステップＨ９において、ＩＯキャッシュ部１５のＩＯキャッシュ制御部１５１は、メタデータに含まれるキャッシュファイル名、ブロックおよびその範囲に該当するデータが、自身のキャッシュ（ＳＳＤ１７）に存在するか確認する。存在する場合は、処理はステップＨ１０へ進められる。存在しない場合は、処理はステップＨ８へ戻される。

【0140】

ステップＨ１０において、ＩＯキャッシュ制御部１５１は、ネットワーク接続部１８を経由し、フラッシュ要求されているキャッシュデータを共有ＦＳサーバ４に送信する。共有ＦＳサーバ４は、フラッシュ要求されているキャッシュデータを共有ファイル部４ａに書き込む。この際、キャッシュデータファイル内の更新時刻が設定される。

【0141】

ステップＨ１１において、ＩＯキャッシュ制御部１５１は、キャッシュファイルデータ（図５）内の該当するブロックの更新フラグに「SHARED」を設定する。

【0142】

以上により、強制フラッシュ処理を完了する。

【0143】

（１０．ファイルのクローズ処理）
次に、アプリケーション部１１（図１参照）による、ＩＯリクエストを終了するためのファイルのクローズ処理について、図１９のフローチャートを参照して説明する。

【0144】

ステップＩ１において、アプリケーション部１１に格納されるアプリケーションプログラムに従い、ＣＰＵ（不図示）は、入出力ライブラリ部１２により提供されるclose関数内でcloseシステムコールを呼び出す。

【0145】

ステップＩ２において、ＡＰ仮想ＦＳ部１３は、クローズ処理するファイルのファイルハンドル値を受け取り、ファイルシステムの選択を行う。

【0146】

ステップＩ３において、キャッシュＦＳ用のファイルハンドルを受け取った場合、ＡＰ仮想ＦＳ部１３は、ユーザＦＳ制御部１４を経由して、ユーザ領域上に実装されているＩＯキャッシュ部１５を呼び出す。ＩＯキャッシュ部１５は、キャッシュデータファイルをクローズする。

【0147】

ステップＩ４において、ＩＯ仮想ＦＳ部１６は、ローカルＦＳ部１６１を選択し、ローカルＦＳ部１６１は、ＳＳＤ１７上に作成されたキャッシュデータファイルを削除する。

【0148】

以上により、ＩＯリクエストを終了するためのファイルのクローズ処理を終了する。

【0149】

（効果）
本発明の第１の実施形態によると、共有ストレージシステムにおいて、適切なペアリング処理を自動で行い、キャッシュ書き込み時の信頼性が高い、共有ファイルシステムを使用するためのＩＯ端末１〜３等を提供することができる。

【0150】

これは、自身のキャッシュデータのコピーを一時格納させるためのペアリング先のＩＯ端末を、当該ＩＯ端末のキャッシュ使用量や共有ＦＳサーバ４へのアクセス量を考慮した上で、ファイル単位ブロック毎に選択するからである。これにより、書き込み時の信頼性を高くすることができる。更に、共有ファイルシステムの本来のＩＯリクエストは阻害せずにすむ。

【0151】

＜第２の実施形態＞
本発明の第２の実施形態に係る共有ファイルシステムを使用する為のＩＯ端末（情報処理端末）１０を図２０に示す。ＩＯ端末１０は、キャッシュメモリ領域のファイル単位毎にキャッシュデータをペアリングする端末を検出し、当該キャッシュデータを、ペアリングする端末のキャッシュメモリ領域に書き込むよう指示する。

【0152】

本発明の第２の実施形態によると、共有ストレージシステムにおいて、適切なペアリング処理を自動で行い、キャッシュ書き込み時の信頼性が高いＩＯ端末１０を提供することができる。

【0153】

これは、自身のキャッシュデータのコピーを一時格納させるためのペアリング先のＩＯ端末を、当該ＩＯ端末のキャッシュ使用量や共有ファイルシステムサーバへのアクセス量を考慮した上で、ファイル単位ブロック毎に選択するからである。

【0154】

＜変更例＞
上記の実施形態においてはユーザファイルシステム制御部１４として、ＦＵＳＥを用い、ユーザ領域による実装によるファイルシステムを構成しているが、カーネルモジュールを用いた実装や、カーネル内における実装によっても、同機能は実現可能である。

【0155】

キャッシュの整合性を保つために、キャッシュ制御については、ＭＳＩ（Modified/Shared/Invalid）プロトコルを使用することが簡素化のために望ましいが、その他のキャッシュ制御アルゴリズムを適応してもよい。

【0156】

上記の実施形態においては、キャッシュのコピーを持たせるＩＯ端末を１つのみ選択しているが、冗長性を高めるため、２以上のＩＯ端末を選択してもよい。

【0157】

（ハードウェア構成）
本発明の各実施形態において、ＩＯ端末１〜３における各構成要素は、機能単位のブロックを示している。ＩＯ端末１〜３における各構成要素の一部又は全部は、例えば図１、２０に示すような情報処理装置とプログラムとの任意の組み合わせにより実現される。これを実現する情報処理装置５００の一例を図２１に示す。情報処理装置５００は、一例として、以下のような構成を含む。

【0158】

・ＣＰＵ５０１
・ＲＯＭ５０２
・ＲＡＭ５０３
・ＲＡＭ５０３にロードされるプログラム５０４
・プログラム５０４を格納する記憶装置５０５
・記録媒体５０６の読み書きを行うドライブ装置５０７
・通信ネットワーク５０９と接続する通信インターフェース５０８
・データの入出力を行う入出力インターフェース５１０
・各構成要素を接続するバス５１１
各実施形態におけるＩＯ端末１〜３の各構成要素は、これらの機能を実現するプログラム５０４をＣＰＵ５０１が取得して実行することで実現される。各装置の各構成要素の機能を実現するプログラム５０４は、例えば、予め記憶装置５０５やＲＡＭ５０３に格納されており、必要に応じてＣＰＵ５０１が読み出す。なお、プログラム５０４は、通信ネットワーク５０９を介してＣＰＵ５０１に供給されてもよいし、予め記録媒体５０６に格納されており、ドライブ装置５０７が当該プログラムを読み出してＣＰＵ５０１に供給してもよい。

【0159】

ＩＯ端末の実現方法には、様々な変形例がある。例えば、ＩＯ端末は、構成要素毎にそれぞれ別個の情報処理装置５００とプログラムとの任意の組み合わせにより実現されてもよい。また、ＩＯ端末が備える複数の構成要素が、一つの情報処理装置５００とプログラムとの任意の組み合わせにより実現されてもよい。

【0160】

また、ＩＯ端末の各構成要素の一部又は全部は、その他の汎用または専用の回路、プロセッサ等やこれらの組み合わせによって実現される。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。

【0161】

ＩＯ端末の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。

【0162】

ＩＯ端末の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

【0163】

上述した各実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、趣旨を逸脱しない範囲で、種々の変更が可能であることは勿論である。

【符号の説明】

【0164】

１ ：ＩＯ端末
２ ：ＩＯ端末
３ ：ＩＯ端末
１０ ：ＩＯ端末
４ ：共有ＦＳサーバ
４ａ ：共有ファイル部
５ ：ネットワーク
１１ ：アプリケーション部
１２ ：入出力ライブラリ部
１３ ：ＡＰ仮想ＦＳ部
１４ ：ユーザＦＳ制御部
１５ ：ＩＯキャッシュ部
１６ ：ＩＯ仮想ＦＳ部
１７ ：共有ＦＳサーバ
１８ ：ネットワーク接続部
２５ ：ＩＯキャッシュ部
３５ ：ＩＯキャッシュ部
１００ ：共有ファイルシステム
１５１ ：ＩＯキャッシュ制御部
１５２ ：データ流量制御部
１５３ ：キャッシュ統計情報記憶部
１５４ ：ペアリング部
１６１ ：ローカルＦＳ部
１６２ ：共有ＦＳクライアント制御部
５００ ：情報処理装置
５０１ ：ＣＰＵ
５０２ ：ＲＯＭ
５０３ ：ＲＡＭ
５０４ ：プログラム
５０５ ：記憶装置
５０６ ：記録媒体
５０７ ：ドライブ装置
５０８ ：通信インターフェース
５０９ ：通信ネットワーク
５１０ ：入出力インターフェース
５１１ ：バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】