JP2004213122A - クライアント/サーバによる制御システムの安定稼働方法及びそのプログラム - Google Patents
クライアント/サーバによる制御システムの安定稼働方法及びそのプログラム Download PDFInfo
- Publication number
- JP2004213122A JP2004213122A JP2002378918A JP2002378918A JP2004213122A JP 2004213122 A JP2004213122 A JP 2004213122A JP 2002378918 A JP2002378918 A JP 2002378918A JP 2002378918 A JP2002378918 A JP 2002378918A JP 2004213122 A JP2004213122 A JP 2004213122A
- Authority
- JP
- Japan
- Prior art keywords
- server
- restart
- client
- servers
- operating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
Abstract
【課題】市販のクライアント/サーバシステムにおいて、前記サーバの機能を低下又は停止させることなく、長時間にわたって安定的にシステムを稼働させることができ制御システムの安定稼働方法を提供する。
【解決手段】パーソナルコンピュータとサーバとを有するクライアント/サーバシステムにおいて、サーバを複数準備し、前記サーバの稼働状態を監視し、前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行うようにした。前記サーバの稼働状態の監視を、メモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うようにしてもよい。
【選択図】 図3
【解決手段】パーソナルコンピュータとサーバとを有するクライアント/サーバシステムにおいて、サーバを複数準備し、前記サーバの稼働状態を監視し、前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行うようにした。前記サーバの稼働状態の監視を、メモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うようにしてもよい。
【選択図】 図3
Description
【0001】
【発明の属する技術分野】
本発明は、クライアント/サーバシステムを用いて、プラント等の制御を行う制御システムの改良に関し、特に、市販のパーソナルコンピュータとサーバとからなる安価なクライアント/サーバシステムを用いて、前記制御システムを長時間にわたって安定的に動作させることができるクライアント/サーバによる制御システムの安定稼働方法に関する。
【0002】
【従来の技術】
各種プラントや設備、装置等の制御を行う制御システムとして、クライアント/サーバが利用されている。図9は、クライアント/サーバの構成を説明するブロック図で、クライアントである端末装置100と、この端末装置100から入力された要求にしたがって所定の処理を行うサーバ300と、このサーバ300の処理結果を格納するデータベース600と、端末装置100,サーバ300及びデータベース600を接続するLAN等の信号線200とから概略構成されている。サーバ300の処理結果は、信号線200を介して端末装置100に送信され、端末装置100のディスプレイ等に表示され、あるいは、データベース600に格納される。
【0003】
ところで、米マイクロソフト社製のWindows(登録商標)のように、市販されている汎用のOS(オペレーション・システム)の下で動作するサーバ300においては、いわゆるメモリリークによる問題がある。
図10は、クライアント/サーバにおけるメモリリークと時間との関係を示したグラフである。図10に示すように、上記のOS環境下においては、時間とともにメモリ資源が侵食されて、徐々に動作が不安定になるという問題が知られている(例えば、特許文献1参照)。
【0004】
【特許文献1】
特表2000−515279号公報(発明の詳細な説明の「2.背景」の記載参照)
【0005】
そして、動作不安定のままで運転を続けると、動作停止の状態に陥ったり、大きなメモリ領域を必要とするアプリケーションの実行が不可能になったりする。このような状態は、OSを再起動しなければ復帰することができず、実行中のアプリケーションの内容やデータが消去されるという問題がある。そのため、長時間連続して制御を行う必要のあるシステムにおいては、OSとしてメモリリークによる動作不安定が生じにくいもの、例えば、UNIX(登録商標)等をOSとして用いることが多い。
【0006】
しかしながら、このような制御システムは、価格が高いという問題がある。また、使用できるソフトウェアが限定されるという問題がある。さらに、近年のパソコンの低価格・高機能化にともない、制御システムに市販の安価なクライアント/サーバを利用したいという要望もある。
また、長時間の連続稼働による動作不安定や停止といった上記の問題を解決するための一つの手段として、クラスタシステムの利用が考えられる(例えば特許文献2参照)。
【0007】
【特許文献2】
特開2002−222125号公報(明細書の[0009]〜[0018]参照)
【0008】
前記したクラスタシステムは、複数のサーバ(ノード)で処理を行うシステムで、その中でもフェイルオーバー型クラスタは、障害が発生した場合でも業務の運用を継続させることができるものである。フェイルオーバー型のクラスタは、メインで動作するメインサーバと、メインサーバが正常に動作している間は待機状態にある待機サーバとを有していて、メインサーバに異常が発生したときに、ただちに待機サーバを起動させて処理を引き継がせるものである。
【0009】
しかし、このようなシステムでは、メインサーバの他に待機サーバを常に確保しておかねばならないという問題がある。そのため、クラスタで処理できる負荷がメインサーバによって決定され、処理上の無駄が生じるという問題がある。
全てのサーバをメインサーバとし、異常が発生したときに他のメインサーバが当該メインサーバの負荷を分担するようにすることで、上記の問題は解決できるが、高負荷時に異常が発生すると、メインサーバの許容負荷を超えてしまい、サーバの機能が低下するという問題が生じる。
【0010】
【発明が解決しようとする課題】
この発明は上記の問題点にかんがみてなされたもので、市販のパーソナルコンピュータとサーバとからなる安価なクライアント/サーバシステムにおいて、前記サーバの機能を低下又は停止させることなく、長時間にわたって安定的にシステムを稼働させることができ、かつ、簡単な改良を施すだけで実施が可能なクライアント/サーバによる制御システムの安定稼働方法を提供するものである。
【0011】
【課題を解決するための手段】
本発明の発明者は、鋭意研究を重ねた結果、サーバの稼働状態の監視を行い、稼働状態が不安定になる前に再起動を行うことで、継続的にシステムを安定化させることができることを見出した。
【0012】
具体的には、本発明は、請求項1に記載するように、パーソナルコンピュータを端末装置とするクライアント/サーバシステムにおいて、サーバを複数準備し、前記サーバの稼働状態を監視し、前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行う方法としてある。
【0013】
この場合、請求項2に記載するように、前記した予め設定された条件として、前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うようにするとよい。また、請求項3に記載するように、前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定されたしきい値を超える回数をカウントし、このカウント数が予め設定された回数を超えたときに、前記サーバの再起動を行うようにしてもよい。
前記しきい値を、メモリリークによってサーバが稼働しなくなる限界値に対して余裕をもって設定することで、メモリリークが前記しきい値を複数回連続して超えても、前記カウント数が所定回数になるまでは安定稼働を続けることができる。
【0014】
また、請求項4に記載するように、前記再起動を行う再起動時間を設定するとともに、前記監視を定期的に行い、稼働条件が予め設定された条件になったと判断されたときに、前記再起動時間に到達するまで待機して再起動を行うようにしてもよい。前記再起動時間としては、サーバに作用する負荷が最小になる時間帯を設定するとよい。このようにすることで、一のサーバについて再起動を行う際に、他のサーバに過大な負荷がかからないようにすることができる。
【0015】
請求項5に記載するように、複数の前記サーバについて稼働状態を相互に監視し、一のサーバが前記条件になったときに、他のサーバが稼働しているかどうかを判断して、前記他のサーバが稼働していることを条件に、前記再起動を行うようにするとよい。
このようにすることで、一のサーバと他のサーバの同時再起動を防止することができる。
【0016】
請求項6に記載の発明は、一のサーバの再起動を行う際に、他のサーバの負荷を検出し、前記一のサーバを停止させたときの前記他のサーバの負荷が許容量を超えないことを条件に、前記一のサーバの再起動を行う方法である。
このようにすることで、一のサーバについて再起動を行う際に、他のサーバに許容値を超える過大な負荷がかからないようにすることができる。
【0017】
請求項7に記載の発明は、前記サーバの個々について、稼働状態の監視時間及び/又は再起動を行う時間をずらした方法としてある。また、請求項8に記載の発明は、一の前記サーバについて再起動が完了するまで他の前記サーバの再起動を禁止する方法としてある。
これらの方法によっても、一のサーバと他のサーバの同時再起動を防止することができる。
【0018】
本発明の方法は、請求項9に記載するように、請求項1〜請求項8に記載の各ステップを実行するプログラムによって行うことができる。このプログラムは、FD(フレキシブルディスク)等の磁気ディスクや、CD(コンパクトディスク)等の光ディスクからCPUに読み込むことによって実行することができる他、インターネットや電話回線等の通信回線を介してCPUに読み込むことによっても実行することが可能である。
【0019】
【発明の実施の形態】
以下、本発明の好適な実施形態を、図面にしたがって詳細に説明する。
[第一の実施形態]
図1は、本発明の第一の実施形態を示す図で、クライアント/サーバによる制御システムの全体構成を説明するブロック図、図2は、クラスタの構成を示すブロック図である。
【0020】
この実施形態において、制御システムは、端末装置(クライアント)であるパーソナルコンピュータ(以下、PCと記載する)1と、このPC1の要求にしたがって処理を実行するクラスタ3と、処理の結果を格納するデータベース6とを有し、各々がLAN等の信号線2で接続されている。
この実施形態では、説明の便宜のため、クラスタ3の内部に、二つのサーバS1及びサーバS2が構築されているものとし、PC1から要求された処理を、この二つのサーバS1,S2で分担するものとする。
【0021】
なお、クラスタ3内に複数のサーバを設ける手段としては、ハードウェアとしてのサーバを複数設ける方法のほか、市販のクラスタソフトウェアやその他のソフトウェア(例えば、米マイクロソフト社製のOS、Windows(登録商標)2000アドバンスドサーバ)を用いる方法がある。
【0022】
サーバS1,S2の負担分散は、ロードバランサ31によって行われる。そして、サーバS1に負担された処理要求は、処理部41で、サーバS2に負担された処理要求は処理部51で処理される。通常、この処理は、サーバS1,S2のCPUで行われる。処理部41,51は、メモリ42,52との間でデータの授受を行いながら処理を実行するが、時間の経過とともにメモリ42,52の記憶領域が侵食されて、動作が徐々に不安定になる。
そこで、この実施形態では、メモリ42,52のメモリリークを監視することで、サーバS1,S2の動作状態を判断する監視部43,53を設けて、メモリリークが一定以上になったときに、この監視部43,53がシステム起動部44,54に指令を出力して、サーバS1,S2の再起動を行うようにしている。
【0023】
図3は、上記構成のクライアント/サーバにおける、再起動の手順を説明するフローチャートである。
クライアント/サーバの起動(ステップS1)とともに、監視部43,53によるメモリ42,52のメモリリークの監視が開始される(ステップS2)。
一方のサーバS1の監視部43は、他方のサーバS2の稼働状態(稼働しているかどうか)を監視し、他方のサーバS2の監視部53は、一方のサーバS1の稼働状態を監視する(ステップS3)。
【0024】
監視部43,53によるメモリリークの監視及び稼働状態の相互監視は、例えば1秒おきのように、定期的に行うのが好ましい。また、両方のサーバS1,S2が同時に再起動を行うことがないように、再起動に必要な分(例えば5分以上)だけ時間をずらして、メモリリークの監視を行うようにするとよい。
監視部43,53は、メモリリークが予め設定されたしきい値を超えたかどうかを判断し(ステップS4)、メモリリークがしきい値が超えたときに、その回数をカウントアップする(ステップS5)。
この場合、カウントの途中でメモリリークがしきい値を下回ったときにカウンタをリセットするようにして、しきい値を超えるメモリリークが連続して検出されていることを条件に、カウントアップを行うように設定することも可能である。
【0025】
図4は、本発明のクライアント/サーバにおける再起動のタイミングを、メモリリークと時間との関係で示したグラフである。
前記したしきい値は、図4に示すように、メモリリークが動作不良を引き起こす限界値の下方に、余裕をもって設定する。すなわち、メモリリークがしきい値を超える回数を、監視部43,53が予め設定した回数以上検出しても、前記限界値に達しないように、しきい値を前記限界値よりも十分下方に設定する。
監視部43,53は、メモリリークがしきい値が超えた回数が予め設定された回数(例えば60回)を超えたかどうかを判断する(ステップS6)。
【0026】
そして、監視部43は、例えば一方のサーバS1が前記回数を超えたときに、他方のサーバS2が稼働していること(ステップS8)を条件に、再起動要求メッセージを表示すし(ステップS10)、再起動を行うようにシステム起動部44に指令を出力する(ステップS11)。再起動完了後は、カウンタのリセットを行って(ステップS12)、ステップS2以下の処理を繰り返す。
なお、ステップS8で他方のサーバS2が稼働を停止している場合は、他方のサーバS2が稼働を開始するまで、再起動を行うことなく待機する(ステップS9)。
【0027】
[第二の実施形態]
第一の実施形態で説明した手順により、一方のサーバS1(又は他方のサーバS2)の再起動を開始すると、再起動中における他方のサーバS2(又は一方のサーバS1)の負荷は増大する。この負荷の増大は、可能な限り小さいものであることが好ましい。
図5は、サーバS1及びサーバS2の負荷状態の時間変化を示すグラフである。一般に、サーバの負荷は、時間によって変化する。そのため、負荷状態が大きいときに、例えば一方のサーバS1の再起動を行うと、他方のサーバS2に過大な負荷が作用し、サーバS2の機能が低下するおそれがある。
そこで、この第二の実施形態では、サーバS1,S2の再起動を、サーバS1,S2の負荷が小さい時間帯に行うようにしている。すなわち、図5のグラフに示す例においては、負荷状態が最も小さくなるポイント▲1▼,▲2▼,▲3▼のいずれかの時間帯で、再起動を行うようにする。
【0028】
負荷の小さい時間帯に限定してサーバS1又はサーバS2の再起動を行うようにした場合の処理の手順を、図6のフローチャートを参照しながら説明する。なお、図3に示す第一の実施形態のフローチャートと同一ステップには同一の符号を付して、詳しい説明は省略するものとする。また、以下の説明においては、適宜に図2のブロック図を参照するものとする。
一方のサーバS1の監視部43(図2参照)は、メモリリークがしきい値を越える回数をカウント(ステップS5)、この回数が所定回数を超えたときに(ステップS6)、システム再起動要求メッセージを表示するとともに(ステップS17)、システム起動部44に対して、システム再起動予約を行う(ステップS18)。この再起動の予約は、サーバS1,S2に対する負荷が小さくなる図5中のポイント▲1▼,▲2▼,▲3▼のいずれかを指定して行われる。
【0029】
そして、システム起動部44は、現在時刻が、図5中のポイント▲1▼,▲2▼,▲3▼のいずれかに到達しているかどうかを判断し(ステップS20)、到達している場合には、他方のサーバS2が稼働していることを条件に(ステップS21)、システムの再起動を実行する(ステップS22)。再起動実行後は、カウンタをリセットして(ステップS23)、ステップS2以下の処理を繰り返す。
なお、ステップS20で、到達していないと判断した場合、又はステップS21で他方のサーバS2が稼働していないと判断した場合は、ポイント▲1▼,▲2▼,▲3▼のいずれかに到達するまで、又は、他方のサーバS2が稼働を開始するまで、待機する(ステップS19)。
【0030】
[第三の実施形態]
上記した第一及び第二の実施形態では、クラスタ3内に二つのサーバS1,S2を設けた場合について説明した。以下の第三の実施形態では、図7に示すように、クラスタ3内に三つ以上のサーバS1,S2,S3・・・を設け、ロードバランサ31で負荷分配を行う場合について説明する。
図8は、この第三の実施形態におけるサーバの再起動の手順を説明するフローチャートである。なお、クラスタ3の基本構成は、図2に示した第一の実施形態のクラスタの構成と変わりがないので、以下の説明においては、適宜に図2のブロック図を参照するものとする。
なお、図3に示す第一の実施形態のフローチャートと同一ステップには同一の符号を付して、詳しい説明は省略する。
【0031】
一のサーバ(例えばサーバS1)のメモリリークが、しきい値を所定回数を超えてカウントされた場合(ステップS6)、当該一のサーバの監視部が、ロードバランサ31を介して、他のサーバS2,S3・・・に作用される負荷を求める。そして、サーバS1の再起動を行う際に、他のサーバS2,S3・・・の負荷が許容値を超えないことを条件に(ステップS8′)、システム再起動要求メッセージを表示し(ステップS10)、システムの再起動を行う(ステップS11)。
サーバS1の再起動を行う際に、他のサーバS2,S3・・・の負荷が許容値を超えるときには、所定時間待機する(ステップS9)。
【0032】
この実施形態においては、他のサーバの負荷が許容値を超えない範囲内で、複数台のサーバS1,S2,S3・・・について、同時に再起動を行うことが可能である。
また、複数のサーバS1,S2,S3・・・について、同時に、メモリリークのしきい値を越える回数が所定回数を超えた判断されたときは、負荷の許容値を超えない範囲内で、一部のサーバについて同時に再起動を行い、残りのサーバについては、前記一部のサーバの再起動終了後に、再起動を行うように設定することも可能である。
さらに、この実施形態では、第一の実施形態と同様に、複数のサーバS1,S2,S3・・・について監視等を行う時間をずらしたり、第二の実施形態と同様に、再起動の時間を所定の時間帯に限定することも可能である。
【0033】
本発明の好適な実施形態について説明してきたが、本発明は上記の実施形態によりなんら限定されるものではなく、本発明の適用範囲内で種々に変更することが可能である。
例えば、上記の実施形態では、メモリリークを状態監視の一手段として説明したが、システムの稼働状態を監視し、稼働状態が不安定又は停止する前に、再起動を行うように判断することができるのであれば、上記のメモリリークに限らず、他の状態監視の手段を用いることができる。例えば、メモリ上で実行されているプログラムの数を監視し、この数が予め設定された数を超えたときに再起動を行うようにすることも可能であるし、ハードディスク等でメモリの拡張を行っているような場合においては、仮想空間の空きページ数を監視し、このページ数が予め設定された数を超えたときに再起動を行うようにすることも可能である。
【0034】
【発明の効果】
本発明によれば、市販のパーソナルコンピュータとサーバとからなる安価なクライアント/サーバシステムを、長時間にわたって安定的に稼働させることができ、制御システムを低価格で構築することが可能なる。また、複数のサーバを設けて、サーバの稼働状態の監視を行い、稼働状態が不安定になる前に一のサーバの再起動を行うようにするだけで、簡単に実施が可能である。
【図面の簡単な説明】
【図1】本発明の第一の実施形態を示す図で、クライアント/サーバによる制御システムの全体構成を説明するブロック図である。
【図2】図1のクラスタの構成を示すブロック図である。
【図3】第一の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図4】本発明のクライアント/サーバにおける再起動のタイミングを示すグラフである。
【図5】サーバの負荷状態の時間変化を示すグラフである。
【図6】本発明の第二の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図7】本発明の第三の実施形態にかかり、クラスタ内に三つ以上のサーバを設けた場合を示すブロック図である。
【図8】第三の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図9】本発明の従来例にかかり、クライアント/サーバの構成を説明するブロック図である。
【図10】クライアント/サーバにおけるメモリリークと時間との関係を示したグラフである。
【符号の説明】
1 パーソナルコンピュータ
2 LAN
3 クラスタ
31 ロードバランサ
41,51 処理部(CPU)
42,52 メモリ
43,53 監視部
44,54 システム起動部
6 データベース
S1,S2・・・ サーバ
【発明の属する技術分野】
本発明は、クライアント/サーバシステムを用いて、プラント等の制御を行う制御システムの改良に関し、特に、市販のパーソナルコンピュータとサーバとからなる安価なクライアント/サーバシステムを用いて、前記制御システムを長時間にわたって安定的に動作させることができるクライアント/サーバによる制御システムの安定稼働方法に関する。
【0002】
【従来の技術】
各種プラントや設備、装置等の制御を行う制御システムとして、クライアント/サーバが利用されている。図9は、クライアント/サーバの構成を説明するブロック図で、クライアントである端末装置100と、この端末装置100から入力された要求にしたがって所定の処理を行うサーバ300と、このサーバ300の処理結果を格納するデータベース600と、端末装置100,サーバ300及びデータベース600を接続するLAN等の信号線200とから概略構成されている。サーバ300の処理結果は、信号線200を介して端末装置100に送信され、端末装置100のディスプレイ等に表示され、あるいは、データベース600に格納される。
【0003】
ところで、米マイクロソフト社製のWindows(登録商標)のように、市販されている汎用のOS(オペレーション・システム)の下で動作するサーバ300においては、いわゆるメモリリークによる問題がある。
図10は、クライアント/サーバにおけるメモリリークと時間との関係を示したグラフである。図10に示すように、上記のOS環境下においては、時間とともにメモリ資源が侵食されて、徐々に動作が不安定になるという問題が知られている(例えば、特許文献1参照)。
【0004】
【特許文献1】
特表2000−515279号公報(発明の詳細な説明の「2.背景」の記載参照)
【0005】
そして、動作不安定のままで運転を続けると、動作停止の状態に陥ったり、大きなメモリ領域を必要とするアプリケーションの実行が不可能になったりする。このような状態は、OSを再起動しなければ復帰することができず、実行中のアプリケーションの内容やデータが消去されるという問題がある。そのため、長時間連続して制御を行う必要のあるシステムにおいては、OSとしてメモリリークによる動作不安定が生じにくいもの、例えば、UNIX(登録商標)等をOSとして用いることが多い。
【0006】
しかしながら、このような制御システムは、価格が高いという問題がある。また、使用できるソフトウェアが限定されるという問題がある。さらに、近年のパソコンの低価格・高機能化にともない、制御システムに市販の安価なクライアント/サーバを利用したいという要望もある。
また、長時間の連続稼働による動作不安定や停止といった上記の問題を解決するための一つの手段として、クラスタシステムの利用が考えられる(例えば特許文献2参照)。
【0007】
【特許文献2】
特開2002−222125号公報(明細書の[0009]〜[0018]参照)
【0008】
前記したクラスタシステムは、複数のサーバ(ノード)で処理を行うシステムで、その中でもフェイルオーバー型クラスタは、障害が発生した場合でも業務の運用を継続させることができるものである。フェイルオーバー型のクラスタは、メインで動作するメインサーバと、メインサーバが正常に動作している間は待機状態にある待機サーバとを有していて、メインサーバに異常が発生したときに、ただちに待機サーバを起動させて処理を引き継がせるものである。
【0009】
しかし、このようなシステムでは、メインサーバの他に待機サーバを常に確保しておかねばならないという問題がある。そのため、クラスタで処理できる負荷がメインサーバによって決定され、処理上の無駄が生じるという問題がある。
全てのサーバをメインサーバとし、異常が発生したときに他のメインサーバが当該メインサーバの負荷を分担するようにすることで、上記の問題は解決できるが、高負荷時に異常が発生すると、メインサーバの許容負荷を超えてしまい、サーバの機能が低下するという問題が生じる。
【0010】
【発明が解決しようとする課題】
この発明は上記の問題点にかんがみてなされたもので、市販のパーソナルコンピュータとサーバとからなる安価なクライアント/サーバシステムにおいて、前記サーバの機能を低下又は停止させることなく、長時間にわたって安定的にシステムを稼働させることができ、かつ、簡単な改良を施すだけで実施が可能なクライアント/サーバによる制御システムの安定稼働方法を提供するものである。
【0011】
【課題を解決するための手段】
本発明の発明者は、鋭意研究を重ねた結果、サーバの稼働状態の監視を行い、稼働状態が不安定になる前に再起動を行うことで、継続的にシステムを安定化させることができることを見出した。
【0012】
具体的には、本発明は、請求項1に記載するように、パーソナルコンピュータを端末装置とするクライアント/サーバシステムにおいて、サーバを複数準備し、前記サーバの稼働状態を監視し、前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行う方法としてある。
【0013】
この場合、請求項2に記載するように、前記した予め設定された条件として、前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うようにするとよい。また、請求項3に記載するように、前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定されたしきい値を超える回数をカウントし、このカウント数が予め設定された回数を超えたときに、前記サーバの再起動を行うようにしてもよい。
前記しきい値を、メモリリークによってサーバが稼働しなくなる限界値に対して余裕をもって設定することで、メモリリークが前記しきい値を複数回連続して超えても、前記カウント数が所定回数になるまでは安定稼働を続けることができる。
【0014】
また、請求項4に記載するように、前記再起動を行う再起動時間を設定するとともに、前記監視を定期的に行い、稼働条件が予め設定された条件になったと判断されたときに、前記再起動時間に到達するまで待機して再起動を行うようにしてもよい。前記再起動時間としては、サーバに作用する負荷が最小になる時間帯を設定するとよい。このようにすることで、一のサーバについて再起動を行う際に、他のサーバに過大な負荷がかからないようにすることができる。
【0015】
請求項5に記載するように、複数の前記サーバについて稼働状態を相互に監視し、一のサーバが前記条件になったときに、他のサーバが稼働しているかどうかを判断して、前記他のサーバが稼働していることを条件に、前記再起動を行うようにするとよい。
このようにすることで、一のサーバと他のサーバの同時再起動を防止することができる。
【0016】
請求項6に記載の発明は、一のサーバの再起動を行う際に、他のサーバの負荷を検出し、前記一のサーバを停止させたときの前記他のサーバの負荷が許容量を超えないことを条件に、前記一のサーバの再起動を行う方法である。
このようにすることで、一のサーバについて再起動を行う際に、他のサーバに許容値を超える過大な負荷がかからないようにすることができる。
【0017】
請求項7に記載の発明は、前記サーバの個々について、稼働状態の監視時間及び/又は再起動を行う時間をずらした方法としてある。また、請求項8に記載の発明は、一の前記サーバについて再起動が完了するまで他の前記サーバの再起動を禁止する方法としてある。
これらの方法によっても、一のサーバと他のサーバの同時再起動を防止することができる。
【0018】
本発明の方法は、請求項9に記載するように、請求項1〜請求項8に記載の各ステップを実行するプログラムによって行うことができる。このプログラムは、FD(フレキシブルディスク)等の磁気ディスクや、CD(コンパクトディスク)等の光ディスクからCPUに読み込むことによって実行することができる他、インターネットや電話回線等の通信回線を介してCPUに読み込むことによっても実行することが可能である。
【0019】
【発明の実施の形態】
以下、本発明の好適な実施形態を、図面にしたがって詳細に説明する。
[第一の実施形態]
図1は、本発明の第一の実施形態を示す図で、クライアント/サーバによる制御システムの全体構成を説明するブロック図、図2は、クラスタの構成を示すブロック図である。
【0020】
この実施形態において、制御システムは、端末装置(クライアント)であるパーソナルコンピュータ(以下、PCと記載する)1と、このPC1の要求にしたがって処理を実行するクラスタ3と、処理の結果を格納するデータベース6とを有し、各々がLAN等の信号線2で接続されている。
この実施形態では、説明の便宜のため、クラスタ3の内部に、二つのサーバS1及びサーバS2が構築されているものとし、PC1から要求された処理を、この二つのサーバS1,S2で分担するものとする。
【0021】
なお、クラスタ3内に複数のサーバを設ける手段としては、ハードウェアとしてのサーバを複数設ける方法のほか、市販のクラスタソフトウェアやその他のソフトウェア(例えば、米マイクロソフト社製のOS、Windows(登録商標)2000アドバンスドサーバ)を用いる方法がある。
【0022】
サーバS1,S2の負担分散は、ロードバランサ31によって行われる。そして、サーバS1に負担された処理要求は、処理部41で、サーバS2に負担された処理要求は処理部51で処理される。通常、この処理は、サーバS1,S2のCPUで行われる。処理部41,51は、メモリ42,52との間でデータの授受を行いながら処理を実行するが、時間の経過とともにメモリ42,52の記憶領域が侵食されて、動作が徐々に不安定になる。
そこで、この実施形態では、メモリ42,52のメモリリークを監視することで、サーバS1,S2の動作状態を判断する監視部43,53を設けて、メモリリークが一定以上になったときに、この監視部43,53がシステム起動部44,54に指令を出力して、サーバS1,S2の再起動を行うようにしている。
【0023】
図3は、上記構成のクライアント/サーバにおける、再起動の手順を説明するフローチャートである。
クライアント/サーバの起動(ステップS1)とともに、監視部43,53によるメモリ42,52のメモリリークの監視が開始される(ステップS2)。
一方のサーバS1の監視部43は、他方のサーバS2の稼働状態(稼働しているかどうか)を監視し、他方のサーバS2の監視部53は、一方のサーバS1の稼働状態を監視する(ステップS3)。
【0024】
監視部43,53によるメモリリークの監視及び稼働状態の相互監視は、例えば1秒おきのように、定期的に行うのが好ましい。また、両方のサーバS1,S2が同時に再起動を行うことがないように、再起動に必要な分(例えば5分以上)だけ時間をずらして、メモリリークの監視を行うようにするとよい。
監視部43,53は、メモリリークが予め設定されたしきい値を超えたかどうかを判断し(ステップS4)、メモリリークがしきい値が超えたときに、その回数をカウントアップする(ステップS5)。
この場合、カウントの途中でメモリリークがしきい値を下回ったときにカウンタをリセットするようにして、しきい値を超えるメモリリークが連続して検出されていることを条件に、カウントアップを行うように設定することも可能である。
【0025】
図4は、本発明のクライアント/サーバにおける再起動のタイミングを、メモリリークと時間との関係で示したグラフである。
前記したしきい値は、図4に示すように、メモリリークが動作不良を引き起こす限界値の下方に、余裕をもって設定する。すなわち、メモリリークがしきい値を超える回数を、監視部43,53が予め設定した回数以上検出しても、前記限界値に達しないように、しきい値を前記限界値よりも十分下方に設定する。
監視部43,53は、メモリリークがしきい値が超えた回数が予め設定された回数(例えば60回)を超えたかどうかを判断する(ステップS6)。
【0026】
そして、監視部43は、例えば一方のサーバS1が前記回数を超えたときに、他方のサーバS2が稼働していること(ステップS8)を条件に、再起動要求メッセージを表示すし(ステップS10)、再起動を行うようにシステム起動部44に指令を出力する(ステップS11)。再起動完了後は、カウンタのリセットを行って(ステップS12)、ステップS2以下の処理を繰り返す。
なお、ステップS8で他方のサーバS2が稼働を停止している場合は、他方のサーバS2が稼働を開始するまで、再起動を行うことなく待機する(ステップS9)。
【0027】
[第二の実施形態]
第一の実施形態で説明した手順により、一方のサーバS1(又は他方のサーバS2)の再起動を開始すると、再起動中における他方のサーバS2(又は一方のサーバS1)の負荷は増大する。この負荷の増大は、可能な限り小さいものであることが好ましい。
図5は、サーバS1及びサーバS2の負荷状態の時間変化を示すグラフである。一般に、サーバの負荷は、時間によって変化する。そのため、負荷状態が大きいときに、例えば一方のサーバS1の再起動を行うと、他方のサーバS2に過大な負荷が作用し、サーバS2の機能が低下するおそれがある。
そこで、この第二の実施形態では、サーバS1,S2の再起動を、サーバS1,S2の負荷が小さい時間帯に行うようにしている。すなわち、図5のグラフに示す例においては、負荷状態が最も小さくなるポイント▲1▼,▲2▼,▲3▼のいずれかの時間帯で、再起動を行うようにする。
【0028】
負荷の小さい時間帯に限定してサーバS1又はサーバS2の再起動を行うようにした場合の処理の手順を、図6のフローチャートを参照しながら説明する。なお、図3に示す第一の実施形態のフローチャートと同一ステップには同一の符号を付して、詳しい説明は省略するものとする。また、以下の説明においては、適宜に図2のブロック図を参照するものとする。
一方のサーバS1の監視部43(図2参照)は、メモリリークがしきい値を越える回数をカウント(ステップS5)、この回数が所定回数を超えたときに(ステップS6)、システム再起動要求メッセージを表示するとともに(ステップS17)、システム起動部44に対して、システム再起動予約を行う(ステップS18)。この再起動の予約は、サーバS1,S2に対する負荷が小さくなる図5中のポイント▲1▼,▲2▼,▲3▼のいずれかを指定して行われる。
【0029】
そして、システム起動部44は、現在時刻が、図5中のポイント▲1▼,▲2▼,▲3▼のいずれかに到達しているかどうかを判断し(ステップS20)、到達している場合には、他方のサーバS2が稼働していることを条件に(ステップS21)、システムの再起動を実行する(ステップS22)。再起動実行後は、カウンタをリセットして(ステップS23)、ステップS2以下の処理を繰り返す。
なお、ステップS20で、到達していないと判断した場合、又はステップS21で他方のサーバS2が稼働していないと判断した場合は、ポイント▲1▼,▲2▼,▲3▼のいずれかに到達するまで、又は、他方のサーバS2が稼働を開始するまで、待機する(ステップS19)。
【0030】
[第三の実施形態]
上記した第一及び第二の実施形態では、クラスタ3内に二つのサーバS1,S2を設けた場合について説明した。以下の第三の実施形態では、図7に示すように、クラスタ3内に三つ以上のサーバS1,S2,S3・・・を設け、ロードバランサ31で負荷分配を行う場合について説明する。
図8は、この第三の実施形態におけるサーバの再起動の手順を説明するフローチャートである。なお、クラスタ3の基本構成は、図2に示した第一の実施形態のクラスタの構成と変わりがないので、以下の説明においては、適宜に図2のブロック図を参照するものとする。
なお、図3に示す第一の実施形態のフローチャートと同一ステップには同一の符号を付して、詳しい説明は省略する。
【0031】
一のサーバ(例えばサーバS1)のメモリリークが、しきい値を所定回数を超えてカウントされた場合(ステップS6)、当該一のサーバの監視部が、ロードバランサ31を介して、他のサーバS2,S3・・・に作用される負荷を求める。そして、サーバS1の再起動を行う際に、他のサーバS2,S3・・・の負荷が許容値を超えないことを条件に(ステップS8′)、システム再起動要求メッセージを表示し(ステップS10)、システムの再起動を行う(ステップS11)。
サーバS1の再起動を行う際に、他のサーバS2,S3・・・の負荷が許容値を超えるときには、所定時間待機する(ステップS9)。
【0032】
この実施形態においては、他のサーバの負荷が許容値を超えない範囲内で、複数台のサーバS1,S2,S3・・・について、同時に再起動を行うことが可能である。
また、複数のサーバS1,S2,S3・・・について、同時に、メモリリークのしきい値を越える回数が所定回数を超えた判断されたときは、負荷の許容値を超えない範囲内で、一部のサーバについて同時に再起動を行い、残りのサーバについては、前記一部のサーバの再起動終了後に、再起動を行うように設定することも可能である。
さらに、この実施形態では、第一の実施形態と同様に、複数のサーバS1,S2,S3・・・について監視等を行う時間をずらしたり、第二の実施形態と同様に、再起動の時間を所定の時間帯に限定することも可能である。
【0033】
本発明の好適な実施形態について説明してきたが、本発明は上記の実施形態によりなんら限定されるものではなく、本発明の適用範囲内で種々に変更することが可能である。
例えば、上記の実施形態では、メモリリークを状態監視の一手段として説明したが、システムの稼働状態を監視し、稼働状態が不安定又は停止する前に、再起動を行うように判断することができるのであれば、上記のメモリリークに限らず、他の状態監視の手段を用いることができる。例えば、メモリ上で実行されているプログラムの数を監視し、この数が予め設定された数を超えたときに再起動を行うようにすることも可能であるし、ハードディスク等でメモリの拡張を行っているような場合においては、仮想空間の空きページ数を監視し、このページ数が予め設定された数を超えたときに再起動を行うようにすることも可能である。
【0034】
【発明の効果】
本発明によれば、市販のパーソナルコンピュータとサーバとからなる安価なクライアント/サーバシステムを、長時間にわたって安定的に稼働させることができ、制御システムを低価格で構築することが可能なる。また、複数のサーバを設けて、サーバの稼働状態の監視を行い、稼働状態が不安定になる前に一のサーバの再起動を行うようにするだけで、簡単に実施が可能である。
【図面の簡単な説明】
【図1】本発明の第一の実施形態を示す図で、クライアント/サーバによる制御システムの全体構成を説明するブロック図である。
【図2】図1のクラスタの構成を示すブロック図である。
【図3】第一の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図4】本発明のクライアント/サーバにおける再起動のタイミングを示すグラフである。
【図5】サーバの負荷状態の時間変化を示すグラフである。
【図6】本発明の第二の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図7】本発明の第三の実施形態にかかり、クラスタ内に三つ以上のサーバを設けた場合を示すブロック図である。
【図8】第三の実施形態におけるサーバの再起動の手順を説明するフローチャートである。
【図9】本発明の従来例にかかり、クライアント/サーバの構成を説明するブロック図である。
【図10】クライアント/サーバにおけるメモリリークと時間との関係を示したグラフである。
【符号の説明】
1 パーソナルコンピュータ
2 LAN
3 クラスタ
31 ロードバランサ
41,51 処理部(CPU)
42,52 メモリ
43,53 監視部
44,54 システム起動部
6 データベース
S1,S2・・・ サーバ
Claims (9)
- パーソナルコンピュータとサーバとを有するクライアント/サーバシステムにおいて、
サーバを複数準備し、
前記サーバの稼働状態を監視し、
前記サーバの稼働状態が予め設定された条件になったときに、前記サーバの再起動を行うこと、
を特徴とするクライアント/サーバによる制御システムの安定稼働方法。 - 前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定された値を超えたときに、前記サーバの再起動を行うことを特徴とする請求項1に記載のクライアント/サーバによる制御システムの安定稼働方法。
- 前記サーバの稼働状態の監視をメモリリークに基づいて行い、前記メモリリークが予め設定されたしきい値を超える回数をカウントし、このカウント数が予め設定された回数を超えたときに、前記サーバの再起動を行うことを特徴とする請求項1に記載のクライアント/サーバによる制御システムの安定稼働方法。
- 前記再起動を行う再起動時間を設定するとともに、前記監視を定期的に行い、稼働条件が予め設定された条件になったと判断されたときに、前記再起動時間に到達するまで待機して再起動を行うことを特徴とする請求項1〜3のいずれかに記載のクライアント/サーバによる制御システムの安定稼働方法。
- 複数の前記サーバについて稼働状態を相互に監視し、一のサーバが前記条件になったときに、他のサーバが稼働しているかどうかを判断して、前記他のサーバが稼働していることを条件に、前記再起動を行うことを特徴とする請求項1〜4のいずれかに記載のクライアント/サーバによる制御システムの安定稼働方法。
- 一のサーバの再起動を行う際に、他のサーバの負荷を検出し、前記一のサーバを停止させたときの前記他のサーバの負荷が許容量を超えないことを条件に、前記一のサーバの再起動を行うことを特徴とする請求項1〜5のいずれかに記載のクライアント/サーバによる制御システムの安定稼働方法。
- 前記サーバの個々について、稼働状態の監視時間及び/又は再起動を行う時間をずらしたことを特徴とする請求項1〜6のいずれかに記載のクライアント/サーバによる制御システムの安定稼働方法。
- 一の前記サーバについて再起動が完了するまで他の前記サーバの再起動を禁止することを特徴とする請求項1〜7のいずれかに記載のクライアント/サーバによる制御システムの安定稼働方法。
- 請求項1〜8のいずれかに記載の方法を実行するプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002378918A JP2004213122A (ja) | 2002-12-27 | 2002-12-27 | クライアント/サーバによる制御システムの安定稼働方法及びそのプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002378918A JP2004213122A (ja) | 2002-12-27 | 2002-12-27 | クライアント/サーバによる制御システムの安定稼働方法及びそのプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004213122A true JP2004213122A (ja) | 2004-07-29 |
Family
ID=32815588
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002378918A Pending JP2004213122A (ja) | 2002-12-27 | 2002-12-27 | クライアント/サーバによる制御システムの安定稼働方法及びそのプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004213122A (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007257259A (ja) * | 2006-03-23 | 2007-10-04 | Nec Corp | 情報処理装置、記憶領域クリーンアップ方法およびプログラム |
JP2007328396A (ja) * | 2006-06-06 | 2007-12-20 | Hitachi Ltd | 記憶システム並びに管理装置及び方法 |
JP2011233075A (ja) * | 2010-04-30 | 2011-11-17 | Nec System Technologies Ltd | 資源解放漏れ判定装置、メモリリーク判定装置、資源解放漏れ判定方法およびプログラム |
JP2012083841A (ja) * | 2010-10-07 | 2012-04-26 | Fujitsu Advanced Engineering Ltd | プログラム、アプリケーションサーバ装置の制御方法、アプリケーションサーバ装置 |
WO2014132466A1 (ja) * | 2013-02-28 | 2014-09-04 | 日本電気株式会社 | ソフトウェア安全停止システム、ソフトウェア安全停止方法、およびプログラム |
JP2015114825A (ja) * | 2013-12-11 | 2015-06-22 | Necプラットフォームズ株式会社 | コンピュータシステム及びその動作方法 |
-
2002
- 2002-12-27 JP JP2002378918A patent/JP2004213122A/ja active Pending
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007257259A (ja) * | 2006-03-23 | 2007-10-04 | Nec Corp | 情報処理装置、記憶領域クリーンアップ方法およびプログラム |
JP2007328396A (ja) * | 2006-06-06 | 2007-12-20 | Hitachi Ltd | 記憶システム並びに管理装置及び方法 |
JP2011233075A (ja) * | 2010-04-30 | 2011-11-17 | Nec System Technologies Ltd | 資源解放漏れ判定装置、メモリリーク判定装置、資源解放漏れ判定方法およびプログラム |
JP2012083841A (ja) * | 2010-10-07 | 2012-04-26 | Fujitsu Advanced Engineering Ltd | プログラム、アプリケーションサーバ装置の制御方法、アプリケーションサーバ装置 |
WO2014132466A1 (ja) * | 2013-02-28 | 2014-09-04 | 日本電気株式会社 | ソフトウェア安全停止システム、ソフトウェア安全停止方法、およびプログラム |
JPWO2014132466A1 (ja) * | 2013-02-28 | 2017-02-02 | 日本電気株式会社 | ソフトウェア安全停止システム、ソフトウェア安全停止方法、およびプログラム |
US9588798B2 (en) | 2013-02-28 | 2017-03-07 | Nec Corporation | Software safe shutdown system, software safe shutdown method, and program to prevent a problem caused by a system failure |
JP2015114825A (ja) * | 2013-12-11 | 2015-06-22 | Necプラットフォームズ株式会社 | コンピュータシステム及びその動作方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI267782B (en) | Deallocation of computer data in a multithreaded computer | |
US8204979B2 (en) | Adaptive client/server control protocol | |
US7047484B1 (en) | Method, system, and apparatus for providing access to asynchronous data in a spreadsheet application program | |
US20210149732A1 (en) | Resource Conservation for Containerized Systems | |
US20100005465A1 (en) | Virtual machine location system, virtual machine location method, program, virtual machine manager, and server | |
US20180113764A1 (en) | Hypervisor Based Watchdog Timer | |
US20170126582A1 (en) | Idle Worker-Process Page-Out | |
EP1329809B1 (en) | Distributed computing system and method | |
US20060242453A1 (en) | System and method for managing hung cluster nodes | |
US7162629B2 (en) | Method to suspend-and-resume across various operational environment contexts | |
US7315959B2 (en) | Real-time remote backup system and related method | |
US7546604B2 (en) | Program reactivation using triggering | |
US6351824B1 (en) | Methods and apparatuses for controlling the operation of a digital processing system | |
JP2004213122A (ja) | クライアント/サーバによる制御システムの安定稼働方法及びそのプログラム | |
JP4009192B2 (ja) | 効率的なタイマ管理システム | |
US7797473B2 (en) | System for executing system management interrupts and methods thereof | |
JPH0822424A (ja) | クライアント・サーバ・システムおよびその制御方法 | |
CA2365427A1 (en) | Internal product fault monitoring apparatus and method | |
WO2022228012A1 (zh) | 异常处理方法、装置、电子设备及*** | |
US11714696B2 (en) | Custom baseboard management controller (BMC) firmware stack watchdog system and method | |
CN107704399B (zh) | 一种存储数据的方法和装置 | |
JP2868447B2 (ja) | トランザクション処理タスク数制御方式 | |
JP2000132428A (ja) | コンピュータシステム、コンピュータシステムのアプリケーション監視方法、及びプログラム記録媒体 | |
JPH11288406A (ja) | 動作監視機能付きマルチプロセッサシステム | |
JP2009042873A (ja) | ネットワークアプリケーションの利用制限システム、利用制限方法、及びプログラム。 |