JPH11143843A - 複数ノード構成システムの稼働状態管理方法 - Google Patents

Abstract

(57)【要約】 【課題】ネットワークで接続された複数ノードで構成さ
れるシステムにおいて、システム内のいかなるノードも
停止することなくノードの増減が自由に行え、かつノー
ド数の多少に関わらず通信で使用するソケットを最小限
の数だけ使用し、全ノードの稼働情報を収集および伝達
できる方法を提供すること。 【解決手段】同一ポート番号を使用したソケットを確保
しているプロセスに対して、ブロードキャスト機能を使
用することによりメッセージを送信する。このメッセー
ジは応答の返却先アドレスを含んでおり、メッセージを
受信したプロセスは、この返却先アドレスに応答を送信
する。このため、非コネクション型の通信を行うＵＣＰ
／ＩＰソケットを使用する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のノードから
構成されるシステムにおいて、各ノードの稼働状態を伝
達および収集する管理に関する。

【０００２】

【従来の技術】クライアント／サーバ型のシステムで
は、ユーザの所有するデータ量が大規模である場合に
は、各ノードをネットワークで相互接続した複数のノー
ドにデータを分散して配置したシステム（以下、並列シ
ステム）となることがある。並列システムにおいて大き
なスループットと迅速なターンアラウンドを実現するた
めには、例えば各ノード間で通信を行い、必要なデータ
のやりとりを行わなければならない。つまり、複数のノ
ードにデータが分散している場合には、並列システム内
の各ノードが稼働中であるのかを全てのノードが認識し
ていないと、クライアントからの要求を迅速に処理する
ことが出来なくなってしまう。そこで、システム内のあ
る１つのノードを、システム全体の状態を管理するノー
ド（以下、システム管理ノード）として位置づけ、その
他のノードは必要に応じてシステム管理ノードと通信を
行い、メッセージをやりとりすることによって各ノード
の稼働状態を把握することが従来行われている。このと
き、システム管理ノードとの通信は、障害の発生したノ
ードを検知するため、およびメッセージの再送を自動的
に行ってもらうため、例えばＴＣＰ／ＩＰ通信方式のよ
うに、コネクション型の通信を使用している。この方式
では、システム管理ノードが全てのノードの稼働状態を
常に把握しておかねばならないが、これを実現するため
には、システム管理ノードが一定時間毎にその他のノー
ドと連絡を取り合う機能と、新たに稼働し始めた、また
は障害などから復帰したノードがその旨システム管理ノ
ードへ連絡する機能の２つが必要である。

【０００３】図１は従来システムの構成図であり、シス
テム管理ノード７とその他のノード８、９、１０がネッ
トワーク１で接続されている。各ノードには、分散して
配置されたデータを保持するデータベース１１、１２、
１３、１４があり、また各ノードごとに保有している現
在稼働中のノードの情報を、１９、２０、２１、２２に
システム稼働情報として保持している。システム管理ノ
ードにはシステム管理プロセス１５が、その他のノード
には連絡プロセス１６、１７、１８が動作中であり、こ
れらのプロセスはＴＣＰ／ＩＰプロトコルを使用して相
互に通信を行うためのソケット３２、３３、３４、３５
をそれぞれ保有している。なお、相互に通信を行うため
に、２３、２４、２５、２６に示すシステム環境情報と
して、システム管理プロセスおよび連絡プロセスが接続
要求を受信するために使用するソケットのポート番号
や、システム管理ノードのノード名は、全てのノードが
保有していなければならない。また、システム管理ノー
ドだけは、２７に示すシステム構成情報として、システ
ムを構成する全てのノード名を認識していなければなら
ない。

