特開 2024-154303 ＡＰＩ実行制御システム、ＡＰＩ実行制御方法及びＡＰＩ実行制御プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024154303

(43)【公開日】2024-10-30

(54)【発明の名称】ＡＰＩ実行制御システム、ＡＰＩ実行制御方法及びＡＰＩ実行制御プログラム

(51)【国際特許分類】

   G06F 9/48 20060101AFI20241023BHJP

【ＦＩ】

G06F9/48 300B

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023068071

(22)【出願日】2023-04-18

(71)【出願人】

【識別番号】524132520

【氏名又は名称】日立ヴァンタラ株式会社

(74)【代理人】

【識別番号】110001689

【氏名又は名称】青稜弁理士法人

(72)【発明者】

【氏名】野村 和正

(57)【要約】

【課題】
ユーザ操作を基準としたＱｏＳを制御するＡＰＩ実行制御システムを提供する。
【解決手段】
ユーザから連続する複数のＡＰＩ実行要求を受け付けるＡＰＩ受付部と、受付けた連続する複数のＡＰＩ実行要求パターンを検出し、検出した連続する複数のＡＰＩ実行要求パターンをＡＰＩ群管理テーブルへ登録するテーブル更新部と、ＡＰＩ受付部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致するかどうかを判定するＡＰＩ実行予測部と、ＡＰＩ実行予測部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致すると判定したとき、次に実行要求を受け付けるＡＰＩの実行優先度を上げるＡＰＩ実行制御部を備えるＡＰＩ実行制御システム。
【選択図】図１

【特許請求の範囲】

【請求項1】

ユーザから連続する複数のＡＰＩ実行要求を受け付けるＡＰＩ受付部と、
受付けた連続する複数のＡＰＩ実行要求パターンを検出し、検出した連続する複数のＡＰＩ実行要求パターンをＡＰＩ群管理テーブルへ登録するテーブル更新部と、
ＡＰＩ受付部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致するかどうかを判定するＡＰＩ実行予測部と、
ＡＰＩ実行予測部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致すると判定したとき、次に実行要求を受け付けるＡＰＩの実行優先度を上げるＡＰＩ実行制御部
を備えるＡＰＩ実行制御システム。

【請求項2】

ユーザとユーザの優先順位を対応付けて登録するＱｏＳ管理テーブルを備え、
ＡＰＩ実行制御部はＱｏＳ管理テーブルを参照し、ＡＰＩ実行要求元のユーザの優先順位に基づいて、実行要求を受付けたＡＰＩの実行優先度を上げる優先度向上方法を変更する請求項１に記載のＡＰＩ実行制御システム。

【請求項3】

前記優先度向上方法は実行優先度を上げるＡＰＩ実行のための処理装置を確保する請求項２に記載のＡＰＩ実行制御システム。

【請求項4】

更にＡＰＩの実行順序を登録するキューを備え、
前記優先度向上方法は実行優先度を上げるＡＰＩのキュー内における実行順序を早める請求項２に記載のＡＰＩ実行制御システム。

【請求項5】

テーブル更新部はユーザから定期的に実行要求を受け付けるＡＰＩのパターンを検出し、検出したＡＰＩのパターンをＡＰＩ群管理テーブルへ登録し、
ＡＰＩ実行制御部はＡＰＩ群管理テーブルへ登録された定期的に実行要求を受け付けるＡＰＩの次回実行予定時刻の予め定められた時刻に、当該ＡＰＩのユーザに対応付けられた優先度に基づく優先度向上方法を実行する請求項２に記載のＡＰＩ実行制御システム。

【請求項6】

テーブル更新部はＡＰＩ群管理テーブルに登録されているパターンのうち予め定められた時間内に実行されていないパターンを削除する請求項２に記載のＡＰＩ実行制御システム。

【請求項7】

ＡＰＩ群管理テーブルは登録されているパターン毎に最終実行日時を示す情報を備え、テーブル更新部はＡＰＩ群管理テーブルに登録されているパターンが実行されたとき、実行されたパターンに対応する最終実行日時を更新する請求項２に記載のＡＰＩ実行制御システム。

