JP5951111B2 - 管理計算機、計算機システム、及びインスタンス管理方法 - Google Patents

Description

本発明は、管理計算機、計算機システム、及びインスタンス管理方法に関し、例えば、仮想サーバおよび物理サーバが混在する計算機システムにおいて、リソースの割り当てを管理するための技術に関する。

サーバ仮想化技術が普及し、企業情報システムを構築するための複数の仮想サーバを単一のハードウェア上に統合することが一般的となった。仮想サーバは、単一の物理サーバ（仮想サーバホスト）が提供するリソースを共有しているため、同じ仮想サーバホスト上の他の仮想サーバから性能上の影響を受ける。性能上の影響（例えば、処理負荷の増減）は、処理の目的や種類を把握できなければ予測が困難である。例えば、処理負荷の増減の場合、例えば一方の仮想サーバの処理負荷が高まるにつれ、他方の仮想サーバでは処理リソースが奪われ、性能劣化を招く可能性がある。この点、１つの仮想サーバホスト上に１つの仮想サーバのみを稼働させることにより、この性能影響を排除することができる。ところが、サーバ仮想化機能を実装しているハイパバイザの処理がオーバヘッドとなり、物理サーバの全てのリソースを活用することができない。特に、科学技術計算やビジネスインテリジェンスなど運用管理の容易性よりも計算性能を優先する分野では、処理のオーバヘッドが許されない。その他、一般の仮想サーバ環境には、ハイパバイザという抽象化層を設ける分だけ構造の複雑性が増し、管理の負担が増大したり、ハイパバイザ自体の導入費用も必要であったり、さらには１つのハイパバイザや仮想サーバホストの障害が複数のシステムに波及する恐れがあるという短所がある。

そこで、仮想サーバが存在する環境であっても、ハイパバイザを有さない物理サーバをそのまま処理環境として利用する運用方法が考えられる。そのような物理サーバはベアメタルサーバと呼ばれ、１つのハードウェア装置が持つ処理性能を全て活用することができ、さらに他のサーバから影響を受けることなく安定稼働させることができる。また、ベアメタルサーバは、従来主流であった運用方法であり、管理ソフトウェアなど充分に信頼性の高い既存技術および資産を活用することもできる。

一方、サーバ上にあってアプリケーションに提供するためのリソースを制御するＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ（ＯＳ）は、ハードウェア抽象化層と呼ばれる内部構造を持ち、ある程度の互換性を満たせば、別の物理ハードウェア上で稼働させることができる。そのため、例えば仮想サーバ内に稼働していたアプリケーションおよびそのデータを、互換性を満たす場合に限り、ＯＳごとベアメタルサーバへ移行できる。同様にしてベアメタルサーバから仮想サーバへの移行も可能であり、一般にＰ２Ｖ(Physical to Virtual)／Ｖ２Ｐ(Virtual to Physical)と呼ばれるそれら移行機能を実装したソフトウェアが提供されている。

以上のサーバ仮想化技術、ベアメタルサーバ運用管理技術、および移行技術の組み合わせにより、仮想サーバ、ベアメタルサーバが任意に混在する環境で業務システムを運用できる可能性が示唆される。そのような環境では、リソース利用効率を重視する場合は仮想サーバで、処理性能や稼働の安定性を重視する場合はベアメタルサーバで、という業務システムの要件に合わせて好適な処理基盤を使い分ける運用が実現できる。特許文献１では、そのような運用を実現する技術の１つとしてシステムを仮想サーバからベアメタルサーバへ移行する方法が開示されている。

一方で、近年の傾向として、クラウドコンピューティングの隆盛がある。クラウドでは多数のサーバを仮想化によりプラットフォームに集約、統合管理することで運用管理コストを削減し、情報システムへの依存度の高まりに応えている。そのようなクラウドの特長の１つとして、ユーザのセルフサービスを強化している点が挙げられ、クラウド運用管理における標準と認知されている。

特にＩａａＳ（Infrastructure as a Service）クラウドにおいては、情報システムを構築するユーザ自身により、サーバインスタンス（以下単にインスタンス）と呼ばれる処理環境の作成、および構成変更が行われる。インスタンスは一般的には１つの仮想サーバにあたり、ユーザはそこにＯＳとアプリケーションを導入し、所望のシステムを構築する。すなわち、従来はユーザから要件を聞き出して管理者が行っていた作業をユーザへ委譲し、ユーザ自身のセルフサービスによる環境構築が実現されるようになったと言える。これにより、管理者の作業負担が軽減され、またユーザは所望の環境を迅速に構築することができる。

このセルフサービスを実現するにあたって重要な仕組みの１つがサーバのマシン構成を記述したカタログである。ユーザは、自身の構築したいシステムの要件について、アプリケーションの視点では知識を持っているものの、どのようなマシン構成が適切か、さらにそれらを稼働させる装置全体の構成については、管轄外であるためよく知らない場合が多い。そこで、管理者は、仮想サーバの用途や物理リソースのサイジングなどの要因を考慮し、サーバの典型的な構成をカタログとして複数パターン作成し、ユーザに提示する。一方、ユーザはそれらカタログを基にインスタンスを作成する。カタログが厳密にはユーザのシステムに対し最適な構成でなくとも、ユーザは実際の運用を始めてから、必要に応じてインスタンスをカスタマイズし、その時の処理負荷に見合ったマシン構成へ調整することができる。これにより、ユーザは自身の導入するアプリケーションに向く構成を独自に判断して選択できるようになり、管理者にとっても仮想サーバを作成する度にユーザに要件を確認する作業が不要となるため管理を省力化できる。さらに、特に仮想サーバについては動的なリソース追加や仮想サーバホストの変更が比較的容易に行えるため、物理装置の処理負荷に応じて自動的に構成を変更する技術により、ユーザに意識させることなくシステムのリソース利用効率を高めることができる。特許文献２は、このような自動構成変更の技術について開示している。

また、カタログは、ＩａａＳクラウドを利用するユーザと、インスタンスをサービスとして提供するプロバイダ（管理者含む）の間にあって、インスタンスに対するユーザ側の要件と、プロバイダがインスタンスを提供する上での条件を明確化する仕組みであるとも言える。カタログに記載する事項は、ユーザとプロバイダとの関係によって異なるものの、多くの場合、インスタンスの構成（インスタンスに割り当てられるリソース）と利用可能な管理機能の記述が含まれる。それらの記述は、クラウド基盤となるハードウェアおよびソフトウェアの構成および機能に依存するため、全くの任意というよりは、インスタンスの用途や基盤の構成に基づいて数段階の水準が設けられる場合が多い。本明細書では、この割り当てられるリソースの種類・量、および管理機能について設定されるインスタンスの水準を、サービスレベルと呼ぶこととする。

そして、前述のベアメタルサーバをクラウド環境で提供すれば、仮想サーバの場合と同じくユーザのセルフサービスにより高性能・高品質のサーバインスタンスを提供できると考えられる。

特開２００９−１４５９３１号広報 特開２０１１−１１８５２５号広報

しかしながら、ベアメタルサーバをサーバインスタンス（ベアインスタンス、物理インスタンスとも言う）として提供する場合、仮想サーバとの属性の違いから、カタログには仮想サーバとは異なる項目が記述されたり、割り当てられるリソース量や適用可能な管理機能が異なったり、といった差異が生じる。これらの差異は、一方では多様なサービスレベルを提供できるという利点と捉えられるが、他方ではベアメタルサーバの運用管理について専門的な知識を持たないユーザを困惑させるものになる恐れがある。ユーザは、サーバ構成を拡張したい場合、仮想インスタンスであれば設定ファイルの書き換え等により簡単に拡張できるが、ベアインスタンスの場合、ダイナミックな変更が簡単にできないからである。

したがって、処理需要に対する性能が満たされていない、あるいは処理需要に対して性能が余剰であると感じても、どの種類のリソースをどれだけ増減させればよいか判断することがユーザにとって困難である。例えば、仮想サーバにおいて同じアプリケーションを利用し、同じような処理をさせているのにも拘わらず、時期によって所要時間が変動する場合、ベアメタルサーバに移行するのがよいのか、仮想リソースの追加で充分であるかは、ユーザには判断できない。これは、カタログなどの抽象化構造によって、サーバインスタンスと物理装置の対応関係が隠蔽化されたために生じる。より具体的には、ユーザは自身が利用している仮想サーバがどの仮想サーバホスト上で稼働し、他にどのような負荷傾向を持つ仮想サーバとリソースを共有しているのかを知らされていないためである。

ユーザによるセルフサービス（例えば、アプリケーションを使いたいユーザが自らインスタンスのスペックを決めて展開させたり、アプリケーションの処理負荷に応じてサーバの構成の変更をユーザが決定したりすること）を実現するためには、ユーザ自身が、所望のアプリケーションに見合った構成を選べるように、適切なサービスレベルを、それを運用するために必要なコストと合わせて提示するシステムが必要となる。ここでいうコストとは、インスタンスの運用管理に必要となる作業に対して、ユーザが支払う対価のことを指す。このように、多くのクラウド環境では、利用可能なリソースや機能に対する上限値や価格が設定されている。そのため、ユーザは所望のアプリケーションを稼働させるために十分な性能を持つインスタンスを利用したいと考える反面、余剰のリソース利用を削減してコストを効率化したいという欲求を抱えている。

本発明はこのような状況に鑑みてなされたものであり、サーバリソースの利用効率の向上とコスト削減とのバランスを考慮したサーバインスタンスの設定・変更を可能にする技術を提供するものである。

上記課題を解決するために、本発明では、管理サーバ（管理計算機）は、ユーザの構成変更要求や、性能劣化或いは性能余剰の検出結果に基づく構成変更要求に応じて、性能影響の要因を判定し、性能影響を解消し得る適切な移行先候補を算出する。ここで、管理サーバは、各サーバ装置、ネットワーク装置、ストレージ装置の性能情報を取得し、履歴として保持している。また、管理サーバは、取得した性能情報をもとに、性能が低下している要因や部位を特定する。さらに、管理サーバは、性能低下を緩和する方策を算出し、インスタンスの構成変更の候補となる装置の情報を取得し、装置互換性（デバイスドライバの有無など）を確認した上で移行先候補を決定する。

つまり、本発明は、複数の物理サーバと、少なくとも１つのストレージ装置と、それらを管理する管理計算機と、を有する計算機システムに関する。管理計算機は、物理サーバ上のインスタンスの構成情報と、物理サーバ及びストレージ装置の性能情報と、をメモリ上に保持している。そして、管理計算機は、インスタンスの構成変更の要求に応答して、性能情報を参照し、構成変更対象のインスタンスが設定されている対象物理サーバにおいて、当該構成変更対象のインスタンスが他のインスタンスとの間で処理需要が競合しているか判定する性能競合判定処理と、当該性能競合判定処理の結果に基づいて、構成変更の対象のインスタンスの構成変更方法の候補を生成する候補生成処理と、生成された構成変更方法の候補をユーザ（クライアント計算機）に提供する候補提供処理と、を実行する。

ここで、少なくとも１つの物理サーバは、仮想化機構を有し、当該物理サーバのリソースを分割してインスタンスに割り当て、仮想インスタンスとして機能させる、第１種サーバである。また、第１種物理サーバ以外の少なくとも１つの物理サーバは、当該物理サーバのリソースの全てをインスタンスに割り当て、物理インスタンスとして機能させる、第２種サーバとなっている。そして、管理計算機は、構成変更方法の候補として、仮想インスタンス、及び／又は物理インスタンスの構成を提示する。

本発明によれば、サーバリソースの利用効率の向上とコスト削減とのバランスを考慮して、サーバインスタンスの設定・変更が可能となる。

本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。

本発明の第１の実施形態による計算機システムの物理構成を示す図である。 本発明の実施形態による物理的なシステムユニット構成の一例を示す図である。 本発明の実施形態による計算機システムの論理構成を示す図である。 本発明の第１の実施形態１によって実現される機能の概念を示す図である。 本発明の実施形態による改善方策リストの構成例を示す図である。 本発明の実施形態による管理プログラムを構成する要素を示す図である。 本発明の実施形態におけるインスタンス管理テーブルの構成例を示す図である。 本発明の実施形態例における移行条件管理テーブルの構成例を示す図である。 本発明の実施形態におけるデバイス管理テーブルの構成例を示す図である。 本発明の第１の実施形態における移行方策算出処理を説明するためのフローチャート（１）である。 本発明の第１の実施形態における移行方策算出処理を説明するためのフローチャート（２）である。 本発明の第２の実施形態におけるカタログ検索方法の概念を説明するための図である。 本発明の第３の実施形態における移行条件管理テーブルの構成例、及び移行管理部の構成例を示す図である。

以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。

本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。また、実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以後の説明では「ａａａテーブル」、「ａａａリスト」等の表現にて本発明の情報を説明するが、これら情報はテーブル、リスト、ＤＢ、キュー等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」等について「ａａａ情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについては互いに置換が可能である。

