JP2011039740A - サーバ管理システム、サーバ管理方法、及びプログラム - Google Patents

Abstract

【課題】コストを抑えると共にサービス・レベル・アグリーメント（ＳＬＡ）違反を回避するサーバ管理システム等を提供する。
【解決手段】サーバ管理システム１は、サービスレベル管理テーブルに記憶されているサービスレベルに関わる情報を基に、仮想マシンで構成された複数のシステムのうち、ＳＬＡ違反が発生する危険性のあるシステムを自動的に高可用性の環境に移行させる。具体的に、冗長構成可能な場合には仮想マシンを物理サーバ１０及び２０上に追加してクラスタを構成する一方で、冗長構成が取れない場合には、ＦＴサーバ３０に移行する。また、ＳＬＡの計算単位期間終了後には、ＦＴサーバ３０に移動したシステムや冗長構成にしたシステムを元のシングル構成に戻す。
【選択図】図１

Description

本発明は、サーバ管理システム、サーバ管理方法、及びプログラムに関し、特に、コストを抑えると共にサービス・レベル・アグリーメント（ＳＬＡ）違反を回避するサーバ管理システム、サーバ管理方法、及びプログラムに関する。

ネットワーク上のオンラインシステム等のホスティング環境の構築及び保守について、保守管理コスト低減等のため、多くの企業では、データセンタと呼ばれるサービス業者にアウトソーシングしている。

通常、こうしたデータセンタでは、顧客との間でサービス品質に関する契約が存在する。これは、一般的にサービス・レベル・アグリーメント（ＳＬＡ）と呼ばれ、データセンタを提供する側は、システムトラブル等を排し、ＳＬＡに従ったサービスレベルを保持する必要がある。

従来より、ＳＬＡに基づき、計算機の稼働状況を確認しながら、各ユーザに割り当てる資源を決定するというものが知られている（例えば特許文献１及び２参照）。

特開２００５−１７４２０１号公報 特開２００２−０２４１９２号公報

しかしながら、従来のＳＬＡについては、下記の様な問題点があった。すなわち、可用性を高くするために冗長構成をとると、機器の設置費用及び管理コストが増大してしまうという問題があった。また、一度障害が発生したシステムに障害が再発すると著しいサービスレベルの低下となりＳＬＡ違反となってしまいやすいといった問題もあった。

このような費用のかさみを防止するためには、できるだけ冗長化していない環境で運用してコストを削減する必要がある。また、ＳＬＡ違反を防止するためには、障害履歴のあるシステムに障害が再発しないよう、可用性向上のための対処を実施する必要がある。

本発明は、上記の課題を解決するためになされたものであり、コストを抑えると共にサービス・レベル・アグリーメント（ＳＬＡ）違反を回避するサーバ管理システム、サーバ管理方法、及びプログラムを提供する。

上記目的を達成するため、本発明の第１の観点に係るサーバ管理システムは、物理サーバ上の仮想マシンによって構成されるシステムにおける所定の状態値が、ＳＬＡ（service level agreement）に基づいて定められた違反値を超えるか否かを判別することによって、該システムが該ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ違反判別手段と、前記ＳＬＡ違反判別手段によって前記ＳＬＡに違反する危険性があると判別されたシステムを冗長構成化することが可能か否かを判別する冗長構成化判別手段と、前記冗長構成化判別手段によって前記システムを冗長構成化することが可能であると判別された場合、該システムを構成する前記仮想マシンを複数の前記物理サーバ上に配置して冗長構成化する一方で、該システムを冗長構成化することが不能であると判別した場合、該システムを構成する該仮想マシンを該物理サーバ上から所定のＦＴ（Fault Tolerant）サーバ上に移行する仮想マシン移行手段と、を備える。

上記サーバ管理システムは、前記仮想マシン移行手段によって前記冗長構成化された前記システムが再度前記ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ再違反判別手段と、前記ＳＬＡ再違反判別手段によって前記システムが再度前記ＳＬＡに違反する可能性がないと判別された場合、該システムを構成する前記仮想マシンが配置された前記複数の物理サーバのうちのいずれかの物理サーバ上における該仮想マシンを削減する仮想マシン削減手段と、をさらに備えてもよい。

また、上記サーバ管理システムは、前記仮想マシン移行手段によって前記システムが冗長構成化される毎に、多重度を１加算して更新する一方で、前記仮想マシン削減手段によって前記仮想マシンが削減される毎に、該多重度を１減算して更新する多重度更新手段をさらに備え、前記冗長構成化判別手段は、前記多重度更新手段によって更新された前記多重度が、前記ＳＬＡ違反判別手段によって前記ＳＬＡに違反する危険性があると判別されたシステムの最大多重度未満である場合、該システムを冗長構成化することが可能であると判別してもよい。

さらに、上記目的を達成するため、本発明の第２の観点に係るサーバ管理方法は、物理サーバ上の仮想マシンによって構成されるシステムにおける所定の状態値が、ＳＬＡ（service level agreement）に基づいて定められた違反値を超えるか否かを判別することによって、該システムが該ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ違反判別ステップと、前記ＳＬＡ違反判別ステップによって前記ＳＬＡに違反する危険性があると判別されたシステムを冗長構成化することが可能か否かを判別する冗長構成化判別ステップと、前記冗長構成化判別ステップによって前記システムを冗長構成化することが可能であると判別された場合、該システムを構成する前記仮想マシンを複数の前記物理サーバ上に配置して冗長構成化する一方で、該システムを冗長構成化することが不能であると判別した場合、該システムを構成する該仮想マシンを該物理サーバ上から所定のＦＴ（Fault Tolerant）サーバ上に移行する仮想マシン移行ステップと、を備える。

