JP2018169920A - 管理装置、管理方法及び管理プログラム - Google Patents

Abstract

【課題】情報処理環境での管理機構の復旧を短時間で行うこと。【解決手段】情報取得部３４が、サービスデーモン５からステータス情報を取得する通信を行うとともに、サービスＶＭ２及びクローンと相互通信を行う。そして、ログ処理部３２が、サービスデーモン５との通信の状態、サービスＶＭ２との通信の状態及びクローンとの相互通信の状態に基づいて問題箇所の特定に用いる項目の状態を特定する。そして、情報取得部３４が、問題箇所の特定に用いる項目についてクローンが特定した状態をクローンから取得する。そして、問題箇所特定部３３ａが、問題箇所の特定に用いる項目についてログ処理部３２が特定した状態と情報取得部３４がクローンから取得した状態に基づいて、問題箇所がサービスデーモン５、サービスＶＭ２又は管理マネージャー３のいずれであるかを特定する。そして、復旧部３３ｂが、問題箇所に対応する復旧動作を行う。【選択図】図２

Description

本発明は、管理装置、管理方法及び管理プログラムに関する。

近年、仮想化技術によりＣＰＵ（Central Processing Unit）、メインメモリ等のハードウェア資源を仮想化した仮想環境の利用が進んでいる。仮想環境では、ハードウェア及び仮想環境の状態を監視して管理するために、仮想環境に専用のＶＭ（Virtual Machine）としてサービスＶＭを設定して運用することが行われる。

図１０は、仮想環境での管理機構を説明するための図である。図１０に示すように、仮想環境では、仮想基盤４がハードウェア６を仮想化して提供する。サービスＶＭ９２は、仮想基盤上で動作する。サービスＶＭ９２では、管理マネージャー９３が動作する。管理マネージャー９３は、仮想基盤４で動作するサービスデーモン５からハードウェア６及び仮想環境の状態に関する情報を取得し、仮想環境の監視及び管理を行う。

なお、第１ＯＳ、第１ＯＳと異なる第２ＯＳ、第１ＯＳと第２ＯＳの間のＯＳ間通信機能を備えるマルチＯＳ制御部、第２ＯＳ上で動作する障害監視モニタを搭載する計算機において、障害監視モニタがＯＳ間通信機能を介して第１ＯＳの障害を監視する技術がある。ここで、ＯＳは、オペレーティングシステム（Operating System）である。この技術によれば、専用のハードウェアを追加することなくＯＳの障害を監視することができる。

また、第１ＡＰがＶＭを起動後、ＶＭ上で動作する第２ＡＰを起動して第２ＡＰの動作を監視し、第２ＡＰの動作異常を検出すると、ＶＭを別のＶＭに切替え、切替後のＶＭ上にて第２ＡＰを再起動することで第２ＡＰを復旧する技術がある。ここで、ＡＰはアプリケーションプログラム（Application Program）である。この技術によれば、現ＯＳと異なるＯＳ環境下で第２ＡＰを動作させることにより、第２ＡＰが動作しているＯＳが異常動作しても監視を行うことができる。

特開２００１−１０１０３３号公報 特開２００６−２６８２７７号公報

図１０に示した管理機構において、ハードウェア６の状態表示ができない等の状況が発生した場合、サービスＶＭ９２の側に原因があるのかサービスデーモン５の側に原因があるのかの特定に手間取り、管理機構の復旧に時間がかかるという問題がある。

本発明は、１つの側面では、情報処理環境での管理機構の復旧を短時間で行うことを目的とする。

１つの態様では、管理装置は、通信部と第１特定部と取得部と第２特定部と復旧部とを有する。通信部は、自身が動作する基盤の状態情報を取得する通信を行うとともに、自身と同様の機能を有し基盤で動作するクローンと相互通信を行う。第１特定部は、基盤との通信状態、基盤の状態情報及びクローンとの通信状態に基づいて、問題箇所の特定に用いる項目の状態を特定する。取得部は、クローンが基盤の状態情報及び相互通信の通信状態に基づいて項目について特定した状態をクローンから取得する。第２特定部は、第１特定部が項目について特定した状態と取得部が項目について取得した状態とに基づいて、問題箇所が基盤の状態情報を収集する機能部、クローン又は自身のいずれであるかを特定する。復旧部は、第２特定部により特定された問題箇所に対応する復旧動作を行う。