【０００４】図２は、各ノードの稼働状態収集および伝
達処理のアルゴリズムを示すものであり、まずシステム
管理プロセスおよび連絡プロセスは、Ｓ２０１、Ｓ２１
１にて他ノードからの接続受信用ソケットを作成する。
そしてシステム管理プロセスは、一定の時間Ｓ２０２で
示す連絡プロセスからの接続を待つ。連絡プロセスはシ
ステム管理プロセスとの連絡用ソケットを確保し、Ｓ２
１２で示すシステム管理プロセスとの接続が完了した後
に、自ノードの構成および稼働状態をメッセージとし
て、Ｓ２１３にてシステム管理プロセスに送信する。シ
ステム管理プロセスは、Ｓ２０３にてこのメッセージを
受け取り、現在稼働中のノードの状態情報を更新した上
で、システム稼働情報を応答としてＳ２０４にて送信す
る。連絡プロセスでは、Ｓ２１４にて応答受信後、自ノ
ードのシステム稼働情報を更新し、システム管理プロセ
スからの定期的な連絡に備えて、Ｓ２１５にてシステム
管理プロセスからの連絡を待つ。システム管理プロセス
は、監視待ち時間が経過する間の接続待ち状態を経て、
現在稼働中のノードの状態を再確認するための連絡を行
うため、現在のシステム稼働情報をＳ２０５で連絡プロ
セスに送信し、Ｓ２０６で連絡プロセスからの応答を待
つ。連絡プロセスは、Ｓ２１５でシステム管理プロセス
からのメッセージを受信し、自ノードが記憶しているシ
ステム稼働情報を更新した後、自ノードが稼働中である
ことを報告するため、Ｓ２１６にて応答を送信する。シ
ステム管理プロセスでは、Ｓ２０６で連絡プロセスから
の稼働中である旨の応答を受け取った後に、別のノード
の連絡プロセスと稼働状態を確認するための連絡を行
う。この定期的な連絡は、現在稼働中である全てのノー
ドに対して行われる。

【０００５】図３は、システム管理ノードのみが何らか
の要因で一旦停止した後に再起動した直後の、各ノード
の稼働状態収集処理のアルゴリズムを示すものである。
まず、システム管理プロセスは他のノードからの接続受
信用ソケットを作成し、Ｓ３０１でシステム環境情報か
らシステムを構成する全てのノードを求める。そして、
システム内の各ノードの稼働状態を収集するため、Ｓ３
０２で連絡用ソケットを作成し、Ｓ３０３でノード名と
ポート番号から連絡プロセスの接続受信用ソケットのア
ドレスを求め、Ｓ３０４で接続要求を行う。連絡プロセ
スでは、システム管理プロセスからの接続要求を受け
て、Ｓ３２１で連絡用ソケットを作成する。システム管
理プロセスはＳ３０５で稼働状態確認のためのメッセー
ジを送信し、連絡プロセスはＳ３２２でメッセージを受
信した後、Ｓ３２３で自ノードが稼働中であることを応
答として送信する。システム管理プロセスはＳ３０６で
応答を受信し、該当ノードが稼働中である旨システム稼
働情報を更新する。またシステム管理プロセスは、連絡
プロセスとの接続に失敗したり、メッセージの送信に失
敗した場合には、該当ノードが非稼働中であるとして。
Ｓ３０７でシステム稼働情報を更新する。その後はＳ３
０２に戻って、システムを構成する全てのノードに対し
て稼働情報の収集を行う。そして、全てのノードの稼働
情報の収集が完了した後は、図２に示す通常時の稼働情
報収集および伝達処理に戻る。

【０００６】従来は以上のアルゴリズムによって、シス
テム管理ノードおよびその他のノードで、システム内の
稼働中のノードに関する情報を、各ノード毎に保有して
いた。しかし実際には、システム全体を起動する際やノ
ードに障害が発生した直後には、監視待ち時間の間だけ
各ノードで記憶しているシステム稼働情報が不一致とな
るが、一般的に監視待ち時間は数秒から数十秒程度であ
り、各ノードで記憶しているシステム稼働情報が不一致
であることが、システム全体の稼働に大きな影響を及ぼ
さない。

【０００７】

【発明が解決しようとする課題】しかしながら、システ
ム管理ノードが障害が原因で停止した場合、システム管
理ノード再起動後にシステム管理プロセスはシステム稼
働情報を再作成する必要があるため、他ノードに稼働状
態を確認しなければならない。この時、停止直前までの
システム稼働情報が失われているので、前回システム管
理ノードが稼働中だったときにどのノードが稼働中であ
ったかがわからず、従ってどのノードにメッセージを送
信して稼働情報を収集すればよいかがわからない。この
ため、システム環境情報にシステムを構成するノードを
記載しておく必要がある。このように、システムを構成
するノードを予め規定してしまうと、それ以外のノード
を新たに追加しようとする場合、システム管理ノードの
停止／再開始が必要になってしまう。

