JP2009199246A

JP2009199246A - ノード稼働監視システムおよびノード稼働監視方法

Info

Publication number: JP2009199246A
Application number: JP2008039006A
Authority: JP
Inventors: Kiyosato Yamamoto; 聖哲山本; Osamu Takasaki; 修高崎; Masaki Kishihara; 正樹岸原
Original assignee: Toshiba Corp; Toshiba Solutions Corp
Current assignee: Toshiba Corp; Toshiba Digital Solutions Corp
Priority date: 2008-02-20
Filing date: 2008-02-20
Publication date: 2009-09-03

Abstract

【課題】ネットワーク上のノード間で稼働監視情報を共有する。
【解決手段】ネットワーク２に接続された複数のノード１の各々が、タスク情報、リソース情報、およびハードウェア情報を含む自ノード情報を収集する自ノード情報収集部１２と、収集された自ノード情報を解析してノード１の稼働状態を判定し、この判定結果と自ノード情報を含む稼働監視情報を出力する自ノード情報判定部１３と、稼働状態が異常と判定された場合に、出力された稼働監視情報をネットワーク上の他のノードへ送信する送信部１５と、他のノード１から送信された他の稼働監視情報を受信する受信部１６と、受信された他の稼働監視情報に基づいて他のノードの稼働状態を判定する他ノード情報判定部１７と、を有することで稼働監視情報をネットワーク２上のノード間で共有する。
【選択図】図１

Description

本発明は、ノード稼働監視システムおよびノード稼働監視方法に関する。

この種の技術としては、サーバー（監視ノード）がクライアント端末（被監視ノード）において所定の時間間隔で収集された稼働情報をネットワークを介して取得し、この稼働情報をサーバー側で解析することによって各クライアント端末の稼働状態を把握する稼働監視システムが知られている（例えば、特許文献１参照）。
特開２００６−１７８８５１号公報

しかしながら、上記の技術においては、各クライアント端末はサーバーを介さなければ他のクライアント端末の稼動監視情報を知ることが出来ない。また、監視を行うサーバー自体が異常になった場合には、クライアント端末の監視が出来ないという問題があった。

そこで、本発明は、従来技術の問題に鑑み、ネットワーク上のノード間で稼働監視情報を共有できるノード稼働監視システムおよびノード稼働監視方法を提供することを目的とする。

本発明に係るノード稼働監視システムは、ネットワークに接続された複数のノードの各々が、タスク情報、リソース情報、およびハードウェア情報を含む自ノード情報を収集する自ノード情報収集部と、この自ノード情報収集部において収集された前記自ノード情報を解析して前記ノードの稼働状態を判定し、この判定結果を含む稼働監視情報を出力する自ノード情報判定部と、この自ノード情報判定部において前記稼働状態が異常と判定された場合に、前記出力された稼働監視情報を前記ネットワーク上の他のノードへ送信する送信部と、前記他のノードに係る前記送信部から送信された他の稼働監視情報を受信する受信部と、この受信部において受信された前記他の稼働監視情報に基づいて前記他のノードの稼働状態を判定する他ノード情報判定部と、を有することを特徴とする。

本発明に係るノード稼働監視方法は、ネットワークに接続された複数のノードの各々が、全ノードの稼働監視情報を共有するノード稼働監視方法であって、前記ノードが、タスク情報、リソース情報、およびハードウェア情報を含む自ノード情報を収集する自ノード情報収集ステップと、前記ノードが、前記自ノード情報収集ステップにおいて収集された前記自ノード情報を解析して前記ノードの稼働状態を判定し、この判定結果を含む稼働監視情報を出力する自ノード情報判定ステップと、この自ノード情報判定ステップにおいて前記稼働状態が異常と判定された場合に、前記ノードが、前記出力された稼働監視情報を前記ネットワーク上の他のノードへ送信する送信ステップと、前記ノードが、前記他のノードから送信された他の稼働監視情報を受信する受信ステップと、前記ノードが、前記受信ステップにおいて受信された前記他の稼働監視情報に基づいて前記他のノードの稼働状態を判定する他ノード情報判定ステップと、を有することを特徴とする。

本発明によれば、ネットワーク上のノード間で稼働監視情報を共有できるノード稼働監視システムおよびノード稼働監視方法が提供される。