１つの側面では、本発明は、情報処理環境での管理機構の復旧を短時間で行うことができる。

図１は、実施例に係る管理システムによる管理機構の仕組みを説明するための図である。 図２は、管理マネージャーの機能構成を示す図である。 図３Ａは、サービスデーモンに問題ありと判定する方法を説明するための図である。 図３Ｂは、サービスＶＭに問題ありと判定する方法を説明するための図である。 図３Ｃは、管理マネージャーに問題ありと判定する方法を説明するための図である。 図４は、復旧動作を説明するための図である。 図５は、仮想環境の負荷変動に応じた対応を説明するための図である。 図６は、管理マネージャーによる処理のフローを示すフローチャートである。 図７は、管理マネージャー、サービスＶＭ及びサービスデーモンのステータスを用いた問題箇所の特定を説明するための図である。 図８は、スタンバイ側とアクティブ側の２者間の関係に基づいて問題箇所を特定する処理のフローを示すフローチャートである。 図９は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。 図１０は、仮想環境での管理機構を説明するための図である。

以下に、本願の開示する管理装置、管理方法及び管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例に係る管理システムによる管理機構の仕組みについて説明する。図１は、実施例に係る管理システムによる管理機構の仕組みを説明するための図である。図１に示すように、実施例に係る管理システム１では、仮想基盤４でサービスＶＭ（Ａ）とサービスＶＭ（Ｂ）で表される２つのサービスＶＭ２が動作する。

サービスＶＭ２は、ハードウェア６及び仮想環境の状態を監視して管理するための専用のＶＭである。サービスＶＭ（Ａ）では、管理マネージャー（Ａ）で表される管理マネージャー３が動作する。管理マネージャー３は、仮想基盤４で動作するサービスデーモン５からハードウェア６及び仮想環境のステータス（状態）に関する情報を取得し、仮想環境の監視及び管理を行う。サービスＶＭ（Ｂ）は、サービスＶＭ（Ａ）のクローンである。管理マネージャー（Ｂ）は、管理マネージャー（Ａ）のクローンである。

管理マネージャー３は、ハード管理部７を介してＣＰＵ、メインメモリ、ディスク装置等のハードウェア６のステータスを収集する。

サービスＶＭ２では、基準サービス部２３が動作する。基準サービス部２３は、サービスデーモン５の応答を模擬する。管理マネージャー３は、サービスデーモン５の代わりに基準サービス部２３と通信することによって、管理マネージャー３からサービスＶＭ２への通信経路が正常に動作しているか否かを確認することができる。

管理マネージャー３は、他の管理マネージャー３とハートビート通信を行うことにより、相互に状態を確認する。また、管理マネージャー３は、他の管理マネージャー３から監視情報を取得する。また、管理マネージャー３は、定期的に監視状況を管理者８に通報する。

このように、管理システム１は、元のサービスＶＭ２とクローンのサービスＶＭ２との組み合わせで、同じ経路による監視の仕組みを２つ備え、それぞれがサービスデーモン５及びハード管理部７と通信し、管理者８に監視状況を通報する。そして、管理システム１は、元のサービスＶＭ２、クローンのサービスＶＭ２、サービスデーモン５、ハード管理部７、管理者８の間の通信状態に基づいて、サービスＶＭ２、管理マネージャー３及びサービスデーモン５の状態を監視する。

次に、管理マネージャー３の機能構成について説明する。図２は、管理マネージャー３の機能構成を示す図である。図２に示すように、管理マネージャー３は、ログ記憶部３１と、ログ処理部３２と、情報解析部３３と、情報取得部３４と、通報部３５とを有する。

