JP6757708B2 - 情報処理装置及び構成要素の管理方法 - Google Patents

Description

本発明は、管理機能を有する情報処理装置に関する。

近年、原価低減などの理由により、ＩＴリソース（ストレージ装置やサーバ装置などの情報処理装置）を管理サーバが無い場合でも管理することが要求されている。このため、管理サーバが無い環境においても管理を実施可能なＩＴリソースの開発が行われており、従来の管理サーバ内の管理プログラムがＩＴリソース内に組み込まれ、ＩＴリソース自体と管理プログラムが計算資源（ＣＰＵ／Ｍｅｍｏｒｙなど）を共有する。このため、管理プログラムは、限られた資源で効率的にリクエストを処理する必要がある。

限られた資源を用いて制御を行う技術としては、特許文献１が知られている。特許文献１には、複数のデータ転送装置からデータ受信装置へデータを転送する計算機システムで、ネットワークの負荷に応じてデータの転送順序を入れ替える技術が開示されている。

特開２０１２−１４７１０７号公報

ＩＴリソースとしてのストレージ装置に上記従来例を適用すると、管理プログラムとストレージ装置の制御プログラムが計算機資源を共有する。ストレージ装置内ではストレージ装置を管理するためのリクエスト（例えば、構成変更リクエスト）と、ストレージ装置を利用するためのリクエスト（例えば、Ｉ／Ｏリクエスト）を受け付けて、管理プログラムと制御プログラムがそれぞれの各リクエストを処理する。

Ｉ／Ｏリクエストの処理負荷が高い状態では、管理用のリクエストのうち負荷が高い処理を実施できない。この場合、負荷の低い管理用のリクエストを実施することができる。しかしながら、ＩＴリソースの構成要素は依存関係を持っているため、各構成要素に対するリクエストの処理に必要な計算資源のみを考慮して処理の順序を入れ替えた場合、リクエストに失敗することがあった。

そこで本発明は、上記問題点に鑑みてなされたもので、構成要素の依存関係に応じて管理用のリクエストを処理する順序を柔軟に制御することを目的とする。

本発明は、プロセッサとメモリを含む計算機資源と、制御対象の構成要素を有する情報処理装置であって、データ要求を受け付けて前記構成要素にアクセスするデータ制御部と、管理要求を受け付けて前記構成要素の管理を行う管理部と、前記構成要素の種別毎に予め設定されて、構成要素の識別子と、当該識別子に関連する関連構成要素種別と、当該識別子に関連する構成要素の関連構成要素識別子と、を予め設定した構成要素情報と、前記管理要求の種別と、制御対象の構成要素の種別と、当該管理要求を実行する際の実行負荷と、を予め設定した負荷情報と、前記管理部が付与したリクエスト識別子と、前記管理要求の構成要素の種別と、前記管理要求の構成要素の識別子と、前記管理要求の構成要素の当該種別及び識別子に関連する関連構成要素種別と、当該種別及び識別子に関連する関連構成要素識別子と、当該管理要求よりも先行して実施すべき管理要求の前記リクエスト識別子を含む処理待ち識別子と、当該管理要求を実行する際の前記実行負荷と、をレコード単位で格納するリクエスト情報と、を有し、前記管理部は、前記計算機資源を前記データ制御部と共有し、前記管理要求の種別と、制御対象の構成要素の種別と、制御対象の構成要素の識別子を含む前記管理要求を受け付けて、前記構成要素情報から前記制御対象の構成要素の種別と制御対象の構成要素の識別子に対応する前記関連構成要素種別と前記関連構成要素識別子を取得し、当該管理要求を実行する際の実行負荷を前記負荷情報から取得し、前記管理要求で指定された制御対象の構成要素の種別と制御対象の構成要素の識別子を含むレコードをリクエスト情報で検索し、当該構成要素の種別と当該構成要素の識別子を含むレコードが存在する場合には、当該レコードのリクエスト識別子を処理待ち識別子として取得し、前記構成要素情報から取得されて前記管理要求で制御対象となる構成要素の関連構成要素種別と前記関連構成要素識別子が、一致するレコードをリクエスト情報から検索し、当該一致するリクエスト情報のレコードのリクエスト識別子を処理待ち識別子として取得し、前記受け付けた管理要求の構成要素に関連する関連構成要素種別と関連構成要素識別子と、当該管理要求の実行負荷と、前記処理待ち識別子と、前記管理要求の種別と、制御対象の構成要素の種別と、制御対象の構成要素の識別子を新たなレコードとして前記リクエスト情報に追加し、使用状況として計算機資源の負荷を検出し、当該負荷と所定の第１の閾値から許容負荷を算出し、前記リクエスト情報のうち、前記処理待ち識別子が無く、かつ、前記実行負荷が前記許容負荷以内のレコードに対応する前記管理要求を実行し、当該リクエスト識別子に対応する前記リクエスト情報のレコードを削除し、他のリクエスト情報のレコードに当該リクエスト識別子が前記処理待ち識別子に含まれる場合には、当該レコードの処理待ち識別子から当該リクエスト識別子を削除して、前記管理要求の実行順序を動的に変更する。

