JP2020201637A - 情報処理システム - Google Patents

Abstract

【課題】 運用コストを抑えることができる情報処理システムを提供する。【解決手段】 遠隔管理システムにおいて、複数のインスタンスで並列分散処理を実行するデバイス管理サービス４０のインスタンスのそれぞれは、インスタンス自身の復旧に関する処理の状況をカウンター情報から取得するとともに、インスタンス自身の復旧に関する処理を実行した場合に、この処理の状況をカウンター情報に記憶し（Ｓ２２３、Ｓ２２４、Ｓ２４３）、複数のインスタンスで並列分散処理を実行するワーカーサービス５０のインスタンスのそれぞれは、デバイス管理サービス４０のインスタンスの復旧に関する処理の状況をカウンター情報から取得するとともに、デバイス管理サービス４０のインスタンスの復旧に関する処理を実行した場合に、この処理の状況をカウンター情報に記憶する（Ｓ２２１、Ｓ２２２、Ｓ２４２）ことを特徴とする。【選択図】 図１１

Description

本発明は、障害から自律復旧することが可能な情報処理システムに関する。

従来、パプリッククラウドにおいて、現用系の情報処理システムで発生した障害を検出した場合に、現用系の情報処理システムから待機系の情報処理システムにＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを付け替えることによって、現用系の情報処理システムに代えて待機系の情報処理システムでサービスの提供を継続するものが知られている（例えば、特許文献１参照。）。

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

しかしながら、従来の技術においては、待機系の情報処理システムが必要であり、待機系の情報処理システム分の運用コストがかかるという問題がある。

そこで、本発明は、運用コストを抑えることができる情報処理システムを提供することを目的とする。

本発明の情報処理システムは、複数のインスタンスを備え、これらのインスタンスで並列分散処理を実行する第１の並列分散処理システムと、複数のインスタンスを備え、これらのインスタンスで並列分散処理を実行する第２の並列分散処理システムと、前記第１の並列分散処理システムの前記インスタンスの復旧に関する処理の状況を前記第１の並列分散処理システムの前記インスタンス毎に示す処理状況情報を記憶する処理状況記憶部とを備え、前記第１の並列分散処理システムの前記インスタンスのそれぞれは、インスタンス自身の復旧に関する処理の状況を前記処理状況情報から取得するとともに、インスタンス自身の復旧に関する処理を実行した場合に、この処理の状況を前記処理状況情報に記憶し、前記第２の並列分散処理システムの前記インスタンスのそれぞれは、前記第１の並列分散処理システムの前記インスタンスの復旧に関する処理の状況を前記処理状況情報から取得するとともに、前記第１の並列分散処理システムの前記インスタンスの復旧に関する処理を実行した場合に、この処理の状況を前記処理状況情報に記憶することを特徴とする。

この構成により、本発明の情報処理システムは、第１の並列分散処理システムのインスタンスの復旧に関する処理を、第１の並列分散処理システムのインスタンス自身と、第２の並列分散処理システムのインスタンスとによって実行するので、第１の並列分散処理システムに対応する待機系のシステムが不要であり、運用コストを抑えることができる。

本発明の情報処理システムにおいて、前記第１の並列分散処理システムの前記インスタンスは、このインスタンスの異常に対する前記第２の並列分散処理システムの前記インスタンスによる監視の状況が特定の状況になったことが前記処理状況情報に示された場合に、前記第１の並列分散処理システムの前記インスタンス自身の復旧に関する処理として、前記第１の並列分散処理システムの前記インスタンス自身のアプリケーションを再起動しても良い。

この構成により、本発明の情報処理システムは、第１の並列分散処理システムのインスタンスの異常に対する第２の並列分散処理システムのインスタンスによる監視の状況に応じて、第１の並列分散処理システムのインスタンスのアプリケーションを再起動するので、第１の並列分散処理システムのインスタンスのアプリケーションの再起動を適切なタイミングで実行することができる。

本発明の情報処理システムにおいて、前記第２の並列分散処理システムの前記インスタンスは、前記第１の並列分散処理システムの前記インスタンスの前記アプリケーションの再起動から特定の時間が経過しても、このアプリケーションの再起動が成功したことが前記処理状況情報に示されない場合に、前記第１の並列分散処理システムのこのインスタンスの再起動を要求しても良い。

この構成により、本発明の情報処理システムは、第１の並列分散処理システムのインスタンスのアプリケーションの再起動が失敗した場合に、このインスタンスの再起動を適切なタイミングで実行することができる。

本発明の情報処理システムにおいて、前記第２の並列分散処理システムの前記インスタンスは、前記第１の並列分散処理システムの前記インスタンスの再起動の要求から特定の時間が経過しても、このインスタンスの再起動が成功したことが前記処理状況情報に示されない場合に、自律復旧処理の失敗の通知のための処理を実行しても良い。

この構成により、本発明の情報処理システムは、第１の並列分散処理システムのインスタンスの再起動が失敗した場合に、自律復旧処理の失敗の通知のための処理を実行するので、人間による復旧処理を適切なタイミングで受ける可能性を向上することができる。

本発明の情報処理システムは、運用コストを抑えることができる。

本発明の一実施の形態に係るシステムのブロック図である。 図１に示す遠隔管理システムのブロック図である。 図２に示すカウンター情報の一例を示す図である。 １台のコンピューターによって構成される場合の図１に示す監視システムのブロック図である。 インスタンスが起動される場合の図２に示す復旧処理モジュールの動作のフローチャートである。 インスタンスの内部でＷｅｂアプリケーションが起動される場合の図２に示す復旧処理モジュールの動作のフローチャートである。 インスタンスの内部のＷｅｂアプリケーションの起動後の図２に示す復旧処理モジュールの動作のフローチャートである。 監視処理を実行する場合の図２に示す監視モジュールの動作のフローチャートである。 図８に示すインスタンス別監視処理のフローチャートである。 図９に示す監視詳細処理のフローチャートである。 （ａ）図２に示すデバイス管理サービスのインスタンスのＷｅｂアプリケーションの再起動が成功する場合のフローチャートである。 （ｂ）図２に示すデバイス管理サービスのインスタンスのＷｅｂアプリケーションの再起動が失敗するが、このインスタンスの再起動が成功する場合のフローチャートである。 （ｃ）図２に示すデバイス管理サービスのインスタンスのＷｅｂアプリケーションの再起動が失敗し、このインスタンスの再起動も失敗する場合のフローチャートである。 （ａ）図２に示すデバイス管理サービスのインスタンスのＷｅｂアプリケーションの再起動が開始されないが、このインスタンスの再起動が成功する場合のフローチャートである。 （ｂ）図２に示すデバイス管理サービスのインスタンスのＷｅｂアプリケーションの再起動が開始されず、このインスタンスの再起動も失敗する場合のフローチャートである。

