JP2012088943A

JP2012088943A - 仮想サーバ管理装置

Info

Publication number: JP2012088943A
Application number: JP2010235174A
Authority: JP
Inventors: Masatomo Ukeda; 賢知受田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2010-10-20
Filing date: 2010-10-20
Publication date: 2012-05-10
Anticipated expiration: 2030-10-20
Also published as: WO2012053243A1; JP5364070B2

Abstract

【課題】
クラウドコンピューティングシステムでは，ユーザ毎に異なる要求に対応した複数のサポート品質が混在するため、最も高いサポートを要求するユーザに合わせて全体を運用するか，高いサポート品質を希望するユーザを除外せざるを得なかった。
【解決手段】
仮想サーバと，仮想サーバが稼働する物理サーバに対して，それぞれのサポート品質の水準を示すサポートレベルを関連付けてクラウド管理サーバで管理する。クラウド管理サーバは，仮想サーバと物理サーバのサポートレベルが一致する状態でのみ，仮想サーバが対象の物理サーバ上で稼働することを許可し，一致しない場合は稼働を許可せず，サポートレベルが一致する物理サーバへ仮想サーバを移動させる。
【選択図】図１

Description

本発明は仮想サーバと，仮想サーバの管理機能を有する管理装置とを備えた情報システムに関する。

VMware vCenter（VMware社）やSCVMM（米Microsoft社）のような仮想サーバ管理ツールは、自動でリソース配置の最適化を行う機能を持つ。それらは、システムの構築時に指定したグループ内の各物理サーバの性能監視を行い、その負荷の傾向等に基づいて，負荷の高い物理サーバから低い物理サーバへ仮想サーバを自動で移動させる機能を持つ。これにより，システム管理者は個々の物理サーバのCPUやメモリの使用状況を手動で管理することなく，自動で適切なリソースの配置が行えるというメリットがある。

特開２０１０−１４６４２０号公報

クラウドコンピューティングシステムでは，ユーザ毎に要求の異なる複数のサポート品質が混在することになる。従来のハウジングサービスでは，ユーザ毎に物理サーバを分け物理サーバ毎にサポート品質を分けていた。しかし，クラウドコンピューティングシステムにおいて，仮想化技術を用い，自動でリソースの管理を行いたい場合，物理サーバの障害に対するSE(System Engineer)やオペレータによる迅速な障害分析と復旧を適切に行うためには，例え，そのような品質を求めるユーザが100台に付き1台のみであったとしても，全ての物理サーバに対して障害対応できる準備を整えておく必要があった。そのため，クラウドコンピューティングシステムの提供者は，最も高いサポートを要求するユーザに合わせて全体を運用するか，高いサポート品質を希望するユーザを除外せざるを得なかった。

また，サポート品質は，同じユーザであっても時間帯，時期に応じて変化するため，仮想サーバと物理サーバのサポートレベルを一致させておくことは困難であり，またサポートレベルに応じて個別に物理サーバを運用する場合では，負荷分散する母数（物理サーバの台数）が減ってしまうため効率的な運用ができなくなるという問題があった。

仮想サーバと，仮想サーバが稼働する物理サーバに対して，サポート品質の水準を示すサポートレベルを関連付けて，クラウド管理サーバで管理する。クラウド管理サーバは，仮想サーバと物理サーバのサポートレベルが一致する場合に，仮想サーバが対象の物理サーバ上で稼働することを許可し，一致しない場合は稼働を許可せず，サポートレベルが一致する物理サーバへ仮想サーバを移動させる。

高付加価値なサポートが必要な仮想サーバを物理サーバの単位で集約して管理することが可能になるため，運用コストを低減する効果がある。

契約の変更等により，サポートレベルが変化した場合でも，適切な物理サーバへ仮想サーバを移動させることが可能となることから，仮想サーバと物理サーバのサポートレベルの差によって，エスカレーション（段階的拡大）ができないようなケースを除外する効果がある。

8時間サポートと24時間サポートのように，特定の時間帯においては２つのサポートのサポート品質が一致するような場合，サポート品質が一致する時間帯においては負荷の変動に応じて仮想サーバの移動可能な物理サーバの母数（台数）を増大させることが可能になるため，安定した性能を提供できるという効果がある。

本発明の実施例１によるクラウドコンピューティングシステムの構成図である。本発明の実施例１によるストレージ１５０で保管されるデータの詳細図である。本発明の実施例１によるクラウド管理ソフトウェア１３５と，仮想サーバ管理ソフトウェア１４５間の通信手順を表すフローチャートである。本発明の実施例１によるクラウド管理ソフトウェア１３５によって実施される配置変更手順の詳細を表すフローチャートである。本発明の実施例１によるクラウド管理ソフトウェア１３５によって実施される移動先検索処理手順の詳細を表すフローチャートである。本発明の実施例２によるクラウドコンピューティングシステムの構成図である。本発明の実施例２によるストレージ１５０で保管されるデータの詳細図である。

図１は本発明を適用したクラウドコンピューティングシステム（以下，クラウドと略する）の構成を表す第１の実施例である。第１の実施例は、クラウド提供者がデータセンタ１００内に計算機システムを構築し，複数の物理サーバ上のそれぞれで仮想サーバを稼働させ，仮想サーバを、データセンタと端末とを接続するネットワーク１１５を通じてユーザ１１２に提供するモデルである。