【請求項8】

ＡＰＩ受付部がユーザから連続する複数のＡＰＩ実行要求を受け付け、
テーブル更新部が受付けた連続する複数のＡＰＩ実行要求パターンを検出し、検出した連続する複数のＡＰＩ実行要求パターンをＡＰＩ群管理テーブルへ登録し、
ＡＰＩ実行予測部がＡＰＩ受付部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致するかどうかを判定し、
ＡＰＩ実行制御部がＡＰＩ実行予測部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致すると判定したとき、次に実行要求を受け付けるＡＰＩの実行優先度を上げるＡＰＩ実行制御方法。

【請求項9】

ユーザとユーザの優先順位を対応付けて登録するＱｏＳ管理テーブルを備え、
ＡＰＩ実行制御部がＱｏＳ管理テーブルを参照し、ＡＰＩ実行要求元のユーザの優先順位に基づいて、実行要求を受付けたＡＰＩの実行優先度を上げる優先度向上方法を変更する請求項８に記載のＡＰＩ実行制御方法。

【請求項10】

コンピューターにユーザから連続する複数のＡＰＩ実行要求を受け付ける手順と、
受付けた連続する複数のＡＰＩ実行要求パターンを検出し、検出した連続する複数のＡＰＩ実行要求パターンをＡＰＩ群管理テーブルへ登録する手順と、
ＡＰＩ受付部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致するかどうかを判定する手順と、
ＡＰＩ実行予測部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致すると判定したとき、次に実行要求を受け付けるＡＰＩの実行優先度を上げる手順を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＡＰＩ実行制御システム、ＡＰＩ実行制御方法及びＡＰＩ実行制御プログラムに関する。

【背景技術】

【0002】

昨今、マルチテナンシ化が進んでおり、ユーザからのストレージＡＰＩ実行頻度は以前よりも高頻度になってきている。また、ストレージリソースに限りがあることから同時実行可能なＡＰＩ数も限られている。その中で重要度の高いＡＰＩを優先処理したいというニーズも強まってきている。さらに、エンドユーザからのストレージ操作をクラウドシステムなどが仲介することで、ある1つのエンドユーザ操作に対して、クラウドシステムがストレージへ数十以上のストレージＡＰＩ（ストレージＡＰＩ群）を発行することも増えてきており、ストレージＡＰＩの実行頻度はさらに多くなってきている。

【0003】

例えば特許文献１にはＡＰＩリクエストの要求者または／および要求元システムを判別して当該ＡＰＩリクエストを認証するＡＰＩメッセージ受付部と、各ＡＰＩリクエストの要求者または／および要求元システムを示す固有の識別子と優先度との組合せを保持する要求元別優先度登録テーブルと、このＡＰＩリクエストの要求者または／および要求元システムに基づき、前記要求元別優先度登録テーブルを参照してＡＰＩリクエストの優先度を判定する優先度判定部と、判定した優先度に応じてＡＰＩリクエストを優先的に処理するか否かを決定する制御対象決定部とを備えるシステムが開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１７－１６４０８

【発明の概要】

【発明が解決しようとする課題】

【0005】

エンドユーザ操作と、実行されるストレージＡＰＩ数は１対多の関係にある。個々のストレージＡＰＩに対して、優先度に応じてキューイングする方法が従来技術としてあるが、エンドユーザ操作の延長で実行される複数のストレージＡＰＩ群を纏めて管理し、ＱｏＳ制御する方法は検討されていない。つまり、個々のストレージＡＰＩを基準としたＱｏＳ制御は存在するが、エンドユーザ操作を基準としたＱｏＳを提供できるようなシステムは検討されていない。

【課題を解決するための手段】

【0006】

