JP4951034B2 - 計算機システムとその稼働情報管理方法 - Google Patents

Description

本発明は、ソフトウェアが複数の物理サーバ上で稼働する際の性能、障害、システム構成といった稼働に関する情報を記録したログの内容を正確に突き合わせることを可能とする技術に関する。

近年、ブレードサーバ市場や仮想サーバ市場の伸長に伴い、業務、例えば、業務アプリケーションを別のサーバへ移動させて稼働させたり、稼働中の仮想サーバを別の物理サーバで稼働する仮想化機構上へ移動させたりすることで、業務を性能の異なる別の物理サーバへ移動させたりすることが可能になってきている。

この際、仮想サーバを別の物理サーバへ移動させる毎に、管理サーバが、移行時刻、仮想サーバ識別子、移動元の物理サーバの識別子、および移行先の物理サーバの識別子を含む移動履歴を記録するようにしたものが提案されている（特許文献１参照）。
特開２００７−３２３２４４号公報

上記のように、業務を稼働させる物理サーバを移動することは公知技術を用いて実施することが可能である。この際、稼働情報であるログは、各階層（物理サーバ、仮想化機構、仮想サーバ、OS、業務アプリケーション）で別々に設定されているとともに、物理サーバとそれ以外のログは共通する識別子として、時刻が設定されている。すなわち、常に同じ物理サーバ上で業務が稼働している場合は、単一の物理サーバのログのみを参照すれば良いため、この唯一の手掛かりである時刻を基に、業務のログと物理サーバのログを突き合わせることが可能であった。

一方、上記特許文献１に開示される技術は、複数の物理サーバで仮想サーバが移動するケースに着目し、仮想サーバが移動したときに、物理サーバのログへリンクを張るなどして、時刻を識別子とした情報の追跡を可能としている。

しかし、一般的には、時刻は物理サーバ毎に異なる。このため、時刻を識別子としたのでは、時刻調整による弊害、例えば、同じアラートを複数回送信してしまう等が生じることがあり、時刻を識別子としている上記特許文献１では、仮想サーバが移動したときに、正確に業務と物理サーバのログを突き合わせることは出来ない。

本発明は、前記従来技術の課題に鑑みて為されたものであり、その目的は、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができる計算機システムの稼働情報管理方法と計算機システムを提供することにある。

前記目的を達成するために、本発明は、ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバを管理サーバで管理するに際して、管理サーバは、ソフトウェア資源のうちいずれかのソフトウェア資源の変更を契機として、各物理サーバのうち、ソフトウェア資源の稼働の変更元となる物理サーバのログ情報に、変更元の物理サーバで稼働していたソフトウェア資源を特定する識別子を記憶し、その後、変更の完了を契機として、他の物理サーバのログ情報に前記識別子を記録することを特徴とする。

本発明によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができる。

本発明の第１実施例を示すシステム構成図である。 管理サーバの構成を示す構成図である。 物理サーバの構成を示す構成図である。 BMCの構成を示す構成図である。 システム構築方法の動作概略を説明するための説明図である。 別のBMCの構成を示す構成図である。 別の物理サーバの構成を示す構成図である。 ブレードサーバのシステム構成を示すシステム構成図である。 サービスプロセッサの構成を示す構成図である。 ブレードサーバの構成を示す構成図である。 物理サーバ管理テーブルを示す構成図である。 仮想化機構管理テーブルを示す構成図である。 仮想サーバ管理テーブルを示す構成図である。 OS管理テーブルを示す構成図である。 業務管理テーブルを示す構成図である。 システム管理テーブルを示す構成図である。 契機管理テーブルを示す構成図である。 マーキング規則管理テーブルを示す構成図である。 課金情報管理テーブルを示す構成図である。 契機監視部の処理を説明するためのフローチャートである。 ログ取得指示部の処理を説明するためのフローチャートである。 マーキング指示部の処理を説明するためのフローチャートである。 仮想サーバの構成を示す構成図である。 ログ収集部の処理を説明するためのフローチャートである。 傾向分析部の処理を説明するためのフローチャートである。 システム構成提案部の処理を説明するためのフローチャートである。

本実施例は、ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバを管理サーバで管理するに際して、管理サーバは、ソフトウェア資源、例えば、業務アプリケーション、OS（Operating System）、仮想サーバ、仮想化機構のうちいずれかの変更を契機として、各物理サーバのうち、ソフトウェア資源の稼働の変更元となる物理サーバのログ情報に、変更元の物理サーバで稼働していたソフトウェア資源を特定する識別子を記憶し、その後、変更の完了を契機として、他の物理サーバのログ情報に前記識別子を記録するものである。

図１は、実施例１における計算機システムの構成図を示す。図１において、計算機システムは、管理サーバ１０１と、複数の物理サーバ１０２を備え、管理サーバ１０１と各物理サーバ１０２は、NW-SW（Network−Switch：管理用ネットワーク）１０３とNW-SW１０４を介して接続されている。

管理サーバ１０１は、NW-SW１０３の管理インタフェース(管理I/F)１１３、NW-SW（業務用ネットワーク）１０４の管理インタフェース１１４へ接続されており、管理サーバ１０１から各NW-SW１０３、１０４のVLAN（Virtual Local Area Network）を設定することが可能である。

NW-SW１０３は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といった、各物理サーバ１０２の運用管理をするために必要なネットワークである。NW-SW１０４は、業務用のネットワークに属しており、各物理サーバ１０２上で実行される業務用アプリケーションが使用するネットワークである。

管理サーバ１０１上では、制御部１１０による処理が実行され、制御部１１０の処理に伴って管理テーブル群１１１が参照および更新される。

図２は、管理サーバ１０１の構成を示す。管理サーバ１０１は、演算を処理するCPU（Central Processing Unit）２０１、CPU２０１で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ２０２、プログラムやデータを格納するストレージ装置とのディスクインタフェース２０３、IP（Internet Protocol）ネットワークを介した通信のためのネットワークインタフェース２０４から構成される。

図２では、ネットワークインタフェース２０４及びディスクインタフェース２０３を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、管理サーバ１０１は、例えば、管理用ネットワーク１０３と業務用ネットワーク１０４への接続は、各々異なるネットワークインタフェース２０４を用いることができる。

メモリ２０２には、制御部１１０および管理テーブル群１１１が格納されている。制御部１１０は、契機監視部２１０（図２０参照）、ログ取得指示部２１１（図２１参照）、マーキング指示部２１２（図２２参照）、ログ収集部２１３（図２４参照）、傾向分析部２１４（図２５参照）、及びシステム構成提案部２１５（図２６参照）を有する。

管理テーブル群１１１は、物理サーバ管理テーブル２２１（図１１参照）、仮想化機構管理テーブル２２２（図１２参照）、仮想サーバ管理テーブル２２３（図１３参照）、OS管理テーブル２２４（図１４参照）、業務管理テーブル２２５（図１５参照）、システム管理テーブル２２６（図１６参照）、契約管理テーブル２２７（図１７参照）、マーキング規則管理テーブル２２８（図１８参照）、及び課金情報管理テーブル２２９（図１９参照）を有する。

各テーブルへの情報収集は、標準インタフェースや情報収集用プログラムを使用した自動収集でも良いし、手動で利用者に入力させても良い。ただし、規則や方針といった情報のうち物理的要件や法律の要請で限界値が決定されるもの以外は、利用者に予め入力させる必要がある。この場合、入力用のインタフェースを備える必要がある。また、利用者の方針によって、限界値に至らない運用をする場合も、同様に条件を入力するインタフェースが必要である。

図３は、物理サーバ１０２の構成を示す。物理サーバ１０２は、演算を処理するCPU３０１、CPU３０１で演算するプログラムや、プロググラムの実行に伴うデータを格納するメモリ３０２、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース３０４、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース３０３、CPU３０１に対する電源制御や各インタフェース３０３、３０４に対する制御を行うBMC（Baseboard Management Controller）３０５を有する。

