JP5425117B2 - 計算機システム、及びその管理方法、並びにプログラム - Google Patents

Description

本発明は、計算機システム、及びその管理方法、並びにプログラムに関し、例えば、計算機システム内の管理対象の構成管理に関するものである。

近年、企業や個人の利用するデータの量は急激に増加している。そこで、記憶装置（以下、ストレージサブシステムとも表記する）やホスト計算機をスイッチやハブで接続し、柔軟なデータ管理を可能にするＳＡＮ（Storage Area Network）や、ＮＡＳ（Network Attached Storage）といった技術を利用したストレージシステムが広く利用されている。

また、近年ではストレージシステム（計算機システムとも言う）の複雑化に伴い、ストレージシステムの運用コストの低減が重要な課題となっている。これを解決する１つの方法として、ストレージサブシステムやホスト計算機、スイッチ、ハブなど、ストレージシステムの構成を、管理ソフトウェアによって一元的に管理する方法がある。このような方法には、例えば特許文献１にて開示されている方法がある。このような技術を利用することで、ストレージシステムの管理者は、例えば複数のストレージサブシステムから複数のホスト計算機までの記憶リソースのつながりを参照する、あるいはストレージサブシステムからホスト計算機に新たにリソースを割り当てる、といった管理操作を単一の管理ソフトウェアから行うことができる。また、このような技術により、管理者は、単一の管理ソフトウェアによって、ストレージサブシステム、ホスト計算機、スイッチ、ハブなどから構成されるストレージシステムを一元的に管理することができるようになる。

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

一方、最近では、企業などのデータセンタに設置されるストレージサブシステムやホスト計算機などの台数が増加し、ストレージシステムが大規模化している。

しかしながら、特許文献１に代表される従来技術による方法では、ストレージシステムの全ての構成情報を管理ソフトウェアが常に保持している。このため、管理計算機が持つメモリなどのリソースの不足が原因で、データセンタ内の全てのストレージサブシステムやホスト計算機を単一の管理ソフトウェアで管理できないという課題がある。また、たとえ管理自体は可能であっても、管理操作を行った際に管理ソフトウェアの処理時間が長くなり、管理の効率が低下する、といった課題がある。

本発明はこのような状況に鑑みてなされたものであり、大規模なストレージシステムであっても、当該システムを効率よく一元的に管理できるようにするための技術を提供するものである。

上記課題を解決するために、本発明では、管理ソフトウェアがストレージシステム（計算機システム）の構成情報を２段階に分けて取得する。第１段階目では、管理ソフトウェアはストレージサブシステム、ホスト計算機、スイッチ、ハブなどから、それらが持つリソースの基本的な情報（リソースの識別子、リソースの数、リソース間の関連等、リソースの追加・変更がない限り、システム運用中に値が変動しない固定的な情報のみを含む）のみを取得する。次に、管理ソフトウェアは、取得した基本情報に基づき、詳細な構成情報を取得する範囲、タイミング、保持の必要性を決定する。そして、第２段階目において、管理ソフトウェアは、適切なタイミングで、適切な範囲の詳細な構成情報（システム運用中に値が変動する情報を含む）を取得する。管理ソフトウェアは、基本情報については常に保持しておくが、詳細情報については保持の必要性がある情報に関してのみ、保持する。

即ち、本発明では、管理計算機は、記憶装置（ストレージサブシステム）及びホスト計算機の構成要素の識別子及び構成要素の対応関係を少なくとも含む構成要素基本構成情報を取得する。また、管理計算機は、計算機システムを運用するに従って変動する構成要素の詳細構成情報を取得するための取得条件及び取得方法を示す詳細情報取得規則に基づいて、構成要素基本構成情報に対応する詳細構成情報を取得する。

詳細情報取得規則は、複数の前記取得条件と当該取得条件に対応する複数の前記取得方法の組み合わせによって構成される。また、取得方法の情報は、詳細構成情報を取得する範囲とタイミングについての情報を含んでいる。この場合、管理計算機は、複数の取得条件のそれぞれについて、取得条件を満たす構成要素が存在するか判定し、当該判定結果及び対応する取得方法に基づいて、詳細構成情報を取得する。

本発明に関連する更なる特徴は、以降に続く記述に一部は明記され一部は本記述から明らかになり、或は本発明の実施により学ぶことが出来る。本発明の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付されるクレームの様態により達成され実現される。

前述及び後述の記述は典型的で説明の為であり、本発明のクレーム又はアプリケーションを如何なる意味に於いても限定するものではないことを理解する必要がある。

本発明によれば、大規模なストレージシステム（計算機システム）であっても、当該システムを効率よく一元的に管理できるようになる。

本発明の第１の実施形態における計算機システム（ストレージシステム）の概略構成を示す図である。 ストレージ構成情報テーブル群の構成例を示す図である。 ボリューム割当てテーブルの構成例を示す図である。 物理リソース割当てテーブルの構成例を示す図である。 構成情報テーブル群の構成例を示す図である。 ストレージ情報テーブルの構成例を示す図である。 ボリューム情報テーブルの構成例を示す図である。 プール情報テーブルの構成例を示す図である。 物理リソース情報テーブルの構成例を示す図である。 ホスト情報テーブルの構成例を示す図である。 ホスト関連情報テーブルの構成例を示す図である。 ボリューム割当て情報テーブルの構成例を示す図である。 情報取得条件テーブルの構成例を示す図である。 管理タスクテーブルの構成例を示す図である。 ストレージサブシステムやホスト計算機を管理ソフトウェアの管理対象として登録する処理を説明するためのフローチャートである。 ストレージサブシステムやホスト計算機から管理ソフトウェアが情報を取得する範囲とタイミングを決定する処理を説明するためのフローチャートである。 ストレージサブシステムやホスト計算機から管理ソフトウェアが情報を取得する処理を説明するためのフローチャートである。 ストレージサブシステムやホスト計算機に対する管理操作を管理ソフトウェアに登録する処理を説明するためのフローチャートである。 ストレージサブシステムやホスト計算機に対する管理操作を管理ソフトウェアが実行する処理を説明するためのフローチャートである。 ストレージサブシステムやホスト計算機で発生した障害の情報を管理ソフトウェアが受信する処理を説明するためのフローチャートである。 ストレージサブシステムやホスト計算機の情報を管理ソフトウェアが表示する処理を説明するためのフローチャートである。 本発明によるユーザインタフェース（リソース一覧表示）の構成例を示す図である。 本発明によるユーザインタフェース（論理ボリュームの詳細表示）の構成例を示す図である。 第２の実施形態における計算機システムの概略構成を示す図である。 第２の実施形態におけるストレージ構成情報テーブル群の構成例を示す図である。 第２の実施形態における物理リソース割当てテーブルの構成例を示す図である。 第２の実施形態におけるコピー情報テーブルの構成例を示す図である。 第２の実施形態における情報取得条件テーブルの構成例を示す図である。 第３の実施形態における計算機システムの概略構成を示す図である。 第３の実施形態における構成情報テーブル群の構成例を示す図である。 第３の実施形態における情報最終更新日時テーブルの構成例を示す図である。 第３の実施形態における情報取得条件テーブルの構成例を示す図である。 第３の実施形態における情報保持ポリシテーブルの構成例を示す図である。 第３の実施形態において、ストレージサブシステムやホスト計算機から管理ソフトウェアが情報を取得する処理を説明するためのフローチャートである。 第３の実施形態において、管理ソフトウェアがストレージサブシステムやホスト計算機から定期的に情報を取得する処理を説明するためのフローチャートである。

以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。

本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。

更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。

本発明の１つの実施形態においては、管理ソフトウェアがストレージシステムの構成情報のうち、詳細な情報を取得する範囲とタイミングを決定するための条件（以下、情報取得条件と表記する）を保持し、当該条件に基づいて、ストレージシステムの構成情報の取得を制御する。なお、情報取得条件は管理ソフトウェアがデータとして保持しても良いし、プログラム中のロジックとして実装しても良い。また、情報取得条件は管理ソフトウェアのユーザが入力しても良い。

情報取得条件には、例えば、ユーザが管理操作を実行する頻度が高いストレージサブシステムについては詳細情報を常に管理ソフトが保持する、という条件や、直近の２４時間以内に重大な障害が発生したストレージサブシステムについては、障害が発生したリソースと、そのリソースと関連のあるリソースについてのみ、管理ソフトが詳細情報を保持する、といった条件がある。

なお、以後の説明では「テーブル」形式によって本発明の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

以下では「プログラム」を主語（動作主体）として本発明の実施形態における各処理について説明を行うが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

Ａ．第１の実施形態
＜計算機システムの構成＞
図１は、本発明の第１の実施形態による計算機システムの概略構成を示す図である。計算機システム１００は、ストレージサブシステム１０００と、ホスト計算機２０００と、スイッチ装置３０００と、管理計算機４０００と、スイッチ装置５０００と、を有している。図１では、ストレージサブシステム１０００が２台存在すると共に、ホスト計算機２０００と、スイッチ装置３０００と、管理計算機４０００と、スイッチ装置５０００と、がそれぞれ１台ずつ存在しているがこの限りではなく、１台以上存在すれば良い。

ストレージサブシステム１０００とホスト計算機２０００は、スイッチ装置３０００を介してネットワーク接続されている。また、ストレージサブシステム１０００とホスト計算機２０００と管理計算機４０００は、スイッチ装置５０００を介してネットワーク接続されている。なお、スイッチ装置３０００とスイッチ装置５０００は同一の装置であっても良い。またスイッチ装置５０００は、ストレージサブシステム１０００と管理計算機４０００を接続する装置と、ホスト計算機２０００と管理計算機４０００を接続する装置に分かれていても良い。

スイッチ装置５０００は、ストレージサブシステム１０００との接続のためのＩ／Ｆ（Ａ）５１００と、管理計算機４０００との接続のためのＩ／Ｆ（Ｂ）５２００と、ホスト計算機２０００との接続のためのＩ／Ｆ（Ｃ）５３００と、を有している。ストレージサブシステム１０００と管理計算機４０００とホスト計算機２０００と、これらを接続するスイッチ装置５０００との間で利用されるネットワークプロトコルには、ＴＣＰ／ＩＰなどがあるが特に限定はしない。また、図中ではＩ／Ｆ（Ａ）５１００が１つ、Ｉ／Ｆ（Ｂ）５２００が１つ、Ｉ／Ｆ（Ｃ）５３００が１つ存在しているがこの限りではなく、１つ以上存在すれば良い。

また、図１では、管理計算機４０００とストレージサブシステム１０００は別々の装置として示されているが、この限りではなく、管理計算機４０００はストレージサブシステム１０００と同一の筐体内に存在しても良い。

（i）ストレージサブシステム
ストレージサブシステム１０００は、ディスク装置１１００と、ディスクコントローラ１２００と、を有している。

ディスク装置１１００は、物理リソース１１２１と、プール１１２０と、を有している。ここで、物理リソース１１２１とは、ＨＤＤ(Hard Disk Drive)やＳＳＤ(Solid State Drive)などの物理デバイスによって提供される記憶領域のリソースのことを表している。ただし、物理リソース１１２１を提供する物理デバイスの種類については特に限定しない。プール１１２０は、物理リソース１１２１のグループである。一般的にプール１１２０は、ＲＡＩＤ(Redundant Array of Independent Disks)と呼ばれる技術を用いて、物理リソース１１２１を冗長化した上で構成されるが、この限りではなく、１つ以上の物理リソース１１２１をグループ化したものであれば良い。図中では、プール１１２０が４つ、物理リソース１１２１が５つ存在しているがこの限りではなく、１つ以上存在すれば良い。例えば、論理ボリューム１１１０（１）に接続されるプール１１２０は、ＲＡＩＤによって構成され、論理ボリューム１１１０（２）に接続されるプール１１２０は、Thin Provisioning技術による仮想ボリュームを提供するように構成されている。ただし、この限りではなく、両方がＲＡＩＤで構成されても良いし、両方が仮想ボリュームを提供するように構成されても良い。

ディスクコントローラ１２００は、メモリ１２１０と、制御装置（プロセッサとも言う）１２２０と、スイッチ装置３０００との接続のためのＩ／Ｆ (Interface)１２３０と、スイッチ装置５０００との接続のためのＩ／Ｆ（Ｂ）１２４０と、ディスク装置との接続のためのディスクＩ／Ｆ１２５０と、を有している。これらの構成要素はバスを通じて接続されている。

ディスクコントローラ１２００は更に、論理ボリューム１１１０を有している。論理ボリューム１１１０は、１つ以上の物理リソースから構成され、ディスクコントローラ１２００によって、ホスト計算機２０００に提供される、論理的な記憶領域のことを表している。ここで、論理ボリューム１１１０（１）は、あらかじめ割当てられた、１又は複数の物理リソース１１２１から構成されており、論理ボリューム１１１０（１）の容量と、それを構成する物理リソース１１２１の合計の容量とは等しい。但し、物理リソースがＲＡＩＤによって冗長化されている場合は、論理ボリューム１１１０（１）の容量は、それを構成する物理リソース１１２１の合計の容量より少ない場合もある。一方、論理ボリューム１１１０（２）は、ホスト計算機２０００に対して提供される仮想的な論理ボリュームであり、ホスト計算機２０００からの書き込み要求に応じて、物理リソース１１２１が割当てられるものである。具体的には、ディスクコントローラ１２００は、論理ボリューム１１１０（２）に対するデータの書き込み要求を受領したとき、当該書き込み要求の対象領域に対して物理リソースが割当てられていない場合に、物理リソース１１２１の記憶領域を論理ボリューム１１００（２）に割当て、当該割当てられた物理リソースの記憶領域にデータを書き込む。これによって、ホスト計算機２０００に提供される論理ボリューム１１１０（２）の記憶容量を、実際に割り当てられている物理リソース１１２１の合計容量よりも、大きな容量とすることができる。なお、図１では、上述の２種類の論理ボリューム１１１０が１つずつ存在しているが、この限りでなく、どちらか一方のみ、もしくは２種類が混在していてもよく、１つ以上の論理ボリューム１１１０が存在していれば良い。

