アプリケーションシステムのストレージリソースを識別する方法およびシステム
本発明は、デジタル処理環境内、より詳細には、デジタルストレージ環境内で、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを可能にするとともに、デジタルストレージ環境内の任意のストレージ要素に負荷を生じさせているアプリケーションセット（他のソフトウェアプログラム）の階層イメージを提供するように動作可能な方法、装置、システム、およびコンピュータプログラムコード（ソフトウェア）製品を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、２００６年１２月２１日に出願され「Methods and Systems for Identifying Application System Storage Resources（アプリケーションシステムストレージリソースを識別する方法およびシステム）」という名称の米国仮特許出願第６０／８７１４４４号（代理人整理番号：ＡＫＲ−１１４−ＰＲ）の優先権の利益を主張するものであり、この仮特許出願を、その全体が記載されているかのように参照により本明細書に援用する。
【０００２】
本特許出願は、２００７年７月５日に出願され「Managing Application System Load（アプリケーションシステムの負荷管理）」という名称の米国特許出願第１１／７７３８２５号（代理人整理番号：ＡＫＲ−１１０−ＵＳ）の一部継続出願（ＣＩＰ）でもあり、この特許出願も参照により本明細書に援用され、その詳細な説明および図面が本明細書において記載される。そして、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）は、２００６年７月６日に出願された米国仮特許出願第６０／８０６，６９９号（ＡＫＲ−１１０−ＰＲ）の優先権の利益を主張するものであり、この仮特許出願を、その全体が記載されているかのように参照により本明細書に援用する。
【０００３】
発明の分野
本発明は、一般には、デジタル処理システム、装置、およびネットワークに関し、より詳細には、アプリケーション性能および自己管理システムの分野に関する。さらにより詳細には、本発明は、システムリソースで生じた性能問題を、性能制約システムリソースに対して負荷を生み出しているアプリケーションサーバ、アプリケーション、およびアプリケーションタスクに再びマッピングする方法、システム、および装置に関する。
【背景技術】
【０００４】
発明の背景
多くのストレージプラットフォームでは、ストレージ管理者がストレージリソースを異なるハードウェアサーバに割り振りそして割り当てることができる。単一のハードウェアサーバは複数のアプリケーションを並行に実行することができる。単一のアプリケーションはいくつかの並行タスクを具現することができる。単一のアプリケーションは、通常、いくつかのシステムリソースを利用する。アプリケーション性能は、アプリケーションのシステムリソースへのアクセスを最適化できる場合、潜在的に加速することができる。
【０００５】
不都合なことに、従来のストレージプラットフォームでは、ユーザまたはシステム管理者は、個々のアプリケーションがシステムリソースセットをどのように利用するかについて殆ど指針を有さない。同じハードウェアサーバで並行に実行されている２つのアプリケーションが、共通のシステムリソースに対する競合により、ストールする場合があり得る。システムリース競合は識別することができるが、アプリケーションからそのアプリケーションを使用しているシステムリソースへのマッピング、およびこの逆のマッピングを識別できない場合を除き、問題の原因を完全には知ることなく、性能ボトルネックを修復しようと試みることができる。
【０００６】
より詳細には、アプリケーションは、多くの場合、ストレージエリアネットワーク（ＳＡＮ）を通して共通のストレージシステムを共有するサーバにホストされる。アプリケーションの要求と中央ストレージの能力との不均衡は、中央ストレージリソースを共有しているアプリケーションの全体性能を不良にし得る。この不均衡は、サーバ（ＣＰＵおよびメモリ）、バスアダプタ、スイッチ、ディスクコントローラ、およびディスクアレイを含むいくつかの任意の異なるシステム要素のアプリケーションによる使用に影響を及ぼし得る。
【０００７】
個々のアプリケーションは、サーバとサポートしているストレージサブシステムとの間のパス内の任意の特定のシステム要素に対して大きすぎる負荷をかけている場合、性能の影響を受け得る。さらに、同じまたは独立したサーバで実行されている複数のアプリケーションは、ネットワークおよびストレージがアプリケーションおよびサーバで共有されている場合、互いの性能に影響を及ぼし得、多くの場合、ＳＡＮが共有リソースとして導入される。
【０００８】
任意のアプリケーションの性能は、アプリケーションが単一の装置に対して大きすぎる負荷を生成する場合、または複数のアプリケーションが多くの要求でシステムを溢れさせる場合に低下し得、それにより、ストレージシステムが集合負荷にサービス提供することができなくなる。
【０００９】
ストレージシステムにアクセスする際にあるアプリケーションが別のアプリケーションに対して生じさせる干渉は、性能の大きなばらつきに繋がり得る。より予測可能なアプリケーション性能を提供しようという試みは、多くの場合、システムリソース（例えば、ＣＰＵ、メモリ、ネットワーク、ディスク）のオーバープロビジョニングに繋がる。
【００１０】
ストレージプラットフォームのリソースに関連する問題のうちのいくつかに対処する既知の一方法は、ストレージリソース管理（ＳＲＭ）であり、通常、ＳＲＭは、割り振られたリソースセットのトポロジを発見し、その性能の健康状態を評価する計測機能を提供する。システム性能の健康状態は、応答時間およびストレージ帯域幅に関して測定することができる。ＳＲＭは、性能が制約されたストレージリソースを検出し、これをストレージ管理者に報告することができる。
【００１１】
ネットワーク化された特定のストレージリソースセットを使用するアプリケーションセットの識別を可能にするには、ストレージシステムとアプリケーションとの間の完全なマッピングが要求される。マッピングは、（１）アプリケーションによって使用されているすべてのシステムリソース（例えば、個々のディスク、ディスクコントローラ、バスアダプタ）についての情報および（２）ストレージシステムからアプリケーションサーバへのパス（ボリュームＬＵＮマッピングおよびネットワークスイッチを含む）の両方を含まなければならない。
【００１２】
例として、米国特許第７，０５８，５４５号（「’５４５号特許」）は、参照により本明細書に援用され、ストレージ装置とアプリケーションとの間の論理データパスおよび物理データパスを識別するが、パスを構成するすべてのシステムリソースを識別する能力を有さない方法を記載している。’５４５号特許は、データパスを管理して、データパスの性能、信頼性、またはセキュリティを増大させることを対象とし、複数のアプリケーション間の競合に対処しない。
【特許文献１】米国特許第７，０５８，５４５号
【発明の概要】
【発明が解決しようとする課題】
【００１３】
したがって、特に、複数のアプリケーションが実行されている現実世界環境において、システムリソースをアプリケーションに効率的にマッピングするように動作可能な方法およびシステムを提供することが有用である。
【００１４】
このような方法およびシステムを利用する改良されたストレージプラットフォームおよびアーキテクチャを提供することも有用である。
【課題を解決するための手段】
【００１５】
これらのニーズを満たし、他の技術的利点および特徴を提供する本発明について、次に、添付の図面に関連して詳細に説明する。
【００１６】
発明の概要
本発明は、デジタル処理環境内、より詳細にはデジタルストレージ環境内で動作可能であり、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素との間のマッピングを可能にするとともに、デジタルストレージ環境内の任意のストレージ要素に対して負荷を発生させているアプリケーション（他のソフトウェアプログラム）セットの階層イメージを提供する方法、装置、システム、およびコンピュータプログラムコード（ソフトウェア）製品を提供する。
【００１７】
例として、本発明の一態様は、（Ａ）集合的にデジタルストレージ環境内のストレージ要素である、少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境内で動作可能なこのような方法、装置、システム、およびコンピュータプログラムコード（ソフトウェア）製品を提供するが、この少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、デジタルストレージ環境内のストレージ要素である。本発明のこの態様は、（Ａ）アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供することと、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義することと、
ＡＲＧはＡＲＧ抽象を含み、ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
ＡＲＧおよびサブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である。
【００１８】
本発明の別の態様では、ＡＲＧおよびサブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である。
【００１９】
本発明の別の態様では、ＡＲＧおよびサブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、ＡＲＧが、ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である。
【００２０】
本発明のさらに別の態様では、ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される。
【００２１】
さらなる詳細、例、および実施形態を、添付図面と併せて読まれるべき以下の詳細な説明において説明する。
【００２２】
上述したように、本発明は、２００７年７月５日に出願された「Managing Application System Load（アプリケーションシステムの負荷管理）」という名称の米国特許出願第１１／７７３８２５号（代理人整理番号：ＡＫＲ−１１０−ＵＳ）の一部継続出願（ＣＩＰ）であるため、以下の詳細な説明ではまず、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）の発明を記載し（以下のセクションＡ〜Ｄ）、それから、本発明の説明に続く（以下のセクションＥおよびＦ）。当業者は、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）内で記載されているデジタル処理、計算、またはストレージ環境が、本発明を実施することができる処理環境の例のうちのいくつかにすぎないことを理解するとともに、本発明を米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）で記載される環境以外で実施可能なことも理解するであろう。
【００２３】
当業者は、添付図面に関連して行われる以下の詳細な説明に基づく本発明を容易に理解するであろう。
【図面の簡単な説明】
【００２４】
【図１】本発明を実施することができるか、または本発明を実施することができるネットワーク化されたデジタル計算システムの一部分を形成し得る従来のワークステーションまたはＰＣ（パーソナルコンピュータ）デジタル計算システムの概略図である（先行技術）。
【図２Ａ】本発明を実施することができるネットワーク化されたデジタル計算システムの概略図である（先行技術）。
【図２Ｂ】図１に示すような従来のワークステーション環境またはＰＣ環境の構成要素の概略図である（先行技術）。
【図３】本発明の一実施形態の概略図である。
【図４】本発明を実施することができるデジタル計算システムの概略図である。
【図５】調整可能なアプリケーションパラメータを有するアプリケーションプログラムを示す概略図である。
【図６】デジタル計算システムで実行されており、システム負荷を発生させているアプリケーションの概略図である。
【図７】本発明により構築された計算システムおよび情報リソースマネージャ（ＩＲＭ）を示す概略図である。
【図８】計算システムで実行されているアプリケーションの性能統計、構成データ、およびアプリケーションパラメータのデータベースを示す概略図である。
【図９】本発明により性能情報を計算システムからどのように得ることができるかを示す概略図である。
【図１０】本発明により構成情報を計算システムの各要素からどのように得ることができるかを示す概略図である。
【図１１】本発明の一実施形態によるＩＲＭの解析モデルの態様を示す概略図である。
【図１２】本発明により、構成データ、ＣＰＵ統計、ネットワーク統計、およびＳＡＮ統計を使用して、解析モデルをどのように構築することができるかを示す概略図である。
【図１３】本発明の一実施により、解析モデルが更新アプリケーションパラメータセットをどのように生成するかを示す概略図である。
【図１４】本発明の一実施形態により、更新アプリケーションパラメータを使用して、アプリケーションによって使用されているアプリケーションパラメータセットがどのように更新されるかを示す概略図である。
【図１５】情報リソースマネージャ（ＩＲＭ）がいくつかのＣＰＵ統計、ネットワーク統計、およびＳＡＮ統計をどのように維持することができるかを示す概略図である。
【図１６】本発明により、複数の更新統計セットを解析モデルにどのように適用することができるかを示す概略図であり、次に、解析モデルは、計算システムで実行されているアプリケーションデータを更新する。
【図１７】本発明の一実施形態によるＥＬＭアーキテクチャの主要構成要素の概略ブロック図である。
【図１８】ＥＬＭアーキテクチャの統計収集のタイミングを示す図である。
【図１９】ＥＬＭ統計の収集および計算の頻度のサマリを提供する表である。
【図２０】ＥＬＭ統計のサマリを提供する表である。
【図２１】ＥＬＭ統計のサマリを提供する表である。
【図２２】ＥＬＭ統計のサマリを提供する表である。
【図２３】ＥＬＭ統計のサマリを提供する表である。
【図２４】ＥＬＭ統計のサマリを提供する表である。
【図２５】ＥＬＭ統計のサマリを提供する表である。
【図２６】ＥＬＭ統計のサマリを提供する表である。
【図２７】ＥＬＭ統計のサマリを提供する表である。
【図２８】本発明の一実施によるＥＤａＣサービスに含まれる各種コネクタを示す概略図である。
【図２９Ａ】デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する本発明による方法を示すフローチャートである。
【図２９Ｂ】デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する本発明による方法を示すフローチャートである。
【図３０】デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する本発明による方法を示すフローチャートである。
【図３１】アプリケーションシステムストレージリソースのマルチレベルマッピングを提供する本発明のさらなる態様によるレベル、グループ、およびインフラストラクチャ要素が列に列挙される表である。
【図３２】アプリケーションシステムストレージリソースをマルチレベルマッピングする、説明されるシステムおよび技法の実施に適した例示的なコンピュータインフラストラクチャアーキテクチャの図である。
【図３３】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３４】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３５】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３６】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３７】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３８】代替の例示的なコンピュータインフラストラクチャアーキテクチャの図である。
【図３９Ａ】図３８のアーキテクチャに記される要素のサブセットから形成されるサブグループを示す図である。
【図３９Ｂ】図３８のアーキテクチャに記される要素のサブセットから形成されるサブグループを示す図である。
【図４０】アプリケーションシステムストレージリソースをマルチレベルマッピングする本発明のさらなる態様による全般的な技法のフローチャートである。
【発明を実施するための形態】
【００２５】
発明の詳細な説明
以下の記載には、本発明の理解を提供するために多くの特定の詳細が記される。しかし、本発明をこういった特定の詳細なしで実施可能なことを当業者は理解するであろう。場合によっては、周知の方法、手続き、構成要素、プロトコル、アルゴリズム、および回路については、本発明を曖昧にしないように詳細に記載されていない。以下の考察には、アプリケーションパラメータを適宜調整することによってストレージリソースに対する負荷への対処に関連する態様ならびにＣＰＵ、ネットワーク、およびＳＡＮリソースの平衡化に関連する態様を含む本発明の各種態様が記載される。
【００２６】
上述したように、本発明は、２００７年７月５日に出願された「Managing Application System Load（アプリケーションシステムの負荷管理）」という名称の米国特許出願第１１／７７３８２５号（代理人整理：ＡＫＲ−１１０−ＵＳ）の一部継続出願（ＣＩＰ）であるため、以下の詳細な説明ではまず、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）の発明を記載し（以下のセクションＡ〜Ｄ）、それから、本発明の説明に続く（以下のセクションＥおよびＦ）。当業者は、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）内で記載されているデジタル処理、計算、またはストレージ環境が、本発明を実施することができる処理環境の例のうちのいくつかにすぎないことを理解するとともに、本発明を米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）で記載される環境以外で実施可能なことも理解するであろう。
【００２７】
この詳細な説明は以下のセクションで編成される。
Ａ．本発明を実施することができるデジタル処理環境
Ｂ．アプリケーションシステム負荷の管理
Ｃ．アプリケーションシステム負荷の管理−実施のさらなる詳細／例
Ｃ１．システムアーキテクチャ
Ｃ２．外部発見サブシステム
Ｃ３．発見エンジン
Ｄ．アプリケーションシステム負荷の管理−一般的な方法
Ｅ．アプリケーションシステムストレージリソースのマルチレベルマッピング
Ｆ．マルチレベルマッピングの実施形態
Ｇ．結び
【００２８】
Ａ．本発明を実施することができるデジタル処理環境
本発明の特定の例および実施形態を記載する前に、以下は、本発明を実施し、実行することができる基盤をなすデジタル処理構造および環境の、図１、図２Ａ、および図２Ｂと併せて読まれるべき考察である。
【００２９】
本発明は、コンピュータサーバクラスシステムで一般に見られるアプリケーションでのより効率的なアプリケーション実行を可能にする方法、システム、装置、およびコンピュータプログラム製品を提供することが当業者には理解されるであろう。これらのアプリケーションは、データベースアプリケーション、ウェブサーバアプリケーション、および電子メールサーバアプリケーションを含む。これらのアプリケーションは、一般に、大きなグループのコンピュータユーザに対して媒体を同時にサポートするために使用される。これらのアプリケーションは、複数のユーザによる一貫し組織されたアクセスおよび共有を共有データセットに提供する。アプリケーションは、デジタル計算システムの複数または単一の共有セットでホストすることができる。各アプリケーションで実行されるタスクセットは、デジタル計算システムで生成されるパターンおよび負荷を指示し、パターンおよび負荷は構成可能なアプリケーションパラメータセットを通して管理することができる。
【００３０】
したがって、本発明は、別個のソフトウェアアプリケーション、システムソフトウェアを含むコンピュータシステムの部分、またはデジタル計算システムの部分を形成するコンピュータの専用コンピュータハードウェアとして実施することができる。本発明は、別個のスタンドアロンのソフトウェアベースまたはハードウェアベースのシステムとして実施してもよい。実施態様は、キーボードおよび／またはマウス等のユーザインタフェース要素、メモリ、ストレージ、および他の従来のユーザインタフェース構成要素を含み得る。このような種類の従来の構成要素は、当業者に周知であるため、本明細書においてさらに詳細に記載する必要はなく、以下の概観には、本発明をデジタルコンピュータシステム内のこのような構成要素と併せてどのように実施できるかを示す。
【００３１】
特に、本発明をデジタルコンピュータシステム性能のプロファイリングおよび解析ならびにアプリケーション調整に利用できることを当業者は理解するであろう。本明細書において記載する技法は、デジタルコンピュータシステムの部分として実施することができ、性能データが定期的に収集され、適応的に解析される。データは、さらに、現在のシステムを変更することの影響を見積もるために使用できる解析モデルへの入力として使用することができる。この場合、デジタルコンピュータシステムで実行されているアプリケーションを再構成して、性能を向上させることができる。
【００３２】
以下の詳細な説明は、こういった技法による方法、構造、システム、コンピュータソフトウェア製品の例を示す。記載される方法およびシステムが、独立構成もしくはネットワークを介するMicrosoft Windows（登録商標）、Linux、またはUnix（登録商標）等の従来のオペレーティングシステムに従って動作する（または従来のオペレーティングシステムをエミュレートする）パーソナルコンピュータ（ＰＣ）または等価の装置等の従来のコンピュータ装置を使用してソフトウェア、ハードウェア、またはソフトウェアとハードウェアとの組み合わせで実施できることが当業者には理解されるであろう。したがって、本明細書において記載する各種処理態様および手段は、適宜構成されたデジタル処理装置または装置のネットワークのソフトウェア要素および／またはハードウェア要素で実施することができる。処理は逐次または並列に実行してよく、専用ハードウェアまたは再構成可能ハードウェアを使用して実施してもよい。
【００３３】
一例として、本明細書に添付される図１は、データベースおよびメールサーバ等のサーバクラスアプリケーションを実行できる例示的なコンピュータシステム１０を示す。図１を参照すると、一実施形態において、コンピュータシステム１０は、プロセッサモジュール１１と、キーボード１２Ａおよび／またはマウス１２Ｂ（またはデジタイジングタブレットまたは他のアナログ要素、包括的にオペレータ入力要素１２として識別される）等のオペレータ入力構成要素およびビデオ表示装置１３等のオペレータ出力要素を含むオペレータインタフェース要素とを含む。例示的なコンピュータシステム１０は、従来の内蔵プログラムコンピュータアーキテクチャのものであることができる。プロセッサモジュール１１は、例えば、１つまたは複数のプロセッサ、メモリ、ならびにディスクおよび／またはテープ記憶要素（別個に示さず）等の大容量記憶装置を含むことができ、提供されるデジタルデータと併せて処理動作および記憶動作を実行する。オペレータ入力要素１２は、オペレータが、処理する情報を入力できるようにするために提供することができる。ビデオ表示装置１３は、オペレータが処理のために入力することができるデータ、オペレータが処理制御のために入力できる情報、ならびに処理中に生成される情報を含め、プロセッサモジュール１１によって生成された情報をオペレータに対して画面１４上に表示するために提供することができる。プロセッサモジュール１１は、いわゆる「グラフィカルユーザインタフェース」（「ＧＵＩ」）を使用してビデオ表示装置１３によって表示される情報を生成することができ、ビデオ表示装置１３には、各種アプリケーションプログラムについての情報が各種「ウィンドウ」を使用して表示される。
【００３４】
用語「メモリ」、「ストレージ」、および「ディスクストレージ装置」は、コンピュータハードディスク、コンピュータフロッピー（登録商標）ディスク、コンピュータ可読フラッシュドライブ、コンピュータ可読ＲＡＭ要素、コンピュータ可読ＲＯＭ要素、またはデジタル情報を符号化する任意の他の既知の手段等の任意のコンピュータ可読媒体を包含することができる。用語「アプリケーションプログラム」、「アプリケーション」、「プログラム」、「コンピュータプログラム製品」、または「コンピュータソフトウェア製品」は、コンピュータ可読媒体が固定式、リムーバブル式、永久的、または消去可能であるか等にかかわりなく、コンピュータ可読媒体に符号化され、かつ／または記憶されたコンピュータ可読プログラム命令からなる任意のコンピュータプログラム製品を包含することができる。上述したように、例えば、図２Ｂの概略ブロック図のブロック１２２において、アプリケーションおよびデータは、当該技術分野において周知の実施および技法に従ってディスク、ＲＡＭ、ＲＯＭ、他のリムーバブルストレージ、固定ストレージに、これらが内部にあるか外部にあるかにかかわりなく、記憶することができ、ダウンロードまたはアップロードすることができる。本書において述べるように、本発明は、コンピュータ可読媒体に記憶されたソフトウェアまたはコンピュータプログラム製品の形態をとってもよく、アップロードされてもよく、ダウンロードされてもよく、ＦＰＧＡ、ＲＯＭ、もしくは他の電子構造に固定されてもよいコンピュータプログラムコードの形態であってもよく、または方法もしくはこのような方法を実行するシステムの形態をとってもよい。コンピュータシステム１０は、入力情報をオペレータから受け取るためのキーボード１２Ａおよびマウス１２Ｂ、ならびに出力情報をオペレータに表示するためのビデオ表示装置１３等の特定の構成要素を備えて示されるが、コンピュータシステム１０が、図１に示される構成要素に加えて、または図１に示される構成要素に代えて、様々な構成要素を含んでよいことが理解されるであろう。
【００３５】
さらに、プロセッサモジュール１１は、包括的に参照番号１４で識別される１つまたは複数のネットワークポートを含むことができ、ネットワークポートは、コンピュータシステム１０をコンピュータネットワークに接続する通信リンクに接続される。ネットワークポートは、コンピュータシステム１０が、ネットワーク内の他のコンピュータシステムおよび他の装置に対して情報を送信するとともに、情報を受信できるようにする。例えば、クライアント−サーバパラダイムに従って組織された典型的なネットワークでは、ネットワーク内の特定のコンピュータシステムがサーバとして示され、他のクライアントコンピュータシステムによって処理されるデータおよびプログラム（包括的に「情報」）を記憶し、それにより、クライアントコンピュータシステムが情報を都合良く共有できるようにする。特定のサーバによって保持されている情報にアクセスする必要があるクライアントコンピュータシステムは、サーバがネットワークを介して情報をダウンロードできるようにする。データを処理した後、クライアントコンピュータシステムは、処理されたデータをサーバに返して、そこに記憶することもできる。コンピュータシステム（上述したサーバおよびクライアントを含む）に加えて、ネットワークは、例えば、プリンタおよびファクシミリ装置、デジタルオーディオまたはデジタルビデオの記憶・配信装置等を含み得、これらをネットワークに接続された各種コンピュータシステムで共有することができる。ネットワーク内のコンピュータシステムを相互接続する通信リンクは、従来のように、ワイヤ、光ファイバ、または信号をコンピュータシステム間で搬送する他の媒体を含めた任意の都合の良い情報搬送媒体を含み得る。コンピュータシステムは、通信リンク上で転送されるメッセージによってネットワーク上で情報を転送し、各メッセージは、情報およびメッセージを受信する装置を識別する識別子を含む。
【００３６】
図面に示されるコンピュータシステム１０に加えて、本発明による方法、装置、またはソフトウェア製品は、従来のＰＣ１０２、ラップトップ１０４、ハンドヘルドもしくはモバイルコンピュータ１０６、またはインターネットもしくは他のネットワーク１０８を介するものを含め、スタンドアロンか、ネットワーク化されているか、可搬であるか、それとも固定されるかにかかわりなく、サーバ１１０およびストレージ１１２を含み得る、図２Ａおよび図２Ｂに例として示されるもの（例えば、ネットワークシステム１００）等の任意の広範囲の従来の計算装置およびシステムで動作することができる。
【００３７】
従来のコンピュータソフトウェアおよびハードウェアでの実施と並んで、本発明により構成されたソフトウェアアプリケーションは、例えば、図１、図２Ａ、および図２Ｂに示されるようなＰＣ１０２内で動作することもでき、この場合、プログラム命令は、ＲＯＭ、ＣＤ−ＲＯＭ１１６（図２Ｂ）、磁気ディスク、または他のストレージ１２０から読み出して、ＲＡＭ１１４にロードしてＣＰＵ１１８によって実行することができる。データは、従来のキーボード、スキャナ、マウス、デジタイジングタブレット、または他の要素１０３を含めた任意の既知の装置または手段を介してシステムに入力することができる。図２Ｂに示すように、図示のストレージ１２０はリムーバブルストレージを含む。図２Ｂにさらに示すように、アプリケーションおよびデータ１２２を、固定ストレージ、リムーバブルストレージ、またはＲＯＭのうちのいくつかまたはすべてに配置してもよく、またはダウンロードしてもよい。
【００３８】
本明細書において記載する本発明の方法態様が、ＡＳＩＣ製造業者にとって既知のＡＳＩＣ構築技法を使用して、本明細書において記載される処理を実行するように特に構築されたフィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）等のハードウェア要素で実行可能なことを当業者は理解するであろう。本発明の実行に使用できる従来のＡＳＩＣ、等価の集積回路、または他の従来のハードウェア要素の実際の半導体素子は、本発明の部分ではなく、本明細書において詳細に考察しない。
【００３９】
さらに詳細に本明細書において記載する本発明の教示を使用して、さらに詳細に後述する、例えば図３以下に示される本発明の方法を実行するように、ＡＳＩＣまたは他の従来の集積回路または半導体素子を実装可能なことも当業者は理解するであろう。
【００４０】
本発明の方法態様が、ワークステーションまたはパーソナルコンピュータ（ＰＣ）のオペレーティングシステムおよび本発明により構成されたコンピュータプログラム製品の下で動作する、ワークステーションおよびＰＣ等の市販のデジタル処理システム内で実行可能なことも当業者は理解するであろう。用語「コンピュータプログラム製品」は、コンピュータ可読媒体に符号化されたコンピュータ可読プログラム命令の任意のセットを包含することができる。コンピュータ可読媒体は、ワークステーション、ＰＣ、または他のデジタル処理装置もしくはシステムからローカルであれ、またはリモートであれ、コンピュータハードディスク、コンピュータフロッピー（登録商標）ディスク、コンピュータ可読フラッシュドライブ、コンピュータ可読ＲＡＭ要素、コンピュータ可読ＲＯＭ要素、またはデジタル情報の符号化、記憶、または提供を行う任意の他の既知の手段を含むが、これらに制限されない任意の形態のコンピュータ可読要素を包括することができる。各種形態のコンピュータ可読要素および媒体が、コンピューティング分野において周知であり、その選択は実施者に任せられる。
【００４１】
Ｂ．アプリケーションシステム負荷の管理
次に、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）に記載される本発明の各種態様によるアプリケーションシステム負荷を管理するシステムおよび技法の例および実施形態について記載する。本願は、米国特許出願第１１／７７３８２５号の一部継続出願（ＣＩＰ）である。
【００４２】
アプリケーションは、一般に、ストレージエリアネットワーク（ＳＡＮ）を通して共通ネットワークおよびストレージシステムを共有するサーバでホストされる。アプリケーションの要求とＣＰＵ、ネットワーク、およびＳＡＮの能力との不均衡は、中央リソースを共有しているアプリケーションの全体性能の低下に繋がる。しかし、個々のアプリケーションは、サブシステム内の任意の単一の要素、特にＳＡＮに大きすぎる負荷を課す場合、性能の影響を受け得る。さらに、ＣＰＵ、ネットワーク、およびストレージアレイは、多くの場合、共有リソースとして利用される。独立したサーバで実行されている複数のアプリケーションは、サブシステム要素がアプリケーション間で共有されている場合、互いの性能に影響を及ぼし得る。
【００４３】
多くのアプリケーションは内部パラメータを有し、内部パラメータはユーザまたはシステム管理者によって設定することができ、アプリケーションの性能およびスループットに劇的な影響を及ぼし得る。ユーザは、通常、アプリケーションが実行のために初期化されているとき、計算システム構成で維持可能な帯域幅または存在する並列性を考慮しない。システム負荷の設定には、デフォルト値セットが一般に使用される。これらのデフォルト値は、例えば、スレッド数、個々のアプリケーションの優先度、記憶領域、およびログバッファ構成を含み得る。これらの値は、実行時中に調整することも可能である。これらの値はユーザ、アプリケーションプログラマ、またはシステム管理者によって調整可能であるが、基盤をなす計算システムリソースの特性によりよく合うように、アプリケーション負荷を調整するための指針は提供されない。
【００４４】
任意のアプリケーションの性能は、アプリケーションが単一の装置に対して大きすぎるトラフィックを生成する場合、または複数のアプリケーションが、システムが集合負荷にサービス提供できないような多くの要求でシステムを溢れさせる場合に低下し得る。システム内の任意の要素に過負荷がかかる際に、あるアプリケーションが別のアプリケーションに対して生み出す干渉は、性能の大きなばらつきを生じさせ得る。より予測可能なアプリケーション性能を提供しようという試みは、多くの場合、サブシステム内の特定の要素のキャパシティのオーバープロビジョニングに繋がる。
【００４５】
これらの課題を解決するか、又はこれらの課題を少なくとも最小にしようとして、システム管理者は、各アプリケーションが固定の優先度を有することを要求することができる。優先度の設定は、システムリソースに対するアプリケーションの要求を「抑制する」ために使用される。不都合なことに、固定の優先度の割り当てはリソースを無駄にする恐れがあるとともに、アプリケーションスタベーションに繋がる恐れもある。抑制に対する代替は、各アプリケーションが受けているサービス品質（「ＱｏＳ」）を管理することができる。ストレージリソースの割り振りは、様々な基準、例えばストレージアクセスの帯域幅に基づくことができる。米国特許出願公開第２００５／００８９０５４号には、ＱｏＳに基づいたリソースの割り振りを提供する装置が記載されており、参照によりその全体が本明細書に援用される。
【００４６】
上記懸案事項に対する従来の解決策は、通常、それ自体の性能制約及び懸案事項を提示してきた。したがって、１つまたは複数のアプリケーションによって生成されるシステム負荷をより効率的かつ柔軟に管理する改良された方法、装置、ソフトウェア、およびシステムを提供することが望ましい。
【００４７】
ディスクまたは帯域幅を個々のサーバまたはアプリケーションに割り振るのではなく、本明細書に記載するシステムおよび技法は、アプリケーションによって提供される内部調整機能（internal tuning facility）を利用し、提供されたストレージサブシステムの特性に基づいて調整されたパラメータセットに到達する。さらに、本発明は、ネットワーク化されたデジタル計算システム等の完全デジタルコンピュータシステムのリソースも考慮する。記載のシステムおよび技法は、Microsoft Windows（登録商標）、Linux、およびUnix（登録商標）等の市販のオペレーティングシステムで開発された既存の性能監視システムおよび技法を利用する。実行時パラメータセットを通してアプリケーションを適応的に調整できるようにする記載のシステムおよび技法は、既存のインタフェースを利用して、データベースおよび電子メールアプリケーションを調整する。本発明はさらに、利用可能なシステムリソースの入念なプロビジョニングを通してＱｏＳ保証を提供して、複数のアプリケーションを並行に管理することができる。
【００４８】
システム性能を決定する、アプリケーションパラメータの構成に使用されている従来の方法は、いくつかの著しい欠点を有する。すなわち、（１）今日まで使用されてきた調整方法は、試行錯誤反復調整に基づいておらず、（２）ユーザは、調整の選択をガイドするために基盤をなすＣＰＵ、ネットワーク、およびストレージサブシステムについて殆ど情報を有さず、（３）共有デジタル計算システムを利用する複数のアプリケーションまたは複数のサーバを並行に管理することが殆ど考慮されておらず、かつ（４）現在、デジタル計算システムの特性を個々のアプリケーションパラメータの変更に変換する一般に認められた方法がない。
【００４９】
アプリケーションによっては、ストレージアクセス動作の待ち時間の影響を受けやすいものもあれば、そうでないものもある。データベースおよびメールサーバアプリケーションは、非逐次モードでデータにアクセスすることが多く、時によっては、別のコマンドを発行する前に、１つのアクセスまたは一連のアクセスの完了を待たなければならないことがあるため、ストレージアクセス動作に関連する待ち時間の影響を特に受けやすい。
【００５０】
データベースシステム、メールサーバ等の多くの待ち時間の影響を受けやすいアプリケーションは、自己調整を実行する能力を有する。例えば、Oracle１０ｇは、最近のクエリの挙動に基づいて将来のクエリの性能を加速化できるクエリオプティマイザを提供する。Oracle１０ｇは、データベース性能に影響し得る２５０を超える調整可能パラメータも有する。これらのパラメータは、メモリリソース、例えばキャッシュおよびバッファの利用に影響するとともに、並行アクセス可能量、例えばスレッディングを定義することができる。
【００５１】
記載のシステムおよび技法は、基盤をなすＣＰＵサブシステム、ネットワークサブシステム、およびストレージサブシステムについての情報を利用することによるこれらの内部パラメータの適正な設定を目標とする。本明細書において記載するように、ＣＰＵサブシステム情報は、使用中のプロセッサの種別および個数ならびに関連するメモリ階層の両方を含み、ネットワークサブシステム情報は、使用されているネットワークスイッチの速度および構成ならびにスイッチに接続されたアダプタの速度を含み、ストレージサブシステム情報は、物理ディスク装置の特性、ＲＡＩＤグループへのこれらの装置のグループ化、論理アドレスからＲＡＩＤグループへのマッピング、およびこのシステムを通る個々のパスのスループットを含む。本発明のさらなる一態様は、システムの実行時特性を捕捉することによってストレージサブシステム情報を得る能力を提供する。この情報は、カスタマイズされたエクササイザを実行するか、またはシステムの通常の実行を観察することによって得ることができる。
【００５２】
アプリケーションパラメータの調整は、アプリケーションの初期化時または動的に行うことができる。基盤をなすサブシステム性能の異なる特性を捕捉するために使用される方法は、静的、すなわち予め決まった方法であり、ストレージシステムと共に出荷してもよく、またはプロファイリングを通して動的に取得されてもよい。現在記載している本発明は、この情報を静的に指定する方法およびプロファイリングを通してこの情報を取得する方法の両方を含む。本発明のさらなる態様によれば、この情報は、フィードバックとしてアプリケーションに提供されて、システムパラメータを自動的に、またはシステム／アプリケーション管理者によって調整できるようにする。
【００５３】
上記考察では、デジタル計算リソースを最も良く利用するために、性能の影響を受けやすいアプリケーションのパラメータを適宜調整する必要性について述べた。このようなパラメータを調整する装置およびシステムの一実施形態を図３に示す。
【００５４】
図３に示すように、アプリケーションサーバ２９０は、サーバ２６０に直接接続されるものもあれば、スイッチファブリック２５０を使用してストレージエリアネットワーク２７０を介してサーバに接続されるものもある、様々な記憶要素にアクセスする。これは、サーバおよびストレージシステムの可能な編成の１つにすぎない。本発明は特定の編成を必要としない。
【００５５】
したがって、本発明の現在記載している態様には、サーバおよびストレージシステムの両方に通信できる要素が導入される。この要素は、本明細書では、ストレージシステムアウェアアプリケーション調整システム（ＳＳＡＡＴＳ）２８０と呼ばれる。この要素ならびに同様の構造および機能についても記載され、以下では情報リソース管理（ＩＲＭ）システムと呼ばれる。後述するように、本発明のさらなる態様は、ＳＳＡＡＴＳ要素の機能のうちのいくつかまたはすべてを実行する他の名称の要素を提供する。
【００５６】
図３に示すＳＳＡＡＴＳの実施形態は３つの下位要素を含む。すなわち、
（１）ストレージネットワークプロファイリングシステム２１０、
（２）解析モデル２２０、および
（３）アプリケーションパラメータ決定サブシステム２３０
である。
【００５７】
ＳＳＡＡＴＳ要素２８０は、スタンドアロンサブシステムとして実施してもよく、またはサーバサブシステム２９０もしくはネットワークファブリックサブシステム２４０の部分として統合されてもよい。
【００５８】
プロファイリングサブシステム要素１００は、ストレージネットワーク内の並列度を決定する能力を有し、上述したように基盤をなすストレージシステム２６０および２７０の帯域幅値および待ち時間値を推定することができる。プロファイリングサブシステム要素２１０は、存在するネットワークファブリック要素２５０の帯域幅値および待ち時間値を決定することもできる。
【００５９】
プロファイリングサブシステム要素２１０は、ストレージシステム製造業者から常に入手可能であるとは限らない性能関連情報を取得する。ストレージシステムが設置される際、利用可能なストレージは多くの異なる編成で構成され得る。そのため、いくらかの性能関連情報が製造業者によって提供される場合であっても、必要な情報の大半は、ストレージシステムが設置され構成された後でのみ的を得たものである。
【００６０】
必要な性能関連情報としては、例えば、
（１）ＣＰＵ、ネットワーク、およびＳＡＮ内で利用可能な並列度、
（２）各種装置の速度、
（３）アプリケーションサーバ、ネットワーク、および個々のストレージ装置の間のパスの帯域幅、および
（４）サーバから見たストレージ装置の構成
が含まれるが、これらに制限されない。
【００６１】
必要な性能関連情報を取得するために、一連の入／出力コマンドをストレージサブシステムに発行することができる。特定のコマンドシーケンスの応答時間およびスループットに基づいて、必要な性能関連情報を取得することができる。次に、この情報は解析モデル要素２２０に供給される。
【００６２】
解析モデル要素２２０は、プロファイル情報をプロファイリングストレージネットワーク２１０から取得する。プロファイリングデータは解析性能モデル２２０によって使用され、解析性能モデル２２０は、アプリケーションサーバ２９０のＣＰＵサブシステム、ネットワークサブシステム２５０、ならびにストレージサブシステム２６０および２７０が維持できる適正負荷を確立するために使用される。解析モデル要素２２０の出力は、パラメータ値２３０を決定する要素に供給され、次に、この要素は、これらの値をアプリケーションサーバ２９０に通信し、アプリケーションサーバ２９０は、次に、アプリケーションの内部パラメータを設定する。
【００６３】
オプションの一実施形態では、プロファイリングシステムがプロファイリングネットワーク２１０を通してストレージシステムの性能を引き続きプロファイリングし、動的プロファイルを解析性能モデル２２０に供給し、新しいアプリケーションパラメータセットをパラメータ決定システム２３０からアプリケーションサーバ２９０に通信することができる。このオプションの実施形態の主要特徴としては、（ａ）プロファイリングシステムが、パラメータ変更を通して得られる恩益を低減する恐れのある著しいオーバーヘッドをデジタル計算システムに導入し得ないこと、かつ（ｂ）システムが連続して性能遷移に適応しないようにパラメータ変更の頻度を抑制するために、適切な制御が提供されていることをシステムが保証しなければならないことが含まれる。
【００６４】
オプションの一実施形態では、プロファイリングシステム２１０が、利用可能なシステム構成の使用をさらに改良するために、ネットワークインタフェースを通してストレージリソース２６０および２７０と直接通信することができ、これは、本明細書では「発見（Discovery）」と呼ばれる。
【００６５】
本明細書において記載する解析モデル２２０は、標準キューイング理論技法を利用し、ストレージサブシステムが維持できる負荷量を確立する。特に、解析モデル２２０は、既知のキューイング理論式、アルゴリズム、および技法を適用して、サポート可能なストレージ負荷を決定することができる。このような式、アルゴリズム、および技法は、例として、Kleinrock, L., Queueing Systems: Volume I - Theory (Wiley Interscience, New York, 1975）、Kleinrock, L., Queueing Systems: Volume II - Computer Applications (Wiley Interscience, New York, 1976）に記載されており、これらを両方とも、その全体が記載されているかのように参照により本明細書に援用される。次に、パラメータ決定要素は、これらの負荷値をターゲットアプリケーションの具体的なパラメータ値に変換する。本発明のさらなる態様によれば、ＳＳＡＡＴＳ２８０は、１つのアプリケーションソフトウェアにつき１つずつ、複数のパラメータ決定要素２３０を含む。
【００６６】
アプリケーションパラメータユニット２３０の決定は、いくつかのアプリケーション固有パラメータを考慮する。１つの特定のパラメータセットは、例えば、Oracle １０ｇの内部に提供されるコストベース最適化（ＣＢＯ）パラメータを含む。こういったパラメータは、Oracle内でインデックス付与および走査がどのように実行されるか、ならびにアプリケーションによって想定される並列度を制御することができる。例えば、マルチブロックリードカウントは、アクセスサイズを調整するために設定することができ、または並列テーブル走査を実行するために並列自動調整を設定することができる。
【００６７】
多くの状況において、ストレージ管理者が待ち時間の影響の受けやすさによってアプリケーションを区別することが有益であり得る。現在記載しているメカニズムは、個々のアプリケーションのシステムリソース要求の抑制を目標とするが、ネットワークおよびストレージは一般に異なるアプリケーションによって共有されるため、同じシステムを使用して複数のアプリケーションを管理することができる。
【００６８】
ネットワークおよびストレージが異なるアプリケーションによって共有される場合、解析モデル２２０は、競合するアプリケーション作業負荷の影響を捕捉するように調整することができる。２つの典型的な作業負荷は、オンライントランザクション処理作業負荷と、これと競合するストレージバックアップ作業負荷である。バックアップアプリケーションがクリティカルな動作を実行している間、オンライアントランザクション処理アプリケーショの実行が優先されるべきである。
【００６９】
複数のアプリケーションが同じＩＯストレージリソース２６０おび２７０のセットを共有している場合、アプリケーションパラメータユニット２３０の決定は、共有に役立つように複数のパラメータ値セットを調整する必要がある。
【００７０】
複数のアプリケーションが同じＩＯストレージリソース２６０おび２７０のセットを共有し、システム管理者であるユーザが各アプリケーションのスループットに優先度を付けたい場合、アプリケーションパラメータユニット２３０の決定は、一方のアプリケーションのＩＯ要求を他方のアプリケーションのＩＯ要求よりも優先するようにパラメータ値をさらに調整することができる。
【００７１】
これより、本発明によるシステムのさらなる一実施形態について記載し、上述した要素および他についてさらに詳細に記載する。
【００７２】
図４は、中央演算処理装置（ＣＰＵ）３０１、３０２、３０３と、ネットワーク要素３１０と、ストレージアレイネットワーク３２０とを含む例示的な計算システム３００の要素を示す図である。図示の構成は、現在利用可能な多くのサーバクラス計算システムの典型的な構成である。本明細書において記載するように、本発明の態様は、システム３００の解析モデルを構築することによってシステム３００の性能を向上させるシステムおよび技法を対象とする。解析モデルは、まず、システム構成情報および異なる要素の実行時性能統計を取得することによって構築される。解析モデルには、システム３００で実行されている特定のアプリケーションセットについての知識が提供される。解析モデルの出力は、性能数ならびに計算システム３００で実行されているアプリケーションに関連するアプリケーションパラメータの調整の仕方についての推奨を含む。次に、解析モデルの出力を使用して、アプリケーションの将来の性能を向上させることができる。
【００７３】
図５は、アプリケーション３５０が計算システム３００でどのように実行されるかを構成するために使用されるプログラムコード３６０とアプリケーションパラメータセット３７０とを含むアプリケーション３５０の図を示す。
【００７４】
図６は、ＣＰＵ１ ３０１で実行されるアプリケーション３５０の図を示し、アプリケーション３５０にはアプリケーションパラメータセット３７０が供給され、システムに負荷を生じさせる。
【００７５】
図７は、計算システム３００および情報リソースマネージャ４００を示す図を示す。情報リソースマネージャ４００は、解析モデル４１０を含み、ＣＰＵ統計４４０、ネットワーク統計４５０、およびＳＡＮ統計４６０を含むいくつかの計算システム性能統計４３０と、計算システム構成データ４７０と、計算システム３７０で実行されているアプリケーションセットのアプリケーションパラメータセット３７０とのデータベース４２０を保持する。
【００７６】
図８は、ＣＰＵ統計４４０と、ネットワーク統計４５０と、ＳＡＮ統計４６０と、構成データ４７０と、計算システム３００で実行されているアプリケーションのアプリケーションパラメータ３７０とのデータベース４２０を示す。
【００７７】
図９は、性能統計を計算システム３００からどのように取得できるかの一例を示す図を示す。ＣＰＵ統計４４０は、iostat ５１０およびperfmon ５２０等の標準ソフトウェアユーティリティを使用してＣＰＵ１ ３０１から取得することができる。ネットワーク統計４５０は、大半のネットワークスイッチ装置に提供されているＳＮＭＰインタフェース５３０を使用して取得することができる。ＳＡＮ統計４６０は、多くのＳＡＮシステム１２０に提供されているＳＭＩＳ５４０を介して取得することができる。図９に示すインタフェースは、異なる要素から性能統計を取得する１つの特定のインタフェースセットを示すが、情報リソース管理ユニット４００が、利用可能な計算システムの追加のインタフェースにアクセスすることを除外しない。
【００７８】
図１０は、構成データ４１０が計算システム１００の各要素からどのように得られるかを示す。異なる計算システム要素１００の各ベンダーは、一般に、この情報を報告するインタフェースを提供する。
【００７９】
図１１は、情報リソース管理ユニット４００の部分である解析モデル４１０の図を示す。解析モデル４１０の目的は、性能インジケータを生成すること、および計算システム３００で実行されているアプリケーションの性能を向上させるために、更新アプリケーションパラメータセット３７２（図１３および図１４）を生成することの両方である。
【００８０】
図１２は、構成データ４７０ならびにＣＰＵ統計４３０、ネットワーク統計４３０、およびＳＡＮ統計４４０がどのように使用されて、解析モデル４１０が構築されるかを示す。解析モデルは、ＣＰＵ４１１、ネットワーク４１２、およびＳＡＮ４１３のモデルを含み、追加の計算システム要素を含んでもよい。
【００８１】
図１３は、解析モデル４１０がどのように更新アプリケーションパラメータセット３７２を生成するかを示す。この新しいパラメータセットは計算システムに供給されて、システムで実行されているアプリケーション３５０が計算システムの要素をどのように使用するかを再構成する。目標は、システムの性能を向上させることである。
【００８２】
図１４は、更新アプリケーションパラメータ３７２がどのように使用されて、アプリケーション３５０によって使用されるアプリケーションパラメータセット３７０が更新されるかを示す。図１４には、アプリケーションがＣＰＵ１ ３０１で実行されて示されるが、アプリケーションは、システム３０２、３０３の任意のＣＰＵまたはシステムネットワーク３１０もしくはＳＡＮ３２０内の任意の他の要素で実行されてもよい。
【００８３】
図１５は、情報リソース管理ユニットが、いくつかのＣＰＵ統計４４２、ネットワーク統計４５２、およびＳＡＮ統計４６２を保持できることを示す。これらの記録は、通常、時間順に並べられ、システムのより長期の挙動を提供する。この記録セットは、計算システムで実行されている複数のアプリケーションについて生成される性能統計を表すこともできる。このより豊富な統計セットに再び解析モデル４１０を適用し、解析モデル４１０は次に、計算システムで実行されているアプリケーションデータ３７２を更新する。この技法を図１６にさらに示す。
【００８４】
Ｃ．アプリケーションシステム負荷の管理−実施のさらなる詳細／例
以下の考察は、本発明の各種態様による実施態様の１つまたは複数の例に関するさらなる詳細を提供する。以下があくまでも例として提示され、本発明を、後述する特定の構造を必ずしも必要とせずに、異なる構成および実施形態で実行し実施することが可能なことが当業者には理解されるであろう。以下の考察は、以下のサブセクションに編成される。
Ｃ１．システムアーキテクチャ
Ｃ２．外部発見サブシステム
Ｃ３．発見エンジン
【００８５】
Ｃ１．システムアーキテクチャ
現在記載しているアーキテクチャは、包括的に、本明細書ではイベントレベルモニタ（ＥＬＭ）と呼ばれる。ＥＬＭアーキテクチャは、以下のＥＬＭ製品特徴をサポートする。すなわち、（１）データセンタ可視性、（２）ホットスポット検出、および（３）解析である。
【００８６】
これらの機能をサポートするために、ＥＬＭアーキテクチャは以下の特徴を提供する。すなわち、構成／トポロジ発見、統計収集、統計計算、アプリケーション固有ストレージトポロジおよび統計、解析、ならびにアラーム・イベント生成である。
【００８７】
図１７は、ＥＬＭアーキテクチャ６００の例示的な実施形態の主要構成要素のブロック図を示す。図示の各構成要素についてこれより順に記載する。
【００８８】
プラットフォーム６１０：プラットフォーム６１０は、ＩＲＭ４００が実行される土台および基本環境を提供する。
【００８９】
Linux ６２０：Linux ＯＳ６２０は低レベル機能をプラットフォームに提供する。
【００９０】
構成要素タスクフレームワーク（ＣＴＦ）６３０：構成要素タスクフレームワーク６３０は、共通のプリミティブおよびサービスの有用なセット、メッセージング、イベント、メモリ管理、ロギングおよびトレース、デバッグシェル、タイマ、同期、データ操作を提供し、ハッシュテーブル、リスト等を含む。
【００９１】
ＭｙＳＱＬ６４０：システムデータのリポジトリであるデータストア（ＤＳ）６５０が、ＭｙＳＱＬ６４０の一番上に構築される中央データベースに記憶される。
【００９２】
データストア（ＤＳ）６５０：ＤＳ６５０は、発見された要素、その関係またはトポロジ、およびその統計を含む。
【００９３】
情報リソースマネージャ（ＩＲＭ）４００：情報リソースマネージャ（ＩＲＭ）４００は、上述したように、データセンタについての情報、トポロジ、および統計すべての収集を担う。
【００９４】
外部発見・収集（ＥＤａＣ）７００：外部発見・収集（ＥＤａＣ）７００は、さらに後述するように、データセンタの、サーバおよびストレージアレイ等の要素への接続をシステムに提供する構成要素である。特定の各種要素、例えばCLARiiONストレージアレイに対する通信の仕方を知っており、その特定の要素のトポロジを発見し、またはその特定の要素から統計を収集する。したがって、特定のアレイまたはサーバに対して別個のモジュールまたはコレクタを有する。各種の要素に対して、ＸＭＬで定義され、あらゆるコレクタが準拠する標準ＡＰＩがある。
【００９５】
発見エンジン６６０：発見エンジン６６０は、データセンタ要素、特にサーバおよびストレージアレイのトポロジの発見を行う。ユーザは、発見したいサーバまたはストレージアレイを入力する。発見エンジン６６０は、データストア６５０にアクセスして、ユーザが入力したサーバ、ネットワーク、およびストレージアレイのリストを得る。それぞれ１つごとに、発見エンジン６６０は、ＥＤａＣ７００にトポロジの取得を要求する。ＥＤａＣ７００は要素に問い合わせ、発見されたすべての情報、例えば、ストレージアレイのディスクを返す。次に、発見エンジン６６０は、この情報をデータストア６５０内に配置し、これらの関係を接続する。サーバの初回発見時、発見エンジン６６０は、統計マネージャ６７０にもそのサーバからの統計の収集を開始するように通知する。さらに、発見エンジン６６０は、デジタル計算システム３００の要素を定期的に起こし、「再発見」もする。これにより、任意のトポロジ変更を発見することができる。
【００９６】
統計マネージャ６７０：統計マネージャ６７０は、コンピュータシステム要素、特にサーバからの統計の収集を行う。現在の製品では、統計はサーバからのみ収集されるが、これらの統計を使用して、他のデータセンタ要素についての統計も同様に導出される。統計マネージャ６７０には、発見エンジン６６０により、新しいサーバが発見されたときに通知される。統計マネージャ６７０は、次に、そのサーバを収集リストに追加する。統計マネージャ６７０は、定期的に起きて、収集リストに目を通す。収集リスト内の各サーバにつき、統計マネージャ６７０は、統計を集めるようにＥＤａＣ７００に要求する。ＥＤａＣ７００は、サーバの統計を収集すると、これらの統計を統計マネージャ６７０に送信する。統計マネージャ６７０は、これらの統計を処理し、データストア６５０に挿入する。統計によっては、データストア６５０に変更なしで追加されるものもあれば、平均化等の何等かの単純な処理の後に追加されるものもあれば、完全に新しい統計を導出するより高度なアルゴリズムで処理されるものもある。
【００９７】
統計モニタ６８０：新しい統計が常に収集され計算される。これは、ユーザが時間を遡ってシステムで何か発生していたかを調べることができることを意味する。すべての統計はデータストア（ＤＳ）６５０に記憶される。記憶される統計としては、計算された統計ならびに収集された統計が含まれる。これにより、常に統計を表示に即座に利用できるようになる。
【００９８】
統計モニタ６８０は、統計マネージャ６７０によって統計がデータストア６５０に入力されると、その配置された統計を監視し管理する。統計モニタ６８０内には、定期的に起きて、データストア６５０内の統計に対して異なるタスクを実行するいくつかのデーモンがある。こういったタスクとしては、サマリ統計の作成、例えば、収集された統計の時間統計への集計、ある統計の移動平均の計算、ある統計の閾値との比較およびイベントの生成、そして最終的に、閾値を超えた場合にはアラームの生成が含まれる。
【００９９】
計算され解析される異なる種類の統計がある。これらのうちのいくつかは以下を含む。
【０１００】
計算された統計：計算された統計は、収集された統計または他の計算された統計に対して計算を実行することによって作成される。計算は、加算のように単純であってもよく、または非線形曲線当てはめの実行のように複雑であってもよい。計算された統計は、収集された統計と同じ方法および同じ形式でＤＳ６５０に記憶される。
【０１０１】
計算されたストレージ統計：すべてのストレージ統計がサーバＬＵＮから収集される統計から導出されることに留意することが重要である。次に、発見されたサーバおよびストレージアレイのトポロジを使用して、他のストレージオブジェクト：サーバボリューム、ストレージアレイＬＵＮ、ＡＳＧ、およびサブグループの統計が導出される。
【０１０２】
収集および計算の頻度：統計収集は、システムが統計的に安定しているときの使用率を計算することができるように行われる。統計的な安定は、統計が変化しないことを意味するのではなく、むしろ、システムが同じ種類の作業または作業セットを期間にわたって行っていることを意味する。使用率の計算は一連のサンプルを必要とする。したがって、統計的に安定した期間での使用率を計算するには、一連のサンプルを短期間に収集しなければならない。しかし、著しい数のサーバの統計を高頻度で連続して収集することは、システムに大きすぎる負担をかける。上記要件／制約は、図１８に示すように、バーストで統計を収集することによって満たされる。
【０１０３】
パラメータは以下の意味を有する。
メジャー期間（Major Period） サンプルバースト間の時間。範囲は５〜６０分である。
マイナー期間（Minor Period） バーストの各サンプル間の時間。範囲は１〜１０秒である。
バースト マイナー期間レートで各メジャー期間でとられるサンプル数。範囲は１〜５０サンプルである。
これらのパラメータはサーバ毎に可変である。したがって、１つのサーバについての統計をメジャー期間３０分、マイナー期間１０秒、およびバーストサイズ１０で収集し、別のサーバについての統計を、メジャー期間１５分、マイナー期間１秒、およびバーストサイズ２５で収集することが可能である。使用率の計算に使用されない統計は、メジャー期間毎に１度の頻度で収集される。バーストで収集される統計は、使用率の計算にすぐに使用される。使用率計算の結果はＤＳに保存され、未処理のデータは破棄される。したがって、統計は、サーバ毎のメジャー期間毎に１度、ＤＳに挿入される。
【０１０４】
サーバ統計計算頻度：サーバについてのすべての統計：ＣＰＵ、メモリ、ＬＵＮ、およびボリュームが同時に収集され計算される。これは、サーバのメジャーサンプルレートで行われる。
【０１０５】
アプリケーションストレージグループ／ストレージグループ統計計算頻度：特定の問題は、アプリケーションストレージグループ（ＡＳＧ）およびストレージグループ（ＳＧ）の計算期間である。ＡＳＧおよびＳＧの統計は、異なるサーバから送信されたものであり得るサーバＬＵＮ統計から計算される。大概、これらのサーバＬＵＮ統計は異なる時間に、かつ潜在的に異なるレートで収集される。これは、ＡＳＧ／ＳＧ統計をメジャーサンプル期間で計算できないことを意味する。各サーバＬＵＮからの複数のサンプルを使用することができるように、ＡＳＧ／ＳＧ統計をそれよりも低いあるレートで計算しなければならない。
【０１０６】
現在状態更新頻度：多くのオブジェクトは現在状態、履歴状態、および傾向状態を保持する。現在状態は比較的頻繁に計算されるが、メジャーサンプルレートよりも低い。
【０１０７】
履歴状態および傾向更新頻度：履歴状態および傾向はより長期のインジケータであり、より低い頻度で計算される。
【０１０８】
サマリ計算頻度：サマリは、データベース内の空間を節約するメカニズムである。サマリは、古いデータほど価値が低く、新しいデータと同じ粒度で見る必要がないという理論の下で動作する。
【０１０９】
発見頻度：発見は、環境についての比較的静的なデータを収集する。そのため、あまり頻繁に実行する必要はない。しかし、これは、任意の変更を素早く明らかしたいという要望とバランスをとる必要がある。
【０１１０】
収集および計算の頻度のサマリ：図１９に示す表は、収集および計算の頻度のサマリを提供する。すべての収集パラメータおよび計算パラメータが、変更可能なようにパラメータ化されるべきであることに留意する。
【０１１１】
統計サマリ：図２０〜図２７に示す表は、本明細書において記載するＥＬＭシステムの統計のサマリを提供する。
図２０−収集されたサーバ統計 サーバ統計はサーバから収集される。これらは、メジャーサンプル期間レートで頻繁に収集される動的統計である。
図２１−収集されたサーバ属性 サーバ属性はサーバから収集される。これらは、発見レートであまり頻繁には収集されない比較的静的なパラメータである。
図２２−記憶されたサーバ属性 サーバ属性はサーバから収集される。これらは、発見レートであまり頻繁には収集されない比較的静的なパラメータである。
図２３−記憶されたサーバ現在統計 サーバ統計は収集されたサーバ統計から生成され、データベースに記憶される。これらのうちの１つは、サーバ毎のメジャーサンプル期間毎に生成されるべきである。
図２４−サーバサマリ統計 サマリサーバ統計は、より短い期間からより長い期間までのサーバ統計の集計である。例えば、メジャー期間統計を日毎または週毎の統計にまとめることができる。
図２５−記憶されたストレージ統計 様々なストレージオブジェクトの統計の記憶に使用される共通のストレージ統計がある。ストレージ統計が生成される頻度は、統計が生成されているオブジェクトに依存する。サーバボリューム−メジャーサンプル期間毎に１回、サーバＬＵＮ−メジャーサンプル期間毎に１回、アプリケーションストレージグループ−アプリケーションストレージグループ／ストレージグループ計算期間毎に１回、サブグループ−アプリケーションストレージグループ／ストレージグループ計算期間毎に１回。
図２６−記憶されたストレージ統計 あらゆる統計があらゆるオブジェクトに対して有効であるわけではない。図２６の表は、どの統計がどのオブジェクトに対して有効であるかを示す。
図２７−記憶されたサマリストレージ統計 サマリストレージ統計は、より短い期間からより長い期間までのストレージ統計のまとめである。例えば、メジャー期間統計を日毎または週毎の統計にまとめることができる。
【０１１２】
解析：解析は、データストアに記憶されているデータ、主にトポロジおよび統計を使用して、システムに何が起こっているのかについてユーザに通知するか、またはシステムについての推奨を行う。解析は、データストア内のデータに対してルールエンジンによって実行されるルールセットとして、またはアプリケーションパラメータの調整に使用される解析モデルとして実施することができる。実行可能ないくつかの異なる種類の解析がある。これらは以下を含む。
アプリケーションポイントインタイム解析 ある時点でアプリケーションの性能はどうなっているか、およびリソースの使用を解析する。
アプリケーションデルタ時間解析 ２つの時点間でアプリケーションの性能の何が変更されたか、およびリソースの使用を解析する。
アプリケーションストレージグループ解析 ある時点でのアプリケーションとストレージとの間のパスを解析して、そのパスがホットスポットであるか否か、およびそのパスに対してアプリケーション競合があるか否かを判断する。
ストレージプロビジョニング推奨 アプリケーションに対してより多くの物理ストレージをどこでプロビジョニングすべきかについて推奨を行う。
アプリケーション推奨 アプリケーションパラメータに対する変更を行う
【０１１３】
上記に加えて、既知のＡＰＩ実施に従って構築された各種ＡＰＩ（アプリケーションプログラミングインタフェース）を様々なポイントおよびレイヤに提供して、システム設計者、管理者、または他が望むようにインタフェースを供給してよいことを当業者は理解するであろう。
【０１１４】
Ｃ２．外部発見・収集サービス
これより、機器外部のリソースについてのすべての構成および統計へのアクセスを提供する上述した外部発見・収集（ＥＤａＣ）サービスについてさらに詳細に記載する。ＥＤａＣサービスは、任意の外部リソースに要求をディスパッチすることを担う。図２８は、ＥＤａＣサービス７００の例示的な一実施形態に含まれる様々なコネクタを示す図である。各コネクタ７３０は、特定のリソースへのアクセスを提供する。
【０１１５】
担当リストは以下を含む。すなわち、（１）統計要求イベントをリッスンし、適切なコネクタに転送し、（２）発見要求イベントをリッスンし、適切なコネクタに転送し、かつ（３）発見要求を何等かのスケジュールですべてのコネクタに対して実行し、発見イベントを生成する。本発明のさらなる態様によれば、項目（３）の機能は情報リソースマネージャ（ＩＲＭ）に移してもよい。
【０１１６】
発見処理には２つの部分がある。すなわち、（１）装置を「見つけ」、（２）その装置の最も静的な構成を把握する。発見アルゴリズムは、何千もの装置を処理するのに十分な堅牢性を有さなければならない。完全な発見処理は数時間かかり得る。構成に関しては、以下のデータが、オブジェクトモデルにおいて発見および収集を達成するために必要である。
サーバ：ＩＰアドレス、ログイン／パスワード、ＳＳＨ／telnet、Solarisの場合、ポーリング間隔、および永続的接続
ストレージアレイ：管理サーバ、ログイン／パスワード、ＣＬＩへのパス、ポーリング間隔、永続的接続
アプリケーション：ＩＰアドレス、ログイン／パスワード、サービス名、ポート、ポーリング間隔、永続的接続
【０１１７】
様々な周知のデータアクセスツールを本発明のこの態様と併せて利用することができ、構成可能アクセス方法を含む複数のアクセス方法を利用することができる。これらとしては、サーバへのtelnetアクセス、ＯＤＢＣ（DataDirect Technologies (Bedford, MA)市販のＯＤＢＣライブラリを利用できる）を介するデータベースデータアクセス、ＳＳＨ技法、および他の従来の技法が含まれ得る。
【０１１８】
シーケンスイベントブローカ７１０が、ＥＤａＣコア７２０へのインタフェースを提供し、記載したコネクタ７３０を含む。
【０１１９】
Oracleデータベースコネクタ７３０ａは、データベース構成およびデータベース統計の収集を担う。Oracleデータベースコネクタ７３０ａはＯＤＢＣライブラリ７４０を使用する。
【０１２０】
Windows（登録商標）サーバコネクタ７３０ｂおよびSolarisサーバコネクタ７３０ｃは、メモリの利用ならびにボリューム／ＬＵＮのマッピングおよび統計等のＯＳレベルデータの収集を担う。ボリューム／ＬＵＮマッピングを計算するために、設置されているボリュームマネージャならびにマルチパス製品の両方を把握する必要があり得る。それぞれの詳細、すなわちストライピング特性またはパス情報を把握する必要がない場合であっても、どのＬＵＮがボリュームに関連するかを計算するためだけに、各製品から情報が必要になる可能性が高い。ＥＬＭをターゲットとする特定の製品を選ぶことができる。Solarisサーバコネクタ７３０ｃはＳＳＨを使用する。SolarisのボリュームマネージャはVeritasおよびネイティブのものである。Windows（登録商標）サーバコネクタ７３０ｂはＷＭＩライブラリ７５０を使用する。Windows（登録商標）のボリュームマネージャはネイティブのものであり、これはVeritasである。
【０１２１】
ストレージコネクタ７３０ｄ、７３０ｅ、および７３０ｆは、ＬＵＮの利用、性能、およびＲＡＩＤセット／ディスクへのマッピングの収集およびボックス７６０で包括的に表される他のデータの収集を担う。アレイ性能統計はＥＬＭには必要ない。
【０１２２】
CLARiiONストレージコネクタ７３０ｄに関しては、ＮａｖｉＣＬＩがCLARiiONへのリッチＣＬＩインタフェースである。これは、データをｘｍｌで返すことができる。性能統計はCLARiiONに対してイネーブルし、ＣＬＩを通して検索することができる。ＣＬＩをＡＳＣにインストールすることも可能である。ＣＬＩに顧客サーバのうちの１つからＳＳＨ７８０を通してアクセスする可能性が高い。いくらかのデータは、telnetによってCLARiiONに直接提供されもする。
【０１２３】
Dothillストレージコネクタ７３０ｅに関しては、DothillはホストベースＣＬＩも有する。データをｘｍｌで返すことができる。Dothillは性能統計へアクセスを提供しない。アクセス問題は、CLARiiON ＣＬＩの場合と同じである。いくらかのデータは、telnetによってDothillに直接提供されもする。
【０１２４】
適したＨＰストレージコネクタ７３０ｆも提供される。
【０１２５】
ボックス７３０ｇで表されるように、現在記載しているシステムは、以下の要素、すなわち、ＣＩＭ／ＷＢＥＭ／ＳＭＩ−Ｓアクセス、ＳＮＭＰアクセス、ファブリックコネクタ、外部ＳＲＭコネクタ、リモートプロクシ／エージェント、構成を変更するイベントを含めるように変更し拡張することができる。さらに、１つのWindows（登録商標）エージェントが、「Windows（登録商標）ワールド」へのゲートウェイとして機能することができ、ＷＭＩおよびＯＤＢＣとよりシームレスに統合する。こういった将来のアクセスツールはボックス７７０によって表される。
【０１２６】
Ｃ３．発見エンジン
上で触れた発見エンジンについて、さらに詳細にこれより記載する。発見エンジン（ＤＥ）は、情報リソースマネージャ（ＩＲＭ）に常駐する。発見エンジンは、ユーザによってデータストア（ＤＳ）に入れられたサーバおよびストレージアレイの定期的なトポロジ発見の開始を担う。これは、上述した外部発見・収集（ＥＤａＣ）モジュールと併せてこれを行う。
【０１２７】
ＤＥは、メッセージキューからのメッセージを処理する主ループの周囲に構築される。これらのメッセージとしては以下が含まれる。
発見タイマイベント このイベントは完全な発見処理を開始する。
発見完了イベント これらは、ＤＥによってＥＤａＣに元々送信され、今では、ＥＤａＣがサーバまたはストレージアレイのすべての発見イベントを生成した後、ＥＤａＣによって返されているストレージアレイトポロジ発見イベントおよびサーバトポロジ発見イベントである。これらのイベントは、トポロジ発見がサーバまたはストレージアレイに対して完了したことを示す。
オブジェクト発見イベント ＥＤａＣは、サーバまたはストレージアレイのトポロジを決定する処理において発見した各オブジェクトの発見イベントを生成する。例えば、ＥＤａＣは、サーバのトポロジの決定を要求された場合、サーバ、サーバＦＣポート、サーバボリューム、およびサーバＬＵＮの各発見イベントを生成する。
【０１２８】
主ループは単純に、メッセージキュー上で処理する次のメッセージを待つことができる。
【０１２９】
発見タイマイベント：ＤＥは構成要素タスクフレームワーク（ＣＴＦ）を使用して、発見間隔タイマを設定する。タイマが切れた場合、ＣＴＦはメッセージを生成し、ＤＥのメッセージキューに送出する。これは、ＤＥに、発見処理を開始する時間であることを通知する。
【０１３０】
発見タイマイベントは、ＤＥにＮ個の初期発見サーバトポロジイベントまたは発見ストレージアレイトポロジイベントを並列に開始させる。Ｎは任意の数である。トポロジを発見するサーバまたはストレージアレイがなくなるまで、常にＮ個の未処理の発見トポロジイベントがあることになる。
【０１３１】
サーバまたはストレージアレイ発見完了イベント：サーバまたはサーバアレイ発見完了イベントは、実際には、ＥＤａＣがそのオブジェクトに対する発見を完了した後、ＤＥに返されたサーバトポロジ発見イベントまたはストレージアレイトポロジ発見イベントである。
【０１３２】
発見完了イベント処理：この処理ステップは以下の通りである。
１．ＤＥがＤＳに、オブジェクトトポロジ発見中に発見されなかった既存の任意の記録、例えばサーバＬＵＮか否かを見つけるように問い合わせる。ＤＳは、発見タイムスタンプが現在の記録のものと同じではないすべての記録にクエリを作成することによってこれを行う。
２．タイムスタンプが一致しない各記録について、失われたイベント、例えば、サーバボリュームロストイベントが生成され送信される。
３．発見すべきサーバまたはストレージアレイがまだある場合、次のものがＤＳから検索され、それに対するトポロジ発見イベントがＥＤａＣに送信される。
４．発見すべきサーバまたはストレージアレイがもうない場合、発見は完了し、発見間隔タイマが再開される。
【０１３３】
オブジェクト発見イベント：トポロジ発見イベントを受信すると、ＥＤａＣは、トポロジについてサーバまたはストレージアレイに問い合わせる。トポロジは記録セットからなる。ＥＤａＣは、現在のイベントに対する発見イベントセットを生成する。発見イベントが特定の順序で行われることが重要である。
【０１３４】
サーバトポロジ発見イベント：サーバ発見イベント、サーバＦＣポート発見イベント、サーバボリューム発見イベント、サーバＬＵＮ発見イベント。
【０１３５】
ストレージアレイトポロジ発見イベント：ストレージアレイ発見イベント、ストレージアレイＦＣポート発見イベント、ストレージアレイディスク発見イベント、ストレージアレイＬＵＮ発見イベント。
【０１３６】
各発見イベントには、その発見のタイムスタンプが含まれる。タイムスタンプはＥＤａＣによって挿入される。特定のストレージアレイまたはサーバについての各発見イベントは同じタイムスタンプ値を有する。
【０１３７】
発見処理：この処理ステップは以下の通りである。
１．ＤＥがデータストアに問い合わせて、記録がすでに存在するか否かを判断する。
２．記録がすでに存在する場合、記録関係が検証され、発見タイムスタンプが更新される。
３．記録がＤＳ内に存在しない場合、他の記録に対する関係と共に記録が作成される。したがって、このステップでの処理は特に、発見中の記録に対するものである。
４．「記録発見」イベントが作成され、ログに記憶される。
【０１３８】
Ｄ．アプリケーションシステム負荷の管理−一般的な方法
図２９Ａは、デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する一般的な方法８００のフローチャートである。この方法は、有利なことに、少なくとも１つの中央演算処理装置（ＣＰＵ）と、ＣＰＵがデジタル計算システムの他の要素と通信可能にするように動作可能なネットワークと、少なくとも１つのストレージ装置を含み、少なくとも１つのＣＰＵと通信するように動作可能なストレージエリアネットワーク（ＳＡＮ）とを含むネットワーク化されたデジタル計算システムで実施することができる。計算システムは、少なくとも１つのアプリケーションプログラムを実行するように動作可能であり、少なくとも１つのアプリケーションプログラムは、アプリケーションプログラムの実行を制御するように調整可能なアプリケーションパラメータを有する。
【０１３９】
本発明による例示的な方法をボックス８０１〜８０３に示す。
【０１４０】
ボックス８０１：デジタル計算システムの要素と通信するように動作可能な情報リソースマネージャ（ＩＲＭ）を利用して、計算システムの動作および計算システム内で利用可能なリソースに関する性能情報を取得し、少なくとも１つのＣＰＵ、ネットワーク、およびＳＡＮと通信して、そこから性能情報および構成情報を取得する。本書の他のどこかに記したように、性能情報および構成情報は、デジタル計算システム内の任意のＣＰＵ、ネットワーク、またはストレージ装置からのものであってよい。情報は、Ｉ／Ｏまたは他のコマンドをデジタル計算システムの少なくとも１つの要素に発行することによって取得することができる。ＩＲＭは、デジタル計算システム内の離散モジュールであってもよく、または計算システムサブシステムもしくはＳＡＮ内のストレージネットワークファブリックサブシステム内のモジュールとして実施されてもよい。
【０１４１】
ボックス８０２：性能情報および構成情報を利用して、解析モデル出力を生成し、解析モデル出力は性能統計および更新アプリケーションパラメータのうちの任意のものを含む。本書の他のどこかに記したように、本発明は、キューイング理論を利用して、ストレージシステムまたはサブシステムがサポートできる負荷の程度を決定することができる。
【０１４２】
ボックス８０３：解析モデル出力を利用して、更新アプリケーションパラメータ値を決定し、更新アプリケーションパラメータ値を、デジタル計算システムで実行されている少なくとも１つのアプリケーションに送信し、アプリケーションは更新アプリケーションパラメータ値を使用してアプリケーションパラメータを設定し、それにより、更新実行時パラメータを使用して、デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する。本書の他のどこかに記したように、この方法は負荷値、例えば、キューイング理論を使用して決定された負荷値を利用して、所与のアプリケーションのパラメータ値を決定することができる。この方法は、更新アプリケーションパラメータ値を決定する際に、いくつかのアプリケーション固有パラメータ、例えば、コストベース最適化（ＣＢＯ）パラメータを考慮することを含むこともできる。
【０１４３】
図２９Ｂは、図２９Ａの方法８００を繰り返して、または他の様式でどのように続けて実行することができるかを示し、動作中にストレージシステムの性能を引き続きプロファイリングし、それにより、一連の時間ベースのサンプルを収集すること（８０４）、時間ベースのサンプルに応答して更新プロファイルを生成すること（８０５）、および更新プロファイルに応答して、所与のアプリケーションが実行される際に、更新アプリケーションパラメータセットを送信すること（８０６）によって含む。本書の他の部分に記したように、この方法は、システムが連続して性能状態の性能遷移に適応しないように、アプリケーションパラメータ更新の頻度を抑制制御する、選択された程度を提供することを含むことができる。この方法は、発見インタフェースを介してデジタル計算システムの個々の要素と直接通信することを含むこともできる（図２９Ｂと図２９Ａとの例示的な対応性が各図の点「Ａ」と「Ｂ」を介して示される）。
【０１４４】
図３０は、本書の他の部分の考察により、本発明による方法８１０を、複数のアプリケーションがネットワーク、ストレージ、または他のリソースを共有している環境内でどのようにさらに実施できるかを示し、競合するアプリケーション作業負荷の影響を決定し、それを考慮に入れるように解析モデルを調整すること（８１１）、改良されたリソース共有に役立つように複数のパラメータ値セットを調整すること（８１２）、および必要に応じて、あるアプリケーション、そのＩ／Ｏ要求、または他の側面を別のアプリケーション、そのＩ／Ｏ要求、または他の側面よりも優先するように、パラメータ値を調整することによって含む。
【０１４５】
Ｅ．アプリケーションシステムストレージリソースのマルチレベルマッピング
米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）において考察されたものと同様の１つまたは複数のデジタルストレージ環境について上述したが、次に、本発明の態様、実施形態、および例についてのさらに詳細な説明に進む。本願は、米国特許出願第１１／７７３８２５号の一部継続出願（ＣＩＰ）である。米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）において記載されているデジタル処理、計算、またはストレージ環境が、本発明を実施することができる処理環境の例のうちのいくつかにすぎないことを当業者は理解するとともに、本発明を上述した、かつ米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）において記載される環境以外の環境で実施してもよいことも理解するであろう。
【０１４６】
特に、本発明の態様は、アプリケーションにシステムリソースを効率的にマッピングするように動作可能な方法、システム、装置、およびコンピュータプログラムコード（ソフトウェア）製品、ならびに係る方法およびシステムを利用する改良されたストレージプラットフォームおよびアーキテクチャを提供する。このマッピングの基礎は、アプリケーションリソースグループ（ＡＲＧ）の定義であり、ＡＲＧは、アプリケーションに関連するサーバ、バスアダプタ、ボリューム、論理ユニット番号（ＬＵＮ）、ネットワークスイッチ、ディスクコントローラ、およびディスクについての完全な情報を提供する。
【０１４７】
本発明の現在記載している態様について、ストレージエリアネットワーク（ＳＡＮ）インフラストラクチャアーキテクチャに関して記載する。しかし、記載されるシステムおよび技法の態様を他の計算環境で実施してもよいことが理解されるであろう。
【０１４８】
ストレージエリアネットワーク（ＳＡＮ）は、ディスクドライブアレイ等のリモートコンピュータストレージ装置を、オペレーティングシステムにとって装置がローカルに取り付けられているように見えるようにホストサーバに取り付けられるようにするアーキテクチャである。
【０１４９】
図３１は、いくつかの異なるレベルでのＳＡＮインフラストラクチャの例示的なマッピングを示す表１０００である。表の１列目１００１には以下の定義レベルが列挙される。
１００１ａ−サーバレベル
１００１ｂ−バスアダプタレベル
１００１ｃ−ネットワークスイッチレベル
１００１ｄ−ディスクコントローラレベル
１００１ｅ−ディスクレベル
【０１５０】
表の２列目１００２には、各定義レベルに対応する以下の定義グループが列挙される。
１００２ａ−サーバレベルに対応するアプリケーションサーバグループ（ＡＳｅｒＧ）
１００２ｂ−バスアダプタレベルに対応するアプリケーションアダプタグループ（ＡＡＧ）
１００２ｃ−ネットワークスイッチレベルに対応するアプリケーションスイッチグループ（ＡＳｗＧ）
１００２ｄ−ディスクコントローラレベルに対応するアプリケーションコントローラグループ（ＡＣＧ）
１００２ｅ−ディスクレベルに対応するアプリケーションストレージグループ（ＡＳＧ）
【０１５１】
表の列１００３に示すように、各レベル１００１ａ−ｅおよびグループ１００２ａ−ｅは、例示的なインフラストラクチャアーキテクチャの各要素の１つまたは複数のサブセットに対応する。
１００３ａ−アプリケーション（ＡＰＰ）
１００３ｂ−サーバ（ＳＥＲＶ）
１００３ｃ−バスアダプタ（ＢＡ）
１００３ｄ−ボリューム（ＶＯＬ）
１００３ｅ−論理ユニット番号（ＬＵＮ）
１００３ｆ−スイッチ（ＳＷ）
１００３ｇ−コントローラ（ＣＴＬＲ）
１００３ｈ−ディスクアレイ（ＤＩＳＫ）
【０１５２】
一般的に言えば、各グループ１００２ａ−ｅはその名称が付けられた要素と、アプリケーション１００３ａまでのすべての「上流」要素とを含む。したがって、例えば、アプリケーションスイッチグループ（ＡＳｗＧ）は、スイッチ（ＳＷ）と、スイッチの上流にある要素、すなわち、論理ユニット番号（ＬＵＮ）、ボリューム（ＶＯＬ）、バスアダプタ（ＢＡ）、サーバ（ＳＥＲＶ）、およびアプリケーション（ＡＰＰ）とを含む。後述する各グループの特定のインフラストラクチャ要素の選択を図３２〜図３７に示す。
【０１５３】
さらに、本発明の現在記載している態様は、サブグループ１００２ｆの定義をさらに提供する。表１０００では、例示的なサブグループ１００２が、アプリケーションストレージグループ（ＡＳＧ）内の個々のＬＵＮについてのより詳細な情報を提供するものとして定義され、ＬＵＮと、ＳＡＮスイッチ１００３ｆ、コントローラ１００３ｇ、およびディスクアレイ１００３ｈを含む「下流」要素とを含む。後述するサブグループの特定のインフラストラクチャ要素の選択を図３８、図３９Ａ、および図３９Ｂに示す。
【０１５４】
このアプリケーション−ストレージシステムのマッピングのより完全な知識に基づいて、アプリケーションに関連するシステムリソースをより制約の小さいシステムリソースにリマッピングまたは再構成して、システム内の性能ボトルネックを除去することができる。これらの特徴および要素のそれぞれについてさらに詳細に後述する。
【０１５５】
本発明は、ストレージシステム内に記憶されているデータにアクセスする際に、アプリケーションの性能に影響を及ぼし得る他のリソース（すなわち、サーバ、ネットワークスイッチ、ディスクコントローラ、ディスク）を識別するために、データパスを発見する能力を利用する。本発明は、複数のアプリケーションがストレージシステム内の要素を共有しているときをユーザが明確に識別できるようにする。
【０１５６】
本発明は、エージェントレスの方法の組み合わせを利用して、ＡＲＧトポロジを発見する。これらの方法は、既存のＡＰＩおよびオペレーティングシステムユーティリティを利用して、サーバ、スイッチ、アダプタ、およびディスクインタフェースにおいてトポロジマッピング情報を捕捉することを含む。
【０１５７】
これとは対照的に、初期の一技法は、トポロジを発見できるようにアプリケーションに接続することに依存するエージェントベースの手法を使用する。この技法は、著しいオーバーヘッドをシステムにもたらし、潜在的に、実行中のアプリケーションの挙動に影響を及ぼし得る。
【０１５８】
本発明はこれらの問題を実質的に回避する。本発明は、アプリケーションとストレージシステムとのストレージシステムマッピングおよびデータパスの両方の完全な知識を利用することによってアプリケーションの信頼性またはセキュリティを向上させるように容易に拡張することも可能である。
【０１５９】
ストレージシステム性能の管理に使用される従来の方法は、アプリケーションまたはストレージシステムのいずれかのみに焦点を合わせ、これらの２つの関係を考慮しない。システムの制限されたビューを利用することに伴ういくつかの問題としては、
（１）問題が往々にして誤診断されることがあるとともに、アプリケーションボトルネック、例えばサーバメモリ使用率、またはストレージシステムボトルネック、例えば、ディスクコントローラ接続のいずれかまたは両方に起因し得ること、
（２）共有されるアプリケーションサーバ、ネットワークスイッチ、またはストレージサブシステムを利用する複数のアプリケーションまたは複数のサーバを同時に管理することが殆ど考慮されていないこと、および
（３）ストレージ、ネットワーク、およびサーバの仮想化技法が、アプリケーションとシステムリソースとの間にさらなるレベルの抽象を追加し得、性能の帰属をさらに難しくすること
が挙げられる。
【０１６０】
本発明は、すべてのシステムリソースおよびパスを個々のアプリケーションに結び付けるモデルを定義する。本発明はストレージ装置（すなわち、個々のディスクスピンドル）の観点から元の個々のアプリケーションへのマッピングを定義する。本発明の主要要素は、ストレージシステム内の任意の競合ポイントに関連するアプリケーションセットを容易に識別可能なことである。
【０１６１】
本発明は、アプリケーションとサポートしているストレージシステムとの動的に変更するマッピングを捕捉することにより、ストレージサブシステム情報を取得する能力を含む。この情報は、ストレージシステムおよびアプリケーションを定期的にプロービングして、マッピングへのあらゆる変更を追跡することによって取得することができる。
【０１６２】
Ｆ．マルチレベルマッピングの実施形態
以下の考察には、本発明の開示の理解を提供し、本発明の開示を可能にする多くの特定の詳細を記す。本発明をこれらの特定の詳細なしで実施してもよいことを当業者は理解するであろう。場合によっては、周知の方法、手続き、構成要素、プロトコル、アルゴリズム、および回路については、本発明を曖昧にしないように詳細に記載されていない。
【０１６３】
上記考察には、ストレージリソースをこれらのリソースを利用するアプリケーションにマッピングする必要性について記載した。以下の考察には、添付の図面と併せて、システムリソースをアプリケーションに効率的にマッピングするように動作可能な本発明の実施態様について記載する。
【０１６４】
これより図３２を参照すると、図３２には、以下の要素を含むコンピュータシステムインフラストラクチャ１０１０の一例が示される。すなわち、
２つのアプリケーションサーバ１０１１および１０１２、
３つのアプリケーション１１００、１１１０、および１１２０、
２つのバスアダプタ１２００および１２１０、
４つのストレージボリューム１３００、１３１０、１３２０、および１３３０、
５つのサーバＬＵＮ１３０１、１３１１、１３２１、１３２２、および１３３１、
１つのネットワークスイッチ１４００、
３つのディスクコントローラ１５００、１５１０、および１５２０、ならびに
３つのディスクグループ１５０１、１５１１、および１５２１
である。
【０１６５】
図示のシステムの基盤をなすハードウェア要素（例えば、基盤をなすサーバ、バスアダプタ、ストレージボリューム、サーバＬＵＮ、ネットワークスイッチ、ディスクコントローラ、およびディスクグループ）ならびにアプリケーションは、一般に従来の性質のものであってよく、市販の製品を使用して当業者によって実施することができる。
【０１６６】
図３２が例示的なものであり、本記載のために提供されることに留意されたい。例えば、上述したように、実際のＳＡＮには、何百もの、さらには何千ものＬＵＮがあり得る。特定のネットワークを別様に構成してもよく、または特定のネットワークが異なる要素を含んでもよい。現在記載しているシステムおよび技法の態様も同様にそれらの文脈の中で適用してもよいことが理解されるであろう。
【０１６７】
例えば、図３２に示すようなデジタル計算環境またはプラットフォームで実施される本発明によれば、アプリケーションリソースグループ（ＡＲＧ）が定義される。ＡＲＧは、共通のシステムリソースセットを包含し、アプリケーションセットからシステム内で使用されるシステム要素（例えば、サーバ、ホストアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスク）への完全または略完全なマッピングとして定義される。
【０１６８】
さらに、本発明によれば、ＡＲＧは、アプリケーションサーバグループ（ＡＳｅｒＧ）、アプリケーションアダプタグループ（ＡＡＧ）、アプリケーションスイッチグループ（ＡＳｗＧ）、アプリケーションコントローラグループ（ＡＣＧ）、およびアプリケーションストレージグループ（ＡＳＧ）の定義を含む。ＡＲＧは、アプリケーションとストレージシステムとの間のパス内の任意のポイントでの完全なマッピングを提供する。
【０１６９】
ＡＲＧは、ストレージシステム内の任意の要素に対して負荷を発生させているアプリケーションセットの階層図を提供する。複数のアプリケーションが単一のストレージ要素に関して競合しており、かつ性能ボトルネックが生じている場合、ＡＲＧは、ボトルネックの原因であり得るアプリケーションセットを識別することができる。
【０１７０】
図３３は、本発明によるサーバ１０１１のアプリケーションサーバグループ（ＡＳｅｒＧ）を示す。ＡＳｅｒＧは、アプリケーション１１００および１１１０をサーバ１０１１に負荷をかけているアプリケーションとして識別する。
【０１７１】
図３４は、本発明によるバスアダプタ１２１０のアプリケーションアダプタグループ（ＡＡＧ）を示す。ＡＡＧは、アプリケーション１１２０をバスアダプタ１２１０に負荷をかけているアプリケーションとして識別する。ＡＡＧは、バスアダプタ１２１０がサーバ１０１２に接続されていることも識別する。
【０１７２】
図３５は、本発明によるネットワークスイッチ４００のアプリケーションスイッチグループ（ＡＳｗＧ）を示す。ＡＳｗＧは、アプリケーション１１００、１１１０、および１１２０をネットワークスイッチ４００に負荷をかけているアプリケーションとして識別する。ＡＳｗＧは、スイッチ１４００がＬＵＮ１３０１、１３１１、１３２１、１３２２、１３３１に接続され、ＬＵＮ１３０１、１３１１、１３２１、１３２２、１３３１は、ボリューム１３００、１３１０、１３２０、および１３３０のマッピングに使用され、ボリューム１３００、１３１０、１３２０、および１３３０はバスアダプタ１２００および１２１０に接続され、バスアダプタ１２００および１２１０はサーバ１０１１および１０１２に接続されていることも識別する。
【０１７３】
図３６は、本発明によるディスクコントローラ１５１０のアプリケーションコントローラグループ（ＡＣＧ）を示す。ＡＣＧは、アプリケーション１１２０をディスクコントローラ１５１０に負荷をかけているアプリケーションとして識別する。ＡＣＧは、コントローラ１５１０がネットワークスイッチ４００に接続され、ネットワークスイッチ４００がＬＵＮ１３２１および１３２２に接続され、ＬＵＮ１３２１および１３２２がボリューム１３２０のマッピングに使用され、ボリューム１３２０がバスアダプタ１２１０に接続され、バスアダプタ１２１０がサーバ１０１２に接続されていることも識別する。
【０１７４】
図３７は、本発明によるディスクアレイ１５０１のアプリケーションストレージグループ（ＡＳＧ）を示す。ＡＳＧは、アプリケーション１１００および１１１０をディスクアレイ１５０１に負荷をかけているアプリケーションとして識別する。ＡＳＧは、アレイ１５０１がディスクコントローラ１５００によって接続され、ディスクコントローラ１５００がネットワークスイッチ４００に接続され、ネットワークスイッチ４００がＬＵＮ１３０１および１３１１に接続され、ＬＵＮ１３０１および１３１１がボリューム１３００および１３１０のマッピングに使用され、ボリューム１３００および１３１０がバスアダプタ１２００に接続され、バスアダプタ１２００がサーバ１３００に接続されることを識別する。
【０１７５】
本発明では、任意のＡＲＧ抽象を単一のアプリケーションに関連するＬＵＮまでさらに分解するサブグループも定義される。各ＡＲＧ抽象（ＡＳｅｒＧ、ＡＳｗＧ、ＡＳｅｒＧ、ＡＣＧ、およびＡＳＧ）は、少なくとも１つの、恐らくは複数のサブグループを含むことになる。単一のサブグループは、単一のＡＳＧ抽象内でのみ提示することができる。サブグループは、単一のストレージ要素とアプリケーションとの関係の粒度をさらに改善する。
【０１７６】
図３８、図３９Ａ、図３９Ｂは、本発明によるサブグループの詳細図を提供する。サブグループは、ストレージ要素に負荷を発生させている原因であるアプリケーションに関連するＬＵＮのより詳細な図を提供する。
【０１７７】
図３８は、単一のバスアダプタ１２３０を使用する単一のアプリケーション１１３０を実行しているホストサーバ１０１３を含む代替のインフラストラクチャアーキテクチャを示す。単一のアプリケーション１１３０は複数のボリューム１３５０および１３６０にマッピングされ、これらの各ボリュームは複数のＬＵＮにマッピングされ得る。ボリューム１３５０はＬＵＮ１３５１および１３５２にマッピングされ、ボリューム１３６０はＬＵＮにマッピングされる。各ＬＵＮは異なるＲＡＩＤグループにマッピングすることができる。ＬＵＮ１３５１はディスクアレイ１５３１にマッピングされ、ＬＵＮ１３５２および１３６１はディスクアレイ１５４１にマッピングされる。
【０１７８】
図３９Ａは、ＬＵＮ１３５１、スイッチ１４１０、コントローラ１５３０、およびディスクアレイ１５３１を含む第１のサブグループＡ１６００を示す。図３９Ｂは、ＬＵＮ１３５２および１３６１、スイッチ１４１０、コントローラ１５４０、ならびにディスクアレイ１５４１を含む第２のサブグループＢを示す。
【０１７９】
サブグループは、ストレージ要素内で性能問題の原因であり得る単一のアプリケーションに関連するＬＵＮの識別を助けることができる。例えば、図３９Ａに示すように、サブグループＡ１６００を使用して、アプリケーション１１３０内の特定のどのプロセスがディスクアレイ１５３１で受けている負荷の原因であるかを識別することが可能である。
【０１８０】
アプリケーションのＡＲＧマッピングを完全に記述するために必要な情報は、いくつかの方法を通して取得することができる。この情報は、既存のオペレーティングシステムインタフェース（例えば、Windows（登録商標）の場合、ＷＭＩ）を通して、またはオペレーティングシステムユーティリティおよびボリュームマネージャ）（例えば、Solarisの場合、Solarisボリュームマネージャ）を使用して発見することができる。スイッチレベル発見は、スイッチ製造業者によって規定される簡易ネットワーク管理プロトコル（ＳＮＭＰ）ＡＰＩを使用する。ディスクアレイレベル発見は、Storage Network Industry Associationによって規定されるストレージ管理イニシアティブ仕様（ＳＭＩ−Ｓ）ＡＰＩならびにコマンドラインインタフェース（ＣＬＩ）を使用する。ローカル−物理ＬＵＮマッピングは、ネットワークによって定義され、Unix（登録商標）上のオペレーティングシステムユーティリティまたはWindows（登録商標）上のWindows（登録商標）レジストリを使用して得られるワールドワイドネーム（ＷＷＮまたはＷＷＩＤ）を使用して得られる。
【０１８１】
本発明の一実施では、ＡＲＧトポロジは、サーバまたはストレージシステムのいずれかで実行されている仮想化技術によって曖昧になり得る。システムの発見要素は、仮想化技術によって提供される利用可能なＡＰＩを利用することができる（例えば、ＶＭＷａｒｅのＥＳＸコレクタが仮想化されたホストツールと協働する）。次に、仮想化システム要素または存在する実際の物理要素のいずれかを示すＡＲＧトポロジをユーザに提示することができる。
【０１８２】
上述したオペレーティングシステムインタフェースの例（ＷＭＩ、Solarisボリュームマネージャ）、ＡＰＩの例（ＳＭＩ−Ｓ、ＣＬＩ等）、およびVMWareのＥＳＸコレクタ等の仮想化の例が、市販の製品またはサービスを指し、それらと相互動作可能なように本発明を実施可能なことを当業者は理解するであろう。
【０１８３】
図４０は、本発明の方法およびシステムの一実施２０００を示すフローチャートを提供し、以下を含む。
ボックス２００１−サーバ、ネットワーク、およびストレージサービスに問い掛けることによってトポロジを最初に発見する
ボックス２００２−仮想化が使用されている場合、存在する任意の仮想−物理マッピングを発見する
ボックス２００３−ＡＳｅｒＧ、ＡＡＧ、ＡＳｗＧ、ＡＣＧ、およびＡＳＧの各グループならびにサブグループを識別する
ボックス２００４−トポロジ内のすべてのポイントで実行統計を収集し、統計リポジトリに記憶する
ボックス２００５−トポロジの特定のグループビューに基づいて収集された実行統計を照会する
ボックス２００６−性能情報をシステムユーザに報告する
【０１８４】
Ｇ．結び
上記記載は当業者が本発明を実施できるようにする詳細を含むが、この記載は例示的な性質のものであり、その多くの変更および変形が本教示の恩恵を有する当業者には明らかであり、そういった変更および変形が本発明の主旨および範囲内にあることを認められたい。したがって、本明細書における本発明は添付の特許請求の範囲によってのみ規定され、特許請求の範囲は先行技術によって許される限り広義に解釈されることが意図される。
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、２００６年１２月２１日に出願され「Methods and Systems for Identifying Application System Storage Resources（アプリケーションシステムストレージリソースを識別する方法およびシステム）」という名称の米国仮特許出願第６０／８７１４４４号（代理人整理番号：ＡＫＲ−１１４−ＰＲ）の優先権の利益を主張するものであり、この仮特許出願を、その全体が記載されているかのように参照により本明細書に援用する。
【０００２】
本特許出願は、２００７年７月５日に出願され「Managing Application System Load（アプリケーションシステムの負荷管理）」という名称の米国特許出願第１１／７７３８２５号（代理人整理番号：ＡＫＲ−１１０−ＵＳ）の一部継続出願（ＣＩＰ）でもあり、この特許出願も参照により本明細書に援用され、その詳細な説明および図面が本明細書において記載される。そして、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）は、２００６年７月６日に出願された米国仮特許出願第６０／８０６，６９９号（ＡＫＲ−１１０−ＰＲ）の優先権の利益を主張するものであり、この仮特許出願を、その全体が記載されているかのように参照により本明細書に援用する。
【０００３】
発明の分野
本発明は、一般には、デジタル処理システム、装置、およびネットワークに関し、より詳細には、アプリケーション性能および自己管理システムの分野に関する。さらにより詳細には、本発明は、システムリソースで生じた性能問題を、性能制約システムリソースに対して負荷を生み出しているアプリケーションサーバ、アプリケーション、およびアプリケーションタスクに再びマッピングする方法、システム、および装置に関する。
【背景技術】
【０００４】
発明の背景
多くのストレージプラットフォームでは、ストレージ管理者がストレージリソースを異なるハードウェアサーバに割り振りそして割り当てることができる。単一のハードウェアサーバは複数のアプリケーションを並行に実行することができる。単一のアプリケーションはいくつかの並行タスクを具現することができる。単一のアプリケーションは、通常、いくつかのシステムリソースを利用する。アプリケーション性能は、アプリケーションのシステムリソースへのアクセスを最適化できる場合、潜在的に加速することができる。
【０００５】
不都合なことに、従来のストレージプラットフォームでは、ユーザまたはシステム管理者は、個々のアプリケーションがシステムリソースセットをどのように利用するかについて殆ど指針を有さない。同じハードウェアサーバで並行に実行されている２つのアプリケーションが、共通のシステムリソースに対する競合により、ストールする場合があり得る。システムリース競合は識別することができるが、アプリケーションからそのアプリケーションを使用しているシステムリソースへのマッピング、およびこの逆のマッピングを識別できない場合を除き、問題の原因を完全には知ることなく、性能ボトルネックを修復しようと試みることができる。
【０００６】
より詳細には、アプリケーションは、多くの場合、ストレージエリアネットワーク（ＳＡＮ）を通して共通のストレージシステムを共有するサーバにホストされる。アプリケーションの要求と中央ストレージの能力との不均衡は、中央ストレージリソースを共有しているアプリケーションの全体性能を不良にし得る。この不均衡は、サーバ（ＣＰＵおよびメモリ）、バスアダプタ、スイッチ、ディスクコントローラ、およびディスクアレイを含むいくつかの任意の異なるシステム要素のアプリケーションによる使用に影響を及ぼし得る。
【０００７】
個々のアプリケーションは、サーバとサポートしているストレージサブシステムとの間のパス内の任意の特定のシステム要素に対して大きすぎる負荷をかけている場合、性能の影響を受け得る。さらに、同じまたは独立したサーバで実行されている複数のアプリケーションは、ネットワークおよびストレージがアプリケーションおよびサーバで共有されている場合、互いの性能に影響を及ぼし得、多くの場合、ＳＡＮが共有リソースとして導入される。
【０００８】
任意のアプリケーションの性能は、アプリケーションが単一の装置に対して大きすぎる負荷を生成する場合、または複数のアプリケーションが多くの要求でシステムを溢れさせる場合に低下し得、それにより、ストレージシステムが集合負荷にサービス提供することができなくなる。
【０００９】
ストレージシステムにアクセスする際にあるアプリケーションが別のアプリケーションに対して生じさせる干渉は、性能の大きなばらつきに繋がり得る。より予測可能なアプリケーション性能を提供しようという試みは、多くの場合、システムリソース（例えば、ＣＰＵ、メモリ、ネットワーク、ディスク）のオーバープロビジョニングに繋がる。
【００１０】
ストレージプラットフォームのリソースに関連する問題のうちのいくつかに対処する既知の一方法は、ストレージリソース管理（ＳＲＭ）であり、通常、ＳＲＭは、割り振られたリソースセットのトポロジを発見し、その性能の健康状態を評価する計測機能を提供する。システム性能の健康状態は、応答時間およびストレージ帯域幅に関して測定することができる。ＳＲＭは、性能が制約されたストレージリソースを検出し、これをストレージ管理者に報告することができる。
【００１１】
ネットワーク化された特定のストレージリソースセットを使用するアプリケーションセットの識別を可能にするには、ストレージシステムとアプリケーションとの間の完全なマッピングが要求される。マッピングは、（１）アプリケーションによって使用されているすべてのシステムリソース（例えば、個々のディスク、ディスクコントローラ、バスアダプタ）についての情報および（２）ストレージシステムからアプリケーションサーバへのパス（ボリュームＬＵＮマッピングおよびネットワークスイッチを含む）の両方を含まなければならない。
【００１２】
例として、米国特許第７，０５８，５４５号（「’５４５号特許」）は、参照により本明細書に援用され、ストレージ装置とアプリケーションとの間の論理データパスおよび物理データパスを識別するが、パスを構成するすべてのシステムリソースを識別する能力を有さない方法を記載している。’５４５号特許は、データパスを管理して、データパスの性能、信頼性、またはセキュリティを増大させることを対象とし、複数のアプリケーション間の競合に対処しない。
【特許文献１】米国特許第７，０５８，５４５号
【発明の概要】
【発明が解決しようとする課題】
【００１３】
したがって、特に、複数のアプリケーションが実行されている現実世界環境において、システムリソースをアプリケーションに効率的にマッピングするように動作可能な方法およびシステムを提供することが有用である。
【００１４】
このような方法およびシステムを利用する改良されたストレージプラットフォームおよびアーキテクチャを提供することも有用である。
【課題を解決するための手段】
【００１５】
これらのニーズを満たし、他の技術的利点および特徴を提供する本発明について、次に、添付の図面に関連して詳細に説明する。
【００１６】
発明の概要
本発明は、デジタル処理環境内、より詳細にはデジタルストレージ環境内で動作可能であり、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素との間のマッピングを可能にするとともに、デジタルストレージ環境内の任意のストレージ要素に対して負荷を発生させているアプリケーション（他のソフトウェアプログラム）セットの階層イメージを提供する方法、装置、システム、およびコンピュータプログラムコード（ソフトウェア）製品を提供する。
【００１７】
例として、本発明の一態様は、（Ａ）集合的にデジタルストレージ環境内のストレージ要素である、少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境内で動作可能なこのような方法、装置、システム、およびコンピュータプログラムコード（ソフトウェア）製品を提供するが、この少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、デジタルストレージ環境内のストレージ要素である。本発明のこの態様は、（Ａ）アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供することと、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義することと、
ＡＲＧはＡＲＧ抽象を含み、ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
ＡＲＧおよびサブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である。
【００１８】
本発明の別の態様では、ＡＲＧおよびサブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である。
【００１９】
本発明の別の態様では、ＡＲＧおよびサブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、ＡＲＧが、ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である。
【００２０】
本発明のさらに別の態様では、ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される。
【００２１】
さらなる詳細、例、および実施形態を、添付図面と併せて読まれるべき以下の詳細な説明において説明する。
【００２２】
上述したように、本発明は、２００７年７月５日に出願された「Managing Application System Load（アプリケーションシステムの負荷管理）」という名称の米国特許出願第１１／７７３８２５号（代理人整理番号：ＡＫＲ−１１０−ＵＳ）の一部継続出願（ＣＩＰ）であるため、以下の詳細な説明ではまず、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）の発明を記載し（以下のセクションＡ〜Ｄ）、それから、本発明の説明に続く（以下のセクションＥおよびＦ）。当業者は、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）内で記載されているデジタル処理、計算、またはストレージ環境が、本発明を実施することができる処理環境の例のうちのいくつかにすぎないことを理解するとともに、本発明を米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）で記載される環境以外で実施可能なことも理解するであろう。
【００２３】
当業者は、添付図面に関連して行われる以下の詳細な説明に基づく本発明を容易に理解するであろう。
【図面の簡単な説明】
【００２４】
【図１】本発明を実施することができるか、または本発明を実施することができるネットワーク化されたデジタル計算システムの一部分を形成し得る従来のワークステーションまたはＰＣ（パーソナルコンピュータ）デジタル計算システムの概略図である（先行技術）。
【図２Ａ】本発明を実施することができるネットワーク化されたデジタル計算システムの概略図である（先行技術）。
【図２Ｂ】図１に示すような従来のワークステーション環境またはＰＣ環境の構成要素の概略図である（先行技術）。
【図３】本発明の一実施形態の概略図である。
【図４】本発明を実施することができるデジタル計算システムの概略図である。
【図５】調整可能なアプリケーションパラメータを有するアプリケーションプログラムを示す概略図である。
【図６】デジタル計算システムで実行されており、システム負荷を発生させているアプリケーションの概略図である。
【図７】本発明により構築された計算システムおよび情報リソースマネージャ（ＩＲＭ）を示す概略図である。
【図８】計算システムで実行されているアプリケーションの性能統計、構成データ、およびアプリケーションパラメータのデータベースを示す概略図である。
【図９】本発明により性能情報を計算システムからどのように得ることができるかを示す概略図である。
【図１０】本発明により構成情報を計算システムの各要素からどのように得ることができるかを示す概略図である。
【図１１】本発明の一実施形態によるＩＲＭの解析モデルの態様を示す概略図である。
【図１２】本発明により、構成データ、ＣＰＵ統計、ネットワーク統計、およびＳＡＮ統計を使用して、解析モデルをどのように構築することができるかを示す概略図である。
【図１３】本発明の一実施により、解析モデルが更新アプリケーションパラメータセットをどのように生成するかを示す概略図である。
【図１４】本発明の一実施形態により、更新アプリケーションパラメータを使用して、アプリケーションによって使用されているアプリケーションパラメータセットがどのように更新されるかを示す概略図である。
【図１５】情報リソースマネージャ（ＩＲＭ）がいくつかのＣＰＵ統計、ネットワーク統計、およびＳＡＮ統計をどのように維持することができるかを示す概略図である。
【図１６】本発明により、複数の更新統計セットを解析モデルにどのように適用することができるかを示す概略図であり、次に、解析モデルは、計算システムで実行されているアプリケーションデータを更新する。
【図１７】本発明の一実施形態によるＥＬＭアーキテクチャの主要構成要素の概略ブロック図である。
【図１８】ＥＬＭアーキテクチャの統計収集のタイミングを示す図である。
【図１９】ＥＬＭ統計の収集および計算の頻度のサマリを提供する表である。
【図２０】ＥＬＭ統計のサマリを提供する表である。
【図２１】ＥＬＭ統計のサマリを提供する表である。
【図２２】ＥＬＭ統計のサマリを提供する表である。
【図２３】ＥＬＭ統計のサマリを提供する表である。
【図２４】ＥＬＭ統計のサマリを提供する表である。
【図２５】ＥＬＭ統計のサマリを提供する表である。
【図２６】ＥＬＭ統計のサマリを提供する表である。
【図２７】ＥＬＭ統計のサマリを提供する表である。
【図２８】本発明の一実施によるＥＤａＣサービスに含まれる各種コネクタを示す概略図である。
【図２９Ａ】デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する本発明による方法を示すフローチャートである。
【図２９Ｂ】デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する本発明による方法を示すフローチャートである。
【図３０】デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する本発明による方法を示すフローチャートである。
【図３１】アプリケーションシステムストレージリソースのマルチレベルマッピングを提供する本発明のさらなる態様によるレベル、グループ、およびインフラストラクチャ要素が列に列挙される表である。
【図３２】アプリケーションシステムストレージリソースをマルチレベルマッピングする、説明されるシステムおよび技法の実施に適した例示的なコンピュータインフラストラクチャアーキテクチャの図である。
【図３３】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３４】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３５】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３６】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３７】図３２のアーキテクチャに記される要素のサブセットから形成されるグループを示す図である。
【図３８】代替の例示的なコンピュータインフラストラクチャアーキテクチャの図である。
【図３９Ａ】図３８のアーキテクチャに記される要素のサブセットから形成されるサブグループを示す図である。
【図３９Ｂ】図３８のアーキテクチャに記される要素のサブセットから形成されるサブグループを示す図である。
【図４０】アプリケーションシステムストレージリソースをマルチレベルマッピングする本発明のさらなる態様による全般的な技法のフローチャートである。
【発明を実施するための形態】
【００２５】
発明の詳細な説明
以下の記載には、本発明の理解を提供するために多くの特定の詳細が記される。しかし、本発明をこういった特定の詳細なしで実施可能なことを当業者は理解するであろう。場合によっては、周知の方法、手続き、構成要素、プロトコル、アルゴリズム、および回路については、本発明を曖昧にしないように詳細に記載されていない。以下の考察には、アプリケーションパラメータを適宜調整することによってストレージリソースに対する負荷への対処に関連する態様ならびにＣＰＵ、ネットワーク、およびＳＡＮリソースの平衡化に関連する態様を含む本発明の各種態様が記載される。
【００２６】
上述したように、本発明は、２００７年７月５日に出願された「Managing Application System Load（アプリケーションシステムの負荷管理）」という名称の米国特許出願第１１／７７３８２５号（代理人整理：ＡＫＲ−１１０−ＵＳ）の一部継続出願（ＣＩＰ）であるため、以下の詳細な説明ではまず、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）の発明を記載し（以下のセクションＡ〜Ｄ）、それから、本発明の説明に続く（以下のセクションＥおよびＦ）。当業者は、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）内で記載されているデジタル処理、計算、またはストレージ環境が、本発明を実施することができる処理環境の例のうちのいくつかにすぎないことを理解するとともに、本発明を米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）で記載される環境以外で実施可能なことも理解するであろう。
【００２７】
この詳細な説明は以下のセクションで編成される。
Ａ．本発明を実施することができるデジタル処理環境
Ｂ．アプリケーションシステム負荷の管理
Ｃ．アプリケーションシステム負荷の管理−実施のさらなる詳細／例
Ｃ１．システムアーキテクチャ
Ｃ２．外部発見サブシステム
Ｃ３．発見エンジン
Ｄ．アプリケーションシステム負荷の管理−一般的な方法
Ｅ．アプリケーションシステムストレージリソースのマルチレベルマッピング
Ｆ．マルチレベルマッピングの実施形態
Ｇ．結び
【００２８】
Ａ．本発明を実施することができるデジタル処理環境
本発明の特定の例および実施形態を記載する前に、以下は、本発明を実施し、実行することができる基盤をなすデジタル処理構造および環境の、図１、図２Ａ、および図２Ｂと併せて読まれるべき考察である。
【００２９】
本発明は、コンピュータサーバクラスシステムで一般に見られるアプリケーションでのより効率的なアプリケーション実行を可能にする方法、システム、装置、およびコンピュータプログラム製品を提供することが当業者には理解されるであろう。これらのアプリケーションは、データベースアプリケーション、ウェブサーバアプリケーション、および電子メールサーバアプリケーションを含む。これらのアプリケーションは、一般に、大きなグループのコンピュータユーザに対して媒体を同時にサポートするために使用される。これらのアプリケーションは、複数のユーザによる一貫し組織されたアクセスおよび共有を共有データセットに提供する。アプリケーションは、デジタル計算システムの複数または単一の共有セットでホストすることができる。各アプリケーションで実行されるタスクセットは、デジタル計算システムで生成されるパターンおよび負荷を指示し、パターンおよび負荷は構成可能なアプリケーションパラメータセットを通して管理することができる。
【００３０】
したがって、本発明は、別個のソフトウェアアプリケーション、システムソフトウェアを含むコンピュータシステムの部分、またはデジタル計算システムの部分を形成するコンピュータの専用コンピュータハードウェアとして実施することができる。本発明は、別個のスタンドアロンのソフトウェアベースまたはハードウェアベースのシステムとして実施してもよい。実施態様は、キーボードおよび／またはマウス等のユーザインタフェース要素、メモリ、ストレージ、および他の従来のユーザインタフェース構成要素を含み得る。このような種類の従来の構成要素は、当業者に周知であるため、本明細書においてさらに詳細に記載する必要はなく、以下の概観には、本発明をデジタルコンピュータシステム内のこのような構成要素と併せてどのように実施できるかを示す。
【００３１】
特に、本発明をデジタルコンピュータシステム性能のプロファイリングおよび解析ならびにアプリケーション調整に利用できることを当業者は理解するであろう。本明細書において記載する技法は、デジタルコンピュータシステムの部分として実施することができ、性能データが定期的に収集され、適応的に解析される。データは、さらに、現在のシステムを変更することの影響を見積もるために使用できる解析モデルへの入力として使用することができる。この場合、デジタルコンピュータシステムで実行されているアプリケーションを再構成して、性能を向上させることができる。
【００３２】
以下の詳細な説明は、こういった技法による方法、構造、システム、コンピュータソフトウェア製品の例を示す。記載される方法およびシステムが、独立構成もしくはネットワークを介するMicrosoft Windows（登録商標）、Linux、またはUnix（登録商標）等の従来のオペレーティングシステムに従って動作する（または従来のオペレーティングシステムをエミュレートする）パーソナルコンピュータ（ＰＣ）または等価の装置等の従来のコンピュータ装置を使用してソフトウェア、ハードウェア、またはソフトウェアとハードウェアとの組み合わせで実施できることが当業者には理解されるであろう。したがって、本明細書において記載する各種処理態様および手段は、適宜構成されたデジタル処理装置または装置のネットワークのソフトウェア要素および／またはハードウェア要素で実施することができる。処理は逐次または並列に実行してよく、専用ハードウェアまたは再構成可能ハードウェアを使用して実施してもよい。
【００３３】
一例として、本明細書に添付される図１は、データベースおよびメールサーバ等のサーバクラスアプリケーションを実行できる例示的なコンピュータシステム１０を示す。図１を参照すると、一実施形態において、コンピュータシステム１０は、プロセッサモジュール１１と、キーボード１２Ａおよび／またはマウス１２Ｂ（またはデジタイジングタブレットまたは他のアナログ要素、包括的にオペレータ入力要素１２として識別される）等のオペレータ入力構成要素およびビデオ表示装置１３等のオペレータ出力要素を含むオペレータインタフェース要素とを含む。例示的なコンピュータシステム１０は、従来の内蔵プログラムコンピュータアーキテクチャのものであることができる。プロセッサモジュール１１は、例えば、１つまたは複数のプロセッサ、メモリ、ならびにディスクおよび／またはテープ記憶要素（別個に示さず）等の大容量記憶装置を含むことができ、提供されるデジタルデータと併せて処理動作および記憶動作を実行する。オペレータ入力要素１２は、オペレータが、処理する情報を入力できるようにするために提供することができる。ビデオ表示装置１３は、オペレータが処理のために入力することができるデータ、オペレータが処理制御のために入力できる情報、ならびに処理中に生成される情報を含め、プロセッサモジュール１１によって生成された情報をオペレータに対して画面１４上に表示するために提供することができる。プロセッサモジュール１１は、いわゆる「グラフィカルユーザインタフェース」（「ＧＵＩ」）を使用してビデオ表示装置１３によって表示される情報を生成することができ、ビデオ表示装置１３には、各種アプリケーションプログラムについての情報が各種「ウィンドウ」を使用して表示される。
【００３４】
用語「メモリ」、「ストレージ」、および「ディスクストレージ装置」は、コンピュータハードディスク、コンピュータフロッピー（登録商標）ディスク、コンピュータ可読フラッシュドライブ、コンピュータ可読ＲＡＭ要素、コンピュータ可読ＲＯＭ要素、またはデジタル情報を符号化する任意の他の既知の手段等の任意のコンピュータ可読媒体を包含することができる。用語「アプリケーションプログラム」、「アプリケーション」、「プログラム」、「コンピュータプログラム製品」、または「コンピュータソフトウェア製品」は、コンピュータ可読媒体が固定式、リムーバブル式、永久的、または消去可能であるか等にかかわりなく、コンピュータ可読媒体に符号化され、かつ／または記憶されたコンピュータ可読プログラム命令からなる任意のコンピュータプログラム製品を包含することができる。上述したように、例えば、図２Ｂの概略ブロック図のブロック１２２において、アプリケーションおよびデータは、当該技術分野において周知の実施および技法に従ってディスク、ＲＡＭ、ＲＯＭ、他のリムーバブルストレージ、固定ストレージに、これらが内部にあるか外部にあるかにかかわりなく、記憶することができ、ダウンロードまたはアップロードすることができる。本書において述べるように、本発明は、コンピュータ可読媒体に記憶されたソフトウェアまたはコンピュータプログラム製品の形態をとってもよく、アップロードされてもよく、ダウンロードされてもよく、ＦＰＧＡ、ＲＯＭ、もしくは他の電子構造に固定されてもよいコンピュータプログラムコードの形態であってもよく、または方法もしくはこのような方法を実行するシステムの形態をとってもよい。コンピュータシステム１０は、入力情報をオペレータから受け取るためのキーボード１２Ａおよびマウス１２Ｂ、ならびに出力情報をオペレータに表示するためのビデオ表示装置１３等の特定の構成要素を備えて示されるが、コンピュータシステム１０が、図１に示される構成要素に加えて、または図１に示される構成要素に代えて、様々な構成要素を含んでよいことが理解されるであろう。
【００３５】
さらに、プロセッサモジュール１１は、包括的に参照番号１４で識別される１つまたは複数のネットワークポートを含むことができ、ネットワークポートは、コンピュータシステム１０をコンピュータネットワークに接続する通信リンクに接続される。ネットワークポートは、コンピュータシステム１０が、ネットワーク内の他のコンピュータシステムおよび他の装置に対して情報を送信するとともに、情報を受信できるようにする。例えば、クライアント−サーバパラダイムに従って組織された典型的なネットワークでは、ネットワーク内の特定のコンピュータシステムがサーバとして示され、他のクライアントコンピュータシステムによって処理されるデータおよびプログラム（包括的に「情報」）を記憶し、それにより、クライアントコンピュータシステムが情報を都合良く共有できるようにする。特定のサーバによって保持されている情報にアクセスする必要があるクライアントコンピュータシステムは、サーバがネットワークを介して情報をダウンロードできるようにする。データを処理した後、クライアントコンピュータシステムは、処理されたデータをサーバに返して、そこに記憶することもできる。コンピュータシステム（上述したサーバおよびクライアントを含む）に加えて、ネットワークは、例えば、プリンタおよびファクシミリ装置、デジタルオーディオまたはデジタルビデオの記憶・配信装置等を含み得、これらをネットワークに接続された各種コンピュータシステムで共有することができる。ネットワーク内のコンピュータシステムを相互接続する通信リンクは、従来のように、ワイヤ、光ファイバ、または信号をコンピュータシステム間で搬送する他の媒体を含めた任意の都合の良い情報搬送媒体を含み得る。コンピュータシステムは、通信リンク上で転送されるメッセージによってネットワーク上で情報を転送し、各メッセージは、情報およびメッセージを受信する装置を識別する識別子を含む。
【００３６】
図面に示されるコンピュータシステム１０に加えて、本発明による方法、装置、またはソフトウェア製品は、従来のＰＣ１０２、ラップトップ１０４、ハンドヘルドもしくはモバイルコンピュータ１０６、またはインターネットもしくは他のネットワーク１０８を介するものを含め、スタンドアロンか、ネットワーク化されているか、可搬であるか、それとも固定されるかにかかわりなく、サーバ１１０およびストレージ１１２を含み得る、図２Ａおよび図２Ｂに例として示されるもの（例えば、ネットワークシステム１００）等の任意の広範囲の従来の計算装置およびシステムで動作することができる。
【００３７】
従来のコンピュータソフトウェアおよびハードウェアでの実施と並んで、本発明により構成されたソフトウェアアプリケーションは、例えば、図１、図２Ａ、および図２Ｂに示されるようなＰＣ１０２内で動作することもでき、この場合、プログラム命令は、ＲＯＭ、ＣＤ−ＲＯＭ１１６（図２Ｂ）、磁気ディスク、または他のストレージ１２０から読み出して、ＲＡＭ１１４にロードしてＣＰＵ１１８によって実行することができる。データは、従来のキーボード、スキャナ、マウス、デジタイジングタブレット、または他の要素１０３を含めた任意の既知の装置または手段を介してシステムに入力することができる。図２Ｂに示すように、図示のストレージ１２０はリムーバブルストレージを含む。図２Ｂにさらに示すように、アプリケーションおよびデータ１２２を、固定ストレージ、リムーバブルストレージ、またはＲＯＭのうちのいくつかまたはすべてに配置してもよく、またはダウンロードしてもよい。
【００３８】
本明細書において記載する本発明の方法態様が、ＡＳＩＣ製造業者にとって既知のＡＳＩＣ構築技法を使用して、本明細書において記載される処理を実行するように特に構築されたフィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）等のハードウェア要素で実行可能なことを当業者は理解するであろう。本発明の実行に使用できる従来のＡＳＩＣ、等価の集積回路、または他の従来のハードウェア要素の実際の半導体素子は、本発明の部分ではなく、本明細書において詳細に考察しない。
【００３９】
さらに詳細に本明細書において記載する本発明の教示を使用して、さらに詳細に後述する、例えば図３以下に示される本発明の方法を実行するように、ＡＳＩＣまたは他の従来の集積回路または半導体素子を実装可能なことも当業者は理解するであろう。
【００４０】
本発明の方法態様が、ワークステーションまたはパーソナルコンピュータ（ＰＣ）のオペレーティングシステムおよび本発明により構成されたコンピュータプログラム製品の下で動作する、ワークステーションおよびＰＣ等の市販のデジタル処理システム内で実行可能なことも当業者は理解するであろう。用語「コンピュータプログラム製品」は、コンピュータ可読媒体に符号化されたコンピュータ可読プログラム命令の任意のセットを包含することができる。コンピュータ可読媒体は、ワークステーション、ＰＣ、または他のデジタル処理装置もしくはシステムからローカルであれ、またはリモートであれ、コンピュータハードディスク、コンピュータフロッピー（登録商標）ディスク、コンピュータ可読フラッシュドライブ、コンピュータ可読ＲＡＭ要素、コンピュータ可読ＲＯＭ要素、またはデジタル情報の符号化、記憶、または提供を行う任意の他の既知の手段を含むが、これらに制限されない任意の形態のコンピュータ可読要素を包括することができる。各種形態のコンピュータ可読要素および媒体が、コンピューティング分野において周知であり、その選択は実施者に任せられる。
【００４１】
Ｂ．アプリケーションシステム負荷の管理
次に、米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）に記載される本発明の各種態様によるアプリケーションシステム負荷を管理するシステムおよび技法の例および実施形態について記載する。本願は、米国特許出願第１１／７７３８２５号の一部継続出願（ＣＩＰ）である。
【００４２】
アプリケーションは、一般に、ストレージエリアネットワーク（ＳＡＮ）を通して共通ネットワークおよびストレージシステムを共有するサーバでホストされる。アプリケーションの要求とＣＰＵ、ネットワーク、およびＳＡＮの能力との不均衡は、中央リソースを共有しているアプリケーションの全体性能の低下に繋がる。しかし、個々のアプリケーションは、サブシステム内の任意の単一の要素、特にＳＡＮに大きすぎる負荷を課す場合、性能の影響を受け得る。さらに、ＣＰＵ、ネットワーク、およびストレージアレイは、多くの場合、共有リソースとして利用される。独立したサーバで実行されている複数のアプリケーションは、サブシステム要素がアプリケーション間で共有されている場合、互いの性能に影響を及ぼし得る。
【００４３】
多くのアプリケーションは内部パラメータを有し、内部パラメータはユーザまたはシステム管理者によって設定することができ、アプリケーションの性能およびスループットに劇的な影響を及ぼし得る。ユーザは、通常、アプリケーションが実行のために初期化されているとき、計算システム構成で維持可能な帯域幅または存在する並列性を考慮しない。システム負荷の設定には、デフォルト値セットが一般に使用される。これらのデフォルト値は、例えば、スレッド数、個々のアプリケーションの優先度、記憶領域、およびログバッファ構成を含み得る。これらの値は、実行時中に調整することも可能である。これらの値はユーザ、アプリケーションプログラマ、またはシステム管理者によって調整可能であるが、基盤をなす計算システムリソースの特性によりよく合うように、アプリケーション負荷を調整するための指針は提供されない。
【００４４】
任意のアプリケーションの性能は、アプリケーションが単一の装置に対して大きすぎるトラフィックを生成する場合、または複数のアプリケーションが、システムが集合負荷にサービス提供できないような多くの要求でシステムを溢れさせる場合に低下し得る。システム内の任意の要素に過負荷がかかる際に、あるアプリケーションが別のアプリケーションに対して生み出す干渉は、性能の大きなばらつきを生じさせ得る。より予測可能なアプリケーション性能を提供しようという試みは、多くの場合、サブシステム内の特定の要素のキャパシティのオーバープロビジョニングに繋がる。
【００４５】
これらの課題を解決するか、又はこれらの課題を少なくとも最小にしようとして、システム管理者は、各アプリケーションが固定の優先度を有することを要求することができる。優先度の設定は、システムリソースに対するアプリケーションの要求を「抑制する」ために使用される。不都合なことに、固定の優先度の割り当てはリソースを無駄にする恐れがあるとともに、アプリケーションスタベーションに繋がる恐れもある。抑制に対する代替は、各アプリケーションが受けているサービス品質（「ＱｏＳ」）を管理することができる。ストレージリソースの割り振りは、様々な基準、例えばストレージアクセスの帯域幅に基づくことができる。米国特許出願公開第２００５／００８９０５４号には、ＱｏＳに基づいたリソースの割り振りを提供する装置が記載されており、参照によりその全体が本明細書に援用される。
【００４６】
上記懸案事項に対する従来の解決策は、通常、それ自体の性能制約及び懸案事項を提示してきた。したがって、１つまたは複数のアプリケーションによって生成されるシステム負荷をより効率的かつ柔軟に管理する改良された方法、装置、ソフトウェア、およびシステムを提供することが望ましい。
【００４７】
ディスクまたは帯域幅を個々のサーバまたはアプリケーションに割り振るのではなく、本明細書に記載するシステムおよび技法は、アプリケーションによって提供される内部調整機能（internal tuning facility）を利用し、提供されたストレージサブシステムの特性に基づいて調整されたパラメータセットに到達する。さらに、本発明は、ネットワーク化されたデジタル計算システム等の完全デジタルコンピュータシステムのリソースも考慮する。記載のシステムおよび技法は、Microsoft Windows（登録商標）、Linux、およびUnix（登録商標）等の市販のオペレーティングシステムで開発された既存の性能監視システムおよび技法を利用する。実行時パラメータセットを通してアプリケーションを適応的に調整できるようにする記載のシステムおよび技法は、既存のインタフェースを利用して、データベースおよび電子メールアプリケーションを調整する。本発明はさらに、利用可能なシステムリソースの入念なプロビジョニングを通してＱｏＳ保証を提供して、複数のアプリケーションを並行に管理することができる。
【００４８】
システム性能を決定する、アプリケーションパラメータの構成に使用されている従来の方法は、いくつかの著しい欠点を有する。すなわち、（１）今日まで使用されてきた調整方法は、試行錯誤反復調整に基づいておらず、（２）ユーザは、調整の選択をガイドするために基盤をなすＣＰＵ、ネットワーク、およびストレージサブシステムについて殆ど情報を有さず、（３）共有デジタル計算システムを利用する複数のアプリケーションまたは複数のサーバを並行に管理することが殆ど考慮されておらず、かつ（４）現在、デジタル計算システムの特性を個々のアプリケーションパラメータの変更に変換する一般に認められた方法がない。
【００４９】
アプリケーションによっては、ストレージアクセス動作の待ち時間の影響を受けやすいものもあれば、そうでないものもある。データベースおよびメールサーバアプリケーションは、非逐次モードでデータにアクセスすることが多く、時によっては、別のコマンドを発行する前に、１つのアクセスまたは一連のアクセスの完了を待たなければならないことがあるため、ストレージアクセス動作に関連する待ち時間の影響を特に受けやすい。
【００５０】
データベースシステム、メールサーバ等の多くの待ち時間の影響を受けやすいアプリケーションは、自己調整を実行する能力を有する。例えば、Oracle１０ｇは、最近のクエリの挙動に基づいて将来のクエリの性能を加速化できるクエリオプティマイザを提供する。Oracle１０ｇは、データベース性能に影響し得る２５０を超える調整可能パラメータも有する。これらのパラメータは、メモリリソース、例えばキャッシュおよびバッファの利用に影響するとともに、並行アクセス可能量、例えばスレッディングを定義することができる。
【００５１】
記載のシステムおよび技法は、基盤をなすＣＰＵサブシステム、ネットワークサブシステム、およびストレージサブシステムについての情報を利用することによるこれらの内部パラメータの適正な設定を目標とする。本明細書において記載するように、ＣＰＵサブシステム情報は、使用中のプロセッサの種別および個数ならびに関連するメモリ階層の両方を含み、ネットワークサブシステム情報は、使用されているネットワークスイッチの速度および構成ならびにスイッチに接続されたアダプタの速度を含み、ストレージサブシステム情報は、物理ディスク装置の特性、ＲＡＩＤグループへのこれらの装置のグループ化、論理アドレスからＲＡＩＤグループへのマッピング、およびこのシステムを通る個々のパスのスループットを含む。本発明のさらなる一態様は、システムの実行時特性を捕捉することによってストレージサブシステム情報を得る能力を提供する。この情報は、カスタマイズされたエクササイザを実行するか、またはシステムの通常の実行を観察することによって得ることができる。
【００５２】
アプリケーションパラメータの調整は、アプリケーションの初期化時または動的に行うことができる。基盤をなすサブシステム性能の異なる特性を捕捉するために使用される方法は、静的、すなわち予め決まった方法であり、ストレージシステムと共に出荷してもよく、またはプロファイリングを通して動的に取得されてもよい。現在記載している本発明は、この情報を静的に指定する方法およびプロファイリングを通してこの情報を取得する方法の両方を含む。本発明のさらなる態様によれば、この情報は、フィードバックとしてアプリケーションに提供されて、システムパラメータを自動的に、またはシステム／アプリケーション管理者によって調整できるようにする。
【００５３】
上記考察では、デジタル計算リソースを最も良く利用するために、性能の影響を受けやすいアプリケーションのパラメータを適宜調整する必要性について述べた。このようなパラメータを調整する装置およびシステムの一実施形態を図３に示す。
【００５４】
図３に示すように、アプリケーションサーバ２９０は、サーバ２６０に直接接続されるものもあれば、スイッチファブリック２５０を使用してストレージエリアネットワーク２７０を介してサーバに接続されるものもある、様々な記憶要素にアクセスする。これは、サーバおよびストレージシステムの可能な編成の１つにすぎない。本発明は特定の編成を必要としない。
【００５５】
したがって、本発明の現在記載している態様には、サーバおよびストレージシステムの両方に通信できる要素が導入される。この要素は、本明細書では、ストレージシステムアウェアアプリケーション調整システム（ＳＳＡＡＴＳ）２８０と呼ばれる。この要素ならびに同様の構造および機能についても記載され、以下では情報リソース管理（ＩＲＭ）システムと呼ばれる。後述するように、本発明のさらなる態様は、ＳＳＡＡＴＳ要素の機能のうちのいくつかまたはすべてを実行する他の名称の要素を提供する。
【００５６】
図３に示すＳＳＡＡＴＳの実施形態は３つの下位要素を含む。すなわち、
（１）ストレージネットワークプロファイリングシステム２１０、
（２）解析モデル２２０、および
（３）アプリケーションパラメータ決定サブシステム２３０
である。
【００５７】
ＳＳＡＡＴＳ要素２８０は、スタンドアロンサブシステムとして実施してもよく、またはサーバサブシステム２９０もしくはネットワークファブリックサブシステム２４０の部分として統合されてもよい。
【００５８】
プロファイリングサブシステム要素１００は、ストレージネットワーク内の並列度を決定する能力を有し、上述したように基盤をなすストレージシステム２６０および２７０の帯域幅値および待ち時間値を推定することができる。プロファイリングサブシステム要素２１０は、存在するネットワークファブリック要素２５０の帯域幅値および待ち時間値を決定することもできる。
【００５９】
プロファイリングサブシステム要素２１０は、ストレージシステム製造業者から常に入手可能であるとは限らない性能関連情報を取得する。ストレージシステムが設置される際、利用可能なストレージは多くの異なる編成で構成され得る。そのため、いくらかの性能関連情報が製造業者によって提供される場合であっても、必要な情報の大半は、ストレージシステムが設置され構成された後でのみ的を得たものである。
【００６０】
必要な性能関連情報としては、例えば、
（１）ＣＰＵ、ネットワーク、およびＳＡＮ内で利用可能な並列度、
（２）各種装置の速度、
（３）アプリケーションサーバ、ネットワーク、および個々のストレージ装置の間のパスの帯域幅、および
（４）サーバから見たストレージ装置の構成
が含まれるが、これらに制限されない。
【００６１】
必要な性能関連情報を取得するために、一連の入／出力コマンドをストレージサブシステムに発行することができる。特定のコマンドシーケンスの応答時間およびスループットに基づいて、必要な性能関連情報を取得することができる。次に、この情報は解析モデル要素２２０に供給される。
【００６２】
解析モデル要素２２０は、プロファイル情報をプロファイリングストレージネットワーク２１０から取得する。プロファイリングデータは解析性能モデル２２０によって使用され、解析性能モデル２２０は、アプリケーションサーバ２９０のＣＰＵサブシステム、ネットワークサブシステム２５０、ならびにストレージサブシステム２６０および２７０が維持できる適正負荷を確立するために使用される。解析モデル要素２２０の出力は、パラメータ値２３０を決定する要素に供給され、次に、この要素は、これらの値をアプリケーションサーバ２９０に通信し、アプリケーションサーバ２９０は、次に、アプリケーションの内部パラメータを設定する。
【００６３】
オプションの一実施形態では、プロファイリングシステムがプロファイリングネットワーク２１０を通してストレージシステムの性能を引き続きプロファイリングし、動的プロファイルを解析性能モデル２２０に供給し、新しいアプリケーションパラメータセットをパラメータ決定システム２３０からアプリケーションサーバ２９０に通信することができる。このオプションの実施形態の主要特徴としては、（ａ）プロファイリングシステムが、パラメータ変更を通して得られる恩益を低減する恐れのある著しいオーバーヘッドをデジタル計算システムに導入し得ないこと、かつ（ｂ）システムが連続して性能遷移に適応しないようにパラメータ変更の頻度を抑制するために、適切な制御が提供されていることをシステムが保証しなければならないことが含まれる。
【００６４】
オプションの一実施形態では、プロファイリングシステム２１０が、利用可能なシステム構成の使用をさらに改良するために、ネットワークインタフェースを通してストレージリソース２６０および２７０と直接通信することができ、これは、本明細書では「発見（Discovery）」と呼ばれる。
【００６５】
本明細書において記載する解析モデル２２０は、標準キューイング理論技法を利用し、ストレージサブシステムが維持できる負荷量を確立する。特に、解析モデル２２０は、既知のキューイング理論式、アルゴリズム、および技法を適用して、サポート可能なストレージ負荷を決定することができる。このような式、アルゴリズム、および技法は、例として、Kleinrock, L., Queueing Systems: Volume I - Theory (Wiley Interscience, New York, 1975）、Kleinrock, L., Queueing Systems: Volume II - Computer Applications (Wiley Interscience, New York, 1976）に記載されており、これらを両方とも、その全体が記載されているかのように参照により本明細書に援用される。次に、パラメータ決定要素は、これらの負荷値をターゲットアプリケーションの具体的なパラメータ値に変換する。本発明のさらなる態様によれば、ＳＳＡＡＴＳ２８０は、１つのアプリケーションソフトウェアにつき１つずつ、複数のパラメータ決定要素２３０を含む。
【００６６】
アプリケーションパラメータユニット２３０の決定は、いくつかのアプリケーション固有パラメータを考慮する。１つの特定のパラメータセットは、例えば、Oracle １０ｇの内部に提供されるコストベース最適化（ＣＢＯ）パラメータを含む。こういったパラメータは、Oracle内でインデックス付与および走査がどのように実行されるか、ならびにアプリケーションによって想定される並列度を制御することができる。例えば、マルチブロックリードカウントは、アクセスサイズを調整するために設定することができ、または並列テーブル走査を実行するために並列自動調整を設定することができる。
【００６７】
多くの状況において、ストレージ管理者が待ち時間の影響の受けやすさによってアプリケーションを区別することが有益であり得る。現在記載しているメカニズムは、個々のアプリケーションのシステムリソース要求の抑制を目標とするが、ネットワークおよびストレージは一般に異なるアプリケーションによって共有されるため、同じシステムを使用して複数のアプリケーションを管理することができる。
【００６８】
ネットワークおよびストレージが異なるアプリケーションによって共有される場合、解析モデル２２０は、競合するアプリケーション作業負荷の影響を捕捉するように調整することができる。２つの典型的な作業負荷は、オンライントランザクション処理作業負荷と、これと競合するストレージバックアップ作業負荷である。バックアップアプリケーションがクリティカルな動作を実行している間、オンライアントランザクション処理アプリケーショの実行が優先されるべきである。
【００６９】
複数のアプリケーションが同じＩＯストレージリソース２６０おび２７０のセットを共有している場合、アプリケーションパラメータユニット２３０の決定は、共有に役立つように複数のパラメータ値セットを調整する必要がある。
【００７０】
複数のアプリケーションが同じＩＯストレージリソース２６０おび２７０のセットを共有し、システム管理者であるユーザが各アプリケーションのスループットに優先度を付けたい場合、アプリケーションパラメータユニット２３０の決定は、一方のアプリケーションのＩＯ要求を他方のアプリケーションのＩＯ要求よりも優先するようにパラメータ値をさらに調整することができる。
【００７１】
これより、本発明によるシステムのさらなる一実施形態について記載し、上述した要素および他についてさらに詳細に記載する。
【００７２】
図４は、中央演算処理装置（ＣＰＵ）３０１、３０２、３０３と、ネットワーク要素３１０と、ストレージアレイネットワーク３２０とを含む例示的な計算システム３００の要素を示す図である。図示の構成は、現在利用可能な多くのサーバクラス計算システムの典型的な構成である。本明細書において記載するように、本発明の態様は、システム３００の解析モデルを構築することによってシステム３００の性能を向上させるシステムおよび技法を対象とする。解析モデルは、まず、システム構成情報および異なる要素の実行時性能統計を取得することによって構築される。解析モデルには、システム３００で実行されている特定のアプリケーションセットについての知識が提供される。解析モデルの出力は、性能数ならびに計算システム３００で実行されているアプリケーションに関連するアプリケーションパラメータの調整の仕方についての推奨を含む。次に、解析モデルの出力を使用して、アプリケーションの将来の性能を向上させることができる。
【００７３】
図５は、アプリケーション３５０が計算システム３００でどのように実行されるかを構成するために使用されるプログラムコード３６０とアプリケーションパラメータセット３７０とを含むアプリケーション３５０の図を示す。
【００７４】
図６は、ＣＰＵ１ ３０１で実行されるアプリケーション３５０の図を示し、アプリケーション３５０にはアプリケーションパラメータセット３７０が供給され、システムに負荷を生じさせる。
【００７５】
図７は、計算システム３００および情報リソースマネージャ４００を示す図を示す。情報リソースマネージャ４００は、解析モデル４１０を含み、ＣＰＵ統計４４０、ネットワーク統計４５０、およびＳＡＮ統計４６０を含むいくつかの計算システム性能統計４３０と、計算システム構成データ４７０と、計算システム３７０で実行されているアプリケーションセットのアプリケーションパラメータセット３７０とのデータベース４２０を保持する。
【００７６】
図８は、ＣＰＵ統計４４０と、ネットワーク統計４５０と、ＳＡＮ統計４６０と、構成データ４７０と、計算システム３００で実行されているアプリケーションのアプリケーションパラメータ３７０とのデータベース４２０を示す。
【００７７】
図９は、性能統計を計算システム３００からどのように取得できるかの一例を示す図を示す。ＣＰＵ統計４４０は、iostat ５１０およびperfmon ５２０等の標準ソフトウェアユーティリティを使用してＣＰＵ１ ３０１から取得することができる。ネットワーク統計４５０は、大半のネットワークスイッチ装置に提供されているＳＮＭＰインタフェース５３０を使用して取得することができる。ＳＡＮ統計４６０は、多くのＳＡＮシステム１２０に提供されているＳＭＩＳ５４０を介して取得することができる。図９に示すインタフェースは、異なる要素から性能統計を取得する１つの特定のインタフェースセットを示すが、情報リソース管理ユニット４００が、利用可能な計算システムの追加のインタフェースにアクセスすることを除外しない。
【００７８】
図１０は、構成データ４１０が計算システム１００の各要素からどのように得られるかを示す。異なる計算システム要素１００の各ベンダーは、一般に、この情報を報告するインタフェースを提供する。
【００７９】
図１１は、情報リソース管理ユニット４００の部分である解析モデル４１０の図を示す。解析モデル４１０の目的は、性能インジケータを生成すること、および計算システム３００で実行されているアプリケーションの性能を向上させるために、更新アプリケーションパラメータセット３７２（図１３および図１４）を生成することの両方である。
【００８０】
図１２は、構成データ４７０ならびにＣＰＵ統計４３０、ネットワーク統計４３０、およびＳＡＮ統計４４０がどのように使用されて、解析モデル４１０が構築されるかを示す。解析モデルは、ＣＰＵ４１１、ネットワーク４１２、およびＳＡＮ４１３のモデルを含み、追加の計算システム要素を含んでもよい。
【００８１】
図１３は、解析モデル４１０がどのように更新アプリケーションパラメータセット３７２を生成するかを示す。この新しいパラメータセットは計算システムに供給されて、システムで実行されているアプリケーション３５０が計算システムの要素をどのように使用するかを再構成する。目標は、システムの性能を向上させることである。
【００８２】
図１４は、更新アプリケーションパラメータ３７２がどのように使用されて、アプリケーション３５０によって使用されるアプリケーションパラメータセット３７０が更新されるかを示す。図１４には、アプリケーションがＣＰＵ１ ３０１で実行されて示されるが、アプリケーションは、システム３０２、３０３の任意のＣＰＵまたはシステムネットワーク３１０もしくはＳＡＮ３２０内の任意の他の要素で実行されてもよい。
【００８３】
図１５は、情報リソース管理ユニットが、いくつかのＣＰＵ統計４４２、ネットワーク統計４５２、およびＳＡＮ統計４６２を保持できることを示す。これらの記録は、通常、時間順に並べられ、システムのより長期の挙動を提供する。この記録セットは、計算システムで実行されている複数のアプリケーションについて生成される性能統計を表すこともできる。このより豊富な統計セットに再び解析モデル４１０を適用し、解析モデル４１０は次に、計算システムで実行されているアプリケーションデータ３７２を更新する。この技法を図１６にさらに示す。
【００８４】
Ｃ．アプリケーションシステム負荷の管理−実施のさらなる詳細／例
以下の考察は、本発明の各種態様による実施態様の１つまたは複数の例に関するさらなる詳細を提供する。以下があくまでも例として提示され、本発明を、後述する特定の構造を必ずしも必要とせずに、異なる構成および実施形態で実行し実施することが可能なことが当業者には理解されるであろう。以下の考察は、以下のサブセクションに編成される。
Ｃ１．システムアーキテクチャ
Ｃ２．外部発見サブシステム
Ｃ３．発見エンジン
【００８５】
Ｃ１．システムアーキテクチャ
現在記載しているアーキテクチャは、包括的に、本明細書ではイベントレベルモニタ（ＥＬＭ）と呼ばれる。ＥＬＭアーキテクチャは、以下のＥＬＭ製品特徴をサポートする。すなわち、（１）データセンタ可視性、（２）ホットスポット検出、および（３）解析である。
【００８６】
これらの機能をサポートするために、ＥＬＭアーキテクチャは以下の特徴を提供する。すなわち、構成／トポロジ発見、統計収集、統計計算、アプリケーション固有ストレージトポロジおよび統計、解析、ならびにアラーム・イベント生成である。
【００８７】
図１７は、ＥＬＭアーキテクチャ６００の例示的な実施形態の主要構成要素のブロック図を示す。図示の各構成要素についてこれより順に記載する。
【００８８】
プラットフォーム６１０：プラットフォーム６１０は、ＩＲＭ４００が実行される土台および基本環境を提供する。
【００８９】
Linux ６２０：Linux ＯＳ６２０は低レベル機能をプラットフォームに提供する。
【００９０】
構成要素タスクフレームワーク（ＣＴＦ）６３０：構成要素タスクフレームワーク６３０は、共通のプリミティブおよびサービスの有用なセット、メッセージング、イベント、メモリ管理、ロギングおよびトレース、デバッグシェル、タイマ、同期、データ操作を提供し、ハッシュテーブル、リスト等を含む。
【００９１】
ＭｙＳＱＬ６４０：システムデータのリポジトリであるデータストア（ＤＳ）６５０が、ＭｙＳＱＬ６４０の一番上に構築される中央データベースに記憶される。
【００９２】
データストア（ＤＳ）６５０：ＤＳ６５０は、発見された要素、その関係またはトポロジ、およびその統計を含む。
【００９３】
情報リソースマネージャ（ＩＲＭ）４００：情報リソースマネージャ（ＩＲＭ）４００は、上述したように、データセンタについての情報、トポロジ、および統計すべての収集を担う。
【００９４】
外部発見・収集（ＥＤａＣ）７００：外部発見・収集（ＥＤａＣ）７００は、さらに後述するように、データセンタの、サーバおよびストレージアレイ等の要素への接続をシステムに提供する構成要素である。特定の各種要素、例えばCLARiiONストレージアレイに対する通信の仕方を知っており、その特定の要素のトポロジを発見し、またはその特定の要素から統計を収集する。したがって、特定のアレイまたはサーバに対して別個のモジュールまたはコレクタを有する。各種の要素に対して、ＸＭＬで定義され、あらゆるコレクタが準拠する標準ＡＰＩがある。
【００９５】
発見エンジン６６０：発見エンジン６６０は、データセンタ要素、特にサーバおよびストレージアレイのトポロジの発見を行う。ユーザは、発見したいサーバまたはストレージアレイを入力する。発見エンジン６６０は、データストア６５０にアクセスして、ユーザが入力したサーバ、ネットワーク、およびストレージアレイのリストを得る。それぞれ１つごとに、発見エンジン６６０は、ＥＤａＣ７００にトポロジの取得を要求する。ＥＤａＣ７００は要素に問い合わせ、発見されたすべての情報、例えば、ストレージアレイのディスクを返す。次に、発見エンジン６６０は、この情報をデータストア６５０内に配置し、これらの関係を接続する。サーバの初回発見時、発見エンジン６６０は、統計マネージャ６７０にもそのサーバからの統計の収集を開始するように通知する。さらに、発見エンジン６６０は、デジタル計算システム３００の要素を定期的に起こし、「再発見」もする。これにより、任意のトポロジ変更を発見することができる。
【００９６】
統計マネージャ６７０：統計マネージャ６７０は、コンピュータシステム要素、特にサーバからの統計の収集を行う。現在の製品では、統計はサーバからのみ収集されるが、これらの統計を使用して、他のデータセンタ要素についての統計も同様に導出される。統計マネージャ６７０には、発見エンジン６６０により、新しいサーバが発見されたときに通知される。統計マネージャ６７０は、次に、そのサーバを収集リストに追加する。統計マネージャ６７０は、定期的に起きて、収集リストに目を通す。収集リスト内の各サーバにつき、統計マネージャ６７０は、統計を集めるようにＥＤａＣ７００に要求する。ＥＤａＣ７００は、サーバの統計を収集すると、これらの統計を統計マネージャ６７０に送信する。統計マネージャ６７０は、これらの統計を処理し、データストア６５０に挿入する。統計によっては、データストア６５０に変更なしで追加されるものもあれば、平均化等の何等かの単純な処理の後に追加されるものもあれば、完全に新しい統計を導出するより高度なアルゴリズムで処理されるものもある。
【００９７】
統計モニタ６８０：新しい統計が常に収集され計算される。これは、ユーザが時間を遡ってシステムで何か発生していたかを調べることができることを意味する。すべての統計はデータストア（ＤＳ）６５０に記憶される。記憶される統計としては、計算された統計ならびに収集された統計が含まれる。これにより、常に統計を表示に即座に利用できるようになる。
【００９８】
統計モニタ６８０は、統計マネージャ６７０によって統計がデータストア６５０に入力されると、その配置された統計を監視し管理する。統計モニタ６８０内には、定期的に起きて、データストア６５０内の統計に対して異なるタスクを実行するいくつかのデーモンがある。こういったタスクとしては、サマリ統計の作成、例えば、収集された統計の時間統計への集計、ある統計の移動平均の計算、ある統計の閾値との比較およびイベントの生成、そして最終的に、閾値を超えた場合にはアラームの生成が含まれる。
【００９９】
計算され解析される異なる種類の統計がある。これらのうちのいくつかは以下を含む。
【０１００】
計算された統計：計算された統計は、収集された統計または他の計算された統計に対して計算を実行することによって作成される。計算は、加算のように単純であってもよく、または非線形曲線当てはめの実行のように複雑であってもよい。計算された統計は、収集された統計と同じ方法および同じ形式でＤＳ６５０に記憶される。
【０１０１】
計算されたストレージ統計：すべてのストレージ統計がサーバＬＵＮから収集される統計から導出されることに留意することが重要である。次に、発見されたサーバおよびストレージアレイのトポロジを使用して、他のストレージオブジェクト：サーバボリューム、ストレージアレイＬＵＮ、ＡＳＧ、およびサブグループの統計が導出される。
【０１０２】
収集および計算の頻度：統計収集は、システムが統計的に安定しているときの使用率を計算することができるように行われる。統計的な安定は、統計が変化しないことを意味するのではなく、むしろ、システムが同じ種類の作業または作業セットを期間にわたって行っていることを意味する。使用率の計算は一連のサンプルを必要とする。したがって、統計的に安定した期間での使用率を計算するには、一連のサンプルを短期間に収集しなければならない。しかし、著しい数のサーバの統計を高頻度で連続して収集することは、システムに大きすぎる負担をかける。上記要件／制約は、図１８に示すように、バーストで統計を収集することによって満たされる。
【０１０３】
パラメータは以下の意味を有する。
メジャー期間（Major Period） サンプルバースト間の時間。範囲は５〜６０分である。
マイナー期間（Minor Period） バーストの各サンプル間の時間。範囲は１〜１０秒である。
バースト マイナー期間レートで各メジャー期間でとられるサンプル数。範囲は１〜５０サンプルである。
これらのパラメータはサーバ毎に可変である。したがって、１つのサーバについての統計をメジャー期間３０分、マイナー期間１０秒、およびバーストサイズ１０で収集し、別のサーバについての統計を、メジャー期間１５分、マイナー期間１秒、およびバーストサイズ２５で収集することが可能である。使用率の計算に使用されない統計は、メジャー期間毎に１度の頻度で収集される。バーストで収集される統計は、使用率の計算にすぐに使用される。使用率計算の結果はＤＳに保存され、未処理のデータは破棄される。したがって、統計は、サーバ毎のメジャー期間毎に１度、ＤＳに挿入される。
【０１０４】
サーバ統計計算頻度：サーバについてのすべての統計：ＣＰＵ、メモリ、ＬＵＮ、およびボリュームが同時に収集され計算される。これは、サーバのメジャーサンプルレートで行われる。
【０１０５】
アプリケーションストレージグループ／ストレージグループ統計計算頻度：特定の問題は、アプリケーションストレージグループ（ＡＳＧ）およびストレージグループ（ＳＧ）の計算期間である。ＡＳＧおよびＳＧの統計は、異なるサーバから送信されたものであり得るサーバＬＵＮ統計から計算される。大概、これらのサーバＬＵＮ統計は異なる時間に、かつ潜在的に異なるレートで収集される。これは、ＡＳＧ／ＳＧ統計をメジャーサンプル期間で計算できないことを意味する。各サーバＬＵＮからの複数のサンプルを使用することができるように、ＡＳＧ／ＳＧ統計をそれよりも低いあるレートで計算しなければならない。
【０１０６】
現在状態更新頻度：多くのオブジェクトは現在状態、履歴状態、および傾向状態を保持する。現在状態は比較的頻繁に計算されるが、メジャーサンプルレートよりも低い。
【０１０７】
履歴状態および傾向更新頻度：履歴状態および傾向はより長期のインジケータであり、より低い頻度で計算される。
【０１０８】
サマリ計算頻度：サマリは、データベース内の空間を節約するメカニズムである。サマリは、古いデータほど価値が低く、新しいデータと同じ粒度で見る必要がないという理論の下で動作する。
【０１０９】
発見頻度：発見は、環境についての比較的静的なデータを収集する。そのため、あまり頻繁に実行する必要はない。しかし、これは、任意の変更を素早く明らかしたいという要望とバランスをとる必要がある。
【０１１０】
収集および計算の頻度のサマリ：図１９に示す表は、収集および計算の頻度のサマリを提供する。すべての収集パラメータおよび計算パラメータが、変更可能なようにパラメータ化されるべきであることに留意する。
【０１１１】
統計サマリ：図２０〜図２７に示す表は、本明細書において記載するＥＬＭシステムの統計のサマリを提供する。
図２０−収集されたサーバ統計 サーバ統計はサーバから収集される。これらは、メジャーサンプル期間レートで頻繁に収集される動的統計である。
図２１−収集されたサーバ属性 サーバ属性はサーバから収集される。これらは、発見レートであまり頻繁には収集されない比較的静的なパラメータである。
図２２−記憶されたサーバ属性 サーバ属性はサーバから収集される。これらは、発見レートであまり頻繁には収集されない比較的静的なパラメータである。
図２３−記憶されたサーバ現在統計 サーバ統計は収集されたサーバ統計から生成され、データベースに記憶される。これらのうちの１つは、サーバ毎のメジャーサンプル期間毎に生成されるべきである。
図２４−サーバサマリ統計 サマリサーバ統計は、より短い期間からより長い期間までのサーバ統計の集計である。例えば、メジャー期間統計を日毎または週毎の統計にまとめることができる。
図２５−記憶されたストレージ統計 様々なストレージオブジェクトの統計の記憶に使用される共通のストレージ統計がある。ストレージ統計が生成される頻度は、統計が生成されているオブジェクトに依存する。サーバボリューム−メジャーサンプル期間毎に１回、サーバＬＵＮ−メジャーサンプル期間毎に１回、アプリケーションストレージグループ−アプリケーションストレージグループ／ストレージグループ計算期間毎に１回、サブグループ−アプリケーションストレージグループ／ストレージグループ計算期間毎に１回。
図２６−記憶されたストレージ統計 あらゆる統計があらゆるオブジェクトに対して有効であるわけではない。図２６の表は、どの統計がどのオブジェクトに対して有効であるかを示す。
図２７−記憶されたサマリストレージ統計 サマリストレージ統計は、より短い期間からより長い期間までのストレージ統計のまとめである。例えば、メジャー期間統計を日毎または週毎の統計にまとめることができる。
【０１１２】
解析：解析は、データストアに記憶されているデータ、主にトポロジおよび統計を使用して、システムに何が起こっているのかについてユーザに通知するか、またはシステムについての推奨を行う。解析は、データストア内のデータに対してルールエンジンによって実行されるルールセットとして、またはアプリケーションパラメータの調整に使用される解析モデルとして実施することができる。実行可能ないくつかの異なる種類の解析がある。これらは以下を含む。
アプリケーションポイントインタイム解析 ある時点でアプリケーションの性能はどうなっているか、およびリソースの使用を解析する。
アプリケーションデルタ時間解析 ２つの時点間でアプリケーションの性能の何が変更されたか、およびリソースの使用を解析する。
アプリケーションストレージグループ解析 ある時点でのアプリケーションとストレージとの間のパスを解析して、そのパスがホットスポットであるか否か、およびそのパスに対してアプリケーション競合があるか否かを判断する。
ストレージプロビジョニング推奨 アプリケーションに対してより多くの物理ストレージをどこでプロビジョニングすべきかについて推奨を行う。
アプリケーション推奨 アプリケーションパラメータに対する変更を行う
【０１１３】
上記に加えて、既知のＡＰＩ実施に従って構築された各種ＡＰＩ（アプリケーションプログラミングインタフェース）を様々なポイントおよびレイヤに提供して、システム設計者、管理者、または他が望むようにインタフェースを供給してよいことを当業者は理解するであろう。
【０１１４】
Ｃ２．外部発見・収集サービス
これより、機器外部のリソースについてのすべての構成および統計へのアクセスを提供する上述した外部発見・収集（ＥＤａＣ）サービスについてさらに詳細に記載する。ＥＤａＣサービスは、任意の外部リソースに要求をディスパッチすることを担う。図２８は、ＥＤａＣサービス７００の例示的な一実施形態に含まれる様々なコネクタを示す図である。各コネクタ７３０は、特定のリソースへのアクセスを提供する。
【０１１５】
担当リストは以下を含む。すなわち、（１）統計要求イベントをリッスンし、適切なコネクタに転送し、（２）発見要求イベントをリッスンし、適切なコネクタに転送し、かつ（３）発見要求を何等かのスケジュールですべてのコネクタに対して実行し、発見イベントを生成する。本発明のさらなる態様によれば、項目（３）の機能は情報リソースマネージャ（ＩＲＭ）に移してもよい。
【０１１６】
発見処理には２つの部分がある。すなわち、（１）装置を「見つけ」、（２）その装置の最も静的な構成を把握する。発見アルゴリズムは、何千もの装置を処理するのに十分な堅牢性を有さなければならない。完全な発見処理は数時間かかり得る。構成に関しては、以下のデータが、オブジェクトモデルにおいて発見および収集を達成するために必要である。
サーバ：ＩＰアドレス、ログイン／パスワード、ＳＳＨ／telnet、Solarisの場合、ポーリング間隔、および永続的接続
ストレージアレイ：管理サーバ、ログイン／パスワード、ＣＬＩへのパス、ポーリング間隔、永続的接続
アプリケーション：ＩＰアドレス、ログイン／パスワード、サービス名、ポート、ポーリング間隔、永続的接続
【０１１７】
様々な周知のデータアクセスツールを本発明のこの態様と併せて利用することができ、構成可能アクセス方法を含む複数のアクセス方法を利用することができる。これらとしては、サーバへのtelnetアクセス、ＯＤＢＣ（DataDirect Technologies (Bedford, MA)市販のＯＤＢＣライブラリを利用できる）を介するデータベースデータアクセス、ＳＳＨ技法、および他の従来の技法が含まれ得る。
【０１１８】
シーケンスイベントブローカ７１０が、ＥＤａＣコア７２０へのインタフェースを提供し、記載したコネクタ７３０を含む。
【０１１９】
Oracleデータベースコネクタ７３０ａは、データベース構成およびデータベース統計の収集を担う。Oracleデータベースコネクタ７３０ａはＯＤＢＣライブラリ７４０を使用する。
【０１２０】
Windows（登録商標）サーバコネクタ７３０ｂおよびSolarisサーバコネクタ７３０ｃは、メモリの利用ならびにボリューム／ＬＵＮのマッピングおよび統計等のＯＳレベルデータの収集を担う。ボリューム／ＬＵＮマッピングを計算するために、設置されているボリュームマネージャならびにマルチパス製品の両方を把握する必要があり得る。それぞれの詳細、すなわちストライピング特性またはパス情報を把握する必要がない場合であっても、どのＬＵＮがボリュームに関連するかを計算するためだけに、各製品から情報が必要になる可能性が高い。ＥＬＭをターゲットとする特定の製品を選ぶことができる。Solarisサーバコネクタ７３０ｃはＳＳＨを使用する。SolarisのボリュームマネージャはVeritasおよびネイティブのものである。Windows（登録商標）サーバコネクタ７３０ｂはＷＭＩライブラリ７５０を使用する。Windows（登録商標）のボリュームマネージャはネイティブのものであり、これはVeritasである。
【０１２１】
ストレージコネクタ７３０ｄ、７３０ｅ、および７３０ｆは、ＬＵＮの利用、性能、およびＲＡＩＤセット／ディスクへのマッピングの収集およびボックス７６０で包括的に表される他のデータの収集を担う。アレイ性能統計はＥＬＭには必要ない。
【０１２２】
CLARiiONストレージコネクタ７３０ｄに関しては、ＮａｖｉＣＬＩがCLARiiONへのリッチＣＬＩインタフェースである。これは、データをｘｍｌで返すことができる。性能統計はCLARiiONに対してイネーブルし、ＣＬＩを通して検索することができる。ＣＬＩをＡＳＣにインストールすることも可能である。ＣＬＩに顧客サーバのうちの１つからＳＳＨ７８０を通してアクセスする可能性が高い。いくらかのデータは、telnetによってCLARiiONに直接提供されもする。
【０１２３】
Dothillストレージコネクタ７３０ｅに関しては、DothillはホストベースＣＬＩも有する。データをｘｍｌで返すことができる。Dothillは性能統計へアクセスを提供しない。アクセス問題は、CLARiiON ＣＬＩの場合と同じである。いくらかのデータは、telnetによってDothillに直接提供されもする。
【０１２４】
適したＨＰストレージコネクタ７３０ｆも提供される。
【０１２５】
ボックス７３０ｇで表されるように、現在記載しているシステムは、以下の要素、すなわち、ＣＩＭ／ＷＢＥＭ／ＳＭＩ−Ｓアクセス、ＳＮＭＰアクセス、ファブリックコネクタ、外部ＳＲＭコネクタ、リモートプロクシ／エージェント、構成を変更するイベントを含めるように変更し拡張することができる。さらに、１つのWindows（登録商標）エージェントが、「Windows（登録商標）ワールド」へのゲートウェイとして機能することができ、ＷＭＩおよびＯＤＢＣとよりシームレスに統合する。こういった将来のアクセスツールはボックス７７０によって表される。
【０１２６】
Ｃ３．発見エンジン
上で触れた発見エンジンについて、さらに詳細にこれより記載する。発見エンジン（ＤＥ）は、情報リソースマネージャ（ＩＲＭ）に常駐する。発見エンジンは、ユーザによってデータストア（ＤＳ）に入れられたサーバおよびストレージアレイの定期的なトポロジ発見の開始を担う。これは、上述した外部発見・収集（ＥＤａＣ）モジュールと併せてこれを行う。
【０１２７】
ＤＥは、メッセージキューからのメッセージを処理する主ループの周囲に構築される。これらのメッセージとしては以下が含まれる。
発見タイマイベント このイベントは完全な発見処理を開始する。
発見完了イベント これらは、ＤＥによってＥＤａＣに元々送信され、今では、ＥＤａＣがサーバまたはストレージアレイのすべての発見イベントを生成した後、ＥＤａＣによって返されているストレージアレイトポロジ発見イベントおよびサーバトポロジ発見イベントである。これらのイベントは、トポロジ発見がサーバまたはストレージアレイに対して完了したことを示す。
オブジェクト発見イベント ＥＤａＣは、サーバまたはストレージアレイのトポロジを決定する処理において発見した各オブジェクトの発見イベントを生成する。例えば、ＥＤａＣは、サーバのトポロジの決定を要求された場合、サーバ、サーバＦＣポート、サーバボリューム、およびサーバＬＵＮの各発見イベントを生成する。
【０１２８】
主ループは単純に、メッセージキュー上で処理する次のメッセージを待つことができる。
【０１２９】
発見タイマイベント：ＤＥは構成要素タスクフレームワーク（ＣＴＦ）を使用して、発見間隔タイマを設定する。タイマが切れた場合、ＣＴＦはメッセージを生成し、ＤＥのメッセージキューに送出する。これは、ＤＥに、発見処理を開始する時間であることを通知する。
【０１３０】
発見タイマイベントは、ＤＥにＮ個の初期発見サーバトポロジイベントまたは発見ストレージアレイトポロジイベントを並列に開始させる。Ｎは任意の数である。トポロジを発見するサーバまたはストレージアレイがなくなるまで、常にＮ個の未処理の発見トポロジイベントがあることになる。
【０１３１】
サーバまたはストレージアレイ発見完了イベント：サーバまたはサーバアレイ発見完了イベントは、実際には、ＥＤａＣがそのオブジェクトに対する発見を完了した後、ＤＥに返されたサーバトポロジ発見イベントまたはストレージアレイトポロジ発見イベントである。
【０１３２】
発見完了イベント処理：この処理ステップは以下の通りである。
１．ＤＥがＤＳに、オブジェクトトポロジ発見中に発見されなかった既存の任意の記録、例えばサーバＬＵＮか否かを見つけるように問い合わせる。ＤＳは、発見タイムスタンプが現在の記録のものと同じではないすべての記録にクエリを作成することによってこれを行う。
２．タイムスタンプが一致しない各記録について、失われたイベント、例えば、サーバボリュームロストイベントが生成され送信される。
３．発見すべきサーバまたはストレージアレイがまだある場合、次のものがＤＳから検索され、それに対するトポロジ発見イベントがＥＤａＣに送信される。
４．発見すべきサーバまたはストレージアレイがもうない場合、発見は完了し、発見間隔タイマが再開される。
【０１３３】
オブジェクト発見イベント：トポロジ発見イベントを受信すると、ＥＤａＣは、トポロジについてサーバまたはストレージアレイに問い合わせる。トポロジは記録セットからなる。ＥＤａＣは、現在のイベントに対する発見イベントセットを生成する。発見イベントが特定の順序で行われることが重要である。
【０１３４】
サーバトポロジ発見イベント：サーバ発見イベント、サーバＦＣポート発見イベント、サーバボリューム発見イベント、サーバＬＵＮ発見イベント。
【０１３５】
ストレージアレイトポロジ発見イベント：ストレージアレイ発見イベント、ストレージアレイＦＣポート発見イベント、ストレージアレイディスク発見イベント、ストレージアレイＬＵＮ発見イベント。
【０１３６】
各発見イベントには、その発見のタイムスタンプが含まれる。タイムスタンプはＥＤａＣによって挿入される。特定のストレージアレイまたはサーバについての各発見イベントは同じタイムスタンプ値を有する。
【０１３７】
発見処理：この処理ステップは以下の通りである。
１．ＤＥがデータストアに問い合わせて、記録がすでに存在するか否かを判断する。
２．記録がすでに存在する場合、記録関係が検証され、発見タイムスタンプが更新される。
３．記録がＤＳ内に存在しない場合、他の記録に対する関係と共に記録が作成される。したがって、このステップでの処理は特に、発見中の記録に対するものである。
４．「記録発見」イベントが作成され、ログに記憶される。
【０１３８】
Ｄ．アプリケーションシステム負荷の管理−一般的な方法
図２９Ａは、デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する一般的な方法８００のフローチャートである。この方法は、有利なことに、少なくとも１つの中央演算処理装置（ＣＰＵ）と、ＣＰＵがデジタル計算システムの他の要素と通信可能にするように動作可能なネットワークと、少なくとも１つのストレージ装置を含み、少なくとも１つのＣＰＵと通信するように動作可能なストレージエリアネットワーク（ＳＡＮ）とを含むネットワーク化されたデジタル計算システムで実施することができる。計算システムは、少なくとも１つのアプリケーションプログラムを実行するように動作可能であり、少なくとも１つのアプリケーションプログラムは、アプリケーションプログラムの実行を制御するように調整可能なアプリケーションパラメータを有する。
【０１３９】
本発明による例示的な方法をボックス８０１〜８０３に示す。
【０１４０】
ボックス８０１：デジタル計算システムの要素と通信するように動作可能な情報リソースマネージャ（ＩＲＭ）を利用して、計算システムの動作および計算システム内で利用可能なリソースに関する性能情報を取得し、少なくとも１つのＣＰＵ、ネットワーク、およびＳＡＮと通信して、そこから性能情報および構成情報を取得する。本書の他のどこかに記したように、性能情報および構成情報は、デジタル計算システム内の任意のＣＰＵ、ネットワーク、またはストレージ装置からのものであってよい。情報は、Ｉ／Ｏまたは他のコマンドをデジタル計算システムの少なくとも１つの要素に発行することによって取得することができる。ＩＲＭは、デジタル計算システム内の離散モジュールであってもよく、または計算システムサブシステムもしくはＳＡＮ内のストレージネットワークファブリックサブシステム内のモジュールとして実施されてもよい。
【０１４１】
ボックス８０２：性能情報および構成情報を利用して、解析モデル出力を生成し、解析モデル出力は性能統計および更新アプリケーションパラメータのうちの任意のものを含む。本書の他のどこかに記したように、本発明は、キューイング理論を利用して、ストレージシステムまたはサブシステムがサポートできる負荷の程度を決定することができる。
【０１４２】
ボックス８０３：解析モデル出力を利用して、更新アプリケーションパラメータ値を決定し、更新アプリケーションパラメータ値を、デジタル計算システムで実行されている少なくとも１つのアプリケーションに送信し、アプリケーションは更新アプリケーションパラメータ値を使用してアプリケーションパラメータを設定し、それにより、更新実行時パラメータを使用して、デジタル計算システムで実行されている複数のアプリケーションの実行を最適化する。本書の他のどこかに記したように、この方法は負荷値、例えば、キューイング理論を使用して決定された負荷値を利用して、所与のアプリケーションのパラメータ値を決定することができる。この方法は、更新アプリケーションパラメータ値を決定する際に、いくつかのアプリケーション固有パラメータ、例えば、コストベース最適化（ＣＢＯ）パラメータを考慮することを含むこともできる。
【０１４３】
図２９Ｂは、図２９Ａの方法８００を繰り返して、または他の様式でどのように続けて実行することができるかを示し、動作中にストレージシステムの性能を引き続きプロファイリングし、それにより、一連の時間ベースのサンプルを収集すること（８０４）、時間ベースのサンプルに応答して更新プロファイルを生成すること（８０５）、および更新プロファイルに応答して、所与のアプリケーションが実行される際に、更新アプリケーションパラメータセットを送信すること（８０６）によって含む。本書の他の部分に記したように、この方法は、システムが連続して性能状態の性能遷移に適応しないように、アプリケーションパラメータ更新の頻度を抑制制御する、選択された程度を提供することを含むことができる。この方法は、発見インタフェースを介してデジタル計算システムの個々の要素と直接通信することを含むこともできる（図２９Ｂと図２９Ａとの例示的な対応性が各図の点「Ａ」と「Ｂ」を介して示される）。
【０１４４】
図３０は、本書の他の部分の考察により、本発明による方法８１０を、複数のアプリケーションがネットワーク、ストレージ、または他のリソースを共有している環境内でどのようにさらに実施できるかを示し、競合するアプリケーション作業負荷の影響を決定し、それを考慮に入れるように解析モデルを調整すること（８１１）、改良されたリソース共有に役立つように複数のパラメータ値セットを調整すること（８１２）、および必要に応じて、あるアプリケーション、そのＩ／Ｏ要求、または他の側面を別のアプリケーション、そのＩ／Ｏ要求、または他の側面よりも優先するように、パラメータ値を調整することによって含む。
【０１４５】
Ｅ．アプリケーションシステムストレージリソースのマルチレベルマッピング
米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）において考察されたものと同様の１つまたは複数のデジタルストレージ環境について上述したが、次に、本発明の態様、実施形態、および例についてのさらに詳細な説明に進む。本願は、米国特許出願第１１／７７３８２５号の一部継続出願（ＣＩＰ）である。米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）において記載されているデジタル処理、計算、またはストレージ環境が、本発明を実施することができる処理環境の例のうちのいくつかにすぎないことを当業者は理解するとともに、本発明を上述した、かつ米国特許出願第１１／７７３８２５号（ＡＫＲ−１１０−ＵＳ）において記載される環境以外の環境で実施してもよいことも理解するであろう。
【０１４６】
特に、本発明の態様は、アプリケーションにシステムリソースを効率的にマッピングするように動作可能な方法、システム、装置、およびコンピュータプログラムコード（ソフトウェア）製品、ならびに係る方法およびシステムを利用する改良されたストレージプラットフォームおよびアーキテクチャを提供する。このマッピングの基礎は、アプリケーションリソースグループ（ＡＲＧ）の定義であり、ＡＲＧは、アプリケーションに関連するサーバ、バスアダプタ、ボリューム、論理ユニット番号（ＬＵＮ）、ネットワークスイッチ、ディスクコントローラ、およびディスクについての完全な情報を提供する。
【０１４７】
本発明の現在記載している態様について、ストレージエリアネットワーク（ＳＡＮ）インフラストラクチャアーキテクチャに関して記載する。しかし、記載されるシステムおよび技法の態様を他の計算環境で実施してもよいことが理解されるであろう。
【０１４８】
ストレージエリアネットワーク（ＳＡＮ）は、ディスクドライブアレイ等のリモートコンピュータストレージ装置を、オペレーティングシステムにとって装置がローカルに取り付けられているように見えるようにホストサーバに取り付けられるようにするアーキテクチャである。
【０１４９】
図３１は、いくつかの異なるレベルでのＳＡＮインフラストラクチャの例示的なマッピングを示す表１０００である。表の１列目１００１には以下の定義レベルが列挙される。
１００１ａ−サーバレベル
１００１ｂ−バスアダプタレベル
１００１ｃ−ネットワークスイッチレベル
１００１ｄ−ディスクコントローラレベル
１００１ｅ−ディスクレベル
【０１５０】
表の２列目１００２には、各定義レベルに対応する以下の定義グループが列挙される。
１００２ａ−サーバレベルに対応するアプリケーションサーバグループ（ＡＳｅｒＧ）
１００２ｂ−バスアダプタレベルに対応するアプリケーションアダプタグループ（ＡＡＧ）
１００２ｃ−ネットワークスイッチレベルに対応するアプリケーションスイッチグループ（ＡＳｗＧ）
１００２ｄ−ディスクコントローラレベルに対応するアプリケーションコントローラグループ（ＡＣＧ）
１００２ｅ−ディスクレベルに対応するアプリケーションストレージグループ（ＡＳＧ）
【０１５１】
表の列１００３に示すように、各レベル１００１ａ−ｅおよびグループ１００２ａ−ｅは、例示的なインフラストラクチャアーキテクチャの各要素の１つまたは複数のサブセットに対応する。
１００３ａ−アプリケーション（ＡＰＰ）
１００３ｂ−サーバ（ＳＥＲＶ）
１００３ｃ−バスアダプタ（ＢＡ）
１００３ｄ−ボリューム（ＶＯＬ）
１００３ｅ−論理ユニット番号（ＬＵＮ）
１００３ｆ−スイッチ（ＳＷ）
１００３ｇ−コントローラ（ＣＴＬＲ）
１００３ｈ−ディスクアレイ（ＤＩＳＫ）
【０１５２】
一般的に言えば、各グループ１００２ａ−ｅはその名称が付けられた要素と、アプリケーション１００３ａまでのすべての「上流」要素とを含む。したがって、例えば、アプリケーションスイッチグループ（ＡＳｗＧ）は、スイッチ（ＳＷ）と、スイッチの上流にある要素、すなわち、論理ユニット番号（ＬＵＮ）、ボリューム（ＶＯＬ）、バスアダプタ（ＢＡ）、サーバ（ＳＥＲＶ）、およびアプリケーション（ＡＰＰ）とを含む。後述する各グループの特定のインフラストラクチャ要素の選択を図３２〜図３７に示す。
【０１５３】
さらに、本発明の現在記載している態様は、サブグループ１００２ｆの定義をさらに提供する。表１０００では、例示的なサブグループ１００２が、アプリケーションストレージグループ（ＡＳＧ）内の個々のＬＵＮについてのより詳細な情報を提供するものとして定義され、ＬＵＮと、ＳＡＮスイッチ１００３ｆ、コントローラ１００３ｇ、およびディスクアレイ１００３ｈを含む「下流」要素とを含む。後述するサブグループの特定のインフラストラクチャ要素の選択を図３８、図３９Ａ、および図３９Ｂに示す。
【０１５４】
このアプリケーション−ストレージシステムのマッピングのより完全な知識に基づいて、アプリケーションに関連するシステムリソースをより制約の小さいシステムリソースにリマッピングまたは再構成して、システム内の性能ボトルネックを除去することができる。これらの特徴および要素のそれぞれについてさらに詳細に後述する。
【０１５５】
本発明は、ストレージシステム内に記憶されているデータにアクセスする際に、アプリケーションの性能に影響を及ぼし得る他のリソース（すなわち、サーバ、ネットワークスイッチ、ディスクコントローラ、ディスク）を識別するために、データパスを発見する能力を利用する。本発明は、複数のアプリケーションがストレージシステム内の要素を共有しているときをユーザが明確に識別できるようにする。
【０１５６】
本発明は、エージェントレスの方法の組み合わせを利用して、ＡＲＧトポロジを発見する。これらの方法は、既存のＡＰＩおよびオペレーティングシステムユーティリティを利用して、サーバ、スイッチ、アダプタ、およびディスクインタフェースにおいてトポロジマッピング情報を捕捉することを含む。
【０１５７】
これとは対照的に、初期の一技法は、トポロジを発見できるようにアプリケーションに接続することに依存するエージェントベースの手法を使用する。この技法は、著しいオーバーヘッドをシステムにもたらし、潜在的に、実行中のアプリケーションの挙動に影響を及ぼし得る。
【０１５８】
本発明はこれらの問題を実質的に回避する。本発明は、アプリケーションとストレージシステムとのストレージシステムマッピングおよびデータパスの両方の完全な知識を利用することによってアプリケーションの信頼性またはセキュリティを向上させるように容易に拡張することも可能である。
【０１５９】
ストレージシステム性能の管理に使用される従来の方法は、アプリケーションまたはストレージシステムのいずれかのみに焦点を合わせ、これらの２つの関係を考慮しない。システムの制限されたビューを利用することに伴ういくつかの問題としては、
（１）問題が往々にして誤診断されることがあるとともに、アプリケーションボトルネック、例えばサーバメモリ使用率、またはストレージシステムボトルネック、例えば、ディスクコントローラ接続のいずれかまたは両方に起因し得ること、
（２）共有されるアプリケーションサーバ、ネットワークスイッチ、またはストレージサブシステムを利用する複数のアプリケーションまたは複数のサーバを同時に管理することが殆ど考慮されていないこと、および
（３）ストレージ、ネットワーク、およびサーバの仮想化技法が、アプリケーションとシステムリソースとの間にさらなるレベルの抽象を追加し得、性能の帰属をさらに難しくすること
が挙げられる。
【０１６０】
本発明は、すべてのシステムリソースおよびパスを個々のアプリケーションに結び付けるモデルを定義する。本発明はストレージ装置（すなわち、個々のディスクスピンドル）の観点から元の個々のアプリケーションへのマッピングを定義する。本発明の主要要素は、ストレージシステム内の任意の競合ポイントに関連するアプリケーションセットを容易に識別可能なことである。
【０１６１】
本発明は、アプリケーションとサポートしているストレージシステムとの動的に変更するマッピングを捕捉することにより、ストレージサブシステム情報を取得する能力を含む。この情報は、ストレージシステムおよびアプリケーションを定期的にプロービングして、マッピングへのあらゆる変更を追跡することによって取得することができる。
【０１６２】
Ｆ．マルチレベルマッピングの実施形態
以下の考察には、本発明の開示の理解を提供し、本発明の開示を可能にする多くの特定の詳細を記す。本発明をこれらの特定の詳細なしで実施してもよいことを当業者は理解するであろう。場合によっては、周知の方法、手続き、構成要素、プロトコル、アルゴリズム、および回路については、本発明を曖昧にしないように詳細に記載されていない。
【０１６３】
上記考察には、ストレージリソースをこれらのリソースを利用するアプリケーションにマッピングする必要性について記載した。以下の考察には、添付の図面と併せて、システムリソースをアプリケーションに効率的にマッピングするように動作可能な本発明の実施態様について記載する。
【０１６４】
これより図３２を参照すると、図３２には、以下の要素を含むコンピュータシステムインフラストラクチャ１０１０の一例が示される。すなわち、
２つのアプリケーションサーバ１０１１および１０１２、
３つのアプリケーション１１００、１１１０、および１１２０、
２つのバスアダプタ１２００および１２１０、
４つのストレージボリューム１３００、１３１０、１３２０、および１３３０、
５つのサーバＬＵＮ１３０１、１３１１、１３２１、１３２２、および１３３１、
１つのネットワークスイッチ１４００、
３つのディスクコントローラ１５００、１５１０、および１５２０、ならびに
３つのディスクグループ１５０１、１５１１、および１５２１
である。
【０１６５】
図示のシステムの基盤をなすハードウェア要素（例えば、基盤をなすサーバ、バスアダプタ、ストレージボリューム、サーバＬＵＮ、ネットワークスイッチ、ディスクコントローラ、およびディスクグループ）ならびにアプリケーションは、一般に従来の性質のものであってよく、市販の製品を使用して当業者によって実施することができる。
【０１６６】
図３２が例示的なものであり、本記載のために提供されることに留意されたい。例えば、上述したように、実際のＳＡＮには、何百もの、さらには何千ものＬＵＮがあり得る。特定のネットワークを別様に構成してもよく、または特定のネットワークが異なる要素を含んでもよい。現在記載しているシステムおよび技法の態様も同様にそれらの文脈の中で適用してもよいことが理解されるであろう。
【０１６７】
例えば、図３２に示すようなデジタル計算環境またはプラットフォームで実施される本発明によれば、アプリケーションリソースグループ（ＡＲＧ）が定義される。ＡＲＧは、共通のシステムリソースセットを包含し、アプリケーションセットからシステム内で使用されるシステム要素（例えば、サーバ、ホストアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスク）への完全または略完全なマッピングとして定義される。
【０１６８】
さらに、本発明によれば、ＡＲＧは、アプリケーションサーバグループ（ＡＳｅｒＧ）、アプリケーションアダプタグループ（ＡＡＧ）、アプリケーションスイッチグループ（ＡＳｗＧ）、アプリケーションコントローラグループ（ＡＣＧ）、およびアプリケーションストレージグループ（ＡＳＧ）の定義を含む。ＡＲＧは、アプリケーションとストレージシステムとの間のパス内の任意のポイントでの完全なマッピングを提供する。
【０１６９】
ＡＲＧは、ストレージシステム内の任意の要素に対して負荷を発生させているアプリケーションセットの階層図を提供する。複数のアプリケーションが単一のストレージ要素に関して競合しており、かつ性能ボトルネックが生じている場合、ＡＲＧは、ボトルネックの原因であり得るアプリケーションセットを識別することができる。
【０１７０】
図３３は、本発明によるサーバ１０１１のアプリケーションサーバグループ（ＡＳｅｒＧ）を示す。ＡＳｅｒＧは、アプリケーション１１００および１１１０をサーバ１０１１に負荷をかけているアプリケーションとして識別する。
【０１７１】
図３４は、本発明によるバスアダプタ１２１０のアプリケーションアダプタグループ（ＡＡＧ）を示す。ＡＡＧは、アプリケーション１１２０をバスアダプタ１２１０に負荷をかけているアプリケーションとして識別する。ＡＡＧは、バスアダプタ１２１０がサーバ１０１２に接続されていることも識別する。
【０１７２】
図３５は、本発明によるネットワークスイッチ４００のアプリケーションスイッチグループ（ＡＳｗＧ）を示す。ＡＳｗＧは、アプリケーション１１００、１１１０、および１１２０をネットワークスイッチ４００に負荷をかけているアプリケーションとして識別する。ＡＳｗＧは、スイッチ１４００がＬＵＮ１３０１、１３１１、１３２１、１３２２、１３３１に接続され、ＬＵＮ１３０１、１３１１、１３２１、１３２２、１３３１は、ボリューム１３００、１３１０、１３２０、および１３３０のマッピングに使用され、ボリューム１３００、１３１０、１３２０、および１３３０はバスアダプタ１２００および１２１０に接続され、バスアダプタ１２００および１２１０はサーバ１０１１および１０１２に接続されていることも識別する。
【０１７３】
図３６は、本発明によるディスクコントローラ１５１０のアプリケーションコントローラグループ（ＡＣＧ）を示す。ＡＣＧは、アプリケーション１１２０をディスクコントローラ１５１０に負荷をかけているアプリケーションとして識別する。ＡＣＧは、コントローラ１５１０がネットワークスイッチ４００に接続され、ネットワークスイッチ４００がＬＵＮ１３２１および１３２２に接続され、ＬＵＮ１３２１および１３２２がボリューム１３２０のマッピングに使用され、ボリューム１３２０がバスアダプタ１２１０に接続され、バスアダプタ１２１０がサーバ１０１２に接続されていることも識別する。
【０１７４】
図３７は、本発明によるディスクアレイ１５０１のアプリケーションストレージグループ（ＡＳＧ）を示す。ＡＳＧは、アプリケーション１１００および１１１０をディスクアレイ１５０１に負荷をかけているアプリケーションとして識別する。ＡＳＧは、アレイ１５０１がディスクコントローラ１５００によって接続され、ディスクコントローラ１５００がネットワークスイッチ４００に接続され、ネットワークスイッチ４００がＬＵＮ１３０１および１３１１に接続され、ＬＵＮ１３０１および１３１１がボリューム１３００および１３１０のマッピングに使用され、ボリューム１３００および１３１０がバスアダプタ１２００に接続され、バスアダプタ１２００がサーバ１３００に接続されることを識別する。
【０１７５】
本発明では、任意のＡＲＧ抽象を単一のアプリケーションに関連するＬＵＮまでさらに分解するサブグループも定義される。各ＡＲＧ抽象（ＡＳｅｒＧ、ＡＳｗＧ、ＡＳｅｒＧ、ＡＣＧ、およびＡＳＧ）は、少なくとも１つの、恐らくは複数のサブグループを含むことになる。単一のサブグループは、単一のＡＳＧ抽象内でのみ提示することができる。サブグループは、単一のストレージ要素とアプリケーションとの関係の粒度をさらに改善する。
【０１７６】
図３８、図３９Ａ、図３９Ｂは、本発明によるサブグループの詳細図を提供する。サブグループは、ストレージ要素に負荷を発生させている原因であるアプリケーションに関連するＬＵＮのより詳細な図を提供する。
【０１７７】
図３８は、単一のバスアダプタ１２３０を使用する単一のアプリケーション１１３０を実行しているホストサーバ１０１３を含む代替のインフラストラクチャアーキテクチャを示す。単一のアプリケーション１１３０は複数のボリューム１３５０および１３６０にマッピングされ、これらの各ボリュームは複数のＬＵＮにマッピングされ得る。ボリューム１３５０はＬＵＮ１３５１および１３５２にマッピングされ、ボリューム１３６０はＬＵＮにマッピングされる。各ＬＵＮは異なるＲＡＩＤグループにマッピングすることができる。ＬＵＮ１３５１はディスクアレイ１５３１にマッピングされ、ＬＵＮ１３５２および１３６１はディスクアレイ１５４１にマッピングされる。
【０１７８】
図３９Ａは、ＬＵＮ１３５１、スイッチ１４１０、コントローラ１５３０、およびディスクアレイ１５３１を含む第１のサブグループＡ１６００を示す。図３９Ｂは、ＬＵＮ１３５２および１３６１、スイッチ１４１０、コントローラ１５４０、ならびにディスクアレイ１５４１を含む第２のサブグループＢを示す。
【０１７９】
サブグループは、ストレージ要素内で性能問題の原因であり得る単一のアプリケーションに関連するＬＵＮの識別を助けることができる。例えば、図３９Ａに示すように、サブグループＡ１６００を使用して、アプリケーション１１３０内の特定のどのプロセスがディスクアレイ１５３１で受けている負荷の原因であるかを識別することが可能である。
【０１８０】
アプリケーションのＡＲＧマッピングを完全に記述するために必要な情報は、いくつかの方法を通して取得することができる。この情報は、既存のオペレーティングシステムインタフェース（例えば、Windows（登録商標）の場合、ＷＭＩ）を通して、またはオペレーティングシステムユーティリティおよびボリュームマネージャ）（例えば、Solarisの場合、Solarisボリュームマネージャ）を使用して発見することができる。スイッチレベル発見は、スイッチ製造業者によって規定される簡易ネットワーク管理プロトコル（ＳＮＭＰ）ＡＰＩを使用する。ディスクアレイレベル発見は、Storage Network Industry Associationによって規定されるストレージ管理イニシアティブ仕様（ＳＭＩ−Ｓ）ＡＰＩならびにコマンドラインインタフェース（ＣＬＩ）を使用する。ローカル−物理ＬＵＮマッピングは、ネットワークによって定義され、Unix（登録商標）上のオペレーティングシステムユーティリティまたはWindows（登録商標）上のWindows（登録商標）レジストリを使用して得られるワールドワイドネーム（ＷＷＮまたはＷＷＩＤ）を使用して得られる。
【０１８１】
本発明の一実施では、ＡＲＧトポロジは、サーバまたはストレージシステムのいずれかで実行されている仮想化技術によって曖昧になり得る。システムの発見要素は、仮想化技術によって提供される利用可能なＡＰＩを利用することができる（例えば、ＶＭＷａｒｅのＥＳＸコレクタが仮想化されたホストツールと協働する）。次に、仮想化システム要素または存在する実際の物理要素のいずれかを示すＡＲＧトポロジをユーザに提示することができる。
【０１８２】
上述したオペレーティングシステムインタフェースの例（ＷＭＩ、Solarisボリュームマネージャ）、ＡＰＩの例（ＳＭＩ−Ｓ、ＣＬＩ等）、およびVMWareのＥＳＸコレクタ等の仮想化の例が、市販の製品またはサービスを指し、それらと相互動作可能なように本発明を実施可能なことを当業者は理解するであろう。
【０１８３】
図４０は、本発明の方法およびシステムの一実施２０００を示すフローチャートを提供し、以下を含む。
ボックス２００１−サーバ、ネットワーク、およびストレージサービスに問い掛けることによってトポロジを最初に発見する
ボックス２００２−仮想化が使用されている場合、存在する任意の仮想−物理マッピングを発見する
ボックス２００３−ＡＳｅｒＧ、ＡＡＧ、ＡＳｗＧ、ＡＣＧ、およびＡＳＧの各グループならびにサブグループを識別する
ボックス２００４−トポロジ内のすべてのポイントで実行統計を収集し、統計リポジトリに記憶する
ボックス２００５−トポロジの特定のグループビューに基づいて収集された実行統計を照会する
ボックス２００６−性能情報をシステムユーザに報告する
【０１８４】
Ｇ．結び
上記記載は当業者が本発明を実施できるようにする詳細を含むが、この記載は例示的な性質のものであり、その多くの変更および変形が本教示の恩恵を有する当業者には明らかであり、そういった変更および変形が本発明の主旨および範囲内にあることを認められたい。したがって、本明細書における本発明は添付の特許請求の範囲によってのみ規定され、特許請求の範囲は先行技術によって許される限り広義に解釈されることが意図される。
【特許請求の範囲】
【請求項１】
（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境において、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、改良が、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供することと、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義することとを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、改良。
【請求項２】
さらに、前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項１に記載の改良。
【請求項３】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項１に記載の改良。
【請求項４】
さらに、ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項１に記載の改良。
【請求項５】
（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境において、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、改良が、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供する手段と、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義する手段であって、各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、改良。
【請求項６】
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項５に記載の改良。
【請求項７】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項５に記載の改良。
【請求項８】
ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項５に記載の改良。
【請求項９】
コンピュータ可読媒体に記憶され、（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境において動作可能なコンピュータプログラム製品であって、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、前記コンピュータプログラム製品は、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供する、前記デジタルストレージ環境内で実行可能なコンピュータプログラムコード手段と、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義するコンピュータプログラムコード手段とを含み、、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、コンピュータプログラム製品。
【請求項１０】
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項９に記載のコンピュータプログラム製品。
【請求項１１】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項９に記載のコンピュータプログラム製品。
【請求項１２】
ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項９に記載のコンピュータプログラム製品。
【請求項１３】
アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを可能にする方法であって、（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備える前記デジタルストレージ環境内で実行可能であり、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、前記方法は、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供することと、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義することとを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、方法。
【請求項１４】
さらに、前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項１に記載の方法。
【請求項１５】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項１に記載の方法。
【請求項１６】
さらに、ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項１に記載の方法。
【請求項１７】
アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを可能にするシステムであって、（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備える前記デジタルストレージ環境において実施可能であり、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、前記システムは、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供する手段と、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義する手段とを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、システム。
【請求項１】
（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境において、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、改良が、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供することと、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義することとを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、改良。
【請求項２】
さらに、前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項１に記載の改良。
【請求項３】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項１に記載の改良。
【請求項４】
さらに、ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項１に記載の改良。
【請求項５】
（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境において、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、改良が、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供する手段と、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義する手段であって、各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、改良。
【請求項６】
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項５に記載の改良。
【請求項７】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項５に記載の改良。
【請求項８】
ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項５に記載の改良。
【請求項９】
コンピュータ可読媒体に記憶され、（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備えるデジタルストレージ環境において動作可能なコンピュータプログラム製品であって、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、前記コンピュータプログラム製品は、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供する、前記デジタルストレージ環境内で実行可能なコンピュータプログラムコード手段と、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義するコンピュータプログラムコード手段とを含み、、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、コンピュータプログラム製品。
【請求項１０】
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項９に記載のコンピュータプログラム製品。
【請求項１１】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項９に記載のコンピュータプログラム製品。
【請求項１２】
ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項９に記載のコンピュータプログラム製品。
【請求項１３】
アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを可能にする方法であって、（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備える前記デジタルストレージ環境内で実行可能であり、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、前記方法は、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供することと、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義することとを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、方法。
【請求項１４】
さらに、前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素への略完全なマッピングを提供するように動作可能である、請求項１に記載の方法。
【請求項１５】
前記ＡＲＧおよび前記サブグループは集合的に、複数のアプリケーションが単一のストレージ要素に関して競合し、ボトルネックを生み出している場合、前記ＡＲＧが、前記ボトルネックの原因であり得るアプリケーションセットを識別できるように動作可能である、請求項１に記載の方法。
【請求項１６】
さらに、ＡＳＧ抽象が、単一のサブグループを単一のＡＳＧ抽象内でのみ提示できるように構成される、請求項１に記載の方法。
【請求項１７】
アプリケーションセットからデジタルストレージ環境内で使用されるストレージ要素へのマッピングを可能にするシステムであって、（Ａ）少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイと、（Ｂ）少なくとも２つのアプリケーションとを備える前記デジタルストレージ環境において実施可能であり、前記少なくとも１つのアプリケーションサーバ、バスアダプタ、ネットワークスイッチ、ディスクコントローラ、およびディスクアレイは集合的に、前記デジタルストレージ環境内のストレージ要素であり、前記システムは、
（Ａ）アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供するように動作可能なアプリケーションリソースグループ（ＡＲＧ）を提供する手段と、
（Ｂ）単一のストレージ要素とアプリケーションとの関係の粒度を改善するように動作可能なサブグループを定義する手段とを含み、
前記ＡＲＧはＡＲＧ抽象を含み、前記ＡＲＧ抽象は、
サーバに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションサーバグループ（ＡＳｅｒＧ）、
バスアダプタに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションアダプタグループ（ＡＡＧ）、
ネットワークスイッチに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションスイッチグループ（ＡＳｗＧ）、
ディスクコントローラに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションコントローラグループ（ＡＣＧ）、および
ディスクアレイに負荷をかけているアプリケーションを識別するように動作可能なアプリケーションストレージグループ（ＡＳＧ）
のうちの少なくとも１つを含み、
各ＡＲＧ抽象は少なくとも１つのサブグループを含み、
前記ＡＲＧおよび前記サブグループは集合的に、アプリケーションセットから前記デジタルストレージ環境内で使用されるストレージ要素へのマッピングを提供し、前記デジタルストレージ環境内の任意のストレージ要素に負荷を発生させているアプリケーションセットの階層イメージを提供するように動作可能である、システム。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９Ａ】
【図２９Ｂ】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９Ａ】
【図３９Ｂ】
【図４０】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９Ａ】
【図２９Ｂ】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９Ａ】
【図３９Ｂ】
【図４０】
【公表番号】特表２０１０−５１５１２１（Ｐ２０１０−５１５１２１Ａ）
【公表日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願番号】特願２００９−５４３２１５（Ｐ２００９−５４３２１５）
【出願日】平成１９年１２月２０日（２００７．１２．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８８３３９
【国際公開番号】ＷＯ２００８／０７９９５５
【国際公開日】平成２０年７月３日（２００８．７．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（５０９００７１７１）アコリ ネットワークス，インコーポレイテッド (2)
【Ｆターム（参考）】
【公表日】平成２２年５月６日（２０１０．５．６）
【国際特許分類】
【出願日】平成１９年１２月２０日（２００７．１２．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８８３３９
【国際公開番号】ＷＯ２００８／０７９９５５
【国際公開日】平成２０年７月３日（２００８．７．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（５０９００７１７１）アコリ ネットワークス，インコーポレイテッド (2)
【Ｆターム（参考）】
[ Back to top ]