特開 2024-158306 システム及びシステムの制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024158306

(43)【公開日】2024-11-08

(54)【発明の名称】システム及びシステムの制御方法

(51)【国際特許分類】

   G06F 11/20 20060101AFI20241031BHJP

【ＦＩ】

G06F11/20 623

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2023073408

(22)【出願日】2023-04-27

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001678

【氏名又は名称】藤央弁理士法人

(72)【発明者】

【氏名】河合 英宏

【テーマコード（参考）】

5B034

【Ｆターム（参考）】

5B034BB11

5B034BB15

(57)【要約】

【課題】スプリットブレインを抑止し、かつ、高い品質のサービスの継続を実現する。
【解決手段】システムは、複数の計算機から構成される基盤システム及び基盤システムと接続するクライアント装置を備える。基盤システムは、リーダノード及び二つ以上のフォロワノードを含むクラスタを構成する。クラスタは、定足数ベースのクラスタ管理アルゴリズムに基づいて管理される。クライアント装置は、リーダノード及びフォロワノードに同一内容の第１メッセージを送信し、リーダノードは、クライアント装置及びフォロワノードに第２メッセージを送信する。フォロワノードは、クライアント装置から第１メッセージを受信した場合、リーダノードに第１メッセージを転送し、リーダノードから第２メッセージを受信した場合、クライアント装置に第２メッセージを転送する。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数の計算機から構成される基盤システム及び前記基盤システムと接続するクライアント装置を備えるシステムであって、
前記基盤システムは、サービスの主系として機能する一つのリーダノード及び前記サービスの待機系として機能する二つ以上のフォロワノードを含むクラスタを構成し、
前記クラスタは、定足数ベースのクラスタ管理アルゴリズムに基づいて管理され、
前記クライアント装置は、前記リーダノード及び少なくとも一つの前記フォロワノードに同一内容の第１メッセージを送信し、
前記リーダノードは、前記クライアント装置からの前記第１メッセージに対する応答として、前記クライアント装置及び少なくとも一つの前記フォロワノードに第２メッセージを送信し、
前記フォロワノードは、
前記クライアント装置から前記第１メッセージを受信した場合、前記リーダノードに前記第１メッセージを転送し、
前記リーダノードから前記第２メッセージを受信した場合、前記クライアント装置に前記第２メッセージを転送することを特徴とするシステム。

【請求項2】

請求項１に記載のシステムであって、
前記リーダノードは、
前記クライアント装置から直接受信する前記第１メッセージの受信時間、及び前記フォロワノードを介して受信する前記第１メッセージの受信時間の差分に基づいて、前記クライアント装置及び前記リーダノードの間の通信経路の通信遅延、並びに、前記クライアント装置及び前記フォロワノードの間の通信経路の通信遅延を評価し、
前記クライアント装置及び前記リーダノードの間の通信経路で通信遅延が発生している場合、前記第１メッセージの受付を停止し、前記サービスの提供を終了する、前記リーダノードの閉塞処理を実行し、
前記クライアント装置及び前記フォロワノードの間の通信経路で通信遅延が発生している場合、前記フォロワノードとしての機能を停止させる前記フォロワノードの閉塞処理を実行することを特徴とするシステム。

【請求項3】

請求項１に記載のシステムであって、
前記リーダノードは、
前記第１メッセージの受信状態を監視し、
前記監視の結果に基づいて、前記クライアント装置から直接前記第１メッセージを受信できているか否かを判定し、
前記クライアント装置から直接前記第１メッセージを受信できていない場合、前記第１メッセージの受付を停止し、前記サービスの提供を終了する、前記リーダノードの閉塞処理を実行することを特徴とするシステム。

【請求項4】

請求項１に記載のシステムであって、
前記リーダノードは、
前記第１メッセージの受信状態を監視し、
前記監視の結果に基づいて、前記フォロワノードが前記第１メッセージを受信できているか否かを判定し、
前記フォロワノードが前記第１メッセージを受信できていない場合、前記フォロワノードとしての機能を停止させる前記フォロワノードの閉塞処理を実行することを特徴とするシステム。

【請求項5】

複数の計算機から構成される基盤システム及び前記基盤システムと接続するクライアント装置を備えるシステムの制御方法であって、
前記基盤システムは、サービスの主系として機能する一つのリーダノード及び前記サービスの待機系として機能する二つ以上のフォロワノードを含むクラスタを構成し、
前記クラスタは、定足数ベースのクラスタ管理アルゴリズムに基づいて管理され、
前記システムの制御方法は、
前記クライアント装置が、前記リーダノード及び少なくとも一つの前記フォロワノードに同一内容の第１メッセージを送信するステップと、
前記フォロワノードが、前記クライアント装置から前記第１メッセージを受信した場合、前記リーダノードに前記第１メッセージを転送するステップと、
前記リーダノードが、前記クライアント装置からの前記第１メッセージに対する応答として、前記クライアント装置及び少なくとも一つの前記フォロワノードに第２メッセージを送信するステップと、
前記フォロワノードが、前記リーダノードから前記第２メッセージを受信した場合、前記クライアント装置に前記第２メッセージを転送するステップと、を含むことを特徴とするシステムの制御方法。

【請求項6】