メモリ１２１０は、制御装置１２２０が用いるプログラムとデータを記憶する。特にメモリ１２１０は、ストレージ情報取得プログラム１２１１と、ストレージ構成情報テーブル群１２１２と、ストレージ障害通知プログラム１２１３と、を有している。

ストレージ情報取得プログラム１２１１は、ストレージサブシステム１０００の構成情報を収集し、当該情報を他プログラムに送信するプログラムである。

ストレージ構成情報テーブル群１２１２は、ストレージサブシステム１０００の構成情報を格納するテーブルの集合である。

ストレージ障害通知プログラム１２１３は、ストレージサブシステム１０００内で発生した障害の情報を、他のプログラム（構成管理プログラム４１１０）に通知するプログラムである。障害の種類には例えば、物理リソース１１２１を提供する物理デバイスの故障などがあるが、特に限定はしない。

制御装置１２２０は、メモリ１２１０内のプログラムの実行やデータの入出力、ディスクコントローラ１２００が有する各Ｉ／Ｆを通じたデータや制御命令の入出力を制御する。

ストレージサブシステム１０００は他に、物理リソース１１２１からプール１１２０を構成する機能や、プール１１２０から論理ボリューム１１１０を生成する機能、論理ボリュームをＩ／Ｆ（Ａ）１２３０を通じてホスト計算機２０００に割り当てる機能、管理計算機４０００からストレージサブシステム１０００の構成や設定の変更要求を受け付ける機能など、ストレージ装置として一般的な機能を有している。

また、ストレージサブシステム１０００は他に、ストレージサブシステム１０００のユーザがデータを入力するための入力装置や、ストレージサブシステム１０００のユーザに情報を提示するための出力装置を有していても良いが、本発明とは直接関係ないため、図示はしない。

（ii）ホスト計算機
ホスト計算機２０００は、メモリ２１００と、制御装置（プロセッサとも言う）２２００と、スイッチ装置３０００との接続のためのＩ／Ｆ（Ａ）２３００と、スイッチ装置５０００との接続のためのＩ／Ｆ（Ｂ）２４００と、を有している。これらの構成要素はバスを通じて接続されている。メモリ２１００は、制御装置２２００が用いるプログラムとデータを記憶する。特にメモリ２１００は、アプリケーションプログラム２１１０と、ホスト情報取得プログラムと、ホスト障害通知プログラムと、を有する。

アプリケーションプログラム２１１０はどのようなプログラムであっても構わない。
ホスト情報取得プログラム２１２０は、ホスト計算機２０００の構成情報を収集し、当該情報を他プログラム（構成管理プログラム４１１０）に送信するプログラムである。なお、ホスト情報取得プログラムはＯＳ(Operating System)とは別のプログラムであっても良いし、ＯＳ自体の機能として実現されても良い。

ホスト障害通知プログラム２１３０は、ホスト計算機２０００内で発生した障害の情報を、他のプログラム（構成管理プログラム４１１０）に通知するプログラムである。障害の種類には例えば、メモリ２１００の故障などがあるが、特に限定はしない。
制御装置２２００は、メモリ２１００内のプログラムの実行やデータの入出力、Ｉ／Ｆ（Ａ）２３００を通じたデータや制御命令の入出力を制御する。

ホスト計算機２０００は他に、ホスト計算機２０００のユーザがデータを入力するための入力装置（キーボード、マウス等のポインティングデバイス、音声入力装置等）や、ホスト計算機２０００のユーザに情報を提示するための出力装置（ディスプレイ装置、プリンタ、音声出力装置等）、データを記憶するための二次記憶装置を有していても良いが、本発明とは直接関係ないため、図示はしない。

スイッチ装置３０００は、ストレージサブシステム１０００との接続のためのＩ／Ｆ（Ａ）３１００と、ホスト計算機２０００との接続のためのＩ／Ｆ（Ｂ）３２００と、を有している。ストレージサブシステム１０００とホスト計算機２０００および両者を接続するスイッチ装置３０００との間で利用されるネットワークプロトコルには、ＦＣ(Fibre Channel)やｉＳＣＳＩなどがあるが特に限定はしない。また、図中ではＩ／Ｆ（Ａ）３１００が１つ、Ｉ／Ｆ（Ｂ）３２００が１つ存在しているがこの限りではなく、１つ以上存在すれば良い。

（iii）管理計算機
管理計算機４０００は、メモリ４１００と、制御装置（プロセッサとも言う）４２００と、スイッチ装置５０００との接続のためのＩ／Ｆ４３００と、を有している。メモリ４１００は、制御装置４２００が用いるプログラムとデータを記憶する。例えば、メモリ４１００は、構成管理プログラム４１１０と情報収集プログラム４１２０と、構成情報テーブル群４１３０と、情報取得方法決定プログラム４１４０と、情報取得条件テーブル４１５０と、管理タスクテーブル４１６０と、を有している。

管理計算機４０００は他に、管理計算機４０００のユーザがデータを入力するための入力装置や、管理計算機４０００のユーザに情報を提示するための出力装置、データを記憶するための二次記憶装置を有していても良い。また、管理計算機４０００が持つ各種テーブルは、メモリ上だけでなく二次記憶装置上に保持しても良い。

構成管理プログラム４１１０は、ストレージサブシステム１０００およびホスト計算機２０００の構成を管理するためのプログラムである。構成管理プログラム４１１０は、例えば、情報収集プログラム４１２０を介して、ストレージサブシステム１０００やホスト計算機２０００の構成情報を収集する機能と、ストレージ障害通知プログラム１２１３やホスト障害通知プログラム２１３０から、ストレージサブシステム１０００やホスト計算機２０００内で発生した障害に関する情報を受信する機能と、を有する。構成管理プログラム４１１０は他に、物理リソース１１２１からプール１１２０を構成する機能や、プール１１２０から論理ボリューム１１１０を生成する機能、論理ボリューム１１１０をＩ／Ｆ（Ａ）１２３０を通じてホスト計算機２０００に割り当てる機能、特定の時刻に特定の処理を行うスケジューラ機能など、管理計算機として一般的な機能を有している。また、構成管理プログラム４１１０は、ストレージサブシステム１０００やホスト計算機２０００の構成情報の表示や、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作を行うためのユーザインタフェースを提供する。

情報収集プログラム４１２０は、ストレージサブシステム１０００やホスト計算機２０００の構成情報を収集するプログラムである。情報収集プログラム４１２０は、ストレージサブシステム１０００が持つストレージ情報取得プログラム１２１１と通信することによって、ストレージサブシステム１０００の構成情報を取得する機能と、ホスト計算機２０００が持つホスト情報取得プログラム２１２０と通信することによって、ホスト計算機２０００の構成情報を取得する機能と、を有する。

構成情報テーブル群４１３０は、ストレージサブシステム１０００やホスト計算機２０００の構成情報を格納するテーブルの集合である。

情報取得方法決定プログラム４１４０は、情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００から情報を収集する際の、情報取得の方法を決定するプログラムである。本実施例においては、情報取得の方法には情報取得対象の範囲と、情報取得のタイミングが含まれる。

情報取得条件テーブル４１５０は、情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００から情報を収集する際の、条件と情報取得方法を示すテーブルである。

管理タスクテーブル４１６０は、構成管理プログラム４１１０が実行する管理タスクの情報を格納するテーブルである。

なお、管理計算機４０００が有する入力装置及び表示装置（出力装置）の代替としてシリアルインターフェースやイーサーネットインターフェースを入出力装置とし、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。

また、管理計算機４０００のメモリ４１００内のプログラムをストレージサブシステム１０００のメモリ１２１０内に有し、制御装置１２２０によって当該プログラムを実行することで、管理計算機４０００と同様の機能を実現しても良い。さらに、管理計算機４０００は他に、スイッチ装置３０００やスイッチ装置５０００を管理するためのプログラムを有していても良い。

以後、計算機システム１００を管理し、本願発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機４０００が表示用情報を表示する場合は管理計算機４０００が管理システムであり、また、管理計算機４０００と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

＜ストレージ構成情報テーブル群＞
図２は、ストレージサブシステムにおけるストレージ構成情報テーブル群１２１２の具体例を示す図である。本実施形態においては、ストレージ構成情報テーブル群１２１２は、ボリューム割当てテーブル１２１２０と、物理リソース割当てテーブル１２１２１と、を有している。

ボリューム割当てテーブル１２１２０は、ホスト計算機２０００に割り当てられた論理ボリューム１１１０の情報を格納するテーブルである。

物理リソース割当てテーブル１２１２１は、論理ボリューム１１１０の各セグメントに対する物理リソースの割当ての情報を格納するテーブルである。

＜ボリューム割当てテーブルの構成例＞
図３は、ボリューム割当てテーブル１２１２０の具体的構成例を示す図である。ボリューム割当てテーブル１２１２０は、ホスト計算機が持つＩ／Ｆ（Ａ）２３００を識別するためのInitiator ID１２１２００と、ストレージサブシステム１０００が持つＩ／Ｆ（Ａ）１２３０を識別するためのTarget ID１２１２０１と、論理ボリューム１１１０を識別するためのＬＵＮ(Logical Unit Number)１２１２０２と、を構成項目として有する。

図３では、Initiator ID１２１２００およびTarget ID１２１２０１を表すために、それぞれホスト計算機２０００が持つＩ／Ｆ（Ａ）２３００のＷＷＮ(World Wide Name)と、ストレージサブシステム１０００が持つＩ／Ｆ(Ａ)１２３０のＷＷＮと、を用いているが、この限りではなく、ホスト計算機２０００が持つＩ／Ｆ（Ａ）２３００と、ストレージサブシステム１０００が持つＩ／Ｆ(Ａ)１２３０と、をそれぞれ一意に識別できる情報であれば良い。また、図３では、論理ボリューム１１１０の識別子としてＬＵＮ１２１２０２を用いているが、この限りではなく、論理ボリューム１１１０を一意に識別できる情報であれば良い。

＜物理リソース割り当てテーブルの構成例＞
図４は、本実施形態における、物理リソース割当てテーブル１２１２１の構成例を示す図である。物理リソース割当てテーブル１２１２１は、論理ボリューム１１１０を識別するためのＬＵＮ１２１２１０と、論理ボリューム内のセグメントを識別するためのセグメントＩＤ１２１２１１と、論理ボリューム１１１０の各セグメントの領域を識別するためのボリュームＬＢＡ(Logical Block Address)領域１２１２１２と、論理ボリューム１１１０の各セグメントに割り当てられた物理リソース１１２１を識別するための物理リソースＩＤ１２１２１３と、論理ボリューム１１１０の各セグメントに割り当てられた物理リソース１１２１の記憶領域を識別するためのＬＢＡ領域１２１２１４と、を構成項目として有している。

なお、ＬＵＮ１２１２１０と、セグメントＩＤ１２１２１１と、物理リソースＩＤ１２１２１３はそれぞれ、論理ボリューム１１１０と、論理ボリューム１１１０内のセグメントと、物理リソース１１２１と、を一意に識別できる情報である。従って、それらは、図３の表記に限らず、他の情報でも良い。

また、ボリュームＬＢＡ領域１２１２１２と、ＬＢＡ領域１２１２１４と、はそれぞれ論理ボリューム１１１０内の各セグメントの領域と、物理リソース１１２１内の記憶領域と、を一意に識別できる情報であれば、図３の表記に限らず、他の情報でも良い。

図４において、物理リソースＩＤ１２１２１３とＬＢＡ領域１２１２１４の欄に「−」が格納されている行（ＬＵＮ１２１２１０が「２」、セグメントＩＤ１２１２１１が「２」で示される行）は、ホスト計算機２０００に対して提供される仮想的な論理ボリューム１１１０（２）の一部のセグメントに対して、ホスト計算機２０００からの書き込み要求がまだなく、したがって当該セグメントにまだ物理リソース１１２１の記憶領域が割り当てられていないことを示している。

＜構成情報テーブル群＞
図５は、構成情報テーブル群４１３０の具体例を示す図である。本実施形態においては、構成情報テーブル群４１３０は、ストレージ情報テーブル４１３１と、ボリューム情報テーブル４１３２と、プール情報テーブル４１３３と、物理リソース情報テーブル４１３４と、ホスト情報テーブル４１３５と、ホスト関連情報テーブル４１３６と、ボリューム割当て情報テーブル４１３７と、を有している。

ストレージ情報テーブル４１３１は、ストレージサブシステム１０００の情報を格納するテーブルである。

ボリューム情報テーブル４１３２は、ストレージサブシステム１０００が持つ論理ボリューム１１１０の情報を格納するテーブルである。

プール情報テーブル４１３３は、ストレージサブシステム１０００が持つプール１１２０の情報を格納するテーブルである。

物理リソース情報テーブル４１３４は、ストレージサブシステム１０００が持つ物理リソース１１２１の情報を格納するテーブルである。

ホスト情報テーブル４１３５は、ホスト計算機２０００の情報を格納するテーブルである。

