JP2006031096A - 分散処理システムおよびその再起動制御方法および再起動制御プログラム - Google Patents

Abstract

【課題】
サービス自体を停止させることなく、再起動を行う処理サーバを選択できるようにした分散処理システムおよびその再起動制御方法および再起動制御プログラムを提供する。
【解決手段】
クライアントからの処理要求に基づいて処理を行う処理サーバが現在処理している処理要求を実行中情報管理部２０４により管理し、実行中の処理要求と選択項目指定部２０１により指定された選択項目または、複数の選択項目ごとに重み付けを行った評価式に基づいて、複数の処理サーバのうち再起動を行う処理サーバを決定部２０２で決定する。
【選択図】図２

Description

本発明は、複数の処理サーバを有する分散処理システムおよびその再起動制御方法および再起動制御プログラムに関し、特に、複数の処理サーバの再起動を最適に行うことができるようにした分散処理システムおよびその再起動制御方法および再起動制御プログラムに関する。

一般に、同一の機能を複数の処理サーバによって提供してシステムの安定性を向上させる負荷分散システムや複数の機能により構成される処理に対して各機能を複数の処理サーバで同時に処理することでシステムを高速化、または信頼性を向上させるコンポーネント分散システムなどの複数の処理サーバにより処理が行われているシステムでは、サービスが停止する時間を減じるため、異常発生時においてサービスや装置自体を再起動させるような構成で作成されている。

この場合、アプリケーションなどによるメモリが解放されないメモリリーク状態を異常発生として検出することが困難であり、異常発生の検知によるシステム全体の安定のための再起動を効率的に実現することが難しい。

そこで、長時間の安定稼動を要求するサービスにおいてはあらかじめ指定されたスケジュールに基づいてシステムの安定を向上させる従来技術として特許文献１、特許文献２に示す技術が開示されている。

この特許文献１に開示された従来技術においては、複数のコンピュータ間相互に相手の異常停止を検出するための通信を行い、当該コンピュータ全てが正常動作を行っている間にコンピュータごとの運転スケジュール情報にしたがって、無人で起動および停止を行うことができ、コンピュータが異常停止すると他の正常なコンピュータが異常停止したコンピュータの業務を引き継ぐことが可能である。

また、この特許文献２に開示された従来技術においては、一定時間経過後、定期的にオペレーティングシステムに再起動の要求を行うコンピュータプログラムを備えて、コンピュータプログラムが動作するＰＣが１台の場合、そのＰＣを定期的に再起動することができメモリリークなどを回避することが可能である。
特開平３−００９４６２ 特開２００３−１８６５６３

しかしながら、特許文献１に示された従来技術においては、正常動作を行っているコンピュータの再起動をスケジュール情報に基づいて行うことにより、処理中のリクエストが強制的に終了させられてしまい、他の正常なコンピュータに再起動したコンピュータの業務を引き継ぐようにしているため引き継いだコンピュータは一時的であっても過負荷状態に陥り、処理能力の低下を招くという問題がある。

加えて、再起動するコンピュータの選択が最適なものとは限らず、メモリリークなどの問題を起こしているコンピュータではなく正常なコンピュータが再起動されてしまうことがある。その結果、不安定なコンピュータのみで業務が行われる状態に陥り、システムとしての信頼性が低下する可能性が生じてしまう。

また、特許文献２に示された従来技術では、再起動を行うコンピュータの再起動を行うための情報を他のコンピュータに記録のみを行ってオペレーティングシステムの再起動を行うので、当該コンピュータが提供するプログラムが停止し、その間、処理を実行することが出来なくなるという問題がある。

そこで、本発明は、サービスの負荷の最も少ない時間にあらかじめ設定した項目または、評価式に基づいて複数の処理装置のうち再起動を行う処理装置を選択するようにすることで、サービス自体を停止させることなく、再起動を行う処理装置を選択できるようにした分散処理システムおよびその再起動制御方法および再起動制御プログラムを提供することを目的とする。