ユーザ１１２は端末１１０を利用して，データセンタ１００上の仮想サーバを利用する。ユーザ１１２は，クラウドを利用することにより，自分でサーバを所有する必要はなく，利用したい時に仮想サーバを利用することが可能になる。この仕組みを利用してユーザは，仮想サーバを利用して要求に応じたシステムを構築するが，システムの運用においては，データセンタ１００が提供するサービスを利用することになる。

データセンタ１００が提供するサービスとしては，DNS(Domain Name System)サーバ提供サービス，NTP(Network Time Protocol)サーバ提供サービス，SSL(Secure Sockets Layer)証明書発行サービス，死活監視サービス，性能監視サービス，オペレータ作業提供サービス，ソフトウェア保守サービス，バックアップサービス等が該当する。

ユーザは，仮想サーバの利用目的に応じて，これらのサービスの1つまたは複数を利用するが，このようなサービスは提供するサービスの品質に応じて，複数のレベルが設けられていることがある。例えば，ソフトウェア保守サービスは，窓口の対応時間や，問合せ回数等に応じて，サポートレベルが設けられており，サポートレベルに応じた価格差がある。ユーザ１１２は，コストや利用目的に適したレベルのサービスを契約し，利用することになる。クラウドは，複数のユーザが仮想化技術を利用するために、1つまたは複数の物理的なシステムを論理的に分割し，その仮想的なシステムを個々のユーザに提供するサービスである。

ユーザ１１２が個々に要求する利用目的や投資額が異なるため，各ユーザが契約する複数のサポートレベルが，クラウド上で混在する状態になる。このとき，仮想サーバがどの物理サーバ上にあっても良いならば，物理サーバの負荷状況に合わせて仮想サーバを移動するなどして，物理サーバの負荷を平均化することが可能となる。しかし，あるユーザが障害発生時の原因の切り分けをサポートサービスに含めている場合には，仮想サーバがどの物理サーバ上であっても均質なサポートを提供できるように，最も高品質なサポートを要求するユーザの水準で全ての物理サーバを運用する必要が生じるので，運用コストが高くなるという問題がある。

これとは逆に，仮想サーバと物理サーバの関係が密（固定的）であるほど，高品質なサポートを要求する仮想サーバと，品質の要求が厳しくない仮想サーバとをそれぞれ物理サーバレベルで分けて管理することが可能になるため，運用コストを抑えられる。しかし，仮想化技術を利用した集約の効果が薄れるため，物理サーバをレンタルでユーザに提供するホスティングサービスとの差異がなくなり，低価格なサービスをユーザに提供できないという問題がある。本発明では，この課題を解決する。

図１において、ユーザ１１２は端末１１０を利用し，ネットワーク１１５を通じてデータセンタ１００上にある仮想サーバ１７０にアクセスするものとする。

データセンタ１００は，仮想サーバと端末１１０を接続するためのネットワーク１１５からの通信を適切な仮想サーバに受け渡すルータ１２０と，ルータ１２０に接続され，ネットワーク１１５からデータセンタ１００及びデータセンタ１００からネットワーク１１５への許可されていない通信を遮断するファイアウオール１２５と，ルータ１２０に接続され，仮想サーバが動作する物理サーバ１６０、１６２及び１６４と，物理サーバ１６０、１６２及び１６４に接続され、物理サーバ１６０、１６２及び１６４のデータの保管とデータ共有のために利用されるストレージ１８０と，物理サーバ１６０、１６２及び１６４上で動作する仮想サーバ１７０、１７２、１７４及び１７６と，それらを管理する仮想サーバ管理サーバ１４０と，仮想サーバ管理サーバ１４０に接続され，仮想サーバ管理サーバ１４０に対して指示を行うクラウド管理サーバ１３０と，クラウド管理サーバのデータを保管するストレージ１５０から構成される。

ここで，端末１１０は，PCや携帯電話，ゲーム機などのデバイスや，企業内やインターネットに公開されるサーバであってもよい。ネットワーク１１５は，インターネットや，VPN(Virtual Private Network)，専用線，無線通信，電話網及びそれらの組み合わせにより構築される通信回線であってもよい。ルータ１２０は，ネットワークのルーティング機能のみを持つ装置に限定されず，L3スイッチ，L2スイッチ，ロードバランサ，NAT(Network Address Translation)等を含む構成でもよく，複数の装置の集合により構成されていても良い。

ファイアウオール１２５は，ディープパケットインスぺクション機能や，ウイルス検知機能，侵入検知機能等を有する構成でもよい。また，これらの機能が物理サーバまたは仮想サーバ上のソフトウェアの一機能として実現されている場合には，仮想サーバまたは物理サーバ上で用意されていてもよい。また、特段のセキュリティが不要である場合には，ファイアウオール１２５は未接続であってもよい。

ストレージ１８０は，物理サーバ１６０、１６２及び１６４と接続されているが，ルータ１２０を経由して仮想サーバの移動が可能であるならば，各物理サーバが個別にストレージを有し，ストレージ１８０を共有しなくても良い。ストレージ１８０と物理サーバ１６０、１６２及び１６４との接続形態は，本発明の特徴に関係しないため，ファイバーチャネル，iSCSI，SATA，IEEE1394，USB，LAN等，通信方式に依らない。

