計算機システムとその稼働情報管理方法
【課題】 物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができること。
【解決手段】 管理サーバ101は、各物理サーバ102からそれぞれログ情報を収集し、いずれかのログ情報が、予め設定した閾値を跨いだことを契機として、閾値を跨いだログ情報の収集先となる物理サーバ102のログ情報に、閾値を跨いだログ情報の収集のために稼働している業務アプリケーション321を特定する識別子または閾値を跨いだログ情報を記録し、業務アプリケーション321が、他の物理サーバ102に移動したことを条件に、他の物理サーバ102のログ情報に、識別子または閾値を跨いだログ情報を記録する。
【解決手段】 管理サーバ101は、各物理サーバ102からそれぞれログ情報を収集し、いずれかのログ情報が、予め設定した閾値を跨いだことを契機として、閾値を跨いだログ情報の収集先となる物理サーバ102のログ情報に、閾値を跨いだログ情報の収集のために稼働している業務アプリケーション321を特定する識別子または閾値を跨いだログ情報を記録し、業務アプリケーション321が、他の物理サーバ102に移動したことを条件に、他の物理サーバ102のログ情報に、識別子または閾値を跨いだログ情報を記録する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ソフトウェアが複数の物理サーバ上で稼働する際の性能、障害、システム構成といった稼働に関する情報を記録したログの内容を正確に突き合わせることを可能とする技術に関する。
【背景技術】
【0002】
近年、ブレードサーバ市場や仮想サーバ市場の伸長に伴い、業務、例えば、業務アプリケーションを別のサーバへ移動させて稼働させたり、稼働中の仮想サーバを別の物理サーバで稼働する仮想化機構上へ移動させたりすることで、業務を性能の異なる別の物理サーバへ移動させたりすることが可能になってきている。
【0003】
この際、仮想サーバを別の物理サーバへ移動させる毎に、管理サーバが、移行時刻、仮想サーバ識別子、移動元の物理サーバの識別子、および移行先の物理サーバの識別子を含む移動履歴を記録するようにしたものが提案されている(特許文献1参照)。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2007−323244号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記のように、業務を稼働させる物理サーバを移動することは公知技術を用いて実施することが可能である。この際、稼働情報であるログは、各階層(物理サーバ、仮想化機構、仮想サーバ、OS、業務アプリケーション)で別々に設定されているとともに、物理サーバとそれ以外のログは共通する識別子として、時刻が設定されている。すなわち、常に同じ物理サーバ上で業務が稼働している場合は、単一の物理サーバのログのみを参照すれば良いため、この唯一の手掛かりである時刻を基に、業務のログと物理サーバのログを突き合わせることが可能であった。
【0006】
一方、上記特許文献1に開示される技術は、複数の物理サーバで仮想サーバが移動するケースに着目し、仮想サーバが移動したときに、物理サーバのログへリンクを張るなどして、時刻を識別子とした情報の追跡を可能としている。
【0007】
しかし、一般的には、時刻は物理サーバ毎に異なる。このため、時刻を識別子としたのでは、時刻調整による弊害、例えば、同じアラートを複数回送信してしまう等が生じることがあり、時刻を識別子としている上記特許文献1では、仮想サーバが移動したときに、正確に業務と物理サーバのログを突き合わせることは出来ない。
【0008】
本発明は、前記従来技術の課題に鑑みて為されたものであり、その目的は、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができる計算機システムの稼働情報管理方法と計算機システムを提供することにある。
【課題を解決するための手段】
【0009】
前記目的を達成するために、本発明は、各物理サーバからそれぞれログ情報を収集し、前記収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、前記物理サーバのうち、前記閾値を跨いだログ情報の収集先となる物理サーバのログ情報に、前記閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または前記閾値を跨いだログ情報を記録し、その後、前記他の物理サーバのログ情報に、前記収集先となる物理サーバのログ情報に記録された前記識別子または前記閾値を跨いだログ情報を記録することを特徴とする。
【発明の効果】
【0010】
本発明によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができる。
【図面の簡単な説明】
【0011】
【図1】本発明の第1実施例を示すシステム構成図である。
【図2】管理サーバの構成を示す構成図である。
【図3】物理サーバの構成を示す構成図である。
【図4】BMCの構成を示す構成図である。
【図5】システム構築方法の動作概略を説明するための説明図である。
【図6】別のBMCの構成を示す構成図である。
【図7】別の物理サーバの構成を示す構成図である。
【図8】ブレードサーバのシステム構成を示すシステム構成図である。
【図9】サービスプロセッサの構成を示す構成図である。
【図10】ブレードサーバの構成を示す構成図である。
【図11】物理サーバ管理テーブルを示す構成図である。
【図12】仮想化機構管理テーブルを示す構成図である。
【図13】仮想サーバ管理テーブルを示す構成図である。
【図14】OS管理テーブルを示す構成図である。
【図15】業務管理テーブルを示す構成図である。
【図16】システム管理テーブルを示す構成図である。
【図17】契機管理テーブルを示す構成図である。
【図18】マーキング規則管理テーブルを示す構成図である。
【図19】課金情報管理テーブルを示す構成図である。
【図20】契機監視部の処理を説明するためのフローチャートである。
【図21】ログ取得指示部の処理を説明するためのフローチャートである。
【図22】マーキング指示部の処理を説明するためのフローチャートである。
【図23】仮想サーバの構成を示す構成図である。
【図24】ログ収集部の処理を説明するためのフローチャートである。
【図25】傾向分析部の処理を説明するためのフローチャートである。
【図26】システム構成提案部の処理を説明するためのフローチャートである。
【発明を実施するための形態】
【実施例1】
【0012】
本実施例は、ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバを管理サーバで管理するに際して、管理サーバは、ソフトウェア資源、例えば、業務アプリケーション、OS(Operating System)、仮想サーバ、仮想化機構のうちいずれかの変更を契機として、各物理サーバのうち、ソフトウェア資源の稼働の変更元となる物理サーバのログ情報に、変更元の物理サーバで稼働していたソフトウェア資源を特定する識別子を記憶し、その後、変更の完了を契機として、他の物理サーバのログ情報に前記識別子を記録するものである。
【0013】
図1は、実施例1における計算機システムの構成図を示す。図1において、計算機システムは、管理サーバ101と、複数の物理サーバ102を備え、管理サーバ101と各物理サーバ102は、NW-SW(Network−Switch:管理用ネットワーク)103とNW-SW104を介して接続されている。
【0014】
管理サーバ101は、NW-SW103の管理インタフェース(管理I/F)113、NW-SW(業務用ネットワーク)104の管理インタフェース114へ接続されており、管理サーバ101から各NW-SW103、104のVLAN(Virtual Local Area Network)を設定することが可能である。
【0015】
NW-SW103は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といった、各物理サーバ102の運用管理をするために必要なネットワークである。NW-SW104は、業務用のネットワークに属しており、各物理サーバ102上で実行される業務用アプリケーションが使用するネットワークである。
【0016】
管理サーバ101上では、制御部110による処理が実行され、制御部110の処理に伴って管理テーブル群111が参照および更新される。
【0017】
図2は、管理サーバ101の構成を示す。管理サーバ101は、演算を処理するCPU(Central Processing Unit)201、CPU201で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ202、プログラムやデータを格納するストレージ装置とのディスクインタフェース203、IP(Internet Protocol)ネットワークを介した通信のためのネットワークインタフェース204から構成される。
【0018】
図2では、ネットワークインタフェース204及びディスクインタフェース203を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、管理サーバ101は、例えば、管理用ネットワーク103と業務用ネットワーク104への接続は、各々異なるネットワークインタフェース204を用いることができる。
【0019】
メモリ202には、制御部110および管理テーブル群111が格納されている。制御部110は、契機監視部210(図20参照)、ログ取得指示部211(図21参照)、マーキング指示部212(図22参照)、ログ収集部213(図24参照)、傾向分析部214(図25参照)、及びシステム構成提案部215(図26参照)を有する。
【0020】
管理テーブル群111は、物理サーバ管理テーブル221(図11参照)、仮想化機構管理テーブル222(図12参照)、仮想サーバ管理テーブル223(図13参照)、OS管理テーブル224(図14参照)、業務管理テーブル225(図15参照)、システム管理テーブル226(図16参照)、契約管理テーブル227(図17参照)、マーキング規則管理テーブル228(図18参照)、及び課金情報管理テーブル229(図19参照)を有する。
【0021】
各テーブルへの情報収集は、標準インタフェースや情報収集用プログラムを使用した自動収集でも良いし、手動で利用者に入力させても良い。ただし、規則や方針といった情報のうち物理的要件や法律の要請で限界値が決定されるもの以外は、利用者に予め入力させる必要がある。この場合、入力用のインタフェースを備える必要がある。また、利用者の方針によって、限界値に至らない運用をする場合も、同様に条件を入力するインタフェースが必要である。
【0022】
図3は、物理サーバ102の構成を示す。物理サーバ102は、演算を処理するCPU301、CPU301で演算するプログラムや、プロググラムの実行に伴うデータを格納するメモリ302、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース304、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース303、CPU301に対する電源制御や各インタフェース303、304に対する制御を行うBMC(Baseboard Management Controller)305を有する。
【0023】
また、メモリ302には、ソフトウェア資源として、プログラム311と業務アプリケーション321およびOS311の他に、後述するように、仮想サーバと仮想化機構が格納されている。仮想化機構は、物理サーバ102のハードウェア資源であるCPU301などを仮想化したものである。仮想サーバは、仮想化機構で仮想化された仮想サーバである。OS311は、仮想サーバは、OS311上で動作し、仮想サーバは、仮想化機構上で動作する。
【0024】
この物理サーバ102においては、メモリ302上のOS311がCPU301によって実行され、OS311の下で、業務を提供するアプリケーション321や監視プログラム322などが動作する。この際、物理サーバ102は、アプリケーション321や監視プログラム322に従って、監視対象などから物理的な稼働情報であるログ情報として、例えば、消費電力を含む電力量などの電力情報、電圧情報、環境温度などの温度情報、電動ファンの回転数を含むファン情報などを収集する。
【0025】
図3では、ネットワークインタフェース303及びディスクインタフェース304を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、物理サーバ102は、例えば、管理用ネットワーク103と業務用ネットワーク104への接続は、各々異なるネットワークインタフェース303を用いることができる。
【0026】
図4は、BMC305の構成を示す。BMC305は、演算を処理するCPU401、CPU401の演算に伴うデータを格納するメモリ402、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース403、CPU401の演算前後のデータを格納するデータ格納領域404、CPU401の演算に用いるプログラムを格納するプログラム格納領域405を有する。
【0027】
BMC305は、特定用途に特化した機能のみが実装されていることが多いが、BMC305にログ情報を追記する仕組みを構築することができる。例えば、ファームウェアを更新する際に、プログラム格納領域405に格納されているプログラムに、ログ情報を追記するための機能を追加することで、BMC305にログ情報を追記する仕組みを構築することができる。
【0028】
なお、従来のBMC305を利用し続ける場合や、制御インタフェースが公開されてないBMC305の場合には、図6や図7に示すように、BMC305の内外に、ハードウェア的にデバイス、例えば、プログラムにしたがってログ情報を収集するCPUなどを有するデバイスを追加することよって、ログ情報を追記する仕組みを構築することができる。
【0029】
図5は、システム稼働情報管理方法の動作概略を示す。まず、(1)管理サーバ101は、定期監視またはイベント(サーバ間業務移動指示など)を契機501として、ソフトウェア資源の変更に伴う処理を開始する。
【0030】
(2)次に、管理サーバ101は、ソフトウェア資源(業務アプリケーション321、OS311、仮想サーバ、仮想化機構)のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション321を他の物理サーバに移動させる変更が生じた場合、複数の物理サーバ102の中から、変更元あるいは移動元となる物理サーバ102を抽出し、抽出した移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集502する。
【0031】
この際、管理サーバ101は、識別子と同時に電力情報を取得することで、業務アプリケーション321の移動直前の状況をログ情報に残すことが可能となり、これにより高精度な稼働情報のマッピングが可能となる。
【0032】
(3)次に、管理サーバ101は、収集した電力情報に、収集した識別子として、IPアドレスなど記録(マーク)503する。
【0033】
(4)この後、管理サーバ101は、契機501に伴う制御を移動元の物理サーバ102と移動先の物理サーバ(他の物理サーバ)102へ指示する。これにより、移動元の物理サーバ(サーバA)102で稼働していた業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動する。
【0034】
(5)その後、管理サーバ101は、業務アプリケーション321を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ(サーバB)102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動したことをログ情報として残す。
【0035】
これにより、ソフトウェア資源(業務アプリケーション321、OS311、仮想サーバ、仮想化機構)のうち、例えば、業務アプリケーション321で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。
【0036】
業務アプリケーション321や仮想サーバが使用した稼働情報については、OS311や仮想化機構が稼働情報または割当情報として正確に把握している。そのため、全体における特定業務アプリケーションまたは特定仮想サーバが利用した使用量を両者で按分し、按分されたものと、本発明で実現する物理的な稼働情報として記録されたログ情報とを正確に突き合わせることによって、特定業務アプリケーションまたは特定仮想サーバが利用した物理量を計算することが可能になる。これにより、例えば、業務毎の消費電力量を正確に知ること出来る。
【0037】
また、管理サーバ101が、各物理サーバ102の取得による物理量(例えば、電力量)とその閾値(kW)について監視し、各物理サーバ102の取得による物理量が閾値を跨いだとき、例えば、電力量が閾値を超えたとき、あるいは、電力量が閾値を下回ったときを契機として、そのとき稼働していた業務アプリケーション321や仮想サーバを把握することが可能になる。
【0038】
すなわち、管理サーバ101は、各物理サーバ102からそれぞれログ情報を収集し、収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、複数の物理サーバ102のうち、閾値を跨いだログ情報の収集先となる物理サーバ102のログ情報に、閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または閾値を跨いだログ情報を記録することができる。これにより、物理視点で、正確なログ情報(業務稼働ログ)を把握することができる。
【0039】
この際、取得による物理量が閾値を跨いだ物理サーバ102に対して、別の物理サーバ、別のシャーシ(ブレードサーバの場合)、別のラック、別のブレーカ、別のフロア、別のセンタへの移動計画を立案することが可能になる。
【0040】
また、ログ情報に識別子をマーキング(記録)するに際しては、障害、例えば、ハードウェア障害、ソフトウェア障害、性能障害の発生を契機としてマーキングしたり、障害予兆や性能障害予兆でマーキングしたりすることで、以下のようなメリットが生じる。
【0041】
具体的には、ハードウェア障害を契機として、ソフトウェア情報(識別子など)をハードウェアログにマーキングすると、その時点で稼働していたソフトウェアを記録することで、どのソフトウェアをリカバリすれば良いかを判断することができる。
【0042】
ソフトウェア障害を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、物理的な計算機資源が枯渇していたことが原因なのか判定出来る。
【0043】
ソフトウェア障害を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、仮想サーバを利用する環境で、障害がユーザプログラム起因で発生したものか否かを特定出来る。これにより、ユーザが起こした障害の場合は、ユーザに課金するが、計算機環境側が障害を起こした障害の場合は、ユーザに課金しない、といった厳密な運用が可能となる。すなわち、リスクの適正な分散が可能となる。
【0044】
性能障害を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。
【0045】
性能障害を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務(ソフトウェア資源)がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。
【0046】
障害予兆を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、ソフトウェアログ゛を監視することで、障害によるシステムダウンが発生する前に、別のサーバへ移動する、といった対策を講じることが可能になる。温度が異常であれば、その周辺の温度が高くなっていると判断し、別のラックやフロアへ移動したり、周辺の温度を取得して移動先を決めたりする、といった対策を講じることが可能になる。
【0047】
障害予兆を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、業務の優先順位や移動のし易さなどから、退避の優先順位付けを行い、優先順位の高い業務をより高確率に継続させるよう対策を講じることが可能になる。
【0048】
性能障害予兆を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。
【0049】
性能障害予兆を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。
【0050】
図6は、BMC305の異なる実現形態を示す。このBMC305は、ログ制御機能601を有する他は、図4のものと同様である。ログ制御機能601は、データ格納領域404へ格納されているログ(ログ情報)へマーキングする機能を持つ。なお、ログ制御機能601に、データ格納領域404からログを収集し、収集したログにマーキングした後、ログ制御機能601内にデータを格納するか、あるいは収集したログを管理サーバ101へ送信する機能を付加することもできる。
【0051】
図6におけるBMC305は、図4に示すBMC305にハードウェアを追加することで実現できる形態であって、過去資産の流用が可能なため、安価に実現することが出来る。また、法規制などの要請により、ログに追記しない形態で保存する必要があって、BMC305から、追加されたハードウェアを外す場合には、データ格納領域404へ元のログは残す実現方式が可能となる。
【0052】
図7は、物理サーバ102の異なる実現形態を示す。ログ制御機能701は、BMC305へ格納されているログへマーキングする機能を持つ。なお、ログ制御機能701に、BMC305からログを収集し、収集したログに、マーキングした後、ログ制御機能701内にデータを格納するか、あるいは、収集したログを管理サーバ101へ送信する機能を付加することもできる。
【0053】
図7における物理サーバ102は、図6におけるBMC305の実現形態と同様、過去資産を流用することで安価に実現できる。また、ログ制御機能701と同等の機能が管理サーバ101にて実現されていても、同様の効果を得ることが出来る。
【0054】
図8は、複数の物理サーバ102の代わりに、物理サーバと略同一の機能を有する複数のブレードサーバ802を用い、各ブレードサーバ802をサービスプロセッサ801に接続したときの計算機システムの構成図を示す。
【0055】
管理サーバ101は、NW-SW(管理用ネットワーク)103を介して、シャーシ803のサービスプロセッサ801及び各ブレードサーバ802と接続されている。サービスプロセッサ801は、内部ネットワークを介してブレードサーバ802と接続されている。管理サーバ101は、NW-SW103の管理インタフェース(管理I/F)113、NW-SW(業務用ネットワーク)104の管理インタフェース114へ接続されており、管理サーバ101から各NW-SWのVLAN(Virtual LAN)を設定することが可能である。
【0056】
サービスプロセッサ801は、ブレードサーバ802のシャーシ803への挿抜(ブレードサーバ802の追加、削除)やブレードサーバ802の障害を検知し、管理サーバ101へアラートを通知する。
【0057】
NW-SW103は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といったブレードサーバ103の運用管理をするために必要なネットワークである。NW-SW104は、業務用のネットワークに属しており、ブレードサーバ802上で実行される業務用アプリケーションが使用するネットワークである。
【0058】
図9は、サービスプロセッサ801の構成を示す。図9において、サービスプロセッサ801は、演算を処理するCPU901、CPU901で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ902、プログラムやデータを格納するストレージ装置とのディスクインタフェース904、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース903、ログを制御する機能を持つログ制御機能905を有する。
【0059】
ただし、ログ制御機能905は、ブレードサーバ802内やブレードサーバ802のBMC1005(図10参照)内や管理サーバ101にて実現されている場合は、必ずしも必要とはしない。
【0060】
図10は、ブレードサーバ802の構成を示す。図10において、ブレードサーバ802は、演算を処理するCPU1001、CPU1001で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ1002、プログラムやデータを格納するストレージ装置とのディスクインタフェース1004、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース1003、電源制御や各インタフェースの制御を行うBMC(Baseboard Management Controller)1005を有する。
【0061】
ブレードサーバ802は、メモリ1002上のOS311がCPU1001によって実行されることで、ブレードサーバ802内のデバイス管理を行っている。OS311の下で、業務を提供する業務アプリケーション321や監視プログラム322などが動作する。BMC1005は、サービスプロセッサ801と内部ネットワークを介して接続されており、稼働情報や障害情報を通知する機能や、電源制御の指示を受け付け実行する機能を持つ。また、本実施例におけるブレードサーバ802は、ログの取得・ログの送信・ログへのマーキングを実行する機能を持つ。
【0062】
図11は、物理サーバ管理テーブル221を示す。図11において、物理サーバ102やブレードサーバ802を管理するための物理サーバ管理テーブル221のカラム1101には、物理サーバ識別子が格納しており、本識別子によって各物理サーバを一意に識別することができる。カラム1101へ格納するデータは、本テーブル221で使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。
【0063】
カラム1102には、UUID(Universal Unique IDentifier)が格納されている。UUIDは、重複しないように形式が規定された識別子である。そのため、各サーバ102または802に対応して、UUIDを保持することにより、確実なユニーク性を保証する識別子となり得る。そのため、カラム1101に格納されている識別子は、サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。
【0064】
ただし、カラム1101には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1101のサーバ識別子には、MACアドレス、WWN(World Wide Name)などを用いても良い。
【0065】
カラム1103(カラム1171〜カラム1172)には、I/Oデバイスに関する情報が格納されている。カラム1171には、デバイス種別が格納されている。例えば、HBA(Host Bus Adaptor)やNIC(Network Interface Card)などが格納される。カラム1172には、HBAの識別子であるWWN(World Wide Name)、NICの識別子であるMAC(Media Access Control)アドレスが格納されている。
【0066】
カラム1104には、物理サーバ102のモデルが格納されている。このモデルは、インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。
【0067】
カラム1105には、物理サーバ102の構成に関する構成情報が格納されている。例えば、物理サーバ102の構成に関する構成情報として、プロセッサ(CPU301、CPU1001)のアーキテクチャ、シャーシ803やスロットなどの物理位置情報、特徴機能(ブレード間SMP:Symmetric Multiprocessing、HA(High Availability)構成などの有無)が格納されている。カラム1104も同様、インフラに関わる情報である。
【0068】
カラム1106には、物理サーバ102の性能情報が格納されている。カラム1104も同様、インフラに関わる情報である。
【0069】
カラム1107には、ログ情報が格納されている。このカラム1107には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0070】
カラム1108には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1107とカラム1108から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0071】
インフラに関わる情報は、物理サーバ102の移動先を提案する場合に、移動が可能か否かを判定するために必要である。
【0072】
図12は、仮想化機構管理テーブル222を示している。仮想化機構管理テーブル222は、どのような仮想化機構で、どんなログがどこに格納されていて、どのようにすればアクセス可能か、といった情報を管理するものである。
【0073】
カラム1201には、仮想化機構識別子が格納されており、本識別子によって各仮想化機構を一意に識別することができる。カラム1201へ格納するデータは、本テーブルで使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで、入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。
【0074】
カラム1202にはUUIDが格納されている。UUIDは、仮想化機構識別子として、有力な候補である。
【0075】
カラム1203には、仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。
【0076】
カラム1204には、仮想化機構設定情報が格納されている。仮想化機構設定情報は、仮想化機構へ接続するために必要なIPアドレスなどである。
【0077】
カラム1205にはログ情報が格納されている。カラム1205には、どのような情報をログとして保持し、どこへ保持されているか、が格納される。
【0078】
カラム1206には、ログ情報操作インタフェースが格納されている。ログを操作するときに接続するプログラムやインタフェースに関する情報が格納されている。
【0079】
カラム1205とカラム1206から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0080】
図13は、仮想サーバ管理テーブル223を示している。仮想サーバ管理テーブル223は、どのようなシステム構成を定義した仮想サーバで、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。
【0081】
カラム1301には、仮想サーバ識別子が格納されており、本識別子によって各仮想サーバを一意に識別することができる。
【0082】
カラム1302には、UUIDが格納されている。カラム1301に格納されている仮想サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1301には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。
【0083】
例えば、カラム1301の仮想サーバ識別子には、仮想MACアドレス、仮想WWNなど(カラム1372へ格納)を用いても良い。また、OS311によっては、独自にユニーク性を保つための識別子を採用している場合があるが、この場合は、OS311が採用しているIDを使っても良いし、ユニーク性を確保するために独自に保持してもかまわない。
【0084】
カラム1303(カラム1371〜カラム1373)には、仮想I/Oデバイスに関する情報が格納されている。カラム1371には、仮想デバイス種別が格納されている。例えば、仮想HBAや仮想NICなどが格納される。カラム1372には、仮想HBAの識別子である仮想WWN、仮想NICの識別子である仮想MACアドレスが格納されている。カラム1373には、仮想I/Oデバイスのモードが格納されており、このモードには、共有モードと占有モードがある。
【0085】
仮想デバイスには、使用する物理デバイスを共有で使用するモードと、占有で使用するモードが存在する。共有の場合、他の仮想デバイスが物理デバイスを同時に使用する。占有モードの場合、物理デバイスをその仮想デバイスが単独で使用する。
【0086】
カラム1304には、仮想サーバの仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。
【0087】
カラム1305には、仮想サーバの性能情報が格納されている。カラム1304も同様、インフラに関わる情報である。
【0088】
カラム1306には、ログ情報が格納されている。カラム1306には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0089】
カラム1307には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1306とカラム1307から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0090】
インフラに関わる情報は、物理サーバ102の移動先を提案する場合に、移動が可能か否かを判定するために必要である。
【0091】
図14は、OS管理テーブル224を示している。OS管理テーブル224は、どのようなOS311で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのデーブルである。
【0092】
カラム1401には、OS識別子が格納されており、本識別子によってOSを一意に識別することができる。
【0093】
カラム1402には、UUIDが格納されている。カラム1401に格納されているOS識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1401には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1401のOS識別子には、OS設定情報(カラム1404へ格納)を用いても良い。
【0094】
カラム1403は、OS設定情報が格納されている。例えば、IPアドレスやホスト名、ID、パスワード、ディスクイメージなどが格納されている。ディスクイメージは、設定前後のOSが物理サーバ102または仮想サーバ2302へ配信されたシステムディスクのディスクイメージを指す。カラム1404へ格納するディスクイメージに関する情報は、データディスクを含めても良い。
【0095】
カラム1405には、ログ情報が格納されている。カラム1405には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0096】
カラム1406には、ログ情報を操作するインタフェースに関する情報が格納している。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1405とカラム1406から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0097】
図15は、業務管理テーブル225を示している。業務管理テーブル225は、どのようなソフトウェア資源(例えば、業務アプリケーション321)で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。
【0098】
カラム1501には、業務識別子が格納されており、本識別子によって業務、例えば、業務アプリケーション321を一意に識別することができる。
【0099】
カラム1502には、UUIDが格納されている。カラム1501に格納されている業務識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1501には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1501のサーバ識別子には、業務設定情報(カラム1504へ格納)を用いても良い。
【0100】
カラム1503には、業務種別が格納されており、使用するアプリケーションやミドルウェアといった業務を特定するソフトウェアに関する情報が格納されている。業務で使用する論理的なIPアドレスやID、パスワード、ディスクイメージ、業務で使用するポート番号などが格納されている。ディスクイメージは、設定前後の業務が物理サーバ102または仮想サーバ2302上のOS311へ配信されたシステムディスクのディスクイメージを指す。カラム1504へ格納するディスクイメージに関する情報は、データディスクを含めても良い。
【0101】
カラム1505には、ログ情報が格納されている。カラム1505には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0102】
カラム1506には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1505とカラム1506から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0103】
図16は、システム管理テーブル226を示している。システム管理テーブル226は、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224及び業務管理テーブル225で管理される、物理サーバ102、仮想化機構2301、仮想サーバ2302、OS331及び業務321の組み合わせによるシステム構成を管理し、システム変更やサーバ移動のステータス及びログ制御を管理するためのテーブルである。
【0104】
カラム1601には、システム識別子が格納しており、本識別子によって業務、例えば、業務アプリケーション321を一意に識別することができる。
【0105】
カラム1602には、UUIDが格納されている。カラム1603からカラム1605の全部または一部の組み合わせで実現しても良いし、独自に生成しても良い。少なくとも、管理サーバ101が管理する範囲で一意である必要がある。
【0106】
カラム1603には、物理サーバ識別子1101が格納され、カラム1604には、仮想化機構識別子1201が格納され、カラム1605には、仮想サーバ識別子1301が格納され、カラム1606には、OS識別子1401が格納され、カラム1607には、業務識別子1501が格納されている。
【0107】
図面には記載していないが、ラックやフロア、コンセントボックス、ブレーカ、センタ、HA構成の有無、ネットワークインフラ情報、電力グリッド、ネットワーク結線関係、ネットワークスイッチ、ファイバチャネルスイッチ、各スイッチの収容量、ネットワーク帯域などを管理することで、それらにまたがったシステムの移動についても本発明の効果を得ることが可能になる。
【0108】
カラム1608には、システム変更ステータスが格納されている。カラム1608には、なにをどこへ移動するのか、移動前・移動中・移動後、といったステータスが格納される。
【0109】
カラム1609には、ログ取得ステータスが格納されている。ログ取得ステータスは、ログ取得を要請する対象でのログ取得が完了しているかどうかを管理するためのものである。
【0110】
カラム1610には、マーキングステータスが格納されている。マーキングステータスは、ログへマーキングを要請する対象へマーキングが完了しているかどうかを管理するためのものである。マーキングステータスは、本発明における重要ポイントである。
【0111】
カラム1611には、ログ収集ステータスが格納されている。ログ収集ステータスは、対象からログを収集する場合に、ログ収集が完了しているかどうかを管理するためのものである。管理サーバ101内やBMC305の内外デバイス、サービスプロセッサ801内へログを収集する際に、ステータスを管理する必要がある。
【0112】
図17は、契機管理テーブル227を示している。契機管理テーブル227のカラム1701には、契機識別子が格納されている。カラム1702には、契機の内容が格納されている。カラム1702には、管理サーバ101へサーバ移動などの動作が入力される場合もあるが、契機を検出して自動実行するときの動作が入力される場合もある。
【0113】
後者の場合、動作に伴うイベント通知が契機となる。契機としては、以下に挙げるような動作が考えられるが、システム管理テーブル226のシステム構成に関するカラムが変更される場合は、全て契機と成り得る。
【0114】
仮想サーバをライブマイグレーションする場合、仮想サーバ2302以上(仮想サーバ2302、OS321、業務321、図23参照)は、稼働する物理サーバ102を移動(変更)することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
【0115】
LU(Logical Unit)を接続する物理サーバ102が変更となる場合、OS321と業務321は稼働する物理サーバ102を移動(変更)することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
【0116】
また、LUを接続する仮想サーバ2302が変更となる場合、仮想化機構2301または仮想サーバ2302以上(OS321、業務321を含む)が移動することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。
【0117】
別の業務のディスクイメージをデプロイ(配信、デプロイメント)する場合、LUを接続するサーバを変更する場合と同様である。
【0118】
インタフェースカードの固有値(WWNやMACアドレス)を書き換える場合、LUを接続する物理サーバ102を変更する場合と同様である。
【0119】
Java(登録商標)アプリケーションをデプロイする場合、業務321内のプロセス(論理サーバ)が追加・削除・変更されるため、業務321およびプロセスの識別子を物理サーバ102の稼働情報ログへマーキングする。
【0120】
業務ソフトウェアのIPアドレスを変更する場合、稼働する物理サーバ102または仮想サーバ2302を移動(変更)するように見なすことが出来る。
【0121】
この場合も、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。
【0122】
ソフトウェア起動通知、OS起動通知、仮想サーバ起動通知、仮想化機構起動通知で、稼働しているシステム情報を取得し、システム管理テーブル226との差異を調査し、差異がある場合、物理サーバ102の移動(変更)が発生している。物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
【0123】
この際、管理サーバ101は、例えば、ソフトウェア資源がある物理サーバ102から、他の物理サーバ102に移動する場合、他の物理サーバ102が起動したことを条件に、他の物理サーバ102に属するソフトウェア資源と他の物理サーバ102の構成を示すハードウェア構成情報との間に差異があるか否かを判定し、差異があるときには、その旨の情報を、識別子とともに、他の物理サーバ102のログ情報に記録することで、記録された情報を基に正しい構成に修正したり、あるいは、マーキングに失敗したことを把握したりすることができる。
【0124】
また、上記に挙げる契機で、物理サーバ102の識別子を物理サーバ102以外の稼働ログへマーキングしても良い。これにより、論理的な稼働情報(業務321、OS311、仮想サーバ2302、仮想化機構2301)を記録したログから、正確かつ簡単に物理サーバの稼働情報を参照することが可能である。記録先のログは全てでも良いし、一部でも良い。
【0125】
監視対象の物理量(例えば消費電力量)が設定した閾値を跨ぐ場合、論理的な稼働情報を記録したログへ、物理サーバ識別子をマーキングする。また、測定した物理量を同時にマーキングしても良い。この契機と同様のものとして、ハードウェアやソフトウェアの障害情報の通知、性能障害情報の通知、警告(障害予兆、性能障害含む)の通知などが挙げられる。
【0126】
図18は、マーキング規則管理テーブル228を示している。マーキング規則管理テーブル228は、どんな契機で、どのログに、なんの識別子をマーキングするか、を管理するためのテーブルである。
【0127】
カラム1801には、規則識別子が格納され、カラム1802には、契約識別子(カラム1701)が格納され、カラム1803には、マーキングする対象の階層が格納され、カラム1804には、マーキングする対象となるログまたはログ種別が格納され、カラム1805には、マーキングする識別子が格納される。
【0128】
マーキングの方法としては、ログ内の最新情報部にマーキングする識別子を追記する方法を用いることができる。また、マーキングの開始と終了のみを追記しても良いし(システムが変更されたときのみマーキング)、その後のログ全てにマーキングしても良い。
【0129】
図19は、課金情報管理テーブル229を示している。課金情報管理テーブル229は、課金に関する情報を管理するテーブルであり、運用コストが下がるシステム構成を提案するために使用される。
【0130】
課金情報管理テーブル229のカラム1901には、課金情報識別子が格納され、カラム1902には、課金対象が格納されている。格納される情報は、消費電力量のような物理量でも良いし、仮想サーバや物理サーバ102といったインフラ情報、トランザクション保証のレベルといったSLA(Service Level Agreement)情報でも良い。
【0131】
カラム1903には、課金情報が有効となる条件が格納されている。時刻やシステム構成、インフラ情報(HA構成の有無や種類、ネットワーク帯域、地域など)である。カラム1904には、単価が格納されている。
【0132】
課金情報管理テーブル229を利用するに際して、物理稼動情報を記録したログを参照し、温度の高いサーバといったIT機器および負荷のかかったファシリティを検出した場合、課金情報管理テーブル229の条件や単価を操作し、一時的に価格を上げ、需要を抑えるような価格操作によって、より効率の良い運用(例えば、該当サーバの需要は下がり、利用率が下がることで温度を下げる効果がある)を管理者に提供することが出来る。
【0133】
また、計算機資源を利用するユーザにとってみれば、温度が高いサーバを使うことは、温度上昇によるハードウェア障害のリスクが高いことになるが、価格の安い計算機資源を選ぶことで、同時に温度によるハードウェア障害のリスクを回避することも可能となる。
【0134】
図20は、契機監視部210の処理フローチャートを示す。
【0135】
契機監視部210は、管理サーバ101のCPU201によって処理を開始する。契機監視部210は、契機の発生を監視し、発生した契機についてログへマーキングするか否かを判定し、ログへマーキングする場合は、ログを取得およびマーキングを指示、またはログを収集およびマーキングする指示する。
【0136】
まず、ステップ2001で、管理サーバ101は契機の発生を監視し、契機が発生した場合、ステップ2002へ進む。
【0137】
ステップ2002で、管理サーバ101は、契機を基に契機管理テーブル227を参照する。
【0138】
ステップ2003で、管理サーバ101は、契機管理テーブル227を参照した結果を基に、ログへマーキングするか否かを判定し、マーキングする場合、ステップ2004へ進み、マーキングしない場合、ステップ2001へ進む。
【0139】
ステップ2004で、管理サーバ101は、システム管理テーブル226を参照し、マーキングする旨、システム管理テーブル226を変更し、処理を完了する。
【0140】
契機としては、ユーザ操作によるもの(GUI操作、CLI発行など)、イベント発生によるもの(ハードウェア障害情報の書き込み及び通知など)、アラート通知によるもの(閾値越え、障害通知など)がある。
【0141】
図21は、ログ取得指示部211の処理フローチャートを示す。
【0142】
ログ取得指示部211は、管理サーバ101のCPU201によって処理を開始する。この処理へ移行する前提として、契機監視部210が「ログへマーキングする」と判断し、契機を契機監視部210から受け取っていることが挙げられる。また、元々のログを取得する契機と時間的に近い場合、ログ取得指示部211は、ログ取得を指示しなくても良い。
【0143】
まず、ステップ2101で、ログ取得指示部211は、契機管理テーブル227を参照する。
【0144】
ステップ2102で、ログ取得指示部211は、契機管理テーブル227を参照した結果を基に、システム管理テーブル226を参照し、次に挙げる、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225のうち、全てのテーブルまたは契機やログのマーキングに関連するテーブルのみを参照する。
【0145】
次に、ステップ2103において、ログ取得指示部211は、ステップ2102で参照したテーブルの内容を基に管理対象へログ取得を指示する。
【0146】
この後、ログ取得指示部211は、ステップ2104において、システム管理テーブル226を更新し、処理を完了する。
【0147】
図22は、マーキング指示部212の処理フローチャートを示す。
【0148】
マーキング指示部212は、管理サーバ101のCPU201によって処理を開始する。この処理へ移行する前提として、マーキング対象のログと追記する識別子は確定していることとしている。
【0149】
まず、ステップ2201で、マーキング指示部212は、マーキング規則管理テーブル228を参照する。
【0150】
ステップ2202で、マーキング指示部212は、マーキング規則管理テーブル228を参照した結果を基に、マーキング対象のログ情報を保持するテーブルを参照する。参照するテーブルは、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225のうち、全てでも良いし、マーキング対象となるもののみでも良い。
【0151】
ステップ2203で、マーキング指示部212は、マーキング対象ログへ識別子を追記する。
【0152】
ステップ2204で、マーキング指示部212は、マーキング対象ログへ識別子を追記した内容を基にシステム管理テーブル226を更新する。
【0153】
本実施例においては、ソフトウェア資源のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション321を他の物理サーバに移動させる変更が生じた場合、管理サーバ101は、複数の物理サーバ102の中から、変更元あるいは移動元となる物理サーバ102を抽出し、抽出した移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスを収集し、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、その後、移動先の物理サーバ(サーバB)102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動したことをログ情報として残すこととしている。
【0154】
従って、本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。
【実施例2】
【0155】
本実施例は、サーバ仮想化技術を利用するとともに、物理サーバとして、ブレードサーバ802を用いたものであり、他の構成は、実施例1と同様である。
【0156】
図23は、サーバ仮想化技術を適用した実施例2のシステム構成のうち、物理サーバ102の内部構成を示している。この際、物理サーバ102として、ブレードサーバ802を用いても、内部構成は同様である。
【0157】
ブレードサーバ802は、演算を処理するCPU301、CPU301で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ302、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース304、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース303、電源制御や各インタフェースの制御を行うBMC305から構成される。
【0158】
メモリ302には、計算機資源を仮想化するためのサーバ仮想化技術を提供する仮想化機構2301が配備され、仮想サーバ2302を提供する。また、仮想化機構2301は、制御用インタフェースとして仮想化機構管理用インタフェース2311を備えている。仮想化機構2301は、物理サーバ102(またはブレードサーバ802)の計算機資源を仮想化し、仮想サーバ2302を構成する。仮想サーバ2302は、仮想CPU2321、仮想メモリ2322、仮想ネットワークインタフェース2323、仮想ディスクインタフェース2324から構成されている。
【0159】
仮想メモリ2322には、OS331が配信され、仮想サーバ2302内の仮想デバイスを管理している。また、OS331上では、業務アプリケーション321が実行されている。OS331上で稼働する管理プログラム322によって、障害検知やOS電源制御、インベントリ管理などが提供されている。
【0160】
仮想化機構2301は、物理デバイスと論理デバイスの対応付けを管理しており、物理デバイスと論理デバイスとを対応付けたり、両者の対応付けを解除したりすることが出来る。
【0161】
また、メモリ302には、どの仮想サーバ2302が物理サーバ102(またはブレードサーバ802)の計算機資源を、どれくらい割り当てられ、また、使用しているかといった構成情報および稼働履歴が保持されている。この情報及び、例えば、物理サーバ102が保持する稼働ログ(例えば、消費電力ログ)に、本発明で実施する識別子がマーキングされたログを突き合わせることで、正確にどの仮想サーバ2302がどれだけの電力消費に関わっていたかを導くことが可能である。
【0162】
これにより、精度の高い課金や電力消費の特に高いまたは低い仮想サーバ2302を特定することが可能になる。
【0163】
本発明の実施に関わる制御部110及び管理テーブル群111の構成は実施例1と同様である。
【0164】
本実施例では、ソフトウェア資源として、仮想化機構2301上に仮想サーバ2302が構築され、仮想サーバ2302上にOS331が構築され、OS331上に業務アプリケーション321が構築される構成となっている。
【0165】
このため、仮想化機構2301が他の物理サーバ102に移動するときには、仮想化機構2301とともに、OS331及び業務アプリケーション321が他の物理サーバ102に移動し、仮想サーバ2302が他の物理サーバ102に移動するときには、仮想サーバ2302とともに、OS331及び業務アプリケーション321が他の物理サーバ102に移動し、OS331が他の物理サーバ102に移動するときには、OS331とともに、業務アプリケーション321が他の物理サーバ102に移動し、業務アプリケーション321が他の物理サーバ102に移動するときには、業務アプリケーション321のみが他の物理サーバ102に移動することになる。
【0166】
この際、管理サーバ101は、例えば、業務アプリケーション321の移動を契機として、移動対象となる業務アプリケーション321を稼働している物理サーバ102を変更元あるいは移動元の物理サーバ102とし、移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集する。
【0167】
次に、管理サーバ101は、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、この後、契機に伴う制御を移動元の物理サーバ102と移動先の物理サーバ102へ指示する。これにより、移動元の物理サーバ102で稼働していた業務アプリケーション321が移動先の物理サーバ102へ移動する。
【0168】
その後、管理サーバ101は、業務アプリケーション321を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ102へ移動したことをログ情報として残す。
【0169】
これにより、業務アプリケーション321で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。
【0170】
ソフトウェア資源として、業務アプリケーション321、OS331、仮想サーバ2302、仮想化機構2301を用い、これらのいずれかをソフトウェア資源の変更の対象として、ログ情報を記録すると、以下のようなメリットが生じる。
【0171】
ソフトウェア資源の変更の対象として、業務アプリケーション321を用いた場合、業務アプリケーショ321ンごとに、物理的な計算機資源の利用状況を知ることが可能となる。これにより、業務アプリケーション321を追加するときに、同じOS(仮想サーバ)331上に同居させるべきか、別のOS(仮想サーバ)331上に置くべきかを判断することが可能になる。
【0172】
また、変更の対象となる業務アプリケーション321が稼働している物理サーバ102とは別の物理サーバ102へ負荷を分散させたり、更に高スペックな物理サーバへ移動させたりするべきか、といった判断が可能となる。
【0173】
また、一つの業務を提供するソフトウェアが、性能や価格によって幾つか選択可能な場合に、状況に応じて選択可能となる。
【0174】
ソフトウェア資源の変更の対象として、OS331を用いた場合、OS331ごとに、物理的な計算機資源の利用状況を知ることが可能となる。すなわち、IPアドレスやホスト名、稼動する業務の設定を引き継ぐことで、あたかもOS331が移動したかのように見ることが出来る。これにより、OS331は、性能の異なるハードウェア間を容易に移動出来るのだが、この移動をすべきか否かの判断が可能となる。
【0175】
またディスクイメージをデプロイすることで、移動することも可能であるが、時間がかかるが設定変更に比べて、操作の手間やミス発生の確率が低いというメリットがある。この際、どちらが利用者によって有益化を判定することが可能になる。
【0176】
ソフトウェア資源の変更の対象として、仮想サーバ2302を用いた場合、仮想サーバ2302毎に、物理的な計算機資源の利用状況を知ることが可能となる。これにより、仮想サーバ2302ごと移動させるか、OS331より上位を移動させるか、業務アプリケーション321のみを移動させるかを判断することが可能になる。仮想サーバ2302を動的に移動させた場合と一旦停止させて移動させた場合では、移動にかかる時間が異なる。このような場合にでも、正確に稼動情報を知ることが可能になり、正しい課金を実施することが出来る。
【0177】
ソフトウェア資源の変更の対象として、仮想化機構2301を用いた場合、仮想化機構2301の、物理的な計算機資源の利用状況を知ることが可能となる。異なる仮想化機構(価格、性能といった特徴が異なる)を使い分けることが可能となる。
【0178】
本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。
【実施例3】
【0179】
本実施例は、ログ収集部213が稼働するか否かを判定する他は、実施例1および実施例2と同様である。すなわち、本実施例は、古いシステムやログへの接続が独自インタフェースといった仕様、また独立性の保持という観点(他からログを改ざんされないこと、ログが暗号化されている場合など)が原因で、ログを直接編集出来ない場合が存在することを考慮したものである。ログを直接編集出来ない場合、ログ収集インタフェースを介してログを別のサーバ(例えば管理サーバ101)やサービスプロセッサ801へ収集し、収集したログにマーキングを施す、といったことが必要である。そのため、ログ収集部213が必要となる。
【0180】
図24は、ログ収集部213の処理フローチャートを示す。
【0181】
ログ収集部213は、管理サーバ101のCPU201によって処理を開始する。まず、ステップ2401で、ログ収集部213は、マーキング管理テーブル228を参照する。
【0182】
ステップ2402で、ログ収集部213は、マーキング管理テーブル228を参照した結果を基に、マーキング対象のログ情報を保持するテーブルとして、以下のテーブル、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225を参照する。
【0183】
ステップ2403で、ログ収集部213は、各テーブルの参照結果を基に、ログを他のサーバ(管理サーバ101、サービスプロセッサ801など)へ収集するか判定し、収集する場合はステップ2404へ進み、しない場合は処理を完了する。
【0184】
ステップ2404で、ログ収集部213は、管理対象へログ提供を指示し、ログを収集する。
【0185】
この後、ステップ2405で、ログ収集部213は、システム管理テーブル226を更新して、処理を完了する。
【0186】
本実施例によれば、古いシステムやログへの接続が独自インタフェースといった仕様、また独立性の保持という観点が原因で、ログを直接編集出来ない場合でも、ログ収集インタフェースを介してログを管理サーバ101やサービスプロセッサ801へ収集させることができる。
【実施例4】
【0187】
実施例4では、実施例1、実施例2及び実施例3で記載した構成を用いるとともに、業務や物理サーバ102の計算機利用に関する傾向分析を実施する。この際、業務視点、物理サーバ視点、仮想サーバ視点といった各階層において、観測する物理量、動作しているソフトウェアや仮想サーバの量や種類、といった可観測なものの傾向を分析することで、利用者や管理ソフトウェアへ分析結果を通知したり、またはアラートを上げたりすることができる。
【0188】
また、この結果を基にシステム構成提案を実施することで、より効率的な計算機資源の利用を利用者へ提供する。例えば、予算内で一番性能の良い構成や、同じく一番可用性の高い構成、またはその組み合わせなどである。
【0189】
図25は、傾向分析部214の処理フローチャートを示す。
【0190】
傾向分析部214は、管理サーバ101のCPU201によって処理を開始する。まず、傾向分析部214は、ステップ2501で、「分析する視点」と「分析する対象」に関する入力を受け付ける。これは、利用者が契機を与える場合である。または、ハードウェアやソフトウェアの障害通知または性能障害通知を契機としても良い。
【0191】
これにより、現在の構成では業務の稼働や予算内運用に支障をきたす場合に、利用者は原因の分析結果や回避策となるシステム構成を容易に迅速に把握することが可能となり、対策も容易に迅速に行うことが出来る。
【0192】
次に、傾向分析部214は、ステップ2502で、視点を判定する。
【0193】
ステップ2503で、傾向分析部214は、システム管理テーブル226を参照する。
【0194】
ステップ2504で、傾向分析部214は、システム管理テーブル226を参照した結果を基に、稼働情報を保持するテーブルとして、以下のテーブル、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225を参照する。
【0195】
ステップ2505で、傾向分析部214は、各テーブルを参照した結果を基に、分析する対象のログの中で、分析する視点のマーキングに相当する箇所を抽出する。
【0196】
ステップ2506で、傾向分析部214は、分析結果を出力し、処理を完了する。
【0197】
本実施例によれば、現在の構成では業務の稼働や予算内運用に支障をきたす場合に、利用者は、原因の分析結果や回避策となるシステム構成を容易に迅速に把握することが可能となり、対策も容易に迅速に行うことが出来る。
【0198】
図26は、システム構成提案部215の処理フローチャートを示す。
【0199】
電力使用量を最低にするシステム構成を提案、スペース使用量を最低にするシステム構成を提案、昼夜で使用量または料金が異なる場合に、予算の範囲内で性能または可用性が高いシステムを提案、といったことが可能になる。
【0200】
例えば、高性能で高可用なシステムが低価格で入手出来れば良いが、現実は高付加価値なシステムほど高価格になる。また利用者の予算は上限が存在し、折り合いをつける必要がある。
【0201】
使用制限の例としては、予算、消費電力量の上限、CPU使用量の上限および下限(〜%以上で使用したい)、メモリ使用量の上限、ネットワーク帯域使用量の上限、ネットワークインフラ(〜Gbps以上)、業務アプリケーション321のスループット上限および下限、計算機資源の占有利用または共有利用、HA構成の有無や種類など、である。
【0202】
システム構成提案部215は、管理サーバ101のCPU201によって処理を開始する。まず、システム構成提案部215は、ステップ2601で、「最小または最大にする物理量」(評価基準となる物理量)に関する入力及び「前提条件」(制限値)の入力を受け付ける。
【0203】
ステップ2602で、システム構成提案部215は、課金情報管理テーブル229、システム管理テーブル226を参照する。
【0204】
ステップ2603で、システム構成提案部215は、テーブルの参照結果を基に、前提条件内に収まる範囲でシステム構成を変化させる。
【0205】
ステップ2604で、システム構成提案部215は、評価基準となる物理量が最小または最大であるか判定する。このとき、最小か最大かはなにを満足する条件として設定するかによって変わる。どちらでも良い訳ではない。システム構成提案部215は、最小または最大となる場合はステップ2605へ進み、そうでない場合はステップ2606へ進む。
【0206】
ステップ2605で、システム構成提案部215は、システム構成と目論見の物理量を保存する。この値をステップ2604で使用する。
【0207】
ステップ2606で、システム構成提案部215は、全試行を完了したかを判定し、完了した場合はステップ2607へ進み、完了していない場合はステップ2603へ進む。
【0208】
ステップ2607で、システム構成提案部215は、保存したシステム構成と目論見の物理量を出力し、処理を完了する。
【0209】
システム構成提案部215は、出力した結果を管理サーバ101へアラート通知し、管理サーバ101が構成変更の指示を出すことで、管理者が不在の場合も問題を解決することが可能になる。または、自動実行せず、利用者の判断を仰いだ上で、承認後に構成変更が実行されるようになっていても良い。
【0210】
本実施例によれば、電力使用量を最低にするシステム構成、スペース使用量を最低にするシステム構成あるいは昼夜で使用量または料金が異なる場合に、予算の範囲内で性能または可用性が高いシステム構成を提案することができる。
【0211】
また、各実施例においては、ログ情報に識別子を記録する代わりに、UUIDを生成し、生成したUUIDをログ情報に記録することもできる。この際、UUIDの生成や記録は、マーキングする主体が行っても良いし、管理サーバ101やBMC305、サービスプロセッサ801が行っても良い。
【0212】
また、各実施例においては、ログ情報に識別子を記録するに際して、移動に関連する物理サーバ102の時刻または管理サーバ101の時刻を取得し、取得した時刻をログ情報に記録することで、ログ情報を時刻に関連づけて把握することができる。この際、問い合わせの時刻を用いるときよりも、マーキングの時刻やログに記録された時刻を用いることで、より正確な照合が可能になる。
【0213】
また、各実施例においては、ログ情報に識別子を記録するに際して、ソフトウェア資源の移動の履歴を示す識別子をログ情報に追加でマーキングすることで、より正確な照合が可能になる。例えば、最近(例えば、ユーザ設定もしくは10分以内などをデフォルト設定)、同じ物理サーバ102間でソフトウェア資源の移動が発生した場合、ソフトウェア資源の移動の履歴を示す識別子を参照することで、2回目以降のソフトウェア資源の移動を正確に把握することができる。
【0214】
さらに、各実施例においては、管理サーバ101が動作の主体であったが、物理サーバ102やブレードサーバ802、サービスプロセッサ801、仮想化機構2301、仮想サーバ2302が動作の主体となり、制御部及び管理テーブル群を保持していても発明の効果を得ることが出来る。
【符号の説明】
【0215】
101:管理サーバ、102:物理サーバ、321:業務、501:契機を検出、502:識別子を収集、503:移動元のログへ識別子をマーキング、504:契機に伴う制御を指示、503:移動先のログへ識別子をマーキング。
【技術分野】
【0001】
本発明は、ソフトウェアが複数の物理サーバ上で稼働する際の性能、障害、システム構成といった稼働に関する情報を記録したログの内容を正確に突き合わせることを可能とする技術に関する。
【背景技術】
【0002】
近年、ブレードサーバ市場や仮想サーバ市場の伸長に伴い、業務、例えば、業務アプリケーションを別のサーバへ移動させて稼働させたり、稼働中の仮想サーバを別の物理サーバで稼働する仮想化機構上へ移動させたりすることで、業務を性能の異なる別の物理サーバへ移動させたりすることが可能になってきている。
【0003】
この際、仮想サーバを別の物理サーバへ移動させる毎に、管理サーバが、移行時刻、仮想サーバ識別子、移動元の物理サーバの識別子、および移行先の物理サーバの識別子を含む移動履歴を記録するようにしたものが提案されている(特許文献1参照)。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2007−323244号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記のように、業務を稼働させる物理サーバを移動することは公知技術を用いて実施することが可能である。この際、稼働情報であるログは、各階層(物理サーバ、仮想化機構、仮想サーバ、OS、業務アプリケーション)で別々に設定されているとともに、物理サーバとそれ以外のログは共通する識別子として、時刻が設定されている。すなわち、常に同じ物理サーバ上で業務が稼働している場合は、単一の物理サーバのログのみを参照すれば良いため、この唯一の手掛かりである時刻を基に、業務のログと物理サーバのログを突き合わせることが可能であった。
【0006】
一方、上記特許文献1に開示される技術は、複数の物理サーバで仮想サーバが移動するケースに着目し、仮想サーバが移動したときに、物理サーバのログへリンクを張るなどして、時刻を識別子とした情報の追跡を可能としている。
【0007】
しかし、一般的には、時刻は物理サーバ毎に異なる。このため、時刻を識別子としたのでは、時刻調整による弊害、例えば、同じアラートを複数回送信してしまう等が生じることがあり、時刻を識別子としている上記特許文献1では、仮想サーバが移動したときに、正確に業務と物理サーバのログを突き合わせることは出来ない。
【0008】
本発明は、前記従来技術の課題に鑑みて為されたものであり、その目的は、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができる計算機システムの稼働情報管理方法と計算機システムを提供することにある。
【課題を解決するための手段】
【0009】
前記目的を達成するために、本発明は、各物理サーバからそれぞれログ情報を収集し、前記収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、前記物理サーバのうち、前記閾値を跨いだログ情報の収集先となる物理サーバのログ情報に、前記閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または前記閾値を跨いだログ情報を記録し、その後、前記他の物理サーバのログ情報に、前記収集先となる物理サーバのログ情報に記録された前記識別子または前記閾値を跨いだログ情報を記録することを特徴とする。
【発明の効果】
【0010】
本発明によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができる。
【図面の簡単な説明】
【0011】
【図1】本発明の第1実施例を示すシステム構成図である。
【図2】管理サーバの構成を示す構成図である。
【図3】物理サーバの構成を示す構成図である。
【図4】BMCの構成を示す構成図である。
【図5】システム構築方法の動作概略を説明するための説明図である。
【図6】別のBMCの構成を示す構成図である。
【図7】別の物理サーバの構成を示す構成図である。
【図8】ブレードサーバのシステム構成を示すシステム構成図である。
【図9】サービスプロセッサの構成を示す構成図である。
【図10】ブレードサーバの構成を示す構成図である。
【図11】物理サーバ管理テーブルを示す構成図である。
【図12】仮想化機構管理テーブルを示す構成図である。
【図13】仮想サーバ管理テーブルを示す構成図である。
【図14】OS管理テーブルを示す構成図である。
【図15】業務管理テーブルを示す構成図である。
【図16】システム管理テーブルを示す構成図である。
【図17】契機管理テーブルを示す構成図である。
【図18】マーキング規則管理テーブルを示す構成図である。
【図19】課金情報管理テーブルを示す構成図である。
【図20】契機監視部の処理を説明するためのフローチャートである。
【図21】ログ取得指示部の処理を説明するためのフローチャートである。
【図22】マーキング指示部の処理を説明するためのフローチャートである。
【図23】仮想サーバの構成を示す構成図である。
【図24】ログ収集部の処理を説明するためのフローチャートである。
【図25】傾向分析部の処理を説明するためのフローチャートである。
【図26】システム構成提案部の処理を説明するためのフローチャートである。
【発明を実施するための形態】
【実施例1】
【0012】
本実施例は、ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバを管理サーバで管理するに際して、管理サーバは、ソフトウェア資源、例えば、業務アプリケーション、OS(Operating System)、仮想サーバ、仮想化機構のうちいずれかの変更を契機として、各物理サーバのうち、ソフトウェア資源の稼働の変更元となる物理サーバのログ情報に、変更元の物理サーバで稼働していたソフトウェア資源を特定する識別子を記憶し、その後、変更の完了を契機として、他の物理サーバのログ情報に前記識別子を記録するものである。
【0013】
図1は、実施例1における計算機システムの構成図を示す。図1において、計算機システムは、管理サーバ101と、複数の物理サーバ102を備え、管理サーバ101と各物理サーバ102は、NW-SW(Network−Switch:管理用ネットワーク)103とNW-SW104を介して接続されている。
【0014】
管理サーバ101は、NW-SW103の管理インタフェース(管理I/F)113、NW-SW(業務用ネットワーク)104の管理インタフェース114へ接続されており、管理サーバ101から各NW-SW103、104のVLAN(Virtual Local Area Network)を設定することが可能である。
【0015】
NW-SW103は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といった、各物理サーバ102の運用管理をするために必要なネットワークである。NW-SW104は、業務用のネットワークに属しており、各物理サーバ102上で実行される業務用アプリケーションが使用するネットワークである。
【0016】
管理サーバ101上では、制御部110による処理が実行され、制御部110の処理に伴って管理テーブル群111が参照および更新される。
【0017】
図2は、管理サーバ101の構成を示す。管理サーバ101は、演算を処理するCPU(Central Processing Unit)201、CPU201で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ202、プログラムやデータを格納するストレージ装置とのディスクインタフェース203、IP(Internet Protocol)ネットワークを介した通信のためのネットワークインタフェース204から構成される。
【0018】
図2では、ネットワークインタフェース204及びディスクインタフェース203を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、管理サーバ101は、例えば、管理用ネットワーク103と業務用ネットワーク104への接続は、各々異なるネットワークインタフェース204を用いることができる。
【0019】
メモリ202には、制御部110および管理テーブル群111が格納されている。制御部110は、契機監視部210(図20参照)、ログ取得指示部211(図21参照)、マーキング指示部212(図22参照)、ログ収集部213(図24参照)、傾向分析部214(図25参照)、及びシステム構成提案部215(図26参照)を有する。
【0020】
管理テーブル群111は、物理サーバ管理テーブル221(図11参照)、仮想化機構管理テーブル222(図12参照)、仮想サーバ管理テーブル223(図13参照)、OS管理テーブル224(図14参照)、業務管理テーブル225(図15参照)、システム管理テーブル226(図16参照)、契約管理テーブル227(図17参照)、マーキング規則管理テーブル228(図18参照)、及び課金情報管理テーブル229(図19参照)を有する。
【0021】
各テーブルへの情報収集は、標準インタフェースや情報収集用プログラムを使用した自動収集でも良いし、手動で利用者に入力させても良い。ただし、規則や方針といった情報のうち物理的要件や法律の要請で限界値が決定されるもの以外は、利用者に予め入力させる必要がある。この場合、入力用のインタフェースを備える必要がある。また、利用者の方針によって、限界値に至らない運用をする場合も、同様に条件を入力するインタフェースが必要である。
【0022】
図3は、物理サーバ102の構成を示す。物理サーバ102は、演算を処理するCPU301、CPU301で演算するプログラムや、プロググラムの実行に伴うデータを格納するメモリ302、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース304、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース303、CPU301に対する電源制御や各インタフェース303、304に対する制御を行うBMC(Baseboard Management Controller)305を有する。
【0023】
また、メモリ302には、ソフトウェア資源として、プログラム311と業務アプリケーション321およびOS311の他に、後述するように、仮想サーバと仮想化機構が格納されている。仮想化機構は、物理サーバ102のハードウェア資源であるCPU301などを仮想化したものである。仮想サーバは、仮想化機構で仮想化された仮想サーバである。OS311は、仮想サーバは、OS311上で動作し、仮想サーバは、仮想化機構上で動作する。
【0024】
この物理サーバ102においては、メモリ302上のOS311がCPU301によって実行され、OS311の下で、業務を提供するアプリケーション321や監視プログラム322などが動作する。この際、物理サーバ102は、アプリケーション321や監視プログラム322に従って、監視対象などから物理的な稼働情報であるログ情報として、例えば、消費電力を含む電力量などの電力情報、電圧情報、環境温度などの温度情報、電動ファンの回転数を含むファン情報などを収集する。
【0025】
図3では、ネットワークインタフェース303及びディスクインタフェース304を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、物理サーバ102は、例えば、管理用ネットワーク103と業務用ネットワーク104への接続は、各々異なるネットワークインタフェース303を用いることができる。
【0026】
図4は、BMC305の構成を示す。BMC305は、演算を処理するCPU401、CPU401の演算に伴うデータを格納するメモリ402、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース403、CPU401の演算前後のデータを格納するデータ格納領域404、CPU401の演算に用いるプログラムを格納するプログラム格納領域405を有する。
【0027】
BMC305は、特定用途に特化した機能のみが実装されていることが多いが、BMC305にログ情報を追記する仕組みを構築することができる。例えば、ファームウェアを更新する際に、プログラム格納領域405に格納されているプログラムに、ログ情報を追記するための機能を追加することで、BMC305にログ情報を追記する仕組みを構築することができる。
【0028】
なお、従来のBMC305を利用し続ける場合や、制御インタフェースが公開されてないBMC305の場合には、図6や図7に示すように、BMC305の内外に、ハードウェア的にデバイス、例えば、プログラムにしたがってログ情報を収集するCPUなどを有するデバイスを追加することよって、ログ情報を追記する仕組みを構築することができる。
【0029】
図5は、システム稼働情報管理方法の動作概略を示す。まず、(1)管理サーバ101は、定期監視またはイベント(サーバ間業務移動指示など)を契機501として、ソフトウェア資源の変更に伴う処理を開始する。
【0030】
(2)次に、管理サーバ101は、ソフトウェア資源(業務アプリケーション321、OS311、仮想サーバ、仮想化機構)のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション321を他の物理サーバに移動させる変更が生じた場合、複数の物理サーバ102の中から、変更元あるいは移動元となる物理サーバ102を抽出し、抽出した移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集502する。
【0031】
この際、管理サーバ101は、識別子と同時に電力情報を取得することで、業務アプリケーション321の移動直前の状況をログ情報に残すことが可能となり、これにより高精度な稼働情報のマッピングが可能となる。
【0032】
(3)次に、管理サーバ101は、収集した電力情報に、収集した識別子として、IPアドレスなど記録(マーク)503する。
【0033】
(4)この後、管理サーバ101は、契機501に伴う制御を移動元の物理サーバ102と移動先の物理サーバ(他の物理サーバ)102へ指示する。これにより、移動元の物理サーバ(サーバA)102で稼働していた業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動する。
【0034】
(5)その後、管理サーバ101は、業務アプリケーション321を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ(サーバB)102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動したことをログ情報として残す。
【0035】
これにより、ソフトウェア資源(業務アプリケーション321、OS311、仮想サーバ、仮想化機構)のうち、例えば、業務アプリケーション321で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。
【0036】
業務アプリケーション321や仮想サーバが使用した稼働情報については、OS311や仮想化機構が稼働情報または割当情報として正確に把握している。そのため、全体における特定業務アプリケーションまたは特定仮想サーバが利用した使用量を両者で按分し、按分されたものと、本発明で実現する物理的な稼働情報として記録されたログ情報とを正確に突き合わせることによって、特定業務アプリケーションまたは特定仮想サーバが利用した物理量を計算することが可能になる。これにより、例えば、業務毎の消費電力量を正確に知ること出来る。
【0037】
また、管理サーバ101が、各物理サーバ102の取得による物理量(例えば、電力量)とその閾値(kW)について監視し、各物理サーバ102の取得による物理量が閾値を跨いだとき、例えば、電力量が閾値を超えたとき、あるいは、電力量が閾値を下回ったときを契機として、そのとき稼働していた業務アプリケーション321や仮想サーバを把握することが可能になる。
【0038】
すなわち、管理サーバ101は、各物理サーバ102からそれぞれログ情報を収集し、収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、複数の物理サーバ102のうち、閾値を跨いだログ情報の収集先となる物理サーバ102のログ情報に、閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または閾値を跨いだログ情報を記録することができる。これにより、物理視点で、正確なログ情報(業務稼働ログ)を把握することができる。
【0039】
この際、取得による物理量が閾値を跨いだ物理サーバ102に対して、別の物理サーバ、別のシャーシ(ブレードサーバの場合)、別のラック、別のブレーカ、別のフロア、別のセンタへの移動計画を立案することが可能になる。
【0040】
また、ログ情報に識別子をマーキング(記録)するに際しては、障害、例えば、ハードウェア障害、ソフトウェア障害、性能障害の発生を契機としてマーキングしたり、障害予兆や性能障害予兆でマーキングしたりすることで、以下のようなメリットが生じる。
【0041】
具体的には、ハードウェア障害を契機として、ソフトウェア情報(識別子など)をハードウェアログにマーキングすると、その時点で稼働していたソフトウェアを記録することで、どのソフトウェアをリカバリすれば良いかを判断することができる。
【0042】
ソフトウェア障害を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、物理的な計算機資源が枯渇していたことが原因なのか判定出来る。
【0043】
ソフトウェア障害を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、仮想サーバを利用する環境で、障害がユーザプログラム起因で発生したものか否かを特定出来る。これにより、ユーザが起こした障害の場合は、ユーザに課金するが、計算機環境側が障害を起こした障害の場合は、ユーザに課金しない、といった厳密な運用が可能となる。すなわち、リスクの適正な分散が可能となる。
【0044】
性能障害を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。
【0045】
性能障害を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務(ソフトウェア資源)がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。
【0046】
障害予兆を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、ソフトウェアログ゛を監視することで、障害によるシステムダウンが発生する前に、別のサーバへ移動する、といった対策を講じることが可能になる。温度が異常であれば、その周辺の温度が高くなっていると判断し、別のラックやフロアへ移動したり、周辺の温度を取得して移動先を決めたりする、といった対策を講じることが可能になる。
【0047】
障害予兆を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、業務の優先順位や移動のし易さなどから、退避の優先順位付けを行い、優先順位の高い業務をより高確率に継続させるよう対策を講じることが可能になる。
【0048】
性能障害予兆を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。
【0049】
性能障害予兆を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。
【0050】
図6は、BMC305の異なる実現形態を示す。このBMC305は、ログ制御機能601を有する他は、図4のものと同様である。ログ制御機能601は、データ格納領域404へ格納されているログ(ログ情報)へマーキングする機能を持つ。なお、ログ制御機能601に、データ格納領域404からログを収集し、収集したログにマーキングした後、ログ制御機能601内にデータを格納するか、あるいは収集したログを管理サーバ101へ送信する機能を付加することもできる。
【0051】
図6におけるBMC305は、図4に示すBMC305にハードウェアを追加することで実現できる形態であって、過去資産の流用が可能なため、安価に実現することが出来る。また、法規制などの要請により、ログに追記しない形態で保存する必要があって、BMC305から、追加されたハードウェアを外す場合には、データ格納領域404へ元のログは残す実現方式が可能となる。
【0052】
図7は、物理サーバ102の異なる実現形態を示す。ログ制御機能701は、BMC305へ格納されているログへマーキングする機能を持つ。なお、ログ制御機能701に、BMC305からログを収集し、収集したログに、マーキングした後、ログ制御機能701内にデータを格納するか、あるいは、収集したログを管理サーバ101へ送信する機能を付加することもできる。
【0053】
図7における物理サーバ102は、図6におけるBMC305の実現形態と同様、過去資産を流用することで安価に実現できる。また、ログ制御機能701と同等の機能が管理サーバ101にて実現されていても、同様の効果を得ることが出来る。
【0054】
図8は、複数の物理サーバ102の代わりに、物理サーバと略同一の機能を有する複数のブレードサーバ802を用い、各ブレードサーバ802をサービスプロセッサ801に接続したときの計算機システムの構成図を示す。
【0055】
管理サーバ101は、NW-SW(管理用ネットワーク)103を介して、シャーシ803のサービスプロセッサ801及び各ブレードサーバ802と接続されている。サービスプロセッサ801は、内部ネットワークを介してブレードサーバ802と接続されている。管理サーバ101は、NW-SW103の管理インタフェース(管理I/F)113、NW-SW(業務用ネットワーク)104の管理インタフェース114へ接続されており、管理サーバ101から各NW-SWのVLAN(Virtual LAN)を設定することが可能である。
【0056】
サービスプロセッサ801は、ブレードサーバ802のシャーシ803への挿抜(ブレードサーバ802の追加、削除)やブレードサーバ802の障害を検知し、管理サーバ101へアラートを通知する。
【0057】
NW-SW103は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といったブレードサーバ103の運用管理をするために必要なネットワークである。NW-SW104は、業務用のネットワークに属しており、ブレードサーバ802上で実行される業務用アプリケーションが使用するネットワークである。
【0058】
図9は、サービスプロセッサ801の構成を示す。図9において、サービスプロセッサ801は、演算を処理するCPU901、CPU901で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ902、プログラムやデータを格納するストレージ装置とのディスクインタフェース904、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース903、ログを制御する機能を持つログ制御機能905を有する。
【0059】
ただし、ログ制御機能905は、ブレードサーバ802内やブレードサーバ802のBMC1005(図10参照)内や管理サーバ101にて実現されている場合は、必ずしも必要とはしない。
【0060】
図10は、ブレードサーバ802の構成を示す。図10において、ブレードサーバ802は、演算を処理するCPU1001、CPU1001で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ1002、プログラムやデータを格納するストレージ装置とのディスクインタフェース1004、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース1003、電源制御や各インタフェースの制御を行うBMC(Baseboard Management Controller)1005を有する。
【0061】
ブレードサーバ802は、メモリ1002上のOS311がCPU1001によって実行されることで、ブレードサーバ802内のデバイス管理を行っている。OS311の下で、業務を提供する業務アプリケーション321や監視プログラム322などが動作する。BMC1005は、サービスプロセッサ801と内部ネットワークを介して接続されており、稼働情報や障害情報を通知する機能や、電源制御の指示を受け付け実行する機能を持つ。また、本実施例におけるブレードサーバ802は、ログの取得・ログの送信・ログへのマーキングを実行する機能を持つ。
【0062】
図11は、物理サーバ管理テーブル221を示す。図11において、物理サーバ102やブレードサーバ802を管理するための物理サーバ管理テーブル221のカラム1101には、物理サーバ識別子が格納しており、本識別子によって各物理サーバを一意に識別することができる。カラム1101へ格納するデータは、本テーブル221で使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。
【0063】
カラム1102には、UUID(Universal Unique IDentifier)が格納されている。UUIDは、重複しないように形式が規定された識別子である。そのため、各サーバ102または802に対応して、UUIDを保持することにより、確実なユニーク性を保証する識別子となり得る。そのため、カラム1101に格納されている識別子は、サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。
【0064】
ただし、カラム1101には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1101のサーバ識別子には、MACアドレス、WWN(World Wide Name)などを用いても良い。
【0065】
カラム1103(カラム1171〜カラム1172)には、I/Oデバイスに関する情報が格納されている。カラム1171には、デバイス種別が格納されている。例えば、HBA(Host Bus Adaptor)やNIC(Network Interface Card)などが格納される。カラム1172には、HBAの識別子であるWWN(World Wide Name)、NICの識別子であるMAC(Media Access Control)アドレスが格納されている。
【0066】
カラム1104には、物理サーバ102のモデルが格納されている。このモデルは、インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。
【0067】
カラム1105には、物理サーバ102の構成に関する構成情報が格納されている。例えば、物理サーバ102の構成に関する構成情報として、プロセッサ(CPU301、CPU1001)のアーキテクチャ、シャーシ803やスロットなどの物理位置情報、特徴機能(ブレード間SMP:Symmetric Multiprocessing、HA(High Availability)構成などの有無)が格納されている。カラム1104も同様、インフラに関わる情報である。
【0068】
カラム1106には、物理サーバ102の性能情報が格納されている。カラム1104も同様、インフラに関わる情報である。
【0069】
カラム1107には、ログ情報が格納されている。このカラム1107には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0070】
カラム1108には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1107とカラム1108から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0071】
インフラに関わる情報は、物理サーバ102の移動先を提案する場合に、移動が可能か否かを判定するために必要である。
【0072】
図12は、仮想化機構管理テーブル222を示している。仮想化機構管理テーブル222は、どのような仮想化機構で、どんなログがどこに格納されていて、どのようにすればアクセス可能か、といった情報を管理するものである。
【0073】
カラム1201には、仮想化機構識別子が格納されており、本識別子によって各仮想化機構を一意に識別することができる。カラム1201へ格納するデータは、本テーブルで使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで、入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。
【0074】
カラム1202にはUUIDが格納されている。UUIDは、仮想化機構識別子として、有力な候補である。
【0075】
カラム1203には、仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。
【0076】
カラム1204には、仮想化機構設定情報が格納されている。仮想化機構設定情報は、仮想化機構へ接続するために必要なIPアドレスなどである。
【0077】
カラム1205にはログ情報が格納されている。カラム1205には、どのような情報をログとして保持し、どこへ保持されているか、が格納される。
【0078】
カラム1206には、ログ情報操作インタフェースが格納されている。ログを操作するときに接続するプログラムやインタフェースに関する情報が格納されている。
【0079】
カラム1205とカラム1206から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0080】
図13は、仮想サーバ管理テーブル223を示している。仮想サーバ管理テーブル223は、どのようなシステム構成を定義した仮想サーバで、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。
【0081】
カラム1301には、仮想サーバ識別子が格納されており、本識別子によって各仮想サーバを一意に識別することができる。
【0082】
カラム1302には、UUIDが格納されている。カラム1301に格納されている仮想サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1301には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。
【0083】
例えば、カラム1301の仮想サーバ識別子には、仮想MACアドレス、仮想WWNなど(カラム1372へ格納)を用いても良い。また、OS311によっては、独自にユニーク性を保つための識別子を採用している場合があるが、この場合は、OS311が採用しているIDを使っても良いし、ユニーク性を確保するために独自に保持してもかまわない。
【0084】
カラム1303(カラム1371〜カラム1373)には、仮想I/Oデバイスに関する情報が格納されている。カラム1371には、仮想デバイス種別が格納されている。例えば、仮想HBAや仮想NICなどが格納される。カラム1372には、仮想HBAの識別子である仮想WWN、仮想NICの識別子である仮想MACアドレスが格納されている。カラム1373には、仮想I/Oデバイスのモードが格納されており、このモードには、共有モードと占有モードがある。
【0085】
仮想デバイスには、使用する物理デバイスを共有で使用するモードと、占有で使用するモードが存在する。共有の場合、他の仮想デバイスが物理デバイスを同時に使用する。占有モードの場合、物理デバイスをその仮想デバイスが単独で使用する。
【0086】
カラム1304には、仮想サーバの仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。
【0087】
カラム1305には、仮想サーバの性能情報が格納されている。カラム1304も同様、インフラに関わる情報である。
【0088】
カラム1306には、ログ情報が格納されている。カラム1306には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0089】
カラム1307には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1306とカラム1307から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0090】
インフラに関わる情報は、物理サーバ102の移動先を提案する場合に、移動が可能か否かを判定するために必要である。
【0091】
図14は、OS管理テーブル224を示している。OS管理テーブル224は、どのようなOS311で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのデーブルである。
【0092】
カラム1401には、OS識別子が格納されており、本識別子によってOSを一意に識別することができる。
【0093】
カラム1402には、UUIDが格納されている。カラム1401に格納されているOS識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1401には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1401のOS識別子には、OS設定情報(カラム1404へ格納)を用いても良い。
【0094】
カラム1403は、OS設定情報が格納されている。例えば、IPアドレスやホスト名、ID、パスワード、ディスクイメージなどが格納されている。ディスクイメージは、設定前後のOSが物理サーバ102または仮想サーバ2302へ配信されたシステムディスクのディスクイメージを指す。カラム1404へ格納するディスクイメージに関する情報は、データディスクを含めても良い。
【0095】
カラム1405には、ログ情報が格納されている。カラム1405には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0096】
カラム1406には、ログ情報を操作するインタフェースに関する情報が格納している。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1405とカラム1406から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0097】
図15は、業務管理テーブル225を示している。業務管理テーブル225は、どのようなソフトウェア資源(例えば、業務アプリケーション321)で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。
【0098】
カラム1501には、業務識別子が格納されており、本識別子によって業務、例えば、業務アプリケーション321を一意に識別することができる。
【0099】
カラム1502には、UUIDが格納されている。カラム1501に格納されている業務識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1501には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1501のサーバ識別子には、業務設定情報(カラム1504へ格納)を用いても良い。
【0100】
カラム1503には、業務種別が格納されており、使用するアプリケーションやミドルウェアといった業務を特定するソフトウェアに関する情報が格納されている。業務で使用する論理的なIPアドレスやID、パスワード、ディスクイメージ、業務で使用するポート番号などが格納されている。ディスクイメージは、設定前後の業務が物理サーバ102または仮想サーバ2302上のOS311へ配信されたシステムディスクのディスクイメージを指す。カラム1504へ格納するディスクイメージに関する情報は、データディスクを含めても良い。
【0101】
カラム1505には、ログ情報が格納されている。カラム1505には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
【0102】
カラム1506には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1505とカラム1506から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
【0103】
図16は、システム管理テーブル226を示している。システム管理テーブル226は、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224及び業務管理テーブル225で管理される、物理サーバ102、仮想化機構2301、仮想サーバ2302、OS331及び業務321の組み合わせによるシステム構成を管理し、システム変更やサーバ移動のステータス及びログ制御を管理するためのテーブルである。
【0104】
カラム1601には、システム識別子が格納しており、本識別子によって業務、例えば、業務アプリケーション321を一意に識別することができる。
【0105】
カラム1602には、UUIDが格納されている。カラム1603からカラム1605の全部または一部の組み合わせで実現しても良いし、独自に生成しても良い。少なくとも、管理サーバ101が管理する範囲で一意である必要がある。
【0106】
カラム1603には、物理サーバ識別子1101が格納され、カラム1604には、仮想化機構識別子1201が格納され、カラム1605には、仮想サーバ識別子1301が格納され、カラム1606には、OS識別子1401が格納され、カラム1607には、業務識別子1501が格納されている。
【0107】
図面には記載していないが、ラックやフロア、コンセントボックス、ブレーカ、センタ、HA構成の有無、ネットワークインフラ情報、電力グリッド、ネットワーク結線関係、ネットワークスイッチ、ファイバチャネルスイッチ、各スイッチの収容量、ネットワーク帯域などを管理することで、それらにまたがったシステムの移動についても本発明の効果を得ることが可能になる。
【0108】
カラム1608には、システム変更ステータスが格納されている。カラム1608には、なにをどこへ移動するのか、移動前・移動中・移動後、といったステータスが格納される。
【0109】
カラム1609には、ログ取得ステータスが格納されている。ログ取得ステータスは、ログ取得を要請する対象でのログ取得が完了しているかどうかを管理するためのものである。
【0110】
カラム1610には、マーキングステータスが格納されている。マーキングステータスは、ログへマーキングを要請する対象へマーキングが完了しているかどうかを管理するためのものである。マーキングステータスは、本発明における重要ポイントである。
【0111】
カラム1611には、ログ収集ステータスが格納されている。ログ収集ステータスは、対象からログを収集する場合に、ログ収集が完了しているかどうかを管理するためのものである。管理サーバ101内やBMC305の内外デバイス、サービスプロセッサ801内へログを収集する際に、ステータスを管理する必要がある。
【0112】
図17は、契機管理テーブル227を示している。契機管理テーブル227のカラム1701には、契機識別子が格納されている。カラム1702には、契機の内容が格納されている。カラム1702には、管理サーバ101へサーバ移動などの動作が入力される場合もあるが、契機を検出して自動実行するときの動作が入力される場合もある。
【0113】
後者の場合、動作に伴うイベント通知が契機となる。契機としては、以下に挙げるような動作が考えられるが、システム管理テーブル226のシステム構成に関するカラムが変更される場合は、全て契機と成り得る。
【0114】
仮想サーバをライブマイグレーションする場合、仮想サーバ2302以上(仮想サーバ2302、OS321、業務321、図23参照)は、稼働する物理サーバ102を移動(変更)することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
【0115】
LU(Logical Unit)を接続する物理サーバ102が変更となる場合、OS321と業務321は稼働する物理サーバ102を移動(変更)することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
【0116】
また、LUを接続する仮想サーバ2302が変更となる場合、仮想化機構2301または仮想サーバ2302以上(OS321、業務321を含む)が移動することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。
【0117】
別の業務のディスクイメージをデプロイ(配信、デプロイメント)する場合、LUを接続するサーバを変更する場合と同様である。
【0118】
インタフェースカードの固有値(WWNやMACアドレス)を書き換える場合、LUを接続する物理サーバ102を変更する場合と同様である。
【0119】
Java(登録商標)アプリケーションをデプロイする場合、業務321内のプロセス(論理サーバ)が追加・削除・変更されるため、業務321およびプロセスの識別子を物理サーバ102の稼働情報ログへマーキングする。
【0120】
業務ソフトウェアのIPアドレスを変更する場合、稼働する物理サーバ102または仮想サーバ2302を移動(変更)するように見なすことが出来る。
【0121】
この場合も、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。
【0122】
ソフトウェア起動通知、OS起動通知、仮想サーバ起動通知、仮想化機構起動通知で、稼働しているシステム情報を取得し、システム管理テーブル226との差異を調査し、差異がある場合、物理サーバ102の移動(変更)が発生している。物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
【0123】
この際、管理サーバ101は、例えば、ソフトウェア資源がある物理サーバ102から、他の物理サーバ102に移動する場合、他の物理サーバ102が起動したことを条件に、他の物理サーバ102に属するソフトウェア資源と他の物理サーバ102の構成を示すハードウェア構成情報との間に差異があるか否かを判定し、差異があるときには、その旨の情報を、識別子とともに、他の物理サーバ102のログ情報に記録することで、記録された情報を基に正しい構成に修正したり、あるいは、マーキングに失敗したことを把握したりすることができる。
【0124】
また、上記に挙げる契機で、物理サーバ102の識別子を物理サーバ102以外の稼働ログへマーキングしても良い。これにより、論理的な稼働情報(業務321、OS311、仮想サーバ2302、仮想化機構2301)を記録したログから、正確かつ簡単に物理サーバの稼働情報を参照することが可能である。記録先のログは全てでも良いし、一部でも良い。
【0125】
監視対象の物理量(例えば消費電力量)が設定した閾値を跨ぐ場合、論理的な稼働情報を記録したログへ、物理サーバ識別子をマーキングする。また、測定した物理量を同時にマーキングしても良い。この契機と同様のものとして、ハードウェアやソフトウェアの障害情報の通知、性能障害情報の通知、警告(障害予兆、性能障害含む)の通知などが挙げられる。
【0126】
図18は、マーキング規則管理テーブル228を示している。マーキング規則管理テーブル228は、どんな契機で、どのログに、なんの識別子をマーキングするか、を管理するためのテーブルである。
【0127】
カラム1801には、規則識別子が格納され、カラム1802には、契約識別子(カラム1701)が格納され、カラム1803には、マーキングする対象の階層が格納され、カラム1804には、マーキングする対象となるログまたはログ種別が格納され、カラム1805には、マーキングする識別子が格納される。
【0128】
マーキングの方法としては、ログ内の最新情報部にマーキングする識別子を追記する方法を用いることができる。また、マーキングの開始と終了のみを追記しても良いし(システムが変更されたときのみマーキング)、その後のログ全てにマーキングしても良い。
【0129】
図19は、課金情報管理テーブル229を示している。課金情報管理テーブル229は、課金に関する情報を管理するテーブルであり、運用コストが下がるシステム構成を提案するために使用される。
【0130】
課金情報管理テーブル229のカラム1901には、課金情報識別子が格納され、カラム1902には、課金対象が格納されている。格納される情報は、消費電力量のような物理量でも良いし、仮想サーバや物理サーバ102といったインフラ情報、トランザクション保証のレベルといったSLA(Service Level Agreement)情報でも良い。
【0131】
カラム1903には、課金情報が有効となる条件が格納されている。時刻やシステム構成、インフラ情報(HA構成の有無や種類、ネットワーク帯域、地域など)である。カラム1904には、単価が格納されている。
【0132】
課金情報管理テーブル229を利用するに際して、物理稼動情報を記録したログを参照し、温度の高いサーバといったIT機器および負荷のかかったファシリティを検出した場合、課金情報管理テーブル229の条件や単価を操作し、一時的に価格を上げ、需要を抑えるような価格操作によって、より効率の良い運用(例えば、該当サーバの需要は下がり、利用率が下がることで温度を下げる効果がある)を管理者に提供することが出来る。
【0133】
また、計算機資源を利用するユーザにとってみれば、温度が高いサーバを使うことは、温度上昇によるハードウェア障害のリスクが高いことになるが、価格の安い計算機資源を選ぶことで、同時に温度によるハードウェア障害のリスクを回避することも可能となる。
【0134】
図20は、契機監視部210の処理フローチャートを示す。
【0135】
契機監視部210は、管理サーバ101のCPU201によって処理を開始する。契機監視部210は、契機の発生を監視し、発生した契機についてログへマーキングするか否かを判定し、ログへマーキングする場合は、ログを取得およびマーキングを指示、またはログを収集およびマーキングする指示する。
【0136】
まず、ステップ2001で、管理サーバ101は契機の発生を監視し、契機が発生した場合、ステップ2002へ進む。
【0137】
ステップ2002で、管理サーバ101は、契機を基に契機管理テーブル227を参照する。
【0138】
ステップ2003で、管理サーバ101は、契機管理テーブル227を参照した結果を基に、ログへマーキングするか否かを判定し、マーキングする場合、ステップ2004へ進み、マーキングしない場合、ステップ2001へ進む。
【0139】
ステップ2004で、管理サーバ101は、システム管理テーブル226を参照し、マーキングする旨、システム管理テーブル226を変更し、処理を完了する。
【0140】
契機としては、ユーザ操作によるもの(GUI操作、CLI発行など)、イベント発生によるもの(ハードウェア障害情報の書き込み及び通知など)、アラート通知によるもの(閾値越え、障害通知など)がある。
【0141】
図21は、ログ取得指示部211の処理フローチャートを示す。
【0142】
ログ取得指示部211は、管理サーバ101のCPU201によって処理を開始する。この処理へ移行する前提として、契機監視部210が「ログへマーキングする」と判断し、契機を契機監視部210から受け取っていることが挙げられる。また、元々のログを取得する契機と時間的に近い場合、ログ取得指示部211は、ログ取得を指示しなくても良い。
【0143】
まず、ステップ2101で、ログ取得指示部211は、契機管理テーブル227を参照する。
【0144】
ステップ2102で、ログ取得指示部211は、契機管理テーブル227を参照した結果を基に、システム管理テーブル226を参照し、次に挙げる、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225のうち、全てのテーブルまたは契機やログのマーキングに関連するテーブルのみを参照する。
【0145】
次に、ステップ2103において、ログ取得指示部211は、ステップ2102で参照したテーブルの内容を基に管理対象へログ取得を指示する。
【0146】
この後、ログ取得指示部211は、ステップ2104において、システム管理テーブル226を更新し、処理を完了する。
【0147】
図22は、マーキング指示部212の処理フローチャートを示す。
【0148】
マーキング指示部212は、管理サーバ101のCPU201によって処理を開始する。この処理へ移行する前提として、マーキング対象のログと追記する識別子は確定していることとしている。
【0149】
まず、ステップ2201で、マーキング指示部212は、マーキング規則管理テーブル228を参照する。
【0150】
ステップ2202で、マーキング指示部212は、マーキング規則管理テーブル228を参照した結果を基に、マーキング対象のログ情報を保持するテーブルを参照する。参照するテーブルは、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225のうち、全てでも良いし、マーキング対象となるもののみでも良い。
【0151】
ステップ2203で、マーキング指示部212は、マーキング対象ログへ識別子を追記する。
【0152】
ステップ2204で、マーキング指示部212は、マーキング対象ログへ識別子を追記した内容を基にシステム管理テーブル226を更新する。
【0153】
本実施例においては、ソフトウェア資源のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション321を他の物理サーバに移動させる変更が生じた場合、管理サーバ101は、複数の物理サーバ102の中から、変更元あるいは移動元となる物理サーバ102を抽出し、抽出した移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスを収集し、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、その後、移動先の物理サーバ(サーバB)102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動したことをログ情報として残すこととしている。
【0154】
従って、本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。
【実施例2】
【0155】
本実施例は、サーバ仮想化技術を利用するとともに、物理サーバとして、ブレードサーバ802を用いたものであり、他の構成は、実施例1と同様である。
【0156】
図23は、サーバ仮想化技術を適用した実施例2のシステム構成のうち、物理サーバ102の内部構成を示している。この際、物理サーバ102として、ブレードサーバ802を用いても、内部構成は同様である。
【0157】
ブレードサーバ802は、演算を処理するCPU301、CPU301で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ302、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース304、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース303、電源制御や各インタフェースの制御を行うBMC305から構成される。
【0158】
メモリ302には、計算機資源を仮想化するためのサーバ仮想化技術を提供する仮想化機構2301が配備され、仮想サーバ2302を提供する。また、仮想化機構2301は、制御用インタフェースとして仮想化機構管理用インタフェース2311を備えている。仮想化機構2301は、物理サーバ102(またはブレードサーバ802)の計算機資源を仮想化し、仮想サーバ2302を構成する。仮想サーバ2302は、仮想CPU2321、仮想メモリ2322、仮想ネットワークインタフェース2323、仮想ディスクインタフェース2324から構成されている。
【0159】
仮想メモリ2322には、OS331が配信され、仮想サーバ2302内の仮想デバイスを管理している。また、OS331上では、業務アプリケーション321が実行されている。OS331上で稼働する管理プログラム322によって、障害検知やOS電源制御、インベントリ管理などが提供されている。
【0160】
仮想化機構2301は、物理デバイスと論理デバイスの対応付けを管理しており、物理デバイスと論理デバイスとを対応付けたり、両者の対応付けを解除したりすることが出来る。
【0161】
また、メモリ302には、どの仮想サーバ2302が物理サーバ102(またはブレードサーバ802)の計算機資源を、どれくらい割り当てられ、また、使用しているかといった構成情報および稼働履歴が保持されている。この情報及び、例えば、物理サーバ102が保持する稼働ログ(例えば、消費電力ログ)に、本発明で実施する識別子がマーキングされたログを突き合わせることで、正確にどの仮想サーバ2302がどれだけの電力消費に関わっていたかを導くことが可能である。
【0162】
これにより、精度の高い課金や電力消費の特に高いまたは低い仮想サーバ2302を特定することが可能になる。
【0163】
本発明の実施に関わる制御部110及び管理テーブル群111の構成は実施例1と同様である。
【0164】
本実施例では、ソフトウェア資源として、仮想化機構2301上に仮想サーバ2302が構築され、仮想サーバ2302上にOS331が構築され、OS331上に業務アプリケーション321が構築される構成となっている。
【0165】
このため、仮想化機構2301が他の物理サーバ102に移動するときには、仮想化機構2301とともに、OS331及び業務アプリケーション321が他の物理サーバ102に移動し、仮想サーバ2302が他の物理サーバ102に移動するときには、仮想サーバ2302とともに、OS331及び業務アプリケーション321が他の物理サーバ102に移動し、OS331が他の物理サーバ102に移動するときには、OS331とともに、業務アプリケーション321が他の物理サーバ102に移動し、業務アプリケーション321が他の物理サーバ102に移動するときには、業務アプリケーション321のみが他の物理サーバ102に移動することになる。
【0166】
この際、管理サーバ101は、例えば、業務アプリケーション321の移動を契機として、移動対象となる業務アプリケーション321を稼働している物理サーバ102を変更元あるいは移動元の物理サーバ102とし、移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集する。
【0167】
次に、管理サーバ101は、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、この後、契機に伴う制御を移動元の物理サーバ102と移動先の物理サーバ102へ指示する。これにより、移動元の物理サーバ102で稼働していた業務アプリケーション321が移動先の物理サーバ102へ移動する。
【0168】
その後、管理サーバ101は、業務アプリケーション321を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ102へ移動したことをログ情報として残す。
【0169】
これにより、業務アプリケーション321で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。
【0170】
ソフトウェア資源として、業務アプリケーション321、OS331、仮想サーバ2302、仮想化機構2301を用い、これらのいずれかをソフトウェア資源の変更の対象として、ログ情報を記録すると、以下のようなメリットが生じる。
【0171】
ソフトウェア資源の変更の対象として、業務アプリケーション321を用いた場合、業務アプリケーショ321ンごとに、物理的な計算機資源の利用状況を知ることが可能となる。これにより、業務アプリケーション321を追加するときに、同じOS(仮想サーバ)331上に同居させるべきか、別のOS(仮想サーバ)331上に置くべきかを判断することが可能になる。
【0172】
また、変更の対象となる業務アプリケーション321が稼働している物理サーバ102とは別の物理サーバ102へ負荷を分散させたり、更に高スペックな物理サーバへ移動させたりするべきか、といった判断が可能となる。
【0173】
また、一つの業務を提供するソフトウェアが、性能や価格によって幾つか選択可能な場合に、状況に応じて選択可能となる。
【0174】
ソフトウェア資源の変更の対象として、OS331を用いた場合、OS331ごとに、物理的な計算機資源の利用状況を知ることが可能となる。すなわち、IPアドレスやホスト名、稼動する業務の設定を引き継ぐことで、あたかもOS331が移動したかのように見ることが出来る。これにより、OS331は、性能の異なるハードウェア間を容易に移動出来るのだが、この移動をすべきか否かの判断が可能となる。
【0175】
またディスクイメージをデプロイすることで、移動することも可能であるが、時間がかかるが設定変更に比べて、操作の手間やミス発生の確率が低いというメリットがある。この際、どちらが利用者によって有益化を判定することが可能になる。
【0176】
ソフトウェア資源の変更の対象として、仮想サーバ2302を用いた場合、仮想サーバ2302毎に、物理的な計算機資源の利用状況を知ることが可能となる。これにより、仮想サーバ2302ごと移動させるか、OS331より上位を移動させるか、業務アプリケーション321のみを移動させるかを判断することが可能になる。仮想サーバ2302を動的に移動させた場合と一旦停止させて移動させた場合では、移動にかかる時間が異なる。このような場合にでも、正確に稼動情報を知ることが可能になり、正しい課金を実施することが出来る。
【0177】
ソフトウェア資源の変更の対象として、仮想化機構2301を用いた場合、仮想化機構2301の、物理的な計算機資源の利用状況を知ることが可能となる。異なる仮想化機構(価格、性能といった特徴が異なる)を使い分けることが可能となる。
【0178】
本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。
【実施例3】
【0179】
本実施例は、ログ収集部213が稼働するか否かを判定する他は、実施例1および実施例2と同様である。すなわち、本実施例は、古いシステムやログへの接続が独自インタフェースといった仕様、また独立性の保持という観点(他からログを改ざんされないこと、ログが暗号化されている場合など)が原因で、ログを直接編集出来ない場合が存在することを考慮したものである。ログを直接編集出来ない場合、ログ収集インタフェースを介してログを別のサーバ(例えば管理サーバ101)やサービスプロセッサ801へ収集し、収集したログにマーキングを施す、といったことが必要である。そのため、ログ収集部213が必要となる。
【0180】
図24は、ログ収集部213の処理フローチャートを示す。
【0181】
ログ収集部213は、管理サーバ101のCPU201によって処理を開始する。まず、ステップ2401で、ログ収集部213は、マーキング管理テーブル228を参照する。
【0182】
ステップ2402で、ログ収集部213は、マーキング管理テーブル228を参照した結果を基に、マーキング対象のログ情報を保持するテーブルとして、以下のテーブル、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225を参照する。
【0183】
ステップ2403で、ログ収集部213は、各テーブルの参照結果を基に、ログを他のサーバ(管理サーバ101、サービスプロセッサ801など)へ収集するか判定し、収集する場合はステップ2404へ進み、しない場合は処理を完了する。
【0184】
ステップ2404で、ログ収集部213は、管理対象へログ提供を指示し、ログを収集する。
【0185】
この後、ステップ2405で、ログ収集部213は、システム管理テーブル226を更新して、処理を完了する。
【0186】
本実施例によれば、古いシステムやログへの接続が独自インタフェースといった仕様、また独立性の保持という観点が原因で、ログを直接編集出来ない場合でも、ログ収集インタフェースを介してログを管理サーバ101やサービスプロセッサ801へ収集させることができる。
【実施例4】
【0187】
実施例4では、実施例1、実施例2及び実施例3で記載した構成を用いるとともに、業務や物理サーバ102の計算機利用に関する傾向分析を実施する。この際、業務視点、物理サーバ視点、仮想サーバ視点といった各階層において、観測する物理量、動作しているソフトウェアや仮想サーバの量や種類、といった可観測なものの傾向を分析することで、利用者や管理ソフトウェアへ分析結果を通知したり、またはアラートを上げたりすることができる。
【0188】
また、この結果を基にシステム構成提案を実施することで、より効率的な計算機資源の利用を利用者へ提供する。例えば、予算内で一番性能の良い構成や、同じく一番可用性の高い構成、またはその組み合わせなどである。
【0189】
図25は、傾向分析部214の処理フローチャートを示す。
【0190】
傾向分析部214は、管理サーバ101のCPU201によって処理を開始する。まず、傾向分析部214は、ステップ2501で、「分析する視点」と「分析する対象」に関する入力を受け付ける。これは、利用者が契機を与える場合である。または、ハードウェアやソフトウェアの障害通知または性能障害通知を契機としても良い。
【0191】
これにより、現在の構成では業務の稼働や予算内運用に支障をきたす場合に、利用者は原因の分析結果や回避策となるシステム構成を容易に迅速に把握することが可能となり、対策も容易に迅速に行うことが出来る。
【0192】
次に、傾向分析部214は、ステップ2502で、視点を判定する。
【0193】
ステップ2503で、傾向分析部214は、システム管理テーブル226を参照する。
【0194】
ステップ2504で、傾向分析部214は、システム管理テーブル226を参照した結果を基に、稼働情報を保持するテーブルとして、以下のテーブル、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225を参照する。
【0195】
ステップ2505で、傾向分析部214は、各テーブルを参照した結果を基に、分析する対象のログの中で、分析する視点のマーキングに相当する箇所を抽出する。
【0196】
ステップ2506で、傾向分析部214は、分析結果を出力し、処理を完了する。
【0197】
本実施例によれば、現在の構成では業務の稼働や予算内運用に支障をきたす場合に、利用者は、原因の分析結果や回避策となるシステム構成を容易に迅速に把握することが可能となり、対策も容易に迅速に行うことが出来る。
【0198】
図26は、システム構成提案部215の処理フローチャートを示す。
【0199】
電力使用量を最低にするシステム構成を提案、スペース使用量を最低にするシステム構成を提案、昼夜で使用量または料金が異なる場合に、予算の範囲内で性能または可用性が高いシステムを提案、といったことが可能になる。
【0200】
例えば、高性能で高可用なシステムが低価格で入手出来れば良いが、現実は高付加価値なシステムほど高価格になる。また利用者の予算は上限が存在し、折り合いをつける必要がある。
【0201】
使用制限の例としては、予算、消費電力量の上限、CPU使用量の上限および下限(〜%以上で使用したい)、メモリ使用量の上限、ネットワーク帯域使用量の上限、ネットワークインフラ(〜Gbps以上)、業務アプリケーション321のスループット上限および下限、計算機資源の占有利用または共有利用、HA構成の有無や種類など、である。
【0202】
システム構成提案部215は、管理サーバ101のCPU201によって処理を開始する。まず、システム構成提案部215は、ステップ2601で、「最小または最大にする物理量」(評価基準となる物理量)に関する入力及び「前提条件」(制限値)の入力を受け付ける。
【0203】
ステップ2602で、システム構成提案部215は、課金情報管理テーブル229、システム管理テーブル226を参照する。
【0204】
ステップ2603で、システム構成提案部215は、テーブルの参照結果を基に、前提条件内に収まる範囲でシステム構成を変化させる。
【0205】
ステップ2604で、システム構成提案部215は、評価基準となる物理量が最小または最大であるか判定する。このとき、最小か最大かはなにを満足する条件として設定するかによって変わる。どちらでも良い訳ではない。システム構成提案部215は、最小または最大となる場合はステップ2605へ進み、そうでない場合はステップ2606へ進む。
【0206】
ステップ2605で、システム構成提案部215は、システム構成と目論見の物理量を保存する。この値をステップ2604で使用する。
【0207】
ステップ2606で、システム構成提案部215は、全試行を完了したかを判定し、完了した場合はステップ2607へ進み、完了していない場合はステップ2603へ進む。
【0208】
ステップ2607で、システム構成提案部215は、保存したシステム構成と目論見の物理量を出力し、処理を完了する。
【0209】
システム構成提案部215は、出力した結果を管理サーバ101へアラート通知し、管理サーバ101が構成変更の指示を出すことで、管理者が不在の場合も問題を解決することが可能になる。または、自動実行せず、利用者の判断を仰いだ上で、承認後に構成変更が実行されるようになっていても良い。
【0210】
本実施例によれば、電力使用量を最低にするシステム構成、スペース使用量を最低にするシステム構成あるいは昼夜で使用量または料金が異なる場合に、予算の範囲内で性能または可用性が高いシステム構成を提案することができる。
【0211】
また、各実施例においては、ログ情報に識別子を記録する代わりに、UUIDを生成し、生成したUUIDをログ情報に記録することもできる。この際、UUIDの生成や記録は、マーキングする主体が行っても良いし、管理サーバ101やBMC305、サービスプロセッサ801が行っても良い。
【0212】
また、各実施例においては、ログ情報に識別子を記録するに際して、移動に関連する物理サーバ102の時刻または管理サーバ101の時刻を取得し、取得した時刻をログ情報に記録することで、ログ情報を時刻に関連づけて把握することができる。この際、問い合わせの時刻を用いるときよりも、マーキングの時刻やログに記録された時刻を用いることで、より正確な照合が可能になる。
【0213】
また、各実施例においては、ログ情報に識別子を記録するに際して、ソフトウェア資源の移動の履歴を示す識別子をログ情報に追加でマーキングすることで、より正確な照合が可能になる。例えば、最近(例えば、ユーザ設定もしくは10分以内などをデフォルト設定)、同じ物理サーバ102間でソフトウェア資源の移動が発生した場合、ソフトウェア資源の移動の履歴を示す識別子を参照することで、2回目以降のソフトウェア資源の移動を正確に把握することができる。
【0214】
さらに、各実施例においては、管理サーバ101が動作の主体であったが、物理サーバ102やブレードサーバ802、サービスプロセッサ801、仮想化機構2301、仮想サーバ2302が動作の主体となり、制御部及び管理テーブル群を保持していても発明の効果を得ることが出来る。
【符号の説明】
【0215】
101:管理サーバ、102:物理サーバ、321:業務、501:契機を検出、502:識別子を収集、503:移動元のログへ識別子をマーキング、504:契機に伴う制御を指示、503:移動先のログへ識別子をマーキング。
【特許請求の範囲】
【請求項1】
ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバと、前記複数の物理サーバとネットワークを介して接続されて、前記各物理サーバを管理する管理サーバを備え、
前記管理サーバは、
前記各物理サーバからそれぞれ前記ログ情報を収集ステップと、
前記ステップで収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、前記物理サーバのうち、前記閾値を跨いだログ情報の収集先となる物理サーバのログ情報に、前記閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または前記閾値を跨いだログ情報を記録するステップと、
前記収集先となる物理サーバで稼働するソフトウェア資源が、前記収集先となる物理サーバから他の物理サーバに移動したことを条件に、前記他の物理サーバのログ情報に、前記収集先となる物理サーバのログ情報に記録された前記識別子または前記閾値を跨いだログ情報を記録するステップを実行する、計算機システムの稼働情報管理方法。
【請求項2】
前記ソフトウェア資源は、業務アプリケーションである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項3】
前記ソフトウェア資源は、オペレーティングシステムである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項4】
前記ソフトウェア資源は、仮想サーバである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項5】
前記ソフトウェア資源は、仮想化機構である、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項6】
前記ソフトウェア資源は、前記物理サーバのハードウェア資源を仮想化した仮想化機構と、前記仮想化機構で仮想化された仮想サーバと、前記仮想サーバで動作するオペレーティングシステムと、前記オペレーティングシステムに従って動作する業務アプリケーションである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項7】
ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバと、前記複数の物理サーバとネットワークを介して接続されて、前記各物理サーバを管理する管理サーバを備え、
前記管理サーバは、
前記各物理サーバからそれぞれ前記ログ情報を収集し、前記収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、前記物理サーバのうち、前記閾値を跨いだログ情報の収集先となる物理サーバのログ情報に、前記閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または前記閾値を跨いだログ情報を記録し、
前記収集先となる物理サーバで稼働するソフトウェア資源が、前記収集先となる物理サーバから他の物理サーバに移動したことを条件に、前記他の物理サーバのログ情報に、前記収集先となる物理サーバのログ情報に記録された前記識別子または前記閾値を跨いだログ情報を記録する、計算機システム。
【請求項1】
ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバと、前記複数の物理サーバとネットワークを介して接続されて、前記各物理サーバを管理する管理サーバを備え、
前記管理サーバは、
前記各物理サーバからそれぞれ前記ログ情報を収集ステップと、
前記ステップで収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、前記物理サーバのうち、前記閾値を跨いだログ情報の収集先となる物理サーバのログ情報に、前記閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または前記閾値を跨いだログ情報を記録するステップと、
前記収集先となる物理サーバで稼働するソフトウェア資源が、前記収集先となる物理サーバから他の物理サーバに移動したことを条件に、前記他の物理サーバのログ情報に、前記収集先となる物理サーバのログ情報に記録された前記識別子または前記閾値を跨いだログ情報を記録するステップを実行する、計算機システムの稼働情報管理方法。
【請求項2】
前記ソフトウェア資源は、業務アプリケーションである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項3】
前記ソフトウェア資源は、オペレーティングシステムである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項4】
前記ソフトウェア資源は、仮想サーバである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項5】
前記ソフトウェア資源は、仮想化機構である、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項6】
前記ソフトウェア資源は、前記物理サーバのハードウェア資源を仮想化した仮想化機構と、前記仮想化機構で仮想化された仮想サーバと、前記仮想サーバで動作するオペレーティングシステムと、前記オペレーティングシステムに従って動作する業務アプリケーションである、請求項1に記載の計算機システムの稼働情報管理方法。
【請求項7】
ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバと、前記複数の物理サーバとネットワークを介して接続されて、前記各物理サーバを管理する管理サーバを備え、
前記管理サーバは、
前記各物理サーバからそれぞれ前記ログ情報を収集し、前記収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、前記物理サーバのうち、前記閾値を跨いだログ情報の収集先となる物理サーバのログ情報に、前記閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または前記閾値を跨いだログ情報を記録し、
前記収集先となる物理サーバで稼働するソフトウェア資源が、前記収集先となる物理サーバから他の物理サーバに移動したことを条件に、前記他の物理サーバのログ情報に、前記収集先となる物理サーバのログ情報に記録された前記識別子または前記閾値を跨いだログ情報を記録する、計算機システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【公開番号】特開2012−79356(P2012−79356A)
【公開日】平成24年4月19日(2012.4.19)
【国際特許分類】
【出願番号】特願2012−14298(P2012−14298)
【出願日】平成24年1月26日(2012.1.26)
【分割の表示】特願2009−150724(P2009−150724)の分割
【原出願日】平成21年6月25日(2009.6.25)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
【公開日】平成24年4月19日(2012.4.19)
【国際特許分類】
【出願日】平成24年1月26日(2012.1.26)
【分割の表示】特願2009−150724(P2009−150724)の分割
【原出願日】平成21年6月25日(2009.6.25)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
[ Back to top ]