JP5695324B2 - スプリットブレイン状況におけるメジャーグループを決定するための方法、システム、及びコンピュータ読み取り可能な記録媒体 - Google Patents

Description

本発明は、ネットワークベースの分散コンピューティング環境（または、分散環境）で発生するスプリットブレイン（Ｓｐｌｉｔ−Ｂｒａｉｎ）状況におけるメジャーグループを決定するための方法、システム、及びコンピュータ読み取り可能な記録媒体に関する。より詳しくは、スプリットブレイン状況におけるノードの履歴情報を参照してメジャーグループを決定するための方法、システム、及びコンピュータ読み取り可能な記録媒体に関する。

現在のＩＴ環境では、多様なネットワークベースの分散システムを効率よく管理し、統制することができる方法が必要である。分散環境では、複数のコンピュータを物理的かつ論理的に接続し、このように接続された複数のコンピュータの処理能力を用いて、巨大な計算問題を解決することが一般的である。この際、分散環境に参加するコンピュータまたはプロセスが数十個レベルであれば、分散環境を管理する運営者によって分散環境が適切に維持され得るが、分散環境が数千個または数万個のコンピュータまたはプロセスを含む規模である場合は、これを総体的に同期化し、調整することができるソリューションとして管理システムが必要とされているといえる。

管理システムにおいて最も重要な条件は、耐故障性（ｆａｕｌｔ ｔｏｌｅｒａｎｃｅ）の保障といえるが、特に、クラスターを構成するそれぞれのノード間のリンクの不安定によって、ネットワークが異常に分離される障害状況での対処が最も重要なものの一つである。

図１は、スプリットブレイン状況を例示した図である。図１において、分散環境管理システムは、５つのサーバで構成されるクラスターを含み、クラスターを構成するそれぞれのサーバは、リアルタイムでデータを複製し、同一の状態情報を保持しているものと仮定して示した。

図１の状態において、スプリットブレインが発生し、クラスターが２つのサーバグループに分けられる場合、グループ♯１のサーバは、グループ♯２の全てのサーバがダウンした（すなわち、不能状態に陥った）とみなし、同時にグループ♯２のサーバも、グループ♯１のサーバがダウンしたとみなすだろう。したがって、ネットワーク上の前記２つのグループが自身をメジャーグループと判断し、クライアントは、前記自身をメジャーグループと判断した２つのグループにそれぞれ接続して作業を行うようになる。例えば、グループ♯１に接続したクライアントグループ♯１は、平素通り読みまたは書き作業を行い、グループ♯２に接続したクライアントグループ♯２も、読みまたは書き作業を行うようになる。

しかしながら、上記のような状況では、以降、スプリットブレインが復旧され、分けられた２つのグループが再び一つに合わせられなければならない場合、どのグループのデータが正しいデータであり、どのグループのデータが削除されなければならないかを判断する方法がなかった。すなわち、従来の技術によると、スプリットブレイン状況において、サービスの連続性やデータの整合性に問題が生じるという短所があった。

韓国公開特許第２０００‐００７６５１３号公報 韓国公開特許第２００４‐００７３２７４号公報

本発明は、上述した従来技術の問題点を解決することをその目的とする。

また、分散コンピューティングに参加する複数のコンピュータを総体的に同期化し、調整することができるソリューションを提供することを他の目的とする。

また、スプリットブレインが発生した状況でも、サービスの連続性とデータの整合性を最大限に保障することをまた他の目的とする。

上記目的を達成するために、本発明の一実施形態によると、ネットワークベースの分散環境において、複数のノードで構成された初期グループが分離されて生成された２つ以上のグループのうちから、メジャーグループを決定するための方法であって、第１グループのノード数と第２グループのノード数とを比較し、前記第１グループのノード及び前記第２グループのノードの履歴情報を取得し、前記ノード数の比較結果及び前記履歴情報の少なくともいずれかを用いて、前記第１グループまたは前記第２グループをメジャーグループと決定する方法が提供される。

