JP5667506B2 - クラスタシステムおよびソフトウェアアップデート方法 - Google Patents

Description

クラスタシステムにおけるソフトウェアアップデート技術に関する。

近年、Webサーバホスティング等の分野では、データセンタのようなサーバ管理事業者が一括してサーバを管理し、サービス提供事業者をホスティングするＩａａＳ（Infrastructure as a Service）等と呼ばれる形態が一般化している（非特許文献１参照）。ここで、サービスの需要増時や、そのサービスを提供しているサーバが障害によって離脱した場合に、速やかに要求に対応するためには、ある程度の待機余剰資源（待機余剰サーバ）を用意しておく必要がある。また、近年では、現用系サーバと待機系サーバの二重化構成をとるのではなく、サーバをＮ台クラスタリングしたN-Active構成が登場している。N-Active構成は、二重化構成に比べて資源利用効率が高いだけでなく、より柔軟にサーバの追加および削除が可能である(非特許文献２参照)。さらに、需要に応じて、サーバプールに集約されたサーバを各クラスタに動的に追加したり削除したりすることにより、全体の設備利用効率を向上させる技術が提案されている(非特許文献３参照)。

Amazon Elastic Compute Cloud （Amazon EC2）、[online]、[平成23年3月31日検索]、インターネット、<URL:http://aws.amazon.com/ec2/> Mobicents、[online]、[平成23年3月31日検索]、インターネット、<URL: http://www.mobicents.org/> 西村豪生他、高可用ネットワークサーバの資源運用柔軟化に向けた高速リモートブート機構、信学技報、NS2010-148、pp.37-42、Jan、2011.

ここで、例えば、電話のようなライフラインサービスでは、サーバのソフトウェアのアップデート時にも無停止でサービスを提供し続けることが必要である。N-Active構成では、サーバのソフトウェアの更新中にＮ台の待機資源（待機サーバ）をサーバプールから取得する必要が生じる。このため、１つのクラスタが平常時の２倍の台数のサーバを占有することになり、他のクラスタへ割り振るサーバが枯渇するおそれがある。そこで、本発明は、N-Active構成のクラスタがサービス無停止でソフトウェアのアップデートを行う場合において、占有されるサーバの台数を低減することを目的とする。

前記した課題を解決するため、本発明は、N-Active構成のクラスタへのサーバの追加および削除と、サーバのソフトウェアのバージョンアップとを行うクラスタ管理装置と、追加対象のサーバ群と、外部装置からクラスタへの処理要求を、当該クラスタのいずれかのサーバへ振り分けるロードバランサとを備えるクラスタシステムが以下の処理を行うこととした。すなわち、このクラスタシステムのロードバランサは、処理要求の振り分け先となるサーバを示した振り分け情報を参照して、処理要求の振り分け先となるサーバを決定し、決定したサーバへ、処理要求を送信する。また、クラスタシステムのクラスタ管理装置は、クラスタへの追加対象として選択したサーバへ、当該選択したサーバが用いるブートイメージを送信し、サーバの起動処理を行う。クラスタ管理装置は、ソフトウェアのアップデートの指示を受け付けたとき、ソフトウェアを用いるクラスタのサーバのうち、アップデート前のソフトウェアがインストールされたサーバを、旧クラスタのサーバとし、アップデート後のソフトウェアがインストールされたサーバを、新クラスタのサーバとし、旧クラスタのサーバ台数をＮ台としたとき、１台以上Ｎ台未満の所定台数のサーバを選択する。そして、選択したサーバの起動し、ソフトウェアを用いるクラスタのサーバへの処理要求を行うロードバランサを特定する。この後、クラスタ管理装置は、この特定したロードバランサの振り分け情報に、新たな処理要求を受け付けたときの当該処理要求の振り分け先のサーバとして選択した新クラスタのサーバを示す新テーブルを設定する。
また、クラスタ管理装置は、サーバそれぞれの負荷状況を監視し、新クラスタのサーバの負荷が所定の第１の閾値以上のとき、新クラスタへ新たに追加するサーバを選択する。そして、クラスタ管理装置は、この選択したサーバの起動を指示し、新クラスタのサーバへの処理要求を行うロードバランサを特定し、特定したロードバランサの振り分け情報の新テーブルに、選択したサーバを追加する。
さらに、クラスタ管理装置は、サーバそれぞれの負荷状況を監視し、旧クラスタのサーバの負荷が所定の第２の閾値以下となったとき、旧クラスタから削除するサーバを選択する。そして、クラスタ管理装置は、選択したサーバへの処理要求を行うロードバランサを特定し、特定したロードバランサの振り分け情報から、選択したサーバを削除する。

