JP4616899B2 - 管理サーバ、プール増設方法および計算機システム - Google Patents

Description

本発明は、ストレージ仮想化技術を適用したストレージシステムを有する計算機システムに関する。

近年、１台以上の外部記憶装置と１台以上のホスト計算機（以下、単に「ホスト」ともいう。）とをＳＡＮ（Storage Area Network）によって接続し、１台以上のホスト計算機が１台以上の外部記憶装置からなる大容量記憶装置を使用（ホスト計算機が複数の場合は「共有」）する計算機システムが広く普及している。このような計算機システムでは、記憶資源（外部記憶装置等）や計算機資源（ホスト計算機等）を後から追加、削除、交換等をすることが容易であり、拡張性に優れるという利点がある。ＳＡＮに接続する外部記憶装置には、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成されたストレージ装置が一般的によく利用される。なお、ストレージ装置（単に「ストレージ」ともいう。）とは、ディスク装置等からなる大規模記憶装置のことを指す。

また、最近になって、企業データの増加によるストレージ環境の大規模化や複雑化に伴い、運用管理の容易化やストレージ環境の統合を目的としたストレージシステムの仮想化技術であるシンプロビジョニング（Thin Provisioning）が普及しつつある。
シンプロビジョニングとは、ストレージシステムがそれ自身は記憶領域を持たない（実記憶領域（実際の物理的あるいは論理的な記憶領域）と対応していない）シンプロビジョニングボリュームをホストに提供し（ホストに見せ）、このシンプロビジョニングボリュームにはプールと呼ばれる仮想的な記憶領域の集合を対応させる機能である。そして、ホストがシンプロビジョニングボリュームにアクセスすると、ストレージシステムは、ホストによってアクセスされたシンプロビジョニングボリュームの領域に実記憶領域を割り当てる。

例えば、ホストのプロセッサがストレージ装置のシンプロビジョニングボリュームに書き込みを行ったときに初めて、書き込みが行われたシンプロビジョニングボリューム上の領域に実記憶領域を割り当てる技術が提案されている（特許文献１参照）。また、特許文献２には、ホストがアクセスするシンプロビジョニングボリュームをストレージシステムに設け、このシンプロビジョニングボリュームに物理的記憶領域を割り当てる技術が記載されている。

一つのプールには複数のシンプロビジョニングボリュームが対応可能であるために、ストレージシステムはプールの仮想的な記憶領域を有効活用することができる。つまり、ストレージシステムは、あらかじめ大きな見かけの容量を持つシンプロビジョニングボリュームを用意しておき、ストレージシステムはプールの利用状況に応じてプールに仮想的な記憶領域を追加し、仮想的な記憶容量を増加させることができる。その際、仮想的な記憶領域に対応するハードウェア（記憶媒体）は、最初からすべて用意（設置）しておく必要はなく、必要に応じて後から追加すればよい。そうすることで、安価なハードウェア（記憶媒体）を後から購入して設置する等のメリットが生まれる。
特開２００５−１１３１６号公報 米国特許第６８２３４４２号明細書

シンプロビジョニング等のストレージシステムの仮想化技術によるストレージの統合が進むことで、プールの仮想的な記憶容量は増加する傾向にある。しかしながら、１つのプールの仮想的な記憶容量が増加すると、そのプールが依存する物理的な構成要素（ポートや外部ストレージ装置等）の数も増加するため、プールごとの可用性（壊れにくさの度合い）、更には各シンプロビジョニングボリュームの可用性が低下する。

そこで、本発明は、前記した問題に鑑みてなされたものであり、計算機システムにおいて、プールの仮想的な記憶容量を増加させるときでも、プールごとの可用性をある程度以上に維持することを課題とする。

前記課題を解決するために、本発明は、複数の記憶デバイスと、通信経路を介して接続されるホスト計算機からの要求に応じて記憶デバイスに対するデータの入出力制御を行うコントローラと、を備えるストレージ装置を管理する管理サーバである。
ストレージ装置は、ホスト計算機がアクセスする仮想ボリュームと、仮想ボリュームに割り当てられ、複数の記憶デバイスと対応付けられた仮想的な記憶領域である論理ボリュームの集合であるプールと、をそれぞれ１つ以上備えている。
そして、管理サーバは、コントローラから取得したプールに関する物理的な構成情報を用いて導出した可用性の評価値と、予め記憶している基準値と、を比較し、当該可用性の評価値が基準値を超えたと判断した場合に、プールの増設が必要であると判断し、ストレージ装置にプールの増設を指示することを特徴とする。また、可用性の評価値は、プールに関する物理的な構成要素の数に基づくパラメータを含み、前記数が大きくなるほど大きな値となるものである。
その他の手段については後記する。

本発明によれば、計算機システムにおいて、プールの仮想的な記憶容量を増加させるときでも、プールごとの可用性をある程度以上に維持することができる。

以下、図面を参照（言及図以外の図も適宜参照）して、本発明を実施するための最良の形態（以下、実施形態という。）について説明する。本発明の実施形態として、第１〜第３の実施形態について説明する。

＜第１の実施形態＞
図１から図１０を参照して、第１の実施形態について説明する。
図１は、第１の実施形態の計算機システムのハードウェア構成の一例を示すブロック図である。
第１の実施形態の計算機システムＳは、１台以上のホスト計算機（以下、「ホスト」という。）３００（「３００」は「３００ａ」と「３００ｂ」の総称であり、以下、他の構成についても同様である。）、ファイバチャネルスイッチ４００、管理サーバ２００、ストレージ（装置）１００を備える。

ホスト３００は、ＣＰＵ（Central Processing Unit）３３０、メモリ３１０、記憶装置３２０、入力装置３４０、出力装置３５０、インタフェース制御部（Ｉ／Ｆ）３６０およびポート３７０を備える計算機（コンピュータ装置）である。
ＣＰＵ３３０は、メモリ３１０に格納されたソフトウェアを読み出して実行するプロセッサである。ＣＰＵ３３０がオペレーティングシステムおよびアプリケーションプログラム等のソフトウェアを実行することによって、所定の機能が達成（実現）される。

メモリ３１０には、記憶装置３２０から読み出されたオペレーティングシステムやアプリケーションプログラム等のソフトウェアが格納される。
記憶装置３２０は、例えば、ディスクドライブ又は光磁気ディスクドライブであり、オペレーティングシステムやアプリケーションプログラム等のソフトウェアを格納する。
入力装置３４０は、例えば、キーボードおよびマウス等である。入力装置３４０は、ホスト管理者等からの入力を受け付ける。

出力装置３５０はディスプレイ等であり、ＣＰＵ３３０から指示された情報を出力する。
インタフェース制御部３６０は、ＩＰ（Internet Protocol）ネットワーク１と接続される。ホスト３００は、複数のインタフェース制御部３６０を備えてもよい。
ポート３７０は、ファイバチャネルスイッチ４００のポート１０に接続される。ホスト３００は、一つ以上のホストバスアダプタ（ＨＢＡ）を備え、１つのＨＢＡが１つ以上のポート３７０を備えてもよい。

