JP2010250689A - 性能モニタリングシステム、ボトルネック判定方法及び管理計算機 - Google Patents

Abstract

【課題】複数の仮想計算機が物理リソースを共有するシステムで、物理リソースの割当ポリシ、ソフトウェアへの影響を考慮してボトルネックを判定する。
【解決手段】サーバと、サーバに接続されたストレージシステムと、サーバ及びストレージシステムを管理する管理計算機とを備える性能モニタリングシステムであって、サーバ上では、サーバを論理的に分割して作成された、複数の仮想計算機が実行され、管理計算機は、リソース割当ポリシに関する情報を管理し、指定された仮想計算機の論理リソースにボトルネックが発生しているか否かを判定し、ボトルネックが発生している論理リソースの性能が仮想計算機の性能に与える影響を示す性能値を取得し、取得された性能値に基づいて、仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定し、前記仮想計算機に大きいボトルネックが発生したことを通知することを特徴とする。
【選択図】図８

Description

本発明は、仮想計算機システムに関し、複数の仮想サーバの間における性能ボトルネック要因の判定を支援するツールに関する。

近年、ＣＰＵの高性能化にともない、サーバ統合によるコスト削減、運用の柔軟化等を実現するために、１つの計算機を複数のシステムが共有するサーバ仮想化が広く用いられている。

仮想化を実施するシステムでは、一台のサーバ上に複数の仮想サーバを設け、各々独立したＯＳを動作させる。以下では、仮想サーバをＬＰＡＲ（Ｌｏｇｉｃａｌ Ｐａｒｔｉｔｉｏｎ、論理区画）と呼ぶ。

各ＬＰＡＲは一台の物理サーバを分割（時分割、又はＣＰＵコア毎の分割）して使用し、ユーザからはあたかも複数のサーバが独立して存在するように見せることができる。

前述したように、仮想化システムでは、複数のＬＰＡＲが単一の物理リソース（ＣＰＵ、Ｉ／Ｏデバイス）が共有される。さらに、大規模なシステムでは、ＳＡＮ等によるＩ／Ｏ共有が行われるため、Ｉ／Ｏにおいても単一の物理リソース（ＳＡＮのスイッチ、又はストレージ）が複数のＬＰＡＲによって共有される。

前述したように仮想化を実現するシステムでは、物理リソースと、ユーザが使用する論理リソース（ＬＰＡＲとそれが使用するＩ／ＯデバイスやＣＰＵの組）との間のマッピングが行われ、一対一の対応関係ではなくなる。その結果、論理的なリソースと物理リソースとの対応関係が複雑化し、アプリケーションがどの物理リソースを使用しているかが判りにくくなる。

一方、個々の物理リソース、論理リソースの性能を測定するツールは各種存在するが、前述した仮想化システムでは、測定された大量のデータのどこを見ればよいかがわかりにくい。

以上の原因によって、従来の性能評価、又はボトルネック判定手法をそのまま使用することが困難になりつつある。

前述の課題を解決するために、複数サーバでの性能モニタリングに関して、複数のサーバがストレージネットワークを共有するシステムにおいて、各サーバで測定された性能データを元に、物理−論理リソースマッピングを表わすシステム構成管理表に基づいて、各サーバが物理リソースをどれだけ使用しているかを表示する管理プログラムを備える方法がある（例えば、特許文献１参照）。

特許文献１に記載されている方法を使用することによって、複数の仮想サーバが一つの物理リソースを共有している環境において、どの仮想サーバがどの物理リソースを占有しているかを判定することができる。

しかし、複数のサーバが物理リソースを共有する場合、ベストエフォート（使った者勝ち）では、各サーバがどれだけ物理リソースを使用するか制御できないため、性能管理ができない問題がある。

前述した問題に対して、共有するリソースに関して割当ポリシを設定し、各サーバのリソース使用量を制御することが行われている。割当ポリシとしては、リソース割当率、最大リソース使用量の指定、及び優先度指定等、種々の方式が使用される。

例えば、ストレージネットワークで各サーバに物理リソース使用量を割り当てるときに、動的に変化する仮想計算機のストレージリソース使用状況を定期的にモニタリングし、リソース割当量を再検査し、余分なリソースを回収し、優先度にしたがって再割当する方法がある（例えば、特許文献２参照）。

また、仮想化システムでは、ＸｅｎのＤｏｍａｉｎ０等の特定の仮想サーバが他の仮想サーバのＩ／Ｏ処理を代行する。ある仮想サーバの通信処理が増加した場合、前記特定の仮想サーバのＣＰＵ処理が同時に増加するため、システムのボトルネック判定を複雑化する要因となる。

前述の問題に対して、前記特定の仮想サーバに対するＩ／Ｏ処理の影響を考慮し、リソース使用量を計算する方法がある（例えば、特許文献３参照）。

さらに、ストレージシステムにおいて、アクセスパスの接続経路における物理ポートのトラフィック量をモニタリングすることによって、物理リソースがネックになっている場合、空きリソースを持つパスを表示し、パス切り替えをナビゲーションする方法がある（例えば、特許文献４参照）。

特開２００５−６２９４１号 特開２００５−３０９６４４号 特開２００８−２１７３３２号 特開２００４−７２１３５号

前述した従来例は、各ＬＰＡＲがＩ／Ｏ機器、ＣＰＵ等の物理リソースをどれだけ使用しているかを示す使用状況を把握することができる。

しかし、以下に示す理由によって、従来技術で物理リソースの使用状況をモニタリングするだけでは、システムのどの部分が性能的に問題あるかを明らかにすることが困難である。

（１）論理リソースの割当量を限界まで使用してボトルネックとなるＬＰＡＲの判断が困難。

複数ＬＰＡＲが物理リソースを共有し、当該物理リソース使用量が割当ポリシによって制限されている場合、１００％使用されていない物理リソースでもボトルネックになっている可能性がある。

例えば、２つのＬＰＡＲがあるシステムにおいて、ＬＰＡＲ１に割り当てられたリソース使用量が１００％で使い切られているのに対して、ＬＰＡＲ２に割り当てられたリソース使用量には余裕がある場合が考えられる。前述のような場合、物理リソースのリソース使用量は１００％では無いが、ＬＰＡＲ１にとっては該当するリソースの使用量をこれ以上増やすことができないため、ボトルネックになっている。つまり、このような場合におけるボトルネック判断が必要になる。

（２）アプリケーション性能に与える影響がわからない。

前記したように複数の論理リソースがボトルネックになっていると判定された場合、そのうちどれがアプリケーション性能に与える影響が大きいかわからない。そのため、複数のボトルネックの対策の優先度が判定できないため、迅速な対策を採ることができない。

例えば、ストレージデバイスのリソース使用量が１００％になっている場合でも、待ち行列の長さによって、アプリケーションの待ち時間は大きく異なり、性能への悪影響は異なる。このような場合は、待ち行列長が長く、アプリケーションの待ち時間への悪影響が大きい項目を先に対策するべきである。つまり、性能モニタリングシステムが優先度を判定し、システム管理者をナビゲーションする必要がある。

前述した理由によって、従来技術では単純な性能モニタリングは可能であるが、アプリケーション性能が低下している場合に、原因となる箇所を判断することが困難であり、どの部分を対策してよいかがわからないという問題点があった。特に大規模なシステムでは、（１）で判定される論理リソースのボトルネックが非常に多数（数十〜数百）発生する場合があり、（１）による自動判定だけでは、対策箇所を判断することが非常に困難である。

本発明は、物理リソースの割当ポリシ、及びアプリケーション性能に与える影響を考慮して、ボトルネック判定を支援するモニタリングシステムを提供することを目的とする。

本発明の代表的な一例を示せば以下の通りである。すなわち、サーバと、前記サーバに接続されたストレージシステムと、前記サーバ及び前記ストレージシステムを管理する管理計算機とを備える性能モニタリングシステムであって、前記サーバは、第１のプロセッサと、前記第１のプロセッサと接続される第１のメモリと、前記第１のプロセッサと接続される第１のネットワークインタフェースとを備え、前記ストレージシステムは、コントローラと、記憶装置と、前記コントローラと前記記憶装置とを接続するディスクインタフェースとを備え、前記コントローラは、第２のプロセッサと、前記第２のプロセッサと接続される第２のメモリとを備え、前記管理計算機は、第３のプロセッサと、前記第３のプロセッサと接続される第３のメモリと、前記第３のプロセッサと接続される記憶装置とを備え、前記サーバ上では、前記サーバを論理的に分割して作成された、複数の仮想計算機が実行され、前記ストレージシステムは、前記記憶装置を論理的に分割した論理記憶ユニットを前記仮想計算機に提供し、前記仮想計算機から前記論理ユニットまでの経路における物理リソースが、前記仮想計算機の論理リソースとして割り当てられ、前記サーバは、前記論理リソースごとに、前記仮想計算機が測定する前記論理リソースによって使用される物理リソースの使用量に関する時系列データを収集し、前記管理計算機は、前記論理リソースに設定されるリソース割当ポリシに関する情報を管理し、前記サーバから、前記収集された時系列データを取得し、前記取得された時系列データの各時刻において、指定された前記仮想計算機の論理リソースが使用する物理リソースの使用量と、前記リソース割当ポリシとを参照し、前記指定された仮想計算機の論理リソースにボトルネックが発生しているか否かを判定し、ボトルネックが発生している前記論理リソースの性能が前記仮想計算機の性能に与える影響を示す性能値を取得し、前記取得された性能値に基づいて、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定し、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定された場合、前記仮想計算機に大きいボトルネックが発生したことを通知することを特徴とする。

本発明によれば、各仮想計算機が使用する物理リソースにおけるボトルネックの有無を判定する場合、物理リソース使用量が１００％に達していない状態でも、ボトルネックとなっている科捜研算器を判定することができる。

さらに、ボトルネックであると判定された箇所が複数ある場合、各ボトルネック箇所における、仮想計算機への影響が大きい部分を判定することができる。

