JP6286280B2 - 資源割り当て方法及び資源割り当てシステム - Google Patents

Description

本出願は、複数ユーザシステムにおいて、ソフトウエア資源を割り当てる方法及びシステムに関する。

クラスタ又はクラウドサーバのような複数ユーザシステム上で演算タスクを行うとき、多くの処理を同時に実行しなければないことが多い。さらに通常は、同時に実行される処理のそれぞれが、１つの特定のソフトウエアのコピーを別途要求する。例えば、自動車設計を行う複数ユーザシステムでは、１つの演算処理を行うためには、いくつかの異なるソフトウエア資源を纏めた１つのコピーを使用することが必要となることもある。

さらに、いくつかのタスクを実行するために、同じ１つのソフトウエア資源をいくつかコピーして使用することが必要になることも多い。例えば、自動車産業では、相当複雑なシミュレーションをするには、いくつかの異なるソフトウエア資源を複数コピーして使用することが必要となる。

現在、コンピュータ産業における仮想化技術は、いくつかのサーバを仮想化し、あたかも１つの物理サーバであるかのように統合することを可能にする。しかしながら、ソフトウエアに対する要求に変化があるかと言えばそうではなく、それぞれの仮想マシンが、それぞれのタスクを実行するのに必要なそれぞれのソフトウエア資源の適法なコピーを引続き必要とする。

ネットワーク内の異なる複数のソフトウエア資源の場所を決定し、それらを割り当てる試みが従来から知られている。しかしながら、これらの従来から知られているシステムは、すべて、ハードウエア資源及びソフトウエア資源の量が無限であることを前提としている。しかしながら、経済的理由を含む多くの理由により、無限のソフトウエア資源を実際に提供し得るサービスプロバイダは存在しない。さらに、これらの従来から知られている割り当てシステムのうち、特定のタスクに要求される複数のソフトウエア資源を統合することを試みたものは皆無である。そのため、ソフトウエア資源を非効率的に使用してしまう結果となっている。

（要約）
本発明は、複数ユーザネットワークにおいて、ソフトウエア資源を割り当てるための方法及びシステムを提供する。これらの方法及びシステムは、従来から知られている方法及びシステムの前記欠点を克服する。

要するに、本発明においては、ネットワークからタスクが受け取られる。受取られたそれぞれのタスクは、少なくとも１つの、しばしば多くの、ソフトウエア資源を要求する。

それぞれのタスクは分析されて、そのタスクを実行するのに要求されるソフトウエア資源のタイプと数を決定する。

決定されたソフトウエア資源の利用可能性が判断され、利用可能である場合、そのソフトウエア資源が、それを要求するタスクに割り当てられる。一方、ある特定のタスク向けのソフトウエア資源が利用不可能である場合、そのタスクは、しばらくの期間、処理待ちキュー（行列）に並ぶことになる。その後、要求されているソフトウエア資源が発見され割り当てられるまで、その特定のタスクが要求するソフトウエア資源の利用可能性が繰り返し判断される。

添付の図と併せて以下の詳細な説明を参照すると、本発明をよりよく理解できる。複数の図を通じて、同じ箇所には同じ参照番号が振られている。
本発明の好ましい実施形態に係る仮想資源管理システムの全体図である。 クライアントシステムの一例のブロック図である。 サーバシステムの一例のブロック図である。 仮想ハードウエア資源サーバのブロック図である。 ソフトウエア資源サーバのブロック図である。 資源管理サーバのブロック図である。 未処理キュー処理手順のフローチャートである。 タスク分析処理手順のフローチャートである。 保留キュー処理手順のフローチャートである。 資源割り当て最適化処理手順のフローチャートである。 統合処理手順のフローチャートである。 仮想資源割り当て処理手順のフローチャートである。 仮想マシン再活用処理手順のフローチャートである。 （ａ）は、タスクを統合する前の統合テーブルの一例である。（ｂ）は、タスクを統合した後の統合テーブルの一例である。 （ａ）は、ハードウエア資源テーブルの一例である。（ｂ）は、ソフトウエア資源テーブルの一例である。

