JP2017027166A - 運用管理装置、運用管理プログラムおよび情報処理システム - Google Patents

Abstract

【課題】物理リソースを有効利用することを課題とする。
【解決手段】運用管理サーバは、第１のサーバ群に属する各呼処理サーバについて、各呼処理サーバが有する第１のプロセッサの各コアを、当該呼処理サーバの第１の仮想マシンごとに割り当てる。そして、運用管理サーバは、第１のサーバ群の待機系である第２のサーバ群に属する各呼処理サーバについて、各呼処理サーバが有する第２のプロセッサの複数のコアの一部を、待機系である複数の第２の仮想マシンに割り当てる。
【選択図】図４

Description

本発明は、運用管理装置、運用管理プログラムおよび情報処理システムに関する。

従来、呼処理サービスに利用される交換機のようなサーバシステムは、信頼性が要求されることから、運用系と待機系から構成される二重化構成が一般的である。呼処理サービスは、ＴＡＴ（Turn Around Time）や信号遅延時間が厳格に規定されており、僅かな揺らぎや変動が許容されない要件がある。この対策として、ＣＰＵ（Central Processing Unit）コアリソースを呼処理サービスのプロセスに独占的に割り当てる手法が利用されており、待機系であっても切り替え後の運用化に備え、運用系と同じ条件で待機系のＣＰＵコアリソースが割り当てられている。

近年では、ＮＦＶ（Network Functions Virtualisation）による通信サービスの仮想化が推し進められており、呼処理サービスにおいても、仮想環境を用いた二重化構成が利用されている。例えば、待機系の仮想マシンは、運用系の仮想マシンの故障に備え、ある状態変化のポイントで運用系から送られてくる複製データを受信して、メモリあるいはディスクに格納する。つまり、待機系は、運用系と同じＣＰＵコアリソースが割り当てられ、運用系のデータと同期したデータを保持する。このようにすることで、運用系から待機系の切替時間を短縮し、サービスの信頼性を向上させている。

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

しかしながら、上記技術では、運用系と同条件の待機系を用意することになるので、待機系に割当てる物理リソースが無駄である。例えば、待機系には、運用系と同じＣＰＵコアリソースが割り当てられるが、運用系へ切り替えられるまでは、データ同期程度の処理が実行しない。このため、待機系に割当てられたＣＰＵコアリソースの多くが、通常は使用されていない。

１つの側面では、物理リソースを有効利用することができる運用管理装置、運用管理プログラムおよび情報処理システムを提供することを目的とする。

第１の案では、運用管理装置は、第１のサーバ群に属する物理サーバが有する第１のプロセッサの各コアを、前記物理サーバの第１の仮想マシンごとに割り当てる第１割当部を有する。運用管理装置は、前記第１のサーバ群の待機系である第２のサーバ群に属する物理サーバが有する第２のプロセッサの複数のコアの一部を、前記待機系である複数の第２の仮想マシンに割り当てる第２割当部を有する。

一実施形態によれば、物理リソースを有効利用することができる。

図１は、実施例１にかかるシステムの全体構成例を示す図である。 図２は、呼処理サーバの階層構造例を示す図である。 図３は、運用系と待機系との対応関係を説明する図である。 図４は、実施例１にかかるシステムを構成する各サーバの機能構成を示す機能ブロック図である。 図５は、ＶＭ属性ＤＢに記憶される情報の例を示す図である。 図６は、物理マシン属性ＤＢに記憶される情報の例を示す図である。 図７は、ＶＭリソース管理ＤＢに記憶される情報の例を示す図である。 図８は、ＣＰＵコア管理ＤＢに記憶される情報の例を示す図である。 図９は、運用系である呼処理サーバ１の正常時のＶＭリソース管理状況を説明する図である。 図１０は、待機系である呼処理サーバ３１の正常時のＶＭリソース管理状況を説明する図である。 図１１は、呼処理サーバ１を待機系に切り替えた時のＶＭリソース管理状況を説明する図である。 図１２は、呼処理サーバ１を待機系に切り替えた時の構成図を説明する図である。 図１３は、ＶＭ生成処理の流れを示すシーケンス図である。 図１４は、故障検出時の処理の流れを示すシーケンス図である。 図１５は、運用管理サーバが実行する故障検出時の処理の流れを示すフローチャートである。 図１６は、ハードウェア構成例を示す図である。

以下に、本願の開示する運用管理装置、運用管理プログラムおよび情報処理システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、複数の呼処理サーバ１から３４と、サービス用スイッチ５０と、監視用スイッチ５１と、クライアント装置５２と、運用管理サーバ１００とを有する呼制御システムである。また、このシステムは、呼処理の信頼性を向上させるために、運用系と待機系とで冗長化されている。なお、各サーバの台数は一例であり、任意に設定変更することができる。

また、クライアント装置５２、運用管理サーバ１００、各呼処理サーバは、ネットワークＮを介して相互に通信可能に接続される。かかるネットワークＮには、有線または無線を問わず、インターネット（Internet）を始め、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。

呼処理サーバ１から３４は、ＳＩＰ（Session Initiation Protocol）などを用いた呼処理を実行する物理サーバの一例である。呼処理サーバ１から３４は、サービス用スイッチ５０を介してネットワークＮに接続され、クライアント装置５２や運用管理サーバ１００と通信可能に接続される。また、呼処理サーバ１から３４は、監視用スイッチ５１を介して相互に通信可能に接続される。

各呼処理サーバは、運用管理サーバ１００から受信する設定情報などにしたがって、仮想マシン（ＶＭ：Virtual Machine）を実行し、ＶＭを用いて呼処理サービスを実行する。図２は、呼処理サーバの階層構造例を示す図である。ここでは呼処理サーバ１を例にして説明する。図２に示すように、呼処理サーバ１は、ハードウェア、ＯＳ、サーバ管理部、ＨＶ、ＶＭを有する。ＯＳ、ＨＶおよびＶＭは、物理サーバである呼処理サーバのハードウェアによって、実行されるソフトウェアである。

ハードウェアの構成については後述する。ＯＳは、ハードウェアを制御するオペレーティングシステム（Operating System）である。ＨＶは、ＯＳ上で実行されるハイパーバイザのプログラムである。例えば、ＨＶは、ハードウェアに含まれるメモリの領域を仮想的に割り当てた仮想メモリやハードウェアに含まれるプロセッサを仮想的に割り当てた仮想プロセッサなどを用いて、少なくとも１つのＶＭを実行する。