このようにすることで、クラスタシステムのクラスタ管理装置は、ロードバランサにおいて既に受け付け済みの処理要求については、旧クラスタのサーバへ振り分け、新たな処理要求を受け付けたときは、アップデート後のソフトウェアがインストールされたサーバ（新クラスタのサーバ）に振り分けるよう設定する。つまり、ロードバランサにおいて、旧クラスタへの処理要求の振り分けに用いる現テーブルと、新クラスタへの処理要求の振り分けに用いる新テーブルとを併存させる。また、クラスタ管理装置は、新クラスタのサーバの台数を、１台以上Ｎ台未満の所定台数（新クラスタを構成する最小限の台数）とする。これにより、サービス無停止でソフトウェアのバージョンアップを行うとき、旧クラスタと同数のサーバを用意しておく必要がなくなる。
また、クラスタ管理装置は、新クラスタのサーバの負荷が大きくなったとき、これに応じて新クラスタにサーバを追加する。これにより、サービス無停止でソフトウェアのバージョンアップを行いたいときに、バージョンアップしたソフトウェアをインストールしたサーバの台数を必要以上に増やす必要がなくなる。
さらに、クラスタ管理装置は、旧クラスタのサーバの負荷が小さくなったとき、これに応じて旧クラスタのサーバを削減する。つまり、ロードバランサは、新たな処理要求については、新クラスタのサーバに振り分けていくので、旧クラスタのサーバ（バージョンアップ前のソフトウェアを用いるサーバ）への処理要求は徐々に減っていく。よって、この旧クラスタのサーバを、振り分け情報から削除してもよくなる。クラスタ管理装置は、ロードバランサの振り分け情報から旧クラスタのサーバを削除することで、このサーバを他のクラスタにおけるサーバ資源として利用できるようになる。つまり、限られたサーバ資源を有効活用できる。

また、本発明は、クラスタシステムのクラスタ管理装置が、前記旧クラスタから削除するサーバとして、前記処理要求を処理中のサーバを選択したとき、当該サーバで行っている処理を、前記旧クラスタのサーバから選択した他のいずれかのサーバに引き継ぐよう指示する。

このようにすることで、クラスタ管理装置は、旧クラスタのサーバが処理中であったとしても、旧クラスタのサーバの台数を削減できる。

本発明によれば、N-Active構成のクラスタがサービス無停止でソフトウェアのアップデートを行う場合において、占有されるサーバの台数を低減できる。

本実施の形態のクラスタ管理装置を含むシステム構成例を示した図である。 図１の振り分け情報の更新を例示した図である。 図１のサーバ情報を例示した図である。 図１のサービス情報を例示した図である。 図１のブートイメージ情報を例示した図である。 図１の振り分け情報を例示した図である。 図１のクラスタ管理装置によるサーバ追加手順を示した図である。 図１のクラスタ管理装置によるクラスタアップデート手順を示した図である。 図１のクラスタ管理装置による旧クラスタのサーバ減設および新クラスタのサーバ増設手順を示した図である。

本発明を実施するための形態（以下、実施の形態とする）を説明する。まず、システムの概要を説明する。なお、以下の説明において、クラスタは、サーバプール４００から選択されたＮ個のサーバ４０１から構成される（N-Active構成である）ものとする。

図１に示すように、クラスタシステム２０００は、保守ネットワーク６００によって保守者端末１００と接続し、外部ネットワーク９００によって利用者端末２００と接続する。サービス提供者は、保守者端末１００により、クラスタシステム２０００に対し、クラスタへのサーバ追加コマンドやクラスタアップデートコマンド（クラスタで用いるソフトウェアのアップデートのコマンド）を入力する。また、ユーザは、利用者端末２００を用い、クラスタシステム２０００上で提供されるサービスを外部ネットワーク９００越しに利用する。

また、クラスタシステム２０００は、クラスタ管理装置３００と、サーバ４０１の集合であるサーバプール４００と、ロードバランサ５０１の集合であるロードバランサプール５００とを含んで構成される。クラスタ管理装置３００とサーバ４０１とは、管理ネットワーク７００経由で接続される。クラスタ管理装置３００は、この管理ネットワーク７００経由で、サーバ４０１へブートイメージを配信する。サーバ４０１とロードバランサ５０１とは内部ネットワーク８００により接続される。また、ロードバランサ５０１とクラスタ管理装置３００とは、管理ネットワーク７００経由で接続される。なお、クラスタ管理装置３００は、クラスタ内のサーバ４０１で用いるソフトウェアがアップデートされると、このアップデートされたソフトウェアを含むブートイメージ（以下、適宜「アップデートされたブートイメージ」という）をサーバ４０１へ配信する。

また、保守ネットワーク６００、管理ネットワーク７００、内部ネットワーク８００および外部ネットワーク９００は、例えば、ＬＡＮ（Local Area Network）またはＩＰ（Internet Protocol）網である。なお、以下の説明において、アップデートの指示を受けたソフトウェアを用いるクラスタのサーバ４０１のうち、アップデート前のソフトウェアがインストールされたサーバ４０１を、旧クラスタのサーバ４０１という。また、アップデート後のソフトウェアがインストールされたサーバ４０１を、新クラスタのサーバ４０１という。