以下、本発明の実施の形態について、図面を用いて説明する。

まず、本発明の一実施の形態に係るシステムの構成について説明する。

図１は、本実施の形態に係るシステム１０のブロック図である。

図１に示すように、システム１０は、画像形成装置を管理する業者（以下「管理業者」という。）の客のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワーク２０を備えている。システム１０は、ネットワーク２０以外にも、ネットワーク２０と同様の構成のネットワークを少なくとも１つ備えることが可能である。

ネットワーク２０は、ネットワーク２０の内部と、ネットワーク２０の外部との間の通信を制御するファイアウォール２１と、画像形成装置２２とを備えている。ネットワーク２０は、画像形成装置２２以外にも、画像形成装置２２と同様の構成の画像形成装置を少なくとも１つ備えることが可能である。ネットワーク２０における画像形成装置は、例えば、ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、プリンター専用機などによって構成されており、管理業者の客によって使用される。

システム１０は、システム１０における各画像形成装置を遠隔管理する情報処理システムとしての遠隔管理システム３０を備えている。遠隔管理システム３０は、例えば世界中に配置されている、例えば数百万台などの膨大な数の画像形成装置を管理することが可能である。遠隔管理システム３０は、管理業者によって使用される。遠隔管理システム３０は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。以下において、遠隔管理システム３０は、パブリッククラウドのクラウドプラットフォーム上で動作するものとして説明する。

遠隔管理システム３０にはインターネットを介して多数の画像形成装置が接続可能であるので、遠隔管理システム３０を構成するサーバーの能力は、遠隔管理システム３０に接続される画像形成装置の増加に伴って、機動的に拡大される。また、遠隔管理システム３０が動作するクラウドプラットフォームは、このクラウドプラットフォームのシステム障害やメンテナンスのために、遠隔管理システム３０が把握していないタイミングで、システムの一部がダウンする場合がある。

システム１０は、遠隔管理システム３０を監視する監視システム７０を備えている。監視システム７０は、管理業者によって使用される。監視システム７０は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

システム１０における各ネットワークと、遠隔管理システム３０と、監視システム７０とは、インターネット１１を介して互いに通信可能である。

図２は、遠隔管理システム３０のブロック図である。

図２に示すように、遠隔管理システム３０は、遠隔管理システム３０によって遠隔管理される画像形成装置とのデータ通信を担当するサービスであって、外部との通信を行うためのＷｅｂサーバーを実現するデバイス管理サービス４０と、利用者からは見えないデータ集計や、メール送信、レポート作成といったバッチ処理を実施するサービスであるワーカーサービス５０とを備えている。

デバイス管理サービス４０は、インスタンス４１を備えている。インスタンス４１は、例えばＩＩＳ（Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）など、Ｗｅｂサーバーを実現するためのＷｅｂアプリケーション４１ａを備えている。デバイス管理サービス４０は、インスタンス４１以外にも、インスタンス４１と同様な構成のインスタンスを少なくとも１つ備えている。すなわち、デバイス管理サービス４０は、インスタンスが冗長化されていて、複数のインスタンスで並列分散処理を実行する構成を有しており、本発明の第１の並列分散処理システムを構成している。デバイス管理サービス４０のインスタンスが冗長化されている理由は、例えば、複数のインスタンスによって実行することによる処理の高速化のためや、いずれかのインスタンスに障害が生じた場合に、障害が生じたインスタンスを再起動しても処理を継続することができるためである。

ワーカーサービス５０は、インスタンス５１を備えている。ワーカーサービス５０は、インスタンス５１以外にも、インスタンス５１と同様な構成のインスタンスを少なくとも１つ備えている。すなわち、ワーカーサービス５０は、インスタンスが冗長化されていて、複数のインスタンスで並列分散処理を実行する構成を有しており、本発明の第２の並列分散処理システムを構成している。ワーカーサービス５０のインスタンスが冗長化されている理由は、例えば、複数のインスタンスによって実行することによる処理の高速化のためや、いずれかのインスタンスに障害が生じた場合に、障害が生じたインスタンスを再起動しても処理を継続することができるためである。

遠隔管理システム３０は、ワーカーサービス５０のインスタンスによって実行される処理を示すメッセージを格納するためのメッセージキュー６１を備えている。遠隔管理システム３０は、メッセージキュー６１以外にも、メッセージキュー６１と同様なメッセージキューを少なくとも１つ備えることが可能である。遠隔管理システム３０におけるメッセージキューは、処理の種類毎に設けられている。

遠隔管理システム３０の利用者や画像形成装置が遠隔管理システム３０に何らかの処理を依頼すると、デバイス管理サービス４０のインスタンスのうち、処理中ではないいずれかのインスタンスは、依頼された処理の種類に応じたメッセージキューに、この処理を示すメッセージを格納する。ワーカーサービス５０のインスタンスのうち、処理中ではないいずれかのインスタンスは、遠隔管理システム３０のいずれかのメッセージキューに実行待ちのメッセージが格納されている場合、このメッセージをメッセージキューから取り出した後、このメッセージに応じた処理を実行する。なお、ワーカーサービス５０のインスタンスは、メッセージに応じた処理の実行を開始した後、この処理の実行を終了するまでに、インスタンス自身が再起動などによって終了する場合、この処理の実行を中止して、この処理を示すメッセージを、いずれかのメッセージキューに格納する。