請求項５に記載のシステムの制御方法であって、
前記リーダノードが、前記クライアント装置から直接受信する前記第１メッセージの受信時間、及び前記フォロワノードを介して受信する前記第１メッセージの受信時間の差分に基づいて、前記クライアント装置及び前記リーダノードの間の通信経路の通信遅延、並びに、前記クライアント装置及び前記フォロワノードの間の通信経路の通信遅延を評価するステップと、
前記クライアント装置及び前記リーダノードの間の通信経路で通信遅延が発生している場合、前記リーダノードが、前記第１メッセージの受付を停止し、前記サービスの提供を終了する、前記リーダノードの閉塞処理を実行するステップと、
前記クライアント装置及び前記フォロワノードの間の通信経路で通信遅延が発生している場合、前記リーダノードが、前記フォロワノードとしての機能を停止させる前記フォロワノードの閉塞処理を実行するステップと、を含むことを特徴とするシステムの制御方法。

【請求項7】

請求項５に記載のシステムの制御方法であって、
前記リーダノードが、前記第１メッセージの受信状態を監視するステップと、
前記リーダノードが、前記監視の結果に基づいて、前記クライアント装置から直接前記第１メッセージを受信できているか否かを判定するステップと、
前記クライアント装置から直接前記第１メッセージを受信できていない場合、前記リーダノードが、前記第１メッセージの受付を停止し、前記サービスの提供を終了する、前記リーダノードの閉塞処理を実行するステップと、を含むことを特徴とするシステムの制御方法。

【請求項8】

請求項５に記載のシステムの制御方法であって、
前記リーダノードが、前記第１メッセージの受信状態を監視するステップと、
前記リーダノードが、前記監視の結果に基づいて、前記フォロワノードが前記第１メッセージを受信できているか否かを判定するステップと、
前記フォロワノードが前記第１メッセージを受信できていない場合、前記リーダノードが、前記フォロワノードとしての機能を停止させる前記フォロワノードの閉塞処理を実行するステップと、を含むことを特徴とするシステムの制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、高い可用性を実現するシステムに関する。

【背景技術】

【0002】

可用性を確保する方法としてクラスタ構成が使用される。クラスタ構成では、一つのノードが主系として稼働し、他のノードが待機系となっている。主系のノードに障害が発生した場合、いずれかの待機系のノードが主系としてサービスを継続する。

【0003】

クラスタ構成では、スプリットブレインが問題となる。スプリットブレインを防止する方法として、例えば、特許文献１に記載の方法が知られている。

【0004】

特許文献１には「第１施設に設置されたコンピュータは、複数の第２施設それぞれに１システムずつ設置された複数の外部システムのいずれとも直接の通信が不通の場合、自システムが孤立状態であると判定する。コンピュータは、複数の外部システムのうち、最終生存確認時刻から所定時間以上経過している第１外部システムについて、停止状態であると判定する。またコンピュータは、複数の外部システムのうち、直接通信が可能な第２外部システムについて、生存状態であると判定する。そしてコンピュータは、最終生存確認時刻から所定時間以上経過しておらず、直接の通信が不通の第３外部システムがある場合、所定の条件に基づいて、自システムと第３外部システムとのうちの一方を停止状態にし、他方を生存状態にすると判定する。」ことが記載されている。

【0005】

特許文献１に記載の技術を用いれば、システムは他のシステムの状態を把握することができるため、スプリットブレインを抑止することができる。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】国際公開第２０１８／０３７５３５号

【発明の概要】

【発明が解決しようとする課題】

【0007】

クライアント装置は、ネットワークを介してシステムと通信することによって、サービスを利用する。主系として稼働するノードとクライアント装置との間の通信に障害が発生した場合、サービスを正しく提供できなくなる。この場合、主系を切り替える必要がある。しかし、特許文献１に記載の技術では前述の課題に対応できない。また、前述の通信経路上でパケットロストや通信遅延が発生した場合、クライアント装置は期待する時間内に応答を受信できない。これは通信の定時性を期待する制御システムにおいて問題となる。

【0008】

本発明は、スプリットブレインを抑止し、かつ、高い品質のサービスの継続を実現するシステムを提供する。

【課題を解決するための手段】

【0009】

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の計算機から構成される基盤システム及び前記基盤システムと接続するクライアント装置を備えるシステムであって、前記基盤システムは、サービスの主系として機能する一つのリーダノード及び前記サービスの待機系として機能する二つ以上のフォロワノードを含むクラスタを構成し、前記クラスタは、定足数ベースのクラスタ管理アルゴリズムに基づいて管理され、前記クライアント装置は、前記リーダノード及び少なくとも一つの前記フォロワノードに同一内容の第１メッセージを送信し、前記リーダノードは、前記クライアント装置からの前記第１メッセージに対する応答として、前記クライアント装置及び少なくとも一つの前記フォロワノードに第２メッセージを送信し、前記フォロワノードは、前記クライアント装置から前記第１メッセージを受信した場合、前記リーダノードに前記第１メッセージを転送し、前記リーダノードから前記第２メッセージを受信した場合、前記クライアント装置に前記第２メッセージを転送する。

【発明の効果】

【0010】

本発明によれば、スプリットブレインを抑止し、かつ、高い品質のサービスの継続を実現できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0011】

【図1】実施例１のシステムの構成の一例を示す図である。

【図2】実施例１の計算機のハードウェアの構成の一例を示す図である。

【図3】実施例１のセッション管理情報のデータ構造の一例を示す図である。

【図4】実施例１のメッセージ管理情報のデータ構造の一例を示す図である。