本発明の他の実施形態によると、複数のノードで構成される分散環境管理システムであって、前記複数のノードの履歴情報を含み、前記複数のノードの少なくとも一つは、初期グループが２つ以上のグループに分離される場合、前記分離された各グループのノード数及び前記履歴情報の少なくともいずれかを用いて、前記２つ以上のグループのうち一つをメジャーグループと決定する分散環境管理システムが提供される。

その他、本発明を具現するための他の方法、システム、及び、前記方法を実行するためのコンピュータプログラムを記録するためのコンピュータ読み取り可能な記録媒体がさらに提供される。

本発明によると、分散コンピューティングに参加する複数のコンピュータを総体的に同期化し、調整することができるソリューションが提供される。また、スプリットブレインが発生した状況でも、サービスの連続性とデータの整合性を最大限に保障することができるようになる。

スプリットブレイン状況を例示した図である。 本発明の一実施形態による分散環境を概略的に示す図である。 分散環境管理システム２００が提供するロック機能を例示した図である。 スプリットブレイン状況にコーラムアルゴリズムを適用した様子を示す図である。 履歴テーブルに基づいた動的コーラム方式を適用してスプリットブレインを解決する過程を例示した図である。 スプリットブレイン発生時、メジャーグループを決定する方法を例示した図である。

後述する本発明についての詳細な説明は、本発明が実施可能な特定の実施形態を例示として示す添付図面を参照する。これらの実施形態は、当業者が本発明を十分に実施することができるように詳細に説明される。本発明の様々な実施形態は、互いに異なるが、相互排他的である必要はない。例えば、ここに記載されている特定の形状、構造及び特性は、一実施形態と関連して、本発明の精神を逸脱しない範囲内で他の実施形態に具現されてもよい。また、それぞれの開示された実施形態内の個別構成要素の位置または配置は、本発明の精神を逸脱しない範囲内で変更され得る。従って、後述する詳細な説明は、限定的な意味として解釈されてはならず、本発明の範囲は、適切に説明されれば、その請求項が主張するものと均等な全ての範囲と共に、添付の請求項によってのみ限定される。図面において、類似した参照符号は、いくつかの側面にわたって同一または類似の機能を表す。
以下、本発明の属する技術の分野における通常の知識を有する者が、本発明を容易に実施することができるようにするため、添付した図面に基づき、本発明の好適な実施形態について詳述する。

全体システムの構成
図２は、本発明の一実施形態による分散環境を概略的に示す図である。

図２に示すように、本発明の一実施形態による全体システムは、通信網１００と、分散環境においてロックサービスを提供する分散環境管理システム２００と、分散環境管理システム２００が提供するサービスを用いる複数のクライアント３００と、で構成される。

先ず、通信網１００は、有線及び無線等のようなその通信の様態によらずに構成され、ローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、都市規模ネットワーク（ＭＡＮ：Ｍｅｔｒｏｐｏｌｉｔａｎ Ａｒｅａ Ｎｅｔｗｏｒｋ）、広域ネットワーク（ＷＡＮ：Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等、多様な通信網で構成されてもよい。

本発明の一実施形態によると、分散環境管理システム２００は、数個のサーバ（以下では、主に「ノード」と表す）で構成されてもよく、多様なシステム資源を共有する複数のクライアント３００間において、データの整合性が保障されるようにするため、クライアント３００にロックサービスを提供することができる。

また、分散環境管理システム２００は、クライアント３００が分散環境管理システム２００内の特定ノードと通信可能に、セッションを生成／維持／解除する機能を行い、クライアント３００と通信する特定ノードに障害が発生した場合、クライアント３００が待機中である他のノードと通信可能にスイッチングサービスを提供することができる。

また、分散環境管理システム２００は、複数のノード間の同期化を行い、様々なイベントを処理する機能を行うことができる。

本発明の一実施形態によると、分散環境管理システム２００は、クラスターマネージャー、イベントマネージャー、及び場合に応じてクライアントライブラリ（図示せず）を含めてもよい。

