JPWO2017126097A1 - 計算機システム、計算機 - Google Patents

Abstract

ストレージプログラムをＯＳ上で動作させつつ、Ｉ／Ｏ性能を維持することを可能にする計算機システムを提供する。計算機システムは、ＯＳ上で動作し、ホストに論理ボリュームを提供するストレージプログラムを実行する。また、計算機システムは、ストレージプログラムが提供する論理ボリュームに適用されるストレージ機能の情報を含むボリューム管理情報、を有する。ＯＳは、ホストから論理ボリュームに対するＩ／Ｏ要求を受信した場合、ボリューム管理情報を参照して、論理ボリュームに適用されるストレージ機能の情報に基づいて、ストレージプログラムによるＩ／Ｏ処理が必要か否かを判定する。必要と判定した場合、ストレージプログラムと通信し、ストレージプログラムによるＩ／Ｏ処理を実行する。また、ＯＳは、ストレージプログラムによるＩ／Ｏ処理が必要でないと判定した場合、ホストへＩ／Ｏ応答する。

Description

本発明は、計算機システム、計算機に関する。

本技術分野の背景技術を開示する文献として特許第４４８０４７９号公報（特許文献１）がある。この公報には、ストレージシステム（ファイルシステム）をオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＯＳ）の一部として動作させる技術が記載されている。

特許第４４８０４７９号公報

ストレージプログラムの可搬性を向上させ開発効率を高めるため、ストレージプログラムを、ＯＳ内部のプログラムではなく、ＯＳ上で動作するプログラムとして実装したいという新たな要求がある。この場合においても、大量かつ多様なストレージ処理を高速かつ高信頼に実行することが求められる。

しかしながら、ストレージプログラムをＯＳ上で動作させた場合、例えばＯＳとストレージプログラムとの間の通信量が増大して、Ｉ／Ｏ帯域が不足すると、Ｉ／Ｏ性能が低下する可能性がある。この点に関し、特許文献１は、ストレージプログラムをＯＳ上で動作させることを想定しておらず、Ｉ／Ｏ性能の低下を抑える技術については言及していない。

そこで、ストレージプログラムをＯＳ上で動作させつつ、Ｉ／Ｏ性能を維持する技術を提供する。

上記課題を解決するために、本発明の一態様である計算機システムは、オペレーティングシステムと、オペレーティングシステム上で動作しホストに論理ボリュームを提供するストレージプログラムと、を実行するプロセッサを備える。また、計算機システムは、オペレーティングシステムとストレージプログラムとの通信データを保持するキューと、ストレージプログラムが提供する論理ボリュームに適用されるストレージ機能の情報を含むボリューム管理情報と、を有するメモリをさらに備える。オペレーティングシステムは、ホストから論理ボリュームに対するＩ／Ｏ要求を受信した場合、ボリューム管理情報を参照して、Ｉ／Ｏ要求の対象となる論理ボリュームに適用されるストレージ機能の情報に基づいて、ストレージプログラムによるＩ／Ｏ要求の処理が必要か否かを判定し、必要と判定した場合、キューを介してストレージプログラムと通信する。そして、ストレージプログラムは、Ｉ／Ｏ要求に基づく処理を実行する。また、オペレーティングシステムは、ストレージプログラムによるＩ／Ｏ要求の処理が必要でないと判定した場合、ホストへＩ／Ｏ要求に対する応答を実行する。

本発明によれば、ストレージプログラムをＯＳ上で動作させつつ、Ｉ／Ｏ性能を維持することを可能にする技術を提供できる。上記した以外の課題、構成および効果は、以下の発明を実施するための形態の説明により明らかにされる。

Ｉ／Ｏ処理の概要を示す模式図である。 Ｉ／Ｏ処理の概要を示すフローチャートである。 計算機システム１０の構成例を示す図である。 サーバ２００のメモリ３２０の構成例を示す図である。 計算機システム１０の他の構成例を示す図である。 Ｉｎｉｔｉａｔｏｒ−Ｔａｒｇｅｔキュー４１０の構成例を示す図である。 Ｔａｒｇｅｔ−Ｉｎｉｔｉａｔｏｒキュー４２０の構成例を示す図である。 ボリューム管理表１０００の構成例を示す図である。 キャッシュ管理表９００の構成例を示す図である。 プロセス管理表１３００の構成例を示す図である。 資源管理表１４００の構成例を示す図である。 キューペア管理表１５００の構成例を示す図である。 ポリシ管理表１６００の構成例を示す図である。 通信ドライバプログラム５００のフローチャートである。 ストレージプログラム７００のフローチャートである。 キャッシュ操作処理のフローチャートである。 複数のキューペアが存在するサーバ２００の構成例を示す図である。 キューペア監視プログラム１７００のフローチャートである。 キューペア増加処理のフローチャートである。 キューペア削減処理のフローチャートである。 システム設定を管理するＧＵＩの一例を示す図である。

以下、図面を参照して本発明の実施形態を説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。本発明が本実施形態に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。特に限定しない限り、各構成要素は複数でも単数でも構わない。

以下の説明では、例えば、「ｘｘｘ表」の表現にて各種情報を説明することがあるが、各種情報は表以外のデータ構造で表現されていてもよい。各種情報がデータ構造に依存しないことを示すために、「ｘｘｘ表」を「ｘｘｘ情報」と呼ぶことがある。

管理システムは、一又は複数の計算機で構成することができる。例えば、管理計算機が情報を処理及び表示する場合、管理計算機が管理システムである。例えば、複数の計算機で管理計算機と同等の機能が実現されている場合、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んでよい）が、管理システムである。本実施形態では、管理端末２４０が管理システムである。

以下の説明では、「プログラム」あるいはそのプロセスを主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えば、メモリ）及び／又は通信インタフェース装置（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサであってもよい。プロセッサは、プログラムに従って動作することによって、所定の機能を実現する機能部として動作する。プロセッサを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。

プログラム、プロセス、又はプロセッサを主語として説明された処理は、計算機（例えば、サーバ、ストレージシステム、管理計算機、クライアント又はホスト）を主語として説明することもできる。プロセッサは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。コンピュータプログラムは、プログラムソースから各計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ（例えば、管理計算機）又は記憶メディアでよい。

図１は、Ｉ／Ｏ処理の概要を示す模式図である。計算機システム１０は、サーバ２００とホスト２１０とを有する。サーバ２００は、共有メモリ４００とディスク装置３６０を有する。サーバ２００では、ＯＳ６００が動作し、またＯＳ６００上でストレージプログラム７００が動作する。ＯＳ６００は、Ｉ／Ｏ要求受信プログラム６２０と、Ｉ／Ｏ応答送信プログラム６４０と、通信ドライバプログラム５００と、を有する。

ストレージプログラム７００は、複数のディスク装置３６０の物理的な記憶領域から、１または２以上の仮想的なディスク装置を構成し、ホスト２１０に提供する。以後の説明では、この仮想的なディスク装置を論理ボリューム３４０と呼ぶ。論理ボリューム３４０の構成方法には、例えば、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）があり、複数のディスク装置３６０を用いることで、データ冗長化による信頼性向上や、ディスク装置３６０の並列動作による性能向上が期待できる。

共有メモリ４００は、Ｉｎｉｔｉａｔｏｒ−Ｔａｒｇｅｔキュー（ＩＴＱ）４１０とＴａｒｇｅｔ−Ｉｎｉｔｉａｔｏｒキュー（ＴＩＱ）４２０のペア（以下「キューペア」ともいう）、またキャッシュ８００を有する。

ＩＴＱ４１０は、Ｉ／Ｏ要求受信プログラム６２０からストレージプログラム７００への通信データを保持する。ＴＩＱ４２０は、ストレージプログラム７００からＩ／Ｏ応答送信プログラム６４０への通信データを保持する。同じキューペアであるＩＴＱ４１０とＴＩＱ４２０は、実際の処理において対として用いられる。キューペアが複数存在する場合、通信時、ストレージプログラム７００は一連の通信にはペアになっているＴＩＱ４２０とＩＴＱ４１０を使う必要がある。また、１つのキューペアを１つのストレージプログラム７００が独占して処理してもよいし、複数のストレージプログラム７００が１つのキューペアを共有して処理してもよい。

図１の破線は制御情報の流れを示している。以下の説明において、制御情報は、Ｉ／Ｏ要求またはＩ／Ｏ応答である。また、図２は、Ｉ／Ｏ処理の概要を示すフローチャートである。図１及び図２を用いて、サーバ２００がホスト２１０から論理ボリューム３４０に対するＩ／Ｏ要求を受信した場合におけるＩ／Ｏ処理の概要を、以下説明する。

ホスト２１０は、サーバ２００へ論理ボリューム３４０に対するＩ／Ｏ要求を送信する。サーバ２００がホスト２１０からＩ／Ｏ要求を受信する際、サーバ２００が有するＨＢＡ３３１またはＮＩＣ３３２が、Ｉ／Ｏ割り込み要求を発行する。ＣＰＵコア３１１は、Ｉ／Ｏ割り込み要求を受け取り、図２に示すＩ／Ｏ処理を開始する（Ｓ３０００）。

Ｉ／Ｏ割り込み要求を受け取ったＣＰＵコア３１１は、Ｉ／Ｏ要求受信プログラム６２０を呼び出す（Ｓ３０１０）。ＣＰＵコア３１１は、Ｉ／Ｏ要求受信プログラム６２０を実行して、Ｉ／Ｏ要求を受信する。ＣＰＵコア３１１は、受信したＩ／Ｏ要求をメモリ３２０に記録し、通信ドライバプログラム５００へＩ／Ｏ要求の到着の通知を発行する。その後、ＣＰＵコア３１１は、Ｉ／Ｏ要求受信プログラム６２０の処理を終了する。図１の破線Ｃ１は、このＳ３０１０及びＳ３０２０を実行するときの制御情報（ここではＩ／Ｏ要求）の流れを示している。

次に、ＣＰＵコア３１１は、通信ドライバプログラム５００を呼び出し（Ｓ３０２０）、通信ドライバプログラム５００を実行して、ストレージプログラム７００による処理の要否を決定する（Ｓ３０３０）。

ここで、ＣＰＵコア３１１は、Ｓ３０３０においてＹＥＳの場合、すなわちストレージプログラム７００の処理が必要と判断した場合、Ｉ／Ｏ要求をＩＴＱ４１０にエンキューする。図１の破線Ｃ２は、Ｓ３０３０がＹｅｓの場合における制御情報（ここではＩ／Ｏ要求）の流れを示している。