ログ記憶部３１は、サービスデーモン５から取得したステータス情報及びハード管理部７から取得したハードウェア情報をログとして記憶する。

ログ処理部３２は、ログ記憶部３１が記憶するログを処理して、問題箇所の特定に用いる項目の状態を特定する。問題箇所の特定に用いる項目には、サービスデーモン通信、管理マネージャー通信、サービスＶＭ通信、ステータス情報、通報サービス及びハードウェア情報がある。

サービスデーモン通信は、サービスデーモン５との通信であり、状態として、サービスデーモン５との通信ができる「接続可」と、サービスデーモン５との通信ができない「接続不可」とがある。

管理マネージャー通信は、他の管理マネージャー３との通信であり、状態として、他の管理マネージャー３との通信ができる「接続可」と、他の管理マネージャー３との通信ができない「接続不可」とがある。

サービスＶＭ通信は、サービスＶＭ２との通信であり、状態として、サービスＶＭ２との通信ができる「応答あり」と、サービスＶＭ２との通信ができない「応答なし」とがある。

ステータス情報は、サービスデーモン５から取得する情報であり、状態として、直近の情報が得られた「直近情報あり」と、直近の情報が得られなかった「直近情報なし」とがある。

通報サービスは、管理者８へ通報するサービスであり、状態として、管理者８への通報が行われている「通報済」と、管理者８への通報が行われていない「通報なし」とがある。

ハードウェア情報は、ハード管理部７から取得する情報であり、状態として、ハードウェア６に問題がある「問題あり」と、ハードウェア６に問題がない「問題なし」とがある。

情報解析部３３は、ログ処理部３２により特定された項目状態に基づいて、問題箇所を特定し、特定した問題に対応する復旧動作を行う。情報解析部３３は、問題箇所特定部３３ａと、復旧部３３ｂと、負荷対応部３３ｃとを有する。

問題箇所特定部３３ａは、ログ処理部３２により特定された項目状態とクローンの管理マネージャー３から受け取ったクローンの監視情報に基づいて、問題箇所を特定する。ここで、クローンの監視情報は、クローンの管理マネージャー３が特定した項目状態の情報である。

図３Ａ〜図３Ｃは、問題箇所を特定する方法を説明するための図である。図３Ａは、サービスデーモン５に問題ありと判定する方法を説明するための図であり、図３Ｂは、サービスＶＭ２に問題ありと判定する方法を説明するための図であり、図３Ｃは、管理マネージャー３に問題ありと判定する方法を説明するための図である。

なお、図３Ａ〜図３Ｃにおいて、監視管理系統Ａは、管理マネージャー（Ａ）による各項目の状態の特定結果を示し、監視管理系統Ｂは、管理マネージャー（Ｂ）による各項目の状態の特定結果を示す。また、判定は、項目について特定された状態を示す。監視管理系統Ａか監視管理系統Ｂのいずれかで状態の特定結果が異常（×）である場合に、判定は異常（×）であり、監視管理系統Ａと監視管理系統Ｂの両方で状態の特定結果が正常（○）である場合に、判定は正常（○）である。

図３Ａでは、サービスデーモン通信は「接続不可」（×）であり、管理マネージャー通信は「接続可」（○）であり、サービスＶＭ通信は、「応答あり」（○）であり、ステータス情報は「直近情報なし」（×）であり、通報サービスは「通報済」（○）である。また、ハードウェア情報は「問題なし」（○）である。すなわち、直近情報が得られず、サービスデーモン５との通信ができず、管理マネージャー３の間では通信できることから、サービスデーモン５に問題ありと特定される。

