JP2014191816A - 情報処理装置、制御方法、プログラム、及び情報処理システム - Google Patents

Abstract

【課題】アクションを実行する情報処理装置の切り替えを円滑に行うこと。
【解決手段】他の情報処理装置１２と同じデータ１１を取得する情報処理装置１６が提供される。当該情報処理装置１６は、他の情報処理装置１２においてデータ１１の取得に応じて実行されるアクションが正常に完了した場合に他の情報処理装置１２から受信される、アクションによって処理されたデータを示す履歴情報１５を記憶する記憶部１７と、データ１１を取得したとき、記憶部１７の履歴情報１５の格納状況に基づいて、情報処理装置１６がアクションの実行を抑止するか、他の情報処理装置１２に代わって情報処理装置１６がアクションを実行するかを決定する制御部１８とを有する。
【選択図】図１

Description

本発明は、情報処理システム、情報処理装置、及びプログラムに関する。

情報処理システムの中には、耐故障性を高めるため、同じ機能を有する（例えば、同じソフトウェアを搭載した）複数の情報処理装置を用意し、１つの情報処理装置に障害が発生しても他の情報処理装置が情報処理を引き継げるように冗長化されたものがある。現時点でサービス提供の責任を受けもっている情報処理装置は主系・稼働系・現用系と呼ばれることがあり、他の情報処理装置は従系・待機系・予備系と呼ばれることがある。

障害発生時に主系の切り替えを迅速に行ってサービス停止時間を短くしたい場合には、主系の情報処理装置が正常に稼働している間も従系の情報処理装置を立ち上げておくことがある。かかる形態の冗長化システムの中には、正常時から従系の情報処理装置が主系の情報処理装置と同じデータを継続的に取得するようにしたものがある。

例えば、現用系と予備系の２台の計算機を用いて無線機などの設備の状態を監視する二重化監視システムが提案されている。この二重化監視システムでは、設備の障害を検出した検出装置が現用系と予備系の両方の計算機に対してアラームデータを送信し、両方の計算機がそれぞれ統計データを生成する。２台の計算機のうち現用系の計算機によって生成された統計データが、スイッチによって選択されてプリンタに出力される。

また、例えば、データベースを備えた稼働系のサーバ計算機と、稼働系と同じ内容のデータベースを備えた待機系のサーバ計算機とを含む、複数サーバ計算機システムが提案されている。この複数サーバ計算機システムでは、端末計算機が稼働系と待機系の両方のサーバ計算機に対してデーベースの更新依頼を送信し、両方のサーバ計算機がそれぞれデータベースを更新する。更新依頼に対するレスポンスは、稼働系と待機系のサーバ計算機のうち稼働系のサーバ計算機のみが端末計算機に対して送信する。

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

上記のように、正常時から主系と従系の情報処理装置が同じデータを取得する一方、主系と従系のうち主系の情報処理装置のみがアクション（例えば、プリンタへの出力やレスポンスの送信）を行う冗長化システムが考えられる。しかし、かかる形態の冗長化システムでは、障害発生時の主系の切り替えをどのように行えばよいかが問題となる。

上記の二重化監視システムでは、２台の計算機の外部にあるスイッチが現用系の計算機の切り替えを行っている。また、上記の複数サーバ計算機システムでは、各サーバ計算機は自身が稼働系であるか待機系であるかを予め知っていることを前提としている。主系の切り替えを外部からの指示（例えば、ユーザによる手動での設定変更）に応じて行う場合には、主系の切り替えが完了するまでの遅延が大きくなるおそれがある。

また、主系と従系の情報処理装置が同じデータを取得するタイミングは、厳密に一致するとは限らない。このため、主系の切り替えにあたっては、障害発生の前後で同じデータに対するアクションが二重に実行されないよう制御することが好ましい。すなわち、障害発生前に主系だった情報処理装置がアクションを実行済みのデータについては、障害発生後に主系になった情報処理装置がアクションを再び実行しないことが好ましい。

そこで、１つの側面では、本発明は、アクションを実行する情報処理装置の切り替えを円滑に行うことができる情報処理システム、情報処理装置、及びプログラムを提供することを目的とする。

１つの側面では、同じデータを取得する第１及び第２の情報処理装置を含む情報処理システムが提供される。第１の情報処理装置は、データの取得に応じてアクションを実行する演算部と、アクションが正常に完了した場合に、アクションによって処理されたデータを示す履歴情報を第２の情報処理装置に送信する通信部と、を有する。第２の情報処理装置は、第１の情報処理装置から受信された履歴情報を記憶する記憶部と、データを取得したとき、記憶部の履歴情報の格納状況に基づいて、第２の情報処理装置がアクションの実行を抑止するか、第１の情報処理装置に代わって第２の情報処理装置がアクションを実行するかを決定する制御部と、を有する。

他の１つの側面では、他の情報処理装置と同じデータを取得する情報処理装置が提供される。当該情報処理装置は、他の情報処理装置においてデータの取得に応じて実行されるアクションが正常に完了した場合に他の情報処理装置から受信される、アクションによって処理されたデータを示す履歴情報を記憶する記憶部と、データを取得したとき、記憶部の履歴情報の格納状況に基づいて、情報処理装置がアクションの実行を抑止するか、他の情報処理装置に代わって情報処理装置がアクションを実行するかを決定する制御部とを有する。

他の１つの側面では、他のコンピュータと同じデータを取得するコンピュータに、他のコンピュータにおいてデータの取得に応じて実行されるアクションが正常に完了した場合に、他のコンピュータからアクションによって処理されたデータを示す履歴情報を受信し、履歴情報をコンピュータが備える記憶部に格納し、データを取得したとき、記憶部の履歴情報の格納状況に基づいて、コンピュータがアクションの実行を抑止するか、他のコンピュータに代わってコンピュータがアクションを実行するかを決定する処理を実行させるプログラムが提供される。

１つの側面では、アクションを実行する情報処理装置の切り替えを円滑に行うことができるようになる。

第１の実施の形態に係る情報処理システムの例を示した図である。 第２の実施の形態に係る情報処理システムの例を示した図である。 第２の実施の形態に係る第１情報処理装置のハードウェアの例を示した図である。 第２の実施の形態に係る第１情報処理装置の機能を示したブロック図である。 第２の実施の形態に係る第２情報処理装置の機能を示したブロック図である。 第２の実施の形態に係る被監視装置の機能を示したブロック図である。 第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第１の図である。 第２の実施の形態に係る他装置履歴データベースの例を示した図である。 第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第２の図である。 第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第３の図である。 第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第４の図である。 第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第５の図である。 第２の実施の形態に係る他装置履歴データベースの更新方法について説明するフロー図である。 第２の実施の形態に係る主系及び従系の装置による復旧時の動作について説明するシーケンス図である。 第２の実施の形態に係る主系の装置の動作について説明するフロー図である。 第２の実施の形態に係る従系の装置の動作について説明するフロー図である。 第２の実施の形態の一変形例（変形例＃１）に係るポーリング間隔テーブルの生成に用いる情報の例を示した図である。 第２の実施の形態の一変形例（変形例＃１）に係るポーリング間隔テーブルの更新方法について説明するフロー図である。 第２の実施の形態の一変形例（変形例＃２）に係る主系及び従系の装置の動作について説明する図である。 第２の実施の形態の一変形例（変形例＃２）に係るアクション負荷値テーブルの生成に用いる情報の例を示した図である。 第２の実施の形態の一変形例（変形例＃２）に係るアクション負荷値テーブルの更新方法について説明するフロー図である。 第２の実施の形態の一変形例（変形例＃２）に係るアクション切り替え境界値の更新方法について説明するフロー図である。 第２の実施の形態の一変形例（変形例＃２）に係る実行依頼の要否判定方法について説明する第１のフロー図である。 第２の実施の形態の一変形例（変形例＃２）に係る実行依頼の要否判定方法について説明する第２のフロー図である。 第２の実施の形態の一変形例（変形例＃２）に係る従系の装置の動作について説明するフロー図である。 第２の実施の形態の一変形例（変形例＃３）に係る未通知履歴データベースの例を示した図である。 第２の実施の形態の一変形例（変形例＃３）に係る未通知履歴データベースの更新方法について説明するフロー図である。 第２の実施の形態の一変形例（変形例＃３）に係る未通知履歴情報に基づいて成功履歴の有無を判断する方法について説明するフロー図である。

以下、図面を参照しながら実施の形態について説明する。
［第１の実施の形態］
第１の実施の形態について説明する。

図１は、第１の実施の形態に係る情報処理システムの例を示した図である。
情報処理システム１０は、同じデータ１１を取得する第１及び第２の情報処理装置１２、１６を含む。第１の情報処理装置１２は、演算部１３、及び通信部１４を有する。第２の情報処理装置１６は、記憶部１７、及び制御部１８を有する。

演算部１３は、データ１１の取得に応じてアクションを実行する。アクションの例としては、メール通知、音声通知、アプリケーションプログラムの実行、リモートコマンドの発行、ＳＮＭＰ（Simple Network Management Protocol）トラップの発行、ポップアップ表示などがある。

通信部１４は、アクションが正常に完了した場合に、アクションによって処理されたデータを示す履歴情報１５を第２の情報処理装置１６に送信する。記憶部１７は、第１の情報処理装置１２から受信された履歴情報１５を記憶する。例えば、記憶部１７には、アクションの種類、アクションが実行済みであるか、実行中であるかを示す情報、或いは、実行済みの場合には成功又は失敗を示す情報などが格納される。

制御部１８は、データ１１を取得したとき、記憶部１７の履歴情報１５の格納状況に基づいて、第２の情報処理装置１６がアクションの実行を抑止するか、第１の情報処理装置１２に代わって第２の情報処理装置１６がアクションを実行するかを決定する。例えば、制御部１８は、データ１１に対応する履歴情報１５が記憶部１７に格納されている場合にアクションの実行を抑止することを決定する。一方、データ１１に対応する履歴情報１５が記憶部１７に格納されていない場合、制御部１８は、第２の情報処理装置１６がアクションを実行することを決定する。

以上、第１の実施の形態について説明した。
［第２の実施の形態］
第２の実施の形態について説明する。

（情報処理システムについて）
まず、第２の実施の形態に係る情報処理システムについて説明する。図２は、第２の実施の形態に係る情報処理システムの例を示した図である。

図２に示すように、第２の実施の形態に係る情報処理システム１００は、互いに接続された第１情報処理装置１１０及び第２情報処理装置１３０を含む。第１情報処理装置１１０及び第２情報処理装置１３０は、ネットワーク９４を介して被監視装置２１０、２２０及び端末装置３００に接続されている。なお、図２の例では、監視対象となる装置の一例として２台の被監視装置２１０、２２０を明示しているが、監視対象となる装置の数は１台であってもよいし、３台以上であってもよい。

（被監視装置２１０、２２０）
被監視装置２１０でイベントが発生した場合、被監視装置２１０は、第１情報処理装置１１０及び第２情報処理装置１３０に対してイベントの種類及びその内容を含むメッセージを送信する。このとき、被監視装置２１０は、イベント発生日時及び発生したイベントを個々に識別するためのイベントＩＤをさらにメッセージに含めて第１情報処理装置１１０及び第２情報処理装置１３０に送信する。イベントＩＤは、例えば、イベントの発生順に個々の被監視装置によりイベント毎に付与される番号である。

イベントの種類は、被監視装置２１０の種類や被監視装置２１０で動作するソフトウェアの種類などに依存する。例えば、被監視装置２１０がアプリケーションサーバの場合、被監視装置２１０で実行中のアプリケーションソフトウェアによる警告やエラーの出力などがイベントとなる。被監視装置２１０がジョブサーバの場合、ジョブの実行失敗やジョブの実行完了などがイベントとなる。その他にも、ネットワークの切断やメモリへのデータ書き込みエラーなどがイベントとなる。

なお、被監視装置２１０は、イベントの発生時だけでなく、イベントログから抽出した情報をメッセージとして定期的に第１情報処理装置１１０及び第２情報処理装置１３０へ送信してもよい。例えば、被監視装置２１０は、オペレーティングシステムの稼働状況を記録するシステムログ、アプリケーションソフトウェアの稼働状況を記録するアプリケーションログ、ログオンの結果などを記録するセキュリティログの情報を送信してもよい。

上記のように、被監視装置２１０は、イベントが発生した場合に、そのイベントに関するメッセージを第１情報処理装置１１０及び第２情報処理装置１３０に送信する。但し、第１情報処理装置１１０又は第２情報処理装置１３０でメッセージが正常に受信されなかった場合、被監視装置２１０は、そのメッセージを未通知メッセージとして保持する。

例えば、何らかのトラブルにより第１情報処理装置１１０が停止している場合、被監視装置２１０がメッセージを送信しても、第１情報処理装置１１０から受信完了を示す確認応答が得られない。この場合、被監視装置２１０は、第１情報処理装置１１０により正常に受信されなかったメッセージを第１情報処理装置１１０に対する未通知メッセージとして保持する。なお、被監視装置２２０についても同様である。

（第１情報処理装置１１０、第２情報処理装置１３０）
被監視装置２１０、２２０から送信されたメッセージを受信した場合、第１情報処理装置１１０又は第２情報処理装置１３０は、受信したメッセージの種類に対応するアクションを実行する。アクションの例としては、メール通知、音声通知、アプリケーションプログラムの実行、リモートコマンドの発行、ＳＮＭＰトラップの発行、ポップアップ表示などがある。これらのアクション種別は、イベントの種別に対応付けられている。例えば、Disk Errorに対してメール通知、Application Warningに対して音声通知、Application Errorに対してメール通知及び音声通知が対応付けられている。

メール通知は、電子メールを用いて端末装置３００を利用するユーザにイベントの発生及びその内容を通知するアクションである。音声通知は、イベントの発生及びその内容を音声で通知するための音声データを端末装置３００に送信してユーザに音声で情報を通知するアクションである。ポップアップ表示は、イベントの発生及びその内容を記載したポップアップウィンドウを端末装置３００の画面上に表示させるアクションである。その他のアクションも、端末装置３００を利用するユーザにイベントの発生及びその内容の通知、或いは、イベントへの対処方法や対処結果などを通知するものである。

１つのメッセージに対するアクションは、第１情報処理装置１１０又は第２情報処理装置１３０のいずれかで実行される。第１情報処理装置１１０及び第２情報処理装置１３０には、それぞれ、メッセージに対するアクションを優先的に実行する「主系」又はアクションを優先的には実行せず待機する「従系」という属性が設定される。第１情報処理装置１１０が「主系」であり、第２情報処理装置１３０が「従系」である場合、第１情報処理装置１１０がメッセージに対するアクションを主に実行する。

