JP2008250427A - 情報処理システムに用いられるバージョンアップ装置及び該装置を備えた情報処理システム並びに情報処理システムをバージョンアップするためのプログラム - Google Patents

Abstract

【課題】複数のサーバとクライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムを停止させずにかつデータの引き継ぎ作業を行わずにバージョンアップする。
【解決手段】情報処理システム１０に備えられた管理サーバ２０は、サーバ１１…１１に格納されているソフトウエアのバージョンアップ指令を受け付ける受付手段２１ｂと、受付手段２１ｂでバージョンアップ指令を受け付けたとき、複数のサーバ１１…１１のうちの所定のサーバ１１を停止させ、そのサーバ１１に格納されているソフトウエアをバージョンアップするバージョンアップ手段２１ａと、バージョンアップ手段２１ａによるサーバ１１の停止及びバージョンアップの作業を各サーバ１１について順次行うことにより全てのサーバ１１…１１に格納されているソフトウエアをバージョンアップする制御手段２１ａとを備える。
【選択図】図１

Description

本発明は情報処理システム、特に、システム全体としての処理の高速化を図るために、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムをバージョンアップする技術分野に属する。

近年、飛行機やホテルの予約サービス、あるいは銀行のオンラインサービス等が、クライアントコンピュータとサーバコンピュータとが専用回線で相互に情報通信可能に接続されたクライアントサーバシステムを用いて提供されることが多くなっている。このようなクライアントサーバシステムでは、システムダウンが起きると、業務に多大の影響を及ぼすことになるので、営業中は安定に連続運転することが求められている。そのため、例えば、サーバ側のハードウエアを稼動系と待機系とに二重化しておき、万が一稼働系がシステムダウンしても、待機系を直ちに稼働系として用いることができるように待機系を常時アップデートしておく、等の対策が一般に行われている。

一方、クライアントサーバシステム全体としての処理の高速化を図るために、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを備えることが知られている。この負荷分散機の動作として、例えば特許文献１には、複数のホストコンピュータ間で端末からの処理要求による負荷を分散させるために、各コンピュータの処理能力の余裕度を各コンピュータから定期的に収集しておき、現在処理能力の余裕度が最も高いコンピュータに端末からの新たな処理要求を依頼することや、現在確立されているセッションの数が最も少ないホストコンピュータに端末からの新たな処理要求を依頼することが記載されている。いずれにしても、負荷分散機は、稼動中のサーバになるべく均等に処理要求を依頼して負荷分散を図るものであり、何等かの理由によって稼働停止中のサーバには処理要求を依頼しないものである。

ところで、クライアントサーバシステムはセキュリティの向上やバグの修正等のために機能を改善したり追加する頻度が高く、そのため、システムのバージョンアップ、つまりサーバに格納されているアプリケーションモジュール等のソフトウエアの更新（バージョンアップ）が頻繁に行われる。このシステムのバージョンアップ時の動作として、例えば特許文献２には、稼働系と待機系の１＋１冗長構成の複数プロセッサシステムにおいて、稼働系プロセッサを稼働させたまま、待機系プロセッサのソフトウエアを更新し、次いで、サービスに必要な各種データを稼働系プロセッサのメモリから待機系プロセッサのメモリへ引き継ぎ、その後、待機系プロセッサと稼働系プロセッサとを相互に切り替える技術が記載されている。

特開平９−９７２３３（段落０００３、０００７） 特開２００２−４９５０２（段落００１４）

しかしながら、特許文献２に記載の技術は、システムをバージョンアップするに際し、待機系プロセッサと稼働系プロセッサとを切り替えるものであるから、この技術をクライアントサーバシステムにそのまま適用すると、たとえ短時間であってもその切替時にはシステムが停止することになり、その停止中はクライアントからの処理要求が受け付けられなくなる。

また、特許文献２に記載の技術は、待機系プロセッサのデータを稼働系プロセッサのデータにアップデートさせるために、待機系プロセッサと稼働系プロセッサとの切替えを行う前に、サービスに必要な各種データを稼働系プロセッサのメモリから待機系プロセッサのメモリへ引き継ぐ作業を行わなければならず、そのためのソフトウエアを別途準備する必要がある。

本発明は、システム全体としての処理の高速化を図るために、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムをバージョンアップする際に生じ得る前記のような不具合に対処するもので、システムを停止させることなく、かつ、データの引き継ぎ作業を行うことなく、システムをバージョンアップすることが可能な技術の提供を課題とする。

前記課題を解決するため、請求項１に記載の発明は、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムに用いられるバージョンアップ装置であって、前記情報処理システムの外部から入力される、前記サーバに格納されているソフトウエアのバージョンアップ指令を受け付ける受付手段と、この受付手段で前記バージョンアップ指令を受け付けたとき、複数のサーバのうちの所定のサーバを停止させ、そのサーバに格納されているソフトウエアをバージョンアップするバージョンアップ手段と、このバージョンアップ手段によるサーバの停止及びバージョンアップの作業を各サーバについて順次行うことにより、全てのサーバに格納されているソフトウエアをバージョンアップする制御手段とを備えていることを特徴とする。

次に、請求項２に記載の発明は、請求項１に記載の情報処理システムに用いられるバージョンアップ装置であって、各サーバの稼働率を検出する稼働率検出手段を備え、前記バージョンアップ手段は、既にバージョンアップが済んでいるサーバを除き、この稼働率検出手段で検出された稼働率が最も低いサーバを停止させることを特徴とする。

次に、請求項３に記載の発明は、請求項１又は２に記載の情報処理システムに用いられるバージョンアップ装置であって、前記受付手段で前記バージョンアップ指令を受け付けたとき、前記バージョンアップ手段が所定のサーバを停止させる前に、サーバに現在格納されているソフトウエアの現行バージョンをバックアップするバックアップ手段と、前記バージョンアップ手段によるバージョンアップが成功したか否かを判定する成否判定手段と、この成否判定手段でバージョンアップが失敗したと判定したとき、前記サーバに格納されているソフトウエアを前記バックアップ手段でバックアップした現行バージョンに復帰させる復帰手段とを備えていることを特徴とする。