遠隔管理システム３０がデバイス管理サービス４０およびワーカーサービス５０の両方を備えている理由は、遠隔管理システム３０の利用者や画像形成装置がデバイス管理サービス４０を介して遠隔管理システム３０に依頼した処理をワーカーサービス５０で実行することによって、遠隔管理システム３０の利用者や画像形成装置がデバイス管理サービス４０との処理を一旦終了することができ、その結果、遠隔管理システム３０の利用者や画像形成装置がデバイス管理サービス４０を介して新たな処理を遠隔管理システム３０に依頼することができるからである。

遠隔管理システム３０は、デバイス管理サービス４０およびワーカーサービス５０の両方から読み出しまたは書き込みが可能なカウンターを示すカウンター情報６２ａを記憶するキャッシュサービス６２を備えている。

図３は、カウンター情報６２ａの一例を示す図である。

図３に示すように、カウンター情報６２ａは、デバイス管理サービス４０のインスタンスの識別情報（以下「インスタンスＩＤ」という。）と、このインスタンスＩＤが付されたインスタンス用のカウンターの値（以下「カウンター値」という。）と、時刻とを互いに関連付けて、デバイス管理サービス４０のインスタンス毎に含む。カウンター情報６２ａは、デバイス管理サービス４０のインスタンスの復旧に関する処理の状況をデバイス管理サービス４０のインスタンス毎に示す情報であり、本発明の処理状況情報を構成している。したがって、キャッシュサービス６２は、本発明の処理状況記憶部を構成している。

図２に示すように、遠隔管理システム３０は、遠隔管理システム３０のログなどの各種の情報を記憶するＳｔｏｒａｇｅＴａｂｌｅ６３を備えている。ＳｔｏｒａｇｅＴａｂｌｅ６３は、監視システム７０（図１参照。）によって監視される。

デバイス管理サービス４０のインスタンス４１は、インスタンス４１に発生した異常からの復旧に必要な内部処理を実行する復旧処理モジュール４１ｂを備えている。

デバイス管理サービス４０のインスタンスの復旧処理モジュールによって実行される内部処理としては、このインスタンスのＷｅｂサーバーのメモリーダンプを出力する処理である「Ｄｕｍｐ出力」と、このインスタンスの内部でＷｅｂアプリケーションを再起動する処理である「アプリケーション再起動」とが存在する。

「Ｄｕｍｐ出力」とは、デバイス管理サービス４０における対象のインスタンスが外部からの要求を受け付けないと判断された場合に、このインスタンスが外部からの要求を受け付けないと判断された時点での、このインスタンスのＷｅｂサーバーのメモリーダンプを取得、転送することで、後の障害解析を容易にするための処理である。「アプリケーション再起動」とは、デバイス管理サービス４０における対象のインスタンスの内部でＷｅｂアプリケーションを再起動することによって、このインスタンスが新たな要求を受け付けられるようにするための復旧処理である。「アプリケーション再起動」が実行される前には、「Ｄｕｍｐ出力」が必ず実行される。

ワーカーサービス５０のインスタンス５１は、デバイス管理サービス４０のインスタンスを監視する監視モジュール５１ａを備えている。監視モジュール５１ａは、デバイス管理サービス４０のインスタンスの停止が発生しているか否かを監視する処理である「死活監視」、デバイス管理サービス４０のインスタンスによる復旧処理の進行を監視する処理である「リカバリー状況監視」、および、「通知判断」という３つの処理を実行する。

「死活監視」は、ワーカーサービス５０からデバイス管理サービス４０のインスタンスに対して、５０３ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）エラーなど、処理の滞留によるインスタンスの停止が発生していないかを監視する処理である。

「リカバリー状況監視」は、遠隔管理システム３０が動作するパブリッククラウドにおいて、デバイス管理サービス４０のデプロイ済みのいずれかのインスタンスをＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）レベルで再起動するための操作である「インスタンス再起動」を、「アプリケーション再起動」によって障害の復旧が行われない場合に行う処理である。「リカバリー状況監視」は、例えば、遠隔管理システム３０の外部からの過負荷による障害である場合や、Ｗｅｂアプリケーションの障害ではなく、デバイス管理サービス４０のインスタンス自体の障害である場合など、デバイス管理サービス４０の復旧処理モジュール４１ｂによって実施された「アプリケーション再起動」によっても、障害が解消されない場合に、パブリッククラウド側に「インスタンス再起動」を要求する。パブリッククラウドは、ワーカーサービス５０の監視モジュール５１ａによって「インスタンス再起動」が要求された場合、要求された「インスタンス再起動」の対象のインスタンスの再起動を行う。

「通知判断」は、「インスタンス再起動」によっても障害が復旧しない場合に、遠隔管理システム３０による自律復旧処理の失敗の通知を監視システム７０に実行させるための通知用ログをＳｔｏｒａｇｅＴａｂｌｅ６３に記憶する処理である。

遠隔管理システム３０は、ワーカーサービス５０にデバイス管理サービス４０のインスタンスを監視させる処理（以下「監視処理」という。）のためのメッセージ（以下「監視メッセージ」という。）を、例えば５分毎など、定期的に発行する監視メッセージ発行部６４を備えている。

図４は、１台のコンピューターによって構成される場合の監視システム７０のブロック図である。

図４に示す監視システム７０は、種々の操作が入力される例えばキーボード、マウスなどの操作デバイスである操作部７１と、種々の情報を表示する例えばＬＣＤなどの表示デバイスである表示部７２と、ＬＡＮ、インターネットなどのネットワーク経由で、または、ネットワークを介さずに有線または無線によって直接に、外部の装置と通信を行う通信デバイスである通信部７３と、各種の情報を記憶する例えば半導体メモリー、ＨＤＤなどの不揮発性の記憶デバイスである記憶部７４と、監視システム７０全体を制御する制御部７５とを備えている。

記憶部７４は、遠隔管理システム３０（図２参照。）を監視するための監視プログラム７４ａを記憶している。監視プログラム７４ａは、例えば、監視システム７０の製造段階で監視システム７０にインストールされていても良いし、ＣＤ、ＤＶＤ、ＵＳＢメモリーなどの外部の記憶媒体から監視システム７０に追加でインストールされても良いし、ネットワーク上から監視システム７０に追加でインストールされても良い。