サーバ管理部は、ＶＭを動作させるための各種情報の設定、ＶＭの生成や削除などを実行するソフトウェア等の一例である。例えば、運用管理サーバ１００は、本システムにおいてシステムの２重化を実現するサーバ管理ソフトウェアのエージェント機能であるサーバ管理エージェントの一例である。各ＶＭは、ＨＶによって生成、管理される仮想マシン・プログラムである。各ＶＭは、ＶＭ上で動作するゲストＯＳ、ＶＭ上で動作するミドルウェア、呼処理サービスを実行する呼処理ＡＰＬ（アプリケーション）を実行する。

この呼処理サーバ１から３４は、運用系の第１サーバ群と待機系の第２サーバ群とに分けられる。本実施例では、呼処理サーバ１から３０は、運用系サーバであり、呼処理サーバ３１から３４は、待機系サーバとする。つまり、呼処理サーバ１から３０で実行される各ＶＭが運用系のサービスを提供し、呼処理サーバ３１から３４で実行される各ＶＭが待機系として機能する。このため、待機系の呼処理サーバ３１から３４は、運用系の呼処理サーバからデータを定期的に取得し、データの同期を実行する。なお、同期の手法等は、公知の様々な手法を採用することができる。

クライアント装置５２は、ユーザが利用するユーザ端末であり、例えばコンピュータや、携帯電話やスマートフォンなどの移動体端末の一例である。このクライアント装置５２は、ＳＩＰ接続要求をいずれかの呼処理サーバに対して送信し、宛先の装置との間でセッションを確立し、呼処理を実行する。

運用管理サーバ１００は、各呼処理サーバで動作させるＶＭを決定し、各ＶＭに関する情報などを呼処理サーバに配信するサーバの一例である。例えば、運用管理サーバ１００は、本システムにおいてシステムの２重化を実現するサーバ管理ソフトウェアのマネージャ機能であるサーバ管理マネージャを実行する。なお、本実施例では、運用管理サーバ１００を物理サーバで実現する例で説明するが、これに限定されるものではなく、ＶＭで実現することもできる。

この運用管理サーバ１００は、第１のサーバ群である運用系に属する呼処理サーバが有する第１のプロセッサの各コアを、呼処理サーバのＶＭごとに割り当てる。運用管理サーバ１００は、待機系である第２のサーバ群に属する呼処理サーバが有する第２のプロセッサの複数のコアの一部を、待機系である複数のＶＭに割り当てる。

ここで、運用管理サーバ１００によって生成される運用系と待機系について説明する。図３は、運用系と待機系との対応関係を説明する図である。なお、以下の実施例では、呼処理サーバ１を呼処理サーバ＃１などと記載する場合がある。

図３に示すように、運用系サーバ群は、呼処理サーバ１から呼処理サーバ３０の合計３０台である。また、各呼処理サーバは、１６個のコアを有するＣＰＵ（Central Processing Unit）を有し、呼処理プロセスを実行する４台のＶＭを動作させる。このとき、運用系の各呼処理サーバは、運用管理サーバ１００の指示にしたがって、ＶＭごとに４つのＣＰＵコアを割当てる。つまり、運用系のＶＭは、同じ物理サーバ上で動作する他のＶＭとＣＰＵコアを共有せず、特定のＣＰＵコアを割当てる。

一方で、待機系サーバ群は、呼処理サーバ３１から呼処理サーバ３４の合計４台である。各呼処理サーバは、１６個のコアを有するＣＰＵを有し、呼処理プロセスを実行する３０台のＶＭを動作させる。このとき、待機系の各呼処理サーバは、運用管理サーバ１００の指示にしたがって、８個のＣＰＵコアを３０台のＶＭに割当てる。つまり、待機系のＶＭは、同じ物理サーバ上で動作する他のＶＭとＣＰＵコアを共有する。なお、各待機系の呼処理サーバは、各運用系の呼処理サーバとデータ同期を実行する。

上述したように、運用管理サーバ１００は、運用系の各ＶＭがＣＰＵコアを占有し、待機系の各仮想マシンがＣＰＵコアを共有するように、各系の呼処理サーバに設定する。このようにすることで、待機系のリソースを削減でき、物理リソースを有効利用できる。

［機能構成］
次に、各呼処理サーバと運用管理サーバの機能構成について説明する。図４は、実施例１にかかるシステムを構成する各サーバの機能構成を示す機能ブロック図である。なお、各呼処理サーバは、同様の構成を有するので、呼処理サーバ１を例にして説明する。

（呼処理サーバの構成）
図４に示すように、呼処理サーバ１は、通信部１ａ、記憶部１ｂ、制御部１ｃを有する。通信部１ａは、有線や無線を問わず、他のサーバとの通信を実行する処理部であり、例えば通信インタフェースなどである。例えば、通信部１ａは、監視用スイッチ５１を介して他の呼処理サーバとの間で各種情報を送受信し、サービス用スイッチ５０を介してクライアント装置５２や運用管理サーバ１００との間で各種情報を送受信する。

記憶部１ｂは、制御部１ｃが実行するプログラムや各種データを記憶する記憶装置であり、例えばハードディスクやメモリなどである。この記憶部１ｂは、動作対象のＶＭ数や各ＶＭへのＣＰＵコアの割当などを示したリストなどの設定情報も記憶する。

制御部１ｃは、呼処理サーバ１全体を司る処理部である。この制御部１ｃは、例えば、ＣＰＵやＭＰＵ（Micro Processing Unit）等によって、内部の記憶装置に記憶されているプログラムがＲＡＭ（Random Access Memory）を作業領域として実行されることにより実現される。また、制御部１ｃは、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されるようにしてもよい。

この制御部１ｃは、ＶＭ制御部１ｄとサーバ管理部１ｅを有する。なお、待機系の呼処理サーバの制御部では、運用系の呼処理サーバから定期的にデータを取得するデータ同期を実行する。

ＶＭ制御部１ｄは、ＶＭに関する各種処理を実行する処理部である。例えば、ＶＭ制御部１ｄは、記憶部１ｂに記憶される設定情報にしたがって、ＶＭの生成、起動、停止、削除、ＶＭに対するＣＰＵコアの割当てなどを実行する。また、ＶＭ制御部１ｄは、運用系から待機系への系切替や待機系から運用系への系切替などを実行する。なお、ＶＭ制御部１ｄは、サーバ管理エージェントの一例である。