図３Ｂでは、サービスデーモン通信は「接続可」（○）であり、管理マネージャー通信は監視管理系統Ａで「接続可」（○）であり、監視管理系統Ｂで「接続不可」（×）である。また、サービスＶＭ通信は、監視管理系統Ａで「応答あり」（○）であり、監視管理系統Ｂで「応答なし」（×）であり、ステータス情報は「直近情報あり」（○）である。また、通報サービスは「通報済」（○）であり、ハードウェア情報は「問題なし」（○）である。すなわち、監視管理系統ＡではサービスＶＭ通信及び管理マネージャー通信ができ、監視管理系統ＢではサービスＶＭ通信及び管理マネージャー通信ができないことから、サービスＶＭ（Ｂ）に問題ありと特定される。

図３Ｃでは、サービスデーモン通信は「接続可」（○）であり、管理マネージャー通信は「接続不可」（×）であり、サービスＶＭ通信は、「応答あり」（○）である。また、ステータス情報は、監視管理系統Ａで「直近情報なし」（×）であり、監視管理系統Ｂで「直近情報あり」（○）であり、通報サービスは、監視管理系統Ａで「通報なし」（×）であり、監視管理系統Ｂで「通報済」（○）である。また、ハードウェア情報は「問題なし」（○）である。すなわち、監視管理系統Ａで、直近情報が得られず、管理者８への通報がなく、管理マネージャー通信に問題があることから、管理マネージャー（Ａ）に問題ありと特定される。

復旧部３３ｂは、問題箇所特定部３３ａにより特定された問題箇所に応じた復旧動作を行う。図４は、復旧動作を説明するための図である。図４は、サービスＶＭ（Ａ）、サービスＶＭ（Ｂ）、サービスデーモン５のそれぞれに問題がある場合（×）と問題がない場合（○）の組合せ（ステータスパターン）に対応する復旧動作を示す。

なお、管理マネージャー（Ａ）に問題がある場合の復旧動作は、サービスＶＭ（Ａ）に問題がある場合と同じであり、管理マネージャー（Ｂ）に問題がある場合の復旧動作は、サービスＶＭ（Ｂ）に問題がある場合と同じである。

図４に示すように、サービスＶＭ（Ａ）、サービスＶＭ（Ｂ）、サービスデーモン５のいずれにも問題がない場合には、復旧部３３ｂは何もしない。また、サービスデーモン５だけに問題がある場合には、復旧部３３ｂは、サービスデーモン５を再起動する。また、復旧部３３ｂは、サービスＶＭ（Ｂ）だけに問題がある場合には、サービスＶＭ（Ｂ）を再起動し、サービスＶＭ（Ａ）だけに問題がある場合には、サービスＶＭ（Ａ）を再起動する。

また、サービスデーモン５とサービスＶＭ（Ｂ）に問題がある場合には、復旧部３３ｂは、サービスデーモン５とサービスＶＭ（Ｂ）を再起動する。また、サービスデーモン５とサービスＶＭ（Ａ）に問題がある場合には、復旧部３３ｂは、サービスデーモン５とサービスＶＭ（Ａ）を再起動する。

また、サービスＶＭ（Ａ）とサービスＶＭ（Ｂ）の両方に問題があり、サービスデーモン５に問題がない場合には、復旧部３３ｂではなく、外部、例えば管理者８に通報し、外部からサービスＶＭ（Ａ）とサービスＶＭ（Ｂ）の再起動を行う。また、サービスＶＭ（Ａ）、サービスＶＭ（Ｂ）、サービスデーモン５の全てに問題がある場合には、外部、例えば管理者８に通報し、外部からサービスＶＭ（Ａ）、サービスＶＭ（Ｂ）、サービスデーモン５の再起動を行う。

負荷対応部３３ｃは、仮想環境の負荷変動に応じた対応を行う。サービスＶＭ２は、仮想基盤上で動作するので、仮想基盤上で動作する業務ＶＭに影響を与えることは望ましくない。このため、負荷対応部３３ｃは、仮想環境の負荷が高い場合には、クローンのサービスＶＭ２の負荷を抑えるように制御する。

図５は、仮想環境の負荷変動に応じた対応を説明するための図である。負荷対応部３３ｃは、仮想環境の負荷が所定の第１閾値より高い場合に、例えば、サービスデーモン５との通信周期を長期化する。あるいは、負荷対応部３３ｃは、仮想環境の負荷がより大きな第２閾値より高い場合には、クローンの動作を一定期間休止する。