本発明の第１の実施形態のモニタリングシステムの構成を説明するブロック図である。 本発明の第１の実施形態のストレージアクセスの次に本実施例における物理的な経路を説明するブロック図である。 本発明の第１の実施形態の各ＬＰＡＲのストレージシステム上の論理ボリュームへの接続の論理構成を示す説明図である。 本発明の第１の実施形態の管理用ＬＰＡＲを介したネットワーク通信処理の詳細を示す説明図である。 本発明の第１の実施形態の管理サーバが備えるシステム構成管理表の一例を示す説明図である。 本発明の第１の実施形態の管理サーバが備えるリソース割当ポリシ管理の一例を示す図である。 本発明の第１の実施形態におけるボトルネック箇所報告画面を説明する図である。 本発明の第１の実施形態における物理リソースボトルネック画面を説明する図である。 本発明の第１の実施形態の管理サーバが物理リソース全体の使用状況を収集する処理を説明するフローチャートである。 本発明の第１の実施形態の管理サーバが実行するリソース割当ポリシを考慮した、ボトルネック箇所判定処理を説明するフローチャートである。 本発明の第１の実施形態の管理サーバが実行する、リソース待ち時間を考慮したボトルネック対策の優先順位判定処理を説明するフローチャートである。 本発明の第１の実施形態の管理サーバが実行する、ボトルネック解決処理を説明するフローチャートである。 本発明の第１の実施形態におけるリソース割当ポリシの一例を示す説明図である。 本発明の第１の実施形態の時系列性能データを説明する図である。 本発明の第１の実施形態の変形例１における物理リソースボトルネック画面の表示方法の変形例を説明するフローチャートである。 本発明の第１の実施形態の変形例２におけるリソース待ち時間比の計算方法を示す説明図である。

［第１の実施形態］
以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本発明の第１の実施形態のモニタリングシステムの構成を説明するブロック図である。

モニタリングシステムは、モニタリング対象となるモニタリング対象システム１００、及び管理サーバ２００から構成される。

モニタリング対象システム１００は、複数のサーバ１１０、１２０、ＦＣ−ＳＷ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ）５００、ストレージシステム５５０、ネットワーク１６０、及び、ポリシ管理サーバ１９０から構成される。

サーバ１１０は、ネットワーク１６０を介してポリシ管理サーバ１９０及び管理サーバ２００と接続される。また、サーバ１１０は、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介して、ストレージシステム５５０と接続される。具体的には、ストレージインタフェース（ＨＢＡ：Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）１１４とＦＣ−ＳＷ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈ）５００及びコントローラ（５５１、５５２）（図２参照）を介して、サーバ１１０、１２０とストレージシステム５５０とは互いに接続される。

以下、サーバ１１０の詳細を説明するが、サーバ１２０についても同一の構成である。なお、図中の実線はネットワークの接続関係、点線はデータの流れを示す。

サーバ１１０は、ＣＰＵ１１１、主記憶装置１１２、ネットワークインタフェース（ＮＩＣ：Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１１３、及びストレージインタフェース（ＨＢＡ：Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）１１４を備える。

サーバ１１０は仮想化機構を備え、当該仮想化機構によって複数のＬＰＡＲに論理分割され、各々のＬＰＡＲが仮想サーバとして機能する。

サーバ１１０の主記憶装置１１２は、仮想化を実現するための制御プログラムであるハイパバイザ３５０、並びに各ＬＰＡＲ（管理用ＬＰＡＲを含む）のプログラムであるＬＰＡＲ３００、ＬＰＡＲ３１０、及び管理用ＬＰＡＲ３６０が格納される。前述したプログラムは、ＣＰＵ１１１によって実行される。

ＬＰＡＲ３００、３１０は、ユーザプログラムを実行する仮想サーバである。管理用ＬＰＡＲ３６０は、各ＬＰＡＲ３００、３１０のネットワーク１６０を介した通信機能を担当し、ネットワークＩ／Ｏの仮想化を実現する。具体的には、管理用ＬＰＡＲ３６０は、各ＬＰＡＲ３００、３１０が通信に使用する仮想的なＮＩＣの実現、各ＬＰＡＲ３００、３１０及びＮＩＣ１１３を結ぶ仮想的なスイッチの実現、並びに、ＮＩＣ１１３を介したネットワーク１６０へのＩ／Ｏの実現をサポートする。詳細については、図４を用いて後述する。

ＣＰＵ１１１は、ハイパバイザ３５０を介して、各ＬＰＡＲ３００、３１０を実行する。これによって、ＯＳ、及びアプリケーションを含んだ仮想的なサーバをユーザに提供される。

各ＬＰＡＲ３００、３１０、３６０では、該ＬＰＡＲ３００、３１０、３６０で動作するＯＳ上で、ＯＳモニタリングプログラム３０１、３１１、３６１が実行され、ＯＳやＩ／Ｏの基本的な情報が周期的にモニタリングされる。

さらに、ハイパバイザ３５０も、ハイパバイザモニタリングプログラム３５１が実行され、各ＬＰＡＲ３００、３１０、３６０に割り当てられたＣＰＵ時間等の性能基本情報がモニタリングされる。

ＯＳのモニタリングプログラムの例としては、ＵＮＩＸ（登録商標）系ＯＳのｓａｒ及びｉｏｓｔａｔ、Ｗｉｎｄｏｗｓ（登録商標）系ＯＳのｓｙｓｔｅｍ ｍｏｎｉｔｏｒがある。ハイパバイザのモニタリング機能の例としては、Ｘｅｎ（登録商標）のｘｅｎｔｏｐがある。

前述のモニタリングされた各データは、後述する測定データ収集プログラム２２１によって、ネットワーク１６０を介して管理サーバ２００のストレージシステム２３０に収集される。モニタリングされる情報については、図１４を用いて後述する。

性能データとして、例えば、ストレージアクセススループット（各ＬＰＡＲ３００、３１０、３６０上のＯＳがストレージシステム５５０上に作成された論理デバイスにアクセスするスループット）、ストレージの平均待ち時間（ＯＳ上で計測された、ストレージアクセスの論理デバイス毎の平均待ち時間）、及び、サーバ（１１０）での各ＬＰＡＲ（３００、３１０、３６０）のＣＰＵ（１１１）使用率等がある。

ポリシ管理サーバ１９０は、モニタリング対象システム１００内で動作するＬＰＡＲ（３００、３１０、３６０）が使用する物理リソース（各サーバ１１０、１２０のＣＰＵ、ストレージ１５０、ネットワーク１６０等）の割り当てを管理する。具体的には、ポリシ管理サーバ１９０は、リソース割当ポリシ１９１によって、各ＬＰＡＲ３００、３１０、３６０への物理リソースの割当を管理する。リソース割当ポリシ１９１は、ポリシ管理サーバ１９０によって設定され、また管理される。

リソース割当ポリシ１９１に基づいて、サーバ１１０のＣＰＵ１１１には、ハイパバイザ３５０にＣＰＵリソース割当ポリシ３５２が設定され、ストレージシステム５５０にはＳＡＮリソース割当ポリシ５５１０が設定され、また、ネットワーク１６０内の機器（図示省略）にはネットワークリソース割当ポリシ１６１が設定される。

なお、第１の実施形態におけるポリシ管理の対象は、ＣＰＵの割当時間、ネットワーク帯域、及びストレージシステム５５０内のＳＡＮの帯域である。

管理サーバ２００は、モニタリング機能が動作する計算機であり、ＣＰＵ２１０、主記憶装置２２０、ストレージシステム２３０、表示装置２４０、及びＮＩＣ２５０を備える。

管理サーバ２００は、ＮＩＣ２５０を介して、モニタリング対象システム１００のネットワーク１６０に接続される。

主記憶装置２２０は、制御プログラム２２２、測定データ収集プログラム２２１、表示プログラム２２３が格納する。前述した各プログラムはＣＰＵ２１０によって実行され、これによってモニタリング機能が実現される。

ストレージシステム２３０は、モニタリング対象システム１００で測定され、測定データ収集プログラム２２１によって収集されたモニタデータ２３１、並びに制御プログラム２２２が使用する管理用のデータを格納する。具体的には、ストレージシステム２３０は、管理用のデータとして、システム構成管理表２３２、リソース割当ポリシ２３３、及びリソース待ち時間しきい値２３４を格納する。

システム構成管理表２３２は、各ＬＰＡＲにおける論理リソースと物理リソースとのマッピングを格納する。リソース割当ポリシ２３３は、ポリシ管理サーバ１９０が格納するリソース割当ポリシ１９１と同一のものである。リソース待ち時間しきい値２３４はシステム管理者によって入力される。例えば、システム管理者が表示装置を用いて、リソース待ち時間しきい値２３４を入力する。

管理サーバ２００は、測定データ収集プログラム２２１を実行し、モニタリング対象システム１００内のモニタリングプログラム（ＯＳモニタリングプログラム３０１、３１１、３６１、ハイパバイザモニタリングプログラム３５１）によって測定された性能の時系列データを、ネットワーク１６０経由でストレージシステム２３０上のモニタデータ２３１として蓄積する。

また、管理サーバ２００は、制御プログラム２２２を実行することによって後述する処理が実行され、また、表示プログラム２２３を実行することによって当該処理の結果が表示装置２４０に表示される。なお、表示プログラム２２３は、表示装置２４０からのパラメータ入力処理も実行する。

なお、図１に示す例では、モニタリング対象システム１００は、２つのサーバ１１０、１２０を備えるが、１つ、又は３以上の数のサーバを備えていてもよい。また、図１に示す例では、通常の（ユーザプログラムを実行する）ＬＰＡＲが２つある場合を示しているが、１つ又は３つ以上ＬＰＡＲがあってもよい。

図２は、本発明の第１の実施形態のストレージアクセスの次に本実施例における物理的な経路を説明するブロック図である。

図２の説明において、各サーバ１１０、１２０の内部は、ＣＰＵ１１１、１２１、ＣＰＵ１１１、１１２上で動作するＬＰＡＲ３００、３１０、４００、４１０、４２０、ハイパバイザ３５０、４５０、及びＨＢＡ１１４、１２４のみを示し、その他の構成要素は省略する。

ストレージシステム５５０は、コントローラ５５１、５５２、複数の記憶媒体（図示省略）を備え、当該複数の記憶媒体から複数のＲＡＩＤ Ｇｒｏｕｐを作成する。図２に示す例では、ストレージシステム５５０上には、ＲＡＩＤ Ｇｒｏｕｐ５６０〜５６３が作成されている。

ストレージシステム５５０は、さらに、ＲＡＩＤ Ｇｒｏｕｐ５６０〜５６３上に論理ボリューム（図３参照）を作成する。

各サーバ１１０、１２０はそれぞれＨＢＡ１１４、１２４を介してストレージシステム５５０に接続される。

図２に示す例では、コントローラ５５１、５５２は各々、ポートを備え、当該ポートを介してＦＣ−ＳＷ５００に接続される。具体的には、ＲＡＩＤグループＲＧ００、ＲＧ０１はＣＴＲＬ０コントローラ経由でアクセスされ、また、ＲＧ０２、ＲＧ０３はＣＴＲＬ１経由でアクセスされる。

