JP5111204B2 - ストレージシステム及びストレージシステムの管理方法 - Google Patents

Description

本発明は、ストレージシステムに係り、特に、モジュール型ストレージの結合・分割の技術に関する。さらに本発明は、ストレージシステムの管理方法に関するものである。

例えば、データセンタなどのような大規模なデータを取り扱うデータベースシステムでは、ホストコンピュータとは別に構成された記憶システムを用いてデータを管理することが行われている。この記憶システムは、例えば、ディスクアレイ装置などから構成されている。ディスクアレイ装置は、ホストコンピュータからの入出力要求に応答して、複数の記憶デバイスの記憶領域上に形成された論理ボリューム（論理ユニット）をホストコンピュータに提供することができる。

ディスクアレイ装置を通信ネットワークを介してホストコンピュータに接続したストレージシステムにおいては、システム構成の変更に伴ってストレージシステムを論理分割することが行われている（特許文献１参照）。
米国特許第７０６９４０８号

上記のストレージシステムを論理分割する機能は、１装置内に分割されたストレージを定義し、各分割ストレージシステムに対して、空きリソース(使っていないディスク)などを割り当てて使用することを前提としている。即ち、物理的に分割されるような運用、それに伴ってデータの移動や制御情報の分割が発生するケースは考慮していない。また、複数のストレージ筐体を動的に(オンラインで)結合して１つのストレージ装置として運用管理可能にすることも想定していない。

本発明は、システム構成の変更に合わせて情報を管理することができるストレージシステムを提供することを目的とするものである。

前記目的を達成するために、本発明は、システム構成を変更する際、例えば、複数のサブストレージシステムをストレージシステムとして結合するときには、各サブストレージシステムを互いに物理的に結合し、当該結合された各サブストレージシステムを、上位計算機に対して単一のアクセス対象として管理し、且つ単一の運用対象として管理する。また、ストレージシステムを複数のサブストレージシステムに分割するときには、ストレージシステムを物理的に複数のサブストレージシステムに分割し、当該分割された各サブストレージシステムを、上位計算機に対して、それぞれ独立のアクセス対象とするとともに、独立の運用対象として管理することを特徴とする。さらに本発明は、サブストレージシステムが疎結合構成を成して結合される場合に、各々のサブストレージシステムのメモリが、自サブストレージシステムの記憶装置の管理情報と他サブストレージシステムの記憶装置の管理情報の少なくとも一部を結合して格納し、各々のサブストレージシステムの制御部が、上位計算機からデータの入出力要求を受信すると、結合された管理情報を参照して当該入出力要求で指定された記憶装置を有するサブストレージシステムを判定して当該入出力要求を処理し、リソースの割付処理が必要になると、自サブストレージシステム内の未使用リソースを探し、未使用リソースが足りない場合には統合管理部が管理する未使用リソース情報から未使用リソースが十分ある他サブストレージシステムを選択して未使用リソースを割付けることを特徴とし、サブストレージシステムが密結合構成を成して結合される場合に、各々のサブストレージシステムの何れかのメモリが、サブストレージシステムの各々の記憶装置の管理情報を結合して格納し、各々のサブストレージシステムの制御部が、上位計算機からデータの入出力要求を受信すると、少なくとも二つのサブストレージシステムの何れかのメモリに格納されている結合された管理情報を参照して当該入出力要求を処理し、リソースの割付処理が必要になると、少なくとも二つのサブストレージシステム内の何れかの未使用リソースを選択して割付けることを特徴とする。

本発明によれば、システム構成の変更に合わせて情報を動的に管理することができる。

以下、本発明の一実施形態を説明する。
＜システム構成の一例＞
図１は，本発明の一実施形態に係るシステム全体の構成例を示す。以下の説明では、同種の要素を区別しないで説明する場合には，親番号のみ（例えば２０）を用いて説明し，同種の要素を区別して説明する場合には，親番号と子符号（例えば２０A，２０B）を用いて説明することにする。

ストレージサブシステム２０A，２０Bは、それぞれ独立に使われていて、図２の結合処理により、ストレージシステム１００となる。各ホスト計算機５１は，図示しないCPU（Central Processing Unit） や記憶資源（例えばメモリ）を備える。記憶資源に，コンピュータプログラムが記憶されており，CPUが，そのコンピュータプログラムを実行することができる。以下，コンピュータプログラムが主語になる場合は，実際にはそのコンピュータプログラムを実行するCPUによって処理が行われるものとする。

サブストレージシステム２０A，２０Bには，ホスト計算機５１A、５１Bがそれぞれ接続されている。ホスト計算機５１Aまたは５１Bは，SAN（Storage Area Network）４１を介して，それぞれのサブストレージシステム２０Aまたは２０Bに接続していてもよい（図３参照）。

各ホスト計算機５１は，アプリケーションプログラム６０を有する。アプリケーションプログラム６０は，例えば，データベース管理ソフトウェア，Webアプリケーションソフトエア，ストリーミングアプリケーションソフトウェアなどの業務プログラムである。

サブストレージシステム２０は，例えば，制御部と，記憶部とに大別することができる。制御部は，例えば，CPU（Central Processing Unit）２１，メモリ２２，ディスクインターフェース制御部２３，FC（Fiber Channel）インターフェース制御部２６，及びLAN（Local Area Network）インターフェース制御部２７を備える。記憶部は，例えば，ディスクユニット２４である。

CPU２１は，メモリ２２に格納されている各種プログラム又はモジュール（ここではマイクロ的なものを指す）を実行することにより，サブストレージシステム２０における各種制御処理を実行する。メモリ２２は，内部記憶装置と称されるものであり，各種モジュール等を記憶する不揮発性メモリと，CPU２１の演算処理結果を一時的に保持する揮発性メモリとを含む。

CPU２１は，ディスクインターフェース制御部２３を介してディスクユニット２４に接続されている。ディスクインターフェース制御部２３は，伝送制御装置として、CPU２１から出力される論理アドレスをLBA（Logical Block Address）に変換し，CPU２１による論理デバイスへのアクセスを可能とする。

ディスクユニット２４は，記憶装置として、RAID（Redundant Arrays of Independent Inexpensive Disks）構成された複数のディスクドライブ２４０を有する。ディスクドライブ２４０は，FC（Fibre Channel）ディスクドライブ，SATA（Serial Advanced Technology Attachment）ディスクドライブ，PATA（Parallel Advanced Technology Attachment）ディスクドライブ，FATA（Fibre Attached Technology Adapted）ディスクドライブ，SAS（Serial Attached SCSI）ディスクドライブ或いはSCSI（Small Computer System Interface）ディスクドライブ等の物理デバイスである。物理デバイスとは，実記憶領域を有する実デバイスである。なお，物理デバイスは，ディスクドライブ２４０に限らず，他種の記憶デバイス（例えばフラッシュメモリ）が採用されても良い。

仮想LDEV（Virtual Logical Device）２４２は、実記憶領域を有しない仮想的なデバイスである。実際にはプールと呼ばれる記憶領域にデータは記録される。これについては、後述する。

FCインターフェース２６は，複数のディスクドライブ２４０をRAID方式に規定されるRAIDレベル（例えば，０，１，５）で制御することができる。RAID方式においては，複数のディスクドライブ２４０が一つのRAIDグループとして管理される。RAIDグループは，例えば，４つのディスクドライブ２４０を一組としてグループ化することにより（３D＋１P），或いは，８つのディスクドライブ２４０を一組としてグループ化することにより（７D＋１P），構成される。

即ち，複数のディスクドライブ２４０のそれぞれが提供する記憶領域が集合して一つのRAIDグループが構成される。RAIDグループ上には，ホスト計算機５１からのアクセス単位である複数の論理デバイス２４１が定義される。ホスト計算機５１が認識する論理的な記憶領域である論理ユニットには，一つ以上の論理デバイス２４１がマッピングされる。ホスト計算機５１は，LUNとLBAとを指定することにより，論理デバイス２４１にアクセスできる。

尚，サブストレージシステム２０は，後述の外部ストレージシステム７０に接続することにより，外部ストレージシステム７０の記憶領域をホスト計算機５１に提供できるならば，必ずしもディスクユニット２４とディスクインターフェース制御部２３とを備えている必要はない。

FCインターフェース制御部２６は，ストレージサブシステム２０とホスト計算機５１との間のコマンドやデータの転送を制御する。サブストレージシステム２０とホスト計算機５１と間のSANがあってもよい。SANを介するデータ通信プロトコルとしては，例えば，ファイバチャネルプロトコルやｉSCSIプロトコルなどを採用することができる。

LANインターフェース制御部２７は，管理ネットワーク４０を介して管理装置５０に接続する。管理ネットワーク４０は，イーサネット（登録商標）ケーブルなどで構成されるLANである。管理ネットワーク４０におけるデータ通信プロトコルは，例えば，TCP／IPである。管理装置５０は，サブストレージシステム２０内のLDEVの作成，ホスト計算機５１へのLDEVの割り当て，ホスト計算機５１とサブストレージシステム２０との間のアクセスパスの設定（LUNマスキングやゾーニングなど）などを管理することができる。

図２のストレージシステムの結合処理により、ストレージシステム１００となると，サブストレージシステム２０はモジュール２０となり、モジュール２０間で制御情報を送受信することにより、各モジュール間におけるコマンド転送やボリュームマイグレーションを実行できる。各モジュール２０に外部ストレージシステム７０が接続されている構成（図４参照）では，ストレージシステム１００の範囲は，複数のモジュール２０と外部ストレージシステム７０とを含む。各モジュール２０に外部ストレージシステム７０が接続されていない場合には，ストレージシステム１００の範囲は，複数のモジュール２０を含み，外部ストレージシステム７０を含まない。

各モジュール２０は，例えば，RAID構成された複数のディスクドライブ２４０を備えるディスクアレイシステムとして構成することもできるし，或いは各モジュール２０自体がSCSIターゲットになる仮想化スイッチとして構成することもできる。LDEV番号などの階層化された管理識別子を管理し、ストレージシステムの動作を制御する装置を，「制御装置」と総称することができる。制御装置は，モジュールの中にあっても良いし，外にあっても良い。