したがって、本発明は、情報処理装置の構成要素に対して複数の管理要求が発行された場合、データ制御部の実行に影響を与えることなく、かつ、構成要素の依存関係に応じて管理要求を処理する順序を柔軟に制御することが可能となる。

本発明の実施例を示し、ストレージ装置の構成の一例を示すブロック図である。 本発明の実施例を示し、リクエストテーブルの一例を示す図である。 本発明の実施例を示し、オブジェクト種別がプールの構成情報テーブルの一例を示す図である。 本発明の実施例を示し、オブジェクト種別がボリュームの構成情報テーブルの一例を示す図である。 本発明の実施例を示し、負荷テーブルの一例を示す図である。 本発明の実施例を示し、管理ソフトウェアのリクエスト登録プログラムで行われるリクエストの受け付け処理の一例を示すフローチャートである。 本発明の実施例を示し、管理ソフトウェアのリクエスト処理プログラムで行われるリクエスト決定処理の一例を示すフローチャートである。 本発明の実施例を示し、リクエスト決定処理の詳細を示すフローチャートである。 本発明の実施例を示し、負荷と時間の関係を示すグラフである。 本発明の実施例を示し、１回目の処理におけるリクエストテーブルの一例を示す図である。 本発明の実施例を示し、１回目の処理が完了した後のリクエストテーブルの一例を示す図である。 本発明の実施例を示し、２回目の処理におけるリクエストテーブルの一例を示す図である。 本発明の実施例を示し、２回目の処理が完了した後のリクエストテーブルの一例を示す図である。 本発明の実施例を示し、３回目の処理におけるリクエストテーブルの一例を示す図である。 本発明の実施例を示し、３回目の処理が完了した後のリクエストテーブルの一例を示す図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

図１は、本発明の実施例を示し、ストレージ装置の一例を示すブロック図である。ストレージ装置１は、本発明を適用したＩＴリソース（または情報処理装置）の一例である。ストレージ装置１は、１以上の管理クライアント２０からの管理要求（以下、リクエスト）に基づいて、ストレージデバイス５の記憶領域にプール５１を設定し、プール５１にボリューム５２を割り当てて、ボリューム５２を管理クライアント２０や図示しないクライアントに提供する。

ストレージ装置１は、計算機資源２として、プロセッサ３と、メモリ４と、ストレージデバイス５と、ネットワーク９を介して１以上の管理クライアント２０と通信を行うインタフェース６を含む。

メモリ４には、ストレージデバイス５を管理する管理ソフトウェア８と、ストレージデバイス５に対するＩ／Ｏ（読み書き）処理を制御する制御ソフトウェア７がロードされ、プロセッサ３によって実行される。管理ソフトウェア８と制御ソフトウェア７は、計算機資源２を共有する。ストレージデバイス５は、複数のドライブ（または記憶媒体）を含み、ＲＡＩＤグループなどの記憶領域を提供する。

管理ソフトウェア（管理部）８は、管理クライアント２０からのリクエストに応じて、ストレージデバイス５の記憶領域のプール５１への割り当てや、プール５１の記憶領域のボリューム５２への割り当てや、記憶領域とポート（図示省略）のマッピング等、制御対象となる構成要素（ストレージデバイス５）の管理を実施する。なお、管理ソフトウェア８は、記憶領域を提供するＲＡＩＤグループの生成や変更などについても実施することができる。

制御ソフトウェア７（データ制御部）は、クライアント（図示省略）からのデータ要求（読み出し要求や書き込み要求）を受け付けると、制御対象の構成要素であるストレージデバイス５にアクセスしてクライアントに応答する。なお、制御ソフトウェア７は、ストレージ制御プログラムや制御用のテーブルを含み、公知ないし周知の技術を適用すれば良いので、本実施例では詳述しない。

管理ソフトウェア８は、管理クライアント２０からのリクエストを受け付けるリクエスト登録プログラム１１と、登録されたリクエストの実行を制御するリクエスト処理プログラム１２と、計算機資源２の負荷を取得する計算機資源情報取得プログラム１３と、各プログラムが利用するテーブルを含む。

プロセッサ３は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ３は、リクエスト登録プログラムに従って処理することでリクエスト登録部として機能し、あるいは、リクエスト処理プログラムに従って処理することでリクエスト処理部として機能する。他のプログラムについても同様である。さらに、プロセッサ３は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。なお、リクエスト登録プログラム１１やリクエスト処理プログラム１２等を含む管理ソフトウェア８が、管理部として機能しても良い。

各プログラムが利用するテーブルとしては、受け付けたリクエストを登録するリクエストテーブル１４と、計算機資源２の構成要素の依存関係（または関連性）を予め設定した構成情報テーブル１５と、リクエストが計算機資源２へ与える負荷（負荷の推定値）を予め設定した負荷テーブル１６を含む。

図２は、リクエストテーブル１４の一例を示す図である。リクエストテーブル１４は、リクエスト登録プログラム１１によって生成され、リクエスト処理プログラム１２によって更新されるテーブルである。

リクエストテーブル１４は、番号１４１と、リクエストＩＤ１４２と、リクエスト種別１４３と、オブジェクト種別１４４と、オブジェクトＩＤ１４５と、関連オブジェクト種別１４６と、関連オブジェクトＩＤ１４７と、処理待ちリクエストＩＤ１４８と、負荷１４９と、をひとつのレコードに含む。

