以下、図面を参照しながら実施の形態について説明する。
[第1の実施の形態]
第1の実施の形態について説明する。
図1は、第1の実施の形態に係る情報処理システムの例を示した図である。
情報処理システム10は、同じデータ11を取得する第1及び第2の情報処理装置12、16を含む。第1の情報処理装置12は、演算部13、及び通信部14を有する。第2の情報処理装置16は、記憶部17、及び制御部18を有する。
演算部13は、データ11の取得に応じてアクションを実行する。アクションの例としては、メール通知、音声通知、アプリケーションプログラムの実行、リモートコマンドの発行、SNMP(Simple Network Management Protocol)トラップの発行、ポップアップ表示などがある。
通信部14は、アクションが正常に完了した場合に、アクションによって処理されたデータを示す履歴情報15を第2の情報処理装置16に送信する。記憶部17は、第1の情報処理装置12から受信された履歴情報15を記憶する。例えば、記憶部17には、アクションの種類、アクションが実行済みであるか、実行中であるかを示す情報、或いは、実行済みの場合には成功又は失敗を示す情報などが格納される。
制御部18は、データ11を取得したとき、記憶部17の履歴情報15の格納状況に基づいて、第2の情報処理装置16がアクションの実行を抑止するか、第1の情報処理装置12に代わって第2の情報処理装置16がアクションを実行するかを決定する。例えば、制御部18は、データ11に対応する履歴情報15が記憶部17に格納されている場合にアクションの実行を抑止することを決定する。一方、データ11に対応する履歴情報15が記憶部17に格納されていない場合、制御部18は、第2の情報処理装置16がアクションを実行することを決定する。
以上、第1の実施の形態について説明した。
[第2の実施の形態]
第2の実施の形態について説明する。
(情報処理システムについて)
まず、第2の実施の形態に係る情報処理システムについて説明する。図2は、第2の実施の形態に係る情報処理システムの例を示した図である。
図2に示すように、第2の実施の形態に係る情報処理システム100は、互いに接続された第1情報処理装置110及び第2情報処理装置130を含む。第1情報処理装置110及び第2情報処理装置130は、ネットワーク94を介して被監視装置210、220及び端末装置300に接続されている。なお、図2の例では、監視対象となる装置の一例として2台の被監視装置210、220を明示しているが、監視対象となる装置の数は1台であってもよいし、3台以上であってもよい。
(被監視装置210、220)
被監視装置210でイベントが発生した場合、被監視装置210は、第1情報処理装置110及び第2情報処理装置130に対してイベントの種類及びその内容を含むメッセージを送信する。このとき、被監視装置210は、イベント発生日時及び発生したイベントを個々に識別するためのイベントIDをさらにメッセージに含めて第1情報処理装置110及び第2情報処理装置130に送信する。イベントIDは、例えば、イベントの発生順に個々の被監視装置によりイベント毎に付与される番号である。
イベントの種類は、被監視装置210の種類や被監視装置210で動作するソフトウェアの種類などに依存する。例えば、被監視装置210がアプリケーションサーバの場合、被監視装置210で実行中のアプリケーションソフトウェアによる警告やエラーの出力などがイベントとなる。被監視装置210がジョブサーバの場合、ジョブの実行失敗やジョブの実行完了などがイベントとなる。その他にも、ネットワークの切断やメモリへのデータ書き込みエラーなどがイベントとなる。
なお、被監視装置210は、イベントの発生時だけでなく、イベントログから抽出した情報をメッセージとして定期的に第1情報処理装置110及び第2情報処理装置130へ送信してもよい。例えば、被監視装置210は、オペレーティングシステムの稼働状況を記録するシステムログ、アプリケーションソフトウェアの稼働状況を記録するアプリケーションログ、ログオンの結果などを記録するセキュリティログの情報を送信してもよい。
上記のように、被監視装置210は、イベントが発生した場合に、そのイベントに関するメッセージを第1情報処理装置110及び第2情報処理装置130に送信する。但し、第1情報処理装置110又は第2情報処理装置130でメッセージが正常に受信されなかった場合、被監視装置210は、そのメッセージを未通知メッセージとして保持する。
例えば、何らかのトラブルにより第1情報処理装置110が停止している場合、被監視装置210がメッセージを送信しても、第1情報処理装置110から受信完了を示す確認応答が得られない。この場合、被監視装置210は、第1情報処理装置110により正常に受信されなかったメッセージを第1情報処理装置110に対する未通知メッセージとして保持する。なお、被監視装置220についても同様である。
(第1情報処理装置110、第2情報処理装置130)
被監視装置210、220から送信されたメッセージを受信した場合、第1情報処理装置110又は第2情報処理装置130は、受信したメッセージの種類に対応するアクションを実行する。アクションの例としては、メール通知、音声通知、アプリケーションプログラムの実行、リモートコマンドの発行、SNMPトラップの発行、ポップアップ表示などがある。これらのアクション種別は、イベントの種別に対応付けられている。例えば、Disk Errorに対してメール通知、Application Warningに対して音声通知、Application Errorに対してメール通知及び音声通知が対応付けられている。
メール通知は、電子メールを用いて端末装置300を利用するユーザにイベントの発生及びその内容を通知するアクションである。音声通知は、イベントの発生及びその内容を音声で通知するための音声データを端末装置300に送信してユーザに音声で情報を通知するアクションである。ポップアップ表示は、イベントの発生及びその内容を記載したポップアップウィンドウを端末装置300の画面上に表示させるアクションである。その他のアクションも、端末装置300を利用するユーザにイベントの発生及びその内容の通知、或いは、イベントへの対処方法や対処結果などを通知するものである。
1つのメッセージに対するアクションは、第1情報処理装置110又は第2情報処理装置130のいずれかで実行される。第1情報処理装置110及び第2情報処理装置130には、それぞれ、メッセージに対するアクションを優先的に実行する「主系」又はアクションを優先的には実行せず待機する「従系」という属性が設定される。第1情報処理装置110が「主系」であり、第2情報処理装置130が「従系」である場合、第1情報処理装置110がメッセージに対するアクションを主に実行する。
但し、何らかのトラブルが生じて第1情報処理装置110が停止している場合、第2情報処理装置130がメッセージに対するアクションを実行する。さらに、第2情報処理装置130は、自身の属性を「従系」から「主系」に切り替える。その後、第1情報処理装置110が復旧した場合、第1情報処理装置110は、自身の属性を「主系」から「従系」に切り替え、「従系」として動作する。このように、第1情報処理装置110及び第2情報処理装置130は、互いに状態を監視し、相手の状態に応じて自身の属性を切り替える。
以上、第2の実施の形態に係る情報処理システムの例について説明した。なお、図2の例では、第1情報処理装置110と第2情報処理装置130とが直接接続されているが、両者がネットワーク94を介する経路のみで接続されていてもよい。但し、以下では、第1情報処理装置110と第2情報処理装置130とが直接接続されているものとして説明を進める。
(第1情報処理装置のハードウェアについて)
次に、第2の実施の形態に係る第1情報処理装置のハードウェアの例について説明する。図3は、第2の実施の形態に係る第1情報処理装置のハードウェアの例を示した図である。
図3に示すように、第1情報処理装置110は、例えば、CPU(Central Processing Unit)901、RAM(Random Access Memory)902、HDD(Hard Disk Drive)903、画像信号処理部904、入力信号処理部905、ディスクドライブ906、及び通信インターフェース907a、907bを有する。
CPU901は、プログラムに記述された命令を実行する演算器を含むプロセッサである。CPU901は、HDD903に記憶されているプログラムやデータの少なくとも一部をRAM902にロードし、プログラムに記述された命令を実行する。なお、CPU901は、複数のプロセッサコアを含んでいてもよい。また、第1情報処理装置110は、複数のCPU901を搭載していてもよい。この場合、第1情報処理装置110は、処理を並列実行することができる。
RAM902は、CPU901が実行するプログラムや、処理に用いられるデータを一時的に記憶するための揮発性メモリである。なお、第1情報処理装置110は、RAM902とは異なる種類のメモリを有していてもよい。また、第1情報処理装置110は、複数のメモリを備えていてもよい。
HDD903は、Operating System(OS)、ファームウェア、或いは、アプリケーションソフトウェアなどのプログラムや、処理に用いられるデータなどを記憶する不揮発性記憶装置の一例である。なお、第1情報処理装置110は、フラッシュメモリやSolid State Drive(SSD)など、HDD903とは異なる種類の記憶装置を有していてもよい。また、第1情報処理装置110は、複数の記憶装置を有していてもよい。
画像信号処理部904は、CPU901による制御を受け、第1情報処理装置110に接続された表示装置91に画像を出力する。表示装置91は、例えば、Cathode Ray Tube(CRT)ディスプレイ、Liquid Crystal Display(LCD)、Plasma Display Panel(PDP)、Organic Electro-Luminescence Display(OELD)などの表示デバイスである。
入力信号処理部905は、第1情報処理装置110に接続された入力デバイス92から入力信号を取得し、CPU901に通知する。入力デバイス92としては、例えば、マウス、キーボード、タッチパネル、タッチパッド、トラックボール、リモートコントローラ、ボタンスイッチなどを用いることができる。
ディスクドライブ906は、記録媒体93に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体93としては、例えば、Flexible Disk(FD)、HDDなどの磁気ディスク、Compact Disc(CD)やDigital Versatile Disc(DVD)などの光ディスク、Magneto-Optical disk(MO)などの光磁気ディスクを用いることができる。ディスクドライブ906は、例えば、CPU901による制御を受け、記録媒体93から読み取ったプログラムやデータをRAM902又はHDD903に格納する。
通信インターフェース907aは、ネットワーク94を介して他のコンピュータと通信を行うためのインターフェースである。通信インターフェース907bは、第2情報処理装置130との間で通信を行うためのインターフェースである。通信インターフェース907a、907bは、有線インターフェースであってもよいし、無線インターフェースであってもよい。
以上、第2の実施の形態に係る第1情報処理装置のハードウェアの例について説明した。なお、第2情報処理装置130の機能、被監視装置210、220の機能、及び端末装置300の機能は、第1情報処理装置110と同じハードウェアを用いて実現できる。但し、被監視装置210、220、及び端末装置300の場合、通信インターフェース907bが省略される。
(第1情報処理装置の機能について)
次に、第2の実施の形態に係る第1情報処理装置の機能について説明する。図4は、第2の実施の形態に係る第1情報処理装置の機能を示したブロック図である。
図4に示すように、第1情報処理装置110は、第1通信部111と、イベント監視部112と、第2通信部113と、アクション実行部114と、第1記憶部115と、第2記憶部116と、第3記憶部117と、制御部118とを有する。
なお、イベント監視部112、アクション実行部114、及び制御部118は、CPU901が実行するプログラムのモジュールとして実現できる。但し、イベント監視部112、アクション実行部114、及び制御部118が有する機能の一部又は全部をソフトウェアではなく電子回路として実現することも可能である。
第1記憶部115、第2記憶部116、及び第3記憶部117は、RAM902やHDD903に確保された記憶領域である。第1通信部111の機能は、通信インターフェース907aを用いて実現することができる。第2通信部113の機能は、通信インターフェース907bを用いて実現することができる。
(第1通信部111)
第1通信部111は、ネットワーク94を介して被監視装置210、220及び端末装置300と通信するための通信手段である。例えば、第1通信部111は、被監視装置210が送信したメッセージを受信する。そして、第1通信部111は、受信したメッセージをイベント監視部112に入力する。また、第1通信部111は、アクションの実行に関する情報を端末装置300に送信する際に利用される。例えば、第1通信部111は、電子メールのデータや音声データなどを端末装置300に送信する際に利用される。
(イベント監視部112)
イベント監視部112は、第1通信部111から入力されたメッセージのうち、アクションの実行を要するイベントに対応するメッセージを抽出する。なお、アクションとイベントの種類との対応関係は予め設定されているものとする。また、イベント監視部112は、アクションとイベントの種類との対応関係を示す情報(以下、フィルタリング情報)を参照できるものとする。イベント監視部112は、メッセージからイベントの種類を示す情報を抽出し、フィルタリング情報と照合してアクションの実行を要するイベントに対応するメッセージを抽出する。イベント監視部112により抽出されたメッセージは、制御部118に入力される。
(第2通信部113)
第2通信部113は、第2情報処理装置130と直接通信するための通信手段である。例えば、第2通信部113は、第1情報処理装置110によるアクションの実行状況(実行開始、実行終了)や実行結果(成功、失敗)などの情報を第2情報処理装置130に対して送信する際に利用される。また、第2通信部113は、第1情報処理装置110の属性(「主系」又は「従系」)を示す情報(以下、属性情報)を第2情報処理装置130に対して送信する際に利用される。また、第2通信部113は、第2情報処理装置130からアクションの実行状況や実行結果などの情報、或いは、属性情報を受信する際に利用される。
(アクション実行部114)
アクション実行部114は、後述する制御部118による制御を受けてアクションを実行する。例えば、メール通知を行う場合、アクション実行部114は、第1通信部111を利用して端末装置300に電子メールのデータを送信する。音声通知を行う場合、アクション実行部114は、第1通信部111を利用して端末装置300に音声データを送信する。その他にも、アクション実行部114は、アプリケーションプログラムの実行、リモートコマンドの発行、SNMPトラップの発行、及びポップアップ表示などのアクションを実行する。
(第1記憶部115)
第1記憶部115は、他装置履歴データベース115aを格納している。他装置履歴データベース115aには、第2情報処理装置130が実行したアクションの実行履歴に関する情報(以下、第2実行履歴情報)が格納される。例えば、他装置履歴データベース115aには、アクションに対応するイベントのイベント発生日時、イベントID、イベントが発生した装置の装置名(以下、発生元装置名)、アクションの種類(以下、アクション種別)、及び実行状態を示す情報(以下、状態情報)が対応付けて格納される。状態情報は、例えば、アクションが実行済みであるか、実行中であるかを示す情報、及び、実行済みの場合には成功又は失敗を示す情報を含む。
(第2記憶部116)
第2記憶部116は、未通知履歴データベース116aを格納している。未通知履歴データベース116aには、アクション実行部114が実行したアクションの実行履歴に関する情報(以下、第1実行履歴情報)のうち、第2情報処理装置130に通知できなかった情報(以下、第1未通知履歴情報)が格納される。例えば、未通知履歴データベース116aには、アクションに対応するイベントのイベント発生日時、イベントID、発生元装置名、アクション種別、及び状態情報が対応付けて格納される。
(第3記憶部117)
第3記憶部117には、第1情報処理装置110の属性情報、フィルタリング情報、被監視装置210、220や端末装置300を特定するための情報(例えば、ホスト名やIPアドレスなど)、及びアプリケーションプログラムなどが格納される。さらに、第3記憶部117には、第2実行履歴情報のうち、第1情報処理装置110に通知できずに第2情報処理装置130が保持していた情報(以下、第2未通知履歴情報)が格納される。
(制御部118)
制御部118は、履歴更新部118a、及び属性管理部118bを含む。履歴更新部118aは、第2通信部113を介して第2情報処理装置130から第2実行履歴情報を受信した場合、受信した第2実行履歴情報を第1記憶部115の他装置履歴データベース115aに格納する。
属性管理部118bは、イベント監視部112からメッセージが入力された場合、第1情報処理装置110の属性を確認する。また、属性管理部118bは、第1情報処理装置110及び第2情報処理装置130の状態に応じて属性情報を更新する。さらに、属性管理部118bは、第2情報処理装置130に通知できなかった第1実行履歴情報が生じた場合、第1未通知履歴情報を第2記憶部116の未通知履歴データベース116aに格納する。
なお、第1情報処理装置110の属性が「主系」の場合、制御部118は、下記(1)のように機能する。一方、第1情報処理装置110の属性が「従系」の場合、制御部118は、下記(2)のように機能する。
(1)第1情報処理装置110が「主系」の場合
第1情報処理装置110が「主系」の場合における制御部118の機能について説明する。なお、以下では、第1情報処理装置110が正常動作している場合(復旧時ではない場合)と、何らかの事情により動作停止など(以下、単に障害と言う。)が発生した状態から復旧した場合(復旧時)とに分けて説明する。
(1−1)第1情報処理装置110が正常動作している場合
属性管理部118bは、イベント監視部112から入力されたメッセージと同じメッセージに対応する情報(イベントID及び発生元装置名)が他装置履歴データベース115aに格納されているか否かを確認する。つまり、属性管理部118bは、同じメッセージに対応するアクションが既に第2情報処理装置130で実行されたか否かを確認する。
第1情報処理装置110が「主系」として正常動作している場合、通常、他装置履歴データベース115aには同じメッセージに対応する情報が格納されていないため、属性管理部118bは、アクションを実行させる動作に移る。但し、後述する変形例のように、「主系」が実行すべき一部のアクションを「従系」が実行する場合、他装置履歴データベース115aには同じメッセージに対応する情報が格納されることがある。こうした変形例については後述する。
属性管理部118bは、フィルタリング情報を参照し、イベント監視部112から入力されたメッセージが示すイベント種別に対応するアクションをアクション実行部114に実行させる。アクション実行部114にアクションの実行を開始させる際、属性管理部118bは、第2通信部113を利用してアクションの実行開始を示す情報(以下、開始通知)を第2情報処理装置130に送信する。さらに、アクション実行部114によるアクションの実行が終了した際、属性管理部118bは、第2通信部113を利用してアクションの実行終了及びその成否を示す情報(以下、終了通知)を第2情報処理装置130に送信する。
但し、第2情報処理装置130が開始通知を受信できなかった場合、属性管理部118bは、未通知履歴データベース116aにイベント発生日時、発生元装置名、アクション種別、及び状態情報(第1未通知履歴情報)を格納する。例えば、開始通知の送信に対するACK(ACKnowledgement)が第2情報処理装置130から得られない場合、属性管理部118bは、未通知履歴データベース116aに第1未通知履歴情報を格納する。この場合、属性管理部118bは、アクション実行部114によるアクションの実行が終了しても終了通知を第2情報処理装置130に送信しない。
なお、属性管理部118bは、アクションの実行開始から実行終了までの間、未通知履歴データベース116aに格納する状態情報を「実行中」とする。アクションの実行が終了した際、属性管理部118bは、未通知履歴データベース116aに格納した状態情報を「実行済」に更新する。さらに、属性管理部118bは、アクションの実行結果(成功、失敗)を状態情報に付加する。なお、アクションの実行が失敗した場合、属性管理部118bは、同じアクションをアクション実行部114に再び実行させる。
1つのアクションの実行が終了した後、属性管理部118bは、フィルタリング情報を参照し、同じイベント種別に対応する他のアクションが存在するか否かを確認する。同じイベント種別に他のアクションが対応付けられている場合、属性管理部118bは、他のアクションをアクション実行部114に実行させる。この場合、属性管理部118bは、他のアクションの実行開始を通知する開始通知を第2情報処理装置130に送信しない。そして、属性管理部118bは、未通知履歴データベース116aに第1未通知履歴情報を格納する。さらに、他のアクションの実行が終了した場合も、属性管理部118bは、終了通知を第2情報処理装置130に送信しない。そして、属性管理部118bは、未通知履歴データベース116aの状態情報を更新する。
(1−2)第1情報処理装置110の復旧時
第1情報処理装置110が「主系」の場合に、第1情報処理装置110で障害が発生すると、第2情報処理装置130が「主系」となってアクションを実行する場合がある。この場合、制御部118は、第1情報処理装置110の復旧時に次のような処理を実行する。なお、制御部118は、例えば、電源の投入、オペレーティングシステムやアプリケーションソフトウェアの起動、ネットワーク機能の回復、或いは、ユーザ(端末装置300)による明示的な通知を検知することで復旧時であると判断できる。
復旧時であると判断した場合、属性管理部118bは、第2通信部113を利用して、第2情報処理装置130が保持する属性情報及び第2未通知履歴情報を第2情報処理装置130に要求する。そして、属性管理部118bは、第2通信部113を利用して、第2情報処理装置130から送信された属性情報及び第2未通知履歴情報を受信する。属性管理部118bは、受信した第2未通知履歴情報を第3記憶部117に格納する。また、属性管理部118bは、受信した属性情報を参照して第2情報処理装置130の属性を確認する。
障害の発生時から復旧時までの間に第1情報処理装置110及び第2情報処理装置130へメッセージが送信され、第2情報処理装置130の属性が「主系」へと変更されている場合、属性管理部118bは、第3記憶部117に格納された属性情報を更新する。つまり、属性管理部118bは、第1情報処理装置110の属性を「主系」から「従系」へと変更する。なお、障害の発生時から復旧時までの間に第1情報処理装置110及び第2情報処理装置130へメッセージが送信されず、第2情報処理装置130の属性が変更されていない場合、属性管理部118bは、属性を変更せずに動作を再開する。
障害の発生時から復旧時までの間に被監視装置210から第1情報処理装置110へメッセージが送信された場合、第1情報処理装置110により正常に受信されなかったメッセージは、未通知メッセージとして被監視装置210により保持される。被監視装置210は、定期的に第1情報処理装置110の状態を確認し、第1情報処理装置110の復旧時に、保持していた未通知メッセージを再送する。属性管理部118bは、被監視装置210から送信された未通知メッセージを第1通信部111及びイベント監視部112を介して受信し、未通知メッセージの処理を実行する。
属性管理部118bは、未通知メッセージが示すイベントと同じイベントの情報(イベントID及び発生元装置名)が第3記憶部117に格納した第2未通知履歴情報に含まれているか否かを確認する。つまり、属性管理部118bは、同じイベントに対するアクションが既に第2情報処理装置130で実行されたか否かを確認する。
受信した未通知メッセージが示すイベントと同じイベントの情報が第2未通知履歴情報に含まれている場合、属性管理部118bは、その未通知メッセージが示すイベントに対応するアクションの実行を抑止する(そのアクションを実行しないことにする。)。一方、受信した未通知メッセージが示すイベントと同じイベントの情報が第2未通知履歴情報に含まれていない場合、属性管理部118bは、その未通知メッセージが示すイベントに対応するアクションをアクション実行部114に実行させる。
未通知メッセージが複数存在する場合、属性管理部118bは、被監視装置210から順次未通知メッセージを受信し、受信した未通知メッセージが示すイベントと同じイベントの情報が第2未通知履歴情報に含まれているか否かを確認する。そして、属性管理部118bは、上記と同様に、確認結果に応じて未通知メッセージを処理(アクションの実行又は抑止)する。全ての未通知メッセージに対して処理が完了すると、制御部118は、下記(2)に示す第1情報処理装置110が「従系」の場合の動作に移る。
(2)第1情報処理装置110が「従系」の場合
第1情報処理装置110が「従系」の場合における制御部118の機能について説明する。なお、以下では、第1情報処理装置110が正常動作している場合(復旧時ではない場合)と、何らかの事情により障害が発生した状態から復旧した場合(復旧時)とに分けて説明する。
(2−1)第1情報処理装置110が正常動作している場合
イベント監視部112からメッセージが入力された場合、属性管理部118bは、メッセージの入力から所定の時間だけ待機する。第2通信部113を介して開始通知を受信した場合、履歴更新部118aは、他装置履歴データベース115aに第1実行履歴情報を格納する。このとき、履歴更新部118aは、状態情報を「実行中」にする。また、第2通信部113を介して終了通知を受信した場合、履歴更新部118aは、状態情報を「実行済」に更新し、その状態情報に実行結果(成功又は失敗)を付与する。
属性管理部118bは、他装置履歴データベース115aを参照し、メッセージの入力から所定の時間が経過するまでに、アクションの実行が成功していることが確認できた場合、そのメッセージに対応するアクションの実行を抑止する。なお、所定の時間は、予め設定されていてもよいし、後述する変形例のように所定のタイミングで更新されるようにしてもよい。また、所定の時間は、アクション種別毎に設定されていてもよい。
一方、メッセージの入力から所定の時間が経過するまでに、アクションの実行が成功したことを確認できない場合、属性管理部118bは、そのアクションをアクション実行部114に実行させる。この場合、属性管理部118bは、第2通信部113を利用して、アクションの実行開始時及び実行終了時にそれぞれ開始通知及び終了通知を第2情報処理装置130へと送信する。さらに、属性管理部118bは、第3記憶部117に格納された属性情報を変更する。つまり、属性管理部118bは、第1情報処理装置110の属性を「従系」から「主系」に変更する。
但し、第2情報処理装置130が開始通知を受信できなかった場合、属性管理部118bは、未通知履歴データベース116aにイベント発生日時、発生元装置名、アクション種別、及び状態情報(第1未通知履歴情報)を格納する。この場合、属性管理部118bは、アクション実行部114によるアクションの実行が終了しても終了通知を第2情報処理装置130に送信しない。
なお、属性管理部118bは、アクションの実行開始から実行終了までの間、未通知履歴データベース116aに格納する状態情報を「実行中」とする。アクションの実行が終了した際、属性管理部118bは、未通知履歴データベース116aに格納した状態情報を「実行済」に更新する。さらに、属性管理部118bは、アクションの実行結果(成功、失敗)を状態情報に付加する。なお、アクションの実行が失敗した場合、属性管理部118bは、同じアクションをアクション実行部114に再び実行させる。
1つのアクションの実行が終了した後、属性管理部118bは、フィルタリング情報を参照し、同じイベント種別に対応する他のアクションが存在するか否かを確認する。同じイベント種別に他のアクションが対応付けられている場合、属性管理部118bは、他のアクションをアクション実行部114に実行させる。この場合、属性管理部118bは、他のアクションの実行開始を通知する開始通知を第2情報処理装置130に送信しない。そして、属性管理部118bは、未通知履歴データベース116aに第1未通知履歴情報を格納する。他のアクションの実行が終了した場合、属性管理部118bは、終了通知を第2情報処理装置130に送信しない。そして、属性管理部118bは、未通知履歴データベース116aの状態情報を更新する。
(2−2)第1情報処理装置110の復旧時
第1情報処理装置110が「従系」の場合、第1情報処理装置110で障害が発生しても、第2情報処理装置130が「主系」としてアクションの実行を継続する。従って、第2情報処理装置130の属性は変更されない。
第1情報処理装置110が復旧した場合、属性管理部118bは、第2通信部113を利用して、第2情報処理装置130が保持する第2未通知履歴情報を第2情報処理装置130に要求する。そして、属性管理部118bは、第2通信部113を利用して、第2情報処理装置130から送信された第2未通知履歴情報を受信する。属性管理部118bは、第2情報処理装置130から受信した第2未通知履歴情報を第3記憶部117に格納する。
障害の発生時から復旧時までの間に被監視装置210から第1情報処理装置110へメッセージが送信された場合、第1情報処理装置110により正常に受信されなかったメッセージは、未通知メッセージとして被監視装置210により保持される。第1情報処理装置110の復旧時に、属性管理部118bは、被監視装置210から送信された未通知メッセージを第1通信部111及びイベント監視部112を介して受信し、未通知メッセージの処理を実行する。
属性管理部118bは、未通知メッセージが示すイベントと同じイベントの情報(イベントID及び発生元装置名)が第3記憶部117に格納した第2未通知履歴情報に含まれているか否かを確認する。つまり、属性管理部118bは、同じイベントに対するアクションが既に第2情報処理装置130で実行されたか否かを確認する。
通常、受信した未通知メッセージが示すイベントと同じイベントの情報が第2未通知履歴情報に含まれているため、属性管理部118bは、その未通知メッセージに対応するアクションの実行を抑止する。しかし、受信した未通知メッセージが示すイベントと同じイベントの情報が第2未通知履歴情報に含まれていない場合、属性管理部118bは、そのイベントに対するアクションをアクション実行部114に実行させる。
複数の未通知メッセージが存在する場合、属性管理部118bは、被監視装置210から順次未通知メッセージを受信し、受信した未通知メッセージが示すイベントと同じイベントの情報が第2未通知履歴情報に含まれているか否かを確認する。そして、属性管理部118bは、上記と同様に、確認結果に応じて未通知メッセージを処理(アクションの実行又は抑止)する。全ての未通知メッセージに対する処理が完了すると、制御部118は、上記(2−1)に示す第1情報処理装置110が正常動作している場合の動作に移る。
以上、第2の実施の形態に係る第1情報処理装置の機能について説明した。
(第2情報処理装置の機能について)
次に、第2の実施の形態に係る第2情報処理装置の機能について説明する。図5は、第2の実施の形態に係る第2情報処理装置の機能を示したブロック図である。
図5に示すように、第2情報処理装置130は、第1通信部131と、イベント監視部132と、第2通信部133と、アクション実行部134と、第1記憶部135と、第2記憶部136と、第3記憶部137と、制御部138とを有する。
なお、イベント監視部132、アクション実行部134、及び制御部138は、CPU901が実行するプログラムのモジュールとして実現できる。但し、イベント監視部132、アクション実行部134、及び制御部138が有する機能の一部又は全部をソフトウェアではなく電子回路として実現することも可能である。
第1記憶部135、第2記憶部136、及び第3記憶部137は、RAM902やHDD903に確保された記憶領域である。第1通信部131の機能は、通信インターフェース907aを用いて実現することができる。第2通信部133の機能は、通信インターフェース907bを用いて実現することができる。
図5に示した第2情報処理装置130の機能は、図4に示した第1情報処理装置110の機能と同じである。上述した第1通信部111、イベント監視部112、第2通信部113、及びアクション実行部114の機能が、それぞれ第1通信部131、イベント監視部132、第2通信部133、及びアクション実行部134の機能に対応する。
さらに、上述した第1記憶部115、第2記憶部116、第3記憶部117、及び制御部118の機能が、それぞれ第1記憶部135、第2記憶部136、第3記憶部137、及び制御部138の機能に対応する。従って、第2情報処理装置130の機能については詳細な説明を省略する。
以上、第2の実施の形態に係る第2情報処理装置の機能について説明した。
(被監視装置の機能について)
次に、第2の実施の形態に係る被監視装置の機能について説明する。図6は、第2の実施の形態に係る被監視装置の機能を示したブロック図である。なお、ここでは一例として被監視装置210の機能について説明するが、被監視装置220など、情報処理システム100が監視する他の被監視装置についても同様である。
図6に示すように、被監視装置210は、記憶部211と、演算処理部212と、イベント監視部213と、通信部214とを有する。
なお、記憶部211は、RAM902やHDD903に確保された記憶領域である。演算処理部212及びイベント監視部213は、CPU901が実行するプログラムのモジュールとして実現できる。但し、演算処理部212及びイベント監視部213が有する機能の一部又は全部をソフトウェアではなく電子回路として実現することも可能である。通信部214の機能は、通信インターフェース907aを用いて実現することができる。
記憶部211には、各種のイベントログが格納される。さらに、記憶部211には、第1情報処理装置110又は第2情報処理装置130により正常に受信されなかったメッセージ(未通知メッセージ)が格納される。なお、記憶部211は、任意のデータ書き込みに失敗した場合、書き込みエラーをイベント監視部213に通知する。
演算処理部212は、オペレーティングシステムやアプリケーションソフトウェアなどの動作に関する処理を実行する。さらに、演算処理部212は、オペレーティングシステムの稼働状況を記録するシステムログ、アプリケーションソフトウェアの稼働状況を記録するアプリケーションログ、ログオンの結果などを記録するセキュリティログの情報を記憶部211に格納する。また、演算処理部212は、処理の実行中に発生したエラーをイベント監視部213に通知する。
通信部214は、ネットワーク94に接続された機器と通信する通信手段である。例えば、通信部214は、ネットワーク94を介して第1情報処理装置110及び第2情報処理装置130にメッセージを送信する。また、通信部214は、ネットワークの切断や大量のパケットロスなどが発生した場合にエラーなどをイベント監視部213に通知する。
イベント監視部213は、記憶部211、演算処理部212、及び通信部214で検出されるエラーなどのイベントを監視し、イベントの発生に応じて第1情報処理装置110及び第2情報処理装置130にメッセージを送信する。このとき、イベント監視部213は、イベント発生日時及びイベントIDをメッセージに含めて送信する。なお、イベント監視部213は、記憶部211に格納されたイベントログを定期的に読み出して第1情報処理装置110及び第2情報処理装置130に送信してもよい。
また、第1情報処理装置110又は第2情報処理装置130が正常にメッセージを受信できなかった場合(例えば、ACKが返ってこない場合)、イベント監視部213は、そのメッセージを未通知メッセージとして記憶部211に格納する。このとき、イベント監視部213は、メッセージを受信できなかった第1情報処理装置110又は第2情報処理装置130を識別する情報と共に未通知メッセージを記憶部211に格納する。
また、第1情報処理装置110又は第2情報処理装置130の復旧状況を定期的に監視し、イベント監視部213は、復旧した第1情報処理装置110又は第2情報処理装置130に対して記憶部211に格納された未通知メッセージを送信する。
以上、第2の実施の形態に係る被監視装置の機能について説明した。
(装置の動作及びデータベースの内容について)
次に、第1情報処理装置110及び第2情報処理装置130の動作、及び第1情報処理装置110及び第2情報処理装置130が保持するデータベースの内容について、さらに説明する。なお、以下の説明において、障害が発生している状態を「異常」、障害から復旧して間もない状態を「復旧」、継続して障害が発生していないか、復旧後の処理を終えた状態を「正常」と表現する場合がある。
(「主系」及び「従系」が共に「正常」の場合)
図7は、第2の実施の形態に係る第1及び第2情報処理装置の動作について説明する第1の図である。図7の例は、第1情報処理装置110の属性が「主系」、第2情報処理装置130の属性が「従系」であり、「主系」及び「従系」が共に「正常」の場合の動作を示している。
図7に示すように、被監視装置210から第1情報処理装置110及び第2情報処理装置130にメッセージが送信されると、「主系」である第1情報処理装置110は、受信したメッセージが示すイベントに対してアクションを実行する。一方、「従系」である第2情報処理装置130は、メッセージの受信から所定の時間だけ待機する。
第1情報処理装置110は、アクションの実行を開始し、開始通知を第2情報処理装置130に送信する。この開始通知を受信した第2情報処理装置130は、他装置履歴データベース135aに第1実行履歴情報を格納する。そして、第2情報処理装置130は、状態情報を「実行中」に設定し、さらに待機する。
アクションの実行を終了した場合、第1情報処理装置110は、アクションの実行結果(成功、失敗)を含む終了通知を第2情報処理装置130に送信する。この終了通知を受信した第2情報処理装置130は、他装置履歴データベース135aの状態情報を「完了済」とし、その状態情報にアクションの実行結果(成功、失敗)を付加する。アクションの実行が失敗した場合、第1情報処理装置110は、アクションを再実行する。成功を示す終了通知を受信した第2情報処理装置130は、そのアクションの実行を抑止する。
被監視装置210から送信されるメッセージに応じて上記のような動作を繰り返すことにより、第2情報処理装置130の他装置履歴データベース135aには、図8に示すような情報が格納される。
図8は、第2の実施の形態に係る他装置履歴データベースの例を示した図である。なお、他装置履歴データベース115a、未通知履歴データベース116a、136aにも図8の例と同様の情報が格納される。図8に示すように、他装置履歴データベース135aには、イベント発生日時、イベントID、発生元装置名(図8の例では被監視装置210の装置名「host1」)、アクション種別、及び状態情報が対応付けて格納される。また、「実行済」を示す状態情報には実行結果(成功、失敗)が付加される。
(「主系」が「異常」、「従系」が「正常」の場合)
図9は、第2の実施の形態に係る第1及び第2情報処理装置の動作について説明する第2の図である。図9の例は、第1情報処理装置110の属性が「主系」、第2情報処理装置130の属性が「従系」であり、「主系」が「異常」であり、「従系」が「正常」である場合の動作を示している。
図9に示した状況では、被監視装置210から第1情報処理装置110及び第2情報処理装置130にメッセージが送信されても、「主系」である第1情報処理装置110は、メッセージの受信及びメッセージに対応するアクションの実行ができない。一方、「従系」である第2情報処理装置130は、メッセージの受信から所定の時間だけ待機する。
しかし、メッセージの受信から所定の時間が経過しても、第2情報処理装置130は、第1情報処理装置110からアクションの成功を示す終了通知を受信できない(図9の例では開始通知も受信できない。)。この場合、所定の時間が経過した後、第2情報処理装置130は、メッセージが示すイベントに対するアクションを実行し、属性を「従系」から「主系」へと変更する。
まず、第2情報処理装置130は、他装置履歴データベース135aを参照し、過去に同じイベントに対するアクションを第1情報処理装置110が実行して成功していないか確認する。同じイベントに対する第1実行履歴情報が他装置履歴データベース135aにない場合、第2情報処理装置130は、アクションの実行を開始し、開始通知を第1情報処理装置110に送信する。
なお、図9の例では第1情報処理装置110が開始通知を正常に受信できないため、第2情報処理装置130は、未通知履歴データベース136aに第2未通知履歴情報を格納する。このとき、第2情報処理装置130は、状態情報を「実行中」に設定する。
アクションの実行を終了した場合、第2情報処理装置130は、未通知履歴データベース136aの状態情報を「実行済」に更新し、その状態情報にアクションの実行結果(成功、失敗)を付加する。この場合、第2情報処理装置130は、終了通知を第1情報処理装置110に送信しない。アクションの実行が失敗した場合、第2情報処理装置130は、アクションを再実行する。この場合も、第2情報処理装置130は、第2未通知履歴情報を未通知履歴データベース136aに格納する。
(「旧主系」が「復旧」、「主系」が「正常」の場合)
図10は、第2の実施の形態に係る第1及び第2情報処理装置の動作について説明する第3の図である。図10の例は、図9に例示した状況で、第1情報処理装置110が復旧した場合の動作を示したものである。図9に例示した状況では、第2情報処理装置130が属性を「従系」から「主系」に変更したため、第1情報処理装置110及び第2情報処理装置130が共に「主系」の属性となっている。そこで、両者を区別するために復旧時における第1情報処理装置110の属性を「旧主系」と表現する。
第1情報処理装置110が復旧した場合、第1情報処理装置110は、第2情報処理装置130に対して第2未通知履歴情報及び属性情報の送信を要求する。第2情報処理装置130は、要求に応じて未通知履歴データベース136aに格納された第2未通知履歴情報、及び第3記憶部137に格納された属性情報を第1情報処理装置110に送信する。
第1情報処理装置110は、第2情報処理装置130から受信した第2未通知履歴情報を第3記憶部117に格納する。さらに、第1情報処理装置110は、第2情報処理装置130から受信した属性情報を参照して第2情報処理装置130の属性が「主系」であることを確認し、第3記憶部117に格納された自身の属性情報を「主系」から「従系」に変更する。
さらに、第1情報処理装置110は、被監視装置210に対して未通知メッセージの送信を要求する。この要求を受けた被監視装置210は、第1情報処理装置110に対して未通知メッセージを送信する。第1情報処理装置110は、第3記憶部117に格納した第2未通知履歴情報を参照して、未通知メッセージに対応するイベントと同じイベントに対するアクションを第2情報処理装置130が既に実行して成功しているかを確認する。
第1情報処理装置110は、未通知メッセージが示すイベントと同じイベントに対するアクションを第2情報処理装置130が既に実行して成功している場合、そのアクションの実行を抑止する。一方、未通知メッセージが示すイベントと同じイベントに対するアクションを第2情報処理装置130が実行していないか、成功していない場合、第1情報処理装置110は、そのアクションを実行する。
複数の未通知メッセージが存在する場合、第1情報処理装置110は、全ての未通知メッセージについて上記の処理(アクションの抑止又は実行)を行う。全ての未通知メッセージに対する処理を完了すると、第1情報処理装置110は、「従系」として動作する。一方、第2情報処理装置130は、そのまま「主系」として動作を継続する。つまり、第1情報処理装置110及び第2情報処理装置130は、それぞれ「主系」及び「従系」を入れ替えた形で図7に例示したような動作を行う。
(「主系」が正常、「従系」が「異常」の場合)
図11は、第2の実施の形態に係る第1及び第2情報処理装置の動作について説明する第4の図である。図11の例は、第1情報処理装置110の属性が「主系」、第2情報処理装置130の属性が「従系」であり、「主系」が「正常」であり、「従系」が「異常」である場合の動作を示している。
図11に示した状況の場合、被監視装置210から第1情報処理装置110及び第2情報処理装置130にメッセージが送信されると、「主系」である第1情報処理装置110は、正常にメッセージの受信及びメッセージに対応するアクションを実行できる。そのため、第1情報処理装置110は、受信したメッセージに対応するアクションを実行する。但し、第1情報処理装置110がアクションを実行開始する際に第2情報処理装置130へと送信する開始通知は、第2情報処理装置130により正常に受信されない。
そのため、第1情報処理装置110は、アクションの実行開始時に、未通知履歴データベース116aに第1未通知履歴情報を格納する。そして、第1情報処理装置110は、状態情報を「実行中」に設定する。アクションの実行を終了した場合、第1情報処理装置110は、未通知履歴データベース116aの状態情報を「実行済」に更新し、その状態情報にアクションの実行結果(成功、失敗)を付加する。このとき、第1情報処理装置110は、第2情報処理装置130に対して終了通知を送信しない。なお、アクションの実行が失敗した場合、第1情報処理装置110は、アクションを再実行する。この場合も、第1情報処理装置110は、第1未通知履歴情報を未通知履歴データベース116aに格納する。
(「主系」が正常、「従系」が「復旧」の場合)
図12は、第2の実施の形態に係る第1及び第2情報処理装置の動作について説明する第5の図である。図12の例は、図11に例示した状況で、第2情報処理装置130が復旧した場合の動作を示したものである。
第2情報処理装置130が復旧した場合、第2情報処理装置130は、第1情報処理装置110に対して第1未通知履歴情報の送信を要求する。第1情報処理装置110は、要求に応じて未通知履歴データベース116aに格納された第1未通知履歴情報を第2情報処理装置130に送信する。第2情報処理装置130は、第1情報処理装置110から受信した第1未通知履歴情報を第3記憶部137に格納する。
さらに、第2情報処理装置130は、被監視装置210に対して未通知メッセージの送信を要求する。この要求を受けた被監視装置210は、第2情報処理装置130に対して未通知メッセージを送信する。第2情報処理装置130は、第3記憶部137に格納した第1未通知履歴情報を参照して、未通知メッセージが示すイベントと同じイベントに対するアクションを第1情報処理装置110が既に実行して成功しているかを確認する。第2情報処理装置130は、第1情報処理装置110が既に実行して成功しているアクションの実行を抑止する。なお、第1情報処理装置110が成功していないアクションがある場合には、第2情報処理装置130が実行する。
複数の未通知メッセージが存在する場合、第2情報処理装置130は、全ての未通知メッセージについて上記と同様に順次処理を実行する。全ての未通知メッセージに対する処理を完了すると、第2情報処理装置130は、「従系」として動作を再開する。一方、第1情報処理装置110は、そのまま「主系」として動作を継続する。つまり、第1情報処理装置110及び第2情報処理装置130は、図7に例示した動作を再開する。
以上、第1情報処理装置110及び第2情報処理装置130の動作、及び第1情報処理装置110及び第2情報処理装置130が保持するデータベースの内容について、さらに説明した。
(他装置履歴データベースの更新方法について)
次に、第2の実施の形態に係る他装置履歴データベースの更新方法について、フロー図を参照しながら説明する。図13は、第2の実施の形態に係る他装置履歴データベースの更新方法について説明するフロー図である。
なお、一例として、第1情報処理装置110が「主系」、第2情報処理装置130が「従系」とし、第2情報処理装置130の制御部138(主に履歴更新部138a)が他装置履歴データベース135aを更新する状況を想定して説明する。但し、第1情報処理装置110の制御部118(主に履歴更新部118a)が他装置履歴データベース115aを更新する場合も同じ処理フローになる。
(S101)履歴更新部138aは、第1情報処理装置110がアクションの実行を開始する際に送信する開始通知を受信した場合に、S102の動作に移る。一方、第1情報処理装置110がアクションの実行を開始する際に送信する開始通知を受信していない場合、履歴更新部138aは待機する。
(S102)履歴更新部138aは、イベント発生日時、イベントID、発生元装置名、アクション種別、及び状態情報(第1実行履歴情報)を他装置履歴データベース135aに格納する。このとき、履歴更新部138aは、状態情報を「実行中」に設定する。なお、イベント発生日時及びイベントIDはメッセージに含まれる。発生元装置名(ホスト名)は、例えば、メッセージの送信元を示すIPアドレスから得られる。アクション種別は、第3記憶部137に格納されたフィルタリング情報から得られる。
(S103)履歴更新部138aは、第1情報処理装置110がアクションの実行を終了した際に送信する終了通知を受信した場合、S104の動作に移る。この終了通知には、アクションの実行結果(成功又は失敗)が含まれる。一方、第1情報処理装置110がアクションの実行を終了した際に送信する終了通知を受信していない場合、履歴更新部138aは待機する。
(S104)履歴更新部138aは、他装置履歴データベース135aに格納された状態情報を「実行済」に更新する。さらに、履歴更新部138aは、アクションの実行結果を状態情報に付与する。S104の動作を終了すると、履歴更新部138aは、1つのアクションに対する1回の実行について他装置履歴データベース135aの更新に係る動作を終了する。
以上、第2の実施の形態に係る他装置履歴データベースの更新方法について説明した。
(復旧時の動作について)
次に、第2の実施の形態に係る主系及び従系の装置による復旧時の動作について、シーケンス図を参照しながら説明する。図14は、第2の実施の形態に係る主系及び従系の装置による復旧時の動作について説明するシーケンス図である。なお、一例として、「主系」として動作していた第1情報処理装置110が障害により停止した状態から復旧する状況を想定して説明する。さらに、「従系」として動作していた第2情報処理装置130が、第1情報処理装置110の停止中に「主系」へと変更された場合を想定する。
(S111)第1情報処理装置110が復旧した場合、属性管理部118bは、第2情報処理装置130に対して第2未通知履歴情報及び属性情報を要求する。なお、属性管理部118bは、例えば、電源の投入、オペレーティングシステムやアプリケーションソフトウェアの起動、ネットワーク機能の回復、或いは、ユーザ(端末装置300)による明示的な通知を検知することで復旧を判断する。
(S112)属性管理部138bは、第1情報処理装置110から受けた要求に応じて未通知履歴データベース136aに格納された第2未通知履歴情報、及び第3記憶部137に格納された属性情報を第1情報処理装置110に送信する。
(S113)属性管理部118bは、第2情報処理装置130から受信した第2未通知履歴情報及び属性情報を第3記憶部117に格納する。
(S114)属性管理部118bは、第3記憶部117に格納した第2情報処理装置130の属性情報を参照し、第2情報処理装置130の属性を確認する。第2情報処理装置130の属性が「主系」である場合、属性管理部118bは、第1情報処理装置110の属性を「従系」に変更する。
(S115)属性管理部118bは、監視対象となる被監視装置210、220などの被監視装置から未通知メッセージを受信する。属性管理部118bは、第3記憶部117に格納した第2未通知履歴情報を参照し、未通知メッセージが示すイベントと同じイベントに対して第2情報処理装置130が既にアクションを実行して成功しているかを確認する。
属性管理部118bは、第2情報処理装置130が既に実行して成功したアクションの実行を抑止する。第2情報処理装置130が実行していないか、成功していないアクションがある場合、属性管理部118bは、そのアクションを実行する。全ての未通知メッセージについて処理を完了した場合、第1情報処理装置110は、「従系」として動作する。一方、第2情報処理装置130は、そのまま「主系」として動作する。
以上、第2の実施の形態に係る主系及び従系の装置による復旧時の動作について説明した。なお、元々「従系」として動作していた装置が復旧した場合には、属性及び属性情報に関する動作を省略することができる。
(主系の装置の動作について)
次に、第2の実施の形態に係る主系の装置の動作について、フロー図を参照しながら説明する。図15は、第2の実施の形態に係る主系の装置の動作について説明するフロー図である。なお、一例として、第1情報処理装置110が「主系」、第2情報処理装置130が「従系」とし、第1情報処理装置110の動作を想定して説明する。但し、第1情報処理装置110が「従系」、第2情報処理装置130が「主系」の場合も同様である。
(S121)属性管理部118bは、監視対象となる被監視装置210、220などの被監視装置からメッセージを受信したか否かを判定する。被監視装置からメッセージを受信した場合、属性管理部118bは、S122の動作に移る。一方、被監視装置からメッセージを受信していない場合、属性管理部118bは、再びS121の動作に戻る。
(S122)属性管理部118bは、他装置履歴データベース115aを参照し、S121の動作で被監視装置から受信したメッセージが示すイベントと同じイベントに対応する第2実行履歴情報を探索する。このとき、属性管理部118bは、同じイベントに対応する第2実行履歴情報のうち、状態情報に付与されているアクションの実行結果が「成功」となっている第2実行履歴情報(以下、成功履歴情報)を抽出する。
なお、第1情報処理装置110が第2情報処理装置130から開始通知や終了通知を受信した場合には、図13に示した方法で履歴更新部118aにより他装置履歴データベース115aがその都度更新される。そのため、イベントに対するアクションの実行を開始する前に、属性管理部118bは、第2情報処理装置130が既に同じイベントに対するアクションの実行を成功しているか確認できる。
(S123)属性管理部118bは、S122の動作で他装置履歴データベース115aから成功履歴情報を抽出できた場合、S124の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第2情報処理装置130が既にアクションを実行して成功している場合、属性管理部118bは、S124の動作に移る。
一方、S122の動作で他装置履歴データベース115aから成功履歴情報を抽出できなかった場合、属性管理部118bは、S126の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第2情報処理装置130がアクションを実行していないか、成功していない場合、属性管理部118bは、S126の動作に移る。
「主系」として第1情報処理装置110が正常動作している場合(停止せずに動作している場合)、通常、メッセージが示すイベントに対するアクションは第1情報処理装置110が実行する。そのため、同じイベントの成功履歴情報が他装置履歴データベース115aに格納されていない。しかし、何らかの理由で先に第2情報処理装置130が同じイベントに対するアクションを実行した場合、同じイベントの成功履歴情報が他装置履歴データベース115aに格納されることがある。このような状況として、例えば、第1情報処理装置110に対してのみメッセージの到達が極端に遅れた場合などが考えられる。
(S124)属性管理部118bは、S121の動作で被監視装置から受信したメッセージが示すイベントに対するアクションの実行を抑止する。つまり、属性管理部118bは、このイベントに対するアクションを第1情報処理装置110では実行しないこととする。
(S125)属性管理部118bは、第3記憶部117に格納された属性情報を変更し、第1情報処理装置110の属性を「主系」から「従系」へと変更する。他装置履歴データベース115aに成功履歴情報が格納されている場合、第2情報処理装置130が「主系」としてアクションを実行しているため、その後は第1情報処理装置110が「従系」として動作する。S125の動作を完了すると、1つのメッセージに対するアクションの実行についての処理が終了する。
(S126)属性管理部118bは、アクションの実行を開始し、第2情報処理装置130に開始通知を送信してアクションの実行開始を通知する。
(S127)属性管理部118bは、第2情報処理装置130に送信した開始通知が正常に受信されたか否かを判定する。例えば、属性管理部118bは、第2情報処理装置130から開始通知に対する確認応答を受信したか否かを確認する。
第2情報処理装置130により開始通知が正常に受信された場合、属性管理部118bは、第2情報処理装置130が正常に動作していると認識し、S128の動作に移る。一方、第2情報処理装置130により開始通知が正常に受信されなかった場合、属性管理部118bは、第2情報処理装置130に障害が発生していると認識し、S130の動作に移る。
(S128)アクション実行部114は、メッセージが示すイベントに対するアクションを実行する。例えば、該当するイベント種別に対応するアクションがメール通知である場合、アクション実行部114は、端末装置300に対してイベントの発生及びその内容を通知する電子メールを送信する。端末装置300へ電子メールを送信できた場合、属性管理部118bは、アクションの実行が成功したと判断する。端末装置300へ電子メールを送信できなかった場合、属性管理部118bは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部118bは、S129の動作に移る。
(S129)属性管理部118bは、アクションの実行結果を含む終了通知を第2情報処理装置130に送信してアクションの実行終了を通知する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、属性管理部118bは、その実行動作について開始通知の送信、アクションの実行、及び終了通知の送信を行う。S129の動作を終了すると、1つのメッセージに対するアクションの実行についての処理が終了する。
(S130)属性管理部118bは、未通知履歴データベース116aにイベント発生日時などの第1未通知履歴情報を格納する。このとき、属性管理部118bは、第1未通知履歴情報に含まれる状態情報を「実行中」に設定する。
(S131)アクション実行部114は、メッセージが示すイベントに対するアクションを実行する。例えば、アクション実行部114は、端末装置300に対してイベントの発生及びその内容を通知する電子メールを送信する。この場合、端末装置300へ電子メールを送信できた場合、属性管理部118bは、アクションの実行が成功したと判断する。一方、端末装置300へ電子メールを送信できなかった場合、属性管理部118bは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部118bは、S132の動作に移る。
(S132)属性管理部118bは、未通知履歴データベース116aに格納した第1未通知履歴情報の状態情報を「実行済」に更新する。さらに、属性管理部118bは、アクションの実行結果を状態情報に付加する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、S130〜S132の動作が再び行われる。S132の動作を終了すると、1つのメッセージに対するアクションの実行についての処理が終了する。
以上、第2の実施の形態に係る主系の装置の動作について説明した。
(従系の装置の動作について)
次に、第2の実施の形態に係る従系の装置の動作について、フロー図を参照しながら説明する。図16は、第2の実施の形態に係る従系の装置の動作について説明するフロー図である。なお、一例として、第1情報処理装置110が「主系」、第2情報処理装置130が「従系」とし、第2情報処理装置130の動作を想定して説明する。但し、第1情報処理装置110が「従系」、第2情報処理装置130が「主系」の場合も同様である。
(S141)属性管理部138bは、監視対象となる被監視装置210、220などの被監視装置からメッセージを受信したか否かを判定する。被監視装置からメッセージを受信した場合、属性管理部138bは、S142の動作に移る。一方、被監視装置からメッセージを受信していない場合、属性管理部138bは、再びS141の動作に戻る。
(S142)属性管理部138bは、他装置履歴データベース135aを参照し、S141の動作で被監視装置から受信したメッセージが示すイベントと同じイベントに対応する第1実行履歴情報を探索する。このとき、属性管理部138bは、同じイベントに対応する第1実行履歴情報のうち、成功履歴情報を抽出する。
なお、第2情報処理装置130が第1情報処理装置110から開始通知や終了通知を受信した場合には、図13に示した方法で履歴更新部138aにより他装置履歴データベース135aがその都度更新される。そのため、イベントに対するアクションの実行を開始する前に、属性管理部138bは、第1情報処理装置110が既に同じイベントに対するアクションの実行を成功しているか確認できる。
(S143)属性管理部138bは、S142の動作で他装置履歴データベース135aから成功履歴情報を抽出できた場合、S144の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第1情報処理装置110が既にアクションを実行して成功している場合、属性管理部138bは、S144の動作に移る。
一方、S142の動作で他装置履歴データベース135aから成功履歴情報を抽出できなかった場合、属性管理部138bは、S145の動作に移る。つまり、被監視装置から受信したメッセージが示すイベントに対して第1情報処理装置110がアクションを実行していないか、成功していない場合、属性管理部138bは、S145の動作に移る。
(S144)属性管理部138bは、S141の動作で被監視装置から受信したメッセージが示すイベントに対するアクションの実行を抑止する。つまり、属性管理部138bは、このイベントに対するアクションを第2情報処理装置130では実行しないこととする。S144の動作を完了すると、1つのメッセージに対するアクションの実行についての処理が終了する。
(S145)属性管理部138bは、S141の動作で被監視装置からメッセージを受信した後、S142の動作(以下、ポーリング)を所定回数行ったか否かを判定する。例えば、属性管理部138bは、S141の動作でメッセージを受信した際にカウンタをリセットし、S142の動作を行う度にカウンタの値を1ずつ増加させ、カウンタの値が所定の閾値(所定回数を示す値)に達したか否かを判定する。
ポーリングの回数が所定回数に達していない場合、属性管理部138bは、S146の動作に移る。一方、ポーリングの回数が所定回数に達した場合、属性管理部138bは、S147の動作に移る。なお、所定回数(例えば、10回)は予め設定される。例えば、ポーリングを所定回数だけ実行した際に要する時間が、1つのアクションを第1情報処理装置110が実行して成功させるのに十分と考えられる時間となるように所定回数が設定される。
(S146)属性管理部138bは、所定時間(以下、ポーリング間隔)だけ待機する。つまり、属性管理部138bは、自身が受信したメッセージと同じメッセージが示すイベントに対して第1情報処理装置110がアクションを成功させるのを待ち受ける。例えば、ポーリング間隔は、第1情報処理装置110が正常動作している状態で1つのアクションを1回実行完了するまでに要すると予想される時間に予め設定される。ポーリング間隔は、例えば、60秒に設定される。
(S147)履歴更新部138aは、S141の動作で受信したメッセージが示すイベントに対するアクションを開始し、未通知履歴データベース136aにイベント発生日時などの第2未通知履歴情報を格納する。
(S148)アクション実行部134は、メッセージが示すイベントに対するアクションを実行する。例えば、イベント種別がメール通知の場合、アクション実行部134は、端末装置300に対してイベントの発生及びその内容を通知する電子メールを送信する。端末装置300へ電子メールを送信できた場合、属性管理部138bは、アクションの実行が成功したと判断する。一方、端末装置300へ電子メールを送信できなかった場合、属性管理部138bは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部138bは、S149の動作に移る。
(S149)属性管理部138bは、未通知履歴データベース136aに格納した第2未通知履歴情報の状態情報を「実行済」に更新する。さらに、属性管理部138bは、アクションの実行結果を状態情報に付与する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、S147〜S149の動作が再び実行される。S149の動作を終了すると、属性管理部138bは、S150の動作に移る。
(S150)属性管理部138bは、第3記憶部137に格納された自身の属性情報を更新し、第2情報処理装置130の属性を「従系」から「主系」へと変更する。S150の動作を終了すると、1つのメッセージに対するアクションの実行についての処理が終了する。
以上、第2の実施の形態に係る従系の装置の動作について説明した。
[変形例#1:ポーリング間隔の調整]
ここで、第2の実施の形態に係る一変形例(変形例#1)について説明する。変形例#1では、(1)ポーリング間隔をアクション種別毎に設定する方法、及び(2)実際に計測されたアクションの実行時間に基づいてポーリング間隔を調整する方法を提案する。なお、ここでは、説明の都合上、第2情報処理装置130の属性が「従系」である場合を想定し、第2情報処理装置130がポーリング間隔を調整する例について説明する。但し、第1情報処理装置110の属性が「従系」である場合についても同様である。
変形例#1に係る第2情報処理装置130は、上述した所定回数(ポーリングの最大実行回数)及びポーリング間隔の初期値を示す情報を第3記憶部137に保持している。そして、属性管理部138bは、この情報に基づいて動作し、アクション種別毎に1回のアクションの実行に要した時間(以下、実行時間)を計測する。例えば、属性管理部138bは、開始通知を受信してから終了通知を受信するまでの時間を計測して実行時間とする。そして、属性管理部138bは、計測した実行時間の情報を第3記憶部137に格納する。
さらに、属性管理部138bは、同じアクション種別について過去に計測した実行時間と現在計測した実行時間との平均値を算出する。例えば、属性管理部138bが計測した実行時間の情報及び平均値の情報は、図17のようにアクション種別毎に保持される。図17は、第2の実施の形態の一変形例(変形例#1)に係るポーリング間隔テーブルの生成に用いる情報の例を示した図である。こうした情報に基づき、属性管理部138bは、アクション種別と平均値とを対応付けた情報(以下、ポーリング間隔テーブル)を生成して第3記憶部137に格納する。
属性管理部138bは、第1情報処理装置110でアクションが実行される度に実行時間を計測し、計測した実行時間を用いて平均値を算出する。そして、属性管理部138bは、算出した平均値を用いてポーリング間隔テーブルを更新する。さらに、属性管理部138bは、ポーリング間隔テーブルに記載されている平均値をポーリング間隔に設定する。このとき、属性管理部138bは、アクション種別毎にポーリング間隔を設定する。なお、ポーリング間隔の設定タイミングは、ポーリング間隔テーブルの更新時でもよいし、実行時間の計測回数が所定の閾値を超えたときやユーザによる設定の指示があったときでもよい。
ここで、ポーリング間隔テーブルの更新方法について、フロー図を参照しながら説明する。図18は、第2の実施の形態の一変形例(変形例#1)に係るポーリング間隔テーブルの更新方法について説明するフロー図である。
(S201)属性管理部138bは、第1情報処理装置110から開始通知を受信したか否かを判定する。開始通知を受信した場合、属性管理部138bは、S202の動作に移る。一方、開始通知を受信していない場合、属性管理部138bは、再びS201の動作に移る。
(S202)属性管理部138bは、実行時間の計測を開始する。例えば、属性管理部138bは、計測を開始した時刻の情報を保持する。
(S203)属性管理部138bは、第1情報処理装置110から終了通知を受信したか否かを判定する。終了通知を受信した場合、属性管理部138bは、S205の動作に移る。つまり、第1情報処理装置110により1つのアクションの実行が終了したことが確認された際に、属性管理部138bは、S205の動作に移る。一方、終了通知を受信していない場合、属性管理部138bは、S204の動作に移る。
(S204)属性管理部138bは、ポーリングを所定回数行ったか否かを判定する。ポーリングの回数が所定回数に達している場合、属性管理部138bは、ポーリング間隔テーブルの更新を行わず、ポーリング間隔テーブルの更新に関する動作を終了する。つまり、図16に示したフロー図におけるS145の動作で、属性管理部138bがS147の動作に移った場合、ポーリング間隔テーブルの更新は行われない。一方、ポーリングの回数が所定回数に達していない場合、属性管理部138bは、再びS203の動作に移る。
(S205)属性管理部138bは、実行時間の計測を終了する。例えば、属性管理部138bは、計測を終了した時刻の情報を保持する。そして、属性管理部138bは、計測を開始した時刻から計測を終了した時刻までの時間を計算し、計算した時間を実行時間とする。
(S206)属性管理部138bは、S205の動作で今回計測した実行時間に対応するアクションと同じアクション種別について、過去に計測した実行時間の情報を保持している場合、今回計測した実行時間と過去に計測した実行時間との平均値を計算する。
(S207)属性管理部138bは、S206の動作で計算した平均値を用いてポーリング間隔テーブルを更新する。S207の動作を終了すると、属性管理部138bは、ポーリング間隔テーブルの更新について処理を終了する。
以上、第2の実施の形態に係る一変形例(変形例#1)について説明した。変形例#1によれば、アクション種別毎に実際に計測された実行時間に基づいてポーリング間隔が設定されるため、「主系」に障害が生じた場合に適切なタイミングで「従系」が「主系」として動作できるようになる。さらに、他装置履歴データベース135aへのアクセス頻度が大きくなり過ぎないように調整されるため、ポーリングに伴う負荷を低減できる。
なお、上記の説明においては、ポーリングを行う最大回数である所定回数を固定値と考えていたが、この所定回数を実行時間に応じて変更してもよい。例えば、ポーリング間隔を固定して所定回数を増加させれば、「主系」に障害が生じたと判断するまでの待ち時間を延ばすことができる。逆に、ポーリング間隔を固定して所定回数を減少させれば、「主系」に障害が生じたと判断するまでの待ち時間を短縮することができる。そのため、実際に計測された実行時間に応じて所定回数を増減させることで、適切なタイミングで属性の変更及び動作の引き継ぎを行うことが可能になる。
[変形例#2:従系への実行依頼]
次に、第2の実施の形態に係る一変形例(変形例#2)について説明する。変形例#2では、「主系」の負荷が高い場合に、実行すべき一部のアクションを「従系」に実行依頼する方法を提案する。なお、ここでは、説明の都合上、第1情報処理装置110の属性が「主系」であり、第2情報処理装置130の属性が「従系」である場合を想定して説明する。但し、第1情報処理装置110の属性が「従系」であり、第2情報処理装置130の属性が「主系」である場合についても同様である。
(装置の動作及びアクション負荷値テーブルについて)
変形例#2に係る主系及び従系の装置の動作について説明する。図19は、第2の実施の形態の一変形例(変形例#2)に係る主系及び従系の装置の動作について説明する図である。
例えば、「主系」である第1情報処理装置110がアクション#1〜#3を実行中である場合に、第1情報処理装置110及び第2情報処理装置130に新たなメッセージ(アクション#4に対応)が送信された状況を想定する。この状況では、高負荷状態にある「主系」の第1情報処理装置110がアクション#4を実行するよりも、「従系」の第2情報処理装置130がアクション#4を実行する方が効率的である。そこで、変形例#2に係る第1情報処理装置110は、アクション#4を実行した場合における自身の負荷状況(例えば、CPU使用率など)を予測し、高負荷状態になると判断し、かつ、一定の条件満たした場合にアクション#4を第2情報処理装置130に依頼する。
第1情報処理装置110による負荷状況の予測は、例えば、負荷状況を表す評価値(以下、アクション負荷値)に基づいて行われる。例えば、属性管理部118bは、アクション負荷値が所定の閾値(以下、アクション切り替え境界値)を超えた場合にアクション#4を第2情報処理装置130に依頼する。アクション負荷値は、属性管理部118bにより計算され、第3記憶部117に格納されるアクション負荷値テーブルに記録される。
ここで、アクション負荷値の計算方法及びアクション負荷値テーブルについて、さらに説明する。図20は、第2の実施の形態の一変形例(変形例#2)に係るアクション負荷値テーブルの生成に用いる情報の例を示した図である。
アクション負荷値は、アクション種別毎に計算される。属性管理部118bは、アクションを実行する際、アクションの実行時間、アクションの実行期間における平均メモリ使用量及び平均CPU使用率を保持する。そして、属性管理部118bは、例えば、(実行時間(秒)×平均メモリ使用量(キロバイト(KB))×平均CPU使用率(%))をアクション負荷値とする。なお、ここで示した各値の単位は一例である。
図20の例では、アクション種別が「メール通知」であるアクションについて、実行時間「1秒」、平均メモリ使用量「50KB」、平均CPU使用率「1%」が得られており、これらの値に基づくとアクション負荷値は(1×50×1)=50となる。他のアクション種別についても同様である。このような方法で、属性管理部118bは、アクション種別毎にアクション負荷値を計算し、アクション負荷値テーブルに記録する。
なお、アクション負荷値テーブルに記録したものと同じアクション種別のアクション負荷値を新たに算出した場合、属性管理部118bは、それらの平均値を新たなアクション負荷値としてアクション負荷値テーブルの情報を更新する。
(アクション負荷値テーブルの更新方法について)
ここで、アクション負荷値テーブルの更新方法について、フロー図を参照しながら説明する。図21は、第2の実施の形態の一変形例(変形例#2)に係るアクション負荷値テーブルの更新方法について説明するフロー図である。
(S301)属性管理部118bは、アクションの実行を開始するか否かを判定する。アクションの実行を開始する場合、属性管理部118bは、S302の動作に移る。つまり、図15に示したフロー図におけるS128又はS131の動作に移った場合、属性管理部118bは、S302の動作に移る。一方、アクションの実行を開始しない場合、属性管理部118bは、再びS301の動作に移る。
(S302)属性管理部118bは、実行時間の計測を開始する。例えば、属性管理部118bは、アクションの実行を開始する時刻を保持する。
(S303)属性管理部118bは、アクション負荷値の計算用にメモリ使用量の記録を開始する。記録を開始した後、属性管理部118bは、アクションの実行が終了するまでの間、所定の時間間隔で定期的にメモリ使用量の情報を記録する。所定の時間間隔は、予めユーザにより任意に設定されているものとする。
(S304)属性管理部118bは、アクション負荷値の計算用にCPU使用率の記録を開始する。記録を開始した後、属性管理部118bは、アクションの実行が終了するまでの間、所定の時間間隔で定期的にCPU使用率の情報を記録する。所定の時間間隔は、予めユーザにより任意に設定されているものとする。なお、S302〜S304の動作は任意に順序を入れ替えてよい。
(S305)属性管理部118bは、アクションの実行が終了したか否かを判定する。アクションの実行が終了した場合、属性管理部118bは、S306の動作に移る。つまり、図15に示したフロー図におけるS129又はS132の動作に移った場合、属性管理部118bは、S306の動作に移る。一方、アクションの実行が終了していない場合、属性管理部118bは、再びS305の動作に移る。
(S306)属性管理部118bは、実行時間の計測を終了する。例えば、属性管理部118bは、アクションの実行を終了した時刻を保持し、実行を開始した時刻から実行を終了した時刻までの時間を計算して実行時間とする。
(S307)属性管理部118bは、S303の動作で記録を開始してからアクションが終了するまでの間に定期的に記録されたメモリ使用量を読み出し、読み出したメモリ使用量の平均値を計算する。属性管理部118bは、計算した平均値をアクション負荷値の計算に用いる平均メモリ使用量とする。
(S308)属性管理部118bは、S304の動作で記録を開始してからアクションが終了するまでの間に定期的に記録されたCPU使用率を読み出し、読み出したCPU使用率の平均値を計算する。属性管理部118bは、計算した平均値をアクション負荷値の計算に用いる平均CPU使用率とする。なお、S306〜S308の動作は任意に順序を入れ替えてもよい。
(S309)属性管理部118bは、S306〜S308の動作で計算された実行時間、平均メモリ使用量、及び平均CPU使用率に基づいてアクション負荷値(実行時間×平均メモリ使用量×平均CPU使用率)を計算する。
(S310)属性管理部118bは、S309の動作で計算したアクション負荷値を用いてアクション負荷値テーブルを更新する。なお、S309の動作で計算したアクション負荷値と同じアクション種別のアクション負荷値がアクション負荷値テーブルに記録されている場合、属性管理部118bは、これら2つのアクション負荷値の平均値を用いてアクション負荷値テーブルを更新する。S310の動作を終了すると、属性管理部118bは、アクション負荷値テーブルの更新について処理を終了する。
(アクション切り替え境界値の更新方法について)
ここで、高負荷状況か否かを判定する際に閾値として用いられるアクション切り替え境界値の更新方法について、フロー図を参照しながら説明する。図22は、第2の実施の形態の一変形例(変形例#2)に係るアクション切り替え境界値の更新方法について説明するフロー図である。なお、アクション切り替え境界値は、その値が大きいほど従系への実行依頼が発生しにくくなり、逆に値が小さいほど実行依頼が発生しやすくなる。
(S311)属性管理部118bは、アクション切り替え境界値の更新タイミングになったか否かを判定する。アクション切り替え境界値の更新タイミングは任意に設定することができるが、一例として、ここでは一定の時間間隔で更新が行われる場合を想定している。従って、一定の時間間隔で更新タイミングが訪れる。更新タイミングになった場合、属性管理部118bは、S312の動作に移る。一方、更新タイミングになっていない場合、属性管理部118bは、再びS311の動作に移る。
(S312)属性管理部118bは、第2情報処理装置130に対してCPU使用率の情報を送信するように要求する。第2情報処理装置130のCPU使用率の情報を受信した場合、属性管理部118bは、受信したCPU使用率の情報を保持する。
(S313)属性管理部118bは、前回の更新タイミングの際に第2情報処理装置130から受信して保持しているCPU使用率(以下、前回CPU使用率)の情報を参照する。さらに、属性管理部118bは、今回の更新タイミングの際に第2情報処理装置130から受信して保持しているCPU使用率(以下、今回CPU使用率)の情報を参照する。そして、属性管理部118bは、前回CPU使用率に比べて今回CPU使用率の方が大きいか否かを判定する。
前回CPU使用率よりも今回CPU使用率の方が大きい場合、属性管理部118bは、S315の動作に移る。一方、前回CPU使用率よりも今回CPU使用率の方が小さいか、同じの場合、属性管理部118bは、S314の動作に移る。
(S314)属性管理部118bは、アクション切り替え境界値を減少させる。つまり、前回の更新タイミングでアクション切り替え境界値を更新したが、第2情報処理装置130の負荷状況が悪化していないので、第2情報処理装置130に余裕があると考え、属性管理部118bは、従系の実行依頼が発生しやすくなるようにする。S314の動作を終えると、属性管理部118bは、アクション切り替え境界値の更新(1回分)について処理を終了する。
(S315)属性管理部118bは、アクション切り替え境界値を増加させる。つまり、前回の更新タイミングでアクション切り替え境界値を更新した結果、第2情報処理装置130の負荷状況が悪化したので、属性管理部118bは、従系の実行依頼が発生しにくくなるようにする。S315の動作を終えると、アクション切り替え境界値の更新(1回分)についての処理が終了する。
(実行依頼の要否判定方法について)
次に、上記のアクション負荷値テーブル及びアクション切り替え境界値を利用した従系への実行依頼(アクション切り替え判定)方法について、フロー図を参照しながら説明する。図23は、第2の実施の形態の一変形例(変形例#2)に係る実行依頼の要否判定方法について説明する第1のフロー図である。なお、第1情報処理装置110の属性が「主系」であるとする。
(S321)属性管理部118bは、次に実行するアクションが発生したか否かを判定する。次に実行するアクションが発生した場合、属性管理部118bは、S322の動作に移る。つまり、属性管理部118bは、図15に示したフロー図のS126の動作に移る場合、すぐにはS126の動作へ移らずにS322以降の動作を行う。次に実行するアクションが発生していない場合、属性管理部118bは、再びS321の動作に移る。
(S322)属性管理部118bは、アクション負荷値テーブルを参照し、実行中のアクションと同じアクション種別のアクション負荷値を取得する。なお、実行中のアクションが複数存在する場合、属性管理部118bは、全てのアクションについてアクション負荷値を取得する。さらに、属性管理部118bは、次に実行するアクションと同じアクション種別のアクション負荷値を取得する。
(S323)属性管理部118bは、実行中のアクションのアクション負荷値と、次に実行するアクションのアクション負荷値とを合計して合計値を算出する。なお、実行中のアクションが複数存在する場合、属性管理部118bは、全ての実行中のアクションに対応するアクション負荷値及び次に実行するアクションのアクション負荷値を合計して合計値を算出する。
(S324)属性管理部118bは、S323の動作で算出した合計値がアクション切り替え境界値よりも大きいか否かを判定する。つまり、属性管理部118bは、次に実行するアクションを実行した場合に予測される自身の負荷状況を示す合計値が、実行依頼の要否を判定する閾値となるアクション切り替え境界値よりも大きいか否かを判定する。合計値がアクション切り替え境界値よりも大きい場合、属性管理部118bは、図24に示したS325の動作に移る。一方、合計値がアクション切り替え境界値よりも小さい場合、属性管理部118bは、図24に示したS329の動作に移る。
次に、図24を参照する。図24は、第2の実施の形態の一変形例(変形例#2)に係る実行依頼の要否判定方法について説明する第2のフロー図である。
(S325)属性管理部118bは、S325の動作時における自身の負荷状況を示す値(以下、主系のシステム負荷値)を算出する。例えば、属性管理部118bは、CPU使用率及びメモリ使用量を検出し、(CPU使用率×メモリ使用量)を主系のシステム負荷値とする。この主系のシステム負荷値は、アクション切り替え判定を行う時点における属性管理部118bの実際の負荷状況を表すものである。
(S326)属性管理部118bは、S326の動作時における第2情報処理装置130の負荷状況を示す値(以下、従系のシステム負荷値)を算出する。例えば、属性管理部118bは、第2情報処理装置130に対してCPU使用率及びメモリ使用量を検出して送信するように依頼し、第2情報処理装置130からCPU使用率及びメモリ使用量の情報を受信する。そして、属性管理部118bは、第2情報処理装置130から受信した情報に基づき、(CPU使用率×メモリ使用量)を計算して従系のシステム負荷値とする。この従系のシステム負荷値は、アクション切り替え判定を行う時点における第2情報処理装置130の実際の負荷状況を表すものである。なお、S325の動作とS326の動作とは順序を入れ替えてもよい。
(S327)属性管理部118bは、主系のシステム負荷値が従系のシステム負荷値よりも大きいか否かを判定する。主系のシステム負荷値が従系のシステム負荷値よりも大きい場合、属性管理部118bは、S328の動作に移る。つまり、次に実行するアクションを実行した場合に高負荷状態になると予想され、現時点の負荷状況を比較すると第2情報処理装置130の方が低負荷の状態にある場合、属性管理部118bは、S328の動作に移る。
一方、主系のシステム負荷値が従系のシステム負荷値よりも小さい場合、属性管理部118bは、S329の動作に移る。つまり、次に実行するアクションを実行した場合には高負荷状態になると予想されるが、現時点の負荷状況を比較すると第2情報処理装置130の方が高負荷の状態にある場合、属性管理部118bは、S329の動作に移る。
(S328)属性管理部118bは、次に実行するアクションを従系に依頼する。例えば、属性管理部118bは、次に実行するアクションに対応するメッセージを特定できる情報(例えば、イベントID及び発生元装置名)を含めて実行依頼を第2情報処理装置130に送信する。S328の動作を終えると、属性管理部118bは、そのアクションの実行を抑止し(図15に示したフロー図におけるS126の動作には移らずに終了する。)、アクション切り替え判定について処理を終了する。
(S329)属性管理部118bは、次に実行するアクションを第1情報処理装置110で実行する。つまり、属性管理部118bは、図15に示したフロー図におけるS126の動作に移る。S329の動作を終えると、アクション切り替え判定についての処理が終了する。
(従系の装置の動作について)
次に、主系の装置から実行依頼を受信する場合を想定した従系の装置の動作について、フロー図を参照しながら説明する。図25は、第2の実施の形態の一変形例(変形例#2)に係る従系の装置の動作について説明するフロー図である。なお、第1情報処理装置110の属性が「主系」であり、第2情報処理装置130の属性が「従系」であるとする。
(S331)属性管理部138bは、第1情報処理装置110から実行依頼を受信したか否かを判定する。「従系」である第2情報処理装置130の属性管理部138bは、メッセージを受信した後、ポーリングを繰り返しながら成功履歴情報を履歴更新部138aが他装置履歴データベース135aに格納するか、所定のポーリング回数に達するまで待機する。この間に、第1情報処理装置110により上述したアクション切り替え判定の処理が実行される。この処理の中で所定の条件を満たした場合に第1情報処理装置110が送信した実行依頼を第2情報処理装置130は受信する。実行依頼を受信した場合、属性管理部138bは、S332の動作に移る。一方、実行依頼を受信していない場合、属性管理部138bは、ポーリングの動作を継続する。
(S332)属性管理部138bは、実行依頼で指定されたアクションの実行を開始し、そのアクションの実行開始を示す開始通知を第1情報処理装置110に送信する。
(S333)アクション実行部134は、アクションを実行する。例えば、アクション実行部134は、端末装置300に対してイベントの発生及びその内容を通知する電子メールを送信する。端末装置300へ電子メールを送信できた場合、属性管理部138bは、アクションの実行が成功したと判断する。一方、端末装置300へ電子メールを送信できなかった場合、属性管理部138bは、アクションの実行が失敗したと判断する。アクションの実行が終了すると、属性管理部138bは、S334の動作に移る。
(S334)属性管理部138bは、アクションの実行結果を含む終了通知を第1情報処理装置110に送信してアクションの実行終了を通知する。なお、アクションの実行が失敗し、同じアクションを再実行する場合、属性管理部138bは、開始通知の送信、アクションの実行制御、及び終了通知の送信を行う。S334の動作を終了すると、実行依頼されたアクションの実行についての処理が終了する。
以上、第2の実施の形態に係る一変形例(変形例#2)について説明した。変形例#2によれば、主系の装置が高負荷状態にある場合に、一部のアクションを従系の装置で実行することが可能になる。また、変形例#2の場合、新たに実行するアクションを実行した場合に予測される主系の負荷状況と、そのアクションを実行する前の主系及び従系における実際の負荷状況とを共に考慮して実行依頼を行うか否かを判断する。そのため、アクション以外の処理によって従系の装置が高負荷状態になっている状況なども考慮して適切に実行依頼が行われる。
[変形例#3:未通知履歴データベースの簡略化]
次に、第2の実施の形態の一変形例(変形例#3)について説明する。変形例#3では、障害から復旧した装置に対して送信する未通知履歴情報のデータ量を低減する方法を提案する。なお、この方法を適用することで、未通知履歴データベース116a、136aに格納されるデータ量も低減される。以下では、第1情報処理装置110の未通知履歴データベース116aを例に説明を進める。但し、第2情報処理装置130の未通知履歴データベース136aについても同様である。
(未通知履歴データベースについて)
図26は、第2の実施の形態の一変形例(変形例#3)に係る未通知履歴データベースの例を示した図である。図26に示すように、変形例#3に係る未通知履歴データベース116aは、少なくとも発生元装置名及びイベント発生日時を格納したものであればよい。イベント発生日時の情報は、発生元装置名毎に最新の情報に更新される。
例えば、未通知履歴データベース116aに発生元装置名及びイベント発生日時を格納する場合、属性管理部118bは、同じ発生元装置名に対応するイベント発生日時が未通知履歴データベース116aに格納されているか確認する。同じ発生元装置名に対応するイベント発生日時が未通知履歴データベース116aに格納されている場合、属性管理部118bは、そのイベント発生日時を最新のイベント発生日時で更新する。一方、同じ発生元装置名に対応するイベント発生日時が未通知履歴データベース116aに格納されていない場合、属性管理部118bは、発生元装置名とイベント発生日時とを対応付けて未通知履歴データベース116aに格納する。
(未通知履歴データベースの更新方法について)
ここで、変形例#3に係る未通知履歴データベースの更新方法について、フロー図を参照しながら説明する。図27は、第2の実施の形態の一変形例(変形例#3)に係る未通知履歴データベースの更新方法について説明するフロー図である。なお、第1情報処理装置110が「主系」である場合も「従系」である場合も同様である。
変形例#3の場合(但し、第1情報処理装置110が「主系」の場合)、図15に示したフロー図のS130及びS132の動作が省略され、S131の動作が実行された後で図27に示したフロー図の動作が実行される形となる。さらに、変形例#3の場合(但し、第1情報処理装置110が「従系」の場合)、図16に示したフロー図のS147及びS149の動作が省略され、S149の動作が実行された後で図27に示したフロー図の動作が実行される形となる。
(S401)属性管理部118bは、アクションの実行が成功したか否かを判定する。アクションの実行が成功した場合、属性管理部118bは、S402の動作に移る。一方、アクションの実行が成功していない場合、属性管理部118bは、再びS401の動作に移る。
(S402)属性管理部118bは、未通知履歴データベース116aを参照し、実行したアクションに対応するイベントの発生元を示す発生元装置名と同じ発生元装置名を検索する。
(S403)属性管理部118bは、未通知履歴データベース116aから、実行したアクションに対応するイベントの発生元を示す発生元装置名と同じ発生元装置名を見つけた場合、S405の動作に移る。つまり、第2情報処理装置130で障害が発生している間に、同じ発生元装置名の装置で発生した何らかのイベントに対して第1情報処理装置110がアクションを実行して成功している場合、属性管理部118bは、S405の動作に移る。
一方、実行したアクションに対応するイベントの発生元を示す発生元装置名と同じ発生元装置名が未通知履歴データベース116aで見つからなかった場合、属性管理部118bは、S404の動作に移る。つまり、第2情報処理装置130で障害が発生している間に、同じ発生元装置名の装置でイベントが発生していないか、発生したイベントに対して第1情報処理装置110がアクションを成功させていない場合、属性管理部118bは、S404の動作に移る。
(S404)属性管理部118bは、実行したアクションに対応するイベントの発生元を示す発生元装置名及びイベント発生日時を対応付けて未通知履歴データベース116aに格納する。S404の動作を終えると、属性管理部118bは、未通知履歴データベース116aの更新について処理を終了する(図15のフロー図では処理の終了へ動作が移る。図16のフロー図ではS150の動作に移る。)。
(S405)属性管理部118bは、実行したアクションに対応するイベントのイベント発生日時と、未通知履歴データベース116aに格納された同じ発生元装置名に対応するイベント発生日時とを比較する。そして、未通知履歴データベース116aのイベント発生日時が古い場合、属性管理部118bは、実行したアクションに対応するイベントのイベント発生日時で未通知履歴データベース116aのイベント発生日時を更新する。S405の動作を終えると、未通知履歴データベース116aの更新についての処理が終了する(図15のフロー図では処理の終了へ動作が移る。図16のフロー図ではS150の動作に移る。)。
(未通知履歴情報に基づく成功履歴の有無判断について)
上記のように未通知履歴情報の内容を簡略化した場合、第2情報処理装置130が復旧した際の動作が一部変更される。具体的には、第2情報処理装置130が未通知メッセージを処理する際、未通知メッセージに対応するイベントを第1情報処理装置110が実行して成功しているか否かを判定する際の動作が変更される。なお、第1情報処理装置110が復旧する際の動作についても同様である。
以下、変形例#3に係る未通知履歴情報に基づいて成功履歴の有無を判断する方法について、フロー図を参照しながら説明する。図28は、第2の実施の形態の一変形例(変形例#3)に係る未通知履歴情報に基づいて成功履歴の有無を判断する方法について説明するフロー図である。
(S411)属性管理部138bは、復旧時に第1情報処理装置110から取得した未通知履歴情報を参照し、未通知メッセージに対応する発生元装置名と同じ発生元装置名を検索する。
(S412)属性管理部138bは、S411の動作で同じ発生元装置名を発見できたか否かを判定する。つまり、属性管理部138bは、第2情報処理装置130に障害が発生している間に、同じ発生元装置名の被監視装置で発生した少なくとも1つのイベントに対するアクションが第1情報処理装置110により完了しているか否かを判定する。同じ発生元装置名を発見できた場合、属性管理部138bは、S413の動作に移る。一方、同じ発生元装置名を発見できなかった場合、属性管理部138bは、S415の動作に移る。
(S413)属性管理部138bは、未通知メッセージが示すイベント発生日時より、未通知履歴情報から発見された同じ発生元装置名に対応するイベント発生日時の方が新しいか否かを判定する。つまり、属性管理部138bは、未通知メッセージが示すイベントよりも後に発生したイベントに対して第1情報処理装置110がアクションを実行して成功しているか否かを判定する。未通知履歴情報のイベント発生日時の方が新しい場合、属性管理部138bは、S414の動作に移る。一方、未通知メッセージのイベント発生日時の方が新しい場合、属性管理部138bは、S415の動作に移る。
(S414)属性管理部138bは、未通知メッセージが示すイベントに対して既に第1情報処理装置110がアクションを実行して成功していると判断する。S414の動作を終えると、属性管理部138bは、未通知履歴情報に基づいて成功履歴の有無を判断する動作を終了する。その後、属性管理部138bは、その未通知メッセージが示すイベントに対するアクションの実行を抑止する。
(S415)属性管理部138bは、未通知メッセージが示すイベントに対して第1情報処理装置110がアクションを実行していないか、成功していないと判断する。S415の動作を終えると、属性管理部138bは、未通知履歴情報に基づいて成功履歴の有無を判断する動作を終了する。その後、属性管理部138bは、その未通知メッセージが示すイベントに対するアクションを実行する。
以上、第2の実施の形態に係る一変形例(変形例#3)について説明した。変形例#3によれば、未通知履歴データベース116aに最新の成功履歴情報のみを格納することで、未通知履歴データベース116aに格納されるデータ量を低減することができる。さらに、未通知履歴情報を第2情報処理装置130に送信する際、送信されるデータ量が少なくて済むため、通信負荷を低減することが可能になる。
以上、第2の実施の形態及びその変形例について説明した。なお、上記説明においては、アクションの実行が失敗した場合に、アクションを実行した一方の装置が同じアクションを再実行することとしていたが、他方の装置が実行することとしてもよい。例えば、アクションの実行失敗を示す終了通知を受信した従系の装置が、その受信に応じて同じアクションを実行し、一方で主系の装置はアクションの実行を抑止するようにしてもよい。このような変形についても第2の実施の形態の技術的範囲に属する。