本発明の課題はユーザから連続する複数のＡＰＩ実行要求を受け付けるＡＰＩ受付部と、受付けた連続する複数のＡＰＩ実行要求パターンを検出し、検出した連続する複数のＡＰＩ実行要求パターンをＡＰＩ群管理テーブルへ登録するテーブル更新部と、ＡＰＩ受付部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致するかどうかを判定するＡＰＩ実行予測部と、ＡＰＩ実行予測部が受付けたＡＰＩ実行要求がＡＰＩ群管理テーブルに登録されているパターンと一致すると判定したとき、次に実行要求を受け付けるＡＰＩの実行優先度を上げるＡＰＩ実行制御部を備えるＡＰＩ実行制御システムにより達成される。

【発明の効果】

【0007】

本発明によれば、ＡＰＩ実行システムのＱＯＳを制御することができる。上記した以外の課題、構成及び効果は以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0008】

【図1】本発明の実施例におけるシステム概要を説明する図

【図2】本発明の実施例におけるストレージ装置のブロック図の例

【図3】本発明の実施例におけるＱｏＳ管理テーブルの例

【図4】本発明の実施例におけるＡＰＩ群管理テーブルの例

【図5】本発明の実施例におけるＡＰＩ群操作間隔管理テーブルの例

【図6】本発明の実施例におけるＡＰＩキャッシュテーブルの例

【図7】本発明の実施例におけるＡＰＩ群管理テーブル更新処理のフローチャートの例

【図8】本発明の実施例におけるＡＰＩ群管理テーブルからのＡＰＩ群削除処理のフローチャートの例

【図9】本発明の実施例におけるＡＰＩ群操作間隔管理テーブル更新処理のフローチャートの例

【図10】本発明の実施例におけるＡＰＩ実行予測処理のフローチャートの例

【図11】本発明の実施例におけるリソース割当処理のフローチャートの例

【図12】本発明の実施例におけるキュー制御処理を説明する図

【図13】本発明の実施例における実行ＡＰＩキュー処理のフローチャートの例

【図14】本発明の実施例における定期的なリクエストに対するリソース割当処理のフローチャートの例

【発明を実施するための形態】

【0009】

以下、本発明の実施例を、図面を用いて説明する。なお、実施例を説明するための各図において、同一の構成要素にはなるべく同一の名称、符号を付して、その繰り返しの説明を省略する。

【0010】

本発明は後述する実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例および同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。

【0011】

また、実指例で説明する処理部は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することによりソフトウェアで実現してもよい。

【0012】

実施例で説明するテーブル、領域等はデータベース（ＤＢ）であっても良く主記憶メモリに記憶されたデータであっても良い。

【実施例0013】

図１は本発明の実施例におけるシステム概要を説明する図である。ユーザ４からクラウドシステム１やストレージ管理ソフト２へコマンドが入力される。クラウドシステム１には複数のホスト６が設けられている。クラウドシステム１やストレージ管理ソフト２へ入力されたコマンドは複数のＡＰＩ（ＡＰｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）に変換されてストレージ装置３へネットワーク５経由で送信される。ＡＰＩはストレージ装置を操作するコマンドやプログラムの様な働きをするものである。

【0014】

ストレージ装置にはＡＰＩ処理制御装置７と記憶部８が含まれており、ＡＰＩ処理制御装置７はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９、メモリ１１、外部記憶装置１０、入出力部１２等を備える計算機で構成される。記憶部８は複数の記憶装置１４で構成されＡＰＩ処理制御装置７と接続され、ＡＰＩ処理制御装置７からＡＰＩを受け取ってユーザ４の指示した処理が実行される。

【0015】

図２は図１でハードウェア構成を説明したＡＰＩ処理制御装置７のソフトウェアモジュールと外部記憶装置１０に格納されてソフトウェアモジュールからアクセスされる各種テーブルを説明する。

【0016】

ＡＰＩ処理制御装置７にはクラウドシステム１やストレージ管理ソフトからＡＰＩを受け付けるＡＰＩ受付部２１とＡＰＩ受付部２１が受付けたＡＰＩの実行を制御するＡＰＩ実行制御部２２が含まれる。

【0017】

ＡＰＩ受付部２１にはＡＰＩを発行した発行元であるユーザの情報を取得するユーザ情報取得部２４とＡＰＩの情報自体を取得するＡＰＩ情報取得部２５を備える。