また，図１は、物理サーバと仮想サーバの台数や，物理サーバ上の仮想サーバの配置は，本発明を説明のための一例であり，図１の配置は、物理サーバや仮想サーバの台数に依存しない。これは図4及び図５に示すように，本発明では，クラウド管理サーバまたは仮想サーバ管理サーバに接続された全仮想サーバ及び物理サーバを対象としているためである。

仮想サーバ管理サーバ１４０は，仮想サーバや物理サーバの性能監視機能と，物理サーバ間で仮想サーバを移動する機能，物理サーバの性能監視結果に基づき，どの物理サーバで仮想サーバを動作させるのが適しているかを評価する機能等を有する，仮想サーバ管理ソフトウェア１４５を有している。

仮想サーバ管理ソフトウェア１４５としては，VMware vCenter(VMware社の登録商標である)や，SCVMM（Microsoft System Center Virtual Machine Managerの略であり，Microsoft社の製品の名称である）等が該当する。これらはそれぞれ，仮想化技術を利用して仮想化されたハードウェアの制御を行うための製品である。ただし，本発明における仮想化技術は，個々の物理サーバが，ハードウェアまたはソフトウェアまたはその両者を用いて，単一のハードウェアを複数のハードウェアであるかのように制御する機構を備えたものであればよく，本発明は仮想サーバの配置制御だけに関するので，仮想化技術の実施形態に制約をうけるものではないことは言うまでもない。

また、仮想サーバ管理ソフトウェア１４５に含まれる機能は，単一のソフトウェアにより実現される必要はなく，複数のソフトウェアの組み合わせで実現されるものであっても良い。例えば，物理サーバの監視機能と，仮想サーバの監視機能は別のソフトウェアにより実現されても良く，仮想サーバの移動機能と，性能監視結果により仮想サーバの稼働場所を判断する機能は別のソフトウェアにより実現されても良い。本発明による，仮想サーバの配置制御機能は，性能のような，仮想サーバや物理サーバから得られた情報のみではなく，仮想サーバや物理サーバをどのように運用するかというポリシーに基づき制御を行うものであり，仮想サーバ管理ソフトウェア１４５の構成により効果を減ずるものではない。

クラウド管理サーバ１３０は，仮想サーバと物理サーバのサポートレベルを管理する機能と，仮想サーバと物理サーバのサポートレベルが同じ範囲であれば，仮想サーバ管理ソフトウェア１４５に基づき仮想サーバの移動を行い，仮想サーバと物理サーバのサポートレベルの範囲が異なる場合には仮想サーバ管理ソフトウェア１４５による仮想サーバの物理サーバ間の移動は行わず，サポートレベルが異なる状態にある場合には，サポートレベルが一致する物理サーバに仮想サーバを仮想サーバ管理ソフトウェア１４５を用いて移動させる機能を有する，クラウド管理ソフトウェア１３５を有する。また，クラウド管理サーバ１３０は，ストレージ１５０に、クラウド管理ソフトウェア１３５により利用される，仮想サーバ管理データ１５２，物理サーバ管理データ１５４，サポートレベル管理データ１５６及びサービス管理データ１５８を保管している。ここで，ストレージ１５０は，クラウド管理サーバ１３０に接続された論理ディスクであればよく，本発明が，その接続形態，ストレージ１５０の物理的な配置に依存しないものであることは言うまでもない。

図１ではクラウド管理サーバ１３０と仮想サーバ管理サーバ１４０の２つのサーバで制御を行っているが、これら２つのサーバで行っている制御を１台の仮想サーバ管理装置で実施する形態でもよい。

図2は，仮想サーバ管理データ１５２，物理サーバ管理データ１５４，サポートレベル管理データ１５６及びサービス管理データ１５８の詳細を表している。
仮想サーバ管理データ１５２は，仮想サーバ毎に１つずつ定義される、仮想サーバをサポートレベルに応じて移動させるための情報であり、仮想サーバ名２１０，サポートレベルフラグ（以下，SLFと略す）２１２，物理サーバ名２１４，前回移動時刻２１６，未移動回数２１８及び性能情報２１９を有する。仮想サーバ名２１０は，仮想サーバ毎にユニークな識別子である。SLF２１２は，仮想サーバが提供するサポート品質の水準を表す識別子である。物理サーバ名２１４は，現在仮想サーバ名２１０により識別される仮想サーバが存在する物理サーバのユニークな識別子である。前回移動時刻２１６は，仮想サーバが前回移動した時刻である。仮想サーバの頻繁な移動は，システムの負荷を増大させる危険性がある。仮想サーバの頻繁な移動を個別に制御したい場合，この情報２１６を利用する。

ただし、仮想サーバ管理データ１５２は、いくつかの仮想サーバがクラスタとして組まれているなど、複数の仮想サーバを同時に移動させる必要がある場合、仮想サーバ群として用意されていてもよい。この時、仮想サーバ名２１０は、仮想サーバ単体とは異なる情報が付加された仮想サーバ群の識別子であってもよい。