次に、請求項４に記載の発明は、請求項１から３のいずれかに記載の情報処理システムに用いられるバージョンアップ装置であって、サーバに格納されているソフトウエアのバージョンアップに伴い、クライアントに格納されているソフトウエアのバージョンアップが必要か否かを判定する要否判定手段と、この要否判定手段でバージョンアップが必要と判定したとき、サーバ側のバージョンアップが完了したのち処理要求をしてきた各クライアントについてそのクライアントに格納されているソフトウエアを順次バージョンアップしていく第２のバージョンアップ手段とを備えていることを特徴とする。

次に、請求項５に記載の発明は、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムであって、請求項１から４のいずれかに記載のバージョンアップ装置を備えていることを特徴とする。

次に、請求項６に記載の発明は、請求項５に記載の情報処理システムであって、前記負荷分散機は、複数のサーバのうちのいずれのサーバが停止しているかを検出する停止検出手段を備えていることを特徴とする。

次に、請求項７に記載の発明は、請求項５に記載の情報処理システムであって、前記バージョンアップ装置は、複数のサーバのうちのいずれのサーバを停止させたかを前記負荷分散機に通知する通知手段を備えていることを特徴とする。

なお、前記請求項１〜４に記載のバージョンアップ装置の各手段、及び前記請求項５〜７に記載の情報処理システムの各手段は、コンピュータの中央処理装置、入力装置、出力装置、通信装置、記録装置等のハードウエア資源と、これらのハードウエア資源を用いて各手段の動作を実現するプログラムとによって構成される。

次に、請求項８に記載の発明は、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムをバージョンアップするためのプログラムであって、コンピュータを、前記情報処理システムの外部から入力される、前記サーバに格納されているソフトウエアのバージョンアップ指令を受け付ける受付手段、この受付手段で前記バージョンアップ指令を受け付けたとき、複数のサーバのうちの所定のサーバを停止させ、そのサーバに格納されているソフトウエアをバージョンアップするバージョンアップ手段、及び、このバージョンアップ手段によるサーバの停止及びバージョンアップの作業を各サーバについて順次行うことにより、全てのサーバに格納されているソフトウエアをバージョンアップする制御手段として機能させることを特徴とする。

まず、請求項１に記載の発明によれば、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムに用いられるバージョンアップ装置において、受付手段とバージョンアップ手段とが備えられ、前記サーバに格納されているソフトウエアのバージョンアップ指令が前記情報処理システムの外部から入力されて、これを受付手段が受け付けたとき、バージョンアップ手段が複数のサーバのうちの所定のサーバを停止させるから、負荷分散機は、このバージョンアップ手段によって停止されたサーバ、つまり稼動中でないサーバに対しては処理要求を依頼することがなくなり、この停止中のサーバを除く他の稼動中のサーバ間で負荷分散を図ることになる。

そして、バージョンアップ手段は、停止させたサーバに格納されているソフトウエアをバージョンアップするので、このようなサーバの停止及びバージョンアップという一連の作業により、複数のサーバのうちの所定のサーバについてのバージョンアップが完了することになる。

そして、制御手段が、このようなバージョンアップ手段によるサーバの停止及びバージョンアップという一連の作業を各サーバについて順次行うことにより、全てのサーバに格納されているソフトウエアをバージョンアップするから、結局、システム全体として見たときには、従来のように稼働系と待機系とを切り替える、というようなことをせずに済み、複数のサーバのうちの所定のサーバのみが一時的に停止するだけで、他の複数のサーバは稼動中のままであるから、システム全体としては停止することがない。その結果、クライアントからの処理要求がシステムのバージョンアップ中も常時受け付け可能であって、情報処理システムの営業中における安定な連続運転が達成される。

しかも、このように稼働系と待機系との切替えを行わないから、サービスに必要な各種データを稼働系から待機系へ引き継ぐ作業を行わずに済み、そのためのソフトウエアを別途準備する必要がなくなる。

次に、請求項２に記載の発明によれば、バージョンアップ装置に、各サーバの稼働率を検出する稼働率検出手段が備えられ、バージョンアップ手段は、この稼働率検出手段で検出された稼働率が最も低いサーバ、換言すれば、負荷が最も少ないサーバ（処理能力の余裕度が最も高いサーバ）を停止させるから、システム全体としての処理の高速化を大きく減損することなく、複数のサーバを順次バージョンアップしていくことが可能となる。

しかも、既にバージョンアップが済んでいるサーバを除いて稼働率が最低のサーバを停止させるから、既にバージョンアップが済んでいるサーバを再びバージョンアップするというような無駄な動作が回避される。

なお、稼働率検出手段は、各サーバの稼働率を定期的に検出してもよく、あるいは、システム外部からのバージョンアップ指令が受け付けられたときに検出してもよい。

次に、請求項３に記載の発明によれば、バージョンアップ装置にバックアップ手段が備えられ、このバックアップ手段は、システム外部からのバージョンアップ指令が受け付けられたとき、前記バージョンアップ手段により所定のサーバが停止される前に、サーバに現在格納されているソフトウエアの現行バージョンをバックアップするから、前記バージョンアップ手段によるバージョンアップが開始される前にソフトウエアの現行バージョンがバージョンアップ装置に保存されることになる。

そして、前記バージョンアップ手段によるバージョンアップが失敗したと判定されたときは、復帰手段が、停止されたサーバに格納されているソフトウエアを前記バックアップ手段でバックアップした現行バージョンに復帰させるから、たとえバージョンアップがうまくいかなかった場合でも、サーバを元のバージョンのソフトウエアで再び稼動させることができ、その結果、サーバの停止時間が徒に長引くことが回避されて、稼動中のサーバの数が減少している時間、つまりシステム全体としての処理の高速化が減損している時間の短縮化が図られることになる。