但し、何らかのトラブルが生じて第１情報処理装置１１０が停止している場合、第２情報処理装置１３０がメッセージに対するアクションを実行する。さらに、第２情報処理装置１３０は、自身の属性を「従系」から「主系」に切り替える。その後、第１情報処理装置１１０が復旧した場合、第１情報処理装置１１０は、自身の属性を「主系」から「従系」に切り替え、「従系」として動作する。このように、第１情報処理装置１１０及び第２情報処理装置１３０は、互いに状態を監視し、相手の状態に応じて自身の属性を切り替える。

以上、第２の実施の形態に係る情報処理システムの例について説明した。なお、図２の例では、第１情報処理装置１１０と第２情報処理装置１３０とが直接接続されているが、両者がネットワーク９４を介する経路のみで接続されていてもよい。但し、以下では、第１情報処理装置１１０と第２情報処理装置１３０とが直接接続されているものとして説明を進める。

（第１情報処理装置のハードウェアについて）
次に、第２の実施の形態に係る第１情報処理装置のハードウェアの例について説明する。図３は、第２の実施の形態に係る第１情報処理装置のハードウェアの例を示した図である。

図３に示すように、第１情報処理装置１１０は、例えば、ＣＰＵ（Central Processing Unit）９０１、ＲＡＭ（Random Access Memory）９０２、ＨＤＤ（Hard Disk Drive）９０３、画像信号処理部９０４、入力信号処理部９０５、ディスクドライブ９０６、及び通信インターフェース９０７ａ、９０７ｂを有する。

ＣＰＵ９０１は、プログラムに記述された命令を実行する演算器を含むプロセッサである。ＣＰＵ９０１は、ＨＤＤ９０３に記憶されているプログラムやデータの少なくとも一部をＲＡＭ９０２にロードし、プログラムに記述された命令を実行する。なお、ＣＰＵ９０１は、複数のプロセッサコアを含んでいてもよい。また、第１情報処理装置１１０は、複数のＣＰＵ９０１を搭載していてもよい。この場合、第１情報処理装置１１０は、処理を並列実行することができる。

ＲＡＭ９０２は、ＣＰＵ９０１が実行するプログラムや、処理に用いられるデータを一時的に記憶するための揮発性メモリである。なお、第１情報処理装置１１０は、ＲＡＭ９０２とは異なる種類のメモリを有していてもよい。また、第１情報処理装置１１０は、複数のメモリを備えていてもよい。

ＨＤＤ９０３は、Operating System（ＯＳ）、ファームウェア、或いは、アプリケーションソフトウェアなどのプログラムや、処理に用いられるデータなどを記憶する不揮発性記憶装置の一例である。なお、第１情報処理装置１１０は、フラッシュメモリやSolid State Drive（ＳＳＤ）など、ＨＤＤ９０３とは異なる種類の記憶装置を有していてもよい。また、第１情報処理装置１１０は、複数の記憶装置を有していてもよい。

画像信号処理部９０４は、ＣＰＵ９０１による制御を受け、第１情報処理装置１１０に接続された表示装置９１に画像を出力する。表示装置９１は、例えば、Cathode Ray Tube（ＣＲＴ）ディスプレイ、Liquid Crystal Display（ＬＣＤ）、Plasma Display Panel（ＰＤＰ）、Organic Electro-Luminescence Display（ＯＥＬＤ）などの表示デバイスである。

入力信号処理部９０５は、第１情報処理装置１１０に接続された入力デバイス９２から入力信号を取得し、ＣＰＵ９０１に通知する。入力デバイス９２としては、例えば、マウス、キーボード、タッチパネル、タッチパッド、トラックボール、リモートコントローラ、ボタンスイッチなどを用いることができる。

ディスクドライブ９０６は、記録媒体９３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体９３としては、例えば、Flexible Disk（ＦＤ）、ＨＤＤなどの磁気ディスク、Compact Disc（ＣＤ）やDigital Versatile Disc（ＤＶＤ）などの光ディスク、Magneto-Optical disk（ＭＯ）などの光磁気ディスクを用いることができる。ディスクドライブ９０６は、例えば、ＣＰＵ９０１による制御を受け、記録媒体９３から読み取ったプログラムやデータをＲＡＭ９０２又はＨＤＤ９０３に格納する。

通信インターフェース９０７ａは、ネットワーク９４を介して他のコンピュータと通信を行うためのインターフェースである。通信インターフェース９０７ｂは、第２情報処理装置１３０との間で通信を行うためのインターフェースである。通信インターフェース９０７ａ、９０７ｂは、有線インターフェースであってもよいし、無線インターフェースであってもよい。

以上、第２の実施の形態に係る第１情報処理装置のハードウェアの例について説明した。なお、第２情報処理装置１３０の機能、被監視装置２１０、２２０の機能、及び端末装置３００の機能は、第１情報処理装置１１０と同じハードウェアを用いて実現できる。但し、被監視装置２１０、２２０、及び端末装置３００の場合、通信インターフェース９０７ｂが省略される。

（第１情報処理装置の機能について）
次に、第２の実施の形態に係る第１情報処理装置の機能について説明する。図４は、第２の実施の形態に係る第１情報処理装置の機能を示したブロック図である。

図４に示すように、第１情報処理装置１１０は、第１通信部１１１と、イベント監視部１１２と、第２通信部１１３と、アクション実行部１１４と、第１記憶部１１５と、第２記憶部１１６と、第３記憶部１１７と、制御部１１８とを有する。

なお、イベント監視部１１２、アクション実行部１１４、及び制御部１１８は、ＣＰＵ９０１が実行するプログラムのモジュールとして実現できる。但し、イベント監視部１１２、アクション実行部１１４、及び制御部１１８が有する機能の一部又は全部をソフトウェアではなく電子回路として実現することも可能である。

第１記憶部１１５、第２記憶部１１６、及び第３記憶部１１７は、ＲＡＭ９０２やＨＤＤ９０３に確保された記憶領域である。第１通信部１１１の機能は、通信インターフェース９０７ａを用いて実現することができる。第２通信部１１３の機能は、通信インターフェース９０７ｂを用いて実現することができる。

（第１通信部１１１）
第１通信部１１１は、ネットワーク９４を介して被監視装置２１０、２２０及び端末装置３００と通信するための通信手段である。例えば、第１通信部１１１は、被監視装置２１０が送信したメッセージを受信する。そして、第１通信部１１１は、受信したメッセージをイベント監視部１１２に入力する。また、第１通信部１１１は、アクションの実行に関する情報を端末装置３００に送信する際に利用される。例えば、第１通信部１１１は、電子メールのデータや音声データなどを端末装置３００に送信する際に利用される。

（イベント監視部１１２）
イベント監視部１１２は、第１通信部１１１から入力されたメッセージのうち、アクションの実行を要するイベントに対応するメッセージを抽出する。なお、アクションとイベントの種類との対応関係は予め設定されているものとする。また、イベント監視部１１２は、アクションとイベントの種類との対応関係を示す情報（以下、フィルタリング情報）を参照できるものとする。イベント監視部１１２は、メッセージからイベントの種類を示す情報を抽出し、フィルタリング情報と照合してアクションの実行を要するイベントに対応するメッセージを抽出する。イベント監視部１１２により抽出されたメッセージは、制御部１１８に入力される。

（第２通信部１１３）
第２通信部１１３は、第２情報処理装置１３０と直接通信するための通信手段である。例えば、第２通信部１１３は、第１情報処理装置１１０によるアクションの実行状況（実行開始、実行終了）や実行結果（成功、失敗）などの情報を第２情報処理装置１３０に対して送信する際に利用される。また、第２通信部１１３は、第１情報処理装置１１０の属性（「主系」又は「従系」）を示す情報（以下、属性情報）を第２情報処理装置１３０に対して送信する際に利用される。また、第２通信部１１３は、第２情報処理装置１３０からアクションの実行状況や実行結果などの情報、或いは、属性情報を受信する際に利用される。

（アクション実行部１１４）
アクション実行部１１４は、後述する制御部１１８による制御を受けてアクションを実行する。例えば、メール通知を行う場合、アクション実行部１１４は、第１通信部１１１を利用して端末装置３００に電子メールのデータを送信する。音声通知を行う場合、アクション実行部１１４は、第１通信部１１１を利用して端末装置３００に音声データを送信する。その他にも、アクション実行部１１４は、アプリケーションプログラムの実行、リモートコマンドの発行、ＳＮＭＰトラップの発行、及びポップアップ表示などのアクションを実行する。

（第１記憶部１１５）
第１記憶部１１５は、他装置履歴データベース１１５ａを格納している。他装置履歴データベース１１５ａには、第２情報処理装置１３０が実行したアクションの実行履歴に関する情報（以下、第２実行履歴情報）が格納される。例えば、他装置履歴データベース１１５ａには、アクションに対応するイベントのイベント発生日時、イベントＩＤ、イベントが発生した装置の装置名（以下、発生元装置名）、アクションの種類（以下、アクション種別）、及び実行状態を示す情報（以下、状態情報）が対応付けて格納される。状態情報は、例えば、アクションが実行済みであるか、実行中であるかを示す情報、及び、実行済みの場合には成功又は失敗を示す情報を含む。

（第２記憶部１１６）
第２記憶部１１６は、未通知履歴データベース１１６ａを格納している。未通知履歴データベース１１６ａには、アクション実行部１１４が実行したアクションの実行履歴に関する情報（以下、第１実行履歴情報）のうち、第２情報処理装置１３０に通知できなかった情報（以下、第１未通知履歴情報）が格納される。例えば、未通知履歴データベース１１６ａには、アクションに対応するイベントのイベント発生日時、イベントＩＤ、発生元装置名、アクション種別、及び状態情報が対応付けて格納される。

（第３記憶部１１７）
第３記憶部１１７には、第１情報処理装置１１０の属性情報、フィルタリング情報、被監視装置２１０、２２０や端末装置３００を特定するための情報（例えば、ホスト名やＩＰアドレスなど）、及びアプリケーションプログラムなどが格納される。さらに、第３記憶部１１７には、第２実行履歴情報のうち、第１情報処理装置１１０に通知できずに第２情報処理装置１３０が保持していた情報（以下、第２未通知履歴情報）が格納される。

（制御部１１８）
制御部１１８は、履歴更新部１１８ａ、及び属性管理部１１８ｂを含む。履歴更新部１１８ａは、第２通信部１１３を介して第２情報処理装置１３０から第２実行履歴情報を受信した場合、受信した第２実行履歴情報を第１記憶部１１５の他装置履歴データベース１１５ａに格納する。

属性管理部１１８ｂは、イベント監視部１１２からメッセージが入力された場合、第１情報処理装置１１０の属性を確認する。また、属性管理部１１８ｂは、第１情報処理装置１１０及び第２情報処理装置１３０の状態に応じて属性情報を更新する。さらに、属性管理部１１８ｂは、第２情報処理装置１３０に通知できなかった第１実行履歴情報が生じた場合、第１未通知履歴情報を第２記憶部１１６の未通知履歴データベース１１６ａに格納する。

なお、第１情報処理装置１１０の属性が「主系」の場合、制御部１１８は、下記（１）のように機能する。一方、第１情報処理装置１１０の属性が「従系」の場合、制御部１１８は、下記（２）のように機能する。

（１）第１情報処理装置１１０が「主系」の場合
第１情報処理装置１１０が「主系」の場合における制御部１１８の機能について説明する。なお、以下では、第１情報処理装置１１０が正常動作している場合（復旧時ではない場合）と、何らかの事情により動作停止など（以下、単に障害と言う。）が発生した状態から復旧した場合（復旧時）とに分けて説明する。

（１−１）第１情報処理装置１１０が正常動作している場合
属性管理部１１８ｂは、イベント監視部１１２から入力されたメッセージと同じメッセージに対応する情報（イベントＩＤ及び発生元装置名）が他装置履歴データベース１１５ａに格納されているか否かを確認する。つまり、属性管理部１１８ｂは、同じメッセージに対応するアクションが既に第２情報処理装置１３０で実行されたか否かを確認する。

第１情報処理装置１１０が「主系」として正常動作している場合、通常、他装置履歴データベース１１５ａには同じメッセージに対応する情報が格納されていないため、属性管理部１１８ｂは、アクションを実行させる動作に移る。但し、後述する変形例のように、「主系」が実行すべき一部のアクションを「従系」が実行する場合、他装置履歴データベース１１５ａには同じメッセージに対応する情報が格納されることがある。こうした変形例については後述する。

属性管理部１１８ｂは、フィルタリング情報を参照し、イベント監視部１１２から入力されたメッセージが示すイベント種別に対応するアクションをアクション実行部１１４に実行させる。アクション実行部１１４にアクションの実行を開始させる際、属性管理部１１８ｂは、第２通信部１１３を利用してアクションの実行開始を示す情報（以下、開始通知）を第２情報処理装置１３０に送信する。さらに、アクション実行部１１４によるアクションの実行が終了した際、属性管理部１１８ｂは、第２通信部１１３を利用してアクションの実行終了及びその成否を示す情報（以下、終了通知）を第２情報処理装置１３０に送信する。

但し、第２情報処理装置１３０が開始通知を受信できなかった場合、属性管理部１１８ｂは、未通知履歴データベース１１６ａにイベント発生日時、発生元装置名、アクション種別、及び状態情報（第１未通知履歴情報）を格納する。例えば、開始通知の送信に対するＡＣＫ（ACKnowledgement）が第２情報処理装置１３０から得られない場合、属性管理部１１８ｂは、未通知履歴データベース１１６ａに第１未通知履歴情報を格納する。この場合、属性管理部１１８ｂは、アクション実行部１１４によるアクションの実行が終了しても終了通知を第２情報処理装置１３０に送信しない。

なお、属性管理部１１８ｂは、アクションの実行開始から実行終了までの間、未通知履歴データベース１１６ａに格納する状態情報を「実行中」とする。アクションの実行が終了した際、属性管理部１１８ｂは、未通知履歴データベース１１６ａに格納した状態情報を「実行済」に更新する。さらに、属性管理部１１８ｂは、アクションの実行結果（成功、失敗）を状態情報に付加する。なお、アクションの実行が失敗した場合、属性管理部１１８ｂは、同じアクションをアクション実行部１１４に再び実行させる。

