特許 6072072 クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6072072

(24)【登録日】2017年1月13日

(45)【発行日】2017年2月1日

(54)【発明の名称】クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム

(51)【国際特許分類】

   G06F 11/20 20060101AFI20170123BHJP

   G06F 9/50 20060101ALI20170123BHJP

   G06F 9/46 20060101ALI20170123BHJP

【ＦＩ】

   G06F11/20 633

   G06F9/46 462A

   G06F9/46 350

【請求項の数】8

【全頁数】21

(21)【出願番号】特願2014-551787(P2014-551787)

(86)(22)【出願日】2012年12月12日

(86)【国際出願番号】JP2012082215

(87)【国際公開番号】WO2014091580

(87)【国際公開日】20140619

【審査請求日】2015年5月14日

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】301063496

【氏名又は名称】東芝ソリューション株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】遠藤 浩太郎

【審査官】 井上 宏一

(56)【参考文献】

【文献】 特開２０１１− ３９７４０（ＪＰ，Ａ）

【文献】 特開２０１２−１０８６５１（ＪＰ，Ａ）

【文献】 特開２００７−２４９４７０（ＪＰ，Ａ）

【文献】 特表２００４−５３８５７３（ＪＰ，Ａ）

【文献】 特開２００４−２５９０９２（ＪＰ，Ａ）

【文献】 特開２００２− ２４１９２（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／２０

Ｇ０６Ｆ ９／４６ −９／５４

(57)【特許請求の範囲】

【請求項1】

クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もる見積部と、
前記サーバ装置の故障を検出する検出部と、
前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、
前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部と
を備えるクラウドシステム管理装置。

【請求項2】

前記クラウドシステムは、
前記可用性を必ず保証することが前記品質情報で定められている前記第１サービスプロセスが動作する第１サーバ装置で構成される第１クラスタと、
前記可用性を必ず保証することが前記品質情報で定められていない前記第２サービスプロセスが動作する第２サーバ装置で構成される第２クラスタと、
を含み、
前記決定部は、前記第１サーバ装置の故障が検出された場合に、前記第２サーバ装置のうち、前記第１サービスプロセスを再配置する前に前記再配置先の前記第２サーバ装置で動作していた前記サービスプロセスの前記違約情報の総和が小さい前記第２サーバ装置を優先して、前記第１サーバ装置で動作する前記第１サービスプロセスの再配置先に決定する
請求項１に記載のクラウドシステム管理装置。

【請求項3】

前記再配置部は、
更に、前記第２サービスプロセスを、他の前記第２サーバ装置に移すことにより再配置する
請求項２に記載のクラウドシステム管理装置。

【請求項4】

前記見積部は、
前記違約情報を、前記第２サービスプロセスの前記累積動作不能時間に、前記第２サービスプロセスを再配置する場合に要する前記第２サービスプロセスの前記動作不能時間を加算することにより見積もる
請求項１乃至３のいずれか１項に記載のクラウドシステム管理装置。

【請求項5】

前記第２サービスプロセスの前記品質情報は、前記第２サービスプロセスの性能情報を更に含み、
前記見積部は、
前記違約情報を、前記第２サービスプロセスを前記他の第２サーバ装置に移した場合に、前記第２サービスプロセスが前記他の第２サーバ装置のリソースを使用できる割合に応じて算出される処理時間により見積もる
請求項３に記載のクラウドシステム管理装置。

【請求項6】

少なくとも１つのサービスプロセスが動作する複数のサーバ装置と、
クラウドシステム管理装置と
を備えるクラウドシステムであって、
前記クラウドシステム管理装置は、
クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もる見積部と、
前記サーバ装置の故障を検出する検出部と、
前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、
前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部と
を備えるクラウドシステム。

【請求項7】

クラウドシステム管理装置が、クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もるステップと、
前記クラウドシステム管理装置が、前記サーバ装置の故障を検出するステップと、
前記クラウドシステム管理装置が、前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定するステップと、
前記クラウドシステム管理装置が、前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置するステップと
を含む再配置方法。

【請求項8】

コンピュータを、
クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もる見積部と、
前記サーバ装置の故障を検出する検出部と、
前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、
前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部と
して機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラムに関する。

【背景技術】

【0002】

近年、クラウドシステムにより提供されるサービス（以下「クラウドサービス」という。）を事業活動に採用する企業が増えている。クラウドサービスを利用するメリットのひとつは、システムのＴＣＯ（Ｔｏｔａｌ Ｃｏｓｔ ｏｆ Ｏｗｎｅｒｓｈｉｐ）の削減である。特に、運用管理コストが低減される点が注目される。また、システムの導入費用や更新費用等が、社内で構築するシステムに比べて大幅に削減されることも魅力のひとつである。

【0003】

クラウドサービスの利用によりＴＣＯが削減される根本的な理由のひとつとして、サーバ装置等のコンピュータ資源の有効利用が挙げられる。多数のサービスを提供しているクラウドサービスの事業者は、コンピュータ資源を効率的に各サービスに割り当てることにより、コンピュータ資源の総合的な利用率をあげることができる。

【0004】

これにより、クラウドサービスの事業者は、ユーザが、個別にシステムを所有するのに比べて安価なコストでサービスを提供できる。なお、従来の典型的なシステムでは、サービス毎にコンピュータ資源を固定的に割り当てる前提でシステムが設計されているため、多数のサービスプロセスを多数のコンピュータ上へ自在に配置できるようなシステム構成ではなかった。

【0005】

クラウドサービスの普及について、技術的な側面を見ると、仮想化技術の発展が大きく関与している。仮想化技術によって、物理的なコンピュータ資源を論理的な単位（仮想マシン）に分割して、サービスプロセスに割り当てることができる。これにより、コンピュータ資源のサービスへの割り当てを自在に行うことができるようになった。その結果、サービスの種類に関わらず、物理的コンピュータ資源の共有ができるようになり、最適配置の可能性が大きく広がった。

【0006】