ここで、クラスタ管理装置３００は、クラスタのサーバ４０１で用いるソフトウェアがアップデートされると、アップデートされたブートイメージを、最小限の台数のサーバ４０１に配信し、起動させる。このアップデートされたブートイメージをインストールしたサーバ４０１群を新クラスタとする。そして、この起動したサーバ４０１（例えば、サーバ４０１Ｅ，４０１Ｆ）を、振り分け情報５０２の新クラスタのサーバ４０１群を示したテーブル（新テーブル）に登録する（図２（ａ）→図２（ｂ）参照）。その後、ロードバランサ５０１は、利用者端末２００から新たな処理要求を受信したときは、この新テーブルを参照して、サーバ４０１（例えば、図２（ｂ）のサーバ４０１Ｅ，４０１Ｆ）へ、処理要求を送信する。つまり、ロードバランサ５０１において、振り分け情報５０２に、ソフトウェアがアップデートされたサーバ４０１のクラスタ（新クラスタ）を示す新テーブルと、ソフトウェアのアップデート前のサーバ４０１のクラスタ（旧クラスタ）を示す現テーブルとを併存させる。

その後、旧クラスタのサーバ４０１での処理が減少してくると、クラスタ管理装置３００は、振り分け情報５０２における旧クラスタのサーバ台数を減少させる（図２（ｃ）および（ｄ）参照）。また、新クラスタのサーバ４０１への処理要求が増加すると、クラスタ管理装置３００は、振り分け情報５０２における新クラスタのサーバ台数を増加させる（図２（ｃ）および（ｄ）参照）。つまり、クラスタ管理装置３００は、新クラスタおよび旧クラスタそれぞれの処理負荷に応じて、新クラスタのサーバ台数を徐々に増加させ、また、旧クラスタのサーバ台数を徐々に減少させる。これにより、クラスタ管理装置３００は、サービス無停止でサーバ４０１のソフトウェアのバージョンアップを行うとき、予めサーバプール４００から多数のサーバ４０１をクラスタに追加しておく必要がなくなるので、サーバプール４００内のサーバ資源を効率よく利用できる。

＜構成＞
図１に戻り、システムの構成を詳細に説明する。クラスタ管理装置３００は、保守者端末１００から入力されたコマンドに基づき、サーバプール４００のサーバ４０１から、クラスタに組み込むサーバ４０１を選択すると、このサーバ４０１にブートイメージを配信し、起動させる。

このクラスタ管理装置３００は、コマンド処理部３０１と、サーバ情報管理部３０２と、サービス情報管理部３０３と、ブートイメージ管理部３０４と、遠隔ブート部３０５と、資源調節部３０６とを備える。また、このクラスタ管理装置３００の記憶部（図示省略）は、サーバ情報３０７と、サービス情報３０８と、ブートイメージ情報３０９とを記憶する。このクラスタ管理装置３００は、入出力インタフェース、通信インタフェース、ＣＰＵ（Central Processing Unit）、メモリ等を備えるコンピュータにより実現される。

コマンド処理部３０１は、クラスタへのサーバ追加やクラスタアップデート（そのクラスタで用いるソフトウェアのアップデート）コマンド等のコマンドを受け付ける。コマンド処理部３０１は、クラスタアップデートコマンドを受け付けた場合に、サーバ情報管理部３０２経由で、サーバ情報３０７において「利用可能」となっている１台以上のサーバ４０１を選択する。ここで選択する台数は、旧クラスタのサーバ台数（Ｎ台）未満で、新クラスタを構成する最小限の台数であり、１台のみでもよいし、冗長化のため２台としてもよい。コマンド処理部３０１は、この選択したサーバ４０１の起動を遠隔ブート部３０５へ指示する。次に、コマンド処理部３０１は、サービス情報管理部３０３経由で、アップデートしたソフトウェアを用いるクラスタのサーバ４０１への処理要求を行うロードバランサ５０１を特定する。そして、コマンド処理部３０１は、この特定したロードバランサ５０１の振り分け情報５０２における新テーブル（図２参照）に登録するサーバ４０１を選ぶ。ロードバランサ５０１は、サーバ４０１のソフトウェアのアップデート後、利用者端末２００から新たな処理要求を受け付けたときには、この新テーブルを参照することで、新たな処理要求をアップデート後のソフトウェアを備えるサーバ４０１へ振り分けることになる。なお、新クラスタにサーバ４０１が追加されると、サーバ情報管理部３０２は、サーバ情報３０７（図３参照）における当該サーバ４０１の状態を「利用可能」から「利用中」に更新する。

