JP5406363B2 - プール領域の一部の領域を動的にデータ格納領域として割り当てる記憶制御装置及び記憶制御方法 - Google Patents

Description

本発明は、プール領域の一部の領域を動的にデータ格納領域として割り当てる記憶制御技術に関するものである。

記憶制御装置として、プール領域の一部の領域を動的にデータ格納領域として割り当てる装置が知られている。プール領域は、例えば、一以上のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）グループに基づく物理記憶領域であり、例えば、一又は複数の論理ボリュームの集合である。ＲＡＩＤグループは、複数の物理記憶デバイスで構成されており、ＲＡＩＤグループには、所定のＲＡＩＤレベルでデータが格納される。以下の説明では、上記の物理記憶領域を「プール領域」と言う。

プール領域を用いる機能としては、幾つかの種類がある。

例えば、第１種の機能として、動的容量拡張がある。具体的には、例えば、ホスト装置に提供された論理ボリューム（仮想ボリューム）にホストからのライトが発生するなど、実際にデータ格納領域が必要となった場合に、プール領域の一部の領域が、データ格納領域として割当てられる。

また、例えば、第２種の機能として、スナップショット管理がある。具体的には、例えば、或る時点の論理ボリュームのイメージを保持し、保持したイメージと現状のイメージとの差分に相当するデータ（差分データ）を格納するための領域が、プール領域から動的に割り当てられる。

特許文献１では、一元管理されたプール領域を複数機能で共有する事で、記憶領域の使用効率を向上する方法が記載されている。

特開２００７−１９３５７３号公報

記憶制御装置内の各部位の制御や、機能を実現するプログラムの実行は、ＣＰＵで実行される。記憶制御装置内に複数のＣＰＵ（Central Processing Unit）を備える、もしくは、ＣＰＵ内部に複数のＣＰＵコアが搭載されている事により、装置内に複数のＣＰＵコアを備える記憶制御装置がある。

装置内に複数のＣＰＵコアを備える記憶制御装置では、ＣＰＵコア間で同一の物理的、論理的リソースにアクセスする際に、他コアの処理を排他する必要があるが、排他論理によるオーバヘッドによって、処理能力の低下が発生する。特に、ホストに提供する論理ボリュームを複数のＣＰＵコアで使用する場合、すなわち、同一論理ボリュームに対して同時に複数コアが処理を実施する可能性がある場合には、同一論理アドレスに対するアクセスや、同一冗長データを使用する近傍アドレスに対するアクセスなど、複数のＣＰＵコアが無制限に処理を実施する事が不可能なケースがあり、多くの排他処理が発生する。

これらの排他処理によるオーバヘッドを回避するための方法として、アクセスする物理的、論理的リソースを予め特定のＣＰＵコアに割り当てるという方法がある。ホストに提供する論理ボリュームについては、或る論理ボリュームに関する制御権を、或るＣＰＵコアに割り当て、このＣＰＵコアのみで当該論理ボリュームに対する処理を実行する事によって、制御権（言い換えれば所有権）を持つＣＰＵコア以外に対する排他を不要とする事が可能となる。なお、この制御権の単位は、ホスト装置に提供する論理ボリュームの単位であっても良いし、論理ボリュームとは異なる論理記憶領域の単位であっても良い。

しかし、単純にこの方法が採用されると、プール領域を一又は複数の論理ボリュームから構成し各論理ボリューム及びプール領域について制御権を設定した場合、プール領域を使用する機能を実行するＣＰＵコア数分のプール領域が必要となる。このため、或るプール領域では容量が余っていても別のプール領域では容量が枯渇してしまうといった容量効率低下の原因ともなる。この問題は、特に、プール領域を使用する異種の機能が記憶制御装置に混在する場合に、大きいと考えられる。

従って、本発明の目的は、複数のＣＰＵコアの各々が論理記憶領域に関する制御権を持つ記憶制御装置での容量効率の低下を抑えることにある。

複数のＣＰＵコアの各々が、複数種類の論理記憶領域のうちの一種類以上の論理記憶領域の制御権を有する。論理記憶領域に割り当てられる領域のソースとして、複数種類の論理記憶領域に共通とした物理記憶領域が管理される。各ＣＰＵコアは、そのＣＰＵコアが有する制御権に対応した論理記憶領域に対するデータのアクセスの場合、そのデータの格納に必要な領域を共通の物理記憶領域から割り当てる。

複数のＣＰＵコアの各々が論理記憶領域に関する制御権を持つ記憶制御装置での容量効率の低下を抑えることが出来る。

図１は、本発明の実施例１に係る記憶制御装置を含むコンピュータシステムの全体構成図である。 図２は、メモリ１１８は記憶するプログラム及び情報を示す。 図３は、仮想ボリューム実現プログラム２１１によって実現される仮想ボリューム機能の説明図である。 図４は、スナップショット実現プログラム２１２によって実現されるスナップショット機能の説明図である。 図５は、仮想ボリューム機能とスナップショット機能で共通のプールボリュームを使用する方法について説明した図である。 図６は、制御情報２３１の構成を示す。 図７は、プール領域へ格納する情報があふれる可能性が発生した場合に行う処理のシーケンスを示した図である。 図８は、プールあふれ対応処理実行要否のチェックをポーリングで行う場合の処理シーケンスを示した図である。 図９は、ディスク１５１群に対するデータ配置の一例を示す。 図１０は、図９で示したデータ配置の別の観点を示した図である。 図１１は、図１０で示したデータ配置に本実施例に従うデータ管理が適用された図である。 図１２は、実施例２に係る制御情報２３１の一部を示す。 図１３は、プール使用ＬＵ情報１２０１の構成を示す。 図１４は、制御権セット管理情報１２０２の構成を示す。 図１５は、ページ管理情報１２０３の構成を示す。 図１６は、チャンク管理情報１２０４の構成を示す。 図１７は、属性情報１２０５の構成を示す。 図１８は、新規ページ割り当てを実施する際の処理シーケンスを示す。 図１９は、ページの属性変更処理のシーケンスを示す。 図２０は、制御権を移行する処理のシーケンスを示す。 図２１は、プールＬＵを設定するための管理画面２１０１を示す。 図２２は、プール使用ＬＵの設定に用いる管理画面２２０１を示す。 図２３は、ページ割り当て方針を設定するための管理画面２３０１を示す。 図２４は、制御権移行処理を指示するための管理画２４０１を示す。

以下、本発明の一実施例を図面に基づいて説明する。

図１は、本発明の実施例１に係る記憶制御装置を含むコンピュータシステムの全体構成図である。

図１において、コンピュータシステムは、記憶制御装置１０１、ホスト１０２、及び管理ホスト１０３を備える。

ホスト１０２は、記憶制御装置１０１にＩ／Ｏコマンド（ライトコマンド又はリードコマンド）を発行する装置（例えば計算機又は別の記憶制御装置）である。ホスト１０２は、記憶制御装置１０１に接続するための通信ポートを有しており、このポートを介して、接続経路１０４を通り、記憶制御装置１０１に接続される。

管理ホスト１０３は、記憶制御装置１０１を管理する装置（例えば計算機）である。管理ホスト１０３は、管理用接続経路１０５を通り、記憶制御装置１０１に接続される。

図１では、ホスト１０２及び管理ホスト１０３と、記憶制御装置１０１とを直接接続した構成を記載しているが、ホスト１０２と記憶制御装置１０１との接続については、通信ネットワーク（例えばＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ））が利用されてもよい。管理ホスト１０３と記憶制御装置１０１との接続については、通信ネットワーク（例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ））が利用されてもよい。ここで、ＳＡＮとして、Ｆｉｂｒｅ ＣｈａｎｎｅｌやｉＳＣＳＩ等のプロトコルを使用する事が出来る。また、管理ホスト接続については、ホスト接続と同じ接続経路を用いる事も出来る。

記憶制御装置１０１は、コントローラ１１１及び１６１と複数のディスク１５１とを備える。コントローラ１１１及び１６１間は、コントローラ間バス１４１によって接続される。コントローラ１１１及び１６１とディスク１５１とは、ディスク接続経路１４２によって接続される。ディスク１５１としては、ＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）、ＡＴＡ（Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）やＳＳＤ（Ｓｏｌｉｄ ｓｔａｔｅ Ｄｒｉｖｅ）等のＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）を使用することができる。ディスク１５１に代えて、テープやフラッシュメモリなどの他種の物理記憶デバイスが採用されてもよい。

コントローラ１１１及び１６１について、コントローラ１１１を代表的に例に採り説明する。

コントローラ１１１は、ホスト入出力制御部１１２、データ転送制御部１１３、ディスク入出力制御部１１４、キャッシュメモリ１１５、ブリッジ１１６、ＣＰＵ１１７、メモリ１１８、及び管理Ｉ／Ｆ１１９を備える。

ホスト入出力制御部１１２は、インタフェース装置であり、接続経路１０４を通じてホスト１０２に接続され、ホスト１０２との入出力の制御を行う。

データ転送制御部１１３は、例えばハードウェア回路（例えばＬＳＩ）であり、内部バス１３１によってホスト入出力制御部１１２と、内部バス１３２によってディスク入出力制御部１１４と、内部バス１３４によってブリッジ１１６と接続され、コントローラ１１１内のデータ転送を制御する。また、データ転送制御部１１３は、コントローラ１６１と接続され、コントローラ１１１及び１１６間の制御情報通信及びデータ転送を制御する。

ディスク入出力制御部１１４は、インタフェース装置であり、ディスク接続経路１４２によってディスク１５１と接続され、ディスクに対するデータの入出力を制御する。

キャッシュメモリ１１５は、内部バス１３３によってデータ転送制御部１１３と接続され、データ転送に伴い移動するデータを一時的に保持する。

メモリ１１８は、内部バス１３６を介してＣＰＵ１１７と接続される。メモリ１１８は、ＣＰＵ１１７内のコア１２１によって実行されるコンピュータプログラムや、コンピュータプログラムの実行の際に参照される制御情報を記憶する。

ＣＰＵ１１７は、内部バス１３５によってブリッジ１１６と接続される。また、ＣＰＵ１１７は、例えばマルチコアシングルプロセッサ、つまり、複数のコア１２１を有する。もちろん、ＣＰＵ１１７がシングルコアＣＰＵの場合は、複数コアは格納されていないが、ＣＰＵ１１７自体を一つのコアと見なす事が出来る。この場合、複数のＣＰＵ１１７が設けられる。コア１２１は、メモリ１１８に格納されたプログラムに従って各種の演算処理を実行し、処理結果をもとにコントローラ１１１全体の制御を実行する。また、コントローラ１６１内のリソースについても制御を実行する場合がある。

管理Ｉ／Ｆ１１９は、インターフェース装置であり、内部バス１３７によってブリッジ１１６に接続される。また、管理Ｉ／Ｆ１１９は、管理用接続経路１０５を介して、管理ホスト１０３に接続されており、管理ホスト１０３とのデータの授受や通信の制御を行う。

記憶制御装置１０１の構成は、図１の構成に限らない。例えば、ＣＰＵ１１７とブリッジ１１６が一体となったチップや、ＣＰＵ１１７とデータ転送制御部１１３が一体となったチップや、少なくとも一つのインターフェース装置とＣＰＵ１１７が一体となったチップを用いた構成が採用されてもよい。また、キャッシュメモリ１１５とメモリ１１８を同一メモリで実現した構成が採用されてもよい。

図２は、メモリ１１８は記憶するプログラム及び情報を示す。なお、以下の説明においてプログラムが行う処理は、実際には、プログラムを実行するコアによって実行される。