記憶部７４は、各種の情報の連絡先を示す連絡先情報７４ｂを記憶している。連絡先情報７４ｂに示される連絡先は、例えば電子メールアドレスである。連絡先情報７４ｂは、例えば、遠隔管理システム３０の開発者の連絡先や、遠隔管理システム３０の利用者の連絡先など、複数の連絡先を示しても良い。

制御部７５は、例えば、ＣＰＵと、プログラムおよび各種のデータを記憶しているＲＯＭと、制御部７５のＣＰＵの作業領域として用いられるメモリーとしてのＲＡＭとを備えている。制御部７５のＣＰＵは、記憶部７４または制御部７５のＲＯＭに記憶されているプログラムを実行する。

制御部７５は、監視プログラム７４ａを実行することによって、遠隔管理システム３０の構成要素を監視する構成要素監視部７５ａと、構成要素監視部７５ａによる監視結果が事前に定めた条件を満たす場合に、連絡先情報７４ｂに示す連絡先に対して通知を実行する通知実行部７５ｂとを実現する。

次に、システム１０の動作について説明する。

まず、インスタンスが起動される場合の復旧処理モジュールの動作について説明する。

図５は、インスタンスが起動される場合の復旧処理モジュールの動作のフローチャートである。

デバイス管理サービス４０のインスタンスが起動されると、このインスタンスの復旧処理モジュールは、図５に示す動作を実行する。

図５に示すように、復旧処理モジュールは、復旧処理モジュール自身を備えるインスタンス用のカウンター値にカウンター情報６２ａにおいて０を登録する（Ｓ１０１）。

次いで、復旧処理モジュールは、カウンター情報６２ａにおいて、復旧処理モジュール自身を備えるインスタンスに関連付けられた時刻として現在時刻を登録して（Ｓ１０２）、図５に示す動作を終了する。

次に、インスタンスの内部でＷｅｂアプリケーションが起動される場合の復旧処理モジュールの動作について説明する。

図６は、インスタンスの内部でＷｅｂアプリケーションが起動される場合の復旧処理モジュールの動作のフローチャートである。

例えば、デバイス管理サービス４０のインスタンスが起動されると、このインスタンスは、内部でＷｅｂアプリケーションを起動する。また、デバイス管理サービス４０のインスタンスは、Ｗｅｂアプリケーションを再起動する場合もある。デバイス管理サービス４０のインスタンスの内部でＷｅｂアプリケーションが起動されると、このインスタンスの復旧処理モジュールは、図６に示す動作を実行する。

図６に示すように、復旧処理モジュールは、復旧処理モジュール自身を備えるインスタンス用のカウンター値をカウンター情報６２ａにおいて０に更新する（Ｓ１２１）。

次いで、復旧処理モジュールは、カウンター情報６２ａにおいて、復旧処理モジュール自身を備えるインスタンスに関連付けられた時刻を現在時刻に更新して（Ｓ１２２）、図６に示す動作を終了する。

次に、インスタンスの内部のＷｅｂアプリケーションの起動後の復旧処理モジュールの動作について説明する。

図７は、インスタンスの内部のＷｅｂアプリケーションの起動後の復旧処理モジュールの動作のフローチャートである。

デバイス管理サービス４０のインスタンスの内部でＷｅｂアプリケーションが起動されると、このインスタンスの復旧処理モジュールは、図７に示す動作を実行する。

図７に示すように、復旧処理モジュールは、復旧処理モジュール自身を備えるインスタンス用のカウンター値を、このインスタンスのインスタンスＩＤに基づいてカウンター情報６２ａから取得する（Ｓ１４１）。

次いで、復旧処理モジュールは、Ｓ１４１において取得したカウンター値が特定の値以上であるか否かを判断する（Ｓ１４２）。Ｓ１４２における「特定の値」は、例えば５である。

復旧処理モジュールは、Ｓ１４１において取得したカウンター値が特定の値以上ではないとＳ１４２において判断すると、Ｓ１４１の処理を実行する。

復旧処理モジュールは、Ｓ１４１において取得したカウンター値が特定の値以上であるとＳ１４２において判断すると、復旧処理モジュール自身を備えるインスタンス用のカウンター値をカウンター情報６２ａにおいて−１に更新する（Ｓ１４３）。

次いで、復旧処理モジュールは、カウンター情報６２ａにおいて、復旧処理モジュール自身を備えるインスタンスに関連付けられた時刻を現在時刻に更新する（Ｓ１４４）。

次いで、復旧処理モジュールは、復旧処理モジュール自身を備えるインスタンスの内部でＷｅｂアプリケーションを再起動する（Ｓ１４５）。

次いで、復旧処理モジュールは、Ｓ１４５における復旧処理の内容のログをＳｔｏｒａｇｅＴａｂｌｅ６３に記憶して（Ｓ１４６）、Ｓ１４１の処理を実行する。

次に、監視処理を実行する場合のワーカーサービス５０のインスタンスの監視モジュールの動作について説明する。

図８は、監視処理を実行する場合のワーカーサービス５０のインスタンスの監視モジュールの動作のフローチャートである。

監視メッセージ発行部６４は、監視メッセージを、例えば５分毎など、定期的に発行し、監視処理用のメッセージキュー（以下「監視メッセージキュー」という。）に、この監視メッセージを格納する。ワーカーサービス５０のインスタンスのうち、処理中ではないいずれかのインスタンスは、監視メッセージキューに実行待ちの監視メッセージが格納されている場合、この監視メッセージを監視メッセージキューから取り出した後、この監視メッセージに応じた監視処理を、図８に示すように実行する。

図８に示すように、ワーカーサービス５０のインスタンスのうち、図８に示す動作を実行するインスタンスの監視モジュール（以下「対象監視モジュール」という。）は、今回の監視処理の開始のログをＳｔｏｒａｇｅＴａｂｌｅ６３に記憶する（Ｓ１６１）。

次いで、対象監視モジュールは、デバイス管理サービス４０のインスタンスのリストをパブリッククラウドから取得する（Ｓ１６２）。