ファイバチャネルスイッチ４００は、インタフェース制御部（Ｉ／Ｆ）４０１および複数のポート１０を備え、ホスト３００およびストレージ１００を相互に接続するネットワーク（ＳＡＮ）を構成する。

管理サーバ２００は、ＣＰＵ２３０、メモリ２１０、記憶装置２２０、入力装置２４０、出力装置２５０およびインタフェース制御部（Ｉ／Ｆ）２６０を備える計算機である。
ＣＰＵ２３０は、メモリ２１０に格納されたソフトウェアを読み出して実行するプロセッサである。ＣＰＵ２３０がストレージ管理ソフトウェア等を実行することによって、計算機システムＳ全体の運用および保守管理等の所定の機能が達成（実現）される。

メモリ２１０には、記憶装置２２０から読み出されたストレージ管理ソフトウェア等が格納される。
記憶装置２２０は、例えば、ディスクドライブ又は光磁気ディスクドライブであり、ストレージ管理ソフトウェア等を格納する。
入力装置２４０、出力装置２５０およびインタフェース制御部２６０は、それぞれ、入力装置３４０、出力装置３５０およびインタフェース制御部３６０と同様の構成であるため、説明を省略する。

ＣＰＵ２３０によってストレージ管理ソフトウェアが実行されると、管理サーバ２００は、インタフェース制御部２６０からＩＰネットワーク１を介して、計算機システムＳ内の各機器から構成情報、リソース利用率、性能監視情報、障害ログ等を収集する。そして、管理サーバ２００は、収集したそれらの情報を出力装置２５０等の出力装置に出力してストレージ管理者に提示する。また、管理サーバ２００は、キーボードおよびマウス等の入力装置２４０を介してストレージ管理者からの指示の入力を受け付け、その受け付けた運用・保守指示を、インタフェース制御部２６０を介して各機器に送信する。

ストレージ１００は、例えば、コントローラ１０１と、記憶部１１０とを備えたディスクアレイサブシステムのように構成できるデータ記憶装置である。
コントローラ１０１は、ストレージ１００の動作を制御する。コントローラ１０１は、例えば、複数のチャネルアダプタ（ＣＨＡ）１２０、複数のディスクアダプタ（ＤＫＡ）１３０、キャッシュメモリ１４０、共有メモリ１５０、内部結合網１６０、ＳＶＰ(Service Processor)１７０およびインタフェース制御部（Ｉ／Ｆ）１８０を備えて構成される。

ＣＨＡ１２０は、ホスト３００との間のデータ通信を制御するものである。ＣＨＡ１２０は、例えば、マイクロプロセッサやメモリ、プロトコルチップ、データ転送チップ等を備えたコンピュータ装置として構成することができる。各ＣＨＡ１２０は、各ポート１２１を備えている。各ポート１２１には、例えば、ＩＰ（Internet Protocol）アドレスやＷＷＮ（World Wide Name）のようなネットワークアドレスが、それぞれ割り当てられている。

ＤＫＡ１３０は、記憶部１１０との間のデータ通信を制御するものである。ＤＫＡ１３０は、ＣＨＡ１２０と同様に、マイクロプロセッサやメモリ等を備えたコンピュータ装置として構成される。ＤＫＡ１３０のポート１３１は、通信ネットワーク１０２を介して、記憶部１１０に接続されている。

キャッシュメモリ１４０は、ホスト３００から受信したライト（書き込み）データや、記憶部１１０から読み出されたリードデータ等を記憶する。共有メモリ１５０は、ストレージ１００の動作を制御するために必要な各種の制御情報や構成情報等を記憶する。また、キャッシュメモリ１４０と共有メモリ１５０とを同一のメモリパッケージとして構成してもよい。

内部結合網１６０は、例えば、クロスバスイッチ等のように構成される。内部結合網１６０は、各ＣＨＡ１２０、各ＤＫＡ１３０を、キャッシュメモリ１４０、共有メモリ１５０にそれぞれ接続させる。
ＳＶＰ１７０は、内部ＬＡＮ（Local Area Network）等（内部結合網１６０）を介して、ＣＨＡ１２０やインタフェース制御部１８０に接続されている。ＳＶＰ１７０は、ストレージ１００内の各種ステータス等の情報を定期的にまたは不定期に収集し、収集した情報に基づいて、警告信号や解析結果等を出力する。

インタフェース制御部１８０は、ＩＰネットワーク１に接続されている。ＳＶＰ１７０は、インタフェース制御部１８０を介して、管理サーバ２００にも接続可能である。従って、管理サーバ２００は、ＩＰネットワーク１およびＳＶＰ１７０を介して、ストレージ１００の内部状態の情報を取得できる。また、ユーザは、管理サーバ２００からＳＶＰ１７０を介して、ストレージ１００の設定を変更することもできる。

記憶部１１０は、例えば、アレイ状に接続された複数のディスクドライブ１１１（記憶デバイス）を備えている。ディスクドライブ１１１は、例えば、ハードディスクドライブ、半導体メモリドライブ、光ディスクドライブ、光磁気ディスクドライブ、磁気テープドライブ等のような種々の記憶デバイスとして構成することができる。

ハードディスクドライブの場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＡＴＡ（Serial AT Attachment）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスクのように、種々の種類のハードディスクドライブを利用可能である。また、記憶部１１０内に、異なる種類の記憶デバイスを混在させることもできる。
例えば、４台や８台等のような所定数のディスクドライブ１１１によって、一つのグループが構成される。このグループをアレイグループ１１２と呼ぶ。アレイグループ１１２を構成する各ディスクドライブ１１１は、それぞれ物理的な記憶領域を提供し、これら物理的な記憶領域の集合体が形成される。

アレイグループ１１２の物理的記憶領域には、１つまたは複数の論理ボリューム（ldev（logical device）：論理デバイス）１１３（以下、単に「ldev」ともいう。）を設定することができる。ldev１１３は、ＣＨＡ１２０のポート１２１に割り当てられ、ホスト３００からのアクセス対象となる。ホスト３００は、ldev１１３に対応するポート１２１を用いて、ストレージ１００に格納されているデータにアクセスする。ホスト３００によって書き込まれたデータは、最終的に、ディスクドライブ１１１に格納される。

管理サーバ２００から、ストレージ管理ソフトウェアに従って、もしくはストレージ管理者からの指示を受けて、ストレージ１００における構成が変更された場合、または、ストレージ１００における構成が障害・自動交替等によって変化した場合、ＳＶＰ１７０が共有メモリ１５０内の該当する構成情報を更新する。そして、構成情報を更新したＳＶＰ１７０は、当該構成情報を更新した旨を、管理サーバ２００に通知する。