【０００８】そして、システム管理ノードに障害が発生
し早期に回復できなくなった場合、システム管理プロセ
スの機能を交代して実行できるプロセスが他のノードに
はいないため、一旦システム全体を停止し、システム環
境情報に記載したシステム管理ノード名、およびシステ
ム構成情報に記載したシステムを構成するノード名を変
更した後に、システム全体を再度起動しなければならな
い。つまりこの場合も、システムの構成を変更するため
にシステムの停止／再開始が必要になってしまう。

【０００９】また、システム管理プロセスではノード数
分のソケットを確保する必要があり、システム内のノー
ド数が多い場合には、その数も多大な数となってしまう
ことなども問題点である。

【００１０】以上の問題点は、コネクション型の通信を
使用する上で止むを得ない問題点である。

【００１１】そこで本発明は、各ノード間の接続有無や
システム内のノード数の増減および各ノードの稼働を停
止することなく、全ノードの稼働情報を収集および伝達
できることを目的とするものである。

【００１２】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、システム管理プロセスから連絡プロセス
への稼働状態の確認のためのメッセージ送信で、同一ポ
ート番号を使用したソケットを確保しているプロセスに
対して、ブロードキャスト機能を使用することにより、
メッセージを送信する。このブロードキャスト機能を使
用することで、システム内のノード数や各ノードのアド
レスを事前に知ることなく、各ノードの連絡プロセスと
の通信が可能になる。このため、コネクション型の通信
を行うＴＣＰ／ＩＰソケットの使用を止め、非コネクシ
ョン型の通信を行うＵＤＰ／ＩＰソケットを使用し、Ｕ
ＤＰ／ＩＰのブロードキャスト機能を使用する。これに
より、各ノードの連絡プロセスへのシステム稼働情報の
伝達が容易に行えるようになる。また、システム管理プ
ロセスから連絡プロセスへ送信されるメッセージには、
応答の返却先としてシステム管理プロセスが確保してい
るソケットのアドレスを格納する。連絡プロセスは、メ
ッセージ受信後の応答返却ではブロードキャスト機能を
使用せず、システム管理プロセスのみへ応答を返却す
る。このとき、返却先アドレスに自ノードが稼働中であ
る旨応答を返却することにより、システム管理プロセス
が稼働中のノードを認識することができる。

【００１３】システム管理ノードがその他のノードのア
ドレスを認識する必要がないことから、新たなノードを
システム内に組み込む際にもシステム管理ノードの再開
始を行う必要がなく、また予めシステム環境情報に記載
していたシステムを構成するノード名に関する情報が必
要なくなる。

【００１４】さらに、ＵＤＰ／ＩＰソケットを使用する
ことにより、連絡プロセスだけでなくシステム管理プロ
セスでも通信用のソケット数を１つにすることが出来
る。このため、システム内のノード数に関わらず、シス
テム管理プロセスが使用するソケット数が一定となる。

【００１５】

【発明の実施の形態】以下、本発明を実施する場合の一
形態を図面を参照して具体的に説明する。

【００１６】図４は、本発明の実施の一形態であるシス
テムの構成図であり、システム管理ノード４４とその他
のノード４５、４６、４７がネットワーク４１で接続さ
れている。各ノードには分散して配置されたデータを保
持するデータベース４８、４９、５０、５１があり、ま
たシステム稼働情報を伝達／収集するために必要な情報
として、システム環境情報６０、６１、６２、６３が各
ノード毎に配置されている。システム管理ノードにはシ
ステム管理プロセス５２が、その他のノードには連絡プ
ロセス５３、５４、５５が動作中であり、これらのプロ
セスは、ＵＤＰ／ＩＰプロトコルを使用して通信を行う
ためのソケット６４、６５、６６、６７を所有してい
る。なおこのソケットは、各プロセス間で相互に通信を
行うために、システム環境情報に記載しているポート番
号を使用したアドレスとなっている。