【0018】

ＡＰＩ実行制御部２２には各種テーブルを更新するテーブル更新部３０、ＡＰＩの実行を予測するＡＰＩ実行予測部３１、ＡＰＩを実行するためのＣＰＵ等のリソースを割り当てるリソース割当制御部３２、ストレージの情報を取得するストレージ情報取得部３３、ＡＰＩの処理を記憶部８へ要求するＡＰＩ処理要求部３４を備える。

【0019】

ＡＰＩ処理要求部３４には実行中のＡＰＩ群を格納するＡＰＩキャッシュ３５と実行するＡＰＩの待ち行列を核のする実行ＡＰＩキュー３６を備える。

【0020】

さらに、外部記憶装置１０にはＱｏＳ管理テーブル２６、ＡＰＩ群管理テーブル２７、ＡＰＩ実行ログ２９、ＡＰＩ群操作間隔管理テーブル２８が格納される。

【0021】

図３は本発明の実施例におけるＱｏＳ管理テーブルの例である。ＡＰＩを実行するエンドユーザ４１、ＱｏＳの優先順位を示すＱｏＳタイプ４２、ＱｏＳタイプごとの優先内容を示すＱｏＳ内容４３を対応付けて記憶する。

【0022】

この例ではエンドユーザ４１はＡ、Ｂ、Ｃの３種類のユーザ４とストレージ管理ソフト、クラウドシステムのシステムエンドユーザが定義されている。ＱｏＳタイプ４２はＧｏｌｄ、Ｓｉｌｖｅｒ、Ｂｒｏｎｚｅの３段階のユーザ優先順位とＳｐｅｃｉａｌのシステム優先順位がある。優先順位はＢｒｏｎｚｅ、Ｓｉｌｖｅｒ、Ｇｏｌｄ、Ｓｐｅｃｉａｌの順に高くなる。

【0023】

ＱｏＳ内容はＱｏＳタイプＢｒｏｎｚｅは最も優先順位が低いため優先順位の制御は行わないことを示す。ＱｏＳタイプＳｉｌｖｅｒでは優先的にリクエストを処理するために実行ＡＰＩキュー３６の中における実行順序を早めるよう制御する。ＱｏＳタイプＧｏｌｄではさらにＡＰＩの実行優先度を上げるため、実行ＡＰＩキュー３６の制御だけでなくＡＰＩ実行に必要なリソースの確保も行う。ＱｏＳタイプＳｐｅｃｉａｌは最も優先順位が高いため即実行が可能なように実行ＡＰＩキュー３６の制御とリソースの確保を行う。

【0024】

ユーザのＱｏＳタイプＳｉｌｖｅｒ，Ｇｏｌｄでどの程度の実行ＡＰＩキュー３６の制御、リソースの確保を行うかは適用するシステム依存である。したがって実行ＡＰＩキュー３６の制御においてどの程度ＡＰＩ実行順序を早めるか、リソース確保で確保するＣＰＵの種類、確保する時間等が変わってくる。

【0025】

また、優先順位を下げるＱｏＳタイプを用意し、ストレージシステムの負荷が下がったときに実行されるようにしても良い。
図４は本発明の実施例におけるＡＰＩ群管理テーブルの例である。実行されるＡＰＩ群４５、ＡＰＩ群の実行ユーザであるＡＰＩ実行ユーザ４６、エンドユーザ４７、最終実行日時４８を対応付けて格納している。

【0026】

１行目のＧＥＴ／ｌｄｅｖｓ、ＰＯＳＴ／ｌｄｅｖｓは新たにボリュームを作成するＡＰＩ群であり、クラウドシステム、ストレージ管理ソフトの両方から実行されている。エンドユーザもＡ、Ｂ、Ｃの３名から実行された記録があり、最終実行日時は２０２３／２／１３ ８：００：００である。

【0027】

