JP3833117B2 - サーバ決定方法及び装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
従来、複数のサーバをネットワークで接続して1つのシステムとして運用するクラスタシステムが使用されている。このクラスタシステムを構成する各サーバはノードと呼ばれる。クラスタシステムは、障害が発生したノードを排除し、そのノードが遂行していた業務を正常な他のノードに引継ぐ(譲渡)ことで、システム規模を縮退しながらも正常に動作するようにし、システム全体の可用性を保証している。
【０００２】
またクラスタシステムは、各ノードが独立したＯＳをもち、ノード間の通信制御や状態通知、ノード間で一貫性と一元性の実現、更にノードの引継ぎを行うクラスタ制御のソフトウェアをＯＳ上に配置し、ユーザアプリケーションをＯＳ上で運用する。このようにクラスタシステムが独立したＯＳで動作するノードで構成されるため、各ノードごとに資源の定義や運用を設定し、運用中に各ノードの状態を監視するクラスタ管理サーバが必要になる。
【従来技術】
【０００３】
このクラスタ管理サーバは、クラスタシステムの設定、運用、監視をＷＷＷブラウザで実現する。ＷＷＷブラウザは、ＷＷＷサーバ機能をもったクラスタ管理サーバに対し管理画面を表示するアプレットを要求し、アプレットに設定、指示された要求をクラスタ管理サーバから各ノードに指示し、また各ノードの状態をＷＷＷブラウザに表示して監視することができる。
【０００４】
このためクスラタシステムでは、ノード群の中のいずれかのノードに、各ノードの設定、運用、監視を行うクラスタ管理サーバの役割を持たせるようにしている。また通常の運用中に各ノードの設定、運用、監視を行うクラスタ管理サーバを主サーバとし、何らかの原因で主サーバが業務遂行が不可能となった場合にクラスタ管理業務の一部又は全部を引継ぐ副サーバを設け、クラスタシステムの信頼性を向上させている。
【発明が解決しようとする課題】
【０００５】
ところで、従来の各サーバのクラスタ管理業務を行う主サーバとそのバックアップを行う副サーバは、システム構成時にハードウェア構成やアプリケーションの割振り等を考慮して余裕のあるノードに固定的に決定している。しかしながら、主サーバと副サーバの両方が障害等によって業務遂行が不可能になった場合、システム管理者がＷＷＷブラウザを使用してシステムを監視し、構成を変更することができず、システム全体の業務に支障を来す問題があった。
【０００６】
本発明は、ノードの設定や監視等の特定業務を運用する主サーバとそのバックアップ業務を運用する副サーバを、候補となっているノード群の中からの各ノードが自立的に決定してシステム運用の信頼性を向上することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、ネットワークを介して複数のノードを接続したクラスタシステム中に、ある特定業務を運用する唯一のサーパの存在を決定するノード決定方法である。
【０００８】
本発明のノード決定方法は、まずクラスタシステムの各ノードを、特定業務を運用可能な主サーバ候補ノード群と、特定業務のバックアップ業務を運用可能な副サーバ候補ノード群と、特定業務及びバックアップ業務から除外された候補外ノード群とにグループ分けする。
【０００９】
次に主サーバ候補ノード群に属するサーバの各々は、立ち上げ時に、主サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、主サーバ候補ノード群の中に他のサーバにより承認された唯一の主サーバを存在させる。
【００１０】
また副サーバ候補ノード群に属するサーバの各々は、立ち上げ時に、副サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、これによって副サーバ候補ノード群の中に他のサーバにより承認された唯一の副サーバを存在させる。
【００１１】
このようにシステム立ち上げ時の主サーバあるいは副サーバが存在しない状態においては、主サーバ候補ノード群及び副サーバ候補ノード群は、それぞれの状態を判断して主サーバあるいは副サーバを選出することができ、サーバ候補となるノードが存在する限り、主サーバ又は副サーバが障害等で停止しても、新たな主サーバ又は副サーバを選出して特定業務を引継ぐことができ、システムの可用性が向上する。
【００１２】
また主サーバ又は副サーバは、立ち上げ後の運用開始に、他のノードに対し定期的に特定業務の運用を報告して主サーバ又は副サーバの権利を主張し、他のノードから同様な主サーバ又は副サーバの権利を主張する報告を受信した際に、複数の主サーバの存在又は複数の副サーバの重複起動を認識して、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、これによって主サーバ又は副サーバ候補ノード群の中に他のサーバにより承認された唯一の主サーバ又は副サーバを存在させる。
【００１３】
このように主サーバあるいは副サーバは定期的な権利を主張する旨の通知を監視することで、立ち上げ後の運用開始時に主サーバ又は副サーバが重複起動された異常を認識し、同時に存在する複数の主サーバ又は副サーバを新たな立候補ノード群とすることで、ノードの立ち上げ時と同様にして主サーバ又は副サーバの唯一性を保証できる。
【００１４】
更に、主サーバ又は副サーバは、運用中に、他のノードに対し定期的に特定業務の運用を報告して主サーバ又は副サーバの権利を主張し、他のノードから同様な主サーバ又は副サーバの権利を主張する報告を受信した際に、複数の主サーバ又は複数の副サーバの存在を認識し、自己の広報情報を他の全てのノードに提示して立候補し、自己の広報情報と他のノードからの広報情報との比較により、他のノードが主サーバ又は副サーバに適していると判断した場合は、適切な時間に特定業務を停止して他のサーバに主サーバ又は副サーバの権利を譲渡する。
【００１５】
このため運用状況が変動したとしても、その変動した状況が一定期間で安定した場合、その状況に見合ったノードが新しい主サーバもしくは副サーバとして業務を遂行することかできる。
【００１６】
ここで主サーバ候補ノード群は、特定業務を運用する上で必要な資源を持つか、又は特定業務を積極的に運用させたいノード群であり、また副サーバ候補ノード群は特定業務を運用する上で必要な資源を十分に持たないか、又は特定業務を消極的に運用させたいノード群であり、更に、候補外ノード群は、特定業務を運用する上で必要な資源を持たないか、又は前記特定業務を運用させたくないノード群である。
【００１７】
また主サーバ又は副サーバに適しているとの判断は、広報情報が資源の使用率である場合、特定業務の要求資源と広報情報の使用率から提供可能資源の許容率を当選確率として求め、自己の当選確率が他のノードの当選確率より小さい場合に、自己の広報情報の提示を停止して立候補を取り下げる。この場合、許容率をＣＰＵ、メモリ、ディスクといった資源の種別毎に求め、その内の最小の許容率を当選確率とする。
【００１８】
本発明の主サーバの特定業務は、例えばクラスタシステムの各ノードの設定、運用、監視を行うクラスタ管理業務であり、また副サーバの特定業務は主サーバのクラスタ管理業務をバックアップする業務である。
【００１９】
一方、本発明は、ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する唯一のサーバの存在を決定するノード決定装置を提供する。
【００２０】
本発明のサーバ決定装置は、クラスタシステムの各ノードを、特定業務の運用を割り当てる主サーバ候補ノード群と、特定業務のバックアップ業務を割り当てる副サーバ候補ノード群と、特定業務の運用及びバックアップから除外された候補外ノード群とにグループ分けし、主サーバ候補ノード群に属するノードの各々に主サーバ立候補処理部を設け、副サーバ候補ノード群に属するノードの各々に副サ一バ立候補処理部を設ける。
【００２１】
主サーバ立候補処理部は、主サーバ候補ノード群に属するノードの各々に、立ち上げ時に、主サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、主サーバ候補ノード群の中に他のノードにより承認された唯一の主サーバを存在させる。
【００２２】
副サーバ立候補処理部は、副サーバ候補ノード群に属するノードの各々に、立上時に、副サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、副サーバ候補ノード群の中に他のノードにより承認された唯一の副サーバを存在させる。
【００２３】
このサーバ決定装置の詳細はサーバ決定方法と基本的に同じになる。
【００２４】
また本発明は、ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する唯一のサーバの存在を決定するノード決定方法に於いて、複数のノードを、特定業務を運用可能なサーバ候補ノード群と、特定業務の運用から除外された候補外ノード群とに分割し、複数のノードの各々に、特定業務サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、ノード群の中に他のノードにより承認された唯一の特定業務サーバを存在させることを特徴とする。
【００２５】
また本発明は、ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する唯一のサーバの存在を決定するノード決定装置に於いて、複数のノードを、特定業務を運用司能なサーバ候補ノード群と、特定業務の運用から除外された候補外ノード群とに分割し、複数のノードの各々に、特定業務サーバの選出判断に必要な自己の情報を他の全てのノードに提示して立候補すると共に、自己の情報と立候補した他のノードの情報とを比較し、自己が適切でないと判断した場合に自己の情報の提示を停止して立候補を取下げ、ノード群の中に他のノードにより承認された唯一の特定業務サーバを存在させるサーバ立候補処理部を設けたことを特徴とする。
【発明の実施の形態】
【００２６】
図１は、本発明のサーバ決定方法及び装置が適用される二層構成のクラスタシステムのブロック図である。
【００２７】
図１において、クラスタシステムは、例えばノード１０−１，１０−２，１０−３，１０−４，１０−５で構成され、ＬＡＮ１８を介して接続されている。尚、実際には、３２ノード、６４ノード、１２８ノード、２５６ノード、５１２ノードといった構成をとる。ノード１０−１〜１０−５のそれぞれは、ＯＳ１２−１〜１２−５、クラスタ管理サーバ１４−１〜１４−５及びクラスタ制御部１６−１〜１６−５が設けられている。ＯＳ１２−１，１２−５としては、例えばＳｏｌａｒｉｓが使用される。
【００２８】
この図１のクラスタシステムの二層構造は、クラスタ管理サーバ１４−１〜１４−５とクラスタ制御部１６−１〜１６−５で実現される。現されるクラスタノードがノード１０−１〜１０−５のそれぞれの同一ノードに存在する形態である。ノード１０−１〜１０−５に設けているクラスタ管理サーバ１４−１〜１４−５のそれぞれは、インターネットやイントラネット等のネットワーク２６を介して接続したクライアント２０のＷＷＷブラウザ２４及びクラスタシステムの設定、運用、管理を行うことができる。
【００２９】
即ち、クライアント２０のＷＷＷブラウザ２４がＷＷＷサーバ機能を持つクラスタ管理サーバ１４−１〜１４−５に対し、クラスタ管理に必要な設定、運用画面を表示するＪａｖａアップレットを要求し、このアプレットに設定指示された要求をクラスタ管理サーバ１４−１〜１４−５からクラスタノードとしてのクラスタ制御部１６−１〜１６−５に指示する処理を行う。またクラスタ管理サーバ１４−１〜１４−５は、ＷＷＷサーバ上においてｈｔｔｐプロトコルによって要求されたクラスタ設定画面及びクラスタ運用画面をＷＷＷブラウザ２４に配信すると同時に、設定された内容に従ってクラスタ制御部１６−１〜１６−５で実現されるクラスタノードにコマンドを発行し、その結果をWWWブラウザ２４に通知する。
【００３０】
このようなクラスタシステムにあっては、ノード１０−１〜１０−５に設けているクラスタ管理サーバ１４−１〜１４−５のうちのいずれか１つが主サーバとして決定され、主サーバによってノード１０−１〜１０−５の設定と運用が行われる。また主サーバとして決定したクラスタ管理サーバを持つノードの停止に対し、クラスタ管理サーバの機能をバックアップのために引き継ぐ待機用の副サーバが主サーバ以外に決定される。本発明のサーバ決定処理にあっては、クラスタシステムの立ち上げ時に、ノード１０−１〜１０−５のクラスタ管理サーバ１４―１〜１４−５を対象に唯一の主サーバと副サーバの決定を立候補処理に従って実行する。このため本発明にあっては、クラスタシステムのノード１０−１〜１０−５を主サーバ候補ノード群２８、副サーバ候補ノード群３０及び候補外ノード群３２にグループ分けしている。
【００３１】
主サーバ候補ノード群２８はクラスタ管理サーバによる管理業務を運用可能なノード群である。一般的には主サーバ候補ノード群２８は、ある特定業務を運用する上で必要な資産を持つか、あるいは特定業務を積極的に運用させたいノード群ということができる。
【００３２】
副サーバ候補ノード群３０は、クラスタ管理業務のバックアップ業務を運用可能な待機系としてのノード群である。この副サーバ候補ノード群３０は、一般的には主サーバの特定業務を運用する上で必要な資源を十分に持たないか、または特定業務を消極的に運用させたいノード群ということができる。更に候補外ノード群３２はクラスタ管理業務及びそのバックアップ業務の運用から除外されたノード群であり、一般的には主サーバの特定業務を運用させたくないノード群ということができる。
【００３３】
図１のクラスタシステムにあっては、ノード１０−１〜１０−４がネットワーク２６を介してクライアント２０のＷＷＷブラウザ２４に接続されており、ノード１０−５は接続されていないことから、ＷＷＷブラウザ２４によって運用管理ができないノード１０−５は候補外ノード群３２に属する。これに対しWWWブラウザ２４から運用管理ができるノード１０−１〜１０−４は、主サーバ候補ノード群２８及び副サーバ候補ノード群３０の対象となり、この実施形態ではノード１０−１，１０−２の２つを主サーバ候補ノード群２８に割り当て、ノード１０−３，１０−４を副サーバ候補ノード群３０に割り当てている。この主サーバ候補ノード群２８と副サーバ候補ノード群３０の振り分けは、主サーバ候補ノード群２８に含まれるノードの方がクラスタ制御部の負荷が少なく、クラスタ管理サーバを設けても処理に余裕のあるノードということができる。
【００３４】
このような主サーバ候補ノード群２８と副サーバ候補ノード群３０の振り分けは、システム立ち上げ時の初期設定で予め定めておく。また二層構造のクラスタシステムは比較的小規模なシステムを対象とし、特別なクラスタ管理サーバのノードを設置しない構成となる。
【００３５】
図２は、本発明のサーバ決定処理が適用される三層構成のクラスタシステムのブロック図である。この三層構成のクラスタシステムは、クラスタ管理サーバとクラスタノード
が別ノードになる形態を取る。この三層構成の形態は、大規模システムでクラスタを集中管理した場合やクラスタノードにクラスタ管理サーバとしての負荷を負わせたくないような構成である。
【００３６】
図２において、クラスタシステムは、クラスタ管理サーバとクラスタ制御部の両方を備えたノード１０−１〜１０−４と、クラスタ管理サーバを持たないノード１０−１１〜１０−１５で構成され、これらのノード１０−１〜１０−４及び１０−１１〜１０−１５はＬＡＮを介して接続されている。ノード１０−１〜１０−４，１０−１１〜１０−１５は、ＯＳ１２−１〜１２−４，１２−１１〜１２−１５とクラスタノードとして機能するクラスタ制御部１６−１〜１６−４，１６−１１〜１６−１５を備えている。更にノード１０−１〜１０−４についてはクラスタ管理サーバ１４−１〜１４−４が設けられている。
【００３７】
このような三層構成のクラスタシステムにあっては、ノード１０−１〜１０−４がネットワーク２６を介してクライアント２０のＷＷＷブラウザ２４に接続されて遠隔的にクラスタ管理ができることから、主サーバ候補ノード群２８及び副サーバ候補ノード群３０の対象となる。この例ではノード１０−１〜１０−１を主サーバ候補ノード群２８に分類し、ノード１０−３，１０−４を副サーバ候補ノード群３０に分類している。更にクラスタ管理サーバを持たないノード１０−１１〜１−１５は候補外ノード群３２に分類することになる。
【００３８】
図３は、図１の二層構成のクラスタシステムを対象に、ノード１０−１〜１０−５のクラスタ管理サーバ１４−１〜１４−４に設けられている本発明によるサーバ決定のための機能構成を示している。図３において、ノード１０−１〜１０―５には、サーバ決定処理のためにサーバ立候補処理部３４−１〜３４−５と通信部３６−１〜３６−５が設けられる。
【００３９】
また主サーバ候補ノード群２８に属するサーバ１０−１，１０―２のサーバ立候補処理部３４−１，３４−２には、主サ一バとして決定された際にセットされる主サーバフラグ３８−１，３８−２が設けられている。また副サーバ候補ノード群３０に属する１０−３，１０−４のサーバ立候補処理部３４−３，３４−４にも、副サーバとして決定された際にオンする副サーバフラグ３８−３，３８−４が設けられている。これに対し候補外サーバノード群３２に属するノード１０−５のサーバ立候補処理部３４−５については、サーバ決定の対象とならないことからサーバフラグは設けられていない。
【００４０】
図４は、図１の二層構成のクラスタシステムにおける主サーバ候補ノード群と副サーバ候補ノード群のグループ分けの他の実施形態である。図３の主サーバ候補ノード群２８と副サーバ候補ノード群３０のグループ分けにあっては、ＷＷＷブラウザからアクセス可能なノード１０−１〜１０−４について２2つずつグループ分けしているが、図４の実施形態にあってはノード１０−１〜１０−４の４つのノードを主サーバ候補ノード群２８にグループ分けし、４つのノード間で立候補方式により主サーバの決定を行う。また副サーバ候補ノード群３０については、図３の場合と同様、ノード１０−３，１０−４との間で副サーバの決定を立候補方式により行うことになる。
【００４１】
図５は、図３及び図４に示したノード１０−１のサーバ立候補処理部３４−１の機能ブロック図である。この構成は他のサーバ立候補処理部３４−２〜３４−５についても同じである。図５において、サーバ立候補処理部３４―１は、状態監視部４０、受付処理部４２、広報送信部４４、広報受信部４５、当選予測部４６、報告送信部４８及び報告受信部５０で構成される。状態監視部４０はノードの電源投入による立ち上げ時に、主サーバを決定するためのサーバ立候補処理を起動して、主サーバ決定の全体的な制御を行う。状態監視部４０によるサーバ立候補処理は、次の３つのフェーズで行われる。
【００４２】
（１）ノード立ち上げ時
（２）ノード立ち上げ後の運用開始時
（３）運用開始中
【００４３】
このうちノード立ち上げ時のサーバ実行処理が基本的な処理であり、残りのノード立ち上げ後の運用開始時の処理及び運用中の処理は、クラスタシステムの中に２以上の主サーバが存在した異常状態を解消するための処理となる。状態監視部４０はノード立ち上げによる初期処理が済むと、受付処理部４２に対し受付処理の開始を指示する。受付処理部４２には受付タイマ５２が設けられており、受付開始から終了までの予め定めた時間管理を行う。即ち、受付処理部４２は、運用中の他のノードが主サーバ又は副サーバに決定された状態で、受付２５を開始し、受付期間中に他のノードから主サーバ又は副サーバであるこのと権利を主張する報告情報を受信すると、受付タイマ５２をリトリガして受付処理を繰り返す。
【００４４】
これに対し受付期間中に他のノードから主サーバ又は副サーバであることの権利を主張する報告情報を受信しない場合は、主サーバ又は副サーバが決定されていない状態と判断し、受付期間の終了により主サーバ又は副サーバを決定するための立候補処理に移行させる。この受付期間の終了により主サーバ又は副サーバを決定するために立候補処理に移行させるのは、各サーバを立ち上げるシステム起動時に生ずる。広報送信部４４は受付処理部４２の受付タイマ５２による受付期間終了（選挙開始判断）に基づき、ＬＡＮ１８を介して他の全てのノードに対し主サーバの選出判断に必要な自己の広報情報５４を送信する。この広報情報５４としては、例えば図６に示す情報内容を持つ。
【００４５】
図６の広報情報５４は、自己ノードにおける資源の使用状態を表す。広報情報５４は資源識別番号（ＲＩＤ）、資源番号（ＲＮ）、仕様番号（ＳＩＤ）、平均使用率（ＡＶＥ）、最大使用率（ＭＡＸ）を含む。資源識別番号（ＲＩＤ）として、この広報情報５４にあっては１番から４番を持っており、１番はＣＰＵ、２番はメモリ、３番はディスク、４番はネットワークである。資源番号（ＲＮ）は同じ資源識別番号について資源の数を表わす。このうち資源番号１番、２番については、ＣＰＵメモリは1つずつであることから資源番号＃１が示される。資源識別番号３番、４番のディスクとネットワークについては、２つずつ持つことから資源番号は＃１，＃２となる。次の仕様番号（ＳＩＤ）は使っている資源の名称及び性能を表しており、仕様番号（ＳＩＤ）に対応した使用テーブルの情報を見ることで取得できる。次の平均使用率（ＡＶＥ）と最大使用率（ＭＡＸ）はパーセント表示であり、統計的なデータとして提供される。
【００４６】
再び図５を参照するに、広報送信部４４より他のノードに対し広報情報５４を提示することは、主サーバを決める選挙に対する立候補を意味する。即ちサーバ立候補処理部３４−１は、主サーバを決める選挙に対する立候補の表明として広報送信部４４より広報情報５４を送信することになる。広報受信部４５は他のノ'一ドより立候補として提示された広報情報５４をＬＡＮ１８から受信して当選予測部４６に提示する。当選予測部４６には選挙タイマ５８とサーバフラグ６０が設けられている。
【００４７】
選挙タイマ５８は受付処理部４６の受付タイマ５２による受付終了に基づいて起動し、一定の選挙期間を設定する。当選予測部４６は広報送信部４４から送信する自己の広報情報５４、広報受信部４５で受信した他のノードの立候補による広報情報、及び状態監視部４０より提供されるクラスタ管理サーバの処理に必要な業務要件情報５６を用いて当選予測を行う。この当選予測は、自己の広報情報５４と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報54の提示を停止して立候補を取り下げる。このような他のノードとの比較により適切でないと判断した場合に立候補を取り下げることで、結果的に、選挙期間が終了した際に複数ノードの中に唯一のサーバ候補が残り、最後に残った候補が主サーバとして選出されることになる。
【００４８】
ここで当選予測部４６による処理は、自己の広報情報と他のノードの広報情報からそれぞれ当選確率を算出し、
（自己の当選確率）＜（他の当選確率）
である場合に立候補を取り消す。この当選確率は次式で与えられる。
当選確率＝ＭＩＮ（許容率） （１）
【００４９】
ここで許容率は、図６に示した広報情報５４における資源識別番号１〜４ごと、即ち資源の種類ごとに算出され、そのうちの最も小さい許容率を当選確率としている。この当選確率を示す許容率は次式で算出される。
許容率＝（資源量Ｖ／要求量ＲＶ）×重み係数Ｗ×１００％ （２）
【００５０】
この（２）式における資源量Ｖ，要求量ｒｖ、重み係数Ｗは、状態監視部４０より業務要件情報５６即ちクラスタ管理サーバの運用に必要な業務要件情報５６から算出される。
【００５１】
図７は業務要件情報５６の一例である。この業務要件情報５６は、資源識別番号１〜４に対応して、クラスタ管理サーバの運用に必要な資源要求量ＲＶ、閾値係数ＴＨ及び重み係数Ｗを定めている。
【００５２】
ここで（２）式の資源量Ｖは次式で算出される。
資源量Ｖ＝（１００−使用率Ｕ）×性能係数ＰＦ （３）
【００５３】
ここで（３）式の使用率Ｕは次式で与えられる。
使用率Ｕ＝平均使用率ＡＶ＋最大使用率ＭＡＸ×閾値係数ＴＨ （４）
【００５４】
この（４）式の平均使用率，最大使用率は図６の広報情報５４から得られ、また閾値係数ＴＨは図７の業務要件情報５６から得られる。更に（３）式の性能係数ＰＦは、予め準備した性能表を資源の使用番号ＳＩＤで参照することで得ることができる。
性能係数ＰＦ＝性能表［仕様番号ＳＩＤ］ （５）
【００５５】
したがって当選予測部４６にあっては、自己の広報情報の資源識別番号ごとに（２）式〜（５）式に従って許容率を算出し、資源の種類ごとに求めた許容率の中から（１）式に従って最小の許容率を選択して、これを当選確率とする。最終的に自己の当選確率と他のノードの当選確率を比較し、自己の当選確率が小さければ広報情報５４の送信を停止して立候補を取り下げる。
【００５６】
立候補の取り下げは当選予測部４６に設けているサーバフラグ６０をオフする。これに対し自己の当選確率が他のノードの当選確率より大きい場合には立候補を取り下げず、サーバフラグをオンしたまま選挙期間の終了を待つ。もちろん、選挙期間中における他のノードとの比較による当選予測の判断は、同時に立ち上げられている複数のノードとの間で行われることになる。選挙タイマ５８による選挙期間が終了し、そのとき立候補が取り下げられずにサーバフラグ６０がオンとなっていた場合には、これによって自分自身が主サーバに決定されたことになる。
【００５７】
自らが主サーバに決定された場合には、選挙期間終了後の運用中において報告送信部４８より他のノードに対し、自分自身が主サーバであることを主張する報告情報６２を定期的に送信する。これによって、主サーバに決定されなかった他のノードにあっては、報告情報６２を送信したノードが主サーバであることを常時認識することができる。報告受信部５０は他のノードからの主サーバであることの主張を示す報告情報を受信して状態監視部４０に通知する。
【００５８】
報告送信部４８より報告情報６２を他のノードに定期的に送信している際に、報告受信部５０で他のノードより主ノードであることを主張する報告情報を受信した場合には、状態監視部４０においてクラスタシステムに２つの主サーバが存在する異常状態であることが認識される。このようにクラスタシステムに２以上の主サーバが存在する異常が認識された場合には、この異常状態を解消するため、状態監視部４０は受付処理部４２に対し受付処理の開始を指示し・改めて主サーバを決定するためのサーバ立候補処理を行わせる。
【００５９】
このシステム内に２以上の主サーバが存在する異常は、報告情報を送信するネットワークの一部が故障（あるスイッチングハブの故障）してしまうと、ノード群が２つに分割されてしまい、分割されたノード群の各々で主サーバが決定され、ネットワークの故障が復旧して１つのノード群に戻ったときに起きる。例えばネットワークとしてスイッチングハブＳＨ３を介して２つのスイッチングハブＳＨ１、ＳＨ２を設け、スイッチングハブＳＨ１に複数のノードを接続し、またスイッチングハブＳＨ２に他の複数のノードを接続していた場合、スイッチングハブＳＨ３が故障すると、スイッチンクバブＳH１、ＳＨ２の間の送信が不能となり、各々に接続している２つのノード群に分かれてしまう。このため分かれた２つのノード群の各々で主サーバが決定される。その後にスイッチングハブＳＨ３が復旧してスイッチバブＳＨ１，ＳＨ２間での送信が可能なると、１つに戻ったノード群の中に２つの主サーバが存在する異常状態となってしまう。
【００６０】
このようネットワークの一部の故障に伴って復旧時にシステム内に２つの主サーバが存在する状態となった場合には、主サーバとなった２つのノードは他のノードより主サーバであることを主張する報告情報を受信して主サーバが複数存在する異常と認識し、他のサーバからの報告情報を立候補と見なして、立ち上げ時と同様、受付処理部４２の起動によりサーバ立候補処理を開始するようになる。
【００６１】
図８はシステム立ち上げ時におけるサーバ立候補処理のタイムチャートであり、例えば図２のように、主サーバ候補ノード群２８にサーバ１０−１〜１０−４を含め、そのうちの３つのノード１０−１〜１０−３で主サーバを決定するサーバ立候補処理を行った場合を例に取っている。
【００６２】
図８において、まずノード１０−１，１０−２の２つがステップＳ１，Ｓ１１の同時刻で立ち上げられたとする。この立ち上げに続いて、ステップＳ２，Ｓ１２でそれぞれ受付処理を開始する。この受付処理は既に主ノードが決定されている場合の報告を受信して受付期間を更新する処理であり、もし他のノードより報告があれば、主ノードは決定されていることから立候補は行わないようにする。
【００６３】
この場合には、対象となる３つのノード１０−１〜１０−３は運用に入っていないことから、ステップＳ２，Ｓ１２において他のノードより主ノード決定後の報告情報は受信されず、したがってノード１０−１，１０−２は受付期間の終了でそれぞれステップＳ３，Ｓ１３の立候補処理を行う。
【００６４】
この立候補の処理は自己の広報情報を他のノードに送信する処理である。この場合にはノード１０−１のステップＳ３の立候補によって、その広報情報がノード１０−２，１０−３に提示される。このときノード１０−２はステップＳ１３で立候補しており、この状態でノード１０−１からの立候補による広報情報を受信するため、ステップＳ１４で自己の広報情報とノード１０−１から受信した広報情報に基づいて、それぞれの当選確率を求める。このステップＳ１４にあっては、ノード１０−２の当選確率がノード１０−１の当選確率より大きい場合であり、立候補の取り下げは行わず、ステップＳ１４の当選予測に続いてノード１０−１は、他のノード１０−１，１０−３に対し自己の広報情報を送信する。
【００６５】
一方、ノード１０−１がステップＳ３で立候補に基づいて送信した広報情報はノード１０−３でも受信されるが、このときノード１０−３はステップＳ１０２で受付処理を行っており、ステップＳ１０３の立候補前であることから、ノード１０−１からの広報情報に基づく当選予測は行わない。ノード１０−２がステップＳ１０４の当選予測で自己の当選確率が高いため、立候補を取り下げることなく、ステップＳ１４の当選予測に続いて他のノード１０−１、１０−３に対しそれぞれ自己の広報情報を送信する。
【００６６】
このときノード１０−１はステップＳ３で立候補が済んでいることから、ノード１０−２からの広報情報を受信し、ステップＳ４で当選予測を行う。ステップＳ４の当選予測においてノード１０−１の当選確率がノード１０−２の当選確率より小さかったとすると、この場合にはステップＳ５で立候補を取り消し、それ以降の他のノードに対する自己の広報情報の送信を停止する。これに対し、ステップＳ１４の当選予測で立候補を取り下げることのなかったノード１０−２にあっては、それ以降の一定周期で自己の広報情報を他のノードに対し繰り返し送信している。
【００６７】
一方、立ち上げが最も遅くなったノード１０−３にあっては、ステップＳ１０３で立候補を行い、この立候補に基づき他のノードに自己の広報情報を送信し、また現在立候補を取り下げていないノード１０−２よりその広報情報を受信すると、ステップＳ１０４で当選予測を行う。ステップＳ１０４の当選予測の結果、ノード１０−３の当選確率がノード１０−２の当選確率より小さかったとすると、ステップＳ５で立候補を取り消し、それ以降の自己の広報情報の送信を停止する。その後にノード１０−２においてステップＳ１３の立候補で起動した選挙タイマによる選挙期間が終了すると、ステップＳ１５で立候補終了となる。
【００６８】
このタイミングでノード１０−１はステップＳ５で既に立候補を取り消しており、またノード１０−３もステップＳ１０５で既に立候補を取り消しているため、立候補を取り消さなかったノード１０−２のみが候補として残り、これによって選挙期間が終了した時点でノード１０−２が主サーバに決定される。
【００６９】
ステップＳ１５の立候補終了によりノード１０−２が主サーバに決定されると、ノード１０−２は一定周期ごとに他のノード１０−１，１０−３に対し自分自身が主サーバである権利を主張する報告情報の送信を繰り返し行う。これに対しノード１０−１，１０−３にあっては、受付タイマによる受付処理を行っている。この受付処理における受付期間の間に、主サーバとなったノード１０−２より主サーバの権利を主張する報告情報が受信されると、受付タイマをリトリガ（更新）し、新たな受付期間の開始を行う。このため、もし主サーバに決定されたノード１０−２が障害等により停止した場合には、受付タイマによる受付期間の間に主サーバの権利を主張する報告情報が受信できず、受付期間終了により主サーバの停止を認識し、この時点で新たに主サーバを決めるための立候補を行うことになる。
【００７０】
図９は本発明によるサーバ決定処理の全体的な処理のフローチャートである。
【００７１】
図９において、まずステップＳ１で受付処理を行い、主サーバが決定されていない状態では主サーバの権利を主張する報告情報が受信されないことから受付処理を終了し、ステップＳ２の立候補処理とステップＳ３の広報処理を並行して行う。ステップＳ２の立候補処理にっいてステップＳ４で立候補終了が判別されると、ステップＳ５で主サーバ決定後の報告処理を行うことになる。
【００７２】
図１０は図９のステップＳ１の受付処理の詳細を示したフローチャートである。まずステップＳ１で受付を開始すると、ステップＳ２で受付タイマの起動により受付期間の計数を開始する。次にステップＳ３で受付期間確認を行い、ステップＳ４で受付期間終了でなければ、ステップＳ５で他のノードからの主サーバの権利を主張する報告情報の受付を行い、ステップＳ６で報告情報の受信があれば、ステップＳ２に戻り、受付タイマを再起動して新たな受付期間の計数を再開する。
【００７３】
これに対しステップＳ６で報告情報の受信がなかった場合には、ステップＳ３で受付期間を確認し、この場合には受付タイマを再起動することなく、ステップＳ４の受付期間終了か否かのチェックと、ステップＳ５の報告受付の受信確認を繰り返す。ステップＳ４で受付期間中に主サーバの権利を主張する報告受信がなかった場合にはシステム内に主サーバが存在しないものと判断し、ステップＳ７で受付を終了し、図９のステップＳ２の立候補処理及びステップＳ３の広報処理に進む。
【００７４】
ここで図８のタイムチャートに示したノード１０−１〜１０−３に示した立ち上げ後の受付処理にあっては、この状態では主ノードを主張する報告情報の受信はないことから、必ず受付期間の終了となって次の広報処理及び立候補処理に移行することになる。これに対し主サーバを決定した後の運用中に報告情報が受信されずに受付期間が終了した場合には、主サーバを決定したノードが障害等により停止した場合であることから、この場合には再度、主サーバを決めるための立候補及び広報処理を行うことになる。
【００７５】
更に図１０の受付処理は基本的には主サーバに決定されていないノードで行われるものであるが、主サーバに決定されたノードについては、ステップＳ５で他のノードからの報告受付を行い、もしステップＳ６で受信があった場合にはシステム内に２つの主サーバが存在する異常状態であることから、この場合には強制的にステップＳ７の受付終了により他のノードからの主サーバの権利を主張する報告情報の受信を立候補と見なして、図９のステップＳ２の立候補処理及びステップＳ３の広報処理に入るようにする。
【００７６】
図１１は図９の立候補処理１２の詳細のフローチャートである。まずステップＳ１で受付終了に基づいて立候補を開始し、ステップＳ２で選挙タイマを起動して選挙期間を開始する。続いてステップＳ３で選挙期間を確認し、ステップＳ４で選挙期間終了か否かチェックする。選挙期間中であれば、ステップＳ５で他のノードからの広報の受信処理を割り当て、ステップＳ６で他のノードから広報受信があれば、ステップＳ７で当選予測を行う。
【００７７】
ステップＳ７の当選予測の結果、当選可能であればステップＳ２に戻り、新たな選挙期間の開始即ち選挙タイマを再起動して新たな選挙期間をスタートさせる。これに対しステップＳ８で当選予測の結果、当選可能でなかった場合には、ステップＳ９で広報停止指示を行った後、ステップＳ１０で立候補取り消し、具体的にはサーバフラグを立候補時のオンからオフして立候補を取り消す。
【００７８】
一方、選挙期間中に他のノードから広報情報を受信しなかったり、あるいは広報情報を受信して当選予測を行い当選予測可能であった状態で選挙期間が終了した場合には、ステップＳ４からステップＳ１１に進み、広報停止指示を行った後、ステップＳ１２で立候補終了とする。この場合には立候補でオンしたサーバフラグはオン状態を維持し、その結果、自分自身が主サーバに決定された状態となる。
【００７９】
図１２は図９のステップＳ３の広報処理の詳細である。受付期間終了に伴って、広報処理をステップＳ１で開始すると、ステップＳ２で広報処理に関する停止指示を確認する。ステップＳ３で停止指示がなければ、ステップＳ４で広報を他のノードに送信する。これに対し図１１の立候補処理におけるステップＳ９またはＳ１１で広報停止指示があると、ステップＳ３でこの停止指示が判別され、ステップＳ５に進んで広報停止を行う。
【００８０】
このような広報処理により、図１１の立候補処理において立候補をステップＳ１０で取り下げない場合は広報停止指示がないことから、図１２の広報処理においてステップＳ２，Ｓ３，Ｓ４の処理の繰り返しにより定期的に他のノードに対し広報送信が繰り返される。これに対し図１１の立候補処理で立侯補取り消しに先立って広報停止を行ったり選挙期間終了で広報停止を行うと、図１２のステップＳ５に進んで広報停止となる。
【００８１】
図１３は図９のステップＳ５の報告処理の詳細なフローチャートである。この報告処理にあっては、ステップＳ４で立候補処理により主サーバに決定された場合に報告開始となり、ステップＳ２で主サーバであることの権利を主張する報告情報を他のノードに配布し、このステップＳ１，Ｓ２の処理を定期的に繰り返す。この報告処理は主サーバに決定されたノードのみから行われるものであり、もし主ノードに決定されたサーバが障害等により停止すると、定期的な報告配布が停止することで他のノードは主サーバが停止したことを認識し、受付処理により再度、主ノードを残された複数のノード間で決定する立候補処理を行うことになる。
【００８２】
以上のサーバ決定処理は、図３，図４の主サーバ候補ノード群２８に属するノ一ド間における処理を例に取るものであったが、副サーバ候補ノード群３０に属するノードについても全く同様な副サーバを決定するための処理が行われる。このためクラスタシステムにおいて、立ち上げ時に主サーバ及び副サーバが決定され、運用中に主サーバと副サーバの２つのノードが同時に停止するような異常が発生しても、主サーバ候補ノード群２８及び副サーバ候補ノード群３０にノードが存在する限り、主サーバ及び副サーバとして最適なノードが立候補処理により自動的に決定されて唯一の主サーバ及び副サーバとして常に存在することとなり、ＷＷＷブラウザによるクラスタシステムの設定と運用の管理業務の信頼性を大幅に向上することができる。
【００８３】
また上記の実施形態は、主サーバ候補ノード群と副サーバ候補ノード群に分けて主サーバ及び副サーバを決定する場合を例に取るものであったが、1つのノード群を対象にその中に対象とする特定業務例えばクラスタ管理業務を割り当てるサーバを決定する処理であっても全く同様にして行うことができる。また上記の実施形態は、クラスタシステムのクラスタ管理サーバについて主サーバと副サーバを決定する場合を例に取るものであったが、主サーバ及び副サーバを決定する業務としてはクラスタ管理業務に限定されず、必要に応じて適宜の業務、例えばユーザアプリケーションについても同様にして主サーバと副サーバを立候補処理によりダイナミックに決めるようにしても良い。
【００８４】
更に上記の実施形態にあっては、立候補したノードから主サーバまたは副サーバを決める当選予測として各サーバの当選確率を求めて比較しているが、当選確率以外の立候補したノード間で最適なノードを選択できる情報の提示による比較処理で最適なノードを決定するようにしても良い。例えば要求された業務に割り当てることのできる資源の一覧表や、現在要求された業務を割り当てた場合に支障を来す度合など、立候補したノード間で最適なノードを選択できるような情報を提示しあって立候補を取り下げるか否か判断するようにすれば良い。
【００８５】
また本発明は上記の実施形態に限定されず、その目的と利点を損なわない適宜の変形を含む。更に本発明は上記の実施形態に示した数値による限定は受けない。
【発明の効果】
【００８６】
以上説明してきたように本発明によれば、システム構成時に主サーバ候補のノード群と副サーバ候補のノード群とにグループ分けしておくことで、システムを立ち上げると候補ノードの中での立候補により特定の業務例えば管理業務に最適なノードが主サーバ及び副サーバとして自動的に決定され、更に運用中に主サーバ及びまたは副サーバを決定したノードが停止したような場合にも、残されたノード間で最適なノードが主サーバ及びまたは副サーバに決定され、主サーバ及び副サーバを決定したノードが停止してシステム全体の業務が遂行不可能になるような事態を確実に回避し、例えばクラスタシステムにおける設定、運用といった管理業務の信頼性を向上し、システムとしての可用性を大幅に向上することができる。
【図面の簡単な説明】
【００８７】
【図１】本発明が適用される２層構成のクラスタシステムのブロック図
【図２】本発明が適用される３層構成のクラスタシステムのブロック図
【図３】主サーバ候補ノード群と副サーバ候補ノード群を分けた本発明によるサーバ決定の機能ブロック図
【図４】主サーバ候補ノード群に副サーバ候補ノード群を含めた本発明によるサーバ決定の機能ブロック図
【図５】本発明のサーバ決定を行うサーバ立候補処理部の機能ブロック図
【図６】図５のサーバ立候補処理部が他のノードに通知する広報情報の説明図
【図７】当選予測に使用するクラスタ管理業務の業務要件情報の説明図
【図８】３つのノードを例にとった立ち上げ時のサーバ決定処理のタイムチャート
【図９】サーバ立候補処理部による全体的なフローチャート
【図１０】図９の受付け処理の詳細なフローチャート
【図１１】図９の広報処理の詳細なフローチャート
【図１２】図９の立候補処理の詳細なフローチャート
【図１３】図９の報告処理の詳細なフローチャート
【符号の説明】
【００８８】
１０：ノード
１８：ＬＡＮ
１２：ＯＳ
１４：クラスタ管理サーバ
１６：クラスタ制御部
２０：クライアント
２４：ＷＷＷブラウザ
２６：ネットワーク
２８：主サーバノード群
３０：副サーバノード群
３２：候補外ノード群
３４：サーバ立候補処理部
３８，６０：フラグ
４０：状態監視部
４２：受付処理部
４４：公報送信部
４５：公報受信部
４６：当選予測部
４８：報告送信部
５０：報告受信部
５２：タイマ
５８：選挙タイマ