図１は、本発明に係るソフトウエア資源管理システム３０のブロック図である。ソフトウエア資源管理システム３０は、コンピュータネットワーク３２を介して複数のユーザ３４と電子的に接続されている。よって、ユーザ３４がコンピュータネットワーク３２を介してソフトウエア資源管理システム３０に様々なタスクを提示すると、ソフトウエア資源管理システム３０は、自身がアクセス可能なソフトウエアを使用してそのタスクを実行することになる。

図２を参照する。ユーザシステム又はクライアントシステム３４は、典型的には、クライアントバス３８及びネットワークインタフェース４０を介してネットワーク３２と通信する中央制御装置３６を有している。主記憶装置（Random Access Memory）４２及びハードディスクドライブのような不揮発性の補助記憶装置４４もまた、クライアントバス３８に接続されている。

モニタのような出力装置４６が、ディスプレイインタフェース４８を介してクライアントバス３８と接続されている。同様にキーボードのような入力装置５０もまた、ＵＳＢ（Universal Serial Bus）インタフェース５２を介してクライアントバス３８と接続されている。

実際には、ユーザシステム又はクライアントシステム３４は、自動車シミュレーションのようなタスクを作成し、そのタスクをソフトウエア資源管理システム３０にネットワークインタフェース４０を介して提示する。ソフトウエア資源管理システム３０に提示されたタスクは、少なくとも１つの、多くの場合は２つ以上の、ソフトウエア資源を要求する。同じ１つのソフトウエア資源の複数のコピーが、提示されたタスクを実行することになる場合もある。タスクを実行するのに必要なソフトウエア資源の数に関係なく、一旦ユーザがクライアントシステム３４でタスクを作成すると、タスクは、ネットワークインタフェース４０を介してソフトウエア資源管理システム３０に送信される。

図３を参照する。図２のクライアントシステム３４に代替する構成として、サーバ５４がネットワーク３２と通信し、サーバ５４が、ユーザが提示した、１又は複数のソフトウエア資源を要求するタスクを実行してもよい。ソフトウエア資源管理システム３０（図１）において、サーバ群１９４を構成する１つの仮想マシンとして、又は、タスク分析等のような他のジョブを実行する管理サーバとして、複数のサーバ５４が存在してもよい。出力装置４６、入力装置５０、それらのそれぞれに対応するディスプレイインタフェース４８及びＵＳＢインタフェース５２のいずれも有さないという点で、サーバ５４は、クライアントシステム３４とは異なる。なぜならば、ユーザはサーバ５４と物理的にやり取りするわけではないからである。その他の点については、図２に示されているクライアントシステム３４の記述は、図３についても同様にあてはまる。

図１及び図７を参照する。ソフトウエア資源管理システム３０は、自身に提示されたすべてのタスクを、まずタスク処理部５６（図１）で処理する。図７は、タスク処理部５６の未処理キュー処理手順を図示するフローチャートである。

ステップＳ５８において、タスク処理部５６が起動し、その後ステップＳ６０に進む。
ステップＳ６０において、タスク処理部５６は、ネットワーク３２から新たなタスクが受け取られているか否かを判断する。新たなタスクが受け取られていない場合（ステップＳ６０“ＮＯ”）、タスク処理部５６は、ステップＳ６２に進む。
ステップＳ６２において、タスク処理部５６は、しばらくの期間（例えば数ミリ秒）待機し、その後ステップＳ６０に戻る。ステップＳ６０及びＳ６２の処理は、ネットワーク３２から新たなタスクが受け取られるまで繰り返される。新たなタスクが受け取られている場合（ステップＳ６０“ＹＥＳ”）、タスク処理部５６は、ステップＳ６４に進む。

ステップＳ６４において、タスク処理部５６は、新たに受け取られたタスクを、未処理キュー６６（図１）に加え、その後ステップＳ６８に進む。

ステップＳ６８において、タスク処理部５６は、新たに受取られたタスクがソフトウエア資源管理システム３０によって処理可能であるか否かを判断する。通常は、処理可能である。処理可能である場合（ステップＳ６８“ＹＥＳ”）、タスク処理部５６は、ステップＳ６０に戻る。ステップＳ６０、Ｓ６４及びＳ６８の処理は、ネットワーク３２から新たなタスクが受け取られる都度繰り返される。処理可能ではない場合（ステップＳ６８“ＮＯ”）、タスク処理部５６は、繰り返しループを抜け出て、未処理キュー処理手順を終了する（ステップＳ７０）。