ＩＴＱ４１０にエンキューされたＩ／Ｏ要求は、ＯＳ６００上で動作するストレージプログラム７００によって処理される（Ｓ３０４０）。ストレージプログラム７００は、Ｉ／Ｏ応答をＴＩＱ４２０にエンキューし、通信ドライバプログラム５００をシステムコールする。図１の破線Ｃ３は、Ｓ３０４０を実行するときの制御情報（ここではＩ／Ｏ要求またはＩ／Ｏ応答）の流れを示している。

ＣＰＵコア３１１は、システムコールにより呼び出された通信ドライバプログラム５００を実行し、ストレージプログラム７００によるＩ／Ｏ応答をＴＩＱ４２０からデキューし、Ｉ／Ｏ応答送信プログラム６４０に通知する（Ｓ３０５０）。図１の破線Ｃ４は、Ｓ３０５０を実行するときの制御情報（ここではＩ／Ｏ応答）の流れを示している。

一方、ＣＰＵコア３１１は、Ｓ３０３０においてＮｏの場合、すなわちストレージプログラム７００の処理が不要と判断した場合、Ｉ／Ｏ要求をＩＴＱ４１０にエンキューしないことで、ストレージプログラム７００にＩ／Ｏ要求を通知しない。この場合、ＣＰＵコア３１１は、通信ドライバプログラム５００を実行して、Ｉ／Ｏ応答を行う。例えば、Ｉ／Ｏ要求がリード要求であれば、Ｉ／Ｏ応答送信プログラム６４０を呼び出し、リード対象のデータが存在するキャッシュ８００のアドレス及びサイズを通知する（Ｓ３０５０）。図１の破線Ｃ６は、このＳ３０３０がＮｏの場合における制御情報（ここではＩ／Ｏ要求またはＩ／Ｏ応答）の流れを示している。

次にＣＰＵコア３１１は、Ｉ／Ｏ応答送信プログラム６４０を実行し、ホスト２１０にＩ／Ｏ応答を行う（Ｓ３０６０）。呼び出されたＩ／Ｏ応答送信プログラム６４０は、Ｉ／Ｏ要求に対する応答として、Ｉ／Ｏ完了通知をホスト２１０に送信する。

例えば、Ｉ／Ｏ要求がリード要求であれば、ＣＰＵコア３１１は、ＨＢＡ３３１もしくはＮＩＣ３３２に対し、ホスト２１０へリードデータの転送を指示する。この指示には、Ｓ３０５０のＩ／Ｏ応答で通知されたリード対象のデータが存在するキャッシュ８００のアドレス及びサイズが含まれる。ＨＢＡ３３１もしくはＮＩＣ３３２は、このキャッシュ８００のアドレス及びサイズを参照し、キャッシュ８００の該当領域からリードデータを読み出して、ホスト２１０へリードデータを転送する。そして、ＣＰＵコア３１１は、ＨＢＡ３３１もしくはＮＩＣ３３２に対し、ホスト２１０へＩ／Ｏ処理（リード処理）の完了通知を送信することを指示する（Ｓ３１７０）。

また、例えば、Ｉ／Ｏ要求がライト要求であれば、ＣＰＵコア３１１は、ＨＢＡ３３１もしくはＮＩＣ３３２に対し、ホスト２１０へＩ／Ｏ処理（ライト処理）の完了通知を送信することを指示する。

ホスト２１０へＩ／Ｏ処理の完了通知が送信されて、図２に示すＩ／Ｏ処理が完了する（Ｓ３０７０）。図１の破線Ｃ５は、Ｓ３０６０を実行するときの制御情報（ここではＩ／Ｏ応答）の流れを示している。

したがって、図２のＩ／Ｏ処理のフローチャートにおいて、Ｓ３０３０がＹｅｓの場合、すなわちストレージプログラム７００の処理が必要と判断された場合、図１の破線Ｃ１、Ｃ２、Ｃ３、Ｃ４、Ｃ５で示される制御情報の流れとなる。一方、Ｓ３０３０においてＮｏの場合、すなわちストレージプログラム７００の処理が不要と判断された場合、図１の破線Ｃ１、Ｃ６、Ｃ５で示される制御情報の流れとなる。

ここで、ストレージプログラム７００は、ＯＳ６００内部のプログラムではなく、ＯＳ６００上で動作している。そのため、ストレージプログラム７００がホスト２１０に提供する論理ボリューム３４０へのＩ／Ｏ要求の全てを、例えばストレージプログラム７００で処理させると、ＯＳ６００とストレージプログラム７００との間の通信量が増大する。これにより、Ｉ／Ｏ帯域の不足や、ＣＰＵコア３１１で実行させる処理の増加により、Ｉ／Ｏ性能が低下する可能性がある。

そこで、本実施形態においては、通信ドライバプログラム５００が、ストレージプログラム７００による処理の要否を決定して（Ｓ３０３０）、ストレージプログラム７００での処理が不要な場合は、Ｉ／Ｏ要求の対象である論理ボリューム３４０を提供するストレージプログラム７００であるにもかかわらず、ストレージプログラム７００で当該Ｉ／Ｏ要求を処理しない。このように、ストレージプログラム７００によるストレージ機能を使用しなくてもＩ／Ｏ応答が可能な場合には、通信ドライバプログラム５００でＩ／Ｏ応答することで、ストレージプログラム７００をＯＳ６００上で動作させつつ、Ｉ／Ｏ性能の低下を抑え、Ｉ／Ｏ性能を維持または向上することを可能にする。例えば、ＯＳ６００は、ホスト２１０から論理ボリューム３４０に対するライト要求を受信した場合、キューペアを介してストレージプログラム７００と通信する。そして、ストレージプログラム７００では、ライト要求に基づく処理を実行する。一方、ＯＳ６００は、ホスト２１０から論理ボリューム３４０に対するリード要求を受信した場合、キャッシュ管理表９００を参照して、キャッシュ８００上にリード要求に対応するデータが存在すると判定したとき、キャッシュ８００上に存在するデータに基づき、ホスト２１０へリード要求に対する応答を実行する。

また、図１には、１つのＯＳ６００（ＯＳカーネル６１０）にＩ／Ｏ要求受信プログラム６２０のプロセスおよびＩ／Ｏ応答送信プログラム６４０のプロセスが１つずつ配置された例が示されているが、この構成に限定されることは無く、１つのＯＳ６００（ＯＳカーネル６１０）内にＩ／Ｏ要求受信プログラム６２０のプロセスおよびＩ／Ｏ応答送信プログラム６４０のプロセスを複数配置することも可能である。

図３は、計算機システム１０の構成例を示す図である。計算機システム１０は、サーバ２００と、ホスト２１０と、管理端末２４０とを有する。サーバ２００とホスト２１０と管理端末２４０は、ネットワーク２２０で互いに接続される。

サーバ２００は、複数のデータ通信プロトコルを処理可能な計算機である。例えば、サーバ２００は、ＦＣＰ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ Ｐｒｏｔｏｃｏｌ）、ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などのデータ通信プロトコルを使い、ホスト２１０や管理端末２４０とデータ通信を行う。

サーバ２００は、例えば、ホスト２１０からのＩ／Ｏ要求を、ネットワーク２２０を介して受け取り、そのＩ／Ｏ処理を実行した後、処理結果（Ｉ／Ｏ応答）をホスト２１０へ返す。サーバ２００は、データセンタなどの施設に固定設置される形態でもよいし、コンテナ型など移動可能であり、必要に応じて地理的な位置を変更してもよい。また、サーバ２００が１つの計算機ではなく複数の計算機で構成されていてもよい。

管理端末２４０は、サーバ２００のソフトウェアおよび各種設定などを管理する管理計算機である。管理端末２４０は管理プログラムを格納しており、管理プログラムを実行することによりサーバ２００の管理に関する各種処理を行う。

ネットワーク２２０は、通信ネットワークであれば、その形態は問わない。ネットワーク２２０は、例えば、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＳＡＮ(Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ)、無線ＬＡＮ、携帯電話通信網などである。また、ネットワーク２２０は、単一の通信ネットワークではなく、複数種類の通信ネットワークから構成されてもよい。

ホスト２１０は、データセンタなどの施設に固定設置されてもよいし、コンテナ型など移動可能とし地理的な位置を変化させてもよい。ホスト２１０としては例えばスマートフォンを含む携帯電話や汎用計算機などが想定される。また、ホスト２１０は単一の装置ではなく、複数の異なる計算機から構成されていてもよい。

また、本実施形態では、計算機の一例としてサーバ２００を例示しているが、本発明はこれに限定されることはない。他の例として、ストレージシステムを用いてもよい。本実施形態において、サーバ２００は、計算機、ストレージシステム、またはストレージ装置としてもよい。

サーバ２００は、メモリ３２０、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｏｒ）３３１、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）３３２、ディスク装置３６０、及びそれらに接続された制御演算ユニットであるＣＰＵ３１０を有する。

メモリ３２０に代えて、または加えて別種の記憶資源が採用されてもよい。ＨＢＡ３３１及びＮＩＣ３３２に変えて、別種の通信インタフェースデバイスが採用されてもよい。

ＣＰＵ３１０は、メモリ３２０に格納されているコンピュータプログラムを実行する。ＣＰＵ３１０は、複数の演算ユニットであるＣＰＵコア３１１を有し、各コアは独立して動作することができ、並列にコンピュータプログラムを実行する。

ＣＰＵコア３１１は、ストレージプログラム７００、ＯＳ６００、Ｉ／Ｏ要求受信プログラム６２０、およびＩ／Ｏ応答送信プログラム６４０を含む各種プログラムをメモリ３２０から読み出して実行するプロセッサコアである。ＣＰＵコア３１１は、プロセッサと呼んでも良い。

メモリ３２０は、コンピュータプログラム及びその他のデータを記憶する。メモリ３２０は、ホスト２１０から受信したデータ及びホスト２１０に送信するデータを一時的に記憶するキャッシュ８００を含んでいてもよい。

ＨＢＡ３３１は、ネットワーク２２０に接続され、ＮＩＣ３３２は、ＬＡＮやＷＡＮ、インターネットなどのネットワーク２２０に接続され、管理端末２４０やホスト２１０とのデータ通信に用いられる。