上記目的を達成するため、請求項１の発明は、複数の処理サーバと前記複数の処理サーバの処理を管理する管理サーバとを有し、前記管理サーバは、クライアント装置から要求された処理を前記複数の処理サーバのいずれかに振り分けることにより該処理を実行する分散処理システムにおいて、前記管理サーバは、前記複数の処理サーバで実行中の処理をそれぞれ管理する第１の管理手段と、前記複数の処理サーバの状態をそれぞれ管理する第２の管理手段と、前記複数の処理サーバの再起動の条件情報を管理する第３の管理手段と、前記第１の管理手段および前記第２の管理手段の管理情報を参照して前記第３の管理手段の管理情報に基づき前記複数の処理サーバの中の再起動を行う処理サーバを選択する選択手段と、前記選択手段で選択された処理サーバに対して再起動を指示する再起動指示手段とを具備することを特徴とする。

また、請求項２の発明は、請求項１の発明において、前記選択手段は、一定の時間毎若しくは前記クライアント装置から処理の要求がある毎若しくは前記クライアント装置から要求された処理が終了する毎に、前記第１の管理手段で管理する実行中の処理の数を調べ、該実行中の処理の数が予め設定された数より小さいことを条件に前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項３の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの再起動の順番情報を管理し、前記選択手段は、前記順番情報に基づき前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項４の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの起動開始時刻を管理し、前記選択手段は、前記起動開始時刻に基づき起動されている時間が長い処理サーバを優先して前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項５の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの実行した処理の数を計数管理し、前記選択手段は、前記実行した処理の数が多い処理サーバを優先して前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項６の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの実行した処理の延べ処理時間を計数管理し、前記選択手段は、前記実行した処理の延べ処理時間が長い処理サーバを優先して前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項７の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの平均処理時間を算出管理し、前記選択手段は、前記平均処理時間の増加率が大きい処理サーバを優先して前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項８の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの同一の処理に対する処理時間を算出管理し、前記選択手段は、前記処理時間の大きい処理サーバを優先して前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項９の発明は、請求項１または２の発明において、前記第３の管理手段は、前記複数の処理サーバの再起動の順番情報、前記複数の処理サーバの起動開始時刻、前記複数の処理サーバの実行した処理の数、前記複数の処理サーバの実行した処理の延べ処理時間、前記複数の処理サーバの平均処理時間、前記複数の処理サーバの同一の処理に対する処理時間の内の少なくとも２つの情報を管理し、前記選択手段は、前記少なくとも２つの情報の基づき前記再起動を行う処理サーバを選択することを特徴とする。

また、請求項１０の発明は、複数の処理サーバと前記複数の処理サーバの処理を管理する管理サーバとを有し、前記管理サーバは、クライアント装置から要求された処理を前記複数の処理サーバのいずれかに振り分けることにより該処理を実行する分散処理システムの再起動制御方法であって、前記複数の処理サーバで実行中の処理をそれぞれ第１の管理手段で管理し、前記複数の処理サーバの状態をそれぞれ第２の管理手段で管理し、前記複数の処理サーバの再起動の条件情報を第３の管理手段で管理し、前記第１の管理手段および前記第２の管理手段の管理情報を参照して前記第３の管理手段の管理情報に基づき前記複数の処理サーバの中の再起動を行う処理サーバを選択手段で選択し、前記選択手段で選択された処理サーバに対して前記管理サーバから再起動を指示することを特徴とする。

また、請求項１１の発明は、複数の処理サーバと前記複数の処理サーバの処理を管理する管理サーバとを有し、前記管理サーバは、クライアント装置から要求された処理を前記複数の処理サーバのいずれかに振り分けることにより該処理を実行する分散処理システムの再起動制御をコンピュータにより実行させる再起動制御プログラムであって、前記複数の処理サーバで実行中の処理をそれぞれ管理する第１のステップと、前記複数の処理サーバの状態をそれぞれ管理する第２のステップと、前記複数の処理サーバの再起動の条件情報を管理する第３のステップと、前記第１のステップおよび前記第２のステップの管理情報を参照して前記第３のステップの管理情報に基づき前記複数の処理サーバの中の再起動を行う処理サーバを選択する第４のステップと、前記第４のステップで選択された処理サーバに対して再起動を指示する第５のステップとを含むことを特徴とする。

