(57)【要約】【課題】通常運用時におけるストレージシステム内のボリュームを効率的に提供し、利用率を向上させる。【解決手段】  正論理ボリュームと副論理ボリュームとを含むストレージシステムを管理する管理計算機において、正論理ボリュームへのアクセス量が閾値を超える場合、正論理ボリュームに対応付けられる物理ボリュームより入出力性能が高い物理ボリュームに対応付けられる副論理ボリュームを選択する。そして、選択された副論理ボリュームに対応する物理ボリュームに格納されたデータの移行時間が所定の時間以内である場合、正論理ボリュームに対応する物理ボリュームに格納されているデータを、選択された副論理ボリュームに対応する物理ボリュームに移行し、選択された副論理ボリュームに対応する物理ボリュームを正論理ボリュームに対応付ける。【選択図】図１
2011076286.tif 000002
【特許請求の範囲】
【請求項１】
他のストレージシステムに接続するストレージシステムと、
前記ストレージシステムを管理する管理計算機と、が含まれる計算機システムであって、
前記ストレージシステムは、
第一の正論理ボリュームと、複数の第一の副論理ボリュームと、バッファボリュームを含む複数の論理ボリュームに対応する複数の物理ボリュームと、
前記複数の物理ボリュームへのデータの入出力処理を実行する第一のコントローラと、を含み、
前記管理計算機は、
前記複数の物理ボリュームの性能を示す物理ボリューム情報を格納するメモリと、
第二のコントローラと、を含み、
前記複数の第一の副論理ボリュームは、前記他のストレージシステムが提供する複数の第二の正論理ボリュームとコピーペアを形成し、前記第一の正論理ボリュームは、前記他のストレージシステムが提供する第二の副論理ボリュームとコピーペアを形成し、
前記第二のコントローラは、前記第一の正論理ボリュームへのアクセス量が閾値を超える場合、前記メモリから読み出した前記物理ボリューム情報を参照することにより、前記複数の第一の副論理ボリュームに含まれ、前記第一の正論理ボリュームに対応付けられる第一の物理ボリュームより入出力性能が高い第二の物理ボリュームに対応付けられる副論理ボリュームを選択し、
前記第二のコントローラは、データ移行時間が所定の時間以内であるかを確認し、前記移行時間が所定の時間内である場合、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに格納されているデータを、前記バッファボリュームに対応する第三の物理ボリュームに移行し、前記第一の正論理ボリュームに対応する前記第一の物理ボリュームに格納されているデータを、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに移行し、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームを前記第一の正論理ボリュームに対応付ける、指示を前記ストレージシステムに発行する、ことを特徴とする計算機システム。
【請求項２】
請求項１に記載の計算機システムであって、
前記データ移行時間は、前記前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに格納されているデータを、前記バッファボリュームに対応する前記第三の物理ボリュームに移行した場合に、前記バッファボリュームに対応する前記第三の物理ボリュームに格納されるデータを前記バッファボリュームに対応する前記第三の物理ボリュームよりも入出力性能が高い第四の物理ボリュームへ移行するために要する時間である、ことを特徴とする計算機システム。
【請求項３】
請求項２に記載の計算機システムであって、
前記メモリは、さらに、前記ストレージシステムにおいて前記複数の物理ボリュームに含まれる一方の物理ボリュームに格納されるデータを他方の物理ボリュームに移行するためのデータ移行速度を示すデータ移行性能情報を格納し、
前記第二のコントローラは、前記データ移行時間を、前記データ移行情報を参照し、前記第二の物理ボリュームに格納されるデータのデータ量と、前記データ移行速度をもとに算出される、ことを特徴とする計算機システム。
【請求項４】
請求項３に記載の計算機システムであって、
前記第二のコントローラは、前記データ移行時間を、前記第二の物理ボリュームに格納されるデータの前記データ量と、前記データ移行速度とに加えて、さらに、前記第四の物理ボリュームに格納されるデータのデータ量をもとに算出する、ことを特徴とする計算機システム。
【請求項５】
請求項４に記載の計算機システムであって、
前記移行時間は、前記第二の物理ボリュームに格納されるデータの前記データ量と前記データ移行速度によって算出される第一の移行時間と、前記第四の物理ボリュームに格納されるデータの前記データ量と前記データ移行速度によって算出される第二の移行時間との和である、ことを特徴とする計算機システム。
【請求項６】
請求項５に記載の計算機システムであって、さらに
前記ストレージシステムと接続し、複数のアプリケーションを動作するホスト計算機を含み、
各々の前記複数の論理ボリュームは各々の前記複数のアプリケーションに割り当てられることを特徴とする計算機システム。
【請求項７】
請求項６に記載の計算機システムであって、
前記メモリは、さらに、前記複数の第一の副論理ボリュームが割り当てられるアプリケーションが、前記他のストレージシステムの被災時に要求する被災時要求性能を示す性能情報を格納し、
前記第四の物理ボリュームの入出力性能は、前記選択された副論理ボリュームに割り当てられるアプリケーションの被災時要求性能より高い、ことを特徴とする計算機システム。
【請求項８】
請求項７に記載の計算機システムであって、
前記所定の時間は、前記他のストレージシステムの被災時において、前記選択された副論理ボリュームに割り当てられるアプリケーションの前期被災時要求性能より入手力性能が低い物理ボリュームを、前記選択された副論理ボリュームに割り当てられることを許容する時間である、ことを特徴とする計算機システム。
【請求項９】
請求項５に記載の計算機システムであって、さらに
前記ストレージシステムと接続し、複数の仮想サーバが動作する物理サーバを含み、
各々の前記複数の仮想計算機の仮想ボリュームファイルが、前記複数の論理ボリュームに格納されていることを特徴とする計算機システム。
【請求項１０】
請求項９に記載の計算機システムあって、
前記物理サーバは、インタフェースを有し、
前記メモリは、前記複数の仮想計算機に割り当てられる前記インタフェースの入出力性能を示す仮想計算機情報を格納し、
前記第二のコントローラは、前記仮想計算機情報を参照し、前記第二の物理ボリュームの入出力性能と、前記正論理ボリュームに仮想ボリュームファイルを格納する第一の仮想計算機に割り当てられている前記インタフェースの入出力性能と、を比較し、第一の仮想計算機に割り当てられている前記インタフェースの入出力性能が前記第二の物理ボリュームの入出力性能より低い場合、前記第二の物理ボリュームを前記正論理ボリュームに対応付ける際に前記第一の仮想計算機に割り当てられている前記インタフェースの入出力性能を変更することを特徴とする計算機システム。
【請求項１１】
請求項１０に記載の計算機システムであって、
前記第一の仮想計算機に割り当てられている前記インタフェースの入出力性能を変更により、第一の仮想計算機に割り当てられている前記インタフェースの入出力性能を前記第二の物理ボリュームの入出力性能より高くすることができない場合、前記第一の仮想計算機を前記物理サーバとは別の物理サーバに移行させることを特徴とする計算機システム。
【請求項１２】
請求項１１に記載の計算機システムであって、
前記メモリは、さらに、前記選択された副論理ボリュームに仮想ボリュームファイルを格納する仮想計算機が、前記他のストレージシステムの被災時に要求する被災時要求性能を示す性能情報を格納し、
前記第四の物理ボリュームの入出力性能は、前記第二の仮想計算機の前記被災時要求性能より高い、ことを特徴とする計算機システム。
【請求項１３】
請求項１２に記載の計算機システムであって、
前記所定の時間は、前記仮想計算機の要求する被災時要求性能より入出性能が低い物理ボリュームを前記選択された副論理ボリュームに割り当てられていることを許容する時間である、ことを特徴とする計算機システム。
【請求項１４】
第一の正論理ボリュームと、複数の第一の副論理ボリュームと、バッファボリュームを含む複数の論理ボリュームに対応する複数の物理ボリュームと、前記複数の物理ボリュームへのデータの入出力処理を実行する第一のコントローラと、により構成され、他のストレージシステムに接続するストレージシステムと、前記複数の物理ボリュームの性能を示す物理ボリューム情報を格納するメモリと、第二のコントローラと、により構成され前記ストレージシステムを管理する管理計算機と、が含まれる計算機システムにおける物理ボリューム割り当て方法であって、
前記複数の第一の副論理ボリュームは、前記他のストレージシステムが提供する複数の第二の正論理ボリュームとコピーペアを形成し、
前記第一の正論理ボリュームは、前記他のストレージシステムが提供する第二の副論理ボリュームとコピーペアを形成し、
前記第二のコントローラは、前記第一の正論理ボリュームへのアクセス量が閾値を超える場合、前記メモリから読み出した前記物理ボリューム情報を参照することにより、前記複数の第一の副論理ボリュームに含まれ、前記第一の正論理ボリュームに対応付けられる第一の物理ボリュームより入出力性能が高い第二の物理ボリュームに対応付けられる副論理ボリュームを選択し、
前記第二のコントローラは、データ移行時間が所定の時間以内であるかを確認し、前記移行時間が所定の時間内である場合、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに格納されているデータを、前記バッファボリュームに対応する第三の物理ボリュームに移行し、前記第一の正論理ボリュームに対応する前記第一の物理ボリュームに格納されているデータを、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに移行し、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームを前記第一の正論理ボリュームに対応付ける、指示を前記ストレージシステムに発行する、ことを特徴とする物理ボリューム割り当て方法。
【請求項１５】
請求項１４に記載の物理ボリューム割り当て方法であって、
前記データ移行時間は、前記前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに格納されているデータを、前記バッファボリュームに対応する前記第三の物理ボリュームに移行した場合に、前記バッファボリュームに対応する前記第三の物理ボリュームに格納されるデータを前記バッファボリュームに対応する前記第三の物理ボリュームよりも入出力性能が高い第四の物理ボリュームへ移行するために要する時間である、ことを特徴とする物理ボリューム割り当て方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ボリューム割り当てを管理する計算機システム及びボリューム割り当て管理方法であって、特にディザスタリカバリ構成を採用する計算機システムにおいて、物理ボリュームの正副論理ボリュームへの割り当て管理を行う技術に関する。
【背景技術】
【０００２】
情報の電子化に伴って、計算機システムが保有する業務データ量は増加している。業務データの損失は、企業の業務継続を困難にし、企業の信用を失墜させるため、企業生命に関わる大問題となる。しかし、地震などの自然災害、あるいはテロなどによる業務データの損失のリスクは常に存在する。このリスクを低減するため、計算機システムでは、ディザスタリカバリ構成を採用するケースが増加している。ディザスタリカバリとは、通常運用時に業務データの複製を遠隔地に作成し、業務データ損失時にその複製を用いて遠隔地にて業務を継続できる仕組みのことである。例えば、特許文献１では、ストレージシステムが保有する筐体間データ複製機能（リモートコピー機能）を用いたディザスタリカバリ構成を構築するための技術が開示されている。
【０００３】
また、通常運用時の業務データを複製する計算機システムでは、一般に複製元ボリューム(正論理ボリューム)にはホスト計算機からのアクセスが発生するため、複製先ボリューム(副論理ボリューム)よりも負荷が高くなる。このため、複数のホスト計算機の正論理ボリュームが同一の記憶装置を共有している場合、その記憶装置への負荷が増大する。特許文献２では、単一の物理ボリュームから複数の論理ボリュームを生成するストレージシステムが開示されている。そして、該ストレージシステムにおいて、特定の物理ボリュームへの負荷の増大を回避するために、第一のホスト計算機が第一の物理ボリュームから生成された論理ボリュームを正論理ボリュームとして、第二の物理ボリュームから生成された論理ボリュームを副論理ボリュームとして使用する場合は、第二のホスト計算機は第二の物理ボリュームから生成された論理ボリュームを正論理ボリュームとして、第一の物理ボリュームから生成された論理ボリュームを副論理ボリュームとして使用するように制御する技術が開示されている。
【０００４】
この技術の拡張としてディザスタリカバリ構成においても負荷分散のため、一般に、第一のホスト計算機が第一のストレージシステムが格納する論理ボリュームを正論理ボリュームとして、第二のストレージシステムが格納する論理ボリュームを副論理ボリュームとして使用する場合は、第二のホスト計算機は第二のストレージシステムが格納する論理ボリュームを正論理ボリュームとして、第一のストレージシステムが格納する論理ボリュームを副論理ボリュームとして使用する構成が採られる。一般に、これをＡｃｔｉｖｅ−Ａｃｔｉｖｅのディザスタリカバリ構成と呼ぶ。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１５１３８９号公報
【特許文献２】特開２００３−１６２３７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に開示されるディザスタリカバリ構成は、業務を運用している正サイトが被災した場合に、正サイトのデータをリモートコピーして格納している副サイトにて業務を再開することを目的としている。被災時にリモートコピーしたデータを用いて副サイトにて再開される業務は、通常運用時と同様に、性能目標を満たす必要がある。従来は、被災時においてユーザから要求される性能目標を満たすために、副サイトのストレージ装置において、リモートコピーしたデータを性能目標を満たす副論理ボリュームに格納し業務に割り当てていた。たとえば、被災時も通常運用と同等の性能で業務を継続する必要がある場合は、正論理ボリュームと同性能のボリュームを副論理ボリュームとして業務に割り当てる。
【０００７】
一方で、様々な制約によりストレージ装置内の高性能なボリュームの数は制限される。ある業務に高性能な副論理ボリュームを割り当てる場合、他の業務に対しては要求よりも低い性能の正論理ボリュームに割り当てざるを得なくなる場合があった。しかし、ホスト計算機は、通常運用時には副論理ボリュームに対してアクセスしない。したがって、被災時に再開される業務の性能目標を満たすために割り当てられた高性能な副論理ボリュームの性能を、通常運用時には活かすことができないという課題がある。
【課題を解決するための手段】
【０００８】
上記課題を解決するための計算機システムは、他のストレージシステムに接続するストレージシステムと、前記ストレージシステムを管理する管理計算機と、が含まれる計算機システムであって、前記ストレージシステムは、第一の正論理ボリュームと、複数の第一の副論理ボリュームと、バッファボリュームを含む複数の論理ボリュームに対応する複数の物理ボリュームと、前記複数の第一の物理ボリュームへのデータの入出力処理を実行する第一のコントローラと、を含み、前記管理計算機は、前記複数の物理ボリュームの性能を示す物理ボリューム情報と、を格納するメモリと、前記メモリに格納されるデータを参照して処理を実行する第二のコントローラと、を含み、前記複数の第一の副論理ボリュームは、前記他のストレージシステムが提供する複数の第二の正論理ボリュームとコピーペアを形成し、前記第一の正論理ボリュームが、前記他のストレージシステムが提供する第二の副論理ボリュームとコピーペアを形成し、前記第二のコントローラは、前記第一の正論理ボリュームへのアクセス量が閾値を超える場合、前記メモリから読み出した前記物理ボリューム情報を参照することにより、前記複数の第一の副論理ボリュームに含まれ、前記第一の正論理ボリュームに対応付けられる第一の物理ボリュームより入出力性能が高い第二の物理ボリュームに対応付けられる副論理ボリュームを選択し、前記第二のコントローラは、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに格納されたデータの移行時間が所定の時間以内であるかを確認し、前記移行時間が所定の時間内である場合、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに格納されているデータを、前記バッファボリュームに対応する第三の物理ボリュームに移行し、前記第一の正論理ボリュームに対応する前記第一の物理ボリュームに格納されているデータを、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームに移行し、前記選択された副論理ボリュームに対応する前記第二の物理ボリュームを前記第一の正論理ボリュームに対応付ける、指示を前記ストレージシステムに発行する、ことを特徴とする計算機システムである。
【発明の効果】
【０００９】
サーバが要求する業務性能を、ストレージシステム内の正論理ボリュームに対応する物理ボリュームが満たせない場合に、高性能な副論理ボリュームであって通常運用時であるために使用されていない論理ボリュームに対応する物理ボリュームを、正論理ボリュームに割り当てて使用することができるため、ストレージシステム内の物理ボリュームを効率的に利用することができる。
【図面の簡単な説明】
【００１０】
【図１】第一の実施例において計算機システムの構成の概要を示すブロック図である。
【図２】第一の実施例においてストレージシステムの構成の一例を示した図である。
【図３】第一の実施例においてホスト計算機の構成の一例を示した図である。
【図４】第一の実施例において管理計算機の構成の一例を示した図である。
【図５】第一の実施例においてアプリケーション情報の構成例を示した図である。
【図６】第一の実施例において論理ボリューム情報の構成例を示した図である。
【図７】第一の実施例において物理ボリューム情報４０１５の構成例を示した図である。
【図８】第一の実施例においてデータ移行性能情報４０１６の構成例を示した図である。
【図９】第一の実施例において構成構築プログラム４０１０がディザスタリカバリ構成を構築する際の処理の流れを示した図である。
【図１０】第一の実施例において代替構成提案画面の構成例を示す図である。
【図１１】第一の実施例において稼働状況監視プログラムの動作を示すフローチャートである。
【図１２】第一の実施例において被災時復旧プログラムの動作を示すフローチャートである。
【図１３】第二の実施例においてストレージシステムの構成例を示すブロック図である。
【図１４】第二の実施例においてホスト計算機の構成例を示すブロック図である。
【図１５】第二の実施例において管理計算機の構成例を示すブロック図である。
【図１６】第二の実施例においてＶＭ性能情報のテーブルの構成例を示す図である。
【図１７】第二の実施例において論理ボリューム情報のテーブルの構成例を示す図である。
【図１８】第二の実施例において論理ボリューム構成情報のテーブルの構成例を示す図である。
【図１９】第二の実施例において物理ボリューム情報のテーブルの構成例を示す図である。
【図２０】第二の実施例においてＶＭ構成情報のテーブルの構成例を示す図である。
【図２１】第二の実施例において物理サーバ情報のテーブルの構成例を示す図である。
【図２２】第二の実施例においてＶＭ移行性能情報のテーブルの構成例を示す図である。
【図２３】第二の実施例において構成構築プログラムの動作を示すフローチャートである。
【図２４】第二の実施例において稼働状況監視プログラムの動作を示すフローチャートである。
【図２５】第二の実施例において被災時復旧プログラムの動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施例について、図面を参照しながら詳細に説明する。
【第一の実施例】
【００１２】
まず、第一の実施例について説明する。
以下、本実施例のシステム構成と動作を説明する。
【００１３】
（１−１）第一の実施例のシステム構成。
図１は、本実施例において計算機システムの構成の概要を示すブロック図の一例である。
本システムは、サイトＡ１１００とサイトＢ１２００によるＡｃｔｉｖｅ−Ａｃｔｉｖｅのディザスタリカバリ構成となっている。
【００１４】
本計算機システムは、通常運用時にアプリケーションを稼動させる運用系ホスト計算機（正ホスト計算機）として、サイトＡ１１００にホスト計算機Ａ１１０１、サイトＢ１２００にホスト計算機Ｂ１２０２を含む。サイトＡ１１００の被災時に、ホスト計算機Ａ１１０１と同等のアプリケーションを稼動させる待機系ホスト計算機（副ホスト計算機）としてホスト計算機Ｃ１２０１がサイトＢ１２００に含まれる。また、サイトＢ１２００の被災時にホスト計算機Ｂ１２０２と同等のアプリケーションを稼動させる待機系ホスト計算機（副ホスト計算機）としてホスト計算機Ｄ１１０２がサイトＡ１１００に含まれる。
ここで、待機系ホスト計算機は対応する運用系ホスト計算機と同等の構成をとることが望ましい。しかし、被災時に運用系ホスト計算機で稼動していたアプリケーションと同等のアプリケーションが稼動する構成であれば異なっていても良い。
【００１５】
ホスト計算機Ａ１１０１とホスト計算機Ｄ１１０２に加え、サイトＡ１１００にはストレージシステムＡ１１０３が含まれる。サイトＡ１１００のストレージシステムＡ１１０３はデータネットワークＣ１４００を介してサイトＢ１２００のストレージシステム１２０３に接続する。
【００１６】
また、ホスト計算機Ａ１１０１はデータネットワークＡ１１０４を介してストレージシステムＡ１１０３に含まれる論理ボリュームＡ１１１１に対しデータの読み書き要求を発0行する。ストレージシステムＡ１１０３は、自身が保有する制御プログラム（リモートコピープログラム）をＣＰＵにより実行し、データネットワークＣ１４００を介し、論理ボリュームＡ１１１１に格納されるデータを、ストレージシステムＢ１２００の論理ボリュームＣ１２１１に複製（リモートコピー）する。サイトＡ１１００被災時において、ホスト計算機Ｃ１２０１は、該論理ボリュームＣ１２１１のデータを用いて、ホスト計算機Ａで稼動していたアプリケーションと同等のアプリケーションをユーザに提供し、復旧することができる。なお、論理ボリュームには、物理ボリュームが対応付けられている。そして、論理ボリュームに対するデータの読み書き処理は、実際には、論理ボリュームに対応付けられている物理ボリュームに対する読み書き処理となる。以下、「論理ボリュームに対するデータの読み書き処理」として説明する場合もあるが、「論理ボリュームに対応付けられている物理ボリュームに対する読み書き処理」を意味する。
【００１７】
ホスト計算機Ｂ１２０２とホスト計算機Ｃ１２０１に加え、サイトＢ１２００にはストレージシステムＢ１２０３が含まれる。ストレージシステムＢ１２０３は、データネットワークＣ１４００を介してストレージシステムＡ１１０３に接続される。また、ホスト計算機Ｂ１２０２は、データネットワークＢ１２０４を介してストレージシステム１２００の論理ボリュームＢ１２１２に対してデータの読み書き要求を発行する。ストレージシステムＢ１２０３は、自身が保有する制御プログラム（リモートコピープログラム）により、データネットワークＣ１４００を介し、論理ボリュームＢ１２１２のデータを、論理ボリュームＤ１１１２に複製（リモートコピー）する。サイトＢ１２００被災時に、ホスト計算機Ｄ１１０２は、この論理ボリュームＤ１１１２を用いて、ホスト計算機Ｂで稼動していたアプリケーションと同等のアプリケーションを復旧することができる。
【００１８】
本計算機システムは、管理計算機１５００を含む。管理計算機１５００は、管理ネットワーク１３００を介して各サイトの運用系ホスト計算機、待機系ホスト計算機、ストレージシステムに接続する。そして、管理計算機１５００は、各サイトの運用系ホスト計算機、待機系ホスト計算機、ストレージシステムを管理する。
【００１９】
なお、本計算機システム構成図では、各サイトにストレージシステムが一台、ホスト計算機が２台である。しかしこれに限定されるものではなく、本計算機システムは、複数のストレージシステムや２台以上のホスト計算機を含んでもよい。また、データネットワークＡ１１０４、データネットワークＢ１２０４、データネットワークＣ１４００は、ストレージエリアネットワーク（ＳＡＮ）である。しかしこれに限定されるものではなく、ＩＰネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。また、管理ネットワーク１３００は、ＩＰネットワークである。しかし、これに限定されるものではなく、ストレージエリアネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。また、各ネットワークが同一ネットワークであってもよいし、ホスト計算機Ａ１１０１とホスト計算機Ｄ１１０２と管理計算機１５００の二つ以上が単一の計算機により実現されていてもよい。同様に、ホスト計算機Ｂ１２０２とホスト計算機Ｃ１２０１と管理計算機１５００の二つ以上が単一の計算機により実現されていてもよい。
【００２０】
図２は、本実施例においてストレージシステムＡ１１０３の構成の一例を示した図である。
ストレージシステムＡ１１０３は、ホスト計算機のアプリケーションが利用するデータを格納する論理ボリュームを提供するストレージシステムである。ストレージシステムＡ１１０３は、データを格納する物理ボリューム２０１１と、ストレージシステムＡ１１０３内の制御を行うディスクコントローラ２０２０とを備える
物理ボリューム２０１１は、ディスク型の記憶装置、例えば、ハードディスクドライブ（ＨＤＤ）である。物理ボリューム１０１１は、ラッシュメモリデバイス等、多種の記憶装置であってもよい。
【００２１】
ディスクコントローラ２０２０は、データＩ／Ｆ２０２１と、管理Ｉ／Ｆ２０２４と、ディスクＩ／Ｆ２０２３と、メモリ２０２５と、ＣＰＵ２０２２とを含む。
【００２２】
メモリ２０２５には、管理情報群２０３１と、制御プログラム２０３２とが記憶される。ＣＰＵ２０２２は、メモリ２０２５に記憶された制御プログラム２０３２を実行する。以下、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するＣＰＵによって処理が行われるものとする。
【００２３】
制御プログラム２０３２は、物理ボリューム２０１１を１以上の領域に論理的に分割した領域を作成し管理する。この分割された領域は、論理ボリューム２０１２である。図２においては、単一の物理ボリューム２０１１から論理ボリューム２０１２を作成するように図示されている。しかし、これに代えて、複数の物理ボリューム２０１１をＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）技術によりグループ化したものから論理ボリューム２０１２を作成しても良い。
【００２４】
また、制御プログラム２０３２は、論理ボリューム２０１２に格納されたデータを、ストレージシステム１２０３にリモートコピーするために必要な処理を実行する。たとえば、制御プログラムは、ユーザの指示に従い、正論理ボリュームとなる論理ボリューム２０１２の識別子と、副論理ボリュームとなる他筐体の論理ボリューム２０１２の識別子の組を管理情報群２０３１に記録する。そして、制御プログラム２０３２は、副論理ボリュームを格納するストレージシステムの制御プログラムと連携し、正論理ボリュームのデータを副論理ボリュームにコピーする。その後、ホスト計算機から正論理ボリュームに対する書き込みを受け付け、書き込まれるデータを副論理ボリュームへ転送するなどの処理を行う。
【００２５】
また、制御プログラム２０３２は、物理ボリューム２０１１に格納されるデータを他の物理ボリュームに再配置する処理を実行する。具体的には、制御プログラム２０３２は、指定された論理ボリュームの領域に対応する物理ボリュームの領域に格納されているデータを他の物理ボリュームの領域にコピーする。そして、制御プログラム２０３２は、指定された論理ボリュームの領域をコピー先の物理ボリュームの領域に対応付けなおすことで、ホスト計算機に影響を与えることなく、物理ボリューム間でのデータの再配置を行う。本技術の詳細は特開２０００−２９３３１７号公報に開示されているものと同等である。ここでは、このデータを再配置することを「データを移行させる」とよぶ。
【００２６】
また、制御プログラム２０３２は、管理計算機やホスト計算機からの要求に応じ、論理ボリューム２０１２へデータ入出力（読み書き）処理をする。制御プログラム２０３２は、ストレージシステム１０００内の構成情報や制御情報を設定する。ここで、構成情報には、物理ボリューム１０１１と論理ボリューム２０１２の関係が含まれる。構成情報は、管理情報群２０３１の全部又は一部として、メモリ２０２５に記録される。制御プログラム２０３２は、管理情報群２０３１に含まれる構成情報を参照または更新しながら上述した種々の処理を実行する。
【００２７】
データＩ／Ｆ２０２１は、データネットワークＡ１１０４あるいはデータネットワークＣ１４００と接続するインタフェースである。制御プログラム２０３２は、データＩ／Ｆ２０２１を介してホスト計算機や他のストレージシステムと、データや制御命令の送受信を行う。
【００２８】
管理Ｉ／Ｆ１０２２は、管理ネットワーク１３００と接続するインタフェースである。制御プログラム２０３２は、管理Ｉ／Ｆ２０２４を介してホスト計算機や管理計算機と、データや制御命令の送受信を行う。
【００２９】
ディスクＩ／Ｆ２０２３は、物理ボリューム２０１１と接続するインタフェースである。制御プログラム２０３２は、ディスクＩ／Ｆ２０２４を介して物理ボリューム２０１１とデータや制御命令の送受信を行う。
【００３０】
なお、ストレージシステムＢ１２０３もこれと同様の構成をとるため説明は省略する。
【００３１】
図３は、本実施例においてホスト計算機Ａ１１０１の構成の一例を示した図である。
ホスト計算機Ａ１１０１は、キーボードやマウスなどの入力装置３００１と、ＣＰＵ３００２と、ＣＲＴなどの表示装置３００３と、メモリ３００６と、データＩ／Ｆ３００４と、管理Ｉ／Ｆ３００５とを備える。
【００３２】
ＣＰＵ３００２は、メモリ３００６に記憶されたアプリケーション３０１０などのプログラムを実行する。メモリ３００６には、アプリケーション３０１０が記憶される。アプリケーション３０１０は、論理ボリューム２０１２を利用するアプリケーションプログラムであり、例えば、ＤＢＭＳやファイルシステムである。データＩ／Ｆ３００４は、データネットワーク１１０４と接続するインタフェースである。アプリケーション３０１０は、データＩ／Ｆ３００４を介してストレージシステムと、データや制御命令の送受信を行う。
【００３３】
管理Ｉ／Ｆ３００５は、管理ネットワーク１４００に対するインタフェースである。アプリケーション３０１０は、管理Ｉ／Ｆ３００５を介して管理計算機、他のホスト計算機、ストレージシステムと、データや制御命令の送受信を行う。
【００３４】
なお、ホスト計算機Ｂ１２０２、ホスト計算機Ｃ１２０１、ホスト計算機Ｄ１１０２もこれと同様の構成をとるため説明は省略する。また、ホスト計算機Ａのメモリに格納されるアプリケーションは、ホスト計算機Ｃのメモリに格納されるアプリケーションを含む。ホスト計算機Ｂのメモリに格納されるアプリケーションは、ホスト計算機Ｄのメモリに格納されるアプリケーションを含む。
【００３５】
図４は、本実施例において管理計算機１５００の構成の一例を示した図である。
管理計算機１５００は、キーボードやマウスなどの入力装置４００１と、ＣＰＵ４００２と、ＣＲＴなどの表示装置４００３と、メモリ４００５と、管理Ｉ／Ｆ４００４とを含む。
【００３６】
メモリ４００５には、構成構築プログラム４０１０と、稼働状況監視プログラム４０１１と、被災時復旧プログラム４０１２と、アプリケーション情報４０１３と、論理ボリューム情報４０１４と、物理ボリューム情報４０１５と、データ移行性能情報４０１６とが記憶される。ＣＰＵ４００２は、メモリ４００５に記憶されたプログラムを実行する。なお、以下プログラムを主語にして動作を説明する場合もあるが、実際にはＣＰＵ４００２がメモリから該プログラムを読み出して実行することを意味する。
【００３７】
構成構築プログラム４０１０は、ディザスタリカバリ構成を構築するためのプログラムである。ユーザは本プログラムが提供するユーザインタフェースを用いて、構築するディザスタリカバリ構成に関する設定情報を入力する。本プログラムの処理の流れについては後述する。
【００３８】
稼働状況監視プログラム４０１１は、稼働中のディザスタリカバリ環境内の正論理ボリュームへのアクセス状況を監視し、正論理ボリュームの性能が不十分である場合に、ユーザの指示に応じて正論理ボリュームのデータを他のボリュームへの移行するプログラムである。本プログラムは、ユーザにより起動された後、計算機システム内でデーモンプロセスとして稼動し続ける。本プログラムの処理の流れについては後述する。
【００３９】
被災時復旧プログラム４０１２は、被災時に各アプリケーションが要求する性能を持つボリュームを割り当てるためのプログラムである。本プログラムは、ユーザの指示により起動する。本プログラムの処理の流れについては後述する。
【００４０】
アプリケーション情報４０１３、論理ボリューム情報４０１４、物理ボリューム情報４０１５、データ移行性能情報４０１６については後述する。
【００４１】
図５は、本実施例においてアプリケーション情報４０１３の構成例を示した図である。
アプリケーションＩＤ５００１は、本計算機システムにおいてアプリケーションを一意に識別するためのＩＤを格納する。以降のフィールドは、この値により示されるアプリケーションに関する情報を格納する。
通常時要求性能５００２は、通常運用時に、アプリケーションが要求する論理ボリュームの処理性能を格納する。論理ボリュームの処理性能とは、論理ボリュームに対応する物理ボリュームの処理性能を示す。以下、「論理ボリュームの処理性能」とは、「論理ボリュームに対応する物理ボリュームの処理性能」を意味する。本構成例では、一秒間に可能なＩ／Ｏの回数を示すＩＯＰＳにより示されるが、他の形式でも良い。以降、この値を通常時要求性能と呼ぶ。
【００４２】
被災時要求性能５００３は、被災時に他のサイトで再開される場合に、アプリケーションが要求する論理ボリュームの処理性能を格納する。本構成例では、一秒間に可能なＩ／Ｏの回数を示すＩＯＰＳにより示されるが、他の形式でも良い。以降、この値を被災時要求性能と呼ぶ。
性能劣化許容時間５００４は、被災時に、指定された被災時要求性能を持つ論理ボリュームに移行し終わるまでの許容可能な時間を格納する。本構成例では、秒数により示されるが、他の形式でも良い。以降、この値を被災時性能劣化許容時間又は性能劣化許容時間と呼ぶ。また、指定された被災時要求性能を持つ論理ボリュームに移行し終わるまでの時間を被災時性能劣化時間又は性能劣化時間と呼ぶ。
【００４３】
サイトＩＤ５００５は、通常運用時においてアプリケーションを稼動するホスト計算機が属するサイトを、本計算機システムにおいて一意に識別するためのＩＤを格納する。
通常時ホストＩＤは、通常運用時においてアプリケーションを稼動するホスト計算機を、本計算機システムにおいて一意に識別するためのＩＤを格納する。
被災時ホストＩＤは、被災時においてアプリケーションを稼動するホスト計算機を、本計算機システムにおいて一意に識別するためのＩＤを格納する。
【００４４】
これらの情報は、ユーザ入力にもとづき構成構築プログラム１２５１により設定される。また、これらの情報の利用、設定、変更方法は後述する。
【００４５】
図６は、本実施例における論理ボリューム情報の構成例を示した図である。
ストレージＩＤ６００１は、本計算機システムにおいてストレージシステムを一意に識別するためのＩＤを格納する。
論理ＶＯＬＩＤ６００２は、ストレージＩＤ６００１により示されるストレージシステムの論理ボリュームを一意に識別するためのＩＤを格納する。以降のフィールドは、ストレージＩＤ６００１と論理ＶＯＬＩＤ６００２により示される論理ボリュームに関する情報を格納する。
【００４６】
物理ボリューム６００３は、論理ボリュームに対応付けられた物理ボリュームを一意に識別するためのＩＤを格納する。
容量６００４は論理ボリュームの容量を格納する。
使用状況６００５は論理ボリュームの使用状況を格納する。使用されている場合は、使用中のアプリケーションＩＤを格納する。
属性６００６は論理ボリュームの属性を格納する。使用状況６００５にアプリケーションＩＤが格納されている場合は、正論理ボリュームとして使われているか、副論理ボリュームとして使われているかを示す文字列が格納される。また、バッファボリュームとして指定されている場合は、バッファボリュームを示す文字列が格納される。なお、バッファボリュームの使われ方については後述する。未使用のボリュームについては未使用を示す文字列が格納される。
サイトＩＤ６００７は、ストレージシステム及び論理ボリュームが属するサイトのＩＤを格納する。
【００４７】
ストレージＩＤ６００１、論理ボリュームＶＯＬＩＤ６００２、物理ＶＯＬＩＤ６００３、容量６００４は、管理計算機の構成構築プログラム４０１０が管理ネットワーク１３００を介しストレージシステムの制御プログラム２０３２から取得する。この取得処理については、本発明に関わる分野に精通する技術者にとっては明らかであるため、説明を省略する。
【００４８】
同一のアプリケーションにより使用されている属性が「正」の論理ボリューム（正論理ボリューム）と属性が「副」の論理ボリューム（副論理ボリューム）は、リモートコピーペアを形成していることを示す。
【００４９】
使用状況６００５、属性６００６、サイトＩＤ６００７については、ユーザ入力にもとづき構成構築プログラム４０１０により設定される。使用状況６００５は初期値として未使用を示す「−」(ハイフン)が格納される。属性６００６は初期値として未使用を示す文字列が格納される。論理ボリュームをバッファボリュームに指定する場合は、構成構築プログラム１２５１を起動し、対象となる論理ボリュームのＩＤとバッファボリュームに指定する旨を入力することにより、対応する属性６００６にバッファボリュームを示す文字列が格納される。バッファボリューム、未使用以外の使用状況を示す値を設定する方法については後述する。また、サイトＩＤ６００７にサイトＩＤを登録する場合は、構成構築プログラム４０１０を起動し、対象となる論理ボリュームのＩＤとサイトＩＤを入力することにより、対応するサイトＩＤ６００７に入力されたサイトＩＤが登録される。
【００５０】
図７は、本実施例における物理ボリューム情報４０１５の構成例を示した図である。
ストレージＩＤ７００１は、本計算機システムにおいてストレージシステムを一意に識別するためのＩＤを格納する。
物理ＶＯＬＩＤ７００２は、ストレージＩＤ４００１により示されるストレージシステム内の物理ボリュームを一意に識別するためのＩＤを格納する。
性能４００３は、物理ＶＯＬＩＤ４００３により示される物理ボリュームの性能を格納する。本構成例では、一秒間に可能なＩ／Ｏの回数を示すＩＯＰＳにより示されるが、他の形式でも良い。なお、論理ボリュームの性能は、上記の通り、該論理リュームに対応する物理ボリュームの性能である。また、論理ボリュームが複数の物理ボリュームの記憶領域より形成されている場合には、論理ボリュームの性能は、該複数の物理ボリュームのうち最も性能の低い物理ボリュームの性能である。
これらの情報は、管理計算機の構成構築プログラム４０１０が管理ネットワーク１３００を介しストレージシステムの制御プログラム２０３２から取得する。この取得処理については、本発明に関わる分野に精通する技術者にとっては明らかであるため、説明を省略する。
【００５１】
図８は、本実施例におけるデータ移行性能情報４０１６の構成例を示した図である。
ストレージＩＤ８００１は、本計算機システムにおいてストレージシステムを一意に識別するためのＩＤを格納する。
データ移行速度８００２は、ストレージＩＤ８００１により示されるストレージシステムの内部においてＣＰＵにて実行されるデータの移行を行う速度を格納する。本構成例では、一秒間に移行可能なデータ量（帯域）により示されるが、他の形式でも良い。
【００５２】
図９は、本実施例において構成構築プログラム４０１０がディザスタリカバリ構成を構築する際の処理の流れを示した図である。
まず、構成構築プログラム４０１０は起動されると、管理計算機の入力装置よりユーザより要件を受け付ける（ステップ９０１０）。要件の内容としては、（ａ）アプリケーションのＩＤと、（ｂ）ボリュームの容量と、（ｃ）通常時要求性能と、（ｄ）被災時要求性能と、（ｅ）被災時性能劣化許容時間と、（ｆ）通常運用時にアプリケーションが稼動するサイトのＩＤ、（ｇ）通常時にアプリケーションが稼動するホスト計算機のＩＤ、（ｈ）被災時にアプリケーションが稼動するホスト計算機のＩＤである。
【００５３】
ユーザからの入力を受け付けると、構成構築プログラム４０１０は、（ｆ）のサイト内の未使用なボリュームで、（ｂ）の容量と（ｃ）の性能を満たすボリュームを、論理ボリューム情報４０１４及び物理ボリューム情報４０１５を参照して探索する（ステップ９０２０）。
ステップ９０２０で該当する論理ボリュームを発見した場合、構成構築プログラム４０１０は、ステップ９１００に進む。なお、以降の説明では、発見した論理ボリュームを第一の論理ボリュームと呼ぶ。ステップ９１００では、構成構築プログラム４０１０は、（ｆ）が示すサイト（正サイト）とは異なるサイトであり、（ｈ）のホスト計算機が含まれるサイト（副サイト）から（ｂ）の容量と（ｄ）の性能を満たすボリュームを論理ボリューム情報４０１４及び物理ボリューム情報を参照して探索する（ステップ９１００）。
【００５４】
ステップ９１００で該当する論理ボリュームを発見した場合、構成構築プログラム４０１０は、ステップ９１１０に進む。なお、以降の説明では、発見した論理ボリュームを第二の論理ボリュームと呼ぶ。
【００５５】
ステップ９１１０では、構成構築プログラム４０１０は、第一の論理ボリュームを正論理ボリュームとして、第二の論理ボリュームを副論理ボリュームとしてリモートコピー構成を構築する指示を、制御プログラム２０３２に対して送信する。また、構成構築プログラム４０１０は、第一の論理ボリュームを（ｇ）のホスト計算機に割り当てる。また、構成構築プログラム４０１０は、第二の論理ボリュームを（ｈ）のホスト計算機に割り当てる（ステップ９１１０）。
【００５６】
次に、構成構築プログラム４０１０は、（ａ）をアプリケーションＩＤ５００１に、（ｃ）を通常時要求性能５００２に、（ｄ）を被災時要求性能５００３に、（ｅ）を性能劣化許容時間５００４に、（ｆ）をサイトＩＤ５００５に、（ｇ）を通常時ホストＩＤ５００６に、（ｈ）を被災時ホストＩＤ５００７に設定する。また、構成構築プログラム４０１０は、設定したリモートコピー構成の内容に応じて使用状況６００５と物理ＶＯＬＩＤ６００３を更新する（ステップ９１２０）。そして構成構築プログラム４０１０は、処理を終了する。
【００５７】
ステップ９０２０で該当する論理ボリュームを発見できなかった場合、（ｆ）が示すサイト内で、未使用かつ（ｂ）の容量を満たす論理ボリュームを論理ボリューム情報４０１４を参照して探索する（ステップ９０３０）。
ステップ９０３０で該当するボリュームを発見できなかった場合、構成構築プログラム４０１０は、構成を構築できない旨を出力装置を介してユーザに通知して（ステップ９１３０）、処理を終了する。
ステップ９０３０で該当する論理ボリュームを発見できた場合、構成構築プログラム４０１０は、ステップ９０４０に進む。なお、以降の説明では、発見した論理ボリュームを第一の代替ボリュームと呼び、この時点で第一の代替ボリュームに対応付けられている物理ボリュームを第一の物理ボリュームと呼ぶ。構成構築プログラム４０１０は、第一の代替ボリュームが属するストレージシステム内の副論理ボリュームであること、（ｂ）の容量を満たしていること、（ｃ）の性能要件を超えることを条件に論理ボリュームを探索する（ステップ９０４０）。また、第一の代替ボリュームが属するストレージシステム内の副論理ボリュームであること、（ｂ）の容量を満たしていること、第一の代替ボリュームより性能がよいこと、（ｃ）の性能要件に最も近い性能を持つこと、を条件に論理ボリュームを探索してもよい。
【００５８】
ステップ９０４０で該当する論理ボリュームを発見できた場合、構成構築プログラム４０１０は、ステップ９０５０に進む。なお、以降の説明では、発見した論理ボリュームを第二の代替ボリュームと呼び、この時点で第二の代替ボリュームに対応付けられている物理ボリュームを第二の物理ボリュームと呼ぶ。
【００５９】
ステップ９０５０では、構成構築プログラム４０１０は、第二の代替ボリュームに対応する第二の物理ボリュームに格納されるデータを第一の代替ボリュームに対応する第一の物理ボリュームに移行させ、第一の物理ボリュームを第二の代替ボリュームに割り当て、第二の物理ボリュームを（ａ）のアプリケーションの正論理ボリュームとして用いられる第一の代替ボリュームに割り当てたことを想定し、被災時に発生する処理をシミュレーションする(ステップ９０５０)。
本シミュレーションでは、被災時の性能回復の可否と、各アプリケーションに対する被災時性能劣化時間を算出する。本構成例では、被災時には図１２の説明で示す方法でボリュームの入れ替えを行うため、本シミュレーションはこれに従う。
図１２のシミュレーションにて、第一の物理ボリュームが割り当てられている第二の代替ボリュームに関してエラー通知１２０９０が必要になる場合があるか否かを判断する。そして、エラー通知１２０９０が必要になる場合には、被災時の性能回復の不可と判断する。また、エラー通知１２０９０が必要ではなく、被災時の性能回復の可と判断された場合には、被災時性能要求を満たすために第二の代替ボリュームのデータ移行に要する時間を算出する。算出された時間は、被災時性能劣化時間となる。被災時性能劣化時間は、第二の代替ボリュームに対応する第一の物理ボリュームに格納されるデータサイズと、データ移行性能情報４０１６のデータ移行速度をもとに算出することが可能である。具体的には、ストレージシステム「ＳＴＧ２」の論理ボリューム「ＬＵ０２」に割り当てられる物理ボリューム内の１００Ｇのデータを、データスピード４００ＭＢ／Ｓで他の物理ボリュームに移行する場合には、２５０秒の時間を要する。
【００６０】
また、被災時の性能回復するために、第二の代替ボリュームと他のボリュームとをバッファボリュームを用いてスワップ処理を行う場合には、第二の代替ボリュームに格納されるデータサイズと、データ移行性能情報４０１６のデータ移行速度に加えて、さらに他のボリュームに格納されるデータサイズを用いて被災時性能劣化時間を算出する。具体的には、他のボリュームに対応付けられる物理ボリュームに格納されるデータを、バッファボリュームに対応付けられる物理ボリュームに移行する時間と、第二の代替ボリュームに対応付けられる物理ボリュームに格納されるデータを、他のボリュームに対応付けられる物理ボリュームに移行する時間との和が、被災時性能劣化時間である。
なお、本構成例では、図１２で示す方法をボリューム入れ替えのアルゴリズムとして用いるが、他のアルゴリズムでボリューム入れ替えを行う場合は、それに応じた方法で性能劣化時間の算出する必要がある。
そして、第二の代替ボリュームのうち、被災時の性能回復の可と判断され、性能劣化許容時間が被災時性能劣化時間を越えるボリュームを選択する。そして、選択されたボリュームを新たに第二の代替ボリュームとする。
【００６１】
ステップ９０４０で該当する論理ボリュームを発見できなかった場合、構成構築プログラム４０１０は、ステップ９０５０はスキップする。
【００６２】
次に、構成構築プログラム４０１０は、通常時性能要求を満たすように第一の代替ボリュームと第二の代替ボリュームを用いた代替構成を、出力画面を介してユーザに提示する(ステップ９０６０)。ここで表示される代替構成には二つのタイプがある。
代替構成タイプ１は、第一の代替ボリュームを正論理ボリュームとして使用する構成である。代替構成タイプ２は、通常運用時には第二の代替ボリュームに対応付けられる第二の物理ボリュームを第一の代替ボリュームに対応付けて正論理ボリュームとして利用する。そして、もともと第二の代替ボリュームを副論理ボリュームとしてペアを組む正論理ボリュームが含まれるサイトが被災した場合、第一の代替ボリュームの物理ボリュームを正論理ボリュームとして利用する構成である。ユーザは本ステップで提示する画面から、代替構成タイプ１と代替構成タイプ２と構築中断の三つの選択肢から処理の流れを選ぶことができる。本画面の構成例は図１０を用いて説明する。
【００６３】
構成構築プログラム４０１０は、ステップ９０６０で出力装置に提示した画面によりユーザからの入力を入力装置より受け付ける（ステップ９０７０）。以下、「構築中断」「代替構成タイプ２」「代替構成タイプ１」に分けてステップ９０７０以降の処理を説明する。
【００６４】
ステップ９０７０の入力が構築中断を示す値である場合、環境構築を中断した旨をユーザに提示し（ステップ９１３０）、処理を終了する。
【００６５】
ステップ９０７０の入力が代替構成タイプ２を示す値である場合、構成構築プログラム４０１０は、第一の代替ボリュームと第二の代替ボリュームをスワップする（ステップ９０９０）。具体的には、第二の代替ボリュームに対応付けられる第二の物理ボリュームに格納されているデータを、第一の代替ボリュームに対応付けられる第一の物理ボリュームへ移行するように、制御プログラム１０３２に指示する。そして、制御プログラムは、第二の代替ボリュームに対応付けられる第二の物理ボリュームに格納されているデータを、第一の代替ボリュームに対応付けられる第一の物理ボリュームへ移行する。
なお、制御プログラム１０３２は、論理ボリュームと物理ボリュームの対応付けの変更処理も行う。つまり、制御プログラム１０２３は、第二の代替ボリュームへの第二の物理ボリュームの対応付け（割り当て）を解消する。そして、制御プログラム１０２３は、第二の代替ボリュームに、第一の代替ボリュームに対応付けられていた第一の物理ボリュームを対応付ける。さらに、制御プログラム１０２３は、第一の代替ボリュームに第二の代替ボリュームに対応付けられていた第二の物理ボリュームを対応付ける。以上が、スワップの処理である。
【００６６】
ステップ９０７０の入力が代替構成タイプ１を示す値である場合、構成構築プログラム４０１０は、ステップ９０９０をスキップする。
次に、構成構築プログラム４０１０は、ステップ９１００に進む。このステップは前述のとおりである。
次に、構成構築プログラム４０１０は、ステップ９１１０に進む。以下に、前述のステップ９１１０との差分を示す。リモートコピーの正論理ボリュームとして設定されるボリュームは、第一の代替ボリュームとなる。なお、ステップ９０７０で代替構成タイプ２を選択した場合、第一の代替ボリュームには、ステップ９０９０のスワップ前に、第二の代替ボリュームに対応付けられていた第二の物理ボリュームが対応付けられている。また、構成構築プログラム４０１０は、第一の代替ボリュームを（ｇ）のホスト計算機に割り当てる。また、構成構築プログラム４０１０は、第二の論理ボリュームを（ｈ）で指定されたホスト計算機に割り当てる。
次に、構成構築プログラム４０１０は、ステップ９１２０に進む。このステップは、前述のものとほぼ同じであるため、差分だけ示す。通常時要求性能５００２には、第一の代替ボリュームに、ステップ９０３０の時点で対応付けられていた物理ボリュームの性能が設定される。そして構成構築プログラム４０１０は、処理を終了する。以上が、構成構築プログラム１２５１の処理の流れである。
【００６７】
図１０は、本実施例において、図９のステップ９０６０において表示される代替構成提案画面の構成例を示す図である。
本構成例では、三つの選択肢をユーザに提示している。ユーザは選択肢１００１０、選択肢１００２０、選択肢１００３０のいずれかを選択した後に、ボタン７０４０を押下することで、代替構成を受け入れ可否と、受け入れる可の場合の受け入れ大体構成のタイプを構成構築プログラム４０２０に対して入力することができる。
選択肢１００１０は、代替構成タイプ１を許可する選択肢である。選択肢の下には通常時要求性能に対する代替構成タイプ１における性能が表示されている。通常運用時の性能は要求性能を下回ることが示される。
選択肢１００２０は、代替構成タイプ２を許可する選択肢である。選択肢の下には通常時要求性能に対する代替構成タイプ２における性能が表示されている。通常運用時は、正論理ボリュームにおいて要求性能を上回る性能又は要求性能に近い性能を提供できるが、他のサイトが被災したときに要求性能を下回ることが示される。なお、本選択肢は、ステップ９０４０で該当する副論理ボリュームが発見されること、ステップ９０５０で算出した被災時性能劣化時間が各アプリケーションの被災時性能劣化許容時間を下回ること、ステップ９０５０で被災時に性能回復が可能であることが判明すること、を全て満たしたときのみ活性化される。
選択肢１００３０は、代替構成を受け入れず、構成の構築を中断することを示す選択肢である。
以上が、図９のステップ９０６０においてユーザに表示する画面の構成例である。
なお、本構成例では、選択肢１００２０の活性・不活性を制御する際に、ステップ９０５０で算出した被災時性能劣化時間が各アプリケーションの被災時性能劣化許容時間を下回るかを判断したが、別の構成例として、ステップ９０５０で算出した各アプリケーションの被災時性能劣化時間を選択肢１００２０の下に表示し、この画面上でその値が許容可能かを判定するようにしても良い。この場合は、ステップ９０１０における(e)の入力と性能劣化許容時間５００４の管理を省略することができる。この構成は、計算機システム内のアプリケーションを管理するユーザが少数であり、性能劣化許容時間がユーザ間で共有されている場合に有効である。
【００６８】
図１１は、本実施例において稼動監視プログラムの動作のフローチャートの一例を示す図である。具体的には、稼働状況監視プログラム４０１１が稼働中のディザスタリカバリ環境内の正論理ボリュームへのアクセス状況を監視し、正論理ボリュームの性能が不十分である場合に、ユーザの指示に応じて正論理ボリュームに対応付けられた物理ボリュームを他の物理ボリュームへの移行させる処理の流れを示した図である。
【００６９】
稼働状況監視プログラム４０１１は、デーモンプロセスとして計算機システム内で起動し続けている。まず、稼働状況監視プログラム４０１１は所定の時間待機する（ステップ１１０１０）。なお、この所定の時間は、ユーザにより指定されても良いし、プログラム内にコーディングされていても良い。
所定の時間経過後、稼働状況監視プログラム４０１１は、計算機システム内の正論理ボリュームを検索する。そして、それぞれの検索された正論理ボリュームを対象にして、ステップ１１０２０〜ステップ１１１２０の処理を繰り返す。なお、以降の説明では、対象となる正論理ボリュームを対象正論理ボリュームと呼び、対象正論理ボリュームに対応する物理ボリュームを第一の物理ボリュームと呼ぶ。
まず、稼働状況監視プログラム４０１１は、対象正論理ボリュームへの単位時間当たりのアクセス量を取得する（ステップ１１０３０）。
次に、稼働状況監視プログラム４０１１は、その単位時間当たりのアクセス量が対象正論理ボリュームの性能を上回っているか、又は上回る可能性があるかを判定する（ステップ１１０４０）。本ステップでの判定では、ステップ１１０３０にて取得した単位時間当たりのアクセス量が一定の閾値を超えた場合に上回る可能性があると判定しても良いし、ステップ１１０３０にて取得した値の履歴をとっておき、トレンド分析により上回る可能性があると判定しても良い。
【００７０】
ステップ１１０４０の判定の結果、上回る可能性がないと判定された場合、稼働状況監視プログラム４０１１は、ステップ１１０２０に移行し、次の正論理ボリュームを対象とした処理に移行する。
【００７１】
ステップ１１０４０の判定の結果、上回る可能性があると判定された場合、稼働状況監視プログラム４０１１は、バッファボリュームの有無を判定する（ステップ１１０５０）。本ステップでは、稼働状況監視プログラム４０１１は、対象正論理ボリュームが属するストレージシステムにおいて、対象正論理ボリュームと同じ容量又は対象正論理ボリュームの容量を上回る容量を持ち、かつ、バッファボリュームに指定されている論理ボリュームが存在するかを、論理ボリューム情報４０１４を用いて判定する。
ステップ１１０５０の判定の結果、該当する論理ボリュームが無い場合、稼働状況監視プログラム４０１１は、対象正論理ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ１１１３０）、ステップ１１０２０に移行し、次の正論理ボリュームを対象とした処理に移行する。
【００７２】
ステップ１１０５０の判定の結果、該当する論理ボリュームを発見した場合、稼働状況監視プログラム４０１１は、ステップ１１０６０へ進む。ステップ１１０６０では、稼働状況監視プログラム４０１１は、対象正論理ボリュームが属するストレージシステム内で、対象正論理ボリュームよりも性能の良い副論理ボリュームを論理ボリューム情報４０１４から探索する（ステップ１１０６０）。本実施例においては、性能のよい論理ボリュームとは、該論理ボリュームを形成する物理ボリュームのＩＯＰＳの値が大きい論理ボリュームを意味する。
【００７３】
ステップ１１０６０の結果、該当する副論理ボリュームが無い場合、稼働状況監視プログラム４０１１は、対象正論理ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ１１１３０）、ステップ１１０２０に移行し、次の正論理ボリュームの処理に移行する。
【００７４】
ステップ１１０６０の結果、稼働状況監視プログラム４０１１は、該当する副論理ボリュームを発見した場合、ステップ１１０７０に進む。なお、以降の説明では、発見した副論理ボリュームを代替ボリュームと呼び、この時点で代替ボリュームに対応付けられている物理ボリュームを第二の物理ボリュームと呼ぶ。ステップ１１０７０では、稼働状況監視プログラム４０１１は、被災時の処理のシミュレーションを行うことにより、被災時の性能回復可否と性能劣化時間を算出する（ステップ１１０７０）。性能回復時間と性能劣化時間の算出方法は、ステップ９０５０にて示した通りである。
【００７５】
ステップ１１０７０のシミュレーションの結果、被災時に性能回復が可能であるかを判定する。(ステップ１１０７５)また、被災時性能劣化時間が、代替ボリュームを使用するアプリケーションの性能劣化許容時間を越えるか否かを判定する。そして、被災時に性能回復が不可である場合、又は被災時性能劣化時間が、代替ボリュームを副論理ボリュームとして使用するアプリケーションの性能劣化許容時間を越える場合には、ユーザに警告を通知した後（ステップ１１１３０）、ステップ１１０２０に移行し、次の正論理ボリュームを対象とした処理に移行する。
【００７６】
次に、稼動状況監視プログラム４０１１は、代替構成をユーザに提示する（ステップ１１０８０）。ここで表示される代替構成のタイプは一つだけである。代替ボリュームと対象正論理ボリュームをスワップする構成である。ユーザは、この構成を選択するか、現在の構成を継続するかの二つの選択肢から処理を選ぶこができる。なお、本画面の構成は、選択肢が前述の二つに変わる以外は図１０と同じであるため図示は省略する。
【００７７】
ステップ１１０８０で表示された画面によりユーザの入力を受け付ける（ステップ１１０９０）
ステップ１１０９０で受け入れたユーザの入力が現在の構成を継続することを示している場合、対象正論理ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ１１１３０）、ステップ１１０２０に移行し、次の正論理ボリュームを対象とした処理に移行する。
ステップ１１０９０で受け入れたユーザの入力が代替構成を受け入れることを意味している場合、稼動状況監視プログラム４０１１は、対象正論理ボリュームと代替ボリュームをスワップする（ステップ１１１００）。具体的には、代替ボリュームに対応する第二の物理ボリュームに格納されるデータを、バッファボリュームに対応する物理ボリュームへ移行するように、制御プログラム２０３２に指示する。指示を受けた制御プログラム２０３２は、代替ボリュームに対応する第二の物理ボリュームに格納されるデータを、バッファボリュームに対応する物理ボリュームへ移行する。その後、対象正論理ボリュームに対応付けられている第一の物理ボリュームに格納されるデータを、代替ボリュームに対応する第二の物理ボリュームへ移行するように、制御プログラム２０３２に指示する。指示を受けた制御プログラム２０３２は、対象正論理ボリュームに対応付けられている第一の物理ボリュームに格納されるデータを、代替ボリュームに対応する第二の物理ボリュームへ移行する。
【００７８】
なお、このデータの移行は前述のとおり、制御プログラム２０３２が、論理ボリュームと物理ボリュームの対応付けの変更処理を行う。具体的には、まず、制御プログラム２０３２は、代替ボリュームに、バッファボリュームに対応付けられていた物理ボリュームを対応付ける。次に、制御プログラム２０３２は、対象正論理ボリュームに、第一の代替ボリュームに対応付けられていた第二の物理ボリュームを対応付ける。
【００７９】
最後に働状況監視プログラム４０１１は、設定した内容に応じて使用状況６００５と属性６００６と物理ＶＯＬＩＤ６００３を更新する（ステップ１１１１０）。そして構成構築プログラム４０１１は、ステップ１１０２０に戻り、次の正論理ボリュームを対象に処理を続ける。
【００８０】
全正論理ボリュームに対して、ステップ１１０２０からステップ１１１２０までの処理が完了したら、働状況監視プログラム４０１１は、ステップ１１０１０に戻る。
以上が、働状況監視プログラム４０１１の処理の流れである。
【００８１】
図１２は、被災時復旧プログラム４０１２が、被災時に各アプリケーションが要求する性能を持つボリュームを割り当てなおす処理の流れを示した図である。図１２は、実際にあるサイトが被災した場合の処理を示す。図９の９０５０や、図１１の１１０７０でのシミュレーションは、図１２の処理の流れに沿って、データ移行する論理ボリュームと、データ移行先を決定する。
【００８２】
被災時復旧プログラム４０１２は、一方のサイトが被災した時に、被災していない側のサイトＩＤをパラメータとして起動される。被災時復旧プログラム４０１２は、起動すると、一方のサイトが被災した後に被災していないサイトのホスト計算機にて実行されるアプリケーションのうち、要求性能の高いもの順にアプリケーションのソートを行う（ステップ１２０１０）。本ソートでは、パラメータとして入力されたサイトＩＤとサイトＩＤ５００５を比較し、一致するアプリケーションは通常時要求性能５００２を要求性能とし、一致しないアプリケーションは、被災時要求性能５００３を要求性能としてソートを行う。パラメータとして入力されたサイトＩＤとサイトＩＤ５００５とが一致するアプリケーションは、一方のサイトが被災する前から、被災していない側のサイトを正サイトとして利用していたアプリケーションである。パラメータとして入力されたサイトＩＤとサイトＩＤ５００５とが一致しないアプリケーションは、一方のサイトが被災する前には、被災していない側のサイトを副サイトとして利用していたアプリケーションである。
【００８３】
その後、被災時復旧プログラム４０１２は、アプリケーションをソートした順番に一つずつ対象として、ステップ１２０２０〜ステップ１２０８０までの処理を繰り返す。なお、以降の説明では、対象となっているアプリケーションを対象アプリケーションと呼ぶ。
【００８４】
まず、被災時復旧プログラム４０１２は、ステップ１２０１０で用いた要求性能と、対象アプリケーションが利用している論理ボリュームの性能を比較する（ステップ１２０３０）。
要求性能を満たしている場合は、被災時復旧プログラム４０１２は、ステップ１２０２０に戻り、次のアプリケーションを対象に処理を続ける。
要求性能を満たしていない場合は、対象アプリケーションが利用している論理ボリュームと同じストレージシステムに属すること、要求性能を満たすこと、を条件に論理ボリュームを探索する（ステップ１２０４０）。また、さらに、バッファボリュームに指定されていないこと、対象アプリケーションより要求性能の高いアプリケーションに使用されていないことを条件に論理ボリュームを探索してもよい（ステップ１２０４０）。
【００８５】
ステップ１２０４０の結果、該当するボリュームを発見できなかった場合は、ユーザにエラーを通知した後（ステップ１２０９０）、異常終了する。
【００８６】
ステップ１２０４０の結果、該当するボリュームを発見できた場合は、被災時復旧プログラム４０１２は、ステップ１２０５０に進む。なお、発見したボリュームを第一の代替ボリュームと呼ぶ。ステップ１２０５０では、被災時復旧プログラム４０１２は、対象アプリケーションが利用する論理ボリューム以上の容量のバッファボリュームを探索する（ステップ１２０５０）。探索の結果、該当するボリュームを発見できなかった場合は、ユーザにエラーを通知した後（ステップ１２０９０）、異常終了する。
【００８７】
ステップ１２０５０の結果、該当するボリュームを発見できた場合は、被災時復旧プログラム４０１２は、対象アプリケーションが利用している論理ボリュームと第一の代替ボリュームをスワップする指示をストレージシステムに発行する（ステップ１２０６０）。スワップ指示を受信したストレージシステムの制御プログラムは、第一の代替ボリュームに対応する物理ボリュームに格納されるデータをバッファボリュームに対応する物理ボリュームに移行させる。次に、制御プログラムは、対象アプリケーションが利用する論理ボリュームに対応する物理ボリュームのデータを、第一の代替ボリュームに対応付けられていた物理ボリュームに移行する。そして、制御プログラムは、第一の代替ボリュームに対応する物理ボリュームからバッファボリュームに対応する物理ボリュームに移行されたデータを、アプリケーションが利用する論理ボリュームに対応付けられていた物理ボリュームに移行する。そして、制御プログラムは、第一の代替ボリュームに対応していた物理ボリュームを、アプリケーションが利用する論理ボリュームに割り当てる。また、制御プログラムは、アプリケーションが利用する論理ボリュームに対応していた物理ボリュームを、第一の代替ボリュームに割り当てる。
【００８８】
なお、第一の代替ボリュームにデータが格納されていない場合には、バッファボリュームを使用せずに、対象アプリケーションが利用している論理ボリュームに対応する物理ボリュームに格納されているデータを、第一の代替ボリュームに対応する物理ボリュームに移動してもよい。
【００８９】
最後に、被災時復旧プログラム４０１２は、ステップ１２０６０にて設定した内容に応じて使用状況６００５、属性６００６、物理ＶＯＬＩＤ６００３を更新する（ステップ１２０７０）。
以上が、被災時復旧プログラム４０１２の処理の流れである。
【００９０】
なお、本構成例では、データの移行方法をボリューム単位としたが、ページ単位でこれを行っても良い。また、性能劣化許容時間が一定以上となる場合は、ページ単位でのデータ移行を用いて、書き込みが発生した場合だけ要求性能を満たす物理ボリュームからページを割り当てる方式をとっても良い。
以上が、第一の実施例の説明である。
【００９１】
本実施例によれば、Ａｃｔｉｖｅ−Ａｃｔｉｖｅのディザスタリカバリ構成において、被災時に性能劣化許容時間内で元の状態に戻せる場合、副論理ボリュームとして割り当てられている高性能な物理ボリュームをその副論理ボリュームが存在するサイトで稼動するアプリケーションの正論理ボリュームとして使用させることができる。これにより、高性能なボリュームが副論理ボリュームとして割り当てられているため、いかしきれていなかった性能を生かすことができるようになり、ストレージシステム全体としての利用率を向上させることができる。
【第二の実施例】
【００９２】
次に、第二の実施例について説明する。
本実施例では、計算機システムに含まれるホスト計算機は、複数の仮想的なホスト計算機を稼動させるホスト計算機である。仮想的なホスト計算機のことを仮想サーバあるいは仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ、ＶＭ）と呼ぶ。また、説明の明確化のため、仮想サーバを稼動させていているホスト計算機のことを物理サーバと呼ぶ。
【００９３】
本発明を適用する計算機システムに含まれるホスト計算機に仮想サーバを構築することで、ストレージシステムの利用率を向上させることができる。第一の実施例においても同様の効果を得ることができた。しかし、ストレージシステムの利用率が、ホスト計算機のデータＩ／Ｆの性能に依存し、高性能な物理ボリュームの性能を十分に利用することができない場合もある。一方、仮想サーバには仮想的なデータＩ／Ｆを割り当てることができる。本実施例では、割り当てなおされた物理ボリュームの性能にあわせて仮想的なデータＩ／Ｆを割り当てなおすことで上記問題に対応する。以降、この仮想的なデータＩ／Ｆを仮想データＩ／Ｆと呼ぶ。
【００９４】
また、単一の物理サーバ上に複数の仮想サーバが稼動する場合、仮想データＩ／Ｆの性能を保証するためには、それぞれの仮想サーバの仮想データＩ／Ｆの性能が物理サーバのデータＩ／Ｆの性能以下である必要がある。このため、物理サーバのデータＩ／Ｆの性能と、物理サーバ上に稼動する他の仮想サーバの仮想データＩ／Ｆ性能により、本発明により割り当てなおされた物理ボリュームの性能に適した仮想データＩ／Ｆを割り当てなおすことができない可能性がある。仮想サーバ環境においては、仮想サーバを物理サーバ間で移行させることができるため、本実施例では、適切なデータＩ／Ｆを持つ物理サーバを探索し、仮想サーバをその物理サーバへ移行させることで、上記問題に対応する。以下、実施方式を説明する。
【００９５】
（２−１）第二の実施例のシステム構成
本実施例において計算機システムの構成は、第一の実施例とほぼ同等であるため、主に差異について説明する。
本実施例において計算機システムの構成の概要は図１と同様であり、図示はしない。
ホスト計算機Ａ１１０１、ホスト計算機Ｂ１２０２、ホスト計算機Ｃ１２０１、ホスト計算機Ｄ１１０２は物理サーバであり、内部で複数の仮想サーバが稼動する。
図１の計算機システムとの違いを以下に示す。本実施例においては、ホスト計算機Ｄ１１０２がデータネットワークに接続する。そして、ホスト計算機Ｄ１１０２は、データネットワークＡ１１０４を介して論理ボリュームＡ１１１１へアクセスする。また、ホスト計算機Ｃ１２０１は、データネットワークＢ１２０４に接続する。ホスト計算機Ｃ１２０１は、データネットワークＢ１２０４を介して論理ボリュームＢ１２１２へアクセスする。
【００９６】
該相違点は、ホスト計算機Ａ１１０１とホスト計算機Ｄ１１０２の間で、あるいは、ホスト計算機Ｂ１２０２とホスト計算機Ｃ１２０１の間で、仮想サーバを移行させ、移行後においてもストレージシステムにアクセスできるようにするためのものである。仮想サーバ環境における仮想サーバの移行は、使用する論理ボリュームを含めた仮想サーバの構成情報と稼動状態に関する情報を、第一の物理サーバから第二の物理サーバへ移動させ、第二の物理サーバでその構成情報と稼動状態に関する情報を復元する。このため、仮想サーバからアクセスされる論理ボリュームは、第一の物理サーバと第二の物理サーバのどちらからもアクセス可能にしておく必要がある。
【００９７】
図１３は、本実施例におけるストレージシステム１１０３、ストレージシステム１２０３の構成例を示した図である。本実施例では、制御プログラム２０３２により、論理ボリューム２０１２が一つ以上の領域に分割されて管理されている。この領域を論理ページと呼ぶ。また、物理ボリューム２０１１も、制御プログラム２０３２により、一つ以上の領域に分割され、管理されている。この領域を物理ページと呼ぶ。制御プログラム２０３２は、論理ページと物理ページの対応付けを管理している。この対応付けを論物ページマップと呼ぶ。制御プログラム２０３２は、論理ボリューム２０１２へのアクセスを、論物ページマップの対応付けにもとづいて、物理ボリューム２０１１へのアクセスに変換し、アクセスの処理を行う。なお、制御プログラム２０３２は、対応付けのなされていない論理ページに書き込みが発生した際に、この論理ページに未使用の物理ページを対応付ける。
【００９８】
また、制御プログラム２０３２は、ユーザや管理計算機の外部プログラムからの指示により、論物ページマッピングの内容を変更することができる。たとえば、制御プログラム２０３２は、ある論理ボリュームのアドレス０ｘ００ｆｆ〜０ｘ０ｆｆｆの論理ページを低性能な物理ボリュームの物理ページから高性能な物理ボリュームの物理ページへ移行するように、ユーザ（又は管理計算機）から指示を受け付ける。すると、制御プログラム２０３２は、指定された論理ページに対応付けられた物理ボリュームのページを特定する。制御プログラム２０３２は、高性能な物理ボリュームの未使用な物理ページを同容量分探し、その物理ページに前記低性能な物理ボリュームの物理ページのデータをコピーする。指定された論理ページをコピー先の物理ページに対応付けなおす。
【００９９】
なお、ホスト計算機の入出力やストレージシステムのリモートコピー機能の入出力では、論理ボリュームのアドレスを用いてデータにアクセスするため、論物ページマップの内容変更による影響を受けることは無い。また、管理計算機における管理プログラムでは、管理の容易化のため、同等の属性を持つ複数の物理ボリュームをプールとして管理する。本実施例でもこれに倣うが、別の実施形態として、物理ボリューム毎に管理するなど、他の管理形態でもかまわない。なお、以降の説明では、このページ間でのデータ移行を伴う論物ページマッピングの内容変更を、ページ間データ移行と呼ぶ。
【０１００】
図１４は、本実施例におけるホスト計算機Ａ１１０１、ホスト計算機Ｂ１２０２、ホスト計算機Ｃ１２０１、ホスト計算機Ｄ１１０２の構成例を示したブロック図である。本実施例では、メモリ３００６上にハイパバイザ１４０１０、ＶＭ割り当てメモリ１４０１１、エージェント１４０１２が格納されている。
【０１０１】
ハイパバイザ１４０１０は、仮想サーバを稼動させるためのプログラムである。ハイパバイザ１４０１０は、自身が稼動する物理サーバ上で稼動する仮想サーバの管理を行う。具体的には、ハイパバイザ１４０１０は仮想サーバに仮想的なボリュームを割り当てる。仮想サーバは、この仮想的なボリュームを用いてデータの書き込み、読み出しを行うことができる。以降、この仮想的なボリュームを仮想ボリュームと呼ぶ。この仮想ボリュームは、物理サーバが使用する論理ボリューム２０１１に、ファイルとして格納される。以降、このファイルを仮想ボリュームファイルと呼ぶ。
【０１０２】
また、ハイパバイザ１４０１０は仮想サーバに、仮想的なメモリを割り当てることができる。仮想サーバは、この仮想的なメモリ上でアプリケーションを稼動させることができる。以降、この仮想的なメモリを仮想メモリと呼ぶ。
また、ハイパバイザ１４０１０は仮想サーバに、アクセス性能を属性として持つ仮想的なデータＩ／Ｆを割り当てることができる。この仮想的なデータＩ／Ｆにより、物理サーバがもつデータＩ／Ｆのアクセス性能の範囲で複数の仮想サーバのアクセス性能を保証することができる。以降、この仮想的なデータＩ／Ｆを仮想データＩ／Ｆと呼ぶ。
また、ハイパバイザ１４０１０は、ユーザや外部プログラムからの指示により、一方の物理サーバから他方の物理サーバへ仮想サーバを移行させることができる。たとえば、ホスト計算機Ａ１１０１上のハイパバイザ１４０１０は、ホスト計算機Ａ１１０１上で稼動している仮想サーバを、ホスト計算機Ｄ１１０２に移行させる指示を受け付けることができる。この指示を受け付けると、ホスト計算機Ａ１１０１上のハイパバイザ１４０１０は、ホスト計算機Ｄ１１０２上のハイパバイザ１４０１０に、仮想サーバに割り当てている仮想メモリと同容量のメモリを確保させる。その後、ホスト計算機Ａ１１０１上のハイパバイザ１４０１０は、ホスト計算機Ｄ１１０２上のハイパバイザ１４０１０に、仮想サーバに割り当てているメモリ内の情報と、仮想データＩ／Ｆや仮想ボリュームなどの仮想サーバの構成情報を転送する。ホスト計算機Ｄ１１０２上のハイパバイザ１４０１０は、これらの情報を受け取ると、受け取ったメモリ内の情報を、ホスト計算機Ｄ１１０２上のメモリ上に確保した領域に格納する。そして、ホスト計算機Ｄ１１０２上のハイパバイザ１４０１０は、受け取った構成情報をもとに仮想サーバを起動する。
【０１０３】
ＶＭ割り当てメモリ１４０１１は、前述した仮想サーバに割り当てた仮想メモリである。
エージェント１４０１２は、仮想サーバの構成情報をハイパバイザ１４０１０から取得するためのプログラムである。後述する管理計算機１５００で稼動するＶＭ構成情報収集プログラム１５００１からの指示により、エージェント１４０１２は、ハイパバイザ１４０１０から情報を取得し、ＶＭ構成情報収集プログラム１５００１にその情報を提供する。
【０１０４】
図１５は、本実施例における管理計算機１５００の構成例を示したブロック図である。
本実施例では、新たにメモリ４００５上に、ＶＭ構成情報収集プログラム１５００１、ＶＭ性能情報１５００２、論理ボリューム構成情報１５００３、ＶＭ構成情報１５００４、物理サーバ情報１５００５、ＶＭ移行性能情報１５００６が格納される。
【０１０５】
ＶＭ構成情報収集プログラム１５００１は、前述したエージェント１４０１２から仮想サーバの構成情報を収集する。ユーザは、本プログラムを物理サーバのＩＤをパラメータとして起動する。起動したＶＭ構成情報収集プログラム１５００１は、指定された物理サーバ上のエージェント１４０１２に構成情報の収集を指示する。指示を受け付けたエージェント１４０１２は、自身が稼動する物理サーバ上で稼動する仮想サーバの情報をハイパバイザ１４０１０から取得する。取得する情報は、仮想サーバに割り当てた仮想メモリの容量、仮想データＩ／Ｆの性能、仮想ボリュームファイルが格納されている論理ボリュームのアドレスなどである。また、エージェント１４０１２はハイパバイザ１４０１０の情報も取得する。取得する情報は、ハイパバイザ１４０１０が仮想サーバに割り当て可能なＩ／Ｏ性能とメモリ量などである。また、エージェント１４０１２は物理サーバ間でのＶＭの移行の際に発生するデータ転送の速度も取得する。エージェント１４０１２は、これらの情報をＶＭ構成情報収集プログラム１５００１に提供する。これらの情報を受け取ったＶＭ構成情報収集プログラム１５００１は、後述する論理ボリューム４０１４、ＶＭ構成情報１５００４、物理サーバ情報１５００５、ＶＭ移行性能情報１５００６に格納する。
【０１０６】
ＶＭ性能情報１５００２、論理ボリューム構成情報１５００３、ＶＭ構成情報１５００４、物理サーバ情報１５００５、ＶＭ移行性能情報１５００６については、別の図で説明する。
【０１０７】
図１６は、本実施例におけるＶＭ性能情報１５００２の構成例を示した図である。
ＶＭ性能情報１５００２は、アプリケーション情報４０１３を仮想サーバ向けに変更したものである。
【０１０８】
アプリケーションＩＤ５００１が、本計算機システムにおいて仮想サーバを一意に示すＶＭＩＤ１６００１に変更されている。
また、通常時ホストＩＤ５００６が、通常時に仮想サーバが稼動する物理サーバを一意に示す、通常時物理サーバＩＤ１６００２に変更されている。
また、被災時ホストＩＤ５００７が、被災時に仮想サーバが稼動する物理サーバを一意に示す、被災時物理サーバＩＤ１６００３に変更されている。
【０１０９】
図１７は、本実施例における論理ボリューム４０１４の構成例を示した図である。
本図は、図６の一部を変更した図である。前述のとおり本実施例では、論物ページマップにより、論理ボリュームはページ単位で物理ボリュームに対応付けられる。これに関わる管理方法については別の図で説明するため、物理ＶＯＬＩＤ６００３は削除されている。
また、論理ボリュームの使用量を示す使用量１７００１が追加される。仮想ボリュームは論理ボリュームにファイルとして格納される。仮想サーバに割り当て可能な仮想ボリュームのサイズは論理ボリュームの空き容量に依る。このため、本実施例では、このテーブルで論理ボリュームの使用量を管理している。この情報は、前述のとおり、ＶＭ構成情報収集プログラム１５００１がエージェント１４０１２から収集する。
【０１１０】
図１８は、本実施例における論理ボリューム構成情報１５００３の構成例を示した図である。これは、前述した論物ページマップの情報を管理するテーブルである。
【０１１１】
ストレージＩＤ１８００１は、本計算機システムにおいてストレージシステムを一意に識別するためのＩＤを格納する。
論理ＶＯＬＩＤ１８００２は、ストレージＩＤ１８００１により示されるストレージシステム内の論理ボリュームを一意に識別するためのＩＤを格納する。
開始アドレス１８００３は、論理ＶＯＬＩＤ１８００２により示される論理ボリューム内のページ（領域）の開始位置を示す。
終了アドレス１８００４は、論理ＶＯＬＩＤ１８００２により示される論理ボリューム内のページ（領域）の終了位置を示す。
ＰｏｏｌＩＤ１８００５は、ストレージＩＤ１８００１、論理ＶＯＬＩＤ１８００２、開始アドレス１８００３、終了アドレス１８００４で示されるページに対応する物理ボリュームが属するプールを、本計算機システムで一意に識別するためのＩＤを格納する。
【０１１２】
これらの情報は、構成構築プログラム４０１０が管理ネットワーク１３００を介し制御プログラム２０３２から取得する。この取得処理については、本発明に関わる分野に精通する技術者にとっては明らかであるため、説明を省略する。
【０１１３】
図１９は、本実施例において物理ボリューム情報４０１５の構成例を示した図である。本図は、図7を本実施例向けに変更したものである。
本実施例では、同等の性能を持つ複数の物理ボリュームをプールとして管理する。このため、物理ＶＯＬＩＤ７００２を、本計算機システムでプールを一意に識別するためのＩＤを格納するＰｏｏｌＩＤ１９００１に変更している。
また、プール内の物理ボリュームは、論理ボリュームに対してページ単位で割り当てられる。特定の性能の物理ページの割り当て可能な量は、その性能のプール内の物理ページの全容量と割り当て済みの容量による。このため、本テーブルで、全体容量と割り当て済みの容量（使用量）を管理する。本テーブルでは、プール全体の容量を格納する容量１９００２と、割り当て済みの容量を格納する使用量１９００３を追加する。
【０１１４】
この情報は、構成構築プログラム４０１０が管理ネットワーク１３００を介し制御プログラム２０３２から取得する。この取得処理については、本発明に関わる分野に精通する技術者にとっては明らかであるため、説明を省略する。
【０１１５】
図２０は、本実施例における、ＶＭ構成情報１５００４の構成例を示した図である。
ＶＭＩＤ２０００１は、本計算機システムにいて仮想サーバを一意に識別するためのＩＤを格納する。以降のフィールドは、本値に示される仮想サーバに関する情報を格納する。
割り当てメモリ量２０００２は、割り当てられた仮想メモリの容量を示す値を格納する。
割り当てデータＩ／Ｆ性能２０００３は、割り当てられた仮想データＩ／Ｆの性能を示す値を格納する。
【０１１６】
ストレージＩＤ２０００４、論理ボリュームＩＤ２０００５、論理ボリュームアドレス２０００６は、割り当てられた仮想ボリュームの仮想ボリュームファイルが格納されている領域を示す値を格納する。
ストレージＩＤ２０００４は、ストレージシステムのＩＤを格納する。論理ボリュームＩＤ２０００５は論理ボリュームのＩＤを格納する。論理ボリュームアドレス２０００６は、ファイルの格納アドレスを格納する。ファイルが複数の領域に渡って格納されている場合、本値は、それぞれをカンマつなぎで列挙した形で示される。
【０１１７】
これらの情報は、前述のとおり、ＶＭ構成情報収集プログラム１５００１がエージェント１４０１２から収集する。
【０１１８】
図２１は、本実施例における物理サーバ情報１５００５の構成例を示した図である。
【０１１９】
物理サーバＩＤ２１００１は、本計算機システムにおいて物理サーバを一意に識別するＩＤを格納する。以降のフィールドは、本値に示される物理サーバに関する情報を格納する。
Ｉ／Ｏ性能２１００２は、物理サーバ上のハイパバイザが仮想サーバに割り当て可能な物理的なデータＩ／Ｆにより処理可能なＩ／Ｏ性能の総和を格納する。
メモリ量２１００３は、物理サーバ上のハイパバイザが仮想サーバに割り当て可能なメモリの容量の総和を格納する。
ストレージＩＤ２１００４は、物理サーバ上のハイパバイザが仮想サーバに割り当てる仮想ボリュームの仮想ボリュームファイルを格納するストレージシステムのＩＤを格納する。
論理ボリュームＩＤ２１００５は、物理サーバ上のハイパバイザが仮想サーバに割り当てる仮想ボリュームの仮想ボリュームファイルを格納する論理ボリュームのＩＤを格納する。
【０１２０】
これらの情報は、前述のとおり、ＶＭ構成情報収集プログラム１５００１がエージェント１４０１２から収集する。
【０１２１】
図２２は、本実施例におけるＶＭ移行性能情報１５００６の構成例を示した図である。
【０１２２】
ソース物理サーバＩＤ２２００１は、本計算機システムにおいて物理サーバを一意に識別するＩＤを格納する。ターゲット物理サーバＩＤ２２００２は、本計算機システムにおいて物理サーバを一意に識別するＩＤを格納する。
速度２２００３は、ソース物理サーバＩＤ２２００１からターゲット物理サーバＩＤ２２００２へＶＭを移行する際に発生するデータ転送の速度を示す値を格納する。
【０１２３】
これらの情報は、前述のとおり、ＶＭ構成情報収集プログラム１５００１がエージェント１４０１２から収集する。
【０１２４】
図２３は、本実施例における構成構築プログラム４０１０がディザスタリカバリ構成を構築する際の処理の流れを示した図である。本処理では、ハイパバイザが管理する論理ボリュームに対してリモートコピーの構成が作成されている前提とする。
【０１２５】
まず、構成構築プログラム４０１０は、入力装置を介してユーザより要件を受け付ける（ステップ２３０１０）。要件の内容としては、（ａ）仮想サーバのＩＤと、（ｂ）仮想ボリュームの容量と、（ｃ）通常時要求性能と、（ｄ）被災時要求性能と、（ｅ）被災時性能劣化許容時間と、（ｆ）通常運用時に仮想サーバが稼動するサイトのＩＤ、（ｇ）通常時に仮想サーバが稼動する物理サーバのＩＤ、（ｈ）被災時に仮想サーバが稼動する物理サーバのＩＤである。
【０１２６】
ユーザからの入力を受け付けると、構成構築プログラム４０１０は、論理ボリュームの空き容量を確認する（ステップ２３０１５）。構成構築プログラム４０１０は、物理サーバ情報１５００５と論理ボリューム情報４０１４から、（ｇ）の通常時に使用する物理サーバが管理する論理ボリュームの中で、（ｂ）の空き容量を満たす論理ボリュームを探索する。この論理ボリュームを第一の論理ボリュームと呼ぶ。また、第一の論理ボリュームを格納するストレージシステムを第一のストレージシステムと呼ぶ。
【０１２７】
ステップ２３０１５において、該当する論理ボリュームがない場合、構成構築プログラム４０１０はユーザに出力装置を介してエラーを通知して処理を終了する（ステップ２３１３０）。
ステップ２３０１５において、該当する論理ボリュームを発見した場合、（ｃ）の性能を満たす物理ボリュームの残り容量が（ｂ）の容量以上であるかを確認する（ステップ２３０２０）。この確認では、発見した論理ボリュームを格納するストレージシステム内で(ｃ)の性能を満たす物理ボリュームのプールに(ｂ)の容量があるかを確認する。これは、物理ボリューム情報４０１５を参照することで可能である。
なお、本判定は、別の実施形態として、(ｂ)の容量ではなく、仮想ボリューム割り当ての際に発生する書き込みにより割り当てられるページの分だけの空き容量があるかを確認する形式でもよい。
【０１２８】
ステップ２３０２０で（ｃ）の性能を満たすプールの残り容量が（ｂ）の容量以上である場合、ステップ２３１００に進む。構成構築プログラム４０１０は、第一の論理ボリュームを正論理ボリュームとするペアにおいて副論理ボリュームとなる論理ボリュームを特定する。この副論理論理ボリュームを格納する第二のストレージシステムにおいて、（ｄ）の性能を満たし、（ｂ）の容量以上の残り容量のある物理ボリュームがあるかを確認する（ステップ２３１００）。
なお、別の実施形態として、仮想サーバに割り当てを行った際に発生する書き込みにより割り当てられるページの分だけ空き容量があるかを確認してもよい。以降、副論理ボリュームを格納するストレージシステムを第二のストレージシステム、特定された論理ボリュームを第二の論理ボリュームと呼ぶ。
【０１２９】
ステップ２３１００において、（ｄ）の性能を満たし、（ｂ）の空き容量があるプールが第二のストレージシステムに存在しない場合、構成構築プログラム４０１０はユーザにエラーを通知して（ステップ２３１３０）処理を終了する。
【０１３０】
ステップ２３１００において、（ｄ）の性能を満たし、（ｂ）の空き容量があるプールが第二のストレージシステムに存在する場合、構成構築プログラム４０１０は、第一の論理ボリュームに仮想ボリュームファイルを作成して、（ａ）の仮想サーバに仮想ボリュームを割り当てるように（ｇ）上のハイパバイザに指示する。また、作成した仮想ボリュームファイルが格納される論理ページに（ｃ）の性能を満たすプールから物理ページを割り与えるように、第一のストレージシステムの制御プログラム２０３２に指示する。また、第二の論理ボリュームの対応する論理ページに（ｄ）の性能を満たすプールから物理ページを割り与えるように第二のストレージシステムの制御プログラム２０３２に指示する（ステップ２３１１０）。
【０１３１】
次に、構成構築プログラム４０１０は、（ａ）をＶＭＩＤ１６００１に、（ｃ）を通常時要求性能５００２に、（ｄ）を被災時要求性能５００３に、（ｅ）を性能劣化許容時間５００４に、（ｆ）をサイトＩＤ５００５に、（ｇ）を通常時物理サーバＩＤ１６００２に、（ｈ）を被災時物理サーバＩＤ１６００３に設定する設定する。また、構成構築プログラム４０１０は、設定した内容に応じてＶＭ構成情報１５００４を更新する（ステップ２３１２０）。そして構成構築プログラム４０１０は、処理を終了する。
【０１３２】
ステップ２３０２０で十分な空き容量が無かった場合、第一のストレージシステム内で、（ｄ）の空き容量を持つプールを物理ボリューム情報４０１５から探索する（ステップ２３０３０）。
【０１３３】
ステップ２３０３０において、該当するプールを発見できなかった場合、構成構築プログラム４０１０はユーザにエラーを通知して処理を終了する（ステップ２３１３０）。
【０１３４】
ステップ２３０３０において、該当するプールを発見できた場合、ステップ２３０４０に進む。なお、以降の説明では、ステップ２３０３０において発見したプールを第一の代替プールと呼ぶ。
【０１３５】
ステップ２３０４０では、構成構築プログラム４０１０は、副論理ボリュームに（ｂ）の容量分のページ割り当てていることと、第一の代替プールよりも性能がよいことと、（ｃ）の性能に最も近いこととを条件に、第一のストレージシステムから他のプールを探索する（ステップ２３０４０）。なお、副論理ボリュームに（ｂ）の容量分のページを割り当てていることと、副論理ボリュームに割り当てられている該ページが（ｃ）の性能を超える性能を提供することを条件に、第一のストレージシステムから他のプールを探索してもよい。
【０１３６】
ステップ２３０４０で該当するプールを発見できた場合、ステップ２３０５０に進む。なお、以降の説明では、発見したプールを第二の代替プールと呼ぶ。ステップ２３０５０では、構成構築プログラム４０１０は、第二の代替プールの物理ページを割り当てられている副論理ボリュームのデータを第一の代替プールへページ間データ移行し、第一の代替プールを副論理ボリュームに対応付け、第二の代替プールに出来た空領域に（ａ）の仮想ボリュームファイルを作成して正論理ボリュームに対応付けたことを想定し、この想定において図２５に示される被災時に発生する処理の流れをシミュレーションする（ステップ２３０５０）。
図２５のシミュレーションにて、副論理ボリュームとして使用されている第一の代替プールに関してエラー通知２３１５０が必要になる場合があるか否かを判断する。そして、エラー通知１２０９０が必要になる場合には、被災時の性能回復の不可と判断する。また、エラー通知１２０９０が必要ではなく、被災時の性能回復の可と判断された場合には、被災時性能要求を満たすために第一の代替プールのデータ移行に要する時間を算出する。算出された時間は、被災時性能劣化時間となる。被災時性能劣化時間は、第一の代替プールに格納されるデータサイズと、データ移行性能情報４０１６のデータ移行速度をもとに算出することが可能である。
【０１３７】
また、被災時の性能回復するために、第一の代替プールと他のプールとスワップする場合には、第一の代替プールに格納されるデータサイズと、データ移行性能情報４０１６のデータ移行速度に加えて、さらに他のプールに格納されるデータサイズを用いて被災時性能劣化時間を算出する。具体的には、他のプールに格納されるデータを移行する時間と、第一の代替プールに格納されるデータを、他のプールに移行する時間との和が、被災時性能劣化時間である。
なお、本構成例では、図２５で示す方法をボリューム入れ替えのアルゴリズムとして用いるが、他のアルゴリズムでボリューム入れ替えを行う場合は、それに応じた方法で性能劣化時間の算出する必要がある。
そして、第一の代替プールのうち、被災時の性能回復の可と判断され、性能劣化許容時間が被災時性能劣化時間を越えるプールを選択する。そして、選択されたプールを新たに第一の代替プールとする。
ステップ２３０４０で該当するプールが発見できなかった場合、ステップ２３０５０はスキップする。
【０１３８】
次に、構成構築プログラム４０１０は、ステップ２３０６０に進む。本処理はステップ９０６０と同じである。ただし、アプリケーションを仮想サーバと読み替える必要がある。
次に、構成構築プログラム４０１０は、ステップ２３０７０に進む。本処理はステップ９０７０と同じである。ただし、アプリケーションを仮想サーバと読み替える必要がある。
【０１３９】
ステップ２３０７０の入力が構築中断を示す値である場合、環境構築を中断した旨をユーザに提示し（ステップ２３１３０）、処理を終了する。
ステップ２３０７０の入力が代替構成タイプ２を示す値である場合、構成構築プログラム４０１０は、第二の代替プールの物理ページを割り当てられている副論理ボリュームのデータを、第一の代替プールへページ間データ移行するように制御プログラム２０３２に指示する（ステップ２３０９０）。これにより、（ａ）の仮想サーバ用の仮想ボリュームファイルの格納領域を、第二の代替プールに作成することができる。また、副論理ボリュームのデータを移行された第一の代替プールの物理ページを、副論理ボリュームに割り当てる。また、第二の代替プールにおいて仮想ボリュームファイルを格納する物理ページを正論理ボリュームに割り当てる。
ステップ２３０７０の入力が代替構成タイプ１を示す値である場合、構成構築プログラム４０１０は、ステップ２３０９０はスキップする。
【０１４０】
次に、構成構築プログラム４０１０は、ステップ２３１００に進む。このステップは前述のとおりである。
次に、構成構築プログラム４０１０は、ステップ２３１１０に進む。このステップは、前述の通りであるが、相違点のみ説明する。代替構成タイプ２を選択した場合、作成した仮想ボリュームファイルの格納領域には、ステップ２３０９０で空き領域を作った第二の代替プールから物理ページを割り与えるように、第一のストレージシステムの制御プログラム２０３２に指示する。代替構成タイプ１を選択した場合、作成した仮想ボリュームが格納される領域には、第一の代替プールから物理ページを割り与えるように、第一のストレージシステムの制御プログラム２０３２に指示する。
【０１４１】
次に、構成構築プログラム４０１０は、ステップ２３１２０に進む。このステップは、前述のものとほぼ同じであるため、差分だけ示す。通常時要求性能５００２には、第一の代替プールの性能が設定される。そして構成構築プログラム４０１０は、処理を終了する。
以上が、構成構築プログラム１２５１の処理の流れである。
【０１４２】
図２４は、本実施例において稼働状況監視プログラム４０１１が稼働中の仮想ボリュームへのアクセス状況を監視し、仮想ボリュームの性能が不十分である場合に、ユーザの指示に応じて仮想ボリュームに割り当てられた物理ページを他のプールの物理ページへの移行させる処理の流れを示した図である。
【０１４３】
稼働状況監視プログラム４０１１は、デーモンプロセスとして計算機システム内で起動し続けている。そして、稼働状況監視プログラム４０１１は所定の時間待機する。なお、この所定の時間は、ユーザにより指定されても良いし、プログラム内にコーディングされていても良い。その後、図２４の処理を行う。図２４の処理終了後は、再び所定の時間帯記して、図２４の処理を繰り返す。以下、図２４の処理の説明を行う。
【０１４４】
稼働状況監視プログラム４０１１は、計算機システム内の仮想サーバを列挙し、一つずつ順番に特定の仮想サーバを対象として、ステップ２４０２０〜ステップ２４１２０を繰り返す。以降、対象となる仮想サーバを対象仮想サーバと呼ぶ。
【０１４５】
まず、稼働状況監視プログラム４０１１は、対象仮想サーバの仮想ボリュームへの単位時間あたりのアクセス量を取得する（ステップ２４０３０）。この値は、ハイパバイザ１４０１０から取得することができる。
次に、稼働状況監視プログラム４０１１は、取得した単位時間あたりのアクセス量が、仮想ボリュームに割り当てられた物理ページの性能を上回る可能性があるかを判定する（ステップ２４０４０）。なお、仮想ボリュームに割り当てられた物理ページとは、仮想ボリュームファイルを格納する論理ボリュームに割り当てられた物理ページを意味する。本ステップでの判定では、ステップ２４０３０にて取得した単位時間あたりのアクセス量と、物理ページの性能以下であって設定された一定の閾値とを比較し、取得した単位時間あたりのアクセス量が閾値を超えた場合に、上回る可能性があると判定しても良い。また、ステップ２４０３０にて取得した値の履歴をとっておき、トレンド分析により性能を上回る可能性があると判定しても良い。
【０１４６】
ステップ２４０４０の判定の結果、上回る可能性がないと判定された場合、稼働状況監視プログラム４０１１は、ステップ２４０２０に移行し、次の仮想サーバを対象とした処理に移行する。
ステップ２４０４０の判定の結果、上回る可能性があると判定された場合、稼働状況監視プログラム４０１１は、対象仮想サーバの仮想ボリュームに割り当てられている物理ページの容量分の空き容量を持つプールを探索する（ステップ２４０５０）。該当するプールが無い場合、稼働状況監視プログラム４０１１は、対象仮想サーバの仮想ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ２４１３０）、ステップ２４０２０に移行し、次の仮想サーバを対象とした処理に移る。
【０１４７】
ステップ２４０５０の判定の結果、該当するプールを発見した場合、稼働状況監視プログラム４０１１はステップ２４０６０へ移行する。なお、この発見したプールを第一の代替プールと呼ぶ。ステップ２４０６０では、稼働状況監視プログラム４０１１は、対象仮想サーバの仮想ボリュームに割り当てられている物理ページより良い性能であること、他の副論理ボリュームに対して、対象仮想サーバの仮想ボリュームに割り当てられている物理ページの容量以上物理ページを割り当てていることを条件として、プールを検索する（ステップ２４０６０）。
ステップ２４０６０の結果、該当するプールが無い場合、稼働状況監視プログラム４０１１は、対象となっている仮想サーバの仮想ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ２４１３０）、ステップ２４０２０に移行し、次の仮想サーバを対象にした処理に移る。
【０１４８】
ステップ２４０６０の結果、該当するプールを発見した場合、稼動状況監視プログラム１２５２は、ステップ２４０６５に進む。なお、以降の説明では、この発見したプールを第二の代替プールと呼ぶ。ステップ２４０６５では、第二の代替プールの性能に適した仮想データＩ／Ｆを対象仮想サーバに割り当てることができるかを判定する（ステップ２４０６５）。
まず、対象仮想サーバへ割り当てられているデータＩ／Ｆの性能と、第二の代替プールの性能とを比較する。データＩ／Ｆの性能が第二の代替プールの性能以上である場合、稼動状況監視プログラム１２５２はステップ２４０７０に進む。データＩ／Ｆの性能が第二の代替プールの性能を下回る場合、以下の処理を実行する。
【０１４９】
ＶＭ性能情報１５００２から同一の物理サーバ上の他の仮想サーバを特定する。そして、対象仮想サーバ以外の仮想サーバの仮想データＩ／Ｆの性能の総和を、物理サーバのＩ／Ｏ性能２１００２から引き、対象仮想サーバに割り当てることのできるデータＩ／Ｆ性能（割り当て可能なデータＩ／Ｆ性能）を算出する。算出したデータＩ／Ｆ性能をもとに、対象仮想サーバが稼動する物理サーバ上で、第二の代替プールの性能に適した仮想データＩ／Ｆを作成可能か判定する。例えば、仮想データＩ／Ｆ性能と第二の代替プールの性能との差が閾値以内になるように、データＩ／Ｆ性能を割り当てることができるか否かで判断する。作成可能である場合は、仮想データＩ／Ｆ性能と第二の代替プールの性能との差が上記閾値以内となる仮想データＩ／Ｆの性能を算出し、稼動状況監視プログラム１２５２はステップ２４０７０に進む。
作成不可である場合は、ＶＭ以降性能情報１５００６から仮想サーバが移行可能な物理サーバを探索する。仮想サーバが移行可能な物理サーバが存在する場合には、ＶＭ性能情報１５００２と、物理サーバのＩ／Ｏ性能２１００２から、割り当てることのできるデータＩ／Ｆ性能を算出する。そして、探索された物理サーバにおいて、第二の代替プールの性能に適した仮想データＩ／Ｆを作成可能か判定する。作成可能であるかの判断方法は、ステップ２４０６５で説明した通りである。作成可能である場合は、探索された物理サーバから割り当てる仮想データＩ／Ｆ性能と第二の代替プールの性能との差が上記閾値以内となるように、仮想データＩ／Ｆの性能を算出し、稼動状況監視プログラム１２５２はステップ２４０７０に進む。作成不可である場合は、稼働状況監視プログラム４０１１は、対象となっている仮想サーバの仮想ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ２４１３０）、ステップ２４０２０に移行し、次の仮想サーバを対象にした処理に移る。
【０１５０】
ステップ２４０７０では、構成構築プログラム４０１０は、第二の代替プールの物理ページを割り当てられている副論理ボリュームのデータを第一の代替プールへページ間データ移行し、第一の代替プールに出来た空領域に（ａ）の仮想ボリュームファイルを作成したことを想定し、この想定において被災時に発生する処理の流れをシミュレーションする（ステップ２４０７０）。なお、ステップ２４０６５において、仮想サーバを移行させる必要があると判定された場合は、仮想サーバの移行も行われたことも想定に加える。これにより、被災時に要求性能を満たせるかと、被災時性能劣化時間を確認する。
なお、本シミュレーションの処理内容は、図２５の説明で示す被災時の復旧処理方法に従う。なお、被災時性能劣化時間の算出方法に関しては、図２３にて説明した通りである。被災時性能劣化時間を算出するためのパラメータとして、ページ間データ移行の処理時間が必要となるが、これは、まず、論理ボリュームアドレス２０００６と論理ボリューム構成情報１５００３から各仮想サーバの仮想ボリュームファイルに割り当てられているページの容量を取得し、これをデータコピー性能４０１６で割ることで算出可能である。また、同様に、仮想サーバの以降の処理時間も必要となるが、これは、まず、仮想サーバに割り当てられた割り当てメモリ量２０００２を、物理サーバ間のデータ転送速度である速度２２００３で割ることで算出可能である（ステップ２４０７０）。
【０１５１】
ステップ２４０７０のシミュレーションの結果、被災時に性能回復が可能であるかを判定し(ステップ２４０７５)、不可である場合、ユーザに警告を通知した後（ステップ２４１３０）、ステップ２４０２０に移行し、次の仮想サーバを対象とした処理移行する。
次に、稼働状況監視プログラム４０１１は、代替構成をユーザに提示する（ステップ２４０８０）。ここで表示される代替構成のタイプは一つだけである。第二の代替プールを使用する副論理ボリュームのデータを第一の代替プールに移行し、対象仮想サーバの仮想ボリュームファイルを現在使用中のプールから第二の代替プールへ移行する構成である。ユーザは、この構成を選択するか、現在の構成を継続するかの二つの選択肢から処理を選ぶことができる。なお、本画面の構成は、選択肢が前述の二つに変わる以外は図１０と同じであるため図示は省略する。
【０１５２】
ステップ２４０８０で表示された画面によりユーザの入力を受け付ける（ステップ２４０９０）
ステップ２４０９０でユーザが現在の構成を継続すること選択した場合、対象となっている仮想ボリュームの性能をアクセス量が上回る危険性があることをユーザに警告を通知した後（ステップ２４１３０）、ステップ２４０２０に移行し、次の正論理ボリュームの判定に移行する。
【０１５３】
ステップ２４０９０でユーザが代替構成に移行することを選択した場合、稼動状況監視プログラム４０１１は、第二の代替プールの副論理ボリュームを第一の代替プールへ移行し、対象仮想サーバの仮想ボリュームファイルを現在のプールから第二の代替プールへ移行するように制御プログラム２０３２に指示する。（ステップ２４１００）。また、ステップ２４０６５において、仮想データＩ／Ｆの再割り当てが必要とされている場合は、ハイパバイザ１４０１０に仮想データＩ／Ｆの再割り当てを実施するように指示する。また、同様に、仮想サーバを物理サーバ間で移行させる必要があるとされている場合は、仮想サーバの移行し、移行先の物理サーバにて仮想データＩ／Ｆの割り当てを行うようにハイパバイザ１４０１０に指示する。
【０１５４】
最後に働状況監視プログラム４０１１は、設定した内容に応じてＶＭ性能情報１５００２、論理ボリューム構成情報１５００３、ＶＭ構成情報１５００４を更新する（ステップ２４１１０）。そして構成構築プログラム４０１１は、ステップ２４０２０に戻り、次の正論理ボリュームを対象に処理を続ける。
【０１５５】
全仮想サーバに対して、ステップ２４０２０からステップ２４１２０までの処理が完了したら、働状況監視プログラム４０１１は、ステップ２４０１０に戻る。
以上が、働状況監視プログラム４０１１の処理の流れである。なお、仮想データＩ／Ｆの性能が移行後の仮想ボリュームの性能に対して十分かという判断で、仮想サーバの移行の有無を判断したが、その他、ＣＰＵやメモリなどが十分であるかを考慮しても良い。
【０１５６】
図２５は、被災時復旧プログラム４０１２が、被災時に各仮想サーバが要求する性能を持つボリュームを割り当てなおす処理の流れを示した図である。
【０１５７】
被災時復旧プログラム４０１２は、一方のサイトが被災した時に、被災していない側のサイトＩＤをパラメータとして起動される。被災時復旧プログラム４０１２は、起動すると、仮想サーバが仮想ボリュームに要求する性能に応じて、要求性能の高いもの順にアプリケーションのソートを行う（ステップ２５０１０）。本ソートでは、パラメータとして入力されたサイトＩＤとサイトＩＤ５００５を比較し、一致する仮想サーバは通常時要求性能５００２を要求する性能とし、一致しない仮想サーバは、被災時要求性能５００３を要求する性能としてソートを行う。パラメータとして入力されたサイトＩＤとサイトＩＤ５００５とが一致するアプリケーションは、一方のサイトが被災する前から、被災していない側のサイトを正サイトとして利用していたアプリケーションである。パラメータとして入力されたサイトＩＤとサイトＩＤ５００５とが一致しないアプリケーションは、一方のサイトが被災する前には、被災していない側のサイトを副サイトとして利用していたアプリケーションである。
その後、被災時復旧プログラム４０１２は、要求性能が高い順に一つずつ仮想サーバを対象として、ステップ２５０２０〜ステップ２５０８０までの処理を繰り返す。以降、対象となる仮想サーバを対象仮想サーバと呼ぶ。
【０１５８】
まず、被災時復旧プログラム４０１２は、ステップ２５０１０で用いた要求性能と、仮想サーバの仮想ボリュームファイルを格納する論理ボリュームに割り当てられた物理ページの性能を比較する（ステップ２５０２０）。要求性能を満たしている場合は、被災時復旧プログラム４０１２は、ステップ２５０２０に戻り、次の仮想サーバを対象に処理を続ける。要求性能を満たしていない場合は、要求性能を満たすプールを探索する（ステップ２５０４０）。本探索処理では、要求性能を満たすこと、対象仮想サーバよりも要求性能が低い仮想サーバの仮想ボリュームファイルを格納する論理ボリュームに割り当てられた物理ページの総容量が対象仮想サーバの仮想ボリュームの容量より大きいこと、を条件とする。
【０１５９】
ステップ２５０４０の結果、該当するプールを発見できなかった場合は、ユーザにエラーを通知した後（ステップ２５０９０）、異常終了する。
【０１６０】
ステップ２５０４０の結果、該当するプールを発見できた場合は、被災時復旧プログラム４０１２は、ステップ２５０５０に進む。なお、以降、発見したプールを第一の代替プールと呼ぶ。ステップ２５０５０では、被災時復旧プログラム４０１２は、第一の代替プール以外で対象仮想サーバの仮想ボリュームと同容量の空き容量をもつプールを探索する（ステップ２５０５０）。探索の結果、該当するプールを発見できなかった場合は、ユーザにエラーを通知した後（ステップ２５０９０）、異常終了する。
【０１６１】
ステップ２５０５０の結果、該当するプールを発見できた場合は、ステップ２５０６０に進む。なお、以降、発見したプールを第二の代替プールと呼ぶ。ステップ２５０６０では、被災時復旧プログラム４０１２は、第一の代替プールから対象仮想サーバよりも要求性能が低い仮想サーバの仮想ボリュームファイルのデータを第二の代替プールへ移行する指示を発行する。そして、対象仮想サーバの仮想ボリュームファイルのデータを現在のプールから第一の代替プールへ移行するように制御プログラム２０３２に指示を発行する（ステップ２５０６０）。
【０１６２】
また、対象仮想サーバが稼動している物理サーバが指定されたものであるかを確認し、異なる場合は、指定された物理サーバへ仮想サーバを移行する。なお、この確認は、起動パラメータとして与えられたサイトＩＤがサイトＩＤ５００５と一致する場合は、通常時物理サーバＩＤ１６００２で示される物理サーバで稼動しているかを確認する。一致しない場合は、被災時物理サーバＩＤ１６００３で示される物理サーバで稼動しているかを確認する。また、新たに割り当てられた物理ページの性能に適した性能の仮想データＩ／Ｆを割り当てる。
【０１６３】
最後に、被災時復旧プログラム４０１２は、設定した内容に応じてＶＭ性能情報１５００２、論理ボリューム構成情報１５００３、ＶＭ構成情報１５００４を更新する（ステップ２５０７０）。
以上が、被災時復旧プログラム４０１２の処理の流れである。
なお、本処理では、高性能なプールには、空き容量が無いことを想定しているが、ある場合には、高性能なプールの空き容量への仮想ボリュームの移行を行うようにすることが望ましい。以上が、第二の実施例の説明である。
【０１６４】
本実施例によれば、仮想サーバ環境におけるＡｃｔｉｖｅ−Ａｃｔｉｖｅのディザスタリカバリ構成において、被災時に性能劣化許容時間内で元の状態に戻せる場合、仮想サーバに仮想ボリュームの性能変更に合わせて仮想データＩ／Ｆを割り当てることで、仮想データＩ／Ｆがボトルネックとなり生かしきれていなかったボリュームの性能を生かすことができるようになり、ストレージシステム全体としての利用率を向上させることができる。
【符号の説明】
【０１６５】
１１０３：ストレージシステムＡ、１２０３：ストレージシステムＢ、１１０１：ホスト計算機Ａ、１２０２：ホスト計算機Ｂ、１２０１：ホスト計算機Ｃ、１１０２：ホスト計算機Ｄ、１５００：管理計算機、１１０４：データネットワークＡ、１２０４：データネットワークＢ、１４００：データネットワークＣ、１３００：管理ネットワーク
【図１】
2011076286.tif 000003
【図２】
2011076286.tif 000004
【図３】
2011076286.tif 000005
【図４】
2011076286.tif 000006
【図５】
2011076286.tif 000007
【図６】
2011076286.tif 000008
【図７】
2011076286.tif 000009
【図８】
2011076286.tif 000010
【図９】
2011076286.tif 000011
【図１０】
2011076286.tif 000012
【図１１】
2011076286.tif 000013
【図１２】
2011076286.tif 000014
【図１３】
2011076286.tif 000015
【図１４】
2011076286.tif 000016
【図１５】
2011076286.tif 000017
【図１６】
2011076286.tif 000018
【図１７】
2011076286.tif 000019
【図１８】
2011076286.tif 000020
【図１９】
2011076286.tif 000021
【図２０】
2011076286.tif 000022
【図２１】
2011076286.tif 000023
【図２２】
2011076286.tif 000024
【図２３】
2011076286.tif 000025
【図２４】
2011076286.tif 000026
【図２５】
2011076286.tif 000027