次に、請求項４に記載の発明によれば、バージョンアップ装置に要否判定手段が備えられ、この要否判定手段により、サーバ側のバージョンアップに伴い、クライアントに格納されているソフトウエアのバージョンアップが必要と判定されたときは、第２のバージョンアップ手段が、サーバ側のバージョンアップが完了したのち処理要求をしてきた各クライアントについてそのクライアントに格納されているソフトウエアを順次バージョンアップしていくから、サーバ側とクライアント側とで共に全機器がバージョンアップされ、その結果、クライアントを用いて情報処理システムが提供するサービスを利用する者が、セキュリティの向上やバグの修正等のための機能の改善や追加の効果を満足に享受することが可能となる。

次に、請求項５に記載の発明によれば、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムにおいて、請求項１から４のいずれかに記載のバージョンアップ装置が備えられたから、前記請求項１から前記請求項４に記載した発明の効果と同様の効果が奏される情報処理システムが得られることになる。

次に、請求項６に記載の発明によれば、負荷分散機に、複数のサーバのうちのいずれのサーバが停止しているかを検出する停止検出手段が備えられたから、負荷分散機は、複数のサーバのうちのいずれのサーバが停止中であるかの情報、換言すれば、クライアントからの処理要求をいずれのサーバに依頼できるかの情報を自ら収集することができる。

なお、停止検出手段は、停止中のサーバを定期的に検出してもよく、あるいは、クライアントから新たな処理要求があったときに検出してもよい。

次に、請求項７に記載の発明によれば、バージョンアップ装置に、複数のサーバのうちのいずれのサーバを停止させたかを負荷分散機に通知する通知手段が備えられたから、負荷分散機は、複数のサーバのうちのいずれのサーバが停止中であるかの情報、換言すれば、クライアントからの処理要求をいずれのサーバに依頼できるかの情報を自ら収集する必要がなくなる。

次に、請求項８に記載の発明によれば、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムをバージョンアップするためのプログラムにおいて、コンピュータを、請求項１に記載の受付手段、バージョンアップ手段、及び、制御手段として機能させるから、このプログラムをコンピュータに搭載すれば、請求項１に記載のバージョンアップ装置と同様の装置及び同様の効果が得られることになる。

以下、図面を参照して本発明の最良の実施の形態を説明する。なお、本実施形態に係る管理サーバ２０（バージョンアップ装置）に搭載されたプログラムは、本発明に係る情報処理システム１０をバージョンアップするためのプログラムの実施の形態を構成する。

図１は、本実施形態に係る情報処理システム１０の構成図である。この情報処理システム１０は、クライアントサーバシステムであって、複数のアプリケーションサーバ１１…１１（１号機〜Ｘ号機）と、複数のクライアントコンピュータ１３…１３とが、専用回線１４を介して、相互に情報通信可能に接続されている。アプリケーションサーバ（以下単に「サーバ」ということがある）１１…１１は、例えば飛行機やホテルの予約サービス等を提供する者の側にあり、クライアントコンピュータ（以下単に「クライアント」ということがある）１３…１３は、そのサービスを利用する者の側にある。

特に、この情報処理システム１０は、システム全体としての処理の高速化を図るために、クライアント１３…１３からの処理要求による負荷を稼動中のサーバ１１…１１間で分散させる負荷分散機１２が備えられている。負荷分散機１２は、サーバ１１…１１と専用回線１４との間に配設され、クライアント１３…１３からの処理要求を稼動中のサーバ１１…１１間でなるべく均等に割り振って、サーバ１１…１１間で負荷の均等化を図るものである。その場合に、負荷分散機１２は、理由の如何を問わず、稼動が停止中のサーバ１１…１１にはクライアント１３…１３からの処理要求を依頼しないようになっている。

負荷分散機１２は、複数のサーバ１１…１１のうちの特定のサーバ１１に負荷が集中する結果、システム全体としての処理速度が低下する、という不具合を抑制するもので、例えば、クライアント１３から新たな処理要求を受け付けたときに、複数のサーバ１１…１１のうち現在最も処理能力に余裕のある（負荷が最も少ない）サーバを選択し、そのサーバに新たな処理要求を依頼するように構成されている。

また、この情報処理システム１０は、セキュリティの向上やバグの修正等のために、サーバ１１…１１に格納されたソフトウエアをバージョンアップする際に主たる機能を発揮するアプリケーションサーバ管理部２１と、クライアント１３…１３に格納されたソフトウエアをバージョンアップする際に主たる機能を発揮するクライアント管理部２２とを有する管理サーバ２０（特許請求の範囲の「バージョンアップ装置」に相当する）が、サーバ１１…１１と専用回線１４との間に配設されている。

図示したように、アプリケーションサーバ１１及び管理サーバ２０のアプリケーションサーバ管理部２１は、コンピュータで構成され、ＣＰＵ等の中央処理装置１１ａ，２１ａ、外部から情報を入力するための入力装置１１ｂ，２１ｂ、外部へ情報を出力するための出力装置１１ｃ，２１ｃ、他の機器との情報通信を管理する通信装置１１ｄ，２１ｄ、及び、各種プログラムやデータを格納するためのメインメモリやＲＯＭ、ＲＡＭ等の記録装置１１ｅ，２１ｅ等が、バスを介して相互に接続されている。特に、管理サーバ２０のアプリケーションサーバ管理部２１は、その入力装置２１ｂを介して、この情報処理システム１０のバージョンアップ指令を情報処理システム１０の外部から受け付けるようになっている。バージョンアップ指令は、例えばこの情報処理システム１０の管理者が必要時に適宜のタイミングで出すものである。

図２は、この情報処理システム１０の通常稼動時における主な信号の流れを示す機能ブロック図、図３は、この情報処理システム１０のバージョンアップ時における主な信号の流れを示す機能ブロック図である。これらの図２及び図３においては、アプリケーションサーバ１１の内部構成を機能別に示してある。

アプリケーションサーバ１１のアプリケーション制御部（フレームワーク）Ａ，Ｂ，…は、負荷分散機１２及び管理サーバ２０と信号を授受し合うもので、中央処理装置１１ａ及び通信装置１１ｄ等のハードウエア資源と、これらのハードウエア資源を用いて該当する機能を実現するプログラムとによって構成されている。