Claims (14)

1. ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する主サーバおよび副サーバを決定するサーバ決定方法に於いて、
   前記複数のノードを、前記特定業務を運用可能な主サーバ候補ノード群と、前記特定業務のバックアップ業務を運用可能な副サーバ候補ノード群と、前記特定業務及びバックアップ業務の運用から除外された候補外ノード群とにグループ分けし、
   前記主サーバ候補ノード群に属するノードの各々は、立ち上げ時に、主サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、
   前記副サーバ候補ノード群に属するノードの各々は、立上げ時に、副サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、
   前記広報情報は資源の使用率であり、前記特定業務の要求資源と前記広報情報の使用率から提供可能資源の許容率を当選確率として求め、自己の当選確率が他のノードの当選確率より小さい場合に、自己の広報情報の提示を停止して立候補を取下げることを特徴とするサーバ決定方法。
2. 請求項１のサーバ決定方法に於いて、前記主サーバ又は副サーバは、立ち上げ後の運用開始時に、他のノードに対し前記特定業務の運用を報告して主サーバ又は副サーバの権利を主張し、他のノードから同様な主サーバ又は副サーバの権利を主張する報告を受信した際に、複数の主サーバ又は複数の副サーバの重複起動を認識し、自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げることを特徴するサーバ決定方法。
3. 請求項１記載のサーバ決定方法に於いて、主サーバ及び副サーバが決定した後、前記主サーバ又は副サーバは、運用中に、他のノードに対し定期的に前記特定業務の運用を報告して主サーバ又は副サーバの権利主張し、
   他のノードから同様な主サーバ又は副サーバの権利を主張する報告を受信した際に、複数の主サーバ又は副サーバの存在を認識して自己の広報情報を他の全てのノードに提示して立候補し、自己の広報情報と他のノードからの広報情報との比較により他のノードが主サーバ又は副サーバに適していると判断した場合は、適切な時間に特定業務を停止して他のサーバに主サーバ、又は副サーバの権利を譲渡することを特徴とするサーバ決定方法。