（実施形態１）
以下、本発明の実施形態について図面を用いて説明する。図１は、本発明の一実施形態に係るノード稼働監視システムの全体構成例を示す図である。同図に示されるように、ノード稼働監視システムは、複数のノード１がネットワーク２を介して接続され、データの送受信が可能に構成されている。

ノード１は、記憶部１１、自ノード情報収集部１２、自ノード情報判定部１３、表示部１４、送信部１５、受信部１６、および他ノード情報判定部１７から構成されるコンピュータである。ノード１の具体例としては、パーソナルコンピュータなど各種のコンピュータが挙げられる。

記憶部１１は、タスク登録情報、リソース登録情報、ハードウェア登録情報、過去の稼働監視履歴情報等の各種の情報を記憶する記憶装置である。登録情報は設定ファイルとして記録されており、後述する自ノード情報収集部１２からの要求に基づいてメモリ（図示省略する）に展開される。

図２は、タスク登録情報の具体例を示す図である。ここでは、データ項目としてタスク名、ヘルシー値（閾値）、メモリ使用量（閾値）、リカバリ回数（閾値）、各項目の異常時コマンドが含まれている。また、閾値はアラート（警告）、アラーム（警報）の２つの異常レベルに応じて定義されている。

図３は、リソース登録情報の具体例を示す図である。ここでは、リソース登録情報が複数のプログラム同士でリソース（ファイルやメモリなど）を共有する際に排他や同期のための制御を行うセマフォとプロセス間で交わされるメッセージに大別されている。図３（ａ）は、セマフォに関する情報であり、データ項目にセマフォ登録キー名、セマフォ操作時間（閾値）、異常時コマンドが含まれている。図３（ｂ）は、メッセージに関する情報であり、データ項目にメッセージ登録キー名、メッセージ数（閾値）、異常時コマンドが含まれている。また、タスク登録情報と同様に、閾値はアラート（警告）、アラーム（警報）の２つの異常レベルに応じて定義されている。

図４は、ハードウェア登録情報の具体例を示す図である。ここでは、データ項目として監視周期に加えて、温度、周辺温度、ＤＩ信号状態、本体内部温度状態、ＬＡＮ状態、ファン状態、ハードディスク状態、およびバッテリー状態の異常時コマンドが含まれている。また、タスク登録情報などと同様に、閾値はアラート（警告）、アラーム（警報）の２つの異常レベルに応じて定義されている。

自ノード情報収集部１２は、タスク登録情報、リソース登録情報、ハードウェア登録情報に基づいてノード１内のタスク情報、リソース情報、ハードウェア情報からなる自ノードの情報（以下、「自ノード情報」という。）を収集するプログラムである。

図５は、自ノード情報収集部１２における情報収集処理を説明する図である。同図に示されるように、自ノード情報収集部１２は、タスク情報収集プログラム１２１、リソース情報収集プログラム１２２、ハードウェア情報収集プログラム１２３を含んでいる。

タスク情報収集プログラム１２１は、上述したタスク登録情報に基づいて起動されたタスクの状態をタスク情報として定周期で収集するプログラムである。図６は、自ノード情報収集部１２で収集されたタスク情報の具体例を示す図である。ここでは、各タスクの実行状態（実行中、停止中、実行待ちなど）を示すステータス、プロセスＩＤ（ＰＩＤ）、ヘルシー値、メモリ使用量、リカバリ（再起動）回数などをタスク情報として収集している。

リソース情報収集プログラム１２２は、リソース登録情報に基づいてシステム上のプログラムが使用するシステム上のリソースの状態をリソース情報として定周期に収集するプログラムである。図７は、自ノード情報収集部１２で収集されたリソース情報の具体例を示す図である。ここでは、セマフォ（排他ロックキー）とメッセージに関する情報が収集されている。図７（ａ）は、セマフォに関する収集情報であり、データ項目にセマフォ登録キー名、ＯＳキー名、操作時間（排他時間）、セマフォ操作時間（閾値）、最終使用プロセスＩＤ、異常時の最終使用プロセスＩＤなどが含まれている。図７（ｂ）は、メッセージに関する収集情報であり、データ項目にメッセージ登録キー名、ＯＳキー名、メッセージ数、メッセージ数（閾値）、最終使用プロセスＩＤ、異常時の最終使用プロセスＩＤなどが含まれている。