アプリケーションサーバ１１の処理装置は、アプリケーション制御部Ａ，Ｂ，…と信号を授受し合うもので、中央処理装置１１ａ等のハードウエア資源と、これらのハードウエア資源を用いて該当する機能を実現するプログラムとによって構成されている。

アプリケーションサーバ１１のアプリケーションモジュール格納部Ａ，Ｂ，…は、サービスの提供に必要な各種プログラムやデータ等のアプリケーションモジュール（ソフトウエア）を格納し、呼び出しに応じてそのコピーを処理装置に提供するもので、記録装置１１ｅ等のハードウエア資源と、これらのハードウエア資源を用いて該当する機能を実現するプログラムとによって構成されている。

なお、図３に示したように、管理サーバ２０は、前記アプリケーションモジュール格納部Ａ，Ｂ，…に直接アクセスすることができ、該格納部Ａ，Ｂ，…にアプリケーションモジュールの新バージョンを書き込む（あるいは送信する）ことができる。

また、図２及び図３に示したように、本実施形態においては、特に、アプリケーション制御部及びアプリケーションモジュール格納部はそれぞれ種類の異なるものが複数づつ具備されている。その場合に、１つのアプリケーション制御部と１つのアプリケーションモジュール格納部とは相互に対応し合い、アプリケーション制御部Ａ，Ｂ，…はそれぞれアプリケーションモジュール格納部Ａ，Ｂ，…のために動作する。ただし、複数のアプリケーションサーバ１１…１１間でみれば、全てのアプリケーションサーバ１１…１１は相互に同じ機能を有している。つまり、種類の異なる同数のアプリケーション制御部及びアプリケーションモジュール格納部を具備しているのである。

図２に例示したように、この情報処理システム１０の通常稼動時は、まず、負荷分散機１２からアプリケーションサーバ１１のアプリケーション制御部に対して（どのアプリケーションサーバ１１のアプリケーション制御部を選択するかについては後述する：図４のステップＳ１３参照）、クライアント１３から要求された処理が依頼される（符号１）。アプリケーション制御部は、この処理依頼を受けると、処理装置にアプリケーションモジュールの実行指示を出す（符号２）。処理装置は、この実行指示を受けると、アプリケーションモジュール格納部から該当するアプリケーションモジュールを読み出して実行し、アプリケーション制御部にアプリケーションモジュールの実行完了を報告する（符号３）。そして、アプリケーション制御部から負荷分散機１２に処理の実行結果が送信され（符号４）、この実行結果は、処理を要求したクライアント１３に送られる。

これに対し、図３に例示したように、この情報処理システム１０のバージョンアップ時は、まず、管理サーバ２０からアプリケーションサーバ１１のアプリケーション制御部に対して（どのアプリケーションサーバ１１のアプリケーション制御部を選択するかについては後述する：図６のステップＳ３４参照）、停止命令が送信される（符号１）。アプリケーション制御部は、この停止命令を受けると、処理装置にアプリケーションモジュールの停止指示を出す（符号２）。処理装置は、この停止指示を受けると、現在実行中の処理が終わったときに、アプリケーション制御部にアプリケーションモジュールの停止完了を報告する（符号３）。そして、アプリケーション制御部から管理サーバ２０に停止完了が送信され（符号４）、管理サーバ２０は、この停止完了の通知を受けると、バージョンアップ命令として、アプリケーションサーバ１１のアプリケーションモジュール格納部に直接アクセスし、該格納部に格納されているアプリケーションモジュールを新バージョンに更新する（符号５）。

なお、アプリケーション制御部から管理サーバ２０に停止完了が送信された（符号４）後、このアプリケーション制御部が再び起動されるまでの間は、負荷分散機１２がこのアプリケーション制御部に稼働状況を問い合せると（符号ｉ）、アプリケーション制御部は、停止中である旨を送信する（符号ｉｉ）。これにより、負荷分散機１２は、複数のサーバ１１…１１のうちのいずれのサーバが停止しているかを検出することができる。

ここで、クライアント１３からの処理要求の種類に応じて、負荷分散機１２は、アプリケーションサーバ１１の制御部Ａか、Ｂか、Ｃか、…のいずれかにその処理を依頼する。そして、格納部Ａか、Ｂか、Ｃか、…のいずれかに格納されているアプリケーションモジュールＡか、Ｂか、Ｃか、…のいずれかが実行される。１つのサーバ１１において、例えばアプリケーションモジュールＡとアプリケーションモジュールＢとが同時に実行されることもあり、制御部Ａは停止中であるが制御部Ｂは稼動中であることもある。また、例えば制御部Ａが停止中で格納部Ａに格納されているアプリケーションモジュールＡがバージョンアップされつつ、制御部Ｂが稼動中で格納部Ｂに格納されているアプリケーションモジュールＢが実行されていることもある。

一般に、本明細書で、サーバについて稼動というのは、本実施形態では、サーバ１１の制御部Ａか、Ｂか、Ｃか、…について稼動という意味であり、サーバについて停止というのは、本実施形態では、サーバ１１の制御部Ａか、Ｂか、Ｃか、…について停止という意味である。これは、前述したように、本実施形態では、１つのサーバ１１において、複数種類のアプリケーション制御部Ａ，Ｂ，…、同種類のアプリケーションモジュール格納部Ａ，Ｂ，…及び同種類のアプリケーションモジュールＡ，Ｂ，…が備えられているからである。これに代えて、例えば、１つのサーバ１１に、１種類のアプリケーション制御部、１種類のアプリケーションモジュール格納部及び１種類のアプリケーションモジュールだけが備えられている場合は、サーバについて稼動というのは、機器としての１つのサーバ１１が稼動という意味となり、サーバについて停止というのは、機器としての１つのサーバ１１が停止という意味となる。そして、このように、機器としてのサーバ１１を単位とする場合も、サーバ１１内の制御部、格納部及びアプリケーションモジュールの組を単位とする場合も、いずれの場合も、負荷分散機１２又は管理サーバ２０に対して、稼動状況として「実行可」を送信するのは、クライアント１３からの処理要求を処理可能という意味であり、稼動状況として「停止中」を送信するのは、クライアント１３からの処理要求を処理不能という意味である（クライアント１３からの処理要求以外の動作（例えばバージョンアップに伴う動作）は実行可能）。