ディスク装置３６０として、サーバ２００の二次記憶装置であるＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）３５１、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）３５２を有する。二次記憶装置はストレージとして、Ｉ／Ｏ処理のデータを格納する。ＳＳＤ３５１、ＨＤＤ３５２の個数は特に限定されず、それぞれ図３に示した数に限定されない。また、ディスク装置３６０は、典型的には、ＳＳＤ３５１、ＨＤＤ３５２であるが、ブロック形式のデータを格納できるものであれば何でもよい。本実施形態では、記憶デバイスの一例としてディスク装置３６０を例示しているが、本発明はこれに限定されることはない。他の例として、ディスク装置３６０は、テープアーカイブ、あるいはＤＶＤ、ＣＤなどの光ディスクライブラリを備えた装置であってもよい。以下では、ＳＳＤ３５１、ＨＤＤ３５２を総称してディスク装置３６０と呼ぶことにする。本実施形態において、ディスク装置３６０は、記憶デバイスとしてもよい。

図４は、サーバ２００のメモリ３２０の構成例を示す図である。メモリ３２０には、ストレージプログラム７００、キューペア監視プログラム１７００、プロセス管理表１３００、資源管理表１４００、ポリシ管理表１６００、ＯＳ６００が格納されている。ＯＳ６００はＯＳカーネル６１０を有する。ＯＳカーネル６１０は、通信ドライバプログラム５００、Ｉ／Ｏ要求受信プログラム６２０、Ｉ／Ｏ応答送信プログラム６４０を有する。

また、メモリ３２０には、ストレージプログラム７００、キューペア監視プログラム１７００、ＯＳ６００からアクセス可能な領域である共有メモリ４００を有する。共有メモリ４００は、キャッシュ８００、キャッシュ管理表９００、Ｉｎｉｔｉａｔｏｒ−Ｔａｒｇｅｔキュー（ＩＴＱ）４１０、Ｔａｒｇｅｔ−Ｉｎｉｔｉａｔｏｒキュー（ＴＩＱ）４２０、キューペア管理表１５００、およびボリューム管理表１０００を有する。図４に示すプログラムまたは管理情報は、ディスク装置３６０からロードされ、メモリ３２０へ格納される。

通信ドライバプログラム５００は、Ｉ／Ｏ要求受信プログラム６２０およびＩ／Ｏ応答送信プログラム６４０とストレージプログラム７００との間の通信を実現する。通信ドライバプログラム５００は、ＯＳカーネル６１０からストレージプログラム７００への通信を、ＴＩＱ４２０を介して伝達する。通信ドライバプログラム５００は、ストレージプログラム７００からＯＳカーネル６１０への通信を、ＩＴＱ４１０を介して伝達する。

Ｉ／Ｏ要求受信プログラム６２０は、ＦＣＰ／ｉＳＣＳＩなどの通信プロトコルを用いて、ホスト２１０からＩ／Ｏ要求を受信し、受信したＩ／Ｏ要求（入出力要求）を、通信ドライバプログラム５００を介してストレージプログラム７００へ送信する。

Ｉ／Ｏ応答送信プログラム６４０は、通信ドライバプログラム５００を介して、ストレージプログラム７００からＩ／Ｏ応答を受信し、ホスト２１０へＩ／Ｏ応答を送信する。

ストレージプログラム７００は、ＦＣＰ／ｉＳＣＳＩなどの通信プロトコルを介して、ホスト２１０からのＩ／Ｏ要求に従って、キャッシュ８００を用いつつディスク装置３６０にデータを書き込み、またはキャッシュ８００を用いつつディスク装置３６０からデータを読み出す。ストレージプログラム７００は、ＯＳカーネル６１０上で動作するプログラムであり、ストレージ（ディスク装置３６０）へデータを書き込む処理、またはストレージ（ディスク装置３６０）からデータを読み出す処理を実行するプログラムである。ストレージプログラム７００は、スナップショットやＲＡＩＤ等のストレージ機能を実行するプログラムである。ストレージプログラム７００は、ストレージ処理プログラム、ストレージプロセス、ストレージ機能と呼んでもよい。

ストレージキャッシュ（キャッシュ）８００は、ディスク装置３６０に書き込むデータまたはディスク装置３６０から読み出したブロックデータ（データ）を一時的に格納する。「ホスト２１０が論理ボリューム３４０にブロックデータを書き込む」というような説明は、実際はストレージプログラム７００がキャッシュ８００またはディスク装置３６０にブロックデータを書き込むことを意味する。同様に、「ホスト２１０が論理ボリューム３４０からブロックデータを読み出す」というような説明は、実際はストレージプログラム７００がキャッシュ８００またはディスク装置３６０からブロックデータを読み出すことを意味する。

論理ボリューム３４０は、ボリューム管理表１０００により管理される。

一般に、ストレージプログラム７００は、ホスト２１０から論理ボリューム３４０に対するデータを書き込む要求（ライト要求）を受信した場合、アクセス速度の速いキャッシュ８００に一時的にデータを書き込んだ後、ホスト２１０にＩ／Ｏ応答として書き込み完了を通知する。そして、ホスト２１０からの書き込み要求とは非同期にディスク装置３６０に、キャッシュ８００に格納されているデータを書き込む。これにより、ディスク装置３６０の性能が低い場合でも、キャッシュ８００の性能によって、システムとしてのＩ／Ｏ性能を向上することができる。

本実施例では、ストレージプログラム７００は、高い応答性能と高いスループット性能を実現するため、ポーリングでＩ／Ｏ処理を行う。

キャッシュ８００は、ディスク装置３６０に書き込むデータまたはディスク装置３６０から読み出したブロックデータを一時的に格納するために用いられる。なお、図４の例では、キャッシュ８００は、メモリ３２０の内部にあるが、実施形態がこれに限定されることはない。耐障害性の観点からストレージプログラム７００とは別に、不揮発性の半導体メモリに格納されていてもよいし、キャッシュ８００の一部として、半導体メモリより低速な記憶装置を用いてもよい。

キャッシュ管理表９００は、キャッシュ８００に格納されているブロックデータの状態を管理するテーブルである。例えば、キャッシュ８００に格納されているブロックデータの、キャッシュ８００上のアドレス、格納先ボリュームアドレス、およびデータサイズが格納されている。キャッシュ管理表９００は、キャッシュ管理情報と呼ばれてもよい。

ボリューム管理表１０００は、論理ボリューム３４０の情報を格納するテーブルである。例えば、各論理ボリューム３４０に関するボリューム番号、ボリューム属性、およびボリューム状態が格納されている。ボリューム管理表１０００は、ボリューム管理情報と呼ばれても良い。

ＴＩＱ４２０は、ストレージプログラム７００が通信ドライバプログラム５００を介してＩ／Ｏ応答送信プログラム６４０へデータを送信する際、そのデータを記録しておくための領域である。ＴＩＱ４２０はＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）型のデータ構造を有する。

ＩＴＱ４１０は、Ｉ／Ｏ要求受信プログラム６２０が通信ドライバプログラム５００を介してストレージプログラム７００へデータを通信する際、そのデータを記録しておくための領域である。ＩＴＱ４１０はＦＩＦＯ型のデータ構造を有する。

プロセス管理表１３００は、サーバ２００内で動作しているストレージプログラム７００の情報を管理するテーブルである。プロセス管理表１３００には、起動中のストレージプログラム７００のプロセスＩＤと、そのストレージプログラム７００が監視するキューペアのＩＤが格納される。

資源管理表１４００は、サーバ２００が有する資源を管理するためのテーブルである。資源管理表１４００には、サーバ２００内に接続されているＨＢＡ３３１のポート数、ＮＩＣ３３２のポート数、メモリ３２０内のうち共有メモリ４００として使用しているメモリ量、共有メモリ４００として使用しているメモリ量のうち、キャッシュ８００として使用しているメモリ量が格納される。

キューペア管理表１５００は、共有メモリ４００上に格納されているＴＩＱ４２０とＩＴＱ４１０のペア（以後、単にキューペアと呼ぶ）を管理するテーブルである。キューペア管理表１５００には、キューペアに格納される情報を識別するためのキューペアＩＤ、ＴＩＱ４２０の先頭アドレス、ＩＴＱ４１０の先頭アドレス、およびキューサイズが格納される。

ポリシ管理表１６００は、キューペアを増減させるためのポリシを管理するテーブルである。ポリシ管理表１６００には、どのような条件でキューペアを増加させるか、またどのような条件でキューペアを削減するかを定めたポリシが格納される。ポリシ管理表１６００は、キューペア増減ポリシ管理情報と呼んでもよい。

キューペア監視プログラム１７００は、定期的にプロセス管理表１３００、資源管理表１４００、キューペア管理表１５００、およびポリシ管理表１６００を監視し、状況に応じてキューペアの数を増減させるプログラムである。キューペア監視プログラム１７００は、ストレージプログラム７００の一部であってもよいし、ストレージプログラム７００とは別のプログラムであってもよい。

図５は、計算機システム１０の他の構成例を示す図である。図５に示すように、サーバ２００でハイパーバイザ２０３が動作し、ハイパーバイザ２０３上で１または複数の仮想計算機２０２が稼働しても良い。仮想計算機２０２上で、ＯＳ６００やストレージプログラム７００、キューペア監視プログラム１７００が動作してもよい。すなわち、図４に示す各プログラムは、物理計算機のハードウェア上で動作することもあれば、仮想計算機上で動作することもある。また、ホスト２１０は、仮想計算機上で動作するホストプログラムであってもよいし、物理的なホスト計算機であっても良い。ＯＳ６００やストレージプログラム７００、キューペア監視プログラム１７００が動作する仮想計算機と、ホストプログラムが動作する仮想計算機とが、同一サーバ２００上であっても、ネットワーク２２０を介して接続する異なるサーバ２００上であってもよい。

図６は、Ｉｎｉｔｉａｔｏｒ−Ｔａｒｇｅｔキュー（ＩＴＱ）４１０の構成例を示す図である。図７は、Ｔａｒｇｅｔ−Ｉｎｉｔｉａｔｏｒキュー（ＴＩＱ）４２０の構成例を示す図である。

図６に示したＩＴＱ４１０は、先入れ先出し式すなわちＦＩＦＯ型のデータ構造を有している。ＩＴＱ４１０には、Ｉ／Ｏ要求受信プログラム６２０がホスト２１０から受信したＩ／Ｏ要求が順番に詰め込まれる。

図７に示したＴＩＱ４２０も、ＦＩＦＯ型のデータ構造を有している。ＴＩＱ４２０には、ストレージプログラム７００が、Ｉ／Ｏ要求受信プログラム６２０から通信ドライバプログラム５００を介して受信したＩ／Ｏ要求に対して返送するＩ／Ｏ応答が順番にエンキューされる。Ｉ／Ｏ応答は、Ｉ／Ｏ処理完了通知と呼んでも良い。