管理ネットワーク４０は，一つ以上のホスト計算機５１に接続している。なお，ホスト計算機５１から各モジュール２０へコマンドを発行するためのネットワーク（SAN）と，管理装置５０が各モジュール２０との間で管理情報を送受信するためのネットワーク（管理ネットワーク４０）とが異なるアウトバンド方式でもよいし，インバウンド方式でもよい。例えば，図３のように、管理装置５０がSAN４１経由で各モジュール２０との間で管理情報を送受信するように構成すれば，インバンド方式となる。

また、ストレージシステムとしては、管理装置５０Aと５０Bを物理的に分けたものについて述べたが、１台の管理装置５０を設け、サブストレージシステム２０Aの管理者とサブストレージシステム２０Bの管理者のアカウント（管理者アカウント）を作っても良い。以降の説明では、管理者＝管理装置で説明するが、必ずしも１対１でなくても良い。

本実施形態に係るシステムの全体構成としては、メインフレームシステムとオープンシステムのいずれか一方あるいはそれらが混在した構成であっても良い。

上記構成において、制御の仕方によって、「疎結合構成」と「密結合構成」がある。図５に、複数モジュールから構成される１つのストレージシステム１００を示す。

図６（a）に、疎結合となる場合の内部構成を示す。ストレージシステム１００内のモジュール２０Aと２０Bには、それぞれメモリ２２とCPU２１がある。メモリ２２には、自分のモジュールが制御を担当するリソースの情報が入る。例えば、モジュール２０Aが制御を担当するボリュームのボリューム管理情報テーブル２０３Aは、モジュール２０A内のメモリ２２Aに格納する。他のモジュールが制御を担当するボリューム管理情報テーブルもメモリ２２A内に持つが、ボリューム管理情報テーブルのうち、「ボリューム番号」と「管理者識別子」情報のみを登録する。「管理者識別子」には、そのボリュームの制御を担当するモジュールを示す識別子が入る。

図６（b）に、この構成において、密結合となる場合の内部構成を示す。モジュール２０Aのメモリ２２Aとモジュール２０Bのメモリ２２Bは、モジュール２０A、２０Bのどちらのモジュールからもそれぞれのメモリ２２に参照可能である。メモリ２０A、２０Bは物理的には２つのモジュールに分割されているが、モジュール２０AのCPU２１A、CPU２０Bのどちらからも単一のアドレス空間に見える。

以上が，本実施形態のシステム全体についての説明である。
＜サブストレージシステムの結合＞
図２にサブストレージシステムの結合処理概要のフローチャート図を示す。システム構成例を図１に示す。図１に示すサブストレージシステム２０Aと２０Bは、物理的に別々の同じ構成のサブストレージシステムである。このサブストレージシステム２０Aと２０Bを結合する処理を説明する。

サブストレージシステム２０Aと２０Bを接続線（結合部）４４で物理的に結合する。接続線４４は専用の接続線でもよいし、スイッチ機構でもよいし、ネットワークでもよいし、結合のための装置でもよい。これにより、ストレージシステム１００となり、結合前のサブストレージシステム２０Aと２０Bはストレージシステム１００内に論理的に存在するサブストレージシステムとして「モジュール」と呼ぶこととする。モジュール２０Aと２０Bは、結合直後は物理的に分離していて、リソースもそれぞれでモジュール毎に物理的に分けて、それぞれのモジュール２０Aと２０Bから使用されている状態である（ステップ１００１）。

モジュール２０Aと２０Bの制御情報を結合する。この際、図７に示すように、管理制御情報はモジュール２０内のメモリ２２に格納され、モジュール２０Aと２０Bでそれぞれ管理している。詳細は後述する（ステップ１００２）。また結合に伴って必要になる処理ができるように、プログラムを追加する（後述）。

サブストレージシステム２０A、２０Bの管理を統合する。ここで、管理の統合とは、管理装置５０Aと５０Bを統合すると、サブストレージシステム２０Aを管理する管理者とサブストレージシステム２０Bを管理する管理者を統合することを示す（ステップ１００３）。

ここまでの処理が完了したら、ストレージシステム１００となり、モジュール２０A、２０Bの範囲にかかわらず、ストレージシステム１００内の全てのリソースを利用することができるようになる。

サブストレージシステム結合後は、図１の１００が「ストレージシステム」となり、サブストレージシステム２０Aと２０Bは「モジュール」となる。ホスト５１A及び５１Bからは、ストレージシステム１００を認識させることができる。すなわち、モジュール２０A、２０BのCPU２１と管理装置５０Aと５０BのCPUは、モジュール２０Aと２０Bを、ホスト（上位計算機）５１A及び５１Bに対して、単一のアクセス対象として管理するとともに、単一の運用対象として管理する統合管理部として機能する。

モジュールを結合したストレージシステム１００では、一つ以上のモジュール２０Aを、ホスト５１に対して一台のストレージシステムとしてみせる。このため、管理者がモジュール２０Bのボリューム６３０へのI/O用のパスを定義する場合に、モジュール２０Aのポート６１５を指定する可能性がある（図８参照）。

パス定義は、ユーザが管理装置５０からパス定義を指示すると、管理装置５０のプログラム（図示せず）と、各モジュール２０のパス定義プログラム（図示せず）が実行されることで実現される。ユーザは、管理装置５０に対して使用するポート６１５のポート番号、対象となるボリューム６３０のボリューム番号を指定するものとする。前記プログラムは、管理装置５０のCPU２１がメモリ２２に格納されているプログラムを実行することで実現される。さらに、パス定義プログラムの処理は、モジュール２０のCPU２１がメモリ２２に格納されているパス定義プログラムを実行することで実現される。

パス定義の処理を図９のフローチャートに従って説明する。まず、前記プログラムは、指定ポート６１５を有するモジュール２０Aに、パス定義を指示し(ステップ３５０１)、指定先のモジュール２０Bからの完了報告を待つ(ステップ３５０２)。パス定義の指示とともに、前記プログラムは、モジュール２０Bに、使用するポート６１５のポート番号、及び、対象となるボリューム６３０のボリューム番号を通知する。

パス定義プログラムは指示を受け取り（ステップ３５０３）、ボリューム管理情報テーブル２０３の中の、対象となるポートに対応する「LUN」番号の「管理識別子」にモジュール２０Bを示す情報を登録する(ステップ３５０４)。そして、パス定義プログラムは、プログラムに完了を報告する(ステップ３５０５)。この後、プログラムは、パス定義プログラムから完了報告を受領し(ステップ３５０６)、処理を終了する(ステップ３５０７)。

＜結合後の要求処理＞
＜複数モジュールが結合して疎結合構成を成す場合＞
次に、ホスト５１AからモジュールBへの要求を出したときの処理を図１０のフローチャートにしたがって説明する。ホスト５１Aからモジュール２０Bへ要求を出すと、ホスト５１Aからの要求はモジュール２０Aに入力され、モジュール２０Aはホスト５１から要求を受け取ったときに（ステップ６００１）、どのモジュールの要求かを判定する（ステップ６００２）。ここで、図１１（a）に疎結合の場合の制御情報の持ち方を示す。テーブルについては後述する。

モジュール２０Aは、自分のメモリ２２A内にあるボリューム管理情報テーブル２０３Aを参照し、ホスト５１Aから要求のあったLUNが自分のモジュール内のものか他のモジュール内のものかを判定する。例えば、LUN＝“０１０”の場合は、管理者識別子がモジュール２０Aを示しているので、自分のモジュール内への要求と判断し、LUN＝“０２０”の場合は、モジュール２０Bへの要求と判定する。

このとき、モジュール２０Aは、モジュール２０Bへの要求であると判定したときには、モジュール２０Bへ要求を転送する（ステップ６００３）。要求を受け取ったモジュールBは処理を開始する（ステップ６００４）。処理が完了したときには、モジュール２０Aはモジュール２０Bから完了報告をもらい（ステップ６００５）、ホスト５１Aへ返答する（ステップ６００６）。

ステップ６００２で自分のモジュールの処理と判断したときには、モジュール２０Aは処理を開始する（ステップ６００７）。なお、ホスト５１Bからモジュール２０Aへの要求時もその逆で同様に行う。

前記実施形態では、２つのサブストレージシステム２０A、２０Bを１つのストレージシステム１００へ結合するパターンを示したが、複数のサブストレージシステムを１つのストレージシステムへ結合する場合も同様に処理する。この場合、ネットワーク４０Aと４０Bを接続してもよいし、しなくてもよい。複数サブストレージシステム２０A、２０B、２０Cの場合、２０Aと２０B間及び２０Bと２０C間に接続線４４を設けてもよいし、サブストレージシステム２０A、２０B、２０Cのすべての間に接続線４４を設けてもよい。

＜複数モジュールが結合して密結合構成を成す場合＞
複数モジュールが結合して密結合構成を成すときの処理を図１２のフローチャートにしたがって説明する。まず、モジュール２０Aは、ホスト５１から要求を受け取ったときに（ステップ６１０１）、要求されたLUN情報が格納されているアドレスの位置を計算する。例えば、ボリューム管理情報テーブルの格納された先頭アドレスを各モジュールで覚えておき、LUNから何番目（＝N）の情報かを計算し、先頭アドレス+Nにて求める情報の格納されているアドレスを計算する（ステップ６１０２）。この際、図１１（b）に密結合の場合の制御情報の持ち方の例を示す。テーブルについては後述する。

モジュール２０Aは、メモリ２２A内にあるボリューム管理情報テーブル２０５を参照し、ホスト５１Aから要求のあったLUNが自分のモジュール内のものか他のモジュール内のものかを判断する（ステップ６１０３）。例えば、LUN＝“０１０”の場合は、管理者識別子がモジュール２０Aを示しているので、モジュール２０Aは、自分のモジュール内への要求と判断し、LUN＝“０２０”の場合は、モジュール２０Bへの要求と判断する。このとき、モジュール２０Bへの要求であると判断したときには、モジュール２０Aはモジュール２０Bへ要求を転送する（ステップ６１０４）。要求を受け取った２０Bは処理を開始する（ステップ６１０５）。処理が完了したモジュール２０Aはモジュール２０Bから完了報告をもらい（ステップ６１０６）、ホスト５１へ返答する（ステップ６１０７）。ホスト５１Bからモジュール２０Aへの要求時もその逆で同様に行う。