以下、図４〜図１０のフローチャートに従って、前記管理サーバ２０を含むこの情報処理システム１０の具体的動作をさらに詳しく説明する。

図４は、情報処理システム１０の通常稼動時における負荷分散機１２及びアプリケーションサーバ１１の具体的動作の１例を示すフローチャートである。まず、負荷分散機１２は、クライアント１３から新たな処理要求を受け付けると（ステップＳ１１）、サーバ１１…１１の稼動状況及び稼働率のモニタリングを実行する（ステップＳ１２）。

このモニタリングは、図５のフローチャートに従って行われる。まず、負荷分散機１２は、各サーバ１１のアプリケーション制御部（処理要求の種類に応じた制御部）に対し、稼働状況の問合せを行う（ステップＳ２１）。負荷分散機１２は、全サーバ１１…１１のアプリケーション制御部に稼働状況の問合せを行ったか否かを判定し（ステップＳ２２）、全サーバ１１…１１のアプリケーション制御部に稼動状況の問合せを行うまで稼働状況の問合せを続行する。一方、各サーバ１１のアプリケーション制御部は、この稼働状況の問合せを受け付けると（ステップＳ２３）、自己の稼働状況を負荷分散機１２に送信する（ステップＳ２４）。ここで、各サーバ１１のアプリケーション制御部は、稼働状況として「実行可」又は「停止中」を送信する。負荷分散機１２は、各サーバ１１からの稼働状況を受信する（ステップＳ２５）と共に、その応答時間（ステップＳ２１の問合せからステップＳ２５の受信までの時間）に基いて各サーバ１１のアプリケーション制御部の稼働率を記録する（ステップＳ２６）。ただし、この稼働率の記録は、稼働状況として「実行可」が送信されてきた場合に限られる（つまりサーバ１１のアプリケーション制御部が停止中のときは稼働率は記録しない）。ここで、応答時間が短いほど（応答速度が速いほど）、サーバ１１のアプリケーション制御部の現在の処理能力に余裕があると判断され、稼働率は低い値に記録される。また、負荷分散機１２は、各サーバ１１から稼働状況として「実行可」又は「停止中」を受信する（ステップＳ２５）ことにより、複数のサーバ１１…１１のうちのいずれのサーバが停止しているかを検出することができる（請求項６の停止検出手段）。

図４に戻り、次いで、負荷分散機１２は、複数のサーバ１１…１１のうちから、前記ステップＳ２５で受信した稼働状況が「実行可」であり、かつ、ステップＳ２６で記録した稼働率が最も低いサーバ１１のアプリケーション制御部を選択する（ステップＳ１３）。つまり、現在最も処理能力に余裕がある稼働中のサーバ１１を選択するのである。そして、負荷分散機１２は、その選択したサーバ１１のアプリケーション制御部に対し、クライアント１３から要求された処理を依頼する（ステップＳ１４：図２の符号１参照）。一方、サーバ１１は、この処理依頼を受けると、処理を実行し（ステップＳ１５：図２の符号２〜３参照）、その実行結果を負荷分散機１２に送信する（ステップＳ１６：図２の符号４参照）。負荷分散機１２は、前記実行結果を受信すると（ステップＳ１７）、これを処理を要求したクライアント１３に送る。情報処理システム１０は、通常稼動時は、このように動作することにより、複数のサーバ１１…１１間で負荷の均一分散が図られ、システム全体としての処理が高速化することになる。

次に、図６〜図１０は、情報処理システム１０のバージョンアップ時における管理サーバ２０及びアプリケーションサーバ１１の具体的動作の１例を示すフローチャートである。まず、管理サーバ２０は、前述したように、この情報処理システム１０の管理者が必要時に適宜のタイミングで出すバージョンアップ指令を受け付けると（ステップＳ３１：図１参照：このとき管理サーバ２０はアプリケーションモジュールの新バージョンを取り込む：請求項１及び請求項８の受付手段）、サーバ１１のアプリケーションモジュール格納部（処理要求の種類に応じた格納部）に現在格納されているアプリケーションモジュールの現行バージョンをバックアップする（ステップＳ３２：請求項４のバックアップ手段）。次いで、管理サーバ２０は、サーバ１１…１１の稼動状況及び稼働率のモニタリングを実行する（ステップＳ３３）。

このモニタリングは、図８のフローチャートに従って行われる。まず、管理サーバ２０は、各サーバ１１のアプリケーション制御部（処理要求の種類に応じた制御部）に対し、稼働状況の問合せを行う（ステップＳ５１）。管理サーバ２０は、全サーバ１１…１１のアプリケーション制御部に稼働状況の問合せを行ったか否かを判定し（ステップＳ５２）、全サーバ１１…１１のアプリケーション制御部に稼動状況の問合せ行うまで稼働状況の問合せを続行する。一方、各サーバ１１のアプリケーション制御部は、この稼働状況の問合せを受け付けると（ステップＳ５３）、自己の稼働状況を管理サーバ２０に送信する（ステップＳ５４）。ここで、各サーバ１１のアプリケーション制御部は、稼働状況として「実行可」又は「停止中」を送信する。管理サーバ２０は、各サーバ１１からの稼働状況を受信する（ステップＳ５５）と共に、その応答時間（ステップＳ５１の問合せからステップＳ５５の受信までの時間）に基いて各サーバ１１のアプリケーション制御部の稼働率を記録する（ステップＳ５６）。ただし、この稼働率の記録は、稼働状況として「実行可」が送信されてきた場合に限られる（つまりサーバ１１のアプリケーション制御部が停止中のときは稼働率は記録しない）。ここで、応答時間が短いほど（応答速度が速いほど）、サーバ１１のアプリケーション制御部の現在の処理能力に余裕があると判断され、稼働率は低い値に記録される。これにより、管理サーバ２０は、各サーバ１１の稼働率を検出することができる（請求項２の稼働率検出手段）。