ハードウェア情報収集プログラム１２３は、ハードウェア登録情報に基づいてシステム上のハードウェアの状態を定周期で収集するプログラムである。図８は、自ノード情報収集部１２で収集されたハードウェア情報の具体例を示す図である。ここでは、ＣＰＵ使用率、メモリ使用量、監視周期、ハードウェアの温度、ハードディスク状態、ファン状態、電源状態、およびＬＡＮ状態に加えて、各項目の最終異常発生時刻などが収集されている。

自ノード情報判定部１３は、自ノード情報収集部１２で収集された自ノード情報から自ノードの稼働状態の正常／異常を判定し、稼働監視情報を生成するプログラムである。自ノード情報判定部１３においては、タスク情報、リソース情報、およびハードウェア情報の各々について異常値の有無の判定が行われ、タスク監視情報、リソース監視情報、およびハードウェア監視情報からなる稼働監視情報を作成する。この稼働監視情報は記憶部１１に格納され、定周期で更新が行われる。

図９は、稼働監視情報に含まれるタスク監視情報の具体例を示す図である。ここでは、上述したタスク情報に含まれる項目に対しての判定結果（異常フラグ）が付加されたタスク監視情報が示されている。

図１０は、稼働監視情報に含まれるリソース監視情報の具体例を示す図である。図１０（ａ）では、上述したリソース情報（セマフォ）内の項目に対する判定結果が付加されたリソース監視情報が示されている。同様に、図１０（ｂ）では上述したリソース情報（メッセージ）内の項目に対しての判定結果が付加されたリソース監視情報が示されている。

図１１は、稼働監視情報に含まれるハードウェア監視情報の具体例を示す図である。ここでは、上述したハードウェア情報に含まれる項目に対しての判定結果が付加されたハードウェア監視情報が示されている。

表示部１４は、自ノード情報判定部１３や他ノード情報判定部１７から出力される判定結果を表示する表示装置である。

送信部１５は、自ノード情報収集部１２で作成された稼動監視情報を他のノード１に対して送信する送信装置である。稼動監視情報の送信処理においては、自ノードにおける異常の有無やタイマーに基づいて送信すべきか否かの判定が行われる。また、タスクやリソースの情報はノード１の各々で異なる場合があるため、送信部１５ではタスク名などの固定的な情報（以下、「固定情報」という。）と、タスクのメモリ使用量などの可変する情報（以下、「可変情報」という。）に分類して送信処理を行う。分類のルールは任意に変更可能である。各送信データは、予め定められた送信データのフォーマットの相違によって識別される。

更に、各ノード１における処理の負荷を軽減するために、伝送するデータをある特定のデータブロックサイズに分割して送受信を行い、各データブロックの処理が完了したら逐次CPUを開放すると好適である。

受信部１６は、他のノード１から送信される稼動監視情報を受信する受信装置である。

他ノード情報判定部１７は、受信部１６で受信された他のノード１の稼動監視情報から他のノード１の稼動状態を判定するプログラムである。他のノード１において異常が検出されている場合には、自ノードを制御する制御部（図示省略する）へ通知する。尚、通知後の動作は、異常の検出内容などに応じて実装することができる。

以下、ノード稼働監視システムを構成する各ノード１内の動作を図面を用いて説明する。

図１２は、自ノード情報収集部１２における収集処理の具体例を示すフローチャートである。

Ｓ１２０１においては、記憶部１１からタスク登録情報を取得し、このタスク登録情報に基づいてタスク情報を収集する。

Ｓ１２０２においては、記憶部１１からリソース登録情報を取得し、リソース登録情報に基づいてセマフォおよびメッセージに関するリソース情報を収集する。

Ｓ１２０３においては、記憶部１１からハードウェア登録情報を取得し、ハードウェア登録情報に基づいてハードウェア情報を収集する。

Ｓ１２０４においては、タスク情報、リソース情報、およびハードウェア情報からなる自ノード情報を自ノード情報判定部１３へ出力し、処理を終了する。

図１３は、自ノード情報判定部１３における判定処理の具体例を示すフローチャートである。

Ｓ１３０１においては、自ノード情報収集部１２から出力されたタスク情報の解析によってタスクに関する異常項目の有無を判定し、この判定結果を含むタスク監視情報を作成する（タスク情報判定処理）。

