(57)【特許請求の範囲】
【請求項１】
所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、
を備え、
前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するか否かを検出し、
前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、
ストレージシステム。
【請求項２】
請求項１に記載のストレージシステムであって、
前記目標値設定部は、検出した前記進捗状況が前記理想値を満たさず前記処理待ちタスクが存在しない前記処理部の前記進捗状況を、その処理部の前記目標値として設定する、
ストレージシステム。
【請求項３】
請求項１に記載のストレージシステムであって、
前記目標値設定部は、検出した前記進捗状況が前記目標値を超えている前記他の処理部の前記目標値を引き上げるよう設定する、
ストレージシステム。
【請求項４】
請求項１に記載のストレージシステムであって、
前記目標値設定部は、前記目標値を引き上げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き上げるよう設定する、
ストレージシステム。
【請求項５】
請求項１に記載のストレージシステムであって、
前記目標値設定部は、検出した前記進捗状況が前記目標値に満たない前記処理部に前記処理待ちタスクが存在している場合に、他の前記処理部の前記目標値を引き下げるよう設定する、
ストレージシステム。
【請求項６】
請求項５に記載のストレージシステムであって、
前記目標値設定部は、前記目標値を引き下げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き下げるよう設定する、
ストレージシステム。
【請求項７】
所定のタスクをそれぞれ実行する各処理部が実装された情報処理装置に、
前記各処理部による前記情報処理装置全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、
を実現させると共に、
前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するか否かを検出し、
前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、
ことを実現させるためのプログラム。
【請求項８】
所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出し、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定し、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御すると共に、
前記進捗状況の検出時に、前記各処理部に処理待ちタスクが存在するが否かを検出し、
検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージシステムにかかり、特に、複数のタスクを実行するストレージシステムに関する。
【背景技術】
【０００２】
ストレージシステムでは、書込み／読出し動作（ユーザーロード）と平行して、パリティデータの再構築、デフラグ、ガーベジコレクション等の様々なタイプのバックグラウンドタスクを実行する。通常、タスクの優先順位はシステムの状態に依存する。一般的には、ユーザが望むサービス品質を達成するために、ユーザーロードの優先順位が最も高い。障害が発生した場合は、期待される復元力レベルを回復するために、高い優先順位で、失ったパリティデータを再構築する必要がある（例えばRAIDの再構築）。復元力レベルとは、データを損失せずに耐えられる障害の数のことである。このような再構築の優先順位は、現在の復元力レベルによって異なる場合がある。記憶領域が不足しているシステムでは、書込み速度を遅くして開放されたリソースをガーベジコレクションに割り当てる必要がある。健全なシステムでも、ガーベジコレクションやデフラグといったメンテナンスタスクは、優先順位は低いが無くすべきでない。
【０００３】
ここで、以下では、「ロードタイプ」と「ロードソース」という表記を使用する。「ロードタイプ（以下「ロード」）」とは、類似する特徴を持つタスクのクラスを意味し、例えば、書込みタスク、バックグラウンドタスク等である。「ロードソース（「以下ソース」）」とは、特定のロードタイプのタスクを作成するシステムの一部を意味し、例えば、書込み／読出しの承認、またはバックグラウンドタスクの実行を行うソフトウェアの構成要素である。
【０００４】
ロードの優先順位の決定は、所定のポリシに従ってロードにリソースを分配する何らかのメカニズムによって実施される必要がある（非特許文献１，２）。また、このメカニズムは、システムを可能な限り最高のパフォーマンスで機能させ、優先順位の高いロードがその割り当て（シェア）を使用していない場合は、優先順位の低いロードの処理を加速するようにしなければならない。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】GULATI, A., AHMAD, I., AND WALDSPURGER, C. A. PARDA: ProportionalAllocation of Resources for Distributed Storage Access. In 7th USENIXConference on File and Storage Technologies (San Francisco, California, USA,February 2009).
【非特許文献２】LU, C., ALVAREZ, G. A., AND WILKES, J. Aqueduct: Online datamigration with performance guarantees. In FAST ’02: Proceedings of the 1stUSENIX Conference on File and Storage Technologies (Berkeley, CA, USA, 2002),USENIX Association, p. 21.
【非特許文献３】DUBNICKI, C., GRYZ, L., HELDT, L., KACZMARCZYK, M., KILIAN, W.,STRZELCZAK, P., SZCZEPKOWSKI, J., UNGUREANU, C., AND WELNICKI, M. HYDRAstor: aScalable Secondary Storage. In 7th USENIX Conference on File and Storage Technologies(San Francisco, California, USA, February 2009).
【発明の概要】
【発明が解決しようとする課題】
【０００６】
分散型ストレージシステムでは、システムのアーキテクチャの複雑性、システム固有の不均一性、またロードが予測不能であることから、リソースを制御するメカニズムの設計は困難な仕事である。複合的なシステムに関しては、特定のロードが使用するリソースの種類と量を予測する十分なモデルを定義することは、まずできない。ロードは必要とするリソースを動的に変更するため、ロードに対するリソースの静的割り当てといった簡易な解決策は現実的ではない。さらに、同じサーバに対する外部の処理によって、システム内のロードが利用可能なリソースの総量は時間と共に変化する。
【０００７】
また、ユーザにより書込みおよびバックグラウンドタスクの特徴がいずれも非常に多様であることも、この問題が複雑になる理由である。ユーザの書込みには限られた待ち時間が要求されることがあるが、通常は、重複排除、キャッシュ、および作業負荷の変動等の理由により、１つのブロック書込み時間を予測することができない。プリフェッチでは限られたメモリしか使用できないため、高いパフォーマンスを実現するには、ユーザの読出しにはよりいっそう低レイテンシが必要になる。
【０００８】
このため、本発明の目的は、上述した課題である、ストレージシステムにおいてリソースの効率的な使用を図り、システムの性能の向上を図ること、にある。
【課題を解決するための手段】
【０００９】
本発明の一形態であるストレージシステムは、
所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、
を備えた、
という構成をとる。
【００１０】
また、本発明の他の形態であるプログラムは、
所定のタスクをそれぞれ実行する各処理部が実装された情報処理装置に、
前記各処理部による前記情報処理装置全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、
を実現させるためのプログラムである。
【００１１】
また、本発明の他の形態である情報処理方法は、
所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出し、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定し、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する、
という構成をとる。
【発明の効果】
【００１２】
本発明は、以上のように構成されることにより、リソースの効率的な使用を図り、ストレージシステムの性能の向上を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】実施形態１における進捗割り当てポリシの一例を示す図である。
【図２】実施形態１におけるリソース管理の様子を示す図である。
【図３】実施形態１におけるリソース管理のアーキテクチャを示す図である。
【図４】実施形態１におけるアルゴリズム１を示す図である。
【図５】実施形態１におけるアルゴリズム２を示す図である。
【図６】実施形態１における進捗割り当てポリシの一例を示す図である。
【図７】実施形態１における実験結果を示す図である。
【図８】実施形態１における実験結果を示す図である。
【図９】実施形態１における実験で想定される進捗割り当てを示す図である。
【図１０】実施形態１における実験結果を示す図である。
【図１１】実施形態２におけるストレージシステムを含むシステム全体の構成を示すブロック図である。
【図１２】実施形態２におけるストレージシステムの構成の概略を示すブロック図である。
【図１３】実施形態２におけるストレージシステムの構成を示す機能ブロック図である。
【図１４】図１３に開示したストレージシステムにおけるデータ記憶処理の様子を説明するための説明図である。
【図１５】図１３に開示したストレージシステムにおけるデータ記憶処理の様子を説明するための説明図である。
【図１６】図１３に開示したストレージシステムにおけるデータ読み出し処理の様子を説明するための説明図である。
【図１７】実施形態２におけるストレージシステムの動作を示すフローチャートである。
【図１８】本発明の付記１におけるストレージシステムの構成を示すブロック図である。
【発明を実施するための形態】
【００１４】
＜実施形態１＞
本願では、システム内における高レベルなリソースの利用を確かなものにする一方、異種のロード間で動的にリソースを分配するメカニズムについて述べる。ここで述べるアプローチは、ロードの抽象的概念に基づくものであり、利用するリソースや特定のタイプのロードの処理を仮定することはない。特に、ロードは異なるタイプの複数のオブジェクトによって処理され、各々が同じリソースを得るために競い合うことがある。
【００１５】
本願で提案する方法は、ロードが利用するリソースを比例配分するのではなく、ロードを比例的に進捗させることである。ユーザの視点で考えると、ユーザはリソース消費といった内部で実施されることの詳細よりも、ロードの影響と進捗に関心を持つため、このようなアプローチが好ましい。また、このようなアプローチは、システムの観点からも好ましい。その理由は、精密なリソース配分や計算は、複雑なシステム、特に分散型のシステムには問題が多いからである。このため、本願では、バックグラウンドタスクを含む異種のロードまで対象を広げた。
【００１６】
異種のロードの進捗を制御するために、各ロードが進捗インジケータを有し、他のロードの進捗と比較できるようにした。ほとんどのタスクはデータに対して動作するため、このようなインジケータは、ロードに関連するタスクによって生成されるスループット、つまり処理データの総量を経過時間で割った値、として選択することができる。例えば、書込み要求のスループットは、１秒当たりのディスクに保存されるデータ量である。データに対する動作ではないタスクについては、そのタスクによって達成される進捗を推定する人為的な値をスループットとして使用してもよい。
【００１７】
同じスループットを持つタスクでも、システムに対する負荷が異なる場合がある。他のタスクよりもはるかに重いタスク、つまり、同量のリソースでは進捗がはるかに遅くなるタスクもある。そのようなタスクは、高い進捗を得るために膨大な量のリソースを消費しなければならず、他のタスクの実行を遅延させたり、場合によっては阻害することもある。このような影響を減らすために、任意の加重により、かかるタスクのスループットを人為的に増加させることができる。ここからは、ロードのスループットについて、ロードタイプに関連する加重を加えたスループットと理解する。また、進捗については様々な測定基準があるが、スループットによって測定すると仮定とする。
【００１８】
コアアルゴリズムは、所定のポリシに従ってロード間でリソースを分配する。ポリシは、進捗割り当て、つまりシステムの総スループットを既存のロード間で分配する比率、を特定する。このポリシはシステムの状態に応じて動的に変化することがある。
【００１９】
（例１）図１に進捗ポリシの一例を示す。これらの進捗割り当て（シェア）により、数１式を満たすロードのスループットを達成することを目的とする。つまり、各ロードタイプによって生成されるスループットが各進捗割り当てに比例することが目的となる。
【００２０】
【数１】
0005500256.tif 000002
【００２１】
上記のように、ロードの進捗を制御するメカニズムは、システム内のリソースが最大限に使用される状態を維持する。あるロードが自身の進捗配分を消費できない場合（例えばアプリケーションのシステムへの書込みスループットが低い、またはメンテナンスタスクを実行する必要がない場合）、他のタイプの進捗が加速されるため、システム内の全リソースが使用される。
【００２２】
（例２）図１の進捗ポリシについて検討する。ロードタイプ１が進捗全体の２５％しか消費できない場合、残りの２５％はロードタイプ２とロードタイプ３に対して、ポリシに比例して分配される。その結果、ロードタイプ２には４５％（３０％＋１５％）、ロードタイプ３には３０％（２０％＋１０％）が分配される。
【００２３】
条件の変化に対して十分な反応時間を取ることは重要である。その理由は、特定のロードのリソース消費と利用可能なリソースは常に変動するからである。このような変動の主な原因は、時間と共にポリシとロードが変化することである。さらに、制御されているシステムの外部で行われる処理も、システムのロードが利用可能なリソースに影響を与える。
【００２４】
リソース分配メカニズムの高レベル構造を図２に示す。すべてのロードソースは、各々、出力された「制限値」を通じて各自の処理速度を制御する許可制御メカニズム（Admission Control Mechanism：ＡＣＭ）を持つ。「制限値」（実施形態２における「目標値」）は、ソースによって生成されるスループットに影響を与えるため、「制限値」の引き上げまたは引き下げは、スループットにおける同様の変化を誘発する。例えば、「制限値」は、ロードのスループットの上限値、または、特定のロードタイプの同時に実行されるタスク数の制限値、などである。
【００２５】
進捗ポリシに定められたスループットの比率を達成するため、アルゴリズムは定期的に各ロードのスループットを測定し、その「制限値」の現在値を調整する。
【００２６】
本願は、以下のように構成されている。まず、本願における新しいアルゴリズムを説明する。次に、アルゴリズムの要素について詳細に述べる。次に、企業向けストレージシステムであるＨＹＤＲＡｓｔｏｒ（非特許文献３）でのタスクのスケジューリングに関する具体的な問題と、このシステムに実装している本願の解決策について説明する。次に、ＨＹＤＲＡｓｔｏｒで行った実験の結果を提示し、この解決策の主な特性を証明する。次に、関連技術を我々のアプローチと対比させて説明し、最後に、結論を述べる。
【００２７】
［リソース管理メカニズム］
ここでは、リソース管理メカニズムの構成と、異なるタイプのロードを制御して、進捗ポリシに定める比率でそれらのスループットを維持するコアアルゴリズムについて説明する。
【００２８】
［アーキテクチャ］
リソース管理メカニズムは、以下の部分によって構成される（図２参照）。
「１．許可制御メカニズム（ＡＣＭ）」：あらゆるロードタイプと関連付けられたソフトウェアユニットで、「制限値」を通じてソースの処理速度を制御する。「制限値」が大きいとは、上記で説明したように、対応するロードソースがより高速で動作できることを意味する。ロードに関して、ＡＣＭは、ソースのスループットを含む「情報」と、ソース内で実行を待っている「タスクの有無の指標」と、を集める。ＡＣＭの情報については後に詳細に説明する。
【００２９】
「２．フィルタ」：スループット等の値の変動を排除するために、ＡＣＭから受信した情報の平滑化を行う機能を持つ。簡易なフィルタでは所定の期間で平均化することがある。
【００３０】
「３．アルゴリズム」：上述したようにロードソースの現状を記述するすべてのＡＣＭからのフィルタリングされた情報を用いて、各ロードタイプについて、「制限値」の引き上げ、引き下げ、または現状維持を決定する。
【００３１】
「４．コントローラ」：アルゴリズムの決定を受信し、そのＡＣＭに関する「制限値」の正確な値を計算する。
【００３２】
このアルゴリズムは、定期的に（本願で実施したのは１０秒毎。この期間は最長の分割不能タスクの長さに基づく）すべてのＡＣＭから「情報」を収集し、「決定」を下し、それを適切なコントローラに提供する。コントローラは「制限値」の新たな値を計算し、それをＡＣＭに提供する。
【００３３】
すべてのサイクルにおいて、進捗の実際の分配（実施形態２における「進捗状況」）を（進捗ポリシが示す）所望のもの（実施形態２における「理想値」）に近づけるよう「制限値」（実施形態２における「目標値」）が修正される。進捗の分配から進捗ポリシによる分配への収束速度と、システムの安定性と、はトレードオフの関係にある。
【００３４】
［飽和検出］
ロードソースの処理速度を上げるために、アルゴリズムはそのＡＣＭの「制限値」を引き上げる。しかし、タスクを処理するサーバのリソースは限られているため、ある一定のレベルを超えてロードタイプのパフォーマンスを高めることはできない。
【００３５】
（例３）ＡＣＭの「制限値」を、スループットの上限値と定義する。毎秒Ｔバイトを処理する能力を持つサーバについて考えてみると、ＡＣＭの「制限値」がＴより高くなっても、対応するロードソースはＴの速度で動作する。そのサーバで外部の処理が行われている場合、またはそのサーバが他のロードも処理している場合、システムはもっと少ないタスクしか処理できない（例えばｔバイト（ｔ＜Ｔ）とする）。このような状況では、「制限」値が上がってもロードソースはｔ以下の速度で動作する。
【００３６】
（例４）「制限値」を、並行して実行できるタスク数の上限と定義する。サーバは、いくつでも並行してタスクを許可することが可能だが、一定の値を超えて「制限値」を上げてもスループットが増えるわけではなく、ページングや頻繁なコンテキストのスイッチングにより、スループットが低下することすらある。最大のスループットをもたらす可能性がある最小限の値をｎとする。制限値をｎより大きくしても、実際のスループットに何ら影響はない。ｎの値は一定ではなく、システム内で平行して実行されている他のタスクによって変化する。
【００３７】
上記例３と例４のいずれでも、スループットを低下させずにそのロードの他の性能（例えばレイテンシ（待ち時間）、メモリ消費等）を改善する制約を導入することができる。例３では、システムが現在処理しているデータ量を制限することができる。このような制約は、パフォーマンスに影響を与えずに、スラッシングを排除しメモリ消費を削減する。例４では、同時タスクについて、レイテンシが所定の定数Ｌを下回った状態を維持することで、同時タスク数ｎを制御することができる。ＡＣＭにｎよりも大きい制限値Ｎが与えられている場合でも、ソースは（レイテンシ制限を守るために）ｎを使用する。例３と同様に、サーバで外部の処理が行われている場合、またはサーバが他のタイプのタスクを処理している場合、サーバが処理できる同時要求はさらに少なくなる（レイテンシ制限）。
【００３８】
すべてのロードソースに対して、システム内の進行中のロードに関するこのような制約を導入できると仮定する。このような制約があると、システムでリソースが不足した場合、ソースは所定の「制限値」に達しないこともあるが、「制限値」が低いものとして動作する（ＡＣＭが制限に達しなかった、という）。あるタイプのタスクのリソースが不足し、そのために制限値にかかわらず所望の速度に達することができない状態をリソース飽和（または単に飽和）という。本願では、各ＡＣＭが飽和によってロードの動作が非常に遅い状態を検出できるものと仮定する。
【００３９】
ロードは飽和の場合だけでなく、十分な仕事がない場合も制限に達しない。例えば、バックグラウンドタスクについては、実行するバックグラウンドタスクがほとんどない場合、またユーザーロードについては、システムに対する外部のアプリケーションの書込みのスループットが低い場合に発生する。
【００４０】
［ＡＣＭ情報］
各ＡＣＭからアルゴリズムへ送信される情報は、以下のフィールドで構成される。
【００４１】
「limit（制限値）」：上述した処理速度の制限。この値はアルゴリズムによって事前に設定され、アルゴリズムをステートレスにする場合のみ返送される。
【００４２】
「hasWaitingWork（実行待ち作業あり）」：ソースに実行待ちタスクがあることを示す（例５参照）。近い将来の作業量は現在の量と類似すると仮定する。ソースに実行待ち作業がある場合は、「limit」を引き上げるか、またはリソースを増やす（他のソースの「limit」を引き下げる）ことで、その処理速度を上げることができる。
【００４３】
「throughput（スループット）」：前回の情報収集以降に、対応するロードタイプのタスクによって生成されるスループット。これは進捗インジケータである（上記参照）。
【００４４】
「limitAchieved（制限値達成）」：ロードタイプが「制限値」に達したかどうかを示す（例６参照）。上述したように、リソース不足（飽和）または処理がないために、ソースが制限まで使用されないこともある。
【００４５】
（例５）：「hasWaitingWork」がどのように計算されるかを見るために、バッファからのタスクを処理するソースについて検討する。タスクは、ＡＣＭの「制限値」が許可し、追加のリソース制約がない場合に、バッファからシステムへ送信される。リソース制約とは、例えばシステム内に利用可能なメモリがない、処理される要求のレイテンシが長すぎる（例４参照）、またはシステム内の実行中のロードが所定値を超えている（例３参照）、等である。このようなモデルでは、「hasWaitingWork」はバッファ内で待っている要求があるかどうかを示す。
【００４６】
（例６）「limitAchieved」がどのように計算されるかについて、以下の２つのケースを検討する。「制限値」がスループットの上限値である場合（例３参照）、「limitAchieved」は、前回の情報が回収された以降のいずれかの時点で、次の等式が満たされる場合にのみ「真」である。
throughput = limit
【００４７】
「制限値」が同時に実行されるタスク数の上限値である場合（例４参照）、「limitAchieved」は前回の情報が回収された以降のいずれかの時点で次の等式が満たされる場合にのみ「真」である。
ｎ = limit
【００４８】
ロードソースにシステムに出すタスクがない場合（その場合、「hasWaitingWork」は偽）、またはロードソースが十分なリソースを取得しない場合（既に飽和）に、「limitAchieved」は偽となる。
【００４９】
［アルゴリズム］
アルゴリズムは、ＡＣＭから収集した情報を用いて、各ロードソース用の「制限値（limit）」の引き上げ、引き下げ、または現状維持をすべきかを推論する。この決定に基づき、コントローラが各「制限値」の新たな値を計算する。
【００５０】
アルゴリズムによる決定は、システムが飽和状態かどうかに依存する。あるロードタイプに関して、「hasWaitingWork」が「真」に設定され「limitAchieved」が「偽」に設定されている場合、飽和状態と診断される。つまり、このロードソースには実行すべき作業があり、その「制限値」は高速化を許可しているが、リソース不足により速度を上げることができないことを意味する。したがって、処理速度を上げるためには、他のタイプのロードの「制限値」を下げるべきである。一方、システムが飽和状態でない場合（各ロードに作業がない、または所定の「制限値」に達していない場合）、アルゴリズムは少なくとも１つのロードの「制限値」を引き上げる（補助定理２参照）。
【００５１】
このアルゴリズムの骨格を、図４のアルゴリズム１に示す。入力として、ＡＣＭから収集した情報と、進捗割り当てマップであるポリシを取る。最初の３ステップで、ローカル変数を初期化する。ステップ４と５で現在の進捗割り当てをカウントする。ステップ６〜８では、変数「someoneHasWork」を初期化する。以降のステップについては次のサブセクションで説明する。
【００５２】
［目標割り当て（targetShares）の再計算］
ステップ１０で、アルゴリズムは、待ち作業のないロードの割り当てを、待ち作業のあるロードに分配する。待ち作業のないロードにはそれらが利用する割り当てのみが残され、残りの部分は待ち作業のあるロードに分配される。このような割り当ての再計算は、リソースを最大限に利用し、進捗の分配を修正するために行われる。これについては、上述した例２で記載しており、またその詳細を以下に説明する。
【００５３】
ロードタイプＬに待ち作業がなく、現在の割り当て（currentShare）がポリシで定められるものよりも低い場合（hasWaitingWork＝偽、および、currentShare < policyShare）、このロードは全てのシェアを使うことができない。targetShareは、次のように現在の割り当てに設定される。
targetShares[L] = currentShares[L]
上記以外の場合（currentShares ≧ policyShares、または、hasWaitingWork＝真）
targetShares[L] = policyShares[L]
【００５４】
最初のケースでは、スペアの割り当て：（policyShares[L] - currentShares[L]）は、他のタイプのロード間で、それらのpolicySharesにしたがって分配される。
【００５５】
ロードタイプｌは、currentShares[l] ≦ targetShares[l]の場合、より多くのリソースを得る資格がある。待ち作業がある少なくとも１つのロードタイプは、より多くのリソースを得る資格があり、これは次の不変式で正式に表現される。
【００５６】
（補助定理１）「hasWaitingWork＝真」のロードタイプがある場合、その内の少なくとも１つはcurrentShare ≦ targetShareである。
【００５７】
（証明）待ち作業なし（hasWaitingWork＝偽）のあらゆるタイプのロードは、targetShare ≦ currentShareである（targetShares計算のルールにおいて、currentShare <
policyShareとcurrentShare ≧ policyShareとの２つの場合を別々に検討する）。これは以下の数２式を意味する。
【００５８】
【数２】
0005500256.tif 000003
【００５９】
また、全targetSharesの合計は、全currentSharesの合計に等しい（つまり１００％）ため、以下の数３式が成り立つ。
【００６０】
【数３】
0005500256.tif 000004
【００６１】
ここで、「hasWaitingWork＝真」の少なくとも１つのロードタイプについて、currentShare ≦ targetShareであることが明らかである。
【００６２】
この補助定理を用いて、アルゴリズムによってシステムが常に完全ロード状態を維持することを後述する。
【００６３】
targetSharesを計算したら、アルゴリズムは「決定（decision）」を下して、対応するタイプのロードのスループットがこれらの割り当てに比例するよう「制限値（limit）」を更新する。
【００６４】
［制限引き上げの試み］
ステップ１２〜１５で、アルゴリズムはいくつかのロードの「limit」の引き上げを試みる。アルゴリズムは、いくつかのロードの「limit」を引き上げることによって何らかの効果を得られ、その引き上げがポリシの観点から適切である場合にのみ引き上げを試みるため、（「limit」の引き上げに関して）欲張りだと考えられる。「limit」の引き上げのためには、ロードは次のすべてを満たす必要がある。（１）リソースが必要である（hasWaitingWork）、（２）より多くのリソースを受ける資格がある（currentShare ≦ targetShare）、（３）「limit」に達している（limitAchievedが真）。
【００６５】
最初の２つの条件は直感的である。３番目の条件はアルゴリズムが効果のない動作を行わないようにするためである。上記で説明したように、「hasWaitingWork」が「真」で、そのソースが所定の「limit」に達することができない場合は、システムが飽和状態にあり「limit」を引き上げても効果はないと思われることを意味する。
【００６６】
ここで、補助定理１を用いて次の不変条件を証明する。
（補助定理２）システム内に作業がある場合（少なくとも１つのロードタイプに待ち作業がある場合）、システムが既に飽和状態にあるか、または、あるロードタイプの「limit」が引き上げられる。
【００６７】
（証明）システム内にいくつかの作業があると仮定し、作業があるロードタイプについて検討する。その内のいずれか１つで「limitAchieved＝偽」である、つまりシステムが既に飽和状態にあるか、またはすべてのロードで「limitAchieved＝真」である。２番目のケースでは、補助定理１を用いて、次のすべての数式を満たすロードタイプｌが少なくとも１つあると推論する。
hasWaitingWork[l]＝真
limitAchieved[l]＝真
currentShares[l] ≦ targetShares[l]
したがって、アルゴリズムはlの「limit」を引き上げる。
【００６８】
［制限引き下げの試み］
いかなるソースについても制限が引き上げられなかったがタスクを作成できるロードがある場合は、システムが飽和状態にあることを意味する（補助定理２参照）。この場合、リソースの消費が過剰なロードについては、ステップ１７〜２０で引き下げられる。開放されたリソースは他のロードによって取得される。
【００６９】
（例７）例２に戻り、ロードタイプ２のcurrentShareが２０％でロードタイプ３のcurrentSharesが５５％であり、実行を待つ両ロードタイプのタスクがある（hasWaitingWork＝真）と仮定する。targetShares（２５％−４５％−３０％）によると、ロードタイプ２の動作が遅すぎる。そこでアルゴリズムは次の２つのいずれかの決定を下す。
【００７０】
・ロードタイプ２の「limit」を引き上げる−ロードタイプ２が所定の「limit」を満たしている場合（limitAchieved）はこの決定がなされる。
・他のロードの「limit」を引き下げる−ロードタイプ２が既に所定の「limit」を満たすことができない場合はこの決定がなされる。ロードタイプ３がtargetShareにより与えられる速度よりも速く作業を行っているため、アルゴリズムはロードタイプ３の「limit」を引き下げる。
【００７１】
［コントローラへの決定送信］
ステップ２２と２３では、「decision（決定）」、「currentShare」、「targetShare」、および「old limit（旧制限値）」をコントローラへ送信し、コントローラが「limit」の正確な値を計算する（以下参照）。
【００７２】
［制限の正確な値を探す］
上記で説明したアルゴリズムは、各ソースに関して、制限の引き上げ、引き下げ、また現状維持を決定する。この決定は、コントローラによって特定の「limit」の値に変換される。このようなコントローラは様々な方法で実装が可能である。本願では、図５に示すアルゴリズム２に示す方法を用いる。
【００７３】
本願で提案する実装方法では、差異｜targetShare - currentShare｜およびいくつかの定因数αに比例して「limit」を変更する。このように、現在の進捗分配が望ましい分配と大きく異なる場合は変更も大きく、直ちに適切な割り当てへと収束する。各ステップにおいて、あるロードタイプの全体的な進捗の割合は、そのtargetShareに近くなる。進捗分配が収束すると、「limit」に対する変更は小さくなる（これにより「limit」の変動が抑制される）。
【００７４】
定数αは、変更がどの程度急激に行われるかを決定する。αが大きければ収束は早くなるが、システムが不安定になる恐れがある。αが小さければ安定性は改善するが、所望の値への収束が遅くなる。我々の実験では、α＝０．２を選択した。
【００７５】
［アルゴリズムのプロパティ］
アルゴリズムは以下のプロパティを含む。
１．十分な作業がある場合は、システムを完全にロードされた状態に維持する。これは補助定理２から直接得られる結論である。システムが飽和状態にあるか、またはいくつかのロードタイプの「limit」が引き上げられる。
２．システムが飽和状態にある場合は、全体的な進捗の分配をtargetShareに向けて修正する。currentShare < targetShareのロードタイプについて検討する。各ステップにおいて、そのロードタイプの「limit」が引き上げられるか、または他のロードタイプの「limit」が引き下げられる。いずれの場合でもリソースが増える。類推により、currentShare > targetShareであるロードタイプのリソースが減少する。
３．システムが飽和状態でない場合は、すべてのロードがフルスピードで処理される。
【００７６】
［コントローラの設計］
上記では、望ましい進捗分配とリソースの最大活用を実現するための一般的な解決策を説明してきた。ここでは、リソース管理メカニズムの反応時間を改善するコントローラの更なるメカニズムについて説明する。
【００７７】
［制限引き下げの高速化］
「limit」の引き下げが直ちに実行されない以下の例について検討する。
（例８）ソースの「limit」がスループットの上限であると定義する。以下のシーケンスについて検討する。
【００７８】
１．ソースには作業があり、それはシステム内で作業がある唯一のロードである。そのため「limit」が引き上げられる（例えば制限値５０ＭＢ／秒）。
２．ソースがタスクを終了したため、作業がなくなった。制限値は５０ＭＢ／秒のままである。
３．しばらくの後、ソースは作業が開始したが、もはやシステム内で唯一のロードではない。その結果、待ち作業がある。制限値は５０ＭＢ／秒のままだが、作業のスループットは２５ＭＢ／秒である（高速で作業を行うためのリソースがない）。
【００７９】
ここで、アルゴリズムがこのソースの「limit」を例えば４５ＭＢ／秒に引き下げても、実際は２５ＭＢ／秒の速度で作業を行っているため、ソースの作業速度に影響を与えない。アルゴリズムが数サイクルした後に「limit」が２５ＭＢ／秒を下回り、ソースの作業速度に影響を与え始める。
【００８０】
例８に示す状況は、targetSharesへの収束速度に著しい効果をもたらすことがあるため、何らかの改良を加えることは有益である。以下に他の解決策を２つ示す。
【００８１】
［スループットを「limit」付近で維持］
コントローラは、「limit」を常にソースの作業の現在速度近くに維持するよう目指すことができる。「limit」がスループットの制限値の場合（例３参照）、現在のスループットよりもあまり大きくならないよう「limit」の修正を試みる。例えば次の通り。
【数４】
0005500256.tif 000005
【００８２】
「limit」が同時処理タスク数の制限値である場合（例４参照）、「limit」をシステム内における現在の同時タスク数ｎの近くに維持するよう目指す。例えば次の通り。
【数５】
0005500256.tif 000006
αとβの値は反応時間を満たすように選択されている。本願のシステムでは、αは１．２に設定し、βは各ソース毎に個別に選択する。
【００８３】
［制限を現在速度に引き下げる］
「limit」を値Ｌに引き下げたいと仮定する（例８では、Ｌ＝４５ＭＢ／秒）。Ｌが、ソースの処理の現在速度よりも大きい場合、「limit」を現在速度の値まで引き下げなければならない（例８では２５ＭＢ／秒）。「limit」がスループットの制限値の場合は、次の通りである。
【数６】
0005500256.tif 000007
「limit」が同時進行タスク数の限度である場合は次の通り。
【数７】
0005500256.tif 000008
【００８４】
［制限引き上げの高速化］
「limit」を小さな値（例えば１）から大きな値（例えば１００００）に引き上げることを検討する。アルゴリズム２では、引き上げステップは「oldLimit」に比例することがわかる。したがって、このような変更には多大なサイクル数が必要であるため、反応時間に関して満足できるものではない。我々は、制限値が低い場合の収束速度を改善する最小制限（minLimit）を定めることを決定した。
【数８】
0005500256.tif 000009
【００８５】
［ＨＹＤＲＡｓｔｏｒでのアルゴリズム］
ＨＹＤＲＡｓｔｏｒ（非特許文献３）は、企業向け市場を対象とした拡張性のある高性能分散型コンテンツアドレスストレージシステムである。このシステムは、分散型ハッシュテーブルの周囲に構築されたストレージノードのグリッドであるバックエンドと、フロントエンドとで構成される。各ストレージノードは読出し／書込み要求の処理を担当する。このシステムは重複排除に対応しているため、書込み要求の中には、データブロックのディスク上への保存によるオーバーヘッドをもたらさないものもある。ユーザによる書込みおよび読出し要求とは別に、バックエンドでは、障害後のデータ再構築、デフラグ、早期のエラー検出のためのデータスクラビング、ノード間でのデータのバランス調整、またはガーベジコレクションとスペース再利用、といったバックグラウンドのタスクを実行する。バックグラウンドのタスクには各々差別化された特徴があり、また重要である。
【００８６】
ＨＹＤＲＡｓｔｏｒでは、異なるタイプのタスクのスケジューリングを行うために適応性のある高レベルリソース管理を利用している。ＨＹＤＲＡｓｔｏｒでは主に、ユーザ要求（書込みおよび読出し）、データ削除（除去するためのブロックのマーキング）、およびバックグラウンドタスク（再構築、デフラグ、スペース再利用等）、という３つのクラスのタスクがある。１つのストレージノードは、同じリソースを使用してあらゆる種類のタスクを同時に実行することができるが、それらは異なるソフトウェア構成要素によって扱われる。ＨＹＤＲＡｓｔｏｒ内のタスクのモデルを作るのは難しい。
【００８７】
［書込みと読出し］
ＨＹＤＲＡｓｔｏｒでの書込みと読出しは、様々なリソース（ディスク、ＣＰＵ、メモリ、ネットワーク）を用いて、いくつかの構成要素によって処理される。書込みでは、データストリームをブロックに分割し、重複を排除し、ブロックを圧縮し、圧縮したブロックを冗長符号化してフラグメント群を作成し、そのフラグメントを適切なストレージノードに保存する必要がある。重複排除機能により、既に保存されているブロックについては、圧縮、冗長符号化、保存を行う必要がない。重複排除をより機能させるために様々なサイズのブロックがあるため、１つの要求の処理に関するオーバーヘッドは常に同じではなく、予測するのは難しい。このシステムは、いくつかのレベルのキャッシュを用いる。これも、書込みと読出しの要求の負荷の予測を困難にする原因である。また１つの要求に対する反応時間が所定値を下回ることが要求されるため、書込みと読出しの要求はこのシステム固有のものである。
【００８８】
［バックグラウンドタスク］
ＨＹＤＲＡｓｔｏｒでは、ユーザによる書込みと読出しに加えて、一連のメンテナンスタスクがある。これらはユーザに対して透過的であり、バックグラウンドで実行され、パリティデータの再構築、スペース再利用（削除のマークが付けられたブロックの除去）、デフラグ等のタスクが含まれる。バックグラウンドタスクでのリソース消費は多様である。
【００８９】
デフラグ等については、大きなデータブロック上で動作を実行し、主にハードディスク上にロードを出す。また、メタデータの同期等、非常に小さなチャンク上で動作し他のリソースよりも比較的多くのＣＰＵを消費するものもある。またタスクには様々な優先順位のものがある。重要なデータ再構築は、デフラグやスペース再利用よりも優先順位が高い。一方、システムにスペースが不足している場合は、スペース再利用の優先順位が高くなる。
【００９０】
システム内でタスクのスケジューリングを行う際、簡単な解決策は、より高い優先順位がないときにだけ、与えられた優先順位でタスクを実行することである。ＨＹＤＲＡｓｔｏｒでは、実行する特定のバックグラウンドタスクを選択する際にこのアプローチが採用された。しかし、優先順位が最も高いバックグラウンドタスクがある場合でも、他のロードタイプ（例えばユーザーロード）を停止させてはならない。
【００９１】
バックグランドタスクは、読出し／書込み動作よりもはるかに長時間を要し、開始したら先回りして回避することができない。読出し／書込みのトップパフォーマンスに対する影響を削減し、ユーザーロードでの変動に耐えられるように、バックグラウンドタスクは、空きリソースが検出されたときに徐々に開始する必要がある。
【００９２】
［削除］
ＨＹＤＲＡｓｔｏｒのアーキテクチャと重複排除機能により、データの削除は、かなりの計算能力を必要とする、別個の非常に複雑なプロセスとなっている。このシステムでは、他のバックグラウンドタスクやユーザの読出し／書込みと平行して削除を実行することができる。
【００９３】
［状態依存型のリソース分配］
ＨＹＤＲＡｓｔｏｒのポリシは、システムの状態の変化に伴って変わる。例えば、データの復元レベルが著しく損なわれる障害発生後は、重要な再構築ポリシが有効となり、バックグラウンドタスクに大きな割り当てが与えられる。システムの状態に依存する進捗割り当てを表す様々なポリシを図６に示す。リソース管理アルゴリズムは、常に現状に対応するポリシを使用する。
【００９４】
［ローカルアーキテクチャ］
ＨＹＤＲＡｓｔｏｒは分散型のシステムである。各ノードは、ローカルで動作するリソース管理メカニズムのインスタンスを含む。しかし、タスクの中には複数のノードのリソースを使用するものもある。そのようなタスクは同期する必要があるため、関与するすべてのノード上で同じ速度で実行される。各々のノードは計算能力も利用できるリソースも異なることがあるため、複数のノードに関わるタスクは、あるノード上で他のノードでの計算を待たなければならない場合がある。その結果、かかるタスクはポリシで保証された速度よりも遅い速度で実行される場合がある。しかし、すべてのノードが同じポリシを持つ限り、すべてのタスクは、少なくとも１つのノード上でポリシにしたがって進捗割り当てを与えられる。
【００９５】
あるタスクに関して、速度の遅いリモートノードと同期する必要があるため、あるノードがポリシで与えられている速度よりも遅い速度でそのタスクを実行する場合は、リソースを最大限に利用するために、そのローカルノードは他のタスク（もしあれば）を実行する。
【００９６】
［実験評価］
ここでは、ＨＹＤＲＡｓｔｏｒシステムを使用して行った２つの実験の結果を説明する。この実験により、リソース管理メカニズムに関して次の２つの主な特徴が判明した。
（１）このアルゴリズムは常にシステム能力を完全に利用する。（２）リソースが飽和状態の場合、進捗分配はポリシが定めるものに近くなる。
【００９７】
［実験の設定］
すべての実験でＨＹＤＲＡｓｔｏｒの４サーバ構成を使用した。各サーバは、２つのクアドコア、６４ビット、３．０ＧＨｚのＩｎｔｅｌ  Ｘｅｏｎプロセッサ、２４ＧＢのメモリ、１２のＲＰＭ  Ｈｉｔａｃｈｉ  ＨＵＡ７２１０１ＡＣ３Ａ  ＳＡＴＡディスクを含み、すべてのサーバでＬｉｎｕｘカーネル２．６．１８を使用した。各サーバは２つの論理的ストレージノードを含む。
【００９８】
実験は、所定のスループットでシステムに書込みを行うよう構成されたアプリケーションを用いて行われた。また、このアプリケーションは、このシステムで可能な最高速度で動作するよう構成されている（レイテンシ制限による。上記参照）。
【００９９】
［リソースの最大活用］
最初の実験は、書込みタスクがシステム内のすべてのリソースを消費しない場合、バックグラウンドタスクを開始してリソースを完全に利用することを示している。
【０１００】
この実験では、書込みとバックグラウンドタスクとの２つのロードタイプのタスクを生成した。書込みの特徴は３回変化した。最初の３０分間は、外部のアプリケーションがフルスピードで動作して１ノード当たり５５ＭＢ／秒に達した。３０分の時点で構成が変更されてアプリケーションは４０ＭＢ／秒で一定のスループットを生成した。６０分の時点では、書込み速度が再び変更されて１０ＭＢ／秒になった。そして９０分の時点では、書込み速度を４５ＭＢ／秒に設定したが、重複データが含まれていた。ユーザの書込みの処理と平行して、システムはデフラグも実行していた。システム内には膨大なデータがあるため、常に実行待ち状態のデフラグのタスクがあった。
【０１０１】
このテストでは、図６の「データデフラグポリシ」（Data defragmentation）を使用した。これは、進捗全体が、ユーザによる書込みとデータ削除の間でのみ分配されることを意味する。この実験ではデータ削除を行わないため、進捗は１００％ユーザ書込みに与えられることになる。バックグラウンドタスクは、システム内に使用されないリソースがある場合にのみ実行される。
【０１０２】
この実験の結果を図７に示す。このプロットは、ユーザの書込みのスループット（最後の期間では総書込みスループットと非重複データスループットに分けられている）と１つのストレージノードからのバックグラウンドタスクを示している。図８は、プロセッサとハードディスクの利用状態を示しており、書込みの各フェーズでのボトルネックリソースが特定される。
【０１０３】
最初の期間である０〜３０分では、書込みアプリケーションがフルスピードで動作しており、バックグラウンドタスクはあまり行われていなかった。このフェーズではプロセッサがボトルネックであった。第２の期間である３０〜６０分では、アプリケーションの動作が遅くなり、使用されていないリソースがバックグラウンドタスクに割り当てられた。バックグラウンドタスクは著しく進捗し、この実験では書込みのスループットに影響はなかった。このフェーズではハードディスクがボトルネックであった。ハードディスクはレイテンシ制約内で最大限に利用されていたからである。第３の期間である６０〜９０分では、アプリケーションの動作が更に遅くなっても、バックグラウンドタスクはより高いスループットを達成した。このフェーズでは、同時に実行される書込みタスクが減少したため、限られたレイテンシを容易に維持することができた。その結果、ハードディスクをほぼ１００％利用することができた。第４の期間である９０〜１２０分では、書込みは、スループットの高さにかかわらずシステムに与える負荷が小さかったため（ほぼすべての書込みが重複）、バックグラウンドタスクは再び高速になった。
【０１０４】
バックグラウンドタスクが達成した最大スループットである１１０ＭＢ／秒がユーザーロードによって達成されたスループットよりも高いことを考えると、書込み動作はデフラグのタスクよりも重いことがわかる。この違いは、上記で説明したスケーリング要因を用いることで修正することができる。ＨＹＤＲＡｓｔｏｒでは、修正を行わずに実際のスループットを用いることに決定した。
【０１０５】
［ポリシの変更］
２つ目の実験は、現在のポリシを変更するものである。システムに書込みを行う外部のアプリケーションは、実験期間全体に渡ってフルスピードで動作するよう構成されていた。最初の１時間は、システムはデフラグのタスクを実行したので、図６の「データデフラグ」ポリシを使用した。次に、６０分の時点で、１つのストレージノードで障害が発生してシステムがポリシを「通常の再構築」（Normal reconstruction）に変更してデータの再構築を始めるシミュレーションを行った。その２５分後（８５分の時点）、データの削除を開始した。これはポリシの変更を伴わないが、システム内に新たなロードタイプが出現した。
【０１０６】
書込みとバックグラウンドのタスクは常に待ち作業があり、削除は第３フェーズにしか待ち作業がないことを考えると、３つのテストステップにおいて、次のような進捗分配が想定された。
１．第１の期間（０〜６０分）：書込みに１００％。
２．第２の期間（６０〜８５分）：書込みに７１．５％（５０％＋５／７×３０％）、バックグラウンドタスクに２８．５％（２０％＋２／７×３０％）。つまり、削除のシェアの３０％が５：２の比率で書込みとバックグラウンドのタスクに分配される。
３．第３の期間（８５〜１４０分）：書込みに５０％、バックグラウンドタスクに２０％、データ削除に３０％。
【０１０７】
図９は想定される進捗分配、図１０は１つのストレージノード上でのユーザによる書込み、バックグラウンドタスク、およびデータ削除によって達成されるスループットを示す。その結果である進捗分配（書込み−バックグラウンドタスク−削除）は、第１の期間では９５％−５％−０％、第２の期間では７６％−２４％−０％、第３の期間では４８％−２１％−３１％であった。
【０１０８】
［関連技術］
制御理論の応用に関する新たなトレンドは、モデルベースの解決策の利用を促すものである。しかし、本願のシステムでは、タスクは、リソース消費だけでなく、レイテンシ制限、限られたメモリ、または分散型の実行といった他の要件についても、差別化された性質を持つ。本願のシステムの複雑なアーキテクチャと、それによって正確なモデリングが不可能であることを考え、本願では適応高レベルリソース分配の導入を決定した。
【０１０９】
分散型ストレージシステムにおけるタスクのスケジューリングの問題点には共通性があり、頻繁に取り上げられている。入手可能な多くの文献では、同じタイプのタスク間でのリソースの分配に関する問題、または既知のサイズのパケットのスケジューリングに関する問題に対処している。本願における研究は、ユーザーロードとバックグラウンドタスクとの間でリソースを分配する問題に対処している。これらのタスクは特徴が異なるため、他の問題よりもはるかに複雑である。他の既存の解決策は、アイドル期間にバックグラウンドタスクを実行するよう試みている。しかし、サーバが常にユーザの要求を処理し、バックグラウンドタスクがユーザの活動と平行して効果的に実行される場合、そのような方法は適切ではない。
【０１１０】
タスクのスケジューリングに関する既存の解決策の多くは、待ち行列のメカニズムであるＹＦＱ、ＳＦＱおよびＦＳＦＱ、またはそれを改変したものを使用している。各ロードソースは、タスクをキューに入れる。そのタスクは適切なキューから取り出され、所望の進捗分配が行われるようシステムに送信される。我々のシステムの場合、このアプローチの問題点は適切なサイズのキューを維持することである。これは、タスクが差別化された特徴を持つ場合は特に困難である。また、待ち行列のメカニズムでは、メモリオーバーヘッドの追加や要求レイテンシの増加が発生し、これはＨＹＤＲＡｓｔｏｒのようなシステムでは許可できない。また、待ち行列のメカニズムではタスクモデルが必要であり、我々のケースでは、例えば何個の要求を平行して処理できるのか、といったパフォーマンスに関する質問に対する明確な回答を提供することができない。
【０１１１】
待ち行列理論の適用とレイテンシ制限に基づくフィードバック制御ループを組み合わせる解決策もあるが、標準的な待ち行列は、同時に処理するタスクの数を決定するメカニズムで強化されているため、レイテンシに関する要件は満たされる。しかし、これらの解決策は、類似する特徴を持つタスク間でのリソース分配に関するものである。
【０１１２】
異なる性質を持つタスクでのリソース分配は、仮想化によって達成されることが多い。各仮想マシンは、適切なクラスのタスクを実行する単一のアプリケーションを採用している。仮想マシンはアプリケーション間でＣＰＵサイクルを正確に分配することができるが、このようなアプローチはアーキテクチャ上および実装上の制約をもたらし、パフォーマンスのオーバーヘッドが著しく大きくなる。
【０１１３】
［結論と今後の研究］
本願では、異なるロードタイプのタスク間でリソースを分配する新しいメカニズムを提示した。この新たなアプローチは、タスクの抽象的概念に基づくものであり、それらの特徴に関する推測を回避している。したがって、システムのアーキテクチャが複雑なためモデル定義の標準的な方法では失敗する、分散型システムに適する。このメカニズムは、商用システムであるＨＹＤＲＡｓｔｏｒに実装され、制御されたシステムが高性能を達成することに焦点が当てられている。理論上の検討においても、また実験の評価においても、このアルゴリズムはシステムの飽和状態を維持すること、つまりリソースを最大限に利用することが確認されている。実験によれば、制御されたシステムは安定性があり（スループットにもオーバーシュートにも深刻な変動がない）、進捗の分配はポリシが定める所望のものに収束する。また、反応時間も条件を満たしている。実験では、新たな進捗分配およびワークロードの変更に適応するまでの時間が合理的であることがわかった。結論として、適応高レベルリソース管理は高性能な同時計算サーバに適している。
【０１１４】
今後は、システムの安定性を維持しつつメカニズムの反応時間をさらに減少させるために、コントローラの設計における制御理論の利用に関する研究を行う予定である。
【０１１５】
＜実施形態２＞
本発明の第２の実施形態を、図１１ないし図１７を参照して説明する。図１１は、システム全体の構成を示すブロック図である。図１２は、ストレージシステムの概略を示すブロック図であり、図１３は、構成を示す機能ブロック図である。図１４ないし図１７は、ストレージシステムの動作を説明するための説明図である。
【０１１６】
ここで、本実施形態では、ストレージシステムが上述したＨＹＤＲＡｓｔｏｒといったシステムであり、複数台のサーバコンピュータが接続されて構成されている場合を説明する。但し、本発明におけるストレージシステムは、複数台のコンピュータにて構成されることに限定されず、１台のコンピュータで構成されていてもよい。
【０１１７】
図１１に示すように、本発明におけるストレージシステム１０は、ネットワークＮを介してバックアップ処理を制御するバックアップシステム１１に接続している。そして、バックアップシステム１１は、ネットワークＮを介して接続されたバックアップ対象装置１２に格納されているバックアップ対象データ（記憶対象データ）を取得し、ストレージシステム１０に対して記憶するよう要求する。これにより、ストレージシステム１０は、記憶要求されたバックアップ対象データをバックアップ用に記憶する。
【０１１８】
そして、図１２に示すように、本実施形態におけるストレージシステム１０は、複数のサーバコンピュータが接続されて構成を採っている。具体的には、ストレージシステム１０は、ストレージシステム１０自体における記憶再生動作を制御するサーバコンピュータであるアクセラレータノード１０Ａと、データを格納する記憶装置を備えたサーバコンピュータであるストレージノード１０Ｂと、を備えている。なお、アクセラレータノード１０Ａの数とストレージノード１０Ｂの数は、図１２に示したものに限定されず、さらに多くの各ノード１０Ａ，１０Ｂが接続されて構成されていてもよい。
【０１１９】
さらに、本実施形態におけるストレージシステム１０は、データを分割及び冗長化し、分散して複数の記憶装置に記憶すると共に、記憶するデータの内容に応じて設定される固有のコンテンツアドレスによって、当該データを格納した格納位置を特定するコンテンツアドレスストレージシステムである。このコンテンツアドレスストレージシステムについては、後に詳述する。
【０１２０】
なお、以下では、ストレージシステム１０が１つのシステムであるとして、当該ストレージシステム１０が備えている構成及び機能を説明する。つまり、以下に説明するストレージシステム１０が有する構成及び機能は、アクセラレータノード１０Ａあるいはストレージノード１０Ｂのいずれに備えられていてもよい。なお、ストレージシステム１０は、図１２に示すように、必ずしもアクセラレータノード１０Ａとストレージノード１０Ｂとを備えていることに限定されず、いかなる構成であってもよく、例えば、１台のコンピュータにて構成されていてもよい。さらには、ストレージシステム１０は、コンテンツアドレスストレージシステムであることにも限定されない。
【０１２１】
図１３に、ストレージシステム１０の構成を示す。この図に示すように、ストレージシステム１０は、ストレージシステム１０の動作を制御する制御装置２０と、データを記憶する記憶装置３１と、を備えている。そして、制御装置２０は、上記実施形態１におけるロードソースに対応しそれぞれ所定のタスクを実行する複数の処理部２１，２２，２３を備えている。例えば、制御装置２０は、各処理部２１，２２，２３として、記憶装置３０に対するデータの記憶及び読み出し動作を制御するデータ記憶再生処理部２１と、使用されなくなり削除するブロックデータを検出するデータ削除処理部２２と、データツリーの再構築やデフラグ・領域再利用処理などのバックグラウンドタスクを実行するバックグラウンドタスク処理部２３と、を備えている。
【０１２２】
また、制御装置２０は、ストレージシステム１０内で上述した各処理部２１，２２，２３に対する様々なリソース（ディスク、ＣＰＵ、メモリ、ネットワーク等）の割り当てを分散させる構成として、進捗状況検出部２４と、目標値設定部２５と、処理動作制御部２６と、を備えている。
【０１２３】
なお、実際には、上記制御装置２０内の各部２１〜２６は、図１２に示したアクセラレータノード１０Ａ及びストレージノード１０Ｂが備えているＣＰＵ（Central Processing Unit）などの複数の演算装置にプログラムが組み込まれることで構成され、特に、各部２４〜２６は、ストレージノード１０Ｂに構成されている。また、記憶装置３１は、主にストレージノード１０Ｂが備えている記憶装置にて構成されている。
【０１２４】
なお、上記プログラムは、例えば、ＣＤ−ＲＯＭなどの記憶媒体に格納された状態でストレージシステム１０に提供される。あるいは、上記プログラムは、ネットワーク上の他のサーバコンピュータの記憶装置に記憶され、当該他のサーバコンピュータからネットワークを介してストレージシステム１０に提供されてもよい。
【０１２５】
以下、制御装置２０が備える各部２１〜２６の構成について詳述する。はじめに、データ記録再生処理部２１によるコンテンツアドレス方式のブロックデータ単位におけるストリームデータの記憶及び読み出し方法を、図１４ないし図１６を参照して説明する。
【０１２６】
まず、データ記録再生処理部２１は、図１５の矢印Ｙ１に示すように、ストリームデータであるバックアップ対象データＡの入力を受けると、図１４及び図１５の矢印Ｙ２に示すように、当該バックアップ対象データＡを、所定容量（例えば、６４ＫＢ）のブロックデータＤに分割する。そして、このブロックデータＤのデータ内容に基づいて、当該データ内容を代表する固有のハッシュ値Ｈ（内容識別情報）を算出する（矢印Ｙ３）。例えば、ハッシュ値Ｈは、予め設定されたハッシュ関数を用いて、ブロックデータＤのデータ内容から算出する。なお、このデータ記録再生処理部２１による処理は、アクセラレータノード１０Ａにて実行される。
【０１２７】
そして、上記データ記録再生処理部２１は、バックアップ対象データＡのブロックデータＤのハッシュ値Ｈを用いて、当該ブロックデータＤが既に記憶装置３０に格納されているか否かを調べる。具体的には、まず、既に格納されているブロックデータＤは、そのハッシュ値Ｈと格納位置を表すコンテンツアドレスＣＡが、関連付けてＭＦＩ（Ｍａｉｎ  Ｆｒａｇｍｅｎｔ  Ｉｎｄｅｘ）ファイルに登録されている。従って、データ記録再生処理部２１は、格納前に算出したブロックデータＤのハッシュ値ＨがＭＦＩファイル内に存在している場合には、既に同一内容のブロックデータＤが格納されていると判断できる（図１５の矢印Ｙ４）。この場合には、格納前のブロックデータＤのハッシュ値Ｈと一致したＭＦＩ内のハッシュ値Ｈに関連付けられているコンテンツアドレスＣＡを、当該ＭＦＩファイルから取得する。そして、このコンテンツアドレスＣＡ（アドレスデータ）を、記憶要求にかかるブロックデータＤのコンテンツアドレスＣＡとして記憶する。あるいは、既に格納されているブロックデータＤを参照するコンテンツアドレスＣＡをさらに参照する他のアドレスデータをツリー構造にて記憶する。これにより、このコンテンツアドレスＣＡにて参照される既に格納されているデータが、記憶要求されたブロックデータＤとして使用されることとなり、当該記憶要求にかかるブロックデータＤは記憶する必要がなくなる。
【０１２８】
また、データ記録再生処理部２１は、は、上述したように重複チェック部２３にてまだ記憶されていないと判断されたブロックデータＤを圧縮して、図１５の矢印Ｙ５に示すように、複数の所定の容量のフラグメントデータに分割する。例えば、図１４の符号Ｄ１〜Ｄ９に示すように、９つのフラグメントデータ（分割データ４１）に分割する。さらに、データ記録再生処理部２１は、分割したフラグメントデータのうちいくつかが欠けた場合であっても、元となるブロックデータを復元可能なよう冗長データを生成し、上記分割したフラグメントデータ４１に追加する。例えば、図１４の符号Ｄ１０〜Ｄ１２に示すように、３つのフラグメントデータ（冗長データ４２）を追加する。これにより、９つの分割データ４１と、３つの冗長データとにより構成される１２個のフラグメントデータからなるデータセット４０を生成する。なお、上記データ記録再生処理部２１による処理は、ＷＩと呼ばれる１つのストレージノード１０Ｂによって実行される。
【０１２９】
そして、データ記録再生処理部２１は、上記フラグメント生成部２４にて生成されたデータセットを構成する各フラグメントデータを、記憶装置３１に形成された各記憶領域に、それぞれ分散して格納する。例えば、図１４に示すように、１２個のフラグメントデータＤ１〜Ｄ１２を生成した場合には、１２個の記憶装置３１内にそれぞれ形成したデータ格納ファイルＦ１〜Ｆ１２（データ格納領域）に、各フラグメントデータＤ１〜Ｄ１２を１つずつそれぞれ格納する（図１５の矢印Ｙ６参照）。
【０１３０】
また、データ記録再生処理部２１は、上述したように記憶装置３１に格納したフラグメントデータＤ１〜Ｄ１２の格納位置、つまり、当該フラグメントデータＤ１〜Ｄ１２にて復元されるブロックデータＤの格納位置を表す、コンテンツアドレスＣＡを生成して管理する。具体的には、格納したブロックデータＤの内容に基づいて算出したハッシュ値Ｈの一部（ショートハッシュ）（例えば、ハッシュ値Ｈの先頭８Ｂ（バイト））と、論理格納位置を表す情報と、を組み合わせて、コンテンツアドレスＣＡを生成する。そして、このコンテンツアドレスＣＡを、ストレージシステム１０内のファイルシステム、つまり、アクセラレータノード１０Ａに返却する（図１５の矢印Ｙ７）。すると、アクセラレータノード１０Ａは、バックアップ対象データのファイル名などの識別情報と、コンテンツアドレスＣＡとを関連付けてファイルシステムで管理する。
【０１３１】
また、データ記録再生処理部２１は、ブロックデータＤのコンテンツアドレスＣＡと、当該ブロックデータＤのハッシュ値Ｈと、を関連付けて、各ストレージノード１０ＢがＭＦＩファイルにて管理する。このように、上記コンテンツアドレスＣＡは、ファイルを特定する情報やハッシュ値Ｈなどと関連付けられて、アクセラレータノード１０Ａやストレージノード１０Ｂの記憶装置３０に格納される。
【０１３２】
さらに、データ記録再生処理部２１は、上述したように格納したバックアップ対象データを読み出す制御を行う。例えば、ストレージシステム１０に対して、特定のファイルを指定して読み出し要求があると（図１６の矢印Ｙ１１参照）、まず、ファイルシステムに基づいて、読み出し要求にかかるファイルに対応するハッシュ値の一部であるショートハッシュと論理位置の情報からなるコンテンツアドレスＣＡを指定する（図１６の矢印Ｙ１２参照）。そして、データ記録再生処理部２１は、コンテンツアドレスＣＡがＭＦＩファイルに登録されているか否かを調べる（図１６の矢印１３参照）。登録されていなければ、要求されたデータは格納されていないため、エラーを返却する。
【０１３３】
一方、読み出し要求にかかるコンテンツアドレスＣＡが登録されている場合には、上記コンテンツアドレスＣＡにて指定される格納位置を特定し、この特定された格納位置に格納されている各フラグメントデータを、読み出し要求されたデータとして読み出す（図１６の矢印Ｙ１４参照）。このとき、各フラグメントが格納されているデータ格納ファイルＦ１〜Ｆ１２と、当該データ格納ファイルのうち１つのフラグメントデータの格納位置が分かれば、同一の格納位置から他のフラグメントデータの格納位置を特定することができる。
【０１３４】
そして、データ記録再生処理部２１は、読み出し要求に応じて読み出した各フラグメントデータからブロックデータＤを復元する（図１６の矢印Ｙ１５参照）。さらに、データ記録再生処理部２１は、復元したブロックデータＤを複数連結し、ファイルＡなどの一群のデータに復元して、読み出し制御を行っているアクセラレータノード１０Ａに返却する（図１６の矢印Ｙ１６参照）。
【０１３５】
また、上記データ削除処理部２２は、「ガーベジ識別処理」といった、使用されなくなったブロックデータを識別する処理を行う。例えば、記憶装置３１に記憶されているブロックデータ（メタデータを含む）が他の上位階層のメタデータから参照されている数である被参照数をカウントし、被参照数が「０」である全く参照されていないブロックデータを検出する。
【０１３６】
また、上記バックグラウンドタスク処理部２３は、上述したように被参照数が「０」となったブロックデータを解放して記憶領域を再利用する処理や、デフラグなどのバックグラウンドタスクを実行する。
【０１３７】
次に、上記進捗状況検出部２４、目標値設定部２５、処理動作制御部２６の構成及び動作について、図１７のフローチャートを参照して説明する。
【０１３８】
上記進捗状況検出部２４は、上述したデータ記録再生処理部２１、データ削除処理部２２、バックグラウンドタスク処理部２３といった各処理部による処理の進捗状況を、それぞれ検出する（ステップＳ１）。各処理部２１，２２，２３の進捗状況とは、例えば、各処理部のスループットであり、ストレージシステム１０全体の処理量に対する各処理部２１，２２，２３のそれぞれの処理量の割合である。
【０１３９】
また、進捗状況検出部２４は、上記進捗状況を検出する際に、各処理部２１，２２，２３から、当該各処理部２１，２２，２３に処理待ち状態となっているタスク（処理待ちタスク）が存在するか否かも検出する。また、進捗状況検出部２４は、後述する目標値設定部２５にて各処理部２１，２２，２３にそれぞれ設定された処理動作の目標値を取得する。
【０１４０】
このように、進捗状況検出部２４は、各処理部２１，２２，２３から、スループットである進捗状況と、処理待ちタスクの有無と、設定されている目標値と、をそれぞれ取得して、目標値設定部２５に渡す。なお、進捗状況検出部２４は、上述した各処理部２１，２２，２３以外の他の処理部から上述した進捗状況などの情報を検出してもよく、さらに他の情報を検出してもよい。
【０１４１】
続いて、上記目標値設定部２５は、上記進捗状況検出部２４から渡された各情報に基づいて、各処理部２１，２２，２３の処理状態の目標値を設定する（ステップＳ２）。このとき、目標値の設定は、さらに各処理部２１，２２，２３の進捗状況について予め設定された各理想値に基づいて行われる。このため、目標値設定部２５は、各処理部２１，２２，２３の進捗状況の理想値を記憶している。例えば、各処理部２１，２２，２３が理想とするスループットの値（ストレージシステム全体の処理量に対する各処理部における処理量の割合）を記憶している。
【０１４２】
ここで、上記目標値は、例えば、各処理部の進捗状況と同様に、当該各処理部のスループットである。つまり、目標値は、ストレージシステム全体の処理量に対する各処理部による処理量の割合を表す値の上限値として設定される。但し、目標値は、各処理部のスループットの上限値であることに限定されず、各処理部が実行可能なタスク数の上限値であってもよい。
【０１４３】
具体的に、目標値設定部２５は、まず、特定の処理部に着目し、当該特定の処理部から取得した進捗状況が当該特定の処理部に対して設定されている理想値に満たない場合であり、当該特定の処理部に処理待ちタスクが存在しない場合を考える。この場合には、特定の処理部に処理待ちタスクが存在しないため、現在の進捗状況が理想値に満たないが、進捗状況をこれ以上引き上げる必要はない。従って、この特定の処理部の現在の進捗状況の値を、当該特定の処理部の処理状態の目標値として設定する。なお、このとき、特定の処理部の目標値は、設定されている値のまま、つまり現状維持としてもよい。
【０１４４】
そして、上述したように、特定の処理部が理想値に満たない状態で作動している場合には、当該特定の処理部にて利用されるリソースが余ることとなる。すると、この余ったリソースを、特定の処理部とは異なる他の処理部にて利用されるよう分配可能となる。従って、目標値設定部２５は、他の処理部の処理状態の目標値を、現在値よりも引き上げて設定する。特に、上記進捗状況検出部２４による傑出結果に基づいて、処理待ちタスクが存在する他の処理部の目標値を引き上げて設定する。
【０１４５】
このとき、上記目標値設定部２５は、他の処理部について進捗状況検出部２４にて検出した現在の進捗状況が、当該他の処理部に現在設定されている目標値を超えている場合に、当該他の処理部の目標値を引き上げて設定する。さらにこのとき、他の処理部について検出した現在の進捗状況と、当該他の処理部に現在設定されている目標値と、の差の絶対値に、所定の係数（例えば、「０．２」の値）をかけた値だけ、目標値を引き上げるよう設定する。
【０１４６】
また、目標値設定部２５は、目標値を引き上げる他の処理部が複数存在する場合には、特定の処理部に対して余ったリソースを、複数の他の処理部にそれぞれ設定された各理想値の割合に対応して分配するよう、当該他の処理部の目標値をそれぞれ設定してもよい。つまり、複数の他の処理部の理想値の割合に対応する値だけ、それぞれ他の処理部の目標値を引き上げてもよい。
【０１４７】
また、目標値設定部２５は、上述したように進捗状況検出部２４から取得した情報に基づいて、処理部の目標値を引き下げて設定する場合もある。例えば、特定の処理部に着目し、この特定の処理部から取得した進捗状況が当該特定の処理部に設定されている目標値に満たない場合であり、当該特定の処理部に処理待ちタスクが存在している場合を考える。この場合には、特定の処理部に処理待ちタスクが存在するものの、他の処理部にてリソースが使用されているため、特定の処理部の進捗状況が目標値までも達していないことが考えられる。従って、この特定の処理部の現在の進捗状況を増大させるべく、他の処理部の目標値を引き下げるよう設定する。これにより、他の処理部の進捗状況が低下し、その分のリソースが特定の処理部に割り当てられることが期待される。
【０１４８】
このとき、他の処理部の目標値は、当該他の処理部について検出した現在の進捗状況と、当該他の処理部に現在設定されている目標値と、の差の絶対値に、所定の係数（例えば、「０．２」の値）をかけた値だけ、目標値を引き下げるよう設定してもよい。
【０１４９】
そして、上記処理動作制御部２６は、各処理部２１，２２，２３の処理状態、つまり、進捗状況が、上述したように目標値設定部２５にて設定された目標値となるよう、当該各処理部２１，２２，２３の処理状態を制御する（ステップＳ３）。例えば、ある処理部の進捗状況であるスループットが目標値に満たない場合には、かかるスループットが目標値に近づくようその処理部により多くのリソースを割り当てる。一方、ある処理部の進捗状況であるスループットが目標値を超えている場合には、かかるスループットが目標値に近づくようその処理部に割り当ててられているリソースを減らす。
【０１５０】
以上のように、各処理部の処理状態、例えば進捗状況であるスループットの目標値を変更して設定することで、進捗状況を徐々に理想値に近付けることができ、ストレージシステム全体のリソースの有効利用を図りつつ、理想の処理状態にすることができる。また、ロード間でスループット比率のバランスを取ることにより、システムの性能向上を図ることができる。
【０１５１】
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージシステム（図１８参照）、プログラムを記憶した記憶媒体、情報処理方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。
【０１５２】
（付記１）
所定のタスクをそれぞれ実行する各処理部１１０が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部１２１と、
検出した前記各処理部１１０の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部１１０の処理状態の目標値を設定する目標値設定部１２２と、
前記各処理部１１０の処理状態が設定した前記目標値となるよう当該各処理部１１０の処理状態を制御する処理動作制御部１２３と、
を備えたストレージシステム１００。
【０１５３】
（付記２）
付記１に記載のストレージシステムであって、
前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するが否かを検出し、
前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、
ストレージシステム。
【０１５４】
（付記３）
付記２に記載のストレージシステムであって、
ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、
前記目標値設定部は、検出した前記進捗状況が前記理想値を満たさず前記処理待ちタスクが存在しない前記処理部の前記進捗状況を、その処理部の前記目標値として設定する、
ストレージシステム。
【０１５５】
（付記４）
付記２に記載のストレージシステムであって、
ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、
前記目標値設定部は、検出した前記進捗状況が前記目標値を超えている前記他の処理部の前記目標値を引き上げるよう設定する、
ストレージシステム。
【０１５６】
（付記５）
付記２に記載のストレージシステムであって、
ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、
前記目標値設定部は、前記目標値を引き上げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き上げるよう設定する、
ストレージシステム。
【０１５７】
（付記６）
付記２に記載のストレージシステムであって、
ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、
前記目標値設定部は、検出した前記進捗状況が前記目標値に満たない前記処理部に前記処理待ちタスクが存在している場合に、他の前記処理部の前記目標値を引き下げるよう設定する、
ストレージシステム。
【０１５８】
（付記７）
付記６に記載のストレージシステムであって、
前記目標値設定部は、前記目標値を引き下げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き下げるよう設定する、
ストレージシステム。
【０１５９】
（付記８）
所定のタスクをそれぞれ実行する各処理部が実装された情報処理装置に、
前記各処理部による前記情報処理装置全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、
を実現させるためのプログラム。
【０１６０】
（付記９）
付記８に記載のプログラムであって、
前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するが否かを検出し、
前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、
プログラム。
【０１６１】
（付記１０）
所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出し、
検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定し、
前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する、
情報処理方法。
【０１６２】
（付記１１）
付記１０に記載の情報処理方法であって、
前記進捗状況の検出時に、前記各処理部に処理待ちタスクが存在するが否かを検出し、
検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、
情報処理方法。
【図１】
0005500256.tif 000010
【図２】
0005500256.tif 000011
【図３】
0005500256.tif 000012
【図４】
0005500256.tif 000013
【図５】
0005500256.tif 000014
【図６】
0005500256.tif 000015
【図７】
0005500256.tif 000016
【図８】
0005500256.tif 000017
【図９】
0005500256.tif 000018
【図１０】
0005500256.tif 000019
【図１１】
0005500256.tif 000020
【図１２】
0005500256.tif 000021
【図１３】
0005500256.tif 000022
【図１４】
0005500256.tif 000023
【図１５】
0005500256.tif 000024
【図１６】
0005500256.tif 000025
【図１７】
0005500256.tif 000026
【図１８】
0005500256.tif 000027