図２は、第１の実施形態の計算機システムの論理構成の一例を示すブロック図である。ストレージ１００内では、１つもしくは複数のldev１１３をプール１１５（以下、符号を省略して単に「プール」ともいう。）にプールボリューム１１４（以下、符号を省略して単に「プールボリューム」ともいう。）として予め登録しておき、ストレージ１００はホスト３００にプール１１５から仮想的なボリューム（記憶領域）であるシンプロビジョニングボリューム１１６(Thin Provisioning volume)（以下、符号を省略して単に「シンプロビジョニングボリューム」ともいう。）（仮想ボリューム）を割り当てる。ホスト３００はシンプロビジョニングボリューム１１６に対してアクセスする。アクセスされたシンプロビジョニングボリューム１１６の領域は、プール１１５内のldev１１３の記憶領域に対応している。

このシンプロビジョニングボリューム１１６に対する記憶領域の割り当ては、ホスト３００からのアクセスに応じてコントローラ１０１によって動的に生成される。シンプロビジョニングボリューム１１６の領域のうち使用されていない領域の分は物理記憶装置を消費（使用）しないので、ストレージシステム（ストレージ１００）はホスト３００に対してあらかじめ十分大きな容量のシンプロビジョニングボリューム１１６を用意して（見せて）おき、プール１１５内の記憶領域のシンプロビジョニングボリューム１１６に対する割り当て状況を見て、徐々に新たなldev１１３をプール１１５に追加するという運用が可能になる。

次に、第１の実施形態におけるプールの可用性の評価値について説明する。可用性とは、前記したように、壊れにくさの度合いのことであるが、具体的には、一般に、システムが利用可能であることが期待される期間（例えば１０００時間）に対する、システムが利用可能である時間（例えば９９９時間（１時間は故障のため利用不可））の比（例えば999/1000＝0.999）である。第１の実施形態では、プールの構成要素の数が多いほど当該プールに障害が発生する（構成要素のいずれかが故障する）可能性が高いと考えて、プールの構成要素の種別ごとのその個数をプールの可用性の評価値と定義する。つまり、構成要素の種別ごとにその個数が多いほど、プールの可用性が低いと考える。ただし、第１の実施形態ではプールの可用性の評価値を構成要素の数で求めるが、プールの可用性の評価値をプールの全構成要素の平均故障時間の総計としてもよい。平均故障時間の総計とは、各平均故障時間の逆数の和を求め、その和の逆数である。

次に、第１の実施形態における管理サーバ２００のソフトウェア構成について説明する。
図３は、第１の実施形態の管理サーバ２００の記憶装置２２０およびメモリ２１０に格納される、制御情報（構成情報）およびストレージ制御処理のためのプログラムの一例を示すソフトウェア構成図である。
記憶装置２２０には、構成情報２２１、基準値２２２および可用性評価値テーブル２２７が格納される。なお、可用性評価値テーブル２２７は、構成情報２２１内に格納されてもよい。ストレージ１００から収集する構成情報２２１には、プール・プールボリューム対応テーブル２２３およびプールボリューム・物理リソース対応テーブル２２４が含まれる。

さらに、メモリ２１０には、制御処理プログラム２１１、構成変更検知処理プログラム２１２、可用性評価値導出処理プログラム２１３、増設要否判定処理プログラム２１４、プール作成処理プログラム２１５およびボリューム追加処理プログラム２１６が格納される。これらの処理プログラムは、ＣＰＵ２３０によって実行されるプログラムである。これらの処理については、後で詳細に説明する。

次に、各制御情報（構成情報）について説明する。まず、プール・プールボリューム対応テーブル２２３について説明する。
図４は、第１の実施形態のプール・プールボリューム対応テーブル２２３の一例を示す説明図である。プール・プールボリューム対応テーブル２２３は、各プールについて、当該プールを構成するプールボリューム名２２とそれぞれのプールボリュームの容量２３の情報の組を保持する。

プール名２１には、プールを識別するためにＳＶＰ１７０がプールに割り当てた名称が格納される。プール名は、任意の文字列等、当該プールを一意に識別可能な値であれば何を用いてもよい。
プールボリューム名２２には、プールボリュームを識別するためにＳＶＰ１７０がプールに割り当てた名称が格納される。
容量２３には、各プールボリューム名２２に示されるプールボリュームのそれぞれのボリュームの容量（５０Ｔ（テラバイト）等）を示す情報が格納される。

次に、プールボリューム・物理リソース対応テーブル２２４について説明する。
図５は、プールボリューム・物理リソース対応テーブル２２４の一例を示す説明図である。プールボリューム・物理リソース対応テーブル２２４は、プールボリュームごとにプールボリューム名３１、ldev名３２、ldevサイズ３３、ＤＫＡ名３４、ＤＫＡポート名３５およびアレイグループ名３６の情報の組を保持する。

プールボリューム名３１には、ストレージ１００のＳＶＰ１７０が当該プールボリュームに対して割り当てた、ストレージ１００内で一意な値が格納される。
ldev名３２には、ＳＶＰ１７０が当該プールボリュームとして割り当てたldev１１３の名称が格納される。
ldevサイズ３３には、各ldev名３２に示されるldev１１３のそれぞれの容量を示す情報が格納される。

ＤＫＡ名３４には、各アレイグループ１１２が接続されているＤＫＡ１３０の名称が格納される。
ＤＫＡポート名３５には、各アレイグループ１１２を接続するＤＫＡ１３０のポート１３１の名称が格納される。
アレイグループ名３６には、当該アレイグループ１１２に割り当てられたアレイグループの名称が格納される。

次に、基準値２２２について説明する。
図６は、基準値２２２の内容の一例を示す説明図である。基準値２２２は、ldev数４１、ＤＫＡ数４２およびポート数４３の情報の組を保持する。
ldev数４１には、１つのプールに含まれるldev１１３の個数の最大数が格納される。
ＤＫＡ数４２には、１つのプールに含まれるＤＫＡ１３０の個数の最大数が格納される。
ポート数４３には、１つのプールに含まれるポート１３０の個数の最大数が格納される。

第１の実施形態では、基準値２２２の各値はストレージ管理者が設定することを想定している。ただし、基準値２２２の各値に関して、管理サーバ２００のストレージ管理ソフトウェアが過去に発生した仮想ボリュームが使用不可となる障害時のプールの構成情報に基づいて基準値を設定するものとしてもよい。

次に、可用性評価値テーブル２２７について説明する。
図９は、可用性評価値テーブル２２７の一例を示す図である。可用性評価値テーブル２２７は、プールボリュームごとのldev数５１、ＤＫＡ数５２およびポート数５３の情報の組を保持する（詳細は図８で後記）。

次に、再び図３に戻り、管理サーバ２００のメモリ２１０に格納されているプログラムについて説明する。なお、これらのプログラムは、ＣＰＵ２３０により実行されるが、以下では、説明を簡潔にするために、各動作プログラムを動作主体として記載する。

