JP6165886B2 - 動的ストレージサービスレベル・モニタリングの管理システムおよび方法 - Google Patents

Description

本発明は、広くは、コンピュータアプリケーションによるストレージ利用に関し、より具体的には、動的ストレージサービスレベル・モニタリングの管理システムおよび方法に関するものである。

大規模なデータセンタでは、数十万ものストレージデバイス（別称、ボリューム）と、それらのストレージデバイスを使用する数万ものサーバが設けられている。高コストのストレージシステムを使用する目的は、より高レベルのサービス（例えば、応答時間およびスループット）を得ることである。それらのストレージデバイスのパフォーマンスを追跡するソフトウェアツールでは、ユーザは、パフォーマンスを監視する基準となる閾値を設定することが必要となり、パフォーマンスレベルが規定の閾値を満たさない場合には、警告が発せられる。

本発明の例示的な実施形態により、動的ストレージサービスレベル・モニタリングの管理システムおよび方法を提供する。動的ストレージサービスレベル・モニタリングには、例えば以下のものを含む多くの課題がある。

１．いかにして、ＳＬＯ（サービスレベル目標）パラメータを正確に決定するか。

ａ．どのボリュームを監視すべきか？

ｂ．いつ、モニタリングすべきか？ 多くのアプリケーション／サーバは、異なるＩＯ（入力／出力）パターンを持ついくつかの異なるオペレーションモードを有するので、それらは、いくつかの異なるサービスレベル・モニタリングを必要とし得る。

ｃ．監視されるべきメトリクスは何か？ そして、どのような閾値を用いるべきか？

２．ストレージデバイスを使用するアプリケーションのワークロード・プロファイルは、一般に、極めて動的である。そのようなデバイスを、静的な設定によって監視することにより、不正確な結果を得ることがある。

従来、管理ソフトウェアによって、ユーザは、モニタリングに用いるＳＬＯメトリクス、モニタリングウィンドウ（ＳＬＯを監視するための期間）、および閾値を、手動で選択することが可能である。本発明により、過去のパフォーマンスデータを分析して、ボリュームおよびストレージグループごとにＳＬＯパラメータを決定する。これらの値は、リコメンデーションとしてユーザに提示される。ユーザは、リコメンデーションを確認して、背景情報を分析し、そして、それらの推奨値を修正および／または承認することができる。

本発明の一態様は、コンピュータ可読記憶媒体に格納されたコンピュータプログラムであって、コンピュータで実行されるコンピュータプログラムに関し、該コンピュータは、ストレージコントローラと、ストレージコントローラによって制御される複数のストレージデバイスと、を備えるストレージシステムを、該ストレージシステムの複数のストレージボリュームのうちのストレージボリュームに対して別のコンピュータから送信された入力／出力（Ｉ／Ｏ）コマンドの書き込みデータを保存するために、管理するように機能する。コンピュータプログラムは、ストレージボリュームごとに、ある期間についてＩ／Ｏオペレーションのパフォーマンス情報を分析するためのコードであって、その期間についてストレージシステムから収集される複数のストレージボリュームの各々のＩ／Ｏオペレーションのパフォーマンス情報を分析するためのコードと、その分析に基づいて、（ｉ）同じタイプのＩ／Ｏパフォーマンス特性を有するものとみなされる周期的時間ウィンドウ、および（ｉｉ）その周期的時間ウィンドウで施行されるものとして特徴付けられるその同じタイプのＩ／Ｏパフォーマンス特性としてのＩ／Ｏパフォーマンス特性のタイプ、を導出するためのコードであって、その周期的時間ウィンドウおよびその周期的時間ウィンドウのＩ／Ｏパフォーマンス特性のタイプを、ストレージボリュームごとに導出するためのコードと、周期的時間ウィンドウごとにサービスレベル目標（ＳＬＯ）のタイプを、その周期的時間ウィンドウのＩ／Ｏパフォーマンス特性のタイプに基づいて決定するためのコードと、周期的時間ウィンドウごとにＳＬＯの閾値を、その周期的時間ウィンドウ、ＳＬＯのタイプ、およびＩ／Ｏオペレーションのパフォーマンス情報に基づいて計算するためのコードと、上記別のコンピュータ上で同じアプリケーションによって実行されるデータを保存するストレージボリュームのセットを有するストレージボリュームグループごとに、（ｉ）ある周期的モニタリングウィンドウのＳＬＯのタイプ、および（ｉｉ）その周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードであって、上記周期的時間ウィンドウ、周期的時間ウィンドウのＳＬＯのタイプ、および周期的時間ウィンドウのＳＬＯの閾値を用いることにより生成される、周期的モニタリングウィンドウ、周期的モニタリングウィンドウのＳＬＯのタイプ、および周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードと、その周期的モニタリングウィンドウのサービスレベル値がＳＬＯに違反しているか否かを、その周期的モニタリングウィンドウのＳＬＯの閾値に基づいて、ストレージボリュームごとに監視するためのコードと、を含み、その周期的モニタリングウィンドウのサービスレベル値は、その周期的モニタリングウィンドウのＳＬＯのタイプと同じタイプの、上記期間後に施行されるＩ／Ｏオペレーションのパフォーマンス情報から導出され、上記期間後のＩ／Ｏオペレーションのパフォーマンス情報は、複数のストレージボリュームの各々について、ストレージシステムから収集される。

一部の実施形態では、コンピュータプログラムは、Ｉ／Ｏオペレーションの既定の正常パフォーマンスレベルに基づいて、正常オペレーションではない非正常オペレーションの１期間以上の期間を同定するためのコードと、上記周期的時間ウィンドウから非正常オペレーションの１期間以上の期間を除外するためのコードと、をさらに含む。周期的モニタリングウィンドウは、その間に、あるモニタリンググループのすべてのストレージボリュームが同じタイプのＩ／Ｏパフォーマンス特性を示す周期的な期間であり、モニタリンググループは、上記ストレージボリュームグループ内のストレージボリュームからなるグループである。コンピュータプログラムは、上記ストレージボリュームグループについて１つ以上の周期的時間ウィンドウを導出するためのコード、をさらに含み、各々の周期的時間ウィンドウは、対応するモニタリンググループに対応しており、その対応するモニタリンググループのすべてのストレージボリュームは、その対応する周期的時間ウィンドウの間に、同じタイプのＩ／Ｏパフォーマンス特性を示すように、各々の周期的時間ウィンドウは対応するモニタリンググループに関連付けられている。各々のモニタリンググループは、上記ストレージボリュームグループ内のストレージボリュームからなるグループであり、対応するモニタリンググループＩＤによって識別される。

具体的な実施形態では、コンピュータプログラムは、あるストレージボリュームが監視されているか否か判断するためのコードと、そのストレージボリュームが監視されている場合には、そのストレージボリュームの該周期的モニタリングウィンドウのＳＬＯの閾値に基づいて、該周期的モニタリングウィンドウのサービスレベル値をＳＬＯと比較し、一方、そのストレージボリュームが監視されていない場合には、前の周期的時間ウィンドウを分析して、そのストレージボリュームについて周期的時間ウィンドウが検出されるか否か判断することにより、そのストレージボリュームの監視を開始するかどうか決定し、ｙｅｓの場合には、その検出された周期的時間ウィンドウの期間のすべてのサービスレベル値を評価することで、その検出された周期的時間ウィンドウのＳＬＯのタイプを決定し、その検出された周期的時間ウィンドウのＳＬＯの閾値を計算し、そして、そのストレージボリュームを含むストレージボリュームグループについて、ある周期的モニタリングウィンドウのＳＬＯのタイプ、およびその周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードと、この比較または評価に続いて、そのストレージボリュームのその周期的モニタリングウィンドウのＳＬＯの閾値に基づいて、その周期的モニタリングウィンドウのサービスレベル値がＳＬＯに違反しているか否か判断するためのコードと、をさらに含む。

一部の実施形態では、Ｉ／Ｏオペレーションのパフォーマンス情報を分析するためのコードは、（１）ランダムＩ／Ｏが第１の閾値を下回る場合のシーケンシャルＩ／Ｏ、（２）ランダムＩ／Ｏが第１の閾値と第２の閾値の間である場合の混合Ｉ／Ｏ、（３）ランダムＩ／Ｏが第２の閾値を上回る場合のランダムＩ／Ｏ、を含む複数のタイプのＩ／Ｏパフォーマンス特性のタイプを、ストレージボリュームごとに決定するためのコードを含む。ランダムＩ／Ｏの場合のＳＬＯのタイプは応答時間であり、シーケンシャルＩ／Ｏの場合のＳＬＯのタイプはデータスループットレートである。周期的時間ウィンドウを導出することは、その間は同じタイプのＩ／Ｏパフォーマンス特性が施行されている持続Ｉ／Ｏデュレーションであって、既定の最小持続Ｉ／Ｏデュレーション閾値を上回る持続Ｉ／Ｏデュレーションを、その周期的時間ウィンドウが有することを規定することを含む。