図１に戻る。タスク分析部７２は、未処理キュー６６内のそれぞれのタスクが要求する資源を分析し、充分なソフトウエア資源がない場合は、保留キュー７４にタスクを記憶する。タスク分析部７２は、ソフトウエア資源を割り当てたタスクを処理済キュー１０６に移動する。
図８を参照する。ステップＳ７６において、タスク分析部７２が起動し、その後ステップＳ７８に進む。ステップＳ７８において、タスク分析部７２は、保留キュー７４に記憶されているタスクをまず処理する。

ここで一旦図９を参照する。図９は、タスク分析部７２による保留キュー処理手順のフローチャートである。保留キュー処理手順は、図８のステップＳ７８の詳細である。
ステップＳ８０において、タスク分析部７２が起動し、その後ステップＳ８２に進む。ステップＳ８２において、タスク分析部７２は、保留キュー７４が空き状態であるか否かを判断する。空き状態である場合（ステップＳ８２“ＹＥＳ”）、タスク分析部７２は、ステップＳ８４に進み、保留キュー処理手順を終了したうえで、ステップＳ８６（図８）に進む。

一方、保留キュー７４が空き状態ではない場合（ステップＳ８２“ＮＯ”）、タスク分析部７２は、ステップＳ８８に進む。
ステップＳ８８において、タスク分析部７２は、保留キュー７４に記憶されている次のタスクを取得する。

ステップＳ９０において、タスク分析部７２は、ソフトウエア資源管理システム３０に利用可能であって、かつ、ステップＳ８８において取得されたタスクを実行するのに必要なソフトウエア資源が充分にあるか否かを判断する。この判断をするために、タスク分析部７２は、資源プール３７（図１）におけるソフトウエア９２と通信する。図５に最もよく示されているように、ソフトウエア資源サーバ９２（図１におけるソフトウエア９２）は、ソフトウエアデータベース９４、及び、ソフトウエアデータベース９４にアクセスするデータベースアプリケーション９６を有する。データベースアプリケーション９６自身は、オペレーティングシステム９８の制御のもとで動作し、ソフトウエア資源サーバ９２は、物理サーバ１００を介してネットワーク３２と通信する。

ステップＳ９０において、タスク分析部７２は、ソフトウエア資源サーバ９２と通信して、ステップＳ８８において取得されたタスクを実行するために利用可能なソフトウエア資源が充分にあるか否かを判断する。充分にない場合（ステップＳ９０“ＮＯ”）、タスク分析部７２は、ステップＳ１０２に進む。
ステップＳ１０２において、タスク分析部７２は、保留キュー７４が空き状態であるか否かを判断する。空き状態である場合（ステップＳ１０２“ＹＥＳ”）、タスク分析部７２は、ステップＳ８４に進み保留キュー処理手順を終了し、ステップＳ８６（図８）に進む。一方、保留キュー７４が空き状態ではない場合（ステップＳ１０２“ＮＯ”）、タスク分析部７２は、ステップＳ８８に戻り前記の処理を繰り返す。

一方、タスクを実行するために利用可能なソフトウエア資源が充分にある場合（ステップＳ９０“ＹＥＳ”）、タスク分析部７２は、ステップＳ１０４に進む。
ステップＳ１０４において、タスク分析部７２は、タスクを保留キュー７４から処理済キュー１０６（図１）に移動する。その後、タスク分析部７２は、ステップＳ１０８に進む。

ステップＳ１０８において、タスク分析部７２は、ソフトウエア資源サーバ９２と通信し、ステップＳ８８において取得されたタスクに割り当てられたソフトウエア資源を削除する又は控除することよって、ソフトウエア資源利用可能性テーブルを更新する。その後、タスク分析部７２は、ステップＳ１０２に進む。
ステップＳ１０２においては、タスク分析部７２は、前記したように、判断に応じて処理を振り分ける。

図８に戻る。保留キュー７４内のすべてのタスクが前記のように処理された後（ステップＳ１０２“ＹＥＳ”のパス）、ステップＳ８６において、タスク分析部７２は、未処理キュー６６から次のタスクを取得する。その後、タスク分析部７２は、ステップＳ１１０に進む。