図６に戻り、次いで、管理サーバ２０は、複数のサーバ１１…１１のうちから、前記ステップＳ５６で記録した稼働率が最も低いサーバ１１のアプリケーション制御部を選択する（ステップＳ３４）。つまり、現在最も処理能力に余裕がある稼働中のサーバ１１を選択するのである。ただし、ステップＳ３４では、既にバージョンアップが済んでいるサーバ１１を再びバージョンアップするというような無駄な動作を回避するために、既にバージョンアップが済んでいるサーバ１１を除いて稼働率が最低のサーバ１１を選択するようにする。

そして、管理サーバ２０は、その選択したサーバ１１のアプリケーション制御部に対し、停止命令を出力する（ステップＳ３５：図３の符号１参照）。一方、サーバ１１は、この停止命令を受けると、停止処理を実行し（ステップＳ３６：図３の符号２〜３参照：これ以降、負荷分散機１２からの稼働状況の問合せに対して「停止中」を送信し、負荷分散機１２からの新規の処理依頼を拒否することになる）、停止完了した旨を管理サーバ２０に送信する（ステップＳ３７：図３の符号４参照）。

管理サーバ２０は、前記停止完了を受信すると（ステップＳ３８）、選択したサーバ１１のアプリケーション制御部に対し、アプリケーションモジュールのバージョンアップ命令を出力する（ステップＳ３９：図３の符号５参照：請求項１及び請求項８のバージョンアップ手段）。サーバ１１は、このバージョンアップ命令を受けると、アプリケーションモジュールのバージョンアップ処理を実行し（ステップＳ４０）、モジュールパーミッションを変更したのち（ステップＳ４１）、バージョンアップ処理の結果（成功又は失敗）を管理サーバ２０に送信する（ステップＳ４２）。

管理サーバ２０は、前記バージョンアップ処理の結果を受信すると（ステップＳ４３）、前記バージョンアップ処理が成功したか否かを判定し（ステップＳ４４：請求項３の成否判定手段）、成功したと判定した場合は、管理サーバ２０は、選択したサーバ１１のアプリケーション制御部に対し、起動命令を出力する（ステップＳ４５）。サーバ１１は、この起動命令を受けると、起動処理を実行し（ステップＳ４６：これ以降、負荷分散機１２からの稼働状況の問合せに対して「実行可」を送信し、負荷分散機１２からの新規の処理依頼を受け入れることになる）、バージョンアップしたアプリケーションモジュールの稼動を開始する（ステップＳ４７）。

一方、管理サーバ２０は、起動命令を出力（ステップＳ４５）したのち、全てのサーバ１１…１１で、前記のようなサーバ１１の停止（ステップＳ３５〜Ｓ３８）及びバージョンアップ（ステップＳ３９〜Ｓ４７）という一連の作業を完了したか否かを判定し（ステップＳ４８）、全サーバ１１…１１で前記一連の作業を行うまで前記一連の作業を続行する（請求項１及び請求項８の制御手段）。

これに対し、管理サーバ２０は、前記バージョンアップ処理が成功したか否かを判定（ステップＳ４４：請求項３の成否判定手段）した結果、失敗したと判定した場合は、選択したサーバ１１のアプリケーション制御部に対し、アプリケーションモジュールの現行バージョンを送信して（ステップＳ３２でバックアップしておいたもの）、モジュールの復帰命令を出力する（ステップＳ６１：請求項３の復帰手段）。サーバ１１は、このモジュール復帰命令を受けると、アプリケーションモジュールの現行バージョンへの復帰処理を実行し（ステップＳ６２）、復帰処理が完了した旨を管理サーバ２０に送信する（ステップＳ６３）。

管理サーバ２０は、前記復帰処理の完了通知を受信すると（ステップＳ６４）、選択したサーバ１１のアプリケーション制御部に対し、起動命令を出力する（ステップＳ６５）。サーバ１１は、この起動命令を受けると、起動処理を実行し（ステップＳ６６：これ以降、負荷分散機１２からの稼働状況の問合せに対して「実行可」を送信し、負荷分散機１２からの新規の処理依頼を受け入れることになる）、復帰した現行バージョンのアプリケーションモジュールの稼動を開始する（ステップＳ６７）。

さらに、図７のステップＳ４８でＹＥＳの場合は、引き続き、図１０のステップＳ７１に進んで、管理サーバ２０のアプリケーションサーバ管理部２１は、サーバ１１に格納されているアプリケーションモジュールのバージョンアップに伴い、クライアント１３に格納されているクライアントモジュールのバージョンアップが必要か否かを判定し（請求項４の要否判定手段）、必要と判定した場合は、管理サーバ２０のクライアント管理部２２に対し、クライアントモジュールの新バージョンを移設して、クライアントモジュールのバージョンアップ命令を出力する（ステップＳ７２）。クライアント管理部２２は、このバージョンアップ命令を受けると、クライアントモジュールの新バージョンを格納する（ステップＳ７３）。そして、サーバ１１…１１のバージョンアップが完了したのち（ステップＳ４８でＹＥＳ）、処理要求をしてきた各クライアント１３は、そのクライアント１３に格納されているクライアントモジュールを順次バージョンアップしていく（ステップＳ７４：請求項４の第２のバージョンアップ手段）。