制御処理プログラム２１１は、入力装置２４０からの指示を受け起動され、構成変更検知処理プログラム２１２、可用性評価値導出処理プログラム２１３、増設要否判定処理プログラム２１４、プール作成処理プログラム２１５およびボリューム追加処理プログラム２１６による一連の処理を制御する。

図７は、第１の実施形態の管理サーバ２００で実行される制御処理プログラム２１１による処理フローの一例を示す図である。
制御処理プログラム２１１は、図７に示すように、まず、ステップ７００で構成変更検知処理プログラム２１２を起動する。構成変更検知処理プログラム２１２は、ストレージ１００のＳＶＰ１７０を介してストレージ１００のプール構成の変更の有無を確認し、ldev１１３ａを追加する等のプール構成の変更があった場合にはそのことを検知する。ストレージ１００のプール構成の変更を検知した場合（ステップ７００でＹｅｓ）、ステップ７０１に進む。ストレージ１００のプール構成の変更を検知しない場合（ステップ７００でＮｏ）、ステップ７００の処理を繰り返す。

ステップ７０１で、制御処理プログラム２１１は、可用性評価値導出処理プログラム２１３を起動する。可用性評価値導出処理プログラム２１３は、構成情報２２１に基づきプール構成の変更後のプールの可用性の評価値を導出する。この可用性の評価値の導出の処理フローは図８で詳細に説明する。

次に、ステップ７０２で、制御処理プログラム２１１は、増設要否判定処理プログラム２１４を起動する。増設要否判定処理プログラム２１４は、ステップ７０１で導出したプールの可用性の評価値（図９参照）の各パラメータと、基準値２２２の各パラメータとを比較する。いずれか１種類のパラメータでも基準値を超える場合には、新規プールの増設（作成）が必要と判定し（ステップ７０２で「要」）、ステップ７０３に進む。いずれのパラメータも基準値を超えない場合には、新規プールの増設（作成）が不要と判定し（ステップ７０２で「否」）、ステップ７００に戻る。

ステップ７０３で、制御処理プログラム２１１は、プール作成処理プログラム２１５を起動する。プール作成処理プログラム２１５は、ストレージ１００のＳＶＰ１７０に対してプールの新規作成を指示する。
ステップ７０３の後、ステップ７０４で、制御処理プログラム２１１は、ボリューム追加処理プログラム２１６を起動する。ボリューム追加処理プログラム２１６は、ステップ７０３で作成したプールにldev１１３ａを追加する。

図８は、図７のステップ７０１の処理フローの一例を示す図である。
まず、ステップ８００で、可用性評価値導出処理プログラム２１３は、プールを構成する各プールボリューム名称（プールボリューム名２２）をプール・プールボリューム対応テーブル２２３から取得する。
次に、ステップ８０１で、可用性評価値導出処理プログラム２１３は、プールボリューム・物理リソース対応テーブル２２４から各プールボリュームを構成するldev名３２を取得（検索）し、その個数を可用性評価値テーブル２２７のldev数５１に格納する。

次に、ステップ８０２で、可用性評価値導出処理プログラム２１３は、プールボリューム・物理リソース対応テーブル２２４から各ldevが使用するＤＫＡ名３４を取得（検索）し、その個数を可用性評価値テーブル２２７のＤＫＡ数５２に格納する。
最後に、ステップ８０３で、可用性評価値導出処理プログラム２１３は、プールボリューム・物理リソース対応テーブル２２４から各ldevが使用するＤＫＡポート名３５を取得（検索）し、その個数を可用性評価値テーブル２２７のポート数５３に格納する。

例えば、第１の実施形態で、プールの残容量低下に伴いストレージ１００にアレイグループ１１２ｃ（不図示）およびldev１１３ｃを追加したときに、図７および図８のフローに従い図９に示す可用性評価値テーブル２２７の各評価値を導出したとする。可用性評価値テーブル２２７の各評価値と基準値２２２とを比較すると、可用性評価値テーブル２２７におけるＤＫＡ数５２が基準値２２２におけるＤＫＡ数４２を超えている。よって、この場合、プールの増設が必要と判断して、図１０のようにストレージ１００にプール１１５ｂを増設し、新たに追加したldev１１３ｃを当該プール１１５ｂにプールボリューム１１４ｃに対応させて追加する。こうすることで、各プール１１５の可用性の劣化を抑制できる。図１０は、プールを増設した場合の論理構成の一例（図２に対応）を示す図である。

また、可用性評価値テーブル２２７および基準値２２２の項目として前記したもの以外に、プールが依存する構成要素であるファイバチャネルスイッチ４００の装置数、ファイバチャネルスイッチ４００のポート１０の個数、キャッシュメモリ１４０の個数、あるいは、共有メモリ１５０の個数等を用いてもよい。

＜第２の実施形態＞
図１１から図１７を参照して、第２の実施形態について説明する。第２の実施形態は、外部ストレージを含めてストレージシステムを構築していることが第１の実施形態と異なる。
図１１は、第２の実施形態における計算機システムＳａ（Ｓ）のハードウェア構成の一例を示すブロック図である。つまり、第２の実施形態では、第１の実施形態（図１）と比較し、外部ストレージ１０００が追加されており、また、管理サーバ２００の構成に変更点がある。

まず、外部ストレージ１０００の構成について説明する。外部ストレージ１０００は、例えば、コントローラ１００１と、記憶部１０１０とを備えるディスクアレイサブシステムとして構成することができる。
コントローラ１００１は、外部ストレージ１０００の動作を制御するもので、前記したコントローラ１０１と同様に、ＣＨＡ１０２０、ＤＫＡ１０３０、キャッシュメモリ１０４０、共有メモリ１０５０、内部結合網１０６０、ＳＶＰ１０７０およびインタフェース制御部（Ｉ／Ｆ）１０８０を備えている。コントローラ１００１は、ポート１０３１および通信ネットワーク１００２を介して、記憶部１０１０に接続されている。

記憶部１０１０は、前記した記憶部１１０と同様に、複数のディスクドライブ１０１１を備えている。そして、複数のディスクドライブ１０１１によってアレイグループ１０１２が構成されている。このアレイグループ１０１２には、ldev１０１３が設けられる。
また、コントローラ１００１は、ポート１０２１を介して、ストレージ１００のコントローラ１０１のポート１２１に接続されている。コントローラ１００１とコントローラ１０１との間には、通信ネットワーク１００２が設定されている。
なお、ストレージ１００と各外部ストレージ１０００との間を、それぞれ複数の通信ネットワーク１００２で接続してもよい。これにより、通信負荷を分散させたり、耐障害性を向上させたりすることができる。

ストレージ１００は、外部ストレージ接続を実行することができる。外部ストレージ接続とは、外部ストレージ１０００のldev１０１３を外部デバイスとして管理し、ストレージ１００のデバイスとして仮想化する技術である。この外部ストレージ接続を用いてストレージ１００によって管理される一つ以上の外部デバイスは、ストレージ１００の物理デバイスと同様、ストレージ１００のldev１１３と直接対応づけられる。