番号１４１は、リクエスト登録プログラム１１によって付与される番号で、例えば、シリアル値である。リクエストＩＤ１４２は、リクエスト登録プログラム１１によって付与される識別子で、ストレージ装置１内でユニークな値が設定される。

リクエスト種別１４３は、制御対象（ストレージデバイス５）に対する操作の種類が格納され、例えば、管理クライアント２０が発行したリクエスト内のコマンドなどが含まれる。図示の例では、「Ｆｏｒｍａｔ」や「Ａｔｔａｃｈ」、「Ｉｎｉｔｉａｌｉｚｅ」等の記憶領域に対する操作の種類が格納される。

オブジェクト種別１４４には、操作対象の構成要素の種類（または名称）が格納される。例えば、管理クライアント２０が発行したリクエストに含まれる操作対象としての「ボリューム」や「プール」が、オブジェクト種別１４４に格納される。

オブジェクトＩＤ１４５には、オブジェクト種別１４４で指定された構成要素の種類のうち、操作対象を特定する識別子が格納される。オブジェクトＩＤ１４５には、例えば、リクエスト登録プログラム１１が構成情報テーブル１５から取得したオブジェクトＩＤや、管理クライアント２０が発行したリクエストに含まれる操作対象の識別子が格納される。

関連オブジェクト種別１４６には、操作対象のオブジェクト種別１４４に関係する構成要素の種類（または名称）が格納される。関連オブジェクト種別１４６は、リクエスト登録プログラム１１が構成情報テーブル１５から取得した値が格納される。例えば、オブジェクト種別１４４が「Ｖｏｌｕｍｅ」の場合、当該ボリュームを切り出す元となる「Ｐｏｏｌ」が格納される。

関連オブジェクトＩＤ１４７には、関連オブジェクト種別１４６のうち関係のある構成要素を特定するための識別子が格納される。関連オブジェクトＩＤ１４７には、リクエスト登録プログラム１１が構成情報テーブル１５から取得した関連オブジェクトＩＤを格納する。

処理待ちリクエストＩＤ１４８には、オブジェクト種別１４４と関連オブジェクト種別１４６の関係から、当該エントリのリクエストよりも先に処理を行う必要があるリクエストＩＤ１４２が格納される。処理待ちリクエストＩＤ１４８は、リクエスト登録プログラム１１またはリクエスト処理プログラム１２によって設定または更新され、複数のリクエストＩＤ１４２を格納することができる。

負荷１４９には、当該エントリのリクエストで計算機資源２に生じると推定される負荷が格納される。負荷１４９は、負荷テーブル１６で予め設定された値がリクエスト登録プログラム１１によって設定される。

図３、図４は、構成情報テーブル１５の一例を示す図である。構成情報テーブル１５は、オブジェクト種別毎に予め設定される。図３は、オブジェクト種別が「Ｐｏｏｌ」の構成情報テーブル１５を示し、図４は、オブジェクト種別が「Ｖｏｌｕｍｅ」の構成情報テーブル１５を示す。構成情報テーブル１５は、ストレージ装置１の管理者や管理ソフトウェア８によって設定される。

図３のオブジェクト種別が「Ｐｏｏｌ」の構成情報テーブル１５は、番号１５１と、オブジェクトＩＤ１５２と、容量１５３と、関連オブジェクト種別１５４と、関連オブジェクトＩＤ１５５を、ひとつのレコードに含む。

番号１５１は、管理ソフトウェア８によって付与されるシリアル値である。オブジェクトＩＤ１５２は、管理ソフトウェア８またはストレージ装置１の管理者によって付与される識別子で、ストレージ装置１内でユニークな値が設定される。

容量１５３は、プール５１の容量が格納される。関連オブジェクト種別１５４には、当該プール５１に関係（依存関係）する構成要素の種類（または名称）が格納される。図３の例ではオブジェクト種別がプール５１の構成情報テーブル１５であるので、関連オブジェクト種別１５４は、「Ｖｏｌｕｍｅ」が設定される。

関連オブジェクトＩＤ１５５には、関連オブジェクト種別１５４のうち当該プール５１と関係のある構成要素の識別子が格納される。関連オブジェクトＩＤ１４７には、リクエスト登録プログラム１１が構成情報テーブル１５から取得した関連オブジェクトＩＤを格納する。図３の例ではオブジェクト種別がプール５１の構成情報テーブル１５であるので、関連オブジェクトＩＤ１５５には、当該プール５１に割り当てられたボリューム５２の識別子が設定される。

図４のオブジェクト種別が「Ｖｏｌｕｍｅ」の構成情報テーブル１５は、番号１５１と、オブジェクトＩＤ１５２と、容量１５３を、ひとつのレコードに含む。各項目（フィールド）は、図３と同様である。オブジェクト種別が「Ｖｏｌｕｍｅ」の場合、ボリューム５２の配下となる構成要素がないため、関連オブジェクトは存在しない。

なお、本実施例ではＩＴリソースの一例としてストレージ装置１を例にしたので、管理ソフトウェア８の制御対象となる構成要素がストレージデバイス５となり、構成情報テーブル１５に容量などの項目を設定したが、ＩＴリソースの構成要素の特性や機能に応じた項目を設定すれば良い。