情報取得部３４は、サービスＶＭ２の通信Ｉ／Ｆ部２１を介してサービスデーモン５からステータス情報を取得する。通信Ｉ／Ｆ部２１は、サービスデーモン５と通信を行うインタフェースである。また、情報取得部３４は、通信Ｉ／Ｆ部２１を介して基準サービス部２３と通信する。

また、情報取得部３４は、サービスＶＭ２のステータス監視部２２を介して他の管理マネージャー３から問題箇所の特定に用いられる項目の状態についての情報を取得する。ステータス監視部２２は、他のサービスＶＭ２のステータス監視部２２と相互に状態を監視するとともに、監視情報を相互に交換する。

通報部３５は、サービスデーモン５から取得したハードウェア６及び仮想環境のステータスに関する情報に基づいて、管理者８への通報を行う。管理者８への通報は、ＳＮＭＰ(Simple Network Management Protocol)トラップ又はメールにより行われる。

次に、管理マネージャー３による処理のフローについて説明する。図６は、管理マネージャー３による処理のフローを示すフローチャートである。図６に示すように、管理マネージャー３は、サービスデーモン５、クローンの管理マネージャー３、サービスＶＭ２、ハード管理部７と所定の周期で通信する（ステップＳ１）。

管理マネージャー３は、サービスデーモン５との通信では、ハードウェア６及び仮想環境の状態に関する情報を取得する。また、管理マネージャー３は、クローンの管理マネージャー３と接続が可能であるかを確認するために通信を行う。また、管理マネージャー３は、サービスＶＭ２と通信が可能であるかを確認するために通信を行う。また、管理マネージャー３は、ハード管理部７との通信では、ハードウェア６の情報を取得する。なお、管理マネージャー３は、サービスデーモン５、クローンの管理マネージャー３、サービスＶＭ２、ハード管理部７との通信において、周期が異なってもよい。

そして、管理マネージャー３は、取得した情報、情報の取得状況及び通信状態に基づいて、問題箇所の特定に用いる項目の状態を特定する（ステップＳ２）。ここで、問題箇所の特定に用いる項目には、サービスデーモン通信、管理マネージャー通信、サービスＶＭ通信、ステータス情報、通報サービス及びハードウェア情報がある。

そして、管理マネージャー３は、クローンの管理マネージャー３から問題箇所の特定に用いる項目の状態を取得する（ステップＳ３）。クローンの管理マネージャー３は、問題箇所の特定に用いる項目の状態を特定し、特定した項目状態を送信する。

そして、管理マネージャー３は、特定した項目状態とクローンの管理マネージャー３から取得した項目状態とに基づいて問題箇所を特定する（ステップＳ４）。そして、管理マネージャー３は、問題箇所に対応する復旧動作を特定し（ステップＳ５）、特定した復旧動作を実行する（ステップＳ６）。

上述してきたように、実施例では、情報取得部３４が、サービスデーモン５からステータス情報を取得する通信を行うとともに、サービスＶＭ２及びクローンと相互通信を行う。そして、ログ処理部３２が、サービスデーモン５との通信の状態、サービスＶＭ２との通信の状態及びクローンとの相互通信の状態に基づいて問題箇所の特定に用いる項目の状態を特定する。そして、情報取得部３４が、問題箇所の特定に用いる項目についてクローンが特定した状態をクローンから取得する。そして、問題箇所特定部３３ａが、問題箇所の特定に用いる項目についてログ処理部３２が特定した状態と情報取得部３４がクローンから取得した状態に基づいて、問題箇所がサービスデーモン５、サービスＶＭ２又は管理マネージャー３のいずれであるかを特定する。そして、復旧部３３ｂが、問題箇所特定部３３ａにより特定された問題箇所に対応する復旧動作を行う。したがって、管理マネージャー３は、仮想環境での管理機構の復旧を短時間で行うことができる。