4. 請求項１乃至３のいずれかに記載のサーバ決定方法に於いて、
   前記主サーバ候補ノード群は、前記特定業務を運用する上で必要な資源を持つか、又は前記特定業務を積極的に運用させたいノード群であり、
   前記副サーバ候補ノード群は、前記特定業務を運用する上で必要な資源を十分に持たないか、又は前記特定業務を消極的に運用させたいノード群であり、
   更に、候補外ノード群は、前記特定業務を運用する上で必要な資源を持たないか、又は前記特定業務を運用させたくないノード群であることを特徴とするサーバ決定方法。
5. 請求項１のサーバ決定方法に於いて、前記許容率を資源の種別毎に求め、その内の最小の許容率を当選確率とすることを特徴とするサーバ決定方法。
6. 請求項１乃至３のいずれかに記載のサーバ決定方法に於いて、前記主サーバの特定業務は各ノードの設定と監視を行う管理業務であり、前記副サーバの特定業務は主サーバ管理業務をバックアップする業務であることを特徴とするサーバ決定方法。
7. ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する主サーバおよび副サーバを決定するサーバ決定装置に於いて、
   前記各ノードを、前記特定業務を運用可能な主サーバ候補ノード群と、前記特定業務のバックアップ業務を運用可能な副サーバ候補ノード群と、前記特定業務及びバックアップの運用から除外された候補外ノード群とにグループ分けし、
   前記主サーバ候補ノード群に属するノードの各々に、立上げ時に、主サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げる主サ一バ立候補処理部を設け、
   前記副サーバ候補ノード群に属するノードの各々に、立上げ時に、副サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げる副サ一バ立候補処理部を設け、
   前記広報情報は資源の使用率であり、前記特定業務の要求資源と前記広報情報の使用率から提供可能資源の許容率を当選確率として求め、自己の当選確率が他のノードの当選確率より小さい場合に、自己の広報情報の提示を停止して立候補を取下げることを特徴とするサーバ決定装置。