図５は、負荷テーブル１６の一例を示す図である。負荷テーブル１６は、要求されたリクエストの内容に応じて、計算機資源２の負荷（負荷の推定値）が管理者などによって予め設定される。

負荷テーブル１６は、番号１６１と、リクエスト種別１６２と、オブジェクト種別１６３と、容量１６４と、負荷１６５を、ひとつのレコードに含む。

番号１６１は、管理ソフトウェア８によって付与されるシリアル値である。リクエスト種別１６２は、制御対象（ストレージデバイス５）に対する操作の種類が格納され、例えば、管理クライアント２０が発行するリクエスト内のコマンドなどが含まれる。

オブジェクト種別１６３には、操作対象の構成要素の種類（または名称）が格納される。例えば、管理クライアント２０が発行したリクエストに含まれる操作対象の構成要素として「Ｖｏｌｕｍｅ」や「Ｐｏｏｌ」が、オブジェクト種別１６３に格納される。

容量１６４には、構成要素の容量の閾値が格納される。構成要素が記憶領域の場合、同一の構成要素であっても操作対象の容量に応じて計算機資源２にかかる負荷が異なるため、負荷を段階的に切り替えるための容量の閾値が格納される。

負荷１６５には、当該リクエスト種別１６２をオブジェクト種別１６３の容量１６４で実行した場合に計算機資源２にかかる負荷（または負荷の推定値）の増分値が格納される。負荷１６５の値は、管理ソフトウェア８と制御ソフトウェア７が共有する計算機資源２にかかる負荷を示し、例えば、プロセッサ３の使用率やメモリ４の使用率などを負荷として使用することができる。本実施例では、負荷として計算機資源２のプロセッサ３の使用率を用いる例を示す。

図示の例では、リクエスト種別１６２が「Ｆｏｒｍａｔ」で、オブジェクト種別１６３が「Ｖｏｌｕｍｅ」の場合、容量１６４が５００ＧＢ未満では負荷１６５＝５となり、５００ＧＢ以上では負荷１６５＝１５に設定される。

図６は、管理ソフトウェア８のリクエスト登録プログラム１１で行われるリクエストの受け付け処理の一例を示すフローチャートである。この処理は、インタフェース６が管理クライアント２０からストレージデバイス５を管理するためのリクエストを受信したときに実行される。なお、以下の説明では、プログラムを処理の主体とする例を示すが、プロセッサ３やストレージ装置１が処理の主体となってもよい。

リクエスト登録プログラム１１は、ステップＳ１で、管理クライアント２０からのリクエストを受け付ける。リクエストは操作の種類（リクエスト種別）と、制御対象の構成要素（オブジェクト種別）及びオブジェクトＩＤを含むことができる。

次に、ステップＳ２では、リクエスト登録プログラム１１が、受け付けたリクエストのオブジェクト種別とオブジェクトＩＤを取得して、当該オブジェクト種別に対応する構成情報テーブル１５を参照して、オブジェクトＩＤに対応する構成情報を取得する。なお、リクエスト登録プログラム１１は、構成情報として容量１５３と関連オブジェクト種別１５４と、関連オブジェクトＩＤ１５５を取得する。

ステップＳ３では、リクエスト登録プログラム１１が、取得した構成情報（容量１５３）とリクエスト種別１４３とオブジェクト種別１４４から負荷テーブル１６を参照し、負荷１６５を取得する。これにより、操作の種類と制御対象の構成要素の構成情報に応じた負荷１６５が決定される。

ステップＳ４では、リクエスト登録プログラム１１が、受け付けたリクエストで指定されたオブジェクト種別１４４とオブジェクトＩＤ１４５を含むレコードをリクエストテーブル１４で検索する。すなわち、リクエスト登録プログラム１１は、リクエストの内容が同じ構成要素に対するリクエストの有無を検索する。

ステップＳ５では、リクエスト登録プログラム１１が、上記条件を満足するか否かを判定し、該当するレコードが存在しなければステップＳ７へ進み、同じ構成要素のレコードが存在すれば、ステップＳ６に進んで、当該レコードのリクエストＩＤ１４２を処理待ちリクエストＩＤ１４８として取得する。すなわち、リクエスト登録プログラム１１は、同じ構成要素に対するリクエストがあれば、当該リクエストよりも先行するリクエストとして後述のステップＳ１０で処理待ちリクエストＩＤ１４８に設定する。

ステップＳ７では、リクエスト登録プログラム１１が、リクエストに含まれる構成要素の関連オブジェクト種別１４６と、関連オブジェクトＩＤ１４７が一致するレコードをリクエストテーブル１４で検索する。

ステップＳ８では、リクエスト登録プログラム１１が、上記条件を満足するか否かを判定し、該当するレコードがなければステップＳ１０へ進み、同じ関連オブジェクト種別１４６と関連オブジェクトＩＤ１４７が一致するレコード存在すれば、ステップＳ９に進んで、当該レコードのリクエストＩＤ１４２を処理待ちリクエストＩＤとして取得する。すなわち、リクエスト登録プログラム１１は、当該リクエストの構成要素と依存関係がある構成要素に対して先行するリクエストがあれば、後述するステップＳ１０で処理待ちリクエストＩＤ１４８に格納する。

