本実施例は、ソフトウェア資源を稼働するとともに、ログ情報を収集する複数の物理サーバを管理サーバで管理するに際して、管理サーバは、ソフトウェア資源、例えば、業務アプリケーション、OS(Operating System)、仮想サーバ、仮想化機構のうちいずれかの変更を契機として、各物理サーバのうち、ソフトウェア資源の稼働の変更元となる物理サーバのログ情報に、変更元の物理サーバで稼働していたソフトウェア資源を特定する識別子を記憶し、その後、変更の完了を契機として、他の物理サーバのログ情報に前記識別子を記録するものである。
図1は、実施例1における計算機システムの構成図を示す。図1において、計算機システムは、管理サーバ101と、複数の物理サーバ102を備え、管理サーバ101と各物理サーバ102は、NW-SW(Network−Switch:管理用ネットワーク)103とNW-SW104を介して接続されている。
管理サーバ101は、NW-SW103の管理インタフェース(管理I/F)113、NW-SW(業務用ネットワーク)104の管理インタフェース114へ接続されており、管理サーバ101から各NW-SW103、104のVLAN(Virtual Local Area Network)を設定することが可能である。
NW-SW103は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といった、各物理サーバ102の運用管理をするために必要なネットワークである。NW-SW104は、業務用のネットワークに属しており、各物理サーバ102上で実行される業務用アプリケーションが使用するネットワークである。
管理サーバ101上では、制御部110による処理が実行され、制御部110の処理に伴って管理テーブル群111が参照および更新される。
図2は、管理サーバ101の構成を示す。管理サーバ101は、演算を処理するCPU(Central Processing Unit)201、CPU201で演算するプログラムや、プログラムの実行に伴うデータを格納するメモリ202、プログラムやデータを格納するストレージ装置とのディスクインタフェース203、IP(Internet Protocol)ネットワークを介した通信のためのネットワークインタフェース204から構成される。
図2では、ネットワークインタフェース204及びディスクインタフェース203を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、管理サーバ101は、例えば、管理用ネットワーク103と業務用ネットワーク104への接続は、各々異なるネットワークインタフェース204を用いることができる。
メモリ202には、制御部110および管理テーブル群111が格納されている。制御部110は、契機監視部210(図20参照)、ログ取得指示部211(図21参照)、マーキング指示部212(図22参照)、ログ収集部213(図24参照)、傾向分析部214(図25参照)、及びシステム構成提案部215(図26参照)を有する。
管理テーブル群111は、物理サーバ管理テーブル221(図11参照)、仮想化機構管理テーブル222(図12参照)、仮想サーバ管理テーブル223(図13参照)、OS管理テーブル224(図14参照)、業務管理テーブル225(図15参照)、システム管理テーブル226(図16参照)、契約管理テーブル227(図17参照)、マーキング規則管理テーブル228(図18参照)、及び課金情報管理テーブル229(図19参照)を有する。
各テーブルへの情報収集は、標準インタフェースや情報収集用プログラムを使用した自動収集でも良いし、手動で利用者に入力させても良い。ただし、規則や方針といった情報のうち物理的要件や法律の要請で限界値が決定されるもの以外は、利用者に予め入力させる必要がある。この場合、入力用のインタフェースを備える必要がある。また、利用者の方針によって、限界値に至らない運用をする場合も、同様に条件を入力するインタフェースが必要である。
図3は、物理サーバ102の構成を示す。物理サーバ102は、演算を処理するCPU301、CPU301で演算するプログラムや、プロググラムの実行に伴うデータを格納するメモリ302、プログラムやデータを格納するストレージ装置と情報の授受を行うためのディスクインタフェース304、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース303、CPU301に対する電源制御や各インタフェース303、304に対する制御を行うBMC(Baseboard Management Controller)305を有する。
また、メモリ302には、ソフトウェア資源として、プログラム311と業務アプリケーション321およびOS311の他に、後述するように、仮想サーバと仮想化機構が格納されている。仮想化機構は、物理サーバ102のハードウェア資源であるCPU301などを仮想化したものである。仮想サーバは、仮想化機構で仮想化された仮想サーバである。OS311は、仮想サーバは、OS311上で動作し、仮想サーバは、仮想化機構上で動作する。
この物理サーバ102においては、メモリ302上のOS311がCPU301によって実行され、OS311の下で、業務を提供するアプリケーション321や監視プログラム322などが動作する。この際、物理サーバ102は、アプリケーション321や監視プログラム322に従って、監視対象などから物理的な稼働情報であるログ情報として、例えば、消費電力を含む電力量などの電力情報、電圧情報、環境温度などの温度情報、電動ファンの回転数を含むファン情報などを収集する。
図3では、ネットワークインタフェース303及びディスクインタフェース304を、それぞれ代表して一つずつ示しているが、各々が複数ある。このため、物理サーバ102は、例えば、管理用ネットワーク103と業務用ネットワーク104への接続は、各々異なるネットワークインタフェース303を用いることができる。
図4は、BMC305の構成を示す。BMC305は、演算を処理するCPU401、CPU401の演算に伴うデータを格納するメモリ402、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース403、CPU401の演算前後のデータを格納するデータ格納領域404、CPU401の演算に用いるプログラムを格納するプログラム格納領域405を有する。
BMC305は、特定用途に特化した機能のみが実装されていることが多いが、BMC305にログ情報を追記する仕組みを構築することができる。例えば、ファームウェアを更新する際に、プログラム格納領域405に格納されているプログラムに、ログ情報を追記するための機能を追加することで、BMC305にログ情報を追記する仕組みを構築することができる。
なお、従来のBMC305を利用し続ける場合や、制御インタフェースが公開されてないBMC305の場合には、図6や図7に示すように、BMC305の内外に、ハードウェア的にデバイス、例えば、プログラムにしたがってログ情報を収集するCPUなどを有するデバイスを追加することよって、ログ情報を追記する仕組みを構築することができる。
図5は、システム稼働情報管理方法の動作概略を示す。まず、(1)管理サーバ101は、定期監視またはイベント(サーバ間業務移動指示など)を契機501として、ソフトウェア資源の変更に伴う処理を開始する。
(2)次に、管理サーバ101は、ソフトウェア資源(業務アプリケーション321、OS311、仮想サーバ、仮想化機構)のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション321を他の物理サーバに移動させる変更が生じた場合、複数の物理サーバ102の中から、変更元あるいは移動元となる物理サーバ102を抽出し、抽出した移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスなどを収集502する。
この際、管理サーバ101は、識別子と同時に電力情報を取得することで、業務アプリケーション321の移動直前の状況をログ情報に残すことが可能となり、これにより高精度な稼働情報のマッピングが可能となる。
(3)次に、管理サーバ101は、収集した電力情報に、収集した識別子として、IPアドレスなど記録(マーク)503する。
(4)この後、管理サーバ101は、契機501に伴う制御を移動元の物理サーバ102と移動先の物理サーバ(他の物理サーバ)102へ指示する。これにより、移動元の物理サーバ(サーバA)102で稼働していた業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動する。
(5)その後、管理サーバ101は、業務アプリケーション321を特定する識別子、例えば、IPアドレスなどを、移動先の物理サーバ(サーバB)102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動したことをログ情報として残す。
これにより、ソフトウェア資源(業務アプリケーション321、OS311、仮想サーバ、仮想化機構)のうち、例えば、業務アプリケーション321で使用した可観測な物理量、例えば、電力情報である電力量を正確に知ることが可能となる。
業務アプリケーション321や仮想サーバが使用した稼働情報については、OS311や仮想化機構が稼働情報または割当情報として正確に把握している。そのため、全体における特定業務アプリケーションまたは特定仮想サーバが利用した使用量を両者で按分し、按分されたものと、本発明で実現する物理的な稼働情報として記録されたログ情報とを正確に突き合わせることによって、特定業務アプリケーションまたは特定仮想サーバが利用した物理量を計算することが可能になる。これにより、例えば、業務毎の消費電力量を正確に知ること出来る。
また、管理サーバ101が、各物理サーバ102の取得による物理量(例えば、電力量)とその閾値(kW)について監視し、各物理サーバ102の取得による物理量が閾値を跨いだとき、例えば、電力量が閾値を超えたとき、あるいは、電力量が閾値を下回ったときを契機として、そのとき稼働していた業務アプリケーション321や仮想サーバを把握することが可能になる。
すなわち、管理サーバ101は、各物理サーバ102からそれぞれログ情報を収集し、収集したログ情報のうちいずれかのログ情報が、予め設定した閾値を跨いだことを契機として、複数の物理サーバ102のうち、閾値を跨いだログ情報の収集先となる物理サーバ102のログ情報に、閾値を跨いだログ情報の収集のために稼働しているソフトウェア資源を特定する識別子または閾値を跨いだログ情報を記録することができる。これにより、物理視点で、正確なログ情報(業務稼働ログ)を把握することができる。
この際、取得による物理量が閾値を跨いだ物理サーバ102に対して、別の物理サーバ、別のシャーシ(ブレードサーバの場合)、別のラック、別のブレーカ、別のフロア、別のセンタへの移動計画を立案することが可能になる。
また、ログ情報に識別子をマーキング(記録)するに際しては、障害、例えば、ハードウェア障害、ソフトウェア障害、性能障害の発生を契機としてマーキングしたり、障害予兆や性能障害予兆でマーキングしたりすることで、以下のようなメリットが生じる。
具体的には、ハードウェア障害を契機として、ソフトウェア情報(識別子など)をハードウェアログにマーキングすると、その時点で稼働していたソフトウェアを記録することで、どのソフトウェアをリカバリすれば良いかを判断することができる。
ソフトウェア障害を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、物理的な計算機資源が枯渇していたことが原因なのか判定出来る。
ソフトウェア障害を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、仮想サーバを利用する環境で、障害がユーザプログラム起因で発生したものか否かを特定出来る。これにより、ユーザが起こした障害の場合は、ユーザに課金するが、計算機環境側が障害を起こした障害の場合は、ユーザに課金しない、といった厳密な運用が可能となる。すなわち、リスクの適正な分散が可能となる。
性能障害を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。
性能障害を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務(ソフトウェア資源)がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。
障害予兆を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、ソフトウェアログ゛を監視することで、障害によるシステムダウンが発生する前に、別のサーバへ移動する、といった対策を講じることが可能になる。温度が異常であれば、その周辺の温度が高くなっていると判断し、別のラックやフロアへ移動したり、周辺の温度を取得して移動先を決めたりする、といった対策を講じることが可能になる。
障害予兆を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、業務の優先順位や移動のし易さなどから、退避の優先順位付けを行い、優先順位の高い業務をより高確率に継続させるよう対策を講じることが可能になる。
性能障害予兆を契機として、ハードウェア情報(識別子など)をソフトウェアログにマーキングすると、どの物理的な計算機資源がどれだけ枯渇していたのか判定出来る。物理的な計算機資源が枯渇していなければ、対策は仮想化機構より上位で実施すれば良いと判断することが出来る。
性能障害予兆を契機として、ソフトウェア情報(識別子)をハードウェアログにマーキングすると、どの業務がどれくらい稼動しているかを特定出来る。これにより、同一サーバへ同居させる業務の組み合わせを調整し、性能障害を回避する対策を講じることが可能になる。また、業務の優先順位に応じて、別のサーバへ業務を退避させる、といった対策を講じることが可能になる。
図6は、BMC305の異なる実現形態を示す。このBMC305は、ログ制御機能601を有する他は、図4のものと同様である。ログ制御機能601は、データ格納領域404へ格納されているログ(ログ情報)へマーキングする機能を持つ。なお、ログ制御機能601に、データ格納領域404からログを収集し、収集したログにマーキングした後、ログ制御機能601内にデータを格納するか、あるいは収集したログを管理サーバ101へ送信する機能を付加することもできる。
図6におけるBMC305は、図4に示すBMC305にハードウェアを追加することで実現できる形態であって、過去資産の流用が可能なため、安価に実現することが出来る。また、法規制などの要請により、ログに追記しない形態で保存する必要があって、BMC305から、追加されたハードウェアを外す場合には、データ格納領域404へ元のログは残す実現方式が可能となる。
図7は、物理サーバ102の異なる実現形態を示す。ログ制御機能701は、BMC305へ格納されているログへマーキングする機能を持つ。なお、ログ制御機能701に、BMC305からログを収集し、収集したログに、マーキングした後、ログ制御機能701内にデータを格納するか、あるいは、収集したログを管理サーバ101へ送信する機能を付加することもできる。
図7における物理サーバ102は、図6におけるBMC305の実現形態と同様、過去資産を流用することで安価に実現できる。また、ログ制御機能701と同等の機能が管理サーバ101にて実現されていても、同様の効果を得ることが出来る。
図8は、複数の物理サーバ102の代わりに、物理サーバと略同一の機能を有する複数のブレードサーバ802を用い、各ブレードサーバ802をサービスプロセッサ801に接続したときの計算機システムの構成図を示す。
管理サーバ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)を設定することが可能である。
サービスプロセッサ801は、ブレードサーバ802のシャーシ803への挿抜(ブレードサーバ802の追加、削除)やブレードサーバ802の障害を検知し、管理サーバ101へアラートを通知する。
NW-SW103は、管理用のネットワークであり、OSやアプリケーションの配信や電源制御といったブレードサーバ103の運用管理をするために必要なネットワークである。NW-SW104は、業務用のネットワークに属しており、ブレードサーバ802上で実行される業務用アプリケーションが使用するネットワークである。
図9は、サービスプロセッサ801の構成を示す。図9において、サービスプロセッサ801は、演算を処理するCPU901、CPU901で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ902、プログラムやデータを格納するストレージ装置とのディスクインタフェース904、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース903、ログを制御する機能を持つログ制御機能905を有する。
ただし、ログ制御機能905は、ブレードサーバ802内やブレードサーバ802のBMC1005(図10参照)内や管理サーバ101にて実現されている場合は、必ずしも必要とはしない。
図10は、ブレードサーバ802の構成を示す。図10において、ブレードサーバ802は、演算を処理するCPU1001、CPU1001で演算するプログラムや、プロググラムの実行に伴いデータを格納するメモリ1002、プログラムやデータを格納するストレージ装置とのディスクインタフェース1004、IPネットワークを介して、外部と通信を行うためのネットワークインタフェース1003、電源制御や各インタフェースの制御を行うBMC(Baseboard Management Controller)1005を有する。
ブレードサーバ802は、メモリ1002上のOS311がCPU1001によって実行されることで、ブレードサーバ802内のデバイス管理を行っている。OS311の下で、業務を提供する業務アプリケーション321や監視プログラム322などが動作する。BMC1005は、サービスプロセッサ801と内部ネットワークを介して接続されており、稼働情報や障害情報を通知する機能や、電源制御の指示を受け付け実行する機能を持つ。また、本実施例におけるブレードサーバ802は、ログの取得・ログの送信・ログへのマーキングを実行する機能を持つ。
図11は、物理サーバ管理テーブル221を示す。図11において、物理サーバ102やブレードサーバ802を管理するための物理サーバ管理テーブル221のカラム1101には、物理サーバ識別子が格納しており、本識別子によって各物理サーバを一意に識別することができる。カラム1101へ格納するデータは、本テーブル221で使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。
カラム1102には、UUID(Universal Unique IDentifier)が格納されている。UUIDは、重複しないように形式が規定された識別子である。そのため、各サーバ102または802に対応して、UUIDを保持することにより、確実なユニーク性を保証する識別子となり得る。そのため、カラム1101に格納されている識別子は、サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。
ただし、カラム1101には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1101のサーバ識別子には、MACアドレス、WWN(World Wide Name)などを用いても良い。
カラム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)アドレスが格納されている。
カラム1104には、物理サーバ102のモデルが格納されている。このモデルは、インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。
カラム1105には、物理サーバ102の構成に関する構成情報が格納されている。例えば、物理サーバ102の構成に関する構成情報として、プロセッサ(CPU301、CPU1001)のアーキテクチャ、シャーシ803やスロットなどの物理位置情報、特徴機能(ブレード間SMP:Symmetric Multiprocessing、HA(High Availability)構成などの有無)が格納されている。カラム1104も同様、インフラに関わる情報である。
カラム1106には、物理サーバ102の性能情報が格納されている。カラム1104も同様、インフラに関わる情報である。
カラム1107には、ログ情報が格納されている。このカラム1107には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
カラム1108には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1107とカラム1108から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
インフラに関わる情報は、物理サーバ102の移動先を提案する場合に、移動が可能か否かを判定するために必要である。
図12は、仮想化機構管理テーブル222を示している。仮想化機構管理テーブル222は、どのような仮想化機構で、どんなログがどこに格納されていて、どのようにすればアクセス可能か、といった情報を管理するものである。
カラム1201には、仮想化機構識別子が格納されており、本識別子によって各仮想化機構を一意に識別することができる。カラム1201へ格納するデータは、本テーブルで使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで、入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。
カラム1202にはUUIDが格納されている。UUIDは、仮想化機構識別子として、有力な候補である。
カラム1203には、仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。
カラム1204には、仮想化機構設定情報が格納されている。仮想化機構設定情報は、仮想化機構へ接続するために必要なIPアドレスなどである。
カラム1205にはログ情報が格納されている。カラム1205には、どのような情報をログとして保持し、どこへ保持されているか、が格納される。
カラム1206には、ログ情報操作インタフェースが格納されている。ログを操作するときに接続するプログラムやインタフェースに関する情報が格納されている。
カラム1205とカラム1206から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
図13は、仮想サーバ管理テーブル223を示している。仮想サーバ管理テーブル223は、どのようなシステム構成を定義した仮想サーバで、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。
カラム1301には、仮想サーバ識別子が格納されており、本識別子によって各仮想サーバを一意に識別することができる。
カラム1302には、UUIDが格納されている。カラム1301に格納されている仮想サーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1301には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。
例えば、カラム1301の仮想サーバ識別子には、仮想MACアドレス、仮想WWNなど(カラム1372へ格納)を用いても良い。また、OS311によっては、独自にユニーク性を保つための識別子を採用している場合があるが、この場合は、OS311が採用しているIDを使っても良いし、ユニーク性を確保するために独自に保持してもかまわない。
カラム1303(カラム1371〜カラム1373)には、仮想I/Oデバイスに関する情報が格納されている。カラム1371には、仮想デバイス種別が格納されている。例えば、仮想HBAや仮想NICなどが格納される。カラム1372には、仮想HBAの識別子である仮想WWN、仮想NICの識別子である仮想MACアドレスが格納されている。カラム1373には、仮想I/Oデバイスのモードが格納されており、このモードには、共有モードと占有モードがある。
仮想デバイスには、使用する物理デバイスを共有で使用するモードと、占有で使用するモードが存在する。共有の場合、他の仮想デバイスが物理デバイスを同時に使用する。占有モードの場合、物理デバイスをその仮想デバイスが単独で使用する。
カラム1304には、仮想サーバの仮想化種別が格納されている。仮想化種別とは、仮想化製品や仮想化技術を示し、制御インタフェースや機能差が明確に判別出来るものである。バージョン情報を含めても良い。独自に管理機能を持つ場合は、その管理機能の名称や管理インタフェースを含めても良い。インフラに関する情報であり、性能や構成可能なシステム限界など、サーバ移動の可否や課金に関わる情報である。
カラム1305には、仮想サーバの性能情報が格納されている。カラム1304も同様、インフラに関わる情報である。
カラム1306には、ログ情報が格納されている。カラム1306には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
カラム1307には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1306とカラム1307から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
インフラに関わる情報は、物理サーバ102の移動先を提案する場合に、移動が可能か否かを判定するために必要である。
図14は、OS管理テーブル224を示している。OS管理テーブル224は、どのようなOS311で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのデーブルである。
カラム1401には、OS識別子が格納されており、本識別子によってOSを一意に識別することができる。
カラム1402には、UUIDが格納されている。カラム1401に格納されているOS識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1401には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1401のOS識別子には、OS設定情報(カラム1404へ格納)を用いても良い。
カラム1403は、OS設定情報が格納されている。例えば、IPアドレスやホスト名、ID、パスワード、ディスクイメージなどが格納されている。ディスクイメージは、設定前後のOSが物理サーバ102または仮想サーバ2302へ配信されたシステムディスクのディスクイメージを指す。カラム1404へ格納するディスクイメージに関する情報は、データディスクを含めても良い。
カラム1405には、ログ情報が格納されている。カラム1405には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
カラム1406には、ログ情報を操作するインタフェースに関する情報が格納している。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1405とカラム1406から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
図15は、業務管理テーブル225を示している。業務管理テーブル225は、どのようなソフトウェア資源(例えば、業務アプリケーション321)で、どのような設定がされていて、どんなログがどこに格納されていて、どのようにアクセス可能か、といった情報を管理するためのテーブルである。
カラム1501には、業務識別子が格納されており、本識別子によって業務、例えば、業務アプリケーション321を一意に識別することができる。
カラム1502には、UUIDが格納されている。カラム1501に格納されている業務識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム1501には、システム管理者がサーバを識別する識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、UUIDを使うことが望ましいものの必須とはならない。例えば、カラム1501のサーバ識別子には、業務設定情報(カラム1504へ格納)を用いても良い。
カラム1503には、業務種別が格納されており、使用するアプリケーションやミドルウェアといった業務を特定するソフトウェアに関する情報が格納されている。業務で使用する論理的なIPアドレスやID、パスワード、ディスクイメージ、業務で使用するポート番号などが格納されている。ディスクイメージは、設定前後の業務が物理サーバ102または仮想サーバ2302上のOS311へ配信されたシステムディスクのディスクイメージを指す。カラム1504へ格納するディスクイメージに関する情報は、データディスクを含めても良い。
カラム1505には、ログ情報が格納されている。カラム1505には、どのような種類の情報を格納したログが、どの場所に格納されているか、に関する情報が格納されている。
カラム1506には、ログ情報を操作するインタフェースに関する情報が格納されている。この情報は、どのような種類の情報に対して、どのようなインタフェースで制御出来るのかを示している。カラム1505とカラム1506から得られる情報を使い、本発明で実現するログへのマーキングが可能となる。
図16は、システム管理テーブル226を示している。システム管理テーブル226は、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224及び業務管理テーブル225で管理される、物理サーバ102、仮想化機構2301、仮想サーバ2302、OS331及び業務321の組み合わせによるシステム構成を管理し、システム変更やサーバ移動のステータス及びログ制御を管理するためのテーブルである。
カラム1601には、システム識別子が格納しており、本識別子によって業務、例えば、業務アプリケーション321を一意に識別することができる。
カラム1602には、UUIDが格納されている。カラム1603からカラム1605の全部または一部の組み合わせで実現しても良いし、独自に生成しても良い。少なくとも、管理サーバ101が管理する範囲で一意である必要がある。
カラム1603には、物理サーバ識別子1101が格納され、カラム1604には、仮想化機構識別子1201が格納され、カラム1605には、仮想サーバ識別子1301が格納され、カラム1606には、OS識別子1401が格納され、カラム1607には、業務識別子1501が格納されている。
図面には記載していないが、ラックやフロア、コンセントボックス、ブレーカ、センタ、HA構成の有無、ネットワークインフラ情報、電力グリッド、ネットワーク結線関係、ネットワークスイッチ、ファイバチャネルスイッチ、各スイッチの収容量、ネットワーク帯域などを管理することで、それらにまたがったシステムの移動についても本発明の効果を得ることが可能になる。
カラム1608には、システム変更ステータスが格納されている。カラム1608には、なにをどこへ移動するのか、移動前・移動中・移動後、といったステータスが格納される。
カラム1609には、ログ取得ステータスが格納されている。ログ取得ステータスは、ログ取得を要請する対象でのログ取得が完了しているかどうかを管理するためのものである。
カラム1610には、マーキングステータスが格納されている。マーキングステータスは、ログへマーキングを要請する対象へマーキングが完了しているかどうかを管理するためのものである。マーキングステータスは、本発明における重要ポイントである。
カラム1611には、ログ収集ステータスが格納されている。ログ収集ステータスは、対象からログを収集する場合に、ログ収集が完了しているかどうかを管理するためのものである。管理サーバ101内やBMC305の内外デバイス、サービスプロセッサ801内へログを収集する際に、ステータスを管理する必要がある。
図17は、契機管理テーブル227を示している。契機管理テーブル227のカラム1701には、契機識別子が格納されている。カラム1702には、契機の内容が格納されている。カラム1702には、管理サーバ101へサーバ移動などの動作が入力される場合もあるが、契機を検出して自動実行するときの動作が入力される場合もある。
後者の場合、動作に伴うイベント通知が契機となる。契機としては、以下に挙げるような動作が考えられるが、システム管理テーブル226のシステム構成に関するカラムが変更される場合は、全て契機と成り得る。
仮想サーバをライブマイグレーションする場合、仮想サーバ2302以上(仮想サーバ2302、OS321、業務321、図23参照)は、稼働する物理サーバ102を移動(変更)することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
LU(Logical Unit)を接続する物理サーバ102が変更となる場合、OS321と業務321は稼働する物理サーバ102を移動(変更)することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
また、LUを接続する仮想サーバ2302が変更となる場合、仮想化機構2301または仮想サーバ2302以上(OS321、業務321を含む)が移動することになり、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。
別の業務のディスクイメージをデプロイ(配信、デプロイメント)する場合、LUを接続するサーバを変更する場合と同様である。
インタフェースカードの固有値(WWNやMACアドレス)を書き換える場合、LUを接続する物理サーバ102を変更する場合と同様である。
Java(登録商標)アプリケーションをデプロイする場合、業務321内のプロセス(論理サーバ)が追加・削除・変更されるため、業務321およびプロセスの識別子を物理サーバ102の稼働情報ログへマーキングする。
業務ソフトウェアのIPアドレスを変更する場合、稼働する物理サーバ102または仮想サーバ2302を移動(変更)するように見なすことが出来る。
この場合も、物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ以外のどれでも良く、複数でも良い。
ソフトウェア起動通知、OS起動通知、仮想サーバ起動通知、仮想化機構起動通知で、稼働しているシステム情報を取得し、システム管理テーブル226との差異を調査し、差異がある場合、物理サーバ102の移動(変更)が発生している。物理サーバ102の稼働情報ログへマーキングが実施される。マーキングする識別子は、物理サーバ102以外のどれでも良く、複数でも良い。
この際、管理サーバ101は、例えば、ソフトウェア資源がある物理サーバ102から、他の物理サーバ102に移動する場合、他の物理サーバ102が起動したことを条件に、他の物理サーバ102に属するソフトウェア資源と他の物理サーバ102の構成を示すハードウェア構成情報との間に差異があるか否かを判定し、差異があるときには、その旨の情報を、識別子とともに、他の物理サーバ102のログ情報に記録することで、記録された情報を基に正しい構成に修正したり、あるいは、マーキングに失敗したことを把握したりすることができる。
また、上記に挙げる契機で、物理サーバ102の識別子を物理サーバ102以外の稼働ログへマーキングしても良い。これにより、論理的な稼働情報(業務321、OS311、仮想サーバ2302、仮想化機構2301)を記録したログから、正確かつ簡単に物理サーバの稼働情報を参照することが可能である。記録先のログは全てでも良いし、一部でも良い。
監視対象の物理量(例えば消費電力量)が設定した閾値を跨ぐ場合、論理的な稼働情報を記録したログへ、物理サーバ識別子をマーキングする。また、測定した物理量を同時にマーキングしても良い。この契機と同様のものとして、ハードウェアやソフトウェアの障害情報の通知、性能障害情報の通知、警告(障害予兆、性能障害含む)の通知などが挙げられる。
図18は、マーキング規則管理テーブル228を示している。マーキング規則管理テーブル228は、どんな契機で、どのログに、なんの識別子をマーキングするか、を管理するためのテーブルである。
カラム1801には、規則識別子が格納され、カラム1802には、契約識別子(カラム1701)が格納され、カラム1803には、マーキングする対象の階層が格納され、カラム1804には、マーキングする対象となるログまたはログ種別が格納され、カラム1805には、マーキングする識別子が格納される。
マーキングの方法としては、ログ内の最新情報部にマーキングする識別子を追記する方法を用いることができる。また、マーキングの開始と終了のみを追記しても良いし(システムが変更されたときのみマーキング)、その後のログ全てにマーキングしても良い。
図19は、課金情報管理テーブル229を示している。課金情報管理テーブル229は、課金に関する情報を管理するテーブルであり、運用コストが下がるシステム構成を提案するために使用される。
課金情報管理テーブル229のカラム1901には、課金情報識別子が格納され、カラム1902には、課金対象が格納されている。格納される情報は、消費電力量のような物理量でも良いし、仮想サーバや物理サーバ102といったインフラ情報、トランザクション保証のレベルといったSLA(Service Level Agreement)情報でも良い。
カラム1903には、課金情報が有効となる条件が格納されている。時刻やシステム構成、インフラ情報(HA構成の有無や種類、ネットワーク帯域、地域など)である。カラム1904には、単価が格納されている。
課金情報管理テーブル229を利用するに際して、物理稼動情報を記録したログを参照し、温度の高いサーバといったIT機器および負荷のかかったファシリティを検出した場合、課金情報管理テーブル229の条件や単価を操作し、一時的に価格を上げ、需要を抑えるような価格操作によって、より効率の良い運用(例えば、該当サーバの需要は下がり、利用率が下がることで温度を下げる効果がある)を管理者に提供することが出来る。
また、計算機資源を利用するユーザにとってみれば、温度が高いサーバを使うことは、温度上昇によるハードウェア障害のリスクが高いことになるが、価格の安い計算機資源を選ぶことで、同時に温度によるハードウェア障害のリスクを回避することも可能となる。
図20は、契機監視部210の処理フローチャートを示す。
契機監視部210は、管理サーバ101のCPU201によって処理を開始する。契機監視部210は、契機の発生を監視し、発生した契機についてログへマーキングするか否かを判定し、ログへマーキングする場合は、ログを取得およびマーキングを指示、またはログを収集およびマーキングする指示する。
まず、ステップ2001で、管理サーバ101は契機の発生を監視し、契機が発生した場合、ステップ2002へ進む。
ステップ2002で、管理サーバ101は、契機を基に契機管理テーブル227を参照する。
ステップ2003で、管理サーバ101は、契機管理テーブル227を参照した結果を基に、ログへマーキングするか否かを判定し、マーキングする場合、ステップ2004へ進み、マーキングしない場合、ステップ2001へ進む。
ステップ2004で、管理サーバ101は、システム管理テーブル226を参照し、マーキングする旨、システム管理テーブル226を変更し、処理を完了する。
契機としては、ユーザ操作によるもの(GUI操作、CLI発行など)、イベント発生によるもの(ハードウェア障害情報の書き込み及び通知など)、アラート通知によるもの(閾値越え、障害通知など)がある。
図21は、ログ取得指示部211の処理フローチャートを示す。
ログ取得指示部211は、管理サーバ101のCPU201によって処理を開始する。この処理へ移行する前提として、契機監視部210が「ログへマーキングする」と判断し、契機を契機監視部210から受け取っていることが挙げられる。また、元々のログを取得する契機と時間的に近い場合、ログ取得指示部211は、ログ取得を指示しなくても良い。
まず、ステップ2101で、ログ取得指示部211は、契機管理テーブル227を参照する。
ステップ2102で、ログ取得指示部211は、契機管理テーブル227を参照した結果を基に、システム管理テーブル226を参照し、次に挙げる、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225のうち、全てのテーブルまたは契機やログのマーキングに関連するテーブルのみを参照する。
次に、ステップ2103において、ログ取得指示部211は、ステップ2102で参照したテーブルの内容を基に管理対象へログ取得を指示する。
この後、ログ取得指示部211は、ステップ2104において、システム管理テーブル226を更新し、処理を完了する。
図22は、マーキング指示部212の処理フローチャートを示す。
マーキング指示部212は、管理サーバ101のCPU201によって処理を開始する。この処理へ移行する前提として、マーキング対象のログと追記する識別子は確定していることとしている。
まず、ステップ2201で、マーキング指示部212は、マーキング規則管理テーブル228を参照する。
ステップ2202で、マーキング指示部212は、マーキング規則管理テーブル228を参照した結果を基に、マーキング対象のログ情報を保持するテーブルを参照する。参照するテーブルは、物理サーバ管理テーブル221、仮想化機構管理テーブル222、仮想サーバ管理テーブル223、OS管理テーブル224、業務管理テーブル225のうち、全てでも良いし、マーキング対象となるもののみでも良い。
ステップ2203で、マーキング指示部212は、マーキング対象ログへ識別子を追記する。
ステップ2204で、マーキング指示部212は、マーキング対象ログへ識別子を追記した内容を基にシステム管理テーブル226を更新する。
本実施例においては、ソフトウェア資源のうち少なくともいずれか一つ変更になった場合、例えば、稼働している業務アプリケーション321を他の物理サーバに移動させる変更が生じた場合、管理サーバ101は、複数の物理サーバ102の中から、変更元あるいは移動元となる物理サーバ102を抽出し、抽出した移動元の物理サーバ102から、移動元の物理サーバ102の収集によるログ情報(物理稼働ログ)、例えば、電力情報を収集するとともに、移動元の物理サーバ102で稼働していた業務アプリケーション321を特定するための識別子、例えば、計算機システムで一意となるIPアドレスを収集し、収集した電力情報に、収集した識別子として、IPアドレスなど記録し、その後、移動先の物理サーバ(サーバB)102のログ情報(物理稼働ログ)、例えば、電力情報に記録(マーク)し、業務アプリケーション321が移動先の物理サーバ(サーバB)102へ移動したことをログ情報として残すこととしている。
従って、本実施例によれば、物理サーバのソフトウェア資源が変更されても、物理サーバのログ情報とソフトウェア資源を正確に突き合わせることができ、結果として、計算機資源の使用量を正確に把握することが可能になる。