以上のように、本実施形態によれば、複数のサーバ１１…１１と、クライアント１３…１３からの処理要求による負荷を稼動中のサーバ１１…１１間で分散させる負荷分散機１２とを有する情報処理システム１０に用いられるバージョンアップ装置（管理サーバ）２０において、受付手段（ステップＳ３１）とバージョンアップ手段（ステップＳ３９）とが備えられ、前記サーバ１１に格納されているソフトウエア（アプリケーションモジュール）のバージョンアップ指令（図１参照）が前記情報処理システム１０の外部から入力されて、これを受付手段（ステップＳ３１）が受け付けたとき、バージョンアップ手段（ステップＳ３９）が複数のサーバ１１…１１のうちの所定のサーバ１１を停止させるから、負荷分散機１２は、このバージョンアップ手段（ステップＳ３９）によって停止されたサーバ１１、つまり稼動中でないサーバ１１に対しては処理要求を依頼することがなくなり、この停止中のサーバ１１を除く他の稼動中のサーバ１１…１１間で負荷分散を図ることになる。

そして、バージョンアップ手段（ステップＳ３９）は、停止させたサーバ１１に格納されているソフトウエアをバージョンアップするので、このようなサーバ１１の停止及びバージョンアップという一連の作業により、複数のサーバ１１…１１のうちの所定のサーバ１１についてのバージョンアップが完了することになる。

そして、制御手段（ステップＳ３５〜Ｓ４８）が、このようなバージョンアップ手段（ステップＳ３９）によるサーバ１１の停止及びバージョンアップという一連の作業を各サーバ１１…１１について順次行うことにより、全てのサーバ１１…１１に格納されているソフトウエアをバージョンアップするから、結局、システム全体として見たときには、従来のように稼働系と待機系とを切り替える、というようなことをせずに済み、複数のサーバ１１…１１のうちの所定のサーバ１１のみが一時的に停止するだけで、他の複数のサーバ１１…１１は稼動中のままであるから、システム全体としては停止することがない。その結果、クライアント１３からの処理要求がシステム１０のバージョンアップ中も常時受け付け可能であって、情報処理システム１０の営業中における安定な連続運転が達成される。

しかも、このように稼働系と待機系との切替えを行わないから、サービスに必要な各種データを稼働系から待機系へ引き継ぐ作業を行わずに済み、そのためのソフトウエアを別途準備する必要がなくなる。

また、バージョンアップ装置２０に、各サーバ１１…１１の稼働率を検出する稼働率検出手段（ステップＳ５６）が備えられ、バージョンアップ手段（ステップＳ３９）は、この稼働率検出手段（ステップＳ５６）で検出された稼働率が最も低いサーバ１１、換言すれば、負荷が最も少ないサーバ１１（処理能力の余裕度が最も高いサーバ１１）を停止させるから、システム全体としての処理の高速化を大きく減損することなく、複数のサーバ１１…１１を順次バージョンアップしていくことが可能となる。

しかも、既にバージョンアップが済んでいるサーバ１１を除いて稼働率が最低のサーバ１１を停止させるから（ステップＳ３４）、既にバージョンアップが済んでいるサーバ１１を再びバージョンアップするというような無駄が生じない。

なお、各サーバの稼働率は、システム外部からのバージョンアップ指令（図１参照）が受け付けられたときに検出する他、定期的に検出するようにしてもよい。

また、バージョンアップ装置２０にバックアップ手段（ステップＳ３２）が備えられ、このバックアップ手段（ステップＳ３２）は、システム外部からのバージョンアップ指令が受け付けられたとき、前記バージョンアップ手段（ステップＳ３９）により所定のサーバ１１が停止される前に、サーバ１１に現在格納されているソフトウエアの現行バージョンをバックアップするから、前記バージョンアップ手段（ステップＳ３９）によるバージョンアップが開始される前にソフトウエアの現行バージョンがバージョンアップ装置２０に保存されることになる。

そして、前記バージョンアップ手段（ステップＳ３９）によるバージョンアップが失敗したと判定されたとき（ステップＳ４４）は、復帰手段（ステップＳ６１）が、停止されたサーバ１１に格納されているソフトウエアを前記バックアップ手段（ステップＳ３２）でバックアップした現行バージョンに復帰させるから、たとえバージョンアップがうまくいかなかった場合でも、サーバ１１を元のバージョンのソフトウエアで再び稼動させることができ、その結果、サーバ１１の停止時間が徒に長引くことが回避されて、稼動中のサーバ１１…１１の数が減少している時間、つまりシステム全体としての処理の高速化が減損している時間の短縮化が図られることになる。

また、バージョンアップ装置２０に要否判定手段（ステップＳ７１）が備えられ、この要否判定手段（ステップＳ７１）により、サーバ１１…１１側のバージョンアップに伴い、クライアント１３…１３に格納されているソフトウエア（クライアントモジュール）のバージョンアップが必要と判定されたときは（このことから、サーバ１１…１１側がバージョンアップされたからといってクライアント１３…１３側を常にバージョンアップするとは限らないことが判る。ただし、サーバ１１…１１側がバージョンアップされていないのにクライアント１３…１３側だけバージョンアップすることはない）、第２のバージョンアップ手段（ステップＳ７４）が、サーバ１１…１１側のバージョンアップが完了したのち処理要求をしてきた各クライアント１３…１３についてそのクライアント１３に格納されているソフトウエアを順次バージョンアップしていくから、サーバ１１側とクライアント１３側とで共に全機器がバージョンアップされ、その結果、クライアント１３を用いて情報処理システム１０が提供するサービスを利用する者が、セキュリティの向上やバグの修正等のための機能の改善や追加の効果を満足に享受することが可能となる。

また、負荷分散機１３に、複数のサーバ１１…１１のうちのいずれのサーバ１１が停止しているかを検出する停止検出手段（ステップＳ２５）が備えられたから、負荷分散機１３は、複数のサーバ１１…１１のうちのいずれのサーバ１１が停止中であるかの情報、換言すれば、クライアント１３からの処理要求をいずれのサーバ１１に依頼できるかの情報を自ら収集することができる。

なお、停止中のサーバ１１は、クライアント１３から新たな処理要求があったときに検出する他、定期的に検出するようにしてもよい。