8. 請求項７のサーバ決定装置に於いて、立上げ時に選定された主サーバの主サーバ立候補処理部又は副サーバの副サーバ立候補処理部は、立上げ後の運用開始時に、他のノードに対し前記特定業務の運用を報告して主サーバ又は副サーバの権利を主張し、他のノードから同様な主サーバ又は副サーバの権利を主張する報告を受信した際に、複数の主サーバ又は複数の副サーバの重複起動を認識し、自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較して自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げることを特徴するサーバ決定装置。
9. 請求項８記載のサーバ決定方法に於いて、主サーバ及び副サーバが決定した後、前記主サーバ立候補処理部又は副サーバ立候補処理部は、運用中に、他のノードに対し定期的に前記特定業務の運用を報告して主サーバ又は副サーバの権利を主張し、他のノードから同様な主サーバ又は副サーバの権利を主張する報告を受信した際に、複数の主サーバ又は副サーバの存在を認識して自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と他のノードからの広報情報との比較により他のノードが主サーバ又は副サーバに適していると判断した場合は、適切な時間に特定業務を停止して他のサーバに主サーバ又は副サーバの権利を譲渡することを特徴とするサーバ決定装置。
10. 請求項７乃至９に記載のいずれかのサーバ決定装置に於いて、
    前記主サーバ候補ノード群は、前記特定業務を運用する上で必要な資源を持つか、又は前記特定業務を積極的に運用させたいノード群であり、
    前記副サーバ候補ノード群は前記特定業務を運用する上で必要な資源を十分に持たないか、又は前記特定業務を消極的に運用させたいノード群であり、
    更に、候補外ノード群は、前記特定業務を運用する上で必要な資源を持たないか、又は前記特定業務を運用させたくないノード群であることを特徴とするサーバ決定装置。