ホスト関連情報テーブル４１３６は、ホスト計算機２０００と別のホスト計算機２０００との関連を示す情報を格納するテーブルである。

ボリューム割当て情報テーブル４１３７は、ホスト計算機２０００と、ホスト計算機２０００に割り当てられた論理ボリューム１１１０との関係を示すテーブルである。

＜ストレージ情報テーブルの構成例＞
図６は、ストレージ情報テーブル４１３１の具体的構成例を示す図である。ストレージ情報テーブル４１３１は、ストレージサブシステム１０００を識別するためのストレージＩＤ４１３１０と、ストレージサブシステム１０００が持つプール１１２０の総容量４１３１１と、ストレージサブシステム１０００が持つプール１１２０の総空き容量４１３１２と、ストレージサブシステム１０００が持つ論理ボリューム１１１０の総数である総ボリューム数４１３１３と、ストレージサブシステム１０００内で最後に障害が発生した日時を示す最終障害発生日時４１３１４と、ストレージサブシステム１０００に対して実行された管理操作の頻度を示す管理操作頻度４１３１５と、ストレージサブシステム１０００が導入された年月日を示す導入年月日４１３１６と、を構成項目として有する。

ストレージ情報テーブル４１３１において、基本情報を構成するのは、ストレージＩＤ４１３１０と総ボリューム数４１３１３である。最終障害発生日時４１３１４は、ストレージサブシステム１０００やホスト計算機２０００が障害時に通知してくる情報であって、管理計算機４０００が取得しに行く詳細情報には含まれない。また、管理操作頻度４１３１５は、詳細情報ではなく、管理ソフトウェアがストレージサブシステム１０００に対して、過去にどの程度の頻度で管理に関する操作を実行したかを示す情報である。導入年月日４１３１６は、設置されたストレージの動作が開始された情報であり、例えば、管理者（ユーザ）によって入力される。

図６においては、情報を未取得の項目（例えばストレージＩＤが「ＳＴ．１」である行の総容量４１３１１など）には「ｎｕｌｌ」を格納している。情報を未取得であることを示す方法はこれに限らず、他の方法であっても良い。また、ストレージ情報テーブル４１３１は、図６に示した情報に限らず、ストレージサブシステム１０００の他の情報を格納しても良い。

＜ボリューム情報テーブルの構成例＞
図７は、ボリューム情報テーブル４１３２の具体的構成例を示す図である。ボリューム情報テーブル４１３２は、ストレージサブシステム１０００を識別するためのストレージＩＤ４１３２０と、論理ボリューム１１１０を識別するためのボリュームＩＤ４１３２１と、論理ボリューム１１１０の容量４１３２２と、論理ボリューム１１１０のＲＡＩＤレベル４１３２３と、論理ボリューム１１１０の記憶領域の提供元である物理リソース１１２１のメディア種別４１３２４と、論理ボリューム１１１０の切り出し元であるプール１１２０を識別するためのプールＩＤ４１３２５と、論理ボリューム１１１０の状態４１３２６と、を構成項目として有する。当該テーブルにおいて、ストレージＩＤ４１３２０と、ボリュームＩＤ４１３２１と、プールＩＤ４１３２５は、最初に取得される基本情報である。一方、総容量４１３２２、ＲＡＩＤレベル４１３２３、メディア種別４１３２４、及び状態４１３２６は、詳細情報に相当し、当該情報の取得前、各欄には「ｎｕｌｌ」が挿入されている。

ここで、ＲＡＩＤレベル４１３２３は、論理ボリューム１１１０の切り出し元であるプール１１２０に適用されたＲＡＩＤ技術の種類を示す情報、すなわち論理ボリューム１１１０の冗長性の程度を示す情報である。また、状態４１３２６は、論理ボリューム１１１０の稼働状態を示す情報である。

なお、図７においては、情報を未取得の項目（例えばストレージＩＤが「ＳＴ．１」、ボリュームＩＤが「ＬＵ．１」である行の容量４１３２２など）には「ｎｕｌｌ」を格納している。情報を未取得であることを示す方法はこれに限らず、他の方法であっても良い。また、図７においては、状態４１３２６には「ｎｕｌｌ」「正常」「エラー」のいずれかの値が格納されるが、これに限らず、論理ボリューム１１１０の稼働状態を示す情報であれば良い。さらに、ボリューム情報テーブル４１３２は、図７に示した情報に限らず、論理ボリューム１１１０の他の情報を格納しても良い。

＜プール情報テーブルの構成例＞
図８は、プール情報テーブル４１３３の具体的構成例を示す図である。プール情報テーブル４１３３は、ストレージサブシステム１０００を識別するためのストレージＩＤ４１３３０と、プール１１２０を識別するためのプールＩＤ４１３３１と、プール１１２０の容量４１３３２と、プール１１２０の空き容量４１３３３と、プール１１２０の種別を示すプール種別４１３３４と、プール１１２０の状態４１３３５と、を構成項目として有する。当該テーブルにおいて、ストレージＩＤ４１３３０と、プールＩＤ４１３３１は、最初に取得される基本情報である。一方、総容量４１３３２、空き容量４１３３３、プール種別４１３３４、及び状態４１３３５は、詳細情報に相当し、当該情報の取得前、各欄には「ｎｕｌｌ」が挿入されている。

また、図７を図８との関係で説明すると、ＬＵはプールから切り出されるため、例えば、ストレージＩＤ４１３２０がＳＴ．２でボリュームＩＤ４１３２１がＬＵ．１については、容量４１３３２が２ＴＢの、プールＩＤ４１３３１がＰｏｏｌ．１から容量１００ＧＢ分が切り出されて、ＳＴ．２のＬＵ．１が構成されているということが分かる。

図８においては、情報を未取得の項目（例えばストレージＩＤが「ＳＴ．１」、プールＩＤが「Ｐｏｏｌ．１」である行の容量４１３３２など）には「ｎｕｌｌ」を格納している。情報を未取得であることを示す方法はこれに限らず、他の方法であっても良い。また図８においては、プール種別４１３３４には「ｎｕｌｌ」「ＲＡＩＤグループ」「Thin Provisioningプール」のいずれかの値が格納されるが、これに限らず、プールの種別を示す情報であれば良い。

なお、本実施形態においては、プール種別４１３３４が「ＲＡＩＤグループ」であるプール１１２０は、論理ボリューム１１１０（１）に対して１又は複数の物理リソース１１２１の容量を予め割当てることが可能なプールを示している。また、プール種別４１３３４が「Thin Provisioningプール」であるプール１１２０は、論理ボリューム１１１０（２）に対して、ホスト計算機２０００からの書き込み要求に応じて、物理リソース１１２１を割り当てることが可能なプールを示している。図８においては、状態４１３３５には「ｎｕｌｌ」「正常」「エラー」のいずれかの値が格納されるが、これに限らず、プール１１２０の稼働状態を示す情報であれば良い。また、プール情報テーブル４１３３は、図８に示した情報に限らず、プール１１２０の他の情報を格納しても良い。

＜物理リソース情報テーブル＞
図９は、物理リソース情報テーブルの具体的構成例を示す図である。物理リソース情報テーブル４１３４は、ストレージサブシステム１０００を識別するためのストレージＩＤ４１３４０と、物理リソース１１２１を識別するための物理リソースＩＤ４１３４１と、物理リソース１１２１が割り当てられたプール１１２０を識別するためのプールＩＤ４１３４２と、物理リソース１１２１の容量４１３４３と、物理リソース１１２１における記憶領域の提供元メディアの種別を示すメディア種別４１３４４と、物理リソース１１２１における記憶領域の提供元メディアのディスク回転数４１３４５と、物理リソース１１２１の状態４１３４６と、を構成項目として有する。当該テーブルにおいて、ストレージＩＤ４１３４０、物理リソースＩＤ４１３４１、及びプールＩＤ４１３４２は、最初に取得される基本情報である。一方、容量４１３４３、メディア種別４１３４４、ディスク回転数４１３４５、及び状態４１３４６は、詳細情報に相当し、当該情報の取得前、各欄には「ｎｕｌｌ」が挿入されている。

図９においては、情報を未取得の項目（例えばストレージＩＤが「ＳＴ．１」、物理リソースＩＤが「Ｄｒｉｖｅ．１」である行の容量４１３４３など）には「ｎｕｌｌ」が格納されている。情報を未取得であることを示す方法はこれに限らず、他の方法であっても良い。また、図９においては、メディア種別４１３４４には「ｎｕｌｌ」「ＳＡＴＡ」「ＳＳＤ」のいずれかの値が格納されるが、これに限らず、メディアの種別を示す情報であれば良い。

本実施形態においては、メディア種別４１３４４が「ＳＳＤ」の場合、ディスク回転数４１３４５には「ｎ／ａ」を格納している。これはＳＳＤにはディスクがなため、ディスクの回転も起こり得ないことを示している。ディスクの回転がないことを示す方法はこれに限らず、他の表現方法であっても良い。

また、図９においては、状態４１３４６には「ｎｕｌｌ」「正常」「エラー」のいずれか値が格納されるが、これに限らず、物理リソース１１２１の稼働状態を示す情報であれば良い。例えば、「エラー」は、ストレージサブシステムやストレージコントローラボード等が故障した場合に挿入される。また、物理リソース情報テーブル４１３４は、図９に示した情報に限らず、物理リソース１１２１の他の情報を格納しても良い。

＜ホスト情報テーブルの構成例＞
図１０は、ホスト情報テーブルの具体的構成例を示す図である。ホスト情報テーブル４１３５は、ホスト計算機２０００を識別するためのホストＩＤ４１３５０と、ホスト計算機２０００に割り当てられたＩＰアドレス４１３５１と、ホスト計算機２０００のホスト名４１３５２と、ホスト計算機２０００の種別を示すホスト種別４１３５３と、ホスト計算機２０００の状態４１３５４と、を構成項目として有する。当該テーブルにおいて、ホストＩＤ４１３５０及びＩＰアドレス４１３５１は、最初に取得される基本情報である。一方、ホスト名４１３５２、ホスト種別４１３５３、及び状態４１３５４は、詳細情報に相当し、当該情報の取得前、各欄には「ｎｕｌｌ」が挿入されている。

図１０においては、情報を未取得の項目（例えばホストＩＤが「Ｈｏｓｔ．１」である行のホスト名４１３５２など）には「ｎｕｌｌ」を格納している。情報を未取得であることを示す方法はこれに限らず、他の方法であっても良い。また本実施例においては、ホスト情報テーブル４１３５にホスト計算機２０００のＩＰアドレスを格納しているが、これに限らず、ホスト計算機２０００のネットワークアドレスを示す情報であれば良い。

また、図１０においては、ホスト種別４１３５３には「ｎｕｌｌ」「クラスタ」「ノード」「物理サーバ」「ハイパーバイザ」「仮想サーバ」のいずれかの値が格納されるが、これに限らず、ホスト計算機２０００の種別を示す情報であれば良い。ここで、クラスタとは複数のホスト計算機を冗長化して構成される論理的なホスト計算機であり、ノードとはクラスタに含まれるホスト計算機を示している。さらに、ハイパーバイザとは、サーバ仮想化機能を持ったホスト計算機である。仮想サーバとはハイパーバイザ上に構築された仮想的なホスト計算機である。

図１０においては、状態４１３５４には「ｎｕｌｌ」「正常」「エラー」のいずれか値が格納されるが、これに限らず、ホスト計算機２０００の稼働状態を示す情報であれば良い。また、ホスト情報テーブル４１３５は、図１０に示した情報に限らず、ホスト計算機２０００の他の情報を格納しても良い。

＜ホスト関連情報テーブルの構成例＞
図１１は、ホスト関連情報テーブル４１３６の具体的構成例を示す情報である。ホスト関連情報テーブル４１３６は、ホスト計算機２０００を識別するためのホストＩＤ４１３６０と、ホスト計算機２０００が関連を持つ別のホスト計算機２０００を識別するための関連ホストＩＤ４１３６１と、ホスト計算機２０００と別のホスト計算機２０００との関連の種別を示す関連種別４１３６２と、を構成項目として有する。当該テーブルにおいては、全ての構成項目が基本情報となっている。

図１１においては、関連種別４１３６２には「クラスタ（親子）」「クラスタノード同士」「ボリューム共有ハイパーバイザ」「ハイパーバイザと仮想サーバ」のいずれかの値が格納されるが、これに限らず、ホスト計算機２０００と別のホスト計算機２０００との関連の種別を示す情報であれば良い。ここで、「クラスタ（親子）」とは、クラスタとそこに含まれるホスト計算機との関係を示しており、「クラスタノード同士」とは、同一のクラスタに含まれるホスト計算機同士の関係を示している。また、「ボリューム共有ハイパーバイザ」とは、ストレージサブシステム１０００から同一の論理ボリューム１１１０を割り当てられ、当該ボリュームを共有しているハイパーバイザ同士の関係を示しており、「パイパーバイザと仮想サーバ」とは、ハイパーバイザと、当該ハイパーバイザ上に構築された仮想サーバとの関係を示している。

なお、ホスト関連情報テーブル４１３６は、図１１に示した情報に限らず、ホスト計算機２０００と別のホスト計算機２０００との関連に関する他の情報を格納しても良い。