メモリ１１８に格納されている情報の多くはＣＰＵ１１７の処理に使用されるが、ＣＰＵ以外の各部位とのＩ／Ｆに使用する場合もある。図２には明示していないが、例えば、ホスト入出力制御部１１２が行うべき処理を定義した情報をメモリ１１８に格納し、ホスト入出力制御部１１２はその情報を確認した後処理を行い、処理の結果をメモリ１１８上に記録する等の使用方法がある。また、ＣＰＵ１１７の処理に使用する情報は、ＣＰＵ１１７内部の全てのコア１２１向けであったり、特定のコア１２１向けの情報であったりする。図２では、説明の簡単化のため、全ての情報をコア間で共有するような記載としている。しかし、コア間の排他処理に伴うオーバヘッドを削減する目的で、コア毎にアクセスする領域を固定とするため、例えば制御情報２３１を分割するような構成も採用可能である。

メモリ１１８は、オペレーティングシステム２０１、ディスクアレイ制御プログラム２０２、データ転送制御プログラム２０３、入出力制御部制御プログラム２０４、仮想ボリューム実現プログラム２１１、スナップショット実現プログラム２１２、プール管理プログラム２２１、プールあふれ監視プログラム２２２、データ消去プログラム２２３、データコピー／移動プログラム２２４、ページ割り当て／解放プログラム２２５、チャンク割り当て／開放プログラム２２６、制御権移行プログラム２２７、及び制御情報２３１を記憶する。

オペレーティングプログラム２０１は、ＣＰＵ１１７及びコア１２１が各プログラムを実行する際のスケジューリング等の基本処理を行うプログラムである。

ディスクアレイ制御プログラム２０２は、ホストへ提供する論理ボリュームの管理や、ディスク１５１への入出力位置演算など、記憶制御装置全体の制御に用いるプログラムである。

データ転送制御部制御プログラム２０３は、データ転送制御部１１３の制御に用いるプログラムである。

入出力制御部制御プログラム２０４は、ホスト入出力制御部１１２、ディスク入出力制御部１１４の制御に用いるプログラムである。

仮想ボリューム実現プログラム２１１は、仮想ボリューム機能（例えば、Thin Provisioningに従う容量仮想化）を実現するためのプログラムである。仮想ボリューム機能とは、ホスト１０２に対して提供する論理ボリュームのデータ領域を記憶制御装置内のプール領域から動的に確保する機能である。

スナップショット実現プログラム２１２は、スナップショット機能を実現するためのプログラムである。ここでいうスナップショット機能とは、記憶制御装置内の論理ボリュームの或る時点でのイメージを取得及び保持する機能である。スナップショット機能には、複数の実現形態があるが、以下では、複数のスナップショットイメージ及び現時点の論理ボリュームが、同一のデータを共有する形態であるものとする。図２では、仮想ボリューム機能及びスナップショット機能を実現するプログラムのみを記載しているが、もちろん、これ以外にも後述のプール領域を使用する複数種類の機能があってもよい。このような機能の例としては、重複排除機能がある。重複排除機能とは、一又は複数の論理ボリューム間で同一内容のデータを共有し実際のデータをプール領域に格納する機能である。

プール管理プログラム２２１は、プール領域を管理するためのプログラムである。プール領域は、前述の仮想ボリューム機能やスナップショット機能で用いられる、データを実際に格納する領域である。

プールあふれ監視プログラム２２２は、プール領域に予め定められたサイズ以上のデータを格納しようとしていないか、もしくはそのような可能性が高い状況になっていないかを監視するプログラムである。

データ消去プログラム２２３は、プールあふれからの解消を行う場合などに、格納済みのデータ及び関連する管理情報を消去する際に用いるプログラムである。

データコピー／移動プログラム２２４は、主にプール領域を使用しているデータに関して、格納済みのデータを別の位置にコピーしたり、移動したりする際に用いるプログラムである。

ページ割り当て／開放プログラム２２５は、ページ単位で領域を確保したり解放したりするためのプログラムである。「ページ」とは、プール領域の一部の領域であり、ページ単位とは、プール領域を使用する機能が使用する管理単位である。

チャンク割り当て／開放プログラム２２６は、チャンク単位で領域を確保したり解放したりするためのプログラムである。「チャンク」とは、複数のページで構成された記憶領域であり、プール領域の一部の領域である。

制御権移行プログラム２２７は、あるコア１２１に対して割り当てられた制御権を別のコアに移行する際に使用するプログラムである。

制御情報２３１は。コア１２１が各種プログラムを実行する上で必要となる、各物理的リソース及び論理的リソースの状態や、設定が格納されている。

図３は、仮想ボリューム実現プログラム２１１によって実現される仮想ボリューム機能の説明図である。

記憶制御装置１０１は、ホスト１０２に対して論理ボリュームを提供する。この論理ボリュームは、ホスト向けボリューム３０１である。ホスト向けボリューム３０１の中に、通常ボリューム３１１、仮想ボリュームＡ３１２、仮想ボリュームＢ３１３があり、ホスト１０２はこれらのボリュームにアクセスする。

通常ボリューム３１１は、ディスク１５１を用いて構成された、実際にデータを格納する領域である実データ領域Ａ３３１と同等のサイズであり、一対一に結び付けられている。このため、通常ボリューム３１１内の領域ａ３４１に対するホスト１０２からのアクセスは、そのまま実データ領域３３１内の該当領域ａ３６１に対するアクセスとなる。

一方、仮想ボリュームＡ３１２は、仮想ボリューム機能を用いて構成される論理ボリュームである。仮想ボリュームＡ３１２は、ボリューム作成時には実際のデータ及びデータ格納領域が割り当てられていない。仮想ボリュームＡ３１２に対するホスト１０２からのアクセス、特にライトアクセスが発生した場合に、実際のデータ格納領域の一部領域が割り当てられる。データ格納領域の割り当ては、仮想プールボリューム（仮想ボリューム機能向けプールボリューム）３２１の一部を用いて実行される。仮想プールボリューム３２１は、ディスク１５１から構成される、実データ領域Ｂ３３２と同等のサイズであり、一対一に結び付けられている。よって、仮想ボリュームＡ３１２内のある領域ｂ３４２に対するアクセスは、まず仮想プールボリューム３２１内の領域ｂ３５２へのアクセスに変換される。このときの領域ｂ３４２へのアクセスが、仮想ボリュームＡ３１２を作成してから初めてのアクセスだった場合には、仮想プールボリューム３２１内の領域ｂ３５２を新たに割り当てる処理が実行される。さらに、実際にデータを格納する領域は、実データ領域Ｂ３３２内の領域ｂ３６２となる。

また、仮想ボリュームＢ３１３も仮想ボリュームＡ３１２と同様に仮想ボリューム機能を用いて構成される論理ボリュームである。仮想ボリュームＢ３１３内の領域ｃ３４３は、仮想プールボリューム３２１内の領域ｃ３５３に対応しており、実データ領域３３２内の領域ｃ３６３へと対応している。すなわち、仮想ボリュームＡ３１２と仮想ボリュームＢ３１３は、同一の仮想ボリューム機能向けプールボリューム３２１を使用する事が可能である。

仮想ボリューム機能によって実現される効果として、例えば、ホストに提供される論理ボリュームのサイズ設計が不要となるという効果がある。ホストが使用する論理ボリュームが必要とするサイズは、将来どのように変化していくかを予測する事は困難であるため、予め大きなサイズの論理ボリュームを作成しておくという方法が有効である。しかし、この論理ボリュームを通常ボリュームとして作成すると、大きな記憶領域が使用されないまま確保されているという状況が生じ得る。このため、大きなサイズの論理ボリュームを仮想ボリュームとして作成しておき、実際にホストからのアクセスがあった場合のみ、実データ領域を割り当てていくという方法が好ましい。

このような目的で仮想ボリューム機能を用いる場合、仮想ボリュームの合計サイズと、仮想プールボリュームの合計サイズが一致している必要は無い。例えば、仮想プールボリュームのサイズの方が小さくてよい。例えば図３の例では、仮想ボリュームＡ３１２と仮想ボリュームＢ３１３がそれぞれ１００ＴＢで、仮想プールボリューム３２１のサイズが２０ＴＢだった場合であっても、実際にホスト１０２が使用するサイズが、仮想プールボリューム３２１のサイズ以下であれば、運用可能である。

図４は、スナップショット実現プログラム２１２によって実現されるスナップショット機能の説明図である。

スナップショット機能とは、記憶制御装置１０１がホスト１０２に提供する論理ボリュームの或る時点でのイメージを取得及び保持する機能の事であるが、本実施例では、スナップショット機能とは、前述したように、スナップショットイメージとスナップショットのベースとなるボリュームとの間、及び、スナップショット間で共通するデータについては、同一領域を参照するような機能のことである。

記憶制御装置１０１は、ホスト１０２に対して、ホスト向けボリューム３０１として、スナップショットベースボリューム４１１と、スナップショットボリュームＡ４１２と、スナップショットボリュームＢ４１３とを提供している。

スナップショットベースボリューム４１１は、図３に示したような仮想ボリュームであってもよいが、ここでは通常ボリュームとする。スナップショットベースボリューム４１１は、ディスク１５１から構成される実データ領域４３１と結び付けられており、ボリューム上の領域ａ４４１は、実データ領域上の領域ａ４６１に相当する。

スナップショットボリュームＡ４１２は、スナップショットベースボリューム４１１のある時点の状態を保持したものである。スナップショットボリュームＡ４１２内のある領域ａ４４２は、スナップショットベースボリューム４１１内の領域ａ４４１と同等のデータを指し示す。このため、スナップショットボリュームＡ４１２内の領域ａ４４２に対応するデータは、スナップショットベースボリューム４１１内の領域ａ４４１、すなわち実データ領域４３１内の領域ａ４６１に格納されており、スナップショットベースボリューム４１１と共有している。

スナップショットボリュームＡ４１２内の、スナップショットベースボリューム４１１とは異なるデータとして、領域ｂ４４３内のデータを例として挙げる。領域ｂ４４３内のデータは、スナップショットベースボリューム４１１とは異なる、スナップショットボリュームＡ４１２のみが持つデータとする。これは、スナップショットボリュームＡ４１２取得後に、スナップショットベースボリューム４１１の領域ｂ４４３に相当する領域に対して更新が行われた場合や、スナップショットボリュームＡ４１２の領域ｂ４４３に対して、直接更新が行われた場合に相当する。領域ｂ４４３内のデータ等、スナップショットベースボリュームとの差異が発生した場合のデータは、スナッププールボリューム（スナップショット向けプールボリューム）４２１に格納される。領域ｂ４４３内のデータは、スナッププールボリューム４２１内の領域ｂ４５３内のデータに対応し、実際は、ディスク１５１から構成される実データ領域Ｂ４３２内の領域ｂ４６３に格納される。

スナップショットボリュームＢ４１３も同様であり、差分が発生した領域ｃ４４４のデータは、スナッププールボリューム４２１内の領域ｃ４５４が対応し、実際のデータは、実データ領域Ｂ４３２内の領域ｃ４６４に格納される。

領域ｂ４４３内のデータと領域ｃ４４４内のデータは、それぞれ異なるスナップショットボリューム内のデータであるが、同一のスナッププールボリューム４２１に格納する事が可能である。

また、スナップショット取得後のスナップショットベースボリュームやスナップショットボリュームに対するライトアクセスによって、差分データは増加していくが、この増加する度合い（差分データの増加速度）を事前に予想する事は困難である。