以後の説明では、サービスレベル判定部や移行管理部等の「各処理部」を主語として説明を行う場合があるが、各処理部の実行内容はプログラムの一部或いは全部としてプロセッサによって実行されるため、プロセッサを主語とした説明としてもよい。また、各処理部（プログラム）の一部または全ては専用ハードウェアによって実現されてもよい。

以後、計算機システムを管理し、本発明の表示用情報を表示する１つ以上の計算機の集合を管理システムと呼ぶことがある。管理コンピュータが表示用情報を表示する場合は管理コンピュータが管理システムである。また、管理コンピュータと表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理コンピュータと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

（１）第1の実施形態
第１の実施形態は、ユーザの要求に応じて性能影響の要因を特定し、その結果に応じて適切な移行方策の候補を提示するシステムに関する。

＜計算機システムの構成＞
図１は、本発明の第１の実施形態例による計算機システムの物理的概略構成を示す図である。本計算機システムは、それぞれ少なくとも１つの、第１の物理サーバ１０と、第２の物理サーバ２０と、ストレージ装置１００と、クライアントコンピュータ５１０と、管理サーバ（管理コンピュータ）５００と、を備え、さらにそれらを相互に接続するネットワーク５１およびネットワーク６１を備えている。

第１の物理サーバ１０は、ＣＰＵ１１と、メモリ１２と、ファイバチャネルインタフェース（ＦＣ ＩＦ）１５と、およびイーサネット（以下、登録商標）インタフェース（Ｅｔｈｅｒ ＩＦ）１６と、を備える。メモリ１２には少なくともＯＳ１３ａが格納され、ＣＰＵ１１の演算処理によって物理サーバ１０で稼働するアプリケーション１３ｂに対し処理リソースを提供する機能を実現する。以降、特に仮想化プログラムが稼働せず、ＯＳ１３ａが物理サーバ１０上で直接的に稼働するという意味で、物理サーバ１０をベアメタルサーバと呼ぶこともある。ＦＣ ＩＦ１５は、ネットワーク５１を介して他の装置と通信を行うためのものであり、主にストレージ資源を接続する目的で使用される。同じ目的を達成する相互接続の手段である限りにおいてファイバチャネル以外の通信規格を使用してもよく、また、用途によって複数あってもよい。Ｅｔｈｅｒ ＩＦ１６は、ネットワーク６０を介して他の装置と通信を行うためのものであり、他の物理サーバ１０及び２０、クライアントコンピュータ５１０や管理コンピュータ５００と接続する目的で使用される。同じ目的を達成する相互接続の手段である限りにおいてイーサネット以外の通信規格に準拠するものであってもよく。また、用途によって複数あってもよい。

第２の物理サーバ２０は、ＣＰＵ２１と、メモリ２２と、ＦＣ ＩＦ２５と、Ｅｔｈｅｒ ＩＦ２６と、を備える。メモリ２２には少なくともＯＳ２３ａおよび仮想化プログラム２３ｂが格納され、ＣＰＵ２１の演算処理によって物理サーバ２０を１つ以上のリソース領域に分割してその他のＯＳまたはアプリケーション２３ｃへ提供する機能を実現する。仮想化プログラム２３ｂは必ずしもＯＳ２３ａと分離される必要はなく、物理サーバ２０を１つ以上のリソース領域に分割する機能を備える限りにおいて、ＯＳ２３ａ内部の１つのモジュールとして実装されてもよいし、またはＯＳ２３ａそのものとして実装されてもよい。以降、仮想化プログラム２３ｂの機能を実装したものをハイパバイザと呼ぶことがある。また、仮想化プログラム２３ｂの機能により、物理サーバ２０のハードウェアの一部が、閉じたリソース領域として切り出される。このリソース領域は仮想マシンと呼ばれる１つの論理的なサーバのハードウェアを構成しており、第２の物理サーバ２０を仮想マシンホストと呼ぶこともある。ＦＣ ＩＦ２５、及びＥｔｈｅｒ ＩＦ２６についての詳細は、第１の物理サーバの場合と同様である。

ネットワーク５１は、１つ以上の物理サーバ１０及び２０と、１つ以上のストレージ装置１００を相互に接続するためのものである。これにより、物理サーバ１０、２０がストレージ装置１００と通信し、アプリケーション１３ｂ、２３ｃなどが稼働する際に必要なストレージ資源を利用可能とする。ネットワーク５１上には１つ以上のファイバチャネルスイッチ（ＦＣ ＳＷ）５０が介在してもよい。ＦＣ ＳＷ５０の構成は、Ｅｔｈｅｒ ＩＦ５６が接続されたネットワーク６１を介して、管理コンピュータ５００により設定される。

ネットワーク６１は、主に以下の３つの目的のために使用される。第１の目的は、クライアントコンピュータ５１０と物理サーバ１０および２０との間のサービス通信を提供することである。例えば、物理サーバ１０はクライアントコンピュータ５１０から処理要求や処理対象のデータを受信し、アプリケーション１３ｂにより加工または生成されたデータを再度クライアントコンピュータ５１０に向け送信する。第２の目的は、サービス通信に関わる物理サーバ１０および２０の構成変更を行うことである。例えば、物理サーバ２０上に新たなアプリケーション２３ｃを導入したり、仮想化プログラム２３ｂ上に仮想サーバと呼ばれるリソース領域を作成したりといったことが行われる。第３の目的は、物理サーバ１０、２０とストレージ装置１００との間のデータネットワーク５１について構成を変更することである。例えば、ストレージ装置１００のストレージ制御部１５０を通じて、ボリュームと呼ばれるストレージ資源の単位を作成し、物理サーバとの論理的な通信路を設定することで、ストレージ資源を利用可能とする。

ストレージ装置１００は、複数の物理ストレージデバイス１０１を集積したものであり、装置を集中的に制御するストレージ制御部１５０を備えており、物理サーバ１０及び２０など他の装置に対してデータ格納用のストレージ資源を提供する。図１に示すように、物理ストレージデバイス１０１は、例えばハードディスクドライブ（ＨＤＤ）であり、他にもソリッドステートドライブと呼ばれる不揮発性の記憶デバイスが用いられる。ストレージ制御部１５０は、ＣＰＵ１５１と、メモリ１５２と、キャッシュ１５４と、ＦＣ ＩＦ１５５と、Ｅｔｈｅｒ ＩＦ１５６と、Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔインタフェース（ＳＡＴＡ ＩＦ）１５７と、を備える。メモリ１５２には、少なくとも読み書き要求に応答する応答プログラム１５３ａ、及び装置の論理構成を制御するストレージ制御プログラム１５３ｂを含む、プログラムが格納されている。これらのプログラムがＣＰＵ１５１によって演算処理されることによりストレージ装置１００の機能が実現される。キャッシュ１５４は、主に物理サーバの読み書き要求に対するストレージ資源の応答性能を向上させるために用いられる。ＦＣ ＩＦはネットワーク５１を介して他の装置と通信を行うためのものであり、主に物理サーバ１０、２０と接続する目的で使用される。同じ目的を達成する相互接続の手段である限りにおいてファイバチャネル以外の通信規格を使用してもよく、また、物理サーバの台数などによって複数あってもよい。Ｅｔｈｅｒ ＩＦ１６は、ネットワーク６０を介して他の装置と通信を行うためのものであり、主に管理コンピュータ５００と接続する目的で使用される。

管理コンピュータ５００は、ＣＰＵ５０１と、メモリ５０２と、Ｅｔｈｅｒ ＩＦ５０６と、を備え、主に他の装置の構成を変更する機能を有する。メモリ５０２には、少なくとも管理コンピュータのハードウェアを制御するＯＳ５０３ａ、および管理プログラム５０３ｂが格納される。これらＯＳやプログラムがＣＰＵ５０１によって演算処理されることにより管理コンピュータ５００の機能が実現される。管理プログラム５０３ｂは、管理コンピュータ５００が許容する処理能力を超えない限り、用途に応じて複数稼働してもよい。管理プログラム５０３ｂの詳細については後述する。Ｅｔｈｅｒ ＩＦ５０６は、ネットワーク６０を介して他の装置と通信を行うためのものである。

クライアントコンピュータ５１０は、物理サーバ１０及び２０上のアプリケーションプログラムが提供するサービスを享受するためのものであり、ユーザによって操作される。クライアントコンピュータ５１０は、ＣＰＵ５１１と、メモリ５１２と、Ｅｔｈｅｒ ＩＦ５１６と、を備える。メモリ５１２には、少なくともクライアントコンピュータのハードウェアを制御するＯＳ５１３ａ、およびクライアントプログラム５１３ｂが格納される。これらＯＳやプログラムがＣＰＵ５１１によって演算処理されることによりクライアントコンピュータ５１０の機能が実現される。クライアントプログラム５１３ｂは、物理サーバ上のアプリケーションプログラムと通信して、サービス処理の要求、処理結果の表示を行ったり、あるいは管理コンピュータ５００上の管理プログラム５０３ｂと通信して、ユーザが許可された範囲でのシステムの構成変更を行ったり、といったユーザインタフェースの機能を提供する。なお、クライアントプログラム５１３ｂは、上記機能を実現するものである限り、他のプログラムと連携するための特別な実装であってもよいし、適切な通信プロトコルが使用されていればＷｅｂブラウザのように汎用的なプログラムであってもよい。

＜計算機システムの物理的配置例＞
上述の通り、図１は本発明の実施形態による計算機システムの一般的な物理構成を示すが、物理装置の配置について、より具体的には例えば図２のようになる。図２は、図１に示す計算機システムを構成する各装置をラックに搭載した物理的配置、及びそれらのネットワーク結線を示す図であり、全体で１つのシステムユニットを構成する。システムユニットは運用管理の基本的な単位であり、必要に応じて複数のシステムユニットを組み合わせることでデータセンタを構築できる。データセンタ内に多数の装置が設置されている昨今、システムユニットは装置を秩序立てて配置・接続し、管理する重要な概念である。本実施形態におけるシステムユニットは、計算ラック６５０、及びストレージラック６５１から構成される。それら計算ラック６５０やストレージラック６５１は、図２のように１つずつであるとは限らず、必要なリソース量に応じて複数あってもよい。ただし、計算ラック６５０内に搭載される管理サーバ６５３は、１つのシステムユニット全体を管理対象とするよう構成されなければならない。

計算ラック６５０は、主にインスタンスを稼働させるためのサーバ装置（サーバシャーシ６５２）と、各装置を制御する管理装置（管理サーバ６５３）を搭載する。図２の例では、ブレード型のサーバ装置を搭載しており、サーバシャーシ６５２に搭載したサーバブレード６５２ａ上でインスタンスを稼働させる。これらサーバ装置は同一の構成を持つものに限定せず、システムユニット内で複数種類のものが存在してもよい。サーバシャーシ６５２には、イーサネットスイッチモジュール６５２ｂやファイバチャネルスイッチ６５２ｃなど、各装置がモジュール化されて搭載される。また、計算ラック６５０には、システムユニットに含まれる各装置を管理する管理サーバ６５３と、ストレージ装置を集中的に制御するストレージ制御ユニット６５４が搭載される。さらに、各装置を相互に接続するためのイーサネットスイッチを集めたイーサスイッチユニット６５６、及びファイバチャネルスイッチを集めたファイバチャネルスイッチユニット６５７が搭載される。その他には、ラック内の各装置に電源を供給するための電力供給ユニット６５５が搭載される。

一方、ストレージラック６５１には、主に物理ストレージデバイス（例えばＨＤＤ１０１）を集積したストレージディスクユニット６５８が搭載される。ストレージディスクユニット６５８は、ストレージ制御ユニット６５４と合わせてストレージ資源を提供する機能を実現している。ストレージディスクユニット６５８とストレージ制御ユニット６５４は、図２のように搭載されるラックが別であってもよく、また必要とされる容量や性能に応じて複数のストレージラックにまたがって設置されてもよい。ストレージラック６５１にもイーサスイッチユニット６５６、及びファイバチャネルスイッチユニット６５７が搭載され、ラック内にある装置を接続する役割と、他のラックと接続する役割を担う。その他には、ラック内の各装置に電源を供給するための電力供給ユニット６５５が搭載される。

上述の各物理装置は、システムユニット内で固定であるよう構成される一方、各装置を相互に接続するネットワーク配線もシステムユニット内部で閉じており、原則的には変更されない。ただし、他のシステムユニットへインスタンスを移行するなど、複数のシステムユニットが連携する必要が生じる場合に備え、ネットワークスイッチ間にシステムユニット間通信路が設置される。しかし、基本的に、あるシステムユニット内の装置を直接的に他のシステムユニットの装置と接続したり、あるいは他のシステムユニットの管理サーバ６５３から管理させることはない。例えば物理故障の場合に装置を交換する際、あるいは装置更改に伴う移行作業の際という例外があるものの、通常はシステムユニット内で閉じた運用管理が行われる。