本発明の別の態様は、コンピュータ可読記憶媒体に格納されたコンピュータプログラムであって、コンピュータで実行されるコンピュータプログラムに関し、該コンピュータは、ストレージコントローラと、ストレージコントローラによって制御される複数のストレージデバイスと、を備えるストレージシステムを、該ストレージシステムの複数のストレージボリュームのうちのストレージボリュームに対して別のコンピュータから送信された入力／出力（Ｉ／Ｏ）コマンドの書き込みデータを保存するために、管理するように機能する。コンピュータプログラムは、ストレージボリュームごとに、ある期間についてのＩ／Ｏオペレーションのパフォーマンス情報であって、その期間についてストレージシステムから収集される複数のストレージボリュームの各々のＩ／Ｏオペレーションのパフォーマンス情報を分析することにより、（ｉ）同じタイプのＩ／Ｏパフォーマンス特性を有するものとみなされる周期的時間ウィンドウ、（ｉｉ）その周期的時間ウィンドウのサービスレベル目標（ＳＬＯ）のタイプ、および（ｉｉｉ）ＳＬＯのそのタイプに応じて導出される、その周期的時間ウィンドウのＳＬＯの閾値、をストレージボリュームごとに導出するためのコードと、（ｉ）ある周期的モニタリングウィンドウのＳＬＯのタイプ、および（ｉｉ）その周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードであって、上記周期的時間ウィンドウ、周期的時間ウィンドウのＳＬＯのタイプ、および周期的時間ウィンドウのＳＬＯの閾値を用いることにより生成される、周期的モニタリングウィンドウ、周期的モニタリングウィンドウのＳＬＯのタイプ、および周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードと、その周期的モニタリングウィンドウのサービスレベル値がＳＬＯに違反しているか否かを、その周期的モニタリングウィンドウのＳＬＯの閾値に基づいて監視するためのコードと、を含み、その周期的モニタリングウィンドウのサービスレベル値は、その周期的モニタリングウィンドウのＳＬＯのタイプと同じタイプの、上記期間後に施行されるＩ／Ｏオペレーションのパフォーマンス情報から導出され、上記期間後のＩ／Ｏオペレーションのパフォーマンス情報は、複数のストレージボリュームの各々について、ストレージシステムから収集される。

本発明の別の態様によれば、コンピュータプログラムは、ストレージコントローラと、ストレージコントローラによって制御される複数のストレージデバイスと、を備えるストレージシステムを、該ストレージシステムの複数のストレージボリュームのうちのストレージボリュームに対してコンピュータから送信された入力／出力（Ｉ／Ｏ）コマンドの書き込みデータを保存するために、管理するためのコードと、ストレージボリュームごとに、ある期間についてのＩ／Ｏオペレーションのパフォーマンス情報であって、その期間についてストレージシステムから収集される複数のストレージボリュームの各々のＩ／Ｏオペレーションのパフォーマンス情報を分析することにより、（ｉ）同じタイプのＩ／Ｏパフォーマンス特性を有するものとみなされる周期的時間ウィンドウ、（ｉｉ）その周期的時間ウィンドウのサービスレベル目標（ＳＬＯ）のタイプ、および（ｉｉｉ）ＳＬＯのそのタイプに応じて導出される、その周期的時間ウィンドウのＳＬＯの閾値、をストレージボリュームごとに導出するためのコードと、（ｉ）ある周期的モニタリングウィンドウのＳＬＯのタイプ、および（ｉｉ）その周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードであって、上記周期的時間ウィンドウ、周期的時間ウィンドウのＳＬＯのタイプ、および周期的時間ウィンドウのＳＬＯの閾値を用いることにより生成される、その周期的モニタリングウィンドウ、周期的モニタリングウィンドウのＳＬＯのタイプ、および周期的モニタリングウィンドウのＳＬＯの閾値を、ユーザに提供するためのコードと、その周期的モニタリングウィンドウのサービスレベル値がＳＬＯに違反しているか否かを、その周期的モニタリングウィンドウのＳＬＯの閾値に基づいて監視するためのコードと、を含み、その周期的モニタリングウィンドウのサービスレベル値は、その周期的モニタリングウィンドウのＳＬＯのタイプと同じタイプの、上記期間後に施行されるＩ／Ｏオペレーションのパフォーマンス情報から導出され、上記期間後のＩ／Ｏオペレーションのパフォーマンス情報は、複数のストレージボリュームの各々について、ストレージシステムから収集される。

本発明のこれらおよび他の特徴ならびに効果は、以下の具体的な実施形態についての詳細な説明を参照することで、当業者に明らかになるであろう。

本発明の方法ならびに装置を適用することができるシステムのハードウェア構成の一例を示している。

プロビジョニングされたボリュームの論理レイアウトの一例を示している。

ボリュームのワークロード特性（ワークロード・プロファイル）を示す、データベースアプリケーションについてのテーブルである。

ボリュームパフォーマンスデータ・テーブルの一例を示している。

ストレージグループ／ボリューム・テーブルの一例を示している。

SRE_SUSTAINED_IOテーブルの一例を示している。

SRE_TIME_BUCKETテーブルの一例を示している。

SRE_RECOMMENDATIONテーブルの一例を示している。

SRE_THRESHOLD_BUCKETテーブルの一例を示している。

SRE_RECOMMENDED_MONITORING_GROUPテーブルの一例を示している。

SRE_MONITORING_GROUP_VOLUMEテーブルの一例を示している。

ボリュームパフォーマンスデータを分析するプロセスを示すフロー図の一例を示している。

推奨ＳＬＯパラメータを計算するプロセスを示すフロー図の一例を示している。

タイムバケットＩＤを計算するプロセスを示すフロー図の一例を示している。

ワークロードＩＯの周期性を同定するプロセスを示すフロー図の一例を示している。

ＳＬＯ閾値を集約するプロセスを示すフロー図の一例を示している。

モニタリングウィンドウおよびモニタリンググループデータを計算するプロセスを示すフロー図の一例を示している。

基本的なＳＬＯモニタリングのプロセスを示すフロー図の一例を示している。

発明の本実施形態で使用されるパラメータのリストの一例を示している。

アプリケーションＵＩ（ユーザインタフェース）の一例を示している。

ＳＬＯリコメンデーションの概要ビューの画面の一例を示している。

ＳＬＯリコメンデーションのカテゴリビューの画面の一例を示している。

モニタリンググループの一覧の画面の一例を示している。

モニタリンググループのＳＬＯパラメータの閲覧および編集のための画面の一例を示している。

ボリュームのＳＬＯリコメンデーションを確認するための画面の概観の一例を示している。

ＳＬＯリコメンデーションの概観である概要ビュー（図２１ａを参照）を表示するためのプロセスを示すフロー図の一例を示している。

ＳＬＯリコメンデーションの概観であるカテゴリビュー（図２１ｂを参照）を表示するためのプロセスを示すフロー図の一例を示している。

ボリュームの詳細情報を閲覧するためのプロセスを示すフロー図の一例を示している。

ユーザがＳＬＯ推奨値を承認するためのプロセスを示すフロー図の一例を示している。

ユーザが現在値を編集するためのプロセスを示すフロー図の一例を示している。

ポートパフォーマンスデータの一例を示しており、各ポートＩＤについて、データ時刻およびポートプロセッサビジー（％）を一覧表示している。

ＲＡＩＤグループパフォーマンスデータの一例を示しており、各ＲＡＩＤグループについて、データ時刻およびＲＧプロセッサビジー（％）を一覧表示している。

ポートからボリュームへのマッピングデータの一例を示している。

ＲＡＩＤグループからボリュームへのマッピングデータの一例を示している。

ポートのパフォーマンス低下を特定するためのプロセスを示すフロー図の一例を示している。

ＲＡＩＤグループのパフォーマンス低下を特定するためのプロセスを示すフロー図の一例を示している。

動的モニタリングのためのプロセスを示すフロー図の一例を示している。

本発明のプロセスの一例を示す概念図である。

ＳＬＯパラメータを決定するための過去のパフォーマンスデータの分析の視覚表示である。

図３８の分析のステップ１を示している。

図３８の分析のステップ２を示している。

図３８の分析のステップ３を示している。

本発明の以下の詳細な説明では、本開示の一部をなす添付の図面を参照し、それらの図面に、限定するものではない実例として、本発明を実施することができる例示的な実施形態を示している。図面では、本質的に類似したコンポーネントは、いくつかの図面にわたって同様の符号で示している。また、詳細な説明では、以下に記載するような、さらには図面に示すような、種々の例示的な実施形態を提示しているが、本発明は、本明細書で記載および図示される実施形態に限定されるものではなく、当業者に周知であるような、または周知となるような、他の実施形態に拡張することができるということに留意すべきである。本明細書における「一実施形態」、「本実施形態」、または「これらの実施形態」という表現は、その実施形態に関連して記載される特定の機能、構造、または特徴が、本発明の少なくとも１つの実施形態に含まれることを意味し、これらの表現が本明細書の様々な箇所に記載されていても、必ずしもそれらがすべて同じ実施形態を指しているとは限らない。また、本発明についての完全な理解を与えるため、様々な具体的詳細が以下の詳細な説明において記載される。しかしながら、これら特定の詳細は、すべてが本発明を実施するために必要とは限らないことは、当業者には明らかであろう。他の状況では、本発明を不必要に不明瞭にすることがないよう、周知の構造、材料、回路、プロセス、およびインタフェースについては詳細に記載しておらず、さらに／または、それらをブロック図の形式で示している場合がある。