また、メモリ３０２には、ソフトウェア資源として、プログラム３１１と業務アプリケーション３２１およびOS３１１の他に、後述するように、仮想サーバと仮想化機構が格納されている。仮想化機構は、物理サーバ１０２のハードウェア資源であるCPU３０１などを仮想化したものである。仮想サーバは、仮想化機構で仮想化された仮想サーバである。OS３１１は、仮想サーバは、OS３１１上で動作し、仮想サーバは、仮想化機構上で動作する。

この物理サーバ１０２においては、メモリ３０２上のOS３１１がCPU３０１によって実行され、OS３１１の下で、業務を提供するアプリケーション３２１や監視プログラム３２２などが動作する。この際、物理サーバ１０２は、アプリケーション３２１や監視プログラム３２２に従って、監視対象などから物理的な稼働情報であるログ情報として、例えば、消費電力を含む電力量などの電力情報、電圧情報、環境温度などの温度情報、電動ファンの回転数を含むファン情報などを収集する。

図３では、ネットワークインタフェース３０３及びディスクインタフェース３０４を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、物理サーバ１０２は、例えば、管理用ネットワーク１０３と業務用ネットワーク１０４への接続は、各々異なるネットワークインタフェース３０３を用いることができる。

図４は、BMC３０５の構成を示す。BMC３０５は、演算を処理するCPU４０１、CPU４０１の演算に伴うデータを格納するメモリ４０２、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース４０３、CPU４０１の演算前後のデータを格納するデータ格納領域４０４、CPU４０１の演算に用いるプログラムを格納するプログラム格納領域４０５を有する。

BMC３０５は、特定用途に特化した機能のみが実装されていることが多いが、BMC３０５にログ情報を追記する仕組みを構築することができる。例えば、ファームウェアを更新する際に、プログラム格納領域４０５に格納されているプログラムに、ログ情報を追記するための機能を追加することで、BMC３０５にログ情報を追記する仕組みを構築することができる。

なお、従来のBMC３０５を利用し続ける場合や、制御インタフェースが公開されてないBMC３０５の場合には、図６や図７に示すように、BMC３０５の内外に、ハードウェア的にデバイス、例えば、プログラムにしたがってログ情報を収集するCPUなどを有するデバイスを追加することよって、ログ情報を追記する仕組みを構築することができる。

図５は、システム稼働情報管理方法の動作概略を示す。まず、（１）管理サーバ１０１は、定期監視またはイベント（サーバ間業務移動指示など）を契機５０１として、ソフトウェア資源の変更に伴う処理を開始する。

（２）次に、管理サーバ１０１は、ソフトウェア資源（業務アプリケーション３２１、OS３１１、仮想サーバ、仮想化機構）のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション３２１を他の物理サーバに移動させる変更が生じた場合、複数の物理サーバ１０２の中から、変更元あるいは移動元となる物理サーバ１０２を抽出し、抽出した移動元の物理サーバ１０２から、移動元の物理サーバ１０２の収集によるログ情報（物理稼働ログ）、例えば、電力情報を収集するとともに、移動元の物理サーバ１０２で稼働していた業務アプリケーション３２１を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集５０２する。

この際、管理サーバ１０１は、識別子と同時に電力情報を取得することで、業務アプリケーション３２１の移動直前の状況をログ情報に残すことが可能となり、これにより高精度な稼働情報のマッピングが可能となる。

（３）次に、管理サーバ１０１は、収集した電力情報に、収集した識別子として、IPアドレスなど記録（マーク）５０３する。

（４）この後、管理サーバ１０１は、契機５０１に伴う制御を移動元の物理サーバ１０２と移動先の物理サーバ（他の物理サーバ）１０２へ指示する。これにより、移動元の物理サーバ（サーバA）１０２で稼働していた業務アプリケーション３２１が移動先の物理サーバ（サーバB）１０２へ移動する。

（５）その後、管理サーバ１０１は、業務アプリケーション３２１を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ（サーバB）１０２のログ情報（物理稼働ログ）、例えば、電力情報に記録（マーク）し、業務アプリケーション３２１が移動先の物理サーバ（サーバB）１０２へ移動したことをログ情報として残す。

これにより、ソフトウェア資源（業務アプリケーション３２１、OS３１１、仮想サーバ、仮想化機構）のうち、例えば、業務アプリケーション３２１で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。

業務アプリケーション３２１や仮想サーバが使用した稼働情報については、OS３１１や仮想化機構が稼働情報または割当情報として正確に把握している。そのため、全体における特定業務アプリケーションまたは特定仮想サーバが利用した使用量を両者で按分し、按分されたものと、本発明で実現する物理的な稼働情報として記録されたログ情報とを正確に突き合わせることによって、特定業務アプリケーションまたは特定仮想サーバが利用した物理量を計算することが可能になる。これにより、例えば、業務毎の消費電力量を正確に知ること出来る。

また、管理サーバ１０１が、各物理サーバ１０２の取得による物理量（例えば、電力量）とその閾値（kW）について監視し、各物理サーバ１０２の取得による物理量が閾値を跨いだとき、例えば、電力量が閾値を超えたとき、あるいは、電力量が閾値を下回ったときを契機として、そのとき稼働していた業務アプリケーション３２１や仮想サーバを把握することが可能になる。

すなわち、管理サーバ１０１は、各物理サーバ１０２からそれぞれログ情報を収集し、収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、複数の物理サーバ１０２のうち、閾値を跨いだログ情報の収集先となる物理サーバ１０２のログ情報に、閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または閾値を跨いだログ情報を記録することができる。これにより、物理視点で、正確なログ情報（業務稼働ログ）を把握することができる。

この際、取得による物理量が閾値を跨いだ物理サーバ１０２に対して、別の物理サーバ、別のシャーシ（ブレードサーバの場合）、別のラック、別のブレーカ、別のフロア、別のセンタへの移動計画を立案することが可能になる。

また、ログ情報に識別子をマーキング（記録）するに際しては、障害、例えば、ハードウェア障害、ソフトウェア障害、性能障害の発生を契機としてマーキングしたり、障害予兆や性能障害予兆でマーキングしたりすることで、以下のようなメリットが生じる。

具体的には、ハードウェア障害を契機として、ソフトウェア情報（識別子など）をハードウェアログにマーキングすると、その時点で稼働していたソフトウェアを記録することで、どのソフトウェアをリカバリすれば良いかを判断することができる。

ソフトウェア障害を契機として、ハードウェア情報（識別子など）をソフトウェアログにマーキングすると、物理的な計算機資源が枯渇していたことが原因なのか判定出来る。

ソフトウェア障害を契機として、ソフトウェア情報（識別子）をハードウェアログにマーキングすると、仮想サーバを利用する環境で、障害がユーザプログラム起因で発生したものか否かを特定出来る。これにより、ユーザが起こした障害の場合は、ユーザに課金するが、計算機環境側が障害を起こした障害の場合は、ユーザに課金しない、といった厳密な運用が可能となる。すなわち、リスクの適正な分散が可能となる。

性能障害を契機として、ハードウェア情報（識別子など）をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。

性能障害を契機として、ソフトウェア情報（識別子）をハードウェアログにマーキングすると、どの業務（ソフトウェア資源）がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。

障害予兆を契機として、ハードウェア情報（識別子など）をソフトウェアログにマーキングすると、ソフトウェアログを監視することで、障害によるシステムダウンが発生する前に、別のサーバへ移動する、といった対策を講じることが可能になる。温度が異常であれば、その周辺の温度が高くなっていると判断し、別のラックやフロアへ移動したり、周辺の温度を取得して移動先を決めたりする、といった対策を講じることが可能になる。