サーバ情報管理部３０２は、サーバ情報３０７（図３参照）の読み出しおよび書き込みを行う。このサーバ情報３０７は、サーバごとに、そのサーバ４０１の状態、つまり、そのサーバ４０１が利用中であるか、利用可能であるか、利用不可能であるかを示した情報である。図３に例示するサーバ情報３０７は、サーバプール４００内のサーバ４０１Ａ〜４０１Ｃがクラスタに追加されサービス提供中であることを示す。さらに、サーバ４０１Ａ，４０１Ｂは、サービスＡというサービスを提供するクラスタによって利用されており、サーバ４０１Ｃは、サービスＢを提供するクラスタによって利用されていることを示す。また、サーバ４０１Ｄは「利用可能」であり、需要に応じてクラスタに追加可能な状態であることを示す。さらに、サーバ４０１Ｅは「利用不可能」であり、故障等何らかの理由で、クラスタに追加できない状態であることを示す。サーバ情報管理部３０２は、サーバ４０１の状態が変化すると、この状態（そのサーバ４０１が利用中であるか、利用可能であるか、利用不可能であるか）をサーバ情報３０７に反映させる。なお、このサーバ情報３０７は、コマンド処理部３０１や資源調節部３０６が、クラスタに追加するサーバ４０１を選択する際に参照される。

サービス情報管理部３０３は、サービス情報３０８（図４参照）の読み出しおよび書き込みを行う。このサービス情報３０８は、クラスタシステム２０００に登録されているサービスのＩＤ（サービスＩＤ）ごとに、このサービスを提供するクラスタのサーバ４０１への処理要求の振り分けを行うロードバランサ５０１と、そのサービスを提供するためのソフトウェアが含まれたブートイメージ（ブートイメージのイメージＩＤ）とを示す情報である。図４に例示するサービス情報３０８は、クラスタシステム２０００に、サービスＡ，Ｂ，Ｃ…というサービスが登録されており、サービスＡのサービスを提供するクラスタのサーバ４０１のロードバランサが「５０１Ａ」、サービスＡを提供するためのソフトウェアが含まれたブートイメージが「ＢＩ１」であることを示す。なお、このサービス情報３０８は、資源調節部３０６が振り分け情報５０２の更新を行うべきロードバランサ５０１を特定するときや、クラスタのサーバ４０１に配信すべきブートイメージを特定する際に参照される。

ブートイメージ管理部３０４は、ブートイメージ情報３０９の読み出しおよび書き込みを行う。このブートイメージ情報３０９（図５参照）は、サービス提供に必要なブートイメージの種別（イメージＩＤ）ごとに、ブートイメージの格納場所を示した情報である。ブートイメージは、サービスの提供に必要なソフトウェアを含んだファイルであり、サーバ４０１に配信されるファイルである。ブートイメージ管理部３０４は、イメージＩＤの入力を受け付けると、そのイメージＩＤのブートイメージの格納場所を示すパスを返す。パスは、クラスタ管理装置３００がアクセス可能な場所であれば、クラスタ管理装置３００のローカルディスク上でもよいし、リモートストレージ上でもよい。なお、ソフトウェアがアップデートされると、ブートイメージ管理部３０４は、ブートイメージ情報３０９における、ブートイメージのパスを、アップデートされたソフトウェアを含むブートイメージのパスに変更する。例えば、図５のブートイメージ情報３０９において、「ＢＩ１」のブートイメージに含まれるソフトウェアがアップデートされると、「ＢＩ１」のパスを「/path/to/1.img」から「/path/to/1_new.img」に変更する。

遠隔ブート部３０５は、コマンド処理部３０１または資源調節部３０６からの指示に基づき、サーバプール４００内のサーバ４０１をブートする（起動させる）。ここで、サーバ４０１が電源オフになっている場合、遠隔ブート部３０５は、ＩＰＭＩ（Intelligent Platform Management Interface）等の管理インタフェースを用いて、このサーバ４０１の遠隔電源オンを行う。そして、遠隔ブート部３０５は、サービス情報管理部３０３およびブートイメージ管理部３０４に対し、サーバ４０１が用いるブートイメージを問い合わせ、この問い合わせ結果から得られたブートイメージを、管理ネットワーク７００経由で配信する。

資源調節部３０６は、新テーブルの設定後、各サーバ４０１の負荷状況を監視する。そして、新クラスタのサーバ４０１の負荷が所定の閾値を超えたとき、新クラスタへのサーバ４０１の追加（増設）を行う。つまり、まず、資源調節部３０６は、新クラスタへ追加するサーバ４０１を選択し、この選択したサーバ４０１の起動を遠隔ブート部３０５へ指示する。次に、資源調節部３０６は、ロードバランサ５０１の振り分け情報５０２の新テーブルに選択したサーバ４０１を追加する。さらに、資源調節部３０６は、旧クラスタのサーバ４０１の負荷が所定の閾値以下となったとき、旧クラスタからサーバ４０１を削除（減設）する。つまり、まず、資源調節部３０６は、サーバ情報管理部３０２経由で、旧クラスタから削除するサーバ４０１を選択する。次に、資源調節部３０６は、サービス情報管理部３０３経由で、この選択したサーバ４０１への処理要求を行うロードバランサ５０１を特定する。そして、資源調節部３０６は、このロードバランサ５０１の振り分け情報５０２の現テーブルから、この選択したサーバ４０１を削除する。次に、資源調節部３０６は、この選択したサーバの電源オフを遠隔ブート部３０５へ指示する。なお、このようにしてサーバ４０１がクラスタに追加されると、サーバ情報３０７（図３参照）における当該サーバ４０１の状態が「利用可能」から「利用中」に更新される。また、サーバ４０１がクラスタから削除されると、サーバ情報３０７（図３参照）における当該サーバ４０１の状態が「利用中」から「利用可能」に更新される。