差分データは、スナッププールボリューム４２１のようにプールボリュームという形で動的に領域を割り当てていく事によって、前述のように、異なるスナップショットボリュームのデータを格納する事や、差分データの増加傾向を厳密に予想する事無くスナップショット機能を運用していく事が可能となる。

以上が、スナップショット機能に関する説明である。

図５は、仮想ボリューム機能とスナップショット機能で共通のプールボリュームを使用する方法について説明した図である。

ホスト１０２に提供されるホスト向けボリューム３０１として、仮想ボリューム５１１、スナップショットボリューム５１２、スナップショットベースボリューム５１３がある。

仮想ボリューム５１１は、仮想プールボリューム（仮想ボリューム機能向けプールボリューム）５３１を使用し、実データ領域Ａ５４１に実際のデータを格納する。スナップショットベースボリューム５１３は、実データ領域Ｂ５４２に実際のデータを格納する、通常ボリュームである。もちろん、前述の通り、スナップショットベースボリューム５１３は仮想ボリュームであってもよい。

スナップショットボリューム５１２は、スナップショットベースボリューム５１３の或る時点のボリュームイメージを保持したものである。スナップショットボリューム５１２内の領域ｂ５５２については、スナップショットベースボリューム５１３内の領域ｂ５５３を指し示しており、実際のデータは実データ領域５４２内の領域ｂ５８３に格納されている。すなわち、図４の場合と同じく、ベースボリュームとの共通データについては、同一データを指し示している。

スナップショットボリューム５１２内の、ベースボリュームと差異が発生した領域として、領域ｃ５５４がある。この領域ｃ５５４のデータは、スナップショット向けプールボリュームに格納するが、本実施例では、このプールボリュームを、仮想ボリューム機能にて実現し、スナップショット向け仮想プールボリューム５２１とする。このスナップショット向け仮想プールボリューム５２１は、仮想プールボリューム５３１を、そのプール領域として使用する。スナップショット領域ｃ５５４は、スナップショット向け仮想プールボリューム５２１内の領域ｃ５６４に相当し、さらに仮想ボリューム機能によって、仮想プールボリューム５３１内の領域ｃ５７４に相当し、最終的な実データは、実データ領域Ａ５４１内の領域ｃ５８４に格納される。

この方式によって、仮想プールボリュームと、その他の機能向けのプールボリューム（本獅子形態では、スナッププールボリューム）を同一のボリュームとする事が可能となる。すなわち、プールを使用する各種機能が使用するプールを単一のプールとする事が可能となる。複数種類の機能による単一プールでは、複数の仮想ボリュームが単一のプールを使用する場合や、複数のスナップショットボリュームが単一のプールを使用する場合と同様に、複数プールボリュームに比べてプールボリュームの容量効率を高める事が可能となる。また、この方式によれば、スナップショット向け仮想プールボリューム５２１の容量は、実際に記憶制御装置が備える実データ領域Ａ５４１の容量とは無関係となるため、スナップショット機能向けのプール領域に関する容量設計が不要となる。

さらに、記憶制御装置が論理ボリュームに制御権を設定し、ある論理ボリュームに関する処理はあるコア１２１が担当するような制御を実施している場合には、仮想ボリューム機能の階層で、制御権に関する処理が実行できていればよい。すなわち、仮想プールボリューム５３１を、異なる複数のコアから使用可能な状態となっていれば、ホスト向けボリューム３０１に含まれるボリュームの制御権の状態に関わらず、共通したプールボリュームを使用可能となる。この仮想ボリューム機能の階層で、制御権に関する処理を行う方式については、後述のチャンク方式がある。

図６は、制御情報２３１の構成を示す。

同図には、制御情報２３１のうち、複数機能が同一のプールを使用する場合に必要となるものを記載している。また、本実施例では、プール領域として論理ボリュームを使用する事を想定しているため、制御情報に含まれる各種情報は、ＬＵ（Logical Unit）単位の情報としている。制御情報２３１には、プールＬＵ情報６０１とプール使用ＬＵ情報６０２が含まれている。

プールＬＵ情報６０１には、プールＬＵ情報テーブルＴ６０１が格納されている。プールＬＵ情報テーブルＴ６０１には、プールとして使用される論理ボリュームの情報が格納されている。具体的には、例えば、テーブルＴ６０１は、プールとして使用される論理ボリューム（ＬＵ）毎に、プールＬＵ番号（図では「ＰＬＵ」）、用途、種別、使用プールＬＵ番号（図では「ＵＬＵ」）、容量、使用容量、あふれ対応開始閾値（図では「開始閾値」及びあふれ対応終了閾値（図では「終了閾値」）を表す情報を有する。

「プールＬＵ番号」は、プールとして使用する論理ボリュームのＬＵ番号（他種の識別情報でもよい）である。「使用プールＬＵ番号」は、使用中のプールＬＵの番号である。

「用途」は、プールＬＵをどのような機能が使用するのかである。

「種別」は、各プールＬＵの実現方法として、通常ボリュームと仮想ボリュームのいずれの方法でプールを実現するかである。

プールＬＵ情報テーブルＴ６０１において、プールＬＵ番号５の論理ボリュームは、スナップショット機能向けの通常ボリュームのプールであるため、スナップショット向けプールボリューム４２１に相当する。プールＬＵ番号１３及び１４の論理ボリュームは、スナップショット向けプールであるが、その実現方法が仮想ボリュームのため、スナップショット向け仮想プールボリューム５２１に相当する。また、プールＬＵ番号３の論理ボリュームは、仮想ボリューム向けプールであり、かつ、スナップショット向け仮想プールボリュームのプールとしても使用されている事から、仮想ボリューム機能向けプールボリューム５３１に相当する。

プールＬＵ情報テーブルＴ６０１について、「容量」は、各プール領域（プールＬＵ）の容量を示す。ここで、種別が通常ボリュームであるプールＬＵについては、同等の容量を実際に用意する必要があるが、種別が仮想ボリュームの場合は必ずしもそうではない。例えば、プールＬＵ番号３に関しては、容量が３０ＴＢとなっており、実際に３０ＴＢのディスクを用意する。しかし、共にプールＬＵ番号３を使用するプールＬＵ番号１３，１４については、合計サイズが４０ＴＢとなっているように、実際の容量である３０ＴＢとは無関係に設定可能である。

「使用容量」は、前述の定められた容量に対して、現在どの程度のサイズが実際に割り当てられているか（すなわち、割当て済みの領域の総量）を示す。

「あふれ対応開始閾値」及び「あふれ対応終了閾値」は、あふれ対応処理の開始及び終了の契機としての閾値であり、プールＬＵの容量に対する使用容量の比率の閾値である。例えば、容量が１００ＴＢ、あふれ対応開始閾値が９０％、あふれ対応終了閾値が８０％の場合は、使用容量が９０ＴＢになった場合にあふれ対応処理が開始される。その後、あふれ対応処理によって使用中の容量を低減したり、容量を追加したりする等の対応を行い、使用容量が容量の８０％（容量を増加しなかった場合は８０ＴＢ）以下になると、あふれ対応処理が終了する。

プール使用ＬＵ情報６０２には、プール使用ＬＵ情報テーブルＴ６０２が格納されている。プール使用ＬＵ情報テーブルＴ６０２は、プールＬＵ情報テーブルＴ６０１に記載されている各プールＬＵを実際に使用しているＬＵの情報が格納されている。具体的には、例えば、テーブルＴ６０２は、プールＬＵ情報テーブルＴ６０１に記載されている各プールＬＵを実際に使用しているＬＵ毎に、ＬＵ番号、使用プールＬＵ番号（図ではＰＬＵ）、用途及び優先度を表す情報を有する。

「ＬＵ番号」は、プールＬＵを使用しているＬＵの番号である。

「使用プールＬＵ番号」は、使用中のプールＬＵの番号である。

「用途」は、対象のＬＵがどういった機能のためにプールを使用しているかである。

「優先度」は、あふれ対応処理における処理内容を決定するためのパラメータである。なお、優先度という情報はテーブルＴ１６０２に無くても良く、その場合、用途を基に、優先度に相当する情報が決定されても良い。例えば、後述のあふれ対応処理において、第１の用途のＬＵは第２の用途のＬＵよりも高い優先度であると認識されても良い。

図２１は、プールＬＵを設定するための管理画面２１０１を示す。

本発明の全ての実施例において、「管理画面」とは、管理ホスト１０３に表示される画面である。管理画面２１０１は、プールＬＵ設定部位２１１１、設定ボタン２１１２及びキャンセルボタン２１１３を有する。

プールＬＵ設定部位２１１１には、プールＬＵ選択部位２１２１があり、新規にプールを作成するのか、既存プールの設定を変更するのかの選択ラジオボタンと、対象とするプールＬＵ番号を設定する入力ボックスがある。選択したプールＬＵ番号に対して、種別設定部位２１２２にて、通常ボリュームを使用するのか、仮想ボリュームを使用するのか、仮想ボリュームを使用する場合はどのプールＬＵを使用するのかを選択する。

さらに、プールＬＵ設定部位２１１１には、設定するプールＬＵの用途を選択する部位２１３１、容量を入力する部位２１３２，あふれ対応開始閾値を入力する部位２１３３，あふれ対応終了閾値を入力する部位２１３４がある。

設定ボタン２１１２は、入力された各種情報を反映するためのボタンであり、キャンセルボタン２１１３は、入力された各種情報を破棄するためのボタンである。

本管理画面で設定された各種の情報は、プールＬＵ情報テーブルＴ６０１に反映される。

図２２は、プール使用ＬＵの設定に用いる管理画面２２０１を示す。

管理画面２２０１は、プール使用ＬＵ設定部位２２１１と、設定ボタン２２１２，キャンセルボタン２２１３からなる。

プール使用ＬＵ設定部位には、対象ＬＵ選択部位２２２１があり、本画面で設定対象とするＬＵを選択する。さらに対象ＬＵがプールを使用する際の用途を選択する、用途選択部位２２２２と、対象ＬＵが使用するプールＬＵを選択するプールＬＵ選択部位２２２３と、対象ＬＵの優先度を設定する優先度設定部位２２２４を備える。

設定ボタン２２１２は、入力された各種情報を反映するためのボタンであり、キャンセルボタン２２１３は、入力された各種情報を破棄するためのボタンである。

本管理画面で設定された各種の情報は、プール使用ＬＵ情報テーブルＴ６０２に反映される。

図７は、プール領域へ格納する情報があふれる可能性が発生した場合に行う処理のシーケンスを示した図である。

前述の通り、プール領域を使用する各種機能では、プール領域に割り当てられている実際の容量よりも、大きな容量を設定する事が可能である。これは、容量設計を簡易化するという効果がある反面、実際にプール領域に割り当てられた以上の容量をホスト等から要求される可能性がある事を示している。このため、プール領域へ格納すべき情報が、実際の容量を上回る、もしくは、上回る可能性が高くなる（プール領域の使用率が高くなる）という場合がある。

図７が示すプールあふれ対応処理は、上記のような状況で、あふれを回避するために実行する処理であるが、本実施例では、プール内に存在するデータの内、削除可能なデータを削除する処理を対象とする。削除処理以外には、記憶制御装置内の空き領域や、容量に余裕のある他のプール領域から、ディスク領域を追加に割り当て、プールの容量自体を大きくする事で容量使用率を下げる方法や、ユーザに対して当該プールへの容量追加を促す等の処理がある。

まず、プールあふれに関連する処理が開始され（Ｓ７０１）、あふれ対応処理が発生する可能性のある処理が実行される（Ｓ７０２）。あふれ対応処理が発生する契機は、或るプールの使用率が、そのプールに対応したあふれ対応開始閾値を上回る事である。よって、Ｓ７０２では、例えば、或るプールから新たに領域を割り当てる処理（或るプールの使用容量が増加する処理）や、或るプールに割り当てられている実データ領域が取り除かれる処理（プール容量が低減される処理）が行われる。