管理サーバ６５３は、単一のシステムユニット全体について、物理的な構成情報を保持している。これは、物理的な経路情報を保持していることに等しい。例えば、サーバブレード６５２ａの計算ラック番号が分かれば、同じシステムユニット内のストレージラック番号を調べることで、接続先のストレージディスクユニット６５８が容易に特定できる。また、同じシャーシ番号やラック番号を有するサーバ同士は、互いの位置が物理的に近く、レイテンシ（遅延）が小さいと言える。前述のとおり、原則的にシステムユニットにおける物理構成は固定的であるため、初期導入時や装置更改の際に装置構成を調査していれば、接続構成を永続的に把握できる。例えば、ハイパバイザやＯＳに構成管理エージェントを導入し定期的に構成情報を収集する、などの特別な解析手段を用いる必要はない。

＜計算機システムの論理的構成、及びインスタンスの作成手順＞
（i）論理的構成
図３は、本発明の実施形態による計算機システムの論理構成を示す図である。図３は、システム運用中にユーザがサーバを新たに作成する場面を想定している。

図３において、ユーザが利用するアプリケーション１３ｂ及び２３ｃは、ネットワーク６１を介してクライアントコンピュータ５１０上のクライアントプログラム５１３ｂと通信し、業務サービスを提供する。アプリケーションは、ベアメタルサーバ１０であれば直接的にハードウェアで稼働するＯＳ１３ａ上にあり、仮想マシンホスト２０であればハイパバイザ２３ｂ上で稼働する仮想マシンのさらに内部で稼働するＯＳ２３ｄ上にある。以下、論理的なサーバの単位であり、アプリケーションおよびＯＳを導入可能なリソース領域をインスタンスと呼ぶこととする。特に、ベアメタルサーバ上にあれば物理インスタンス、仮想マシンホスト２０上にある仮想マシンであれば仮想インスタンスと呼ぶ。本実施形態において、ユーザは、所望のインスタンスを作成および構成変更し、所望のＯＳやアプリケーションを導入して、目的の業務システムを構築する。

各インスタンスが使用するストレージ資源は、ストレージ装置１００により提供される。図３に示すように、物理インスタンスの場合はストレージ装置１００内にあるボリューム１６０と呼ばれる単位で提供される。物理インスタンス１４のＯＳ１３ａからはボリューム１６０が１つの物理ディスクドライブとして認識される。また、仮想インスタンスの場合、ハイパバイザ２３ｂが接続したボリューム１６０内でファイル形式の仮想ディスク１６１を作成し、仮想インスタンスに接続する。さらに、ハイパバイザ２３ｂは仮想ディスク１６１内に仮想的なボリューム１６２を定義しており、仮想インスタンス２４のＯＳ２３ｄからは仮想的なボリューム１６２が物理ディスクドライブとして認識される。また、仮想インスタンスにはオーナが設定されていて、オーナさえ同一であればどのクライアントコンピュータからでも該当する仮想インスタンスを用いることができるようになっている。

物理インスタンス１４とボリューム１６０の接続経路、あるいはハイパバイザ２３ｂとボリューム１６０の接続経路は、ＯＳ１３ａやハイパバイザ２３ｂによって設定される。ただし、それらの接続経路の設定は、ネットワーク５１の物理的な結線、及び論理的な接続により通信経路が構成された範囲内でのみ可能である。物理的な結線は、ネットワークに参加する装置に備えられたＦＣＩＦ上のポート５２を、ファイバチャネルケーブルにより接続することで実施される。論理的な接続は、ＦＣ ＳＷ５０において設定するものと、ストレージ装置１００において設定するものの２つがある。ＦＣ ＳＷ５０ではゾーニングと呼ばれる技術が用いられ、通信可能なスイッチ上のポートの組を設定する方法、およびポート５２の識別子（ＷＷＮ）により通信可能なノードを設定する方法が提供されている。一方、ストレージ装置１００においては、ボリューム１６０にアクセス可能なストレージ制御部１５０上のポートを設定する方法、および当該ストレージ側ポートと通信可能な物理サーバのＷＷＮを設定する方法が提供されている。これらＦＣ ＳＷ５０の設定およびストレージ装置１００の構成は、後述する各装置管理部により管理・制御される。

また、図３は管理コンピュータ５００で稼働する管理プログラム５０３ｂ（図１参照）の詳細を示す。本実施形態において、管理プログラム５０３ｂの種類は次に挙げるものである。すなわち、管理コンピュータ５００は、クライアントコンピュータ５１０から要求を受け付けるサービス管理部５０４ａと、サービスレベルの維持・変更に関する機能を備える統合サービスレベル管理部５０４ｂと、統合サービスレベル管理部５０４ｂのもとで各装置の管理を行うサーバ管理部５０４ｃと、ネットワーク管理部５０４ｄと、ストレージ管理部５０４ｅと、を備える。これら各管理部５０４ａ乃至ｅは、プログラムによって構成される。サービス管理部５０４ａは、クライアントコンピュータからユーザの要求を受信し、インスタンスの作成や構成変更を行う。統合サービスレベル管理部５０４ｂは、サービス管理部５０４ａより受けた要求に従って、インスタンスに割り当てられたリソースの性能や品質の水準を維持する役割（性能が下がったときにはリソースの拡張やサーバの移行を実行し、負荷が下がって利用効率が下がったときには利用効率の低いインスタンスの構成を縮小する）を担う。実際に装置と物理サーバやストレージ装置と直接的に接続して、個々の構成変更を行う処理は、サーバ管理部５０４ｃ、ネットワーク管理部５０４ｄ、ストレージ管理部５０４ｅによる。便宜上、これらを総称して装置管理部と呼ぶことにする。これらの装置管理部は、装置の論理的な構成情報を取得および変更することで、管理対象の装置を制御する。本実施形態においては、これらの装置管理部が互いに通信して異なる装置の構成を把握することはできず、異種装置間の連携は各装置管理部の上位に位置する統合サービスレベル管理部５０４ｂによってのみ実現される。なお、本実施形態では、ユーザの指示によってインスタンスの構成変更（拡張、移行、縮小）を実行するようにしているが、インスタンスに割当てられたリソースの性能品質が所定の閾値を超えた場合にインスタンスを自動的に構成変更して性能や品質の水準を維持するようにしても良い。

（ii）セルフサービスによるインスタンス作成
上述の各構成の機能を説明する具体例として、本実施形態による構成において（仮想）インスタンスを作成する手順を述べる。なお、ここで説明するインスタンス作成の手順および技術は既知のものである。

ユーザは、クライアントコンピュータ５１０上のクライアントプログラム５１３ｂを操作し、管理コンピュータ５００にアクセスする。管理コンピュータ５００上のサービス管理部５０４ａは、ユーザ名とパスワードなどの識別情報を用いて、当該ユーザにインスタンスの作成権限があることを認証する。一般に、ユーザは所属する組織のグループアカウントと関連付けられており、グループごとに作成可能なインスタンスの数や、割り当て可能なリソースの量や物理装置が事前に決定されている。

ユーザの権限が認証されると、サービス管理部５０４ａはインスタンスの雛形となる１つ以上のカタログをユーザに対して提示する。カタログには、ＣＰＵ、ＲＡＭ、ネットワークアダプタ、ディスク容量、ＯＳなどの構成や、高可用性オプションなど適用される管理機能についての詳細が記述されている。ユーザは提示されたカタログの中から所望のものを選択し、選択したカタログからインスタンスを作成するようサービス管理部５０４ａに対して要求する。必要であれば、サービス管理部５０４ａが許容するサービスレベルの範囲で、カタログに記載されたものから構成を一部変更（カスタマイズ）して要求する。

サービス管理部５０４ａは、ユーザからクライアントプログラム５１３ｂを経由してインスタンスの作成要求を受けると、インスタンスの作成処理を行う。インスタンスの作成処理は、配置先物理サーバ／ボリュームの決定や、仮想リソースの作成、ＯＳイメージのコピーといった手順を含む。このうち、配置先物理サーバ／ボリュームの決定は、配置先のリソース空き容量や、他の構成変更タスクとの兼ね合いを考慮して行われる。また、物理的な結線や物理ボリューム１６０のマウントなど、複数種類の装置を跨る構成変更は事前に行われており、インスタンスを作成するときには、たかだか構成管理ファイルの作成や仮想ディスクファイルの作成など、ハイパバイザ２３ｂが有する構成変更機能のみが使用される。また、インスタンスが利用する仮想ディスクのうち、特にＯＳ領域については、再利用可能なＯＳセットアップ済み仮想ディスク（ＯＳイメージ）を用意しておき、インスタンスの作成時にはそのＯＳイメージの論理コピーすることで、ＯＳのインストールを不要化する技術もある。

インスタンスの作成が完了すると、サービス管理部５０４ａは、当該インスタンスが利用可能状態となったことをユーザに通知する。その後、ユーザは所望のアプリケーションのインストーラ（ＩＳＯディスクイメージなど）をインスタンスに転送し、業務システムの構築を行うことができる。

＜サービスレベルの変更＞
本発明は、特にインスタンスに割り当てるリソースの管理において、サービスレベルの変更に着目してなされたものである。本実施形態により、ユーザの構成変更要求に対して、適切な移行方策の候補を提示するシステムが提供される。

図４は、本発明の実施形態において提供される機能の概念を示す図である。例えば、仮想インスタンス７０７を使用しており、同インスタンスの性能が低下している場合を考える。仮想マシンホストおよびベアメタルサーバが混在する環境において、仮想インスタンス７０７の処理性能を改善する方策は、主に以下の３通りの方策が考えられる。

第１の方策は、同じ仮想マシンホスト２０上でリソース割り当て量を増やすスケールアップ７０４であり、仮想マシンホスト２０に空きリソースがある場合は比較的容易に実行できる。しかし、同じ仮想マシンホスト上の他の仮想インスタンスから性能影響を受けていた場合、性能を改善することができない。

第２の方策は、当該仮想インスタンス７０７を他の仮想マシンホストへ移行するＶ２Ｖ移行７０５であり、移行元の仮想マシンホストにおいて他の仮想サーバから計算リソースに対する性能影響を受けていた場合に有効である。ディスクＩＯに対する性能影響を受けていた場合は、仮想ディスク７１１をボリューム７１３へ変換することにより、性能が改善する可能性がある。しかしながら、移行先の仮想マシンホストにおいて、負荷傾向が同じような仮想インスタンスが他に存在した場合には、Ｖ２Ｖ移行７０５を実施しても性能が改善しない恐れがある。また、ディスクＩＯに対する性能影響が、実態として重大でなかった場合、仮想ディスク７１１をボリューム７１３へ変換しても、性能低下が解消されない。

第３の方策は、仮想インスタンス７０７をベアメタルサーバ１０上に移行し、物理インスタンス７１０に変換するＶ２Ｐ移行７０６である。このＶ２Ｐ移行７０６によれば、他のインスタンスの性能影響を排除し、インスタンスの安定稼働を実現できる。しかしながら、一般にＶ２Ｐ移行は、所要時間が長時間であったり、ＯＳのシャットダウンが必要であったりという短所を伴う。

ユーザは、当該仮想インスタンスの物理配置や、他の仮想インスタンスの処理負荷傾向を把握できないため、性能低下の要因を把握することができない。また、ユーザはそれぞれ管理コンピュータ５００にアクセスしてセルフサービスでインスタンスの作成／構成変更が可能であり、それらは他ユーザや管理者側の操作とは非同期に行われる。そのため、あるユーザが性能改善のために構成変更をする場合であって、さらに他のインスタンスへ影響するような操作を行うには、他ユーザや管理者との緊密な調整が必要であり、即座に実行できない。システムの論理構成に対する変更が頻繁に行われれば、性能改善の要求が生じた時から移行が行われるまでに構成が変化してしまっており、移行が失敗する恐れがある。その上、上述のように各移行方策にはトレードオフがあり、ユーザが誤って性能低下を解消できない方策を選択してしまうばかりか、無駄なコストを支払わなければならない恐れがある。

本発明によれば、ユーザが知りえない性能影響の要因を適切に判定し、その解消に適した移行方策を提示するシステムが提供される。すなわち、本計算機システムは、図４において、ユーザが管理コンピュータ５００に対してインスタンスの性能改善要求７０１を発行すると、装置の構成と性能履歴を参照して適切な移行方策（以下、改善方策とも言う）７０２を算出し、ユーザに提示することを特徴とする統合サービスレベル管理部５０４ｂを提供する。

＜移行方策リスト＞
図５は、本実施形態において移行方策７０２を提示するための具体的な形式である、移行方策リスト（以下、改善方策リストとも言う）７０３を示す図である。移行方策リスト７０３において、１つの行は１つの移行方策を表している。