＜ボリューム割当て情報テーブルの構成例＞
図１２は、ボリューム割当て情報テーブル４１３７の具体的構成例を示す図である。ボリューム割当て情報テーブル４１３７は、ホスト計算機２０００を識別するためのホストＩＤ４１３７０と、ストレージサブシステム１０００を識別するためのストレージＩＤ４１３７１と、論理ボリューム１１１０を識別するためのボリュームＩＤ４１３７２と、を構成項目として有する。当該テーブルにおいて、全ての構成項目が基本情報となっている。

なお、ボリューム割当て情報テーブル４１３７は、図１２に示した情報に限らず、ホスト計算機２０００と、ホスト計算機２０００に割り当てられた論理ボリューム１１１０との関係に関する他の情報を格納しても良い。

＜情報取得条件テーブルの構成例＞
図１３は、情報取得条件テーブル４１５０の具体的構成例を示す図である。情報取得条件テーブル４１５０は、情報取得条件を識別するための条件ＩＤ４１５００と、情報取得の条件を示す情報取得条件４１５０１と、情報取得の方法を示す情報取得方法４１５０２と、情報取得条件の優先度４１５０３と、を構成項目として有する。

条件ＩＤ４１５００は、情報取得条件を特定する識別情報である。情報取得条件４１５０１は、所定の条件が満足した場合、或いは所定のイベントが発生した場合に、詳細情報を管理計算機４０００が取得しに行くかを規定する情報である。情報取得方法４１５０２は、詳細情報の取得方法について規定する情報である。優先順位４１５０３は、チェックする順番を規定するための情報であり、管理者によって設定可能となっている。

例えば、条件ＩＤ＝２として定義されている情報取得条件４１５０１によれば、今後実行される管理タスク（図１４に定義されたタスク）が存在する場合に、該当する管理タスクを実行するために必要な詳細情報を取得しなければならないことが分かる。

また、条件ＩＤ＝４の情報取得条件４１５０１においては、総ボリューム数が５０００以下のストレージについては、当該ストレージが設置されたときに詳細情報が取得されることが分かる。ここで、総ボリューム数は、常に（設定と同時に）詳細情報を取得する場合のデメリットと詳細情報が必要なとき（例えば、表示したいとき）に初めてそれを取得しに行く処理を実行することのデメリットとの効率的バランスを考慮して決定され、数値５０００は単なる例示であって、管理者が自由に設定可能である。

情報取得条件テーブル４１５０のチェックは、後述するように、例えば、管理対象を追加した場合（図１５参照）、構成管理プログラム４１１０が定期的にストレージサブシステム１０００やホスト計算機２０００に管理タスクを実行する場合（図１９参照）、ストレージサブシステム１０００やホスト計算機２０００から障害発生の通知を受けた場合（図２０）等に実行される。

なお、図１３においては、情報取得条件４１５０１と、情報取得方法４１５０２には自然言語で記述された条件および方法が格納されているが、これに限らず情報取得の条件と方法を示す情報であれば良い。情報取得の条件と方法は予め決められていても良いし、ユーザが入力しても良い。また情報取得の条件や方法は、図１３に示したものに限らず、他の条件や方法であっても良い。さらに、本実施形態においては、情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００から情報を収集する際の条件と情報取得方法を、情報取得条件テーブル４１５０に格納しているが、これに限らず、例えば同様の情報を情報取得方法決定プログラム４１４０内に処理のロジックとして実装しても良い。

＜管理タスクテーブルの構成例＞
図１４は、管理タスクテーブル４１６０の具体的構成例を示す図である。管理タスクテーブル４１６０は、管理タスクを識別するためのタスクＩＤ４１６００と、管理タスクの実行日時４１６０１と、管理タスクの実行対象リソースを示す対象４１６０２と、管理タスクを示すタスク４１６０３と、を構成項目として有する。当該管理タスクテーブルに規定されている各管理タスクは、管理者によって設定可能となっている。

図１４において、対象４１６０２には管理対象の実行対象であるリソースのＩＤを符号「：」で連結した値が格納されるが、これに限らず、管理対象の実行対象リソースを識別する情報であれば良い。また、図１４では、タスク４１６０３には自然言語で記述された管理タスクが格納されているが、これに限らず、管理タスクを示す情報であれば良い。
制御装置４２００は、メモリ４１００内のプログラムの実行やデータの入出力、Ｉ／Ｆ４３００を通じたデータや制御命令の入出力を制御する。

＜管理登録処理＞
図１５は、本実施形態において構成管理プログラム４１１０が、ストレージサブシステム１０００やホスト計算機２０００を、管理対象として登録する際の処理を説明するためのフローチャートである。

ステップＳ１０００において、管理者（ユーザ）が、構成管理プログラム４１１０のユーザインタフェースを介して、ストレージサブシステム１０００やホスト計算機２０００を、構成管理プログラム４１１０の管理対象として登録することを指示し、構成管理プログラムはその指示を受け付ける。なお、本実施形態においては、管理者（ユーザ）が既に登録済みのストレージサブシステム１０００やホスト計算機２０００を指定した場合には、管理者が構成情報テーブル群４１３０に格納されている当該ストレージサブシステム１０００やホスト計算機２０００の構成情報を取得し直して更新することを指示したものとする。

次に、ステップＳ１０１０において、構成管理プログラム４１１０は、構成情報テーブル群４１３０を参照し、ユーザが指定したストレージサブシステム１０００やホスト計算機２０００の基本情報を取得済みか否かを判断する。本実施形態においては、基本情報とは、リソースの識別子とリソースの数、リソース間の関連を指すものとする。

ステップＳ１０１０で基本情報が未取得であると判断された場合（ステップＳ１０１０でＮｏの場合）、処理はステップＳ１０２０に移行し、構成管理プログラム４１１０は、情報収集プログラム４１２０に、ユーザがステップＳ１０００で指定したストレージサブシステム１０００やホスト計算機２０００から、基本情報を取得するように指示する。

そして、ステップＳ１０３０において、情報収集プログラム４１２０は、ストレージサブシステム１０００上のストレージ情報取得プログラム１２１１やホスト計算機２０００上のホスト情報取得プログラム２１２０と通信を行い、ストレージサブシステム１０００やホスト計算機２０００の基本情報を取得し、構成情報テーブル群４１３０に格納する。当該処理が完了すると、ステップＳ１０４０に遷移する。

一方、ステップＳ１０１０において基本情報を取得済みと判断された場合（Ｓ１０１０でＹｅｓの場合）、処理は、ステップＳ１０４０に遷移する。

次に、ステップＳ１０４０において、構成管理プログラム４１１０は、情報取得方法決定プログラム４１４０に対して、情報取得方法の決定処理の実行を指示する。情報取得方法決定プログラム４１４０は、ストレージサブシステム１０００やホスト計算機２０００の基本情報と、情報取得条件テーブル４１５０に格納された情報に基づいて、ストレージサブシステム１０００やホスト計算機２０００から詳細情報を取得する方法（範囲とタイミング）を決定する。情報取得方法決定プログラム４１４０は、決定した情報取得方法を、情報収集プログラム４１２０に通知する。なお、情報取得方法決定プログラム４１４０による情報取得方法決定処理の詳細については後述する（図１６参照）。

さらに、ステップＳ１０５０において、構成管理プログラム４１１０は、情報収集プログラム４１２０に対して、情報取得方法決定プログラム４１４０が決定した情報取得方法に基づいて、ストレージサブシステム１０００やホスト計算機２０００に対する情報取得処理を行うように指示する。当該情報取得処理の詳細については後述する（図１７参照）。

最後に、ステップＳ１０６０において、構成管理プログラム４１１０は、管理者に対して、ストレージサブシステム１０００やホスト計算機２０００を管理対象として登録したことを通知する。通知の方法にはＧＵＩ (Graphical User Interface)やＣＬＩ (Command Line Interface)などのユーザインタフェースを介して通知する方法や、ログにメッセージを出力するなどの方法があるが、特に限定はしない。なお、本実施形態においては、構成情報テーブル群にストレージサブシステム１０００やホスト計算機２０００の構成情報が（基本情報のみであっても）格納されていれば、当該ストレージサブシステム１０００やホスト計算機２０００が、構成管理プログラム４１１０の管理対象であるとする。

以上の処理により、ストレージサブシステム１０００やホスト計算機２０００を構成管理プログラム４１１０の管理対象として登録する処理が完了する。なお本処理は、必ずしもユーザがストレージサブシステム１０００やホスト計算機２０００を、構成管理プログラム４１１０の管理対象として登録することを契機として実行されなくても良い。すなわち、ＳＬＰ(Service Location Protocol)などの技術を用いて、構成管理プログラム４１１０がスイッチ装置５０００を介して接続されたストレージサブシステム１０００やホスト計算機２０００の存在を検出し、これを契機として登録処理を実行しても良い。

＜情報取得方法決定処理＞
図１６は、本実施形態において情報取得方法決定プログラム４１４０が、ストレージサブシステム１０００やホスト計算機２０００から情報を取得する方法（範囲とタイミング）を決定する際の処理を説明するためのフローチャートである。

まずステップＳ２０００において、情報取得方法決定プログラム４１４０は、情報取得条件テーブル４１５０を参照し、ステップＳ２０１０で未だチェックしていない条件を１つ取得する。この際、本実施形態では、情報取得条件テーブル４１５０の優先順位４１５０３の数字が小さい順（優先順位が高い順）に条件を取得するものとする。

ステップＳ２０１０において、情報取得方法決定プログラム４１４０が、未チェックの条件が存在するか否かを判定する。

未チェックの条件が存在する場合（ステップＳ２０１０でＹｅｓの場合）は、情報取得決定プログラム４１４０は当該条件をチェック済みとした上で、処理をステップＳ２０２０に遷移させる。

次に、ステップＳ２０２０において、情報取得方法決定プログラム４１４０は、構成情報テーブル群４１３０と情報取得条件テーブル４１５０とを参照し、ストレージサブシステム１０００やホスト計算機２０００の情報と、情報取得条件とを比較する。

そして、ステップＳ２０３０において、情報取得方法決定プログラム４１４０は、情報取得条件を満たすリソースが存在するか否かを判定する。本実施形態においては、図１５のステップＳ１０３０から図１６の処理が呼び出された場合には、情報取得方法決定プログラム４１４０は、図１５のステップＳ１０００にてユーザが指定したストレージサブシステム１０００やホスト計算機２０００のリソースを対象として、該当するリソースが存在するか否かを判定する。具体的には、例えば図１５のステップＳ１０００にてユーザがストレージサブシステム１０００のうち１台を指定した場合、かつ当該ストレージサブシステム１０００が持つ論理ボリュームの数が５０００以下の場合は、当該ストレージサブシステム１０００は情報取得条件（情報取得条件テーブル４１５０の条件ＩＤ４１５００が「４」である行の情報取得条件４１５０１）を満たすと判定する。

情報取得条件を満たすリソースが存在しない場合（ステップＳ２０３０でＮｏの場合）、処理はステップＳ２０００に遷移する。一方、情報取得条件を満たすリソースが存在する場合（ステップＳ２０３０でＹｅｓの場合）、処理はステップＳ２０４０に遷移する。

ステップＳ２０４０において、情報取得方法決定プログラム４１４０は、情報取得条件を満たすリソースの情報を、情報取得条件テーブル４１５０に記載のタイミングで取得することを情報収集プログラム４１２０に指示する。具体的には、例えば、図１５のステップＳ１０００にてユーザがストレージサブシステム１０００のうち１台を指定した場合、かつ当該ストレージサブシステム１０００が持つ論理ボリュームの数が５０００以下の場合は、情報取得方法決定プログラム４１４０は、情報収集プログラム４１２０に対して、当該ストレージが持つ全リソースについて詳細情報を取得し、構成情報テーブル群４１３０に保持するように指示する。ステップＳ２０４０の処理が完了すると、処理はステップＳ２０００に遷移する。

ステップＳ２０１０において、未チェックの情報取得条件が存在しないと判断された場合（ステップＳ２０１０でＮｏの場合）、処理はステップＳ２０５０に遷移する。

続いて、ステップＳ２０５０において、情報取得方法決定プログラム４１４０は、ステップＳ２０４０の処理が１回以上実行されたか否かを判定する。

ステップＳ２０４０の処理が１回以上実行されたと判定された場合（ステップＳ２０５でＹｅｓの場合）は、情報取得方法決定プログラム４１４０は、情報取得方法決定処理を終了する。

一方、ステップＳ２０４０の処理が１回以上実行されていない場合、即ち、情報取得条件テーブル４１５０に１つも条件が格納されていなかった場合（ステップＳ２０５０でＮｏの場合）は、情報取得方法決定プログラム４１４０は、対象ストレージサブシステム１０００あるいはホスト計算機２０００の全てのリソースについて、詳細情報を直ちに取得することを情報収集プログラム４１２０に指示する。ステップＳ２０４０の処理が一回も実行されないといつまでも詳細情報が取得されないことになるからであり、全ての情報取得条件に合致しない場合には、従来技術のように、全てのリソースについての詳細情報が取得される。

以上の処理により、ストレージサブシステム１０００やホスト計算機２０００から情報を取得する範囲とタイミングを決定する処理が完了する。

ここで、より理解を深めるため、具体例を用いて当該処理について説明する。まず、２０１０年１１月１９日の３時３０分１５秒に、ストレージサブシステム１０００が持つ物理リソース１１２１の１つにおいて障害が発生したと仮定する。このとき、ストレージ障害通知プログラム１２１３が、ストレージサブシステム１０００の物理リソース１１２１に関する障害情報を構成管理プログラム４１１０に送信し、構成管理プログラム４１１０がこれを物理リソース情報テーブル４１３４に保持しているとする。これは図９にて、ストレージＩＤ４１３４０が「ＳＴ．２」、物理リソースＩＤ４１３４１が「Ｄｒｉｖｅ．５」で示される行（「エラー」と表示されている行）に該当する。また、同様に、障害が発生した日時がストレージ情報テーブル４１３１の最終障害発生日時４１３１４に格納されているものとする。これは図６にて、ストレージＩＤ４１３１０が「ＳＴ．２」で示される行に該当する。