また、実施例では、負荷対応部３３ｃが、仮想基盤４の負荷状況に基づいてサービスデーモン５との通信の周期の変更又はクローンの休止を行うので、管理マネージャー３は、仮想基盤４で動作する業務ＶＭへの悪影響を抑えることができる。

また、実施例では、基準サービス部２３が、サービスデーモン５からの応答を模擬するので、管理マネージャー３は、サービスデーモン５との通信に問題があるのかサービスＶＭ２の中の通信に問題があるのかを特定することができる。

ところで、上記実施例では、管理マネージャー３は、問題箇所の特定に用いる項目として、サービスデーモン通信、管理マネージャー通信、サービスＶＭ通信、ステータス情報、通報サービス及びハードウェア情報を用いた。しかしながら、管理マネージャー３は、より少ない情報を用いて問題箇所を特定することもできる。

図７は、管理マネージャー３、サービスＶＭ２及びサービスデーモン５のステータスを用いた問題箇所の特定を説明するための図である。図７は、管理マネージャー３、サービスＶＭ２及びサービスデーモン５について、監視管理系統Ａと監視管理系統Ｂのそれぞれのステータスを示す。ステータスは、正常を示す「ＯＫ」又は異常を示す「ＮＧ」である。

管理マネージャー３は、クローンの管理マネージャー３との定期的通信のログメッセージを抽出し、抽出したログメッセージに基づいて管理マネージャー３のステータスが正常か異常かを特定する。また、管理マネージャー３は、サービスＶＭ２への定期的通信のログメッセージを抽出し、抽出したログメッセージに基づいてサービスＶＭ２のステータスが正常か異常かを特定する。また、管理マネージャー３は、サービスデーモン５への定期的通信のログメッセージを抽出し、抽出したログメッセージに基づいてサービスデーモン５のステータスが正常か異常かを特定する。

そして、管理マネージャー３は、クローンの管理マネージャー３から、クローンの管理マネージャー３が特定した管理マネージャー３、サービスＶＭ２及びサービスデーモン５のステータスを取得する。

そして、管理マネージャー３は、管理マネージャー３、サービスＶＭ２及びサービスデーモン５について、自身が特定したステータスとクローンが特定したステータスに基づいて、問題箇所を特定する。例えば、図７（ａ）では、両系統ともサービスデーモン５に問題ありと特定しているので、管理マネージャー３は、問題箇所をサービスデーモン５と特定する。

また、図７（ｂ）では、サービスＶＭ２及びサービスデーモン５との通信には問題がなく、クローンの管理マネージャー３との通信に問題があるので、問題箇所をクローンの管理マネージャー３と特定する。また、図７（ｃ）では、サービスデーモン５との通信には問題がなく、クローンの管理マネージャー３との通信、及び、クローンの管理マネージャー３とサービスＶＭ２との間の通信に問題があるので、問題箇所をクローンのサービスＶＭ２と特定する。

このように、管理マネージャー３は、管理マネージャー３、サービスＶＭ２及びサービスデーモン５について、自身が特定したステータスとクローンが特定したステータスに基づいて、問題箇所を特定するので、簡単に問題箇所を特定することができる。

また、２つの監視管理系統を運用中のアクティブ監視管理系統とスタンバイの状態にあるスタンバイ監視管理系統として問題箇所を特定してもよい。図８は、スタンバイ側とアクティブ側の２者間の関係に基づいて問題箇所を特定する処理のフローを示すフローチャートである。図８（ａ）は、スタンバイ側の処理のフローを示し、図８（ｂ）は、アクティブ側の処理のフローを示す。

図８に示すように、スタンバイ側の管理マネージャー３は、スタンバイ側のアクションを管理者８に定期的に通報する（ステップＳ１０）。そして、スタンバイ側の管理マネージャー３は、サービスＶＭアクティブとサービスＶＭスタンバイ間に問題ありか否かを判定する（ステップＳ１１）。ここで、サービスＶＭアクティブとは、運用中のサービスＶＭ２であり、サービスＶＭスタンバイとは、スタンバイの状態にあるサービスＶＭ２である。

