JP2008537242A - ストレージリソースを割り振る方法および装置 - Google Patents

Abstract

【課題】 ストレージリソースを割り振る方法および装置を提供すること。
【解決手段】 ストレージイベントの発生を通知することにより、アプリケーションのストレージ可用性を調整する方法および装置が記載される。要件を変更する必要性が生じると、ネゴシエーションが引き起こされ、一連のネゴシエーションステージがストレージプロバイダサーバに提示される。送信されたネゴシエーションステージの各ストレージプロバイダ応答について、応答がネゴシエーションステージに記されている提案よりも良好であるか否かが判断される。良好である場合、アプリケーションはストレージの変更をコミットする。
【選択図】 なし

Description

本発明は、データストレージおよび冗長性の分野に関する。より詳細には、本発明は、ネゴシエーションプロセスを通してストレージリソース、たとえば多次元ディスクアレイを公正に割り振る手法に関する。

ストレージは、今日使用されている略あらゆるソフトウェアアプリケーションの極めて重要な構成要素である。ストレージ業界が成熟するにつれて、ストレージオプションの数およびデータ入力・検索のパフォーマンスの両方が増大した。ストレージオプションとしては、たとえば、磁気テープ、ハードディスクドライブ（ＨＤＤ）、ＣＤ−ＲＯＭ、および光媒体が挙げられる。ＨＤＤカテゴリには、たとえば、スタンドアロンＨＤＤ、ディスクアレイ、および複雑な仮想ストレージ環境が含まれる。

ディスクアレイは、たとえば、特にＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）０、ＲＡＩＤ １、ＲＡＩＤ ０＋１（向上した冗長性および性能を有する）、ＲＡＩＤ １＋５、およびＲＡＩＤ ５に分類することができる。仮想ストレージ環境はストレージエリアネットワーク（ＳＡＮ）を含む。各ストレージオプションにはコストおよびサービスレベルが関連し、これらは両方とも広く変化する。

アプリケーションによっては、たとえば、１つまたは複数のサーバにホストされるアプリケーションは、往々にしてアプリケーションの機能に対する需要の顕著な増大を受ける。これはＣＰＵ利用率、ネットワークトラフィック、および特にストレージの急速な変動に繋がり得る。時により、これら「ピーク」時間が周知であり、予定イベント、たとえば日付け、時間、および期間で識別することができることもあれば、スケジュールされず、いくらかの応答性が臨時で必要になることもある。

ストレージリソースを割り振る方法は、パフォーマンスレベルを監視することで開始される。パフォーマンスレベルが閾値を超える場合、要件の変更が行われたか否かについてがさらに判断される。要件の変更が行われていた場合、実施形態は、メタデータに記憶されているネゴシエーションステージセットから未使用ネゴシエーションステージを調べる。ネゴシエーションステージが存在する場合、未使用ネゴシエーションステージに基づいたサービスへの要求が行われ、要求はストレージプロバイダサーバに送られる。ストレージプロバイダはストレージプロバイダ応答を行う（または少なくとも行うように見える）。実施形態は、ＳＰ応答が許容できるものか否かを判断する。許容できる場合、実施形態はＳＰ応答に基づいてストレージの変更をコミットする。

本発明の例示的な実施形態について、これより単に例として添付図面を参照して説明する。

これより、図、特に図１を参照して、本発明を実施することができる、本発明の好ましい実施形態にいよるデータ処理システムの絵図表現を示す。コンピュータ１００が、システムユニット１０２、ビデオディスプレイ端末１０４、キーボード１０６、フレキシブルドライブ（ｆｌｏｐｐｙ ｄｒｉｖｅ）および他の種類の永続的および取り外し可能なストレージメディアを含むことができる記憶装置１０８、ならびにマウス１１０を含んで示される。さらなる入力装置、たとえばジョイスティック、タッチパッド、タッチスクリーン、トラックボール、マイクロホン等をパーソナルコンピュータ１００に含めてもよい。コンピュータ１００は、ニューヨーク州アーモンク（Ａｒｍｏｎｋ）に所在のＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎの製品であるＩＢＭ ｅＳｅｒｖｅｒ（Ｒ）コンピュータまたはＩｎｔｅｌｌｉＳｔａｔｉｏｎ（Ｒ）コンピュータ等の任意の適したコンピュータを使用して実施することができる。図示の表現にはコンピュータを示すが、本発明の他の実施形態は、ネットワークコンピュータ等の他の種類のデータ処理システムで実施することができる。コンピュータ１００は、好ましくは、コンピュータ１００内で動作するコンピュータ可読媒体に常駐するシステムソフトウェアにより実施することができるグラフィカルユーザインタフェース（ＧＵＩ）も含む。