結合されたボリューム管理情報テーブル２０５は、単一アドレス空間のどこかのアドレス上に存在する。上記の例では、ボリューム管理情報テーブル２０５がモジュール２０A内のメモリ２２A内に入っている場合についての処理であるが、モジュール２０B内のメモリ２２B内に入っている場合もあるし、モジュール２０Aと２０Bに分散して格納されている場合もある。密結合構成の場合も、リードライトの処理は、制御を担当しているモジュールが処理する例を示したが、他のモジュールのメモリを参照して要求処理まで実行しても良い。

≪制御情報の例≫
図７に、結合前の制御情報の一例であるボリューム管理情報テーブル２０１Aと２０１Bを示す。サブストレージシステム２０Aには、サブストレージシステム２０A内のリソースの管理情報、サブストレージシステム２０Bには、サブストレージシステム２０B内のリソースの管理情報が入る。ボリューム管理情報テーブル２０１Aと２０１Bは、モジュール２０A、２０B内のメモリ２２にそれぞれ格納されている。

ボリューム管理情報２０１は、LUを識別するための識別子である「LUN番号」、LUに割当てられた「ボリューム番号（＝LDEV）」、ボリュームの属性を示す「ボリューム管理情報」からなる。ボリューム管理情報は、ボリュームが使用中/未使用や、属性（エミュレーションタイプ、サイズ、RAID構成など）が入る（図示せず）。さらに、リソースを管理しているモジュールを示す「管理者識別子」がある。この管理者識別子は、結合したときに、モジュールを示すためのユニークなものである。

図７では、ボリューム管理情報テーブル２０１Aには、サブストレージシステム２０Aを示す管理者識別子が入り、ボリューム管理情報テーブル２０１Ｂには、サブストレージシステム２０Ｂを示す管理者識別子が入る。他のテーブルとしては、空き領域管理のテーブルなどがある。

尚、ここでは、テーブル形式を例に挙げているが、情報の保持形式は他の形態でもよく、発明の本質ではない。

≪制御情報の結合 ステップ１００２の詳細≫
次に、図７のボリューム管理情報を結合する例を挙げて、ステップ１００２の制御情報の結合について説明する。

図１１（ａ）のボリューム管理情報２０３Aは、ボリューム管理情報２０１Aにボリューム管理情報２０１Bの情報を結合したものである。但し、ボリューム管理情報２０１Bに相当する箇所は、LUN番号とそのLUNが使用するモジュールを表す管理識別子の情報が記載される。ボリューム管理情報２０３Aはモジュール２０A内で管理する。ボリューム管理情報２０３Bの場合も同様な関係となる。管理識別子が別のモジュールのものであるLUN関連の情報については、前記管理識別子が示すモジュール内に詳細な情報があり、前記管理識別子が示すモジュールへ問い合わせて詳細情報を入手する。

図１１（ｂ）は別の形態の制御情報の管理である。こちらは、ボリューム管理情報テーブル２０１Aと２０１Bを１つに統合してボリューム管理情報テーブル２０５としている。ボリューム管理情報テーブル２０５は、ストレージシステム１００で１つ持つ。バリエーションとして、ストレージシステム１００内の特定のモジュール２０で１つ持つ、又は、全体管理装置５０に持つ場合もある。

ボリューム番号など、論理ストレージシステム内で使っていた番号のままでもよいし、ストレージシステム１００内で通し番号になるように番号を付け直しても良い。この方法については後述する。

図１１（a）は、結合後、疎結合構成のストレージシステムの場合、図１１（b）は結合後、密結合構成のストレージシステムの場合である。

サブストレージシステムの結合に伴い、ホスト５１AからモジュールB内への論理ボリュームを認識し、モジュール２０Bの論理ボリュームへの要求をホスト５１Aからも出すためには、パスの定義を行う。

＜結合後疎結合の構成＞
図１３（a）に結合後疎結合構成を取る場合のメモリ情報とプログラムを追加したものを示す。結合したことで、他のモジュールの情報を持つ必要があり、これは、図１１（a）のように持てば良い。結合したことで、要求が自分モジュール内の要求か否かを判定するための処理および要求を他のモジュールに転送するためのプログラムが必要となる。

＜結合後密結合の構成＞
図１３（b）に結合後密結合構成を取る場合のメモリ情報とプログラムを追加したものを示す。サブストレージシステムを結合したことで、各モジュールは、他のモジュールのメモリも含めて単一アドレス空間として認識する必要がある。例えば、制御情報は結合して連続アドレス空間に置く（このようにすると、ステップ６１０２の例のように、アクセスできる。）。または、各モジュールの情報の先頭アドレスを認識し、求めたい情報が格納されているアドレスを認識すれば、他の方法でも良い。

≪管理の結合 ステップ１００３の詳細≫
前提として、サブストレージシステム２０Aと２０Bにそれぞれ管理者が存在する。ここでは、管理装置５０A（５０B）を操作する人をサブストレージシステム２０A（２０B）の管理者と呼ぶ。

ストレージシステムにて管理者アカウントの情報テーブルを持つことになる。図１４に、結合前の管理者アカウント情報テーブルの例を示す。管理者アカウントの情報テーブル１９０Aは、サブストレージシステム（結合後はモジュール）２０Aが持つテーブルである。「ユーザID」は、結合前のサブストレージシステム２０A内の管理者アカウントを示したもので、サブストレージシステム２０A内でユニークな識別子となっている。「パスワード」は、管理者アカウントにて、管理装置５０Aにログインするためのものである。サブストレージシステム２０Aにアクセスするために、管理装置５０AからユーザIDとパスワードが必要になる。「アカウント識別子」は、管理者アカウント１９０Aの場合は、サブストレージシステム２０A（またはモジュール２０A）と記載されている。

サブストレージシステム２０Bの場合も同様に、管理者アカウントの情報テーブル１９０Bを持つことになる。

サブストレージシステム２０Aと２０Bを結合する場合、管理者アカウントの統合の仕方には、次の３つのバリエーションがある。

（１）管理者アカウントをどちらか一方のアカウントに統一する。
（２）新規に結合のストレージシステムの管理者アカウントを作成する。
（３）それぞれの管理者アカウントはそれぞれのモジュールの範囲で有効とする。

≪（１）管理装置５０Aを残し、管理装置５０Bを廃止するケース≫
サブストレージシステム２０Aと２０Bを結合後、ストレージシステム１００となった場合に、管理者を１人にして、ストレージシステム１００全体を管理する。ここでは、管理装置５０Aを残し、管理装置５０Bを廃止する例を挙げて図１５のフローチャートに従って説明する。

管理装置５０Aと５０Bのネットワークを接続する（ステップ４００１）。もともと同じネットワーク上に管理装置５０Aと５０Bがある場合は、ステップ４００２へ進む。管理装置５０A、５０Bには、ストレージシステムを結合した場合に全体管理装置５０になる全体管理者プログラム５０１を搭載しておく（図１６（ａ））。または、サブストレージシステム２０A、２０B側のメモリ内に全体管理者プログラム５０１を置いておき、結合時に管理装置へ送信する（図１６（ｂ））。

ユーザの入力により、管理装置５０Aが全体管理装置５０になることを指示する（ステップ４００２）。指示を受け取った管理装置５０Aは、全体管理プログラム５０１を起動し、管理装置５０Aは他の管理装置５０Bに対し、全体管理者になったことを通知する（ステップ４００３）。管理装置５０Bは通知を受けたら、自分は全体管理者にはならないことを認識し、全体管理者５０Aの指示により、管理装置５０Bにて管理する制御情報を全体管理装置５０Aに送信する（ステップ４００４）。

管理装置５０Bは、全体管理装置５０Aから受信の完了報告を受けたら、以降、管理者アカウントはモジュールBの入力を受付けず、要求も出さない設定に切換える（ステップ４００５）。つまり、管理装置５０Bは廃止する。管理装置５０Bは、ネットワーク上に置いたままでも良いし、外しても良い。管理装置５０Aにある管理者アカウントの管理者種別を全体管理者として、モジュール２０Aとモジュール２０B両方を受け持つ管理者とする（ステップ４００６）。このとき、管理者アカウント情報テーブル１９０AのユーザIDを残し、管理者アカウント情報テーブル１９０BのユーザIDは削除する。管理者アカウント情報テーブル１９０Aのアカウント種別を“モジュール２０Aの管理者”から“全体管理者”へ変更する。ストレージシステム１００側は、管理装置が５０Aであることを認識する（ステップ４００７）。

≪（２）新たに管理装置を設けて、それを全体管理者とするケース≫
管理装置５０Aと５０B以外に新たな管理装置５０Mを設けてストレージシステム１００の全体管理者として設定し、サブストレージシステム２０Aと２０Bを管理装置５０Mから管理する処理を図１７のフローチャートに従って説明する。

管理装置５０Aと５０Bのネットワークを接続する（ステップ５００１）。もともと同じネットワーク上に管理装置５０Aと５０Bがある場合はステップ５００２へ進む。

次に、ネットワーク上にPCなどの新規装置を接続し、これを全体管理装置５０Mとする（ステップ５００２）。管理装置５０M、全体管理者としての設定を行うための全体管理者設定プログラム５０１持ち、前記プログラムを起動する。管理装置５０A、５０Bは管理装置５０Mからの指示により、管理装置５０A、５０B上で管理する制御情報を管理装置５０Mへ送信し、管理装置５０Mにて制御情報を一括管理するように設定する（ステップ５００３）。管理装置５０Mから制御情報の一括管理処理の完了を受け取った管理装置５０A、５０Bは、ネットワークから切り離すもしくは使用しない状態（管理者アカウントを無効にする又は破棄する）にする（ステップ５００４）。

このとき、管理装置５０A、５０Bは、管理者アカウント情報テーブル１９０Aと１９０Bを削除（ユーザIDを削除）し（ステップ５００５）、管理者アカウント情報テーブル１９０を新規に設け、アカウント種別を“全体管理者”に設定する（ステップ５００６）。ストレージシステム１００の管理装置が管理装置５０Mになったことをストレージシステム１００へ報告する（ステップ５００７）。ストレージシステム１００側でも認識する。管理装置５０Mは交替系を持たせ、２重化しておいても良い。