同様に２行目はサーバとボリュームに接続するマッピング処理、３行目はスナップショットを取得するバックアップ処理、４行目はパフォーマンス情報、構成情報を取得する処理である。エンドユーザは人ではなく、スクリプトやツールの場合もある。
図５は本発明の実施例におけるＡＰＩ群操作間隔管理テーブルの例である。図４のＡＰＩ群管理テーブルに実行間隔５４と次回実行予測時刻である次回実行時間５５の情報が追加されている。
図６は本発明の実施例におけるＡＰＩキャッシュテーブルの例である。このテーブルには実行中のＡＰＩ群と最近実行されたＡＰＩ群の情報を格納するテーブルである。例えば過去１秒以内に実行されたＡＰＩ群の情報であり、処理が完了したＡＰＩ群の情報も含まれる。
図７は本発明の実施例におけるＡＰＩ群管理テーブル更新処理のフローチャートの例である。ＡＰＩ受付部２１でＡＰＩ実行のリクエストを受け付ける（Ｓ７１）。次にユーザ情報取得部２４が受付けたリクエストのＡＰＩ実行ユーザ４６、エンドユーザ４７等のユーザ情報を取得しＡＰＩ群管理テーブル２７に格納する（Ｓ７２）。一定時間以内に同一ユーザからのＡＰＩ実行リクエストがあれば（Ｓ７３）ＡＰＩ群の実行要求である可能性があるため、ＡＰＩキャッシュ３５へ当該ＡＰＩを登録する（Ｓ７４）。

【0028】

一定時間内に同じユーザからのリクエストが無ければ、つまり当該ユーザからのＡＰＩ群実行リクエストが終了したと判断したときはＡＰＩ群管理テーブル２７に当該ユーザから要求のあったＡＰＩ群が登録されているかどうかを判定する（Ｓ７５）。

【0029】

当該ユーザから実行リクエストのあったＡＰＩ群がＡＰＩ群管理テーブル２７に登録されていたときは、ＡＰＩ群管理テーブル２７の最終実行日時４８を更新する（Ｓ７６）。

【0030】

当該ユーザから実行リクエストのあったＡＰＩ群がＡＰＩ群管理テーブル２７に登録されていなかったときは、新たに実行リクエストのあったＡＰＩ群をＡＰＩ群管理テーブル２７へ追加する（Ｓ７７）。

【0031】

図８は本発明の実施例におけるＡＰＩ群管理テーブルからのＡＰＩ群削除処理のフローチャートの例である。ＡＰＩ群管理テーブルに登録されている各ＡＰＩ群の最終実行日時４８を参照する（Ｓ８１）。

【0032】

最終実行日時４８から一定期間実行されていなければ（Ｓ８２）、当該ＡＰＩ群をＡＰＩ群管理テーブルから削除する（Ｓ８３）。実行されていれば当該ＡＰＩ群を保持する。

【0033】

この処理はストレージシステムの用途に依存するが１か月に１度程度ＡＰＩ群削除処理を行えば、ＡＰＩ群管理テーブルが肥大しストレージシステムの処理性能を下げることを回避できる。

【0034】

図９は本発明の実施例におけるＡＰＩ群操作間隔管理テーブル更新処理のフローチャートの例である。ＡＰＩ実行ログ情報を取得し（Ｓ９１）、各ユーザが実行したＡＰＩ群ごとに周期性がないか判定する（Ｓ９２）。周期性があると判定されたとき（Ｓ９３）ＡＰＩ群操作間隔管理テーブル２８に当該ＡＰＩ群を実行間隔５４、次回実行時間５５とともに登録する。また、既にＡＰＩ群操作間隔管理テーブルに登録されているＡＰＩ群であったときは、登録されている実行間隔５４に変化がないかを確認し、変化している場合は実行間隔５４、次回実行時間５５を更新する。周期性が無いと判定されたときは登録しない。

【0035】

ＡＰＩ群操作間隔管理テーブル更新処理はストレージシステムの用途に依存するが１か月に１度程度行えば、最新のストレージ運用方法に即したＡＰＩ実行が可能となる。

【0036】