移行方策リスト７０３は、移行方策７０３ａごとに、性能安定性７０３ｂと、所要時間７０３ｃと、所要コスト７０３ｄと、停止時間７０３ｅについて値を保持する。本実施形態においては、ユーザが所望の移行方策７０３ａを選択することを想定しており、必ずしも各移行方策７０３ａの優劣を示す必要はない。したがって、同移行方策７０３ａは、単純に後述する処理フローにおいて検出された順に移行方策リスト７０３へ格納されてもよい。他方で、ユーザにとって有益である場合、またはユーザが重要であると定めた移行ポリシの下、自動的に移行方策を一定数に絞り込む場合には、移行方策７０３ａの優劣をリスト７０３への格納順序で示してもよい。そのような順序の決定方法としては、例えば、後述する移行方策の推奨度の高いものから並べられてもよいし、移行ポリシを満足する項目の多いものから並べられてもよい。

移行安定性７０３ｂは、例えば、計算リソース、ネットワークリソース、及びストレージリソースの３項目で評価され、他のインスタンスから性能影響を受けないことが保証される場合に「Ｙｅｓ」が記載される。ここでいう他のインスタンスから性能影響を受けないとは、対象のインスタンスが１つの装置上の物理的な構成要素（例えば１つのプロセッサやポート、記憶領域）を占有し、他のインスタンスと共有していない状態のことを指す。計算リソースの安定とはリソースを十分に確保できることを意味する。ネットワークの安定とはボトルネックが発生しないことを意味する。ストレージの安定とはＩＯＰＳが所定値以下であること（良好）であることを意味する。以下では、便宜上それら装置上の物理的な構成要素のことを、単に装置と呼ぶ。移行することにより他のインスタンスと装置を共有する、あるいは移行前の時点で性能影響が生じていなかった項目については、移行直後には問題でないが、移行後性能が不安定になる可能性があるため性能安定とみなさず、何も記載しない。したがって、「Ｙｅｓ（安定）」と記載のない項目は、移行による効果が「Ｙｅｓ（安定）」となっている場合よりも低いことを表す。「Ｙｅｓ］となっていなくてもユーザが要求するスペックを満たさないということではなく、安定が保証されていない（他のインスタンスの影響を受ける可能性がある）だけであり、現状のスペックよりは高くなっている。
所要時間７０３ｃは、当該移行方策の実施に必要な時間を保持する。

所要コスト７０３ｄは、移行作業自体にかかるコスト、および移行後の通常運用コストを保持する。所要コストは、課金システムが実現する計算式に合わせて算出されなければならない。停止時間７０３ｅには、当該移行方法においてインスタンス上のＯＳをシャットダウンする必要があるか否かを保持する。ユーザはインスタンス上のアプリケーションを利用しており、移行に際してＯＳのシャットダウンが必要になる場合、そのアプリケーションによる作業の中断や、データの保存が必要となるため、本項目をユーザに提示することが重要である。

図５からすると、移行方策＃１を選択することが安定性を考慮すると一番良いことになる。移行方策＃１では移行の所要時間が長くなるため、移行のための時間が十分ある場合には移行方策＃１を選択することができる。しかし、例えば、ユーザが対象の仮想サーバを長時間停止できないときには、計算リソース等が多少足りず、安定性を保証しない場合であっても移行方策＃２を選ぶことがある。つまり、ユーザは、リストで提示された移行方策の中から運用状況に応じて適宜最適な方策を選択できるようになっている。

＜管理プログラムの機能構成＞
図６は、管理コンピュータ５００上で動作し、本発明の特徴的な機能を提供する管理プログラム群５０３ｂの詳細を示す図である。管理コンピュータ５００は、管理プログラムとして、サービス管理部５０４ａと、統合サービスレベル管理部５０４ｂと、サーバ管理部５０４ｃと、ネットワーク管理部５０４ｄと、ストレージ管理部５０４ｅと、を有している。以下に各部の構成及び機能について説明する。

（i）サービス管理部５０４ａは、少なくともカタログテンプレートリスト６００ａと、インスタンス構成管理部６００ｂと、サービスレベル定義部６００ｃと、を有する。

カタログテンプレートリスト６００ａは、インスタンスを作成する際に雛形として参照できるようカタログの一覧を保持する。カタログに含まれる構成情報の項目は、後述のインスタンス管理テーブル６０１に保持される項目から選ばれる。したがって、インスタンス管理テーブル６０１に保持される項目以外のものはカタログには含まれず、多くとも同テーブルと同一である。カタログはさらに、構成情報の項目ごとに利用コストを保持している。それら利用コストの値は、割り当てられるリソース量や管理機能の有無にのみ基づき、サービス管理部５０４ａにより算出される。

インスタンス構成管理部６００ｂは、カタログに記載された事項やユーザのカスタマイズ要求に従って、インスタンス構成を作成し、適用する。インスタンスの構成情報は、後述のインスタンス管理テーブル６０１に保持される。例えば、インスタンス構成管理部６００ｂは、現在使用しているインスタンスの構成についての問い合せがあった場合には、後述のインスタンス管理テーブル６０１から該当する情報を取得してユーザに知らせる。

サービスレベル定義部６００ｃは、カスタマイズが可能な範囲やカスタマイズが可能な項目を保持する。より具体的には、選択肢の中で最も読み書き性能の高いストレージ階層における、ＳＳＤメディアとＳＡＳＨＤＤメディアの割り当て比率を定めるなどの機能を提供する。例えば、ゴールド、シルバー、ブロンズのように３階層のサービスレベルを定義してニーズや状況に応じて使い分けができる。

（ii）統合サービスレベル管理部５０４ｂは、インスタンス管理テーブル６０１と、サービスレベル判定部６０２と、移行条件管理テーブル６０３と、性能履歴格納部６０４と、デバイス管理テーブル６０５と、移行管理部６０６と、を有する。このうち、性能履歴格納部６０４、デバイス管理テーブル６０５、及び移行管理部６０６は、装置管理部（サーバ管理部５０４ｃ、ネットワーク管理部５０４ｄ、及びストレージ管理部５０４ｅ）を参照、または装置構成を設定することができる。

インスタンス管理テーブル６０１の詳細を図７に示す。インスタンス管理テーブル６０１は、各インスタンス（稼働中のインスタンス）について、基本属性６０１ａと、割り当てられる計算リソース６０１ｂと、ネットワークリソース６０１ｃと、ストレージリソース６０１ｄの各設定値と、管理機能６０１ｅの設定値と、を保持する。同図では、インスタンス管理テーブル６０１が、インスタンス６０１−１から６０１−３の３つのインスタンスについて情報を保持していることを示す。インスタンスは一意な識別子により重複なく識別される。基本属性６０１ａには、インスタンスの名称、作成元となったカタログ、インスタンスの使用者など、インスタンスごとに付与される管理情報が記載される。インスタンスの名称は使用者にとって理解しやすい文字列であればよいが、少なくとも同一使用者のインスタンスにおいて一意であるとする。他に必要であればインスタンスの用途を示すタグ、作成日時などの情報を含んでもよい。計算リソース６０１ｂには、ＣＰＵやＲＡＭなど、計算性能に関するリソースの属性、およびその割り当て量が記載される。同様に、ネットワークリソース６０１ｃにはイーサネットワークおよびファイバチャネルネットワークについての、ストレージリソース６０１ｄにはディスクに関する属性、およびその割り当て量が記載される。

さらに、インスタンス管理テーブル６０１は、リソースごとに安定性を示す項目（図７中下線部）を有しており、これは本発明においてサービスレベルを決定づける重要な設定値である。安定性の項目において、「Ｎｏ」となっている場合には他のインスタンスとの競合によりパフォーマンス低下の可能性があるため、移行した方が良いことを示している。

また、管理機能６０１ｅは、インスタンスごとに有効化されている項目や、その種類が記載されている。管理機能６０１ｅとして記載されうる項目は、サービスレベル定義部６００ｃにより定義されており、統合サービスレベル管理部５０４ｂの制御化にある装置管理部、および各装置が有する機能に基づく。なお、図７中「Ｃｏｌｄ」はインスタンスを停止する必要性があることを示している。

図６に戻り、サービスレベル判定部６０２は、ユーザからの構成変更要求を受け取り、どのインスタンスが性能の影響を受けていてどのインスタンスが性能の影響を受けていないか判断する。そして、サービスレベル判定部６０２は、適切な移行先候補の装置を選ぶための移行方策およびインスタンス候補６０２ａを算出する。サービスレベル判定部６０２に含まれるインスタンス候補６０２ａは、移行方策を検証するため仮に想定した移行後のインスタンス構成であり、インスタンス管理テーブル６０１と同様の項目により表現される。また、移行方策を検討する基となる性能情報は、性能履歴格納部６０４から提供される。さらに、性能影響の要因が特定され、算出された移行方策を移行管理部６０６に対して指定する。

移行条件管理テーブル６０３の詳細を図８に示す。移行条件管理テーブル６０３は、ある構成要素の移行に関する条件を列挙したものであり、各インスタンス候補について、移行管理部６０６によって全ての条件が評価される。図８に示される移行条件管理テーブル６０３は、仮想インスタンスから仮想インスタンスへの移行、仮想インスタンスから物理インスタンスへの移行、物理インスタンスから仮想インスタンスへの移行、物理インスタンスから物理インスタンスへの移行の全ての場合に参照される。ここで、構成要素の移行に関する条件とは、インスタンスを構成するソフトウェアコンポーネントや、ハードウェア装置に対して課される条件であり、移行の可否を判断する基準や、移行に必要な手順（移行方法）を論理化したものである。具体的には、“モデルＡのベアメタルサーバ上で稼働していた物理インスタンスをモデルＢのベアメタルサーバに移行するには、デバイスＣのドライバ導入が必要であること”、あるいは“ゲストＯＳの種類がＤである仮想インスタンスは、ハイパバイザＥには移行不可能であること”といったものを指す。これらの条件は、計算機システムの管理ポリシや、利用される移行ツールの動作要件により決定される。ただし、それらの条件は、必ず管理コンピュータ５００が観測可能な値によって表現され、かつ一致／不一致や値の大小、範囲など論理的に評価することが可能なものに限られる。

移行条件管理テーブル６０３は、移行条件ＩＤ６０３ａと、条件６０３ｄに合致した場合の出力値を示すタイプ６０３ｂと、移行方法６０３ｆを決定づけるパラメータ６０３ｃと、パラメータ６０３ｃが適用される条件式６０３ｄと、条件式６０３ｄが真であるときの属性（タイプ）６０３ｂと、当該移行方法の実行にかかる所要時間６０３ｅと、当該移行方法を実行した場合に掛かるコスト６０３ｇと、を構成項目として保持する。

移行元および移行先として指定される構成の組には、条件式６０３ｄが真である際に移行可能であるもの（Ａｃｃｅｐｔｅｄ）と、移行不可能であるもの（Ｒｅｆｕｓｅｄ）があり、属性（タイプ）６０３ｂはその可否を示す。移行方策について、１つでも移行不可能（Ｒｅｆｕｓｅｄ）と判定されるパラメータを含む場合、属性（タイプ）６０３ｂが移行不可能である条件式６０３ｄが成立し、当該移行方策は棄却される。ただし、Ａｃｃｅｐｔｅｄの条件に合致しない場合でも対象の移行方策が即座に棄却されることはない。Ａｃｃｅｐｔｅｄの属性（タイプ）の場合に、パラメータ６０３ｃが条件６０３ｄに合致するときは、方策６０３ｆが実行されることになるだけである。例えば、ＩＤ６０３ａ＝＃２００５の場合、処理対象のインスタンス候補のゲストＯＳ名がＸ、ＶＭホスト（物理サーバ）名がＹのときを考える。このときこれらのパラメータを該当する条件に合致するか判断される。この例の場合、ゲストＯＳ（Ｘ）がＰｌａｔｆｏｒｍ_Ａで、かつＶＭホスト（Ｙ）がＨｏｓｅｔＬｉｓｔ_Ａであったとき、属性（タイプ）が”Ａｃｃｅｐｔｅｄ”となり、移行方法６０３ｆで示される作業が実行されることになる。

また、移行条件管理テーブル６０３は、条件式６０３ｄの評価方法とその結果に対する挙動を記述することができれば、テーブル形式に限らずシェルスクリプトやプログラムの集合として実現されてもよい。移行管理部６０６は、移行元構成と、移行方策から算出される移行先候補の構成を、移行条件管理テーブル６０３により評価し、当該移行方策が実施可能であるか否かを判定する。移行方策が実施可能である場合、同じ移行条件管理テーブル６０３を評価することにより、さらに移行にかかる所要時間およびコストが算出される。