本発明によれば、同一の機能を提供する複数の処理装置のうち再起動を行う処理装置をあらかじめ設定された項目ないしは該設定された項目を組み合わせた評価式により再起動を行う処理装置を選択するように構成したので、機能を提供する処理装置が過負荷状態または不安定になるのを未然に防ぐことができ、機能の停止によるサービス提供不可能状態を回避することが可能になるという効果を奏する。

以下、本発明に係わる分散処理システムおよび方法およびプログラムの一実施例を添付図面を参照して詳細に説明する。

図１は、この発明に係わる分散処理システムおよび方法およびプログラムを適用して構成した分散処理のネットワーク構成図である。

図１において、処理要求を送出するクライアント（１０１−１，１０１−２，・・・，１０１−Ｎ）、処理要求に対して分散処理の管理を行う管理サーバ１０２、管理サーバ１０２により管理された分散処理を行う処理サーバ（１０３−１，１０３−２，・・・，１０３−Ｎ）を具備して構成される。

クライアント（１０１−１，１０１−２，・・・，１０１−Ｎ）は、ネットワーク回線を介して管理サーバ１０２に処理要求を送出する。

管理サーバ１０２は、クライアントからの処理要求を受け付けて予め設定された情報に基づいて処理サーバ（１０３−１，１０３−２，・・・，１０３−Ｎ）に処理を分散する。

このとき、管理サーバにより分散される処理内容は、１つの処理要求における複数の処理内容を処理内容ごとに各処理サーバで処理するような構成や１つの処理要求における複数の処理内容のうち同一の処理内容を複数の処理サーバで処理するような構成にしてもよい。これにより、ＮＬＢ（Network Load Balancing：ネットワーク負荷分散）やＣＬＢ（Component Load Balancing：コンポーネント負荷分散）によって負荷分散が行え、処理の高速化や信頼性の向上を図ることができるようになり、また同一処理内容を複数の処理サーバで実行することによるシステムの二重化などを行うことができる。

例えば、クライアント１０１−１から管理サーバ１０２に対して処理要求Ａを送出し、クライアント１０１−２から管理サーバ１０２に対して処理要求Ｂを送出した場合にＮＬＢを実現するには、管理サーバ１０２に予め設定された処理を行う処理サーバを選択する情報である処理サーバ選択情報にしたがって処理要求Ａを処理サーバ１０３−１に、処理要求Ｂを処理サーバ１０３−２に振り分けを行う。これによって、１つの処理サーバで集中的に処理を行わずに分散処理を行うことができ、負荷分散を実現できる。

また、クライアント１０１−１から管理サーバ１０２に対して処理要求Ｃを送出した場合にＣＬＢを実現するには、管理サーバ１０２は処理サーバ選択情報に基づいて処理要求Ｃを処理サーバ１０３−１と処理サーバ１０３−３にコンポーネント単位で処理を分散し、同期をとることで処理要求Ｃを処理できる。

処理サーバ（１０３−１，１０３−２，・・・，１０３−Ｎ）は、管理サーバ１０２により分散された個々の処理をそれぞれ行う。処理サーバはすくなくとも二台以上からなり、一方を再起動している場合にはもう一方の処理サーバで処理を行う。

このとき、処理サーバの台数を三台四台と増やすことにより再起動を行っている間の他の処理処理サーバに処理が集中することなく、効率よく負荷を分散することができるようになる。

なお、主系のサーバに障害が発生した場合に待機系として待機状態になっている待機サーバを再起動時にのみ使用することで、処理サーバを安易に増やすのではなく、既存のシステム構成を用いて処理サーバの再起動を行うことような構成にすることも可能である。

図２は、この発明に係わる管理サーバのシステム構成を示す図である。

図２には、選択項目指定部２０１、決定部２０２、管理部２０３、実行中情報管理部２０４、選択項目管理部２０５、処理状態管理部２０６、通知部２０７を具備して構成される。

選択項目指定部２０１は、再起動を行う処理サーバを選択する条件である選択項目を指定し、その選択項目は選択項目管理部２０５で管理された項目のうち１つを図６に示す画面を用いて指定する。

決定部２０２は、選択項目指定部２０１により指定された項目に該当する処理サーバを「再起動を行う処理サーバ」として決定する。また、決定部２０２は処理サーバの決定を行うにあたり、管理部２０３内の実行中情報管理部２０４、選択項目管理部２０５、処理状態管理部２０６とのやりとりを行い、項目の削除または更新を行う。