ステップＳ１０では、リクエスト登録プログラム１１が、上記取得したリクエストと構成情報及び処理待ちリクエストＩＤを新しいレコードに追加する。

上記処理によって、管理ソフトウェア８のリクエスト登録プログラム１１は、受け付けたリクエストの構成要素に関連する関連オブジェクト種別と関連オブジェクトＩＤと負荷を設定するのに加えて、当該制御対象の構成要素に関連するオブジェクトＩＤを含むリクエストＩＤを、処理待ちリクエストＩＤ１４８として取得して新たなレコードをリクエストテーブル１４に追加する。

図７は、管理ソフトウェア８のリクエスト処理プログラム１２で行われるリクエスト処理の一例を示すフローチャートである。この処理では、ステップＳ１１〜ステップＳ１５が繰り返して実行される。

ステップＳ１２では、リクエスト処理プログラム１２がリクエストテーブル１４を参照する。そして、ステップＳ１３ではリクエスト処理プログラム１２が、リクエストテーブル１４に１レコード以上のデータがあるか否かを判定する。

１レコード以上のデータがあればステップＳ１４へ進んで、リクエスト処理プログラム１２は、後述するリクエスト決定処理を実行する。一方、リクエストテーブル１４にデータが無ければ上記ステップＳ１２以降の処理を繰り返す。

図８は、管理ソフトウェア８のリクエスト処理プログラム１２で行われるリクエスト決定処理の一例を示すフローチャートである。この処理は、図７のステップＳ１４で行われる処理である。

ステップＳ２１では、リクエスト処理プログラム１２が、計算機資源情報取得プログラム１３を呼び出して、計算機資源２の負荷情報（使用状況に関連する値）を取得させる。計算機資源情報取得プログラム１３は、負荷情報として、上述したように、プロセッサ３の使用率などを図示しないＯＳやハイパバイザから取得する。

ステップＳ２２では、リクエスト処理プログラム１２が、計算機資源情報取得プログラム１３から取得した負荷情報と、予め設定された計算機資源２の負荷閾値（第１の閾値）から、管理ソフトウェア８で利用可能な許容負荷を次のように算出する。

許容負荷＝負荷閾値−負荷情報

負荷許容は、図９で示すように、制御ソフトウェア７が利用する計算機資源２に応じて変動し、負荷の閾値から制御ソフトウェア７が利用する負荷を差し引いて算出される。

ステップＳ２３では、リクエスト処理プログラム１２が、許容負荷が０より大であるか否かを判定する。換言すれば、管理ソフトウェア８で利用可能な計算機資源２の有無を判定する。許容負荷が０（第２の閾値）より大であれば、ステップＳ２５へ進み。許容負荷が０であればステップＳ２４へ進む。

ステップＳ２４では、管理ソフトウェア８で利用可能な計算機資源２が無いので、リクエスト処理プログラム１２は、リクエストテーブル１４で待機しているリクエストの処理を一時的に禁止して処理を終了する。

一方、ステップＳ２５では、管理ソフトウェア８で利用可能な計算機資源２があるので、リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８に値が設定されていないレコードを選択する。すなわち、リクエスト処理プログラム１２は、構成要素の依存関係等からリクエストを処理する順序の変更を制限し、許容負荷以内で実行可能なリクエストであっても、構成要素の依存関係に応じたリクエストの実行順序を保持する。これにより、構成要素の依存関係に基づくリクエストの失敗を未然に防ぐことが可能となる。

ステップＳ２６では、リクエスト処理プログラム１２が、上記選択されたレコードの中から、負荷１４９が許容負荷以下で、かつ上記選択されたレコードの中で最大の負荷を有するレコードを処理の候補として取得する。

ステップＳ２７では、ステップＳ２６の処理の結果、処理の候補となるレコードが存在するか否かを判定する。処理の候補が存在する場合にはステップＳ２８へ進み、存在しない場合には処理を終了する。

次に、ステップＳ２８では、リクエスト処理プログラム１２が処理候補のリクエストを実行し、リクエストテーブル１４から当該リクエストのレコードを削除する。そして、ステップＳ２９では、当該リクエストのリクエストＩＤを処理待ちリクエストＩＤ１４８に含むレコードを検出し、処理待ちリクエストＩＤ１４８から当該リクエストＩＤを削除する。

上記処理によって、リクエストテーブル１４に格納されたリクエストは、負荷閾値と負荷情報（現在の負荷）の差分である許容負荷が０（所定値＝第２の閾値）より大であれば、許容負荷以内で負荷１４９が最大のリクエストから実行する。これにより、制御対象の構成要素を管理するためのリクエストを処理する順序を柔軟に制御することが可能となる。

そして、管理ソフトウェア８は、構成要素の依存関係からリクエストを処理する順序の変更を制限することで、構成要素の依存関係に応じたリクエストの実行順序を保持し、構成要素の依存関係に基づくリクエストの失敗を未然に防ぐことが可能となる。

また、許容負荷が所定値以下であれば、リクエストの実行を禁止して制御ソフトウェア７によるデータ要求の処理を優先させることができる。