【図5】実施例１の経路管理情報のデータ構造の一例を示す図である。

【図6】実施例１のクラスタ管理情報のデータ構造の一例を示す図である。

【図7】実施例１のメッセージ管理情報のデータ構造の一例を示す図である。

【図8】実施例１のクライアント装置が実行するメッセージ送信処理の一例を説明するフローチャートである。

【図9A】実施例１のノードが実行するメッセージ受信処理の一例を説明するフローチャートである。

【図9B】実施例１のノードが実行するメッセージ受信処理の一例を説明するフローチャートである。

【図10】実施例１のノードが実行するメッセージ管理情報の更新処理の一例を説明するフローチャートである。

【図11A】実施例１のノードが実行する経路管理情報の更新処理の一例を説明するフローチャートである。

【図11B】実施例１のノードが実行する経路管理情報の更新処理の一例を説明するフローチャートである。

【図12】実施例１のクライアント装置が実行するメッセージ受信処理の一例を説明するフローチャートである。

【図13】実施例２のメッセージ管理情報のデータ構造の一例を示す図である。

【図14】実施例２のノードが実行するメッセージ管理情報の更新処理の一例を説明するフローチャートである。

【発明を実施するための形態】

【0012】

以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

【0013】

以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。

【0014】

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。

【0015】

図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。

【実施例0016】

図１は、実施例１のシステムの構成の一例を示す図である。図２は、実施例１の計算機のハードウェアの構成の一例を示す図である。

【0017】

システムは、基盤システム１００及びクライアント装置１０１から構成される。基盤システム１００及びクライアント装置１０１は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワーク１０２を介して接続される。ネットワーク１０２の接続方式は有線及び無線のいずれでもよい。

【0018】

基盤システム１００は、サービスを提供するためのリソースを提供するシステムであり、複数の計算機２００から構成される。計算機２００は、例えば、プロセッサ２０１、主記憶装置２０２、副記憶装置２０３、及びネットワークインタフェース２０４を有する。

【0019】

以下の説明では、機能部を主語に処理を説明する場合、プロセッサ２０１が当該機能部を実現するプログラムを実行していることを示す。

【0020】

なお、基盤システム１００は、ネットワークスイッチ及びストレージシステムを含んでもよい。

【0021】

基盤システム１００には、サービスを提供する複数のノード１１０が存在する。可用性を確保するために、複数のノード１１０を用いてクラスタが構成される。クラスタに含まれるノード１１０の数は３以上であるものとする。なお、共通の障害点を持たないようにするために、異なる拠点のノード１１０を用いてクラスタを構成することが望ましい。

【0022】

クラスタは、スプリットブレインを抑止するために、ＲＡＦＴ等の定足数ベースのクラスタ管理アルゴリズムに基づいて管理される。クラスタでは、一つのノード１１０がリーダ（主系）として機能し、他のノード１１０はフォロワ（待機系）として機能する。

【0023】

ノード１１０は、サービスを提供するアプリケーションが稼働するインスタンスであり、計算機２００でもよいし、仮想計算機又はコンテナでもよい。ノード１１０は、アプリケーション実行部１２０及び通信管理部１２１を有し、また、セッション管理情報１２３、メッセージ管理情報１２４、及び経路管理情報１２５を保持する。

【0024】

アプリケーション実行部１２０は、サービスを提供するアプリケーションを実行する。通信管理部１２１は、通信の制御を行う。通信管理部１２１は、プロキシ部１３０、クラスタ管理部１３１、多重化通信部１３２、及び通信異常検知部１３３を含む。

【0025】

プロキシ部１３０は、通信の中継を行う。クラスタ管理部１３１は、定足数ベースのクラスタ管理アルゴリズムに基づいてクラスタを管理する。例えば、クラスタ管理部１３１は、ノード１１０の生存監視及びノード１１０の縮退処理を実行する。多重化通信部１３２は、ノード１１０及びクライアント装置１０１間の通信を多重化する。通信異常検知部１３３は、通信の異常を検知する。

【0026】

なお、ノード１１０が有する各機能部については、複数の機能部を一つの機能部にまとめてもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。

【0027】

セッション管理情報１２３は、ノード１１０及びクライアント装置１０１間の通信のセッションを管理するための情報である。メッセージ管理情報１２４は、クライアント装置１０１が送信したメッセージの受信状態を管理するための情報である。経路管理情報１２５は、ノード１１０とクライアント装置１０１との間の通信経路の状態を管理するための情報である。

【0028】

クライアント装置１０１は、サービスを利用する装置である。クライアント装置１０１は、図示しない、プロセッサ、主記憶装置、副記憶装置、ネットワークインタフェース、入力装置、及び出力装置を有する。

【0029】

クライアント装置１０１は、アプリケーション実行部１４０及び通信管理部１４１を有し、また、クラスタ管理情報１４２及びメッセージ管理情報１４３を保持する。

【0030】

アプリケーション実行部１４０は、サービスを利用するためのアプリケーションを実行する。通信管理部１４１は、通信の制御を行う。具体的には、通信管理部１４１は、通信の中継及び通信の多重化を行う。

【0031】

クラスタ管理情報１４２は、クラスタの構成を管理するための情報である。メッセージ管理情報１４３は、ノード１１０が送信したメッセージの受信状態を管理するための情報である。

【0032】

なお、アプリケーション実行部１４０及び通信管理部１４１は、仮想計算機又はコンテナを用いて実現してもよい。