そして、上記目的を達成するため、本発明の第３の観点に係るプログラムは、コンピュータに、物理サーバ上の仮想マシンによって構成されるシステムにおける所定の状態値が、ＳＬＡ（service level agreement）に基づいて定められた違反値を超えるか否かを判別することによって、該システムが該ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ違反判別手順と、前記ＳＬＡ違反判別手順によって前記ＳＬＡに違反する危険性があると判別されたシステムを冗長構成化することが可能か否かを判別する冗長構成化判別手順と、前記冗長構成化判別手順によって前記システムを冗長構成化することが可能であると判別された場合、該システムを構成する前記仮想マシンを複数の前記物理サーバ上に配置して冗長構成化する一方で、該システムを冗長構成化することが不能であると判別した場合、該システムを構成する該仮想マシンを該物理サーバ上から所定のＦＴ（Fault Tolerant）サーバ上に移行する仮想マシン移行手順と、を実行させる。

本発明によれば、コストを抑えると共にサービス・レベル・アグリーメント（ＳＬＡ）違反を回避するサーバ管理システム、サーバ管理方法、及びプログラムを提供することができる。

サーバ管理システムの構成例を示すブロック図である。 サービスレベルマネージャの構成例を示すブロック図である。 構成管理部の構成例を示すブロック図である。 サービスレベル管理テーブルの構成例を示す図である。 サービスステータス管理テーブルの構成例を示す図である。 システム構成テーブルの構成例を示す図である。 システム管理テーブルの構成例を示す図である。 リソース管理テーブルの構成例を示す図である。 移行スケジュールテーブルの構成例を示す図である。 履歴管理テーブルの構成例を示す図である。 システム構成制御処理の一例を示すフローチャートである。 性能監視処理の一例を示すフローチャートである。 ＶＭ再配置案決定処理の一例を示すフローチャートである。 ＶＭ再配置案決定（縮退）処理の一例を示すフローチャートである。 ＶＭ再配置処理の一例を示すフローチャートである。 サーバ管理システムの動作例を示すタイミングチャートである。 サーバ管理システムの動作例を示すタイミングチャートである。

以下、本発明を実施するための形態について説明する。

まず、本実施形態に係るサーバ管理システムの構成について、図面を参照しつつ説明する。

図１は、サーバ管理システムの構成例を示すブロック図である。

サーバ管理システム１は、図１に示すように、物理サーバ１０（Ｓ０１）と、物理サーバ（Ｓ０２）２０と、ＦＴ（Fault Tolerant）サーバ（ＦＴ１）３０と、共有ディスク４０と、ロードバランサ５０と、サービスレベルマネージャ１００と、から構成され、インターネット（Internet）６０を介してサービス利用者端末７０、８０、及び９０に接続されている。

物理サーバ１０は、例えば汎用サーバコンピュータなどから構成され、物理サーバ１０の実リソース上で仮想マシン（Virtual Machine：ＶＭ）を実行するとともに実リソースの割当を行うハイパバイザ（ＨＶ１）１１を備えている。

物理サーバ２０は、例えば汎用サーバコンピュータなどから構成され、物理サーバ２０の実リソース上で仮想マシンを実行するとともに実リソースの割当を行うハイパバイザ（ＨＶ２）２１を備えている。

ＦＴサーバ３０は、例えばＣＰＵ（Central Processing Unit）、メインメモリ、ハードディスク、ネットワークインタフェイス、ＰＣＩ（Peripheral Component Interconnect）スロット、及び電源などのハードウェア部品をそれぞれ２つずつ（又は３つ以上）搭載し、冗長化を持たせた構成を有している。ＦＴサーバ３０は、ＦＴサーバ３０の実リソース上で仮想マシンを実行するとともに実リソースの割当を行うハイパバイザ３１（ＨＶｆｔ）を備えている。

共有ディスク４０は、例えばハードディスクなどから構成され、データや仮想マシンのイメージの実ファイル（イメージファイル）を記録する。

共有ディスク４０には、ＦＴサーバ３０環境で実行可能な構成を備え、かかる環境に対応したシステムの場合、通常の物理サーバ１０及び２０用のイメージファイルと、ＦＴサーバ３０用のイメージファイルと、の双方が用意されている。そして、共有ディスク４０からは、通常の物理サーバ１０及び２０用のイメージファイル及びＦＴサーバ３０用のイメージファイルのいずれかが、物理サーバ１０、２０、及びＦＴサーバ３０のいずれに配置するかに合わせて選択される。

ロードバランサ５０は、物理サーバ１０及び２０といった複数のサーバによって提供されるサーバ管理システム１において、そのトラフィックの振分等を行う。

サービスレベルマネージャ１００は、サービスレベルの管理、仮想マシンの管理、及び実構成の管理を行うとともに、サービスレベルを維持するための組替等を行うもので、例えば汎用サーバコンピュータなどから構成されている。