１つのアクションの実行が終了した後、属性管理部１１８ｂは、フィルタリング情報を参照し、同じイベント種別に対応する他のアクションが存在するか否かを確認する。同じイベント種別に他のアクションが対応付けられている場合、属性管理部１１８ｂは、他のアクションをアクション実行部１１４に実行させる。この場合、属性管理部１１８ｂは、他のアクションの実行開始を通知する開始通知を第２情報処理装置１３０に送信しない。そして、属性管理部１１８ｂは、未通知履歴データベース１１６ａに第１未通知履歴情報を格納する。さらに、他のアクションの実行が終了した場合も、属性管理部１１８ｂは、終了通知を第２情報処理装置１３０に送信しない。そして、属性管理部１１８ｂは、未通知履歴データベース１１６ａの状態情報を更新する。

（１−２）第１情報処理装置１１０の復旧時
第１情報処理装置１１０が「主系」の場合に、第１情報処理装置１１０で障害が発生すると、第２情報処理装置１３０が「主系」となってアクションを実行する場合がある。この場合、制御部１１８は、第１情報処理装置１１０の復旧時に次のような処理を実行する。なお、制御部１１８は、例えば、電源の投入、オペレーティングシステムやアプリケーションソフトウェアの起動、ネットワーク機能の回復、或いは、ユーザ（端末装置３００）による明示的な通知を検知することで復旧時であると判断できる。

復旧時であると判断した場合、属性管理部１１８ｂは、第２通信部１１３を利用して、第２情報処理装置１３０が保持する属性情報及び第２未通知履歴情報を第２情報処理装置１３０に要求する。そして、属性管理部１１８ｂは、第２通信部１１３を利用して、第２情報処理装置１３０から送信された属性情報及び第２未通知履歴情報を受信する。属性管理部１１８ｂは、受信した第２未通知履歴情報を第３記憶部１１７に格納する。また、属性管理部１１８ｂは、受信した属性情報を参照して第２情報処理装置１３０の属性を確認する。

障害の発生時から復旧時までの間に第１情報処理装置１１０及び第２情報処理装置１３０へメッセージが送信され、第２情報処理装置１３０の属性が「主系」へと変更されている場合、属性管理部１１８ｂは、第３記憶部１１７に格納された属性情報を更新する。つまり、属性管理部１１８ｂは、第１情報処理装置１１０の属性を「主系」から「従系」へと変更する。なお、障害の発生時から復旧時までの間に第１情報処理装置１１０及び第２情報処理装置１３０へメッセージが送信されず、第２情報処理装置１３０の属性が変更されていない場合、属性管理部１１８ｂは、属性を変更せずに動作を再開する。

障害の発生時から復旧時までの間に被監視装置２１０から第１情報処理装置１１０へメッセージが送信された場合、第１情報処理装置１１０により正常に受信されなかったメッセージは、未通知メッセージとして被監視装置２１０により保持される。被監視装置２１０は、定期的に第１情報処理装置１１０の状態を確認し、第１情報処理装置１１０の復旧時に、保持していた未通知メッセージを再送する。属性管理部１１８ｂは、被監視装置２１０から送信された未通知メッセージを第１通信部１１１及びイベント監視部１１２を介して受信し、未通知メッセージの処理を実行する。

属性管理部１１８ｂは、未通知メッセージが示すイベントと同じイベントの情報（イベントＩＤ及び発生元装置名）が第３記憶部１１７に格納した第２未通知履歴情報に含まれているか否かを確認する。つまり、属性管理部１１８ｂは、同じイベントに対するアクションが既に第２情報処理装置１３０で実行されたか否かを確認する。

受信した未通知メッセージが示すイベントと同じイベントの情報が第２未通知履歴情報に含まれている場合、属性管理部１１８ｂは、その未通知メッセージが示すイベントに対応するアクションの実行を抑止する（そのアクションを実行しないことにする。）。一方、受信した未通知メッセージが示すイベントと同じイベントの情報が第２未通知履歴情報に含まれていない場合、属性管理部１１８ｂは、その未通知メッセージが示すイベントに対応するアクションをアクション実行部１１４に実行させる。

未通知メッセージが複数存在する場合、属性管理部１１８ｂは、被監視装置２１０から順次未通知メッセージを受信し、受信した未通知メッセージが示すイベントと同じイベントの情報が第２未通知履歴情報に含まれているか否かを確認する。そして、属性管理部１１８ｂは、上記と同様に、確認結果に応じて未通知メッセージを処理（アクションの実行又は抑止）する。全ての未通知メッセージに対して処理が完了すると、制御部１１８は、下記（２）に示す第１情報処理装置１１０が「従系」の場合の動作に移る。

（２）第１情報処理装置１１０が「従系」の場合
第１情報処理装置１１０が「従系」の場合における制御部１１８の機能について説明する。なお、以下では、第１情報処理装置１１０が正常動作している場合（復旧時ではない場合）と、何らかの事情により障害が発生した状態から復旧した場合（復旧時）とに分けて説明する。

（２−１）第１情報処理装置１１０が正常動作している場合
イベント監視部１１２からメッセージが入力された場合、属性管理部１１８ｂは、メッセージの入力から所定の時間だけ待機する。第２通信部１１３を介して開始通知を受信した場合、履歴更新部１１８ａは、他装置履歴データベース１１５ａに第１未通知履歴情報を格納する。このとき、履歴更新部１１８ａは、状態情報を「実行中」にする。また、第２通信部１１３を介して終了通知を受信した場合、履歴更新部１１８ａは、状態情報を「実行済」に更新し、その状態情報に実行結果（成功又は失敗）を付与する。

属性管理部１１８ｂは、他装置履歴データベース１１５ａを参照し、メッセージの入力から所定の時間が経過するまでに、アクションの実行が成功していることが確認できた場合、そのメッセージに対応するアクションの実行を抑止する。なお、所定の時間は、予め設定されていてもよいし、後述する変形例のように所定のタイミングで更新されるようにしてもよい。また、所定の時間は、アクション種別毎に設定されていてもよい。

一方、メッセージの入力から所定の時間が経過するまでに、アクションの実行が成功したことを確認できない場合、属性管理部１１８ｂは、そのアクションをアクション実行部１１４に実行させる。この場合、属性管理部１１８ｂは、第２通信部１１３を利用して、アクションの実行開始時及び実行終了時にそれぞれ開始通知及び終了通知を第２情報処理装置１３０へと送信する。さらに、属性管理部１１８ｂは、第３記憶部１１７に格納された属性情報を変更する。つまり、属性管理部１１８ｂは、第１情報処理装置１１０の属性を「従系」から「主系」に変更する。

但し、第２情報処理装置１３０が開始通知を受信できなかった場合、属性管理部１１８ｂは、未通知履歴データベース１１６ａにイベント発生日時、発生元装置名、アクション種別、及び状態情報（第２未通知履歴情報）を格納する。この場合、属性管理部１１８ｂは、アクション実行部１１４によるアクションの実行が終了しても終了通知を第２情報処理装置１３０に送信しない。

なお、属性管理部１１８ｂは、アクションの実行開始から実行終了までの間、未通知履歴データベース１１６ａに格納する状態情報を「実行中」とする。アクションの実行が終了した際、属性管理部１１８ｂは、未通知履歴データベース１１６ａに格納した状態情報を「実行済」に更新する。さらに、属性管理部１１８ｂは、アクションの実行結果（成功、失敗）を状態情報に付加する。なお、アクションの実行が失敗した場合、属性管理部１１８ｂは、同じアクションをアクション実行部１１４に再び実行させる。

１つのアクションの実行が終了した後、属性管理部１１８ｂは、フィルタリング情報を参照し、同じイベント種別に対応する他のアクションが存在するか否かを確認する。同じイベント種別に他のアクションが対応付けられている場合、属性管理部１１８ｂは、他のアクションをアクション実行部１１４に実行させる。この場合、属性管理部１１８ｂは、他のアクションの実行開始を通知する開始通知を第２情報処理装置１３０に送信しない。そして、属性管理部１１８ｂは、未通知履歴データベース１１６ａに第１未通知履歴情報を格納する。他のアクションの実行が終了した場合、属性管理部１１８ｂは、終了通知を第２情報処理装置１３０に送信しない。そして、属性管理部１１８ｂは、未通知履歴データベース１１６ａの状態情報を更新する。

（２−２）第１情報処理装置１１０の復旧時
第１情報処理装置１１０が「従系」の場合、第１情報処理装置１１０で障害が発生しても、第２情報処理装置１３０が「主系」としてアクションの実行を継続する。従って、第２情報処理装置１３０の属性は変更されない。

第１情報処理装置１１０が復旧した場合、属性管理部１１８ｂは、第２通信部１１３を利用して、第２情報処理装置１３０が保持する第２未通知履歴情報を第２情報処理装置１３０に要求する。そして、属性管理部１１８ｂは、第２通信部１１３を利用して、第２情報処理装置１３０から送信された第２未通知履歴情報を受信する。属性管理部１１８ｂは、第２情報処理装置１３０から受信した第２未通知履歴情報を第３記憶部１１７に格納する。

障害の発生時から復旧時までの間に被監視装置２１０から第１情報処理装置１１０へメッセージが送信された場合、第１情報処理装置１１０により正常に受信されなかったメッセージは、未通知メッセージとして被監視装置２１０により保持される。第１情報処理装置１１０の復旧時に、属性管理部１１８ｂは、被監視装置２１０から送信された未通知メッセージを第１通信部１１１及びイベント監視部１１２を介して受信し、未通知メッセージの処理を実行する。

属性管理部１１８ｂは、未通知メッセージが示すイベントと同じイベントの情報（イベントＩＤ及び発生元装置名）が第３記憶部１１７に格納した第２未通知履歴情報に含まれているか否かを確認する。つまり、属性管理部１１８ｂは、同じイベントに対するアクションが既に第２情報処理装置１３０で実行されたか否かを確認する。

通常、受信した未通知メッセージが示すイベントと同じイベントの情報が第２未通知履歴情報に含まれているため、属性管理部１１８ｂは、その未通知メッセージに対応するアクションの実行を抑止する。しかし、受信した未通知メッセージが示すイベントと同じイベントの情報が第２未通知履歴情報に含まれていない場合、属性管理部１１８ｂは、そのイベントに対するアクションをアクション実行部１１４に実行させる。

複数の未通知メッセージが存在する場合、属性管理部１１８ｂは、被監視装置２１０から順次未通知メッセージを受信し、受信した未通知メッセージが示すイベントと同じイベントの情報が第２未通知履歴情報に含まれているか否かを確認する。そして、属性管理部１１８ｂは、上記と同様に、確認結果に応じて未通知メッセージを処理（アクションの実行又は抑止）する。全ての未通知メッセージに対する処理が完了すると、制御部１１８は、上記（２−１）に示す第１情報処理装置１１０が正常動作している場合の動作に移る。

以上、第２の実施の形態に係る第１情報処理装置の機能について説明した。
（第２情報処理装置の機能について）
次に、第２の実施の形態に係る第２情報処理装置の機能について説明する。図５は、第２の実施の形態に係る第２情報処理装置の機能を示したブロック図である。

図５に示すように、第２情報処理装置１３０は、第１通信部１３１と、イベント監視部１３２と、第２通信部１３３と、アクション実行部１３４と、第１記憶部１３５と、第２記憶部１３６と、第３記憶部１３７と、制御部１３８とを有する。

なお、イベント監視部１３２、アクション実行部１３４、及び制御部１３８は、ＣＰＵ９０１が実行するプログラムのモジュールとして実現できる。但し、イベント監視部１３２、アクション実行部１３４、及び制御部１３８が有する機能の一部又は全部をソフトウェアではなく電子回路として実現することも可能である。

第１記憶部１３５、第２記憶部１３６、及び第３記憶部１３７は、ＲＡＭ９０２やＨＤＤ９０３に確保された記憶領域である。第１通信部１３１の機能は、通信インターフェース９０７ａを用いて実現することができる。第２通信部１３３の機能は、通信インターフェース９０７ｂを用いて実現することができる。

図５に示した第２情報処理装置１３０の機能は、図４に示した第１情報処理装置１１０の機能と同じである。上述した第１通信部１１１、イベント監視部１１２、第２通信部１１３、及びアクション実行部１１４の機能が、それぞれ第１通信部１３１、イベント監視部１３２、第２通信部１３３、及びアクション実行部１３４の機能に対応する。

さらに、上述した第１記憶部１１５、第２記憶部１１６、第３記憶部１１７、及び制御部１１８の機能が、それぞれ第１記憶部１３５、第２記憶部１３６、第３記憶部１３７、及び制御部１３８の機能に対応する。従って、第２情報処理装置１３０の機能については詳細な説明を省略する。

以上、第２の実施の形態に係る第２情報処理装置の機能について説明した。
（被監視装置の機能について）
次に、第２の実施の形態に係る被監視装置の機能について説明する。図６は、第２の実施の形態に係る被監視装置の機能を示したブロック図である。なお、ここでは一例として被監視装置２１０の機能について説明するが、被監視装置２２０など、情報処理システム１００が監視する他の被監視装置についても同様である。

図６に示すように、被監視装置２１０は、記憶部２１１と、演算処理部２１２と、イベント監視部２１３と、通信部２１４とを有する。
なお、記憶部２１１は、ＲＡＭ９０２やＨＤＤ９０３に確保された記憶領域である。演算処理部２１２及びイベント監視部２１３は、ＣＰＵ９０１が実行するプログラムのモジュールとして実現できる。但し、演算処理部２１２及びイベント監視部２１３が有する機能の一部又は全部をソフトウェアではなく電子回路として実現することも可能である。通信部２１４の機能は、通信インターフェース９０７ａを用いて実現することができる。

記憶部２１１には、各種のイベントログが格納される。さらに、記憶部２１１には、第１情報処理装置１１０又は第２情報処理装置１３０により正常に受信されなかったメッセージ（未通知メッセージ）が格納される。なお、記憶部２１１は、任意のデータ書き込みに失敗した場合、書き込みエラーをイベント監視部２１３に通知する。

演算処理部２１２は、オペレーティングシステムやアプリケーションソフトウェアなどの動作に関する処理を実行する。さらに、演算処理部２１２は、オペレーティングシステムの稼働状況を記録するシステムログ、アプリケーションソフトウェアの稼働状況を記録するアプリケーションログ、ログオンの結果などを記録するセキュリティログの情報を記憶部２１１に格納する。また、演算処理部２１２は、処理の実行中に発生したエラーをイベント監視部２１３に通知する。

通信部２１４は、ネットワーク９４に接続された機器と通信する通信手段である。例えば、通信部２１４は、ネットワーク９４を介して第１情報処理装置１１０及び第２情報処理装置１３０にメッセージを送信する。また、通信部２１４は、ネットワークの切断や大量のパケットロスなどが発生した場合にエラーなどをイベント監視部２１３に通知する。