なお、前記実施形態は、本発明の最良の実施形態であるが、特許請求の範囲を逸脱しない限り、さらに種々の変更や改良を加えることができる。例えば、バージョンアップ装置２０に、複数のサーバ１１…１１のうちのいずれのサーバ１１を停止させたかを負荷分散機１２に通知する通知手段を備えるようにしてもよい。これにより、負荷分散機１２は、複数のサーバ１１…１１のうちのいずれのサーバ１１が停止中であるかの情報、換言すれば、クライアント１３からの処理要求をいずれのサーバ１１に依頼できるかの情報を自ら収集する必要がなくなる。

以上、具体例を挙げて詳しく説明したように、本発明は、システム全体としての処理の高速化を図るために、複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムをバージョンアップする際に、システムを停止させることなく、かつ、データの引き継ぎ作業を行うことなく、システムをバージョンアップすることが可能な技術であるから、コンピュータを用いた情報処理の技術分野、特に、システムのバージョンアップが頻繁に行われるクライアントサーバシステムの技術分野において広範な産業上の利用可能性が期待される。

本発明の最良の実施の形態に係る情報処理システムの構成図である。 前記情報処理システムの通常稼動時における主な信号の流れを示す機能ブロック図である。 前記情報処理システムのバージョンアップ時における主な信号の流れを示す機能ブロック図である。 前記情報処理システムの通常稼動時における負荷分散機及びアプリケーションサーバの具体的動作の１例を示すフローチャートである。 図４のステップＳ１２のサブルーチンを示すフローチャートである。 前記情報処理システムのバージョンアップ時における管理サーバ及びアプリケーションサーバの具体的動作の１例の前半部分を示すフローチャートである。 同、後半部分を示すフローチャートである。 図６のステップＳ３３のサブルーチンを示すフローチャートである。 図７のステップＳ４４でＮＯの場合における管理サーバ及びアプリケーションサーバの具体的動作の１例を示すフローチャートである。 図７のステップＳ４８でＹＥＳの場合に引き続き行われる管理サーバのアプリケーションサーバ管理部及びクライアント管理部並びにクライアントコンピュータの具体的動作の１例を示すフローチャートである。

符号の説明

１０ 情報処理システム
１１ アプリケーションサーバ
１２ 負荷分散機
１３ クライアントコンピュータ
１４ 専用回線
２０ 管理サーバ（バージョンアップ装置）
２１ アプリケーションサーバ管理部
２２ クライアント管理部

Claims (8)

1. 複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムに用いられるバージョンアップ装置であって、
   前記情報処理システムの外部から入力される、前記サーバに格納されているソフトウエアのバージョンアップ指令を受け付ける受付手段と、
   この受付手段で前記バージョンアップ指令を受け付けたとき、複数のサーバのうちの所定のサーバを停止させ、そのサーバに格納されているソフトウエアをバージョンアップするバージョンアップ手段と、
   このバージョンアップ手段によるサーバの停止及びバージョンアップの作業を各サーバについて順次行うことにより、全てのサーバに格納されているソフトウエアをバージョンアップする制御手段とを備えていることを特徴とする情報処理システムに用いられるバージョンアップ装置。
2. 請求項１に記載の情報処理システムに用いられるバージョンアップ装置であって、
   各サーバの稼働率を検出する稼働率検出手段を備え、
   前記バージョンアップ手段は、既にバージョンアップが済んでいるサーバを除き、この稼働率検出手段で検出された稼働率が最も低いサーバを停止させることを特徴とする情報処理システムに用いられるバージョンアップ装置。
3. 請求項１又は２に記載の情報処理システムに用いられるバージョンアップ装置であって、
   前記受付手段で前記バージョンアップ指令を受け付けたとき、前記バージョンアップ手段が所定のサーバを停止させる前に、サーバに現在格納されているソフトウエアの現行バージョンをバックアップするバックアップ手段と、
   前記バージョンアップ手段によるバージョンアップが成功したか否かを判定する成否判定手段と、
   この成否判定手段でバージョンアップが失敗したと判定したとき、前記サーバに格納されているソフトウエアを前記バックアップ手段でバックアップした現行バージョンに復帰させる復帰手段とを備えていることを特徴とする情報処理システムに用いられるバージョンアップ装置。
4. 請求項１から３のいずれかに記載の情報処理システムに用いられるバージョンアップ装置であって、
   サーバに格納されているソフトウエアのバージョンアップに伴い、クライアントに格納されているソフトウエアのバージョンアップが必要か否かを判定する要否判定手段と、
   この要否判定手段でバージョンアップが必要と判定したとき、サーバ側のバージョンアップが完了したのち処理要求をしてきた各クライアントについてそのクライアントに格納されているソフトウエアを順次バージョンアップしていく第２のバージョンアップ手段とを備えていることを特徴とする情報処理システムに用いられるバージョンアップ装置。
5. 複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムであって、
   請求項１から４のいずれかに記載のバージョンアップ装置を備えていることを特徴とする情報処理システム。
6. 請求項５に記載の情報処理システムであって、
   前記負荷分散機は、複数のサーバのうちのいずれのサーバが停止しているかを検出する停止検出手段を備えていることを特徴とする情報処理システム。
7. 請求項５に記載の情報処理システムであって、
   前記バージョンアップ装置は、複数のサーバのうちのいずれのサーバを停止させたかを前記負荷分散機に通知する通知手段を備えていることを特徴とする情報処理システム。
8. 複数のサーバと、クライアントからの処理要求による負荷を稼動中のサーバ間で分散させる負荷分散機とを有する情報処理システムをバージョンアップするためのプログラムであって、
   コンピュータを、
   前記情報処理システムの外部から入力される、前記サーバに格納されているソフトウエアのバージョンアップ指令を受け付ける受付手段、
   この受付手段で前記バージョンアップ指令を受け付けたとき、複数のサーバのうちの所定のサーバを停止させ、そのサーバに格納されているソフトウエアをバージョンアップするバージョンアップ手段、及び、
   このバージョンアップ手段によるサーバの停止及びバージョンアップの作業を各サーバについて順次行うことにより、全てのサーバに格納されているソフトウエアをバージョンアップする制御手段として機能させることを特徴とする情報処理システムをバージョンアップするためのプログラム。

Images