【0033】

図３は、実施例１のセッション管理情報１２３のデータ構造の一例を示す図である。

【0034】

セッション管理情報１２３は、セッションＩＤ３０１、ＤＳ（Ｄｏｗｎｓｔｒｅａｍ）宛先情報３０２、及びＳＳ（Ｓｉｄｅｓｔｒｅａｍ）宛先情報３０３を含むエントリを格納する。一つのセッションに対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

【0035】

セッションＩＤ３０１は、セッションのＩＤを格納するフィールドである。ＤＳ宛先情報３０２は、メッセージ送信元のクライアント装置１０１の宛先情報を格納するフィールドである。ＤＳ宛先情報３０２には、例えば、ＩＰアドレス及びポート番号等が格納される。ＳＳ宛先情報３０３は、メッセージの送信元のノード１１０の宛先情報を格納するフィールドである。ＳＳ宛先情報３０３には、例えば、ＩＰアドレス及びポート番号等が格納される。

【0036】

クライアント装置１０１から受信したメッセージ、及びリーダノード１１０がフォロワノード１１０経由で受信したクライアント装置１０１からのメッセージにはセッションＩＤを含む。このセッションＩＤが初めて見るＩＤだった場合、当該セッションＩＤを持つエントリをセッション管理情報１２３に追加する。また、受信したメッセージがクライアント装置１０１から送信されたものだった場合、同じセッションＩＤを持つエントリのＤＳ宛先情報に当該クライアント装置１０１の宛先情報を記録する。フォロワ経由で受信した場合、同じセッションＩＤを持つエントリのＳＳ宛先情報に当該フォロワノードの宛先情報を記録する。

【0037】

図４は、実施例１のメッセージ管理情報１２４のデータ構造の一例を示す図である。

【0038】

メッセージ管理情報１２４は、セッションＩＤ４０１、通番４０２、直接受信４０３、及び間接受信４０４を含むエントリを格納する。セッションＩＤ及び通番の組みに対して一つのエントリが存在する。

【0039】

セッションＩＤ４０１は、セッションのＩＤを格納するフィールドである。通番４０２は、メッセージに付与される通番を格納するフィールドである。通番はセッション内でメッセージを識別するために用いられる。

【0040】

直接受信４０３は、他のノード１１０を経由することなくクライアント装置１０１から直接メッセージを受信したか否かを示すフラグを格納するフィールドである。初期値として「０」が設定され、直接受信した場合「１」が格納される。間接受信４０４は、他のノード１１０を経由してメッセージを受信したか否かを示すフラグを格納するフィールドである。初期値として「０」が設定され、間接受信した場合「１」が格納される。

【0041】

図５は、実施例１の経路管理情報１２５のデータ構造の一例を示す図である。

【0042】

経路管理情報１２５は、経路５０１、受信時刻５０２、及びカウンタ５０３を含むエントリを格納する。クライアント装置１０１がメッセージを送信するノード１１０に対して一つのエントリが存在する。

【0043】

経路５０１は、クライアント装置１０１及びノード１１０の間の通信経路の識別情報を格納する。「直接」は経路管理情報１２５を保持するノード１１０とクライアント装置１０１との間の通信経路を表す。「間接」は他のノード１１０を経由した、経路管理情報１２５を保持するノード１１０とクライアント装置１０１との間の通信経路を表す。

【0044】

受信時刻５０２は、当該経路において最後に受信したメッセージの受信時刻を格納するフィールドである。カウンタ５０３は、ノード１１０が通信経路を介して送信されるメッセージを受信していない回数を格納するフィールドである。カウンタ５０３には初期値として「０」が設定される。

【0045】

図６は、実施例１のクラスタ管理情報１４２のデータ構造の一例を示す図である。

【0046】

クラスタ管理情報１４２は、クラスタ名６０１、宛先情報６０２、及びタイプ６０３を格納するフィールドである。クラスタ及びノードの組みに対して一つのエントリが存在する。

【0047】

クラスタ名６０１は、クラスタの識別情報を格納するフィールドである。宛先情報６０２は、クラスタに含まれるノード１１０の宛先情報を格納するフィールドである。宛先情報６０２には、例えば、ＩＰアドレス及びポート番号等が格納される。タイプ６０３は、クラスタにおけるノード１１０のタイプを格納するフィールドである。

【0048】

本実施例では、リーダノード１１０と、少なくとも一つのフォロワノード１１０とにメッセージが送信されるようにクラスタ管理情報１４２が設定される。

【0049】

クラスタ管理情報１４２は、予め手動で設定してもよいし、基盤システム１００の利用開始時に基盤システム１００から取得してもよい。また、基盤システム１００は、クラスタの構成が変更された場合、任意のタイミングで更新されたクラスタ管理情報１４２を送信する。

【0050】

図７は、実施例１のメッセージ管理情報１４３のデータ構造の一例を示す図である。

【0051】

メッセージ管理情報１４３は、セッションＩＤ７０１及び通番７０２を含むエントリを格納する。セッションＩＤ及び通番の組みに対して一つのエントリが存在する。

【0052】

セッションＩＤ７０１及び通番７０２は、セッションＩＤ４０１及び通番４０２と同一のフィールドである。

【0053】

図８は、実施例１のクライアント装置１０１が実行するメッセージ送信処理の一例を説明するフローチャートである。

【0054】