図６の例では、ＩＴＱ４１０には、２つのＩ／Ｏ要求が格納されている。Ｉ／Ｏ要求には、Ｉ／Ｏ要求の対象である論理ボリューム３４０のボリューム番号１１１０、Ｉ／Ｏ種別１１２０、ボリュームアドレス１１３０、データサイズ１１４０を示す情報が含まれていて良い。さらに、Ｉ／Ｏ種別１１２０がライトの場合、ライトデータが格納されたメモリ３２０のメモリアドレス１１５０を示す情報が含まれていて良い。例えば、図６によると、先に格納されたＩ／Ｏ要求は、対象のボリューム番号１１１０が「１」であり、Ｉ／Ｏ種別１１２０が「リード」であり、ボリュームアドレス１１３０が「０ｘ１００」であり、データサイズ１１４０が「０ｘ１００」である。後から格納されたＩ／Ｏ要求は、対象のボリューム番号１１１０が「２」であり、Ｉ／Ｏ種別１１２０が「ライト」であり、ボリュームアドレス１１３０が「０ｘ３０００」であり、データサイズ１１４０が「０ｘ４００」であり、メモリアドレス１１５０が「０ｘ５８０００」である。Ｉ／Ｏ種別１１２０が「ライト」であるＩ／Ｏ要求をライト要求と呼んでも良い。Ｉ／Ｏ種別１１２０が「リード」であるＩ／Ｏ要求をリード要求と呼んでも良い。

図７の例では、ＴＩＱ４２０には、２つのＩ／Ｏ応答（Ｉ／Ｏ処理完了通知）が格納されている。Ｉ／Ｏ応答は、Ｉ／Ｏ応答の対象である論理ボリューム３４０のボリューム番号１２１０、Ｉ／Ｏ種別１２１５、ボリュームアドレス１２２０、データサイズ１２２５を示す情報が含まれていて良い。さらに、Ｉ／Ｏ種別１１２０がリードの場合、リードデータが格納されたメモリ３２０（キャッシュ８００）のメモリアドレス１２３０を示す情報が含まれていて良い。先に格納されたＩ／Ｏ応答は、ボリューム番号１２１０が「１」であり、Ｉ／Ｏ種別１２１５が「リード」であり、ボリュームアドレス１２２０が「０ｘ１００」であり、データサイズ１２２５が「０ｘ１００」であり、メモリアドレス１２３０が「０ｘ５８０００」である。後から格納されたＩ／Ｏ応答は、ボリューム番号１２１０が「２」であり、Ｉ／Ｏ種別１２１５が「ライト」であり、ボリュームアドレス１２２０が「０ｘ３００」であり、データサイズ１２２５が「０ｘ４００」である。

図８は、ボリューム管理表１０００の構成例を示す図である。ボリューム管理表１０００には、ストレージプログラム７００が管理する論理ボリューム３４０の情報が記録される。例えば、ストレージプログラム７００が論理ボリューム３４０を作成したときに、論理ボリューム３４０の情報をボリューム管理表１０００に記録する。図８の例では、ボリューム管理表１０００には、ストレージプログラム７００が作成した論理ボリューム３４０の数だけ行がある。

ボリューム管理表１０００には、論理ボリューム３４０の情報として、ボリューム番号１０１０、ボリューム状態１０２０、ボリュームサイズ１０３０、ボリュームアドレス１０３５、ディスク装置番号１０４０、ディスク装置アドレス１０５０、ストレージ機能１０６０が含まれる。

ボリューム番号１０１０には、論理ボリューム３４０を一意に識別するボリュームＩＤが格納される。ボリューム状態１０２０には、論理ボリューム３４０へのＩ／Ｏが可か不可かを示す情報が格納される。ここでは「Ｉ／Ｏ可」か「Ｉ／Ｏ不可」のいずれかが格納される。ボリュームサイズ１０３０には、論理ボリューム３４０の容量が格納される。

ボリュームアドレス１０３５には、論理ボリューム３４０上の論理アドレスが格納される。ディスク装置番号１０４０には、論理ボリューム３４０を構成するディスク装置３６０の識別子が格納される。ディスク装置アドレス１０５０は、ボリュームアドレス１０３５に対応づけられた物理的な記憶領域のアドレスであって、ディスク装置番号１０４０で識別されるディスク装置３６０上のアドレスが格納される。なお、図８の例では、ボリュームアドレス１０３５から所定サイズ（例えば「０ｘ１００」）の論理ボリューム３４０の論理的な記憶領域と、ディスク装置アドレス１０５０から所定サイズのディスク装置３６０の物理的な記憶領域と、を対応づけている。この所定サイズの大きさは図８の例に限定されるものではないし、必ずしも所定サイズ毎の固定長で管理しなくても良い。

ボリューム管理表１０００は、論理ボリューム３４０の全ての記憶領域について、ディスク装置３６０の物理的な記憶領域と対応づけて、管理してもよい。または、論理ボリューム３４０のデータが格納されているディスク装置３６０の物理的な記憶領域と、論理ボリューム３４０の記憶領域との対応関係をボリューム管理表１０００で管理しても良い。この場合、ストレージプログラム７００は、残りの論理ボリューム３４０の記憶領域に対してライト要求があったときに、ディスク装置３６０の物理的な記憶領域を割り当て、その論理ボリューム３４０の記憶領域とディスク装置３６０の物理的な記憶領域との対応関係を、ボリューム管理表１０００で管理しても良い。

ストレージ機能１０６０には、論理ボリューム３４０に適用されるストレージ機能が格納される。ストレージ機能の例として、スナップショットやＲＡＩＤなどがある。サーバ２００がＩ／Ｏ要求を受信した場合に、ストレージプログラム７００での処理が必要となる所定のストレージ機能を論理ボリューム３４０に適用している場合、ストレージ機能１０６０には、その旨を示す情報（例えばＹｅｓ）を格納しても良い。

図８の例によると、ボリューム番号１０１０が「１」の論理ボリューム３４０は、ボリューム状態１０２０が「Ｉ／Ｏ可」であり、ボリュームサイズ１０３０が「１ＴＢ」であり、ストレージ機能１０６０としてＲＡＩＤ及びスナップショットを適用していることが示されている。

図９は、キャッシュ管理表９００の構成例を示す図である。キャッシュ管理表９００の各行には、ストレージプログラム７００がキャッシュ８００に格納したデータに関する情報が格納される。格納される情報には、ボリューム番号９１０、ボリュームアドレス９２０、データサイズ９３０、メモリアドレス９４０、データ状況９５０が含まれる。

キャッシュ管理表９００には、キャッシュ８００に格納されているデータの数だけ行がある。キャッシュ管理表９００には、最大でキャッシュ８００の容量分のデータを管理できるだけの容量がある。

ボリューム番号９１０には、キャッシュ８００に格納されているデータについて、データが属する論理ボリューム３４０の、ボリューム管理表１０００で管理されているボリュームＩＤが格納される。

ボリュームアドレス９２０には、キャッシュ８００に格納されているデータについて、論理ボリューム３４０上でのアドレスが格納される。データサイズ９３０は、キャッシュ８００に格納されているデータのサイズを示す。メモリアドレス９４０は、当該データについて、キャッシュ８００上のアドレスを示す。

データ状況９５０には、キャッシュ８００上のデータについて、ディスク装置３６０へライト済みを示す「クリーン」、ディスク装置３６０へライト未完了を示す「ダーティ」、ストレージプログラムの処理状況を示す「リード中」、もしくは「ライト中」が格納される。

図９には、キャッシュ８００内に５つのデータが格納されている場合のキャッシュ管理表９００が例示されている。例えば、ある行には、ボリューム番号９１０が「１」であり、ボリュームアドレス９２０が「０ｘ１００」であり、データサイズ９３０が「０ｘ４００」であり、メモリアドレス９４０が「０ｘ００００」であり、データ状況９５０が「クリーン」であるデータが示されている。

図１０は、プロセス管理表１３００の構成例を示す図である。プロセス管理表１３００の各行には、起動中（実行中）のストレージプログラム７００の情報が格納される。格納される情報には、プロセスＩＤ１３１０およびキューペアＩＤ１３２０が含まれる。プロセス管理表１３００には、ストレージプログラム７００の起動中（実行中）のプロセス数だけ行がある。

プロセスＩＤ１３１０には、起動中（実行中）のストレージプログラム７００のプロセスの識別子であるプロセスＩＤが格納される。キューペアＩＤ１３２０には、起動中のストレージプログラム７００が使用するキューペアについての、キューペア管理表１５００にて管理されているキューペアＩＤが格納される。

図１０には、起動中のストレージプログラム７００が２個の場合のプロセス管理表１３００が例示されている。例えば、行１３３０には、プロセスＩＤ１３１０が「２０００」であり、キューペアＩＤ１３２０が「１、２」である起動中のストレージプログラム７００が示されている。

図１１は、資源管理表１４００の構成例を示す図である。資源管理表１４００の各行には、サーバ２００に接続されている資源に関する情報が示されている。資源には、メモリ３２０、ＨＢＡ３３１、およびＮＩＣ３３２が含まれる。資源に関する情報には、各資源についての資源種別１４１０と資源量１４２０が含まれる。

資源管理表１４００には、ＨＢＡ３３１のポート種別数、ＮＩＣ３３２のポート種別数、共有メモリ、キャッシュの数の合計数だけ行がある。

資源種別１４１０には、サーバ２００に接続されているＨＢＡ３３１のポート種別、ＮＩＣ３３２のポート種別、共有メモリ、キャッシュのいずれかが格納される。

資源量１４２０には、サーバ２００に接続されているＨＢＡ３３１やＮＩＣ３３２のポート数や、共有メモリやキャッシュ８００の容量が格納されている。

図１１には、ポート種別がＦＣポートのＨＢＡ３３１と、ポート種別がＥｔｈｅｒｎｅｔポート（Ｅｔｈｅｒｎｅｔは登録商標）のＮＩＣ３３２と、キャッシュ８００とが示された資源管理表１４００が例示されている。例えば、行１４３０には、資源種別１４１０が「ＦＣポート」であり、資源量１４２０が「８」である資源の情報が格納されている。

図１２は、キューペア管理表１５００の構成例を示す図である。キューペア管理表１５００の各行には、ＴＩＱ４２０およびＩＴＱ４１０のキューペアに関する情報が記録される。記録される情報には、キューペアＩＤ１５１０、ＴＩＱ格納先頭アドレス１５２０、ＩＴＱ格納先頭アドレス１５３０、キューサイズ１５４０、および操作可否１５４５が含まれる。

キューペア管理表１５００には、ＴＩＱ４２０およびＩＴＱ４１０のキューペアの数だけ行がある。