次いで、対象監視モジュールは、デバイス管理サービス４０のインスタンス別に実行する処理であるインスタンス別監視処理を、Ｓ１６２において取得したリストに示されているインスタンスのそれぞれに対して並行して実行する（Ｓ１６３）。

図９は、図８に示すインスタンス別監視処理のフローチャートである。

図９に示すように、対象監視モジュールは、デバイス管理サービス４０のインスタンスのうち、今回のインスタンス別監視処理の対象のもの（以下、図９および図１０に示す動作の説明において「対象インスタンス」という。）のカウンター値を、対象インスタンスのインスタンスＩＤに基づいてカウンター情報６２ａから取得する（Ｓ１８１）。

次いで、対象監視モジュールは、Ｓ１８１において取得したカウンター値が０以上であるか否かを判断する（Ｓ１８２）。

対象監視モジュールは、Ｓ１８１において取得したカウンター値が０以上であるとＳ１８２において判断すると、図１０に示す監視詳細処理を実行する（Ｓ１８３）。

図１０は、図９に示す監視詳細処理のフローチャートである。

図１０に示すように、対象監視モジュールは、対象インスタンスに対する監視用のＷｅｂリクエストを作成する（Ｓ２０１）。

次いで、対象監視モジュールは、Ｓ２０１において作成したＷｅｂリクエストを、特定の時間のリクエストタイムアウト値を設定して実行する（Ｓ２０２）。

なお、Ｓ２０１〜Ｓ２０２の処理は、上述した「死活監視」に関する処理である。

対象監視モジュールは、Ｓ２０２の処理の後、Ｓ２０２における実行の結果を判断する（Ｓ２０３）。

対象監視モジュールは、Ｓ２０２における実行の結果が、Ｓ２０２において実行したＷｅｂリクエストに対して対象インスタンスから正常なレスポンスが届いたとＳ２０３において判断すると、カウンター情報６２ａにおいて対象インスタンス用のカウンター値を０に更新して（Ｓ２０４）、カウンター情報６２ａにおいて対象インスタンスに関連付けられた時刻（以下「対象カウンター時刻」という。）を現在時刻に更新する（Ｓ２０５）。

対象監視モジュールは、Ｓ２０２における実行の結果が、５０３ＨＴＴＰエラーであった、または、Ｓ２０２において設定したリクエストタイムアウト値に応じたタイムアウトであったとＳ２０３において判断すると、カウンター情報６２ａにおける対象インスタンス用のカウンター値が特定の閾値以上であるか否かを判断する（Ｓ２０６）。Ｓ２０６における閾値は、例えば１０など、正の値である。

対象監視モジュールは、カウンター情報６２ａにおける対象インスタンス用のカウンター値が特定の閾値以上ではないとＳ２０６において判断すると、カウンター情報６２ａにおいて対象インスタンス用のカウンター値を１だけ増加させて（Ｓ２０７）、対象カウンター時刻を現在時刻に更新する（Ｓ２０８）。

対象監視モジュールは、カウンター情報６２ａにおける対象インスタンス用のカウンター値が特定の閾値以上であるとＳ２０６において判断すると、カウンター情報６２ａにおいて対象インスタンス用のカウンター値を−２に更新して（Ｓ２０９）、対象カウンター時刻を現在時刻に更新する（Ｓ２１０）。

次いで、対象監視モジュールは、対象インスタンスに関してパブリッククラウド側に「インスタンス再起動」を要求する（Ｓ２１１）。

対象監視モジュールは、Ｓ２０２における実行の結果が、５０３ＨＴＴＰエラーおよびタイムアウトのいずれでもないエラーであったとＳ２０３において判断すると、このエラーのログをＳｔｏｒａｇｅＴａｂｌｅ６３に記憶する（Ｓ２１２）。

対象監視モジュールは、Ｓ２０５、Ｓ２０８、Ｓ２１１またはＳ２１２の処理の後、図１０に示す監視詳細処理を終了する。

図９に示すように、対象監視モジュールは、Ｓ１８１において取得したカウンター値が０以上ではないとＳ１８２において判断すると、対象カウンター時刻を取得する（Ｓ１８４）。

次いで、対象監視モジュールは、Ｓ１８４において取得した対象カウンター時刻に特定の時間を足した時刻より現在時刻が後であるか否かを判断する（Ｓ１８５）。Ｓ１８５における「特定の時間」は、例えば２０分である。

対象監視モジュールは、対象カウンター時刻に特定の時間を足した時刻より現在時刻が後であるとＳ１８５において判断すると、カウンター情報６２ａにおける対象インスタンス用のカウンター値が−２以下であるか否かを判断する（Ｓ１８６）。

対象監視モジュールは、カウンター情報６２ａにおける対象インスタンス用のカウンター値が−２以下ではないとＳ１８６において判断すると、カウンター情報６２ａにおいて対象インスタンス用のカウンター値を１だけ減少させて（Ｓ１８７）、カウンター情報６２ａにおいて対象カウンター時刻を現在時刻に更新する（Ｓ１８８）。

次いで、対象監視モジュールは、対象インスタンスに関してパブリッククラウド側に「インスタンス再起動」を要求する（Ｓ１８９）。

なお、Ｓ１８２、Ｓ１８４〜Ｓ１８９の処理は、上述した「リカバリー状況監視」に関する処理である。

対象監視モジュールは、カウンター情報６２ａにおける対象インスタンス用のカウンター値が−２以下であるとＳ１８６において判断すると、カウンター情報６２ａにおいて対象カウンター時刻を現在時刻に更新する（Ｓ１９０）。

次いで、対象監視モジュールは、遠隔管理システム３０による自律復旧処理の失敗を監視システム７０に通知させるための通知用ログをＳｔｏｒａｇｅＴａｂｌｅ６３に記憶する（Ｓ１９１）。

なお、Ｓ１８２、Ｓ１８４〜Ｓ１８６およびＳ１９０〜Ｓ１９１の処理は、上述した「通知判断」に関する処理である。

