(57)【要約】【課題】冗長化システムに対して、障害を迅速に検知できると共に誤検知のリスクが小さく、監視負荷が小さいハードウェア障害検出手法を提供する。【解決手段】複数のコンピュータ２上に稼働するホストＯＳ２１、および各仮想マシン２３、仮想マシン２３によって実行される二重化構成のアプリケーションを含んで構成される冗長化システム１において、各ホストＯＳ２１の死活を監視するホストＯＳ監視部３１と、ホストＯＳ２１の応答が途絶えたことを検知したならば、当該ホストＯＳ２１上の仮想マシン２３によって実行される代表アプリケーションを選出し、更に対となる対応アプリケーションを選出する代表アプリケーション選出部３２と、選出された対応アプリケーションの状態が片系運転中か否かを確認するアプリケーション状態確認部３３と、を備える。【選択図】図１
2019008340.tif 000002
【特許請求の範囲】
【請求項１】
複数の物理コンピュータ上に稼働するホストＯＳ、および各仮想マシン、前記仮想マシンによって実行される二重化構成のアプリケーションを含んで構成される冗長化システムにおいて、
各前記ホストＯＳの死活を監視するホストＯＳ監視部と、
前記ホストＯＳ監視部が、いずれかのホストＯＳの応答が途絶えたことを検知したならば、検知した当該ホストＯＳ上の仮想マシンによって実行される代表アプリケーションを選出し、更に当該代表アプリケーションの対となる対応アプリケーションを選出する代表アプリケーション選出部と、
前記代表アプリケーション選出部によって選出された前記対応アプリケーションの状態が片系運転中か否かを確認するアプリケーション状態確認部と、
を備えることを特徴とする冗長化システム。
【請求項２】
前記アプリケーション状態確認部が確認した前記対応アプリケーションのうちいずれかの状態が片系運転中であったならば、前記ホストＯＳ監視部が検知したホストＯＳ上の仮想マシンを他のホストＯＳ上に復旧する復旧処理部、
を備えることを特徴とする請求項１に記載の冗長化システム。
【請求項３】
各前記物理コンピュータと、当該物理コンピュータ上に具現化された前記仮想マシンと、当該仮想マシンによって実行される代表アプリケーションと、当該代表アプリケーションの対となる対応アプリケーションとの対応関係を格納した代表アプリケーション候補データベース、
を備えることを特徴とする請求項１に記載の冗長化システム。
【請求項４】
前記代表アプリケーションの状態が片系運転中か否かを確認する状態確認コマンドと、前記状態確認コマンドに対する応答とを格納した状態確認ロジック、
を備えることを特徴とする請求項１に記載の冗長化システム。
【請求項５】
各前記仮想マシンは、前記ホストＯＳ上で動作するハイパーバイザによって具現化される、
ことを特徴とする請求項１に記載の冗長化システム。
【請求項６】
各前記物理コンピュータ上で動作するハイパーバイザによって、前記アプリケーションを実行する各前記仮想マシンと、前記ホストＯＳを実行する仮想マシンとが具現化される、
ことを特徴とする請求項１に記載の冗長化システム。
【請求項７】
複数の物理コンピュータ上に稼働するホストＯＳ、および各仮想マシン、前記仮想マシンによって実行される二重化構成のアプリケーションを含んで構成される冗長化システムにおいて、
ホストＯＳ監視部が各前記ホストＯＳの死活を監視し、
前記ホストＯＳ監視部によって、いずれかのホストＯＳの応答が途絶えたことを検知したならば、代表アプリケーション選出部は、検知した当該ホストＯＳ上の仮想マシンによって実行される代表アプリケーションを選出し、
当該代表アプリケーションの対となる対応アプリケーションを選出し、
アプリケーション状態確認部によって、前記対応アプリケーションの状態が片系運転中か否かを確認する、
ことを特徴とする冗長化システムのハードウェア障害検出方法。
【請求項８】
前記アプリケーション状態確認部が確認した前記代表アプリケーションのうちいずれかの状態が片系運転中であったならば、復旧処理部により、応答が途絶えたことを検知したホストＯＳ上の仮想マシンを他のホストＯＳ上に復旧する、
ことを特徴とする請求項７に記載の冗長化システムのハードウェア障害検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、冗長化システムおよびハードウェア障害検出方法に関する。
【背景技術】
【０００２】
近年のクラウドサービスでは、集約効率を高めるために、仮想化技術を用いて物理コンピュータのハードウェア上に複数の論理コンピュータ（仮想マシン）を設け、テナントユーザへ提供することが一般的である。論理コンピュータとは、一般にはＶＭ（Virtual Machine）を指す。
【０００３】
このようなクラウドサービスは、仮想リソース管理機能によって管理、運用することができる。仮想リソース管理機能を担うソフトウェアとして、近年はOpenStack（登録商標：非特許文献１参照）が注目されている。
仮想リソース管理機能と、クラウドサービスを構成する物理コンピュータや論理コンピュータを監視する機能とを連携させることにより、クラウドサービスの冗長性を担保することが可能である。以下、このようにクラウドサービスの冗長性を担保するシステムを冗長化システムと呼称する。
【０００４】
図５は、比較例の冗長化システムの構成例を示す機能ブロック図である。
冗長化システム１Ａは、コンピュータ２−１〜２−３、監視装置３、仮想リソース管理機能４、コンピュータＩＰアドレス一覧４１から構成される。
比較例の冗長化システム１Ａは、高い可用性を要件とするため、現用系のアプリケーションと予備系のアプリケーションとで二重化されている。仮想化環境においても、現用系のアプリケーションと予備系のアプリケーションとを異なるＶＭに実行させ、各ＶＭをそれぞれ異なるコンピュータ上で稼働させることで二重化し、ハードウェア障害に対する冗長性を持たせている。
【０００５】
コンピュータ（物理コンピュータ）２−１上でホストＯＳ２１−１が稼働し、ホストＯＳ２１−１上でハイパーバイザ２２−１が稼働する。ハイパーバイザ２２−１はＶＭ（仮想マシン）２３−１，２３−２を具現化する。ＶＭ２３−１は現用系アプリケーションＡを、ＶＭ２３−２は現用系アプリケーションＢを二重化するための予備系アプリケーションｂを実行する。
コンピュータ（物理コンピュータ）２−２上でホストＯＳ２１−２が稼働し、ホストＯＳ２１−２上でハイパーバイザ２２−２が稼働する。ハイパーバイザ２２−２はＶＭ２３−３，２３−４を具現化する。ＶＭ２３−３は現用系アプリケーションＢを、ＶＭ２３−４は現用系アプリケーションＣを二重化するための予備系アプリケーションｃを実行する。
コンピュータ（物理コンピュータ）２−３上でホストＯＳ２１−３が稼働し、ホストＯＳ２１−３上でハイパーバイザ２２−３が稼働する。ハイパーバイザ２２−３はＶＭ２３−５，２３−６を具現化する。ＶＭ２３−５は現用系アプリケーションＣを、ＶＭ２３−６は現用系アプリケーションＡを二重化するための予備系アプリケーションａを実行する。
【０００６】
コンピュータ２−１〜２−３を単にコンピュータ２と記載することがある。ホストＯＳ２１−１〜２１−３を単にホストＯＳ２１と記載することがある。ハイパーバイザ２２−１〜２２−３を単にハイパーバイザ２２と記載することがある。ＶＭ２３−１〜２３−６を単にＶＭ２３と記載することもある。
【０００７】
監視装置３は、コンピュータ２とＶＭ２３のどちらか一方または両方の死活を監視する。
死活の監視の方法としては、例えばpingを送信して応答有無を確認する方法が簡易であり、多く用いられる。この方法では、監視装置３がコンピュータ２の物理ＮＩＣ（Network Interface Card）へpingを送信することにより、コンピュータ２のハードウェア障害を検知することができる。また、監視装置３がＶＭ２３の仮想ＮＩＣへpingを送信することにより、コンピュータ２のハードウェア障害を検知することもできる。コンピュータ２とＶＭ２３両方にpingを送信して応答確認しても、片方だけに送信して応答確認してもよい。
Pingの送信先のＮＩＣに割り当てられたＩＰアドレスは、コンピュータＩＰアドレス一覧４１に格納されている。監視装置３はコンピュータＩＰアドレス一覧４１を参照して、確認対象のＮＩＣにpingを送信する。
【０００８】
仮想リソース管理機能４は、監視装置３と連携し、コンピュータ２上に具現化されたＶＭ２３を管理する。
このような構成により、監視装置３がコンピュータ２のハードウェア障害を検出した際、仮想リソース管理機能４は、ＶＭ２３を故障ハードウェア上のホストＯＳ２１上から削除し、異なるハードウェア上のホストＯＳ２１上に再生成できる。このようなＶＭの自動的な削除と再生成とを、以降、復旧処理またはオートヒーリングと呼ぶこともある。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】OpenStack Project、“OpenStack Open Source Cloud Computing Software”、[online]、[平成29年6月16日検索]、インターネット<URL:http://www.openstack.org/>
【発明の概要】
【発明が解決しようとする課題】
【００１０】
物理コンピュータのみで構成されたシステムであれば、定常時は監視への応答遅延は起こりづらい。しかし、複数のＶＭが１つの物理コンピュータに共存する仮想環境においては、ハードウェア障害が発生していない場合であっても応答遅延のばらつきが大きい。そのため、物理コンピュータとＶＭとが正常に動作していても、あらかじめ規定した時間（タイムアウト時間）内に応答が返らない可能性がある。その場合、監視装置３は、応答が途絶えたと誤認し、ハードウェア障害を誤検知するおそれがある。
【００１１】
このような誤検知が発生した場合、仮想リソース管理機能４は、自動的にＶＭ２３を削除して別のホストＯＳ２１上に再生成する。このような処置は、アプリケーションによってはサービス中断の原因や、コンピュータ処理と通信の負荷等となる。よって、このような場合に行うべきではない。
【００１２】
このような障害の誤検知によるオートヒーリングを回避するため、pingのタイムアウト時間を長くする方法も考えられる。しかし、この方法では、障害検知にかかる時間が長くなるため、迅速に復旧を開始できなくなる。
【００１３】
ハードウェア障害検知手段として、個々のアプリケーションに対して定期的な状態確認やログ取得を行う方法もある。しかしながら、アプリケーションごとの確認は、pingによる単純な応答確認と比較して、応答処理負荷やデータ転送の通信負荷が大きい。そのため、複数のＶＭが同時に存在するような環境で高頻度にアプリケーションごとの確認を行うと、サービス障害の原因となるおそれがある。
【００１４】
本発明はこのような点を鑑みてなされたものであり、障害を迅速に検知できると共に誤検知のリスクが小さく、監視負荷が小さい冗長化システムおよびハードウェア障害検出手法を提供することを課題とする。
【課題を解決するための手段】
【００１５】
前記した課題を解決するため、請求項１に記載の発明は、
複数の物理コンピュータ上に稼働するホストＯＳ、および各仮想マシン、前記仮想マシンによって実行される二重化構成のアプリケーションを含んで構成される冗長化システムにおいて、
各前記ホストＯＳの死活を監視するホストＯＳ監視部と、
前記ホストＯＳ監視部が、いずれかのホストＯＳの応答が途絶えたことを検知したならば、検知した当該ホストＯＳ上の仮想マシンによって実行される代表アプリケーションを選出し、更に当該代表アプリケーションの対となる対応アプリケーションを選出する代表アプリケーション選出部と、
前記代表アプリケーション選出部によって選出された前記対応アプリケーションの状態が片系運転中か否かを確認するアプリケーション状態確認部と、
を備えることを特徴とする冗長化システムとした。
【００１６】
このようにすることで、冗長化システムは、定常時の負荷を抑えつつ、障害を誤検知するリスクを小さくすることが可能となる。更にこの構成では、正常なコンピュータ上に具現化された仮想マシンに対して状態を問い合わせ、障害が疑われるコンピュータ上に具現化された仮想マシンに対しては状態を問い合わせない。これにより、障害が疑われるコンピュータに対して、更に処理と通信の負荷をかけることを回避できる。
【００１７】
前記した課題を解決するため、請求項２に記載の発明は、
前記アプリケーション状態確認部が確認した前記対応アプリケーションのうちいずれかの状態が片系運転中であったならば、前記ホストＯＳ監視部が検知したホストＯＳ上の仮想マシンを他のホストＯＳ上に復旧する復旧処理部、
を備えることを特徴とする請求項１に記載の冗長化システムとした。
【００１８】
このようにすることで、冗長化システムは、精度の高い障害検知に基づく必要なオートヒーリングのみを行うことが可能となる。これにより、サービスの中断、コンピュータ処理と通信の負荷の増大等を回避することができる。
【００１９】
前記した課題を解決するため、請求項３に記載の発明は、
各前記物理コンピュータと、当該物理コンピュータ上に具現化された前記仮想マシンと、当該仮想マシンによって実行される代表アプリケーションと、当該代表アプリケーションの対となる対応アプリケーションとの対応関係を格納した代表アプリケーション候補データベース、
を備えることを特徴とする請求項１に記載の冗長化システムとした。
【００２０】
このようにすることで、冗長化システムは、障害が疑われるコンピュータ上の代表アプリケーションと対になる対応アプリケーションを特定し、対応アプリケーションの状態確認を行う。これにより、冗長化システムは、障害を迅速に検知できる。
【００２１】
前記した課題を解決するため、請求項４に記載の発明は、
前記代表アプリケーションの状態が片系運転中か否かを確認する状態確認コマンドと、前記状態確認コマンドに対する応答とを格納した状態確認ロジック、
を備えることを特徴とする請求項１に記載の冗長化システムとした。
【００２２】
このようにすることで、冗長化システムは、確認対象の対応アプリケーションに対応したロジックで、対応アプリケーションの状態確認を行うことが可能となる。個々に状態確認ロジックが異なるアプリケーションであっても、状態確認が可能となる。
【００２３】
前記した課題を解決するため、請求項５に記載の発明は、
各前記仮想マシンは、前記ホストＯＳ上で動作するハイパーバイザによって具現化される、
ことを特徴とする請求項１に記載の冗長化システムとした。
【００２４】
このようにすることで、冗長化システムは、Type２のハイパーバイザを適用できる。
【００２５】
前記した課題を解決するため、請求項６に記載の発明は、
各前記物理コンピュータ上で動作するハイパーバイザによって、前記アプリケーションを実行する各前記仮想マシンと、前記ホストＯＳを実行する仮想マシンとが具現化される、
ことを特徴とする請求項１に記載の冗長化システムとした。
【００２６】
このようにすることで、冗長化システムは、Type１のハイパーバイザを適用できる。
【００２７】
前記した課題を解決するため、請求項７に記載の発明は、
複数の物理コンピュータ上に稼働するホストＯＳ、および各仮想マシン、前記仮想マシンによって実行される二重化構成のアプリケーションを含んで構成される冗長化システムにおいて、
ホストＯＳ監視部が各前記ホストＯＳの死活を監視し、
前記ホストＯＳ監視部によって、いずれかのホストＯＳの応答が途絶えたことを検知したならば、代表アプリケーション選出部は、検知した当該ホストＯＳ上の仮想マシンによって実行される代表アプリケーションを選出し、
当該代表アプリケーションの対となる対応アプリケーションを選出し、
アプリケーション状態確認部によって、前記対応アプリケーションの状態が片系運転中か否かを確認する、
ことを特徴とする冗長化システムのハードウェア障害検出方法とした。
【００２８】
このようにすることで、冗長化システムは、定常時の負荷を抑えつつ、障害を誤検知するリスクを小さくすることが可能となる。更にこの構成では、正常なコンピュータ上に具現化された仮想マシンに対して状態を問い合わせ、障害が疑われるコンピュータ上に具現化された仮想マシンに対しては状態を問い合わせない。これにより、障害が疑われるコンピュータに対して、更に処理と通信の負荷をかけることを回避できる。
【００２９】
前記した課題を解決するため、請求項８に記載の発明は、
前記アプリケーション状態確認部が確認した前記代表アプリケーションのうちいずれかの状態が片系運転中であったならば、復旧処理部により、応答が途絶えたことを検知したホストＯＳ上の仮想マシンを他のホストＯＳ上に復旧する、
ことを特徴とする請求項７に記載の冗長化システムのハードウェア障害検出方法とした。
【００３０】
このようにすることで、冗長化システムは、精度の高い障害検知に基づく必要なオートヒーリングのみを行うことが可能となる。これにより、サービスの中断、コンピュータ処理と通信の負荷の増大等を回避することができる。
【発明の効果】
【００３１】
本発明によれば、障害を迅速に検知できると共に誤検知のリスクが小さく、監視負荷が小さい冗長化システムおよびハードウェア障害検出手法を提供することができる。
【図面の簡単な説明】
【００３２】
【図１】本実施形態に係る冗長化システムの構成例を示す機能ブロック図である。
【図２】本実施形態に係るハードウェア障害検出方法のフローチャートである。
【図３】本実施形態に係る状態確認ロジックのテーブルの一例である。
【図４】本実施形態に係るホストＯＳ監視の実行から復旧処理までの流れを示すシーケンス図である。
【図５】比較例の冗長化システムの構成例を示す機能ブロック図である。
【発明を実施するための形態】
【００３３】
次に、本発明を実施するための形態（以下、「本実施形態」と称する。）における冗長化システム１等について説明する。
【００３４】
本実施形態の冗長化システム１は、高い可用性を要件とするため、現用系のアプリケーションと予備系のアプリケーションとで二重化されている。仮想化環境においても、現用系のアプリケーションと予備系のアプリケーションとを異なるＶＭに実行させ、各ＶＭをそれぞれ異なるコンピュータ上で稼働させることで、ハードウェア障害に対する冗長性を持たせている。
二重化構成では、一つの系に障害が発生したとき、正常なもう片系に問い合わせることで、稼動状態を確認することが可能である。本実施形態では、この性質を利用して、仮想化環境における二重化構成のアプリケーションを利用した二段階の監視機能を設ける。
【００３５】
図１は本実施形態に係る冗長化システム１の構成例を示す機能ブロック図である。
冗長化システム１は、コンピュータ２−１〜２−３、監視装置３、仮想リソース管理機能４から構成される。
【００３６】
コンピュータ（物理コンピュータ）２−１上でホストＯＳ２１−１が稼働し、ホストＯＳ２１−１上でハイパーバイザ２２−１が稼働する。ハイパーバイザ２２−１はＶＭ（仮想マシン）２３−１，２３−２を具現化する。
コンピュータ（物理コンピュータ）２−２上でホストＯＳ２１−２が稼働し、ホストＯＳ２１−２上でハイパーバイザ２２−２が稼働する。ハイパーバイザ２２−２はＶＭ２３−３，２３−４を具現化する。
コンピュータ（物理コンピュータ）２−３上でホストＯＳ２１−３が稼働し、ホストＯＳ２１−３上でハイパーバイザ２２−３が稼働する。ハイパーバイザ２２−３はＶＭ２３−５，２３−６を具現化する。
【００３７】
コンピュータ２−１〜２−３を単にコンピュータ２と記載することがある。ホストＯＳ２１−１〜２１−３を単にホストＯＳ２１と記載することがある。ハイパーバイザ２２−１〜２２−３を単にハイパーバイザ２２と記載することがある。ＶＭ２３−１〜２３−６を単にＶＭ２３と記載することもある。
【００３８】
仮想リソース管理機能４は、コンピュータＩＰアドレス一覧４１を備える。ＶＭ２３の情報は仮想リソース管理機能４に格納され管理される。
【００３９】
監視装置３は、ホストＯＳ監視部３１、代表アプリケーション選出部３２、代表アプリケーション候補データベース３４、アプリケーション状態確認部３３、状態確認ロジック３５を備える。監視装置３は、仮想リソース管理機能４とは別個の機能である。仮想リソース管理機能４と同一のコンピュータ上に配備することも異なるコンピュータ上に配備することも可能であり、その配備方法は問わない。なお、図面ではデータベースのことを“ＤＢ”と記載している場合がある。
【００４０】
現用系アプリケーションＡは、コンピュータ２−１上に具現化されたＶＭ２３−１が実行している。現用系アプリケーションＡの対となる予備系アプリケーションａは、コンピュータ２−３上に具現化されたＶＭ２３−６が実行している。
現用系アプリケーションＢは、コンピュータ２−２上に具現化されたＶＭ２３−３が実行している。現用系アプリケーションＢの対となる予備系アプリケーションｂは、コンピュータ２−１上に具現化されたＶＭ２３−２が実行している。
現用系アプリケーションＣは、コンピュータ２−３上に具現化されたＶＭ２３−５が実行している。現用系アプリケーションＣの対となる予備系アプリケーションｃは、コンピュータ２−２上に具現化されたＶＭ２３−４が実行している。
このように、これらのアプリケーションは二重化されている。
【００４１】
二重化構成のアプリケーションＡとａ、Ｂとｂ、およびＣとｃは、対となるアプリケーションに対して互いに定期的に問い合わせて（ポーリング）、対となるアプリケーションの状態を保持している。
ユーザは事前に、代表アプリケーション候補データベース３４に、二重化されたアプリケーションの情報を格納しておく。具体的には、例えばコンピュータ２−１と、その上に具現化されたＶＭ２３−１と、ＶＭ２３−１によって実行される代表アプリケーションＡと、この代表アプリケーションＡの対となる対応アプリケーションａとの対応関係を格納する。格納は既知の方法で行うことができる。
代表アプリケーション候補の格納は、例えば、ＶＭ２３の情報を仮想リソース管理機能４に格納するときに行うことができる。また、代表アプリケーション候補が削除等によりユーザが当初格納した数を下回った場合等、必要に応じて随時、代表アプリケーション候補の追加格納が可能である。
【００４２】
ホストＯＳ監視部３１は、アプリケーションを実行している全てのＶＭ２３に共通のホストＯＳ２１に対して死活の監視を行う。ホストＯＳ２１の監視は、個々のＶＭ２３ごとの監視よりも低負荷である。監視は、例えば既存技術と同様、ping送信による応答確認等により行う。ホストＯＳ監視部３１はコンピュータＩＰアドレス一覧４１からコンピュータ２の物理ＮＩＣに割り当てられたＩＰアドレスを取得する。取得したＩＰアドレスに基づいて、コンピュータ２の物理ＮＩＣへ定期的にpingを送信し、応答を確認する。
なお、死活の監視方法として、ホストＯＳ２１からホストＯＳ監視部３１に向けてkeep aliveを定期的に送信する方法を採用してもよいし、その他の方法でホストＯＳを監視してもよい。
【００４３】
ホストＯＳ２１−１から一定時間内の応答が得られなかった場合を考える。
このとき、コンピュータ２−１のハードウェアに障害が発生したことが疑われる。障害の確認のため、代表アプリケーション選出部３２は、代表アプリケーション候補データベース３４から、１つ以上の代表アプリケーションを選出する。選出方法はランダムでも、ＶＭ生成順でも、その他の方法でもよい。本例では、コンピュータ２−１上に具現化されるＶＭ２３−１が実行する現用系アプリケーションＡと、ＶＭ２３−２が実行する予備系アプリケーションｂとが、代表アプリケーションとして選出される。
【００４４】
更に、代表アプリケーション選出部３２は、選出した代表アプリケーションと対になりかつ別のコンピュータ２で動作しているアプリケーションを、代表アプリケーション候補データベース３４から特定する。このようなアプリケーションを、以降、対応アプリケーションと称する。
本例では、代表アプリケーションＡの対応アプリケーションとして、コンピュータ２−３上に具現化されるＶＭ２３−６が実行する予備系アプリケーションａが特定される。また、代表アプリケーションｂの対応アプリケーションとして、コンピュータ２−２上に具現化されるＶＭ２３−３が実行する現用系アプリケーションＢが特定される。
【００４５】
対応アプリケーションａと対応アプリケーションＢに対して、アプリケーション状態確認部３３が状態確認を行い、片系運転中か否かを判定する。前述のように、対応アプリケーションは、対となる代表アプリケーションの状態をポーリングによって確認し保持している。そのため対応アプリケーションへの状態確認によって代表アプリケーションの状態が確認できる。対応アプリケーションが二重化運転中ならば、代表アプリケーションは動作中である。対応アプリケーションが片系運転中ならば、代表アプリケーションは停止している。
アプリケーションの状態確認コマンドや、異常状態の判定ロジックは、アプリケーションごとに異なる。よってユーザが事前に、状態確認ロジック３５にアプリケーション固有のインタフェースを事前に格納しておくものとする。状態確認ロジック３５の詳細については後述する。
【００４６】
アプリケーション状態確認部３３は、状態確認ロジック３５を参照し、確認対象の対応アプリケーションに応じたロジックで対応アプリケーションの状態確認を行う。確認の結果、いずれかの二重化構成のアプリケーションにおいて、対応アプリケーションのみが稼働している（片系運転）ことが判明した場合、監視装置３は、コンピュータ２−１のハードウェアに障害が発生したと判定する。
この判定により、仮想リソース管理機能４は、コンピュータ２−１上に具現化されているＶＭ２３−１，ＶＭ２３−２を削除し、コンピュータ２−１以外のホストＯＳ２１上に再生成する。
【００４７】
図１のように、本実施形態のＶＭ２３は、ホストＯＳ２１上で動作するハイパーバイザ２２によって具現化されている。このようなハイパーバイザを、Type２のハイパーバイザという。
なお、コンピュータ上でホストＯＳを介さずに動作するType１のハイパーバイザによって、アプリケーションを実行するＶＭとホストＯＳを実行するＶＭとを具現化する方法も採用できる。この場合も、本実施形態と同様の方法でハードウェア障害検出が可能である。
【００４８】
図２は、本実施形態に係るハードウェア障害検出方法のフローチャートである。
まず、ホストＯＳ監視部３１は、ホストＯＳ２１に対して死活を監視する（ステップＳ１０）。実際にはホストＯＳ監視部３１は、ホストＯＳ２１−１〜２１−３に対して死活を監視するが、ここでは単純化のために、１台のホストＯＳ２１に着目して説明する。
【００４９】
監視の結果、一定時間内に応答があった場合、ホストＯＳ監視部３１はその後も定期的に監視を実行し続ける（ステップＳ１０：応答）。
監視の結果、一定時間内に応答がなかった場合（ステップＳ１０：タイムアウト）、ホストＯＳ監視部３１は、ホストＯＳ２１の応答が途絶えたことを検知する。代表アプリケーション選出部３２は、代表アプリケーション候補データベース３４に基づき、このホストＯＳ２１上のＶＭ２３によって実行される代表アプリケーションを選出する（ステップＳ１１）。代表アプリケーション選出部３２は、コンピュータ１台につき１つ以上の代表アプリケーションを選出する。
【００５０】
監視装置３は、選出された各代表アプリケーションについてステップＳ１２〜Ｓ１５の処理を繰り返す。
【００５１】
以下に繰り返し処理の内容を述べる。
代表アプリケーション選出部３２は、代表アプリケーション候補データベース３４から、代表アプリケーションの対となる対応アプリケーションを特定する（ステップＳ１３）。なお、対応アプリケーションの特定は、アプリケーション状態確認部３３が行ってもよい。
特定された対応アプリケーションに対して、アプリケーション状態確認部３３は、状態確認を行う（ステップＳ１４）。
【００５２】
対応アプリケーションの状態確認の結果、二重化運転ならば（ステップＳ１４：正常／二重化運転）、代表アプリケーションが正常であったと判定できる。この場合、アプリケーション状態確認部３３は、監視結果（タイムアウト）が誤検知であったか、または通信経路に留まる障害であったと判定する。よって、復旧処理には移行せず、監視装置３は次の代表アプリケーションについて繰り返し処理を行う（ステップＳ１５）。
ステップＳ１５において、全ての代表アプリケーションについて異常が検出されなかった場合、ホストＯＳ監視部３１は再びホストＯＳ２１に対する死活の監視に戻る（ステップＳ１０）。
故障が疑われるコンピュータ２上で動作している代表アプリケーションに対して状態を確認する場合、代表アプリケーションの応答がないか、または応答時間が長くなることが予想される。これに対して、代表アプリケーションの対となる対応アプリケーションは、正常に動作しているコンピュータ２上で動作していると考えられる。よって、対応アプリケーションは、迅速に応答する。これにより、冗長化システム１は、障害を迅速に検知することができる。
【００５３】
対応アプリケーションの状態確認の結果、対応アプリケーションのみが稼働する片系運転ならば（ステップＳ１４：異常／片系運転）、代表アプリケーションに障害が発生していると判定できる。この場合、アプリケーション状態確認部３３は、監視結果（タイムアウト）はコンピュータ２のハードウェアの障害によるものであると判定して、ステップＳ１６の復旧処理に進む。
復旧処理において、仮想リソース管理機能４は、故障したコンピュータ２上のホストＯＳ２１に配備されたＶＭ２３を削除し、別のホストＯＳ２１上にＶＭ２３を再生成する。その後、ホストＯＳ監視部３１は、再びホストＯＳ２１の監視に戻る（ステップＳ１０）。
【００５４】
図３は、本実施形態に係る状態確認ロジック３５のテーブルの一例である。
本例では、状態確認ロジック３５は代表アプリケーション（アプリケーション種別）と、状態確認コマンドと、正常確認ロジックを関連付けて記憶している。
アプリケーション状態確認部３３は、この状態確認ロジック３５を参照することで、確認対象の対応アプリケーションに対応した状態確認コマンドの実行と、正常確認ロジックによる正常確認を行う。
具体的には、アプリケーション状態確認部３３は、アプリケーションＡに対して、状態確認コマンドＸｘｘｘを実行し、コマンドの応答に文字列ＡＡＡが含まれた場合は、アプリケーションＡの状態は正常だと判定する。
アプリケーション状態確認部３３は、アプリケーションＢに対して、状態確認コマンドＹｙｙｙを実行し、コマンドの応答に文字列ＢＢＢが含まれた場合は、アプリケーションＢの状態は正常だと判定する。
アプリケーション状態確認部３３は、アプリケーションＣに対して、状態確認コマンドＺｚｚｚを実行し、コマンドの応答に文字列ＣＣＣが含まれた場合は、アプリケーションＣの状態は正常だと判定する。
【００５５】
なお、状態確認ロジック３５には、本例のように正常確認ロジックを関連付けるだけでなく、異常確認ロジックを関連付けてもよい。この場合、アプリケーション状態確認部３３は、対応アプリケーションの異常確認を行う。その際、アプリケーション状態確認部３３が、異常発生の事実だけでなく対応アプリケーションのログ等の情報も取得するようにしてもよい。
【００５６】
図４は、本実施形態に係るホストＯＳ監視の実行から復旧処理までの流れを示すシーケンス図である。なお、この例では監視装置３のホストＯＳ監視部３１からpingを送信することで、ホストＯＳ２１の監視を行っている。
【００５７】
まず、監視装置３のホストＯＳ監視部３１は、コンピュータ２−１の物理ＮＩＣへpingを送信する（ステップＳ２０）。ホストＯＳ２１−１は、正常であれば一定時間以内に応答を返す（ステップＳ２１）。
【００５８】
ping送信の際（ステップＳ２２）、通信障害などにより一定時間以内に応答が返らなかった場合（ステップＳ２３）、監視装置３はタイムアウトを検知する（ステップＳ２４）。
このとき、監視装置３のアプリケーション状態確認部３３は、ホストＯＳ２１−１に配備されたＶＭ２３−１が実行する代表アプリケーションＡと対になる対応アプリケーションａの状態を確認する（ステップＳ２５）。前述の通り、今回のタイムアウトの原因は通信障害であり、コンピュータ２−１にハードウェア障害は発生しておらず、代表アプリケーションＡは正常に動作している。代表アプリケーションＡの正常動作をポーリングで確認している対応アプリケーションａは、代表アプリケーションＡと対応アプリケーションａの両方が稼働した二重化運転がなされている旨を応答する（ステップＳ２６）。
【００５９】
次に、監視装置３のアプリケーション状態確認部３３は、もう一つの代表アプリケーションｂと対になる対応アプリケーションＢの状態確認を行う（ステップＳ２７）。コンピュータ２−１にハードウェア障害は発生していないので、対応アプリケーションＢも、二重化運転がなされている旨を応答する（ステップＳ２８）。
【００６０】
このようにコンピュータ２−１上の全ての代表アプリケーションが正常動作している場合、復旧処理には移行せず、監視装置３は再び定期監視に戻る（ステップＳ２９）。監視に対して、ホストＯＳ２１−１は、正常であれば一定時間以内に応答を返す（ステップＳ３０）。
【００６１】
ここで、コンピュータ２−１のハードウェアに障害が発生した場合を考える。このとき、監視装置３のホストＯＳ監視部３１から送信されたpingには（ステップＳ３１）、一定時間内に応答が返らず、監視装置３はタイムアウトを検知する（ステップＳ３２）。
このとき、監視装置３のアプリケーション状態確認部３３は、ホストＯＳ２１−１に配備されたＶＭ２３−１が実行する代表アプリケーションＡと対になる対応アプリケーションａの状態を確認する（ステップＳ３３）。コンピュータ２−１に発生したハードウェア障害のため、代表アプリケーションＡは正常に動作していない。代表アプリケーションＡの異常をポーリングによって確認している対応アプリケーションａは、対応アプリケーションａのみが稼働した片系運転となっている旨を応答する（ステップＳ３４）。
【００６２】
対応アプリケーションａの応答により、コンピュータ２−１のハードウェア障害を検出した監視装置３は復旧処理に移行し、仮想リソース管理機能４に自動復旧を実行させる（ステップＳ３５）。
【００６３】
実施形態は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、前記した機構や構成は説明上必要と考えられるものを示しており、製品上必ずしも全ての機構や構成を示しているとは限らない。
【００６４】
このように、本実施形態では、仮想環境で実行する複数サービスに共用されるコンピュータリソースに対して、障害誤検知のリスクが小さく、かつ、定常負荷が小さい冗長化システムおよびハードウェア障害検出手法を提供することができる。このハードウェア障害検出手法は、特殊なハードウェアが不要であり、ソフトウェアだけで実装可能である。
【００６５】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｃ）のようなものがある。
（ａ）  死活監視の方法は、pingに限定されず、任意のコマンドをホストＯＳに送信して、その応答を監視してもよい。
（ｂ）  その他の死活監視の方法は、keep aliveに限定されず、任意のハートビート通信によって監視してもよい。
（ｃ）  上記実施形態では、いずれかの代表アプリケーションと対となる対応アプリケーションに対して状態を確認し、片系運転ならば、この代表アプリケーションが動作しているコンピュータ上の全ての仮想マシンを自動復旧している。しかし、これに限られず、障害を検知した代表アプリケーションに係る仮想マシンのみを自動復旧してもよい。
【符号の説明】
【００６６】
１                                      冗長化システム
２−１，２−２，２−３                  コンピュータ（物理コンピュータ）
２１−１，２１−２，２１−３            ホストＯＳ
２２−１，２２−２，２２−３            ハイパーバイザ
２３−１，２３−２，２３−３，２３−４，２３−５，２３−６    仮想マシン（ＶＭ）（論理コンピュータ）
３          監視装置
３１        ホストＯＳ監視部
３２        代表アプリケーション選出部
３３        アプリケーション状態確認部
３４        代表アプリケーション候補データベース（代表アプリケーション候補ＤＢ）
３５        状態確認ロジック
４          復旧処理部（仮想リソース管理機能）
４１        コンピュータＩＰアドレス一覧
Ａ，Ｂ，Ｃ  アプリケーション（現用系アプリケーション）（代表アプリケーション）（対応アプリケーション）
ａ，ｂ，ｃ  アプリケーション（予備系アプリケーション）（代表アプリケーション）（対応アプリケーション）
【図１】
2019008340.tif 000003
【図２】
2019008340.tif 000004
【図３】
2019008340.tif 000005
【図４】
2019008340.tif 000006
【図５】
2019008340.tif 000007