未移動回数２１８は，仮想サーバ管理ソフトウェア１４５から推奨された移動先があるにもかかわらず，クラウド管理ソフトウェア１３５での判断の結果，仮想サーバを移動しないことにした回数を表している。ある単位期間の未移動回数２１８が多い場合，物理サーバへの仮想サーバの割当てに余裕がない等の，構成上の不一致や，サポートレベルの差に応じた適切な物理サーバが十分に用意されていない可能性を判断できる。定期的にこの情報２１８を確認することで，サポートレベルに応じた物理サーバの比率や数を変更し，より効率的な運用を行うことが可能になる。

性能情報２１９は，仮想サーバが要求する性能の水準を指す。仮想サーバが要求する性能の水準には，仮想サーバに割り当てる仮想CPUのタイムスライスの量や，仮想メモリ及び仮想ディスクの量，仮想サーバに割り当てるネットワークやストレージへのI/O帯域が含まれている。新規に仮想サーバを作成する場合や，仮想サーバを別の物理サーバに移動させる際には，この性能情報２１９に示すスペックが満たせるかどうかを基に，仮想サーバ移動の可否を判断する。

物理サーバ管理データ１５４は，物理サーバに１つずつ定義される、どういったサポートレベルの仮想サーバを物理サーバで稼動可能化させるかを制御するための情報であり、物理サーバ名２２０，SLF２２２，性能監視ログ２２４，推奨性能閾値２２６及び性能情報２２８を有する。物理サーバ名２２０は，物理サーバ毎にユニークな識別子である。SLF２２２は，その物理サーバ上で動作することを許可する仮想サーバのサポート品質の水準を表す識別子である。

性能監視ログ２２４は，物理サーバの性能監視ログまたは，性能監視ログの格納先アドレスを保管する。性能監視ログ２２４としては，仮想サーバのCPU使用率，仮想メモリ使用量，仮想ディスクの使用量，ネットワーク転送量及びストレージへのデータ転送量等が含まれており、さらに、1日や1ヵ月などの一定期間における平均の使用率やピーク負荷，ピーク負荷時のリソースの不足量などが保管されている。

推奨性能閾値２２６は，定常状態での各性能情報の推奨利用量である。クラウドの運用では，他の物理サーバの故障等により，故障した物理サーバ上の仮想サーバを別の物理サーバへ移動できる場合があり，そのためには，移動先の物理サーバに余裕がなければ，既に存在している仮想サーバの性能に大きな影響が生じてしまう。そこで，予め想定する同時故障発生量に応じて余裕を持たせておくための物理サーバ毎の性能が，推奨性能閾値２２６である。クラウド管理ソフトウェア１３５は，全ての物理サーバの推奨性能閾値２２６に対する性能監視ログ２２４に基づく現在の平均値の分散が最小になるように配置制御を行う。

性能情報２２８は，各物理サーバの物理的な性能である。物理サーバに仮想化技術を用いることで，仮想サーバの集約の効果が見込める場合，性能情報２２８を超えて，性能推奨閾値２２６の設定が可能である。

サポートレベル管理データ１５６は，サポートレベルの種類毎に１つずつ定義される、各サポートレベルの仮想サーバをどの時間帯に物理サーバに割り当てるかを定義した情報であり、サポートレベル２３０，開始時間２３２及び終了時間２３４を有する。サポートレベル２３０は，SLF２１２が示すサポートレベルを表す識別子である。開始時間２３２はサポートの開始時間，終了時間２３４はサポートの終了時間である。例えば，朝9時から夕方１７時までのサポートの場合は，開始時間２３２として「９」を，終了時間２３４として「１７」を設定する。24時間サポートの場合は，開始時間２３２と終了時間２３４に0以外の同じ数字を設定することで表現しても良い。サポートレベル管理データ１５６としては，この他に，サポートを実施する曜日に関するデータ，監視内容に関するデータ，オペレータの有無に関するデータ，SEの有無に関するデータ，窓口の開設の有無に関するデータ及びインシデントの回数に関するデータ等が含まれていても良い。

サービス管理データ１５８は，システム毎に１つずつ用意される、サポートレベルを満足する範囲で、仮想サーバの移動回数や物理サーバの負荷を抑えて運用するための情報であり、移動頻度２４０及び構成変更閾値２４２を含む。移動頻度２４０は，前回移動時刻２１５から，どれだけ時間が経った後に仮想サーバの移動を許可するかを示す値である。構成変更閾値２４２は、未移動回数２１８に基づき，物理サーバの構成変更を推奨する際の閾値であり，1ヵ月の未移動回数２１８が構成変更閾値２４２を超えた場合，物理サーバの構成変更のためのアラートを上げることができる。ただし、サービス管理データ１５８は、システム毎に複数用意され、そのうちの一つが、時間帯や電力価格などの観点で選択されるものであってもよい。

図1では，クラウド管理ソフトウェア１３５はクラウド管理サーバ１３０上で動作するように記載されているが，仮想サーバ管理サーバ１４０上にインストールされて利用される形であってもよく，仮想サーバ管理サーバ１４０のソフトウェア上の機能ブロックであっても良い。なお、クラウド管理ソフトウェア１３５と仮想サーバ管理ソフトウェア１４５を別ソフトウェアとして分けた場合，クラウド管理ソフトウェア１３５は，仮想サーバ管理ソフトウェア１４５が性能監視結果に基づいて導出した推奨配置案に基づき，サポートレベルの一致する範囲内で仮想サーバを移動させることで，サポートレベルを一致させつつ，物理サーバの負荷の均等化を行えるようになるという効果がある。