キューペアＩＤ１５１０には、各キューペアに割り振られたＩＤが格納される。

ＴＩＱ格納先頭アドレス１５２０には、ＴＩＱ４２０が格納されているメモリ３２０上の先頭アドレスが格納される。

ＩＴＱ格納先頭アドレス１５３０には、ＩＴＱ４１０が格納されているメモリ３２０の先頭アドレスが格納される。

キューサイズ１５４０には、ＴＩＱ４２０およびＩＴＱ４１０のサイズが格納される。操作可否１５４５には、キューペアへの操作が可か不可を示す情報が格納される。ここでは「可」か「否」のいずれかが格納される。

図１２には、キューペアが４個ある場合のキューペア管理表１５００が例示されている。例えば、行１５５０には、キューペアＩＤ１５１０が「１」であり、ＴＩＱ格納先頭アドレスが「０ｘ８０００００」であり、ＩＴＱ格納先頭アドレスが「０ｘ８８００００」であり、キューサイズが「０ｘ８００００」であり、操作可否が「否」であるデータが格納されている。

図１３は、ポリシ管理表１６００の構成例を示す図である。ポリシ管理表１６００の各行には、キューペアを増減させることを決める判定に用いるポリシの情報が格納される。ポリシの情報には、ポリシ項目１６１０、上限１６２０、および下限１６３０が含まれている。

本実施形態では、ポリシ項目１６１０には、「ストレージプログラムが処理担当するキューペア数」、「ＦＣポート数」、「Ｅｔｈｅｒｎｅｔポート数」、「キューペア使用メモリ量」がある。「ストレージプログラムが処理担当するキューペア数」に関しては上限と下限が、「ＦＣポート数」、「Ｅｔｈｅｒｎｅｔポート数」、および「キューペア使用メモリ」に関しては上限が設定できる。

例えば、行１６４０には、ポリシ項目１６１０が「ストレージプログラムが処理するキューペア数」であり、上限１６２０が「８」であり、下限１６３０が「１」であるポリシが設定されている。

キューペア増減の実行要否は、ストレージプログラム７００の起動中のプロセス数、および各種資源の使用量と、それぞれの上限および下限とを比較することで決定される。ストレージプログラム７００の起動中のプロセス数は、プロセス管理表１３００から算出することができる。

各種資源として、ＦＣポート数およびＥｔｈｅｒｎｅｔポート数、共有メモリ量およびキャッシュ量、およびキューペアが使用しているメモリ量がある。ＦＣポート数およびＥｔｈｅｒｎｅｔポート数は資源管理表１４００に記載されている。共有メモリ量およびキャッシュ量も資源管理表１４００に記載されている。キューペアが使用しているメモリ量は、キューペア管理表１５００から算出される。

各資源の上限および下限は、ポリシ管理表１６００の各ポリシ項目１６１０の上限あるいは下限から得られる。

図１４は、通信ドライバプログラム５００のフローチャートである。ＣＰＵコア３１１は、Ｉ／Ｏ要求受信プログラム６２０からＩ／Ｏ要求の到着の通知を受信すると、通信ドライバプログラム５００の処理を開始する。または、ＣＰＵコア３１１は、ストレージプログラム７００がシステムコールを発行すると、通信ドライバプログラム５００の処理を開始する（Ｓ３３００）。

次に、ＣＰＵコア３１１は、通信ドライバプログラム５００がＩ／Ｏ要求の到着の通知を受信したか否かの判定処理を行う（Ｓ３３１０）。

ステップＳ３３１０の判定で、Ｉ／Ｏ要求の到着の通知を受信していた場合（Ｓ３３１０：ＹＥＳ）、ＣＰＵコア３１１は、ボリューム管理表１０００を参照して、Ｉ／Ｏ要求の対象となる論理ボリューム３４０が所定のストレージ機能１０６０を使用しているか判定する（Ｓ３３１５）。ここで、所定のストレージ機能とは、サーバ２００がＩ／Ｏ要求を受信した場合、ストレージプログラム７００での処理が必要となるストレージ機能である。所定のストレージ機能は、事前に設定されていても良い。ストレージプログラム７００が備える複数のストレージ機能のうちの一部が、所定のストレージ機能であっても良い。

ステップＳ３３１５の判定で、論理ボリューム３４０が所定のストレージ機能１０６０を使用していない場合（Ｓ３３１５：Ｎｏ）、ＣＰＵコア３１１は、ボリューム管理表１０００を参照して、Ｉ／Ｏ要求の対象となる論理ボリューム３４０のボリューム状態１０２０がＩ／Ｏ可か否か判定する（Ｓ３３２０）。

ステップＳ３３２０の判定で、論理ボリューム３４０のボリューム状態１０２０がＩ／Ｏ可である場合（Ｓ３３２０：ＹＥＳ）、ＣＰＵコア３１１は、Ｉ／Ｏ要求のＩ／Ｏ種別がリードであるかどうかを判定する（Ｓ３３３０）。

ステップＳ３３３０の判定で、Ｉ／Ｏ要求の種別がリードの場合（Ｓ３３３０：ＹＥＳ）、ＣＰＵコア３１１は、Ｉ／Ｏ要求の対象となっている論理ボリューム３４０のアドレスとデータサイズについて、キャッシュ８００上にデータが存在するか否かを、キャッシュ管理表９００を参照して判定する（Ｓ３３４０）。

ステップＳ３３４０の判定で、Ｉ／Ｏ要求対象の論理ボリューム３４０のアドレス範囲に対して、キャッシュ８００上にデータが存在する場合（Ｓ３３４０：ＹＥＳ）、ＣＰＵコア３１１は、ＩＴＱ４１０内に、Ｉ／Ｏ要求対象の論理ボリューム３４０のアドレス範囲に対するデータの書き込みを要求するライト要求が存在するか否かを判定する（Ｓ３３５０）。

ステップＳ３３５０の判定で、ＩＴＱ４１０内に、Ｉ／Ｏ要求対象の論理ボリューム３４０のアドレス範囲に対するライト要求が存在しない場合（Ｓ３３５０：ＹＥＳ）、ＣＰＵコア３１１は、Ｉ／Ｏ処理完了通知（Ｉ／Ｏ応答）を発行する（Ｓ３３６０）。これは、図２のＳ３０３０においてＮｏの場合、すなわちＣＰＵコア３１１がストレージプログラム７００の処理が不要と判断した場合に該当し、Ｉ／Ｏ要求をＩＴＱ４１０にエンキューしないことで、ストレージプログラム７００にＩ／Ｏ要求を通知しない。ＣＰＵコア３１１は、Ｉ／Ｏ応答送信プログラム６４０を呼び出し、リード対象のデータが存在するキャッシュ８００のアドレス及びサイズを通知する。ＣＰＵコア３１１は、ステップＳ３３６０の処理が完了次第、通信ドライバプログラム５００の処理を終了する（Ｓ３４００）。

ステップＳ３３１５の判定において、所定のストレージ機能を使用している場合（Ｓ３３１５：ＹＥＳ）、Ｉ／Ｏ要求の対象となる論理ボリューム３４０がストレージプログラム７００での処理が必要となるストレージ機能を使用しているので、ＣＰＵコア３１１は、ＩＴＱ４１０にＩ／Ｏ要求をエンキューする（Ｓ３３７０）。

ステップＳ３３２０の判定において、論理ボリューム３４０のボリューム状態１０２０がＩ／Ｏ不可である場合（Ｓ３３２０：ＮＯ）、論理ボリューム３４０が障害状態である可能性や、フォーマット中である可能性があるので、ＣＰＵコア３１１は、ＩＴＱ４１０にＩ／Ｏ要求をエンキューする（Ｓ３３７０）。

ステップＳ３３３０の判定において、Ｉ／Ｏ種別がリードでない場合（Ｓ３３３０：ＮＯ）、例えばＩ／Ｏ種別がライトである場合、キャッシュ操作処理や、ＲＡＩＤ等のストレージ機能を使用する（または使用する可能性がある）ので、ＣＰＵコア３１１は、ＩＴＱ４１０にＩ／Ｏ要求をエンキューする（Ｓ３３７０）。

ステップＳ３３４０の判定において、Ｉ／Ｏ要求対象のボリュームアドレス範囲についてキャッシュ８００上にデータが存在しない場合（Ｓ３３４０：ＮＯ）、ストレージプログラム７００によりディスク装置３６０からのデータ読み出しまたはデータ書き込みが必要となる可能性があるので、ＣＰＵコア３１１は、ＩＴＱ４１０にＩ／Ｏ要求をエンキューする（Ｓ３３７０）。

ステップＳ３３５０の判定において、ＩＴＱ４１０内に、Ｉ／Ｏ要求対象の論理ボリューム３４０のアドレス範囲に対するライト要求が存在する場合（Ｓ３３５０：ＮＯ）、ストレージプログラム７００で当該先行するライト要求を処理した後に、今回のＩ／Ｏ要求（リード要求）を処理する必要があるので、ＣＰＵコア３１１は、ＩＴＱ４１０にＩ／Ｏ要求をエンキューする（Ｓ３３７０）。

Ｉ／Ｏ要求がＩＴＱ４１０にエンキューされると、ストレージプログラム７００の処理が必要な状態になる。ＣＰＵコア３１１は、ステップＳ３３７０の処理が完了次第、通信ドライバプログラム５００を終了する（Ｓ３４００）。

Ｓ３３１０の判定で、Ｉ／Ｏ要求を受信していない場合（Ｓ３３１０：ＮＯ）、すなわちシステムコールに通信ドライバプログラム５００が呼び出された場合、ＣＰＵコア３１１は、ＴＩＱ４２０から、Ｉ／Ｏ応答をデキューする（Ｓ３３８０）。

次に、ＣＰＵコア３１１は、Ｉ／Ｏ応答を、Ｉ／Ｏ応答送信プログラム６４０に通知する（Ｓ３３９０）。ＣＰＵコア３１１は、ステップＳ３３９０の処理が完了次第、通信ドライバプログラム５００を終了する（Ｓ３４００）。

以上、ステップＳ３３００からＳ３４００で処理を完了する。なお、図１４に示す各判断ステップＳ３３１０、Ｓ３３１５、Ｓ３３２０、Ｓ３３３０、Ｓ３３４０、Ｓ３３５０について、一部のステップの順序を変更しても、一部のステップを省略してもよい。