また、以下の詳細な説明の一部は、コンピュータにおける演算のアルゴリズムおよび記号表現によって提示される。これらのアルゴリズム記述および記号表現は、データ処理技術の当業者が、自身の技術革新の本質を他の当業者に最も効果的に伝えるために用いる手段である。アルゴリズムは、所望の最終状態または結果に至る一連の定義されたステップである。本発明において、実施されるステップは、具体的な結果を得るための具体的な数量の物理的操作を必要とする。通常、これらの数量は、必ずしもではないが、記憶、伝達、結合、比較、およびその他の操作が可能な電気信号もしくは磁気信号または命令の形をとるものである。これらの信号は、ビット、値、要素、記号、文字、項、番号、命令などとして参照することが、一般的に使用されているという主な理由で、時として好都合であることが実証されている。しかしながら、留意すべきことは、これらおよび類似の表現はすべて、適切な物理量に関連付けられるべきであり、それらの数量に適用される単なる便宜的なラベルにすぎないということである。別段の規定がある場合を除き、以下の説明から明らかなように、本明細書全体を通して「処理する」、「演算する」、「計算する」、「判断する」、「表示する」などのような用語を使用する解説は、コンピュータシステムのレジスタおよびメモリ内の物理的（電子的）な量として表されるデータを、コンピュータシステムのメモリもしくはレジスタ内または他の情報記憶、伝達、または表示装置内で同様に物理量として表される他のデータに操作および変換する、コンピュータシステムまたは他の情報処理装置のアクションおよびプロセスを含み得るものと理解される。

本発明は、さらに、本明細書に記載のオペレーションを実行するための装置に関する。この装置は、所要の目的のために専用に構築することができ、または１つ以上のコンピュータプログラムにより選択的にアクティブ化または再構成される１つ以上の汎用コンピュータを含むことができる。かかるコンピュータプログラムは、限定するものではないが、光ディスク、磁気ディスク、読み取り専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびドライブ、または電子情報を保存するのに適した他の任意のタイプの媒体など、非一時的媒体を含むコンピュータ可読記憶媒体に保存することができる。本明細書で提示するアルゴリズムならびに表示は、本来、特定のコンピュータまたは他の装置に関連したものではない。種々の汎用システムを、本明細書に記載の教示によるプログラムおよびモジュールと共に用いることができ、または所望の方法ステップを実行するために、より特化した装置を構築するほうが適当であることが実証される場合がある。また、本発明は、いずれかの特定のプログラミング言語に準拠して説明されるものではない。当然のことながら、本明細書に記載の発明の教示を実施するために、様々なプログラミング言語を用いることができる。プログラミング言語（複数の場合もある）による命令は、例えば中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラである１つ以上の処理装置で実行することができる。

さらに詳細に以下で説明する本発明の例示的な実施形態により、動的ストレージサービスレベル・モニタリングのための装置、方法、およびコンピュータプログラムを提供する。

本発明の一態様は、管理モジュール（ソフトウェアなどとすることができる）であり、これは、すべてのストレージデバイスについて、過去のパフォーマンスデータならびに連続フローのパフォーマンスデータを分析して、（１）現在のＩＯプロファイルに基づいて、どのＳＬＯモニタリングを適用すべきか、および（２）（現在のＩＯタイプおよび過去のプロファイルに基づいて）そのＳＬＯのモニタリングにはどのようなパラメータを用いるべきか、を特定する。このソリューションでは、現行のＩＯワークロードおよびパフォーマンスレベルを分析する。サーバおよびデバイスのほとんどが正常に動作していると仮定して、ＩＯプロファイルおよびワークロードパターンを取得することで、どのボリュームを、どのメトリクスについて、いつ、どのような閾値を用いて、監視すべきかを特定する。

一実施形態において、システムは、少なくとも１つのストレージエリアネットワーク（ＳＡＮ）と、少なくとも１つの接続されたストレージシステムと、管理サーバと、を備える。管理サーバは、ＳＡＮに接続するためのホストバスアダプタ（ＨＢＡ）を有し、さらに、（コマンドデバイスと呼ばれる）特殊なストレージデバイスが、このサーバにプロビジョニングされている。多くのサーバが、ストレージシステムからのストレージデバイス（別称、ボリューム）を使用するように構成されている。それらのサーバはいずれも、ＳＡＮに接続するためのホストバスアダプタ（ＨＢＡ）を有する。これらのサーバに、ストレージシステムからストレージデバイスがプロビジョニングされる。

管理モジュール（管理ソフトウェアとすることができる）のプロセスには、以下のことが含まれる。

１．コマンドデバイスを用いて、すべてのストレージシステム・コンポーネント（ボリューム、ポート、キャッシュ、ＲＡＩＤグループ、など）についてのパフォーマンスデータを収集する。

２．各ボリュームのパフォーマンスメトリクスを分析することで、ＩＯタイプ（ランダム、シーケンシャル、など）を特定する。

３．ＩＯパターンを分析することで、持続ＩＯの期間を特定する。

４．ストレージアレイ・コンポーネントの使用率をさらに分析することで、正常オペレーションの期間、およびコンポーネントの使用率が高い（パフォーマンスの低下を引き起こし得る）期間を特定する。

ａ．一部のコンポーネント（例えば、ポートおよびＲＡＩＤグループ）の使用率レベルが高いと、正常オペレーションではなく、パフォーマンスの低下を引き起こす。これは、典型的には、高負荷の分散が不均衡であるときに生じる。

５．持続ＩＯ期間中のデータポイントの統計分析を用いて閾値を計算する。コンポーネントの高使用率（ステップ４）に対応するデータポイントは、非正常（低下した）システムパフォーマンスを表すものとして、サンプルから除外される。

６．各々のＳＬＯタイプについて、閾値をバケット化によりグループ分けすることで、その特定のＩＯタイプのサービスレベルの、人間が管理できるリストを導出する。例えば、トランザクショナル／ランダムＩＯワークロードについては、１ミリ秒未満で異なる数百通りの値ではなく、５〜１０レベルの応答時間レベルが特定される。

７．（サーバまたはアプリケーションにプロビジョニングされたボリュームからなる）所与のストレージグループおよび（応答時間またはデータスループットレートなどの）特定のＳＬＯタイプについて、そのメンバーであるボリュームの様々に異なるモニタリングウィンドウを、＋／−１時間に、さらにグループ分けして、モニタリングウィンドウのリストに集約する。

８．これらの集約されたＳＬＯレベルおよびモニタリングウィンドウを、推奨値としてユーザに提示する。ユーザは、推奨値を承認して、推奨されたＳＬＯのセットでストレージグループを監視する決断をすることができ、またはそれらのＳＬＯを変更して受け入れることができ、またはそれらを完全に無視することができる。

９．ユーザは、ＳＬＯポリシー・リコメンデーションエンジンを周期的に（毎月、または四半期ごとに）作動させることで、そのストレージ環境におけるワークロードの変化を分析して、モニタリングレベルを微調整することができる。

図３７は、本発明のプロセスの一例を示す概念図である。データ収集ステップは、上記のステップ１に相当し、ストレージアレイ構成データを収集することと、各々のボリュームについてストレージアレイ・パフォーマンスデータを収集することと、を伴う。データ分析ステップのうちの３つのステップは、上記のステップ２〜５に相当し、ストレージグループを作成するために構成データを分析することと、適用可能なＳＬＯおよびＭＷ（モニタリングウィンドウ）を決定するために（経時的に）各ボリュームのＩＯタイプを分析することと、現在のＳＬＯメトリクスのベースライン値を特定することと、を含む。その後に続くデータ分析ステップは、上記のステップ６および７に相当し、ＳＬＯタイプ、閾値、およびＭＷを、（例えば、１０〜２０個未満の）ＳＬＯプロファイルからなる固定セットにクラスタ化することを伴う。ユーザ入力ステップは、上記のステップ８に相当し、これにより、ユーザは、推奨ＳＬＯプロファイルを確認して、それらを更新および／または承認することができ、さらに、所与のアプリケーション用の推奨ＳＬＯプロファイルを過去の傾向と共に確認して、それらを更新および／または承認することができる。最後に、上記のステップ９は、図３７において、現在のＩＯプロファイルを、構成されたＳＬＯプロファイルと比較するために、ユーザが周期的に分析を実行することができるステップに相当する。図３７は、さらにモニタリングステップを示しており、このステップにおいて、コマンドディレクタは、ＳＬＯプロファイルを監視して、ＳＬＯ違反を通知する。

本発明は、ストレージ環境を計画し、監視するために用いることができる。共通のモニタリング閾値によるベースライン設定法に比した利点は、簡単なモニタリング構成で、ＯＬＴＰ、バッチなど、変化するアプリケーションＩ／Ｏ挙動に応じて、ユーザが適切なサービスレベル・モニタリング方法を動的に適用することを可能としていることである。

［使用される例の説明］

実施形態について説明するために、以下の例を用いる。図１は、本発明の方法ならびに装置を適用することができるシステムのハードウェア構成の一例を示している。システムは、ストレージシステム１００１と、サーバ１００２と、ストレージ管理サーバ１００３とを備え、これらは、ＳＡＮ １００４に接続されている。ストレージ管理サーバ１００３は、コマンドディレクタ・ソフトウェア１００５を有している。ウェブストア・アプリケーションのためのプロダクション・データベースをホストしているプロダクションサーバ１００６（ＰＲＯＤ＿ＤＢ＿ＷＥＢＳＴＯＲＥ）が、さらにＳＡＮ １００４に接続されている。このアプリケーションは、３つのタイプのボリューム、すなわち、インデックスボリューム、データボリューム、トランザクションログ・ボリュームを有する。