Ｓ１３０２においては、自ノード情報収集部１２から出力されたリソース情報の解析によってリソースに関する異常項目の有無を判定し、この判定結果を含むリソース監視情報を作成する（リソース情報判定処理）。

Ｓ１３０３においては、自ノード情報収集部１２から出力されたハードウェア情報の解析によってハードウェアに関する異常項目の有無を判定し、この判定結果を含むハードウェア監視情報を作成する（ハードウェア情報判定処理）。

Ｓ１３０４においては、タスク監視情報、リソース監視情報、およびハードウェア監視情報からなる稼働監視情報を作成する。

Ｓ１３０５においては、稼働監視情報内に異常項目の情報が含まれているか否かを判定する。ここで、異常有りと判定された場合には、Ｓ１３０６へ進む。これに対し、異常無しと判定された場合には、処理を終了する。

Ｓ１３０６においては、制御部（図示省略する）に異常を出力し、処理を終了する。

図１４は、図１３のタスク情報判定処理の具体例を示すフローチャートである。

Ｓ１４０１においては、タスク判定数（変数）を初期化する。

Ｓ１４０２においては、タスク判定数がタスク登録数以下であるか判定を行う。ここで、タスク判定数がタスク情報に含まれるタスク登録数以下と判定された場合には、Ｓ１４０３へ進む。これに対し、タスク判定数がタスク登録数を超えると判定された場合には、全ての登録タスクに対する処理が終了しているのでＳ１４１１へ進む。

Ｓ１４０３においては、タスク情報から判定対象となるタスクの情報を取得する。

Ｓ１４０４においては、タスクのメモリ使用量が閾値（アラート・アラーム）以上か否かを判定する。ここで、タスクのメモリ使用量が閾値以上と判定された場合には、Ｓ１４０５に進む。これに対し、タスクのメモリ使用量が閾値未満と判定された場合には、Ｓ１４０６へ進む。

Ｓ１４０５においては、タスク監視情報にメモリ使用状態の異常を記録すると共に異常コマンドを発行する。

Ｓ１４０６においては、タスクのヘルシーカウンタが閾値（アラート・アラーム）以上か否かを判定する。本実施形態では、ヘルシーカウンタは、ヘルシー（ハートビート）値を一定間隔で記録した際に前回値より増加していないことを条件に加算される。したがって、ヘルシーカウンタが閾値以上となることは、プログラムが異常によって停止したことを示す。ここで、タスクのヘルシーカウンタが閾値以上と判定された場合には、Ｓ１４０７に進む。これに対し、タスクのヘルシーカウンタが閾値未満と判定された場合には、Ｓ１４０８へ進む。

Ｓ１４０７においては、タスク監視情報にヘルシー値の状態の異常を記録すると共に異常コマンドを発行する。

Ｓ１４０８においては、タスクの再起動回数が閾値（アラート・アラーム）以上か否かを判定する。本実施形態では、タスクに異常が生じた場合には全処理を終了するのではなく、タスクの再起動（リカバリ）が所定の回数行われる。すなわち、閾値は再起動の最大試行回数を示す。ここで、タスクの再起動回数が閾値以上と判定された場合には、Ｓ１４０９に進む。これに対し、タスクの再起動回数が閾値未満と判定された場合には、Ｓ１４０１０へ進む。

Ｓ１４０９においては、タスク監視情報にタスクの再起動状態の異常を記録すると共に異常コマンドを発行する。

Ｓ１４１０においては、タスク判定数を加算し、Ｓ１４０２へ戻る。Ｓ１４０２〜Ｓ１４１０の処理は登録された全てのタスクの判定処理が終了されるまで繰り返される。

Ｓ１４１１においては、タスク監視情報を出力し、処理を終了する。

図１５は、図１３のリソース情報判定処理の具体例の具体例を示すフローチャートである。

Ｓ１５０１においては、セマフォ判定数（変数）を初期化する。

Ｓ１５０２においては、セマフォ判定数がリソース情報（セマフォ）に含まれるセマフォの登録数（以下、「セマフォ登録数」という。）以下であるか判定を行う。ここで、セマフォ判定数がセマフォ登録数以下と判定された場合には、Ｓ１５０３へ進む。これに対し、セマフォ判定数がセマフォ登録数を超えると判定された場合には、全ての登録セマフォに対する処理が終了しているのでＳ１５０７へ進む。

