(57)【要約】【解決手段】  ストレージシステムにおいて仮想マシンごとにネイティブにサービス品質（ＱｏＳ）要件を満足させるための技術が開示される。様々な実施形態では、複数の仮想マシンの各々について、対応する入力／出力（Ｉ／Ｏ）リクエストキューがストレージシステムに格納される。リクエストは、仮想マシンごとのサービス品質パラメータに少なくとも部分的に基づいて決定された順序でストレージシステムにおいてそれぞれのリクエストキューから引き出されて対応するストレージ動作パイプラインに追加されるようにスケジュールされる。【選択図】図５
2018517201.tif 000002
【特許請求の範囲】
【請求項１】
ストレージシステムであって、
複数の仮想マシンの各々について、対応する入力／出力（Ｉ／Ｏ）リクエストキューを格納するように構成されているメモリと、
前記メモリに結合され、リクエストを、仮想マシンごとのサービス品質パラメータに少なくとも部分的に基づいて、決定された順序で前記それぞれのリクエストキューから引き出されて対応するストレージ動作パイプラインに追加されるようにスケジュールするように構成されているプロセッサと、
を備えるストレージシステム。
【請求項２】
請求項１に記載のストレージシステムであって、
前記プロセッサは、更に、リクエストを受信し、受信された各リクエストを前記入力／出力（Ｉ／Ｏ）リクエストキューのうちの対応する１つのキューにマッピングするように構成される、ストレージシステム。
【請求項３】
請求項２に記載のストレージシステムであって、
前記プロセッサは、受信された各リクエストを、前記リクエストが関連付けられているファイル識別子を前記リクエストから抽出し前記ファイル識別子を前記ファイル識別子が関連付けられている仮想マシンにマッピングすることによって前記入力／出力（Ｉ／Ｏ）リクエストキューのうちの対応する１つのキューにマッピングするように構成されている、ストレージシステム。
【請求項４】
請求項２に記載のストレージシステムであって、
前記リクエストは、１つ以上のハイパーバイザから受信される、ストレージシステム。
【請求項５】
請求項１に記載のストレージシステムであって、
前記プロセッサは、前記順序を、複数の仮想マシン間における自動的に決定された公平なリソースシェアリングに少なくとも部分的に基づいて決定するように構成されている、ストレージシステム。
【請求項６】
請求項１に記載のストレージシステムであって、
前記プロセッサは、前記順序を、異なるリクエストキューの中のリクエストに関連付けられたそれぞれのリクエストサイズに少なくとも部分的に基づいて決定するように構成されている、ストレージシステム。
【請求項７】
請求項１に記載のストレージシステムであって、
前記複数の仮想マシンのうちの少なくとも一部について、前記仮想マシンごとのサービス品質パラメータは、ＩＯＰＳ容量の最小シェアを含む、ストレージシステム。
【請求項８】
請求項７に記載のストレージシステムであって、
前記プロセッサは、前記順序を、前記最小シェア及びリクエストサイズに少なくとも部分的に基づいて決定するように構成されている、ストレージシステム。
【請求項９】
請求項１に記載のストレージシステムであって、
前記複数の仮想マシンのうちの少なくとも一部について、前記仮想マシンごとのサービス品質パラメータは、最大ＩＯＰＳ設定を含む、ストレージシステム。
【請求項１０】
請求項１に記載のストレージシステムであって、
前記プロセッサは、更に、少なくとも一部には実際のリクエストサイズを基準リクエストサイズと比較することによって決定される正規化ＩＯＰＳ指標を追跡及び報告するように構成されている、ストレージシステム。
【請求項１１】
請求項１に記載のストレージシステムであって、
前記プロセッサは、更に、仮想マシンごとに競合レイテンシを追跡及び報告するように構成されている、ストレージシステム。
【請求項１２】
請求項１に記載のストレージシステムであって、
前記プロセッサは、最大ＩＯＰＳ設定を遂行するように、及び関連付けられた絞り調整レイテンシの報告を追跡するように構成されている、ストレージシステム。
【請求項１３】
請求項１に記載のストレージシステムであって、
前記プロセッサは、ストレージシステムパフォーマンス容量のモデルに少なくとも部分的に基づいてリクエストをスケジュールするように構成されている、ストレージシステム。
【請求項１４】
請求項１３に記載のストレージシステムであって、
前記モデルは、ストレージシステム動作に固有なモデルを含む、ストレージシステム。
【請求項１５】
請求項１に記載のストレージシステムであって、
前記ストレージ動作パイプラインは、フロントエンド書き込みリクエストパイプラインを含み、前記プロセッサは、関連付けられたバックエンド書き込みパイプラインの現状態に少なくとも部分的に基づいてリクエストをスケジュールするように構成されている、ストレージシステム。
【請求項１６】
方法であって、
複数の仮想マシンの各々について、対応する入力／出力（Ｉ／Ｏ）リクエストキューをストレージシステムに格納し、
リクエストを、仮想マシンごとのサービス品質パラメータに少なくとも部分的に基づいて決定された順序でストレージシステムにおいて前記それぞれのリクエストキューから引き出されて対応するストレージ動作パイプラインに追加されるようにスケジュールする、
ことを備える方法。
【請求項１７】
請求項１６に記載の方法であって、更に、
リクエストを受信し、受信された各リクエストを前記入力／出力（Ｉ／Ｏ）リクエストキューのうちの対応する１つのキューにマッピングすることを備える方法。
【請求項１８】
請求項１７に記載の方法であって、
受信された各リクエストは、前記リクエストが関連付けられているファイル識別子を前記リクエストから抽出し前記ファイル識別子を前記ファイル識別子が関連付けられている仮想マシンにマッピングすることによって記入力／出力（Ｉ／Ｏ）リクエストキューのうちの対応する１つのキューにマッピングされる、方法。
【請求項１９】
請求項１６に記載の方法であって、
前記順序は、複数の仮想マシン間における自動的に決定された公平なリソースシェアリングに少なくとも部分的に基づいて決定される、方法。
【請求項２０】
非一時的なコンピュータ読み取り可能ストレージ媒体に記録されているコンピュータプログラム製品であって、
複数の仮想マシンの各々について、対応する入力／出力（Ｉ／Ｏ）リクエストキューをストレージシステムに格納するためのコンピュータ命令と、
リクエストを、仮想マシンごとのサービス品質パラメータに少なくとも部分的に基づいて決定された順序で前記ストレージシステムにおいて前記それぞれのリクエストキューから引き出されて対応するストレージ動作パイプラインに追加されるようにスケジュールするためのコンピュータ命令と、
を備えるコンピュータプログラム製品。
【発明の詳細な説明】
【背景技術】
【０００１】
［関連技術の相互参照］
本出願は、２０１５年４月８日に出願され名称を「ＮＡＴＩＶＥ  ＳＴＯＲＡＧＥ  ＱＵＡＬＩＴＹ  ＯＦ  ＳＥＲＶＩＣＥ  ＦＯＲ  ＶＩＲＴＵＡＬ  ＭＡＣＨＩＮＥＳ  ＷＩＴＨ  ＰＥＲ−ＶＭ  ＣＯＮＴＥＮＴＩＯＮ  ＶＩＳＵＡＬＩＺＡＴＩＯＮ  ＡＮＤ  ＡＵＴＯ  ＡＬＬＯＣＡＴＩＯＮ  ＰＯＬＩＣＩＥＳ（仮想マシンごとの競合可視化及び自動割り当てのポリシーを伴う仮想マシンのためのネイティブなストレージサービス品質）」とする米国仮特許出願第６２／１４４，５１８号に基づく優先権を主張する。この出願は、あらゆる目的のために、参照によって本明細書に組み込まれる。
【０００２】
通常、ストレージシステムは、仮想マシン（ＶＭ）を認識しない。その代わり、通常のシステムは、ファイルシステムリクエスト（例えば、ファイル作成、読み出し、書き込みなど）を受信し、そのようなリクエストを、そのリクエストがどのＶＭに関連付けられているかを全く認識することなく実施する。
【０００３】
ストレージサービス品質（ＱｏＳ）は、２つの主要研究分野、即ち、１）スペースシェアリング（共有）と、２）パフォーマンスシェアリングとに分類できる。パフォーマンスシェアリングの２つの重要な使用事例は、「パフォーマンス分離」と、「パフォーマンス保護」とを特徴とする。
【０００４】
パフォーマンス分離は、あるストレージシステムリソースコンシューマのＩ／Ｏトラフィックを別のストレージシステムリソースコンシューマのＩ／Ｏトラフィックから分離することを言う。これは、仮想化された環境において重要だと考えられる。なぜならば、複数のＶＭユーザが、異なる種類のアプリケーションを実行していることがあり、その場合、一方のＶＭユーザが、他方のＶＭユーザのＩ／Ｏパフォーマンスに影響を及ぼすべきではないからである。しかしながら、通常のストレージシステムは、どのＩ／ＯリクエストがどのＶＭに関連付けられているかをネイティブに認識しないので、ＶＭごとのパフォーマンス分離は、通常のストレージシステムにおいてネイティブに利用できるものではない。
【０００５】
パフォーマンス保護は、１つ以上の既定のパフォーマンス消費指標に基づいてサービスプロバイダがエンドユーザに課金するストレージ環境においてサービスレベルを提供することを言う。ストレージシステムリソースコンシューマ（消費体）へのパフォーマンスサービスレベルは、例えば、ＩＯＰＳ又はスループットなどのパフォーマンス指標に最下限及び最上限を設定することによって割り振られてよい。リソースコンシューマへの最下限は、少なくとも指定されたパフォーマンスサービスレベルをそのリソースコンシューマのために保証し、リソースコンシューマへの最上限は、指定されたパフォーマンスサービスレベルまでをそのリソースコンシューマに保証する。場合によっては、サービスレベルは、あるリソースコンシューマがストレージＩ／Ｏリソースの消費を独り占めし、それによってその他のリソースコンシューマからパフォーマンスを奪う悪評高い厄介な競合問題を解決するために使用される。
【０００６】
保証されたサービスレベルからユーザが期待できることは、どれくらいのシステムリソースが利用可能であるかに大いに依存する。どのストレージアプライアンスも、それが送ることができるパフォーマンスに上限がある。したがって、ストレージＱｏＳは、ユーザがパフォーマンスに関してストレージシステムに過剰な設定を行うと、その旨をユーザに通知できることが望ましい。
【０００７】
パフォーマンス保護は、また、サービスレベルを設定されたリソースコンシューマと、サービスレベルを設定されていないリソースコンシューマとがいる場合に、一連の複雑性を生じる。これは、システムパフォーマンスリソースの割り当て間に不均衡を生じることがあり、ひいては枯渇を招く恐れがある。
【０００８】
正しいパフォーマンス指標の使用が、最小及び最大についてＶＭごとのストレージＱｏＳポリシーを設定するにあたって重要だと考えられる。ＩＯＰＳは、広く使用されている指標であるが、パフォーマンスの尺度を正しく精測するものではない。なぜならば、ＶＭのＩ／Ｏリクエストのサイズが様々であるゆえに、スループットの方が、より現実的なパフォーマンス測定基準であるからである。しかしながら、パフォーマンスの尺度としてユーザに馴染みがあるのは、ＩＯＰＳの方である。
【図面の簡単な説明】
【０００９】
本発明の様々な実施形態が、以下の詳細な説明及び添付の図面において開示される。
【００１０】
【図１】仮想マシン認識ストレージシステム及び仮想マシン認識環境の一実施形態を示したブロック図である。
【００１１】
【図２】どのファイルがどの仮想マシンに関連付けられるかを追跡するためのプロセスの一実施形態を示したフローチャートである。
【００１２】
【図３Ａ】ストレージシステムパフォーマンスをモデル化するためのプロセスの一実施形態を示したフローチャートである。
【００１３】
【図３Ｂ】仮想マシン認識システムの一実施形態におけるストレージシステムパフォーマンスのグラフの一例を示した図である。
【００１４】
【図３Ｃ】仮想マシン認識システムの一実施形態におけるストレージシステムパフォーマンスのグラフの一例を示した図である。
【００１５】
【図４】ＱｏＳパラメータを仮想マシンごとに実装するためのプロセスの一実施形態を示したフローチャートである。
【００１６】
【図５】ＶＭごとのＩ／Ｏキューを伴う仮想マシン認識ストレージシステムの一実施形態を示したブロック図である。
【００１７】
【図６】仮想マシン認識ストレージシステムの一実施形態に実装される比例スケジューラの一例を示した図である。
【００１８】
【図７】最大ＩＯＰＳ  ＱｏＳパラメータを遂行するように構成されている仮想マシン認識ストレージシステムの一実施形態を示したブロック図である。
【００１９】
【図８】ストレージシステムパフォーマンスの可視化をＶＭごとに提供するためのプロセスの一実施形態を示したフローチャートである。
【００２０】
【図９】正規化されたストレージシステムパフォーマンスをＶＭごとに報告するためのプロセスの一実施形態を示したフローチャートである。
【００２１】
【図１０】バックエンド書き込みキュー状態に基づいてフロントエンド書き込みキューへの許可を調整するように構成されている仮想マシン認識ストレージシステムの一実施形態を示したブロック図である。
【００２２】
【図１１】バックエンド書き込みキュー状態に基づいてフロントエンド書き込みキューへの許可を調整するためのプロセスの一実施形態を示したフローチャートである。
【００２３】
【図１２】プログラムによって決定された割り当てにしたがってストレージリソースの使用を許すためのプロセスの一実施形態を示したフローチャートである。
【００２４】
【図１３】利用可能なリソースと、様々なストレージシステムリソースコンシューマクラスに関連付けられたそれぞれのＱｏＳパラメータとに基づいてプログラムによってストレージシステムリソースを割り当てるためのプロセスの一実施形態を示したフローチャートである。
【００２５】
【図１４】ストレージシステムリソース割り当てを柔軟に遂行するためのプロセスの一実施形態を示したフローチャートである。
【００２６】
【図１５】ストレージシステムリソースの割り当てを遂行するように構成されているストレージシステムスケジューラの一実施形態を示したブロック図である。
【発明を実施するための形態】
【００２７】
本発明は、プロセス、装置、システム、合成物、コンピュータ読み取り可能ストレージ媒体に実装されたコンピュータプログラム製品、並びに／又は接続先のメモリに格納された命令及び／若しくは接続先のメモリによって提供される命令を実行するように構成されているプロセッサなどのプロセッサを含む、数々の形態で実現できる。本明細書では、これらの実現形態、又は本発明がとりえるその他のあらゆる形態が、技術と称されてよい。総じて、開示されるプロセスのステップの順序は、発明の範囲内で変更されてよい。別途明記されない限り、タスクを実施するように構成されるものとして説明されるプロセッサ又はメモリなどのコンポーネントは、所定時にタスクを実施するように一時的に構成される汎用コンポーネントとして、又はタスクを実施するように製造された特殊コンポーネントとして実装されてよい。本書で使用される「プロセッサ」という用語は、コンピュータプログラム命令などのデータを処理するように構成されている１つ以上のデバイス、回路、及び／又は処理コアを言う。
【００２８】
本発明の原理を例示した添付の図面とともに、以下で、本発明の１つ以上の実施形態の詳細な説明が提供される。本発明は、このような実施形態に関連付けて説明されるが、いずれの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、数々の代替形態、変更形態、及び同等形態を包含している。以下の説明では、本発明の完全な理解を与えるために、数々の具体的詳細が明記されている。これらの詳細は、例示を目的として提供されるものであり、本発明は、これらの詳細の一部又は全部を伴わずとも特許請求の範囲にしたがって実施されてよい。明瞭を期するため、本発明に関連する技術分野で知られる技術要素は、本発明が不必要に不明瞭にされないように詳細な説明を省略される。
【００２９】
ＶＭごとにサービス品質（ＱｏＳ）をネイティブに提供するＶＭ認識ストレージアプライアンス又はその他のストレージシステムが開示される。様々な実施形態では、例えば１つ以上のハイパーバイザから受信された、ＶＭごとの固有な読み出しリクエスト及び書き込みリクエストのキューが維持される。リクエストは、対応するＶＭ別のキューにマッピングされる。スケジューラは、それぞれのキューからのリクエストを、それぞれのキューに関連付けられた及び／又はそれらのキューが関連付けられているそれぞれのＶＭに関連付けられたそれぞれのＱｏＳパラメータ（例えば、最小ＩＯＰＳや最大ＩＯＰＳなど）に少なくとも部分的に基づいて決定された順序で１つのパイプラインに又はもし該当する場合は一部の実施形態では別々の読み出しパイプライン及び書き込みパイプラインに入れられるように許可する。
【００３０】
様々な実施形態では、例えばＶＭウェア及びＨｙｐｅｒ−Ｖなどのハイパーバイザ環境に密に一体化されたストレージアプライアンスが提供される。ハイパーバイザ環境との一体化を通じて、ストレージアプライアンスのファイルシステムは、そこに常住しているＶＭに関する情報を有する。このＶＭ情報によって、ファイルシステムは、２つの異なるＶＭによって生成されたＩ／Ｏを区別することができる。様々な実施形態では、どのＩ／ＯがどのＶＭに関連付けられているかについてのこの認識が、ＶＭごとのストレージサービス品質（ＱｏＳ）を提供するための基礎を形成する。
【００３１】
図１は、仮想マシン認識ストレージシステム及び仮想マシン認識環境の一実施形態を示したブロック図である。図に示された例では、図１でハイパーバイザ１０２及び１０４で表されている複数のハイパーバイザの各々が、ネットワーク１０６を通じて仮想マシン認識ストレージシステム１０８へのアクセスを有する。各ハイパーバイザは、ハイパーバイザ１０２に関連付けられたＶＭ１１２とＶＭ１１４、及びハイパーバイザ１０４に関連付けられたＶＭ１１６とＶＭ１１８によって表されるものなどの、複数の仮想マシン（ＶＭ）を管理する。仮想マシン認識ストレージシステム１０８は、仮想マシン関連データを、バックエンドストレージ１１０に格納されているファイルに格納する。例えば、図１でＶＭ１１２、１１４、１１６、及び１１８によって表されている各ＶＭは、関係したファイルを、仮想マシン認識ストレージシステム１０８に格納されていてよい。バックエンドストレージ１１０は、フラッシュストレージ（例えば、ＳＳＤ）、ハードディスクドライブ、及び／又はハイブリッド／階層状のフラッシュ・ハードディスクドライブストレージのうちの１つ以上を含んでいてよい。
【００３２】
様々な実施形態では、仮想マシン認識ストレージシステム１０８は、仮想マシン認識ストレージを提供するように最適化されたオペレーティングシステムを実行させる。様々な実施形態では、仮想マシン認識ストレージシステム１０８は、ハイパーバイザ１０２及び１０４などのハイパーバイザに高度に一体化される。仮想マシン認識ストレージシステム１０８は、仮想マシン認識ストレージシステム１０８に格納されているどのファイルがどの（１つ又は複数の）仮想マシンに関連付けられるかを追跡するために、ハイパーバイザ１０２及び１０４などのハイパーバイザから直接的に及び／又は間接的に得られた情報を使用する。一部の実施形態では、仮想マシン認識ストレージシステム１０８は、最近新しくファイルを作成したハイパーバイザに、その新しく作成されたファイルが関連付けられる仮想マシンをもしあれば決定するために照会を行ってよい。一部の実施形態では、仮想マシン認識ストレージシステム１０８は、新規ファイルの作成に関連してハイパーバイザから受信されたファイル作成の及び／若しくはそれに関係したリクエスト及び／又は通信から、仮想マシン識別子情報を抽出してよい。例えば、リクエストを発信しているハイパーバイザが関連付けられているハイパーバイザタイプの認識に基づいて、仮想マシン認識ストレージシステム１０８は、ハイパーバイザによって送信された通信及び／又はハイパーバイザからのリクエストから、ハイパーバイザタイプに少なくとも部分的に基づいて決定された方式で、仮想マシン識別をファイルに関連付ける情報を抽出してよい。
【００３３】
様々な実施形態では、どのファイルがどの（１つ又は複数の）仮想マシンに関連付けられているかについてのこの認識は、以下で更に詳細に説明されるように、例えば仮想マシン認識ストレージシステム１０８などのストレージシステムにＶＭごとにストレージシステムサービス品質をネイティブに提供するために使用されてよい。
【００３４】
図２は、どのファイルがどの仮想マシンに関連付けられるかを追跡するためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図２のプロセスは、図１の仮想マシン認識ストレージシステム１０８などの仮想マシン認識ストレージシステムによって実行されてよい。様々な実施形態では、仮想マシン認識ストレージシステムのファイルシステムが、図２のプロセスを実施してよい。図に示された例では、新規ファイルが作成される（２０２）ときに、その新規ファイルが関連付けられる仮想マシンが存在すれば決定される（２０４）。一部の実施形態では、ハイパーバイザが、新規ファイルが関連付けられる仮想マシン識別子を示してよい。この表示は、ファイルを作成するためのリクエストに及び／又は後続の通信に関連して受信されてよい。一部の実施形態では、ハイパーバイザは、ファイルが関連付けられる仮想マシンを決定するために、例えばハイパーバイザのＡＰＩを通じて照会されてよい。もし、ファイルが仮想マシンに関連付けられると決定されたならば（２０６）、そのファイルを対応する仮想マシンに関連付けるデータが、例えば表、インデックス、データベース、又はその他のデータ構造及び／又はリポジトリに格納される（２０８）。もし、新規ファイルが仮想マシンに関連付けられない（若しくは関連付けられるとまだ決定されていない）ならば（２０６）、又はそのファイルを対応する仮想マシンに関連付けるデータが格納されたら（２０８）、プロセスは終了する。
【００３５】
様々な実施形態では、様々なサイズのＩ／Ｏリクエストに関わるストレージシステムパフォーマンスのモデルを生成するために、仮想マシン認識ストレージシステムが較正及び／又はテストされてよい。結果として得られる（１つ又は複数の）モデルは、様々な実施形態では、例えば異なるサイズのＩ／Ｏリクエストを生成するなどの非類似の特性を有するだろう複数のＶＭとの関わりでＶＭごとにＱｏＳを提供するために使用されてよい。例えば、一部の実施形態では、仮想マシンは、異なるサイズ（例えば、８ｋＢや２５６ｋＢなど）のリクエスト（例えば、読み出しリクエストや書き込みリクエスト）を作成するように構成されてよい。リクエストのサイズが大きいほど、小さいサイズのリクエストよりも例えば処理時間が多く必要である。様々な実施形態では、異なるリクエストサイズを使用するように構成されるだろう複数のＶＭにわたってＶＭごとにＱｏＳが提供されることを可能にするために、リクエストサイズの違いを超えてストレージシステムパフォーマンスをモデル化するように生成される。
【００３６】
図３Ａは、ストレージシステムパフォーマンスをモデル化するためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図３Ａのプロセスは、図１の仮想マシン認識ストレージシステム１０８などの仮想マシン認識ストレージシステムによって及び／又は図１の仮想マシン認識ストレージシステム１０８などの仮想マシン認識ストレージシステムとの関わりで実施されてよい。図に示された例では、異なるリクエストサイズ（例えば、８ｋＢ、１６ｋＢ、３２ｋＢ、６４ｋＢ、２５６ｋＢなど）にわたってストレージシステムパフォーマンスを特徴付けるために、テストが行われる（３０２）。例えば、所定のリクエストサイズについて、リクエストが数（ＩＯＰＳ）を増やしてサブミットされてよく、様々なワークロードでのストレージシステムのレイテンシ（例えば、リクエストを完了させるまでの時間）が観察されてよい。１つ以上のパフォーマンスモデルを生成するために、統計分析が実施される（３０４）。一部の実施形態では、読み出しパフォーマンス及び書き込みパフォーマンスについて、それぞれ別々のモデルが生成されてよい。様々な実施形態では、モデルは、例えば、キューと、読み出し動作を実施するための関連付けられたパイプラインとからなる一式、及びキューと、書き込み動作を実施するための関連付けられたパイプラインとからなる別の一式のような、ＩＯＰＳを実施するための、ＶＭごとのキューと、関連付けられたパイプラインとを設計及び管理するために使用されてよい。一部の実施形態では、（１つ又は複数の）モデルは、ストレージシステムによって、ＶＭ別のキューから該キューに関連付けられたＩ／Ｏパイプライン（例えば、読み出しパイプラインや書き込みパイプライン）に次のリクエストを許可するかどうかを決定するために使用されてよい。例えば、パイプラインは、所定の時点でストレージシステムが扱うことができる、一部の実施形態では総「コスト」として及び／又はスループット（例えばキロバイト単位）で表される最大ワークロードに関する理解にしたがって、サイズ決定されてよい。もし、パイプラインにおける現時点でのワークが総容量未満であり、尚且つ（１つ又は複数の）適用可能モデルに基づくと、（例えば、そのリクエストを次にパイプラインへ許可される順番にあるキューから）次のリクエストを追加することによる「コスト」増分が総システム容量（例えば、パイプラインサイズ）を超えさせる結果とならないならば、そのリクエストは、許可されてよい。
【００３７】
図３Ｂは、仮想マシン認識システムの一実施形態におけるストレージシステムパフォーマンスのグラフの一例を示した図である。図に示された例において、グラフ３２０では、レイテンシが、所定のリクエストサイズにおけるＩＯＰＳの数又は所定のサイズのリクエストに基づくデータスループット（例えば、８ｋＢ）などのワークロード（「パフォーマンス」）の増加に対してプロットされている。曲線３２２は、この例で観察された結果を示している。ワークロード「Ｘｉ」に対応する地点「Ｐ」では、Ｘｉよりもワークロードが軽いときと比べて、レイテンシが、リクエスト数（及び／又は所定サイズのリクエストの増加に関連付けられたスループット）の増加に伴うワークロードの増加とともに急激に増加し始めることが見て取れる。
【００３８】
図３Ｃは、仮想マシン認識の一実施形態におけるストレージシステムパフォーマンスのグラフの一例を示した図である。図に示された例では、様々なリクエストサイズに関連付けられたそれぞれの変曲点Ｘｉが、グラフ３４０にプロットされており、スループットの増加を伴うことなくレイテンシの急増前の飽和限界で処理できる所定のサイズのリクエストの数によって様々なリクエストサイズにわたってシステム容量を特徴付ける線３４２を決定するために、統計処理（例えば、線形回帰分析）が実施される。
【００３９】
様々な実施形態では、図３Ａ〜３Ｃに関連して上述されたような解析が、ストレージシステムを特徴付けるために及び様々なワークロードを扱うその能力をモデル化するために実施されてよい。一部の実施形態では、リクエストを実施するためとして観察された「コスト」の、リクエストサイズに依存しない第１の成分と、リクエストのサイズに起因する第２の成分とを区別するために、計算が実施されてよい。例えば、もし、ストレージシステムが、８ｋＢリクエスト及び２５６ｋＢリクエストなどの２つの異なるサイズのリクエストで特徴付けられるならば、それぞれのサイズでレイテンシが急上昇したときの上記リクエストの数の間に、等価関係が設定されてよい。
【００４０】
ｘ8k（８ｋ＋コスト）＝ｘ256k（２５６ｋ＋コスト）
【００４１】
一部の実施形態では、ｘ8k及びｘ256kは、テストによって決定され、上記の方程式は、キロバイト（ｋＢ）で表されるサイズ非依存コスト成分（例えば、上記の方程式における「コスト」）を決定するために解かれる。例えば、もし、ストレージシステムがリクエストで飽和に達するパフォーマンステストにおいて、８ｋＢリクエストサイズで６４のリクエスト又は２５６ＫＢで４のリクエストが十分であった、即ち、スループットの増加を伴うことなくレイテンシの急上昇前に処理できたならば、算出されるリクエストサイズ非依存コスト成分は、８．５ｋＢになる。一部の実施形態では、パイプラインに次のリクエストを追加するコストは、この例では８．５ｋＢであるサイズ非依存コストをリクエストサイズに加えたものだと見なせるだろう。例えば、次の８ｋＢリクエストは、少なくとも１６．５ｋＢに相当するパイプラインが空いている場合にのみ追加されてよく、それに対し、次の２５６ｋリクエストは、パイプラインの中に少なくとも２６４．５ｋＢの容量が空いている場合のみ追加されてよい。
【００４２】
図４は、ＱｏＳパラメータを仮想マシンごとに実装するためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図４のプロセスは、図１のストレージシステム１０８などの仮想マシン認識ストレージシステムによって実行されてよい。図に示された例では、１つ以上の仮想マシンの各々について、サービス品質（ＱｏＳ）パラメータデータが受信される（４０２）。様々な実施形態では、ＱｏＳパラメータは、管理ユーザインターフェース、又はＡＰＩ、ウェブサービスコール、若しくはその他のプログラムインターフェース、又は設定ファイルなどを通じて受信されてよい。様々な実施形態では、ストレージシステムに格納されている全て又は一部のファイルが、ＱｏＳパラメータに関連付けられてよい。例えば、ファイルによって、最小ＩＯＰＳ  ＱｏＳパラメータ値を各々に割り振られた仮想マシンに関連付けられていたり、最小ＩＯＰＳコミットメントが設定されていない仮想マシンに関連付けられていたり、及び／又はいかなる仮想マシンにも（まだ）関連付けられていなかったりしてよい。
【００４３】
図４を更に参照すると、ストレージシステムは、受信されたＱｏＳパラメータに少なくとも部分的に基づいて決定される方式でリクエストを処理するように構成される（４０４）。様々な実施形態では、仮想マシン別のキューは、仮想マシンに関連付けられたファイルに関連付けられたリクエストにサービス（情報）を提供するために使用され、リクエストは、それぞれの仮想マシンに及び／又はそのそれぞれの対応するキューに関連付けられたそれぞれのＱｏＳパラメータ値がもしあれば、そのようなＱｏＳパラメータ値に少なくとも部分的に基づいて、サービスを受けるためにそれぞれのキューから引き出される。
【００４４】
図５は、ＶＭごとのＩ／Ｏキューを伴う仮想マシン認識ストレージシステムの一実施形態を示したブロック図である。様々な実施形態では、図５に示された要素は、図１のストレージシステム１０８などの仮想マシン認識ストレージシステムに含まれてよい。図に示された例では、ストレージシステム５０２は、１つ以上のハイパーバイザからなるハイパーバイザセットからリクエスト（例えば、ファイル作成／削除、読み出し、書き込み）を受信するように構成されている通信インターフェース５０４を含む。通信インターフェース５０４は、受信された各リクエストについて、そのリクエストが関連付けられている仮想マシンを決定するために、及びそのリクエストを対応する仮想マシン別のキュー５０６の中の次の空き位置（がもしあればその位置）に置くために、ネットワークインターフェース（例えば、ネットワークインターフェースカード）及びロジックの一方又は両方を含んでいてよい。様々な実施形態では、リクエストが関連付けられている仮想マシンは、リクエストが関連付けられているファイルに及びそのファイルを対応する仮想マシンに関連付ける事前に格納されたデータに少なくとも部分的に基づいて決定されてよい。複数の仮想マシン別のキュー５０６のそれぞれの中のリクエストの場所は、処理のためにリクエストのパイプライン５１０に追加されるように、比例スケジューラ５０８によってスケジュールされる。例えば、パイプライン５１０の中の次の空き位置５１２は、次にスケジュールされたリクエストをキュー５０６のなかから引き出してそれをパイプライン５１０の位置５１２に追加することによって満たされてよい。Ｉ／Ｏエンジン５１４は、パイプライン５１０からリクエストを引き出し、例えば関連付けられたファイルからデータを読み出す及び／又は関連付けられたファイルにデータを書き込むことによって各リクエストに順番にサービスを提供する。一部の実施形態では、ストレージシステムの読み出しパフォーマンスと書き込みパフォーマンスとが、別々にモデル化され、別々のキュー及び／又はパイプライン構造が、読み出しリクエストの管理及び処理と書き込みリクエストの管理及び処理とにそれぞれ使用されてよい。
【００４５】
図６は、仮想マシン認識ストレージシステムの一実施形態に実装される比例スケジューラの一例を示した図である。様々な実施形態では、図６に示されたスケジュールは、図５のスケジューラ５０８などの比例スケジューラによって作成されるスケジュールの一例であってよい。図に示された例では、スケジュール６０２は、５つの仮想マシンの各々について、「ｖｍ−１」から「ｖｍ−５」までで標識された列に、１０のスケジュールラウンドのラウンドごとに、対応する「仮想時間」を含む。この対応する「仮想時間」は、仮想マシンに関連付けられた仮想マシン別のキューから、次のリクエストが、スケジュール６０２が関連付けられているパイプライン（例えば、読み出しリクエストパイプラインや書き込みリクエストパイプラインなど）に追加される時間である。図に示された例では、ストレージシステムリソースは、５つのＶＭの間で、それぞれに帰属する「シェア」の数（記入がある第１の行を参照）、即ち、１０、８０、２０、６０、及び４０によってそれぞれ示されるだけ割り当てられている。各ＶＭに関連付けられたそれぞれのリクエストサイズ（「ワークロード」と記された行）が示されており、具体的には、それぞれ８ｋＢ、２５６ｋＢ、１６ｋＢ、６４ｋＢ、及び３２ｋＢである。各ＶＭについて計算される、この例ではＶＭに帰属するシェアの数をリクエストサイズで割ったものとして定義される「ワーク」値が、図のように算出されている。例えば、６０４で標識されたボックスに示されるように、ＶＭ  ｖｍ−１及びｖｍ−２についてのワーク値は、それぞれ１．２５及び０．３１２５である。ｖｍ−１に関連付けられた各リクエストは、ｖｍ−２からのリクエストの４倍のワークを必要とすると見なされる（１．２５＝４×０．３１２５）ので、６０６で標識された角括弧によって示されるように、スケジューラは、ｖｍ−２から４つのリクエストがパイプラインに追加される間にｖｍ−１からは１つのリクエストのみをパイプラインに追加されるようにスケジュールしている。同様に、６０８で標識された破線の両矢印によって示されるように、ｖｍ−４からのリクエストへのサービス提供に関連付けられたワークは、ｖｍ−２からのリクエストのそれの３倍であると計算されたので、対をなす破線の角括弧６１０によって示されるように、ｖｍ−４から１つのリクエストがスケジュールされる間にｖｍ−２から３つのリクエストがスケジュールされている。このように、スケジュール６０２は、ストレージシステムリソースへの公平なアクセスを保証しており、リソースは、この例では不均等に割り当てられたストレージシステムの「シェア」を反映するように調整されたワークロード（例えば、リクエストサイズ）に比例して割り当てられている。
【００４６】
様々な実施形態では、対応する各ＶＭに割り当てられるシェアは、一部の実施形態では、対応する各ＶＭが関連付けられている対応する各ＶＭ及び／又はＱｏＳ（若しくはその他の）カテゴリに関連付けられたＱｏＳ保証（例えば最小ＩＯＰＳ）及び／又は限界（例えば最大ＩＯＰＳ）に少なくとも部分的に基づいて、プログラムによって決定されてよい。一部の実施形態では、シェアは、例えば管理ユーザインターフェース又はその他のユーザインターフェースを通じて手動で割り当てられてよい。
【００４７】
図７は、最大ＩＯＰＳ  ＱｏＳパラメータを遂行するように構成されている仮想マシン認識ストレージシステムの一実施形態を示したブロック図である。様々な実施形態では、図７に示されたコンポーネント及び関連の技術は、図１のストレージシステム１０８などの仮想マシン認識ストレージシステムに組み込まれてよい。図に示された例では、パイプライン２の中のリクエストが、Ｉ／Ｏエンジン７０４によってサービスを受ける。各リクエストがサービスを受ける際、もし、そのリクエストが、最大ＩＯＰＳ  ＱｏＳパラメータを関連付けられた仮想マシンに関連付けられているならば、リクエスト肯定応答が生成され、ただし、この肯定応答は、図に示された例における仮想マシン別の漏出バケツ（先入れ先出しバケツ）７０６、７０８、及び７１０などの漏出バケツタイプのデータ構造を少なくとも使用して決定される次の時間まで送信されない。各漏出バケツ（７０６、７０８、７１０）は、その漏出バケツが関連付けられている仮想マシンに関連付けられた最大ＩＯＰＳパラメータに関連付けられた速度で肯定応答を発信する。一部の実施形態では、限られた時間にわたってＶＭ  Ｉ／Ｏが最大ＩＯＰＳを超えてバーストする条件が存在し、これは、そのＶＭによって生成されるバーストサイクルの数に比例する。このような方式による肯定応答の抑制の結果、（少なくとも正常に動作している）リクエスト送信元（例えば、特定のＶＭに関連付けられたハイパーバイザ及び／又はスレッド）は、ストレージシステムへの新しいリクエストの送信を調整し、そのＶＭについて最大ＩＯＰＳを効果的に遂行する。図に示された例では、漏出バケツ７０８によって発信される肯定応答７１２は、その肯定応答７１２に関連付けられているリクエストを送信したノード（例えば、ハイパーバイザ）に通信７１４を通じて送信されてよい。漏出バケツ７０６、７０８、及び７１０からまだ発信されていないその他の肯定応答は、関連付けられたリクエストがたとえ完了していたとしても、それらの肯定応答が各々その対応する漏出バケツから発信されてよい後の時点まで送信されない。
【００４８】
一部の実施形態では、リクエストは、図５に示された５０６などのＶＭキューの中で待機して時間を費やし、ＶＭのＩ／Ｏリクエストに起因するこのようなレイテンシは、ストレージリソースのためにこのＶＭが経験する競合の度合い（本書では、「競合レイテンシ」と呼ぶこともある）を決定する。
【００４９】
一部の実施形態では、ＶＭからのリクエストは、図７に示されるように、クライアントソースに肯定応答が送信される前に絞り調整され、これは、このような絞り調整に関連付けられた、例えば最大ＩＯＰＳ  ＱｏＳパラメータを遂行するためのレイテンシ（本書では、「絞り調整レイテンシ」と呼ぶこともある）が、実施されるためにキュー及び／又はパイプラインの中で待機することに関連付けられたレイテンシ（本書では、「競合レイテンシ」と呼ぶこともある）から区別される（、並びに／又はそれとは別に報告される及び／若しくは可視化して表される）ことを可能にする。
【００５０】
図８は、ストレージシステムパフォーマンスの可視化をＶＭごとに提供するためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図８のプロセスは、図１のストレージシステム１０８などの仮想マシン認識ストレージシステムの分析及び／又は報告モジュールによって実行されてよい。図に示された例では、競合レイテンシ（例えば、キューの中にある時間、パイプラインの中にある時間、及び実際の処理時間のうちの１つ以上）と、（例えば、図７のような、最大ＩＯＰＳを遂行するための）絞り調整レイテンシとが、ＶＭごとに別々に（８０２）。例えば、所定のＶＭについて、各リクエストについての競合時間を算出するために、そのＶＭに関連付けられたＶＭ別のキューに各リクエストが追加される時間が、対応する肯定応答が生成された時間と比較されてよく、この肯定応答が生成された時間は、絞り調整レイテンシを（もしあれば）算出するために、肯定応答が送信された時間と比較されてよい。このような統計は、ＶＭごとに計算、集約、蓄積などされてよい。競合レイテンシ、絞り調整レイテンシ、又はその両方をＶＭごとに報告するために、報告及び／又は可視化が生成及び提供されてよい（８０４）。
【００５１】
図９は、正規化されたストレージシステムパフォーマンスをＶＭごとに報告するためのプロセスの一実施形態を示したフローチャートである。本書で説明されるように、異なるＶＭ及び／又はハイパーバイザが、異なるサイズ（例えば、８ｋＢや２５６ｋＢなど）の読み出し及び／又は書き込みリクエストをサブミットするように構成されてよい。したがって、最も馴染みのある旧来のストレージシステムパフォーマンスの尺度である「ＩＯＰＳ」、即ち「１秒あたりのＩ／Ｏ」は、様々なワークロードサイズにわたって完全に且つ正確にパフォーマンス達成度を反映することはできないだろう。様々な実施形態では、したがって、ＩＯＰＳ、又はスループット（例えば、所定の期間内に何バイトが読み出された及び／若しくは書き込まれたか）などのその他のパフォーマンス尺度に追加して、及び／又は代わって、「正規化ＩＯＰＳ」が計算及び報告されてよい。一部の実施形態では、８ｋＢなどの基準サイズではないサイズのリクエストに関わるストレージシステムのパフォーマンスは、基準リクエストサイズのワークロードに関わるパフォーマンスと、より直接的に比較可能であるために、正規化されてよい。例えば、サイズ８ｋＢのリクエストに関わるＩ／Ｏ動作の完了が、１正規化ＩＯＰであると見なされてよく、それに対し、サイズ２５６ｋＢのリクエストに関わる同じ動作の１回の反復は、このリクエストサイズが３２倍の大きさであるゆえに、３２正規化ＩＯＰＳであるとカウントされてよい。
【００５２】
更に図９を参照すると、図に示された例では、各リクエストサイズについて、１秒あたりの実際のＩ／Ｏ動作の数（実際のＩＯＰＳ）が決定される（９０２）。それぞれの実際のＩＯＰＳ数は、対応する正規化ＩＯＰＳを例えばＶＭごとに計算するために使用される（９０４）。実際のＩＯＰＳ及び計算された正規化ＩＯＰＳの一方又は両方が、報告及び／又は可視化に含められる（９０６）。
【００５３】
図１０は、バックエンド書き込みキュー状態に基づいてフロントエンド書き込みキューへの許可を調整するように構成されている仮想マシン認識ストレージシステムの一実施形態を示したブロック図である。様々な実施形態では、仮想マシン認識ストレージシステムは、ファイルに書き込まれることをリクエストされたデータを、先ず、フロントエンド書き込みプロセスにおいて不揮発性メモリに格納し、そして、それとは別に、バックエンド書き込みプロセスにおいて、最初に不揮発性メモリに書き込まれたデータをより恒久的に半導体ドライブ（ＳＳＤ）／フラッシュストレージに書き込むことによって、書き込みリクエストを処理してよい。様々な実施形態では、次の書き込みリクエストをフロントエンドパイプラインへ許可するかどうかを決定するために、バックエンドキュー／パイプラインの深さが監視及び考慮される。
【００５４】
図１０に示された例では、例えばスケジューラ１００２が、リクエストを、ＶＭ別のキュー（図１０では図示されていない）から引き出されてフロントエンド書き込みリクエストパイプライン１００４に追加されるようにスケジュールするように構成される。Ｉ／Ｏエンジン（図１０では図示されていない）は、各リクエストで書き込まれることをリクエストされたデータをＮＶＲＡＭ１００６に格納することによって、パイプライン１００４の中のリクエストにサービスを提供する。バックエンドパイプライン１００８が、ＮＶＲＡＭ１００６からの読み出しの、及びＮＶＲＡＭ１００６に最初に書き込まれたデータのＳＳＤ／フラッシュ１０１０へのより恒久的な書き込みの、バックエンドプロセスを管理するために使用される。図に示された例では、フロントエンドパイプライン１００４の中の空き位置１０１４へ次の書き込みリクエストを許可するかどうかの決定の際に、スケジューラ１００２によって考慮に入れられるように、バックエンドパイプライン状態フィードバック１０１２が、スケジューラ１００２に提供される。一部の実施形態では、もし、バックエンドパイプライン１００８が、図に示された例のように満杯であるならば、スケジューラ１００２は、フロントエンドパイプラインの中に次の書き込みリクエストを受け入れるだけの十分な空きスペース（例えば、１０１４）がたとえあったとしても、フロントエンドパイプライン１００４への次の書き込みリクエストの許可を待機してよい。
【００５５】
図１１は、バックエンド書き込みキュー状態に基づいてフロントエンド書き込みキューへの許可を調整するためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図１１のプロセスは、図１０のスケジューラ１００２などのスケジューラによって実行されてよい。図に示された例では、ＮＶＲＡＭ（又はその他のフロントエンドストレージ）からＳＳＤ／フラッシュ（又はその他のバックエンドストレージ）への書き込みのバックエンドパイプラインが監視される（１１０２）。もし、次の書き込みリクエストが、ＮＶＲＡＭへの書き込みのためにフロントエンドパイプラインに追加される準備ができた（例えば、次にスケジュールされているキューが、待機中の書き込みリクエストを有する）ならば（１１０４）、フロントエンド書き込みパイプライン及びバックエンド書き込みパイプラインの両方に現時点で空きがあるかどうかが決定される（１１０６）。もし、空きがないならば（１１０６）、プロセスは、フロントエンド書き込みパイプライン及びバックエンド書き込みパイプラインの両方に空きができるまで待機する（１１０７）。もし、フロントエンド書き込みパイプライン及びバックエンド書き込みパイプラインの両方に空きがあるならば（１１０６）、書き込みリクエストは、フロントエンドパイプラインへ許可される（１１０８）。プロセスは、例えばシステムがメインテナンスのためにオフラインにされるなど終わりになるまで続く（１１１０）。
【００５６】
様々な実施形態では、ストレージシステムリソースが、例えば、コンシューマ（例えばＶＭ）がＱｏＳパラメータセットを有するかどうか、並びにもし有するならばそれぞれどのパラメータであり及びどの値であるかに基づいて、異なるコンシューマカテゴリに割り当てられてよい。また、一部の実施形態では、ストレージシステムリソースのうちの幾らかの割合が、ガベージコレクション及びその他の内部プロセスなどの、内部ファイルシステムによる使用に割り当てられてよい。一部の実施形態では、ストレージシステムに格納されたファイルの全部又は一部が関連付けられているそれぞれのＶＭに関連付けられた、もし該当するならばＱｏＳパラメータなどの、ストレージシステムが利用できる情報に基づいて、少なくとも一部にはプログラムによって、割り当て及び／又はデフォルト割り当てが決定及び／又は設定されてよい。
【００５７】
図１２は、プログラムによって決定された割り当てにしたがってストレージリソースの使用を許すためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図１２のプロセスは、図１のストレージシステム１０８などの仮想マシン認識ストレージシステムによって実行されてよい。図に示された例では、ストレージシステムの、複数のリソースコンシューマカテゴリの各々について、そのリソースコンシューマカテゴリに割り当てるための対応する割り当てられたストレージシステムリソース割合が決定される（１２０２）。ストレージシステムリソースは、各リソースコンシューマが関連付けられているカテゴリに、並びに同じ及び／若しくはその他のカテゴリのリソースコンシューマによって所定の時点で使用されているストレージシステムリソースのそれぞれの割合に、少なくとも部分的に基づいて実行時に動的に決定されことにしたがって、リソースコンシューマによって使用されることを許可される（１２０４）。
【００５８】
様々な実施形態では、ストレージリソースは、異なるＶＭカテゴリなどの外部コンシューマと、内部ファイルシステム動作との間で、プログラムによって割り当てられてよい。一部の実施形態では、内部動作は、ストレージシステムリソースの割り当てにおいてＶＭと同じに扱われてよく、このような「内部」ＶＭは、実際のＶＭと同じ又は同様な方式でリソースを割り当てられてよい。このような内部動作の非限定的な例として、以下が挙げられる。
・ログ構造ファイルシステムのためのガベージコレクション
・ホットデータをフラッシュの中に維持してコールドデータをディスクへ撤退させるための、ハイブリッドファイルシステムにおけるフラッシュエビクション
・ＳＳＤ又はＨＤＤのドライブが機能しないときの、ＲＡＩＤ再構築
・アクセスされたコールドデータをＨＤＤからＳＳＤに移すことを伴う、ハイブリッドファイルシステムにおける読み出しキャッシング
・データ保護のための、ＶＭごとの複製
【００５９】
様々な実施形態では、ストレージシステムリソースが、１つ以上のＱｏＳパラメータタイプからなる異なる一式をそれぞれ関連付けられた複数のＶＭカテゴリにわたってプログラムによって割り当てられてよい。例えば、一部の実施形態では、最小及び最大の正規化ＩＯＰＳに関してＶＭごとのストレージＱｏＳを設定しつつも、ユーザは、以下の設定のうちの１つ以上から選択を行う柔軟性を有する。
・ＶＭについて、最小ＩＯＰＳ及び最大ＩＯＰＳの両方を設定する
・ＶＭについて、最小ＩＯＰＳのみを設定し、最大ＩＯＰＳを設定しない
・ＶＭについて、最小ＩＯＰＳを設定せず、最大ＩＯＰＳのみを設定する
・ＶＭについて、最小ＩＯＰＳも最大ＩＯＰＳも設定しない
【００６０】
上記の選択肢によって表される柔軟性は、システムにおけるＱｏＳ設定を異種混合にするかもしれず、これは、扱いを難しくなる恐れがある。様々な実施形態では、ストレージシステムリソースの割り当てが、最小ＩＯＰＳ設定を有さないＶＭのリソースが枯渇しないことを保証できるように成される。
【００６１】
一部の実施形態では、ＶＭのリソースを枯渇させないという上記の目標は、以下の表に示された例のように、システムリソースを複数のカテゴリに振り分けることによって達成される。
【表１】
2018517201.tif 000003
【００６２】
図１３は、利用可能なリソースと、様々なストレージシステムリソースコンシューマクラスに関連付けられたそれぞれのＱｏＳパラメータとに基づいてプログラムによってストレージシステムリソースを割り当てるためのプロセスの一実施形態を示したフローチャートである。様々な実施形態では、図１３のプロセスは、上記の表にあるように、ストレージシステムリソースの割り当てをプログラムによって決定するために使用されてよい。図に示された例では、システムリソースの合計が決定される（１３０２）。例えば、ストレージシステムがマテリアルパフォーマンスの低下を伴うことなく扱えるだろう最大正規化ＩＯＰＳが決定されてよい。ストレージシステム容量は、正規化ＩＯＰＳ、スループット（例えばキロバイト単位）、及び／又は合計容量を表し様々なコンシューマカテゴリに割り当てるために利用できると見なされる決定されたトークンの数（若しくは図６に示された例における「シェア」）などの更に抽象的な容量表現で表されてよい。１つ以上のコンシューマカテゴリの各カテゴリの中のリソースコンシューマについて、リソース可用性データ（例えば、最小ＩＯＰＳ及び／又はその他のＱｏＳコミットメント）が受信される（１３０４）。例えば、上記の表に示された例では、「最小ＩＯＰＳを伴うＶＭ」のＶＭに関連付けられたそれぞれの最小ＩＯＰＳ保証が受信されてよい。ストレージシステムリソースは、最小ＩＯＰＳなどのＱｏＳコミットメントを有するもの、そのようなコミットメントを有さないもの（例えば、最小ＩＯＰＳを伴わないＶＭ）、及び内部ファイルシステム動作などのその他のコンシューマなどの、複数のコンシューマカテゴリ間で、プログラムによって割り当てられる（１３０６）。一部の実施形態では、割り当ては、基準値又はデフォルト値から始まって、その値を、各カテゴリの中のリソースコンシューマの数、及び対応する最小ＩＯＰＳコミットメントなどのそれらに関して知られている情報に基づいて、もし必要であれば調整することによって決定されてよい。例えば、上記の表を参照すると、最小ＩＯＰＳを伴うＶＭへの基準／デフォルト割り当ては、４０％であったかもしれないが、その数値は、「最小ＩＯＰＳを伴うＶＭ」の中のＶＭに関わって成されたことを示された特定の最小ＩＯＰＳコミットメント、及びその他のカテゴリの中のコンシューマの数の一方又は両方に基づいて、５０％に調整されているだろう。
【００６３】
図１３を更に参照すると、ひとたび割り当てが決定されると、ストレージシステムは、それぞれのコンシューマからのリクエストを、個々のリソースコンシューマに関して成されたことを示されたそれぞれの可用性コミットメント（例えば、その特定のＶＭについての最小ＩＯＰＳ）と、プログラムによって決定された割り当て（例えば、最小ＩＯＰＳを伴うＶＭによる使用のために割り当てられたリソースの百分率又はそれ以外の形で示された割合）とに少なくとも部分的に基づいて決定されるやり方で、優先順位を付けるように構成される。
【００６４】
様々な実施形態では、ストレージシステムリソースの割り当ては、例えば、或るカテゴリからのコンシューマが別のカテゴリに割り当てられたリソースを、その別のカテゴリからのコンシューマが自身に割り当てられたレベルの又はそのレベルに近いレベルのリソースをリクエストしていない期間中などに使用することを許すなどして、柔軟に適用されてよい。一部の実施形態では、或るカテゴリからのリソースコンシューマが、例えば短期的な需要の急増又は急上昇を扱うために、別のカテゴリに割り当てられたリソースを使用することを許されてよい。
【００６５】
図１４は、ストレージシステムリソース割り当てを柔軟に遂行するためのプロセスの一実施形態を示したフローチャートである。図に示された例では、各リソースコンシューマカテゴリによるストレージシステムリソースの使用が監視される（１４０２）。もし、所定のコンシューマカテゴリ内で、そのカテゴリの中のコンシューマ（例えばＶＭ）からの、サービスを求める次のリクエストが、そのコンシューマカテゴリの中のコンシューマによる使用のために割り当てられたリソースを超えるリソース使用にならない（１４０４）ならば、そのリクエストは、サービスを受ける（１４０６）。もし、或るカテゴリ内で、サービスを求める次のリクエストが、結果として割り当てを超えさせるならば（１４０４）、その他のユーザカテゴリに関連付けられた未使用の容量があるかどうかを決定するために、チェックが実施される（１４０８）。もし、そのような別のカテゴリ内のコンシューマが、そのカテゴリに割り当てられたリソースを完全に使用していないならば（１４０８）、前者のカテゴリの中のコンシューマからのリクエストは、サービスを受けてよく、これは、後者のカテゴリの中のコンシューマによる使用のために割り当てられたが現時点ではそれらのコンシューマによって使用されていないリソースを、前者のカテゴリからのコンシューマが一時的な形で使用することを、実質的に許す。もし、或るカテゴリに割り当てられたリソースが、完全に使用されており（１４０４）、その他のカテゴリに割り当てられた未使用の容量がないならば（１４０８）、リクエストは、サービスを受けるために待機しなければならない（１４１２、１４１４）。一部の実施形態では、或るカテゴリに割り当てられた未使用の容量は、例えば、もし、そのカテゴリの中のリクエストが急激に増えるなどしても、そのカテゴリ内のリクエストへのサービス提供にリソースが利用可能であることを保証するために、別のカテゴリの中のコンシューマからのリクエストへのサービス提供には、現時点で未使用である容量の５０％までなど何らかの限界までしか使用されなくてよい。
【００６６】
様々な実施形態では、本書で開示されるようにリソースを割り当てること、及び次いで、そのような割り当てを本書で開示されるように柔軟に遂行することが、リソースが枯渇するリソースコンシューマカテゴリがないことを保証しつつもストレージシステムリソースが最大限に利用されることを可能にするだろう。
【００６７】
図１５は、ストレージシステムリソースの割り当てを遂行するように構成されているストレージシステムスケジューラの一実施形態を示したブロック図である。図に示された例では、スケジューラ１５０２は、例えば上述のような、ＶＭ別の固有な読み出しリクエストキュー及び／又は書き込みリクエストキューなどのリクエストキュー１５０４の中のリクエストを、対応するリクエストパイプライン１５０６への追加のためにスケジュールするように構成される。また、この例では、スケジュール１５０２は、ファイルシステム及び／又はその他の内部動作１５０８などの内部コンシューマによるストレージシステムリソースへのアクセスを調整するように構成される。一部の実施形態では、ファイルシステムは、内部ファイルシステム動作を実施する前に、スケジューラ１５０２からリソースをリクエストする。図に示された例では、外部コンシューマ（例えばＶＭ）リクエスト（例えば読み出しや書き込み）パイプライン１５０６は、ストレージシステムにおける動的リソース割り当ての現状態を反映した現サイズ１５１０を有する。例えば、任意の所定の時点において、サイズ１５１０は、ストレージシステムのリソース全体、リクエストキュー１５０４に関連付けられたサイズ、現深さ、数、及び／又はパフォーマンスコミットメント、並びに内部コンシューマなどのその他のコンシューマカテゴリによる、そのカテゴリによる使用のために割り当てられたリソースの現利用程度のうちの１つ以上に基づいて決定されてよい。例えば、図に示された例では、ストレージシステムリソースの一部分１５１２が、内部動作１５０８による使用のために割り当てられているが、図に示された例では、それらのリソースのかなりの部分が、（破線の矩形として示された空きスロットによって記されるように、）使用されていない。様々な実施形態では、もし、外部リクエストパイプライン１５０６が満杯になると、内部動作１５０８に割り当てられたが現時点でそのような動作のために使用されていないリソースが、外部ユーザ（例えばＶＭ）からの更なるリクエストにサービスを提供するための一時的な使用のために動的に解放されて、外部リクエストパイプライン１５０６のサイズ１５１０を（矢印１５１４によって記されるように）一時的に効果的に増大させてよい。一部の実施形態では、もし、内部動作を実施するためのリソースを求めるリクエストが増加したならば、スケジューラは、そのような内部動作による使用に利用可能な割り当てられたリソースレベルを取り戻すために、外部リクエストパイプライン１５０６のサイズを例えばそのパイプラインの中のリクエストがサービスを受けている間は更なるリクエストを追加しないなどによって削ってよい。
【００６８】
様々な実施形態では、本書で開示された技術は、ＶＭ認識ストレージシステムによってネイティブに遂行される、ＶＭごとのサービス品質の保証及び／若しくは制限、異なるリクエストサイズなどの非類似の属性を有するＶＭにわたってＶＭごとに成される、より正確で且つ直感的なパフォーマンスの統計、報告、及び／若しくは可視化、異質なリソースコンシューマカテゴリ間におけるリソースの割り当てに少なくとも部分的に基づいて、一部の実施形態では柔軟に、ストレージシステムリソースへのアクセスを許すこと、並びにそのような割り当てをプログラムによって決定すること、のうちの１つ以上を提供するために使用されてよい。
【００６９】
以上の実施形態は、理解を明瞭にする目的で幾らか詳細に説明されてきたが、本発明は、提供された詳細に限定されない。本発明を実現するためには、多くの代替的手法がある。開示された実施形態は、例示的であり、限定的ではない。
【図１】
2018517201.tif 000004
【図２】
2018517201.tif 000005
【図３Ａ】
2018517201.tif 000006
【図３Ｂ】
2018517201.tif 000007
【図３Ｃ】
2018517201.tif 000008
【図４】
2018517201.tif 000009
【図５】
2018517201.tif 000010
【図６】
2018517201.tif 000011
【図７】
2018517201.tif 000012
【図８】
2018517201.tif 000013
【図９】
2018517201.tif 000014
【図１０】
2018517201.tif 000015
【図１１】
2018517201.tif 000016
【図１２】
2018517201.tif 000017
【図１３】
2018517201.tif 000018
【図１４】
2018517201.tif 000019
【図１５】
2018517201.tif 000020
【国際調査報告】
2018517201.tif 000021