特許第6051228号(P6051228)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧
特許6051228計算機システム、ストレージ管理計算機及びストレージ管理方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6051228
(24)【登録日】2016年12月2日
(45)【発行日】2016年12月27日
(54)【発明の名称】計算機システム、ストレージ管理計算機及びストレージ管理方法
(51)【国際特許分類】
   G06F 13/10 20060101AFI20161219BHJP
   G06F 3/06 20060101ALI20161219BHJP
   G06F 12/00 20060101ALI20161219BHJP
【FI】
   G06F13/10 340A
   G06F3/06 301T
   G06F12/00 501B
【請求項の数】10
【全頁数】37
(21)【出願番号】特願2014-545478(P2014-545478)
(86)(22)【出願日】2012年11月7日
(86)【国際出願番号】JP2012078781
(87)【国際公開番号】WO2014073045
(87)【国際公開日】20140515
【審査請求日】2015年3月27日
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】100100310
【弁理士】
【氏名又は名称】井上 学
(74)【代理人】
【識別番号】100098660
【弁理士】
【氏名又は名称】戸田 裕二
(74)【代理人】
【識別番号】100091720
【弁理士】
【氏名又は名称】岩崎 重美
(72)【発明者】
【氏名】三輪 京子
(72)【発明者】
【氏名】中島 淳
(72)【発明者】
【氏名】坂下 幸徳
(72)【発明者】
【氏名】柴山 司
(72)【発明者】
【氏名】名倉 正剛
【審査官】 坂東 博司
(56)【参考文献】
【文献】 特開2008−097502(JP,A)
【文献】 特開2007−233783(JP,A)
【文献】 国際公開第2012/020471(WO,A1)
【文献】 国際公開第2011/092739(WO,A1)
【文献】 国際公開第2011/092738(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 13/10
G06F 3/06
G06F 12/00
(57)【特許請求の範囲】
【請求項1】
ホスト計算機とストレージ装置とに接続され、
前記ストレージ装置により前記ホスト計算機に提供される仮想論理ボリュームの情報であって、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報、および、前記ホスト計算機から前記ストレージ装置へアクセスする際に満たされるべき第1の要求性能を示す情報を含む仮想論理ボリューム管理情報と、
前記ストレージ装置により提供される、データの物理的な記憶領域群で構成され、前記ホスト計算機からのライトアクセスに応じて前記仮想論理ボリュームに前記データの物理的な記憶領域を割り当てる複数のプール、の使用状況に関する情報を示すプール管理情報と、
を格納するメモリと、
前記メモリに接続され、
前記ストレージ装置へのアクセスに関する性能情報を前記ホスト計算機により取得し、
取得した前記アクセスに関する性能情報が、前記第1の要求性能を満たすか否かを判断し、
前記判断の結果、前記第1の要求性能が満たされていなければ、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報および前記第1の要求性能を示す情報を含む仮想論理ボリューム管理情報に基づいて前記判断の結果の原因である仮想論理ボリュームを特定し、
前記プール管理情報に基づき、各プールに含まれる前記データの物理的な記憶領域の容量消費傾向を算出し、
前記特定した仮想論理ボリュームの情報と、算出した前記容量消費傾向とに基づいて、所定の時間後に実施し得る前記第1の要求性能が満たされるための複数の対策案を生成し、
生成した前記複数の対策案のそれぞれについて、前記第1の要求性能及び予め定められた許容ダウンタイムと、各対策案を実行したと仮定した場合の前記ストレージ装置へのアクセスに関する性能及び前記対策案実行に要する時間とに基づいて、実行推奨度を算出し、
生成した前記対策案及び算出した前記実行推奨度を共に出力装置に出力するプロセッサと、
を有することを特徴とする管理計算機。
【請求項2】
前記第1の要求性能は、前記ホスト計算機で実行される仮想マシンについて予め定められており、
前記プロセッサは、
各仮想論理ボリュームの応答性能情報を前記ストレージ装置より取得して、前記仮想論理ボリューム管理情報に格納し、
前記仮想マシンから、前記仮想マシンに提供される前記仮想論理ボリュームへのアクセスに関するVM応答性能情報を、前記ホスト計算機より取得して、前記判断を行い、
取得した前記VM応答性能情報が前記第1の要求性能を満たしていなければ、前記仮想論理ボリューム管理情報に基づき、前記仮想マシンに提供される仮想論理ボリュームの応答性能が、前記第1の要求性能に対応する第2の要求性能を満たすか否かを判断し、
前記第2の要求性能が満たされていない場合、前記仮想論理ボリュームが、前記第1の要求性能が満たされていない状態の原因であると特定する
ことを特徴とする請求項1に記載の管理計算機。
【請求項3】
前記メモリは、さらに、前記ストレージ装置の有するポートの性能情報を示すポート管理情報を格納し、
前記プロセッサは、
前記ポート管理情報に基づき、前記ホスト計算機からのアクセスに用いられるポートの負荷増加傾向を算出し、
算出した前記負荷増加傾向にさらに基づいて、前記対策案を生成し、前記出力装置に出力する
ことを特徴とする請求項1に記載の管理計算機。
【請求項4】
前記対策案は、前記仮想論理ボリュームの他のプールへの移動、前記仮想マシンの他のホスト計算機への移動、及び、前記プールへの前記データの物理的な記憶領域の追加のタスクのうち、少なくとも1種類のタスクにより構成される
ことを特徴とする請求項2の記載の管理計算機。
【請求項5】
前記プロセッサは、
前記プールが、前記状態の原因である前記仮想論理ボリュームの移動に必要な空き容量を前記所定の時間後に備えているか否かを、算出した前記容量消費傾向を用いて予測し、
前記予測の結果が肯定的である場合に、前記プールへの前記仮想論理ボリュームの移動を、前記対策案を構成するタスクとして採用する
ことを特徴とする請求項4に記載の管理計算機。
【請求項6】
前記メモリはさらに、
実行順序に依存関係を有するタスクを第1の権限に基づき一連の処理として実行する自動実行制御を、前記プロセッサに許可するポリシを示す自動実行ポリシ情報を格納し、
前記プロセッサは、
前記自動実行ポリシ情報に基づき、生成した前記対策案の自動実行の可否を判断し、
判断結果を前記出力装置に出力する
ことを特徴とする請求項4に記載の管理計算機。
【請求項7】
前記メモリは、さらに、前記タスクの種別毎の実行権限情報を格納し、
前記プロセッサは、前記実行権限情報と前記自動実行ポリシ情報とに基づいて、前記対策案の自動実行可否判断を行う
ことを特徴とする請求項6に記載の管理計算機。
【請求項8】
前記プロセッサは、
所定の時間幅の複数の時刻のそれぞれにおいて実施し得る前記対策案を生成し、
生成した前記対策案の中で、前記実行推奨度が最も高い対策案を前記出力装置に出力する
ことを特徴とする請求項1に記載の管理計算機。
【請求項9】
前記プロセッサは、
所定の時間幅の複数の時刻のそれぞれにおいて実施し得る前記対策案を生成し、
前記自動実行可否判断の結果、自動実行可能であると判断した対策案の中で、前記実行推奨度が最も高い対策案の自動実行制御を行う
ことを特徴とする請求項7に記載の管理計算機。
【請求項10】
ホスト計算機とストレージ装置の管理方法であって、
前記ストレージ装置により前記ホスト計算機に提供される仮想論理ボリュームの情報であって、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報、および、前記ホスト計算機から前記ストレージ装置へアクセスする際に満たされるべき第1の要求性能を示す情報を含む仮想論理ボリューム管理情報と、
前記ストレージ装置により提供される、データの物理的な記憶領域群で構成され、前記ホスト計算機からのライトアクセスに応じて前記仮想論理ボリュームに前記データの物理的な記憶領域を割り当てる複数のプール、の使用状況に関する情報を示すプール管理情報と、
を記憶し、
前記ストレージ装置へのアクセスに関する性能情報を前記ホスト計算機より取得し、
取得した前記アクセスに関する性能情報が、前記第1の要求性能を満たすか否かを判断し、
前記判断の結果、前記第1の要求性能が満たされていなければ、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報および前記第1の要求性能を示す情報を含む前記仮想論理ボリューム管理情報に基づいて前記判断の結果の原因である仮想論理ボリュームを特定し、
前記プール管理情報に基づき、各プールに含まれる前記データの物理的な記憶領域の容量消費傾向を算出し、
前記特定した仮想論理ボリュームの情報と、算出した前記容量消費傾向とに基づいて、所定の時間後に実行し得る前記第1の要求性能が満たされるための複数の対策案を生成し、
生成した前記複数の対策案のそれぞれについて、前記第1の要求性能及び予め定められた許容ダウンタイムと、各対策案を実行したと仮定した場合の前記ストレージ装置へのアクセスに関する性能及び前記対策案実行に要する時間とに基づいて、実行推奨度を算出し、
生成した前記対策案及び算出した前記実行推奨度を共に出力装置に出力する
ことを特徴とする管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストレージ装置を含む計算機システムに関し、特にシステムの状態改善のための対策技術に関する。
【背景技術】
【0002】
近年、シンプロビジョニングと呼ばれる技術がストレージシステムにおいて盛んに用いられてきている。特許文献1には、シンプロビジョニングにおけるプールの容量監視方法が開示されている。ストレージ装置または管理サーバが、ストレージプールに属する物理ボリュームの記憶領域から、業務サーバにシンプロビジョニングボリュームを提供する。管理サーバは、ストレージプールの使用容量を監視し、業務サーバが所定の期間稼動するために必要な記憶容量が、ストレージプールに存在するか否かを判定し、必要な記憶容量が存在しない場合には所定の対策を行う。
【0003】
また、特許文献2には、複数の仮想領域で構成された仮想的な論理ボリューム(以下、VVOLと呼ぶ)の状況を管理し、不適切な状況にあるVVOLの状況改善のためにVVOLに関連付けられているプールに関わるマイグレーションを行う技術が開示されている。
【0004】
【特許文献1】特開2008−097502号公報
【特許文献2】国際公開第2011092738号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【0005】
計算機システムの運用管理において、ストレージシステムの状態を改善するための対策案を生成した後、例えば実際に採用する対策案の選定や、上位管理者による対策実行の承認作業などの都合により、状態の改善が必要と判断されてから実際に対策を実行するまでに一定の時間を要することが考えられる。
【0006】
その間も、通常業務、すなわちホスト計算機からストレージシステムへのI/O(Input/Output)発行は継続して行われるために、実際の対策実行までにストレージシステムの状態が変化し、変化前の状態に基づいて生成された対策案によっては期待する効果が得られなくなる場合がある。
【0007】
本発明は、ストレージシステムの状態の変化を考慮した対策案の生成を目的の1つとする。
【課題を解決するための手段】
【0008】
本発明の提供する管理計算機は、ストレージ装置によりホスト計算機に提供される仮想論理ボリュームの情報であって、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報、および、前記ホスト計算機から前記ストレージ装置へアクセスする際に満たされるべき第1の要求性能を示す情報を含む仮想論理ボリューム管理情報と、ストレージ装置により提供される、データの物理的な記憶領域群で構成され、ホスト計算機からのライトアクセスに応じて仮想論理ボリュームに前記データの物理的な記憶領域を割り当てる複数のプールの使用状況に関する情報を示す、プール管理情報とをメモリに格納する。管理計算機のプロセッサが、ストレージ装置へのアクセスに関する性能情報をホスト計算機より取得し、取得したアクセスに関する性能情報が、前記第1の要求性能を満たすか否かを判断し、第1の要求性能が満たされていなければ、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報および前記第1の要求性能を示す情報を含む仮想論理ボリューム管理情報に基づいて状態の原因である仮想論理ボリュームを特定する。プール管理情報に基づき、各プールに含まれるデータの物理的な記憶領域の容量消費傾向を算出し、特定した仮想論理ボリュームの情報と、算出した容量消費傾向とに基づいて、所定の時間後に実施し得る前記第1の要求性能が満たされるための複数の対策案を生成し、出力装置に出力する。
【発明の効果】
【0009】
本発明によれば、ストレージシステムの状態の変化を考慮した効果的な対策案を生成することができる。
【図面の簡単な説明】
【0010】
図1図1は、実施例1に係る計算機システムの構成を示す。
図2図2は、実施例1に係る計算機システムの概念図を示す。
図3図3は、実施例1に係るプール管理テーブルを示す。
図4図4は、実施例1に係るVOL管理テーブルを示す。
図5図5は、実施例1に係るVVOL管理テーブルの一部を示す。
図6図6は、実施例1に係るVVOL管理テーブルの残りを示す。
図7図7は、実施例1に係るプール容量消費傾向管理テーブルを示す。
図8図8は、実施例1に係るポート負荷傾向管理テーブルを示す。
図9図9は、実施例1に係るTier定義管理テーブルを示す。
図10図10は、実施例1に係るタスク実行権限管理テーブルを示す。
図11図11は、実施例1に係る生成中対策案管理テーブルを示す。
図12図12は、実施例1に係る自動実行判定管理テーブルを示す。
図13図13は、実施例1に係る対策案生成処理のフローチャートである。
図14図14は、実施例1に係るプール別対策案生成処理のフローチャートである。
図15図15は、実施例1に係る対策案効果算出処理のフローチャートである。
図16図16は、実施例1に係る実行推奨度算出処理のフローチャートである。
図17図17は、実施例1に係る自動実行可否判定処理のフローチャートである。
図18図18は、実施例1に係る自動実行最終時間判定処理のフローチャートである。
図19図19は、実施例1に係る対策案実行予定時間指定インタフェースを示す。
図20図20は、実施例1に係る対策案一覧提示インタフェースの例を示す。
図21図21は、実施例1に係る対策案一覧提示インタフェースの別の例を示す。
図22図22は、実施例2に係る生成中対策案管理テーブルを示す。
図23図23は、実施例2に係る対策案生成処理のフローチャートである。
図24図24は、実施例2に係る対策案一覧提示インタフェースを示す。
図25図25は、実施例3に係る生成中対策案管理テーブルを示す。
図26図26は、実施例3に係る実行タスク選択インタフェースを示す。
【発明を実施するための形態】
【0011】
幾つかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
【0012】
なお、以下の説明では、「aaaテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「aaaテーブル」を「aaa情報」と呼ぶことができる。さらに、テーブル内の各列の値からなる情報要素をエントリと呼び、「aaaテーブル」のエントリを、説明のために、「aaaテーブルエントリ」と称する。
【0013】
また、以下の説明では、単に管理計算機及びホスト計算機を主語として処理を説明する場合があるが、これら処理は、計算機が備える制御デバイスが有するプロセッサ(例えば、CPU(Central Processing Unit))によって、実行されていることを示す。同様に、単にストレージ装置を主語として処理を説明する場合には、ストレージ装置が備えるコントローラが実行していることを示す。また、上記制御デバイス及びコントローラのうちの少なくとも1つは、プロセッサそれ自体であっても良いし、制御デバイス又はコントローラが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。
【0014】
プログラムは、プログラムソースから各計算機或いはストレージシステムにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。
【実施例1】
【0015】
図1は、実施例1の計算機システムの構成を示す。
【0016】
ストレージ装置102が、例えばLAN(Local Area Network)などの第1の通信ネットワーク231を介して、管理計算機201及びホスト計算機101に接続されている。また、ストレージ装置102は、例えばSANなどの第2の通信ネットワーク232を介して、ホスト計算機101に接続されている。なお、第1の通信ネットワーク231、及び第2の通信ネットワーク232は一体に形成されても良い。
【0017】
ストレージ装置102は、物理記憶デバイス群と、物理記憶デバイス群に接続されたコントローラ251とを有する。物理記憶デバイス群は、1以上の物理記憶デバイスより構成される。物理記憶デバイス群としては、図2で示す通りSSD群309A、SAS群309B及びSATA群309Cがある。SSD群309Aは、1以上のSSD(Solid State Drive)であり、SAS群309Bは、1以上のSAS(Serial Attached SCSI)−HDDであり、SATA群309Cは、1以上のSATA(Serial ATA(Advanced Technology Attachment))−HDDである。このように、ストレージ装置203は、性能の異なる複数の物理記憶デバイスが混在している。なお、物理記憶デバイス群は、ストレージ装置102の外部から提供されるものであっても良い。
【0018】
コントローラ251は、管理I/F(以下、M−I/Fと記載)241と、通信I/F242(以下、C−I/Fと記載)242と、デバイスI/F(以下、D−I/Fと記載)245と、メモリ243と、それらに接続されたプロセッサ244とを有する。
【0019】
M−I/F241は、第1のプロトコルで通信するための通信インタフェース装置であり、例えば、NIC(Network Interface Card)である。C−I/F242は、第2のプロトコルで通信するための通信インタフェース装置である。
【0020】
D−I/F245は、第3のプロトコルで物理記憶デバイスと通信するための通信インタフェース装置である。D−I/F245は、物理記憶デバイスの種類毎に有していても良い。コントローラ251は、D−I/F245を介して、物理記憶デバイスに対してアクセスをする。
【0021】
メモリ243は、プロセッサ244で実行されるコンピュータプログラムや、種々の情報を記憶する。また、メモリ243は、キャッシュメモリ領域を有する。キャッシュメモリ領域には、ホスト計算機101から受けたライトコマンドに従うデータや、ホスト計算機101から受けたリードコマンドに応答して、物理記憶デバイス上の実データ保存領域(以下、ページと呼ぶ)から読み出されたデータが一時格納される。キャッシュメモリ領域内のライト対象のデータは、ライト先の仮想領域に割り当てられた物理記憶デバイスに格納される。キャッシュメモリ領域内のリード対象のデータは、ホスト計算機101に提供される。
【0022】
メモリ243には、プール管理テーブル302、VOL管理テーブル304、プール管理プログラム305が記憶される。プール管理プログラム305は、ストレージシステム102が有する後述のプール107を管理するためのプログラムである。プール管理プログラム305は、プロセッサ244に実行され、各種テーブルに基づき、各種処理が実現される。
【0023】
なお、1以上のストレージ装置102の集合によって、後述のストレージシステム103が構成される。
【0024】
ホスト計算機101は、M―I/F224と、C―I/F226と、記憶資源221と、それらに接続されたプロセッサ222と、I/Oデバイス223とを含んで構成される。M−I/F224は例えばNICであり、C−I/F226は例えばHBA(Host Bus Adapter)である。記憶資源221は、例えば、メモリであり、HDD(Hard Disk Drive)等の補助記憶装置を含んでも良い。記憶資源221は、例えば、業務プログラムなどのアプリケーションプログラムやOS(Operating System)を記憶し、プロセッサ222が、そのアプリケーションプログラムやOSを実行する。I/Oデバイス223としては、ユーザからの入力を受け付ける入力部(例えば、キーボード、スイッチ、ポインティングデバイス及び/又はマイクロフォン等)と各種情報をユーザに対して表示する出力部(例えば、ディスプレイ装置及び/又はスピーカ等)とを有する。
【0025】
管理計算機201は、M−I/F214と、記憶資源211と、それらに接続されたプロセッサ212と、I/Oデバイス213とを含んで構成される。M−I/F214は、例えばNICである。I/Oデバイス213は、I/Oデバイス223と同様である。
【0026】
記憶資源211は、例えば、メモリであり、HDD等の補助記憶装置を含んでも良い。記憶資源211は、コンピュータプログラムや種々の情報を記憶する。コンピュータプログラムは、プロセッサ212で実行される。記憶資源211には、情報としてVVOL管理テーブル801、プール容量消費傾向管理テーブル802、ポート負荷傾向管理テーブル803、ティア定義管理テーブル804、タスク実行権限管理テーブル806、生成中対策案管理テーブル807、自動実行判定管理テーブル808が記憶され、プログラムとして、状態監視プログラム810、対策案生成プログラム811が記憶される。
【0027】
以上が、実施例1に係る計算機システムのハードウェア等構成である。なお、前述のM−I/F、C−I/Fなどの通信インタフェースデバイスは、例えば、そのI/Fが接続されるネットワークの種類や、そのI/Fを有する装置の種類によって異なる。
【0028】
図2は、実施例1に係る計算機システムの概念図である。
【0029】
ストレージシステム103は、1以上のストレージ装置102で構成される。ストレージ装置102のうちの少なくとも1つが、シンプロビジョニング技術が適用されたストレージ装置である。ストレージシステム103は、物理記憶デバイスの実領域から構成された性能の異なる複数の論理ボリューム(以下、LDEVと呼ぶ)を有する。
【0030】
本実施例では、3種類のLDEVの集合を考える。具体的には、SSDから構成されるLDEV109Aと、SASから構成されるLDEV109Bと、SATAから構成されるLDEV109Cとがある。
【0031】
なお、ストレージシステム103が有する論理ボリュームの集合は、例えば、これら3つの集合のうちの少なくとも1つが別種の論理ボリュームの集合であっても良い。また、論理ボリュームの集合の数は、2以上であれば良い。例えば、同種の論理ボリュームが、アクセス性能に応じて2以上の異なる集合に分けられても良い。例えば、SASから構成されるLDEV109Bは、SAS[10K/rpm](回転数が10、000[回転/分]のSAS)から構成される集合と、SAS[15K/rpm](回転数が15、000[回転/分]のSAS)から構成される集合とに分けられても良い。また、プール107を有するストレージ装置とは別のストレージ装置から提供された論理ボリュームであっても良い。
【0032】
ストレージシステム103は、1以上のプール107を有する。各プール107は、性能の異なる複数のLDEVで構成されている。例えば、各プール107は、SSDから構成されるLDEV109Aのうちの1以上のLDEVと、SASから構成されるLDEV109Bのうちの1以上のLDEVと、SATAから構成される109Cのうちの1以上のLDEVとで構成されている。各LDEVが、複数のページに区切られている。このため、各プール107は、SSDページ群と、SASページ群と、SATAページ群とで構成されていることになる。各LDEVは、1つのプールの構成要素となり、2以上のプールの共通の構成要素とならないで良い。なお、図2における、プール107と各LDEV109との間の結線は、物理的な接続を意味するものではなく、上述の通りプール107がLDEV109から構成されることを示している。
【0033】
なお、1つのプール107には、複数のティアがある。1つのティアは、同じ性能の1以上のLDEVで構成される。例えば、上位のティアとして、SSDで構成されたティアがあり、中位のティアとして、SASで構成されたティアがあり、下位のティアとして、SATAで構成されたティアがある。なお、「同じ性能」とは、完全に同じ性能であっても良いし、例えば、アクセス性能の差が所定の差以下であるなど、実質的にほぼ同じ性能の場合を含んで良い。
【0034】
各ティアには、アクセス頻度範囲が関連付けられる。アクセス頻度は、単位時間当りのアクセスの数であり、例えば、IOPS(Input Output Per Second)で表される。なお、IOPSは、1秒間当たりに行われるアクセス(I/O)の数の単位である。
【0035】
ストレージシステム103は、複数のVVOL105を有する。VVOL105は、シンプロビジョニング技術に従う仮想的な論理ボリュームであり、複数の、仮想的な記憶領域である仮想領域で構成されている。仮想領域は、例えば、LBA(Logical Block Addressing)などのアドレスである。ストレージシステム103は、ホスト計算機101からVVOL105を指定したライトコマンドを受信した場合、そのライトコマンドから特定されるライト先の仮想領域に、実領域であるページが割り当てられていれば、当該ページにデータを書き込み、ページが割り当てられていなければ、そのライト先のVVOL105が関連付けられているプールから、未使用のページを割り当て、その割り当てたページに、そのライトコマンドに従うライト対象のデータを書き込む。
【0036】
ホスト計算機101は、ストレージシステム103へのアクセス元の一例である。ホスト計算機101は、VM(Virtual Machine)111を論理的に生成してVM111を実行できるハイパーバイザ112を有する。ハイパーバイザは一度に複数のVM111を制御することができる。複数のVM111の夫々は、あたかもスタンドアローンの物理計算機のようにアプリケーションを実行できる。また、ハイパーバイザ112は、あるホスト上で稼働しているVM111を他のホストに移動するVMマイグレーションを行うことができる。
【0037】
VVOL105は、複数のVM111のうちのいずれか1つのVM111に提供される。実施例1では、VVOL105とVM111が1対1で対応する。なお、図2における、ホスト計算機101とVVOL105との間の結線は、物理的な接続を意味するものではなく、VVOL105がホスト計算機101に提供され、ホスト計算機101から認識されていることを示す。同様に、プール107とVVOL105との間の結線も、物理的な接続を意味するものではなく、VVOL105がプール107に関連付けられていることを示す。
【0038】
ホスト計算機はVM111のリクエストに従い、提供されたVVOL105にアクセスする。具体的には、ホスト計算機101は、アクセス先情報を有するアクセスコマンドを、ストレージシステム103に送信する。アクセス先情報は、アクセス先を表す情報であり、例えば、LUN(Logical Unit Number)などのVVOL105のIDと、LBAなどの仮想領域のIDとを含んでいる。
【0039】
図3は、プール管理テーブル302を示す。プール管理テーブル302は、プール107の情報を格納する。プール管理テーブル302により、プールを構成するLDEV及びLDEVの属するティア、各ページと仮想領域との対応関係、ページ毎のIOPSなどが分かる。コントローラ251は、定期的に、または外部からの情報収集要求の受け付けを契機として、ストレージ装置103の各構成要素より情報を収集し、プール管理テーブル302に格納する。
【0040】
具体的に、プール管理テーブル302は、以下の情報を有する。プールID501は、プール107を識別するための情報である。ページID502は、プール107に属するページを識別するための情報である。LDEV ID503は、ページを有するLDEVを識別するための情報である。ティアレベル504は、LDEVが属するティアのレベルを表す情報である。アクセス頻度限界505は、LDEVに対するアクセス頻度の上限値を示す情報である。図3では、アクセス頻度限界505は、LDEVへの単位時間内のI/O数(IOPS)の上限として示されている。LDEVアクセス頻度506は、LDEVへのアクセス頻度を示す情報である。図3では、LDEVアクセス頻度506は、LDEVへの単位時間内のI/O数(IOPS)を示す。LDEV LBA507は、LDEVにおけるページの位置(例えば、ページの先頭のLBAとそのページの末端のLBA)を示す情報である。
【0041】
VVOL ID508は、ページの割当先の仮想領域を有するVVOLを識別するための情報である。「N/A(Not/Assigned)」は、ページがどの仮想領域にも割り当てられていないことを示す。VVOL LBA509は、ページの割当先の仮想領域の位置(例えば、仮想領域の先頭のLBAとその仮想領域の末端のLBA)を示す情報である。ページアクセス頻度510は、ページに対するアクセスの頻度を示す情報である。アクセス頻度は、「ライトの頻度」と、「リードの頻度」とに分けて管理されても良い。アクセス頻度は、ページに対するアクセスが行われた場合に更新され、アクセスコマンドを受けたもののページに対するアクセスが行われなかった場合には、更新されない。
【0042】
図4は、VOL管理テーブル304を示す。VOL管理テーブル304は、ストレージシステム103が有するボリュームに関する情報を有する。VOL管理テーブル304は、ストレージシステム103がホスト計算機101に提供可能なボリュームの情報を格納しており、情報が格納される対象はストレージシステム103が有する全てのボリュームであっても、その一部のみであってもよい。VOL管理テーブル304により、ボリュームがVVOLである場合、そのVVOLが仮想領域を提供するホスト計算機101、そのVVOLにページを割り当てているプール107が分かる。
【0043】
VOL ID701は、VVOL又はLDEVを識別するための情報である。容量702は、VVOL又はLDEVの記憶容量を示す。ボリュームタイプ703は、ボリュームのタイプが、VVOL又はどのLDEVであるかを示す。ボリュームがLDEVである場合、ボリュームタイプ703は、SSD、SAS、或いはSATAを示す。ポートID704は、VVOLに関連づけられているストレージポートを識別するための情報である。ホストID705は、ボリュームの提供先のホスト計算機を識別するための情報である。図4の例では、LDEV1、LDEV2は、ホスト計算機101に直接割り当てられていない。プールID706は、VVOLに関連付けられたプールを識別するための情報である。
【0044】
プール管理プログラム305は、プール管理テーブル302及びVOL管理テーブル304に基づいて、例えば、以下の処理を行う。
(A)プール管理プログラム305は、以下の(a1)〜(a9)の処理を含んだライト処理を行う。
(a1)ホスト装置101からのライトコマンドを受け付ける。
(a2)ライトコマンドに含まれるアクセス先情報を基に、ライト先VVOLとライト先仮想領域を特定する。
(a3)ライトコマンドに従うライト対象のデータをキャッシュメモリ領域に格納する。この時点で、ホスト装置101にライト完了と応答して良い。
(a4)プール管理テーブル302を参照して、上記(a2)で特定されたライト先仮想領域にページが割り当てられているかを判断する。
(a5)上記(a4)の判断の結果が肯定的であれば、プール管理プログラム305ライト先仮想領域に割り当てられているページに、キャッシュメモリ領域内のライト対象のデータを書き込む。
(a6)上記(a4)の判断の結果が否定的であれば、VOL管理テーブル304と、プール管理テーブル302とに基づき、ライト先VVOLに関連付けられているプールにおける、どの仮想領域にも割り当てられていないページ未使用のページを特定する。ここで、なるべく上位の階層に属するLDEVから未使用のページを特定して良い。
(a7)(a6)で特定したページをライト先仮想領域に対応付ける。具体的には、プール管理プログラム305は、プール管理テーブル302のVVOL LBA506に、割り当てたページに対応するライト先仮想領域の先頭LBA及び末端LBAを書き込む。
(a8)上記(a6)で特定したページに、キャッシュメモリ領域内のライト対象のデータを書き込む。この段階で、ホスト装置101にライト完了と応答しても良い。
(a9)上記(a5)又は(a8)において、プール管理テーブル302における、データの書込み先のページのアクセス頻度を更新する。また、それに伴い、プール管理プログラム305は、プール管理テーブル302における、そのページを有するLDEVのアクセス頻度を更新する。
【0045】
(B)プール管理プログラム305は、以下の(b1)〜(b8)の処理を含んだリード処理を行う。
(b1)ホスト装置101からのリードコマンドを受け付ける。
(b2)リードコマンドに含まれるアクセス先情報を基に、リード元VVOLとリード元仮想領域を特定する。
(b3)リード対象のデータがキャッシュメモリ領域に残っているか否かを判断する。
(b4)上記(b3)の判断の結果が肯定的の場合、プール管理プログラム305は、キャッシュメモリ領域内のリード対象データを、ホスト装置101に送信する。この場合、リード元仮想領域に割り当てられているページのアクセス頻度(及び、そのページを有するLDEVのアクセス頻度)は、更新されない。
(b5)上記(b3)の判断の結果が否定的の場合、プール管理プログラム305は、プール管理テーブル302を参照して、上記(b2)で特定されたリード元仮想領域にページが割り当てられているかを判断する。
(b6)上記(b5)の判断の結果が否定的であれば、プール管理プログラム305は、所定のデータ(例えばエラー応答)をホスト装置101に送信する。
(b7)上記(b5)の判断の結果が肯定的であれば、プール管理プログラム305は、リード元仮想領域に割り当てられているページからデータを読み出し、そのデータをキャッシュメモリ領域に書き込む。そして、キャッシュメモリ領域内のそのデータをホスト装置101に送信する。
(b8)プール管理プログラム305は、上記(b6)において、プール管理テーブル302における、データの書込み先のページのアクセス頻度を更新する。また、それに伴い、プログラムは、プール管理テーブル302における、そのページを有するLDEVのアクセス頻度を更新する。
【0046】
(C)プール管理プログラム305は、以下の(c1)〜(c3)の処理を含んだLDEV追加処理(プール拡張)を行う。なお、(c3)の後に、後述の(E)リバランス処理が行われて良い。
(c1)追加対象のLDEVにLDEV IDを付与する。
(c2)追加対象のLDEVをページに分割し、分割により得られた各ページにPage IDを付与する。
(c3)追加対象のLDEVに関する情報(LDEVの追加先のプールのID、(c1)で付与されたLDEV ID、(c2)で付与されたページID等)を、プール管理テーブル302に追加する。
(D)プール管理プログラム305は、以下の(d1)及び(d2)の処理を含んだLDEV削除処理(プール縮小)を行う。
(d1)削除対象のLDEV内の全ての使用ページ(いずれかの仮想領域に割り当てられているページ)内のデータを他のLDEVにマイグレーションするリバランス処理を実行する。
(d2)削除対象のLDEVに関する情報を、プール管理テーブル302から削除する。
【0047】
(E)プール管理プログラム305は、以下の(e1)〜(e4)の処理を含んだリバランス処理を行うことができる。その場合、例えば、メモリ243は、管理計算機201が有する後述のティア定義管理テーブル804を有していて良い。このリバランス処理は、定期的に行われて良い。また、このリバランス処理は、上記(d1)でのリバランス処理に適用されて良い。
(e1)プール管理プログラム305は、不適切に配置されているデータが記憶されているページをマイグレーション元のページとして特定する。具体的には、ページのアクセス頻度がそのページを有する階層のアクセス頻度範囲に含まれないページをプール管理テーブル302より検索する。なお、マイグレーション元のページは、上記(d1)のリバランス処理では、削除対象のLDEV内の使用ページである。
(e2)上記(e1)で見つけたマイグレーション元ページのアクセス頻度505が属するアクセス頻度範囲に対応した階層を特定する。
(e3)上記(e2)で特定した階層から、未使用のページを特定する。ここで特定された未使用のページが、マイグレーション先のページである。
(e4)上記(e1)で特定したマイグレーション元ページ内のデータを、上記(e3)で特定したマイグレーション先ページにマイグレーションする。また、プール管理プログラム305は、マイグレーション元ページが割り当てられている仮想領域に、マイグレーション元ページに代えて、マイグレーション先ページを割り当て、プール管理テーブル302を更新する。
【0048】
図5図6は、VVOL管理テーブル801を示す。VVOL管理テーブル801は、VVOLに関する情報を有する。VVOL管理テーブル801により、各VVOLを使用しているVM、各VVOLに要求される要求性能、及び各VVOLの仮想領域にページを提供しているプールが分かる。
【0049】
VVOL管理テーブル801は、VVOL毎に、下記情報を有する。VVOL ID901は、VVOLを識別するための情報である。サブシステムID902は、VVOLを有するストレージ装置102を識別するための情報である。容量903は、VVOLの容量を表す情報である。使用容量904は、ページが割り当てられている仮想領域の総記憶容量を表す情報である。プールID905は、VVOLに関連付けられているプールを識別するための情報である。ポートID906は、VVOLに関連づけられているストレージポートを識別するための情報である。ホストID907は、VVOLが割り当てられているホスト計算機101を識別するための情報である。VM ID908は、VVOLが割り当てられているVMを識別するための情報である。VM稼働時間909は、VMが稼働している時間帯を示す情報である。要求性能910は、VMがボリュームにアクセスする際に求められる応答性能を示す情報である。
【0050】
許容ダウンタイム911は、VMに関して許容されるダウンタイムである。ここでいうダウンタイムとは、VMがボリュームにアクセスすることが完全にできなくなることだけでなく、応答性能が要求性能よりも遅延している状態が続いている時間も含む。許容コスト912は、VMに関して、状態改善のための対策にかけることが認められているコストである。具体的な金額ではなく、High、Middle、Low、といった相対的な値を記載してもよい。時間913は、計測時間帯を示す情報である。VM性能914は、VMの応答性能を表す情報である。VVOL性能915は、VVOLの応答性能を表す情報である。アクセス分布916は、アクセス頻度範囲毎に、そのアクセス頻度範囲に該当するページの総数を表す情報である。図6では、アクセス頻度範囲は、IOPSの数値範囲を250毎に区切ってカウントしているが、1以上で整数であればこれに限定されない。状態監視プログラム810が、ストレージシステム103の有するプール管理テーブル302を基に、VVOL毎のアクセス分布を算出することができる。新規ページ割り当て容量917は、計測時間帯にVVOLに新規に割り当てられたページ割り当て総容量を示す情報である。ポート負荷918は、計測時間帯にVVOLにアクセスするために使用したポートにかかる負荷を示す情報である。
【0051】
ここで要求性能910は、VM性能914と比較される閾値である。要求性能910は、VMがストレージ装置に格納されたデータにアクセスする際に満たされるべきレスポンスタイムが登録される。例えば、VMがVVOLを指定したアクセスコマンドを発行してからその応答をVMが受け取るまでの時間長である。VVOL性能915は、VVOLの平均のレスポンスタイムである。例えば、VVOLを指定したアクセスコマンドがストレージ装置102に入ってから応答がホスト装置101に返されるまでの時間長である。
【0052】
要求性能910は例えば管理者がVMの使用状況等を考慮して決定する。VVOLの平均レスポンスタイムは、例えば、状態監視プログラム801が下記の(1)式により算出して、VVOL管理テーブル801に格納する。
【0053】
(VVOLの平均レスポンスタイム)=(VVOLに割り当てられている全てのページについての、アクセス頻度とレスポンスタイムの積の和)/(VVOLに割り当てられている全てのページについてのアクセス頻度の和)・・・(1)。ここで、アクセス頻度の単位は、例えば、IOPSである。
【0054】
例えば、VVOLにページ1〜6が割り当てられているとする。ページ1〜6のそれぞれについて、「ページが属する階層/その階層でのアクセス速度[msec]/ページのアクセス頻度[IOPS]」は、次の通りであるとする。ページ1:上位階層(SSD)/1/100、ページ2:中位階層(SAS)/10/50、ページ3:中位階層(SAS)/10/20、ページ4:下位階層(SATA)/20/10、ページ5:下位階層(SATA)/20/5、ページ6:下位階層(SATA)/20/0。
【0055】
この場合、(1)式によれば、VVOLの平均レスポンスタイムKは、
K=(100×1+50×10+20×10+10×20+5×20+0×20)/(100+50+20+10+15)=約5.37ms
となる。アクセス速度は、後述のティア定義管理テーブル804から取得する。
【0056】
このようにして求められた平均レスポンスタイム(性能)は、要求性能910から求められるVVOLについての要求応答性能と比較される。VVOL性能915には、ホストとストレージ装置間のデータ転送にかかる時間は含まれないため、環境に応じたデータ転送時間を考慮してVVOLの要求応答性能を算出する。例えば、あるVMの要求性能が5msと指定されているとする。VMがVVOLに対するアクセスコマンドを発行してからその応答をホストが受け取るまでの時間長のうち、VMとストレージ装置間のデータ転送にかかる時間として20%が必要とされる場合、期待されるVVOLのレスポンスタイムLは、
L=5ms×(100−20)÷100 =4ms
となる。
【0057】
VMがVVOLに対するアクセスコマンドを発行してからその応答をホスト計算機101が受け取るまでの時間が8msだったとする。VVOL性能915に登録された平均レスポンスタイムが4msよりも小さければ、VVOLに期待されるレスポンスタイムは満たしているものの、VMとストレージ装置間のデータ転送が遅延していると判断される。一方、VVOL性能915に登録された平均レスポンスタイムが4msよりも大きければ、VVOLのレスポンスタイム自体が期待される要求応答性能を満たしていないと判断される。
【0058】
なお、要求性能910、許容ダウンタイム911、許容コスト912については、当該VMがハイパーバイザにより生成される際などを契機として、管理者の設定を入力部により受け付け、コントローラ251がVVOL管理テーブル801に格納することとしてよい。また、上記例のように、VVOLに期待されるレスポンスタイムを、VMの要求性能910(レスポンスタイム)の所定割合の値とする代わりに、要求性能910から、規定値としてVMとストレージ装置間のデータ転送時間を差し引いた値としてもよい。また、VVOLに期待されるレスポンスタイムを、VVOL管理テーブル801の追加エントリ(図示せず)として格納してもよい。
【0059】
図7は、プール容量消費傾向管理テーブル802を示す。プール容量使用傾向管理テーブル802は、ストレージシステム103が有するプールの使用傾向に関する情報を有する。
【0060】
プールID1101は、プールを識別するための情報である。サブシステムID1102は、プールを有するストレージ装置102を識別するための情報である。時間1103は、計測時間帯を示す情報である。新規ページ割り当て容量1104は、計測時間帯に新規に割り当てられたページの総容量を示す情報である。
【0061】
図8は、ポート負荷傾向管理テーブル803を示す。ポート負荷傾向管理テーブル803は、ストレージ装置102が有するポートの使用傾向に関する情報を有する。ポートID1201は、ポートを識別するための情報である。
【0062】
最大許容負荷1202は、ポートが許容できる負荷の最大値を示す情報である。
サブシステムID1203は、ポートを有するストレージ装置102を識別するための情報である。時間1204は、計測時間帯を示す情報である。ポート負荷1205は、計測時間帯においてポートにかかった負荷を示す情報である。
【0063】
図9は、ティア定義管理テーブル804を示す。ティア定義テーブル804は、ティアの定義を表す。ティア定義テーブル804により、各ティアを構成するLDEVの種類、そのLDEVの性能、及びそのLDEVに対する最大のアクセス頻度が分かる。
【0064】
ティアレベル1301は、ティアのレベルを表す情報である。「ティアのレベル」とは、ティアの高さを表す数値である。本実施例では、数値が小さいティアほど、高いティアである。LDEVタイプ1302は、ティアに属するLDEVのタイプを表す情報である。速度1303は、ティアに対するアクセスの速度を表す情報である。最大アクセス頻度1304は、ティアに対応するアクセス頻度の最大値を示す情報である。コスト1305は、ティアに属するボリュームのビットコストを表す情報である。図9では仮に、SATAのビットコストを1としたときの値を格納している。
【0065】
各ティアの最大アクセス頻度により、各ティアのアクセス頻度範囲が表されている。図9の例によれば、上位ティア(SSD)のアクセス頻度範囲は、25000〜2500(2500を含まない)である。中位ティア(SAS)のアクセス頻度範囲は、2500〜1250(1250を含まない)である。下位ティア(SATA)のアクセス頻度範囲は、1250〜0である。
【0066】
図10は、タスク実行権限管理テーブル806を示す。タスク実行権限管理テーブル806は、ストレージ装置102(ストレージシステム103)やホスト計算機101に対する操作などのタスクを実行する際に必要となる管理権限を表す。
【0067】
タスク種別1501は、ホスト計算機、ストレージ装置等に対する操作を識別するための情報である。実行可能管理権限1502は、タスクを実行するのに必要な管理権限を示す情報である。図10の例では、ボリュームマイグレーション、プール拡張の実行にはストレージ管理権限を必要とし、VMマイグレーションの実行にはサーバ管理権限を必要とすることが分かる。タスク実行権限は、管理者の設定を入力部から受け付けて管理計算機201のCPUがタスク実行権限管理テーブル806に格納することとしてもよいし、予め管理計算機201がタスク実行権限管理テーブル806を備えることとしてもよい。
【0068】
図11は、生成中対策案管理テーブル807を示す。生成中対策案管理テーブル807は、生成した1以上の対策案とその効果を表す。生成中対策案管理テーブル807により、各対策案を構成するタスクと、対策案を実行したときの効果が分かる。
【0069】
対策案ID1601は、対策案を識別するための情報である。タスクID1602は、対策案を構成するタスクを識別するための情報である。タスク種別1603は、タスクの種別を示す情報である。タスクパラメタ1604は、タスクの実行に必要なパラメタを識別するための情報である。例えば、タスクが、ボリュームマイグレーションであれば、移動するVVOLの識別情報、移動するVVOLが移動前に使用しているプールの識別情報、移動先プールの識別情報を登録する。VMマイグレーションであれば、移動するVMの識別情報、移動するVMが移動前に使用しているホストの識別情報、移動先ホストの識別情報を登録する。プール拡張であれば、LDEV追加対象プールの識別情報、追加LDEV種別・容量を登録する。
【0070】
タスク実行権限1605は、タスクの実行に必要な管理権限を示す情報である。応答性能1606は、対策案実行後のVVOL性能(応答時間)を示す情報である。例えば、VVOL1の性能(応答時間)が悪化した時に応答性能を改善する対策案であれば、対策実行後のVVOL1の性能(応答時間)を登録する。実行時間1607は、対策実行に要する時間を示す情報である。実行コスト1608は、対策実行に要するコストを示す情報である。影響VM ID1609は、対策実行中に対策の影響が及ぶ可能性があるVMを示す情報である。実行推奨度1610は、対策案の実行推奨度を示す情報である。実行推奨度の算出方法は、図16で説明する。自動実行可否1611は、対策案の自動実行ができるかどうかを示す情報である。自動実行最終1612は、対策案が自動実行できる最後の時間であるかを示す情報である。
【0071】
ここで、自動実行とは、実行順序に依存関係を有する1以上のタスクを、特定の権限により一連の処理として実行することを指す。自動実行が許可されるとは、特定の権限を有する管理者の操作を管理計算機201等が受け付けることによる、一連の処理の自動実行のための制御が許可されることを示す。
【0072】
なお、対策案を自動実行できるか否かを判定する処理、対策案を自動実行できる最終の時間か否かを判定する処理は、図17図18で説明する。
【0073】
図12は、自動実行判定管理テーブル808を示す。自動実行判定管理テーブル808には、図11に示す生成中対策案管理テーブル808で管理される各対策案の自動実行を許すか否かを判定するための条件(ポリシ)が登録される。
【0074】
大規模システムの運用管理においては、システム構成に変更を加える場合、画一的に、全体の構成を把握、管理している上位管理者の承認を要することが通例である。しかし、例えば重要度の低いリソースにのみ影響する対策案についてまで、上位管理者が全件の検討、承認を行わなければならないとすると、管理対象が膨大となり、無駄な管理コストの増大につながる。また、対策案に複数のタスクが含まれる場合、タスク実行権限を有する管理者がタスクごとに異なると、対策案の検討、承認作業が煩雑となる。また、タスク種別としてはストレージ管理者に実行権限がある場合でも、対策案実行予定時間に稼動しているVMがあれば、業務に影響を与える可能性があるため、結局、実際の運用においては、対策案について、システム運用管理に関与している他の管理者(サーバ管理者や上位管理者)の検討、承認も要するのが実情である。
【0075】
このような管理負荷の削減のために、例えばシステム全体への影響が比較的少ない対策案や、コストのかからない対策案については、予め設定されたポリシに基づいて、上位管理者や他の管理者の権限に拠らずに自動実行を許可する。自動実行判定管理テーブル808により、対策案の自動実行が許される条件が分かる。
【0076】
自動実行判定属性1701は、自動実行を許すか否かを判定する属性を示す情報である。判定パラメタ1702は、自動実行を許す場合の自動実行判定属性に示す属性の値を示す情報である。図12の例では、自動実行判定属性として以下のエントリが登録されている。「使用リソース」は、対策案で使用するリソースである。StorageXのリソースであれば自動実行可能であり、また、VM Xが使っているリソースの場合は、重要な業務を行っているVM Xに影響を与えるおそれがあるため、自動実行否とする。「実行権限」は、対策案を構成するタスクの実行に必要な実行権限である。サーバ管理者権限が不要であれば、自動実行可能とする。「影響VM数」は、対策案の実行予定時刻に稼動しているため、対策案実行によって応答性能が下がるなどの影響を受ける可能性のあるVMの数である。影響VMが5つ以下であれば、サーバ管理者に問い合わせずに自動実行可能とする。「実行時間」は、対策案の実行に要する時間である。2時間以内に実行可能であれば、システムに与える影響が比較的小さいために、上位管理者等の権限に拠らずに自動実行可能とする。「実行コスト」は、対策案の実行に要するコストである。$1000以下であれば、上位管理者の権限に拠らずに自動実行可能とする。
【0077】
なお、実施例1に記載している属性は一例であり、記載した属性のみに限定されるものでない。例えば管理者の設定を入力部より受け付けて、対策案生成プログラム811などが、自動実行判定管理テーブル808を生成することとしてもよい。
【0078】
実施例1では、自動実行判定管理テーブル808に登録された全ての判定条件を満足した場合のみ自動実行を許すケースを例として説明する。例えば、図12の例では、以下条件をすべて満たした対策案のみ自動実行が許される。対策案に使用するリソースはStorage1であり、対策案に使用するリソースはVM Xが使っていない。対策案を構成する全てのタスクの実行にはサーバ管理権限は不要である。対策案によって影響が及ぶVMの数は5つ以下である。対策案の実行に要する時間は2時間以下で、要するコストは$1000である。
【0079】
ただし、全ての自動実行判断条件に該当した場合のみ自動実行を許可するのではなく、自動実行条件に優先度を設け、優先度の高い自動実行条件に所定数該当した場合は、優先度の低い自動実行条件に該当していなくても自動実行する、としてもよい。
【0080】
次に、記憶資源211上の状態監視プログラム810、対策案生成プログラム811について説明する。
【0081】
状態監視プログラム810は、一定時間ごとに、あるいは外部からの情報収集要求を受け付けたことを契機として、VVOL、プール、ポートの使用傾向情報及びVMの性能情報を収集し、それらの情報を、VVOL管理テーブル801、プール容量消費傾向管理テーブル802、ポート負荷傾向管理テーブル803などに記録する。
【0082】
(F)状態監視プログラム810は、例えば1時間毎に、以下の処理を実行する。
(f1)状態監視プログラム810は、プール管理テーブル302に登録された情報をストレージ装置102より取得する。
(f2)(f1)で取得した情報を基に、状態監視プログラム810は、VVOL毎の使用容量、アクセス分布、新規ページ割り当て容量を算出し、その結果と計測時間情報を、VVOL管理テーブル801の使用容量904、VVOL性能915、アクセス分布916、新規ページ割り当て容量917、時間912に追加更新する。
(f3)(f1)で取得した情報を基に、状態監視プログラム810は、プール毎の新規ページ割り当て容量を算出し、その結果と計測時間情報を、プール容量消費傾向管理テーブル802の時間1103、新規ページ割り当て容量1104、時間1103に追加更新する。
(f4)状態監視プログラム810は、VM111がVVOLに対するアクセスコマンドを発行してからその応答をVM111が受け取るまでの時間長(VM性能)をホスト計算機101から取得する。例えば、VM111がストレージ装置102に格納されたデータにアクセスする際に、VM111やハイパーバイザ112がそのレスポンスタイムを記録しておき、状態監視プログラム801はその記録結果を取得する。そして、取得したVM応答性能情報を、VVOL管理テーブル801のVM性能914に記録する。
(f5)状態監視プログラム810は、ポート負荷情報をストレージ装置102から取得する。例えば、ストレージ装置102のメモリ243上のプログラムが、ポート241の負荷情報とそのポートを使ったアクセスが発生したVVOLに関する情報を定期的にメモリ243に記録しておき、状態監視プログラム810はその記録結果を取得する。そして、取得したポート負荷情報をVVOL管理テーブル801のポート負荷918に記録する。
(f6)(f5)で取得した情報を基に、状態監視プログラム810は、VVOL毎のポート負荷情報を算出し、その結果と計測時間情報を、ポート負荷傾向管理テーブル803の時間1204、ポート負荷1205に追加更新して、処理を終了する。
【0083】
状態監視プログラム810はさらに、VM111に関して不適切な状態が発生していないかを監視する。ここでいう不適切な状態とは、例えば、ストレージ装置に格納されているデータにVMがアクセスする際の応答性能が要求する応答性能よりも遅い状態(VM応答遅延)、である。なお、応答性能が過剰に速いケースも、無駄に良いリソースが割り当てられており、不要な投資が生じていると言えるので、不適切な状態として扱うことができる。
【0084】
(G)状態監視プログラム810は、例えば、以下のステップでシステムの状態の監視を行う。
(g1)状態監視プログラム810は、VVOL管理テーブルの要求性能910と、VM性能914とを比較する。VM性能914に登録された性能値が要求性能値よりも大きい(遅い)場合は、期待されている性能をVMが満たしていないと判断し、(g2)を実施する。反対にVM性能914に登録された性能値が要求性能値よりも小さい(速い)場合は、処理を終了する。ただし、VM性能914に登録された性能値が要求性能値よりも小さすぎる場合は、無駄に良いリソースが割り当てられていると判断し、(g2)を実施してもよい。
(g2)次に状態監視プログラム810は、要求性能910から求められるVVOLの要求応答性能とVVOL性能915を比較する。VVOL性能915に登録された値が要求性能910に登録された値の所定割合を上回る(遅い)場合は、VVOL応答時間が期待を下回っていることを根本原因とするVM応答遅延が発生していることをアラートとして出力部に出力する。反対に、VVOL性能915に登録された値が要求性能910に登録された値の所定割合を下回っていたら、VVOL応答時間遅延以外を根本原因とするVM応答遅延が発生していることをアラートとして出力部に出力する。
【0085】
なお、応答遅延等に対する根本原因の特定には、応答遅延アラートのようなイベント情報に基づいて根本原因を特定するRCA(Root Cause Analysis)技術を使ってもよい。また、本実施例の以下の説明では、主にVVOLを原因としてVMの応答遅延が発生していることを想定しているが、他に、ストレージポートやネットワーク、ホスト計算機のCPUの過負荷が原因であることも考えられる。
【0086】
図13から図18は、対策案生成処理の流れを示すフローチャートである。例えば、対策案生成プログラム811は、対策案生成指示を受信したときに対策案生成処理を実行する。対策案生成指示は、状態監視プログラム809からアラートが発せられた場合などに管理者による入力を受け付けて発行されることとしてよい。
【0087】
図13は、例としてVM1で応答遅延が発生し、その根本原因がVVOL1であった場合の対策案を生成する処理フローを説明する。
【0088】
対策案生成プログラム811は、状態監視プログラム810の出力結果及び、対策案生成指示の内容として、対策案生成の動機である状態は、VM1の応答遅延であり、上記状態の根本原因は、VVOL1である、及び管理者が対策を実行する予定時間である対策実行予定時間を受け付ける(S10000)。
【0089】
次に対策案生成プログラム811は、管理計算機101が管理しているストレージシステム103が所有するプール一覧の情報をストレージシステム103より取得する(S10001)。対策案生成プログラム811は、VVOL1が使用しているプールを特定した上で、取得したプール一覧のうち、特定したプール以外のプール、すなわちVVOL1の移行先候補であるプールそれぞれに対してプール別対策案生成処理を実行する(S10002、S10003)。なお、S10003の処理の詳細は図14で説明する。以降、VVOL1が使用しているプールをプール1とする。
【0090】
次に、対策案生成プログラム811は、生成中対策案管理テーブル807を参照し、S10003の処理によって登録された対策案一覧を取得する(S10004)。対策案生成プログラム811は、取得した対策案一覧に含まれる対策案それぞれに対して、対策案効果算出処理を実行する(S10005、S10006)。なお、S10005の処理の詳細は図15で説明する。次に、対策案生成プログラム811は、生成中対策案管理テーブル807から、生成した対策案一覧を取得し、出力装置に出力して処理を終了する(S10007)。なお、上記ステップの代わりに、生成した対策案について生成中対策案管理テーブル807に格納する前に対策案効果算出処理を行った上で、算出した効果とともに対策案を生成中対策案管理テーブル807に格納することとしてもよいし、あるいは直接出力装置に出力することとしてもよい。
【0091】
図14では、図13のS10003で実行されるプール別対策案生成処理の詳細を説明する。図14は、S10002で選択したプールにVVOLを移動するタスクを含む対策案を生成する処理の流れを示すフローチャートである。VVOLをS10002で選択したプールに移動することで性能改善が見込めるかを予測し、性能改善が見込める場合にはS10002で選択したプールにVVOLを移動するタスクを含む対策案を生成する。なお、以降の説明では、S10002で処理対象プールとして選択したプールをプールXとして説明する。
【0092】
対策案生成プログラム811は、プール1とプールXが、同一ストレージ装置102が提供するプールか否かを判断する(S10010)。S10010の判断が否定的な場合は、VM1からVVOL1にアクセスするのに使用するストレージポートを変更してもよい。
【0093】
具体的には、VM1がVVOL1にアクセスする際に使用するストレージポートを、プール1を有するストレージ装置のポートからプールXを有するストレージ装置のポートに変更する。ストレージポートを変更しないと、プール1を有するストレージ装置を介して、プールXを有するストレージ装置にアクセスしなければならないため、直接アクセスするときよりも性能が遅延する可能性がある。当然VM1が稼働しているホスト計算機101から当該ポートが接続されていなくてはならないため、もし、VM1が稼働しているホスト計算機101から当該ポートが接続されていなければ、VM1を稼働させるホスト計算機自体を変更する処理を実施するか、新規にホスト計算機101とストレージ装置を接続させる必要がある。実施例1では、VM1と当該ポートとが接続されているものとする。
【0094】
対策案生成プログラム811は、プールXを有するストレージのポートを特定する(S10018)。なお、以降、S10018で特定したストレージのポートをポートXとする。次に、対策案生成プログラム811は、VM1がVVOL1にアクセスする際に使用するストレージポートを、プール1を有するストレージ装置のポートからプールXを有するストレージ装置のポートに変更したと仮定して、対策実行予定時間が、ポートXの閾値超過予定時間から対策に要する時間を差し引いた値よりも前になるか後になるかを判断する(S10019)。
【0095】
ポートXの閾値超過予定時間は、例えば、対策案生成プログラム811が以下の方法で求める。
(1)VVOL管理テーブル801などから、VVOL1が使用しているポート1のポート負荷履歴を取得し、VVOL1によるポート1の負荷傾向式を算出する。例えば、回帰分析等の手法を使うことができる。
(2)ポート負荷傾向管理テーブル803から、ポートXのポート負荷傾向を取得し、ポートXの負荷傾向式を算出する。
(3)(1)で算出したVVOL1によるポート1の負荷傾向式と、(2)で算出したポートXの負荷傾向式を使って、ポートXにかかる負荷がポート負荷傾向管理テーブル803に登録されているポートXの最大許容負荷を超過する時間を算出する。
【0096】
例えば、VVOL1がポート1にかける負荷が単調増加する傾向にあって、Y=2T+2(T:時間)という式で表されたとする。また、ポートXにかかる負荷が単調増加する傾向にあって、K=2T+10(T:時間)という式で表されたとする。
【0097】
VVOL1が使用するポートをポート1からポートXに変更すると、予測されるポートXの負荷増加傾向は、以下式で表されることになる。
【0098】
W=(2T+2)+(2T+10)=4T+12
上記式と、ポート負荷傾向管理テーブル803に登録されているポートXの最大許容負荷から、ポート最大許容負荷を超過する時間を算出する。例えば、ポート負荷傾向管理テーブル803によるとポートXの最大許容負荷が40であったとする。ポートXの負荷増加傾向は、W=4T+12、と予測されるため、Wの値が40を超えるTは、7、である。このため、現在時刻から7時間後がポート最大許容負荷を超過する時間、と算出することができる。なお、対策実行時間の算出方法の例は、図15のS10030で説明する。S10010の判断が肯定的な場合は、ストレージポートの変更は不要なため、S10018とS10019の処理は省略する。
【0099】
対策案生成プログラム811は、VVOL1をプールXに移動したと仮定して、対策実行予定時間が、プールXの容量枯渇予定時間から対策実行時間を差し引いた値よりも前か否かを判断する(S10011)。プールXの容量枯渇予定時間は、例えば、対策案生成プログラム811が以下方法で求める。
(1)VVOL管理テーブル801から、VVOL1が使用しているプール1の新規ページ割り当て容量傾向を取得し、VVOL1によるプール1の単位時間当たりの新規ページ割り当て傾向式を算出する。
(2)プール容量消費傾向管理テーブル802から、プールXのプール消費傾向を取得し、プールXの単位時間当たりのプール容量消費傾向式を算出する。
(3)(1)で取得したVVOL1によるプール1の単位時間当たりのプール容量消費傾向式と、(2)で取得したプールXの単位時間当たりのプール容量消費傾向式を使って、プールXの未使用容量が枯渇する時間を算出する。
【0100】
なお、対策が完了してすぐにプール容量が枯渇することや、ポート負荷が最大許容量を超過してしまうことを防止するために、S10019とS10011で対策実行予定時間とポートXの閾値超過予定時間(又はプールXの容量枯渇予定時間)から対策実行時間を差し引いた値を比較する際に、一定の余裕がなければその対策案は不適切であると判断してもよい。
【0101】
また、S10011ではプールXの容量枯渇予定時間と対策実行予定時間とを比較して判断を行うが、時間でなく、対策実行予定時間におけるプールXの残存容量を予測し、残存容量が十分でなければその対策案が不適切であると判断しても良い。また、例えば、HDDが納入されるのが3日後なので3日間だけ性能を維持したい、その後は納入されたHDDを使って抜本的な対策を実施するというように、その対策実行による効果(性能)を維持させたい日数が予め決まっているような場合、効果を維持させたい日数について管理者の指定を入力部により受け付け、その日数に耐えられなければその対策案は不適切であると判断してもよい。また、S10019の説明ではポート負荷が単調増加傾向にあった場合を例として説明したが、単調増加傾向になくてもポートを変更することで最大許容負荷を超えてしまう場合は、当該ポートに使用を変更することは不適切だと判定してもよい。
【0102】
次に、対策案生成プログラム811は、VVOL1をプールXに移動したと仮定して、VVOL1アクセス時の応答性能を予測する(S10012)。VVOL1アクセス時の応答性能は、例えば、VVOL管理テーブル801からVVOL1のアクセス分布履歴を取得し、対策実行予定時間のプールXのアクセス分布を算出し、算出したアクセス分布からVVOL性能の予測値を算出する。アクセス分布からVVOL性能を算出する方法は、例えば特許文献2に示された方法を用いてよい。
【0103】
次に、S10012で算出した応答性能が、VM1の要求性能910から求められるVVOL1の要求応答性能を満足しているかを判断する(S10013)。S10013の判断が否定的な場合は、対策案生成プログラム811はフロー2の処理を終了する。S10013の判断が肯定的な場合は、対策案生成プログラム811は、VVOL管理テーブル801に基づき、既にプールXから切り出されているVVOLおよびそのVVOLを使用しているVMを特定する(S10014)。
【0104】
対策案生成プログラム811は、VM1をプールXに移動したと仮定した場合に、S10014で特定したVVOL(およびVM)が、要求性能を満足するか否かを判断する(S10015)。これは、S10012で算出したプールXのアクセス分布からプールXから切り出されたVVOLの応答性能を算出し、その結果と、VVOL管理テーブル801の要求性能910から求められるVVOLの要求応答性能とを比較し、判断する。
【0105】
S10015の判断が否定的な場合は、要求性能を満足しないと判定されたVVOLをVVOL Y、VVOL Yが割り当てられているVMをVM Yとすると、改善すべき状態は、VM Yの応答遅延であり、その根本原因がVVOL Yであり、対策実行予定時間は、S10000で受け付けた対策実行予定時間であるとする対策案(タスク)生成処理を再帰的に実行する(S10016)。S10015の判断が肯定的な場合は、S10016の処理を省略する。
【0106】
なお、VVOL Yのアクセス性能を改善するための対策案(タスク)生成処理のS10019と、S10011の処理は、VVOL1のアクセス性能を改善する対策案を実施したという前提で行う。つまり、VVOL1の対策案生成処理で、VVOL1にアクセスするためのストレージポートを変更するとした場合は、VVOL1のポート負荷がポートXに加算されていることを仮定して(逆に、ポート1の負荷はVVOL1が移動した分下がる)、VVOL Yについてのプール別対策案生成処理のS10019を実施する。VVOL1の対策案生成処理で、VVOL1をプールXに移動するとした場合は、VVOL1の容量消費傾向がプールXに加算されていることを仮定して(逆に、プール1で消費されるページ容量はVVOL1が移動した分少なくなる)、VVOL Yについてのプール別対策案生成処理のS10011を実施する。
【0107】
次に、対策案生成プログラム811は、生成した対策案を生成中対策案管理テーブル807に登録して処理を終了する(S10017)。例えば、S10010の判断で肯定的と判定されてS10015の判断も肯定的であった場合は、VVOL1をプール1からプールXに移動するタスクを一対策案として生成中対策案管理テーブル807に登録する。S10010の判断で否定的と判定された場合は、VVOL1をプール1からプールXに移動するタスクと、VM1がVVOL1にアクセスするのに使用するポートをポートXに変更するタスクとを含む対策案を生成中対策案管理テーブル807に登録する。このとき、登録するタスクの種別に応じて、タスク実行権限管理テーブル806を基にタスク実行権限1605を登録し、S10012で算出した予測性能を応答性能1606に登録する。
【0108】
なお、対策案によって性能の変更が見込まれるVVOLが複数ある場合には、それぞれについての予測性能を登録することとしてもよい。また、VMとストレージ間のデータ転送時間を考慮して、VMの予測性能を登録し、以降の処理ではVVOLでなくVMの予測性能を判断に用いることとしてもよい。図11では、VMの予測性能を対策案の効果として格納している。
【0109】
以上、図13図14の処理をもって、VM1に性能遅延が発生しその原因がVVOL1の応答性能遅延であった場合の対策案を生成することができる。なお、図13図14の処理は、VVOL応答遅延が根本原因だった場合の処理であるが、根本原因が例えば、ホスト計算機101のCPUにある場合は、VMをプロセッサ負荷の低い他のホスト計算機101に移動するVMマイグレーションの対策案を生成してもよい。
【0110】
また、根本原因がVVOLにあった場合の対策としては、VVOLをプール間でマイグレーションする対策だけでなく、プールにLDEVを追加する(プール拡張)対策も考えられるため、そのような対策案を生成してもよい。例えば、VVOL管理テーブルで管理されている各VVOLのアクセス分布から、各ティアに必要とされるLDEV容量を算出する。
【0111】
また、S10016で対策案(タスク)生成処理を再帰的に実施してもなお要求性能を満足しないVMが存在し続けることがある。このようなケースに対応するために、あらかじめ対策案(タスク)生成処理を実施する最大回数を決めておき、対策案(タスク)生成処理が最大回数分実施された場合は処理を打ち止めとしてもよい。また、対策案(タスク)生成処理を再帰的に実行するうちに、解消したはずの状態が再度生じることがある。この場合も処理を打ち止めにする。
【0112】
例えば、VVOL1(VM1)の応答遅延を解消しようとするとVVOL3(VM3)の応答遅延が発生し、さらにVVOL3(VM3)の応答遅延を解消しようとすると再度VVOL1(VM1)の応答遅延が生じるという場合は、それが判明した段階で(具体的には、S10015の判定で過去に解消したはずの状態が再度生じていないかを確認する)、その対策案生成処理を中止する。これらの場合、当該対策案を生成、出力しないこととするか、または、当該対策案を実行しても残される状態(当該対策案により新たに生じる状態)を、対策案と合わせて出力することとしてよい。
【0113】
また、要求応答性能を満足しないVMのうち、要求性能と現在性能(予測性能)のギャップが大きいVMについて優先的に対策案(タスク)生成処理を実施してもよい。対策案生成処理が途中で打ち止めされたとしても、優先的に解決することができる。
【0114】
また、実施例1では、応答遅延が発生したVVOL自体を他のプールに移動するタスクを含む対策案を生成する。しかし、応答遅延が発生したVVOL自体ではなく、同じプールを共有しているVVOLを他のプールに移動させることで、状態が解消されることもある。このため、例えば、高Tierからの割り当てページ量が多いVVOLを他のプールに移動する対策案を生成してもよい。
【0115】
図15は、図13のS10006で実行される対策案効果算出処理の詳細である。図15は、S10002、S10003で生成した対策案それぞれについて、対策案の効果(応答性能、実行時間、実行コスト、影響VM数)、実行推奨度、自動実行可否、自動実行最終かを算出する処理の流れを示すフローチャートである。なお、以降の説明では、S10005で処理対象対策案として選択した対策案を対策案Xとして説明する。また、効果とは、対策案を実行した場合にシステム全体等に与える影響を指す。
【0116】
対策案生成プログラム811は、対策案Xを実行するのに要する時間を予測する(S10030)。例えば、対策案を構成するタスク毎に実行時間を算出し、各タスクをパラレルに実行できるのであれば、最も時間がかかるタスクの実行時間を対策案の実行に要する時間とし、シーケンシャルに実行する必要があるタスクであれば全てのタスクの実行時間の総和を対策案の実行時間とすることで算出する。
【0117】
また、各タスクの実行時間算出方法としては、VVOLをプール間でマイグレーションするタスクであれば、当該VVOL、および当該VVOL以外のVVOLの過去の移動履歴を使ってマイグレーションに要する時間を算出する。例えば、過去に移動したVVOLの容量とマイグレーション時の負荷情報(例えば、移動対象VVOLのアクセス頻度、移動元・移動先プールのアクセス頻度、CPU244及びポート242等にかかっている負荷)、マイグレーションにかかった時間を実績として保持しておき、移動対象となっているVVOLの容量と実績を比較することでVVOLのプール間移動に要する時間を算出する。
【0118】
次に、対策案生成プログラム811は、対策案Xの実行によって新規に使われるリソースを特定し、そのリソースを使っているVMのうち対策実行時間帯に稼働しているVMを特定する。例えば、プール1から切り出されているVVOL1をプール3に移動する対策案である場合、プール3に関連づいているVVOL、VMを特定する。図2の例では、プール3に関連づいているVVOL3、VVOL3を使っているVM3が特定される。そして、特定したVMの中からさらに、S10000で取得した「対策実行予定時間」から「対策実行予定時間+対策案の実行に要する時間」までの時間に稼働しているため、当該対策案によって影響を受ける可能性があるVMを特定する(S10031)。
【0119】
次に、対策案生成プログラム811は、対策案Xを実行するのに要するコストを算出する(S10032)。例えば、プールにLDEVを追加する対策案の場合は、プールに新規追加するLDEVの容量とLDEVの種別に応じたビットコスト情報から、追加で必要となるボリュームのコストを算出してもよい。
【0120】
次に、対策案生成プログラム811は、対策案Xの実行推奨度算出処理を算出する(S10033)。実行推奨度算出処理の詳細は図16で説明する。
【0121】
対策案生成プログラム811は、算出した対策案の実行に要する時間、対策実行予定時間帯に稼働しているVMの数、対策案の実行に要するコスト、実行推奨度の情報を、生成中対策案管理テーブル807の対策案Xの実行時間1607、影響VM数1609、実行コスト1608、実行推奨度1610に登録する(S10034)。
【0122】
対策案生成プログラム811は、自動実行可否判定処理を実行して、処理を終了する(S10035)。なお、S10035の処理の詳細は図17で説明する。
【0123】
図16は、図15のS10032で実行される実行推奨度算出処理の詳細である。図16は、S10005で選択した対策案Xの実行推奨度を算出する処理の流れを示すフローチャートである。生成した各対策案を、VVOL管理テーブル801で保持されている要求/許容要件をより満たす順に出力装置に出力し、管理者に提示することができる。
【0124】
対策案生成プログラム811は、VVOL管理テーブル801から、VVOL1を使っているVM1の要求性能、許容ダウンタイム、許容コストを取得する(S10040)。対策案生成プログラム811は、S10040で取得した要求性能と、対策案Xを実行した場合の達成性能とから、対策案Xによる性能満足度を算出する(S10041)。次に、対策案生成プログラム811は、S10040で取得した許容ダウンタイムと、対策案Xの実行時間とから対策案Xによる実行時間満足度を算出する(S10042)。次に、対策案生成プログラム811は、S10040で取得した許容コストと、対策案Xの実行コストから対策案Xによる実行コスト満足度を算出する(S10043)。
【0125】
次に、対策案生成プログラム811は、S10041、S10042、S10043で算出した値を使って、対策案Xの実行推奨度を算出する(S10044)。
【0126】
例えば、図5図6のVVOL管理テーブルで801を例にとると、VM1の要求性能は4ms、許容ダウンタイムは5時間、許容コスト$10000である。それに対して、図11の対策案1を実行した場合のVM1の応答性能は3ms、対策案の実行に要する時間は4時間、実行コスト$0である。以上より、性能満足度は、(3÷4)×100=75とする。実行時間満足度は、許容ダウンタイム内に実行可能なため100とする。実行コスト満足度も、許容コスト以内であるため、100とする。これらの値から、対策案1の実行推奨度を(75+100+100)÷3=約90.3と求める。
【0127】
性能については、遅くても早くても性能遅延またはオーバープロビジョニングという状態が生じているといえるため、どちらの場合でも要求性能と予測性能の差分を算出する。一方、実行時間、実行コストについては、短ければ短いほど、小さければ小さいほどよいといえる。このため、実行時間については、許容ダウンタイムより短いか長いか、長い場合は許容ダウンタイムと比較してどれくらい長いのかを算出する。また、実行コストについても、許容コストより小さいか大きいか、大きい場合は許容コストと比較してどれくらい大きいのかを算出する。上記の例では、実行時間、実行コストともに許容ダウンタイムよりも短く、許容コストよりも小さいため、満足度100として算出している。もし、実行時間が、許容ダウンタイムよりも長ければ、許容ダウンタイムと実行時間の差分を算出する。実行コストと許容コストについても同様である。
【0128】
それに対して、図11の対策案2を実行した場合のVMの応答性能は1ms、対策案の実行に要する時間は2時間、実行コスト$5000であるため、性能満足度は(1÷4)×100=25とする。実行時間満足度は、100とする。実行コスト満足度は、100とする。以上より、対策案2の実行推奨度を(25+100+100)÷3=75と求める。
【0129】
対策案1と対策案2の実行推奨度を比較すると、対策案1の実行推奨度の方が高い。対策案1、2ともに要求/許容要件は満たしているが、対策案2は対策案1と比較して過剰に性能が出ており、オーバープロビジョニングが生じている。このため、対策案1の方が対策案2と比較して無駄がない対策案といえ、対策案1の推奨度が高くなっている。
【0130】
このように、要求性能や許容コスト、許容されるダウンタイムをあらかじめ定義しておき、上記情報と、対策案の達成性能、実行時間、実行コストとから対策案の実行推奨度を算出することで、「多少実行コストがかかってもよいから、応答性能を早くしたい」というケースや、逆に「実行コストはかけたくないから応答性能はそこそこでよい」「性能は最低限改善されれば良いから対策に時間をかけたくない」というケース等、システム管理の事情に応じた対策案を選び出すことができる。
【0131】
図17図18は、図15のS10035で実行される自動実行可否判定処理の詳細を示す。まず図17は、S10005で選択した対策案Xが自動実行できるか否か、自動実行できる場合は自動実行できる最後のタイミングなのかを示すフローチャートである。なお、自動実行判定属性について判断する各処理の順序は、以下に限定されるものではない。
【0132】
対策案生成プログラム811は、生成中対策案管理テーブル807から対策案Xの詳細情報、実行権限、実行時間、実行コスト、影響VM IDの情報を取得する(S10050)。対策案生成プログラム811は、自動実行判定管理テーブル808より登録されている自動実行判定条件を取得する(S10051)。
【0133】
次に、対策案生成プログラム811は、対策案Xの実行によって新規に使われるリソースを対策案詳細情報から取得し(S10052)、自動実行否と判断されるリソースが含まれていないかを判断する(S10053)。例えば、図15の対策案1では、VVOL1の移動先であるプール3が新規に使われるリソースとして特定される。そして、プール3が、自動実行判定管理テーブル808の自動実行判定属性1701が「使用リソース」であるエントリの判定パラメタ1702に登録されたリソースに含まれているか否かを判断する。例えば、図12の例では、プール3が、StorageXが有するプールか否か、VM Xが使っていないリソースか否かを判断する。
【0134】
S10053の判断が否定的な場合は、生成中対策案管理テーブル807の自動実行可否1611に自動実行できない(No)ことを登録して(S10060)、処理を終了する。S10053の判断が肯定的な場合は、対策案生成プログラム811は次に、対策案Xに、自動実行否と判断される管理権限を必要とするタスクが含まれていないかを判断する(S10054)。例えば、自動実行判定管理テーブル808の自動実行判定属性1701が「実行権限」であるエントリの判定パラメタ1702に登録された管理権限を取得し、S10052で取得した対策案Xを構成する各タスクの管理権限に含まれているか否かを判断する。
【0135】
S10054の判断が否定的な場合は、S10060の処理を実行して、処理を終了する。S10054の判断が肯定的な場合は、対策案生成プログラム811は、移動先プールを共有しているVMを特定し(S10055)、対策実行予定時間に稼働しているVMの数が、自動実行可とされるVMの数よりも小さいかを判定する(S10056)。例えば、自動実行判定管理テーブル808の自動実行判定属性1701が「影響VM数」であるエントリの判定パラメタ1702に登録されたVM数を取得し、S10050で取得した対策案Xによって影響が及ぶVMの数と比較して判断する。
【0136】
S10056の判断が否定的な場合は、S10060の処理を実行して、処理を終了する。S10056の判断が肯定的な場合は、対策案生成プログラム811は、対策案Xを実行するのに要するコストが、自動実行否と判断されるコストよりも小さいかを判断する(S10057)。例えば、自動実行判定管理テーブル808の自動実行判定属性1701が「実行コスト」であるエントリの判定パラメタ1702に登録されたコストを取得し、S10050で取得した対策案Xの実行に要するコストと比較して判断する。
【0137】
S10057の判断が否定的な場合は、S10060の処理を実行して、処理を終了する。S10057の判断が肯定的な場合は、対策案生成プログラム811は、対策案Xを実行するのに要する時間が、自動実行否と判断される時間よりも小さいかを判断する(S10058)。例えば、自動実行判定管理テーブル808の自動実行判定属性1701が「実行時間」であるエントリの判定パラメタ1702に登録された実行時間を取得し、S10050で取得した対策案Xの実行に要する時間と比較して判断する。
【0138】
S10058の判断が否定的な場合は、S10060の処理を実行して、処理を終了する。S10058の判断が肯定的な場合は、自動実行判定管理テーブル808に登録された全ての自動実行条件を満足したため、次に自動実行最終時間判定処理を実行し(S10059)、処理を終了する。
【0139】
図18は、図17のS10059で実行される自動実行最終時間判定処理の詳細を示す。図18は、S10005で選択した対策案Xが自動実行できる場合に、S10000で受信した対策案実行予定時間が対策案Xを自動実行できる最終タイミングか否かを判定するフローチャートである。
【0140】
本処理では、S10000で受信した対策実行予定時間より後の時間に対策案Xを実行すると仮定して、対策案Xを自動実行できるか否かを判定し、自動実行できないと判定された場合には、S10000で受信した対策実行予定時間が対策案Xを自動実行できる最後の時間として出力する。
【0141】
なお、以下処理の説明では、対策案Xが自動実行できるかを判定した「対策実行予定時間よりも後の時間」を「対策実行予定時間+X時間」と表記している。Xには、例えば、「1分」等の固定の値が入る。例えば、S10005で受信した対策実行予定時間が、「2012年4月1日12:00」であれば、「2012年4月1日12:01」に対策案Xが自動実行できるか否かを判断し、自動実行できないと判断された場合は、「2012年4月1日12:00」が、対策案Xを自動実行できる最終タイミングとして提示される。「対策実行予定時間+X時間」のXは、システム管理環境の実情に照らして、予め設定されることとしてよい。
【0142】
以下、自動実行最終時間判定処理の詳細を説明する。対策案生成プログラム811は、対策に使用するプールの容量枯渇時間を予測し(S10070)、「対策実行予定時間+X時間」がプールの容量が枯渇する時間より後か否かを判断する(S10071)。S10071の判断が肯定的な場合、「対策実行予定時間+X時間」に示す時間には、移動先プールに必要容量を確保できなくなっており、対策案Xが実行できない。このため、生成中対策案管理テーブル807の自動実行可否1611に「自動実行できる(Yes)」であることと、「対策実行予定時間+X時間」が「自動実行できる最終タイミングであること(Yes)」を登録して(S10078)、処理を終了する。なお、この場合はそもそも対策案の実行自体が「対策実行予定時間+X時間」には不可であるので、対策案の実行の最終タイミングである旨を記録するするエントリ(図示せず)に登録することとしてもよい。
【0143】
S10071の判断が否定的な場合は、対策案生成プログラム811は、「対策実行定時間+X時間」に対策案Xを実行したと仮定して、対策案Xの実行に要する時間を算出する(S10072)。次に、対策案生成プログラム811は、対策案Xが使用するプールを使っているVMのうち、「対策実行予定時間+X時間」から対策実行完了時間までに稼働しているVMを特定する(S10073)。次に、対策案生成プログラム811は、自動実行判定管理テーブル808から、自動実行可否条件を取得する(S10074)。
【0144】
次に、対策案生成プログラム811は、S10072で算出した対策に要する時間が、自動実行可と判定される実行時間よりも大きいか否かを判断する(S10075)。S10075の判断が肯定的な場合は、「対策実行予定時間+X時間」に示す時間には対策案Xが自動実行できないと判断し、S10078の処理を実行して終了する。S10075の判断が否定的な場合は、対策案生成プログラム811は、S10073で特定したVMの数が、自動実行可と判定される影響VM数より大きいか否かを判断する(S10076)。
【0145】
S10076の判断が肯定的な場合は、「対策実行予定時間+X時間」に示す時間には対策案Xが自動実行できないと判断し、S10078の処理を実行して終了する。S10076の判断が否定的な場合は、S10001で受信した対策実行予定時間に対策案Xを自動実行できるだけでなく、「対策実行予定時間+X時間」に示す時間にも自動実行可能である。このため、生成中対策案管理テーブルの自動実行可否欄に自動実行できる(Yes)ことのみを登録して(S10077)、処理を終了する。
【0146】
図19は、対策案実行予定時間指定インフェース24000を示す。状態監視プログラム810によって状態を検知し、アラートを出力する際に表示してもよいし、その状態に対する対策案生成開始の指示を入力部により受け付けたときの最初の起動画面として表示させてもよい。
【0147】
対策案実行予定時間指定インタフェース24000は、対策実行予定日指定欄24001、対策実行予定時間指定スライダー24002、対策案生成ボタン24003を有する。管理者は、対策案実行予定時間指定インタフェース24000により、希望する時刻に採りうる対策案の生成を指示することができる。
【0148】
対策実行予定日指定欄24001では、対策の実行を予定している日の入力を受け付ける。加えて、対策実行予定時間指定スライダー24002を左右に動かすことによって実行予定時間を指定する。対策案生成ボタン24003が押下されることにより、指定された対策予定日時に対策案を実行すると仮定して対策案生成処理を実行する。なお、実際の日時でなく、何日後に実行を予定するかなど、現在時刻から対策実行予定時までの時間数の入力を受け付けるようにしても良い。
【0149】
図20は、対策案一覧提示インタフェース25000を示す。図13から図18の処理によって生成した対策案一覧を提示するための画面である。対策案一欄提示インタフェース25000は、対策案一覧25001を有する。対策案一覧には、生成中対策案管理テーブル807に登録されている対策案が実行推奨度順に提示される。対策案IDは、対策案を識別するための情報である。タスクIDは、対策案を構成するタスクを識別するための情報である。タスク種別は、タスクの種別を示す情報である。タスクパラメタは、タスクの実行に必要なパラメタを識別するための情報である。タスク実行権限は、各タスクの実行に必要な管理権限を示す情報である。応答時間は、対策案実行後の応答時間を示す情報である。実行時間は、対策実行に要する時間を示す情報である。実行コストは、対策実行に要するコストを示す情報である。影響VMは、対策実行中に対策の影響が及ぶ可能性があるVMを示す情報である。自動実行可否は、対策案を自動実行できるか否かを示す情報である。対策案が自動実行できる場合はさらに、入力を受け付けた対策案の実行予定時間が対策案を自動実行できる最終タイミングか否かを示す情報を提示する。図20の例では、自動実行可否欄がYesの場合に、対策を自動実行できる最終時間か否か(Yes or No)を提示している。
【0150】
なお、対策を自動実行できる最終時間か否か(Yes or No)ではなく、自動実行できる最終時間や自動実行できる期限を表示させてもよい。例えば、対策案実行予定時間を10:00とした場合に自動実行できるか否か、11:00とした場合に自動実行できるか、12:00とした場合に自動実行できるか、というように、現在時刻からX1、X2、X3・・・・Xnと一定時間毎に自動実行可否判定処理を実行する。そして、自動実行可否判定がYesからNoに切り替わった時間の直前を自動実行できる期限として提示する。例えば、X3の時間では自動実行可と判定されたが、X4の時間では自動実行否として判定されたら、X3の時間を自動実行できる最終時間として提示する。
【0151】
また、ある時間に自動実行否と判定されても、一定時間経過すると再度自動実行できるようになる場合もある。このようなケースに対応するために、自動実行できる最終タイミングか否か(Yes or No)や自動実行期限ではなく、自動実行できる時間帯情報を管理者に提示してもよい。
【0152】
また、管理者の判断の参考となるよう、実行推奨度1610を対策案一覧提示インタフェース25000に提示してもよい。
【0153】
管理者が実行したい対策案のチェックボックスを選択して対策案実行のボタンを押下することにより、管理計算機201のCPU212が、選択された対策案実行のための次の処理を行う。ここで、自動実行可の場合には、他の管理者の承認処理を行わずに、自動実行制御を行うこととしてよい。
【0154】
また、図19に示したインタフェースにより管理者に対策実行予定時間を指定させ、図20に示した対策案一覧画面により対策案を管理者に提示するのではなく、図21のような画面26000を出力してもよい。画面26000は対策実行日を選択する対策実行日選択欄26001、時間別対策案リスト26002を有する。対策実行日選択欄26001に提示された日付一覧から対策を実行する日付が選択されると、時間別対策案リスト26002に時間帯毎に推奨対策案が表示される。
【0155】
以上、実施例1では、計算機システムの構成とインフラリソースの使用傾向とを考慮して、管理者が指定した実行予定時間に実行可能な対策案を生成し、自動実行可否とあわせて提示することにより、システム管理負荷を軽減できる。
【実施例2】
【0156】
以下、実施例2について説明する。以下の説明においては、実施例1と異なる構成について特に詳細に説明し、実施例1と同様の構成については詳細な説明は省略する。実施例1では、管理者が指定した対策案の実行予定時間を受け付け、その時間に有効な対策案を生成、出力して管理者に提示する、と例示した。一方、実施例2では、対策案の実行予定時間の入力を受け付けるのではなく、対策を実行する時間も考慮して、より効果の高い対策案を生成し、自動実行する処理を行う。
【0157】
ここでいう効果が高いとは、要求/許容要件をより満足することを指す。例えば、対策案の実行に要する時間や、対策案の実行によって影響が及ぶVMの数等は、対策案を実行するタイミングによって変化する。このため、より対策案の実行に要する時間が短く、影響が及ぶVM数が少ない時刻に実行可能な対策案を生成し、自動実行可否を判断する。なお、実施例1と同様、実際に自動実行できる対策案は一定の条件に合致した場合のみとし、それ以外の場合は各管理者の権限に基づく実行許可を要する。
【0158】
図22は、実施例2における生成中対策案管理テーブル807である。
【0159】
実施例2の生成中対策案管理テーブル807では、実行予定時間毎に対策案とその効果を管理することができる。実施例2の生成中対策案管理テーブル807では、実施例1で示した生成中対策案管理テーブル807が保持する情報に加えて、対策案の実行予定時間である実行予定時間1613を格納する。
【0160】
図23は、実施例2における対策案生成処理の流れを示すフローチャートである。実施例1と同様、対策案生成プログラム811は、例えば対策案生成指示の受付を契機として対策案生成処理を実行する。対策案生成プログラム811は、実施例1と同様に、状態監視プログラム810によって検知された状態と、その根本原因とを取得する。ここで、実施例1の実行予定時間に替えて対策実行最遅時間を取得する(S10100)。対策実行最遅時間とは、対策実行が許される最も遅い時間である。すなわち、状態が解消されるべき最遅時間、である。生成した対策案は、対策案が生成された時間から対策実行最遅時間で指定された時間の間の、要求/許容要件をより満足する時間に実行されることになる。対策実行最遅時間は、入力部により管理者からの入力を受け付けて取得することとしてよい。
【0161】
対策案生成プログラム811は、対策案実行予定時間として、現在時刻から対策実行最遅時間で指定された時間までの任意の時間X1、X2・・・Xnを指定して、S10102からS10107までの処理を繰り返し実行する。X1・・・Xnは、例えば、一時間間隔(10:00、11:00、12:00・・・)などと予め設定されてよい。
【0162】
S10102からS10107の処理は、実施例1の対策案生成処理のS10001からS10006の処理と基本的に同じである。生成した対策案を生成中対策案管理テーブル807に登録する際に、S10101で指定した対策案実行予定時間を時間1613に登録する。S10107までの処理を実行後、対策案生成プログラム811は、生成中対策案管理テーブル807から、生成した対策案一覧を取得し、推奨度が最も高い対策案を取得し、出力する(S10108)。
【0163】
なお、S10108で取得した対策案が自動実行可能と判断されている場合は、実行予定時間1613に登録された時間に自動実行する。実施例2においては、対策案生成指示を受け付けたことをもって自動実行を「特定の権限」に基づくと判断し、管理者による実際の対策案実行指示を受け付けることなく実行してもよい。また、推奨度が最も高い対策案が自動実行否である場合などは、後述の図24のように、自動実行可能な対策案の中で推奨度が最も高い対策案を、あわせて表示し、管理者の入力を受け付けなければ、自動実行可能な対策案を優先して実行することとしてもよい。また、実施例1と同様、実行推奨度が高い順に対策案を複数表示させることとしてもよい。
【0164】
図24は、対策案一覧提示インタフェース29000を示す。対策案一覧提示インタフェース29000は、生じたそれぞれの状態に対する対策案を提示する。各々の状態に対する対策案としては、図23の処理によって生成された対策案のうち、最も推奨度が高かった対策案を提示する。
【0165】
なお、改善すべき状態が複数のリソース(VM)において発生した場合も、対策案の生成方法は図23の対策案生成処理と基本は同じであるが、プールの枯渇時間の予測、ポート負荷閾値超過時間、予測性能を算出する際に、複数のタスクを実行したと仮定して算出する必要がある。また、状態が発生した順に対策案を生成してもよいが、改善すべき状態のリソースが複数検知された状況で対策案(タスク)を生成する場合は、状態の深刻さ(性能遅延であれば要求性能と現状の性能との差分の大きさ、等)によって、対策案を生成する順序を決定してもよい。
【0166】
対策案一覧29001には、図20の対策案一覧25001の項目とほぼ同様の内容を含むが、自動実行可否の情報に替えて、自動実行可の対策案が実行される実行予定時間を表示する。実行予定時間には、生成中対策案管理テーブル807の実行予定時間1613に登録された時間を提示してもよいし、実行予定時間1613に登録された時間までのカウントダウンを表示してもよい。また、自動実行可の場合は、実行をキャンセルするボタンを表示し、自動実行をキャンセルすることを管理者に許可してもよい。実行予定時間までにキャンセルボタンの押下を受け付けなければ、CPU212は当該対策案の自動実行制御を行う。
【0167】
また、自動実行できないが通常の実行であれば可能な対策案も表示する場合は、対策案の提示とともに実行ボタンを表示し、各管理者の承認等を前提とする通常の対策案実行を選択できるようにしてもよい。図24の例では、効果が高いと判断された時間が実行時間として指定されているが、入力部により管理者の実行時間指定を受け付けることとしてもよい。また、実行推奨度が高い順に対策案を複数表示させる場合は、自動実行可能な対策案のうちで、推奨度が高い対策案を優先して自動実行する設定としておき、自動実行が予定されている対策案の実行がキャンセルされたら、次に推奨度が高く自動実行可能な対策案を自動実行することとしてもよい。
【0168】
以上、実施例2では、より効果の高い時間帯に対策案を自動実行し、管理負荷を軽減することができる。
【実施例3】
【0169】
以下の説明においては、実施例1と異なる構成について特に詳細に説明し、実施例1と同様の構成については詳細な説明は省略する。実施例1では、状態監視プログラム810によって発見された状態を解消するタスクと、その対策案を実行することによって新たに発生する状態を解消するタスクとを一つの対策案として提示していた。実施例3では、それらを分割して提示、実行できるようにする。
【0170】
これにより、対策案を構成する全てのタスクを実行するには、対策にかけられる時間が不足する場合でも、一部のタスクのみを即時実行することで、最低限解消すべき状態については対策をすることができる。ここでいう最低限解消すべき状態の対策とは、例えば、状態監視プログラム810によって検知された状態についてのみ解消することである。ただし、この場合でも、当該状態への対策に伴って生じる新たな改善すべき状態や、その大きさについての情報を出力することで、対策案を構成する全てのタスクを実行しないことによる不利益を管理者が把握できるようにする。
【0171】
図25は、実施例3における生成中対策案管理テーブル807である。実施例3の生成中対策案管理テーブル807では、対策案を構成するタスク毎にそのタスクを実行した時の効果を管理することができる。実施例3の生成中対策案管理テーブル807では、実施例1で示した生成中対策案管理テーブル807が保持する情報に加えて、タスク毎の実行に要する実行時間1614、タスク毎に要する実行コスト1615、タスク実行によって解決される状態1616、タスク実行によって残される(新たに生じる)状態1617を格納する。
【0172】
タスク毎の実行時間、タスク毎の実行コストは、図15の対策案算出処理の対策案Xの実行に要する時間、対策案Xの実行に要するコストを算出する際に(S10030、S10032の処理)、その途中経過として算出した各タスクの実行時間やコストを登録すればよい。また、解決される状態1616には、図13の対策案生成処理のS10000で受け付けた状態を登録する。残される状態1617には、図14のプール別対策案生成処理のS10015で特定した、要求を満たしていないVMに関する情報を登録する。
【0173】
図26は、実施例3における実行タスク選択インフェース31000を示す。実施例1で示した対策案一覧提示インタフェースを用いて、管理者による実行する対策案の選択を受け付けた後に、実行タスク選択インタフェース31000を出力してもよい。
【0174】
図26の実行タスク選択インタフェース31000は、対策案詳細31001、実行ボタン(活性)31002、実行ボタン(非活性)31003を有し、対策案を構成するタスク毎に実行ボタンを提示している。図26のタスク2はタスク1の実行により生じる状態(VM3応答遅延)を解消するタスクであるため、タスク1実行後に初めて実行ボタンを活性化させる。
【0175】
以上、実施例3では、生成した対策案を構成するタスクのうち、最低限の状態を解消するタスクのみを即時実行し、残りのタスクについては別の時間、例えば、S10000で管理者が指定した対策案実行予定時間に実行することができる。これにより、全てのタスクを実行する時間がない場合でも、最低限解消すべき状態についての対策を行うことができ、システム管理の精度を向上させることができる。
【符号の説明】
【0176】
101…ホスト計算機、103…ストレージシステム、201…管理計算機、251…コントローラ、801…VVOL管理テーブル、811…対策案生成プログラム
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26