サーバ４０１は、電源オンになった後、クラスタ管理装置３００から配信されたブートイメージを受信し、このブートイメージにより、サーバ４０１を起動させる。サーバ４０１も、入出力インタフェース、通信インタフェース、ＣＰＵ、記憶部等を備えるコンピュータにより実現される。

ロードバランサ５０１は、処理要求の振り分け先（サーバ４０１）を示した振り分け情報５０２と、この振り分け情報５０２を参照して、利用者端末２００からの処理要求を振り分ける処理要求振り分け部５０３とを備える。この振り分け情報５０２は、図２および図６に例示するように、現テーブルと新テーブルとを備える。この振り分け情報５０２は、ロードバランサ５０１の記憶部の所定領域に記憶される。この現テーブルは、旧クラスタのサーバ４０１（ソフトウェアのアップデート前のサーバ４０１）を示した情報であり、新テーブルは、新クラスタのサーバ４０１（ソフトウェアのアップデート後のサーバ４０１）を示した情報である。処理要求振り分け部５０３は、利用者端末２００から新たな処理要求を受け付けたときには、振り分け情報５０２の新テーブルの情報を参照して、処理要求の振り分け先を決定する。なお、振り分け情報５０２は、クラスタ管理装置３００の資源調節部３０６により更新される。この振り分け情報５０２は、コマンド処理部３０１によっても更新可能である。このロードバランサ５０１も、入出力インタフェース、通信インタフェース、ＣＰＵ、記憶部等を備えるコンピュータにより実現される。

＜サーバ追加の処理手順＞
次に、図７を用いて、図１のクラスタ管理装置３００のコマンド処理部３０１が、サーバ追加コマンドを受け付けたときの処理手順を説明する。このサーバ追加コマンドは、少なくともサービスＩＤおよび追加サーバ数を含む。コマンド処理部３０１が、サーバ追加コマンドを受け付けると（Ｓ１１）、サーバ情報管理部３０２経由でサーバ情報３０７（図３参照）を参照し、追加サーバ数と同数の利用可能状態のサーバ４０１（例えば、サーバ４０１Ｄ）を選択する（Ｓ１２）。ここでの選択は、サーバ情報３０７の先頭から探索して利用可能状態のサーバ４０１を上から必要数選択する方法や、各サーバ４０１のハードウェアスペックを参照して、最も性能がよいサーバ４０１を選択する方法が考えられる。

コマンド処理部３０１は、サービス情報管理部３０３経由でサービス情報３０８（図４参照）を参照して、サービスＩＤから必要なブートイメージおよびロードバランサＩＤを取得する（Ｓ１３）。例えば、図４に例示するサービス情報３０８を参照して、サービスＡのブートイメージのイメージＩＤ「ＢＩ１」と、ロードバランサＩＤ「５０１Ａ」のアドレスとを取得する。そして、ブートイメージ情報３０９（図５参照）に示されるイメージＩＤ「ＢＩ１」のパスを参照して、イメージＩＤ「ＢＩ１」のブートイメージを取得する。その後、コマンド処理部３０１は、遠隔ブート部３０５に、Ｓ１２で選択したサーバ４０１（例えば、サーバ４０１Ｄ）の遠隔電源オンを指示し、Ｓ１３で取得したブートイメージを配信し、起動させる（Ｓ１４）。起動が終わると、コマンド処理部３０１は、該当のロードバランサ５０１（例えば、ロードバランサ５０１Ａ）にアクセスし、起動したサーバ４０１（例えば、サーバ４０１Ｄ）を、振り分け情報５０２の現テーブルへ登録する（Ｓ１５、図６（ｂ）参照）。

例えば、図６（ａ）に示す振り分け情報５０２の現テーブルには、サーバ４０１Ａ〜４０１Ｃが登録されている。ここで、サーバ追加コマンドによってサービスＡを提供するクラスタに、サーバ４０１Ｄを追加する場合、図６（ｂ）に示すように現テーブルを書き換えてサーバ４０１Ｄを登録する。また、コマンド処理部３０１は、サーバ情報管理部３０２経由で追加したサーバ情報３０７（図３参照）における、この追加したサーバ４０１Ｄの状態を「利用可能」から「利用中」に書き換え、そのサーバ４０１Ｄが提供するサービスのサービスＩＤを登録する。