本発明の一実施形態によると、クラスターマネージャーは、分散環境管理システム２００のノードの集合であるクラスター内の全ノードを管理する機能を行うことができる。より具体的には、クラスターマネージャーは、クラスター内のノードを管理する機能と、クライアントライブラリと通信しながらロック動作を処理する機能を行うことができる。また、クライアント３００において、特定の経路またはデータに対してロック動作を行おうとすると、クラスターマネージャーは、要求したクライアント３００が該当ロック動作の権限を持っているか否かを確認し、即時に（いわゆる、ノンブロッキングモード）ロック取得の有無を真（Ｔｒｕｅ）または偽（Ｆａｌｓｅ）の値として返還することができる。また、クラスターマネージャーは、クライアント３００のロック動作処理またはロック動作に伴うイベント処理に関する機能を行うことができるが、例えば、ロックの類型に応じて、該当経路またはデータにロックがかかったことを他のクライアント３００に知らせるためのイベントを生成し、これを、イベントマネージャーに伝達する機能を行うことができる。
本発明の一実施形態によると、クライアントライブラリとの通信は、マスタークラスターマネージャーを通じてのみ行われ、他の補助クラスターマネージャーは、マスタークラスターマネージャーの状態情報のレプリカをリアルタイムで保持することができる。マスタークラスターマネージャーの障害時は、補助クラスターマネージャーのうち、新たなマスタークラスターマネージャーが選出される。

次に、本発明の一実施形態によると、イベントマネージャーは、クラスターマネージャーと同様に、一つのマスターイベントマネージャーと複数の補助イベントマネージャーとで構成され、イベントが通知されるべきクライアント３００のリストを管理し、イベントが発生する場合、該当クライアント３００にイベントに対する通知を伝達する機能を行うことができる。より具体的には、イベントマネージャーは、大別してロックイベントと汎用イベントのような２つのイベントを行うことができる。前記イベントの処理過程をより詳述すると、先ず、ロックイベントの場合、マスタークラスターマネージャーがロックイベントに関する情報をマスターイベントマネージャーに伝達し、イベントマネージャーは、登録された複数のクライアント３００にマルチキャスト方式でイベントを伝送する方式で処理されてもよい。次に、汎用イベントの場合、ロック動作にかかわらず、クライアント３００が、一般のパブリッシュ・サブスクライブ方式で、イベントマネージャーにイベントの生成を要求または登録し、イベントマネージャーからイベントを伝達される方式で処理されてもよい。

また、本発明の一実施形態によると、クライアントライブラリは、クライアント３００が分散環境管理システム２００のロックサービス及びイベントサービスを容易に用いることができるように、ライブラリの形態で提供されるプログラムであって、その少なくとも一部が分散環境管理システム２００内に含まれるものであってもよい。勿論、必要に応じて、クライアントライブラリの少なくとも一部がクライアント３００内に含まれてもよい。

本発明の一実施形態によると、クライアント３００は、クライアントライブラリが提供する機能を用いて、分散環境管理システム２００と通信するようになる。より具体的には、クライアントライブラリは、遠隔で分散環境管理システム２００が提供するサービスを用いるように、クライアント３００に提供されるライブラリの集合である。本発明の一実施形態によると、使用者は、このライブラリを、自身のプログラム内にプラグインとして組み込んで使うことができ、初期化の場合は、プロキシオブジェクトを生成し、クラスターに接続して、ＲＰＣ形態でロック作業を行うこともできる。クライアントライブラリは、遠隔のクラスター内で発生するマスターノードの選出、フェイルオーバー、メンバー変更等の多様な状況を抽象化することにより、使用者が、単に安全であり抽象化した遠隔サービスを、ローカルサービスを用いる場合と同様に使用することができるよう、助ける機能を行う。

ロックサービスの提供
分散環境では、複数のプロセスまたはスレッドが一つの作業を協働して行うことが多いが、プロセスまたはスレッドに含まれた複数のトランザクションが一つのデータに対して同時に読みまたは書き作業を行う場合、誤った結果をもたらすことがあるので、複数のトランザクションから共通にアクセス可能なデータの保護が必要である。これは、分散環境に含まれたそれぞれのコンピュータが互いにデータを共有する場合も、同様である。したがって、分散環境において、一つのトランザクションによって用いられるデータに、他のトランザクションがアクセスできないようにするロック機能も必要とされ得る。

