JP2004213122A - クライアント／サーバによる制御システムの安定稼働方法及びそのプログラム - Google Patents

Abstract

【課題】市販のクライアント／サーバシステムにおいて、前記サーバの機能を低下又は停止させることなく、長時間にわたって安定的にシステムを稼働させることができ制御システムの安定稼働方法を提供する。
【解決手段】パーソナルコンピュータとサーバとを有するクライアント／サーバシステムにおいて、サーバを複数準備し、前記サーバの稼働状態を監視し、前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行うようにした。前記サーバの稼働状態の監視を、メモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うようにしてもよい。
【選択図】 図３

Description

【０００１】
【発明の属する技術分野】
本発明は、クライアント／サーバシステムを用いて、プラント等の制御を行う制御システムの改良に関し、特に、市販のパーソナルコンピュータとサーバとからなる安価なクライアント／サーバシステムを用いて、前記制御システムを長時間にわたって安定的に動作させることができるクライアント／サーバによる制御システムの安定稼働方法に関する。
【０００２】
【従来の技術】
各種プラントや設備、装置等の制御を行う制御システムとして、クライアント／サーバが利用されている。図９は、クライアント／サーバの構成を説明するブロック図で、クライアントである端末装置１００と、この端末装置１００から入力された要求にしたがって所定の処理を行うサーバ３００と、このサーバ３００の処理結果を格納するデータベース６００と、端末装置１００，サーバ３００及びデータベース６００を接続するＬＡＮ等の信号線２００とから概略構成されている。サーバ３００の処理結果は、信号線２００を介して端末装置１００に送信され、端末装置１００のディスプレイ等に表示され、あるいは、データベース６００に格納される。
【０００３】
ところで、米マイクロソフト社製のWindows（登録商標）のように、市販されている汎用のＯＳ（オペレーション・システム）の下で動作するサーバ３００においては、いわゆるメモリリークによる問題がある。
図１０は、クライアント／サーバにおけるメモリリークと時間との関係を示したグラフである。図１０に示すように、上記のＯＳ環境下においては、時間とともにメモリ資源が侵食されて、徐々に動作が不安定になるという問題が知られている（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特表２０００−５１５２７９号公報（発明の詳細な説明の「２．背景」の記載参照）
【０００５】
そして、動作不安定のままで運転を続けると、動作停止の状態に陥ったり、大きなメモリ領域を必要とするアプリケーションの実行が不可能になったりする。このような状態は、ＯＳを再起動しなければ復帰することができず、実行中のアプリケーションの内容やデータが消去されるという問題がある。そのため、長時間連続して制御を行う必要のあるシステムにおいては、ＯＳとしてメモリリークによる動作不安定が生じにくいもの、例えば、ＵＮＩＸ（登録商標）等をＯＳとして用いることが多い。
【０００６】
しかしながら、このような制御システムは、価格が高いという問題がある。また、使用できるソフトウェアが限定されるという問題がある。さらに、近年のパソコンの低価格・高機能化にともない、制御システムに市販の安価なクライアント／サーバを利用したいという要望もある。
また、長時間の連続稼働による動作不安定や停止といった上記の問題を解決するための一つの手段として、クラスタシステムの利用が考えられる（例えば特許文献２参照）。
【０００７】
【特許文献２】
特開２００２−２２２１２５号公報（明細書の［０００９］〜［００１８］参照）
【０００８】
前記したクラスタシステムは、複数のサーバ(ノード)で処理を行うシステムで、その中でもフェイルオーバー型クラスタは、障害が発生した場合でも業務の運用を継続させることができるものである。フェイルオーバー型のクラスタは、メインで動作するメインサーバと、メインサーバが正常に動作している間は待機状態にある待機サーバとを有していて、メインサーバに異常が発生したときに、ただちに待機サーバを起動させて処理を引き継がせるものである。
【０００９】
しかし、このようなシステムでは、メインサーバの他に待機サーバを常に確保しておかねばならないという問題がある。そのため、クラスタで処理できる負荷がメインサーバによって決定され、処理上の無駄が生じるという問題がある。
全てのサーバをメインサーバとし、異常が発生したときに他のメインサーバが当該メインサーバの負荷を分担するようにすることで、上記の問題は解決できるが、高負荷時に異常が発生すると、メインサーバの許容負荷を超えてしまい、サーバの機能が低下するという問題が生じる。
【００１０】
【発明が解決しようとする課題】
この発明は上記の問題点にかんがみてなされたもので、市販のパーソナルコンピュータとサーバとからなる安価なクライアント／サーバシステムにおいて、前記サーバの機能を低下又は停止させることなく、長時間にわたって安定的にシステムを稼働させることができ、かつ、簡単な改良を施すだけで実施が可能なクライアント／サーバによる制御システムの安定稼働方法を提供するものである。
【００１１】
【課題を解決するための手段】
本発明の発明者は、鋭意研究を重ねた結果、サーバの稼働状態の監視を行い、稼働状態が不安定になる前に再起動を行うことで、継続的にシステムを安定化させることができることを見出した。
【００１２】
具体的には、本発明は、請求項１に記載するように、パーソナルコンピュータを端末装置とするクライアント／サーバシステムにおいて、サーバを複数準備し、前記サーバの稼働状態を監視し、前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行う方法としてある。
【００１３】
この場合、請求項２に記載するように、前記した予め設定された条件として、前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うようにするとよい。また、請求項３に記載するように、前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定されたしきい値を超える回数をカウントし、このカウント数が予め設定された回数を超えたときに、前記サーバの再起動を行うようにしてもよい。
前記しきい値を、メモリリークによってサーバが稼働しなくなる限界値に対して余裕をもって設定することで、メモリリークが前記しきい値を複数回連続して超えても、前記カウント数が所定回数になるまでは安定稼働を続けることができる。
【００１４】
また、請求項４に記載するように、前記再起動を行う再起動時間を設定するとともに、前記監視を定期的に行い、稼働条件が予め設定された条件になったと判断されたときに、前記再起動時間に到達するまで待機して再起動を行うようにしてもよい。前記再起動時間としては、サーバに作用する負荷が最小になる時間帯を設定するとよい。このようにすることで、一のサーバについて再起動を行う際に、他のサーバに過大な負荷がかからないようにすることができる。
【００１５】
請求項５に記載するように、複数の前記サーバについて稼働状態を相互に監視し、一のサーバが前記条件になったときに、他のサーバが稼働しているかどうかを判断して、前記他のサーバが稼働していることを条件に、前記再起動を行うようにするとよい。
このようにすることで、一のサーバと他のサーバの同時再起動を防止することができる。
【００１６】
請求項６に記載の発明は、一のサーバの再起動を行う際に、他のサーバの負荷を検出し、前記一のサーバを停止させたときの前記他のサーバの負荷が許容量を超えないことを条件に、前記一のサーバの再起動を行う方法である。
このようにすることで、一のサーバについて再起動を行う際に、他のサーバに許容値を超える過大な負荷がかからないようにすることができる。
【００１７】
請求項７に記載の発明は、前記サーバの個々について、稼働状態の監視時間及び／又は再起動を行う時間をずらした方法としてある。また、請求項８に記載の発明は、一の前記サーバについて再起動が完了するまで他の前記サーバの再起動を禁止する方法としてある。
これらの方法によっても、一のサーバと他のサーバの同時再起動を防止することができる。
【００１８】
本発明の方法は、請求項９に記載するように、請求項１〜請求項８に記載の各ステップを実行するプログラムによって行うことができる。このプログラムは、ＦＤ（フレキシブルディスク）等の磁気ディスクや、ＣＤ（コンパクトディスク）等の光ディスクからＣＰＵに読み込むことによって実行することができる他、インターネットや電話回線等の通信回線を介してＣＰＵに読み込むことによっても実行することが可能である。
【００１９】
【発明の実施の形態】
以下、本発明の好適な実施形態を、図面にしたがって詳細に説明する。
[第一の実施形態]
図１は、本発明の第一の実施形態を示す図で、クライアント／サーバによる制御システムの全体構成を説明するブロック図、図２は、クラスタの構成を示すブロック図である。
【００２０】
この実施形態において、制御システムは、端末装置（クライアント）であるパーソナルコンピュータ（以下、ＰＣと記載する）１と、このＰＣ１の要求にしたがって処理を実行するクラスタ３と、処理の結果を格納するデータベース６とを有し、各々がＬＡＮ等の信号線２で接続されている。
この実施形態では、説明の便宜のため、クラスタ３の内部に、二つのサーバＳ１及びサーバＳ２が構築されているものとし、ＰＣ１から要求された処理を、この二つのサーバＳ１，Ｓ２で分担するものとする。
【００２１】
なお、クラスタ３内に複数のサーバを設ける手段としては、ハードウェアとしてのサーバを複数設ける方法のほか、市販のクラスタソフトウェアやその他のソフトウェア（例えば、米マイクロソフト社製のＯＳ、Windows（登録商標）２０００アドバンスドサーバ）を用いる方法がある。
【００２２】
サーバＳ１，Ｓ２の負担分散は、ロードバランサ３１によって行われる。そして、サーバＳ１に負担された処理要求は、処理部４１で、サーバＳ２に負担された処理要求は処理部５１で処理される。通常、この処理は、サーバＳ１，Ｓ２のＣＰＵで行われる。処理部４１，５１は、メモリ４２，５２との間でデータの授受を行いながら処理を実行するが、時間の経過とともにメモリ４２，５２の記憶領域が侵食されて、動作が徐々に不安定になる。
そこで、この実施形態では、メモリ４２，５２のメモリリークを監視することで、サーバＳ１，Ｓ２の動作状態を判断する監視部４３，５３を設けて、メモリリークが一定以上になったときに、この監視部４３，５３がシステム起動部４４，５４に指令を出力して、サーバＳ１，Ｓ２の再起動を行うようにしている。
【００２３】
図３は、上記構成のクライアント／サーバにおける、再起動の手順を説明するフローチャートである。
クライアント／サーバの起動（ステップＳ１）とともに、監視部４３，５３によるメモリ４２，５２のメモリリークの監視が開始される（ステップＳ２）。
一方のサーバＳ１の監視部４３は、他方のサーバＳ２の稼働状態（稼働しているかどうか）を監視し、他方のサーバＳ２の監視部５３は、一方のサーバＳ１の稼働状態を監視する（ステップＳ３）。
【００２４】
監視部４３，５３によるメモリリークの監視及び稼働状態の相互監視は、例えば１秒おきのように、定期的に行うのが好ましい。また、両方のサーバＳ１，Ｓ２が同時に再起動を行うことがないように、再起動に必要な分（例えば５分以上）だけ時間をずらして、メモリリークの監視を行うようにするとよい。
監視部４３，５３は、メモリリークが予め設定されたしきい値を超えたかどうかを判断し（ステップＳ４）、メモリリークがしきい値が超えたときに、その回数をカウントアップする（ステップＳ５）。
この場合、カウントの途中でメモリリークがしきい値を下回ったときにカウンタをリセットするようにして、しきい値を超えるメモリリークが連続して検出されていることを条件に、カウントアップを行うように設定することも可能である。
【００２５】
図４は、本発明のクライアント／サーバにおける再起動のタイミングを、メモリリークと時間との関係で示したグラフである。
前記したしきい値は、図４に示すように、メモリリークが動作不良を引き起こす限界値の下方に、余裕をもって設定する。すなわち、メモリリークがしきい値を超える回数を、監視部４３，５３が予め設定した回数以上検出しても、前記限界値に達しないように、しきい値を前記限界値よりも十分下方に設定する。
監視部４３，５３は、メモリリークがしきい値が超えた回数が予め設定された回数（例えば６０回）を超えたかどうかを判断する（ステップＳ６）。
【００２６】
そして、監視部４３は、例えば一方のサーバＳ１が前記回数を超えたときに、他方のサーバＳ２が稼働していること（ステップＳ８）を条件に、再起動要求メッセージを表示すし（ステップＳ１０）、再起動を行うようにシステム起動部４４に指令を出力する（ステップＳ１１）。再起動完了後は、カウンタのリセットを行って（ステップＳ１２）、ステップＳ２以下の処理を繰り返す。
なお、ステップＳ８で他方のサーバＳ２が稼働を停止している場合は、他方のサーバＳ２が稼働を開始するまで、再起動を行うことなく待機する（ステップＳ９）。
【００２７】
［第二の実施形態］
第一の実施形態で説明した手順により、一方のサーバＳ１（又は他方のサーバＳ２）の再起動を開始すると、再起動中における他方のサーバＳ２（又は一方のサーバＳ１）の負荷は増大する。この負荷の増大は、可能な限り小さいものであることが好ましい。
図５は、サーバＳ１及びサーバＳ２の負荷状態の時間変化を示すグラフである。一般に、サーバの負荷は、時間によって変化する。そのため、負荷状態が大きいときに、例えば一方のサーバＳ１の再起動を行うと、他方のサーバＳ２に過大な負荷が作用し、サーバＳ２の機能が低下するおそれがある。
そこで、この第二の実施形態では、サーバＳ１，Ｓ２の再起動を、サーバＳ１，Ｓ２の負荷が小さい時間帯に行うようにしている。すなわち、図５のグラフに示す例においては、負荷状態が最も小さくなるポイント▲１▼，▲２▼，▲３▼のいずれかの時間帯で、再起動を行うようにする。
【００２８】
負荷の小さい時間帯に限定してサーバＳ１又はサーバＳ２の再起動を行うようにした場合の処理の手順を、図６のフローチャートを参照しながら説明する。なお、図３に示す第一の実施形態のフローチャートと同一ステップには同一の符号を付して、詳しい説明は省略するものとする。また、以下の説明においては、適宜に図２のブロック図を参照するものとする。
一方のサーバＳ１の監視部４３（図２参照）は、メモリリークがしきい値を越える回数をカウント（ステップＳ５）、この回数が所定回数を超えたときに（ステップＳ６）、システム再起動要求メッセージを表示するとともに（ステップＳ１７）、システム起動部４４に対して、システム再起動予約を行う（ステップＳ１８）。この再起動の予約は、サーバＳ１，Ｓ２に対する負荷が小さくなる図５中のポイント▲１▼，▲２▼，▲３▼のいずれかを指定して行われる。
【００２９】
そして、システム起動部４４は、現在時刻が、図５中のポイント▲１▼，▲２▼，▲３▼のいずれかに到達しているかどうかを判断し（ステップＳ２０）、到達している場合には、他方のサーバＳ２が稼働していることを条件に（ステップＳ２１）、システムの再起動を実行する（ステップＳ２２）。再起動実行後は、カウンタをリセットして（ステップＳ２３）、ステップＳ２以下の処理を繰り返す。
なお、ステップＳ２０で、到達していないと判断した場合、又はステップＳ２１で他方のサーバＳ２が稼働していないと判断した場合は、ポイント▲１▼，▲２▼，▲３▼のいずれかに到達するまで、又は、他方のサーバＳ２が稼働を開始するまで、待機する（ステップＳ１９）。
【００３０】
［第三の実施形態］
上記した第一及び第二の実施形態では、クラスタ３内に二つのサーバＳ１，Ｓ２を設けた場合について説明した。以下の第三の実施形態では、図７に示すように、クラスタ３内に三つ以上のサーバＳ１，Ｓ２，Ｓ３・・・を設け、ロードバランサ３１で負荷分配を行う場合について説明する。
図８は、この第三の実施形態におけるサーバの再起動の手順を説明するフローチャートである。なお、クラスタ３の基本構成は、図２に示した第一の実施形態のクラスタの構成と変わりがないので、以下の説明においては、適宜に図２のブロック図を参照するものとする。
なお、図３に示す第一の実施形態のフローチャートと同一ステップには同一の符号を付して、詳しい説明は省略する。
【００３１】
一のサーバ（例えばサーバＳ１）のメモリリークが、しきい値を所定回数を超えてカウントされた場合（ステップＳ６）、当該一のサーバの監視部が、ロードバランサ３１を介して、他のサーバＳ２，Ｓ３・・・に作用される負荷を求める。そして、サーバＳ１の再起動を行う際に、他のサーバＳ２，Ｓ３・・・の負荷が許容値を超えないことを条件に（ステップＳ８′）、システム再起動要求メッセージを表示し（ステップＳ１０）、システムの再起動を行う（ステップＳ１１）。
サーバＳ１の再起動を行う際に、他のサーバＳ２，Ｓ３・・・の負荷が許容値を超えるときには、所定時間待機する（ステップＳ９）。
【００３２】
この実施形態においては、他のサーバの負荷が許容値を超えない範囲内で、複数台のサーバＳ１，Ｓ２，Ｓ３・・・について、同時に再起動を行うことが可能である。
また、複数のサーバＳ１，Ｓ２，Ｓ３・・・について、同時に、メモリリークのしきい値を越える回数が所定回数を超えた判断されたときは、負荷の許容値を超えない範囲内で、一部のサーバについて同時に再起動を行い、残りのサーバについては、前記一部のサーバの再起動終了後に、再起動を行うように設定することも可能である。
さらに、この実施形態では、第一の実施形態と同様に、複数のサーバＳ１，Ｓ２，Ｓ３・・・について監視等を行う時間をずらしたり、第二の実施形態と同様に、再起動の時間を所定の時間帯に限定することも可能である。
【００３３】
本発明の好適な実施形態について説明してきたが、本発明は上記の実施形態によりなんら限定されるものではなく、本発明の適用範囲内で種々に変更することが可能である。
例えば、上記の実施形態では、メモリリークを状態監視の一手段として説明したが、システムの稼働状態を監視し、稼働状態が不安定又は停止する前に、再起動を行うように判断することができるのであれば、上記のメモリリークに限らず、他の状態監視の手段を用いることができる。例えば、メモリ上で実行されているプログラムの数を監視し、この数が予め設定された数を超えたときに再起動を行うようにすることも可能であるし、ハードディスク等でメモリの拡張を行っているような場合においては、仮想空間の空きページ数を監視し、このページ数が予め設定された数を超えたときに再起動を行うようにすることも可能である。
【００３４】
【発明の効果】
本発明によれば、市販のパーソナルコンピュータとサーバとからなる安価なクライアント／サーバシステムを、長時間にわたって安定的に稼働させることができ、制御システムを低価格で構築することが可能なる。また、複数のサーバを設けて、サーバの稼働状態の監視を行い、稼働状態が不安定になる前に一のサーバの再起動を行うようにするだけで、簡単に実施が可能である。
【図面の簡単な説明】
【図１】本発明の第一の実施形態を示す図で、クライアント／サーバによる制御システムの全体構成を説明するブロック図である。
【図２】図１のクラスタの構成を示すブロック図である。
【図３】第一の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図４】本発明のクライアント／サーバにおける再起動のタイミングを示すグラフである。
【図５】サーバの負荷状態の時間変化を示すグラフである。
【図６】本発明の第二の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図７】本発明の第三の実施形態にかかり、クラスタ内に三つ以上のサーバを設けた場合を示すブロック図である。
【図８】第三の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図９】本発明の従来例にかかり、クライアント／サーバの構成を説明するブロック図である。
【図１０】クライアント／サーバにおけるメモリリークと時間との関係を示したグラフである。
【符号の説明】
１ パーソナルコンピュータ
２ ＬＡＮ
３ クラスタ
３１ ロードバランサ
４１，５１ 処理部（ＣＰＵ）
４２，５２ メモリ
４３，５３ 監視部
４４，５４ システム起動部
６ データベース
Ｓ１，Ｓ２・・・ サーバ