本発明では，仮想サーバの性能が十分かどうか，さらに仮想サーバのサポートレベルが物理サーバのサポートレベルと一致しているかどうかを定期的に調べ，調べた結果に基づいて仮想サーバを移動させる処理を行う。

図４は，クラウド管理ソフトウェア１３５が行う配置変更処理の詳細を表している。クラウド管理ソフトウェア１３５は，定期的に配置変更処理を開始する（４００）。クラウド管理ソフトウェア１３５は，仮想サーバ管理データ１５２を調べ，登録されている仮想サーバを選択する（４０２）。次に、クラウド管理ソフトウェア１３５は，仮想サーバがどの物理サーバ上にあるかという情報と，適切な移動先、即ち、仮想サーバのサポートレベルと同じサポートレベルの物理サーバを調べる（４０４）。クラウド管理ソフトウェア１３５は，仮想サーバ管理ソフトウェア１４５が適切な移動先を検索する機能を有する場合，仮想サーバ管理ソフトウェア１４５に適切な移動先を問い合わせてもよいし，自身で判断してもよい。

図3は、図４の手続き４０４における仮想サーバ管理ソフトウェア１４５に適切な移動先を問い合わせる場合の手順の一例を表している。クラウド管理ソフトウェア１３５は、仮想サーバ管理ソフトウェア１４５に対して，仮想サーバ名３１２を含む問合せ情報３１０を送付する。仮想サーバ管理ソフトウェア１４５は、仮想サーバ名３１２の仮想サーバの動作に適した物理サーバを検索する。仮想サーバ管理ソフトウェア１４５は，仮想サーバ名３１２と同じ仮想サーバ名３２２と物理サーバ名３２４を含む推薦情報３２０をクラウド管理ソフトウェア１３５に送信する。クラウド管理ソフトウェア１３５は，推薦情報３２０に含まれる物理サーバへの移動を許可する場合，仮想サーバ名３３２と物理サーバ名３３４を含む移動指示３３０を仮想サーバ管理ソフトウェア１４５に送信することで，仮想サーバ管理ソフトウェア１４５は仮想サーバの移動処理を行う。移動が終了すると，仮想サーバ管理ソフトウェア１４５は，移動結果３４２を含む完了通知３４０をクラウド管理ソフトウェア１３５に送信する。ここで，推薦情報３２０とは異なる物理サーバに仮想サーバを移動させたい場合，推薦情報３２０の物理サーバ名３２４と移動指示３３０の物理サーバ名３３４は一致する必要はなく，移動先としてより適した物理サーバ名を含めて送信すればよい。

図５は，図４の手続き４０４において、クラウド管理ソフトウェア１３５が仮想サーバ管理ソフトウェア１４５に適切な移動先を問い合わせずに，自身で移動先を判断する場合の手順を表している。クラウド管理ソフトウェア１３５は手続き４０４で外部のソフトウェアを利用しない場合，移動先検索処理を開始する（５００）。クラウド管理ソフトウェア１３５は，検索処理が開始されると，ストレージ１５０に含まれる，物理サーバ管理データ１５４を調べる（５０２）。次にクラウド管理ソフトウェア１３５は，物理サーバ管理データ１５４に含まれる性能監視ログ２２４を調べ，これと推奨性能閾値２２６との差を調べる（５０４）。

性能監視ログ２２４の期間内における物理サーバの性能の平均が，推奨性能閾値２２６と仮想サーバの性能情報２１９の和よりも大きい場合、即ち、移動対象の仮想サーバを追加する以前に既に性能の負荷が大きい場合（５０６），仮想サーバの移動が必要と判断し（５０８），そうでない場合，移動は不要と判断したとの結果を返し（５１４），処理を終了する（５２０）。

移動処理が必要であると判断した場合，次に、仮想サーバの移動先となりうる他の物理サーバに対する性能監視ログ２２４の期間内における性能の平均と仮想サーバの性能情報２１９の和が，推奨性能閾値２２６より小さい場合、即ち、移動対象の仮想サーバを移動させても性能に余裕がある場合（５１０），検索された物理サーバを結果として返し（５１２），処理を終了する（５２０）。

そうでない場合，まだ未検索の物理サーバがあるなら（５１６），別の物理サーバに対して手続き５１０を実行する。そうでない場合，移動可能な物理サーバなしと判断した結果を返し（５１８），処理を終了する（５２０）。

ここで，最初に見つかった物理サーバの結果を返す代わりに，全ての物理サーバについて、各物理サーバの性能監視ログ２２４と推奨性能閾値２２６との差を調べ、最も差の大きな物理サーバを結果として返しても良い。手続き５１０で、全ての物理サーバで、性能監視ログ２２４の期間内平均と仮想サーバの性能情報２１９との和が推奨性能閾値２２６と同じか，推奨性能閾値２２６より大きな場合でも，手続き５０６で求めた性能監視ログ２２４と，推奨性能閾値２２６と性能情報２１９の和との差よりも小さい値（物理サーバの性能監視ログ２２４と推奨性能閾値２２６との差）が見つかるのであれば，見つかった値を推奨値として返しても良いし，別の移動を行うことでこの差を大きくできるのなら，その順序を含めて推奨値としてもよい。