図２は、サービスレベルマネージャの構成例を示すブロック図である。

サービスレベルマネージャ１００は、図２に示すように、サービスレベル管理部１１０と、サービス監視部１２０と、再配置決定部１３０と、システム構成制御部１４０と、構成管理部１５０と、を備えている。

サービスレベル管理部１１０は、例えばＣＰＵや、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）などによって実現され、それぞれのサービス毎に、サービス・レベル・アグリーメント（ＳＬＡ）と状態値とを記録及び管理する。

サービス監視部１２０は、例えばＣＰＵや、ＲＯＭ、ＲＡＭなどによって実現され、それぞれのサービス状況を監視してサービスレベルに関わる情報を収集する。

再配置決定部１３０は、例えばＣＰＵや、ＲＯＭ、ＲＡＭなどによって実現され、サービスレベル管理部１１０で管理された状態値が所定の違反値や警告値を超えた場合に、ＳＬＡ違反の危険性（可能性）があるものと判別して、仮想マシンの配置先（移行先）スケジュールを決定する。

システム構成制御部１４０は、例えばＣＰＵや、ＲＯＭ、ＲＡＭなどによって実現され、再配置決定部１３０で決定された仮想マシンの配置先に従って、配置換えを行う。

構成管理部１５０は、例えばハードディスクなどによって実現され、物理サーバ１０及び２０の資源情報、サービス、並びに仮想マシンの配置状況を記録したテーブルを管理する。

図３は、構成管理部の構成例を示すブロック図である。

構成管理部１５０は、図３に示すように、サービスレベル管理テーブル１５１と、サービスステータス管理テーブル１５２と、システム構成テーブル１５３と、システム管理テーブル１５４と、リソース管理テーブル１５５と、移行スケジュールテーブル１５６と、履歴管理テーブル１５７と、を有している。

サービスレベル管理テーブル１５１は、各システム毎に、それぞれＳＬＡとして管理すべき項目を記録するもので、レスポンスタイム（応答時間）及び停止時間など最低限守るべき規定の値（サービスレベル）、警告を発する値（警告値）、並びにそれぞれにおいて、契約上のペナルティなどに応じて設定したリスク値（違反リスク値及び警告リスク値）などを記憶する。

図４は、サービスレベル管理テーブルの構成例を示す図である。

本実施形態において、サービスレベル管理テーブル１５１には、図４に示すように、サービスレベルＩＤ（Identification Data）と、システムＩＤと、管理項目と、業務ＩＤと、サービスレベル（違反値）と、違反リスク値と、警告値と、警告リスク値と、管理単位と、が対応付けて記憶されている。

図３に示すサービスステータス管理テーブル１５２は、各システム毎に、それぞれＳＬＡとして管理すべき項目ごとにどのような状況にあるか管理するもので、サービス監視部１２０の監視によって適宜更新される。

図５は、サービスステータス管理テーブルの構成例を示す図である。

本実施形態において、サービスステータス管理テーブル１５２には、図５に示すように、サービスレベルＩＤと、システムＩＤと、管理項目と、業務ＩＤと、状態値と、違反回数と、警告回数と、前回更新日時と、が対応付けて記憶されている。

図３に示すシステム構成テーブル１５３は、各システムを構成する仮想マシン、その仮想マシンの実態となるイメージファイル、自動対処が可能か否か、並びにクラスタ化可能な最大多重度等のシステム構成を表すものである。

図６は、システム構成テーブルの構成例を示す図である。

本実施形態において、システム構成テーブル１５３には、図６に示すように、システムＩＤと、システム名と、自動対処と、最大多重度と、システム構成マシン名と、通常の物理サーバ１０及び２０用のイメージファイルと、ＦＴサーバ３０用のイメージファイルと、が対応付けて記憶されている。

図３に示すシステム管理テーブル１５４は、各システムがどのような状態にあるかを管理するためのものである。

図７は、システム管理テーブルの構成例を示す図である。

本実施形態において、システム管理テーブル１５４には、図７に示すように、システムＩＤと、対処ステータスと、多重度と、が対応付けて記憶されている。図中、Ｎｕｌｌは、特に多重化等対応を行っていない状態を表している。

図３に示すリソース管理テーブル１５５は、各仮想マシンがどのサーバ上で動作しているかを管理する。

図８は、リソース管理テーブルの構成例を示す図である。

本実施形態において、リソース管理テーブル１５５には、図８に示すように、仮想マシンＩＤと、システムＩＤと、サーバＩＤと、が対応付けて記憶されている。図中、仮想マシンＩＤは、仮想マシン名に対応するイメージファイルが実際に仮想マシンとして動作する単位毎に付与される。

図３に示す移行スケジュールテーブル１５６は、移行スケジュールを管理するもので、再配置決定部１３０によって更新される。新たに仮想マシンを追加する際、空きがない場合には、削除してから追加となるため、このような移行スケジュールテーブル１５６が必要になる。

図９は、移行スケジュールテーブルの構成例を示す図である。

本実施形態において、移行スケジュールテーブル１５６には、図９に示すように、仮想マシンＩＤと、移行元サーバと、移行先サーバと、移行理由と、が対応付けて記憶されている。

図１０は、履歴管理テーブルの構成例を示す図である。