クライアント装置１０１の通信管理部１４１は、アプリケーション実行部１４０からノード１１０へのメッセージの送信リクエストの受信を監視する（ステップＳ１０１）。

【0055】

送信リクエストを受信した場合、通信管理部１４１は、クラスタ管理情報１４２を参照して送信先のノード１１０を特定する（ステップＳ１０２）。

【0056】

具体的には、通信管理部１４１は、送信リクエストに含まれるアプリケーションの名称を取得し、クラスタ名６０１にアプリケーションの名称が格納されるエントリを検索する。

【0057】

通信管理部１４１は、リーダノード１１０及び少なくとも一つのフォロワノード１１０に同一のメッセージを送信する（ステップＳ１０３）。その後、通信管理部１４１は、送信リクエストの受信の監視を継続する。

【0058】

このとき、メッセージにはセッションＩＤ及び通番が含まれる。通番は、通信管理部１４１によって決定される。セッションＩＤはクライアント装置１０１上のアプリケーションと、ノード１１０上のアプリケーションの間の一連の送受信を区別するものであり、一連の送受信を開始する際に、固有の値を割り当てる。ここでいう一連の送受信とは、例えばＴＣＰ通信におけるセッションの確立から切断までに相当する。セッションＩＤとしては、例えば送信元ＩＰアドレスとポート番号の組み合わせなどを用い、唯一性を保証することができる。通番はセッションＩＤごと、かつ送受信の方向ごとに管理される通し番号であり、当該セッションＩＤにて新たなメッセージを送信する都度、１ずつ加算していく。

【0059】

図９Ａ及び図９Ｂは、実施例１のノード１１０が実行するメッセージ受信処理の一例を説明するフローチャートである。

【0060】

ノード１１０の通信管理部１２１は、メッセージの受信を監視する（ステップＳ２０１）。

【0061】

メッセージを受信した場合、通信管理部１２１は、メッセージに含まれる送信元の情報に基づいて、受信したメッセージはクライアント装置１０１から送信されたメッセージであるか否かを判定する（ステップＳ２０２）。

【0062】

受信したメッセージはクライアント装置１０１から送信されたメッセージである場合、通信管理部１２１は、クラスタ管理部１３１に問合せを行うことによって、自身がリーダノード１１０であるか否かを判定する（ステップＳ２０３）。

【0063】

自身がリーダノード１１０ではない場合、通信管理部１２１は、クラスタ管理部１３１に問合せを行ってリーダノード１１０を特定し、リーダノード１１０にメッセージを転送する（ステップＳ２０４）。その後、通信管理部１２１は、メッセージの受信の監視を継続する。

【0064】

自身がリーダノード１１０である場合、通信管理部１２１は、メッセージ管理情報１２４の更新処理を実行し（ステップＳ２０５）、また、経路管理情報１２５の更新処理を実行する（ステップＳ２０６）。メッセージ管理情報１２４の更新処理の詳細は図１０を用いて説明する。経路管理情報１２５の更新処理の詳細は図１１Ａ及び図１１Ｂを用いて説明する。

【0065】

通信管理部１２１は、メッセージ管理情報１２４を参照して、同一メッセージを受信済みであるか否かを判定する（ステップＳ２０７）。

【0066】

具体的には、通信管理部１２１は、セッションＩＤ４０１及び通番４０２の組合せが、受信したメッセージに含まれるセッションＩＤ及び通番の組合せと一致するエントリが存在するか否かを判定する。前述の条件を満たすエントリが存在する場合、通信管理部１２１は、同一メッセージを受信済みであると判定する。

【0067】

同一メッセージを受信済みである場合、通信管理部１２１は、当該メッセージを破棄し、メッセージの受信の監視を継続する。

【0068】

同一メッセージを受信していない場合、通信管理部１２１は、アプリケーション実行部１２０にメッセージを転送する（ステップＳ２０８）。その後、通信管理部１２１はメッセージの受信の監視を継続する。

【0069】

ステップＳ２０２において、受信したメッセージはクライアント装置１０１から送信されたメッセージではないと判定された場合、すなわち、受信したメッセージはアプリケーション実行部１２０、又はリーダノード１１０から送信されたメッセージであると判定された場合、通信管理部１２１は、クラスタ管理部１３１に問合せを行うことによって、自身がリーダノード１１０であるか否かを判定する（ステップＳ２０９）。

【0070】

自身がリーダノード１１０である場合、通信管理部１２１は、セッション管理情報１２３を参照して、送信先のクライアント装置１０１及びフォロワノード１１０を特定し、クライアント装置１０１にメッセージを送信し、また、フォロワノード１１０にメッセージを転送する（ステップＳ２１０）。その後、通信管理部１２１はメッセージの受信の監視を継続する。このとき、通信管理部１２１はメッセージに通番を付与する。

【0071】

自身がリーダノード１１０ではない場合、通信管理部１２１は、セッション管理情報１２３を参照して、送信先のクライアント装置１０１を特定し、クライアント装置１０１にメッセージを送信する（ステップＳ２１１）。その後、通信管理部１２１はメッセージの受信の監視を継続する。

【0072】

図１０は、実施例１のノード１１０が実行するメッセージ管理情報１２４の更新処理の一例を説明するフローチャートである。

【0073】

通信管理部１２１は、メッセージ管理情報１２４を参照して、同一メッセージを受信済みであるか否かを判定する（ステップＳ３０１）。ステップＳ３０１の処理はステップＳ２０７の処理と同一である。