Ｓ１５０３においては、リソース情報から判定対象となるセマフォの情報を取得する。

Ｓ１５０４においては、セマフォ操作時間が閾値（アラート・アラーム）以上か否かを判定する。セマフォ操作時間は、タスクがリソースの排他制御を行っている時間であり、この時間が閾値以上となることは、リソースが解放されていないことを示す。ここで、セマフォ操作時間が閾値以上と判定された場合には、Ｓ１５０５に進む。これに対し、セマフォ操作時間が閾値未満と判定された場合には、Ｓ１５０６へ進む。

Ｓ１５０５においては、リソース監視情報にセマフォ操作時間の異常を記録すると共に異常コマンドを発行する。

Ｓ１５０６においては、セマフォ判定数を加算し、Ｓ１５０２へ戻る。Ｓ１５０２〜Ｓ１５０６の処理は登録された全てのセマフォの判定処理が終了されるまで繰り返される。

Ｓ１５０７においては、メッセージ判定数（変数）を初期化する。

Ｓ１５０８においては、メッセージ判定数がリソース情報（メッセージ）に含まれるメッセージの登録数（以下、「メッセージ登録数」という。）以下であるか判定を行う。ここで、メッセージ判定数がメッセージ登録数以下と判定された場合には、Ｓ１５０９へ進む。これに対し、メッセージ判定数がメッセージ登録数を超えると判定された場合には、全ての登録メッセージに対する処理が終了しているのでＳ１５１３へ進む。

Ｓ１５０９においては、リソース情報から判定対象となるメッセージの情報を取得する。

Ｓ１５１０においては、メッセージ数が閾値（アラート・アラーム）以上か否かを判定する。メッセージ数は、プロセス間で扱うメッセージ（データ）の数を示す。ここで、メッセージ数が閾値以上と判定された場合には、Ｓ１５１１に進む。これに対し、メッセージ数が閾値未満と判定された場合には、Ｓ１５１２へ進む。

Ｓ１５１１においては、リソース監視情報にメッセージ数の異常を記録すると共に異常コマンドを発行する。

Ｓ１５１２においては、メッセージ判定数を加算し、Ｓ１５０８へ戻る。Ｓ１５０８〜Ｓ１５１２の処理は登録された全てのメッセージの判定処理が終了されるまで繰り返される。

Ｓ１５１３においては、リソース監視情報を出力し、処理を終了する。

図１６は、図１３のハードウェア情報判定処理の具体例を示すフローチャートである。

Ｓ１６０１においては、装置の温度が閾値以上か否か判定される。ここで、装置温度が閾値以上と判定された場合には、Ｓ１６０２へ進む。これに対し、装置温度が閾値未満と判定された場合には、Ｓ１６０３へ進む。

Ｓ１６０２においては、ハードウェア監視情報に装置温度の異常を記録すると共に異常コマンドを発行する。

Ｓ１６０３においては、ハードディスク状態が異常か否か判定される。ここで、ハードディスク状態が異常と判定された場合には、Ｓ１６０４へ進む。これに対し、ハードディスク状態が正常と判定された場合には、Ｓ１６０５へ進む。

Ｓ１６０４においては、ハードウェア監視情報にハードディスク状態の異常を記録すると共に異常コマンドを発行する。

Ｓ１６０５においては、ＬＡＮ状態が異常か否か判定される。ここで、ＬＡＮ状態が異常と判定された場合には、Ｓ１６０６へ進む。これに対し、ＬＡＮ状態が正常と判定された場合には、Ｓ１６０７へ進む。

Ｓ１６０６においては、ハードウェア監視情報にＬＡＮ状態の異常を記録すると共に異常コマンドを発行する。

Ｓ１６０７においては、ファン状態が異常か否か判定される。ここで、ファン状態が異常と判定された場合には、Ｓ１６０８へ進む。これに対し、ファン状態が正常と判定された場合には、Ｓ１６０９へ進む。

Ｓ１６０８においては、ハードウェア監視情報にファン状態の異常を記録すると共に異常コマンドを発行する。

Ｓ１６０９においては、ハードウェア監視情報を出力し、処理を終了する。

図１７は、送信部１５における処理の具体例を示すフローチャートである。

Ｓ１７０１においては、自ノード情報判定部１３から出力された稼働監視情報の有無を判定する。ここで、稼働監視情報有りと判定された場合には、Ｓ１７０２へ進む。これに対し、稼働監視情報無しと判定された場合には、処理を終了する。