ステップＳ１１０において、タスク分析部７２は、タスクのタイプが“０”であるか否かを判断する。タイプが“０”であるタスクとは、そのタスクを実行するために要求される複数のソフトウエア資源のすべてが、それぞれ“１回”しか要求されないタスクであり、したがって、ソフトウエア資源ごとに１つのコピーだけが要求されているタスクである。一方、タイプが“１”であるタスクとは、少なくとも１つの同じソフトウエア資源を２回以上要求するタスクである。他のソフトウエア資源についても同様である。後者の場合、タイプが“１”であるソフトウエア資源の統合（詳細後記）が可能である。

引続き図８を参照する。タスクのタイプが“０”である場合（ステップＳ１１０“ＹＥＳ”）、タスク分析部７２は、ステップＳ１１２に進む。
ステップＳ１１２において、タスク分析部７２は、タスクを実行するために充分なソフトウエア資源があるか否かを判断する。ステップＳ１１２は、図９のステップＳ９０と同じである。充分なソフトウエア資源が利用可能ではない場合（ステップＳ１１２“ＮＯ”）、タスク分析部７２は、ステップＳ１１４に進む。
ステップＳ１１４において、タスク分析部７２は、タスクを保留キュー７４に移動し、後続処理に備える。一方、タイプが“０”であるタスクを実行するために充分なソフトウエア資源がある場合（ステップＳ１１２“ＹＥＳ”）、タスク分析部７２は、ステップＳ１１５に進む。
ステップＳ１１５において、タスク分析部７２は、タスクを処理済キュー１０６に移動する。その後、タスク分析部７２は、ステップＳ１１６に進む。
ステップＳ１１６において、タスク分析部７２は、図９のステップＳ１０８と同じ方法で、ソフトウエア資源利用可能性テーブルを更新する。その後、タスク分析部７２は、ステップＳ１１８に進む。
ステップＳ１１８において、タスク分析部７２は、未処理キュー６６が空き状態であるか否かを判断する。空き状態である場合（ステップＳ１１８“ＹＥＳ”）、タスク分析部７２は、ステップＳ１２０に進み、タスク分析処理手順を終了する。一方、未処理キュー６６が空き状態ではない場合（ステップＳ１１８“ＮＯ”）、タスク分析部７２は、ステップＳ８６に戻り前記処理（Ｓ８０〜Ｓ８４）を繰り返す。

タスクのタイプが“１”である場合、つまり、タスクが少なくとも１つのソフトウエア資源について複数回コピーを要求する場合（ステップＳ１１０“ＮＯ”）、タスク分析部７２は、ステップＳ１２２に進む。
ステップＳ１２２において、タスク分析部７２は、ソフトウエア資源の割り当てを、タイプが“１”である複数のタスクごとに最適化する。図１０は、資源割り当て最適化処理手順のフローチャートである。資源割り当て最適化処理手順は、図８のステップＳ１２２の詳細である。

図１０を参照する。ステップＳ１２４において、資源割り当て部１６２が起動し、その後、ステップＳ１２６に進む。ステップＳ１２６において、資源割り当て部１６２は、タスクを検査し、同じタイプの１つのソフトウエア資源を要求する複数の処理を合成することによって、１つの特定のソフトウエア資源の複数のコピーを求める要求が統合され得るか否かを判断する。統合され得ない場合（ステップＳ１２６“ＮＯ”）、資源割り当て部１６２は、ステップＳ１２８に進む。
ステップＳ１２８において、資源割り当て部１６２は、タスクが要求している他のタイプのソフトウエア資源があるか否かを判断する。つまり、他のタイプの処理を統合するか否かを判断する。タスクが要求している他のタイプのソフトウエア資源がある場合（ステップＳ１２８“ＹＥＳ”）、資源割り当て部１６２は、ステップＳ１２６に戻る。タスクが要求している他のタイプのソフトウエア資源がない場合（ステップＳ１２８“ＮＯ”）、資源割り当て部１６２は、資源割り当て最適化処理手順を終了する（ステップＳ１３０）。