さらには、処理サーバの再起動を行うタイミングを考慮して再起動を行うこともできる。

なお、再起動を行う処理サーバの決定は、選択項目管理部２０５により管理された選択項目ごとに重み付けを行った評価式（図７参照）によっても行うことができる。

管理部２０３は、実行中情報管理部２０４、選択項目管理部２０５、処理状態管理部２０６を具備し、決定部２０２からの管理状態の確認や更新をこれら３つの管理部に行う。

実行中情報管理部２０４は、各処理サーバにおける現在実行中の処理要求を管理する。これによりクライアントからの処理要求内容がどの処理サーバにより処理されているか容易に確認することができる。

選択項目管理部２０５は、再起動を行う処理サーバを選択する項目として以下の項目を管理している。

（１）処理サーバ名称
（２）連続起動時間
（３）処理したリクエスト数
（４）単位リクエスト当りの処理時間
（５）同一リクエストに対する処理時間の差
（６）テスト用リクエストの処理時間
処理状態管理部２０６は、各処理サーバのサーバ状態を管理している。つまり、各処理サーバが再起動を行うための待ち状態である[再起動待ち状態]であるのか、再起動を行っている最中である[再起動実行中]であるのか、クライアントからの処理要求を処理できる状態である[リクエスト受付可能状態]にあるのかを管理する。

例えば、[再起動待ち状態]である場合には、その処理サーバは再起動を行う処理サーバとして決定されており、処理サーバで実行されている処理要求が終了するのを待っている状態を示している。

それに対して[再起動実行中]である場合には、まさに今、再起動を行っている状態を示している。

そして、[リクエスト受付可能状態]である場合には、再起動を行う処理サーバとして決定されてなく、通常の処理を行うことができる状態を示している。

通知部２０７は、決定部２０２により再起動を行う処理サーバと決定された処理サーバに対して再起動の通知を行う。

このような構成によれば、指定された選択項目または評価式に基づいて、再起動を行う処理サーバを選択することができる。また、処理サーバにより実行されている処理要求を容易に確認することができる。

次に管理サーバの管理部２０５に保存された情報について説明する。

図３は、管理サーバで管理する実行中の処理要求の情報を示す図である。

図３は、図２に示す実行中情報管理部２０４で管理されるテーブルであって[処理ＩＤ]を主キーとし、処理要求を送出した[クライアントＩＤ]、処理要求に応じて処理を行っている処理サーバの[処理サーバＩＤ]、処理要求を受け付けて処理を開始してから経過した[経過時間]（単位：秒）の各項目を具備した処理状態テーブル３０１を示している。

処理要求を送出してきたクライアントの[クライアントＩＤ]に対してその処理要求が実行中の[処理サーバＩＤ]を示している。このときの[クライアントＩＤ]と[処理サーバＩＤ]を外部キーとして、別途設けられたテーブルにリンクするような構成にしてもよいし、単に処理要求を行ってきたクライアントを識別するクライアント名称やＩＰ（Internet Protocol）アドレスを表示するような構成にしても良い。

これにより管理サーバがクライアントから受けた処理要求をどの処理サーバにより処理されているか容易に判別することが出来るだけでなく、反対に、処理サーバが行っている処理要求を判別することができる。つまり、処理サーバの稼動状態を見極めることが出来る。

なお、複数の処理サーバに同一の処理要求を行った場合に、[処理開始経過時間]から処理効率などを算出することができるようになる。

図４は、管理サーバで再起動を行う処理サーバを選択するための選択方法定義テーブル４０１を示す図である。

図４は、図２に示す選択項目管理部２０５で管理されるテーブルであって、図６に示す再起動を行う処理サーバの選択方法を指定する処理サーバ選択手段指定画面により指定される項目を定義している。

図４は、図６の画面により選択される項目の名称である[項目名称]とその[項目名称]ごとに設定が定義されている位置を示す[保存位置]を定義している。なお、図４ではＯＳ（Operating System：基本システム）ファイルシステム上のディレクトリに設定の定義を保存するような例を示しているが、設定の定義の保存先としてメモリ中のアドレスやデータベースにおけるテーブル名といった値を保存することによっても、同様の効果を実現できる。