障害予兆を契機として、ソフトウェア情報（識別子）をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、業務の優先順位や移動のし易さなどから、退避の優先順位付けを行い、優先順位の高い業務をより高確率に継続させるよう対策を講じることが可能になる。

性能障害予兆を契機として、ハードウェア情報（識別子など）をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。

性能障害予兆を契機として、ソフトウェア情報（識別子）をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。

図６は、BMC３０５の異なる実現形態を示す。このBMC３０５は、ログ制御機能６０１を有する他は、図４のものと同様である。ログ制御機能６０１は、データ格納領域４０４へ格納されているログ（ログ情報）へマーキングする機能を持つ。なお、ログ制御機能６０１に、データ格納領域４０４からログを収集し、収集したログにマーキングした後、ログ制御機能６０１内にデータを格納するか、あるいは収集したログを管理サーバ１０１へ送信する機能を付加することもできる。

図６におけるBMC３０５は、図４に示すBMC３０５にハードウェアを追加することで実現できる形態であって、過去資産の流用が可能なため、安価に実現することが出来る。また、法規制などの要請により、ログに追記しない形態で保存する必要があって、BMC３０５から、追加されたハードウェアを外す場合には、データ格納領域４０４へ元のログは残す実現方式が可能となる。

図７は、物理サーバ１０２の異なる実現形態を示す。ログ制御機能７０１は、BMC３０５へ格納されているログへマーキングする機能を持つ。なお、ログ制御機能７０１に、BMC３０５からログを収集し、収集したログに、マーキングした後、ログ制御機能７０１内にデータを格納するか、あるいは、収集したログを管理サーバ１０１へ送信する機能を付加することもできる。

図７における物理サーバ１０２は、図６におけるBMC３０５の実現形態と同様、過去資産を流用することで安価に実現できる。また、ログ制御機能７０１と同等の機能が管理サーバ１０１にて実現されていても、同様の効果を得ることが出来る。

図８は、複数の物理サーバ１０２の代わりに、物理サーバと略同一の機能を有する複数のブレードサーバ８０２を用い、各ブレードサーバ８０２をサービスプロセッサ８０１に接続したときの計算機システムの構成図を示す。

管理サーバ１０１は、NW-SW（管理用ネットワーク）１０３を介して、シャーシ８０３のサービスプロセッサ８０１及び各ブレードサーバ８０２と接続されている。サービスプロセッサ８０１は、内部ネットワークを介してブレードサーバ８０２と接続されている。管理サーバ１０１は、NW-SW１０３の管理インタフェース(管理I/F)１１３、NW-SW（業務用ネットワーク）１０４の管理インタフェース１１４へ接続されており、管理サーバ１０１から各NW-SWのVLAN（Virtual LAN）を設定することが可能である。

サービスプロセッサ８０１は、ブレードサーバ８０２のシャーシ８０３への挿抜（ブレードサーバ８０２の追加、削除）やブレードサーバ８０２の障害を検知し、管理サーバ１０１へアラートを通知する。

NW-SW１０３は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といったブレードサーバ１０３の運用管理をするために必要なネットワークである。NW-SW１０４は、業務用のネットワークに属しており、ブレードサーバ８０２上で実行される業務用アプリケーションが使用するネットワークである。

図９は、サービスプロセッサ８０１の構成を示す。図９において、サービスプロセッサ８０１は、演算を処理するCPU９０１、CPU９０１で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ９０２、プログラムやデータを格納するストレージ装置とのディスクインタフェース９０４、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース９０３、ログを制御する機能を持つログ制御機能９０５を有する。

ただし、ログ制御機能９０５は、ブレードサーバ８０２内やブレードサーバ８０２のBMC１００５（図１０参照）内や管理サーバ１０１にて実現されている場合は、必ずしも必要とはしない。

図１０は、ブレードサーバ８０２の構成を示す。図１０において、ブレードサーバ８０２は、演算を処理するCPU１００１、CPU１００１で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ１００２、プログラムやデータを格納するストレージ装置とのディスクインタフェース１００４、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース１００３、電源制御や各インタフェースの制御を行うBMC（Baseboard Management Controller）１００５を有する。

ブレードサーバ８０２は、メモリ１００２上のOS３１１がCPU１００１によって実行されることで、ブレードサーバ８０２内のデバイス管理を行っている。OS３１１の下で、業務を提供する業務アプリケーション３２１や監視プログラム３２２などが動作する。BMC１００５は、サービスプロセッサ８０１と内部ネットワークを介して接続されており、稼働情報や障害情報を通知する機能や、電源制御の指示を受け付け実行する機能を持つ。また、本実施例におけるブレードサーバ８０２は、ログの取得・ログの送信・ログへのマーキングを実行する機能を持つ。

図１１は、物理サーバ管理テーブル２２１を示す。図１１において、物理サーバ１０２やブレードサーバ８０２を管理するための物理サーバ管理テーブル２２１のカラム１１０１には、物理サーバ識別子が格納しており、本識別子によって各物理サーバを一意に識別することができる。カラム１１０１へ格納するデータは、本テーブル２２１で使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。

カラム１１０２には、UUID（Universal Unique IDentifier）が格納されている。UUIDは、重複しないように形式が規定された識別子である。そのため、各サーバ１０２または８０２に対応して、UUIDを保持することにより、確実なユニーク性を保証する識別子となり得る。そのため、カラム１１０１に格納されている識別子は、サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。

ただし、カラム１１０１には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム１１０１のサーバ識別子には、MACアドレス、WWN（World Wide Name）などを用いても良い。

カラム１１０３（カラム１１７１〜カラム１１７２）には、I/Oデバイスに関する情報が格納されている。カラム１１７１には、デバイス種別が格納されている。例えば、HBA（Host Bus Adaptor）やNIC（Network Interface Card）などが格納される。カラム１１７２には、HBAの識別子であるWWN（World Wide Name）、NICの識別子であるMAC（Media Access Control）アドレスが格納されている。

カラム１１０４には、物理サーバ１０２のモデルが格納されている。このモデルは、インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。

カラム１１０５には、物理サーバ１０２の構成に関する構成情報が格納されている。例えば、物理サーバ１０２の構成に関する構成情報として、プロセッサ（CPU３０１、CPU１００１）のアーキテクチャ、シャーシ８０３やスロットなどの物理位置情報、特徴機能（ブレード間SMP：Symmetric Multiprocessing、HA（High Availability）構成などの有無）が格納されている。カラム１１０４も同様、インフラに関わる情報である。

カラム１１０６には、物理サーバ１０２の性能情報が格納されている。カラム１１０４も同様、インフラに関わる情報である。

カラム１１０７には、ログ情報が格納されている。このカラム１１０７には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。

カラム１１０８には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム１１０７とカラム１１０８から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。

インフラに関わる情報は、物理サーバ１０２の移動先を提案する場合に、移動が可能か否かを判定するために必要である。

図１２は、仮想化機構管理テーブル２２２を示している。仮想化機構管理テーブル２２２は、どのような仮想化機構で、どんなログがどこに格納されていて、どのようにすればアクセス可能か、といった情報を管理するものである。

カラム１２０１には、仮想化機構識別子が格納されており、本識別子によって各仮想化機構を一意に識別することができる。カラム１２０１へ格納するデータは、本テーブルで使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで、入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。

カラム１２０２にはUUIDが格納されている。UUIDは、仮想化機構識別子として、有力な候補である。

カラム１２０３には、仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。

カラム１２０４には、仮想化機構設定情報が格納されている。仮想化機構設定情報は、仮想化機構へ接続するために必要なIPアドレスなどである。

カラム１２０５にはログ情報が格納されている。カラム１２０５には、どのような情報をログとして保持し、どこへ保持されているか、が格納される。

カラム１２０６には、ログ情報操作インタフェースが格納されている。ログを操作するときに接続するプログラムやインタフェースに関する情報が格納されている。

カラム１２０５とカラム１２０６から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。