ストレージシステム１００１は、（ＲＡＩＤグループ用の）バックエンドプロセッサと、（ポート用の）フロントエンドプロセッサと、キャッシュと、キャッシュスイッチと、ディスクドライブと、を有する。サーバ１００２は、ＣＰＵ（中央処理装置）と、メモリと、ユーザアプリケーションと、ＯＳ（オペレーティングシステム）と、ＨＢＡインタフェースカードと、を有する。ストレージ管理サーバは、ＣＰＵと、メモリと、ストレージと、パフォーマンスデータを収集するためのコマンドデバイスと、ＨＢＡインタフェースカードと、を有する。コマンドディレクタ・ソフトウェア１００５は、データコレクタと、ＬＵＮ所有者アナライザと、ＳＬＯリコメンデーションエンジンと、ＳＬＯモニタリングモジュールと、レポートエンジンと、ウェブサーバと、プレゼンテーション層と、データベースと、を含む。

図２は、プロビジョニングされたボリュームの論理レイアウトの一例を示している。ストレージシステム内にあるのは、ＲＡＩＤグループ（例えば、０１−０１および０１−０５）である。プロビジョニングされたボリュームは、インデックスボリューム０１：０１および０１：０２と、データボリューム０２：０１および０２：０２と、トランザクションログ・ボリューム０３：０１および０３：０２と、を含んでいる。

図３は、データベースアプリケーションについて、ボリュームのワークロード特性（ワークロード・プロファイル）を示すテーブルである。ワークロード１のとき（昼間）には、インデックスボリュームは、高速応答時間で、５０％のランダムリードと５０％のランダムライトを有し、データボリュームは、通常応答時間で、６５％のランダムリードと３５％のランダムライトを有し、トランザクションログ・ボリュームは、９８％のシーケンシャルライトを有する。ワークロード２のとき（夜間）には、データボリュームは、１００％のシーケンシャルリードを有する。ワークロード３のとき（深夜）には、データボリュームは、１００％のシーケンシャルリードを有する。

インデックスボリュームは、データベースインデックスを保持しており、従って、少量であるが高速のランダムリードおよびライトを有する。データボリュームは、実データを保持している。通常のウェブオペレーション（ワークロード１）の間は、これらのボリュームは、ランダムアクセスパターンを有する。データウェアハウスへのデータのデステージング（ワークロード２）およびバックアップ・オペレーション（ワークロード３）の間は、ワークロードは、主にシーケンシャルリードである。トランザクションログ・ボリュームは、主にトランザクションログの書き込み（ワークロード１）のためのものである。データ保守の際に、これらのログを読み出すことができる。主なワークロードパターンは、シーケンシャルライトである。

窓口の稼働に関して、米国の企業は、このウェブストアを使用し、従って、主に、午前９時から午後５時までが、通常の稼働状態（ワークロード１）である。毎夜、午後９時から午後１１時までは、データウェアハウスアプリケーションへのデータのデステージング（ワークロード２）がある。毎日未明の午前１時から午前３時までは、データベースの増分バックアップ・オペレーション（ワークロード３）がある。日曜日の未明の午前１時から午前５時までは、完全バックアップが予定されている。

図４は、ボリュームパフォーマンスデータ・テーブルの一例を示している。テーブルは、各ボリュームについて、データ時刻、ランダムリードＩＯＰＳ（１秒あたりの入力／出力オペレーション数）、シーケンシャルリードＩＯＰＳ、ランダムライトＩＯＰＳ、シーケンシャルライトＩＯＰＳ、ランダムリードＭｂｐｓ（メガビット／秒）、シーケンシャルリードＭｂｐｓ、ランダムライトＭｂｐｓ、シーケンシャルライトＭｂｐｓ、平均応答時間、を示している。

動的ＳＬＯモニタリングロジックの背後にある論理的根拠は、数万から数百万に及び得る数のボリュームであるデータセンタ内のすべてのＳＡＮボリュームについてＳＬＯパラメータ（ＳＬＯのタイプ、閾値、モニタリングウィンドウ）を正確に推定することは極めて難しいということである。そこで、これらのサーバ／アプリケーションおよび関連するＳＡＮボリュームの正常オペレーションの間に、ＳＬＯパラメータを評価し、そして、それらの値を、同ボリュームのモニタリングに使用する。その目的は、環境を監視して、それらのボリュームが、正常オペレーショに基づいて設定されたＳＬＯ閾値に違反しているときにはユーザにアラートを発することである。

本明細書において、ストレージグループとは、同じサーバまたはクラスタにプロビジョニングされたボリュームからなるグループである。このグループ分けは、ストレージシステムにおいて設定されたボリュームパス情報から導出される。モニタリンググループとは、あるストレージグループ内で同じＩＯワークロード特性（例えば、同じ時間帯に、同じＩＯタイプおよび同等レベルのＩＯ応答時間）を示すボリュームからなるサブグループである。図５は、ストレージグループ／ボリューム・テーブルの一例を示している。モニタリンググループＩＤ５７は、ボリューム０１：０１、０１：０２、０２：０１、０２：０２を含んでいる。

持続ＩＯ期間とは、その間、あるボリュームが同じＩＯタイプ（ランダム、シーケンシャル、または混合）である連続した期間である。持続ＩＯ期間は、各ボリュームに対して定義され、それは反復的であっても、反復的でなくてもよい。図６は、ＳＲＥ（ＳＬＯリコメンデーションエンジン）持続ＩＯテーブルの一例を示している。テーブルは、各ボリュームについて、ＩＯタイプ（ランダム、シーケンシャル）、開始時刻、終了時刻、（開始時刻値から算出された）時刻、（開始時刻値から算出された）曜日、タイムバケットＩＤ、ストレージグループＩＤ、を示している。タイムバケットＩＤは、時刻およびウィンドウ（例えば、±３０分の１時間ウィンドウ）に基づくグループ分けを表している。図７は、SRE_TIME_BUCKETテーブルの一例を示している。テーブルは、各タイムバケットＩＤについて、開始時刻、終了時刻、最小開始時刻、最大終了時刻、を示している。

モニタリングウィンドウとは、その間、あるモニタリンググループのすべてのボリュームが同じＩＯワークロード（ランダムまたはシーケンシャル）を示す期間である。モニタリングウィンドウは、典型的には、反復的である（例えば、毎日同じ時間に、または特定の曜日の同じ時間に生じる）。

図８は、SRE_RECOMMENDATIONテーブルの一例を示している。テーブルは、各ボリュームについて、ＩＯタイプ、曜日（空欄は毎日パターンを意味する）、開始時刻、終了時刻、ＲＴ（応答時間）閾値（シーケンシャルＩＯの場合は空欄）、ＤＴＲ（データスループットレート）閾値（ランダムＩＯの場合は空欄）、閾値バケットＩＤ、タイムバケットＩＤ、ストレージグループＩＤ、を示している。閾値バケットＩＤは、閾値の値に基づくグループ分けを表している。図９は、SRE_THRESHOLD_BUCKETテーブルの一例を示している。テーブルは、各閾値バケットＩＤについて、ＩＯタイプ、ＲＴ閾値、ＤＴＲ閾値を示している。

図１０は、SRE_RECOMMENDED_MONITORING_GROUPテーブルの一例を示している。テーブルは、各ストレージグループＩＤについて、モニタリンググループＩＤ、モニタリンググループ、ＩＯタイプ、曜日、開始時刻、終了時刻、ＲＴ閾値、ＤＴＲ閾値、を示している。図１０に示す例では、それぞれのストレージグループＩＤによって表される各ストレージグループ内に、複数のモニタリンググループを表す複数のモニタリンググループＩＤがある。場合によっては、図１７に関連して後述するように、あるストレージグループが、モニタリンググループを１つのみ含む（すなわち、同じストレージグループ内のすべてのボリュームが１つのモニタリンググループに含まれる）ことがある。このテーブルは、ボリュームに基づいて編成された図８のSRE_RECOMMENDATIONテーブルを用いて、ストレージグループＩＤに基づいて再編成される。図１１は、SRE_MONITORING_GROUP_VOLUMEテーブルの一例を示しており、これは、モニタリンググループＩＤおよびボリュームを一覧表示している。

［第１の実施形態］

第１の実施形態は、ＳＬＯパラメータ（閾値およびモニタリングウィンドウの周期性）を決定するための過去のパフォーマンスデータの分析、および正常性を監視するためにどのＳＬＯを用いるべきかを決定するためのリアルタイム・パフォーマンスデータの分析、を示すために提示される。

３つの仮定を用いる。第１の仮定は、個々のデータポイントに対するＩＯタイプの決定に関するものである。いずれのパフォーマンスデータのスナップショットに対しても、ＩＯタイプの決定は、以下の基準を用いて行われる。

１．ランダムＩＯ％が０％〜４０％の間である場合は、シーケンシャルＩＯ。

２．ランダムＩＯ％が４０％〜６０％の間である場合は、混合ＩＯ。

３．ランダムＩＯ％が６０％超である場合は、ランダムＩＯ。

第２の仮定は、ＩＯタイプからＳＬＯタイプへのマッピング、すなわち適用可能なＳＬＯタイプを決定することに関するものである。主としてランダムなＩＯは、「応答時間」すなわちＲＴ閾値を用いて監視するべきである。主としてシーケンシャルなＩＯは、「データスループットレート」すなわちＤＴＲ閾値を用いて監視するべきである。その論理的根拠は、典型的には、シーケンシャルＩＯは、バッチ処理オペレーション（例えば、バックアップ、データウェアハウジングのためのデータ採集、など）の場合に観測されるということである。これらのオペレーションを完了するために要する時間は、決定的因子である。言うまでもなく、他のＩＯタイプがある。