【0074】

同一メッセージを受信済みである場合、通信管理部１２１は、該当エントリを更新し（ステップＳ３０２）、メッセージ管理情報１２４の更新処理を終了する。

【0075】

具体的には、クライアント装置１０１から直接メッセージを受信した場合、通信管理部１２１は、該当エントリの直接受信４０３を「１」に更新し、他のノード１１０を経由してメッセージを受信した場合、該当エントリの間接受信４０４を「１」に更新する。

【0076】

同一メッセージを受信していない場合、通信管理部１２１は、メッセージ管理情報１２４にエントリを追加し（ステップＳ３０３）、メッセージ管理情報１２４の更新処理を終了する。

【0077】

具体的には、通信管理部１２１は、メッセージ管理情報１２４にエントリを追加し、メッセージに含まれるセッションＩＤ及び通番を、追加されたエントリのセッションＩＤ４０１及び通番４０２に設定する。通信管理部１２１は、クライアント装置１０１から直接メッセージを受信した場合、追加されたエントリの直接受信４０３に「１」を設定し、他のノード１１０を経由してメッセージを受信した場合、追加されたエントリの間接受信４０４に「１」を設定する。

【0078】

なお、通信管理部１２１は、直接受信４０３及び間接受信４０４が「１」であるエントリを任意のタイミングで削除してもよい。これば、メッセージを正常に受信したことが確認できたため、管理が不要となるためである。

【0079】

図１１Ａ及び図１１Ｂは、実施例１のノード１１０が実行する経路管理情報１２５の更新処理の一例を説明するフローチャートである。

【0080】

通信管理部１２１は、経路管理情報１２５の該当エントリの最終受信時刻を現在時刻に更新する（ステップＳ４０１）。

【0081】

具体的には、通信管理部１２１は、メッセージの送信元を特定し、経路５０１に送信元が格納されるエントリを検索する。通信管理部１２１は、検索されたエントリの受信時刻５０２に現在時刻を格納する。

【0082】

通信管理部１２１は、通信経路が「直接」であるか否かを判定する（ステップＳ４０２）。

【0083】

通信経路が「直接」でない場合、通信管理部１２１は、該当する「間接」エントリのカウンタ５０３をクリアする（ステップＳ４０３）。具体的には、カウンタ５０３の値が「０」に変更される。

【0084】

通信管理部１２１は、「直接」のエントリのカウンタ５０３の値を１インクリメントする（ステップＳ４０４）。

【0085】

通信管理部１２１は、リーダノード１１０及びクライアント装置１０１の間の通信経路において、全てのクライアント装置１０１に共通する部位（例えばリーダノード１１０近傍のルータ）で通信障害が発生しているか否かを判定する（ステップＳ４０５）。

【0086】

具体的には、通信管理部１２１は、条件（１）及び条件（２）を満たすか否かを判定する。なお、第１閾値及び第２閾値は任意の値を設定できる。

【0087】

（１）該当「間接」エントリの受信時刻Ｔｉから「直接」のエントリの受信時刻Ｔｄを減算した値（Ｔｉ－Ｔｄ）が第１閾値以上である。
（２）「直接」のエントリのカウンタ５０３の値が第２閾値以上である。

【0088】

条件（１）及び条件（２）を満たす場合、一定期間、フォロワノード１１０のみからクライアント装置１０１が送信したメッセージを受信していることを示す。すなわち、リーダノード１１０はクライアント装置１０１からメッセージを受信できていないことを示す。そのため、条件（１）及び条件（２）を満たす場合、通信管理部１２１は、リーダノード１１０と、全てのクライアント装置１０１の間の共通する通信経路で通信障害が発生していると判定する。

【0089】

リーダノード１１０及びクライアント装置１０１の間の通信経路で通信障害が発生していない場合、通信管理部１２１は経路管理情報１２５の更新処理を終了する。

【0090】

リーダノード１１０及びクライアント装置１０１の間の通信経路で通信障害が発生している場合、通信管理部１２１は、リーダノード１１０の縮退処理を実行し（ステップＳ４０６）、その後、経路管理情報１２５を終了する。これによって、リーダノード１１０はクラスタから切り離され、定足数ベースのクラスタ管理アルゴリズムに基づいて新たなリーダノード１１０が決定される。

【0091】

ステップＳ４０２において、通信経路が「直接」であると判定された場合、通信管理部１２１は、「直接」のエントリのカウンタ５０３をクリアする（ステップＳ４０７）。具体的には、カウンタ５０３の値が「０」に更新される。

【0092】

通信管理部１２１は、全ての「間接」のエントリのカウンタ５０３の値を１インクリメントする（ステップＳ４０８）。

【0093】

通信管理部１２１は、クライアント装置１０１との間の通信経路で通信障害が発生しているフォロワノード１１０があるか否かを判定する（ステップＳ４０９）。

【0094】

具体的には、通信管理部１２１は、各「間接」の経路について条件（３）及び条件（４）を満たすか否かを判定する。なお、第３閾値及び第４閾値は任意の値を設定できる。また、通信経路毎に異なる第３閾値及び第４閾値を設定できる。

【0095】

（３）「間接」のエントリの受信時刻Ｔｉから「直接」のエントリの受信時刻Ｔｄを減算した値（Ｔｉ－Ｔｄ）が第３閾値以上である。
（４）「間接」のエントリのカウンタ５０３の値が第４閾値以上である。