クラウドシステムは多数のコンピュータで構成されるため、コンピュータの故障を想定した対策が必須である。一般的に、コンピュータの台数が大きくなればなるほど、クラウドシステムの中での故障の発生確率は大きくなる。例えば、コンピュータ単独の可用性が９９．９５％だとしても、コンピュータが１００００台あれば、全てのコンピュータが同時に動作する可用性は、１％に満たない。

【0007】

クラウドサービスの適用範囲が広がるにつれ、いわゆる社会インフラ・サービスのような、２４時間３６５日の安定的な運用が求められるサービスへの適用も検討されるようになってきた。一方、ビッグデータ分析のような、大量の計算資源を必要とするものの、必ずしも高信頼性や高可用性が絶対ではないクラウドサービスもある。

【0008】

例えば、２４時間３６５日の連続運転で１分以内のＭＴＴＲ（Ｍｅａｎ Ｔｉｍｅ Ｔｏ Ｒｅｐａｉｒ）の保証が要求される場合がある。一方、稼働率９９％程度のベストエフォートの可用性で十分な場合もある。また、可用性が重視されない例として、コンピュータ資源が余っているときに、当該コンピュータ資源を低価格で利用させるようなサービスもある。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２００５−０１１２３７号公報

【特許文献2】特開２００５−１００３８７号公報

【発明の概要】

【発明が解決しようとする課題】

【0010】

しかしながら、クラウドシステム内のサーバ装置が故障したとき、サービスプロセスが保証する品質に応じて、使用できるサーバ装置を、サービスプロセスに効率的に割り当てることが難しいという課題があった。

【課題を解決するための手段】

【0011】

実施形態のクラウドシステム管理装置は、クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もる見積部と、前記サーバ装置の故障を検出する検出部と、前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部とを備える。

【0012】

実施形態のクラウドシステムは、少なくとも１つのサービスプロセスが動作する複数のサーバ装置と、クラウドシステム管理装置とを備えるクラウドシステムであって、前記クラウドシステム管理装置は、クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もる見積部と、前記サーバ装置の故障を検出する検出部と、前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部とを備える。

【0013】

実施形態の再配置方法は、見積部が、クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もるステップと、検出部が、前記サーバ装置の故障を検出するステップと、決定部が、前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定するステップと、再配置部が、前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置するステップとを含む。

【0014】

実施形態のプログラムは、コンピュータを、クラウドシステム内のサーバ装置で動作するサービスプロセスについて定められている可用性を表す品質情報と、前記サービスプロセスを停止してから開始するまでの動作不能時間の和を示す累積動作不能時間と、に基づいて、前記サービスプロセスが、前記累積動作不能時間によって前記可用性を達成できない程度を表す違約情報を見積もる見積部と、前記サーバ装置の故障を検出する検出部と、前記故障が検出された前記サーバ装置で動作する第１サービスプロセスを再配置するときに、前記第１サービスプロセスを再配置する前に再配置先のサーバ装置で動作していた第２サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、前記第１サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部として機能させる。

【図面の簡単な説明】

【0015】

【図1】図１は、実施形態のクラウドシステムの構成の一例を示す図である。

【図2】図２は、実施形態のクラウドシステム管理装置の状況データの一例を示す図である。

【図3】図３は、実施形態のクラウドシステム管理装置の見積データの一例を示す図である。

【図4】図４は、実施形態のクラウドシステムの第１クラスタの一例を説明するための図である。

【図5】図５は、実施形態のクラウドシステムの第２クラスタの一例を説明するための図である。

【図6】図６は、実施形態のクラウドシステムの第２クラスタのサービスプロセスの再配置方法の一例を説明するための図である。

【図7】図７は、実施形態のクラウドシステム管理装置の第１クラスタのサービスプロセスの再配置方法の一例を説明するためのフローチャートである。

【図8】図８は、実施形態のクラウドシステムの第１クラスタのサービスプロセスの再配置方法の一例を説明するための図である。

【図9】図９は、実施形態のクラウドシステムの第１クラスタのサービスプロセスの再配置方法の一例を説明するための図である。

【図10】図１０は、実施形態のクラウドシステムの第１クラスタのサービスプロセスの再配置方法の一例を説明するための図である。

【図11】図１１は、実施形態のクラウドシステムの第１クラスタのサービスプロセスの再配置方法の一例を説明するための図である。

【図12】図１２は、実施形態のクラウドシステム管理装置の第１クラスタのサービスプロセスを再配置先するサーバ装置を決定する方法の一例を説明するためのフローチャートである。

【図13】図１３は、実施形態のクラウドシステムのクラウドシステム管理装置、及びサーバ装置のハードウェアの構成の一例を示す図である。

【発明を実施するための形態】

【0016】

一般に、クラウドサービスに要求される可用性、及び性能は、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）で定められている。ＳＬＡは、サービスを提供する事業者がサービスの提供品質をお客様に約束するものである。ＳＬＡにより、可用性や、平均応答時間等の性能等が保証される。なお、性能の保証についても可用性の場合と同様に、クラウドサービスの種類によって、その保証品質はさまざまである。

【0017】

ＳＬＡは、その保証の程度によって二つに大別することができる。ギャランティ型とベストエフォート型である。ギャランティ型は、要求された品質を約束する。ベストエフォート型は、品質の向上に最大の努力をすることを約束する。一般に、性能にギャランティ型の保証を必要とするサービスは、可用性においてもギャランティ型の保証を必要とする場合が多いと考えられる。

【0018】

ギャランティ型のサービスを提供するためは、最悪ケースを想定して余裕を持ってコンピュータ資源を割り当てておく必要があるため、コンピュータ資源の総合的な利用率が下がる傾向がある。一方、ベストエフォート型のサービスは、物理的なコンピュータ資源の総量を超えてコンピュータ資源を割り当てるオーバーコミットを行うことにより、コンピュータ資源の総合的な利用率を上げることが可能である。

【0019】

