"複数の物理サーバ、及びサーバ管理装置がネットワークを介して接続されるサーバ管理システムであって、前記物理サーバは、前記物理サーバの電源のONとOFFとを制御する電源ユニットと、前記物理サーバ上に仮想的に設けられた論理サーバの稼働又は休止の状態を制御する論理サーバ制御部と、前記論理サーバを稼働する際に使用するリソースと、前記リソースのリソース使用率を示す情報であるリソース使用率情報を前記サーバ管理装置に送信する物理サーバ状態通知部と、を備え、前記サーバ管理装置は、前記物理サーバ毎に前記リソース使用率情報、前記リソース使用率の所定の上限値である上限閾値、及び前記リソース使用率の所定の下限値である下限閾値が記憶されるサーバ状態管理テーブルと、前記論理サーバ毎に論理サーバの稼働又は休止の状態を示す情報、及び当該論理サーバを制御している物理サーバを識別する情報が記憶される論理サーバ状態管理テーブルとを格納している記憶部と、前記物理サーバから前記リソース使用率情報を受信し、受信した前記リソース使用率情報に基づいて前記サーバ状態管理テーブルを更新するサーバ状態管理部と、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記上限閾値とを比較し、前記リソース使用率が前記上限閾値を上回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該上回った物理サーバ上で休止状態の前記論理サーバを他の物理サーバに移行する移行指示を、当該上回った物理サーバに送信するリソース分割割当実行部と、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記下限閾値とを比較し、前記リソース使用率が前記下限閾値を下回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該下回った物理サーバ上で稼働状態及び休止状態である前記論理サーバを他の物理サーバに移行する移行指示を、当該下回った物理サーバに送信し、さらに、電源をOFFすることを指示する第1の電源状態変更命令を当該物理サーバに送信するリソース集約割当実行部と、を備える、ことを特徴とするサーバ管理システム。前記リソース分割割当実行部は、電源がOFFされている前記物理サーバに対して、電源をONすることを指示する第2の電源状態変更命令を送信し、当該物理サーバに、前記リソース使用率が前記上限閾値を上回った前記物理サーバ上で休止状態の前記論理サーバを移行する、ことを特徴とする請求項1に記載のサーバ管理システム。前記論理サーバ状態管理テーブルには、論理サーバの稼働を中断可能な時間を示す中断許容時間情報が記憶され、前記リソース集約割当実行部は、前記論理サーバ状態管理テーブルを参照し、前記中断許容時間情報以内に移行可能な前記物理サーバを、前記論理サーバを移行する他の物理サーバとして選択する、ことを特徴とする請求項1又は請求項2に記載のサーバ管理システム。前記リソース分割割当実行部は、前記複数の物理サーバの内で前記リソース使用率が最も低い物理サーバを、前記論理サーバを移行する他の物理サーバとして選択し、前記リソース集約割当実行部は、前記複数の物理サーバの内で前記リソース使用率が最も低い物理サーバを、前記論理サーバを移行する他の物理サーバとして選択する、ことを特徴とする請求項1に記載のサーバ管理システム。前記物理サーバは、前記物理サーバが有する前記論理サーバの少なくとも一部に状態変化が発生した場合に、前記論理サーバの状態の変化を示す論理サーバ状態変更情報を前記サーバ管理装置に送信する論理サーバ状態通知部をさらに備え、前記サーバ管理装置は、前記物理サーバから受信した前記論理サーバ状態変更情報に基づいて前記論理サーバ状態管理テーブルを更新する論理サーバ状態管理部をさらに備え、前記リソース分割割当実行部は、前記論理サーバ状態管理テーブルの前記論理サーバの稼働又は休止の状態を示す情報が更新されたと判定した場合に、前記サーバ状態管理テーブルの前記リソース使用率と前記上限閾値とを比較し、前記リソース集約割当実行部は、前記論理サーバ状態管理テーブルの前記論理サーバの稼働又は休止の状態を示す情報が更新されたと判定した場合に、前記サーバ状態管理テーブルの前記リソース使用率と前記下限閾値とを比較する、ことを特徴とする請求項1ないし請求項4のいずれか1項に記載のサーバ管理システム。電源のONとOFFとを制御する電源ユニットと、物理サーバ上に仮想的に設けられた論理サーバの稼働又は休止の状態を制御する論理サーバ制御部と、前記論理サーバを稼働する際に使用するリソースと、を備える複数の物理サーバにネットワークを介して接続されるサーバ管理装置であって、前記物理サーバ毎に前記リソース使用率情報、前記リソース使用率の所定の上限値である上限閾値、及び前記リソース使用率の所定の下限値である下限閾値が記憶されるサーバ状態管理テーブルと、前記論理サーバ毎に論理サーバの稼働又は休止の状態を示す情報、及び当該論理サーバを制御している物理サーバを識別する情報が記憶される論理サーバ状態管理テーブルとを格納している記憶部と、前記物理サーバから前記リソースのリソース使用率を示す情報であるリソース使用率情報を受信し、受信した前記リソース使用率情報に基づいて前記サーバ状態管理テーブルを更新するサーバ状態管理部と、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記上限閾値とを比較し、前記リソース使用率が前記上限閾値を上回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該上回った物理サーバ上で休止状態の前記論理サーバを他の物理サーバに移行する移行指示を、当該上回った物理サーバに送信するリソース分割割当実行部と、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記下限閾値とを比較し、前記リソース使用率が前記下限閾値を下回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該下回った物理サーバ上で稼働状態及び休止状態である前記論理サーバを他の物理サーバに移行する移行指示を、当該下回った物理サーバに送信し、さらに、電源をOFFすることを指示する第1の電源状態変更命令を当該物理サーバに送信するリソース集約割当実行部と、を備える、ことを特徴とするサーバ管理装置。電源のONとOFFとを制御する電源ユニットと、物理サーバ上に仮想的に設けられた論理サーバの稼働又は休止の状態を制御する論理サーバ制御部と、前記論理サーバを稼働する際に使用するリソースと、を備える複数の物理サーバにネットワークを介して接続されるサーバ管理装置のサーバ管理方法であって、前記物理サーバ毎に前記リソース使用率情報、前記リソース使用率の所定の上限値である上限閾値、及び前記リソース使用率の所定の下限値である下限閾値が記憶されるサーバ状態管理テーブルと、前記論理サーバ毎に論理サーバの稼働又は休止の状態を示す情報、及び当該論理サーバを制御している物理サーバを識別する情報が記憶される論理サーバ状態管理テーブルとを格納している記憶部を備え、前記物理サーバから前記リソースのリソース使用率を示す情報であるリソース使用率情報を受信し、受信した前記リソース使用率情報に基づいて前記サーバ状態管理テーブルを更新し、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記上限閾値とを比較し、前記リソース使用率が前記上限閾値を上回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該上回った物理サーバ上で休止状態の前記論理サーバを他の物理サーバに移行する移行指示を、当該上回った物理サーバに送信し、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記下限閾値とを比較し、前記リソース使用率が前記下限閾値を下回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該下回った物理サーバ上で稼働状態及び休止状態である前記論理サーバを他の物理サーバに移行する移行指示を、当該下回った物理サーバに送信し、さらに、電源をOFFすることを指示する第1の電源状態変更命令を当該物理サーバに送信する、ことを特徴とするサーバ管理方法。請求項7に記載のサーバ管理方法をコンピュータに実行させるサーバ管理プログラム。しかしながら、特許文献1に記載される技術は、消費電力の高低により計算処理装置を選択するものであって、計算処理装置のリソースに関する検討がなされていない。すなわち、いくらシステム全体として消費電力が低くなる場合でも、消費電力の低い計算処理装置のリソースの使用率が他の計算処理装置に比べて突出して高くなることは、システムを安全に運用する観点で言えば好ましくないという問題がある。また、消費電力の低い計算処理装置が、安全設計の範囲内でリソースを有効に使用して稼働した場合に、システム内で消費電力の高い計算処理装置のリソース使用率は低くなるので、消費電力の高い計算処理装置を稼働しておくための消費電力が無駄になるという問題がある。本発明は前記問題に鑑みてなされたものであり、システム内の各サーバの負荷の突出を抑制するとともに、システム全体の電力量を低減することができる、サーバ管理システム、サーバ管理装置、サーバ管理方法、及びサーバ管理プログラムを提供することを課題とする。前記課題を解決するため、本発明に係るサーバ管理システムは、複数の物理サーバ、及びサーバ管理装置がネットワークを介して接続されるサーバ管理システムであって、前記物理サーバが、前記物理サーバの電源のONとOFFとを制御する電源ユニットと、前記物理サーバ上に仮想的に設けられた論理サーバの稼働又は休止の状態を制御する論理サーバ制御部と、前記論理サーバを稼働する際に使用するリソースと、前記リソースのリソース使用率を示す情報であるリソース使用率情報を前記サーバ管理装置に送信する物理サーバ状態通知部と、を備え、前記サーバ管理装置が、前記物理サーバ毎に前記リソース使用率情報、前記リソース使用率の所定の上限値である上限閾値、及び前記リソース使用率の所定の下限値である下限閾値が記憶されるサーバ状態管理テーブルと、前記論理サーバ毎に論理サーバの稼働又は休止の状態を示す情報、及び当該論理サーバを制御している物理サーバを識別する情報が記憶される論理サーバ状態管理テーブルとを格納している記憶部と、前記物理サーバから前記リソース使用率情報を受信し、受信した前記リソース使用率情報に基づいて前記サーバ状態管理テーブルを更新するサーバ状態管理部と、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記上限閾値とを比較し、前記リソース使用率が前記上限閾値を上回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該上回った物理サーバ上で休止状態の前記論理サーバを他の物理サーバに移行する移行指示を、当該上回った物理サーバに送信するリソース分割割当実行部と、前記サーバ状態管理テーブルを参照して前記リソース使用率と前記下限閾値とを比較し、前記リソース使用率が前記下限閾値を下回った前記物理サーバがあると判定した場合に、前記論理サーバ状態管理テーブルを参照して当該下回った物理サーバ上で稼働状態及び休止状態である前記論理サーバを他の物理サーバに移行する移行指示を、当該下回った物理サーバに送信し、さらに、電源をOFFすることを指示する第1の電源状態変更命令を当該物理サーバに送信するリソース集約割当実行部と、を備えることを特徴とする。ここで、前記リソースは、前記物理サーバのCPU、メモリ、ハードディスク、及びネットワークカードのいずれかであるのが好ましい。このようにすることで、本発明に係るサーバ管理システムは、リソースの使用率が上限閾値を上回ったサーバがある場合に、論理サーバを他のサーバに移行し、また、下限閾値を下回ったサーバがある場合に論理サーバを他のサーバに移行するとともに、下限閾値を下回ったサーバの電源をOFFする。つまり、本発明に係るサーバ管理システムは、リソースの使用率が高いサーバの負荷の突出を抑制することができ、リソースの使用率が低いサーバの電源をOFFすることができる。したがって、本発明に係るサーバ管理システムは、システムを安全に運用した上で、全体の電力量を低減することができる。また、本発明に係るサーバ管理システムは、前記リソース分割割当実行部が、電源がOFFされている前記物理サーバに対して、電源をONすることを指示する第2の電源状態変更命令を送信し、当該物理サーバに、前記リソース使用率が前記上限閾値を上回った前記物理サーバ上で休止状態の前記論理サーバを移行する、ことを特徴とする。このようにすることで、本発明に係るサーバ管理システムは、リソースの使用率が上限閾値を上回ったサーバがある場合に、休止状態のサーバを起動する。したがって、本発明に係るサーバ管理システムは、システムを構成するサーバの負荷を全体的に低く制御することができる。また、本発明に係るサーバ管理システムは、前記論理サーバ状態管理テーブルには、論理サーバの稼働を中断可能な時間を示す中断許容時間情報が記憶され、前記リソース集約割当実行部が、前記論理サーバ状態管理テーブルを参照し、前記中断許容時間情報以内に移行可能な前記物理サーバを、前記論理サーバを移行する他の物理サーバとして選択する、ことを特徴とする。このようにすることで、本発明に係るサーバ管理システムは、稼働中の論理サーバを移行する場合に、信頼性に関する情報である中断許容時間情報以内に移行可能なサーバを移行先として選択する。したがって、本発明に係るサーバ管理システムは、信頼性を考慮した論理サーバの移行を行うことができる。また、本発明に係るサーバ管理システムは、前記リソース分割割当実行部が、前記複数の物理サーバの内で前記リソース使用率が最も低い物理サーバを、前記論理サーバを移行する他の物理サーバとして選択し、また、前記リソース集約割当実行部が、前記複数の物理サーバの内で前記リソース使用率が最も低い物理サーバを、前記論理サーバを移行する他の物理サーバとして選択することを特徴とする。このようにすることで、本発明に係るサーバ管理システムは、リソースの使用率が上限閾値を上回ったサーバがある場合にリソース使用率が最も低いサーバを選択する。したがって、本発明に係るサーバ管理システムは、システムを構成するサーバの負荷を全体的に低く制御することができる。さらに、本発明に係るサーバ管理システムは、リソースの使用率が下限閾値を下回ったサーバがある場合にリソース使用率が最も低いサーバを選択する。したがって、本発明に係るサーバ管理システムは、システムを構成するサーバの負荷を全体的に低く制御することができる。また、本発明に係るサーバ管理システムは、前記物理サーバが、前記物理サーバが有する前記論理サーバの少なくとも一部に状態変化が発生した場合に、前記論理サーバの状態の変化を示す論理サーバ状態変更情報を前記サーバ管理装置に送信する論理サーバ状態通知部をさらに備え、前記サーバ管理装置が、前記物理サーバから受信した前記論理サーバ状態変更情報に基づいて前記論理サーバ状態管理テーブルを更新する論理サーバ状態管理部をさらに備え、前記リソース分割割当実行部が、前記論理サーバ状態管理テーブルの前記論理サーバの稼働又は休止の状態を示す情報が更新されたと判定した場合に、前記サーバ状態管理テーブルの前記リソース使用率と前記上限閾値とを比較し、前記リソース集約割当実行部が、前記論理サーバ状態管理テーブルの前記論理サーバの稼働又は休止の状態を示す情報が更新されたと判定した場合に、前記サーバ状態管理テーブルの前記リソース使用率と前記下限閾値とを比較することを特徴とする。このようにすることで、本発明に係るサーバ管理システムは、論理サーバの状態が変更された場合にのみ判定を行う。したがって、本発明に係るサーバ管理システムは、リソース使用率が上限閾値を上回ったか否かの判定、又は下限閾値を下回ったか否かの判定を常に監視する必要がない。本発明に係るサーバ管理システム、サーバ管理装置、サーバ管理方法、及びサーバ管理プログラムによれば、システム内の各サーバの負荷の突出を抑制するとともに、システム全体の電力量を低減することができる。以下、図面を参照して、本発明の実施の形態につき詳細に説明する。なお、各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。第1実施形態以下、図1を参照して、第1実施形態に係るサーバ管理システム1000の構成について説明する。なお、図1は、第1実施形態に係るサーバ管理システム1000の構成図である。≪サーバ管理システムの構成≫第1実施形態に係るサーバ管理システム1000は、ディスク装置100と、6台のサーバ1~6で構成されるサーバ群200と、サーバ管理装置300とがネットワーク400を介して接続される構成である。次に、サーバ管理システム1000を構成する各装置について説明する。<ディスク装置>ディスク装置100は、サーバ群200を構成するサーバ1~6で実行される論理サーバプログラム1~論理サーバプログラム34が格納される。サーバ群200を構成するサーバ1~6がディスク装置100に格納される論理サーバプログラム1~論理サーバプログラム34のいずれかを実行することで、論理サーバが、サーバ1~6上で稼働する。なお、論理サーバに対して、サーバ1~6を物理サーバ1~6と呼ぶ場合がある。<サーバ群>図2を参照して、第1実施形態に係るサーバ群200の構成について説明する。なお、図2は、第1実施形態に係るサーバ群200の構成図である。サーバ群200は、例えば、ブレードサーバである。第1実施形態では、サーバ群200は、6台のサーバ1~6で構成されることを想定しているが、サーバの数は6台に限定されず複数台であればよい。サーバ2~6の構成は、サーバ1と同様なので、以下ではサーバ1の構成についてのみ説明しサーバ2~6の構成の説明は省略する。サーバ1は、電源ユニット11と、CPU群12と、メモリ13と、制御部14とで構成される。電源ユニット11は、サーバ1の電源のONとOFFとを制御する。電源ユニット11は、電源がON状態において、CPU群12、メモリ13、及び制御部14に電力を供給し、これらの装置を動作可能にする。第1実施形態では、電源ユニット11は、論理機能付き多電源レベルの電源ユニットである場合を想定して説明する。その為、電源ユニット11は、所定範囲で自由に電源レベルを変換可能で、CPU群12で稼働する論理サーバの数に応じて電源レベルが変化する。以下では、論理サーバ毎に与えられ、電源レベルが変化する仮想的な電源のことを論理電源と呼ぶ場合があり、これに対して、サーバ1~6毎に与えられる電源のことを物理電源と呼ぶ場合がある。CPU群12は、8個のCPU12a~12hで構成される。第1実施形態では、CPU群12は、8個のCPU12a~12hで構成されることを想定しているが、CPUの数は8個に限定されず複数個であればよい。なお、第1実施形態では、8個のCPU12a~12hは同じ処理能力を備えるものとして説明する。メモリ13は、ディスク装置100に格納されるVMプログラム1~VMプログラム34が制御部14内の後記する論理サーバ制御部15の指示に基づき実行可能に展開される。制御部14は、論理サーバ制御部15と、物理サーバ状態通知部16と、論理サーバ状態通知部17とを含めて構成される。なお、制御部14は、説明の便宜上、CPU群12及びメモリ13と異なる構成として図示しているが、実際は、CPU群12の一部とメモリ13の一部、及びこれらの周辺回路で構成される。そして、この制御部14は、例えば、図示しない記憶部に格納される図示しないプログラムをメモリ13に展開し、CPU群12で実行することにより実現される。論理サーバ制御部15は、リソースとしてのCPU群12、及びメモリ13を制御して、論理サーバを稼働する。以下では、CPU群12及びメモリ13をまとめてリソースと呼ぶ場合がある。例えば、論理サーバ制御部15は、ディスク装置100に格納されるVMプログラム1~VMプログラム34をメモリ13に展開し、メモリ13に展開されたVMプログラム1~VMプログラム34をCPU群12で実行させる。これにより、論理サーバは、CPU群12上で稼働する。なお、論理サーバの稼働に対して、サーバ群200で稼働していない論理サーバの状態を休止と呼ぶこととする。論理サーバ制御部15は、例えば、稼働している論理サーバの処理が終了すれば、論理サーバを休止する。また、論理サーバ制御部15は、例えば、ネットワーク400に通信可能に接続される図示しないクライアントからの要求に応じて休止している論理サーバを稼働する。なお、論理サーバ制御部15は、論理サーバが休止している状態ではVMプログラム1~VMプログラム34を実行するのに必要なメモリ13上の領域及びCPU12a~12hを確保しておらず、稼働するに際してリソースを確保する。図2では、論理サーバ制御部15は、VMプログラム1をメモリ13に展開し、メモリ13に展開されたVMプログラム1をCPU12aで実行している様子を示している。これにより、論理サーバは、CPU12a上で稼働している。また、休止している論理サーバがサーバ1上で稼働することになった場合、論理サーバ制御部15は、VMプログラム2をメモリ13に展開し、メモリ13に展開されたVMプログラム2をCPU12b,12cで実行する。これにより、論理サーバは、CPU12b,12c上で稼働することになる。なお、論理サーバが稼働するに際して、メモリ13上で確保する領域、及び使用するCPU12a~12hの数が論理サーバに比べて多いのは、論理サーバが論理サーバに比べてリソースを多く消費することを示している。物理サーバ状態通知部16は、リソースとしてのCPU12群やメモリ13のリソース使用率を示す情報であるリソース使用率情報をサーバ管理装置300に送信する。物理サーバ状態通知部16がリソース使用率情報をサーバ管理装置300に送信するタイミングは、任意であってよい。第1実施形態では、物理サーバ状態通知部16は、極めて短い間隔で、リソース使用率情報をサーバ管理装置300に送信していることとし、サーバ管理装置300は、サーバ1の最新のリソース使用率を常に認識しているものとする。また、物理サーバ状態通知部16は、サーバ1の電源の状態ON又はOFFを示す情報である電源状態情報をサーバ管理装置300に送信する。論理サーバ状態通知部17は、サーバ1が制御している論理サーバの状態稼働又は休止を示す情報であるVM状態情報をサーバ管理装置300に送信する。以上で、第1実施形態に係るサーバ群200の説明を終了する。<サーバ管理装置>図1に戻り、サーバ管理装置300の構成を説明する。サーバ管理装置300は、記憶部70と、制御部80とを備えて構成される。サーバ管理装置300は、一般的なコンピュータであってよい。記憶部70は、例えばHDDとして構成される。記憶部70には、論理サーバ状態管理テーブル71と、サーバ状態管理テーブル72とが格納される。論理サーバ状態管理テーブル図3を参照して、論理サーバ状態管理テーブル71のデータ構成について説明する。論理サーバ状態管理テーブル71は、VM識別子711と、VM状態712と、サーバ識別子713と、割当CPU714と、割当メモリ715とで構成される。VM識別子711の欄には、サーバ1~6が制御する論理サーバを一意に識別する情報が格納される。第1実施形態では、VM以降の下付き数字がVM識別子711に該当する。VM状態712の欄には、サーバ1~6が制御する論理サーバの状態が格納される。VM状態712には、稼働又は休止の2つの状態がある。サーバ識別子713の欄には、VM識別子711に対応する論理サーバを制御するサーバ1~6を一意に識別する情報が格納される。割当CPU714の欄には、VM識別子711に対応する論理サーバをサーバ1~6上で稼働する際に、必要なCPUの数が格納される。割当メモリ715の欄には、VM識別子711に対応する論理サーバVMをサーバ1~6上で稼働する際に、必要なメモリの領域が格納される。サーバ状態管理テーブル次に、図4を参照して、サーバ状態管理テーブル72のデータ構成について説明する。サーバ状態管理テーブル72は、サーバ識別子721と、電源状態722と、最大リソースに対する割当中のCPU数723と、最大リソースに対する割当中のメモリ領域724と、CPU使用率725と、メモリ使用率726と、下限閾値727と、上限閾値728とで構成される。サーバ識別子721の欄には、サーバ1~6を一意に識別する情報が格納される。電源状態722の欄には、サーバ識別子721に対応するサーバ1~6の電源の状態が格納される。電源がONされていれば稼働が格納され、電源がOFFされていれば休止が格納される。最大リソースに対する割当中のCPU数723の欄には、サーバ識別子721に対応するサーバ1~6が備えるCPU総数と、稼働中の論理サーバに割り当てられている割当中CPU数とが格納される。最大リソースに対する割当中のメモリ領域724の欄には、サーバ識別子721に対応するサーバ1~6が備えるメモリ総領域と、稼働中の論理サーバに割り当てられている割当中メモリ領域が格納される。CPU使用率725の欄には、サーバ識別子721に対応するサーバ1~6のCPU使用率が格納される。メモリ使用率726の欄には、サーバ識別子721に対応するサーバ1~6のメモリ使用率が格納される。下限閾値727の欄には、サーバ識別子721に対応するサーバ1~6が備えるCPUやメモリ等のリソースのリソース使用率の所定の下限閾値が格納される。ここで、下限閾値727は、電力を有効に使うことを考慮する場合には高めに設定し、サーバ管理システム1000の安全設計を考慮する場合には低めに設定するのがよい。上限閾値728の欄には、サーバ識別子721に対応するサーバ1~6が備えるCPUやメモリ等のリソースのリソース使用率の所定の上限閾値が格納される。ここで、上限閾値728は、リソースを有効に使うことを考慮する場合には高めに設定し、サーバ管理システム1000の安全設計を考慮する場合には低めに設定するのがよい。第1実施形態では、CPU使用率の下限閾値と、メモリ使用率の下限閾値とを同様に設定していることを前提としているので、まとめてリソースの下限閾値727としているが、CPUとメモリとでそれぞれ別の下限閾値727を設定するようにしてもよい。また、同様に、第1実施形態では、CPU使用率の上限閾値と、メモリ使用率の上限閾値とを同様に設定していることを前提としているので、まとめてリソースの上限閾値728としているが、CPUとメモリとでそれぞれ別の上限閾値728を設定するようにしてもよい。なお、論理サーバ状態管理テーブル71及びサーバ状態管理テーブル72に格納される情報は、後記するサーバ状態管理部81、論理サーバ状態管理部82、及びリソース割当実行部83が更新する情報を除いて、サーバ管理装置300の管理者が適宜更新する。図1に戻り、引き続きサーバ管理装置300の構成を説明する。制御部80は、CPU、及びこれらの周辺回路等いずれも図示せずから構成される。また、制御部80は、サーバ状態管理部81と、論理サーバ状態管理部82と、リソース割当実行部83とを含んで構成される。そして、この制御部80は、記憶部70に格納される図示しないプログラムをメモリに展開し、実行することにより実現される。次に、図5及び図6を適宜参照して、制御部80が実現する各機能を説明する。なお、図5は、第1実施形態に係るサーバ管理システム1000で行われる処理を説明するためのシーケンス図リソース使用率が下限閾値を下回った場合である。図6は、第1実施形態に係るサーバ管理システム1000で行われる処理を説明するためのシーケンス図リソース使用率が上限閾値を上回った場合である。サーバ状態管理部サーバ状態管理部81は、サーバ群200を構成するサーバ1~6の状態を管理する。例えば、サーバ状態管理部81は、サーバ管理装置81が起動した場合やサーバ群200を構成するサーバ1~6を起動させた場合に、サーバ1~6の電源の状態ON又はOFFを示す情報である電源状態情報を初期情報としてサーバ1~6から受信する図5及び図6のステップS100。そして、サーバ状態管理部81は、受信した電源状態情報に基づいて、サーバ状態管理テーブル72の電源状態722を更新する。また、サーバ状態管理部81は、詳細を後記するリソース割当実行部83からサーバ1~6に対して指示される電源状態変更命令に基づいて、サーバ1~6の電源状態が変更された場合にも同様に、電源状態情報をサーバ1~6から受信する図5のステップS165、図6のステップS195。そして、この場合にも、サーバ状態管理部81は、受信した電源状態情報に基づいて、サーバ状態管理テーブル72を更新する。また、サーバ状態管理部81は、サーバ1~6から極めて短い間隔でリソースのリソース使用率を示すリソース使用率情報を受信し、受信したリソース使用率情報に基づいて、サーバ状態管理テーブル72の、CPU使用率725及びメモリ使用率726を更新する。これにより、サーバ状態管理テーブル72の、CPU使用率725及びメモリ使用率726は、常に最新の情報となっている。論理サーバ状態管理部論理サーバ状態管理部82は、サーバ群200を構成するサーバ1~6が制御する論理サーバの状態を管理する。例えば、論理サーバ状態管理部82は、サーバ管理装置81が起動した場合やサーバ群200を構成するサーバ1~6を起動させた場合に、サーバ1~6が制御している論理サーバの状態稼働又は休止を示す情報であるVM状態情報を初期情報としてサーバ1~6から受信する図5及び図6のステップS100。そして、論理サーバ状態管理部82は、受信したVM状態情報に基づいて、論理サーバ状態管理テーブル71のVM状態712と、サーバ状態管理テーブル72の最大リソースに対する割当中のCPU数723及び最大リソースに対する割当中のメモリ領域724とを更新する。また、論理サーバ状態管理部82は、サーバ1~6で制御する論理サーバが行っている処理が終了することにより休止し、又は休止している論理サーバがクライアントからの要求に応じて稼働することなどで、論理サーバの状態が変更された場合に、VM状態情報をサーバ1~6から受信する図5及び図6のステップS110。そして、この場合も、論理サーバ状態管理部82は、受信したVM状態情報に基づいて、論理サーバ状態管理テーブル71及びサーバ状態管理テーブル72を更新する。また、論理サーバ状態管理部82は、詳細を後記するリソース割当実行部83からサーバ1~6に対して指示されるVM移行命令に基づいて、サーバ群200を構成するあるサーバ1~6で制御している論理サーバを他のサーバ1~6に移行した場合に、移行後のVM状態情報を移行先のサーバ1~6から受信する図5のステップS155、図6のステップS205。そして、この場合も、論理サーバ状態管理部82は、受信したVM状態情報に基づいて、論理サーバ状態管理テーブル71及びサーバ状態管理テーブル72を更新する。リソース割当実行部リソース割当実行部83は、サーバ1~6が制御する論理サーバをサーバ1~6間で移行する処理の指示やサーバ1~6の電源の状態を切り替える指示をする。第1実施形態では、リソース割当実行部83が行う論理サーバの移行、及びサーバ1~6の電源の状態の切り替えをリソースの割り当て又はリソース割当と呼ぶ場合がある。例えば、リソース割当実行部83は、サーバ1~6で稼働する論理サーバが行っている処理が終了することにより休止し、又は休止している論理サーバがクライアントからの要求に応じて稼働することなどで、論理サーバの状態が変更されたことにより、VM状態情報をサーバ1~6から受信し図5及び図6のステップS110、リソース使用率がサーバ状態管理テーブル72の下限閾値727、又は上限閾値728を超えた場合にサーバ1~6に対してリソースの割り当てを実行する図5のステップS115,ステップS150,ステップS160、図6のステップS115,ステップS190,ステップS200。以下では、図7及び図8を参照して、リソース割当の概要を説明する。図7は、リソース使用率と上限閾値及び下限閾値との関係を説明するための図である。図8は、サーバ管理装置が行うリソース割当処理の概要を説明するための図である。なお、リソース割当処理には、リソース使用率が下限閾値を下回った場合と、リソース使用率が上限閾値を上回った場合との2通りの処理がある。Aリソース使用率が下限閾値を下回った場合のリソース割当まず最初に、リソース使用率が下限閾値を下回った場合のリソース割当を説明する。なお、リソース割当実行部83の内、リソース使用率が下限閾値を下回った場合のリソース割当を行う機能をリソース集約割当実行部と呼ぶ場合がある。ここで、サーバ1では、当初論理サーバが稼働していたが、論理サーバが休止し、それに伴い、サーバ1のリソース使用率が低下したと想定する。サーバ1の物理サーバ状態通知部16は、低下したリソース使用率を示すリソース使用率情報をサーバ管理装置300に送信し、また、論理サーバ状態通知部17は、論理サーバが休止及び論理サーバが稼働状態であることを示すVM状態情報をサーバ管理装置300に送信する。サーバ管理装置300のサーバ状態管理部81は、サーバ1から送信されたリソース使用率情報を受信し、サーバ状態管理テーブル72を更新する。また、論理サーバ状態管理部82は、サーバ1から送信されるVM状態情報を受信し、論理サーバ状態管理テーブル71を更新する。ここで、サーバ1のCPU使用率725、及びメモリ使用率726は、図7aに示すように、下限閾値727を下回っているものとする。サーバ管理装置300のリソース割当実行部83は、サーバ状態管理テーブル72を参照し、CPU使用率725、及びメモリ使用率726が下限閾値727を下回ったか否かを判定する。図7aに示すようにリソース使用率であるCPU使用率725、及びメモリ使用率726は下限閾値727を下回っているので、リソース割当実行部83は、サーバ1が制御する休止状態の論理サーバ及び稼働状態の論理サーバを、サーバ群200内の他のサーバ2~6に移行することを示すVM移行命令を移行元であるサーバ1に送信する図5のステップS150。これにより、論理サーバの制御は、他のサーバ2~6に移ることになる。図8aは、論理サーバの制御が、サーバ2に移行した場合を示しており、移行先のサーバの選択は後記するアルゴリズムで詳細を説明する。また、リソース割当実行部83は、電源の状態をONからOFFに切り替えることを示す電源状態変更命令を移行元のサーバ1に対して送信する図5のステップS160。これにより、サーバ1の電源ユニット11は、電源をONからOFFに切り替え、サーバ1は休止状態になる。図8aでは、サーバ1の休止状態を、破線と共にサーバ1として表現している。Bリソース使用率が上限閾値を上回った場合のリソース割当次に、リソース使用率が上限閾値を上回った場合のリソース割当を説明する。なお、リソース割当実行部83の内、リソース使用率が上限閾値を上回った場合のリソース割当を行う機能をリソース分割割当実行部と呼ぶ場合がある。ここで、サーバ5では、当初論理サーバが休止していたが、論理サーバが順次稼働しは依然として休止、それに伴い、サーバ5のリソース使用率が上昇したと想定する。サーバ5の物理サーバ状態通知部56は、上昇したリソース使用率を示すリソース使用率情報をサーバ管理装置300に送信し、また、論理サーバ状態通知部17は、論理サーバが休止及び論理サーバが稼働状態であることを示すVM状態情報をサーバ管理装置300に送信する。サーバ管理装置300のサーバ状態管理部81は、サーバ5から送信されたリソース使用率情報を受信し、サーバ状態管理テーブル72を更新する。また、論理サーバ状態管理部82は、サーバ1から送信されるVM状態情報を受信し、論理サーバ状態管理テーブル71を更新する。ここで、サーバ5のCPU使用率725、及びメモリ使用率726は、図7bに示すように、上限閾値728を上回っているものとする。サーバ管理装置300のリソース割当実行部83は、サーバ状態管理テーブル72を参照し、CPU使用率725、及びメモリ使用率726が上限閾値728を上回ったか否かを判定する。図7bに示すようにリソース使用率であるCPU使用率725、及びメモリ使用率726は上限閾値728を上回っているので、リソース割当実行部83は、サーバ5が制御する休止状態の論理サーバを、サーバ群200内の他のサーバ1~4,6に移行することを示すVM移行命令を移行元であるサーバ5に送信する図6のステップS200。これにより、論理サーバの制御は、他のサーバ1~4,6に移ることになる。図8bは、論理サーバの制御が、サーバ6に移行した場合を示している。なお、リソース割当実行部83は、論理サーバの移行先の電源の状態がOFFである場合に、VM移行命令に先立って、電源の状態をOFFからONに切り替えることを示す電源状態変更命令を移行先のサーバ1~4,6に対して送信する図6のステップS190。これにより、移行先のサーバ1~4,6の電源の状態は、ONからOFFに切り替えられ、移行先のサーバ1~4,6は稼働状態になる。次に、図9~図12を参照して、リソース割当実行部83が行うリソース割当に関するアルゴリズムを説明する。図9は、第1実施形態に係るサーバ管理装置300が行うリソース割当を説明するためのフローチャートである。サーバ1~6が制御する論理サーバの状態が変更された場合に、サーバ管理装置300の論理サーバ状態管理部82は、サーバ1~6から送信されるVM状態情報を受信しステップS110、論理サーバ状態管理テーブル71を更新する。次に、リソース割当実行部83は、サーバ状態管理テーブル72を参照し、リソース使用率が下限閾値727を下回ったか否かを判定するステップS120。リソース使用率が下限閾値727を下回ったと判定された場合ステップS120Yesに、処理はステップS130に進む。一方、リソース使用率が下限閾値727を下回っていないと判定された場合ステップS120Noに、処理はステップS170に進む。前記ステップS120Yesの場合に、リソース割当実行部83は、サーバ状態管理テーブル72を参照し、リソース使用率が下限閾値727を下回ったサーバのサーバ識別子721に対応する最大リソースに対する割当中のCPU数723と、最大リソースに対する割当中のメモリ領域724とを取得するステップS130。ステップS130で取得した情報を、稼働状態のVM総リソースと呼ぶ場合がある。そして、処理はステップS140に進む。ステップS140の処理の詳細を、図10に示す。図10は、第1実施形態に係るサーバ管理装置300が行うリソース割当を説明するためのフローチャートである。リソース割当実行部83は、ステップS130で取得した稼働状態のVM総リソースである最大リソースに対する割当中のCPU数723と、最大リソースに対する割当中のメモリ領域724とを入力データとするステップS410。また、リソース割当実行部83は、変数MAXに初期値を設定し、変数MINに初期値を設定する。次に、リソース割当実行部83は、サーバ群200の中から任意の1つのサーバを選択し、ステップS430~ステップS480の処理を行う。第1のサーバの処理が終了したら、他の第2のサーバ、第3のサーバ、を選択し、ステップS430~ステップS480の処理を行う。つまり、ステップS420のループ処理は、サーバ単位に繰り返し行うステップS420。次に、リソース割当実行部83は、選択した1つのサーバが備えるリソースの中から任意の1つのリソースを選択し、ステップS430~ステップS460の処理を行う。第1のリソースの処理が終了したら、他の第2のリソース、第3のリソース、を選択し、ステップS430~ステップS460の処理を行う。つまり、ステップS430のループ処理は、使用リソース単位に繰り返し行うステップS430。ここでは、第1のリソースとしてCPUが選択され、第2のリソースとしてメモリが選択されたとする。次に、リソース割当実行部83は、ステップS410で入力した最大リソースに対する割当中のCPU数723の内の割当中CPU数と、第1のサーバのサーバ識別子721に対応する最大リソースに対する割当中のCPU数723の内の割当中CPU数を加算し、第1のサーバのサーバ識別子721に対応する最大リソースに対する割当中のCPU数723の内のCPU総数の割合を計算しステップS440、計算した値を変数Kに設定する。次に、リソース割当実行部83は、ステップS440で設定した変数Kと変数MAXを比較し、変数Kが変数MAXよりも大きい場合に、変数MAXを変数Kに置き換えるステップS460。一方、変数Kが変数MAXよりも大きくない場合に、変数MAXを変数Kに置き換える処理は行わない。次に、リソース割当実行部83は、第2のリソースとしてメモリを選択し、ステップS440~ステップS460の処理を行う。つまり、ステップS430のループ処理が終了した時点で、第1のサーバのリソースの内、リソース割合が最も高いリソースのリソース割合以下、サーバ毎リソース割合と呼ぶが求められる。次に、リソース割当実行部83は、ステップS420で設定した変数MAXと変数MINとを比較し、変数MAXが変数MINよりも小さい場合に、変数MINを変数MAXに置き換えるステップS480。一方、変数MAXが変数MINよりも小さくない場合に、変数MINを変数MAXに置き換える処理は行わない。次に、リソース割当実行部83は、第2のサーバを選択し、ステップS420~ステップS480の処理を行う。つまり、ステップS420のループ処理が終了した時点で、サーバ群200を構成する各サーバの中で、最も低いサーバ毎リソース割合及び最も低いサーバ毎リソース割合を有するサーバが求められる。当該サーバが移行先のサーバとなる。そして、処理は図9のステップS150に進む。次に、リソース割当実行部83は、ステップS120でリソース使用率が下限閾値727を下回ったと判定した移行元のサーバに対して、ステップS140で最も低いサーバ毎リソース割合を有するサーバを移行先とするVM移行命令を送信する。これにより、移行元の論理サーバは、移行先のサーバに移行するステップS150。次に、リソース割当実行部83は、ステップS120でリソース使用率が下限閾値727を下回ったと判定した移行元のサーバに対して、電源の状態をONからOFFに切り替えることを示す電源状態変更命令を送信する。これにより、移行元のサーバの電源はONからOFFに切り替えられるステップS160。一方、前記ステップS120Noの場合に、処理はステップS170に進む。リソース割当実行部83は、サーバ状態管理テーブル72を参照し、リソース使用率が上限閾値728を上回ったか否かを判定するステップS170。リソース使用率が上限閾値728を上回ったと判定された場合ステップS170Yesに、処理はステップS180に進む。一方、リソース使用率が上限閾値728を上回っていないと判定された場合ステップS170Noに、処理は終了する。前記ステップS170Yesの場合に、処理はステップS180に進む。ステップS180の処理の詳細を、図11に示す。図11は、第1実施形態に係るサーバ管理装置300が行うリソース割当を説明するためのフローチャートである。最初に、リソース割当実行部83は、サーバ状態管理テーブル72を参照し、電源状態722が休止状態のサーバをランダムに1つ選択するステップS510。当該サーバが移行先のサーバとなる。次に、リソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ識別子713がステップS170でリソース使用率が上限閾値728を上回ったと判定したサーバである論理サーバを1つ選択と呼ぶし、ステップS530~ステップS540の処理を行う。第1の論理サーバの処理が終了したら、他の第2の論理サーバ、第3の論理サーバ、を選択し、ステップS530~ステップS540の処理を行う。つまり、ステップS520のループ処理は、論理サーバ単位に繰り返し行うステップS520。次に、リソース割当実行部83は、ステップS520で選択した第1の論理サーバのVM電源がOFFか否か、すなわち、VM状態712が休止状態であるか否かを判定しステップS530、ステップS530でYesと判定した場合に、第1の論理サーバを移行するサーバとして選択する。次に、リソース割当実行部83は、第2の論理サーバを選択し、ステップS530~ステップS540の処理を行う。つまり、ステップS520の処理を終了した時点で、ステップS510で選択したサーバが制御する休止状態の論理サーバのすべてが選択される。なお、上記したステップS180の処理の他に、リソース割当実行部83は、サーバ状態管理テーブル72を参照し、電源状態722が稼働状態のサーバの内、リソース使用率が最も低いサーバを移行先と選択することもできる。そして、処理は図9のステップS190に進む。次に、リソース割当実行部83は、ステップS180で選択した移行先のサーバに対して、電源の状態をOFFからONに切り替えることを示す電源状態変更命令を送信する。これにより、移行先のサーバの電源はOFFからONに切り替えられるステップS190。次に、リソース割当実行部83は、ステップS170でリソース使用率が上限閾値728を上回ったと判定した移行元のサーバに対して、ステップS180で選択したサーバを移行先とする、ステップS180で選択した休止状態の論理サーバのVM移行命令を送信する。これにより、移行元の論理サーバは、移行先のサーバに移行するステップS200。以上で、第1実施形態に係るサーバ管理装置300の構成の説明を終了する。また、第1実施形態に係るサーバ管理システム1000の構成の説明を終了する。≪サーバ管理システムの動作≫図12~図18を参照して、第1実施形態に係るサーバ管理システム1000の動作について説明する。図12は、時刻とリソース利用率との関係図である。図13は、サーバ管理装置300とサーバ1~3との関係を示すシーケンス図である。図14~図18は、各時刻におけるサーバ1~3の状態を示す図である。ここで、前提として、サーバ群200は、3台のサーバ1~3で構成され、各サーバ1~3は、稼働状態である6つの論理サーバを制御している。時刻t1において、サーバ1が制御する論理サーバ、及びサーバ2が制御する論理サーバの論理電源が切断されたことで、これらの論理サーバが休止したとする。サーバ1の論理サーバ状態通知部17及びサーバ2の論理サーバ状態通知部27は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信する図13のステップS1。サーバ管理装置300のリソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ1のリソース利用率が下限閾値を下回ったことを確認し、サーバ2を移行先と決定したとする。そして、リソース割当実行部83は、サーバ1に対して、移行先をサーバ2とするVM移行命令を送信するステップS2。サーバ1の論理サーバ制御部15は、VM移行命令に従って、制御する論理サーバをサーバ2に移行するステップS3。なお、リソース割当実行部83は、サーバ2のリソース利用率が、上限閾値を上回ることも下限閾値を下回ることもないため、サーバ2に対して、VM移行命令を送信しない。時刻t2において、サーバ3が制御する論理サーバの論理電源が切断されたことで、これらの論理サーバが休止したとする。サーバ3の論理サーバ状態通知部37は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS4。リソース割当実行部83は、サーバ3のリソース利用率が、上限閾値を上回ることも下限閾値を下回ることもないため、サーバ3に対して、VM移行命令を送信しない。また、サーバ1が制御していた論理サーバのサーバ2への移行が完了したとする。サーバ1の論理サーバ状態通知部17は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS5。サーバ管理装置300のリソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ1のリソース利用率が0になったことを確認し、サーバ1に対して、電源をOFFとする電源状態変更命令を送信するステップS6。サーバ1の電源ユニット11は、電源状態変更命令に従って、物理電源を切断すると共に、物理サーバ状態通知部16は、電源の状態の変化を確認したことにより、サーバ管理装置300に対して、電源状態情報を送信するステップS7。時刻t3において、サーバ3が制御する論理サーバの論理電源が切断されたことで、これらの論理サーバが休止したとする。サーバ3の論理サーバ状態通知部37は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS8。サーバ管理装置300のリソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ3のリソース利用率が下限閾値を下回ったことを確認し、サーバ2を移行先と決定したとする。そして、リソース割当実行部83は、サーバ1に対して、移行先をサーバ2とするVM移行命令を送信するステップS9。サーバ3の論理サーバ制御部35は、VM移行命令に従って、制御する論理サーバをサーバ2に移行するステップS10。時刻t4において、サーバ3が制御していた論理サーバのサーバ2への移行が完了したとする。サーバ1の論理サーバ状態通知部17は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS11。サーバ管理装置300のリソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ3のリソース利用率が0になったことを確認し、サーバ3に対して、電源をOFFとする電源状態変更命令を送信するステップS12。サーバ3の電源ユニット31は、電源状態変更命令に従って、物理電源を切断すると共に、物理サーバ状態通知部36は、電源の状態の変化を確認したことにより、サーバ管理装置300に対して、電源状態情報を送信するステップS13。これにより、図15bに示す状態になる。時刻t6において、サーバ2が制御している論理サーバの論理電源が起動されたことで、これらの論理サーバが稼働したとする。サーバ2の論理サーバ状態通知部27は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS14。サーバ管理装置300のリソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ2のリソース利用率が上限閾値を上回ったことを確認し、サーバ1を移行先と決定したとする。そして、サーバ管理装置300のリソース割当実行部83は、サーバ1に対して、電源をONとする電源状態変更命令を送信するステップS15。サーバ1の電源ユニット11は、電源状態変更命令に従って、物理電源を起動すると共に、物理サーバ状態通知部16は、電源の状態の変化を確認したことにより、サーバ管理装置300に対して、電源状態情報を送信するステップS16。時刻t7において、リソース割当実行部83は、サーバ2に対して、移行先をサーバ1とする論理サーバのVM移行命令を送信するステップS17。サーバ2の論理サーバ制御部25は、VM移行命令に従って、制御する論理サーバをサーバ2に移行するステップS18。これにより、図17aに示す状態になる。時刻t9において、サーバ1が制御している論理サーバの論理電源が起動されたことで、これらの論理サーバが稼働したとする。サーバ1の論理サーバ状態通知部17は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS19。サーバ管理装置300のリソース割当実行部83は、論理サーバ状態管理テーブル71を参照し、サーバ1のリソース利用率が上限閾値を上回ったことを確認し、サーバ3を移行先と決定したとする。そして、サーバ管理装置300のリソース割当実行部83は、サーバ3に対して、電源をONとする電源状態変更命令を送信するステップS20。時刻t10において、サーバ3の電源ユニット31は、電源状態変更命令に従って、物理電源を起動すると共に、物理サーバ状態通知部36は、電源の状態の変化を確認したことにより、サーバ管理装置300に対して、電源状態情報を送信するステップS21。リソース割当実行部83は、サーバ1に対して、移行先をサーバ3とする論理サーバのVM移行命令を送信するステップS22。サーバ1の論理サーバ制御部15は、VM移行命令に従って、制御する論理サーバをサーバ3に移行するステップS23。時刻t11において、サーバ3が制御している論理サーバの論理電源が起動されたことで、これらの論理サーバが稼働したとする。サーバ3の論理サーバ状態通知部37は、論理サーバの状態の変化を確認したことにより、サーバ管理装置300に対して、VM状態情報を送信するステップS24。リソース割当実行部83は、サーバ3のリソース利用率が、上限閾値を上回ることも下限閾値を下回ることもないため、サーバ3に対して、VM移行命令を送信しない。これにより、図18bに示す状態になる。以上で、サーバ管理システム1000の動作の説明を終了する。以上のように、第1実施形態に係るサーバ管理システム1000は、リソースの使用率が上限閾値を上回ったサーバがある場合に、論理サーバを他のサーバに移行し、また、下限閾値を下回ったサーバがある場合に論理サーバを他のサーバに移行するとともに、下限閾値を下回ったサーバの電源をOFFする。つまり、第1実施形態に係るサーバ管理システム1000は、リソースの使用率が高いサーバの負荷の突出を抑制することができ、リソースの使用率が低いサーバの電源をOFFすることができる。したがって、第1実施形態に係るサーバ管理システム1000は、システムを安全に運用した上で、全体の電力量を低減することができる。また、第1実施形態に係るサーバ管理システム1000は、リソースの使用率が上限閾値を上回ったサーバがある場合に、休止状態のサーバを起動する。したがって、第1実施形態に係るサーバ管理システム1000は、システムを構成するサーバの負荷を全体的に低く制御することができる。また、第1実施形態に係るサーバ管理システム1000は、リソースの使用率が上限閾値を上回ったサーバがある場合にリソース使用率が最も低いサーバを選択する。したがって、第1実施形態に係るサーバ管理システム1000は、システムを構成するサーバの負荷を全体的に低く制御することができる。さらに、第1実施形態に係るサーバ管理システム1000は、リソースの使用率が下限閾値を下回ったサーバがある場合にリソース使用率が最も低いサーバを選択する。したがって、第1実施形態に係るサーバ管理システム1000は、システムを構成するサーバの負荷を全体的に低く制御することができる。また、第1実施形態に係るサーバ管理システム1000は、論理サーバの状態が変更された場合にのみ判定を行う。したがって、第1実施形態に係るサーバ管理システム1000は、リソース使用率が上限閾値を上回ったか否かの判定、又は下限閾値を下回ったか否かの判定を常に監視する必要がない。第2実施形態第1実施形態に係るサーバ管理システム1000では、リソースの使用率が下限閾値を下回ったサーバがある場合に稼働する論理サーバを他のサーバに移行するとともに、下限閾値を下回ったサーバの電源をOFFすることが可能であった。第2実施形態に係るサーバ管理システム1000Aでは、各論理サーバに信頼性を定義する。定義する信頼性の一例としては、サービス停止の許容時間が挙げられる。そして、第2実施形態に係るサーバ管理システム1000Aは、稼働中の論理サーバを移行する際に、この信頼性を考慮した移行を行う。≪第2実施形態に係るサーバ管理システムの構成≫次に、第2実施形態に係るサーバ管理システムについて説明する。図19は、第2実施形態に係るサーバ管理システム1000Aの構成図である。第2実施形態に係るサーバ管理システム1000Aは、第1実施形態に係るサーバ管理システム1000と比べて、サーバ管理装置300Aの構成が異なる。第2実施形態に係るサーバ管理装置300Aは、第1実施形態に係るサーバ管理装置300と比べて、論理サーバ状態管理テーブル71Aの構成が異なる。また、第2実施形態に係るサーバ管理装置300Aは、以降候補サーバ管理テーブル73が追加されている。また、第2実施形態に係るサーバ管理装置300Aは、リソース割当実行部83Aの処理の内容が異なる。以下、第2実施形態に係るサーバ管理装置300Aの変更点を説明する。論理サーバ状態管理テーブル図20を参照して、論理サーバ状態管理テーブル71Aのデータ構成について説明する。論理サーバ状態管理テーブル71Aは、第1実施形態に係る論理サーバ状態管理テーブル71と比べて、さらにサービス中断許容時間716が構成として追加されている。サービス中断許容時間716の欄には、VM識別子711に該当する論理サーバが稼働状態の場合で、当該論理サーバの移行によりサービスの中断が許容される時間が格納される。サービス中断許容時間716は、信頼性に関する情報である。移行候補サーバ管理テーブル図21を参照して、移行候補サーバ管理テーブル73のデータ構成について説明する。移行候補サーバ管理テーブル73は、サーバ識別子731と、第1の移行候補732と、第2の移行候補733と、第3の移行候補734と、、第nの移行候補739とで構成される。サーバ識別子731の欄には、サーバ1~6を一意に識別する情報が格納される。第1の移行候補732の欄には、サーバ識別子731に対応するサーバ1~6が制御する論理サーバを移行する第1の候補のサーバ1~6を識別する情報が格納される。第2の移行候補733の欄には、サーバ識別子731に対応するサーバ1~6が制御する論理サーバを移行する第2の候補のサーバ1~6を識別する情報が格納される。第3の移行候補734の欄には、サーバ識別子731に対応するサーバ1~6が制御する論理サーバを移行する第3の候補のサーバ1~6を識別する情報が格納される。第nの移行候補739の欄には、サーバ識別子731に対応するサーバ1~6が制御する論理サーバを移行する第nの候補のサーバ1~6を識別する情報が格納される。第1の移行候補732、第2の移行候補733、第3の移行候補734、、第nの移行候補739は、サーバ識別子731に対応するサーバ1~6との関係で決定される。例えば、サーバ間のPingの応答速度が早い順に第1の候補と決定し、または、サーバ間の物理的な位置情報が近い順に第1の候補と決定する。移行候補サーバ管理テーブル73は、随時更新するようにしてもよい。リソース割当実行部図22を参照して、リソース割当実行部83Aが行うリソース割当に関するアルゴリズムを説明する。図22は、第2実施形態に係るサーバ管理装置300Aが行うリソース割当を説明するためのフローチャートである。リソース割当実行部83Aは、第1実施形態のリソース割当実行部83と比べて、サーバ選択処理が異なる。サーバ選択処理の詳細を、図23に示す。図23は、第2実施形態に係るサーバ管理装置300Aが行うリソース割当を説明するためのフローチャートである。ステップS410に続いて、リソース割当実行部83Aは、ステップS410で入力した稼働状態のVM総リソースが0であるか判定し、稼働状態のVM総リソースが0である場合に処理はステップS420に進む。一方、稼働状態のVM総リソースが0でない場合に処理はステップS412に進む。ステップS411Noの場合に、リソース割当実行部83Aは、図20に示す論理サーバ状態管理テーブル71Aを参照し、稼働状態のVM総リソースの内で最も小さいサービス中断許容時間716を取得し、取得した最も小さいサービス中断許容時間716と移行元と移行先の候補のサーバ1~6間の通信速度とに基づいて、図21に示す第1の移行候補732、第2の移行候補733、第3の移行候補734、、第nの移行候補739の中からどこまでの移行候補に実際に移行可能か否かを決定する。次に、リソース割当実行部83Aは、ステップS412で決定した移行候補を、第1の移行候補732から順に選択し、ステップS414~ステップS415の処理を繰り返し行うステップS413。次に、リソース割当実行部83Aは、ステップS410で入力した最大リソースに対する割当中のCPU数723の内の割当中CPU数と、第1のサーバのサーバ識別子721に対応する最大リソースに対する割当中のCPU数723の内の割当中CPU数を加算し、第1のサーバのサーバ識別子721に対応する最大リソースに対する割当中のCPU数723の内のCPU総数の割合を計算しステップS414、計算したリソース割合がサーバ状態管理テーブル72の移行先のサーバの上限閾値728を超えていないか否かを判定するステップS415。サーバの上限閾値728を超えていない場合に、当該サーバを移行先のサーバに決定し、処理は図9のステップS150に進む。一方、サーバの上限閾値728を超えている場合に、リソース割当実行部83Aは、次の移行候補を選択し、ステップS414~ステップS415の処理を行う。移行候補が無くなれば移行処理を終了する。以上で、第2実施形態に係るサーバ管理装置300Aの構成の説明を終了する。また、第2実施形態に係るサーバ管理システム1000Aの構成の説明を終了する。以上のように、第2実施形態に係るサーバ管理システム1000Aは、稼働中の論理サーバを移行する場合に、信頼性に関する情報である中断許容時間情報以内に移行可能なサーバを移行先として選択する。したがって、本発明に係るサーバ管理システムは、信頼性を考慮した論理サーバの移行を行うことができる。変形例以上、本発明の第1実施形態及び第2実施形態について説明したが、本発明はこれに限定されるものではなく、その趣旨を変えない範囲で実施することができる。第1実施形態及び第2実施形態の変形例を以下に示す。リソース第1実施形態及び第2実施形態では、CPU群12,22,32及びメモリ13,23,33をリソースとして上限閾値及び下限閾値を設定したが、その他にも、例えば、ディスク装置100をリソースとしてディスクの使用率に上限閾値及び下限閾値を設定してもよい。また、図24に示すように、サーバ1~6が備えるネットワークカード群18,28,38等をリソースとして、ネットワークカード群18,28,38を用いて通信を行う場合に、ネットワークカード群18,28,38の使用率に上限閾値及び下限閾値を設定してもよい。電源ユニット第1実施形態及び第2実施形態では、電源ユニット11,21,31がサーバの電源のONとOFFとを制御していたが、これ以外にも、電源ユニット11,21,31は、スタンバイモード、省電力モード等を制御するようにしてもよい。この場合、電源ユニット11,21,31は、電源をOFFする代わりにこれらのモードにすることで、電源をOFFするのと同様に電力量を低減することができる。サーバ管理システム第1実施形態及び第2実施形態では、サーバ群200が複数あり、その複数のサーバ群200をサーバ管理装置300が管理することを想定していたので、サーバ群200とサーバ管理装置300とを別々の装置とする構成にしていたが、サーバ管理装置300をサーバ群200内に配設する構成にすることもできる。また、第1実施形態及び第2実施形態では、ディスク装置100とサーバ群200とを別々の装置とする構成にしていたが、ディスク装置100をサーバ群200内に配設する構成にすることもできる。また、第1実施形態及び第2実施形態では、サーバ管理装置300のサーバ状態管理テーブル72に下限閾値727、及び上限閾値728を格納しておく構成としたが、サーバ群200内に下限閾値727、及び上限閾値728を格納する構成として、サーバ管理装置300は、サーバ1~6のリソース使用率が下限閾値727を下回った旨の情報、又は上限閾値728を上回った旨の情報をサーバ群200から受信するようにしてもよい。"