一方、１つの特定のソフトウエア資源の複数のコピーを求める要求が統合され得る場合（ステップＳ１２６“ＹＥＳ”）、資源割り当て部１６２は、ステップＳ１３２に進む。
ステップＳ１３２において、資源割り当て部１６２は、その特定のタイプのソフトウエア資源のうち、そのタスクが要求するソフトウエア資源の総数“Ｎ”を決定する。その後、資源割り当て部１６２は、ステップＳ１３４に進む。
ステップＳ１３４において、資源割り当て部１６２は、ソフトウエアデータベース９４（図５）に問い合わせることによって、そのタイプのソフトウエア資源の最大数“Ｍ”を決定する。その後、資源割り当て部１６２は、ステップＳ１３６に進む。

ステップＳ１３６において、資源割り当て部１６２は、“Ｍ”が“Ｎ”以上であるか否かを判断する。前記したように、“Ｍ”は、そのタイプの利用可能なソフトウエア資源の最大数（利用可能数）であり、“Ｎ”は、そのタイプのソフトウエア資源のうち特定のタスクが要求するソフトウエア資源の総数（要求数）である。“Ｍ”が“Ｎ”以上である場合（ステップＳ１３６“ＹＥＳ”）、資源割り当て部１６２は、統合の必要はないと決定する。つまり、資源割り当て部１６２は、ステップＳ１２８に進み、そのタスクが要求するすべての処理が検査されるまで処理を繰り返す。

一方、特定のタイプのソフトウエア資源の数“Ｎ”が、そのタイプのソフトウエア資源の利用可能なコピーの数“Ｍ”を超える場合（ステップＳ１３６“ＮＯ”）、資源割り当て部１６２は、統合の必要があると決定し、ステップＳ１３８に進む。
ステップＳ１３８において、資源割り当て部１６２は、“Ｎ”個の処理を“Ｍ”個の処理に統合する。つまり、資源割り当て部１６２は、タスクが要求する、特定のタイプのソフトウエア資源の数を、利用可能なソフトウエア資源の数に統合する。

ここで一旦図１１を参照する。図１１に統合処理手順が示されている。統合処理手順は、図１０のステップＳ１３８の詳細である。
ステップＳ１４２において、資源割り当て部１６２は、統合処理手順を開始し、ステップＳ１４４に進む。
ステップＳ１４４において、資源割り当て部１６２は、コンピュータの処理負担が小さい順に（昇順に）ソフトウエア資源を並び替える。ここでの並び替えは、複数の中央制御装置に対して可能な限り均一にタスクの処理負担を配分するためには有益である。その後、資源割り当て部１６２は、ステップＳ１４６に進む。

ステップＳ１４６において、資源割り当て部１６２は、インデクス“ｉ”を設定し、“ｉ”に“１”を代入する。その後、資源割り当て部１６２は、ステップＳ１４８に進む。
ステップＳ１４８において、資源割り当て部１６２は、ダミー変数“ｊ”を設定し、“ｊ”に“１”を代入する。その後、資源割り当て部１６２は、ステップＳ１５０に進む。

ステップＳ１５０において、資源割り当て部１６２は、ダミー変数“ｊ”と利用可能なライセンスの数“Ｍ”との積に対して、インデクス“ｉ”を加算する。そして、“ｉ＋Ｍ×ｊ”の値を、タスクを実行するために要求されるソフトウエア資源の数である“Ｎ”と比較し、“ｉ＋Ｍ×ｊ＞Ｎ”であるか否かを判断する。比較結果が“ｉ＋Ｍ×ｊ＞Ｎ”ではない（ライセンスの数に余裕がない）場合（ステップＳ１５０“ＮＯ”）、資源割り当て部１６２は、ステップＳ１５２に進む。
ステップＳ１５２において、資源割り当て部１６２は、インデクス“ｉ”を有する処理を、インデクス“ｉ＋Ｍ×ｊ”を有する処理と統合する。その後、資源割り当て部１６２は、ステップＳ１５４に進む。
ステップＳ１５４において、資源割り当て部１６２は、ダミー変数“ｊ”に対して“１”を加算する。その後、資源割り当て部１６２は、ステップＳ１５０に戻り、前記の処理を繰り返す。