図５は、管理サーバにより管理された各処理サーバの状態を示す図である。

図５において、図５（ａ）は、図２に示す処理状態管理部２０６で管理されるテーブルであって、各処理サーバに割り当てられた[処理サーバＩＤ]、[処理サーバの名称]、処理サーバの状態を示す[サーバ状態ＩＤ]を具備した処理サーバ状態テーブル５０１であり、図５（ｂ）は、図５（ａ）の[サーバ状態ＩＤ]を主キーとしてサーバの状態を定義したサーバ状態定義テーブル５０２である。

図５（ａ）の処理サーバ状態テーブル５０１に示した[サーバ状態ＩＤ]を外部キーとして図５（ｂ）のサーバ状態定義テーブル５０２を参照している。

上記に示すテーブルを用いてクライアントからの処理要求を受け付けて処理が行われ、再起動を行う処理サーバの決定までの流れを以下に示す。

クライアントから処理要求を管理サーバで受け付け、管理サーバは分散処理を行う処理サーバをサーバ状態定義テーブル５０２で定義したサーバの稼動状態に基づき決定し、処理要求に対する処理サーバの情報を処理状態テーブル３０１に更新する。このとき処理要求に対する処理が終了した場合には処理状態テーブル３０１から処理状態を消去する。

管理サーバは一定の時間毎またはリクエストの受付や終了時などに設定された再起動の要求を受け付けると、処理サーバ状態テーブル５０１で管理された再起動する処理サーバを選択するための情報から再起動の要求時に指定した選択情報に基づいて再起動を行う処理サーバを選択する。選択された処理サーバの処理状態を確認するために処理状態テーブル３０１を参照し、予め定められた処理数以下である場合に再起動を行う処理サーバとする。このようにすることにより処理の負荷が高くない場合に処理サーバの再起動を行うことができるようになり、サービスのレスポンス劣化を回避できる。

再起動を行う処理サーバとして選択されると、処理サーバ状態テーブル５０１の[サーバ状態ＩＤ]をリクエスト受付可能状態「２」から再起動待ち状態「０」に更新する。当該処理サーバがクライアントからの処理要求を１つも実行していない状態になるのを確認して再起動を実行する。このとき処理サーバ状態テーブル５０１の[サーバ状態ＩＤ]の項目を再起動待ち状態「０」から再起動実行中「１」に更新する。

処理サーバの再起動を完了すると、処理サーバ状態テーブル５０１の[サーバ状態ＩＤ]を再起動実行中「１」からリクエスト受付可能状態「２」に更新する。

図６は、本発明に係わる分散処理システムおよび方法およびプログラムの処理サーバの選択方法を指定する処理サーバ選択手段指定画面６００を示す図である。

図６には、選択方法として図２に示す選択項目管理部２０５に管理された６つの項目が示されている。これら６つのうちいずれか一つを選択することにより再起動を行う処理サーバを選択することができるようになり、再起動処理が実行される。ただし、請求項９に示したように複数の情報を元にして再起動する処理サーバを選択する方式では、図６で選択できる項目は複数個となる。また、予め選択方法を決めておくことで、図６のような選択画面を表示させないようにシステムを構成することも可能である。

図７は、管理サーバにより再起動を行う処理サーバを複数の情報を元に選択する際に用いられる評価式を示す図である。

図７において、評価式は図２の選択項目管理部２０５により管理された選択項目それぞれに対して重み付けを行い、この重み付けの総スコア数が最も高い処理サーバを再起動を行う処理サーバとして選択する。このとき、優先する項目についてはより高い重み付けを行い、優先順位の低い項目については低い重み付けを行う。

図７に示す例では、図２の管理部２０５における選択項目のうち「（２）連続起動時間」「（３）処理したリクエスト数」「（６）テスト用リクエストの処理時間」の３つの項目について重み付けを行い、このうち「（２）連続起動時間」を最も高い優先順位に設定して重み付けを行う。そして、各処理サーバにつけられた重み付けの総スコア数のうち最も高いスコア数を持つ処理サーバを再起動を行う処理サーバとして選択する。