【００１７】図５は、各ノードの稼働状態収集及び伝達
処理のアルゴリズムを示すものである。システム管理プ
ロセスおよび連絡プロセスは、Ｓ５０１、Ｓ５２１にて
システム環境情報に記載されているポート番号を使用し
たＵＤＰ／ＩＰソケットを確保する。その後連絡プロセ
スは、Ｓ５２２でシステム管理プロセスからのメッセー
ジを受信するため、待ち状態になる。システム管理プロ
セスでは、Ｓ５０２で連絡プロセスからの応答の送信先
アドレスとして自プロセスが作成したＵＤＰ／ＩＰソケ
ットのアドレスを求め、Ｓ５０３で現在のシステム稼働
情報と応答送信先アドレスを連絡プロセスに引き渡すメ
ッセージとして組み立てる。そして、Ｓ５０４でシステ
ム環境情報に記載されているポート番号を使用したソケ
ットを確保している、他ノードの連絡プロセスに対して
メッセージをブロードキャストする。この時、障害の発
生しているノードおよび通信の途絶えているノードや、
システムを構成していないノードにはメッセージは届か
ない。その後システム管理プロセスは、現在記憶してい
るシステム稼働情報をＳ５０５にて一旦破棄し、Ｓ５０
６にて他ノードからの応答を待つ。連絡プロセスでは、
システム管理プロセスから送信されたメッセージを分解
し、Ｓ５２３で自ノードのシステム稼働情報を更新し、
システム管理プロセスから送信されたメッセージ中に格
納されているシステム管理プロセスのソケットに対し
て、自ノードが稼働中である旨Ｓ５２４で応答を送信す
る。その後連絡プロセスは、次回のシステム管理プロセ
スからのメッセージ送信に備えて、再度Ｓ５２２でメッ
セージ受信待ちになる。システム管理プロセスでは、監
視待ち時時間が経過するまで連絡プロセスからの応答を
待ち、連絡プロセスからの応答が到着した場合にはＳ５
０７でシステム稼働情報を更新する。そして、監視待ち
時間が経過した後に、再度Ｓ５０３に戻って監視のため
のメッセージ送信を行う。

【００１８】図６は、システム内に新たなノードを追加
した場合の動作の説明図である。６０１に示すノード５
を追加した場合、ノード５ではシステム管理プロセスか
らの連絡を受ける前は、６０２で示すように他のノード
の稼働状態を認識していないため自ノードのみ稼働中で
あると認識し、スタンドアロン状態でのサービスのみ可
能な状態である。システム管理プロセスではＵＤＰ／Ｉ
Ｐのブロードキャスト機能を使用してメッセージを送信
しているため、新たに追加されたノードの連絡プロセス
が、他のノードと同じポート番号を使用したソケットを
確保していれば、その連絡プロセスにメッセージを引き
渡すことが出来る。ノード５の連絡プロセスでは、シス
テム管理プロセスからのメッセージを受け取り、自ノー
ド以外の稼働中のノードの情報を得られる。そして、６
０３で示すように自ノードのシステム稼働情報を更新
し、これ以降稼働中の他ノードとのデータのやりとりが
可能になるので、システム内の１つのノードとしてサー
ビスを行うことが出来るようになる。また、ノード５が
稼働中であることをシステム管理プロセスに報告するこ
とにより、６０４で示すようにシステム管理プロセスで
もノード５が稼働中であることを認識する。このノード
５が稼働中である旨のシステム稼働情報は、次の全ノー
ドへの稼働状態確認連絡で通知され、この時点から他ノ
ードでもノード５とのデータのやりとりが可能になる。

【００１９】図７は、システム管理ノード以外のノード
に障害が発生したり、通信経路に障害が発生した場合の
動作の説明図である。システム稼働中に、７０１に示す
ようにノード２との通信経路に障害が発生したり、７０
２に示すようにノード３自身がダウンした等の障害が発
生した場合、これらのノードはシステム管理プロセスか
らの稼働状態確認連絡が途絶えてしまう。このため、そ
の他のノードでは７０３に示すようにノード２およびノ
ード３が稼働中ではないと認識し、システムの稼働を続
行する。その後通信障害の回復やノードの再起動が行わ
れ、システムに復帰できるようになった場合、システム
管理プロセスからの稼働状態確認連絡が回復したノード
にも届くようになるため、７０４で示すように障害から
回復したノードの稼働状態を取得することができる。ま
た、障害から回復したノードが稼働中であることが、シ
ステム管理プロセスを経由して他ノードにも連絡される
ので、７０５で示すようにシステム稼働情報が最新の状
態に更新される。その後は、システム内の全てのノード
間でデータのやりとりが自由に行えるようになる。