したがって、以下では、本発明の一実施形態によって、分散環境管理システム２００がクライアント３００に提供するロックサービスについて詳述する。

図３は、分散環境管理システム２００が提供するロック機能を例示した図である。一方、図３は、一つのサービスが３つのクライアント３００において同時に実行される状況を仮定して示している。

図３を参照すると、クライアント１（３１０）、クライアント２（３２０）、及びクライアント３（３３０）が、共有データに対する読みまたは書き作業を行おうとする場合、本発明の一実施形態による分散環境管理システム２００のマスタークラスターマネージャーに、該当データに対するロックを要求することができることが分かる。図３のクライアント１（３１０）がロックを要求するとき、クライアント２（３２０）及びクライアント３（３３０）が、該当データに対するロックを要求していなければ、クライアント１（３１０）は、あまり無理なくロックを取得することができる。しかし、図３に示すように、少なくとも２つ以上のクライアントが競争的にロックを要求していれば、そのうち一つのクライアントにのみロックが付与される。

それぞれのクライアント３１０、３２０、３３０が競争的にロックを要求する場合に備えるための一つの方法として、それぞれのクライアント３１０、３２０、３３０がロックを取得するまで、分散環境管理システム２００に持続的にロックを要求することを想定することができるが、これは、以下のようなプログラムコードを用いて実現されてもよい。

特定のクライアント３００にロックが付与されると、マスタークラスターマネージャーは、該当クライアント３００のロック情報をデータベースまたはメモリ等のような保存装置に記録することができる。

また、上述したように、マスタークラスターマネージャーによって更新されたロック情報は、周期的または非周期的に補助クラスターマネージャーに複製されるので、マスタークラスターマネージャーに記録された情報と補助クラスターマネージャーに記録された情報との間の整合性が維持される。

本発明の一実施形態によると、分散環境管理システム２００から取得されたロックは、該当ロックを要求したプロセスまたはスレッドにのみ使用が許可される。また、本発明の他の実施形態によると、分散環境管理システム２００から取得されたロックは、該当ロックを取得したクライアント３００内の全てのプロセスまたはスレッドに使用が許可されてもよい。

スプリットブレイン状況におけるマスターノードの選出
上述したように、分散コンピューティングの条件として、耐故障性の保障が必須であるといえるが、本発明の一実施形態によると、分散環境に参加するクライアント３００のロック情報及びクライアント３００に対するイベント通知処理は、分散環境管理システム２００に含まれたクラスターマネージャー及びイベントマネージャーによって管理されるので、クラスターマネージャーまたはイベントマネージャーに障害が発生する場合、分散環境に参加した全てのクライアント３００の作業が正常に行われなくなるという問題点が生じる。

したがって、本発明の分散環境管理システム２００は、複数のクラスターマネージャーを含み、そのうちの一つをマスタークラスターマネージャーと設定し、クライアントとの直接的な通信を行わせるのに対して、その他の補助クラスターマネージャーは、マスタークラスターマネージャーのロック情報を複製して保存することにより、マスタークラスターマネージャーに障害が発生しても、補助クラスターマネージャーのうち一つを用いて、サービスの連続性やデータの整合性が保障されるようにすることができる。上記のような構成は、イベントマネージャーにも、同様に適用されてもよい（以下では、マスタークラスターマネージャーとマスターイベントマネージャーを包括する意味として「マスターノード」との用語を用いる）。

もっとも、上記のような構成のみでは、スプリットブレインに適切に対処することができない。これは、上述したように、スプリットブレイン状況で分けられたそれぞれのグループは、他のグループのノードが全てダウンしたものと判断するようになるので、それぞれのグループ毎にマスターノードが生成され、したがって、障害が復旧された後、それぞれのグループに属していたノード間のデータの整合性に問題が生じるからである。