例えば、ＶＭ制御部１ｄは、運用管理サーバ１００から、ＶＭとＣＰＵコアとを対応付けたリストを含む切替指示を受信する。すると、ＶＭ制御部１ｄは、受信したリストに従ってＶＭとＣＰＵコアの設定を変更する。ＶＭ制御部１ｄは、入力されたリスト上で、何れのＶＭからも割り当てられていないＣＰＵコアについては電源を停止する。一方、ＶＭ制御部１ｄは、１台以上のＶＭから割り当てられているＣＰＵコアがあれば電源を投入する。そして、ＶＭ制御部１ｄは、全ＶＭに対して上記処理を実施した後、サーバ切り替え制御の結果を、運用管理サーバ１００に応答する。また、ＶＭ制御部１ｄは、運用化される各ＶＭのミドルウェアに対して切り替えを指示して、呼処理を起動させる。

サーバ管理部１ｅは、サーバに関する各種処理を実行する処理部である。具体的には、サーバ管理部１ｅは、ＣＰＵコアへの電源投入や電源ＯＦＦ、各種故障監視、ＣＰＵやメモリなどの負荷測定などを実行する。

例えば、サーバ管理部１ｅは、様々な監視ツール等を用いて、ハードウェア障害、ソフトウェア障害、ネットワーク障害などの各種障害（故障）を検出する。また、サーバ管理部１ｅは、運用管理サーバ１００からの問い合わせに対して、故障の検出有無を応答する。

また、サーバ管理部１ｅは、呼処理サーバ１上で動作するＶＭごとに、ＣＰＵ使用率、メモリ使用率、ネットワーク使用率などの負荷状況を測定する。そして、サーバ管理部１ｅは、運用管理サーバ１００からの問い合わせに対して、測定した負荷状況を応答する。

（運用管理サーバの構成）
図４に示すように、運用管理サーバ１００は、通信部１０１、記憶部１０２、制御部１１０を有する。

通信部１０１は、有線や無線を問わず、他のサーバとの通信を実行する処理部であり、例えば、通信インタフェースなどである。例えば、通信部１０１は、各呼処理サーバから障害の検出有無や負荷状況などを受信し、各呼処理サーバにＶＭの設定に関する設定情報を送信する。

記憶部１０２は、制御部１１０が実行するプログラムや各種データを記憶する記憶装置であり、例えばハードディスクやメモリなどである。この記憶部１０２は、ＶＭ属性ＤＢ１０３、物理マシン属性ＤＢ１０４、ＶＭリソース管理ＤＢ１０５、ＣＰＵコア管理ＤＢ１０６を記憶する。

ＶＭ属性ＤＢ１０３は、ＶＭに関する情報を記憶するデータベースである。具体的には、ＶＭ属性ＤＢ１０３は、システム内のＶＭごとに、ＶＭが動作するための情報などを記憶する。図５は、ＶＭ属性ＤＢに記憶される情報の例を示す図である。図５に示すように、ＶＭ属性ＤＢ１０３は、「仮想マシン番号、系種別、必要ＣＰＵコア数、ＣＰＵコア使用率閾値、物理サーバ番号」を対応付けたＶＭ属性データを記憶する。

ここで記憶される「仮想マシン番号」は、ＶＭの運用系と待機系それぞれに閉じた一意な番号である。「系種別」は、運用系か待機系かを示す。「必要ＣＰＵコア数」は、運用系のＶＭが必要とするＣＰＵコア数が設定され、待機系のＶＭについては未設定となる。「ＣＰＵコア使用率閾値」は、待機系のＶＭが必要とするＣＰＵ使用率の上限値が設定され、運用系のＶＭについては未設定となる。「物理サーバ番号」は、ＶＭを動作する物理サーバ（呼処理サーバ）に付与される一意な番号である。

物理マシン属性ＤＢ１０４は、物理マシンである呼処理サーバに関する情報を記憶するデータベースである。具体的には、物理マシン属性ＤＢ１０４は、各呼処理サーバに搭載されるＣＰＵコアの数を管理する。図６は、物理マシン属性ＤＢに記憶される情報の例を示す図である。

図６に示すように、物理マシン属性ＤＢ１０４は、「物理サーバ番号、搭載ＣＰＵコア数」を対応付けた物理マシン属性データを記憶する。ここで記憶される「物理サーバ番号」は、物理サーバである呼処理サーバに付与される一意な番号である。「搭載ＣＰＵコア数」は、呼処理サーバに搭載されるＣＰＵコア数である。

ＶＭリソース管理ＤＢ１０５は、ＶＭの状態を記憶するデータベースである。図７は、ＶＭリソース管理ＤＢに記憶される情報の例を示す図である。図７に示すように、ＶＭリソース管理ＤＢ１０５は、「物理サーバ番号、仮想マシン番号、仮想マシン状態、ＣＰＵコア割り当て状態、割り当てＣＰＵコア番号」を対応付けたＶＭリソース管理データを記憶する。

ここで記憶される「物理サーバ番号」は、物理サーバである呼処理サーバに付与される一意な番号である。「仮想マシン番号」は、ＶＭの運用系と待機系それぞれに閉じた一意な番号であり、運用系と待機系に付与される一意な番号はペア同士で同じ番号である。「仮想マシン状態」は、ＶＭの状態が設定され、運用系であることを示す運用中、待機系であることを示す待機中、障害が発生したことを示す故障中のいずれかが設定される。「ＣＰＵコア割り当て状態」は、ＶＭに対するＣＰＵコアの割当状態が設定され、占有か共有のいずれかが設定される。「割り当てＣＰＵコア番号」は、ＶＭで使用しているＣＰＵコア番号が設定され、ビットマップで設定される。なお、ビットマップにおいては、使用されているＣＰＵコアには「１」、未使用のＣＰＵコアには「０」が設定される。

ＣＰＵコア管理ＤＢ１０６は、各呼処理サーバが有するＣＰＵコアの状態を記憶するデータベースである。図８は、ＣＰＵコア管理ＤＢに記憶される情報の例を示す図である。図８に示すように、ＣＰＵコア管理ＤＢ１０６は、「物理サーバ番号、ＣＰＵコア番号、ＣＰＵコア状態」を対応付けたＣＰＵコア管理データを記憶する。

ここで記憶される「物理サーバ番号」は、物理サーバである呼処理サーバに付与される一意な番号である。「ＣＰＵコア番号」は、ＣＰＵコアを識別する番号であり、呼処理サーバ内で一意な番号である。「ＣＰＵコア状態」は、ＣＰＵコアの状態が設定され、運用中、停止中、故障中のいずれかが設定される。