以下、実施形態のクラウドシステム管理装置、クラウドシステム、及びプログラムについて説明する。図１は、実施形態のクラウドシステム１００の構成の一例を示す図である。本実施形態のクラウドシステム１００は、クラウドシステム管理装置１０、サーバ装置３１ａ〜３１ｎ、及びサーバ装置３２ａ〜３２ｎを備える。サーバ装置３１ａ〜３１ｎは、クラウドシステム１００の運用開始時点では、第１クラスタ３３に使用されているものとする。また、サーバ装置３２ａ〜３２ｎは、クラウドシステム１００の運用開始時点では、第２クラスタ３４に使用されているものとする。第１クラスタ３３、及び第２クラスタ３４の詳細については後述する。

【0020】

なお、サーバ装置３１ａ〜３１ｎを区別しない場合は、サーバ装置３１という。また、サーバ装置３２ａ〜３２ｎを区別しない場合は、サーバ装置３２という。サーバ装置３１、及びサーバ装置３２は、任意の台数でよい。また、クラウドシステム１００は、クラウドサービス事業者が営利目的でクラウドサービスを提供するものであっても、プライベートクラウドシステムでもよい。

【0021】

クラウドシステム管理装置１０、サーバ装置３１ａ〜３１ｎ、及びサーバ装置３２ａ〜３２ｎは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）２０を介して互いに接続されている。また、クラウドシステム管理装置１０、サーバ装置３１ａ〜３１ｎ、及びサーバ装置３２ａ〜３２ｎは、ＬＡＮ２０、及びネットワーク４０を介して、クライアント装置５１ａ〜５１ｎに接続されている。なお、クライアント装置５１ａ〜５１ｎを区別しない場合は、クライアント装置５１という。

【0022】

クライアント装置５１は、ユーザがクラウドシステム１００のサービスを受けるために使用する装置である。クライアント装置５１は任意の装置でよい。例えば、クライアント装置５１は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）や、携帯端末等である。

【0023】

また、ネットワーク４０は、例えば、インターネットである。また、クラウドシステム管理装置１０、サーバ装置３１ａ〜３１ｎ、及びサーバ装置３２ａ〜３２ｎの一部が、他の拠点にある等の場合は、ＬＡＮ２０は、インターネットやＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等でもよい。

【0024】

クラウドシステム管理装置１０は、検出部１、記憶部２、見積部３、決定部４、及び再配置部５を備える。検出部１は、サーバ装置３１ａ〜３１ｎ、及びサーバ装置３２ａ〜３２ｎの故障を検出する。

【0025】

記憶部２は、状況データ６、及び見積データ７を記憶する。図２は、実施形態のクラウドシステム管理装置１０の品質達成状況データの一例を示す図である。状況データ６は、サービスプロセス名、品質情報、累積動作不能時間、及び違約情報を含む。サービスプロセス名は、サーバ装置３１（３２）で動作するサービスプロセスの名称である。品質情報は、サービスプロセスが保証する品質である。品質情報は、例えば、ＳＬＡにより定められる。当該品質は、サービスプロセスに適用される可用性や、性能等である。当該性能は、サービスプロセスの平均応答時間等である。累積動作不能時間は、サービスプロセスが動作不能になった時間の総和である。違約情報は、品質情報が達成できない程度を表す情報である。図２の例では、違約情報は違約金である。違約金は、例えば、品質情報で許される動作不能時間を越えた時間（以下「違約時間」という。）に、時間単価を乗じた分の料金で生成する。

【0026】

図２の具体例について説明する。サービスプロセスＡの品質情報は、サービスプロセスＡの累積動作不能時間が、１年間で５２分以内であることを示す。すなわち、見積部３は、累積動作不能時間が５２分を超えると違約情報を生成する。なお、サービスプロセスＡの累積動作不能時間は０分である。そのため、見積部３は、まだ違約情報を生成しない。

【0027】

サービスプロセスＢの品質情報は、サービスプロセスＢの累積動作不能時間が、１年間で３０分以内であることを示す。すなわち、見積部３は、累積動作不能時間が３０分を超えると違約情報を生成する。なお、サービスプロセスＢの累積動作不能時間は２９分である。そのため、見積部３は、まだ違約情報を生成しない。しかしながら、違約金が発生するまで、サービスプロセスＢを動作不能にできる時間は、あと１分である。

【0028】

サービスプロセスＮの品質情報は、サービスプロセスＮの累積動作不能時間が、１年間で４０分以内であることを示す。すなわち、見積部３は、累積動作不能時間が４０分を超えると違約情報を生成する。なお、サービスプロセスＮの累積動作不能時間は４２分である。そのため、見積部３は、違約時間（２分）に、違約時間の時間単価を乗じてＸＸＸ円の違約情報（違約金）を生成している。

【0029】

このように、クラウドシステム管理装置１０は、品質情報（例えばＳＬＡ）の達成状況を、状況データ６として定量化する。品質情報の達成状況の定量化は、サービスプロセス毎にする。サービスプロセス毎の達成状況は、サービスプロセス毎に随時、記憶部２に記録される。

【0030】

なお、違約情報の生成方法は、上述の方法に限られない。また、図２の品質情報は、サービスプロセスの可用性に関して定められているが、当該品質情報は、サービスプロセスの可用性に関するものに限られない。当該品質情報は、サーバ装置のリソースを使用できる割合等に応じて算出される処理時間（平均応答時間）等のサービスプロセスの性能に関する情報であってもよい。

【0031】

図３は、実施形態のクラウドシステム管理装置１０の見積データ７の一例を示す図である。見積データ７は、サービスプロセス名、及び予想違約情報を含む。サービスプロセス名は、サービスプロセスの名称である。予想違約情報は、サービスプロセスの累積動作不能時間に、サービスプロセスを再配置した場合の動作不能時間を加算して見積もられている。予想違約情報は、サービスプロセスを停止させてよいか否かの１つの指標として利用することができる。なお、予想違約情報の算出方法は、サービスプロセスの品質情報にあわせて任意に定めてよい。

【0032】