第３の仮定は、持続ＩＯの特定に関するものである。いくらかのダンピングを提供する（ＩＯタイプの変化に敏感すぎないようにする）ためには、持続するＩＯタイプのみが、モニタリング用として適切であると考えられる。従って、最小値である「最小持続ＩＯデュレーション閾値」が規定される。

図３８は、ＳＬＯパラメータを決定するための過去のパフォーマンスデータの分析の視覚表示である。あるアプリケーションのＬＤＥＶについての、時間経過に伴うパフォーマンスデータのスナップショットを示している。各ＬＤＥＶについての連続ＩＯパフォーマンスメトリクスを分析する。

図３９は、図３８の分析のステップ１を示している。第１の仮定で定義された規則を用いて、各データ時刻に、Ｒ（ランダムＩＯの場合）、Ｍ（混合ＩＯの場合）、またはＳ（シーケンシャルＩＯの場合）とマークする。

図４０は、図３８の分析のステップ２を示している。第３の仮定で定義される「最小持続ＩＯデュレーション閾値」を用いて、ＳＬＯモニタリングを実施すべき持続期間（十字マークに対するチェックマークで示される）を選択する。変動するＩＯタイプは、モニタリングされない。

図４１は、図３８の分析のステップ３を示している。第２の仮定で定義された規則を用いて、ＳＬＯモニタリングのタイプおよび閾値を決定する。応答時間ＳＬＯタイプを用いるランダムＩＯタイプの場合は、分析によって、その特定のＬＤＥＶ用のベースライン応答時間を特定する。データスループットレートＳＬＯタイプを用いるシーケンシャルＩＯタイプの場合は、分析によって、ベースライン処理ウィンドウを特定する。

図１２は、ボリュームパフォーマンスデータを分析するプロセスを示すフロー図の一例を示している。プログラムにより、（次の）ボリュームパフォーマンスデータ・レコードを読み出し、ランダムＩＯが６０％超であるかどうか判断する。ｙｅｓの場合は、そのＩＯタイプを、Ｒ（主にランダム）としてマークする。ｎｏの場合は、プログラムにより、ランダムＩＯが４０％以下であるかどうか判断する。ｙｅｓの場合は、そのＩＯタイプを、Ｓ（主にシーケンシャル）としてマークする。ｎｏの場合、プログラムは、次のボリュームパフォーマンスデータ・レコードを読み出すための前のステップに戻る。次のステップで、プログラムにより、ＩＯタイプが変化したかどうか判断する。ｎｏの場合、プログラムは、次のボリュームパフォーマンスデータ・レコードを読み出すための前のステップに戻る。ｙｅｓの場合は、プログラムにより、そのボリュームについて、持続ＩＯ期間を計算する（ステップ１０２）。次に、プログラムにより、その持続ＩＯ期間は、最小所要期間よりも長いかどうか判断する。ｙｅｓの場合は、プログラムにより、そのデータを、ＤＢ（データベース）SRE_SUSTAINED_IOテーブル（図６を参照）に書き込む。ｎｏの場合、プログラムは、すべてのレコードが読み出されるまでは、次のボリュームパフォーマンスデータを読み出すための前のステップに戻る。

図１３は、推奨ＳＬＯパラメータを計算するプロセスを示すフロー図の一例を示している。ステップ２０１で、プログラムにより、ストレージグループからボリュームへのマッピングを、ストレージグループ／ボリューム・テーブル（図５を参照）から読み出して、SRE_SUSTAINED_IOテーブル（図６を参照）において情報を更新する。ステップ２０２で、プログラムにより、SRE_SUSTAINED_IOテーブル（図６を参照）において「時刻」および「曜日」の情報を更新する。これらの値は、同テーブルの「開始時刻」の欄から算出される。ステップ２０３で、プログラムにより、図１４に示すプロセスを用いて、SRE_SUSTAINED_IOテーブル内の各レコードについてタイムバケットＩＤを計算する。ステップ２０４で、プログラムにより、図１５に示すプロセスを用いて、（毎日または毎週の）ＩＯウィンドウの発生パターンを同定する。

ステップ２０５で、プログラムにより、SRE_RECOMMENDATIONテーブル（図８を参照）の各レコードについて、ボリュームパフォーマンス・テーブル（図４を参照）から、同ボリュームについてのレコードであって、そのデータ時刻が、過去のデータのパターン分析で検出された毎日または特定の曜日のいずれかで、開始時刻と終了時刻の範囲内にあるレコードを、読み出す。読み出されるべきメトリクスは、ＩＯタイプに依存する。ＩＯタイプ＝Ｒの場合、プログラムにより、応答時間値を読み出す。ＩＯタイプ＝Ｓの場合、プログラムにより、トータルスループット値を読み出す。プログラムにより、読み出されたそれらのレコードのすべてのメトリクス値の８５パーセンタイル値を計算する。プログラムにより、SRE_RECOMMENDATIONテーブル（図８を参照）において、そのボリューム、ＩＯタイプについてのレコードであって、開始時刻、終了時刻、毎日／曜日についてのレコードの、この「閾値」を更新する。

ステップ２０６で、プログラムにより、図１６に示すプロセスを用いて、ＳＬＯ閾値バケットＩＤを計算する。ステップ２０７で、プログラムにより、図１７に示すプロセスを用いて、各ストレージグループについてのモニタリングウィンドウ、およびモニタリンググループ情報を計算する。SRE_RECOMMENDED_MONITORING_GROUPテーブル（図１０を参照）およびSRE_MONITORING_GROUP_VOLUMEテーブル（図１１を参照）は、ＵＩ（ユーザインタフェース）ワークフローを開始させるために用いることができる最終リコメンデーションを有している。

図１４は、タイムバケットＩＤを計算するプロセスを示すフロー図の一例を示している。ステップ３０１で、プログラムにより、SRE_SUSTAINED_IOテーブル（図６を参照）からすべてのレコードを読み出して、それらのレコードを開始時刻によって順序付けし、次に終了時刻によって順序付けする。ステップ３０２で、プログラムにより、第１のレコードのタイムバケットＩＤに、「１」とマークする。ステップ３０３で、プログラムにより、そのタイムバケットＩＤ、開始時刻、終了時刻を、SRE_TIME_BUCKETテーブル（図７を参照）に記録する。続いて、プログラムにより、次のレコードを読み出して、その新たなレコードの開始時刻と終了時刻が、SRE_TIME_BUCKETテーブル（図７を参照）における現在のタイムバケットＩＤに対応するレコードのそれぞれ開始時刻と終了時刻のタイムバケットサイズ（例えば１時間）内にあるかどうか判断する。ｙｅｓの場合は、プログラムにより、その新たなレコードにおいて現在のタイムバケットＩＤをマークし（ステップ３０５）、そして、さらなるレコードがなくなるまでは、次のレコードを読み出すための前のステップに戻る。ｎｏの場合は、プログラムにより、現在のタイムバケットＩＤ値をインクリメントして（ステップ３０４）、その現在のタイムバケットＩＤ、開始時刻、終了時刻を、SRE_TIME_BUCKETテーブル（図７を参照）に記録し（ステップ３０３）、その新たなレコードにおいて現在のタイムバケットＩＤをマークし（ステップ３０５）、そして、さらなるレコードがなくなるまでは、次のレコードを読み出すための前のステップに戻る。読み出されるべき、さらなるレコードがない場合、プログラムは、ステップ３０６に進む。ステップ３０６では、プログラムにより、各タイムバケットＩＤについて、そのタイムバケットＩＤに対応する最小開始時刻および最大終了時刻を見つけるために、SRE_SUSTAINED_IOテーブル（図６を参照）のレコードに照会する。次に、プログラムにより、これらの計算された最小値および最大値を、SRE_RECOMMENDATIONテーブル（図８を参照）において、同じタイムバケットＩＤのレコードの開始時刻および終了時刻として更新する。

図１５は、ワークロードＩＯの周期性を同定するプロセスを示すフロー図の一例を示している。毎日パターンを見つけるためのステップ４０１において、プログラムにより、SRE_SUSTAINED_IOテーブル（図６を参照）のレコードを読み出す。所与のボリュームについて、その時間の少なくとも７５％において、同じＩＯタイプおよびタイムバケットＩＤのレコードを確認できる（例えば、４週間のデータを分析して、全部で２８個の可能性のあるレコードのうち少なくとも２１個のレコードを確認できる）場合には、そのボリュームおよびＩＯタイプについて毎日パターンを見つけることができると結論付けられる。プログラムにより、これらを適切な情報と共に、SRE_RECOMMENDATIONテーブル（図８を参照）に記録する。（毎日パターンが見つからなかったボリュームについてのみ）毎週パターンを見つけるためのステップ４０２において、プログラムにより、SRE_SUSTAINED_IOテーブル（図６を参照）において、毎日パターンが見つからなかったレコードを読み出す。所与のボリュームについて、その時間の少なくとも７５％において、同じＩＯタイプ、タイムバケットＩＤ、および曜日のレコードを確認できる（例えば、４週間のデータを分析して、全部で４個の可能性のあるレコードのうち少なくとも３個のレコードを確認できる）場合には、そのボリュームおよびＩＯタイプについて毎週パターンを見つけることができると結論付けられる。プログラムにより、これらを適切な情報と共に、SRE_RECOMMENDATIONテーブル（図８を参照）に記録する。