次に、プールあふれ監視プログラム２２２が、処理対象としているプールであふれ対応処理が必要かどうかを判断する（Ｓ７０３）。これは、Ｓ７０２によって、例えば使用容量が増加した場合においても、あふれ対応開始閾値を下回っていれば、プールあふれ対応処理を行う必要は無い。そのため、Ｓ７０３で、閾値をチェックする。あふれ対応処理が不要な場合は、あふれ対応処理を行うことなく、プールあふれ関連処理は終了する（Ｓ７３１）。

あふれ対応処理が必要となった場合は、プールあふれ監視プログラム２２２が、処理中のプールを使用しているＬＵ群を抽出する（Ｓ７１１）。ここでは、プールＬＵ情報テーブルＴ６０１と、プール使用ＬＵ情報テーブルＴ６０２が参照される。プールＬＵ番号３のプールボリュームがあふれる可能性がある場合には、プール使用ＬＵ情報テーブルＴ６０２から、プールＬＵ番号３を使用しているＬＵとして、ＬＵ番号２，１１が対象となる事が分かる。さらに、プールＬＵ情報テーブルＴ６０１から、プールＬＵ番号３は、プールＬＵ番号１３，１４も使用している事が分かり、これらのプールＬＵ番号１３，１４を使用しているＬＵ番号２０，３５，５２も、Ｓ７１１における、処理中のプールを使用するＬＵ群である事がわかる。

次に、抽出したＬＵ群に関して、プールあふれ監視プログラム２２２が、各ＬＵの優先度を解析する（Ｓ７１２）。各ＬＵの優先度は、プール使用ＬＵ情報テーブルＴ６０２から得られる。ここ、で参照する優先度とその解釈の方法は幾つか考えられる。

以下、優先度とその解釈の一例を挙げる。優先度Ａ，Ｂ，ＣのＬＵについては、必ず削除しないものとする。仮想ボリューム機能を用いたボリュームをコンピュータシステムの通常運用で用いているケースでは、システムの継続運用を行う上で、データを削除する事は通常不可能であるため、これらの優先度に設定する事が妥当である。

優先度ＡとＢとＣの差異の例を以下に示す。優先度Ａは、同一のプールを使用するＬＵに削除可能なＬＵがあった場合は、その削除可能なＬＵを削除する。優先度Ｂの場合は、削除可能なＬＵがあった場合であっても、その削除可能なＬＵを削除しない。また、優先度Ｃの場合は、あふれ対応開始閾値を超えている場合には、新規領域割り当てを実行せず、新規領域割り当てを伴う要求を失敗させる。

あふれ対応開始閾値が１００％未満であった場合は、本処理を実行したものの使用率を下げる事が出来なかったとしても、処理の継続が可能である。しかし、プールの使用率が１００％となってしまうと、その後に当該プールを使用するＬＵに対して、プールからの新規領域割り当てを伴う処理要求が発行された場合には、その要求は失敗してしまう。

優先度Ａのボリュームは、このような完全あふれによる要求失敗を出来るだけ発生させないため、他の削除可能なボリューム（ＬＵ）が積極的に削除するという方針のボリュームである。それにより、優先度Ａのボリュームが使用するプールに空き容量が増える、つまり、優先度Ａのボリュームに割当て可能な領域が増える。

優先度Ｂのボリュームについては、自身を削除する事やあふれ処理対応中であっても、新規割り当てを伴う処理要求を失敗させる事による運用への影響は避けるが、その他のボリュームの削除を行うほど優先度が高くはなく、完全なあふれをある程度許容するという方針のボリュームとなる。

優先度Ｃのボリュームは、自身を削除する事は許可できないが、新規割り当てを失敗させる事によって、優先度Ａ，Ｂのボリュームに対する影響を最小限にするという方針のボリュームとなる。

もちろん、本実施例の様な処理を行ったとしても、プールの完全あふれは発生する場合がある。本実施例の処理は、あくまでもプールあふれを発生しにくくする、またあふれが発生する場合であっても、そのボリュームの優先度から、最適なプールボリュームの使用方法を選択するための処理である。

優先度Ｄ以下のボリュームは、あふれ対応処理によって削除可能なボリュームである。例えば、スナップショットボリュームは、削除しても通常のコンピュータシステムの運用には影響を与えない。また、所定の時点間隔（例えば１分おき）にスナップショットボリュームが取得される場合、１０分おきのイメージを残して削除した時には復元可能なイメージが減るものの、システム運用に与える影響は小さくなる。また、古いログを格納している仮想ボリュームなどについても、ログのラップという現象ととらえる事で、削除が可能である。優先度Ｄ以下は、削除可能なボリュームの中から、さらにどのボリュームを削除すべきかを判断するための情報となり、もちろん、優先度が低いものほど削除した場合の影響が小さい事を示す。

Ｓ７１２によって解析した結果を受け、プールあふれ監視プログラム２２２が、抽出したＬＵ群に消去すべきＬＵが存在するかを判断する（Ｓ７１３）。ここでは、例えば、優先度Ｄ以下の削除可能なＬＵが存在しなかったり、優先度ＡのＬＵが存在しなかったりした場合には、消去すべきＬＵは存在しないとなり、プールあふれの対応処理要求があったものの、消去による対応は実施不可という結果であふれ関連処理は終了となる（Ｓ７３１）。

消去すべきＬＵが存在した場合は、プールあふれ監視プログラム２２２が、消去すべきＬＵの中で最低優先度のＬＵの消去を指示する（Ｓ７２１）。Ｓ７２１の指示を受け、データ消去プログラム２２３によって、消去すべきＬＵのデータの消去が実行され、また、処理中のプールの使用容量の低減、使用中ＬＵ情報の削除が実施され、プールＬＵ情報テーブルＴ６０１とプール使用ＬＵ情報テーブルＴ６０２が更新される。

次に、処理中のプールに対して、プールあふれ監視プログラム２２２が、さらに継続してあふれ対応処理が必要か判断を行う（Ｓ７２２）。ここでは、プールＬＵ情報テーブルＴ６０１の容量と使用容量とあふれ対応終了閾値を用いて判断する。あふれ対応処理を開始する閾値と終了する閾値は、終了閾値をある程度低く設定する事によって、あふれ対応処理を連続して実行可能な状態とし、処理効率を上げる事が可能であるため、上記のようなシーケンスとしている。Ｓ７２２において、あふれ対応終了閾値を下回っていた場合は、プールあふれ対応処理要求があり、成功したという結果で、プールあふれ関連処理は終了となる（Ｓ７３１）。あふれ対応終了閾値を上回っていた場合は、Ｓ７１１へ戻り、再度処理対象のＬＵ群の抽出から、あふれ対応処理を実行する事となる。

図７においては、プールあふれ対応処理が必要か否かは、プール使用率に変化のある処理の度にＳ７０３にてチェックが行われる。この方式では、プールあふれの危険性がある場合に迅速な処理が可能であるものの、チェックのためのオーバヘッドが大きいという問題がある。

図８は、プールあふれ対応処理実行要否のチェックをポーリングで行う場合の処理シーケンスを示した図である。

プールあふれ対応処理が開始されると（Ｓ８０１）、まず、プールあふれ監視プログラム２２２が、あふれ対応が必要なプールがあるかどうかを判断する（Ｓ８０２）。ここで、あふれ対応が必要なプールが存在しない場合は、プールあふれ対応処理は終了となる（Ｓ８３１）。

あふれ対応が必要なプールが存在した場合は、プールあふれ監視プログラム２２２が、対応が必要なプールの中から一つを選択する（Ｓ８１１）。

次に、プールあふれ監視プログラム２２２が、選択したプールを使用するＬＵ群を抽出し（Ｓ８１２）、抽出したＬＵ群の優先度を解析し（Ｓ８１３）、抽出したＬＵ群に消去すべきＬＵが存在するかを判断する（Ｓ８１４）。これらの処理は、Ｓ７１１，Ｓ７１２，Ｓ７１３と同等である。

Ｓ８１４にて、消去すべきＬＵが存在しなかった場合は、プールあふれ監視プログラム２２２が、選択したプールについては、あふれ対応必要判定から除外し（Ｓ８２１）、そのプールが再度選択されないような設定を行った後、Ｓ８０２にて、別のあふれ対応が必要なプールがあるかを判断する。

Ｓ８１４にて、消去すべきＬＵが存在した場合は、プールあふれ監視プログラム２２２が、消去すべきＬＵの中で最低優先度のＬＵの消去を指示し（Ｓ８２２）、選択したプールに対して、継続してあふれ対応が必要かを判断する（Ｓ８２３）。これらの処理は、Ｓ７２１，Ｓ７２２と同等である。Ｓ８２３にて、あふれ対応が必要となった場合は、Ｓ８１２に戻り、選択したプールを使用するＬＵ群の抽出が再度行われる。あふれ対応が不要となった場合は、選択中プールに対してあふれ対応要求があり、成功したという結果で終了となり、Ｓ８０２にて、さらに別のあふれ対応が必要なプールが存在するかの判断が行われ。

図９は、ディスク１５１群に対するデータ配置の一例を示す。

データ１等の一つの四角９０１は、ストライプと呼ばれ、ディスク１５１上に設けられる単位領域であり、一般的に連続したアドレスのデータとなる。データ１，データ５，データ９，パリティ４，…がディスクＡに、データ２，データ６，パリティ３，データ１０，…がディスクＢに格納される。

図９は、ＲＡＩＤ５と呼ばれるデータ配置を示しており、特に、３つのデータから１つのパリティを作成する、３Ｄ１Ｐと呼ばれるデータ配置を示している。データ１〜データ２４は、この数字の順でデータが配置される。さらに、データ１，２，３からパリティ１が、データ４，５，６からパリティ２が、というようにパリティデータを作成し、順に格納する。ＲＡＩＤグループに対するデータのＩ／Ｏの単位領域、具体的には、例えば、このデータ１，２，３とパリティ１の組が格納される領域をストライプ列と呼ぶ。もちろん、記憶制御装置では、ＲＡＩＤ５以外のＲＡＩＤレベルや、１つのパリティに対するデータの数等から異なる構成をサポートしており、本実施例はこれを限定しない。また、同じＲＡＩＤ５の３Ｄ１Ｐであっても、データの配置等について限定するものでは無い。

図１０は、図９で示したデータ配置の別の観点を示した図である。

図１０によれば、データとパリティの構成に関する関係はそのままに、ディスクへの格納位置のみが仮想的に組み替えられている。具体的には、仮想ディスクＡには、データ１，４，７，１０，…が、仮想ディスクＢには、データ２，５，８，…が格納されている。以降では、図１０に示す仮想ディスクＡ〜Ｄを用いて、データの管理方法について説明を行う。

図１１は、図１０で示したデータ配置に本実施例に従うデータ管理が適用された図である。

まず、プールを使用する機能が、プール領域内にデータを格納する領域を確保する単位を「ページ」と呼ぶ。ここでは、例として、ページのサイズが４ストライプ分とする。もちろん、このページのサイズは任意であり、また、プールを使用する機能によって可変であってもよく、さらに同一機能の中でも状況に応じて、サイズを変化させてもよい。ページサイズが４ストライプ分で、順にページを割り当てていった場合、ページＡ１１０１には、データ１，２，３，４が、ページＢ１１０２には、データ５，６，７，８が、といったようにデータが割り当てられる。