一方、比較結果が“ｉ＋Ｍ×ｊ＞Ｎ”である（ライセンスの数に余裕がある）場合（ステップＳ１５０“ＹＥＳ”）、資源割り当て部１６２は、ステップＳ１５６に進む。
ステップＳ１５６において、資源割り当て部１６２は、インデクス“ｉ”に対して“１”を加算する。その後、資源割り当て部１６２は、ステップＳ１５８に進む。
ステップＳ１５８において、資源割り当て部１６２は、インデクス“ｉ”を、利用可能なソフトウエア資源の数“Ｍ”と比較し、“ｉ＞Ｍ”であるか否かを判断する。比較結果が“ｉ＞Ｍ”である場合（ステップＳ１５８“ＹＥＳ”）、資源割り当て部１６２は、ステップＳ１６０に進み、統合処理手順を終了する。比較結果が“ｉ＞Ｍ”ではない場合（ステップＳ１５８“ＮＯ”）、資源割り当て部１６２は、ステップＳ１４８に戻り、前記の処理を繰り返す。

図１０に戻る。
ステップＳ１３８においてソフトウエア資源を統合した後、資源割り当て部１６２は、ステップＳ１４０に進む。
ステップＳ１４０において、資源割り当て部１６２は、「当該タスクは、現在“Ｍ”個の処理を要求するに過ぎなくなっている。したがって、当該タスクは、このようなソフトウエア資源のコピーを“Ｍ”個しか必要としていない」旨をタスク情報に書き加えて、タスク情報を更新した後、前記のステップＳ１２８の処理を実行する。

図１４（ａ）は、統合前のタスクの一例を示し、図１４（ｂ）は、統合後のタスクの一例を示す。この例では、タイプが“１”である処理は２つ存在し、これらの処理は、タイプ欄に“Ｂ”が記載されている２つのレコードに対応する（図１４（ａ））。しかしながら、コピーライセンスは、１つ（１回分）しかない。そこで、タスクを実行可能にするために、資源割り当て部１６２は、タイプ“Ｂ”の２つの処理を１つに統合する（図１４（ｂ））。その結果、１つのコピーライセンスで足りることになる。統合処理後、タスクは適法なライセンスの数で実行され得る。

図８に戻る。
ステップＳ１２２において、ソフトウエア資源の割り当てを最適化した後、タスク分析部７２は、タスクを処理済キュー１０６（図１）に移動し、ソフトウエア資源利用可能性テーブルを更新する。

図１５（ａ）は、ハードウエア資源の資源テーブル１０７の例である。図１５（ｂ）は、ソフトウエア資源の資源テーブル１０９の例である。

図１５（ａ）を参照する。資源テーブル１０７は、カテゴリに関連付けて、総容量、予約済容量、割り当て済容量及び利用可能容量が記憶されている。例えば中央制御装置の行（レコード）において、総容量から予約済容量を減算し、さらに割り当て済容量を減算した結果が利用可能容量となっている。利用可能容量は、他のタスクのために利用可能な中央制御装置の容量である。主記憶装置（ＲＡＭ）及びハードディスクドライブのような不揮発性の補助記憶装置の行についても同様である。

図１５（ｂ）は、ソフトウエア資源の資源テーブル１０９である。資源テーブル１０９は、Ａ、Ｂ、Ｃ等異なる複数のソフトウエアのカテゴリに関連付けて、各カテゴリに属するソフトウエアの総数、予約済のソフトウエアの数、割り当て済のソフトウエアの数及び利用可能なソフトウエアの数が記憶されている。カテゴリごとに、ソフトウエアの総数から、予約済のソフトウエアの数を減算し、さらに割り当て済のソフトウエアの数を減算することによって、当該カテゴリの利用可能なソフトウエアの数を算出できる。

図１、及び図６を参照する。処理済キュー１０６内の次のタスクを実行するには、適当なソフトウエア資源及びハードウエア資源が割り当てられなければならない。したがって、資源割り当て部１６２（１８２）は、ハードウエア資源及びソフトウエア資源を割り当てなければならない。