制御部１１０は、運用管理サーバ１００全体を司る処理部である。この制御部１１０は、例えば、ＣＰＵやＭＰＵ等によって、内部の記憶装置に記憶されているプログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１１０は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されるようにしてもよい。この制御部１１０は、割当部１１１、監視部１１２、切替部１１３を有する。

割当部１１１は、運用系に属する呼処理サーバ１から３０の各ＶＭについて、各呼処理サーバが有するＣＰＵの各コアを割当て、待機系に属する呼処理サーバ３１から３４のＶＭについて、呼処理サーバ３１から３４が有するＣＰＵコアの一部を割当てる処理部である。

具体的には、割当部１１１は、予め定められた定義書やユーザからの入力にしたがって、物理マシン属性ＤＢ１０４とＶＭ属性ＤＢ１０３とを生成し、ＶＭとＣＰＵコアとの対応付けをリスト化する。そして、割当部１１１は、リスト化されたＶＭとＣＰＵコアの対応表を仮想マシンのイメージファイルに包含して、各呼処理サーバにダウンロードさせて展開する。呼処理サーバでは、展開後にサーバ管理エージェントが起動され、包含された対応表を参照しながら、ＶＭとＣＰＵコアの対応付けが実施される。

例えば、割当部１１１は、クライアント装置５２からの入力にしたがって、図６に示した物理マシン属性ＤＢ１０４に記憶される物理マシン属性データを、全呼処理サーバ台数分設定する。設定する情報は、システムユニークな物理サーバ番号と、各物理サーバが実装するＣＰＵコア数の対応付けである。なお、本実施例では、呼処理サーバが３４台、ＣＰＵコア数が各呼処理サーバに１６個搭載されているものとする。

割当部１１１は、物理マシン属性データを設定した後、図５に示したＶＭ属性ＤＢ１０３に記憶されるＶＭ属性データを設定する。具体的には、割当部１１１は、ＶＭ属性データについて、運用系と待機系の系種別毎に設定する。割当部１１１は、仮想マシン番号について系種別毎にユニークに設定し、搭載される呼処理サーバとの対応付けを設定するとともに、該呼処理サーバ上でのＣＰＵコアリソースの要求数を設定する。なお、本実施例では、運用系のＶＭはＣＰＵコアを４個占有し、１台の呼処理サーバ上に４台のＶＭを搭載するものとし、計１２０台のＶＭをシステムに設置する。

また、割当部１１１は、待機系のＶＭについては、運用系のＶＭを搭載する呼処理サーバ上のＶＭが、待機系として同一の物理サーバ上に配置されないように設置する。本実施例では、運用系として１台の呼処理サーバ上に４台のＶＭを搭載するため、待機系のＶＭは、最低４台の待機系サーバ（呼処理サーバ）上に分散配置されることになる。また待機系のＶＭはＣＰＵコアを占有しないため、設計上の使用率上限（閾値）を超えない範囲で設定する。この閾値により待機系に集約可能なＶＭ台数に制限をかける。

そして、割当部１１１は、ＶＭ属性データの設定が完了した後、ＶＭとＣＰＵコアの対応付けを設計し、設計結果をリスト化する。このとき、割当部１１１は、待機系の呼処理サーバのリストについて、余剰なＣＰＵコアに対する電源を停止するＣＰＵコア番号も識別できるようにする。

割当部１１１は、ＶＭとＣＰＵコアの対応付けを行った後、ＶＭリソース管理ＤＢ１０５の「仮想マシン状態」に運用中または待機中の何れかを設定する。同様に、割当部１１１は、「ＣＰＵコア割り当て状態」に占有または共有の何れかを設定し、「割り当てＣＰＵコア番号」に該ＶＭが使用しているＣＰＵコア番号を設定する。また、割当部１１１は、ＣＰＵコア管理ＤＢ１０６に対して、物理サーバ単位にＣＰＵコアの使用状態を「ＣＰＵコア状態」に設定する。なお、割当部１１１は、上記した設定が完了すると、監視部１１２に障害監視の開始を指示する。

ここで、上記処理によって生成されるＤＢの一例として、システム起動時のＶＭリソース管理ＤＢ１０５の管理状況について具体例を説明する。図９は、運用系である呼処理サーバ１の正常時のＶＭリソース管理状況を説明する図である。図９に示すように、運用系の呼処理サーバ１にはＶＭ＃１からＶＭ＃４の４台が動作する。割当部１１１は、ＶＭ＃１からＶＭ＃４の「系種別」を「運用中」に設定して、ＶＭ＃１、ＶＭ＃２、ＶＭ＃３、ＶＭ＃４それぞれを動作させる。また、割当部１１１は、ＶＭ１に対してＣＰＵコア１から４のビットマップを「１」に変更して、「ＣＰＵ割り当て状態」に「占有」を設定し、ＶＭ＃１に４つのコアを占有させる。同様に、割当部１１１は、ＶＭ＃２に対してＣＰＵコア５から８のビットマップを「１」に変更して、「ＣＰＵ割り当て状態」に「占有」を設定し、ＶＭ＃２に４つのコアを占有させる。また、割当部１１１は、ＶＭ＃３に対してＣＰＵコア９から１２のビットマップを「１」に変更して、「ＣＰＵ割り当て状態」に「占有」を設定し、ＶＭ＃３に４つのコアを占有させる。割当部１１１は、ＶＭ＃４に対してＣＰＵコア１３から１６のビットマップを「１」に変更して、「ＣＰＵ割り当て状態」に「占有」を設定し、ＶＭ４に４つのコアを占有させる。

また、図１０は、待機系である呼処理サーバ３１の正常時のＶＭリソース管理状況を説明する図である。図１０に示すように、待機系の呼処理サーバ３１にはＶＭ＃１、＃５、＃９・・・＃１１７の３０台が存在する。割当部１１１は、各ＶＭの「系種別」に「待機中」を設定して、３０台の各ＶＭを待機系に設定する。さらに、割当部１１１は、各ＶＭの「ＣＰＵ割り当て状態」に「共有」を設定し、ＣＰＵコア１から８のビットマップを「１」に設定することで、各ＶＭにＣＰＵコア１から８を共有させる。

監視部１１２は、運用系の呼処理サーバ１から３０の障害発生を監視する処理部である。具体的には、監視部１１２は、ＳＮＭＰ（Simple Network Management Protocol）トラップや監視ツールなどを用いて、運用系の障害監視を実行する。また、監視部１１２は、運用管理サーバ１００主体で定期的に監視を実行することもでき、障害を検知した呼処理サーバから障害発生の通知を受信することもできる。