図４において、クラウド管理ソフトウェア１３５は手続き４０４で前記手段等を用いて適切な移動先を調べると共に，仮想サーバ管理データ１５２に記載の仮想サーバ名２１０に対応した物理サーバ名２１４を調べることで現在仮想サーバが稼働している物理サーバを調べても良い。クラウド管理ソフトウェア１３５は，図４に示すように、検索結果の物理サーバ名を基に，物理サーバ管理データ１５４を調べ， SLF２１２とSLF２２２が一致しているかどうかを確かめる（４０６）。即ち、仮想サーバと物理サーバとでサポートレベルが一致しているかどうかを確かめる。サポートレベルが一致していない場合で，手続き４０４で適切な仮想サーバ見つかっている場合（４０８），移動先の物理サーバの現時刻におけるサービスのサポートの有無が，仮想サーバと一致しているなら（４１０），仮想サーバを指定の物理サーバへ移動させる（４２２）。

ここで、サポートの有無の比較方法を説明する。クラウド管理ソフトウェア１３５は、現在移動対象となっている仮想サーバのＳＬＦ２１２を利用し、ＳＬＦ２１２とサポートレベル２３０が一致しているサポートレベル管理データ１５６を検索し、開始時間２３２と終了時間２３４を調べる。次に、物理サーバの物理サーバ管理データ１５４のＳＬＦ２２２を利用し、ＳＬＦ２１２とサポートレベル２３０が一致しているサポート管理データ１５６を検索し、同様に開始時間２３２と終了時間２３４を調べる。ここで、仮想サーバと物理サーバが共にサポート時間内にあるか、共にサポート時間内にない場合、サポートの有無が一致しているとみなす。そうでない場合、サポートの有無は一致していないとみなす。ただし、ＳＬＦ２１２とＳＬＦ２２２の識別子が一致している場合は、開始時間２３２と終了時間２３４を利用した比較を省略し、サポートの有無が一致しているとみなしてもよい。

手続き４０４で適切な移動先が見つかっていない場合や，移動先は見つかっていても，サービスのサポートの有無が一致しない場合は，サポートの有無が一致する物理サーバを選択し，手続き４２２を実行する。ここでサポートの有無が一致する物理サーバとして，サポートの有無が一致する物理サーバの中で最も条件に一致した、即ち、サービスのサポートが最も類似している物理サーバを選択することにしてよいし，サポートの有無が一致する物理サーバの中から任意の1つを選択しても良い。

クラウド管理ソフトウェア１３５は、図4に記載の配置変更処理により定期的に負荷を分散するので，一時的に負荷が増大しても長期的には平均化される。ただし，CPUやメモリの制約により，推奨性能閾値２２６より一定値を超えて仮想サーバを追加できないと定めている場合は，予め定めた条件を満たす物理サーバを検索して割り当てても良い。このとき，物理サーバ管理データ１５４として，予め定めた条件の中に上限値を含んでもよい。例えば，ここで上限値としてメモリ４０GBと設定している場合，物理サーバで動作している仮想サーバの性能情報２１９に含まれるメモリの合計が４０GBを超える設定はできないとしてもよい。条件を満たす仮想サーバがない場合は，クラウドシステムの管理者にアラートを発行しても良い。

図４において、現在の仮想サーバと物理サーバのサポートレベルが一致している場合であっても，仮想サーバの移動先がない場合（４１４），この仮想サーバの移動処理は終了し，対象の全ての仮想サーバに対する検索が終了していない場合は（４２８），他の仮想サーバに対して手続き４０２を実行し，全ての仮想サーバの検索が終了している場合は，処理を終了する（４３０）。現在の仮想サーバと物理サーバのサポートレベルが一致している場合であって、かつ、仮想サーバの移動先がある場合，その移動先の物理サーバにおけるサービスのサポートの有無が，仮想サーバにおけるサービスのサポートの有無と一致しているかどうかを調べる（４１６）。サポートの有無が一致していない場合，未移動回数２１８をカウントアップし（４２６），仮想サーバを移動させず，手続き４２８を実行する。

サポートの有無が一致している場合は，次に，仮想サーバの前回移動からの経過時間を前回移動時刻２１６に基づいて調べる（４１８）。ここで，前回移動時刻２１６と現在時刻の差が，移動頻度２４０に満たない場合（４２０），頻繁な移動をさけるために，仮想サーバの移動は行わず，手続き４２８を実行する。そうでない場合，仮想サーバを指定の物理サーバへ移動（４２２）し，仮想サーバ管理データ１５２，物理サーバ管理データ１５４を移動後の情報に変更し，手続き４２８を実行する。上記の処理で仮想サーバを移動しないと判断された場合、その旨を仮想サーバ管理サーバ１４０に通知する。

クラウド管理ソフトウェア１３５は，定期的に未移動回数２１８が構成変更閾値２４２を超えていないかを確認しても良い。未移動回数２１８が構成変更閾値２４２を超えている場合，SLF２２２によって分類される物理サーバの比率が適正でない可能性があるため，構成変更を実施しても良い。