これより図２を参照して、本発明を実施することができるデータ処理システムのブロック図を示す。データ処理システム２００は、本発明のプロセスを実施するコードまたは命令を置くことができる図１のコンピュータ１００等のコンピュータの例である。データ処理システム２００は、周辺機器相互接続（ＰＣＩ）ローカルバスアーキテクチャを利用する。図示の例ではＰＣＩバスを利用するが、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）およびＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）等の他のバスアーキテクチャを使用してもよい。プロセッサ２０２およびメインメモリ２０４は、ＰＣＩブリッジ２０８を通してＰＣＩローカルバス２０６に接続される。ＰＣＩブリッジ２０８は、プロセッサ２０２に一体化メモリコントローラ・キャッシュメモリを含むこともできる。ＰＣＩバス２０６へのさらなる接続は、直接構成要素相互接続を通して、またはアドインコネクタを通して行うことができる。図示の例では、ローカルエリアネットワーク（ＬＡＮ）アダプタ２１０、小型コンピュータシステムインタフェース（ＳＣＳＩ）ホストバスアダプタ２１２、および拡張バスインタフェース２１４が、直接構成要素接続によりＰＣＩローカルバス２０６に接続されている。これとは対照的に、オーディオアダプタ２１６、グラフィックスアダプタ２１８、およびオーディオ／ビデオアダプタ２１９が、拡張スロットに挿入されたアドインボードによりＰＣＩローカルバス２０６に接続される。拡張バスインタフェース２１４は、キーボード・モデムアダプタ２２０、モデム２２２、およびさらなるメモリ２２４に接続を提供する。ＳＣＳＩホストバスアダプタ２１２は、ハードディスクドライブ２２６、テープドライブ２２８、およびＣＤ−ＲＯＭドライブ２３０に接続を提供する。典型的なＰＣＩローカルバス実施態様は、３つまたは４つのＰＣＩ拡張スロットまたはアドインコネクタをサポートする。

オペレーティングシステムがプロセッサ２０２で実行され、図２のデータ処理システム２００内の各種構成要素を調整し、制御を提供するために使用される。。オペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ ＸＰ（Ｒ）等の市販のオペレーティングシステムであることができる。オペレーティングシステム、オブジェクト指向プログラミングシステム、およびアプリケーションまたはプログラムへの命令は、ハードディスクドライブ２２６等の記憶装置に配置され、メインメモリ２０４にロードしてプロセッサ２０２により実行することができる。

図２のハードウェアが実施態様に応じて変更可能であることを当業者は理解しよう。フラッシュ読み取り専用メモリ（ＲＯＭ）、同等の不揮発性メモリ、または光ディスクドライブ等の他の内部ハードウェアまたは周辺機器を、図２に示すハードウェアに加えて、またはこれに代えて使用することができる。また、本発明のプロセスはマルチプロセッサデータ処理システムに適用することも可能である。

たとえば、データ処理システム２００は、任意選択的にネットワークコンピュータとして構成されている場合、ＳＣＳＩホストバスアダプタ２１２、ハードディスクドライブ２２６、テープドライブ２２８、およびＣＤ−ＲＯＭ２３０を含まないことがある。この場合、コンピュータは、正しくはクライアントコンピュータと呼ぶべきであり、ＬＡＮアダプタ２１０、モデム２２２等のある種のネットワーク通信インタフェースを含む。別の例として、データ処理システム２００は、ある種のネットワーク通信インタフェースを有しているか否かに関わらず、ある種のネットワーク通信インタフェースに頼ることなく起動可能なように構成されたスタンドアロンシステムであってもよい。さらなる例として、データ処理システム２００は、ＲＯＭまたはフラッシュＲＯＭあるいはこの両方が構成されて、オペレーティングシステムファイルまたはユーザ生成データあるいはこの両方を記憶するための不揮発性メモリを提供する携帯情報端末（ＰＤＡ）装置であってもよい。

