(57)【要約】【課題】  性能やプラットフォームの異なるノードが混在する分散環境において、各ノードの状態変化(負荷変動、障害の発生、新規ノードの追加)に応じて、負荷分散を最適化し性能を向上させること、障害の発生に際して分散処理を継続させること及び容易に計算機資源の追加が行なえるようにすることである。【解決手段】  ＯＭＧ標準のＣＯＲＢＡ及びＳＤＯによりプラットフォーム非依存及び位置透過性を実現する分散オブジェクト通信基盤部と、各ノードの負荷状態を収集する状態監視部と、負荷状態に応じて分散処理単位の配分を決定し分散処理を実行する資源管理部と、ノード障害を検知した際に動的に構成変更し分散処理を引き継ぐ動的フェール・オーバー制御部と、新規ノードを検知した際に自動的に分散処理に参加させる分散自動参加制御部とを有する分散処理制御方法及び分散処理制御プログラムで解決できる。【選択図】  図１
2009086741.tif 000002
【特許請求の範囲】
【請求項１】
CPU性能の異なるｎ台のノードが混在する分散処理システムにおける、前記ｎ台の各ノードへの分散処理単位を配分する分散処理制御方法であって、あるノードが、前記各ノードのCPU使用率を収集し、前記収集した前記各ノードのCPU使用率を所定期間で平均化し、前記平均化した前記各ノードの平均CPU使用率、前記各ノードのCPU性能および前記各ノードのCPU性能の総和を用いて、前記各ノードの余裕率を求め、前記各ノードの余裕率に対応して、前記分散処理単位を前記各ノードに配分する分散処理制御方法。
【請求項２】
前記あるノードの障害の検知に応じて、前記ｎ台の各ノードに含まれる他のノードが、前記あるノードを除いたn−１台の各ノードのCPU使用率を収集し、前記収集した前記n−１台の各ノードのCPU使用率を所定期間で平均化し、前記平均化した前記n−１台の各ノードの平均CPU使用率、前記n−１台の各ノードのCPU性能および前記n−１台の各ノードのCPU性能の総和を用いて、前記n−１台の各ノードの余裕率を求め、前記n−１台の各ノードの余裕率に対応して、前記分散処理単位を前記n−１台の各ノードに配分する請求項１記載の分散処理制御方法。
【請求項３】
前記あるノード以外のノードの障害の検知に応じて、前記あるノードが、前記障害が検知されたノードを除いた前記n−１台の各ノードのCPU使用率を収集し、前記収集した前記n−１台の各ノードのCPU使用率を所定期間で平均化し、前記平均化した前記n−１台の各ノードの平均CPU使用率、前記n−１台の各ノードのCPU性能および前記n−１台の各ノードのCPU性能の総和を用いて、前記n−１台の各ノードの余裕率を求め、前記n−１台の各ノードの余裕率に対応して、前記分散処理単位を前記n−１台の各ノードに配分する請求項１記載の分散処理制御方法。
【請求項４】
前記分散処理システムを構成する各ノードへの新たなノードの加入に応答して、前記あるノードが、前記加入したノードを含めてn＋１台の各ノードのCPU使用率を収集し、前記収集した前記n＋１台の各ノードのCPU使用率を所定期間で平均化し、前記平均化した前記n＋１台の各ノードの平均CPU使用率、前記n＋１台の各ノードのCPU性能および前記n＋１台の各ノードのCPU性能の総和を用いて、前記n＋１台の各ノードの余裕率を求め、前記n＋１台の各ノードの余裕率に対応して、前記分散処理単位を前記n＋１台の各ノードに配分する請求項１記載の分散処理制御方法。
【請求項５】
CPU性能の異なる各ノードに分散処理単位を配分する分散処理システムであって、前記各ノードのCPU使用率を収集し、前記収集した前記各ノードのCPU使用率を所定期間で平均化し、前記平均化した前記各ノードの平均CPU使用率、前記各ノードのCPU性能および前記各ノードのCPU性能の総和を用いて、前記各ノードの余裕率を求め、前記各ノードの余裕率に対応して、前記分散処理単位を前記各ノードに配分するあるノードと、前記CPU使用率の収集要求に応じて自CPU使用率を応答し、前記配分された前記分散処理単位を実行する他のノードを有する分散処理システム。
【請求項６】
CPU性能の異なるノードが混在する分散処理システムにおける、前記各ノードへの分散処理単位を配分するあるノードの分散処理制御プログラムであって、各ノードのCPU使用率を収集するステップ、前記収集した前記各ノードのCPU使用率を所定期間で平均化するステップ、前記平均化した前記各ノードの平均CPU使用率、前記各ノードのCPU性能および前記各ノードのCPU性能の総和を用いて、前記各ノードの余裕率を求めるステップ、および前記各ノードの余裕率に対応して、前記分散処理単位を前記各ノードに配分するステップをコンピュータに実行させる分散処理制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散処理制御に係る。特に、性能やプラットフォームが異なるノード(計算機または計算機システム)が混在する分散環境において、各ノードの状態変化(負荷変動、障害の発生、新規ノード追加)に応じ、自律的な分散処理制御を実現する分散処理制御方法及び分散処理制御プログラムに関する。
【背景技術】
【０００２】
分散環境における負荷分散には、従来から、各ノードの負荷に応じて、分散する処理単位を割り振る方式が広く知られている。特許文献１は、トランザクション単位に負荷の低いサーバに割り振る方法である。特許文献２は、プログラム単位に処理の緊急度と優先度の変換を行う方法である。特許文献３は、オブジェクト間通信量に応じてオブジェクト自体の実行場所を動的に配置変更する方法である。これらの方法は、着目するトランザクション、プログラム、又はオブジェクト毎の粒度で負荷を分散する。
【０００３】
分散環境における障害発生の際に必要な動的フェール・オーバー技術としては、待機系サーバに切り替える方式が広く知られている。特許文献４は、障害時に待機系サーバに切り替え、サーバロケーションを変更する方法である。また、特許文献５は、障害業務の通信経路を現用系から待機系に設定変更する方法である。
【０００４】
特許文献６は、分散処理の一般的形態で、トランザクションの振り分け及び実行制御を行う専用サーバと負荷分散する複数サーバで負荷を分散する方式である。この方法では、新規ノードの追加に際して、事前にシステム構成の設定変更やプログラム変更が必要である。
【０００５】
【特許文献１】特開2003-296289号
【特許文献２】特開平7-282013号
【特許文献３】特開2000-242609号
【特許文献４】特開2000-99483号
【特許文献５】特開平9-293059号
【特許文献６】特開2006-113827号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１〜３に記載される技術では、分散処理単位であるトランザクション、プログラム、又はオブジェクトの１つで多くの計算機資源を必要とする場合に、負荷分散に偏りが発生する可能性がある。特許文献４及び５に記載される技術では、障害発生に伴う動的フェール・オーバーの際に、待機系サーバが必須であり、またサーバロケーションの変更や通信経路を変更する処理が必要である。
【０００７】
そこで本発明は、性能やプラットフォームの異なるノードが混在する分散処理システムにおいて、各ノードの状態変化(負荷変動、障害の発生、新規ノードの追加)に応じて、分散処理単位を各ノードに適切に配分し、負荷分散を図り、性能を向上させることを目的とする。
【０００８】
本発明の他の目的は、障害の発生に際して分散処理を継続させること及び容易に計算機資源の追加が行なえるようにすることである。
【課題を解決するための手段】
【０００９】
本発明の態様の一つは、CPU性能の異なるｎ台のノードが混在する分散処理システムにおける、各ノードへの分散処理単位を配分する分散処理制御である。管理ノードが、各ノードのCPU使用率を収集し、収集したCPU使用率を所定期間で平均化し、各ノードの平均CPU使用率、CPU性能およびCPU性能の総和を用いて、各ノードの余裕率を求め、その余裕率に対応して、分散処理単位を各ノードに配分する分散処理制御である。
【００１０】
本発明の他の態様は、ｎ台のノードの1台に障害が発生してｎ−1台の分散処理システムになっても、新たにノードが加わりｎ＋1台の分散処理システムになっても、各ノードの余裕率に対応して分散処理単位を各ノードに配分する分散処理制御である。
【発明の効果】
【００１１】
余裕率に基づく、各ノードの負荷状態に応じた分散処理単位の配分によって、きめ細かい負荷分散が図れ、分散処理の性能が向上する。
【発明を実施するための最良の形態】
【００１２】
図面を参照し、実施例を説明する。図１は、性能やプラットフォームが異なるノードが混在する分散処理システムにおいて、各ノードの状態変化として負荷変動を考慮した場合の、各ノードの負荷に応じた分散処理単位の最適配分を説明する図である。
【００１３】
図１の管理ノード100は、分散処理システムの全体を管理するノードである。計算ノード110は、分散処理単位を実行するノードである（一般的に計算ノードは複数存在するが、本図では省略している。）。
【００１４】
なお、図１では管理ノード100と計算ノード110とは異なるノードであるように示しているが、管理ノードとしての負荷が低い場合、その余裕は計算ノードとして使用される。
【００１５】
ＳＤＯミドルウェア300は、分散オブジェクト技術の標準化団体OMG(Object Management Group)によるＳＤＯ(Super Distributed Objects：OMG標準の超分散オブジェクト仕様)及びＣＯＲＢＡ(Common Object Request Broker Architecture：OMG標準のオブジェクト仕様)を使用して、ノード状態に応じた分散処理を制御する。ＳＤＯミドルウェア300は、分散処理アプリケーションに関わらず共通である。また、分散処理アプリケーションは、ユーザプログラムＡ200及びユーザプログラムＢ210から構成される。ユーザプログラムＡ200は、分散処理依頼元に相当し、分散処理パラメータを生成し、分散処理要求を行う。一方、ユーザプログラムＢ210は、分散処理依頼先に相当し、分散処理要求により、配分された分散処理単位を実行する。
【００１６】
図１を参照しながら、負荷状態の監視、余裕率の算出、分散処理単位数の配分決定、配分された分散処理単位の実行の順に、最適負荷分散の仕組みを説明する。
【００１７】
まず、負荷状態の監視を説明する。各ノードの状態監視部310は、ＣＰＵ使用率を含む自ノードの負荷状態を、パブリッシュ・サブスクライブ型配信サービスであるＤＤＳ(Data Distributed Service)を介して、管理ノードの資源管理部320へ周期的に通知する。状態監視部310の具体的な処理を、図5を用いて説明する。図5に示す処理は周期的に、必要に応じて障害等のイベントの発生に応じて起動され、自ノードの障害状態情報を取得する（Ｓ500）。正常状態であれば、障害状態情報は正常状態であることを示す。次に、ＣＰＵ負荷情報、使用可能なメモリ容量情報を取得する（Ｓ505、Ｓ510）これら取得した情報を管理ノード100の資源管理部320へ送る（Ｓ115）。
【００１８】
資源管理部320では、各ノードの平均ＣＰＵ使用率Ｕ(t)を式（1）により算出する。
【００１９】
【数１】
2009086741.tif 000003
【００２０】
Ｕ(t)は時刻tにおける平均ＣＰＵ使用率、cは平均する周期数、pは周期の長さ(収集間隔)、kは１以上の整数、ΣＵ｛t-p(k-1)｝は一定時間に収集したＣＰＵ使用率の和を示す。ここで、平均ＣＰＵ使用率を算出する理由を説明する。分散処理単位の配分を決定する際に、各ノードから収集したＣＰＵ使用率（瞬時値）をそのまま使用すると、瞬時値の大きな偏差による影響を受け、分散処理単位の配分が偏る可能性がある。これを防止するため、平均ＣＰＵ使用率を算出する。
【００２１】
次に、各ノードが、分散処理のためにどの程度の計算機資源を提供できるかを示す指標である余裕率の算出を説明する。ここで、余裕率を計算機資源の余力（分散処理の配分に使用できるＣＰＵ使用率の割合）と定義し、（１００−平均ＣＰＵ使用率）で表すものとする。資源管理部320では、平均ＣＰＵ使用率と各計算ノードの性能の絶対評価値(ベンチマーク等の値)と併せて、各ノードの余裕率Ｆ(i)を式(２)により算出する。
【００２２】
【数２】
2009086741.tif 000004
【００２３】
Ｆ(i)はノードiにおける余裕率を示す。Ｕ(t)は時刻tにおける平均ＣＰＵ使用率、Ｐ(i)はノードｉの性能の絶対評価値(ベンチマークの値等)、ｎは本分散制御システムの全ノード数、ｊは１以上の整数、ΣＰ(j)は全ノードの絶対評価値の和を示す。
【００２４】
ここで、性能の絶対値を算出式で使用する理由を説明する。単に、（１００−平均ＣＰＵ使用率）を余裕率とすると、性能の異なるノードが混在する環境では、適切な負荷配分ができない。たとえば同じ余裕率の２つのノードが存在し、この２つのノードの性能差が２倍である場合、余裕率だけで配分すると１：１である。実際は、性能が２倍優れているノードと他方のノードの余裕率の比は、２：１であり、これに対応して最適配分比は、２：１となるからである。したがって、性能の絶対評価値に基づいた各ノードの余裕率を算出する必要があり、このための算出式が式(２)である。
【００２５】
絶対評価値を使用して余裕率の算出することで、性能の異なるノードにおいて同一基準で余裕率を算出したことになる。この余裕率の算出により、性能の異なるノードが混在する分散制御システムにおいて、各ノードの負荷に応じて分散処理単位を適切に配分できる。
【００２６】
以上の管理ノード100の資源管理部320での処理を図6に示す。各ノードからの障害状態情報、ＣＰＵ負荷情報、使用可能なメモリ容量情報などの状態監視情報を受け取る（Ｓ600）。受け取った状態監視情報を基に各ノードの平均ＣＰＵ使用率を求める（Ｓ605）。求めた平均ＣＰＵ使用率から、各ノードの余裕率を求める。
【００２７】
なお、ここではＣＰＵ負荷情報であるＣＰＵ使用率を基に余裕率を求めているが、監視状態情報の一つとして得た使用可能なメモリ容量が、分散処理単位を配分する際に配分対象となるノードになる制約条件になる場合があることは当業者には明らかであろう。
【００２８】
次に、分散処理単位数の配分決定及び配分された分散処理単位の実行を説明する。資源管理部320では、分散処理依頼元からの処理要求により、算出した余裕率の比に従って、分散処理単位数の配分を式(３)により決定し、ＣＯＲＢＡを介して各計算ノード110に分散処理単位を配分する。各計算ノード110で配分された分散処理単位の処理を実行する。
【００２９】
【数３】
2009086741.tif 000005
【００３０】
各ノードにおける分散処理単位の配分数Ｄ(i)を求める式（3）を説明する。Ｄ(i)はノードiへの分散処理単位の配分数、Ｄallは配分対象となる分散処理単位の全体数、Ｆ(i)はノードiにおける余裕率、ｎは本分散制御システムの全ノード数、ｊは１以上の整数、ΣＦ(j)は全ノードの余裕率の和を示す。
【００３１】
以上、説明したように図１の仕組みにより、各ノードの負荷状態に応じた分散処理単位の配分によって、きめ細かい負荷分散が図れ、分散処理の性能が向上する。
図２と図３は、性能やプラットフォームが異なるノードが混在する分散処理システムにおいて、各ノードの状態変化として障害の発生を考慮した場合の、動的フェール・オーバーを説明する図である。
【００３２】
図２は、管理ノード100の障害時の動的フェール・オーバーを説明する図である。図２を参照しながら、障害検知、新管理ノードの選出、参照情報の登録、分散処理の引継ぎの順に、管理ノード障害時の動的フェール・オーバーの仕組みを説明する。
【００３３】
まず、障害検知を説明する。この動的フェール・オーバーを実現するため、各計算ノード110に、動的フェール・オーバー制御部を含む資源管理部320を配置し、稼動させる。各計算ノード110は、管理ノード100が周期的に発生する稼動通知を監視し、管理ノード100の障害を検知する。
【００３４】
障害が検知された管理ノード100に代わる、新たな管理ノードの選出について説明する。自動的に新管理ノードを決定するため、障害を検知した計算ノード101(この後、新管理ノードになるが、この時点では計算ノードである。)の資源管理部320は、自ノードの優先順位を付加した代表選出メッセージを他ノードに送出する。各計算ノード(たとえば、計算ノード110)は、受け取った代表選出メッセージの優先順位と自ノードの優先順位とを比較し、自ノード110の優先順位が低い場合は計算ノードとしての機能を継続する。自ノード110の優先順位が受け取った代表選出メッセージの優先順位より高い場合、このノードは改めて自ノード110の優先順位を付加した代表選出メッセージを他ノードに送出する。代表選出メッセージを送出の所定時間後までに、新たな代表選出メッセージを受け取らなかったならば、代表選出メッセージを送出したこのノードが新管理ノードになる。このような新管理ノードの選出により、障害を検知した計算ノード101の優先順位が最も高い場合、計算ノード101が新たな管理ノードになる。このように代替ノードの位置や予めの取り決めに依存せずに、新管理ノードを選出できる。
【００３５】
以上の新たな管理ノードの選出処理を図7を用いて説明する。図7の処理は、各計算ノード101の資源管理部320の処理として実行される。管理ノード100が周期的に発生する稼動通知を監視し、管理ノード100の障害を検知する（Ｓ700）。自ノードの優先順位を他の計算ノードに向けて送出する（Ｓ705）。所定時間の間（Ｓ710）、他の計算ノードからの優先順位情報を受け取る（Ｓ715）。他の計算ノードから受信した優先順位とステップ705で送出した自ノードの優先順位とを比較し（Ｓ720）、受け取った他の計算ノードからの優先順位が自ノードの優先順位よりも高い場合は、処理を終了する。所定時間経過中に自ノードの優先順位を超える他の計算ノードからの優先順位を受け取らなかった場合、自ノードが新たな管理ノードと決定する（Ｓ725）。
【００３６】
次に、新参照情報の登録を説明する。新管理ノード101が決定した後、新管理ノード101の資源管理部(新代表)320は、ネーミングサービスに新参照情報を登録する。この新参照情報の登録により、以降、新管理ノードのオブジェクト参照ができる。
【００３７】
分散処理中の動的フェール・オーバーの際、分散処理の途中結果を引き継ぐための仕組みとしては、分散共有メモリ(図示略)を使用したテーブル参照を使用する。
【００３８】
以上、説明したように図２の動的フェール・オーバーの仕組みにより、管理ノードの障害発生の際に、分散処理を引き継ぎ、代替ノードの位置に依存せずに、分散処理を継続することができる。以降、分散処理は、新管理ノード101と複数の計算ノード110により、負荷に応じた分散処理が可能な状態として動作する。
【００３９】
管理ノード100の障害に伴う新たな管理ノード101は管理ノードとしての機能を実行する分だけ負荷が高くなる。そこで、管理ノード100を除いて分散制御システムを構成するn−1台のノードに関して、図1に示した分散制御の仕組みを適用することにより、負荷に応じた分散処理が可能な状態として動作する。この場合、新たに配分する分散処理単位は、新たな管理ノード101によって未処理の分散処理単位を対象とすることが望ましい。全ノードの未処理の分散処理単位を対象とすると、その再配分のための処理オーバーヘッドが大きくなるからである。
【００４０】
図３は、計算ノード110の障害時の動的フェール・オーバーを説明する図である。図３を参照しながら、障害検知、ＳＤＯの再立ち上げ、レジストリの登録の順に、計算ノード障害時の動的フェール・オーバーの仕組みを説明する。
【００４１】
計算ノード110の障害は、管理ノード100の資源管理部320が検出する。たとえば、計算ノード110の状態監視部310から、所定時間、状態情報の報告がない場合は、計算ノード110の障害として検知する。また、各計算ノード上の状態監視部310でＳＤＯレジストリ(ＳＤＯ、ノードアドレス等に関する情報を蓄積・管理するレジストリ)に定周期アクセスを行わせて、アクセスできない場合には、状態情報として“障害”を、管理ノード100の資源管理部320に報告する。これも、計算ノードの障害検知である。
【００４２】
次に、ＳＤＯの再立ち上げを説明する。計算ノードの障害を検知した場合、資源管理部320(動的フェール・オーバー制御部を含む)はフェール・オーバー先の計算ノード111に対して、ＳＤＯの再立ち上げ（フェール・オーバー）を指示する。
【００４３】
次に、レジストリの登録を図8を用いて説明する。ＳＤＯを再立ち上げした計算ノード111では、動的フェール・オーバー制御部の一部であるＳＤＯ管理（ＳＤＯの登録、更新、削除等を行うモジュール）がＳＤＯレジストリに登録する（Ｓ800）。自ノード上でのＳＤＯ起動時にＳＤＯ ＩＤ(一意識別子)及びＣＯＲＢＡオブジェクトリファレンスを含むＳＤＯ起動通知をイベントチャネルにより１対多の同時送信をする（Ｓ805）。
【００４４】
各ノードは、自ノードで管理しているＳＤＯ  ＩＤに該当するＳＤＯ起動通知を受信した場合に、ＳＤＯレジストリのノードアドレス情報を更新する。このレジストリの登録により、以降、新計算ノードのオブジェクト参照ができる。
【００４５】
分散処理中の動的フェール・オーバーの際、分散処理の途中結果を引き継ぐための仕組みとして、管理ノード障害の場合と同様、分散共有メモリを使用したテーブル参照を使用する。
以上、説明したように図３の動的フェール・オーバーの仕組みにより、計算ノードの障害発生の際に、分散処理を引き継ぎ、代替ノードの位置に依存せずに、分散処理を継続することができる。
【００４６】
計算ノード110の障害に伴い、計算ノード110を除いて分散制御システムを構成するn−1台のノードに関して、図1に示した分散制御の仕組みを適用することにより、負荷に応じた分散処理が可能な状態として動作する。この場合、新たに配分する分散処理単位は、計算ノード110によって未処理の分散処理単位を対象とすることが望ましい。全ノードの未処理の分散処理単位を対象とすると、その再配分のための処理オーバーヘッドが大きくなるからである。
【００４７】
図４は、各ノードの状態変化のうち、新規ノードの追加に対するもので、新規ノードの分散処理への自動参加を説明する図である。図４を参照しながら、新規ノード検知、新規ノードの参加準備、新規ノードの追加、分散参加中アイコンの順に、新規ノード追加による分散自動参加の仕組みを説明する。
【００４８】
新規ノード検知の方法を説明する。管理ノード100の資源管理部320は、各計算ノードからの周期的に送信される状態情報を監視し、管理下にない新規ノード120からの状態情報の受信により、新規ノード120を検知する。この新規ノード120の検知により、管理ノード100は、新規ノード120を自動的に検知できる。
【００４９】
次に、新規ノードの参加準備を説明する。管理ノード100の資源管理部320は、新規ノード120を検知したタイミングで新規ノード120に対して、分散参加を指示する。分散参加を指示された新規ノード120の分散自動参加制御部330の処理を、図9を用いて説明する。分散参加を指示された新規ノード120の分散自動参加制御部330は、事前設定された自ノード120に関する性能の絶対評価値を管理ノード100に通知（Ｓ900）した後、分散処理に参加する際に必要な定義ファイル及びＤＬＬ(Dynamic Link Library)を、ＦＴＰ(File Transfer Protocol)を使用して管理ノード100から新規ノード120が受け取る（Ｓ905）。この新規ノードの準備により、分散処理参加に必要な準備が自動的にできる。
【００５０】
なお、性能の絶対評価値に関しては、事前設定された値を使う。または、管理ノード100から分散参加を指示された新規ノード120でベンチマークを実行し、性能の絶対評価値を取得する。
【００５１】
新規ノード120の分散自動参加制御部330は、ＦＴＰ転送の完了後に、準備完了(新規ノードの絶対評価値を含む。)を、管理ノード100の資源管理部320に通知する（Ｓ910）。
【００５２】
次に、新規ノードの追加を説明する。管理ノード100の資源管理部320は、準備完了の受信タイミングで、分散環境管理テーブルに、新規ノード情報を追加する。この追加により、新規ノード120は分散環境に参加したことになる。なぜならば、管理ノード100の資源管理部320は、分散処理単位の配分を決定する際に、分散環境管理テーブルを参照するからである。
【００５３】
次に、分散参加中アイコンを説明する。管理ノード100の資源管理部320は、新規ノード120が分散環境に参加完了したこと(分散環境管理テーブルに追加完了したこと)を新規ノード120へ参加完了として通知する。新規ノード120の分散自動参加制御部は、参加完了の通知を受けたタイミングで、分散参加中を示すアイコンを表示する。
【００５４】
また、このアイコンは、分散環境へ参加中であることを示すと共に、アイコン操作により、該ノードを分散環境から離脱させることができる。該ノードを分散環境から離脱させるために、アイコン操作がされた場合には、管理ノード100の分散環境管理テーブルから、該ノードの情報を削除する。この削除により、分散環境から離脱したことになる。なぜならば、管理ノード100の資源管理部320は、分散処理単位の配分を決定する際に、分散環境管理テーブルを参照するからである。離脱後は、アイコンを消去する。
【００５５】
以上、説明したように図４の新規ノードの分散処理への自動参加の仕組みにより、新規ノードの検知、分散処理に参加するための設定、分散処理開始に至る一連の、分散処理への自動参加ができる。
【００５６】
新規ノード120の追加に伴い、新規ノード120を加えた分散制御システムを構成するn＋1台のノードに関して、図1に示した分散制御の仕組みを適用することにより、負荷に応じた分散処理が可能な状態として動作する。この場合、新規ノード120に分散処理単位を配分するタイミングを考慮すべきである。次に分散処理単位が生成するタイミングに合わせて配分することが望ましい。全ノードの未処理の分散処理単位を対象とすると、その再配分のための処理オーバーヘッドが大きくなるからである。
【００５７】
以上のように、性能やプラットフォームが異なるノードが混在する分散環境において、各ノードの状態変化(負荷変動、障害の発生、新規ノードの追加)に応じて、分散処理単位を最適配分し性能向上させることができる。障害の発生に際して専用の待機サーバなしに分散処理を継続することができ、新規ノードをＬＡＮ接続するだけで分散処理に自動参加させることができる。
【００５８】
たとえば、各ノードの負荷状況に応じ、同時並列処理が可能な計算パラメータの最小単位に区分した処理単位（分散処理単位）を、各ノードに最適配分することにより、極細かい負荷分散を図り、分散処理の性能を向上させることができる。
【００５９】
ここで、負荷に応じた極細かい分散処理単位の配分で、なぜ性能が向上するかを説明する。もし、トランザクション単位のように分散の粒度が粗いと、一番負荷の低いノードに対して、該トランザクションを実行させることになり、該トランザクションが多くの計算機資源を必要とするケースでは、今まで一番負荷が低かったノードが逆に過負荷になる可能性がある。一方、粒度の細かい分散処理単位を、各ノードの負荷に応じて配分すると、負荷の偏りなく平準化が図れ、結果として分散処理の性能が向上する。
【００６０】
また、ノード障害の際に専用の待機系サーバを必要とせず、動的フェール・オーバーにより、自動的に分散処理の途中結果を引き継ぎ、分散処理を継続することができる。また、ユーザプログラムにおいて、サーバロケーションの設定変更や通信経路の設定変更処理は必要ない。さらに、新規ノードをＬＡＮ接続するだけで特別な設定なしに、分散処理中であっても、計算機資源を追加し、分散処理を継続することができる。
【図面の簡単な説明】
【００６１】
【図１】性能やプラットフォームが異なるノードが混在する分散環境における分散処理の負荷に応じた最適配分を説明する図である。
【図２】管理ノード障害時の動的フェール・オーバーを説明する図である。
【図３】計算ノード障害時の動的フェール・オーバーを説明する図である。
【図４】新規ノードの分散処理への自動参加を説明する図である。
【図５】状態監視部の処理フローチャートである。
【図６】資源管理部の処理フローチャートである。
【図７】新たな管理ノード選出の処理フローチャートである。
【図８】フェール・オーバー先の計算ノードにおけるレジストリ登録の処理フローチャートである。
【図９】新規ノードの分散自動参加制御部の処理フローチャートである。
【符号の説明】
【００６２】
100…管理ノード、110…計算ノード、300…SDOミドルウエア、310…状態監視部、320…資源管理部、330…分散自動参加制御部、
【図１】
2009086741.tif 000006
【図２】
2009086741.tif 000007
【図３】
2009086741.tif 000008
【図４】
2009086741.tif 000009
【図５】
2009086741.tif 000010
【図６】
2009086741.tif 000011
【図７】
2009086741.tif 000012
【図８】
2009086741.tif 000013
【図９】
2009086741.tif 000014