(57)【特許請求の範囲】
【請求項１】
第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および第１サイトの処理が移行される第２サイトの情報処理装置において稼働される１または複数の第２サイトの処理のリソース使用量を収集する収集ステップと、
前記収集ステップにより収集された前記第１サイトの各処理のリソース使用量の合計が前記第２サイトの空きリソース量以上となる場合であって、
（１）前記第２サイトの各処理に対する現在の割り当てリソース量の比率で前記第２サイトの各処理に対する割り当てリソース量を削減すると前記第２サイトの各処理のいずれかのリソース量が所定の基準に達しない場合に、前記第２サイトの空きリソース量が前記第１サイトの各処理のリソース使用量の合計以上となるまで前記第２サイトの処理のいずれか１つ以上を停止し、
（２）前記第２サイトの処理の各処理に対する現在の割り当てリソースの比率で前記第２サイトの各処理に対する割り当てリソース量を削減しても前記第２サイトの各処理のすべてのリソース量が所定の基準に達する場合に、前記第１サイトの各処理のリソース使用量の合計から前記第２サイトの空きリソース量を減算した不足値を算出し、前記第２サイトの各処理に対する割当てリソース量の比率で前記不足値を分割して割り当てた分割リソース量を前記第２サイトの各処理から削減すること、
をリソース制御情報として定義するステップと、を定期的時点および災害の発生を検知した時点の少なくとも一方の時点で実行する定義部と、
前記災害の発生を検知した時点で、前記定義されたリソース制御情報による処理を実行するリソース制御部と、
を備える管理装置。
【請求項２】
前記リソース制御部は、前記第２サイトの各処理のリソース使用量の合計に対する前記第２サイトの各処理のリソース使用量の割合であるリソース使用率を算出し、前記第２サイトの各処理のうち、前記リソース使用率が他の処理よりも高い処理を停止することを定義する、
請求項１に記載の管理装置。
【請求項３】
前記リソース制御部は、前記第２サイトの各処理の前記リソース使用率に応じて、前記
第２サイトの各処理に対する割当てリソースを削減することによって前記第２サイトのいずれかの処理において割当てリソース削減後のリソース使用量が所定の基準を下回る場合には、前記第２サイトの各処理のうち、前記リソース使用率が他の処理よりも高い処理を停止することを定義する、
請求項１または２に記載の管理装置。
【請求項４】
前記リソース制御情報に従って、前記第２サイトの各処理に割り当てるリソース使用量を変更し、前記第１サイトの処理を前記第２サイトの情報処理装置に移行する移行部をさらに備える、
請求項１から３のいずれか一項に記載の管理装置。
【請求項５】
管理装置と、第１サイトの情報処理装置と、第２サイトの情報処理装置とを有する情報処理システムであって、
前記管理装置は、
前記第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および前記第２サイトの情報処理装置において稼働される１または複数の第２サイトの処理のリソース使用量を収集するステップと、
前記収集部により収集された前記第１サイトの各処理のリソース使用量の合計が前記第２サイトの空きリソース量以上となる場合であって、
（１）前記第２サイトの各処理に対する現在の割り当てリソース量の比率で前記第２サイトの各処理に対する割り当てリソース量を削減すると前記第２サイトの各処理のいずれかのリソース量が所定の基準に達しない場合に、前記第２サイトの空きリソース量が前記第１サイトの各処理のリソース使用量の合計以上となるまで前記第２サイトの処理のいずれか１つ以上を停止し、
（２）前記第２サイトの処理の各処理に対する現在の割り当てリソースの比率で前記第２サイトの各処理に対する割り当てリソース量を削減しても前記第２サイトの各処理のすべてのリソース量が所定の基準に達する場合に、前記第１サイトの各処理のリソース使用量の合計から前記第２サイトの空きリソース量を減算した不足値を算出し、前記第２サイトの各処理に対する割当てリソース量の比率で前記不足値を分割して割り当てた分割リソース量を前記第２サイトの各処理から削減すること、
をリソース制御情報として定義するステップと、を定期的時点および災害の発生を検知した時点の少なくとも一方の時点で実行する定義部と、
前記災害の発生を検知した時点で、前記定義されたリソース制御情報による処理を実行するリソース制御部と、を備える、
情報処理システム。
【請求項６】
コンピュータに、
第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および第２サイトの情報処理装置において稼働される１または複数の第２サイトの処理のリソース使用量を収集するステップと、
収集された前記第１サイトの各処理のリソース使用量の合計が前記第２サイトの空きリソース量以上となる場合であって、
（１）前記第２サイトの各処理に対する現在の割り当てリソース量の比率で前記第２サイトの各処理に対する割り当てリソース量を削減すると前記第２サイトの各処理のいずれかのリソース量が所定の基準に達しない場合に、前記第２サイトの空きリソース量が前記第１サイトの各処理のリソース使用量の合計以上となるまで前記第２サイトの処理のいずれか１つ以上を停止し、
（２）前記第２サイトの処理の各処理に対する現在の割り当てリソースの比率で前記第２サイトの各処理に対する割り当てリソース量を削減しても前記第２サイトの各処理のすべてのリソース量が所定の基準に達する場合に、前記第１サイトの各処理のリソース使用量
の合計から前記第２サイトの空きリソース量を減算した不足値を算出し、前記第２サイトの各処理に対する割当てリソース量の比率で前記不足値を分割して割り当てた分割リソース量を前記第２サイトの各処理から削減すること、
をリソース制御情報として定義するステップと、を定期的時点および災害の発生を検知した時点の少なくとも一方の時点で実行させ、
前記災害の発生を検知した時点で、前記定義されたリソース制御情報による処理を実行させる、
ための管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理装置、情報処理システム及び管理プログラムに関する。
【背景技術】
【０００２】
近年、企業の扱うデータ量が増え、システム環境の変更に柔軟に対応するため、例えば、クラウドコンピューティング等の普及が進んでいる。クラウドコンピューティングによるシステム環境（以下、クラウド環境ともいう）が災害やシステム障害により被害を受けた場合、業務を継続するために、実行環境やデータは、別のクラウド環境に移行される。クラウド環境その他のコンピュータシステムにおいて、災害等の発生時に業務を継続するためのソリューションは、ディザスタリカバリ（Ｄｉｓａｓｔｅｒ  Ｒｅｃｏｖｅｒｙ、ＤＲ）とも呼ばれる。
【０００３】
ＤＲでは、業務を稼働する運用サイト（以下、本番サイトともいう）の他、災害等の発生時に本番サイトの業務を移行するための災害対策用サイト（以下、災対サイトともいう）が用意される。災対サイトは、災害等の発生に備えて用意されるが、資源の有効活用の観点から、本番サイトとは別の業務を稼働する。災対サイトで稼働される業務は、本番サイトで稼働される業務よりも優先度が低いことが多い。
【０００４】
クラウド環境等を対象としたＤＲでは、災害等の発生時に災対サイトに移行される本番サイトの業務、および本番サイトの業務を稼働するために停止される災対サイトの業務が、事前に定義される。災害等が発生した場合には、事前の定義に従って、業務の切替えや停止が実行される。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−１１７８８９号公報
【特許文献２】特開２０１３−０５８１２６号公報
【特許文献３】特開２０１１−１９７９８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、クラウド環境等のコンピュータシステムでは、業務構成が繰り返し変更され、リソース使用量が頻繁に変動する。したがって、災害等が発生した場合には、事前の定義に従って、業務の切替えや停止が実行されても、災対サイトでのリソース不足や無駄な業務の停止を回避できない場合が生じる。例えば、本番サイトのリソース使用量が増加した場合、災対サイトのリソース空き容量が減少した場合、または各業務の負荷が上がった場合に、災対サイトにおけるリソースが不足する可能性がある。一方、本番サイトのリソース使用量が減少した場合、または災対サイトのリソース空き容量が増加した場合には、災対サイトで継続可能な業務まで停止される可能性がある。
【０００７】
本発明の一態様は、運用サイトから災対サイトに業務を移行する場合の災対サイトでのリソース不足を回避し、災対サイトのリソースを有効活用する管理装置、情報処理システム及び管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の態様の一つは、第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および第２サイトの情報処理装置において稼働され
る１または複数の第２サイトの処理のリソース使用量を収集する収集部と、収集部により収集された第１サイトの各処理のリソース使用量および第２サイトの各処理のリソース使用量の変動に応じて、第２サイトの処理のいずれか１つ以上を停止すること、および第２サイトの処理のいずれか１つ以上に対する割当てリソースを削減することの少なくとも一方を、リソース制御情報として定義するリソース制御部と、を備える管理装置である。
【発明の効果】
【０００９】
開示の管理装置、情報処理システム及び管理プログラムによれば、運用サイトから災対サイトに業務を移行する場合の災対サイトでのリソース不足を回避し、災対サイトのリソースを有効活用することができる。
【図面の簡単な説明】
【００１０】
【図１】クラウド環境を対象としたＤＲソリューションの例を示す図である。
【図２】災害等の発生時に復旧シナリオに定義された動作が実行される例を示す図である。
【図３】情報処理システムの一例を示す図である。
【図４】管理装置のハードウェア構成の一例を示す図である。
【図５】管理装置の機能構成の一例を示す図である。
【図６】管理装置が収集する管理情報の例を示す図である。
【図７】復旧シナリオの再定義の要否を判定する例を示す図である。
【図８】災対サイトの空き容量に余裕がある場合に、各業務から不足分のリソースを供出する例を示す図である。
【図９】災対サイトの空き容量に余裕がある場合に、他の業務よりもリソース使用率が高い業務を停止する例を示す図である。
【図１０】災対サイトの空き容量に余裕がない場合に、リソース使用率が所定の閾値よりも高い業務を停止する例を示す図である。
【図１１】災対サイトの空き容量に余裕がない場合に、他の業務よりもリソース使用率が高い業務を停止する例を示す図である。
【図１２】災対サイトの空き容量に余裕がほとんどない場合に、災対サイトの業務をいずれも停止する例を示す図である。
【図１３】通常運用時に復旧シナリオを再定義する処理のフローチャートの一例である。
【図１４】災害発生時に復旧シナリオに従ってサイトの切替えを実行する処理のフローチャートの一例である。
【図１５】災対サイトの空き容量に余裕がある場合の、復旧シナリオの動的定義の判断フローの一例である。
【図１６】災対サイトの空き容量に余裕がない場合の、復旧シナリオの動的定義の判断フローの一例である。
【図１７】災対サイトの空き容量に余裕がほとんどない場合の、復旧シナリオの動的定義の判断フローの一例である。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１２】
＜ＤＲソリューション＞
ＤＲソリューションは、クラウド環境等のコンピュータシステムが被災した場合等に、別のコンピュータシステムに実行環境やデータを移行させ、業務継続するための解決手段である。
【００１３】
図１は、クラウド環境を対象としたＤＲソリューションの例を示す図である。図１において、本番サイト２０（運用サイト）は、サイト管理マネージャ２５、Virtual Machine
（ＶＭ、仮想マシン）ホスト２６、ストレージ２７を含むコンピュータである。ＶＭホスト２６は、複数のＶＭを動作させ業務を稼働させる。ストレージ２７は、業務に対応するデータを記憶する。
【００１４】
災対サイト３０は、本番サイト２０と同様のクラウド環境を有し、ミラーリングにより本番サイト２０と同期を取るコンピュータである。災害等の発生時、本番サイト２０は災対サイト３０に切り替えられる。本番サイト２０から災対サイト３０への切替えは、事前に定義された復旧シナリオに従って実行される。復旧シナリオは、災対サイト３０に移行される本番サイト２０の業務、および災対サイト３０で停止される業務等を定義する。なお、本番サイト２０および災対サイト３０のコンピュータはＶＭホスト２６を有する仮想コンピュータに限定される訳ではない。また、本番サイト２０および災対サイト３０はクラウド環境に限定される訳ではない。
【００１５】
図２は、災害等の発生時に復旧シナリオ２３に定義された動作が実行される例を示す図である。図２において、本番サイト２０は業務Ａ、業務Ｂおよび業務Ｃを稼働している。また、災対サイト３０は業務１、業務２、業務３および業務４を稼働している。
【００１６】
災害の発生により、本番サイト２０の業務Ａから業務Ｃは停止する。復旧シナリオ２３に従って、災対サイト３０は、業務１から業務４を停止する。次に、災対サイト３０は、業務Ａから業務Ｃを起動する。
【００１７】
なお、図２において、災対サイト３０は、業務１を起動する余裕があり、業務１を停止することなく稼働することができる。各業務のリソース使用量が変動した場合、復旧シナリオ２３を再定義することで、災対サイト３０は、リソース不足を回避し、稼働可能な業務を停止することなくリソースを有効活用できる。
【００１８】
＜実施形態＞
クラウド環境において、災害等の発生により本番サイトの業務が停止した場合、停止した業務は、復旧シナリオに従って災対サイトに移行される。本実施形態は、本番サイトおよび災対サイトで稼働する各業務のリソース使用量を定期的に監視し、各業務のリソース使用量や災対サイトのリソースの空き容量の変動に応じて、動的に復旧シナリオを再定義する。
【００１９】
これにより、業務構成が変更され、各業務のリソース使用量が変動しても、災害等発生時の状況に応じた復旧シナリオに従って業務が移行されるため、災対サイトは、リソース不足を回避し、リソースを有効活用することができる。
【００２０】
＜装置構成＞
図３は、情報処理システム１の一例を示す図である。情報処理システム１は、管理装置１０、本番サイト２０および災対サイト３０を含む。図３において、本番サイト２０は、業務Ａ、業務Ｂおよび業務Ｃを稼働する。災対サイト３０は、業務１、業務２、業務３および業務４を稼働する。災対サイト３０は、災害等の発生時には、復旧シナリオに従って業務１から業務４の一部を停止し、業務Ａから業務Ｃを稼働する。
【００２１】
なお、本番サイト２０および災対サイト３０は、いずれも１つに限られず複数であってもよい。本番サイト２０は、第１サイトの一例である。災対サイト３０は、第２サイトの一例である。
【００２２】
図４は、管理装置１０のハードウェア構成の一例を示す図である。管理装置１０は、プロセッサ１１、主記憶装置１２、補助記憶装置１３、入力装置１４、出力装置１５、ネットワークインタフェース１６を備える。また、これらはバス１７により互いに接続される。
【００２３】
プロセッサ１１は、補助記憶装置１３に保持されたＯＳや様々なコンピュータプログラムを主記憶装置１２にロードして実行することによって、様々な処理を実行する。ただし、コンピュータプログラムによる処理の一部がハードウェア回路により実行されてもよい。プロセッサ１１は、例えば、Central Processing Unit（ＣＰＵ）や、Digital Signal Processor（ＤＳＰ）である。
【００２４】
主記憶装置１２は、プロセッサ１１に、補助記憶装置１３に格納されているプログラムをロードするための記憶領域、及びプログラムを実行するための作業領域を提供する。また、主記憶装置１２は、データを保持するためのバッファとして用いられる。主記憶装置１２は、例えば、Read Only Memory（ＲＯＭ）、Random Access Memory（ＲＡＭ）等の半導体メモリである。
【００２５】
補助記憶装置１３は、様々なプログラムや、各プログラムの実行に際してプロセッサ１１が使用するデータを格納する。補助記憶装置１３は、例えば、Erasable Programmable ROM（ＥＰＲＯＭ）、又はハードディスクドライブ（Hard Disk Drive、ＨＤＤ）等の不揮発性のメモリである。補助記憶装置１３は、例えば、オペレーティングシステム（Operating System、ＯＳ）、管理プログラム、その他様々なアプリケーションプログラムを保持する。また、補助記憶装置１３は、管理装置１０が収集した本番サイト２０および災対サイト３０の使用状況等の情報を保持する。
【００２６】
入力装置１４は、ユーザからの操作入力を受け付ける。例えば、入力装置１４は、タッチパッド、マウス、タッチパネル等のポインティングデバイス、キーボード、操作ボタン、遠隔操作機からの信号を受信する回路等である。出力装置１５は、管理装置１０により再定義された復旧シナリオの内容を出力する。出力装置１５は、例えば、液晶ディスプレイ（Liquid Crystal Display、ＬＣＤ）である。
【００２７】
ネットワークインタフェース１６は、ネットワークとの情報の入出力を行うインタフェースである。ネットワークインタフェース１６は、有線のネットワーク、または無線のネットワークと接続する。ネットワークインタフェース１６は、例えば、Network Interface Card（ＮＩＣ）、無線Local Area Network（ＬＡＮ）カード等である。ネットワークインタフェース１６で受信されたデータ等は、プロセッサ１１に出力される。
【００２８】
例えば、管理装置１０では、プロセッサ１１が、補助記憶装置１３に保持される管理プログラムを主記憶装置１２にロードして実行する。なお、管理装置１０のハードウェア構成は一例であり、上記に限られず、実施の形態に応じて適宜構成要素の省略や置換、追加が可能である。
【００２９】
図５は、管理装置１０の機能構成の一例を示す図である。管理装置１０は、機能構成として、収集部２１、リソース制御部２２、復旧シナリオ２３および移行部２４を備える。管理装置１０のプロセッサ１１は、コンピュータプログラムにより、収集部２１、リソース制御部２２および移行部２４の処理を実行する。ただし、収集部２１、リソース制御部２２および移行部２４のいずれか、またはその処理の一部がハードウェア回路により実行されてもよい。
【００３０】
収集部２１は、本番サイト２０および災対サイト３０で稼働する各業務のリソース使用
量を収集する。リソース使用量は、例えば、ＣＰＵ使用量、メモリ使用量、ディスクInput/Output（Ｉ／Ｏ）量、ネットワークＩ／Ｏ量である。
【００３１】
リソース制御部２２は、本番サイト２０および災対サイト３０で稼働する各業務のリソース使用量の変動に応じて、災対サイト３０に移行される本番サイト２０の業務、および災対サイト３０で停止される業務等を定義する復旧シナリオ２３を生成する。
【００３２】
復旧シナリオ２３は、本番サイト２０から災対サイト３０への業務の移行、災対サイト３０での業務の停止、災対サイト３０の各業務への割当てリソースの削減等を定義する。復旧シナリオ２３は、コンピュータプログラムにより、プロセッサ１１が読み出して実行可能な形式、例えば、テキストやバイナリ形式で定義されたものであればよい。復旧シナリオ２３は、リソース制御情報の一例である。
【００３３】
移行部２４は、災害等の発生時に、復旧シナリオ２３に従って、災対サイト３０での業務の停止、災対サイト３０の各業務への割当てリソースの削減等を行う。また、移行部２４は、本番サイト２０で稼働される各業務を、災対サイト３０に移行する。
【００３４】
＜復旧シナリオ定義＞
図６から図１２は、復旧シナリオ２３の定義を説明するための図である。管理装置１０は、所定の時間間隔で業務ごとのリソースの使用状況および災対サイト３０のリソースの空き状況等の管理情報を収集する。管理装置１０は、収集した管理情報から得られる所定の指標値に応じた復旧シナリオ２３を定義する。図６および図７は、収集される管理情報および指標値について説明する。図８から図１２は、指標値に応じた復旧シナリオ２３の例を示す。
【００３５】
復旧シナリオ２３の定義に使用する管理情報を収集するため、ユーザは、監視対象のリソース種別および監視間隔を指定する。監視対象のリソース種別は、例えば、ＣＰＵ、メモリ、ディスク、ネットワーク等の使用量である。監視間隔は、管理装置１０が、復旧シナリオ２３の定義に使用する管理情報を収集する時間間隔である。管理装置１０は、監視間隔として指定された時間ごとに、各業務のリソース使用状況、および災対サイト３０のリソースの空き状況等を収集する。
【００３６】
図６は、管理装置１０が収集する管理情報４０の例を示す図である。図６において、「業務」の項目は、本番サイト２０および災対サイト３０で稼働する業務名を示す。各「業務」に対し、「サイト」および「最新状態」の情報が保持される。「サイト」は、業務が本番サイト２０で稼働しているか、災対サイト３０で稼働しているかを示す。「最新状態」は、業務が起動されているか否かを示す。
【００３７】
また、図６の例では、各「業務」に対し、「２０１４年８月８日０時２０分」、「２０１４年８月８日６時２０分」、「２０１４年８月８日１２時２０分」の各時刻におけるＣＰＵ使用量の情報が保持されている。管理装置１０は、リソースの使用量を定期的に監視し、情報収集をした時刻（以下、情報収集時刻ともいう）における各業務のリソース使用量を保持していく。
【００３８】
具体的には、“業務Ａ”は、本番サイト２０の業務であり起動状態である。“業務Ａ”のＣＰＵ使用量は、２０１４年８月８日０時２０分には２ＧＨｚ、２０１４年８月８日６時２０分には１ＧＨｚ、２０１４年８月８日１２時２０分には３ＧＨｚである。
【００３９】
各業務のリソース使用量のほか、災対サイト３０の空き容量も収集され、保持される。具体的には、災対サイト３０の空き容量は、２０１４年８月８日０時２０分には５ＧＨｚ
、２０１４年８月８日６時２０分には５ＧＨｚ、２０１４年８月８日１２時２０分には３ＧＨｚである。
【００４０】
図７は、復旧シナリオの再定義の要否を判定する例を示す図である。管理装置１０は、「災対サイトのＣＰＵ空き容量」、「本番サイトのＣＰＵ使用量」および「指標値Ｘ」から「復旧シナリオの再定義」の要否を判定する。
【００４１】
「災対サイトのＣＰＵ空き容量」は、各情報収集時刻における災対サイト３０のＣＰＵ空き容量である。「本番サイトのＣＰＵ使用量」は、各情報収集時刻において各業務が使用する本番サイト２０のＣＰＵ使用量の合計である。
【００４２】
「指標値Ｘ」は、「災対サイトのＣＰＵ空き容量」をＡ、「本番サイトのＣＰＵ使用量」をＢとした場合、Ａ÷Ｂにより算出される値である。なお、「指標値Ｘ」は、ＡとＢの比率を表す値であれば、他の計算式により算出されてもよい。
【００４３】
「復旧シナリオの再定義」は、復旧シナリオ２３を再定義するか否かを示す。「災対サイトのＣＰＵ空き容量」が「本番サイトのＣＰＵ使用量」以上であれば、復旧シナリオ２３は、再定義されなくてもよい。管理装置１０は、例えば、「指標値Ｘ」が１以上の場合は復旧シナリオ２３を再定義せず、「指標値Ｘ」が１より小さい場合は復旧シナリオ２３を再定義する。
【００４４】
具体的には、２０１４年８月８日０時２０分における「災対サイトのＣＰＵ空き容量」は５ＧＨｚ、「本番サイトのＣＰＵ使用量」は４ＧＨｚである。「指標値Ｘ」は、５÷４＝１．２５と算出される。「指標値Ｘ」が１以上であるため、復旧シナリオ２３は再定義されない。
【００４５】
また、２０１４年８月８日１２時２０分における「災対サイトのＣＰＵ空き容量」は３ＧＨｚ、「本番サイトのＣＰＵ使用量」は７ＧＨｚである。「指標値Ｘ」は、３÷７より約０．４３と算出される。「指標値Ｘ」が１より小さく、災対サイト３０の空き容量が不足しているため、復旧シナリオ２３は再定義される。
【００４６】
さらに、復旧シナリオ２３の再定義の要否は、災害等の発生時にも確認される。図７では、２０１４年８月８日１２時４１分に災害が発生した例が示される。災害発生時、「災対サイトのＣＰＵ空き容量」は１ＧＨｚ、「本番サイトのＣＰＵ使用量」は７ＧＨｚである。「指標値Ｘ」は、１÷７より約０．１４と算出される。「指標値Ｘ」が、前回の情報収集時刻である２０１４年８月８日１２時２０分における値から変動しているため、復旧シナリオ２３は再定義される。
【００４７】
図８から図１２は、指標値Ｘに応じた復旧シナリオ２３の例を示す。本実施形態では、指標値Ｘの値に応じてケース１からケース５に場合を分けて、復旧シナリオ２３を再定義する。図８から図１２は、それぞれケース１からケース５に対応する。
【００４８】
なお、復旧シナリオ２３の再定義は、ケース１からケース５の場合分けに限られず、任意の条件によって場合分けをしてもよい。各場合分け（ケース）において、災対サイト３０の空き容量を確保する処理は、ケース１からケース５で行われる処理を適宜組み合わせてもよい。
【００４９】
また、ケース１からケース５は、リソースがＣＰＵ使用量であるものとして説明されるが、リソースはメモリ使用量、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量等であってもよい。
【００５０】
（ケース１）
ケース１は、災対サイト３０の空き容量に余裕がある場合である。この場合、例えば、指標値Ｘは０．６≦Ｘ＜１を満たす。指標値Ｘの閾値は０．６に限られず、災対サイト３０の空き容量に余裕があるとされる値であればよい。
【００５１】
災対サイト３０の空き容量に余裕があるため、不足するリソースは、災対サイト３０の各業務に分散して負担される。具体的には、不足するリソースは、リソースの使用率に応じて、災対サイト３０の各業務から供出される。
【００５２】
図８は、災対サイトの空き容量に余裕がある場合に、各業務から不足分のリソースを供出する例を示す図である。管理装置１０が収集した管理情報４０に基づいて、復旧シナリオ２３が再定義されるか否かが判断される。図８において、２０１４年８月８日１２時２０分における「災対サイトのＣＰＵ空き容量」は７ＧＨｚ、「本番サイトのＣＰＵ使用量」は１０ＧＨｚ、「不足するリソース量」は３ＧＨｚである。「指標値Ｘ」は、７÷１０＝０．７と算出される。「指標値Ｘ」が１より小さいため、復旧シナリオ２３は再定義される。
【００５３】
災対サイト３０において、業務１から業務４が稼働中である。業務１から業務４のリソース使用量は、それぞれ２ＧＨｚ、３ＧＨｚ、３ＧＨｚ、２ＧＨｚであり、災対サイト３０のリソース使用量は１０ＧＨｚとなる。災対サイト３０のリソース使用量１０ＧＨｚに対する業務１から業務４のリソース使用率は、それぞれ２０％、３０％、３０％、２０％である。
【００５４】
不足するリソースの３ＧＨｚは、各業務のリソース使用率に応じて供出される。業務１は、不足するリソース３ＧＨｚに、業務１のリソース使用率０．２を乗じた０．６ＧＨｚを供出する。業務２は、不足するリソース３ＧＨｚに、業務２のリソース使用率０．３を乗じた０．９ＧＨｚを供出する。業務３は、不足するリソース３ＧＨｚに、業務３のリソース使用率０．３を乗じた０．９ＧＨｚを供出する。業務４は、不足するリソース３ＧＨｚに、業務４のリソース使用率０．２を乗じた０．６ＧＨｚを供出する。
【００５５】
各業務からのリソースの供出により、災対サイト３０の空き容量は、３ＧＨｚ増加して１０ＧＨｚとなる。指標値Ｘは１０÷１０＝１となり、指標値Ｘが１以上であるため、復旧シナリオ２３は終了する。
【００５６】
（ケース２）
ケース２は、災対サイト３０の空き容量に余裕がある場合である。この場合、例えば、指標値Ｘは０．６≦Ｘ＜１を満たす。指標値Ｘの閾値は０．６に限られず、災対サイト３０の空き容量に余裕があるとされる値であればよい。
【００５７】
さらに、ケース２は、ケース１のように災対サイト３０の各業務からリソースを供出すると、いずれかの業務において、供出後のリソース使用量が所定の基準を下回る場合である。この場合、リソース使用率が他の業務よりも高い業務が停止される。なお、所定の基準は、業務の継続に使用されるリソース量であって、業務ごとに事前に定義される値である。
【００５８】
図９は、災対サイトの空き容量に余裕がある場合に、他の業務よりもリソース使用率が高い業務を停止する例を示す図である。図９では、ケース１と同様に「指標値Ｘ」が１より小さいため、復旧シナリオ２３は再定義される。
【００５９】
災対サイト３０において、業務１から業務４が稼働中である。業務１から業務４のリソース使用量は、それぞれ１ＧＨｚ、４ＧＨｚ、３ＧＨｚ、２ＧＨｚであり、災対サイト３０のリソース使用量は１０ＧＨｚとなる。災対サイト３０のリソース使用量１０ＧＨｚに対する業務１から業務４のリソース使用率は、それぞれ１０％、４０％、３０％、２０％である。
【００６０】
不足するリソースを各業務から供出する場合、業務１は、不足するリソース３ＧＨｚに、業務１のリソース使用率０．１を乗じた０．３ＧＨｚを供出することになる。供出後のリソース使用量は、０．７ＧＨｚであって、所定の基準を下回るものとする。この場合、不足するリソースを各業務から供出せずに、リソース使用率が他の業務よりも高い業務２が停止される。
【００６１】
業務２の停止により、災対サイト３０の空き容量は、４ＧＨｚ増加して１１ＧＨｚとなる。指標値Ｘは１１÷１０＝１．１となり、指標値Ｘが１以上であるため、復旧シナリオ２３は終了する。
【００６２】
（ケース３）
ケース３は、災対サイト３０の空き容量に余裕がない場合である。この場合、例えば、指標値Ｘは０．２≦Ｘ＜０．６を満たす。指標値Ｘの閾値は、０．２と０．６に限られず、災対サイト３０の空き容量に余裕がないとされる値であればよい。
【００６３】
災対サイト３０の空き容量に余裕がないため、災対サイト３０の各業務のうちリソース使用率が相対的に高い業務が停止される。例えば、リソース使用率が４０％以上の業務が停止される。リソース使用率が相対的に高い業務の停止により、災対サイト３０の他の業務は、影響を受けることなく稼働を継続することができる。
【００６４】
リソース使用率が相対的に高い業務を停止しても、指標値Ｘが１以上にならない場合、災対サイト３０の各業務は、リソースの使用率に応じて不足分のリソースを供出すればよい。
【００６５】
図１０は、災対サイトの空き容量に余裕がない場合に、リソース使用率が所定の閾値よりも高い業務を停止する例を示す図である。管理装置１０が収集した管理情報４０に基づいて、復旧シナリオ２３が再定義されるか否かが判断される。図１０において、２０１４年８月８日１２時２０分における「災対サイトのＣＰＵ空き容量」は３ＧＨｚ、「本番サイトのＣＰＵ使用量」は７ＧＨｚ、「不足するリソース量」は４ＧＨｚである。「指標値Ｘ」は、３÷７より約０．４３と算出される。「指標値Ｘ」が１より小さいため、復旧シナリオ２３は再定義される。
【００６６】
災対サイト３０において、業務１から業務４が稼働中である。業務１から業務４のリソース使用量は、それぞれ３ＧＨｚ、８ＧＨｚ、３ＧＨｚ、２ＧＨｚであり、災対サイト３０のリソース使用量は１６ＧＨｚとなる。災対サイト３０のリソース使用量１６ＧＨｚに対する業務１から業務４のリソース使用率は、それぞれ約１９％、５０％、１９％、１２％である。
【００６７】
リソース使用率が５０％と他の業務よりも相対的に高い業務２が停止される。業務２の停止により、災対サイト３０の空き容量は、８ＧＨｚ増加して１１ＧＨｚとなる。指標値Ｘは１１÷７より約１．５７と算出される。指標値Ｘが１以上であるため、復旧シナリオ２３は終了する。
【００６８】
（ケース４）
ケース４は、災対サイト３０の空き容量に余裕がない場合である。例えば、指標値Ｘが０．２≦Ｘ＜０．６を満たす場合である。指標値Ｘの閾値は、０．２と０．６に限られず、災対サイト３０の空き容量に余裕がないとされる値であればよい。
【００６９】
さらに、ケース４は、ケース３と異なり、リソース使用率が相対的に高い業務がない場合である。この場合、不足するリソースは、リソースの使用率に応じて災対サイト３０の各業務から供出される。
【００７０】
災対サイト３０の各業務からリソースを供出すると、いずれかの業務において、供出後のリソース使用量が所定の基準を下回る場合には、リソース使用率が他の業務よりも高い業務が停止されればよい。なお、所定の基準は、業務ごとに事前に定義される値である。
【００７１】
各業務からのリソースの供出または業務の停止によっても、指標値Ｘが１より小さい場合は、指標値Ｘが１以上になるまで、各業務からのリソースの供出または業務の停止を繰り返す。
【００７２】
図１１は、災対サイトの空き容量に余裕がない場合に、他の業務よりもリソース使用率が高い業務を停止する例を示す図である。管理装置１０が収集した管理情報４０に基づいて、復旧シナリオ２３が再定義されるか否かが判断される。図１１において、２０１４年８月８日１２時２０分における「災対サイトのＣＰＵ空き容量」は２．５ＧＨｚ、「本番サイトのＣＰＵ使用量」は１０ＧＨｚ、「不足するリソース量」は７．５ＧＨｚである。「指標値Ｘ」は、２．５÷１０＝０．２５と算出される。「指標値Ｘ」が１より小さいため、復旧シナリオ２３は再定義される。
【００７３】
災対サイト３０において、業務１から業務４が稼働中である。業務１から業務４のリソース使用量は、それぞれ２．６ＧＨｚ、１．３ＧＨｚ、４．８ＧＨｚ、４．３ＧＨｚであり、災対サイト３０のリソース使用量は１３ＧＨｚとなる。災対サイト３０のリソース使用量１３ＧＨｚに対する業務１から業務４のリソース使用率は、それぞれ約２０％、１０％、３７％、３３％である。
【００７４】
不足するリソースを各業務から供出する場合、業務２は、不足するリソース７．５ＧＨｚに、業務２のリソース使用率０．１を乗じた０．７５ＧＨｚを供出することになる。供出後のリソース使用量は、０．５５ＧＨｚであって、所定の基準を下回るものとする。この場合、不足するリソースを各業務から供出せずに、リソース使用率が他の業務よりも高い業務３が停止される。
【００７５】
業務３の停止により、災対サイト３０の空き容量は、４．８ＧＨｚ増加して７．３ＧＨｚとなる。指標値Ｘは７．３÷１０＝０．７３と算出される。指標値Ｘが１より小さいため、さらに不足するリソースは、各業務から供出される。
【００７６】
災対サイト３０において、業務１、業務２および業務４が稼働中である。業務１、業務２および業務４のリソース使用量は、それぞれ２．６ＧＨｚ、１．３ＧＨｚ、４．３ＧＨｚであり、災対サイト３０のリソース使用量は８．２ＧＨｚとなる。災対サイト３０のリソース使用量８．２ＧＨｚに対する業務１、業務２および業務４のリソース使用率は、それぞれ約３７％、１８％、６２％である。また、不足するリソースは１０−７．３＝２．７ＧＨｚとなる。
【００７７】
不足するリソースを各業務から供出する場合、業務２は、不足するリソース２．７ＧＨｚに、業務２のリソース使用率０．１８を乗じた約０．４８６ＧＨｚを供出することになる。供出後のリソース使用量は、０．８ＧＨｚであって、所定の基準を下回るものとする。この場合、不足するリソースを各業務から供出せずに、リソース使用率が他の業務よりも高い業務４が停止される。
【００７８】
業務４の停止により、災対サイト３０の空き容量は、４．３ＧＨｚ増加して１１．６ＧＨｚとなる。指標値Ｘは１１．６÷１０＝１．１６となり、指標値Ｘが１以上であるため、復旧シナリオ２３は終了する。
【００７９】
（ケース５）
ケース５は、災対サイト３０の空き容量に余裕がほとんどない場合である。例えば、指標値ＸがＸ＜０．２を満たす場合である。指標値Ｘの閾値は、０．２に限られず、災対サイト３０の空き容量に余裕がほとんどないとされる値であればよい。災対サイト３０の空き容量に余裕がほとんどないため、災対サイト３０の各業務は停止される。
【００８０】
図１２は、災対サイト３０の空き容量に余裕がほとんどない場合に、災対サイトの業務をいずれも停止する例を示す図である。管理装置１０が収集した管理情報４０に基づいて、復旧シナリオ２３が再定義されるか否かが判断される。図１２において、２０１４年８月８日１２時２０分における「災対サイトのＣＰＵ空き容量」は１ＧＨｚ、「本番サイトのＣＰＵ使用量」は１３ＧＨｚ、「不足するリソース量」は１２ＧＨｚである。「指標値Ｘ」は、１÷１３より約０．０８と算出される。「指標値Ｘ」が１より小さいため、復旧シナリオ２３は再定義される。
【００８１】
災対サイト３０の空き容量に余裕がほとんどないため、災対サイト３０で稼働中の各業務は停止される。各業務の停止により、災対サイト３０の空き容量は、１２ＧＨｚ増加して１３ＧＨｚとなる。指標値Ｘは１３÷１３＝１と算出される。指標値Ｘが１以上であるため、復旧シナリオ２３は終了する。
【００８２】
＜処理の流れ＞
図１３および図１４は、復旧シナリオ２３の再定義および実行の処理の流れを説明する。図１５から図１７は、復旧シナリオ２３の動的定義の判断フローの詳細を説明する。
【００８３】
図１３は、通常運用時に復旧シナリオを再定義する処理のフローチャートの一例である。通常運用時に復旧シナリオを再定義する処理は、例えば、管理装置１０の起動により開始される。
【００８４】
ＯＰ１１では、管理装置１０は、復旧シナリオ２３の初期設定をする。初期設定は、例えば、監視対象のリソース種別および監視間隔の設定を含む。次に処理がＯＰ１２に進む。ＯＰ１２では、管理装置１０は、本番サイト２０および災対サイト３０のリソースの使用状況を一定時間ごとに収集する。次に処理がＯＰ１３に進む。
【００８５】
ＯＰ１３では、管理装置１０は、指標値Ｘを計算する。次に処理がＯＰ１４に進む。ＯＰ１４では、管理装置１０は、使用状況を収集した時点で復旧シナリオ２３の再定義をするか否かを判定する。復旧シナリオ２３の再定義をする場合、すなわち指標値Ｘ＜１の場合には（ＯＰ１４：Ｙｅｓ）、処理がＯＰ１５に進む。復旧シナリオ２３の再定義をしない場合、すなわち指標値Ｘ≧１の場合には（ＯＰ１４：Ｎｏ）、処理がＯＰ１２に戻る。
【００８６】
ＯＰ１５では、管理装置１０は、図１５から図１７に示される復旧シナリオ２３の動的定義の判断フローに従って復旧シナリオ２３を再定義する。次に、処理がＯＰ１２に戻る。管理装置１０が起動されている間、ＯＰ１２からＯＰ１５までの処理が繰り返される。
【００８７】
図１４は、災害発生時に復旧シナリオに従ってサイトの切替えを実行する処理のフロー
チャートの一例である。災害発生時に復旧シナリオに従ってサイトの切替えを実行する処理は、例えば、管理装置１０が災害等の発生を検知することにより開始される。災害等の発生は、例えば、本番サイト２０への通信障害、オペレータ入力等によって検知される。
【００８８】
ＯＰ２１では、管理装置１０は、本番サイト２０および災対サイト３０のリソースの使用状況を収集する。次に処理がＯＰ２２に進む。ＯＰ２２では、管理装置１０は、指標値Ｘを計算する。次に処理がＯＰ２３に進む。
【００８９】
ＯＰ２３では、管理装置１０は、復旧シナリオ２３の再定義をするか否かを判定する。復旧シナリオ２３の再定義をする場合、すなわち指標値Ｘ＜１の場合には（ＯＰ２３：Ｙｅｓ）、処理がＯＰ２４に進む。復旧シナリオ２３の再定義をしない場合、すなわち指標値Ｘ≧１の場合には（ＯＰ２３：Ｎｏ）、処理がＯＰ２６に進む。
【００９０】
ＯＰ２４では、管理装置１０は、平時に設定した復旧シナリオ２３の再定義をするか否かを判定する。すなわち、管理装置１０は、災害発生時に算出した指標値Ｘが、平時に設定した復旧シナリオ２３に対する指標値Ｘの範囲外であるか否かを判定する。
【００９１】
復旧シナリオ２３の再定義をする場合、すなわち災害発生時に算出した指標値Ｘが、平時に設定した復旧シナリオ２３に対する指標値Ｘの範囲外である場合には（ＯＰ２４：Ｙｅｓ）、処理がＯＰ２５に進む。復旧シナリオ２３の再定義をしない場合、すなわち災害発生時に算出した指標値Ｘが、平時に設定した復旧シナリオ２３に対する指標値Ｘの範囲内である場合には（ＯＰ２４：Ｎｏ）、処理がＯＰ２６に進む。
【００９２】
ＯＰ２５では、管理装置１０は、図１５から図１７に示す、復旧シナリオ２３の動的定義の判断フローに従って復旧シナリオ２３を再定義する。次に処理がＯＰ２６に進む。ＯＰ２６では、管理装置１０は、復旧シナリオ２３に従って、本番サイト２０の業務を、災対サイト３０に切り替え、処理が終了する。
【００９３】
図１５から図１７は、復旧シナリオ２３の動的定義の判断フローの詳細を説明する。図１５から図１７の処理は、図１３のＯＰ１５および図１４のＯＰ２５の処理の詳細であり、それぞれ動的定義の判断フロー１、動的定義の判断フロー２、動的定義の判断フロー３と称される。
【００９４】
図１５は、災対サイトの空き容量に余裕がある場合の、復旧シナリオ２３の動的定義の判断フローの一例である。すなわち、図１５は、ケース１およびケース２の復旧シナリオ２３の流れを説明する。
【００９５】
ＯＰ３１では、管理装置１０は、指標値Ｘが０．６≦指標値Ｘ＜１．０を満たすか否かを判定する。０．６≦指標値Ｘ＜１．０を満たす場合には（ＯＰ３１：Ｙｅｓ）、処理がＯＰ３２に進む。０．６≦指標値Ｘ＜１．０を満たさない場合には（ＯＰ３１：Ｎｏ）、処理が動的定義の判断フロー２に進む。
【００９６】
ＯＰ３２では、管理装置１０は、リソース供出後に、リソース使用量の所定基準を下回る業務が存在するか否かを判定する。リソース使用量の所定基準を下回る業務が存在する場合には（ＯＰ３２：Ｙｅｓ）、処理がＯＰ３３に進む。リソース使用量の所定基準を下回る業務が存在しない場合には（ＯＰ３２：Ｎｏ）、ケース１の復旧シナリオ２３が定義され、処理が終了する。ケース１の復旧シナリオ２３は、災対サイトの各業務のリソース使用量に応じて、リソースを供出するシナリオである。
【００９７】
ＯＰ３３では、管理装置１０は、相対的にリソース使用率が高い業務を停止する。ケー
ス２の復旧シナリオ２３が定義され、処理が終了する。ケース２の復旧シナリオ２３は、所定基準を下回る業務を除外し、その他の各業務のリソース使用量に応じて、リソースを供出するシナリオである。
【００９８】
図１６は、災対サイトの空き容量に余裕がない場合の、復旧シナリオの動的定義の判断フローの一例である。すなわち、図１６は、ケース３およびケース４の復旧シナリオ２３の流れを説明する。
【００９９】
ＯＰ４１では、管理装置１０は、指標値Ｘが０．２≦指標値Ｘ＜０．６を満たすか否かを判定する。０．２≦指標値Ｘ＜０．６を満たす場合には（ＯＰ４１：Ｙｅｓ）、処理がＯＰ４２に進む。０．２≦指標値Ｘ＜０．６を満たさない場合には（ＯＰ４１：Ｎｏ）、処理が動的定義の判断フロー３に進む。
【０１００】
ＯＰ４２では、管理装置１０は、災対サイト３０の各業務の中で相対的にリソース使用量が多い業務があるか否かを判定する。相対的にリソース使用量が多い業務がある場合には（ＯＰ４２：Ｙｅｓ）、処理がＯＰ４３に進む。相対的にリソース使用量が多い業務がない場合には（ＯＰ４２：Ｎｏ）、処理がＯＰ４５に進む。
【０１０１】
ＯＰ４３では、管理装置１０は、相対的にリソース使用率が高い業務を停止する。次に処理がＯＰ４４に進む。ＯＰ４４では、管理装置１０は、指標値Ｘを再計算し、指標値Ｘ≧１．０となるか否かを判定する。指標値Ｘ≧１．０となる場合には（ＯＰ４４：Ｙｅｓ）、ケース３の復旧シナリオ２３が定義され、処理が終了する。ケース３の復旧シナリオ２３は、災対サイトでリソース使用率が相対的に高い業務を停止し、リソースを供出するシナリオである。指標値Ｘ≧１．０とならない場合には（ＯＰ４４：Ｎｏ）、処理がＯＰ４５に進む。
【０１０２】
ＯＰ４５では、管理装置１０は、リソース供出後に、リソース使用量の所定基準を下回る業務が存在するか否かを判定する。リソース使用量の所定基準を下回る業務が存在する場合には（ＯＰ４５：Ｙｅｓ）、処理がＯＰ４６に進む。リソース使用量の所定基準を下回る業務が存在しない場合には（ＯＰ４５：Ｎｏ）、ケース４の復旧シナリオ２３が定義され、処理が終了する。
【０１０３】
ＯＰ４６では、管理装置１０は、相対的にリソース使用率が高い業務を停止する。なお、ＯＰ４６の処理後、指標値Ｘ＜１．０である場合には、指標値Ｘ≧１．０となるまで、ＯＰ４５およびＯＰ４６の処理が繰り返される。次に、ケース４の復旧シナリオ２３が定義され、処理が終了する。ケース４の復旧シナリオ２３は、災対サイトでのリソース使用率とリソース使用量の所定基準の両方を加味してリソースを供出するシナリオである。
【０１０４】
図１７は、災対サイトの空き容量に余裕がほとんどない場合の、復旧シナリオの動的定義の判断フローの一例である。すなわち、図１７は、ケース５の復旧シナリオ２３の流れを説明する。
【０１０５】
ＯＰ５１では、管理装置１０は、指標値Ｘが指標値Ｘ＜０．２を満たすか否かを判定する。指標値Ｘ＜０．２を満たす場合には（ＯＰ５１：Ｙｅｓ）、処理がＯＰ５２に進む。動的定義の判断フロー１および２の処理において、指標値Ｘ≧０．２となる場合は除かれているため、通常は指標値Ｘ＜０．２が満たされる。しかしながら、指標値Ｘ＜０．２を満たさない場合には（ＯＰ５１：Ｎｏ）、処理が動的定義の判断フロー１に戻るようにしてもよい。
【０１０６】
ＯＰ５２では、管理装置１０は、災対サイト３０の各業務を停止する。ケース５の復旧
シナリオ２３が定義され、処理が終了する。ケース５の復旧シナリオ２３は、災対サイト３０の各業務を停止するシナリオである。
【０１０７】
＜実施形態の作用効果＞
管理装置１０は、定期的に、および災害等の発生時に、本番サイト２０および災対サイト３０で稼働される各業務のリソースの使用量を収集し、収集したリソース使用量の変動に応じて復旧シナリオ２３を再定義する。これにより、管理装置１０は、各サイトのリソース使用状況に合わせた復旧シナリオ２３を自動で生成し、実行することができる。また、復旧シナリオ２３の維持管理の工数が削減される。
【０１０８】
管理装置１０は、災対サイト３０の空きリソースが、本番サイト２０のリソース使用量以上となるように復旧シナリオ２３を再定義する。これにより、災対サイト３０のリソース不足を回避することができる。
【０１０９】
管理装置１０は、不足するリソースを確保するため、災対サイト３０における各業務のリソース使用率を算出し、リソース使用率が他の業務よりも高い業務を停止する。これにより、災対サイト３０で稼働中の業務への影響範囲が局所化される。
【０１１０】
また、管理装置１０は、不足するリソースを確保するため、リソース使用率に応じて各業務からリソースを供出させる。なお、管理装置１０は、リソースの供出により、業務に割り当てられるリソースが所定の基準を下回る場合には、リソース使用率が他の業務よりも高い業務を停止すればよい。これにより、災対サイト３０で稼働中の業務への影響が低減される。災対サイト３０で稼働中の業務への影響範囲を局所化し、影響を低減することで、災対サイト３０のリソースを有効活用することができる。
【０１１１】
災害等の発生時には、復旧シナリオ２３を再定義し、本番サイト２０の各業務を災対サイト３０に移行することで、管理装置１０は、災害等発生時の両サイトの稼働状況に応じた移行が可能となる。災害等の発生時に、本番サイト２０のリソース使用状況の収集ができない等、復旧シナリオ２３を再定義できない場合には、管理装置１０は、直前の復旧シナリオ２３に従って移行を行えばよい。これにより、災害等の発生時により近い稼働状況に応じた移行が可能となる。
【０１１２】
＜記録媒体＞
コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
【０１１３】
ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。さらに、Solid State Drive（ＳＳＤ）はコンピュータ等から取り外し可能な記録媒体としても、コンピュータ等
に固定された記録媒体としても利用可能である。
【符号の説明】
【０１１４】
１        情報処理システム
１０      管理装置
１１      プロセッサ
１２      主記憶装置
１３      補助記憶装置
１４      入力装置
１５      出力装置
１６      ネットワークインタフェース
１７      バス
２０      本番サイト
２１      収集部
２２      リソース制御部
２３      復旧シナリオ
２４      移行部
２５      サイト管理マネージャ
２６      ＶＭホスト
２７      ストレージ
３０      災対サイト
４０      管理情報
【図１】
0006540072.tif 000002
【図２】
0006540072.tif 000003
【図３】
0006540072.tif 000004
【図４】
0006540072.tif 000005
【図５】
0006540072.tif 000006
【図６】
0006540072.tif 000007
【図７】
0006540072.tif 000008
【図８】
0006540072.tif 000009
【図９】
0006540072.tif 000010
【図１０】
0006540072.tif 000011
【図１１】
0006540072.tif 000012
【図１２】
0006540072.tif 000013
【図１３】
0006540072.tif 000014
【図１４】
0006540072.tif 000015
【図１５】
0006540072.tif 000016
【図１６】
0006540072.tif 000017
【図１７】
0006540072.tif 000018