ＯＳ６００は、Ｓ３３１５において、ホスト２１０から論理ボリューム３４０に対するＩ／Ｏ要求を受信した場合、ボリューム管理表１０００を参照して、Ｉ／Ｏ要求の対象となる論理ボリューム３４０に適用されるストレージ機能１０６０の情報に基づいて、ストレージプログラム７００によるＩ／Ｏ要求の処理が必要か否かを判定する。ストレージプログラム７００によるＩ／Ｏ要求の処理が必要と判定した場合、キューペアを介してストレージプログラム７００と通信する。ストレージプログラム７００では、Ｉ／Ｏ要求に基づく処理が実行される。一方、ＯＳ６００は、ストレージプログラム７００によるＩ／Ｏ要求の処理が必要でないと判定した場合、ホスト２１０へＩ／Ｏ要求に対する応答を実行する。ストレージプログラム７００をＯＳ６００上で動作させつつ、Ｉ／Ｏ性能の低下を抑え、Ｉ／Ｏ性能を維持または向上することを可能にする。

ストレージプログラム７００は、データをキャッシュ８００に書き込んだ後に記憶デバイス（ディスク装置３６０）にデステージする。Ｉ／Ｏ応答送信プログラム６４０は、データ出力の要求を受けると、その要求の対象のデータがキャッシュ８００に存在すればキャッシュ８００のデータを出力する。一方、その要求の対象のデータがキャッシュ８００に存在しなければ、Ｉ／Ｏ応答送信プログラム６４０は、その要求をＩＴＱ４１０を介してストレージプログラム７００に通知する。これによれば、キャッシュ８００によりデータ出力の処理を高速化する構成において、キャッシュ８００にデータが存在するとき、通信ドライバプログラム５００が、キューペアを用いた通信およびストレージプログラム７００の処理を介さず、データ出力の処理を迅速に完了させることができる。

図１５は、ストレージプログラム７００のフローチャートである。ＣＰＵコア３１１は、サーバ２００の起動時に、図１５に示す処理を開始する（Ｓ３５００）。ＣＰＵコア３１１は、まず、プロセス管理表１３００を参照し、実行しているストレージプログラム７００のプロセスが担当となっているキューペアの中から処理対象とするキューペアを１つ選択する。キューペアの選択方法は限定されないが、例えばラウンドロビンで複数のキューペアから順番に１つずつ選択するという方法が挙げられる。

次にＣＰＵコア３１１は、キューペア管理表１５００を参照し、選択した処理対象のキューペアが操作可能な状態かどうか（操作可否１５４５）を判定する（Ｓ３５０５）。処理対象のキューペアが操作不可の場合（Ｓ３５０５：ＮＯ）、ＣＰＵコア３１１は再度ステップＳ３５００に戻って処理をやり直す。

処理対象のキューペアが操作可能な場合（Ｓ３５０５：ＹＥＳ）、ＣＰＵコア３１１は、ＩＴＱ４１０にエントリがあるかどうかを判定する（Ｓ３５１０）。

Ｓ３５１０の判定で、ＩＴＱ４１０にエントリがない場合（Ｓ３５１０：ＮＯ）、ＣＰＵコア３１１はステップＳ３５００に戻る。一方、Ｓ３５１０の判定で、ＩＴＱ４１０にエントリがある場合（Ｓ３５１０：ＹＥＳ）、ＣＰＵコア３１１は、ＩＴＱ４１０からＩ／Ｏ要求をデキューする（Ｓ３５２０）。

次に、ＣＰＵコア３１１は、ＩＴＱ４１０からデキューしたＩ／Ｏ要求の対象となっている論理ボリューム３４０に対して、テスト用コマンドを発行し、論理ボリューム３４０へのＩ／Ｏが可能かどうか判定する処理を行う（Ｓ３５３０）。Ｓ３５３０の判定で、論理ボリューム３４０へのＩ／Ｏが不可の場合（Ｓ３５３０：ＮＯ）、ＣＰＵコア３１１は、ＴＩＱ４２０へ、Ｉ／Ｏ応答としてエラー応答をエンキューする（Ｓ３５９０）。

Ｓ３５３０の判定で、論理ボリューム３４０へのＩ／Ｏが可能の場合（Ｓ３５３０：ＹＥＳ）、ＣＰＵコア３１１は、図１６のキャッシュ操作処理を行う（Ｓ３５３５）。次に、ＣＰＵコア３１１は、ＩＴＱ４１０からデキューしたＩ／Ｏ要求のＩ／Ｏ種別がリードかどうかを判定する（Ｓ３５４０）。

Ｓ３５４０の判定で、Ｉ／Ｏ種別が「リード」である場合（Ｓ３５４０：ＹＥＳ）、ＣＰＵコア３１１は、Ｉ／Ｏ要求の対象の論理ボリューム３４０のデータをディスク装置３６０からキャッシュ８００へ転送する（Ｓ３５７０）。次に、ＣＰＵコア３１１は、キャッシュ管理表９００における、Ｉ／Ｏ要求の対象の論理ボリューム３４０のデータ状況９５０を「クリーン」に更新する（Ｓ３５８０）。

Ｓ３５４０の判定で、Ｉ／Ｏ種別が「リード」でない場合（Ｓ３５４０：ＮＯ）、ＣＰＵコア３１１は、Ｉ／Ｏ要求に基づき、キャッシュ８００にデータをライトする（Ｓ３６２０）。次に、ＣＰＵコア３１１は、キャッシュ管理表９００における、Ｉ／Ｏ要求の対象の論理ボリューム３４０のデータ状況９５０を「ダーティ」に更新する（Ｓ３５８０）。

次に、ＣＰＵコア３１１は、ＴＩＱ４２０へ、Ｉ／Ｏ応答をエンキューする（Ｓ３５９０）。ＣＰＵコア３１１は、システムコールを発行し、ＴＩＱ４２０へのエンキューを行ったことを通信ドライバプログラム５００へ通知する（Ｓ３６００）。ステップＳ３６００の処理が終了次第、ＣＰＵコア３１１はステップＳ３５００へ戻る。

以上、ステップＳ３５００からＳ３６２０でストレージプログラム７００の処理を実行する。

図１６は、ストレージプログラム７００におけるＳ３５３５のキャッシュ操作処理のフローチャートである。

ＣＰＵコア３１１は、キャッシュ８００に空き領域があるかどうかを、キャッシュ管理表９００を用いて判定する（Ｓ３７３０）。

ステップＳ３７３０の判定において、キャッシュ８００に空き領域がある場合（Ｓ３７３０：ＹＥＳ）、ＣＰＵコア３１１は、空き領域を使用するために、キャッシュ管理表９００の空き領域を示す行の情報を更新し、使用する領域を示す行を追加することにより、キャッシュ管理表９００を更新する（Ｓ３７８０）。

ステップＳ３７３０の判定において、キャッシュ８００に空き領域がない場合（Ｓ３７３０：ＮＯ）、ＣＰＵコア３１１は、更にキャッシュ管理表９００を参照し、キャッシュ８００上にクリーンデータがあるかどうかを判定する（Ｓ３７４０）。

ステップＳ３７４０の判定において、クリーンデータが存在する場合（Ｓ３７４０：ＹＥＳ）、ＣＰＵコア３１１はキャッシュ８００上のクリーンデータを破棄する（Ｓ３７５０）。

次に、ＣＰＵコア３１１は、破棄したクリーンデータに該当するキャッシュ管理表９００上の行を削除し、その領域を空き領域として使用するために、キャッシュ管理表９００を更新する（Ｓ３７８０）。

ステップＳ３７４０の判定において、クリーンデータが存在しない場合（Ｓ３７４０：ＮＯ）、ＣＰＵコア３１１は、キャッシュ管理表９００からダーティデータを示す行を１つ選択し、選択した行のデータ状況９５０に「ライト中」を付加し、キャッシュ８００上の当該データをディスク装置３６０へ書き込む（Ｓ３７７０）。

次に、ＣＰＵコア３１１は、キャッシュ管理表９００上のディスク装置３６０に書き込んだデータに該当する行のデータ状況９５０を「クリーン」へ更新し、当該領域を空き領域として使用するために、キャッシュ管理表９００を更新する（Ｓ３７８０）。

以上により、キャッシュ操作処理を完了する。

図１７は、複数のキューペアが存在するサーバ２００の構成例を示す図である。図１のサーバ２００にはキューペアが１組のみ記載されているが、図１７のように、サーバ２００にキューペアが複数存在してもよい。ストレージプログラム７００の各プロセスは１または複数のキューペアを使用してもよい。また、キューペアは動的に増減させても良い。

図１８は、キューペア監視プログラム１７００のフローチャートである。ＣＰＵコア３１１は、サーバ２００の起動時に、図１８に示す処理を開始する（Ｓ４０００）。

ＣＰＵコア３１１は、Ｉ／Ｏ要求受信プログラム６２０からストレージプログラム７００への通信データを保持するＩＴＱ４１０と、ストレージプログラム７００からＩ／Ｏ応答送信プログラム６４０への通信データを保持するＴＩＱ４２０とを対として用い、そのキューペアの個数を制御する。

その際、ＣＰＵコア３１１は、キューペアに関連する資源の使用量に基づいてキューペアの個数を制御する。ここでは資源の例として、ストレージプログラム７００が処理するキューペア数、ＦＣポート数、Ｅｔｈｅｒｎｅｔポート数、およびキューペア使用メモリ量がある。キューペアに関連する資源の使用量に基づいてキューペアの個数を制御するので、資源の使用量を適切な範囲に維持することができる。

また、キューペアの個数には上限数と下限数が定められ、ＣＰＵコア３１１は、キューペアの個数が下限数を下回ったらキューペアを増加させ、キューペアの個数が上限数を超えたらキューペアを削減する。これによれば、キューペアの個数を状況に応じて増減制御するとともに、上限と下限の間の適切な範囲に維持することができる。

ＣＰＵコア３１１は、ポリシ管理表１６００を読み込む。このポリシ管理表１６００は、キューペアの個数の制御に用いるポリシを表わすキューペア増減ポリシ管理情報である。管理端末２４０は、キューペア増減ポリシ管理情報を画面表示し、入力操作により更新する。サーバ２００は、管理端末２４０からキューペア増減ポリシ管理情報（ポリシ管理表１６００）を取得してもよい。

ＣＰＵコア３１１は、以下に示すように、キューペア増減ポリシ管理情報を参照してキューペアの個数を制御する。これにより、キューペアの増減制御の条件をユーザの所望により設定したり変更したりすることができる。

ＣＰＵコア３１１は、資源管理表１４００、キューペア管理表１５００、プロセス管理表１３００を読み込む。ＣＰＵコア３１１は、ポリシ管理表１６００において、ストレージプログラムが処理するキューペア数に関するポリシを記述した行１６４０における下限値と、処理すべきキューペア数を意味するキューペア管理表１５００の行数とを比較し、ポリシ管理表１６００の行１６４０の下限値がキューペア管理表１５００の行数を上回っているか否か判定する（Ｓ４０５０）。