＜（３）管理装置５０A、５０Bはそれぞれのモジュールの範囲で有効。分割ストレージ管理者のイメージのケース＞

次に、サブストレージシステム２０Aと２０Bを結合したあとの処理を図１８のフローチャートにしたがって説明する。まず、サブストレージシステム２０Aと２０Bを結合後（ステップ７００１）、ストレージシステム１００となった場合に、管理装置５０Aと５０Bはそのまま存在させ、管理装置５０A（５０B）は、モジュールとなった２０A（２０B）内を管理する。管理装置５０A（５０B）はモジュール２０A（２０B）内のリソースについては管理しない。管理者アカウント情報テーブル１９０Aと１９０Bはそのまま使用するため、１９０A内のユーザIDと１９０B内のユーザIDが同じである場合が生じる。同一のユーザIDは、どちらかを別のユーザIDに変更する必要がある。ここでは、１９０B側のユーザIDを変更する（ステップ７００２）。

全体を管理する全体管理者が必要なため、結合前に、全体管理者を設けておく（ステップ７００３）。管理装置５０Aか５０Bのうちどちらかが全体管理者を兼任しても良いし、ネットワーク４０上に新規に全体管理者用の管理装置５０Mを設置しても良い。

管理アカウントの統合については、例えば、暗号鍵の統合がある。従来、暗号鍵はボリュームやストレージシステム単位に設定される。ここではストレージシステム単位、サブストレージシステム２０Aと２０Bで異なる暗号鍵を設定し、サブストレージシステム２０Aと２０Bを結合して、ストレージシステム１００とした場合を考える。管理者アカウントは、それぞれの担当のモジュールの暗号鍵などの暗号情報を持っている。

サブストレージシステムを結合した場合、ストレージシステム１００の全体管理者は、サブストレージシステム２０Aの暗号鍵とサブストレージシステム２０Bの暗号鍵を両方認識・管理する。または、暗号鍵の統一をするため、新たに暗号鍵をストレージシステム１００に再設定し、ストレージシステム１００の全体管理者はそれを認識・管理する。
これに対して、後述する処理、ストレージシステム１００をストレージシステム２０Ａと２０Ｂに分割する場合は、暗号鍵を分割するため、ストレージシステム２０Ａと２０Ｂ用に暗号鍵を生成し再設定し、ストレージシステム１００の全体管理者はそれを認識・管理する。

結合後、全体管理者は、ストレージシステム１００内にある全ての未使用リソース（空きリソース）を管理する。空きリソース情報テーブルの例を図１９に示す。図１９（a)に、結合前のテーブルを示す。空きポート情報テーブル２１０Aと空きHDD情報テーブル２２０Aはサブストレージシステム２０Aが持つ。ポート番号ごとに、空き状態として、「使用中」、「未使用」を持つ。空きHDD情報も同様にHDD番号ごとに、空き状態を持つ。同様に、空きポート情報テーブル２１０Bと空きHDD情報テーブル２２０BはサブストレージシステムBが持つ。ポート番号やHDD番号は、それぞれのサブストレージシステム２０Aまたは２０B内でユニークである。

結合後密結合構成のストレージシステム１００になる場合に、空きリソース情報テーブルを結合する処理を行う。

図１９（b）は、結合してストレージシステム１００になっても、２つの空きポート情報テーブル２１１Aと２１１Bを保持する場合の結合例である。結合前の空きポート情報テーブルより、ポートの所属モジュールを明確にする必要があるため、テーブルに「所属モジュール」の情報を持たせてある。空きポート情報テーブル２１１Aに対して「所属モジュール」の情報を別のテーブルに持たせても良い。

図１９（c）は、結合してストレージシステム１００になった場合、空きポート情報テーブルを１つ保持する例である。テーブルを１つにする場合、結合前のポート番号がモジュール２０Aとモジュール２０Bで同じ番号を持っている場合は、結合後のストレージシステム１００内でユニークになるように、番号を付け替える必要がある。

ストレージシステム１００内の全リソースを管理できるように、管理装置５０Mは、管理装置５０Aと５０Bから結合前に持っていた空きリソース情報を受信する。サブストレージシステム２０Aと２０Bを結合後は、管理装置５０A、５０Bの管理者は、各モジュールの管理者がモジュールの範囲を意識せずに、他のモジュールのリソースを含む全てのストレージシステム１００内のリソースを使用できる。

＜疎結合の場合の空きリソースの割付＞
リソースを割り付ける際には、まず自分のモジュール内の空きリソースを探してから割り付ける。自モジュール内のリソースが足りなくて割り付けられない場合は、全体管理者が持つ空きリソース情報から、リソースが十分あるモジュールを選択し、そのモジュールのリソースを割り付ける要求を、リソースを持つモジュールへ送信して割付処理を行う。

割付の処理を図２０のフローチャートにしたがって説明する。リソースの割付は具体的には、モジュール２０AのLDEV＃１０００に、データ領域を割当てる場合（図２１（a）参照）の処理を使って説明する。

モジュール２０AはLDEV＃１０００のデータ領域をモジュール２０A内から割当てるものを検索する（ステップ２１０１）。このとき、データ領域が新規に確保できない場合（ステップ２１０２）、全体管理者に空きデータ領域があるモジュールを検索してもらう（ステップ２１０３）。データ領域を新規に確保できるときには、データ領域を割り付ける（ステップ２１０７）。全体管理者は、他のモジュールで空きデータ領域があるモジュール番号２０Bをモジュール２０Aへ通知する（ステップ２１０４）。モジュール２０Aは、モジュール２０BにLDEV＃１０００のデータ領域を確保することを要求する（ステップ２１０５）。モジュール２０Bは要求を受け取り、データ領域を確保してモジュール２０Aへ通知する（ステップ２１０６）。

＜密結合の場合の空きリソースの割付＞
リソースの割付は、具体的には、モジュール２０AのLDEV＃１０００に、データ領域を割当てる場合（図２１（b）参照）の処理を使って説明する。
モジュール２０Aは、LDEV＃１０００のデータ領域を割当てるものを検索する。この際、テーブルは、図２１（b）に示すものであり、モジュールを示す管理識別子は意識せずに空いているものを選択する。

この際、同じリソースを同時に異なるモジュールに割り付けることがないように、管理装置５０Ａが操作中は、他の管理装置５０Ｂは排他される制御をする。１つの方法として、全体管理者が操作中の管理装置を認識するビットマップをもち、操作する前に、管理装置が全体管理者に前記ビットを‘１’にする（初期状態は‘０’）。操作を開始する前にビットを参照し、ビットが‘１’の場合は、他の管理装置は操作ができない。管理装置の操作が終わったら、前記ビットを‘０’に戻す。

＜リソース番号の付け直し＞
モジュールの結合時に、単純にモジュールのリソース番号をユニークになるように付け替える（リナンバリング）方法がある。例えば、ボリューム番号を付け替えた場合、管理者アカウントへ番号をつけかえてことを通知する。その際に、どの番号をどの番号へ付け替えたか、又は、新しい番号の算出方法（例えば演算式）も渡す。管理者アカウントでは、番号が変わったことを認識し、ユーザへ画面で表示する際には、旧モジュール単位（例えば、モジュール２０A、２０B）での論理ボリューム番号で表示する方法と、ストレージシステム１００で通し番号となった新しい論理ボリューム番号で表示する方法とを選択できる。画面イメージを図２２に示す。

別の方法として、LDEV層３８１の上位であって、LUN３８３の下位に、グローバルLDEV層３８２を設ける（図２３参照）。グローバルLDEV層３８２は、LDEV層３８１と違って、複数モジュール２０に跨っている。別の言い方をすれば、個々のモジュール２０でのみ管理されるLDEVの上位に、全てのモジュール２０で管理されるグローバルLDEVが設けられる。LDEV層は各モジュール２０A〜２０N内でユニークな番号が付与されるため、モジュール２０Aと２０Bで同じLDEV番号（前記のボリューム番号と同じ）が存在してもよい。

グローバルLDEV層はストレージシステム１００でユニークな番号が付与されるため、各モジュール２０A〜２０N間でもユニークとなる。グローバルLDEVは、仮想的なLDEVであって、複数のモジュール２０内の複数のLDEVのうちのいずれかに関連付けられるLDEVである。また、グローバルLDEVには、LUNが関連付けられる。管理者アカウントはグローバルLDEV層の番号を使用する。

次に、結合構成のストレージシステムの運用バリエーションについて説明する。

バリエーション１：ホスト５１Aからモジュール２０Aを認識し、モジュール２０Bは外部ストレージシステムを構成するイメージ。
この際、ホスト５１Aは、モジュール２０Aを認識するが、モジュール２０Bのボリュームを認識せず、モジュール２０Bはモジュール２０Aの外部ストレージシステム構成（後述）として認識する。通常のリードライト処理は外部ストレージシステム構成とほぼ同様となる。但し、密結合構成の場合には、モジュール２０Aがモジュール２０Bのキャッシュメモリに直接書き込む処理にて実行できる点が異なる。

ここまでの「外部ストレージシステムに見せる」という運用（見せ方）は公知技術である。発明のポイントは、見せ方だけではなく、それぞれのモジュールで稼動していたものを、外部ストレージシステム構成に見せるような結合の仕方と、 それに伴う管理の統合にある。外部ストレージシステムの管理者の情報は、従来技術の外部ストレージ構成の場合は、外部ストレージシステム側にあり、図１のネットワーク４０上にはない。これに対し、本発明の構成では、管理者の情報はモジュール２０Aもモジュール２０Bも管理装置５０にあることが相違点となる。これにより、モジュール２０Bが外部ストレージシステム構成であっても、モジュール２０Aとモジュール２０Bの管理の統合が可能となる点がメリットである。

図２４(ａ)に、これまでの結合構成を、図２４(ｂ)にバリエーション１を示す。結合構成では、パス定義がモジュール間にまたがって行われる可能性があり、ホストからもモジュール２０BのLDEV情報が見える。バリエーション１の構成では、パス定義はモジュール２０Aとのみしか行われず、ホスト５１に見えるLDEV情報もモジュール２０Aの仮想LDEVであり、仮想LDEVが割り付けられたモジュール２０BのLDEV情報は見えない。２つの構成の管理装置５０の画面から見えるイメージも図示した。