ここで、このプールを仮想ボリューム機能が使用し、かつ複数の仮想ボリュームのデータを格納するケースを想定する。図１１は、図３における、仮想ボリュームＡ３１２と仮想ボリュームＢ３１３が使用する仮想プールボリューム３２１の、実データ領域３３２の一部を表しているものとする。このような状況で、各仮想ボリュームに対して、ページ単位で領域が割り当てられると、ページＡ１１０１は仮想ボリュームＡ３１２に、ページＢ１１０２は仮想ボリュームＢ３１３にそれぞれ割り当てられるという状況が発生し得る。さらに、各仮想ボリュームの制御権が、異なるコアに割り当てられていた場合、もしくは、領域割り当て時には同一コアに割り当てられていたが、制御権移行処理によって、各仮想ボリュームの制御権が異なるコアに割り当てられてしまった場合を想定する。

この場合、データ１，２，３から算出されるパリティ１については、ページＡ１１０１が割り当てられている仮想ボリュームＡ３１２の担当コアが処理すればよい。しかし、データ４，５，６から算出されるパリティ２については、データ４，５，６のいずれかに対する変更が行われた場合に、パリティ２に対する更新が発生する。すなわち、データ４が割り当てられているページＡ１１０１が所属する仮想ボリュームＡ３１２を担当するコアと、データ５，６が割り当てられているページＢ１１０２が所属する仮想ボリュームＢ３１３を担当するコアの、２つのコアがパリティ２に対して更新を行う可能性がある。

このパリティ更新処理を矛盾無く行うためには、データ４，５，６，パリティ２に対する更新を行う際に、自分以外のコアが同領域に対してアクセスを行わないように排他処理を行う必要がある。これは、制御権を設定する事で低減したはずの、コア間の排他処理を実行する必要がある事を示しており、煩雑で非効率な処理となってしまう。

ここで、本実施例では、チャンクという概念が導入される。「チャンク」は、複数のページから構成されており、チャンクの境界はストライプ列の境界となっている事が保証される単位である。チャンクのサイズは任意であるが、ここではストライプ２１個分とし、チャンクＡ１１１１には、データ１〜２１が含まれ、これは、ページＡ〜Ｅに相当する。データ２１は空き領域とする。さらに、あるチャンクには、単一の仮想ボリュームのデータのみを格納可能とし、チャンクＡ１１１１には仮想ボリュームＡ３１２を、チャンクＢ１１１２には仮想ボリュームＢ３１３のみが割り当てられるとする。こうした場合、チャンクＡ１１１１に対応するパリティ領域パリティ１〜７は、仮想ボリュームＡ３１２の制御権を持つコアのみがアクセスする事となる。また、同様にチャンクＢ１１１２に対応するパリティ８〜１４は、仮想ボリュームＢ３１３の制御権を持つコアのみがアクセスする事となる。よって、これらの領域に対するアクセスについては、コア間の排他処理が不要となり、制御権を持つコアが、他コアの動作を無視して処理を行う事が可能となり、制御権を導入した目的に見合った高速な動作が可能となる。

なお、ページ単位で制御権を設定し、かつ、ページの境界をストライプ列の境界とする方式でも、上記の効果は得られるが、チャンク方式に比べると、データの無駄領域が多くなってしまう。また、ページというプール領域を使用する機能が意識すべき単位が、制御権の管理単位にも影響を与えてしまい、各処理が複雑化する。

このチャンク方式によって、複数の仮想ボリュームが単一プール内に混在した場合に、各仮想ボリュームの制御権を持つ複数のコアによるアクセスを高速にかつ単純に実施する事が可能となる。これは、図５にて示したように、仮想ボリューム５１１と、スナップショット向け仮想プールボリューム５２１が、同じ仮想ボリューム機能向けプールボリューム５３１を使用する場合にも当てはまる。

よって、複数のコアを持ち、ボリュームの制御権を持ったコアが動作する記憶制御装置において、単一のプールに対して複数のプールを使用する機能がアクセスする場合に、他コアの排他処理を行わない高速で、かつ、各機能のページサイズや各機能における使用するページやその冗長データの制御権等を考慮する必要のない単純な処理を行う事が期待できる。

本発明の実施例２を説明する。その際、第１の実施例との相違点を主に説明し、第１の実施例との共通点については説明を省略或いは簡略する。

図１２は、実施例２に係る制御情報２３１の一部を示す。

実施例２に係る制御情報２３１は、プール領域を使用するＬＵに関する設定等を格納するプール使用ＬＵ情報１２０１、後述の制御権セットに関する情報を格納する制御権セット管理情報１２０２、ページ毎の状態を格納するページ管理情報１２０３、チャンクに関する情報を格納するチャンク管理情報１２０４、及び、ページの属性に関する情報を格納する属性情報１２０５を含む。

図１３は、プール使用ＬＵ情報１２０１の構成を示す。

プール使用ＬＵ情報１２０１には、プール使用ＬＵ情報テーブルＴ１３０１が含まれている。プール使用ＬＵ情報テーブルＴ１３０１は、プールを使用するＬＵ毎に、ＬＵ番号と、ＬＵの範囲、制御権セット番号、用途、ページ割り当て方針を表す情報を有する。

「制御権セット番号」とは、記憶制御装置１０１内で内部的に割り当てた管理のための番号であり、制御権セットを識別するための番号である。「制御権セット」とは、同一の制御権をもつ論理記憶領域（ＬＵもしくは他種の論理記憶領域）のセットである。同一の制御権セット番号を持つ論理記憶領域セット（一以上のＬＵ及び／又は一以上の他種の論理記憶領域のセット）は、基本的に同一の制御権を持つものとする。このため、同一の制御権セット番号を持つ論理記憶領域群は、チャンクを共有可能であり、また、制御権の移行時には、同一の制御権セット番号を持つ論理記憶領域群全てが例えば同時に移行する。例えば、スナップショットベースボリュームとそのスナップショットボリュームや、ホストが必ずセットで使用するボリューム群などが、同一制御権セット番号を持つＬＵセットの候補となる。例外及びその際の処理内容については後述する。また、同一ＬＵ内で複数の制御権セット番号を持つケースも存在する（プール使用ＬＵ情報テーブルＴ１３０１内のＬＵ番号３を参照）。こういった状態のＬＵでは、同一ＬＵを複数のコアが担当する事が可能である。例えば、記憶制御装置１０１内にＬＵが１つしか存在しないようなケースにおいても、記憶制御装置１０１内の全てのＣＰＵコアの能力を活用する場合などに、このような設定を行う事で、ＬＵをある程度のサイズの領域に分割し、複数コアで処理を分け合いつつ、コア間の排他処理を削減する事が可能となる。

「用途」は、各ＬＵ（もしくはＬＵの一部領域）がプール領域をどのような機能により使用するかを示している。

「ページ割り当て方針」は、各ＬＵ（もしくはＬＵの一部領域）に対して、どのようなページを割り当てるべきかを示している。例えば、高速なアクセスが期待されるＬＵ（プール使用ＬＵ情報テーブルＴ１３０１内のＬＵ番号０を参照）については、高速でかつ高速な状態で固定すると設定する事で、高速なページが優先的に割り当たるよう処理する。

図１４は、制御権セット管理情報１２０２の構成を示す。

制御権セット管理情報１２０２は、制御権セット管理情報テーブルＴ１４０１を有する。制御権セット管理情報テーブルＴ１４０１は、制御権セット毎に、制御権セット番号と、担当ＣＰＵコア番号と、所属ＬＵ番号と、割り当て済みチャンク番号とを有する。

「担当ＣＰＵコア番号」は、制御権セット番号から一意に決まる当該制御権セット番号を処理するＣＰＵコアの番号である。ここで、「ＣＰＵコアの番号」とは、複数のコア１２１のそれぞれを識別するための番号である。

「所属ＬＵ番号」は、当該制御権セット番号に所属するＬＵ番号の一覧を示すものである。これは、プール使用ＬＵ情報テーブルＴ１３０１から容易に導かれる情報であるが、処理の簡単化のため、制御権セット管理情報テーブルＴ１４０１にも情報を持つものとする。なお、本実施例では、ＬＵ番号３のＬＵが複数の領域に分割され、得られた各領域に異なる制御権セット番号が付与されている。このため、制御権セット管理情報テーブルＴ１４０１では、複数の制御権セット番号（１と３）に、同一の所属ＬＵ番号（３）が対応付けられている。

「割り当て済みチャンク番号」は、当該制御権セット番号が、現在使用中としているチャンクの番号である。「チャンクの番号」とは、チャンクを識別するための番号である。

図１５は、ページ管理情報１２０３の構成を示す。

ページ管理情報１２０３は、ページ管理情報テーブルＴ１５０１を有する。ページ管理情報テーブルＴ１５０１は、ページ毎に、ページ番号、用途、ページサイズ、ページ使用ＬＵ番号、チャンク番号、及び、属性を表す情報を有する。

「ページ番号」は、ページを識別するための番号である。

「用途」は、当該ページ番号がどのような機能で使用されているかを示す。

「ページサイズ」は、ページのサイズ（記憶容量）である。ページサイズをページ毎に設定可能とする事によって、同一チャンク内に異なるページサイズのページが混在する事が可能となる。このテーブルＴ１５０１によれば、チャンク番号０のチャンク中にページサイズ４ｋＢ，６４ｋＢ，２５６ｋＢのページが混在している。また、要求されるページサイズが機能毎に異なる場合であっても対応可能であるため、同一チャンク内に複数の機能が使用するページが混在する事も可能である。このテーブルＴ１５０１によれば、チャンク番号０のチャンク中に、スナップショット用のページと仮想ボリューム用のページが混在している。

「ページ使用ＬＵ番号」は、ページを使用しているＬＵのＬＵ番号である。スナップショット機能における、スナップショットボリュームとベースボリュームで同一のデータは、ベースボリューム側に存在している。プールを使用する多くの機能は、ホスト向け論理ボリューム上では別のアドレスであっても、内容が同一のデータに関しては共有する事がある。このため、単一ページ番号に対して複数のページＬＵ番号が割り当たっている事がある（ページ番号０のページは、ＬＵ１と２が使用）。

「チャンク番号」は、ページが所属するチャンクの識別番号である。

「属性」は、ページが持つ属性を表す情報であり、例えば、ページの性能、コスト及び信頼性を示す情報である。詳細は後述する。

図１６は、チャンク管理情報１２０４の構成を示す。

チャンク管理情報１２０４は、チャンクがどのような状態にあるかを管理するための情報である。チャンク管理情報１２０４は、チャンク管理情報テーブルＴ１６０１を有する。チャンク管理情報テーブルＴ１６０１は、チャンク毎に、チャンク番号、ＲＧ番号、属性、及び空き領域状況を表す情報を有する。

「チャンク番号」は、チャンクを識別するための番号である。

「ＲＧ番号」は、チャンクが所属するＲＧ（ＲＡＩＤ Ｇｒｏｕｐ）の識別番号である。ＲＧ番号から、チャンクが実際に格納される領域は、物理的にどのような構成であるかを参照する事が出来る。このテーブルＴ１６０１によれば、チャンク番号１５に複数のＲＧ番号が対応付けられている。これは、チャンク番号１５のチャンクは、異なる２つのＲＧから構成されている事を意味する。前述の通り、チャンクの境界がストライプ列境界と合致していればよいため、このような構成が可能となる。

「属性」は、チャンク番号及びＲＧ番号で定まる領域が持つ属性である。詳細は後述する。