したがって、以下では、本発明の一実施形態によって、スプリットブレイン状況でマスターノードを選出する方法について、かかる問題の解決を含め、より詳細に説明する。

１．コーラムに基づくマスターノード選出
本発明の一実施形態によると、分散環境管理システム２００は、スプリットブレインが感知される場合、コーラムアルゴリズムを適用してマスターノードを選出するようになる。以下では、図４を参照して、より具体的に説明する。

図４は、スプリットブレイン状況にコーラムアルゴリズムを適用した様子を示す図である。

図４を参照すると、全７つのノードで構成されたクラスターにスプリットブレインが発生し、４つのノードを含むグループＡと３つのノードを含むグループＢに分けられたことが分かる。

上記のような状況において、グループＡは、全ノード数（すなわち、７つ）の過半数に該当するノードを確保しているので、コーラムを満足し、メジャーグループに分類される。これにより、メジャーグループに含まれたノードのうち一つが、マスターノードに指定され、該当マスターノードを介してクライアント３００との通信が行われる。また、マスターノードは、データに対する読みまたは書き作業を許容される。

これに対して、グループＢは、全ノード数の過半数に該当するノードを確保していないので、マイナーグループに分類される。このようなマイナーグループからはマスターノードが選出されない。

スプリットブレイン状況において、それぞれのグループが、自身がメジャーグループであるかマイナーグループであるかを判断するためには、スプリットブレインが発生する前の初期グループに、どれほど複数のノードが存在したかに関する情報が、スプリットブレインが発生した後のそれぞれのグループの少なくとも一つのノードに保存されていなければならないが、本発明の一実施形態によると、マスターノードに保存された情報は、これに対応している補助ノードに複製されるので、初期グループに、どれほど複数のノードが存在したかに関する情報をマスターノードに保存することにより、前記要求が達成され得る。

次に、図４のように、スプリットブレインが発生した状況において、再度スプリットブレインが発生して、グループＡが、３つのノードを含むグループＡ１と１つのノードを含むグループＡ２に分類され、グループＢが、２つのノードを含むグループＢ１と１つのノードを含むグループＢ２に分離された状況を仮定してみると、いずれのグループも、初期グループに属していたノードの過半数に該当する４つ以上のノードを含んでいないので、コーラムを満足するグループを特定することができないという問題が生じる。

このような問題点を解決するために、本発明の一実施形態によると、コーラムは、グループを構成するノード数の変化に応じて動的に再設定されてもよい。より具体的には、動的コーラムを具現するためには、先ず、グループの再設定時間を設定しなければならない。本発明の一実施形態によると、グループの再設定時間は、３０秒に設定されてもよいが、この場合、グループ内のノードの数が３０秒間変わらないと、この時点を基準としてグループが再設定される。グループが再設定されることにより、コーラムの算定の基準となるグループ内のノード数が初期化され、よって、コーラムも変更されるようになる。

上述した例の場合、最初のスプリットブレインが発生する前には、グループに含まれたノードの総数が７であるので、コーラムは４に設定される。その後、第一のスプリットブレインが発生すると、グループＡの場合、４つのノードが含まれるので、コーラムが３に再設定され、グループＢの場合、３つのノードが含まれるので、コーラムが２に再設定される。これにより、第二のスプリットブレインが発生しても、グループＡ１及びグループＢ１がコーラムを満足するようになる。

しかし、グループＢ１の場合、第一のスプリットブレインが発生した時点でマイナーグループに分類されたので、たとえ、第二のスプリットブレインが発生して、過半数のノードを確保したとしても、メジャーグループに分類されず、グループＡ１のみがメジャーグループに分類される。このため、マスターノードは、スプリットブレインが発生する前のグループにどれほど複数のノードが存在したかに関する情報と共に、スプリットブレインが発生する前に該当グループがメジャーグループであったかマイナーグループであったかに関する情報も一緒に保存してもよい。

