ＳＡＮ管理方法およびＳＡＮ管理システム
【課題】データ転送負荷の影響を極力受けないように、アプリケーションを移行すべきホストを決定することができるＳＡＮ管理方法を提供する。
【解決手段】管理サーバ１００は、ホストＡで稼動するアプリケーションＡ１２０ａを、他のホストに移行する際、データ負荷換算処理Ｓ２０１により、ホストＢに移行した場合またはホストＣに移行した場合のＳＡＮ上のデータ転送負荷を予測し、ＳＡＮ上の各リソースにおけるボトルネック解析処理Ｓ２０２を行う。さらに、管理サーバ１００は、ボトルネック解析処理Ｓ２０２の結果に基づいて、ボトルネックが発生しないホストに移行先を決定するアプリケーションＡの移行先ホスト決定処理Ｓ２０３を行う。
【解決手段】管理サーバ１００は、ホストＡで稼動するアプリケーションＡ１２０ａを、他のホストに移行する際、データ負荷換算処理Ｓ２０１により、ホストＢに移行した場合またはホストＣに移行した場合のＳＡＮ上のデータ転送負荷を予測し、ＳＡＮ上の各リソースにおけるボトルネック解析処理Ｓ２０２を行う。さらに、管理サーバ１００は、ボトルネック解析処理Ｓ２０２の結果に基づいて、ボトルネックが発生しないホストに移行先を決定するアプリケーションＡの移行先ホスト決定処理Ｓ２０３を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＡＮ（Storage Area Networkの略、以下、ＳＡＮという。）管理方法およびＳＡＮ管理システムに関わり、特に、クラスタシステムによりアプリケーションの移行を行う際のＳＡＮ管理方法およびＳＡＮ管理システムに関する。
【背景技術】
【０００２】
近年、高可用性を要する業務アプリケーションに対してクラスタシステムを用いたシステムを構築することが一般的となっている。高可用性とは、ユーザが期待しているサービスを受けることが出来ることを意味する。例えば、システムが動いていたとしても、負荷が高くユーザに満足な応答時間でサービスを提供できなければ、ユーザにとっては故障しているとみなされる。特に、サーバ障害によりサーバで動作していたアプリケーションを他のサーバへ移行する（フェイルオーバする）際に、アプリケーションの性能保証は、ビジネスクリティカルなアプリケーションでは特に重要である。
【０００３】
特許文献１には、平常時にテストプログラムを用いて各ホストにおける性能情報を取得し、フェイルオーバ後の負荷変化が少なくなるような移行先ホストを選択可能としていることが記載されている。
【０００４】
特許文献２には、フェイルオーバ先のリソースの稼動状況に応じてフェイルオーバするアプリケーションの停止も含めた優先度の変更を行うことにより、フェイルオーバ後における性能確保を可能としていることが記載されている。
【０００５】
また、企業内で必要とされるストレージ容量が加速度的に増加し、ＳＡＮの導入とその大規模化が進んでいる。さらに、データ転送経路の負荷分散および冗長化のために、マルチパス管理ソフトを利用し、単一のホストと、ストレージサブシステムの各ボリュームの間で、複数のデータパス（ＨＢＡ（Host Bus Adapter）、ＣＨＡ（Channel Adapter）を通る論理経路）を設定して利用する場合も多い。
【０００６】
特許文献３には、複数のデータパスで冗長化を行っている環境においてパスの障害が発生した場合に、全てのデータパスの障害検知前に予防的にフェイルオーバを行うことで、フェイルオーバの切替時間を短縮可能としていることが記載されている。
【特許文献１】特開２００５−２３４９１７号公報（段落００１３、図３）
【特許文献２】特開平１１−３５３２９２号公報（段落０００９〜００２０、図２）
【特許文献３】特開２００５−１４９２８１号公報（段落００９９、図２）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
全てのＳＡＮ上の通信に関わるリソースを各ホスト、アプリケーションから排他的に利用させるのは経済的、および構成管理の煩雑さから難しい。特にＳＡＮ環境の大規模・複雑化にともない、クラスタシステム間で使用するＳＡＮリソースが非対称な場合や複雑にリソースを共有する場合が増えている。このため、あるアプリケーションの性能はＳＡＮ内部のリソースに対する他のアプリケーションのデータ転送負荷からの影響を受ける可能性がある。このことから、アプリケーションを他のホストに移行した場合のＳＡＮ内のリソース使用負荷を予測することは困難であった。
【０００８】
また、ＳＡＮでは、前記の理由から移行先ホストのアプリケーションを停止しても、その他のホストのアプリケーションがＳＡＮ上の競合するリソースを使用しデータ転送の性能保証ができない場合があった。
【０００９】
さらに、データ転送量はＳＡＮのみに影響されるものではなく、ホスト上のＣＰＵ使用率などにも依存する。このような状況では、フェイルオーバ後の性能保証を行うことも難しかった。
【００１０】
本発明は、上記の課題を解決するための発明であって、データ転送負荷の影響を極力受けないように、アプリケーションを移行すべきホストを決定することができるＳＡＮ管理方法およびＳＡＮ管理システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、アプリケーションを他のホストに移行する際に、ＳＡＮ内のデータ転送負荷を予測するために、管理サーバ上にボリュームに対するアプリケーションの負荷割合の情報と、経路毎のデータ転送負荷情報を保持する。移行元アプリケーションに対して、現在のデータ転送負荷をボリューム毎に合計し、任意のホストから同一ボリュームへ接続する経路に対して、合計したデータ転送負荷を均等に分配する。分配後のデータ転送負荷をリソース毎に合計することで、当該ホストにアプリケーションを移行した場合の各リソースのデータ転送負荷を予測する。
【００１２】
さらに、データ転送負荷の換算による予測に基づきボトルネックの解析を行う。このために、管理サーバ上にＳＡＮ経路上のリソース毎の性能上限値と、アプリケーションの優先度を保持する。データ転送負荷の換算により予測した各リソースのデータ転送負荷が性能上限値を超える場合に、低優先度のアプリケーションを任意に選択し、その分のデータ転送負荷を経路の負荷情報から削除し、アプリケーションを停止した場合の性能負荷を予測する。その上で、データ転送負荷の換算による予測を再度行ない、ボトルネックが発生しない移行先ホストが見つかるまで低優先度のアプリケーションの停止、データ転送負荷の予測とボトルネックの解析を続ける。
【００１３】
また、性能予測が困難な場合、もしくはアプリケーションの切替時間を最小としたい場合には、アプリケーションの優先度に基づき、停止可能な全てのアプリケーションを停止する。このとき、停止完了のレスポンスを最も早く返してきたホストに移行することで移行元アプリケーションの切替時間を最小にする。停止したアプリケーションは本発明の方式に基づいて、ホストを移行し停止したアプリケーションを起動する。
【発明の効果】
【００１４】
本発明によれば、ＳＡＮ環境においてアプリケーションを現在稼動中のホストと異なるホストに移行する際に、データ転送負荷の影響を極力受けないように、アプリケーションの移行すべきホストを決定することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施の形態について図面を参照して説明する。
《第１の実施の形態》
図１は、本発明の全体構成を示すブロック図である。図１に示すように、ＳＡＮ管理システムは、管理サーバ１００、ホストＡ１１０ａ、ホストＢ１１０ｂ、ホストＣ１１０ｃ、およびＦＣ（Fibre Channel）ネットワーク１４０を介して接続されたストレージ１３０を含む。ホストＡ１１０ａは、ＨＢＡポート１１３ａおよび１１３ｂを介してＦＣネットワーク１４０に接続される。ホストＢ１１０ｂは、ＨＢＡポート１１３ｃを介してＦＣネットワーク１４０に接続される。ホストＣ１１０ｃは、ＨＢＡポート１１３ｄおよび１１３ｅを介してＦＣネットワーク１４０に接続される。
【００１６】
ストレージ１３０は、ＣＨＡポート１３１ａ〜１３１ｄを介してＦＣネットワーク１４０に接続されている。管理サーバ１００とホスト１１０ａ〜１１０ｃは、ＬＡＮ１４１により接続される。ストレージ１３０には、論理的なボリューム１３２ａ〜１３２ｄがあり、ＦＣネットワーク１４０を介してアクセスされる。図１では、３台のホスト１１０ａ〜１１０ｃと１台のストレージ１３０の場合を示しているが、４台以上のホストおよび２台以上のストレージであってもよい。
【００１７】
ホストＡ１１０ａには、ストレージ１３０を利用するアプリケーション・プログラム（Ａｐｐ．Ａ）１２０ａ(以下、アプリケーション・プログラムを単にアプリケーションという。)、アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂ、アプリケーションＣ（Ａｐｐ．Ｃ）１２０ｃ、アプリケーションＤ（Ａｐｐ．Ｄ）１２０ｄ、パス管理プログラム１１２ａ、およびクラスタ管理プログラム１１１ａを含む。パス管理プログラム１１２ａは、パスの構成情報、およびホストＡ１１０ａが発行するＩ／Ｏリクエスト、データ転送量などを取得し、管理サーバ１００に渡すことができる。クラスタ管理プログラム１１１ａは、当該ホスト上で実行されるアプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の状態を監視し、監視中のアプリケーションが停止した時には、異なるホスト上で実行しているクラスタ管理プログラムと連携する。クラスタ管理プログラム１１１ａは、アプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の起動および停止を行い、アプリケーションを他のホストに移行させる。図１では、ホストＡ１１０ａ上では、現在、アプリケーションＡ１２０ａおよびアプリケーションＢ１２０ｂが稼動状態であり、アプリケーションＣ１２０ｃおよびアプリケーションＤ１２０ｄが停止状態にある。
【００１８】
ホストＢ１１０ｂには、ストレージ１３０を利用するアプリケーションＡ１２０ａ、アプリケーションＢ１２０ｂ、アプリケーションＣ１２０ｃ、アプリケーションＤ１２０ｄ、パス管理プログラム１１２ｂ、およびクラスタ管理プログラム１１１ｂを含む。パス管理プログラム１１２ｂは、パスの構成情報、およびホストＢ１１０ｂが発行するＩ／Ｏリクエスト、データ転送量などを取得し、管理サーバ１００に渡すことができる。クラスタ管理プログラム１１１ｂは、当該ホスト上で実行されるアプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の状態を監視し、監視中のアプリケーションが停止した時には、異なるホスト上で実行しているクラスタ管理プログラムと連携する。クラスタ管理プログラム１１１ｂは、アプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の起動および停止を行い、アプリケーションを他のホストに移行させる。図１では、ホストＢ１１０ｂ上では、現在、アプリケーションＣ１２０ｃが稼動状態であり、アプリケーションＡ１２０a、アプリケーションＢ１２０ｂ、およびアプリケーションＤ１２０ｄが停止状態にある。
【００１９】
ホストＣ１１０ｃには、ストレージ１３０を利用するアプリケーションＡ１２０ａ、アプリケーションＢ１２０ｂ、アプリケーションＣ１２０ｃ、アプリケーションＤ１２０ｄ、パス管理プログラム１１２ｃ、およびクラスタ管理プログラム１１１ｃを含む。パス管理プログラム１１２ｃは、パスの構成情報、およびホストＣ１１０ｃが発行するＩ／Ｏリクエスト、データ転送量などを取得し、管理サーバ１００に渡すことができる。クラスタ管理プログラム１１１ｃは、当該ホスト上で実行されるアプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の状態を監視し、監視中のアプリケーションが停止した時には、異なるホスト上で実行しているクラスタ管理プログラムと連携する。クラスタ管理プログラム１１１ｃは、アプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の起動および停止を行い、アプリケーションを他のホストに移行させる。図１では、ホストＣ１１０ｃ上では、現在、アプリケーションＤ１２０ｄが稼動状態であり、アプリケーションＡ１２０a、アプリケーションＢ１２０ｂ、およびアプリケーションＣ１２０ｃが停止状態にある。管理サーバ１００の構成については、図３で説明する。
【００２０】
図２は、本発明の骨子を示す概念図である。図２では図示していないが、ホストＡ１１０ａには、クラスタ管理プログラム１１１ａと、パス管理プログラム１１２ａとを有している。ホストＢ１１０ｂには、クラスタ管理プログラム１１１ｂと、パス管理プログラム１１２ｂとを有している。ホストＣ１１０ｃには、クラスタ管理プログラム１１１ｃと、パス管理プログラム１１２ｃとを有している。
【００２１】
可用性を高めるために、各ホスト１１０ａ〜１１０ｃからストレージ１３０への論理経路は、複数のポートを利用することで冗長化される。本実施の形態では、ホストＡ１１０ａからストレージ１３０への接続の場合、ＨＢＡポート１１３ａおよび１１３ｂ、ＣＨＡポート１３１ａおよび１３１ｂが使われる。ホスト上のパス管理プログラムは冗長化された経路を、ＨＢＡポートおよびＣＨＡポートの組合せによる論理経路として認識する。本実施の形態のホストＡ１１０ａの場合、４つの論理経路が存在する。概念図では、発明のポイントを明快にするために論理経路を用いて説明している。
【００２２】
同様に、本実施の形態では、ホストＣ１１０ｃからストレージ１３０への接続の場合、ＨＢＡポート１１３ｄおよび１１３ｅ、ＣＨＡポート１３１ｃおよび１３１ｄが使われる。ホストＣ１１０ｃの場合、４つの論理経路が存在する。
【００２３】
各ホストの構成は同一とは限らず、論理経路も異なる場合がある。本実施の形態の場合、ホストＢ１１０ｂは、１つのＨＢＡポート１１３ｃと３つのＣＨＡポート１３１ｂ、１３１ｃ、および１３１ｄの組合せによる３つの論理経路を持つ。
【００２４】
パス管理プログラム１１２ａ〜１１２ｄ（図１参照）は、ストレージ１３０の各ボリューム１３２ａ〜１３２ｄに対応するデバイス２２０ａ〜２２０ｄを当該ホスト上に構築する。デバイスは、アプリケーションがＩ／Ｏリクエストを発行するインタフェースとも言えるもので、論理経路が冗長化されていてもボリュームに対して１つになる。本実施の形態では、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａは、デバイス２２０ａおよびデバイス２２０ｂを使用して、ボリューム１３２ａおよびボリューム１３２ｂにアクセスする。アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂは、デバイス２２０ｂを使用して、ボリューム１３２ｂにアクセスする。アプリケーションＣ（Ａｐｐ．Ｃ）１２０ｃは、デバイス２２０ｃを使用して、ボリューム１３２ｃにアクセスする。アプリケーションＤ（Ａｐｐ．Ｄ）１２０ｄは、デバイス２２０ｄを使用して、ボリューム１３２ｄにアクセスする。
【００２５】
平常運用時において、管理サーバ１００は、パス情報集約処理Ｓ２００を行う。本実施の形態では、各ホスト上のパス管理プログラム（パス管理ソフト）から論理パス毎のデータ転送負荷を集約するものとする。なお、パス情報集約処理Ｓ２００は、図９に詳細なステップを示す。
【００２６】
ここで、アプリケーションＡ１２０ａをホストＢ１１０ｂまたはホストＣ１１０ｃに移行する場合を考える。移行の契機は、例えば、ホストＡ１１０ａの制御部（図示していない）が、クラスタ管理プログラム１１１ａに基づいて、アプリケーションＡ１２０ａの障害を検知した場合である。但し、本発明は、移行の契機をクラスタ管理プログラム（クラスタ管理ソフト）１１１ａに限定するものではない。例えば、ホストＡ１１０ａの制御部が、パス管理プログラム（パス管理ソフト）１１２ａに基づいて、冗長化されたパスの一部に障害を検知した場合に早めに移行を決定してもよい。また、ユーザが、事前評価のために特定のアプリケーションを指定してもよい。アプリケーションＡ１２０ａが選択された場合、管理サーバ１００では、アプリケーションＡ１２０ａによって発生していたデータ転送負荷について、移行先の候補ホストであるホストＢ１１０ｂ、ホストＣ１１０ｃのパスへのデータ負荷換算処理Ｓ２０１を行う。これにより、アプリケーションＡ１２０ａの移行元データ転送負荷２１０をホストＢ１１０ｂに移行時またはホストＣ１１０ｃに移行時の換算後データ転送負荷２１１および２１２を予測する。データ負荷換算処理Ｓ２０１の詳細なステップは、図１１に示す。
【００２７】
次に、管理サーバ１００は、データ負荷換算処理Ｓ２０１による予測に基づいて、ＳＡＮ上の各リソースにおけるボトルネック解析処理Ｓ２０２を行う。ＳＡＮ上の各リソースとはＣＨＡポート１３１ａ〜１３１ｄ、ＨＢＡポート１１３ａ〜１１３ｅがある。ボトルネック解析処理Ｓ２０２の詳細なステップは、図１３に示す。
【００２８】
最後に、管理サーバ１００では、ボトルネック解析処理Ｓ２０２の結果に基づいて、アプリケーションＡ１２０ａの移行先ホスト決定処理Ｓ２０３を行い、ボトルネックが発生しないホストに移行先を決定する。決定した移行先をホストＡ１１０ａに通知することで、アプリケーションＡ１２０ａの移行を行う。ユーザによる事前評価の場合は、移行先ホストとその他の評価内容とともに結果レポートとして出力する。移行先ホスト決定処理Ｓ２０３の詳細なステップは、図１０に示す。
【００２９】
図３は、管理サーバの構成を示すブロック図である。管理サーバ１００は、表示装置３０１、入力装置３０２、中央演算処理装置（ＣＰＵ）３０３、通信制御装置３０４、外部記憶装置３０５、メモリ３０６、およびこれらを接続するバス３０７から構成される。表示装置３０１は、ディスプレイなどであり、管理サーバ１００による処理の実行状況や実行結果などを表示する。入力装置３０２は、キーボードやマウスなどのコンピュータに指示を入力するための装置であり、プログラム起動などの指示を入力する。中央演算処理装置（ＣＰＵ）３０３は、メモリ３０６に格納される各種プログラムを実行する。通信制御装置３０４は、ＬＡＮ１４１を介して、他の装置と各種データやコマンドを交換する。外部記憶装置３０５は、管理サーバ１００が処理を実行するための各種データを保存する。メモリ３０６は、管理サーバ１００が処理を実行する各種プログラムおよび一時的なデータを保持する。
【００３０】
外部記憶装置３０５には、経路別負荷テーブル３２０、ボリューム利用比率テーブル３２１、換算レートテーブル３２２、性能上限値テーブル３２３、アプリケーション優先度テーブル３２４が格納される。
【００３１】
メモリ３０６には、パス情報集約プログラム３１０、移行先ホスト決定プログラム３１１、データ負荷換算プログラム３１２、ボトルネック解析プログラム３１３が格納される。
【００３２】
パス情報集約プログラム３１０は、パス情報集約処理Ｓ２００を実行するプログラムであり、通信制御装置３０４を介して取得した各ホストの性能情報を集約し、経路別負荷テーブル３２０に格納する。
【００３３】
データ負荷換算プログラム３１２は、経路別負荷テーブル３２０、ボリューム利用比率テーブル３２１、換算レートテーブル３２２を用いて、データ負荷換算処理Ｓ２０１を行う。
【００３４】
ボトルネック解析プログラム３１３は、換算した結果と性能上限値テーブル３２３を用いてボトルネック解析処理Ｓ２０２を行う。
【００３５】
移行先ホスト決定プログラム３１１は、データ負荷換算プログラム３１２を実行して負荷換算を行ない、換算結果を入力としてボトルネック解析プログラム３１３を実行する。ボトルネックの解析結果とアプリケーション優先度テーブル３２４に基づいて、移行先ホスト決定処理Ｓ２０３を行う。
【００３６】
図４は、経路別負荷テーブルの一例を示す説明図である。図４に示す経路別負荷テーブル３２０には、経路情報として、ＨＢＡ４０１、ＣＨＡ４０２、ボリューム４０３の組を持ち、その論理経路毎にデータ転送量４０４を格納する。ＨＢＡ４０１は、ＨＢＡポートを識別する情報であり、そのＨＢＡポートのＷＷＮ（World Wide Name）若しくはホスト名とポート番号の組などである。ＣＨＡ４０２は、ＣＨＡポートを識別する情報であり、そのＣＨＡポートのＷＷＮやストレージ名とポート番号の組などである。ボリューム４０３は、ボリュームの識別子であり、ストレージ名とボリューム番号の組であらわす。本実施の形態では、これらを図１、図２で用いた番号で表す。
【００３７】
図４に示すように、データ転送負荷の値としては、秒間のデータ転送量を用いた。データ転送負荷としては、Ｉ／Ｏリクエストの発行回数などでもよい。また、記録されているデータは、平常運用時の稼動実績を平均したデータとなる。本実施の形態では、各ホスト１１０ａ〜１１０ｃのパス管理プログラム１１２ａ〜１１２ｃで、短期的な平均値を計算しているものとする。一方、管理サーバ１００に時系列毎の性能情報を蓄積し、中長期的な平均値を計算してこれを用いることもできる。本発明では、データ負荷情報の種別および負荷情報における平均値の取り方については問わない。
【００３８】
具体例として、ボリューム１３２ａに対する経路別負荷を４１０に示す。当該経路は４つであり、経路毎に８０ＭＢ／ｓのデータ転送量である。また、本テーブルには実際にアクセスしていないボリュームに対する情報も含まれる。４１１は、ホストＡ１１０ａからボリューム１３２ｂに対する経路であり、当該経路は４つであり、経路毎にデータ転送量は１００ＭＢ／ｓである。４１２は、ホストＡ１１０ａからボリューム１３２ｃに対する経路であり、この場合のデータ転送量は０ＭＢ／ｓである。４１３は、ホストＢ１１０ｂからボリューム１３２ｃに対する経路であり、当該経路は３つであり、経路毎にデータ転送量は８０ＭＢ／ｓである。４１４は、ホストＣ１１０ｃからボリューム１３２ｄに対する経路であり、当該経路は４つであり、経路毎にデータ転送量は１２０ＭＢ／ｓである。なお、アクセスしていないボリュームへのデータは仮想的な値として入力してもよい。しかし、アプリケーションに障害発生時に、他のホストに移行させるような状況では、フェイルオーバに要する時間は短くすべきである。このためにＳＡＮに対するセキュリティ設定や各ホスト上でデバイスを認識させることは平常時に行い、論理経路は設定済みとすべきである。論理経路が設定済みであれば、各ホストのパス管理ソフトは通常の論理経路と同様にデータ転送量０ＭＢ／ｓの経路として認識し、管理サーバに情報を送ることができる。
【００３９】
本具体例では、データ転送量０ＭＢ／ｓのデータを一部省略するが、４つのボリューム１３２ａ〜１３２ｄについて計１１本の論理経路が存在するため、実際の行数は４４行となる。
【００４０】
図５は、ボリューム利用比率テーブルの一例を示す説明図である。ボリューム利用比率テーブル３２１には、ボリューム５０１のデータ転送負荷に対するアプリケーション５０２毎の使用割合５０３が示されている。本実施の形態の場合、ボリューム１３２ｂに対するデータ転送負荷を表す２行（５１０）のうちアプリケーションＡ（Ａｐｐ．Ａ）１２０ａが０．２、アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂが０．８の割合で使用している。ファイルシステムを介してアクセスしているような場合にはこのようなケースが発生する。一方、ボリューム１３２ａ、１３２ｃ、および１３２ｄは、使用するアプリケーションが限定されている。この場合はアプリケーションの使用割合が１．０となる。
【００４１】
図６は、換算レートテーブルの一例を示す説明図である。換算レートテーブル３２２には、ホスト６０１に対するデータ転送負荷の換算レート６０２が設定される。ホスト６０１には、ホストＡ（Ｈｏｓｔ．Ａ）１１０ａ、ホストＢ（Ｈｏｓｔ．Ｂ）１１０ｂ、およびホストＣ（Ｈｏｓｔ．Ｃ）１１０ｃがある。同一のアプリケーションを実行した場合でも高性能なホスト上ではより多くの処理を行ない、結果としてより多くのＩ／Ｏリクエストを行う場合がある。本換算レート６０２は、前記のような状況を換算による予測値に取り込むためのものである。例えば、ホストＡ（Ｈｏｓｔ．Ａ）１１０ａのレートが１．２であるのに対し、ホストＣ（Ｈｏｓｔ．Ｃ）１１０ｃのレートは１．５である。これは、ホストＡ１１０ａのアプリケーションをホストＣ１１０ｃで実行した場合、１．５／１．２＝１．２５倍の性能負荷に換算することを表す。
【００４２】
図７は、性能上限値テーブルの一例を示す説明図である。性能上限値テーブル３２３には、リソース７０１毎にデータ転送負荷の上限値（上限転送量）７０２を保持する。本実施の形態では、リソースとしてＨＢＡポート１１３ａ〜１１３ｅおよびＣＨＡポート１３１ａ〜１３１ｄを考慮する。例えば、１１３ｃが許容できる上限のデータ転送量は４００ＭＢ／ｓである。
【００４３】
図８は、アプリケーション優先度テーブルの一例を示す説明図である。アプリケーション優先度テーブル３２４には、アプリケーション８０１に対する優先順位８０２と停止可否８０３を保持する。例えば、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａは、優先順位１であり、最優先のアプリケーションであり、停止不可のアプリケーションである。アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂは、優先順位１０であり、停止可のアプリケーションである。
【００４４】
次に動作について、図１〜図３を参照しつつ、主に図９、図１０、図１１、および図１３に沿って説明する。
【００４５】
図９は、パス情報集約処理の処理過程を示すフローチャートである。図９には、図２に示すパス情報集約処理Ｓ２００のフローチャートが示されている。パス情報集約処理Ｓ２００は、パス情報集約プログラム３１０に基づき、各ホスト１１０ａ〜１１０ｃ上のパス管理プログラム（パス管理ソフト）１１２ａ〜１１２ｃにより、論理パス毎のデータ転送負荷を集約するものである。中央演算処理装置（ＣＰＵ）３０３は、一定時間毎にパス情報集約を繰り返す（ステップＳ９０１）。一定時間毎にパス情報集約を繰り返すことにより、最新のパス情報を得ることができる。中央演算処理装置３０３は、管理サーバ１００が管理する全てのホスト１１０ａ〜１１０ｃに対してパス情報集約を繰り返す（ステップＳ９０２）。パス情報集約プログラム３１０に基づいて、中央演算処理装置３０３は、各ホスト上のパス管理プログラム１１２ａ〜１１２ｃに対して通信を行ない、経路毎のデータ転送量を取得し（ステップＳ９０３）、収集したデータ転送負荷を、図４に示される経路別負荷テーブル３２０に格納する（ステップＳ９０４）。
【００４６】
図１０は、第１の実施の形態における移行先ホスト決定処理の処理過程を示すフローチャートである。図１０には、図２に示す移行先ホスト決定処理Ｓ２０３のフローチャートが示されている。移行先ホスト決定処理Ｓ２０３は、移行先ホスト決定プログラム３１１に基づき、データ負荷換算プログラム３１２およびボトルネック解析プログラム３１３を実行する。具体例と共に各ステップを説明する。
【００４７】
中央演算処理装置（ＣＰＵ）３０３は、クラスタ管理プログラム１１１ａ〜１１１ｃから障害が発生したアプリケーションについて通知を受け取る。本通知により、移行すべきアプリケーションが選択される。本例では、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａに障害が発生し、クラスタ管理プログラム１１１ａによって通知されたものとする（ステップＳ１００１）。中央演算処理装置３０３は、全ての移行先の候補ホストについて、以降のステップＳ２０１、Ｓ２０２を行う。本実施の形態の場合、候補ホストはホストＢ１１０ｂおよびホストＣ１１０ｃである（ステップＳ１００２）。
【００４８】
中央演算処理装置３０３は、データ負荷換算プログラム３１２に基づき、データ負荷換算を行う。入力は、障害が発生したアプリケーションと移行先候補のホストであり、出力は、候補ホストに対する換算後のデータ転送負荷である（ステップＳ２０１）。中央演算処理装置３０３は、ボトルネック解析プログラム３１３に基づき、通信経路のボトルネック解析を行う。入力は、データ負荷換算プログラム３１２により出力した換算後のデータ転送負荷、出力は、ボトルネックの有無である（ステップＳ２０２）。ステップＳ２０１、ステップＳ２０２において、ホストＢ１１０ｂに移行した場合の換算後データ負荷とボトルネック解析経過をそれぞれ図１２、図１４に示す。
【００４９】
図１２は、ホストＢに移行した場合の換算後データ負荷情報を示す説明図である。図１２に示すデータ負荷情報１２００には、図４と同様に、経路情報として、ＨＢＡ１２０１、ＣＨＡ１２０２、ボリューム１２０３の組を持ち、その論理経路毎にデータ転送量１２０４を格納する。
【００５０】
図１４は、ホストＢに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１４００には、リソース１４０１毎にデータ転送負荷の上限Ｉ／Ｏ量１４０２、および予測Ｉ／Ｏ量１４０３を保持する。
【００５１】
また、ホストＣ１１０ｃに移行した場合の換算後データ負荷とボトルネック解析経過をそれぞれ図１５、図１６に示す。
【００５２】
図１５は、ホストＣに移行した場合の換算後データ負荷情報を示す説明図である。図１５に示すデータ負荷情報１５００には、図４と同様に、経路情報として、ＨＢＡ１５０１、ＣＨＡ１５０２、ボリューム１５０３の組を持ち、その論理経路毎にデータ転送量１５０４を格納する。
【００５３】
図１６は、ホストＣに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１６００には、リソース１６０１毎にデータ転送負荷の上限Ｉ／Ｏ量１６０２、および予測Ｉ／Ｏ量１６０３を保持する。
【００５４】
中央演算処理装置３０３は、ボトルネックの発生有無を確認する（ステップＳ１００３）。もし、全ての移行先の候補ホストについてボトルネックが発生する場合、ステップＳ１００４に進む。本具体例の場合、ホストＢ１１０ｂに移行すると図１４に示すようにＨＢＡポート１１３ｃにボトルネックが発生する。すなわち、ＨＢＡポート１１３ｃにおいて、予測Ｉ／Ｏ量１４１３は、５４０ＭＢ／ｓであり、上限Ｉ／Ｏ量４００ＭＢ／ｓを超える。また、ホストＣ１１０ｃに移行すると図１６に示すようにＣＨＡポート１３１ｃおよび１３１ｄにボトルネックが発生する。すなわち、ＣＨＡポート１３１ｃおよび１３１ｄにおいて、予測Ｉ／Ｏ量１６１１および１６１２は、５７０ＭＢ／ｓであり、上限Ｉ／Ｏ量５００ＭＢ／ｓを超える。ステップＳ１００３でボトルネックの発生しない候補ホストがある場合、ステップＳ１００６に進む。
【００５５】
ステップＳ１００４において、中央演算処理装置３０３は、アプリケーション優先度テーブル３２４（図８参照）から障害発生アプリケーションよりも優先度が低く、かつ、停止可能なアプリケーションを取得する。本具体例の場合、アプリケーションＡ（Ａｐｐ．Ａ）より優先度の低く、かつ、停止可能なアプリケーションは、アプリケーションＢ（Ａｐｐ．Ｂ）、アプリケーションＣ（Ａｐｐ．Ｃ）、およびアプリケーションＤ（Ａｐｐ．Ｄ）である。このうち、より優先度の低いアプリケーションＣ（Ａｐｐ．Ｃ）を選択する。なお、条件を満たすアプリケーション全てについてデータ負荷換算を行ない、換算後にＳＡＮ上のリソースに対するデータ転送負荷の偏りが最も少ないアプリケーションを停止予定アプリケーションとして選択してもよい。
【００５６】
ステップＳ１００５において、中央演算処理装置３０３は、停止予定アプリケーションのデータ転送負荷を経路別負荷テーブル３２０から減算し、アプリケーション停止後のデータ負荷を予測する。このデータ負荷に基づいて、再度データ負荷の換算とボトルネック解析を行う（ステップＳ１００２、ステップＳ２０１、およびステップＳ２０２）。本具体例では、アプリケーションＣ（Ａｐｐ．Ｃ）のデータ負荷を減算する。
【００５７】
アプリケーションＣ（Ａｐｐ．Ｃ）を停止した場合において、ホストＢに移行した場合のボトルネック解析経過を図１７に示す。アプリケーションＣ（Ａｐｐ．Ｃ）を停止する前のホストＢに移行した場合のボトルネック解析経過である図１４に比べて、ＨＢＡポート１１３ｃのボトルネックが解消されている。すなわち、ＨＢＡポート１１３ｃの予測Ｉ／Ｏ量１７１１は、３００ＭＢ／ｓであり、上限Ｉ／Ｏ量４００ＭＢ／ｓ以内となっている。アプリケーションＣ（Ａｐｐ．Ｃ）を停止した場合において、ホストＣに移行した場合のボトルネック解析経過を図１８に示す。アプリケーションＣ（Ａｐｐ．Ｃ）を停止する前のホストＣに移行した場合のボトルネック解析経過である図１６に比べて、ＣＨＡポート１３１ｃ、１３１ｄのボトルネックが解消されている。すなわち、ＣＨＡポート１３１ｃおよび１３１ｄにおいて、予測Ｉ／Ｏ量１８１１および１８１２は、４９０ＭＢ／ｓであり、上限Ｉ／Ｏ量５００ＭＢ／ｓ以内となっている。ステップＳ１００３において、全ての候補ホストでボトルネックが発生しない場合、ステップＳ１００６に進む。
【００５８】
ステップＳ１００６において、中央演算処理装置３０３は、停止予定アプリケーションが存在した場合に、停止予定アプリケーションが稼動中の該当ホストに停止の通知をし、実際に停止を行う。停止予定アプリケーションとは、ステップＳ１００４にて選択したアプリケーションである。該当ホストの制御部は、クラスタ管理プログラムに基づき、当該アプリケーションの停止を行う。本具体例では、ホストＢに対して、アプリケーションＣ（Ａｐｐ．Ｃ）が停止として通知される。なお、実際の停止をステップＳ１００５で行わない理由は、停止可能なアプリケーションを全て停止しても、ボトルネックが解消しない場合が考えられるからである。
【００５９】
ステップＳ１００７において、中央演算処理装置３０３は、ボトルネックが発生しない候補ホストの中から移行先ホストを決定し、移行先ホストの制御部に通知する。条件を満たすホストが複数ある場合には、例えば各リソースにかかるデータ負荷の偏りが最も少ないホストを移行先とする。本具体例の場合、アプリケーションＣ（Ａｐｐ．Ｃ）の停止後にホストＢに移行した場合を図１７に、アプリケーションＣ（Ａｐｐ．Ｃ）の停止後にホストＣに移行した場合を図１８に示す。どちらの場合もボトルネックは発生しない。この場合、各リソースにかかるデータ負荷の標準偏差は、ホストＢに移行した場合６９であり、ホストＣに移行した場合１８６である。よって偏りの少ないホストＢを移行先として決定する。
【００６０】
なお、例えば、移行後の性能が最も高くなるように、例えばデータ転送量の平均が大きいものを選んでもよい。本具体例の場合、ホストＢに移行すると２４４ＭＢ／ｓ、ホストＣに移行すると２８９ＭＢ／ｓであり、ホストＣを移行先として選択する。いずれの場合も、移行先として決定したホストの制御部に通知し、アプリケーションの移行を行う。
【００６１】
図１１は、データ負荷換算処理の処理過程を示すフローチャートである。図１１には、図２に示すデータ負荷換算処理Ｓ２０１のフローチャートが示されている。データ負荷換算処理Ｓ２０１は、データ負荷換算プログラム３１２に基づき、アプリケーションを移行する際に移行元ホストで選択された移行元アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストでの移行元アプリケーションに対するデータ転送負荷に換算する。移行先ホスト決定プログラム３１１から、移行するアプリケーションと移行先の候補ホストを入力として呼び出される。以下では、具体例として、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａをホストＢ１１０ｂに移行する場合について示す。
【００６２】
中央演算処理装置（ＣＰＵ）３０３は、ボリューム利用比率テーブル３２１から入力アプリケーションに対応するボリュームの情報を取得する。本具体例では、入力アプリケーションがアプリケーションＡ（Ａｐｐ．Ａ）であり、対応するボリュームがボリューム１３２ａおよび１３２ｂである（ステップＳ１１０１）。中央演算処理装置３０３は、経路別負荷テーブル３２０（図４参照）から、ステップＳ１１０１で特定したボリュームに対応する行を抽出する。本具体例の場合、４１０および４１１の行を抽出する（ステップＳ１１０２）。中央演算処理装置３０３は、抽出したデータ転送量をボリューム毎に合計する。本具体例では、ボリューム１３２ａに対応するデータ転送量が３２０ＭＢ／ｓ、１３２ｂに対応するデータ転送量が４００ＭＢ／ｓである（ステップＳ１１０３）。
【００６３】
中央演算処理装置３０３は、ステップＳ１１０３で算出した値にボリューム利用比率テーブル３２１（図５参照）の利用比率（使用割合）を乗算し、入力アプリケーションによるボリューム毎のデータ転送量を計算する。ボリューム１３２ａに対応するデータ転送量は１．０をかけて３２０ＭＢ／ｓ、ボリューム１３２ｂに対応するデータ転送量は０．２をかけて８０ＭＢ／ｓである（ステップＳ１１０４）。中央演算処理装置３０３は、換算レートテーブル３２２（図６参照）から候補ホストに対するレートを取得し、ステップＳ１１０４で求めた値に乗算する。本具体例では、０．９／１．２＝０．７５である。よって、ボリューム１３２ａに対応するデータ転送量は３２０×０．７５＝２４０、ボリューム１３２ｂに対応するデータ転送量は８０×０．７５＝６０に換算される（ステップＳ１１０５）。中央演算処理装置３０３は、候補ホストから移行するアプリケーションが利用するボリュームまでの経路を選択する。本具体例では、図１２に示した１２１１および１２１２が相当する。なお、この時点では、１２１１、および１２１２のデータ転送量は０である（ステップＳ１１０６）。
【００６４】
中央演算処理装置３０３は、ステップＳ１１０５で求めた値をステップＳ１１０６で選択したパスに均等に分配して加算する。本具体例では、ボリューム１３２ａに対する経路１２１１に、ステップＳ１１０６で求めたデータ転送量２４０ＭＢ／ｓを加える。経路１２１１は３経路なので、ボリューム１３２ａに対する各経路のデータ転送量は８０ＭＢ／ｓに分配する。同様にボリューム１３２ｂに対応して、経路１２１２に２０ＭＢ／ｓずつ分配する（ステップＳ１１０７）。中央演算処理装置３０３は、出力として換算後のデータ転送負荷を出力する。ホストＢ移行時の換算データ負荷情報１２００（図１２参照）は、換算後のデータ負荷情報である。但し、データ転送量が０ＭＢ／ｓの行は省略している（ステップＳ１１０８）。
【００６５】
図１３は、ボトルネック解析処理の処理過程を示すフローチャートである。図１３には、図２に示すボトルネック解析処理Ｓ２０２のフローチャートが示されている。ボトルネック解析処理Ｓ２０２は、ボトルネック解析プログラム３１３に基づき、データ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネックの解析を行う。移行先ホスト決定プログラム３１１から、換算後のデータ転送負荷を入力として呼び出される。具体例では、前記換算後のデータ負荷情報１２００を入力として示す。
【００６６】
中央演算処理装置（ＣＰＵ）３０３は、以降のステップをＳＡＮ上の各リソースに対して繰り返す。本実施例では、ＨＢＡポート１１３ａ〜１１３ｅおよびＣＨＡポート１３１ａ〜１３１ｄである（ステップＳ１３０１）。中央演算処理装置３０３は、換算後のデータ転送負荷を当該リソースについて集約する。本具体例では、ＨＢＡポート１１３ａについて集約した値は１６０ＭＢ／ｓとなる。ステップＳ１３０１の全てのリソースについて集約した結果を図１４のホストＢ移行時のボトルネック解析経過１４００に示す。各リソース１４０１に対応する集約値は、予測Ｉ／Ｏ量１４０３である（ステップＳ１３０２）。中央演算処理装置３０３は、性能上限値テーブル３２３から当該リソースと対応する上限値（上限Ｉ／Ｏ量）を取得する。具体例では、ＨＢＡポート１１３ａに対応する上限のデータ転送量は５００ＭＢ／ｓである。図１４では、分かりやすさのために性能上限値テーブル３２３から取得した上限値（上限Ｉ／Ｏ量）１４０２を合わせて示す（ステップＳ１３０３）。中央演算処理装置３０３は、集約後のデータ転送負荷がリソースの上限負荷を超えるかどうかを確認する。上限を超える場合にはステップＳ１３０５に移る。本具体例では、リソースのＨＢＡポート１１３ｃの集約値（予測Ｉ／Ｏ量）１４１３が上限値である４００ＭＢ／ｓを超える（ステップＳ１３０４）。中央演算処理装置３０３は、出力としてボトルネックの発生有無を呼び出し元プログラムに伝える（ステップＳ１３０５）。以上、アプリケーションＡ（Ａｐｐ．Ａ）をホストＢに移行する場合について説明した。
【００６７】
一方、アプリケーションＡ（Ａｐｐ．Ａ）をホストＣに移行する場合は以下のようになる。まず、データ負荷換算プログラム３１２による換算は以下のようになる。ステップＳ１１０６では、１．５／１．２＝１．２５となる。よって、ボリューム１３２ａに対応する転送量は３２０×１．２５＝４００ＭＢ／ｓ、ボリューム１３２ｂに対応する転送量は８０×１．２５＝１００ＭＢ／ｓである。ステップＳ１１０７では、図１５に示した１５１１および１５１２が相当する。ステップＳ１１０８では、換算後の経路は４つなので、ボリューム１３２ａに対する各経路のデータ転送量は１００ＭＢ／ｓとなる。同様にボリューム１３２ｂに対応して、１５１２の各経路のデータ転送量は２５ＭＢ／ｓとなる。ステップＳ１１０８で出力される換算後のデータ転送負荷を、ホストＣ移行時の換算後データ負荷情報１５００（図１５参照）に示す。
【００６８】
次に、図１６に示すように、ホストＣ移行時のボトルネック解析経過１６００には、ＣＨＡポート１３１ｃおよび１３１ｄに対する集約結果１６１１および１６１２が共に５７０ＭＢ／ｓとなり、ボトルネックが発生する。
【００６９】
図１７は、アプリケーションＣを停止し、かつ、ホストＢに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１７００には、リソース１７０１毎にデータ転送負荷の上限Ｉ／Ｏ量１７０２、および予測Ｉ／Ｏ量１７０３を保持する。中央演算処理装置３０３（図３参照）は、ステップＳ１００４（図１０参照）において、アプリケーション優先度テーブル３２４から低優先度で停止可能なアプリケーションを取得し、ステップＳ１００５（図１０参照）において、停止予定アプリケーションのデータ負荷をデータ負荷から減算している。アプリケーションＣ（Ａｐｐ．Ｃ）を停止すると、図１２の１２１０に示す経路に対するデータ転送量が０となる。ステップＳ２０２におけるボトルネック解析の結果、ＨＢＡポート１１３ｃに対する集約結果である予測Ｉ／Ｏ値１７１１は、３００ＭＢ／ｓであり、上限Ｉ／Ｏ値４００ＭＢ／ｓを超えていない。また、その他のリソースにおいても、予測Ｉ／Ｏ値は、上限Ｉ／Ｏ値以内でありボトルネックは発生しない。
【００７０】
図１８は、アプリケーションＣを停止し、かつ、ホストＣに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１８００には、リソース１８０１毎にデータ転送負荷の上限Ｉ／Ｏ量１８０２、および予測Ｉ／Ｏ量１８０３を保持する。アプリケーションＣ（Ａｐｐ．Ｃ）を停止すると、図１５の１５１０に示す経路に対するデータ転送量が０となる。ステップＳ２０２におけるボトルネック解析の結果、ＣＨＡポート１３１ｃおよび１３１ｄの集約結果である予測Ｉ／Ｏ値１８１１および１８１２は、いずれも４９０ＭＢ／ｓであり、上限Ｉ／Ｏ値５００ＭＢ／ｓを超えていない。また、その他のリソースにおいても、予測Ｉ／Ｏ値は、上限Ｉ／Ｏ値以内でありボトルネックは発生しない。
【００７１】
図１９は、アプリケーション移行情報ログの一例を示す説明図である。アプリケーション移行に関する情報は，動作履歴として管理サーバ１００の表示装置３０１に表示されてもよい。表示される情報は、移行したアプリケーション、移行元の業務サーバ、移行先の業務サーバ、優先度に基づいて停止したアプリケーションである。また、より詳細な情報としてボトルネックの発生予測を表示する。図１９には、アプリケーションＡをホストＡから他のホストへ移行する移行情報が示されている。具体的には、ホストＢへ移行する場合にボトルネックが発生する可能性があること、ホストＣへ移行する場合にボトルネックが発生する可能性があることが表示されている。このため、優先度定義（例えば、アプリケーション優先度テーブル３２４）に基づいて、アプリケーションＣを停止し、移行先ホストとして、ホストＢが決定されたことが表示されている。
【００７２】
本実施の形態では、ホストを管理する管理サーバ１００が、障害が発生しているホストからアプリケーションの障害通知を受け取ると、障害が生じたアプリケーションの移行先の候補となる各ホストに対して、アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストで運用したときのデータ転送負荷に換算するデータ負荷換算とデータ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネック解析とを行い、前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生したときは、アプリケーション優先度テーブルから障害が生じたアプリケーションよりも低優先度で停止可能なアプリケーションを取得して停止予定アプリケーションを決定し、停止予定アプリケーションを停止した条件で、障害が生じたアプリケーションの移行先の候補となる各ホストに対して、前記データ負荷換算と前記ボトルネック解析とを行い、前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生しないときは、停止予定アプリケーションがあれば停止を指示し、候補ホストから移行先ホストを決定し、障害が発生しているホストへ移行を指示する。これにより、アプリケーションを現在稼動中のホストと異なるホストに移行する場合に、データ転送負荷の影響を極力受けないように、アプリケーションの移行すべきホストを決定することができる。
【００７３】
《第２の実施の形態》
図２０は、第２の実施の形態における移行先ホスト決定ステップの処理過程を示すフローチャートである。本実施の形態は、第１の実施の形態とシステム構成は同じであるが、移行先ホスト決定プログラム３１１の処理手順が異なる。まず、障害通知を受け取った移行元アプリケーションより低優先度のアプリケーションを停止し、移行元アプリケーションの移行を完了する。その後、停止した低優先度のアプリケーションを第１の実施の形態に従って移行する。これにより、高優先度の移行元アプリケーションの移行に掛かる時間を短くすると共に、移行元アプリケーションが受けるデータ転送負荷の影響を少なくすることが出来る。
【００７４】
中央演算処理装置（ＣＰＵ）３０３は、移行先ホスト決定プログラム３１１に基づき実行する。ホストＡ、ホストＢ、およびホストＣの各制御部は、クラスタ管理プログラム１１１ａ〜１１１ｃに基づき実行する。具体例と共に各ステップの動作について説明する。
【００７５】
ステップＳ１００１は、図１０のステップＳ１００１と同じである。中央演算処理装置３０３は、アプリケーション優先度テーブル３２４から移行元アプリケーションよりも低優先度で、かつ、停止可能な全てのアプリケーションの情報を取得する。本具体例の場合、アプリケーションＡ（Ａｐｐ．Ａ）よりも優先度が低く、かつ、停止可能なアプリケーションとして、アプリケーションＢ（Ａｐｐ．Ｂ）、アプリケーションＣ（Ａｐｐ．Ｃ）、アプリケーションＤ（Ａｐｐ．Ｄ）が取得される（ステップＳ１９０１）。中央演算処理装置３０３は、取得した全ての停止可能アプリケーションに対して、停止指示を行う。すなわち、中央演算処理装置３０３は、停止可能アプリケーションの停止要求を、当該アプリケーションが動作する各ホストに送信する。本具体例の場合、ホストＡ、ホストＢ、およびホストＣに通知する（ステップＳ１９０２）。中央演算処理装置３０３は、ステップＳ１９０２で通知した停止指示に最も早くレスポンスを返したホストを移行先ホストに決定する。これは、稼動状態の確認となりアプリケーションの移行時間を削減できるためである。中央演算処理装置３０３は、決定したホストの制御部に通知し、アプリケーションの移行を行う。具体例としては、ホストＣの制御部が、中央演算処理装置３０３に最も早くレスポンスを返したものとする。中央演算処理装置３０３は、ホストＣの制御部に通知し、アプリケーションＡ（Ａｐｐ．Ａ）を移行する（ステップＳ１９０３）。中央演算処理装置３０３は、アプリケーションＡ（Ａｐｐ．Ａ）移行後のデータ転送負荷を、パス情報集約プログラム３１０が取得するまで待ち合わせる。アプリケーションＡ（Ａｐｐ．Ａ）の移行によるデータ転送負荷の変化を反映するためである（ステップＳ１９０４）。中央演算処理装置３０３は、ステップＳ１９０２にて停止した全てのアプリケーションについて優先度順に以下のステップを繰り返す。本具体例の場合、アプリケーションＤ（Ａｐｐ．Ｄ）、アプリケーションＢ（Ａｐｐ．Ｂ）、アプリケーションＣ（Ａｐｐ．Ｃ）の順に処理を行う（ステップＳ１９０５）。
【００７６】
ステップＳ１００２、Ｓ２０１、およびＳ２０２は、第１の実施の形態と同じであり、中央演算処理装置３０３は、停止したアプリケーションについて、データ負荷換算ステップＳ２０１とボトルネック解析ステップＳ２０２を行う。中央演算処理装置３０３は、ボトルネック解析の結果、全ての候補ホストでボトルネックが発生する場合に処理を終了する。停止可能なホストが全て停止しており、これ以上ボトルネックを改善できる見込みがないためである（ステップＳ１９０６）。ステップＳ１００７は、第１の実施の形態と同じであり、中央演算処理装置３０３は、ボトルネックが発生しない候補ホストの中から移行先ホストを決定し、移行先ホストの制御部に通知する。条件を満たすホストが複数ある場合には、例えば各リソースにかかるデータ負荷の偏りが最も少ないホストを移行先とする。
【００７７】
本実施の形態では、ホストを管理する管理サーバ１００が、アプリケーションを移行する際に、アプリケーションの優先度が移行元ホストで選択された移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する停止可能アプリケーションを決定するステップ（ステップＳ１９０１）と、決定された停止可能アプリケーションが動作するホストに対して停止指示を行うステップ（ステップＳ１９０２）と、前記停止指示に最も早くレスポンスを返したホストを移行先ホストに決定し、決定した移行先ホストに対し前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストに選択されたアプリケーションの移行指示を行うアプリケーション移行ステップ（ステップＳ１９０３）とを含んで実行する。これにより、アプリケーションを現在稼動中のホストと異なるホストに移行する場合に、データ転送負荷の影響を極力受けないように、アプリケーションの移行すべきホストを決定することができる。
【００７８】
以上述べた実施の形態においては、ＳＡＮ上のリソースとして、ＣＨＡポート１３１ａ〜１３１ｄ、ＨＢＡポート１１３ａ〜１１３ｅとして説明した。しかし、リソースとしては、必ずしもこのＣＨＡポート１３１ａ〜１３１ｄ、ＨＢＡポート１１３ａ〜１１３ｅに限らない。例えば、ＦＣネットワーク１４０を構築するファイバチャネルスイッチをリソースとしてもよい。この場合、図４の経路別負荷テーブル３２０に、ファイバチャネルスイッチを合わせて収集し格納すると、ボトルネック解析処理Ｓ２０２において、ファイバチャネルスイッチに対してもデータ転送負荷を集約することができ、ポートのボトルネック以外に、ＦＣネットワーク１４０に関してのボトルネックについても評価することができる。
【００７９】
また、以上述べた実施の形態においては、アプリケーションを移行する際の契機は、アプリケーションの障害を検知した場合、ＨＢＡおよびＣＨＡを通る論理経路パスに障害を検知した場合、ユーザが事前評価のためにアプリケーションの移行を指定した場合として説明したが、必ずしもこのような場合に限らない。例えば、アプリケーションの障害、パスの障害ではないが、ユーザが特定のホストに集中したため、サーバ管理者がユーザに満足な応答時間でアプリケーションのサービスを提供できないと判断した場合に、アプリケーションを移行する際の契機としてもよい。
【産業上の利用可能性】
【００８０】
本発明は、データ転送負荷の影響を極力受けないように、アプリケーションを移行すべきホストを決定する用途に適用でき、例えば、クラスタシステムによりアプリケーションの移行を行う際のＳＡＮ管理方法およびＳＡＮ管理システムの用途に適用できる。
【図面の簡単な説明】
【００８１】
【図１】本発明の全体構成を示すブロック図である。
【図２】本発明の骨子を示す概念図である。
【図３】管理サーバの構成を示すブロック図である。
【図４】経路別負荷テーブルの一例を示す説明図である。
【図５】ボリューム利用比率テーブルの一例を示す説明図である。
【図６】換算レートテーブルの一例を示す説明図である。
【図７】性能上限値テーブルの一例を示す説明図である。
【図８】アプリケーション優先度テーブルの一例を示す説明図である。
【図９】パス情報集約処理の処理過程を示すフローチャートである。
【図１０】第１の実施の形態における移行先ホスト決定処理の処理過程を示すフローチャートである。
【図１１】データ負荷換算処理の処理過程を示すフローチャートである。
【図１２】ホストＢに移行した場合の換算後データ負荷情報を示す説明図である。
【図１３】ボトルネック解析処理の処理過程を示すフローチャートである。
【図１４】ホストＢに移行した場合のボトルネック解析経過を示す説明図である。
【図１５】ホストＣに移行した場合の換算後データ負荷情報を示す説明図である。
【図１６】ホストＣに移行した場合のボトルネック解析経過を示す説明図である。
【図１７】アプリケーションＣを停止し、かつ、ホストＢに移行した場合のボトルネック解析経過を示す説明図である。
【図１８】アプリケーションＣを停止し、かつ、ホストＣに移行した場合のボトルネック解析経過を示す説明図である。
【図１９】アプリケーション移行情報ログの一例を示す説明図である。
【図２０】第２の実施の形態における移行先ホスト決定ステップの処理過程を示すフローチャートである。
【符号の説明】
【００８２】
Ｓ２００ パス情報集約処理
Ｓ２０１ データ負荷換算処理
Ｓ２０２ ボトルネック解析処理
Ｓ２０３ 移行先ホスト決定処理
１００ 管理サーバ
１１０ａ，１１０ｂ，１１０ｃ ホスト
１１１ａ，１１１ｂ，１１１ｃ クラスタ管理プログラム
１１２ａ，１１２ｂ，１１２ｃ パス管理プログラム
１１３ａ，１１３ｂ，１１３ｃ，１１３ｄ，１１３ｅ ＨＢＡポート
１２０ａ，１２０ｂ，１２０ｃ，１２０ｄ アプリケーション・プログラム
１３０ ストレージ
１３１ａ，１３１ｂ，１３１ｃ，１３１ｄ ＣＨＡポート
１３２ａ，１３２ｂ，１３２ｃ，１３２ｄ ボリューム
１４０ ＦＣネットワーク
１４１ ＬＡＮ
２１０ 移行元データ転送負荷
２１１ ホストＢに移行時の換算後データ転送負荷
２１２ ホストＣに移行時の換算後データ転送負荷
２２０ａ，２２０ｂ，２２０ｃ，２２０ｄ デバイス
３０１ 表示装置
３０２ 入力装置
３０３ 中央演算処理装置（ＣＰＵ）
３０４ 通信制御装置
３０５ 外部記憶装置
３０６ メモリ
３０７ バス
３１０ パス情報集約プログラム
３１１ 移行先ホスト決定プログラム
３１２ データ負荷換算プログラム
３１３ ボトルネック解析プログラム
３２０ 経路別負荷テーブル
３２１ ボリューム利用比率テーブル
３２２ 換算レートテーブル
３２３ 性能上限値テーブル
３２４ アプリケーション優先度テーブル
【技術分野】
【０００１】
本発明は、ＳＡＮ（Storage Area Networkの略、以下、ＳＡＮという。）管理方法およびＳＡＮ管理システムに関わり、特に、クラスタシステムによりアプリケーションの移行を行う際のＳＡＮ管理方法およびＳＡＮ管理システムに関する。
【背景技術】
【０００２】
近年、高可用性を要する業務アプリケーションに対してクラスタシステムを用いたシステムを構築することが一般的となっている。高可用性とは、ユーザが期待しているサービスを受けることが出来ることを意味する。例えば、システムが動いていたとしても、負荷が高くユーザに満足な応答時間でサービスを提供できなければ、ユーザにとっては故障しているとみなされる。特に、サーバ障害によりサーバで動作していたアプリケーションを他のサーバへ移行する（フェイルオーバする）際に、アプリケーションの性能保証は、ビジネスクリティカルなアプリケーションでは特に重要である。
【０００３】
特許文献１には、平常時にテストプログラムを用いて各ホストにおける性能情報を取得し、フェイルオーバ後の負荷変化が少なくなるような移行先ホストを選択可能としていることが記載されている。
【０００４】
特許文献２には、フェイルオーバ先のリソースの稼動状況に応じてフェイルオーバするアプリケーションの停止も含めた優先度の変更を行うことにより、フェイルオーバ後における性能確保を可能としていることが記載されている。
【０００５】
また、企業内で必要とされるストレージ容量が加速度的に増加し、ＳＡＮの導入とその大規模化が進んでいる。さらに、データ転送経路の負荷分散および冗長化のために、マルチパス管理ソフトを利用し、単一のホストと、ストレージサブシステムの各ボリュームの間で、複数のデータパス（ＨＢＡ（Host Bus Adapter）、ＣＨＡ（Channel Adapter）を通る論理経路）を設定して利用する場合も多い。
【０００６】
特許文献３には、複数のデータパスで冗長化を行っている環境においてパスの障害が発生した場合に、全てのデータパスの障害検知前に予防的にフェイルオーバを行うことで、フェイルオーバの切替時間を短縮可能としていることが記載されている。
【特許文献１】特開２００５−２３４９１７号公報（段落００１３、図３）
【特許文献２】特開平１１−３５３２９２号公報（段落０００９〜００２０、図２）
【特許文献３】特開２００５−１４９２８１号公報（段落００９９、図２）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
全てのＳＡＮ上の通信に関わるリソースを各ホスト、アプリケーションから排他的に利用させるのは経済的、および構成管理の煩雑さから難しい。特にＳＡＮ環境の大規模・複雑化にともない、クラスタシステム間で使用するＳＡＮリソースが非対称な場合や複雑にリソースを共有する場合が増えている。このため、あるアプリケーションの性能はＳＡＮ内部のリソースに対する他のアプリケーションのデータ転送負荷からの影響を受ける可能性がある。このことから、アプリケーションを他のホストに移行した場合のＳＡＮ内のリソース使用負荷を予測することは困難であった。
【０００８】
また、ＳＡＮでは、前記の理由から移行先ホストのアプリケーションを停止しても、その他のホストのアプリケーションがＳＡＮ上の競合するリソースを使用しデータ転送の性能保証ができない場合があった。
【０００９】
さらに、データ転送量はＳＡＮのみに影響されるものではなく、ホスト上のＣＰＵ使用率などにも依存する。このような状況では、フェイルオーバ後の性能保証を行うことも難しかった。
【００１０】
本発明は、上記の課題を解決するための発明であって、データ転送負荷の影響を極力受けないように、アプリケーションを移行すべきホストを決定することができるＳＡＮ管理方法およびＳＡＮ管理システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、アプリケーションを他のホストに移行する際に、ＳＡＮ内のデータ転送負荷を予測するために、管理サーバ上にボリュームに対するアプリケーションの負荷割合の情報と、経路毎のデータ転送負荷情報を保持する。移行元アプリケーションに対して、現在のデータ転送負荷をボリューム毎に合計し、任意のホストから同一ボリュームへ接続する経路に対して、合計したデータ転送負荷を均等に分配する。分配後のデータ転送負荷をリソース毎に合計することで、当該ホストにアプリケーションを移行した場合の各リソースのデータ転送負荷を予測する。
【００１２】
さらに、データ転送負荷の換算による予測に基づきボトルネックの解析を行う。このために、管理サーバ上にＳＡＮ経路上のリソース毎の性能上限値と、アプリケーションの優先度を保持する。データ転送負荷の換算により予測した各リソースのデータ転送負荷が性能上限値を超える場合に、低優先度のアプリケーションを任意に選択し、その分のデータ転送負荷を経路の負荷情報から削除し、アプリケーションを停止した場合の性能負荷を予測する。その上で、データ転送負荷の換算による予測を再度行ない、ボトルネックが発生しない移行先ホストが見つかるまで低優先度のアプリケーションの停止、データ転送負荷の予測とボトルネックの解析を続ける。
【００１３】
また、性能予測が困難な場合、もしくはアプリケーションの切替時間を最小としたい場合には、アプリケーションの優先度に基づき、停止可能な全てのアプリケーションを停止する。このとき、停止完了のレスポンスを最も早く返してきたホストに移行することで移行元アプリケーションの切替時間を最小にする。停止したアプリケーションは本発明の方式に基づいて、ホストを移行し停止したアプリケーションを起動する。
【発明の効果】
【００１４】
本発明によれば、ＳＡＮ環境においてアプリケーションを現在稼動中のホストと異なるホストに移行する際に、データ転送負荷の影響を極力受けないように、アプリケーションの移行すべきホストを決定することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施の形態について図面を参照して説明する。
《第１の実施の形態》
図１は、本発明の全体構成を示すブロック図である。図１に示すように、ＳＡＮ管理システムは、管理サーバ１００、ホストＡ１１０ａ、ホストＢ１１０ｂ、ホストＣ１１０ｃ、およびＦＣ（Fibre Channel）ネットワーク１４０を介して接続されたストレージ１３０を含む。ホストＡ１１０ａは、ＨＢＡポート１１３ａおよび１１３ｂを介してＦＣネットワーク１４０に接続される。ホストＢ１１０ｂは、ＨＢＡポート１１３ｃを介してＦＣネットワーク１４０に接続される。ホストＣ１１０ｃは、ＨＢＡポート１１３ｄおよび１１３ｅを介してＦＣネットワーク１４０に接続される。
【００１６】
ストレージ１３０は、ＣＨＡポート１３１ａ〜１３１ｄを介してＦＣネットワーク１４０に接続されている。管理サーバ１００とホスト１１０ａ〜１１０ｃは、ＬＡＮ１４１により接続される。ストレージ１３０には、論理的なボリューム１３２ａ〜１３２ｄがあり、ＦＣネットワーク１４０を介してアクセスされる。図１では、３台のホスト１１０ａ〜１１０ｃと１台のストレージ１３０の場合を示しているが、４台以上のホストおよび２台以上のストレージであってもよい。
【００１７】
ホストＡ１１０ａには、ストレージ１３０を利用するアプリケーション・プログラム（Ａｐｐ．Ａ）１２０ａ(以下、アプリケーション・プログラムを単にアプリケーションという。)、アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂ、アプリケーションＣ（Ａｐｐ．Ｃ）１２０ｃ、アプリケーションＤ（Ａｐｐ．Ｄ）１２０ｄ、パス管理プログラム１１２ａ、およびクラスタ管理プログラム１１１ａを含む。パス管理プログラム１１２ａは、パスの構成情報、およびホストＡ１１０ａが発行するＩ／Ｏリクエスト、データ転送量などを取得し、管理サーバ１００に渡すことができる。クラスタ管理プログラム１１１ａは、当該ホスト上で実行されるアプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の状態を監視し、監視中のアプリケーションが停止した時には、異なるホスト上で実行しているクラスタ管理プログラムと連携する。クラスタ管理プログラム１１１ａは、アプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の起動および停止を行い、アプリケーションを他のホストに移行させる。図１では、ホストＡ１１０ａ上では、現在、アプリケーションＡ１２０ａおよびアプリケーションＢ１２０ｂが稼動状態であり、アプリケーションＣ１２０ｃおよびアプリケーションＤ１２０ｄが停止状態にある。
【００１８】
ホストＢ１１０ｂには、ストレージ１３０を利用するアプリケーションＡ１２０ａ、アプリケーションＢ１２０ｂ、アプリケーションＣ１２０ｃ、アプリケーションＤ１２０ｄ、パス管理プログラム１１２ｂ、およびクラスタ管理プログラム１１１ｂを含む。パス管理プログラム１１２ｂは、パスの構成情報、およびホストＢ１１０ｂが発行するＩ／Ｏリクエスト、データ転送量などを取得し、管理サーバ１００に渡すことができる。クラスタ管理プログラム１１１ｂは、当該ホスト上で実行されるアプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の状態を監視し、監視中のアプリケーションが停止した時には、異なるホスト上で実行しているクラスタ管理プログラムと連携する。クラスタ管理プログラム１１１ｂは、アプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の起動および停止を行い、アプリケーションを他のホストに移行させる。図１では、ホストＢ１１０ｂ上では、現在、アプリケーションＣ１２０ｃが稼動状態であり、アプリケーションＡ１２０a、アプリケーションＢ１２０ｂ、およびアプリケーションＤ１２０ｄが停止状態にある。
【００１９】
ホストＣ１１０ｃには、ストレージ１３０を利用するアプリケーションＡ１２０ａ、アプリケーションＢ１２０ｂ、アプリケーションＣ１２０ｃ、アプリケーションＤ１２０ｄ、パス管理プログラム１１２ｃ、およびクラスタ管理プログラム１１１ｃを含む。パス管理プログラム１１２ｃは、パスの構成情報、およびホストＣ１１０ｃが発行するＩ／Ｏリクエスト、データ転送量などを取得し、管理サーバ１００に渡すことができる。クラスタ管理プログラム１１１ｃは、当該ホスト上で実行されるアプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の状態を監視し、監視中のアプリケーションが停止した時には、異なるホスト上で実行しているクラスタ管理プログラムと連携する。クラスタ管理プログラム１１１ｃは、アプリケーションＡ〜アプリケーションＤ（１２０ａ〜１２０ｄ）の起動および停止を行い、アプリケーションを他のホストに移行させる。図１では、ホストＣ１１０ｃ上では、現在、アプリケーションＤ１２０ｄが稼動状態であり、アプリケーションＡ１２０a、アプリケーションＢ１２０ｂ、およびアプリケーションＣ１２０ｃが停止状態にある。管理サーバ１００の構成については、図３で説明する。
【００２０】
図２は、本発明の骨子を示す概念図である。図２では図示していないが、ホストＡ１１０ａには、クラスタ管理プログラム１１１ａと、パス管理プログラム１１２ａとを有している。ホストＢ１１０ｂには、クラスタ管理プログラム１１１ｂと、パス管理プログラム１１２ｂとを有している。ホストＣ１１０ｃには、クラスタ管理プログラム１１１ｃと、パス管理プログラム１１２ｃとを有している。
【００２１】
可用性を高めるために、各ホスト１１０ａ〜１１０ｃからストレージ１３０への論理経路は、複数のポートを利用することで冗長化される。本実施の形態では、ホストＡ１１０ａからストレージ１３０への接続の場合、ＨＢＡポート１１３ａおよび１１３ｂ、ＣＨＡポート１３１ａおよび１３１ｂが使われる。ホスト上のパス管理プログラムは冗長化された経路を、ＨＢＡポートおよびＣＨＡポートの組合せによる論理経路として認識する。本実施の形態のホストＡ１１０ａの場合、４つの論理経路が存在する。概念図では、発明のポイントを明快にするために論理経路を用いて説明している。
【００２２】
同様に、本実施の形態では、ホストＣ１１０ｃからストレージ１３０への接続の場合、ＨＢＡポート１１３ｄおよび１１３ｅ、ＣＨＡポート１３１ｃおよび１３１ｄが使われる。ホストＣ１１０ｃの場合、４つの論理経路が存在する。
【００２３】
各ホストの構成は同一とは限らず、論理経路も異なる場合がある。本実施の形態の場合、ホストＢ１１０ｂは、１つのＨＢＡポート１１３ｃと３つのＣＨＡポート１３１ｂ、１３１ｃ、および１３１ｄの組合せによる３つの論理経路を持つ。
【００２４】
パス管理プログラム１１２ａ〜１１２ｄ（図１参照）は、ストレージ１３０の各ボリューム１３２ａ〜１３２ｄに対応するデバイス２２０ａ〜２２０ｄを当該ホスト上に構築する。デバイスは、アプリケーションがＩ／Ｏリクエストを発行するインタフェースとも言えるもので、論理経路が冗長化されていてもボリュームに対して１つになる。本実施の形態では、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａは、デバイス２２０ａおよびデバイス２２０ｂを使用して、ボリューム１３２ａおよびボリューム１３２ｂにアクセスする。アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂは、デバイス２２０ｂを使用して、ボリューム１３２ｂにアクセスする。アプリケーションＣ（Ａｐｐ．Ｃ）１２０ｃは、デバイス２２０ｃを使用して、ボリューム１３２ｃにアクセスする。アプリケーションＤ（Ａｐｐ．Ｄ）１２０ｄは、デバイス２２０ｄを使用して、ボリューム１３２ｄにアクセスする。
【００２５】
平常運用時において、管理サーバ１００は、パス情報集約処理Ｓ２００を行う。本実施の形態では、各ホスト上のパス管理プログラム（パス管理ソフト）から論理パス毎のデータ転送負荷を集約するものとする。なお、パス情報集約処理Ｓ２００は、図９に詳細なステップを示す。
【００２６】
ここで、アプリケーションＡ１２０ａをホストＢ１１０ｂまたはホストＣ１１０ｃに移行する場合を考える。移行の契機は、例えば、ホストＡ１１０ａの制御部（図示していない）が、クラスタ管理プログラム１１１ａに基づいて、アプリケーションＡ１２０ａの障害を検知した場合である。但し、本発明は、移行の契機をクラスタ管理プログラム（クラスタ管理ソフト）１１１ａに限定するものではない。例えば、ホストＡ１１０ａの制御部が、パス管理プログラム（パス管理ソフト）１１２ａに基づいて、冗長化されたパスの一部に障害を検知した場合に早めに移行を決定してもよい。また、ユーザが、事前評価のために特定のアプリケーションを指定してもよい。アプリケーションＡ１２０ａが選択された場合、管理サーバ１００では、アプリケーションＡ１２０ａによって発生していたデータ転送負荷について、移行先の候補ホストであるホストＢ１１０ｂ、ホストＣ１１０ｃのパスへのデータ負荷換算処理Ｓ２０１を行う。これにより、アプリケーションＡ１２０ａの移行元データ転送負荷２１０をホストＢ１１０ｂに移行時またはホストＣ１１０ｃに移行時の換算後データ転送負荷２１１および２１２を予測する。データ負荷換算処理Ｓ２０１の詳細なステップは、図１１に示す。
【００２７】
次に、管理サーバ１００は、データ負荷換算処理Ｓ２０１による予測に基づいて、ＳＡＮ上の各リソースにおけるボトルネック解析処理Ｓ２０２を行う。ＳＡＮ上の各リソースとはＣＨＡポート１３１ａ〜１３１ｄ、ＨＢＡポート１１３ａ〜１１３ｅがある。ボトルネック解析処理Ｓ２０２の詳細なステップは、図１３に示す。
【００２８】
最後に、管理サーバ１００では、ボトルネック解析処理Ｓ２０２の結果に基づいて、アプリケーションＡ１２０ａの移行先ホスト決定処理Ｓ２０３を行い、ボトルネックが発生しないホストに移行先を決定する。決定した移行先をホストＡ１１０ａに通知することで、アプリケーションＡ１２０ａの移行を行う。ユーザによる事前評価の場合は、移行先ホストとその他の評価内容とともに結果レポートとして出力する。移行先ホスト決定処理Ｓ２０３の詳細なステップは、図１０に示す。
【００２９】
図３は、管理サーバの構成を示すブロック図である。管理サーバ１００は、表示装置３０１、入力装置３０２、中央演算処理装置（ＣＰＵ）３０３、通信制御装置３０４、外部記憶装置３０５、メモリ３０６、およびこれらを接続するバス３０７から構成される。表示装置３０１は、ディスプレイなどであり、管理サーバ１００による処理の実行状況や実行結果などを表示する。入力装置３０２は、キーボードやマウスなどのコンピュータに指示を入力するための装置であり、プログラム起動などの指示を入力する。中央演算処理装置（ＣＰＵ）３０３は、メモリ３０６に格納される各種プログラムを実行する。通信制御装置３０４は、ＬＡＮ１４１を介して、他の装置と各種データやコマンドを交換する。外部記憶装置３０５は、管理サーバ１００が処理を実行するための各種データを保存する。メモリ３０６は、管理サーバ１００が処理を実行する各種プログラムおよび一時的なデータを保持する。
【００３０】
外部記憶装置３０５には、経路別負荷テーブル３２０、ボリューム利用比率テーブル３２１、換算レートテーブル３２２、性能上限値テーブル３２３、アプリケーション優先度テーブル３２４が格納される。
【００３１】
メモリ３０６には、パス情報集約プログラム３１０、移行先ホスト決定プログラム３１１、データ負荷換算プログラム３１２、ボトルネック解析プログラム３１３が格納される。
【００３２】
パス情報集約プログラム３１０は、パス情報集約処理Ｓ２００を実行するプログラムであり、通信制御装置３０４を介して取得した各ホストの性能情報を集約し、経路別負荷テーブル３２０に格納する。
【００３３】
データ負荷換算プログラム３１２は、経路別負荷テーブル３２０、ボリューム利用比率テーブル３２１、換算レートテーブル３２２を用いて、データ負荷換算処理Ｓ２０１を行う。
【００３４】
ボトルネック解析プログラム３１３は、換算した結果と性能上限値テーブル３２３を用いてボトルネック解析処理Ｓ２０２を行う。
【００３５】
移行先ホスト決定プログラム３１１は、データ負荷換算プログラム３１２を実行して負荷換算を行ない、換算結果を入力としてボトルネック解析プログラム３１３を実行する。ボトルネックの解析結果とアプリケーション優先度テーブル３２４に基づいて、移行先ホスト決定処理Ｓ２０３を行う。
【００３６】
図４は、経路別負荷テーブルの一例を示す説明図である。図４に示す経路別負荷テーブル３２０には、経路情報として、ＨＢＡ４０１、ＣＨＡ４０２、ボリューム４０３の組を持ち、その論理経路毎にデータ転送量４０４を格納する。ＨＢＡ４０１は、ＨＢＡポートを識別する情報であり、そのＨＢＡポートのＷＷＮ（World Wide Name）若しくはホスト名とポート番号の組などである。ＣＨＡ４０２は、ＣＨＡポートを識別する情報であり、そのＣＨＡポートのＷＷＮやストレージ名とポート番号の組などである。ボリューム４０３は、ボリュームの識別子であり、ストレージ名とボリューム番号の組であらわす。本実施の形態では、これらを図１、図２で用いた番号で表す。
【００３７】
図４に示すように、データ転送負荷の値としては、秒間のデータ転送量を用いた。データ転送負荷としては、Ｉ／Ｏリクエストの発行回数などでもよい。また、記録されているデータは、平常運用時の稼動実績を平均したデータとなる。本実施の形態では、各ホスト１１０ａ〜１１０ｃのパス管理プログラム１１２ａ〜１１２ｃで、短期的な平均値を計算しているものとする。一方、管理サーバ１００に時系列毎の性能情報を蓄積し、中長期的な平均値を計算してこれを用いることもできる。本発明では、データ負荷情報の種別および負荷情報における平均値の取り方については問わない。
【００３８】
具体例として、ボリューム１３２ａに対する経路別負荷を４１０に示す。当該経路は４つであり、経路毎に８０ＭＢ／ｓのデータ転送量である。また、本テーブルには実際にアクセスしていないボリュームに対する情報も含まれる。４１１は、ホストＡ１１０ａからボリューム１３２ｂに対する経路であり、当該経路は４つであり、経路毎にデータ転送量は１００ＭＢ／ｓである。４１２は、ホストＡ１１０ａからボリューム１３２ｃに対する経路であり、この場合のデータ転送量は０ＭＢ／ｓである。４１３は、ホストＢ１１０ｂからボリューム１３２ｃに対する経路であり、当該経路は３つであり、経路毎にデータ転送量は８０ＭＢ／ｓである。４１４は、ホストＣ１１０ｃからボリューム１３２ｄに対する経路であり、当該経路は４つであり、経路毎にデータ転送量は１２０ＭＢ／ｓである。なお、アクセスしていないボリュームへのデータは仮想的な値として入力してもよい。しかし、アプリケーションに障害発生時に、他のホストに移行させるような状況では、フェイルオーバに要する時間は短くすべきである。このためにＳＡＮに対するセキュリティ設定や各ホスト上でデバイスを認識させることは平常時に行い、論理経路は設定済みとすべきである。論理経路が設定済みであれば、各ホストのパス管理ソフトは通常の論理経路と同様にデータ転送量０ＭＢ／ｓの経路として認識し、管理サーバに情報を送ることができる。
【００３９】
本具体例では、データ転送量０ＭＢ／ｓのデータを一部省略するが、４つのボリューム１３２ａ〜１３２ｄについて計１１本の論理経路が存在するため、実際の行数は４４行となる。
【００４０】
図５は、ボリューム利用比率テーブルの一例を示す説明図である。ボリューム利用比率テーブル３２１には、ボリューム５０１のデータ転送負荷に対するアプリケーション５０２毎の使用割合５０３が示されている。本実施の形態の場合、ボリューム１３２ｂに対するデータ転送負荷を表す２行（５１０）のうちアプリケーションＡ（Ａｐｐ．Ａ）１２０ａが０．２、アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂが０．８の割合で使用している。ファイルシステムを介してアクセスしているような場合にはこのようなケースが発生する。一方、ボリューム１３２ａ、１３２ｃ、および１３２ｄは、使用するアプリケーションが限定されている。この場合はアプリケーションの使用割合が１．０となる。
【００４１】
図６は、換算レートテーブルの一例を示す説明図である。換算レートテーブル３２２には、ホスト６０１に対するデータ転送負荷の換算レート６０２が設定される。ホスト６０１には、ホストＡ（Ｈｏｓｔ．Ａ）１１０ａ、ホストＢ（Ｈｏｓｔ．Ｂ）１１０ｂ、およびホストＣ（Ｈｏｓｔ．Ｃ）１１０ｃがある。同一のアプリケーションを実行した場合でも高性能なホスト上ではより多くの処理を行ない、結果としてより多くのＩ／Ｏリクエストを行う場合がある。本換算レート６０２は、前記のような状況を換算による予測値に取り込むためのものである。例えば、ホストＡ（Ｈｏｓｔ．Ａ）１１０ａのレートが１．２であるのに対し、ホストＣ（Ｈｏｓｔ．Ｃ）１１０ｃのレートは１．５である。これは、ホストＡ１１０ａのアプリケーションをホストＣ１１０ｃで実行した場合、１．５／１．２＝１．２５倍の性能負荷に換算することを表す。
【００４２】
図７は、性能上限値テーブルの一例を示す説明図である。性能上限値テーブル３２３には、リソース７０１毎にデータ転送負荷の上限値（上限転送量）７０２を保持する。本実施の形態では、リソースとしてＨＢＡポート１１３ａ〜１１３ｅおよびＣＨＡポート１３１ａ〜１３１ｄを考慮する。例えば、１１３ｃが許容できる上限のデータ転送量は４００ＭＢ／ｓである。
【００４３】
図８は、アプリケーション優先度テーブルの一例を示す説明図である。アプリケーション優先度テーブル３２４には、アプリケーション８０１に対する優先順位８０２と停止可否８０３を保持する。例えば、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａは、優先順位１であり、最優先のアプリケーションであり、停止不可のアプリケーションである。アプリケーションＢ（Ａｐｐ．Ｂ）１２０ｂは、優先順位１０であり、停止可のアプリケーションである。
【００４４】
次に動作について、図１〜図３を参照しつつ、主に図９、図１０、図１１、および図１３に沿って説明する。
【００４５】
図９は、パス情報集約処理の処理過程を示すフローチャートである。図９には、図２に示すパス情報集約処理Ｓ２００のフローチャートが示されている。パス情報集約処理Ｓ２００は、パス情報集約プログラム３１０に基づき、各ホスト１１０ａ〜１１０ｃ上のパス管理プログラム（パス管理ソフト）１１２ａ〜１１２ｃにより、論理パス毎のデータ転送負荷を集約するものである。中央演算処理装置（ＣＰＵ）３０３は、一定時間毎にパス情報集約を繰り返す（ステップＳ９０１）。一定時間毎にパス情報集約を繰り返すことにより、最新のパス情報を得ることができる。中央演算処理装置３０３は、管理サーバ１００が管理する全てのホスト１１０ａ〜１１０ｃに対してパス情報集約を繰り返す（ステップＳ９０２）。パス情報集約プログラム３１０に基づいて、中央演算処理装置３０３は、各ホスト上のパス管理プログラム１１２ａ〜１１２ｃに対して通信を行ない、経路毎のデータ転送量を取得し（ステップＳ９０３）、収集したデータ転送負荷を、図４に示される経路別負荷テーブル３２０に格納する（ステップＳ９０４）。
【００４６】
図１０は、第１の実施の形態における移行先ホスト決定処理の処理過程を示すフローチャートである。図１０には、図２に示す移行先ホスト決定処理Ｓ２０３のフローチャートが示されている。移行先ホスト決定処理Ｓ２０３は、移行先ホスト決定プログラム３１１に基づき、データ負荷換算プログラム３１２およびボトルネック解析プログラム３１３を実行する。具体例と共に各ステップを説明する。
【００４７】
中央演算処理装置（ＣＰＵ）３０３は、クラスタ管理プログラム１１１ａ〜１１１ｃから障害が発生したアプリケーションについて通知を受け取る。本通知により、移行すべきアプリケーションが選択される。本例では、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａに障害が発生し、クラスタ管理プログラム１１１ａによって通知されたものとする（ステップＳ１００１）。中央演算処理装置３０３は、全ての移行先の候補ホストについて、以降のステップＳ２０１、Ｓ２０２を行う。本実施の形態の場合、候補ホストはホストＢ１１０ｂおよびホストＣ１１０ｃである（ステップＳ１００２）。
【００４８】
中央演算処理装置３０３は、データ負荷換算プログラム３１２に基づき、データ負荷換算を行う。入力は、障害が発生したアプリケーションと移行先候補のホストであり、出力は、候補ホストに対する換算後のデータ転送負荷である（ステップＳ２０１）。中央演算処理装置３０３は、ボトルネック解析プログラム３１３に基づき、通信経路のボトルネック解析を行う。入力は、データ負荷換算プログラム３１２により出力した換算後のデータ転送負荷、出力は、ボトルネックの有無である（ステップＳ２０２）。ステップＳ２０１、ステップＳ２０２において、ホストＢ１１０ｂに移行した場合の換算後データ負荷とボトルネック解析経過をそれぞれ図１２、図１４に示す。
【００４９】
図１２は、ホストＢに移行した場合の換算後データ負荷情報を示す説明図である。図１２に示すデータ負荷情報１２００には、図４と同様に、経路情報として、ＨＢＡ１２０１、ＣＨＡ１２０２、ボリューム１２０３の組を持ち、その論理経路毎にデータ転送量１２０４を格納する。
【００５０】
図１４は、ホストＢに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１４００には、リソース１４０１毎にデータ転送負荷の上限Ｉ／Ｏ量１４０２、および予測Ｉ／Ｏ量１４０３を保持する。
【００５１】
また、ホストＣ１１０ｃに移行した場合の換算後データ負荷とボトルネック解析経過をそれぞれ図１５、図１６に示す。
【００５２】
図１５は、ホストＣに移行した場合の換算後データ負荷情報を示す説明図である。図１５に示すデータ負荷情報１５００には、図４と同様に、経路情報として、ＨＢＡ１５０１、ＣＨＡ１５０２、ボリューム１５０３の組を持ち、その論理経路毎にデータ転送量１５０４を格納する。
【００５３】
図１６は、ホストＣに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１６００には、リソース１６０１毎にデータ転送負荷の上限Ｉ／Ｏ量１６０２、および予測Ｉ／Ｏ量１６０３を保持する。
【００５４】
中央演算処理装置３０３は、ボトルネックの発生有無を確認する（ステップＳ１００３）。もし、全ての移行先の候補ホストについてボトルネックが発生する場合、ステップＳ１００４に進む。本具体例の場合、ホストＢ１１０ｂに移行すると図１４に示すようにＨＢＡポート１１３ｃにボトルネックが発生する。すなわち、ＨＢＡポート１１３ｃにおいて、予測Ｉ／Ｏ量１４１３は、５４０ＭＢ／ｓであり、上限Ｉ／Ｏ量４００ＭＢ／ｓを超える。また、ホストＣ１１０ｃに移行すると図１６に示すようにＣＨＡポート１３１ｃおよび１３１ｄにボトルネックが発生する。すなわち、ＣＨＡポート１３１ｃおよび１３１ｄにおいて、予測Ｉ／Ｏ量１６１１および１６１２は、５７０ＭＢ／ｓであり、上限Ｉ／Ｏ量５００ＭＢ／ｓを超える。ステップＳ１００３でボトルネックの発生しない候補ホストがある場合、ステップＳ１００６に進む。
【００５５】
ステップＳ１００４において、中央演算処理装置３０３は、アプリケーション優先度テーブル３２４（図８参照）から障害発生アプリケーションよりも優先度が低く、かつ、停止可能なアプリケーションを取得する。本具体例の場合、アプリケーションＡ（Ａｐｐ．Ａ）より優先度の低く、かつ、停止可能なアプリケーションは、アプリケーションＢ（Ａｐｐ．Ｂ）、アプリケーションＣ（Ａｐｐ．Ｃ）、およびアプリケーションＤ（Ａｐｐ．Ｄ）である。このうち、より優先度の低いアプリケーションＣ（Ａｐｐ．Ｃ）を選択する。なお、条件を満たすアプリケーション全てについてデータ負荷換算を行ない、換算後にＳＡＮ上のリソースに対するデータ転送負荷の偏りが最も少ないアプリケーションを停止予定アプリケーションとして選択してもよい。
【００５６】
ステップＳ１００５において、中央演算処理装置３０３は、停止予定アプリケーションのデータ転送負荷を経路別負荷テーブル３２０から減算し、アプリケーション停止後のデータ負荷を予測する。このデータ負荷に基づいて、再度データ負荷の換算とボトルネック解析を行う（ステップＳ１００２、ステップＳ２０１、およびステップＳ２０２）。本具体例では、アプリケーションＣ（Ａｐｐ．Ｃ）のデータ負荷を減算する。
【００５７】
アプリケーションＣ（Ａｐｐ．Ｃ）を停止した場合において、ホストＢに移行した場合のボトルネック解析経過を図１７に示す。アプリケーションＣ（Ａｐｐ．Ｃ）を停止する前のホストＢに移行した場合のボトルネック解析経過である図１４に比べて、ＨＢＡポート１１３ｃのボトルネックが解消されている。すなわち、ＨＢＡポート１１３ｃの予測Ｉ／Ｏ量１７１１は、３００ＭＢ／ｓであり、上限Ｉ／Ｏ量４００ＭＢ／ｓ以内となっている。アプリケーションＣ（Ａｐｐ．Ｃ）を停止した場合において、ホストＣに移行した場合のボトルネック解析経過を図１８に示す。アプリケーションＣ（Ａｐｐ．Ｃ）を停止する前のホストＣに移行した場合のボトルネック解析経過である図１６に比べて、ＣＨＡポート１３１ｃ、１３１ｄのボトルネックが解消されている。すなわち、ＣＨＡポート１３１ｃおよび１３１ｄにおいて、予測Ｉ／Ｏ量１８１１および１８１２は、４９０ＭＢ／ｓであり、上限Ｉ／Ｏ量５００ＭＢ／ｓ以内となっている。ステップＳ１００３において、全ての候補ホストでボトルネックが発生しない場合、ステップＳ１００６に進む。
【００５８】
ステップＳ１００６において、中央演算処理装置３０３は、停止予定アプリケーションが存在した場合に、停止予定アプリケーションが稼動中の該当ホストに停止の通知をし、実際に停止を行う。停止予定アプリケーションとは、ステップＳ１００４にて選択したアプリケーションである。該当ホストの制御部は、クラスタ管理プログラムに基づき、当該アプリケーションの停止を行う。本具体例では、ホストＢに対して、アプリケーションＣ（Ａｐｐ．Ｃ）が停止として通知される。なお、実際の停止をステップＳ１００５で行わない理由は、停止可能なアプリケーションを全て停止しても、ボトルネックが解消しない場合が考えられるからである。
【００５９】
ステップＳ１００７において、中央演算処理装置３０３は、ボトルネックが発生しない候補ホストの中から移行先ホストを決定し、移行先ホストの制御部に通知する。条件を満たすホストが複数ある場合には、例えば各リソースにかかるデータ負荷の偏りが最も少ないホストを移行先とする。本具体例の場合、アプリケーションＣ（Ａｐｐ．Ｃ）の停止後にホストＢに移行した場合を図１７に、アプリケーションＣ（Ａｐｐ．Ｃ）の停止後にホストＣに移行した場合を図１８に示す。どちらの場合もボトルネックは発生しない。この場合、各リソースにかかるデータ負荷の標準偏差は、ホストＢに移行した場合６９であり、ホストＣに移行した場合１８６である。よって偏りの少ないホストＢを移行先として決定する。
【００６０】
なお、例えば、移行後の性能が最も高くなるように、例えばデータ転送量の平均が大きいものを選んでもよい。本具体例の場合、ホストＢに移行すると２４４ＭＢ／ｓ、ホストＣに移行すると２８９ＭＢ／ｓであり、ホストＣを移行先として選択する。いずれの場合も、移行先として決定したホストの制御部に通知し、アプリケーションの移行を行う。
【００６１】
図１１は、データ負荷換算処理の処理過程を示すフローチャートである。図１１には、図２に示すデータ負荷換算処理Ｓ２０１のフローチャートが示されている。データ負荷換算処理Ｓ２０１は、データ負荷換算プログラム３１２に基づき、アプリケーションを移行する際に移行元ホストで選択された移行元アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストでの移行元アプリケーションに対するデータ転送負荷に換算する。移行先ホスト決定プログラム３１１から、移行するアプリケーションと移行先の候補ホストを入力として呼び出される。以下では、具体例として、アプリケーションＡ（Ａｐｐ．Ａ）１２０ａをホストＢ１１０ｂに移行する場合について示す。
【００６２】
中央演算処理装置（ＣＰＵ）３０３は、ボリューム利用比率テーブル３２１から入力アプリケーションに対応するボリュームの情報を取得する。本具体例では、入力アプリケーションがアプリケーションＡ（Ａｐｐ．Ａ）であり、対応するボリュームがボリューム１３２ａおよび１３２ｂである（ステップＳ１１０１）。中央演算処理装置３０３は、経路別負荷テーブル３２０（図４参照）から、ステップＳ１１０１で特定したボリュームに対応する行を抽出する。本具体例の場合、４１０および４１１の行を抽出する（ステップＳ１１０２）。中央演算処理装置３０３は、抽出したデータ転送量をボリューム毎に合計する。本具体例では、ボリューム１３２ａに対応するデータ転送量が３２０ＭＢ／ｓ、１３２ｂに対応するデータ転送量が４００ＭＢ／ｓである（ステップＳ１１０３）。
【００６３】
中央演算処理装置３０３は、ステップＳ１１０３で算出した値にボリューム利用比率テーブル３２１（図５参照）の利用比率（使用割合）を乗算し、入力アプリケーションによるボリューム毎のデータ転送量を計算する。ボリューム１３２ａに対応するデータ転送量は１．０をかけて３２０ＭＢ／ｓ、ボリューム１３２ｂに対応するデータ転送量は０．２をかけて８０ＭＢ／ｓである（ステップＳ１１０４）。中央演算処理装置３０３は、換算レートテーブル３２２（図６参照）から候補ホストに対するレートを取得し、ステップＳ１１０４で求めた値に乗算する。本具体例では、０．９／１．２＝０．７５である。よって、ボリューム１３２ａに対応するデータ転送量は３２０×０．７５＝２４０、ボリューム１３２ｂに対応するデータ転送量は８０×０．７５＝６０に換算される（ステップＳ１１０５）。中央演算処理装置３０３は、候補ホストから移行するアプリケーションが利用するボリュームまでの経路を選択する。本具体例では、図１２に示した１２１１および１２１２が相当する。なお、この時点では、１２１１、および１２１２のデータ転送量は０である（ステップＳ１１０６）。
【００６４】
中央演算処理装置３０３は、ステップＳ１１０５で求めた値をステップＳ１１０６で選択したパスに均等に分配して加算する。本具体例では、ボリューム１３２ａに対する経路１２１１に、ステップＳ１１０６で求めたデータ転送量２４０ＭＢ／ｓを加える。経路１２１１は３経路なので、ボリューム１３２ａに対する各経路のデータ転送量は８０ＭＢ／ｓに分配する。同様にボリューム１３２ｂに対応して、経路１２１２に２０ＭＢ／ｓずつ分配する（ステップＳ１１０７）。中央演算処理装置３０３は、出力として換算後のデータ転送負荷を出力する。ホストＢ移行時の換算データ負荷情報１２００（図１２参照）は、換算後のデータ負荷情報である。但し、データ転送量が０ＭＢ／ｓの行は省略している（ステップＳ１１０８）。
【００６５】
図１３は、ボトルネック解析処理の処理過程を示すフローチャートである。図１３には、図２に示すボトルネック解析処理Ｓ２０２のフローチャートが示されている。ボトルネック解析処理Ｓ２０２は、ボトルネック解析プログラム３１３に基づき、データ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネックの解析を行う。移行先ホスト決定プログラム３１１から、換算後のデータ転送負荷を入力として呼び出される。具体例では、前記換算後のデータ負荷情報１２００を入力として示す。
【００６６】
中央演算処理装置（ＣＰＵ）３０３は、以降のステップをＳＡＮ上の各リソースに対して繰り返す。本実施例では、ＨＢＡポート１１３ａ〜１１３ｅおよびＣＨＡポート１３１ａ〜１３１ｄである（ステップＳ１３０１）。中央演算処理装置３０３は、換算後のデータ転送負荷を当該リソースについて集約する。本具体例では、ＨＢＡポート１１３ａについて集約した値は１６０ＭＢ／ｓとなる。ステップＳ１３０１の全てのリソースについて集約した結果を図１４のホストＢ移行時のボトルネック解析経過１４００に示す。各リソース１４０１に対応する集約値は、予測Ｉ／Ｏ量１４０３である（ステップＳ１３０２）。中央演算処理装置３０３は、性能上限値テーブル３２３から当該リソースと対応する上限値（上限Ｉ／Ｏ量）を取得する。具体例では、ＨＢＡポート１１３ａに対応する上限のデータ転送量は５００ＭＢ／ｓである。図１４では、分かりやすさのために性能上限値テーブル３２３から取得した上限値（上限Ｉ／Ｏ量）１４０２を合わせて示す（ステップＳ１３０３）。中央演算処理装置３０３は、集約後のデータ転送負荷がリソースの上限負荷を超えるかどうかを確認する。上限を超える場合にはステップＳ１３０５に移る。本具体例では、リソースのＨＢＡポート１１３ｃの集約値（予測Ｉ／Ｏ量）１４１３が上限値である４００ＭＢ／ｓを超える（ステップＳ１３０４）。中央演算処理装置３０３は、出力としてボトルネックの発生有無を呼び出し元プログラムに伝える（ステップＳ１３０５）。以上、アプリケーションＡ（Ａｐｐ．Ａ）をホストＢに移行する場合について説明した。
【００６７】
一方、アプリケーションＡ（Ａｐｐ．Ａ）をホストＣに移行する場合は以下のようになる。まず、データ負荷換算プログラム３１２による換算は以下のようになる。ステップＳ１１０６では、１．５／１．２＝１．２５となる。よって、ボリューム１３２ａに対応する転送量は３２０×１．２５＝４００ＭＢ／ｓ、ボリューム１３２ｂに対応する転送量は８０×１．２５＝１００ＭＢ／ｓである。ステップＳ１１０７では、図１５に示した１５１１および１５１２が相当する。ステップＳ１１０８では、換算後の経路は４つなので、ボリューム１３２ａに対する各経路のデータ転送量は１００ＭＢ／ｓとなる。同様にボリューム１３２ｂに対応して、１５１２の各経路のデータ転送量は２５ＭＢ／ｓとなる。ステップＳ１１０８で出力される換算後のデータ転送負荷を、ホストＣ移行時の換算後データ負荷情報１５００（図１５参照）に示す。
【００６８】
次に、図１６に示すように、ホストＣ移行時のボトルネック解析経過１６００には、ＣＨＡポート１３１ｃおよび１３１ｄに対する集約結果１６１１および１６１２が共に５７０ＭＢ／ｓとなり、ボトルネックが発生する。
【００６９】
図１７は、アプリケーションＣを停止し、かつ、ホストＢに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１７００には、リソース１７０１毎にデータ転送負荷の上限Ｉ／Ｏ量１７０２、および予測Ｉ／Ｏ量１７０３を保持する。中央演算処理装置３０３（図３参照）は、ステップＳ１００４（図１０参照）において、アプリケーション優先度テーブル３２４から低優先度で停止可能なアプリケーションを取得し、ステップＳ１００５（図１０参照）において、停止予定アプリケーションのデータ負荷をデータ負荷から減算している。アプリケーションＣ（Ａｐｐ．Ｃ）を停止すると、図１２の１２１０に示す経路に対するデータ転送量が０となる。ステップＳ２０２におけるボトルネック解析の結果、ＨＢＡポート１１３ｃに対する集約結果である予測Ｉ／Ｏ値１７１１は、３００ＭＢ／ｓであり、上限Ｉ／Ｏ値４００ＭＢ／ｓを超えていない。また、その他のリソースにおいても、予測Ｉ／Ｏ値は、上限Ｉ／Ｏ値以内でありボトルネックは発生しない。
【００７０】
図１８は、アプリケーションＣを停止し、かつ、ホストＣに移行した場合のボトルネック解析経過を示す説明図である。ボトルネック解析経過１８００には、リソース１８０１毎にデータ転送負荷の上限Ｉ／Ｏ量１８０２、および予測Ｉ／Ｏ量１８０３を保持する。アプリケーションＣ（Ａｐｐ．Ｃ）を停止すると、図１５の１５１０に示す経路に対するデータ転送量が０となる。ステップＳ２０２におけるボトルネック解析の結果、ＣＨＡポート１３１ｃおよび１３１ｄの集約結果である予測Ｉ／Ｏ値１８１１および１８１２は、いずれも４９０ＭＢ／ｓであり、上限Ｉ／Ｏ値５００ＭＢ／ｓを超えていない。また、その他のリソースにおいても、予測Ｉ／Ｏ値は、上限Ｉ／Ｏ値以内でありボトルネックは発生しない。
【００７１】
図１９は、アプリケーション移行情報ログの一例を示す説明図である。アプリケーション移行に関する情報は，動作履歴として管理サーバ１００の表示装置３０１に表示されてもよい。表示される情報は、移行したアプリケーション、移行元の業務サーバ、移行先の業務サーバ、優先度に基づいて停止したアプリケーションである。また、より詳細な情報としてボトルネックの発生予測を表示する。図１９には、アプリケーションＡをホストＡから他のホストへ移行する移行情報が示されている。具体的には、ホストＢへ移行する場合にボトルネックが発生する可能性があること、ホストＣへ移行する場合にボトルネックが発生する可能性があることが表示されている。このため、優先度定義（例えば、アプリケーション優先度テーブル３２４）に基づいて、アプリケーションＣを停止し、移行先ホストとして、ホストＢが決定されたことが表示されている。
【００７２】
本実施の形態では、ホストを管理する管理サーバ１００が、障害が発生しているホストからアプリケーションの障害通知を受け取ると、障害が生じたアプリケーションの移行先の候補となる各ホストに対して、アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストで運用したときのデータ転送負荷に換算するデータ負荷換算とデータ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネック解析とを行い、前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生したときは、アプリケーション優先度テーブルから障害が生じたアプリケーションよりも低優先度で停止可能なアプリケーションを取得して停止予定アプリケーションを決定し、停止予定アプリケーションを停止した条件で、障害が生じたアプリケーションの移行先の候補となる各ホストに対して、前記データ負荷換算と前記ボトルネック解析とを行い、前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生しないときは、停止予定アプリケーションがあれば停止を指示し、候補ホストから移行先ホストを決定し、障害が発生しているホストへ移行を指示する。これにより、アプリケーションを現在稼動中のホストと異なるホストに移行する場合に、データ転送負荷の影響を極力受けないように、アプリケーションの移行すべきホストを決定することができる。
【００７３】
《第２の実施の形態》
図２０は、第２の実施の形態における移行先ホスト決定ステップの処理過程を示すフローチャートである。本実施の形態は、第１の実施の形態とシステム構成は同じであるが、移行先ホスト決定プログラム３１１の処理手順が異なる。まず、障害通知を受け取った移行元アプリケーションより低優先度のアプリケーションを停止し、移行元アプリケーションの移行を完了する。その後、停止した低優先度のアプリケーションを第１の実施の形態に従って移行する。これにより、高優先度の移行元アプリケーションの移行に掛かる時間を短くすると共に、移行元アプリケーションが受けるデータ転送負荷の影響を少なくすることが出来る。
【００７４】
中央演算処理装置（ＣＰＵ）３０３は、移行先ホスト決定プログラム３１１に基づき実行する。ホストＡ、ホストＢ、およびホストＣの各制御部は、クラスタ管理プログラム１１１ａ〜１１１ｃに基づき実行する。具体例と共に各ステップの動作について説明する。
【００７５】
ステップＳ１００１は、図１０のステップＳ１００１と同じである。中央演算処理装置３０３は、アプリケーション優先度テーブル３２４から移行元アプリケーションよりも低優先度で、かつ、停止可能な全てのアプリケーションの情報を取得する。本具体例の場合、アプリケーションＡ（Ａｐｐ．Ａ）よりも優先度が低く、かつ、停止可能なアプリケーションとして、アプリケーションＢ（Ａｐｐ．Ｂ）、アプリケーションＣ（Ａｐｐ．Ｃ）、アプリケーションＤ（Ａｐｐ．Ｄ）が取得される（ステップＳ１９０１）。中央演算処理装置３０３は、取得した全ての停止可能アプリケーションに対して、停止指示を行う。すなわち、中央演算処理装置３０３は、停止可能アプリケーションの停止要求を、当該アプリケーションが動作する各ホストに送信する。本具体例の場合、ホストＡ、ホストＢ、およびホストＣに通知する（ステップＳ１９０２）。中央演算処理装置３０３は、ステップＳ１９０２で通知した停止指示に最も早くレスポンスを返したホストを移行先ホストに決定する。これは、稼動状態の確認となりアプリケーションの移行時間を削減できるためである。中央演算処理装置３０３は、決定したホストの制御部に通知し、アプリケーションの移行を行う。具体例としては、ホストＣの制御部が、中央演算処理装置３０３に最も早くレスポンスを返したものとする。中央演算処理装置３０３は、ホストＣの制御部に通知し、アプリケーションＡ（Ａｐｐ．Ａ）を移行する（ステップＳ１９０３）。中央演算処理装置３０３は、アプリケーションＡ（Ａｐｐ．Ａ）移行後のデータ転送負荷を、パス情報集約プログラム３１０が取得するまで待ち合わせる。アプリケーションＡ（Ａｐｐ．Ａ）の移行によるデータ転送負荷の変化を反映するためである（ステップＳ１９０４）。中央演算処理装置３０３は、ステップＳ１９０２にて停止した全てのアプリケーションについて優先度順に以下のステップを繰り返す。本具体例の場合、アプリケーションＤ（Ａｐｐ．Ｄ）、アプリケーションＢ（Ａｐｐ．Ｂ）、アプリケーションＣ（Ａｐｐ．Ｃ）の順に処理を行う（ステップＳ１９０５）。
【００７６】
ステップＳ１００２、Ｓ２０１、およびＳ２０２は、第１の実施の形態と同じであり、中央演算処理装置３０３は、停止したアプリケーションについて、データ負荷換算ステップＳ２０１とボトルネック解析ステップＳ２０２を行う。中央演算処理装置３０３は、ボトルネック解析の結果、全ての候補ホストでボトルネックが発生する場合に処理を終了する。停止可能なホストが全て停止しており、これ以上ボトルネックを改善できる見込みがないためである（ステップＳ１９０６）。ステップＳ１００７は、第１の実施の形態と同じであり、中央演算処理装置３０３は、ボトルネックが発生しない候補ホストの中から移行先ホストを決定し、移行先ホストの制御部に通知する。条件を満たすホストが複数ある場合には、例えば各リソースにかかるデータ負荷の偏りが最も少ないホストを移行先とする。
【００７７】
本実施の形態では、ホストを管理する管理サーバ１００が、アプリケーションを移行する際に、アプリケーションの優先度が移行元ホストで選択された移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する停止可能アプリケーションを決定するステップ（ステップＳ１９０１）と、決定された停止可能アプリケーションが動作するホストに対して停止指示を行うステップ（ステップＳ１９０２）と、前記停止指示に最も早くレスポンスを返したホストを移行先ホストに決定し、決定した移行先ホストに対し前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストに選択されたアプリケーションの移行指示を行うアプリケーション移行ステップ（ステップＳ１９０３）とを含んで実行する。これにより、アプリケーションを現在稼動中のホストと異なるホストに移行する場合に、データ転送負荷の影響を極力受けないように、アプリケーションの移行すべきホストを決定することができる。
【００７８】
以上述べた実施の形態においては、ＳＡＮ上のリソースとして、ＣＨＡポート１３１ａ〜１３１ｄ、ＨＢＡポート１１３ａ〜１１３ｅとして説明した。しかし、リソースとしては、必ずしもこのＣＨＡポート１３１ａ〜１３１ｄ、ＨＢＡポート１１３ａ〜１１３ｅに限らない。例えば、ＦＣネットワーク１４０を構築するファイバチャネルスイッチをリソースとしてもよい。この場合、図４の経路別負荷テーブル３２０に、ファイバチャネルスイッチを合わせて収集し格納すると、ボトルネック解析処理Ｓ２０２において、ファイバチャネルスイッチに対してもデータ転送負荷を集約することができ、ポートのボトルネック以外に、ＦＣネットワーク１４０に関してのボトルネックについても評価することができる。
【００７９】
また、以上述べた実施の形態においては、アプリケーションを移行する際の契機は、アプリケーションの障害を検知した場合、ＨＢＡおよびＣＨＡを通る論理経路パスに障害を検知した場合、ユーザが事前評価のためにアプリケーションの移行を指定した場合として説明したが、必ずしもこのような場合に限らない。例えば、アプリケーションの障害、パスの障害ではないが、ユーザが特定のホストに集中したため、サーバ管理者がユーザに満足な応答時間でアプリケーションのサービスを提供できないと判断した場合に、アプリケーションを移行する際の契機としてもよい。
【産業上の利用可能性】
【００８０】
本発明は、データ転送負荷の影響を極力受けないように、アプリケーションを移行すべきホストを決定する用途に適用でき、例えば、クラスタシステムによりアプリケーションの移行を行う際のＳＡＮ管理方法およびＳＡＮ管理システムの用途に適用できる。
【図面の簡単な説明】
【００８１】
【図１】本発明の全体構成を示すブロック図である。
【図２】本発明の骨子を示す概念図である。
【図３】管理サーバの構成を示すブロック図である。
【図４】経路別負荷テーブルの一例を示す説明図である。
【図５】ボリューム利用比率テーブルの一例を示す説明図である。
【図６】換算レートテーブルの一例を示す説明図である。
【図７】性能上限値テーブルの一例を示す説明図である。
【図８】アプリケーション優先度テーブルの一例を示す説明図である。
【図９】パス情報集約処理の処理過程を示すフローチャートである。
【図１０】第１の実施の形態における移行先ホスト決定処理の処理過程を示すフローチャートである。
【図１１】データ負荷換算処理の処理過程を示すフローチャートである。
【図１２】ホストＢに移行した場合の換算後データ負荷情報を示す説明図である。
【図１３】ボトルネック解析処理の処理過程を示すフローチャートである。
【図１４】ホストＢに移行した場合のボトルネック解析経過を示す説明図である。
【図１５】ホストＣに移行した場合の換算後データ負荷情報を示す説明図である。
【図１６】ホストＣに移行した場合のボトルネック解析経過を示す説明図である。
【図１７】アプリケーションＣを停止し、かつ、ホストＢに移行した場合のボトルネック解析経過を示す説明図である。
【図１８】アプリケーションＣを停止し、かつ、ホストＣに移行した場合のボトルネック解析経過を示す説明図である。
【図１９】アプリケーション移行情報ログの一例を示す説明図である。
【図２０】第２の実施の形態における移行先ホスト決定ステップの処理過程を示すフローチャートである。
【符号の説明】
【００８２】
Ｓ２００ パス情報集約処理
Ｓ２０１ データ負荷換算処理
Ｓ２０２ ボトルネック解析処理
Ｓ２０３ 移行先ホスト決定処理
１００ 管理サーバ
１１０ａ，１１０ｂ，１１０ｃ ホスト
１１１ａ，１１１ｂ，１１１ｃ クラスタ管理プログラム
１１２ａ，１１２ｂ，１１２ｃ パス管理プログラム
１１３ａ，１１３ｂ，１１３ｃ，１１３ｄ，１１３ｅ ＨＢＡポート
１２０ａ，１２０ｂ，１２０ｃ，１２０ｄ アプリケーション・プログラム
１３０ ストレージ
１３１ａ，１３１ｂ，１３１ｃ，１３１ｄ ＣＨＡポート
１３２ａ，１３２ｂ，１３２ｃ，１３２ｄ ボリューム
１４０ ＦＣネットワーク
１４１ ＬＡＮ
２１０ 移行元データ転送負荷
２１１ ホストＢに移行時の換算後データ転送負荷
２１２ ホストＣに移行時の換算後データ転送負荷
２２０ａ，２２０ｂ，２２０ｃ，２２０ｄ デバイス
３０１ 表示装置
３０２ 入力装置
３０３ 中央演算処理装置（ＣＰＵ）
３０４ 通信制御装置
３０５ 外部記憶装置
３０６ メモリ
３０７ バス
３１０ パス情報集約プログラム
３１１ 移行先ホスト決定プログラム
３１２ データ負荷換算プログラム
３１３ ボトルネック解析プログラム
３２０ 経路別負荷テーブル
３２１ ボリューム利用比率テーブル
３２２ 換算レートテーブル
３２３ 性能上限値テーブル
３２４ アプリケーション優先度テーブル
【特許請求の範囲】
【請求項１】
アプリケーションを実行する複数のホストが、ＳＡＮ（Storage Area Network）を介してストレージと、ＬＡＮ（Local Area Network）を介して管理サーバと通信可能にされ、いずれかの前記ホストにていずれかの前記アプリケーションに障害が生じた場合に、前記障害が生じたアプリケーションを他のホストに移行するシステムにおいて、移行先のホストを決定するＳＡＮ管理方法であって、
前記管理サーバは、
前記障害が発生しているホストからアプリケーションの障害通知を受け取ると、
前記障害が生じたアプリケーションの移行先の候補となる各ホストに対して、アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストで運用したときのデータ転送負荷に換算するデータ負荷換算とデータ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネック解析とを行い、
前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生するときは、アプリケーション優先度テーブルから前記障害が生じたアプリケーションよりも低優先度で停止可能なアプリケーションを取得して停止予定アプリケーションを決定し、前記停止予定アプリケーションを停止した条件で、前記障害が生じたアプリケーションの移行先の候補となる各ホストに対して、前記データ負荷換算と前記ボトルネック解析とを行い、
前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生しないときは、停止予定アプリケーションがあれば停止を指示し、候補ホストから移行先ホストを決定し、前記障害が発生しているホストへ移行を指示する
ことを特徴とするＳＡＮ管理方法。
【請求項２】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理方法において、
前記ホストを管理する管理サーバが、
アプリケーションを移行する際に移行元ホストで選択された移行元アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストでの移行元アプリケーションに対するデータ転送負荷に換算するデータ負荷換算ステップと、
データ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネックの解析を行うボトルネック解析ステップと、
移行先の候補ホストについて前記データ負荷換算ステップと前記ボトルネック解析ステップとを実行しボトルネックとならない候補ホストから移行先ホストを決定する移行先ホスト決定ステップと、を含んで実行する
ことを特徴とするＳＡＮ管理方法。
【請求項３】
前記データ負荷換算ステップは、
移行元アプリケーションに対応するボリュームを特定するステップと、
特定したボリュームに対応するデータ転送負荷をボリューム単位に集約するステップと、
集約したデータ転送負荷を移行先ホストの持つ通信経路に均等に分配するステップとを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項４】
前記ボリューム単位に集約するステップは、集約後のデータ転送負荷の値にアプリケーション毎のボリューム利用比率を乗算するステップを有する
ことを特徴とする請求項３に記載のＳＡＮ管理方法。
【請求項５】
前記ボリューム単位に集約するステップは、集約後のデータ転送負荷の値にホスト間の性能差に基づく換算レートを乗算するステップを有する
ことを特徴とする請求項３に記載のＳＡＮ管理方法。
【請求項６】
前記ボトルネック解析ステップは、
換算後のデータ転送負荷をＳＡＮの各リソースについて集約するステップと、
集約したデータ転送負荷の値を各リソースの性能上限値と比較するステップとを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項７】
前記リソースは、通信経路のポートおよびファイバチャネルスイッチの少なくともいずれかを含む
ことを特徴とする請求項６に記載のＳＡＮ管理方法。
【請求項８】
前記移行先ホスト決定ステップは、全ての移行先の候補ホストでボトルネックが発生した場合に停止させるアプリケーションを決定するステップを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項９】
前記停止させるアプリケーションを決定するステップは、アプリケーションの優先度が移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する
ことを特徴とする請求項８に記載のＳＡＮ管理方法。
【請求項１０】
前記移行先ホスト決定ステップは、移行先に決定したホストで選択された前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストにアプリケーションの移行指示を行うステップを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項１１】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理方法において、
前記ホストを管理する管理サーバが、
アプリケーションを移行する際に、アプリケーションの優先度が移行元ホストで選択された移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する停止可能アプリケーションを決定するステップと、
決定された停止可能アプリケーションが動作するホストに対して停止指示を行うステップと、
前記停止指示に最も早くレスポンスを返したホストを移行先ホストに決定し、決定した移行先ホストに対し前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストに選択されたアプリケーションの移行指示を行うアプリケーション移行ステップと、を含んで実行する
ことを特徴とするＳＡＮ管理方法。
【請求項１２】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理システムにおいて、
アプリケーションを移行する際に移行元ホストで選択された移行元アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストでの移行元アプリケーションに対するデータ転送負荷に換算するデータ負荷換算手段と、
データ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネックの解析を行うボトルネック解析手段と、
移行先の候補ホストについて前記データ負荷換算手段と前記ボトルネック解析手段とを実行しボトルネックとならない候補ホストから移行先ホストを決定する移行先ホスト決定手段と、を有する
ことを特徴とするＳＡＮ管理システム。
【請求項１３】
前記データ負荷換算手段は、移行元アプリケーションに対応するボリュームを特定し、
特定したボリュームに対応するデータ転送負荷をボリューム単位に集約し、集約したデータ転送負荷を移行先ホストの持つ通信経路に均等に分配する
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項１４】
前記データ負荷換算手段は、ボリューム単位に集約後のデータ転送負荷の値にアプリケーション毎のボリューム利用比率を乗算する
ことを特徴とする請求項１３に記載のＳＡＮ管理システム。
【請求項１５】
前記データ負荷換算手段は、ボリューム単位に集約後のデータ転送負荷の値にホスト間の性能差に基づく換算レートを乗算する
ことを特徴とする請求項１３に記載のＳＡＮ管理システム。
【請求項１６】
前記ボトルネック解析手段は、換算後のデータ転送負荷をＳＡＮの各リソースについて集約し、集約したデータ転送負荷の値を各リソースの性能上限値と比較する
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項１７】
前記移行先ホスト決定手段は、全ての移行先の候補ホストでボトルネックが発生した場合に停止させるアプリケーションを決定する
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項１８】
前記移行先ホスト決定手段は、前記停止させるアプリケーションを決定する場合に、アプリケーションの優先度が移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する
ことを特徴とする請求項１７に記載のＳＡＮ管理システム。
【請求項１９】
前記移行先ホスト決定手段は、移行先に決定したホストで選択された前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストにアプリケーションの移行指示を行う
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項２０】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理システムにおいて、
アプリケーションを移行する際に、アプリケーションの優先度が移行元ホストで選択された移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する停止可能アプリケーションを決定する手段と、
決定された停止可能アプリケーションが動作するホストに対して停止指示を行う停止指示手段と、
前記停止指示に最も早くレスポンスを返したホストを移行先ホストに決定し、決定した移行先ホストに対し前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストに選択されたアプリケーションの移行指示を行うアプリケーション移行手段と、を有する
ことを特徴とするＳＡＮ管理システム。
【請求項１】
アプリケーションを実行する複数のホストが、ＳＡＮ（Storage Area Network）を介してストレージと、ＬＡＮ（Local Area Network）を介して管理サーバと通信可能にされ、いずれかの前記ホストにていずれかの前記アプリケーションに障害が生じた場合に、前記障害が生じたアプリケーションを他のホストに移行するシステムにおいて、移行先のホストを決定するＳＡＮ管理方法であって、
前記管理サーバは、
前記障害が発生しているホストからアプリケーションの障害通知を受け取ると、
前記障害が生じたアプリケーションの移行先の候補となる各ホストに対して、アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストで運用したときのデータ転送負荷に換算するデータ負荷換算とデータ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネック解析とを行い、
前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生するときは、アプリケーション優先度テーブルから前記障害が生じたアプリケーションよりも低優先度で停止可能なアプリケーションを取得して停止予定アプリケーションを決定し、前記停止予定アプリケーションを停止した条件で、前記障害が生じたアプリケーションの移行先の候補となる各ホストに対して、前記データ負荷換算と前記ボトルネック解析とを行い、
前記ボトルネック解析の結果、移行先の候補となる全てのホストでボトルネックが発生しないときは、停止予定アプリケーションがあれば停止を指示し、候補ホストから移行先ホストを決定し、前記障害が発生しているホストへ移行を指示する
ことを特徴とするＳＡＮ管理方法。
【請求項２】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理方法において、
前記ホストを管理する管理サーバが、
アプリケーションを移行する際に移行元ホストで選択された移行元アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストでの移行元アプリケーションに対するデータ転送負荷に換算するデータ負荷換算ステップと、
データ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネックの解析を行うボトルネック解析ステップと、
移行先の候補ホストについて前記データ負荷換算ステップと前記ボトルネック解析ステップとを実行しボトルネックとならない候補ホストから移行先ホストを決定する移行先ホスト決定ステップと、を含んで実行する
ことを特徴とするＳＡＮ管理方法。
【請求項３】
前記データ負荷換算ステップは、
移行元アプリケーションに対応するボリュームを特定するステップと、
特定したボリュームに対応するデータ転送負荷をボリューム単位に集約するステップと、
集約したデータ転送負荷を移行先ホストの持つ通信経路に均等に分配するステップとを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項４】
前記ボリューム単位に集約するステップは、集約後のデータ転送負荷の値にアプリケーション毎のボリューム利用比率を乗算するステップを有する
ことを特徴とする請求項３に記載のＳＡＮ管理方法。
【請求項５】
前記ボリューム単位に集約するステップは、集約後のデータ転送負荷の値にホスト間の性能差に基づく換算レートを乗算するステップを有する
ことを特徴とする請求項３に記載のＳＡＮ管理方法。
【請求項６】
前記ボトルネック解析ステップは、
換算後のデータ転送負荷をＳＡＮの各リソースについて集約するステップと、
集約したデータ転送負荷の値を各リソースの性能上限値と比較するステップとを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項７】
前記リソースは、通信経路のポートおよびファイバチャネルスイッチの少なくともいずれかを含む
ことを特徴とする請求項６に記載のＳＡＮ管理方法。
【請求項８】
前記移行先ホスト決定ステップは、全ての移行先の候補ホストでボトルネックが発生した場合に停止させるアプリケーションを決定するステップを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項９】
前記停止させるアプリケーションを決定するステップは、アプリケーションの優先度が移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する
ことを特徴とする請求項８に記載のＳＡＮ管理方法。
【請求項１０】
前記移行先ホスト決定ステップは、移行先に決定したホストで選択された前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストにアプリケーションの移行指示を行うステップを有する
ことを特徴とする請求項２に記載のＳＡＮ管理方法。
【請求項１１】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理方法において、
前記ホストを管理する管理サーバが、
アプリケーションを移行する際に、アプリケーションの優先度が移行元ホストで選択された移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する停止可能アプリケーションを決定するステップと、
決定された停止可能アプリケーションが動作するホストに対して停止指示を行うステップと、
前記停止指示に最も早くレスポンスを返したホストを移行先ホストに決定し、決定した移行先ホストに対し前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストに選択されたアプリケーションの移行指示を行うアプリケーション移行ステップと、を含んで実行する
ことを特徴とするＳＡＮ管理方法。
【請求項１２】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理システムにおいて、
アプリケーションを移行する際に移行元ホストで選択された移行元アプリケーションのＳＡＮにおけるデータ転送負荷を移行先の候補ホストでの移行元アプリケーションに対するデータ転送負荷に換算するデータ負荷換算手段と、
データ負荷換算後のデータ転送負荷に基づいて通信経路のボトルネックの解析を行うボトルネック解析手段と、
移行先の候補ホストについて前記データ負荷換算手段と前記ボトルネック解析手段とを実行しボトルネックとならない候補ホストから移行先ホストを決定する移行先ホスト決定手段と、を有する
ことを特徴とするＳＡＮ管理システム。
【請求項１３】
前記データ負荷換算手段は、移行元アプリケーションに対応するボリュームを特定し、
特定したボリュームに対応するデータ転送負荷をボリューム単位に集約し、集約したデータ転送負荷を移行先ホストの持つ通信経路に均等に分配する
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項１４】
前記データ負荷換算手段は、ボリューム単位に集約後のデータ転送負荷の値にアプリケーション毎のボリューム利用比率を乗算する
ことを特徴とする請求項１３に記載のＳＡＮ管理システム。
【請求項１５】
前記データ負荷換算手段は、ボリューム単位に集約後のデータ転送負荷の値にホスト間の性能差に基づく換算レートを乗算する
ことを特徴とする請求項１３に記載のＳＡＮ管理システム。
【請求項１６】
前記ボトルネック解析手段は、換算後のデータ転送負荷をＳＡＮの各リソースについて集約し、集約したデータ転送負荷の値を各リソースの性能上限値と比較する
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項１７】
前記移行先ホスト決定手段は、全ての移行先の候補ホストでボトルネックが発生した場合に停止させるアプリケーションを決定する
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項１８】
前記移行先ホスト決定手段は、前記停止させるアプリケーションを決定する場合に、アプリケーションの優先度が移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する
ことを特徴とする請求項１７に記載のＳＡＮ管理システム。
【請求項１９】
前記移行先ホスト決定手段は、移行先に決定したホストで選択された前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストにアプリケーションの移行指示を行う
ことを特徴とする請求項１２に記載のＳＡＮ管理システム。
【請求項２０】
複数のホストおよびストレージをＳＡＮ（Storage Area Network）に接続したシステムにおける通信経路のデータ転送負荷を収集および分析するＳＡＮ管理システムにおいて、
アプリケーションを移行する際に、アプリケーションの優先度が移行元ホストで選択された移行元アプリケーションよりも低く、かつ、停止可能なアプリケーションを選択する停止可能アプリケーションを決定する手段と、
決定された停止可能アプリケーションが動作するホストに対して停止指示を行う停止指示手段と、
前記停止指示に最も早くレスポンスを返したホストを移行先ホストに決定し、決定した移行先ホストに対し前記移行元アプリケーションと同一のアプリケーションを起動指示し、前記移行元ホストに選択されたアプリケーションの移行指示を行うアプリケーション移行手段と、を有する
ことを特徴とするＳＡＮ管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００７−２９９１６１（Ｐ２００７−２９９１６１Ａ）
【公開日】平成１９年１１月１５日（２００７．１１．１５）
【国際特許分類】
【出願番号】特願２００６−１２５９６０（Ｐ２００６−１２５９６０）
【出願日】平成１８年４月２８日（２００６．４．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成１９年１１月１５日（２００７．１１．１５）
【国際特許分類】
【出願日】平成１８年４月２８日（２００６．４．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]