Claims (9)

1. パーソナルコンピュータとサーバとを有するクライアント／サーバシステムにおいて、
   サーバを複数準備し、
   前記サーバの稼働状態を監視し、
   前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行うこと、
   を特徴とするクライアント／サーバによる制御システムの安定稼働方法。
2. 前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うことを特徴とする請求項１に記載のクライアント／サーバによる制御システムの安定稼働方法。
3. 前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定されたしきい値を超える回数をカウントし、このカウント数が予め設定された回数を超えたときに、前記サーバの再起動を行うことを特徴とする請求項１に記載のクライアント／サーバによる制御システムの安定稼働方法。
4. 前記再起動を行う再起動時間を設定するとともに、前記監視を定期的に行い、稼働条件が予め設定された条件になったと判断されたときに、前記再起動時間に到達するまで待機して再起動を行うことを特徴とする請求項１〜３のいずれかに記載のクライアント／サーバによる制御システムの安定稼働方法。
5. 複数の前記サーバについて稼働状態を相互に監視し、一のサーバが前記条件になったときに、他のサーバが稼働しているかどうかを判断して、前記他のサーバが稼働していることを条件に、前記再起動を行うことを特徴とする請求項１〜４のいずれかに記載のクライアント／サーバによる制御システムの安定稼働方法。
6. 一のサーバの再起動を行う際に、他のサーバの負荷を検出し、前記一のサーバを停止させたときの前記他のサーバの負荷が許容量を超えないことを条件に、前記一のサーバの再起動を行うことを特徴とする請求項１〜５のいずれかに記載のクライアント／サーバによる制御システムの安定稼働方法。
7. 前記サーバの個々について、稼働状態の監視時間及び／又は再起動を行う時間をずらしたことを特徴とする請求項１〜６のいずれかに記載のクライアント／サーバによる制御システムの安定稼働方法。
8. 一の前記サーバについて再起動が完了するまで他の前記サーバの再起動を禁止することを特徴とする請求項１〜７のいずれかに記載のクライアント／サーバによる制御システムの安定稼働方法。
9. 請求項１〜８のいずれかに記載の方法を実行するプログラム。

Images