図１６は、ＳＬＯ閾値を集約するプロセスを示すフロー図の一例を示している。ステップ５０１で、プログラムにより、SRE_RECOMMENDATIONテーブル（図８を参照）から、所与のストレージグループかつ所与のＳＬＯタイプ／ＩＯタイプのすべてのレコードを読み出し、プログラムにより、それらのレコードを「閾値」によって降順で順序付けする。例えば、閾値は、ＩＯタイプＲの場合のＲＴ閾値、またはＩＯタイプＳの場合のＤＴＲ閾値である。ステップ５０２で、プログラムにより、第１のレコードの閾値バケットＩＤに、「１」とマークする。ステップ５０３で、プログラムにより、現在の閾値バケットＩＤおよび閾値を、SRE_THRESHOLD_BUCKETテーブル（図９を参照）に記録する。続いて、プログラムにより、次のレコードを読み出し、その新たなレコードの閾値と現在の閾値バケットＩＤに対応する閾値との間のΔ（差分）が、対応する閾値バケットサイズよりも大きいかどうか判断する。例えば、ＲＴ閾値の閾値バケットサイズは５ｍｓであり、ＤＴＲ閾値の閾値バケットサイズは１０Ｍｂｐｓである。ｙｅｓの場合は、プログラムにより、新たなレコードにおいて現在の閾値バケットＩＤをマークし（ステップ５０４）、そして、さらなるレコードがなくなるまでは、次のレコードを読み出すための前のステップに戻る。ｎｏの場合は、プログラムにより、現在のタイムバケットＩＤ値をインクリメントして（ステップ５０５）、その現在の閾値バケットＩＤ、ＩＯタイプ、閾値を、SRE_THRESHOLD_BUCKETテーブル（図９を参照）に記録し（ステップ５０３）、その新たなレコードにおいて現在の閾値バケットＩＤをマークし（ステップ５０４）、そして、さらなるレコードがなくなるまでは、次のレコードを読み出すための前のステップに戻る。読み出されるべき、さらなるレコードがない場合、プロセスは終了する。

図１７は、モニタリングウィンドウおよびモニタリンググループデータを計算するプロセスを示すフロー図の一例を示している。ステップ６０１で、プログラムにより、SRE_RECOMMENDATIONテーブル（図８を参照）から、１つのストレージグループのレコードを読み出して、それらのレコードをタイムバケットＩＤによって順序付けし、さらにそれらを閾値バケットＩＤによって順序付けする。ステップ６０２で、プログラムにより、ストレージグループＩＤ、ＩＯタイプ、タイムバケットＩＤ、閾値バケットＩＤの組み合わせの各々のためのレコードを、モニタリング・テーブル（図１０および１１を参照）内に作成する。ステップ６０３で、プログラムにより、そのストレージグループＩＤ、ＩＯタイプ、時刻値、閾値を、SRE_RECOMMENDED_MONITORING_GROUPテーブル（図１０を参照）に記録する。プログラムにより、その新たなモニタリンググループＩＤを追加し、そのＩＯタイプおよび閾値に基づいて図１０のモニタリンググループ名を作成する。ストレージグループＩＤで表されるストレージグループは、１つ以上のモニタリンググループＩＤで表される１つ以上のモニタリンググループを含み得る。図１０に示す例では、各々のストレージグループＩＤが、複数のモニタリンググループＩＤを有している。しかしながら、計算によって、同じストレージグループ内のすべてのボリュームが１つのモニタリンググループに含まれることが示される場合は、ストレージグループＩＤで表されるそのストレージグループは、１つのモニタリンググループＩＤで表される１つのモニタリンググループのみを含む。プログラムにより、さらに同モニタリンググループのボリュームを、SRE_MONITORING_GROUP_VOLUMEテーブル（図１１を参照）に記録する。プログラムにより、次のレコードを読み出し、そして、さらなるレコードがなくなりプロセスの終了となるまでは、ステップ６０２に戻る。

図１８は、基本的なＳＬＯモニタリングのプロセスを示すフロー図の一例を示している。開始するには、そのボリュームの新たなパフォーマンスデータを受け取る。プログラムにより、そのボリュームが既に監視されているどうか（例えば、そのボリュームがモニタリングウィンドウ内にあるかどうか）判断する。ｎｏの場合には、プロセスは終了する。ｙｅｓの場合には、プログラムにより、適切なデータポイント値を、ＳＬＯ閾値（例えば、ＲＴ閾値またはＤＴＲ閾値）と比較する。そのデータポイントがＳＬＯ閾値に違反していない場合、プロセスは終了する。データポイントがＳＬＯ閾値に違反している場合は、プログラムにより、その違反をＤＢに記録し、そしてアラートのためのフラグを設定する。アラート閾値に達していない場合、プロセスは終了する。アラート閾値に達した場合には、プログラムにより、アラートを発して、プロセスは終了する。アラート閾値は、アラートを発するために必要な違反の既定累積数とすることができる既定の閾値である。

図１９は、発明の本実施形態で使用されるパラメータのリストの一例を示している。最小持続ＩＯウィンドウ（例えば、２時間）は、実際のＩＯタイプの変動を安定化させるために用いられる。ＩＯタイプ＝「Ｒ」の場合のランダム％（例えば、＞６０％）、ＩＯタイプ＝「Ｍ」の場合のランダム％（例えば、＞４０％かつ≦６０％）、ＩＯタイプ＝「Ｓ」の場合のランダム％（例えば、≦４０％）は、上述の第１の仮定に基づくものであり、これによって、０％〜１００％の範囲が３つのグループに分割される。閾値として使用される応答時間サンプルデータの値（例えば、８５パーセンタイル値）は、変動が大きい応答時間を示すために用いられる。本例では、８５パーセンタイル値は、平均値＋１標準偏差の統計値に基づいて決定される。同じく、閾値として使用されるデータスループット・サンプルデータの値も、本例では８５パーセンタイル値である。データポイントをサンプリングとして不適格であるとするための最小ＩＯＰＳ限度は、本例では５である。タイムバケットサイズ（例えば、１時間）は、すべての開始時刻または終了時刻を同じタイムバケットに統合するために用いられる時間ウィンドウのサイズである。応答時間（ＲＴ）バケットサイズ（例えば、５ｍｓ）としての、そのバケットサイズ内にあるＲＴ閾値のΔは、同じ閾値バケットＩＤを有するものとして扱われる。データスループットレート（ＤＴＲ）バケットサイズとしての、そのバケットサイズ内にあるＤＴＲ閾値のΔは、同じ閾値バケットＩＤを有するものとして扱われる。

図２０は、アプリケーションＵＩ（ユーザインタフェース）の一例を示している。本例のアプリケーションＵＩは、モニタリンググループ、ボリューム、ＳＬＯタイプ、閾値、モニタリングウィンドウ、アクションを示すテーブルを提示する。ユーザは、モニタリンググループのうちの１つを選択すること、またはそれらのモニタリンググループに関連したアクションを選択すること、が可能である。同様の情報は、SRE_RECOMMENDED_MONITORING_GROUPテーブル（図１０）およびSRE_MONITORING_GROUP_VOLUMEテーブル（図１１）に見られる。「See SLO Monitoring Recommendation」リンクをクリックすると、図２１ａの（ＳＬＯリコメンデーションの概要ビュー）画面および図２１ｂの（ＳＬＯリコメンデーションのカテゴリビュー）画面が起動する。特定のモニタリンググループ名をクリックすると、図２３の（モニタリンググループのＳＬＯパラメータの閲覧および編集）画面が起動する。

図２１ａは、ＳＬＯリコメンデーションの概要ビューの画面の一例を示している。概要ビューには、ＳＬＯプロファイル、タイプ、閾値、＃モニタリンググループの欄が表示される。ＳＬＯプロファイルは、本例ではＳＬＯタイプおよび閾値を含んでいる。＃モニタリンググループ欄の番号をクリックすると、図２２の（モニタリンググループの一覧）画面が起動する。

図２１ｂは、ＳＬＯリコメンデーションのカテゴリビューの画面の一例を示している。カテゴリビューには、ＳＬＯモニタリングプロファイル・カテゴリおよび＃モニタリンググループの欄が表示される。ＳＬＯモニタリングプロファイル・カテゴリの例は、「応答時間モニタリング無しのモニタリンググループ」、「応答時間閾値のΔ＞１０ｍｓのモニタリンググループ」、「データスループットレート閾値のΔ＞１０Ｍｂｐｓのモニタリンググループ」である。この場合も同じく、＃モニタリンググループの欄をクリックすると、図２２の画面が起動する。

図２２は、モニタリンググループの一覧の画面の一例を示している。本例のテーブルは、モニタリンググループ、＃ボリューム、ＳＬＯタイプ、閾値、モニタリングウィンドウ、アクションの欄を有する。この場合も、特定のモニタリンググループ名をクリックすると、図２３の画面が起動する。

図２３は、モニタリンググループのＳＬＯパラメータの閲覧および編集のための画面の一例を示している。本例のテーブルは、ボリューム、現在のＳＬＯタイプ、現在の閾値、現在のモニタリングウィンドウ、推奨ＳＬＯタイプ、推奨閾値、推奨モニタリングウィンドウ、アクションの欄を有する。特定のボリュームをクリックすると、図２４の（ボリュームのＳＬＯリコメンデーションを確認する）画面が起動する。