各ＲＡＩＤ Ｇｒｏｕｐに分散するように論理ボリュームが配置される。図２に示す例では、ＲＧ００（５６０）にはＬＰＡＲ００（３００）がアクセスする論理ボリュームｓｄａ、及びＬＰＡＲ２１（４２０）がアクセスする論理ボリュームｓｄａが作成さている。ＲＧ０１（５６１）にはＬＰＡＲ００（３００）がアクセスする論理ボリュームｓｄｂが作成されている。ＲＧ０２（５６２）にはＬＰＡＲ００（３００）がアクセスする論理ボリュームｓｄｃが作成されている。ＲＧ０３（５６３）にはＬＰＡＲ０１（３１０）がアクセスする論理ボリュームｓｄａ、ＬＰＡＲ１０（４００）がアクセスする論理ボリュームｓｄａ、及びＬＰＡＲ１１（４１０）がアクセスする論理ボリュームｓｄａが作成されている。

図３は、本発明の第１の実施形態の各ＬＰＡＲのストレージシステム５５０上の論理ボリュームへの接続の論理構成を示す説明図である。

図３において、各ＬＰＡＲ３００、３１０、４００、４１０、４２０はｓｄａ等の論理ボリューム９００〜９０６が割り当てられ、論理的には図３に示すように構成される。

各ＬＰＡＲ３００、３１０、４００、４１０、４２０は、２つのポートを介して各論理ボリューム９００〜９０６にアクセスする。ＬＰＡＲ００（３００）を例に詳細を説明すると、論理ボリュームｓｄａ９００、ｓｄｂ９０１はＨＢＡ１１４のポートｈｐｏｒｔ００（１１４Ａ）経由で、ｓｄｃ９０２はＨＢＡ１１４のポートｈｐｏｒｔ０１（１１４Ｂ）経由でアクセスされる。前述のような構成を実現するためには、ＦＣ−ＳＷ５００のポート１はポート５に、ポート２はポート６に接続されなければならない。

また、他のＬＰＡＲ３１０、３５０、４００、４１０、４２０については、図３に示すような構成を実現するためには、ストレージアクセス経路を考慮すると、ＦＣ−ＳＷ５００は図２の点線で示すように接続される必要がある。

図４は、本発明の第１の実施形態の管理用ＬＰＡＲ３６０を介したネットワーク通信処理の詳細を示す説明図である。

以下、管理用ＬＰＡＲ３６０における通信に伴う処理についてネットワーク通信を例に説明する。

各ＬＰＡＲ３００、３１０には、それぞれ、通信を行うための仮想ＮＩＣプログラム３０５、３１５を備える。

仮想ＮＩＣプログラム３０５、３１５は、管理用ＬＰＡＲ３６０上のプログラム（ＯＳ）に対して仮想デバイスとして働き、各ＬＰＡＲ３００、３１０があたかもＮＩＣを備えているように振舞う。仮想ＮＩＣプログラム３０５、３１５は、ハイパバイザ３５０が提供するＬＰＡＲ間通信プログラム３５５を介して、管理用ＬＰＡＲ３６０が備えるネットワーク通信プログラム３６５と通信する。

ネットワーク通信プログラム３６５は、仮想スイッチプログラム３６６と物理ＮＩＣドライバ３６７とを含む。仮想スイッチプログラム３６６は、各ＬＰＡＲ３００、３１０相互間、及び、各ＬＰＡＲ３００、３１０とサーバ１１０外の装置との間の通信のスイッチングを行う。物理ＮＩＣドライバ３６７は、各ＬＰＡＲ３００、３１０がサーバ１１０外の装置との通信を行う時に物理ＮＩＣを介した通信を行う。

前述したように管理用ＬＰＡＲ（３６０）を介した通信処理が必要になる理由は、ＮＩＣ１１３が仮想化機構を備えず、複数のＬＰＡＲ（３００、３１０）からの通信を扱うことが出来ないためである。そのため、管理用ＬＰＡＲ（３６０）上のソフトウェア処理によって、複数のＬＰＡＲ（３００、３１０）が一つのＮＩＣを共有することが可能になる。なお、Ｉ／Ｏアダプタがハードウェアで仮想化機構を備える場合は、各ＬＰＡＲはＩ／Ｏアダプタを直接アクセスすることができ、管理用ＬＰＡＲ３６０を介した処理は行われない。

図５は、本発明の第１の実施形態の管理サーバ２００が備えるシステム構成管理表２３２の一例を示す説明図である。

本実施形態におけるシステム構成管理表２３２は、ＳＡＮを経由してストレージシステム５５０へのアクセスに関して、各ＬＰＡＲの持つ論理リソース（縦軸）毎に、ストレージシステム５５０へのアクセスに使用される物理リソース（横軸）を格納する。つまり、アクセスパスが格納される。

システム構成管理表２３２は、論理リソース２３２１、アクセス時に使用される物理リソース２３２２を含む。

論理リソース２３２１は、各ＬＰＡＲがアクセスする論理ボリュームを識別するための識別子を格納する。アクセス時に使用される物理リソース２３２２は、論理リソース２３２１に対応するＬＰＡＲからストレージシステム５５０上の論理ボリュームへのアクセス時に使用される物理リソースを格納する。

具体的には、アクセス時に使用される物理リソース２３２２は、ＣＰＵ２３２２１、ＨＢＡ２３２２２、ＨＢＡポート２３２２３、ＦＣ−ＳＷポート２３２２４、ＦＣ−ＳＷ２３２２５、ＦＣ−ＳＷポート２３２２６、ストレージポート２３２２７、コントローラ２３２２８、及びＲＡＩＤ Ｇｒｏｕｐ２３２２９を含む。

ＣＰＵ２３２２１は、ＬＰＡＲが動作するＣＰＵを識別するための識別子を格納する。ＨＢＡ２３２２２は、サーバが備えるＨＢＡを識別するための識別子を格納する。ＨＢＡポート２３２２３は、ＨＢＡが備えるＨＢＡポートを識別するための識別子を格納する。

ＦＣ−ＳＷポート２３２２４は、ＦＣ−ＳＷが備える入力ポートを識別するための識別子を格納する。ＦＣ−ＳＷ２３２２５は、ＦＣ−ＳＷを識別するための識別子を格納する。ＦＣ−ＳＷポート２３２２６は、ＦＣ−ＳＷが備える出力ポートを識別するための識別子を格納する。

ストレージポート２３２２７は、ストレージシステムが備えるポートを識別するための識別子を格納する。コントローラ２３２２８は、ストレージシステムが備えるコントローラを識別するための識別子を格納する。ＲＡＩＤ Ｇｒｏｕｐ２３２２９は、ストレージシステム上に作成されたＲＡＩＤ Ｇｒｏｕｐを識別するための識別子を格納する。

例えば、ＬＰＡＲ００（３００）からｓｄａ９００へのアクセスに関しては、ＣＰＵ２３２２１は「ｓｅｒｖｅｒ００」、ＨＢＡ２３２２２は「ＨＢＡ００」、ＨＢＡポート２３２２３は「ｈｐｏｒｔ００」、ＦＣ−ＳＷポート２３２２４は「ＳＷ０−１」、ＦＣ−ＳＷ２３２２５は「ＳＷ０」、ＦＣ−ＳＷポート２３２２６は「ＳＷ０−５」、ストレージポート２３２２７は「ｓ−ｐｏｒｔ０」、コントローラ２３２２８は「ＣＴＲＬ０」を経由して、最終的にＲＡＩＤ Ｇｒｏｕｐ２３２２９が「ＲＧ００」上のｓｄａ９００に格納されたデータにアクセスされることを示している。

その他の論理リソース（論理ボリューム）に関しても同様にアクセスパスが記憶される。

管理サーバ２００は、システム構成管理表２３２を備えることによって、物理リソースと論理リソースとのマッピングを把握することができる。なお、システム構成管理表２３２の各内容はシステム管理者がシステムの構築時にシステム設計情報を元に入力する。

図６は、本発明の第１の実施形態の管理サーバ２００が備えるリソース割当ポリシ２３３の一例を示す図である。

リソース割当ポリシ２３３は、ポリシ管理サーバ１９０が管理しているリソース割当ポリシ１９１から作成される。また、リソース割当ポリシ１９１は、システム管理者が構築やサイジング実施時に入力するパラメータである。

リソース割当ポリシ２３３は、物理リソース２３３１、性能限界２３３２、及び論理リソースへの割当方法２３３３を含む。

物理リソース２３３１は、ポリシが設定される物理リソースを識別するための識別子を格納する。性能限界２３３２は、物理リソース２３３１に対応する物理リソースに設定されるポリシの内容を格納する。論理リソースへの割当方法２３３３は、物理リソース２３３１に対応する物理リソースを使用する論理リソースに設定されるポリシの内容を格納する。

図６に示す例では、２つのエントリのみを示しているが、他の複数の物理リソースに関するエントリがあってもよい。

本実施形態では、ポリシによって、ＬＰＡＲに割り当てられた論理リソースが使用可能な帯域の割当値が設定される。

図６に示す例では、物理リソース２３３１は「ＦＣ−ＳＷ５００のポートＳＷ０−６」であり、当該ポートの性能限界２３３２は「８Ｇｂｐｓ」であり、当該ポートを経由する４つの論理リソース（この場合は論理ボリューム）へのアクセスに対して、ＬＰＡＲ００（３００）のｓｄｃ９０２は「３Ｇｂｐｓ」、ＬＰＡＲ０１（３１０）のｓｄａ９０３は１Ｇｂｐｓ、ＬＰＡＲ１０（４００）のｓｄａ９０４は「２Ｇｂｐｓ」、ＬＰＡＲ１１（４１０）のｓｄａ９０５は「２Ｇｂｐｓ」の帯域が割り当てられている。

また、本実施形態では、各論理リソースへの帯域割当においてキャッピングの有無が指定されている。

ここで、「キャッピング有」は、他の論理リソースへのアクセスに割り当てられた帯域が空いていても、当該帯域を流用することはできないことを示し、また、「キャッピング無」は、他の論理リソースへのアクセスに割り当てられた帯域が空いている場合には、余っている帯域を流用することができることを示す。

なお、図６に示す例では、割当ポリシとして各論理リソースへの割当帯域を使用したが、割当率指定、優先度制御、及び最低割当率指定等、種々のものが考えられる。また、各論理リソースの使用帯域を全く制限しないベストエフォートによる制御が行われる場合も考えられる。

図７及び図８は、本発明の第１の実施形態におけるボトルネック判定結果の表示画面である。管理サーバ２００は、モニタリング対象システム１００から取得されたモニタデータ２３１に基づいて、制御プログラム２２２を実行することによって後述するアルゴリズムに従ってボトルネックの判定を行った後、表示プログラム２２３を実行し表示装置２４０に図７及び図８に示す画面を表示する。

図７は、本発明の第１の実施形態におけるボトルネック箇所報告画面２０００を説明する図である。

ボトルネック箇所報告画面２０００は、ＬＰＡＲへの影響が大きいボトルネックを報告する画面である。