「空き領域状況」は、各チャンク内のページがどのように割り当てられており、どのような空きがあるかを示している。例えば、チャンク番号３のチャンクには、４ｋＢ，９６ｋＢの２つの空き領域が存在する事が分かる。このように、空き領域がチャンク内の合計空き領域サイズではなく複数の数値で表されている理由は、チャンク内でページの確保及び解放を繰り返すうちに空き領域が飛び地になっている（一つのチャンク内に複数の空き領域が分散している）ためである。すなわち、チャンク番号３の例では、４ｋＢと９６ｋＢの空き領域があるが、これらは連続していない事を表しており、例えばこの状態で１００ｋＢのページを割り当てる場合には、ページを分割したり、アドレスが飛ぶ事を許容したページ構成としたりする等の措置が必要である。

図１７は、属性情報１２０５の構成を示す。

属性情報１２０５は、属性定義テーブルＴ１７０１と、ページ属性情報テーブルＴ１７０２とを有する。

属性定義テーブルＴ１７０１は、ページ管理情報テーブルＴ１５０１や、チャンク管理情報テーブルＴ１６０１で示していた属性に用いられていた識別子が持つ内容を定義した情報である。このテーブルＴ１７０１は、属性毎に、属性の識別子（属性定義テーブルＴ１７０１ではＡ〜Ｄ）と、概要と、特徴とを表す情報を有する。

「概要」は、データ格納領域、基本的にはＲＧの概要（例えば、構成するディスクのインタフェース種別（例えばＳＡＳ）、ＲＡＩＤレベル（例えばＲＡＩＤ５）、ディスク構成（４Ｄ＋１Ｐ））である。ＲＧの概要以外には、例えば、記憶制御装置１０１の機能として、他の記憶制御装置１０１の実データ領域を扱えるような機能（外部接続機能）があり、これを用いている場合（属性Ｄ）には、そういった情報を記載する事で、後述のページ割り当て論理の際により詳細な方針に基づく割り当てが可能となる。

「特徴」は、性能やコスト、信頼性等の特徴である。

ページ属性情報テーブルＴ１７０２は、ページ毎に、ページ番号、現状属性、及び、ページ状態と方針を表す情報を有する。なお、これらの情報は、ページ毎の情報を管理してるページ管理情報テーブルＴ１５０１に統合されても良いが、本実施例では、属性に関する処理方針を決定する情報をまとめるため、別テーブル１７０２で管理される。

「ページ番号」は、ページの識別番号である。

「現状属性」は、ページの現在の属性である。

「ページ状態と方針」は、ページの使用頻度や、今後のページ属性変更方針である。ページの使用頻度は、主に、ホスト１０２からページに対して発生するアクセス頻度を表している。属性変更方針は、ページの現在の属性を別の属性に変更することの方針である。例えば、ページの現在の属性は、そのページに対するアクセス頻度が属性変更方針に該当する場合に、変更される。具体的には、例えば、或る高性能のページを含んだチャンクの制御権を持つＣＰＵコアは、そのページに対するアクセス頻度を監視し、そのページに対して低頻度のアクセスしか来ていないことを検出した場合には、低性能で安価なページへの変更を管理者に推奨することができる。また、例えば、或る低性能ページを含んだチャンクの制御権を持つＣＰＵコアは、そのページに対するアクセス頻度を監視し、その低性能ページに対して高頻度のアクセスが来てしまっていることを検出した場合には、高性能なページへの変更を管理者に推奨する事ができる。

図１８は、新規ページ割り当てを実施する際の処理シーケンスを示す。

例えば、作成されてから初めてライトの生じた仮想ボリュームについて、新規ページ割り当て処理が開始される（Ｓ１８０１）。ここでは、その仮想ボリュームが、処理対象ＬＵとなる。そして、この新規ページ割り当て処理は、複数のＣＰＵコアのうちの、処理対象ＬＵの制御権を有するＣＰＵコアによって行われる。以下、図１８の説明において、そのＣＰＵコアを、「対象担当コア」と言う。

まず、対象担当コアが、処理対象ＬＵが所属する同一制御権セットの割り当て済みチャンク内に空きページがあるかを判断する（Ｓ１８０２）。Ｓ１８０２中では、対象担当コアは、プール使用ＬＵ情報テーブルＴ１３０１から、処理対象ＬＵ及び該当する範囲に関して、制御権セット番号を求める。そして、次に、対象担当コアは、制御権セット管理情報テーブルＴ１４０１を用いて、この制御権セット番号に割り当て済みのチャンク番号を抽出する。対象担当コアは、抽出したチャンクに関して、チャンク管理情報テーブルＴ１６０１から、空き領域の状況を求める事で、空きページが存在するかどうかを判断する。

空き領域が存在した場合は、対象担当コアは、その空きページ群の中に、プール使用ＬＵ情報テーブルＴ１３０１に記載されているページ割り当て方針に合致するページがあるかを判断する（Ｓ１８１１）。方針に合致するページがあった場合には、対象担当コアは、ページ割り当て／解放プログラム２２５を用いて、当該ページを処理対象ＬＵに割り当て（Ｓ１８３３）、新規ページ割り当て処理は終了となる（Ｓ１８４４）。

Ｓ１８０２にて割り当て済みチャンク内に空きページが無かった場合、及び、Ｓ１８１１にて、ページ割り当て方針に合致するページが無かった場合には、対象担当コアは、処理対象ＬＵのページ割り当て方針に合致するページを持つチャンクをチャンク管理情報テーブルＴ１６０１から探し、選択する（Ｓ１８２１）。次に、対象担当コアは、Ｓ１８２１の処理が成功したかどうか、すなわち空きチャンクの選択が成功したかどうかを判断する（Ｓ１８２２）。

空きチャンク選択が失敗した場合は、対象担当コアは、新規ページ割り当て失敗用の処理（Ｓ１８３１）を実行する。Ｓ１８３１の処理内容としては、単純にページ不足状態で終了としたり、ページ割り当て方針を緩和して再度ページ割り当て処理を実行したりするなどの方法があるが、いずれにせよ、最終的に新規ページ割り当て処理は終了となる（Ｓ１８４１）。

空きチャンク選択が成功した場合には、対象担当コアは、チャンク割り当て／解放プログラム２２６を用いて、選択したチャンクを、処理対象ＬＵが所属する制御権セットに割り当てる（Ｓ１８３２）。Ｓ１８３２にて割り当てられたチャンクには、処理対象ＬＵのページ割り当て方針に合致したページが存在しているはずである。このため、対象担当コアは、ページ割り当て／解放プログラム２２５を用いてページを割り当て（Ｓ１８３３）、新規ページ割り当て処理を終了する（Ｓ１８４１）。

図１９は、ページの属性変更処理のシーケンスを示す。

属性変更処理が開始されると（Ｓ１９０１）、或るＣＰＵコアによって、未処理の属性変更推奨ページが選択され、以降、未処理の属性変更推奨ページが無くなるまで処理が繰り返えされる（Ｓ１９０２）。

Ｓ１９０２にて、属性変更を推奨しているページがどれであるかは、上記或るＣＰＵコアによって、ページ属性情報テーブルＴ１７０２を用いて特定される。属性変更を推奨するページは、当該ページへのアクセスが当初の予定と異なっていたり、管理者からのページ割り当て方針の変更があったり、記憶制御装置の構成に変更が加えられたり（例えば、新規に極めて高性能の記憶デバイスが追加されるなどした場合には、高性能推奨ページを新規高性能記憶デバイスへ移動させるべき）等の原因によって発生する。

Ｓ１９０２にて選択された属性変更推奨ページについての処理は、そのページを含んだチャンクの制御権を有するＣＰＵコアによって行われる。以下、そのＣＰＵコアを、図１９の説明において、「対象担当コア」と言う。

Ｓ１９０２にて選択された属性変更推奨ページについて、対象担当コアは、まず、ページ属性情報テーブルＴ１７０２にて推奨された属性を持つ空きページもしくは空きチャンクがあるかを、チャンク管理情報テーブルＴ１６０１を用いて判断する（Ｓ１９１１）。この時、もちろん新規にチャンクを割り当てるよりも、割り当て済みチャンク内で新規ページを割り当てる処理の方が、処理内容が小さく高性能である事、また空きページがあるにもかかわらずチャンクを確保する事は容量の無駄を発生させる原因となるため、優先的に確保済みチャンクを調査した方が効率がよい。Ｓ１９１１にて該当する空きページもしくは空きチャンクが無かった場合は、選択したページに対する推奨する属性への変更は不可能と判断される。そして、処理が、ループの末尾に移動し、別の未処理の属性変更推奨ページが選択される。

Ｓ１９１１にて、該当するページがあった場合は、対象担当コアが、新規ページ割り当て処理を実行する（Ｓ１９２１）。Ｓ１９２１の処理は、図１８のＳ１８０１〜Ｓ１８４１にて示した処理と同一である。Ｓ１９２１が終了すると、対象担当コアは、新規ページ割り当て処理が成功したかを判定する（Ｓ１９２２）。失敗した場合は、対象担当コアが選択中ページの処理を終了する。そして、処理が、ループの末尾に移動し、次の属性変更推奨ページが選択される。

新規ページ割り当て処理が成功した場合は、対象担当コアが、データコピー／移動プログラム２２４を用いて、新規割り当てページへのデータ移動処理を実行する（Ｓ１９３１）。また、Ｓ１９３１で実行する処理はページの移動であるため、対象担当コアが、ページ割り当て／解放プログラム２２５を用いて、元々使用していたページを空き状態とし（ページの解放を行い）、チャンクの空き状況の更新や、ページの属性情報の更新などを実施する。また、Ｓ１９３１で実行したページ解放によってチャンクが空となった場合は、対象担当コアが、チャンク割り当て／解放プログラム２２６を用いて、制御権セットからのチャンク解放の実施も行う。Ｓ１９３１が終了すると、次の未処理の属性変更推奨ページが選択される。

Ｓ１９０２のループによって、全ての属性変更推奨ページの処理が完了すると、属性変更処理は終了する（Ｓ１９４１）。

図２０は、制御権を移行する処理のシーケンスを示す。

論理ボリュームもしくはその中のある範囲に関して制御権を設定し、あるコアに制御権を付与する事によって、その他のコアが当該領域にアクセスしない事が保証され、排他処理が削減され、高速かつ単純な動作を行うことができる。このような記憶制御装置１０１において、ＣＰＵコア間の負荷バランスが崩れている場合や、ユーザがあるＣＰＵに少数のボリュームをくくりつけ、優先的に処理をさせたい場合など、制御権を変更すべきケースが存在する。このような場合に、制御権移行プログラム２２７が、制御権を移行する。そのプログラム２２７は、例えば、変更前（移行前）の制御権が付与されているＣＰＵコア及び変更後（移行後）に制御権が付与されるＣＰＵコアで実行される。

制御権移行プログラム２２７は、制御権移行処理を開始すると（Ｓ２００１）、まず、全ての移行処理の対象群（ＬＵもしくはその中のある範囲）が、制御権セット単位となっているかを、プール使用ＬＵ情報テーブルＴ１３０１を用いて判断する（Ｓ２００２）。例えば、プール使用ＬＵ情報テーブルＴ１３０１において、移行処理対象がＬＵ０，１，２だった場合には、制御権セット番号０に属する全ての論理記憶領域が移行処理対象であるため、Ｓ２００２の判定は真となる。制御権セットは、可能な限り、保持したままとする事が望ましく、また、そのように設定すべきである。このため、例えば、移行処理対象がＬＵ０，１だった場合は、制御権セット番号０に属する全ての論理記憶領域のうちＬＵ２が移行処理対象ではないため、Ｓ２００２の判定は偽となる。これは、元々制御権セット番号０に属していた論理記憶領域群が２つに分割され、異なる制御権セットを構成する事を意味している。例えば、スナップショットベースボリューム及びそのスナップショットボリュームは、同一領域を参照する事がある事から、同一の制御権セットに属し、コア間の連携が不要な状態とする事が望ましい。しかし、スナップショットボリュームのうちのいくつかを別コアに割り当て直し、そちらで別のテスト処理を実施したいようなケースでは、上記の制御権セットの分割が行われる。