以下、図４を参照して、スプリットブレインが復旧された場合の処理について説明する。マイナーグループであったグループＢに含まれたノードは、メジャーグループであるグループＡに含まれたノードから最新の状態情報を取り込んでアップデートを行い、これにより、７つの全てのノードが再度一つのグループとして機能できる。

上記の方法で、スプリットブレイン状況でも、データ整合性が保障されるようになる。

しかし、上記のようにコーラムアルゴリズムのみを採用すると、いくつかの場合において、サービスの連続性やデータの整合性を保障できないという短所がある。例えば、６つのノードで構成されたグループが、それぞれ３つのノードを含む２つのグループに分離される場合、いずれのグループも、過半数のノードを含まないので、サービスが持続できない。また、持続的なスプリットブレインにより、それぞれ１つのノードを含むグループが生成した場合も、同様にサービスが持続されない。すなわち、静的な方式でコーラムを適用するときは、特に、サービスの連続性の側面において、以下のような制約がある。
‐初期グループの総ノード数：２Ｎ＋１
‐コーラムの最小数：Ｎ＋１
‐書き作業が可能な最小限のノード個数＝コーラムの個数＝Ｎ＋１（Ｎは整数）

２．履歴に基づくマスターノードの選出
本発明の一実施形態によると、分散環境管理システム２００は、履歴テーブルを用いて、データの整合性を保障すると共に、サービスの連続性をさらに高度化することができる。

本発明の一実施形態によると、履歴テーブルは、最初にグループが構成される時点でのノードＩＤ情報、グループ合流時点情報、ノード状態情報、及びグループ状態情報を含めてもよい。下記表は、履歴テーブルに保存されるデータを例示的に示している。

上記のような履歴テーブルは、グループが最初に構成されるときに生成されてもよく、グループの機能が終了するまで維持されてもよい。前記履歴テーブルにおいて、第三のフィールドであるノード状態情報は、新たなマスターノードが選出されるたびにマスターまたはスレーブに変更され、グループ状態情報は、スプリットブレインが発生することにより、メジャーまたはマイナーに変更されてもよい。

本発明の一実施形態による分散環境管理システム２００は、スプリットブレインにより、一つのグループが同一のノード数を有する２つのグループに分離された場合、前記履歴テーブルを用いてメジャーグループを決定することができる（もちろん、前記履歴テーブルは、必ず同一のノード数を有する２つのグループのうち、メジャーグループを決定する場合のみならず、ノード数の差が所定の基準値以下である２つのグループのうち、メジャーグループを決定する場合も用いられることは、当業者にとって容易に理解される）。より具体的には、スプリットブレインが発生する前にメジャーグループに属しており、グループに合流した時点が最も早いノードが含まれたグループを、新たなメジャーグループと決定することができる。また、本発明の一実施形態によると、グループに合流した時点が最も早いノードを、当該グループのマスターノードと決定してもよい。それでも、コーラムを満足する唯一のグループがない場合は、スプリットブレインが発生する直前のグループ状態がメジャーであり、直近においてマスターに選出されたノード（すなわち、グループに合流した時点が最も早いノード）のあるグループを、新たなメジャーグループと決定してもよい。

図５は、履歴テーブルに基づいた動的コーラム方式を適用してスプリットブレインを解決する過程を例示した図である。以下では、図５に示すステップによって履歴テーブルが変更する過程を記述することにより、履歴テーブルに基づいた動的コーラム方式をより具体的に説明する。

ステップ１：スプリットブレインが発生する前の、６つのノードで構成されたグループであって、であり、全てのノードがメジャーグループに属している。Ｎｏｄｅ＃１のグループ合流時点が最も早いので、マスターノードに選出される。

ステップ２：スプリットブレインが発生し、同一の数のノードを有する２つのグループに分離される。障害以前にメジャーグループに属していたノードのうち、グループ合流時点が最も早いノードは、Ｎｏｄｅ＃１であるので、左グループがメジャーグループと決定され、右グループは、マイナーグループに変更される。

