(57)【要約】【課題】ホストＯＳから下位のホスト部とハイパーバイザから上位のゲスト部とを分離し易くする。【解決手段】ゲストＯＳ４０の上で動作する障害監視・復旧機能部（ゲスト）５０において、ハイパーバイザ３０のウォッチドッグタイマーによるゲストＯＳ４０の障害監視及び再起動を監視する生存通知機能部５０１と、少なくともウォッチドッグタイマーによるゲストＯＳ４０の再起動に基づきゲストＯＳ４０の再起動回数を管理するゲストＯＳ再起動回数管理機能部５０２と、ゲストＯＳ４０の再起動回数が閾値を超える場合、ホストＯＳ２０の汎用インタフェース（ｔｅｌｎｅｔ、ＳＳＨ等）を用いてホストＯＳ２０又はハイパーバイザ３０を再起動する復旧方法判断機能部５０３と、を備える。【選択図】図１
2018041211.tif 000002
【特許請求の範囲】
【請求項１】
ホストＯＳの上でハイパーバイザを介して動作するゲストＯＳの障害を監視・復旧する障害監視復旧装置において、
前記ゲストＯＳの上で動作し、前記ハイパーバイザのウォッチドッグタイマーによる前記ゲストＯＳの障害監視及び再起動を監視する監視部と、
前記ゲストＯＳの上で動作し、少なくとも前記ウォッチドッグタイマーによる前記ゲストＯＳの再起動に基づき前記ゲストＯＳの再起動回数を管理する管理部と、
前記ゲストＯＳの上で動作し、前記ゲストＯＳの再起動回数が閾値を超える場合、前記ホストＯＳのインタフェースを用いて前記ホストＯＳ又は前記ハイパーバイザを再起動する再起動部と、
を備えることを特徴とする障害監視復旧装置。
【請求項２】
ホストＯＳの上でハイパーバイザを介して動作するゲストＯＳの障害を監視・復旧する障害監視復旧装置で行う障害監視復旧方法において、
前記障害監視復旧装置は、ゲストＯＳの上で動作し、
前記ハイパーバイザのウォッチドッグタイマーによる前記ゲストＯＳの障害監視及び再起動を監視するステップと、
少なくとも前記ウォッチドッグタイマーによる前記ゲストＯＳの再起動に基づき前記ゲストＯＳの再起動回数を管理するステップと、
前記ゲストＯＳの再起動回数が閾値を超える場合、前記ホストＯＳのインタフェースを用いて前記ホストＯＳ又は前記ハイパーバイザを再起動するステップと、
を実行することを特徴とする障害監視復旧方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳの障害を監視・復旧する技術に関する。
【背景技術】
【０００２】
従来、サーバの備える伝統的なシステム構成は、ハードウェア、ＯＳ（Operating System）、アプリケーションをその順序で階層化させた構成が採用されている。一方、現在では、高可用が要求されるサーバでも、故障部品の交換を簡便に行うため、サーバのシステム構成を仮想化環境で構築する傾向にある。
【０００３】
具体的には、図３の右側に示すように、従来のＯＳ（ホストＯＳ）の上でハイパーバイザ（Hypervisor）を稼働させ、ハイパーバイザ上でホストＯＳとは別種又は同種のＯＳ（ゲストＯＳ）を１つ以上動作させるようにする。これにより、ホストＯＳから下位のホスト部とハイパーバイザから上位のゲスト部とを分離可能とする。そして、ホスト部とゲスト部を分離することにより、ゲストＯＳ上のアプリケーションにおける機能動作が、ハードウェア変更の影響を受けなくなる。これにより、例えばハードウェアベンダによる保守サポート終了を迎える前に、ゲストＯＳ上のアプリケーション動作に対する機能検証を再度行わなくても、それまでとは異なるハードウェアへの交換を実施できる等、故障部品の交換サポートを柔軟に行うことができるようになる。
【０００４】
上述した仮想化環境で行われる従来の障害監視・復旧方法について説明する。通常、仮想化環境では、障害監視・復旧機能部（ホスト）をホストＯＳの上で動作させると共に、別の障害監視・復旧機能部（ゲスト）をゲストＯＳの上でも動作させておき、サーバ内の任意の箇所で発生した障害に対していずれかの障害監視・復旧機能部が動作する。一般的には、アプリケーションの障害に対しては、障害監視・復旧機能部（ゲスト）が監視・復旧処理を行い、ハードウェアの障害に対しては、障害監視・復旧機能部（ホスト）が監視・復旧処理を行う（非特許文献１参照）。
【０００５】
ここで、図４を参照しながら、ゲストＯＳの障害に対する従来の監視・復旧方法について説明する。ゲストＯＳがフリーズすると、ゲストＯＳでは自身のフリーズ状態を監視できないため、ゲストＯＳより下位レイヤに位置する障害監視・復旧機能部（ホスト）により、ゲストＯＳの障害監視・復旧が行われる。
【０００６】
具体的に、障害監視・復旧機能部（ホスト）は、ゲストＯＳ障害監視機能部でゲストＯＳのフリーズ監視を行い、ゲストＯＳがフリーズした場合、ゲストＯＳ再起動機能部でゲストＯＳの再起動を実行する。また、ゲストＯＳ再起動回数管理機能部は、ゲストＯＳの再起動により保持するゲストＯＳ再起動回数を更新し、更新後のゲストＯＳ再起動回数を障害監視・復旧機能部（ゲスト）に通知する。その後、ゲストＯＳ再起動回数に基づき障害監視・復旧機能部（ゲスト）でハイパーバイザの再起動が必要と判断された場合には、障害監視・復旧機能部（ゲスト）からのハイパーバイザ再起動要求に基づき、障害監視・復旧機能部（ホスト）のＨＶ再起動機能部でハイパーバイザを再起動する。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】“Asianux Server 4 == MIRACLE LINUX V6 HAの特徴”，“自動障害復帰機能”，“サーバ自己監視機能”、ミラクル・リナックス株式会社、［online］、［平成28年8月23日検索］、＜URL: https://www.miraclelinux.com/product-service/linux-solution/axs4-ha/function＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述した通り、ゲストＯＳの障害に対する従来の監視・復旧方法は、障害監視・復旧機能部（ホスト）で、ゲストＯＳの障害監視・再起動管理及びハイパーバイザの再起動を実行していた。しかし、障害監視・復旧機能部（ホスト）は、障害監視・復旧機能部（ゲスト）と連携して動作するため、故障等によるハードウェアの変更時に、変更後のハードウェア上でも障害監視・復旧機能部（ホスト）の動作検証を行う必要があった。それゆえ、ホスト部とゲスト部との分離時には障害監視・復旧機能部（ホスト）の動作検証を行うという煩わしさを伴うという課題があった。
【０００９】
本発明は、上記事情を鑑みてなされたものであり、ホストＯＳから下位のホスト部とハイパーバイザから上位のゲスト部とを分離し易くすることを目的とする。
【課題を解決するための手段】
【００１０】
以上の課題を解決するため、請求項１に係る障害監視復旧装置は、ホストＯＳの上でハイパーバイザを介して動作するゲストＯＳの障害を監視・復旧する障害監視復旧装置において、前記ゲストＯＳの上で動作し、前記ハイパーバイザのウォッチドッグタイマーによる前記ゲストＯＳの障害監視及び再起動を監視する監視部と、前記ゲストＯＳの上で動作し、少なくとも前記ウォッチドッグタイマーによる前記ゲストＯＳの再起動に基づき前記ゲストＯＳの再起動回数を管理する管理部と、前記ゲストＯＳの上で動作し、前記ゲストＯＳの再起動回数が閾値を超える場合、前記ホストＯＳのインタフェースを用いて前記ホストＯＳ又は前記ハイパーバイザを再起動する再起動部と、を備えることを要旨とする。
【００１１】
請求項２に係る障害監視復旧方法は、ホストＯＳの上でハイパーバイザを介して動作するゲストＯＳの障害を監視・復旧する障害監視復旧装置で行う障害監視復旧方法において、前記障害監視復旧装置は、ゲストＯＳの上で動作し、前記ハイパーバイザのウォッチドッグタイマーによる前記ゲストＯＳの障害監視及び再起動を監視するステップと、少なくとも前記ウォッチドッグタイマーによる前記ゲストＯＳの再起動に基づき前記ゲストＯＳの再起動回数を管理するステップと、前記ゲストＯＳの再起動回数が閾値を超える場合、前記ホストＯＳのインタフェースを用いて前記ホストＯＳ又は前記ハイパーバイザを再起動するステップと、を実行することを要旨とする。
【発明の効果】
【００１２】
本発明によれば、ホストＯＳから下位のホスト部とハイパーバイザから上位のゲスト部とを分離し易くすることができる。
【図面の簡単な説明】
【００１３】
【図１】サーバのシステム構成を示す図である。
【図２】障害監視復旧方法の処理フローを示す図である。
【図３】仮想化環境下でのサーバのシステム構成を示す図である。
【図４】従来の障害監視復旧方法の処理フローを示す図である。
【発明を実施するための形態】
【００１４】
本発明は、ゲストＯＳの上で動作する障害監視・復旧機能部（ゲスト）で、ゲストＯＳの障害監視・再起動管理及びハイパーバイザ・ホストＯＳの再起動を行うことを特徴とする。これにより、ホストＯＳの上で従来動作していた障害監視・復旧機能部（ホスト）を不要とし、ハードウェアの変更時に障害監視・復旧機能部（ホスト）の動作検証を行う必要を排除できるので、ホストＯＳから下位のホスト部とハイパーバイザから上位のゲスト部とを分離し易くすることができる。以下、本発明を実施する一実施の形態について図面を用いて説明する。
【００１５】
図１は、本実施の形態に係るサーバ１のシステム構成を示す図である。サーバ１は、サーバ１を物理的に構成するハードウェア１０と、ハードウェア１０の機能を上位レイヤに提供するホストＯＳ２０と、ホストＯＳ２０の上で仮想化環境を提供するハイパーバイザ３０と、ハイパーバイザ３０の上で動作するゲストＯＳ４０と、ゲストＯＳ４０の上で動作する障害監視・復旧機能部（ゲスト）５０と、ゲストＯＳ４０又は障害監視・復旧機能部（ゲスト）５０の上で動作し所定のサービスを提供するサービス提供ＡＰＬ６０と、を備えて構成される。図４に示していた障害監視・復旧機能部（ゲスト）は、存在しない。
【００１６】
本実施の形態において、障害監視・復旧機能部（ゲスト）５０は、ゲストＯＳ４０の上で動作し、ゲストＯＳ４０の障害を監視・復旧する障害監視復旧装置（ゲストＯＳ４０に対するアプリケーション）として機能する。図１に示すように、障害監視・復旧機能部（ゲスト）５０は、生存通知機能部５０１と、ゲストＯＳ再起動回数管理機能部５０２と、復旧方法判断機能部５０３と、ＡＰＬ障害監視機能部５０４と、ＡＰＬ再起動機能部５０５と、ゲストＯＳ再起動機能部５０６と、を備えて構成される。
【００１７】
生存通知機能部（監視部）５０１は、ハイパーバイザ３０の仮想ウォッチドッグタイマーによるゲストＯＳ４０の障害監視及びゲストＯＳ４０の再起動を監視する機能を備える。
【００１８】
ゲストＯＳ再起動回数管理機能部（管理部）５０２は、ハイパーバイザ３０の仮想ウォッチドッグタイマーによるゲストＯＳ４０の再起動、ゲストＯＳ再起動機能部５０６によるゲストＯＳ４０の再起動に基づき、ゲストＯＳ４０の再起動回数を管理する機能を備える。具体的には、ゲストＯＳ４０が起動した直後に、保持するゲストＯＳ再起動回数を更新する。
【００１９】
復旧方法判断機能部（再起動部）５０３は、ゲストＯＳ再起動回数管理機能部５０２から取得したゲストＯＳ再起動回数に基づき、ホストＯＳ２０又はハイパーバイザ３０を再起動するかを判定する機能を備える。具体的には、ゲストＯＳ再起動回数が閾値を超える場合、ホストＯＳ２０の汎用インタフェースを用いて、ホストＯＳ２０又はハイパーバイザ３０を再起動する。
【００２０】
また、復旧方法判断機能部（再起動部）５０３は、サービス提供ＡＰＬ６０の状態及び保持するＡＰＬ再起動回数に基づき、サービス提供ＡＰＬ６０を再起動するか、ゲストＯＳ４０を再起動するかを判定する機能を備える。具体的には、監視対象であるサービス提供ＡＰＬ６０の状態が正常でない場合において、そのサービス提供ＡＰＬ６０のＡＰＬ再起動回数が閾値を超えない場合、サービス提供ＡＰＬ６０を再起動し、ＡＰＬ再起動回数が閾値を超える場合、ゲストＯＳ４０を再起動する。
【００２１】
ＡＰＬ障害監視機能部５０４は、サービス提供ＡＰＬ６０の状態を監視する機能を備える。具体的には、監視対象であるサービス提供ＡＰＬ６０が正常に動作しているか、フリーズ等により異常の状態であるか等を監視する。
【００２２】
ＡＰＬ再起動機能部５０５は、復旧方法判断機能部５０３による判定の結果に基づき、監視対象であるサービス提供ＡＰＬ６０を再起動する機能を備える。
【００２３】
ゲストＯＳ再起動機能部５０６は、復旧方法判断機能部５０３による判定の結果に基づき、ゲストＯＳ４０を再起動する機能を備える。
【００２４】
続いて、ハイパーバイザ３０について説明する。本実施の形態において、ハイパーバイザ３０は、仮想ウォッチドッグタイマーを動作させる仮想ウォッチドッグデバイス３０１を備えて構成される。仮想ウォッチドッグタイマーは、ゲストＯＳ４０の動作を監視し、ゲストＯＳ４０で規則的な操作が行われない場合（＝ゲストＯＳ４０がフリーズした場合）、ゲストＯＳ４０を正常動作に戻すためにゲストＯＳ４０をリセット（＝再起動）する。
【００２５】
次に、障害監視・復旧機能部（ゲスト）５０で行う障害監視復旧方法について説明する。図２は、障害監視復旧方法の処理フローを示す図である。
【００２６】
まず、ステップＳ１において、生存通知機能部５０１は、ハイパーバイザ３０の仮想ウォッチドッグタイマーを用いて、ゲストＯＳ４０がフリーズしているかを監視する。例えば、ハイパーバイザ３０の仮想ウォッチドッグタイマーが動作しているか否かを定期的に確認し、動作していない場合には、ゲストＯＳ４０はフリーズしていないと判定して、ゲストＯＳ４０が生存していることをサーバ１の画面又は他の管理端末へ通知する。
【００２７】
次に、ゲストＯＳ４０に障害が発生してゲストＯＳ４０がフリーズした場合、ステップＳ２において、ハイパーバイザ３０の仮想ウォッチドッグタイマーによりゲストＯＳ４０が再起動され、ステップＳ３において、障害監視・復旧機能部（ゲスト）５０が起動した後に、生存通知機能部５０１は、ゲストＯＳ４０がフリーズしていたこと、ゲストＯＳ４０が再起動したことをサーバ１の画面又は他の管理端末へ通知する。なお、ゲストＯＳ４０の起動サービス情報に登録しておくことにより、ゲストＯＳ４０の起動に伴い障害監視・復旧機能部（ゲスト）５０を自動で起動させることができる。
【００２８】
次に、ステップＳ４において、ゲストＯＳ再起動回数管理機能部５０２は、ゲストＯＳ４０の再起動直後（≒障害監視・復旧機能部（ゲスト）５０の起動直後）に、保持するゲストＯＳ再起動回数を更新する。このとき、ゲストＯＳ再起動回数を管理していない場合には、ゲストＯＳ再起動回数のファイルを生成してゲストＯＳ再起動回数を更新する。
【００２９】
次に、ステップＳ５において、復旧方法判断機能部５０３は、ゲストＯＳ再起動回数管理機能部５０２からゲストＯＳ再起動回数を取得し、取得したゲストＯＳ再起動回数が事前に設定された閾値Ｍを超えるか否かを判定する。なお、閾値Ｍについては、任意に設定可能であり、例えばホストＯＳ２０の不具合によりゲストＯＳ４０の再起動が繰り返し頻発する場合の可能性を基準に設定する。
【００３０】
ステップＳ５での判定の結果、ゲストＯＳ再起動回数が閾値Ｍを超える場合、ステップＳ６において、復旧方法判断機能部５０３は、ゲストＯＳ再起動回数を「０」にリセットし、ステップＳ７において、ホストＯＳ２０の汎用インタフェースを用いて、ホストＯＳ２０又はハイパーバイザ３０を再起動する。
【００３１】
ここで、ホストＯＳ２０の汎用インタフェースとは、例えば、ｔｅｌｎｅｔ、ＳＳＨ（Secure SHell）である。復旧方法判断機能部５０３は、その汎用インタフェースを介してホストＯＳ２０にアクセス（≒ログイン）し、ホストＯＳ２０の再起動処理を実行させることにより、ホストＯＳ２０を再起動することができる。また、ホストＯＳ２０へアクセスすることにより、ハイパーバイザ３０のみを再起動させることも可能である。
【００３２】
なお、ホストＯＳ２０を再起動するか、ハイパーバイザ３０を再起動するかは、任意であり、例えば事前に設定された内容に従う。また、ハイパーバイザ３０をホストＯＳ２０の起動サービス情報に登録しておくことにより、ホストＯＳ２０の起動に伴いハイパーバイザ３０を自動で起動させることができる。同様に、ゲストＯＳ４０をハイパーバイザ３０の起動サービス情報に登録しておくことにより、ハイパーバイザ３０の起動に伴いゲストＯＳ４０を自動で起動させることができる。
【００３３】
一方、ステップＳ５での判定の結果、ゲストＯＳ再起動回数が閾値Ｍを超えない場合、ステップＳ８において、ＡＰＬ障害監視機能部５０４は、監視対象であるサービス提供ＡＰＬ６０の状態を取得する。
【００３４】
次に、ステップＳ９において、復旧方法判断機能部５０３は、監視対象であるサービス提供ＡＰＬ６０の状態が正常であるか否かを判定する。例えば、監視対象であるサービス提供ＡＰＬ６０のプロセスが起動しているか、そのサービス提供ＡＰＬ６０が利用しているメモリの使用量が異常に大きくないか等に基づき、サービス提供ＡＰＬ６０の状態を判定する。
【００３５】
ステップＳ９での判定の結果、監視対象であるサービス提供ＡＰＬ６０の状態が正常でない場合、ステップＳ１０において、復旧方法判断機能部５０３は、保持するＡＰＬ再起動回数を参照し、該監視対象であるサービス提供ＡＰＬ６０のＡＰＬ再起動回数が事前に設定された閾値Ｎを超えるか否かを判定する。なお、閾値Ｎについても、任意に設定可能であり、例えばゲストＯＳ４０の不具合によりサービス提供ＡＰＬ６０の再起動が繰り返し頻発する場合の可能性を基準に設定する。
【００３６】
一方、ステップＳ９での判定の結果、監視対象であるサービス提供ＡＰＬ６０の状態が正常である場合、復旧方法判断機能部５０３は、特に処理を行うことなく、ステップＳ１５で一定時間経過した後に、ステップＳ８へ戻る。
【００３７】
ステップＳ１０での判定の結果、ＡＰＬ再起動回数が閾値Ｎを超える場合、ステップＳ１１において、復旧方法判断機能部５０３は、監視対象であるサービス提供ＡＰＬ６０のＡＰＬ再起動回数を「０」にリセットし、ステップＳ１２において、ゲストＯＳ再起動機能部５０６が、ゲストＯＳ４０を再起動する。
【００３８】
一方、ステップＳ１０での判定の結果、ＡＰＬ再起動回数が閾値Ｎを超えない場合、ステップＳ１３において、復旧方法判断機能部５０３は、監視対象であるサービス提供ＡＰＬ６０のＡＰＬ再起動回数を更新し、該監視対象であるサービス提供ＡＰＬの状態が異常であることから（ステップＳ９でＮｏ）、ステップＳ１４において、ＡＰＬ再起動機能部５０５が、そのサービス提供ＡＰＬ６０を再起動する。その後、ステップＳ１５へ進み、一定時間経過した後に、ステップＳ８へ戻る。
【００３９】
なお、復旧方法判断機能部５０３は、ステップＳ８〜ステップＳ１５の一連の処理とは別に、監視対象であるサービス提供ＡＰＬ６０に一定時間障害が発生しない場合、そのＡＰＬ再起動回数を「０」にリセットすることも可能である。
【００４０】
以上より、本実施の形態によれば、ゲストＯＳ４０の上で動作する障害監視・復旧機能部（ゲスト）５０で、ゲストＯＳ４０の障害監視・再起動管理及びハイパーバイザ３０・ホストＯＳ２０の再起動を行うので、ホストＯＳ２０の上で従来動作していた障害監視・復旧機能部（ホスト）を不要とし、ハードウェア変更時に障害監視・復旧機能部（ホスト）の動作検証を行う必要を排除できることから、ホストＯＳ２０から下位のホスト部とハイパーバイザ３０から上位のゲスト部とを分離し易くすることができる。
【００４１】
また、本実施の形態によれば、ハイパーバイザ３０の仮想ウォッチドッグタイマーを用いてゲストＯＳ４０のフリーズ監視・再起動を行うので、ホストＯＳ２０の上で従来動作していた障害監視・復旧機能部（ホスト）を用いることなく、ゲストＯＳ４０の再起動を行うことができ、ゲストＯＳ４０の再起動によりサービス提供ＡＰＬ６０によるサービスを復旧することができる。
【００４２】
また、本実施の形態によれば、ホストＯＳ２０の汎用インタフェースを用いてホストＯＳ２０又はハイパーバイザ３０を再起動するので、サービス提供ＡＰＬ６０又はゲストＯＳ４０の再起動では復旧できない障害に対処することができる。
【００４３】
最後に、本実施の形態で説明した、サーバ１及び障害監視・復旧機能部（ゲスト）５０は、ＣＰＵ、メモリ、ハードディスク等を備えたコンピュータ（情報処理装置）で実現できる。また、サーバ１又は障害監視・復旧機能部（ゲスト）５０としてコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。
【符号の説明】
【００４４】
１…サーバ
１０…ハードウェア
２０…ホストＯＳ
３０…ハイパーバイザ
４０…ゲストＯＳ
５０…障害監視・復旧機能部（ゲスト）（障害監視復旧装置）
６０…サービス提供ＡＰＬ
５０１…生存通知機能部（監視部）
５０２…ゲストＯＳ再起動回数管理機能部（管理部）
５０３…復旧方法判断機能部（再起動部）
５０４…ＡＰＬ障害監視機能部
５０５…ＡＰＬ再起動機能部
５０６…ゲストＯＳ再起動機能部
【図１】
2018041211.tif 000003
【図２】
2018041211.tif 000004
【図３】
2018041211.tif 000005
【図４】
2018041211.tif 000006