図２４は、ボリュームのＳＬＯリコメンデーションを確認するための画面の概観の一例を示している。画面には、モニタリングウィンドウについて、観測されたストレージサービスレベルが表示される。ランダム％軸は、ランダムＩＯと、混合ＩＯと、シーケンシャルＩＯと、に分割されている。時間軸は、主にシーケンシャルＩＯのモニタリングウィンドウ（ＳＬＯ：データスループットレート）と、主にランダムＩＯのモニタリングウィンドウ（ＳＬＯ：応答時間）と、を含んでいる。画面には、さらに現在のストレージサービス・モニタリングが表示され、これは、ＳＬＯプロファイル、タイプ、閾値、モニタリングウィンドウの欄を有するテーブルに提示される。ＳＬＯプロファイルの例には、「ランダムＩＯ−ゴールドレベル」および「バッチ処理−深夜２」が含まれる。

図２５は、ＳＬＯリコメンデーションの概観である概要ビュー（図２１ａを参照）を表示するためのプロセスを示すフロー図の一例を示している。開始するには、ユーザが、アプリケーション画面（図２０を参照）上の「See SLO Monitoring Recommendation」リンクをクリックする。プログラムにより、SRE_RECOMMENDED_MONITORING_GROUPテーブル（図１０を参照）を読み出して、モニタリンググループ名によって集約し、ボリューム数をカウントする。その他のすべての値は、すべてのレコードで全く同じとなる。プログラムにより、データを画面（図２１ａを参照）に表示する。

図２６は、ＳＬＯリコメンデーションの概観であるカテゴリビュー（図２１ｂを参照）を表示するためのプロセスを示すフロー図の一例を示している。開始するには、ユーザが、アプリケーション画面（図２０を参照）上の「See SLO Monitoring Recommendation」リンクをクリックし、次に「Categorized View」タブ（図２１ｂを参照）をクリックする。プログラムにより、（Ｒは「推奨」を意味するとして、まとめてテーブルＲと呼ばれる）SRE_RECOMMENDED_MONITORING_GROUPテーブル（図１０を参照）およびSRE_MONITORING_GROUP_VOLUMEテーブル（図１１を参照）を読み出し、さらに、（Ｃは「現在の」を意味するとして、テーブルＣと呼ばれる）現在のＳＬＯモニタリングパラメータ・テーブル（例えば、図２４の現在のストレージサービスモニタリング・テーブルを参照）を読み出す。続いて、プログラムにより、両方のＩＯタイプ（Ｒ（ランダム）とＳ（シーケンシャル））について、以下の分析を実行する。あるモニタリンググループ（ＭＧ）のすべてのボリュームが、テーブルＲにはあるが、テーブルＣにはない場合は、その対応するＭＧは、「Not Monitored」に分類される。あるＭＧの一部のボリュームが、テーブルＲにはあるが、テーブルＣにはない場合、またはあるＭＧのすべてのボリュームについて、そのモニタリングウィンドウ（ＭＷ）が、テーブルＣで設定されたものと一致しない場合は、その対応するＭＧは、「Partially Monitored」に分類される。あるＭＧの一部のボリュームがテーブルＲとテーブルＣの両方にあると共に、それらのＭＷも一致している場合は、プログラムにより、推奨閾値と現在設定されている閾値との間のΔを計算して、そのＭＧを、対応するカテゴリに追加する。次に、プログラムにより、データを画面に表示する（図２１ｂを参照）。

図２７は、ボリュームの詳細情報を閲覧するためのプロセスを示すフロー図の一例を示している。開始するには、ユーザが、１つのボリュームをクリックする。プログラムにより、（１）現在のＳＬＯモニタリングデータを収集し、（２）推奨モニタリングデータを収集し、（３）パフォーマンスデータを収集する。収集した情報を、プログラムにより、テーブルおよびチャートを用いて画面に表示する。推奨データおよび現在のデータの例を、図２１ａ、２１ｂ、２４に示している。

図２８は、ユーザがＳＬＯ推奨値を承認するためのプロセスを示すフロー図の一例を示している。開始するには、ユーザが、図２３のモニタリンググループのＳＬＯパラメータの閲覧および編集のための画面表示から、１つ、いくつか、またはすべてのボリュームを選択して、「Accept Recommended value」をクリックする。SRE_RECOMMENDATIONテーブル（図８を参照）からのＳＬＯモニタリングパラメータが、実際のＳＬＯモニタリング・テーブル（リコメンデーション・テーブルと構造は類似したものであり得るが、ただし実際のパラメータおよび値を入れることができる）にコピーされる。プログラムにより、新たな現在値情報で表示を更新する。

図２９は、ユーザが現在値を編集するためのプロセスを示すフロー図の一例を示している。開始するには、ユーザが、図２３のモニタリンググループのＳＬＯパラメータの閲覧および編集のための画面表示から、１つ、いくつか、またはすべてのボリュームを選択して、「Edit Current Value」をクリックする。現在値は、編集可能（または選択可能）となる。ユーザは、それらの値を所望の数値／レベルに手動で変更することができる。そして今度は、この情報が、現在のＳＬＯモニタリング・テーブル（リコメンデーション・テーブルと構造は類似したものであり得るが、ただし現在のパラメータおよび値を入れることができる）に保存される。プログラムにより、新たな現在値情報で表示を更新する。

［第２の実施形態］

第２の実施形態では、アルゴリズムは、ストレージシステム・コンポーネントの内部状態を考慮して修正される。例えば、コンポーネントのいくつかが、全体的なパフォーマンスを低下させるレベルで動作することが分かっているときには、それらの対応するデータポイント（ＲＴおよびＤＴＲ）は、サンプルデータにおいて考慮されない。これにより、サンプルデータは、ストレージシステムの正常な動作状態を忠実に表すものであることが保証される。例として考えられる具体的なケースには、以下のものが含まれる。

１．ポート・マイクロプロセッサの使用率が高い（例えば、６５％超）ときには、ストレージシステムは、パフォーマンスを下げることで、システムをフラッドさせることなく、（パフォーマンスは低下するものの）データ整合性が維持されるように、設計されている。図３０は、ポートパフォーマンスデータの一例を示している。これは、各ポートＩＤについて、データ時刻およびポートプロセッサビジー（％）を一覧表示している。図３２は、ポートからボリュームへのマッピングデータの一例を示している。これは、各ポートＩＤについて、１つ以上のＨＳＤ（ホストストレージドメイン）ＩＤと、さらに各ＨＳＤ ＩＤについて、１つ以上のボリュームＩＤと、を一覧表示している。

２．（ＲＡＩＤグループを制御する）バックエンド・マイクロプロセッサが高い使用率（例えば、８５％超）に達したときには、これがＩＯのパフォーマンスに影響を及ぼす。このような場合も、同じく、対応するデータポイントは、閾値計算用のサンプルデータの一部として考慮されない。図３１は、ＲＡＩＤグループパフォーマンスデータの一例を示している。これは、各ＲＡＩＤグループについて、データ時刻およびＲＧプロセッサビジー（％）を一覧表示している。図３３は、ＲＡＩＤグループからボリュームへのマッピングデータの一例を示している。これは、各ＲＧ ＩＤについて、ボリュームＩＤを一覧表示している。

３．ＩＯの数が極めて少ない場合（例えば、＜５のＩＯＰＳ）は、記録されたメトリクスは、正確ではないと考えられる。このような場合には、それらのデータポイントは、サンプルデータにおいて考慮されない。

図３４は、ポートのパフォーマンス低下を特定するためのプロセスを示すフロー図の一例を示している。プログラムにより、ポートパフォーマンスデータ（図３０を参照）を読み出して、ポートビジー率が６５％超であるか否かチェックする。ｙｅｓの場合は、プログラムにより、そのポートに割り当てられたすべてのボリューム（図３２を参照）を見つけて、この情報を記録し（ステップ１０３）、そしてSRE_SUSTAINED_IOテーブル（図６を参照）に書き込む。いずれの場合も、プログラムにより、すべてのレコードを読み出したかどうか確認して、すべてのレコードが読み出されるまでは、ポートパフォーマンスデータを読み出すための前のステップに戻る。

図３５は、ＲＡＩＤグループのパフォーマンス低下を特定するためのプロセスを示すフロー図の一例を示している。プログラムにより、ＲＡＩＤグループパフォーマンスデータ（図３１を参照）を読み出し、ＲＡＩＤグループビジー率が８５％超であるか否かチェックする。ｙｅｓの場合は、プログラムにより、そのＲＧから作成されたすべてのボリューム（図３３を参照）を見つけて、この情報を記録し（ステップ１０４）、そしてSRE_SUSTAINED_IOテーブル（図６を参照）に書き込む。いずれの場合も、プログラムにより、すべてのレコードを読み出したかどうか確認して、すべてのレコードが読み出されるまでは、ポートパフォーマンスデータを読み出すための前のステップに戻る。

［第３の実施形態］

第３の実施形態では、ＳＬＯモニタリングは、各ストレージグループおよびモニタリンググループに対して特定されたモニタリングウィンドウの間のみではない。ボリュームＩＯは、絶えず監視される。ある特定のタイプの持続ＩＯが確認されると直ちに、予め設定されたＳＬＯ閾値を用いて、そのボリュームのその持続ＩＯを監視する。