【００２０】図８は、システム管理ノードに障害が発生
した場合の動作の説明図である。システム稼働中にシス
テム管理ノードがダウンしても、他のノードはシステム
管理プロセスからの稼働状態確認連絡が途絶えているだ
けであり、稼働中のノードのみでサービスを続行中であ
る。次に、システム管理ノードが復帰してきた場合、シ
ステム管理プロセスからの稼働状態確認連絡が再開する
が、８０１で示すように最初の連絡を行う際にはシステ
ム管理ノードのシステム稼働情報は、他の稼働中のノー
ドの情報が失われてしまっている。このため、最初の稼
働状態確認連絡では、８０２で示すように各ノードが記
憶しているシステム稼働情報を変更しないことをメッセ
ージに記して連絡する。その後システム管理プロセスで
は、稼働中のノードから送信された応答を元に、８０３
に示す新たなシステム稼働情報を作成する。そして、次
回の稼働状態確認連絡で各ノードに通知することによっ
て、全ノードのシステム稼働情報が最新の状態に更新さ
れ、システム内の全てのノード間でデータのやりとりが
自由に行えるようになる。

【００２１】

【発明の効果】以上、説明したように、本発明によれ
ば、管理ノードからシステム内全てのノードへの連絡、
およびシステム内全てのノードから管理ノードへの応答
の返却が、システム内のノードの数やノードアドレスを
意識することなくできるようになるので、ノードの追加
や削除、変更を行う場合にいかなるノードも停止する必
要がない。また、特定ノードにいかなる障害が発生して
も、障害回復後のシステムへの復帰が自動で行えるた
め、システムの保守が容易になる。

【００２２】また、システム管理プロセスが保有するソ
ケット数が少なくて済むので、多数のノードで構成され
るシステムにも耐えられる情報収集／配信方式である。

【図面の簡単な説明】

【図１】従来の機能を使用した形態の概略を示すシステ
ムの構成図。

【図２】従来の機能を使用した、システム管理プロセス
と連絡プロセス間での稼働情報を通信処理フローチャー
ト。

【図３】従来の機能を使用した、システム管理プロセス
再起動直後の稼働情報収集処理フローチャート。

【図４】本発明の一実施の形態の概略を示すシステム構
成図。

【図５】システム管理プロセスと連絡プロセス間での稼
働情報を通信処理フローチャート。

【図６】システム内へのノード追加が発生した例を説明
するための説明図。

【図７】システム管理ノード以外で障害が発生した例を
説明するための説明図。

【図８】システム管理ノードに障害が発生した例を説明
するための説明図。

【符号の説明】

１…ネットワーク、 ２…接続要求の流
れ、３〜６…メッセージ、応答の送受信の流れ、７…シ
ステム管理ノード、８〜１０…システム管理ノード以外
のシステムを構成するノード、１１〜１４…データベー
ス、 １５…システム管理プロセス、１７〜１９…
連絡プロセス、 ２０〜２３…システム稼働情報、
２４〜２７…システム環境情報、 ２８…システム構成
情報、２９〜３２…接続受信用ＴＣＰ／ＩＰソケット、
３３〜３６…相互通信用ＴＣＰ／ＩＰソケット、４１…
ネットワーク、４２…ブロードキャストメッセージの送
受信の流れ、４３…応答の送受信の流れ、 ４４…
システム管理ノード、４５〜４７…システム管理ノード
以外のシステムを構成するノード、４８〜５１…データ
ベース、 ５２…システム管理プロセス、５３〜５
５…連絡プロセス、 ５６〜５９…システム稼働情
報、６０〜６３…システム環境情報、 ６４〜６７…Ｕ
ＤＰ／ＩＰソケット。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 藤久 浩司 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウェアエンジニアリング株式会 社内

Claims (1)

【特許請求の範囲】
1. 【請求項１】各々がネットワークでつながれた複数ノー
   ドで構成されるシステムにおいて、各ノードの稼働情報
   を収集および伝達するために、システム全体を管理する
   プロセスが他ノードのプロセスとの通信で使用する通信
   リソースを、システム内のノード数にかかわらず一定の
   数だけ使用する方法。