資源割り当て部１６２の処理が図１２に示されている。
ステップＳ１６４において、資源割り当て部１６２は、仮想資源割り当て処理手順を開始し、ステップＳ１６６に進む。
ステップＳ１６６において、資源割り当て部１６２は、処理済キュー１０６から次のタスクを取得する。その後、資源割り当て部１６２は、ステップＳ１６８に進む。
ステップＳ１６８において、資源割り当て部１６２は、資源管理サーバ１７２（図６）と通信し、タスクに対してハードウエア及びソフトウエアを割り当てる。割り当てられたハードウエア及びソフトウエアは、一体となってサーバ５４（図３）を構成し、図１のサーバ群１９４に加えられる。図６に示すように、資源管理サーバ１７２は、オペレーティングシステム１７４、及び、オペレーティングシステム１７４の制御下で動作する管理アプリケーション１７６を有する。さらに、管理アプリケーション１７６は、プログラムとして、タスク処理部１７８、タスク分析部１８０、資源割り当て部１８２及び資源再活用部１８４を格納している。専用のサーバ１８６が、ネットワーク３２と通信する。

図４を参照する。仮想ハードウエアサーバシステム１９０は、自身のサーバ１９２を介して、ネットワーク３２と通信する。仮想ハードウエアサーバシステム１９０は、ユーザが提示するジョブを実行する仮想サーバ群である図１のサーバ群１９４の一部であってもよい。サーバ群１９４の仮想サーバのそれぞれは、オペレーティングシステム１９８の制御下で動作するオペレーティングアプリケーション１９６を有する。オペレーティングアプリケーション１９６は、要求されるすべてのソフトウエア資源を含む。仮想ハードウエアシステム１９０は、ハイパーバイザ（サーバ１９２内の物理ハードウエアを使用して仮想ハードウエア２００を提供し得る特別なコンピュータオペレーティングシステム／ソフトウエア）に制御される。

図１２に戻る。ステップＳ１６８において、タスクに対して、仮想ハードウエアサーバシステム１９０（サーバ群１９４においても同様）の第１順位の仮想サーバを一旦割り当てると、資源割り当て部１６２は、タスクを実行するのに必要なソフトウエア資源を仮想サーバに読み出し、読み出したソフトウエア資源を実行する。その後、資源割り当て部１６２は、ステップＳ１７０に進む。
ステップＳ１７０において、資源割り当て部１６２は、処理済になったばかりのタスクを処理済みキュー１０６から削除する。

図１３を参照する。タスクが完了すると、資源再活用部２０４（図１）は、ソフトウエア資源をソフトウエアデータベース９４に戻して再活用し、仮想マシンをハードウエアデータベースに戻して再活用する。図１３は、資源再活用部２０４の処理を示している。

ステップＳ２０８において、資源再活用部２０４は、仮想マシン再活用処理を開始し、ステップＳ２１０に進む。
ステップＳ２１０において、資源再活用部２０４は、図１のサーバ群１９４のうちに非稼動の仮想サーバがあるか否かを判断する。ある場合（ステップＳ２１０“ＹＥＳ”）、資源再活用部２０４は、ステップＳ２１２に進む。
ステップＳ２１２において、資源再活用部２０４は、資源プール３７（図１）のハードウエア２０６及びソフトウエア９２（図５のソフトウエアデータベース９４）を更新する。その後、資源再活用部２０４は、ステップＳ２１４に進む。
ステップＳ２１４において、資源再活用部２０４は、所定の期間待機する。その後、資源再活用部２０４は、ステップＳ２１６に進む。
ステップＳ２１６において、資源再活用部２０４は、再活用を終了すべきであるか否かを判断する。終了するべきではない場合（ステップＳ２１６“ＮＯ”）、資源再活用部２０４は、ステップＳ２１０に戻り前記の処理を繰り返す。終了すべきである場合（ステップＳ２１６“ＹＥＳ”）、資源再活用部２０４は、仮想マシン再活用処理手順を終了する（ステップＳ２１８）。

一方、非稼動の仮想サーバがない場合（ステップＳ２１０“ＮＯ”）、再活用のために利用できる仮想サーバはないことになる。したがって、資源再活用部２０４は、ステップＳ２１４に進み、前記処理を繰り返す。

本発明はソフトウエア資源を割り当てるための効果的な方法及びシステムを提供することが、前記よりわかる。本発明の記述はここで終了する。しかしながら、添付の特許請求の範囲が特定する本発明の趣旨を逸脱しない範囲で、本発明に対する多くの修正が可能であることが、当業者には明らかである。