移行処理対象群が制御権セット単位となっていた場合には、制御権移行プログラム２２７は、処理対象の制御権セットに所属する全てのチャンクの制御権を移行する（Ｓ２０１１）。例えば、プール使用ＬＵ情報テーブルＴ１３０１において、移行処理対象がＬＵ０，１，２だった場合には、制御権移行プログラム２２７は、制御権セット番号０に属する全ての割り当て済みチャンク番号を制御権セット管理情報テーブルＴ１４０１から抽出し（チャンク番号０，３，１５，４６，９５）、これらの制御権を他のコアに移行する事となる。Ｓ２０１１には、移行によって発生する各種管理情報の更新処理も含まれている。Ｓ２０１１により、制御権は移行したので、制御権移行は終了となる（Ｓ２０５１）。

Ｓ２００２にて、移行処理対象群が制御権セット単位となっていなかった場合は、プログラム２２７は、移行処理対象群が所持している全てのページをページ管理情報テーブルＴ１５０１から抽出し、これらを順に選択し、処理を行っていく（Ｓ２０１２）。まず、プログラム２２７は、選択したページを、移行処理対象群以外の領域が共有しているかを判断する（Ｓ２０２１）。例えば、選択したページの現状が、プール使用ＬＵ情報テーブルＴ１３０１に記載されている状態で、移行処理対象群が、ＬＵ０，１であるとすると、ページ管理情報テーブルＴ１５０１から特定される、ページ使用ＬＵ番号０，１に対応した全ページが、Ｓ２０１２の対象となる。このページ番号は、図１５の例によれば、０，１，３，４，１０５，３１５である。さらに、移行処理対象群以外の領域が共有しているかを、同じくプール使用ＬＵ情報テーブルＴ１３０１から判断すると、ページ番号１，４，３１５については、ＬＵ０，１のみが使用しており、他の領域は共有しておらず、ページ番号０，３，１０５については、他の領域（ＬＵ２）が共有している事が分かる。

選択したページを移行処理対象領域と対象外領域が共有している場合には、プログラム２２７は、選択したページのデータを、データコピー／移動プログラム２２４を用いて、移行後の制御権セットに属するチャンク内のページにコピーする（Ｓ２０３１）。これは、選択したページは、異なる制御権セットからのアクセスが発生する可能性があるため、制御権セット毎にデータを用意するという処理に相当する。もちろん、Ｓ２０３１にて、データコピーを行わず、異なる制御権セットからのアクセスを受領可能な状態にするなどの方法もあるが、処理が煩雑となってしまい、また、コア間の連携処理によるオーバヘッドも発生してしまう。

Ｓ２０２１にて、選択したページを移行処理対象領域と対象外領域が共有していない場合には、プログラム２２７は、選択したページのデータを、データコピー／移動プログラム２２４を用いて、移行後の制御権セットに属するチャンク内のページに移動する（Ｓ２０３２）。これは、選択したページは、移行後の制御権セットからのみアクセスされるため、移行元制御権セットに当該ページ情報を残しておく必要が無いためである。

また、Ｓ２０３１，Ｓ２０３２では詳細に記述していないが、移行後の制御権セットに対して、あらたなチャンクもしくはページの割り当て処理が実行される。これらの処理は、新規ページ割り当て処理でのＳ１９２１と同等である。

Ｓ２０３２では、ページの移行を行うため、移行後にページが解放される。この時、プログラム２２７は、選択したページを含んだチャンクが空になったかの判断を行い（Ｓ２０３３）、チャンクが空になっていない場合は、次のページを選択する。チャンクが空になった場合は、プログラム２２７は、チャンク割り当て／解放プログラム２２６を用いて、選択したページを含んだチャンクの解放を行い（Ｓ２０４１）、次のページを選択する。Ｓ２０４１により、テーブルＴ１４０１（図１４参照）から、移行元の制御権セットに属するチャンク番号であって、解放されたチャンクの番号が、削除される。

Ｓ２０１２にて、全てのページの処理が終了すると、制御権移行処理は終了となる（Ｓ２０５１）。

以上のように、図１８，１９，２０を用いて、各種のチャンク、ページ及び制御権セットに関する処理を示した。これらの処理、及び、ホスト１０２からのＩ／Ｏコマンドの処理（ＩＯ処理）において、制御権を意識した動作は、チャンク割り当て／解放プログラム２２６をはじめとする、チャンクを扱う論理のみに集約されている。すなわち、チャンク割り当て／解放プログラム２２６が定められた制御権セット情報に基づき、チャンクを割り当てた後は、各種機能は、制御権を意識することなく、ページを割り当て、処理を実行する事が可能である。よって、制御権という、記憶制御装置１０１の処理の高速化及び単純化を実現する概念を導入しつつ、チャンク処理以外の箇所ではこれを意識しない事により、単純化された論理の構築が可能となる。

図２３は、ページ割り当て方針を設定するための管理画面２３０１を示す。

管理画面２３０１は、ページ割り当て方針設定部位２３１１と、設定ボタン２３１２と、キャンセルボタン２３１３とを有する。

ページ割り当て方針設定部位２３１１は、割り当て方針の設定対象ＬＵを入力する部位２３２１と、その対象範囲を設定する２３２２とを持つ。これらから、割り当て方針を設定する範囲を選択することができる。また、あふれが生じた時に削除が可能か不可能かを選択する部位２３２３と、性能方針を設定する部位２３２４とが設けられ、これらにより、選択した領域に対するページ割り当て方針を設定することができる。

設定ボタン２３１２は、入力された各種情報を反映するためのボタンであり、キャンセルボタン２３１３は、入力された各種情報を破棄するためのボタンである。

図２４は、制御権移行処理を指示するための管理画面２４０１を示す。

管理画面２４０１は、制御権移行処理対象領域選択部位２４１１と、移行先選択部位２４１２と、実行ボタン２４１３と、キャンセルボタン２４１４とを有する。

部位２４１１は、制御権移行処理の対象とする範囲を選択するための部位であり、現在選択されている領域は、選択中領域２４２４に表示される。領域を追加する場合には、対象ＬＵ設定部位２４２１と、対象範囲設定部位２４２２とを用いて、領域を選択し、追加ボタン２４２３を押す事によって、選択中領域２４２４に領域の情報が追加される。

部位２４１２は、選択中領域２４２４をどのＣＰＵコアに割り当てるかを選択する部位である。

実行ボタン２４１３は、選択中領域２４２４に表示されている領域の制御権を、移行先選択部位２４１２に示されたＣＰＵコアに移行させるためのボタンであり、キャンセルボタン２４１４は、入力された各種情報を破棄するためのボタンである。

図２４では、管理者が明示的に制御権を移行する際の画面を示したが、これ以外にも、各領域に対して記憶制御装置が制御権の移行を行う事を許可しておき、記憶制御装置１０１内の負荷バランスや、管理者からの設定内容から判断し、ＣＰＵコアが、自動的に制御権を移行する方法もある。例えば、ＣＰＵコアが、自分が担当する制御権セットに属する論理記憶領域へのアクセス頻度を監視し、そのアクセス頻度が一定の頻度を超えた場合に、自分が担当する制御権を移行してもよい。

以上、本発明の幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、実施例２（例えば、チャンクの設定やチャンクからのページの割り当て）は、実施例１に適用されても良い。また、領域の割り当ては、論理記憶領域に対するデータのリードのときに行われても良い。

１０１：記憶制御装置

Claims (7)

1. 複数のＣＰＵ（Central Processing Unit）コアを有し、
   前記複数のＣＰＵコアの各々が、複数種類の論理記憶領域のうちの一種類以上の論理記憶領域の制御権を有し、
   各ＣＰＵコアは、そのＣＰＵコアが有する制御権に対応した論理記憶領域に対するデータのアクセスの場合、そのデータの格納に必要な領域を、アクセス先の論理記憶領域に共通の物理記憶領域から割り当て、
   前記複数種類の論理記憶領域は、仮想ボリュームと、スナップショットボリュームと、スナップショット用仮想ボリュームとを含み、
   前記仮想ボリューム、前記スナップショット及び前記スナップショット用仮想ボリュームのうち、前記仮想ボリューム及び前記スナップショットボリュームが、ホスト装置向けのボリュームであり、
   前記仮想ボリュームは、ホスト装置からのデータの格納先とされるボリュームであり、
   前記スナップショットボリュームは、ベースとしてのデータを記憶しているスナップショットベースボリュームとの差分のデータを記憶するボリュームであり、
   前記スナップショットボリュームに格納されるデータは、前記スナップショット用仮想ボリュームに格納され、
   前記仮想ボリュームの制御権を有するＣＰＵコアが、前記仮想ボリュームに対するデータのアクセスの際に、そのデータの格納に必要な領域を前記共通の物理記憶領域から割り当て、
   前記スナップショットボリュームの制御権を有するＣＰＵコアが、前記スナップショットボリュームに対するデータのアクセスの際に、そのデータの前記スナップショット用仮想ボリュームに対するアクセスを行い、
   前記スナップショット用仮想ボリュームの制御権を有するＣＰＵコアが、前記スナップショット用仮想ボリュームに対するデータのアクセスの際に、そのデータの格納に必要な領域を前記共通の物理記憶領域から割り当て、
   或るＣＰＵコアが、下記（Ａ）乃至（Ｄ）を含んだ処理であるあふれ対応処理を行い、
   （Ａ）前記共通の物理記憶領域の使用率が第１の閾値を超えているか否かを判断する；
   （Ｂ）前記（Ａ）の判断の結果が肯定的の場合、前記仮想ボリューム、前記スナップショットボリューム及び前記スナップショット用仮想ボリュームのうち優先度が最も低いボリュームを削除する；
   （Ｃ）前記（Ｂ）で削除されたボリュームに割り当てられていた、前記共通の物理記憶領域における領域を解放する；
   （Ｄ）前記（Ｃ）の結果、前記共通の物理記憶領域の使用率が第２の閾値未満に下がったか否かを判断する、
   （Ｅ）前記（Ｄ）の判断の結果が否定的であれば、前記（Ｂ）を実行し、前記（Ｄ）の判断の結果が肯定的であれば、処理を終了する、
   前記第２の閾値は、前記第１の閾値より低い閾値であり、
   前記使用率は、前記共通の物理記憶領域の容量に対する割当て済み領域の総量の比率である、
   記憶制御装置。