【0096】

条件（３）及び条件（４）を満たす場合、一定期間、クライアント装置１０１のみからクライアント装置１０１が送信したメッセージを受信していることを示す。すなわち、フォロワノード１１０はクライアント装置１０１からメッセージを受信できていないことを示す。そのため、条件（３）及び条件（４）を満たす場合、通信管理部１２１は、フォロワノード１１０及びクライアント装置１０１の間の通信経路で通信障害が発生していると判定する。なお、リーダノード１１０とフォロワノード１１０間の通信経路は、前述したようにＲＡＦＴ等の定足数ベースの生存監視により、その健全性が保証されている。すなわち、リーダノード１１０とフォロワノード１１０間の通信経路に障害があった場合、別途ＲＡＦＴ等により障害が検知され、該当ノードはクラスタから切り離され、別の健全なノード１１０により代替される。よって、ここでリーダノード１１０がフォロワノード１１０経由のメッセージ受信が無かった場合、それはリーダノード１１０とフォロワノード１１０間ではなく、フォロワノード１１０とクライアント装置１０１との間の通信経路に問題があったと見做すことができる。

【0097】

クライアント装置１０１との間の通信経路で通信障害が発生しているフォロワノード１１０がない場合、通信管理部１２１は経路管理情報１２５の更新処理を終了する。

【0098】

クライアント装置１０１との間の通信経路で通信障害が発生しているフォロワノード１１０がある場合、通信管理部１２１は、当該フォロワノード１１０の縮退処理を実行し（ステップＳ４１０）、その後、経路管理情報１２５を終了する。これによって、フォロワノード１１０はクラスタから切り離される。

【0099】

なお、リーダノード１１０の通信管理部１２１は、アプリケーション実行部１２０の生存監視を行い、アプリケーション実行部１２０の障害発生を検知した場合、リーダノード１１０の縮退処理を実行してもよい。アプリケーション実行部１２０の生存監視は、生存確認用のリクエストに対する応答の監視及びウォッチドッグタイマを用いた監視等が考えられる。

【0100】

図１２は、実施例１のクライアント装置１０１が実行するメッセージ受信処理の一例を説明するフローチャートである。

【0101】

クライアント装置１０１の通信管理部１４１は、メッセージの受信を監視する（ステップＳ５０１）。

【0102】

メッセージを受信した場合、通信管理部１４１は、メッセージ管理情報１４３を更新する（ステップＳ５０２）。

【0103】

具体的には、通信管理部１４１は、セッションＩＤ７０１及び通番７０２の組合せが、受信したメッセージに含まれるセッションＩＤ及び通番の組合せと一致するエントリが存在するか否かを判定する。前述の条件を満たすエントリが存在しない場合、通信管理部１２１は、メッセージ管理情報１４３にエントリを追加する。前述の条件を満たすエントリが存在する場合、通信管理部１２１は、メッセージ管理情報１４３から当該エントリを削除する。

【0104】

通信管理部１４１は、メッセージ管理情報１４３を参照して、同一メッセージを受信済みであるか否かを判定する（ステップＳ５０３）。ステップＳ５０２の処理結果に基づいて判定が行われる。

【0105】

同一メッセージを受信済みである場合、通信管理部１４１は、当該メッセージを破棄し、メッセージの受信の監視を継続する。

【0106】

同一メッセージを受信していない場合、通信管理部１４１は、アプリケーション実行部１４０に転送する（ステップＳ５０４）。その後、通信管理部１４１はメッセージの受信の監視を継続する。

【0107】

実施例１のシステムでは、クライアント装置１０１は、リーダノード１１０及びフォロワノード１１０に同一メッセージを送信し、フォロワノード１１０はリーダノード１１０にメッセージを転送する。また、リーダノード１１０は、直接クライアント装置１０１にメッセージを送信し、また、フォロワノード１１０を経由してメッセージを送信する。フォロワノード１１０は、リーダノード１１０から受信したメッセージをクライアント装置１０１に転送する。これによって、リーダノード１１０とクライアント装置１０１間、又はフォロワノード１１０とクライアント装置１０１間の通信経路の一方で通信障害やパケットロスが発生したとしても、クライアント装置１０１とリーダノード１１０は特段の遅延なくメッセージを送受信できるため、応答性の高いサービスを継続することができる。

【0108】

また、リーダノード１１０は、メッセージの受信状態に基づいて、ノード１１０及びクライアント装置１０１の間の通信経路の通信障害を検知し、リーダノード１１０の切り替え及びフォロワノード１１０の切り離しを迅速に行うことができる。

【0109】

本発明は、システムの構成及びネットワークの構成に依存しないため、様々なシステムに適用することができる。また、本発明は、専用の機器を用いる必要が無いため、導入コストを抑えることができる。

【実施例0110】

実施例２では、通信経路において通信遅延が発生した場合、ノード１１０の縮退処理が実行される。以下、実施例１との差異を中心に実施例２を説明する。

【0111】

実施例２のシステムの構成は実施例１と同一である。実施例２のクライアント装置１０１の構成は実施例１と同一である。

【0112】

実施例２のノード１１０の構成は実施例１と同一である。ただし、実施例２では、メッセージ管理情報１２４のデータ構造が異なる。図１３は、実施例２のメッセージ管理情報１２４のデータ構造の一例を示す図である。

【0113】