３０ ソフトウエア資源管理システム
３２ コンピュータネットワーク
３４ クライアントシステム
５６ タスク処理部
７２ タスク分析部
１６２ 資源割り当て部
２０４ 資源再活用部

Claims (13)

1. ソフトウエア資源を割り当てるシステムの方法であって、
   前記システムは、
   少なくとも１つのソフトウエア資源を要求するタスクをネットワークから受け取り、
   前記タスクのそれぞれを分析し、前記タスクを実行するために要求されるソフトウエア資源のタイプを決定し、
   前記ソフトウエア資源が利用可能であるか否かを判断し、
   前記ソフトウエア資源が利用可能である場合は、前記タスクのそれぞれに前記ソフトウエア資源を割り当て、
   前記ソフトウエア資源が利用可能でない場合は、前記ソフトウエア資源が利用可能になるまで、前記分析し決定する処理を繰り返し、
   前記要求されるソフトウエア資源の数が、当該ソフトウエア資源の利用可能数を超える場合、前記要求されるソフトウエア資源のコピーの数を前記利用可能数に統合することによって、前記タスクのすべてを実行可能にすること、
   を特徴とする方法。
2. 前記判断することは、
   前記ソフトウエア資源の数及び前記ソフトウエア資源の前記タイプを示すデータを格納する資源プールを検査することを含むこと、
   を特徴とする請求項１に記載の方法。
3. 前記システムは、
   前記タスクが完了すると、前記ソフトウエア資源を前記資源プールに戻すこと、
   を特徴とする請求項２に記載の方法。
4. 前記ソフトウエア資源は、
   仮想マシン上で実行されること、
   を特徴とする請求項１に記載の方法。
5. 前記受け取ったタスクは、
   前記分析する処理に先立って、未処理キューに記憶されること、
   を特徴とする請求項１に記載の方法。
6. 前記システムは、
   前記要求されるソフトウエア資源が利用可能でない場合は、
   前記タスクを保留キューに所定の期間記憶し、当該期間の経過後、当該タスクを分析し、当該タスクを実行するために要求されるソフトウエア資源のタイプを決定すること、
   を特徴とする請求項１に記載の方法。
7. ソフトウエア資源を割り当てるシステムであって、
   前記システムは、
   少なくとも１つのソフトウエア資源を要求するタスクをネットワークから受け取るタスク処理部と、
   前記タスクのそれぞれを分析し、前記タスクを実行するために要求されるソフトウエア資源のタイプを決定し、
   前記ソフトウエア資源が利用可能であるか否かを判断するタスク分析部と、
   前記ソフトウエア資源が利用可能である場合は、前記タスクのそれぞれに前記ソフトウエア資源を割り当て、
   前記ソフトウエア資源が利用可能でない場合は、前記ソフトウエア資源が利用可能になるまで、前記分析し決定する処理を繰り返し、
   前記要求されるソフトウエア資源の数が、当該ソフトウエア資源の利用可能数を超える場合、前記要求されるソフトウエア資源のコピーの数を前記利用可能数に統合することによって、前記タスクのすべてを実行可能にする資源割り当て部と、
   を有することを特徴とするシステム。
8. 前記システムは、
   前記ソフトウエア資源の数及び前記ソフトウエア資源の前記タイプを示すデータを格納する資源プールを検査する資源再活用部を有すること、
   を特徴とする請求項７のシステム。
9. 前記資源再活用部は、
   前記タスクが完了すると、前記ソフトウエア資源を前記資源プールに戻すこと、
   を特徴とする請求項８のシステム。
10. 前記ソフトウエア資源は、
    仮想マシン上で実行されること、
    を特徴とする請求項７のシステム。
11. 前記受け取ったタスクは、
    前記分析する処理に先立って、未処理キューに記憶されること、
    を特徴とする請求項７のシステム。
12. 前記タスク分析部は、
    前記要求されるソフトウエア資源が利用可能でない場合は、
    前記タスクを保留キューに所定の期間記憶し、当該期間の経過後、当該タスクを分析し、当該タスクを実行するために要求されるソフトウエア資源のタイプを決定すること、
    を特徴とする請求項７のシステム。
13. 前記タスク処理部及び前記タスク分析部は、
    プログラミングされたプロセッサであること、
    を特徴とする請求項７のシステム。

Images