ボトルネック箇所報告画面２０００は、着目するＬＰＡＲを指定する入力領域２０１０、リソース待ち時間しきい値２３４を指定する入力領域２０１１、ボトルネック箇所を報告する出力表２０２０から構成される。

出力表２０２０は、時間範囲２０２１、論理デバイス２０２２、物理リソース２０２３、及びリソース待ち時間２０２４を含む。

時間範囲２０２１は、着目するＬＰＡＲにおいて、ボトルネックとなっていると判定された時間間隔を表示する。

論理デバイス２０２２は、着目するＬＰＡＲがアクセスした論理デバイス（この場合、論理ボリューム）を示す。物理リソース２０２３は、着目するＬＰＡＲから論理デバイスまでのアクセスパスにおいて、限界まで使用されている物理リソースを示す。つまり、ボトルネックとなっている物理リソースを示す。リソース待ち時間２０２４は、リソース待ち時間の平均値を示す。

リソース待ち時間２０２４は、論理リソースへのアクセス性能がサーバ性能に与える影響を表わすパラメータであり、当該値が大きいほどソフトウェア性能への悪影響が大きいことを示す。

ボトルネック箇所報告画面２０００は、実際に計測されたリソース待ち時間が入力領域２０１１に入力されたリソース待ち時間しきい値２３４より大きい論理リソースについてのみ、リソース待ち時間の降順にボトルネック部分を表示する。つまり、ソフトウェアから見て影響の大きい順にボトルネック部分が表示される。

これによって、システム管理者は、アプリケーション性能への影響が大きいボトルネック部分を知ることができる。

図７に示す例では、ＬＰＡＲ１１（４１０）に関するボトルネックのうち、リソース待ち時間が「２．０」以上のものが表示されている。例えば、図７に示すボトルネック箇所報告画面２０００の最初の項目は、９時００分から９時１０分の間、論理ボリュームｓｄａ９０５へのアクセスが、ＦＣ−ＳＷ５００のポートＳＷ０−６において割り当てられた帯域を限界まで使用されており、リソース待ち時間２０２４は「４．０」であることが分かる。その他の行についても他のボトルネック箇所が表示されている。

ここで、リソース待ち時間について詳細に説明する。アプリケーションが論理デバイスにアクセスする場合、ＯＳがアクセスのためのキューが用意される。アクセス経路内の何れかの物理リソースの帯域が律速して論理リソースのアクセス帯域が不足し、Ｉ／Ｏリクエストが滞ると、キューにアクセスリクエストの待ち行列ができ、リクエストが待たされる。

リソース待ち時間は、前述のＯＳにおけるＩ／Ｏリクエストの待ち時間を計測した値である。リソース待ち時間が大きいと、アクセスの帯域不足がアプリケーションへ与える影響が大きいことを示す。

例えば、ＵＮＩＸ（登録商標）系のＯＳの場合、Ｉ／Ｏ待ち時間はＯＳの標準コマンドである、ｉｏｓｔａｔコマンドによって、ａｗａｉｔという項目で測定することができる。他のＯＳでも同様に基本コマンドによって測定することができる。

ボトルネックがＩ／Ｏ性能に与える影響を示すパラメータは、前記で述べたリソース待ち時間だけでなく、平均待ち行列長等を使用することもできる。特にＣＰＵがボトルネックになっている場合、平均待ち行列長はｌｏａｄ ａｖｅｒａｇｅとして測定することができる。

図８は、本発明の第１の実施形態における物理リソースボトルネック画面２１００を説明する図である。

物理リソースボトルネック画面２１００は、物理リソースに割り当てられていたリソース使用量の限界に達している部分を報告する画面である。

物理リソースボトルネック画面２１００は、着目する物理リソースを指定する入力領域２１１０、リソース使用量を表示する出力グラフ２１２０、どの論理リソースがボトルネックになっているかを表示するアラート出力領域２１３０から構成される。

出力グラフ２１２０は、縦軸はＩ／Ｏスループットを示し、横軸は時刻を示す。出力グラフ２１２０は、各時刻において、着目された物理リソース（図８に示す例ではＦＣ−ＳＷ５００のポートＳＷ０−６）を使用する各ＬＰＡＲが論理デバイスにアクセスするときに、当該物理リソースをどれだけ使用しているかを、積み上げの面グラフの形で表示する。

出力グラフ２１２０は、さらに、論理デバイスのアクセスにおいて、割り当てられた帯域を使い切っている（ボトルネック）部分について、強調表示する。

図８に示す例では、下から順に、ＬＰＡＲ００（３００）のｓｄｃ９０２、ＬＰＡＲ０１（３１０）のｓｄａ９０３、ＬＰＡＲ１０（４００）のｓｄａ９０４、ＬＰＡＲ１１（４１０）のｓｄａ９０５のＩ／Ｏアクセススループットの時刻変化が表示されている。

図８に示す例では、ＬＰＡＲ１１（４１０）のｓｄａ９０５へのアクセスが２Ｇｂｐｓに制限されている。図８において、点線の部分がＬＰＡＲ１１（４１０）のｓｄａ９０５が使える帯域の上限を示す。図８に示すように、９時から９時１０分までの間、ＬＰＡＲ１１（４１０）のｓｄａ９０５へのアクセスは２Ｇｂｐｓの帯域を使い切っているため、この部分は斜線で強調表示されるとともに、当該論理デバイスのリソース使用量は割り当てられた帯域の限界に達している旨がアラート出力領域２１３０に表示される。

なお、ＬＰＡＲ１１（４１０）のｓｄａ９０５が使える帯域の上限を点線は表示されなくてもよく、斜線の部分のみを表示するものであってもよい。

これによって、システム管理者は、どの時刻に、どの論理リソースへのアクセスが帯域を限界まで使用しているか（ボトルネックが発生しているか）、さらに、ボトルネック発生時に、他の論理リソースへのアクセスは当該物理リソースをどれだけ使用しているかをモニタすることができる。

ボトルネック箇所報告画面２０００及び物理リソースボトルネック画面２１００の表示方法としては、最初にボトルネック箇所報告画面２０００を表示し、システム管理者はボトルネックが発生している部分とその対策優先順位を判定した後に、物理リソースボトルネック画面２１００を表示し、システム管理者は該当する物理リソースのリソース使用量の時系列変化（ボトルネックになっている部分で該当する物理リソースを他のＬＰＡＲがどの程度使用しているかが示される）をモニタし、原因を推定する方法が考えられる。なお、ボトルネック箇所報告画面２０００及び物理リソースボトルネック画面２１００の表示方法はこれに限定されず、例えば、同時に表示するものあってもよい。

次に、管理サーバ２００の処理について説明する。

本発明の第１の実施形態における特長は、管理サーバ２００が制御プログラム２２２を実行することによって、図９〜図１２で示す処理を行うことである。

＜管理サーバ２００の処理＞
以下では、本発明によるモニタリングシステム、すなわち、管理サーバ２００の動作を、図９〜図１４を用いて説明する。

管理サーバ２００は、測定データ収集プログラム２２１を実行することによって、性能データ（図１４参照）を収集し、収集された性能データをストレージシステム２３０上にモニタデータ２３１として蓄積する。

当該処理は、例えば、リモートシェルでｉｏｓｔａｔコマンドを起動することで実現できる。管理サーバ２００は、蓄積されたモニタデータ２３１を元に、ボトルネック解析を実行する。

図１４は、本発明の第１の実施形態の時系列性能データを説明する図である。

時系列性能データは、各ＬＰＡＲ（３００、３１０）上のＯＳで測定され、管理サーバ２００のモニタデータ２３１に蓄積される。図１４に示す例では、Ｌｉｎｕｘ（登録商標）のｉｏｓｔａｔによって等間隔（この場合、１０秒間隔）で測定したデータが、蓄積されている。図１４では１９時１７分４０秒と５０秒に測定されたデータを示すが、その後も同様にデータが蓄積される。以下、各時刻で測定されたデータの内容を順に説明する。

時刻の次の２行はＬＰＡＲ（３００、３１０）上のＯＳで測定されたＣＰＵ（１１１）時間の内訳を示し、各項目の意味は下記のとおりである。

％ｕｓｅｒは、ユーザモードで動作した時間の割合を示す。％ｎｉｃｅは、低優先度のユーザモードで動作した時間の割合を示す。％ｓｙｓｔｅｍは、システムモードで動作した時間の割合を示す。％ｉｏｗａｉｔは、Ｉ／Ｏの完了を待っていた時間の割合を示す。％ｓｔｅａｌは、仮想化環境で他のオペレーティングシステムにより消費された時間の割合を示す。％ｉｄｌｅは、タスク待ちの時間の割合を示す。

測定されたデータの下の４行は、ＬＰＡＲ（３００、３１０）上のＯＳで測定されたＩ／Ｏの動作状況であり、Ｉ／Ｏデバイス毎に測定されている。各項目の意味は下記のとおりである。

Ｄｅｖｉｃｅは、ＯＳ上の論理デバイス名を示す。ｒｒｑｍ／ｓは、デバイスに対するマージされたリクエスト数の一秒毎の数を示す。ｗｒｐｍ／ｓは、デバイスに対するマージされたリクエスト数の一秒毎の数を示す。ｒ／ｓは、デバイスに対する読み出しリクエスト数の一秒毎の数を示す。ｗ／ｓは、デバイスに対する書き込みリクエスト数の一秒毎の数を示す。ｒｓｅｃ／ｓは、デバイスから読み出したセクタ数の一秒毎の数（スループット）を示す。ｗｓｅｃ／ｓは、デバイスに書き込んだセクタ数の一秒毎の数（スループット）を示す。ａｖｇｒｑ−ｓｚは、デバイスに対するリクエストの平均サイズ（セクタ単位）を示す。ａｖｇｑｕ−ｓｚは、デバイスの要求リクエストキューの平均長を示す。
ａｗａｉｔは、デバイスへのＩ／Ｏリクエストがサービス終了するまでの平均待ち時間を示す。ｓｖｃｔｍは、デバイスへのＩ／Ｏの要求の平均サービス時間を示す。％ｕｔｉｌは、デバイスの平均使用率を示す。

本実施形態では、Ｉ／Ｏアクセス性能のソフトウェアに与える影響を表わす指標としてリソース待ち時間ａｗａｉｔを使用する。モニタデータ２３１に蓄積される時系列性能データの内容は、図１４に示したｉｏｓｔａｔの他にも、ｓａｒコマンドや、ハイパバイザのｘｅｎｔｏｐコマンド等、種々のコマンドの出力が可能である。

図９は、本発明の第１の実施形態の管理サーバ２００が物理リソース全体の使用状況を収集する処理を説明するフローチャートである。

当該処理は、ボトルネック判定を実行するときに必要となる、各物理リソースにおける使用状況を収集する処理である。

