(57)【要約】      （修正有）【課題】コンピュータインフラストラクチャを解析する方法および装置を提供する。【解決手段】サービスを提供する複数のコンポーネントを備えるコンピュータインフラストラクチャを解析する方法であって、前記サービスの目的とする品質レベルは、サービスレベル品質目標（ＳＬＯ品質目標）及び関係するコンプライアンスレベルを定義する少なくとも１つのサービスレベル目標（ＳＬＯ）によって定義され、該方法は、選択されたＳＬＯの第１のＳＬＯの前記コンピュータインフラストラクチャから収集されたデータを使用して計算されるコンプライアンスデータを得ることと、前記選択されたＳＬＯの第２のＳＬＯのコンプライアンスデータを、前記収集されたデータ及び選択されたＳＬＯ品質目標についてその目標を満たす値を部分的に使用して計算し、前記第１のデータと前記第２のデータとの差に基づいて、修正に適した１つ又は２つ以上のコンポーネントを特定する。【選択図】図１
2008108262.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供するコンピュータインフラストラクチャを解析する方法であって、前記サービスの目的とする品質レベルは、サービスレベル品質目標及び関係するコンプライアンスレベルを定義する少なくとも１つのサービスレベル目標によって定義され、前記コンピュータインフラストラクチャは、複数のコンポーネントを備え、該方法は、
選択されたサービスレベル目標の第１のサービスレベル目標のコンプライアンスデータを得ることであって、該コンプライアンスデータは、前記コンピュータインフラストラクチャから収集されたデータを使用して計算される、前記第１のサービスレベル目標のコンプライアンスデータを得ることと、
前記選択されたサービスレベル目標の第２のサービスレベル目標のコンプライアンスデータを、前記収集されたデータ及び選択されたサービスレベル品質目標についてその目標を満たす値を部分的に使用して計算することと、
前記第１のデータと前記第２のデータとの間の差を計算することと、
前記計算された差に基づいて、修正に適した１つ又は２つ以上のコンポーネントを特定することと
を含む方法。
【請求項２】
前記サービスの前記品質レベルが、複数のサービスレベル目標によって定義される場合、各サービスレベル目標の各サービスレベル品質目標について前記第２のサービスレベル目標データを計算するステップを繰り返すこと
をさらに含む
請求項１に記載の方法。
【請求項３】
前記特定するステップは、
前記計算された差が第１の所定の範囲内にある場合には、第１の方法で修正のためのコンポーネントを特定すること
をさらに含み、
前記計算された差が第２の所定の範囲内にある場合には、第２の方法で修正のためのコンポーネントを特定すること
をさらに含む、
請求項１または２に記載の方法。
【請求項４】
前記１つ又は２つ以上の適切なコンポーネントを特定するステップは、
修正に適した所定の個数のコンポーネントに優先順位を付けること
を含み、
該優先順位を付けるステップは、
前記提案された修正に関係する財務データにアクセスすること
をさらに含む
請求項３に記載の方法。
【請求項５】
前記特定されたコンポーネントの少なくとも１つを前記特定された方法に従って修正すること
をさらに含む
請求項３または４に記載の方法。
【請求項６】
第１の方法で修正されるように特定されたコンポーネントをアップグレードすることと、
第２の方法によって修正されるように特定されたコンポーネントをダウングレードすることと
をさらに含む
請求項５に記載の方法。
【請求項７】
修正のために特定された前記コンポーネントに関係する事項を、該修正を行うための変更管理システムへ転送すること
をさらに含む
請求項３〜６のいずれかに記載の方法。
【請求項８】
前記収集されるデータは、前記サービスのオペレーション中に所定の期間にわたって前記コンピュータインフラストラクチャから収集される
請求項１〜７のいずれかに記載の方法。
【請求項９】
請求項１〜８のいずれかに従って動作可能なＩＴインフラストラクチャを解析するための装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、包括的には、コンピューティングの分野に関する。
【背景技術】
【０００２】
コンピュータシステムは、顧客にサービスを提供する企業環境で頻繁に使用される。
サービスの例には、電気通信ネットワークを提供すること、インターネットベースのショッピングサービス、ストレージサービス等が含まれる。
【０００３】
関係するサービスが何であろうとも、サービスプロバイダは、一般に、サービスが提供される期間にわたって、合意されたサービス品質を当該サービスプロバイダの顧客に確実に提供する義務を負う。
【０００４】
サービスレベル合意（ＳＬＡ）は、一般に、サービスプロバイダと当該サービスプロバイダの顧客との間で、所定の期間（以下、評価期間と呼ぶ）にわたる特定のサービスについての合意されたサービス品質を定義するのに使用される。
ＳＬＡは、通常、そのＳＬＡを順守しているとみなされるために満たさなければならない複数のサービスレベル目標（ＳＬＯ）を定義する。
ＳＬＯは、通常、最大許容可能サーバ応答時間、最大許容可能トランザクション処理時間、最小許容可能ネットワーク帯域幅等のＳＬＯ品質目標を定義する。
また、ＳＬＯは、必要とされるＳＬＯコンプライアンスレベル（単にＳＬＯコンプライアンスと短縮されることが多い）も有することができる。
このＳＬＯコンプライアンスレベルは、ＳＬＯ品質目標を満たさなければならない評価期間のパーセンテージを示す。
その結果、ＳＬＯは、たとえば、最大許容可能サーバ応答時間が１０ｍｓであること（ＳＬＯ品質目標）、及び、評価期間の９７％についてこれを順守しなければならないこと（ＳＬＯコンプライアンスレベル）を定義することができる。
【０００５】
ＳＬＯは、階層的に配列することができ、たとえば、サーバが評価期間の少なくとも９８％について利用可能でなければならないことを定義するＳＬＯコンプライアンスレベルは、自由なメモリの最小量、最大ＣＰＵ負荷等を定義するＳＬＯ品質目標に依存する場合がある。
【０００６】
ＳＬＡを順守してきたかどうかを評価期間の終了時に判断するには、さまざまなＳＬＯによって定義されるような、ＩＴインフラストラクチャの関連のあるコンポーネント又は構成アイテム（ＣＩ）を監視すること、及び、評価期間の間、性能データを定期的に記録することが必要である。
Hewlett-Packard OpenViewアプリケーションスイートの一部であるHewlett-Packardのサービスレベルマネージャ（Service Level Manager）という製品等の解決法によって、ＩＴインフラストラクチャのコンポーネントから性能データを収集することが可能になる。
【０００７】
記録された性能データは、次に、解析されて、評価期間の終了時に、ＳＬＡが順守されたかどうかを判断することができる。
【０００８】
ＳＬＡは、一般に、契約上の義務をサービスプロバイダに課すので、ＳＬＡを順守できない場合、結果として、契約上のペナルティが課される可能性がある。
しかし一方で、ＳＬＡ要件を満たすことがサービスプロバイダにとって重要であると同時に、サービスを提供するコストも重要である。
【０００９】
たとえば、サービスプロバイダが、ＳＬＡを確実に順守するのに役立つようにＩＴインフラストラクチャのコンポーネントを過剰仕様にすることは可能であるが、コンポーネントを過剰仕様にすると、通常はかなり高価になる。
さらに、コンポーネントを過剰仕様にすると、結果として、不必要な冗長性がもたらされるおそれがある。
他方、コンポーネントを不足仕様にすると、通常は、初期コストが下がる場合があるが、ＳＡＬコンプライアンスを危険な状態にもするおそれがあり、したがって、ペナルティを受ける危険性が増加するおそれがある。
【００１０】
ＩＴインフラストラクチャの一般的な複雑さ及びＩＴインフラストラクチャのコンポーネントの多くの場合に複雑な相互依存関係に加えて、１つのＳＬＡが複数の階層的なＳＬＯに依存でき、且つ、各ＳＬＯがさらに複数の構成アイテムに依存できる方法のために、ＩＴインフラストラクチャの改良及びＩＴインフラストラクチャに対する修正を行うことができるかどうかを正確に求めることは本来的に難しい。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
したがって、本発明の１つの目的は、上述した問題の少なくともいくつかを克服すること、又は、少なくとも緩和することである。
【課題を解決するための手段】
【００１２】
本発明の第１の態様によると、サービスを提供するコンピュータインフラストラクチャを解析する方法であって、サービスの目的とする品質レベルは、サービスレベル品質目標及び関係するコンプライアンスレベルを定義する少なくとも１つのサービスレベル目標によって定義され、コンピュータインフラストラクチャは、複数のコンポーネントを備える、サービスを提供するコンピュータインフラストラクチャを解析する方法が提供される。
当該方法は、選択されたサービスレベル目標の第１のサービスレベル目標のコンプライアンスデータを得ることであって、コンプライアンスデータは、コンピュータインフラストラクチャから収集されたデータを使用して計算される、第１のサービスレベル目標のコンプライアンスデータを得ること、選択されたサービスレベル目標の第２のサービスレベル目標のコンプライアンスデータを、収集されたデータ及び選択されたサービスレベル品質目標についてその目標を満たす値を部分的に使用して計算すること、第１のデータと第２のデータとの間の差を計算すること、及び計算された差に基づいて、修正に適した１つ又は２つ以上のコンポーネントを特定することを含む。
【００１３】
本発明の第２の態様によると、サービスを提供するコンピュータインフラストラクチャを解析する装置であって、サービスの目的とする品質レベルは、サービスレベル品質目標及び関係するコンプライアンスレベルを定義する少なくとも１つのサービスレベル目標によって定義され、コンピュータインフラストラクチャは、複数のコンポーネントを備える、サービスを提供するコンピュータインフラストラクチャを解析する装置が提供される。
当該装置は、選択されたサービスレベル目標の第１のサービスレベル目標のコンプライアンスデータを得る手段であって、コンプライアンスデータは、コンピュータインフラストラクチャから収集されたデータを使用して計算される、第１のサービスレベル目標のコンプライアンスデータを得る手段と、選択されたサービスレベル目標の第２のサービスレベル目標のコンプライアンスデータを、収集されたデータ及び選択されたサービスレベル品質目標についてその目標を満たす値を部分的に使用して計算する処理ロジックと、第１のデータと第２のデータとの間の差を計算する差計算モジュールと、計算された差に基づいて、修正に適した１つ又は２つ以上のコンポーネントを特定する分析モジュールとを含む。
【００１４】
次に、添付図面について、本発明の実施の形態を、限定ではなく単なる例として説明することにする。
【発明を実施するための最良の形態】
【００１５】
次に図１を参照して、本発明の一実施の形態によるシステム１００のブロック図が示されている。
【００１６】
一般に知られている方法でＩＴインフラストラクチャ１０４の構成アイテム（ＣＩ）又はコンポーネントを監視するサービスレベルマネージャ１０２が設けられている。
次に、完全を期すために、サービスレベルマネージャ１０２のオペレーションの簡単な概略を与える。
ＩＴインフラストラクチャ１０４は、顧客（図示せず）にサービスを提供するためのＩＴコンポーネント（図示せず）を配置したものを備える。
サービスレベルマネージャ１０２は、たとえば構成アイテム（ＣＩ）階層を使用して、ＩＴインフラストラクチャ１０４をモデル化する。
ＩＴインフラストラクチャ１０４のモデルは、たとえば、構成管理データベース（ＣＭＤＢ）（図示せず）から得ることもできるし、他のあらゆる適切な方法で得ることもできる。
【００１７】
構成アイテムは、当該技術分野で既知のように、コンピュータハードウェア等の個別に管理できるあらゆるアイテム又はユニットを指す。
このコンピュータハードウェアは、コンピュータサーバ、コンピューティングデバイス、ネットワーク、スイッチ、ルータ等である。
【００１８】
各構成アイテムについて、１つ又は２つ以上の測定可能なメトリックを定義することができる。
定義されたメトリックは、各ＣＩの可用性ステータスを判断することを可能にするように適切に選ばれる。
たとえば、ＣＩは、コンピュータサーバとすることができ、関係するメトリックは、ＣＰＵ負荷、空きディスク空間、利用可能なメモリ、喪失パケットの個数等とすることができる。
【００１９】
また、モデルは、階層モデル内でのコンポーネントステータスの伝播を定義する１つ又は２つ以上のルールも含むことができる。
たとえば、コンピュータサーバの可用性ステータスをネットワークストレージアレイの可用性に依存させることができる。
【００２０】
サービスレベルマネージャ１０２は、ＩＴインフラストラクチャ１０４を通じて提供されているサービスに適用可能な１つ又は２つ以上のＳＬＡの詳細にアクセスすることもできる。
【００２１】
上述したように、ＳＬＡは、合意されたサービスレベルを定義する。
たとえば、ＩＴインフラストラクチャ１０４によって提供されたサービスが、電子メールサービスである場合、複数のサービスレベルを定義することができ、各サービスレベルは、ＳＬＡによって定義される。
たとえば、ハイエンド顧客には、「ゴールド」レベルＳＬＡを定義することができ、ローエンドユーザには、「シルバー」レベルＳＬＡを定義することができる。
【００２２】
「ゴールド」レベルＳＬＡは、たとえば、サーバ応答時間が、評価期間の少なくとも９９％について１秒未満であることを必要とするＳＬＯ、及び、空きディスク空間の量が評価期間の９８％について１０ＧＢよりも大きいことを必要とするＳＬＯを定義することができる。
「シルバー」レベルＳＬＡは、これよりも厳しくない要件を定義することができる。
【００２３】
ＩＴインフラストラクチャ１０４が、適切なサービスを提供するように動作する間、サービスレベルマネージャ１０２は、定義された各ＣＩについて定義されたメトリックを測定し、それらメトリックの値をデータウェアハウス１０６に記録する。
【００２４】
リアルタイムＣＩ可用性ステータス又は準リアルタイムＣＩ可用性ステータスは、定義されたメトリック及び伝播ルールに基づいて、サービスレベルマネージャ１０２により計算可能であり、その結果も、データウェアハウス１０６に記憶することができる。
【００２５】
次に、さらに図２を参照して、本発明の一実施の形態を説明することにする。
図２は、ＳＬＯアナライザ１１２が取ることができる処理ステップの例の概要を説明したフロー図である。
【００２６】
ＳＬＯアナライザ１１２は、たとえばデータウェアハウス１０６から、解析されるＳＬＡを選択する。
選択されたＳＬＡは、ＩＴインフラストラクチャ１０４によって提供されたサービスに関係するものである。
ＳＬＡは、ＸＭＬフォーマット等の適切なコンピュータ可読フォーマットで提供することができる。
いくつかのサービスは、２つ以上のＳＬＡがカバーできること、及び、以下に説明する技法は、複数のＳＬＡに等しく適用されることが、当業者には十分理解されよう。
一方、説明を明確にするために、以下の説明は、単一のＳＬＡのみを説明する。
【００２７】
ステップ２０２において、選択されたＳＬＡに定義されたＳＬＯコンプライアンスレベルが選ばれる。
最後に完了したＳＬＡ評価期間等の履歴評価期間が選ばれ、その期間のＳＬＯコンプライアンスレベルが、前に求められてデータウェアハウス１０６に記憶されている場合には得られ（ステップ２０４）、そうでない場合には、その期間のＳＬＯコンプライアンスレベルは、データウェアハウス１０６に記憶された記憶履歴メトリックデータを使用して計算される。
【００２８】
ステップ２０６において、ＳＬＯアナライザ１１２は、選ばれた履歴評価期間について、データウェアハウス１０６から得られた履歴メトリックデータを使用して、計算されたＳＬＯコンプライアンスレベルを再評価する。
一方、この再評価は、ＳＬＯコンプライアンスレベルが依存するＳＬＯ品質目標の１つ又は２つ以上の値を、その目標を満たす値に修正することによって行われる。
たとえば、サーバ応答時間が評価期間の少なくとも９９％について１秒未満であるべきこと、及び、空きディスク空間の量が評価期間の９８％について１０ＧＢよりも大きいことをＳＬＯが定義している場合、ＳＬＯ品質目標値は、再計算のために、サーバ応答時間がたとえば０．９９９秒であり、空きディスク空間の量が１０．００１ＧＢであるように修正される。
【００２９】
再計算されたＳＬＯコンプライアンスレベルは、次に、履歴ＳＬＯコンプライアンスレベルと比較され（ステップ２０８）、それらのコンプライアンスレベルの間の差が、適切なメモリ又はストレージ媒体に記録される（ステップ２１０）。
【００３０】
上記ステップ２０２〜２１２は、評価中のＳＬＡに定義されたコンプライアンスレベルを有する各ＳＬＯについて繰り返される。
【００３１】
ＳＬＯコンプライアンスレベルのすべてが再評価されると、ステップ２１４において、重要なＳＬＯが、評価中のＳＬＡ内から特定される。
【００３２】
重要なＳＬＯは、複数の異なる方法で特定することができる。
たとえば、測定されたＳＬＯコンプライアンスレベルと再計算されたＳＬＯコンプライアンスレベルとの間の差が非常に小さいか、又は、第１の所定の範囲内にある場合には、これは、ＳＬＯコンプライアンスレベルが依存するＳＬＯ品質目標の少なくともいくつかが、ＳＬＯコンプライアンスレベルを満たすことを助けることにほとんど影響を与えないことを意味している。
これは、たとえば、そのＳＬＯ品質目標に関係する構成アイテムが「過剰仕様」であるおそれがあることをさらに意味するのに使用することができる。
【００３３】
たとえば、コンピュータサーバの最小空きメモリが、評価期間の９５％よりも大きい期間について１０ＭＢよりも大きくなければならないことを定義するＳＬＯを考える。
測定されたＳＬＯコンプライアンスレベルが９９％であり、再計算されたＳＬＯコンプライアンスが１００％であった場合、これは、たとえば、サーバで使用される物理メモリの量が、サービスのオペレーション中、実際に必要とされる量よりも多い場合があることを示し得る。
したがって、対応する構成アイテム（すなわち、コンピュータサーバの物理コンピュータメモリ）にダウングレードが可能であることを強調することができる。
【００３４】
測定されたＳＬＯコンプライアンスレベルと再計算されたＳＬＯコンプライアンスレベルの差が大きいか、又は、第２の所定の範囲の間にある場合、これは、ＳＬＯコンプライアンスレベルが依存するＳＬＯ品質目標の少なくともいくつかが、ＳＬＯコンプライアンスレベルを満たすことを助けることに大きな影響を与えることを意味している。
これは、たとえば、それらのＳＬＯ品質目標に関係する構成アイテムが「不足仕様」であるおそれがあることをさらに意味するのに使用することができる。
再び、コンピュータサーバの最小空きメモリが、評価期間の９５％よりも大きい期間について１０ＭＢよりも大きくなければならないことを定義するＳＬＯの例を考える。
測定されたＳＬＯコンプライアンスレベルが９０％であり、再計算されたＳＬＯコンプライアンスが１００％であった場合、これは、たとえば、サーバで使用される物理メモリの量がサービスのオペレーション中、実際に必要とされる量よりも少ない場合があることを示し得る。
したがって、対応する構成アイテム（すなわち、コンピュータサーバの物理コンピュータメモリ）にアップグレードが可能であることを強調することができる。
第１の所定の範囲及び第２の所定の範囲は、特定の要件に応じて、あらゆる適した方法で選ぶことができる。
たとえば、第１の所定の範囲は、０％と１％との間になるように選ぶことができ、第２の所定の範囲は、１％と１００％との間となるように選ぶことができる。
【００３５】
１つ又は２つ以上の重要なＳＬＯが、上述した技法を使用して選択されると、異なる構成アイテムを修正できる量を求めるために、第２段階を実行することができる。
この段階は、シナリオアナライザ１１４によって実行される。
シナリオアナライザ１１４は、図３を参照してさらに詳細に説明する。
【００３６】
ステップ３０２において、シナリオアナライザ１１４は、ＳＬＯアナライザ１１２から、上述したように選択された１つ又は２つ以上の重要なＳＬＯの詳細を受け取る。
説明のために、コンピュータサーバの最小空きメモリが、評価期間の９５％よりも大きな期間について１０ＭＢよりも大きくなければならないことを定義するＳＬＯが受け取られるものとする。
受信されたＳＬＯは、解析されて、そのＳＬＯが関係する構成アイテムが決定され（ステップ３０４）、関係するメトリックも決定される（ステップ３０６）。
本例では、特定された構成アイテムは、コンピュータサーバの物理メモリであり、特定されたメトリックは、利用可能な空きメモリの量である。
【００３７】
構成アイテムの選ばれたメトリック値は、次に、適切な方法で変更される。
たとえば、現在の物理メモリサイズが１ＧＢである場合、５１２ＭＢの物理メモリサイズを使用することができ、ＳＬＯコンプライアンスのパーセンテージが再評価される。
メトリック値に対する複数の変更を或る範囲の値にわたって行うことができ、ＳＬＯコンプライアンス値を毎回再計算することができる。
【００３８】
このように、全体的なＳＬＯコンプライアンスのパーセンテージについて物理メモリの量を増減する効果を正確に求めることができる。
複数の再評価の結果から、サーバの好ましいメモリサイズを決定することができ、不必要に高い帯域幅も不必要に低い帯域幅も確実に選ばれないようにすることができる。
【００３９】
上記ステップは、上述したようなＳＬＯアナライザ１１２によって特定された重要な各ＳＬＯについて繰り返すことができる。
【００４０】
重要なＳＬＯのそれぞれが解析されると、それら重要なＳＬＯのそれぞれの好ましい値は、それら重要なＳＬＯの好ましいメトリック値と共に、優先順位アナライザ１１６へ送信することができる。
優先順位アナライザ１１６は、財務データストア１１０に記憶された財務データを使用して、メトリック値の提案された変更が、行う価値があるものかどうかを財務の観点から判断する。
財務データストアは、たとえば、あらゆる財務ペナルティに関係する情報を保持することに加えて、たとえば、異なるＩＴインフラストラクチャコンポーネントに対する修正を行うことに関係するコスト情報も保持する。
このようなコスト情報には、たとえば、あらゆる特定のハードウェアコンポーネントのコスト、見積もられたインストールコスト、メンテナンスコスト等が含まれ得る。
資産マネージャ１０８を使用して、データストア１１０の財務データの少なくとも一部を提供することができる。
【００４１】
優先順位アナライザ１１６は、提案されたように構成アイテムを修正するコスト及びサービスについてＳＬＡにより課されたあらゆるペナルティを支払うコストを考慮し、財務データを使用して、特定された構成アイテムに対する修正が財務的に有益であるかどうか判断する。
このように、提案された構成アイテムの修正のすべてが解析され、それら提案のサブセットの詳細が、変更管理システム１１８へ転送される。
【００４２】
変更管理システム１１８は、たとえば、可能な場合には、修正を自動的に適用するように構成することができる。
たとえば、いくつかの状況では、修正は、適切なソフトウェアアップグレードによって適用される場合もあるし、追加された資源ライセンスの取得を通じて適用される場合もある。
これは、たとえば、プロセッサのプールが、要求に応じて利用可能である場合に当てはまる可能性がある。
或いは、変更管理システム１１８は、適切なハードウェアアップグレード又はダウングレードを実行するために、提案された変更に対して人間のオペレータに注意を喚起することができる。
【００４３】
さらに別の実施の形態では、変更管理システム１１８は、たとえば、十分に活用されていない構成アイテムを使用して、過剰使用されている構成アイテムの負荷を削減することを可能にするようにＩＴインフラストラクチャ１０４を再構成するのに使用される。
たとえば、過剰使用されているストレージ媒体に記憶されたデータベースを、大量の空き空間を有するストレージ媒体に移動させることができる。
変更管理システムは、この場合、適宜、ネットワーク識別子又はリンクを更新することが必要な場合もあるし、或いはネットワーク識別子又はリンクを、移動されたデータベースへ移動させることが必要な場合もある。
【００４４】
本発明の実施の形態は、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの組み合わせの形で実現できることが十分理解されよう。
このようなどのソフトウェアも、たとえば、消去可能であろうとなかろうと、再書き込み可能であろうとなかろうと、ＲＯＭのようなストレージデバイス等の揮発性ストレージ又は不揮発性ストレージの形で記憶することもできるし、たとえば、ＲＡＭ、メモリチップ、デバイス、集積回路等のメモリの形で記憶することもできるし、たとえば、ＣＤ、ＤＶＤ、磁気ディスク、磁気テープ等の光可読媒体又は磁気可読媒体に記憶することもできる。
これらのストレージデバイス及びストレージ媒体は、実行されると本発明の実施の形態を実施する１つ又は複数のプログラムを記憶するのに適したマシン可読ストレージの実施の形態であることが十分理解されよう。
したがって、実施の形態は、上述したようなシステム又は方法を実施するためのコードを含むプログラム、及び、このようなプログラムを記憶するマシン可読ストレージを提供する。
さらに、本発明の実施の形態は、ワイヤ接続又はワイヤレス接続で運ばれる通信信号等のあらゆる媒体を介して電子的に搬送することもでき、実施の形態は、それらも適切に包含する。
【図面の簡単な説明】
【００４５】
【図１】本発明の一実施の形態によるシステムのブロック図である。
【図２】図１に示すサービスレベル合意アナライザが取ることができる処理ステップの例の概要を説明したフロー図である。
【図３】図１に示すシナリオアナライザが取ることができる処理ステップの例の概要を説明したフロー図である。
【符号の説明】
【００４６】
１０２  サービスレベルマネージャ
１０４  ＩＴインフラストラクチャ
１０６  データウェアハウス
１０８  資産マネージャ
１１０  財務データ
１１２  ＳＬＯアナライザ
１１４  シナリオアナライザ
１１６  優先順位アナライザ
１１８  変更管理
【図１】
2008108262.tif 000003
【図２】
2008108262.tif 000004
【図３】
2008108262.tif 000005
【外国語明細書】
IMPROVING COMPUTER NETWORKS
Field of the Invention
The present invention relates generally to the field of computing. 
Background of the Invention
Computer systems are frequently used in enterprise environments to provide services to customers. Example services include providing telecommunication networks, Internet-based shopping services, storage services, and so on.
Whatever the service concerned service providers are generally under an obligation to ensure that an agreed quality of service is provided to their customers over the period for which the service is to be provided.
Service level agreements (SLA) are generally used between service providers and their customers to define an agreed quality of service for a particular service over a predetermined period of time, referred to hereinafter as the evaluation period. An SLA typically defines multiple service level objectives (SLO) that must be met in order for the SLA to be considered complied with. An SLO typically defines an SLO quality objective, such as maximum acceptable server response time, a maximum acceptable transaction processing time, a minimum acceptable network bandwidth, etc. An SLO may also have a required SLO compliance level (often shortened to simply SLO compliance) which indicates the percentage of the evaluation period that the SLO quality objective must be met. So, an SLO may define, for example, that a maximum acceptable server response time is 10ms (SLO quality objective) and that this must be complied with for 97% of the evaluation period (SLO compliance level).
SLOs may be hierarchically arranged, for example an SLO compliance level defining that a server must be available for at least 98% of the evaluation period may be dependent on an SLO quality objective defining the minimum amount of free memory, the maximum CPU load, etc.
To determine whether an SLA has been complied with at the end of an evaluation period it is necessary to monitor relevant components or configuration items (CI) of the IT infrastructure, as defined by the various SLOs, and to periodically record performance data during the evaluation period. Solutions, such as the Hewlett-Packard's Service Level Manager product, part of the Hewlett-Packard OpenView suite of applications, enable performance data to be collected from components of an IT infrastructure.
The recorded performance data can then be analysed to determine, at the end of the evaluation period, whether the SLA was complied with.
Since SLAs generally impose contractual obligations on a service provider, failure to comply with an SLA can lead to contractual penalties being imposed. However, whilst meeting SLA requirements is important to service providers, the cost of providing the service is also important.
For example, whilst it is possible for service providers to over specify components in an IT infrastructure to help ensure that an SLA is complied with, over specifying components typically comes at a price. Furthermore, over specifying components may lead to unnecessary redundancy. On the other hand, under specifying components may typically result in lower initial cost but may also put SLA compliance at risk and hence increase the risk of incurring penalties.
Due to the general complexity of IT infrastructures and the often complex interdependencies of IT infrastructure components as well as the way that an SLA may be dependent of multiple hierarchical SLOs, and each SLO may in turn be dependent on multiple configuration items, it is inherently difficult to accurately determine where improvements in or modifications to the IT infrastructure can be made.
Accordingly, one aim of the present invention is to overcome, or at least alleviate, at least some of the above-mentioned problems.
Summary of the Invention
According to a first aspect of the present invention, there is provided a method of analysing a computer infrastructure providing a service, an intended quality level of the service being defined by at least one service level objective defining a service level quality objective and a related compliance level, the computer infrastructure comprising a plurality of components. The method comprises obtaining first service level objective compliance data for a selected service level objective, the compliance data being calculated using data collected from the computer infrastructure, calculating second service level objective compliance data for the selected service level objective using in part the collected data and for a selected service level quality objective a value that meets that objective, calculating a difference between the first and second data, and identifying, based on the calculated difference, one or more components suitable for modification.
According to a second aspect of the present invention, there is provided a apparatus for analysing a computer infrastructure providing a service, an intended quality level of the service being defined by at least one service level objective defining a service level quality objective and a related compliance level, the computer infrastructure comprising a plurality of components. The apparatus comprises means for obtaining first service level objective compliance data for a selected service level objective, the compliance data being calculated using data collected from the computer infrastructure, processing logic for calculating second service level objective compliance data for the selected service level objective using in part the collected data and for a selected service level quality objective a value that meets that objective, a difference calculation module for calculating a difference between the first and second data, and an analysis module for identifying, based on the calculated difference, one or more components suitable for modification.
Brief Description of the Drawings
Embodiments of the invention will now be described, by way of non-limiting example only, with reference to the accompanying diagrams, in which:
Figure 1 is a block diagram of a system according to one embodiment of the present invention;
Figure 2 is a flow diagram outlining example processing steps that may be taken by the service level agreement analyser shown in Figure 1; and
Figure 3 is a flow diagram outlining example processing steps that may be taken by the scenario analyser shown in Figure 1.
Detailed Description of the Preferred Embodiments
Referring now to Figure 1, there is shown a block diagram of a system 100 according to an embodiment of the present invention.
A service level manager 102 is provided to monitor configuration items (CI) or components of an IT infrastructure 104 in a generally known manner. For completeness a brief outline of operation of the service level manager 102 is now given. The IT infrastructure 104 comprises an arrangement of IT components (not shown) for providing a service to a customer (not shown). The service level manager 102 models the IT infrastructure 104, for example, using a configuration item (CI) hierarchy. The model for the IT infrastructure 104 may be, for example, obtained from a configuration management database (CMDB) (not shown) or in any other appropriate manner.
A configuration item, as is well known in the art, refers to any item or unit that can be individually managed, such as computer hardware such as computer servers, computing devices, networks, switches, routers, etc. 
For each configuration item one or more measurable metrics may be defined. The defined metrics are suitably chosen to enable an availability status for each CI to be determined. For example, a CI may be a computer server, and related metrics may be CPU load, free disk space, available memory, number of lost packets, and so on.
The model may also include one or more rules to define the propagation of component statuses within the hierarchical model. For example, the availability status of a computer server may be made dependent on the availability of a network storage array.
The service level manager 102 also has access to details of one or more SLAs applicable to a service being provided through the IT infrastructure 104.
As previously mentioned, an SLA defines an agreed level of service. For example, if the service provided by the IT infrastructure 104 is an email service a number of service levels may be defined, each service level being defined by an SLA. For instance, for high end customers a 'gold' level SLA may be defined and a 'silver' level SLA may be defined for lower end users.
The 'gold' level SLA may, for example, define SLOs that require server response times to be less than 1 second for at least 99% of the evaluation period, and that the amount of free disk space be greater than 10GB for 98% of the evaluation period. A 'silver' level SLA may define less rigorous requirements.
As the IT infrastructure 104 operates to provide the appropriate service the service level manager 102 measures the defined metrics for each defined CI and records their values in a data warehouse 106.
A real-time or near real-time CI availability status, based on the defined metrics and propagation rules, may be calculated by the service level manager 102 and the results also stored in the data warehouse 106.
An embodiment of the present invention will now be described with further reference to Figure 2 which is a flow diagram outlining example processing steps that may be taken by an SLO analyser 112.
The SLO analyser 112 selects, for example from the data warehouse 106, an SLA to be analysed. The selected SLA relates to a service provided by the IT infrastructure 104. The SLA may be provided in a suitable computer readable format, such as an XML format. Those skilled in the art will appreciate that some services may be covered by more than one SLA and the techniques described below apply equally to multiple SLAs. However, for clarity of explanation the following description only describes a single SLA.
At step 202 an SLO compliance level defined in the selected SLA is chosen. A historical evaluation period, such as the last completed SLA evaluation period, is chosen and the SLO compliance level for that period is either obtained (step 204), if previously determined and stored in the data warehouse 106, or otherwise is calculated using the stored historical metric data stored in the data warehouse 106.
At step 206 the SLO analyser 112 re-evaluates the calculated SLO compliance level using the historical metric data, obtained from the data warehouse 106, for the chosen historical evaluation period. However, the re-evaluation is performed by modifying the values of one or more of the SLO quality objectives on which the SLO compliance level depends to a value that meets that objective. For example, if an SLO defines that a server response times is to be less than 1 second for at least 99% of the evaluation period, and that the amount of free disk space be greater than 10GB for 98% of the evaluation period, then the SLO quality objective values are modified, for the purposes of the recalculation, such that the server response time is, for example, 0.999s and the amount of free disk space is 10.001GB.
The re-calculated SLO compliance level is then compared (step 208) with the historical SLO compliance level and the difference between the compliance levels is recorded (step 210) in a suitable memory or storage media.
The above steps 202 to 212 are repeated for each SLO having a defined compliance level in the SLA under evaluation. 
Once all of the SLO compliance levels have been re-evaluated, at step 214, key SLOs are identified from within the SLA under evaluation.
Key SLOs may be identified in a number of different ways. For example, where the difference between a measured SLO compliance level and a recalculated SLO compliance level is very small or between first predefined limits, this implies that at least some of the SLO quality objectives on which the SLO compliance level depends have little impact on the helping the SLO compliance level being met. This may, for instance, be used to further imply that the configuration items related to that SLO quality objective may be 'over specified'. 
Take, for example, an SLO that defines that the minimum free memory of a computer server must be greater than 10MB for greater than 95% of the evaluation period. If the measured SLO compliance level was 99% and the recalculated SLO compliance was 100% this may show, for example, that the amount of physical memory used in the server may be more than that actually required during operation of the service. The corresponding configuration item (i.e. the physical computer memory of the computer server) may thus be highlighted for possible downgrading.
If the difference between a measured SLO compliance level and a recalculated SLO compliance level is higher, or between second predefined limits, this implies that at least some of the SLO quality objectives on which the SLO compliance level depends have a significant impact on the helping the SLO compliance level being met. This may, for instance, be used to further imply that the configuration items related to those SLO objectives may be 'under specified'. Taking again the example of an SLO defines that minimum free memory of a computer server must be greater than 10MB for greater than 95% of the evaluation period. If the measured SLO compliance level was 90% and the recalculated SLO compliance was 100% this may show, for example, that the amount of physical memory used in the server may be less than that actually required during operation of the service. The corresponding configuration item (i.e. the physical computer memory of the computer server) may thus be highlighted for possible upgrading. The first and second predefined limits may be chosen in any suitable manner, depending on particular requirements. For example, the first predefined limits may be chosen to be between 0 and 1% and second predefined limits between 1% and 100%.
Once one or more key SLOs have been selected using the above-described techniques a second stage may be performed in order to determine an amount by which different configuration items may be modified. This stage is performed by a scenario analyser 114, which is described in further detail with reference to Figure 3.
At step 302 the scenario analyser 114 receives from the SLO analyser 112 details of one or more key SLOs selected as described above. For the purposes of explanation an SLO defining that minimum free memory of a computer server must be greater than 10MB for greater than 95% of the evaluation period is received. The received SLO is analysed to determine the configuration items to which it relates (step 304) and also the metrics concerned (step 306). In the present example the configuration item identified is the physical memory of a computer server and the identified metric is the amount of free memory available.
The chosen metric value of the configuration item is then changed in a suitable manner. For example if the current physical memory size is 1GB, a physical memory size of 512MB may be used and the SLO compliance percentage is re-evaluated. Multiple changes to the metric value may be made over a range of values and the SLO compliance value may be recalculated each time.
In this way the effect of increasing or decreasing the amount of a physical memory on the overall SLO compliance percentage can be accurately determined. From the results of the multiple re-evaluations a preferred memory size for the server can be determined ensuring that neither an unnecessarily high or low bandwidth is chosen.
The above-steps may be repeated for each key SLO identified by the SLO analyser 112 as described above.
When each of the key SLOs have been analysed, the preferred values for each of them, along with their preferred metric values may be sent to a priority analyser 116. The priority analyser 116 uses financial data stored in a financial data store 110 to determine whether the proposed changes in metric values are worthwhile from a financial perspective. The financial data store holds, for example, information relating to any financial penalties as well as, for example, cost information relating to making modifications to different IT infrastructure components. Such cost information may include, for example, the cost of any specific hardware components, estimated installation costs, maintenance costs etc. An asset manager, 108, may be used to provide at least some of the financial data in the data store 110.
The priority analyser 116 determines, using the financial data, whether the modification to the identified configuration item is financially beneficial, taking into account the cost of modifying the configuration item as suggested and the cost of paying any penalties imposed by the SLA for the service. In this way, all of the suggested configuration item modifications are analysed and details of a sub-set of those suggestions are forwarded to a change management system 118.
The change management system 118 may, for instance, be arranged to automatically apply modifications where possible. For instance, in some circumstances a modification may be applied by a suitable software upgrade or through the acquisition of an additional resource license. This could be the case, for example, where a pool of processors is available on demand. Alternatively, the change management system 118 can alert a human operator to the suggested changes in order for appropriate hardware upgrades or downgrades to be effected. 
In a further embodiment the change management system 118 is used to reconfigure the IT infrastructure 104 to enable, for example, underused configuration items to be used to reduce the load on overused configuration items. For example, a database stored on an overused storage medium may be moved to a storage medium having a large amount of free space. The change management system, in this case, may have to update or move network identifiers or links to the moved database as appropriate. 
It will be appreciated that embodiments of the present invention can be realised in the form of hardware, software or a combination of hardware and software.  Any such software may be stored in the form of volatile or non-volatile storage such as, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape.  It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs that, when executed, implement embodiments of the present invention.  Accordingly, embodiments provide a program comprising code for implementing a system or method as described above and a machine readable storage storing such a program.  Still further, embodiments of the present invention may be conveyed electronically via any medium such as a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.
1. A method of analysing a computer infrastructure providing a service, an intended quality level of the service being defined by at least one service level objective defining a service level quality objective and a related compliance level, the computer infrastructure comprising a plurality of components, 
the method comprising:
obtaining first service level objective compliance data for a selected service level objective, the compliance data being calculated using data collected from the computer infrastructure;
calculating second service level objective compliance data for the selected service level objective using in part the collected data and for a selected service level quality objective a value that meets that objective;
calculating a difference between the first and second data; and
identifying, based on the calculated difference, one or more components suitable for modification.
2. The method of claim 1, further comprising, where the quality level of the service is defined by a plurality of service level objectives, repeating the step of calculating second service level objective data for each service level quality objective of each service level objective.
3. The method of claim 1 or 2, wherein the step of identifying further comprises, where the calculated difference is within first predetermined limits identifying a component for modification in a first manner, and where the calculated difference is within second predetermined limits identifying a component for modification in a second manner.
4. The method of claim 3, wherein the step of identifying one or more suitable components comprises prioritising a predetermined number of components suitable for modification, the step of prioritising further comprising accessing financial data relating to the proposed modification.
5. The method of claim 3 or 4, further comprising, modifying at least one of the identified components in accordance with the identified manner.
6. The method of claim 5, further comprising upgrading components identified to be modified in a first manner and downgrading components identified to be modified by a second manner.
7. The method of claim 3, 4, 5 or 6, further comprising forwarding relating to the components identified for modification to a change management system for the modifications to be performed.
8. The method of any previous claim, wherein the collected data is collected from the computer infrastructure during operation of the service over a predetermined period.
9. Apparatus for analysing an IT infrastructure operable in accordance with any of claims 1 to 8.
ABSTRACT
According to one embodiment of the present invention, there is provided a method of analysing a computer infrastructure providing a service, an intended quality level of the service being defined by at least one service level objective defining a service level quality objective and a related compliance level, the computer infrastructure comprising a plurality of components, the method comprising: obtaining first service level objective compliance data for a selected service level objective, the compliance data being calculated using data collected from the computer infrastructure; calculating second service level objective compliance data for the selected service level objective using in part the collected data and for a selected service level quality objective a value that meets that objective; calculating a difference between the first and second data; and identifying, based on the calculated difference, one or more components suitable for modification.
[FIGURE 1]
2008108262.tif 000006
2008108262.tif 000007
2008108262.tif 000008