そして、スタンバイ側の管理マネージャー３は、サービスＶＭアクティブとサービスＶＭスタンバイ間に問題がない場合には、サービスＶＭスタンバイとサービスデーモン５間に問題ありか否かを判定する（ステップＳ１２）。そして、サービスＶＭスタンバイとサービスデーモン５間に問題がない場合には、スタンバイ側の管理マネージャー３は、ステップＳ１０に戻る。

一方、サービスＶＭスタンバイとサービスデーモン５間に問題ありの場合には、スタンバイ側の管理マネージャー３は、サービスデーモン５に問題があると判定し、サービスデーモン５を再起動する（ステップＳ１３）。

また、サービスＶＭアクティブとサービスＶＭスタンバイ間に問題ありの場合には、スタンバイ側の管理マネージャー３は、サービスＶＭスタンバイとサービスデーモン５間に問題ありか否かを判定する（ステップＳ１４）。そして、サービスＶＭスタンバイとサービスデーモン５間に問題ありと判定した場合には、スタンバイ側の管理マネージャー３は、サービスＶＭアクティブとサービスデーモン５に問題ありと判定する。そして、スタンバイ側の管理マネージャー３は、サービスデーモン５を再起動し（ステップＳ１５）、スタンバイとアクティブの切り替えを行い（ステップＳ１６）、スタンバイに切り替えられたサービスＶＭ２を再起動する（ステップＳ１７）。

また、ステップＳ１４において、サービスＶＭスタンバイとサービスデーモン５間に問題はないと判定した場合には、スタンバイ側の管理マネージャー３は、サービスＶＭアクティブに問題ありと判定する。そして、スタンバイ側の管理マネージャー３は、スタンバイとアクティブの切り替えを行い（ステップＳ１６）、スタンバイに切り替えられたサービスＶＭ２を再起動する（ステップＳ１７）。

また、アクティブ側の管理マネージャー３は、サービスＶＭアクティブとサービスＶＭスタンバイ間に問題ありか否かを判定し（ステップＳ２１）、問題がない場合には、ステップＳ２１を再度実行する。一方、サービスＶＭアクティブとサービスＶＭスタンバイ間に問題ありの場合には、アクティブ側の管理マネージャー３は、スタンバイ側サービスＶＭを再起動する（ステップＳ２２）。

このように、サービスＶＭアクティブとサービスＶＭスタンバイ間、及び、サービスＶＭスタンバイとサービスデーモン５間に問題があるかを判定することで、スタンバイ側の管理マネージャー３は、簡単に問題箇所を特定することができる。

なお、実施例では、管理マネージャー３について説明したが、管理マネージャー３が有する構成をソフトウェアによって実現することで、同様の機能を有する管理プログラムを得ることができる。そこで、管理プログラムを実行するコンピュータについて説明する。

図９は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。図９に示すように、コンピュータ５０は、メインメモリ５１と、ＣＰＵ５２と、ＬＡＮ（Local Area Network）インタフェース５３と、ＨＤＤ（Hard Disk Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input Output）５５と、ＤＶＩ（Digital Visual Interface）５６と、ＯＤＤ（Optical Disk Drive）５７とを有する。

メインメモリ５１は、プログラムやプログラムの実行途中結果などを記憶するメモリである。ＣＰＵ５２は、メインメモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。

ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納する記憶装置であり、スーパーＩＯ５５は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。

ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low Pin Count）によりＣＰＵ５２に接続される。

そして、コンピュータ５０において実行される管理プログラムは、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記憶され、ＯＤＤ５７によって記憶媒体から読み出されてコンピュータ５０にインストールされる。あるいは、管理プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされた管理プログラムは、ＨＤＤ５４に記憶され、メインメモリ５１に読み出されてＣＰＵ５２によって実行される。