図１に戻り、見積部３は、サービスプロセスが保証する品質を表す品質情報に基づいて、サービスプロセスが、当該品質を達成できない程度を表す違約情報を見積もる。決定部４は、サーバ装置３１の故障等の理由によりサービスプロセスの再配置が必要になった場合に、再配置先となるサーバ装置を、再配置先のサーバ装置で動作する少なくとも１つのサービスプロセスの違約情報の総和が最小になるようにして決定する。

【0033】

再配置部５は、開始部８、及び停止部９を備える。再配置部５は、停止部９によりサービスプロセスを停止し、開始部８によりサービスプロセスを開始することにより、サービスプロセスを再配置する。一例として、サービスプロセスＡを、サーバ装置３１ａからサーバ装置３２ａに再配置する場合について説明する。まず、停止部９は、サーバ装置３１ａのサービスプロセスＡを停止する。次に、開始部８は、サーバ装置３２ａでサービスプロセスＡを開始する。これにより、再配置部５は、サービスプロセスＡを、サーバ装置３１ａからサーバ装置３２ａに移す（再配置する）。このとき、停止から開始までの間に経過した時間が、累積動作不能時間に加算されて記憶部２に記録される。なお、サーバ装置３１aの故障に伴う再配置の場合は、停止部９はサービスプロセスＡの停止を実際には行わないが、停止に要した時間のかわりに、サーバ装置３１aの故障検出に要した時間（たとえば、ハートビートのタイムアウト時間）を、累積動作不能時間に加算する。

【0034】

図４は、実施形態のクラウドシステム１００の第１クラスタ３３の一例を説明するための図である。第１クラスタ３３では、性能、又は可用性等が、品質情報で保証されるサービスプロセス（以下「第１サービスプロセス」という。）が動作する。

【0035】

第１クラスタ３３は、クラウドシステム１００を構成する複数のサーバ装置３１を論理的にひとまとめにした単位である。サーバ装置３１で動作する少なくとも１つのサービスプロセスは、クラウドシステム管理装置１０により固定的に配置される。すなわち、サーバ装置３１で動作する少なくとも１つのサービスプロセスは、所定の性能用件等の品質情報を必ず保証するようにして決定されたシステム設計に基づいたハードウェア、及びソフトウェア構成で動作する。

【0036】

第１クラスタ３３に含まれるサーバ装置３１が故障によって停止した場合、最初にホットスワップを行う。本実施形態のホットスワップは、第２クラスタ３４のサーバ装置３２の資源を開放して当該サーバ装置３２を未使用の状態にし、当該未使用のサーバ装置３２を第１クラスタ３３の故障サーバ装置３１と入れ替える。

【0037】

ホットスワップ対象のサーバ装置３２は、決定部４により決定される。決定部４は、第２クラスタ３２内でホットスワップの対象となるサーバ装置３２を、以下の２つの条件を満たすようにして決定する。第１の条件は、サーバ装置３２を故障したサーバ装置３１と入れ替えても、十分な性能を発揮できるようなコンピュータ資源を備えていることである。第２の条件は、サーバ装置３２を停止させた結果、サーバ装置３２で動作していたサービスプロセスで発生する違約情報が、最も小さいことである。

【0038】

このホットスワップによって、あたかも故障したサーバ装置３１が復旧し、代わりに第２クラスタ３４内のサーバ装置３２が故障したかのようにみなすことができる。つまり、ホットスワップ後、第１クラスタ３３では、元の配置と全く同じ配置でサービスプロセスが再開する。また、第２クラスタ３４では、サーバ装置３２が故障によって停止した場合と同様にして、サーバ装置３２で動作していたサービスプロセスの再配置を行う。

【0039】

図４の例では、サーバ装置３１ａでは、サービスプロセスＡ、及びサービスプロセスＢが動作している。サービスプロセスＡ、及びサービスプロセスＢを、同じホストで動作させることにより、サービスプロセスＡ、及びサービスプロセスＢとの間の通信速度を向上させている。これにより、クラウドシステム１００は、サービスプロセスＡ、及びサービスプロセスＢの性能を保証している。また、サービスプロセスＣは、サーバ装置３１ｂで単独で動作している。そのため、サービスプロセスＣは、サーバ装置３１ｂのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、及び通信Ｉ／Ｆ等のリソースを占有することができる。これにより、クラウドシステム１００は、サービスプロセスＣの性能を保証している。

【0040】

図５は、実施形態のクラウドシステム１００の第２クラスタ３４の一例を説明するための図である。第２クラスタ３４では、性能、又は可用性等が、品質情報で保証されないサービスプロセス（以下「第２サービスプロセス」という。）が動作する。第２サービスプロセスは、性能、又は可用性等が、可能な限り最大に発揮できるような環境で動作する。そのため、第２クラスタ３４のサーバ装置３２では、積極的にオーバーコミットを行い、コンピュータ資源の利用率を高めてもよい。すなわち、サーバ装置３２では、物理リソースよりも多い論理リソースを割り当ててもよい。

【0041】

第２クラスタ３４は、クラウドシステム１００を構成する複数のサーバ装置３２を、論理的にひとまとめにした単位である。サーバ装置３２で動作する少なくとも１つのサービスプロセスは、クラウドシステム管理装置１０により動的に配置される。クラウドシステム管理装置１０は、特定のアルゴリズムによって、動的にサービスプロセスを配置する。当該アルゴリズムは、サービスプロセスが使用するサーバ装置３２のリソース、負荷、及び余剰資源、並びに、サービスプロセスの品質情報（例えばＳＬＡ）、当該サービスプロセスが提供するサービスのコスト（価格等）、サービスプロセスの配置状況等の情報に基づいて決定される。クラウドシステム管理装置１０は、第２クラスタに含まれるサーバ装置３２が故障した場合、そのサーバ装置３２で動作していたサービスプロセスを、第２クラスタ３４の他のサーバ装置３２に再配置する。

【0042】