今、管理サーバによって６台の処理サーバが管理されている場合において重み付けを行うとする。この場合、「（２）連続起動時間」の選択項目については、起動時間の短い処理サーバから順に２点、４点、６点・・・のように２点間隔で重み付けを行うとすると、最も起動時間の短い処理サーバについて「２点」の重み付けを行い、最も起動時間の長い処理サーバについて「１２点」の重み付けを行うことができる。

また、「（３）処理したリクエスト数」の選択項目については、処理したリクエスト数の少ない処理サーバから順に１点、２点、３点・・・のように１点間隔で重み付けを行うとすると、最も処理リクエスト数が少ない処理サーバには「１点」、最も多くの処理リクエストを処理した処理サーバについては「６点」の重み付けを行うことができる。

さらに、「（６）テスト用リクエストの処理時間」の選択項目については、テスト用リクエストの処理時間が最も短い処理サーバから順に１点、２点、３点・・・のように１点間隔で重み付けを行うとすると、最も処理時間の短い処理サーバには「１点」、最も処理時間の長い処理サーバには「６点」の重み付けを行うことができる。

これらの重み付けを加算した総スコア数が最も高い処理サーバを再起動を行う処理サーバとして選択できる。図７に示す例では、処理サーバ[６]が総スコア数「２０点」で最も高いスコアとなっているので、処理サーバ６が再起動を行う処理サーバとして選択される。

なお、評価式による再起動を行う処理サーバの選択では総スコア数による選択だけでなく、少なくとも２つの選択項目における合計スコア数が予め設けられた閾値を超過したものについては、総スコア数によらず再起動を行う処理サーバとして選択するような構成にしてもよい。

例えば、「（２）連続起動時間」と「（６）テスト用リクエストの処理時間」との合計スコア数に設けられた閾値が「２５点」である場合に、この閾値を超過した処理サーバについては総スコア数では、最も高いスコアでないにもかかわらず再起動を行う処理サーバとして選択される。

図８は、処理サーバの再起動処理動作を示すフローチャートである。

図８において、クライアントから処理サーバの再起動要求を受け付けると処理が開始され、図４に示す選択方法定義テーブル４０１を参照し（Ｓ８０１）、図６の処理サーバ選択手段指定画面により指定された再起動を行う処理サーバの選択方法を取得する（Ｓ８０２）。次に、取得した選択方法に基づいて再起動を行う処理サーバを決定し（Ｓ８０３）、その決定した処理サーバに対して図５（ａ）に示す処理サーバ状態テーブル５０１の[サーバ状態ＩＤ]の項目を再起動待ち状態を示す「０」に更新する（Ｓ８０４）。

決定した処理サーバが再起動できる状態であるか否かの判定処理を行う（Ｓ８０５）。ここでは、その処理サーバが実行している処理要求数が一定値以下であるのかの判定が行われる（図９に示すフローチャート参照）。

フラグが「１」であるか、つまり判定結果がある一定値以下である場合かを判断し、フラグが「１」でない場合（Ｓ８０６でＮＯ）には一定値以上の処理要求が処理中であるため再起動処理を行うことができないということで処理を終了する。

それに対して、フラグが「１」である場合（Ｓ８０６でＹＥＳ）には、次に図３に示す処理依頼テーブル３０１にその処理サーバが実行中の処理要求が存在する（実行中処理要求：１以上、一定値以下）か判断し（Ｓ８０７）、実行中の処理要求が存在する場合（Ｓ８０７でＹＥＳ）には、予め設定した一定時間待機し（Ｓ８０８）、再度、実行中の処理要求が存在するか判定する。

それに対して、実行中の処理要求が存在しない場合（Ｓ８０７でＮＯ）には、処理サーバの再起動を実行する（Ｓ８０９）。再起動の実行と同時に図５（ａ）に示す処理サーバ状態テーブル５０１の[サーバ状態ＩＤ]を再起動待ち状態を示す「０」から再起動の実行中状態を示す「１」に更新する（Ｓ８１０）。