ステップ３〜４：ステップ２を経て、メジャーグループは、Ｎｏｄｅ＃１、Ｎｏｄｅ＃３、及びＮｏｄｅ＃５を含むグループに再設定され（これにより、コーラムは２に再設定される）、以降、再度スプリットブレインが発生し、Ｎｏｄｅ＃１を含むグループとＮｏｄｅ＃３及びＮｏｄｅ＃５を含むグループに分離される。Ｎｏｄｅ＃３及びＮｏｄｅ＃５を含むグループが、コーラムを満足するので、メジャーグループと決定され、Ｎｏｄｅ＃１を含むグループは、マイナーグループに変更される。一方、Ｎｏｄｅ＃３のグループ合流時点が最も早いので、新たなマスターノードに選出される。

ステップ５：２つのノード（Ｎｏｄｅ＃３及びＮｏｄｅ＃５）で構成されたグループに再度スプリットブレインが発生し、２つのグループに分けられる。ステップ２におけると同様に、以前にメジャーグループに含まれていたノードのうち、グループ合流時点が最も早いＮｏｄｅ＃３が属しているグループが新たなメジャーグループと決定される。

このように履歴テーブルを活用することにより、グループが、同一のノードを含む２つのグループに分離される場合、または、持続的な障害により単に１つのノードを含むグループのみが存在する場合も、サービスの連続性を保障することができるようになる。

図６は、スプリットブレイン発生時、メジャーグループを決定する方法を例示した図である。スプリットブレインが発生し、２つ以上のグループに分けられた場合、分散環境管理システムは、既存のグループにあった全ノード数、及び分けられたそれぞれのグループに該当するノード数を確認して比較する。また、上述した履歴テーブルを活用して、分けられたそれぞれのグループのノードの履歴情報を確認する。履歴情報の具体例については詳細に上述したので、省略する。図面上では、便宜上、ノード数を確認及び比較するステップが、ノード履歴情報の確認ステップよりも先に行われるように示されているが、前記２つのステップの実行順序は特に限定されない。すなわち、この順序は、図示されているものと反対に行われてもよく、また、２つのステップがそれぞれ同時に行われてもよい。前の２つのステップから出たノード数の比較結果及び確認された履歴情報の少なくとも一つを用いて、２つ以上に分けられたそれぞれのグループのうち、どのグループがメジャーグループであるかを決定することができる。

上述した本発明による実施形態は、多様なコンピュータ構成要素を介して実行され得るプログラム命令語の形態で実現され、コンピュータ読み取り可能な記録媒体に記録されてもよい。前記コンピュータ読み取り可能な記録媒体は、プログラム命令語、データファイル、データ構造等を単独または組み合わせて含むことができる。前記コンピュータ読み取り可能な記録媒体に記録されるプログラム命令語は、本発明のために特別に設計され構成されたものであり、または、コンピュータソフトウェア分野の当業者に公知で使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体、フロプティカルディスクのような磁気‐光媒体、及びＲＯＭ、ＲＡＭ、フラッシュメモリ等のようなプログラム命令語を保存して実行するように特別に構成されたハードウェア装置が挙げられる。プログラム命令語の例としては、コンパイラによって作られるような機械語コードのみならず、インタープリター等を用いてコンピュータによって実行可能な高級言語コードも含まれる。前記ハードウェア装置は、本発明による処理を行うために、一つ以上のソフトウェアモジュールとして作動するように構成されてもよく、その逆も同様である。

以上、本発明が、具体的な構成要素等のような特定事項と、限定された実施形態及び図面によって説明されているが、これは、本発明のさらなる全般的な理解のためのものであるだけで、本発明が上記した実施形態に限定されるものではなく、本発明の属する分野における通常の知識を有する者であれば、このような記載から様々な修正及び変形を図ることができる。

従って、本発明の思想は、上述された実施形態に局限されて定められてはならず、後述する特許請求の範囲のみならず、この特許請求の範囲と均等にまたは等価的に変形された全てのものは、本発明の思想の範疇に属するものと言える。

１００ 通信網
２００ 分散環境管理システム
３００ クライアント

Claims (12)