例えば、サービスプロセスＡが、第２サービスプロセスであるとする。そして、サービスプロセスＡが動作していたサーバ装置３２が故障したと仮定する。サーバ装置３２ａでは、サービスプロセスＢが動作している。サーバ装置３２ｂでは、サービスプロセスＣ、及びサービスプロセスＤが動作している。サーバ装置３２ｃでは、サービスプロセスＥ、及びサービスプロセスＦが動作している。このとき、再配置部５は、サービスプロセスＡを、その他のサービスプロセスの性能、又は可用性等への影響ができる限り少なくなるようにして再配置する。また、再配置部５は、サービスプロセスＡ自身の性能、又は可用性等が、可能な限り最大に発揮できるように再配置する。図５の例では、サービスプロセスＡの再配置先に、サービスプロセスＢのみが起動しているサーバ装置３２ａが選択されている。すなわち、この例の決定部４は、第２サービスプロセスが均等にサーバ装置３２に配置されるように、サービスプロセスＡの再配置先を決定している。なお、図５では、サービスプロセスをサービスプロセスＡ〜Ｆとして区別して説明しているが、ここでのサービスプロセスＡ〜Ｃは、図４のサービスプロセスＡ〜Ｃとは関係しない。以下、図６、及び８〜１１においても同様である。

【0043】

図６は、実施形態のクラウドシステム１００の第２クラスタのサービスプロセスの再配置方法の一例を説明するための図である。図６の例では、サーバ装置３２ａでは、サービスプロセスＡ、及びサービスプロセスＢが動作している。サーバ装置３２ｂは、故障したことを示す。なお、サーバ装置３２ｂでは、サービスプロセスＣ、及びサービスプロセスＤが動作していたものとする。サーバ装置３２ｃは、サービスプロセスＥ、及びサービスプロセスＦが動作している。

【0044】

図６の例では、再配置部５は、サーバ装置３２ｂで動作していたサービスプロセスＣを、サーバ装置３２ｃに再配置する。また、再配置部５は、サーバ装置３２ｂで動作していたサービスプロセスＤを、サーバ装置３２ａに再配置する。すなわち、図６の例では、再配置部５は、サーバ装置３２ｂで動作していたサービスプロセスを、他のサーバ装置３２に均等に再配置している。これにより、第２クラスタで動作するサービスプロセスの性能、又は可用性等が、可能な限り最大に発揮できるようにしている。

【0045】

次に、実施形態のクラウドシステム管理装置１０の第１クラスタ３３のサービスプロセスの再配置方法について説明する。図７は、実施形態のクラウドシステム管理装置１０の第１クラスタ３３のサービスプロセスの再配置方法の一例を説明するためのフローチャートである。また、図８〜１０は、実施形態のクラウドシステム１００の第１クラスタ３３のサービスプロセスの再配置方法の一例を説明するための図である。

【0046】

まず、検出部１が、第１クラスタ３３内のサーバ装置３１の故障を検出する（ステップＳ１）。図８の場合を例にして説明する。図８の例では、第１クラスタ３３は、サーバ装置３１ａ、及びサーバ装置３１ｂを備える。また、第２クラスタ３４は、サーバ装置３２ａ、サーバ装置３２ｂ、及びサーバ装置３２ｃを備える。

【0047】

図８の例では、サーバ装置３１ａでは、サービスプロセスＡ、及びサービスプロセスＢが動作している。サーバ装置３１ｂは、故障したことを示す。検出部１は、サーバ装置３１ｂの故障を検出する。なお、サーバ装置３１ｂでは、サービスプロセスＣ、及びサービスプロセスＤが動作していたものとする。また、サーバ装置３２ａでは、サービスプロセスＧが動作している。サーバ装置３２ｂでは、サービスプロセスＨ、及びサービスプロセスＥが動作している。サーバ装置３２ｃでは、サービスプロセスＪ、及びサービスプロセスＫが動作している。

【0048】

図７に戻り、決定部４が、故障が検出されたサーバ装置３１と、ホットスワップするサーバ装置３２（再配置先のサーバ装置３２）を決定する（ステップＳ２）。図９の場合を例にして説明する。図９の例は、決定部４が、サーバ装置３１ｂのサービスプロセスの再配置先のサーバ装置３２を、サーバ装置３２ｂに決定した場合の例である。なお、決定部４による再配置先のサーバ装置３２の決定方法（ステップＳ２）の詳細は後述する。

【0049】

クラウドシステム１００は、ホットスワップの対象となった第１クラスタ３３のサーバ装置３１を、ホットスワップ後、第２クラスタ３４のサーバ装置３２として認識する。また、クラウドシステム１００は、ホットスワップの対象となった第２クラスタ３４のサーバ装置３２を、ホットスワップ後、第１クラスタ３３のサーバ装置３１として認識する。図１０は、クラスタシステム１００が、再配置先のサーバ装置３２ｂを、第１クラスタとして利用することを示している。また、クラスタシステム１００が、故障したサーバ装置３１ｂを、第２クラスタとして認識することを示している。なお、故障したサーバ装置３１ｂは、軽微な故障である等の理由で復旧可能であれば、復旧後に第２クラスタで利用される。

【0050】

図７に戻り、再配置部５は、再配置先のサーバ装置３２のサービスプロセス（第２サービスプロセス）を停止する（ステップＳ３）。再配置部５は、再配置されたサービスプロセス（第１サービスプロセス、及び第２サービスプロセス）を開始する（ステップＳ４）。図１１の場合を例にして説明する。図１１の例では、再配置部５が、再配置が必要になった第１サービスプロセス（サービスプロセスＣ、及びサービスプロセスＤ）を、決定部４により決定されたサーバ装置３２ｂに移している。また、再配置部５が、再配置先のサーバ装置３２ｂで動作していた第２サービスプロセス（サービスプロセスＨ）を、サーバ装置３２ａに移している。また、再配置部５が、再配置先のサーバ装置３２ｂで動作していた第２サービスプロセス（サービスプロセスＥ）を、サーバ装置３２ｃに移している。

【0051】

図１１の例では、再配置が必要になった第１サービスプロセス（サービスプロセスＣ、及びサービスプロセスＤ）が動作していたサーバ装置３１ｂが、第２クラスタが使用していたサーバ装置３２ｂにホットスワップされている。これにより、クラウドシステム管理装置１０は、第１クラスタの第１サービスプロセスの品質（可用性、又は性能等）を保ちながら、第１サービスプロセスを再配置することができる。