再起動が完了したかどうかを判定し（Ｓ８１１）、再起動が終了している場合（Ｓ８１１でＹＥＳ）には、図５（ａ）に示す処理サーバテーブル５０１の[サーバ状態ＩＤ]を再起動実行中状態を示す「１」からリクエスト受付可能状態を示す「２」に更新する（Ｓ８１２）。

それに対して、再起動が完了していない場合（Ｓ８１１でＮＯ）には一定時間待機し（Ｓ８１３）、再度、再起動完了したか判定を行う。

図９は、処理サーバの再起動を行うか否かの判定を行うフローチャートである。図９は、図８に示す判定処理（Ｓ８０５）の内容における詳細なフローチャートを示している。

図９において、再起動のリクエストを受け付けると、図３（ａ）に示す処理依頼テーブル３０１を参照し（Ｓ９０１）、選択された処理サーバによって実行されている処理要求の数（Ａ）を算出し（Ｓ９０２）、そして、あらかじめ設定された処理要求における閾値（Ｎ）を取得する（Ｓ９０３）。

実行中の処理要求の数（Ａ）が閾値（Ｎ）以上であるか判断し（Ｓ９０４）、閾値（Ｎ）以上である場合（Ｓ９０４でＹＥＳ）には、フラグに「１」をセットする。閾値（Ｎ）未満である場合（Ｓ９０４でＮＯ）には、フラグに「０」をセットする。

これによって、実行中の処理要求数に応じて再起動を行うことができるか否かを決定することができる。

以上の処理によって、指定された選択項目に基づく最適な処理サーバの再起動が行うことができる。

これによって、機能を提供する処理装置が過負荷状態または不安定になるのを未然に防ぐことが可能になる。

したがって、本発明を適用することにより、機能の停止によるサービス提供不可能状態を回避することが可能になるという効果を期待できる。

なお、上記フローチャートに示す処理は、コンピュータにより実行可能な再起動制御プログラムによっても実現できる。

本発明は、上記し、且つ図面に示す実施例に限定することなく、その要旨を変更しない範囲内で適宜変形して実施できるものである。

本発明は、処理要求を分散して処理する分散処理システムの処理サーバにおける再起動制御方法およびプログラムに適用可能であり、特に、指定された選択項目または選択項目の組み合わせにより作成される評価式に基づいて処理サーバを選択して再起動を制御するのに有用である。

この発明に係わる分散処理システムおよび方法およびプログラムを適用して構成した分散処理のネットワーク構成図。 この発明に係わる管理サーバのシステム構成を示す図。 管理サーバで管理する実行中の処理要求の情報を示す図。 管理サーバで再起動を行う処理サーバを選択するための選択方法定義テーブルを示す図。 管理サーバにより管理された各処理サーバの状態を示す図。 本発明に係わる分散処理システムおよび方法およびプログラムの処理サーバの選択方法を指定する処理サーバ選択手段指定画面を示す図。 管理サーバにより再起動を行う処理サーバの選択に用いられる評価式を示す図。 処理サーバの再起動処理動作を示すフローチャート。 処理サーバの再起動するか否かの判定を行うフローチャート。

符号の説明

１０１−Ａ、１０１−Ｂ クライアント
１０２ 管理サーバ
１０３−１、１０３−２、１０３−３、・・・、１０３−Ｎ 処理サーバ
２０１ 要求受付部
２０２ 処理サーバ決定部
２０３ 要求解析部
２０４ 項目選択部
２０５ 管理部
２０６ 選択項目管理部
２０７ 実行中処理情報管理部
２０８ 処理サーバ処理状態管理部
２０９ 再起動処理サーバ決定部
２１０ 再起動時刻算出部
２１１ 再起動通知部

Claims (11)

1. 複数の処理サーバと前記複数の処理サーバの処理を管理する管理サーバとを有し、前記管理サーバは、クライアント装置から要求された処理を前記複数の処理サーバのいずれかに振り分けることにより該処理を実行する分散処理システムにおいて、
   前記管理サーバは、
   前記複数の処理サーバで実行中の処理をそれぞれ管理する第１の管理手段と、
   前記複数の処理サーバの状態をそれぞれ管理する第２の管理手段と、
   前記複数の処理サーバの再起動の条件情報を管理する第３の管理手段と、
   前記第１の管理手段および前記第２の管理手段の管理情報を参照して前記第３の管理手段の管理情報に基づき前記複数の処理サーバの中の再起動を行う処理サーバを選択する選択手段と、
   前記選択手段で選択された処理サーバに対して再起動を指示する再起動指示手段と
   を具備することを特徴とする分散処理システム。