図１３は、仮想サーバ管理テーブル２２３を示している。仮想サーバ管理テーブル２２３は、どのようなシステム構成を定義した仮想サーバで、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。

カラム１３０１には、仮想サーバ識別子が格納されており、本識別子によって各仮想サーバを一意に識別することができる。

カラム１３０２には、UUIDが格納されている。カラム１３０１に格納されている仮想サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム１３０１には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。

例えば、カラム１３０１の仮想サーバ識別子には、仮想MACアドレス、仮想WWNなど（カラム１３７２へ格納）を用いても良い。また、OS３１１によっては、独自にユニーク性を保つための識別子を採用している場合があるが、この場合は、OS３１１が採用しているIDを使っても良いし、ユニーク性を確保するために独自に保持してもかまわない。

カラム１３０３（カラム１３７１〜カラム１３７３）には、仮想I/Oデバイスに関する情報が格納されている。カラム１３７１には、仮想デバイス種別が格納されている。例えば、仮想HBAや仮想NICなどが格納される。カラム１３７２には、仮想HBAの識別子である仮想WWN、仮想NICの識別子である仮想MACアドレスが格納されている。カラム１３７３には、仮想I/Oデバイスのモードが格納されており、このモードには、共有モードと占有モードがある。

仮想デバイスには、使用する物理デバイスを共有で使用するモードと、占有で使用するモードが存在する。共有の場合、他の仮想デバイスが物理デバイスを同時に使用する。占有モードの場合、物理デバイスをその仮想デバイスが単独で使用する。

カラム１３０４には、仮想サーバの仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。

カラム１３０５には、仮想サーバの性能情報が格納されている。カラム１３０４も同様、インフラに関わる情報である。

カラム１３０６には、ログ情報が格納されている。カラム１３０６には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。

カラム１３０７には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム１３０６とカラム１３０７から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。

インフラに関わる情報は、物理サーバ１０２の移動先を提案する場合に、移動が可能か否かを判定するために必要である。

図１４は、OS管理テーブル２２４を示している。OS管理テーブル２２４は、どのようなOS３１１で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのデーブルである。

カラム１４０１には、OS識別子が格納されており、本識別子によってOSを一意に識別することができる。

カラム１４０２には、UUIDが格納されている。カラム１４０１に格納されているOS識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム１４０１には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム１４０１のOS識別子には、OS設定情報（カラム１４０４へ格納）を用いても良い。

カラム１４０３は、OS設定情報が格納されている。例えば、IPアドレスやホスト名、ID、パスワード、ディスクイメージなどが格納されている。ディスクイメージは、設定前後のOSが物理サーバ１０２または仮想サーバ２３０２へ配信されたシステムディスクのディスクイメージを指す。カラム１４０４へ格納するディスクイメージに関する情報は、データディスクを含めても良い。

カラム１４０５には、ログ情報が格納されている。カラム１４０５には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。

カラム１４０６には、ログ情報を操作するインタフェースに関する情報が格納している。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム１４０５とカラム１４０６から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。

図１５は、業務管理テーブル２２５を示している。業務管理テーブル２２５は、どのようなソフトウェア資源（例えば、業務アプリケーション３２１）で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。

カラム１５０１には、業務識別子が格納されており、本識別子によって業務、例えば、業務アプリケーション３２１を一意に識別することができる。

カラム１５０２には、UUIDが格納されている。カラム１５０１に格納されている業務識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム１５０１には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム１５０１のサーバ識別子には、業務設定情報（カラム１５０４へ格納）を用いても良い。

カラム１５０３には、業務種別が格納されており、使用するアプリケーションやミドルウェアといった業務を特定するソフトウェアに関する情報が格納されている。業務で使用する論理的なIPアドレスやID、パスワード、ディスクイメージ、業務で使用するポート番号などが格納されている。ディスクイメージは、設定前後の業務が物理サーバ１０２または仮想サーバ２３０２上のOS３１１へ配信されたシステムディスクのディスクイメージを指す。カラム１５０４へ格納するディスクイメージに関する情報は、データディスクを含めても良い。

カラム１５０５には、ログ情報が格納されている。カラム１５０５には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。

カラム１５０６には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム１５０５とカラム１５０６から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。

図１６は、システム管理テーブル２２６を示している。システム管理テーブル２２６は、物理サーバ管理テーブル２２１、仮想化機構管理テーブル２２２、仮想サーバ管理テーブル２２３、OS管理テーブル２２４及び業務管理テーブル２２５で管理される、物理サーバ１０２、仮想化機構２３０１、仮想サーバ２３０２、OS３３１及び業務３２１の組み合わせによるシステム構成を管理し、システム変更やサーバ移動のステータス及びログ制御を管理するためのテーブルである。

カラム１６０１には、システム識別子が格納しており、本識別子によって業務、例えば、業務アプリケーション３２１を一意に識別することができる。

カラム１６０２には、UUIDが格納されている。カラム１６０３からカラム１６０５の全部または一部の組み合わせで実現しても良いし、独自に生成しても良い。少なくとも、管理サーバ１０１が管理する範囲で一意である必要がある。

カラム１６０３には、物理サーバ識別子１１０１が格納され、カラム１６０４には、仮想化機構識別子１２０１が格納され、カラム１６０５には、仮想サーバ識別子１３０１が格納され、カラム１６０６には、OS識別子１４０１が格納され、カラム１６０７には、業務識別子１５０１が格納されている。

図面には記載していないが、ラックやフロア、コンセントボックス、ブレーカ、センタ、HA構成の有無、ネットワークインフラ情報、電力グリッド、ネットワーク結線関係、ネットワークスイッチ、ファイバチャネルスイッチ、各スイッチの収容量、ネットワーク帯域などを管理することで、それらにまたがったシステムの移動についても本発明の効果を得ることが可能になる。

カラム１６０８には、システム変更ステータスが格納されている。カラム１６０８には、なにをどこへ移動するのか、移動前・移動中・移動後、といったステータスが格納される。

カラム１６０９には、ログ取得ステータスが格納されている。ログ取得ステータスは、ログ取得を要請する対象でのログ取得が完了しているかどうかを管理するためのものである。

カラム１６１０には、マーキングステータスが格納されている。マーキングステータスは、ログへマーキングを要請する対象へマーキングが完了しているかどうかを管理するためのものである。マーキングステータスは、本発明における重要ポイントである。

カラム１６１１には、ログ収集ステータスが格納されている。ログ収集ステータスは、対象からログを収集する場合に、ログ収集が完了しているかどうかを管理するためのものである。管理サーバ１０１内やBMC３０５の内外デバイス、サービスプロセッサ８０１内へログを収集する際に、ステータスを管理する必要がある。

図１７は、契機管理テーブル２２７を示している。契機管理テーブル２２７のカラム１７０１には、契機識別子が格納されている。カラム１７０２には、契機の内容が格納されている。カラム１７０２には、管理サーバ１０１へサーバ移動などの動作が入力される場合もあるが、契機を検出して自動実行するときの動作が入力される場合もある。

後者の場合、動作に伴うイベント通知が契機となる。契機としては、以下に挙げるような動作が考えられるが、システム管理テーブル２２６のシステム構成に関するカラムが変更される場合は、全て契機と成り得る。

仮想サーバをライブマイグレーションする場合、仮想サーバ２３０２以上（仮想サーバ２３０２、OS３２１、業務３２１、図２３参照）は、稼働する物理サーバ１０２を移動（変更）することになり、物理サーバ１０２の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ１０２以外のどれでも良く、複数でも良い。

LU（Logical Unit）を接続する物理サーバ１０２が変更となる場合、OS３２１と業務３２１は稼働する物理サーバ１０２を移動（変更）することになり、物理サーバ１０２の稼働情報ログへマーキングが実施される。マーキングする識別 子は、物理サーバ１０２以外のどれでも良く、複数でも良い。