外部デバイスは、各ストレージ１００内で独立して管理され、前記したシンプロビジョニング技術を適用できる。ストレージ１００で管理するプールにストレージ１０００の外部デバイスをプールボリュームとして格納できる。つまり、ストレージ１０００のldev１０１３は、ストレージ１００のプール１１５にプールボリューム１１４として格納して管理できる。

次に、第２の実施形態における管理サーバ２００のソフトウェア構成について説明する。
図１２は、第２の実施形態の管理サーバ２００の記憶装置２２０およびメモリ２１０に格納される、制御情報（構成情報）およびストレージ制御処理のためのプログラムの一例を示すソフトウェア構成図である。
管理サーバ２００は、第１の実施形態の管理サーバ２００（図３）とほぼ同じであるが、構成情報２２１にプールボリューム・外部接続リソース対応テーブル２２５が追加されており、可用性評価値導出処理２１３ａ、基準値２２２ａおよび可用性評価値テーブル２２７ａが変更されている。

プールボリューム・外部接続リソース対応テーブル２２５について説明する。
図１３は、プールボリューム・外部接続リソース対応テーブル２２５の一例を示す説明図である。プールボリューム・外部接続リソース対応テーブル２２５は、プールボリュームごとにプールボリューム名６１、ldev名６２、ldevサイズ６３、ＤＫＡ名６４、ＤＫＡポート名６５、アレイグループ名６６、外部ストレージ名６７および外部ストレージ側ポート名６８の情報の組を保持する。

プールボリューム名６１には、ストレージ１００のＳＶＰ１７０が当該プールボリュームに対して割り当てた、ストレージ１００内で一意な値が格納される。
ldev名６２には、ＳＶＰ１７０が当該プールボリュームに割り当てたldev１０１３の名称が格納される。
ldevサイズ６３には、各ldev名６２に示されるldev１０１３のそれぞれの容量を示す情報が格納される。
ＤＫＡ名６４には、各アレイグループ１０１２が接続されているＤＫＡ１０３０の名称が格納される。

ＤＫＡポート名６５には、各アレイグループ１０１２が接続されているＤＫＡ１０３０のポート１０３１の名称が格納される。
アレイグループ名６６には、ＳＶＰ１７０が当該アレイグループ１０１２に割り当てたアレイグループ１０１２の名称が格納される。
外部ストレージ名６７には、当該プールボリュームを構成するアレイグループ１０１２が格納されている外部ストレージ１０００の名称が格納される。
外部ストレージ側ポート名６８には、当該外部ストレージ１０００を接続するポート１０２１の名称が格納される。

次に、基準値２２２ａについて説明する。
図１４は、基準値２２２ａの内容の一例を示す説明図である。基準値２２２ａは、基準値２２２（図６参照）における項目に加えて、外部ストレージ数７４および外部接続ポート数７５の情報の組を保持する。
外部ストレージ数７４には、ストレージ１００に外部接続する外部ストレージ１０００の個数が格納される。
外部接続ポート数７５には、外部ストレージ１０００を接続するポート１０２１の個数が格納される。

第２の実施形態では、基準値２２２ａの各値はストレージ管理者が設定することを想定している。ただし、基準値２２２ａの各値を管理サーバ２００のストレージ管理ソフトウェアが過去の障害情報に基づき自動的に設定するとしてもよい。
また、外部ストレージ数７４は、ストレージ１００から外部ストレージ１０００への総Ｉ／Ｏ（Input/Output）量（入出力量）をホスト３００からストレージ１００への全Ｉ／Ｏ量で除算した値を外部ストレージ数７４に乗算した値を用いてもよい。そうすれば、可用性に影響を与える可能性のあるＩ／Ｏ量についても考慮することで、可用性の評価をより高精度で行うことができる。

次に、可用性評価値テーブル２２７について説明する。
図１７は、可用性評価値テーブル２２７ａの一例を示す図である。可用性評価値テーブル２２７ａは、プールごとのldev数８１、ＤＫＡ数８２、ポート数８３、外部ストレージ数８４および外部接続ポート数８５の情報の組を保持する（詳細は図１６で後記）。

図１５は、第２の実施形態の管理サーバ２００で実行される制御処理プログラム２１１による処理フローの一例を示す図である。
制御処理プログラム２１１は、まず、ステップ１１００で、構成変更検知処理プログラム２１２を起動する。構成変更検知処理プログラム２１２は、ストレージ１００のＳＶＰ１７０を介してストレージ１００の構成変更の有無を確認し、ldev１１３ａもしくはldev１０１３ａを追加する等の構成変更があった場合にはそのことを検知する。ストレージ１００のプール構成の変更を検知した場合（ステップ１１００でＹｅｓ）、ステップ１１０１に進む。ストレージ１００のプール構成の変更を検知しない場合（ステップ１１００でＮｏ）、ステップ１１００の処理を繰り返す。

ステップ１１０１で、制御処理プログラム２１１は、可用性評価値導出処理プログラム２１３ａを起動する。可用性評価値導出処理プログラム２１３ａは、構成情報２２１に基づき外部ストレージ１０００を含めてプール構成の変更後の可用性の評価値を導出する。可用性の評価値の導出の処理フローは図１６で詳細に説明する。

次に、ステップ１１０２で、制御処理プログラム２１１は、増設要否判定処理プログラム２１４を起動する。増設要否判定処理プログラム２１４は、ステップ１１０１で導出した可用性の評価値（図１７参照）の各パラメータと、基準値２２２ａの各パラメータとを比較する。いずれか１種類のパラメータでも基準値を超える場合には、プールの増設が必要と判定し（ステップ１１０２で「要」）、ステップ１１０３に進む。いずれのパラメータも基準値を超えない場合には、新規プールの増設（作成）が不要と判定し（ステップ１１０２で「否」）、ステップ１１００に戻る。

次に、ステップ１１０３で、制御処理プログラム２１１は、プール作成処理プログラム２１５を起動する。プール作成処理プログラム２１５は、ストレージ１００のＳＶＰ１７０に対してプールの新規作成を指示する。
ステップ１１０３の後、ステップ１１０４で、制御処理プログラム２１１は、ボリューム追加処理プログラム２１６を起動する。ボリューム追加処理プログラム２１６は、ステップ１１０３で作成したプールにldev１１３ａもしくはldev１０１３ａを追加する。

図１６は、図１５のステップ１１０１の処理フローの一例を示す図である。
まず、ステップ１２００で、可用性評価値導出処理プログラム２１３ａは、プールを構成する各プールボリューム名称（プールボリューム名２２）をプール・プールボリューム対応テーブル２２３から取得する。
次に、ステップ１２０１で、可用性評価値導出処理プログラム２１３ａは、プールボリューム・物理リソース対応テーブル２２４から各プールボリュームを構成するldev名３２を取得し、その個数を可用性評価値テーブル２２７ａのldev数８１に格納する。