当該処理は、管理者がボトルネック箇所報告画面２０００の入力領域２０１０に、着目するＬＰＡＲを指定することによって開始される。

制御プログラム２２２は、システム構成管理表２３２を参照し、入力領域２０１０に入力されたＬＰＡＲ（以下、着目ＬＰＡＲとも記載する）が使用する物理リソースを全て抽出する（ステップ１４０１）。

図７に示す例では入力領域２０１０にＬＰＡＲ１１（４１０）が入力されており、制御プログラム２２２は、ＬＰＡＲ１１（４１０）が使用する物理リソースとして、ＣＰＵ２３２２１は「ｓｅｒｖｅｒ０１」、ＨＢＡ２３２２２は「ＨＢＡ１０」、ＨＢＡポート２３２２３は「ｈｐｏｒｔ１１」、ＦＣ−ＳＷポート２３２２４は「ＳＷ０−４」、ＦＣ−ＳＷ２３２２５は「ＳＷ０」、ＦＣ−ＳＷポート２３２２６は「ＳＷ０−６」、ストレージポート２３２２７は「ｓ−ｐｏｒｔ０」、コントローラ２３２２８「ＣＴＲＬ１」、及びＲＡＩＤ Ｇｒｏｕｐ２３２２９は「ＲＧ０３」を抽出する。

制御プログラム２２２は、抽出された全ての物理リソースについて、以下（ステップ１４０３〜１４０５）の処理を実行する（ステップ１４０２）。具体的には、制御プログラム２２２は、抽出された全ての物理リソースから一つの物理リソースを選択し、選択された物理リソース（以下、着目物理リソースとも記載する）についてステップ１４０３〜１４０５の処理を実行する。

制御プログラム２２２は、システム構成管理表２３２を参照し、着目物理リソースを使用する論理リソース（この場合、ＬＰＡＲと論理デバイスとの組み合わせ）を全て取得する（ステップ１４０３）。

例えば、選択された着目物理リソースがＦＣ−ＳＷ５００のポートＳＷ０−６の場合、ＬＰＡＲ００（３００）のｓｄｃ９０２、ＬＰＡＲ０１（３１０）のｓｄａ（９０３）、ＬＰＡＲ１０（４００）のｓｄａ（９０５）、及びＬＰＡＲ１１（４２０）のｓｄａ９０６が当該着目物理リソースを使用する論理リソースとして取得される。

次に、制御プログラム２２２は、取得された全ての論理リソースについて、蓄積されたモニタデータ２３１から性能の時系列変化を取得する（ステップ１４０４）。

制御プログラム２２２は、全ての論理リソースにおける、取得された時系列データを同一時刻ごとに照合して集計する（ステップ１４０５）。

制御プログラム２２２は、ステップ１４０１において抽出された全ての物理リソースについて処理が実行されたか否かを判定する（ステップ１４０６）。

ステップ１４０１において抽出された全ての物理リソースについて処理が実行されていないと判定された場合、制御プログラム２２２は、ステップ１４０３に戻り、処理されていない物理リソースを一つ選択して同一の処理（ステップ１４０３〜１４０６）を実行する。

ステップ１４０１において抽出された全ての物理リソースについて処理が実行されたと判定された場合、制御プログラム２２２は、処理を終了する。

この処理によって、各時刻において、着目ＬＰＡＲの各論理デバイスへのアクセスによって、物理リソースをどれだけ使用しているかが分かる。

図１０は、本発明の第１の実施形態の管理サーバ２００が実行するリソース割当ポリシを考慮した、ボトルネック箇所判定処理を説明するフローチャートである。

制御プログラム２２２は、図９に示す処理によって集計された各時刻における物理リソースの使用状況を用いて、リソース割当ポリシを考慮したボトルネック判定を実行する。

制御プログラム２２２は、各論理リソースにおける着目物理リソースの使用量の時系列データを取得する（ステップ１０００）。以下に示すボトルネック判定は、ステップ１０００において取得された時系列の測定データの、全ての時刻について行われる。

制御プログラム２２２は、全ての時刻についてステップ１００２〜ステップ１０１５の処理を実行する（ステップ１００１）。

制御プログラム２２２は、着目物理リソースがＣＰＵであるか否かを判定する（ステップ１００２）。

着目物理リソースがＣＰＵであると判定された場合、制御プログラム２２２は、管理用ＬＰＡＲにおける通信処理に伴うＣＰＵネックを判定するための処理を実行する。

具体的には、制御プログラム２２２は、ＣＰＵ使用率が１００％に達しており、かつ、管理用ＬＰＡＲのＣＰＵ処理が動作しているか否か（例えば、１％程度のしきい値を超えているか）を判定する（ステップ１０１４）。

ＣＰＵ使用率が１００％に達しており、かつ、管理用ＬＰＡＲのＣＰＵ処理が動作していると判定された場合、制御プログラム２２２は、管理用ＬＰＡＲにおける通信処理に伴うＣＰＵネックであると判定し、該当する測定点（時刻、論理リソースの組み合わせ）がボトルネックになっていることを記録し（ステップ１０１５）、ステップ１０１６に進む。

ステップ１０１４において、前述した条件を満たしていないと判定された場合、制御プログラム２２２は、ステップ１００３に進む。

着目物理リソースがＣＰＵである場合、通信に伴うＣＰＵ処理ネックが優先して判定される。通信に伴うＣＰＵ処理は各ＬＰＡＲに割り当てられたＣＰＵリソースの空き部分を使って動作するはずであり、通信に伴い管理用ＬＰＡＲが動作して物理ＣＰＵが１００％使われていると状態は、通信用に確保してあるＣＰＵリソースが不足していることを示すためである。

具体的には、ステップ１００２、ステップ１０１４及びステップ１０１５の処理を行うのは、図４に示すように、各ＬＰＡＲ３００、３１０がネットワーク通信を行う場合、管理用ＬＰＡＲ３６０上でネットワーク通信プログラム３６５が実行されるために、ＣＰＵ１１１の負荷が生じる。ネットワーク通信量が多い場合、前述したＣＰＵ１１１の負荷は、各ＬＰＡＲ３００、３１０の処理に比べて無視できない量となるため、ボトルネック判定で考慮する必要になるためである。

ステップ１０１４及びステップ１０１５の処理によって、制御プログラム２２２は、他のＬＰＡＲのＩ／Ｏをまとめて処理する管理用ＬＰＡＲがＩ／Ｏ処理によってボトルネックになっていることを判定できる。

ステップ１００２において、着目物理リソースがＣＰＵでないと判定された場合、制御プログラム２２２は、ステップ１００３以降の処理を実行する。

制御プログラム２２２は、リソース割当ポリシ２３３から、着目物理リソースの性能限界値を読み出す（ステップ１００３）。

制御プログラム２２２は、着目物理リソースが複数の論理リソースによって共有されているか否かを判定する（ステップ１００４）。

着目物理リソースが複数の論理リソースによって共有されていると判定された場合、制御プログラム２２２は、リソース割当ポリシ２３３から、着目物理リソースのリソース割当ポリシを読み出す（ステップ１００５）。

制御プログラム２２２は、リソース割当ポリシが性能限界スレッショルドを用いるか否かを判定する（ステップ１００６）。

その後の処理はリソース割当ポリシによって異なる。まず、リソース割当ポリシについて説明する。

図１３は、本発明の第１の実施形態におけるリソース割当ポリシの一例を示す説明図である。

図９では以下のポリシについて、使用される判定方法、性能限界決定方式を示す。なお、本実施形態では図１３に示すもの以外のリソース割当ポリシであっても可能である。

リソース割当ポリシ分類コラムは、リソース割当ポリシの方法を示している。具体的には、以下に示すようなものである。
・Ｂｅｓｔ Ｅｆｆｏｒｔ
各論理リソースは使えるだけ物理リソースを使用する。
・優先度制御
各論理リソースは優先度に従って物理リソースを使用する。
最低割当率が指定されている場合には、優先度が低い論理リソースにも、あらかじめ、決め られた量の物理リソースが割り当てられる。
・割当率指定
各論理リソースに、指定された割合の物理リソースが割り当てられる。
・割当値指定
各論理リソースへの物理リソース割当値が直接指定される。
割当率指定及び割当値指定については、キャッピングの有無があわせて指定される。

判定方法コラムは、「性能限界スレッショルド」を用いた判定が行われるかどうかを示す。

具体的には、割当値指定や割当率指定のように、論理リソースが使用できる物理リソースの割当量が指定できる場合、「性能限界スレッショルド」を用いた判定が行われる。

優先度制御のように、各論理リソースが使用できる物理リソースの割当量が決められない（他の論理リソースの物理リソースの使用量との相対関係でしか決められない）場合は、性能限界スレッショルドを用いない判定が行われる。

まず、性能限界スレッショルドが用いられる例として、論理リソースが「ＳＷ０−６」、割当ポリシが「割当値指定、キャッピング有」の場合について説明する。この場合、各論理リソースの性能限界スレッショルドは、性能割当値そのもの（例えば、ＬＰＡＲ１１（４１０）のｓｄａ９０５の場合、性能限界スレッショルドは２Ｇｂｐｓ）となる。

制御プログラム２２２は、ステップ１００６において、リソース割当ポリシが性能限界スレッショルドを用いると判定し、次に性能スレッショルドを算出する（ステップ１００７）。例えば、性能割当率が５０％で、キャッピング有の場合、性能スレッショルドは、物理リソース性能限界値に０．５を乗じた値として算出される。

制御プログラム２２２は、測定された性能値（論理リソースの物理リソース使用量）が性能限界スレッショルドに達しているか否かを判定する（ステップ１００８）。

測定された性能値（論理リソースの物理リソース使用量）が性能限界スレッショルドに達していると判定された場合、制御プログラム２２２は、該当する測定点（時刻と、論理リソースとの組み合わせ）がボトルネックであることを記録し（ステップ１０１２）、ステップ１０１６に進む。

測定された性能値（論理リソースの物理リソース使用量）が性能限界スレッショルドに達していないと判定された場合、該当する測定点を通常（ボトルネックにならないと）と記録し（ステップ１００９）、ステップ１０１６に進む。

以上の処理によって、制御プログラム２２２は、論理リソースが物理リソースの割当量を使い切っている（ＬＰＡＲ１１のｓｄａの場合、ＳＷ０−６ポートが２Ｇｂｐｓまで使われている）ことを検出することができる。

次に性能限界スレッショルドが使われない場合の判定方法を説明する。性能限界スレッショルドが使われない場合、図１３の「性能割当決定方式」コラムが、各論理リソースが性能限界に達しているか否か（論理リソースが、物理リソースの割当量を使い切りボトルネックになっている）を判定するアルゴリズムを示している。