図３６は、動的モニタリングのためのプロセスを示すフロー図の一例を示している。プログラムにより、そのボリュームの新たなパフォーマンスデータを受け取って、そのボリュームが既に監視されているか否かチェックする。ｙｅｓの場合は、プログラムにより、適切なデータポイント値を、ＳＬＯ閾値と比較する。ｎｏの場合は、プログラムにより、そのボリュームのモニタリングを開始すべきかどうかの判断を試みる。ボリュームのモニタリングを開始するためのトリガは、そのボリュームが、（持続ＩＯの）最小閾値よりも長い持続ＩＯ期間を有しているかどうか確認することである。ステップ１０５で、プログラムにより、（過去のＩＯデータポイントを含む）その持続ＩＯデュレーションの計算を試みる。持続ＩＯ期間が検出された場合は、そのＩＯタイプに基づいて、プログラムにより、どのＳＬＯモニタリング（ＲＴまたはＤＴＲ）を採用すべきか決定し、さらに、そのボリュームの過去の閾値が所与であるとして、どのような閾値をモニタリングに用いるべきかを決定する。そして、このＳＬＯモニタリングが、検出された持続ＩＯウィンドウ期間のすべてのデータポイントに適用される（ステップ１０６）。ｎｏの場合、プロセスは終了する。

（既に監視されているボリュームについての適切なデータポイント値（持続ＩＯウィンドウのサービスレベル値）をＳＬＯ閾値と比較した後に、またはステップ１０６の後に）続いて、プログラムにより、データポイントが閾値に違反しているかどうか判断する。ｎｏの場合、プロセスは終了する。ｙｅｓの場合は、プログラムにより、その違反をＤＢに記録して、アラートのためのフラグを設定し、そして、アラート閾値（例えば、アラート閾値に達するまでの違反の既定累積数）に達したか否か判断する。ｎｏの場合、プロセスは終了する。ｙｅｓの場合は、プログラムにより、アラートを発する。

言うまでもなく、図１に示すシステム構成は、本発明を実施することができる情報システムの単なる例示であり、本発明は特定のハードウェア構成に限定されない。本発明を実施するコンピュータおよびストレージシステムは、さらに、周知のＩ／Ｏデバイス（例えば、ＣＤおよびＤＶＤドライブ、フロッピーディスクドライブ、ハードドライブなど）を備えることもでき、これらにより、上記発明の実施に使用されるモジュール、プログラム、およびデータ構造を保存し、読み出すことができる。これらのモジュール、プログラム、およびデータ構造は、かかるコンピュータ可読媒体上にコード化することができる。例えば、本発明のデータ構造は、発明で使用するプログラムが常駐する１つ以上のコンピュータ可読媒体とは独立のコンピュータ可読媒体に保存することができる。システムのコンポーネントは、例えば通信ネットワークであるデジタルデータ通信の任意の形式または媒体によって、相互接続することができる。通信ネットワークの例として、ローカルエリアネットワーク、例えばインターネットである広域ネットワーク、無線ネットワーク、ストレージエリアネットワークなどが含まれる。

本明細書では、発明についての完全な理解を与えるため、説明の目的で様々な詳細について記載している。しかしながら、本発明を実施するために、これら特定の詳細のすべてが必要とされるわけではないことは、当業者には明らかであろう。また、本発明は、プロセスとして記述できるということにも留意すべきであり、それは、通常、フローチャート、フロー図、構造図、またはブロック図として表現される。フローチャートでは、オペレーションが逐次プロセスとして記述され得るが、それらのオペレーションの多くは、並列または同時に実行することができる。さらに、オペレーションの順序は並べ替えることができる。

当該技術分野で知られているように、上記オペレーションは、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの何らかの組み合わせによって実行することができる。本発明の実施形態のいくつかの態様は、回路および論理デバイス（ハードウェア）を用いて実装することができる一方、他の態様は、機械可読媒体に格納された命令（ソフトウェア）を用いて実装することができ、それらの命令は、プロセッサで実行されることで、本発明の実施形態を実施する方法をプロセッサに実行させるものである。また、本発明のいくつかの実施形態は、ハードウェアのみで実行することができる一方、他の実施形態は、ソフトウェアのみで実行することができる。さらに、記載された種々の機能は、単一のユニットで実行することができ、または、あらゆる方法で多くのコンポーネントに分散させることができる。ソフトウェアで実行する場合、本方法は、コンピュータ可読媒体に格納された命令に基づいて、汎用コンピュータなどのプロセッサで実行することができる。それらの命令は、所望であれば圧縮および／または暗号化形式で媒体に保存することができる。

上記のことから、本発明は、動的ストレージサービスレベル・モニタリングのための方法、装置、ならびにコンピュータ可読媒体に格納されたプログラムを提供するものであることは明らかであろう。また、本明細書では具体的な実施形態を例示および記載しているが、当業者であれば理解できるように、同じ目的を達成すると予測される任意の構成を、開示された特定の実施形態の代用とすることができる。本開示は、本発明のあらゆる改良または変形を包括するものであり、また、当然のことながら、以下の請求項において使用される用語は、本明細書に開示の特定の実施形態に発明を限定するものと解釈されるべきではない。むしろ、本発明の範囲は、かかる請求項によって権利が認められる均等物の全範囲と共に、確立されたクレーム解釈論に従って解釈されるべき以下の請求項によって、完全に決定されるべきである。

Claims (8)

1. １以上のサーバに複数のストレージボリュームを提供するストレージシステムに接続された管理コンピュータであって、
   ストレージボリュームについて、そのストレージボリュームの監視に使用されるべきサービスレベル目標（ＳＬＯ）の第１のタイプを、そのストレージボリュームについて動的に判断されシーケンシャルＩ／ＯであるかランダムＩ／Ｏであるかに関するＩ／Ｏタイプに基づいて決定する手段であるＳＬＯタイプ決定手段と、
   そのストレージボリュームについて、複数のタイプのＩ／Ｏパフォーマンス値のうち、前記決定された第１のタイプのＳＬＯに関連付けられた第１のタイプのＩ／Ｏパフォーマンス値であって、そのストレージボリュームの第１のタイプのＩ／Ｏパフォーマンス値に基づいて、前記決定された第１のタイプのＳＬＯ用の閾値を決定する手段である閾値決定手段と、
   そのストレージボリュームの監視に使用するべきものとして、前記決定された第１のタイプのＳＬＯおよび前記第１のタイプのＳＬＯ用の前記決定された閾値を表示する手段である表示手段と
   を備える管理コンピュータ。
2. 前記Ｉ／ＯタイプがランダムＩ／Ｏの場合、前記第１のタイプは、応答時間であり、
   前記Ｉ／ＯタイプがシーケンシャルＩ／Ｏの場合、前記第１のタイプは、データスループットレートである、
   請求項１に記載の管理コンピュータ。
3. 同じサーバにプロビジョニングされた１以上の第１のストレージボリュームからなるグループであるストレージグループを作成する手段であるストレージグループ作成手段と、
   前記ストレージグループの下に、前記１以上の第１のストレージボリュームのうちの１以上のストレージボリュームからなるグループであるモニタリンググループを作成する手段であるモニタリンググループ作成手段と
   を更に備える請求項１又は２に記載の管理コンピュータ。
4. 前記表示手段は、前記ストレージグループ内のモニタリンググループごとに、前記決定された第１のタイプのＳＬＯおよび前記第１のタイプのＳＬＯ用の前記決定された閾値を表示する、
   請求項３に記載の管理コンピュータ。
5. １以上のサーバに複数のストレージボリュームを提供するストレージシステムの管理方法であって、
   （ａ）前記ストレージシステムに接続された管理コンピュータが、ストレージボリュームについて動的に判断されシーケンシャルＩ／ＯであるかランダムＩ／Ｏであるかに関するＩ／Ｏタイプを基に、そのストレージボリュームについて、そのストレージボリュームの監視に使用されるべきサービスレベル目標（ＳＬＯ）の第１のタイプを決定し、
   （ｂ）前記管理コンピュータが、そのストレージボリュームについて、複数のタイプのＩ／Ｏパフォーマンス値のうち、前記決定された第１のタイプのＳＬＯに関連付けられた第１のタイプのＩ／Ｏパフォーマンス値であって、そのストレージボリュームの前記第１のタイプのＩ／Ｏパフォーマンス値に基づいて、前記決定された第１のタイプのＳＬＯ用の閾値を決定し、
   （ｃ）前記管理コンピュータが、そのストレージボリュームの監視に使用するべきものとして、前記決定された第１のタイプのＳＬＯおよび前記第１のタイプのＳＬＯ用の前記決定された閾値を表示する、
   管理方法。
6. 前記Ｉ／ＯタイプがランダムＩ／Ｏの場合、前記第１のタイプは応答時間であり、
   前記Ｉ／ＯタイプがシーケンシャルＩ／Ｏの場合、前記第１のタイプはデータスループットレートである、
   請求項５に記載の管理方法。
7. 前記管理コンピュータが、同じサーバにプロビジョニングされた１以上の第１のストレージボリュームからなるグループであるストレージグループを作成し、
   前記管理コンピュータが、前記ストレージグループの下に、前記１以上の第１のストレージボリュームのうちの１以上のストレージボリュームからなるグループであるモニタリンググループを作成する、
   請求項５又は６に記載の管理方法。
8. （ｃ）では、前記管理コンピュータが、前記ストレージグループ内の前記モニタリンググループごとに、前記決定された第１のタイプのＳＬＯおよび前記第１のタイプのＳＬＯ用の前記決定された閾値を表示する、
   請求項７に記載の管理方法。