【0052】

なお、本実施形態のクラウドシステム１００は、品質を必ず保証することが品質情報で定められている第１サービスプロセスが動作するサーバ装置３１で構成される第１クラスタと、品質を必ず保証することが品質情報で定められていない第２サービスプロセスが動作するサーバ装置３２で構成される第２クラスタを含んでいる。しかしながら、クラウドシステム１００は、このような区別をせずにクラスタを１つにしてもよい。この場合は、クラウドシステム管理装置１０は、各サーバ装置３１（３２）で動作するサービスプロセスの品質情報に応じて、クラスタの種類によらずにサーバ装置３１（３２）単位で個別に判定してサービスプロセスを再配置する。

【0053】

また、逆に、クラスタシステム１００は、より詳細にクラスタを区別してもよい。例えば、第２サービスプロセスが動作する第２クラスタ３４を、サービスプロセスが保証する品質を表す品質情報に応じて、第２クラスタ３４と第３クラスタに分けてもよい。すなわち、クラウドシステム管理装置１０に、サービスプロセスに要求される品質を、閾値等により定量的に判定する機能を追加する。そして、クラウドシステム管理装置１０は、当該閾値が所定の値以上のサービスプロセスは、第２クラスタ３４のサーバ装置３２に割り当てる。また、クラウドシステム管理装置１０は、当該閾値が所定の値より小さいサービスプロセスは、第３クラスタのサーバ装置に割り当てる。当該機能は、例えば、見積部３に追加してもよい。また、クラウドシステム管理装置１０は、第３クラスタのリソースのオーバーコミット率（割り当て済み論理リソース／物理リソース）の上限を、第２クラスタのリソースのオーバーコミット率の上限よりも大きくしてもよい。また、クラウドシステム管理装置１０は、第２クラスタの利用料金を、第３クラスタの利用料金よりも高くしてもよい。決定部４が、ホットスワップの対象として、どちらのクラスタを選ぶかは、その時点でのオーバーコミット率が、オーバーコミット率の上限にどの程度到達しているかを比較することによって、決定してもよい。

【0054】

また、再配置部５は、再配置先のサーバ装置３１（３２）で動作しているサービスプロセスを、他のサーバ装置３１（３２）に移さなくてもよい。このような場合としては、例えば、品質情報が、サービスプロセスの処理時間等である場合がある。違約情報は、当該処理時間に応じて決定される。再配置先のサーバ装置３１（３２）にリソースに余裕がある場合は、再配置先のサーバ装置３１（３２）に、サービスプロセスが追加されても、違約情報を生成する必要がない。このような場合は、再配置部５は、再配置先のサーバ装置３１（３２）で動作しているサービスプロセスを、他のサーバ装置３１（３２）に移さなくてもよい。

【0055】

図１２は、実施形態のクラウドシステム管理装置１０の第１クラスタ３３のサービスプロセスを再配置先するサーバ装置３２を決定する方法の一例を説明するためのフローチャートである。

【0056】

見積部３は、第２クラスタ３４内のサーバ装置３２から、サーバ装置ｈを１つ選択する（ステップＳ１１）。見積部３は、サーバ装置ｈのサービスプロセスＳを１つ選択する（ステップＳ１２）。見積部３は、サービスプロセスＳを再配置した場合の違約情報を見積もる（ステップＳ１３）。見積部３は、サーバ装置ｈのサービスプロセスＳを全て選択したか否かを判定する（ステップＳ１４）。サーバ装置ｈのサービスプロセスＳを全て選択した場合は、見積部３は、当該見積もりの合計Ｇ_ｈを算出する（ステップＳ１５）。サーバ装置ｈのサービスプロセスＳを全て選択していない場合は、ステップＳ１２に戻る。見積部３は、第２クラスタ３４内のサーバ装置３２を全て選択したか否かを判定する（ステップＳ１６）。第２クラスタ３４内のサーバ装置３２を全て選択した場合は、決定部４は、合計Ｇ_ｈが最小となるサーバ装置ｈを選択する（ステップＳ１７）。なお、ステップＳ１７において、決定部４は、必ずしも合計Ｇ_ｈが最小となるサーバ装置ｈを選択しなくてもよい。例えば、決定部４は、他の指標も鑑みて、合計Ｇ_ｈが小さいサーバ装置ｈを優先するに留めてもよい。第２クラスタ３４内のサーバ装置３２を全て選択していない場合は、ステップＳ１１に戻る。

【0057】

次に、違約情報の見積方法の一例について説明する。サービスプロセス毎の違約情報の見積もりは、例えば、過去１年間の動作不能時間に、再配置にかかる予想処理時間を加えた値、及び品質情報（例えば、ＳＬＡ）に基づいて計算することができる。ここで、再配置にかかる予想処理時間は、過去の実績値の平均により見積もる。具体的には、再配置にかかる処理時間の過去の実績値の平均は、サービスプロセス毎に記憶部２に記録されている動作不能時間を、再配置回数で割ることによって得ることができる。なお、過去に一度も再配置が行われていない場合には、再配置の実績値は無いので、事前に評価しておいた結果等を使ってもよい。または、再配置対象のサービスプロセスと同様の他のサービスの実績値を使ってもよい。

【0058】

なお、再配置後の違約情報の見積もりが最小となるサーバ装置３２（ホットスワップ対象のサーバ装置３２）が複数あった場合（例えば、違約情報が０で並ぶ等）は、その中から最適な対象サーバ装置３２を選択するために、再配置後にサーバ装置３２が更に故障した場合の違約情報の期待値も見積もる。このようにしてサーバ装置３２を選べば、再配置後の違約情報が最小となるだけでなく、再配置後にサーバ装置３２が、更に故障した場合が考慮された違約情報の期待値も最小となるようにして、サーバ装置３２を選ぶことができる。

【0059】