イベント監視部２１３は、記憶部２１１、演算処理部２１２、及び通信部２１４で検出されるエラーなどのイベントを監視し、イベントの発生に応じて第１情報処理装置１１０及び第２情報処理装置１３０にメッセージを送信する。このとき、イベント監視部２１３は、イベント発生日時及びイベントＩＤをメッセージに含めて送信する。なお、イベント監視部２１３は、記憶部２１１に格納されたイベントログを定期的に読み出して第１情報処理装置１１０及び第２情報処理装置１３０に送信してもよい。

また、第１情報処理装置１１０又は第２情報処理装置１３０が正常にメッセージを受信できなかった場合（例えば、ＡＣＫが返ってこない場合）、イベント監視部２１３は、そのメッセージを未通知メッセージとして記憶部２１１に格納する。このとき、イベント監視部２１３は、メッセージを受信できなかった第１情報処理装置１１０又は第２情報処理装置１３０を識別する情報と共に未通知メッセージを記憶部２１１に格納する。

また、第１情報処理装置１１０又は第２情報処理装置１３０の復旧状況を定期的に監視し、イベント監視部２１３は、復旧した第１情報処理装置１１０又は第２情報処理装置１３０に対して記憶部２１１に格納された未通知メッセージを送信する。

以上、第２の実施の形態に係る被監視装置の機能について説明した。
（装置の動作及びデータベースの内容について）
次に、第１情報処理装置１１０及び第２情報処理装置１３０の動作、及び第１情報処理装置１１０及び第２情報処理装置１３０が保持するデータベースの内容について、さらに説明する。なお、以下の説明において、障害が発生している状態を「異常」、障害から復旧して間もない状態を「復旧」、継続して障害が発生していないか、復旧後の処理を終えた状態を「正常」と表現する場合がある。

（「主系」及び「従系」が共に「正常」の場合）
図７は、第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第１の図である。図７の例は、第１情報処理装置１１０の属性が「主系」、第２情報処理装置１３０の属性が「従系」であり、「主系」及び「従系」が共に「正常」の場合の動作を示している。

図７に示すように、被監視装置２１０から第１情報処理装置１１０及び第２情報処理装置１３０にメッセージが送信されると、「主系」である第１情報処理装置１１０は、受信したメッセージが示すイベントに対してアクションを実行する。一方、「従系」である第２情報処理装置１３０は、メッセージの受信から所定の時間だけ待機する。

第１情報処理装置１１０は、アクションの実行を開始し、開始通知を第２情報処理装置１３０に送信する。この開始通知を受信した第２情報処理装置１３０は、他装置履歴データベース１３５ａに第１未通知履歴情報を格納する。そして、第２情報処理装置１３０は、状態情報を「実行中」に設定し、さらに待機する。

アクションの実行を終了した場合、第１情報処理装置１１０は、アクションの実行結果（成功、失敗）を含む終了通知を第２情報処理装置１３０に送信する。この終了通知を受信した第２情報処理装置１３０は、他装置履歴データベース１３５ａの状態情報を「完了済」とし、その状態情報にアクションの実行結果（成功、失敗）を付加する。アクションの実行が失敗した場合、第１情報処理装置１１０は、アクションを再実行する。成功を示す終了通知を受信した第２情報処理装置１３０は、そのアクションの実行を抑止する。

被監視装置２１０から送信されるメッセージに応じて上記のような動作を繰り返すことにより、第２情報処理装置１３０の他装置履歴データベース１３５ａには、図８に示すような情報が格納される。

図８は、第２の実施の形態に係る他装置履歴データベースの例を示した図である。なお、他装置履歴データベース１１５ａ、未通知履歴データベース１１６ａ、１３６ａにも図８の例と同様の情報が格納される。図８に示すように、他装置履歴データベース１３５ａには、イベント発生日時、イベントＩＤ、発生元装置名（図８の例では被監視装置２１０の装置名「ｈｏｓｔ１」）、アクション種別、及び状態情報が対応付けて格納される。また、「実行済」を示す状態情報には実行結果（成功、失敗）が付加される。

（「主系」が「異常」、「従系」が「正常」の場合）
図９は、第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第２の図である。図９の例は、第１情報処理装置１１０の属性が「主系」、第２情報処理装置１３０の属性が「従系」であり、「主系」が「異常」であり、「従系」が「正常」である場合の動作を示している。

図９に示した状況では、被監視装置２１０から第１情報処理装置１１０及び第２情報処理装置１３０にメッセージが送信されても、「主系」である第１情報処理装置１１０は、メッセージの受信及びメッセージに対応するアクションの実行ができない。一方、「従系」である第２情報処理装置１３０は、メッセージの受信から所定の時間だけ待機する。

しかし、メッセージの受信から所定の時間が経過しても、第２情報処理装置１３０は、第１情報処理装置１１０からアクションの成功を示す終了通知を受信できない（図９の例では開始通知も受信できない。）。この場合、所定の時間が経過した後、第２情報処理装置１３０は、メッセージが示すイベントに対するアクションを実行し、属性を「従系」から「主系」へと変更する。

まず、第２情報処理装置１３０は、他装置履歴データベース１３５ａを参照し、過去に同じイベントに対するアクションを第１情報処理装置１１０が実行して成功していないか確認する。同じイベントに対する第１実行履歴情報が他装置履歴データベース１３５ａにない場合、第２情報処理装置１３０は、アクションの実行を開始し、開始通知を第１情報処理装置１１０に送信する。

なお、図９の例では第１情報処理装置１１０が開始通知を正常に受信できないため、第２情報処理装置１３０は、未通知履歴データベース１３６ａに第２未通知履歴情報を格納する。このとき、第２情報処理装置１３０は、状態情報を「実行中」に設定する。

アクションの実行を終了した場合、第２情報処理装置１３０は、未通知履歴データベース１３６ａの状態情報を「実行済」に更新し、その状態情報にアクションの実行結果（成功、失敗）を付加する。この場合、第２情報処理装置１３０は、終了通知を第１情報処理装置１１０に送信しない。アクションの実行が失敗した場合、第２情報処理装置１３０は、アクションを再実行する。この場合も、第２情報処理装置１３０は、第２未通知履歴情報を未通知履歴データベース１３６ａに格納する。

（「旧主系」が「復旧」、「主系」が「正常」の場合）
図１０は、第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第３の図である。図１０の例は、図９に例示した状況で、第１情報処理装置１１０が復旧した場合の動作を示したものである。図９に例示した状況では、第２情報処理装置１３０が属性を「従系」から「主系」に変更したため、第１情報処理装置１１０及び第２情報処理装置１３０が共に「主系」の属性となっている。そこで、両者を区別するために復旧時における第１情報処理装置１１０の属性を「旧主系」と表現する。

第１情報処理装置１１０が復旧した場合、第１情報処理装置１１０は、第２情報処理装置１３０に対して第２未通知履歴情報及び属性情報の送信を要求する。第２情報処理装置１３０は、要求に応じて未通知履歴データベース１３６ａに格納された第２未通知履歴情報、及び第３記憶部１３７に格納された属性情報を第１情報処理装置１１０に送信する。

第１情報処理装置１１０は、第２情報処理装置１３０から受信した第２未通知履歴情報を第３記憶部１１７に格納する。さらに、第１情報処理装置１１０は、第２情報処理装置１３０から受信した属性情報を参照して第２情報処理装置１３０の属性が「主系」であることを確認し、第３記憶部１１７に格納された自身の属性情報を「主系」から「従系」に変更する。

さらに、第１情報処理装置１１０は、被監視装置２１０に対して未通知メッセージの送信を要求する。この要求を受けた被監視装置２１０は、第１情報処理装置１１０に対して未通知メッセージを送信する。第１情報処理装置１１０は、第３記憶部１１７に格納した第２未通知履歴情報を参照して、未通知メッセージに対応するイベントと同じイベントに対するアクションを第２情報処理装置１３０が既に実行して成功しているかを確認する。

第１情報処理装置１１０は、未通知メッセージが示すイベントと同じイベントに対するアクションを第２情報処理装置１３０が既に実行して成功している場合、そのアクションの実行を抑止する。一方、未通知メッセージが示すイベントと同じイベントに対するアクションを第２情報処理装置１３０が実行していないか、成功していない場合、第１情報処理装置１１０は、そのアクションを実行する。

複数の未通知メッセージが存在する場合、第１情報処理装置１１０は、全ての未通知メッセージについて上記の処理（アクションの抑止又は実行）を行う。全ての未通知メッセージに対する処理を完了すると、第１情報処理装置１１０は、「従系」として動作する。一方、第２情報処理装置１３０は、そのまま「主系」として動作を継続する。つまり、第１情報処理装置１１０及び第２情報処理装置１３０は、それぞれ「主系」及び「従系」を入れ替えた形で図７に例示したような動作を行う。

（「主系」が正常、「従系」が「異常」の場合）
図１１は、第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第４の図である。図１１の例は、第１情報処理装置１１０の属性が「主系」、第２情報処理装置１３０の属性が「従系」であり、「主系」が「正常」であり、「従系」が「異常」である場合の動作を示している。

図１１に示した状況の場合、被監視装置２１０から第１情報処理装置１１０及び第２情報処理装置１３０にメッセージが送信されると、「主系」である第１情報処理装置１１０は、正常にメッセージの受信及びメッセージに対応するアクションを実行できる。そのため、第１情報処理装置１１０は、受信したメッセージに対応するアクションを実行する。但し、第１情報処理装置１１０がアクションを実行開始する際に第２情報処理装置１３０へと送信する開始通知は、第２情報処理装置１３０により正常に受信されない。

そのため、第１情報処理装置１１０は、アクションの実行開始時に、未通知履歴データベース１１６ａに第１未通知履歴情報を格納する。そして、第１情報処理装置１１０は、状態情報を「実行中」に設定する。アクションの実行を終了した場合、第１情報処理装置１１０は、未通知履歴データベース１１６ａの状態情報を「実行済」に更新し、その状態情報にアクションの実行結果（成功、失敗）を付加する。このとき、第１情報処理装置１１０は、第２情報処理装置１３０に対して終了通知を送信しない。なお、アクションの実行が失敗した場合、第１情報処理装置１１０は、アクションを再実行する。この場合も、第１情報処理装置１１０は、第１未通知履歴情報を未通知履歴データベース１１６ａに格納する。

（「主系」が正常、「従系」が「復旧」の場合）
図１２は、第２の実施の形態に係る第１及び第２情報処理装置の動作について説明する第５の図である。図１２の例は、図１１に例示した状況で、第２情報処理装置１３０が復旧した場合の動作を示したものである。

第２情報処理装置１３０が復旧した場合、第２情報処理装置１３０は、第１情報処理装置１１０に対して第１未通知履歴情報の送信を要求する。第１情報処理装置１１０は、要求に応じて未通知履歴データベース１１６ａに格納された第１未通知履歴情報を第２情報処理装置１３０に送信する。第２情報処理装置１３０は、第１情報処理装置１１０から受信した第１未通知履歴情報を第３記憶部１３７に格納する。

さらに、第２情報処理装置１３０は、被監視装置２１０に対して未通知メッセージの送信を要求する。この要求を受けた被監視装置２１０は、第２情報処理装置１３０に対して未通知メッセージを送信する。第２情報処理装置１３０は、第３記憶部１３７に格納した第１未通知履歴情報を参照して、未通知メッセージが示すイベントと同じイベントに対するアクションを第１情報処理装置１１０が既に実行して成功しているかを確認する。第２情報処理装置１３０は、第１情報処理装置１１０が既に実行して成功しているアクションの実行を抑止する。なお、第１情報処理装置１１０が成功していないアクションがある場合には、第２情報処理装置１３０が実行する。

複数の未通知メッセージが存在する場合、第２情報処理装置１３０は、全ての未通知メッセージについて上記と同様に順次処理を実行する。全ての未通知メッセージに対する処理を完了すると、第２情報処理装置１３０は、「従系」として動作を再開する。一方、第１情報処理装置１１０は、そのまま「主系」として動作を継続する。つまり、第１情報処理装置１１０及び第２情報処理装置１３０は、図７に例示した動作を再開する。

以上、第１情報処理装置１１０及び第２情報処理装置１３０の動作、及び第１情報処理装置１１０及び第２情報処理装置１３０が保持するデータベースの内容について、さらに説明した。

（他装置履歴データベースの更新方法について）
次に、第２の実施の形態に係る他装置履歴データベースの更新方法について、フロー図を参照しながら説明する。図１３は、第２の実施の形態に係る他装置履歴データベースの更新方法について説明するフロー図である。

なお、一例として、第１情報処理装置１１０が「主系」、第２情報処理装置１３０が「従系」とし、第２情報処理装置１３０の制御部１３８（主に履歴更新部１３８ａ）が他装置履歴データベース１３５ａを更新する状況を想定して説明する。但し、第１情報処理装置１１０の制御部１１８（主に履歴更新部１１８ａ）が他装置履歴データベース１１５ａを更新する場合も同じ処理フローになる。

（Ｓ１０１）履歴更新部１３８ａは、第１情報処理装置１１０がアクションの実行を開始する際に送信する開始通知を受信した場合に、Ｓ１０２の動作に移る。一方、第１情報処理装置１１０がアクションの実行を開始する際に送信する開始通知を受信していない場合、履歴更新部１３８ａは待機する。

（Ｓ１０２）履歴更新部１３８ａは、イベント発生日時、イベントＩＤ、発生元装置名、アクション種別、及び状態情報（第１実行履歴情報）を他装置履歴データベース１３５ａに格納する。このとき、履歴更新部１３８ａは、状態情報を「実行中」に設定する。なお、イベント発生日時及びイベントＩＤはメッセージに含まれる。発生元装置名（ホスト名）は、例えば、メッセージの送信元を示すＩＰアドレスから得られる。アクション種別は、第３記憶部１３７に格納されたフィルタリング情報から得られる。

（Ｓ１０３）履歴更新部１３８ａは、第１情報処理装置１１０がアクションの実行を終了した際に送信する終了通知を受信した場合、Ｓ１０４の動作に移る。この終了通知には、アクションの実行結果（成功又は失敗）が含まれる。一方、第１情報処理装置１１０がアクションの実行を終了した際に送信する終了通知を受信していない場合、履歴更新部１３８ａは待機する。

（Ｓ１０４）履歴更新部１３８ａは、他装置履歴データベース１３５ａに格納された状態情報を「実行済」に更新する。さらに、履歴更新部１３８ａは、アクションの実行結果を状態情報に付与する。Ｓ１０４の動作を終了すると、履歴更新部１３８ａは、１つのアクションに対する１回の実行について他装置履歴データベース１３５ａの更新に係る動作を終了する。

