"NActive構成のクラスタへのサーバの追加および削除と、前記サーバのソフトウェアのバージョンアップとを行うクラスタ管理装置と、前記追加対象のサーバ群と、外部装置から前記クラスタへの処理要求を、当該クラスタのいずれかのサーバへ振り分けるロードバランサとを備えるクラスタシステムであって、前記ロードバランサは、前記処理要求の振り分け先となるサーバを示した振り分け情報を記憶する記憶部と、前記振り分け情報を参照して、前記処理要求の振り分け先となるサーバを決定し、前記決定したサーバへ、前記処理要求を送信する処理要求振り分け部とを備え、前記クラスタ管理装置は、前記サーバごとに、当該サーバがサービスを提供中か、前記クラスタに追加可能か、前記クラスタへの追加不可能かを示したサーバ情報と、前記サービスの識別情報ごとに、当該サービスを提供するクラスタへの処理要求を処理するロードバランサの識別情報と、当該クラスタのサーバが用いるソフトウェアを含むブートイメージの識別情報とを示したサービス情報と、前記ブートイメージとを記憶する記憶部と、前記サーバ情報および前記サービス情報を参照して、前記サーバ群から前記クラスタへの追加対象のサーバを選択し、前記選択したサーバへ、前記サービス情報に示される、当該選択したサーバが用いるブートイメージを送信し、前記サーバの起動処理を行う遠隔ブート部と、前記ソフトウェアのアップデートの指示を受け付けたとき、前記ソフトウェアを用いるクラスタのサーバのうち、前記アップデート前のソフトウェアがインストールされたサーバを、旧クラスタのサーバとし、前記アップデート後のソフトウェアがインストールされたサーバを、新クラスタのサーバとし、前記旧クラスタのサーバ台数をN台としたとき、1台以上N台未満の所定台数のサーバを選択し、前記選択したサーバの起動を前記遠隔ブート部へ指示し、前記サービス情報を参照して、前記ソフトウェアを用いるクラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報に、新たな前記処理要求を受け付けたときの当該処理要求の振り分け先のサーバとして前記選択した新クラスタのサーバを示す新テーブルを設定するコマンド処理部とを備えることを特徴とするクラスタシステム。前記サーバそれぞれの負荷状況を監視し、前記新クラスタのサーバの負荷が所定の閾値以上のとき、前記サーバ情報および前記サービス情報を参照して、前記新クラスタへ新たに追加するサーバを選択し、前記選択したサーバの起動を前記遠隔ブート部へ指示し、前記サービス情報を参照して、前記新クラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報の前記新テーブルに、前記選択したサーバを追加する資源調節部を備えることを特徴とする請求項1に記載のクラスタシステム。前記資源調節部は、さらに、前記サーバそれぞれの負荷状況を監視し、前記旧クラスタのサーバの負荷が所定の閾値以下となったとき、前記旧クラスタから削除するサーバを選択し、前記サービス情報を参照して、前記選択したサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報から、前記選択したサーバを削除し、前記選択したサーバの電源オフを前記遠隔ブート部へ指示することを特徴とする請求項2に記載のクラスタシステム。前記資源調節部が、前記旧クラスタから削除するサーバとして、前記処理要求を処理中のサーバを選択したとき、当該サーバで行っている処理を、前記旧クラスタのサーバから選択した他のいずれかのサーバに引き継ぐよう指示することを特徴とする請求項3に記載のクラスタシステム。NActive構成のクラスタへのサーバの追加および削除と、前記サーバのソフトウェアのバージョンアップとを行うクラスタ管理装置と、前記追加対象のサーバ群と、外部装置から前記クラスタへの処理要求の振り分け先となるサーバを、振り分け情報を参照して決定するロードバランサとを備えるクラスタシステムにおいて、前記サーバごとに、当該サーバがサービスを提供中か、前記クラスタに追加可能か、前記クラスタへの追加不可能かを示したサーバ情報と、前記サービスの識別情報ごとに、当該サービスを提供するクラスタへの処理要求を処理するロードバランサの識別情報と、当該クラスタのサーバが用いるソフトウェアを含むブートイメージの識別情報とを示したサービス情報と、前記ブートイメージとを記憶する記憶部を備える前記クラスタ管理装置が、前記サーバ情報および前記サービス情報を参照して、前記サーバ群から前記クラスタへの追加対象のサーバを選択し、前記選択したサーバへ、前記サービス情報に示される、当該選択したサーバが用いるブートイメージを送信し、前記サーバの起動処理を行うステップと、前記ソフトウェアのアップデートの指示を受け付けたとき、前記ソフトウェアを用いるクラスタのサーバのうち、前記アップデート前のソフトウェアがインストールされたサーバを、旧クラスタのサーバとし、前記アップデート後のソフトウェアがインストールされたサーバを、新クラスタのサーバとし、前記旧クラスタのサーバ台数をN台としたとき、1台以上N台未満の所定台数のサーバを選択するステップと、前記選択したサーバの起動を指示し、前記サービス情報を参照して、前記ソフトウェアを用いるクラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報に、新たな前記処理要求を受け付けたときの当該処理要求の振り分け先のサーバとして前記選択した新クラスタのサーバを示す新テーブルを設定するステップとを実行することを特徴とするソフトウェアアップデート方法。ここで、例えば、電話のようなライフラインサービスでは、サーバのソフトウェアのアップデート時にも無停止でサービスを提供し続けることが必要である。NActive構成では、サーバのソフトウェアの更新中にN台の待機資源待機サーバをサーバプールから取得する必要が生じる。このため、1つのクラスタが平常時の2倍の台数のサーバを占有することになり、他のクラスタへ割り振るサーバが枯渇するおそれがある。そこで、本発明は、NActive構成のクラスタがサービス無停止でソフトウェアのアップデートを行う場合において、占有されるサーバの台数を低減することを目的とする。前記した課題を解決するため、本発明は、NActive構成のクラスタへのサーバの追加および削除と、サーバのソフトウェアのバージョンアップとを行うクラスタ管理装置と、追加対象のサーバ群と、外部装置からクラスタへの処理要求を、当該クラスタのいずれかのサーバへ振り分けるロードバランサとを備えるクラスタシステムが以下の処理を行うこととした。すなわち、このクラスタシステムのロードバランサは、処理要求の振り分け先となるサーバを示した振り分け情報を参照して、処理要求の振り分け先となるサーバを決定し、決定したサーバへ、処理要求を送信する。また、クラスタシステムのクラスタ管理装置は、サーバごとに、当該サーバがサービスを提供中か、クラスタに追加可能か、クラスタへの追加不可能かを示したサーバ情報と、サービスの識別情報ごとに、当該サービスを提供するクラスタへの処理要求を処理するロードバランサの識別情報と、当該クラスタのサーバが用いるソフトウェアを含むブートイメージの識別情報とを示したサービス情報と、ブートイメージとを記憶する記憶部を備える。そして、このクラスタ管理装置は、サーバ情報およびサービス情報を参照して、サーバ群からクラスタへの追加対象のサーバを選択し、選択したサーバへ、サービス情報に示される、当該選択したサーバが用いるブートイメージを送信し、サーバの起動処理を行う。クラスタ管理装置は、ソフトウェアのアップデートの指示を受け付けたとき、ソフトウェアを用いるクラスタのサーバのうち、アップデート前のソフトウェアがインストールされたサーバを、旧クラスタのサーバとし、アップデート後のソフトウェアがインストールされたサーバを、新クラスタのサーバとし、旧クラスタのサーバ台数をN台としたとき、1台以上N台未満の所定台数のサーバを選択する。そして、選択したサーバの起動し、サービス情報を参照して、ソフトウェアを用いるクラスタのサーバへの処理要求を行うロードバランサを特定する。この後、クラスタ管理装置は、この特定したロードバランサの振り分け情報に、新たな処理要求を受け付けたときの当該処理要求の振り分け先のサーバとして選択した新クラスタのサーバを示す新テーブルを設定する。このようにすることで、クラスタシステムのクラスタ管理装置は、ロードバランサにおいて既に受け付け済みの処理要求については、旧クラスタのサーバへ振り分け、新たな処理要求を受け付けたときは、アップデート後のソフトウェアがインストールされたサーバ新クラスタのサーバに振り分けるよう設定する。つまり、ロードバランサにおいて、旧クラスタへの処理要求の振り分けに用いる現テーブルと、新クラスタへの処理要求の振り分けに用いる新テーブルとを併存させる。また、クラスタ管理装置は、新クラスタのサーバの台数を、1台以上N台未満の所定台数新クラスタを構成する最小限の台数とする。これにより、サービス無停止でソフトウェアのバージョンアップを行うとき、旧クラスタと同数のサーバを用意しておく必要がなくなる。また、本発明は、クラスタシステムのクラスタ管理装置が、サーバそれぞれの負荷状況を監視し、新クラスタのサーバの負荷が所定の閾値以上のとき、サーバ情報およびサービス情報を参照して、新クラスタへ新たに追加するサーバを選択する。そして、クラスタ管理装置は、この選択したサーバの起動を指示し、サービス情報を参照して、新クラスタのサーバへの処理要求を行うロードバランサを特定し、特定したロードバランサの振り分け情報の新テーブルに、選択したサーバを追加する。このようにすることで、クラスタ管理装置は、新クラスタのサーバの負荷が大きくなったとき、これに応じて新クラスタにサーバを追加する。これにより、サービス無停止でソフトウェアのバージョンアップを行いたいときに、バージョンアップしたソフトウェアをインストールしたサーバの台数を必要以上に増やす必要がなくなる。また、本発明は、クラスタシステムのクラスタ管理装置が、さらに、サーバそれぞれの負荷状況を監視し、旧クラスタのサーバの負荷が所定の閾値以下となったとき、旧クラスタから削除するサーバを選択する。そして、クラスタ管理装置は、サービス情報を参照して、選択したサーバへの処理要求を行うロードバランサを特定し、特定したロードバランサの振り分け情報から、選択したサーバを削除し、選択したサーバの電源オフを指示する。このようにすることで、クラスタ管理装置は、旧クラスタのサーバの負荷が小さくなったとき、これに応じて旧クラスタのサーバを削減する。つまり、ロードバランサは、新たな処理要求については、新クラスタのサーバに振り分けていくので、旧クラスタのサーババージョンアップ前のソフトウェアを用いるサーバへの処理要求は徐々に減っていく。よって、この旧クラスタのサーバを、振り分け情報から削除してもよくなる。クラスタ管理装置は、ロードバランサの振り分け情報から旧クラスタのサーバを削除し、また電源オフとすることで、このサーバを他のクラスタにおけるサーバ資源として利用できるようになる。つまり、限られたサーバ資源を有効活用できる。また、本発明は、クラスタシステムのクラスタ管理装置が、前記旧クラスタから削除するサーバとして、前記処理要求を処理中のサーバを選択したとき、当該サーバで行っている処理を、前記旧クラスタのサーバから選択した他のいずれかのサーバに引き継ぐよう指示する。このようにすることで、クラスタ管理装置は、旧クラスタのサーバが処理中であったとしても、旧クラスタのサーバの台数を削減できる。本発明によれば、NActive構成のクラスタがサービス無停止でソフトウェアのアップデートを行う場合において、占有されるサーバの台数を低減できる。本発明を実施するための形態以下、実施の形態とするを説明する。まず、システムの概要を説明する。なお、以下の説明において、クラスタは、サーバプール400から選択されたN個のサーバ401から構成されるNActive構成であるものとする。図1に示すように、クラスタシステム2000は、保守ネットワーク600によって保守者端末100と接続し、外部ネットワーク900によって利用者端末200と接続する。サービス提供者は、保守者端末100により、クラスタシステム2000に対し、クラスタへのサーバ追加コマンドやクラスタアップデートコマンドクラスタで用いるソフトウェアのアップデートのコマンドを入力する。また、ユーザは、利用者端末200を用い、クラスタシステム2000上で提供されるサービスを外部ネットワーク900越しに利用する。また、クラスタシステム2000は、クラスタ管理装置300と、サーバ401の集合であるサーバプール400と、ロードバランサ501の集合であるロードバランサプール500とを含んで構成される。クラスタ管理装置300とサーバ401とは、管理ネットワーク700経由で接続される。クラスタ管理装置300は、この管理ネットワーク700経由で、サーバ401へブートイメージを配信する。サーバ401とロードバランサ501とは内部ネットワーク800により接続される。また、ロードバランサ501とクラスタ管理装置300とは、管理ネットワーク700経由で接続される。なお、クラスタ管理装置300は、クラスタ内のサーバ401で用いるソフトウェアがアップデートされると、このアップデートされたソフトウェアを含むブートイメージ以下、適宜アップデートされたブートイメージというをサーバ401へ配信する。また、保守ネットワーク600、管理ネットワーク700、内部ネットワーク800および外部ネットワーク900は、例えば、LANLocalAreaNetworkまたはIPInternetProtocol網である。なお、以下の説明において、アップデートの指示を受けたソフトウェアを用いるクラスタのサーバ401のうち、アップデート前のソフトウェアがインストールされたサーバ401を、旧クラスタのサーバ401という。また、アップデート後のソフトウェアがインストールされたサーバ401を、新クラスタのサーバ401という。ここで、クラスタ管理装置300は、クラスタのサーバ401で用いるソフトウェアがアップデートされると、アップデートされたブートイメージを、最小限の台数のサーバ401に配信し、起動させる。このアップデートされたブートイメージをインストールしたサーバ401群を新クラスタとする。そして、この起動したサーバ401例えば、サーバ401E,401Fを、振り分け情報502の新クラスタのサーバ401群を示したテーブル新テーブルに登録する図2a→図2b参照。その後、ロードバランサ501は、利用者端末200から新たな処理要求を受信したときは、この新テーブルを参照して、サーバ401例えば、図2bのサーバ401E,401Fへ、処理要求を送信する。つまり、ロードバランサ501において、振り分け情報502に、ソフトウェアがアップデートされたサーバ401のクラスタ新クラスタを示す新テーブルと、ソフトウェアのアップデート前のサーバ401のクラスタ旧クラスタを示す現テーブルとを併存させる。その後、旧クラスタのサーバ401での処理が減少してくると、クラスタ管理装置300は、振り分け情報502における旧クラスタのサーバ台数を減少させる図2cおよびd参照。また、新クラスタのサーバ401への処理要求が増加すると、クラスタ管理装置300は、振り分け情報502における新クラスタのサーバ台数を増加させる図2cおよびd参照。つまり、クラスタ管理装置300は、新クラスタおよび旧クラスタそれぞれの処理負荷に応じて、新クラスタのサーバ台数を徐々に増加させ、また、旧クラスタのサーバ台数を徐々に減少させる。これにより、クラスタ管理装置300は、サービス無停止でサーバ401のソフトウェアのバージョンアップを行うとき、予めサーバプール400から多数のサーバ401をクラスタに追加しておく必要がなくなるので、サーバプール400内のサーバ資源を効率よく利用できる。<構成>図1に戻り、システムの構成を詳細に説明する。クラスタ管理装置300は、保守者端末100から入力されたコマンドに基づき、サーバプール400のサーバ401から、クラスタに組み込むサーバ401を選択すると、このサーバ401にブートイメージを配信し、起動させる。このクラスタ管理装置300は、コマンド処理部301と、サーバ情報管理部302と、サービス情報管理部303と、ブートイメージ管理部304と、遠隔ブート部305と、資源調節部306とを備える。また、このクラスタ管理装置300の記憶部図示省略は、サーバ情報307と、サービス情報308と、ブートイメージ情報309とを記憶する。このクラスタ管理装置300は、入出力インタフェース、通信インタフェース、CPUCentralProcessingUnit、メモリ等を備えるコンピュータにより実現される。コマンド処理部301は、クラスタへのサーバ追加やクラスタアップデートそのクラスタで用いるソフトウェアのアップデートコマンド等のコマンドを受け付ける。コマンド処理部301は、クラスタアップデートコマンドを受け付けた場合に、サーバ情報管理部302経由で、サーバ情報307において利用可能となっている1台以上のサーバ401を選択する。ここで選択する台数は、旧クラスタのサーバ台数N台未満で、新クラスタを構成する最小限の台数であり、1台のみでもよいし、冗長化のため2台としてもよい。コマンド処理部301は、この選択したサーバ401の起動を遠隔ブート部305へ指示する。次に、コマンド処理部301は、サービス情報管理部303経由で、アップデートしたソフトウェアを用いるクラスタのサーバ401への処理要求を行うロードバランサ501を特定する。そして、コマンド処理部301は、この特定したロードバランサ501の振り分け情報502における新テーブル図2参照に登録するサーバ401を選ぶ。ロードバランサ501は、サーバ401のソフトウェアのアップデート後、利用者端末200から新たな処理要求を受け付けたときには、この新テーブルを参照することで、新たな処理要求をアップデート後のソフトウェアを備えるサーバ401へ振り分けることになる。なお、新クラスタにサーバ401が追加されると、サーバ情報管理部302は、サーバ情報307図3参照における当該サーバ401の状態を利用可能から利用中に更新する。サーバ情報管理部302は、サーバ情報307図3参照の読み出しおよび書き込みを行う。このサーバ情報307は、サーバごとに、そのサーバ401の状態、つまり、そのサーバ401が利用中であるか、利用可能であるか、利用不可能であるかを示した情報である。図3に例示するサーバ情報307は、サーバプール400内のサーバ401A~401Cがクラスタに追加されサービス提供中であることを示す。さらに、サーバ401A,401Bは、サービスAというサービスを提供するクラスタによって利用されており、サーバ401Cは、サービスBを提供するクラスタによって利用されていることを示す。また、サーバ401Dは利用可能であり、需要に応じてクラスタに追加可能な状態であることを示す。さらに、サーバ401Eは利用不可能であり、故障等何らかの理由で、クラスタに追加できない状態であることを示す。サーバ情報管理部302は、サーバ401の状態が変化すると、この状態そのサーバ401が利用中であるか、利用可能であるか、利用不可能であるかをサーバ情報307に反映させる。なお、このサーバ情報307は、コマンド処理部301や資源調節部306が、クラスタに追加するサーバ401を選択する際に参照される。サービス情報管理部303は、サービス情報308図4参照の読み出しおよび書き込みを行う。このサービス情報308は、クラスタシステム2000に登録されているサービスのIDサービスIDごとに、このサービスを提供するクラスタのサーバ401への処理要求の振り分けを行うロードバランサ501と、そのサービスを提供するためのソフトウェアが含まれたブートイメージブートイメージのイメージIDとを示す情報である。図4に例示するサービス情報308は、クラスタシステム2000に、サービスA,B,C...というサービスが登録されており、サービスAのサービスを提供するクラスタのサーバ401のロードバランサが501A、サービスAを提供するためのソフトウェアが含まれたブートイメージがBI1であることを示す。なお、このサービス情報308は、資源調節部306が振り分け情報502の更新を行うべきロードバランサ501を特定するときや、クラスタのサーバ401に配信すべきブートイメージを特定する際に参照される。ブートイメージ管理部304は、ブートイメージ情報309の読み出しおよび書き込みを行う。このブートイメージ情報309図5参照は、サービス提供に必要なブートイメージの種別イメージIDごとに、ブートイメージの格納場所を示した情報である。ブートイメージは、サービスの提供に必要なソフトウェアを含んだファイルであり、サーバ401に配信されるファイルである。ブートイメージ管理部304は、イメージIDの入力を受け付けると、そのイメージIDのブートイメージの格納場所を示すパスを返す。パスは、クラスタ管理装置300がアクセス可能な場所であれば、クラスタ管理装置300のローカルディスク上でもよいし、リモートストレージ上でもよい。なお、ソフトウェアがアップデートされると、ブートイメージ管理部304は、ブートイメージ情報309における、ブートイメージのパスを、アップデートされたソフトウェアを含むブートイメージのパスに変更する。例えば、図5のブートイメージ情報309において、BI1のブートイメージに含まれるソフトウェアがアップデートされると、BI1のパスをpathto1imgからpathto1newimgに変更する。遠隔ブート部305は、コマンド処理部301または資源調節部306からの指示に基づき、サーバプール400内のサーバ401をブートする起動させる。ここで、サーバ401が電源オフになっている場合、遠隔ブート部305は、IPMIIntelligentPlatformManagementInterface等の管理インタフェースを用いて、このサーバ401の遠隔電源オンを行う。そして、遠隔ブート部305は、サービス情報管理部303およびブートイメージ管理部304に対し、サーバ401が用いるブートイメージを問い合わせ、この問い合わせ結果から得られたブートイメージを、管理ネットワーク700経由で配信する。資源調節部306は、新テーブルの設定後、各サーバ401の負荷状況を監視する。そして、新クラスタのサーバ401の負荷が所定の閾値を超えたとき、新クラスタへのサーバ401の追加増設を行う。つまり、まず、資源調節部306は、新クラスタへ追加するサーバ401を選択し、この選択したサーバ401の起動を遠隔ブート部305へ指示する。次に、資源調節部306は、ロードバランサ501の振り分け情報502の新テーブルに選択したサーバ401を追加する。さらに、資源調節部306は、旧クラスタのサーバ401の負荷が所定の閾値以下となったとき、旧クラスタからサーバ401を削除減設する。つまり、まず、資源調節部306は、サーバ情報管理部302経由で、旧クラスタから削除するサーバ401を選択する。次に、資源調節部306は、サービス情報管理部303経由で、この選択したサーバ401への処理要求を行うロードバランサ501を特定する。そして、資源調節部306は、このロードバランサ501の振り分け情報502の現テーブルから、この選択したサーバ401を削除する。次に、資源調節部306は、この選択したサーバの電源オフを遠隔ブート部305へ指示する。なお、このようにしてサーバ401がクラスタに追加されると、サーバ情報307図3参照における当該サーバ401の状態が利用可能から利用中に更新される。また、サーバ401がクラスタから削除されると、サーバ情報307図3参照における当該サーバ401の状態が利用中から利用可能に更新される。サーバ401は、電源オンになった後、クラスタ管理装置300から配信されたブートイメージを受信し、このブートイメージにより、サーバ401を起動させる。サーバ401も、入出力インタフェース、通信インタフェース、CPU、記憶部等を備えるコンピュータにより実現される。ロードバランサ501は、処理要求の振り分け先サーバ401を示した振り分け情報502と、この振り分け情報502を参照して、利用者端末200からの処理要求を振り分ける処理要求振り分け部503とを備える。この振り分け情報502は、図2および図6に例示するように、現テーブルと新テーブルとを備える。この振り分け情報502は、ロードバランサ501の記憶部の所定領域に記憶される。この現テーブルは、旧クラスタのサーバ401ソフトウェアのアップデート前のサーバ401を示した情報であり、新テーブルは、新クラスタのサーバ401ソフトウェアのアップデート後のサーバ401を示した情報である。処理要求振り分け部503は、利用者端末200から新たな処理要求を受け付けたときには、振り分け情報502の新テーブルの情報を参照して、処理要求の振り分け先を決定する。なお、振り分け情報502は、クラスタ管理装置300の資源調節部306により更新される。この振り分け情報502は、コマンド処理部301によっても更新可能である。このロードバランサ501も、入出力インタフェース、通信インタフェース、CPU、記憶部等を備えるコンピュータにより実現される。<サーバ追加の処理手順>次に、図7を用いて、図1のクラスタ管理装置300のコマンド処理部301が、サーバ追加コマンドを受け付けたときの処理手順を説明する。このサーバ追加コマンドは、少なくともサービスIDおよび追加サーバ数を含む。コマンド処理部301が、サーバ追加コマンドを受け付けるとS11、サーバ情報管理部302経由でサーバ情報307図3参照を参照し、追加サーバ数と同数の利用可能状態のサーバ401例えば、サーバ401Dを選択するS12。ここでの選択は、サーバ情報307の先頭から探索して利用可能状態のサーバ401を上から必要数選択する方法や、各サーバ401のハードウェアスペックを参照して、最も性能がよいサーバ401を選択する方法が考えられる。コマンド処理部301は、サービス情報管理部303経由でサービス情報308図4参照を参照して、サービスIDから必要なブートイメージおよびロードバランサIDを取得するS13。例えば、図4に例示するサービス情報308を参照して、サービスAのブートイメージのイメージIDBI1と、ロードバランサID501Aのアドレスとを取得する。そして、ブートイメージ情報309図5参照に示されるイメージIDBI1のパスを参照して、イメージIDBI1のブートイメージを取得する。その後、コマンド処理部301は、遠隔ブート部305に、S12で選択したサーバ401例えば、サーバ401Dの遠隔電源オンを指示し、S13で取得したブートイメージを配信し、起動させるS14。起動が終わると、コマンド処理部301は、該当のロードバランサ501例えば、ロードバランサ501Aにアクセスし、起動したサーバ401例えば、サーバ401Dを、振り分け情報502の現テーブルへ登録するS15、図6b参照。例えば、図6aに示す振り分け情報502の現テーブルには、サーバ401A~401Cが登録されている。ここで、サーバ追加コマンドによってサービスAを提供するクラスタに、サーバ401Dを追加する場合、図6bに示すように現テーブルを書き換えてサーバ401Dを登録する。また、コマンド処理部301は、サーバ情報管理部302経由で追加したサーバ情報307図3参照における、この追加したサーバ401Dの状態を利用可能から利用中に書き換え、そのサーバ401Dが提供するサービスのサービスIDを登録する。<クラスタアップデートの処理手順>次に、図2および図8を用いて、図1のクラスタ管理装置300のコマンド処理部301が、クラスタアップデートコマンドを受け付けたときの処理手順を説明する。ここでは、例として、サービスAがサーバ401A~401Dによって構成されており、このサービスAの提供のためのソフトウェアがアップデートされる場合について説明する。なお、サービスAのロードバランサ501が持つ振り分け情報502は、図2aのような状態であるとする。このクラスタアップデートコマンドは、少なくとも新クラスタを実行する上で必要なソフトウェアが含まれたブートイメージのパスを含む。ここで、新ブートイメージのパスがpathto1newimgであるクラスタアップデート処理の手順について述べる。コマンド処理部301は、クラスタアップデートコマンドを受け付けるとS21、ブートイメージ管理部304経由で、ブートイメージ情報309図5参照を書き換えるS22。例えば、図4に例示するサービス情報308において、サービスAのブートイメージのイメージIDはBI1なので、コマンド処理部301は、ブートイメージ管理部304経由で、図5のブートイメージ情報309におけるイメージIDBI1のブートイメージのパスをpathto1imgからpathto1newimgに書き換える。その後、コマンド処理部301は、サーバ情報管理部302経由で、サーバ情報307を参照して、クラスタ新クラスタを構成するサーバ401を選択するS23。前記したとおり、ここで選択するサーバ401の台数は、クラスタを構成する最小限の台数とする。この最小限の台数とは予め設定された台数であり、1台でもよいし、冗長化を考慮するのであれば2台でもよい。また、サーバ401の選択は、サーバ情報307の先頭から探索して利用可能状態のサーバ401を上から必要数選択してもよいし、各サーバ401のハードウェアスペックを参照して、最も性能がよいものから選択してもよい。そして、コマンド処理部301は、前記したS13と同様に、サービス情報管理部303経由でサービス情報308を参照して、サービスIDから必要なブートイメージおよびロードバランサIDを取得するS24。例えば、図4に例示するサービス情報308を参照して、サービスAのブートイメージのイメージIDBI1と、ロードバランサID501Aとを取得する。そして、コマンド処理部301は、遠隔ブート部305経由で、サーバ追加コマンドの場合と同様に、S23で選択したサーバ401例えば、サーバ401E,401Fを遠隔ブートし、ブートイメージアップデートされたブートイメージを配信して、選択したサーバ401を起動させるS25。例えば、サーバ401E,401Fへパスpathto1newimgのブートイメージを配信し、サーバ401E,401Fを起動させる。ここで起動が終わると、コマンド処理部301は、該当のロードバランサ501例えば、ロードバランサ501Aにアクセスし、起動したサーバ401例えば、サーバ401E,401Fを、振り分け情報502の新テーブル図2b参照に登録するS26。このようにすることでロードバランサ501は、新たな処理要求については、新テーブルに登録されたサーバ401例えば、サーバ401E,401Fへ振り分けるようになる。なお、クラスタへのサーバ401の追加処理は、例えば、非特許文献3に記載の技術により行われる。<旧クラスタのサーバ減設および新クラスタのサーバ増設>クラスタ管理装置300は、以上の手順により、クラスタアップデートを実行した後、ロードバランサ501の振り分け情報502に登録された各サーバ401の負荷を監視し、旧クラスタのサーバ減設および新クラスタのサーバ増設を行う。図2および図9を用いて、旧クラスタのサーバ減設および新クラスタのサーバ増設の処理手順を説明する。まず、図1のクラスタ管理装置300の資源調節部306は、ロードバランサ501の振り分け情報502に登録された各サーバ401の負荷を監視するS31、そして、資源調節部306は、旧クラスタ振り分け情報502の現テーブルに登録されたサーバ401群の負荷が小さくなったと判断したときS32のYes、旧クラスタを構成するサーバ数を減少させるS33。そして、S31へ戻る。一方、資源調節部306は、旧クラスタの負荷は小さくなっていないがS32のNo、新クラスタ振り分け情報502の新テーブルに登録されたサーバ401群の負荷が大きくなっているときS34のYes、新クラスタを構成するサーバ数を増加させるS35。そして、S31へ戻る。なお、旧クラスタの負荷が小さくなっておらずS32のNo、また、新クラスタの負荷も大きくなっていないときS34のNo、S31へ戻る。ここで、現クラスタの負荷が小さくなったか否かの判断は、現クラスタを構成するサーバ401のリソース使用率を参照して行われる。例えば、資源調節部306は、現クラスタ内のいずれかサーバ401の使用率がゼロになった場合、予め定められた閾値以下になった場合、または、現クラスタ全体の使用率が予め定められた閾値以下になった場合に、現クラスタの負荷が小さくなったと判断する。その場合、資源調節部306は、減設対象のサーバ401をランダムに選択してもよいし、最も使用率が低いサーバ401を選択してもよい。なお、現クラスタにおいて使用率がゼロになっていないサーバ401、すなわち、何らかの処理を行っているサーバ401を減設する場合には、現テーブル中の他のサーバ401に対してその処理および処理に関するセッション状態を譲渡し、処理を継続させればよい。サーバ減設手順の一例を述べる。資源調節部306は、クラスタからの減設対象のサーバ401を決定し、必要であれば、この減設対象のサーバ401から他サーバへの処理の引継ぎを行う。処理が引き継がれる他サーバは、資源調節部306が現テーブル中のサーバ401からランダムに選択してもよいし、最もリソース使用率が少ないサーバ401を選択してもよい。その後、資源調節部306は、減設対象のサーバ401を、遠隔ブート部305経由で電源オフする。そして、サーバ情報管理部302は、サーバ情報307における、この電源オフにしたサーバ401の状態を利用中から利用可能に変更する。なお、資源調節部306は、減設対象のサーバ401を電源オフする際、この減設対象のサーバ401が有する何らかのデータディスクに書き込んだログ等を別の場所に転送し、バックアップをとってから電源オフするようにしてもよい。また、新クラスタの負荷が大きくなったか否かの判断も、新クラスタを構成するサーバ401のリソース使用率を参照して行われる。例えば、資源調節部306は、新クラスタ内のいずれかのサーバ401の使用率が100になった場合、または、新クラスタ全体の使用率が予め定められた閾値以上になった場合に、新クラスタの負荷が大きくなったと判断する。そして、資源調節部306は、前記したサーバ追加と同様の手順によって増設対象のサーバ401を起動し、ロードバランサ501の新テーブルにそのサーバ401を登録する。例えば、図2bに示す振り分け情報502の状態において、旧クラスタのサーバ減設および新クラスタのサーバ増設の両方が必要となった場合、資源調節部306は、図2cに示すように振り分け情報502の現テーブルからサーバ401Dを削除し、新テーブルにサーバ401Gを追加する。この後、さらに、旧クラスタの減設および新クラスタの増設の両方が必要となった場合、資源調節部306は、図2dに示すように、現テーブルからサーバ401Cを削除し、新テーブルにサーバ401Hを追加する。その後、資源調節部306は、サーバ401A,401Bの両方において、すべての処理が終了したことを確認すると、現テーブルからサーバ401A,401Bを削除し、図2eに示すように現テーブルのエントリがなくなる。この状態になると、図2fに示すように資源調節部306は、新テーブルに登録されたサーバ401サーバ401E~401Hをすべて現テーブルに移動し、新テーブルをクリアする。これにより、ロードバランサ501は、次回のクラスタアップデートに備えることができる。以上の処理により、クラスタ管理装置300は、クラスタアップデートを完了する。このように資源調節部306が、旧クラスタおよび新クラスタの負荷状態を監視しながら、旧クラスタのサーバ減設および新クラスタのサーバ増設を行うので、サーバプール400内のサーバ資源を無駄なく利用できる。なお、前記した処理において、資源調節部306が、サーバ401A,401Bのエントリを現テーブルから削除するのは、サーバ401A,401Bにおける処理要求の処理が完了してからでもよいし、クラスタアップデート開始から処定時間経過後でもよい。また、旧クラスタ全体の平均リソース使用率が予め定められた閾値以下になったときでもよい。但し、旧クラスタに処理中のサーバ401が存在した場合、新クラスタでその処理が引き継ぐようにすればよい。"