一例を挙げると、監視部１１２は、各呼処理サーバのサーバ管理エージェントに対して定期的に監視信号を送信する。そして、監視部１１２は、正常処理中を示す応答を返信した呼処理サーバについては正常動作と判定し、異常を示す応答を返信した呼処理サーバまたは所定時間内に返信が受信できない呼処理サーバについては障害と判定する。そして、監視部１１２は、障害が検出された呼処理サーバに関する情報として、例えば物理サーバ番号などを切替部１１３等に出力する。

切替部１１３は、障害が発生した場合に、運用系から待機系への系切替を実行する処理部である。具体的には、切替部１１３は、監視部１１２によって障害が検出された呼処理サーバで動作する４つのＶＭを停止させる。続いて、切替部１１３は、待機系の呼処理サーバ３１から３４から１つずつ、切替先のＶＭを選択する。その後、切替部１１３は、選択した各ＶＭのＣＰＵコア割当に関し、ＣＰＵコアの共有から占有に変更する。

例えば、切替部１１３は、呼処理サーバ１が故障した場合、ＶＭ属性ＤＢ１０３から呼処理サーバの物理サーバ番号「１」上の仮想マシン番号を全て抽出する。続いて、切替部１１３は、抽出した仮想マシン番号に対応したＶＭリソース管理ＤＢ１０５の「仮想マシン状態」を故障中に設定する。その後、切替部１１３は、故障を検出したＶＭに割り当てられているＣＰＵコア番号を抽出し、ＣＰＵコア管理ＤＢ１０６の「ＣＰＵコア状態」を故障中に設定する。

続いて、切替部１１３は、故障した呼処理サーバ１に対応した待機系の呼処理サーバの物理サーバ番号及び仮想マシン番号を抽出する。具体的には、切替部１１３は、ＶＭ属性ＤＢ１０３を参照して、呼処理サーバ１で動作するＶＭの仮想マシン番号を抽出する。そして、切替部１１３は、ＶＭリソース管理ＤＢ１０５を参照し、抽出した仮想マシン番号と対応付けられる物理サーバ番号のうち、呼処理サーバの物理サーバ番号「１」以外の物理サーバ番号を特定する。特定した物理サーバ番号に対応する呼処理サーバが、切替先の待機系物理サーバであり、抽出された仮想マシン番号が、切替先の待機系ＶＭである。

続いて、切替部１１３は、切り替え先の呼処理サーバ単位に、ＶＭとＣＰＵコアの対応付けリストを作成する。そして、切替部１１３は、リストに従って呼処理サーバ３１〜３４のサーバ管理エージェントに対して、ＶＭの切り替えを指示する。

その後、切替部１１３は、ＶＭへの切り替えが完了した後、生成したリストにしたがって、ＶＭリソース管理ＤＢ１０５において、ＶＭリソース管理データの「仮想マシン状態」を運用中に変更し、「ＣＰＵコア割り当て状態」を占有状態に変更し、「割り当てＣＰＵコア番号」を更新する。また、切替部１１３は、ＣＰＵコア管理ＤＢ１０６の「ＣＰＵコア状態」を、電源の投入状態にあわせて、運用中へ更新する。

また、切替部１１３は、故障が復旧した場合、切替時に設定した各ＤＢの情報を切替前の状態に戻すとともに、元に戻ったＤＢの情報を基にＶＭとＣＰＵコアとを対応付けたリストを生成して、各呼処理サーバに送信して切り戻しを指示する。各呼処理サーバでは、受信したリストにしたがって、ＶＭの起動、停止、ＣＰＵコアの割当変更などを実行して、故障前の状態に戻す。

ここで、故障を契機に待機系に切り替えたときのＤＢの一例としてＶＭリソース管理ＤＢ１０５について説明する。図１１は、呼処理サーバ１を待機系に切り替えた時のＶＭリソース管理状況を説明する図である。ここで、上述したように、呼処理サーバ１ではＶＭ＃１、ＶＭ＃２、ＶＭ＃３、ＶＭ＃４の４台が動作していたものとする。また、呼処理サーバ３１上の待機系ＶＭ＃１、呼処理サーバ３２上の待機系ＶＭ＃２、呼処理サーバ３３上の待機系ＶＭ＃３、呼処理サーバ３４上の待機系ＶＭ＃４が、運用系と同じ仮想マシン番号が割与えられていることから、切替先に指定される。

このような状態において、図１１に示すように、切替部１１３は、呼処理サーバ３１に対応するＶＭリソース管理データにおいて、運用系のＶＭ＃１に対応する仮想マシン番号「１」の「系種別」を「運用中」に変更して、待機系である呼処理サーバ３１上の待機系ＶＭ＃１を運用系に切り替える。また、切替部１１３は、この仮想マシン番号「１」の「ＣＰＵコア割り当て状態」を「占有」に変更して、他のＶＭに対応付けられるＣＰＵコア１から４のビットマップを「０」に変更することで、４つのＣＰＵコアを占有させる。さらに、切替部１１３は、待機系で共有していたＣＰＵコア１から４を占有させたことから、他のＶＭに対応付けられるＣＰＵコア９から１２のビットマップを「１」に変更することで、新たに共有させる。

同様に、切替部１１３は、呼処理サーバ３２に対応するＶＭリソース管理データにおいて、運用系のＶＭ＃２に対応する仮想マシン番号「２」の「系種別」を「運用中」に変更して、待機系である呼処理サーバ３２上の待機系ＶＭ＃２を運用系に切り替える。また、切替部１１３は、この仮想マシン番号「２」の「ＣＰＵコア割り当て状態」を「占有」に変更して、他のＶＭに対応付けられるＣＰＵコア１から４のビットマップを「０」に変更することで、４つのＣＰＵコアを占有させる。さらに、切替部１１３は、待機系で共有していたＣＰＵコア１から４を占有させたことから、他のＶＭに対応付けられるＣＰＵコア９から１２のビットマップを「１」に変更することで、新たに共有させる。