ステップＳ４０５０の判定で、ポリシ管理表１６００の行１６４０の下限値がキューペア管理表１５００の行数を上回っていた場合（Ｓ４０５０：ＹＥＳ）、つまり、キューペア数がポリシ上の下限値を下回っていた場合、ＣＰＵコア３１１は、キューペア増加処理を実行する（Ｓ４０６０）。その後、ＣＰＵコア３１１はスリープ処理を実行する（Ｓ４０９０）。

ステップＳ４０５０の判定で、ポリシ管理表１６００の行１６４０の下限値がキューペア管理表１５００の行数を上回っていた場合（Ｓ４０５０：ＮＯ）、つまり、キューペア数がポリシ上の下限値を下回っていない場合、ＣＰＵコア３１１は、Ｓ４０７０において、キューペア管理表１５００の行数（キューペア数）と、プロセス管理表１３００の行数（起動中のストレージプログラム７００のプロセス数）とを比較する。更に、ＣＰＵコア３１１は、同じＳ４０７０において、ポリシ管理表１６００の行１６４０、行１６５０、および行１６６０の各上限値と、キューペア管理表１５００の行数とを比較する。更に、ＣＰＵコア３１１は、同じＳ４０７０において、ポリシ管理表１６００の行１６７０の上限値と、キューペア管理表１５００から算出されるキューサイズ合計値とを比較する。

Ｓ４０７０において、キューペア管理表１５００から算出される行数が、ポリシ管理表１６００の行数の上限値を超えている場合、もしくはキューペア管理表１５００から算出されるキューサイズ合計値が、ポリシ管理表１６００のキューペア使用メモリ量の上限値を超えている場合（Ｓ４０７０：ＹＥＳ）、つまり、キューペア数がポリシ上の上限値を上回っている場合、ＣＰＵコア３１１は、キューペア削減処理を実行する（Ｓ４０８０）。

同一のキューを複数のプロセスで共有して使用する場合、あるプロセスがキューを操作している間は他のプロセスがキューを操作できないという制約が生じる。このようなキュー操作の競合により高スループットの達成が妨げられる。それに対して、本実施形態では、ＣＰＵコア３１１は、ストレージ処理を実行するプロセスの個数に応じてキューペアの個数を制御する。そのため、キューペアの個数が過剰になり、キューの状況を確認するキューチェック処理の負担が増えるのを抑制する一方で、キュー操作の競合を低減してスループットの低下を抑制することができる。

キューペア管理表１５００から算出される行数が、ポリシ管理表１６００の行数の上限値を超えておらず、かつキューペア管理表１５００から算出されるキューサイズ合計値が、ポリシ管理表１６００のキューペア使用メモリ量の上限値を超えていない場合（Ｓ４０７０：ＮＯ）、つまり、キューペア数がポリシ上の上限値を上回っていない場合、ＣＰＵコア３１１は、一度処理の停止（スリープ処理）を行う（Ｓ４０９０）。

また、ステップＳ４０６０またはステップＳ４０８０の処理が終了した場合も、ＣＰＵコア３１１は、スリープ処理を行う（Ｓ４０９０）。

ステップＳ４０９０においてＣＰＵコア３１１がスリープする時間は、ここでは一例として１０秒である。ただし、実施形態がそれに限定されることはない。他の例として、１秒でも１分でもよい。または、スリープ時間は可変であってもよい。

次にＣＰＵコア３１１は、ステップＳ４０９０のスリープ完了後、ステップＳ４０１０に戻り、再びステップＳ４０００からＳ４０９０まで処理を繰り返し実行する。

本実施形態のように、ストレージ処理をＯＳカーネル６１０の一部ではなくＯＳ６００上で動作するプログラムにすると、ストレージプログラム７００の可搬性が向上し、開発効率が高まる一方で、ストレージプログラム７００はＯＳ６００とは別個独立に動作することとなり、ストレージプログラム７００からＯＳカーネル６１０への通信が増大する。そこで、本実施形態では、通信データの消失を抑えかつ効率よく処理するために、ＯＳカーネル６１０からストレージプログラムへの方向だけでなく、ストレージプログラム７００からＯＳカーネル６１０への方向にも待ち行列を保持するキューを配置する。両方向にキューを用いることにより、高いスループット性能を実現することができる。

ストレージプログラム７００からＯＳカーネル６１０への通信は、その前に発生したＯＳカーネル６１０からストレージプログラム７００へ要求を伝達する通信に対する応答であるため、どちらか一方の通信のスループットが低下すれば、それがボトルネックとなってストレージ処理全体のスループットが低下してしまう。しかし、本実施形態では、両方向にキューを用いているので、ストレージ処理全体を高いスループットに維持することが可能である。

また、ストレージプログラム７００からＯＳカーネル６１０への通信は、その前に発生したＯＳカーネル６１０からストレージプログラム７００へ要求を伝達する通信に対する応答であるため、本実施形態では更に、ＯＳカーネル６１０からストレージプログラム７００への通信データを保持するキューとストレージプログラムからＯＳカーネル６１０への通信データを保持するキューをペアにし、それらの個数を連動するように制御することにより、制御を効率化している。

図１９は、キューペア監視プログラム１７００におけるキューペア増加処理（Ｓ４０６０）のフローチャートである。ＣＰＵコア３１１は、キューペア監視プログラム１７００から呼び出された場合、図１９に示す処理を開始する（Ｓ４２００）。

ＣＰＵコア３１１は、まず、ポリシ管理表１６００における各行に示された上限値のうちで最小のものを算出する。このとき、行１６７０（キューペア使用メモリ量）については、行１６７０（キューペア使用メモリ量）の上限値をキューペア管理表１５００の先頭行のキューサイズの２倍で割った商を求めることにより、上限値をキューペア数に換算する。

ステップＳ４２１０では、そのキューペア数に換算したキューペア使用メモリ量の上限値を他の行１６４０、１６５０、１６６０の上限値と比較する。そして、ＣＰＵコア３１１は、算出した上限値の最小値と、キューペア管理表１５００の行数で表わされる現在のキューペア数との差分を算出し、その差分をキューペアの増加数とする。

次にＣＰＵコア３１１は、Ｓ４２１０で算出したキューペア増加数とキューサイズの積と、キャッシュ管理表９００の空き容量とを比較し、空き容量が、キューペア増加分の総キューサイズを上回っているかどうかを判定する（Ｓ４２２０）。

ステップＳ４２２０の判定において、空き容量が、キューペア増加分の総キューサイズを上回っている場合（Ｓ４２２０：ＹＥＳ）、ＣＰＵコア３１１は、キャッシュ管理表９００の空き容量をキューペア増加分だけ減らした値に更新する（Ｓ４２３０）。空き容量が、キューペア増加分の総キューサイズを下回っている場合（Ｓ４２２０：ＮＯ）、ＣＰＵコア３１１は、キャッシュ操作処理を実施し（Ｓ４２７０）、キャッシュ８００の空き容量を増加させる。

次にＣＰＵコア３１１は、Ｓ４２１０で算出した、キューペアの増加数だけキューペアを作成する（Ｓ４２４０）。

次にＣＰＵコア３１１は、追加したキューペアの情報でキューペア管理表１５００を更新する（Ｓ４２５０）。

次にＣＰＵコア３１１は、プロセス管理表１３００に追加したキューペアのＩＤを追加する（Ｓ４２６０）。ステップＳ４２６０の処理が完了したら、ＣＰＵコア３１１はキューペア増加処理を終了する。

以上のように、ＣＰＵコア３１１は、キューペアを増加するとき、資源の使用量の上限量をキューペアの個数の上限数と互いに比較が可能なように変換する。更に、ＣＰＵコア３１１は、上限量を変換した上限数とキューペアの個数の上限数のうちの最小の上限数を求める。さらに、ＣＰＵコア３１１は、求めた上限数と現在のキューペアの個数との差分をキューペアの増加数と決定する。これにより、資源の使用量の上限量を上限数と比較できるように個数で表わした上限数に変換するので、個数による比較的容易な演算により、各値を制限の範囲内に維持しつつキューペアの個数を適切な個数に増加させることができる。

図２０は、キューペア監視プログラム１７００におけるキューペア削減処理（Ｓ４０８０）のフローチャートである。ＣＰＵコア３１１は、キューペア監視プログラム１７００から呼び出された場合に、図２０の処理を開始する（Ｓ４４００）。

ＣＰＵコア３１１は、ポリシ管理表１６００の各行の上限値のうちで、最小のものを算出する（Ｓ４４１０）。このとき、行１６７０（キューペア使用メモリ量）については、行１６７０（キューペア使用メモリ量）の上限値をキューペア管理表１５００の先頭行のキューサイズの２倍で割った商を求めることにより、上限値をキューペア数に換算する。ステップＳ４４１０では、そのキューペア数に換算したキューペア使用メモリ量の上限値を他の行１６４０、１６５０、１６６０の各上限値と比較する。そして、ＣＰＵコア３１１は、算出した最小値と現在のキューペア数との差分をキューペアの削減数とする。

次にＣＰＵコア３１１は、キューペア管理表１５００とキャッシュ管理表９００を参照し、キャッシュ８００の領域に最も近い側から順に、キューペア削減数分だけキューペアを選択する（Ｓ４４２０）。

なお、本実施形態では、共有メモリ４００が複数個ある場合、ＣＰＵコア３１１は、キューペアを作成するとき、可能であれば、キャッシュ８００が配置されているものと同じ共有メモリ４００にキューペアを配置することとする。そして、このステップＳ４４２０においては、ＣＰＵコア３１１は、キャッシュ８００が配置されているのと同じ共有メモリ４００に配置されているキューペアを選択するようにする。

次にＣＰＵコア３１１は、ステップＳ４４２０で選択したキューペアについて、キューペア管理表１５００の操作可否１５４５の設定を更新し、キューペアの操作を禁止する（Ｓ４４３０）。

次にＣＰＵコア３１１は、選択したキューペア内に存在するエントリを他のキューペアへ移動させる（Ｓ４４４０）。選択したキューペアが空になると、次にＣＰＵコア３１１は、選択したキューペアを削除する（Ｓ４４５０）。次にＣＰＵコア３１１は、削除したキューペアに関する情報をキューペア管理表１５００から削除する（Ｓ４４６０）。次にＣＰＵコア３１１は、プロセス管理表１３００のキューペアＩＤ１３２０から、削除したキューペアのＩＤを削除する（Ｓ４４７０）。