本実施形態において、履歴管理テーブル１５７には、図１０に示すように、日時と、仮想マシンＩＤと、移行元サーバと、移行先サーバと、移行理由と、が対応付けて記憶されている。

次に、上記構成を備えるサーバ管理システムが実行するシステム構成制御処理について図面を参照しつつ説明する。

図１１は、システム構成制御処理の一例を示すフローチャートである。

システム構成制御処理において、サービスレベルマネージャ１００は、まず、図１１に示すように、性能監視処理を実行する（ステップＳ１）。

図１２は、性能監視処理の一例を示すフローチャートである。

性能監視処理が開始されると、サービス監視部１２０は、まず、図１２に示すように、各システムの状況を計測して、所定のレスポンスタイム（応答時間）等の各状況に関する情報を、サービスレベルに関わる情報として収集する（ステップＳ１１）。より具体的に、サービス監視部１２０は、各リクエストに対するレスポンスタイム（応答時間）を計測したり、定期的にＰＩＮＧ（Packet INternet Groper）やリソースの使用状況などを確認したりして、サービスレベルに関わる情報を収集する。

次に、サービスレベル管理部１１０は、ステップＳ１１の処理にて収集した情報を用いて、図５に示すサービスステータス管理テーブル１５２に記憶されている状態値を更新する（ステップＳ１２）。

そして、サービスレベル管理部１１０は、図４に示すサービスレベル管理テーブル１５１に記載された管理単位と、図５に示すサービスステータス管理テーブル１５２に記載された前回更新日時と、から、定期的にそれぞれのサービスの違反回数及び警告回数をリセットしてから（ステップＳ１３）、性能監視処理を終了する。

ステップＳ１３の処理では、管理単位と前回更新日時とが、それぞれ図４に示すサービスレベル管理テーブル１５１と図５に示すサービスステータス管理テーブル１５２とから読み出され、前回更新日時から管理単位（ＳＬＡの計算単位期間）が経過したか否かが判別される。そして、ＳＬＡの計算単位期間が経過したと判別された場合には、所定の時間問題がない状況であったと判断して、前回更新日時に対応する違反回数及び警告回数がリセットされるとともに、前回更新日時が現在の日時に更新される。

図１１に示すステップＳ１の性能監視処理にて各状況（状態値）を更新した後、サービスレベルマネージャ１００は、ＳＬＡ違反可能性検知処理を実行する（ステップＳ２）。ＳＬＡ違反可能性検知処理では、サービスレベル管理部１１０が、図４に示すサービスレベル管理テーブル１５１を参照して、違反値や警告値に達したサービスを検知する。

ステップＳ２の処理では、違反値及び警告値と状態値とが、それぞれ図４に示すサービスレベル管理テーブル１５１と図５に示すサービスステータス管理テーブル１５２とから読み出され、状態値が違反値や警告値を超えているか否かが判別される。そして、状態値が違反値や警告値を超えていると判別された場合には、ＳＬＡ違反の可能性があるものと判別されて、状態値に対応するシステムＩＤが読み出される。

ここで、違反値及び警告値に達したサービスを検知した場合には（ステップＳ３；Ｙｅｓ）、次のＶＭ再配置案決定処理に移行する（ステップＳ４）。

図１３は、ＶＭ再配置案決定処理の一例を示すフローチャートである。

ＶＭ再配置案決定処理が開始されると、再配置決定部１３０は、まず、図１３に示すように、移行対象のサービス（違反値及び警告値に達したサービス）を有するシステムについて、図６に示すシステム構成テーブル１５３を確認して、クラスタ化が可能であるかＦＴサーバ３０への移行が可能であるかを判別することにより、移行形態を決定する（ステップＳ４１）。

ステップＳ４１の処理では、システムＩＤに対応する最大多重度と多重度とが、それぞれ図６に示すシステム構成テーブル１５３とシステム管理テーブル１５４とから読み出され、多重度が最大多重度に達しているか否かが判別される。ここで、多重度が最大多重度に達していないと判別された場合には、冗長構成が可能であると判別して、冗長構成（クラスタ構成）の環境に移行させることが決定される。これに対して、多重度が最大多重度に達していると判別された場合には、冗長構成が取れないと判別して、ＦＴサーバ３０に移行させることが決定される。

次に、再配置決定部１３０は、ステップＳ４１の処理にて決定した移行形態が、冗長構成の環境への移行かＦＴサーバ３０への移行かを判別する（ステップＳ４２）。

ここで、ステップＳ４１の処理にて決定した移行形態が冗長構成の環境への移行であると判別した場合には（ステップＳ４２；Ｙｅｓ）、図８に示すリソース管理テーブル１５５を参照して、移行可能なリソース候補を抽出する（ステップＳ４３）。そして、再配置決定部１３０は、それぞれのリソース候補毎に移行コストを算出して、移行先サーバを物理サーバ１０及び２０のいずれかに決定する（ステップＳ４４）。

移行コストは、物理リソースの空き、当該物理リソース上にあるサービスのパフォーマンス状況、及び同一システムに属する仮想マシンの有無等に応じて算出される。例えば、移行先サーバに空きがある場合を優先するときには、以下のような移行コストの算出方法が考えられる。