また、LUを接続する仮想サーバ２３０２が変更となる場合、仮想化機構２３０１または仮想サーバ２３０２以上（OS３２１、業務３２１を含む）が移動することになり、物理サーバ１０２の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。

別の業務のディスクイメージをデプロイ（配信、デプロイメント）する場合、LUを接続するサーバを変更する場合と同様である。

インタフェースカードの固有値（WWNやMACアドレス）を書き換える場合、LUを接続する物理サーバ１０２を変更する場合と同様である。

Java(登録商標)アプリケーションをデプロイする場合、業務３２１内のプロセス（論理サーバ）が追加・削除・変更されるため、業務３２１およびプロセスの識別子を物理サーバ１０２の稼働情報ログへマーキングする。

業務ソフトウェアのIPアドレスを変更する場合、稼働する物理サーバ１０２または仮想サーバ２３０２を移動（変更）するように見なすことが出来る。

この場合も、物理サーバ１０２の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。

ソフトウェア起動通知、OS起動通知、仮想サーバ起動通知、仮想化機構起動通知で、稼働しているシステム情報を取得し、システム管理テーブル２２６との差異を調査し、差異がある場合、物理サーバ１０２の移動（変更）が発生している。物理サーバ１０２の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ１０２以外のどれでも良く、複数でも良い。

この際、管理サーバ１０１は、例えば、ソフトウェア資源がある物理サーバ１０２から、他の物理サーバ１０２に移動する場合、他の物理サーバ１０２が起動したことを条件に、他の物理サーバ１０２に属するソフトウェア資源と他の物理サーバ１０２の構成を示すハードウェア構成情報との間に差異があるか否かを判定し、差異があるときには、その旨の情報を、識別子とともに、他の物理サーバ１０２のログ情報に記録することで、記録された情報を基に正しい構成に修正したり、あるいは、マーキングに失敗したことを把握したりすることができる。

また、上記に挙げる契機で、物理サーバ１０２の識別子を物理サーバ１０２以外の稼働ログへマーキングしても良い。これにより、論理的な稼働情報（業務３２１、OS３１１、仮想サーバ２３０２、仮想化機構２３０１）を記録したログから、正確かつ簡単に物理サーバの稼働情報を参照することが可能である。記録先のログは全てでも良いし、一部でも良い。

監視対象の物理量（例えば消費電力量）が設定した閾値を跨ぐ場合、論理的な稼働情報を記録したログへ、物理サーバ識別子をマーキングする。また、測定した物理量を同時にマーキングしても良い。この契機と同様のものとして、ハードウェアやソフトウェアの障害情報の通知、性能障害情報の通知、警告（障害予兆、性能障害含む）の通知などが挙げられる。

図１８は、マーキング規則管理テーブル２２８を示している。マーキング規則管理テーブル２２８は、どんな契機で、どのログに、なんの識別子をマーキングするか、を管理するためのテーブルである。

カラム１８０１には、規則識別子が格納され、カラム１８０２には、契約識別子（カラム１７０１）が格納され、カラム１８０３には、マーキングする対象の階層が格納され、カラム１８０４には、マーキングする対象となるログまたはログ種別が格納され、カラム１８０５には、マーキングする識別子が格納される。

マーキングの方法としては、ログ内の最新情報部にマーキングする識別子を追記する方法を用いることができる。また、マーキングの開始と終了のみを追記しても良いし（システムが変更されたときのみマーキング）、その後のログ全てにマーキングしても良い。

図１９は、課金情報管理テーブル２２９を示している。課金情報管理テーブル２２９は、課金に関する情報を管理するテーブルであり、運用コストが下がるシステム構成を提案するために使用される。

課金情報管理テーブル２２９のカラム１９０１には、課金情報識別子が格納され、カラム１９０２には、課金対象が格納されている。格納される情報は、消費電力量のような物理量でも良いし、仮想サーバや物理サーバ１０２といったインフラ情報、トランザクション保証のレベルといったSLA（Service Level Agreement）情報でも良い。

カラム１９０３には、課金情報が有効となる条件が格納されている。時刻やシステム構成、インフラ情報（HA構成の有無や種類、ネットワーク帯域、地域など）である。カラム１９０４には、単価が格納されている。

課金情報管理テーブル２２９を利用するに際して、物理稼動情報を記録したログを参照し、温度の高いサーバといったIT機器および負荷のかかったファシリティを検出した場合、課金情報管理テーブル２２９の条件や単価を操作し、一時的に価格を上げ、需要を抑えるような価格操作によって、より効率の良い運用（例えば、該当サーバの需要は下がり、利用率が下がることで温度を下げる効果がある)を管理者に提供することが出来る。

また、計算機資源を利用するユーザにとってみれば、温度が高いサーバを使うことは、温度上昇によるハードウェア障害のリスクが高いことになるが、価格の安い計算機資源を選ぶことで、同時に温度によるハードウェア障害のリスクを回避することも可能となる。

図２０は、契機監視部２１０の処理フローチャートを示す。

契機監視部２１０は、管理サーバ１０１のCPU２０１によって処理を開始する。契機監視部２１０は、契機の発生を監視し、発生した契機についてログへマーキングするか否かを判定し、ログへマーキングする場合は、ログを取得およびマーキングを指示、またはログを収集およびマーキングする指示する。

まず、ステップ２００１で、管理サーバ１０１は契機の発生を監視し、契機が発生した場合、ステップ２００２へ進む。

ステップ２００２で、管理サーバ１０１は、契機を基に契機管理テーブル２２７を参照する。

ステップ２００３で、管理サーバ１０１は、契機管理テーブル２２７を参照した結果を基に、ログへマーキングするか否かを判定し、マーキングする場合、ステップ２００４へ進み、マーキングしない場合、ステップ２００１へ進む。

ステップ２００４で、管理サーバ１０１は、システム管理テーブル２２６を参照し、マーキングする旨、システム管理テーブル２２６を変更し、処理を完了する。

契機としては、ユーザ操作によるもの（GUI操作、CLI発行など）、イベント発生によるもの（ハードウェア障害情報の書き込み及び通知など）、アラート通知によるもの（閾値越え、障害通知など）がある。

図２１は、ログ取得指示部２１１の処理フローチャートを示す。

ログ取得指示部２１１は、管理サーバ１０１のCPU２０１によって処理を開始する。この処理へ移行する前提として、契機監視部２１０が「ログへマーキングする」と判断し、契機を契機監視部２１０から受け取っていることが挙げられる。また、元々のログを取得する契機と時間的に近い場合、ログ取得指示部２１１は、ログ取得を指示しなくても良い。

まず、ステップ２１０１で、ログ取得指示部２１１は、契機管理テーブル２２７を参照する。

ステップ２１０２で、ログ取得指示部２１１は、契機管理テーブル２２７を参照した結果を基に、システム管理テーブル２２６を参照し、次に挙げる、物理サーバ管理テーブル２２１、仮想化機構管理テーブル２２２、仮想サーバ管理テーブル２２３、OS管理テーブル２２４、業務管理テーブル２２５のうち、全てのテーブルまたは契機やログのマーキングに関連するテーブルのみを参照する。

次に、ステップ２１０３において、ログ取得指示部２１１は、ステップ２１０２で参照したテーブルの内容を基に管理対象へログ取得を指示する。

この後、ログ取得指示部２１１は、ステップ２１０４において、システム管理テーブル２２６を更新し、処理を完了する。

図２２は、マーキング指示部２１２の処理フローチャートを示す。

マーキング指示部２１２は、管理サーバ１０１のCPU２０１によって処理を開始する。この処理へ移行する前提として、マーキング対象のログと追記する識別子は確定していることとしている。

まず、ステップ２２０１で、マーキング指示部２１２は、マーキング規則管理テーブル２２８を参照する。

