WO2017056208A1 - リクエスト実行順序制御方式 - Google Patents
リクエスト実行順序制御方式 Download PDFInfo
- Publication number
- WO2017056208A1 WO2017056208A1 PCT/JP2015/077642 JP2015077642W WO2017056208A1 WO 2017056208 A1 WO2017056208 A1 WO 2017056208A1 JP 2015077642 W JP2015077642 W JP 2015077642W WO 2017056208 A1 WO2017056208 A1 WO 2017056208A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- request
- task
- time
- execution
- executed
- Prior art date
Links
Images
Classifications
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
複数のタスクが多重実行され、タスクの延長で複数のリクエストが実行される情報システムにおいて、リクエストを受け付けるプログラムが、リクエストのタイムアウト要件及び実行時間と、リクエストと、リクエストが発行される元になったタスクとの関連を管理し、プログラムがタスクの延長で多数のリクエストを受け付けた場合に、リクエストのタイムアウト要件と、各リクエストの元になったタスクとの関連を特定し、リクエスト発行もとのプログラムにおけるタスクの実行順序と各リクエストのタイムアウト要件に従って、タイムアウトをできるだけ抑止するようにリクエスト実行順を制御する。
Description
本発明は、複数のプログラムが連携して一つの機能を提供するシステムにおいて、上位プログラムの操作が多重実行されたときに、下位プログラムの処理順序を制御する方法に関する。
クラウドのようなコンピューティングリソースが仮想化されてユーザに提供される環境では、ユーザはクラウド内の物理リソースの状態や制御情報を直接意識せずに、仮想マシンやアプリケーションを利用するのが一般的である。例えば、仮想マシンを作成したときに、バックグラウンドでどのコンピューティングリソースに対して、どのような命令が実行されているかはわからない。
このとき、ユーザが複数の操作を多重実行すると、それらの操作の延長で発行される処理要求が互いに影響しあい、ユーザの意図に反してある操作がタイムアウトして失敗する場合がある。例えば、仮想マシン１を作成中に、さらに追加操作で仮想マシン２を作成したときに、仮想マシン１の作成操作が仮想マシン２の操作に割り込まれて、仮想マシン１の作成に失敗して仮想マシン２の作成に成功するようなケースがある。
以上の状況に関して、特許文献１記載の技術では、個々の仮想マシン毎に行われるアクセスの優先度制御等の処理指定を、仮想マシンにタグ付けして優先度を管理することで、多くの仮想マシンが存在するシステムでも、ストレージの大きな負担、例えばメモリ所要量の増加や処理負荷の増大無しに実現する。
また、特許文献２記載の技術では、仮想マシンの移動順を制御することにより、特定の仮想ホストに一時的に集中して負荷が上昇することを有効に回避する方法について述べられている。
しかしながら、特許文献１や特許文献２に記載されている技術では、仮想マシンに対する操作の優先度は判定できるが、その操作に付随してバックグラウンドで実行されている処理の優先度は考慮されていない。そのため、ある仮想マシンの操作の完了を待ってから次の操作に移るように制御することしかできず、多重時実行可能な処理であっても仮想マシン操作のトータルの実行時間が延びる場合がある。さらに、タイムアウトが短く設定されているような操作の場合には、優先度順に常に実行してしまうと、後半に実行される操作ほどタイムアウトまでの猶予が短くエラーが発生するリスク増大し、ユーザの利便性低下を招く。
また、ユーザはバックグラウンドの処理を直接意識することではできないため、ユーザから見える仮想マシンや仮想マシンに対する操作の情報のみだけでは、内部処理に待たされてタイムアウトが発生するというように、同様の問題が発生する場合がある。
本発明は、上記の課題に鑑みてなされたものであり、複数のプログラムが階層的に呼び出されて一つの機能を提供するシステムにおいて、上位プログラムの操作が大量に多重実行され下位プログラムがバックグラウンドで呼び出される状況において、ユーザが下位レイヤのプログラムの動作を直接意識することなく、上位プログラムの操作性を向上しうる下位プログラムの制御方法を提供することを目的とする。
上記の目的を達成するため、本発明は、複数のタスクが多重実行され、タスクの延長で複数のリクエストが実行される情報システムにおいて、リクエストを受け付けるプログラムが、リクエストのタイムアウト要件及び実行時間と、リクエストと、リクエストが発行される元になったタスクとの関連を管理し、プログラムがタスクの延長で多数のリクエストを受け付けた場合に、リクエストのタイムアウト要件と、各リクエストの元になったタスクとの関連を特定し、リクエスト発行もとのプログラムにおけるタスクの実行順序と各リクエストのタイムアウト要件に従って、タイムアウトをできるだけ抑止するようにリクエスト実行順を制御することで実現する。
本発明によれば、ユーザが直接操作するプログラムとバックグラウンドで処理を実行するプログラムの操作単位が異なる環境において、ユーザは下位プログラムの処理状態を意識することなく、上位プログラムの操作を円滑に行うことが可能になり、ユーザの利便性が向上する。
以下、図面を用いて本発明の実施形態につき詳細に説明する。なお、各図に示す同一の符号は同一の機能または構成を有することを示しているため、重複した説明は省略する。
図１は、本発明の基本動作を示す図である。図１を用いて、リクエストのタイムアウト要件を考慮せず優先制御しないで各タスクを処理した場合（リクエスト優勢制御なし１０１）と、リクエストのタイムアウト要件を考慮して優先制御した場合（リクエスト優勢制御あり１０２）の振る舞いの違いと効果を説明する。
プログラム間やプログラム内で実行される処理は、ある処理の延長で複数の処理がさらに呼ばれる階層構造を取る。例えば、仮想化環境を管理している管理者が、仮想マシンの操作を行うとその要求を受け取ったプログラムは、その操作に必要な複数のＡＰＩを順次実行する場合である。本実施例では、このユーザ操作やユーザ操作を提供している機能にあたる上位の処理をタスク、ユーザ操作や機能を実行した延長で実行される下位の処理をリクエストと定義する。各タスクは一つ以上のリクエストから構成され、タスクとリクエストはタイムアウトの要件がある。
プログラム間やプログラム内で実行される処理は、ある処理の延長で複数の処理がさらに呼ばれる階層構造を取る。例えば、仮想化環境を管理している管理者が、仮想マシンの操作を行うとその要求を受け取ったプログラムは、その操作に必要な複数のＡＰＩを順次実行する場合である。本実施例では、このユーザ操作やユーザ操作を提供している機能にあたる上位の処理をタスク、ユーザ操作や機能を実行した延長で実行される下位の処理をリクエストと定義する。各タスクは一つ以上のリクエストから構成され、タスクとリクエストはタイムアウトの要件がある。
図１は、タスク１が実行されると、そのバックグラウンドでは、リクエスト１－１、リクエスト１－２、リクエスト１－３が順に実行されてタスク１が完了する例である。タスク２も同様に、リクエスト２－１、リクエスト２－２が順に実行され、タスク３はリクエスト３－１のみ実行される。図中の実線部分はリクエストがシステム内で実行中であることを示し、図中の点線部分はシステムがリクエストを受け付けているものの、他のリクエストが実行中のためそのリクエストが待たされていることを示す。
リクエスト優勢制御なし１０１の例では、時刻ｔ０にタスク１が実行され、その延長でリクエスト１－１、リクエスト１－２が順に実行されており、リクエスト１－２実行中にタスク２、タスク３が実行され、リクエスト２－１、リクエスト３－１がリクエスト１－２の実行完了待ちの状態である。その後、リクエスト１－２が完了すると（ｔ２）、待機中のリクエスト２－１が実行され、それが完了すると（ｔ３）、リクエスト３－１が実行される。そしてリクエスト３－１が完了すると待機中のリクエスト１－３が実行される（ｔ４）。このとき、リクエスト１－３は、リクエスト１－２が完了した後に実行開始しているものの、リクエスト２－１とリクエスト３－１の実行完了待ちのため待たされており、実行途中でタイムアウト要件を超えてリクエスト１－３がタイムアウトでエラー終了し（ｔ５）、タスク１が失敗する。その後リクエスト２－２が実行されタスク２は完了する。この結果、タスクを実行したユーザから見ると、最初に投入したタスク１の進捗がある程度あったにもかかわらずタイムアウトが起きて失敗し、その後に投入されたタスクが成功するという現象が生じることになる。
一方、リクエスト優先制御あり１０２の場合は、リクエスト２－１実行完了(ｔ３）までは同様の動きになるが、リクエスト２－１の実行が完了した時点（ｔ３）で、待機中の各リクエスト、この場合はリクエスト１－３とリクエスト３－１のタイムアウト要件をチェックすることにより、リクエスト３－１を先に実行することでリクエスト１－３がタイムアウトしてしまう場合には、最初に実行されたタスクを優先して、リクエストの実行順序を入れ替えてリクエスト１－３を先に実行する。これにより、先行実行されているタスク１はタイムアウトせずに処理が完了する。
これにより、タスクが並列実行された場合でもタスク間のタイムアウト要件をもとにタスクの実行順序が制御され、タイムアウトの発生を抑止することが可能になり、多数の操作が並列に実行される環境下において、ユーザの利便性が向上される。
（第1の実施形態）
＜システム構成＞
以下、図２から図１０を用いて本発明の第１の実施例を詳細に説明する。なお、各図に示す同一の符号は同一の機能または構成を有するため、重複した符号の説明は省略する。
図２は、本発明の第1の実施例に係る計算機システムのブロック図である。計算機システムは、ホスト計算機１、ストレージシステム２、管理計算機３、管理ネットワーク４、データネットワーク５、管理端末６で構成される。
ホスト計算機１は、メモリ１０、ホスト制御プログラム１１、入出力装置１２、ＣＰＵ１３、ストレージ１４、管理インターフェース１５、データインタフェース１６で構成される。ホスト制御プログラム１１は、ホスト計算機を制御するプログラムであり、本実施例では、仮想マシンを制御するハイパーバイザがホスト制御プログラム１１に相当する。ホスト制御プログラム１１は、ストレージ１４に格納されたプログラムをＣＰＵ１３が読み出し、メモリ１０上で実行されることにより実現されるものである。ホスト制御プログラム１１はあらかじめホスト計算機１内のストレージ１４に格納されていてもよいし、必要なときに入出力装置１２やデータインタフェース１６を経由してロードさストレージ１４に格納されてもよい。管理インターフェース２５は、ホスト計算機１を制御するための管理データを送受信するためのインターフェースである。データインタフェース１６は、ホスト計算機上で動作するプログラムが他のホスト計算機１やストレージ装置２とデータを送受信するためのインターフェースである。ストレージ装置２、管理計算機３、管理端末６も同様のコンポーネントを有するため差異部分のみ説明する。
ストレージシステム２は、メモリ２０、ストレージ制御プログラム２１、ＣＰＵ２２、ディスク２３、論理ボリューム２４、管理インターフェース２５、データインタフェース２６で構成される。ストレージ制御プログラム２１は、ストレージの構成変更やデータのレプリケーション、データの重複排除などのストレージ機能を提供するプログラムであり、ＣＰＵ２２がメモリ２０上で実行する。論理ボリューム２４は、データインタフェース２６を通してホスト計算機１に提供されるデータ格納領域であり、ストレージ制御プログラム２１が一つ以上のディスク２３から仮想的に切り出して作成される。ディスク２３はＨＤＤやＳＳＤのような記憶領域である。それ以外の要素はホスト計算機１と同様のため説明を省略する。
管理計算機３は、ホスト計算機１と同様の構成を取り、ホスト制御プログラム１１の変わりホスト管理プログラム３１、ストレージ管理プログラム３２が動作する。 図では別々の物理計算機にそれぞれのプログラムが搭載されているが、1つの物理計算機に搭載されてもよい。
リクエスト優勢制御なし１０１の例では、時刻ｔ０にタスク１が実行され、その延長でリクエスト１－１、リクエスト１－２が順に実行されており、リクエスト１－２実行中にタスク２、タスク３が実行され、リクエスト２－１、リクエスト３－１がリクエスト１－２の実行完了待ちの状態である。その後、リクエスト１－２が完了すると（ｔ２）、待機中のリクエスト２－１が実行され、それが完了すると（ｔ３）、リクエスト３－１が実行される。そしてリクエスト３－１が完了すると待機中のリクエスト１－３が実行される（ｔ４）。このとき、リクエスト１－３は、リクエスト１－２が完了した後に実行開始しているものの、リクエスト２－１とリクエスト３－１の実行完了待ちのため待たされており、実行途中でタイムアウト要件を超えてリクエスト１－３がタイムアウトでエラー終了し（ｔ５）、タスク１が失敗する。その後リクエスト２－２が実行されタスク２は完了する。この結果、タスクを実行したユーザから見ると、最初に投入したタスク１の進捗がある程度あったにもかかわらずタイムアウトが起きて失敗し、その後に投入されたタスクが成功するという現象が生じることになる。
一方、リクエスト優先制御あり１０２の場合は、リクエスト２－１実行完了(ｔ３）までは同様の動きになるが、リクエスト２－１の実行が完了した時点（ｔ３）で、待機中の各リクエスト、この場合はリクエスト１－３とリクエスト３－１のタイムアウト要件をチェックすることにより、リクエスト３－１を先に実行することでリクエスト１－３がタイムアウトしてしまう場合には、最初に実行されたタスクを優先して、リクエストの実行順序を入れ替えてリクエスト１－３を先に実行する。これにより、先行実行されているタスク１はタイムアウトせずに処理が完了する。
これにより、タスクが並列実行された場合でもタスク間のタイムアウト要件をもとにタスクの実行順序が制御され、タイムアウトの発生を抑止することが可能になり、多数の操作が並列に実行される環境下において、ユーザの利便性が向上される。
（第1の実施形態）
＜システム構成＞
以下、図２から図１０を用いて本発明の第１の実施例を詳細に説明する。なお、各図に示す同一の符号は同一の機能または構成を有するため、重複した符号の説明は省略する。
図２は、本発明の第1の実施例に係る計算機システムのブロック図である。計算機システムは、ホスト計算機１、ストレージシステム２、管理計算機３、管理ネットワーク４、データネットワーク５、管理端末６で構成される。
ホスト計算機１は、メモリ１０、ホスト制御プログラム１１、入出力装置１２、ＣＰＵ１３、ストレージ１４、管理インターフェース１５、データインタフェース１６で構成される。ホスト制御プログラム１１は、ホスト計算機を制御するプログラムであり、本実施例では、仮想マシンを制御するハイパーバイザがホスト制御プログラム１１に相当する。ホスト制御プログラム１１は、ストレージ１４に格納されたプログラムをＣＰＵ１３が読み出し、メモリ１０上で実行されることにより実現されるものである。ホスト制御プログラム１１はあらかじめホスト計算機１内のストレージ１４に格納されていてもよいし、必要なときに入出力装置１２やデータインタフェース１６を経由してロードさストレージ１４に格納されてもよい。管理インターフェース２５は、ホスト計算機１を制御するための管理データを送受信するためのインターフェースである。データインタフェース１６は、ホスト計算機上で動作するプログラムが他のホスト計算機１やストレージ装置２とデータを送受信するためのインターフェースである。ストレージ装置２、管理計算機３、管理端末６も同様のコンポーネントを有するため差異部分のみ説明する。
ストレージシステム２は、メモリ２０、ストレージ制御プログラム２１、ＣＰＵ２２、ディスク２３、論理ボリューム２４、管理インターフェース２５、データインタフェース２６で構成される。ストレージ制御プログラム２１は、ストレージの構成変更やデータのレプリケーション、データの重複排除などのストレージ機能を提供するプログラムであり、ＣＰＵ２２がメモリ２０上で実行する。論理ボリューム２４は、データインタフェース２６を通してホスト計算機１に提供されるデータ格納領域であり、ストレージ制御プログラム２１が一つ以上のディスク２３から仮想的に切り出して作成される。ディスク２３はＨＤＤやＳＳＤのような記憶領域である。それ以外の要素はホスト計算機１と同様のため説明を省略する。
管理計算機３は、ホスト計算機１と同様の構成を取り、ホスト制御プログラム１１の変わりホスト管理プログラム３１、ストレージ管理プログラム３２が動作する。 図では別々の物理計算機にそれぞれのプログラムが搭載されているが、1つの物理計算機に搭載されてもよい。
ホスト管理プログラム３１は、管理インターフェース６１やストレージ管理プログラム３２からの要求に伴い、ホスト計算機１で動作するホスト制御プログラム１１に対してホストを操作する命令を出す。本実施例では、ホスト管理プログラム３１は、仮想化環境のハイパーバイザを管理するプログラムに相当し、ホスト制御プログラム１に対する命令としては、ＶＭ作成、ＶＭ起動、ＶＭ複製、ＶＭのスナップショット作成などがある。
ストレージ管理プログラム３２は、管理インターフェース６１やホスト管理プログラム３１からの要求に伴い、ストレージ装置２で動作するストレージ制御プログラム２１に対してストレージを操作する命令を出す。ストレージ制御プログラム２１に対する命令としては、論理ボリューム２４の作成、論理ボリューム２４のホスト計算機１への割り当て、論理ボリューム２４の複製、ホスト計算機１からストレージ装置２にデータが転送に関するＱｏＳの設定、データ暗号化の設定切り替え、重複排除の切り替えなどがある。
管理端末６は、ホスト計算機１と同様の構成を取り、管理インターフェース６１が動作する。管理インターフェース６１は、ホスト管理プログラム３１、ストレージ管理プログラム３２を通して、ホスト計算機１とストレージ装置２を制御するためのユーザーインタフェースを提供するプログラムである。
管理ネットワーク４は、管理用のネットワークである。ホスト管理プログラム３１、ストレージ管理プログラム３２、管理インターフェース６１、ホスト制御プログラム１１、ストレージ制御プログラム２１の間でホスト計算機１やストレージ装置２を制御するためのデータやその実行結果に関するデータが流れる。
データネットワーク５は、ＳＡＮのようなデータ転送用のネットワークである。ホスト計算機１がストレージ装置２の論理ボリューム２４に対して、データの読み書きを実行する際のデータが流れる。図２では、管理操作に伴う各プログラム間のデータ送受信が、ホスト計算機とストレージ装置間のデータの読み書き性能に影響を与えるのを防ぐため管理ネットワーク４とは独立しているが、同一のネットワーク構成でもよい。
次に、図３を用いて第１の実施例における管理計算機３１上で動作するストレージ管理プログラム３２の詳細構成と機能概要について説明する。ストレージ管理プログラム３２は、リクエスト処理部３３とストレージ制御部３９で構成される。リクエスト処理部３３は、さらに、タイムアウト管理部３４、リクエスト登録部３５、リクエスト実行制御部３６、性能要件定義テーブルＴ１、タスク状態管理テーブルＴ２、タイムアウト管理テーブルＴ３で構成される。
リクエスト処理部３３は、ストレージ管理プログラム３２が、ホスト管理プログラム３１や管理インターフェース６１から受け付けたリクエストを処理するモジュールである。リクエストの受け付け、リクエストの実行、リクエストの実行結果の返却を行い、リクエストの種別に応じた処理を実行する。
タイムアウト管理部３４は、リクエストのタイムアウトに関連する情報を管理するモジュールであり、性能要件定義テーブルＴ１のデータの登録、編集、参照、削除機能を提供する。管理端末上で動作する管理インターフェースを通してデータは操作される。
リクエスト登録部３５は、ストレージ管理プログラム３２が受け付けたリクエストをタスク状態管理テーブルＴ２に登録するモジュールである。受け付けたリクエストは一旦タスク状態管理テーブルＴ２に登録されてリクエスト実行順制御部によって適切なタイミングで実行される。
リクエスト実行制御部３６は、性能要件定義テーブルＴ１に定義されているタイムアウト要件に基づいて、タスク状態管理テーブルＴ２に登録されているリクエストの実行順を制御し、リクエストを実行するモジュールである。リクエストの種別に応じてストレージ管理プログラム内で処理が完結し、そのままリクエスト処理部からレスポンスを返却する場合と、ストレージ装置２に対してストレージ操作を実行するためにストレージ制御部３９を呼び出す場合がある。
性能要件定義テーブルＴ１は、ストレージ管理プログラム３２が扱うリクエストの性能要件を定義するテーブルである。ここで定義されているタイムアウトの値や、各リクエストの実行時間の値をもとに、リクエスト実行順制御部３６はリクエストの優先順を制御する。
タスク状態管理テーブルＴ２は、ストレージ管理プログラム３２が受け付けたリクエストの実行状態を定義するテーブルである。このテーブルを参照することで、リクエストが実行中か待機中か、また、リクエストがどのタスクに属するかわかる。
タイムアウト管理テーブルＴ３は、ストレージ管理プログラム３２が受け付けたリクエストがタイムアウトするまでの残り時間を管理するテーブルである。リクエスト実行順制御部３６は、このテーブルを使い、各リクエストがタイムアウトするまでの残り時間を管理し、リクエストの実行順を制御する。
ストレージ制御部３９は、リクエスト処理部３３からの要求を受け、ストレージ装置２で動作するストレージ制御プログラム２１に対し、ストレージ操作を実行するモジュールである。
以上が、本実施例の計算機システムの構成と、計算機システム内の管理計算機３１上で動作するストレージ管理プログラムの構成概要である。
＜データ構成＞
図４は、第１の実施例における性能要件定義テーブルＴ１の例である。性能要件定義テーブルＴ１は、ストレージ管理プログラムが提供する各リクエストの性能要件と実行時間を定義するテーブルである。性能要件定義テーブルＴ１は、属性として、リクエスト１０１、タイムアウト１０２、実行時間１０３を持つ。
リクエスト１０１は、ストレージ管理プログラムが受信したリクエストを一意に識別する属性である。リクエスト１０１の値は、リクエスト名、または、パラメータを含んだリクエスト名が格納される。リクエスト名は、ＡＰＩ名や内部処理の関数名などでもよい。また、同じリクエストでもパラメータによってタイムアウト要件や実行時間が変わるリクエストは、異なるリクエストとして定義される。テーブルＴ１の例では、ストレージ２に論理ボリューム２４を作成するためのｃｒｅａｔｅＶｏｌｕｍｅリクエスト、論理ボリューム２４をホスト計算機１に割り当てるａｌｌｏｃａｔｅＶｏｌｕｍｅ、論理ボリューム２４のスナップショット作成の事前処理を行うためのｃｒｅａｔｅＳｎａｐｓｈｏｔＰａｉｒ、スナップショットペアの作成を完了するためのｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒ、リクエストｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒのタイムアウト要件が異なるｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒ（１０）がそれぞれ定義されている。
タイムアウト１０２は、リクエストがタイムアウトする時間を示す属性である。タイムアウトの値は各リクエストの要件に応じて決定される。実行時間１０３は、リクエストの処理にかかる時間を示す属性である。実行時間１０３は、タイムアウトまでの残り時間を算出するために利用される。本実施例では、ストレージ管理者が定義するが、実際に実行したときにかかった時間を自動的に設定しても良い。
図４の１行目の例では、リクエストｃｒｅａｔｅＶｏｌｕｍｅはタイムアウト要件が６０秒で処理に１０秒かかることを表している。また、２行目の例では、リクエストｃｒｅａｔｅＶｏｌｕｍｅにパラメータarg1が指定された場合は、タイムアウトが２０秒で実行時間が１０秒であることを表している。
図５は、第１の実施例におけるタスク状態管理テーブルＴ２の例である。タスク状態管理テーブルＴ２は、ストレージ管理プログラム３２が受信した各リクエストの実行状態を管理するテーブルであり、図５では、５個のリクエストを受け付けており、同時に実行可能なリクエストが１リクエストの場合の例である。タスク状態管理テーブルＴ２は、属性として、実行順２０１、ＩＤ２０２、リクエスト２０３、タスク２０４、対象２０５、ステータス２０６、受付時刻２０７を持つ。
実行順２０１は、リクエストを実行する順序を示す属性である。値が小さい順に実行されるが、リクエスト実行順制御部４３によって実行順は適宜入れ替えられる。ＩＤ２０２は、ストレージ管理プログラム３２内でリクエストを一意に識別するためのＩＤである。リクエスト２０３は、ストレージ管理プログラム３２が受信して、実行中または待機中のリクエストを示す属性である。タスク２０４は、リクエストの元になったタスクを示す属性である。図６の例では、ＶＭに対する操作を示す“ＶＭ操作”がタスクとして登録されている。対象２０５は、タスクの実行対象を示す属性である。ＶＭ操作の対象となるＶＭがＶＭ１の場合は、“ＶＭ１”が登録される。ステータス２０６は、リクエストの状態を表す属性である。Ｒｕｎｎｉｎｇは実行中、Ｗａｉｔｉｎｇは待機中、Ｃｏｍｐｌｅｔｅｄは完了を表す。完了になったタスクは一定時間後に削除される。受付時刻２０７は、リクエストを受け付けた時刻を示す属性である。タイムアウトの算出に使われる。本実施例では秒単位までの表記だが、ミリ秒など他の単位でも良い。
図５の１行目の例は、ストレージ管理プログラム３２が、ホスト計算機１上でＶＭ１に対する操作の延長で発行されたａｌｌｏｃａｔｅＶｏｌｕｍｅリクエストを１０１５年６月２０日１０時００分００秒に受け付け、実行中であることを表している。また、２行目は、ＶＭ２の操作の延長で発行されたｃｒｅａｔｅＶｏｌｕｍｅリクエストを、その７秒後に受け付けて、実行開始を待機していることを表す。
図６は、第１の実施例におけるタイムアウト管理テーブルＴ３の例である。タイムアウト管理テーブルＴ３は、ストレージ管理プログラム３２のリクエスト実行順制御部４３が、各リクエストのタイムアウト状況を判定し、リクエストの実行順序を入れ替えるために使用するテーブルであり、タイムアウト管理テーブルＴ３は、属性として、ＩＤ３０１、リクエスト３０２、残り時間（実行前）３０３、残り時間（実行完了時）３０４、残り時間（先行リクエスト完了時）３０５を持つ。図６は、実行待機中のリクエストが４個あり、ＩＤ１０００１のｃｒｅａｔｅＶｏｌｕｍｅが完了した時刻１０時００分１０秒の時点の状態、つまり、ＩＤ１０００２のリクエストを受け付けてから３秒経過した状態の例である。
ＩＤ３０１は、リクエストを一意に識別するＩＤでタスク管理テーブルＴ２のＩＤ２０２に対応する。リクエスト３０２はリクエストを表す名称で、タスク管理テーブルＴ２のリクエスト２０３に対応する。
残り時間（実行前）３０３は、リクエストがタイムアウトするまでに残されている時間を示す属性である。この値が負の場合、タイムアウト計算時点でそのリクエストが既にタイムアウトしているということを意味する。ＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅを例に説明すると、性能要件定義テーブルＴ１のｃｒｅａｔｅＶｏｌｕｍｅのタイムアウトの値が６０秒でリクエスト受付から３秒経過しているため５７秒が設定される。
残り時間（実行完了時）３０４は、その行のリクエストが完了した時点でタイムアウトするまでに残されている時間を示す属性である。この値が負の場合、リクエストが実行中にタイムアウトすることを意味する。ＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅを例に説明すると、性能要件定義テーブルＴ１のｃｒｅａｔｅＶｏｌｕｍｅの実行時間属性１０３の値が１０秒で、実行前の残り時間３０３が５７秒のため、実行完了時の残り時間は４７秒になる。
残り時間（先行リクエスト完了時）３０５は、待機中のリクエストの中で実行順序が先頭のリクエストを実行した場合の、先頭リクエスト完了時点のタイムアウトするまでに残されている時間を示す属性である。この値がマイナスの場合、実行待機中の先頭のリクエストを実行すると、その実行中にタイムアウトすることを意味する。ＩＤ１０００４のｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒ（１０）を例に説明すると、実行前の残り時間が８秒で、待機中の先頭のリクエストのであるＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅの実行時間が１０秒であるため、ＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅを実行すると－２秒になりタイムアウトすることがわかる。
＜ユーザーインタフェース＞
図７は、第１の実施例におけるストレージ管理プログラム３２が処理する各リクエストの性能要件と実行時間を定義するリクエスト性能要件設定画面Ｇ１の例である。リクエスト性能要件設定画面Ｇ１は、管理インターフェース６１の画面の一つである。
リクエスト性能要件設定画面Ｇ１のリクエスト７０１は、ストレージ管理プログラム３２がサポートするリクエスト種別の一覧であり、性能要件定義テーブルＴ１のリクエスト属性１０１に対応する。同様に、タイムアウト７０２は、タイムアウト属性１０２に対応し、実行時間７０３は、実行時間属性１０３に対応する。性能要件定義テーブルＴ１に登録されている値が表示され、同様に、ここで設定した値は、性能要件定義テーブルＴ１に登録される。
＜処理フロー＞
図８は、第１の実施例におけるホスト制御プログラムがリクエストを発行するときの、各コンポーネント間の処理の関係を示すシーケンス図である。ホスト管理プログラム３１でユーザがＶＭ操作のタスクを実行すると、そのタスクがホスト制御プログラム１１に通知され、そのタスクに応じた処理がホスト制御プログラム１１で実行される。
ホスト制御プログラム１１がストレージ管理プログラム３２に対してリクエストを実行すると（Ｓ８０１）、リクエスト処理部３５がそのリクエストは受け付けてリクエストをタスク状態管理テーブルＴ２に登録し（Ｓ８０２）、そのリクエストが実行可能になるまで待機させる（Ｓ８０３）。その後、実行中のリクエストが完了して待機中のリクエストが実行可能になったときに、待機中の全リクエストに対して実行順が制御されてから（Ｓ８０４）、リクエストが実行される（Ｓ８０５）。
リクエスト処理部３５から要求を受け付けたストレージ制御部３９は、そのリクエストをストレージ装置２上のストレージ制御プログラム２１に対して要求し（Ｓ８０６）、実行結果を取得すると（Ｓ８０７）、リクエスト処理部３５に結果を返す（Ｓ８０８）。
結果を受け取ったリクエスト処理部３５は、ホスト制御プログラム１１にリクエストの実行結果を返す。
ホスト制御プログラム１１は結果を受け取ると（Ｓ８０９）、タスクを完了するかタスクに応じた次のリクエストを実行する（Ｓ８１０）。
本処理では、ホスト制御プログラム１１がリクエストを送信しているが、ホスト管理プログラム３１がタスク実行の延長で直接ストレージ管理プログラム３２にリクエストを発行する構成を取っても良い。Ｓ８０２の処理の詳細を図９で、Ｓ８０４の処理の詳細を図１０で、それぞれ説明する。
ストレージ管理プログラム３２は、管理インターフェース６１やホスト管理プログラム３１からの要求に伴い、ストレージ装置２で動作するストレージ制御プログラム２１に対してストレージを操作する命令を出す。ストレージ制御プログラム２１に対する命令としては、論理ボリューム２４の作成、論理ボリューム２４のホスト計算機１への割り当て、論理ボリューム２４の複製、ホスト計算機１からストレージ装置２にデータが転送に関するＱｏＳの設定、データ暗号化の設定切り替え、重複排除の切り替えなどがある。
管理端末６は、ホスト計算機１と同様の構成を取り、管理インターフェース６１が動作する。管理インターフェース６１は、ホスト管理プログラム３１、ストレージ管理プログラム３２を通して、ホスト計算機１とストレージ装置２を制御するためのユーザーインタフェースを提供するプログラムである。
管理ネットワーク４は、管理用のネットワークである。ホスト管理プログラム３１、ストレージ管理プログラム３２、管理インターフェース６１、ホスト制御プログラム１１、ストレージ制御プログラム２１の間でホスト計算機１やストレージ装置２を制御するためのデータやその実行結果に関するデータが流れる。
データネットワーク５は、ＳＡＮのようなデータ転送用のネットワークである。ホスト計算機１がストレージ装置２の論理ボリューム２４に対して、データの読み書きを実行する際のデータが流れる。図２では、管理操作に伴う各プログラム間のデータ送受信が、ホスト計算機とストレージ装置間のデータの読み書き性能に影響を与えるのを防ぐため管理ネットワーク４とは独立しているが、同一のネットワーク構成でもよい。
次に、図３を用いて第１の実施例における管理計算機３１上で動作するストレージ管理プログラム３２の詳細構成と機能概要について説明する。ストレージ管理プログラム３２は、リクエスト処理部３３とストレージ制御部３９で構成される。リクエスト処理部３３は、さらに、タイムアウト管理部３４、リクエスト登録部３５、リクエスト実行制御部３６、性能要件定義テーブルＴ１、タスク状態管理テーブルＴ２、タイムアウト管理テーブルＴ３で構成される。
リクエスト処理部３３は、ストレージ管理プログラム３２が、ホスト管理プログラム３１や管理インターフェース６１から受け付けたリクエストを処理するモジュールである。リクエストの受け付け、リクエストの実行、リクエストの実行結果の返却を行い、リクエストの種別に応じた処理を実行する。
タイムアウト管理部３４は、リクエストのタイムアウトに関連する情報を管理するモジュールであり、性能要件定義テーブルＴ１のデータの登録、編集、参照、削除機能を提供する。管理端末上で動作する管理インターフェースを通してデータは操作される。
リクエスト登録部３５は、ストレージ管理プログラム３２が受け付けたリクエストをタスク状態管理テーブルＴ２に登録するモジュールである。受け付けたリクエストは一旦タスク状態管理テーブルＴ２に登録されてリクエスト実行順制御部によって適切なタイミングで実行される。
リクエスト実行制御部３６は、性能要件定義テーブルＴ１に定義されているタイムアウト要件に基づいて、タスク状態管理テーブルＴ２に登録されているリクエストの実行順を制御し、リクエストを実行するモジュールである。リクエストの種別に応じてストレージ管理プログラム内で処理が完結し、そのままリクエスト処理部からレスポンスを返却する場合と、ストレージ装置２に対してストレージ操作を実行するためにストレージ制御部３９を呼び出す場合がある。
性能要件定義テーブルＴ１は、ストレージ管理プログラム３２が扱うリクエストの性能要件を定義するテーブルである。ここで定義されているタイムアウトの値や、各リクエストの実行時間の値をもとに、リクエスト実行順制御部３６はリクエストの優先順を制御する。
タスク状態管理テーブルＴ２は、ストレージ管理プログラム３２が受け付けたリクエストの実行状態を定義するテーブルである。このテーブルを参照することで、リクエストが実行中か待機中か、また、リクエストがどのタスクに属するかわかる。
タイムアウト管理テーブルＴ３は、ストレージ管理プログラム３２が受け付けたリクエストがタイムアウトするまでの残り時間を管理するテーブルである。リクエスト実行順制御部３６は、このテーブルを使い、各リクエストがタイムアウトするまでの残り時間を管理し、リクエストの実行順を制御する。
ストレージ制御部３９は、リクエスト処理部３３からの要求を受け、ストレージ装置２で動作するストレージ制御プログラム２１に対し、ストレージ操作を実行するモジュールである。
以上が、本実施例の計算機システムの構成と、計算機システム内の管理計算機３１上で動作するストレージ管理プログラムの構成概要である。
＜データ構成＞
図４は、第１の実施例における性能要件定義テーブルＴ１の例である。性能要件定義テーブルＴ１は、ストレージ管理プログラムが提供する各リクエストの性能要件と実行時間を定義するテーブルである。性能要件定義テーブルＴ１は、属性として、リクエスト１０１、タイムアウト１０２、実行時間１０３を持つ。
リクエスト１０１は、ストレージ管理プログラムが受信したリクエストを一意に識別する属性である。リクエスト１０１の値は、リクエスト名、または、パラメータを含んだリクエスト名が格納される。リクエスト名は、ＡＰＩ名や内部処理の関数名などでもよい。また、同じリクエストでもパラメータによってタイムアウト要件や実行時間が変わるリクエストは、異なるリクエストとして定義される。テーブルＴ１の例では、ストレージ２に論理ボリューム２４を作成するためのｃｒｅａｔｅＶｏｌｕｍｅリクエスト、論理ボリューム２４をホスト計算機１に割り当てるａｌｌｏｃａｔｅＶｏｌｕｍｅ、論理ボリューム２４のスナップショット作成の事前処理を行うためのｃｒｅａｔｅＳｎａｐｓｈｏｔＰａｉｒ、スナップショットペアの作成を完了するためのｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒ、リクエストｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒのタイムアウト要件が異なるｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒ（１０）がそれぞれ定義されている。
タイムアウト１０２は、リクエストがタイムアウトする時間を示す属性である。タイムアウトの値は各リクエストの要件に応じて決定される。実行時間１０３は、リクエストの処理にかかる時間を示す属性である。実行時間１０３は、タイムアウトまでの残り時間を算出するために利用される。本実施例では、ストレージ管理者が定義するが、実際に実行したときにかかった時間を自動的に設定しても良い。
図４の１行目の例では、リクエストｃｒｅａｔｅＶｏｌｕｍｅはタイムアウト要件が６０秒で処理に１０秒かかることを表している。また、２行目の例では、リクエストｃｒｅａｔｅＶｏｌｕｍｅにパラメータarg1が指定された場合は、タイムアウトが２０秒で実行時間が１０秒であることを表している。
図５は、第１の実施例におけるタスク状態管理テーブルＴ２の例である。タスク状態管理テーブルＴ２は、ストレージ管理プログラム３２が受信した各リクエストの実行状態を管理するテーブルであり、図５では、５個のリクエストを受け付けており、同時に実行可能なリクエストが１リクエストの場合の例である。タスク状態管理テーブルＴ２は、属性として、実行順２０１、ＩＤ２０２、リクエスト２０３、タスク２０４、対象２０５、ステータス２０６、受付時刻２０７を持つ。
実行順２０１は、リクエストを実行する順序を示す属性である。値が小さい順に実行されるが、リクエスト実行順制御部４３によって実行順は適宜入れ替えられる。ＩＤ２０２は、ストレージ管理プログラム３２内でリクエストを一意に識別するためのＩＤである。リクエスト２０３は、ストレージ管理プログラム３２が受信して、実行中または待機中のリクエストを示す属性である。タスク２０４は、リクエストの元になったタスクを示す属性である。図６の例では、ＶＭに対する操作を示す“ＶＭ操作”がタスクとして登録されている。対象２０５は、タスクの実行対象を示す属性である。ＶＭ操作の対象となるＶＭがＶＭ１の場合は、“ＶＭ１”が登録される。ステータス２０６は、リクエストの状態を表す属性である。Ｒｕｎｎｉｎｇは実行中、Ｗａｉｔｉｎｇは待機中、Ｃｏｍｐｌｅｔｅｄは完了を表す。完了になったタスクは一定時間後に削除される。受付時刻２０７は、リクエストを受け付けた時刻を示す属性である。タイムアウトの算出に使われる。本実施例では秒単位までの表記だが、ミリ秒など他の単位でも良い。
図５の１行目の例は、ストレージ管理プログラム３２が、ホスト計算機１上でＶＭ１に対する操作の延長で発行されたａｌｌｏｃａｔｅＶｏｌｕｍｅリクエストを１０１５年６月２０日１０時００分００秒に受け付け、実行中であることを表している。また、２行目は、ＶＭ２の操作の延長で発行されたｃｒｅａｔｅＶｏｌｕｍｅリクエストを、その７秒後に受け付けて、実行開始を待機していることを表す。
図６は、第１の実施例におけるタイムアウト管理テーブルＴ３の例である。タイムアウト管理テーブルＴ３は、ストレージ管理プログラム３２のリクエスト実行順制御部４３が、各リクエストのタイムアウト状況を判定し、リクエストの実行順序を入れ替えるために使用するテーブルであり、タイムアウト管理テーブルＴ３は、属性として、ＩＤ３０１、リクエスト３０２、残り時間（実行前）３０３、残り時間（実行完了時）３０４、残り時間（先行リクエスト完了時）３０５を持つ。図６は、実行待機中のリクエストが４個あり、ＩＤ１０００１のｃｒｅａｔｅＶｏｌｕｍｅが完了した時刻１０時００分１０秒の時点の状態、つまり、ＩＤ１０００２のリクエストを受け付けてから３秒経過した状態の例である。
ＩＤ３０１は、リクエストを一意に識別するＩＤでタスク管理テーブルＴ２のＩＤ２０２に対応する。リクエスト３０２はリクエストを表す名称で、タスク管理テーブルＴ２のリクエスト２０３に対応する。
残り時間（実行前）３０３は、リクエストがタイムアウトするまでに残されている時間を示す属性である。この値が負の場合、タイムアウト計算時点でそのリクエストが既にタイムアウトしているということを意味する。ＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅを例に説明すると、性能要件定義テーブルＴ１のｃｒｅａｔｅＶｏｌｕｍｅのタイムアウトの値が６０秒でリクエスト受付から３秒経過しているため５７秒が設定される。
残り時間（実行完了時）３０４は、その行のリクエストが完了した時点でタイムアウトするまでに残されている時間を示す属性である。この値が負の場合、リクエストが実行中にタイムアウトすることを意味する。ＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅを例に説明すると、性能要件定義テーブルＴ１のｃｒｅａｔｅＶｏｌｕｍｅの実行時間属性１０３の値が１０秒で、実行前の残り時間３０３が５７秒のため、実行完了時の残り時間は４７秒になる。
残り時間（先行リクエスト完了時）３０５は、待機中のリクエストの中で実行順序が先頭のリクエストを実行した場合の、先頭リクエスト完了時点のタイムアウトするまでに残されている時間を示す属性である。この値がマイナスの場合、実行待機中の先頭のリクエストを実行すると、その実行中にタイムアウトすることを意味する。ＩＤ１０００４のｓｐｌｉｔＳｎａｐｓｈｏｔＰａｉｒ（１０）を例に説明すると、実行前の残り時間が８秒で、待機中の先頭のリクエストのであるＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅの実行時間が１０秒であるため、ＩＤ１０００２のｃｒｅａｔｅＶｏｌｕｍｅを実行すると－２秒になりタイムアウトすることがわかる。
＜ユーザーインタフェース＞
図７は、第１の実施例におけるストレージ管理プログラム３２が処理する各リクエストの性能要件と実行時間を定義するリクエスト性能要件設定画面Ｇ１の例である。リクエスト性能要件設定画面Ｇ１は、管理インターフェース６１の画面の一つである。
リクエスト性能要件設定画面Ｇ１のリクエスト７０１は、ストレージ管理プログラム３２がサポートするリクエスト種別の一覧であり、性能要件定義テーブルＴ１のリクエスト属性１０１に対応する。同様に、タイムアウト７０２は、タイムアウト属性１０２に対応し、実行時間７０３は、実行時間属性１０３に対応する。性能要件定義テーブルＴ１に登録されている値が表示され、同様に、ここで設定した値は、性能要件定義テーブルＴ１に登録される。
＜処理フロー＞
図８は、第１の実施例におけるホスト制御プログラムがリクエストを発行するときの、各コンポーネント間の処理の関係を示すシーケンス図である。ホスト管理プログラム３１でユーザがＶＭ操作のタスクを実行すると、そのタスクがホスト制御プログラム１１に通知され、そのタスクに応じた処理がホスト制御プログラム１１で実行される。
ホスト制御プログラム１１がストレージ管理プログラム３２に対してリクエストを実行すると（Ｓ８０１）、リクエスト処理部３５がそのリクエストは受け付けてリクエストをタスク状態管理テーブルＴ２に登録し（Ｓ８０２）、そのリクエストが実行可能になるまで待機させる（Ｓ８０３）。その後、実行中のリクエストが完了して待機中のリクエストが実行可能になったときに、待機中の全リクエストに対して実行順が制御されてから（Ｓ８０４）、リクエストが実行される（Ｓ８０５）。
リクエスト処理部３５から要求を受け付けたストレージ制御部３９は、そのリクエストをストレージ装置２上のストレージ制御プログラム２１に対して要求し（Ｓ８０６）、実行結果を取得すると（Ｓ８０７）、リクエスト処理部３５に結果を返す（Ｓ８０８）。
結果を受け取ったリクエスト処理部３５は、ホスト制御プログラム１１にリクエストの実行結果を返す。
ホスト制御プログラム１１は結果を受け取ると（Ｓ８０９）、タスクを完了するかタスクに応じた次のリクエストを実行する（Ｓ８１０）。
本処理では、ホスト制御プログラム１１がリクエストを送信しているが、ホスト管理プログラム３１がタスク実行の延長で直接ストレージ管理プログラム３２にリクエストを発行する構成を取っても良い。Ｓ８０２の処理の詳細を図９で、Ｓ８０４の処理の詳細を図１０で、それぞれ説明する。
図９は、第１の実施例におけるリクエスト登録処理の処理フローを示す図である。リクエスト処理部３０が、ホスト制御プログラム１１からリクエストを受け付けると、リクエストの情報をタスク状態管理テーブルＴ２に登録する。図９のリクエスト登録処理Ｓ９０２に該当する。本実施例では、リクエストはＶＭ作成、起動などのＶＭに関連する操作の延長で発行されるリクエストで、リクエストは、そのリクエストの種類を決定するリクエスト名とパラメータを含み、パラメータにはどのＶＭに関連する操作か特定するための値が含まれるものを例として説明する。その値は、例えば、ＶＭ名やＶＭのＵＵＩＤ(Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ) である。
リクエスト処理部３０が、ホスト制御プログラム１１からリクエストを受け付けると（Ｓ９０１）、リクエスト処理部３０はそのリクエストからリクエスト名、リクエストのパラメータを取り出す（Ｓ９０２）。リクエスト名とパラメータをもとに性能要件定義テーブルＴ１のリクエスト属性に定義されているリクエストを決定する（Ｓ９０３）。また、同じくリクエストのパラメータからリクエストが対象としているＶＭを特定し、どのＶＭに関連するタスクか決定する（Ｓ９０４）。本実施例では、タスクが“ＶＭ操作”、操作対象が＜ＶＭ名＞である。
対象ＶＭとタスクを決定したら、次はそのタスクがタスク状態管理テーブルＴ２に登録済みかどうか確認する（Ｓ９０５）。対象属性２０５にタスクの実行対象と同じＶＭが含まれる場合に登録済みと判定する。
タスクが登録済みの場合（Ｓ９０５：ＹＥＳ）、その登録されているタスクのステータス属性２０６の値がＲｕｎｎｉｎｇまたはＷａｉｔｉｎｇのレコードしか無いならば（Ｓ９０５：Ｎｏ）、そのレコードの中で実行順２０１が最後のレコードの次に挿入する。このとき挿入した箇所より後のレコードの実行順は１増える。ステータス属性２０６の値がＣｏｍｐｌｅｔｅｄのレコードであれば、新しいＩＤを生成しそのレコードの実行順２０１以外の各属性を更新する（Ｓ９０６）。例えば、ＶＭ１操作に対するｃｒｅａｔｅＶｏｌｕｍｅリクエストのステータスがＣｏｍｐｌｅｔｅｄの場合、次にａｌｌｏｃａｔｅＶｏｌｕｍｅリクエストがきた場合は、ＩＤ２０２に新しいＩＤを生成して設定し、リクエスト２０３に新しくきたリクエストであるａｌｌｏｃａｔｅｖｏｌｕｍｅを設定し、ステータス２０６にＷａｉｔｉｎｇを設定し、受付時刻２０７にａｌｌｏｃａｔｅｖｏｌｕｍｅを受け付けた時刻を設定する。
リクエスト処理部３０が、ホスト制御プログラム１１からリクエストを受け付けると（Ｓ９０１）、リクエスト処理部３０はそのリクエストからリクエスト名、リクエストのパラメータを取り出す（Ｓ９０２）。リクエスト名とパラメータをもとに性能要件定義テーブルＴ１のリクエスト属性に定義されているリクエストを決定する（Ｓ９０３）。また、同じくリクエストのパラメータからリクエストが対象としているＶＭを特定し、どのＶＭに関連するタスクか決定する（Ｓ９０４）。本実施例では、タスクが“ＶＭ操作”、操作対象が＜ＶＭ名＞である。
対象ＶＭとタスクを決定したら、次はそのタスクがタスク状態管理テーブルＴ２に登録済みかどうか確認する（Ｓ９０５）。対象属性２０５にタスクの実行対象と同じＶＭが含まれる場合に登録済みと判定する。
タスクが登録済みの場合（Ｓ９０５：ＹＥＳ）、その登録されているタスクのステータス属性２０６の値がＲｕｎｎｉｎｇまたはＷａｉｔｉｎｇのレコードしか無いならば（Ｓ９０５：Ｎｏ）、そのレコードの中で実行順２０１が最後のレコードの次に挿入する。このとき挿入した箇所より後のレコードの実行順は１増える。ステータス属性２０６の値がＣｏｍｐｌｅｔｅｄのレコードであれば、新しいＩＤを生成しそのレコードの実行順２０１以外の各属性を更新する（Ｓ９０６）。例えば、ＶＭ１操作に対するｃｒｅａｔｅＶｏｌｕｍｅリクエストのステータスがＣｏｍｐｌｅｔｅｄの場合、次にａｌｌｏｃａｔｅＶｏｌｕｍｅリクエストがきた場合は、ＩＤ２０２に新しいＩＤを生成して設定し、リクエスト２０３に新しくきたリクエストであるａｌｌｏｃａｔｅｖｏｌｕｍｅを設定し、ステータス２０６にＷａｉｔｉｎｇを設定し、受付時刻２０７にａｌｌｏｃａｔｅｖｏｌｕｍｅを受け付けた時刻を設定する。
タスクが登録されていない場合（Ｓ９０５：Ｎｏ）、同様に新しいＩＤを生成し、タスク状態管理テーブルＴ２で実行順２０１の最大値＋１の値を設定して新規レコードを追加する（Ｓ９０７）。タスクの有無によってリクエストの実行順を制御することにより、同一ＶＭ操作に関するリクエストを優先的に処理することが可能となる。
以上の処理により、リクエスト登録部４２がリクエストをタスク状態管理テーブルＴ２に登録する処理が完了する。
図１０は、第１の実施例におけるリクエスト実行順制御処理の処理フローを示す図である。リクエスト実行順制御部４３が、リクエストの実行状態を監視しており、実行中のリクエストが完了して待機中の次のリクエストを実行するときに本処理が実行される。完了したリクエストは、リクエスト送信元にリクエストの実行結果が返却された後、タスク状態管理テーブルＴ２のステータス属性２０６をＣｏｍｐｌｅｔｅｄに変更し、Ｃｏｍｐｌｅｔｅｄのまま一定時間経過すると、タスク状態管理テーブルＴ２から削除される。
まず、リクエスト実行順制御部４３が呼び出されると、待機中の全リクエストに対して、リクエストがタイムアウトするまでの現在時刻からの残り時間ｔ１を計算し、タイムアウト管理テーブルＴ３の残り時間（実行前）属性３０３を更新する（Ｓ１００１）。同じく待機中の全リクエストに対して、現在時刻から待機中のリクエストを実行したと仮定した場合に、待機中のリクエスト自身が完了した時点の残り時間ｔ２を計算し、残り時間（実行完了時）属性３０４を更新する。残り時間ｔ１とｔ２がマイナスのリクエストがある場合には（Ｓ１００３：Ｙｅｓ）、それらのリクエストは実行開始前の時点、または、実行中にタイムアウトすることになるため、タイムアウト管理テーブルＴ３から該当するリクエストを削除し、そのリクエストは実行せずに、削除したリクエストが属するタスクの要求元にタイムアウトを返却する（Ｓ１００４）。残り時間ｔ１とｔ２が０秒以上の場合は、そのまま次の処理に移る（Ｓ１００６）。
次に、実行するリクエストを決定するため、実行順が先頭の、すなわち実行順２０１が１のリクエストを実行した場合の各待機中リクエストの残り時間ｔ３を計算し、残り時間（先頭リクエスト完了時）属性３０５を更新する（Ｓ１００５）。
以上の処理により、リクエスト登録部４２がリクエストをタスク状態管理テーブルＴ２に登録する処理が完了する。
図１０は、第１の実施例におけるリクエスト実行順制御処理の処理フローを示す図である。リクエスト実行順制御部４３が、リクエストの実行状態を監視しており、実行中のリクエストが完了して待機中の次のリクエストを実行するときに本処理が実行される。完了したリクエストは、リクエスト送信元にリクエストの実行結果が返却された後、タスク状態管理テーブルＴ２のステータス属性２０６をＣｏｍｐｌｅｔｅｄに変更し、Ｃｏｍｐｌｅｔｅｄのまま一定時間経過すると、タスク状態管理テーブルＴ２から削除される。
まず、リクエスト実行順制御部４３が呼び出されると、待機中の全リクエストに対して、リクエストがタイムアウトするまでの現在時刻からの残り時間ｔ１を計算し、タイムアウト管理テーブルＴ３の残り時間（実行前）属性３０３を更新する（Ｓ１００１）。同じく待機中の全リクエストに対して、現在時刻から待機中のリクエストを実行したと仮定した場合に、待機中のリクエスト自身が完了した時点の残り時間ｔ２を計算し、残り時間（実行完了時）属性３０４を更新する。残り時間ｔ１とｔ２がマイナスのリクエストがある場合には（Ｓ１００３：Ｙｅｓ）、それらのリクエストは実行開始前の時点、または、実行中にタイムアウトすることになるため、タイムアウト管理テーブルＴ３から該当するリクエストを削除し、そのリクエストは実行せずに、削除したリクエストが属するタスクの要求元にタイムアウトを返却する（Ｓ１００４）。残り時間ｔ１とｔ２が０秒以上の場合は、そのまま次の処理に移る（Ｓ１００６）。
次に、実行するリクエストを決定するため、実行順が先頭の、すなわち実行順２０１が１のリクエストを実行した場合の各待機中リクエストの残り時間ｔ３を計算し、残り時間（先頭リクエスト完了時）属性３０５を更新する（Ｓ１００５）。
ｔ３がマイナスのリクエストが無い場合（Ｓ１００６：Ｎｏ）、先頭のリクエストをそのまま実行しても他のリクエストはまだタイムアウトしないため、今の実行順のまま実行する（Ｓ１０１２）。
ｔ３がマイナスのリクエストがある場合（Ｓ１００６：Ｙｅｓ）、つまり、待機中の先頭のリクエストを実行するとタイムアウトするリクエストがある場合、ｔ３がマイナスのリクエストから実行順が先頭のリクエストを選択し、そのリクエストを先に実行した場合の各リクエストとの残り時間ｔ３’を計算する（Ｓ１００９）。ｔ３’がマイナスのリクエストがある場合（Ｓ１０１０：Ｎｏ）、リクエストを入れ替えてもタイムアウトが解消されないため、もとの順序のまま、つまり、ＶＭ操作順を優先して実行する（Ｓ１０１２）。また、ｔ３がマイナスのリクエストを削除し、削除したリクエストが属するタスクの要求基にタイムアウトを返却する。ｔ３’がマイナスのリクエストが無い場合、順序入れ替えによりタイムアウトが発生しなくなるため、入れ替えたリクエストを先に実行する（Ｓ１０１１）。
以上により、各リクエストのタイムアウト要件と実行時間をもとに、リクエストの実行順序が制御され、タイムアウトの発生を抑止することが可能となる。 なお、各モジュールによる処理は、集積回路化などして、それを行う処理部としてハードウェアで実現する事もできる。これについては以下の実施例についても同様である。
（第２の実施形態）
次に、図１１から図１４を用いて本発明の第２の実施例を詳細に説明する。第２の実施例は、第１の実施例においてタスクを構成する各リクエストのタイムアウト要件をもとにリクエスト実行順を優先制御していた処理が、タスク自体のタイムアウト要件に基づいてリクエスト実行順を優先制御する場合の例である。システム構成は第１の実施例と共通である。以下、第１の実施例との差分を中心に説明する。
図１１は、第２の実施例におけるストレージ管理プログラム３２のモジュール構成図である。第１の実施例の図３における各コンポーネントに加え、タスク管理部３７とタスク定義テーブルＴ４を備える。
タスク管理部３７は、ホスト管理プログラム３１がサポートする各タスクとストレージ管理プログラム３２がサポートする各リクエストの対応関係、及び、各タスクのタイムアウト要件を参照するモジュールである。
タスク定義テーブルＴ４は、各タスクと各リクエストの対応関係を定義し、各タスクのタイムアウト要件を管理するテーブルである。
第２の実施例では、タスクは、ホスト管理プログラム３１とホスト制御プログラム１１で実行されるＶＭに関連する操作であり、ＶＭ操作には、ＶＭ作成、ＶＭ起動、ＶＭのスナップショット取得などの操作が該当する。リクエストは、そのＶＭ操作の延長で、ストレージ管理プログラム３２で実行されるＶＭに関連する論理ボリュームの作成やホストへのボリューム割り当てなどの操作が該当する。
図１２は、第２の実施例におけるタスク定義テーブルＴ４の例である。タスク定義テーブルＴ４は、ホスト管理プログラム１１が提供する各タスクの性能要件を定義するテーブルである。タスク定義テーブルＴ４は、属性として、タスク４０１、リクエスト４０２、タイムアウト４０３を持つ。
タスク４０１は、ホスト管理プログラム１１におけるタスクを一意に識別する属性である。各ＶＭ操作を示す名前が設定される。
リクエスト４０２は、タスク４０１の延長で実行されるストレージ管理プログラム３２における各リクエストを示す属性である。リクエスト４０２の値は、性能要件定義テーブルＴ１に定義されるリクエストの値を、タスク実行時に発行される順にカンマ区切りで連結した値が設定される。
タイムアウト４０３は、タスク４０１に設定されているタスクのタイムアウト要件を示す属性である。タイムアウトの値はホスト管理プログラム３１やホスト制御プログラム１１の仕様に基づいて決定される値や、ＶＭ操作のユーザビリティや運用面を考慮した値が設定される。
図１２の１行目の例では、ホスト管理プログラム３１でＶＭ作成タスクが実行されると、ストレージ管理プログラム３２に対し、リクエストｃｒｅａｔｅＶｏｌｕｍｅ１、ａｌｌｏｃａｔｅＶｏｌｕｍｅの順にリクエストが発行され、そのＶＭ作成タスクのタイムアウトが６０秒、つまり、リクエストｃｒｅａｔｅＶｏｌｕｍｅ１の受け付けから、ａｌｌｏｃａｔｅＶｏｌｕｍｅ完了までの合計時間が６０秒以内である必要があることを示している。図１２の２行目の例では、ホスト管理プログラム３１でＶＭ起動タスクが実行されると、ストレージ管理プログラム３２に対し、リクエストｃｒｅａｔｅＶｏｌｕｍｅ２、ａｌｌｏｃａｔｅＶｏｌｕｍｅの順にリクエストが発行され、そのＶＭ起動タスクのタイムアウトが３０秒、つまり、リクエストｃｒｅａｔｅＶｏｌｕｍｅ２の受け付けから、ａｌｌｏｃａｔｅＶｏｌｕｍｅ完了までの合計時間が３０秒以内である必要があることを示している。ｃｒｅａｔｅＶｏｌｕｍｅ１とｃｒｅａｔｅＶｏｌｕｍｅ２は、ｃｒｅａｔｅＶｏｌｕｍｅリクエストに指定されたパラメータの違いにより別のリクエストとして扱われていることを示す。
ｔ３がマイナスのリクエストがある場合（Ｓ１００６：Ｙｅｓ）、つまり、待機中の先頭のリクエストを実行するとタイムアウトするリクエストがある場合、ｔ３がマイナスのリクエストから実行順が先頭のリクエストを選択し、そのリクエストを先に実行した場合の各リクエストとの残り時間ｔ３’を計算する（Ｓ１００９）。ｔ３’がマイナスのリクエストがある場合（Ｓ１０１０：Ｎｏ）、リクエストを入れ替えてもタイムアウトが解消されないため、もとの順序のまま、つまり、ＶＭ操作順を優先して実行する（Ｓ１０１２）。また、ｔ３がマイナスのリクエストを削除し、削除したリクエストが属するタスクの要求基にタイムアウトを返却する。ｔ３’がマイナスのリクエストが無い場合、順序入れ替えによりタイムアウトが発生しなくなるため、入れ替えたリクエストを先に実行する（Ｓ１０１１）。
以上により、各リクエストのタイムアウト要件と実行時間をもとに、リクエストの実行順序が制御され、タイムアウトの発生を抑止することが可能となる。 なお、各モジュールによる処理は、集積回路化などして、それを行う処理部としてハードウェアで実現する事もできる。これについては以下の実施例についても同様である。
（第２の実施形態）
次に、図１１から図１４を用いて本発明の第２の実施例を詳細に説明する。第２の実施例は、第１の実施例においてタスクを構成する各リクエストのタイムアウト要件をもとにリクエスト実行順を優先制御していた処理が、タスク自体のタイムアウト要件に基づいてリクエスト実行順を優先制御する場合の例である。システム構成は第１の実施例と共通である。以下、第１の実施例との差分を中心に説明する。
図１１は、第２の実施例におけるストレージ管理プログラム３２のモジュール構成図である。第１の実施例の図３における各コンポーネントに加え、タスク管理部３７とタスク定義テーブルＴ４を備える。
タスク管理部３７は、ホスト管理プログラム３１がサポートする各タスクとストレージ管理プログラム３２がサポートする各リクエストの対応関係、及び、各タスクのタイムアウト要件を参照するモジュールである。
タスク定義テーブルＴ４は、各タスクと各リクエストの対応関係を定義し、各タスクのタイムアウト要件を管理するテーブルである。
第２の実施例では、タスクは、ホスト管理プログラム３１とホスト制御プログラム１１で実行されるＶＭに関連する操作であり、ＶＭ操作には、ＶＭ作成、ＶＭ起動、ＶＭのスナップショット取得などの操作が該当する。リクエストは、そのＶＭ操作の延長で、ストレージ管理プログラム３２で実行されるＶＭに関連する論理ボリュームの作成やホストへのボリューム割り当てなどの操作が該当する。
図１２は、第２の実施例におけるタスク定義テーブルＴ４の例である。タスク定義テーブルＴ４は、ホスト管理プログラム１１が提供する各タスクの性能要件を定義するテーブルである。タスク定義テーブルＴ４は、属性として、タスク４０１、リクエスト４０２、タイムアウト４０３を持つ。
タスク４０１は、ホスト管理プログラム１１におけるタスクを一意に識別する属性である。各ＶＭ操作を示す名前が設定される。
リクエスト４０２は、タスク４０１の延長で実行されるストレージ管理プログラム３２における各リクエストを示す属性である。リクエスト４０２の値は、性能要件定義テーブルＴ１に定義されるリクエストの値を、タスク実行時に発行される順にカンマ区切りで連結した値が設定される。
タイムアウト４０３は、タスク４０１に設定されているタスクのタイムアウト要件を示す属性である。タイムアウトの値はホスト管理プログラム３１やホスト制御プログラム１１の仕様に基づいて決定される値や、ＶＭ操作のユーザビリティや運用面を考慮した値が設定される。
図１２の１行目の例では、ホスト管理プログラム３１でＶＭ作成タスクが実行されると、ストレージ管理プログラム３２に対し、リクエストｃｒｅａｔｅＶｏｌｕｍｅ１、ａｌｌｏｃａｔｅＶｏｌｕｍｅの順にリクエストが発行され、そのＶＭ作成タスクのタイムアウトが６０秒、つまり、リクエストｃｒｅａｔｅＶｏｌｕｍｅ１の受け付けから、ａｌｌｏｃａｔｅＶｏｌｕｍｅ完了までの合計時間が６０秒以内である必要があることを示している。図１２の２行目の例では、ホスト管理プログラム３１でＶＭ起動タスクが実行されると、ストレージ管理プログラム３２に対し、リクエストｃｒｅａｔｅＶｏｌｕｍｅ２、ａｌｌｏｃａｔｅＶｏｌｕｍｅの順にリクエストが発行され、そのＶＭ起動タスクのタイムアウトが３０秒、つまり、リクエストｃｒｅａｔｅＶｏｌｕｍｅ２の受け付けから、ａｌｌｏｃａｔｅＶｏｌｕｍｅ完了までの合計時間が３０秒以内である必要があることを示している。ｃｒｅａｔｅＶｏｌｕｍｅ１とｃｒｅａｔｅＶｏｌｕｍｅ２は、ｃｒｅａｔｅＶｏｌｕｍｅリクエストに指定されたパラメータの違いにより別のリクエストとして扱われていることを示す。
図１５は、第２の実施例におけるタスク状態管理テーブルＴ２の例である。第１の実施例の図５では、タスク属性２０４に“ＶＭ操作”の固定値が登録されていたが、第２の実施例では、リクエストの実行契機となったＶＭ操作が登録される点で異なる。ＶＭ作成に対応するリクエストが実行された場合には、タスク属性２０４に“ＶＭ作成”が登録される。登録処理については、図１３で説明する。
図１３は、第２の実施例におけるリクエスト登録処理を示す図である。第１の実施例との違いは、第１の実施例では、Ｓ９０４で、リクエストが対象としているＶＭをもとに「そのＶＭに対する操作」をタスクとして決定していたが、第２の実施例では、タスク定義テーブルＴ４の定義に基づいて、受け付けたリクエストがどのＶＭ操作に応じたタスクに関するか決定する点で異なる。
リクエスト処理部３０が、ホスト制御プログラム１１からリクエストを受け付けると（Ｓ１３０１）、リクエスト処理部３０はそのリクエストからリクエスト名、リクエストのパラメータを取り出す（Ｓ１３０２）。リクエスト名とパラメータをもとに性能要件定義テーブルＴ１のリクエスト属性に定義されているリクエストを決定する（Ｓ１３０３）。例えば、図１２に定義されているＶＭ作成タスクが実行された場合、最初に受け付けるリクエストのリクエスト種別はｃｒｅａｔｅＶｏｌｕｍｅ１になり、ｃｒｅａｔｅＶｏｌｕｍｅ１が完了して、次に受け付けるリクエストのリクエスト種別はａｌｌｏｃａｔｅＶｏｌｕｍｅになる。
リクエスト処理部３０が、ホスト制御プログラム１１からリクエストを受け付けると（Ｓ１３０１）、リクエスト処理部３０はそのリクエストからリクエスト名、リクエストのパラメータを取り出す（Ｓ１３０２）。リクエスト名とパラメータをもとに性能要件定義テーブルＴ１のリクエスト属性に定義されているリクエストを決定する（Ｓ１３０３）。例えば、図１２に定義されているＶＭ作成タスクが実行された場合、最初に受け付けるリクエストのリクエスト種別はｃｒｅａｔｅＶｏｌｕｍｅ１になり、ｃｒｅａｔｅＶｏｌｕｍｅ１が完了して、次に受け付けるリクエストのリクエスト種別はａｌｌｏｃａｔｅＶｏｌｕｍｅになる。
その後、同じくリクエストのパラメータからリクエストが対象としているＶＭを特定し、どのＶＭに関連するタスクか決定する（Ｓ１３０４）。ＶＭ１を起動するタスクが実行された場合には、対象ＶＭはＶＭ１になる。
受け付けたリクエストのリクエスト種別ｒｅｑ１と対象ＶＭを決定したら、次はそのリクエストが対象とするＶＭに関連するタスクがタスク状態管理テーブルＴ２に登録済みかどうか確認する（Ｓ１３０５）。対象属性２０５の値にＶＭ名が設定されており、ステータス属性２０６の値がＣｏｍｐｌｅｔｅｄのレコードがある場合に登録済みと判定する。
対象ＶＭのタスクが登録済みでは無い場合（Ｓ１３０５：Ｎｏ）、タスク定義テーブルＴ４に定義されている各タスクの先頭のリクエストを受け付けたと判断し、のタスク定義テーブルＴ４のリクエスト属性４０２を参照し、カンマで連結されているリクエストの先頭の文字列が、Ｓ１３０３で取得したリクエストｒｅｑ１と一致するレコードを検索してタスクｔａｓｋ１を特定する（Ｓ１３０６）。ｒｅｑ１がｃｒｅａｔｅＶｏｌｕｍｅ１の場合、ｃｒｅａｔｅＶｏｌｕｍｅ１をリクエストの先頭に持つＶＭ作成がｔａｓｋ１になる。受け付けたリクエストに対応するタスクを特定したら、新しいＩＤを生成し、タスク状態管理テーブルＴ２で実行順２０１の最大値＋１の値を設定して、リクエストｒｅｑ１、タスクｔａｓｋ１、ステータスＷａｉｔｉｎｇ、受け付け時刻に現在時刻を持つ新規レコードを追加する（Ｓ１３０７）。
対象ＶＭのタスクが登録済みの場合（Ｓ１３０５：Ｙｅｓ）、登録されているタスクのレコードのリクエスト属性２０３の値ｒｅｑ０を取得し、タスク定義テーブルＴ４のリクエスト属性４０２が、登録済みのリクエストｒｅｑ０と受け付けたリクエストｒｅｑ１をカンマで連結した値で定義されているタスク属性４０１を取得する（Ｓ１３０８）。例えば、ＶＭ１に対するＶＭ作成タスクの“ｃｒｅａｔｅＶｏｌｕｍｅ１“リクエストがタスク状態管理テーブルＴ２に登録されている状態で、新たにＶＭ１に対する”ａｌｌｏｃａｔｅＶｏｌｕｍｅ“リクエストを受け付けた場合、“ｃｒｅａｔｅＶｏｌｕｍｅ１，ａｌｌｏｃａｔｅＶｏｌｕｍｅ”をリクエスト属性の値に持つタスク“ＶＭ作成”をタスク定義テーブルＴ４から取得する。３つ以上のリクエストで定義されているタスクの場合も同様に、タスク状態管理テーブルＴ２にリクエスト“ｒｅｑ０，ｒｅｑ１”が登録されていて、リクエスト“ｒｅｑ２”を受け付けた場合には、タスク定義テーブルＴ４に“ｒｅｑ０，ｒｅｑ１，ｒｅｑ２”で定義されているタスクを取得する。
最後に、Ｓ１３０５で特定したレコードのリクエスト属性に“ｒｅｑ０，ｒｅｑ１”を設定し、タスク属性にＳ１３０８で新たに決定したタスクを設定し、ステータス属性にＷａｉｔｉｎｇを設定する。第１の実施例では受け付け時刻も更新したが、第２の実施例ではタイムアウトをタスク基準で判定するため、新たなリクエストを受け付けてもタスクの開始時刻は変わらないことから、受け付け時刻は更新しない。なお、Ｓ１３０８、Ｓ１３０９の処理でタスク属性の値も更新するのは、Ｓ１３０６で複数のタスクの候補がありタスクが一つに絞れなかったときに、Ｓ１３０８で先頭のリクエストだけではなくその前に受け付けた同一ＶＭに対するリクエストの情報も加えてタスクを判定することができ、タスク判定の精度を高める効果がある。
以上の処理により、リクエスト登録部４２がタスク定義テーブルT４の情報に基づいて、リクエストとタスクをタスク状態管理テーブルＴ２に登録、または、更新する処理が完了する。
図１４は、第２の実施例における、リクエスト実行順制御処理の処理フローを示す図である。第１の実施例との違いは、タイムアウトの残り時間の算出に、性能要件定義テーブルＴ１に定義されているリクエストのタイムアウト時間を使用するのではなく、タスク定義テーブルＴ４に定義されているタスクのタイムアウト時間を使ってタイムアウトの残り時間を算出する点である。
まず、リクエスト実行順制御部４３が呼び出されると、待機中の全リクエストに対して、タスクがタイムアウトするまでの現在時刻からの残り時間ｔ１を計算し、タイムアウト管理テーブルＴ３の残り時間（実行前）３０３を更新する（Ｓ１４０１）。ｔ１は、タスクの受け付け開始から現時時刻までの経過時間を、タスクのタイムアウト値から引いて求める。例えば、タスク状態管理テーブルT２において、あるリクエスト１のタスク属性の値が”ＶＭ作成”だった場合、タスク定義テーブルT４のタスク属性４０１が”ＶＭ作成”のレコードのタイムアウト属性４０３を参照してタイムアウト値６０秒を取得したのち、リクエスト１の受付時刻から現在時刻までの経過時間を求め、６０秒から引いてｔ１を計算する。
次に、同じく待機中の全リクエストに対して、現在時刻からそのタスクに含まれる未実行の残りの全リクエストを実行したと仮定した場合に、それらのリクエストが全て実行した時点の残り時間ｔ２を計算し、残り時間（実行完了時）３０４を更新する。例えば、リクエストがｃｒｅａｔｅＶｏｌｕｍｅ１、タスクがＶＭ作成、ステータスがＷａｉｔｉｎｇの場合、タスク定義テーブルＴ４のＶＭ作成タスクのレコードのリクエスト属性４０２を参照してａｌｌｏｃａｔｅＶｏｌｕｍｅが残っていることを特定し、性能要件定義テーブルＴ１から、未実行のｃｒｅａｔｅＶｏｌｕｍｅ１とａｌｌｏｃａｔｅＶｏｌｕｍｅの実行時間属性を参照し、現時点のタスクの残り時間ｔ１からそれらの未実行リクエストの実行時間の合計値を引いてｔ２を求める。第１の実施例はリクエスト単体の実行時間だけで完了時点の残り時間を計算したが、本実施例では、未実行のリクエストの実行時間をもとに、タスクの完了時点の残り時間を計算している点が異なる。
以上の処理により、リクエスト登録部４２がタスク定義テーブルT４の情報に基づいて、リクエストとタスクをタスク状態管理テーブルＴ２に登録、または、更新する処理が完了する。
図１４は、第２の実施例における、リクエスト実行順制御処理の処理フローを示す図である。第１の実施例との違いは、タイムアウトの残り時間の算出に、性能要件定義テーブルＴ１に定義されているリクエストのタイムアウト時間を使用するのではなく、タスク定義テーブルＴ４に定義されているタスクのタイムアウト時間を使ってタイムアウトの残り時間を算出する点である。
まず、リクエスト実行順制御部４３が呼び出されると、待機中の全リクエストに対して、タスクがタイムアウトするまでの現在時刻からの残り時間ｔ１を計算し、タイムアウト管理テーブルＴ３の残り時間（実行前）３０３を更新する（Ｓ１４０１）。ｔ１は、タスクの受け付け開始から現時時刻までの経過時間を、タスクのタイムアウト値から引いて求める。例えば、タスク状態管理テーブルT２において、あるリクエスト１のタスク属性の値が”ＶＭ作成”だった場合、タスク定義テーブルT４のタスク属性４０１が”ＶＭ作成”のレコードのタイムアウト属性４０３を参照してタイムアウト値６０秒を取得したのち、リクエスト１の受付時刻から現在時刻までの経過時間を求め、６０秒から引いてｔ１を計算する。
次に、同じく待機中の全リクエストに対して、現在時刻からそのタスクに含まれる未実行の残りの全リクエストを実行したと仮定した場合に、それらのリクエストが全て実行した時点の残り時間ｔ２を計算し、残り時間（実行完了時）３０４を更新する。例えば、リクエストがｃｒｅａｔｅＶｏｌｕｍｅ１、タスクがＶＭ作成、ステータスがＷａｉｔｉｎｇの場合、タスク定義テーブルＴ４のＶＭ作成タスクのレコードのリクエスト属性４０２を参照してａｌｌｏｃａｔｅＶｏｌｕｍｅが残っていることを特定し、性能要件定義テーブルＴ１から、未実行のｃｒｅａｔｅＶｏｌｕｍｅ１とａｌｌｏｃａｔｅＶｏｌｕｍｅの実行時間属性を参照し、現時点のタスクの残り時間ｔ１からそれらの未実行リクエストの実行時間の合計値を引いてｔ２を求める。第１の実施例はリクエスト単体の実行時間だけで完了時点の残り時間を計算したが、本実施例では、未実行のリクエストの実行時間をもとに、タスクの完了時点の残り時間を計算している点が異なる。
いずれかの値がマイナスの場合（Ｓ１４０３：Ｙｅｓ）、タスクが既にタイムアウトしているか、または、他のリクエストに邪魔されずタスクに含まれる残りの未実行リクエストを実行してもタイムアウトするということなので、この時点でタイムアウトを返却する（Ｓ１４０４）。タスクがタイムアウトしない場合（Ｓ１４０５：Ｙｅｓ）、先頭リクエストを実行した時点でタイムアウトするタスクが無いか、または、他のリクエストを先に実行した時点でタスクがタイムアウトしないかｔ３、ｔ３’を比較してリクエストの優先度を入れ替える。図１１と同様の処理になるため説明を省略する。
以上により、タスクのタイムアウト時間と各リクエストの実行時間をもとに、タスクをタイムアウトさせないようにリクエストの実行順序が制御され、タスクのタイムアウトの発生を抑止することが可能となる。
以上により、タスクのタイムアウト時間と各リクエストの実行時間をもとに、タスクをタイムアウトさせないようにリクエストの実行順序が制御され、タスクのタイムアウトの発生を抑止することが可能となる。
なお、以上に記載した実施例で示したプログラムは、あらかじめ計算機内の記憶装置や外部記憶装置に格納されていても良いし、着脱可能な記憶媒体や通信媒体(有線、無線、光などのネットワーク、又はそのネットワーク上の搬送波やデジタル信号)を介して、必要なときに外部記憶装置に導入されても良い。
１：ホスト計算機
１０：メモリ
１１：ホスト制御プログラム
１２：入出力装置
１３：ＣＰＵ
１４：ストレージ
１５：管理インターフェース
１６：データインタフェース
２：ストレージ装置
２０：メモリ
２１：ストレージ制御プログラム
２２：ＣＰＵ
２３：ディスク
２４：論理ボリューム
２５：管理インターフェース
２６：データインタフェース
３：管理計算機
３１：ホスト管理プログラム
３２：ストレージ管理プログラム
３３：リクエスト処理部
３４：タイムアウト管理部
３５：リクエスト登録部
３６：リクエスト実行順制御部
３７：タスク管理部
３９：ストレージ制御部
４：管理ネットワーク
５：データネットワーク
６：管理端末
６１：管理インターフェース
Ｔ１：性能要件定義テーブル
Ｔ２：タスク状態管理テーブル
Ｔ３：タイムアウト管理テーブル
Ｔ４：タスク定義テーブル
１０：メモリ
１１：ホスト制御プログラム
１２：入出力装置
１３：ＣＰＵ
１４：ストレージ
１５：管理インターフェース
１６：データインタフェース
２：ストレージ装置
２０：メモリ
２１：ストレージ制御プログラム
２２：ＣＰＵ
２３：ディスク
２４：論理ボリューム
２５：管理インターフェース
２６：データインタフェース
３：管理計算機
３１：ホスト管理プログラム
３２：ストレージ管理プログラム
３３：リクエスト処理部
３４：タイムアウト管理部
３５：リクエスト登録部
３６：リクエスト実行順制御部
３７：タスク管理部
３９：ストレージ制御部
４：管理ネットワーク
５：データネットワーク
６：管理端末
６１：管理インターフェース
Ｔ１：性能要件定義テーブル
Ｔ２：タスク状態管理テーブル
Ｔ３：タイムアウト管理テーブル
Ｔ４：タスク定義テーブル
Claims (14)
- 第1の装置と第2の装置に接続する管理計算機であって、
前記第2の装置で実行されるリクエストの種別、
前記リクエストの受け付け時刻及び
前記リクエストの実行順位
を含むリクエスト実行制御情報並びに
前記リクエストの種別、
前記リクエストがタイムアウトする時間及び
前記リクエストを実行するのに要する時間
を含むリクエスト要件情報
を備え、
前記第1の装置でタスクが実行された結果発行される、前記タスクを構成する複数のリクエストのうち1つのリクエストを受信し、
前記受信したリクエストを前記リクエスト実行制御情報に反映し、
前記リクエスト要件情報を参照して前記リクエスト実行制御情報の前記実行順位を更新し、
前記リクエスト実行制御情報を参照して、前記第2の装置に前記リクエストを送信する
ことを特徴とする管理計算機。 - 請求項１に記載の管理計算機であって、
前記リクエスト実行制御情報は、さらに、前記タスクの種別を含む
ことを特徴とする管理計算機。 - 請求項２記載の管理計算機であって、
前記タスクは、前記第1の装置で動作するVMに対する操作であり、
前記リクエストは、前記第2の装置の備えるストレージ装置に対する操作である
ことを特徴とする管理計算機。 - 請求項３記載の管理計算機であって、
前記リクエスト要件情報は、さらに、前記リクエストについて、前記実行順位の最も早いリクエストを実行した場合に、当該実行したリクエストが完了した時点でのタイムアウトする時間を含む
ことを特徴とする管理計算機。 - 請求項４記載の管理計算機であって、
前記リクエスト要件情報を参照し、前記実行したリクエストが完了した時点でのタイムアウトする時間が負のリクエストがある場合、前記リクエスト実行制御情報の前記実行順位を更新しない
ことを特徴とする管理計算機。 - 請求項５記載の管理計算機であって、
前記リクエスト要件情報を参照し、前記実行したリクエストが完了した時点でのタイムアウトする時間が負のリクエストが場合、当該負のリクエストのタイムアウトを前記第1の装置に対して送信する
ことを特徴とする管理計算機。 - 請求項６記載の管理計算機であって、
前記リクエストがタイムアウトする時間が負のリクエストがある場合、当該負のリクエストのタイムアウトを前記第1の装置に送信する
ことを特徴とする管理計算機。 - 第1の装置と第2の装置に接続し、
前記第2の装置で実行されるリクエストの種別、
前記リクエストの受け付け時刻及び
前記リクエストの実行順位
を含むリクエスト実行制御情報並びに
前記リクエストの種別、
前記リクエストがタイムアウトする時間及び
前記リクエストを実行するのに要する時間
を含むリクエスト要件情報
を備える管理計算機において、前記第2の装置で実行されるリクエストを送信する順番を制御するリクエスト制御方法であって、
前記第1の装置でタスクが実行された結果発行される、前記タスクを構成する複数のリクエストのうち1つのリクエストを受信するステップ、
前記受信したリクエストを前記リクエスト実行制御情報に反映するステップ、
前記リクエスト要件情報を参照して前記リクエスト実行制御情報の前記実行順位を更新するステップ及び
前記リクエスト実行制御情報を参照して、前記第2の装置に前記リクエストを送信するステップ
を含むことを特徴とするリクエスト制御方法。 - 請求項８記載のリクエスト制御方法であって、
前記リクエスト実行制御情報は、さらに、前記タスクの種別を含む
ことを特徴とするリクエスト制御方法。 - 請求項９記載のリクエスト制御方法であって、
前記タスクは、前記第1の装置で動作するVMに対する操作であり、
前記リクエストは、前記第2の装置の備えるストレージ装置に対する操作である
ことを特徴とするリクエスト制御方法。 - 請求項１０記載のリクエスト制御方法であって、
前記リクエスト要件情報は、さらに、前記リクエストについて、前記実行順位の最も早いリクエストを実行した場合に、当該実行したリクエストが完了した時点でのタイムアウトする時間を含む
ことを特徴とするリクエスト制御方法。 - 請求項１１記載のリクエスト制御方法であって、
前記実行順位を更新するステップは、前記リクエスト要件情報を参照し、前記実行したリクエストが完了した時点でのタイムアウトする時間が負のリクエストがある場合、更新を行わない
ことを特徴とするリクエスト制御方法。 - 請求項１２記載のリクエスト制御方法であって、さらに、
前記リクエスト要件情報を参照し、前記実行したリクエストが完了した時点でのタイムアウトする時間が負のリクエストがある場合、当該負のリクエストのタイムアウトを前記第1の装置に対して送信するステップ
を含むことを特徴とするリクエスト制御方法。 - 請求項１３記載のリクエスト制御方法であって、さらに、
前記リクエストがタイムアウトする時間が負のリクエストがある場合、当該負のリクエストのタイムアウトを前記第1の装置に送信するステップ
を含むことを特徴とするリクエスト制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2015/077642 WO2017056208A1 (ja) | 2015-09-30 | 2015-09-30 | リクエスト実行順序制御方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2015/077642 WO2017056208A1 (ja) | 2015-09-30 | 2015-09-30 | リクエスト実行順序制御方式 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2017056208A1 true WO2017056208A1 (ja) | 2017-04-06 |
Family
ID=58423027
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/JP2015/077642 WO2017056208A1 (ja) | 2015-09-30 | 2015-09-30 | リクエスト実行順序制御方式 |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2017056208A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112671835A (zh) * | 2020-12-07 | 2021-04-16 | 深圳市晨北科技有限公司 | 一种请求处理的方法、装置、系统及存储介质 |
| US11113003B2 (en) | 2019-01-08 | 2021-09-07 | Fujitsu Limited | Storage apparatus, storage control device, and recording medium with execution command pausing or stopping |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000347999A (ja) * | 1999-06-04 | 2000-12-15 | Hitachi Ltd | コンピュータシステム及びディスク制御装置 |
| JP2008181288A (ja) * | 2007-01-24 | 2008-08-07 | Hitachi Ltd | リモートコピーシステム |
| JP2012038330A (ja) * | 2011-10-05 | 2012-02-23 | Hitachi Global Storage Technologies Netherlands Bv | ハードディスクドライブ |
-
2015
- 2015-09-30 WO PCT/JP2015/077642 patent/WO2017056208A1/ja active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000347999A (ja) * | 1999-06-04 | 2000-12-15 | Hitachi Ltd | コンピュータシステム及びディスク制御装置 |
| JP2008181288A (ja) * | 2007-01-24 | 2008-08-07 | Hitachi Ltd | リモートコピーシステム |
| JP2012038330A (ja) * | 2011-10-05 | 2012-02-23 | Hitachi Global Storage Technologies Netherlands Bv | ハードディスクドライブ |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11113003B2 (en) | 2019-01-08 | 2021-09-07 | Fujitsu Limited | Storage apparatus, storage control device, and recording medium with execution command pausing or stopping |
| CN112671835A (zh) * | 2020-12-07 | 2021-04-16 | 深圳市晨北科技有限公司 | 一种请求处理的方法、装置、系统及存储介质 |
| CN112671835B (zh) * | 2020-12-07 | 2022-08-09 | 深圳市晨北科技有限公司 | 一种请求处理的方法、装置、系统及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11243707B2 (en) | Method and system for implementing virtual machine images | |
| US10222983B2 (en) | Storage management computer and management method of storage apparatus | |
| US20190235904A1 (en) | Cloning services in virtualized computing systems | |
| US10740133B2 (en) | Automated data migration of services of a virtual machine to containers | |
| JP2011076605A (ja) | 仮想マシン・イメージの実行方法及びシステム | |
| JP5229486B2 (ja) | 管理計算機及び処理管理方法 | |
| JP2016167143A (ja) | 情報処理システムおよび情報処理システムの制御方法 | |
| JP2008287631A (ja) | デプロイ対象計算機、デプロイメントシステムおよびデプロイ方法 | |
| WO2014075875A1 (en) | Automatic template creation based on new feeds | |
| JPWO2012066640A1 (ja) | 計算機システム、マイグレーション方法及び管理サーバ | |
| JP5346405B2 (ja) | ネットワークシステム | |
| US20230315511A1 (en) | Managing execution of data processing jobs in a virtual computing environment | |
| US20150154042A1 (en) | Computer system and control method for virtual machine | |
| US11231953B2 (en) | Minimizing downtime when importing virtual machines from other platforms | |
| US10990373B2 (en) | Service managers and firmware version selections in distributed computing systems | |
| JP2014109900A (ja) | データセンタ，データセンタでのシステムの複写サービスの提供方法及びデータセンタでのシステムの複写プログラム | |
| JP5183448B2 (ja) | 情報処理装置及び情報処理方法及びプログラム | |
| US10936330B2 (en) | Instantaneous boot of virtual machine instances via remote direct memory access | |
| JP5492731B2 (ja) | 仮想計算機のボリューム割当て方法およびその方法を用いた計算機システム | |
| WO2017056208A1 (ja) | リクエスト実行順序制御方式 | |
| WO2013145434A1 (ja) | ネットワークシステム及びその制御方法 | |
| JP2017068480A (ja) | ジョブ管理方法、ジョブ管理装置及びプログラム | |
| US9292318B2 (en) | Initiating software applications requiring different processor architectures in respective isolated execution environment of an operating system | |
| JP5391152B2 (ja) | サーバシステム、及び、仮想サーバの移行方式を選択する方法 | |
| JP2011221634A (ja) | 計算機システム、論理区画管理方法及び論理分割処理プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15905362 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 15905362 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: JP |