移行先の物理サーバ１０及び２０に空きがある場合には、同じシステムを構成する仮想マシンを同じ物理サーバ１０及び２０に集めないようにするとともに、類似の警告（管理種別）で移行してきた仮想マシンを同じ物理サーバ１０及び２０上に集めないようにするため、以下の数１に示すように、物理サーバ１０及び２０への移行コストを算出する。

ここで、ａ〜ｃは、重み付係数で、サーバ管理システム１を構成する物理サーバ１０及び２０の規模や実際に稼働する仮想マシンに応じて決定される。

これに対して、移行先の物理サーバ１０及び２０のいずれにも空きがない場合には、多重化されている全てのシステムについて、ＳＬＡ違反リスクを算出する。

再配置決定部１３０は、以下の数２に示すように、システムｉのＳＬＡ違反リスクを、それぞれのシステムに設定されたＳＬＡ（０〜ｊ）について、違反回数及び警告回数などに重み付けを行って計算する。

新たに警告が発生したシステムｉのＳＬＡ違反リスクと比較し、新たに警告が発生したシステムｉがいずれかのシステムのＳＬＡ違反リスクを上回った場合には、当該システムに含まれる仮想マシンのうち、最もコストの低い物理サーバ１０及び２０にある仮想マシンを特定する。そして、特定した仮想マシンを物理サーバ１０及び２０からアンマウントし、当該物理サーバ１０及び２０を移行先として、新たに仮想マシンを配置する。

ステップＳ４２の処理にて移行形態がＦＴサーバ３０への移行であると判別した場合や（ステップＳ４２；Ｎｏ）、ステップＳ４４の処理にて移行先を決定した後、再配置決定部１３０は、当該移行について、図９に示す移行スケジュールテーブル１５６に記録してから（ステップＳ４５）、ＶＭ再配置案決定処理を終了する。

ここで、仮想マシンを収容する空きがない場合には、既にクラスタ化又はＦＴ化されている仮想マシンを縮退し、今回対応を行う仮想マシンと入れ替える処理を行う。具体的には、仮想マシンを収容する空きがないと判別した場合、図５に示すサービスステータス管理テーブル１５２を参照して縮退すべき仮想マシンを決定し、当該移行対象となる仮想マシンよりも前に移行されるよう、図９に示す移行スケジュールテーブル１５６に記録する。

なお、複数のサービスで警告が発生し、仮想マシンの再配置が行われる可能性がある。その場合には、図９に示す移行スケジュールテーブル１５６を参照して、移行先が重複するか否かを判別し、移行先が重複するときには、後から移行可能なリソース候補を抽出したサービスについて別の移行先を選択すればよい。

図１１に示すステップＳ３の処理にて違反値（サービスレベル）及び警告値に達したサービスを検知しなかった場合や（ステップＳ３；Ｎｏ）、ステップＳ４の処理を実行した後、サービスレベル管理部１１０は、減退移行条件検知処理を実行する（ステップＳ５）。減退移行条件検知処理では、サービスレベル管理部１１０が、図１２に示すステップＳ１３の処理にてＳＬＡの計算単位期間が経過し、違反回数及び警告回数がリセットされたサービスがあるか否かを判別する（ステップＳ６）。

ここで、違反回数及び警告回数がリセットされたサービスがあると判別した場合（ステップＳ６；Ｙｅｓ）、再配置決定部１３０は、ＶＭ再配置案決定（縮退）処理を実行する（ステップＳ７）。

図１４は、ＶＭ再配置案決定（縮退）処理の一例を示すフローチャートである。

ＶＭ再配置案決定（縮退）処理が開始されると、再配置決定部１３０は、図１４に示すように、安全にリソースの空きを確保すべく、当面の違反や警告により仮想マシンの再配置が行われる可能性を判別し、再配置の可能性がないものについて、順次物理サーバ１０及び２０から縮退（停止）すべき仮想マシンを決定する（ステップＳ７１）。なお、図１３に示すＶＭ再配置案決定処理の際と同様に、移行コストを算出して停止する仮想マシンを決定するようにしてもよい。

ここで、ＶＭ再配置案決定（縮退）処理にて当面の違反や警告が起きないと判別するには、再配置の発生回数は少ない方が安全であることからそもそも少ない方がよく、再配置の発生回数と縮退する仮想マシンの数とは同じ回数の方が安全ではあるが、再配置の発生回数が多いと、移行コストが発生するためできるだけ避けた方がよいといった考え方から、例えば以下の数３に示す評価値を計算し、所定の閾値以下になる仮想サーバを、縮退すべきものと決定すればよい。

なお、ｄ、ｅは、重みとなる所定の定数である。

その後、再配置決定部１３０は、当該減縮について、図９に示す移行スケジュールテーブル１５６に記録してから（ステップＳ７２）、ＶＭ再配置案決定（縮退）処理を終了する。

ステップＳ６の処理にて違反回数及び警告回数がリセットされたサービスがないと判別した場合や（ステップＳ６；Ｎｏ）、ステップＳ７のＶＭ再配置案決定（縮退）処理を実行した後、システム構成制御部１４０は、図９に示す移行スケジュールテーブル１５６を確認し、各仮想マシンの配置換え等を行うＶＭ再配置処理を実行する（ステップＳ８）。

図１５は、ＶＭ再配置処理の一例を示すフローチャートである。