Ｓ１７０２においては、初回起動時か否かの判定を行う。ここで、初回起動時と判定された場合には、Ｓ１７０８へ進む。

Ｓ１７０３においては、記憶部１１内の登録情報の更新の有無を判定する。ここで、登録情報の更新有りと判定された場合には、Ｓ１７０８へ進む。これに対し、登録情報の更新無しと判定された場合には、Ｓ１７０４へ進む。

Ｓ１７０４においては、記憶部１１内の稼働監視情報の更新の有無を判定する。ここで、稼働監視情報の更新有りと判定された場合には、Ｓ１７０７へ進む。これに対し、稼働監視情報の更新無しと判定された場合には、Ｓ１７０５へ進む。

Ｓ１７０５においては、稼働監視情報の中に異常判定がなされた項目が含まれるか否かを判定する。ここで、異常項目有りと判定された場合には、Ｓ１７０７へ進む。これに対し、異常項目無しと判定された場合には、Ｓ１７０６へ進む。

Ｓ１７０６においては、現時刻が定周期の送信タイミングか否かを判定する。ここで、定周期の送信タイミングであると判定された場合には、Ｓ１７０７へ進む。これに対し、定周期の送信タイミングではないと判定された場合には、処理を終了する。

Ｓ１７０７においては、タスクのメモリ使用量や異常発生情報などの可変情報のみを他のノード１へ送信し、処理を終了する。

Ｓ１７０８においては、タスク名などの固定情報および可変情報を他のノード１へ送信し、処理を終了する。

図１８は、受信部１６における処理の具体例を示すフローチャートである。

Ｓ１８０１においては、他のノード１からの受信情報の有無を判定する。ここで、受信情報有りと判定された場合には、Ｓ１８０２へ進む。これに対し、受信情報無しと判定された場合には、処理を終了する。

Ｓ１８０２においては、受信情報が稼働監視情報か否かを判定する。ここで、受信情報が稼働監視情報であると判定された場合には、Ｓ１８０３へ進む。これに対し、受信情報が稼働監視情報でないと判定された場合には、処理を終了する。

Ｓ１８０３においては、受信された稼働監視情報を他ノード情報判定部１７へ出力し処理を終了する。

図１９は、他ノード情報判定部１７における処理の具体例を示すフローチャートである。

Ｓ１９０１においては、受信部１６から出力された稼働監視情報の有無を判定する。ここで、稼働監視情報有りと判定された場合には、Ｓ１９０２へ進む。これに対し、稼働監視情報無しと判定された場合には、処理を終了する。

Ｓ１９０２においては、他のノード１における稼働監視情報を解析し、異常が検出されているか否かを判定する。ここで、他のノード１において異常が検出されていると判定された場合には、Ｓ１９０３へ進む。これに対し、異常無しと判定された場合には、処理を終了する。

Ｓ１９０３においては、制御部（図示省略する）に対して他のノード１における異常を出力し、処理を終了する。尚、制御部では異常通知を受けて表示部１４への表示指令等が行われる。

このように構成することにより、ネットワーク２上の全てのノード１において他のノード１の稼働状態が取得され、共有可能となる。

また、様々なシステムに適用可能な利点がある。図２０は、本実施形態に係るノード稼働監視システムの適用例を示すブロック図である。ここでは、ノードＡとノードＢがサーバーであり、ノードＡをマスタ、ノードＢをスレーブとしてホットスタンバイの状態にある。また、ノードＣ、Ｄ、Ｅ、ＦはノードＡのクライアント端末である。ここで、ノードＢで異常が発生した場合には、その稼働監視情報が他のノード（Ａ、Ｃ、Ｄ、Ｅ、Ｆ）に通知される。これにより、ノードＢがノードＡの代わりを出来ない状態にあることをノードＡが正常に稼働している間に他のノード１において知ることが出来るので、システム全体が異常となる前段階で対応することができ、システム全体の信頼性が向上する。

更に、データを固定情報と可変情報に分類し、異なるタイミングで送信する仕組みを有するため、データ送信を効率的に行える。

（実施形態２）
図２１は、本発明の実施形態２に係るノード稼働監視システムの全体構成例を示すブロック図である。本実施形態に係るノード稼働監視システムは、実施形態１に機能代行部１８を加えた構成を有する。尚、図１と共通する符号は同一物を示すので説明を省略し、相違点についてのみ説明する。