図４２にモジュール２０Ａと２０Ｂを結合する前（図４２（ａ））と後（図４２（ｂ））の制御情報のテーブル例を示す。モジュール２０Ａは、ボリューム管理情報テーブル２０３Ａを持ち、モジュール２０Ｂは、ボリューム管理情報テーブル２０３Ｂを持つ。モジュール２０Ａと２０Ｂを結合し、ボリューム管理情報は、（ｂ）のボリューム管理情報テーブル２０３１となる。

２０３１は、２０３に、「外部ボリュームとして使用するか否か」、使用する場合、仮想化する「外部ストレージ番号」と外部ストレージ側のボリューム番号である「外部ストレージのボリューム番号」の情報が追加される。（ｂ）では密結合構成の例で示した。ホスト５１Ａからは、２０３１のボリューム番号＃０と＃１が見えており、ボリューム＃２と＃３は見えていない。ホスト５１Ｂからは、ボリューム番号＃３が見えており、ボリューム＃０、＃１、＃２は見えていない。

バリエーション２：バリエーション１＋上記結合構成
ホスト５１Aからはモジュール２０Aと２０Bをそれぞれ認識し、ホスト５１Bからはバリエーション１の見え方、即ちモジュール２０Bを認識するが、モジュール２０Aのボリュームは認識せず、モジュール２０Aはモジュール２０Bの外部ストレージ構成として認識する。

バリエーション３：ネットワーク上のストレージシステムの結合（図２５参照）
モジュール２０Ａ〜２０α（複数）がネットワーク上にあり、そのうち任意のもの同士を結合/分割する。ネットワーク上にあることで、各モジュール２０同士の距離に制約がなくなり、自由に構成を組めるメリットがある。前記疎結合構成においては、より柔軟な構成が組める。制御情報は、通常、モジュール２０ごとに保持しているため、モジュール２０Ａと２０Ｂを統合する際には、両方の制御情報を既出の「密結合」か「疎結合」の方式を取る。

バリエーション４：リモートコピー接続で使用しているストレージシステムを結合（図２６参照）
リモートコピーのローカルサイトとリモートサイトのストレージシステムを結合し、管理者の情報を統合する。結合後も、リモートコピー処理は継続され、結合後のストレージシステム内コピーとして処理される。リモートコピーのローカルサイトとリモートサイトの管理の統合が可能となる点がメリットである。管理の統合のために、管理装置５０Aと５０Bをネットワークで接続してもよいし、管理装置５０Aまたは５０Bのどちらかにローカルサイトの管理者とリモートサイトの管理者の両方のアカウントを作成してもよい。また、全体管理者を設け、例えば前述した暗号鍵などのモジュール２０Aの情報とモジュール２０Bの情報を統合管理する。

ペアボリューム情報やペアのコピー状態などのリモートコピー制御情報は、リモートコピーのローカルサイト側が持っている。モジュールの統合により、前記制御情報はローカルサイトとリモートサイトで共有される。リモートコピーのペア情報は、モジュール番号とボリューム番号を保持する。図４３に示すモジュール２０Ａと２０Ｂの結合後の例では、リモートコピーペア管理情報テーブル２０３２は、ペア番号＃０のペアはモジュール２０Ａ内のボリューム番号＃０とモジュール２０Ｂ内のボリューム番号＃２からなり、ペア状態はリモートコピー中であることを示す。

上記バリエーションでは、モジュールが２つの場合を例に挙げたが、モジュールが３つ以上の場合も同様である。また、例としてホスト５１Aで記載しているが、ホスト５１Bにしても同様である。

＜ストレージシステムの分割＞
図２７にストレージシステムの分割概要処理のフローチャート図を示す。図１に示すストレージシステム１００をサブストレージシステム２０Aと２０Bに物理的に分割する処理を説明する。

ストレージシステム１００は、予めモジュール２０Aと２０Bが結合されたシステム構成でもよいし、そうでなくてもよい。モジュール２０Aと２０Bが結合されたシステム構成でない場合は、分割する際、どのリソースをどのモジュールの管理下にするかを決める処理を行う。具体的には、LDEV番号でわけてもよい。パス番号で分けても良く、その場合は、パスが所属するモジュール番号が決まると、パスに付随するLUNも同じモジュール所属となり、LUNに割り付けられているLDEV番号も同じモジュール所属となる。

分割処理は処理を開始後すぐに、サブストレージシステム２０A、２０Bはそれぞれの範囲内のリソースしか利用できない処理が必要となる。具体的には、他のストレージシステムのリソースを利用しようとすると、エラーにする。

一方、サブストレージシステム２０Aと２０Bに分けるため、制御情報を分割する。制御情報はサブストレージシステム２０Aと２０B内にそれぞれ設定する（ステップ８００１）。また分割範囲（ここで言うモジュール）に対する識別子（ここで言うモジュール番号）をそれぞれ設定する。以下、モジュール番号を“２０A”と“２０B”とする。

サブストレージシステム２０Ａと２０Ｂに物理的に分割できない箇所があれば、物理的に分割できるように、データを移動する（ステップ８００２）。データの移動が発生するケースは、論理的なリソースと実データの格納場所のモジュールが異なる場合や、前記格納場所が設定しようとしている物理的な境界にまたがる場合である。また、リソースとそのリソースに割り付けられたリソースが所属するモジュールが異なる場合がある。これらを、分割する際に「またがる」と定義する。例えば、別のモジュールに所属するパスに付随したLUNに割り付けられたLDEVにコピーボリュームや仮想ボリュームの実データが格納されているボリュームに割りあたっている場合がある。具体例として、図３０に示す。詳細は後述する。

次に、モジュール２０Aと２０B間の接続線（分割部）４４を分離する（ステップ８００３）。ストレージシステム１００が複数モジュールにより結合された構成でない場合は次のステップへ進む。

管理装置５０をサブストレージシステム２０Aと２０Bに対する管理装置５０Aと５０Bに分割する（ステップ８００４）。管理装置５０を使って、サブストレージシステム２０Aと２０Bに対する管理者を別々においてもよい。この際、ストレージシステム１００はサブストレージシステム２０Aと２０Bに分割される。

ストレージシステム１００を分割後は、サブストレージシステム２０Aと２０Bは、それぞれホスト５１A、５１Bからアクセスされる。ホスト５１A（５１B）からはサブストレージシステム２０B（２０A）内のリソースは使えない。この際、モジュール２０A、２０BのCPU２１と管理装置５０Aと５０BのCPUは、分割されたモジュール２０Aと２０Bを、ホスト（上位計算機）５１A及び５１Bに対して、それぞれ独立のアクセス対象として管理するとともに、独立の運用対象として管理する分割管理部として機能する。

本実施形態では、１つのストレージシステムを２つのストレージシステムに分割するパターンを示すが、１つのストレージシステムを複数のストレージシステムに分割する場合も同様に処理する。

≪分割する範囲の決定 ステップ８００１の詳細≫
ストレージシステム１００を分割する場合、図１のようにストレージシステム１００の中にモジュール２０Aと２０Bがある場合は、前記モジュール毎に分割する。

ストレージシステム１００にモジュールがない場合、ストレージシステム１００の分割後の各管理者の管理リソースの範囲を決定する。管理リソースには、論理リソースであるLDEV、キャッシュサイズ、論理的なポートがある。LDEVには、実LDEV、Thin Provisioningなどで使用する仮想VOLなどの種類がある。ボリューム管理情報などの制御情報も前記リソースと同じモジュールになるように分割する。

ユーザは、管理装置５０の画面から、各リソースにモジュール番号を指定する。例えば、LDEV＃１００はサブストレージシステム２０Aに割り当てたが、LDEV＃１００が今まで割り当たっていたパスが、サブストレージシステム２０Bに割り当てられた場合、パスとLDEV＃の関係を維持するために、同じモジュールになるように割り付ける。この場合、別の方法としては、パスに合わせてLDEVをパスと同じモジュール２０Bに割り付ける。

また、ボリュームと物理ブロックのマッピングもまたがらないように範囲を決める。また、ユーザが１つ１つ指定する方法とは別に、ユーザが決定しやすいように、リソースとモジュールを管理装置５０側で予め決め、それを管理装置の画面に出すユーザ支援のプログラム（図示しない）が管理装置５０にあってもよい。

ストレージシステム１００の分割する範囲又はモジュールを決めた後に、その範囲をまたがる指示や要求を受けた場合、受けたモジュールは、要求者にエラーを返す。ストレージシステムの分割範囲が決まる前は、範囲間でまたがった要求や指示があっても、それらは受けて処理は継続する。その後、データや制御情報のモジュール間移動を行う。

≪データの移動 ステップ８００２の詳細≫
モジュール２０Aと２０Bに分割する場合、前記モジュール２０Aと２０Bの間でリソースの「またがり」が発生しているか否か検索する。またがりが発生していれば、モジュール間でのデータ移動のスケジュールを立てる。具体的には、どこへ移動するか移動先のモジュールとボリュームを決定し、移動処理を実行する。データの移動に伴い制御情報を更新する。

モジュール２０Aと２０Bがない構成で、ステップ８００１で分割する範囲を決定し、分割範囲の間に「またがり」が発生する場合も同様にデータの移動を行う。

図２８（a）に、疎粗結合構成のストレージシステムを分割する場合のメモリ情報の例を示す。他のモジュールの情報は制御を担当するモジュールへ移動し、削除する。結合のために必要であって、他がどのモジュールの担当のものかを判定する処理や担当モジュールへ要求を転送する処理のプログラムは不要となる。

図２８（b）に密結合構成のストレージシステムを分割する場合のメモリ情報の例を示す。ボリューム管理情報と空きリソース管理情報を、制御を担当するモジュールのものに分割し、それぞれのメモリのアドレス内に格納する。

＜（運用管理の分割 ステップ８００４の詳細）＞
運用管理に関する情報を分割する操作は、管理の結合の逆の操作となる。この際、モジュール２０A、２０Bそれぞれに管理装置５０A、５０Bが設置されるようにする。全体管理装置５０をモジュールの１つの管理装置とし、他のモジュールには管理装置５０をネットワーク上に追加しても良いし、管理装置５０上にモジュール２０Aと２０Bの管理者アカウントを設定しても良い。