図２に示す例および上述した例は構造的な制限を示すものではない。たとえば、データ処理システム２００は、ＰＤＡの形態をとることに加えて、ノート型コンピュータまたはハンドヘルドコンピュータであってもよい。データ処理システム２００はキオスクまたはウェブアプライアンスであってもよい。

本発明のプロセスは、メモリ、たとえばメインメモリ２０４、メモリ２２４、または１つまたは複数の周辺機器２２６〜２３０内のメモリ等に配置することができる、コンピュータにより実施される命令を使用してプロセッサ２０２により行われる。

表１にメタデータ構造を示す。図２のコンピュータシステムの場合、１つ、多くの場合にはいくつかのネゴシエーションステージを有する１つのメタデータ構造がある。ネゴシエーションステージは少なくとも２つの要件のリストである。要件は通常、ストレージコンシューマの観点から提案の「良好度」を測定するために使用されるテストまたは基準の類いである。したがって、各パラメータ（表１の行に示されるような）を「良好に、またはより良く」しようと努める。これは、状況によっては、パラメータが基準を満たす以上でなければならないことを意味することもあれば、「以下」でなければならない場合もある。

パラメータは、長期に持続したレートまたはバースト基準のいずれかで測定されるデータスループットレートを含むことができる。他のパラメータは、１月であり得る契約期間またはネゴシエーション期間中の可用性パーセントであることができる。故障から回復するまでの時間がパラメータであり得る。「なし」、「オプション」、または「必要」のいずれかのバックアップの有無もさらなるパラメータであり得る。スペースもさらなるパラメータであり得る。ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）の中のアーキテクチャもパラメータであり得、要件は特に、ＲＡＩＤ ０、ＲＡＩＤ １、ＲＡＩＤ５の要件であり得る。

パラメータによっては良好性を測るものではないものがある。こういったパラメータとしては、時間範囲、日範囲、および次のネゴシエーションまでの遅延が挙げられる。

表１の最後の３行は、「利用毎」でのストレージの各種機能の通貨取引を示す。すなわち、課金される消費または利用毎に、後に請求書の作成に使用できる料金が課される。通貨単位に代えて、トークン課金を適用してもよいことが理解される。この場合、クレジットプールまたはトークンプールがいくつかのアプリケーション（本発明の個別の各実施形態）に割り振られる。各アプリケーションでは、各アプリケーションに構成されたトークンに制限されたトークンを有し、時により、共通管理チームにより補充がなされる。このような環境は、たとえば、本発明の実施形態を運用しているアプリケーションを実行するストレージプロバイダサーバおよび各種コンピュータを所有または制御する企業または他の共通法的エンティティに適する。したがって、各アプリケーション内でネゴシエーションステージの確立をガイドする（エンティティの代理人により）のは、トークンの相対希少性である。

図３は、本発明の例示的な実施形態によるネットワークのブロック図である。ストレージコンシューマ３０１が、図２のデータ処理システム２００等のデータ処理システムを使用して構築される実行中のアプリケーションをサポートすることができる。もちろん、ストレージコンシューマ３０１は、任意の適したデータ処理システムを使用して実施することができる。ストレージコンシューマ３０１はオペレーティングシステム３０３を実行することができ、オペレーティングシステム３０３は、時によりストレージコンシューマ３０１で実行することができる１つまたは複数のアプリケーション３０５にハードウェアリソースへの区分アクセスを提供することができる。アプリケーションは本発明の実施形態のステップを実行することができ、ネットワーク３１１を介してストレージプロバイダ３２１と通信することができる。同様に、ストレージプロバイダ３２１は、図２のデータ処理システム２００等のデータ処理システムにより構築されるハードウェアを操作することができる。オペレーティングシステム３２３はこのようなハードウェア上で動作することができ、１つまたは複数のアプリケーション３２５をサポートすることができる。ストレージプロバイダ３２１は単に、市販の広く入手可能なストレージ、たとえばｇｍａｉｌ．ｃｏｍ、ｐｈｏｔｏｂｕｃｋｅｔ．ｃｏｍ等、またはオンラインで利用可能な基本的なストレージを示す他の任意のサービスであってよい。