図６は、サポートレベルの違いによってグループ化された複数の物理サーバに対して本発明を適用したクラウドの構成を表す第２の実施例である。図6では、図1に示した物理サーバ１６０及び１６２がグループ６１０に属しており，物理サーバ１６４がグループ６２０に属している。ここでグループ６１０及び６２０は，サポートレベルの違いによってまとめられたグループとする。実施例１では，物理サーバ毎にSLF２２２を定めていたが，実施例２ではグループ毎にSLF６４４（後述の図７参照）を定めている。これに伴い，図6におけるストレージ１５０の物理サーバ管理データ６３０及びグループ管理データ６４０の詳細は図7のようになる。

上記の物理サーバのグループは、サポートレベルの管理単位を、物理サーバ単体、あるいは物理サーバ群とするかによって決まるグルーピングです。一方、仮想サーバのグループは、クラスタ構成等、複数の仮想サーバをセットで移動させる必要がある場合のグルーピングです。物理サーバのグループは、物理サーバをどのように管理するかに応じてグループの組み換えが可能ですが、仮想サーバのグループは、システムの性能や信頼性を維持するために、基本的にグループの組み換えはできません。即ち、仮想サーバのグループは移動させる単位であり、物理サーバのグループは同じサポートレベルのものとして管理する単位です。さらに、仮想サーバ又は仮想サーバ群（グループ化された仮想サーバ）は、サポートレベルが一致する物理サーバ又は物理サーバ群（グループ化された物理サーバ）で稼動可能です。

一般に、仮想化技術を利用すると、ＯＳからは、仮想化されたＣＰＵが、１つのＣＰＵとして認識されます。つまり、１個のＣＰＵを１０個のＣＰＵに見せかけ、１０台の仮想サーバを動作させることが可能です。逆に、４つのＣＰＵを１つの高速なＣＰＵに見せかけることも可能です。従って、１つの仮想サーバを動作させるＣＰＵ（物理サーバ）の台数はシステムの構成に応じて様々ですが、通常、仮想サーバの台数＞物理サーバの台数となっています。

図７において，物理サーバ管理データ６３０は，物理サーバ名２２０，グループ名６３２，前回移動時刻６３４，性能監視ログ２２４，推奨性能閾値２２６及び性能情報２２８を含んでいる。ここでグループ名６３２は，グループ毎にユニークな識別子である。また、前回移動時刻６３４は，物理サーバがそのグループに追加された時刻である。グループ管理データ６４０は，グループ名６４２，ＳＬＦ６４４を含んでいる。グループ名６４２はグループ毎にユニークな識別子を指す。ＳＬＦ６４４は，グループに属する物理サーバのサポートレベルである。実施例２では，図5の手続き４１２において，検索する対象を同じグループを対象とした検索とするようにフローチャートを変更することで実現される。このように物理サーバがグループ化されておりグループ間で仮想サーバ及び物理サーバが変更される場合においても，サポートレベルに応じた制御を実施できる。

本実施例でも、ＳＬＦは、サポートレベル管理データを参照するための情報として使っており、各サポートレベルにはサポート時間が定義されています。仮想サーバと物理サーバのそれぞれのグループの一方がサポート時間内であるのに、他方がサポート時間外である場合、双方のグループの間でサポートの品質が一致しない時間帯が発生するため、仮想サーバのグループを移動させる必要があります（一致している場合のみ、そのまま稼動し続けることができます）。

本実施例のように、サポートレベルが同じ複数の物理サーバをグループで管理することにより、検索対象の物理サーバ管理データ１５４の数を低減できるため、検索処理を高速化できる。

また、グループ内に複数の物理サーバがある場合、手続き４０４の結果として移動先の候補が同じグループ内にあるならば、その物理サーバに優先的に仮想サーバを移動させてもよい。移動先の候補が同じグループ内にない場合、サポートレベルが一致する別のグループの物理サーバに仮想サーバを移動させてもよい。移動先の候補がない場合、サポートレベルが一致する任意の物理サーバに仮想サーバを割り当ててもよい。このように、仮想サーバの移動先の物理サーバを検索する際に、サポートレベルが同じ複数の物理サーバがグループ化されていると、物理サーバのグループ内を検索するだけでよいのでサポートレベルが同じ移動先の検索が容易になる。

１００…データセンタ
１１０…端末
１１５…ネットワーク
１２０…ルータ
１１６・１６２・１６４…物理サーバ
１７０・１７２・１７４・１７６…仮想サーバ
１３０…クラウド管理サーバ
１３５…クラウド管理ソフトウェア
１４０…仮想サーバ管理サーバ
１４５…仮想サーバ管理ソフトウェア

Claims