例えば、「優先度制御」が行われる場合について説明すると（優先度制御では、各論理リソースの物理リソース使用量の限界値はあらかじめ決められず、他の論理リソースの使用量によって変化する）、以下に示す方式によって判定が行われる。
（１）全ての論理リソースの該物理リソース使用量の合計が、物理リソースの性能限界値より小さい（物理リソースの使用量に余裕がある）場合は、どの論理リソースも性能限界に達していないと判定。
（２）物理リソースが限界まで使われている場合、
（２ａ）論理リソースが最低優先度なら、該論理リソースは性能限界に達していると判定。
（２ｂ）論理リソースが最低優先度でない場合で、該論理リソースより、優先度が低い論理リソースのリソース使用量が全てゼロの場合、該論理リソースは性能限界に達していると判定。
（２ｃ）該論理リソースより、優先度が低い論理リソースのリソース使用量のうちゼロでない値がある場合、該論理リソースは性能限界に達していないと判定。

図１０のフローチャートに戻ると、制御プログラム２２２は、ステップ１００６において、リソース割当ポリシが性能限界スレッショルドを用いないと判定し、図１３で示したアルゴリズムを用いて性能限界有無を判定する（ステップ１０１０）。

制御プログラム２２２は、前述の性能判定有無の処理の結果、性能限界に達しているとか否かを判定する（ステップ１０１１）。

性能限界に達していると判定された場合、制御プログラム２２２は、該当する測定点がボトルネックになっていることを記録し（ステップ１０１２）、ステップ１０１６に進む。

性能限界に達していないと判定された場合は、制御プログラム２２２は、該当する測定点を通常と記録し（ステップ１００９）、ステップ１０１６に進む。

ここで、図１３において説明していないリソース割当ポリシにおける処理を説明する。
・Ｂｅｓｔ Ｅｆｆｏｒｔ
全ての論理リソースの該物理リソース使用量の合計が、物理リソースの性能限界値に達している場合、全ての論理リソースが性能限界に達していると判定。
・優先度制御（最低割当率指定）
前述した優先度制御と同様であるが、（２ｂ）が「論理リソースが最低優先度でない場合で、該論理リソースより、優先度が低い論理リソースのリソース使用量が全て最低値」の場合、該論理リソースは性能限界に達していると判定される。また、（２ｃ）が「該論理リソースより、優先度が低い論理リソースのリソース使用量のうち最低値でない値がある場合」該論理リソースは性能限界に達していないと判定される。
・割当値指定、キャッピング有
性能限界スレッショルドは以下のアルゴリズムで算出される。
（１）該論理リソース以外の他の何れかの論理リソースの物理リソース使用量に余裕がある（割当量より小さい）場合
性能限界スレッショルド＝物理リソースの性能限界値−他の論理リソースのリソース使用量合計
（２）他の何れの論理リソースの使用量にも余裕が無い場合
性能限界スレッショルド＝物理リソースの割当値
・割当率指定（キャッピング有／無）
性能割当値と同じ方法、ただし、性能割当値の代わりに、物理リソース性能限界値×物理リソース割当率が使用される。

前述した性能限界決定方法を適用して、ボトルネックの有無が判定される。

ステップ１００４において、着目物理リソースが複数の論理リソースによって共有されていないと判定された場合、制御プログラム２２２は、物理リソースの性能限界値を「性能限界スレッショルド」として設定し（ステップ１０１３）、ステップ１００８に進む。これによって、着目物理リソースが共有されていない場合、ハードの限界値を超えているかどうかが判定される。

制御プログラム２２２は、全時刻のデータについて処理が終了したか否かを判定する（ステップ１０１６）。

全時刻のデータについて処理が終了していないと判定された場合、制御プログラム２２２は、ステップ１００２に戻り、同様の処理（ステップ１００２〜ステップ１０１６）の処理を実行する。

全時刻のデータについて処理が終了したと判定された場合、制御プログラム２２２は、処理を終了する。

図１０に示す処理によって、各論理リソースの物理リソース使用量の時系列測定点（各時刻の値）について、ボトルネックの有無（該論理リソースがポリシによって決められた割当量を使い切っているか否か）が記録される。その結果、下記を実現する。

当該処理の結果を用いて、図１１を用いて後述する処理によって、リソース待ち時間を考慮したボトルネック対策の優先順位判定が実行される。

図８で示す物理リソースボトルネック画面２１００で、リソース使用量が割り当てられた限界に達している部分を報告するときに使用される。具体的には、入力領域２１１０に入力された着目物理リソースについて、図１０に示す処理の判定結果を取得し、リソース割使用量が割り当てられた限界に達しておりボトルネックありと記録された測定点（時刻範囲）が図８の斜線のように強調表示される。また、アラート出力領域２１３０に、該論理リソースにおいてリソース使用量が割当られた限界に達していることが表示される。

次に、リソース待ち時間を考慮したボトルネック対策の優先順位判定フローを説明する。

図１１は、本発明の第１の実施形態の管理サーバ２００が実行する、リソース待ち時間を考慮したボトルネック対策の優先順位判定処理を説明するフローチャートである。

図１０で示した処理の終了後、システム管理者が入力領域２０１０に着目ＬＰＡＲを入力し、入力領域２０１１にリソース待ち時間しきい値２３４を入力した後に当該処理が開始される。

制御プログラム２２２は、着目ＬＰＡＲを入力領域２０１０から取得する（ステップ１１０１）。

制御プログラム２２２は、システム構成管理表２３２から着目ＬＰＡＲが使用する物理リソースと、論理デバイスとの組み合わせを取得する（ステップ１１０２）。

例えば、着目ＬＰＡＲとしてＬＰＡＲ１１（４１０）が指定された場合、論理リソースとして「ｓｄａ９０５」、また、物理リソースとして、ＣＰＵ２３２２１が「ｓｅｒｖｅｒ０１」、ＨＢＡ２３２２２が「ＨＢＡ１０」、ＨＢＡポート２３２２３が「ｈｐｏｒｔ１１」、ＦＣ−ＳＷポート２３２２４が「ＳＷ０−４」、ＦＣ−ＳＷ２３２２５が「ＳＷ０」、ＦＣ−ＳＷポート２３２２６が「ＳＷ０−６」、ストレージポート２３２２７が「ｓ−ｐｏｒｔ１」、コントローラ２３２２８が「ＣＴＲＬ１」、及びＲＡＩＤ Ｇｒｏｕｐ２３２２９が「ＲＧ０３」と取得される。

制御プログラム２２２は、物理リソースと論理リソースとの全ての組み合わせに関して、以下（ステップ１１０４〜１１０９）の処理を実行する（ステップ１１０３）。

制御プログラム２２２は、図１０で示した処理の結果を参照し、着目ＬＰＡＲが使用する物理リソースにおけるボトルネック（リソース割当ポリシによる割当量の限界に達している部分）の有無を判定する（ステップ１１０４）。

制御プログラム２２２は、モニタデータ２３１を参照し、ボトルネックが発生していると判定された時刻範囲におけるリソース待ち時間を取得し（ステップ１１０５）、取得されたリソース待ち時間の平均値を算出する（ステップ１１０６）。

例えば、物理リソースが「ＳＷ０−６」、論理リソースが「ＬＰＡＲ１１（４１０）のｓｄａ９０５」の場合、９時００分から９時１０分の間のリソース待ち時間測定値の平均値が算出される。

制御プログラム２２２は、算出されたリソース待ち時間の平均値とリソース待ち時間しきい値２３４とを比較し（ステップ１１０７）、算出されたリソース待ち時間の平均値が、リソース待ち時間しきい値２３４を超えているか否かを判定する（ステップ１１０８）。

算出されたリソース待ち時間の平均値が、リソース待ち時間しきい値２３４を超えていると判定された場合、制御プログラム２２２は、出力表２０２０に、リソース待ち時間の大きい順番に該当するボトルネック箇所の情報（時刻範囲、論理デバイス、及び物理リソースの情報）を表示する（ステップ１１０９）。具体的には、ステップ１１０４〜ステップ１１１０のループ処理が実行され、処理が終わった結果から逐次に、出力表２０２０にリソース待ち時間の大きいものから順番に表示される。

なお、制御プログラム２２２は、取得された全ての論理リソースと物理リソースとの組み合わせについてステップ１１０３〜ステップ１１０８までの処理が実行し、処理結果に基づいて、リソース待ち時間の大きいものから降順にボトルネック箇所を表示するための情報を生成し、生成された情報に基づいて出力表２０２０を表示するものであってもよい。

算出されたリソース待ち時間の平均値が、リソース待ち時間しきい値２３４を超えていないと判定された場合、制御プログラム２２２は、ステップ１１１０に進む。

制御プログラム２２２は、ステップ１１０２において取得された全ての論理リソースと物理リソースとの組み合わせについて処理が実行されたか否かを判定する（ステップ１１１０）。

ステップ１１０２において取得された全ての論理リソースと物理リソースとの組み合わせについて処理が実行されていないと判定された場合、制御プログラム２２２は、ステップ１１０４に戻り、ステップ１１０４〜ステップ１１１０の処理を実行する。

ステップ１１０２において取得された全ての論理リソースと物理リソースとの組み合わせについて処理が実行されたと判定された場合、制御プログラム２２２は、処理を終了する。

以上の処理によって、図７に示すボトルネック箇所報告画面２０００が表示される。

次に、ボトルネック判定後の管理サーバ２００上の制御プログラム２２２の動作を、図１２を用いて説明する。

図１２は、本発明の第１の実施形態の管理サーバ２００が実行する、ボトルネック解決処理を説明するフローチャートである。

当該処理では、表示装置２４０を介して、ボトルネックを解決するために、システム管理者との対話的な処理が実行される。

図１１に示す処理が実行された後に当該処理が開始される（ステップ１２０１）。

制御プログラム２２２は、リソース割当ポリシを変更するか否かを判定する（ステップ１２０２）。具体的には、管理サーバ２００が表示プログラム２２３を実行し、表示装置２４０にリソース割当ポリシを変更するか否かの指示を促すメッセージ等を表示する。システム管理者は、当該メッセージに基づいて、リソース割当ポリシを変更するか否かを指示する。

リソース割当ポリシを変更すると判定された場合、つまり、管理サーバ２００がシステム管理者からリソース割当ポリシを変更する旨の指示を受信した場合、制御プログラム２２２は、リソース割当ポリシを変更する（ステップ１２０９）。具体的には、管理サーバ２００が、ポリシ管理サーバ１９０に、ボトルネックが発生していると判定された論理リソースへのリソース割当量を増加させる指示を含むリソース割当ポリシの変更指示を送信する。