次に、ステップ１２０２で、可用性評価値導出処理プログラム２１３ａは、プールボリューム・物理リソース対応テーブル２２４から各ldevが使用するＤＫＡ名３４を取得し、その個数を可用性評価値テーブル２２７ａのＤＫＡ数８２に格納する。
次に、ステップ１２０３で、可用性評価値導出処理プログラム２１３ａは、プールボリューム・物理リソース対応テーブル２２４から各ldevが使用するＤＫＡポート名３５を取得し、その個数を可用性評価値テーブル２２７ａのポート数８３に格納する。

次に、ステップ１２０４で、可用性評価値導出処理プログラム２１３ａは、プールボリューム・外部接続リソース対応テーブル２２５から各プールを構成する外部ストレージ１０００の個数を取得（検索）し、可用性評価値テーブル２２７ａの外部ストレージ数８４に格納する。

最後に、ステップ１２０５で、可用性評価値導出処理プログラム２１３ａは、プールボリューム・外部接続リソース対応テーブル２２５から各外部ストレージ１０００のポート１０２１の数を取得（検索）し、可用性評価値テーブル２２７ａの外部接続ポート数８５に格納する。

例えば、第２の実施形態で、プールの残容量低下に伴いストレージ１００に外部ストレージ１０００を追加（接続）したときに、図１５および図１６のフローに従い図１７に示す可用性評価値テーブル２２７ａの各評価値を導出したとする。可用性評価値テーブル２２７ａと基準値２２２ａとを比較すると、可用性評価値テーブル２２７ａにおける外部ストレージ数８４が基準値２２２ａにおける外部ストレージ数７４を超えている。よって、この場合、第１の実施形態における図１０の場合と同様にプールの増設が必要と判断してストレージ１００にプールを増設し、新たに追加したldev１０１３を当該プールにプールボリュームとして追加する。こうすることで、プールの可用性の劣化を抑制できる。

なお、第２の実施形態におけるストレージ１００のようなプール１１５を構築する装置が、物理的記憶領域となる記憶部１１０等の物理的デバイスを内部に保持せず、コントローラ１０１のみからなる構成であり、物理的記憶領域を外部に有するものとしてもよい。

＜第３の実施形態＞
図１８から図２２を参照して、第３の実施形態について説明する。
前記した２つの実施形態では、ホスト３００によるストレージ１００の使用量が増加するに従ってプールの増設が頻発する可能性があり、増設時のコスト（処理時間等）が問題となる。そこで第３の実施形態では、シンプロビジョニングボリュームの仮想サイズの合計分までデータを格納した場合のプールの構成を予測して、プールの可用性の評価値を導出する。この予測したプールの可用性の評価値に基づいてプール増設の要否を判定することで、ホストがシンプロビジョニングボリュームの仮想サイズ分までデータを格納してもプールの増設が必要となる事態を回避する。

第３の実施形態が適用される計算機システムのハードウェア構成は、図１に示す第１の実施形態と同様であり、管理サーバ２００のソフトウェア構成に変更点がある。
管理サーバ２００について説明する。図１８は、第３の実施形態の管理サーバ２００の一例を示すソフトウェア構成図である。管理サーバ２００は、第１の実施形態の管理サーバ２００（図３）とほぼ同じであるが、構成情報２２１にシンプロビジョニングボリューム・プール対応テーブル２２６が追加されている。

シンプロビジョニングボリューム・プール対応テーブル２２６について説明する。
図１９は、シンプロビジョニングボリューム・プール対応テーブル２２６の一例を示す説明図である。シンプロビジョニングボリューム・プール対応テーブル２２６は、プール名９１、シンプロビジョニングボリューム名９２、仮想容量９３および使用容量９４の情報の組を保持する。

プール名９１には、プールを識別するためにＳＶＰ１７０がプールに割り当てた名称が格納される。プール名９１は、任意の文字列等、当該プールを一意に識別可能な値であれば何を用いてもよい。
シンプロビジョニングボリューム名９２には、各ホスト３００に提供しているシンプロビジョニングボリュームを識別するためにＳＶＰ１７０がそれぞれに割り当てた名称が格納される。

仮想容量９３には、各シンプロビジョニングボリュームそれぞれの仮想容量を示す情報が格納される。
使用容量９４には、各シンプロビジョニングボリュームそれぞれの実際に使用している容量を示す情報が格納される。

図２０は、第３の実施形態の管理サーバ２００で実行される制御処理プログラム２１１による処理フローの一例を示す図である。
制御処理プログラム２１１は、まず、ステップ１３００で、構成変更検知処理プログラム２１２を起動する。構成変更検知処理プログラム２１２は、ストレージ１００のＳＶＰ１７０を介してストレージ１００のプール構成の変更の有無を確認し、ldev１１３ａを追加する等の構成変更があった場合にはそのことを検知する。ストレージ１００のプール構成の変更を検知した場合（ステップ１３００でＹｅｓ）、ステップ１３０１に進む。ストレージ１００のプール構成の変更を検知しない場合（ステップ１３００でＮｏ）、ステップ１３００の処理を繰り返す。

ステップ１３０１で、制御処理プログラム２１１は、可用性評価値導出処理プログラム２１３ｂを起動する。可用性評価値導出処理プログラム２１３ｂは、プール構成の変更後のプールの可用性の評価値を、シンプロビジョニングボリューム・プール対応テーブル２２６の仮想容量９３（仮想ボリュームの仮想サイズ）等に基づいて導出する。この可用性の評価値の導出の処理フローは図２１で詳細に説明する。

次に、ステップ１３０２で、制御処理プログラム２１１は、増設要否判定処理プログラム２１４を起動する。増設要否判定処理プログラム２１４は、ステップ１３０１で導出した可用性の評価値の各パラメータ（図２２で後記）と、基準値２２２の各パラメータとを比較する。いずれか１種類のパラメータでも基準値を超える場合には、新規プールの増設（作成）が必要と判定し（ステップ１３０２で「要」）、ステップ１３０３に進む。いずれのパラメータも基準値を超えない場合には、新規プールの増設（作成）が不要と判定し（ステップ１３０２で「否」）、ステップ１３００に戻る。

次に、ステップ１３０３で、制御処理プログラム２１１は、プール作成処理プログラム２１５を起動する。プール作成処理プログラム２１５は、ストレージ１００のＳＶＰ１７０に対してプールの新規作成を指示する。

ステップ１３０３の後、ステップ１３０４で、制御処理プログラム２１１は、ボリューム追加処理プログラム２１６を起動する。ボリューム追加処理プログラム２１６は、ステップ１３０３で作成したプールにldev１１３ａを追加する。