運用管理を分割するに際しては、下記の管理の仕方によって、分割の方法を採用することができる。

（１）全体管理者による管理されている。元々１つだった運用管理を分割後も可能とする。モジュール２０Aとモジュール２０Bから管理者アカウントを認識させる。
（２）モジュールごとに全体管理者によって管理されている。

上記全体管理者だけによって管理されているストレージシステムを分割する場合は、分割するモジュール単位にアカウントを分割する必要がある。全体管理者によって管理されている制御情報を、制御を担当するモジュールごとに分割し（図２９参照）、各アカウントをモジュールに認識させる。全体管理者アカウントは廃止する。空きリソース情報についても、同様に、制御を担当するモジュールごとに分割する。そのリソースの制御を担当するモジュール側の空きリソース情報のテーブルへ記載する。

＜Thin Provisioningについて＞
Thin Provisioning（シンプロビジョニング）は仮想ボリュームを使った技術で、データの書き込みに基づいて動的にディスクを割り当てる技術である。コピー元のボリューム（正ボリューム）の容量をプール領域から割り当てる。

CoWS（CopyOnWriteスナップショット）は、コピーボリューム（副ボリューム）を作成する技術である。複数世代の副ボリュームのうち，アクセス単位のデータが同一の内容である場合，そのデータは一つだけプールへ格納し，複数世代からそのデータを参照する。副ボリュームは仮想ボリュームとなる。ボリューム全体のコピーであるレプリケーション機能の全コピーは行わず，正ボリュームまたは副ボリュームへのライト処理時に，ライト前データをプールへ退避した後，ライト処理を行う。ライト前データを参照していた世代が複数ある場合は，全てデータがどこになるかのマッピング情報を変更する。

これらの技術において、プールを使用するが、プールの結合分割についてThin Provisioningを例に挙げて説明する。

≪Thin Provisioningのプールの結合≫
図３０に、モジュール結合時のThin Provisioning プールの管理方法を示す。Thin Provisioningを使っている場合、モジュールの結合後は、ストレージシステム１００内のプールを使用することができる。

サブストレージシステム２０A、２０Bを結合してストレージシステム１００となった場合に、モジュール２０Aと２０Bにあるプールを結合する。図３０（ａ）は、モジュール２０Aと２０Bにそれぞれ２つずつプールがある場合の結合の一例を示している。モジュール２０Aのプール２４５Aとモジュール２０Bのプール２４５Bを結合してプール２４９１を新たに作成する。

また、モジュール２０Aのプール２４６Aとモジュール２０Bのプール２４６Bを結合してプール２４９２を新たに作成する。仮想ボリューム２４２１Aはプール２４５Aを使用し、実データをおいていたが、プールを結合後は、プール２４９１を使用することとなり、プール２４５B内にもデータをおくことができるようになる。逆に、仮想ボリューム２４２１Bはプール２４５Aを使用できるようになる。また、ボリューム２４２２Aはプール２４６Aを使用していたが、同様にプール２４９２を使用することとなる。

図３０（ｂ）に示すように、モジュール２０Aの中の複数のプールとモジュール２０Bのプールを統合してもよい。

プールの情報を、図３１に示す。プール制御情報テーブル１０１は各モジュールにあるプール情報で、プールIDごとに、プールの使用できる総容量である「プール容量」、プール容量から使用している容量を引いた残りの容量である「プール残容量」、プールが少なくなってきたかどうかを判断するための「プール残容量閾値」、そのプールを使用する仮想ボリュームの番号「使用仮想VOLの番号」、プールを形成するプールボリュームのボリューム番号「使用プールVOLの番号」と総数「使用プールVOLの数」ある。

プール制御情報テーブル１０１は、結合前は、各サブストレージシステム２０Aと２０Bに持つ。図３２に、結合後のプールIDである結合プールの情報、結合プール情報テーブル１０２を示す。結合プールIDごとに、プール制御情報テーブル１０１に示す「プールID」とそのプールのあるモジュールを示す「モジュール番号」を登録する。

モジュール２０Aのプール＃０とモジュール２０Bのプール＃０を結合し、統合プール＃０とする例を取って、プールの統合処理（結合処理）を図３３のフローチャートにしたがって説明する。

まず、ユーザが結合したいプールを指定する。この際、ユーザはモジュール番号とそのモジュールにあるプール番号を指定する（ステップ２５０１）。例えば、モジュール２０Aのプール＃０とモジュール２０Bのプール＃０を指定する。統合プール情報は、全体管理者が管理する情報であるため、全体管理者が統合プールIDを作成する（ステップ２５０２）。プールが統合されたら、統合対象となったモジュール、ここでは、モジュール２０Aと２０Bにプールが統合されたことを通知する。

≪モジュールまたがりのプールの場合≫
図３４にThin Provisioningのプールがモジュールにまたがった例を示す。
モジュール２０Aにある仮想ボリューム２４２Aは、領域２４２１Aはプールボリューム２４８Aの領域２４８１Aに割り当たっている。領域２４２３Aは、モジュール２０Bにあるプールボリューム２４８Bの領域２４８１Bに割り当たっている。プールボリューム２４８Bの領域２４８Bはモジュール２０B内の仮想ボリューム２４２Bの領域２４２１Bにも割り当たっている。

図３５に上記の状態を管理する制御情報の一例を示す。図３５（ａ）はストレージシステム１００内で制御情報を一括管理する場合である。Thin Provisioningボリューム制御情報テーブル１０４として、仮想ボリュームの各領域がどのプールに割り当たっているかを示している。領域は具体的には、開始アドレスと終了アドレスを指定するなどにより決定する。また、その領域に番号をつけて管理してもよい。

図３５（ｂ）は、モジュール２０Aと２０Bとに制御情報を分けて管理する場合の例である。Thin Provisioningボリューム制御情報テーブル１０５Aはモジュール２０Aにあるテーブルである。同じものがモジュール２０Bにもある。Thin Provisioningボリューム制御情報テーブル１０５Aには、モジュール２０A内のThin Provisioningボリュームの各領域がどのプールボリュームに割り当てられているかを示している。

領域２４２１Aは、仮想ボリュームと同じモジュール２０Aにあるプールボリューム２４８Aの領域２４８１Aが割り当たっていることを示す。領域２４２３Aは、仮想ボリュームと異なるモジュール２０Bのプールボリュームに割り当たっているため、モジュール２０A内には、プールボリュームや領域の情報はなく、割り当てられた領域があるプールボリュームの所属するモジュール番号のみ示されている。一方、プールボリューム制御情報テーブル１０６Bによれば、プールボリュームがモジュール２０Aの仮想ボリューム２４２Aによって使われていることが示されている。

図３６は、ホスト５１がストレージシステムにボリューム番号が「1」である仮想ボリュームを作成し、当該仮想ボリュームに対してモジュール２０Aのポート６１５及びモジュール２０Bのポート６２６からパスを定義した状態である。また、モジュール２０Aはプール６１４を有し、モジュール２０Bは別のプール６２３を有している。

ボリューム番号が「1」の仮想ボリュームをモジュール２０Aとモジュール２０Bに作成する場合、各モジュール２０に仮想ボリュームテーブル１０５を持つ。矢印６１２は、仮想ボリュームの領域６１１がプールの領域６１３にページ割当している様子を示しており、矢印６２２は、領域６２１がプール領域６２３にページ割当している様子を示している。

矢印６３０が領域６２４へのリード、矢印６４０が領域６２１へのリードとする。モジュール２０Bは矢印６４０のリードを受領すると、仮想ボリュームテーブル１０５Bを参照し、領域６２１のページ割当状況をチェックする。チェックした結果、モジュール２０Bのプール６２３のページを使用していることが分る。このため、モジュール２０Bは、プール６２３に格納されているデータをホスト５１へ転送する。

一方、モジュール２０Bが矢印６３０のリードを受領すると、仮想ボリュームテーブル１０５Bを参照し、領域６２４のページ割当状況をチェックする。チェックした結果、モジュール２０Aのプール３００のページを使用していることが分る。この場合、モジュール２０Bは、モジュール２０Aにリード処理依頼６２５を発行する。そして、リード処理依頼を受領したモジュール２０Aがモジュール２０Bのページに対してリードを実行する。このように、ホスト５１から受領したＩ/Ｏの対象領域に対して、既に他モジュール２０でページが割当てられている場合には、モジュール２０間の通信が必要である。

≪Thin Provisioningのプールの分割≫
図３４で示したThin Provisioningのプールがモジュールにまたがったストレージシステム１００をモジュール２０Aと２０Bに分割する例を図３７に示す。モジュール２０Aと２０Bは、Thin Provisioningボリューム制御情報テーブル１０５Aと１０５Bを持つ（図３８参照）。まず、モジュール２０Aは、図３９に示すように、これらのテーブル１０５A、１０５Bからモジュールにまたがったプールを検索する（ステップ３１０１）。

この検索の仕方は、テーブル１０５Aの「モジュール番号」にモジュール２０A以外のモジュール番号が入っているものをテーブルの先頭から順に検索する。モジュールにまたがったプールがあるときには、モジュール２０Aは、次の処理へ以降し、無いときにはこの処理を終了し（ステップ３１０２）、テーブル１０５Aの「モジュール番号」に記載された他のモジュールへデータの移動要求を出す（ステップ３１０３）。ここでは、他モジュールはモジュール２０Bとする。その際、移動の対象となる「仮想VOL番号」、「領域」の情報を要求と共にモジュール２０Bへ渡す。またモジュール２０A内に確保した移動先となる領域情報も渡す。

モジュール２０Bは移動元モジュール２０Aから指示された領域をテーブル１０６Bから検索し、移動処理を実行するためのスケジュールを立て（ステップ３１０４）、スケジュールを実行する（ステップ３１０５）。移動が完了したら、モジュール２０Bはテーブル１０６Bと１０５Aを修正する（ステップ３１０６，３１０７）。

上記の処理は、ストレージシステム１００が疎結合構成の場合である。密結合構成の場合は、疎結合構成と同様に、要求を各モジュールで行うか、他のモジュール内の処理を自モジュールにて実施するケースが考えられる。