図６に戻り、性能履歴格納部６０４は、サーバ管理部５０４ｃ、ネットワーク管理部５０４ｄ、及びストレージ管理部５０４ｅから、各装置のリソースに関する性能履歴を取得し、図示しないメモリに蓄積する。性能履歴格納部６０４が保持する性能情報は、概ね各リソース（ＣＰＵ、ＲＡＭ、ネットワークアダプタ、ディスクデバイス）における利用率（利用時間の比率や、全リソース量に対する稼働数、あるいはバス帯域の使用率）、待ちジョブ長さ（キュー全長に対する平均待ちジョブ数や、平均バッファ使用量）、単位時間あたりのコマンド処理量（ＩＯＰＳや、ＴＰＳ：Transaction Per Second）、や平均応答時間などである。なお、複数のインスタンスに由来する処理負荷が生じている場合は、各インスタンス上のＯＳおよびハイパバイザから取得できる情報に限り、インスタンスごとの負荷に分解できるものとする。ただし、サービスレベル判定部６０２の判定アルゴリズムにより、性能履歴格納部６０４が取得する項目の詳細、および蓄積する履歴の対象期間は異なっていても良い。

デバイス管理テーブル６０５の詳細を図９に示す。デバイス管理テーブル６０５は、インスタンスごとに識別子６０５ａと、稼働する物理サーバ６０５ｂと、ハイパバイザ６０５ｃ（仮想インスタンスの場合）と、同物理サーバが搭載されているサーバシャーシ６０５ｄと、ネットワークインタフェース６０５ｅと、システムユニットの接続構成から求められる接続先のイーサスイッチ６０５ｆと、ファイバチャネル６０５ｇと、ストレージ制御部６０５ｈについての構成情報と、を管理項目として保持する。これらの構成情報は、性能履歴格納部６０４の場合と同様に、各装置管理部から取得できる。

例えば、インスタンスＡ００１とＡ００２は、サーバシャーシを共有している。インスタンスＡ００２とＢ３３０では、ディスクコントローラを共有しており、ここで競合が発生する可能性があると分かる。

以上のように、デバイス管理テーブル６０５を参照することにより、インスタンス間で共有している機器をチェックすることができる。

＜移行方策を算出する処理＞
以下にインスタンスの性能劣化、および性能余剰を改善する方策を算出する処理について述べる。図１０Ａおよび図１０Ｂは、仮想インスタンスおよび物理インスタンスの性能劣化を改善する移行方策を算出する際の処理の詳細を説明するためのフローチャートである。本処理においては、特に統合サービスレベル管理部５０４ｂが重要な役割を担っており、移行方策７０２を移行方策リスト７０３の形式で算出する。統合サービスレベル管理部５０４ｂは、内部的に移行方策の推奨度を有し、前述の通り、移行方策リスト７０３に格納される各移行方策７０３ａの優劣を示す際に用いられてもよい。

ステップ７５０において、ユーザは、クライアントコンピュータ５１０上のクライアントプログラム５１３ｂを使用し、管理コンピュータ５００上のサービス管理部５０４ａに対して、インスタンス２４の構成変更を要求する。このとき、ユーザからの要求を受けて、クライアントプログラム５１３ｂは、当該仮想インスタンスの名称（図７中の６０１ａ参照）をサービス管理部５０４ａに通知する。その背景には、ユーザが当該仮想インスタンス２４上のアプリケーション２３ｃにおける性能低下を感じたことが契機となっている。しかしながら、ユーザ自身は性能低下の主要因が何であるかを判別していない。

ステップ７５１において、サービス管理部５０４ａは、ユーザのアクセス権限に基づいて構成変更要求を承認し、統合サービスレベル管理部５０４ｂに対してユーザが指定したインスタンスの名称を伝える。統合サービスレベル管理部５０４ｂは、サービスレベル判定部６０２にて受信したインスタンスの名称を使用して、インスタンス管理テーブル６０１に記載された当該インスタンスの識別子を特定する。同じインスタンスの名称が複数存在する場合には、ユーザ（インスタンスの使用者）名を用いて特定するなど他の情報と組み合わせて識別子を特定する。

ステップ７５２において、サービスレベル判定部６０２は、ステップ７５１において特定したインスタンスの識別子を用いてデバイス管理テーブル６０５を検索し、当該インスタンスが使用している装置（サーバ装置、ネットワーク装置、ストレージ装置）を特定する。

ステップ７５３において、サービスレベル判定部６０２は、ステップ７５２において特定した全ての装置について、性能履歴格納部６０４より性能情報の履歴（例えば、１日の履歴、１週間の履歴等、様々な種類の履歴がある）を取得する。これにより、当該インスタンスに対して性能影響を及ぼしうる他のインスタンス、および装置が判明する。

ステップ７５４において、サービスレベル判定部６０２は、ユーザが当該インスタンス（当該ユーザが使用中のインスタンス）に対して行った改善要求、またはインスタンスの性能履歴の推移に応じて、性能劣化を改善する処理（ステップ７５５ａ）及び性能余剰を改善する処理（ステップ７５５ｂ）のいずれかに処理を分岐させる。ここでは、例えば、ユーザがステップ７５０において性能劣化を改善する方策を要求している場合や、性能情報履歴から当該インスタンスの処理負荷が高まっていることが検出された場合には、性能劣化を改善する方策を導出する処理７５５ａに進む。一方、ユーザがステップ７５０において性能余剰のインスタンスの構成を縮小させる方策を要求している場合や、性能情報履歴から当該インスタンスの処理負荷が割当てられたリソースに比べて低いことが検出された場合には、性能余剰を改善する方策を導出する処理７５５ｂに進む。処理７５５ａ及び７５５ｂの詳細について以下順次説明するが、同処理により改善方策７０２ａ及びｂを算出することができる。

（i）性能劣化改善方策導出処理
性能劣化を改善する方策を導出する処理７５５ａの詳細を、図１０Ｂを用いて説明する。

前述の分岐ステップ７５４において、性能劣化が生じていると判断された場合、ステップ７６０に進む。

ステップ７６０において、サービスレベル判定部６０２は、当該インスタンスの各装置について、他のインスタンスから性能影響を受けているか否かを判別する。より具体的には、例えば同じ仮想マシンホストを利用している他の仮想サーバから与えられる計算リソースに対する性能影響の有無、あるいは、同じネットワークポートを共有する他の物理サーバから与えられるネットワークリソースに対する性能影響の有無を調査し、判定を行う。性能影響の有無を判定した結果は、計算リソース、ネットワークリソース、ストレージリソースにおいて評価され、インスタンス管理テーブル６０１に保持される。本ステップにおいて他のインスタンスの性能影響が要因でないと判定された場合には、処理はステップ７６１に進む。他のインスタンスが性能影響を及ぼしていると判定された場合には、構成の拡張（リソース追加）が不要であるため、移行後のインスタンス構成を表すインスタンス候補６０２ａに移行対象インスタンスと同じ構成を設定し、処理はステップ７６３に進む。

ステップ７６１において、サービスレベル判定部６０２は、性能履歴格納部６０４から、同一装置における空きリソース量を取得し、適したリソースがあるか（十分に空きリソースがあるか）判断する。ここで、空きリソース量とは、各装置管理部が公開している場合は利用可能なリソース量のことであり、公開していない場合は全リソース量から、利用されているリソース総量を差し引いたもののことである。また、サービスレベル判定部６０２は、拡張するリソース量を決定し、インスタンス候補６０２ａを設定する。拡張するリソース量の算出方法としては、事前に決定された比率を一律に用いる（例えば既存リソース量を２５％増加させるなど）、現在の利用率を以前一定期間の利用率まで低下させる量を追加する、あるいはユーザに問い合わせるなどの方法がある。さらに、サービスレベル判定部６０２は、空きリソース量と拡張するリソース量とを比較し、構成拡張が可能であるか否かを判別する。装置の構成によって、１つのインスタンスに割り当て可能なリソース量の上限値が設定されている場合は、その上限値との比較も行い、可否を判断する。十分な空きリソースがあると判定された場合には、処理はステップ７６２へ進む。空きリソースが不足と判定された場合は、たとえ他のインスタンスから性能影響を受けていない場合であっても別の装置への移行が必要と判定し、処理はステップ７６３へ進む。また、当該インスタンスが各装置を占有している場合、例えば１つのベアメタルサーバを占有する物理インスタンスである場合、ステップ７６０では他のインスタンスから性能影響を受けていないと判定される可能性が高い。その場合、処理はステップ７６１に進むものの、ステップ７６１において空きリソースがないと判断されて、ステップ７６３に進むことになる。

ステップ７６２において、サービスレベル判定部６０２は、同一装置における構成拡張を改善方策リスト７０３に追加し、それを移行管理部６０６に通知する。特に、例えば仮想インスタンスが計算リソースの不足により性能劣化を生じていた場合、同一仮想マシンホストにおける仮想インスタンスの構成変更が行われるのみであり、移行管理部６０６により移行の実施可能性が否定されることはない。したがって、移行管理部６０６は、移行条件管理テーブル６０３により移行にかかる所要時間およびコストを算出するためにのみ利用される。また、各リソースについて性能安定となる個数の積算として、推奨度が算出される。当該インスタンスの性能改善を要求しているユーザの承認が得られるまでの期間、他のユーザや管理者により移行先リソースが消費されてしまう恐れがある場合には、それら対象移行先リソースを予約する手順をさらに行ってもよい。

ステップ７６３以後は、別装置への移行を検討するフローである。ステップ７６３において、サービスレベル判定部６０２は、移行管理部６０６に対し、当該仮想インスタンスが現在稼働しているものとは別の装置へ移行するよう要求する。このとき移行管理部６０６は、移行元が仮想インスタンスであっても、仮想マシンホストのみならずベアメタルサーバについても移行先として検討する。

ステップ７６４において、移行管理部６０６は、物理的に近傍に配置された装置、すなわち同じラックに搭載されている装置を優先的に検出して移行先の候補とする。近傍であればあるほど構成変更のために掛かる時間は少なくて済む。ただし、別のシステムユニットにある装置を移行先の候補とすることはしない。

移行管理部６０６は、移行先装置の候補と、それら候補に対する検証の済・未済を保持し、順次移行先に適した装置であるかを判定するステップ７６５から７７１を実行する。同じシステムユニット内に適切な装置が見つからない場合、システムユニットを跨って移行先装置を検索する必要がある。システムユニットを跨る移行を実施する際には構成を管理する管理コンピュータ５００が異なるため、単に装置の構成変更だけでなく、管理情報を含めて移行しなければならない。

ステップ７６５において、移行管理部６０６は、デバイス管理テーブル６０５を参照して、移行条件管理テーブル６０３に記載された条件を評価する。このとき、少なくとも１つの移行の実行可能性が否定された場合、すなわち属性（タイプ）６０３ｂにより移行不可能であることを示す条件式が成立した場合（Ｒｅｆｕｓｅｄとなった場合）、処理はステップ７６３に進む。また、性能履歴格納部６０４が保持する性能情報から、移行先装置に十分な空きリソースが無いことが検出された場合でも、移行管理部６０６は、即座に移行先として不適であるとみなし、処理をステップ７６９に進ませる。一方、移行の実行可能性が否定されておらず、空きリソースが十分である場合は、処理はステップ７６６へ進む。

ステップ７６６において、移行管理部６０６は、移行先装置が他のインスタンスと共有されているか、もしくは移行すれば占有可能であるかを調べる。ただし、移行先装置が他のインスタンスにより使用されておらず、占有が許される場合には、当該移行方策が適合するとして処理はステップ７７０に進む。移行先装置において他のインスタンスから受ける可能性がある場合は、処理はステップ７６７に進む。

ステップ７６７において、移行管理部６０６は、当該移行方策の推奨度を下げる。本ステップにおいて推奨度を下げるのは、移行方策を棄却する判断はできないものの、性能影響を受ける可能性が残るために、装置を占有させる方策がより安定稼働を実現できる点で優位であることに基づく。

ステップ７６８において、検証対象の装置上で稼働するその他のインスタンスが、移行対象のインスタンスと同じ処理負荷傾向を示す場合には、性能影響を受ける可能性が示唆されるため、移行管理部６０６は、当該装置を移行先として適さないと判定し、処理をステップ７６９に進ませる。移行対象のインスタンスの負荷傾向が他のインスタンスの負荷傾向と競合しない場合、適切な移行先装置の候補であると判断してステップ７７０へ進む。

ステップ７６９では、移行先装置として適切でないことがステップ７６８において判定されているため、移行管理部６０６は、当該装置を移行先候補から棄却し、以降の検証候補から除外する。

ステップ７７０において、移行管理部６０６は、移行条件管理テーブル６０３を参照して移行にかかる所要時間およびコストを評価したものと合わせて、当該移行方法を改善方策リスト７０３に追記する。また、ステップ７６２と同様に、推奨度が算出されるが、ステップ７６７を経由した場合には、当該リソースについて推奨度は一段階下げたものが反映される。さらに、当該インスタンスの性能改善を要求しているユーザの承認が得られるまでの期間、他のユーザや管理者により対象装置の移行先リソースが消費されてしまう恐れがある場合には、それら対象移行先リソースを予約する手順を追加して行ってもよい。さらに、当該装置を以降の検証候補から除外する。