図２１は、図２０のステップ１３０１の処理フローの一例を示す図である。
まず、ステップ１４００で、可用性評価値導出処理プログラム２１３ｂは、プールを構成する各プールボリューム名称（プールボリューム名２２）をプール・プールボリューム対応テーブル２２３から取得する。
次に、ステップ１４０１で、可用性評価値導出処理プログラム２１３ｂは、プールボリューム・物理リソース対応テーブル２２４から各プールボリュームを構成するldev名３２を取得（検索）し、その個数を可用性評価値テーブル２２７（図２２（ａ）で後記）のldev数５１に格納する。

次に、ステップ１４０２で、可用性評価値導出処理プログラム２１３ｂは、プールボリューム・物理リソース対応テーブル２２４から各ldevが使用するＤＫＡ名３４を取得（検索）し、その個数を可用性評価値テーブル２２７（図２２（ａ）で後記）のＤＫＡ数５２に格納する。
次に、ステップ１４０３で、可用性評価値導出処理プログラム２１３ｂは、プールボリューム・物理リソース対応テーブル２２４から各ldevが使用するＤＫＡポート名３５を取得（検索）し、その個数を可用性評価値テーブル２２７（図２２（ａ）で後記）のポート数５３に格納する。
次に、ステップ１４０４で、可用性評価値導出処理プログラム２１３ｂは、シンプロビジョニングボリューム・プール対応テーブル２２６の仮想容量９３（仮想サイズ）から、各プールのシンプロビジョニングボリュームに割り当てている仮想サイズを合算した容量（総容量）を取得する。

次に、ステップ１４０５で、可用性評価値導出処理プログラム２１３ｂは、シンプロビジョニングボリューム・プール対応テーブル２２６の使用容量９４から、各プールのシンプロビジョニングボリュームが実際に使用している容量の値を合算して総使用容量（総容量）を取得する。
次に、ステップ１４０６で、可用性評価値導出処理プログラム２１３ｂは、ステップ１４０４で取得した値をステップ１４０５で取得した値で除算し、仮想サイズと実使用サイズの差の率（比率）を取得する。

最後に、ステップ１４０７で、可用性評価値導出処理プログラム２１３ｂは、可用性評価値テーブル２２７の評価値それぞれにステップ１４０６で取得した値を乗算する。
図２２は、図１９に示すシンプロビジョニングボリューム・プール対応テーブル２２６の各値の内容のときに図２０および図２１の処理フローを実行した例である。図２１のステップ１４００からステップ１４０２までで取得したプールの可用性の評価値を図２２の（ａ）に示す。ステップ１４０４で取得した値は３００Ｔバイト、ステップ１４０５で取得した値は１００Ｔバイトとなり、ステップ１４０６で算出する仮想サイズと実サイズの差の率は「３」となる。よって、図２２の（ａ）の可用性評価値テーブル２２７の各値をそれぞれ３倍すると、図２２の（ｂ）の可用性評価値テーブル２２７の各値となる。

この図２２の（ｂ）の可用性評価値テーブル２２７の各値を用いて第１の実施形態あるいは第２の実施形態の可用性の評価を行えば、予めシンプロビジョニングボリュームの仮想サイズの合計分までデータを格納した場合のプールの構成を予測して可用性の評価値を導出しているので、ホスト３００によるストレージ１００の使用量が増加してもプールの増設を行う必要がなく、増設時のコスト（処理時間等）が問題となる事態を回避することができる。

このように、第１〜第３の実施形態によれば、計算機システムＳにおいて、プールの仮想的な記憶容量を増加させるときでも、プールごとの可用性をある程度以上に維持することができる。

以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。例えば、プール増設の必要を判断するタイミングは、プール構成の変更を検知した直後でなくても、定期的あるいは他のタイミング等であってもよい。その他、ハードウェア、プログラム等の具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

第１の実施形態が適用される計算機システムのハードウェア構成の一例を示す図である。 第１の実施形態が適用される計算機システムの論理構成の一例を示す図である。 第１の実施形態の管理サーバのメモリおよび記憶装置に格納される構成情報およびストレージ制御処理のためのプログラムの一例を示す図である。 第１の実施形態のプール・プールボリューム対応テーブルの一例を示す図である。 第１の実施形態のプールボリューム・物理リソース対応テーブルの一例を示す図である。 第１の実施形態の基準値の一例を示す図である。 第１の実施形態の管理サーバで実行される処理の一例を示すフローチャートである。 第１の実施形態の管理サーバで実行される可用性評価値導出処理の一例を示すフローチャートである。 第１の実施形態の可用性評価値テーブルの一例を示す図である。 第１の実施形態が適用される計算機システムにおいてプールを増設した場合の論理構成の一例を示す図である。 第２の実施形態が適用される計算機システムのハードウェア構成の一例を示す図である。 第２の実施形態の管理サーバのメモリおよび記憶装置に格納される構成情報およびストレージ制御処理のためのプログラムの一例を示す図である。 第２の実施形態のプールボリューム・外部接続リソース対応テーブルの一例を示す図である。 第２の実施形態の基準値の一例を示す図である。 第２の実施形態の管理サーバで実行される処理の一例を示すフローチャートである。 第２の実施形態の管理サーバで実行される可用性評価値導出処理の一例を示すフローチャートである。 第２の実施形態の可用性評価値テーブルの一例を示す図である。 第３の実施形態の管理サーバのメモリおよび記憶装置に格納される構成情報およびストレージ制御処理のためのプログラムの一例を示す図である。 第３の実施形態のシンプロビジョニングボリューム・プール対応テーブルの一例を示す図である。 第３の実施形態の管理サーバで実行される処理の一例を示すフローチャートである。 第３の実施形態の管理サーバで実行される可用性評価値導出処理の一例を示すフローチャートである。 第３の実施形態が適用される計算機システムにおいて可用性の評価値を予測した場合の一例を示す図である。

符号の説明

１００ ストレージ（装置）
１０１ コントローラ
１１１ ディスクドライブ（記憶デバイス）
１１３ 論理ボリューム（ldev）
１１５ プール
１１６ シンプロビジョニングボリューム（仮想ボリューム）
１２０ チャネルアダプタ
１２１ ポート
１３０ ディスクアダプタ
１３１ ポート
２００ 管理サーバ
２２２ 基準値
３００ ホスト（計算機）
１０００ 外部ストレージ（装置）

Claims (17)

1. 複数の記憶デバイスと、通信経路を介して接続されるホスト計算機からの要求に応じて前記記憶デバイスに対するデータの入出力制御を行うコントローラと、を備えるストレージ装置を管理する管理サーバであって、
   前記ストレージ装置は、
   前記ホスト計算機がアクセスする仮想ボリュームと、
   前記仮想ボリュームに割り当てられ、前記複数の記憶デバイスと対応付けられた仮想的な記憶領域である論理ボリュームの集合であるプールと、をそれぞれ１つ以上備えており、
   前記管理サーバは、
   前記コントローラから取得した前記プールに関する物理的な構成情報を用いて導出した可用性の評価値と、予め記憶している基準値と、を比較し、当該可用性の評価値が前記基準値を超えたと判断した場合に、前記プールの増設が必要であると判断し、前記ストレージ装置に前記プールの増設を指示し、
   前記可用性の評価値は、前記プールに関する物理的な構成要素の数に基づくパラメータを含み、前記数が大きくなるほど大きな値となるものである
   ことを特徴とする管理サーバ。