ステップ２２０２で、マーキング指示部２１２は、マーキング規則管理テーブル２２８を参照した結果を基に、マーキング対象のログ情報を保持するテーブルを参照する。参照するテーブルは、物理サーバ管理テーブル２２１、仮想化機構管理テーブル２２２、仮想サーバ管理テーブル２２３、OS管理テーブル２２４、業務管理テーブル２２５のうち、全てでも良いし、マーキング対象となるもののみでも良い。

ステップ２２０３で、マーキング指示部２１２は、マーキング対象ログへ識別子を追記する。

ステップ２２０４で、マーキング指示部２１２は、マーキング対象ログへ識別子を追記した内容を基にシステム管理テーブル２２６を更新する。

本実施例においては、ソフトウェア資源のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション３２１を他の物理サーバに移動させる変更が生じた場合、管理サーバ１０１は、複数の物理サーバ１０２の中から、変更元あるいは移動元となる物理サーバ１０２を抽出し、抽出した移動元の物理サーバ１０２から、移動元の物理サーバ１０２の収集によるログ情報（物理稼働ログ）、例えば、電力情報を収集するとともに、移動元の物理サーバ１０２で稼働していた業務アプリケーション３２１を特定するための識別子、例えば、計算機システムで一意となるIPアドレスを収集し、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、その後、移動先の物理サーバ（サーバB）１０２のログ情報（物理稼働ログ）、例えば、電力情報に記録（マーク）し、業務アプリケーション３２１が移動先の物理サーバ（サーバB）１０２へ移動したことをログ情報として残すこととしている。

従って、本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。

本実施例は、サーバ仮想化技術を利用するとともに、物理サーバとして、ブレードサーバ８０２を用いたものであり、他の構成は、実施例１と同様である。

図２３は、サーバ仮想化技術を適用した実施例２のシステム構成のうち、物理サーバ１０２の内部構成を示している。この際、物理サーバ１０２として、ブレードサーバ８０２を用いても、内部構成は同様である。

ブレードサーバ８０２は、演算を処理するCPU３０１、CPU３０１で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ３０２、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース３０４、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース３０３、電源制御や各インタフェースの制御を行うBMC３０５から構成される。

メモリ３０２には、計算機資源を仮想化するためのサーバ仮想化技術を提供する仮想化機構２３０１が配備され、仮想サーバ２３０２を提供する。また、仮想化機構２３０１は、制御用インタフェースとして仮想化機構管理用インタフェース２３１１を備えている。仮想化機構２３０１は、物理サーバ１０２（またはブレードサーバ８０２）の計算機資源を仮想化し、仮想サーバ２３０２を構成する。仮想サーバ２３０２は、仮想CPU２３２１、仮想メモリ２３２２、仮想ネットワークインタフェース２３２３、仮想ディスクインタフェース２３２４から構成されている。

仮想メモリ２３２２には、OS３３１が配信され、仮想サーバ２３０２内の仮想デバイスを管理している。また、OS３３１上では、業務アプリケーション３２１が実行されている。OS３３１上で稼働する管理プログラム３２２によって、障害検知やOS電源制御、インベントリ管理などが提供されている。

仮想化機構２３０１は、物理デバイスと論理デバイスの対応付けを管理しており、物理デバイスと論理デバイスとを対応付けたり、両者の対応付けを解除したりすることが出来る。

また、メモリ３０２には、どの仮想サーバ２３０２が物理サーバ１０２（またはブレードサーバ８０２）の計算機資源を、どれくらい割り当てられ、また、使用しているかといった構成情報および稼働履歴が保持されている。この情報及び、例えば、物理サーバ１０２が保持する稼働ログ（例えば、消費電力ログ）に、本発明で実施する識別子がマーキングされたログを突き合わせることで、正確にどの仮想サーバ２３０２がどれだけの電力消費に関わっていたかを導くことが可能である。

これにより、精度の高い課金や電力消費の特に高いまたは低い仮想サーバ２３０２を特定することが可能になる。

本発明の実施に関わる制御部１１０及び管理テーブル群１１１の構成は実施例１と同様である。

本実施例では、ソフトウェア資源として、仮想化機構２３０１上に仮想サーバ２３０２が構築され、仮想サーバ２３０２上にOS３３１が構築され、OS３３１上に業務アプリケーション３２１が構築される構成となっている。

このため、仮想化機構２３０１が他の物理サーバ１０２に移動するときには、仮想化機構２３０１とともに、OS３３１及び業務アプリケーション３２１が他の物理サーバ１０２に移動し、仮想サーバ２３０２が他の物理サーバ１０２に移動するときには、仮想サーバ２３０２とともに、OS３３１及び業務アプリケーション３２１が他の物理サーバ１０２に移動し、OS３３１が他の物理サーバ１０２に移動するときには、OS３３１とともに、業務アプリケーション３２１が他の物理サーバ１０２に移動し、業務アプリケーション３２１が他の物理サーバ１０２に移動するときには、業務アプリケーション３２１のみが他の物理サーバ１０２に移動することになる。

この際、管理サーバ１０１は、例えば、業務アプリケーション３２１の移動を契機として、移動対象となる業務アプリケーション３２１を稼働している物理サーバ１０２を変更元あるいは移動元の物理サーバ１０２とし、移動元の物理サーバ１０２から、移動元の物理サーバ１０２の収集によるログ情報（物理稼働ログ）、例えば、電力情報を収集するとともに、移動元の物理サーバ１０２で稼働していた業務アプリケーション３２１を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集する。

次に、管理サーバ１０１は、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、この後、契機に伴う制御を移動元の物理サーバ１０２と移動先の物理サーバ１０２へ指示する。これにより、移動元の物理サーバ１０２で稼働していた業務アプリケーション３２１が移動先の物理サーバ１０２へ移動する。

その後、管理サーバ１０１は、業務アプリケーション３２１を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ１０２のログ情報（物理稼働ログ）、例えば、電力情報に記録（マーク）し、業務アプリケーション３２１が移動先の物理サーバ１０２へ移動したことをログ情報として残す。

これにより、業務アプリケーション３２１で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。

ソフトウェア資源として、業務アプリケーション３２１、OS３３１、仮想サーバ２３０２、仮想化機構２３０１を用い、これらのいずれかをソフトウェア資源の変更の対象として、ログ情報を記録すると、以下のようなメリットが生じる。

ソフトウェア資源の変更の対象として、業務アプリケーション３２１を用いた場合、業務アプリケーショ３２１ンごとに、物理的な計算機資源の利用状況を知ることが可能となる。これにより、業務アプリケーション３２１を追加するときに、同じOS（仮想サーバ）３３１上に同居させるべきか、別のOS（仮想サーバ）３３１上に置くべきかを判断することが可能になる。

また、変更の対象となる業務アプリケーション３２１が稼働している物理サーバ１０２とは別の物理サーバ１０２へ負荷を分散させたり、更に高スペックな物理サーバへ移動させたりするべきか、といった判断が可能となる。

また、一つの業務を提供するソフトウェアが、性能や価格によって幾つか選択可能な場合に、状況に応じて選択可能となる。

ソフトウェア資源の変更の対象として、OS３３１を用いた場合、OS３３１ごとに、物理的な計算機資源の利用状況を知ることが可能となる。すなわち、IPアドレスやホスト名、稼動する業務の設定を引き継ぐことで、あたかもOS３３１が移動したかのように見ることが出来る。これにより、OS３３１は、性能の異なるハードウェア間を容易に移動出来るのだが、この移動をすべきか否かの判断が可能となる。

またディスクイメージをデプロイすることで、移動することも可能であるが、時間がかかるが設定変更に比べて、操作の手間やミス発生の確率が低いというメリットがある。この際、どちらが利用者によって有益化を判定することが可能になる。

