(57)【要約】【課題】サービスを停止することなく、クラスタソフトウェアをアップグレードする。【解決手段】少なくとも１つのクラスタ制御部を稼動させた状態で残りのクラスタ制御部を停止させ（ステップＳ１６）、停止させたクラスタ制御部のソフトウェアをアップグレードし（ステップＳ１８）、この停止させアップグレードするクラスタ制御部を順次変更する（ステップＳ２４）ことにより、クラスタ制御部を順次アップグレードする。【選択図】      図３
2005085114.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンピュータから構成されるクラスタシステムであって、
前記クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作し、クライアント端末から要求されたサービスを提供するためのサービス制御を行う複数のエージェントと、
前記クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作するクラスタ制御部であって、他のクラスタ制御部と通信を行いながら同期して前記エージェントを制御することにより、他のクラスタ制御部と一体となって１つのカーネルとして一貫性のあるクラスタ制御を行う複数のクラスタ制御部と、
少なくとも１つのクラスタ制御部を稼動させた状態で残りのクラスタ制御部を停止させ、停止させたクラスタ制御部のソフトウェアをアップグレードし、この停止させアップグレードするクラスタ制御部を順次変更することにより、クラスタ制御部を順次アップグレードする手段と、
を具備するクラスタシステム。
【請求項２】
前記複数のコンピュータはそれぞれエージェントとクラスタ制御部を具備し、
前記複数のエージェントは複数のサービスをそれぞれ制御し、
前記アップグレード手段は一部づつのクラスタ制御部を停止させ、クラスタ制御部を一部づつアップグレードすることを特徴とする請求項１記載のクラスタシステム。
【請求項３】
前記複数のコンピュータはエージェントを具備しクラスタ制御部は具備しない第１のコンピュータと、クラスタ制御部を具備しエージェントは具備しない第２のコンピュータとを具備し、
前記複数のエージェントはサービスを制御する第１のエージェントと、サービスを制御しないスタンバイ状態の第２のエージェントとを具備し、
前記アップグレード手段は一部づつのクラスタ制御部を停止させ、クラスタ制御部を一部づつアップグレードすることを特徴とする請求項１記載のクラスタシステム。
【請求項４】
前記複数のコンピュータはエージェントを具備しクラスタ制御部は具備しない第１のコンピュータと、クラスタ制御部を具備しエージェントは具備しない第２のコンピュータとを具備し、
前記複数のエージェントは複数のサービスをそれぞれ制御し、
前記アップグレード手段は一部づつのクラスタ制御部を停止させ、クラスタ制御部を一部づつアップグレードすることを特徴とする請求項１記載のクラスタシステム。
【請求項５】
前記各コンピュータ上では、前記クラスタ制御部及びエージェントのいずれか一方のみが動作することを特徴とする請求項１記載のクラスタシステム。
【請求項６】
前記複数のエージェントの各々は、クラスタ制御部との通信を切換えいずれかのクラスタ制御部と通信するための通信経路切換制御部と、他エージェントとのハートビートの途絶を検出するためのハートビート送信部と、サービスの実行制御を行うサービス制御部とを具備する請求項１記載のクラスタシステム。
【請求項７】
複数のコンピュータから構成されるクラスタシステムであって、
前記クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作し、クライアント端末から要求されたサービスを提供するためのサービス制御を行う複数のエージェントと、
前記クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作するクラスタ制御部であって、他のクラスタ制御部と通信を行いながら同期して前記エージェントを制御することにより、他のクラスタ制御部と一体となって１つのカーネルとして一貫性のあるクラスタ制御を行う複数のクラスタ制御部とを具備するクラスタシステムのアップグレード方法において、
少なくとも１つのクラスタ制御部を稼動させた状態で残りのクラスタ制御部を停止させ、停止させたクラスタ制御部のソフトウェアをアップグレードし、この停止させアップグレードするクラスタ制御部を順次変更することにより、クラスタ制御部を順次アップグレードすることを特徴とするクラスタシステムのアップグレード方法。
【請求項８】
複数のコンピュータから構成されるクラスタシステムであって、
前記クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作し、クライアント端末から要求されたサービスを提供するためのサービス制御を行う複数のエージェントと、
前記クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作するクラスタ制御部であって、他のクラスタ制御部と通信を行いながら同期して前記エージェントを制御することにより、他のクラスタ制御部と一体となって１つのカーネルとして一貫性のあるクラスタ制御を行う複数のクラスタ制御部とを具備するクラスタシステムのプログラムにおいて、
コンピュータに少なくとも１つのクラスタ制御部を稼動させた状態で残りのクラスタ制御部を停止させ、停止させたクラスタ制御部のソフトウェアをアップグレードし、この停止させアップグレードするクラスタ制御部を順次変更することにより、クラスタ制御部を順次アップグレードさせるクラスタシステムのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンピュータから構成されるクラスタシステムに係り、特にクラスタ制御を実行するクラスタ制御部と、当該クラスタ制御部とは独立して設けられ、複数のクラスタ制御部が同期して動作することにより実現される仮想マシンとしてのカーネルの制御によって動作するエージェントとからなるクラスタシステム、アップグレード方法及びプログラムに関する。
【背景技術】
【０００２】
近年、コンピュータ上でアプリケーションプログラムを実行することにより、ユーザ（クライアント端末）にサービス（業務）を提供するシステムが運用されている。この種のシステムでは、継続したサービスの提供が必須になっている。これに伴い、サービスを実行しているコンピュータ（サーバコンピュータ）にも高い可用性（サーバ稼働率、業務稼働率）が求められる。そこで、複数のコンピュータをクラスタ構成として、一部のコンピュータで障害が発生しても、別のコンピュータでサービスを引き継いで、システム全体が停止するのを防止する、いわゆるクラスタシステムが開発されている（例えば、非特許文献１参照）。
【０００３】
クラスタシステムを構成するには、各コンピュータ上にクラスタマネージャが必要となる。クラスタマネージャは、クラスタの制御と、アプリケーションを起動・停止する制御（サービス制御）とを実行する。クラスタシステムでは、複数のコンピュータ（ノード）で分散してクラスタマネージャによるクラスタ制御が行われる。ここでは、クラスタ全体としての視点でクラスタ制御が行われること、つまり各コンピュータで分散して行われるクラスタ制御が、全体として一貫性のある制御となっていることが必要となる。そこでクラスタシステムでは、各コンピュータでのクラスタ制御が、互いに通信を行いながら同期して（連携して）行われる。つまり、クラスタ制御が各コンピュータで多重化して行われる。これにより高可用性（高業務稼働率）(High Availability、以下ＨＡと略称する）が実現される。
【０００４】
従来、クラスタ構成で運用されているシステムでクラスタソフトウェアをアップグレードする必要がある場合、クラスタ制御下で稼動しているサービスの停止が必要であった。これは、クラスタシステムを構成、制御しているクラスタ制御部とエージェントとが密に連携しているため、クラスタソフトウェアのアップグレードを行うためには、クラスタソフトウェアの停止が必要となり、これに伴い、稼動しているサービスの停止が必要となるためである。具体的にはアップグレードは、（１）稼動系サービスの停止、（２）稼動系、待機系のクラスタソフトウェアの停止処理、（３）クラスタソフトウェアのアップグレード、（４）クラスタソフトウェアの開始、（５）サービスの起動（サービスの自動開始も含む）の処理により行われる。
【０００５】
近年、サービス停止時間を短くするための提案がなされている（例えば、特許文献１参照）。ここで提案されているアップグレードは、（１）稼動系サービスの停止、（２）待機系でサービスの開始（スイッチオーバ、あるいはフェイルオーバ処理）、（３）稼動系クラスタウェアの停止処理、（４）稼動系のクラスタウェアのアップグレード、（５）稼動系のクラスタソフトウェアの開始（待機系サービスの停止）、（６）稼動系でサービスの開始（スイッチバック、あるいはフェイルバック処理）、（７）待機系のクラスタソフトウェアの停止処理、（８）待機系のクラスタソフトウェアウェアのアップグレード、（９）待機系のクラスタソフトウェアの開始の処理により行われる。
【０００６】
この場合は、サービスの停止時間は（１）から（２）までの期間と、（５）から（６）までの期間であり、僅かな時間ではあるが
一時的にせよサービスが停止する。
【０００７】
なお、サービスを稼動系から待機系へスイッチオーバ／スイッチバックしなければならない理由は、クラスタソフトウェアの障害検出機構によるものである。従来、クラスタソフトウェアは他系の障害を検出するための機構としてハートビートによる障害検出を行っている。他系からのハートビートの途絶を検出することによって、他系で障害が発生したものと判断し、サービスを稼動系から待機系へスイッチオーバすることによって、サービスの可用性を高めている。
【０００８】
サービスを待機系にスイッチオーバを行わずに、稼動系のクラスタソフトウェアを停止した場合、待機系でハートビートの途絶を誤検出し、テイクオーバが発生することによって、両系でサービスの２重起動が生じる。このような状況を発生させないために、サービスを稼動系から待機系へスイッチオーバしている。
【特許文献１】特開２００１−６７３３１（段落０００５）
【非特許文献１】金子哲夫、森良哉、「クラスタソフトウェア」、東芝レビュー、Vol.54 No.12(1999)、p.18-21
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上記したように従来のクラスタシステムでは、クラスタソフトウェアをアップグレードする必要がある場合、クラスタ制御下で稼動しているサービスの停止が必要であった。
【００１０】
本発明は上記事情を考慮してなされたものでその目的は、短時間のサービス停止でクラスタソフトウェアをアップグレードすることができるクラスタシステム、アップグレード方法及びプログラムを提供することである。
【課題を解決するための手段】
【００１１】
本発明の１つの観点によれば、複数のコンピュータから構成されるクラスタシステムが提供される。クラスタシステムは、クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作し、クライアント端末から要求されたサービスを提供するためのサービス制御を行う複数のエージェントと、クラスタシステムを構成する複数のコンピュータのうちの少なくとも一部のコンピュータ上で独立して動作するクラスタ制御部であって、他のクラスタ制御部と通信を行いながら同期してエージェントを制御することにより、他のクラスタ制御部と一体となって１つのカーネルとして一貫性のあるクラスタ制御を行う複数のクラスタ制御部とを具備し、少なくとも１つのクラスタ制御部を稼動させた状態で残りのクラスタ制御部を停止させ、停止させたクラスタ制御部のソフトウェアをアップグレードし、この停止させアップグレードするクラスタ制御部を順次変更することにより、クラスタ制御部を順次アップグレードするものである。
【発明の効果】
【００１２】
本発明によれば、サービス制御とクラスタ制御とがそれぞれ独立のエージェントとクラスタ制御部によって行われているので、クラスタソフトウェアのアップグレード時にはクラスタ制御部のみを停止させればよい。このようにエージェントは停止しないので、サービスを継続して提供することができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１４】
［第１の実施の形態］
図１は本発明の第１の実施の形態に係るクラスタシステムの構成を示すブロック図である。図１のクラスタシステムは、複数台の、例えば４台のサーバコンピュータ１０-1（＃１），１０-2（＃２），１０-3（＃３），１０-4（＃４）から構成される。サーバコンピュータ１０-1，１０-2，１０-3，１０-4は２つのネットワーク２１，２２により相互接続されている。
【００１５】
サーバコンピュータ１０-1，１０-2，１０-3，１０-4上では、クラスタ制御を行うクラスタ制御部１１-1（＃１），１１-2（＃２），１１-3（＃３），１１-4（＃４）が動作する。クラスタ制御部１１-1〜１１-4は、サーバコンピュータ１０-1〜１０-4が、対応するサーバプログラム（クラスタ制御のためのクラスタ制御部プログラム）を実行することにより実現される。
【００１６】
また、サーバコンピュータ１０-1〜１０-4のうちのサーバコンピュータ１０-2，１０-3上では、サービス制御（つまりアプリケーションを起動・停止する制御）を行うエージェント１２-1（＃１），１２-2（＃２）が動作する。エージェント１２-1，１２-2は、サーバコンピュータ１０-2，１２-3が、対応するサーバプログラム（サービス制御のためのエージェントプログラム）を実行することにより実現される。
【００１７】
エージェント１２-1，１２-2の各々は、通信経路切換制御部１２２、ハートビート送信部１２４、サービス制御部１２６からなり、サーバコンピュータ固有の制御を司る。通信経路切換制御部１２２は、任意のクラスタ制御部１１-1〜１１-4との通信を切換えるための制御部である。ハートビート送信部１２４は、他エージェントとのハートビート途絶を検出するための制御部である。サービス制御部１２６は、サービス１２８の実行制御を行う制御部である。
【００１８】
ネットワーク２２には、エージェント１２-1，１２-2に対してサービスの実行を要求するクライアント端末２３が接続されている。エージェント１２-1，１２-2とクライアント端末２３との間の通信は、ネットワーク２２を介して行われる。なお、図１では、作図の都合上、ネットワーク２２に１つのクライアント端末２３が接続されている例が示されている。しかし、ネットワーク２２には、複数のクライアント端末が接続されるのが一般的である。
【００１９】
サーバコンピュータ１０-1〜１０-4上の各クラスタ制御部１１-1〜１１-4は、従来のクラスタシステムにおける各コンピュータ上で動作するクラスタマネージャのクラスタ制御機能と同様のクラスタ制御機能を有し、他のクラスタ制御部と一体となって（多重化して動作して）、クラスタシステムの制御を実行する。クラスタ制御部１１-1〜１１-4は、サービスの開始要求、停止要求、スイッチオーバ処理、優先度に従ったテイクオーバ処理などのクラスタ全体の制御を司る。一体となったクラスタ制御部１１-1〜１１-4は、カーネル１１０と呼ぶ１つのバーチャルマシン（仮想的な実行環境）を形成する。カーネル１１０は、個々のサーバコンピュータ１０-1〜１０-4上で動作するクラスタ制御部１１-1〜１１-4が連携して形成される。このためカーネル１１０は、サーバコンピュータ１０-1〜１０-4にまたがって存在していると考えることができる。つまり、個々のクラスタ制御部１１-1〜１１-4がカーネルなのではなく、クラスタ制御部１１-1〜１１-4が一体となってカーネル１１０が構築され、よってクラスタシステムにはひとつだけカーネルが存在する。
【００２０】
クラスタ制御部１１-1〜１１-4が一体となって同期（連携）して動作する（つまり多重化して動作する）のに必要な、クラスタ制御部１１-1〜１１-4間の通信には、ネットワーク２１が用いられる。ここで、ネットワーク２１には、上記多重化動作の高速化のために、エージェント１２-1，１２-2とクライアント端末２３との間の通信に用いられるネットワーク２２よりも高速のネットワークが用いられる。なお、高速化が要求されない場合には、クラスタ制御部１１-1〜１１-4間の通信にもネットワーク２２を用いても構わない。
【００２１】
サーバコンピュータ１０-2，１０-3上のエージェント１２-1，１２-2は、カーネル１１０からの制御に従って動作し、サービス（アプリケーション）１２８の起動・停止を制御する。つまり、エージェント１２-1，１２-2ではサービス１２８が実行される。このサービス１２８について、ウェブサービスを例に説明する。まずウェブサービスを実行するには、当該サービスに対するクライアント端末２３からのリクエストに応答してコンテンツを配信する役割を持つウェブサーバが必要である。またクライアント端末からウェブサーバにリクエストを届けるためにはアドレス、例えばＩＰ（Internet Protocol）アドレスが必要である。提供されるコンテンツを保存するためのファイルシステムも必要である。つまりウェブサービスの提供には、ウェブサーバ、ＩＰアドレス、ファイルシステムなどの、物理的、もしくは論理的な実体が必要となる。これらの実体は、「リソース」と呼ばれる。つまり、エージェント１２-1，１２-2では、それぞれ複数のリソースを組み合わせて実行することにより、結果としてサービスが実行される。エージェント１２-1，１２-2はリソースの起動・停止を実際に行う手段である。エージェント１２０-1，１２０-2は、カーネル１１０から制御の指示を受け取り、それに従ってリソースを制御し、結果をカーネル１１０に返す。
【００２２】
このように、図１のクラスタシステムには２台のエージェント１２-1，１２-2が存在し、それぞれが独立して稼働する。このため、カーネル１１０が、エージェント１２-1，１２-2をいかに制御し、同期をとるかという点が重要である。そこで本実施の形態では、クラスタシステムの制御がカーネル１１０によって一元的に行われる構成を適用している。カーネル１１０は、クラスタ制御部１１-1〜１１-4で多重化実行されるバーチャルマシンである。このため、一部のクラスタ制御部１１-1〜１１-4に障害が発生した場合でも、クラスタシステムの制御を継続することが可能である。しかも、サーバコンピュータ（クラスタソフトウェア）をそれぞれ独立して動作するクラスタ制御部１１とエージェント１２に分離することにより、クラスタ制御部１１のソフトウェアをアップブレードする場合、サービス１２８を停止することなくアップグレードが可能となる。これにより、クライアント端末２３に対する継続したサービス提供が可能となる。
【００２３】
クラスタ制御部１１-1〜１１-4における多重化実行のアルゴリズムには、前記特許文献１に記載されているスプリットブレインを起こさない２／３定足数アルゴリズムが適用される。本実施の形態のクラスタシステムは、ｎ＝４，ｆ＝１であり、２／３定足数アルゴリズムが適用可能な最も少ない数のコンピュータで構成される。つまり、本実施の形態のクラスタシステムは２／３定足数アルゴリズムが適用可能な最小クラスタ構成をとる。これにより、ｆ（＝１）台のクラスタ制御部の停止障害だけでなく、ビザンティン故障にも耐障害性を実現できる。このように、カーネル１１０は、超高信頼なバーチャルマシンとなっており、信頼性の高いクラスタシステムの制御を実現する。
【００２４】
さて本実施の形態では、クラスタシステム内の全てのサーバコンピュータ、つまり４台のサーバコンピュータ１０-1〜１０-4上でクラスタ制御部１１-1〜１１-4が稼働させられて、カーネル１１０が実現される。これにより上記したように、２／３定足数アルゴリズムを適用するのに必要な最少のコンピュータ数（ｎ＝４）でクラスタシステムが構築される。また、この４台のサーバコンピュータ１０-1〜１０-4のうちの２台のサーバコンピュータ１０-2，１０-3上でエージェント１２-1，１２-2が稼働させられて、クラスタシステムのサービスが実行される。このため、サーバコンピュータ１０-2，１０-3には、それぞれそのサービスに必要なリソースと、それに見合ったハードウェア／ソフトウェアが必要になるものの、サーバコンピュータ１０-1，１０-4ではクラスタ制御部１１-1，１１-2しか動作しないため、当該サーバコンピュータ１０-1，１０-4は比較的小さなコンピュータで十分である。
【００２５】
以上のことから、図１のクラスタシステムでは、サービス制御に関しては、２つのエージェント１２-1，１２-2間でのフェイルオーバによる可用性の向上が期待できる。一方、クラスタ制御に関しては、４つのクラスタ制御部１１-1〜１１-4による２／３定足数アルゴリズムによる可用性の向上が期待できる。
【００２６】
次に、本実施形態におけるソフトウェアのアップグレードについて説明する。前述したように、クラスタソフトウェアをクラスタ制御部１１とエージェント１２とに分離し、それぞれ独立して動作させることにより、クラスタ制御部１１のアップブレードを行う場合、エージェント１２が提供するサービス１２８を停止することなく、アップグレードが可能となる。これにより、クライアント２３に対する継続したサービス１２８の提供が可能となる。なお、エージェント１２のアップグレードに関しては、エージェント１２がサービス１２８の提供を制御しているために、サービスのスイッチオーバにより稼動系と待機計を切換えることは、従来方式と同様である。
【００２７】
以下、提供するサービスの具体例（クラスタシステムの構成例）に応じたアップグレードの例を説明する。
【００２８】
図２は同一マシン（サーバコンピュータ）１０内にクラスタ制御部１１、エージェント１２があり、複数マシンで１つ以上のサービスが稼動している場合を示す。クラスタ制御部１１-1〜１１-Nは連携して、サービス１２８-1〜１２８-Nを制御している。なお、サービスの数とクラスタ制御部の数は一致していなくてもよい。
【００２９】
この場合のアップグレードの手順を図３のフローチャートに示す。ステップＳ１２に示すように、サーバ１０-1〜１０-Nで１つ以上のサービス１２８-1〜１２８-Nを実施している。ステップＳ１４で変数ｉに１をセットする。ステップＳ１６で、サーバ１０-iのクラスタ制御部１１-iを停止する。他のクラスタ制御部は稼動を続ける。ステップＳ１８で、この停止中のクラスタ制御部１１-iのクラスタソフトウェアをアップグレードする。ステップＳ２０で、このアップグレードしたクラスタ制御部１１-iを再起動する。ステップＳ２２で、全てのクラスタ制御部１１のアップグレードが終了したか否かを判定する。否の場合は、ステップＳ２４で変数ｉを１だけ増加してステップＳ１６からの処理を次のｉ（＋１されたｉ）に対して再び実行する。
【００３０】
このようにして、クラスタシステムを構成するサーバコンピュータ１０-1〜１０-Nのクラスタ制御部１１-1〜１１-Nを１つづつアップグレードすることにより、エージェント１２-1〜１２-Nで稼動中のサービス１２８-1〜１２８-Nを停止することなく、クラスタソフトウェアをアップグレードすることが可能となる。また、クラスタソフトウェアのアップグレード中も他のクラスタ制御部１１-1〜１１-Nは稼動しているので、サービス１２８-1〜１２８-Nに障害が発生した場合でも、他サーバ（クラスタ制御部）へのテイクオーバが可能であり、サービスが停止することが防止される。なお、図３のフローチャートではアックグレードするために停止するクラスタ制御部１１は１台づつとしたが、アップグレード中に少なくとも１台のクラスタ制御部が稼動していればよく、複数台づつ纏めてアップグレードしてもよい。
【００３１】
図４はクラスタ制御部１１、エージェント１２が別々のマシン（サーバコンピュータ）１０-1〜１０-4内にあり、１つのマシン１０-1で１つのサービス１２８のみが稼動している（他のマシン１０-2はサービス１２８を稼動していない）場合を示す。クラスタ制御部１１-1〜１１-2は連携して、１つのサービス１２８を制御している。
【００３２】
この場合のアップグレードの手順を図５のフローチャートに示す。ステップＳ３２に示すように、マシン１０-1でサービス１２８-1を実施している。ステップＳ３４で、マシン１０-3のクラスタ制御部１１-1を停止する。他のクラスタ制御部１１-2は稼動を続ける。ステップＳ３６で、この停止中のクラスタ制御部１１-1のクラスタソフトウェアをアップグレードする。ステップＳ３８で、このアップグレードしたクラスタ制御部１１-1を再起動する。次に、ステップＳ３４０で、マシン１０-4のクラスタ制御部１１-2を停止する。クラスタ制御部１１-1は稼動を続ける。ステップＳ４２で、この停止中のクラスタ制御部１１-2のクラスタソフトウェアをアップグレードする。ステップＳ４４で、このアップグレードしたクラスタ制御部１１-2を再起動する。
【００３３】
このようにして、クラスタシステムを構成するクラスタ制御部１１-1〜１１-2を１つづつアップグレードすることにより、エージェント１２-1で稼動中のサービス１２８-1を停止することなく、クラスタソフトウェアをアップグレードすることが可能となる。また、クラスタソフトウェアのアップグレード中も他のクラスタ制御部は稼動しているので、サービス１２８に障害が発生した場合でも、他サーバ（クラスタ制御部）へのテイクオーバが可能であり、サービスが停止することが防止される。さらに、エージェント１２-2はサービス１２８-1に対してホットスタンバイ状態で待機しているので、エージェント１２-1に障害が発生した場合でも、直ちにエージェントを切換えることができ、可用性を高めることができる。
【００３４】
図５はクラスタ制御部１１、エージェント１２が別々のマシン（サーバコンピュータ）１０内にあり、複数マシンで１つ以上のサービスが稼動している場合を示す。クラスタ制御部１１-(N+1)〜１１-(N+M)は連携して、サービス１２８-1〜１２８-Nを制御している。ＮとＭとは同じでも異なっていてもよい。
【００３５】
この場合のアップグレードの手順を図６のフローチャートに示す。ステップＳ６２に示すように、マシン１０-(N+1)〜１０-(N+M)で１つ以上のサービス１２８-1〜１２８-Nを実施している。ステップＳ６４で変数ｉに１をセットする。ステップＳ６６で、マシン１０-(N+i)のクラスタ制御部１１-(N+i)を停止する。他のクラスタ制御部は稼動を続ける。ステップＳ６８で、この停止中のクラスタ制御部１１-(N+i)のクラスタソフトウェアをアップグレードする。ステップＳ７０で、このアップグレードしたクラスタ制御部１１-(N+i)を再起動する。ステップＳ７２で、全てのクラスタ制御部１１のアップグレードが終了したか否か判定する。否の場合は、ステップＳ７４で変数ｉを１だけ増加してステップＳ７６からの処理を次のｉ（＋１されたｉ）に対して再び実行する。
【００３６】
このようにして、クラスタシステムを構成するマシン１０-(N+1)〜１０-(N+M)のクラスタ制御部１１-1〜１１-Mを１つづつアップグレードすることにより、エージェント１２-1〜１２-Nで稼動中のサービス１２８-1〜１２８-Nを停止することなく、クラスタソフトウェアをアップグレードすることが可能となる。また、クラスタソフトウェアのアップグレード中も他のクラスタ制御部１１-(N+1)〜１１-(N+M)は稼動しているので、サービス１２８-1〜１２８-Nに障害が発生した場合でも、他サーバ（クラスタ制御部）へのテイクオーバが可能であり、サービスが停止することが防止される。なお、図３の例と同様に、複数台づつ纏めてアップグレードしてもよい。
【００３７】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施の形態に亘る構成要素を適宜組み合せてもよい。
【図面の簡単な説明】
【００３８】
【図１】本発明の第１の実施の形態に係るクラスタシステムの構成を示すブロック図。
【図２】アップグレードの一具体例を説明するためのクラスタシステムの一構成例を示すブロック図。
【図３】図２の構成例のアップグレード処理を説明するためのフローチャート。
【図４】アップグレードの他の具体例を説明するためのクラスタシステムの他の構成例を示すブロック図。
【図５】図４の構成例のアップグレード処理を説明するためのフローチャート。
【図６】アップグレードのさらに他の具体例を説明するためのクラスタシステムのさらに他の構成例を示すブロック図。
【図７】図６の構成例のアップグレード処理を説明するためのフローチャート。
【符号の説明】
【００３９】
１０-1〜１０-4…サーバコンピュータ、１１-1〜１１-4…クラスタ制御部、１２-1〜１２-2…エージェント、２１，２２ネットワーク、２３…クライアント端末、１１０…カーネル、１２２…通信経路切換制御部、１２４…ハートビード送信部、１２６…サービス制御部。
【図１】
2005085114.tif 000003
【図２】
2005085114.tif 000004
【図３】
2005085114.tif 000005
【図４】
2005085114.tif 000006
【図５】
2005085114.tif 000007
【図６】
2005085114.tif 000008
【図７】
2005085114.tif 000009