＜クラスタアップデートの処理手順＞
次に、図２および図８を用いて、図１のクラスタ管理装置３００のコマンド処理部３０１が、クラスタアップデートコマンドを受け付けたときの処理手順を説明する。ここでは、例として、サービスＡがサーバ４０１Ａ〜４０１Ｄによって構成されており、このサービスＡの提供のためのソフトウェアがアップデートされる場合について説明する。なお、サービスＡのロードバランサ５０１が持つ振り分け情報５０２は、図２（ａ）のような状態であるとする。このクラスタアップデートコマンドは、少なくとも新クラスタを実行する上で必要なソフトウェアが含まれたブートイメージのパスを含む。ここで、新ブートイメージのパスが「/path/to/1_new.img」であるクラスタアップデート処理の手順について述べる。

コマンド処理部３０１は、クラスタアップデートコマンドを受け付けると（Ｓ２１）、ブートイメージ管理部３０４経由で、ブートイメージ情報３０９（図５参照）を書き換える（Ｓ２２）。例えば、図４に例示するサービス情報３０８において、サービスＡのブートイメージのイメージＩＤは「ＢＩ１」なので、コマンド処理部３０１は、ブートイメージ管理部３０４経由で、図５のブートイメージ情報３０９におけるイメージＩＤ「ＢＩ１」のブートイメージのパスを「/path/to/1.img」から「/path/to/1_new.img」に書き換える。

その後、コマンド処理部３０１は、サーバ情報管理部３０２経由で、サーバ情報３０７を参照して、クラスタ（新クラスタ）を構成するサーバ４０１を選択する（Ｓ２３）。前記したとおり、ここで選択するサーバ４０１の台数は、クラスタを構成する最小限の台数とする。この最小限の台数とは予め設定された台数であり、１台でもよいし、冗長化を考慮するのであれば２台でもよい。また、サーバ４０１の選択は、サーバ情報３０７の先頭から探索して利用可能状態のサーバ４０１を上から必要数選択してもよいし、各サーバ４０１のハードウェアスペックを参照して、最も性能がよいものから選択してもよい。

そして、コマンド処理部３０１は、前記したＳ１３と同様に、サービス情報管理部３０３経由でサービス情報３０８を参照して、サービスＩＤから必要なブートイメージおよびロードバランサＩＤを取得する（Ｓ２４）。例えば、図４に例示するサービス情報３０８を参照して、サービスＡのブートイメージのイメージＩＤ「ＢＩ１」と、ロードバランサＩＤ「５０１Ａ」とを取得する。そして、コマンド処理部３０１は、遠隔ブート部３０５経由で、サーバ追加コマンドの場合と同様に、Ｓ２３で選択したサーバ４０１（例えば、サーバ４０１Ｅ，４０１Ｆ）を遠隔ブートし、ブートイメージ（アップデートされたブートイメージ）を配信して、選択したサーバ４０１を起動させる（Ｓ２５）。例えば、サーバ４０１Ｅ，４０１Ｆへパス「/path/to/1_new.img」のブートイメージを配信し、サーバ４０１Ｅ，４０１Ｆを起動させる。ここで起動が終わると、コマンド処理部３０１は、該当のロードバランサ５０１（例えば、ロードバランサ５０１Ａ）にアクセスし、起動したサーバ４０１（例えば、サーバ４０１Ｅ，４０１Ｆ）を、振り分け情報５０２の新テーブル（図２（ｂ）参照）に登録する（Ｓ２６）。このようにすることでロードバランサ５０１は、新たな処理要求については、新テーブルに登録されたサーバ４０１（例えば、サーバ４０１Ｅ，４０１Ｆ）へ振り分けるようになる。

なお、クラスタへのサーバ４０１の追加処理は、例えば、非特許文献３に記載の技術により行われる。

＜旧クラスタのサーバ減設および新クラスタのサーバ増設＞
クラスタ管理装置３００は、以上の手順により、クラスタアップデートを実行した後、ロードバランサ５０１の振り分け情報５０２に登録された各サーバ４０１の負荷を監視し、旧クラスタのサーバ減設および新クラスタのサーバ増設を行う。図２および図９を用いて、旧クラスタのサーバ減設および新クラスタのサーバ増設の処理手順を説明する。

まず、図１のクラスタ管理装置３００の資源調節部３０６は、ロードバランサ５０１の振り分け情報５０２に登録された各サーバ４０１の負荷を監視する（Ｓ３１）、そして、資源調節部３０６は、旧クラスタ（振り分け情報５０２の現テーブルに登録されたサーバ４０１群）の負荷が小さくなったと判断したとき（Ｓ３２のＹｅｓ）、旧クラスタを構成するサーバ数を減少させる（Ｓ３３）。そして、Ｓ３１へ戻る。一方、資源調節部３０６は、旧クラスタの負荷は小さくなっていないが（Ｓ３２のＮｏ）、新クラスタ（振り分け情報５０２の新テーブルに登録されたサーバ４０１群）の負荷が大きくなっているとき（Ｓ３４のＹｅｓ）、新クラスタを構成するサーバ数を増加させる（Ｓ３５）。そして、Ｓ３１へ戻る。なお、旧クラスタの負荷が小さくなっておらず（Ｓ３２のＮｏ）、また、新クラスタの負荷も大きくなっていないとき（Ｓ３４のＮｏ）、Ｓ３１へ戻る。