ここで、仮に２０１０年１１月２０日の０時０分０秒に情報取得方法決定プログラム４１４０が動作した場合、情報取得方法決定プログラム４１４０は、図１３に示す情報取得条件テーブルに格納された条件のうち、条件ＩＤ４１５００が「１」で示される行の条件が該当すると判定する（但し、図１３に示される他の条件には該当しなかったと仮定した場合）。

この結果、情報取得方法決定プログラム４１４０は、図９にて、ストレージＩＤ４１３４０が「ＳＴ．２」、物理リソースＩＤ４１３４１が「Ｄｒｉｖｅ．５」で示される行の物理リソースと、その関連リソースについて、詳細情報を取得し、構成情報テーブル群４１３０に保持することを決定する。このように、障害時には関連リソースについてのみ詳細情報を取得するため、関連リソースを各テーブルから特定する必要がある。なお、この例における関連リソースは、図８にてストレージＩＤ４１３３０が「ＳＴ．２」及びプールＩＤ４１３３１が「Ｐｏｏｌ．１」で示される行のプールと、図７にてストレージＩＤ４１３２０が「ＳＴ．２」及びボリュームＩＤ４１３２１が「ＬＵ．１」で示される行の論理ボリューム、図１２においてホストＩＤ４１３７０が「Ｈｏｓｔ．７」「Ｈｏｓｔ．８」で示される行のホスト計算機、図１１において関連ホストＩＤ４１３６１が「Ｈｏｓｔ．９」「Ｈｏｓｔ．１０」で示されるホスト計算機、である。

＜情報取得処理＞
図１７は、本実施形態において情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００から情報を取得する際の処理を説明するためのフローチャートである。

ステップＳ３０００において、情報収集プログラム４１２０は、情報取得の対象がストレージサブシステム１０００であるか否かを判定する。

情報取得対象がストレージサブシステム１０００でない場合（ステップＳ３０００でＮｏの場合）、処理は、ステップＳ３０４０に遷移する。情報取得対象がストレージサブシステム１０００である場合（ステップＳ３０００でＹｅｓの場合）、処理は、ステップＳ３０１０に遷移する。

ステップＳ３０１０において、情報収集プログラム４１２０は、ストレージサブシステム１０００上のストレージ情報取得プログラム１２１１に対し、ストレージサブシステム１０００の情報を要求する。この時、情報収集プログラム４１２０は、情報取得方法決定プログラム４１４０が詳細情報を取得すると決定した範囲の情報を要求する。なお、情報取得方法決定プログラム４１４０が詳細情報を取得すると決定した範囲の情報であっても、本処理の時点において、当該情報を取得するタイミング（図１３の取得条件）を満たしていない場合には、情報収集プログラム４１２０は情報の要求を行わない。

次に、ステップＳ３０２０において、情報収集プログラム４１２０は、ストレージ情報取得プログラム１２１１から、ステップＳ３０１０の要求に応答して送信されてきたストレージサブシステム１０００の情報を受け取る。

続いて、ステップＳ３０３０において、情報収集プログラム４１２０は、ストレージサブシステム１０００の情報を構成情報テーブル群４１３０に格納する。

一方、ステップＳ３０４０において、情報収集プログラム４１２０は、情報取得対象がホスト計算機２０００であるか否かを判定する。

情報取得対象がホスト計算機２０００でない場合（ステップＳ３０４０でＮｏの場合）、情報収集プログラム４１２０は、情報取得処理を終了する。一方、情報取得対象がホスト計算機２０００である場合（ステップＳ３０４０でＹｅｓの場合）、処理は、ステップＳ３０５０に遷移する。

ステップＳ３０５０において、情報収集プログラム４１２０は、ホスト情報取得プログラム２１２０に、ホスト計算機２０００の情報を要求する。この時、情報収集プログラム４１２０は、情報取得方法決定プログラム４１４０が詳細情報を取得すると決定した範囲の情報を要求する。なお、情報取得方法決定プログラム４１４０が詳細情報を取得すると決定した範囲の情報であっても、本処理の時点において、当該情報を取得するタイミングを満たしていない場合には、情報収集プログラム４１２０は情報の要求を行わない。

そして、ステップＳ３０６０において、情報収集プログラム４１２０は、ホスト情報取得プログラム２１２０から、ステップＳ３０５０の要求に応答して送信されてきたホスト計算機２０００の情報を受け取る。

続いて、ステップＳ３０７０において、情報収集プログラム４１２０は、ホスト計算機２０００の情報を構成情報テーブル群４１３０に格納する。

以上の処理により、情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００から、情報取得方法決定プログラム４１４０が決定した範囲の情報を、情報取得方法決定プログラム４１４０が決定したタイミングで取得する処理が完了する。

＜管理タスクの登録処理＞
図１８は、管理者（ユーザ）が構成管理プログラム４１１０のユーザインタフェースを介して、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作の実行を指示した際に、当該管理操作を構成管理プログラム４１１０に登録する処理を説明するためのフローチャートである。

まずステップＳ４０００において、管理者が構成管理プログラム４１１０のユーザインタフェースを介して、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作の実行を指示すると、構成管理プログラム４１１０は、当該指示を受け付ける。

そして、ステップＳ４０１０において、構成管理プログラム４１１０は、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作を、管理タスクテーブル４１６０に登録する。

以上の処理により、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作を構成管理プログラム４１１０に登録する処理が完了する。なお、ユーザがストレージサブシステム１０００やホスト計算機２０００に対する管理操作を直ちに実行したい場合は、管理タスクの実行日時に現在の日時を指定すればよい。

＜管理タスクの実行処理＞
図１９は、本実施形態において構成管理プログラム４１１０が、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作を実行する際の処理を説明するためのフローチャートである。なお、図１９の処理は他の処理（図１５や図１８の処理など）とは別のスレッドで実行されているものとする。すなわち、図１９の処理は他の処理と並列に実行される。

まずステップＳ５０００において、構成管理プログラム４１１０は、定期的に管理タスクテーブル４１６０を参照する。なお、構成管理プログラム４１１０が管理タスクテーブル４１６０を参照する時間間隔は、予め決められていても良いし、ユーザが指定しても良い。

次に、ステップＳ５０１０において、構成管理プログラム４１１０は、現在の日時と、管理タスクテーブル４１６０の実行日時４１６０１と、を比較し、現在の日時が管理タスクの実行日時４１６０１と一致している、あるいはこれを過ぎているか否かを判定する。管理タスクテーブルを参照する周期（タイミング）によって、テーブル上で設定されたタスク実行日時と参照タイミングが多少ずれることがあるため、「過ぎている」か否かについても判定される。

現在の日時が管理タスクの実行日時４１６０１と一致しておらず、かつこれを過ぎていない場合（ステップＳ５０１０でＮｏの場合）、処理はステップＳ５０００に遷移する。一方、現在の日時が管理タスクの実行日時４１６０１と一致している、あるいはこれを過ぎている場合（ステップＳ５０１０でＹｅｓの場合）、処理は、ステップＳ５０２０に遷移する。

ステップＳ５０２０において、構成管理プログラム４１１０は、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作（管理タスク）を実行する。管理操作には、例えば、プール１１２０から論理ボリューム１１１０を作成する操作や、論理ボリューム１１１０をホスト計算機２０００に割り当てる操作などがあるが、特に限定しない。

次にステップＳ５０３０において、ステップＳ５０２０で実行した管理操作によって変更されたストレージサブシステム１０００やホスト計算機２０００の構成を構成情報テーブル群４１３０に反映するため、構成管理プログラム４１１０は、情報取得方法決定プログラム４１４０に対して情報取得方法決定処理を実行するよう指示し、情報取得方法決定プログラム４１４０は、その指示に応答して、情報取得方法決定処理を実行する。情報取得方法決定処理の詳細は、図１６に示した通りである。

ステップＳ５０４０において、構成管理プログラム４１１０は、情報収集プログラム４１２０に対して、情報収集処理の実行を指示し、情報収集プログラム４１２０は、その指示に応答して、ストレージサブシステム１０００やホスト計算機２０００の情報を取得する。情報取得処理の詳細は、図１７に示した通りである。

最後に、ステップＳ５０５０において、構成管理プログラム４１１０は、ステップＳ５０３０で実行した管理タスクを管理タスクテーブル４１６０から削除する。削除が終了すると、処理は、ステップＳ５０００に遷移する。

以上の処理により、ストレージサブシステム１０００やホスト計算機２０００に対する管理操作（管理タスク）を実行する処理、および当該管理操作によって変更のあったストレージサブシステム１０００やホスト計算機２０００の構成を構成情報テーブル群４１３０に反映する処理が完了する。なお、管理操作によって変更のあった構成情報を構成情報テーブル群４１３０に反映する際には、必ずしも管理操作対象のストレージサブシステム１０００やホスト計算機２０００の全リソースの情報を取得し直す必要はない。例えば、情報取得条件テーブル４１５０に、「ボリューム数が５０００以下のストレージに対して、管理操作を実行した場合、当該管理操作に関係するリソースの詳細情報を取得し保持する」という条件を格納しておけば、ストレージサブシステム１０００やホスト計算機２０００の全リソースの情報を取得し直すことを避けることができる。

＜障害情報受信処理＞
図２０は、本実施形態において構成管理プログラム４１１０が、ストレージサブシステム１０００やホスト計算機２０００にて発生した障害の情報を、ストレージ障害通知プログラム１２１３、あるいはホスト障害通知プログラム２１３０から受信する際の処理を説明するためのフローチャートである。

まずステップＳ６０００において、構成管理プログラム４１１０は、ストレージ障害通知プログラム１２１３、あるいはホスト障害通知プログラム２１３０から通知される、ストレージサブシステム１０００やホスト計算機２０００で発生した障害の情報を受信する。

ステップＳ６０１０において、構成管理プログラム４１１０は、受信した障害の情報を構成情報テーブル群４１３０に格納する。

次に、ステップＳ６０２０において、構成管理プログラム４１１０は、情報取得方法決定プログラム４１４０に対して情報取得方法決定処理を実行するよう指示し、情報取得方法決定プログラム４１４０は、その指示に応答して、情報取得方法決定処理を実行する。これにより、障害に関する情報の取得範囲とタイミングが決定される。情報取得方法決定処理の詳細は、図１６に示した通りである。

次にステップＳ６０３０において、構成管理プログラム４１１０は、情報収集プログラム４１２０に対して、情報収集処理の実行を指示し、情報収集プログラム４１２０は、情報取得処理を実行し、ステップＳ６０２０で決定された範囲の情報を、当該ステップで決定されたタイミングで取得する。情報取得処理の詳細は、図１７に示した通りである。

＜情報表示処理＞
図２１は、本実施形態において構成管理プログラム４１１０が、ストレージサブシステム１０００やホスト計算機２０００の構成情報を、ユーザインタフェースを介して表示する際の処理を説明するためのフローチャートである。

まずステップＳ７０００において、構成管理プログラム４１１０は、ストレージサブシステム１０００やホスト計算機２０００が持つリソースの詳細情報の表示が必要か否かを判定する。必要性の有無は、例えば、管理者がユーザインタフェースによって表示要求したか否かによって判断される。

リソースの詳細情報の表示が不要である（すなわち、識別子などの基本情報の表示のみで良い）場合（ステップＳ７０００でＮｏの場合）、処理は、ステップＳ７０３０に遷移する。一方、リソースの詳細情報の表示が必要な場合（ステップＳ７０００でＹｅｓの場合）、処理は、ステップＳ７０１０に遷移する。

ステップＳ７０１０において、構成管理プログラム４１１０は、構成情報テーブル群４１３０を参照し、さらに、表示対象リソースの詳細情報が取得済みか否かについて判定する。

表示対象リソースの詳細情報を取得済みである場合（ステップ７０１０でＹｅｓの場合）、処理は、ステップＳ７０３０に遷移する。一方、表示対象リソースの詳細情報がまだ取得されていない場合（ステップＳ７０１０でＮｏの場合）、処理は、ステップＳ７０２０に遷移する。

続いて、ステップＳ７０２０において、構成管理プログラム４１１０は、情報収集プログラム４１２０に対して、表示対象リソースの詳細情報を取得するために、情報取得処理を実行するように指示し、この指示に応答して、情報収集プログラム４１２０は、該当するリソースの詳細情報を取得する。情報取得処理の詳細は、図１７に示した通りである。

そして、ステップＳ７０３０において、構成管理プログラム４１１０は、ユーザインタフェースを介してリソースの情報を表示する。

＜ユーザインタフェースの例＞
図２２及び２３は、本発明の実施形態による、管理構成プログラム４１１０のユーザインタフェースの構成例を示す図である。図２２は、リソースの一覧表示を示すユーザインタフェースに相当する。図２３は、論理ボリュームの詳細表示を示すユーザインタフェースに相当する。

（i）図２２において、リソース一覧表示のユーザインタフェース４１１００は、ストレージサブシステムツリー表示領域４１１０１と、ストレージサブシステム概要表示領域４１１０２と、論理ボリューム一覧表示領域４１１０３と、を構成領域として有している。