以上、第２の実施の形態に係る他装置履歴データベースの更新方法について説明した。
（復旧時の動作について）
次に、第２の実施の形態に係る主系及び従系の装置による復旧時の動作について、シーケンス図を参照しながら説明する。図１４は、第２の実施の形態に係る主系及び従系の装置による復旧時の動作について説明するシーケンス図である。なお、一例として、「主系」として動作していた第１情報処理装置１１０が障害により停止した状態から復旧する状況を想定して説明する。さらに、「従系」として動作していた第２情報処理装置１３０が、第１情報処理装置１１０の停止中に「主系」へと変更された場合を想定する。

（Ｓ１１１）第１情報処理装置１１０が復旧した場合、属性管理部１１８ｂは、第２情報処理装置１３０に対して第２未通知履歴情報及び属性情報を要求する。なお、属性管理部１１８ｂは、例えば、電源の投入、オペレーティングシステムやアプリケーションソフトウェアの起動、ネットワーク機能の回復、或いは、ユーザ（端末装置３００）による明示的な通知を検知することで復旧を判断する。

（Ｓ１１２）属性管理部１３８ｂは、第１情報処理装置１１０から受けた要求に応じて未通知履歴データベース１３６ａに格納された第２未通知履歴情報、及び第３記憶部１３７に格納された属性情報を第１情報処理装置１１０に送信する。

（Ｓ１１３）属性管理部１１８ｂは、第２情報処理装置１３０から受信した第２未通知履歴情報及び属性情報を第３記憶部１１７に格納する。
（Ｓ１１４）属性管理部１１８ｂは、第３記憶部１１７に格納した第２情報処理装置１３０の属性情報を参照し、第２情報処理装置１３０の属性を確認する。第２情報処理装置１３０の属性が「主系」である場合、属性管理部１１８ｂは、第１情報処理装置１１０の属性を「従系」に変更する。

（Ｓ１１５）属性管理部１１８ｂは、監視対象となる被監視装置２１０、２２０などの被監視装置から未通知メッセージを受信する。属性管理部１１８ｂは、第３記憶部１１７に格納した第２未通知履歴情報を参照し、未通知メッセージが示すイベントと同じイベントに対して第２情報処理装置１３０が既にアクションを実行して成功しているかを確認する。

属性管理部１１８ｂは、第２情報処理装置１３０が既に実行して成功したアクションの実行を抑止する。第２情報処理装置１３０が実行していないか、成功していないアクションがある場合、属性管理部１１８ｂは、そのアクションを実行する。全ての未通知メッセージについて処理を完了した場合、第１情報処理装置１１０は、「従系」として動作する。一方、第２情報処理装置１３０は、そのまま「主系」として動作する。

以上、第２の実施の形態に係る主系及び従系の装置による復旧時の動作について説明した。なお、元々「従系」として動作していた装置が復旧した場合には、属性及び属性情報に関する動作を省略することができる。

（主系の装置の動作について）
次に、第２の実施の形態に係る主系の装置の動作について、フロー図を参照しながら説明する。図１５は、第２の実施の形態に係る主系の装置の動作について説明するフロー図である。なお、一例として、第１情報処理装置１１０が「主系」、第２情報処理装置１３０が「従系」とし、第１情報処理装置１１０の動作を想定して説明する。但し、第１情報処理装置１１０が「従系」、第２情報処理装置１３０が「主系」の場合も同様である。

（Ｓ１２１）属性管理部１１８ｂは、監視対象となる被監視装置２１０、２２０などの被監視装置からメッセージを受信したか否かを判定する。被監視装置からメッセージを受信した場合、属性管理部１１８ｂは、Ｓ１２２の動作に移る。一方、被監視装置からメッセージを受信していない場合、属性管理部１１８ｂは、再びＳ１２１の動作に戻る。

（Ｓ１２２）属性管理部１１８ｂは、他装置履歴データベース１１５ａを参照し、Ｓ１２１の動作で被監視装置から受信したメッセージが示すイベントと同じイベントに対応する第２実行履歴情報を探索する。このとき、属性管理部１１８ｂは、同じイベントに対応する第２実行履歴情報のうち、状態情報に付与されているアクションの実行結果が「成功」となっている第２実行履歴情報（以下、成功履歴情報）を抽出する。

なお、第１情報処理装置１１０が第２情報処理装置１３０から開始通知や終了通知を受信した場合には、図１３に示した方法で履歴更新部１１８ａにより他装置履歴データベース１１５ａがその都度更新される。そのため、イベントに対するアクションの実行を開始する前に、属性管理部１１８ｂは、第２情報処理装置１３０が既に同じイベントに対するアクションの実行を成功しているか確認できる。

（Ｓ１２３）属性管理部１１８ｂは、Ｓ１２２の動作で他装置履歴データベース１１５ａから成功履歴情報を抽出できた場合、Ｓ１２４の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第２情報処理装置１３０が既にアクションを実行して成功している場合、属性管理部１１８ｂは、Ｓ１２４の動作に移る。

一方、Ｓ１２２の動作で他装置履歴データベース１１５ａから成功履歴情報を抽出できなかった場合、属性管理部１１８ｂは、Ｓ１２６の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第２情報処理装置１３０がアクションを実行していないか、成功していない場合、属性管理部１１８ｂは、Ｓ１２６の動作に移る。

「主系」として第１情報処理装置１１０が正常動作している場合（停止せずに動作している場合）、通常、メッセージが示すイベントに対するアクションは第１情報処理装置１１０が実行する。そのため、同じイベントの成功履歴情報が他装置履歴データベース１１５ａに格納されていない。しかし、何らかの理由で先に第２情報処理装置１３０が同じイベントに対するアクションを実行した場合、同じイベントの成功履歴情報が他装置履歴データベース１１５ａに格納されることがある。このような状況として、例えば、第１情報処理装置１１０に対してのみメッセージの到達が極端に遅れた場合などが考えられる。

（Ｓ１２４）属性管理部１１８ｂは、Ｓ１２１の動作で被監視装置から受信したメッセージが示すイベントに対するアクションの実行を抑止する。つまり、属性管理部１１８ｂは、このイベントに対するアクションを第１情報処理装置１１０では実行しないこととする。

（Ｓ１２５）属性管理部１１８ｂは、第３記憶部１１７に格納された属性情報を変更し、第１情報処理装置１１０の属性を「主系」から「従系」へと変更する。他装置履歴データベース１１５ａに成功履歴情報が格納されている場合、第２情報処理装置１３０が「主系」としてアクションを実行しているため、その後は第１情報処理装置１１０が「従系」として動作する。Ｓ１２５の動作を完了すると、１つのメッセージに対するアクションの実行についての処理が終了する。

（Ｓ１２６）属性管理部１１８ｂは、アクションの実行を開始し、第２情報処理装置１３０に開始通知を送信してアクションの実行開始を通知する。
（Ｓ１２７）属性管理部１１８ｂは、第２情報処理装置１３０に送信した開始通知が正常に受信されたか否かを判定する。例えば、属性管理部１１８ｂは、第２情報処理装置１３０から開始通知に対する確認応答を受信したか否かを確認する。

第２情報処理装置１３０により開始通知が正常に受信された場合、属性管理部１１８ｂは、第２情報処理装置１３０が正常に動作していると認識し、Ｓ１２８の動作に移る。一方、第２情報処理装置１３０により開始通知が正常に受信されなかった場合、属性管理部１１８ｂは、第２情報処理装置１３０に障害が発生していると認識し、Ｓ１３０の動作に移る。

（Ｓ１２８）アクション実行部１１４は、メッセージが示すイベントに対するアクションを実行する。例えば、該当するイベント種別に対応するアクションがメール通知である場合、アクション実行部１１４は、端末装置３００に対してイベントの発生及びその内容を通知する電子メールを送信する。端末装置３００へ電子メールを送信できた場合、属性管理部１１８ｂは、アクションの実行が成功したと判断する。端末装置３００へ電子メールを送信できなかった場合、属性管理部１１８ｂは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部１１８ｂは、Ｓ１２９の動作に移る。

（Ｓ１２９）属性管理部１１８ｂは、アクションの実行結果を含む終了通知を第２情報処理装置１３０に送信してアクションの実行終了を通知する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、属性管理部１１８ｂは、その実行動作について開始通知の送信、アクションの実行、及び終了通知の送信を行う。Ｓ１２９の動作を終了すると、１つのメッセージに対するアクションの実行についての処理が終了する。

（Ｓ１３０）属性管理部１１８ｂは、未通知履歴データベース１１６ａにイベント発生日時などの第１未通知履歴情報を格納する。このとき、属性管理部１１８ｂは、第１未通知履歴情報に含まれる状態情報を「実行中」に設定する。

（Ｓ１３１）アクション実行部１１４は、メッセージが示すイベントに対するアクションを実行する。例えば、アクション実行部１１４は、端末装置３００に対してイベントの発生及びその内容を通知する電子メールを送信する。この場合、端末装置３００へ電子メールを送信できた場合、属性管理部１１８ｂは、アクションの実行が成功したと判断する。一方、端末装置３００へ電子メールを送信できなかった場合、属性管理部１１８ｂは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部１１８ｂは、Ｓ１３２の動作に移る。

（Ｓ１３２）属性管理部１１８ｂは、未通知履歴データベース１１６ａに格納した第１未通知履歴情報の状態情報を「実行済」に更新する。さらに、属性管理部１１８ｂは、アクションの実行結果を状態情報に付加する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、Ｓ１３０〜Ｓ１３２の動作が再び行われる。Ｓ１３２の動作を終了すると、１つのメッセージに対するアクションの実行についての処理が終了する。

以上、第２の実施の形態に係る主系の装置の動作について説明した。
（従系の装置の動作について）
次に、第２の実施の形態に係る従系の装置の動作について、フロー図を参照しながら説明する。図１６は、第２の実施の形態に係る従系の装置の動作について説明するフロー図である。なお、一例として、第１情報処理装置１１０が「主系」、第２情報処理装置１３０が「従系」とし、第２情報処理装置１３０の動作を想定して説明する。但し、第１情報処理装置１１０が「従系」、第２情報処理装置１３０が「主系」の場合も同様である。

（Ｓ１４１）属性管理部１３８ｂは、監視対象となる被監視装置２１０、２２０などの被監視装置からメッセージを受信したか否かを判定する。被監視装置からメッセージを受信した場合、属性管理部１３８ｂは、Ｓ１４２の動作に移る。一方、被監視装置からメッセージを受信していない場合、属性管理部１３８ｂは、再びＳ１４１の動作に戻る。

（Ｓ１４２）属性管理部１３８ｂは、他装置履歴データベース１３５ａを参照し、Ｓ１４１の動作で被監視装置から受信したメッセージが示すイベントと同じイベントに対応する第１実行履歴情報を探索する。このとき、属性管理部１３８ｂは、同じイベントに対応する第１実行履歴情報のうち、成功履歴情報を抽出する。

なお、第２情報処理装置１３０が第１情報処理装置１１０から開始通知や終了通知を受信した場合には、図１３に示した方法で履歴更新部１３８ａにより他装置履歴データベース１３５ａがその都度更新される。そのため、イベントに対するアクションの実行を開始する前に、属性管理部１３８ｂは、第１情報処理装置１１０が既に同じイベントに対するアクションの実行を成功しているか確認できる。

（Ｓ１４３）属性管理部１３８ｂは、Ｓ１４２の動作で他装置履歴データベース１３５ａから成功履歴情報を抽出できた場合、Ｓ１４４の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第１情報処理装置１１０が既にアクションを実行して成功している場合、属性管理部１３８ｂは、Ｓ１４４の動作に移る。

一方、Ｓ１４２の動作で他装置履歴データベース１３５ａから成功履歴情報を抽出できなかった場合、属性管理部１３８ｂは、Ｓ１４５の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第１情報処理装置１１０がアクションを実行していないか、成功していない場合、属性管理部１３８ｂは、Ｓ１４５の動作に移る。

（Ｓ１４４）属性管理部１３８ｂは、Ｓ１４１の動作で被監視装置から受信したメッセージが示すイベントに対するアクションの実行を抑止する。つまり、属性管理部１３８ｂは、このイベントに対するアクションを第２情報処理装置１３０では実行しないこととする。Ｓ１４４の動作を完了すると、１つのメッセージに対するアクションの実行についての処理が終了する。

（Ｓ１４５）属性管理部１３８ｂは、Ｓ１４１の動作で被監視装置からメッセージを受信した後、Ｓ１４２の動作（以下、ポーリング）を所定回数行ったか否かを判定する。例えば、属性管理部１３８ｂは、Ｓ１４１の動作でメッセージを受信した際にカウンタをリセットし、Ｓ１４２の動作を行う度にカウンタの値を１ずつ増加させ、カウンタの値が所定の閾値（所定回数を示す値）に達したか否かを判定する。

ポーリングの回数が所定回数に達していない場合、属性管理部１３８ｂは、Ｓ１４６の動作に移る。一方、ポーリングの回数が所定回数に達した場合、属性管理部１３８ｂは、Ｓ１４７の動作に移る。なお、所定回数（例えば、１０回）は予め設定される。例えば、ポーリングを所定回数だけ実行した際に要する時間が、１つのアクションを第１情報処理装置１１０が実行して成功させるのに十分と考えられる時間となるように所定回数が設定される。

（Ｓ１４６）属性管理部１３８ｂは、所定時間（以下、ポーリング間隔）だけ待機する。つまり、属性管理部１３８ｂは、自身が受信したメッセージと同じメッセージが示すイベントに対して第１情報処理装置１１０がアクションを成功させるのを待ち受ける。例えば、ポーリング間隔は、第１情報処理装置１１０が正常動作している状態で１つのアクションを１回実行完了するまでに要すると予想される時間に予め設定される。ポーリング間隔は、例えば、６０秒に設定される。

（Ｓ１４７）履歴更新部１３８ａは、Ｓ１４１の動作で受信したメッセージが示すイベントに対するアクションを開始し、未通知履歴データベース１３６ａにイベント発生日時などの第２未通知履歴情報を格納する。

（Ｓ１４８）アクション実行部１３４は、メッセージが示すイベントに対するアクションを実行する。例えば、イベント種別がメール通知の場合、アクション実行部１３４は、端末装置３００に対してイベントの発生及びその内容を通知する電子メールを送信する。端末装置３００へ電子メールを送信できた場合、属性管理部１３８ｂは、アクションの実行が成功したと判断する。一方、端末装置３００へ電子メールを送信できなかった場合、属性管理部１３８ｂは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部１３８ｂは、Ｓ１４９の動作に移る。