11. 請求項７のサーバ決定装置に於いて、前記主サーバ立候補処理部又は副サーバ立候補処理部は、前記許容率を資源の種別毎に求め、その内の最小の許容率を当選確率とすることを特徴とするサーバ決定装置。
12. 請求項７乃至９に記載のいずれかのサーバ決定装置に於いて、前記主サーバの特定業務は前記クラスタシステムの各ノードの設定と監視を行う管理業務であり、前記副サーバの特定業務は主サーバの管理業務をバックアップする業務であることを特徴とするサーバ決定装置。
13. ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する唯一のサーバの存在を決定するサーバ決定方法に於いて、
    前記各サーバを、前記特定業務を運用可能とするサーバ候補ノード群と、前記特定業務の運用から除外された候補外ノード群とで構成し、
    前記サーバ候補ノード群に属するノードの各々は、特定業務サーバの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の広報情報の提示を停止して立候補を取下げ、
    前記広報情報は資源の使用率であり、前記特定業務の要求資源と前記広報情報の使用率から提供可能資源の許容率を当選確率として求め、自己の当選確率が他のノードの当選確率より小さい場合に、自己の広報情報の提示を停止して立候補を取下げることを特徴とするサーバ決定方法。
14. ネットワークを介して接続した複数のノードの中に、ある特定業務を運用する唯一のサーバの存在を決定するのサーバ決定装置に於いて、
    前記複数のノードを、前記特定業務の運用を割当てるサーバ候補ノード群と、前記特定業務の運用から除外された候補外ノード群とに分割し、
    前記サーバ候補ノード群に属するノードの各々は、特定業務サ一バの選出判断に必要な自己の広報情報を他の全てのノードに提示して立候補すると共に、自己の広報情報と立候補した他のノードの広報情報とを比較し、自己が適切でないと判断した場合に自己の情報の提示を停止して立候補を取下げ、
    前記広報情報は資源の使用率であり、前記特定業務の要求資源と前記広報情報の使用率から提供可能資源の許容率を当選確率として求め、自己の当選確率が他のノードの当選確率より小さい場合に、自己の広報情報の提示を停止して立候補を取下げることを特徴とするサーバ決定装置。

Images