図４は、ストレージコンシューマで実行されるステップを示すフローチャートである。ストレージコンシューマは、データストレージ要件の変動に相関し得るパフォーマンスレベルを測定することができる。たとえば、ストレージコンシューマは、ローカルで実行されるアプリケーションがより多くまたはより少ないデータストレージを必要とすることを示唆し得るＣＰＵ利用率を測定することができる。別の例はネットワークスループットのシフトであり得る。さらに別の例は、発生し得る使用率シフト、たとえば、ある地理的領域が新年の祝賀を終えたときにウェブサイトで発生する小康状態を示し得る特定の時間の発生であり得る。ＣＰＵ利用率、ネットワークスループット、および時間でのこういった変化はパフォーマンスレベルの変化の例である。しかし、閾値を超えるパフォーマンスレベルが測定される場合、ストレージイベント（ステップ４０１）が発生すると考えられる。

ストレージイベントは予定イベントに基づいても発生し得る。したがって、予定イベントが検出されたときには代替のストレージイベントが発生する。特に、内部時間計測装置がイベントの発生を通知してもよく、またはデータ処理システム２００がネットワーク可用リソースを通して時間を判断してもよい。

ストレージイベントの検出後、実施形態（以下、「コンシューマ」と呼ぶ）は、現在利用可能な（またはコミットされている）リソースが、予期されるニーズを満たすのに十分であるか否かを評価する。すなわち、要件変更が発生したか否かを判断する（ステップ４０３）。判断が「いいえ」である場合、ストレージイベントの監視が続けられる。判断が「はい」の場合、実施形態は、メタデータ構造またはストレージ要件プロファイルに記憶されている少なくとも１つのネゴシエーションストレージの中から未使用ネゴシエーションステージを調べる（ステップ４０５）。未使用ネゴシエーションステージが、最近のステップ（ステップ４０５〜ステップ４１１）の繰り返しで使用されていなかったという観点から未使用である。未使用ネゴシエーションステージはその「良好性」に基づいて選択することができる。このようなネゴシエーションステージは順に使用することができ、最悪のネゴシエーションステージがステップ（ステップ４０５〜ステップ４１１）で使用されるときに使い果たされ得る。

実施形態は、未使用ネゴシエーションステージに基づいてサービスを要求することができる（ステップ４０７）。サービス要求は、未使用ネゴシエーションステージからのパラメータのうちの２つ以上を含むことができる。要求で「と同等に良好であるか、それよりも良好」または「以上」を使用する必要はない。これは、このような条件がストレージコンシューマの役割に潜在するため、すなわち、ストレージのユーザが、他のすべてが等しい場合に、ストレージ量が要求量よりも多いことを好むことは明白であるためである。したがって、要求は、未使用ネゴシエーションステージからのパラメータのうちの２つ以上を運ぶパケットまたは一連のパケットであることができる。要求は、１つまたは複数のパケットを形成するステップならびに図２からのＬＡＮアダプタ２１０を介してこのような１つまたは複数のパケットを送信することを含むことができる。ストレージコンシューマの要求（ステップ４０７）は、ストレージプロバイダのサービスページまたは既知のサービスパラメータページ条件に対して行われるｈｔｔｐ要求またはＳＯＡＰ要求であることができ、ｈｔｔｐ要求または簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）要求は、ネゴシエーションステージのパラメータをストレージプロバイダに伝達することができる。

ストレージプロバイダ（ＳＰ）が、サービスプロバイダ応答またはＳＰ応答を作成することができる。ＳＰ応答は要求を承認または許容することができる。ＳＰ応答は、要求内のパラメータ、すなわち許容指示をエコーバックすることができる。ＳＰ応答は１つまたは複数のパラメータを変更して、何をコミットしているのかを示すことができる。任意のイベントにおいて、コンシューマは応答を受け取ることが出来る（ステップ４０９）。要求は、ＳＰ応答としてストレージプロバイダからハイパーテキストマークアップページを返すことができる。必要に応じて、ストレージコンシューマは、応答の受信に関連してハイパーテキストマークアップをスクリーンスクレープして、該当する詳細、たとえば、ストレージ容量、提供期間等を選択する（ステップ４０９）。