2. 前記パラメータは、前記ストレージ装置のコントローラにおける前記複数の記憶デバイスとの間のデータ通信を制御するためのディスクアダプタ、前記ディスクアダプタにおける通信用のポート、および、前記論理ボリューム、の少なくともいずれかの数である
   ことを特徴とする請求項１に記載の管理サーバ。
3. 前記パラメータが複数あり、
   前記管理サーバは、
   当該パラメータのいずれか１つでもその対応する前記基準値を超えた場合、前記プールの増設が必要であると判断する
   ことを特徴とする請求項２に記載の管理サーバ。
4. 前記管理サーバは、
   過去に発生した前記仮想ボリュームが使用不可となる障害時の前記プールの物理的な構成情報に基づいて、前記基準値を設定する
   ことを特徴とする請求項１に記載の管理サーバ。
5. 前記ストレージ装置は、接続された外部ストレージ装置における論理ボリュームを前記プールに含んでおり、
   前記基準値は、前記外部ストレージ装置の物理的な構成情報に関する情報を含んでいる
   ことを特徴とする請求項１に記載の管理サーバ。
6. 前記可用性の評価値は、前記ストレージ装置と前記外部ストレージ装置とのデータの入出力量に基づくパラメータを含む
   ことを特徴とする請求項５に記載の管理サーバ。
7. 前記管理サーバは、
   前記仮想ボリュームの総容量分までデータを格納した場合の前記プールに関する物理的な構成情報を予測し、その予測した物理的な構成情報を用いて前記可用性の評価値を導出し、その導出した前記可用性の評価値と前記基準値とを比較し、当該可用性の評価値が前記基準値を超えたと判断した場合に、前記プールの増設が必要であると判断し、前記ストレージ装置に前記プールの増設を指示する
   ことを特徴とする請求項１に記載の管理サーバ。
8. 複数の記憶デバイスと、通信経路を介して接続されるホスト計算機からの要求に応じて前記記憶デバイスに対するデータの入出力制御を行うコントローラと、を備えるストレージ装置を管理する管理サーバによるプール増設方法であって、
   前記ストレージ装置は、
   前記ホスト計算機がアクセスする仮想ボリュームと、
   前記仮想ボリュームに割り当てられ、前記複数の記憶デバイスと対応付けられた仮想的な記憶領域である論理ボリュームの集合であるプールと、をそれぞれ１つ以上備えており、
   前記管理サーバは、
   前記コントローラから取得した前記プールに関する物理的な構成情報を用いて導出した可用性の評価値と、予め記憶している基準値と、を比較し、当該可用性の評価値が前記基準値を超えたと判断した場合に、前記プールの増設が必要であると判断し、前記ストレージ装置に前記プールの増設を指示し、
   前記可用性の評価値は、前記プールに関する物理的な構成要素の数に基づくパラメータを含み、前記数が大きくなるほど大きな値となるものである
   ことを特徴とするプール増設方法。
9. 前記パラメータは、前記ストレージ装置のコントローラにおける前記複数の記憶デバイスとの間のデータ通信を制御するためのディスクアダプタ、前記ディスクアダプタにおける通信用のポート、および、前記論理ボリューム、の少なくともいずれかの数である
   ことを特徴とする請求項８に記載のプール増設方法。
10. 前記パラメータが複数あり、
    前記管理サーバは、
    当該パラメータのいずれか１つでもその対応する前記基準値を超えた場合、前記プールの増設が必要であると判断する
    ことを特徴とする請求項９に記載のプール増設方法。
11. 前記管理サーバは、
    過去に発生した前記仮想ボリュームが使用不可となる障害時の前記プールの物理的な構成情報に基づいて、前記基準値を設定する
    ことを特徴とする請求項８に記載のプール増設方法。
12. 前記ストレージ装置は、接続された外部ストレージ装置における論理ボリュームを前記プールに含んでおり、
    前記基準値は、前記外部ストレージ装置の物理的な構成情報に関する情報を含んでいる
    ことを特徴とする請求項８に記載のプール増設方法。
13. 前記可用性の評価値は、前記ストレージ装置と前記外部ストレージ装置とのデータの入出力量に基づくパラメータを含む
    ことを特徴とする請求項１２に記載のプール増設方法。
14. 前記管理サーバは、
    前記仮想ボリュームの総容量分までデータを格納した場合の前記プールに関する物理的な構成情報を予測し、その予測した物理的な構成情報を用いて前記可用性の評価値を導出し、その導出した前記可用性の評価値と前記基準値とを比較し、当該可用性の評価値が前記基準値を超えたと判断した場合に、前記プールの増設が必要であると判断し、前記ストレージ装置に前記プールの増設を指示する
    ことを特徴とする請求項８に記載のプール増設方法。
15. 複数の記憶デバイスと、通信経路を介して接続されるホスト計算機からの要求に応じて前記記憶デバイスに対するデータの入出力制御を行うコントローラと、を備えるストレージ装置、および、前記ストレージ装置を管理する管理サーバ、を有する計算機システムであって、
    前記ストレージ装置は、
    前記ホスト計算機がアクセスする仮想ボリュームと、
    前記仮想ボリュームに割り当てられ、前記複数の記憶デバイスと対応付けられた仮想的な記憶領域である論理ボリュームの集合であるプールと、をそれぞれ１つ以上備えており、
    前記管理サーバは、
    前記コントローラから取得した前記プールに関する物理的な構成情報を用いて導出した可用性の評価値と、予め記憶している基準値と、を比較し、当該可用性の評価値が前記基準値を超えたと判断した場合に、前記プールの増設が必要であると判断し、前記ストレージ装置に前記プールの増設を指示し、
    前記可用性の評価値は、前記プールに関する物理的な構成要素の数に基づくパラメータを含み、前記数が大きくなるほど大きな値となるものである
    ことを特徴とする計算機システム。
16. 前記パラメータは、前記ストレージ装置のコントローラにおける前記複数の記憶デバイスとの間のデータ通信を制御するためのディスクアダプタ、前記ディスクアダプタにおける通信用のポート、および、前記論理ボリューム、の少なくともいずれかの数である
    ことを特徴とする請求項１５に記載の計算機システム。
17. 前記パラメータが複数あり、
    前記管理サーバは、
    当該パラメータのいずれか１つでもその対応する前記基準値を超えた場合、前記プールの増設が必要であると判断する
    ことを特徴とする請求項１６に記載の計算機システム。

Images