対象監視モジュールは、Ｓ１８３の処理が終了するか、対象カウンター時刻に特定の時間を足した時刻より現在時刻が後ではないとＳ１８５において判断するか、Ｓ１８９またはＳ１９１の処理が終了すると、今回の監視処理による監視結果をＳｔｏｒａｇｅＴａｂｌｅ６３に記憶し（Ｓ１９２）、図９に示すインスタンス別監視処理を終了する。

図８に示すように、対象監視モジュールは、Ｓ１６３の処理の後、今回の監視処理の終了のログをＳｔｏｒａｇｅＴａｂｌｅ６３に記憶して（Ｓ１６４）、図８に示す動作を終了する。

次に、遠隔管理システム３０におけるデバイス管理サービス４０の障害の復旧処理の処理パターンの類型について説明する。

なお、以下においては、Ｓ１４２における「特定の値」、Ｓ１８５における「特定の時間」、Ｓ２０６における閾値は、それぞれ、５、２０分、１０であるものとする。

図１１（ａ）は、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が成功する場合のフローチャートである。図１１（ｂ）は、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が失敗するが、このインスタンスの再起動が成功する場合のフローチャートである。図１１（ｃ）は、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が失敗し、このインスタンスの再起動も失敗する場合のフローチャートである。図１２（ａ）は、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が開始されないが、このインスタンスの再起動が成功する場合のフローチャートである。図１２（ｂ）は、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が開始されず、このインスタンスの再起動も失敗する場合のフローチャートである。

図１１および図１２に示す動作の説明においては、デバイス管理サービス４０の全てのインスタンスを代表して、１つのインスタンス（以下、図１１および図１２に示す動作の説明において「対象インスタンス」という。）について説明する。

まず、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が成功する場合について、図１１（ａ）を用いて説明する。

デバイス管理サービス４０の対象インスタンスが起動され、対象インスタンスの内部でＷｅｂアプリケーションが起動されると、Ｓ１０１の処理およびＳ１２１の処理によって、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定される。また、デバイス管理サービス４０の対象インスタンスが正常である場合には（Ｓ２０３で正常）、対象インスタンス用のカウンター値は、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、０に設定される（Ｓ２０４）。したがって、デバイス管理サービス４０の対象インスタンスの異常が発生するまでは、対象インスタンス用のカウンター値は、０である。

図１１（ａ）に示すように、デバイス管理サービス４０の対象インスタンスの異常が発生すると、対象インスタンスに対するワーカーサービス５０のいずれかのインスタンスの監視モジュールによる監視用のＷｅｂリクエストに対して５０３ＨＴＴＰエラーやタイムアウトが発生するので（Ｓ２０３で５０３ＨＴＴＰエラーまたはタイムアウト）、ワーカーサービス５０のこのインスタンスの監視モジュールによって、デバイス管理サービス４０の対象インスタンス用のカウンター値は、Ｓ２０７の処理によって１に設定される（Ｓ２２１）。

同様にして、デバイス管理サービス４０の対象インスタンスに対するワーカーサービス５０のいずれかのインスタンスの監視モジュールによる監視用のＷｅｂリクエストに対して５０３ＨＴＴＰエラーやタイムアウトが合計で５回連続して発生すると、ワーカーサービス５０のこれらのインスタンスの監視モジュールによって、デバイス管理サービス４０の対象インスタンス用のカウンター値は、合計５回のＳ２０７の処理によって５に設定される（Ｓ２２２）。

そして、デバイス管理サービス４０の対象インスタンス用のカウンター値が５以上になると（Ｓ１４２でＹＥＳ）、このカウンター値は、対象インスタンスの復旧処理モジュールによって、Ｓ１４３の処理によって−１に設定され（Ｓ２２３）、対象インスタンスの内部のＷｅｂアプリケーションは、この復旧処理モジュールによって、Ｓ１４５の処理によって再起動させられる。

デバイス管理サービス４０の対象インスタンスの内部のＷｅｂアプリケーションの再起動が成功すると、Ｓ１２１の処理によって、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定される（Ｓ２２４）。対象インスタンスのＷｅｂアプリケーションの再起動が成功した場合、対象インスタンスは、正常である。

次に、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が失敗するが、このインスタンスの再起動が成功する場合について、図１１（ｂ）を用いて説明する。

上述したように、デバイス管理サービス４０の対象インスタンスの異常が発生するまでは、対象インスタンス用のカウンター値は、０である。

図１１（ｂ）に示すように、Ｓ２２１〜Ｓ２２３に関しては、図１１（ａ）に示す処理と同様である。

Ｓ２２３の処理の後、デバイス管理サービス４０の対象インスタンスのＷｅｂアプリケーションの再起動が失敗すると、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定されることはない。したがって、このカウンター値がＳ１４３の処理によって−１に設定された直後のＳ１４４の処理において、対象インスタンスの復旧処理モジュールによって更新された、対象インスタンスに関連付けられた時刻から２０分が経過しても、このカウンター値は、−１のままである（Ｓ２４１）。

デバイス管理サービス４０の対象インスタンスのＷｅｂアプリケーションが、対象インスタンスの復旧処理モジュールによって、Ｓ１４５の処理によって再起動させられた後、対象インスタンス用のカウンター値が−１のまま、デバイス管理サービス４０の対象インスタンスに関連付けられた時刻から２０分が経過すると（Ｓ１８５でＹＥＳ）、対象インスタンス用のカウンター値は、Ｓ１８７の処理によって、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、−２に設定され（Ｓ２４２）、デバイス管理サービス４０の対象インスタンスは、この監視モジュールによって、Ｓ１８９の処理によって再起動が要求される。

デバイス管理サービス４０の対象インスタンスの再起動が成功すると、対象インスタンスの内部でＷｅｂアプリケーションが起動されるので、Ｓ１０１の処理およびＳ１２１の処理によって、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定される（Ｓ２４３）。デバイス管理サービス４０の対象インスタンスの再起動が成功した場合、対象インスタンスは、正常である。

次に、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が失敗し、このインスタンスの再起動も失敗する場合について、図１１（ｃ）を用いて説明する。

上述したように、デバイス管理サービス４０の対象インスタンスの異常が発生するまでは、対象インスタンス用のカウンター値は、０である。