（Ｓ１４９）属性管理部１３８ｂは、未通知履歴データベース１３６ａに格納した第２未通知履歴情報の状態情報を「実行済」に更新する。さらに、属性管理部１３８ｂは、アクションの実行結果を状態情報に付与する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、Ｓ１４７〜Ｓ１４９の動作が再び実行される。Ｓ１４９の動作を終了すると、属性管理部１３８ｂは、Ｓ１５０の動作に移る。

（Ｓ１５０）属性管理部１３８ｂは、第３記憶部１３７に格納された自身の属性情報を更新し、第２情報処理装置１３０の属性を「従系」から「主系」へと変更する。Ｓ１５０の動作を終了すると、１つのメッセージに対するアクションの実行についての処理が終了する。

以上、第２の実施の形態に係る従系の装置の動作について説明した。
［変形例＃１：ポーリング間隔の調整］
ここで、第２の実施の形態に係る一変形例（変形例＃１）について説明する。変形例＃１では、（１）ポーリング間隔をアクション種別毎に設定する方法、及び（２）実際に計測されたアクションの実行時間に基づいてポーリング間隔を調整する方法を提案する。なお、ここでは、説明の都合上、第２情報処理装置１３０の属性が「従系」である場合を想定し、第２情報処理装置１３０がポーリング間隔を調整する例について説明する。但し、第１情報処理装置１１０の属性が「従系」である場合についても同様である。

変形例＃１に係る第２情報処理装置１３０は、上述した所定回数（ポーリングの最大実行回数）及びポーリング間隔の初期値を示す情報を第３記憶部１３７に保持している。そして、属性管理部１３８ｂは、この情報に基づいて動作し、アクション種別毎に１回のアクションの実行に要した時間（以下、実行時間）を計測する。例えば、属性管理部１３８ｂは、開始通知を受信してから終了通知を受信するまでの時間を計測して実行時間とする。そして、属性管理部１３８ｂは、計測した実行時間の情報を第３記憶部１３７に格納する。

さらに、属性管理部１３８ｂは、同じアクション種別について過去に計測した実行時間と現在計測した実行時間との平均値を算出する。例えば、属性管理部１３８ｂが計測した実行時間の情報及び平均値の情報は、図１７のようにアクション種別毎に保持される。図１７は、第２の実施の形態の一変形例（変形例＃１）に係るポーリング間隔テーブルの生成に用いる情報の例を示した図である。こうした情報に基づき、属性管理部１３８ｂは、アクション種別と平均値とを対応付けた情報（以下、ポーリング間隔テーブル）を生成して第３記憶部１３７に格納する。

属性管理部１３８ｂは、第１情報処理装置１１０でアクションが実行される度に実行時間を計測し、計測した実行時間を用いて平均値を算出する。そして、属性管理部１３８ｂは、算出した平均値を用いてポーリング間隔テーブルを更新する。さらに、属性管理部１３８ｂは、ポーリング間隔テーブルに記載されている平均値をポーリング間隔に設定する。このとき、属性管理部１３８ｂは、アクション種別毎にポーリング間隔を設定する。なお、ポーリング間隔の設定タイミングは、ポーリング間隔テーブルの更新時でもよいし、実行時間の計測回数が所定の閾値を超えたときやユーザによる設定の指示があったときでもよい。

ここで、ポーリング間隔テーブルの更新方法について、フロー図を参照しながら説明する。図１８は、第２の実施の形態の一変形例（変形例＃１）に係るポーリング間隔テーブルの更新方法について説明するフロー図である。

（Ｓ２０１）属性管理部１３８ｂは、第１情報処理装置１１０から開始通知を受信したか否かを判定する。開始通知を受信した場合、属性管理部１３８ｂは、Ｓ２０２の動作に移る。一方、開始通知を受信していない場合、属性管理部１３８ｂは、再びＳ２０１の動作に移る。

（Ｓ２０２）属性管理部１３８ｂは、実行時間の計測を開始する。例えば、属性管理部１３８ｂは、計測を開始した時刻の情報を保持する。
（Ｓ２０３）属性管理部１３８ｂは、第１情報処理装置１１０から終了通知を受信したか否かを判定する。終了通知を受信した場合、属性管理部１３８ｂは、Ｓ２０５の動作に移る。つまり、第１情報処理装置１１０により１つのアクションの実行が終了したことが確認された際に、属性管理部１３８ｂは、Ｓ２０５の動作に移る。一方、終了通知を受信していない場合、属性管理部１３８ｂは、Ｓ２０４の動作に移る。

（Ｓ２０４）属性管理部１３８ｂは、ポーリングを所定回数行ったか否かを判定する。ポーリングの回数が所定回数に達している場合、属性管理部１３８ｂは、ポーリング間隔テーブルの更新を行わず、ポーリング間隔テーブルの更新に関する動作を終了する。つまり、図１６に示したフロー図におけるＳ１４５の動作で、属性管理部１３８ｂがＳ１４７の動作に移った場合、ポーリング間隔テーブルの更新は行われない。一方、ポーリングの回数が所定回数に達していない場合、属性管理部１３８ｂは、再びＳ２０３の動作に移る。

（Ｓ２０５）属性管理部１３８ｂは、実行時間の計測を終了する。例えば、属性管理部１３８ｂは、計測を終了した時刻の情報を保持する。そして、属性管理部１３８ｂは、計測を開始した時刻から計測を終了した時刻までの時間を計算し、計算した時間を実行時間とする。

（Ｓ２０６）属性管理部１３８ｂは、Ｓ２０５の動作で今回計測した実行時間に対応するアクションと同じアクション種別について、過去に計測した実行時間の情報を保持している場合、今回計測した実行時間と過去に計測した実行時間との平均値を計算する。

（Ｓ２０７）属性管理部１３８ｂは、Ｓ２０６の動作で計算した平均値を用いてポーリング間隔テーブルを更新する。Ｓ２０７の動作を終了すると、属性管理部１３８ｂは、ポーリング間隔テーブルの更新について処理を終了する。

以上、第２の実施の形態に係る一変形例（変形例＃１）について説明した。変形例＃１によれば、アクション種別毎に実際に計測された実行時間に基づいてポーリング間隔が設定されるため、「主系」に障害が生じた場合に適切なタイミングで「従系」が「主系」として動作できるようになる。さらに、他装置履歴データベース１３５ａへのアクセス頻度が大きくなり過ぎないように調整されるため、ポーリングに伴う負荷を低減できる。

なお、上記の説明においては、ポーリングを行う最大回数である所定回数を固定値と考えていたが、この所定回数を実行時間に応じて変更してもよい。例えば、ポーリング間隔を固定して所定回数を増加させれば、「主系」に障害が生じたと判断するまでの待ち時間を延ばすことができる。逆に、ポーリング間隔を固定して所定回数を減少させれば、「主系」に障害が生じたと判断するまでの待ち時間を短縮することができる。そのため、実際に計測された実行時間に応じて所定回数を増減させることで、適切なタイミングで属性の変更及び動作の引き継ぎを行うことが可能になる。

［変形例＃２：従系への実行依頼］
次に、第２の実施の形態に係る一変形例（変形例＃２）について説明する。変形例＃２では、「主系」の負荷が高い場合に、実行すべき一部のアクションを「従系」に実行依頼する方法を提案する。なお、ここでは、説明の都合上、第１情報処理装置１１０の属性が「主系」であり、第２情報処理装置１３０の属性が「従系」である場合を想定して説明する。但し、第１情報処理装置１１０の属性が「従系」であり、第２情報処理装置１３０の属性が「主系」である場合についても同様である。

（装置の動作及びアクション負荷値テーブルについて）
変形例＃２に係る主系及び従系の装置の動作について説明する。図１９は、第２の実施の形態の一変形例（変形例＃２）に係る主系及び従系の装置の動作について説明する図である。

例えば、「主系」である第１情報処理装置１１０がアクション＃１〜＃３を実行中である場合に、第１情報処理装置１１０及び第２情報処理装置１３０に新たなメッセージ（アクション＃４に対応）が送信された状況を想定する。この状況では、高負荷状態にある「主系」の第１情報処理装置１１０がアクション＃４を実行するよりも、「従系」の第２情報処理装置１３０がアクション＃４を実行する方が効率的である。そこで、変形例＃２に係る第１情報処理装置１１０は、アクション＃４を実行した場合における自身の負荷状況（例えば、ＣＰＵ使用率など）を予測し、高負荷状態になると判断し、かつ、一定の条件満たした場合にアクション＃４を第２情報処理装置１３０に依頼する。

第１情報処理装置１１０による負荷状況の予測は、例えば、負荷状況を表す評価値（以下、アクション負荷値）に基づいて行われる。例えば、属性管理部１１８ｂは、アクション負荷値が所定の閾値（以下、アクション切り替え境界値）を超えた場合にアクション＃４を第２情報処理装置１３０に依頼する。アクション負荷値は、属性管理部１１８ｂにより計算され、第３記憶部１１７に格納されるアクション負荷値テーブルに記録される。

ここで、アクション負荷値の計算方法及びアクション負荷値テーブルについて、さらに説明する。図２０は、第２の実施の形態の一変形例（変形例＃２）に係るアクション負荷値テーブルの生成に用いる情報の例を示した図である。

アクション負荷値は、アクション種別毎に計算される。属性管理部１１８ｂは、アクションを実行する際、アクションの実行時間、アクションの実行期間における平均メモリ使用量及び平均ＣＰＵ使用率を保持する。そして、属性管理部１１８ｂは、例えば、（実行時間（秒）×平均メモリ使用量（キロバイト（ＫＢ））×平均ＣＰＵ使用率（％））をアクション負荷値とする。なお、ここで示した各値の単位は一例である。

図２０の例では、アクション種別が「メール通知」であるアクションについて、実行時間「１秒」、平均メモリ使用量「５０ＫＢ」、平均ＣＰＵ使用率「１％」が得られており、これらの値に基づくとアクション負荷値は（１×５０×１）＝５０となる。他のアクション種別についても同様である。このような方法で、属性管理部１１８ｂは、アクション種別毎にアクション負荷値を計算し、アクション負荷値テーブルに記録する。

なお、アクション負荷値テーブルに記録したものと同じアクション種別のアクション負荷値を新たに算出した場合、属性管理部１１８ｂは、それらの平均値を新たなアクション負荷値としてアクション負荷値テーブルの情報を更新する。

（アクション負荷値テーブルの更新方法について）
ここで、アクション負荷値テーブルの更新方法について、フロー図を参照しながら説明する。図２１は、第２の実施の形態の一変形例（変形例＃２）に係るアクション負荷値テーブルの更新方法について説明するフロー図である。

（Ｓ３０１）属性管理部１１８ｂは、アクションの実行を開始するか否かを判定する。アクションの実行を開始する場合、属性管理部１１８ｂは、Ｓ３０２の動作に移る。つまり、図１５に示したフロー図におけるＳ１２８又はＳ１３１の動作に移った場合、属性管理部１１８ｂは、Ｓ３０２の動作に移る。一方、アクションの実行を開始しない場合、属性管理部１１８ｂは、再びＳ３０１の動作に移る。

（Ｓ３０２）属性管理部１１８ｂは、実行時間の計測を開始する。例えば、属性管理部１１８ｂは、アクションの実行を開始する時刻を保持する。
（Ｓ３０３）属性管理部１１８ｂは、アクション負荷値の計算用にメモリ使用量の記録を開始する。記録を開始した後、属性管理部１１８ｂは、アクションの実行が終了するまでの間、所定の時間間隔で定期的にメモリ使用量の情報を記録する。所定の時間間隔は、予めユーザにより任意に設定されているものとする。

（Ｓ３０４）属性管理部１１８ｂは、アクション負荷値の計算用にＣＰＵ使用率の記録を開始する。記録を開始した後、属性管理部１１８ｂは、アクションの実行が終了するまでの間、所定の時間間隔で定期的にＣＰＵ使用率の情報を記録する。所定の時間間隔は、予めユーザにより任意に設定されているものとする。なお、Ｓ３０２〜Ｓ３０４の動作は任意に順序を入れ替えてよい。

（Ｓ３０５）属性管理部１１８ｂは、アクションの実行が終了したか否かを判定する。アクションの実行が終了した場合、属性管理部１１８ｂは、Ｓ３０６の動作に移る。つまり、図１５に示したフロー図におけるＳ１２９又はＳ１３２の動作に移った場合、属性管理部１１８ｂは、Ｓ３０６の動作に移る。一方、アクションの実行が終了していない場合、属性管理部１１８ｂは、再びＳ３０５の動作に移る。

（Ｓ３０６）属性管理部１１８ｂは、実行時間の計測を終了する。例えば、属性管理部１１８ｂは、アクションの実行を終了した時刻を保持し、実行を開始した時刻から実行を終了した時刻までの時間を計算して実行時間とする。

（Ｓ３０７）属性管理部１１８ｂは、Ｓ３０３の動作で記録を開始してからアクションが終了するまでの間に定期的に記録されたメモリ使用量を読み出し、読み出したメモリ使用量の平均値を計算する。属性管理部１１８ｂは、計算した平均値をアクション負荷値の計算に用いる平均メモリ使用量とする。

（Ｓ３０８）属性管理部１１８ｂは、Ｓ３０４の動作で記録を開始してからアクションが終了するまでの間に定期的に記録されたＣＰＵ使用率を読み出し、読み出したＣＰＵ使用率の平均値を計算する。属性管理部１１８ｂは、計算した平均値をアクション負荷値の計算に用いる平均ＣＰＵ使用率とする。なお、Ｓ３０６〜Ｓ３０８の動作は任意に順序を入れ替えてもよい。

（Ｓ３０９）属性管理部１１８ｂは、Ｓ３０６〜Ｓ３０８の動作で計算された実行時間、平均メモリ使用量、及び平均ＣＰＵ使用率に基づいてアクション負荷値（実行時間×平均メモリ使用量×平均ＣＰＵ使用率）を計算する。

（Ｓ３１０）属性管理部１１８ｂは、Ｓ３０９の動作で計算したアクション負荷値を用いてアクション負荷値テーブルを更新する。なお、Ｓ３０９の動作で計算したアクション負荷値と同じアクション種別のアクション負荷値がアクション負荷値テーブルに記録されている場合、属性管理部１１８ｂは、これら２つのアクション負荷値の平均値を用いてアクション負荷値テーブルを更新する。Ｓ３１０の動作を終了すると、属性管理部１１８ｂは、アクション負荷値テーブルの更新について処理を終了する。

