JP6540072B2 - 管理装置、情報処理システム及び管理プログラム - Google Patents

管理装置、情報処理システム及び管理プログラム Download PDF

Info

Publication number
JP6540072B2
JP6540072B2 JP2015027768A JP2015027768A JP6540072B2 JP 6540072 B2 JP6540072 B2 JP 6540072B2 JP 2015027768 A JP2015027768 A JP 2015027768A JP 2015027768 A JP2015027768 A JP 2015027768A JP 6540072 B2 JP6540072 B2 JP 6540072B2
Authority
JP
Japan
Prior art keywords
site
resource
amount
disaster
resource usage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015027768A
Other languages
English (en)
Other versions
JP2016151816A (ja
Inventor
勝雄 飯村
勝雄 飯村
健一郎 下川
健一郎 下川
隆弘 小島
隆弘 小島
裕 江▲崎▼
裕 江▲崎▼
インジン タラ
インジン タラ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2015027768A priority Critical patent/JP6540072B2/ja
Priority to US15/009,876 priority patent/US9946615B2/en
Publication of JP2016151816A publication Critical patent/JP2016151816A/ja
Application granted granted Critical
Publication of JP6540072B2 publication Critical patent/JP6540072B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/203—Failover techniques using migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3442—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は、管理装置、情報処理システム及び管理プログラムに関する。
近年、企業の扱うデータ量が増え、システム環境の変更に柔軟に対応するため、例えば、クラウドコンピューティング等の普及が進んでいる。クラウドコンピューティングによるシステム環境（以下、クラウド環境ともいう）が災害やシステム障害により被害を受けた場合、業務を継続するために、実行環境やデータは、別のクラウド環境に移行される。クラウド環境その他のコンピュータシステムにおいて、災害等の発生時に業務を継続するためのソリューションは、ディザスタリカバリ（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ、ＤＲ）とも呼ばれる。
ＤＲでは、業務を稼働する運用サイト（以下、本番サイトともいう）の他、災害等の発生時に本番サイトの業務を移行するための災害対策用サイト（以下、災対サイトともいう）が用意される。災対サイトは、災害等の発生に備えて用意されるが、資源の有効活用の観点から、本番サイトとは別の業務を稼働する。災対サイトで稼働される業務は、本番サイトで稼働される業務よりも優先度が低いことが多い。
クラウド環境等を対象としたＤＲでは、災害等の発生時に災対サイトに移行される本番サイトの業務、および本番サイトの業務を稼働するために停止される災対サイトの業務が、事前に定義される。災害等が発生した場合には、事前の定義に従って、業務の切替えや停止が実行される。
特開２０１３−１１７８８９号公報 特開２０１３−０５８１２６号公報 特開２０１１−１９７９８９号公報
しかしながら、クラウド環境等のコンピュータシステムでは、業務構成が繰り返し変更され、リソース使用量が頻繁に変動する。したがって、災害等が発生した場合には、事前の定義に従って、業務の切替えや停止が実行されても、災対サイトでのリソース不足や無駄な業務の停止を回避できない場合が生じる。例えば、本番サイトのリソース使用量が増加した場合、災対サイトのリソース空き容量が減少した場合、または各業務の負荷が上がった場合に、災対サイトにおけるリソースが不足する可能性がある。一方、本番サイトのリソース使用量が減少した場合、または災対サイトのリソース空き容量が増加した場合には、災対サイトで継続可能な業務まで停止される可能性がある。
本発明の一態様は、運用サイトから災対サイトに業務を移行する場合の災対サイトでのリソース不足を回避し、災対サイトのリソースを有効活用する管理装置、情報処理システム及び管理プログラムを提供することを目的とする。
本発明の態様の一つは、第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および第２サイトの情報処理装置において稼働され
る１または複数の第２サイトの処理のリソース使用量を収集する収集部と、収集部により収集された第１サイトの各処理のリソース使用量および第２サイトの各処理のリソース使用量の変動に応じて、第２サイトの処理のいずれか１つ以上を停止すること、および第２サイトの処理のいずれか１つ以上に対する割当てリソースを削減することの少なくとも一方を、リソース制御情報として定義するリソース制御部と、を備える管理装置である。
開示の管理装置、情報処理システム及び管理プログラムによれば、運用サイトから災対サイトに業務を移行する場合の災対サイトでのリソース不足を回避し、災対サイトのリソースを有効活用することができる。
クラウド環境を対象としたＤＲソリューションの例を示す図である。 災害等の発生時に復旧シナリオに定義された動作が実行される例を示す図である。 情報処理システムの一例を示す図である。 管理装置のハードウェア構成の一例を示す図である。 管理装置の機能構成の一例を示す図である。 管理装置が収集する管理情報の例を示す図である。 復旧シナリオの再定義の要否を判定する例を示す図である。 災対サイトの空き容量に余裕がある場合に、各業務から不足分のリソースを供出する例を示す図である。 災対サイトの空き容量に余裕がある場合に、他の業務よりもリソース使用率が高い業務を停止する例を示す図である。 災対サイトの空き容量に余裕がない場合に、リソース使用率が所定の閾値よりも高い業務を停止する例を示す図である。 災対サイトの空き容量に余裕がない場合に、他の業務よりもリソース使用率が高い業務を停止する例を示す図である。 災対サイトの空き容量に余裕がほとんどない場合に、災対サイトの業務をいずれも停止する例を示す図である。 通常運用時に復旧シナリオを再定義する処理のフローチャートの一例である。 災害発生時に復旧シナリオに従ってサイトの切替えを実行する処理のフローチャートの一例である。 災対サイトの空き容量に余裕がある場合の、復旧シナリオの動的定義の判断フローの一例である。 災対サイトの空き容量に余裕がない場合の、復旧シナリオの動的定義の判断フローの一例である。 災対サイトの空き容量に余裕がほとんどない場合の、復旧シナリオの動的定義の判断フローの一例である。
以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
＜ＤＲソリューション＞
ＤＲソリューションは、クラウド環境等のコンピュータシステムが被災した場合等に、別のコンピュータシステムに実行環境やデータを移行させ、業務継続するための解決手段である。
図１は、クラウド環境を対象としたＤＲソリューションの例を示す図である。図１において、本番サイト２０（運用サイト）は、サイト管理マネージャ２５、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（ＳＳＤ）はコンピュータ等から取り外し可能な記録媒体としても、コンピュータ等
に固定された記録媒体としても利用可能である。
１ 情報処理システム
１０ 管理装置
１１ プロセッサ
１２ 主記憶装置
１３ 補助記憶装置
１４ 入力装置
１５ 出力装置
１６ ネットワークインタフェース
１７ バス
２０ 本番サイト
２１ 収集部
２２ リソース制御部
２３ 復旧シナリオ
２４ 移行部
２５ サイト管理マネージャ
２６ ＶＭホスト
２７ ストレージ
３０ 災対サイト
４０ 管理情報

Claims (6)

  1. 第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および第１サイトの処理が移行される第２サイトの情報処理装置において稼働される１または複数の第２サイトの処理のリソース使用量を収集する収集ステップと、
    前記収集ステップにより収集された前記第１サイトの各処理のリソース使用量の合計が前記第２サイトの空きリソース量以上となる場合であって、
    （１）前記第２サイトの各処理に対する現在の割り当てリソース量の比率で前記第２サイトの各処理に対する割り当てリソース量を削減すると前記第２サイトの各処理のいずれかのリソース量が所定の基準に達しない場合に、前記第２サイトの空きリソース量が前記第１サイトの各処理のリソース使用量の合計以上となるまで前記第２サイトの処理のいずれか１つ以上を停止し、
    （２）前記第２サイトの処理の各処理に対する現在の割り当てリソースの比率で前記第２サイトの各処理に対する割り当てリソース量を削減しても前記第２サイトの各処理のすべてのリソース量が所定の基準に達する場合に、前記第１サイトの各処理のリソース使用量の合計から前記第２サイトの空きリソース量を減算した不足値を算出し、前記第２サイトの各処理に対する割当てリソース量の比率で前記不足値を分割して割り当てた分割リソース量を前記第２サイトの各処理から削減すること、
    をリソース制御情報として定義するステップと、を定期的時点および災害の発生を検知した時点の少なくとも一方の時点で実行する定義部と、
    前記災害の発生を検知した時点で、前記定義されたリソース制御情報による処理を実行するリソース制御部と、
    を備える管理装置。
  2. 前記リソース制御部は、前記第２サイトの各処理のリソース使用量の合計に対する前記第２サイトの各処理のリソース使用量の割合であるリソース使用率を算出し、前記第２サイトの各処理のうち、前記リソース使用率が他の処理よりも高い処理を停止することを定義する、
    請求項１に記載の管理装置。
  3. 前記リソース制御部は、前記第２サイトの各処理の前記リソース使用率に応じて、前記
    第２サイトの各処理に対する割当てリソースを削減することによって前記第２サイトのいずれかの処理において割当てリソース削減後のリソース使用量が所定の基準を下回る場合には、前記第２サイトの各処理のうち、前記リソース使用率が他の処理よりも高い処理を停止することを定義する、
    請求項１または２に記載の管理装置。
  4. 前記リソース制御情報に従って、前記第２サイトの各処理に割り当てるリソース使用量を変更し、前記第１サイトの処理を前記第２サイトの情報処理装置に移行する移行部をさらに備える、
    請求項１から３のいずれか一項に記載の管理装置。
  5. 管理装置と、第１サイトの情報処理装置と、第２サイトの情報処理装置とを有する情報処理システムであって、
    前記管理装置は、
    前記第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および前記第２サイトの情報処理装置において稼働される１または複数の第２サイトの処理のリソース使用量を収集するステップと、
    前記収集部により収集された前記第１サイトの各処理のリソース使用量の合計が前記第２サイトの空きリソース量以上となる場合であって、
    （１）前記第２サイトの各処理に対する現在の割り当てリソース量の比率で前記第２サイトの各処理に対する割り当てリソース量を削減すると前記第２サイトの各処理のいずれかのリソース量が所定の基準に達しない場合に、前記第２サイトの空きリソース量が前記第１サイトの各処理のリソース使用量の合計以上となるまで前記第２サイトの処理のいずれか１つ以上を停止し、
    （２）前記第２サイトの処理の各処理に対する現在の割り当てリソースの比率で前記第２サイトの各処理に対する割り当てリソース量を削減しても前記第２サイトの各処理のすべてのリソース量が所定の基準に達する場合に、前記第１サイトの各処理のリソース使用量の合計から前記第２サイトの空きリソース量を減算した不足値を算出し、前記第２サイトの各処理に対する割当てリソース量の比率で前記不足値を分割して割り当てた分割リソース量を前記第２サイトの各処理から削減すること、
    をリソース制御情報として定義するステップと、を定期的時点および災害の発生を検知した時点の少なくとも一方の時点で実行する定義部と、
    前記災害の発生を検知した時点で、前記定義されたリソース制御情報による処理を実行するリソース制御部と、を備える、
    情報処理システム。
  6. コンピュータに、
    第１サイトの情報処理装置において稼働される１または複数の第１サイトの処理のリソース使用量、および第２サイトの情報処理装置において稼働される１または複数の第２サイトの処理のリソース使用量を収集するステップと、
    収集された前記第１サイトの各処理のリソース使用量の合計が前記第２サイトの空きリソース量以上となる場合であって、
    （１）前記第２サイトの各処理に対する現在の割り当てリソース量の比率で前記第２サイトの各処理に対する割り当てリソース量を削減すると前記第２サイトの各処理のいずれかのリソース量が所定の基準に達しない場合に、前記第２サイトの空きリソース量が前記第１サイトの各処理のリソース使用量の合計以上となるまで前記第２サイトの処理のいずれか１つ以上を停止し、
    （２）前記第２サイトの処理の各処理に対する現在の割り当てリソースの比率で前記第２サイトの各処理に対する割り当てリソース量を削減しても前記第２サイトの各処理のすべてのリソース量が所定の基準に達する場合に、前記第１サイトの各処理のリソース使用量
    の合計から前記第２サイトの空きリソース量を減算した不足値を算出し、前記第２サイトの各処理に対する割当てリソース量の比率で前記不足値を分割して割り当てた分割リソース量を前記第２サイトの各処理から削減すること、
    をリソース制御情報として定義するステップと、を定期的時点および災害の発生を検知した時点の少なくとも一方の時点で実行させ、
    前記災害の発生を検知した時点で、前記定義されたリソース制御情報による処理を実行させる、
    ための管理プログラム。
JP2015027768A 2015-02-16 2015-02-16 管理装置、情報処理システム及び管理プログラム Active JP6540072B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2015027768A JP6540072B2 (ja) 2015-02-16 2015-02-16 管理装置、情報処理システム及び管理プログラム
US15/009,876 US9946615B2 (en) 2015-02-16 2016-01-29 Management apparatus and information processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015027768A JP6540072B2 (ja) 2015-02-16 2015-02-16 管理装置、情報処理システム及び管理プログラム

Publications (2)

Publication Number Publication Date
JP2016151816A JP2016151816A (ja) 2016-08-22
JP6540072B2 true JP6540072B2 (ja) 2019-07-10

Family

ID=56621518

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015027768A Active JP6540072B2 (ja) 2015-02-16 2015-02-16 管理装置、情報処理システム及び管理プログラム

Country Status (2)

Country Link
US (1) US9946615B2 (ja)
JP (1) JP6540072B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10855515B2 (en) * 2015-10-30 2020-12-01 Netapp Inc. Implementing switchover operations between computing nodes
US10838767B2 (en) * 2016-09-12 2020-11-17 International Business Machines Corporation Distributed computing utilizing a recovery site

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005250839A (ja) * 2004-03-04 2005-09-15 Nomura Research Institute Ltd 耐障害性システム
JP2011128967A (ja) * 2009-12-18 2011-06-30 Hitachi Ltd 仮想計算機の移動方法、仮想計算機システム及びプログラム
JP2011197989A (ja) 2010-03-19 2011-10-06 Nomura Research Institute Ltd 情報処理システムの動的管理装置、動的管理システムおよび動的管理方法
JP2013012187A (ja) * 2011-06-03 2013-01-17 Panasonic Corp 負荷分散サーバシステム
JP5738133B2 (ja) 2011-09-09 2015-06-17 三菱電機株式会社 縮退処理装置、縮退処理システム、縮退処理装置の縮退処理方法および縮退処理プログラム
JP5632820B2 (ja) * 2011-12-05 2014-11-26 株式会社日立システムズ 広域分散構成変更システム
US9170849B2 (en) * 2012-01-09 2015-10-27 Microsoft Technology Licensing, Llc Migration of task to different pool of resources based on task retry count during task lease
US9483324B2 (en) * 2012-06-26 2016-11-01 Nec Corporation Program conversion device and method, process switching method, method of determining execution scheme and program storage medium therefor, processor system, and parallel execution scheme

Also Published As

Publication number Publication date
JP2016151816A (ja) 2016-08-22
US20160241450A1 (en) 2016-08-18
US9946615B2 (en) 2018-04-17

Similar Documents

Publication Publication Date Title
EP2598993B1 (en) Providing application high availability in highly-available virtual machine environments
JP4920391B2 (ja) 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム
US20120137289A1 (en) Protecting high priority workloads in a virtualized datacenter
US10333859B2 (en) Multi-tenant resource coordination method
US9317381B2 (en) Storage system and data management method
WO2014073045A1 (ja) 計算機システム、ストレージ管理計算機及びストレージ管理方法
US8392736B2 (en) Managing memory power usage
US20120131180A1 (en) Server system and method for managing the same
CN109358947B (zh) 一种虚拟机快照的实现方法及系统
JP2009252204A (ja) 計算機の運用管理システム及び運用管理方法
JP4618263B2 (ja) ソフトウェア挙動監視装置及びソフトウェア挙動監視システム
JP2014186652A (ja) データ転送装置、データ転送システム、データ転送方法及びプログラム
WO2014073046A1 (ja) 情報処理装置、プログラムおよび仮想マシン移動方法
US20180139100A1 (en) Storage-aware dynamic placement of virtual machines
JP2008257572A (ja) 論理区画に動的に資源割り当てを行うストレージシステム及びストレージシステムの論理分割方法
KR102513961B1 (ko) 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
KR20130019698A (ko) 사용자 스케줄러와 마이그레이션(Ｍｉｇｒａｔｉｏｎ)을 통한 자원 최적화 방법 및 시스템
KR20160094434A (ko) 다중-운영-체제 환경들에서 운영 체제 전환들을 위한 기술들
JP2008217575A (ja) ストレージ装置及びその構成最適化方法
US9910709B2 (en) Allocation control method and apparatus
JP6540072B2 (ja) 管理装置、情報処理システム及び管理プログラム
US20180136958A1 (en) Storage-aware dynamic placement of virtual machines
US10002173B1 (en) System and methods for dynamically adjusting between asynchronous and synchronous data replication policies in a networked virtualization environment
US10095533B1 (en) Method and apparatus for monitoring and automatically reserving computer resources for operating an application within a computer environment
JP2012216008A (ja) 仮想計算機装置及び仮想計算機装置の制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171215

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180625

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180731

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180928

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190305

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190426

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190514

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190527

R150 Certificate of patent or registration of utility model

Ref document number: 6540072

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150