1. ネットワークベースの分散環境において、複数のノードで構成された初期グループが第１グループと第２グループに分離された場合、前記複数のノードのうち少なくとも一つのノードが、前記第１のグループまたは前記第２グループのうちからメジャーグループを決定するための方法であって、
   前記第１グループのノード数と前記第２グループのノード数とを比較し、
   前記ノード数の差が所定の基準値を超える場合、前記第１グループ及び前記第２グループのうち、より多くのノードを含むグループを前記メジャーグループと決定し、
   前記第１グループのノード数と前記第２グループのノード数との差が、前記所定の基準値以下である場合、前記第１グループのノード及び前記第２グループのノードの履歴情報を取得し、履歴テーブルに保存された前記履歴情報を用いて、前記第１グループまたは前記第２グループをメジャーグループと決定する
   ことを特徴とするメジャーグループの決定方法。
2. 前記履歴情報は、前記第１グループのノード及び前記第２グループのノードが前記初期グループに合流した時点の情報を含むことを特徴とする請求項１に記載のメジャーグループの決定方法。
3. 前記履歴情報を用いて、前記第１グループまたは前記第２グループをメジャーグループと決定することは、前記第１グループ及び前記第２グループのうち、前記初期グループに合流した時点が最も早いノードが含まれたグループを前記メジャーグループと決定することを特徴とする請求項２に記載のメジャーグループの決定方法。
4. 前記履歴情報を用いて、前記第１グループまたは前記第２グループをメジャーグループと決定することは、前記第１グループ及び前記第２グループのうち、前記初期グループにおいてマスターノードであったノードが含まれたグループを前記メジャーグループと決定することを特徴とする請求項１に記載のメジャーグループの決定方法。
5. 前記第１グループ及び前記第２グループは、前記初期グループが少なくとも２回分離されることにより生成され、
   前記履歴情報を用いて、前記第１グループまたは前記第２グループをメジャーグループと決定することは、前記第１グループ及び前記第２グループが、最近、共通に属していたグループがメジャーグループであった場合にのみ、前記第１グループまたは前記第２グループをメジャーグループと決定することを特徴とする請求項１に記載のメジャーグループの決定方法。
6. 特定のデータに対する読みまたは書き作業は、前記メジャーグループに属するノードに対してのみ許容されることを特徴とする請求項１に記載のメジャーグループの決定方法。
7. 前記特定のデータは、前記分散環境におけるロック情報であることを特徴とする請求項６に記載のメジャーグループの決定方法。
8. 前記履歴情報は、前記複数のノードのそれぞれに複製された履歴テーブルに含まれた情報であることを特徴とする請求項１に記載のメジャーグループの決定方法。
9. 前記履歴テーブルは、前記複数のノードのそれぞれが、前記初期グループに合流した時点に関する情報を含むことを特徴とする請求項８に記載のメジャーグループの決定方法。
10. 請求項１から９のいずれか一項に記載のメジャーグループの決定方法を実行するためのコンピュータプログラムを記録するコンピュータ読み取り可能な記録媒体。
11. 複数のノードで構成される分散環境管理システムであって、
    前記複数のノードの履歴テーブルに保存された履歴情報を含み、
    前記複数のノードの少なくとも一つは、初期グループが第１グループと第２グループに分離された場合には、前記第１グループのノード数と前記第２グループのノード数とを比較し、
    前記第１グループのノード数と前記第２グループのノード数との差が、所定の基準値を超える場合、前記第１グループ及び前記第２グループのうち、より多くのノードを含むグループを前記メジャーグループと決定し、
    前記第１グループのノード数と前記第２グループのノード数との差が、所定の基準値以下である場合、前記履歴情報かを用いて、前記第１グループまたは前記第２グループをメジャーグループと決定することを特徴とする分散環境管理システム。
12. 前記履歴情報には、前記複数のノードのそれぞれが、前記初期グループに合流した時点に関する情報、及び前記複数のノードのそれぞれが、最近、属していたグループの状態に関する情報が含まれることを特徴とする請求項１１に記載の分散環境管理システム。