図１０〜図１５は、上記処理を実施した場合のリクエストテーブル１４の変化を示す図である。以下の説明では、図１０の状態から図８の処理を３回繰り返した例を示し、許容負荷＝１５とした場合を示す。

図１０は、１回目の処理におけるリクエストテーブル１４の一例を示す図である。リクエストＩＤ１４２＝１〜４のレコードが格納され、リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８に値を含まないレコードを選択する（Ｓ２５）。この結果、リクエスト処理プログラム１２は、リクエストＩＤ１４２＝１〜３の３つのレコードを選択する。これにより、構成要素の依存関係に応じた処理の順序を保持し、許容負荷以内で実行可能なリクエストであっても、構成要素の依存関係に反するリクエストの実行順序の変更を禁止する。

次に、リクエスト処理プログラム１２は、負荷１４９が許容負荷（＝１５）以下で、かつ上記選択されたレコードの中で最大の負荷を有するレコードを処理の候補として取得する（Ｓ２６）。この処理により、負荷１４９＝１５のリクエストＩＤ１４２＝２のレコードが処理の候補として選択されて、構成要素＝「Ｖｏｌｕｍｅ」に対する「Ｆｏｒｍａｔ」のリクエストが実行される。

図１１は、１回目の処理が完了した後のリクエストテーブル１４の一例を示す図である。リクエストＩＤ１４２＝２の処理が完了すると、リクエスト処理プログラム１２は、リクエストＩＤ１４２＝２のレコードを削除する（Ｓ２８）。

次に、リクエスト処理プログラム１２は、削除したレコードのリクエストＩＤ１４２＝２を処理待ちリクエストＩＤ１４８に含むレコードを検索し、削除したレコードのリクエストＩＤ１４２＝２を、処理待ちリクエストＩＤ１４８から削除する（Ｓ２９）。

すなわち、図１０において、リクエストＩＤ１４２＝４の処理待ちリクエストＩＤ１４８には、「１」と「２」が設定されている。リクエストＩＤ１４２＝２の処理が完了したので、リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８から「２」のリクエストＩＤを削除し、「１」を残す。

図１２は、２回目の処理を行う際のリクエストテーブル１４の一例を示す図である。この図では、リクエストＩＤ１４２＝１、３、４が未処理の状態で、許容負荷＝１５である。

リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８に値を含まないレコードを選択する（Ｓ２５）。この結果、リクエスト処理プログラム１２は、リクエストＩＤ１４２＝１、３の２つのレコードを選択する。

次に、リクエスト処理プログラム１２は、負荷１４９が許容負荷（＝１５）以下で、かつ上記選択されたレコードの中で最大の負荷を有するレコードとして、負荷１４９＝１０のリクエストＩＤ１４２＝１のレコードが処理の候補として選択される。そして、リクエスト処理プログラム１２は、構成要素＝「Ｖｏｌｕｍｅ」に対する「Ｆｏｒｍａｔ」のリクエストを実行する（Ｓ２６）。

図１３は、２回目の処理が完了した後のリクエストテーブル１４の一例を示す図である。リクエストＩＤ１４２＝１の処理が完了すると、リクエスト処理プログラム１２は、リクエストＩＤ１４２＝１のレコードを削除する（Ｓ２８）。

次に、リクエスト処理プログラム１２は、削除したレコードのリクエストＩＤ１４２＝１を処理待ちリクエストＩＤ１４８に含むレコードを検索し、削除したレコードのリクエストＩＤ１４２＝１を、処理待ちリクエストＩＤ１４８から削除する（Ｓ２９）。

すなわち、図１２において、リクエストＩＤ１４２＝４の処理待ちリクエストＩＤ１４８には、「１」が設定されている。リクエストＩＤ１４２＝１の処理が完了したので、リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８から「１」のリクエストＩＤを削除し、処理待ちリクエストＩＤ１４８はブランクとなる。

図１４は、３回目の処理を行う際のリクエストテーブル１４の一例を示す図である。この図では、リクエストＩＤ１４２＝３、４が未処理の状態で、許容負荷＝１５である。

リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８に値を含まないレコードが無いので、リクエストＩＤ１４２＝３、４の２つのレコードを選択する。

次に、リクエスト処理プログラム１２は、負荷１４９が許容負荷（＝１５）以下で、かつ上記選択されたレコードの中で最大の負荷を有するレコードとして、負荷１４９＝１０のリクエストＩＤ１４２＝４のレコードが処理の候補として選択される。そして、リクエスト処理プログラム１２は、構成要素＝「Ｐｏｏｌ」に対する「Ｉｎｉｔｉａｌｉｚｅ」のリクエストを実行する（Ｓ２６）。

図１５は、３回目の処理が完了した後のリクエストテーブル１４の一例を示す図である。リクエストＩＤ１４２＝４の処理が完了すると、リクエスト処理プログラム１２は、リクエストＩＤ１４２＝４のレコードを削除する（Ｓ２８）。

次に、リクエスト処理プログラム１２は、処理待ちリクエストＩＤ１４８に値がないので処理を終了する。