ストレージサブシステムツリー４１１０１は、計算機システム１００内で管理され、リソースの一覧表示が可能となっているストレージサブシステム１０００を示す領域であり、何れか１つが選択可能となっている。図２２においては、ＳＴ．１が管理者（ユーザ）によって選択されているものとする。

ストレージサブシステム概要４１１０２は、選択されたストレージサブシステムの総ボリューム数を示す領域であるが、当該領域には、他の情報が含まれていても良い。

論理ボリューム一覧４１１０３は、選択されたストレージサブシステムに含まれる論理ボリュームの一覧を表示するための領域であり、論理ボリューム一覧表４１１０４と、詳細表示ボタン４１１０５と、を有している。論理ボリューム一覧表４１１０４においては、各論理ボリュームについて、論理ボリュームを識別するための情報であるボリュームＩＤと、論理ボリュームが属するプールを識別するための情報であるプールＩＤと、論理ボリュームを使用するホスト計算機を識別するための情報であるホストＩＤと、当該ホスト計算機のＩＰアドレスを示す情報であるホストＩＰアドレスと、を含む基本情報が表示される。また、論理ボリューム一覧表４１１０４は、ラジオボタンによって１つの論理ボリュームを選択することができ、当該選択後に詳細表示ボタン４１１０４を押下すると、選択された論理ボリュームについて図２３に示される詳細表示画面が表示される。

なお、図２２の表示は、図２１のフローチャートの処理に従って行われる。図２２によるユーザインタフェースを表示する際には、詳細情報は不要であるため、ステップＳ７０００の判定結果はＮｏであり、構成管理プログラム４１１０は、リソースの基本情報のみを表示する。一方、上述したように、管理者（ユーザ）が、論理ボリュームを１つ選択した状態で「詳細表示」ボタンを押下すると、図２３による「詳細表示画面」を表示するために、図２１のフローチャートによる処理が実行される。つまり、図２３の表示に当たっては詳細情報が必要となるため，ステップＳ７０００の判定結果がＹｅｓとなる。

（ii）図２３において、論理ボリューム詳細表示のユーザインタフェース４１１１０は、対象論理ボリュームの詳細情報を含む論理ボリューム情報４１１１１と、対象論理ボリュームを切出し元のプールの詳細情報を含む切出し元プール情報４１１１２と、対象論理ボリュームに割り当てられたホスト計算機を特定するための情報である割り当て先ホスト情報４１１１３と、を表示項目として有している。

論理ボリューム情報４１１１１において、ストレージサブＩＤとボリュームＩＤは基本情報に相当し、容量、ＲＡＩＤレベル、及びメディア種別は、図２１のステップＳ７０２０で取得された詳細情報に相当する。

また、切出し元プール情報４１１１２において、プールＩＤは基本情報に相当し、容量、空き容量、及びプール種別は図２１のステップＳ７０２０で取得された詳細情報に相当する。

なお、例えば、ＳＴ．１のＬＵ．１の詳細情報が未取得であった場合（ＳＴ．１のＬＵ．１について図７に示した情報のみ有している場合）、図２１のステップＳ７０１０の判定結果はＮｏとなり、ステップＳ７０２０で、ＳＴ．１のＬＵ．１の詳細情報が取得される。そして、最後にステップＳ７０３０の処理によって、図２３が表示されることになる。

Ｂ．第２の実施形態
＜計算機システムの構成＞
図２４は、本発明の第２の実施形態による計算機システム２００の概略構成を示す図である。計算機システム２００は、第１のストレージサブシステム１０００ｂと、ホスト計算機２０００と、スイッチ装置３０００と、管理計算機４０００ｂと、スイッチ装置５０００と、第２のストレージサブシステム６０００と、を有している。図中では、第１のストレージサブシステム１０００ｂと、第２のストレージサブシステム６０００が２台ずつ存在すると共に、ホスト計算機２０００と、スイッチ装置３０００と、管理計算機４０００ｂと、スイッチ装置５０００と、がそれぞれ１台ずつ存在しているがこの限りではなく、１台以上存在すれば良い。本構成の大部分は第１実施例の構成と同等であるため、以降は差分のみを説明する。

図１に示す計算機システム１００との差異は、第1のストレージサブシステム１０００ｂが、ストレージ仮想化プログラム１２１４ｂと、データコピープログラム１２１５ｂと、を有している点と、ストレージ構成情報テーブル群１２１２ｂを構成するテーブルが異なる点と、管理計算機４０００ｂが持つ情報取得条件テーブル４１５０ｂの構成が異なる点、である。なお、第２のストレージサブシステム６０００の構成は、第1のストレージサブシステム１０００と同様であるため説明は省略する。

ストレージ仮想化プログラム１２１４ｂは、仮想化機能を実現するためのプログラムである。具体的には、ストレージ仮想化プログラム１２１４ｂは、スイッチ装置３０００を介して接続された第２のストレージサブシステム６０００内の論理ボリューム６１１０を、第１のストレージサブシステム１０００ｂ内の論理ボリューム１１１０にマッピングする機能を有している。これにより、第２のストレージサブシステム６０００の論理ボリューム６１１０を、第１のストレージサブシステム１０００ｂの論理ボリュームとしてホスト計算機２０００に提供することができるようになる。本実施形態では、例えば、特許文献２及び３に開示された仮想化機能を用いることができる。仮想化機能は、スイッチ装置３０００によって実現されても良い。また、第１のストレージサブシステム１０００ｂと第２のストレージサブシステム６０００とは、１対１の関係であっても良いし、１対多、多対１、多対多の関係であっても良い。

データコピープログラム１２１５ｂは、論理ボリュームに格納されたデータを、別の論理ボリュームにコピーするためのプログラムである。コピー元の論理ボリュームと、コピー先の論理ボリュームとは、同じストレージサブシステム上に存在しても良いし、別のストレージサブシステム上に存在しても良い。例えば、第１のストレージサブシステム１０００ｂ上の論理ボリューム１１１０（１）から論理ボリューム１１１０（２）にデータをコピーする場合、当該プログラムによるデータのコピーは、第１のストレージサブシステム１０００ｂのディスクＩ／Ｆ１２５０を通じてデータを転送することで実現される。一方、第１のストレージサブシステム１０００ｂ上の論理ボリューム１１１０から第２のストレージサブシステム６０００上の論理ボリューム６１１０にデータをコピーする場合は、当該プログラムによるデータのコピーは、第１のストレージサブシステム１０００ｂのＩ／Ｆ（Ａ）１２３０と、スイッチ装置３０００の持つＩ／Ｆ（Ａ）３１００と、第２のストレージサブシステム６０００のＩ／Ｆ（Ａ）６２３０と、を通じてデータを転送することで実現される。

＜ストレージ構成情報テーブル群＞
図２５は、第２の実施形態によるストレージ構成情報テーブル群１２１２ｂの構成例を示す図である。

図２に示すストレージ構成情報テーブル群１２１２と、図２５に示すストレージ構成情報テーブル群１２１２ｂとの差異は、物理リソース割当てテーブル１２１２１ｂの構成が、第１の実施形態における物理リソース割当てテーブル１２１２１と異なる点と、ストレージ構成情報テーブル群１２１２ｂがコピー情報テーブル１２１２２ｂを有する点、である。

＜物理リソース割り当てテーブルの詳細構成例＞
図２６は、第２の実施形態による物理リソース割当てテーブル１２１２１ｂの構成例を示す図である。

図４に示す物理リソース割当てテーブル１２１２１と、図２６に示す物理リソース割当てテーブル１２１２１ｂとの差異は、物理リソース割当てテーブル１２１２１ｂが、ストレージサブシステムを識別するためのストレージＩＤ１２１２１３ｂを有する点と、物理リソースＩＤ１２１２１３の代わりにリソースＩＤ１２１２１４ｂを有する点、である。

本実施形態においては、論理ボリューム１１１０のセグメントに対して、第１のストレージサブシステム１０００ｂ自身が持つ物理リソース１１２１の記憶領域だけでなく、第２のストレージサブシステム６０００が持つ論理ボリューム６１１０の記憶領域を割り当てることができる。このため、論理ボリューム１１１０のセグメントに対して、第２のストレージサブシステム６０００が持つ論理ボリューム６１１０の記憶領域を割り当てた場合（例えば図２６においてＬＵＮ１２１２１０ｂが「３」、セグメントＩＤ１２１２１１ｂが「１」である行）においては、ストレージＩＤ１２１２１３ｂに第２のストレージサブシステム６０００を識別する情報が、リソースＩＤ１２１２１４ｂに第２のストレージサブシステム６０００が有する論理ボリューム６１１０を識別する情報が、それぞれ格納される。

なお、第１の実施形態と同様に、論理ボリューム１１１０のセグメントに対して、ストレージサブシステム１０００ｂ自身が持つ物理リソース１１２１の記憶領域を割り当てた場合には、ストレージＩＤ１２１２１３ｂには第１のストレージサブシステム１０００ｂを識別する情報が、リソースＩＤ１２１２１４ｂには物理リソース１１２１を識別する情報が、それぞれ格納される。ストレージ仮想化プログラムによる仮想化・被仮想化の関係を示す方法は図２６の表現に限らず、他の方法であっても良い。

＜コピー情報テーブルの詳細構成例＞
図２７は、第２の実施形態によるコピー情報テーブル１２１２２ｂの詳細構成例を示す図である。コピー情報テーブル１２１２２ｂは、論理ボリューム間のコピーに関する情報を格納するテーブルである。

コピー情報テーブル１２１２２ｂは、コピー元の論理ボリュームを持つストレージサブシステムを識別するためのコピー元ストレージＩＤ１２１２２０ｂと、コピー元の論理ボリュームを識別するためのコピー元ＬＵＮ１２１２２１ｂと、コピー先の論理ボリュームを持つストレージサブシステムを識別するためのコピー先ストレージＩＤ１２１２２２ｂと、コピー先の論理ボリュームを識別するためのコピー先ＬＵＮ１２１２２３ｂと、コピーの種別を示すコピー種別１２１２２４ｂと、を有する。コピーの種別には例えば、「ミラー」や「クローン」がある。ここで「ミラー」とは、コピー元の論理ボリュームからコピー先の論理ボリュームにデータのコピーが完了した後で、ホスト計算機２０００からコピー元の論理ボリュームに対する書き込みがあった場合に、書き込まれたデータをコピー先の論理ボリュームにも反映するコピー種別である。また、「クローン」とは、コピー元の論理ボリュームからコピー先の論理ボリュームにデータのコピーが完了した後で、ホスト計算機２０００からコピー元の論理ボリュームに対する書き込みがあった場合に、書き込まれたデータをコピー先の論理ボリュームには反映しないコピー種別である。コピーの種別についてはこれに限らず、他の種別であっても良い。

また、コピー情報テーブル１２１２２ｂは、図２５に示した情報に限らず、論理ボリューム間のコピーに関する他の情報を格納しても良い。

＜情報取得条件テーブルの構成例＞
図２８は、第２の実施形態による情報取得条件テーブル４１５０ｂの構成例を示す図である。第１の実施形態による情報取得条件テーブル４１５０と、第２の実施形態による情報取得条件テーブル４１５０ｂとの差異は、情報取得条件テーブル４１５０ｂが、ストレージ仮想化やストレージサブシステムを跨ったコピーの構成に関する情報取得条件および情報取得方法を有している点である。

＜データ処理の内容＞
本実施形態における処理の大部分は第１の実施形態の処理内容と同じであるため、以降は差分のみを説明する。本実施形態の処理を説明するためのフローチャートは、第１の実施形態のフローチャートと同様である。第１の実施形態における処理と第２の実施形態による処理との差異は、図２８に示す情報取得条件テーブル４１５０ｂに格納されている情報が、図１３に示す情報取得条件テーブル４１５０に格納されている情報と異なることにより、情報取得方法決定プログラム４１４０が、詳細情報を取得する範囲とタイミングを決定する処理の結果が異なる点である。

例えば、情報取得条件テーブル４１５０ｂでは、条件ＩＤ４１５００ｂが「１」である行のように、任意のホスト計算機に対して直接、１つ以上のボリュームが割り当てられているストレージサブシステムについて、当該ストレージサブシステムが持つ全リソースについて詳細情報を常に保持するという情報取得方法を含んでいる。例えば第２のストレージサブシステム６０００が持つ全ての論理ボリューム６１１０が、ストレージサブシステム１０００ｂが持つ論理ボリュームとして仮想化されている場合、第２のストレージサブシステム６０００が持つ論理ボリューム６１１０は、直接的にはホスト計算機２０００に割り当てられることはない。このような場合、本実施形態では、情報取得方法決定プログラム４１４０ｂは、第２のストレージサブシステム６０００の詳細情報は取得しないように情報収集プログラム４１２０に指示する。

このような制御を行う利点には、例えば次のようなものがある。一般的に、第２のストレージサブシステム６０００が持つ論理ボリューム６１１０を、ストレージサブシステム１０００ｂが持つ論理ボリュームとして仮想化する管理操作が行われるタイミングは、計算機システム２００の運用期間において、時間的な偏りを持つ傾向がある。すなわち、例えば第２のストレージサブシステム６０００が導入された際に、これが有する複数ないしは全ての論理ボリューム６１１０を仮想化する管理操作を一括で実施するといったケースがある。また一般的に、計算機システム２００の運用においては、ホスト計算機２０００とストレージサブシステム１０００ｂ、および両者を接続するスイッチ装置３０００が管理操作の主対象となることが多い。第２のストレージサブシステム６０００については、例えば障害が発生した場合だけ、管理操作の対象となるといったケースがある。さらに、一般的にストレージサブシステム１０００ｂに比べて、第２のストレージサブシステム６０００の方が、台数が多くなる傾向がある。以上のような一般的な傾向を踏まえると、情報取得条件テーブル４１５０ｂにおける条件ＩＤ４１５００ｂが「１」である行で示される条件を持つことによって管理計算機４０００は、台数が多く、かつ管理操作の対象となる頻度が低い第２のストレージサブシステム６０００の構成情報を常に保持しておく必要がなくなり、したがって計算機システム２００を効率よく管理することができるようになる。