ポリシ自体の内容は、システム管理者が、各ＬＰＡＲの仕事の優先度等を考慮して決定する。図８に示す例では、スイッチの物理ポートＳＷ０−６の使用率には余裕があるので、割当ポリシの該論理リソースに対するキャッピングを「無」に設定する等の対策が可能である。

リソース割当ポリシを変更しないと判定された場合、つまり、管理サーバ２００がシステム管理者からリソース割当ポリシを変更しない旨の指示を受信した場合、制御プログラム２２２は、論理リソースを移動させるか否かを判定する（ステップ１２０３）。具体的には、管理サーバ２００が表示プログラム２２３を実行し、表示装置２４０に論理リソースを移動させるか否かの指示を促すメッセージ等を表示する。

論理リソースを移動させないと判定された場合、つまり、管理サーバ２００がシステム管理者から論理リソースを移動させない旨の指示を受信した場合、制御プログラム２２２は、表示装置２４０に移動しない旨を表示する（ステップ１２０８）。

論理リソースを移動させると判定された場合、つまり、管理サーバ２００がシステム管理者から論理リソースを移動させる旨の指示を受信した場合、制御プログラム２２２は、ボトルネックになった論理リソースに割り当て可能な空きリソースを検索し（ステップ１２０４）、ボトルネックになった論理リソースに割り当て可能な空きリソースがあるか否かを判定する（ステップ１２０５）。

ボトルネックになった論理リソースに割り当て可能な空きリソースがあると判定された場合、制御プログラム２２２は、当該空きリソースに論理リソースを移動する（ステップ１２０６）。

ボトルネックになった論理リソースに割り当て可能な空きリソースがないと判定された場合、制御プログラム２２２は、表示装置２４０に空きリソースがない旨を表示する（ステップ１２０７）。

図２を例に説明すると、ＦＣ−ＳＷのポートＳＷ０−６がボトルネックの場合、仮にポートＳＷ０−５やストレージのコントローラＣＴＲＬ０の使用率に余裕が十分にある場合、制御プログラム２２２は、ＬＰＡＲ１１（４１０）がアクセスするｓｄａ９０５のストレージ側の担当コントローラとＦＣ−ＳＷとの接続を変更し、ＳＷ０−５とＣＴＲＬ０経由でアクセスするようにアクセス経路を変更する、等の対策が可能である。

以上の処理によって、管理サーバ２００は、リソース使用量の監視、ボトルネック判定、及びボトルネックの対策の一連の流れを実行できる。

［変形例１］
第１の実施形態では、図８に示す物理リソースボトルネック画面２１００において、ボトルネックが発生している部分を強調表示した。しかし、限界に達して初めて強調表示する方式の他に、限界に達する前から使用率に応じて色を変えて表示する方式が考えられる。

図１５は、本発明の第１の実施形態の物理リソースボトルネック画面２１００の表示方法の変形例を説明するフローチャートである。

制御プログラム２２２は、リソース割当ポリシにおいて、論理リソースへのリソース割り当てが割当値又は割当率で指定されているか否かを判定する（ステップ１３０１）。

論理リソースへのリソース割り当てが割当値又は割当率で指定されていると判定された場合、制御プログラム２２２は、以下のように変数Ｒを算出する（ステップ１３０２）。つまり、論理リソースへのリソース割り当てが割当値で指定されている場合、変数Ｒは、
Ｒ＝論理リソースのリソース使用量測定値÷リソース割当値…（１）
と算出される。
また、論理リソースへのリソース割り当てが割当率で指定されている場合、変数Ｒは、
Ｒ＝物理リソースの性能限界値×割当率…（２）
と算出される。

論理リソースへのリソース割り当てが割当値又は割当率で指定されていると判定された場合、制御プログラム２２２は、変数Ｒを下式で算出する（ステップ１３０４）。
Ｒ＝全論理リソースの該物理リソース使用量合計÷物理リソースの性能限界値…（３）
変数Ｒは、論理リソースに対して割当られたリソース量に対してどれだけ使用されているかを示す指標である。各論理リソースに対して、割当率や割当量が指定されていない、優先度制御等が行われている（ステップ１３０４の）場合、個々の論理リソースではなく、論理リソース全体で一括して、Ｒが算出される。

制御プログラム２２２は、算出された変数Ｒの値によって、色分けして該当する論理リソースにおける物理リソース使用量を表わすグラフを描画する（ステップ１３０３）。

ここで注意しなければならないのは、キャッピングが行われている場合、Ｒの値が１００％以上になることである。この場合、Ｒの値が１００％と超えていることと、該当する論理リソースがボトルネックとなっている（物理リソースを限界まで使用している）こととは直接には関連しない（他の論理リソースの使用量に空きがある場合、該論理リソースの使用量が１００％を超えていても、ボトルネックとは判定されない）。したがって、図８で示すようなボトルネック範囲の強調表示と本変形例の色づけとは独立に行われる必要がある。

なお、当該処理は、物理リソースボトルネック画面２１００の入力領域２１１０に着目物理リソースが入力されてから開始される。

変形例１によれば、各論理リソースの物理リソース使用量が限界までどれだけ余裕が有るかを視覚的に認識でき、システム性能管理を容易化することができる。

［変形例２］
第１の実施形態では、Ｉ／Ｏアクセス性能のソフトウェアに与える影響を表わす指標として、リソース待ち時間の絶対値が使用されていた。しかし、前述の指標は簡便ではあるがアクセスされるデータの属性によって異なるため、異なる性質のデータにアクセスするＬＰＡＲでは、複数の論理デバイス間の性能を比較するときに、正確な比較にならない可能性がある。例えば、ＯＳが異なると、ＯＳ毎にリソース待ち時間のはかり方が異なる場合があり、比較する指標としては適切でない。

前述した問題を回避するために、リソース待ち時間の絶対値に代え、通常時におけるリソース待ち時間と、Ｉ／Ｏスループットが限界に達している時におけるリソース待ち時間との比を、ソフトウェアに与える影響の指標として使用する方法が考えられる。

図１６は、本発明の第１の実施形態の変形例におけるリソース待ち時間比の計算方法を示す説明図である。

図１６の上部記載の表はハードウェアリソース使用量の時系列変化を示し（図８の出力グラフ２１２０と同一のグラフである）、図１６の下部記載の表は、ＬＰＡＲ１１（４１０）がアクセスするｓｄａ９０５のリソース待ち時間の時系列変化を示す。

両グラフの横軸は同一の時刻を表わす。図１６に示すように、論理リソースのスループットが限界に達している時刻範囲で、リソース待ち時間の値が大きな値になる。

以下、論理リソースのスループットが限界に達している時刻範囲でのリソース待ち時間の平均値をＷｐと記載し、それ以外の区間でのリソース待ち時間の平均値をＷｎと記載する。第１の実施形態では、Ｉ／Ｏアクセス性能のソフトウェアに与える影響を表わす指標としてＷｐが用いられていたが、本変形例ではＩ／Ｏアクセス性能のソフトウェアに与える影響を表わす指標としてＷｐ／Ｗｎが用いられる。

具体的には、図１１のステップ１１０５、１１０６に代えて以下のステップを制御プログラム２２２が実行する。
（１）ボトルネックが発生している時刻範囲の情報、及び論理デバイスのリソース待ち時間の時系列変化データから、Ｗｐ及びＷｎを算出するステップ。
（２）Ｗｐ／Ｗｎを算出するステップ。
なお、それ以降のしきい値判定、及び表示は、第１の実施形態と同様のアルゴリズムで実行される。

変形例２によれば、性質の異なるＩ／Ｏアクセスのソフトウェアに与える影響についても、同一の指標を用いて比較できるようになる。

さらに、本発明は、性能指標としてリソース待ち時間でなく、Ｉ／Ｏのキュー長やサービス時間、及びＣＰＵのｌｏａｄ ａｖｅｒａｇｅ（待ち行列長）を用いて可能である。また、本発明では測定された値の平均値を用いていたが、最大値を用いることもできる。

以上のように、本発明によれば、複数の論理リソースが物理リソースを共有する環境において、リソース割当ポリシを考慮して、論理リソースの使用量がボトルネックに達している（決められた割当値の限界に達している）ことを判定できる。さらに、ボトルネックと判定された部分がソフトウェアに与える影響を判定し、ソフトウェアに与える悪影響が大きい部分をナビゲーションすることができる。

これによって、従来の性能モニタリングシステムでは実現できなかった、リソース割当ポリシ、及びソフトウェアへの影響を考慮したボトルネック判定を実現し、システム管理者は迅速に性能対策を行うことができる。

１００ モニタリング対象システム
１１０ サーバ
１１１ ＣＰＵ
１１２ 主記憶装置
１１３ ＮＩＣ
１１４ ＨＢＡ
１２０ サーバ
１５０ ストレージ
１６０ ネットワーク
１６１ ネットワークリソース割当ポリシ
１９０ ポリシ管理サーバ
１９１ リソース割当ポリシ
２００ 管理サーバ
２２１ 測定データ収集プログラム
２２２ 制御プログラム
２２３ 表示プログラム
２３０ ストレージシステム
２３１ モニタデータ
２３２ システム構成管理表
２３３ リソース割当ポリシ
２４０ 表示装置
２５０ ＮＩＣ
３０１ ＯＳモニタリングプログラム
３０５ 仮想ＮＩＣプログラム
３１０ ＬＰＡＲ
３５０ ハイパバイザ
３５１ ハイパバイザモニタリングプログラム
３５２ ＣＰＵリソース割当ポリシ
３５５ ＬＰＡＲ間通信プログラム
３６５ ネットワーク通信プログラム
３６６ 仮想スイッチプログラム
３６７ 物理ＮＩＣドライバ
５００ ＦＣ−ＳＷ
５５０ ストレージシステム
５５１ コントローラ
５６０〜５６３ ＲＡＩＤ Ｇｒｏｕｐ
２０００ ボトルネック箇所報告画面
２１００ 物理リソースボトルネック画面
５５１０ ＳＡＮリソース割当ポリシ

Claims (15)