以上のように、本実施例では、リクエストＩＤ１４２＝２、１、４の順序でリクエストの処理を行い、負荷１４９と許容負荷の関係からリクエストの実行順序を変更してリクエストＩＤ１４２＝２のリクエストから処理を開始する。しかし、構成要素の依存関係によるリクエストの実行順序を保持するため、リクエストＩＤ１４２＝１、２の処理が完了するまで、リクエストＩＤ１４２＝４の実行は制限される。すなわち、処理待ちリクエストＩＤ１４８によって、許容負荷に応じた動的な実行順序の入れ替えが制限される。

このように、本実施例のストレージ装置１では、データ要求を処理する制御ソフトウェア７（データ制御部）と管理要求を処理する管理ソフトウェア８（管理部）が計算機資源２を共有する情報処理装置において、許容負荷に応じてリクエストを処理する順序を動的に変更しながらも、構成要素の依存関係に基づくリクエストの順序を保持する。これにより、管理用のリクエストの失敗を未然に防ぎながらも、管理用のリクエストを処理する順序を柔軟に制御することが可能となる。

また、管理ソフトウェア８は、構成情報テーブル１５を参照することで、構成要素の依存関係を検出し、検出した構成要素の依存関係からリクエストの実行順序を決定して処理待ちリクエストＩＤ１４８に格納する。これにより、リクエストの実行順序の動的な変更と、構成要素の依存関係に応じた処理の順序を両立させることが可能となるのである。

本実施例では本発明を適用したＩＴリソースの一例としてストレージ装置１を示したが、これに限定されるものではない。例えば、仮想マシンを管理する管理プログラムとハイパバイザを稼働させる仮想計算機システムや、ＳＤＮ（Software Defined Network）を管理する管理プログラムとネットワークデバイスの制御ソフトウェアを稼働させるネットワークシステム等の情報処理装置に本発明を適用することができる。

また、上記実施例では、管理ソフトウェア８が、処理待ちリクエストＩＤ１４８を設定する例を示したが、管理クライアント２０が発行する管理要求に実行順序を付与するようにしても良い。この場合、管理要求のメタデータに当該要求よりも先に実行すべき管理要求を管理クライアント２０が格納すれば良い。

また、上記実施例では、計算機資源２の使用状況に関連する情報として計算機資源２の負荷を用いる例を示したが、構成要素の特性に応じて使用状況に関連する情報を選択することができる。例えば、構成要素とポート間の帯域や、構成要素の転送速度などを計算機資源２の使用状況に関連する情報とすることができる。

また、上記実施例では、許容負荷が０（第２の閾値）を超えるときに管理要求の実行順序を動的に変更する例を示したが、許容負荷の所定値は０に限定されるものではない。許容負荷が所定値を超えていれば許容負荷に応じて管理要求の実行を許可し、許容負荷が所定値以下であれば管理要求の実行を禁止すればよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１ ストレージ装置
２ 計算機資源
３ プロセッサ
４ メモリ
５ ストレージデバイス
６ インタフェース
７ 制御ソフトウェア
８ 管理ソフトウェア
９ ネットワーク
１１ リクエスト登録プログラム
１２ リクエスト処理プログラム
１３ 計算機資源情報取得プログラム
１４ リクエストテーブル
１５ 構成情報テーブル
１６ 負荷テーブル
２０ 管理クライアント
５１ プール
５２ ボリューム

Claims (6)

1. プロセッサとメモリを含む計算機資源と、制御対象の構成要素を有する情報処理装置であって、
   データ要求を受け付けて前記構成要素にアクセスするデータ制御部と、
   管理要求を受け付けて前記構成要素の管理を行う管理部と、
   前記構成要素の種別毎に予め設定されて、構成要素の識別子と、当該識別子に関連する関連構成要素種別と、当該識別子に関連する構成要素の関連構成要素識別子と、を予め設定した構成要素情報と、
   前記管理要求の種別と、制御対象の構成要素の種別と、当該管理要求を実行する際の実行負荷と、を予め設定した負荷情報と、
   前記管理部が付与したリクエスト識別子と、前記管理要求の構成要素の種別と、前記管理要求の構成要素の識別子と、前記管理要求の構成要素の当該種別及び識別子に関連する関連構成要素種別と、当該種別及び識別子に関連する関連構成要素識別子と、当該管理要求よりも先行して実施すべき管理要求の前記リクエスト識別子を含む処理待ち識別子と、当該管理要求を実行する際の前記実行負荷と、をレコード単位で格納するリクエスト情報と、
   を有し、
   前記管理部は、
   前記計算機資源を前記データ制御部と共有し、
   前記管理要求の種別と、制御対象の構成要素の種別と、制御対象の構成要素の識別子を含む前記管理要求を受け付けて、前記構成要素情報から前記制御対象の構成要素の種別と制御対象の構成要素の識別子に対応する前記関連構成要素種別と前記関連構成要素識別子を取得し、
   当該管理要求を実行する際の実行負荷を前記負荷情報から取得し、
   前記管理要求で指定された制御対象の構成要素の種別と制御対象の構成要素の識別子を含むレコードをリクエスト情報で検索し、当該構成要素の種別と当該構成要素の識別子を含むレコードが存在する場合には、当該レコードのリクエスト識別子を処理待ち識別子として取得し、
   前記構成要素情報から取得されて前記管理要求で制御対象となる構成要素の関連構成要素種別と前記関連構成要素識別子が、一致するレコードをリクエスト情報から検索し、当該一致するリクエスト情報のレコードのリクエスト識別子を処理待ち識別子として取得し、
   前記受け付けた管理要求の構成要素に関連する関連構成要素種別と関連構成要素識別子と、当該管理要求の実行負荷と、前記処理待ち識別子と、前記管理要求の種別と、制御対象の構成要素の種別と、制御対象の構成要素の識別子を新たなレコードとして前記リクエスト情報に追加し、
   使用状況として計算機資源の負荷を検出し、当該負荷と所定の第１の閾値から許容負荷を算出し、
   前記リクエスト情報のうち、前記処理待ち識別子が無く、かつ、前記実行負荷が前記許容負荷以内のレコードに対応する前記管理要求を実行し、当該リクエスト識別子に対応する前記リクエスト情報のレコードを削除し、他のリクエスト情報のレコードに当該リクエスト識別子が前記処理待ち識別子に含まれる場合には、当該レコードの処理待ち識別子から当該リクエスト識別子を削除して、前記管理要求の実行順序を動的に変更することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記管理部は、
   前記許容負荷が第２の閾値を超えているときに前記管理要求の実行を許容することを特徴とする情報処理装置。