また、切替部１１３は、呼処理サーバ３３に対応するＶＭリソース管理データにおいて、運用系のＶＭ＃３に対応する仮想マシン番号「３」の「系種別」を「運用中」に変更して、待機系である呼処理サーバ３３上の待機系ＶＭ＃３を運用系に切り替える。また、切替部１１３は、この仮想マシン番号「３」の「ＣＰＵコア割り当て状態」を「占有」に変更して、他のＶＭに対応付けられるＣＰＵコア１から４のビットマップを「０」に変更することで、４つのＣＰＵコアを占有させる。さらに、切替部１１３は、待機系で共有していたＣＰＵコア１から４を占有させたことから、他のＶＭに対応付けられるＣＰＵコア９から１２のビットマップを「１」に変更することで、新たに共有させる。

同様に、切替部１１３は、呼処理サーバ３４に対応するＶＭリソース管理データにおいて、運用系のＶＭ＃４に対応する仮想マシン番号「４」の「系種別」を「運用中」に変更して、待機系である呼処理サーバ３４上の待機系ＶＭ＃４を運用系に切り替える。また、切替部１１３は、この仮想マシン番号「４」の「ＣＰＵコア割り当て状態」を「占有」に変更して、他のＶＭに対応付けられるＣＰＵコア１から４のビットマップを「０」に変更することで、４つのＣＰＵコアを占有させる。さらに、切替部１１３は、待機系で共有していたＣＰＵコア１から４を占有させたことから、他のＶＭに対応付けられるＣＰＵコア９から１２のビットマップを「１」に変更することで、新たに共有させる。

このような設定にしたがって、各呼処理サーバがＶＭへのＣＰＵコア割り当てなどを変更することで、運用系と待機系とが切り替わる。図１２は、呼処理サーバ１を待機系に切り替えた時の構成図を説明する図である。図１２に示すように、呼処理サーバ１が故障してＶＭ＃１からＶＭ＃４が停止すると、呼処理サーバ３１のＶＭ＃１が４つのＣＰＵコアを占有して起動し、呼処理サーバ３２のＶＭ＃２が４つのＣＰＵコアを占有して起動し、呼処理サーバ３３のＶＭ＃３が４つのＣＰＵコアを占有して起動し、呼処理サーバ３４のＶＭ＃４が４つのＣＰＵコアを占有して起動する。この結果、停止したＶＭと同条件で待機系を起動させることができる。

また、呼処理サーバ３１から３４の他のＶＭに対して、新たに４つのＣＰＵコア（ＣＰＵコア９から１２）を共有させることで、待機系で最低限必要なＣＰＵコア数を維持することができ、待機系のサービスも維持することができる。

［ＶＭ生成処理］
図１３は、ＶＭ生成処理の流れを示すシーケンス図である。図１３に示すように、運用管理サーバ１００の割当部１１１は、クライアント装置５２等からの指示にしたがって、ＶＭ属性ＤＢ１０３を更新し（Ｓ１０１）、物理マシン属性ＤＢ１０４を更新する（Ｓ１０２）。なお、割当部１１１は、必要に応じて他のＤＢも更新する。

その後、割当部１１１は、ＶＭとＣＰＵコアの割当とを対応付けたリストを含むＶＭ起動指示を全呼処理サーバに送信する（Ｓ１０３とＳ１０４）。

この指示を受信した各呼処理サーバは、ロードモジュールとコンフィグファイル一式などを含むイメージファイルを、運用管理サーバ１００からダウンロードする。例えば、呼処理サーバ１の制御部１ｃは、イメージファイルを運用管理サーバ１００からダウンロードし（Ｓ１０５とＳ１０６）、呼処理サーバ２の制御部１ｃは、イメージファイルを運用管理サーバ１００からダウンロードする（Ｓ１０７とＳ１０８）。同様に、呼処理サーバ３１の制御部１ｃは、イメージファイルを運用管理サーバ１００からダウンロードし（Ｓ１０９とＳ１１０）、呼処理サーバ３４の制御部１ｃは、イメージファイルを運用管理サーバ１００からダウンロードする（Ｓ１１１とＳ１１２）。

その後、各呼処理サーバは、ダウンロードが完了すると、完了通知を運用管理サーバ１００に送信する。例えば、呼処理サーバ１の制御部１ｃは、完了通知を運用管理サーバ１００に送信し（Ｓ１１３とＳ１１４）、呼処理サーバ２の制御部１ｃは、完了通知を運用管理サーバ１００に送信する（Ｓ１１５とＳ１１６）。同様に、呼処理サーバ３１の制御部１ｃは、完了通知を運用管理サーバ１００に送信し（Ｓ１１７とＳ１１８）、呼処理サーバ３４の制御部１ｃは、完了通知を運用管理サーバ１００に送信する（Ｓ１１９とＳ１２０）。

すると、運用管理サーバ１００の割当部１１１は、各呼処理サーバに、ＶＭの起動および生成指示を送信する（Ｓ１２１とＳ１２２）。その後、各呼処理サーバは、ＶＭの生成を実行する。

具体的には、呼処理サーバ１の制御部１ｃは、サーバ管理エージェントを起動し（Ｓ１２３）、イメージファイルを展開し（Ｓ１２４）、イメージファイルからＶＭを生成し（Ｓ１２５）、ＶＭとＣＰＵコアの割当を設定する（Ｓ１２６）。ここでは、呼処理サーバ１の制御部１ｃは、対象となっているＶＭの台数である４台分Ｓ１２５とＳ１２６を繰り返し、処理が終了すると、ＶＭ生成および起動の完了通知を運用管理サーバ１００に送信する（Ｓ１２７）。その後、運用管理サーバ１００の割当部１１１は、ＶＭリソース管理ＤＢ１０５を更新し（Ｓ１２８）、ＣＰＵコア管理ＤＢ１０６を更新する（Ｓ１２９）。

このＳ１２３からＳ１２９までを含む生成処理が、呼処理サーバ２でもＶＭの台数である４台分実行され（Ｓ１３０）、呼処理サーバ３１ではＶＭの台数である３０台分実行され（Ｓ１３１）、呼処理サーバ３４でもＶＭの台数である３０台分実行される（Ｓ１３２）。

［故障検出時の処理］
図１４は、故障検出時の処理の流れを示すシーケンス図である。図１４に示すように、運用管理サーバ１００の監視部１１２は、各呼処理サーバに故障確認を実行する（Ｓ２０１とＳ２０２）。そして、呼処理サーバ１のサーバ管理部１ｅが故障通知応答する（Ｓ２０３とＳ２０４）。

すると、運用管理サーバ１００の監視部１１２は、呼処理サーバ１の故障を検出し（Ｓ２０５）、切替部１１３は、ＶＭ属性ＤＢ１０３を参照して、故障した呼処理サーバ１で動作する対象ＶＭの仮想マシン番号を全て抽出する（Ｓ２０６）。