ここでは、モジュール２０Aとモジュール２０Bにデータがまたがっているモジュール２０Bにあるプールボリューム２４８Bをどうわかるかがポイントである。プールボリューム２４８Bはもともとモジュール２０Bの管理下のものであるため、モジュール２０B以外で使われている箇所をデータ移動させる。この例では、領域２４８１B内のデータを仮想ボリューム２４２Ａが使用しているモジュール２０A内のプールに所属するプールボリュームの領域、プールボリューム２４９Aの領域２４９１Aを確保してコピーする。

またがったものがなくなると、Thin Provisioningボリューム制御情報テーブル１０５Aから「モジュール番号」の情報が入るものはなくなり、プールボリューム制御情報テーブル１０６Bの「割当プールVOL番号」にも他のモジュールのボリューム番号が入ることはなくなる。

なお、コピー中に到着した要求への処理は、例えば、米国特許第７，１５５，５８７号に示す。

≪Thin Provisioningのデータ移動≫
前記データの移動と同様にデータをモジュール間で移動し、モジュール内に仮想ボリュームとプールが閉じるような構成にする。

本実施形態は、シンプロビジョニングについて説明するが、CoWSの場合は、複数の仮想ボリュームが同一データを使っている場合があり、そのデータを必要に応じてコピーすることのを忘れないことが必要となる。仮想ボリュームだけでなく、レプリケーションの場合も同じように、データを移動することでコピー元とコピー先のボリュームが同じモジュール内にあるような構成にする。

≪外部アクセス≫
次に、外部アクセスの処理を図４０のフローチャートにしたがって説明する。ホストからアクセス要求をサブストレージシステム２０が受信したら（ステップ３３０１）、I/Oプログラム（図示せず）は、その特定されたローカルLDEV番号が、内部LDEVに対応したものか、外部LDEVに対応したものかを、内部に保持するデバイス情報（図示せず）により判定する（ステップ３３０２）。つまり、アクセス要求が、外部LDEV７０１へのアクセス要求であるか、内部LDEV２４１へのアクセス要求であるかが判定される。

サブストレージシステム２０は、外部LDEV７０１へのアクセス要求であるならば（ステップ３３０２でYES）、外部LDEV７０１とのマッピングテーブル（図示せず）を参照し、外部LDEV７０１へのアドレス変換などを行って、外部LDEV７０１へのアクセス要求を外部ストレージシステム７０に送信する（ステップ３３０４）。一方、サブストレージシステム２０は、内部LDEV２４１へのアクセス要求であるならば（ステップ３３０２でNO）、内部LDEV２４１へのアクセスを行う（ステップ３３０３）。

≪ＬＤＥＶ連結構成≫
２つ以上の論理ボリューム（LDEV）を連結して１つのLDEVとして定義する連結LDEV構成というものがある。従来のLDEVサイズはストレージシステム内で予め上限が設定されるが，１つのLDEVサイズを超えてユーザに領域を提供することを目的とした機能である。前記連結LDEV構成を構成するLDEVが同じモジュールになるように分割する。

＜別システム構成＞
別のシステム構成としては、外部ストレージが接続されていてもよい（図４参照）。ＦＣインターフェース制御部２５は，サブストレージシステム２０と外部ストレージシステム７０との間のコマンドやデータの転送を制御する。尚，FCインターフェース制御部２５と外部ストレージシステム７０の間にSAN４３があってもよいし、FCインターフェース制御部２５と外部ストレージシステム７０とが光ファイバケーブルなどで直接接続されていてもよい。

外部ストレージシステム７０は，RAID構成された一つ以上のディスクドライブ７００を有する。ディスクドライブ７００は，FC（Fibre Channel）ディスクドライブ，SATA（Serial Advanced Technology Attachment）ディスクドライブ，PATA（Parallel Advanced Technology Attachment）ディスクドライブ，FATA（Fibre Attached Technology Adapted）ディスクドライブ，SAS（Serial Attached SCSI）ディスクドライブ或いはSCSI（Small Computer System Interface）ディスクドライブ等のストレージデバイスである。複数のディスクドライブ７００上には，外部LDEV７０１が形成されている。なお，ディスクドライブ７００に代えて又は加えて，他種の記憶デバイス（例えばフラッシュメモリ）があっても良い。

LDEV２４３は，実記憶領域を有しない仮想的なデバイスである。データを記憶する実体的な記憶領域は，後述の外部ストレージシステム７０内の論理デバイス７０１に存在する。即ち，サブストレージシステム２０は，外部ストレージシステム７０の外部LDEV７０１を自己の内部デバイスとして取り込み，これを論理ユニットとしてホスト計算機５１に提供している。ホスト計算機５１がUNIX（登録商標）系のシステムである場合には、論理ユニットは，デバイスファイル（Device File）に対応付けられる。ホスト計算機５１がWindows（登録商標）系のシステムである場合には，論理ユニットは、ドライブレター（ドライブ名）に対応付けられる。論理ユニットには，LUN（Logical Unit Number）がアサインされ、外部LDEV７０１があたかもサブストレージシステム２０の内部デバイスであるかのように仮想化する方法を採用することができる（例えば、特開２００５−１０７６４５号公報（ＵＳ出願番号１０／７６９８０５号，ＵＳ出願番号１１／４７１５５６号）。

次に他のシステム構成を図４１に示す。このストレージシステムにおいて、図１と同じ装置，同じ機能を持つものは同一番号を付して、それらの説明を省略する。

ストレージシステム１１０は，I/Fパッケージ部９０と制御部８０と不揮発メモリ２９，I/Fパッケージ部９０と制御部８０を接続するネットワーク３３，ディスク装置部２４及び７０からなる。各要素は少なくとも１つ以上からなる。

ストレージシステム１１０は、SAN４１を介してホスト計算機５１に接続されている。I/Fパッケージ部９０AはどのLDEVがどの８０に格納されているかを認識するための構成情報を格納している。構成情報は，８０内のローカルメモリ２２やメモリ２９にも格納されている。または、ネットワーク３３上に別のプロセッサ（図示せず）を設け、構成情報をおいてもよい。

I/Fパッケージ部９０Aは，ホストからのI/Oを受けると，コマンドを解析して，要求するデータが格納されているLDEVがどの制御部８０の配下に管理されているかを判断し，その制御部８０へI/Oを振り分ける処理を行う。また，I/Fパッケージ部９０B、ディスク装置２４及び７０へデータ転送も行う。制御部８０は，メモリ２９へデータを転送する。

尚，外部ストレージシステム７０は，サブストレージシステム２０とは異なる機種であってもよく，或いはサブストレージシステム２０と同一の機種であってもよい。サブストレージシステム２０Aと２０Bは別の筐体である外部ストレージシステム７０A、７０Bとそれぞれ接続していてもよい。上記構成にて，外部ストレージシステム７０は無くても良い。

図４１の構成において、ストレージシステム１１０を分割する際には、制御部８０単位に分割し、前記制御部８０が担当するLDEVの実データが格納されているディスク装置２４を制御部８０と同じストレージシステムに所属させる。ディスク装置２４が複数の前記制御装置８０が担当するLDEVの実データが格納されている場合、ディスク装置２４Aが所属している制御部８０Aと異なる制御部８０Bが担当するLDEVの実データは、データ移動する。

例えば、制御部８０Aに所属するディスク装置２４００Aに、制御部８０Bが担当するLDEVの実データが格納されている場合、前記実データはディスク装置Aからディスク装置２４００Bへデータを移動することで、制御部８０とディスク装置が物理的に分割できる。

本実施形態によれば、システム構成の変更（結合・分割）に合わせて情報を動的（オンラインで）に管理することができる。

また、本実施形態によれば、ストレージシステムの結合を動的に実施可能とし、複数企業・部門統合時の管理統一化を実現することができ、管理の統合により、管理端末の統合、管理者の統合が可能となり、ストレージシステムの結合により、各ストレージシステムにある空きリソースを相互に利用可能となる。

さらに、本実施形態によれば、ストレージシステムの分割を動的に実施可能とし、企業単位での管理、資源の利用を行うことで、性能を確保することができ、他の企業のＩ/Ｏにリソースを奪われることがなくなる。

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

本発明に係るストレージシステムのブロック構成図である。 サブストレージの結合方法を説明するためのフローチャート。 本発明の第２実施形態を示すストレージシステムのブロック構成図である。 本発明の第３実施形態を示すストレージシステムのブロック構成図である。 結合後のストレージシステムのブロック構成図である。 モジュールを疎結合または密結合した場合の内部構成図である。 結合前の制御情報の構成を示すボリューム管理情報テーブルの構成図である。 パス定義を行うときの構成を説明するための構成図である。 パス定義の処理を説明するためのフローチャートである。 疎結合構成における処理を説明するためのフローチャートである。 疎結合構成におけるボリューム管理情報テーブルと密結合構成におけるボリューム管理テーブルの構成図である。 密結合構成における処理を説明するためのフローチャートである。 制御情報を疎結合するときまたは密結合するときの内部構成図である。 結合前の管理者アカウント情報テーブルの構成図である。 管理者アカウントを結合するときの処理を説明するためのフローチャートである。 管理者アカウントを結合するときの内部構成図である。 管理者アカウントを結合するときの処理を説明するためのフローチャートである。 管理者アカウントの他の結合方法を説明するためのフローチャートである。 結合前の空きポート情報テーブルと結合後の空きポート情報テーブルの構成図である。 疎結合構成における空きリソースの割付方法を説明するためのフローチャートである。 疎結合構成におけるボリュームマッピング管理情報テーブルと密結合構成におけるボリュームマッピング管理情報テーブルの構成図である。 リソース番号の付け直しを行うときの画面の表示例を示す図である。 リソース番号の付け直しを説明するためのブロック構成図である。 結合構成のバリエーションを説明するための構成図である。 ネットワーク上のストレージシステムの結合を説明するための構成図である。 リピートコピー接続で使用しているストレージシステムの結合を説明するための構成図である。 ストレージシステムをサブストレージシステムに分割するときの処理を説明するためのフローチャートである。 疎結合のストレージシステムまたは密結合のストレージシステムを分割するときの内部構成図である。 運用管理の分割を説明するための管理者アカウント情報テーブルの構成図である。 プールの結合を説明するための内部構成図である。 プール制御情報テーブルの構成図である。 結合後の統合プール情報テーブルの構成図である。 プールの統合処理を説明するためのフローチャートである。 モジュールにまたがるプールの構成を説明するための内部構成図である。 Thin Provisioningボリューム制御情報テーブルとプールボリューム制御テーブルの構成図である。 仮想ボリュームをモジュールに作成するときの作用を説明するための構成図である。 モジュールにまたがるプールを有するストレージシステムをモジュールに分割するときの構成を説明するための内部構成図である。 Thin Provisioningボリューム制御情報テーブルとプールボリューム制御情報テーブルの構成図である。 プールの分割処理を説明するためのフローチャートである。 外部アクセスを説明するためのフローチャートである。 本発明の第４実施形態を示すストレージシステムのブロック構成図である。 モジュール２０Ａと２０Ｂを結合する前（図４２（ａ））と後（図４２（ｂ））の制御情報のテーブルの例である。 モジュール２０Ａと２０Ｂの結合後の例を示したブロック図及びテーブルである。