また、情報取得条件テーブル４１５０ｂでは、条件ＩＤ４１５００ｂが「２」や「３」である行のように、情報取得条件４１５０１ｂに格納された情報が、第１の実施形態における情報取得条件４１５０１に格納された情報と同じである場合でも、情報取得方法４１５０２に格納された情報が、第１の実施形態における情報取得方法４１５０２に格納された情報と異なる場合がある。具体的には、第１の実施形態における情報取得方法４１５０２では、情報取得対象のストレージサブシステム１０００のみが、情報取得方法の決定対象であったのに対し、第２の実施形態における情報取得方法４１５０２ｂでは、情報取得対象の第１のストレージサブシステム１０００ｂと、当該ストレージサブシステムと関連を持った第２のストレージサブシステム６０００も、情報取得方法の決定対象となる。

Ｃ．第３の実施形態
＜計算機システムの構成＞
図２９は、本発明の第３の実施形態による計算機システム３００の概略構成を示す図である。この計算機システム３００は、ストレージサブシステム１０００と、ホスト計算機２０００と、スイッチ装置３０００と、管理計算機４０００ｃと、スイッチ装置５０００と、を有している。図中では、ストレージサブシステム１０００が２台存在すると共に、ホスト計算機２０００と、スイッチ装置３０００と、管理計算機４０００ｃと、スイッチ装置５０００と、がそれぞれ１台ずつ存在しているがこの限りではなく、１台以上存在すれば良い。本構成の大部分は第１の実施形態の構成と同等であるため、以降は差分のみを説明する。