最後にＣＰＵコア３１１は、キャッシュ管理表９００の空き容量の情報を更新して処理を終了する（Ｓ４４８０）。

上述したように、共有メモリ４００上にキャッシュ８００が配置されている場合、ＣＰＵコア３１１は、キューペアを削除するとき、キャッシュ８００の領域に最も近いキューペアを削除する。これによれば、キューペアを削除するときにキャッシュ８００の領域に最も近いキューペアを削除するので、キューペア削除でできる空き領域を効率よくキャッシュ８００に利用できる位置に作成することができる。

また、ＣＰＵコア３１１は、キューペアを削減するとき、資源の使用量の上限量をキューペアの個数の上限数と互いに比較が可能なように変換する。さらに、ＣＰＵコア３１１は、その上限量を変換した上限数と前記キューペアの個数の上限数のうちの最小の上限数を求める。さらにＣＰＵコア３１１は、求めた上限数と現在のキューペアの個数との差分をキューペアの削減数と決定する。資源の使用量の上限量を上限数と比較できるように個数に変換するので、個数による比較的容易な演算により、各値を制限の範囲内に維持しつつキューペアの個数を適切に削減することができる。

図２１は、システム設定を管理するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の一例を示す図である。管理端末２４０が有するＣＰＵで実行される管理プログラムは、システム設定を行うためのＧＵＩ１９００をシステム管理者に提供する。システム管理者は、ＧＵＩ１９００を用いてサーバ２００へシステム設定に関する指示を入力する。

ＧＵＩ１９００は、キューペア数増減ポリシを設定するためのＧＵＩであり、キューペア数増減ポリシ設定部１９１０、更新ボタン１９３０、キャンセルボタン１９４０を含む。

キューペア数増減ポリシ設定部１９１０は、サーバ２００に格納しているポリシ管理表１６００の情報を表示するため、あるいはサーバ２００に格納するポリシ管理表１６００の情報をシステム管理者に設定させるための部位である。ポリシ項目１６１０で示された、ストレージプログラムが処理するキューペア数、ＦＣポート数、Ｅｔｈｅｒｎｅｔポート数、およびキューペア使用メモリ量について、上限１６２０と下限１６３０には、現在設定されている値が表示され、かつその値が編集可能となっている。ポリシ項目１６１０とその上限１６２０及び下限１６３０のそれぞれの意味はポリシ管理表１６００におけるそれぞれの意味と同じである。

システム管理者が、キューペア数増減ポリシ設定部１９１０を編集し、更新ボタン１９３０を押すと、管理端末２４０からサーバ２００へ更新内容が通知される。更新内容を受け取ったサーバ２００は、受け取った更新内容に従って、ポリシ管理表１６００の内容を更新する。

システム管理者がキャンセルボタン１９４０を押すと、管理端末２４０は、システム設定を終了し、ＧＵＩ１９００を閉じる。

以上、本発明の実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲を上記構成に限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

１０ 計算機システム、２００ サーバ、２１０ ホスト、２２０ ネットワーク、２４０ 管理端末、３１０ ＣＰＵ、３１１ ＣＰＵコア、３２０ メモリ、３３１ ＨＢＡ、３３２ ＮＩＣ、３４０ 論理ボリューム、３５１ ＳＳＤ、３５２ ＨＤＤ、３６０ ディスク装置、４００ 共有メモリ、４１０ Ｉｎｉｔｉａｔｏｒ−Ｔａｒｇｅｔキュー（ＩＴＱ）、４２０ Ｔａｒｇｅｔ−Ｉｎｉｔｉａｔｏｒキュー（ＴＩＱ）、５００ 通信ドライバプログラム、６００ ＯＳ、６１０ ＯＳカーネル、６２０ Ｉ／Ｏ要求受信プログラム、６４０ Ｉ／Ｏ応答送信プログラム、７００ ストレージプログラム、８００ キャッシュ、９００ キャッシュ管理表、１０００ ボリューム管理表、１３００ プロセス管理表、１４００ 資源管理表、１５００ キューペア管理表、１６００ ポリシ管理表、１７００ キューペア監視プログラム

Claims (13)

1. オペレーティングシステムと、前記オペレーティングシステム上で動作しホストに論理ボリュームを提供するストレージプログラムと、を実行するプロセッサと、
   前記オペレーティングシステムと前記ストレージプログラムとの通信データを保持するキューと、前記ストレージプログラムが提供する前記論理ボリュームに適用されるストレージ機能の情報を含むボリューム管理情報と、を有するメモリと、を備え、
   前記オペレーティングシステムは、前記ホストから前記論理ボリュームに対するＩ／Ｏ要求を受信した場合、前記ボリューム管理情報を参照して、前記Ｉ／Ｏ要求の対象となる前記論理ボリュームに適用されるストレージ機能の情報に基づいて、前記ストレージプログラムによる前記Ｉ／Ｏ要求の処理が必要か否かを判定し、必要と判定した場合、前記キューを介して前記ストレージプログラムと通信し、
   前記ストレージプログラムは、前記Ｉ／Ｏ要求に基づく処理を実行し、
   前記オペレーティングシステムは、前記ストレージプログラムによる前記Ｉ／Ｏ要求の処理が必要でないと判定した場合、前記ホストへ前記Ｉ／Ｏ要求に対する応答を実行する、
   計算機システム。
2. 前記メモリは、前記論理ボリュームのデータを一時的に格納するキャッシュと、前記キャッシュ上のデータを管理するキャッシュ管理情報と、を有し、
   前記プロセッサにより実行される前記オペレーティングシステムは、前記ホストから前記論理ボリュームに対するライト要求を受信した場合、前記キューを介して前記ストレージプログラムと通信し、
   前記プロセッサにより実行される前記ストレージプログラムは、前記ライト要求に基づく処理を実行し、
   前記オペレーティングシステムは、前記ホストから前記論理ボリュームに対するリード要求を受信した場合、前記キャッシュ管理情報を参照して、前記キャッシュ上に前記リード要求に対応するデータが存在すると判定したとき、前記キャッシュ上に存在するデータに基づき、前記ホストへ前記リード要求に対する応答を実行する、
   請求項１に記載の計算機システム。
3. 前記プロセッサにより実行される前記オペレーティングシステムは、前記リード要求の対象となる前記論理ボリュームのアドレス範囲を対象とするライト要求が、前記キューに存在する場合、前記キューを介して前記ストレージプログラムと通信し、
   前記プロセッサにより実行される前記ストレージプログラムは、前記リード要求に基づく処理を実行し、
   前記オペレーティングシステムは、前記リード要求の対象となる前記論理ボリュームのアドレス範囲を対象とするライト要求が、前記キューに存在しない場合、前記リード要求に対する前記応答を実行する、
   請求項２に記載の計算機システム。
4. 前記プロセッサは、前記オペレーティングシステムから前記ストレージプログラムへの通信データを保持する第１キューと、前記ストレージプログラムから前記オペレーティングシステムへの通信データを保持する第２キューとを対として用い、前記第１キューと前記第２キューの対であるキューペアの個数を制御する、
   請求項３に記載の計算機システム。
5. 前記プロセッサは、前記ストレージプログラムのプロセスの個数に応じて、前記キューペアの個数を制御する、
   請求項４に記載の計算機システム。
6. 前記プロセッサは、前記キューペアに関連する資源の使用量に基づいて、前記キューペアの個数を制御する、
   請求項４に記載の計算機システム。
7. 前記ストレージプログラムと前記オペレーティングシステムが共有する前記メモリの領域上に前記キャッシュ及び前記キューペアが配置され、
   前記プロセッサは、前記キューペアを削除するとき、前記キャッシュの領域に最も近いキューペアを削除する、
   請求項４に記載の計算機システム。
8. 前記キューペアの個数には上限数と下限数が定められ、
   前記プロセッサは、前記キューペアの個数が前記下限数を下回ったら前記キューペアを増加させ、前記キューペアの個数が前記上限数を超えたら前記キューペアを削減する、
   請求項４に記載の計算機システム。
9. 前記資源の使用量には上限量が設定されており、
   前記プロセッサは、キューペアを増加するとき、前記資源の使用量の前記上限量を前記キューペアの個数の上限数と互いに比較が可能なように変換し、前記上限量を変換した上限数と前記キューペアの個数の上限数のうちの最小の上限数を求め、求めた前記上限数と現在の前記キューペアの個数との差分を前記キューペアの増加数と決定する、
   請求項６に記載の計算機システム。
10. 前記資源の使用量には上限量が設定されており、
    前記プロセッサは、キューペアを削減するとき、前記資源の使用量の上限量を前記キューペアの個数の上限数と互いに比較が可能なように変換し、前記上限量を変換した上限数と前記キューペアの個数の上限数のうちの最小の上限数を求め、求めた前記上限数と現在の前記キューペアの個数との差分を前記キューペアの削減数と決定する、
    請求項６に記載の計算機システム。
11. 前記プロセッサは、前記キューペアの個数の制御に用いるポリシを表わすキューペア増減ポリシ管理情報を画面表示し入力操作により更新する管理計算機から、該キューペア増減ポリシ管理情報を取得し、該キューペア増減ポリシ管理情報を参照して前記キューペアの個数を制御する、
    請求項４に記載の計算機システム。
12. オペレーティングシステムと、前記オペレーティングシステム上で動作しホストに論理ボリュームを提供するストレージプログラムと、を実行するプロセッサと、
    前記オペレーティングシステムと前記ストレージプログラムとの通信データを保持するキューと、前記ストレージプログラムが提供する前記論理ボリュームに適用されるストレージ機能の情報を含むボリューム管理情報と、を有するメモリと、を備え、
    前記オペレーティングシステムは、前記ホストから前記論理ボリュームに対するＩ／Ｏ要求を受信した場合、前記ボリューム管理情報を参照して、前記Ｉ／Ｏ要求の対象となる前記論理ボリュームに適用されるストレージ機能の情報に基づいて、前記ストレージプログラムによる前記Ｉ／Ｏ要求の処理が必要か否かを判定し、必要と判定した場合、前記キューを介して前記ストレージプログラムと通信し、
    前記ストレージプログラムは、前記Ｉ／Ｏ要求に基づく処理を実行し、
    前記オペレーティングシステムは、前記ストレージプログラムによる前記Ｉ／Ｏ要求の処理が必要でないと判定した場合、前記ホストへ前記Ｉ／Ｏ要求に対する応答を実行する、
    計算機。
13. 前記ホストは、前記プロセッサにより実行されるホストプログラムである、
    請求項１２の計算機。
    
    

Images