図１１（ｃ）に示すように、Ｓ２２１〜Ｓ２２３、Ｓ２４１〜Ｓ２４２に関しては、図１１（ｂ）に示す処理と同様である。

Ｓ２４２の処理の後、デバイス管理サービス４０の対象インスタンスの再起動が失敗すると、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定されることはない。したがって、このカウンター値がＳ１８７の処理によって−２に設定された直後のＳ１８８の処理において、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって更新された、対象インスタンスに関連付けられた時刻から２０分が経過しても、このカウンター値は、−２のままである（Ｓ２６１）。

デバイス管理サービス４０の対象インスタンスが、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、Ｓ１８９の処理によって再起動が要求された後、対象インスタンス用のカウンター値が−２のまま、対象インスタンスに関連付けられた時刻から２０分が経過すると（Ｓ１８５でＹＥＳ）、Ｓ１９１の処理によって、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、通知用ログがＳｔｏｒａｇｅＴａｂｌｅ６３に記憶される。ＳｔｏｒａｇｅＴａｂｌｅ６３に通知用ログが記憶されると、ＳｔｏｒａｇｅＴａｂｌｅ６３を監視する監視システム７０は、ＳｔｏｒａｇｅＴａｂｌｅ６３に記憶されている通知用ログに基づいて、対象インスタンスに関して遠隔管理システム３０による自律復旧処理の失敗を、連絡先情報７４ｂに示す連絡先に対して電子メールで通知する。したがって、この電子メールを確認した人間によって、遠隔管理システム３０の障害の復旧処理が実行される。

次に、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が開始されないが、このインスタンスの再起動が成功する場合について、図１２（ａ）を用いて説明する。

上述したように、デバイス管理サービス４０の対象インスタンスの異常が発生するまでは、対象インスタンス用のカウンター値は、０である。

図１２（ａ）に示すように、Ｓ２２１〜Ｓ２２２に関しては、図１１（ａ）に示す処理と同様である。

しかしながら、デバイス管理サービス４０の対象インスタンスに障害が発生している場合、対象インスタンス用のカウンター値が５以上になっても、対象インスタンスの復旧処理モジュールによって、このカウンター値が−１に設定されたり、対象インスタンスの内部のＷｅｂアプリケーションが再起動させられたりすることはない。

したがって、デバイス管理サービス４０の対象インスタンスに対するワーカーサービス５０のいずれかのインスタンスの監視モジュールによる監視用のＷｅｂリクエストに対して５０３ＨＴＴＰエラーやタイムアウトが更に５回連続して発生することによって合計で１０回連続して発生すると、ワーカーサービス５０のこれらのインスタンスの監視モジュールによって、デバイス管理サービス４０の対象インスタンス用のカウンター値は、合計１０回のＳ２０７の処理によって１０に設定される（Ｓ２８１）。

そして、デバイス管理サービス４０の対象インスタンス用のカウンター値が１０以上になると（Ｓ２０６でＹＥＳ）、このカウンター値は、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、Ｓ２０９の処理によって−２に設定され（Ｓ２８２）、対象インスタンスは、この監視モジュールによって、Ｓ２１１の処理によって再起動が要求される。

デバイス管理サービス４０の対象インスタンスの再起動が成功すると、対象インスタンスの内部でＷｅｂアプリケーションが起動されるので、Ｓ１０１の処理およびＳ１２１の処理によって、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定される（Ｓ２８３）。デバイス管理サービス４０の対象インスタンスの再起動が成功した場合、対象インスタンスは、正常である。

次に、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が開始されず、このインスタンスの再起動も失敗する場合について、図１２（ｂ）を用いて説明する。

上述したように、デバイス管理サービス４０の対象インスタンスの異常が発生するまでは、対象インスタンス用のカウンター値は、０である。

図１２（ｂ）に示すように、Ｓ２２１〜Ｓ２２２、Ｓ２８１〜Ｓ２８２に関しては、図１２（ａ）に示す処理と同様である。

Ｓ２８２の処理の後、デバイス管理サービス４０の対象インスタンスの再起動が失敗すると、対象インスタンス用のカウンター値は、対象インスタンスの復旧処理モジュールによって、０に設定されることはない。したがって、このカウンター値がＳ２０９の処理によって−２に設定された直後のＳ２１０の処理において、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって更新された、対象インスタンスに関連付けられた時刻から２０分が経過しても、このカウンター値は、−２のままである（Ｓ３０１）。

デバイス管理サービス４０の対象インスタンスが、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、Ｓ２１１の処理によって再起動が要求された後、対象インスタンス用のカウンター値が−２のまま、対象インスタンスに関連付けられた時刻から２０分が経過すると（Ｓ１８５でＹＥＳ）、Ｓ１９１の処理によって、ワーカーサービス５０のいずれかのインスタンスの監視モジュールによって、通知用ログがＳｔｏｒａｇｅＴａｂｌｅ６３に記憶される。ＳｔｏｒａｇｅＴａｂｌｅ６３に通知用ログが記憶されると、ＳｔｏｒａｇｅＴａｂｌｅ６３を監視する監視システム７０は、ＳｔｏｒａｇｅＴａｂｌｅ６３に記憶されている通知用ログに基づいて、対象インスタンスに関して遠隔管理システム３０による自律復旧処理の失敗を、連絡先情報７４ｂに示す連絡先に対して電子メールで通知する。したがって、この電子メールを確認した人間によって、遠隔管理システム３０の障害の復旧処理が実行される。

以上に説明したように、デバイス管理サービス４０のインスタンスのそれぞれは、インスタンス自身の復旧に関する処理の状況をカウンター情報６２ａから取得する（Ｓ１４１）とともに、インスタンス自身の復旧に関する処理を実行した場合に、この処理の状況をカウンター情報６２ａに記憶する（Ｓ１０１〜Ｓ１０２、Ｓ１２１〜Ｓ１２２、Ｓ１４３〜Ｓ１４４）。また、ワーカーサービス５０のインスタンスのそれぞれは、デバイス管理サービス４０のインスタンスの復旧に関する処理の状況をカウンター情報６２ａから取得する（Ｓ１８１、Ｓ１８４）とともに、デバイス管理サービス４０のインスタンスの復旧に関する処理を実行した場合に、この処理の状況をカウンター情報６２ａに記憶する（Ｓ１８７〜Ｓ１８８、Ｓ１９０、Ｓ２０４〜Ｓ２０５、Ｓ２０７〜Ｓ２０８、Ｓ２０９〜Ｓ２１０）。この構成により、遠隔管理システム３０は、デバイス管理サービス４０のインスタンスの復旧に関する処理を、デバイス管理サービス４０のインスタンス自身と、ワーカーサービス５０のインスタンスとによって実行するので、デバイス管理サービス４０に対応する待機系のシステムが不要であり、運用コストを抑えることができる。