ステップ７７１では、移行管理部６０６は、検証候補として保持したもののなかで、未検証のものがあるかを判定する。未検証のものがあれば、そのうち１つを選択して再度検証処理を適用するべく、処理はステップ７５９へ戻り、未検証のものがなければ（残った検証候補が空ならば）本処理は終了する。本処理フローを経ることで、改善方策リスト７０３には、性能低下を解消する方策が格納される。

（ii）性能余剰改善方策導出処理
以上の説明は、インスタンスの性能劣化を改善する方策の算出について述べたものであるが、インスタンスの性能余剰を改善する方策の算出についても同様に図１０Ａおよび図１０Ｂに示す処理フローを用いて説明する。性能余剰が起こりやすい状況としては、例えば、物理ネットワークポートなどの装置コンポーネントを占有している場合や、１つの物理サーバを占有している場合である。特に物理インスタンスはベアメタルサーバであり、物理サーバの豊富な処理リソースを独占的に割り当てられており、インスタンス上のアプリケーションへの処理需要が減少した場合には、リソース利用効率が低下してしまう可能性がある。本構成において、ユーザがそれらの性能余剰を感じ、このまま当該インスタンスを使用し続けるとコストが高くなってしまうと判断した場合、クライアントプログラム５１３ｂを用いて管理コンピュータ５００に対して、管理リソース利用効率を高めたいという要求が出される。その要求に対して、管理プログラムの各コンポーネントは、インスタンスに割り当てられたリソース量を縮小するか、あるいはよりリソース量の少ない別の装置へと移行することにより、リソース利用効率を改善する。仮想サーバである仮想インスタンスの場合など、ユーザが性能影響を許容して他のインスタンスと同じ物理装置を共有している場合の性能余剰においても、単にリソース割り当て量を縮小するのではなく、性能安定を維持しつつ移行する。このとき、性能の影響を加味して、装置を共有させるか、あるいはよりリソース容量の小さい装置を占有させるか、という判定を行う必要がある。特に物理インスタンス（物理サーバ）の場合には、仮想サーバのようにリソース割当て変更による構成縮小が簡単にできないため、移行を前提とした改善方策の算出処理となる。そして、物理インスタンスの場合、構成を縮小できる移行先として物理インスタンス或いは仮想インスタンスが選択されるが、そもそも物理インスタスを用いていたということはサーバの安定性を重視していたということであるから、構成の縮小が可能で、かつ動作の安定性を保証する移行先（物理インスタンスから仮想インスタンスに変更する場合でも）を選択する必要があることになる。

上述の性能余剰を改善する処理においては、図１０Ａにおいてステップ７５０からステップ７５４を適用し、ステップ７５４の分岐において性能余剰を改善する方策を導出処理７５５ｂへ進む。処理７５５ｂの詳細は以下に述べるが、同処理により改善方策７０２ｂが算出される。

性能余剰を改善する方策を導出する処理７５５ｂの詳細についても、処理７５５ａと同様に図１０Ｂを用いて説明する。

ステップ７５４において、性能余剰が生じていると判断された場合、処理はステップ７６０に進む。

ステップ７６０において、サービスレベル判定部６０２は、当該インスタンスの各装置について、他のインスタンスから性能影響を受けているか否かを判別する。前述の性能劣化の場合と比較して、性能余剰が生じている場合には、他のインスタンスからの性能影響が当該インスタンスの性能上限を左右する可能性は低く、ステップ７６０は負荷傾向の相関を調べるために行われる。当該ステップにおいて、他のインスタンスの負荷傾向と競合していないと判定された場合には、処理はステップ７６１に進む。他のインスタンスの負荷傾向と競合していると判定された場合には、より要求性能に適した別の装置を求めて、処理はステップ７６３に進む。

ステップ７６１において、サービスレベル判定部６０２は、性能履歴格納部６０４から、同一装置におけるリソース量を取得する。また、サービスレベル判定部６０２は、縮小するリソース量を決定し、インスタンス候補６０２ａを設定する。インスタンス候補６０２ａの構成は、処理需要に応じて設定され、例えば、事前に決定された比率を一律に用いる（例えば既存リソース量を２５％削減させるなど）、現在の利用率を以前一定期間の利用率まで向上させるリソース量を削減する、あるいはユーザに問い合わせるなどがある。さらに、サービスレベル判定部６０２は、取得した同一装置のリソース量とインスタンス候補６０２ａのリソース量を比較し、移行の可否を判断する。特に仮想インスタンスの計算リソースにおける性能余剰の場合、多くの場合問題なく構成を縮小できるが、物理インスタンスの場合はＣＰＵの数など物理的に構成変更できない場合が多い。また、装置の構成によって、１つのインスタンスに割り当て可能なリソース量の下限値が設定されている場合は、その下限値との比較を行い、可否を判断する。移行が可能であると判定された場合には、処理はステップ７６２へ進む。移行が不可能であると判定された場合には別の装置への移行が必要と判定し、処理はステップ７６３へ進む。

ステップ７６２において、サービスレベル判定部６０２は同一装置における構成縮小を改善方策リスト７０３に追加し、それを移行管理部６０６に通知する。

ステップ７６３以後は、別装置へのインスタンスの移行を検討する処理である。
ステップ７６３において、サービスレベル判定部６０２は、移行管理部６０６に対し、当該仮想インスタンスが現在稼働しているものとは別の装置へ移行するよう要求する。

ステップ７６４において、移行管理部６０６は、サービスレベル判定部６０２からの要求（指示）に応答して、物理的に近傍に配置された装置、すなわち同じラックに搭載されている装置を優先的に検出して移行先の候補とする。同じラックに搭載されている装置を優先する理由は上述の通りである。

ステップ７６５において、移行管理部６０６は、デバイス管理テーブル６０５を参照して、移行条件管理テーブル６０３に記載された条件を評価する。このとき、少なくとも１つの移行の実行可能性が否定された場合、すなわち属性（タイプ）６０３ｂにより移行不可能であることを示す条件式が成立した場合（１つでもＲｅｆｕｓｅｄが成立した場合）、処理はステップ７６３に進む。また、性能履歴格納部６０４が保持する性能情報から、移行先装置に十分な空きリソースが無いことが検出された場合でも、移行管理部６０６は、当該装置が移行先として不適であると即座にみなし、処理をステップ７６９へ進ませる。移行の実行可能性が否定されておらず、空きリソースが十分である場合は、処理はステップ７６６へ進む。

ステップ７６０において、移行管理部６０６は、移行先装置が他のインスタンスと共有されているか、もしくは移行すれば占有可能であるかを調べる。ただし、移行先装置が他のインスタンスにより使用されておらず、占有が許される場合には、当該移行方策が適合するとして、処理はステップ７７０に進む。移行先装置において他のインスタンスから受ける可能性がある場合は、処理はステップ７６７に進む。
ステップ７６７において、移行管理部６０６は、当該移行方策の推奨度を下げる。

ステップ７６８において、検証対象の装置上で稼働するその他のインスタンスが、移行対象のインスタンスと同じ処理負荷傾向を示す場合には、性能影響を受ける可能性が示唆されるため、移行管理部６０６は、当該装置は移行先として適さないと判定し、処理をステップ７６９に進ませる。移行対象のインスタンスの負荷傾向が他のインスタンスの負荷傾向と競合しない場合、移行管理部６０６は、当該装置は適切な移行先装置の候補であると判断して、処理をステップ７７０へ進ませる。

ステップ７６９では、当該装置が移行先装置として適切でないとステップ７６８で判定されているため、移行管理部６０６は、当該装置を移行先候補から棄却し、以降の検証候補から除外する。

ステップ７７０において、移行管理部６０６は、移行条件管理テーブル６０３を参照して移行にかかる所要時間およびコストを評価したものと合わせて、当該移行方法を改善方策リスト７０３に追記する。また、ステップ７６２と同様に、推奨度が算出されるが、ステップ７６７を経由した場合には、当該リソースについて推奨度は一段階下げたものが反映される。さらに、当該インスタンスの性能改善を要求しているユーザの承認が得られるまでの期間、他のユーザや管理者により対象装置の移行先リソースが消費されてしまう恐れがある場合には、それら対象移行先リソースを予約する手順を追加して行ってもよい。さらに、当該装置を以降の検証候補から除外する。

ステップ７７１では、移行管理部６０６は、検証候補として保持したもののなかで、未検証のものがあるかを判定する。未検証のものがあれば、そのうち１つを選択して再度検証処理を適用するべく処理はステップ７５９へ戻り、未検証のものがなければ（残った検証候補が空ならば）、処理は終了する。

以上のようにして、改善方策リスト７０３には、性能余剰を解消する方策が格納される。

＜性能影響要因の特定方法＞
前述の通り、インスタンスの性能劣化が起こる要因として、単にリソースの割り当て量が不足している場合と、他のインスタンスと共有しているリソースについて処理需要が競合している場合がある。また、逆に性能余剰の場合でも、処理需要が競合しないインスタンスにより同一装置を共有させるよう移行することで、全体的なリソース利用率の向上が見込める。ここでは、適切な移行方策を選択するために必須となる、影響要因を判別する方法について述べる。これは、より具体的には、本実施形態における処理フロー（図１０Ａ及びＢ参照）のうち、ステップ７６０およびステップ７６８において必要となる処理である。

改善対象のインスタンスの性能に対して他のインスタンスが影響を及ぼしているか否かを判定するには、まず、どの装置を他のインスタンスと共有しているかを調べる必要がある。これは、デバイス管理テーブル６０５（図９参照）を参照することにより調べることができ、改善対象が使用している各装置について、同じ装置を含むレコードを検索すればよい。例えば、識別子「Ａ００２」のインスタンスは、インスタンスＢ３３０と、ファイバチャネルスイッチＦＳ２０のポート＃０５およびストレージコントローラのポート＃Ａ１を共有していることがわかる。

次に、共有されている装置について、インスタンス同士が互いに影響し合っているかを調べる。そのための方法として、少なくとも以下の３つの方法が挙げられる。

第１の方法として、性能履歴格納部６０４から当該装置の性能履歴を参照し、改善対象のインスタンスに由来する負荷の推移傾向と、その他のインスタンスに由来する負荷の推移傾向の相関を評価するやり方がある。改善対象のインスタンスとその他のインスタンスとで、推移傾向が逆となっていれば性能影響を受けている可能性が高く、相関が無ければ性能影響の可能性が低い。例えば、改善対象のインスタンスの性能が劣化しているのに対し、他のインスタンスの性能が向上している場合は、他のインスタンスにより処理性能が奪われていると判定できる。一方で、他のインスタンスの性能に変化がない場合に、改善対象のインスタンスの性能が劣化している場合は、単にインスタンス内の処理需要の増加に対してリソース供給が不足していると判定できる。

第２の方法として、性能履歴格納部６０４から当該装置の性能履歴を参照し、改善対象のインスタンスおよびその他のインスタンスに由来する負荷について、最近の履歴と過去の履歴とを比較するやり方がある。過去の一定期間の性能履歴と比較して、改善対象の性能が定常的に低下しており、他が定常的に上昇していることで性能影響を検出できる。当該装置において、ディスクＩＯや、ネットワークスイッチにおける優先度制御を利用している場合、制御ポリシの設定を変更することで、結果的に優先度の低いものの性能が長期的に低下する場合がある。それらの制御ポリシは、通信の用途（例えば、データの送受信を要求するアプリケーションの別や、データ転送／制御情報／プログラムコードのロードの別など）に対して定められることもあり、インスタンスごとに設定されない可能性もある。そのような場合には、より長期的な負荷傾向を調べることで性能影響を検出することができる。

第３の方法として、性能履歴格納部６０４から性能履歴を参照し、当該装置の性能容量が限界値に達していることを検出するやり方がある。複数のインスタンスにより装置が共有されている場合、それぞれの負荷の総和によりリソースが逼迫する可能性があり、これは当該装置全体の負荷を把握しなければ検出することができない。さらにこの方法では、例えばメモリ領域のスワップや、ネットワークアダプタにおける転送データのバッファリング、ＣＰＵコアの動的割り当てなど、装置内でリソースを融通する既存技術の効果により、複数インスタンス間の負荷傾向に顕著な相関が生じない場合であっても、相互の性能影響を検出できる。

以上の方法のいずれにしても、同一装置を共有しているインスタンスを特定し、さらにそれらの処理負荷における傾向を調べることで、複数インスタンス間で性能影響が生じているか否かを判定する点が共通している。これらの判定方法はサービスレベル判定部６０２により実現され、装置ごとの性能履歴については性能履歴格納部６０４から取得可能である。ただし、性能履歴格納部６０４が保持できる性能履歴は、各装置管理部から取得できる項目に限られるため、サービスレベル判定部６０２は取得可能な性能項目に基づいて利用可能な判定方法を選択する機能を有する。