3. 請求項２に記載の情報処理装置であって、
   前記管理部は、
   前記許容負荷が閾値以下であれば前記管理要求の実行を禁止することを特徴とする情報処理装置。
4. プロセッサとメモリを含む計算機資源で、制御対象の構成要素を管理する構成要素の管理方法であって、
   前記プロセッサが、データ要求を受け付けて前記構成要素にアクセスするデータ要求ステップと、
   前記プロセッサが、管理要求の種別と、制御対象の構成要素の種別と、制御対象の構成要素の識別子を含む前記管理要求を受け付ける受け付けステップと、
   前記プロセッサが、前記構成要素の種別毎に予め設定されて、構成要素の識別子と、当該識別子に関連する関連構成要素種別と、当該識別子に関連する構成要素の関連構成要素識別子と、を予め設定した構成要素情報から、制御対象の構成要素の種別及び制御対象の構成要素の識別子に対応する関連構成要素種別と前記関連構成要素識別子を取得する構成要素情報取得ステップと、
   前記プロセッサが、前記管理要求の種別と、制御対象の構成要素の種別と、当該管理要求を実行する際の実行負荷と、を予め設定した負荷情報から、当該管理要求を実行する際の実行負荷を取得する負荷情報取得ステップと、
   前記プロセッサが、リクエスト識別子と、前記管理要求の構成要素の種別と、前記管理要求の構成要素の識別子と、前記管理要求の構成要素の当該種別及び識別子に関連する関連構成要素種別と、当該種別及び識別子に関連する関連構成要素識別子と、当該管理要求よりも先行して実施すべき管理要求の前記リクエスト識別子を含む処理待ち識別子と、当該管理要求を実行する際の前記実行負荷と、をレコード単位で格納するリクエスト情報について、前記管理要求で指定された制御対象の構成要素の種別と制御対象の構成要素の識別子を含むレコードを検索し、前記構成要素の種別と構成要素の識別子を含むレコードが存在する場合には、当該レコードのリクエスト識別子を処理待ち識別子として取得し、
   前記構成要素情報から取得されて前記管理要求で制御対象となる構成要素の関連構成要素種別と前記関連構成要素識別子が、一致するレコードをリクエスト情報から検索し、当該一致するリクエスト情報のレコードのリクエスト識別子を処理待ち識別子として取得し、
   前記受け付けた管理要求の構成要素に関連する関連構成要素種別と関連構成要素識別子と、当該管理要求の実行負荷と、前記処理待ち識別子と、前記管理要求の種別と、制御対象の構成要素の種別と、制御対象の構成要素の識別子を新たなレコードとして前記リクエスト情報に追加するリクエスト格納ステップと、
   前記プロセッサが、使用状況として計算機資源の負荷を検出し、当該負荷と所定の第１の閾値から許容負荷を算出する許容負荷算出ステップと、
   前記プロセッサが、前記リクエスト情報のうち、前記処理待ち識別子が無く、かつ、前記実行負荷が前記許容負荷以内のレコードに対応する前記管理要求を実行する管理要求実行ステップと、
   前記プロセッサが、当該リクエスト識別子に対応する前記リクエスト情報のレコードを削除し、他のリクエスト情報のレコードに当該リクエスト識別子が前記処理待ち識別子に含まれる場合には、当該レコードの処理待ち識別子から当該リクエスト識別子を削除するリクエスト情報削除ステップと、
   を含むことを特徴とする構成要素の管理方法。
5. 請求項４に記載の構成要素の管理方法であって、
   前記管理要求実行ステップは、
   前記許容負荷が第２の閾値を超えているときに前記管理要求の実行を許容することを特徴とする構成要素の管理方法。
6. 請求項５に記載の構成要素の管理方法であって、
   前記管理要求実行ステップは、
   前記許容負荷が閾値以下であれば前記管理要求の実行を禁止することを特徴とする構成要素の管理方法。

Images