図１０は本発明の実施例におけるＡＰＩ実行予測処理のフローチャートの例である。ＡＰＩ受付部２１がＡＰＩの実行リクエストを受付け（Ｓ１０１）、ユーザ情報を取得し（Ｓ１０２）、ＡＰＩキャッシュ３５へ追加する（Ｓ１０３）。

【0037】

ＡＰＩ実行予測部３１はＡＰＩ群管理テーブルを参照し、現在実行中のＡＰＩ群が登録されているか判定する（Ｓ１０４）。この判定ではＡＰＩ群に含まれるＡＰＩの並びが完全に一致するかどうかを判定する。現在実行中のＡＰＩ群が登録されていると判定されたとき登録されているＡＰＩ群は後続のＡＰＩを持つか判定する（Ｓ１０５）。後続のＡＰＩを持つ場合、登録されている次のＡＰＩが実行されると予測する（Ｓ１０６）。

【0038】

Ｓ１０４でＡＰＩ群が登録されていないと判断されたとき、複数の登録されているＡＰＩ群候補があり後続のＡＰＩがあるかどうかを判定する（Ｓ１０７）。複数の登録されているＡＰＩ群候補があり後続のＡＰＩがある場合は登録されている次のＡＰＩが実行されると予測する（Ｓ１０６）。

【0039】

図１１は本発明の実施例におけるリソース割当処理のフローチャートの例である。ＡＰＩ実行予測処理にて、次のＡＰＩが実行されると予測されたＡＰＩ群か判定する（Ｓ１１１）。次のＡＰＩが実行されることが無ければ処理を終了する。

【0040】

Ｓ１１１で次のＡＰＩが実行されるＡＰＩ群に複数の可能性がある場合はユーザが同一ユーザかどうかを判定する（Ｓ１１２）。同一ユーザでなければ処理を終了する。同一ユーザの場合はＡＰＩ群を実行しているユーザのＱｏＳ情報を取得し（Ｓ１１３）、ストレージ情報取得部からＭＰＵ（Micro Processor Unit）の稼働情報を取得する（Ｓ１１４）。

【0041】

当該ＡＰＩ群の処理が完了するまで、ユーザのＱｏＳタイプに基づくＱｏＳレベルを設定し、ＭＰＵを確保する。ただし、当該ＡＰＩ群よりもＱｏＳレベルが高いＡＰＩ群が発行された場合、確保したプロセッサを奪われる可能性はある。ＭＰＵだけでなくメモリやボリュームについても確保しても良い。

【0042】

そして、当該ＡＰＩ群の処理が完了したときに、確保したＭＰＵ等のリソースを開放する。

【0043】

図１２は本発明の実施例におけるキュー制御処理を説明する図である。ストレージ装置３のＡＰＩ処理要求部３４には実行ＡＰＩキュー３６を備える。実行ＡＰＩキューに実行リクエストを受付けたＡＰＩが登録される。この例ではＢ－２、Ｃ－２というＡＰＩが登録されており実行ＡＰＩキュー３６に登録されていたＡＰＩのＢ－１とＣ－１が各々ＭＰＵ２とＭＰＵ３で実行されている。ＭＰＵ１はＱｏＳタイプがＧｏｌｄであるユーザＡのＡＰＩを実行するために確保されている。

【0044】

この状態でエンドユーザＡからのＡＰＩであるＡ－２の実行リクエストを受付けた場合Ａ－２は実行ＡＰＩキューの先頭へ登録される。そしてＧｏｌｄ用に確保されているＭＰＵ１ですぐさま実行される。

【0045】

このような制御を行うことにより優先度の高いＡＰＩを実行することが可能となる。ただしＧｏｌｄのエンドユーザＡからのＡＰＩの実行リクエストを複数同じ時間帯に受付けた場合はエンドユーザごとに確保可能なＭＰＵは１つであるため、新規に受付けた別のリクエストに確保しておいたＭＰＵが割り当てられる可能性がある。

【0046】