ソフトウェア資源の変更の対象として、仮想サーバ２３０２を用いた場合、仮想サーバ２３０２毎に、物理的な計算機資源の利用状況を知ることが可能となる。これにより、仮想サーバ２３０２ごと移動させるか、OS３３１より上位を移動させるか、業務アプリケーション３２１のみを移動させるかを判断することが可能になる。仮想サーバ２３０２を動的に移動させた場合と一旦停止させて移動させた場合では、移動にかかる時間が異なる。このような場合にでも、正確に稼動情報を知ることが可能になり、正しい課金を実施することが出来る。

ソフトウェア資源の変更の対象として、仮想化機構２３０１を用いた場合、仮想化機構２３０１の、物理的な計算機資源の利用状況を知ることが可能となる。異なる仮想化機構（価格、性能といった特徴が異なる）を使い分けることが可能となる。

本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。

本実施例は、ログ収集部２１３が稼働するか否かを判定する他は、実施例１および実施例２と同様である。すなわち、本実施例は、古いシステムやログへの接続が独自インタフェースといった仕様、また独立性の保持という観点（他からログを改ざんされないこと、ログが暗号化されている場合など）が原因で、ログを直接編集出来ない場合が存在することを考慮したものである。ログを直接編集出来ない場合、ログ収集インタフェースを介してログを別のサーバ（例えば管理サーバ１０１）やサービスプロセッサ８０１へ収集し、収集したログにマーキングを施す、といったことが必要である。そのため、ログ収集部２１３が必要となる。

図２４は、ログ収集部２１３の処理フローチャートを示す。

ログ収集部２１３は、管理サーバ１０１のCPU２０１によって処理を開始する。まず、ステップ２４０１で、ログ収集部２１３は、マーキング管理テーブル２２８を参照する。

ステップ２４０２で、ログ収集部２１３は、マーキング管理テーブル２２８を参照した結果を基に、マーキング対象のログ情報を保持するテーブルとして、以下のテーブル、物理サーバ管理テーブル２２１、仮想化機構管理テーブル２２２、仮想サーバ管理テーブル２２３、OS管理テーブル２２４、業務管理テーブル２２５を参照する。

ステップ２４０３で、ログ収集部２１３は、各テーブルの参照結果を基に、ログを他のサーバ（管理サーバ１０１、サービスプロセッサ８０１など）へ収集するか判定し、収集する場合はステップ２４０４へ進み、しない場合は処理を完了する。

ステップ２４０４で、ログ収集部２１３は、管理対象へログ提供を指示し、ログを収集する。

この後、ステップ２４０５で、ログ収集部２１３は、システム管理テーブル２２６を更新して、処理を完了する。

本実施例によれば、古いシステムやログへの接続が独自インタフェースといった仕様、また独立性の保持という観点が原因で、ログを直接編集出来ない場合でも、ログ収集インタフェースを介してログを管理サーバ１０１やサービスプロセッサ８０１へ収集させることができる。

実施例４では、実施例１、実施例２及び実施例３で記載した構成を用いるとともに、業務や物理サーバ１０２の計算機利用に関する傾向分析を実施する。この際、業務視点、物理サーバ視点、仮想サーバ視点といった各階層において、観測する物理量、動作しているソフトウェアや仮想サーバの量や種類、といった可観測なものの傾向を分析することで、利用者や管理ソフトウェアへ分析結果を通知したり、またはアラートを上げたりすることができる。

また、この結果を基にシステム構成提案を実施することで、より効率的な計算機資源の利用を利用者へ提供する。例えば、予算内で一番性能の良い構成や、同じく一番可用性の高い構成、またはその組み合わせなどである。

図２５は、傾向分析部２１４の処理フローチャートを示す。

傾向分析部２１４は、管理サーバ１０１のCPU２０１によって処理を開始する。まず、傾向分析部２１４は、ステップ２５０１で、「分析する視点」と「分析する対象」に関する入力を受け付ける。これは、利用者が契機を与える場合である。または、ハードウェアやソフトウェアの障害通知または性能障害通知を契機としても良い。

これにより、現在の構成では業務の稼働や予算内運用に支障をきたす場合に、利用者は原因の分析結果や回避策となるシステム構成を容易に迅速に把握することが可能となり、対策も容易に迅速に行うことが出来る。

次に、傾向分析部２１４は、ステップ２５０２で、視点を判定する。

ステップ２５０３で、傾向分析部２１４は、システム管理テーブル２２６を参照する。

ステップ２５０４で、傾向分析部２１４は、システム管理テーブル２２６を参照した結果を基に、稼働情報を保持するテーブルとして、以下のテーブル、物理サーバ管理テーブル２２１、仮想化機構管理テーブル２２２、仮想サーバ管理テーブル２２３、OS管理テーブル２２４、業務管理テーブル２２５を参照する。

ステップ２５０５で、傾向分析部２１４は、各テーブルを参照した結果を基に、分析する対象のログの中で、分析する視点のマーキングに相当する箇所を抽出する。

ステップ２５０６で、傾向分析部２１４は、分析結果を出力し、処理を完了する。

本実施例によれば、現在の構成では業務の稼働や予算内運用に支障をきたす場合に、利用者は、原因の分析結果や回避策となるシステム構成を容易に迅速に把握することが可能となり、対策も容易に迅速に行うことが出来る。

図２６は、システム構成提案部２１５の処理フローチャートを示す。

電力使用量を最低にするシステム構成を提案、スペース使用量を最低にするシステム構成を提案、昼夜で使用量または料金が異なる場合に、予算の範囲内で性能または可用性が高いシステムを提案、といったことが可能になる。

例えば、高性能で高可用なシステムが低価格で入手出来れば良いが、現実は高付加価値なシステムほど高価格になる。また利用者の予算は上限が存在し、折り合いをつける必要がある。

使用制限の例としては、予算、消費電力量の上限、CPU使用量の上限および下限（〜％以上で使用したい）、メモリ使用量の上限、ネットワーク帯域使用量の上限、ネットワークインフラ（〜Gbps以上）、業務アプリケーション３２１のスループット上限および下限、計算機資源の占有利用または共有利用、HA構成の有無や種類など、である。

システム構成提案部２１５は、管理サーバ１０１のCPU２０１によって処理を開始する。まず、システム構成提案部２１５は、ステップ２６０１で、「最小または最大にする物理量」（評価基準となる物理量）に関する入力及び「前提条件」（制限値）の入力を受け付ける。

ステップ２６０２で、システム構成提案部２１５は、課金情報管理テーブル２２９、システム管理テーブル２２６を参照する。

ステップ２６０３で、システム構成提案部２１５は、テーブルの参照結果を基に、前提条件内に収まる範囲でシステム構成を変化させる。

ステップ２６０４で、システム構成提案部２１５は、評価基準となる物理量が最小または最大であるか判定する。このとき、最小か最大かはなにを満足する条件として設定するかによって変わる。どちらでも良い訳ではない。システム構成提案部２１５は、最小または最大となる場合はステップ２６０５へ進み、そうでない場合はステップ２６０６へ進む。

ステップ２６０５で、システム構成提案部２１５は、システム構成と目論見の物理量を保存する。この値をステップ２６０４で使用する。

ステップ２６０６で、システム構成提案部２１５は、全試行を完了したかを判定し、完了した場合はステップ２６０７へ進み、完了していない場合はステップ２６０３へ進む。

ステップ２６０７で、システム構成提案部２１５は、保存したシステム構成と目論見の物理量を出力し、処理を完了する。

システム構成提案部２１５は、出力した結果を管理サーバ１０１へアラート通知し、管理サーバ１０１が構成変更の指示を出すことで、管理者が不在の場合も問題を解決することが可能になる。または、自動実行せず、利用者の判断を仰いだ上で、承認後に構成変更が実行されるようになっていても良い。