以下では、違約情報の見積もりが最小のサーバ装置３２（再配置先のサーバ装置３２の候補）が複数あった場合に、更に違約情報の期待値を見積もる方法の一例について説明する。

【0060】

第２クラスタ３４内のサーバ装置３２の総数をＮとし、各サーバ装置３２には１からＮの番号が振られているとする。各サーバ装置ｈ_ｋ（１≦ｋ≦Ｎ）が、再配置先のサーバ装置３２に選ばれた後、第２クラスタ３４内のサーバ装置３２が故障した場合の違約情報の期待値を算出する。

【0061】

なお、以下の説明では、各サーバ装置ｈ_ｋ（１≦ｋ≦Ｎ）が、故障する確率は、同一であると仮定する。また、各サーバ装置ｈ_ｋ（１≦ｋ≦Ｎ）が故障する確率は、十分に小さいと考えることができるとして、同時に複数台のサーバ装置ｈ_ｋが故障する場合の違約情報の期待値を０とみなす。すなわち、二点故障の確率は相当小さいので、一点故障までの違約情報の期待値が、違約情報の期待値の主要部であるとみなす。決定部４は、当該主要部が最小であるサーバ装置ｈ_ｋを再配置先に決定する。

【0062】

まず、使用する記号について説明する。ｓを第２クラスタ３４のサーバ装置３２で動作しているサービスプロセスとする。ｇ（ｎ，ｓ）を、サービスプロセスｓを見積もり基準時からｎ回再配置したときの違約情報の見積もり値とする。具体的には、例えば、過去１年間の動作不能時間に、ｎ回分の再配置の予想処理時間を加えた値から、品質情報で約束された値（例えば５２分）を引いて違約時間を見積もる。次に、この違約時間に応じた違約情報（例えば違約金）を算出し、当該違約情報をｇ（ｎ，ｓ）とする。なお、ｇ（０，ｓ）は、サービスプロセスｓの見積もり基準時の違約情報であることを示す。

【0063】

ｎ回再配置したときの違約情報の増加分Ｇ（ｎ，ｓ）を、次式（１）により定義する。

【0064】

【数1】

【0065】

ここでは、計算を簡易的に行うため、サーバ装置ｈ_ｋは全て同一機種であるとする。すなわち、Ｇ（ｎ，ｓ）は、サービスプロセスが配置されるサーバ装置ｈ_ｋに関係なく見積もれるものとする。

【0066】

サーバ装置ｈ_ｋのサービスプロセスｓを、他のサーバ装置３２に移した後（１回再配置した後）の全てのサービスプロセスｓの違約情報は、次式（２）で表すことができる。

【0067】

【数2】

【0068】

ここでＨ_ｋは、サーバ装置ｈ_ｋで動いていたサービスプロセスの集合である。なお、式（２）の第１項は、サーバ装置ｈ_ｋで動作していたサービスプロセスｓの違約情報の総和を示す。また、式（２）の第２項は、サーバ装置ｈ_ｋ以外のサーバ装置３２で動作しているサービスプロセスｓの違約情報の総和を示す。式（２）は、以下のようにして式（３）に変形することができる。

【0069】

【数3】

【0070】

つまり、サーバ装置ｈ_ｋのサービスプロセスｓを、他のサーバ装置３２に移した後の全てのサーバ装置３２のサービスプロセスｓの違約情報は、見積もり基準時の違約情報（第１項）と、サーバ装置ｈ_ｋ上のサービスプロセスｓを１回再配置することによる違約情報の増加分（第２項）の和である。式（３）のｋに依存する項は、第２項のみであることがわかる。

【0071】

再配置後の違約情報の見積もりが最小となるサーバ装置３２が複数ある場合（例えば、違約情報が０で並ぶ等）は、式（３）の第２項が最小（同一）となるサーバ装置ｈ_ｋが複数あることを示す。したがって、更に違約情報の見積もりの期待値を算出する場合は、次式（４）が同一であると仮定してよい。

【0072】

【数4】

【0073】

各サーバ装置ｈ_ｋ（１≦ｋ≦Ｎ）について、サーバ装置ｈ_ｋが再配置先のサーバ装置３２に選ばれた後、第２クラスタ３４内のサーバ装置３２が故障した場合の違約情報の期待値を算出する。当該違約情報の期待値は、サーバ装置ｈ_ｉ（１≦ｉ≦Ｎ）のいずれか１台の故障により発生するサービスプロセスｓの違約金の増加分の期待値を、式（１）に加算した次式（５）により算出できる。

【0074】

【数5】

【0075】

ここで、ｐはサーバ装置ｈ_ｉの故障確率とする（サーバ装置ｈ_ｉの故障確率を全て同一であると仮定している。）。／Ｈ_ｉ（ただし、“／”は上線であることを示す。）は、再配置後（ホットスワップを一回した後）にサーバ装置ｈ_ｉで動いていたサービスプロセスの集合である。／Ｇ（ｓ）（ただし、“／”は上線であることを示す。）は、サービスｓの違約情報の増加分である。

【0076】

／Ｇ（ｓ）は、次式（６）で表すことができる。

【0077】

【数6】

【0078】

式（５）は、次のようにして式（７）に変形することができる。

【0079】

【数7】

【0080】

式（７）の第３項（式（４））は、違約情報の期待値の評価対象となっているサーバ装置ｈ_ｋの間で同じである。したがって、ｋに依存する項は、式（７）の第１項のみである。すなわち、決定部４は、次式（８）により算出された値が、最小となるサーバ装置ｈ_ｋを決定すればよい。

【0081】

【数8】

【0082】

式（８）は、故障確率ｐや、各サービスプロセスｓの再配置先のサーバ装置３２に関係なく、値が確定できるため、実際に計算可能である。上記の計算を踏まえると、再配置後に２回（２台）以上サーバ装置ｈ_ｋが故障する場合にも、次式（９）を、違約情報の期待値の見積もりの値の評価に利用できることがわかる。

【0083】

【数9】

【0084】