図１３は本発明の実施例における実行ＡＰＩキュー処理のフローチャートの例である。ＡＰＩ受付部２１がＡＰＩの実行リクエストを受付け（Ｓ１３１）、ユーザ情報を取得し（Ｓ１３２）、ＡＰＩ群としてＡＰＩ群管理テーブル２７に登録されている次のＡＰＩの実行リクエストか判定する（Ｓ１３３）。登録されている次のＡＰＩの実行リクエストでない場合は実行ＡＰＩキュー３６の末尾にＡＰＩを登録する（Ｓ１３５）。

【0047】

登録されている次のＡＰＩ（ＹＥＳ）の場合は当該ユーザのＱｏＳタイプよりも優先度の高いＡＰＩがキューに登録されていないか判定する（Ｓ１３４）。

【0048】

優先度の高いＡＰＩがキューに登録されていない（ＹＥＳ）場合は、実行ＡＰＩキュー３６の最も最初にＡＰＩが実行される先頭に登録する。優先度の高いＡＰＩが実行ＡＰＩキュー３６に登録されている（ＮＯ）場合は、実行ＡＰＩキュー３６の該当ＡＰＩより優先度の高い処理の次にＡＰＩを登録する。

【0049】

図１４は本発明の実施例における定期的なリクエストに対するリソース割当処理のフローチャートの例である。ＡＰＩ群操作間隔管理テーブルに次回実行時刻が近いＡＰＩ群があるか判定する（Ｓ１４１）。近いかどうかの判定はストレージシステムの運用に依存するが通常は１秒から数秒の時間を設定する。

【0050】

次回実行時刻が近いＡＰＩ群があったとき、当該ＡＰＩ群の実行が完了するまで、ＱｏＳタイプに応じてＭＰＵ１２３を当該ＡＰＩ群実行用に確保する（Ｓ１４２）。当該ＡＰＩ群の実行が完了したとき、確保したＭＰＵ１２３を解放する（Ｓ１４３）。

【0051】

この例ではＭＰＵを例に説明したが、メモリ、ディスクボリュームの確保も必要に応じて制御する。

【符号の説明】

【0052】

１ クラウドシステム、２ ストレージ管理ソフト、３ ストレージ装置、４ ユーザ、６ ホスト、７ ＡＰＩ処理制御装置、８ 記憶部、９ ＣＰＵ、１０ 外部記憶装置、１１ メモリ、１２ 入出力部、１４ 記憶装置、２１ ＡＰＩ受付部、２２ ＡＰI実行制御部、２４ ユーザ情報取得部、２５ ＡＰＩ情報取得部、２６ ＱｏＳ管理テーブル、２７ ＡＰＩ群管理テーブル、２８ ＡＰＩ群操作間隔管理テーブル、２９ＡＰＩ実行ログ、３０ テーブル更新部、３１ ＡＰＩ実行予測部、３２ リソース割当制御部、３３ ストレージ情報取得部、３４ ＡＰＩ処理要求部、３５ ＡＰＩキャッシュ、３６ 実行ＡＰＩキュー、１２３ ＭＰＵ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【手続補正書】

【提出日】2024-02-21

【手続補正1】

【補正対象書類名】明細書

【補正対象項目名】００１１

【補正方法】変更

【補正の内容】

【0011】

また、実施例で説明する処理部は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することによりソフトウェアで実現してもよい。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】００１３

【補正方法】変更

【補正の内容】

【0013】

図１は本発明の実施例におけるシステム概要を説明する図である。ユーザ４からクラウドシステム１やストレージ管理ソフト２へコマンドが入力される。クラウドシステム１には複数のホスト６が設けられている。クラウドシステム１やストレージ管理ソフト２へ入力されたコマンドは複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）に変換されてストレージ装置３へネットワーク５経由で送信される。ＡＰＩはストレージ装置を操作するコマンドやプログラムの様な働きをするものである。

【手続補正3】

【補正対象書類名】図面

【補正対象項目名】図４

【補正方法】変更

【補正の内容】

【図4】

【手続補正4】

【補正対象書類名】図面

【補正対象項目名】図６

【補正方法】変更

【補正の内容】

【図6】

【手続補正5】

【補正対象書類名】図面

【補正対象項目名】図７

【補正方法】変更

【補正の内容】

【図7】