（アクション切り替え境界値の更新方法について）
ここで、高負荷状況か否かを判定する際に閾値として用いられるアクション切り替え境界値の更新方法について、フロー図を参照しながら説明する。図２２は、第２の実施の形態の一変形例（変形例＃２）に係るアクション切り替え境界値の更新方法について説明するフロー図である。なお、アクション切り替え境界値は、その値が大きいほど従系への実行依頼が発生しにくくなり、逆に値が小さいほど実行依頼が発生しやすくなる。

（Ｓ３１１）属性管理部１１８ｂは、アクション切り替え境界値の更新タイミングになったか否かを判定する。アクション切り替え境界値の更新タイミングは任意に設定することができるが、一例として、ここでは一定の時間間隔で更新が行われる場合を想定している。従って、一定の時間間隔で更新タイミングが訪れる。更新タイミングになった場合、属性管理部１１８ｂは、Ｓ３１２の動作に移る。一方、更新タイミングになっていない場合、属性管理部１１８ｂは、再びＳ３１１の動作に移る。

（Ｓ３１２）属性管理部１１８ｂは、第２情報処理装置１３０に対してＣＰＵ使用率の情報を送信するように要求する。第２情報処理装置１３０のＣＰＵ使用率の情報を受信した場合、属性管理部１１８ｂは、受信したＣＰＵ使用率の情報を保持する。

（Ｓ３１３）属性管理部１１８ｂは、前回の更新タイミングの際に第２情報処理装置１３０から受信して保持しているＣＰＵ使用率（以下、前回ＣＰＵ使用率）の情報を参照する。さらに、属性管理部１１８ｂは、今回の更新タイミングの際に第２情報処理装置１３０から受信して保持しているＣＰＵ使用率（以下、今回ＣＰＵ使用率）の情報を参照する。そして、属性管理部１１８ｂは、前回ＣＰＵ使用率に比べて今回ＣＰＵ使用率の方が大きいか否かを判定する。

前回ＣＰＵ使用率よりも今回ＣＰＵ使用率の方が大きい場合、属性管理部１１８ｂは、Ｓ３１５の動作に移る。一方、前回ＣＰＵ使用率よりも今回ＣＰＵ使用率の方が小さいか、同じの場合、属性管理部１１８ｂは、Ｓ３１４の動作に移る。

（Ｓ３１４）属性管理部１１８ｂは、アクション切り替え境界値を減少させる。つまり、前回の更新タイミングでアクション切り替え境界値を更新したが、第２情報処理装置１３０の負荷状況が悪化していないので、第２情報処理装置１３０に余裕があると考え、属性管理部１１８ｂは、従系の実行依頼が発生しやすくなるようにする。Ｓ３１４の動作を終えると、属性管理部１１８ｂは、アクション切り替え境界値の更新（１回分）について処理を終了する。

（Ｓ３１５）属性管理部１１８ｂは、アクション切り替え境界値を増加させる。つまり、前回の更新タイミングでアクション切り替え境界値を更新した結果、第２情報処理装置１３０の負荷状況が悪化したので、属性管理部１１８ｂは、従系の実行依頼が発生しにくくなるようにする。Ｓ３１５の動作を終えると、アクション切り替え境界値の更新（１回分）についての処理が終了する。

（実行依頼の要否判定方法について）
次に、上記のアクション負荷値テーブル及びアクション切り替え境界値を利用した従系への実行依頼（アクション切り替え判定）方法について、フロー図を参照しながら説明する。図２３は、第２の実施の形態の一変形例（変形例＃２）に係る実行依頼の要否判定方法について説明する第１のフロー図である。なお、第１情報処理装置１１０の属性が「主系」であるとする。

（Ｓ３２１）属性管理部１１８ｂは、次に実行するアクションが発生したか否かを判定する。次に実行するアクションが発生した場合、属性管理部１１８ｂは、Ｓ３２２の動作に移る。つまり、属性管理部１１８ｂは、図１５に示したフロー図のＳ１２６の動作に移る場合、すぐにはＳ１２６の動作へ移らずにＳ３２２以降の動作を行う。次に実行するアクションが発生していない場合、属性管理部１１８ｂは、再びＳ３２１の動作に移る。

（Ｓ３２２）属性管理部１１８ｂは、アクション負荷値テーブルを参照し、実行中のアクションと同じアクション種別のアクション負荷値を取得する。なお、実行中のアクションが複数存在する場合、属性管理部１１８ｂは、全てのアクションについてアクション負荷値を取得する。さらに、属性管理部１１８ｂは、次に実行するアクションと同じアクション種別のアクション負荷値を取得する。

（Ｓ３２３）属性管理部１１８ｂは、実行中のアクションのアクション負荷値と、次に実行するアクションのアクション負荷値とを合計して合計値を算出する。なお、実行中のアクションが複数存在する場合、属性管理部１１８ｂは、全ての実行中のアクションに対応するアクション負荷値及び次に実行するアクションのアクション負荷値を合計して合計値を算出する。

（Ｓ３２４）属性管理部１１８ｂは、Ｓ３２３の動作で算出した合計値がアクション切り替え境界値よりも大きいか否かを判定する。つまり、属性管理部１１８ｂは、次に実行するアクションを実行した場合に予測される自身の負荷状況を示す合計値が、実行依頼の要否を判定する閾値となるアクション切り替え境界値よりも大きいか否かを判定する。合計値がアクション切り替え境界値よりも大きい場合、属性管理部１１８ｂは、図２４に示したＳ３２５の動作に移る。一方、合計値がアクション切り替え境界値よりも小さい場合、属性管理部１１８ｂは、図２４に示したＳ３２９の動作に移る。

次に、図２４を参照する。図２４は、第２の実施の形態の一変形例（変形例＃２）に係る実行依頼の要否判定方法について説明する第２のフロー図である。
（Ｓ３２５）属性管理部１１８ｂは、Ｓ３２５の動作時における自身の負荷状況を示す値（以下、主系のシステム負荷値）を算出する。例えば、属性管理部１１８ｂは、ＣＰＵ使用率及びメモリ使用量を検出し、（ＣＰＵ使用率×メモリ使用量）を主系のシステム負荷値とする。この主系のシステム負荷値は、アクション切り替え判定を行う時点における属性管理部１１８ｂの実際の負荷状況を表すものである。

（Ｓ３２６）属性管理部１１８ｂは、Ｓ３２６の動作時における第２情報処理装置１３０の負荷状況を示す値（以下、従系のシステム負荷値）を算出する。例えば、属性管理部１１８ｂは、第２情報処理装置１３０に対してＣＰＵ使用率及びメモリ使用量を検出して送信するように依頼し、第２情報処理装置１３０からＣＰＵ使用率及びメモリ使用量の情報を受信する。そして、属性管理部１１８ｂは、第２情報処理装置１３０から受信した情報に基づき、（ＣＰＵ使用率×メモリ使用量）を計算して従系のシステム負荷値とする。この従系のシステム負荷値は、アクション切り替え判定を行う時点における第２情報処理装置１３０の実際の負荷状況を表すものである。なお、Ｓ３２５の動作とＳ３２６の動作とは順序を入れ替えてもよい。

（Ｓ３２７）属性管理部１１８ｂは、主系のシステム負荷値が従系のシステム負荷値よりも大きいか否かを判定する。主系のシステム負荷値が従系のシステム負荷値よりも大きい場合、属性管理部１１８ｂは、Ｓ３２８の動作に移る。つまり、次に実行するアクションを実行した場合に高負荷状態になると予想され、現時点の負荷状況を比較すると第２情報処理装置１３０の方が低負荷の状態にある場合、属性管理部１１８ｂは、Ｓ３２８の動作に移る。

一方、主系のシステム負荷値が従系のシステム負荷値よりも小さい場合、属性管理部１１８ｂは、Ｓ３２９の動作に移る。つまり、次に実行するアクションを実行した場合には高負荷状態になると予想されるが、現時点の負荷状況を比較すると第２情報処理装置１３０の方が高負荷の状態にある場合、属性管理部１１８ｂは、Ｓ３２９の動作に移る。

（Ｓ３２８）属性管理部１１８ｂは、次に実行するアクションを従系に依頼する。例えば、属性管理部１１８ｂは、次に実行するアクションに対応するメッセージを特定できる情報（例えば、イベントＩＤ及び発生元装置名）を含めて実行依頼を第２情報処理装置１３０に送信する。Ｓ３２８の動作を終えると、属性管理部１１８ｂは、そのアクションの実行を抑止し（図１５に示したフロー図におけるＳ１２６の動作には移らずに終了する。）、アクション切り替え判定について処理を終了する。

（Ｓ３２９）属性管理部１１８ｂは、次に実行するアクションを情報処理装置１１０で実行する。つまり、属性管理部１１８ｂは、図１５に示したフロー図におけるＳ１２６の動作に移る。Ｓ３２９の動作を終えると、アクション切り替え判定についての処理が終了する。

（従系の装置の動作について）
次に、主系の装置から実行依頼を受信する場合を想定した従系の装置の動作について、フロー図を参照しながら説明する。図２５は、第２の実施の形態の一変形例（変形例＃２）に係る従系の装置の動作について説明するフロー図である。なお、第１情報処理装置１１０の属性が「主系」であり、第２情報処理装置１３０の属性が「従系」であるとする。

（Ｓ３３１）属性管理部１３８ｂは、第１情報処理装置１１０から実行依頼を受信したか否かを判定する。「従系」である第２情報処理装置１３０の属性管理部１３８ｂは、メッセージを受信した後、ポーリングを繰り返しながら成功履歴情報を履歴更新部１３８ａが他装置履歴データベース１３５ａに格納するか、所定のポーリング回数に達するまで待機する。この間に、第１情報処理装置１１０により上述したアクション切り替え判定の処理が実行される。この処理の中で所定の条件を満たした場合に第１情報処理装置１１０が送信した実行依頼を第２情報処理装置１３０は受信する。実行依頼を受信した場合、属性管理部１３８ｂは、Ｓ３３２の動作に移る。一方、実行依頼を受信していない場合、属性管理部１３８ｂは、ポーリングの動作を継続する。

（Ｓ３３２）属性管理部１３８ｂは、実行依頼で指定されたアクションの実行を開始し、そのアクションの実行開始を示す開始通知を第１情報処理装置１１０に送信する。
（Ｓ３３３）アクション実行部１３４は、アクションを実行する。例えば、アクション実行部１３４は、端末装置３００に対してイベントの発生及びその内容を通知する電子メールを送信する。端末装置３００へ電子メールを送信できた場合、属性管理部１３８ｂは、アクションの実行が成功したと判断する。一方、端末装置３００へ電子メールを送信できなかった場合、属性管理部１３８ｂは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部１３８ｂは、Ｓ３３４の動作に移る。

（Ｓ３３４）属性管理部１３８ｂは、アクションの実行結果を含む終了通知を第１情報処理装置１１０に送信してアクションの実行終了を通知する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、属性管理部１３８ｂは、開始通知の送信、アクションの実行制御、及び終了通知の送信を行う。Ｓ３３４の動作を終了すると、実行依頼されたアクションの実行についての処理が終了する。

以上、第２の実施の形態に係る一変形例（変形例＃２）について説明した。変形例＃２によれば、主系の装置が高負荷状態にある場合に、一部のアクションを従系の装置で実行することが可能になる。また、変形例＃２の場合、新たに実行するアクションを実行した場合に予測される主系の負荷状況と、そのアクションを実行する前の主系及び従系における実際の負荷状況とを共に考慮して実行依頼を行うか否かを判断する。そのため、アクション以外の処理によって従系の装置が高負荷状態になっている状況なども考慮して適切に実行依頼が行われる。

［変形例＃３：未通知履歴データベースの簡略化］
次に、第２の実施の形態の一変形例（変形例＃３）について説明する。変形例＃３では、障害から復旧した装置に対して送信する未通知履歴情報のデータ量を低減する方法を提案する。なお、この方法を適用することで、未通知履歴データベース１１６ａ、１３６ａに格納されるデータ量も低減される。以下では、第１情報処理装置１１０の未通知履歴データベース１１６ａを例に説明を進める。但し、第２情報処理装置１３０の未通知履歴データベース１３６ａについても同様である。

（未通知履歴データベースについて）
図２６は、第２の実施の形態の一変形例（変形例＃３）に係る未通知履歴データベースの例を示した図である。図２６に示すように、変形例＃３に係る未通知履歴データベース１１６ａは、少なくとも発生元装置名及びイベント発生日時を格納したものであればよい。イベント発生日時の情報は、発生元装置名毎に最新の情報に更新される。

例えば、未通知履歴データベース１１６ａに発生元装置名及びイベント発生日時を格納する場合、属性管理部１１８ｂは、同じ発生元装置名に対応するイベント発生日時が未通知履歴データベース１１６ａに格納されているか確認する。同じ発生元装置名に対応するイベント発生日時が未通知履歴データベース１１６ａに格納されている場合、属性管理部１１８ｂは、そのイベント発生日時を最新のイベント発生日時で更新する。一方、同じ発生元装置名に対応するイベント発生日時が未通知履歴データベース１１６ａに格納されていない場合、属性管理部１１８ｂは、発生元装置名とイベント発生日時とを対応付けて未通知履歴データベース１１６ａに格納する。

（未通知履歴データベースの更新方法について）
ここで、変形例＃３に係る未通知履歴データベースの更新方法について、フロー図を参照しながら説明する。図２７は、第２の実施の形態の一変形例（変形例＃３）に係る未通知履歴データベースの更新方法について説明するフロー図である。なお、第１情報処理装置１１０が「主系」である場合も「従系」である場合も同様である。

変形例＃３の場合（但し、第１情報処理装置１１０が「主系」の場合）、図１５に示したフロー図のＳ１３０及びＳ１３２の動作が省略され、Ｓ１３１の動作が実行された後で図２７に示したフロー図の動作が実行される形となる。さらに、変形例＃３の場合（但し、第１情報処理装置１１０が「従系」の場合）、図１６に示したフロー図のＳ１４７及びＳ１４９の動作が省略され、Ｓ１４９の動作が実行された後で図２７に示したフロー図の動作が実行される形となる。

（Ｓ４０１）属性管理部１１８ｂは、アクションの実行が成功したか否かを判定する。アクションの実行が成功した場合、属性管理部１１８ｂは、Ｓ４０２の動作に移る。一方、アクションの実行が成功していない場合、属性管理部１１８ｂは、再びＳ４０１の動作に移る。