本実施例によれば、電力使用量を最低にするシステム構成、スペース使用量を最低にするシステム構成あるいは昼夜で使用量または料金が異なる場合に、予算の範囲内で性能または可用性が高いシステム構成を提案することができる。

また、各実施例においては、ログ情報に識別子を記録する代わりに、UUIDを生成し、生成したUUIDをログ情報に記録することもできる。この際、UUIDの生成や記録は、マーキングする主体が行っても良いし、管理サーバ１０１やBMC３０５、サービスプロセッサ８０１が行っても良い。

また、各実施例においては、ログ情報に識別子を記録するに際して、移動に関連する物理サーバ１０２の時刻または管理サーバ１０１の時刻を取得し、取得した時刻をログ情報に記録することで、ログ情報を時刻に関連づけて把握することができる。この際、問い合わせの時刻を用いるときよりも、マーキングの時刻やログに記録された時刻を用いることで、より正確な照合が可能になる。

また、各実施例においては、ログ情報に識別子を記録するに際して、ソフトウェア資源の移動の履歴を示す識別子をログ情報に追加でマーキングすることで、より正確な照合が可能になる。例えば、最近（例えば、ユーザ設定もしくは１０分以内などをデフォルト設定）、同じ物理サーバ１０２間でソフトウェア資源の移動が発生した場合、ソフトウェア資源の移動の履歴を示す識別子を参照することで、２回目以降のソフトウェア資源の移動を正確に把握することができる。

さらに、各実施例においては、管理サーバ１０１が動作の主体であったが、物理サーバ１０２やブレードサーバ８０２、サービスプロセッサ８０１、仮想化機構２３０１、仮想サーバ２３０２が動作の主体となり、制御部及び管理テーブル群を保持していても発明の効果を得ることが出来る。

１０１：管理サーバ、１０２：物理サーバ、３２１：業務、５０１：契機を検出、５０２：識別子を収集、５０３：移動元のログへ識別子をマーキング、５０４：契機に伴う制御を指示、５０３：移動先のログへ識別子をマーキング。

Claims (17)

1. ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバと、前記複数の物理サーバとネットワークを介して接続されて、前記各物理サーバを管理する管理サーバを備え、
   前記管理サーバは、
   前記各物理サーバで稼働するソフトウェア資源のうちいずれかのソフトウェア資源を移動させる変更が生じたことを契機として、
   前記各物理サーバのうち前記ソフトウェア資源の稼働の移動元となる物理サーバからログ情報を収集するステップと、
   前記移動元の物理サーバで稼働していた前記ソフトウェア資源を特定する識別子を前記移動元の物理サーバから収集するステップと、
   前記移動元の物理サーバから収集したログ情報に、前記移動元の物理サーバから収集した識別子を記録するステップと、
   前記ソフトウェア資源が、前記移動元の物理サーバから他の物理サーバに移動したことを条件に、前記他の物理サーバのログ情報に、前記移動元の物理サーバから収集した識別子を記録するステップを実行する、計算機システムの稼働情報管理方法。
2. 前記管理サーバは、
   前記他の物理サーバのログ情報に、前記移動元の物理サーバから収集した識別子を記録するときには、前記ログ情報に、前記識別子を特定するための履歴を記録するステップを実行する、請求項１に記載の計算機システムの稼働情報管理方法。
3. 前記変更は、
   前記移動元の物理サーバに属する前記ソフトウェア資源の前記他の物理サーバへの移動である、請求項１に記載の計算機システムの稼働情報管理方法。
4. 前記変更は、
   前記移動元の物理サーバで稼働していたソフトウェア資源を前記他の物理サーバで稼働させるための、物理サーバの変更である、請求項１に記載の計算機システムの稼働情報管理方法。
5. 前記変更は、
   前記移動元の物理サーバと、前記移動元の物理サーバに属する前記ソフトウェア資源を含むシステム構成の変更である、請求項１に記載の計算機システムの稼働情報管理方法。
6. 前記ソフトウェア資源は、業務アプリケーションである、請求項１、２、３、４または５のうちいずれか１項に記載の計算機システムの稼働情報管理方法。
7. 前記ソフトウェア資源は、オペレーティングシステムである、請求項１、２、３、４または５のうちいずれか１項に記載の計算機システムの稼働情報管理方法。
8. 前記ソフトウェア資源は、仮想サーバである、請求項１、２、３、４または５のうちいずれか１項に記載の計算機システムの稼働情報管理方法。
9. 前記ソフトウェア資源は、仮想化機構である、請求項１、２、３、４または５のうちいずれか１項に記載の計算機システムの稼働情報管理方法。
10. 前記ソフトウェア資源は、前記物理サーバのハードウェア資源を仮想化した仮想化機構と、前記仮想化機構で仮想化された仮想サーバと、前記仮想サーバで動作するオペレーティングシステムと、前記オペレーティングシステムに従って動作する業務アプリケーションである、請求項１、２、３、４または５のうちいずれか１項に記載の計算機システムの稼働情報管理方法。
11. 前記ソフトウェア資源は、前記物理サーバのハードウェアを仮想化した仮想化機構と、前記仮想化機構で仮想化された仮想サーバと、前記仮想サーバで動作するオペレーティングシステムと、前記オペレーティングシステムに従って動作する業務アプリケーションで構成され、前記ソフトウェア資源を移動させる変更は、前記仮想化機構と、前記仮想サーバと、前記オペレーティングシステムまたは前記業務アプリケーションのうち少なくとも１つの変更である、請求項１、２、３、４または５のうちいずれか１項に記載の計算機システムの稼働情報管理方法。
12. ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバと、前記複数の物理サーバとネットワークを介して接続されて、前記各物理サーバを管理する管理サーバを備え、
    前記管理サーバは、
    前記各物理サーバで稼働するソフトウェア資源のうちいずれかのソフトウェア資源を移動させる変更が生じたことを契機として、前記各物理サーバのうち前記ソフトウェア資源の稼働の移動元となる物理サーバからログ情報を収集すると共に、前記移動元の物理サーバで稼働していた前記ソフトウェア資源を特定する識別子を前記移動元の物理サーバから収集し、
    前記移動元の物理サーバから収集したログ情報に、前記移動元の物理サーバから収集した識別子を記録し、
    前記ソフトウェア資源が、前記移動元の物理サーバから他の物理サーバに移動したことを条件に、前記他の物理サーバのログ情報に、前記移動元の物理サーバから収集した識別子を記録する、計算機システム。
13. 前記変更は、前記移動元の物理サーバに属する前記ソフトウェア資源の前記他の物理サーバへの移動である、請求項１２に記載の計算機システム。
14. 前記変更は、前記移動元の物理サーバで稼働していたソフトウェア資源を前記他の物理サーバで稼働させるための、物理サーバの変更である、請求項１２に記載の計算機システム。
15. 前記変更は、
    前記移動元の物理サーバと、前記移動元の物理サーバに属する前記ソフトウェア資源を含むシステム構成の変更である、請求項１２に記載の計算機システム。
16. 前記ソフトウェア資源は、前記物理サーバのハードウェアを仮想化した仮想化機構と、前記仮想化機構で仮想化された仮想サーバと、前記仮想サーバで動作するオペレーティングシステムと、前記オペレーティングシステムに従って動作する業務アプリケーションである、請求項１２、１３、１４または１５のうちいずれか１項に記載の計算機システム。
17. 前記ソフトウェア資源は、前記物理サーバのハードウェアを仮想化した仮想化機構と、前記仮想化機構で仮想化された仮想サーバと、前記仮想サーバで動作するオペレーティングシステムと、前記オペレーティングシステムに従って動作する業務アプリケーションで構成され、前記ソフトウェア資源を移動させる変更は、前記仮想化機構と、前記仮想サーバと、前記オペレーティングシステムまたは前記業務アプリケーションのうち少なくとも１つの変更である、請求項１２、１３、１４または１５のうちいずれか１項に記載の計算機システム。

Images