2. 前記選択手段は、
   一定の時間毎若しくは前記クライアント装置から処理の要求がある毎若しくは前記クライアント装置から要求された処理が終了する毎に、前記第１の管理手段で管理する実行中の処理の数を調べ、該実行中の処理の数が予め設定された数より小さいことを条件に前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１記載の分散処理システム。
3. 前記第３の管理手段は、
   前記複数の処理サーバの再起動の順番情報を管理し、
   前記選択手段は、
   前記順番情報に基づき前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
4. 前記第３の管理手段は、
   前記複数の処理サーバの起動開始時刻を管理し、
   前記選択手段は、
   前記起動開始時刻に基づき起動されている時間が長い処理サーバを優先して前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
5. 前記第３の管理手段は、
   前記複数の処理サーバの実行した処理の数を計数管理し、
   前記選択手段は、
   前記実行した処理の数が多い処理サーバを優先して前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
6. 前記第３の管理手段は、
   前記複数の処理サーバの実行した処理の延べ処理時間を計数管理し、
   前記選択手段は、
   前記実行した処理の延べ処理時間が長い処理サーバを優先して前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
7. 前記第３の管理手段は、
   前記複数の処理サーバの平均処理時間を算出管理し、
   前記選択手段は、
   前記平均処理時間の増加率が大きい処理サーバを優先して前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
8. 前記第３の管理手段は、
   前記複数の処理サーバの同一の処理に対する処理時間を算出管理し、
   前記選択手段は、
   前記処理時間の大きい処理サーバを優先して前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
9. 前記第３の管理手段は、
   前記複数の処理サーバの再起動の順番情報、前記複数の処理サーバの起動開始時刻、前記複数の処理サーバの実行した処理の数、前記複数の処理サーバの実行した処理の延べ処理時間、前記複数の処理サーバの平均処理時間、前記複数の処理サーバの同一の処理に対する処理時間の内の少なくとも２つの情報を管理し、
   前記選択手段は、
   前記少なくとも２つの情報の基づき前記再起動を行う処理サーバを選択する
   ことを特徴とする請求項１または２記載の分散処理システム。
10. 複数の処理サーバと前記複数の処理サーバの処理を管理する管理サーバとを有し、前記管理サーバは、クライアント装置から要求された処理を前記複数の処理サーバのいずれかに振り分けることにより該処理を実行する分散処理システムの再起動制御方法であって、
    前記複数の処理サーバで実行中の処理をそれぞれ第１の管理手段で管理し、
    前記複数の処理サーバの状態をそれぞれ第２の管理手段で管理し、
    前記複数の処理サーバの再起動の条件情報を第３の管理手段で管理し、
    前記第１の管理手段および前記第２の管理手段の管理情報を参照して前記第３の管理手段の管理情報に基づき前記複数の処理サーバの中の再起動を行う処理サーバを選択手段で選択し、
    前記選択手段で選択された処理サーバに対して前記管理サーバから再起動を指示する
    ことを特徴とする再起動方法。
11. 複数の処理サーバと前記複数の処理サーバの処理を管理する管理サーバとを有し、前記管理サーバは、クライアント装置から要求された処理を前記複数の処理サーバのいずれかに振り分けることにより該処理を実行する分散処理システムの再起動制御をコンピュータにより実行させる再起動制御プログラムであって、
    前記複数の処理サーバで実行中の処理をそれぞれ管理する第１のステップと、
    前記複数の処理サーバの状態をそれぞれ管理する第２のステップと、
    前記複数の処理サーバの再起動の条件情報を管理する第３のステップと、
    前記第１のステップおよび前記第２のステップの管理情報を参照して前記第３のステップの管理情報に基づき前記複数の処理サーバの中の再起動を行う処理サーバを選択する第４のステップと、
    前記第４のステップで選択された処理サーバに対して再起動を指示する第５のステップと
    を含むことを特徴とする再起動制御プログラム。

Images