＜第1の実施形態についての小括＞
以上のようにすることにより、インスタンス上のアプリケーションの性能劣化や性能余剰を動機としてインスタンスの構成変更が要求された際に、性能を改善するのに適した移行方策を提示するシステムが提供される。第１の実施形態によれば、インスタンスが配置されている装置構成や接続構成を、インスタンスの利用者が知りえない場合においても、適切な移行方策が提示される。また、提示される移行方策には性能が改善されるリソースの種別に加え、所要時間および当該方策により生じるコストや、移行後のインスタンスの運用にかかるコストの予測値が含まれる。これにより、複数提示される移行方策の長所および短所を定量的に把握し、利用者が単独で移行方策を選択する、あるいは利用者が設定するポリシに基づき自動的に移行方策を決定することが可能となる。

（２）第２の実施形態
第２の実施形態は、ユーザの構成変更に対して移行方策を生成するという機能を有する点ではおいては第１の実施形態と同じであるが、移行方策として近似のカタログを推奨する点において異なる。

前述の通り、カタログとは、インスタンスの用途や物理リソースのサイジングなどの要因を考慮し設計される、サーバの典型的な構成である。したがって、カタログの構成から極端に逸脱する構成変更を行った場合には、リソース利用効率が低下したり、インスタンス上で稼働するアプリケーションのソフトウェア要件を満たさなくなったりする恐れがある。

より具体的には、例えば、仮想インスタンスのメモリリソースが不足した際に、性能改善のためメモリの追加のみを行った場合を考える。このとき、ＣＰＵやＮＩＣなど他のリソースの利用率は低いまま、当該仮想インスタンスが物理サーバのメモリリソースの大半を消費するために他の仮想インスタンスを同物理サーバ上に作成できないという可能性が生じる。また、メモリリソース容量に対して、相応のネットワーク帯域を追加しなければならないというサイジング要件を有するアプリケーションであった場合には、その後ネットワーク通信がボトルネックとなり処理性能が低下する可能性がある。このとき、大容量のメモリを搭載する物理サーバ用に設計されたカタログや、特定アプリケーション向けに大容量メモリとネットワークをサイジングしたカタログを提示することにより、よりインスタンスの用途、およびシステム全体に対して適切なインスタンス構成へと誘導できる。
さらに、このようなカタログ提案の結果、カタログが選択された頻度の統計により、人気の高いカタログを把握することができるという効果もある。これは、カタログを設計する管理者や、物理装置を増設する管理者にとってサイジングの根拠を得られるという有用な効果である。

第２の実施形態では、第１の実施形態と比較して、移行先構成の候補を算出する処理を含む、ステップ７６１、およびステップ７６５が変更される。同ステップにおいて、特にインスタンス候補６０２ａとして設定され得るカタログを検索する処理が追加される。さらに、ユーザに提示される移行方策７０２は、図５に示す改善方策リスト７０３に代わり、カタログのリストとなる。その他の物理構成および論理構成は第１の実施形態と同一である。

ステップ７６１においては、同一装置における移行後のインスタンス構成を仮に保持するインスタンス候補６０２ａが設定される。このとき近似のカタログを検索し、同カタログに記載の設定値によりインスタンス候補６０２ａを更新する。このようなカタログを以後、推奨カタログと呼ぶことにする。

本実施形態において、仮想インスタンス用のカタログと、物理インスタンス用のカタログは、主にサーバ装置の構成に合わせてそれらカタログが別々に作成される。したがって、ステップ７６４において、ストレージ装置やネットワーク装置ではなく、未検証のサーバ装置が選ばれた場合には、サーバ装置の構成に適したカタログを推奨カタログとして再度選び直す。より具体的には、ステップ７６５において、特に仮想インスタンスから物理インスタンスへの変更（Ｖ２Ｐ移行）、または物理インスタンスから仮想インスタンスへの変更（Ｐ２Ｖ移行）が必要と判定された場合には、再度推奨カタログの検索を行い、インスタンス候補６０２ａを更新して再度ステップ７６５の判定処理を行う。

＜近似カタログの検索処理の概念＞
図１１は、本実施形態による、あるインスタンスに対して、近似のカタログを検索する処理の概念を説明するための図である。ここでは、例として、評価対象のインスタンス構成８００を考える。ここで、推奨カタログを検索する処理としては、次の２通りの方法が考えられる。

（i）第１の方法
第１の方法は、リソースの量に基づくものである。この方法は、主に移行前のインスタンス候補６０２ａに対して構成の変更が必要であると判定されたときに用いられる。

サービスレベル判定部６０２は、インスタンス候補６０２ａに対してリソースの追加量（または削減量）を決定し、評価対象のインスタンス構成とし、変更が必要な項目を保持しておく。

次に、サービスレベル判定部６０２は、カタログテンプレートリスト６００ａから順次候補カタログ８０１を取得し、変更が必要な項目について比較することで、差分量を計算する。さらに、その差分量が所望の変更量を満たすようなものを推奨カタログとする。例えば、メモリを最低でも４ＧＢ追加する必要がある場合には、最低でも４ＧＢ以上増加するカタログを候補として選出する。

このようなカタログが複数選出される場合、サービスレベル判定部６０２は、他の各リソース量および管理機能の有無について差分（差分情報８０２ａ−８０２ｄ）を計算し、差分量が最小となるものを選ぶことにより候補を絞ってもよい。

そして、サービスレベル判定部６０２は、推奨カタログによりインスタンス候補６０２ａを更新し、推奨カタログの識別子を保持する。

（ii）第２の方法
第２の方法は、リソースの性能安定性に基づくものである。この方法は、主に移行前のインスタンス候補６０２ａに対して他のインスタンスにより性能影響が生じていると判定されたときに用いられる。

サービスレベル判定部６０２は、インスタンス候補６０２ａに対して、性能影響を解消すべきリソースを特定し、保持しておく。

次に、サービスレベル判定部６０２は、カタログテンプレートリスト６００ａから順次候補カタログ８０１を取得し、安定化が必要な項目について比較することで、差分量を計算する。例えば、図１１のように、例えば計算リソースとストレージリソースの安定化が必要であると算出された場合、計算リソースとストレージリソースの両方が安定になるカタログを推奨カタログとする。

このようなカタログが複数選出される場合、サービスレベル判定部６０２は、他の各リソース量および管理機能の有無について差分を計算し、差分量が最小となるものを選ぶことにより候補を絞ってもよい。

そして、サービスレベル判定部６０２は、推奨カタログによりインスタンス候補６０２ａを更新し、推奨カタログの識別子を保持する。

（iii）改善方策の提示
移行方策を算出する処理（上記（i）或いは（ii））が完了した後、サービス管理部５０４ａは、サービスレベル判定部６０２により保持された推奨カタログの識別子に基づき、当該推奨カタログの情報をカタログテンプレートリスト６００ａから取得し、改善方策７０２として提示する。

＜第２の実施形態の小括＞
以上の構成により、インスタンス上のアプリケーションの性能低下を動機としてインスタンスの構成変更が要求された際に、性能を改善するのに適した変更先カタログを提示するシステムが提供される。本実施形態によれば、利用者はインスタンスの物理的な配置や、他のインスタンスとの兼ね合いを意識することなく、所望の計算機環境を構築できる。さらに、管理者により設計されたカタログを移行に採用することで、カスタマイズについてのノウハウを考慮せずとも、アプリケーションに適したサイジングが行える。

（３）第３の実施形態
第３の実施形態では、インスタンスの性能劣化を動機としてユーザが構成変更を要求した際に、性能劣化を解消する移行方策を算出した後、移行を自動的に実施するシステムが提供される。本実施例においては、移行方策を算出する機能性については前の実施例までと共通であるが、さらに算出された移行方策７０２または推奨カタログへの移行を、自動実行する機能を備える点において異なる。

＜移行方策の自動実行＞
本実施形態は以下のように実現される。つまり、本実施形態例では、第１の実施形態または第２の実施形態において、図１２に示す構成（実行条件６０３ｈ）が、移行条件管理テーブル６０３に追加される。そして、移行管理部６０６はこの実行条件に６０３ｈに従って、条件に合致した移行方法を実行する。

移行条件管理テーブル６０３に関して、第１の実施形態または第２の実施形態においては、単に移行にかかる所要時間とコストを積算すればよかった。

しかし、本実施形態においては、各条件６０３ｄに応じて決まる移行方法６０３ｆを実行する順序を保持する必要がある。具体例として、仮想インスタンスから物理インスタンスへ移行し、記憶域の形式を仮想ディスクからボリュームへと変更する場合を考える。この場合、例えば移行元の仮想ディスクが保持していたデータを移行先のボリュームへコピーする手順の前に、移行先ボリュームを作成する手順を行っておく必要がある。また、ベアメタルサーバ用のデバイスドライバをＯＳにインストールする手順は、移行対象データを移行先ボリュームへコピーする手順の後に行わなければならない。

このような移行方法６０３ｆの順序付けを、本実施形態では、移行方法に対する実行条件６０３ｈのように表現する。図１２は、例えば、識別子「＃１２０３」の移行条件が成立した際に実行される移行方法Ａは、該当する実行条件６０３ｈに従って移行条件「＃８０１２」または「＃５９６４」を評価した後に行う必要があることを示している。

一方、移行管理部６０６は、本実施形態において新たに実行キュー６０６ａを有し、実行予定の移行方法６０３ｆの実行順序を保持する。移行管理部６０６は、移行条件管理テーブル６０３を評価する手順において、実行条件６０３ｈを参照し、実行キュー６０６ａに移行方法６０３ｆを設定する。ユーザにより当該移行方策の実施が承認された場合、移行方法６０３ｆが当該実行キュー６０６ａに設定された順序で自動的に実施される。

以上のように、本実施形態では、例えば、図５の移行方策の１つが選択されると、合致する条件が図１２から抽出される。抽出された条件に対応する移行方法６０３ｆの実行順序が実行条件６０３ｈによって自動的に決定されることになる。

なお、複数のインスタンスについて移行要求が行われており、同一装置に対して排他的に移行作業を行う必要があるときなどのスケジューリングを行うために、他の移行作業との進捗を取得したり、実行を待ち合わせるチェックポイントを設けてもよい。ただし、それらチェックポイントは、ユーザや管理者が定義するものや、管理サーバにより機械的に評価可能なものに限られる。

＜第３の実施形態の小括＞
第３の実施形態によれば、性能劣化や性能の余剰を動機としてユーザがインスタンスの構成改善を要求した際に、当該インスタンスを自動的に適切な構成へと移行するシステムが実現される。これにより、各ユーザは自身が利用しているインスタンスの性能に対して不適合であることを察知したときに、システムに対し構成変更を要求するという切っ掛けを与えるのみでよく、どのリソースや管理機能をどの程度変更するのかを管理者とともに逐一検討する負担が生じない。さらに、必ず性能影響の要因を特定して移行方策を提案することで、多くのインスタンスが稼働するクラウド環境全体のリソース効率を高めると同時に、個々のユーザが利用するアプリケーションに適した構成をとることができる。これらの効果は、単にユーザや管理者が普段行うような構成変更作業の自動化では実現できない。

（４）まとめ
（i）本発明の第1の実施形態では、物理サーバ上で稼働中のインスタンス（仮想インスタンス及び物理インスタンス）の性能が劣化或いは性能が過剰とユーザが判断した場合、或いは各インスタンスの構成と各装置（サーバ、ストレージ）の性能情報から性能劣化・過剰と判断された場合（何れの場合にも管理サーバにはインスタンスの構成変更の要求が出されることになる）に、インスタンスの構成の変更案（移行方策）をユーザ（クライアント端末）に対して提供する。より具体的には、管理サーバは、上記要求を受信すると、処理対象の現行インスタンスが設定されている物理サーバにおいて、現行インスタンスが他のインスタンスとの間で処理需要が競合しているか、デバイス管理情報（図９）を参照して判断する。競合していなければ、その物理サーバ上で構成を拡張することが可能であれば、インスタンス（この場合、対象のインスタンスは仮想インスタンスとなる）の構成変更案（リソースの拡張案）を生成してユーザに提示する（図５参照）。競合している場合には、他の物理サーバへの移行を検証して、構成変更案を生成して提示する。このようにすることにより、ユーザは、サーバの物理的な配置や他者のサーバとの競合を気に掛けることなく、所望の処理性能を享受できるようになる。

現行のインスタンスが物理インスタンスの場合には、物理インスタンスのままで、稼働中の物理サーバ上で構成を拡張・縮小することはできない。この場合には、移行先の物理サーバを探して構成変更するか、物理サーバ上の仮想インスタンスに構成変更する。

以上のようにすることにより、多数の業務システムに対するその時々の処理要求に応じて、性能要求の低い処理を仮想化により少数の物理装置に集約したり、性能要求が高い処理をベアメタルサーバで安定的に稼働させたりするといった使い分けが可能となる。