ＶＭ再配置処理が開始されると、システム構成制御部１４０は、まず、図１５に示すように、図９に示す移行スケジュールテーブル１５６を確認して、仮想サーバＩＤと移行サーバと移行先サーバと移行理由とを特定する（ステップＳ８１）。

ここで、ステップＳ８１の処理にて特定した移行理由がクラスタ構成の環境への移行又はＦＴサーバ３０への移行である場合には（ステップＳ８２；Ｎｏ）、仮想マシンＩＤに対応する仮想マシンのイメージファイルを図６に示すシステム構成テーブル１５３から特定し、移行先（配置先）サーバに共有ディスク４０から対象の仮想マシンのイメージファイルの読出を指示して、移行先サーバ上に仮想マシンを配置させる（ステップＳ８３）。

また、システム構成制御部１４０は、移行先サーバ上の仮想マシンを起動させる（ステップＳ８４）。

その後、仮想マシンの起動の完了が確認されると（ステップＳ８５；Ｙｅｓ）、移行理由がクラスタ構成の環境への移行であった場合には（ステップＳ８６；Ｙｅｓ）、仮想マシンＩＤに対応するシステムＩＤをリソース管理テーブル１５５から特定する（ステップＳ８７）。

そして、システム構成制御部１４０は、ステップＳ８７の処理にて特定したシステムＩＤに対応する多重度を１インクリメントするなどして、システム管理テーブル１５４を更新してから（ステップＳ８８）、ＶＭ再配置決定処理を終了する。

これに対して、移行理由がＦＴサーバ３０への移行であった場合には（ステップＳ８６；Ｎｏ）、移行処理を実行する（ステップＳ８９）。ステップＳ８９の移行処理では、ステップＳ８３の処理にて特定された移行元サーバ上で現在稼働している仮想マシンの停止を行う一方で、図示せぬメモリの情報を読み出した上、ＦＴサーバ３０の仮想マシン上で処理を継続させることにより、仮想マシンをＦＴサーバ３０に移行させる。

また、ステップＳ８１の処理にて特定した移行理由が仮想サーバの縮退である場合には（ステップＳ８２；Ｙｅｓ）、移行元サーバ（物理サーバ１０及び２０）に、仮想サーバＩＤが示す仮想サーバの停止処理の実行を指示する停止命令を発効する（ステップＳ９０）。

その後、移行元サーバ（物理サーバ１０及び２０）から停止通知を受信して、仮想サーバの停止を確認すると（ステップＳ９１；Ｙｅｓ）、システム構成制御部１４０は、仮想マシンＩＤに対応するシステムＩＤをリソース管理テーブル１５５から特定する（ステップＳ９２）。

そして、システム構成制御部１４０は、ステップＳ９２の処理にて特定したシステムＩＤに対応する多重度を１デクリメントするなどして、システム管理テーブル１５４を更新してから（ステップＳ９３）、ＶＭ再配置決定処理を終了する。

続いて、上記システム構成制御処理を実行するサーバ管理システムの動作例について図面を参照しつつ説明する。

図１６及び図１７は、サーバ管理システムの動作例を示すタイミングチャートである。

この動作例において、初期状態では、図１６（ａ）に示すように、システム００１を構成する仮想マシン００１Ｍ０１ａ及び００１Ｍ０２ａが物理サーバ（ＳＯ１）１０で、システム００２を構成する仮想マシン００２Ｍ０１ａが物理サーバ（ＳＯ２）２０で稼働しているものとする。また、システム００３は、クラスタ化され、仮想マシン００３Ｍ０１ａが物理サーバ（ＳＯｌ）１０で、００３Ｍ０１ｂが物理サーバ（ＳＯ２）２０で稼働しているものとする。

サービスレベル管理部１１０は、図１１に示すステップＳ１の性能監視処理において、システム００２の停止状態を検知し、ステップＳ２のＳＬＡ違反可能性検知処理において、停止時間が警告時間を超えたか否かを判別する。

そして、サービスレベル管理部１１０によって停止時間が警告時間を超えたと判別された場合（ステップＳ３；Ｙｅｓ）、再配置決定部１３０は、ステップＳ４のＶＭ再配置案決定処理において、仮想マシン００２Ｍ０１ａの移行先（再配置先）サーバを決定する。

図１６（ｂ）に示す動作例では、図１３に示すステップＳ４１の処理にてＦＴサーバ３０への移行が可能であると判別されるので、ＦＴサーバ３０が移行先サーバとして決定され（ステップＳ４２；Ｎｏ）、ステップＳ４５の処理にて移行元サーバとして物理サーバ２０が、移行先サーバとしてＦＴサーバ３０が図９に示す移行スケジュールテーブル１５６に記録される。

そして、システム構成制御部１４０は、図１５に示すステップＳ８３の処理にて図６に示すシステム構成テーブル１５３を参照し、共有ディスク４０から仮想マシン００２Ｍ０１に対応するＦＴサーバ３０用のイメージファイル００２Ｍ０１＿ｆ．ｖｍｘをＦＴサーバ３０に読み出させ、ＦＴサーバ３０上に仮想マシン００２Ｍ０１を配置させるとともに、ステップＳ８４の処理にてＦＴサーバ３０上の仮想マシン００２Ｍ０１を起動させる。