それぞれで少なくとも１つの仮想サーバ又は仮想サーバ群が動作する複数の物理サーバ、前記仮想サーバ又は仮想サーバ群及び前記物理サーバを監視して制御を行う仮想サーバ管理装置とを含む計算機システムにおいて、前記仮想サーバ管理装置は、
前記仮想サーバ又は仮想サーバ群が稼動する前記物理サーバを移動する際に、前記仮想サーバ又は仮想サーバ群が要求するサービスのサポートレベルを示す第１の管理情報と，前記物理サーバが前記サポートレベルを要する前記仮想サーバ又は仮想サーバ群の稼働に適しているかどうかを示す第2の管理情報とに基づき，移動先の前記物理サーバが前記仮想サーバ又は仮想サーバ群の稼働に適すかどうかを判断する手段、
前記物理サーバが前記仮想サーバ又は仮想サーバ群の稼働に適さない場合は、前記仮想サーバ又は仮想サーバ群を，移動先の前記物理サーバに移動させない通知を出力する手段を有することを特徴とする仮想サーバ管理装置。
前記仮想サーバ又は仮想サーバ群の移動先があっても移動させなかった未移動回数が構成変更の閾値を超えたときに、物理サーバの構成変更のアラートを出すことを特徴とする請求項１に記載の仮想サーバ管理装置。
前記仮想サーバ又は仮想サーバ群の移動先を決定する際に、前記仮想サーバ又は仮想サーバ群を管理する第１の管理手段に前記仮想サーバ又は仮想サーバ群の動作に適した物理サーバを問い合わせることを特徴とする請求項１に記載の仮想サーバ管理装置。
端末から前記仮想サーバ又は仮想サーバ群にアクセスするための第２の管理手段が、各物理サーバの性能監視ログの性能情報と、性能閾値と、仮想サーバ又は仮想サーバ群の性能情報とに基づいて、前記仮想サーバ又は仮想サーバ群の移動の要否を判断し、移動可能な物理サーバを決めることを特徴とする請求項１に記載の仮想サーバ管理装置。
さらに、前記物理サーバのサポートレベルが前記仮想サーバ又は仮想サーバ群のサポートレベルと一致するかどうかを確認することを特徴とする請求項３、４のいずれかに記載の仮想サーバ管理装置。
サービスのサポートの有無が一致しない場合、サポートの有無が一致する別の物理サーバに前記仮想サーバ又は仮想サーバ群を移動することを特徴とする請求項１に記載の仮想サーバ管理装置。
性能閾値より一定値を超えて前記仮想サーバ又は仮想サーバ群を追加できない場合、予め定めた条件を満たす物理サーバを検索して前記仮想サーバ又は仮想サーバ群に割り当てることを特徴とする請求項４に記載の仮想サーバ管理装置。
サービスのサポートが一致している場合であっても、前記仮想サーバ又は仮想サーバ群の前回移動時刻と現在時刻との差が移動頻度に満たない場合は、前記仮想サーバ又は仮想サーバ群の移動を行わないことを特徴とする請求項５に記載の仮想サーバ管理装置。
サポートレベルに応じて複数の物理サーバをグループ化し、グループ内の物理サーバの負荷が大きくなった場合に、グループ内の他の物理サーバに仮想サーバ又は仮想サーバ群を移動することを特徴とする請求項１に記載の仮想サーバ管理装置。
それぞれで少なくとも１つの仮想サーバ又は仮想サーバ群が動作する複数の物理サーバ、前記仮想サーバ又は仮想サーバ群及び前記物理サーバを監視して制御を行う仮想サーバ管理装置とを含む計算機システムにおいて、前記仮想サーバ管理装置は、
前記仮想サーバ又は仮想サーバ群が稼動する前記物理サーバを移動する際に、前記仮想サーバ又は仮想サーバ群が要求するサービスのサポートレベルを示す第１の管理情報と，前記物理サーバが前記サポートレベルを要する前記仮想サーバ又は仮想サーバ群の稼働に適しているかどうかを示す第2の管理情報とに基づき，移動先の前記物理サーバが前記仮想サーバ又は仮想サーバ群の稼働に適すかどうかを判断し、
前記物理サーバが前記仮想サーバ又は仮想サーバ群の稼働に適さない場合は、前記仮想サーバ又は仮想サーバ群を，移動先の前記物理サーバに移動させない通知を出力することを特徴とする仮想サーバ管理方法。
それぞれで少なくとも１つの仮想サーバ又は仮想サーバ群が動作する複数の物理サーバ、前記仮想サーバ又は仮想サーバ群及び前記物理サーバを監視して制御を行う仮想サーバ管理装置とを含む計算機システムにおいて、前記仮想サーバ管理装置は、
前記仮想サーバ又は仮想サーバ群が稼動する前記物理サーバを移動する際に、前記仮想サーバ又は仮想サーバ群が要求するサービスのサポートレベルを示す第１の管理情報と，前記物理サーバが前記サポートレベルを要する前記仮想サーバ又は仮想サーバ群の稼働に適しているかどうかを示す第2の管理情報とに基づき，移動先の前記物理サーバが前記仮想サーバ又は仮想サーバ群の稼働に適すかどうかを判断する第１の手段、
前記仮想サーバ又は仮想サーバ群の稼動に適す物理サーバの性能監視ログの性能情報と、性能閾値と、移動対象の前記仮想サーバ又は仮想サーバ群の性能情報とに基づいて、前記仮想サーバ又は仮想サーバ群の移動の要否を判断する第２の手段、
前記仮想サーバ又は仮想サーバ群の前回移動時刻と現在時刻との差が移動頻度に満たない場合は、前記仮想サーバ又は仮想サーバ群の移動を行わないと判断する第３の手段、
前記第１、第２及び第３の手段に基づいて、前記仮想サーバ又は仮想サーバ群を移動しない場合は、前記仮想サーバ又は仮想サーバ群が稼動する前記物理サーバを移動させない通知を出力する手段を有することを特徴とする仮想サーバ管理装置。