続いて、切替部１１３は、ＶＭリソース管理ＤＢ１０５において、抽出した対象ＶＭに対応付ける「仮想マシン状態」を「故障中」に更新するとともに（Ｓ２０７）、ＣＰＵコア管理ＤＢ１０６において、該当するＣＰＵコアの「ＣＰＵコア状態」を「故障中」に更新する（Ｓ２０８）。

そして、切替部１１３は、ＶＭ属性ＤＢ１０３を参照して、抽出したＶＭの仮想マシン番号と対応付けられる待機系の呼処理サーバおよび仮想マシン番号を決定する（Ｓ２０９）。

その後、切替部１１３は、切替情報を示すＶＭとＣＰＵコアとを対応付けたリストを含む切替指示を、切替先に指定された呼処理サーバ３１に送信する（Ｓ２１０とＳ２１１）。

呼処理サーバ３１のＶＭ制御部１ｄは、該当ＶＭにＣＰＵコアを割当てる（Ｓ２１２）。具体的には、ＶＭ制御部１ｄは、受信したリストに基づいて運用化されるＶＭを特定し、当該ＶＭにＣＰＵコアを占有させ、他の待機系ＶＭとの共有を解除する。このとき、ＶＭ制御部１ｄは、新たなＣＰＵコアを共有させる。続いて、ＶＭ制御部１ｄは、受信したリストにしたがって新たに共有させるＣＰＵコアの電源を投入する（Ｓ２１３）。そして、ＶＭ制御部１ｄは、系切替を実行して、該当する待機系ＶＭを運用系に切り替え（Ｓ２１４）、切替完了を運用管理サーバ１００に通知する（Ｓ２１５とＳ２１６）。

その後、運用管理サーバ１００の割当部１１１は、ＶＭリソース管理ＤＢ１０５を更新し（Ｓ２１７）、ＣＰＵコア管理ＤＢ１０６を更新する（Ｓ２１８）。このＳ２１０からＳ２１８までを含む切替処理が、呼処理サーバ３４を含む各切替先サーバで実行される（Ｓ２１９）。

［運用管理サーバの処理］
次に、故障検出時に、運用管理サーバ１００が実行する処理を説明する。図１５は、運用管理サーバが実行する故障検出時の処理の流れを示すフローチャートである。ここでは、一例として、上述した例と同様、ＶＭ＃１からＶＭ＃４を動作させる呼処理サーバ１が故障したこととする。

図１５に示すように、運用管理サーバ１００の監視部１１２が呼処理サーバ１の故障を検出すると（Ｓ３０１：Ｙｅｓ）、切替部１１３は、各ＤＢを参照して、故障した呼処理サーバ１で実行されるＶＭ＃１からＶＭ＃４を全て抽出する（Ｓ３０２）。

続いて、切替部１１３は、各ＤＢにおいて、故障した呼処理サーバ１のＶＭ＃１からＶＭ＃４の状態を故障中に設定し（Ｓ３０３）、故障した呼処理サーバ１のＣＰＵコアを故障中に設定する（Ｓ３０４）。

その後、切替部１１３は、故障したＶＭ＃１からＶＭ＃４の仮想マシン番号と同じ仮想マシン番号が付与されているＶＭを有する待機系の呼処理サーバ３１から３４を切替先に決定する（Ｓ３０５）。

そして、切替部１１３は、切替元の呼処理サーバの物理サーバ番号と仮想マシン番号をキーにしてＶＭリソース管理ＤＢ１０５やＶＭ属性ＤＢ１０３を検索し、切替先の待機系サーバの物理サーバ番号や仮想マシン番号を抽出する（Ｓ３０６）。

続いて、切替部１１３は、切替先の待機系サーバである呼処理サーバ３１から３４について、ＶＭとＣＰＵコアとを対応付けたリストを生成し（Ｓ３０７）、生成したリストにしたがって切替先の各呼処理サーバ３１から３４に、切替準備を指示する（Ｓ３０８）。

その後、切替部１１３は、切替準備の完了通知を受信すると（Ｓ３０９：Ｙｅｓ）、切替先の各呼処理サーバ３１から３４に、切替を指示する（Ｓ３１０）。そして、切替部１１３は、切替先の各呼処理サーバへの指示が完了すると（Ｓ３１１：Ｙｅｓ）、切替先の各ＶＭについてＶＭリソース管理ＤＢ１０５を更新し（Ｓ３１２）、ＣＰＵコア管理ＤＢ１０６を更新する（Ｓ３１３）。

［効果］
このように、運用管理サーバ１００は、運用系のＶＭでは呼処理サービスのリアルタイム性を重視するため、同じ物理サーバ上に同居する他のＶＭとはＣＰＵコアの共有はさせず、特定のＣＰＵコアを呼処理プロセスに割り当てる。また、運用管理サーバ１００は、待機系のＶＭについて、全運用系ＶＭに対して同じ物理サーバに配置しないように分散配置する。これにより運用系の物理サーバが１台故障してもサービス停止を回避することができる。

更に、運用管理サーバ１００は、１台の物理サーバ内のＣＰＵコアを複数の待機系ＶＭと共有使用させることで、物理サーバ台数を削減することができる。また、運用管理サーバ１００は、待機系が故障切り替えによって運用化された後も、サービス低下をさせないようにするために、１台以上の仮想マシン分のＣＰＵコアリソースは予備として確保しておく。また、予備確保したＣＰＵコアは電源をオフにしておき消費電力を削減する。また、運用管理サーバ１００は、物理サーバを修復・切り戻す事によって定常状態へ復旧させることができる。

また、運用管理サーバ１００は、待機系ＶＭにＣＰＵコアリソースを共有利用させることにより、余剰のＣＰＵコアリソースを効率的に利用することが可能になる。この結果、待機系サーバは運用系サーバと同等な台数を必要とせず、待機系サーバの数を減らすことができ、不要な物理リソースの削減が実現できる。例えば、上記例で説明すると、従来では、運用系サーバと待機系サーバでは合計６０台が必要であったが、本実施例により３４台に削減することができ、約４３％の削減効果がある。