機能代行部１８は、他ノード情報判定部１７の判定結果に基づいて他のノード１が実行していた機能の代行処理を行うプログラムである。

図２２は、機能代行部１８における機能代行処理の具体例を示すフローチャートである。

Ｓ２２０１においては、他のノード１からの稼働監視情報の有無を判定する。ここで、稼働監視情報有りと判定された場合には、Ｓ２２０２へ進む。これに対し、稼働監視情報無しと判定された場合には、処理を終了する。

Ｓ２２０２においては、他ノード情報判定部１７から該当する稼働監視情報を読込む。

Ｓ２２０３においては、稼働監視情報が他のノード１の異常発生情報を含むか否かを判定する。ここで、異常発生情報を含むと判定された場合には、Ｓ２２０４へ進む。これに対し、異常発生情報を含まないと判定された場合には、処理を終了する。

Ｓ２２０４においては、異常発生情報に係るノードの機能代行処理が未実施か否かを判定する。ここで、機能代行処理が未実施であると判定された場合には、Ｓ２２０５へ進む。これに対し、機能代行処理が実施中であると判定された場合には、処理を終了する。

Ｓ２２０５においては、自ノードにおいて異常情報に係るノード１の機能代行が必要か否かを判定する。ここで、機能代行が必要と判定された場合には、Ｓ２２０６へ進む。これに対し、機能代行の必要が無いと判定された場合には、処理を終了する。

Ｓ２２０６においては、機能代行プログラムを実行する。

Ｓ２２０７においては、他のノード１に対する機能代行プログラムの実行情報の送信要求を送信部１５へ出力し、処理を終了する。

尚、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。また、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

例えば、組込み型のボード型装置（コンピュータ上のボードや、各種遠隔保守を必要とする監視対象に接続するための遠隔監視用のボード型装置など）をノード１として実装しても良い。この場合、Ｎ台で構成されるネットワーク上のボード型装置自体が他のボード型装置の状態を相互に監視することが可能になる。また、センターにあるサーバとのデータ伝送が出来なくても、ボード型装置が他のボード型装置の稼動監視状態に応じて自立的な処理を実現することが可能になる。Ｎ台の稼動監視状態を取得する場合には、ボード型装置上でアプリケーションを起動させるだけでＮ台全ての稼動監視ができる。これにより、容易にＮ台全ての遠隔監視を実現することが可能になる。

また、ノード１は計測センサー（例えば、流量計、濃度計、水位計等）でも良い。複数台の計測センサーをＩＰｖ６ネットワーク接続して実装することにより、計測センサーが他の計測センサーの状態を相互に監視することが可能になる。すなわち、ある計測センサーが故障しても、他の計測センサーが必要に応じて自立的にバックアップすることが可能になる。Ｎ台の計測センサーの稼動監視状態を取得する場合には、各ノード１においてアプリケーションを起動させるだけでＮ台全ての稼動監視ができる。

更に、複数個の装置から構成され、原則的に停止することが許されない制御装置（例えば、酸素製造装置、生命維持装置等）にも適用可能である。例えば、複数の酸素製造装置を無線ＬＡＮやＩＰｖ６ネットワークで接続して構成される総合酸素製造装置において個々の装置が故障した場合には、故障した装置が行っていた仕事量（酸素の製造量）を故障していない他の装置が分担して製造することで、予め設定された酸素製造量の総量を自動的に維持することが可能になる。尚、稼動状態が正常な各装置が負担する仕事量は、装置の処理能力や台数などに応じた演算式などによって任意に定めることができる。

