計算機システム及び計算機システムの管理方法
【課題】仮想的な論理ボリュームに実記憶領域を提供するプールの容量が不足した場合、適切な対処法を選択して実行する。
【解決手段】管理計算機は、各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定する。管理計算機は、所定プールが検出された場合、所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、仮想的な論理ボリュームのデータを所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、選択された方法に従って、所定プールのプールサイズを拡張させる。
【解決手段】管理計算機は、各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定する。管理計算機は、所定プールが検出された場合、所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、仮想的な論理ボリュームのデータを所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、選択された方法に従って、所定プールのプールサイズを拡張させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システム及び計算機システムの管理方法に関する。
【背景技術】
【０００２】
大型のストレージはストレージサブシステムとも呼ばれ、高速かつ大容量なデータ保管を可能とするだけでなく、高度なデータ管理機能を有する。ストレージ内にはハードディスクドライブなどの物理的な記憶装置が複数搭載される。それら記憶装置内の記憶領域を用いて、論理的な記憶領域である論理ボリュームが構成される。ストレージ装置は、論理ボリュームをホスト計算機に提供する。ホスト計算機は、論理ボリュームに対して、データを読み書きする。
【０００３】
近年、論理ボリュームの容量効率を向上させるシンプロビジョニング技術が提案されている。シンプロビジョニング技術は、従来の論理ボリュームに代わる仮想的な論理ボリューム（以下、仮想ボリューム）をホストに提供する。
【０００４】
従来の論理ボリュームは、ボリューム作成時に指定されたサイズの、物理的な記憶領域（実記憶領域）を必要とする。これに対し、仮想ボリュームは、実際にデータの書き込みが発生した時点で、そのデータを記憶するための実記憶領域をプールから取り出して、仮想ボリュームに割り当てるようになっている。シンプロビジョニング技術を用いると、実際にデータの書き込みが発生するまでの間は、仮想ボリュームに実記憶領域を割り当てる必要がないため、実記憶領域を節約することができる。
【０００５】
しかし、仮想ボリュームへのデータ書き込み状況によっては、仮想ボリュームに書き込まれるデータの量が、仮想ボリュームに割り当て可能な実記憶領域のサイズを超えてしまう場合が考えられる。仮想ボリュームに割り当てるべき実記憶領域が不足すると、エラーが発生しうる。
【０００６】
そのため、シンプロビジョニング技術を用いる場合は、仮想ボリュームに割り当て可能な実記憶領域の量（実使用量）を正確に管理することが好ましい。
【０００７】
第１の従来技術では、プールに容量不足が発生した場合、使用可能なボリュームをプールに追加して、プールのサイズを拡張する（特許文献１）。第２の従来技術では、プールを利用している仮想ボリュームを他のプールに移行させることにより、移行元のプールの容量不足を解消する（特許文献２）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−１９３５７３号公報
【特許文献１】特開２０１０−８６４２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
プールのサイズが不足した場合の対処法として、前記の二通りの方法が知られている。しかし、計算機システムの構成は複雑であり、かつ、状況は変化するため、計算機システムの管理者であるユーザは、どの対処法を選択すべきなのか判断に迷う。
【００１０】
複数の異種ストレージが混在するヘテロジニアスな計算機システムでは、考慮すべき要素が多くなるため、適切な対処法の選択がより難しい。特に、経験が少なく、知識の乏しいユーザの場合は、頼るべき基準を持たないため、対象法の選択は一層困難となる。
【００１１】
そこで、本発明の目的は、複数の方法の中から所定の選択基準に基づいて少なくとも一つの方法を選択して実行することにより、管理者の負担を軽減し、プールサイズを拡張できるようにした 計算機システム及び計算機システムの管理方法を提供することにある。
【課題を解決するための手段】
【００１２】
上記課題を解決すべく、本発明に従う計算機システムは、少なくとも一つの仮想的な論理ボリュームを生成する複数の記憶制御装置と、仮想的な論理ボリュームを使用する少なくとも一つのホスト計算機と、各記憶制御装置とホスト計算機とを管理するための少なくとも一つの管理計算機とを含む計算機システムであって、各記憶制御装置は、ホスト計算機からのライトアクセスに応じて、プール内の実ボリュームの有する実記憶領域を仮想的な論理ボリュームに割り当て、ホスト計算機から受信するライトデータを、割り当てられた実記憶領域に記憶させるようになっており、管理計算機は、マイクロプロセッサと、マイクロプロセッサにより読み込まれて実行される所定のコンピュータプログラムを記憶するメモリと、各記憶制御装置及びホスト計算機と通信するための通信インターフェース部とを備えており、マイクロプロセッサは、所定のコンピュータプログラムを読み込んで実行することにより、各プールの使用状態を取得し、取得された各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定し、所定プールが検出された場合は、（Ａ）所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、（Ｂ）仮想的な論理ボリュームのデータを所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、選択された方法に従って、所定プールのプールサイズを拡張させる。
【００１３】
マイクロプロセッサは、ボリューム追加方法とデータ移動方法のいずれかを選択する場合に、仮想的な論理ボリュームを使用するアプリケーションプログラムの稼働状況を考慮して、所定時間内に所定プールのプールサイズの拡張が完了するか否かを判定することもできる。
【００１４】
ボリューム追加方法は、各記憶制御装置のうち所定プールの属する所定の記憶制御装置が有する、未使用の第１の実ボリュームを所定プールに追加させる、第１のボリューム追加方法を含ませてもよい。
【００１５】
マイクロプロセッサは、第１のボリューム追加方法を実行する場合、所定の選択基準として、第１の実ボリュームのボリュームサイズと、所定プールに予め設定されている属性ラベルと第１の実ボリュームに予め設定されている属性ラベルとの適合状態と、所定プールに第１の実ボリュームを追加した場合の所定プールの応答性能とを考慮してもよい。
【００１６】
ボリューム追加方法には、各記憶制御装置のうち所定の記憶制御装置以外の他の記憶制御装置が有する、未使用の第２の実ボリュームを所定の記憶制御装置に接続することにより、第２の未使用の実ボリュームを所定プールに追加させる、第２のボリューム追加方法を含めてもよい。
【００１７】
ボリューム追加方法には、各記憶制御装置のうち所定の記憶制御装置の有する第１の他のプールに設けられている第３の実ボリュームを取り外し、その取り外された第３の実ボリュームを未使用の実ボリュームとして所定プールに追加させる、第３のボリューム追加方法を含めてもよい。
【００１８】
ボリューム追加方法には、所定の記憶制御装置以外の他の記憶制御装置が有する、第２の他のプールに設けられている第４の実ボリュームを取り外し、その取り外された第４の実ボリュームを未使用の実ボリュームとして所定プールに追加させる、第４のボリューム追加方法を含めてもよい。
【００１９】
データ移動方法には、ホスト計算機が仮想的な論理ボリュームのデータを所定のプール以外の他のプールに移動させる、第１のデータ移動方法を含めてもよい。
【００２０】
データ移動方法には、所定の記憶制御装置が仮想的な論理ボリュームのデータを所定のプール以外の他のプールに移動させる、第２データ移動方法を含めてもよい。
【００２１】
本発明は、コンピュータプログラムまたはコンピュータプログラムを記録する記録媒体として把握することもできる。さらに、本発明は、上述した各観点の組合せに限らず、それら以外の組合せを含むことができる。
【図面の簡単な説明】
【００２２】
【図１】図１は、本実施例に係る計算機システムの全体構成図。
【図２】図２は、プールサイズの拡張方法を模式的に示す図。
【図３】図３は、ホストが使用する仮想ボリュームの情報を示す図。
【図４】図４は、ストレージの情報を示す図。
【図５】図５は、プールの情報を示す図。
【図６】図６は、未使用ボリュームの情報を示す図。
【図７】図７は、管理ポリシーの情報を示す図。
【図８】図８は、プールの使用率を監視する処理のフローチャート。
【図９】図９は、プールサイズを拡張する処理のフローチャート。
【図１０】図１０は、自ストレージ内でプールサイズを拡張する処理を示すフローチャート。
【図１１】図１１は、仮想ボリュームを移動させる処理のフローチャート。
【図１２】図１２は、他ストレージを用いてプールサイズを拡張する処理を示すフローチャート。
【図１３】図１３は、他のプールで使用されているボリュームを流用して、プールサイズを拡張する処理を示すフローチャート。
【図１４】図１４は、仮想ボリュームにプール内の実記憶領域を割り当てる様子と、ホスト計算機が仮想ボリュームを移動させた場合に得られる効果とを示す模式図。
【発明を実施するための形態】
【００２３】
以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態では、後述のように、プールのサイズが不足した場合に、その容量不足を解消するための対処法を選択する方法を提示する。
【００２４】
対処法は、例えば、以下の観点に基づいて選択してもよい。
【００２５】
（観点１）異種のホスト計算機及び異種のストレージが混在する環境を考慮
計算機システムに含まれる各ホスト計算機及び各ストレージが有する、対処機能（例えば、プールを拡張する機能、および、仮想ボリュームを移動させる機能）は、同一であるとは限らない。従って、対処機能の有無と前提条件とを管理計算機が把握した上で、対処法を選択する。
【００２６】
（観点２）対処の緊急性と対処に要する時間とに関する考慮
所要時間の長い対処法を選択して実施した場合に起こり得るリスクを低減する。リスクとは、プールサイズの拡張が間に合わず、プールサイズが枯渇することである。例えば、アプリケーションプログラムの稼働していない期間中に、仮想ボリュームを他のプールに移動させる、という対処法を選択する場合には、注意が必要であろう。仮想ボリュームの移動が完了する前にアプリケーションプログラムが稼働を開始した場合、プールサイズが枯渇する可能性があるかも知れない。一方、所要時間が短ければ短いほど良い対処法である、とは必ずしも言えない。必要以上に所要時間の短い対処法を選択すると、対処法を選択する自由度が低下し、使い勝手に影響を与えるかも知れない。
【００２７】
（観点３）プール使用率の適正化に関する考慮
ある対策を実施しても、プールの使用率が高いままでは、容量不足は解消しない。つまり、プールの使用率低下に有効な対処法を実施する必要がある。しかし、プール使用率を必要以上に低下させる運用は、記憶サイズの浪費を招くであろう。
【００２８】
（観点４）ボリュームおよびプールの属性に関する考慮
仮想ボリューム、実ボリューム（論理ボリューム）、プールには、それぞれの構成または目的等に応じた属性（例えば、性能、価格、所属部門等）を有する。それらの属性を無視して、仮想ボリュームを他のプールに移動させたり、プールに実ボリュームを自由に追加したりすると、使い勝手等が低下するかも知れない。例えば、高速応答を要求される仮想ボリュームを応答性能の低いプールに移動させたり、高い信頼性を要求される仮想ボリュームを信頼性の低いプールに移動させるような場合である。さらに、例えば、高速な論理ボリュームから構成されるプールに低速な論理ボリュームを追加すると、そのプールの応答性能が低下する。そこで、仮想ボリューム、論理ボリューム及びプールに、属性ラベル（後述の実施例では「区分」と呼ぶ）を設定し、属性ラベルが適合するように、対処法を選択する。
【００２９】
（観点５）対処法の実行前後の性能変化に関する考慮
対処法を実行すると、仮想ボリュームの性能、または、プールの性能が変化する。対処法の実行前後で、仮想ボリュームの性能またはプールの性能が許容範囲以下に低下しないように、対処法の選択時に考慮する。
【実施例１】
【００３０】
以下、図面に従い、発明を実施するための形態について述べる。図１は、本実施例に係る計算機システムの全体構成図である。計算機システムは、例えば、少なくとも一つの管理端末１０と、少なくとも一つの管理計算機２０と、複数のストレージ３０と、少なくとも一つのホスト計算機４０と、管理用ネットワーク５１と、ストレージネットワーク５２とを含む。
【００３１】
管理端末１０と、管理計算機２０と、各ストレージ３０及びホスト計算機４０は、管理用ネットワーク５１によって双方向通信可能に結ばれている。さらに、管理計算機２０と、各ストレージ３０及びホスト計算機４０は、ストレージネットワーク５２によって双方向通信可能に接続されている。
【００３２】
管理用ネットワーク５１及びストレージネットワーク５２は通信回線であり、各情報処理装置間でデータを送受信するための通信経路である。なお、図１では、管理用ネットワーク５１とストレージネットワーク５２を別の通信回線として示すが、両方のネットワーク５１，５２を共通の通信回線として構成してもよい。
【００３３】
管理端末１０は、情報処理装置であり、例えば、メモリ１１と、マイクロプロセッサ（図中、ＣＰＵ）１２と、ディスプレイ装置１３と、キーボード１４と、マウス１５と、ホストインターフェース（以下、インターフェースをＩ／Ｆと表示）１６とを備える。
【００３４】
メモリ１１は、データ及びコンピュータプログラムを記憶する。マイクロプロセッサ（以下、プロセッサ）１２は、メモリ１１からコンピュータプログラムを読み込んで実行する。ディスプレイ装置１３は、データ等を表示する。キーボード１４は、ユーザからの文字による入力を受け付ける。マウス１５は、ディスプレイ装置に表示された画面上の任意の地点を指し示すために使用される。ホストＩ／Ｆ１６は、管理用ネットワーク５１を介して、管理計算機２０とデータを送受信する。なお、ユーザインターフェースとしては、ディスプレイ装置、キーボード、マウスに限らず、例えば、音声による指示装置、脳波による指示装置等を用いることもできる。
【００３５】
メモリ１１には、コンソールプログラム１１１が格納されている。プロセッサ１２がコンソールプログラム１１１を実行することにより、ホストＩ／Ｆ１６及び管理用ネットワーク５１を介して管理計算機２０とデータを交換する機能と、ディスプレイ装置１３に情報を表示させる機能と、キーボード１４及びマウス１５を介してユーザからの入力を受け付ける機能とが実現される。
【００３６】
管理端末１０は、ストレージの運用及び管理に携わるユーザ（ストレージ管理者）が、ストレージ３０を運用したり、管理したりするための窓口として用いられる。
【００３７】
管理計算機２０は、情報処理装置であり、例えば、メモリ２１と、プロセッサ２２と、ＳＡＮ Ｉ／Ｆ２３と、ホストＩ／Ｆ２４とを備える。
【００３８】
メモリ２１は、データやコンピュータプログラムを記憶する。プロセッサ２２は、メモリ２１からコンピュータプログラムを読み込み、実行する。これにより、後述する各機能が実現される。ＳＡＮ Ｉ／Ｆ２３は、ストレージネットワーク５２を経由して各ストレージ３０に操作指示または情報照会等を行なうための回路である。ホストＩ／Ｆ２４は、管理用ネットワーク５１を介して、他の情報処理装置１０，３０，４０とデータ通信するための回路である。
【００３９】
管理サーバプログラム２１１は、各ストレージ３０を管理するためのコンピュータプログラムであり、メモリ２１に格納されている。ホスト−ボリューム情報２１２は、ホスト計算機４０上で使用される仮想ボリュームの構成及び利用状況等を管理するための情報である。ストレージ情報２１３は、各ストレージ３０が搭載している機能を管理するための情報である。プール情報２１４は、各プールの構成及び使用状況等を管理するための情報である。未使用ボリューム情報２１５は、各ストレージ３０内の未使用ボリュームに関する情報である。管理ポリシー情報２１６は、管理サーバプログラム２１１の動作を定義する情報である。
【００４０】
ホスト−ボリューム情報２１２、ストレージ情報２１３、プール情報２１４、未使用ボリューム情報２１５及び管理ポリシー情報２１６は、メモリ２１に格納される。それら情報２１２，２１３，２１４，２１５，２１６の詳細については後述する。
【００４１】
なお、図１には、管理計算機２０とホスト計算機４０とを別々に構成する場合を示しているが、これに代えて、ホスト計算機４０に管理計算機の機能を実現させてもよい。例えば、複数のホスト計算機４０のうち少なくとも一つのホスト計算機４０に、管理計算機２０の有するコンピュータプログラム２１１及び各種管理情報２１２−２１６を設ける構成としてもよい。
【００４２】
「記憶制御装置」としての各ストレージ３０は、情報を記憶するための装置である。各ストレージ３０は、例えば、ストレージコントローラ３１と、ディスクユニット３２とを備える。
【００４３】
ストレージコントローラ３１は、ホストＩ／Ｆ３１１と、ＳＡＮ Ｉ／Ｆ３１２と、マイクロプロセッサ３１３と、メモリ３１４と、ディスクコントローラ３１５を備える。ホスト Ｉ／Ｆ３１１は、管理用ネットワーク５１に接続するための回路である。ＳＡＮ Ｉ／Ｆ３１２は、ストレージネットワーク５２に接続するための回路である。
【００４４】
メモリ３１４には、例えば、入出力処理プログラム（図中、Ｉ／Ｏプログラム）３１４１と、ボリューム移行プログラム（図中、マイグレーションプログラム）３１４２と、シンプロビジョニングプログラム３１４３とが記憶される。マイクロプロセッサ３１３は、それらコンピュータプログラム３１４１，３１４２，３１４３を読み込んで実行する。ディスクコントローラ３１５は、ディスクドライブ３２１に対するデータの読み書きを制御する。
【００４５】
ディスクユニット３２は、複数のディスクドライブ３２１を備える。各ディスクドライブ３２１がそれぞれ有する物理的記憶領域をグループ化し、そのグループ化された物理的記憶領域に複数の論理的記憶領域を設定することができる。その論理的な記憶領域を論理ボリューム３２２と呼ぶ。
【００４６】
ディスクドライブとしては、例えば、ハードディスクドライブ、半導体メモリドライブ、光ディスクドライブ、光磁気ディスクドライブ等のデータを読み書き可能な種々のデバイスを利用可能である。
【００４７】
ハードディスクドライブを用いる場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスク、ＳＡＴＡディスク、ＡＴＡ（AT Attachment）ディスク、ＳＡＳ（Serial Attached SCSI）ディスク等を用いることができる。また、例えば、フラッシュメモリ、ＦｅＲＡＭ（Ferroelectric Random Access Memory）、ＭＲＡＭ（MagnetoresistiveRandom Access
Memory）、相変化メモリ（Ovonic Unified Memory）、ＲＲＡＭ（Resistance RAM）」等の種々の記憶装置を用いることもできる。
【００４８】
入出力処理プログラム３１４１は、管理計算機２０からの要求に応じて論理ボリュームを定義する。さらに、入出力処理プログラム３１４１は、ホスト計算機４０からの求めに応じて、論理ボリューム及び仮想ボリュームに対してデータを読み書きする。
【００４９】
ボリューム移行プログラム３１４２は、管理計算機２０からの指示に応じて、仮想ボリュームを他のプールに移行させる。仮想ボリュームとプールに関する説明は、図２で後述する。
【００５０】
シンプロビジョニングプログラム３１４３は、例えば、プールの構成管理、プールの稼動管理、仮想ボリュームの構成管理、仮想ボリュームの稼動管理、データ読み書き機能等を提供する。
【００５１】
ホスト計算機４０は、情報処理装置であり、例えば、ＳＡＮ Ｉ／Ｆ４１と、ホストＩ／Ｆ４２と、プロセッサ４３と、メモリ４０を備える。
【００５２】
ＳＡＮ Ｉ／Ｆ４１は、ストレージネットワーク５２を経由して、各ストレージ３０とデータ通信するための回路である。ホストＩ／Ｆ４２は、管理用ネットワーク５１を介して、管理計算機２０とデータ通信するための回路である。
【００５３】
メモリ４４には、例えば、管理エージェントプログラム４４１と、マイグレーションプログラム（ボリューム移行プログラムとも呼ぶ）４４２と、アプリケーションプログラム４４３と、ＯＳ（オペレーティングシステム）４４４とが記憶されている。プロセッサ４３は、各コンピュータプログラム４４１，４４２，４４３を読み込んで実行する。
【００５４】
管理エージェントプログラム４４１は、管理サーバプログラム２１１からの指示に基づいて、ボリューム移行プログラム４４２を実行させる。
【００５５】
ボリューム移行プログラム４４２は、論理ボリュームまたは仮想ボリュームのデータを、他の論理ボリュームまたは他の仮想ボリュームに移すプログラムである。
【００５６】
アプリケーションプログラム４４３は、ホスト計算機４０で業務処理を実行するためのプログラムである。
【００５７】
ＯＳ４４４は、管理エージェントプログラム４４１及びアプリケーションプログラム４４３の実行基盤となる基本ソフトウェアである。
【００５８】
図２は、シンプロビジョニング技術を用いた情報処理システムの論理的な構成、及び、プール容量不足時の対処法を示す概念図である。
【００５９】
まず最初に、シンプロビジョニング技術におけるプールと仮想ボリュームとについて説明する。ストレージ３０（１）は「ＤＫＣ−Ａ」という識別名で特定されるストレージである。ストレージ３０（１）の内部には、「ＰＯＯＬ−Ａ」という識別名で特定されるプール６１１が含まれる。
【００６０】
プール６１１は、複数の論理ボリューム６２１，６２２，６２３を含む。プール６１１には、「ＶＶＯＬ−Ａ」という識別名で特定される仮想ボリューム６３１と、「ＶＶＯＬ−Ｂ」という識別名で特定される仮想ボリューム６３２とが所属している。
【００６１】
仮想ボリューム６３１は、ホスト計算機４０（１）上において、「ＶＯＬ−Ａ」という識別名で特定されるボリューム６５１となっている。ボリューム６５１は、「ＡＰ−Ａ」という識別名で特定されるアプリケーションプログラム４４３（１）から利用される。このような構成において、アプリケーションプログラム４４３（１）がボリューム６５１にデータを書き込むと、以下の処理が行われる。
【００６２】
ボリューム６５１に対する書き込み要求を受けたＯＳ４４４は、ストレージ３０（１）に、ボリューム６５１に対応する仮想ボリューム６３１への書き込み要求を発行する。その書き込み要求を受けたストレージ３０（１）内の入出力処理プログラム３１４１は、シンプロビジョニングプログラム３１４３に、書き込み要求があった旨を通知する。シンプロビジョニングプログラム３１４３は、その通知を受けると、仮想ボリューム６３１の全記憶領域のうち書き込み対象の記憶領域（仮想ページ）に、プール６１１内の記憶領域（実ページまたはチャンク）を割り当て済みか否かを判定する。
【００６３】
シンプロビジョニングプログラム３１４３は、書き込み対象の仮想ページに実ページが未割り当てであると判定した場合、プール６１１を構成する各論理ボリュームの有する実記憶領域の中から実ページを選択して、書き込み対象の仮想ページに割り当てる。
、仮想ページに割り当てられた実ページには、アプリケーションプログラム４４３（１）からのデータが書き込まれる。書き込み対象の仮想ページに実ページが既に割り当てられている場合、その割り当て済みの実ページに、アプリケーションプログラム４４３（１）から書き込まれるデータを保存する。
【００６４】
以上の処理は、プール６１１を共有する仮想ボリューム６３２と、それを利用するボリューム６５２、さらには、アプリケーションプログラム４４３（２）についても同様に行われる。仮想ボリューム６３１に割り当てられた実ページの総数と仮想ボリューム６３２に割り当てられてた実ページの総数との合計に対応する量の記憶領域（実記憶領域）が、プール６１１から使用されることになる。
【００６５】
次に、プールサイズが不足した場合の対処法について述べる。例えば、ストレージ３０（２）内のプール６１２が容量不足になった場合の対処法としては、以下に述べる五つを挙げることができる。
【００６６】
第一の対処法は、同一ストレージ３０（２）内の未使用ボリューム６４２を使用してプール６１２を拡張をすることである（図２の矢印６９１）。ストレージ３０（２）内に未使用ボリューム６４２が存在する場合、そのボリューム６４２をプール６１２に追加することにより、プール６１２のサイズを拡張することができる。
【００６７】
第二の対処法は、他のストレージ３０（４）内の未使用ボリューム６４３を使用してプール６１２を拡張することである（図２の矢印６９２）。第二の対処法が利用できる条件は、他のストレージ３０（４）に未使用ボリューム６４３が存在すること、及び、他のストレージ３０（４）内のボリュームにストレージ３０（２）がアクセスする機能を有することである。
【００６８】
一方のストレージ３０（２）が他方のストレージ３０（４）内のボリューム６４３にアクセスする機能を、外部接続機能と呼ぶことができる。一方のストレージ３０（２）から見ると、他方のストレージ３０（４）は一方のストレージ３０（２）の外部に存在する外部ストレージである。他方のストレージ３０（４）内のボリューム６４３は、一方のストレージ３０（１）の外部に存在する外部ボリュームである。一方のストレージ３０（１）内に外部ボリューム６４３と接続するための仮想的なボリューム６２５を設ける。その接続用のボリューム６２５は、外部接続ボリュームと呼ぶことができる。外部接続ボリューム６２５をプール６１２に追加して、プール６１２のサイズを拡張できる。
【００６９】
外部ボリューム６４３と外部接続ボリューム６２５とを接続する場合は、外部ボリューム６４３と外部接続ボリューム６２５との接続関係を定義する接続テーブルを設ける。接続テーブルとは、簡単に言えば、外部接続ボリューム６２５の記憶空間と外部ボリューム６４３の記憶空間との対応関係を示すマッピングテーブルである。
【００７０】
一方のストレージ３０（２）は、ホスト計算機からコマンドを受信すると、マッピングテーブルを用いて、そのコマンドを他方のストレージ３０（４）に送信するためのコマンドに変換する。一方のストレージ３０（２）は、変換されたコマンドを他方のストレージ３０（４）に送信する。一方のストレージ３０（２）は、他方のストレージ３０（４）からの応答に基づいて、ホスト計算機に応答する。
【００７１】
第三の対処法は、他のストレージ３０（４）内のプール６１４を構成する論理ボリューム６２７を流用してプール６１２拡張することである（図２の矢印６９３）。第三の対処法が利用できる条件は、第二の対処法の条件に加え、他ストレージ３０（４）内のプール６１４から論理ボリューム６２７を取り外すことが可能であることである。
【００７２】
第四の対処法は、ストレージ３０（２）の機能を利用して他のストレージ３０（３）内のプール６１３に仮想ボリューム６３４を移行させることである（図２の矢印６９４）。第四の対処法が利用できる条件は、ストレージ３０（２）が他ストレージ３０（３）に仮想ボリューム６３４を移行させる機能を有すること、及び、仮想ボリューム６３４を収容するだけの容量的な余裕が移行先プール６１３にあることである。仮想ボリューム６３４を他のプール６１３に移行させるとは、仮想ボリューム６３４を他のプール６１３の記憶領域に対応付けるという意味である。
【００７３】
なお、仮想ボリューム６３４を他のプール６９３に移行させる機能を実行するにあたって、アプリケーションプログラム４４３（３）が稼働していないこと（非稼働中）が前提条件となる場合がある。その場合は、第四の対処法を利用する条件に、その前提条件も含まれる。
【００７４】
第五の対処法は、ホスト計算機４０（２）の機能を利用して他のストレージ３０（１）内のプール６１１に仮想ボリュームを移行させることである（図２の矢印６９５）。第五の対処法が利用できる条件は、ホスト計算機４０（２）がストレージ３０（２）から他ストレージ３０（３）に、仮想ボリューム６３３（移行後の仮想ボリューム６３２）を移行させる機能を有すること、及び、仮想ボリューム６３３を収容するだけの容量的な余裕が移行先プール６１１にあることである。
【００７５】
なお、第四の対処法と同様に、仮想ボリューム６３３を他のプール６１１に移行させる機能の実行に際して、アプリケーションプログラム４４３（２）の停止（非稼動）を前提条件とする場合は、その前提条件も満たす必要がある。
【００７６】
なお、ストレージ３０（２）内に複数のプールが存在する場合、ストレージ３０（２）内の一方のプールからストレージ３０（２）内の他のプールに、仮想ボリュームを移行させることもできる。さらに、ストレージ３０（２）内の他のプールを構成する論理ボリュームを取り外して、一方のプールに追加することもできる。
【００７７】
次に、管理サーバプログラム２１１により使用される各種情報と、管理サーバプログラム２１１により実行される処理について説明する。以下、選択された対処法を管理サーバプログラム２１１が自動的に実行する場合を説明する。これに代えて、管理サーバプログラム２１１は、選択された対処法をユーザに提示するに止める構成でもよい。ユーザが、提示された対処法を承認した場合、その対処法が実行される。
【００７８】
図３は、管理サーバプログラム２１１により使用されるホスト−ボリューム情報２１２のデータ構造及びデータ例を示す。ホスト−ボリューム情報２１２は、仮想ボリューム単位に情報を保持する。その属性情報は、仮想ボリューム番号（図中、ＶＶＯＬ＃）２１２１、アプリケーションプログラム番号（図中、ＡＰ＃）２１２２、所属プール番号（図中、ＰＯＯＬ番号）２１２３、使用サイズ２１２４、アプリケーションプログラム稼動期間２１２５、ボリューム移行機能（図中、マイグレーション機能）２１２６、及び、コスト区分２１２７である。
【００７９】
以下の説明において、名前、識別子、識別情報、番号は、それぞれ対象物を他の対象物と区別するために使用される情報であり、相互に変換可能である。例えば、仮想ボリューム番号は仮想ボリューム識別子または仮想ボリューム名と呼び変えることができる。さらに、各テーブルの構成は図示の例に限られない。例えば、複数のテーブルをリンクさせることにより、本実施例で必要な情報を管理することもできる。
【００８０】
次に、ホスト−ボリューム情報２１２の各属性を説明する。仮想ボリューム番号２１２１は、仮想ボリュームの識別名を保持する。アプリケーションプログラム番号２１２２は、仮想ボリュームを使用するアプリケーションプログラム４４３の識別名を保持する。所属プール番号２１２３は、仮想ボリュームが所属するプールの識別名を保持する。使用サイズ２１２４は、仮想ボリュームの全ボリュームサイズのうち実際に使用されているサイズ、言い換えるとプール内のページが割り当てられているサイズを保持する。
【００８１】
アプリケーションプログラム稼動期間２１２５は、仮想ボリュームを使用するアプリケーションプログラム４４３の稼動期間を保持する。ボリューム移行機能２１２６は、仮想ボリュームを使用するホスト計算機４０上でボリューム移行が可能か否かを示す。可能な場合は、アプリケーションプログラム４４３の稼動中に移行できるか否かも示す。図３の例で「Ｉ／Ｏ無停止」となっているのは、アプリケーションプログラム４４３の稼動中に、仮想ボリュームの移行が可能なことを示している。
【００８２】
コスト区分２１２７は、仮想ボリュームの所属するプールのコスト区分を示す。コスト区分は識別名である。コスト区分は、プールを構成する各論理ボリュームのグレードまたは所属先の部門を区別するために設定される。
【００８３】
グレードは、例えば、論理ボリュームの価格帯などによって分けられる。例えば「Ａ」は高価格帯のボリュームを示し、「Ｂ」は中価格帯のボリュームを示し、「Ｃ」は低価格帯のボリュームを示す。コスト区分「Ａ」の設定されているプールは、高価格帯のボリュームのみから構成される。コスト区分「Ａ，Ｂ」の設定されているプールは、高価格帯ボリュームまたは／及び中価格帯ボリュームから構成される。高価格帯ボリュームを高信頼性ボリュームと、中価格帯ボリュームを中信頼性ボリュームと、低価格帯ボリュームを低信頼性ボリュームと、呼び変えることもできる。高信頼性ボリュームは、高信頼性のディスクドライブから構成される。中信頼性ボリュームは、中信頼性のディスクドライブから構成される。低信頼性ボリュームは、低信頼性のディスクドライブから構成される。
【００８４】
所属先の部門は、プールを構成する各論理ボリュームを部門別に割り当てる場合に使用される。部門Ａには「Ａ」、部門Ｂには「Ｂ」、部門Ｃには「Ｃ」と設定される。コスト区分は、仮想ボリューム及びプールの、性質または位置付けが変化するのを防止するために使用される。
【００８５】
コスト区分が適合しているか否かを判定することにより、例えば、高価格帯の各論理ボリュームから構成されるプールに対応付けられるべき重要な仮想ボリュームが、低価格帯の各論理ボリュームから構成されるプールに移行されてしまうのを防止できる。または、部門Ａで使用される仮想ボリュームが、部門Ｂの論理ボリュームで構成されているプールに移行されたりするのを防止できる。
【００８６】
コスト区分２１４４は、上述のように複数の区分を含んでも良い。複数区分が設定されている場合は、どちらも適用可能であることを示す。なお、ホスト−ボリューム情報２１２は、ストレージ３０内のシンプロビジョニングプログラム３１４３と、ホスト計算機４０上のアプリケーションプログラム４４３と、ボリューム移行プログラム４４２等から取得できる情報、及び、管理者からの入力される情報に基づいて作成できる。
【００８７】
図４は、管理サーバプログラム２１１により使用されるストレージ情報２１３のデータ構造及びデータ例を示す。ストレージ情報２１３は、ストレージ３０単位に情報を保持する。その属性情報は、ストレージ番号（図中、ストレージ＃）２１３１、ボリューム移行機能（図中、マイグレーション機能）２１３２、他ストレージ内のボリュームへのアクセス機能（図中、外部接続機能）２１３３である。
【００８８】
ストレージ番号２１３１は、ストレージ３０の識別名を保持する。ボリューム移行機能２１３２は、ストレージ３０がボリューム移行機能を持つか否かを保持する。移行機能を持つ場合は、アプリケーションプログラム４４３が停止中の場合のみ移行可能か否かも併せて示す。例えば、図４の例で「Ｉ／Ｏ停止」とあるのは、アプリケーションプログラム４４３が停止されており、Ｉ／Ｏ要求が発生しない場合のみ、ボリュームを移行可能であることを示している。なお、ストレージ情報２１３は、ストレージ３０内の入出力プログラム３１４１及びボリューム移行プログラム３１４２などから取得できる情報等に基づいて作成することができる。
【００８９】
図５は、管理サーバプログラム２１１により使用されるプール情報２１４のデータ構造及びデータ例を示す。プール情報２１４は、プール単位に情報を保持する。その属性情報は、プール番号（図中、プール＃）２１４１、プールサイズ２１４２、使用率２１４３、コスト区分２１４４である。
【００９０】
プール番号２１４１は、プールの識別名を保持する。プールサイズ２１４２は、プールの総サイズ、即ち、仮想ボリュームに割当可能な実ページの総サイズを保持する。使用率２１４３は、プールサイズ２１４２に占める、仮想ボリュームに割当済みのページサイズの割合を示す。全プールサイズを仮想ボリュームに割り当てた場合、使用率は１００%となる。
【００９１】
コスト区分２１４４は、ホスト−ボリューム情報２１２におけるコスト区分２１２７と同じ目的で付与されている。コスト区分２１４４は、プールを構成する論理ボリュームを区別するための識別名である。なお、プール情報２１４は、ストレージ３０内のシンプロビジョニングプログラム３１４３、及び、管理者から直接入力される情報等に基づいて作成すればよい。
【００９２】
図６は、管理サーバプログラム２１１により使用される未使用ボリューム情報２１５のデータ構造及びデータ列を示す。未使用ボリューム情報２１５は、未使用のボリューム単位に情報を保持する。その属性情報は、未使用ボリューム番号２１５１、ストレージ番号２１５２、サイズ２１５３、コスト区分２１５４である。
【００９３】
未使用ボリューム番号２１５１は、未使用ボリュームの識別名を保持する。ストレージ番号２１５２は、未使用ボリュームが存在するストレージの識別名を保持する。サイズ２１５３は、未使用ボリュームの記憶サイズを保持する。コスト区分２１５４は、未使用ボリュームのコスト区分を示す識別名を保持する。コスト区分２１５４は、複数の識別名を保持しても良い。なお、未使用ボリューム情報２１５は、ストレージ３０内のシンプロビジョニングプログラム３１４３と、ディスクコントローラ３１５から取得できる情報及び管理者から直接入力される情報等に基づいて作成すればよい。
【００９４】
図７は、管理サーバプログラム２１１により使用される管理ポリシー情報２１６のデータ構造及びデータ列を示す。管理ポリシー情報２１６は、管理ポリシー単位に情報を保持する。管理ポリシーとは、管理サーバプログラム２１１が各種管理操作を実行する上での指針を示す情報である。管理ポリシーは、例えば、プールサイズが不足した場合の対応方針を示す。
【００９５】
管理ポリシー情報２１６の属性は、ポリシー番号２１６１、適用対象２１６２、起動条件２１６３、アクション２１６４、成功条件２１６５である。ポリシー番号２１６１は、ポリシーの識別名を保持する。適用対象２１６２は、ポリシーの適用対象を保持する。図７の例で「全プール」となっている場合、全てのプールに同じポリシーを適用することを示している。適用対象として特定のプールの識別名が指定されている場合、ポリシーは、その特定されたプールのみに適用される。
【００９６】
起動条件２１６３は、特定のアクションを実行するきっかけとなる条件を保持する。図７の例では、起動条件を、プール使用率に関する条件として規定している。アクション２１６４は、アクションの種別を保持する。アクションの種別としては、「プールサイズ拡張」、「警告」等を挙げることができる。「プールサイズ拡張」は、例えば、プールサイズが不足した場合にプールサイズを拡張させることを意味する。「警告」とは、例えば、プールサイズが不足しそうな場合に、ユーザに警告を発することを意味する。
【００９７】
成功条件２１６５は、アクションの目的となる条件を保持する。図示の例では、プールの使用率を特定の範囲に収めることを、アクションの成功条件（目的）としている。なお、管理ポリシー情報２１６は、管理サーバプログラム２１１のベンダにより予め用意されている構成でもよいし、管理者が手動で作成できる構成でもよい。
【００９８】
図８は、プールの容量使用率を監視するための処理を示すフローチャートである。以下、ステップをＳと略記する。プールの容量使用率は、プールサイズの過不足を測る指標であり、その値が１００%に近いほどサイズが不足していることを示す。容量使用率の監視では、予め監視用の閾値を設定しておき、各プールの容量使用率がその閾値を超えた場合に、何らかのアクションを実行する。具体的な手順を以下に示す。以下の説明では、動作の主体を管理計算機として説明する。マイクロプロセッサ２２が管理サーバプログラム２１１を読み込んで実行することにより以下の機能が実現されるため、マイクロプロセッサ２２または管理サーバプログラム２１１を動作の主体として説明することもできる。
【００９９】
管理計算機２０は、プール情報２１４を参照し、先頭のプールを選択する（Ｓ８１０１）。管理計算機２０は、処理対象のプールを選択できたか否かを判定する（Ｓ８１０２）。もしも、選択するプールがなければ処理を終了する（Ｓ８１０２：ＮＯ）。選択するプールがあれば以下の処理を実行する。
【０１００】
管理計算機２０は、選択したプールの容量使用率を取得する（Ｓ８１０３）。管理計算機２０は、Ｓ８１０３で取得した容量使用率が管理ポリシー情報２１６で規定された閾値を超えたか否かをチェックする（Ｓ８１０４）。換言すれば、取得した容量使用率が起動条件２１６３に合致するか否かを判定する。
【０１０１】
もしも、容量使用率が閾値を超えた場合（Ｓ８１０４：ＹＥＳ）、管理計算機２０は、容量不足に対応すべく、プールサイズを拡張する処理を実施する（Ｓ８１０５）。プールサイズ拡張処理の詳細については、図９で後述する。
【０１０２】
処理対象プールの容量使用率が起動条件に一致しない場合（Ｓ８１０４：ＮＯ）、Ｓ８１０５をスキップする。
【０１０３】
管理計算機２０は、プール情報２１４から次のプールを新たな処理対象プールとして選択し（Ｓ８１０６）、Ｓ８１０２に戻る。プール情報２１４に登録されている全てのプールについて処理を完了して、選択可能なプールが無くなると（Ｓ８１０２：ＮＯ）、本処理は正常に終了する。
【０１０４】
図９は、プールサイズの不足に対応するために、プールサイズを拡張させる処理のフローチャートである。図９のフローチャートは、図８のＳ８１０５で実行される。本処理では、プールサイズが不足した場合の各対処法の妥当性を順番に評価し、妥当と評価された対処法を実行する。以下に具体的な手順を説明する。以下、処理対象のストレージ３０を自ストレージと呼び、処理対象ストレージ以外の他のストレージと区別する。
【０１０５】
最初に、管理計算機２０は、容量不足が発生したストレージ（自ストレージ）内でプール拡張が可能か否かを判定し、それが可能ならば実行する（Ｓ８２０１）。自ストレージ内でプールサイズを拡張する処理の詳細については、図１０で後述する。Ｓ８２０１の実行によって、プールの容量不足が解消した場合（Ｓ８２０２：ＹＥＳ）、本処理は終了する。
【０１０６】
Ｓ８２０１を実行してもプールの容量不足が解消しない場合（Ｓ８２０２：ＮＯ）、管理計算機２０は、自ストレージを除く他ストレージの一覧（他ストレージ一覧）を、ストレージ情報２１３に基づいて作成する（Ｓ８２０３）。なお、他ストレージ一覧をストレージ情報２１３と別に作成するのではなく、ストレージ情報２１３から他ストレージの情報を取得する構成でもよい。その場合、Ｓ８２０４及びＳ８２１１で、自ストレージを選択しないようにする。
【０１０７】
管理計算機２０は、他ストレージ一覧の先頭に記載される他ストレージを一つ選択する（Ｓ８２０４）。管理計算機２０は、処理対象の他ストレージを選択できたか否かを判定する（Ｓ８２０５）。他ストレージを選択できなかった場合（Ｓ８２０５：ＮＯ）、管理計算機２０は、プールの容量不足を解消するための方法が見つからない旨を示すアラートを発行して（Ｓ８２０６）、本処理を終了する。
【０１０８】
処理対象の他ストレージを選択できた場合（Ｓ８２０５：ＹＥＳ）、管理計算機２０は、仮想ボリュームの移行によるプールサイズの拡張という対処法の妥当性をチェックし、もしも妥当ならその対処法を実行する（Ｓ８２０７）。仮想ボリュームの移動によるプールサイズの拡張方法については、図１１で後述する。Ｓ８２０７を処理した結果、プールの容量不足が解消した場合は、本処理を終了する（Ｓ８２０８：ＹＥＳ）。
【０１０９】
仮想ボリュームを移動させることができない場合、または、仮想ボリュームを移動させてもプールの容量不足が解消しない場合のいずれかの場合（Ｓ８２０８：ＮＯ）、管理計算機２０は、他ストレージを用いたプールサイズの拡張という対処法の妥当性をチェックし、もしも妥当ならその対処法実行する（Ｓ８２０９）。Ｓ８２０９の詳細については、図１２で後述する。
【０１１０】
他ストレージを用いたプールサイズの拡張方法を実行した結果、プールの容量不足が解消した場合には、本処理を終了する（Ｓ８２１０：ＹＥＳ）。他ストレージを用いても、プールの容量不足を解消できない場合（Ｓ８２１０：ＮＯ）、管理計算機２０は、他ストレージ一覧から次の他ストレージを選択し（Ｓ８２１１）、Ｓ８２０５に戻る。
【０１１１】
図１０は、自ストレージ内でプールサイズを拡張する処理を示すフローチャートであり、図９のＳ８２０１で実行される。以下の処理では、自ストレージ内の各未使用ボリュームについて、そのサイズ、そのコスト、その性能の各観点で、プールサイズの拡張用ボリュームとして適切か否かの妥当性を評価する。妥当と評価された未使用ボリュームは、サイズの不足しているプールに追加され、そのプールのサイズを拡張させる。
【０１１２】
最初に、管理計算機２０は、自ストレージ内の未使用ボリュームの一覧（以下、拡張用の候補ボリューム一覧とも呼ぶ）を、未使用ボリューム情報２１５から作成する（Ｓ８３０１）。
【０１１３】
なお、候補ボリューム一覧を、未使用ボリューム情報２１５と別に作成するのではなく、未使用ボリューム情報２１５から候補ボリューム一覧を取得する構成でも良い。その場合、Ｓ８３０２及びＳ８３０７では、自ストレージ内の未使用ボリュームのみを選択するようにする。
【０１１４】
管理計算機２０は、候補ボリューム一覧から最初の未使用ボリュームを選択する（Ｓ８３０２）。選択可能な未使用ボリュームが無い場合（Ｓ８３０３：ＮＯ）は、対策未完として本処理を終了する。なお、選択可能な未使用ボリュームが見つからない場合（Ｓ８３０３：ＮＯ）、図１３で後述する処理（Ｓ８６００）を実施してもよい。
【０１１５】
管理計算機２０は、候補ボリューム一覧から未使用ボリュームを一つ選択できた場合（Ｓ８３０３：ＹＥＳ）、その未使用ボリュームのサイズが所定サイズであるか否かを判定する（Ｓ８３０４）。
【０１１６】
所定サイズとは、例えば、プールサイズの不足を解消するために必要なサイズである。具体的には、所定サイズとは、管理ポリシーの成功条件２１６５を満たすために必要なサイズを意味する。このように、未使用ボリュームのサイズが目的に合致するか否かは、管理ポリシー一覧２１６の内容に基づいて判断できる。
【０１１７】
例えば、容量使用率が７５％のプールには、図７に示すように、起動条件２１６３が「プール使用率７０〜８４％」のポリシーが適用される。そのポリシーのアクションに関する成功条件２１６５の内容は「プールの使用率を４０−６０％の範囲に低減すること」と規定されている。ここで、「４０％」という使用率の下限を設定する理由は、行き過ぎた対処を防ぐためである。現在のプールのサイズと容量使用率とから、目標とする容量使用率を得るために必要な追加サイズは次の（１）式によって求められる。
【０１１８】
（追加サイズ）＝（１÷目標とする容量使用率）×現在の容量使用率×現在のプールサイズ−現在のプールサイズ・・・（１）
【０１１９】
もしも、選択された未使用プールのサイズが１００ＴＢの場合、容量使用率７５％を４０％にするために必要な追加サイズは、上記（１）式より、（１÷０．４）×０．７５×１００−１００＝８７．５ＴＢとなる。同様に、容量使用率７５％を６０％にするために必要な追加サイズは、（１÷０．６）×０．７５×１００−１００＝２５ＴＢとなる。
【０１２０】
従って、プールの容量使用率を現在の７５％から、４０％〜６０％の範囲に収めるためには、２５ＴＢ〜８７．５ＴＢの範囲の追加サイズが必要となる。選択された未使用ボリュームのサイズが上記の範囲内であれば、そのボリュームを使用したプール拡張が妥当であると判断できる。
【０１２１】
選択された未使用ボリュームのサイズが所定サイズに合致しない場合（Ｓ８３０４：ＮＯ）、管理計算機２０は候補ボリューム一覧から次の未使用ボリュームを選択し（Ｓ８３０７）、Ｓ８３０３に移る。
【０１２２】
選択された未使用ボリュームのサイズが所定サイズに合致する場合（Ｓ８３０４：ＹＥＳ）、管理計算機２０は、その未使用ボリュームのコスト区分の妥当性を評価する（Ｓ８３０５）。図中では、便宜上、「コスト区分」を「コスト」と簡略化して示す。
【０１２３】
管理計算機２０は、具体的には、選択された未使用ボリュームに設定されているコスト区分の内容が（未使用ボリューム情報２１５のコスト区分２１５４の内容）が、割当先のプールに設定されているコスト区分の内容（プール情報２１４のコスト区分２１４４の内容）に含まれているか否かを判定する。
【０１２４】
例えば、図６に示すように、「ＵＶＯＬ−Ａ」の識別名を有する未使用ボリュームには、コスト区分２１５４として「Ａ」が設定されている。一方、図５に示すように、「ＰＯＯＬ−Ｂ」の識別名を有するプールには、コスト区分２１４４として「Ａ，Ｂ」が設定されている。この場合、未使用ボリュームのコスト区分「Ａ」は、プールのコスト区分「Ａ，Ｂ」に含まれているため、そのプール（ＰＯＯＬ−Ｂ）のコスト区分と未使用ボリュームのコスト区分とは適合する。
【０１２５】
未使用プールのコスト区分とプールのコスト区分とが適合しないと判定された場合（Ｓ８３０５：ＮＯ）、管理計算機２０は、Ｓ８３０７に移る。
【０１２６】
未使用ボリュームのコスト区分とプールのコスト区分とが適合する場合（Ｓ８３０５：ＹＥＳ）、管理計算機２０は、プールサイズを拡張した後の性能を予測して評価する（８３０６）。管理計算機２０は、選択された未使用ボリュームをプールに追加した場合、そのプールが所定値以上の性能を維持できるか否かを判定する。
【０１２７】
例えば、高速な論理ボリュームから構成されているプールに、低速な論理ボリュームを追加した場合、そのプールの平均応答性能は低下する。プールの応答性能が低下すると、そのプール内のページを使用する仮想ボリュームのＩ／Ｏ性能も低下する。
【０１２８】
仮想ボリュームの性能低下を防ぐためには、例えば、追加対象の未使用ボリュームを、現在使われている論理ボリュームの性能と同じかそれ以上の性能を有する論理ボリュームに限定すればよい。
【０１２９】
なお、未使用ボリュームをプールに追加することにより、そのプール内の各論理ボリュームに対するＩ／Ｏ処理の並列性が高まる。従って、低速の論理ボリュームを追加した場合でも、プールとしての平均性能は低下しないか、または、高まる可能性もある。Ｓ８３０６では、この点を考慮に加えても良い。
【０１３０】
さらに、Ｓ８３０６では、仮想ボリュームの性能低下の度合を推定し、その度合が許容範囲内の場合は、選択された未使用ボリュームをプールに追加する構成でもよい。
【０１３１】
ボリューム追加後に性能上の問題が生じないと予測される場合（Ｓ８３０６：ＹＥＳ）、管理計算機２０は、選択された未使用ボリュームを用いてプールのサイズ拡張を実施させ（Ｓ８３０８）、本処理を終了する。
【０１３２】
選択された未使用ボリュームをプールに追加すると、そのプールが所定値以上の性能を維持できないと予測される場合（Ｓ８３０６：ＮＯ）、管理計算機２０は、候補ボリューム一覧から次の未使用ボリュームを選択（Ｓ８３０７）し、Ｓ８３０３に戻る。
【０１３３】
なお、図１０の処理では、一つの未使用ボリュームをプールに追加するだけで、そのプールの容量不足に対処できる場合を説明している。しかし、一つの未使用ボリュームを追加する構成に限らず、複数の未使用ボリュームをプールに追加してプールの容量不足を解消する構成でも良い。
【０１３４】
その場合、例えば、Ｓ８３０４のサイズチェックでは、未使用ボリュームのサイズが上限値をオーバーする場合を除いて、追加目的に合致すると判定する。そして、Ｓ８３０５及びＳ８３０６それぞれのチェックを通る、未使用ボリュームのリストを作成し、そのリストから、合計サイズが所定サイズとなる複数の未使用ボリュームを抽出して、それら複数の未使用ボリュームをプールに追加する構成でも良い。
【０１３５】
さらに、Ｓ８３０４で所定サイズに満たないと判定された一つの未使用ボリュームを、プールに追加する構成でもよい。その場合、図１０に示す対処法以外に、複数の対処法（図１１，図１２）を併用することが前提となる。
【０１３６】
さらに、成功条件として定義されている目標使用率に達しない場合でも、未使用ボリュームを一つも追加しない場合よりは、プールの使用率を低下させることができる。従って、所定サイズに満たない未使用ボリュームであっても、プールに追加することにより、プールサイズが枯渇するリスクを軽減できる。
【０１３７】
さらに、自ストレージ内に複数のプールが存在する場合、容量不足となっている処理対象プール以外の他プール（自ストレージ内の他プール）で使用されている論理ボリュームを、処理対象プールに移すことで、容量不足に対処することも可能である。
【０１３８】
そのような対処法を図１０ではＳ８６００として示す。図１３を参照して、自ストレージ内の他プールを利用する対処法を説明する。
【０１３９】
図１０のフローチャートで対策未完として終了する前に、管理計算機２０は、自ストレージ内に存在する一つまたは複数の他プールについて、それらの他プールを構成する各論理ボリュームの一覧を作成する（Ｓ８６０１）。
【０１４０】
管理計算機２０は、他プールを構成するボリューム一覧の中から先頭のボリュームを選択する（Ｓ８６０２）。管理計算機２０は、選択されたボリュームが、処理対象のプール（容量不足となっている自プール）に流用可能か否か判断する（Ｓ８６０３）。
【０１４１】
流用可能か否かを判断するための一つの基準として、例えば、その論理ボリュームを他プールから取り外した場合でも、他プールの容量使用率が予め定めた基準以下となることを挙げることができる。この基準は、論理ボリュームを流用したことによって、流用元のプールが容量不足になることを防ぐために設けられる。
【０１４２】
他プール内の論理ボリュームを流用可能な場合（Ｓ８６０３：ＹＥＳ）、管理計算機２０は、図１０で述べたと同様の各判定を行う。管理計算機２０は、その論理ボリュームが所定サイズを有するか否かを判定する（Ｓ８６０４）。次に、管理計算機２０は、その論理ボリュームのコスト区分と流用先のプール（自プール）のコスト区分とが適合するか否かを判定する（Ｓ８６０５）。次に、管理計算機２０は、自プールが所定値以上の性能を有するか否か予測する（Ｓ８６０６）。
【０１４３】
さらに、管理計算機２０は、他プールから論理ボリュームを取り外すと、他プールの性能が低下する可能性がある点と、論理ボリュームの取り外しに時間を要する点を考慮することができる（Ｓ８６０７）。
【０１４４】
他プールから論理ボリュームを一つ取り外すと、他プールを構成する論理ボリュームの数が少なくなるため、他プールにおけるＩ／Ｏ処理の並列性が低下する。従って、他プールの応答性能が低下する可能性がある。他プールから論理ボリュームを取り外す場合、その論理ボリュームに記憶されているデータを、他プール内の別の論理ボリュームにコピーして移動させる必要がある。従って、流用対象の論理ボリュームに記憶されているデータの量によっては、データコピー時間が長くなる可能性がある。この観点から、記憶されているデータ量の多い論理ボリュームは、流用できないボリュームであると判定する構成としてもよい。
【０１４５】
なお、流用可能な論理ボリュームが複数存在する場合は、例えば、流用元プールの容量使用率、論理ボリュームのサイズの少なさ、取り外しに要する時間の短さ、性能低下の少なさ、などの基準に従って、いずれか一つの論理ボリュームを選択すればよい。
【０１４６】
各判断ステップを満たさない場合、管理計算機２０は、次のボリュームを選択して（Ｓ８６０８）、Ｓ８６０３に戻る。各判断ステップを全て満たす場合、管理計算機２０は、他プール内の論理ボリュームを他プールから取り外して、容量不足状態の自プールに追加させる（Ｓ８６０９）。図１１に戻る。
【０１４７】
図１１は、仮想ボリュームの移動によりプールの容量不足を解消する処理を示すフローチャートであり、図９のＳ８２０７で実行される。本処理では、容量不足のプールを利用している各仮想ボリュームについて、移行手段の有無、ボリュームサイズ、コスト区分の適合可否、移行完了時間、移行後の性能の各点で、評価する。他ストレージの他プールへの移動が妥当であると判断された仮想ボリュームは、他ストレージ内の他プールに移動される。以下に具体的な手順を示す。
【０１４８】
最初に、管理計算機２０は、容量不足のプールを利用している仮想ボリュームの一覧を作成する（Ｓ８４０１）。その仮想ボリュームの一覧は、移行候補となる仮想ボリュームの一覧を示すため、以下の説明では、移行候補仮想ボリューム一覧と呼ぶ。
【０１４９】
移行候補仮想ボリューム一覧は、仮想ボリューム情報２１２から作成すれば良い。または、移行候補仮想ボリューム一覧は、仮想ボリューム情報２１２と別に作成するのではなく、仮想ボリューム情報２１２から得ることもできる。その場合は、Ｓ８４０２及びＳ８４０９では、容量不足のプールに所属している仮想ボリュームの中から選択する。
【０１５０】
管理計算機２０は、移行候補仮想ボリューム一覧から最初の仮想ボリュームを選択する（Ｓ８４０２）。仮想ボリュームを選択できなかった場合（Ｓ８４０３：ＮＯ）、本処理は、対策未完として終了する。
【０１５１】
仮想ボリュームを一つ選択できた場合（Ｓ８４０３：ＹＥＳ）、管理計算機２０は、選択されている他ストレージ３０に、その仮想ボリュームを移動させる手段の有無を確認する（Ｓ８４０４）。ストレージ３０側で仮想ボリュームを移動させる手段と、ホスト計算機４０側で仮想ボリュームを移動させる手段とがある。
【０１５２】
ストレージ３０が仮想ボリュームを移動させる手段を備えているか否かは、ストレージ情報２１３のボリューム移行機能２１３２の内容で判断できる。ホスト計算機４０が仮想ボリュームを移動させる手段を備えているか否かは、仮想ボリューム情報２１２のボリューム移行機能２１２６の内容によって判断できる。
【０１５３】
管理計算機２０は、ストレージ側での仮想ボリューム移行手段の有無と、ホスト計算機側での仮想ボリュームの移行手段の有無とを確認し、仮想ボリュームを他ストレージへ移行させるための手段が少なくとも一つ存在するか否かを判定する（Ｓ８４０４）。
【０１５４】
仮想ボリュームを他ストレージへ移行させるための手段が一つも無い場合（Ｓ８４０４：ＮＯ）、管理計算機２０は、次の仮想ボリュームを選択して（Ｓ８４０９）、Ｓ８４０３に戻る。
【０１５５】
仮想ボリュームを他ストレージへ移動させる手段が少なくとも一つ存在する場合（Ｓ８４０９：ＹＥＳ）、管理計算機２０は、その仮想ボリュームのサイズが所定サイズであるか否かを判定する（Ｓ８４０５）。仮想ボリュームのサイズが、管理ポリシーの目的に合致するか否かは、管理ポリシー一覧２１６の内容によって判断することができる。
【０１５６】
例えば、容量使用率が７５％のプールには、図７に示すように、起動条件２１６３が「プール使用率７０〜８４％」のポリシーが適用される。そのポリシーのアクションに関する成功条件２１６５の内容は「プールの使用率を４０−６０％の範囲に低減すること」と規定されている。現在のプールのサイズと容量使用率とから、目標とする容量使用率を得るために必要な仮想ボリュームの移行サイズは、次の（２）式によって求められる。
【０１５７】
（移行サイズ）＝（現在の容量使用率−目標とする容量使用率）×プールサイズ・・・（２）
【０１５８】
もしも、プールのサイズが１００ＴＢの場合、容量使用率７５％を４０％に低下させるために必要な追加サイズは、（０．７５−０．４）×１００＝３５ＴＢとなる。同様に、容量使用率７５％を６０％に低下させるために必要な追加サイズは、（０．７５−０．６）×１００＝１５ＴＢとなる。
【０１５９】
従って、プールの容量使用率を４０％から６０％の範囲に収めるためには、１５ＴＢ〜３５ＴＢの範囲のボリュームサイズを持つ仮想ボリュームを、他ストレージの他プールへ移行させる必要がある。
【０１６０】
Ｓ８４０３で選択された仮想ボリュームのサイズが上記の範囲内であれば、その仮想ボリュームの移行は妥当であると判断できる。仮想ボリュームのサイズが所定サイズに合致しないと判断された場合（Ｓ８４０５：ＮＯ）、Ｓ８４０９に移る。
【０１６１】
仮想ボリュームのサイズが所定サイズに合致する場合（Ｓ８４０５：ＹＥＳ）、管理計算機２０は、その仮想ボリュームに設定されているコスト区分と、移行先の他プールに設定されているコスト区分とが適合するか否かを判定する（Ｓ８４０６）。
【０１６２】
具体的には、仮想ボリューム情報２１２のコスト区分２１５４の内容が、プール情報２１４のコスト区分２１４４の内容に含まれている場合、両者のコスト区分が適合すると判断できる。例えば、図３に示す、「ＶＶＯＬ−Ｂ」の識別名を有する仮想ボリュームを、図５に示す、「ＰＯＯＬ−Ａ」の識別名を有するプールに移動させることを評価する場合を説明する。図３に示すように、仮想ボリューム（ＶＶＯＬ−Ｂ）のコスト区分２１５４は「Ａ，Ｂ」である。図５に示すように、プール（ＰＯＯＬ−Ａ）のコスト区分２１４４には「Ａ」が設定されている。移行先のプールのコスト区分「Ａ」は、仮想ボリュームのコスト区分「Ａ，Ｂ」に含まれているため、管理計算機２０は、両者のコスト区分が適合すると判定する。仮想ボリュームのコスト区分と移行先プールのコスト区分とが適合しないと判断された場合は、Ｓ８４０９に進む。
【０１６３】
両者のコスト区分が適合すると判断された場合（Ｓ８４０６：ＹＥＳ）、管理計算機２０は、仮想ボリュームを他プールに移行させるために要する時間（移行所要時間）が、プールの容量不足の解消に間に合うか否かを判定する（Ｓ８４０７）。
【０１６４】
例えば、プールの容量使用率が急上昇した場合、プールの容量不足に至急対処する必要がある。プールの容量使用率が１００%になる前に、そのプールのサイズを拡張する必要がある。そのためには、プールの容量使用率が１００％に到達する日時（プールサイズが枯渇する日時）と、容量不足の対策が完了する日時（移行完了日時）とを、それぞれ推定する必要がある。
【０１６５】
プールサイズの枯渇日時は、例えば、プール容量使用率の過去の履歴から単位時間あたりの増加率を求め、その増加率に基づいて計算すればよい。移行完了日時は、例えば、（ａ）アプリケーションプログラム４４３が稼動中に仮想ボリュームを移行可能であるか否か、（ｂ）アプリケーションプログラム４４３の稼動期間、（ｃ）仮想ボリュームの移行所要処理時間、などの情報に基づいて計算すればよい。
【０１６６】
（ａ）は、ホスト計算機４０内のボリューム移行プログラム４４２については、仮想ボリューム情報２１２のボリューム移行機能２１２６を参照すれば、確認できる。ストレージ３０内のボリューム移行プログラム３１４２を使用する場合は、ストレージ情報２１３のボリューム移行機能２１３２を参照すれば確認できる。
【０１６７】
（ｂ）については、仮想ボリューム情報２１２のアプリケーションプログラム稼動期間２１２５を参照することで確認できる。
【０１６８】
（ｃ）については、仮想ボリュームのサイズとサイズあたりの仮想ボリューム移行時間との乗算で求められる。サイズあたりの仮想ボリューム移行時間は、例えば、予め設定される参考値に基づいて算出したり、または、過去の仮想ボリュームの移行に要した時間から選択したりできる。参考値は、各論理ボリュームの性能毎にそれぞれ用意される。
【０１６９】
移動完了日時の算出方法は、（ａ）の内容によって異なる。即ち、アプリケーションプログラム４４３を停止させずに仮想ボリュームの移動が可能である場合は、現在時刻に（ｃ）の移行所要時間を加えた時刻となる。
【０１７０】
これに対し、アプリケーションプログラム４４３の稼働中に仮想ボリュームを移動させることができな場合は、アプリケーションプログラム４４３の稼動終了時刻に、（ｃ）の移行所要時間を加えた時刻となる。
【０１７１】
なお、仮想ボリュームの移行所要時間が長い場合等には、業務開始時刻までに仮想ボリュームの移行が完了しない可能性が考えられる。そのような事態が発生するのを防止するために、例えば、（ａ）のアプリケーションプログラム４４３の稼働中に仮想ボリュームを移動させることができない場合であって、かつ、予測される移行完了日時がアプリケーションプログラム４４３の開始時刻以降となる場合は、その仮想ボリュームを移行させることはできない、と判断すればよい。
【０１７２】
なお、プールサイズの枯渇日時及び仮想ボリュームの移行完了日時は、いずれも推定値となるため、余裕を持って判断するのが好ましい。即ち、プールサイズの枯渇日時は、例えば、予測値よりも一定量早い時刻を採用する。移行完了日時は、予測値よりも一定量遅い時刻を採用する。これにより、予想よりも早くプールサイズが枯渇する事態、または、仮想ボリュームの移行が予想よりも遅く完了する事態、の発生を抑制できる。
【０１７３】
さらに、上記の代替案として、容量使用率の絶対値が所定の上限値よりも高い場合、あるいは、容量使用率の増加率が所定の増加率よりも高い場合など、比較的対応が急がれる場合には、対処完了までの処理時間が相対的に短い対処法（例えばプール拡張）を常に選択する構成としてもよい。
【０１７４】
なお、ホスト計算機４０内のボリューム移行プログラム４４２による仮想ボリュームの移行と、ストレージ３０内のボリューム移行プログラム３１４２による仮想ボリュームの移行との両方を実施できる場合は、何らかの方法によっていずれかを一つを選択する必要がある。
【０１７５】
その選択基準としては、例えば、処理完了までの時間の早さ、ホスト計算機４０の負荷の大きさ、ストレージ３０の負荷の大きさなどを挙げることができる。なお、図１４に示すように、ホスト計算機４０のボリューム移行プログラム４４２を用いる場合は、データ転送サイズを比較的少なくでき、かつ、不要なデータを除去できるかも知れないという効果を奏する。
【０１７６】
図１４を参照する。ファイルシステムは、サイズＳＺ１のデータＤ１，Ｄ２，Ｄ３をｎ個管理している。ファイルシステム上の使用サイズは、ＳＺ１×ｎとなる。それらのデータＤ１，Ｄ２，Ｄ３は、仮想ボリューム７２０にばらばらに書き込まれるとする。仮想ボリューム７２０には、各データＤ１，Ｄ２，Ｄ３を格納するために、ｎ個のチャンク（実ページ）Ｃ１，Ｃ２，Ｃ３が割り当てられる。チャンクのサイズをＳＺ２とする（ＳＺ２＞ＳＺ１）。従って、仮想ボリューム７２０へのページ割り当てサイズは、ＳＺ２×ｎとなる。
【０１７７】
ホスト計算機４０が仮想ボリュームを移動させる場合のデータ転送量はＳＺ１×ｎとなるのに対し、ストレージ３０が仮想ボリュームを移動させる場合のデータ転送量はＳＺ２×ｎとなり、後者の方が大きい。このため、図１４に示す例では、ストレージ３０が仮想ボリュームを移動させる場合、ホスト計算機４０が仮想ボリュームを移動させる場合に比べて、移行所要時間が長くなる。
【０１７８】
従って、ファイルシステム上の使用サイズ（ＳＺ１×ｎ）と仮想ボリュームへのページ割り当てサイズ（ＳＺ２×ｎ）との差異を、ボリューム移行手段を選択するための基準として用いても良い。
【０１７９】
さらに、ＯＳ４４４のファイルシステム７１０上でデータが削除されても、削除されたデータが不要データであることを、ストレージ３０が認識できない場合も考えられる。その場合、不要なデータのために、仮想ボリューム７２０にページ（チャンク）が割り当てられたままとなる。
【０１８０】
ホスト計算機４０内のボリューム移行プログラム４４２が、削除されたデータを除外してデータを移行させる仕組みを持つと仮定する。ボリューム移行プログラム４４２を用いて仮想ボリュームのデータを移行元プール７２０から移行先プール７２１に移行させると（図１４の矢印７５１，７５２）、移行先プール７２１には、削除された不要データが格納されない。従って、仮想ボリュームの移行前に比べて、プールの使用サイズを少なくできる。
【０１８１】
この現象を利用して、ファイルシステム７１０上の使用サイズと仮想ボリュームへのページ割り当てサイズの差（または比率）が一定以上になる場合，ホスト計算機４０内のボリューム移行プログラム４４２を優先して実行するようにしても良い。
【０１８２】
図１１に戻る。Ｓ８４０７を実行した結果、プールの容量不足状態が仮想ボリュームのデータ移行完了時刻まで待てないと判定された場合（Ｓ８４０７：ＮＯ）、Ｓ８４０９に進む。
【０１８３】
仮想ボリュームのデータ移行が完了するまで待つことができると判断された場合（Ｓ８４０７：ＹＥＳ）、管理計算機２０は、仮想ボリューム移行後における仮想ボリュームの性能を予測して評価する（Ｓ８４０８）。即ち、管理計算機２０は、移行後においても、仮想ボリュームの性能を維持できるか否か判断する。
【０１８４】
仮想ボリュームを自ストレージ内のプールから他ストレージのプールに移行させることによって、仮想ボリュームのＩ／Ｏ性能が低下する可能性がある。移行後に仮想ボリュームのＩ／Ｏ性能が低下するか否かについては、移行元プール及び移行先プールのそれぞれについて、プールを構成する論理ボリュームの性能、論理ボリュームの数、プールの負荷の大きさ、移行対象の仮想ボリュームのＩ／Ｏ量などを考慮して判断すればよい。仮想ボリュームの性能低下の度合が許容範囲内である場合は、特に問題無しとして、その移行を認めてもよい。
【０１８５】
Ｓ８４０８実行の結果、性能上の問題が無さそうであると判断された場合、選択された仮想ボリュームを、選択された他ストレージ３０に移行させ（Ｓ８４１０）、対策完として本処理を終了する。
【０１８６】
移行後に仮想ボリュームの性能が所定値以上低下するような場合（Ｓ８４０８：ＮＯ）、移行候補仮想ボリューム一覧から次の仮想ボリュームを選択し（Ｓ８４０９）、Ｓ８４０３に戻る。
【０１８７】
なお、図１１のフローチャートでは、一つの仮想ボリュームを移行させるだけで、移行元プールの容量を拡張する場合を示しているが、これに限らず、複数の仮想ボリュームを移動させる構成でもよい。その場合、例えば、Ｓ８４０５でのボリュームサイズのチェックでは、仮想ボリュームのサイズがオーバーする場合を除いて、プール容量不足を解消させる目的に合うものと判定する。Ｓ８４０４、Ｓ８４０６、Ｓ８４０７のそれぞれの判定に合格する複数の仮想ボリュームのリストを作成し、そのリストから、仮想ボリュームの合計サイズが必要なサイズ範囲になるように、複数の仮想ボリュームを抽出する。抽出された複数の仮想ボリュームを複数の他プールへ移行させる。
【０１８８】
なお、Ｓ８４０５で仮想ボリュームのサイズが所定サイズに達していない場合でも、その仮想ボリュームの移行を実施させる構成としても良い。その場合、複数の対処法を併用することになる。最終目標の容量使用率に達しなくても、仮想ボリュームの移行を実施しない場合と比べると、プールの容量使用率を低下させることができる。従って、プールサイズが枯渇するリスクを軽減できる。
【０１８９】
図１１のフローチャートでは詳しく述べていないが、他ストレージ内に複数のプールが存在する場合は、Ｓ８４０５からＳ８４０８までの各ステップを、他ストレージ内の各プールのそれぞれについて実施することになる。
【０１９０】
仮想ボリュームの移行に適したプールが複数ある場合は、例えば、移行先プールの容量使用率、移行時間の短さ、移行後の性能低下の少なさ、などによって移行先プールを一つ選択すればよい。
【０１９１】
なお、図１１のフローチャートでは図示を省略しているが、自ストレージ内に複数のプールが存在する場合への考慮を加えても良い。自ストレージ内に複数のプールが存在する場合、容量不足のプールから、空き容量の十分あるプールに、仮想ボリュームを移行させるという対処法も選択肢に含めることができる。その場合、図１１のフローチャートと同様に、例えば、他プールへ仮想ボリュームを移行させる手段の有無、仮想ボリュームのサイズが目的に合致するか、移行先プールのコスト区分と仮想ボリュームのコスト区分が適合するか、容量不足のプールは移行完了時刻まで待てるか、移行後の性能は維持されるか、などの評価を行えばよい。
【０１９２】
図１２は、他ストレージの有する論理ボリュームを利用して、自ストレージのプールのサイズ拡張を図る処理のフローチャートであり、図９のＳ８２０９で実行される。本処理では、以下に述べるように、選択された他ストレージのボリューム（外部ボリューム）に、自ストレージから接続可能か否かをチェックする。もしも接続可能であれば、選択された他ストレージ内の各ボリュームのうち未使用のボリュームについて、ボリュームサイズ、コスト区分、性能変化の各点で、プール拡張用のボリュームとして適切であるかの妥当性を評価する。妥当と評価された未使用の外部ボリュームが存在する場合、自ストレージからその未使用の外部ボリュームに接続し、その外部ボリュームを自ストレージ内のプールに割り当ててプールサイズを拡張する。
【０１９３】
最初に、管理計算機２０は、選択された他ストレージのボリュームに接続する機能（外部接続機能）を、自ストレージが有するか否かをチェックする（Ｓ８５０１）。このチェックのためには、ストレージ情報２１３の外部接続機能２１３３を参照すればよい。
【０１９４】
自ストレージが外部接続機能を備えていない場合（Ｓ８５０１：ＮＯ）、本処理は、対策未完として終了する。自ストレージが外部接続機能を有する場合（Ｓ８５０１：ＹＥＳ）、以下の処理が実施される。
【０１９５】
管理計算機２０は、選択された他ストレージ内の未使用ボリューム一覧（以下、候補ボリューム一覧）を、未使用ボリューム情報２１５から作成する（Ｓ８５０２）。なお、候補ボリューム一覧を、未使用ボリューム情報２１５と別に作成するのではなく、未使用ボリューム情報２１５から未使用の候補ボリュームの情報を読み出す構成でもよい。その場合、Ｓ８５０３及びＳ８５０８では、選択された他ストレージ内の未使用ボリュームのみを選択する。
【０１９６】
管理計算機２０は、候補ボリューム一覧から先頭の未使用ボリュームを一つ選択する（Ｓ８５０３）。管理計算機２０は、未使用ボリュームを選択できたか否かを判断する（Ｓ８５０４）。選択可能な未使用ボリュームが無い場合（Ｓ８５０４：ＮＯ）、対策未完として本処理を終了する。
【０１９７】
他ストレージ内の未使用ボリュームを選択できた場合（Ｓ８５０４：ＹＥＳ）、管理計算機２０は、その未使用ボリュームのサイズが所定サイズであるか否かを判定する（Ｓ８５０５）。つまり、選択された未使用ボリュームが、自ストレージ内のプールの容量不足を解消させるのに適切なサイズであるかを確認する。未使用ボリュームのサイズが所定サイズであるか否かは、管理ポリシー一覧２１６の内容によって判断すれば良い。その処理内容は、図１０のＳ８３０４と同じである。より詳しくは、管理計算機２０は、未使用ボリュームのサイズが目的達成に必要な範囲のサイズであるか否かを判定する。
【０１９８】
選択された未使用ボリュームのサイズが所定サイズではない場合（Ｓ８５０５：ＮＯ）、管理計算機２０は、候補ボリューム一覧から次の未使用ボリュームを選択し（Ｓ８５０８）、Ｓ８５０４に戻る。
【０１９９】
選択された未使用ボリュームのサイズが所定サイズの場合（Ｓ８５０５：ＹＥＳ）、管理計算機２０は、未使用ボリュームのコスト区分と割当先のプールのコスト区分とが適合するか否かを判断する（Ｓ８５０６）。その具体的な処理内容は、図１０のＳ８３０５と同じである。
【０２００】
未使用ボリュームのコスト区分とプールのコスト区分とが適合しない場合（Ｓ８５０６：ＮＯ）、Ｓ８５０８に移る。
【０２０１】
未使用ボリュームのコスト区分とプールのコスト区分とが適合する場合（Ｓ８５０６：ＹＥＳ）、管理計算機２０は、未使用ボリュームをプールに追加した場合の性能を評価する（Ｓ８５０７）。性能評価の方法は、図１０のＳ８３０６と同様である。
【０２０２】
しかし、Ｓ８５０７の場合は、外部接続機能を利用して、他ストレージ内の未使用ボリュームを自ストレージ内のプールに追加する。従って、自ストレージから他ストレージにアクセスする必要があり、オーバーヘッドが生じる。そのため、オーバーヘッド分の補正を実施すると良い。即ち、本処理では、オーバーヘッドを考慮して、プールの性能値の変化を予測する。例えば、予め固定値として設定されているオーバーヘッドの量を用いて、プール性能を予測することができる。あるいは、ストレージ３０の入出力処理プログラム３１４１に、オーバーヘッド量を測定させる機能を設け、それにより測定された値に基づいてプール性能を予測する構成でもよい。
【０２０３】
他ストレージ内の未使用ボリュームをプールに追加しても、そのプールの性能が維持されると判断された場合（Ｓ８５０７：ＹＥＳ）、選択された未使用ボリュームを用いてプールサイズを拡張する（Ｓ８５０９）。本処理は、対策完として終了する。プールの性能が許容値以上低下すると予測された場合（Ｓ８５０７：ＮＯ）、Ｓ８５０８に移る。
【０２０４】
なお、図１２のフローチャートでは、一つの未使用ボリュームをプールに追加するだけでプールの容量不足に対処する場合を説明した。これに代えて、複数の未使用ボリュームをプールに追加して、プールの容量不足に対処する構成でも良い。
【０２０５】
その場合、例えばＳ８５０５のサイズチェックでは、ボリュームサイズが所定サイズ（所定のサイズ範囲）を超える場合を除いて、目的に合うものと判定する。さらに、Ｓ８５０６及びＳ８５０７のそれぞれのチェックに合格する未使用ボリュームのリストを作成し、そのリストから、未使用ボリュームの合計サイズが必要なサイズ範囲になる複数の未使用ボリュームを抽出する。抽出された複数の未使用ボリュームをプールに追加することにより、プールサイズを拡張することもできる。
【０２０６】
なお、所定サイズに達しない未使用ボリュームを用いて、プールサイズを拡張する構成としても良い。その場合、複数の対処法を実施することになる。目標の容量使用率を実現するための未使用ボリュームが得られない場合でも、未使用ボリュームをプールに一つも追加しない場合に比べると、プールの容量使用率を下げることができる。従って、不十分なサイズの未使用ボリュームであっても、その未使用ボリュームをプールに追加することで、プールの容量が枯渇するリスクを軽減できる。
【０２０７】
図１２のフローチャートでは、他ストレージ内の未使用ボリュームを用いて、自ストレージのプールサイズ拡張について述べている。これに代えて、他プールに割り当てられている、使用済みの論理ボリュームを、自ストレージのプールのサイズ拡張用に流用する構成でもよい。
【０２０８】
そのために、図１３で述べたＳ８６００の処理を、Ｓ８５０４で「ＮＯ」と判定された後に実施すればよい。
【０２０９】
なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。
【符号の説明】
【０２１０】
１０：管理端末、２０：管理計算機、３０：ストレージ、４０：ホスト計算機
【技術分野】
【０００１】
本発明は、計算機システム及び計算機システムの管理方法に関する。
【背景技術】
【０００２】
大型のストレージはストレージサブシステムとも呼ばれ、高速かつ大容量なデータ保管を可能とするだけでなく、高度なデータ管理機能を有する。ストレージ内にはハードディスクドライブなどの物理的な記憶装置が複数搭載される。それら記憶装置内の記憶領域を用いて、論理的な記憶領域である論理ボリュームが構成される。ストレージ装置は、論理ボリュームをホスト計算機に提供する。ホスト計算機は、論理ボリュームに対して、データを読み書きする。
【０００３】
近年、論理ボリュームの容量効率を向上させるシンプロビジョニング技術が提案されている。シンプロビジョニング技術は、従来の論理ボリュームに代わる仮想的な論理ボリューム（以下、仮想ボリューム）をホストに提供する。
【０００４】
従来の論理ボリュームは、ボリューム作成時に指定されたサイズの、物理的な記憶領域（実記憶領域）を必要とする。これに対し、仮想ボリュームは、実際にデータの書き込みが発生した時点で、そのデータを記憶するための実記憶領域をプールから取り出して、仮想ボリュームに割り当てるようになっている。シンプロビジョニング技術を用いると、実際にデータの書き込みが発生するまでの間は、仮想ボリュームに実記憶領域を割り当てる必要がないため、実記憶領域を節約することができる。
【０００５】
しかし、仮想ボリュームへのデータ書き込み状況によっては、仮想ボリュームに書き込まれるデータの量が、仮想ボリュームに割り当て可能な実記憶領域のサイズを超えてしまう場合が考えられる。仮想ボリュームに割り当てるべき実記憶領域が不足すると、エラーが発生しうる。
【０００６】
そのため、シンプロビジョニング技術を用いる場合は、仮想ボリュームに割り当て可能な実記憶領域の量（実使用量）を正確に管理することが好ましい。
【０００７】
第１の従来技術では、プールに容量不足が発生した場合、使用可能なボリュームをプールに追加して、プールのサイズを拡張する（特許文献１）。第２の従来技術では、プールを利用している仮想ボリュームを他のプールに移行させることにより、移行元のプールの容量不足を解消する（特許文献２）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−１９３５７３号公報
【特許文献１】特開２０１０−８６４２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
プールのサイズが不足した場合の対処法として、前記の二通りの方法が知られている。しかし、計算機システムの構成は複雑であり、かつ、状況は変化するため、計算機システムの管理者であるユーザは、どの対処法を選択すべきなのか判断に迷う。
【００１０】
複数の異種ストレージが混在するヘテロジニアスな計算機システムでは、考慮すべき要素が多くなるため、適切な対処法の選択がより難しい。特に、経験が少なく、知識の乏しいユーザの場合は、頼るべき基準を持たないため、対象法の選択は一層困難となる。
【００１１】
そこで、本発明の目的は、複数の方法の中から所定の選択基準に基づいて少なくとも一つの方法を選択して実行することにより、管理者の負担を軽減し、プールサイズを拡張できるようにした 計算機システム及び計算機システムの管理方法を提供することにある。
【課題を解決するための手段】
【００１２】
上記課題を解決すべく、本発明に従う計算機システムは、少なくとも一つの仮想的な論理ボリュームを生成する複数の記憶制御装置と、仮想的な論理ボリュームを使用する少なくとも一つのホスト計算機と、各記憶制御装置とホスト計算機とを管理するための少なくとも一つの管理計算機とを含む計算機システムであって、各記憶制御装置は、ホスト計算機からのライトアクセスに応じて、プール内の実ボリュームの有する実記憶領域を仮想的な論理ボリュームに割り当て、ホスト計算機から受信するライトデータを、割り当てられた実記憶領域に記憶させるようになっており、管理計算機は、マイクロプロセッサと、マイクロプロセッサにより読み込まれて実行される所定のコンピュータプログラムを記憶するメモリと、各記憶制御装置及びホスト計算機と通信するための通信インターフェース部とを備えており、マイクロプロセッサは、所定のコンピュータプログラムを読み込んで実行することにより、各プールの使用状態を取得し、取得された各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定し、所定プールが検出された場合は、（Ａ）所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、（Ｂ）仮想的な論理ボリュームのデータを所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、選択された方法に従って、所定プールのプールサイズを拡張させる。
【００１３】
マイクロプロセッサは、ボリューム追加方法とデータ移動方法のいずれかを選択する場合に、仮想的な論理ボリュームを使用するアプリケーションプログラムの稼働状況を考慮して、所定時間内に所定プールのプールサイズの拡張が完了するか否かを判定することもできる。
【００１４】
ボリューム追加方法は、各記憶制御装置のうち所定プールの属する所定の記憶制御装置が有する、未使用の第１の実ボリュームを所定プールに追加させる、第１のボリューム追加方法を含ませてもよい。
【００１５】
マイクロプロセッサは、第１のボリューム追加方法を実行する場合、所定の選択基準として、第１の実ボリュームのボリュームサイズと、所定プールに予め設定されている属性ラベルと第１の実ボリュームに予め設定されている属性ラベルとの適合状態と、所定プールに第１の実ボリュームを追加した場合の所定プールの応答性能とを考慮してもよい。
【００１６】
ボリューム追加方法には、各記憶制御装置のうち所定の記憶制御装置以外の他の記憶制御装置が有する、未使用の第２の実ボリュームを所定の記憶制御装置に接続することにより、第２の未使用の実ボリュームを所定プールに追加させる、第２のボリューム追加方法を含めてもよい。
【００１７】
ボリューム追加方法には、各記憶制御装置のうち所定の記憶制御装置の有する第１の他のプールに設けられている第３の実ボリュームを取り外し、その取り外された第３の実ボリュームを未使用の実ボリュームとして所定プールに追加させる、第３のボリューム追加方法を含めてもよい。
【００１８】
ボリューム追加方法には、所定の記憶制御装置以外の他の記憶制御装置が有する、第２の他のプールに設けられている第４の実ボリュームを取り外し、その取り外された第４の実ボリュームを未使用の実ボリュームとして所定プールに追加させる、第４のボリューム追加方法を含めてもよい。
【００１９】
データ移動方法には、ホスト計算機が仮想的な論理ボリュームのデータを所定のプール以外の他のプールに移動させる、第１のデータ移動方法を含めてもよい。
【００２０】
データ移動方法には、所定の記憶制御装置が仮想的な論理ボリュームのデータを所定のプール以外の他のプールに移動させる、第２データ移動方法を含めてもよい。
【００２１】
本発明は、コンピュータプログラムまたはコンピュータプログラムを記録する記録媒体として把握することもできる。さらに、本発明は、上述した各観点の組合せに限らず、それら以外の組合せを含むことができる。
【図面の簡単な説明】
【００２２】
【図１】図１は、本実施例に係る計算機システムの全体構成図。
【図２】図２は、プールサイズの拡張方法を模式的に示す図。
【図３】図３は、ホストが使用する仮想ボリュームの情報を示す図。
【図４】図４は、ストレージの情報を示す図。
【図５】図５は、プールの情報を示す図。
【図６】図６は、未使用ボリュームの情報を示す図。
【図７】図７は、管理ポリシーの情報を示す図。
【図８】図８は、プールの使用率を監視する処理のフローチャート。
【図９】図９は、プールサイズを拡張する処理のフローチャート。
【図１０】図１０は、自ストレージ内でプールサイズを拡張する処理を示すフローチャート。
【図１１】図１１は、仮想ボリュームを移動させる処理のフローチャート。
【図１２】図１２は、他ストレージを用いてプールサイズを拡張する処理を示すフローチャート。
【図１３】図１３は、他のプールで使用されているボリュームを流用して、プールサイズを拡張する処理を示すフローチャート。
【図１４】図１４は、仮想ボリュームにプール内の実記憶領域を割り当てる様子と、ホスト計算機が仮想ボリュームを移動させた場合に得られる効果とを示す模式図。
【発明を実施するための形態】
【００２３】
以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態では、後述のように、プールのサイズが不足した場合に、その容量不足を解消するための対処法を選択する方法を提示する。
【００２４】
対処法は、例えば、以下の観点に基づいて選択してもよい。
【００２５】
（観点１）異種のホスト計算機及び異種のストレージが混在する環境を考慮
計算機システムに含まれる各ホスト計算機及び各ストレージが有する、対処機能（例えば、プールを拡張する機能、および、仮想ボリュームを移動させる機能）は、同一であるとは限らない。従って、対処機能の有無と前提条件とを管理計算機が把握した上で、対処法を選択する。
【００２６】
（観点２）対処の緊急性と対処に要する時間とに関する考慮
所要時間の長い対処法を選択して実施した場合に起こり得るリスクを低減する。リスクとは、プールサイズの拡張が間に合わず、プールサイズが枯渇することである。例えば、アプリケーションプログラムの稼働していない期間中に、仮想ボリュームを他のプールに移動させる、という対処法を選択する場合には、注意が必要であろう。仮想ボリュームの移動が完了する前にアプリケーションプログラムが稼働を開始した場合、プールサイズが枯渇する可能性があるかも知れない。一方、所要時間が短ければ短いほど良い対処法である、とは必ずしも言えない。必要以上に所要時間の短い対処法を選択すると、対処法を選択する自由度が低下し、使い勝手に影響を与えるかも知れない。
【００２７】
（観点３）プール使用率の適正化に関する考慮
ある対策を実施しても、プールの使用率が高いままでは、容量不足は解消しない。つまり、プールの使用率低下に有効な対処法を実施する必要がある。しかし、プール使用率を必要以上に低下させる運用は、記憶サイズの浪費を招くであろう。
【００２８】
（観点４）ボリュームおよびプールの属性に関する考慮
仮想ボリューム、実ボリューム（論理ボリューム）、プールには、それぞれの構成または目的等に応じた属性（例えば、性能、価格、所属部門等）を有する。それらの属性を無視して、仮想ボリュームを他のプールに移動させたり、プールに実ボリュームを自由に追加したりすると、使い勝手等が低下するかも知れない。例えば、高速応答を要求される仮想ボリュームを応答性能の低いプールに移動させたり、高い信頼性を要求される仮想ボリュームを信頼性の低いプールに移動させるような場合である。さらに、例えば、高速な論理ボリュームから構成されるプールに低速な論理ボリュームを追加すると、そのプールの応答性能が低下する。そこで、仮想ボリューム、論理ボリューム及びプールに、属性ラベル（後述の実施例では「区分」と呼ぶ）を設定し、属性ラベルが適合するように、対処法を選択する。
【００２９】
（観点５）対処法の実行前後の性能変化に関する考慮
対処法を実行すると、仮想ボリュームの性能、または、プールの性能が変化する。対処法の実行前後で、仮想ボリュームの性能またはプールの性能が許容範囲以下に低下しないように、対処法の選択時に考慮する。
【実施例１】
【００３０】
以下、図面に従い、発明を実施するための形態について述べる。図１は、本実施例に係る計算機システムの全体構成図である。計算機システムは、例えば、少なくとも一つの管理端末１０と、少なくとも一つの管理計算機２０と、複数のストレージ３０と、少なくとも一つのホスト計算機４０と、管理用ネットワーク５１と、ストレージネットワーク５２とを含む。
【００３１】
管理端末１０と、管理計算機２０と、各ストレージ３０及びホスト計算機４０は、管理用ネットワーク５１によって双方向通信可能に結ばれている。さらに、管理計算機２０と、各ストレージ３０及びホスト計算機４０は、ストレージネットワーク５２によって双方向通信可能に接続されている。
【００３２】
管理用ネットワーク５１及びストレージネットワーク５２は通信回線であり、各情報処理装置間でデータを送受信するための通信経路である。なお、図１では、管理用ネットワーク５１とストレージネットワーク５２を別の通信回線として示すが、両方のネットワーク５１，５２を共通の通信回線として構成してもよい。
【００３３】
管理端末１０は、情報処理装置であり、例えば、メモリ１１と、マイクロプロセッサ（図中、ＣＰＵ）１２と、ディスプレイ装置１３と、キーボード１４と、マウス１５と、ホストインターフェース（以下、インターフェースをＩ／Ｆと表示）１６とを備える。
【００３４】
メモリ１１は、データ及びコンピュータプログラムを記憶する。マイクロプロセッサ（以下、プロセッサ）１２は、メモリ１１からコンピュータプログラムを読み込んで実行する。ディスプレイ装置１３は、データ等を表示する。キーボード１４は、ユーザからの文字による入力を受け付ける。マウス１５は、ディスプレイ装置に表示された画面上の任意の地点を指し示すために使用される。ホストＩ／Ｆ１６は、管理用ネットワーク５１を介して、管理計算機２０とデータを送受信する。なお、ユーザインターフェースとしては、ディスプレイ装置、キーボード、マウスに限らず、例えば、音声による指示装置、脳波による指示装置等を用いることもできる。
【００３５】
メモリ１１には、コンソールプログラム１１１が格納されている。プロセッサ１２がコンソールプログラム１１１を実行することにより、ホストＩ／Ｆ１６及び管理用ネットワーク５１を介して管理計算機２０とデータを交換する機能と、ディスプレイ装置１３に情報を表示させる機能と、キーボード１４及びマウス１５を介してユーザからの入力を受け付ける機能とが実現される。
【００３６】
管理端末１０は、ストレージの運用及び管理に携わるユーザ（ストレージ管理者）が、ストレージ３０を運用したり、管理したりするための窓口として用いられる。
【００３７】
管理計算機２０は、情報処理装置であり、例えば、メモリ２１と、プロセッサ２２と、ＳＡＮ Ｉ／Ｆ２３と、ホストＩ／Ｆ２４とを備える。
【００３８】
メモリ２１は、データやコンピュータプログラムを記憶する。プロセッサ２２は、メモリ２１からコンピュータプログラムを読み込み、実行する。これにより、後述する各機能が実現される。ＳＡＮ Ｉ／Ｆ２３は、ストレージネットワーク５２を経由して各ストレージ３０に操作指示または情報照会等を行なうための回路である。ホストＩ／Ｆ２４は、管理用ネットワーク５１を介して、他の情報処理装置１０，３０，４０とデータ通信するための回路である。
【００３９】
管理サーバプログラム２１１は、各ストレージ３０を管理するためのコンピュータプログラムであり、メモリ２１に格納されている。ホスト−ボリューム情報２１２は、ホスト計算機４０上で使用される仮想ボリュームの構成及び利用状況等を管理するための情報である。ストレージ情報２１３は、各ストレージ３０が搭載している機能を管理するための情報である。プール情報２１４は、各プールの構成及び使用状況等を管理するための情報である。未使用ボリューム情報２１５は、各ストレージ３０内の未使用ボリュームに関する情報である。管理ポリシー情報２１６は、管理サーバプログラム２１１の動作を定義する情報である。
【００４０】
ホスト−ボリューム情報２１２、ストレージ情報２１３、プール情報２１４、未使用ボリューム情報２１５及び管理ポリシー情報２１６は、メモリ２１に格納される。それら情報２１２，２１３，２１４，２１５，２１６の詳細については後述する。
【００４１】
なお、図１には、管理計算機２０とホスト計算機４０とを別々に構成する場合を示しているが、これに代えて、ホスト計算機４０に管理計算機の機能を実現させてもよい。例えば、複数のホスト計算機４０のうち少なくとも一つのホスト計算機４０に、管理計算機２０の有するコンピュータプログラム２１１及び各種管理情報２１２−２１６を設ける構成としてもよい。
【００４２】
「記憶制御装置」としての各ストレージ３０は、情報を記憶するための装置である。各ストレージ３０は、例えば、ストレージコントローラ３１と、ディスクユニット３２とを備える。
【００４３】
ストレージコントローラ３１は、ホストＩ／Ｆ３１１と、ＳＡＮ Ｉ／Ｆ３１２と、マイクロプロセッサ３１３と、メモリ３１４と、ディスクコントローラ３１５を備える。ホスト Ｉ／Ｆ３１１は、管理用ネットワーク５１に接続するための回路である。ＳＡＮ Ｉ／Ｆ３１２は、ストレージネットワーク５２に接続するための回路である。
【００４４】
メモリ３１４には、例えば、入出力処理プログラム（図中、Ｉ／Ｏプログラム）３１４１と、ボリューム移行プログラム（図中、マイグレーションプログラム）３１４２と、シンプロビジョニングプログラム３１４３とが記憶される。マイクロプロセッサ３１３は、それらコンピュータプログラム３１４１，３１４２，３１４３を読み込んで実行する。ディスクコントローラ３１５は、ディスクドライブ３２１に対するデータの読み書きを制御する。
【００４５】
ディスクユニット３２は、複数のディスクドライブ３２１を備える。各ディスクドライブ３２１がそれぞれ有する物理的記憶領域をグループ化し、そのグループ化された物理的記憶領域に複数の論理的記憶領域を設定することができる。その論理的な記憶領域を論理ボリューム３２２と呼ぶ。
【００４６】
ディスクドライブとしては、例えば、ハードディスクドライブ、半導体メモリドライブ、光ディスクドライブ、光磁気ディスクドライブ等のデータを読み書き可能な種々のデバイスを利用可能である。
【００４７】
ハードディスクドライブを用いる場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスク、ＳＡＴＡディスク、ＡＴＡ（AT Attachment）ディスク、ＳＡＳ（Serial Attached SCSI）ディスク等を用いることができる。また、例えば、フラッシュメモリ、ＦｅＲＡＭ（Ferroelectric Random Access Memory）、ＭＲＡＭ（MagnetoresistiveRandom Access
Memory）、相変化メモリ（Ovonic Unified Memory）、ＲＲＡＭ（Resistance RAM）」等の種々の記憶装置を用いることもできる。
【００４８】
入出力処理プログラム３１４１は、管理計算機２０からの要求に応じて論理ボリュームを定義する。さらに、入出力処理プログラム３１４１は、ホスト計算機４０からの求めに応じて、論理ボリューム及び仮想ボリュームに対してデータを読み書きする。
【００４９】
ボリューム移行プログラム３１４２は、管理計算機２０からの指示に応じて、仮想ボリュームを他のプールに移行させる。仮想ボリュームとプールに関する説明は、図２で後述する。
【００５０】
シンプロビジョニングプログラム３１４３は、例えば、プールの構成管理、プールの稼動管理、仮想ボリュームの構成管理、仮想ボリュームの稼動管理、データ読み書き機能等を提供する。
【００５１】
ホスト計算機４０は、情報処理装置であり、例えば、ＳＡＮ Ｉ／Ｆ４１と、ホストＩ／Ｆ４２と、プロセッサ４３と、メモリ４０を備える。
【００５２】
ＳＡＮ Ｉ／Ｆ４１は、ストレージネットワーク５２を経由して、各ストレージ３０とデータ通信するための回路である。ホストＩ／Ｆ４２は、管理用ネットワーク５１を介して、管理計算機２０とデータ通信するための回路である。
【００５３】
メモリ４４には、例えば、管理エージェントプログラム４４１と、マイグレーションプログラム（ボリューム移行プログラムとも呼ぶ）４４２と、アプリケーションプログラム４４３と、ＯＳ（オペレーティングシステム）４４４とが記憶されている。プロセッサ４３は、各コンピュータプログラム４４１，４４２，４４３を読み込んで実行する。
【００５４】
管理エージェントプログラム４４１は、管理サーバプログラム２１１からの指示に基づいて、ボリューム移行プログラム４４２を実行させる。
【００５５】
ボリューム移行プログラム４４２は、論理ボリュームまたは仮想ボリュームのデータを、他の論理ボリュームまたは他の仮想ボリュームに移すプログラムである。
【００５６】
アプリケーションプログラム４４３は、ホスト計算機４０で業務処理を実行するためのプログラムである。
【００５７】
ＯＳ４４４は、管理エージェントプログラム４４１及びアプリケーションプログラム４４３の実行基盤となる基本ソフトウェアである。
【００５８】
図２は、シンプロビジョニング技術を用いた情報処理システムの論理的な構成、及び、プール容量不足時の対処法を示す概念図である。
【００５９】
まず最初に、シンプロビジョニング技術におけるプールと仮想ボリュームとについて説明する。ストレージ３０（１）は「ＤＫＣ−Ａ」という識別名で特定されるストレージである。ストレージ３０（１）の内部には、「ＰＯＯＬ−Ａ」という識別名で特定されるプール６１１が含まれる。
【００６０】
プール６１１は、複数の論理ボリューム６２１，６２２，６２３を含む。プール６１１には、「ＶＶＯＬ−Ａ」という識別名で特定される仮想ボリューム６３１と、「ＶＶＯＬ−Ｂ」という識別名で特定される仮想ボリューム６３２とが所属している。
【００６１】
仮想ボリューム６３１は、ホスト計算機４０（１）上において、「ＶＯＬ−Ａ」という識別名で特定されるボリューム６５１となっている。ボリューム６５１は、「ＡＰ−Ａ」という識別名で特定されるアプリケーションプログラム４４３（１）から利用される。このような構成において、アプリケーションプログラム４４３（１）がボリューム６５１にデータを書き込むと、以下の処理が行われる。
【００６２】
ボリューム６５１に対する書き込み要求を受けたＯＳ４４４は、ストレージ３０（１）に、ボリューム６５１に対応する仮想ボリューム６３１への書き込み要求を発行する。その書き込み要求を受けたストレージ３０（１）内の入出力処理プログラム３１４１は、シンプロビジョニングプログラム３１４３に、書き込み要求があった旨を通知する。シンプロビジョニングプログラム３１４３は、その通知を受けると、仮想ボリューム６３１の全記憶領域のうち書き込み対象の記憶領域（仮想ページ）に、プール６１１内の記憶領域（実ページまたはチャンク）を割り当て済みか否かを判定する。
【００６３】
シンプロビジョニングプログラム３１４３は、書き込み対象の仮想ページに実ページが未割り当てであると判定した場合、プール６１１を構成する各論理ボリュームの有する実記憶領域の中から実ページを選択して、書き込み対象の仮想ページに割り当てる。
、仮想ページに割り当てられた実ページには、アプリケーションプログラム４４３（１）からのデータが書き込まれる。書き込み対象の仮想ページに実ページが既に割り当てられている場合、その割り当て済みの実ページに、アプリケーションプログラム４４３（１）から書き込まれるデータを保存する。
【００６４】
以上の処理は、プール６１１を共有する仮想ボリューム６３２と、それを利用するボリューム６５２、さらには、アプリケーションプログラム４４３（２）についても同様に行われる。仮想ボリューム６３１に割り当てられた実ページの総数と仮想ボリューム６３２に割り当てられてた実ページの総数との合計に対応する量の記憶領域（実記憶領域）が、プール６１１から使用されることになる。
【００６５】
次に、プールサイズが不足した場合の対処法について述べる。例えば、ストレージ３０（２）内のプール６１２が容量不足になった場合の対処法としては、以下に述べる五つを挙げることができる。
【００６６】
第一の対処法は、同一ストレージ３０（２）内の未使用ボリューム６４２を使用してプール６１２を拡張をすることである（図２の矢印６９１）。ストレージ３０（２）内に未使用ボリューム６４２が存在する場合、そのボリューム６４２をプール６１２に追加することにより、プール６１２のサイズを拡張することができる。
【００６７】
第二の対処法は、他のストレージ３０（４）内の未使用ボリューム６４３を使用してプール６１２を拡張することである（図２の矢印６９２）。第二の対処法が利用できる条件は、他のストレージ３０（４）に未使用ボリューム６４３が存在すること、及び、他のストレージ３０（４）内のボリュームにストレージ３０（２）がアクセスする機能を有することである。
【００６８】
一方のストレージ３０（２）が他方のストレージ３０（４）内のボリューム６４３にアクセスする機能を、外部接続機能と呼ぶことができる。一方のストレージ３０（２）から見ると、他方のストレージ３０（４）は一方のストレージ３０（２）の外部に存在する外部ストレージである。他方のストレージ３０（４）内のボリューム６４３は、一方のストレージ３０（１）の外部に存在する外部ボリュームである。一方のストレージ３０（１）内に外部ボリューム６４３と接続するための仮想的なボリューム６２５を設ける。その接続用のボリューム６２５は、外部接続ボリュームと呼ぶことができる。外部接続ボリューム６２５をプール６１２に追加して、プール６１２のサイズを拡張できる。
【００６９】
外部ボリューム６４３と外部接続ボリューム６２５とを接続する場合は、外部ボリューム６４３と外部接続ボリューム６２５との接続関係を定義する接続テーブルを設ける。接続テーブルとは、簡単に言えば、外部接続ボリューム６２５の記憶空間と外部ボリューム６４３の記憶空間との対応関係を示すマッピングテーブルである。
【００７０】
一方のストレージ３０（２）は、ホスト計算機からコマンドを受信すると、マッピングテーブルを用いて、そのコマンドを他方のストレージ３０（４）に送信するためのコマンドに変換する。一方のストレージ３０（２）は、変換されたコマンドを他方のストレージ３０（４）に送信する。一方のストレージ３０（２）は、他方のストレージ３０（４）からの応答に基づいて、ホスト計算機に応答する。
【００７１】
第三の対処法は、他のストレージ３０（４）内のプール６１４を構成する論理ボリューム６２７を流用してプール６１２拡張することである（図２の矢印６９３）。第三の対処法が利用できる条件は、第二の対処法の条件に加え、他ストレージ３０（４）内のプール６１４から論理ボリューム６２７を取り外すことが可能であることである。
【００７２】
第四の対処法は、ストレージ３０（２）の機能を利用して他のストレージ３０（３）内のプール６１３に仮想ボリューム６３４を移行させることである（図２の矢印６９４）。第四の対処法が利用できる条件は、ストレージ３０（２）が他ストレージ３０（３）に仮想ボリューム６３４を移行させる機能を有すること、及び、仮想ボリューム６３４を収容するだけの容量的な余裕が移行先プール６１３にあることである。仮想ボリューム６３４を他のプール６１３に移行させるとは、仮想ボリューム６３４を他のプール６１３の記憶領域に対応付けるという意味である。
【００７３】
なお、仮想ボリューム６３４を他のプール６９３に移行させる機能を実行するにあたって、アプリケーションプログラム４４３（３）が稼働していないこと（非稼働中）が前提条件となる場合がある。その場合は、第四の対処法を利用する条件に、その前提条件も含まれる。
【００７４】
第五の対処法は、ホスト計算機４０（２）の機能を利用して他のストレージ３０（１）内のプール６１１に仮想ボリュームを移行させることである（図２の矢印６９５）。第五の対処法が利用できる条件は、ホスト計算機４０（２）がストレージ３０（２）から他ストレージ３０（３）に、仮想ボリューム６３３（移行後の仮想ボリューム６３２）を移行させる機能を有すること、及び、仮想ボリューム６３３を収容するだけの容量的な余裕が移行先プール６１１にあることである。
【００７５】
なお、第四の対処法と同様に、仮想ボリューム６３３を他のプール６１１に移行させる機能の実行に際して、アプリケーションプログラム４４３（２）の停止（非稼動）を前提条件とする場合は、その前提条件も満たす必要がある。
【００７６】
なお、ストレージ３０（２）内に複数のプールが存在する場合、ストレージ３０（２）内の一方のプールからストレージ３０（２）内の他のプールに、仮想ボリュームを移行させることもできる。さらに、ストレージ３０（２）内の他のプールを構成する論理ボリュームを取り外して、一方のプールに追加することもできる。
【００７７】
次に、管理サーバプログラム２１１により使用される各種情報と、管理サーバプログラム２１１により実行される処理について説明する。以下、選択された対処法を管理サーバプログラム２１１が自動的に実行する場合を説明する。これに代えて、管理サーバプログラム２１１は、選択された対処法をユーザに提示するに止める構成でもよい。ユーザが、提示された対処法を承認した場合、その対処法が実行される。
【００７８】
図３は、管理サーバプログラム２１１により使用されるホスト−ボリューム情報２１２のデータ構造及びデータ例を示す。ホスト−ボリューム情報２１２は、仮想ボリューム単位に情報を保持する。その属性情報は、仮想ボリューム番号（図中、ＶＶＯＬ＃）２１２１、アプリケーションプログラム番号（図中、ＡＰ＃）２１２２、所属プール番号（図中、ＰＯＯＬ番号）２１２３、使用サイズ２１２４、アプリケーションプログラム稼動期間２１２５、ボリューム移行機能（図中、マイグレーション機能）２１２６、及び、コスト区分２１２７である。
【００７９】
以下の説明において、名前、識別子、識別情報、番号は、それぞれ対象物を他の対象物と区別するために使用される情報であり、相互に変換可能である。例えば、仮想ボリューム番号は仮想ボリューム識別子または仮想ボリューム名と呼び変えることができる。さらに、各テーブルの構成は図示の例に限られない。例えば、複数のテーブルをリンクさせることにより、本実施例で必要な情報を管理することもできる。
【００８０】
次に、ホスト−ボリューム情報２１２の各属性を説明する。仮想ボリューム番号２１２１は、仮想ボリュームの識別名を保持する。アプリケーションプログラム番号２１２２は、仮想ボリュームを使用するアプリケーションプログラム４４３の識別名を保持する。所属プール番号２１２３は、仮想ボリュームが所属するプールの識別名を保持する。使用サイズ２１２４は、仮想ボリュームの全ボリュームサイズのうち実際に使用されているサイズ、言い換えるとプール内のページが割り当てられているサイズを保持する。
【００８１】
アプリケーションプログラム稼動期間２１２５は、仮想ボリュームを使用するアプリケーションプログラム４４３の稼動期間を保持する。ボリューム移行機能２１２６は、仮想ボリュームを使用するホスト計算機４０上でボリューム移行が可能か否かを示す。可能な場合は、アプリケーションプログラム４４３の稼動中に移行できるか否かも示す。図３の例で「Ｉ／Ｏ無停止」となっているのは、アプリケーションプログラム４４３の稼動中に、仮想ボリュームの移行が可能なことを示している。
【００８２】
コスト区分２１２７は、仮想ボリュームの所属するプールのコスト区分を示す。コスト区分は識別名である。コスト区分は、プールを構成する各論理ボリュームのグレードまたは所属先の部門を区別するために設定される。
【００８３】
グレードは、例えば、論理ボリュームの価格帯などによって分けられる。例えば「Ａ」は高価格帯のボリュームを示し、「Ｂ」は中価格帯のボリュームを示し、「Ｃ」は低価格帯のボリュームを示す。コスト区分「Ａ」の設定されているプールは、高価格帯のボリュームのみから構成される。コスト区分「Ａ，Ｂ」の設定されているプールは、高価格帯ボリュームまたは／及び中価格帯ボリュームから構成される。高価格帯ボリュームを高信頼性ボリュームと、中価格帯ボリュームを中信頼性ボリュームと、低価格帯ボリュームを低信頼性ボリュームと、呼び変えることもできる。高信頼性ボリュームは、高信頼性のディスクドライブから構成される。中信頼性ボリュームは、中信頼性のディスクドライブから構成される。低信頼性ボリュームは、低信頼性のディスクドライブから構成される。
【００８４】
所属先の部門は、プールを構成する各論理ボリュームを部門別に割り当てる場合に使用される。部門Ａには「Ａ」、部門Ｂには「Ｂ」、部門Ｃには「Ｃ」と設定される。コスト区分は、仮想ボリューム及びプールの、性質または位置付けが変化するのを防止するために使用される。
【００８５】
コスト区分が適合しているか否かを判定することにより、例えば、高価格帯の各論理ボリュームから構成されるプールに対応付けられるべき重要な仮想ボリュームが、低価格帯の各論理ボリュームから構成されるプールに移行されてしまうのを防止できる。または、部門Ａで使用される仮想ボリュームが、部門Ｂの論理ボリュームで構成されているプールに移行されたりするのを防止できる。
【００８６】
コスト区分２１４４は、上述のように複数の区分を含んでも良い。複数区分が設定されている場合は、どちらも適用可能であることを示す。なお、ホスト−ボリューム情報２１２は、ストレージ３０内のシンプロビジョニングプログラム３１４３と、ホスト計算機４０上のアプリケーションプログラム４４３と、ボリューム移行プログラム４４２等から取得できる情報、及び、管理者からの入力される情報に基づいて作成できる。
【００８７】
図４は、管理サーバプログラム２１１により使用されるストレージ情報２１３のデータ構造及びデータ例を示す。ストレージ情報２１３は、ストレージ３０単位に情報を保持する。その属性情報は、ストレージ番号（図中、ストレージ＃）２１３１、ボリューム移行機能（図中、マイグレーション機能）２１３２、他ストレージ内のボリュームへのアクセス機能（図中、外部接続機能）２１３３である。
【００８８】
ストレージ番号２１３１は、ストレージ３０の識別名を保持する。ボリューム移行機能２１３２は、ストレージ３０がボリューム移行機能を持つか否かを保持する。移行機能を持つ場合は、アプリケーションプログラム４４３が停止中の場合のみ移行可能か否かも併せて示す。例えば、図４の例で「Ｉ／Ｏ停止」とあるのは、アプリケーションプログラム４４３が停止されており、Ｉ／Ｏ要求が発生しない場合のみ、ボリュームを移行可能であることを示している。なお、ストレージ情報２１３は、ストレージ３０内の入出力プログラム３１４１及びボリューム移行プログラム３１４２などから取得できる情報等に基づいて作成することができる。
【００８９】
図５は、管理サーバプログラム２１１により使用されるプール情報２１４のデータ構造及びデータ例を示す。プール情報２１４は、プール単位に情報を保持する。その属性情報は、プール番号（図中、プール＃）２１４１、プールサイズ２１４２、使用率２１４３、コスト区分２１４４である。
【００９０】
プール番号２１４１は、プールの識別名を保持する。プールサイズ２１４２は、プールの総サイズ、即ち、仮想ボリュームに割当可能な実ページの総サイズを保持する。使用率２１４３は、プールサイズ２１４２に占める、仮想ボリュームに割当済みのページサイズの割合を示す。全プールサイズを仮想ボリュームに割り当てた場合、使用率は１００%となる。
【００９１】
コスト区分２１４４は、ホスト−ボリューム情報２１２におけるコスト区分２１２７と同じ目的で付与されている。コスト区分２１４４は、プールを構成する論理ボリュームを区別するための識別名である。なお、プール情報２１４は、ストレージ３０内のシンプロビジョニングプログラム３１４３、及び、管理者から直接入力される情報等に基づいて作成すればよい。
【００９２】
図６は、管理サーバプログラム２１１により使用される未使用ボリューム情報２１５のデータ構造及びデータ列を示す。未使用ボリューム情報２１５は、未使用のボリューム単位に情報を保持する。その属性情報は、未使用ボリューム番号２１５１、ストレージ番号２１５２、サイズ２１５３、コスト区分２１５４である。
【００９３】
未使用ボリューム番号２１５１は、未使用ボリュームの識別名を保持する。ストレージ番号２１５２は、未使用ボリュームが存在するストレージの識別名を保持する。サイズ２１５３は、未使用ボリュームの記憶サイズを保持する。コスト区分２１５４は、未使用ボリュームのコスト区分を示す識別名を保持する。コスト区分２１５４は、複数の識別名を保持しても良い。なお、未使用ボリューム情報２１５は、ストレージ３０内のシンプロビジョニングプログラム３１４３と、ディスクコントローラ３１５から取得できる情報及び管理者から直接入力される情報等に基づいて作成すればよい。
【００９４】
図７は、管理サーバプログラム２１１により使用される管理ポリシー情報２１６のデータ構造及びデータ列を示す。管理ポリシー情報２１６は、管理ポリシー単位に情報を保持する。管理ポリシーとは、管理サーバプログラム２１１が各種管理操作を実行する上での指針を示す情報である。管理ポリシーは、例えば、プールサイズが不足した場合の対応方針を示す。
【００９５】
管理ポリシー情報２１６の属性は、ポリシー番号２１６１、適用対象２１６２、起動条件２１６３、アクション２１６４、成功条件２１６５である。ポリシー番号２１６１は、ポリシーの識別名を保持する。適用対象２１６２は、ポリシーの適用対象を保持する。図７の例で「全プール」となっている場合、全てのプールに同じポリシーを適用することを示している。適用対象として特定のプールの識別名が指定されている場合、ポリシーは、その特定されたプールのみに適用される。
【００９６】
起動条件２１６３は、特定のアクションを実行するきっかけとなる条件を保持する。図７の例では、起動条件を、プール使用率に関する条件として規定している。アクション２１６４は、アクションの種別を保持する。アクションの種別としては、「プールサイズ拡張」、「警告」等を挙げることができる。「プールサイズ拡張」は、例えば、プールサイズが不足した場合にプールサイズを拡張させることを意味する。「警告」とは、例えば、プールサイズが不足しそうな場合に、ユーザに警告を発することを意味する。
【００９７】
成功条件２１６５は、アクションの目的となる条件を保持する。図示の例では、プールの使用率を特定の範囲に収めることを、アクションの成功条件（目的）としている。なお、管理ポリシー情報２１６は、管理サーバプログラム２１１のベンダにより予め用意されている構成でもよいし、管理者が手動で作成できる構成でもよい。
【００９８】
図８は、プールの容量使用率を監視するための処理を示すフローチャートである。以下、ステップをＳと略記する。プールの容量使用率は、プールサイズの過不足を測る指標であり、その値が１００%に近いほどサイズが不足していることを示す。容量使用率の監視では、予め監視用の閾値を設定しておき、各プールの容量使用率がその閾値を超えた場合に、何らかのアクションを実行する。具体的な手順を以下に示す。以下の説明では、動作の主体を管理計算機として説明する。マイクロプロセッサ２２が管理サーバプログラム２１１を読み込んで実行することにより以下の機能が実現されるため、マイクロプロセッサ２２または管理サーバプログラム２１１を動作の主体として説明することもできる。
【００９９】
管理計算機２０は、プール情報２１４を参照し、先頭のプールを選択する（Ｓ８１０１）。管理計算機２０は、処理対象のプールを選択できたか否かを判定する（Ｓ８１０２）。もしも、選択するプールがなければ処理を終了する（Ｓ８１０２：ＮＯ）。選択するプールがあれば以下の処理を実行する。
【０１００】
管理計算機２０は、選択したプールの容量使用率を取得する（Ｓ８１０３）。管理計算機２０は、Ｓ８１０３で取得した容量使用率が管理ポリシー情報２１６で規定された閾値を超えたか否かをチェックする（Ｓ８１０４）。換言すれば、取得した容量使用率が起動条件２１６３に合致するか否かを判定する。
【０１０１】
もしも、容量使用率が閾値を超えた場合（Ｓ８１０４：ＹＥＳ）、管理計算機２０は、容量不足に対応すべく、プールサイズを拡張する処理を実施する（Ｓ８１０５）。プールサイズ拡張処理の詳細については、図９で後述する。
【０１０２】
処理対象プールの容量使用率が起動条件に一致しない場合（Ｓ８１０４：ＮＯ）、Ｓ８１０５をスキップする。
【０１０３】
管理計算機２０は、プール情報２１４から次のプールを新たな処理対象プールとして選択し（Ｓ８１０６）、Ｓ８１０２に戻る。プール情報２１４に登録されている全てのプールについて処理を完了して、選択可能なプールが無くなると（Ｓ８１０２：ＮＯ）、本処理は正常に終了する。
【０１０４】
図９は、プールサイズの不足に対応するために、プールサイズを拡張させる処理のフローチャートである。図９のフローチャートは、図８のＳ８１０５で実行される。本処理では、プールサイズが不足した場合の各対処法の妥当性を順番に評価し、妥当と評価された対処法を実行する。以下に具体的な手順を説明する。以下、処理対象のストレージ３０を自ストレージと呼び、処理対象ストレージ以外の他のストレージと区別する。
【０１０５】
最初に、管理計算機２０は、容量不足が発生したストレージ（自ストレージ）内でプール拡張が可能か否かを判定し、それが可能ならば実行する（Ｓ８２０１）。自ストレージ内でプールサイズを拡張する処理の詳細については、図１０で後述する。Ｓ８２０１の実行によって、プールの容量不足が解消した場合（Ｓ８２０２：ＹＥＳ）、本処理は終了する。
【０１０６】
Ｓ８２０１を実行してもプールの容量不足が解消しない場合（Ｓ８２０２：ＮＯ）、管理計算機２０は、自ストレージを除く他ストレージの一覧（他ストレージ一覧）を、ストレージ情報２１３に基づいて作成する（Ｓ８２０３）。なお、他ストレージ一覧をストレージ情報２１３と別に作成するのではなく、ストレージ情報２１３から他ストレージの情報を取得する構成でもよい。その場合、Ｓ８２０４及びＳ８２１１で、自ストレージを選択しないようにする。
【０１０７】
管理計算機２０は、他ストレージ一覧の先頭に記載される他ストレージを一つ選択する（Ｓ８２０４）。管理計算機２０は、処理対象の他ストレージを選択できたか否かを判定する（Ｓ８２０５）。他ストレージを選択できなかった場合（Ｓ８２０５：ＮＯ）、管理計算機２０は、プールの容量不足を解消するための方法が見つからない旨を示すアラートを発行して（Ｓ８２０６）、本処理を終了する。
【０１０８】
処理対象の他ストレージを選択できた場合（Ｓ８２０５：ＹＥＳ）、管理計算機２０は、仮想ボリュームの移行によるプールサイズの拡張という対処法の妥当性をチェックし、もしも妥当ならその対処法を実行する（Ｓ８２０７）。仮想ボリュームの移動によるプールサイズの拡張方法については、図１１で後述する。Ｓ８２０７を処理した結果、プールの容量不足が解消した場合は、本処理を終了する（Ｓ８２０８：ＹＥＳ）。
【０１０９】
仮想ボリュームを移動させることができない場合、または、仮想ボリュームを移動させてもプールの容量不足が解消しない場合のいずれかの場合（Ｓ８２０８：ＮＯ）、管理計算機２０は、他ストレージを用いたプールサイズの拡張という対処法の妥当性をチェックし、もしも妥当ならその対処法実行する（Ｓ８２０９）。Ｓ８２０９の詳細については、図１２で後述する。
【０１１０】
他ストレージを用いたプールサイズの拡張方法を実行した結果、プールの容量不足が解消した場合には、本処理を終了する（Ｓ８２１０：ＹＥＳ）。他ストレージを用いても、プールの容量不足を解消できない場合（Ｓ８２１０：ＮＯ）、管理計算機２０は、他ストレージ一覧から次の他ストレージを選択し（Ｓ８２１１）、Ｓ８２０５に戻る。
【０１１１】
図１０は、自ストレージ内でプールサイズを拡張する処理を示すフローチャートであり、図９のＳ８２０１で実行される。以下の処理では、自ストレージ内の各未使用ボリュームについて、そのサイズ、そのコスト、その性能の各観点で、プールサイズの拡張用ボリュームとして適切か否かの妥当性を評価する。妥当と評価された未使用ボリュームは、サイズの不足しているプールに追加され、そのプールのサイズを拡張させる。
【０１１２】
最初に、管理計算機２０は、自ストレージ内の未使用ボリュームの一覧（以下、拡張用の候補ボリューム一覧とも呼ぶ）を、未使用ボリューム情報２１５から作成する（Ｓ８３０１）。
【０１１３】
なお、候補ボリューム一覧を、未使用ボリューム情報２１５と別に作成するのではなく、未使用ボリューム情報２１５から候補ボリューム一覧を取得する構成でも良い。その場合、Ｓ８３０２及びＳ８３０７では、自ストレージ内の未使用ボリュームのみを選択するようにする。
【０１１４】
管理計算機２０は、候補ボリューム一覧から最初の未使用ボリュームを選択する（Ｓ８３０２）。選択可能な未使用ボリュームが無い場合（Ｓ８３０３：ＮＯ）は、対策未完として本処理を終了する。なお、選択可能な未使用ボリュームが見つからない場合（Ｓ８３０３：ＮＯ）、図１３で後述する処理（Ｓ８６００）を実施してもよい。
【０１１５】
管理計算機２０は、候補ボリューム一覧から未使用ボリュームを一つ選択できた場合（Ｓ８３０３：ＹＥＳ）、その未使用ボリュームのサイズが所定サイズであるか否かを判定する（Ｓ８３０４）。
【０１１６】
所定サイズとは、例えば、プールサイズの不足を解消するために必要なサイズである。具体的には、所定サイズとは、管理ポリシーの成功条件２１６５を満たすために必要なサイズを意味する。このように、未使用ボリュームのサイズが目的に合致するか否かは、管理ポリシー一覧２１６の内容に基づいて判断できる。
【０１１７】
例えば、容量使用率が７５％のプールには、図７に示すように、起動条件２１６３が「プール使用率７０〜８４％」のポリシーが適用される。そのポリシーのアクションに関する成功条件２１６５の内容は「プールの使用率を４０−６０％の範囲に低減すること」と規定されている。ここで、「４０％」という使用率の下限を設定する理由は、行き過ぎた対処を防ぐためである。現在のプールのサイズと容量使用率とから、目標とする容量使用率を得るために必要な追加サイズは次の（１）式によって求められる。
【０１１８】
（追加サイズ）＝（１÷目標とする容量使用率）×現在の容量使用率×現在のプールサイズ−現在のプールサイズ・・・（１）
【０１１９】
もしも、選択された未使用プールのサイズが１００ＴＢの場合、容量使用率７５％を４０％にするために必要な追加サイズは、上記（１）式より、（１÷０．４）×０．７５×１００−１００＝８７．５ＴＢとなる。同様に、容量使用率７５％を６０％にするために必要な追加サイズは、（１÷０．６）×０．７５×１００−１００＝２５ＴＢとなる。
【０１２０】
従って、プールの容量使用率を現在の７５％から、４０％〜６０％の範囲に収めるためには、２５ＴＢ〜８７．５ＴＢの範囲の追加サイズが必要となる。選択された未使用ボリュームのサイズが上記の範囲内であれば、そのボリュームを使用したプール拡張が妥当であると判断できる。
【０１２１】
選択された未使用ボリュームのサイズが所定サイズに合致しない場合（Ｓ８３０４：ＮＯ）、管理計算機２０は候補ボリューム一覧から次の未使用ボリュームを選択し（Ｓ８３０７）、Ｓ８３０３に移る。
【０１２２】
選択された未使用ボリュームのサイズが所定サイズに合致する場合（Ｓ８３０４：ＹＥＳ）、管理計算機２０は、その未使用ボリュームのコスト区分の妥当性を評価する（Ｓ８３０５）。図中では、便宜上、「コスト区分」を「コスト」と簡略化して示す。
【０１２３】
管理計算機２０は、具体的には、選択された未使用ボリュームに設定されているコスト区分の内容が（未使用ボリューム情報２１５のコスト区分２１５４の内容）が、割当先のプールに設定されているコスト区分の内容（プール情報２１４のコスト区分２１４４の内容）に含まれているか否かを判定する。
【０１２４】
例えば、図６に示すように、「ＵＶＯＬ−Ａ」の識別名を有する未使用ボリュームには、コスト区分２１５４として「Ａ」が設定されている。一方、図５に示すように、「ＰＯＯＬ−Ｂ」の識別名を有するプールには、コスト区分２１４４として「Ａ，Ｂ」が設定されている。この場合、未使用ボリュームのコスト区分「Ａ」は、プールのコスト区分「Ａ，Ｂ」に含まれているため、そのプール（ＰＯＯＬ−Ｂ）のコスト区分と未使用ボリュームのコスト区分とは適合する。
【０１２５】
未使用プールのコスト区分とプールのコスト区分とが適合しないと判定された場合（Ｓ８３０５：ＮＯ）、管理計算機２０は、Ｓ８３０７に移る。
【０１２６】
未使用ボリュームのコスト区分とプールのコスト区分とが適合する場合（Ｓ８３０５：ＹＥＳ）、管理計算機２０は、プールサイズを拡張した後の性能を予測して評価する（８３０６）。管理計算機２０は、選択された未使用ボリュームをプールに追加した場合、そのプールが所定値以上の性能を維持できるか否かを判定する。
【０１２７】
例えば、高速な論理ボリュームから構成されているプールに、低速な論理ボリュームを追加した場合、そのプールの平均応答性能は低下する。プールの応答性能が低下すると、そのプール内のページを使用する仮想ボリュームのＩ／Ｏ性能も低下する。
【０１２８】
仮想ボリュームの性能低下を防ぐためには、例えば、追加対象の未使用ボリュームを、現在使われている論理ボリュームの性能と同じかそれ以上の性能を有する論理ボリュームに限定すればよい。
【０１２９】
なお、未使用ボリュームをプールに追加することにより、そのプール内の各論理ボリュームに対するＩ／Ｏ処理の並列性が高まる。従って、低速の論理ボリュームを追加した場合でも、プールとしての平均性能は低下しないか、または、高まる可能性もある。Ｓ８３０６では、この点を考慮に加えても良い。
【０１３０】
さらに、Ｓ８３０６では、仮想ボリュームの性能低下の度合を推定し、その度合が許容範囲内の場合は、選択された未使用ボリュームをプールに追加する構成でもよい。
【０１３１】
ボリューム追加後に性能上の問題が生じないと予測される場合（Ｓ８３０６：ＹＥＳ）、管理計算機２０は、選択された未使用ボリュームを用いてプールのサイズ拡張を実施させ（Ｓ８３０８）、本処理を終了する。
【０１３２】
選択された未使用ボリュームをプールに追加すると、そのプールが所定値以上の性能を維持できないと予測される場合（Ｓ８３０６：ＮＯ）、管理計算機２０は、候補ボリューム一覧から次の未使用ボリュームを選択（Ｓ８３０７）し、Ｓ８３０３に戻る。
【０１３３】
なお、図１０の処理では、一つの未使用ボリュームをプールに追加するだけで、そのプールの容量不足に対処できる場合を説明している。しかし、一つの未使用ボリュームを追加する構成に限らず、複数の未使用ボリュームをプールに追加してプールの容量不足を解消する構成でも良い。
【０１３４】
その場合、例えば、Ｓ８３０４のサイズチェックでは、未使用ボリュームのサイズが上限値をオーバーする場合を除いて、追加目的に合致すると判定する。そして、Ｓ８３０５及びＳ８３０６それぞれのチェックを通る、未使用ボリュームのリストを作成し、そのリストから、合計サイズが所定サイズとなる複数の未使用ボリュームを抽出して、それら複数の未使用ボリュームをプールに追加する構成でも良い。
【０１３５】
さらに、Ｓ８３０４で所定サイズに満たないと判定された一つの未使用ボリュームを、プールに追加する構成でもよい。その場合、図１０に示す対処法以外に、複数の対処法（図１１，図１２）を併用することが前提となる。
【０１３６】
さらに、成功条件として定義されている目標使用率に達しない場合でも、未使用ボリュームを一つも追加しない場合よりは、プールの使用率を低下させることができる。従って、所定サイズに満たない未使用ボリュームであっても、プールに追加することにより、プールサイズが枯渇するリスクを軽減できる。
【０１３７】
さらに、自ストレージ内に複数のプールが存在する場合、容量不足となっている処理対象プール以外の他プール（自ストレージ内の他プール）で使用されている論理ボリュームを、処理対象プールに移すことで、容量不足に対処することも可能である。
【０１３８】
そのような対処法を図１０ではＳ８６００として示す。図１３を参照して、自ストレージ内の他プールを利用する対処法を説明する。
【０１３９】
図１０のフローチャートで対策未完として終了する前に、管理計算機２０は、自ストレージ内に存在する一つまたは複数の他プールについて、それらの他プールを構成する各論理ボリュームの一覧を作成する（Ｓ８６０１）。
【０１４０】
管理計算機２０は、他プールを構成するボリューム一覧の中から先頭のボリュームを選択する（Ｓ８６０２）。管理計算機２０は、選択されたボリュームが、処理対象のプール（容量不足となっている自プール）に流用可能か否か判断する（Ｓ８６０３）。
【０１４１】
流用可能か否かを判断するための一つの基準として、例えば、その論理ボリュームを他プールから取り外した場合でも、他プールの容量使用率が予め定めた基準以下となることを挙げることができる。この基準は、論理ボリュームを流用したことによって、流用元のプールが容量不足になることを防ぐために設けられる。
【０１４２】
他プール内の論理ボリュームを流用可能な場合（Ｓ８６０３：ＹＥＳ）、管理計算機２０は、図１０で述べたと同様の各判定を行う。管理計算機２０は、その論理ボリュームが所定サイズを有するか否かを判定する（Ｓ８６０４）。次に、管理計算機２０は、その論理ボリュームのコスト区分と流用先のプール（自プール）のコスト区分とが適合するか否かを判定する（Ｓ８６０５）。次に、管理計算機２０は、自プールが所定値以上の性能を有するか否か予測する（Ｓ８６０６）。
【０１４３】
さらに、管理計算機２０は、他プールから論理ボリュームを取り外すと、他プールの性能が低下する可能性がある点と、論理ボリュームの取り外しに時間を要する点を考慮することができる（Ｓ８６０７）。
【０１４４】
他プールから論理ボリュームを一つ取り外すと、他プールを構成する論理ボリュームの数が少なくなるため、他プールにおけるＩ／Ｏ処理の並列性が低下する。従って、他プールの応答性能が低下する可能性がある。他プールから論理ボリュームを取り外す場合、その論理ボリュームに記憶されているデータを、他プール内の別の論理ボリュームにコピーして移動させる必要がある。従って、流用対象の論理ボリュームに記憶されているデータの量によっては、データコピー時間が長くなる可能性がある。この観点から、記憶されているデータ量の多い論理ボリュームは、流用できないボリュームであると判定する構成としてもよい。
【０１４５】
なお、流用可能な論理ボリュームが複数存在する場合は、例えば、流用元プールの容量使用率、論理ボリュームのサイズの少なさ、取り外しに要する時間の短さ、性能低下の少なさ、などの基準に従って、いずれか一つの論理ボリュームを選択すればよい。
【０１４６】
各判断ステップを満たさない場合、管理計算機２０は、次のボリュームを選択して（Ｓ８６０８）、Ｓ８６０３に戻る。各判断ステップを全て満たす場合、管理計算機２０は、他プール内の論理ボリュームを他プールから取り外して、容量不足状態の自プールに追加させる（Ｓ８６０９）。図１１に戻る。
【０１４７】
図１１は、仮想ボリュームの移動によりプールの容量不足を解消する処理を示すフローチャートであり、図９のＳ８２０７で実行される。本処理では、容量不足のプールを利用している各仮想ボリュームについて、移行手段の有無、ボリュームサイズ、コスト区分の適合可否、移行完了時間、移行後の性能の各点で、評価する。他ストレージの他プールへの移動が妥当であると判断された仮想ボリュームは、他ストレージ内の他プールに移動される。以下に具体的な手順を示す。
【０１４８】
最初に、管理計算機２０は、容量不足のプールを利用している仮想ボリュームの一覧を作成する（Ｓ８４０１）。その仮想ボリュームの一覧は、移行候補となる仮想ボリュームの一覧を示すため、以下の説明では、移行候補仮想ボリューム一覧と呼ぶ。
【０１４９】
移行候補仮想ボリューム一覧は、仮想ボリューム情報２１２から作成すれば良い。または、移行候補仮想ボリューム一覧は、仮想ボリューム情報２１２と別に作成するのではなく、仮想ボリューム情報２１２から得ることもできる。その場合は、Ｓ８４０２及びＳ８４０９では、容量不足のプールに所属している仮想ボリュームの中から選択する。
【０１５０】
管理計算機２０は、移行候補仮想ボリューム一覧から最初の仮想ボリュームを選択する（Ｓ８４０２）。仮想ボリュームを選択できなかった場合（Ｓ８４０３：ＮＯ）、本処理は、対策未完として終了する。
【０１５１】
仮想ボリュームを一つ選択できた場合（Ｓ８４０３：ＹＥＳ）、管理計算機２０は、選択されている他ストレージ３０に、その仮想ボリュームを移動させる手段の有無を確認する（Ｓ８４０４）。ストレージ３０側で仮想ボリュームを移動させる手段と、ホスト計算機４０側で仮想ボリュームを移動させる手段とがある。
【０１５２】
ストレージ３０が仮想ボリュームを移動させる手段を備えているか否かは、ストレージ情報２１３のボリューム移行機能２１３２の内容で判断できる。ホスト計算機４０が仮想ボリュームを移動させる手段を備えているか否かは、仮想ボリューム情報２１２のボリューム移行機能２１２６の内容によって判断できる。
【０１５３】
管理計算機２０は、ストレージ側での仮想ボリューム移行手段の有無と、ホスト計算機側での仮想ボリュームの移行手段の有無とを確認し、仮想ボリュームを他ストレージへ移行させるための手段が少なくとも一つ存在するか否かを判定する（Ｓ８４０４）。
【０１５４】
仮想ボリュームを他ストレージへ移行させるための手段が一つも無い場合（Ｓ８４０４：ＮＯ）、管理計算機２０は、次の仮想ボリュームを選択して（Ｓ８４０９）、Ｓ８４０３に戻る。
【０１５５】
仮想ボリュームを他ストレージへ移動させる手段が少なくとも一つ存在する場合（Ｓ８４０９：ＹＥＳ）、管理計算機２０は、その仮想ボリュームのサイズが所定サイズであるか否かを判定する（Ｓ８４０５）。仮想ボリュームのサイズが、管理ポリシーの目的に合致するか否かは、管理ポリシー一覧２１６の内容によって判断することができる。
【０１５６】
例えば、容量使用率が７５％のプールには、図７に示すように、起動条件２１６３が「プール使用率７０〜８４％」のポリシーが適用される。そのポリシーのアクションに関する成功条件２１６５の内容は「プールの使用率を４０−６０％の範囲に低減すること」と規定されている。現在のプールのサイズと容量使用率とから、目標とする容量使用率を得るために必要な仮想ボリュームの移行サイズは、次の（２）式によって求められる。
【０１５７】
（移行サイズ）＝（現在の容量使用率−目標とする容量使用率）×プールサイズ・・・（２）
【０１５８】
もしも、プールのサイズが１００ＴＢの場合、容量使用率７５％を４０％に低下させるために必要な追加サイズは、（０．７５−０．４）×１００＝３５ＴＢとなる。同様に、容量使用率７５％を６０％に低下させるために必要な追加サイズは、（０．７５−０．６）×１００＝１５ＴＢとなる。
【０１５９】
従って、プールの容量使用率を４０％から６０％の範囲に収めるためには、１５ＴＢ〜３５ＴＢの範囲のボリュームサイズを持つ仮想ボリュームを、他ストレージの他プールへ移行させる必要がある。
【０１６０】
Ｓ８４０３で選択された仮想ボリュームのサイズが上記の範囲内であれば、その仮想ボリュームの移行は妥当であると判断できる。仮想ボリュームのサイズが所定サイズに合致しないと判断された場合（Ｓ８４０５：ＮＯ）、Ｓ８４０９に移る。
【０１６１】
仮想ボリュームのサイズが所定サイズに合致する場合（Ｓ８４０５：ＹＥＳ）、管理計算機２０は、その仮想ボリュームに設定されているコスト区分と、移行先の他プールに設定されているコスト区分とが適合するか否かを判定する（Ｓ８４０６）。
【０１６２】
具体的には、仮想ボリューム情報２１２のコスト区分２１５４の内容が、プール情報２１４のコスト区分２１４４の内容に含まれている場合、両者のコスト区分が適合すると判断できる。例えば、図３に示す、「ＶＶＯＬ−Ｂ」の識別名を有する仮想ボリュームを、図５に示す、「ＰＯＯＬ−Ａ」の識別名を有するプールに移動させることを評価する場合を説明する。図３に示すように、仮想ボリューム（ＶＶＯＬ−Ｂ）のコスト区分２１５４は「Ａ，Ｂ」である。図５に示すように、プール（ＰＯＯＬ−Ａ）のコスト区分２１４４には「Ａ」が設定されている。移行先のプールのコスト区分「Ａ」は、仮想ボリュームのコスト区分「Ａ，Ｂ」に含まれているため、管理計算機２０は、両者のコスト区分が適合すると判定する。仮想ボリュームのコスト区分と移行先プールのコスト区分とが適合しないと判断された場合は、Ｓ８４０９に進む。
【０１６３】
両者のコスト区分が適合すると判断された場合（Ｓ８４０６：ＹＥＳ）、管理計算機２０は、仮想ボリュームを他プールに移行させるために要する時間（移行所要時間）が、プールの容量不足の解消に間に合うか否かを判定する（Ｓ８４０７）。
【０１６４】
例えば、プールの容量使用率が急上昇した場合、プールの容量不足に至急対処する必要がある。プールの容量使用率が１００%になる前に、そのプールのサイズを拡張する必要がある。そのためには、プールの容量使用率が１００％に到達する日時（プールサイズが枯渇する日時）と、容量不足の対策が完了する日時（移行完了日時）とを、それぞれ推定する必要がある。
【０１６５】
プールサイズの枯渇日時は、例えば、プール容量使用率の過去の履歴から単位時間あたりの増加率を求め、その増加率に基づいて計算すればよい。移行完了日時は、例えば、（ａ）アプリケーションプログラム４４３が稼動中に仮想ボリュームを移行可能であるか否か、（ｂ）アプリケーションプログラム４４３の稼動期間、（ｃ）仮想ボリュームの移行所要処理時間、などの情報に基づいて計算すればよい。
【０１６６】
（ａ）は、ホスト計算機４０内のボリューム移行プログラム４４２については、仮想ボリューム情報２１２のボリューム移行機能２１２６を参照すれば、確認できる。ストレージ３０内のボリューム移行プログラム３１４２を使用する場合は、ストレージ情報２１３のボリューム移行機能２１３２を参照すれば確認できる。
【０１６７】
（ｂ）については、仮想ボリューム情報２１２のアプリケーションプログラム稼動期間２１２５を参照することで確認できる。
【０１６８】
（ｃ）については、仮想ボリュームのサイズとサイズあたりの仮想ボリューム移行時間との乗算で求められる。サイズあたりの仮想ボリューム移行時間は、例えば、予め設定される参考値に基づいて算出したり、または、過去の仮想ボリュームの移行に要した時間から選択したりできる。参考値は、各論理ボリュームの性能毎にそれぞれ用意される。
【０１６９】
移動完了日時の算出方法は、（ａ）の内容によって異なる。即ち、アプリケーションプログラム４４３を停止させずに仮想ボリュームの移動が可能である場合は、現在時刻に（ｃ）の移行所要時間を加えた時刻となる。
【０１７０】
これに対し、アプリケーションプログラム４４３の稼働中に仮想ボリュームを移動させることができな場合は、アプリケーションプログラム４４３の稼動終了時刻に、（ｃ）の移行所要時間を加えた時刻となる。
【０１７１】
なお、仮想ボリュームの移行所要時間が長い場合等には、業務開始時刻までに仮想ボリュームの移行が完了しない可能性が考えられる。そのような事態が発生するのを防止するために、例えば、（ａ）のアプリケーションプログラム４４３の稼働中に仮想ボリュームを移動させることができない場合であって、かつ、予測される移行完了日時がアプリケーションプログラム４４３の開始時刻以降となる場合は、その仮想ボリュームを移行させることはできない、と判断すればよい。
【０１７２】
なお、プールサイズの枯渇日時及び仮想ボリュームの移行完了日時は、いずれも推定値となるため、余裕を持って判断するのが好ましい。即ち、プールサイズの枯渇日時は、例えば、予測値よりも一定量早い時刻を採用する。移行完了日時は、予測値よりも一定量遅い時刻を採用する。これにより、予想よりも早くプールサイズが枯渇する事態、または、仮想ボリュームの移行が予想よりも遅く完了する事態、の発生を抑制できる。
【０１７３】
さらに、上記の代替案として、容量使用率の絶対値が所定の上限値よりも高い場合、あるいは、容量使用率の増加率が所定の増加率よりも高い場合など、比較的対応が急がれる場合には、対処完了までの処理時間が相対的に短い対処法（例えばプール拡張）を常に選択する構成としてもよい。
【０１７４】
なお、ホスト計算機４０内のボリューム移行プログラム４４２による仮想ボリュームの移行と、ストレージ３０内のボリューム移行プログラム３１４２による仮想ボリュームの移行との両方を実施できる場合は、何らかの方法によっていずれかを一つを選択する必要がある。
【０１７５】
その選択基準としては、例えば、処理完了までの時間の早さ、ホスト計算機４０の負荷の大きさ、ストレージ３０の負荷の大きさなどを挙げることができる。なお、図１４に示すように、ホスト計算機４０のボリューム移行プログラム４４２を用いる場合は、データ転送サイズを比較的少なくでき、かつ、不要なデータを除去できるかも知れないという効果を奏する。
【０１７６】
図１４を参照する。ファイルシステムは、サイズＳＺ１のデータＤ１，Ｄ２，Ｄ３をｎ個管理している。ファイルシステム上の使用サイズは、ＳＺ１×ｎとなる。それらのデータＤ１，Ｄ２，Ｄ３は、仮想ボリューム７２０にばらばらに書き込まれるとする。仮想ボリューム７２０には、各データＤ１，Ｄ２，Ｄ３を格納するために、ｎ個のチャンク（実ページ）Ｃ１，Ｃ２，Ｃ３が割り当てられる。チャンクのサイズをＳＺ２とする（ＳＺ２＞ＳＺ１）。従って、仮想ボリューム７２０へのページ割り当てサイズは、ＳＺ２×ｎとなる。
【０１７７】
ホスト計算機４０が仮想ボリュームを移動させる場合のデータ転送量はＳＺ１×ｎとなるのに対し、ストレージ３０が仮想ボリュームを移動させる場合のデータ転送量はＳＺ２×ｎとなり、後者の方が大きい。このため、図１４に示す例では、ストレージ３０が仮想ボリュームを移動させる場合、ホスト計算機４０が仮想ボリュームを移動させる場合に比べて、移行所要時間が長くなる。
【０１７８】
従って、ファイルシステム上の使用サイズ（ＳＺ１×ｎ）と仮想ボリュームへのページ割り当てサイズ（ＳＺ２×ｎ）との差異を、ボリューム移行手段を選択するための基準として用いても良い。
【０１７９】
さらに、ＯＳ４４４のファイルシステム７１０上でデータが削除されても、削除されたデータが不要データであることを、ストレージ３０が認識できない場合も考えられる。その場合、不要なデータのために、仮想ボリューム７２０にページ（チャンク）が割り当てられたままとなる。
【０１８０】
ホスト計算機４０内のボリューム移行プログラム４４２が、削除されたデータを除外してデータを移行させる仕組みを持つと仮定する。ボリューム移行プログラム４４２を用いて仮想ボリュームのデータを移行元プール７２０から移行先プール７２１に移行させると（図１４の矢印７５１，７５２）、移行先プール７２１には、削除された不要データが格納されない。従って、仮想ボリュームの移行前に比べて、プールの使用サイズを少なくできる。
【０１８１】
この現象を利用して、ファイルシステム７１０上の使用サイズと仮想ボリュームへのページ割り当てサイズの差（または比率）が一定以上になる場合，ホスト計算機４０内のボリューム移行プログラム４４２を優先して実行するようにしても良い。
【０１８２】
図１１に戻る。Ｓ８４０７を実行した結果、プールの容量不足状態が仮想ボリュームのデータ移行完了時刻まで待てないと判定された場合（Ｓ８４０７：ＮＯ）、Ｓ８４０９に進む。
【０１８３】
仮想ボリュームのデータ移行が完了するまで待つことができると判断された場合（Ｓ８４０７：ＹＥＳ）、管理計算機２０は、仮想ボリューム移行後における仮想ボリュームの性能を予測して評価する（Ｓ８４０８）。即ち、管理計算機２０は、移行後においても、仮想ボリュームの性能を維持できるか否か判断する。
【０１８４】
仮想ボリュームを自ストレージ内のプールから他ストレージのプールに移行させることによって、仮想ボリュームのＩ／Ｏ性能が低下する可能性がある。移行後に仮想ボリュームのＩ／Ｏ性能が低下するか否かについては、移行元プール及び移行先プールのそれぞれについて、プールを構成する論理ボリュームの性能、論理ボリュームの数、プールの負荷の大きさ、移行対象の仮想ボリュームのＩ／Ｏ量などを考慮して判断すればよい。仮想ボリュームの性能低下の度合が許容範囲内である場合は、特に問題無しとして、その移行を認めてもよい。
【０１８５】
Ｓ８４０８実行の結果、性能上の問題が無さそうであると判断された場合、選択された仮想ボリュームを、選択された他ストレージ３０に移行させ（Ｓ８４１０）、対策完として本処理を終了する。
【０１８６】
移行後に仮想ボリュームの性能が所定値以上低下するような場合（Ｓ８４０８：ＮＯ）、移行候補仮想ボリューム一覧から次の仮想ボリュームを選択し（Ｓ８４０９）、Ｓ８４０３に戻る。
【０１８７】
なお、図１１のフローチャートでは、一つの仮想ボリュームを移行させるだけで、移行元プールの容量を拡張する場合を示しているが、これに限らず、複数の仮想ボリュームを移動させる構成でもよい。その場合、例えば、Ｓ８４０５でのボリュームサイズのチェックでは、仮想ボリュームのサイズがオーバーする場合を除いて、プール容量不足を解消させる目的に合うものと判定する。Ｓ８４０４、Ｓ８４０６、Ｓ８４０７のそれぞれの判定に合格する複数の仮想ボリュームのリストを作成し、そのリストから、仮想ボリュームの合計サイズが必要なサイズ範囲になるように、複数の仮想ボリュームを抽出する。抽出された複数の仮想ボリュームを複数の他プールへ移行させる。
【０１８８】
なお、Ｓ８４０５で仮想ボリュームのサイズが所定サイズに達していない場合でも、その仮想ボリュームの移行を実施させる構成としても良い。その場合、複数の対処法を併用することになる。最終目標の容量使用率に達しなくても、仮想ボリュームの移行を実施しない場合と比べると、プールの容量使用率を低下させることができる。従って、プールサイズが枯渇するリスクを軽減できる。
【０１８９】
図１１のフローチャートでは詳しく述べていないが、他ストレージ内に複数のプールが存在する場合は、Ｓ８４０５からＳ８４０８までの各ステップを、他ストレージ内の各プールのそれぞれについて実施することになる。
【０１９０】
仮想ボリュームの移行に適したプールが複数ある場合は、例えば、移行先プールの容量使用率、移行時間の短さ、移行後の性能低下の少なさ、などによって移行先プールを一つ選択すればよい。
【０１９１】
なお、図１１のフローチャートでは図示を省略しているが、自ストレージ内に複数のプールが存在する場合への考慮を加えても良い。自ストレージ内に複数のプールが存在する場合、容量不足のプールから、空き容量の十分あるプールに、仮想ボリュームを移行させるという対処法も選択肢に含めることができる。その場合、図１１のフローチャートと同様に、例えば、他プールへ仮想ボリュームを移行させる手段の有無、仮想ボリュームのサイズが目的に合致するか、移行先プールのコスト区分と仮想ボリュームのコスト区分が適合するか、容量不足のプールは移行完了時刻まで待てるか、移行後の性能は維持されるか、などの評価を行えばよい。
【０１９２】
図１２は、他ストレージの有する論理ボリュームを利用して、自ストレージのプールのサイズ拡張を図る処理のフローチャートであり、図９のＳ８２０９で実行される。本処理では、以下に述べるように、選択された他ストレージのボリューム（外部ボリューム）に、自ストレージから接続可能か否かをチェックする。もしも接続可能であれば、選択された他ストレージ内の各ボリュームのうち未使用のボリュームについて、ボリュームサイズ、コスト区分、性能変化の各点で、プール拡張用のボリュームとして適切であるかの妥当性を評価する。妥当と評価された未使用の外部ボリュームが存在する場合、自ストレージからその未使用の外部ボリュームに接続し、その外部ボリュームを自ストレージ内のプールに割り当ててプールサイズを拡張する。
【０１９３】
最初に、管理計算機２０は、選択された他ストレージのボリュームに接続する機能（外部接続機能）を、自ストレージが有するか否かをチェックする（Ｓ８５０１）。このチェックのためには、ストレージ情報２１３の外部接続機能２１３３を参照すればよい。
【０１９４】
自ストレージが外部接続機能を備えていない場合（Ｓ８５０１：ＮＯ）、本処理は、対策未完として終了する。自ストレージが外部接続機能を有する場合（Ｓ８５０１：ＹＥＳ）、以下の処理が実施される。
【０１９５】
管理計算機２０は、選択された他ストレージ内の未使用ボリューム一覧（以下、候補ボリューム一覧）を、未使用ボリューム情報２１５から作成する（Ｓ８５０２）。なお、候補ボリューム一覧を、未使用ボリューム情報２１５と別に作成するのではなく、未使用ボリューム情報２１５から未使用の候補ボリュームの情報を読み出す構成でもよい。その場合、Ｓ８５０３及びＳ８５０８では、選択された他ストレージ内の未使用ボリュームのみを選択する。
【０１９６】
管理計算機２０は、候補ボリューム一覧から先頭の未使用ボリュームを一つ選択する（Ｓ８５０３）。管理計算機２０は、未使用ボリュームを選択できたか否かを判断する（Ｓ８５０４）。選択可能な未使用ボリュームが無い場合（Ｓ８５０４：ＮＯ）、対策未完として本処理を終了する。
【０１９７】
他ストレージ内の未使用ボリュームを選択できた場合（Ｓ８５０４：ＹＥＳ）、管理計算機２０は、その未使用ボリュームのサイズが所定サイズであるか否かを判定する（Ｓ８５０５）。つまり、選択された未使用ボリュームが、自ストレージ内のプールの容量不足を解消させるのに適切なサイズであるかを確認する。未使用ボリュームのサイズが所定サイズであるか否かは、管理ポリシー一覧２１６の内容によって判断すれば良い。その処理内容は、図１０のＳ８３０４と同じである。より詳しくは、管理計算機２０は、未使用ボリュームのサイズが目的達成に必要な範囲のサイズであるか否かを判定する。
【０１９８】
選択された未使用ボリュームのサイズが所定サイズではない場合（Ｓ８５０５：ＮＯ）、管理計算機２０は、候補ボリューム一覧から次の未使用ボリュームを選択し（Ｓ８５０８）、Ｓ８５０４に戻る。
【０１９９】
選択された未使用ボリュームのサイズが所定サイズの場合（Ｓ８５０５：ＹＥＳ）、管理計算機２０は、未使用ボリュームのコスト区分と割当先のプールのコスト区分とが適合するか否かを判断する（Ｓ８５０６）。その具体的な処理内容は、図１０のＳ８３０５と同じである。
【０２００】
未使用ボリュームのコスト区分とプールのコスト区分とが適合しない場合（Ｓ８５０６：ＮＯ）、Ｓ８５０８に移る。
【０２０１】
未使用ボリュームのコスト区分とプールのコスト区分とが適合する場合（Ｓ８５０６：ＹＥＳ）、管理計算機２０は、未使用ボリュームをプールに追加した場合の性能を評価する（Ｓ８５０７）。性能評価の方法は、図１０のＳ８３０６と同様である。
【０２０２】
しかし、Ｓ８５０７の場合は、外部接続機能を利用して、他ストレージ内の未使用ボリュームを自ストレージ内のプールに追加する。従って、自ストレージから他ストレージにアクセスする必要があり、オーバーヘッドが生じる。そのため、オーバーヘッド分の補正を実施すると良い。即ち、本処理では、オーバーヘッドを考慮して、プールの性能値の変化を予測する。例えば、予め固定値として設定されているオーバーヘッドの量を用いて、プール性能を予測することができる。あるいは、ストレージ３０の入出力処理プログラム３１４１に、オーバーヘッド量を測定させる機能を設け、それにより測定された値に基づいてプール性能を予測する構成でもよい。
【０２０３】
他ストレージ内の未使用ボリュームをプールに追加しても、そのプールの性能が維持されると判断された場合（Ｓ８５０７：ＹＥＳ）、選択された未使用ボリュームを用いてプールサイズを拡張する（Ｓ８５０９）。本処理は、対策完として終了する。プールの性能が許容値以上低下すると予測された場合（Ｓ８５０７：ＮＯ）、Ｓ８５０８に移る。
【０２０４】
なお、図１２のフローチャートでは、一つの未使用ボリュームをプールに追加するだけでプールの容量不足に対処する場合を説明した。これに代えて、複数の未使用ボリュームをプールに追加して、プールの容量不足に対処する構成でも良い。
【０２０５】
その場合、例えばＳ８５０５のサイズチェックでは、ボリュームサイズが所定サイズ（所定のサイズ範囲）を超える場合を除いて、目的に合うものと判定する。さらに、Ｓ８５０６及びＳ８５０７のそれぞれのチェックに合格する未使用ボリュームのリストを作成し、そのリストから、未使用ボリュームの合計サイズが必要なサイズ範囲になる複数の未使用ボリュームを抽出する。抽出された複数の未使用ボリュームをプールに追加することにより、プールサイズを拡張することもできる。
【０２０６】
なお、所定サイズに達しない未使用ボリュームを用いて、プールサイズを拡張する構成としても良い。その場合、複数の対処法を実施することになる。目標の容量使用率を実現するための未使用ボリュームが得られない場合でも、未使用ボリュームをプールに一つも追加しない場合に比べると、プールの容量使用率を下げることができる。従って、不十分なサイズの未使用ボリュームであっても、その未使用ボリュームをプールに追加することで、プールの容量が枯渇するリスクを軽減できる。
【０２０７】
図１２のフローチャートでは、他ストレージ内の未使用ボリュームを用いて、自ストレージのプールサイズ拡張について述べている。これに代えて、他プールに割り当てられている、使用済みの論理ボリュームを、自ストレージのプールのサイズ拡張用に流用する構成でもよい。
【０２０８】
そのために、図１３で述べたＳ８６００の処理を、Ｓ８５０４で「ＮＯ」と判定された後に実施すればよい。
【０２０９】
なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。
【符号の説明】
【０２１０】
１０：管理端末、２０：管理計算機、３０：ストレージ、４０：ホスト計算機
【特許請求の範囲】
【請求項１】
少なくとも一つの仮想的な論理ボリュームを生成する複数の記憶制御装置と、前記仮想的な論理ボリュームを使用する少なくとも一つのホスト計算機と、前記各記憶制御装置と前記ホスト計算機とを管理するための少なくとも一つの管理計算機とを含む計算機システムであって、
前記各記憶制御装置は、前記ホスト計算機からのライトアクセスに応じて、プール内の実ボリュームの有する実記憶領域を前記仮想的な論理ボリュームに割り当て、前記ホスト計算機から受信するライトデータを、割り当てられた前記実記憶領域に記憶させるようになっており、
前記管理計算機は、
マイクロプロセッサと、前記マイクロプロセッサにより読み込まれて実行される所定のコンピュータプログラムを記憶するメモリと、前記各記憶制御装置及び前記ホスト計算機と通信するための通信インターフェース部とを備えており、
前記マイクロプロセッサは、前記所定のコンピュータプログラムを読み込んで実行することにより、
前記各プールの使用状態を取得し、
取得された前記各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定し、
前記所定プールが検出された場合は、（Ａ）前記所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、（Ｂ）前記仮想的な論理ボリュームのデータを前記所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、
前記選択された方法に従って、前記所定プールのプールサイズを拡張させる、
計算機システム。
【請求項２】
（Ａ）前記ボリューム追加方法には、
（Ａ１）前記各記憶制御装置のうち前記所定プールの属する所定の記憶制御装置が有する、未使用の第１の実ボリュームを前記所定プールに追加させる、第１のボリューム追加方法と、
（Ａ２）前記各記憶制御装置のうち前記所定の記憶制御装置以外の他の記憶制御装置が有する、未使用の第２の実ボリュームを前記所定の記憶制御装置に接続することにより、前記第２の未使用の実ボリュームを前記所定プールに追加させる、第２のボリューム追加方法と、
（Ａ３）前記各記憶制御装置のうち前記所定の記憶制御装置の有する第１の他のプールに設けられている第３の実ボリュームを取り外し、その取り外された第３の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第３のボリューム追加方法と、
（Ａ４）前記所定の記憶制御装置以外の前記他の記憶制御装置が有する、第２の他のプールに設けられている第４の実ボリュームを取り外し、その取り外された第４の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第４のボリューム追加方法と、
が含まれており、
（Ｂ）前記データ移動方法には、
（Ｂ１）前記ホスト計算機が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第１のデータ移動方法と、
（Ｂ２）前記所定の記憶制御装置が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第２データ移動方法と、
が含まれており、
前記マイクロプロセッサは、
（Ｃ１）前記第１のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第１の実ボリュームが前記所定プールの使用率を所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている属性ラベルと、前記第１の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第１の実ボリュームを追加した場合でも前記所定プールの応答性能が所定のプール性能値以上となる場合に、前記第１のボリューム追加方法を実行し、
（Ｃ２）前記第２のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第２の実ボリュームが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている前記属性ラベルと、前記第２の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第２の実ボリュームを追加した場合でも前記所定プールの応答性能が前記所定のプール性能値以上となる場合に、前記第２のボリューム追加方法を実行し、
（Ｃ３）前記第３のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第３の実ボリュームが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている前記属性ラベルと、前記第３の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第３の実ボリュームを追加した場合でも前記所定プールの応答性能が前記所定値以上となり、かつ、前記第３の実ボリュームを前記第１の他のプールから取り外しても前記第１の他のプールの応答性能が他のプール性能値以上となる場合に、前記第３のボリューム追加方法を実行し、
（Ｃ４）前記第４のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第４の実ボリュームが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている前記属性ラベルと、前記第４の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第４の実ボリュームを追加した場合でも前記所定プールの応答性能が前記所定のプール性能値以上となる場合に、前記第４のボリューム追加方法を実行し、
（Ｃ５）前記第１のデータ移動方法を実行する場合の前記所定の選択基準として、前記ホスト計算機が前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための機能を有しており、かつ、前記仮想的な論理ボリュームのデータのサイズが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのサイズを有しており、かつ、前記仮想的な論理ボリュームに予め設定されている属性ラベルと、前記他のプールに予め設定されている属性ラベルとが適合し、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための時間が予め設定される所定時間よりも短く、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させた場合でも前記仮想的な論理ボリュームの応答性能が所定のボリューム性能値以上となる場合に、前記第１のデータ移動方法を実行し、
（Ｃ６）前記第２のデータ移動方法を実行する場合の前記所定の選択基準として、前記記憶制御装置が前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための機能を有しており、かつ、前記仮想的な論理ボリュームのデータのサイズが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのサイズを有しており、かつ、前記仮想的な論理ボリュームに予め設定されている属性ラベルと、前記他のプールに予め設定されている属性ラベルとが適合し、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための時間が予め設定される所定時間よりも短く、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させた場合でも前記仮想的な論理ボリュームの応答性能が所定のボリューム性能値以上となる場合に、前記第２のデータ移動方法を実行し、
さらに、（Ａ１）前記第１のボリューム追加方法、（Ａ２）前記第２のボリューム追加方法、（Ｂ１）前記第１のデータ移動方法、（Ｂ２）前記第２のデータ移動方法、（Ａ３）前記第３のボリューム追加方法、（Ａ４）前記第４のボリューム追加方法、の順番で優先順位が設定されており、
前記マイクロプロセッサは、前記優先順位に基づいて前記各方法を実行する、
請求項１に記載の計算機システム。
【請求項３】
前記マイクロプロセッサは、前記ボリューム追加方法と前記データ移動方法のいずれかを選択する場合に、前記仮想的な論理ボリュームを使用するアプリケーションプログラムの稼働状況を考慮して、所定時間内に前記所定プールのプールサイズの拡張が完了するか否かを判定する、
請求項１に記載の計算機システム。
【請求項４】
前記ボリューム追加方法には、
前記各記憶制御装置のうち前記所定プールの属する所定の記憶制御装置が有する、未使用の第１の実ボリュームを前記所定プールに追加させる、第１のボリューム追加方法が含まれている、
請求項１に記載の計算機システム。
【請求項５】
前記マイクロプロセッサは、前記第１のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第１の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている属性ラベルと前記第１の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第１の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項４に記載の計算機システム。
【請求項６】
前記ボリューム追加方法には、
前記各記憶制御装置のうち前記所定の記憶制御装置以外の他の記憶制御装置が有する、未使用の第２の実ボリュームを前記所定の記憶制御装置に接続することにより、前記第２の未使用の実ボリュームを前記所定プールに追加させる、第２のボリューム追加方法が含まれている、
請求項１に記載の計算機システム。
【請求項７】
前記マイクロプロセッサは、前記第２のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第２の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている属性ラベルと前記第２の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第２の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項６に記載の計算機システム。
【請求項８】
前記ボリューム追加方法には、
前記各記憶制御装置のうち前記所定の記憶制御装置の有する第１の他のプールに設けられている第３の実ボリュームを取り外し、その取り外された第３の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第３のボリューム追加方法が含まれている、
請求項１に記載の計算機システム。
【請求項９】
前記マイクロプロセッサは、前記第３のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第３の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている前記属性ラベルと前記第３の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第３の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項８に記載の計算機システム。
【請求項１０】
前記ボリューム追加方法には、
前記所定の記憶制御装置以外の前記他の記憶制御装置が有する、第２の他のプールに設けられている第４の実ボリュームを取り外し、その取り外された第４の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第４のボリューム追加方法が含まれている、請求項１に記載の計算機システム。
【請求項１１】
前記マイクロプロセッサは、前記第４のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第４の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている属性ラベルと前記第４の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第４の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項１０に記載の計算機システム。
【請求項１２】
前記データ移動方法には、
前記ホスト計算機が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第１のデータ移動方法が含まれている、
請求項１に記載の計算機システム。
【請求項１３】
前記データ移動方法には、
前記所定の記憶制御装置が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第２データ移動方法が含まれている、
請求項１に記載の計算機システム。
【請求項１４】
少なくとも一つの仮想的な論理ボリュームを生成する複数の記憶制御装置と、前記仮想的な論理ボリュームを使用する少なくとも一つのホスト計算機とを含む計算機システムを管理するための方法であって、
前記各記憶制御装置は、前記ホスト計算機からのライトアクセスに応じて、プール内の実ボリュームの有する実記憶領域を前記仮想的な論理ボリュームに割り当て、前記ホスト計算機から受信するライトデータを、割り当てられた前記実記憶領域に記憶させるようになっており、
前記各プールの使用状態を取得し、
取得された前記各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定し、
前記所定プールが検出された場合は、（Ａ）前記所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、（Ｂ）前記仮想的な論理ボリュームのデータを前記所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、
前記選択された方法に従って、前記所定プールのプールサイズを拡張させる、
計算機システムの管理方法。
【請求項１】
少なくとも一つの仮想的な論理ボリュームを生成する複数の記憶制御装置と、前記仮想的な論理ボリュームを使用する少なくとも一つのホスト計算機と、前記各記憶制御装置と前記ホスト計算機とを管理するための少なくとも一つの管理計算機とを含む計算機システムであって、
前記各記憶制御装置は、前記ホスト計算機からのライトアクセスに応じて、プール内の実ボリュームの有する実記憶領域を前記仮想的な論理ボリュームに割り当て、前記ホスト計算機から受信するライトデータを、割り当てられた前記実記憶領域に記憶させるようになっており、
前記管理計算機は、
マイクロプロセッサと、前記マイクロプロセッサにより読み込まれて実行される所定のコンピュータプログラムを記憶するメモリと、前記各記憶制御装置及び前記ホスト計算機と通信するための通信インターフェース部とを備えており、
前記マイクロプロセッサは、前記所定のコンピュータプログラムを読み込んで実行することにより、
前記各プールの使用状態を取得し、
取得された前記各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定し、
前記所定プールが検出された場合は、（Ａ）前記所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、（Ｂ）前記仮想的な論理ボリュームのデータを前記所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、
前記選択された方法に従って、前記所定プールのプールサイズを拡張させる、
計算機システム。
【請求項２】
（Ａ）前記ボリューム追加方法には、
（Ａ１）前記各記憶制御装置のうち前記所定プールの属する所定の記憶制御装置が有する、未使用の第１の実ボリュームを前記所定プールに追加させる、第１のボリューム追加方法と、
（Ａ２）前記各記憶制御装置のうち前記所定の記憶制御装置以外の他の記憶制御装置が有する、未使用の第２の実ボリュームを前記所定の記憶制御装置に接続することにより、前記第２の未使用の実ボリュームを前記所定プールに追加させる、第２のボリューム追加方法と、
（Ａ３）前記各記憶制御装置のうち前記所定の記憶制御装置の有する第１の他のプールに設けられている第３の実ボリュームを取り外し、その取り外された第３の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第３のボリューム追加方法と、
（Ａ４）前記所定の記憶制御装置以外の前記他の記憶制御装置が有する、第２の他のプールに設けられている第４の実ボリュームを取り外し、その取り外された第４の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第４のボリューム追加方法と、
が含まれており、
（Ｂ）前記データ移動方法には、
（Ｂ１）前記ホスト計算機が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第１のデータ移動方法と、
（Ｂ２）前記所定の記憶制御装置が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第２データ移動方法と、
が含まれており、
前記マイクロプロセッサは、
（Ｃ１）前記第１のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第１の実ボリュームが前記所定プールの使用率を所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている属性ラベルと、前記第１の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第１の実ボリュームを追加した場合でも前記所定プールの応答性能が所定のプール性能値以上となる場合に、前記第１のボリューム追加方法を実行し、
（Ｃ２）前記第２のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第２の実ボリュームが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている前記属性ラベルと、前記第２の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第２の実ボリュームを追加した場合でも前記所定プールの応答性能が前記所定のプール性能値以上となる場合に、前記第２のボリューム追加方法を実行し、
（Ｃ３）前記第３のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第３の実ボリュームが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている前記属性ラベルと、前記第３の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第３の実ボリュームを追加した場合でも前記所定プールの応答性能が前記所定値以上となり、かつ、前記第３の実ボリュームを前記第１の他のプールから取り外しても前記第１の他のプールの応答性能が他のプール性能値以上となる場合に、前記第３のボリューム追加方法を実行し、
（Ｃ４）前記第４のボリューム追加方法を実行する場合の前記所定の選択基準として、前記第４の実ボリュームが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのボリュームサイズを有しており、かつ、前記所定プールに予め設定されている前記属性ラベルと、前記第４の実ボリュームに予め設定されている属性ラベルとが適合しており、かつ、前記所定プールに前記第４の実ボリュームを追加した場合でも前記所定プールの応答性能が前記所定のプール性能値以上となる場合に、前記第４のボリューム追加方法を実行し、
（Ｃ５）前記第１のデータ移動方法を実行する場合の前記所定の選択基準として、前記ホスト計算機が前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための機能を有しており、かつ、前記仮想的な論理ボリュームのデータのサイズが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのサイズを有しており、かつ、前記仮想的な論理ボリュームに予め設定されている属性ラベルと、前記他のプールに予め設定されている属性ラベルとが適合し、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための時間が予め設定される所定時間よりも短く、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させた場合でも前記仮想的な論理ボリュームの応答性能が所定のボリューム性能値以上となる場合に、前記第１のデータ移動方法を実行し、
（Ｃ６）前記第２のデータ移動方法を実行する場合の前記所定の選択基準として、前記記憶制御装置が前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための機能を有しており、かつ、前記仮想的な論理ボリュームのデータのサイズが前記所定プールの使用率を前記所定の使用率以下に低下させるだけのサイズを有しており、かつ、前記仮想的な論理ボリュームに予め設定されている属性ラベルと、前記他のプールに予め設定されている属性ラベルとが適合し、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させるための時間が予め設定される所定時間よりも短く、かつ、前記仮想的な論理ボリュームのデータを前記他のプールに移動させた場合でも前記仮想的な論理ボリュームの応答性能が所定のボリューム性能値以上となる場合に、前記第２のデータ移動方法を実行し、
さらに、（Ａ１）前記第１のボリューム追加方法、（Ａ２）前記第２のボリューム追加方法、（Ｂ１）前記第１のデータ移動方法、（Ｂ２）前記第２のデータ移動方法、（Ａ３）前記第３のボリューム追加方法、（Ａ４）前記第４のボリューム追加方法、の順番で優先順位が設定されており、
前記マイクロプロセッサは、前記優先順位に基づいて前記各方法を実行する、
請求項１に記載の計算機システム。
【請求項３】
前記マイクロプロセッサは、前記ボリューム追加方法と前記データ移動方法のいずれかを選択する場合に、前記仮想的な論理ボリュームを使用するアプリケーションプログラムの稼働状況を考慮して、所定時間内に前記所定プールのプールサイズの拡張が完了するか否かを判定する、
請求項１に記載の計算機システム。
【請求項４】
前記ボリューム追加方法には、
前記各記憶制御装置のうち前記所定プールの属する所定の記憶制御装置が有する、未使用の第１の実ボリュームを前記所定プールに追加させる、第１のボリューム追加方法が含まれている、
請求項１に記載の計算機システム。
【請求項５】
前記マイクロプロセッサは、前記第１のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第１の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている属性ラベルと前記第１の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第１の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項４に記載の計算機システム。
【請求項６】
前記ボリューム追加方法には、
前記各記憶制御装置のうち前記所定の記憶制御装置以外の他の記憶制御装置が有する、未使用の第２の実ボリュームを前記所定の記憶制御装置に接続することにより、前記第２の未使用の実ボリュームを前記所定プールに追加させる、第２のボリューム追加方法が含まれている、
請求項１に記載の計算機システム。
【請求項７】
前記マイクロプロセッサは、前記第２のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第２の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている属性ラベルと前記第２の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第２の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項６に記載の計算機システム。
【請求項８】
前記ボリューム追加方法には、
前記各記憶制御装置のうち前記所定の記憶制御装置の有する第１の他のプールに設けられている第３の実ボリュームを取り外し、その取り外された第３の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第３のボリューム追加方法が含まれている、
請求項１に記載の計算機システム。
【請求項９】
前記マイクロプロセッサは、前記第３のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第３の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている前記属性ラベルと前記第３の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第３の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項８に記載の計算機システム。
【請求項１０】
前記ボリューム追加方法には、
前記所定の記憶制御装置以外の前記他の記憶制御装置が有する、第２の他のプールに設けられている第４の実ボリュームを取り外し、その取り外された第４の実ボリュームを未使用の実ボリュームとして前記所定プールに追加させる、第４のボリューム追加方法が含まれている、請求項１に記載の計算機システム。
【請求項１１】
前記マイクロプロセッサは、前記第４のボリューム追加方法を実行する場合、前記所定の選択基準として、
前記第４の実ボリュームのボリュームサイズと、前記所定プールに予め設定されている属性ラベルと前記第４の実ボリュームに予め設定されている属性ラベルとの適合状態と、前記所定プールに前記第４の実ボリュームを追加した場合の前記所定プールの応答性能とを考慮する、
請求項１０に記載の計算機システム。
【請求項１２】
前記データ移動方法には、
前記ホスト計算機が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第１のデータ移動方法が含まれている、
請求項１に記載の計算機システム。
【請求項１３】
前記データ移動方法には、
前記所定の記憶制御装置が前記仮想的な論理ボリュームのデータを前記所定のプール以外の前記他のプールに移動させる、第２データ移動方法が含まれている、
請求項１に記載の計算機システム。
【請求項１４】
少なくとも一つの仮想的な論理ボリュームを生成する複数の記憶制御装置と、前記仮想的な論理ボリュームを使用する少なくとも一つのホスト計算機とを含む計算機システムを管理するための方法であって、
前記各記憶制御装置は、前記ホスト計算機からのライトアクセスに応じて、プール内の実ボリュームの有する実記憶領域を前記仮想的な論理ボリュームに割り当て、前記ホスト計算機から受信するライトデータを、割り当てられた前記実記憶領域に記憶させるようになっており、
前記各プールの使用状態を取得し、
取得された前記各プールの使用状態に基づいて、プールサイズの拡張が必要な所定プールが存在するか否かを判定し、
前記所定プールが検出された場合は、（Ａ）前記所定プールに未使用の実ボリュームを追加させるボリューム追加方法と、（Ｂ）前記仮想的な論理ボリュームのデータを前記所定プール以外の他のプールに移動させるデータ移動方法のうち、少なくともいずれか一つの方法を所定の選択基準に基づいて選択し、
前記選択された方法に従って、前記所定プールのプールサイズを拡張させる、
計算機システムの管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−７３８２５（Ｐ２０１２−７３８２５Ａ）
【公開日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願番号】特願２０１０−２１８２４２（Ｐ２０１０−２１８２４２）
【出願日】平成２２年９月２９日（２０１０．９．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＲＲＡＭ
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願日】平成２２年９月２９日（２０１０．９．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＲＲＡＭ
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]