(57)【特許請求の範囲】
【請求項１】
サービスを提供する複数のサーバと、前記複数のサーバを管理するリソースマネージャとからなるクラスタシステムにおいて、
前記リソースマネージャは、所定のサービスを行うためのサーバを追加するスケールアウトの要求があると、前記複数のサーバの中から待機状態にあるサーバをスケールアウトを行うサーバとして選出すると共に、前記複数のサーバの中で前記所定のサービスを既に作動している複数のサーバに対して前記所定のサービスのソフトウェアイメージの断片の転送を指示する手段を有し、
前記ソフトウェアの転送を指示された複数のサーバは、前記所定のサービスのソフトウェアイメージの断片を前記スケールアウトを行うサーバとして選出されたサーバに転送する手段を有し、
前記スケールアウトを行うサーバとして選出されたサーバは、前記ソフトウェアの転送を指示された複数のサーバから転送されてきた所定のサービスのソフトウェアイメージを受信して保存する手段を有する
ことを特徴とするクラスタシステム。
【請求項２】
前記ソフトウェアの転送を指示されたサーバは複数あり、前記ソフトウェアの転送を指示された複数のサーバは、それぞれ、等分の転送量で、前記所定のサービスのソフトウェアイメージの断片を前記スケールアウトを行うサーバに転送することを特徴とする請求項１に記載のクラスタシステム。
【請求項３】
前記ソフトウェアの転送を指示されたサーバは複数あり、前記ソフトウェアの転送を指示された複数のサーバは、それぞれ、重み付けした転送量で、前記所定のサービスのソフトウェアイメージの断片を前記スケールアウトを行うサーバに転送することを特徴とする請求項１に記載のクラスタシステム。
【請求項４】
前記重み付けは、サーバの処理負荷及び有休資源に応じて行うことを特徴とする請求項３に記載のクラスタシステム。
【請求項５】
前記サーバの処理負荷及び有休資源の情報は、前記リソースマネージャが各サーバの平均的な処理負荷及び有休資源に基づいて静的に管理することを特徴とする請求項４に記載のクラスタシステム。
【請求項６】
前記サーバの処理負荷及び有休資源の情報は、前記リソースマネージャが各サーバからの情報を取得して動的に管理することを特徴とする請求項４に記載のクラスタシステム。
【請求項７】
サービスを提供する複数のサーバと、前記複数のサーバを管理するリソースマネージャとからなるクラスタシステムのスケールアウト方法において、
所定のサービスを行うためのサーバを追加するスケールアウトの要求があると、前記リソースマネージャが、前記複数のサーバの中から待機状態にあるサーバをスケールアウトを行うサーバとして選出すると共に、前記複数のサーバの中で前記所定のサービスを既に作動している複数のサーバに対して前記所定のサービスのソフトウェアイメージの断片の転送を指示する工程と、
前記ソフトウェアの転送を指示された複数のサーバが、前記所定のサービスのソフトウェアイメージの断片を前記スケールアウトを行うサーバに転送する工程と、
前記スケールアウトを行うサーバが、前記ソフトウェアの転送を指示された複数のサーバから転送されてきた所定のサービスのソフトウェアイメージを受信して保存する工程と
を含むことを特徴とするスケールアウト方法。
【請求項８】
サービスを提供する複数のサーバと、前記複数のサーバを管理するリソースマネージャとからクラスタシステムを構成するためのリソースマネージャ装置において、
サービス実行に必要なソフトウェアイメージを管理する手段と、
前記複数のサーバの稼働状態を監視する手段と、
所定のサービスを行うためのサーバを追加するスケールアウトの要求があると、前記複数のサーバの中から待機状態にあるサーバをスケールアウトを行うサーバとして選出すると共に、前記複数のサーバの中で前記所定のサービスを既に作動している複数のサーバに対して、前記スケールアウトを行うサーバに前記所定のサービスのソフトウェアイメージの断片を転送することを要求する手段と
を備えることを特徴とするリソースマネージャ装置。
【請求項９】
サービスを提供する複数のサーバと、前記複数のサーバを管理するリソースマネージャとからクラスタシステムを構成するためのサーバ装置において、
ソフトウェアイメージの断片の転送及び取得を行う手段と、
ソフトウェアイメージの格納手段と、
個別設定情報の格納手段とを備え、
他のサーバがスケールアウトを行うサーバとして設定されると、前記リソースマネージャの指示により、前記ソフトウェアイメージの格納手段に格納されているソフトウェアイメージの断片を前記スケールアウトを行うサーバに転送し、
当該サーバがスケールアウトを行うサーバとして選定されると、既に所定のサービスを作動している他の複数のサーバから転送されてくるソフトウェアイメージを取得し、前記ソフトウェアイメージの格納手段に格納する
ことを特徴とするサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信サービスなどを提供する高可用クラスタシステム、クラスタシステムのスケールアウト方法、リソースマネージャ装置、サーバ装置に関する。
【背景技術】
【０００２】
近年、インターネットにおいてはサービスの多様化が顕著である。また、新サービスは、利用者数を事前に明確に把握することが困難であるため、最初に小規模のサーバを用いてサービス提供を開始（スモールスタート）し、利用者の増加に応じてサーバを増強していくことがコスト面で有効である。
【０００３】
また、近年ではサーバ増強の手段として、ハードウェアをより強力なものに交換するのではなく、同じ処理を行うサーバを追加（スケールアウト）し、複数のサーバが並列動作するクラスタによって処理を行うことが一般的となりつつある。
【０００４】
ただし、利用者数の増加時に速やかにスケールアウトを行うためには、稼働していない予備のサーバを常に待機させておく必要がある。そのような常に使用していない待機サーバを個々のサービス提供事業者が用意するのはコストが高い。
【０００５】
そこで、近年ではデータセンターのようなサーバ管理事業者が一括してサーバを管理し、サービス提供事業者をホスティングするＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）などと呼ばれる形態が一般化している（非特許文献１）。ＩａａＳでは、個々のサービス提供事業者にとって、サーバのハードウェアメンテナンスが不要なだけでなく、複数のサービス提供事業者が待機サーバを共有することにより、サーバ設備維持費の低減が期待できる。
【０００６】
一方、近年では設備維持コスト低減を目的として通信網のＩＰ化が進んでおり、従来の交換機のような専用ハードウェアではなく、汎用サーバを用いて通信ネットワーク・通信サービスを実現することが一般化している。また、通信サービスにおいてもサービスは多様化しているため、新サービスをスモールスタートし、利用者の拡大に応じてサーバ数をスケールアウトすることにより、設備コストを低減したいという要求がある。そのような要求に対して、各サービスをスモールスタートし、あるサービスの利用者拡大時に、余剰待機資源が集約されたリソースプールから必要なサーバを獲得し、スケールアウトを行う構成の適用が考えられる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Amazon Elastic Compute Cloud (Amazon EC2), http://aws.amazon.com/ec2/.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述のような、個々のサービスにおけるスケールアウト時に、余剰資源が集約された共用のリソースプールからサーバを取得する構成においては、リソースプール内に保持されているサーバは共用であり、どのようなソフトウェア構成を取るかが事前にわからないため、ソフトウェアを何も有していない状態であることが一般的である。よって、スケールアウト時にサーバを取得した後、個々のサービスに対応したソフトウェア構成が含まれたソフトウェアイメージを、イメージを管理しているリポジトリからそのサーバに転送し、必要な設定を行ってクラスタに組み込む必要がある。
【０００９】
ソフトウェアイメージはオペレーティングシステムや各種ミドルウェア、データ等を全て含んでいるため数〜数十ＧＢに及ぶ大容量であり、転送にはある程度の時間を要する。複数のサービスを同時にスケールアウトするような場合、イメージを管理しているリポジトリがボトルネックとなり、さらにスケールアウト時間が増大するため、インフラとして公共性の高い通信サービスに求められる無停止性・即応性を満たすことができない。
【００１０】
上述の課題を鑑み、本発明の目的は、スケールアウト時のソフトウェアイメージ転送の負荷を軽減できるようにしたクラスタシステム、クラスタシステムのスケールアウト方法、リソースマネージャ装置、サーバ装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述の課題を解決するために、本発明に係るクラスタシステムは、サービスを提供する複数のサーバと、複数のサーバを管理するリソースマネージャとからなるクラスタシステムにおいて、リソースマネージャは、所定のサービスを行うためのサーバを追加するスケールアウトの要求があると、複数のサーバの中から待機状態にあるサーバをスケールアウトを行うサーバとして選出すると共に、複数のサーバの中で所定のサービスを既に作動している複数のサーバに対して所定のサービスのソフトウェアイメージの断片の転送を指示する手段を有し、ソフトウェアの転送を指示された複数のサーバは、所定のサービスのソフトウェアイメージの断片をスケールアウトを行うサーバとして選出されたサーバに転送する手段を有し、スケールアウトを行うサーバとして選出されたサーバは、ソフトウェアの転送を指示された複数のサーバから転送されてきた所定のサービスのソフトウェアイメージを受信して保存する手段を有することを特徴とする。
【００１２】
本発明に係るクラスタシステムのスケールアウト方法は、サービスを提供する複数のサーバと、複数のサーバを管理するリソースマネージャとからなるクラスタシステムのスケールアウト方法において、所定のサービスを行うためのサーバを追加するスケールアウトの要求があると、リソースマネージャが、複数のサーバの中から待機状態にあるサーバをスケールアウトを行うサーバとして選出すると共に、複数のサーバの中で所定のサービスを既に作動している複数のサーバに対して所定のサービスのソフトウェアイメージの断片の転送を指示する工程と、ソフトウェアの転送を指示された複数のサーバが、所定のサービスのソフトウェアイメージの断片をスケールアウトを行うサーバに転送する工程と、スケールアウトを行うサーバが、ソフトウェアの転送を指示された複数のサーバから転送されてきた所定のサービスのソフトウェアイメージを受信して保存する工程とを含むことを特徴とする。
【００１３】
本発明に係るリソースマネージャ装置は、サービスを提供する複数のサーバと、複数のサーバを管理するリソースマネージャとからクラスタシステムを構成するためのリソースマネージャ装置において、サービス実行に必要なソフトウェアイメージを管理する手段と、複数のサーバの稼働状態を監視する手段と、所定のサービスを行うためのサーバを追加するスケールアウトの要求があると、複数のサーバの中から待機状態にあるサーバをスケールアウトを行うサーバとして選出すると共に、複数のサーバの中で所定のサービスを既に作動している複数のサーバに対して、スケールアウトを行うサーバに所定のサービスのソフトウェアイメージの断片を転送することを要求する手段とを備えることを特徴とする。
【００１４】
本発明に係るサーバ装置は、サービスを提供する複数のサーバと、複数のサーバを管理するリソースマネージャとからクラスタシステムを構成するためのサーバ装置において、ソフトウェアイメージの断片の転送及び取得を行う手段と、ソフトウェアイメージの格納手段と、個別設定情報の格納手段とを備え、他のサーバがスケールアウトを行うサーバとして設定されると、リソースマネージャの指示により、ソフトウェアイメージの格納手段に格納されているソフトウェアイメージの断片をスケールアウトを行うサーバに転送し、当該サーバがスケールアウトを行うサーバとして選定されると、既に所定のサービスを作動している他の複数のサーバから転送されてくるソフトウェアイメージを取得し、ソフトウェアイメージの格納手段に格納することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、スケールアウト時に、既に稼働中の現用中のサーバが使用しているソフトウェアイメージが新規にスケールアウトを行うサーバに転送され、新規にスケールアウトを行うサーバの固有の設定が行われる。また、新規にスケールアウトを行うサーバには、クラスタを構成する複数のサーバからソフトウェアイメージが一部ずつ転送される。このため、特定の現用中サーバに転送負荷が集中することがなくなり、高速にスケールアウトすることが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態に係るクラスタシステムの全体構成を示すブロック図である。
【図２】ソフトウェアイメージの管理情報テーブルの構成の説明図である。
【図３】本発明の第１の実施形態に係るクラスタシステムにおいてサービスが起動していないときのシステムの説明図である。
【図４】本発明の第１の実施形態に係るクラスタシステムにおいてサービスが起動していないときのサーバ状態監視機能部のサーバ状態の説明図である。
【図５】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ａ」を起動するときの説明に用いるシーケンス図である。
【図６】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ａ」を起動したときのサーバ状態監視機能部のサーバ状態の説明図である。
【図７】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ｂ」を起動するときの説明に用いるシーケンス図である。
【図８】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ｂ」を起動したときのシステムの説明図である。
【図９】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ｂ」を起動したときのサーバ状態監視機能部のサーバ状態の説明図である。
【図１０】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ｂ」をスケールアウトするときの説明に用いるシーケンス図である。
【図１１】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ｂ」をスケールアウトしたときのシステムの説明図である。
【図１２】本発明の第１の実施形態に係るクラスタシステムにおいてサービス「Ｂ」をスケールアウトしたときのサーバ状態監視機能部が持つサーバ状態の説明図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態について図面を参照しながら説明する。図１は、本発明の第１の実施形態に係るクラスタシステムの全体構成を示すブロック図である。
【００１８】
図１において、本発明の第１の実施形態に係るクラスタシステム１０２は、保守ネットワーク１５０によって保守者端末１０１と接続し、サービスネットワーク１６０によって利用者端末１４０と接続する。
【００１９】
サービス提供者は、クラスタシステム１０２に対する保守コマンドを、保守者端末１０１によって実施する。保守コマンドとしては、サービスを提供するためのサーバクラスタの構築や、スケールアウトによるクラスタの増強などが挙げられる。
【００２０】
ユーザは、利用者端末１４０を用い、クラスタシステム１０２上で提供されるサービスをサービスネットワーク１６０を介して利用する。クラスタシステム１０２は、計算資源が集約されているリソースプール１２０と、資源を管理する機能部であるリソースマネージャ１０３で構成され、両者は管理ネットワーク１１０によって接続される。リソースプール１２０は計算資源である複数のサーバ１３０によって構成される。
【００２１】
次に、リソースマネージャ１０３の構成機能部について説明する。リソースマネージャ１０３は、管理インタフェース２０１と、ソフトウェアイメージ管理機能部２０２と、サーバ状態管理機能部２０３と、サーバ起動処理機能部２０４と、サーバ状態監視機能部２０５とから構成される。
【００２２】
管理インタフェース２０１は、保守者端末１０１とのインタフェースを行い、保守者端末１０１からの保守コマンドを受け付けて、適切な処理を他の機能部と連携して実行する。ソフトウェアイメージは、サービスの提供に必要なソフトウェア構成を含んだファイルであり、サービス提供時にサーバ１３０に転送される。
【００２３】
ソフトウェアイメージ管理機能部２０２は、所定のサービス実行に必要なソフトウェアイメージの種別、格納場所を管理する。図２にソフトウェアイメージ管理機能部２０２が持つソフトウェアイメージの管理情報テーブルの例を示す。ソフトウェアイメージは、サービス毎に一つ存在し、図２の例では、サービス「Ａ」がイメージ「Ａ」、サービス「Ｂ」がイメージ「Ｂ」を用いてサービスを開始する。また、イメージ「Ａ」、イメージ「Ｂ」の格納場所は、リソースマネージャ１０３のファイルシステム上の”／ｐａｔｈ／ｔｏ／ｉｍａｇｅＤｉｒ”であることを示している。本実施形態では、格納場所はリソースマネージャ１０３上のディスク等を想定しているが、リソースマネージャ１０３からアクセス可能であれば、実際の格納場所は外部ストレージなどでもよい。
【００２４】
サーバ状態管理機能部２０３は、リソースプール１２０内の資源であるサーバ１３０が現在どのサービスの提供に用いられているか、などのサーバ１３０の状態情報を管理する。
【００２５】
サーバ起動処理機能部２０４は、サーバの起動要求があった場合、サーバ状態監視機能部２０５の情報を参照し、リソースプール１２０内のどのサーバ１３０を用いるかを決定すると共に、該当サーバ１３０に対してソフトウェアイメージ管理機能部２０２が管理するソフトウェアイメージを転送し、起動する機能を持つ。また、サーバ起動処理機能部２０４は、スケールアウトの要求があった場合、サーバ状態監視機能部２０５の情報を参照し、リソースプール１２０内のどのサーバ１３０をスケールアウトに用いるかを決定すると共に、同一のサービスを既に行っているサーバ１３０に、スケールアウトに用いるサーバ１３０に対してソフトウェアイメージの断片の転送を要求し、起動する機能を持つ。
【００２６】
サーバ状態監視機能部２０５は、常にリソースプール１２０内のサーバ１３０の状態を監視し、サーバ状態管理機能部２０３を更新する機能を持つ。図４、図６、図９、及び図１２に、サーバ状態監視機能部２０５が持つサーバ状態の例を示す。図４では、サーバＩＤ「ＳＶ１」〜「ＳＶ６」の６つのサーバ１３０の状態は、全て待機中である。図６では、サーバＩＤが「ＳＶ１」、「ＳＶ２」のサーバ１３０がサービス「Ａ」の実行中であり、他のサーバは、待機中である。図９では、サーバＩＤが「ＳＶ１」，「ＳＶ２」のサーバ１３０が「サービス「Ａ」の実行中であり、サーバＩＤが「ＳＶ４」，「ＳＶ６」のサーバ１３０がサービス「Ｂ」の実行中であり、他のサーバは待機中である。図１２では、サーバＩＤが「ＳＶ１」，「ＳＶ２」のサーバ１３０が「サービス「Ａ」の実行中であり、サーバＩＤが「ＳＶ４」，「ＳＶ５」，「ＳＶ６」のサーバ１３０がサービス「Ｂ」の実行中であり、他のサーバは待機中である。
【００２７】
次に、リソースプール１２０内のサーバ１３０の構成機能部について述べる。サーバ１３０は、起動エージェント３０１と、ソフトウェアイメージ格納部３０２と、個別設定・データ格納部３０３と、計算処理機能部３０４とから構成される。
【００２８】
起動エージェント３０１は、リソースマネージャ１０３とサーバ１３０間の通信を行う。具体的には、サーバ起動処理機能部２０４からの起動指示を受け付けてソフトウェアイメージを取得する。また、サーバ状態監視機能部２０５からの状態問い合わせに対し、サーバ１３０上で実行中のサービス種別や待機中であることを伝える。また、サーバ起動処理機能部２０４からソフトウェアイメージの転送指示があると、他のサーバ１３０にソフトウェアイメージの断片を転送する。
【００２９】
ソフトウェアイメージ格納部３０２は、起動エージェント３０１が取得してきたソフトウェアイメージを格納する機能部である。ソフトウェアイメージは、サービス毎に存在するものであるが、サーバ１３０を起動してサービスを実行するために必要な設定情報は、個々のサーバ１３０毎に異なる場合がある。本システムでは、サーバ１３０個別の設定情報は取得したソフトウェアイメージを書き換えて保存するのではなく、個別設定・データ格納部３０３に格納する。また、サーバ１３０毎に違う出力を行うログ情報などのような個別データも、個別設定・データ格納部３０３に配置する。
【００３０】
計算処理機能部３０４は、通常の汎用サーバ１３０が持つＣＰＵ、主記憶などの演算装置であり、ソフトウェアイメージ格納部３０２と個別設定／データ格納部をディスクとしてシステムをブートし、サービス提供処理を行う。
【００３１】
次に、本発明の第１の実施形態のクラスタシステム１０２の動作について説明する。図３は、６つのサーバ１３０（サーバＩＤ「ＳＶ１」〜「ＳＶ６」）から構成されるリソースプール１２０を持つクラスタシステム１０２において、サービスが何も起動していない状態を示す。クラスタシステム１０２において、サービスが何も起動していない状態では、サーバ状態監視機能部２０５が持つサーバ状態情報は、図４に示すように、サーバＩＤ「ＳＶ１」〜「ＳＶ６」の６つのサーバ１３０の状態は、全て待機中になっている。以下、この状態から、サービス「Ａ」，サービス「Ｂ」が実行されている状態に遷移する際の処理について説明する。
【００３２】
図５は、６つのサーバ１３０（サーバＩＤ「ＳＶ１」〜「ＳＶ６」）が待機状態から、サービス「Ａ」が実行されている状態に遷移するときの処理を示すシーケンス図である。
【００３３】
リソースマネージャ１０３は、保守者端末１０１から、管理インタフェース経由でサービス「Ａ」のサーバ二台による起動要求を保守コマンドとして受け取ると（ステップＳ１０１）、サーバ起動処理機能部２０４がサーバ状態監視機能部２０５の情報を参照し、待機状態であるサーバ１３０を二つを選出する（ステップＳ１０２）。ここでは、サーバＩＤが「ＳＶ１」と「ＳＶ２」のサーバ１３０が選出されるとする。
【００３４】
サーバＩＤが「ＳＶ１」と「ＳＶ２」のサーバ１３０が選出されると、リソースマネージャ１０３のサーバ起動処理機能部２０４は、ソフトウェアイメージ管理機能部２０２からサービス「Ａ」の実行に必要なソフトウェアイメージであるイメージ「Ａ」を特定し、このイメージ「Ａ」を、選出されたサーバ１３０（サーバＩＤ＝ＳＶ１，ＳＶ２）の起動エージェント３０１に対して転送する（ステップＳ１０３ａ、Ｓ１０３ｂ）。選出されたサーバ１３０（サーバＩＤ＝ＳＶ１，ＳＶ２）上の起動エージェント３０１は、受信したイメージ「Ａ」をソフトウェアイメージ格納部３０２に保存する（ステップＳ１０４ａ、Ｓ１０４ｂ）。
【００３５】
リソースマネージャ１０３のサーバ起動処理機能部２０４は、ＩＰアドレスやネットマスク、ＤＮＳサーバなどのＩＰアドレスなどのネットワーク設定、バッファサイズや同時接続数などミドルウェアやＯＳのパラメータなど、サーバ１３０の起動前に変更する必要がある個別設定情報を、サーバＩＤが「ＳＶ１」と「ＳＶ２」のサーバ１３０上の起動エージェント３０１に渡すと（ステップＳ１０５ａ、１０５ｂ）、サーバＩＤが「ＳＶ１」と「ＳＶ２」のサーバ１３０上の起動エージェント３０１は、個別設定・データ格納部３０３にその個別設定情報を格納する（ステップＳ１０６ａ、１０６ｂ）。
【００３６】
その後、サーバＩＤが「ＳＶ１」と「ＳＶ２」のサーバ１３０の起動エージェント３０１は、計算処理機能部３０４に対してソフトウェアイメージと個別設定情報を用いてブートするように指示する。計算処理機能部３０４はブート後サービス「Ａ」を提供するサーバ１３０として動作する。
【００３７】
このように、サービス「Ａ」を提供するサーバ１３０が設定されると、サーバ状態監視機能部２０５のサーバ状態情報は、図６に示すように、リソースプール１２０内の６個のサーバ１３０（サーバＩＤが「ＳＶ１」〜「ＳＶ６」）のうち、サーバＩＤが「ＳＶ１」、「ＳＶ２」のサーバ１３０がサービス「Ａ」の実行中となり、他のサーバは、待機中となる。
【００３８】
次に、同様の手順で、サービス「Ｂ」の起動要求保守コマンドに対して、それぞれ、サーバＩＤが「ＳＶ４」，「ＳＶ６」上でサービス「Ｂ」を提供するサーバ１３０を起動すると、図７において、ステップＳ２０１〜ステップＳ２０６ａ、Ｓ２０６ｂに示すような処理が行われ、図８で示すような状態となる。このときのサーバ状態監視機能部２０５のサーバ状態情報は、図９に示すように、リソースプール１２０内の６個のサーバ１３０（サーバＩＤが「ＳＶ１」〜「ＳＶ６」）のうち、サーバＩＤが「ＳＶ１」，「ＳＶ２」のサーバ１３０がサービス「Ａ」の実行中となり、サーバＩＤが「ＳＶ４」，「ＳＶ６」のサーバ１３０がサービス「Ｂ」の実行中となり、他のサーバは、待機中となる。
【００３９】
続いて、この状態からサービス「Ｂ」をスケールアウトする手順について述べる。図１０は、サービス「Ｂ」をスケールアウトするときの処理を示すシーケンス図である。
【００４０】
リソースマネージャ１０３は、管理インタフェース経由でサービス「Ｂ」のスケールアウト要求の保守コマンドを受け取ると（ステップＳ３０１）、リソースマネージャ１０３のサーバ起動処理機能部２０４は、サーバ状態管理機能部２０３の情報を参照し、待機中のサーバ１３０を一つ選出する（ステップＳ３０２）。その選出方法としては、待機中状態のサーバ１３０を無作為に一つ選出する、テーブルのエントリーを順に確認していく中で最初に発見されたものを選出する等の単純な方法の他、サーバ起動処理機能部２０４が実ネットワークトポロジやリソースプール１２０内のサーバ１３０の物理的位置を把握しており、その情報を基に、現用中のサーバ１３０に対して最も通信遅延が少ないと判断できる（例えば、同一のハブに接続されている、または直接ネットワークケーブルで接続されている、など）サーバ１３０を選択するような方法も考えられる。
【００４１】
ここでは、待機中のサーバ１３０の中から、サーバＩＤが「ＳＶ５」のサーバ１３０がスケールアウトを行うサーバとして選ばれたとする。この場合、サーバＩＤが「ＳＶ５」のサーバ１３０は、イメージ「Ｂ」のソフトウェアイメージの転送が必要となる。通常のサーバ起動要求では、リソースマネージャ１０３のサーバ起動処理機能部２０４は、ソフトウェアイメージ管理機能部２０２からサービス「Ｂ」の実行に必要なソフトウェアイメージをサーバＩＤが「ＳＶ５」のサーバ１３０に直接転送しているが、スケールアウト時には、サーバ起動処理機能部２０４は、直接ソフトウェアイメージの転送を行わず、サービス「Ｂ」を提供しているサーバがイメージ「Ｂ」の断片を転送を要求する。
【００４２】
すなわち、この場合には、リソースマネージャ１０３のサーバ起動処理機能部２０４は、既にイメージ「Ｂ」を保有しているサーバ１３０（サーバＩＤ＝ＳＶ４，ＳＶ６）に対して、起動エージェント３０１にイメージ「Ｂ」の断片をそれぞれ転送するように指示する（ステップＳ３０３ａ、３０３ｂ）。
【００４３】
イメージ「Ｂ」を保有しているサーバ１３０（サーバＩＤ＝ＳＶ４，ＳＶ６）は、指示されたイメージ「Ｂ」の断片をサーバＩＤが「ＳＶ５」のサーバ１３０に転送する（ステップＳ３０４ａ、３０４ｂ）。その際に、各サーバ１３０が転送する断片の量は、等分である方法と重み付けを行うような方法が考えられる。等分に転送する場合、イメージ「Ｂ」の容量が１ＧＢであったとすると、サーバＩＤが「ＳＶ４」のサーバ１３０がイメージ「Ｂ」の先頭から半分である５００ＭＢまでのデータを、サーバＩＤが「ＳＶ６」のサーバ１３０がイメージ「Ｂ」の半分から末尾までの５００ＭＢをそれぞれサーバＩＤが「ＳＶ５」のサーバ１３０に対して転送する。
【００４４】
重み付けを行うような場合は、静的な各サーバの情報を用いる方法と動的に各サーバの処理負荷を考慮する方法が考えられる。前者は、各サーバが平均的に行っている処理負荷および有休資源（ＣＰＵ時間、ネットワーク帯域など）を、事前にサーバ起動処理機能部２０４が把握していることを前提とし、後者は起動エージェント３０１の申告によってその時のサーバの処理負荷及び有休資源をサーバ起動処理機能部２０４が把握する。そして、サーバＩＤが「ＳＶ４」のサーバ１３０の有休資源がサーバＩＤが「ＳＶ６」のサーバ１３０に比べて例えば３倍多かった場合、イメージ「Ｂ」の容量を１ＧＢとすると、サーバＩＤが「ＳＶ４」のサーバ１３０は先頭から７５０ＭＢを、サーバＩＤが「ＳＶ６」のサーバ１３０は残りの２５０ＭＢを断片としてサーバＩＤが「ＳＶ５」のサーバ１３０に転送する。
【００４５】
サーバＩＤが「ＳＶ５」のサーバ１３０の起動エージェント３０１は、受信したイメージ「Ｂ」をソフトウェアイメージ格納部３０２に保存する（ステップＳ３０５）。そして、リソースマネージャ１０３のサーバ起動処理機能部２０４は、ＩＰアドレスやネットマスク、ＤＮＳサーバなどのＩＰアドレスなどのネットワーク設定、バッファサイズや同時接続数などミドルウェアやＯＳのパラメータなど、サーバ１３０の起動前に変更する必要がある個別設定情報を、サーバＩＤが「ＳＶ５」のサーバ１３０上の起動エージェント３０１に渡すと（ステップＳ３０６）、サーバＩＤが「ＳＶ５」のサーバ１３０上の起動エージェント３０１は、個別設定・データ格納部３０３にその個別設定情報を格納する（ステップＳ３０７）。
【００４６】
その後、サーバＩＤが「ＳＶ５」のサーバ１３０の起動エージェント３０１は、計算処理機能部３０４に対してソフトウェアイメージと個別設定情報を用いてブートするように指示する。計算処理機能部３０４はブート後サービス「Ｂ」を提供するサーバ１３０として動作する。
【００４７】
スケールアウト時には、ステップＳ３０１〜ステップＳ３０７に示すような処理が行われ、図１１で示すような状態となる。このときのサーバ状態監視機能部２０５のサーバ状態情報は、図１２に示すように、リソースプール１２０内の６個のサーバ１３０（サーバＩＤが「ＳＶ１」〜「ＳＶ６」）のうち、サーバＩＤが「ＳＶ１」，「ＳＶ２」のサーバ１３０がサービス「Ａ」の実行中となり、サーバＩＤが「ＳＶ４」，「ＳＶ５」，「ＳＶ６」のサーバ１３０がサービス「Ｂ」の実行中となり、他のサーバは、待機中となる。
【００４８】
以上のように、スケールアウト時にリソースマネージャ１０３にソフトウェアイメージの転送負荷をかけないことにより、複数のサービスのスケールアウトを同時に高速に行うことが可能となる。
【００４９】
本発明は、上述した実施形態に限定されるものではなく、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。
【符号の説明】
【００５０】
１０１：保守者端末
１０２：クラスタシステム
１０３：リソースマネージャ
１１０：管理ネットワーク
１２０：リソースプール
１３０：サーバ
１４０：利用者端末
１５０：保守ネットワーク
１６０：サービスネットワーク
２０１：管理インタフェース
２０２：ソフトウェアイメージ管理機能部
２０３：サーバ状態管理機能部
２０４：サーバ起動処理機能部
２０５：サーバ状態監視機能部
３０１：起動エージェント
３０２：ソフトウェアイメージ格納部
３０３：データ格納部
３０４：計算処理機能部
【図１】
0005551967.tif 000002
【図２】
0005551967.tif 000003
【図３】
0005551967.tif 000004
【図４】
0005551967.tif 000005
【図５】
0005551967.tif 000006
【図６】
0005551967.tif 000007
【図７】
0005551967.tif 000008
【図８】
0005551967.tif 000009
【図９】
0005551967.tif 000010
【図１０】
0005551967.tif 000011
【図１１】
0005551967.tif 000012
【図１２】
0005551967.tif 000013