その後、サービスレベル管理部１１０は、図１２に示すステップＳ１３の処理にて、図５に示すサービスステータス管理テーブル１５２を参照して、システム００３に対応するＳＬＡの計算単位期間が経過して所定の時間が問題ない状況であったと判別した場合、違反回数及び警告回数等をリセットする。

図１６（ｃ）に示す動作例では、図１４に示すステップＳ７１の処理にて物理サーバ１０及び２０から縮退（停止）すべき仮想マシンとして、仮想マシン００３が決定され、ステップＳ７２の処理にて図９に示す移行スケジュールテーブル１５６への記録が行われる。

そして、システム構成制御部１４０は、ステップＳ９０の処理にて仮想マシン００３を停止させて、仮想マシン００３を物理サーバ２０上から取り除く。

次に、サービスレベル管理部１１０は、図１１に示すステップＳ１の性能監視処理において、システム００１の商品検索の応答時間の低下を検知し、ステップＳ２のＳＬＡ違反可能性検知処理において、応答時間が警告時間を超えたか否かを判別する。

そして、サービスレベル管理部１１０によって応答時間が警告時間を超えたと判別された場合（ステップＳ３；Ｙｅｓ）、再配置決定部１３０は、ステップＳ４のＶＭ再配置案決定処理において、仮想マシン００２Ｍ０１ａの移行先（再配置先）サーバを決定する。

図１７に示す動作例では、図１３に示すステップＳ４１の処理にて多重度が最大多重度の範囲内にあり、クラスタ化が可能であると判別されるので、クラスタ化を行うこととし、物理サーバ２０が移行先サーバとして決定され（ステップＳ４４）ステップＳ４５の処理にて移行元サーバとして物理サーバ１０が、移行先サーバとして物理サーバ２０が図９に示す移行スケジュールテーブル１５６に記録される。

そして、システム構成制御部１４０は、図１５に示すステップＳ８３の処理にて図６に示すシステム構成テーブル１５３を参照し、共有ディスク４０からシステム００１を構成する仮想マシン００１Ｍ０１及び００１Ｍ０２に対応するイメージファイル００１Ｍ０１＿ｆ．ｖｍｘ及び００１Ｍ０２＿ｆ．ｖｍｘを物理サーバ２０に読み出させ、物理サーバ２０上に仮想マシン００１Ｍ０１及び００１Ｍ０２を配置させるとともに、ステップＳ８４の処理にてＦＴサーバ３０上の仮想マシン００１Ｍ０１及び仮想マシン００１Ｍ０１ｂを起動させる。

以上説明したように、本実施形態に係るサーバ管理システム１によれば、ユーザに提供するホスティング環境を、マシンの仮想化技術を用いて構築し、サービスレベル管理テーブル１５１やサービスステータス管理テーブル１５２に記憶されているＳＬＡ情報や障害履歴などのサービスレベルに関わる情報を基に、仮想マシンで構成された複数のシステムのうち、ＳＬＡ違反が発生する危険性のあるシステムを、ＳＬＡ違反が起きないよう、自動的に高可用性の環境に移行させる。

具体的に、システム構成テーブル１５３やシステム管理テーブル１５４で冗長構成が可能なシステムかどうかを管理しておき、冗長構成可能な場合には仮想マシンを物理サーバ１０及び２０上に追加してクラスタを構成する一方で、冗長構成が取れない場合には、物理的に堅牢なＦＴサーバ３０に移行する。

また、ＳＬＡの計算単位期間終了後には、ＳＬＡに違反するリスクが低い仮想マシンを物理サーバ１０及び２０から減らすことにより、ＦＴサーバ３０に移動したシステムや冗長構成にしたシステムを元のシングル構成に戻す。

このように、ＳＬＡの違反状況に応じて、適宜、可用性の高い環境に切り替えることで、コストを抑えると共にＳＬＡ違反を回避ことができる。

この結果、ＳＬＡ違反の危険性が発生する以前は、冗長化なしの環境でシステム運用するため、低コストで運用することができる。また、障害発生履歴等によりＳＬＡ違反による違約金等のビジネスリスクがあるシステムを高可用性環境に移行することで、リスクを軽減できる。さらに、顧客に高い確率でＳＬＡが保持されるシステムを低価格で提供できる。

なお、本発明は、上記実施形態に限定されず、種々の変形、応用が可能である。以下、本発明に適用可能な上記実施形態の変形態様について、説明する。

上記実施形態では、上記システム構成制御処理を実行させるためのプログラムを、予め既存の汎用コンピュータに適用することで、上記実施形態に係るサービスレベルマネージャ１００として機能させるものとして説明した。しかしながら、本発明はこれに限定されるものではなく、例えばコンピュータが読取可能な記録媒体（例えばフレキシブルディスク、ＣＤ（Compact Disc）−ＲＯＭ、ＤＶＤ（Digital Versatile Disc）−ＲＯＭなど）に格納して配布されるプログラムや、インターネット等のネットワーク上のストレージからダウンロードしたプログラムを、既存の汎用コンピュータに適用して、上記実施形態に係るサービスレベルマネージャ１００として機能させてもよい。