2. 複数のＣＰＵ（Central Processing Unit）コアを有し、
   前記複数のＣＰＵコアの各々が、複数種類の論理記憶領域のうちの一種類以上の論理記憶領域の制御権を有し、
   各ＣＰＵコアは、そのＣＰＵコアが有する制御権に対応した論理記憶領域に対するデータのアクセスの場合、そのデータの格納に必要な領域を、アクセス先の論理記憶領域に共通の物理記憶領域から割り当て、
   前記複数種類の論理記憶領域は、複数の制御権セットに属する複数のボリュームであり、
   各ＣＰＵコアに、一以上の制御権セットが割り当てられており、
   前記共通の物理記憶領域は、属性の異なる複数のＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループに基づく記憶領域であり、
   ＲＡＩＤグループは、複数の物理記憶デバイスで構成されており、
   前記共通の物理記憶領域が、複数のチャンクで構成されており、
   各チャンクは、複数のストライプ列で構成されており、
   ストライプ列は、複数のストライプで構成されており、ＲＡＩＤグループに基づくデータのＩ／Ｏの単位領域であり、
   ストライプは、物理記憶デバイスにおける単位領域であり、
   各制御権セットに、ボリュームの他に、前記複数のチャンクから割り当てられた一以上のチャンクが属しており、
   データがアクセスされるボリュームである対象ボリュームの制御権セットが割り当てられているＣＰＵコアが、
   （Ａ）前記対象ボリュームの制御権セットに属するチャンクに、データを格納可能な領域があるか否かを判断し、
   （Ｂ）前記（Ａ）の判断の結果が肯定的であれば、前記対象ボリュームの方針に合致する属性の領域があるか否かを判断し、
   （Ｃ）前記（Ｂ）の判断の結果が肯定的であれば、前記対象ボリュームの方針に合致する属性の領域を前記対象ボリュームに割り当て、
   （Ｄ）前記（Ａ）又は前記（Ｂ）の判断の結果が否定的であれば、前記対象ボリュームの方針に合致するチャンクを、前記対象ボリュームの制御権セットに割り当て、その後、前記対象ボリュームの方針に合致する領域を、前記割り当てたチャンクから前記対象ボリュームに割り当て、
   いずれかのＣＰＵコアが、一以上の移行対象ボリュームの所属先を第１の制御権セットから第２の制御権セットに移行する制御権移行処理を行い、前記制御権移行処理において、以下の（ａ）〜（ｃ）を行う、
   （ａ）前記一以上の移行対象ボリュームの全てが、前記第１の制御権セットに属する一以上のボリュームの全てであるか否かを判断する、
   （ｂ）前記（ａ）の判断の結果が肯定的であれば、前記一以上の移行対象ボリュームの全ての所属先を、前記第１の制御権セットから前記第２の制御権セットに移行する、
   （ｃ）前記（ａ）の判断の結果が否定的であれば、前記一以上の移行対象ボリュームに割り当てられている領域毎に、以下の（ｃ−１）〜（ｃ−５）を行う、
   （ｃ−１）領域が、前記一以上の移行対象ボリューム以外のボリュームにも割り当てられているか否かを判断する、
   （ｃ−２）前記（ｃ−１）の判断の結果が肯定的であれば、領域内のデータを、前記第２の制御権セットに所属するチャンクにおける領域にコピーする、
   （ｃ−３）前記（ｃ−１）の判断の結果が否定的であれば、領域内のデータを、前記第２の制御権セットに所属するチャンクにおける領域に移動する、
   （ｃ−４）前記（ｃ−３）の後、データの移動元の領域を有するチャンクが空になったか否かを判断する、
   （ｃ−５）前記（ｃ−４）の判断の結果が肯定的であれば、前記チャンクを前記第１の制御権セットから解放する、
   一つのチャンクには、サイズの異なる領域が混在する、
   記憶制御装置。
3. 請求項２記載の記憶制御装置であって、
   前記複数種類の論理記憶領域は、Thin Provisioning に従う容量仮想化を行う機能である仮想ボリューム機能で使用されるボリュームである複数の第１種のボリュームと、仮想ボリューム機能以外の機能で使用される第２種のボリュームとを含み、
   前記第２種のボリュームにアクセスされるデータのアクセス先として、前記複数の第１種のボリュームのうちの少なくとも一つが採用され、
   データのアクセス先の第１種のボリュームの制御権を有するＣＰＵコアである対象ＣＰＵコアが、そのデータの格納に必要な領域を、共通の物理記憶領域から前記アクセス先の第１種のボリュームに割り当てる、
   記憶制御装置。
4. 請求項３記載の記憶制御装置であって、
   或るＣＰＵコアが、下記（Ａ）乃至（Ｃ）を含んだ処理であるあふれ対応処理を行い、
   （Ａ）前記共通の物理記憶領域の使用率が第１の閾値を超えているか否かを判断する；
   （Ｂ）前記（Ａ）の判断の結果が肯定的の場合、ボリュームを削除する；
   （Ｃ）前記（Ｂ）で削除されたボリュームに割り当てられていた、前記共通の物理記憶領域における領域を解放する、
   記憶制御装置。
5. 請求項４記載の記憶制御装置であって、
   前記或るＣＰＵコアが、前記あふれ対応処理において、更に、以下の（Ｄ）及び（Ｅ）を行う、
   （Ｄ）前記（Ｃ）の結果、前記共通の物理記憶領域の使用率が第２の閾値未満に下がったか否かを判断する、
   （Ｅ）前記（Ｄ）の判断の結果が否定的であれば、前記（Ｂ）を実行し、前記（Ｄ）の判断の結果が肯定的であれば、処理を終了する、
   前記第２の閾値は、前記第１の閾値より低い閾値であり、
   記憶制御装置。
6. 前記複数のＣＰＵコアの各々が、複数種類の論理記憶領域のうちの一種類以上の論理記憶領域の制御権を有し、
   各ＣＰＵコアは、そのＣＰＵコアが有する制御権に対応した論理記憶領域に対するデータのアクセスの場合、そのデータの格納に必要な領域を、アクセス先の論理記憶領域に共通の物理記憶領域から割り当て、
   前記複数種類の論理記憶領域は、仮想ボリュームと、スナップショットボリュームと、スナップショット用仮想ボリュームとを含み、
   前記仮想ボリューム、前記スナップショット及び前記スナップショット用仮想ボリュームのうち、前記仮想ボリューム及び前記スナップショットボリュームが、ホスト装置向けのボリュームであり、
   前記仮想ボリュームは、ホスト装置からのデータの格納先とされるボリュームであり、
   前記スナップショットボリュームは、ベースとしてのデータを記憶しているスナップショットベースボリュームとの差分のデータを記憶するボリュームであり、
   前記スナップショットボリュームに格納されるデータは、前記スナップショット用仮想ボリュームに格納され、
   前記仮想ボリュームの制御権を有するＣＰＵコアが、前記仮想ボリュームに対するデータのアクセスの際に、そのデータの格納に必要な領域を前記共通の物理記憶領域から割り当て、
   前記スナップショットボリュームの制御権を有するＣＰＵコアが、前記スナップショットボリュームに対するデータのアクセスの際に、そのデータの前記スナップショット用仮想ボリュームに対するアクセスを行い、
   前記スナップショット用仮想ボリュームの制御権を有するＣＰＵコアが、前記スナップショット用仮想ボリュームに対するデータのアクセスの際に、そのデータの格納に必要な領域を前記共通の物理記憶領域から割り当て、
   或るＣＰＵコアが、下記（Ａ）乃至（Ｄ）を含んだ処理であるあふれ対応処理を行い、
   （Ａ）前記共通の物理記憶領域の使用率が第１の閾値を超えているか否かを判断する；
   （Ｂ）前記（Ａ）の判断の結果が肯定的の場合、前記仮想ボリューム、前記スナップショットボリューム及び前記スナップショット用仮想ボリュームのうち優先度が最も低いボリュームを削除する；
   （Ｃ）前記（Ｂ）で削除されたボリュームに割り当てられていた、前記共通の物理記憶領域における領域を解放する；
   （Ｄ）前記（Ｃ）の結果、前記共通の物理記憶領域の使用率が第２の閾値未満に下がったか否かを判断する、
   （Ｅ）前記（Ｄ）の判断の結果が否定的であれば、前記（Ｂ）を実行し、前記（Ｄ）の判断の結果が肯定的であれば、処理を終了する、
   前記第２の閾値は、前記第１の閾値より低い閾値であり、
   前記使用率は、前記共通の物理記憶領域の容量に対する割当て済み領域の総量の比率である、
   記憶制御方法。
7. 前記複数のＣＰＵコアの各々が、複数種類の論理記憶領域のうちの一種類以上の論理記憶領域の制御権を有し、
   各ＣＰＵコアは、そのＣＰＵコアが有する制御権に対応した論理記憶領域に対するデータのアクセスの場合、そのデータの格納に必要な領域を、アクセス先の論理記憶領域に共通の物理記憶領域から割り当て、
   前記複数種類の論理記憶領域は、複数の制御権セットに属する複数のボリュームであり、
   各ＣＰＵコアに、一以上の制御権セットが割り当てられており、
   前記共通の物理記憶領域は、属性の異なる複数のＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループに基づく記憶領域であり、
   ＲＡＩＤグループは、複数の物理記憶デバイスで構成されており、
   前記共通の物理記憶領域が、複数のチャンクで構成されており、
   各チャンクは、複数のストライプ列で構成されており、
   ストライプ列は、複数のストライプで構成されており、ＲＡＩＤグループに基づくデータのＩ／Ｏの単位領域であり、
   ストライプは、物理記憶デバイスにおける単位領域であり、
   各制御権セットに、ボリュームの他に、前記複数のチャンクから割り当てられた一以上のチャンクが属しており、
   データがアクセスされるボリュームである対象ボリュームの制御権セットが割り当てられているＣＰＵコアが、
   （Ａ）前記対象ボリュームの制御権セットに属するチャンクに、データを格納可能な領域があるか否かを判断し、
   （Ｂ）前記（Ａ）の判断の結果が肯定的であれば、前記対象ボリュームの方針に合致する属性の領域があるか否かを判断し、
   （Ｃ）前記（Ｂ）の判断の結果が肯定的であれば、前記対象ボリュームの方針に合致する属性の領域を前記対象ボリュームに割り当て、
   （Ｄ）前記（Ａ）又は前記（Ｂ）の判断の結果が否定的であれば、前記対象ボリュームの方針に合致するチャンクを、前記対象ボリュームの制御権セットに割り当て、その後、前記対象ボリュームの方針に合致する領域を、前記割り当てたチャンクから前記対象ボリュームに割り当て、
   いずれかのＣＰＵコアが、一以上の移行対象ボリュームの所属先を第１の制御権セットから第２の制御権セットに移行する制御権移行処理を行い、前記制御権移行処理において、以下の（ａ）〜（ｃ）を行う、
   （ａ）前記一以上の移行対象ボリュームの全てが、前記第１の制御権セットに属する一以上のボリュームの全てであるか否かを判断する、
   （ｂ）前記（ａ）の判断の結果が肯定的であれば、前記一以上の移行対象ボリュームの全ての所属先を、前記第１の制御権セットから前記第２の制御権セットに移行する、
   （ｃ）前記（ａ）の判断の結果が否定的であれば、前記一以上の移行対象ボリュームに割り当てられている領域毎に、以下の（ｃ−１）〜（ｃ−５）を行う、
   （ｃ−１）領域が、前記一以上の移行対象ボリューム以外のボリュームにも割り当てられているか否かを判断する、
   （ｃ−２）前記（ｃ−１）の判断の結果が肯定的であれば、領域内のデータを、前記第２の制御権セットに所属するチャンクにおける領域にコピーする、
   （ｃ−３）前記（ｃ−１）の判断の結果が否定的であれば、領域内のデータを、前記第２の制御権セットに所属するチャンクにおける領域に移動する、
   （ｃ−４）前記（ｃ−３）の後、データの移動元の領域を有するチャンクが空になったか否かを判断する、
   （ｃ−５）前記（ｃ−４）の判断の結果が肯定的であれば、前記チャンクを前記第１の制御権セットから解放する、
   一つのチャンクには、サイズの異なる領域が混在する、
   記憶制御方法。
   

Images