（Ｓ４０２）属性管理部１１８ｂは、未通知履歴データベース１１６ａを参照し、実行したアクションに対応するイベントの発生元を示す発生元装置名と同じ発生元装置名を検索する。

（Ｓ４０３）属性管理部１１８ｂは、未通知履歴データベース１１６ａから、実行したアクションに対応するイベントの発生元を示す発生元装置名と同じ発生元装置名を見つけた場合、Ｓ４０５の動作に移る。つまり、第２情報処理装置１３０で障害が発生している間に、同じ発生元装置名の装置で発生した何らかのイベントに対して第１情報処理装置１１０がアクションを実行して成功している場合、属性管理部１１８ｂは、Ｓ４０５の動作に移る。

一方、実行したアクションに対応するイベントの発生元を示す発生元装置名と同じ発生元装置名が未通知履歴データベース１１６ａで見つからなかった場合、属性管理部１１８ｂは、Ｓ４０４の動作に移る。つまり、第２情報処理装置１３０で障害が発生している間に、同じ発生元装置名の装置でイベントが発生していないか、発生したイベントに対して第１情報処理装置１１０がアクションを成功させていない場合、属性管理部１１８ｂは、Ｓ４０４の動作に移る。

（Ｓ４０４）属性管理部１１８ｂは、実行したアクションに対応するイベントの発生元を示す発生元装置名及びイベント発生日時を対応付けて未通知履歴データベース１１６ａに格納する。Ｓ４０４の動作を終えると、属性管理部１１８ｂは、未通知履歴データベース１１６ａの更新について処理を終了する（図１５のフロー図では処理の終了へ動作が移る。図１６のフロー図ではＳ１５０の動作に移る。）。

（Ｓ４０５）属性管理部１１８ｂは、実行したアクションに対応するイベントのイベント発生日時と、未通知履歴データベース１１６ａに格納された同じ発生元装置名に対応するイベント発生日時とを比較する。そして、未通知履歴データベース１１６ａのイベント発生日時が古い場合、属性管理部１１８ｂは、実行したアクションに対応するイベントのイベント発生日時で未通知履歴データベース１１６ａのイベント発生日時を更新する。Ｓ４０５の動作を終えると、未通知履歴データベース１１６ａの更新についての処理が終了する（図１５のフロー図では処理の終了へ動作が移る。図１６のフロー図ではＳ１５０の動作に移る。）。

（未通知履歴情報に基づく成功履歴の有無判断について）
上記のように未通知履歴情報の内容を簡略化した場合、第２情報処理装置１３０が復旧した際の動作が一部変更される。具体的には、第２情報処理装置１３０が未通知メッセージを処理する際、未通知メッセージに対応するイベントを第１情報処理装置１１０が実行して成功しているか否かを判定する際の動作が変更される。なお、第１情報処理装置１１０が復旧する際の動作についても同様である。

以下、変形例＃３に係る未通知履歴情報に基づいて成功履歴の有無を判断する方法について、フロー図を参照しながら説明する。図２８は、第２の実施の形態の一変形例（変形例＃３）に係る未通知履歴情報に基づいて成功履歴の有無を判断する方法について説明するフロー図である。

（Ｓ４１１）属性管理部１３８ｂは、復旧時に第１情報処理装置１１０から取得した未通知履歴情報を参照し、未通知メッセージに対応する発生元装置名と同じ発生元装置名を検索する。

（Ｓ４１２）属性管理部１３８ｂは、Ｓ４１１の動作で同じ発生元装置名を発見できたか否かを判定する。つまり、属性管理部１３８ｂは、第２情報処理装置１３０に障害が発生している間に、同じ発生元装置名の被監視装置で発生した少なくとも１つのイベントに対するアクションが第１情報処理装置１１０により完了しているか否かを判定する。同じ発生元装置名を発見できた場合、属性管理部１３８ｂは、Ｓ４１３の動作に移る。一方、同じ発生元装置名を発見できなかった場合、属性管理部１３８ｂは、Ｓ４１５の動作に移る。

（Ｓ４１３）属性管理部１３８ｂは、未通知メッセージが示すイベント発生日時より、未通知履歴情報から発見された同じ発生元装置名に対応するイベント発生日時の方が新しいか否かを判定する。つまり、属性管理部１３８ｂは、未通知メッセージが示すイベントよりも後に発生したイベントに対して第１情報処理装置１１０がアクションを実行して成功しているか否かを判定する。未通知履歴情報のイベント発生日時の方が新しい場合、属性管理部１３８ｂは、Ｓ４１４の動作に移る。一方、未通知メッセージのイベント発生日時の方が新しい場合、属性管理部１３８ｂは、Ｓ４１５の動作に移る。

（Ｓ４１４）属性管理部１３８ｂは、未通知メッセージが示すイベントに対して既に第１情報処理装置１１０がアクションを実行して成功していると判断する。Ｓ４１４の動作を終えると、属性管理部１３８ｂは、未通知履歴情報に基づいて成功履歴の有無を判断する動作を終了する。その後、属性管理部１３８ｂは、その未通知メッセージが示すイベントに対するアクションの実行を抑止する。

（Ｓ４１５）属性管理部１３８ｂは、未通知メッセージが示すイベントに対して第１情報処理装置１１０がアクションを実行していないか、成功していないと判断する。Ｓ４１５の動作を終えると、属性管理部１３８ｂは、未通知履歴情報に基づいて成功履歴の有無を判断する動作を終了する。その後、属性管理部１３８ｂは、その未通知メッセージが示すイベントに対するアクションを実行する。

以上、第２の実施の形態に係る一変形例（変形例＃３）について説明した。変形例＃３によれば、未通知履歴データベース１１６ａに最新の成功履歴情報のみを格納することで、未通知履歴データベース１１６ａに格納されるデータ量を低減することができる。さらに、未通知履歴情報を第２情報処理装置１３０に送信する際、送信されるデータ量が少なくて済むため、通信負荷を低減することが可能になる。

以上、第２の実施の形態及びその変形例について説明した。なお、上記説明においては、アクションの実行が失敗した場合に、アクションを実行した一方の装置が同じアクションを再実行することとしていたが、他方の装置が実行することとしてもよい。例えば、アクションの実行失敗を示す終了通知を受信した従系の装置が、その受信に応じて同じアクションを実行し、一方で主系の装置はアクションの実行を抑止するようにしてもよい。このような変形についても第２の実施の形態の技術的範囲に属する。

１０、１００ 情報処理システム
１１ データ
１２、１１０ 第１情報処理装置
１３ 演算部
１４ 通信部
１５ 履歴情報
１６、１３０ 第２情報処理装置
１７ 記憶部
１８、１１８、１３８ 制御部
１１１、１３１ 第１通信部
１１２、１３２ イベント監視部
１１３、１３３ 第２通信部
１１４、１３４ アクション実行部
１１５、１３５ 第１記憶部
１１５ａ、１３５ａ 他装置履歴データベース
１１６ａ、１３６ａ 未通知履歴データベース
１１６、１３６ 第２記憶部
１１７、１３７ 第３記憶部
２１０、２２０ 被監視装置
２１１ 記憶部
２１２ 演算処理部
２１３ イベント監視部
２１４ 通信部
３００ 端末装置

本発明は、情報処理装置、制御方法、プログラム、及び情報処理システムに関する。

また、例えば、データベースを備えた稼働系のサーバ計算機と、稼働系と同じ内容のデータベースを備えた待機系のサーバ計算機とを含む、複数サーバ計算機システムが提案されている。この複数サーバ計算機システムでは、端末計算機が稼働系と待機系の両方のサーバ計算機に対してデータベースの更新依頼を送信し、両方のサーバ計算機がそれぞれデータベースを更新する。更新依頼に対するレスポンスは、稼働系と待機系のサーバ計算機のうち稼働系のサーバ計算機のみが端末計算機に対して送信する。

そこで、１つの側面では、本発明は、アクションを実行する情報処理装置の切り替えを円滑に行うことができる情報処理装置、制御方法、プログラム、及び情報処理システムを提供することを目的とする。

１つの側面では、自装置とは異なる他の情報処理装置に入力されたメッセージについて他の情報処理装置が実行する当該メッセージに対応する処理の状況を示す通知情報を受信する通信部と、通信部が受信した通知情報を記憶する記憶部と、メッセージが入力されたとき、当該メッセージの入力から設定した時間だけ経過した後で、当該メッセージに対応する処理の状況を示す通知情報が記憶部に記憶されているか否かを判定し、当該通知情報が記憶部に記憶されている場合に当該メッセージに対応する処理の実行を抑止する制御部と、を有する、情報処理装置が提供される。

（２−１）第１情報処理装置１１０が正常動作している場合
イベント監視部１１２からメッセージが入力された場合、属性管理部１１８ｂは、メッセージの入力から所定の時間だけ待機する。第２通信部１１３を介して開始通知を受信した場合、履歴更新部１１８ａは、他装置履歴データベース１１５ａに第１実行履歴情報を格納する。このとき、履歴更新部１１８ａは、状態情報を「実行中」にする。また、第２通信部１１３を介して終了通知を受信した場合、履歴更新部１１８ａは、状態情報を「実行済」に更新し、その状態情報に実行結果（成功又は失敗）を付与する。

但し、第２情報処理装置１３０が開始通知を受信できなかった場合、属性管理部１１８ｂは、未通知履歴データベース１１６ａにイベント発生日時、発生元装置名、アクション種別、及び状態情報（第１未通知履歴情報）を格納する。この場合、属性管理部１１８ｂは、アクション実行部１１４によるアクションの実行が終了しても終了通知を第２情報処理装置１３０に送信しない。

第１情報処理装置１１０は、アクションの実行を開始し、開始通知を第２情報処理装置１３０に送信する。この開始通知を受信した第２情報処理装置１３０は、他装置履歴データベース１３５ａに第１実行履歴情報を格納する。そして、第２情報処理装置１３０は、状態情報を「実行中」に設定し、さらに待機する。

（Ｓ３２９）属性管理部１１８ｂは、次に実行するアクションを第１情報処理装置１１０で実行する。つまり、属性管理部１１８ｂは、図１５に示したフロー図におけるＳ１２６の動作に移る。Ｓ３２９の動作を終えると、アクション切り替え判定についての処理が終了する。

Claims (8)

1. 同じデータを取得する第１及び第２の情報処理装置を含む情報処理システムであって、
   前記第１の情報処理装置は、
   データの取得に応じてアクションを実行する演算部と、
   前記アクションが正常に完了した場合に、前記アクションによって処理されたデータを示す履歴情報を前記第２の情報処理装置に送信する通信部と、を有し、
   前記第２の情報処理装置は、
   前記第１の情報処理装置から受信された前記履歴情報を記憶する記憶部と、
   データを取得したとき、前記記憶部の前記履歴情報の格納状況に基づいて、前記第２の情報処理装置が前記アクションの実行を抑止するか、前記第１の情報処理装置に代わって前記第２の情報処理装置が前記アクションを実行するかを決定する制御部と、を有する
   情報処理システム。
2. 前記演算部は、取得したデータに応じて複数の種類のアクションの１つを実行し、
   前記第２の情報処理装置は、前記複数の種類のアクションそれぞれについて当該アクションが過去に正常に完了したときの実行時間に関する統計情報を記憶し、
   前記制御部は、取得したデータに応じた種類のアクションを前記第２の情報処理装置が実行するか否か決定するとき、前記統計情報に基づいて、前記記憶部にアクセスして前記履歴情報の格納状況を確認する周期をアクションの種類によって変える
   請求項１に記載の情報処理システム。
3. 前記制御部は、データを取得してから所定時間経過しても、取得したデータに対応する履歴情報が前記記憶部に格納されていないとき、前記第１の情報処理装置に代わって前記第２の情報処理装置が前記アクションを実行すると決定する
   請求項１又は２に記載の情報処理システム。
4. 前記第１の情報処理装置は、前記アクションの実行によって生じる前記第１の情報処理装置の負荷の増加量に関する負荷情報を記憶し、
   前記演算部は、データを取得したとき、前記アクションを実行した場合の前記第１の情報処理装置の負荷を前記負荷情報に基づいて予測し、予測結果に応じて、前記アクションを実行するか前記第２の情報処理装置に前記アクションの実行を依頼するか決定する、
   請求項１乃至３のいずれか一項に記載の情報処理システム。
5. 前記第１の情報処理装置は、前記第２の情報処理装置に障害が発生している間に処理されたデータを示す他の履歴情報を記憶する他の記憶部をさらに有し、
   前記制御部は、前記第２の情報処理装置が復旧したとき、前記他の記憶部に記憶された前記他の履歴情報を参照して、前記第２の情報処理装置が取得しているデータについて前記アクションの実行を抑止するか前記アクションを実行するかを決定する
   請求項１乃至４のいずれか一項に記載の情報処理システム。
6. 前記第１及び第２の情報処理装置は、複数の電子機器が生成するデータを取得し、
   前記第１の情報処理装置は、前記複数の電子機器それぞれについて、前記第２の情報処理装置に障害が発生している間に処理された当該電子機器からのデータのうち最後のデータを示す他の履歴情報を記憶する他の記憶部をさらに有し、
   前記制御部は、前記第２の情報処理装置が復旧したとき、前記他の記憶部に記憶された前記他の履歴情報が示す各電子機器の前記最後のデータに基づいて、前記第２の情報処理装置が取得している前記複数の電子機器からのデータについて前記アクションの実行を抑止するか前記アクションを実行するかを決定する
   請求項１乃至４のいずれか一項に記載の情報処理システム。
7. 他の情報処理装置と同じデータを取得する情報処理装置であって、
   前記他の情報処理装置においてデータの取得に応じて実行されるアクションが正常に完了した場合に前記他の情報処理装置から受信される、前記アクションによって処理されたデータを示す履歴情報を記憶する記憶部と、
   データを取得したとき、前記記憶部の前記履歴情報の格納状況に基づいて、前記情報処理装置が前記アクションの実行を抑止するか、前記他の情報処理装置に代わって前記情報処理装置が前記アクションを実行するかを決定する制御部と
   を有する情報処理装置。
8. 他のコンピュータと同じデータを取得するコンピュータに、
   前記他のコンピュータにおいてデータの取得に応じて実行されるアクションが正常に完了した場合に、前記他のコンピュータから前記アクションによって処理されたデータを示す履歴情報を受信し、前記履歴情報を前記コンピュータが備える記憶部に格納し、
   データを取得したとき、前記記憶部の前記履歴情報の格納状況に基づいて、前記コンピュータが前記アクションの実行を抑止するか、前記他のコンピュータに代わって前記コンピュータが前記アクションを実行するかを決定する
   処理を実行させるプログラム。

Images