また、上記システム構成制御処理をＯＳ（Operating System）とアプリケーションプログラムとの分担、又はＯＳとアプリケーションプログラムとの協働によって実行する場合には、アプリケーションプログラムのみを記録媒体やストレージに格納してもよい。また、搬送波にプログラムを重畳し、ネットワークを介して配信することも可能である。例えば、ネットワーク上の掲示板（ＢＢＳ：Bulletin Board System）に上記プログラムを掲示し、ネットワークを介してプログラムを配信してもよい。そして、このプログラムを起動し、ＯＳの制御下で、他のアプリケーションプログラムと同様に実行することにより、上記の処理を実行できるように構成してもよい。

１ サーバ管理システム
１０ 物理サーバ
１１ ハイパバイザ
２０ 物理サーバ
２１ ハイパバイザ
３０ ＦＴサーバ
３１ ハイパバイザ
４０ 共有ディスク
５０ ロードバランサ
６０ インターネット
７０ サービス利用者端末
８０ サービス利用者端末
９０ サービス利用者端末
１００ サービスレベルマネージャ
１１０ サービスレベル管理部
１２０ サービス監視部
１３０ 再配置決定部
１４０ システム構成制御部
１５０ 構成管理部
１５１ サービスレベル管理テーブル
１５２ サービスステータス管理テーブル
１５３ システム構成テーブル
１５４ システム管理テーブル
１５５ リソース管理テーブル
１５６ 移行スケジュールテーブル
１５７ 履歴管理テーブル

Claims (5)

1. 物理サーバ上の仮想マシンによって構成されるシステムにおける所定の状態値が、ＳＬＡ（service level agreement）に基づいて定められた違反値を超えるか否かを判別することによって、該システムが該ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ違反判別手段と、
   前記ＳＬＡ違反判別手段によって前記ＳＬＡに違反する危険性があると判別されたシステムを冗長構成化することが可能か否かを判別する冗長構成化判別手段と、
   前記冗長構成化判別手段によって前記システムを冗長構成化することが可能であると判別された場合、該システムを構成する前記仮想マシンを複数の前記物理サーバ上に配置して冗長構成化する一方で、該システムを冗長構成化することが不能であると判別した場合、該システムを構成する該仮想マシンを該物理サーバ上から所定のＦＴ（Fault Tolerant）サーバ上に移行する仮想マシン移行手段と、
   を備えるサーバ管理システム。
2. 前記仮想マシン移行手段によって前記冗長構成化された前記システムが再度前記ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ再違反判別手段と、
   前記ＳＬＡ再違反判別手段によって前記システムが再度前記ＳＬＡに違反する可能性がないと判別された場合、該システムを構成する前記仮想マシンが配置された前記複数の物理サーバのうちのいずれかの物理サーバ上における該仮想マシンを削減する仮想マシン削減手段と、
   をさらに備えることを特徴とする請求項１に記載のサーバ管理システム。
3. 前記仮想マシン移行手段によって前記システムが冗長構成化される毎に、多重度を１加算して更新する一方で、前記仮想マシン削減手段によって前記仮想マシンが削減される毎に、該多重度を１減算して更新する多重度更新手段をさらに備え、
   前記冗長構成化判別手段は、前記多重度更新手段によって更新された前記多重度が、前記ＳＬＡ違反判別手段によって前記ＳＬＡに違反する危険性があると判別されたシステムの最大多重度未満である場合、該システムを冗長構成化することが可能であると判別する、
   ことを特徴とする請求項２に記載のサーバ管理システム。
4. 物理サーバ上の仮想マシンによって構成されるシステムにおける所定の状態値が、ＳＬＡ（service level agreement）に基づいて定められた違反値を超えるか否かを判別することによって、該システムが該ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ違反判別ステップと、
   前記ＳＬＡ違反判別ステップによって前記ＳＬＡに違反する危険性があると判別されたシステムを冗長構成化することが可能か否かを判別する冗長構成化判別ステップと、
   前記冗長構成化判別ステップによって前記システムを冗長構成化することが可能であると判別された場合、該システムを構成する前記仮想マシンを複数の前記物理サーバ上に配置して冗長構成化する一方で、該システムを冗長構成化することが不能であると判別した場合、該システムを構成する該仮想マシンを該物理サーバ上から所定のＦＴ（Fault Tolerant）サーバ上に移行する仮想マシン移行ステップと、
   を備えるサーバ管理方法。
5. コンピュータに、
   物理サーバ上の仮想マシンによって構成されるシステムにおける所定の状態値が、ＳＬＡ（service level agreement）に基づいて定められた違反値を超えるか否かを判別することによって、該システムが該ＳＬＡに違反する危険性があるか否かを判別するＳＬＡ違反判別手順と、
   前記ＳＬＡ違反判別手順によって前記ＳＬＡに違反する危険性があると判別されたシステムを冗長構成化することが可能か否かを判別する冗長構成化判別手順と、
   前記冗長構成化判別手順によって前記システムを冗長構成化することが可能であると判別された場合、該システムを構成する前記仮想マシンを複数の前記物理サーバ上に配置して冗長構成化する一方で、該システムを冗長構成化することが不能であると判別した場合、該システムを構成する該仮想マシンを該物理サーバ上から所定のＦＴ（Fault Tolerant）サーバ上に移行する仮想マシン移行手順と、
   を実行させるためのプログラム。

Images