ここで、現クラスタの負荷が小さくなったか否かの判断は、現クラスタを構成するサーバ４０１のリソース(ＣＰＵ、メモリ、ネットワーク等)使用率を参照して行われる。例えば、資源調節部３０６は、現クラスタ内のいずれかサーバ４０１の使用率がゼロになった場合、予め定められた閾値以下になった場合、または、現クラスタ全体の使用率が予め定められた閾値以下になった場合に、現クラスタの負荷が小さくなったと判断する。その場合、資源調節部３０６は、減設対象のサーバ４０１をランダムに選択してもよいし、最も使用率が低いサーバ４０１を選択してもよい。なお、現クラスタにおいて使用率がゼロになっていないサーバ４０１、すなわち、何らかの処理を行っているサーバ４０１を減設する場合には、現テーブル中の他のサーバ４０１に対してその処理および処理に関するセッション状態を譲渡し、処理を継続させればよい。

サーバ減設手順の一例を述べる。資源調節部３０６は、クラスタからの減設対象のサーバ４０１を決定し、必要であれば、この減設対象のサーバ４０１から他サーバへの処理の引継ぎを行う。処理が引き継がれる他サーバは、資源調節部３０６が現テーブル中のサーバ４０１からランダムに選択してもよいし、最もリソース使用率が少ないサーバ４０１を選択してもよい。その後、資源調節部３０６は、減設対象のサーバ４０１を、遠隔ブート部３０５経由で電源オフする。そして、サーバ情報管理部３０２は、サーバ情報３０７における、この電源オフにしたサーバ４０１の状態を「利用中」から「利用可能」に変更する。なお、資源調節部３０６は、減設対象のサーバ４０１を電源オフする際、この減設対象のサーバ４０１が有する何らかのデータ（ディスクに書き込んだログ等）を別の場所に転送し、バックアップをとってから電源オフするようにしてもよい。

また、新クラスタの負荷が大きくなったか否かの判断も、新クラスタを構成するサーバ４０１のリソース(ＣＰＵ、メモリ、ネットワーク等)使用率を参照して行われる。例えば、資源調節部３０６は、新クラスタ内のいずれかのサーバ４０１の使用率が１００％になった場合、または、新クラスタ全体の使用率が予め定められた閾値以上になった場合に、新クラスタの負荷が大きくなったと判断する。そして、資源調節部３０６は、前記したサーバ追加と同様の手順によって増設対象のサーバ４０１を起動し、ロードバランサ５０１の新テーブルにそのサーバ４０１を登録する。

例えば、図２（ｂ）に示す振り分け情報５０２の状態において、旧クラスタのサーバ減設および新クラスタのサーバ増設の両方が必要となった場合、資源調節部３０６は、図２（ｃ）に示すように振り分け情報５０２の現テーブルからサーバ４０１Ｄを削除し、新テーブルにサーバ４０１Ｇを追加する。この後、さらに、旧クラスタの減設および新クラスタの増設の両方が必要となった場合、資源調節部３０６は、図２（ｄ）に示すように、現テーブルからサーバ４０１Ｃを削除し、新テーブルにサーバ４０１Ｈを追加する。その後、資源調節部３０６は、サーバ４０１Ａ，４０１Ｂの両方において、すべての処理が終了したことを確認すると、現テーブルからサーバ４０１Ａ，４０１Ｂを削除し、図２（ｅ）に示すように現テーブルのエントリがなくなる。この状態になると、図２（ｆ）に示すように資源調節部３０６は、新テーブルに登録されたサーバ４０１（サーバ４０１Ｅ〜４０１Ｈ）をすべて現テーブルに移動し、新テーブルをクリアする。これにより、ロードバランサ５０１は、次回のクラスタアップデートに備えることができる。以上の処理により、クラスタ管理装置３００は、クラスタアップデートを完了する。このように資源調節部３０６が、旧クラスタおよび新クラスタの負荷状態を監視しながら、旧クラスタのサーバ減設および新クラスタのサーバ増設を行うので、サーバプール４００内のサーバ資源を無駄なく利用できる。

なお、前記した処理において、資源調節部３０６が、サーバ４０１Ａ，４０１Ｂのエントリを現テーブルから削除するのは、サーバ４０１Ａ，４０１Ｂにおける処理要求の処理が完了してからでもよいし、クラスタアップデート開始から処定時間経過後でもよい。また、旧クラスタ全体の平均リソース使用率が予め定められた閾値以下になったときでもよい。但し、旧クラスタに処理中のサーバ４０１が存在した場合、新クラスタでその処理が引き継ぐようにすればよい。