ワーカーサービス５０のインスタンスの監視モジュールは、デバイス管理サービス４０のインスタンスの復旧に関する処理の状況を、ワーカーサービス５０からもデバイス管理サービス４０からも独立したキャッシュサービス６２のカウンター情報６２ａに書き込む。したがって、遠隔管理システム３０は、デバイス管理サービス４０と、ワーカーサービス５０とがそれぞれ複数のインスタンスで冗長化された構成であるにもかかわらず、インスタンスの数が変動しても問題なく動作を継続することができ、適切な障害検知と、適切な自律復旧とを実現することができる。

遠隔管理システム３０において、デバイス管理サービス４０のインスタンスは、このインスタンスの異常に対するワーカーサービス５０のインスタンスによる監視の状況が特定の状況になったことがカウンター情報６２ａに示された場合（Ｓ１４２でＹＥＳ）に、デバイス管理サービス４０のインスタンス自身の復旧に関する処理として、デバイス管理サービス４０のインスタンス自身のＷｅｂアプリケーションを再起動する（Ｓ１４５）。この構成により、遠隔管理システム３０は、デバイス管理サービス４０のインスタンスの異常に対するワーカーサービス５０のインスタンスによる監視の状況に応じて、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションを再起動するので、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動を適切なタイミングで実行することができる。

遠隔管理システム３０において、ワーカーサービス５０のインスタンスは、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動から特定の時間が経過しても、このアプリケーションの再起動が成功したことがカウンター情報６２ａに示されない場合（Ｓ１８５でＹＥＳおよびＳ１８６でＮＯ）に、デバイス管理サービス４０のこのインスタンスの再起動を要求する（Ｓ１８９）。この構成により、遠隔管理システム３０は、デバイス管理サービス４０のインスタンスのＷｅｂアプリケーションの再起動が失敗した場合に、このインスタンスの再起動を適切なタイミングで実行することができる。

遠隔管理システム３０において、ワーカーサービス５０のインスタンスは、デバイス管理サービス４０のインスタンスの再起動の要求から特定の時間が経過しても、このインスタンスの再起動が成功したことがカウンター情報６２ａに示されない場合（Ｓ１８５でＹＥＳおよびＳ１８６でＹＥＳ）に、自律復旧処理の失敗の通知のための処理（Ｓ１９１）を実行する。この構成により、遠隔管理システム３０は、デバイス管理サービス４０のインスタンスの再起動が失敗した場合に、自律復旧処理の失敗の通知のための処理を実行するので、人間による復旧処理を適切なタイミングで受ける可能性を向上することができる。

本発明の処理状況記憶部は、本実施の形態においてキャッシュサービス６２であるが、キャッシュサービス以外の記憶部でも良い。例えば、本発明の処理状況記憶部は、データベースやストレージテーブルでも良い。

３０ 遠隔管理システム（情報処理システム）
４０ デバイス管理サービス（第１の並列分散処理システム）
４１ インスタンス
５０ ワーカーサービス（第２の並列分散処理システム）
５１ インスタンス
６２ キャッシュサービス（処理状況記憶部）
６２ａ カウンター情報（処理状況情報）

Claims (4)

1. 複数のインスタンスを備え、これらのインスタンスで並列分散処理を実行する第１の並列分散処理システムと、
   複数のインスタンスを備え、これらのインスタンスで並列分散処理を実行する第２の並列分散処理システムと、
   前記第１の並列分散処理システムの前記インスタンスの復旧に関する処理の状況を前記第１の並列分散処理システムの前記インスタンス毎に示す処理状況情報を記憶する処理状況記憶部と
   を備え、
   前記第１の並列分散処理システムの前記インスタンスのそれぞれは、インスタンス自身の復旧に関する処理の状況を前記処理状況情報から取得するとともに、インスタンス自身の復旧に関する処理を実行した場合に、この処理の状況を前記処理状況情報に記憶し、
   前記第２の並列分散処理システムの前記インスタンスのそれぞれは、前記第１の並列分散処理システムの前記インスタンスの復旧に関する処理の状況を前記処理状況情報から取得するとともに、前記第１の並列分散処理システムの前記インスタンスの復旧に関する処理を実行した場合に、この処理の状況を前記処理状況情報に記憶することを特徴とする情報処理システム。
2. 前記第１の並列分散処理システムの前記インスタンスは、このインスタンスの異常に対する前記第２の並列分散処理システムの前記インスタンスによる監視の状況が特定の状況になったことが前記処理状況情報に示された場合に、前記第１の並列分散処理システムの前記インスタンス自身の復旧に関する処理として、前記第１の並列分散処理システムの前記インスタンス自身のアプリケーションを再起動することを特徴とする請求項１に記載の情報処理システム。
3. 前記第２の並列分散処理システムの前記インスタンスは、前記第１の並列分散処理システムの前記インスタンスの前記アプリケーションの再起動から特定の時間が経過しても、このアプリケーションの再起動が成功したことが前記処理状況情報に示されない場合に、前記第１の並列分散処理システムのこのインスタンスの再起動を要求することを特徴とする請求項２に記載の情報処理システム。
4. 前記第２の並列分散処理システムの前記インスタンスは、前記第１の並列分散処理システムの前記インスタンスの再起動の要求から特定の時間が経過しても、このインスタンスの再起動が成功したことが前記処理状況情報に示されない場合に、自律復旧処理の失敗の通知のための処理を実行することを特徴とする請求項３に記載の情報処理システム。

Images