図１に示す計算機システム１００との差異は、管理計算機４０００ｃが持つ構成情報テーブル群４１３０ｃ(図３０参照）に情報最終更新日時テーブル４１３８ｃが含まれる点と、管理計算機４０００ｃが持つ情報取得条件テーブル４１５０ｃの構成が第１の実施形態における情報取得条件テーブル４１５０の構成と異なる点と、管理計算機４０００ｃが情報保持ポリシテーブル４１７０ｃを有する点、である。

＜情報最終更新日時テーブルの構成例＞
図３１は、第３の実施形態による情報最終更新日時テーブル４１３８ｃの構成例を示す図である。情報最終更新日時テーブル４１３８ｃは、図３０に示される構成情報テーブル群４１３０ｃに含まれるテーブルであり、情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００の構成情報を最後に取得した日時を示す情報を有している。

情報最終更新日時テーブル４１３８ｃは、ストレージサブシステム１０００やホスト計算機２０００が有する構成要素を識別するための構成要素ＩＤ４１３８０ｃと、構成要素の情報を情報収集プログラム４１２０が最後に取得した日時を示す情報最終更新日時４１３８１ｃと、を構成項目として有する。なお、本実施形態では、構成要素ＩＤ４１３８０ｃには、構成情報テーブル群４１３０ｃに含まれる各テーブルにおいて行を一意に識別する情報を符号「：」で連結した情報を格納するが、これに限らず、ストレージサブシステム１０００やホスト計算機２０００が有する構成要素を一意に識別する情報であれば良い。

＜情報取得条件テーブルの構成例＞
図３２は、第３の実施形態による情報取得条件テーブル４１５０ｃの構成例を示す図である。

図１３に示す情報取得条件テーブル４１５０と、図３２に示す情報取得条件テーブル４１５０ｃとの差異は、情報取得条件テーブル４１５０ｃが情報保持ポリシＩＤ４１５０４ｃを有する点である。情報保持ポリシＩＤ４１５０４ｃは、情報保持ポリシテーブル４１７０ｃの行を一意に特定するための情報である。

＜情報保持ポリシテーブルの構成例＞
図３３は、第３の実施形態による情報保持ポリシテーブル４１７０ｃの構成例を示す図である。情報保持ポリシテーブル４１７０ｃは、情報収集プログラム４１２０が取得したストレージサブシステム１０００やホスト計算機２０００の構成情報（詳細情報）の保持及び破棄する方法に関するポリシ（保持及び破棄方法を規定するルール）を示す情報である。

情報保持ポリシテーブル４１７０ｃは、情報保持ポリシを一意に識別するためのポリシＩＤ４１７００ｃと、情報収集プログラム４１２０が、定期的に情報取得条件テーブル４１５０ｃの情報取得条件４１５０１ｃに該当した情報を更新する時間間隔を示す条件該当情報の定期更新間隔４１７０１ｃと、情報取得条件テーブル４１５０ｃの情報取得条件４１５０１ｃに該当した情報の格納先を示す条件該当情報の格納先４１７０２ｃと、情報取得条件テーブル４１５０ｃの情報取得条件４１５０１ｃに該当した情報を破棄するタイミングを示す条件該当情報の破棄タイミング４１７０３ｃと、情報取得条件テーブル４１５０ｃの情報取得条件４１５０１ｃに該当しなかった情報を後から取得した場合の格納先を示す条件非該当情報の格納先４１７０４ｃと、情報取得条件テーブル４１５０ｃの情報取得条件４１５０１ｃに該当しなかった情報を後から取得した場合の、情報を破棄するタイミングを示す条件非該当情報の破棄タイミング４１７０５ｃと、を有する。

＜データ処理の内容＞
本実施形態における処理の大部分は第１の実施形態の処理内容と同じであるため、以降は差分のみを説明する。第１の実施形態におけるデータ処理と、本実施形態におけるデータ処理との差異は、情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００の情報を取得する処理のシーケンスが異なる点と、本実施形態において構成管理プログラム４１１０が情報収集プログラム４１２０に対して、ストレージサブシステム１０００やホスト計算機２０００の情報を定期的に更新するように指示する点、である。以下、これらの差異について説明する。

＜情報取得処理の詳細＞
図３４は、第３の実施形態において情報収集プログラム４１２０がストレージサブシステム１０００やホスト計算機２０００の情報を取得する際の処理を説明するためのフローチャートである。図３４に示す情報取得処理のステップＳ３０００ｃと、ステップＳ３０１０ｃと、ステップＳ３０２０ｃと、ステップＳ３０４０ｃと、ステップＳ３０５０ｃと、ステップＳ３０６０ｃは、図１７に示す情報取得処理のステップＳ３０００と、ステップＳ３０１０と、ステップＳ３０２０と、ステップＳ３０４０と、ステップＳ３０５０と、ステップＳ３０６０と、同等であるため説明は省略する。

図３４に示す情報取得処理では、ステップＳ３０３０ｃにおいて、情報収集プログラム４１２０は、情報取得条件テーブル４１５０ｃと情報保持ポリシテーブル４１７０ｃを参照し、情報の格納先を決定した上で、ストレージサブシステム１０００の情報（詳細情報）を構成情報テーブル群４１３０ｃに格納する。

また、ステップＳ３０７０ｃにおいて、情報収集プログラム４１２０は、情報取得条件テーブル４１５０ｃと情報保持ポリシテーブル４１７０ｃを参照し、情報の格納先を決定した上で、ホスト計算機２０００の情報を構成情報テーブル群４１３０ｃに格納する。

以上の処理により、情報収集プログラム４１２０が取得したストレージサブシステム１０００やホスト計算機２０００の情報を、情報保持ポリシ（図３３参照）に従った格納先メディア（メモリや、ＨＤＤなどの二次記憶装置）に格納することができる。

＜定期的情報更新処理＞
図３５は、第３の実施形態において構成管理プログラム４１１０が情報収集プログラム４１２０に対して、ストレージサブシステム１０００やホスト計算機２０００の情報を定期的に更新するように指示する際の処理を説明するためのフローチャートである。なお、図３５に示す処理は、構成管理プログラム４１１０の他の処理とは別のスレッドで実行されているものとする。すなわち、図３５の処理は他の処理と並列に実行される。

まずステップＳ８０００において、構成管理プログラム４１１０は、定期的に情報最終更新日時テーブル４１３８ｃと、情報取得条件テーブル４１５０ｃと、情報保持ポリシテーブル４１７０ｃと、を参照する。

次にステップＳ８０１０ｃにおいて、構成管理プログラム４１１０は、情報最終更新日時テーブル４１３８ｃの情報最終更新日時４１３８１ｃから、情報保持ポリシテーブル４１７０ｃの条件該当情報の定期更新間隔４１７０１ｃで示される時間が経過しているか否かを判定する。

情報保持ポリシテーブル４１７０ｃの条件該当情報の定期更新間隔４１７０１ｃで示される時間が情報最終更新日時テーブル４１３８ｃの情報最終更新日時４１３８１ｃを経過している場合（ステップＳ８０１０でＹｅｓの場合）は、処理は、ステップＳ８０２０に遷移する。一方、情報保持ポリシテーブル４１７０ｃの条件該当情報の定期更新間隔４１７０１ｃで示される時間が情報最終更新日時テーブル４１３８ｃの情報最終更新日時４１３８１ｃを経過していない場合（ステップＳ８０１０でＮｏの場合）、処理はステップＳ８０００に遷移する。

ステップＳ８０２０において、構成管理プログラム４１１０は、情報収集プログラム４１２０に対して、該当リソースについて情報取得処理を実行するように指示し、情報収集プログラム４１２０は、当該指示に応答して、が徒売りソースの詳細情報を取得する。当該ステップ８０２０の処理の詳細は、図３４で示される通りである。

以上の処理により、ストレージサブシステム１０００やホスト計算機２０００の情報を、情報保持ポリシに従った時間間隔で定期的に更新することができる。

Ｄ．まとめ
（１）第１の実施形態
管理計算機（管理ソフトウェア）は、まず、ストレージサブシステム及びホスト計算機の構成要素の識別子及び構成要素の対応関係を少なくとも含む基本構成情報（管理対象のオブジェクトにとってはシステム運用中に値が変動しない固定の情報のみを含む）を、例えば、それらが設定されたときに取得する。ストレージシステムシステム（計算機システム）を運用するに従って値が変動する情報を含む、構成要素の詳細構成情報（管理対象のオブジェクトをモニタ・管理するために必要な情報）を取得するための取得条件及び取得方法を示す詳細情報取得規則（情報取得条件テーブル：図１３参照）に基づいて、管理計算機は、基本構成情報に対応する詳細構成情報を取得する。また、詳細情報取得規則は、複数の前記取得条件と当該取得条件に対応する複数の取得方法の組み合わせによって構成され、取得方法の情報は、詳細構成情報を取得する範囲とタイミングについての情報を含むようにしても良い。この場合、管理計算機は、複数の取得条件のそれぞれについて、取得条件を満たす構成要素が存在するか判定し、当該判定結果及び対応する取得方法に基づいて、詳細構成情報を取得する。このようにすることにより、ストレージシステムの構成情報のうち詳細な情報を保持しておく範囲とタイミングを適切に制御することができ、よって、ストレージシステムが大規模化した場合であっても、管理ソフトウェアによってこれを効率的に管理することができる。なお、管理ソフトウェアが管理する対象はストレージサブシステム、ホスト計算機、スイッチ、ハブに限定せず、ホスト計算機上で動作するアプリケーションプログラムなどを含んでもよい。

また、管理計算機は、複数の取得条件の何れも満たさない場合、１つ以上のストレージサブシステム及び１つ以上のホスト計算機における全ての構成要素について、詳細構成情報を取得する。このようにすることにより、詳細情報の取得ミスを防止することができるようになる。

管理計算機は、少なくとも、管理対象と当該管理対象に対するタスクの内容を規定する管理タスク情報（図１４参照）を保持するようにしても良い。この場合、管理計算機は、管理タスク情報に含まれる各タスクを実行するために必要な詳細構成情報が取得済であるか否かチェックする。そして、管理計算機は、タスク実行の前に不足している詳細構成情報をストレージサブシステム及びホスト計算機の少なくとも１つから取得する。このようにすることにより、管理操作によって変更のあった管理対象（例えば、論理ボリュームの作成やコピー等）の構成情報を管理タスク前に漏れなく確実に取得することが可能となる。

管理計算機は、リソースの一覧表示に関するユーザインタフェースを介して基本構成情報を表示画面上に一覧表示する。そして、管理者（ユーザ）が当該一覧表示のユーザインタフェースに対して詳細表示をさせたい管理対象（例えば、論理ボリューム）を選択すると、当該選択動作に応答して、管理計算機は、詳細表示のユーザインタフェースを介して構成要素の詳細構成情報を表示画面上に表示する。このようにすることにより、管理者が知りたい管理対象を見やすく管理者に提供することが可能となる。

（２）第２の実施形態
計算機システムは、ホスト計算機に自身の論理ボリュームを直接提供する第１のストレージサブシステムと、少なくとも１つの論理ボリュームを第１のストレージサブシステムの論理ボリュームとしてホスト計算機に提供するように仮想化された第２のストレージサブシステムと、を有する。この場合、管理計算機は、第２のストレージサブシステムが仮想化された論理ボリュームの他にホスト計算機に対して直接割り当てられた論理ボリュームを有するか判断し、そうである場合のみ、第２のストレージサブシステムの構成要素について詳細構成情報を取得する。一方、第２のストレージサブシステムがホスト計算機に対して仮想化された論理ボリュームのみ提供する場合、管理計算機は、構成要素の詳細構成情報は取得しないようにする。このようにすることにより、ストレージサブシステムが仮想化されていても必要な詳細情報が取得でき、また、仮想化されたストレージサブシステムがホスト計算機と直接関連する場合のみ管理対象とすることができるので効率よく管理対象のデバイスを管理することができる。

また、管理計算機は、ストレージのコピー（ローカルコピーやリモートコピー）に関して、コピー元のストレージ及び論理ボリュームとコピー先のストレージ及び論理ボリューム関する情報を管理するようにしても良い。

このようにすることにより、ストレージ仮想化やストレージサブシステムを跨ったコピーのように、ストレージサブシステム間に関連がある場合においても、管理ソフトウェアがストレージシステムの構成情報のうち、詳細な情報を保持しておく範囲とタイミングを適切に制御することができ、ストレージシステムが大規模化した場合であっても、これを効率的に管理することができる。

（３）第３の実施形態
管理計算機は、構成要素の少なくとも詳細構成情報（基本情報を対照としても良い）の格納場所及び破棄についての規則を規定する情報保持ポリシを有し、当該情報保持ポリシに基づいて、取得した詳細構成情報の格納及び破棄について管理する。また、情報保持ポリシは、詳細構成情報の更新タイミング（更新周期等）を規定する情報を含み、管理計算機は、さらに、詳細構成情報の最終更新日時を管理する更新履歴情報を管理する。そして、管理計算機は、最終更新日時と情報保持ポリシに含まれる更新タイミングとを比較して、詳細構成情報の更新の要否を決定し、更新が必要な場合に詳細情報取得規則に基づいて詳細構成情報を取得する。このようにすることにより、ポリシにしたがって、ストレージサブシステムやホスト計算機の情報を保持しておく方法（情報を定期的に更新する間隔や、情報の格納先）を適切に制御することができ、また、計算機システムが大規模化した場合であっても、これを効率的に管理することができる。

（４）その他
本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある人には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになるである。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。

１０００、１０００ｂ、１０００ｃ ストレージサブシステム
１１００ ディスク装置
１１１０ 論理ボリューム
１１２０ プール
１１２１ 物理リソース
１２００ ディスクコントローラ
１２１０ メモリ
１２１１ ストレージ情報取得プログラム
１２１２、１２１２ｂ ストレージ構成情報テーブル群
１２１３ ストレージ障害通知プログラム
１２１４ｂ ストレージ仮想化プログラム
１２１５ｂ データコピープログラム
１２２０ 制御装置
１２３０ Ｉ／Ｆ（Ａ）
１２４０ Ｉ／Ｆ（Ｂ）
１２５０ ディスクＩ／Ｆ
２０００ ホスト計算機
２１００ メモリ
２１１０ アプリケーションプログラム
２１２０ ホスト情報取得プログラム
２１３０ ホスト障害通知プログラム
２２００ 制御装置
２３００ Ｉ／Ｆ（Ａ）
２４００ Ｉ／Ｆ（Ｂ）
３０００ スイッチ装置
３１００ Ｉ／Ｆ（Ａ）
３２００ Ｉ／Ｆ（Ｂ）
４０００、４０００ｂ 管理計算機
４１００ メモリ
４１１０ 構成管理プログラム
４１２０ 情報収集プログラム
４１３０、４１３０ｃ 構成情報テーブル群
４１３１ ストレージ情報テーブル
４１３２ ボリューム情報テーブル
４１３３ プール情報テーブル
４１３４ 物理リソース情報テーブル
４１３５ ホスト情報テーブル
４１３６ ホスト関連情報テーブル
４１３７ ボリューム割当て情報テーブル
４１３８ｃ 情報最終更新日時テーブル
４１４０ 情報取得方法決定プログラム
４１５０、４１５０ｂ、４１５０ｃ 情報取得条件テーブル
４１６０ 管理タスクテーブル
４１７０ｃ 情報保持ポリシテーブル
４２００ 制御装置
４３００ Ｉ／Ｆ
５０００ スイッチ装置
５１００ Ｉ／Ｆ（Ａ）
５２００ Ｉ／Ｆ（Ｂ）
５３００ Ｉ／Ｆ（Ｃ）
６０００ 第２のストレージサブシステム
６１００ ディスク装置
６１１０ 論理ボリューム
６１２０ プール
６１２１ 物理リソース
６２００ ディスクコントローラ
６２１０ メモリ
６２２０ 制御装置
６２３０ Ｉ／Ｆ（Ａ）
６２４０ Ｉ／Ｆ（Ｂ）
６２５０ ディスクＩ／Ｆ

Claims (13)

1. １つ以上の物理リソースと、前記物理リソースから構成される１つ以上の記憶領域と、を有する１つ以上の記憶装置と、
   前記記憶装置から割り当てられた１つ以上の記憶領域を有する１つ以上のホスト計算機と、
   前記１つ以上の記憶装置と、前記１つ以上のホスト計算機とを管理する管理計算機と、を有し、
   前記管理計算機は、前記記憶装置及び前記ホスト計算機の構成要素の識別子及び前記構成要素の対応関係を少なくとも含む構成要素基本構成情報を取得し、システムを運用するに従って変動する前記構成要素の詳細構成情報を取得するための取得条件及び取得方法を示す詳細情報取得規則に基づいて、前記構成要素基本構成情報に対応する前記詳細構成情報を取得し、
   前記管理計算機は、さらに、前記構成要素の少なくとも前記詳細構成情報の格納及び破棄についての規則を規定する情報保持ポリシを有し、当該情報保持ポリシに基づいて、前記取得した詳細構成情報の格納及び破棄について管理することを特徴とする計算機システム。
2. 請求項１において、
   前記詳細情報取得規則は、複数の前記取得条件と当該取得条件に対応する複数の前記取得方法の組み合わせによって構成され、
   前記取得方法の情報は、前記詳細構成情報を取得する範囲とタイミングについての情報を含み、
   前記管理計算機は、前記複数の取得条件のそれぞれについて、前記取得条件を満たす前記構成要素が存在するか判定し、当該判定結果及び対応する前記取得方法に基づいて、前記詳細構成情報を取得することを特徴とする計算機システム。
3. 請求項２において、
   前記管理計算機は、前記複数の取得条件の何れも満たさない場合には、前記１つ以上の記憶装置及び前記１つ以上のホスト計算機における全ての構成要素について、前記詳細構成情報を取得することを特徴とする計算機システム。
4. 請求項２において、
   前記管理計算機は、少なくとも、管理対象と当該管理対象に対するタスクの内容を規定する管理タスク情報を保持し、前記管理タスク情報に含まれる前記タスクを実行するために必要な前記詳細構成情報が取得済であるか否かチェックし、前記タスク実行の前に不足している前記詳細構成情報を前記記憶装置及び前記ホスト計算機の少なくとも１つから取得することを特徴とする計算機システム。
5. 請求項１において、
   前記管理計算機は、第１のユーザインタフェースを介して前記構成要素基本構成情報を表示画面上に一覧表示し、前記第１のユーザインタフェースに対してなされたユーザの選択に応答して、前記第１のユーザインタフェースとは異なる第２のユーザインタフェースを介して前記構成要素の前記詳細構成情報を前記表示画面上に表示することを特徴とする計算機システム。
6. 請求項１において、
   前記ホスト計算機に自身の論理ボリュームを直接提供する第１の記憶装置と、少なくとも１つの論理ボリュームを前記第１の記憶装置の論理ボリュームとして前記ホスト計算機に提供するように仮想化された第２の記憶装置と、を有し、
   前記管理計算機は、前記第２の記憶装置が仮想化された論理ボリュームの他に前記ホスト計算機に対して直接割り当てられた論理ボリュームを有する場合のみ、前記第２の記憶装置の前記構成要素について前記詳細構成情報を取得し、前記第２の記憶装置が前記ホスト計算機に対して仮想化された論理ボリュームのみ提供する場合には、前記構成要素の前記詳細構成情報を取得しないことを特徴とする計算機システム。
7. 請求項１において、
   前記情報保持ポリシは、前記詳細構成情報の更新タイミングを規定する情報を含み、
   前記管理計算機は、前記詳細構成情報の最終更新日時を管理する更新履歴情報を有し、前記最終更新日時と前記情報保持ポリシに含まれる前記更新タイミングとに基づいて、前記詳細構成情報の更新の要否を決定し、更新が必要な場合に前記詳細情報取得規則に基づいて前記詳細構成情報を取得することを特徴とする計算機システム。
8. １つ以上の物理リソースと、前記物理リソースから構成される１つ以上の記憶領域と、を有する１つ以上の記憶装置と、前記記憶装置から割り当てられた１つ以上の記憶領域を有する１つ以上のホスト計算機と、前記１つ以上の記憶装置と、前記１つ以上のホスト計算機とを管理する管理計算機と、を有する計算機システムの管理方法であって、
   前記管理計算機は、プロセッサと、メモリと、を有し、当該メモリに前記構成要素の少なくとも前記詳細構成情報の格納及び破棄についての規則を規定する情報保持ポリシを保持し、
   前記プロセッサが、前記記憶装置及び前記ホスト計算機の構成要素の識別子及び前記構成要素の対応関係を少なくとも含む構成要素基本構成情報を取得するステップと、
   前記プロセッサが、前記取得した構成要素基本構成情報を前記メモリに格納するステップと、
   前記プロセッサが、前記計算機システムを運用するに従って変動する前記構成要素の詳細構成情報を取得するための取得条件及び取得方法を示す詳細情報取得規則に基づいて、前記構成要素基本構成情報に対応する前記詳細構成情報を取得するステップと、
   前記プロセッサが、前記情報保持ポリシに基づいて、前記取得した詳細構成情報の格納及び破棄について管理するステップと、
   を有することを特徴とする管理方法。
9. 請求項８において、
   前記詳細情報取得規則は、複数の前記取得条件と当該取得条件に対応する複数の前記取得方法の組み合わせによって構成され、
   前記取得方法の情報は、前記詳細構成情報を取得する範囲とタイミングについての情報を含み、
   前記詳細構成情報を取得するステップにおいて、前記プロセッサは、前記複数の取得条件のそれぞれについて、前記取得条件を満たす前記構成要素が存在するか判定し、当該判定結果及び対応する前記取得方法に基づいて、前記詳細構成情報を取得することを特徴とする管理方法。
10. 請求項９において、
    前記詳細構成情報を取得するステップにおいて、前記プロセッサは、前記複数の取得条件の何れも満たさない場合に、前記１つ以上の記憶装置及び前記１つ以上のホスト計算機における全ての構成要素について、前記詳細構成情報を取得することを特徴とする管理方法。
11. 請求項９において、
    前記管理計算機は、前記メモリに、少なくとも、管理対象と当該管理対象に対するタスクの内容を規定する管理タスク情報を保持し、
    さらに、前記プロセッサが、前記管理タスク情報に含まれる前記タスクを実行するために必要な前記詳細構成情報が取得済であるか否かチェックするステップと、
    前記プロセッサが、前記タスク実行の前に不足している前記詳細構成情報を前記記憶装置及び前記ホスト計算機の少なくとも１つから取得するステップと、
    を有することを特徴とする管理方法。
12. 請求項８において、
    前記ホスト計算機に自身の論理ボリュームを直接提供する第１の記憶装置と、少なくとも１つの論理ボリュームを前記第１の記憶装置の論理ボリュームとして前記ホスト計算機に提供するように仮想化された第２の記憶装置と、を有し、
    さらに、前記プロセッサが、前記第２の記憶装置が仮想化された論理ボリュームの他に前記ホスト計算機に対して直接割り当てられた論理ボリュームを有するか否か判断するステップと、
    前記プロセッサが、前記第２の記憶装置が前記ホスト計算機に対して直接割り当てられた論理ボリュームを有する場合、前記第２の記憶装置の前記構成要素について前記詳細構成情報を取得するステップと、
    前記プロセッサが、前記第２の記憶装置が前記ホスト計算機に対して仮想化された論理ボリュームのみ提供する場合には、前記構成要素の前記詳細構成情報を取得しないように判断するステップと、
    を有することを特徴とする管理方法。
13. １つ以上の物理リソースと、前記物理リソースから構成される１つ以上の記憶領域と、を有する１つ以上の記憶装置と、前記記憶装置から割り当てられた１つ以上の記憶領域を有する１つ以上のホスト計算機と、前記１つ以上の記憶装置と、前記１つ以上のホスト計算機とを管理する管理計算機と、を有する計算機システムにおいて、前記管理計算機のプロセッサに、
    前記記憶装置及び前記ホスト計算機の構成要素の識別子及び前記構成要素の対応関係を少なくとも含む構成要素基本構成情報を取得する処理と、
    前記取得した構成要素基本構成情報をメモリに格納する処理と、
    前記計算機システムを運用するに従って変動する前記構成要素の詳細構成情報を取得するための取得条件及び取得方法を示す詳細情報取得規則に基づいて、前記構成要素基本構成情報に対応する前記詳細構成情報を取得する処理と、
    前記構成要素の少なくとも前記詳細構成情報の格納及び破棄についての規則を規定する情報保持ポリシに基づいて、前記取得した詳細構成情報の格納及び破棄について管理する処理と、
    を実行させるためのプログラム。

Images