また、他の物理サーバを移行先として検証する場合、管理サーバは、インスタンスの移行先として不適切である示す移行不適合条件（移行条件管理情報：図８参照）を参照して、移行先候補の物理サーバが移行不適合条件に合致せず（図８でＲｅｆｕｓｅｄとならない）、かつインスタンスを生成する十分なリソースを有するか否かを判定する。移行先候補の物理サーバが移行不適合条件に合致する場合（Ｒｅｆｕｓｅｄとなる場合）には、当該移行先候補の物理サーバは、移行先の候補から外される。このように、移行先として不適合な条件を予め定めておくことにより、移行先の物理サーバとして適当か否かを容易に判断できるようになる。

一方、移行先候補の物理サーバが移行不適合条件に合致せず（Ｒｅｆｕｓｅｄとならない場合）、かつ十分なリソースを有すると判定された場合、さらに、移行先候補の物理サーバに他のインスタンスが既に設定されているか否か判定する。既存のインスタンスが移行先に設定されていない場合には、その移行先候補の物理サーバにインスタンスを移行する構成変更案が生成される。既存のインスタンスが移行先に設定されている場合（ただし、この場合には、構成変更案が生成されても推奨度は低くなる）には、既存インスタンスと現行のインスタンスの負荷傾向が競合するか判定する。負荷傾向が競合しなければ、その移行先候補の物理サーバ上でのインスタンスの構成変更案が生成される。負荷傾向が競合する場合（インスタンスの稼働時間に重複があり、両者が同時に稼働できない場合）には、その物理サーバは移行先としては不適と判断され、移行先の候補から外される。このようにすることにより、インスタンスを移行した場合に、その移行先におけるインスタンスの稼働に影響を与えず、より安定的な動作を保証することができるようになる。

（ii）第２の実施形態では、予め推奨される複数のインスタンス構成を含むカタログが用意されている。この場合、管理サーバは、上記生成された構成変更案に近似するインスタンス構成をカタログ情報から抽出し、上記生成された構成変更案と置き換え、近似のインスタンス構成をユーザに提供する。このようにすることにより、カタログからインスタンス構成が選択されるため、構成変更のための処理が予測可能になり、イレギュラーなインスタンスの構成を実現する必要性がなくなる。よって、インスタンス移行（拡張・縮小）処理を効率的に実行することができる。

（iii）第３の実施形態では、予め、所定のパラメータと、そのパラメータが所定の条件を満足する場合に実行される移行方法と、当該移行方法の実行条件とによって構成される、移行実行情報（図１２）を用意する。構成変更案（移行方策：図５参照）の１つがユーザによって選択されると、その構成変更案のＡｃｃｅｐｔｅｄとなっている条件に対応する移行方法が抽出され、その移行方法が対応する実行条件に従って自動的に実行され、構成変更案に従ったインスタンスが設定される。このようにすることにより、自動的にインスタンス移行が実行されるので、ユーザにとってインスタンス変更を実現するための負担がなくなるというメリットがある。

（iv）本発明は、上述のように、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。

１０・・・第１の物理サーバ
１１・・・ＣＰＵ
１２・・・メモリ
１３ａ・・・オペレーティングシステム
１３ｂ・・・アプリケーションプログラム
１５・・・ファイバチャネルインタフェース
１６・・・イーサネットインタフェース
２０・・・第２の物理サーバ
２３ｂ・・・仮想化プログラム
５０・・・ファイバチャネルスイッチ
５１・・・ストレージエリアネットワーク
６０・・・イーサネットスイッチ
６１・・・イーサネットワーク
１００・・・第１のストレージ装置
１５０・・・第１のストレージコントローラ
１５３ａ・・・応答プログラム
１５３ｂ・・・ストレージ制御プログラム
５００・・・管理コンピュータ
５０３ｂ・・・管理プログラム
５０４ａ・・・サービス管理部
５０４ｂ・・・統合サービスレベル管理部
５０４ｃ・・・サーバ装置管理部
５０４ｄ・・・ネットワーク装置管理部
５０４ｅ・・・ストレージ装置管理部
５１０・・・クライアントコンピュータ
５１３ｂ・・・クライアントプログラム
６０１・・・インスタンス管理テーブル
６０２・・・サービスレベル判定部
６０３・・・移行条件管理テーブル
６０４・・・性能履歴格納部
６０５・・・デバイス管理テーブル
６０６・・・移行管理部
６０６ａ・・・実行キュー
７０３・・・移行方策リスト（改善方策リスト）
８０１・・・推奨カタログ

Claims (12)

1. 複数の物理サーバと、少なくとも１つのストレージ装置と、を管理する管理計算機であって、
   前記物理サーバ上のインスタンスの構成情報と、前記物理サーバ及び前記ストレージ装置の性能情報と、を格納する記憶デバイスと、
   前記物理サーバ上のインスタンスの構成変更の要求に応答して、構成変更方法の候補を生成してユーザに提供するプロセッサと、を有し、
   少なくとも１つの物理サーバは、仮想化機構を有し、当該物理サーバのリソースを分割してインスタンスに割り当て、仮想インスタンスとして機能させる、第１種サーバであり、
   前記第１種物理サーバ以外の少なくとも１つの物理サーバは、当該物理サーバのリソースの全てをインスタンスに割り当て、物理インスタンスとして機能させる、第２種サーバであり、
   前記記憶デバイスは、推奨される複数のインスタンス構成を含むカタログ情報を含み、
   前記プロセッサは、
   前記インスタンスの構成変更の要求に応答して、前記記憶デバイスに格納されている前記性能情報を参照し、構成変更対象のインスタンスが設定されている対象物理サーバにおいて、当該構成変更対象のインスタンスが他のインスタンスとの間で処理需要が競合しているか判定する性能競合判定処理と、
   前記性能競合判定処理の結果に基づいて、前記構成変更の対象のインスタンスの構成変更方法の候補を生成する候補生成処理と、
   前記生成された構成変更方法の候補として、仮想インスタンス、及び／又は物理インスタンスの構成を前記ユーザに提供する候補提供処理と、
   を実行し、
   前記候補生成処理において、前記プロセッサは、前記生成された構成変更方法の候補に近似のインスタンス構成を前記カタログ情報から抽出し、前記生成された構成変更方法の候補と置き換え、前記近似のインスタンス構成をユーザに提供することを特徴とする管理計算機。
2. 請求項１において、
   前記性能競合判定処理の結果、前記構成変更対象のインスタンスが他のインスタンスとの間で処理需要が競合していると判定された場合、前記候補生成処理において、前記プロセッサは、前記対象物理サーバとは異なる物理サーバへの移行を移行先候補として検討し、移行先の物理サーバにおけるインスタンスを前記構成変更方法として生成することを特徴とする管理計算機。
3. 請求項１において、
   前記記憶デバイスは、インスタンスの移行先として不適切である示す移行不適合条件を格納し、
   前記候補生成処理において、前記プロセッサは、前記移行先候補の物理サーバが前記移行不適合条件に合致せず、かつインスタンスを生成する十分なリソースを有するか否かを判定する移行条件照会処理を実行し、前記移行先候補の物理サーバが前記移行不適合条件に合致する場合には、当該移行先候補の物理サーバを候補から外すことを特徴とする管理計算機。
4. 請求項３において、
   前記移行条件照会処理の結果、前記移行先候補の物理サーバが前記移行不適合条件に合致せず、かつ十分なリソースを有すると判定された場合、前記プロセッサは、さらに、
   前記移行先候補の物理サーバに他のインスタンスが既に設定されているか否か判定する既存インスタンス判定処理と、
   既存インスタンスが前記移行先候補の物理サーバにあると判定された場合に、当該既存インスタンスと前記構成変更対象のインスタンスの負荷傾向が競合するか判定する負荷傾向判定処理と、
   を実行し、前記移行先候補を生成することを特徴とする管理計算機。
5. 請求項４において、
   前記既存インスタンス判定処理の結果、前記既存インスタンスが前記移行先候補の物理サーバにないと判定された場合、或いは、前記負荷傾向判定処理の結果、前記既存インスタンスと前記構成変更対象のインスタンスとの負荷傾向が競合しないと判定された場合、前記プロセッサは、当該移行先候補の物理サーバへの移行を前記構成変更方法の候補とすることを特徴とする管理計算機。
6. 請求項１において、
   前記構成変更対象のインスタンスは、仮想インスタンスであり、
   前記性能競合判定処理の結果、前記構成変更対象のインスタンスが他のインスタンスとの間で処理需要が競合していないと判定された場合、前記プロセッサは、さらに、前記対象物理サーバにおいて、前記インスタンスの構成変更が可能か否か判定する構成変更判定処理を実行し、
   前記プロセッサは、前記構成変更判定処理の結果、構成変更が可能であると判定された場合、前記候補生成処理において、前記対象物理サーバ上で構成変更して得られるインスタンスの構成変更方法を候補として生成することを特徴とする管理計算機。
7. 請求項１において、
   前記記憶デバイスは、所定のパラメータが所定の条件を満足する場合に実行される移行方法と当該移行方法の実行条件とによって構成される、複数セットの移行実行情報を格納し、
   前記プロセッサは、さらに、前記ユーザによって前記生成された構成変更方法の候補が選択されると、前記複数セットの移行実行情報から、前記選択された候補のパラメータが満足する前記移行方法、及び当該移行方法の実行条件を抽出し、前記抽出された移行方法を前記抽出された実行条件に従って実行することを特徴とする管理計算機。
8. 複数の物理サーバと、少なくとも１つのストレージ装置と、少なくとも１つのクライアント計算機と、請求項１の管理計算機と、を有し、
   前記管理計算機は、前記生成された構成変更方法の候補の情報を前記クライアント計算機に送信し、
   前記クライアント計算機は、前記構成変更方法の候補を表示装置に表示することを特徴とする計算機システム。
9. 請求項８において、
   前記クライアント計算機で表示される構成変更方法の候補の情報は、仮想インスタンスから物理インスタンスへの変更、同一物理サーバにおける仮想リソースの構成変更、及び他の物理サーバへの仮想インスタンスの移行の何れの変更形態であるかを示すインスタンスの変更種別情報と、リソースの安定性を示す情報と、変更に要する時間の情報と、変更に要するコストの情報と、を含むことを特徴とする計算機システム。
10. 複数の物理サーバと、少なくとも１つのストレージ装置と、それらを管理する管理計算機と、を有する計算機システムにおいて、前記物理サーバ上に設定されたインスタンスを管理するインスタンス管理方法であって、
    少なくとも１つの物理サーバは、仮想化機構を有し、当該物理サーバのリソースを分割してインスタンスに割り当て、仮想インスタンスとして機能させる、第１種サーバであり、
    前記第１種物理サーバ以外の少なくとも１つの物理サーバは、当該物理サーバのリソースの全てをインスタンスに割り当て、物理インスタンスとして機能させる、第２種サーバであり、
    前記管理計算機は、推奨される複数のインスタンス構成を含むカタログ情報を保持し、
    前記管理計算機が、前記物理サーバ及び前記ストレージ装置の性能情報と、前記物理サーバ上のインスタンスの構成情報と、を取得し、メモリに格納するステップと、
    前記管理計算機が、インスタンスの構成変更の要求を受信し、当該要求に応答して、前記メモリに格納されている前記性能情報を参照し、構成変更対象のインスタンスが設定されている対象物理サーバにおいて、当該構成変更対象のインスタンスが他のインスタンスとの間で処理需要が競合しているか判定する性能競合判定ステップと、
    前記管理計算機が、前記性能競合判定ステップの実行結果に基づいて、前記構成変更の対象のインスタンスの構成変更方法の候補を生成する候補生成ステップと、
    前記管理計算機が、前記生成された構成変更方法の候補として、仮想インスタンス、及び／又は物理インスタンスの構成をクライアント計算機に提供する候補提供ステップと、
    を含み、
    前記候補生成ステップにおいて、前記管理計算機は、前記生成された構成変更方法の候補に近似のインスタンス構成を前記カタログ情報から抽出し、前記生成された構成変更方法の候補と置き換え、前記近似のインスタンス構成をユーザに提供することを特徴とするインスタンス管理方法。
11. 請求項１０において、
    前記性能競合判定ステップによる処理の結果、前記構成変更対象のインスタンスが他のインスタンスとの間で処理需要が競合していると判定された場合、前記候補生成ステップにおいて、前記管理計算機は、前記対象物理サーバとは異なる物理サーバへの移行を移行先候補として検討し、移行先の物理サーバにおけるインスタンスを前記構成変更方法として生成することを特徴とするインスタンス管理方法。
12. 請求項１１において、
    前記管理計算機は、インスタンスの移行先として不適切である示す移行不適合条件の情報を保持し、
    前記候補生成ステップにおいて、前記管理計算機は、前記移行先候補の物理サーバが前記移行不適合条件に合致せず、かつインスタンスを生成する十分なリソースを有するか否かを判定する移行条件照会処理を実行し、前記移行先候補の物理サーバが前記移行不適合条件に合致する場合には、当該移行先候補の物理サーバを候補から外すことを特徴とするインスタンス管理方法。

Images