本発明の実施形態１に係るノード稼働監視システムの全体構成例を示すブロック図。本発明の実施形態１に係るタスク登録情報の具体例を示す図。本発明の実施形態１に係るリソース登録情報の具体例を示す図。本発明の実施形態１に係るハードウェア登録情報の具体例を示す図。本発明の実施形態１に係る自ノード情報収集部１２における情報収集処理を説明する図。本発明の実施形態１に係る自ノード情報収集部１２で収集されたタスク情報の具体例を示す図。本発明の実施形態１に係る自ノード情報収集部１２で収集されたリソース情報の具体例を示す図。本発明の実施形態１に係る自ノード情報収集部１２で収集されたハードウェア情報の具体例を示す図。本発明の実施形態１に係る稼働監視情報に含まれるタスク監視情報の具体例を示す図。本発明の実施形態１に係る稼働監視情報に含まれるリソース監視情報の具体例を示す図。本発明の実施形態１に係る稼働監視情報に含まれるハードウェア監視情報の具体例を示す図。本発明の実施形態１に係る自ノード情報収集部１２における収集処理の具体例を示すフローチャート。本発明の実施形態１に係る自ノード情報判定部１３における判定処理の具体例を示すフローチャート。図１３のタスク情報判定処理の具体例を示すフローチャート。図１３のリソース情報判定処理の具体例の具体例を示すフローチャート。図１３のハードウェア情報判定処理の具体例を示すフローチャート。本発明の実施形態１に係る送信部１５における処理の具体例を示すフローチャート。本発明の実施形態１に係る受信部１６における処理の具体例を示すフローチャート。本発明の実施形態１に係る他ノード情報判定部１７における処理の具体例を示すフローチャート。本発明の実施形態１に係るノード稼働監視システムの適用例を示すブロック図。本発明の実施形態２に係るノード稼働監視システムの全体構成例を示すブロック図。本発明の実施形態２に係る機能代行部１８における機能代行処理の具体例を示すフローチャート。

符号の説明

１…ノード、
２…ネットワーク、
１１…記憶部、
１２…自ノード情報収集部、
１３…自ノード情報判定部、
１４…表示部、
１５…送信部、
１６…受信部、
１７…他ノード情報判定部、
１８…機能代行部、
１２１…タスク情報収集プログラム、
１２２…リソース情報収集プログラム、
１２３…ハードウェア情報収集プログラム。

Claims

ネットワークに接続された複数のノードの各々が、
タスク情報、リソース情報、およびハードウェア情報を含む自ノード情報を収集する自ノード情報収集部と、
この自ノード情報収集部において収集された前記自ノード情報を解析して前記ノードの稼働状態を判定し、この判定結果を含む稼働監視情報を出力する自ノード情報判定部と、
この自ノード情報判定部において前記稼働状態が異常と判定された場合に、前記出力された稼働監視情報を前記ネットワーク上の他のノードへ送信する送信部と、
前記他のノードに係る前記送信部から送信された他の稼働監視情報を受信する受信部と、
この受信部において受信された前記他の稼働監視情報に基づいて前記他のノードの稼働状態を判定する他ノード情報判定部と、
を有することを特徴とするノード稼働監視システム。
前記ノードが、前記他ノード情報判定部において前記他のノードの稼働状態が異常と判定された場合に、前記他の稼働監視情報に基づいて前記他のノードが担当していた機能を代行する機能代行部を更に有することを特徴とする請求項１記載のノード稼働監視システム。
前記機能代行部は、前記稼働状態が異常のノードが担当していた機能を前記稼働状態が正常な他のノードの数および処理能力に応じて算出される負担分について代行することを特徴とする請求項１および請求項２記載のノード稼働監視システム。
ネットワークに接続された複数のノードの各々が、全ノードの稼働監視情報を共有するノード稼働監視方法であって、
前記ノードが、タスク情報、リソース情報、およびハードウェア情報を含む自ノード情報を収集する自ノード情報収集ステップと、
前記ノードが、前記自ノード情報収集ステップにおいて収集された前記自ノード情報を解析して前記ノードの稼働状態を判定し、この判定結果を含む稼働監視情報を出力する自ノード情報判定ステップと、
この自ノード情報判定ステップにおいて前記稼働状態が異常と判定された場合に、前記ノードが、前記出力された稼働監視情報を前記ネットワーク上の他のノードへ送信する送信ステップと、
前記ノードが、前記他のノードから送信された他の稼働監視情報を受信する受信ステップと、
前記ノードが、前記受信ステップにおいて受信された前記他の稼働監視情報に基づいて前記他のノードの稼働状態を判定する他ノード情報判定ステップと、
を有することを特徴とするノード稼働監視方法。
前記他ノード情報判定ステップにおいて前記他のノードの稼働状態が異常と判定された場合に、前記ノードが、前記他の稼働監視情報に基づいて前記他のノードが担当していた機能を代行する機能代行ステップを更に有することを特徴とする請求項４記載のノード稼働監視方法。