コンシューマは、ＳＰ応答が要求パラメータと同等に良好であるか、またはそれよりも良好であるか否かを評価する、すなわち、ＳＰ応答が許容されるか否かを判断する（ステップ４１１）ことができる。許容されず、使用のネゴシエーションステージがまだある場合（ステップ４２１）、より多くのネゴシエーションステージが調べられる（ステップ４０５）。

最終的に、ＳＰ応答が許容される（ステップ４１１）ことが期待される。これは、すべてのパラメータが行われた任意の要求と同等に良好であるか、またはそれよりも良好である場合に発生することが分かっている。これが発生すると、コンシューマはストレージ変更をコミットする（ステップ４１３）。そして、このようにコミットされた変更は、要件変更が後に行われるか否かの判断のベースをなすことができる。ストレージ変更のコミットは、適当なストレージが次の２４時間期間にコミットされている限り、緑色ＬＥＤを発光させるのと同じくらい簡単なことであることができる。ストレージ変更のコミットにより、たとえば、ネットワークドライブを好ましい文字表示にマッピングすることにより、ある間隔で使用されることを意図されるストレージのネットワークロケーションの参照テーブルを確立することができる。ストレージをコミットすることは、プログラムを呼び出して登録詳細をストレージプロバイダの既知の登録ページに自動的に提供することを含むことができる。

ストレージ変更コミット（ステップ４１３）の終了に際して、実施形態のステップを終了することができる。このとき、メタデータ構造（表１）の任意のエントリまたは行が更新され、再び未使用状態になると考えられる。

緒利点の中でも、本発明は、変化している状況または予期される変化に対応することができ、認められるオペレータの介入なしでパラメータの中でも特に改訂されたストレージサイズ、速度、耐久性を得るように試みることができる。

本発明について十分に機能するデータ処理システムの文脈の中で説明したが、本発明のプロセスがコンピュータ可読媒体の命令の形態または種々の形態で配布が可能であり、本発明が配布の実行に実際に使用される信号搬送媒体の特定の種類に関係なく等しく適用されることを当業者が理解するであろうことに留意することが重要である。コンピュータ可読媒体の例としては、フレキシブルディスク、ハードディスクドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の記録可能型媒体、ならびに伝送形態、たとえば無線周波および光波伝送等を使用したデジタル通信リンク、アナログ通信リンク、有無線通信リンク等の伝送型媒体が挙げられる。コンピュータ可読媒体は、特定のデータ処理システムで実際に使用するために復号化された符号化フォーマットの形態をとってもよい。

本発明の説明は例示および説明のために提示され、網羅的である、すなわち本発明を開示された形態に限定することを意図するものではない。当業者には多くの変更および変形が明らかであろう。実施形態は、本発明の原理、実際の適用を最良に説明し、意図する特定の用途に合うように種々の変更を伴った各種の実施形態に関して当業者が本発明を理解できるようにするために選択され説明されたものである。

本発明の例示的な実施形態によるデータ処理システムを示す。 本発明の例示的な実施形態による構成要素パーツのうちのいくつかのブロック図を示す。 本発明の例示的な実施形態によるネットワークのブロック図である。 本発明の例示的な実施形態により要件およびストレージプロバイダサーバとの契約を時により更新するために実施形態が行うことができるステップを表現する流れ図を示す。

Claims (14)

1. ストレージイベントを検出するステップと、
   閾値を超えるパフォーマンスレベルを検出したことに応答して要件変更が発生したか否かを判断するステップと、
   要件変更が発生したとの判断に応答して、メタデータ構造に記憶されている少なくとも１つのネゴシエーションステージの中から未使用ネゴシエーションステージを調べるステップと、
   前記未使用ネゴシエーションステージに基づいてサービスを要求するステップと、
   サービスプロバイダ応答を受け取るステップと、
   前記サービスプロバイダ応答が許容されるか否かを判断するステップと、
   前記サービスプロバイダ応答に基づいてストレージ変更をコミットするステップと、
   を有するストレージリソースを割り振る方法。
