JP6169105B2 - ストレージシステムの動作を制御するための方法、装置、コンピュータプログラム及び記憶媒体 - Google Patents

ストレージシステムの動作を制御するための方法、装置、コンピュータプログラム及び記憶媒体 Download PDF

Info

Publication number
JP6169105B2
JP6169105B2 JP2014550469A JP2014550469A JP6169105B2 JP 6169105 B2 JP6169105 B2 JP 6169105B2 JP 2014550469 A JP2014550469 A JP 2014550469A JP 2014550469 A JP2014550469 A JP 2014550469A JP 6169105 B2 JP6169105 B2 JP 6169105B2
Authority
JP
Japan
Prior art keywords
client
load
iops
value
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014550469A
Other languages
English (en)
Other versions
JP2015507268A5 (ja
JP2015507268A (ja
Inventor
デイヴィッド ディー ライト
デイヴィッド ディー ライト
マイケル シュー
マイケル シュー
Original Assignee
ネットアップ，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/338,039 external-priority patent/US9003021B2/en
Application filed by ネットアップ，インコーポレイテッド filed Critical ネットアップ，インコーポレイテッド
Publication of JP2015507268A publication Critical patent/JP2015507268A/ja
Publication of JP2015507268A5 publication Critical patent/JP2015507268A5/ja
Application granted granted Critical
Publication of JP6169105B2 publication Critical patent/JP6169105B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0653—Monitoring storage devices or systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Description

関連特許出願の相互参照
本願は、２０１１年１２月２７日付けでＷｒｉｇｈｔらによって出願された、“Ｍａｎａｇｅｍｅｎｔ ｏｆ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ａｃｃｅｓｓ Ｂａｓｅｄ ｏｎ Ｃｌｉｅｎｔ Ｐｅｒｆｏｒｍａｎｃｅ ａｎｄ Ｃｌｕｓｔｅｒ Ｈｅａｌｔｈ”と題する米国特許出願第１３／３３８，０３９号（ＳｏｌｉｄＦｉｒｅ社事件番号Ｐ００２）の、米国特許法第１２０条の規定に基づく、一部継続出願であり、この米国特許出願の全体があらゆる目的のため参照によって本明細書に組み込まれる。
以下の説明は、読者の理解を支援するために提供される。提供される情報は、先行技術であることを自認するものではない。
データストレージアーキテクチャでは、クライアントのデータが、ボリュームに記憶されていることがある。典型的に、ボリュームのデータは、ストレージクラスタ内のほんの僅かな割合のドライブに存在する。この仕組みは、クラスタの一部が過度に利用され、クラスタのその他の部分が十分に利用されないというホットスポットの問題を生じる。例えば、クライアントがボリューム内のデータへの多数回のアクセスを実行している場合、データが記憶されている僅かな割合のドライブのために負荷が増加し、その結果ホットスポットを生じる。この仕組みにより、クラスタの全ボリュームに亘ってクライアントの使用感がばらつくことがある。つまり、自身のデータが十分に利用されていない部分に記憶されている場合、良好な性能を体感するクライアントもいれば、自身のデータが過度に利用されている部分に記憶されている場合、劣悪な性能を感じるクライアントもいる。
より良好なクライアントの使用感を提供することを試みる１つの方法は、クライアント優先順位に基づくサービス品質を使用することである。例えば、クライアントに対して、異なる優先レベルが割り当てられることがある。これらの優先レベルに基づいて、様々なクライアントのためのアクセス要求（例えば、読み出し要求および書き込み要求）に優先順位が付けられる。クライアントのアクセス要求は、クラスタの負荷と各クライアントに割り当てられた優先度とに基づいて振り分けられる。例えば、より高い優先度を有するクライアントは、クラスタがより高い負荷を受けている場合、より低い優先度を有する別のクライアントより多くのアクセス要求が処理される。優先度システムを使用することは、僅かに優れたクライアントの使用感を可能にさせるに過ぎない。例えば、優先度は、特定の、一貫性のある性能のレベルを保証することがなく、クラスタが自身の全性能をいつでも全てのクライアントの間で分割しているという考え方に基づく。この理由の１つは、クラスタの性能への単独のクライアントの影響が上限を定められないということであり、システムにストレスが加えられているとき、システムは、いつでも優先順位を付けられて作動しているので、システムは、システム上の顧客の数とは無関係にいつでもゆっくり作動する。優先順位は、顧客が獲得している現実の性能について理解できる考え方を顧客に示すことがないので、優先順位は、顧客が、自分が受けている現実の性能を理解することをさらに困難にする。さらに、優先順位は、システムが複数の顧客をどの程度支援するか、および、顧客がシステムに負荷をどの程度加えさせるかを管理者が制御することを可能にすることがない。
概要
一般に、本明細書に記載する主題の一態様は、複数のクライアントのうちの第１のクライアントに対するストレージシステム内のボリュームのクライアントメトリクスを決定する方法として実施されてもよい。ストレージシステムは、複数のクライアントからのデータを記憶する。ストレージシステム内のクラスタのシステムメトリクスは、複数のクライアントによるストレージシステムの使用状況に基づいて決定される。ストレージシステムの負荷値は、システムメトリクスおよびクライアントメトリクスに基づいて決定される。負荷値は、所定の閾値を上回るように決定される。目標性能値は、負荷値、最小サービス品質値、および最大サービス品質値に基づいて計算される。ストレージシステムの性能は、目標性能値と、負荷値が所定の閾値を上回っていると判定することとに基づいて、クライアントに合わせて調整される。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、個別のデータボリュームが関連するクライアントを有する複数のデータボリュームのためのデータを記憶するストレージシステムにおいて性能を管理する方法として実施されてもよい。個別のデータボリュームに対する使用状況の性能種別の選択が受信される。使用状況の性能種別は、少なくとも１つの使用状況の性能種別が異なる１秒当たりの入出力動作回数（ＩＯＰＳ）サービス品質パラメータを有する複数の性能種別の中から選択される。個別のデータボリュームへのアクセスは、選択された使用状況の性能種別のＩＯＰＳサービス品質パラメータに基づいて管理される。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、クライアントに対するストレージシステム内に記憶されたデータのアクセスに関連付けられた負荷値を決定する方法として実施されてもよい。データは、複数のブロックに分割され、ストレージシステムの複数のノードの全体に実質的に一様に記憶されている。記憶システムは、複数のクライアントからのデータを含む。クライアントから要求されたサービス品質パラメータが受信される。要求されたサービス品質パラメータに従うデータのアクセスが監視される。データへのアクセスは、データのアセスを監視することに基づいて絞られる。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、クライアントに対するストレージシステムに記憶されたデータのアクセスに関連付けられた１秒当たりの入力／出力動作回数（ＩＯＰＳ）メトリクスを決定する方法として実施されてもよい。データは、複数のブロックに分割され、複数のブロックは、ストレージシステムの複数のノードの全体に実質的に一様に記憶される。ストレージシステムは、複数のクライアントからのデータを含む。要求されたＩＯＰＳ値が受信される。データへのアクセスは、要求されたＩＯＰＳ値に基づいて重要度が下げられる。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、ストレージシステムボリュームにアクセスするコンピュータデバイスに関連付けられた最小性能サービス品質パラメータを受信する方法として実施されてもよい。ストレージシステムボリュームに関連付けられたシステムメトリクスが受信される。コンピュータデバイスに関連付けられた目標性能値は、最小性能サービス品質メトリクスおよびシステムメトリクスに基づいて計算される。目標性能値は、コントローラモジュールがストレージシステムボリュームにアクセスするコンピュータデバイスの性能を目標性能値に制限するような目標性能値が最小性能サービス品質メトリクスを満たすときにコントローラモジュールに送信される。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、ストレージシステムに対する合計容量を決定する方法として実施されてもよい。この容量は、サービス品質パラメータによって決定される。ストレージシステムにアクセスするために複数のクライアントに提供されたサービス品質パラメータの複数の値が受信される。複数のクライアントのうちの各クライアントは、サービス品質パラメータの値が提供される。ストレージシステム内の複数のクライアントに提供された複数の値が監視され、複数の値が閾値に違反するか否かが決定される。この閾値は、ストレージシステムに対する合計容量に基づく。信号は、１以上のクライアントに対するサービス品質パラメータの値、または、ストレージシステムに対する合計容量の調整が実行されるべきことを指示するために、複数の値が閾値に違反したとき自動的に出力される。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、ストレージシステムにアクセスするために複数のクライアントにサービス品質パラメータを提供する方法として実施されてもよい。複数のクライアントによるストレージシステムのアクセスが監視される。ストレージシステムにアクセス中の複数のクライアントのうちのクライアントの性能は、クライアントに提供されたサービス品質パラメータに基づいて制御される。クライアントの性能および複数のクライアントによるストレージシステムのアクセスは、このクライアントに対する目標性能値を決定するために分析される。ストレージシステムにアクセス中のクライアントの制御は、サービス品質パラメータに基づいてクライアントの性能を調整するために動的に調整される。本態様のその他の時実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、ストレージシステムにアクセスするために複数のクライアントにサービス品質パラメータを提供する方法として実施されてもよい。ストレージシステムにアクセス中の複数のクライアントのうちのクライアントの性能が監視される。ストレージシステムにアクセス中のクライアントの性能は、複数のクライアントのうちのその他のクライアントに提供されたサービス品質パラメータとは無関係に、クライアントに提供されたサービス品質パラメータに基づいて独立に制御される。このクライアントに対する負荷値は、このクライアントによるストレージシステムの使用状況とサービス品質パラメータとに基づいて計算される。クライアントの性能は、性能と負荷値との間の差を決定するためにこのクライアントに対するサービス品質パラメータに関連して分析される。ストレージシステムのリソースへのアクセスは、性能と負荷値との間の差に基づいてクライアントの性能の制御を独立に調整するために動的に割り当てられる。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、サーバシステム内部のデータへのクライアントアクセスを調整する方法として実施されてもよい。クライアントと通信するボリュームサーバは、データにアクセスするクライアントからの要求を受信する。性能マネージャは、メトリクスを監視し、メトリクスを目標値と比較することに応答してデータへのクライアントのアクセスを調整する。本態様のその他の実装は、この方法のアクションを実行するように構成されている対応するシステム、装置、およびコンピュータ可読媒体を含む。
本明細書に記載された主題の別の態様は、サーバシステム内部のデータへのクライアントによるアクセスを調整する方法として実施されてもよい。目標クライアントメトリクスを指示する目標値が受信される。サーバシステム内部のデータにアクセスするクライアントによる要求が受信される。クライアント性能は、目標値と比較され、目標値との比較に基づいて、データへのクライアントのアクセスが調整される。
以上の概要は、例示に過ぎず、決して限定することを意図するものではない。上述の例示的態様、実装、および特徴に加えて、さらなる態様、実装、および特徴が添付図面および詳細な説明を参照することによって明白になるであろう。
本開示の以下の特徴およびその他の特徴は、添付図面と併せて以下の説明および請求項から、より一層完全に明白になるであろう。
例示的な実装に係る、ストレージシステム内の性能管理のための簡略化されたシステムを示す。 例示的な実装に係る、システムのより詳細な例を示す。 例示的な実装に係る、サービス品質パラメータを設定するためのユーザインターフェースを示す。 例示的な実装に係る、性能管理を実行する方法の簡略化されたフローチャートを示す。 例示的な実装に係る、性能管理を使用して性能を調整するより詳細な例を示す。 例示的な実装に係る、入力／出力動作のサイズをシステム負荷と比較する性能曲線を示す。 例示的な実装に係る、過負荷状態システムメトリクスをクライアントメトリクスと適合する性能管理を実行する簡略化されたフローチャートを示す。 例示的な実装に係る、ある期間に亘ってクライアントによって実行された一定の回数のＩＯＰＳのグラフを示す。 例示的な実装に係る、ストレージシステムにおいてサービスプロバイダ、ユーザ、および／またはその他のエンティティが異なる性能種別を動的に定義および／または作成すること、および／または、性能／ＱｏＳ関連カスタマイゼーションを定義することを可能にするＱｏＳインターフェースＧＵＩ例８００を示す。 例示的な実装に係る、ストレージシステムの一部を示す。 負荷サービスデータ構造体の特定の実施形態例を示す。 ストレージシステム内部で作動する異なるサービスに関連付けられたシステム負荷特性および条件を追跡するために構成または設計されてもよい負荷サービスデータ構造体１１００の代替的な実施形態例を示す。 クライアントサービスデータ構造体の特定の実施形態例を示す。 例示的な実装に係る、負荷（サービス）分析手順のフロー図を示す。 例示的な実装に係る、負荷（読み出し）分析手順のフロー図を示すフロー図を示す。 例示的な実装に係る、負荷（書き込み）分析手順のフロー図を示す。 例示的な実装に係る、負荷（クライアント）分析手順のフロー図を示す。 例示的な実装に係る、ＱｏＳクライアントポリシー管理手順のフロー図を示す。 例示的な実装に係る、ＱｏＳクライアント読み出しポリシー管理手順のフロー図を示す。 例示的な実装に係る、ＱｏＳクライアント書き込みポリシー管理手順のフロー図を示す。 例示的な実装に係る、ストレージシステムが図１５に示されるようなＱｏＳクライアントポリシー管理手順の態様をどのように実施するかを示すグラフを示す。 例示的な実装に係る、クライアントＩＯＰＳを絞る異なるＱｏＳ管理ポリシー集合が変化する負荷（クライアント）条件に応答してどのように自動的におよび／または動的に実施することができる実施することができるかを示すグラフを示す。 例示的な実装に係る、ＱｏＳ管理およびＩＯＰＳ絞りがストレージシステムの複数の異なるクライアントに対してどのように同時、独立、および動的に実施されてもよいかを示すグラフを示す。 例示的な実装に係る、クライアントＩＯＰＳを絞る異なるＱｏＳ管理ポリシー集合が変化する負荷（クライアント−読み出し）条件に応答してどのように自動的および／または動的に実施することができるかを示すグラフを示す。 例示的な実装に係る、クライアントＩＯＰＳを絞る異なるＱｏＳ管理ポリシー集合が変化する負荷（クライアント−書き込み）条件に応答してどのように自動的／動的に実施することができるかを示すグラフを示す。
特定の実施形態例
１つ以上の異なる発明が本願に記載されてもよい。さらに、本願に記載された発明のうちの１つ以上に対して、多くの実施形態が本特許出願において記載されることがあり、例示の目的のみのため提示される。記載された実施形態は、決して限定的であることが意図されていない。発明のうちの１つ以上は、開示から容易に分かるように、多くの実施形態に広く適用できることがある。これらの実施形態は、当業者が１つ以上の発明を実施することを可能にするために十分に詳しく記載され、その他の実施形態が利用されてもよいこと、ならびに、発明のうちの１つ以上の範囲から逸脱することなく構造的、論理的、ソフトウェア、電気的およびその他の変更がなされてもよいことが理解されるはずである。その結果、当業者は、発明のうちの１つ以上が様々な変更および変形を伴って実施されてもよいことを理解するであろう。発明のうちの１つ以上についての特有の特徴は、１つ以上の特有の実施形態、または、本開示の一部を形成し、実例として、発明のうちの１つ以上についての特定の実施形態が図示されている図面を参照して記載されてもよい。しかし、このような特徴は、これらの特徴が記載される際に参照した１つ以上の特有の実施形態または図面における使用状況に限定されないことが理解されるべきである。本開示は、発明のうちの１つ以上についての全ての実施形態の文字通りの説明ではないだけでなく、全ての実施形態に存在しなければならない発明のうちの１つ以上についての特徴の列挙でもない。
本願に設けられた欄の表題および本願の名称は、利便性のためだけのものであり、決して開示を限定するものとして解釈されるべきではない。相互に通信しているデバイスは、特に断らない限り、相互に絶えず通信している必要はない。その上、相互に通信しているデバイスは、直接的に、または、１つ以上の中間物を介して間接的に通信してもよい。相互に通信している数個のコンポーネントを含む実施形態の記載は、全てのこのようなコンポーネントが必要とされることを意味するものではない。これに反して、種々の自由選択のコンポーネントが発明のうちの１つ以上についての多種多様の考えられる実施形態を例示するために記載されている。
さらに、プロセスステップ、方法ステップ、アルゴリズムなどは、一連の順序で記載されてもよいが、このようなプロセス、方法およびアルゴリズムは、代わりの順序で正常に機能するように構成されてもよい。換言すると、本特許出願において記載されてもよいステップの系列または順序はいずれもステップがこの順序で実行されるという要件をそれ自体で示唆するものではない。記載されたプロセスのステップは、実際的などんな順序でも実行されてもよい。さらに、いくつかのステップは、（例えば、一方のステップが別のステップの後に記載されているので）非同時的に現れるものとして記載または示唆されているとしても、同時に実行されてもよい。さらに、図面におけるプロセスの図示によるプロセスの例示は、例示されたプロセスがこのプロセスへのその他の変形および変更を除外することを意味するものではなく、例示されたプロセスまたはこのプロセスのステップのいずれかが発明のうちの１つ以上に必要であることを意味するものではなく、例示されたプロセスの方が好ましいということを意味するものではない。
単一のデバイスまたは物が記載されるとき、（協働するか否かを問わずに）２台以上のデバイス／物品が単一のデバイス／物品の代わりに使用されてもよいことが容易に分かるであろう。同様に、（協働するか否かを問わずに）２台以上のデバイスまたは物品について記載される場合、単一のデバイス／物品が２台以上のデバイスまたは物品の代わりに使用されてもよいことが容易に理解できるであろう。デバイスの機能および／または特徴は、このような機能／特徴を有するものとして明示的に記載されていない１台以上のその他のデバイスによって代替的に具現化されてもよい。このように、発明のうちの１つ以上についてのその他の実施形態は、このデバイス自体を含んでいる必要がない。
本明細書において記載または参照された手法および仕組みは、時には、明瞭さのため単数形で記載されることもある。しかし、特有の実施形態は、特に断らない限り、手法の複数回の反復、または、仕組みの複数回のインスタンス化を含むことに注意すべきである。
詳細な説明
本明細書に、性能管理ストレージシステムのための手法が開示される。以下の説明では、解説の目的のため、多くの例および特定の詳細が様々な実装の完全な理解を提供するために記載される。請求項に記載された事項によって定義されるように特有の実装は、これらの例における特徴の一部もしくは全部を単独で、または、後述されるその他の特徴と組み合わせて含むことがあり、本明細書に記載された特徴および考え方の変更物と均等物とをさらに含んでもよい。
ストレージシステム
図１Ａは、例示的な実装に係る、ストレージシステム１００内の性能管理のための簡略化されたシステムを示す。このようなシステム１００は、クライアント層１０２と、メタデータ層１０４と、ブロックサーバ層１０６と、ストレージ１１６とを含む。
特有の実装がクライアント１０８の性能をどのように管理するかを検討する前に、考えられるシステムの構造について記載する。クライアント層１０２は、１つ以上のクライアント１０８ａから１０８ｂを含む。クライアント１０８は、１台以上の物理マシン上に存在してもよいクライアントプロセスを含む。用語「クライアント」が開示中で使用されるとき、実行されるアクションは、クライアントプロセスによって実行されてもよい。クライアントプロセスは、システム１００内のデータを記憶、取り出し、および削除する責任を担う。クライアントプロセスは、ストレージシステムの性質および記憶されたデータのフォーマットに依存してデータの断片をアドレス指定してもよい。例えば、クライアントプロセスは、クライアントアドレスを使用してデータを参照する。クライアントアドレスは、異なる形式をとることがある。例えば、ファイルストレージを使用するストレージシステムでは、クライアント１０８は、特有のボリュームまたはパーティションと、ファイル名とを参照してもよい。オブジェクトストレージを用いる場合、クライアントアドレスは、一意のオブジェクト名であることがある。ブロックストレージの場合、クライアントアドレスは、ボリュームまたはパーティションと、ブロックアドレスとであることがある。クライアント１０８は、スモールコンピュータシステムインターフェース（ＳＣＳＩ）、ファイバチャネル（ＦＣ）、共通インターネットファイルシステム（ＣＩＦＳ）、ネットワークファイルシステム（ＮＦＳ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ウェブベースの分散オーサリングおよびバージョン管理（ＷｅｂＤＡＶ）、またはカスタムプロコルなどの異なるプロトコルを使用してメタデータ層１０４と通信する。
メタデータ層１０４は、１台以上のメタデータサーバ１１０ａ〜１１０ｎを含む。性能マネージャ１１４は、メタデータサーバ１１０ａ〜１１０ｎ上に置かれることがある。ブロックサーバ層１０６は、１台以上のブロックサーバ１１２ａ〜１１２ｎを含む。ブロックサーバ１１２ａ〜１１２ｎは、ストレージ１１６に連結され、ストレージは、クライアント１０８に対するボリュームデータを記憶する。一実装では、１つのクライアント１０８だけがボリューム内のデータにアクセスするが、複数のクライアント１０８が単一のボリューム内のデータにアクセスしてもよい。
ストレージ１１６は、複数のソリッドステートドライブ（ＳＳＤ）を含む可能性がある。一実装では、ストレージ１１６は、ネットワークを介して一体的に連結された個別のドライブのクラスタであってもよい。用語「クラスタ」が使用されるとき、クラスタは、一体的にネットワーク化されないことがある複数のディスクを含むストレージシステムを表現してもよいことが理解される。一実装では、ストレージ１１６は、永続データを記憶するためにソリッドステートメモリを使用する。ＳＳＤは、データを不揮発性メモリチップに記憶するマイクロチップを使用し、可動部品を含んでいない。このことの１つの帰結は、ＳＳＤがスピニングディスクを含むドライブと比較すると最適化された方法で異なるデバイス内のデータへの無作為アクセスを可能にすることである。ＳＳＤの非順次部分への読み出しまたは書き込み要求は、順次読み出しまたは書き込み要求と比較すると匹敵する時間で実行されてもよい。対照的に、スピニングディスクが使用される場合、データを読み取るために読み出し／書き込みヘッドを様々な無作為位置に挿入することは、データが順次位置から読み取られる場合より遅いデータアクセスという結果になるので、無作為読み出し／書き込みは、効率的ではないということになる。その結果、電気機械ディスクストレージを使用することは、非順次データへのより遅いデータアクセスを回避するために、データのクライアントのボリュームがクラスタの小規模の相対的な順次部分に集中されることを要求することができる。ＳＳＤを使用することは、この制限を取り除く。
様々な実施では、データをストレージ１１６に非順次記憶することは、データを１つ以上のユニット、例えば、データブロックに分割することに基づく。データブロックは、その結果、ボリュームに対する未加工データであり、最小のアドレス可能なデータの単位であることがある。メタデータ層１０４またはクライアント層１０２は、データをデータブロックに分割することができる。データブロックは、その後、複数のブロックサーバ１１２に記憶されてもよい。データブロックは、固定サイズであってもよいか、最初に固定サイズであり、圧縮されてもよいか、または、可変サイズであってもよい。データブロックは、ブロックの文脈的内容に基づいてセグメント化される可能性もある。例えば、特有のタイプのデータは、その他のタイプのデータより大きいデータブロックサイズを有してもよい。書き込み時のブロックのセグメント化（および対応する読み出し時の再組立）を維持することは、クライアント層１０２および／またはブロックサーバ層１０６内で行われることがある。
データを非順次記憶することに加えて、データブロックは、ストレージシステムの全体に実質的に均一な分布を実現するように記憶されてもよい。様々な例では、均一な分布は、一意のブロック識別子に基づいてもよい。ブロック識別子は、内容のハッシュを用いるようなデータブロックの内容に基づいて決定される識別子であってもよい。ブロック識別子は、データのブロックに対して一意である。例えば、同じ内容を含んでいるブロックは、同じブロック識別子を有するが、異なる内容を含んでいるブロックは、異なるブロック識別子を有する。均一な分布を実現するために、考えられる一意の識別子の値は、一様分布を有することができる。その結果、一意の識別子または一意の識別子の一部に基づいてデータブロックを記憶することにより、データがクラスタ内のドライブの全体に実質的に均一に記憶されるようになる。
クライアントデータ、例えば、クライアントに関連付けられたボリュームは、クラスタ内の全てのドライブの全体に均一に拡散されるので、クラスタ内のあらゆるドライブは、各ボリュームの読み出し経路および書き込み経路に関与される。この構成は、全てのドライブの全体にデータと負荷とのバランスを取る。この仕組みは、クライアントのデータがいずれかのボリュームに順次記憶されたときに生じる可能性があるクラスタ内部のホットスポットも取り除く。
その上、クラスタ内のドライブの全体にデータを均一に拡散させることは、クラスタの一貫性のある全体的な合算性能が定義され、達成されることを可能にする。この合算は、各クライアントに対するデータがドライブを介して均一に拡散されるので、達成されてもよい。その結果、クライアントのＩ／Ｏは、クラスタ内の全てのドライブを関与させることもある。全てのクライアントは、これらのデータをストレージシステム内の全てのドライブを介して実質的に均一に拡散させるので、システムの性能は、単一の数として、例えば、ストレージシステム内の全てのドライブの性能の合計として合算して記述されてもよい。
ブロックサーバ１１２およびスライスサーバ１２４は、ブロック識別子とブロックサーバ１１２のストレージ媒体内のデータブロックの位置との間のマッピングを維持する。ボリュームは、これらの一意の、かつ、一様に無作為な識別子を含むので、ボリュームのデータは、クラスタ全体に同様に均一に分散されている。
メタデータ層１０４は、クライアント層１０２とブロックサーバ層１０６とをマッピングするメタデータを記憶する。例えば、メタデータサーバ１１０は、クライアント１０８によって使用されるクライアントアドレス指定（例えば、ファイル名、オブジェクト名、ブロック番号など）と、ブロックサーバ層１０６によって使用されるブロック層アドレス指定（例えば、ブロック識別子）とをマッピングする。クライアント１０８は、クライアントアドレスに基づいてアクセスを実行してもよい。しかし、前述のとおり、ブロックサーバ１１２は、識別子に基づいてデータを記憶し、クライアントアドレスに基づいてデータを記憶することがない。その結果、クライアントは、ストレージ１１６内のクライアントのデータを参照する対応する一意の識別子に最終的に翻訳されるクライアントアドレスを使用してデータにアクセスすることができる。
システム１００の部品は、論理的に別個であるとして図示されているが、エンティティは、異なる形式で組み合わされてもよい。例えば、いずれかの層の機能は、単一のプロセスまたは単一のマシン（例えば、コンピュータデバイス）に一体化されてもよいが、複数の機能または全ての機能は、１台のマシンに、または、複数のマシンの全体に存在してもよい。さらに、複数のマシンの全体に動作するとき、これらのマシンは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）などのネットワークインターフェースを使用して通信してもよい。一実装では、１台以上のメタデータサーバ１１０は、単一のマシン内の１台以上のブロックサーバ１１２と組み合わされてもよい。システム１００内のエンティティは、仮想化エンティティでもよい。例えば、複数の仮想ブロックサーバ１１２は、マシンに含まれることがある。エンティティは、クラスタ内にさらに含まれることがあり、クラスタのコンピューティングリソースは、コンピューティングリソースが単一のエンティティとして見えるように仮想化される。
図１Ｂは、一実装によるシステム１００のより詳細な例を示す。メタデータ層１０４は、リダイレクトサーバ１２０および複数のボリュームサーバ１２２を含んでもよい。各ボリュームサーバ１２２は、複数のスライスサーバ１２４に関連してもよい。
本例では、クライアント１０８ａは、ボリューム（例えば、クライアントアドレス）に接続したい。クライアント１０８ａは、リダイレクトサーバ１２０と通信し、イニシエータ名によって自身の身元を明らかにし、クライアントが接続したいターゲット名によってボリュームをさらに指示する。異なるボリュームサーバ１２２は、異なるボリュームに対する責任を担う。この場合、リダイレクタサーバ１２０は、クライアントを特定のボリュームサーバ１２２に宛先変更する。クライアント１０８に対して、リダイレクトサーバ１２０は、単一の接続点を提示してもよい。クライアント１０８ａからの第１の要求は、次に、特定のボリュームサーバ１２２に宛先変更される。例えば、リダイレクトサーバ１２０は、どのボリュームサーバ１２２が要求されたターゲット名に対する１次的ボリュームサーバであるかを判定するために、ボリュームのデータベースを使用してもよい。クライアント１０８ａからの要求は、次に、特定のボリュームサーバ１２２に向けられ、クライアント１０８ａを特定のボリュームサーバ１２２に直接的に接続させる。クライアント１０８ａと特定のボリュームサーバ１２２との間の通信は、次に、リダイレクトサーバ１２０を用いることなく処理されてもよい。
ボリュームサーバ１２２は、メタデータサーバ１１０に関連して記載されたように機能を実行する。付加的に、各ボリュームサーバ１２２は、性能マネージャ１１４を含む。ボリュームサーバ１２２によってホストされたボリューム毎に、ブロック識別子のリストがボリューム上の論理ブロック毎に１個のブロック識別子を伴って記憶される。各ボリュームは、１台以上のボリュームサーバ１２２の間で複製されてもよい、各ボリュームに対するメタデータは、このボリュームをホストするボリュームサーバ１２２の各々の間で同期されてもよい。ボリュームサーバ１２２が機能しなくなった場合、リダイレクトサーバ１２０は、クライアント１０８の宛先を代替ボリュームサーバ１２２としてもよい。
一実装では、ボリュームサーバ１２２に記憶されているメタデータは、１台のボリュームサーバ１２２に対して過剰に大きくなることがある。このようにして、複数のスライスサーバ１２４は、各ボリュームサーバ１２２に関連してもよい。メタデータは、スライスに分割されてもよい、メタデータのスライスは、各スライスサーバ１２４に記憶されてもよい。ボリュームの要求がボリュームサーバ１２２で受信されたとき、ボリュームサーバ１２２は、どのサーバ１２４がこのボリュームに対するメタデータを格納するかを判定する。ボリュームサーバ１２２は、次に、要求を適切なスライスサーバ１２４に経路制御する。その結果、スライスサーバ１２４は、付加的な抽象化層をボリュームサーバ１２２に追加する。
上記構造は、ディスクのクラスタの全体に均一にデータを記憶することを可能にする。例えば、ブロック識別子に基づいてデータを記憶することにより、データは、クラスタのドライブの全体に均一に記憶されてもよい。前述のとおり、クラスタの全体に均一に記憶されたデータは、性能メトリクスがシステム１００内の負荷を管理することを可能にする。システム１００が負荷を受けている場合、クライアントは、絞られる、または、ボリュームから締め出されてもよい。クライアントがボリュームから締め出されたとき、メタデータサーバ１１０またはボリュームサーバ１２２は、コマンドウィンドウを閉じることがあり、または、クライアント１０８のため同時に処理されている読み出しもしくは書き込みデータの量を削減もしくは零にしてもよい。メタデータサーバ１１０またはボリュームサーバ１２２は、ボリュームへのクライアントのアクセスが締め出し期間後に再開した後にクライアント１０８からのＩＯ要求が処理できるように、クライアント１０８に対するアクセス要求をキューに入れる可能性がある。
ストレージシステムの性能メトリクスおよび負荷
ストレージシステム１００は、クライアントによるストレージシステムのリソースの使用状況を監視することができる性能マネージャ１１４をさらに含む可能性がある。その上、性能マネージャ１１４は、ユーザによるストレージシステム１００の使用状況を規制することができる。クライアントによるストレージシステムの使用状況は、性能メトリクス、クライアントのサービス品質パラメータ、およびストレージシステムの負荷に基づいて調整されてもよい。性能メトリクスは、ストレージシステムの様々な測定可能な属性である。１つ以上の性能メトリクスがシステムの負荷を計算するために使用される可能性があり、より詳細に後述されるように、このシステムの負荷は、システムのクライアントを絞るために使用されてもよい。
性能メトリクスは、異なるマトリックスのカテゴリにグループ分けされてもよい。システムメトリクスは、１つのカテゴリである。システムメトリクスは、全てのクライアントによるシステムまたはシステムのコンポーネントの使用状況を反映するメトリクスである。システムメトリクスは、ストレージシステム全体またはストレージシステム内部のコンポーネントに関連付けられたメトリクスを含む可能性がある。例えば、システムメトリクスは、システムレベル、クラスタレベル、ノードレベル、サービスレベル、またはドライブレベルで計算されてもよい。空間利用率は、システムメトリクスの一例である。クラスタ空間利用率は、どの程度の空間が特有のクライアントのため利用可能であるかを反映するが、ドライブ空間利用率は、どの程度の空間が特有のドライブのため利用可能性あるかを反映する。空間利用率メトリクスは、システムレベル、サービスレベル、およびノードレベルでさらに決定されてもよい。システムメトリクスのその他の例は、読み出しレイテンシー、書き込みレイテンシー、１秒当たりの入力／出力動作回数（ＩＯＰＳ）、読み出しＩＯＰＳ、書き込みＩＯＰＳ、Ｉ／Ｏサイズ、書き込みキャッシュ容量、重複排除能力、圧縮率、合計帯域幅、読み出し帯域幅、書き込み帯域幅、読み出し／書き込み比率、作業負荷タイプ、データ内容、データタイプなどなどの測定された、または、合算されたメトリクスを含む。
ＩＯＰＳは、クラスタまたはドライブに対して測定された１秒当たりの現実の入力／出力動作回数であってもよい。帯域幅は、クライアント１０８とデータのボリュームとの間で転送されているデータの量であることがある。読み出しレイテンシーは、システム１００がボリュームからデータを読み出し、このデータをクライアントに返すために要する時間であってもよい。書き込みレイテンシーは、システムがデータを書き込み、成功の指標をクライアントに返すために要する時間であってもよい。作業負荷タイプは、ＩＯアクセスが順次であるか、または、無作為であるかを指示することができる。データタイプは、アクセス／書き込みされているデータのタイプ、例えば、テキスト、映像、画像、音声などを識別することができる。書き込みキャッシュ容量は、書き込みキャッシュもしくはノード、ブロックサーバ、またはボリュームサーバを参照する。書き込みキャッシュは、データがストレージ１１６に書き込まれる前にデータを記憶するために使用される比較的高速なメモリである。前述のとおり、これらのメトリクスの１つずつは、システム、クラスタ、ノードなどに対して独立に計算されてもよい。その上、これらの値は、クライアントレベルで計算される可能性もある。
クライアントメトリクスは、計算されてもよい別のメトリクスのカテゴリである。システムメトリクスとは違って、クライアントメトリクスは、クライアントによるシステムの使用状況を考慮して計算される。より詳細に後述されるように、クライアントメトリクスは、システムの共通特徴を使用しているその他のクライアントによる使用状況を含んでもよい。クライアントメトリクスは、しかし、その他のクライアントによるシステムの非共通特徴の使用状況を含むことはないであろう。一実装では、クライアントメトリクスは、システムメトリクスと同じメトリクスを含む可能性があるが、コンポーネントまたはシステム全体に亘るというよりも、クライアントのボリュームに固有のものである。例えば、読み出しレイテンシーまたは書き込みＩＯＰＳなどのメトリクスは、クライアントの特有のボリュームに対して監視されてもよい。
システムメトリクスおよびクライアントメトリクスは、いずれも、ある期間、例えば、２５０ｍｓ、５００ｍｓ、１ｓなどに亘って計算されてもよい。その結果、最小、最大、標準偏差、平均などの異なる値がメトリクス毎に計算されてもよい。メトリクスのうちの１つ以上は、ストレージシステムの負荷を表現する値を計算するために使用されてもよい。より詳細に後述されるように、様々な異なる負荷計算が計算されてもよい。負荷は、ストレージシステム全体に対して、個別のコンポーネントに対して、個別のサービスに対して、および／または、個別のクライアントに対して計算されてもよい。負荷値、例えば、システム負荷値および／またはクライアント負荷値は、次に、クライアントが絞られるべきか否か、およびどの程度絞られるべきかを判定するために、サービス品質システムによって使用されてもよい。
より詳細に後述されるように、個別のクライアントに対する性能は、監視されたメトリクスに基づいて調整されてもよい。例えば、システムメトリクス、クライアントメトリクス、およびクライアントサービス品質パラメータなどの一定の数の要因に基づいて、ある期間に亘ってクライアント１０８によって実行されてもよい一定の回数のＩＯＰＳが管理されてもよい。一実装では、性能マネージャ１１４は、クライアント１０８によって実行され得るＩＯＰＳの回数を管理するために異なる期間に亘ってボリュームからクライアント１０８を締め出すことによりＩＯＰＳの回数を規制する。例えば、クライアント１０８が厳しく制限されているとき、クライアント１０８は、５００ミリ秒毎に４５０ミリ秒ずつボリュームにアクセスすることから締め出されてもよい、クライアント１０８が厳しく制限されていないとき、クライアント１０８は、５００ミリ秒毎に５０ミリ秒ずつボリュームから遮断される。この締め出しは、クライアントが５００ミリ秒毎に実行できるＩＯＰＳの回数を効果的に管理する。ＩＯＰＳを使用する例が記載されているが、より詳細に後述されるように、その他のメトリクスが使用されてもよい。
システム１００内の負荷を管理するためにメトリクスを使用することは、グローバルクラスタ性能へのクライアントの影響がデータ、従って、データ負荷の分布の均一性のために予測可能であるので可能である。例えば、クラスタにアクセスすることからクライアント１０８を締め出すことにより、クラスタ内の負荷は、効果的に管理されることになる。負荷は、均一に分散されているので、クライアントのボリュームへのアクセスを低減することは、クラスタ全体に均一にクライアントの負荷を低減する。しかし、ホットスポットが発生してもよい従来型のストレージアーキテクチャにより、クラスタ性能が予測不可能となる。このようにして、クライアントによるアクセスを低減することは、クライアントがクラスタの問題エリアにアクセスしないことがあるので、ホットスポットを緩和しないことがある。記載された実施形態では、クライアント負荷は、システムを通じて均一に分散されているので、グローバル性能プールが計算される可能性があり、システムが使用されている程度に対する個別のクライアント寄与度も計算されてもよい。
クライアントサービス品質パラメータ
システムメトリクスおよびクライアントメトリクスに加えて、クライアントサービス品質（ＱｏＳ）パラメータは、クライアントがストレージシステムを使用する程度に影響を与えるために使用されてもよい。メトリクスとは違って、クライアントＱｏＳパラメータは、測定値ではなく、むしろ、クライアントに対する所望のＱｏＳ限界を定義する設定できる変数である。クライアントＱｏＳパラメータは、管理者またはクライアントによって設定されてもよい。一実装では、クライアントＱｏＳパラメータは、最小値、最大値、および最大バースト値を含む。一例としてＩＯＰＳを使用すると、最小ＩＯＰＳ値は、クライアントに対するクラスタの性能の比例量である。このようにして、最小ＩＯＰＳは、ボリュームがこの最小ＩＯＰＳ値でいつでも機能するという保証ではない。ボリュームが過負荷状況にあるとき、最小ＩＯＰＳ値は、システムがクライアントに提供しようとするＩＯＰＳの最小数である。しかし、クラスタ性能に基づいて、個別のクライアントのＩＯＰＳは、過負荷状況中に最小値より低くなるまたは高くなることがある。一実装では、システム１００は、全てのクライアントに亘る最小ＩＯＰＳの合計が、システム１００が所定の時点で全てのクライアントに対して最小ＩＯＰＳ値を持続できる程度であるようにプロビジョニングされてもよい。この状況では、各クライアントは、これらの最小ＩＯＰＳ値以上で機能できるべきである。システム１００は、しかし、全てのクライアントに亘る最小ＩＯＰＳの合計が、システム１００が全てのクライアントに対して最小ＩＯＰＳ値を持続できない程度であるようにさらにプロビジョニングされてもよい。この例では、システムが全てのクライアントの使用を通じて過負荷になる場合、クライアントの実現ＩＯＰＳは、クライアントの最小ＩＯＰＳ値未満であってもよい。失敗状況では、システムは、ユーザの実現ＩＯＰＳがこれらの最小ＩＯＰＳ値未満であるようにユーザをさらに絞ることがある。最大ＩＯＰＳパラメータは、延長期間に亘って最大維持ＩＯＰＳ値である。最大バーストＩＯＰＳパラメータは、クライアントがクレジットに基づいて短期間に亘って最大ＩＯＰＳパラメータを上回って「バースト」することができる最大ＩＯＰＳ値である。一実装では、クライアントに対するクレジットは、クライアントがこれらのそれぞれの最大ＩＯＰＳパラメータ未満で動作しているときに増加される。その結果、クライアントは、これらのそれぞれの最大ＩＯＰＳおよび最大ＩＯＰＳパラメータに従ってシステムを使用する可能性しかないであろう。例えば、単一のクライアントは、システムのリソースが利用可能である場合でも、システムの全部のリソースを使用できず、それどころか、これらのそれぞれの最大ＩＯＰＳおよび最大バーストＩＯＰＳパラメータによって制限される。
前述のとおり、クライアントＱｏＳパラメータは、クライアントまたは管理者によっていつでも変更されてもよい。図２は、例示的な一実装に係るクライアントＱｏＳを設定するためのユーザインターフェース２００を示す。ユーザインターフェース２００は、様々なＱｏＳパラメータを変更するために使用される入力を含む可能性がある。前述のとおり一実装では、クライアントＱｏＳパラメータは、最小ＩＯＰＳ、最大ＩＯＰＳ、および最大バーストＩＯＰＳを含む。これらのパラメータの各々は、入力、例えば、スライドバーおよび／またはテキストボックスを用いて調整されてもよい。その上、異なるサイズのＩＯ動作に対するＩＯＰＳが表示されてもよい。ユーザインターフェース２００では、４ｋサイズのＩＯ動作に関連付けられたＱｏＳパラメータが変更される。何らかの性能パラメータが変更されたとき、異なるサイズのＩＯ動作に対する対応するＩＯＰＳは、自動的に調整される。例えば、バーストパラメータが変更されたとき、ＩＯＰＳ値２０６は、自動的に調整される。更新値は、より詳細に後述されるように性能曲線に基づいてもよい。ＱｏＳパラメータが設定されると、変更保存ボタン２０８を作動することは、クライアントのＱｏＳパラメータを更新する。後述されるように、目標性能マネージャ４０２は、更新ＱｏＳパラメータが直ちに有効になるように、更新ＱｏＳパラメータを使用することができる。更新ＱｏＳパラメータは、ユーザデータがシステム内で移動されることを要求することなく有効になる。
性能管理
図３は、一実装による性能管理を実行する方法の簡略化されたフローチャート３００を示す。付加的に、方法３００のより少数の、または、異なる動作が特有の実施形態に依存して実効されてもよい。方法３００は、コンピューティングデバイスで実施することができる。一実装では、方法３００は、コンピューティングデバイスによって実行されたときに、コンピューティングデバイスに方法３００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。
３０２で、性能マネージャ１１４は、１つ以上の性能メトリクスに基づいてクライアント負荷を決定する。例えば、性能マネージャ１１４は、ＩＯＰＳ、帯域幅、およびレイテンシーなどの異なる性能メトリクスに基づいてクライアントの負荷を計算してもよい。メトリクスは、過去のメトリクスおよび／または現在の性能メトリクスであることがある。過去の性能は、先週の性能メトリクスなどの以前のある期間の性能を測定してもよい。現在の性能は、リアルタイム性能メトリクスでもよい。例えば、システムメトリクスおよび／またはクライアントメトリクスなどのこれらの性能メトリクスを使用して負荷値が計算される。負荷値例は、より詳細に後述される。
３０３で、性能マネージャ１１４は、クラスタの正常性に関する情報を収集する。クラスタの正常性は、負荷値などのクラスタの性能を定量化することができる情報でもよい。クラスタ正常性情報は、システム１００の異なる部分から収集されてもよい、システムメトリクスおよび／またはクライアントメトリクスなどのシステム１００の多くの異なる態様における正常性を含んでもよい。加えて、かつ、より詳細に後述されるように、クラスタ正常性情報は、クライアントおよび／またはシステムメトリクスから負荷値として計算されてもよい。より詳細に後述されるように、正常性情報は、全クラスタのものではないことがあり、性能管理を実行しているボリュームサーバ１２２にローカルな情報を含んでもよい。クラスタ正常性は、影響を受けることがあり、例えば、クラスタデータ再構築が行われた場合、クラスタの全性能は、落ちることがある。さらに、データ破棄、ノードの追加もしくは削除、ボリュームの追加もしくは削除、電源異常、使用済みスペース、または性能に影響を与えるその他の事象が起こったとき、性能マネージャ１１４は、クラスタからこの情報を収集する。
３０４で、性能マネージャ１１４は、目標性能値を決定する。例えば、負荷値およびクライアントサービス品質パラメータに基づいて、目標性能値が決定される。より詳細に後述されるように、目標性能値は、負荷値、クライアントメトリクス、システムメトリクス、およびサービス品質パラメータなどの異なる規準に基づくことがある。目標性能値とは、性能マネージャ１１４がクライアント１０８にこの値で動作してもらいたいという値である。例えば、目標性能は、１１０ ＩＯＰＳであることがある。
３０６で、性能マネージャ１１４は、クライアント１０８の性能を調整する。例えば、将来のクライアント性能は、目標性能値に向かって調整されてもよい。ＩＯＰＳが性能メトリクスとして測定される場合、クライアントがある期間に亘って実行するＩＯＰＳの回数は、目標性能値に調整されてもよい。例えば、レイテンシーは、クライアントが実行できるＩＯＰＳの回数を変動させることを可能にするために導入または除去されてもよい。一例では、以前のクライアント性能におけるＩＯＰＳの回数が８０であり、目標性能値が１１０回のＩＯＰＳである場合、クライアントの性能が１１０回のＩＯＰＳの実行に近付くように、クライアントの性能は、クライアント１０８がより多数のＩＯＰＳを実行することを可能にするために調整される。
従来のプロビジョニングシステムは、クライアントのデータをクライアントに要求されたサービス品質を提供すべきシステムに置くことによりサービス品質を達成しようとする。自身のサービス品質への変更を要求するクライアントは、その結果、クライアントのデータが一方のシステムから別のシステムへ移されることを必要とすることができる。例えば、自身のサービス品質を著しく高めることを望むクライアントは、サービス品質の高まりを確実にするために、より一層頑健性のあるシステムへ移されることを必要としてもよい。従来のプロビジョニングシステムとは違って、性能マネージャは、クライアントのデータを別のクラスタへ移すことなく、特定のクライアントに対するサービス品質を動的に調整することができる。その結果、クライアントに対するサービス品質は、即時に調整される可能性があり、クライアントは、ＱｏＳパラメータが効力を発するために手動介入を要求することなく、ＱｏＳパラメータを変更できる。この特徴は、クライアントがこれらのＱｏＳパラメータへの変更を予定することを可能にする。例えば、クライアントが毎月の第１日曜日の午前２時〜午前４時にバックアップを実行する場合、クライアントは、バックアップの直前にこれらのＱｏＳパラメータを自動的に変更させ、かつ、バックアップが終了した後に元に戻すことがあり得る。この態様は、クライアントがクライアントの必要性に基づいてこれらのＱｏＳパラメータへの変更を予定に入れる柔軟性を許す。別の例として、クライアントは、ターボボタンを提示されてもよい。選択されたとき、ターボボタンは、何らかの倍率、例えば、３倍、４倍、５倍などによって、または、何らかの大きい量までクライアントのＱｏＳパラメータを増大させる。クライアントは、クライアントのウェブサイトに大勢の訪問者が訪れているときのように、自身のデータ需要が突然に増加した場合、この特徴を使用することがあり得る。クライアントは、次に、自身の元のＱｏＳパラメータに戻るためにターボボタンを非選択にすることがあり得る。クライアントは、ターボボタン機能を使用した期間に対して課金されてもよい。別の実装では、ターボボタンは、クライアントの元のＱｏＳパラメータにリセットされる前に所定の期間に亘って有効である。
上記例に加えて、クライアントおよび／または管理者は、様々な条件に基づいてクライアントＱｏＳパラメータを設定することができる。その上、前述のとおり、クライアントＱｏＳパラメータは、ＩＯＰＳに限定されない。異なる実施では、クライアントＱｏＳパラメータは、帯域幅、レイテンシーなどであってもよい。異なる実施形態によれば、ストレージシステムは、サービスプロバイダ、クライアント、管理者、および／または、ユーザが、例えば、所定のユーザまたはクライアントによる要求とおりに、ＱｏＳパラメータ、および／または、プロビジョニング／ＱｏＳターゲットタイプの多種多様の組み合わせに基づくことがある異なるタイプのＱｏＳおよびプロビジョニングルールを選択的かつ動的に構成および／または定義することを可能にするように構成または設計されてもよい。
異なる実施形態によれば、クライアントＱｏＳパラメータの例は、限定するものではないが、
ＩＯＰＳ
帯域幅
書き込みレイテンシー
読み出しレイテンシー
書き込みバッファキュー深度
Ｉ／Ｏサイズ（例えば、１秒当たりのアクセスバイト数）
Ｉ／Ｏタイプ（例えば、読み出しＩ／Ｏ、書き込みＩ／Ｏなど）
例えば、作業負荷タイプ（例えば、順次、無作為）、重複排除能力、圧縮率、データ内容、データタイプ（例えば、テキスト、映像、画像、音声など）などのデータ特性
その他
の（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい。
異なる実施形態によれば、様々なプロビジョニング／ＱｏＳ目標タイプの例は、限定するものではないが、
サービスまたはサービスのグループ
クライアントまたはクライアントのグループ
接続（例えば、クライアント接続）
ボリュームまたはボリュームのグループ
ノードまたはノードのグループ
アカウント／クライアント
ユーザ
ｉＳＣＳＩセッション
時間セグメント
読み出しＩＯＰＳ量
書き込みＩＯＰＳ量
アプリケーションタイプ
アプリケーション優先度
ボリュームの領域（例えば、ＬＢＡのサブセット）
ボリュームセッション
Ｉ／Ｏサイズ
データ特性タイプ
その他
（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい。
図８は、サービスプロバイダ、ユーザ、および／またはその他のエンティティがストレージシステム内で異なる使用状況の性能種別を動的に定義および／または作成すること、および／または、性能／ＱｏＳ関連カスタマイゼーションを定義することを可能にするように構成または設計されてもよいＱｏＳインターフェースＧＵＩ例８００を示す。少なくとも一実施形態では、ＱｏＳインターフェースＧＵＩは、サービスプロバイダ、ユーザ、および／または、その他のエンティティが異なる使用状況の性能種別を動的に切り替えることを可能にするように構成または設計されてもよく、このようなクライアントがオンザフライ（例えば、リアルタイム）で自身の性能設定値を動的に変更することを可能にする。
例えば、様々な実施形態によれば、サービスプロバイダは、ストレージシステム内で異なる使用状況の性能種別を動的に定義および／または作成することがあり、クライアントが異なる使用状況の性能種別を動的に切り替えることを可能にすることがあり、このようなクライアントがオンザフライ（例えば、リアルタイム）で自身の性能設定値を動的に修正または変更することを可能にする。少なくとも一実施形態では、ストレージシステムは、直ちに、性能／ＱｏＳ修正を実施するためにクライアントのストレージボリュームがオフラインで利用されることを要求することなく、指定されたプロビジョニング／ＱｏＳ目標に対する指定された変更を実施するように構成または設計されている。少なくとも一実施形態では、異なる使用状況の性能種別は、各々が、例えば、ＱｏＳパラメータおよび／またはプロビジョニング／ＱｏＳ目標タイプの様々の異なる組み合わせに基づくことがあるそれぞれのＱｏＳおよび／またはプロビジョニングルール（例えば、８１０）の集合を関連付けていることがある。
性能管理を実行する上記プロセスは、ある期間に亘って連続的に実行されてもよい。例えば、性能が調整されるべきか否かを評価するために５００ミリ秒の期間が使用される。より詳細に後述されるように、クライアント１０８は、実行されるＩＯＰＳの回数を低減または増大するために期間毎にある一定の時間に亘ってＩＯＰＳを実行することから締め出される。
図８のＱｏＳインターフェースＧＵＩを構成するために使用されてもよい異なるタイプの条件、規準および／またはその他の情報の例は、限定するものではないが、
境界条件例（例えば、８２４）
・負荷（サービス） ・日付
・負荷（読み出し） ・読み出しＩＯＰＳ
・負荷（書き込み） ・書き込みＩＯＰＳ
・負荷（書き込み＿バッファ） ・アプリケーションタイプ
・負荷（クライアント−読み出し） ・アプリケーション優先度
・負荷（クライアント−書き込み） ・ボリュームの領域
・負荷（クライアント） ・ＬＢＡ ＩＤ
・負荷（クラスタ） ・ボリュームセッションＩＤ
・負荷（システム） ・接続ＩＤ
・書き込みレイテンシー ・Ｉ／Ｏサイズ
・読み出しレイテンシー ・Ｉ／Ｏタイプ
・書き込みバッファキュー深度 ・作業負荷タイプ
・負荷（クライアント） ・重複排除能力
・ボリュームＩＤ ・圧縮率
・グループＩＤ ・データ内容
・アカウントＩＤ ・データタイプ
・クライアントＩＤ ・データ特性
・ユーザＩＤ ・検出可能な条件および／または事象
・ｉＳＣＳＩセッションＩＤ ・その他
・時間
ＱｏＳパラメータ例（例えば、８４２）
・最大ＩＯＰＳ ・最大読み出しＩ／Ｏ
・最小ＩＯＰＳ ・最小読み出しＩ／Ｏ
・バーストＩＯＰＳ ・バースト読み出しＩ／Ｏ
・最大帯域幅 ・最大書き込みＩ／Ｏ
・最小帯域幅 ・最小書き込みＩ／Ｏ
・バースト帯域幅 ・バースト書き込みＩ／Ｏ
・最大レイテンシー ・Ｉ／Ｏタイプ
・最小レイテンシー ・作業負荷タイプ
・バーストレイテンシー ・重複排除能力
・最大Ｉ／Ｏサイズ ・圧縮率
・最小Ｉ／Ｏサイズ ・データ内容
・バーストＩ／Ｏサイズ ・データタイプ
・Ｉ／Ｏタイプ ・請求額
プロビジョニング／ＱｏＳ目標例（例えば、８４４）
・クラスタＩＤ ・時間
・サービスＩＤ ・日付
・クライアントＩＤ ・読み出しＩＯＰＳ
・接続ＩＤ ・書き込みＩＯＰＳ
・ノードＩＤ ・アプリケーションタイプ
・ボリュームＩＤ ・アプリケーション優先度
・グループＩＤ ・ボリュームの領域
・アカウントＩＤ ・ＬＢＡ ＩＤ
・クライアントＩＤ ・ボリュームセッションＩＤ
・ユーザＩＤ ・接続ＩＤ
・ｉＳＣＳＩセッションＩＤ ・Ｉ／Ｏサイズ
・Ｉ／Ｏタイプ ・データ内容
・作業負荷タイプ ・データタイプ
・重複排除能力 ・データ特性
・圧縮率 ・その他
演算子例（例えば、８２６、８４６）
・等しい ・等しくない
・より小さい ・包含する
・より大きい ・包含しない
・以下である ・一致する
・以上である ・正規表現
・範囲内である
閾値例（例えば、８２８、８４８）
・英数字値 ・無作為タイプ
・数値 ・テキストタイプ
・数値範囲 ・映像タイプ
・時間間隔値当たりの数値 ・音声タイプ
（例えば、５０００ ＩＯＰＳ／秒） ・画像タイプ
・順次タイプ ・使用状況の性能種別値
ブール演算子例（例えば、８２５、８４５）
・ＡＮＤ ・ＮＡＮＤ
・ＯＲ ・ＮＯＲ
・ＸＯＲ ・ＸＮＯＲ
・ＮＯＴ
・ＥＸＣＥＰＴ
（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい。
以下のシナリオ例は、ＱｏＳインターフェースＧＵＩ ８００によって有効にされた様々な特徴および機能を例示するために役立ち、ストレージシステムの性能／ＱｏＳ関連プロビジョニング特徴を例示するために役立つ。
例Ａ−指定された時間ウィンドウの間にバックアップがより速く進むことを可能にするために自動的および／または動的にストレージ性能を高めるようにストレージシステムを構成／プロビジョニングする。例えば、一実施形態では、ボリュームバックアップ動作の速度は、最大ＩＯＰＳ値および／または最小ＩＯＰＳ値を特有の時間間隔中に自動的かつ動的に増加させることにより指定された時間間隔中に自動的かつ動的に増加されることがある。
例Ｂ−選択されたイニシエータが午後１０時から真夜中までより高速なシーケンシャルＩＯを実行することを自動的および／または動的に可能にするようにストレージシステムを構成／プロビジョニングする。
例Ｃ−選択されたアプリケーションがＩ／Ｏストレージ性能を高めることを自動的および／または動的に可能にするようにストレージシステムを構成／プロビジョニングする。
例Ｄ−選択されたクライアントのグループが毎月の選択された曜日／日付に自身のそれぞれの最大、最小およびバーストＩＯＰＳを２倍にすることを自動的および／または動的に可能にするようにストレージシステムを構成／プロビジョニングする。
例Ｅ−仮想ターボボタンを含む「ターボブースト」インターフェースをクライアントまたはユーザに提示するようにストレージシステムを構成／プロビジョニングする。クライアントは、（例えば、オンザフライまたはリアルタイムで）ターボボタンを手動で作動し、それによって、ストレージシステムにこのクライアントのためプロビジョニングされた性能のレベルを自動的かつ動的に増加させることを選ぶことがある。例えば、一実施形態では、ターボボタンのクライアント作動は、ストレージシステムにクライアントのプロビジョニングされた性能を１時間の間に３倍に自動的かつ動的に高めることがある。少なくとも一実施形態では、プロビジョニングされた性能の動的な増加は、所定の時間間隔後に、自動的に中断してもよい。少なくとも一実施形態では、ストレージシステムは、クライアントにターボブーストサービス／特徴の使用のため増加した請求額を負担させるように構成または設計されてもよい。
例Ｆ−特有の時刻により速く進むように（例えば、より高速なバックアップを可能にするために）高められたストレージアレイ性能を動的に提供するため追加料金または請求額を自動的および／または動的に負担するようにストレージシステムを構成／プロビジョニングする。
例Ｇ−１つ以上の指定された時間間隔中に最小閾値を上回るストレージシステムのＩＯＰＳおよび／またはＩ／Ｏアクセスに対する追加料金または請求額を自動的および／または動的に負担させるようにストレージシステムを構成／プロビジョニングする。
性能マネージャ１１４は、性能を調整する異なる方式を使用してもよい。図４は、一実装による性能マネージャ１１４を使用して性能を調整するより詳細な例を示す。目標性能マネージャ４０２は、目標性能値を決定する。一実装では、目標性能マネージャ４０２は、目標性能値を決定するためにクライアントのＱｏＳパラメータ、システムメトリクス、およびクライアントメトリクスを使用する。より詳細に後述されるように、システムメトリクスおよびクライアントメトリクスは、システム負荷およびクライアント負荷を決定するために使用されてもよい。一例として、クライアント負荷は、ＩＯＰＳ単位、バイト単位、またはミリ秒単位のレイテンシーなどのクライアントメトリクスに基づいて測定されてもよい。
一実装では、システムメトリクスは、クラスタの現在負荷を定量化するデータである。より詳細に後述されるように、様々なシステム負荷値は、システムメトリクスに基づいて計算されてもよい。負荷値は、正規化されたシステム負荷の尺度である。例えば、異なる負荷値は、負荷値がこれらの計算において異なるメトリクスを使用する場合であっても互いに比較されてもよい。一例として、システム負荷は、クラスタの現在負荷に基づいてパーセンテージで表現されてもよい。一例では、処理要求で過負荷状態であるクラスタは、システムが過負荷状態ではないときより低い値を有することがある。別の実施では、目標性能マネージャ４０２は、入力として、システムおよび／またはクライアントメトリクスではなく、計算負荷値を受信する。
目標性能マネージャ４０２は、クライアントＱｏＳパラメータ、関連性のあるシステムメトリクス、および関連性のあるクライアントメトリクスを読み取る可能性がある。これらの値は、クライアント１０８に対する目標性能値を決定するために使用されてもよい。ＱｏＳパラメータは、上位レベルの性能が要望される（例えば、顧客がより高いレベルの性能の代金を支払った）ときなど、前述のとおり管理者またはクライアントによるランタイム中にも動的に調整されてもよい。目標性能値の計算は、より詳細に後述される。
一実装では、目標性能マネージャ４０２は、ターゲット性能値を比例−積分−微分（ＰＩＤ）コントローラブロック４０４に出力する。ＰＩＤコントローラブロック４０４は、異なる性能メトリクスのためのある程度の台数のＰＩＤコントローラを含んでもよい。ＰＩＤコントローラについて記載されているが、その他のコントローラがクライアント１０８の性能を制御するために使用されてもよい。一例では、ＰＩＤコントローラブロック４０４は、ＩＯＰＳ、帯域幅、およびレイテンシーのためのＰＩＤコントローラを含む。目標性能マネージャ４０２は、性能メトリクスのための異なる目標性能値を適用可能なＰＩＤコントローラに出力する。ＰＩＤコントローラは、以前の、および／または、現在のクライアント性能に関する情報と目標性能値とをさらに受信する。例えば、ＰＩＤコントローラは、目標性能値と対応するクライアントメトリクス、システムメトリクス、および／または負荷値を受信することができる。ＰＩＤコントローラは、次に、クライアント性能調整値を決定することができる。例えば、ＰＩＤコントローラは、前のクライアント性能のフィードバックを利用し、システムを目標性能値に近付ける値を決定するように構成されている。例えば、ＰＩＤは、様々の量のプレッシャーを加えさせることが可能であり、この例では、プレッシャーは、ＩＯＰＳを実行する際にクライアント１０８を低速化する、高速化する、または、そのまま留まらせる。一例として、目標性能値が１１０ ＩＯＰＳであり、クライアント１０８が９０ ＩＯＰＳで動作している場合、クライアント性能調整値が出力され、このクライアント性能調整値は、クライアント１０８に適用されることにより、実行されているＩＯＰＳの回数を増大させるはずである。
一実装では、ＰＩＤコントローラブロック４０４は、性能調整値を出力する。一例として、性能調整値は、クライアントがストレージシステム内部でＩＯ動作を実行することから締め出されている時間を指示するプレッシャー値であってもよい。この締め出し時間は、クライアント性能を目標性能値に近付けるものである。例えば、クライアント１０８をボリュームから締め出す期間を決定するために使用されるミリ秒単位の時間が出力される。ＩＯ動作を実行することからクライアントを締め出すことは、クライアントのＩＯ動作にレイテンシーを人為的に導入する。実施のうちの別の実施では、性能調整値は、クライアントがある期間に実行できるＩＯ動作の回数であってもよい。クライアントがより多くのＩＯ動作を実行しようとする場合、クライアントは、後に続く期間まで、これらのＩＯ動作を行うことから締め出されてもよい。異なる時間に亘ってクライアント１０８をボリュームから締め出すことは、クライアント１０８によって実行されるＩＯＰＳの回数を変更する。例えば、短期間に亘ってボリュームからクライアント１０８を締め出すことは、この期間中にクライアント１０８によって実行されてもよいＩＯＰＳの回数を増加させる。
性能コントローラ４０９は、性能調整値を受信し、クライアント１０８の性能を制御するためにクライアント制御信号を出力する。例えば、締め出しの量は、０．５秒毎に計算され、適用されてもよい。一実装では、クライアント１０８は、インターネットスモールコンピュータシステムインターフェース（ｉＳＣＳＩ）コマンドウィンドウなどのコマンドウィンドウを閉じることおよび開くことにより締め出される。コマンドウィンドウを閉じることは、クライアント１０８がアクセス要求をボリュームに発行することを可能にすることがなく、コマンドウィンドウを開くことは、クライアント１０８がアクセス要求をボリュームに発行することを可能にする。ボリュームからクライアント１０８を締め出すことは、クライアント１０８に対するＩＯＰＳの回数、帯域幅、またはレイテンシーを調整してもよい。例えば、クライアント１０８が５００ミリ秒毎に４５０ミリ秒ずつボリュームから締め出されるのと比べて５００ミリ秒毎に５０ミリ秒ずつボリュームから締め出された場合、クライアントは、より多くのＩＯＰＳを発行してもよい。帯域幅の例では、帯域幅が抑制された場合、クライアント１０８は、可用帯域幅を増大させるためにより長い期間に亘ってボリュームから締め出される。別の実施では、同時にサービスされるデータの量は、システムがこのクライアントのＩＯをサービスする性能に影響を与えるために、零またはいくらかの量に修正される。
前述のとおり、ＩＯＰＳは、クライアントの性能を管理するために使用されてもよいメトリクスである。ＩＯＰＳは、書き込みＩＯＰＳおよび読み出しＩＯＰＳを共に含む。個別の入力／出力動作は、定められたサイズを持っていない。すなわち、入力動作は、６４ｋのデータをドライブに書き込むことであってもよいが、別の入力動作は、４ｋのデータをドライブに書き込むことであってもよい。その結果、ある期間に亘る入力／出力動作の生の回数を獲得することは、ＩＯ動作が現実にどの程度費用がかかるかを必ずしも獲得しない。この状況を考慮するために、入力／出力動作は、Ｉ／Ｏ動作のサイズに基づいて正規化されてもよい。この特徴は、各動作のデータのサイズとは無関係に、一貫性のあるＩＯＰＳの取り扱いを可能にさせる。この正規化は、性能曲線を使用して実現されてもよい。図５は、例示的な実装に係る、入力／出力動作のサイズをシステム負荷と比較して性能曲線５００を示す。線５０４は、完全負荷でのシステムを指示し、線５０２は、異なるサイズのＩＯ動作に対するシステムの負荷を指示する。性能曲線は、システム１００の経験的データに基づいて決定されてもよい。性能曲線は、異なるサイズのＩＯＰＳが比較され、異なるサイズのＩＯＰＳを正規化することを可能にする。例えば、サイズ３２ｋのＩＯＰは、４ｋのＩＯＰよりおおよそ５倍多くの費用がかかる。すなわち、システムの１００％負荷を実現するサイズ３２ｋのＩＯＰＳの回数は、サイズ４ｋのＩＯＰＳの回数のおおよそ２０％である。なぜならば、より大きいブロックサイズは、ＩＰを実行する効果を減じ、より小さいデータのブロックを処理する必要がないからである。様々な実施では、この曲線は、クライアントの目標性能値を決定する際に要因として使用されてもよい。例えば、クライアントに対する目標性能値が１０００回のＩＯＰＳであると決定される場合、この回数は、クライアントが過去に実行したＩＯの平均サイズに基づいて変更されてもよい。一例として、クライアントの平均ＩＯサイズが４ｋである場合、クライアントの目標性能値は、１０００ ＩＯＰＳに留まる可能性がある。しかし、クライアントの平均ＩＯサイズが３２ｋであると決定された場合、クライアントの目標性能値は、２００ ＩＯＰＳに、例えば、１０００×０．２に低減されてもよい。サイズ３２ｋの２００ ＩＯＰＳは、サイズ４ｋの１０００ ＩＯＰＳにおおよそ等しい。
目標性能値を決定するとき、目標性能マネージャ４０２は、クライアントに対する目標性能値を決定するためにクライアントのＱｏＳパラメータを使用する。一実装では、過負荷条件が検出され、全てのクライアントは、一貫性のある方式で絞られる。例えば、システム負荷が２０％であると決定された場合、全てのクライアントは、自身の目標性能値に自身の最大ＩＯＰＳ設定値の９０％が設定されるように絞られることがある。システム負荷が５０％まで増加する場合、全てのクライアントは、自身の目標性能値に自身の最大ＩＯＰＳ設定値の４０％を設定することに基づいて絞られる可能性がある。どの程度の過負荷条件が決定されるかについてのさらなる例が以下に与えられる。
クライアントは、同様の方式で絞られる必要がない。例えば、クライアントは、異なる種別に属することができる。一実装では、種別は、異なるクライアントのＱｏＳパラメータを別々に設定することにより簡単に実施することができる。例えば、プレミアム使用状況種別は、標準的な種別と比較して、より高いＱｏＳパラメータ、例えば、最小ＩＯＰＳ、最大ＩＯＰＳ、およびバーストＩＯＰＳ値を有することがあり得る。別の実施では、種別は、目標性能値を計算するときに考慮されてもよい。例えば、２つの異なる種別を考慮して、一方の種別がもう一方の種別より少なく絞られることがあり得る。上記シナリオ例を使用すると、第１の種別に属しているクライアントは、システム負荷が２０％に達するとき、自身の最大ＩＯＰＳ値の８０％に絞られることがあり得る。第２のクライアントの種別は、しかし、全く絞られないか、または、自身の最大ＩＯＰＳ値の９５％などの異なる量で絞られることがある。
別の実施では、クライアントの最小ＩＯＰＳと最大ＩＯＰＳとの間の差は、特有のクライアントをどの程度絞るべきかを判定するために使用されてもよい。例えば、大きい差を持つクライアントは、差が小さいクライアントより多く絞られる可能性がある。一実装では、クライアントの最大ＩＯＰＳと最小ＩＯＰＳとの間の差は、目標性能値を計算するために適用される要因を計算するために使用される。本実施では、要因は、５０００ ＩＯＰＳなどの何らかの所定のＩＯＰＳ量によって除算されたＩＯＰＳ差として決定されてもよい。本例では、自身の最大ＩＯＰＳと自身の最小ＩＯＰＳとの間の差が１００００であったクライアントは、ＩＯＰＳ差が５０００であったクライアントの２倍程度に絞られることになる。システムのクライアントは、自身の種別に基づいて異なる額を請求されてもよい。その結果、クライアントは、他の種別のクライアントより後に、および／または、より少なく絞られるように、より多く支払うことがあり得る。
別の実施では、クライアントの絞り込みは、クライアントによるシステムの使用に基づいてもよい。本実施では、目標性能マネージャ４０２は、どんなメトリクスが現在過負荷状態であるかを判定するためにシステムメトリクスを再調査することができる。次に、クライアントメトリクスは、このクライアントが過負荷状態のシステム値に寄与しているか否かを判定するために分析されてもよい。例えば、目標性能マネージャ４０２は、クラスタの書き込みレイテンシーが過負荷状態であるときにシステムが過負荷状態であると決定することができる。クライアントに対する読み出し／書き込み比率は、特有のクライアントが過負荷条件により大きい影響を有するか否かを判定するために使用されてもよい。本例を続けると、クライアントが読み出しより３倍多い書き込みを実行し、１５００回の書き込みを行ったというような読み出し／書き込み比率を持つクライアントは、クラスタの性能に悪影響を与えていると決定されるであろう。その結果、目標性能マネージャ４０２は、このクライアントを著しく絞ることがあり得る。一実装では、この特徴は、読み出し／書き込みＩＯＰＳ比率に基づいて要因を計算することにより行われる可能性がある。この要因は、上記クライアント例が高い読み出し／書き込みＩＯＰＳ比率をもつクライアントより多く絞られることになるように、目標性能値を計算するときに適用されてもよい。本例では、高い読み出し／書き込みＩＯＰＳ比率は、クライアントが書き込みより多くの読み出しを行っていることを指示する。要因は、各クライアントが行っているＩＯＰＳの回数にも基づいてもよい。その上、特有のクライアントに対するＩＯＰＳの回数は、特有のクライアントがどの程度激しくクラスタを使用しているかの指標が決定できるように、クラスタに対するＩＯＰＳの回数と比較されてもよい。この情報を使用して、目標性能マネージャは、クライアントが全ての他のクライアントと比べてシステムを使用している程度に基づいて、目標性能値に倍率を掛けるために使用されてもよい別の要因を計算することができる。
図６は、例示的な実装に係る、過負荷状態システムメトリクスをクライアントメトリクスと適合する性能管理を実行する方法６００の簡略化されたフローチャートを示す。方法６００の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。方法６００は、コンピューティングデバイスで実施することができる。一実装では、方法６００は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに方法６００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。
動作６０２では、クライアントメトリクスが決定されてもよい。例えば、性能マネージャ１１４は、前述のとおり、先行する期間、例えば、１００ｍｓ、１ｓ、１０ｓなどに亘ってクライアントメトリクスを決定することができる。動作６０４では、システムメトリクスが決定されてもよい。例えば、性能マネージャ１１４または別のプロセスは、前述のとおり、システムメトリクスを決定することができる。一実装では、クライアントメトリクスおよび／またはシステムメトリクスが１つ以上の負荷値を計算するために使用される。負荷値の計算は、詳細に後述される。動作６０６では、目標性能マネージャ４０２は、次に、様々な負荷値に基づく方式でシステムが過負荷状態であるか否かを判定することができる。例えば、目標性能マネージャ４０２は、システム負荷値を対応する閾値と比較することによりシステムが過負荷状態であるか否かを判定することができる。負荷値の対応する閾値を上回る何らかの負荷値は、過負荷状態を指示する。一実装では、システム負荷値は、優先順位が決められた順序で分析され、第１の過負荷状態負荷値がどのようにクライアントを絞るかを判定するために使用される。
動作６０８では、過負荷状態負荷値に関連付けられた１つ以上の対応するクライアントメトリクスが決定される。例えば、過負荷状態システム負荷が読み出し動作の回数である場合、クライアントの読み出し動作の回数は、関連したクライアントメトリクスとして使用されてもよい。クライアントのメトリクスは、過負荷状態システムメトリクスと同じである必要はない。別の例として、過負荷状態システム負荷が読み出しレイテンシーである場合、対応するクライアントメトリクスは、書き込みＩＯ動作に対する読み出しＩＯ動作の比率と、クライアントに対する読み出し動作の合計回数とであってもよい。動作６１０では、クライアント固有係数は、過負荷状態システム負荷値に関連付けられたクライアントメトリクスに基づいて決定される。上記第１の例では、要因は、クライアントによる読み出し動作の回数をクラスタの読み出し動作の合計回数で割ったものであってもよい。クライアント要因は、その結果、クライアントがシステム負荷値に寄与している程度と相対的になるであろう。比較的多数回の読み出しを行ったクライアントは、比較的少数回の読み出しを行ったクライアントと比べてより大きいクライアントメトリクスを有することになる。
動作６１２において、クライアント固有係数は、クライアントに対する目標性能値を計算するために使用される。一実装では、初期目標性能値が計算され、次に、クライアント固有係数が乗じられる可能性がある。別の実施では、クラスタ削減値が決定され、この値にクライアント固有係数が乗じられる。上記例を続けると、クラスタ削減値は、絞られるべき読み出しＩＯＰＳの回数であってもよい。クラスタ削減値に基づいて各クライアントを均一に絞ることに比べて、クライアント固有係数を使用することは、結果として、絞られる同じ回数の読み出しＩＯＰＳを生じるが、多数回の読み出しＩＯ動作を有するクライアントは、より少数回の読み出しＩＯ動作を有するクライアントより多く絞られる。クライアント固有係数を使用することは、絞り込みが有効であることを確実にするのに役立つように目標性能マネージャ４０２がクライアントの絞り込みを制御するために役立つ。例えば、クライアント固有係数が使用されることなく、絞り込みが全てのクライアントに亘って均一に適用された場合、システムの使用がシステムの過負荷に寄与しないクライアントは、絞り込まれる必要がないことになる。悪いことには、クライアントの全ての絞り込みは、絞り込まれる必要がないクライアントの絞り込みが過負荷条件を緩和するのに役立たないことになるので、有効ではないかもしれず、より一層多くの絞り込みがクライアントに適用されるという結果を招くことがあり得る。
動作６１４では、性能マネージャ１１４は、クライアント１０８の性能を調整することができる。例えば、クライアントによるシステムの使用は、前述のとおり絞り込まれる可能性がある。
上記システムを使用すると、クライアント１０８は、ＩＯＰＳなどの性能メトリクスに基づいて性能保証を提供されてもよい。例えば、システム１００がＩＯＰＳの合計回数を処理できると仮定すると、この合計回数は、この合計回数の範囲内のＩＯＰＳの回数に関して異なるクライアント１０８の間で分割されてもよい。ＩＯＰＳは、最小、最大、およびバーストを使用して割り当てられる。これが合計回数より多い場合、可能であれば、管理者は、過剰なＩＯＰＳが保証されていることが通知され、より多くの性能容量を追加するか、または、ＩＯＰ保証内容を変更するように命令される。この通知は、容量閾値（例えば、合計容量、または、合計容量より小さい所定の閾値）に達する前でもよい。この通知は、クライアント性能がＩＯＰＳの観点で特徴付けられているので、容量に達する前に送信される可能性があり、管理者は性能がＩＯＰＳの回数Ｎによって過剰にプロビジョニングされていることを警告されてもよい。例えば、クライアント１０８は、長期間に亘ってＩＯＰＳの最小回数と最大回数との間で（ある時点に最大を上回るバーストを伴って）動作することを保証されてもよい。性能マネージャ１１４は、上記システムを使用してこれらのＱｏＳパラメータの範囲内の性能を保証することが可能である。負荷が均一に分散されているので、ホットスポットが生じることはなく、システム１００は、恒常的におよそＩＯＰＳの合計量で動作してもよい。このようにして、ホットスポット問題なしに、かつ、システム１００が恒常的にＩＯＰＳの合計量を提供する能力がある状態で、各クライアントが所定のクライアント１０８毎のＱｏＳパラメータの範囲内で確実に動作しているように、クライアント１０８によって実行されるＩＯＰＳの回数が合計回数の範囲内で調整されているときに、クライアント１０８に対する性能が保証されてもよい。グローバル性能プールへの各クライアントの影響が測定され、かつ、予測可能であるので、管理者は、各々が独自の性能限界を伴う個別のノードではなく、クラスタの性能全体を性能プールとみなすことができる。この特徴は、クラスタが、自身のボリュームの全ての間に性能を届けるために、自身の性能を正確に特徴付け、自身の能力を保証することを可能にする。
その結果、性能管理は、分散データアーキテクチャに基づいて提供される。データは、クラスタ内の全てのドライブに亘って均一に分散されているので、各個別のボリュームの負荷もまたストレージシステム１００内の１つ１つのドライブに亘って均一である。この特徴は、ホットスポットを除去し、性能管理が正確であり、かつ、偏りなくプロビジョニングされ、個別のボリュームに対してクラスタ性能全体を保証してもよい。
負荷値計算
負荷値は、クライアントが全てのクライアントの間でＱｏＳを保証するのに役立つように絞られるべきであるか否かを判定するために使用されてもよい。様々な負荷値が１つ以上のシステムメトリクスおよび／またはクライアントメトリクスに基づいて計算されてもよい。一例として、クライアントのデータ読み出しレイテンシーに対応する負荷値が計算されてもよい。クライアントと符合する負荷値を計算するとき、クライアントのデータがストレージシステム上でどのように管理されるかが重要になる。
図９は、一例示的な実装に係る、ストレージシステムの一部を示す。図９の特定の実施形態例では、ストレージシステムは、ノード（９１２、９１４、９１６、および９１８）のクラスタ９１０を含むことが示されている。異なる実施形態によれば、各ノードは、例えば、１台以上のソリッドステートドライブ（ＳＳＤ）などの１台以上のストレージデバイスを含んでもよい。図９の実施形態例では、例示の目的のため、３つの異なるクライアント（例えば、クライアントＡ ９０２、クライアントＢ ９０４、およびクライアントＣ ９０６）が各々ストレージクラスタ９１０との間でデータの読み出し／書き込みに活発に関与していると仮定する。
付加的に、図９の実施形態例に示されるように、各ノードは、１つ以上のサービス（例えば、サービスＡ〜Ｈ）を関連付けていることがあり、各サービスは、特有の機能および／またはタスクの組を取り扱うように構成または設計されてもよい。例えば、図９の実施形態例に示されるように、サービスＡおよびＢは、ノード１（９１２）に関連していることがあり（および／または、このノード１（９１２）によって取り扱われることがあり）；サービスＣおよびＤは、ノード２（９１４）に関連していること(および／または、このノード２（９１４）によって取り扱われることがあり)；サービスＥは、ノード３（９１６）に関連していることがあり（および／または、このノード３（９１６）によって取り扱われることがあり）；サービスＦ、Ｇ、Ｈは、ノード４（９１８）に関連してもよい（および／または、このノード４（９１８）によって取り扱われることがある）。少なくとも一実施形態では、サービスのうちの１つ以上は、スライスサーバを実施するように構成または設計されてもよい。スライスサーバは、スライスサービス機能を提供するものとして説明することもできる。
付加的に、異なる実施形態によれば、所定のサービスは、少なくとも１つの１次的役割を関連付けていることがあり、さらに、１つ以上の２次的役割を関連付けていることがある。例えば、図９の実施形態例では、サービスＡは、少なくとも以下の機能、（１）サービスＡの１次的役割がクライアントＡの１次的スライスサービスとしての役割を果たすこと、および（２）サービスＡの２次的役割が、本例では、クライアントＡの書き込み要求（および／または、クライアントＡに対するその他のスライス関連メタデータ）をサービスＣに複製することを伴うクライアントＡに関係するデータ／メタデータ複製タスク（例えば、スライスサービス複製タスク）を取り扱うことを含むように構成または設計されていることを仮定する。このようにして、例えば、一実施形態では、クライアントＡから開始された書き込み要求は、サービスＡ ９０２ａで受信されてもよく、これに応答して、サービスＡは、以下の動作（または、これらの組み合わせ）のうちの１つ以上を実行および／または開始してもよい、
・サービスＡのスライスサーバで書き込み要求を処理すること、例えば、サービスＡのスライスサーバで関連メタデータを発生させること、および、記憶することを含んでもよい動作
・（必要に応じて）（書き込み要求の）データを（例えば、サービスＡによって管理された）ブロックストレージの第１の場所に保存させる動作
・書き込み要求（および／または関連したデータ／メタデータ）を複製のためサービスＣに転送する（９０２ｂ）動作。
少なくとも一実施形態では、サービスＣがクライアントＡ書き込み要求のコピーを受信したとき、サービスＣは、サービスＣのスライスサーバで書き込み要求を処理することにより応答することがあり、（必要に応じて）（書き込み要求の）データを複製または冗長性の目的のため（例えば、サービスＣによって管理された）ブロックストレージの第２の場所に保存させる。少なくとも一実施形態では、ブロックストレージの第１および第２の場所は、各々が異なる物理ノードに存在してもよい。同様に、サービスＡのスライスサーバおよびサービスＣのスライスサーバは、各々が異なる物理ノードで実施されてもよい。
その結果、図９の実施形態例では、クライアントＡ書き込み要求の処理は、クライアントＡ書き込み要求の処理は、２つの区別可能なブロックストレージ書き込み動作を伴うことがあり、−一方がサービスＡ（１次的サービス）によって開始され、もう一方がサービスＣ（冗長サービス）によって開始される。これに反して、サービスＡは、サービスＣを伴わないので、または、サービスＡは、必ずしもサービスＣを伴うことなく読み出し要求を取り扱うことができるので、クライアントＡ読み出し要求の処理は、（例えば、標準的な条件下で）サービスＡによってのみ取り扱われることがある。
例示の目的のため、図９の実施形態例では、サービスＥは、少なくとも以下の機能、（１）サービスＥの１次的役割がクライアントＢに対する１次的スライスサービスとして機能すること、および（２）サービスＥの２次的役割が、本例では、クライアントＢの書き込み要求（および／または、クライアントＢに対するその他のスライス関連メタデータ）をサービスＤに複製することを伴うクライアントＢに関係するデータおよび／またはメタデータ複製タスク（例えば、スライスサービス複製タスク）を取り扱うこと、を含むように構成または設計されていることを、さらに仮定する。このようにして、例えば、一実施形態では、クライアントＢから開始された書き込み要求は、サービスＥ ９０４ａで受信されてもよく、これに応答して、サービスＥは、以下の動作（または、これらの組み合わせ）のうちの１つ以上を実行および／または開始してもよい、
・サービスＥのスライスサーバで書き込み要求を処理すること、例えば、サービスＥのスライスサーバで関連メタデータを発生させること、および、記憶することを含んでもよい動作
・（必要に応じて）（書き込み要求の）データを（例えば、サービスＥによって管理された）ブロックストレージの第１の場所に保存させる動作
・書き込み要求（および／または関連したデータ／メタデータ）を複製のためサービスＤに転送する（９０４ｂ）動作。
少なくとも一実施形態では、サービスＤがクライアントＢ書き込み要求のコピーを受信したとき、サービスＤは、サービスＤのスライスサーバで書き込み要求を処理することにより応答することがあり、（必要に応じて）（書き込み要求の）データを複製または冗長性の目的のため（例えば、サービスＤによって管理された）ブロックストレージの第２の場所に保存させる。少なくとも一実施形態では、ブロックストレージの第１および第２の場所は、各々が異なる物理ノードに存在してもよい。同様に、サービスＥのスライスサーバおよびサービスＤのスライスサーバは、各々が異なる物理ノードで実施されてもよい。
異なる実施形態によれば、複数の複製を実施する（例えば、データ／メタデータがストレージシステム／クラスタ内部の２つ以上のその他の場所で複製される）ことも可能である。例えば、図９の実施形態例において示されるように、サービスＥは、少なくとも以下の機能、（１）サービスＥの１次的役割がクライアントＣに対する１次的スライスサービスとしての役割を果たすこと、（２）サービスＥの２次的役割が、本例では、クライアントＣの書き込み要求（および／または、クライアントＣに対するその他のスライス関連メタデータ）をサービスＣに複製することを伴うクライアントＣに関係するデータおよび／またはメタデータ複製タスク（例えば、スライスサーバ複製タスク）を含むように構成または設計されていること、および（３）サービスＥの２次的役割が、本例では、クライアントＣの書き込み要求（および／または、クライアントＣに対するその他のスライス関連メタデータ）をサービスＧに複製することを伴うクライアントＣに関係するデータおよび／またはメタデータ複製タスク（例えば、スライスサービス複製タスク）を取り扱うこと、を仮定する。このようにして、例えば、一実施形態では、クライアントＣから開始された書き込み要求は、サービスＥ ９０６ａで受信されてもよく、これに応答して、サービスＥは、以下の動作（またはこれらの組み合わせ）のうちの１つ以上を実行および／または開始してもよい。
・サービスＥのスライスサーバで書き込み要求を処理すること、例えば、サービスＥのスライスサーバで関連メタデータを発生させること、および、記憶することを含んでもよい動作
・（必要に応じて）（書き込み要求の）データを（例えば、サービスＥによって管理された）ブロックストレージの第１の場所に保存させる動作
・書き込み要求（および／または関連したデータ／メタデータ）を複製のためサービスＣに転送する（９０６ｂ）動作
・書き込み要求（および／または関連したデータ／メタデータ）を複製のためサービスＧに転送する（９０６ｃ）動作
少なくとも一実施形態では、サービスＣがクライアントＣ書き込み要求のコピーを受信したときに、サービスＣは、サービスＣのスライスサーバで書き込み要求を処理することにより応答することがあり、（必要に応じて）（書き込み要求の）データを複製または冗長性の目的のため（例えば、サーバＣによって管理された）ブロックストレージの第２の場所に保存させる。同様に、少なくとも一実施形態では、サービスＧがクライアントＣ書き込み要求のコピーを受信したとき、サービスＧは、サービスＧのスライスサーバで書き込み要求を処理することにより応答することがあり、（必要に応じて）（書き込み要求の）データを複製または冗長性の目的のため（例えば、サービスＧによって管理された）ブロックストレージの第３の場所に保存させる。
負荷値およびサービス品質（ＱｏＳ）分析
異なる実施形態によれば、ストレージシステムのＱｏＳ機能は、システムメトリクスおよび／またはクライアントメトリクスから決定された様々な負荷値を入力として使用してもよい。例えば、一実施形態では、ストレージシステムは、１つ以上のシステムリソースに負荷、ストレス、および／または過負荷が加えられる値を決定するのに役立つように読み出しおよび／または書き込み動作のため使用されるか、または、影響が与えられるシステムリソースを測定、追跡および／または分析するように構成または設計されてもよい。
少なくとも一実施形態では、異なるタイプのメトリクスが、１つ以上のシステムリソース（例えば、ノード、コンポーネント、サービスなど）に負荷、ストレス、および／または過負荷が加えられる程度を表現するために使用されてもよい負荷値を計算するために使用されてもよい。例えば、少なくとも一実施形態では、１つ以上の異なるタイプの負荷値が、様々なタイプのシステムリソースに負荷、ストレス、および／または、過負荷が加えられることがある相対的な程度を表現もしくは定量化するために自動的および／または動的に計算されてもよい。様々なタイプの負荷値の例は、限定するものではないが、以下（または、これらの組み合わせ）のうちの１つ以上を含んでもよい、
・例えば、システムで動いている識別されたサービスに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（サービス）。異なる実施形態によれば、負荷（サービス）値は、識別されたサービスに関連付けられた読み出しおよび／または書き込み動作に関係する読み出しレイテンシーおよび／または書き込みレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算されてもよい。サービスが複数のクライアントからの読み出し／書き込み動作を取り扱うために割り当てられている少なくとも一実施形態では、負荷（サービス）値は、サービスが割り当てられた複数のクライアントに関連付けられた読み出し／書き込み動作に原因がある読み出しレイテンシーおよび／または書き込みレイテンシーを反映してもよい。
・例えば、読み出しＩＯＰＳに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（読み出し）。異なる実施形態によれば、負荷（読み出し）値は、読み出しＩＯＰＳに関係するシステムレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算されてもよい。異なる実施形態によれば、負荷（読み出し）メトリクスは、以下の識別されたサービス、識別されたサービスのグループ、識別されたクライアント、識別された接続（例えば、クライアント接続）、識別されたボリューム（または、これの一部）、識別されたボリュームのグループ、識別されたノード、識別されたノードのグループ、および／または、その他の明確に識別されたシステムリソース（またはこれらの組み合わせの）のうちの１つ以上に関連付けられた読み出しＩＯＰＳに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現するように構成されてもよい。
・例えば、書き込みＩＯＰＳに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（書き込み）。異なる実施形態によれば、負荷（書き込み）値は、書き込みＩＯＰＳに関係するシステムレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算されてもよい。異なる実施形態によれば、負荷（書き込み）メトリクスは、以下の識別されたサービス、識別されたサービスのグループ、識別されたクライアント、識別された接続（例えば、クライアント接続）、識別されたボリューム（または、これの一部）、識別されたボリュームのグループ、識別されたノード、識別されたノードのグループ、および／または、その他の明確に識別されたシステムリソース（またはこれらの組み合わせの）のうちの１つ以上に関連付けられた書き込みＩＯＰＳに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現するように構成されてもよい。
・例えば、使用中の書き込みバッファキャッシュ容量の相対的な量を表現してもよい負荷（書き込み＿バッファ）。異なる実施形態によれば、負荷（書き込み＿バッファ）値は、書き込みバッファキャッシュの充填の割合に少なくとも部分的に基づいて、（リアルタイムで）自動的および／または動的に計算されてもよい。
・例えば、識別されたクライアントに対する読み出し、書き込みおよび複製動作を取り扱うために割り当てられたサービス（例えば、１次的サービスおよび２次的サービス）に関連付けられたＩＯアクティビティに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（クライアント）。異なる実施形態によれば、負荷（クライアント）値は、識別されたクライアントに対する読み出し、書き込みおよび複製動作を取り扱うために割り当てられたサービスに関係する読み出しレイテンシーおよび／または書き込みレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算されてもよい。
・例えば、識別されたクライアントに対する読み出し動作を取り扱うために割り当てられたサービスに関連付けられたＩＯアクティビティに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（クライアント−読み出し）。異なる実施形態によれば、負荷（クライアント−読み出し）値は、識別されたクライアントに対するＩＯ動作を取り扱うために割り当てられたサービスに関係する読み出しレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算される。
・例えば、識別されたクライアントに対する書き込み動作を取り扱うために割り当てられたサービスに関連付けられたＩＯアクティビティに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（クライアント−書き込み）。異なる実施形態によれば、負荷（クライアント−書き込み）値は、識別されたクライアントに対するＩＯ動作を取り扱うために割り当てられたサービスに関係する書き込みレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算される。
・例えば、識別されたリソース（例えば、キャッシュメモリ、ディスクストレージ空間、クラスタストレージ空間など）に関係するシステム負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（リソース）。異なる実施形態によれば、負荷（リソース）値は、以下の、クラスタレベルメトリクスおよび／またはドライブレベルメトリクス、読み出しレイテンシー、書き込みレイテンシー、１秒当たりの入力／出力動作回数（ＩＯＰＳ）、読み出しＩＯＰＳ、書き込みＩＯＰＳ、Ｉ／Ｏサイズ、書き込みキャッシュ容量、重複排除能力、圧縮率、合計帯域幅、読み出し帯域幅、書き込み帯域幅、読み出し／書き込み比率、作業負荷タイプ、データ内容、データタイプなど（またはこれらの組み合わせ）のうちの１つ以上に関係するリソース利用率／使用状況特性および／または性能特性に少なくとも部分的に基づいて、（リアルタイムで）自動的および／または動的に計算されてもよい。例えば、ストレージシステムの選択された部分に関係するシステム負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（システム）。
・例えば、識別されたサービスに対するディスク空間利用率（ＤＳＵ）の相対的な量を表現してもよい負荷（ＤＳＵ−サービス）。
・例えば、識別されたストレージクラスタに対するディスク空間利用率（ＤＳＵ）の相対的な量を表現してもよい負荷（ＤＳＵ−クラスタ）。
・例えば、識別されたストレージクラスタ（例えば、ストレージクラスタ９１０、図９）に関係するシステム負荷もしくはストレスの相対的な程度もしくは量を表現してもよい負荷（クラスタ）。
前掲のとおり、クライアント負荷値は、クライアントの読み出しレイテンシーおよび書き込みレイテンシーの両方のメトリクスに基づいて計算されてもよい。その上、別個のクライアント負荷値が読み出しレイテンシーメトリクスおよび書き込みレイテンシーメトリクスに基づいて計算されてもよい。少なくとも一実施形態では、ＱｏＳ測定に関係する１つ以上の態様は、（例えば、所定のクライアント、サービス、および／またはサービスのグループに対する）読み出し関連ＩＯＰＳと書き込み関連ＩＯＰＳとを監視し、区別することにより開始される、および／または、実現し易くされてもよい。例えば、一実施形態では、所定のサービス（例えば、サービスＡ）と相対的に読み出し関連動作に対するＱｏＳ実施を実現し易くするために、サービスＡに関連付けられたボリュームの読み出しレイテンシーは、監視されるおよび／または測定されてもよい。一実施形態では、所定のボリュームの読み出しレイテンシーは、システムが識別されたサービス（例えば、スライスサービス）と、データが読み取られる対応するブロックサービスとの間で行われたデータ読み出し動作を内部的にサービスし、完了するために要する時間に基づいて計算または決定されてもよい。
所定のサービス（例えば、サービスＡ）と相対的に書き込み関連動作に対するＱｏＳ実施を開始および／または実現し易くするために、サービスＡに関連付けられたボリュームの書き込みレイテンシーは、監視および／または測定されてもよい。一実施形態では、所定のボリュームの書き込みレイテンシーは、システムが識別されたサービス（例えば、スライスサービス）と、データが書き込まれる対応するブロックサービスとの間で行われたデータ書き込み動作を内部的にサービスし、完了するために要する時間に基づいて計算または決定されてもよい。
少なくとも一実施形態では、所定のクライアント（例えば、クライアントＡ ９０２）と相対的に書き込み関連動作に対するＱｏＳ実施を実現し易くするために、クライアントＡに関連付けられたサービス（例えば、サービスＡ、サービスＣ）の書き込みレイテンシーは、監視および／または測定されてもよい。例えば、一実施形態では、所定のクライアントに対する書き込みレイテンシーは、システムが、例えば、（ｉ）１次的スライスサービス（例えば、サービスＡ）によって取り扱われるデータ書き込み動作、および（ｉｉ）２次的（例えば、複製）サービス（例えば、サービスＣ）の各々によって取り扱われるデータ書き込み動作を含んでもよい関連したデータ書き込み動作を内部的にサービスし、完了するために要する時間に基づいて計算または決定されてもよい。
少なくともいくつかの実施形態では、（１つ以上の識別されたノードに対する）利用可能な書き込みバッファキャッシュ容量の程度もしくは量（例えば、割合）は、書き込みレイテンシー測定／計算を実行するときにさらに使用される、または、考慮されてもよい。例えば、少なくともいくつかの書き込み関連動作に対し、ストレージシステムは、例えば、（例えば、バッテリーバック付きＲＡＭ、Ｍａｒｖｅｌｌ（商標）などに関連付けられたメモリなどの）高速書き込みメモリを使用して実施されてもよい１つ以上の書き込みキャッシュ（または書き込みバッファ）を利用してもよい。少なくとも一実施形態では、ストレージシステムは、書き込みキャッシュに記憶されたキューに入れられた書き込みのサイズもしくは量を監視し、絞り込みクライアントを先行管理するためにこの情報を使用してもよい。
例えば、一実施形態では、所定の書き込みキャッシュ内のデータの量に関連付けられた負荷値が所定の閾値限界に接近するか、または、上回るときに、ストレージシステムは、例えば、（例えば、スライスサービス書き込みキャッシュからブロックストレージへの）データフラッシュプロセスは、入ってくるクライアント書き込みに遅れない可能性がないことが検出または決定された条件の間に、バックプレッシャーを加えることにより、ＱｏＳ規格を維持するのに役立つように適切な手順を自動的および／または動的に識別および／または実施する。いくつかの実施形態では、システムは、所定の閾値限界を満たす、または、上回る書き込みキャッシュを有するものと識別されたノードおよび／またはボリュームのサブセットだけにバックプレッシャーを加えることがある。
異なる実施形態によれば、ストレージシステムによって自動的および／または動的に開始および／または実施されてもよい手順の様々な例は、限定するものではないが、以下の（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい、
・１つ以上の選択されたサービス、ノード、ボリューム、クライアント、および／または接続に対する読み出しおよび書き出しＩＯＰＳを時間的に絞ること
・１つ以上の選択されたサービス、ノード、ボリューム、クライアント、および／または接続に対する読み出し関連ＩＯＰＳを時間的に絞ること
・１つ以上の選択されたサービス、ノード、ボリューム、クライアント、および／または接続に対する書き込み関連ＩＯＰＳを時間的に絞ること
・１つ以上の選択されたサービス、ノード、ボリューム、クライアント、および／または接続の間の内部メッセージ要求を保留すること
・および／または、システムリソース負荷もしくはストレスの相対的な程度もしくは量を削減または緩和するのに役立つことがあるその他のタイプのアクション／アクティビティ。
負荷計算例
異なる実施形態によれば、様々なタイプの手法および／またはコンピュータで実施されるアルゴリズムは、所望の負荷値を動的に計算するため使用されてもよい。例示の目的で、負荷計算手法のいくつかの異なる実施形態例が図９に示されたシステム実施形態例を参照して後述される。
負荷計算手法例Ａ
一実施形態では、図９に示されたシステム実施形態例を参照すると、それぞれの負荷（クライアント）値は、
負荷（クライアントＡ）＝ａ×負荷（サービスＡ）＋ｂ×負荷（サービスＣ）
負荷（クライアントＢ）＝ｃ×負荷（サービスＥ）＋ｄ×負荷（サービスＤ）
負荷（クライアントＣ）＝ｅ×負荷（サービスＡ）＋ｆ×負荷（サービスＣ）＋ｇ×負荷（サービスＧ）
に従って自動的および／または動的に計算されてもよく、式中、ａ、ｂ、ｃは、各々が０と１との間のそれぞれの値を有する重み付け変数（例えば、重み付け係数）であり、ここで、ａ＋ｂ＝１、ｃ＋ｄ＝１、かつｅ＋ｇ＋ｆ＝１である。
少なくとも一実施形態では、係数の値は、例えば、読み出し／書き込み作業負荷の測定された割合に基づいて（例えば、リアルタイムで）自動的および／または動的に調整されてもよい。
一実施形態では、図９に示されたシステム実施形態例を参照すると、識別されたサービス（サービス＿ＩＤ）に対する負荷（サービス）値は、
負荷（サービス＿ＩＤ）＝ｈ×負荷（読み出し＠サービス＿ＩＤ）
＋ｊ×負荷（書き込み＠サービス＿ＩＤ）
＋ｋ×負荷（書き込みバッファ＠サービス＿ＩＤ）
＋ｍ×負荷（ＤＳＵ−サービス＿ＩＤ）
に従って自動的および／または動的に計算されてもよく、式中、
・ｈ、ｊ、ｋ、ｍは、各々が０と１との間のそれぞれの値を有する重み付け変数（例えば、重み付け係数）であり、ここで、ｈ＋ｊ＋ｋ＋ｍ＝１であり、
・負荷（読み出し＠サービス＿ＩＤ）は、サービス＿ＩＤによって識別されたサービスにより取り扱われる読み出しＩＯＰＳに関連付けられたシステムリソース負荷／ストレスの相対的な程度もしくは量を表現する正規化値（例えば、０〜１の間）を表し、
・負荷（書き込み＠サービス＿ＩＤ）は、サービス＿ＩＤによって識別されたサービスにより取り扱われる書き込みＩＯＰＳに関連付けられたシステムリソース負荷／ストレスの相対的な程度もしくは量を表現する正規化値（例えば、０〜１の間）を表し
・負荷（書き込み＿バッファ＠サービス＿ＩＤ）は、サービス＿ＩＤによって識別されたサービスによる使用のため割り当てられたノードの書き込みキャッシュ上でキュー化されたキューに入れられた書き込み要求の相対的なサイズまたは量を表現する正規化値（例えば、０〜１の間）を表し、
・負荷（ＤＳＵ−サービス＿ＩＤ）は、サービス＿ＩＤによって識別されたサービスに対するディスク空間利用率（ＤＳＵ）の相対的な量を表現する正規化値（例えば、０〜１の間）を表す。
サービスが複数のクライアントからの読み出し／書き込み動作を取り扱うために割り当てられている少なくとも一実施形態では、負荷（読み出し）値は、サービスが割り当てられている複数のクライアントに関連付けられた読み出し動作に原因がある読み出しレイテンシーを反映してもよい。同様に、サービスが複数のクライアントからの読み出し／書き込み動作を取り扱うために割り当てられた場合、負荷（書き込み）値は、サービスが割り当てられている複数のクライアントに関連付けられた書き込み動作に原因がある書き込みレイテンシーを反映してもよい。
負荷計算手法例Ｂ
別の実施形態では、所定のクライアントに対する負荷（クライアント）値は、例えば、負荷（クライアント−読み出し）および負荷（クライアント−書き込み）を含んでもよい値の組から相対的に最も高い値を識別し、選択することにより自動的および／または動的に決定されてもよい。
このようにして、例えば、図９に示されたシステム実施形態例を参照すると、負荷（クライアントＡ）値は、
負荷（クライアントＡ）＝最大値｛（負荷（読み出し＠サービスＡ），
負荷（書き込み＠（サービスＡ），
負荷（書き込み＠サービスＣ）｝
に従って自動的および／または動的に計算されてもよく、式中、
・最大値｛ｘ，ｙ，ｚ｝は、集合｛ｘ，ｙ，ｚ｝から選択された相対的に最も高い値を返す関数を表し、
・負荷（読み出し＠サービスＡ）は、サービスＡによって取り扱われた読み出しＩＯＰＳに関連付けられたシステムリソース負荷／ストレスの相対的な程度もしくは量を表現する正規化値（例えば、０〜１の間）を表し、
・負荷（書き込み＠サービスＡ）は、サービスＡによって取り扱われた書き込みＩＯＰＳに関連付けられたシステムリソース負荷／ストレスの相対的な程度もしくは量を表現する正規化値（例えば、０〜１の間）を表し、
・負荷（書き込み＠サービスＣ）は、サービスＣによって取り扱われた書き込みＩＯＰＳに関連付けられたシステムリソース負荷／ストレスの相対的な程度もしくは量を表現する正規化値（例えば、０〜１の間）を表す。
同様に、それぞれの負荷（クライアントＢ）値および負荷（クライアントＣ）値は、各々が、
負荷（クライアントＢ）＝最大値｛（負荷（読み出し＠サービスＥ），
負荷（書き込み＠（サービスＥ），
負荷（書き込み＠サービスＤ）｝
負荷（クライアントＣ）＝最大値｛（負荷（読み出し＠サービスＥ），
負荷（書き込み＠（サービスＥ），
負荷（書き込み＠サービスＣ），
負荷（書き込み＠サービスＧ）｝
に従って自動的および／または動的に計算されてもよい。
負荷値データ構造体
図１０〜１２は、ストレージシステム内部の読み出し、書き込み、および複製機能を実現し易くするために使用されてもよい異なるタイプのデータおよびデータ構造体の実施形態例を示す。少なくとも一実施形態では、図１０〜１２のデータ構造体のうちの１つ以上の別個のインスタンスは、ストレージクラスタ（例えば、９１０）内部で動いているそれぞれのサービスに関連付けられ、それぞれのサービスがインスタンス化されている同じ物理ノードでインスタンス化され、更新されてもよい。異なる実施形態によれば、ストレージシステムは、図１０〜１２に示された様々なデータ構造体を周期的かつ動的に発生させ、投入し、更新するように構成または設計されてもよい。
図１０は、負荷−サービスデータ構造体１０００の特定の実施形態例を示す。少なくとも一実施形態では、負荷−サービスデータ構造体は、ストレージシステム内部で動いている異なるサービスに関連付けられたシステム負荷特性および条件を追跡するため構成または設計されてもよい。少なくとも一実施形態では、負荷−サービスデータ構造体１０００は、ストレージクラスタで動いている選択されたサービスに対する現在、または、更新負荷条件を追跡するため使用されてもよい。一実施形態では、負荷−サービスデータ構造体１０００は、ストレージクラスタで動いている各アクティブスライスサービスに対する現在、または、更新負荷条件を追跡するため使用されてもよい。
負荷−サービスデータ構造体１０００の実施形態例は、次に、図９に示されたストレージシステム構成に関連して一例として記載される。図１０の実施形態例に示されているように、負荷−サービスデータ構造体１０００は、ストレージクラスタ（例えば、９１０、図９）内部で明確に識別されたサービスに関係する複数のレコード（またはエントリー）（例えば、１００１、１００３、１００５）を含んでもよい。少なくとも一実施形態では、各レコードは、以下のタイプの情報（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい、
・ストレージクラスタで動いている特定のサービスを識別するサービス識別子情報（例えば、サービス＿ＩＤ １００２）
・識別されたサービスに関連付けられたリアルタイム（または準リアルタイム）のシステム負荷もしくはストレスの程度もしくは量を表す値（例えば、負荷（サービス）値）を含んでもよいシステム負荷情報（例えば、負荷（サービス）１００４）。
異なる実施形態によれば、所定のサービスに対する負荷（サービス）値は、識別されたサービスに関連付けられた読み出しおよび／または書き込み動作に関係する読み出しレイテンシーおよび／または書き込みレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）ストレージシステムによって自動的および／または動的に計算されてもよい。例えば、一実施形態では、システムは、負荷−サービスデータ構造体１０００を投入および／または更新するために負荷（サービス）分析手順１３００（図１３Ａ）を利用してもよい。
図１１は、ストレージシステム内部で動いている異なるサービスに関連付けられたシステム負荷特性および条件を追跡するため構成または設計されてもよい負荷−サービスデータ構造体１１００の代替的な実施形態例を示す。図１１の実施形態例に示されるように、負荷−サービスデータ構造体１１００は、ストレージクラスタ内部の明確に識別されたサービスに関係する複数のレコード（またはエントリー）（例えば、１１０１、１１０３、１１０５）を含んでもよい。少なくとも一実施形態では、各レコードは、
・ストレージクラスタで動いている特定のサービスを識別するサービス識別子情報（例えば、サービス＿ＩＤ １１０２）
・識別されたサービスに関連付けられた読み出し関連システム負荷もしくはストレスのリアルタイム（または準リアルタイム）の程度もしくは量を表す負荷（読み出し値を含んでもよい負荷（読み出し）情報１１０４
・識別されたサービスに関連付けられた書き込み関連システム負荷もしくはストレスのリアルタイム（または準リアルタイム）の程度もしくは量を表す負荷（書き込み）値を含んでもよい負荷（書き込み）情報１１０４
のタイプの情報（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい。
異なる実施形態によれば、負荷（読み出し）値は、識別されたサービスに関連付けられた読み出しＩ／Ｏレイテンシーの測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算されてもよい。異なる実施形態によれば、負荷（書き込み）値は、識別されたサービスに関連付けられた書き込みＩ／Ｏレイテンシーおよび／または書き込みキャッシュキュー深度の測定量に少なくとも部分的に基づいて、（例えば、リアルタイムで）自動的および／または動的に計算されてもよい。
図１２は、クライアント−サービスデータ構造体１２００の特定の実施形態例を示す。少なくとも一実施形態では、クライアント−サービスデータ構造体１２００は、ストレージクラスタと相互作用する各クライアントに関連付けられた読み出し／書き込み動作を取り扱うために割り当てられているそれぞれのサービスを追跡するため構成または設計されてもよい。例示の目的のため、図１２のクライアント−サービスデータ構造体実施形態例は、次に、図９に示されたストレージシステム構成を参照して一例として記載される。図１２の実施形態例に示されるように、クライアント−サービスデータ構造体１２００は、各々がストレージシステムの明確に識別されたクライアントに関係する複数のレコード（またはエントリー）（例えば、１２０１、１２０３、１２０５）を含んでもよい。少なくとも一実施形態では、各レコードは、
・特定のクライアント（例えば、クライアントＡ、クライアントＢ、クライアントＣなど）を識別するクライアント識別子情報（例えば、クライアント＿ＩＤ １２０２）。いくつかの実施形態では、ストレージクラスタと相互作用する各クライアントは、所定のクライアントに関連付けられている通信、要求（例えば、読み出し／書き込み要求）、アクティビティ、および／または、その他の情報を識別し、追跡するためにシステムによって使用されてもよいそれぞれに一意の接続識別子（接続＿ＩＤに関連してもよい。このようにして、例えば、一実施形態では、所定のクライアント−サービスデータレコード（例えば、１２０１）のクライアント＿ＩＤ部１２０２は、このクライアントの割り当てられた接続＿ＩＤ識別子を使用して表されてもよい。
・識別クライアントに起因する読み出し／書き込み要求のサービスを行うことを含む、識別されたクライアントとの通信を取り扱うために割り当てられた１次的スライスサービスを識別する１次的スライスサービス＿ＩＤ情報１２０４。
・例えば、識別されたクライアントに関連付けられたメタデータ（例えば、スライス）および／またはデータ複製タスクを取り扱うために割り当てられているサービスなどの、識別されたクライアントに関連付けられた１つ以上の２次的サービスを識別する関連した複製サービス＿ＩＤ情報１２０６
のタイプの情報（またはこれらの組み合わせ）のうちの１つ以上を含んでもよい。
少なくとも一実施形態では、クラスタ内の各ノードは、これの計算された負荷値を相互のノードに報告する。このようにして、各ノード（および／またはサービス）は、相互のノードの（および／またはサービスの）負荷値に関して通知されてもよい。この情報は、（例えば、クライアントが接続されているスライスサービスに関して）、このクラスタが使用しているクラスタ内のノードおよび／またはサービスの負荷値を決定するために使用されてもよい。
負荷値は、共有ノード／サービスリソース使用状況情報を使用して計算または決定されてもよい。いくつかの実施形態では、ストレージシステムは、例えば、以下（またはこれらの組み合わせ）、読み出し、書き込み、帯域幅、圧縮などのうちの１つ以上などの異なるシステム負荷値に起因するか、または、引き起こされた過負荷条件を区別するように構成または設計されてもよい。例えば、少なくとも一実施形態では、ストレージシステムは、システム（またはシステムの一部）が、読み出し過負荷状態、書き込み過負荷状態、帯域幅過負荷状態、圧縮過負荷状態などであることを決定してもよい。
少なくとも一実施形態では、（例えば、少なくとも１つのクライアントボリュームに一意であることがある）計算された負荷値は、それぞれのクライアント毎に実施される目標性能値を決定するために、クライアントメトリクスと共に、（図４の）目標性能マネージャ４０２によって使用されてもよい。
手続例およびフロー図
図１３〜１７は、本明細書に開示されたストレージシステムＱｏＳ態様のうちの１つ以上に関係するアクティビティを実現し易くするため使用されてもよい異なる手順および／または手順フローの様々な実施形態例を示す。
図１３Ａは、特定の実施形態に係る負荷（サービス）分析手順１３００のフロー図を示す。手順１３００の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１３００は、コンピューティングデバイスで実施することができる。一実装では、手順１３００は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１３００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、負荷（サービス）分析手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。少なくとも一実施形態では、負荷（サービス）分析手順は、ストレージクラスタで動いている１つ以上の選択されたサービスに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。特定の実施形態によれば、負荷（サービス）分析手順の複数のインスタンスまたはスレッドは、１台以上のプロセッサ、および／または、ハードウェアの組み合わせ、および／または、ハードウェアとソフトウェアとの組み合わせの使用によって並列に実施および／または開始されてもよい。
異なる実施形態によれば、負荷（サービス）手順の１つ以上の異なるスレッドまたはインスタンスが１つ以上の異なる時間間隔（例えば、特定の時間間隔中、規則的な周期的間隔、不規則的な周期的間隔、要求次第など）で自動的および／または動的に開始および／または実施されてもよい。
図１３Ａの実施形態例に示されるように、１３０２で、少なくとも１つの条件または事象が負荷（サービス）分析手順の実行を開始するため検出されていると仮定する。例えば、一実施形態では、負荷（サービス）分析手順の所定のインスタンスは、予定とおりに、例えば、５００ｍ秒毎に、１秒毎に、１０秒毎に、２０秒毎などに、自動的に動き、それによって、識別されたサービスに対する更新負荷（サービス）値を分析および決定するように構成または設計されてもよい。いくつかの実施形態では、所定のサービスに対する負荷（サービス）分析手順の実行の頻度は、例えば、システムメトリクス、クライアントメトリクス、ＱｏＳ管理ポリシーの変化などなどのその他の事象および／または条件に基づいて自動的および／または動的に変化してもよい。
１３０４に示すように、負荷（サービス）分析手順は、識別されたサービスに対するシステムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムおよび／またはクライアントメトリクスの分析は、識別されたサービスに関連付けられた読み出しおよび／または書き込み動作に対する読み出しレイテンシーおよび／または書き込みレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
１３０６に示すように、負荷（サービス）分析手順は、識別されたサービスに対する現在負荷（サービス）値を決定してもよい。異なる実施形態によれば、負荷（サービス）値は、例えば、本明細書に記載された様々な負荷計算手法のうちの１つ以上を使用して決定または計算されてもよい。
１３０８に示すように、選択されたサービスに対する現在計算負荷（サービス）値が以前計算された負荷（サービス）値から変化したか否かに関する決定が場合によっては行われる可能性がある。例えば、一実施形態では、負荷（サービス）分析手順は、ローカル負荷−サービステーブル（例えば、９００、図９）から、例えば、識別されたサービスに対する最新履歴負荷値を表すことがある負荷（サービス）値（例えば、９０４、図９）を取り出す、または、アクセスするために識別されたサービスのサービス＿ＩＤを使用してもよい。少なくとも一実施形態では、負荷（サービス）分析手順は、選択されたサービスに対する現在計算負荷（サービス）値が変化したか否かを判定するために現在計算負荷（サービス）値を負荷−サービステーブルから取り出された対応する負荷（サービス）値と比較してもよい。
一実施形態では、選択されたサービスに対する現在計算負荷（サービス）値が負荷−サービステーブルに記憶された負荷（サービス）値から変化していないと決定された場合、付加的なアクションは、この時点では必要とされないことがある。代替的に、選択されたサービスに対する現在計算負荷（サービス）値が負荷−サービステーブル計算負荷（サービス）値に記憶されたＳ負荷（サービス）値から変化したと決定された場合、選択されたサービスに対する現在計算負荷（サービス）値は、ローカル負荷−サービステーブルに記憶される（１３１０）。付加的に、選択されたサービスに対する負荷（サービス）値のこの更新に関係する情報および／または通知は、ストレージクラスタのその他のノードのうちの１つ以上にプッシュされてもよい（１３１２）。少なくとも一実施形態では、負荷（サービス）値更新通知を受信し次第、その他のノードは、更新負荷（サービス）値情報を使用して自身のそれぞれのローカル負荷−サービステーブルを自動的および動的に更新してもよい。
図１３Ｂは、特定の実施形態に係る負荷（読み出し）分析手順１３３０のフロー図を示す。手順１３３０の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１３３０は、コンピューティングデバイスで実施することができる。一実装では、手順１３３０は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１３３０の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、負荷（読み出し）分析手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。少なくとも一実施形態では、負荷（読み出し）分析手順は、ストレージクラスタで動いている１つ以上の選択されたサービスに関連付けられた読み出し関連トランザクションに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。
図１３Ｂの実施形態例に示されるように、１３３２で、少なくとも１つの条件または事象が負荷（読み出し）分析手順の実行を開始するため検出されていると仮定する。１３３４に示すように、負荷（読み出し）分析手順は、識別されたサービスに対する読み出し関連システムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムおよび／またはクライアントメトリクスの分析は、識別されたサービスによって取り扱われた（または識別されたサービスに関連付けられた）読み出し動作に対する読み出しレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
１３３６に示すように、負荷（読み出し）分析手順は、識別されたサービスに対する現在負荷（読み出し）値を決定してもよい。異なる実施形態によれば、負荷（読み出し）値は、例えば、本明細書に記載された様々な負荷計算手法のうちの１つ以上を使用して決定または計算されてもよい。
１３３８に示すように、選択されたサービスに対する現在計算負荷（読み出し）値が以前計算された負荷（読み出し）値から変化したか否かに関する決定が場合によっては行われる可能性がある。例えば、一実施形態では、負荷（読み出し）分析手順は、ローカル負荷−サービステーブル（例えば、１１００、図１１）から、例えば、識別されたサービスに対する最新履歴負荷（読み出し）値を表すことがある負荷（読み出し）値（例えば、１１０４、図１１）を取り出す、または、アクセスするために識別されたサービスのサービス＿ＩＤを使用してもよい。少なくとも一実施形態では、負荷（読み出し）分析手順は、選択されたサービスに対する現在計算負荷（読み出し）値が変化したか否かを判定するために現在計算負荷（読み出し）値を負荷−サービステーブル１１００から取り出された対応する負荷（読み出し）値と比較してもよい。
一実施形態では、選択されたサービスに対する現在計算負荷（読み出し）値が負荷−サービステーブルに記憶された負荷（読み出し）値から変化していないと決定された場合、付加的なアクションは、この時点では必要とされないことがある。代替的に、選択されたサービスに対する現在計算負荷（読み出し）値が負荷−サービステーブル計算負荷（読み出し）値に記憶されたＳ負荷（読み出し）値から変化したと決定された場合、選択されたサービスに対する現在計算負荷（読み出し）値は、ローカル負荷−サービステーブル１１００に記憶される（１３４０）。付加的に、選択されたサービスに対する負荷（読み出し）値のこの更新に関係する情報および／または通知は、ストレージクラスタのその他のノードのうちの１つ以上にプッシュされてもよい（１３４２）。少なくとも一実施形態では、負荷（読み出し）値更新通知を受信し次第、その他のノードは、更新負荷（読み出し）値情報を使用して自身のそれぞれのローカル負荷−サービステーブルを自動的および動的に更新してもよい。
図１３Ｃは、特定の実施形態に係る負荷（書き込み）分析手順１３５０のフロー図を示す。手順１３５０の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１３５０は、コンピューティングデバイスで実施することができる。一実装では、手順１３５０は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１３５０の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、負荷（書き込み）分析手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。少なくとも一実施形態では、負荷（書き込み）分析手順は、ストレージクラスタで動いている１つ以上の選択されたサービスに関連付けられた書き込み関連トランザクションに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。
図１３Ｃの実施形態例に示されるように、１３５２で、少なくとも１つの条件または事象が負荷（書き込み）分析手順の実行を開始するため検出されていると仮定する。１３５４に示すように、負荷（書き込み）分析手順は、識別されたサービスに対する書き込み関連システムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムおよび／またはクライアントメトリクスの分析は、識別されたサービスによって取り扱われた（または識別されたサービスに関連付けられた）書き込み動作に対する書き込みレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
１３５６に示すように、負荷（書き込み）分析手順は、識別されたサービスに対する現在負荷（書き込み）値を決定してもよい。異なる実施形態によれば、負荷（書き込み）値は、例えば、本明細書に記載された様々な負荷計算手法のうちの１つ以上を使用して決定または計算されてもよい。
１３５８に示すように、選択されたサービスに対する現在計算負荷（書き込み）値が以前計算された負荷（書き込み）値から変化したか否かに関する決定が場合によっては行われる可能性がある。例えば、一実施形態では、負荷（書き込み）分析手順は、ローカル負荷−サービステーブル（例えば、１１００、図１１）から、例えば、識別されたサービスに対する最新履歴負荷（書き込み）値を表すことがある負荷（書き込み）値（例えば、１１０６、図１１）を取り出す、または、アクセスするために識別されたサービスのサービス＿ＩＤを使用してもよい。少なくとも一実施形態では、負荷（書き込み）分析手順は、選択されたサービスに対する現在計算負荷（書き込み）値が変化したか否かを判定するために現在計算負荷（書き込み）値を負荷−サービステーブル１１００から取り出された対応する負荷（書き込み）値と比較してもよい。
一実施形態では、選択されたサービスに対する現在計算負荷（書き込み）値が負荷−サービステーブルに記憶された負荷（書き込み）値から変化していないと決定された場合、付加的なアクションは、この時点では必要とされないことがある。代替的に、選択されたサービスに対する現在計算負荷（書き込み）値が負荷−サービステーブル計算負荷（書き込み）値に記憶されたＳ負荷（書き込み）値から変化したと決定された場合、選択されたサービスに対する現在計算負荷（書き込み）値は、ローカル負荷−サービステーブル１０００に記憶される（１３６０）。付加的に、選択されたサービスに対する負荷（書き込み）値のこの更新に関係する情報および／または通知は、ストレージクラスタのその他のノードのうちの１つ以上にプッシュされてもよい（１３６２）。少なくとも一実施形態では、負荷（書き込み）値更新通知を受信し次第、その他のノードは、更新負荷（書き込み）値情報を使用して自身のそれぞれのローカル負荷−サービステーブルを自動的および動的に更新してもよい。
図１４は、特定の実施形態に係る負荷（クライアント）分析手順１４００のフロー図を示す。手順１４００の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１４００は、コンピューティングデバイスで実施することができる。一実装では、手順１４００は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１４００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、負荷（クライアント）分析手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。例えば、一実施形態では、負荷（クライアント）分析手順は、識別されたクライアントとの読み出し／書き込み通信を取り扱うため割り当てられた１次的スライスサーバによって開始および／または実行されてもよい。少なくとも一実施形態では、負荷（クライアント）分析手順は、ストレージシステムの１つ以上の選択されたクライアントに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。
特定の実施形態によれば、負荷（クライアント）分析手順の複数のインスタンスまたはスレッドは、１台以上のプロセッサ、および／または、ハードウェアおよび／またはハードウェアとソフトウェアとのその他の組み合わせの使用によって、並列に実施および／または開始されてもよい。一実施形態では、負荷（クライアント）分析手順の別個のインスタンスまたはスレッドは、ストレージシステムのそれぞれのクライアント毎に開始されてもよい。図１４の特定の実施形態例では、負荷（クライアント）分析手順は、選択されたクライアント（例えば、クライアントＡ、図９）に対する現在または更新負荷（クライアント）値を動的に決定するためにインスタンス化されている、と仮定する。
異なる実施形態によれば、負荷（クライアント）分析手順の１つ以上の異なるスレッドまたはインスタンスは、１つ以上の異なる時間間隔（例えば、特定の時間間隔中、規則的な周期的間隔、不規則的な周期的間隔、要求次第など）で自動的および／または動的に開始および／または実施されてもよい。例えば、一実施形態では、負荷（クライアント）分析手順の所定のインスタンスは、（例えば、所定のクライアントに対して）およそ１０〜２０秒毎に自動的に動き、それによって、識別されたクライアントに対する更新負荷（クライアント）値を分析し、決定するように構成または設計されてもよい。いくつかの実施形態では、所定のクライアントに対する負荷（クライアント）分析手順の実行の頻度は、例えば、システムメトリクス、クライアントメトリクス、ＱｏＳ管理ポリシーの変化などなどのその他の事象および／または条件に基づいて自動的および／または動的に変化してもよい。
図１４の実施形態例では、１４０２で、負荷（クライアント）分析手順の実行を開始する少なくとも１つの条件または事象が検出されている、と仮定する。１４０４に示すように、負荷（クライアント）分析手順は、システムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムおよび／またはクライアントメトリクスの分析は、識別されたクライアントに関連付けられた読み出し／書き込み動作に対する読み出しレイテンシーおよび／または書き込みレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
図１４の特定の実施形態例では、識別されたクライアント（例えば、クライアントＡ）に対する現在負荷（クライアント）値は、選択されたクライアントに関連付けられ、負荷（クライアント）値の計算に組み込まれるべき適切なサービスを識別すること（１４０６）を含んでもよい。本例では、負荷（クライアント）値は、識別されたクライアントに関連付けられているとして識別されている選択されたサービス（例えば、１次的スライスサービス、複製サービス）に対するリアルタイムシステム負荷を反映するクライアント固有値である、と仮定する。例えば、一実施形態では、負荷（クライアント）分析手順は、（例えば、負荷（クライアント）計算の目的のため）識別されたクライアントに関連付けられた特定のサービスを識別するためにローカルクライアント−サービスデータ構造体（例えば、１１００、図１１）からの情報にアクセスするように識別されたクライアントのクライアント＿ＩＤを使用してもよい。一例として、図１１のサービス−クライアントデータ構造体１１００の特定の実施形態例を参照すると、識別されたクライアントがクライアントＡに対応すると仮定する場合、クライアントＡに関連付けられた特定のサービスは、（例えば、クライアントＡの１次的スライスサーバとして割り当てられている）サービスＡ、および、（クライアントＡデータ／メタデータの複製を取り扱うクライアントＡの２次的サービスとして割り当てられている）サービスＣとして識別されてもよい。
１４０８に示すように、識別されたクライアントに対する現在負荷（クライアント）値は、動的に決定または計算されてもよい。異なる実施形態によれば、例えば、本明細書に記載された様々な負荷（クライアント）計算手法のうちの１つ以上を使用して負荷（クライアント）値は、動的に決定または計算されてもよい。例えば、一実施形態では、クライアントＡに対する現在負荷（クライアント）値は、
負荷（クライアントＡ）＝最大値｛（負荷（読み出し＠サービスＡ），
負荷（書き込み＠（サービスＡ），
負荷（書き込み＠サービスＣ）｝
に従って動的に計算されてもよい。
少なくとも一実施形態では、計算負荷(クライアント)値は、識別されたクライアントに対する読み出し、書き込みおよび複製動作を取り扱うために割り当てられているサービス（例えば、１次的サービスおよび２次的サービス）に関連付けられたＩＯアクティビティに関係するシステムリソース負荷もしくはストレスの相対的な程度もしくは量を表すことがある。少なくとも一実施形態では、ストレージシステムは、読み出し関連トランザクションと書き込み関連トランザクションとを区別し、識別されたクライアントに関連付けられた負荷(読み出し)値および負荷(書き込み)値を別々に分析、決定、および／または追跡するように構成または設計されてもよい。このような手法の実施形態例は、例えば、図１６、１７、２０および２１に例示され、より詳しく後述される。
ストレージシステムにおけるＱｏＳ実施に関する一問題は、比較的「低い」重要度をもつクライアントは、ストレージシステム内のレイテンシー増加を引き起こすか、または、レイテンシー増加に寄与することがあり、比較的高い重要度をもつ（例えば、比較的高い最小ＱｏＳ性能保証を伴う）クライアントがシステムの偏りのない、比例スループットを確保することをより一層困難にする。
図９に関連して一例として、ストレージクラスタ９１０は、以下のＱｏＳパラメータ保証を実施するように構成されている、と仮定する、
・クライアントＡ（９０２）ボリュームが最小ＩＯＰＳ １５ｋに設定されること
・（クライアントＢおよびＣを含む）４０個のその他のクライアントボリュームが最小ＩＯＰＳ １ｋに設定されること
・各クライアントのＩＯが８０％読み出しＩＯＰＳおよび２０％書き込みＩＯＰＳであること
・各ＩＯトランザクションのサイズが４ｋＢであること。
本実施形態例では、例示の目的のため、ストレージシステムは、クライアントＡに指定された最小保証された１５ｋ ＩＯＰＳを提供できない、と仮定されてもよい。さらに、本例では、何らかの読み出しレイテンシー増加は、重い読み出し作業負荷を駆動しているその他の４０個のクライアントボリュームによって引き起こされる、と仮定する。少なくとも一実施形態では、ストレージシステムは、クライアントＡ作業負荷が重い読み出しＩＯＰＳであるので、書き込みベースの負荷値が、クライアントＡが自身の最小ＩＯＰＳ保証を達成できないことの一因となる読み出しレイテンシーの検出された増加に重大な役割を果たさないことがあることを動的に決定するように構成または設計されてもよい。
目標性能値計算
前述のとおり、目標性能マネージャ４０２は、システム負荷値、クライアント負荷値、およびクライアントＱｏＳパラメータに基づいて目標性能値を計算する。目標性能値は、次に、クライアントがストレージシステムのリソースにどのようにアクセスできるかを制御するために使用される。
図１５は、特定の実施形態に係るＱｏＳクライアントポリシー管理手順１５００のフロー図を示す。手順１５００の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１５００は、コンピューティングデバイスで実施することができる。一実装では、手順１５００は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１５００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、ＱｏＳクライアントポリシー管理手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。例示の目的のため、ＱｏＳクライアントポリシー管理手順１５００は、選択されたクライアント（例えば、クライアントＡ、図９）に対するＱｏＳクライアントポリシー管理を実行するためにインスタンス化されている、と仮定する。
一実施形態では、ＱｏＳクライアントポリシー管理手順は、ストレージシステムの１つ以上の選択されたクライアントに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。特定の実施形態によれば、ＱｏＳクライアントポリシー管理手順の複数のインスタンスまたはスレッドは、１台以上のプロセッサ、および／または、ハードウェアおよび／またはハードウェアとソフトウェアとのその他の組み合わせの使用によって、並列に実施および／または開始されてもよい。一実施形態では、ＱｏＳクライアントポリシー管理手順の別個のインスタンスまたはスレッドは、ストレージシステムのそれぞれのクライアント毎にＱｏＳクライアントポリシー管理手順を実行または実現し易くするため開始されてもよい。
異なる実施形態によれば、ＱｏＳクライアントポリシー管理手順の１つ以上の異なるスレッドまたはインスタンスは、１つ以上の異なる時間間隔（例えば、特定の時間間隔中、規則的な周期的間隔、不規則的な周期的間隔、要求次第など）で自動的および／または動的に開始および／または実施されてもよい。例えば、一実施形態では、ＱｏＳクライアントポリシー管理手順の所定のインスタンスは、（例えば、所定のクライアントに対して５００ｍｓ毎に）およそ２５０〜１０００ミリ秒毎に自動的に動き、それによって、識別されたクライアントに対する更新負荷（クライアント）値を分析し、決定するように構成または設計されてもよい。いくつかの実施形態では、所定のクライアントに対するＱｏＳクライアントポリシー管理手順の実行の頻度は、例えば、システムメトリクス、クライアントメトリクス、ＱｏＳ管理ポリシーの変化などなどのその他の事象および／または条件に基づいて自動的および／または動的に変化してもよい。
図１５の実施形態例では、１５０２で、ＱｏＳクライアントポリシー管理手順の実行を開始する少なくとも１つの条件または事象が検出されている、と仮定する。１５０４に示すように、ＱｏＳクライアントポリシー管理手順は、システムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムおよび／またはクライアントメトリクスの分析は、識別されたクライアントに対する読み出し、書き込みおよび複製動作を取り扱うために割り当てられているサービス（例えば、１次的サービスおよび２次的サービス）に関連付けられたＩＯアクティビティに対する読み出しレイテンシーおよび／または書き込みレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
１５０６に示すように、ＱｏＳクライアントポリシー管理手順は、識別されたクライアントに対する現在負荷（クライアント）値を決定してもよい。異なる実施形態によれば、負荷（クライアント）値は、例えば、本明細書に記載された様々な負荷(クライアント)計算手法のうちの１つ以上を使用して決定または計算されてもよい。図１５の特定の実施形態例では、負荷（クライアント）値は、識別されたクライアントに対する読み出し、書き込みおよび複製動作を取り扱うために割り当てられているサービス（例えば、１次的サービスおよび２次的サービス）に関連付けられたＩＯアクティビティに対する読み出しレイテンシーおよび書き込みレイテンシーの両方のメトリクスに寄与するクライアント固有負荷値である、と仮定する。
１５０８で、ＱｏＳクライアントポリシー管理手順は、現在負荷（クライアント）値を分析し、これに応答して、識別されたクライアントに対する適切なＱｏＳ管理ポリシーを選択し実施してもよい。例えば、図１５の実施形態例に示されるように、
・負荷(クライアント)＜閾値Ａ１であると決定された場合、ＱｏＳクライアントポリシー管理手順は、ＱｏＳ管理ポリシー集合Ａ１を実施してもよい（１５１０）
・閾値Ａ１≧負荷(クライアント)≧閾値Ａ２であると決定された場合、ＱｏＳクライアントポリシー管理手順は、ＱｏＳ管理ポリシー集合Ｂ１を実施してもよい（１５１２）
・負荷（クライアント）＞閾値Ａ２であると決定された場合、ＱｏＳクライアントポリシー管理手順は、ＱｏＳ管理ポリシー集合Ｃ１を実施してもよい（１５１４）。
少なくとも一実施形態では、ストレージシステムは、（１）読み出し関連トランザクションと書き込み関連トランザクションとを区別し、所定のクライアントに関連付けられた負荷（クライアント−読み出し）値および負荷（クライアント−書き込み）値を別個に分析し、決定し、および／または、追跡し（２）クライアント関連読み出しＩＯＰＳおよびクライアント関連書き込みＩＯＰＳに対する異なるそれぞれのＱｏＳ管理ポリシー集合を独立に評価し実施するように構成または設計されてもよい。このような手法の実施形態例は、例えば、図１６、１７、２０、および２１に例示され、より詳細に後述されている。
図１８は、ストレージシステムが図１５に関連して記載されているようなＱｏＳクライアントポリシー管理手順の態様を実施する方法を示すグラフを示す。図１８の実施形態例に示されるように、クライアントＩＯＰＳ １８１０（例えば、読み出しおよび書き込みの両方のＩＯＰＳ）に対応する目標性能値を表現するＹ軸と、選択された負荷値（負荷Ａ、１８０１）を表現するＸ軸とを含むＸ−Ｙグラフ部１８００が表される。例示の目的のため、負荷Ａは、選択されたクライアント（例えば、クライアントＡ）に対する負荷（クライアント）メトリクスに対応する、と仮定する。しかし、代替的な実施形態（図示せず）では、負荷Ａは、例えば、以下（またはこれらの組み合わせ）、負荷（サービス）負荷（読み出し）負荷（書き込み）負荷（書き込み＿バッファ）負荷（クライアント−読み込み）負荷（クライアント−書き込み）などのうちの１つ以上などの本明細書に記載された種々の異なるメトリクスのうちの１つに対応してもよいことが認められるであろう。
図１８の実施形態例に示されるように、グラフ部１８００は、識別されたクライアントに対する最小ＩＯＰＳ ＱｏＳパラメータ１８０５；最大ＩＯＰＳ ＱｏＳパラメータ１８０５；および最大バーストＩＯＰＳ ＱｏＳパラメータ１８０７を表す基準線１８０３、１８０５、１８０７を含む。付加的に、グラフ部１８００は、本実施形態例では、識別されたクライアントに対して効力のある現在ＱｏＳ管理ポリシー集合を決定し選択するために使用されてもよい閾値を表す基準線１８１１、１８１３、１８１５を含む。例えば、図１８に示されているように、
・負荷Ａ＜閾値Ａ１である時間中に、ＱｏＳ管理ポリシー集合Ａ１が識別されたクライアントに対して有効に設定されてもよい。図１８の特定の実施形態例では、領域１８０２は、クライアントがＱｏＳ管理ポリシー集合Ａ１に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ａ１は、クライアントがＩＯＰＳクレジットを生じることを許可されること、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータ１８０５以下になる可能性があること、クライアントが生じたクレジットに基づいてクライアントの最大バーストＩＯＰＳ ＱｏＳパラメータを上回って動作することが許可されてもよいが、クライアントの最大バーストＩＯＰＳ ＱｏＳパラメータ１８０７を上回るべきではないことを指定してもよい。
・閾値Ａ１≧負荷Ａ≧閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｂ１が識別されたクライアントに対して有効に設定されてもよい。図１８の具体的な実施形態例では、領域１８０４は、クライアントが実行することができるＩＯＰＳの範囲のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｂ１は、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータと最小ＩＯＰＳ ＱｏＳパラメータとの間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。クライアントは、当然ながら、クライアントによるストレージシステムの使用状況に依存して、最小ＩＯＰＳより小さいＩＯＰＳを使用することができる。付加的に、ＱｏＳ管理ポリシー集合Ｂ１は、（ｉ）クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータを上回るべきではないこと、および（ｉｉ）クライアントのＩＯＰＳの絞り込みがクライアントの負荷（クライアント）値が閾値Ａ１（１８１１）から閾値Ａ２（１８１３）まで増加するのにつれて増加することをさらに指定してもよい。
・負荷Ａ＞閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｃ１が識別されたクライアントに対して有効に設定されてもよい。図１８の特定の実施形態例では、領域１８０６は、クライアントがＱｏＳ管理ポリシー集合Ｃ１に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｂ１は、クライアントのＩＯＰＳがクライアントの最小ＩＯＰＳ ＱｏＳパラメータと零との間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｃ１は、クライアントのＩＯＰＳの絞り込みがクライアントの負荷（クライアント）値が閾値Ａ２（１８１３）から閾値Ａ３（１８１５）まで増加するのにつれて増加することをさらに指定してもよい。
図１９Ａは、クライアントＩＯＰＳを絞る異なるＱｏＳ管理ポリシー集合が変化する負荷（クライアント）条件に応答して自動的および／または動的に実施される方法の実施形態例を示すグラフを示す。図１９Ａの実施形態例に示されるように、クライアントＩＯＰＳ １９１０（例えば、読み出しおよび書き込みの両方のＩＯＰＳ）に対応する目標性能値を表現するＹ軸と、選択されたクライアント（例えば、クライアントＡ）に対するクライアント負荷（クライアント）メトリクスを表現するＸ軸とを含むＸ−Ｙグラフ部１９００が表される。図１９Ａの実施形態例に示されるように、グラフ部１９００は、識別されたクライアントに対する最小ＩＯＰＳ ＱｏＳパラメータ１９０５最大ＩＯＰＳ ＱｏＳパラメータ１９０５および最大バーストＩＯＰＳ ＱｏＳパラメータ１９０７を表す基準線１９０３、１９０５、１９０７を含む。付加的に、グラフ部１９００は、本実施形態例では、識別されたクライアントに対して効力のある現在ＱｏＳ管理ポリシー集合を決定し選択するために使用されてもよい閾値を表す基準線１９１１、１９１３、１９１５を含む。例えば、図１９Ａに示されているように、
・負荷（クライアント）＜閾値Ａ１である時間中に、ＱｏＳ管理ポリシー集合Ａ１が識別されたクライアントに対して有効に設定されてもよい。図１９Ａの特定の実施形態例では、領域１９０２は、クライアントがＱｏＳ管理ポリシー集合Ａ１に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ａ１は、クライアントがＩＯＰＳクレジットを生じることを許可されること、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータ１９０５以下になる可能性があること、クライアントが生じたクレジットに基づいてクライアントの最大バーストＩＯＰＳ ＱｏＳパラメータを上回って動作することが許可されてもよいが、クライアントの最大バーストＩＯＰＳ ＱｏＳパラメータ１９０７を上回るべきではないことを指定してもよい。一実施形態では、閾値Ａ１は、０．２〜０．４の範囲に含まれる数値（例えば、閾値Ａ１＝０．３３）であるように定義されてもよい。
・閾値Ａ１≧負荷（クライアント）≧閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｂ１が識別されたクライアントに対して有効に設定されてもよい。図１９Ａの具体的な実施形態例では、領域１９０４は、クライアントがＱｏＳ管理ポリシー集合Ｂ１に従って動作することができる考えられるＩＯＰＳの値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｂ１は、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータと最小ＩＯＰＳ ＱｏＳパラメータとの間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｂ１は、所定の時点に（閾値Ａ１≧負荷（クライアント）≧閾値Ａ２である間）、クライアントのＩＯＰＳは、クライアントの現在（例えば、リアルタイム）負荷（クライアント）値に基づいて動的に決定された目標性能ＩＯＰＳ値に絞られるべきであることを指定することもある。例えば、図１９Ａの実施形態例では、ＱｏＳ管理ポリシー集合Ｂ１が有効である間に、クライアントのＩＯＰＳは、（例えば、クライアントの現在（クライアント）値と相対的にクライアントの許容ＩＯＰＳの上限を定義する）境界曲線１９０４ａによって定義された対応するＩＯＰＳ値を上回ることがない目標性能ＩＯＰＳ値に絞られるべきである。一実施形態では、閾値Ａ２は、０．５〜０．８の範囲に含まれる数値（例えば、閾値Ａ２＝０．６６）であるように定義されてもよい。
・負荷（クライアント）＞閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｃ１が識別されたクライアントに対して有効に設定されてもよい。図１９Ａの特定の実施形態例では、領域１９０６は、クライアントがＱｏＳ管理ポリシー集合Ｃ１に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｃ１は、クライアントのＩＯＰＳがクライアントの最小ＩＯＰＳ ＱｏＳパラメータと零との間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｃ１は、所定の時点に（負荷（クライアント）＞閾値Ａ２）、クライアントのＩＯＰＳがクライアントの負荷（クライアント）値に基づいて動的に決定された目標性能ＩＯＰＳ値に絞られるべきことをさらに指定する。例えば、図１９Ａの実施形態では、ＱｏＳ管理ポリシー集合Ｃ１が有効である間に、クライアントのＩＯＰＳは、（例えば、クライアントの現在（クライアント）値と相対的にクライアントの許容ＩＯＰＳの上限を定義する）境界曲線１９０６ａによって定義された対応するＩＯＰＳ値を上回ることがないＩＯＰＳ値に絞られるべきである。一実施形態では、閾値Ａ３は、０．７５〜１．０の範囲に含まれる数値（例えば、閾値Ａ３＝０．８５）であるように定義されてもよい。
異なる実施形態によれば、ＱｏＳ管理ポリシー集合（およびこれらに関連付けられたＩＯＰＳ境界曲線）は、クライアント固有でもよく、その結果、１つ以上のクライアントに対して異なることがある。例えば、一実施形態では、クライアントＡに対して実施されてもよいＱｏＳ管理ポリシー集合は、クライアントＢおよびＣに対して実施されたＱｏＳ管理ポリシー集合とは異なることがある。付加的に、少なくとも一実施形態では、ＩＯＰＳ絞り込みは、１クライアント当たりに複数の異なるクライアントに亘って独立に実施され、管理されてもよい。
例えば、図１９Ｂは、ＱｏＳ管理およびＩＯＰＳ絞り込みがストレージシステムの複数の異なるクライアント（例えば、クライアントＡ、クライアントＢ、クライアントＣ）に対して同時、独立、および動的に実施される方法を示す実施形態例を示す。図１９Ｂの実施形態例に示されるように、クライアントＩＯＰＳ １９１０（例えば、読み出しおよび書き込みの両方のＩＯＰＳ）に対応する目標性能値を表現するＹ軸と、クライアント負荷（クライアント）値を表現するＸ軸とを含むＸ−Ｙグラフ部１９５０が表される。
図１９Ｂの実施形態例に示されるように、グラフ部１９５０は、各クライアントの最小ＩＯＰＳ ＱｏＳパラメータ１９０３、最大ＩＯＰＳ ＱｏＳパラメータ１９０５、および最大バーストＩＯＰＳ ＱｏＳパラメータ１９０９の表示を含む。付加的に、グラフ部１９５０は、本実施形態例では、各クライアントに対するＱｏＳ管理および／またはＩＯＰＳ絞り込みを決定するため使用されるべき特有のＱｏＳ管理ポリシー集合を決定するために使用されてもよい閾値を表現する基準線１９１１、１９１３、１９１５を含む。
図１９Ｂの特定の実施形態例において、例示の簡略化のため、クライアントＡ、Ｂ、Ｃに対する最小ＩＯＰＳ、最大ＩＯＰＳ、および最大バーストＩＯＰＳ値が同一である、と仮定する。しかし、その他の実施形態では、クライアントＡ、Ｂ、Ｃに対するそれぞれの最小ＩＯＰＳ、最大ＩＯＰＳ、および最大バーストＩＯＰＳ値は、クライアント毎に異なることがある。同様に、例示の簡略化のため、同じ負荷閾値（例えば、Ａ１、Ａ２、Ａ３）がクライアントＡ、Ｂ、Ｃに適用される、と仮定する。しかし、その他の実施形態では、各クライアントは、このクライアントのため使用されるべき特有のＱｏＳ管理ポリシー集合を決定するため使用されてもよい負荷閾値のそれぞれの集合を関連付けていることがある。
図１９Ｂの実施形態例に示されるように、例示の目的のため、クライアントＡの現在負荷値（「負荷(クライアントＡ)」）１９６２は、負荷(クライアント)閾値Ａ１未満であると考えられる負荷（クライアントＡ）＝０．２３となるように計算されている、と仮定する。その結果、本実施形態例では、ストレージシステムは、ＱｏＳ管理ポリシー集合Ａ１がクライアントＡに対する目標ＩＯＰＳ値を決定するため使用されるべきであると決定してもよい。
このようにして、例えば、図１９Ｂの実施形態例では、クライアントＡに対する目標ＩＯＰＳ値は、負荷（クライアントＡ）値がＱｏＳ管理ポリシー集合Ａ１（「ＱＭＰＡ１」）曲線１９０２ａと交差する座標（１９６２ａ）によって決定されてもよい。本例に示されるように、座標１９６２ａに関連付けられた値は、（０．２３，１．０，ＱＭＰＡ１）であり、ここで、
・０．２３は、負荷（クライアントＡ）値を表現し、
・ＱＭＰＡ１は、ＱｏＳ管理ポリシー集合Ａ１を表現し、
・１．０は、値がＱｏＳ管理ポリシー集合Ａおよび負荷（クライアント）値の関数に基づいて決定されてもよい伸縮された（および／または正規化された）目標ＩＯＰＳ比率を表現する。例えば、図１９Ｂの特定の実施形態例では、目標ＩＯＰＳ比率値は、負荷（クライアントＡ）値がＱｏＳ管理ポリシー集合Ａ１（「ＱＭＰＡ１」）曲線１９０２ａと交差する交差点（例えば、１９６２ａ）によって決定されてもよい。
少なくとも一実施形態では、クライアントＡに対する目標ＩＯＰＳ値（例えば、Ｔ１）は、例えば、
目標ＩＯＰＳ（クライアントＡ）＝Ｔ１
Ｔ２＝（１．０×（最大IOPS(ClientA)＋最小IOPS(ClientA)））＋最小IOPS(ClientA)
といったクライアントＡの最小および最大ＩＯＰＳ値と相対的である関数として表現されてもよい。
このようにして、例えば、ストレージシステムは、クライアントＡのＩＯＰＳを、Ｔ１を上回らないように（少なくとも一時的に）ＩＯＰＳ値に絞ることにより、クライアントＡのＩＯに対するＱｏＳ管理を実施してもよい。図１９Ｂの実施形態例では、クライアントＡに対する目標ＩＯＰＳ値（Ｔ１）は、クライアントＡの最大ＩＯＰＳ値に等しくなるように決定されてもよい。付加的に、ＱｏＳ管理ポリシー集合Ａ１は、クライアントＡのＩＯＰＳが自身のそれぞれの最大ＩＯＰＳ値を上回ってバーストすることを可能にするためクライアントＡのクレジットの使用をさらに許可してもよい。
さらに、図１９Ｂの実施形態例に示されるように、例示の目的のため、クライアントＢの現在負荷値（「負荷(クライアントＢ)」）１９７２は、負荷(クライアント)閾値Ａ１より大きいが、負荷（クライアント）閾値Ａ２未満であると考えられる負荷（クライアントＢ）＝０．３９となるように計算されている、と仮定する。その結果、本実施形態例では、ストレージシステムは、ＱｏＳ管理ポリシー集合Ｂ１がクライアントＢに対する目標ＩＯＰＳ値を決定するため使用されるべきであると決定してもよい。
このようにして、例えば、図１９Ｂの実施形態例では、クライアントＢに対する目標ＩＯＰＳ値は、負荷（クライアントＢ）値がＱｏＳ管理ポリシー集合Ｂ１（「ＱＭＰＢ１」）曲線１９０４ａと交差する座標（１９７２ａ）によって決定されてもよい。本例に示されるように、座標１９７２ａに関連付けられた値は、（０．３９，０．４８，ＱＭＰＢ１）であり、ここで、
・０．３９は、負荷（クライアントＢ）値を表現し、
・ＱＭＰＢ１は、ＱｏＳ管理ポリシー集合Ｂ１を表現し、
・０．４８は、値がＱｏＳ管理ポリシー集合Ｂおよび負荷（クライアント）値の関数に基づいて決定されてもよい伸縮された（および／または正規化された）目標ＩＯＰＳ比率を表現する。例えば、図１９Ｂの特定の実施形態例では、目標ＩＯＰＳ比率値は、負荷（クライアントＢ）値がＱｏＳ管理ポリシー集合Ｂ１（「ＱＭＰＢ１」）曲線１９０４ａと交差する交差点（例えば、１９７２ａ）によって決定されてもよい。
少なくとも一実施形態では、クライアントＢに対する目標ＩＯＰＳ値（例えば、Ｔ２）は、例えば、
目標ＩＯＰＳ（クライアントＢ）＝Ｔ２
Ｔ２＝（０．４８×（最大IOPS(ClientB)＋最小IOPS(ClientB)））＋最小IOPS(ClientB)
といったクライアントＢの最小および最大ＩＯＰＳ値と相対的である関数として表現されてもよい。
このようにして、例えば、ストレージシステムは、クライアントＢのＩＯＰＳを、Ｔ２を上回らないように（少なくとも一時的に）ＩＯＰＳ値に絞ることにより、クライアントＢのＩＯに対するＱｏＳ管理を実施してもよい。
同様に、図１９Ｂの実施形態例に示されるように、例示の目的のため、クライアントＣの現在負荷値（「負荷(クライアントＣ)」）１９８２は、負荷(クライアント)閾値Ａ１より大きいが、負荷（クライアント）閾値Ａ２未満であると考えられる負荷（クライアントＣ）＝０．５５となるように計算されている、と仮定する。その結果、本実施形態例では、ストレージシステムは、ＱｏＳ管理ポリシー集合Ｂ１がクライアントＣに対する目標ＩＯＰＳ値を決定するため使用されるべきであると決定してもよい。
このようにして、例えば、図１９Ｂの実施形態例では、クライアントＣに対する目標ＩＯＰＳ値は、負荷（クライアントＣ）値がＱｏＳ管理ポリシー集合Ｂ１（「ＱＭＰＢ１」）曲線１９０４ａと交差する座標（１９８２ａ）によって決定されてもよい。本例に示されるように、座標１９８２ａに関連付けられた値は、（０．５５，０．１８，ＱＭＰＢ１）であり、ここで、
・０．５５は、負荷（クライアントＣ）値を表現し、
・ＱＭＰＢ１は、ＱｏＳ管理ポリシー集合Ｂ１を表現し、
・０．１９は、値がＱｏＳ管理ポリシー集合Ｂおよび負荷（クライアント）値の関数に基づいて決定されてもよい伸縮された（および／または正規化された）目標ＩＯＰＳ比率を表現する。例えば、図１９Ｂの特定の実施形態例では、目標ＩＯＰＳ比率値は、負荷（クライアントＣ）値がＱｏＳ管理ポリシー集合Ｂ１（「ＱＭＰＢ１」）曲線１９０４ａと交差する交差点（例えば、１９８２ａ）によって決定されてもよい。
少なくとも一実施形態では、クライアントＣに対する目標ＩＯＰＳ値（例えば、Ｔ３）は、例えば、
目標ＩＯＰＳ（クライアントＣ）＝Ｔ３
Ｔ３＝（０．１９×（最大IOPS(ClientC)＋最小IOPS(ClientC)））＋最小IOPS(ClientC)
といったクライアントＣの最小および最大ＩＯＰＳ値と相対的である関数として表現されてもよい。
このようにして、例えば、ストレージシステムは、クライアントＣのＩＯＰＳを、Ｔ３を上回らないように（少なくとも一時的に）ＩＯＰＳ値に絞ることにより、クライアントＣのＩＯに対するＱｏＳ管理を実施してもよい。
付加的に、図１９Ｂの実施形態例に示されるように、例示の目的のため、クライアントＤの現在負荷値（「負荷(クライアントＤ)」）１９９２は、負荷(クライアント)閾値Ａ２より大きいと考えられる負荷（クライアントＤ）＝０．７４となるように計算されている、と仮定する。その結果、本実施形態例では、ストレージシステムは、ＱｏＳ管理ポリシー集合Ｃ１がクライアントＤに対する目標ＩＯＰＳ値を決定するため使用されるべきであると決定してもよい。
このようにして、例えば、図１９Ｂの実施形態例では、クライアントＤに対する目標ＩＯＰＳ値は、負荷（クライアントＤ）値がＱｏＳ管理ポリシー集合Ｃ１（「ＱＭＰＣ１」）曲線１９０６ａと交差する座標（１９９２ａ）によって決定されてもよい。本例に示されるように、座標１９９２ａに関連付けられた値は、（０．７４，０．７４，ＱＭＰＣ１）であり、ここで、
・０．７４は、負荷（クライアントＤ）値を表現し、
・ＱＭＰＣ１は、ＱｏＳ管理ポリシー集合Ｃ１を表現し、
・０．７５は、値がＱｏＳ管理ポリシー集合Ｃ１および負荷（クライアント）値の関数に基づいて決定されてもよい伸縮された（および／または正規化された）目標ＩＯＰＳ比率を表現する。例えば、図１９Ｂの特定の実施形態例では、目標ＩＯＰＳ比率値は、負荷（クライアントＤ）値がＱｏＳ管理ポリシー集合Ｃ１（「ＱＭＰＣ１」）曲線１９０６ａと交差する交差点（例えば、１９９２ａ）によって決定されてもよい。
少なくとも一実施形態では、クライアントＤに対する目標ＩＯＰＳ値（例えば、Ｔ４）は、例えば、
目標ＩＯＰＳ（クライアントＤ）＝Ｔ４
Ｔ４＝０．７５×最小IOPS(ClientD)
といったクライアントＤの最小および最大ＩＯＰＳ値と相対的である関数として表現されてもよい。
このようにして、例えば、ストレージシステムは、クライアントＤのＩＯＰＳを、Ｔ４を上回らないように（少なくとも一時的に）ＩＯＰＳ値に絞ることにより、クライアントＤのＩＯに対するＱｏＳ管理を実施してもよい。
少なくともいくつかの実施形態では、ストレージシステムは、各クライアントの定義済みの最小および最大ＩＯＰＳの範囲と相対的に、この各クライアントに対するＩＯＰＳを比例的に絞ることがある、と理解される。いくつかの実施形態では、それぞれのクライアント毎に実施された異なるＱｏＳ管理ポリシー集合は、いくつかのクライアントをその他のクライアントより優先する効果を有してもよい。付加的に、いくつかの実施形態では、ＱｏＳ管理ポリシー集合は、システムが過負荷になることを防止するのを支援するために１つ以上のクライアントに対する目標ＩＯＰＳ値を予防的に減少させることがある。
前述のとおり、ストレージシステムは、
（１）読み出し関連トランザクションと書き込み関連トランザクションとを区別し、所定のクライアントに関連付けられた負荷（クライアント−読み出し）値および負荷（クライアント−書き込み）値を別個に分析し、決定し、および／または、追跡し（２）クライアント関連読み出しＩＯＰＳおよびクライアント関連書き込みＩＯＰＳに対する異なるそれぞれのＱｏＳ管理ポリシー集合を独立に評価し実施するように構成または設計されてもよい。このような手法の実施形態例は、例えば、図１６、１７、２０、および２１に例示されている。
図１６は、特定の実施形態に係るＱｏＳクライアント−読み出しポリシー管理手順１６００のフロー図を示す。手順１６００の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１６００は、コンピューティングデバイスで実施することができる。一実装では、手順１６００は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１６００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、ＱｏＳクライアント−読み出しポリシー管理手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。例示の目的のため、ＱｏＳクライアント−読み出しポリシー管理手順１６００は、選択されたクライアント（例えば、クライアントＡ、図９）に対するＱｏＳポリシー管理を実行するためにインスタンス化されている、と仮定する。
少なくとも一実施形態では、ＱｏＳクライアント−読み出しポリシー管理手順は、ストレージシステムの１つ以上の選択されたクライアントに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。特定の実施形態によれば、ＱｏＳクライアント−読み出しポリシー管理手順の複数のインスタンスまたはスレッドは、１台以上のプロセッサ、および／または、ハードウェアおよび／またはハードウェアとソフトウェアとのその他の組み合わせの使用によって、並列に実施および／または開始されてもよい。一実施形態では、ＱｏＳクライアント−読み出しポリシー管理手順の別個のインスタンスまたはスレッドは、ストレージシステムのそれぞれのクライアント毎にＱｏＳポリシー管理を実行または実現し易くするため開始されてもよい。
異なる実施形態によれば、ＱｏＳクライアント−読み出しポリシー管理手順の１つ以上の異なるスレッドまたはインスタンスは、１つ以上の異なる時間間隔（例えば、特定の時間間隔中、規則的な周期的間隔、不規則的な周期的間隔、要求次第など）で自動的および／または動的に開始および／または実施されてもよい。例えば、一実施形態では、ＱｏＳクライアント−読み出しポリシー管理手順の所定のインスタンスは、（例えば、所定のクライアントに対して５００ｍｓ毎に）およそ２５０〜１０００ミリ秒毎に自動的に動き、それによって、識別されたクライアントに対する更新負荷（クライアント−読み出し）値を分析し、決定するように構成または設計されてもよい。いくつかの実施形態では、所定のクライアントに対するＱｏＳクライアント−読み出しポリシー管理手順の実行の頻度は、例えば、システムメトリクス、クライアントメトリクス、ＱｏＳ管理ポリシーの変化などなどのその他の事象および／または条件に基づいて自動的および／または動的に変化してもよい。
図１６の実施形態例では、１６０２で、ＱｏＳクライアント−読み出しポリシー管理手順の実行を開始する少なくとも１つの条件または事象が検出されている、と仮定する。１６０４に示すように、ＱｏＳクライアント−読み出しポリシー管理手順は、システムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムメトリクスの分析は、識別されたクライアントに対する読み出し動作を取り扱うために割り当てられているサービスに関連付けられたＩＯアクティビティに対する読み出しレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
１６０６に示すように、ＱｏＳクライアント−読み出しポリシー管理手順は、識別されたクライアントに対する現在負荷（クライアント−読み出し）値を決定してもよい。異なる実施形態によれば、負荷（クライアント−読み出し）値は、例えば、本明細書に記載された様々な負荷(クライアント−読み出し)計算手法のうちの１つ以上を使用して決定または計算されてもよい。少なくとも一実施形態では、負荷（クライアント−読み出し）値は、識別されたクライアントに対する読み出し動作を取り扱うために割り当てられているサービスに関連付けられたＩＯアクティビティに対する読み出しレイテンシーメトリクスを考慮するクライアント固有負荷値として表現されてもよい。
１６０８に示すように、ＱｏＳクライアント−読み出しポリシー管理手順は、現在負荷（クライアント−読み出し）値を分析し、これに応答して、識別されたクライアントに対する適切なＱｏＳ管理ポリシーを選択し実施してもよい。例えば、図１６の実施形態例に示されるように、
・負荷(クライアント−読み出し)＜閾値Ａ１であると決定された場合、ＱｏＳクライアント−読み出しポリシー管理手順は、ＱｏＳ管理ポリシー集合Ａ２を実施してもよい（１６１０）
・閾値Ａ１≧負荷(クライアント−読み出し)≧閾値Ａ２であると決定された場合、ＱｏＳクライアント−読み出しポリシー管理手順は、ＱｏＳ管理ポリシー集合Ｂ２を実施してもよい（１６１２）
・負荷（クライアント−読み出し）＞閾値Ａ２であると決定された場合、ＱｏＳクライアント−読み出しポリシー管理手順は、ＱｏＳ管理ポリシー集合Ｃ２を実施してもよい（１６１５）。
図２０は、クライアントＩＯＰＳを絞る異なるＱｏＳ管理ポリシー集合が変化する負荷（クライアント−読み出し）条件に応答して自動的および／または動的に実施される方法の実施形態例を示すグラフを示す。図２０の実施形態例に示されるように、クライアント読み出しＩＯＰＳ ２０１０に対応する目標性能値を表現するＹ軸と、選択されたクライアント（例えば、クライアントＡ）に対する負荷（クライアント−読み出し）値を表現するＸ軸とを含むＸ−Ｙグラフ部２０００が表される。図２０の実施形態例に示されるように、グラフ部２０００は、識別されたクライアントに対する最小読み出しＩＯＰＳ ＱｏＳパラメータ２００３最大読み出しＩＯＰＳ ＱｏＳパラメータ２００５および最大バースト読み出しＩＯＰＳ ＱｏＳパラメータ２００７を表す基準線２００３、２００５、２００７を含む。付加的に、グラフ部２０００は、本実施形態例では、識別されたクライアントに対して効力のある現在ＱｏＳ管理ポリシー集合を決定し選択するために使用されてもよい閾値を表す基準線２０１１、２０１３、２０１５を含む。例えば、図２０に示されているように、
・負荷（クライアント−読み出し）＜閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ａ２が識別されたクライアントに対して有効に設定されてもよい。図２０の特定の実施形態例では、領域２００２は、クライアントがＱｏＳ管理ポリシー集合Ａ２に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ａ２は、クライアントがＩＯＰＳクレジットを生じることを許可されること、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータ２００５以下になる可能性があること、クライアントが生じたクレジットに基づいてクライアントの最大バーストＩＯＰＳ ＱｏＳパラメータを上回って動作することが許可されてもよいが、クライアントの最大バーストＩＯＰＳ ＱｏＳパラメータ２００７を上回るべきではないことを指定してもよい。
・閾値Ａ２≧負荷（クライアント−読み出し）≧閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｂ２が識別されたクライアントに対して有効に設定されてもよい。図２０の具体的な実施形態例では、領域２００４は、クライアントがＱｏＳ管理ポリシー集合Ｂ２に従って動作することができる考えられるＩＯＰＳの値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｂ２は、クライアントの読み出しＩＯＰＳがクライアントの最大読み出しＩＯＰＳ ＱｏＳパラメータと最小読み出しＩＯＰＳ ＱｏＳパラメータとの間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｂ２は、所定の時点に（閾値Ａ１≧負荷（クライアント−読み出し）≧閾値Ａ２である間）、クライアントの読み出しＩＯＰＳは、クライアントの現在（例えば、リアルタイム）負荷（クライアント−読み出し）値に基づいて動的に決定された目標性能ＩＯＰＳ値に絞られるべきであることを指定することもある。例えば、図２０の実施形態例では、ＱｏＳ管理ポリシー集合Ｂ２が有効である間に、クライアントの読み出しＩＯＰＳは、（例えば、クライアントの現在（クライアント−読み出し）値と相対的にクライアントの許容読み出しＩＯＰＳの上限を定義する）境界曲線２００４ａによって定義された対応するＩＯＰＳ値を上回ることがない目標性能ＩＯＰＳ値に絞られるべきである。
・負荷（クライアント−読み出し）＞閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｃ２が識別されたクライアントに対して有効に設定されてもよい。図２０の特定の実施形態例では、領域２００６は、クライアントがＱｏＳ管理ポリシー集合Ｃ２に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｃ２は、クライアントの読み出しＩＯＰＳがクライアントの最小読み出しＩＯＰＳ ＱｏＳパラメータと零との間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｃ２は、所定の時点に（負荷（クライアント−読み出し）＞閾値Ａ２）、クライアントの読み出しＩＯＰＳがクライアントの負荷（クライアント−読み出し）値に基づいて動的に決定された目標性能ＩＯＰＳ値に絞られるべきことをさらに指定する。例えば、図２０の実施形態では、ＱｏＳ管理ポリシー集合Ｃ２が有効である間に、クライアントの読み出しＩＯＰＳは、（例えば、クライアントの現在（クライアント−読み出し）値と相対的にクライアントの許容読み出しＩＯＰＳの上限を定義する）境界曲線２００６ａによって定義された対応するＩＯＰＳ値を上回ることがないＩＯＰＳ値に絞られるべきである。
図１７は、特定の実施形態に係るＱｏＳクライアント−書き込みポリシー管理手順１７００のフロー図を示す。手順１７００の付加的な、より少数の、または異なる動作は、特有の実施形態に依存して実行されてもよい。手順１７００は、コンピューティングデバイスで実施することができる。一実装では、手順１７００は、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに手順１７００の動作を実行させる命令を格納しているコンピュータ可読媒体上に符号化される。異なる実施形態によれば、ＱｏＳクライアント−書き込みポリシー管理手順によって提供された様々なタイプの関数、動作、アクション、および／またはその他の特徴のうちの少なくとも一部は、ストレージシステムの１つ以上のノードおよび／またはボリュームで実施されてもよい。例示の目的のため、ＱｏＳクライアント−書き込みポリシー管理手順１７００は、選択されたクライアント（例えば、クライアントＡ、図９）に対するＱｏＳポリシー管理を実行するためにインスタンス化されている、と仮定する。
少なくとも一実施形態では、ＱｏＳクライアント−書き込みポリシー管理手順は、ストレージシステムの１つ以上の選択されたクライアントに対する負荷情報の分析、測定、計算および更新に関係する様々なタイプの関数、動作、アクション、および／またはその他の特徴を実行および／または実施するように動作可能であることがある。特定の実施形態によれば、ＱｏＳクライアント−書き込みポリシー管理手順の複数のインスタンスまたはスレッドは、１台以上のプロセッサ、および／または、ハードウェアおよび／またはハードウェアとソフトウェアとのその他の組み合わせの使用によって、並列に実施および／または開始されてもよい。一実施形態では、ＱｏＳクライアント−書き込みポリシー管理手順の別個のインスタンスまたはスレッドは、ストレージシステムのそれぞれのクライアント毎にＱｏＳポリシー管理を実行または実現し易くするため開始されてもよい。
異なる実施形態によれば、ＱｏＳクライアント−書き込みポリシー管理手順の１つ以上の異なるスレッドまたはインスタンスは、１つ以上の異なる時間間隔（例えば、特定の時間間隔中、規則的な周期的間隔、不規則的な周期的間隔、要求次第など）で自動的および／または動的に開始および／または実施されてもよい。例えば、一実施形態では、ＱｏＳクライアント−書き込みポリシー管理手順の所定のインスタンスは、（例えば、所定のクライアントに対して５００ｍｓ毎に）およそ２５０〜１０００ミリ秒毎に自動的に動き、それによって、識別されたクライアントに対する更新負荷（クライアント−書き込み）値を分析し、決定するように構成または設計されてもよい。いくつかの実施形態では、所定のクライアントに対するＱｏＳクライアント−書き込みポリシー管理手順の実行の頻度は、例えば、システムメトリクス、クライアントメトリクス、ＱｏＳ管理ポリシーの変化などなどのその他の事象および／または条件に基づいて自動的および／または動的に変化してもよい。
図１７の実施形態例では、１７０２で、ＱｏＳクライアント−書き込みポリシー管理手順の実行を開始する少なくとも１つの条件または事象が検出されている、と仮定する。１７０４に示すように、ＱｏＳクライアント−書き込みポリシー管理手順は、システムおよび／またはクライアントメトリクスの分析を開始してもよい。少なくとも一実施形態では、システムおよび／またはクライアントメトリクスの分析は、識別されたクライアントに対する書き込みおよび／または複製動作を取り扱うために割り当てられているサービスに関連付けられたＩＯアクティビティに対する書き込みレイテンシーに関係するリアルタイム情報を測定、獲得、および／または決定することを含んでもよい。
１７０６に示すように、ＱｏＳクライアント−書き込みポリシー管理手順は、識別されたクライアントに対する現在負荷（クライアント−書き込み）値を決定してもよい。異なる実施形態によれば、負荷（クライアント−書き込み）値は、例えば、本明細書に記載された様々な負荷(クライアント−書き込み)計算手法のうちの１つ以上を使用して決定または計算されてもよい。少なくとも一実施形態では、負荷（クライアント−書き込み）値は、識別されたクライアントに対する書き込みおよび複製動作を取り扱うために割り当てられているサービスに関連付けられたＩＯアクティビティに対する書き込みレイテンシーメトリクスを考慮するクライアント固有負荷値として表現されてもよい。
１７０８に示すように、ＱｏＳクライアント−書き込みポリシー管理手順は、現在負荷（クライアント−書き込み）値を分析し、これに応答して、識別されたクライアントに対する適切なＱｏＳ管理ポリシーを選択し実施してもよい。例えば、図１７の実施形態例に示されるように、
・負荷(クライアント−書き込み)＜閾値Ａ１であると決定された場合、ＱｏＳクライアント−書き込みポリシー管理手順は、ＱｏＳ管理ポリシー集合Ａ３を実施してもよい（１７１０）
・閾値Ａ１≧負荷(クライアント−書き込み)≧閾値Ａ２であると決定された場合、ＱｏＳクライアント−書き込みポリシー管理手順は、ＱｏＳ管理ポリシー集合Ｂ３を実施してもよい（１７１２）
・負荷（クライアント−書き込み）＞閾値Ａ２であると決定された場合、ＱｏＳクライアント−書き込みポリシー管理手順は、ＱｏＳ管理ポリシー集合Ｃ１を実施してもよい（１７１６）。
図２１は、クライアントＩＯＰＳを絞る異なるＱｏＳ管理ポリシー集合が変化する負荷（クライアント−書き込み）条件に応答して自動的および／または動的に実施される方法の実施形態例を示すグラフを示す。図２１の実施形態例に示されるように、クライアント書き込みＩＯＰＳ ２１１０に対応する目標性能値を表現するＹ軸と、選択されたクライアント（例えば、クライアントＡ）に対する負荷（クライアント−書き込み）値を表現するＸ軸とを含むＸ−Ｙグラフ部２１００が表される。図２１の実施形態例に示されるように、グラフ部２１００は、識別されたクライアントに対する最小書き込みＩＯＰＳ ＱｏＳパラメータ２１０３；最大書き込みＩＯＰＳ ＱｏＳパラメータ２１０５；および最大バースト書き込みＩＯＰＳ ＱｏＳパラメータ２１０７を表す基準線２１０３、２１０５、２１０７を含む。付加的に、グラフ部２１００は、本実施形態例では、識別されたクライアントに対して効力のある現在ＱｏＳ管理ポリシー集合を決定し選択するために使用されてもよい閾値を表す基準線２１１１、２１１３、２１１５を含む。例えば、図２１に示されているように、
・負荷（クライアント−書き込み）＜閾値Ａ１である時間中に、ＱｏＳ管理ポリシー集合Ａ３が識別されたクライアントに対して有効に設定されてもよい。図２１の特定の実施形態例では、領域２１０２は、クライアントがＱｏＳ管理ポリシー集合Ａ３に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ａ３は、クライアントがＩＯＰＳクレジットを生じることを許可されること、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ ＱｏＳパラメータ２１０５以下になる可能性があること、クライアントが生じたクレジットに基づいてクライアントの最大バーストＩＯＰＳ ＱｏＳパラメータを上回って動作することが許可されてもよいが、クライアントの最大バーストＩＯＰＳ ＱｏＳパラメータ２１０７を上回るべきではないことを指定してもよい。
・閾値Ａ３≧負荷（クライアント−読み出し）≧閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｂ３が識別されたクライアントに対して有効に設定されてもよい。図２１の具体的な実施形態例では、領域２１０４は、クライアントがＱｏＳ管理ポリシー集合Ｂ１に従って動作することができる考えられるＩＯＰＳの値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｂ３は、クライアントの書き込みＩＯＰＳがクライアントの最大書き込みＩＯＰＳ ＱｏＳパラメータと最小書き込みＩＯＰＳ ＱｏＳパラメータとの間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｂ１は、所定の時点に（閾値Ａ１≧負荷（クライアント−書き込み）≧閾値Ａ２である間）、クライアントの読み出しＩＯＰＳは、クライアントの現在（例えば、リアルタイム）負荷（クライアント−書き込み）値に基づいて動的に決定された目標性能ＩＯＰＳ値に絞られるべきであることを指定することもある。例えば、図２１の実施形態例では、ＱｏＳ管理ポリシー集合Ｂ３が有効である間に、クライアントの書き込みＩＯＰＳは、（例えば、クライアントの現在（クライアント−書き込み）値と相対的にクライアントの許容書き込みＩＯＰＳの上限を定義する）境界曲線２１０４ａによって定義された対応するＩＯＰＳ値を上回ることがない目標性能ＩＯＰＳ値に絞られるべきである。
・負荷（クライアント−読み出し）＞閾値Ａ２である時間中に、ＱｏＳ管理ポリシー集合Ｃ３が識別されたクライアントに対して有効に設定されてもよい。図２１の特定の実施形態例では、領域２１０６は、クライアントがＱｏＳ管理ポリシー集合Ｃ３に従って動作することができるＩＯＰＳの考えられる値のグラフを提供する。本実施形態例では、ＱｏＳ管理ポリシー集合Ｃ３は、クライアントの書き込みＩＯＰＳがクライアントの最小書き込みＩＯＰＳ ＱｏＳパラメータと零との間の範囲に含まれる目標性能ＩＯＰＳ値に絞られるべきことを指定してもよい。付加的に、ＱｏＳ管理ポリシー集合Ｃ３は、所定の時点に（負荷（クライアント−書き取り）＞閾値Ａ２）、クライアントの書き込みＩＯＰＳがクライアントの負荷（クライアント−書き込み）値に基づいて動的に決定された目標性能ＩＯＰＳ値に絞られるべきことをさらに指定する。例えば、図２１の実施形態では、ＱｏＳ管理ポリシー集合Ｃ３が有効である間に、クライアントの書き込みＩＯＰＳは、（例えば、クライアントの現在（クライアント−書き取り）値と相対的にクライアントの許容書き込みＩＯＰＳの上限を定義する）境界曲線２１０６ａによって定義された対応するＩＯＰＳ値を上回ることがない目標性能ＩＯＰＳ値に絞られるべきである。
少なくとも一実施形態では、本明細書に記載された様々なＱｏＳ手法の少なくとも一部は、ストレージシステムが所定のクラスタの中の複数の異なるクライアントに亘って個別にカスタム化されたＱｏＳ管理ポリシーを動的に実施する能力に少なくとも部分的に基づくことがある。
代替的な実施形態では、ストレージシステムがクラスタは過負荷状態であると決定したとき、システムは、クラスタの各クライアントに関連付けられたＩＯＰＳを比例的かつ均一に絞るために伸縮法を使用してもよい。システム過負荷が増大するのにつれて、各クライアントのＩＯＰＳは、各クライアントのそれぞれの更新目標ＩＯＰＳ値に基づいて自動的、動的および／または比例的に引き下げられる（または絞られる）ことがある。最大ＩＯＰＳおよび最小ＩＯＰＳ ＱｏＳパラメータは、クライアント毎に異なることがあるので、各クライアントに対する目標性能ＩＯＰＳ値は、類似するシステム負荷条件下でも異なることがある。
例えば、５ｍｓレイテンシーで、ストレージシステムは、例えば、結果的に、システムは、各クライアントのＩＯＰＳをそれぞれの最小ＩＯＰＳ ＱｏＳパラメータ付近の値まで絞る第１のＱｏＳ管理ポリシー集合を実施する第１の閾値（例えば、負荷（システム）＝７０％）を上回るようにシステムの負荷を指定してもよい。これが行われたとき、クラスタ上でより高い性能を実現するため、例えば、より多くの容量を追加する、および／または、ボリュームの最大ＩＯＰＳ ＱｏＳパラメータを低下させるといった限定された方式しかないことがある。代替的に、より小さいクラスタレイテンシー（例えば、およそ２ｍｓ未満）で、ストレージシステムは、第２の閾値（例えば、負荷（システム）＝３０％）未満となるようにシステムの負荷を指定することがあり、システムは、クライアントが継続してバーストし、自身の最大ＩＯＰＳ ＱｏＳパラメータを上回ることを可能にする第２のＱｏＳ管理ポリシー集合を実施してもよい。クラスタが過負荷状態ではない（例えば、読み出しレイテンシーが許容可能であり、書き込みキャッシュキューが十分に低い）と考えられる実施形態では、クラスタ負荷は、最終目標性能ＩＯＰＳ値に影響を与えないことがある。このようにして、例えば、クライアントＡの最大ＩＯＰＳ ＱｏＳパラメータに１０００ ＩＯＰＳが設定され、クライアントＡの最大バーストＩＯＰＳ ＱｏＳパラメータに１５００ ＩＯＰＳが設定された場合、無負荷条件下で、システムは、１０００から１５００ ＩＯＰＳの範囲に含まれるようにクライアントＡの目標性能ＩＯＰＳ値を設定する。
自身の最大ＱｏＳパラメータを上回るクライアント動作（バースティング）
図７は、一実装によるある期間に亘ってクライアント１０８によって実行されたある程度の回数のＩＯＰＳのグラフ７００を示す。Ｙ軸は、１秒当たりに実行されたＩＯＰＳの回数を示す。２分の１秒の周囲がＸ軸に示されている。ＩＯＰＳの回数が最大ＩＯＰＳレベル（１００ ＩＯＰＳ）を下回るときに累積されたクレジットが示されている。図示されるように、クレジットは、期間１〜８まで徐々に増加する。期間８で、クライアントは、バー７０２によって指示されているように、およそ３２０個のクレジットを生じている。クライアント１０８が最大ＩＯＰＳを上回ってバーストするのにつれて、クレジットの個数が減少し始める。グラフ７００では、クライアントは、期間９において、正方形７０４によって示されるように、およそ１２５ ＩＯＰＳを使用している。クライアントは、バー７０２によって示されるように、クレジットを生じているので、自身の最大ＩＯＰＳレベルを上回ってバーストすることが許可される。クライアントのＩＯＰＳレベルは、自身のバーストＩＯＰＳ値で上限を定められる。グラフ７００では、クライアントは、期間１０および１１において自身のバーストＩＯＰＳ値に達する。クライアントが自身の最大ＩＯＰＳ値を上回って動作しているとき、自身のクレジットが減少する。一実装では、減少したクレジットの量は、クライアントの最大ＩＯＰＳ値を上回ったＩＯＰＳの量に等しい。期間１３以降、クライアント１０８は、最大ＩＯＰＳレベルで動作し、クレジットの個数は、減少しない。
クレジットは、クライアントメトリクスに基づいて生じている。例えば、一実施形態では、クライアントが利用しない各ＩＯ動作に対して、クライアントのＩＯＰＳが指定された閾値を下回る間に（例えば、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ値を下回る間に）、クライアントは、クライアントのＩＯＰＳがクライアントの最大ＩＯＰＳ値を上回ってバーストすることを可能にさせるために（システムによって許可されたときに）続いて使用されてもよい「ＩＯＰクレジット」を受け取ることがある。例えば、クライアントの最大ＩＯＰＳ値に１０００ ＩＯＰＳが設定され、クライアントの最大バーストＩＯＰＳ値に１５００ ＩＯＰＳが設定されたと仮定し、クライアントは、現在９００ ＩＯＰＳだけを使用中であり、システムは過負荷状態ではないとさらに仮定する場合、クライアントは、クライアントのＩＯＰＳが１０００ ＩＯＰＳを上回ってバーストすることを可能にするために続いて使用されてもよい（例えば、毎秒）１００ ＩＯＰＳクレジットを生じることがある。
異なる実施形態によれば、例えば、以下（またはこれらの組み合わせ）のうちの１つ以上などの１つ以上の制限または限定がＩＯＰＳバーストアクティビティに関して加えられることがある。
（例えば、所定のクライアントおよび／または所定のクラスタに対する）合計ＩＯＰＳクレジットは、ある一定の量で上限を定められる。例えば、一実施形態では、所定のクライアントに対して、このクライアントによって生じされることがある合計ＩＯＰＳクレジットは、
合計ＩＯＰＳクレジット＝（最大バーストＩＯＰＳ値−最大ＩＯＰＳ値）×バースト時間
に従って決定されてもよい。このようにして、バースト時間が１０秒で設定されている一実施形態例では、クライアントは、最大で（１５００−１０００）×１０＝５０００ ＩＯＰＳクレジットを生じることがある。
クライアントは、所定の期間中に自身の生じたＩＯＰＳクレジットのうちの割り当てられた部分だけを使用することに限定されてもよい。例えば、クライアントが５０００クレジットを生じることがあるとしても、クライアントは、１つ以上の特定の期間中に、自身の５０００クレジットのうちの５００（例えば、１５００−１０００＝５００）しか使用することを許可されないことがある。その上、バースティングは、前述のとおりＱｏＳポリシー集合に基づいて限定されてもよい。
スライスサーバリバランシング
前述のとおり、ボリュームサーバ１２２は、１台以上のスライスサーバ１２４に関連付けられる可能性がある。各スライスサーバ１２４は、システム１００内部のボリュームに関連付けられたメタデータを記憶する。一実装では、新たに作成されたボリュームに対する新しいスライスは、ボリュームサーバ１２４の容量に基づいてボリュームサーバ１２２に設置されてもよい。例えば、より多くの空き記憶容量をもつボリュームサーバ１２２は、より少ない空き記憶容量をもつその他のボリュームサーバより優先して選択されてもよい。新しいスライスの設置は、しかし、ボリュームサーバ１２２の負荷に関して理想的ではないことがあり、このことは、新しいボリュームにアクセスするクライアントに対するサービス品質に影響を与える可能性がある。スライスのより優れた分布を得るために、前述の負荷値、システムメトリクス、クライアントメトリクス、およびＱｏＳパラメータは、クライアントのスライスを設置すべき時点および場所を決定するために使用されてもよい。例えば、最小ＱｏＳパラメータは、特有のサービス上で合計されてもよい。この合計値は、サービスがクライアントの要求ＱｏＳを支援することができることを保証するために使用されてもよい。スライスは、様々なサービスに亘るこの合計値に基づいて設置および／または移動されてもよい。
一実装では、クライアントのＱｏＳパラメータは、特有のボリュームサーバの目標サービス品質インデックスを決定するために使用される。例えば、特有のボリュームサーバ上にスライスサーバを有する全てのクライアントが決定されてもよい。各クライアントに対する最小ＩＯＰＳまたは最大ＩＯＰＳが合計されてもよい。この値が所定の閾値を上回る場合、１つ以上のスライスを移動させる決定が行われる。合計が閾値を上回るとき、警報がシステムの管理者に送信されてもよい。管理者は、次に、どのスライスを別のスライスサーバへ移動させるかを判定することができる。代替的な実施形態では、この移動は、無負荷状態ボリュームサーバを選択することなく、スライスサーバの各々に対するサービス品質インデックスを均一化するような方法で自動的に行われる可能性がある。どのボリュームサーバが過負荷状態であるかを識別するのに加えて、十分に利用されていないボリュームサーバが同じように識別される可能性もある。各ボリュームサーバに対する最小ＩＯＰＳの合計は、計算され、管理者に表示されてもよい。管理者は、次に、新しいボリュームサーバをインテリジェントに選択することができる。別の実施では、スライスは、過負荷状態ボリュームサーバを検出することに基づいて自動的に移動されてもよい。
ＱｏＳパラメータを使用するのに加えて、前述の性能メトリクスおよび負荷値は、ボリュームが過負荷状態であるか否か、および、どのボリュームが過負荷状態でないかを判定するために使用されてもよい。例えば、ボリュームサーバの書き込み−キャッシュ容量は、どのスライスをいつ移動すべきかを判定するためにクライアントのメトリクスと併せて使用されてもよい。プロセスは、ボリュームサーバの書き込みキャッシュ容量などの様々なシステムレベルメトリクスを監視し、いずれかのボリュームサーバが過負荷状態であるか否かを判定することができる。前述の目標性能マネージャ４０２と同様に、過負荷条件は、負荷値を対応する閾値と比較することに基づいて決定されてもよい。過負荷条件が検出された場合、クライアントメトリクス、システムメトリクス、および／または負荷値は、いずれかのクライアントが非比例的に過負荷条件の原因となるか否かを判定するために使用されてもよい。例えば、ボリュームサーバは、ある程度の数のクライアントに対するスライスおよび／またはスライスサーバを有することができる。２つのこのようなクライアントは、ボリュームサーバの書き込みキャッシュ容量に影響を与えるボリュームサーバへの大量のデータ書き込みの原因となることがある。ＩＯ書き込みの回数、全てのクライアントの書き込み帯域幅の量、および／または、ＩＯ書き込みの回数および／または帯域幅に関連付けられた負荷値を使用して、他のクライアントより多く書き込みキャッシュ容量に影響を与える２つのクライアントが決定されてもよい。この特性に基づいて、これらの２つのクライアントのうちのいずれかに関連付けられたスライスが別のボリュームサーバへ移動させるために選択されてもよい。この特徴は、ボリュームから特有のスライスを移動することがシステム上のその他のクライアントに対する過負荷条件を低減または除去するときに重大な影響を与えるものであることを保証するのに役立つ。クライアントメトリクス、システムメトリクス、および／または負荷値を詳しく調べることがない場合、ボリュームサーバの性能に著しく影響を与えていないスライスが移動されてもよい。このシナリオにより、元のボリュームサーバが依然として過負荷状態となる可能性がある。
その上、その他のボリュームサーバに関連付けられた性能メトリクスおよび／または負荷値は、スライスサーバに対するボリュームサーバを見つけるために分析されてもよい。上記例を続けると、大量の書き込みを取り扱うことができるボリュームサーバが決定されてもよい。例えば、大きい書き込みキャッシュ容量をもっている、または、ボリュームサーバの全ての顧客に亘って比較的少数の書き込みＩＯを有するボリュームサーバは、性能メトリクスまたは負荷値のいずれかを用いて識別されてもよい。スライスは、次に、これらの識別されたスライスサーバのうちの１つに移動される可能性があり、スライスサーバを移動することが、スライスサーバを移動することに基づいて新しいボリュームサーバに対する過負荷条件を引き起こすものではないことを保証するために役立つ。
一実装では、スライスサーバリバランシングは、サービス品質監視とは独立に行われる可能性がある。例えば、いずれかのスライスが移動されるべきであるか否かを判定するためにチェックすることは、スケジュールとおりに、例えば、５００ミリ秒毎、１秒毎、１分毎などに行われる可能性がある。別の実施では、サービス品質監視およびスライスサーバリバランシングは、統合されてもよい。例えば、クライアントに対するサービス品質をチェックする前に、スライスサーバリバランシングプロセスは、いずれかのスライスが移動されるべきか否かを判定するために照会されてもよい。いずれかのボリュームサーバが過負荷状態である場合、サービス品質監視は、スライスが移動されるまで待つ可能性がある。過負荷状態ボリュームサーバは、システムおよびクライアントの性能メトリクスと負荷値とに影響を与える可能性があるので、サービス品質監視は、スライスサーバがリバランスされるまで待つことがある。この特徴は、サービス品質監視が過負荷状態ボリュームサーバによる悪影響を受けることなくシステム性能およびクライアント性能を適切に記述する性能メトリクスおよび／または負荷値を使用することを可能にする。
本願では、１つ以上のフロー図が使用されている。フロー図の使用は、動作の実行順序に関して限定的であることを意図するものではない。本願に記載された主題は、時には、異なる他のコンポーネントの内部に包含されている、または、異なる他のコンポーネントと接続されている異なるコンポーネントを例示してもよい。このような表現されたアーキテクチャは、単に典型的であること、実際には、同じ機能を達成する多くのその他のアーキテクチャが実施することができることが理解されるべきである。概念的な意味で、同じ機能を達成するコンポーネントの仕組みは、所望の機能が達成されるように効果的に「関連」している。それ故に、特有の機能を達成するためにこの点で組み合わされた２つのコンポーネントはいずれも、アーキテクチャまたは中間コンポーネントとは関係なく、所望の機能が達成されるように、互いに「関連付けられている」とみなすことができる。同様に、このように関連付けられている２つのコンポーネントはいずれも、所望の機能を達成するために互いに「動作的に接続」または「動作的に連結」されているとみなすこともでき、このように関連付けることができる２つのコンポーネントはいずれもいずれも、所望の機能を達成するために互いに「動作的に連結可能」であるとみなすこともできる。動作的に連結可能の特定の例は、限定するものではないが、物理的に嵌合可能なおよび／または物理的に相互作用するコンポーネント、および／または、無線相互作用可能なおよび／または無線相互作用するコンポーネント、および／または、論理的に相互作用するおよび／または論理的に相互作用可能なコンポーネントを含む。
本明細書における実質的に何らかの複数形および／または単数形表現の使用に関して、当業者は、文脈および／または用途に適切であるように、複数形から単数形に、および／または、単数形から複数形に翻訳することができる。様々な単数形／複数形置換は、明瞭さのため明示的に記載されてもよい。
概して、本明細書および特に本願請求項（例えば、本願請求項の本文）で使用された用語は、「オープン」用語として通常は意図されていることが当業者によって理解されるであろう（例えば、用語「含んでいる（ｉｎｃｌｕｄｉｎｇ）」は、「限定するものではないが、含んでいる」と解釈されるべきであり、用語「有する（ｈａｖｉｎｇ）」は、「少なくとも有する」と解釈されるべきであり、用語「含む（ｉｎｃｌｕｄｅｓ）」は、「限定するものではないが、含む」と解釈されるべきであり、以下続く）。導入された請求項記述の特定の数が意図されている場合、このような意図は、請求項に明示的に記述されるものであり、このような記述がない場合、このような意図は存在しないことが当業者によってさらに理解されるであろう。例えば、理解の助けとして、本願請求項は、請求項記述を導入するために導入句「少なくとも１つの（ａｔ ｌｅａｓｔ ｏｎｅ）」および「１つ以上の（ｏｎｅ ｏｒ ｍｏｒｅ）」の使用を含んでもよい。しかし、このような句の使用は、同じ請求項が導入句「１つ以上の（ｏｎｅ ｏｒ ｍｏｒｅ）」または「少なくとも１つの（ａｔ ｌｅａｓｔ ｏｎｅ）」と、「ａ」または「ａｎ」などの不定冠詞とを含むときであっても、不定冠詞「ａ」または「ａｎ」による請求項記述の導入が、このような導入された請求項記述を含んでいる特有の請求項を１つのこのような記述だけを含んでいる発明に限定することを意味するように解釈されるべきではなく（例えば、「ａ」および／または「ａｎ」は、「少なくとも１つの（ａｔ ｌｅａｓｔ ｏｎｅ）」または「１つ以上の（ｏｎｅ ｏｒ ｍｏｒｅ）」を意味するように典型的に解釈されるべきであり）、同じことが請求項記述を導入するために使用される定冠詞の使用に当てはまる。その上、導入された請求項記述の中で特定の数が明示的に記述されている場合であっても、当業者は、このような記述が少なくとも記述された数を意味するように典型的に解釈されるべきであることを認識するであろう（例えば、他の修飾語句を伴わない「２つの記述」というありのままの記述は、少なくとも２つの記述、または、２つ以上の記述を典型的に意味する）。さらに、「Ａ、Ｂ、およびＣなどのうちの少なくとも１つ」に類似している慣用句が使用されるこれらの事例では、概して、このような構文は、当業者がこの慣用句を理解するであろうという意味で意図されている（例えば、「Ａ、Ｂ、およびＣのうちの少なくとも１つを有するシステム」は、限定するものではないが、Ａを単独に、Ｂを単独に、Ｃを単独に、ＡおよびＣを一緒に、ＡおよびＣを一緒に、ＢおよびＣを一緒に、および／または、Ａ、Ｂ、およびＣを一緒に有するシステムなどを含むということになる）。「Ａ、Ｂ、またはＣなどのうちの少なくとも１つ」に類似している慣用句が使用されるこれらの事例では、概して、このような構文は、当業者がこの慣用句を理解するであろうという意味で意図されている（例えば、「Ａ、Ｂ、またはＣのうちの少なくとも１つを有するシステム」は、限定するものではないが、Ａを単独に、Ｂを単独に、Ｃを単独に、ＡおよびＣを一緒に、ＡおよびＣを一緒に、ＢおよびＣを一緒に、および／または、Ａ、Ｂ、およびＣを一緒に有するシステムなどを含むということになる）。２つ以上の代替的な用語を提示する実質的に何らかの択一的な語および／または句は、明細書本文中であろうと、請求項中であろうと、または図面中であろうとも、用語群のうちの１つ、用語群のうちのいずれか一方、または両方の用語を含んでいる可能性を考慮するように理解されるべきであることが当業者によってさらに理解されるであろう。例えば、句「ＡまたはＢ」は、「Ａ」または「Ｂ」または「ＡおよびＢ」の可能性を含むように理解されるであろう。
例示的な実装の以上の記載は、例示および説明の目的のため提示されている。開示されたとおりの形式に関して網羅的であること、または、限定的であることは、意図されることなく、変更および変形は、上記教示を考慮して可能であり、または、開示された実施の実行から得られてもよい。発明の範囲は、請求項に記載された事項およびこれらの均等物によって定められることが意図されている。

Claims (19)

  1. ストレージシステム内のボリュームに対する性能メトリクスにより、ボリュームに対するクライアントの以前のアクセスに関連する以前のクライアント性能値を決定するステップであって、前記ストレージシステムは複数のボリュームに対するデータを保存しており、前記複数のボリュームの各々に対するデータは前記ストレージシステムの複数のドライブにわたって実質的に一様に保存される、ステップ；
    最大性能値と、最小性能値と、前記最大性能値を超える最大バースト値とを含む性能パラメータの集合を受信するステップ；
    クライアント性能値が前記最大性能値未満であることを決定するステップ；
    前記クライアント性能値が前記最大性能値未満である旨の決定に基づいて、前記クライアントに対するバーストクレジットを累積するステップ；
    前記以前のクライアント性能値、前記性能パラメータの集合、及び前記クライアントに対するバーストクレジットに基づいて、前記最大性能値を超えるターゲット性能値を決定するステップ；及び
    コンピューティングデバイスが、前記ターゲット性能値に基づいて、前記性能メトリクスにより、前記ボリュームに対するアクセスに関するクライアントの性能を調整するステップ；
    を有する方法。
  2. 前記調整することは、前記ターゲット性能値に基づいて、前記クライアントのボリュームに対するアクセスを規制することを含む、請求項１に記載の方法。
  3. 前記アクセスを規制することは、ある期間中の締め出し時間内では、アクセスコマンドの実行をクライアントに許可しないことを含む、請求項２に記載の方法。
  4. 前記ターゲット性能値が前記以前のクライアント性能値より大きい場合には、前記期間中の締め出し時間を減少させ；及び
    前記ターゲット性能値が前記以前のクライアント性能値より小さい場合には、前記期間中の締め出し時間を増加させる、
    請求項３に記載の方法。
  5. 前記性能メトリクスは、１秒当たりの入力／出力動作メトリクス、帯域幅メトリクス又はレイテンシーメトリクスを含む、請求項１に記載の方法。
  6. 前記ストレージシステムにおける負荷を表現する正常性情報を受信するステップを更に有し、前記ターゲット性能値は前記正常性情報に基づいている、請求項１に記載の方法。
  7. 前記ストレージシステムは、ソリッドステートドライブを有する、請求項１に記載の方法。
  8. 複数のボリュームに対するデータが、前記ストレージシステムの複数のドライブにわたって実質的に一様に保存されることに起因して、前記ストレージシステムの複数のドライブにわたる負荷は実質的に均等である、請求項１に記載の方法。
  9. 実際の容量が容量閾値に到達する前に、前記ストレージシステムにおける複数のドライブにわたるクライアントに保証される性能が、前記ストレージシステムにおける容量閾値より大きいことを示す通知メッセージを送信するステップを更に有する、請求項１に記載の方法。
  10. 前記ターゲット性能値が前記最大性能値を超えることに基づいて、前記バーストクレジットを減少させるステップを更に有する、請求項１に記載の方法。
  11. １つ以上のコンピュータプロセッサ；及び
    １つ以上のコンピュータプロセッサに方法を実行させる命令を有するコンピュータ読み取り可能な記憶媒体；
    を有する装置であって、前記方法は：
    ストレージシステム内のボリュームに対する性能メトリクスにより、ボリュームに対するクライアントの以前のアクセスに関連する以前のクライアント性能値を決定するステップであって、前記ストレージシステムは複数のボリュームに対するデータを保存しており、前記複数のボリュームの各々に対するデータは前記ストレージシステムの複数のドライブにわたって実質的に一様に保存される、ステップ；
    最大性能値と、最小性能値と、前記最大性能値を超える最大バースト値とを含む性能パラメータの集合を受信するステップ；
    クライアント性能値が前記最大性能値未満であることを決定するステップ；
    前記クライアント性能値が前記最大性能値未満である旨の決定に基づいて、前記クライアントに対するバーストクレジットを累積するステップ；
    前記以前のクライアント性能値、前記性能パラメータの集合、及び前記クライアントに対するバーストクレジットに基づいて、前記最大性能値を超えるターゲット性能値を決定するステップ；及び
    前記ターゲット性能値に基づいて、前記性能メトリクスにより、前記ボリュームに対するアクセスに関するクライアントの性能を調整するステップ；
    を有する、装置。
  12. 前記クライアントの性能を調整するために、前記１つ以上のコンピュータプロセッサは、前記ターゲット性能値に基づいて、前記クライアントのボリュームに対するアクセスを規制するように動作することが可能である、請求項１１に記載の装置。
  13. 前記ボリュームに対するアクセスを規制するために、前記１つ以上のコンピュータプロセッサは、ある期間中の締め出し時間内では、アクセスコマンドの実行をクライアントに許可しないように動作することが可能である、請求項１２に記載の装置。
  14. 前記性能メトリクスは、１秒当たりの入力／出力動作メトリクス、帯域幅メトリクス又はレイテンシーメトリクスを含む、請求項１１に記載の装置。
  15. 前記コンピュータ読み取り可能な記憶媒体は：
    前記ストレージシステムにおける負荷を表現する正常性情報を受信するステップ；
    を前記１つ以上のプロセッサに実行させる命令を更に有し、前記ターゲット性能値は前記正常性情報に基づいている、請求項１１に記載の装置。
  16. 前記ストレージシステムは、ソリッドステートドライブを有する、請求項１１に記載の装置。
  17. 複数のボリュームに対するデータが、前記ストレージシステムの複数のドライブにわたって実質的に一様に保存されることに起因して、前記ストレージシステムの複数のドライブにわたる負荷は実質的に均等である、請求項１１に記載の装置。
  18. 請求項１ないし１０のうち何れか一項に記載の方法をコンピュータに実行させるコンピュータプログラム。
  19. 請求項１８に記載のコンピュータプログラムを記憶する記憶媒体。
JP2014550469A 2011-12-27 2012-12-27 ストレージシステムの動作を制御するための方法、装置、コンピュータプログラム及び記憶媒体 Active JP6169105B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US13/338,039 US9003021B2 (en) 2011-12-27 2011-12-27 Management of storage system access based on client performance and cluser health
US13/338,039 2011-12-27
US201261697905P 2012-09-07 2012-09-07
US61/697,905 2012-09-07
PCT/US2012/071844 WO2013101947A1 (en) 2011-12-27 2012-12-27 Proportional quality of service based on client usage and system metrics

Publications (3)

Publication Number Publication Date
JP2015507268A JP2015507268A (ja) 2015-03-05
JP2015507268A5 JP2015507268A5 (ja) 2016-02-18
JP6169105B2 true JP6169105B2 (ja) 2017-07-26

Family

ID=48698618

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014550469A Active JP6169105B2 (ja) 2011-12-27 2012-12-27 ストレージシステムの動作を制御するための方法、装置、コンピュータプログラム及び記憶媒体

Country Status (4)

Country Link
EP (3) EP2798488B1 (ja)
JP (1) JP6169105B2 (ja)
KR (1) KR20140107544A (ja)
WO (1) WO2013101947A1 (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8671265B2 (en) 2010-03-05 2014-03-11 Solidfire, Inc. Distributed data storage system providing de-duplication of data using block identifiers
JP6179321B2 (ja) 2013-09-27 2017-08-16 富士通株式会社 ストレージ管理装置、制御方法及び制御プログラム
JP6213148B2 (ja) * 2013-10-25 2017-10-18 富士通株式会社 ストレージ装置、ストレージ装置の制御方法およびストレージ装置制御プログラム
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
JP6273966B2 (ja) 2014-03-27 2018-02-07 富士通株式会社 ストレージ管理装置、性能調整方法及び性能調整プログラム
JP6394313B2 (ja) 2014-11-19 2018-09-26 富士通株式会社 ストレージ管理装置、ストレージ管理方法及びストレージ管理プログラム
JP6451307B2 (ja) * 2014-12-24 2019-01-16 富士通株式会社 ストレージ装置およびストレージ装置制御プログラム
JP6451308B2 (ja) * 2014-12-24 2019-01-16 富士通株式会社 ストレージ装置およびストレージ装置制御プログラム
JP6558090B2 (ja) * 2015-06-15 2019-08-14 富士通株式会社 ストレージ管理装置、ストレージ管理方法及びストレージ管理プログラム
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
US10855616B2 (en) * 2017-01-11 2020-12-01 Sony Interactive Entertainment LLC Predicting wait time for new session initiation during increased data traffic latency
CN107040591B (zh) * 2017-03-28 2020-06-19 北京小米移动软件有限公司 一种对客户端进行控制的方法及装置
CN110413206B (zh) * 2018-04-28 2023-05-30 伊姆西Ip控股有限责任公司 存储系统中的操作控制方法、设备和计算机程序产品
EP4111379A1 (en) 2020-02-28 2023-01-04 3M Innovative Properties Company Deep causal learning for data storage and processing power management
JP2023505617A (ja) * 2020-02-28 2023-02-09 スリーエム イノベイティブ プロパティズ カンパニー 高度モデル予測制御のための深層因果学習
CN113765686B (zh) * 2020-06-04 2023-07-21 腾讯科技（深圳）有限公司 设备管理方法、装置、业务获取设备及存储介质
JP7001847B1 (ja) 2021-01-06 2022-01-20 株式会社日立製作所 情報処理システムおよびバースティング制御方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059274A1 (en) * 2000-03-03 2002-05-16 Hartsell Neal D. Systems and methods for configuration of information management systems
US7140016B2 (en) * 2000-11-29 2006-11-21 Texas Instruments Incorporated Media accelerator quality of service
US7167965B2 (en) * 2001-04-30 2007-01-23 Hewlett-Packard Development Company, L.P. Method and system for online data migration on storage systems with performance guarantees
US7519725B2 (en) * 2003-05-23 2009-04-14 International Business Machines Corporation System and method for utilizing informed throttling to guarantee quality of service to I/O streams
US7640231B2 (en) * 2005-11-16 2009-12-29 International Business Machines Corporation Approach based on self-evolving models for performance guarantees in a shared storage system
US7778972B1 (en) * 2005-12-29 2010-08-17 Amazon Technologies, Inc. Dynamic object replication within a distributed storage system
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US8380880B2 (en) * 2007-02-02 2013-02-19 The Mathworks, Inc. Scalable architecture
US20090077097A1 (en) * 2007-04-16 2009-03-19 Attune Systems, Inc. File Aggregation in a Switched File System
JP5245934B2 (ja) * 2009-03-11 2013-07-24 富士通株式会社 管理装置の管理プログラム、管理装置、管理装置の管理方法およびストレージシステム
EP2425341B1 (en) * 2009-05-01 2018-07-11 Citrix Systems, Inc. Systems and methods for establishing a cloud bridge between virtual storage resources
US8335163B2 (en) * 2009-10-27 2012-12-18 Microsoft Corporation Quality of service (QOS) based systems, networks, and advisors
US9342801B2 (en) * 2010-03-29 2016-05-17 Amazon Technologies, Inc. Managing committed processing rates for shared resources
US20110238857A1 (en) * 2010-03-29 2011-09-29 Amazon Technologies, Inc. Committed processing rates for shared resources
JP5471822B2 (ja) * 2010-05-20 2014-04-16 富士通株式会社 入出力制御プログラム、情報処理装置および入出力制御方法

Also Published As

Publication number Publication date
EP2798488B1 (en) 2020-10-14
EP3783485A1 (en) 2021-02-24
EP2798488A4 (en) 2015-08-19
WO2013101947A1 (en) 2013-07-04
JP2015507268A (ja) 2015-03-05
EP2798488A1 (en) 2014-11-05
EP3796169A1 (en) 2021-03-24
KR20140107544A (ko) 2014-09-04

Similar Documents

Publication Publication Date Title
US10951488B2 (en) Rule-based performance class access management for storage cluster performance guarantees
US11212196B2 (en) Proportional quality of service based on client impact on an overload condition
JP6169105B2 (ja) ストレージシステムの動作を制御するための方法、装置、コンピュータプログラム及び記憶媒体
US11886363B2 (en) Quality of service policy sets
US20130227145A1 (en) Slice server rebalancing
US20230283681A1 (en) System and method for throttling service requests having non-uniform workloads
US9003021B2 (en) Management of storage system access based on client performance and cluser health
US11106485B2 (en) Modeling space consumption of a migrated VM
US7930481B1 (en) Controlling cached write operations to storage arrays
US10228860B2 (en) Storage optimization based I/O pattern modeling
US20150317556A1 (en) Adaptive quick response controlling system for software defined storage system for improving performance parameter
US10489074B1 (en) Access rate prediction in a hybrid storage device
US10409501B1 (en) Tiered data storage system using mobility scoring

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151225

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151225

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20160902

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20160902

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20160926

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20160926

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161109

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20161205

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161212

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20161206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170228

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170606

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170627

R150 Certificate of patent or registration of utility model

Ref document number: 6169105

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250