すなわち、式（８）が同一の値となる場合（例えば、０で並ぶ場合）は、式（９）でｎ＝３として、更にもう１回、見積もり基準時のサーバ装置ｈ_ｋ（１≦ｋ≦Ｎ）で動作していたサービスプロセスｓが再配置の対象となった場合を評価する。見積部３は、このようにして、ｎの値を増やして式（９）を評価することにより、違約情報の期待値を見積もる。決定部４は、当該違約情報の期待値により、ホットスワップの対象となるサーバ装置ｈ_ｋを決定する。

【0085】

本実施形態のクラウドシステム管理装置１０によれば、クラウドシステム１００内のサーバ装置３１（３２）が故障したとき、見積部３、決定部４、及び再配置部５により、サービスプロセスが保証する品質に応じて、使用できるサーバ装置３１（３２）を、サービスプロセスに効率的に割り当てることができる。

【0086】

また、本実施形態のクラウドシステム管理装置１０によれば、品質の要求レベルの異なる品質情報（例えばＳＬＡ）を有するサービスプロセスを、クラウドシステム１００により効率的に運用することができる。

【0087】

（その他の実施形態）
その他の実施形態のクラウドシステム管理装置１０、及びクラウドシステム１００について説明する。上述の実施形態のクラウドシステム１００は、サーバ装置３１（３２）は、全て使用されていた。その他の実施形態のクラウドシステム１００として、余剰リソースとして予備サーバ装置がある場合について説明する。

【0088】

予備サーバ装置は、第２クラスタ３４のサーバ装置として利用される。ただし、予備サーバ装置で動作するサービスプロセス（以下「予備サービスプロセス」という。）が保証する品質は、第２クラスタ３４のサーバ装置３２よりも更に低いものとする。例えば、予備サービスプロセスは、サーバ装置３１（３２）で故障が発生したら、すぐに停止しても差し支えのないサービスプロセスである。したがって、決定部４が、予備サーバ装置３１を、ホットスワップの対象に決定しても、予備サービスプロセスは、他のサーバ装置３１（３２）や、他の予備サーバ装置に移さなくてもよい。決定部４は、第１クラスタのサーバ装置３１が故障した際には、まず、予備サーバ装置を、ホットスワップの対象に決定する。

【0089】

本実施形態のクラウドシステム管理装置１０、及びクラウドシステム１００は、クラウドシステム１００のリソースに余裕がある場合でも、サービスプロセスが保証する品質に応じて、クラウドシステム１００のリソースを効率的に割り当てることができる。

【0090】

次に、実施形態のクラウドシステム１００のクラウドシステム管理装置１０、及びサーバ装置３１（３２）のハードウェアの構成の一例について説明する。図１３は、実施形態のクラウドシステムのクラウドシステム管理装置、及びサーバ装置のハードウェアの構成の一例を示す図である。以下では、クラウドシステム管理装置１０の場合を例にして説明する。

【0091】

本実施形態のクラウドシステム管理装置１０は、制御部６１、主記憶部６２、補助記憶部６３、表示部６４、入力部６５、及び通信Ｉ／Ｆ部６６を備える。制御部６１、主記憶部６２、補助記憶部６３、表示部６４、入力部６５、及び通信Ｉ／Ｆ部６６は、バス６７を介して互いに接続されている。

【0092】

制御部６１は、補助記憶部６３から主記憶部６２に読み出されたプログラムを実行する。主記憶部６３は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメモリである。補助記憶部６３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や光学ドライブ等である。表示部６４は、クラウドシステム管理装置１０の状態等を表示する画面である。表示部６は、例えば液晶ディスプレイである。入力部６５は、クラウドシステム管理装置１０を操作するためのインタフェースである。入力部６５は、例えばキーボードやマウス等である。通信Ｉ／Ｆ部６６は、ネットワークに接続するためのインタフェースである。

【0093】

本実施形態のクラウドシステム管理装置１０で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されてコンピュータ・プログラム・プロダクトとして提供される。

【0094】

また、本実施形態のクラウドシステム管理装置１０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態のクラウドシステム管理装置１０で実行されるプログラムをインターネット等のネットワーク経由で提供、又は配布するように構成してもよい。

【0095】

また、本実施の形態のクラウドシステム管理装置１０のプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

【0096】

本実施形態のクラウドシステム管理装置１０で実行されるプログラムは、上述した各機能ブロック（検出部１、見積部３、決定部４、及び再配置部５）を含むモジュール構成となっている。当該各機能ブロックは、実際のハードウェアとしては、制御部６１が上記補助記憶部６３等からプログラムを読み出して実行することにより、上記各機能ブロックが主記憶部６２上にロードされる。すなわち、上記各機能ブロックは、主記憶部６２上に生成される。

【0097】

なお、上述した各部（検出部１、見積部３、決定部４、及び再配置部５）の一部、又は全部を、ソフトウェアにより実現せずに、ＩＣ等のハードウェアにより実現してもよい。また、記憶部２は、例えば、補助記憶部６３である。なお、補助記憶部６３により実現する記憶部２のデータを、主記憶部６２に展開してもよい。

【0098】

以上説明したとおり、実施形態のクラウドシステム管理装置１０によれば、クラウドシステム１００内のサーバ装置３１（３２）が故障したとき、見積部３、決定部４、及び再配置部５により、サービスプロセスが保証する品質に応じて、使用できるサーバ装置３１（３２）を、サービスプロセスに効率的に割り当てることができる。

【0099】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0100】

１ 検出部
２ 記憶部
３ 見積部
４ 決定部
５ 再配置部
６ 状況データ
７ 見積データ
８ 開始部
９ 停止部
１０ クラウドシステム管理装置
２０ ＬＡＮ
３１a〜３１ｎ，３１ サーバ装置
３２a〜３２ｎ，３２ サーバ装置
３３ 第１クラスタ
３４ 第２クラスタ
４０ ネットワーク
５１a〜５１ｎ，５１ クライアント装置
６１ 制御部
６２ 主記憶部
６３ 補助記憶部
６４ 表示部
６５ 入力部
６６ 通信Ｉ／Ｆ
６７ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】