2. 前記検出するステップは、
   パフォーマンスレベルを監視するステップと、
   前記パフォーマンスレベルが閾値を超えるか否かを検出するステップと、
   を有する、請求項１に記載のストレージリソースを割り振る方法。
3. 前記検出するステップは、
   予定イベントを検出するステップ
   を有する、請求項１に記載のストレージリソースを割り振る方法。
4. 前記未使用ネゴシエーションステージに基づいてサービスを要求するステップは、
   前記未使用ネゴシエーションステージはトークン課金を有する、前記未使用ネゴシエーションステージに基づいてサービスを要求するステップ
   を有する、請求項１に記載のストレージリソースを割り振る方法。
5. 前記ストレージプロバイダ応答が許容されるか否かを判断するステップの後に、
   前記サービスプロバイダ応答が許容されないとの判断に応答して、第２の未使用ネゴシエーションステージが存在するか否かを判断するステップと、
   前記第２の未使用ネゴシエーションステージが存在するとの判断に応答して、前記メタデータ構造に記憶されている前記少なくとも１つのネゴシエーションステージの中から前記第２の未使用ネゴシエーションステージを調べるステップと、
   前記第２の未使用ネゴシエーションステージに基づいてサービスを要求するステップと、
   第２のサービスプロバイダ応答を受け取るステップと、
   前記第２のサービスプロバイダ応答が許容されるか否かを判断するステップと、
   を有する、請求項１に記載のストレージリソースを割り振る方法。
6. 前記検出するステップは、
   パフォーマンスレベルを監視するステップと、
   前記パフォーマンスレベルが閾値を超えるか否かを検出するステップと、
   を有する、請求項５に記載のストレージリソースを割り振る方法。
7. 前記検出するステップは、
   予定イベントを検出するステップ
   を有する、請求項５に記載のストレージリソースを割り振る方法。
8. ストレージイベントを検出する手段と、
   閾値を超えるパフォーマンスレベルを検出したことに応答して要件変更が発生したか否かを判断する手段と、
   要件変更が発生したとの判断に応答して、メタデータ構造に記憶されている少なくとも１つのネゴシエーションステージの中から未使用ネゴシエーションステージを調べる手段と、
   前記未使用ネゴシエーションステージに基づいてサービスを要求する手段と、
   サービスプロバイダ応答を受け取る手段と、
   前記サービスプロバイダ応答が許容されるか否かを判断する手段と、
   前記サービスプロバイダ応答に基づいてストレージ変更をコミットする手段と、
   を有するストレージリソースを割り振る装置。
9. 前記検出する手段は、
   パフォーマンスレベルを監視する手段と、
   前記パフォーマンスレベルが閾値を超えるか否かを検出する手段と、
   を有する、請求項８に記載のストレージリソースを割り振る装置。
10. 前記検出する手段は、
    予定イベントを検出する手段
    を有する、請求項８に記載のストレージリソースを割り振る装置。
11. 前記未使用ネゴシエーションステージに基づいてサービスを要求する手段は、
    前記未使用ネゴシエーションステージはトークン課金を有する、前記未使用ネゴシエーションステージに基づいてサービスを要求する手段
    を有する、請求項８に記載のストレージリソースを割り振る装置。
12. 前記サービスプロバイダ応答が許容されないとの判断に応答して、第２の未使用ネゴシエーションステージが存在するか否かを判断する手段と、
    前記第２の未使用ネゴシエーションステージが存在するとの判断に応答して、前記メタデータ構造に記憶されている前記少なくとも１つのネゴシエーションステージの中から前記第２の未使用ネゴシエーションステージを調べる手段と、
    前記第２の未使用ネゴシエーションステージに基づいてサービスを要求する手段と、
    第２のサービスプロバイダ応答を受け取る手段と、
    前記第２のサービスプロバイダ応答が許容されるか否かを判断する手段と、
    を有する、請求項８に記載のストレージリソースを割り振る装置。
13. 前記検出する手段は、
    パフォーマンスレベルを監視する手段と、
    前記パフォーマンスレベルが閾値を超えるか否かを検出する手段と、
    を有する、請求項８に記載のストレージリソースを割り振る装置。
14. 前記検出する手段は、
    予定イベントを検出する手段
    を有する、請求項８に記載のストレージリソースを割り振る装置。

Images