メッセージ管理情報１２４は、セッションＩＤ４０１、通番４０２、及びタイムスタンプ４５１を含むエントリを格納する。セッションＩＤ及び通番の組みに対して一つのエントリが存在する。

【0114】

タイムスタンプ４５１は、メッセージの受信時刻を格納するフィールド群である。タイムスタンプ４５１には、メッセージの多重化の数だけフィールドが含まれる。

【0115】

実施例２では、フォロワノード１１０は、リーダノード１１０にメッセージを転送する場合、フォロワノード１１０がメッセージを受信した時刻を当該メッセージに含めて転送する。

【0116】

実施例２では、メッセージ管理情報１２４の更新処理が実施例１と異なる。図１４は、実施例２のノード１１０が実行するメッセージ管理情報１２４の更新処理の一例を説明するフローチャートである。

【0117】

通信管理部１２１は、メッセージ管理情報１２４を参照して、同一メッセージを受信済みであるか否かを判定する（ステップＳ３０１）。ステップＳ３０１の処理はステップＳ２０７の処理と同一である。

【0118】

同一メッセージを受信済みである場合、通信管理部１２１は、該当エントリを更新し（ステップＳ３５１）、その後、ステップＳ３５３に進む。

【0119】

具体的には、クライアント装置１０１から直接メッセージを受信した場合、通信管理部１２１は、該当エントリのタイムスタンプ４５１の直接のフィールドに、通信管理部１２１がメッセージを受信した時刻を格納する。フォロワノード１１０を経由してメッセージを受信した場合、通信管理部１２１は、該当エントリのタイムスタンプ４５１のフォロワノード１１０のフィールドに、メッセージに含まれる受信時刻を格納する。

【0120】

同一メッセージを受信していない場合、通信管理部１２１は、メッセージ管理情報１２４にエントリを追加し（ステップＳ３５２）、その後、ステップＳ３５３に進む。

【0121】

具体的には、通信管理部１２１は、メッセージ管理情報１２４にエントリを追加し、メッセージに含まれるセッションＩＤ及び通番を、追加されたエントリのセッションＩＤ４０１及び通番４０２に設定する。通信管理部１２１は、クライアント装置１０１から直接メッセージを受信した場合、追加されたエントリのタイムスタンプ４５１の直接のフィールドに通信管理部１２１がメッセージを受信した時刻を設定する。フォロワノード１１０を経由してメッセージを受信した場合、通信管理部１２１は、追加されたエントリのタイムスタンプ４５１のフォロワノード１１０のフィールドにメッセージに含まれる受信時刻を設定する。

【0122】

ステップＳ３５１の処理又はステップＳ３５２の処理の実行後、通信管理部１２１は、同一メッセージをクライアント装置１０１及びフォロワノード１１０の双方から受信したか否かを判定する（ステップＳ３５３）。

【0123】

なお、メッセージの受信について待ち時間を設定し、クライアント装置１０１及びフォロワノード１１０のいずれかからメッセージを受信した後、待ち時間を経過した場合、通信管理部１２１は、タイムアウトと判定し、最初のメッセージの受信時刻に所定時間を加算した時刻を、受信していない経路のフィールドに設定する。

【0124】

同一メッセージをクライアント装置１０１及びフォロワノード１１０の双方から受信していない場合、通信管理部１２１はメッセージ管理情報１２４の更新処理を終了する。

【0125】

同一メッセージをクライアント装置１０１及びフォロワノード１１０の双方から受信した場合、通信管理部１２１は、直接及び間接のペアについて、式（１）に示すΔＴｄと、式（２）に示すΔＴｉを算出する（ステップＳ３５４）。

【0126】

ΔTd = (直接受信時刻)－（間接受信時刻）…(1)

【0127】

ΔTi = (間接受信時刻)－（直接受信時刻）…(2)

【0128】

通信管理部１２１は、ΔＴｄ及びΔＴｉの移動平均を算出する（ステップＳ３５５）。例えば、３０秒間の移動平均が算出される。なお、移動平均の算出には、クライアント装置１０１及びフォロワノード１１０の双方からメッセージを受信したセッションのエントリのΔＴｄ及びΔＴｉを用いる。

【0129】

通信管理部１２１は、ΔＴｄ及びΔＴｉの移動平均に基づいて、通信遅延が発生している通信経路が存在するか否かを判定する（ステップＳ３５６）。

【0130】

例えば、ΔＴｄの移動平均が閾値より大きい場合、通信管理部１２１は、リーダノード１１０及びクライアント装置１０１の間の通信経路に通信遅延が発生していると判定する。ΔＴｄの移動平均が閾値より大きい場合、通信管理部１２１は、フォロワノード１１０及びクライアント装置１０１の間の通信経路に通信遅延が発生していると判定する。

【0131】

通信遅延が発生している通信経路が存在しない場合、通信管理部１２１はメッセージ管理情報１２４の更新処理を終了する。

【0132】

通信遅延が発生している通信経路が存在する場合、通信管理部１２１は、当該通信経路を使用するノード１１０の縮退処理を実行し（ステップＳ３５７）、その後、メッセージ管理情報１２４の更新処理を終了する。

【0133】

なお、通信経路のスローダウンの検知方法は一例であって、これに限定されない。

【0134】

実施例２によれば、通信遅延の発生を契機にノード１１０の縮退処理を実行することによって、サービスの応答性を高く維持することができる。

【0135】

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

【0136】

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

【0137】

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

【0138】

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

【0139】

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。