1. サーバと、前記サーバに接続されたストレージシステムと、前記サーバ及び前記ストレージシステムを管理する管理計算機とを備える性能モニタリングシステムであって、
   前記サーバは、第１のプロセッサと、前記第１のプロセッサと接続される第１のメモリと、前記第１のプロセッサと接続される第１のネットワークインタフェースとを備え、
   前記ストレージシステムは、コントローラと、記憶装置と、前記コントローラと前記記憶装置とを接続するディスクインタフェースとを備え、
   前記コントローラは、第２のプロセッサと、前記第２のプロセッサと接続される第２のメモリとを備え、
   前記管理計算機は、第３のプロセッサと、前記第３のプロセッサと接続される第３のメモリと、前記第３のプロセッサと接続される記憶装置とを備え、
   前記サーバ上では、前記サーバを論理的に分割して作成された、複数の仮想計算機が実行され、
   前記ストレージシステムは、前記記憶装置を論理的に分割した論理記憶ユニットを前記仮想計算機に提供し、
   前記仮想計算機から前記論理ユニットまでの経路における物理リソースが、前記仮想計算機の論理リソースとして割り当てられ、
   前記サーバは、前記論理リソースごとに、前記仮想計算機が測定する前記論理リソースによって使用される物理リソースの使用量に関する時系列データを収集し、
   前記管理計算機は、
   前記論理リソースに設定されるリソース割当ポリシに関する情報を管理し、
   前記サーバから、前記収集された時系列データを取得し、
   前記取得された時系列データの各時刻において、指定された前記仮想計算機の論理リソースが使用する物理リソースの使用量と、前記リソース割当ポリシとを参照し、前記指定された仮想計算機の論理リソースにボトルネックが発生しているか否かを判定し、
   ボトルネックが発生している前記論理リソースの性能が前記仮想計算機の性能に与える影響を示す性能値を取得し、
   前記取得された性能値に基づいて、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定し、
   前記仮想計算機に与える影響が大きいボトルネックが発生していると判定された場合、前記仮想計算機に大きいボトルネックが発生したことを通知することを特徴とする性能モニタリングシステム。
2. 前記性能値は、前記仮想計算機上で実行されるオペレーティングシステムにおけるリソース待ち行列のオーバヘッドを示すパラメータを用い、
   前記管理計算機は、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定する場合に、前記性能値が予め設定されたしきい値より大きいか否かを判定し、前記性能値が予め設定されたしきい値より大きい場合に、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定することを特徴とする請求項１に記載の性能モニタリングシステム。
3. 前記性能値は、ボトルネックが発生している時の前記論理リソースにおける物理リソースの使用量と、ボトルネックが発生していない時の前記論理リソースにおける物理リソースの使用量と、の比を用い、
   前記管理計算機は、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定する場合に、前記性能値が予め設定されたしきい値より大きいか否かを判定し、前記性能値が予め設定されたしきい値より大きい場合に、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定することを特徴とする請求項１に記載の性能モニタリングシステム。
4. 前記性能モニタリングシステムは、前記管理計算機の判定結果を表示する表示部を備え、
   前記管理計算機は、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定された論理リソースを、前記仮想計算機に与える影響が大きい順に表示するための表示情報を生成し、前記生成された表示情報を前記表示部に表示することを特徴とする請求項１に記載の性能モニタリングシステム。
5. 前記性能モニタリングシステムは、前記管理計算機の判定結果を表示する表示部を備え、
   前記管理計算機は、前記仮想計算機に与える影響が大きいボトルネックの発生を検知した場合、前記リソース割当ポリシの変更、又は、ボトルネックが発生していない前記物理リソースに前記論理リソースを移動のいずれかを選択する旨を前記表示部に表示することを特徴とする請求項１に記載の性能モニタリングシステム。
6. 前記性能モニタリングシステムは、前記管理計算機の判定結果を表示する表示部を備え、
   前記管理計算機は、
   前記論理リソースが使用する前記物理リソースの使用量を前記表示部に表示し、
   前記指定された仮想計算機の論理リソースにボトルネックが発生していることを検知した場合、ボトルネックが発生している部分を強調して表示することを特徴とする請求項１に記載の性能モニタリングシステム。
7. 前記管理計算機は、
   前記論理リソースにおける前記物理リソースの使用量と、前記論理リソースに対する前記物理リソースの割当量との比率を算出し、
   前記比率に応じて、前記ボトルネックが発生している部分の表示方法を変更することを特徴とする請求項６に記載の性能モニタリングシステム。
8. サーバと、前記サーバに接続されたストレージシステムと、前記サーバ及び前記ストレージシステムを管理する管理計算機とを備える性能モニタリングシステムにおけるボトルネック判定方法であって、
   前記サーバは、第１のプロセッサと、前記第１のプロセッサと接続される第１のメモリと、前記第１のプロセッサと接続される第１のネットワークインタフェースとを備え、
   前記ストレージシステムは、コントローラと、記憶装置と、前記コントローラと前記記憶装置とを接続するディスクインタフェースとを備え、
   前記コントローラは、第２のプロセッサと、前記第２のプロセッサと接続される第２のメモリとを備え、
   前記管理計算機は、第３のプロセッサと、前記第３のプロセッサと接続される第３のメモリと、前記第３のプロセッサと接続される記憶装置とを備え、
   前記サーバは、前記サーバを論理的に分割して作成された、複数の仮想計算機が実行され、
   前記ストレージシステムは、前記記憶装置を論理的に分割した論理記憶ユニットを前記仮想計算機に提供し、
   前記仮想計算機から前記論理ユニットまでの経路における物理リソースが、前記仮想計算機の論理リソースとして割り当てられ、
   前記サーバは、前記論理リソースごとに、前記仮想計算機が測定する前記論理リソースによって使用される物理リソースの使用量に関する時系列データを収集し、
   前記管理計算機は、前記論理リソースに設定されるリソース割当ポリシに関する情報を管理し、
   前記方法は、
   前記管理計算機が、前記サーバから、前記収集された時系列データを取得するステップと、
   前記管理計算機が、前記取得された時系列データの各時刻において、指定された前記仮想計算機の論理リソースが使用する物理リソースの使用量と、前記リソース割当ポリシとを参照し、前記指定された仮想計算機の論理リソースにボトルネックが発生しているか否かを判定するステップと、
   前記管理計算機が、ボトルネックが発生している前記論理リソースの性能が前記仮想計算機の性能に与える影響を示す性能値を取得するステップと、
   前記管理計算機が、前記取得された性能値に基づいて、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定するステップと、
   前記仮想計算機に与える影響が大きいボトルネックが発生していると判定された場合、前記管理計算機が、前記仮想計算機に大きいボトルネックが発生したことを通知するステップと、を含むことを特徴とするボトルネック判定方法。
9. 前記性能値は、前記仮想計算機上で実行されるオペレーティングシステムにおけるリソース待ち行列のオーバヘッドを示すパラメータを用い、
   前記方法は、
   前記管理計算機が、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定する場合に、前記性能値が予め設定されたしきい値より大きいか否かを判定するステップと、
   前記管理計算機が、前記性能値が予め設定されたしきい値より大きい場合に、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定するステップと、を含むことを特徴とする請求項８に記載のボトルネック判定方法。
10. 前記性能値は、ボトルネックが発生している時の前記論理リソースにおける物理リソースの使用量と、ボトルネックが発生していない時の前記論理リソースにおける物理リソースの使用量と、の比を用い、
    前記方法は、
    前記管理計算機が、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定する場合に、前記性能値が予め設定されたしきい値より大きいか否かを判定するステップと、
    前記管理計算機が、前記性能値が予め設定されたしきい値より大きい場合に、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定するステップと、を含むことを特徴とする請求項８に記載のボトルネック判定方法。
11. 前記性能モニタリングシステムは、前記管理計算機の判定結果を表示する表示部を備え、
    前記方法は、
    前記管理計算機が、前記仮想計算機に与える影響が大きいボトルネックが発生していると判定された論理リソースを、前記仮想計算機に与える影響が大きい順に表示するための表示情報を生成するステップと、
    前記管理計算機が、前記生成された表示情報を前記表示部に表示するステップと、を含むことを特徴とする請求項８に記載のボトルネック判定方法。
12. 前記性能モニタリングシステムは、前記管理計算機の判定結果を表示する表示部を備え、
    前記方法は、
    前記管理計算機が、前記仮想計算機に与える影響が大きいボトルネックの発生を検知した場合、前記リソース割当ポリシの変更、又は、ボトルネックが発生していない前記物理リソースに前記論理リソースを移動のいずれかを選択する旨を前記表示部に表示するステップを含むことを特徴とする請求項８に記載のボトルネック判定方法。
13. 前記性能モニタリングシステムは、前記管理計算機の判定結果を表示する表示部を備え、
    前記方法は、
    前記管理計算機が、前記論理リソースが使用する前記物理リソースの使用量を前記表示部に表示するステップと、
    前記指定された仮想計算機の論理リソースにボトルネックが発生していることを検知した場合、前記管理計算機が、ボトルネックが発生している部分を強調して表示するステップと、を含むことを特徴とする請求項８に記載のボトルネック判定方法。
14. 前記方法は、
    前記管理計算機が、前記論理リソースにおける前記物理リソースの使用量と、前記論理リソースに対する前記物理リソースの割当量との比率を算出するステップと、
    前記管理計算機が、前記比率に応じて、前記ボトルネックが発生している部分の表示方法を変更するステップと、を含むことを特徴とする請求項１３に記載のボトルネック判定方法。
15. サーバと、前記サーバに接続されたストレージシステムとを備える性能モニタリングシステムに備わり、前記サーバ及び前記ストレージシステムを管理する管理計算機であって、
    前記サーバは、第１のプロセッサと、前記第１のプロセッサと接続される第１のメモリと、前記第１のプロセッサと接続される第１のネットワークインタフェースとを備え、
    前記ストレージシステムは、コントローラと、記憶装置と、前記コントローラと前記記憶装置とを接続するディスクインタフェースとを備え、
    前記コントローラは、第２のプロセッサと、前記第２のプロセッサと接続される第２のメモリとを備え、
    前記管理計算機は、第３のプロセッサと、前記第３のプロセッサと接続される第３のメモリと、前記第３のプロセッサと接続される記憶装置とを備え、
    前記サーバは、前記サーバを論理的に分割して作成された、複数の仮想計算機が実行され、
    前記ストレージシステムは、前記記憶装置を論理的に分割した論理記憶ユニットを前記仮想計算機に提供し、
    前記管理計算機は、
    前記仮想計算機に割り当てられ、前記仮想計算機から前記論理ユニットまでの経路における物理リソースである論理リソースに設定されるリソース割当ポリシに関する情報を管理し、
    前記論理リソースごとに、前記サーバが測定する前記論理リソースによって使用される物理リソースの使用量に関する時系列データを取得し、
    前記取得された時系列データの各時刻において、指定された前記仮想計算機の前記論理リソースが使用する物理リソースの使用量と、前記リソース割当ポリシとを参照し、前記指定された仮想計算機の論理リソースにボトルネックが発生しているか否かを判定し、
    ボトルネックが発生している前記論理リソースの性能が前記仮想計算機の性能に与える影響を示す性能値を取得し、
    前記取得された性能値に基づいて、前記仮想計算機に与える影響が大きいボトルネックが発生しているか否かを判定し、
    前記仮想計算機に与える影響が大きいボトルネックが発生していると判定された場合、前記仮想計算機に大きいボトルネックが発生したことを通知することを特徴とする管理計算機。

Images