符号の説明

２０、２０A、２０B…サブストレージシステム ５１…ホスト計算機 ５０…管理装置 ７０…外部ストレージシステム １００…ストレージシステム

Claims (16)

1. 少なくとも一つの上位計算機にそれぞれ接続され、前記上位計算機からの要求に従って、互いに独立にデータの入出力を実行する複数のサブストレージシステムを有するストレージシステムにおいて、
   各々の前記サブストレージシステムは、
   複数の記憶デバイスを備える記憶装置と、
   前記上位計算機に接続され、前記上位計算機からのデータの入出力要求を受信する第一伝送制御部と、
   前記上位計算機からのデータの入出力要求を基に前記記憶装置に対するデータ入出力処理を行う制御部と、
   前記制御部と前記記憶装置とをそれぞれ接続してデータの入出力を制御する第二伝送制御部と、
   各々の前記サブストレージシステムを管理する管理装置に接続される第三伝送制御部と、
   少なくとも前記記憶装置の管理情報を格納するメモリと、
   を備え、
   前記ストレージシステムは、
   前記複数のサブストレージシステムの少なくとも二つのサブストレージシステムを互いに結合する結合部と、
   前記少なくとも二つのサブストレージシステムに接続される一乃至複数の管理装置で構成され、互いに結合された前記少なくとも二つのサブストレージシステムを、前記上位計算機に対して単一のアクセス対象として運用管理するとともに、前記少なくとも二つのサブストレージシステムの未使用リソース情報を管理する統合管理部と、
   を備え、
   前記ストレージシステムにおいて、前記複数のサブストレージシステムの少なくとも二つのサブストレージシステムが前記結合部により結合されて疎結合構成を成す場合、前記少なくとも二つのサブストレージシステムの各々の前記メモリには、自サブストレージシステムの前記記憶装置の管理情報と他サブストレージシステムの記憶装置の管理情報の少なくとも一部が結合されて格納され、前記少なくとも二つのサブストレージシステムの各々の前記制御部は、前記上位計算機からデータの入出力要求を受信すると、前記結合された管理情報を参照して該入出力要求にて指定された記憶装置が自サブストレージシステムの前記記憶装置か前記他サブストレージシステムの記憶装置かを判定して該入出力要求を処理し、リソースの割付処理が必要になると、自サブストレージシステム内の未使用リソースを探し、自サブストレージシステム内の未使用リソースが足りない場合には前記統合管理部が管理する未使用リソース情報から未使用リソースが十分ある前記他サブストレージシステムを選択して未使用リソースを割付け、
   前記少なくとも二つのサブストレージシステムが前記結合部により結合されて密結合構成を成す場合、前記少なくとも二つのサブストレージシステムの何れかの前記メモリには、前記少なくとも二つのサブストレージシステムの各々の前記記憶装置の管理情報が結合されて格納され、前記少なくとも二つのサブストレージシステムの各々の前記制御部は、前記上位計算機からデータの入出力要求を受信すると、前記少なくとも二つのサブストレージシステムの何れかの前記メモリに格納されている前記結合された管理情報を参照して該入出力要求を処理し、リソースの割付処理が必要になると、前記少なくとも二つのサブストレージシステム内の何れかの未使用リソースを選択して割付ける
   ことを特徴とするストレージシステム。
2. 前記統合管理部は、前記複数のサブストレージシステムに関する複数の管理者アカウントと複数の制御情報とをそれぞれ結合して管理する、請求項１に記載のストレージシステム。
3. 前記統合管理部は、前記複数のサブストレージシステムに関する複数の管理者アカウントのうちいずれか一つの管理者アカウントを有効として管理してなる、請求項１に記載のストレージシステム。
4. 前記統合管理部は、前記サブストレージシステムに関する管理者アカウントを、前記サブストレージシステム全体を管理するための管理者アカウントに結合してなる、請求項１に記載のストレージシステム。
5. 前記統合管理部は、前記管理者アカウントを当該管理者アカウントに対応する前記サブストレージシステムに特有なものとして設定するとともに、当該管理者アカウントを前記サブストレージシステム全体を管理するものとして設定する、請求項１に記載のストレージシステム。
6. 前記統合管理部は、前記複数のサブストレージシステムの記憶装置の記憶領域にまたがるプールが存在するときには、当該プールをボリューム制御情報に従って管理してなる、請求項１に記載のストレージシステム。
7. 前記ストレージシステムは、
   前記ストレージシステムを複数のサブストレージシステムに分割する分割部を更に備え、
   前記分割されたサブストレージシステムに接続された前記管理装置は、前記上位計算機に対して、それぞれ独立のアクセス対象として管理するとともに、前記分割されたサブストレージシステムを独立の運用対象として管理する
   請求項１に記載のストレージシステム。
8. 前記制御部は、前記他のサブストレージシステムに属する情報を自サブストレージシステムに属する情報の中から選択して前記他のサブストレージシステムに転送してなる、請求項７に記載のストレージシステム。
9. 前記制御部は、前記他のサブストレージシステムに属する記憶情報と制御情報を前記他のサブストレージシステムに転送するとともに、当該記憶情報と制御情報を転送先に再配置させてなる、請求項７に記載のストレージシステム。
10. 前記分割部は、前記複数のサブストレージシステムの記憶装置の記憶領域にまたがるプールが存在するときには、当該プールを一部のサブストレージシステムに分割してなる、請求項７に記載のストレージシステム。
11. 少なくとも一つの上位計算機と管理装置にそれぞれが接続され、前記上位計算機からの要求に従って、互いに独立にデータの入出力を実行する複数のサブストレージシステムを有するストレージシステムの管理方法において、
    前記複数のサブストレージシステムの少なくとも二つのサブストレージシステムを互いに結合する結合工程と、
    前記少なくとも二つのサブストレージシステムに接続される一乃至複数の前記管理装置で構成される統合管理部により、互いに結合された前記少なくとも二つのサブストレージシステムを、上位計算機に対して単一のアクセス対象として管理し、単一の運用対象として統合管理するとともに、前記少なくとも二つのサブストレージシステムの未使用リソース情報を管理する運用工程と、
    前記少なくとも二つのサブストレージシステムが結合されて疎結合構成を成す場合において、
    前記少なくとも二つのサブストレージシステムの各々により、自サブストレージシステムが備える記憶装置の管理情報と他サブストレージシステムが備える記憶装置の管理情報の少なくとも一部を結合して保持する第一の情報結合工程と、
    前記少なくとも二つのサブストレージシステムの各々において、前記上位計算機からデータの入出力要求を受信すると、前記結合された管理情報を参照して入出力要求にて指定された記憶装置が自サブストレージシステムの記憶装置か他サブストレージシステムの記憶装置かを判定して入出力要求を処理する第一の要求処理工程と、
    前記少なくとも二つのサブストレージシステムの各々において、リソースの割付処理が必要になると、自サブストレージシステム内の未使用リソースを探し、自サブストレージシステム内の未使用リソースが足りない場合は前記統合管理部が管理する未使用リソース情報から未使用リソースが十分ある他サブストレージシステムを選択して未使用リソースを割付ける第一のリソース割付工程と、
    前記少なくとも二つのサブストレージシステムが結合されて密結合構成を成す場合において、
    前記少なくとも二つのサブストレージシステムの何れかにより、前記少なくとも二つのサブストレージシステムの各々が備える記憶装置の管理情報を結合して保持する第二の情報結合工程と、
    前記少なくとも二つのサブストレージシステムの各々において、前記上位計算機からデータの入出力要求を受信すると、前記少なくとも二つのサブストレージシステムの何れかが保持する前記結合された管理情報を参照して入出力要求を処理する第二の要求処理工程と、
    前記少なくとも二つのサブストレージシステムの各々において、リソースの割付処理が必要になると、前記少なくとも二つのサブストレージシステム内の何れかの未使用リソースを選択して割付ける第二のリソース割付工程と、
    を備えてなるストレージシステムの管理方法。
12. 前記運用工程は、前記複数のサブストレージシステムに関する複数の管理者アカウントと複数の制御情報とをそれぞれ結合して管理する、請求項１１に記載のストレージシステムの管理方法。
13. 前記運用工程は、前記複数のサブストレージシステムに関する複数の管理者アカウントのうちいずれか一つの管理者アカウントを有効として管理する、請求項１１に記載のストレージシステムの管理方法。
14. 前記運用工程は、前記サブストレージシステムに関する管理者アカウントを、前記サブストレージシステム全体を管理するための管理者アカウントに結合する、請求項１１に記載のストレージシステムの管理方法。
15. 前記運用工程は、前記管理者アカウントを当該管理者アカウントに対応する前記サブストレージシステムに特有なものとして設定するとともに、当該管理者アカウントを前記サブストレージシステム全体を管理するものとして設定する、請求項１１に記載のストレージシステムの管理方法。
16. 前記運用工程は、前記複数のサブストレージシステムの記憶装置の記憶領域にまたがるプールが存在するときには、当該プールをボリューム制御情報に従って管理する、請求項１１に記載のストレージシステムの管理方法。