また、実施例では、１つのクローンを用いる場合について説明したが、本発明はこれに限定されるものではなく、２つ以上のクローンを用いる場合にも同様に適用することができる。

また、実施例では、仮想環境における問題箇所を特定する場合について説明したが、本発明はこれに限定されるものではなく、仮想化技術を用いない実環境における問題箇所を特定する場合にも同様に適用することができる。

１ 管理システム
２ サービスＶＭ
３ 管理マネージャー
４ 仮想基盤
５ サービスデーモン
６ ハードウェア
７ ハード管理部
８ 管理者
２１ 通信Ｉ／Ｆ部
２２ ステータス監視部
２３ 基準サービス部
３１ ログ記憶部
３２ ログ処理部
３３ 情報解析部
３３ａ 問題箇所特定部
３３ｂ 復旧部
３３ｃ 負荷対応部
３４ 情報取得部
３５ 通報部
５０ コンピュータ
５１ メインメモリ
５２ ＣＰＵ
５３ ＬＡＮインタフェース
５４ ＨＤＤ
５５ スーパーＩＯ
５６ ＤＶＩ
５７ ＯＤＤ

Claims (5)

1. 自身が動作する基盤の状態情報を取得する通信を行うとともに、自身と同様の機能を有し前記基盤で動作するクローンと相互通信を行う通信部と、
   前記基盤との通信状態、前記基盤の状態情報及び前記クローンとの通信状態に基づいて、問題箇所の特定に用いる項目の状態を特定する第１特定部と、
   前記クローンが前記基盤の状態情報及び前記相互通信の通信状態に基づいて前記項目について特定した状態を前記クローンから取得する取得部と、
   前記第１特定部が前記項目について特定した状態と前記取得部が前記項目について取得した状態とに基づいて、前記問題箇所が前記基盤の状態情報を収集する機能部、前記クローン又は自身のいずれであるかを特定する第２特定部と、
   前記第２特定部により特定された問題箇所に対応する復旧動作を行う復旧部と
   を有することを特徴とする管理装置。
2. 前記基盤の負荷の状況に応じて前記基盤の状態情報の取得周期の変更又は前記クローンの休止を行う負荷対応部をさらに有することを特徴とする請求項１に記載の管理装置。
3. 前記第１特定部は、前記基盤の状態情報を収集する機能部からの応答を模擬する模擬部を利用して、前記項目の状態を特定することを特徴とする請求項１又は２に記載の管理装置。
4. コンピュータが、
   自身が動作する基盤の状態情報を取得する通信を行うとともに、自身と同様の機能を有し前記基盤で動作するクローンと相互通信を行い、
   前記基盤との通信状態、前記基盤の状態情報及び前記クローンとの通信状態に基づいて、問題箇所の特定に用いる項目の状態を特定し、
   前記クローンが前記基盤の状態情報及び前記相互通信の通信状態に基づいて前記項目について特定した状態を前記クローンから取得し、
   前記項目について特定した状態と前記項目について前記クローンから取得した状態とに基づいて、前記問題箇所が前記基盤の状態情報を収集する機能部、前記クローン又は自身のいずれであるかを特定し、
   特定した問題箇所に対応する復旧動作を行う
   処理を実行することを特徴とする管理方法。
5. コンピュータに、
   自身が動作する基盤の状態情報を取得する通信を行うとともに、自身と同様の機能を有し前記基盤で動作するクローンと相互通信を行い、
   前記基盤との通信状態、前記基盤の状態情報及び前記クローンとの通信状態に基づいて、問題箇所の特定に用いる項目の状態を特定し、
   前記クローンが前記基盤の状態情報及び前記相互通信の通信状態に基づいて前記項目について特定した状態を前記クローンから取得し、
   前記項目について特定した状態と前記項目について前記クローンから取得した状態とに基づいて、前記問題箇所が前記基盤の状態情報を収集する機能部、前記クローン又は自身のいずれであるかを特定し、
   特定した問題箇所に対応する復旧動作を行う
   処理を実行させることを特徴とする管理プログラム。

Images