また、一般的に、待機系のＶＭは、運用系のＶＭの故障に備え、ある状態変化のポイントで運用系から送られてくる複製データを受信して、メモリあるいはディスクに格納する処理に必要となるＣＰＵ使用率は僅か１０％程度である。そこで、運用管理サーバ１００は、待機系ＶＭとしての処理を行うための必要最低限の物理リソースを稼働させることにより、ＣＰＵコアリソースへの供給電力消費を抑えることが可能になる。例えば、上記例で説明すると、従来では待機系のＣＰＵコアリソースの稼動数が６４コアであったが、本実施例により３２コアに削減することができ、約５０％の削減効果がある。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

例えば、上記実施例では、切替先のＶＭとして異なる物理サーバ上のＶＭを選択する例を説明したが、これに限定されるものではなく、同じ物理サーバ上で動作する複数のＶＭを切替先として選択することができる。また、ＶＭの数や必要とするＣＰＵコア数も一例であり、任意に変更することができる。また、上記実施例では、リアルタイム性を有する呼処理を例にして説明したが、これに限定されるものではなく、通常のデータ通信などにも適用することができる。

［システム］
また、図示した装置の各構成は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、任意の単位で分散または統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［ハードウェア］
運用管理サーバ１００と各呼処理サーバは、基本的に同じハードウェア構成を有するので、ここではサーバ２００として説明する。なお、各サーバで異なる点については、具体的に説明する。

図１６は、ハードウェア構成例を示す図である。図１６に示すように、サーバ２００は、ＮＩＣ２００ａ、ＮＩＣ２００ｂ、ディスク２００ｃ、メモリ２００ｄ、プロセッサ２００ｅを有する。また、図１６に示した各部は、バス等で相互に接続される。なお、運用管理サーバ１００の場合は、ＮＩＣ２００ｂは有していなくてもよい。

ＮＩＣ２００ａは、サービス用スイッチ５０と接続されるネットワークインタフェースカードであり、ネットワークＮを介して各種情報の送受信を実行する。ＮＩＣ２００ｂは、監視用スイッチ５１と接続されるネットワークインタフェースカードであり、呼処理サーバ間で各種情報の送受信を実行する。

ディスク２００ｃは、各種プログラムやＤＢを記憶するハードディスクなどである。例えば、ディスク２００ｃは、図４等に示した機能を動作させるプログラム、ＤＢ、テーブルなどを記憶する。

プロセッサ２００ｅは、図４等に示した各処理部と同様の処理を実行するプログラムをディスク２００ｃ等から読み出してメモリ２００ｄに展開することで、図４等で説明した各機能を実行するプロセスを動作させる。

例えば、このプロセスは、運用管理サーバ１００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ２００ｅは、割当部１１１、監視部１１２、切替部１１３と同様の機能を有するプログラムをディスク２００ｃ等から読み出す。そして、プロセッサ２００ｅは、割当部１１１、監視部１１２、切替部１１３と同様の処理を実行するプロセスを実行する。

このようにサーバ２００は、プログラムを読み出して実行することで運用管理方法を実行する情報処理装置として動作する。また、サーバ２００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、サーバ２００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。なお、各呼処理サーバについても同様である。

１００ 運用管理サーバ
１０１ 通信部
１０２ 記憶部
１０３ ＶＭ属性ＤＢ
１０４ 物理マシン属性ＤＢ
１０５ ＶＭリソース管理ＤＢ
１０６ ＣＰＵコア管理ＤＢ
１１０ 制御部
１１１ 割当部
１１２ 監視部
１１３ 切替部

Claims (6)

1. 第１のサーバ群に属する物理サーバが有する第１のプロセッサの各コアを、前記物理サーバの第１の仮想マシンごとに割り当てる第１割当部と、
   前記第１のサーバ群の待機系である第２のサーバ群に属する物理サーバが有する第２のプロセッサの複数のコアの一部を、前記待機系である複数の第２の仮想マシンに割り当てる第２割当部と、
   を有することを特徴とする運用管理装置。
2. 前記第１のサーバ群の前記第１の仮想マシンで実行されている処理を前記複数の第２の仮想マシンが実行する場合に、前記複数の第２の仮想マシンごとに、前記第２のプロセッサの各コアを割り当てるように、前記複数の第２の仮想マシンに対するコアの割当を変更する割当変更部をさらに有することを特徴とする請求項１に記載の運用管理装置。
3. 前記第２割当部は、前記複数の第２の仮想マシンに割り当てられる前記複数のコアの一部以外のコアへの電力供給を停止することを特徴とする請求項１に記載の運用管理装置。
4. 複数の前記第１の仮想マシンで実行されている処理を前記待機系に切り替える場合、前記複数の第２の仮想マシンの中から、異なる物理サーバで動作する複数の仮想マシンを切替先に選択する選択部と、
   前記選択部によって選択された前記複数の仮想マシン各々に対して、当該仮想マシンが動作する物理サーバの第２のプロセッサのコアを割当てるように、前記複数の仮想マシンに対するコアの割当を変更する割当変更部とをさらに有することを特徴とする請求項１に記載の運用管理装置。
5. コンピュータに、
   第１のサーバ群に属する物理サーバが有する第１のプロセッサの各コアを、前記物理サーバの第１の仮想マシンごとに割り当て、
   前記第１のサーバ群の待機系である第２のサーバ群に属する物理サーバが有する第２のプロセッサの複数のコアの一部を、前記待機系である複数の第２の仮想マシンに割り当てる、
   処理を実行させることを特徴とする運用管理プログラム。
6. 第１の物理サーバと第２の物理サーバと運用管理装置とを有する情報処理システムにおいて、
   前記運用管理装置は、
   第１のサーバ群に属する前記第１の物理サーバが有する第１のプロセッサの各コアを、前記第１の物理サーバの第１の仮想マシンごとに割り当てる第１の割当情報を前記第１の物理サーバに送信する第１送信部と、
   前記第１のサーバ群の待機系である第２のサーバ群に属する前記第２の物理サーバが有する第２のプロセッサの複数のコアの一部を、前記待機系である複数の第２の仮想マシンに割り当てる第２の割当情報を前記第２の物理サーバに送信する第２送信部と、を有し、
   前記第１の物理サーバは、
   前記運用管理装置から前記第１の割当情報を受信する受信部と、
   受信された前記第１の割当情報にしたがって、各第１の仮想マシンに、前記第１のプロセッサの各コアを割当てる割当部と、を有し
   前記第２の物理サーバは、
   前記運用管理装置から前記第２の割当情報を受信する受信部と、
   受信された前記第２の割当情報にしたがって、前記待機系である複数の第２の仮想マシンに、前記第２のプロセッサの複数のコアの一部を割当てる割当部と、
   を有することを特徴とする情報処理システム。

Images