１００ 保守者端末
２００ 利用者端末
３００ クラスタ管理装置
３０１ コマンド処理部
３０２ サーバ情報管理部
３０３ サービス情報管理部
３０４ ブートイメージ管理部
３０５ 遠隔ブート部
３０６ 資源調節部
３０７ サーバ情報
３０８ サービス情報
３０９ ブートイメージ情報
４００ サーバプール
４０１ サーバ
５００ ロードバランサプール
５０１ ロードバランサ
５０２ 振り分け情報
５０３ 処理要求振り分け部
６００ 保守ネットワーク
７００ 管理ネットワーク
８００ 内部ネットワーク
９００ 外部ネットワーク
２０００ クラスタシステム

Claims (3)

1. N-Active構成のクラスタへのサーバの追加および削除と、前記サーバのソフトウェアのバージョンアップとを行うクラスタ管理装置と、前記追加対象のサーバ群と、外部装置から前記クラスタへの処理要求を、当該クラスタのいずれかのサーバへ振り分けるロードバランサとを備えるクラスタシステムであって、
   前記ロードバランサは、
   前記処理要求の振り分け先となるサーバを示した振り分け情報を記憶する記憶部と、
   前記振り分け情報を参照して、前記処理要求の振り分け先となるサーバを決定し、前記決定したサーバへ、前記処理要求を送信する処理要求振り分け部とを備え、
   前記クラスタ管理装置は、
   前記クラスタへの追加対象として選択したサーバへ、当該選択したサーバが用いるブートイメージを送信し、当該サーバの起動処理を行う遠隔ブート部と、
   前記ソフトウェアのアップデートの指示を受け付けたとき、前記ソフトウェアを用いるクラスタのサーバのうち、前記アップデート前のソフトウェアがインストールされたサーバを、旧クラスタのサーバとし、前記アップデート後のソフトウェアがインストールされたサーバを、新クラスタのサーバとし、前記旧クラスタのサーバ台数をＮ台としたとき、１台以上Ｎ台未満の所定台数のサーバを選択し、当該選択したサーバの起動を前記遠隔ブート部へ指示し、前記ソフトウェアを用いるクラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報に、新たな前記処理要求を受け付けたときの当該処理要求の振り分け先のサーバとして当該選択した新クラスタのサーバを示す新テーブルを設定するコマンド処理部と、
   前記サーバそれぞれの負荷状況を監視し、前記新クラスタのサーバの負荷が所定の第１の閾値以上のとき、前記新クラスタへ新たに追加するサーバを選択し、当該選択したサーバの起動を前記遠隔ブート部へ指示し、前記新クラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報の前記新テーブルに、当該選択したサーバを追加するとともに、
   前記サーバそれぞれの負荷状況を監視し、前記旧クラスタのサーバの負荷が所定の第２の閾値以下となったとき、前記旧クラスタから削除するサーバを選択し、当該選択したサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報から、当該選択したサーバを削除する資源調節部とを備えることを特徴とするクラスタシステム。
2. 前記資源調節部が、
   前記旧クラスタから削除するサーバとして、前記処理要求を処理中のサーバを選択したとき、当該サーバで行っている処理を、前記旧クラスタのサーバから選択した他のいずれかのサーバに引き継ぐよう指示することを特徴とする請求項１に記載のクラスタシステム。
3. N-Active構成のクラスタへのサーバの追加および削除と、前記サーバのソフトウェアのバージョンアップとを行うクラスタ管理装置と、前記追加対象のサーバ群と、外部装置から前記クラスタへの処理要求の振り分け先となるサーバを、振り分け情報を参照して決定するロードバランサとを備えるクラスタシステムにおいて、
   前記クラスタ管理装置が、
   前記クラスタへの追加対象として選択したサーバへ、当該選択したサーバが用いるブートイメージを送信し、当該サーバの起動処理を行うステップと、
   前記ソフトウェアのアップデートの指示を受け付けたとき、前記ソフトウェアを用いるクラスタのサーバのうち、前記アップデート前のソフトウェアがインストールされたサーバを、旧クラスタのサーバとし、前記アップデート後のソフトウェアがインストールされたサーバを、新クラスタのサーバとし、前記旧クラスタのサーバ台数をＮ台としたとき、１台以上Ｎ台未満の所定台数のサーバを選択するステップと、
   当該選択したサーバの起動を指示し、前記ソフトウェアを用いるクラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報に、新たな前記処理要求を受け付けたときの当該処理要求の振り分け先のサーバとして当該選択した新クラスタのサーバを示す新テーブルを設定するステップと、
   前記サーバそれぞれの負荷状況を監視し、前記新クラスタのサーバの負荷が所定の第１の閾値以上のとき、前記新クラスタへ新たに追加するサーバを選択し、当該選択したサーバの起動を指示し、前記新クラスタのサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報の前記新テーブルに、当該選択したサーバを追加するステップと、
   前記サーバそれぞれの負荷状況を監視し、前記旧クラスタのサーバの負荷が所定の第２の閾値以下となったとき、前記旧クラスタから削除するサーバを選択し、当該選択したサーバへの処理要求を行うロードバランサを特定し、前記特定したロードバランサの振り分け情報から、当該選択したサーバを削除するステップとを実行することを特徴とするソフトウェアアップデート方法。

Images