(57)【要約】演算環境においてリソースを予約するシステム及び方法を開示する。方法の実施形態は、演算環境内でリソースの要求を受信し、要求によって必要とされた少なくとも１つのリソースタイプに関連した少なくとも１つの完了時間を決定し、少なくとも１つの完了時間の決定に基づいて、演算環境内でリソースを予約する。リソースごとの拡大縮小されたウォールクロック時間も、どのリソースを予約すべきか決定するのに用いられてもよい。システムは、第１タイプのリソースと第２タイプのリソースとの同時割当マップを生成する過程で、生成された同時割当マップに従って、リソースを予約するにあたって、開始時間分析、完了時間分析またはハイブリッド分析のいずれを行うべきか判定してもよい。
2010515155.tif 000002
【特許請求の範囲】
【請求項１】
演算環境でリソースを予約する方法であって、
演算環境内でリソースの要求を受信するステップと、
前記要求によって必要とされた少なくとも１つのリソースタイプと関連する少なくとも１つの完了時間を決定するステップであって、前記少なくとも１つの完了時間は、前記少なくとも１つのリソースタイプが前記要求を処理するのにどれくらいの時間がかかるかの分析に基づく、ステップと、
前記演算環境内で、前記決定された少なくとも１つの完了時間に基づいて、リソースを予約するステップと、
を含む、方法。
【請求項２】
請求項１に記載の方法であって、さらに、
前記要求に対して完了時間の範囲を決定するステップを含む、方法。
【請求項３】
請求項１に記載の方法において、
前記少なくとも１つの完了時間の決定は、少なくとも部分的に、ジョブ固有のウォールクロック時間拡大縮小情報に基づいている、方法。
【請求項４】
請求項１に記載の方法であって、さらに、
前記要求のために前記演算環境内で実行可能なリソースを特定するステップを含む、方法。
【請求項５】
請求項４に記載の方法であって、さらに、
前記要求を満たす実効速度について、特定された実行可能な各リソースを分析するステップを含む、方法。
【請求項６】
請求項５に記載の方法であって、さらに、
特定された実行可能な各リソースについて、ワークロードコミットメントを分析するステップを含む、方法。
【請求項７】
請求項６に記載の方法において、
前記ワークロードコミットメントの分析は、ノードごとの利用可能範囲を表す、方法。
【請求項８】
請求項７に記載の方法であって、さらに、
前記ノードごとの利用可能範囲を潜在完了時間範囲に変換するステップを含む、方法。
【請求項９】
請求項８に記載の方法であって、さらに、
前記潜在完了時間範囲を少なくとも他の要件と統合するステップと、
前記要求を満たすことができるリソースの複数の集合体に対する二重割当を判定するステップと、
を含む、方法。
【請求項１０】
請求項９に記載の方法において、
前記統合は、前記演算環境の様々なリソースの潜在完了時間の少なくとも２つのマッピングの統合を表す、方法。
【請求項１１】
請求項１に記載の方法であって、さらに、
前記要求に対して拡大縮小されたウォールクロック時間制限を用いて、前記要求に関連した少なくとも１つの開始時間を決定するステップを含む、方法。
【請求項１２】
請求項１に記載の方法において、
前記要求に対する前記少なくとも１つの完了時間は、特定のリソースの最悪の場合のシナリオに基づいて決定される、方法。
【請求項１３】
演算環境内でリソースを同時に割り当てる方法であって、
第１タイプのリソース及び第２タイプのリソースを必要とするリソースの要求を受信し、
前記第１タイプのリソースに関連した第１完了時間を分析するステップであって、前記第１完了時間の分析は、前記第１タイプのリソースが前記要求を処理するのにどれくらいの時間がかかるかに基づく、ステップと、
前記第２タイプのリソースに関連した第２完了時間を分析するステップであって、前記第２完了時間の分析は、前記第２タイプのリソースが前記要求を処理するのにどれくらいの時間がかかるかに基づく、ステップと、
前記第１及び第２タイプのリソースに対する前記完了時間の分析に基づいて、前記第１タイプのリソースと前記第２タイプのリソースとの同時割当マップを生成するステップと、
を含む、方法。
【請求項１４】
請求項１３に記載の方法であって、さらに、
前記生成された同時割当マップに従ってリソースを予約するステップを含む、方法。
【請求項１５】
請求項１３に記載の方法において、
前記同時割当マップを生成するステップは、前記第１要求及び前記第２要求を同時に満たすことができるリソースの量を減らしたマップを特定するステップを含む、方法。
【請求項１６】
請求項１５に記載の方法において、
前記同時割当マップは、前記第１要求及び前記第２要求を満たす、利用可能なリソースが存在する全ての時間枠を含む、方法。
【請求項１７】
請求項１３に記載の方法において、
考えられるタイプのリソースは、演算リソース、ディスク記憶リソース、ネットワーク帯域幅リソース、メモリリソース、使用許諾リソースのうち少なくとも１つを含む、方法。
【請求項１８】
請求項１３に記載の方法において、
前記同時割当マップを生成するステップは、さらに、前記第１タイプのリソース及び前記第２タイプのリソースのそれぞれの利用可能性の共通部分を特定するステップを含む、方法。
【請求項１９】
請求項１８に記載の方法において、
前記同時割当マップを生成するステップは、さらに、前記第１要求及び前記第２要求の両方が同時に満たされて交わる時間枠を判定するステップを含む、方法。
【請求項２０】
請求項１９に記載の方法であって、さらに、
前記交わる時間枠を表すイベントのアレイを生成するステップを含む、方法。
【請求項２１】
請求項２０に記載の方法において、前記生成されたイベントのアレイは、リソース量、リソースの質、時間枠、情報の質及びコストのうち少なくとも１つを含む、方法。
【請求項２２】
演算環境内でリソースを同時に割り当てる方法であって、
第１タイプのリソース及び第２タイプのリソースを必要とするリソースの要求を受信するステップと、
前記第１タイプのリソースに関連した第１相対リソース速度の分析を行うステップであって、前記第１タイプのリソースが前記要求を処理するのにどれくらい時間がかかるかを分析するステップを含む、ステップと、
前記第２タイプのリソースに関連した第２相対リソース速度の分析を行うステップであって、前記第２タイプのリソースが前記要求を処理するのにどれくらい時間がかかるかを分析するステップを含む、ステップと、
前記第１及び第２相対リソース速度に基づいて、前記第１タイプのリソースと前記第２タイプのリソースとの同時割当マップを生成するステップと、
を含む、方法。
【請求項２３】
演算環境においてリソースを予約する方法であって、
演算環境内でリソースの要求を受信するステップと、
前記要求に基づいて前記演算環境におけるリソースを予約するにあたって、開始時間分析、前記リソースが前記要求を処理するのにどれくらい時間がかかるかに基づく完了時間分析、または、ハイブリッド分析のいずれを行うかを決定するステップと、
前記決定された分析に基づいて、前記演算環境内でリソースを予約するステップと、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００６年１２月２６日付の米国出願１１／６１６，１５６号の優先権を主張する。当該出願の開示内容の全てを本願に援用する。
【０００２】
本発明は、クラスタやグリッドなどの演算環境内でのリソースの予約に関し、特に、完了時間、及び／または、サブミットされたジョブを演算するリソースの、相対的なマシンまたはリソース速度に基づいて、異なるリソースタイプにわたる同時割当予約を提供するシステム及び方法に関する。
【背景技術】
【０００３】
コンピュータのグリッド、コンピュートファームまたはクラスタなどの演算環境内で、リソースの消費の管理が複雑であるという課題がある。グリッドコンピューティングは、動的な、複数の機関が協力する、調整されたリソース共有及び問題解決として定義されてもよい。多くの演算プロジェクトは、単一のコンピュータが提供できるよりも、はるかに高い演算能力およびリソースを必要とする。プリンタ、スキャナ、入出力装置、保存ディスク、科学的な装置及び機器などの周辺機器のリソースを有するネットワークコンピュータは、タスクを完了させるため、連携して利用する必要があるだろう。コンピュータリソースという語は、一般的に、コンピュータプロセッサ、ネットワーク帯域、及び、これらの周辺機器のリソースを指す。ソフトウェアを用いるためのライセンス許可などの他のリソースもまた、リソースといってもよい。コンピュートファームは、インターネットトラフィックを処理する目的などのため、複数の連携したコンピュータを含んでもよい。ウェブ検索サイトＧｏｏｇｌｅ（登録商標）は、ネットワークトラフィック及びインターネット検索を処理するのに用いられるコンピュートファームを有する。
【０００４】
グリッド／クラスタリソース管理は、一般的に、演算環境にサブミットされたグリッドアプリケーションやジョブをできるだけ効率的に処理するために、要求を確認し、リソースをアプリケーションに適合させ、それらのリソースを割り当て、グリッドリソースをスケジューリングし、経時的に監視するプロセスを指す。各プロジェクトまたはジョブは、異なるリソースを利用するので、一般的に固有である。例えば、コンピュータプロセッサ及びディスクスペースを利用するジョブもあれば、広いネットワーク帯域幅及び特定のオペレーティングシステムを必要とするジョブもある。特定のジョブまたはリソースの要求に対してリソースを割り当てる課題に加えて、管理者にとって、利用できるリソース、演算環境及び利用できるリソースの現在の状態、及び、様々なユーザのリアルタイムの競合する要求を明確に理解することは困難である。このプロセスの一態様は、ジョブに対してリソースを予約する能力である。クラスタマネージャは、リソースを予約して、クラスタが約束されたサービス品質でジョブを処理できるようにする。
【０００５】
クラスタ及びグリッドの一般的な背景情報は、多くの出版物に見られるだろう。例えば、非特許文献１及び非特許文献２を参照のこと。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ジャレック・ナブルジスキ（Jarek Nabrzyski）、ジェニファ・Ｍ．スコフ（Jennifer M. Schopf）、ジャン・ウェグラルツ（Jan Weglarz）、「グリッドリソース管理、最新技術と将来動向（Grid Resource Management, State of the Art and Future Trends）」、クルワ・アカデミック出版社（Kluwer Academic Publishers）、２００４年
【非特許文献２】ウィリアム・グロップ（William Gropp）、ユーイング・ラスク（Ewing Lusk）、及び、トーマス・スターリング編集（Thomas Sterling）、「リナックスによるベオウルフ・クラスタ・コンピューティング（Beowulf Cluster Computing with Linux）」、マサチューセッツ工科大学（Massachusetts Institute of Technology）、２００３年
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本願の親出願には、基本的な演算環境及び異なるリソースタイプにわたるリソースの同時割当について詳細に記載されている。親出願では、リソースが利用可能になる時間を調べ、要求に関連したウォールクロック時間制限（wall clock limit）を調べ、要求を開始でき、かつ、ウォールクロック時間制限を満たしている様々な時間を調べることで利用可能範囲を開始範囲に変換することにより、予約、または、予約範囲を算出する。図２Ａ及び図２Ｂは、様々なノードの利用可能範囲を分析し、ジョブまたはジョブの一部がリソースの消費を開始できる時間に関連した開始時間範囲を特定するプロセスを示す。この処理は、環境におけるリソースの完全な利用を達成できるほど、完全に演算環境を分析できない可能性がある。演算環境を分析して、異なるタイプのリソースを同時に割り当てる領域において、さらなる改善が必要である。
【０００８】
本発明のさらなる特徴及び効果は、以下に記載されるが、一部は記載から明らかであるか、本発明の実施によって理解されるだろう。本発明の特徴及び効果は、特に添付の請求の範囲に指摘された機器及び組み合わせによって実現されるだろう。本発明のこれら及び他の特徴は、以下の記載及び添付の請求の範囲からより完全に明らかになるか、ここに記載される本発明の実施によって理解されるだろう。以下に記載する原理を利用できるソフトウェアアプリケーションの例として、クラスタリソース社（Cluster Resources Inc.）のＭｏａｂ（登録商標）Ｗｏｒｋｌｏａｄ  Ｍａｎａｇｅｒまたは他のソフトウェア製品がある。
【課題を解決するための手段】
【０００９】
本発明は、少なくとも、システム、方法及びコンピュータ可読媒体の実施形態を含む。親出願は、演算環境内でリソースを同時に割り当てるためのシステム及び方法の実施形態を開示している。演算環境は、グリッド、クラスタ、または、ワークロードマネージャの管理制御下の演算装置の他の分類でもよい。本発明の方法は、第１タイプのリソースの予約要求を受信し、第１タイプのリソースに関連した制約及び保証を分析する。本発明を実施するシステムは、第１タイプのリソースの要求を満たす第１グループのリソースを特定し、第１リストに情報を記憶し、第２タイプのリソースの予約要求を受信し、第２タイプのリソースに関連した制約及び保証を分析し、第２タイプのリソースの要求を満たす第２グループのリソースを特定し、第２リストに情報を記憶する。最後に、本システムは、第１グループのリソースと第２グループのリソースとの同時割当パラメータを算出し、算出された第１グループのリソース及び第２グループのリソースの同時割当パラメータに従ってリソースを割り当てる。このプロセスでは、割り当てられる各リソースの実行速度またはジョブの各部分の完了時間についての情報は含まない。従って、この情報は有用であるが、状況次第で最適ではないことがある。
【発明の効果】
【００１０】
上述したように、リソースが利用可能になる時間を調べ、要求に関連したウォールクロック時間制限を調べ、要求を開始でき、ウォールクロック時間制限を満たしている様々な時間を調べて利用可能範囲を開始範囲に変換することによって予約を算出する現在のプラクティスは、最適ではない。この分析は、割り当てられる各リソースの実行速度についての情報を含まない。リソースの同時割当をさらに向上させる提案された方法は、演算環境内でリソースの要求を受信し、演算環境内で、要求を処理する少なくとも１つの完了時間を決定し、決定された少なくとも１つの完了時間に基づいて、演算環境内でリソースを予約する。このアプローチの利点は、システムがまだ現在のリソース情報を有している間に、予め完了時間を決定するための情報を手に入れることができることである。
【００１１】
別の態様では、やはり開始時間を用いるが、ジョブによって消費される各リソースの相対速度を含む。さらに別の態様では、開始時間、終了時間またはハイブリッド分析のいずれが、ジョブ及び／または演算環境により効率的か、または、より適切かをシステムによって判断してもよい。この場合、判断は、リソースが、親出願のように、要求に対して開始時間の分析に基づいて予約されるのか、または、完了時間に基づいて予約されるのかについてのシナリオを予備分析するものであってもよい。また、分析は、両方のアプローチの混合に基づいて行われてもよい。いずれにしても、分析は、ジョブによって消費される必要なリソースの予約が２つのアプローチのうちいずれかで行われるべきか、または、混合したアプローチを用いて行われるべきかを判断するために行われる。
【図面の簡単な説明】
【００１２】
【図１】ジョブに対して各ノードに割り当てられた最大時間を示す図である。
【図２Ａ】ノードごとの範囲分析を示す図である。
【図２Ｂ】開始時間範囲のマッピングを示す図である。
【図２Ｃ】完了時間のマッピングを示す図である。
【図２Ｄ】完了時間分析を用いた利点を示す図である。
【図３】様々なＳＭＤまたはＭＭＰコンテキストを有するノードを示す図である。
【図４Ａ】本発明の方法の実施形態を示す図である。
【図４Ｂ】本発明の方法の実施形態を示す図である。
【図５】本発明の別の方法の実施形態を示す図である。
【図６】本発明のシステムの実施形態を示す図である。
【発明を実施するための形態】
【００１３】
本発明の上述した効果及び特徴、及び、他の効果及び特徴を得る方法を説明するため、簡潔に説明した本発明を、添付の図面に図示される具体的な実施形態を参照して、より詳細に説明する。これらの図面は、本発明の代表的な実施形態を図示しているだけであり、本発明の範囲を限定するものではないことを理解されたい。本発明をさらに具体的に詳細に添付の図面を用いて説明する。
【００１４】
本発明の様々な実施形態を以下に詳細に説明する。特定の実施について説明するが、これは、説明の目的のためであることを理解されたい。当業者は、本発明の趣旨及び範囲を逸脱することなく、他の構成要素及び構成を用いてもよいことを理解するだろう。
【００１５】
本発明の「システム」の実施形態は、ワークロードマネージャまたはソフトウェアモジュールが本発明のステップを実施できるようにする必要なハードウェア及びソフトウェア部品を含む演算装置を含んでもよい。上述したように、クラスタリソース社（Cluster Resources）のＭｏａｂ（登録商標）Ｗｏｒｋｌｏａｄ  Ｍａｎａｇｅｒまたは他のＭｏａｂ（登録商標）ブランドのソフトウェアは、ここに記載される原理を利用できる。図６の例を用いて示される演算装置は、１つ以上の中央処理装置、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードディスクなどの記憶装置、他の演算装置とのネットワーク構築を可能にするモデムやイーサネット（登録商標）などの通信手段、様々なハードウェア素子間のデータ伝送を提供するバス、キーボード、ディスプレイ、オペレーティングシステムなどの既知のハードウェア素子を含んでもよい。本発明の特定のシステムの実施形態は、特定のハードウェア素子を有すると限定されることはなく、請求の範囲に記載されるように演算装置が動作する場合、既知のまたは将来開発されるハードウェア構成が、本発明の範囲内で検討される。これらの原理に従って管理されるワークロードを有するクラスタやグリッドなどの演算環境もまた、実施形態に含んでもよい。特定の機能を果たすモジュールは、１つ以上のハードウェア素子を制御するソフトウェアを含んでもよい。
【００１６】
参照により本願に援用される親出願は、演算環境へのジョブのサブミット、及び、クラスタまたはグリッド環境に対するワークロード管理に関する基本的なプロセス、さらに、開始時間に基づく同時割当プロセスについての詳細も含む。従って、本願では、本願の主題を論じる。例によって示される「リソース」は、プロセッサ、データストレージ、ＲＡＭ、通信帯域幅、ライセンス権限などでもよい。その後、リクエスタが、リソースの要求を提出してそれらのリソースを消費する「ジョブ」を実行してもよい。
【００１７】
本発明の一態様は、システムがリソースの要求を評価する方法を変更し、割当のために評価されるリソースのリストを評価して、要求ごとに、相対的拡張性または速度を調べる。すなわち、システムは、ノードまたはリソースの絶対値または属性を調べるだけでなく、現在処理されている要求に似た特徴のワークロード要求を満たすか、各ノードまたはリソースの有効性を調べる。システムがその情報を有すると、その要求に対して、最悪の場合の拡張性または実行時間、及び、検討されるあらゆるタイプのリソースを調べることができる。システムが、これらのリソースの消費に関わる有効最小拡張性または速度を有すると、実行範囲を決定するのにウォールクロック時間制限を組み込むだけでなく、実際、ジョブがどれくらいの時間、実行されるか、及び、ウォールクロック時間制限がどれくらい拡大縮小されるかを判定する速度係数を組み込むことができる。従って、システムが、拡大縮小されたウォールクロック時間制限を認識すると、完了時間を判定し、開始時間範囲に対して完了時間範囲を返す。
【００１８】
本発明は、マルチリソース要求などの特定の要求が実行できる時間枠及びリソースセットを判定する、高度な予約範囲選択を改良する。以前の取り組みでは、この改良は、リソースが実際に利用できるようになる利用可能範囲を決定し、その利用可能範囲を、ジョブが実際に開始でき、完了のための十分なリソースを有すると保証された時間を示す利用可能時間枠の総範囲に変換することによってなされた。ここで、システムが利用可能時間よりも完了時間を組み込むようにアルゴリズムが改良された。ハイブリッド分析を適用してもよい。このアプローチの主な効果は、システムが、複数のリソース及びその関連する要件を分析し、全てのリソースが完了できる、ジョブごとに固有のスケーリング情報または様々なヘテロジニアスな（heterogenesis）リソース拡張性情報を組み込んだ時間枠を判定することである。
【００１９】
図１は、２４０単位すなわち２４０秒の、ウォールクロック時間要件を有する要求またはジョブの例を示す。演算環境でリソースを消費するようにサブミットされたジョブは、最も遅いシステムと同じ程度の速さで実行されるだけである。図１は、様々なノードＮ1、Ｎ2、Ｎ3及びＮ4、及び、ウォールクロック時間制限に対する相対時間を示す。最も遅いリソースは、１．０と表され、要求を２４０の時間単位で処理することを意味する。このプロセスの第１ステップでは、リソースの要求に対して、システムが、要求を実行できる、要求に適合したリソースを分析する。また、システムは、潜在的に要求を満たす、ワークロードを有さない実行可能なリソースを探してもよい。システムが、リソースのリストを構築すると（この場合、Ｎ1−Ｎ4が、より大きなリソースセットから選択されると）、それらのリソースをそれぞれ分析して、実効速度、または、演算態様を実行する能力、または、要求Ｊ1の要件を満たす能力を判定する。図１に示すように、ノード１は、１．０の相対速度成分を有する。ノード２は、Ｊ1をより速く処理でき、１．５の速度を有する。１．５という速度は、２４０を１．５で割ることにより計算され、１６０が得られる。これは、Ｎ2が、ジョブを２４０単位ではなく、１６０の時間単位で処理できることを意味する。Ｎ3は１．２の速度を有し、Ｎ4は１．０の速度を有する。このように、これらの項目は、それぞれ、要求Ｊ1を処理する個々のノードの能力を表す。これらの時間は、ノードを表してもよいし、他のリソースまたはリソースの分類を表してもよい。例えば、リソースのクラスタ、及び、グリッド内の他のクラスタに対する速度でもよい。図１のこれらの値は、実効時間を判定するためのウォールクロック時間の速度の区分を示す。
【００２０】
利用可能範囲は、リソースが他に消費されたり、専用になったりしていない時間に関する。図２Ａは、ノード単位の利用可能範囲１０２、１０４、１０６、１０８、１１０、１１２、１１４、１１６、１１８、及び１２０を示す。これらは、例えば、これらのノードのプロセッサの経時的な利用可能性を表してもよい。この例では、４つのノードがある。ジョブＪ1を、例を用いて示す。先願では、システムは、これらの全ての利用可能範囲を、（ここでは図２Ｂ、親出願では図２Ｂに示される）累積利用可能範囲に単純に崩していた。図２Ａの利用可能範囲のタイミングと図２Ｂに示される開始時間範囲との相関に注意されたい。これらは、ノードごとの範囲であり、累積利用可能範囲を表す。
【００２１】
プレフィルタリングは、図２Ｂに示す利用可能範囲で行ってもよく、短い範囲１１８など、十分なリソースをジョブＪ1のウォールクロック時間制限にわたって利用できるほど十分に長くないアイテムを削除する。従って、このプレフィルタリングでは、範囲１１８などの、分析に含まれるべきではない範囲の部分の削除などのタスクを行う。（図２Ｂ及び図２Ｃは、図２Ａの範囲のフィルタリングを示さない。）
【００２２】
一時的に図３を参照する。図３は、複数の特徴を有する単一ノード３０２を示す。このノードは、クラスタとして扱われる。このように、このクラスタ内に、ノードがあってもよい。本発明の一態様では、対称型マルチプロセッシング（ＳＭＰ，ｓｙｍｍｅｔｒｉｃ  ｍｕｌｔｉ  ｐｒｏｃｅｓｓｉｎｇ）及び大規模マルチプロセッシング（ＭＭＰ，ｍａｓｓｉｖｅｌｙ  ｍｕｌｔｉ−ｐｒｏｃｅｓｓｉｎｇ）に対する異なるアプローチがある。ＳＭＰがある場合、システムは、上述したようなフィルタリングを行わないことが好ましい。ＳＭＰは、あるリソースまたはノードが、全て同じマシンにあり、システムが、実際、ユーザに意識させずに、実行中のアプリケーションを「覆いの下で」ある場所から別の場所へ移動させることができることを意味する。コンテキストが分散しているか、あるいはＭＭＰコンテキストである場合、システムは、ジョブごとに、または、事前のウォールクロック時間制限に従ってフィルタリングすることが好ましい。処理がＳＭＰと同じマシンに残っている場合、例えば、図３に示すように同じマシン３０４の４つの異なるノードがあってもよい。また、図３は、単一ノードが、４つの積を有する、または、ＭＭＰコンテキストでは、それぞれ１つの積を有する４つのノード３０６Ａ、３０６Ｂ、３０６Ｃ及び３０６Ｄを有する分類３０４としてクラスタ３０２を示す。ＭＭＰのシナリオでは、システムが時間範囲を崩し、処理を続け、フィルタリングを行っても行わなくてもよい。コンテキストがＳＭＰの場合、システムはフィルタリングを行ってから崩すことが好ましい。ここで基本的なポイントは、アプローチがＳＭＰとＭＭＰのどちらに関連しているかに基づいて、システムがフィルタリングを行うか行わないか、及び、どの順序でフィルタリングを行うか及び崩すかを変更してもよいことである。
【００２３】
既に述べたように、本発明の一態様は、完了時間範囲を調べることである。図２Ｂは、親出願のアプローチの累積利用可能開始範囲を示す。例えば、塞がれた領域２００、２０２、２０４、２０６及び２０８は、これらの期間、ジョブを開始できないので利用できない領域を示す。ジョブは完了に時間がかかるので、利用可能範囲の終わりに近すぎる領域では、開始できない。これらの領域を塞ぐのに、図１に示される拡大縮小された制限時間を用いても、用いなくてもよい。システムは、ジョブがどのくらいの時間を必要とするか、及び、完了範囲を調べる。システムは、完了時間範囲を分析するので、この情報を、異なるウォールクロック時間制限を有する別のシステムと併合することができ、この容量を自動的に組み込んだ分析をすることができ、効果的な同時割当完了範囲を返す。
【００２４】
図２Ｂは、時間的または空間的な同時割当のため、実行時間を開始時間範囲に組み込むことを示す。ブロック２００、２０２及び２０４は、それぞれ、塞がれた空間を示し、利用可能範囲に関連するが、開始範囲に関連しない空間を示す。利用可能範囲を開始範囲に変換するプロセスは、基本的に、その範囲の終わりからタスクのウォールクロック時間を差し引くプロセスである。範囲は、初めは利用可能範囲として、開始時間及び終了時間から成る。範囲が開始時間に変換されると、ウォールクロック時間を引いた開始時間から終了時間までの範囲になる。これにより、システムが、ジョブを利用可能範囲内でいつ開始し、終了できるかを効果的に知ることができる。注意すべき重要な点は、各範囲が、異なるリソースまたは異なるラックを評価しているので、異なるウォールクロック時間を潜在的に有し、特定のタスクを実行するのに必要な時間に依存するということである。これは、２つの異なる要素に基づいている。１つは、本質的にタスク自身は、異なる時間を要する。あるタスクは別のタスクよりも複雑かもしれない。或いは、システムが複数のリソースを１つの要求に割り当てると、タスクを処理するリソースの実効速度に基づいて、ウォールクロック時間が変わる。例えば、１時間かかるジョブがあり、相対速度係数１．０の速度で実行するプロセッサの場合、システムが同じタスクを係数２．０の速度を有するマシン上で処理するならば、半分の時間、すなわち、３０分で完了することができるだろう。別のシナリオでは、相対実効速度０．５のマシンで処理する場合、２時間で処理するだろう。開始時間範囲の生成に関連するアルゴリズムに、リソースのタスクの実効ウォールクロック時間を適切に組み込めば、システムは、自動的にマシンの速度情報を範囲分析及び同時割当のデフォルトの計算に引き継ぐか、あるいは組み込むことができる。
【００２５】
従って、本発明の一態様は、改良された同時割当マッピングにおいてウォールクロック時間を考慮することである。改良された同時割当マッピングでは、タスクを処理するリソースの相対的なマシン速度を、適切に反映する。最終的に、各割り当てられたコンピュータリソースが相対速度を考慮してタスクを完了できることを保証する予約を得られるだろう。複数処理要求を同時に割り当てる場合に基づくこのアプローチの２番目の利点は、ある要求が別の要求よりも時間がかからないことである。システムは、これらの要求をそれぞれいつ開始するかを決定し、全てを同時に完了させることができる。実際、システムは、様々な速度の複数のコンピュータリソースを必要とする単一タスクにおいて、同時に両者を混合し、適合させ、異なる速度を本来必要とする複数のタスクと混合することができる。
【００２６】
従って、最終的に、システムが予約を行う場合、及び、ワークロードがリソースを消費する場合、ワークロードマネージャは、演算環境において、リソースをより有効に利用することができる。このアプローチにより、ワークロードマネージャが、空間及び時間の両方で、タスクを無事に完了することができる、より多くの穴またはより多くの場所を見つけるという、より良いジョブができるので、利用率が改善する。別のアプローチでは、単に論理を逆にして、開始時間範囲とは対照的に、完了時間範囲に分析の基礎を置く。しかし、開始時間範囲だろうが、終了時間範囲だろうが、問題ではないだろう。システムは、リソースごとに個々のタスクの相対的なウォールクロック時間を考慮して、同じ手順を用いて、最適な予約をいつ、どこにすべきかを決定する必要がある。
【００２７】
システムが、完了時間範囲を用いるのであれば、全てのタスクが、同時に開始するのとは対照的に、同時に完了するように、複数のリソースに分散してタスクを開始することができる。これらの方法（開始時間及び完了時間）は両方とも、ジョブを実行できるのに十分な時間、リソースを確実に利用できるが、完了時間範囲では、システムが、全てのタスクを確実に同時に完了させる。図２Ｄは、完了時間分析を用いた利点を示す。行２３０は、開始時間Ｓ１及び終了時間Ｅ１を有するように示されている。ウォールクロック時間は考慮されていない。ジョブを処理するために必要な、予約されたリソースは、Ｓ１からＥ１までの時間全体にわたって予約される。しかし、完了時間分析では、完了時間範囲が決定されるか、または、潜在的目標時間に達すると、システムは、全てのタスクを完了でき、全てのリソースが空間及び時間の両方において利用できること、そして、その決定が記録されたことを知り、実際にいつタスクを開始すべきか正確に決定することができる。このように、終了時間Ｅ１からウォールクロック時間２３４を引いた、タスクの新しい開始時間が、新しい開始時間Ｓ２が示された行２３２に表される。Ｓ１からＳ２までの時間は、時間２３６として示され、他のジョブのために残しておいたり、用いられたりしてもよい時間、または、リソースを表す。この分析を、リソースの要求に関わる様々なタスクにそれぞれ行えば、システムは、単に各リソースから有効実行時間を引くことで、これらのタスクの実際の開始時間を変更することができるだろう。
【００２８】
開始時間分析と完了時間分析のどちらを用いるかについての判定は、システムが行ってもよい。例えば、ジョブは、読み出された日付及び格納要件のため、様々なタスクと同時に終了する方が、適しているかもしれない。ジョブは、全てのタスクを同時に開始する必要があるかもしれないし、そのような要件は全く関係ないかもしれない。このように、ジョブ、演算環境、ユーザ証明書、及び／または、他の要素の分析が、開始時間または終了時間またはハイブリッド分析の選択に関与してもよい。ユーザ証明書は、ユーザに対する利益と演算環境の構成または最大利用率とに対立がある場合、システムに、ユーザのジョブに有利なように、開始または終了時間を選択させてもよい。
【００２９】
また、システムは、開始時間分析と完了時間分析とを交互に行ったり、混合したり、適合させたりしてもよい。それらは、両方とも様々な種類のタスクで有用である。完了時間にとって重要なことは、完了できること及び全てのリソースが利用できる場所を見つけることができることである。あるタスクは、全てを同時に開始する方法を利用する方が良く、このことは、開始時間範囲が、完了時間範囲よりも良いことを示す。他のタスクは、全て同じ入力データから処理され、入力データ記録がある時間まで利用できない場合、完了時間範囲が最も良い。それらのタスクが両方とも結果を生成する必要があり、システムの利用可能なディスクスペース量が限定されている場合には、開始時間範囲を選択してもよく、ユーザは、最終データを同時に送信するように完了時間範囲を選択してもよい。
【００３０】
上述したように、本発明の一態様では、知能の一部が、同時割当分析に開始時間または完了時間のどちらを用いるかを選択する選択構成要素を含む。ユーザが、好みの分析、または、独自の分析、または、どの種類の演算を行うかの表示を入力するために、手動入力オプションを設けてもよい。例えば、開始時間分析は、リソースが全て最初に消費され、タスクに全て引き取られるとすぐにリソースを解放することができるので、前もって必要なリソース量を最小限にすることができる。完了時間分析は、最終結果が、最大のコンシューマリソースであり、システムが、リソースを全て同時に利用可能にして、送信したり記憶したりできるようにしたい場合、選択されてもよい。このように、分析は、ジャストインタイムの開始及び／またはジャストインタイムの終了を含んでもよい。開始時間、完了時間、または、２つの混合のうち、いずれに基づいて同時割当するかの判断は、ジョブ、リソース、ユーザ選択、ユーザ支払い、演算環境の状況、ユーザ証明書、または、要素の他の混合のうち少なくとも１つに基づいて行われてもよい。
【００３１】
混合のアプローチでは、システムは、まず、開始時間または完了時間に基づく排他的なアプローチが最適かどうか判定してもよい。この分析は、演算環境最適化、ユーザ証明書、（データ検索、書き込み及び処理のためのデータの必要性、プロセッサの必要性、タイミングの必要性などの）ジョブの構成要素、使用許諾、または他の管理上の必要性または要求などの１つ以上の要素に基づいて行われてもよい。分析によって、開始時間または完了時間のみを用いるという結果が出た場合、システムは、リソースを予約し、演算環境でジョブを処理することを進める。分析により、ハイブリッド分析を用いるという結果が出た場合、システムはジョブのある部分では開始時間分析を利用し、別の部分では完了時間分析を利用してもよい。これは、ジョブの異なる部分に対して、２つの別の分析を用いて、別々にリソースを予約することによって行われてもよいし、別の方法で行ってもよい。その結果、リソースは予約され、システムは、それに応じてジョブを処理する。拡大縮小されたウォールクロック時間データは、本来、これらのプロセスに用いられ、システム性能を改善するが、必要ではない。
【００３２】
システムは、このような分析及び選択を自動的に設定してもよい。システムは、どのリソースに基づけば最も制約されるか、動的に判断してもよい。管理者によってジョブごとに選択されるように設定してもよい。ユーザプロフィールによって選択してもよいし、システムのスケジュールの歴史的に学習された情報に基づいて選択してもよい。さらに、ユーザは、このような最適化に、ジョブごとに、要求ごとに、または、他の方法で、対価を支払ってもよい。
【００３３】
次のステップでは、システムが相対速度を実際に判定し、実行可能な、または、利用できるノードを選択すると、システムは、これらのリソースが、他のワークロードまたは他の目的のために既に行った他のコミットメントを分析する。これは、ノードＮ1について、ブロックが出現する特定の時間枠において、リソースがＪ1のある要素を実行するのに利用できることを表す図形１０２、１０６及び１０８によって表される。Ｊ1を完了できることを必ずしも意味するわけではなく、利用できることだけを示す。Ｎ2が評価され、１０４、１１０及び１１２によって表される時間枠が利用できることを示す。Ｎ3からＮ4についても同様である。これらは、ノードごとの利用可能範囲を構成する。現在のモデルは、利用可能範囲または開始時間範囲に基づいており、経時的なリソース利用可能性が統合または総計され、図２Ｂに示されるグラフを生成する。次に、システムは、ジョブが潜在的に開始できる時間枠を調べ、２００、２０２、２０４、２０６及び２０８で表されるスペースを削除する。そのため、これらは、実際に開始するアプリケーションに利用できない時間を示す。
【００３４】
ジョブが開始できる時間を示す図２Ｂのアプローチでは、相対速度を、生成される範囲グラフに組み込んでいない。一態様では、図２Ａの範囲を利用可能範囲に変換する代わりに、図２Ｃに示すように、システムは、範囲を潜在的に完了時間範囲に変換する。これは、アプリケーションまたはジョブが潜在的に完了できる時間を表す。実行できない時間枠は、２１６、２１８、２２０、２２２、２２４及び２２６である。これらは、リソースを消費するのに必要な時間であるため、特定のジョブを開始できない時間枠である。システムが、ジョブを完了できる時間についての情報を有すると、システムは、別の要件または別のテストと統合し、マルチリソースタイプのリソースまたは複数の集合体のリソースの同時割当要求を判定する。異なるリソースまたは異なるパラメータに対して、このような統合は、ジョブまたはリソースが、様々な拡張性要因または様々な速度要因を有していても、ジョブを完了できる時間枠を表す。この情報は、組み込まれ、生成された情報は、リソースが実際に利用でき、統合できる時間を策定するのに用いることができる。統合が行われると、最終同時割当範囲が設定される。その情報は、引き出すことができ、拡大縮小されたウォールクロック時間制限を再設定することにより、生成された開始時間を、逆に判定してもよい。システムは、検討される個々の要求について、関連する開始時間要求を判定できる。適切なリソースを予約でき、それらの予約されたリソースを消費してジョブを処理できる。
【００３５】
このコンテキストの拡張性は、速度、または、個々のリソースが特定の要求に対して速度要素をどのくらい拡大縮小するかに関する。そのため、このアプローチでは、それぞれ、同じリソースに対して異なる速さで処理するノードまたはプロセスの複数のラックを有するだけでなく、異なるリソースに対して異なる速さで処理する複数のラックも有することができる。システムが関係のある開始点を設定すると、拡張性が分かっているので、その位置を得るのに必要な開始時間を逆算することができる。
【００３６】
終了時間の知識に基づいて算出された開始時間の利用可能範囲は、図２Ｃのグラフ２１２で影付きになっている。システムは、全てのリソースについて、全ての要求を同時に満たすことができる時間枠を探す。システムが、時間枠が重複していると分かると、ジョブがいつ完了するか、どれくらいの速度で処理するか、及び速度が分かるので、ジョブまたは要求を実行するのに必要な利用可能な開始時間、または、開始時間範囲を算出する。
【００３７】
実際には、様々な演算の開始時間は、同時に開始しがちである。若干早く完了するものもあれば、予定期限に完了するものもある。しかし、全てまたはほとんどが、完了する。システムは、全てのリソースの最悪の場合のシナリオも調べているので、全てがスペース２１２内で収まるように保証する。
【００３８】
親出願のシナリオでは、分析において、ジョブは適切な時間で開始するが、割り当てられた利用可能時間後に終了するジョブもあった。この場合、それらのジョブを適切に統合することはより困難である。なぜなら、それらのジョブを適切に統合するには、全てを最悪の場合の拡張集合にマッピングする必要があるからである。そのため、予想される最悪のノードに予想される最悪のラックとなる。しかし、本発明のアプローチは、このように分析を無理に適用していない。
【００３９】
図４Ａは、本発明の方法の実施形態を示す。好ましい実施形態は、演算環境内でリソースの要求を受信し（４０２）、要求によって必要とされた少なくとも１つのリソースタイプに関連する少なくとも１つの完了時間を決定し（４０４）、決定された少なくとも１つの完了時間に基づいて演算環境内でリソースを予約する（４０６）方法による、演算環境でのリソースの予約に関する。別の実施形態が図４Ｂに示され、図４Ｂでは、演算環境内でリソースの要求を受信し（４１０）、各リソースマシンに対する要求の少なくとも一部の処理に関連する少なくとも１つの相対リソース速度を決定し（４１２）、決定された少なくとも１つのリソース速度に基づいて演算環境内でリソースを予約する（４１４）。
【００４０】
本発明の方法の態様は、さらに、要求に対する完了時間範囲を決定する。少なくとも１つの完了時間の決定は、少なくとも部分的に、ジョブ固有のウォールクロック時間拡大縮小情報に基づいてもよい。本発明を実施するシステムは、さらに、要求に対して演算環境内で実行可能なリソースを特定し、要求を満たす実効速度について特定された実行可能なリソースをそれぞれ分析してもよい。例えば、演算環境の様々なリソース、プロセッサ、ハードドライブ、通信帯域幅などを、要求を満たす各実効速度についてそれぞれ分析し、演算環境内で効率を最大化するのに、より効率的でより効果的な予約の判断に、実効速度または相対リソース速度を利用してもよい。本方法は、さらに、各特定されたふさわしいリソースに対するワークロードコミットメントを分析し、ワークロードコミットメントの分析は、ノードごとまたはリソースごとの利用可能範囲を表す。ノードごとまたはリソースごとの利用可能範囲は、潜在完了時間範囲に変換されてもよい。以降のステップは、潜在完了時間範囲を少なくとも１つの他の要求と統合し、要求を満たすリソースの複数の集合体に対して同時割当を判定してもよい。このような統合は、演算環境の様々なリソースの潜在完了時間の少なくとも２つのマッピングの統合でもよい。
【００４１】
上記の方法は、さらに、要求に対して拡大縮小されたウォールクロック時間制限を用いて、要求に関連した少なくとも１つの開始時間を決定してもよい。要求に対して少なくとも１つの完了時間は、どの特定のリソースに対しても最悪の場合のシナリオに基づいて決定されてもよい。例えば、帯域幅範囲が１００ＭＢから１０００ＭＢであれば、システムは、帯域幅１００ＭＢに基づいて判定してもよい。リソースに対してさらに分析をして、時間帯や予約されたリソースを含むユーザ履歴などの他の要素に基づいた、平均リソース性能または予測性能などの１つ以上の他の要素に基づいて、判定を行ってもよい。
【００４２】
図５は、別の方法の実施形態例を示し、演算環境内でリソースを同時に割り当てる方法を示す。本方法は、第１タイプのリソース及び第２タイプのリソースを必要とするリソースの要求を受信し（５０２）、第１タイプのリソースに関連した完了時間を分析し（５０４）、第２タイプのリソースに関連した完了時間を分析し（５０６）、第１及び第２タイプのリソースに対する完了時間の分析に基づいて、第１タイプのリソースと第２タイプのリソースとの間で同時割当マップを生成し（５０８）、生成された同時割当マップに従ってリソースを予約する（５１０）。同時割当マップの生成は、第１要求及び第２要求を同時に満たすことができるリソースの量を減らしたマップを特定してもよい。同時割当マップは、第１要求及び第２要求を満たす利用可能なリソースが存在するすべての時間枠を含んでいてよい。このプロセスでは、考えられるタイプのリソースは、演算リソース、ディスク記憶リソース、ネットワーク帯域幅リソース、メモリリソース、使用許諾リソース、ユーザの好み及びユーザデータのうち少なくとも１つから構成されてもよい。
【００４３】
同時割当マップの生成は、さらに、第１タイプのリソース及び第２タイプのリソースのそれぞれの利用可能性の共通部分を特定してもよい。第１要求及び第２要求の両方が同時に満たされて交わる時間枠を判定し、交わる時間枠を表すイベントのアレイを生成することで、同時割当マップを生成してもよい。イベントのこの生成されたアレイは、リソース量、リソースの質、時間枠、情報の質及びコストのうち少なくとも１つを含んでもよい。
【００４４】
図４Ａ及び図４Ｂの実施形態と同じように、図５に示される実施形態は、完了時間に基づくのではなく、要求の少なくとも一部を処理するのに必要な、少なくとも１つの相対リソース速度に基づいてもよい。このように、この相対または実効リソース速度を、演算環境内で少なくとも１つのリソースに対して分析してもよく、同時割当マップを第１及び第２タイプのリソースのリソース速度に基づいて生成してもよい。この実効速度を、単独で、または、完了時間に関連して利用して、同時割当マップを生成してもよい。また、上述したように、開始時間または完了時間のどちらを同時割当分析に用いるかの判定を、相対リソース速度または実効リソース速度の情報に関連して適用し、同時割当要求が、リソースの要求用に最適化されるようにしてもよい。これらの様々な方法は、さらに同時割当要求を改善し、リソースの利用を最大化するために、混合アプローチを利用するかの分析または判定を含んでもよい。このような分析は、さらに、同時割当要求に対して分析及び準備をするのに、リソースの最大利用、ジョブパフォーマンス、ユーザパフォーマンス、ユーザ利便性または他の関心のあるバランスに重きをおいてもよい。
【００４５】
図６を参照すると、本発明を実施するシステムの例は、処理装置（ＣＰＵ）６２０と、リードオンリーメモリ（ＲＯＭ）６４０やランダムアクセスメモリ（ＲＡＭ）６５０などのシステムメモリを含む様々なシステムコンポーネントを、処理装置６２０に連結するシステムバス６１０とを含む汎用演算装置６００を含む。他のシステムメモリ６３０も利用可能であってもよい。本発明は、１つ以上のＣＰＵ６２０を有する演算装置上で、または、ネットワーク演算装置のグループ、クラスタまたはグリッド上で動作し、より大きな処理能力を提供してもよい。システムバス６１０は、様々なバス構造を用いた、メモリバス、メモリコントローラ、周辺機器用バス及びローカルバスを含む、様々なタイプのバス構造のいずれでもよい。基本入出力システム（ＢＩＯＳ）は、演算装置６００内の素子間の情報の伝達を助ける基本的なルーティンを含むが、一般的にＲＯＭ６４０に格納される。演算装置６００は、さらに、ハードディスクドライブ６６０、磁気ディスクドライブ、光ディスクドライブ、テープドライブなどの記憶手段を含む。記憶装置６６０は、ドライブインターフェースによってシステムバス６１０に接続する。ドライブ及び関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール及び演算装置６００用の他のデータの不揮発性記憶装置となる。基本的な構成要素は、当業者に既知であり、適切な変更は、装置が小型か、携帯型の演算装置か、デスクトップコンピュータか、コンピュータサーバかなどの装置の種類によって検討される。
【００４６】
ここで説明した環境の例では、ハードディスクを用いているが、磁気カセット、フラッシュメモリカード、デジタル多用途ディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭｓ）、リードオンリーメモリ（ＲＯＭ）、ビットストリームを含むケーブル信号または無線信号などの、コンピュータによってアクセス可能なデータを格納できる他の種類のコンピュータ可読媒体も、動作環境例で用いられてもよいことを、当業者に理解されたい。
【００４７】
演算装置６００とのユーザインタラクションを可能にするため、入力装置６９０は、音声用のマイク、ジェスチャや図形入力用のタッチスクリーン、キーボード、マウス、動作入力装置、音声などのあらゆる入力機構を表す。出力装置６７０は、１つ以上の出力手段でもよい。場合によっては、マルチモーダルシステムによって、ユーザは、複数種類の入力を提供して演算装置６００と通信することができる。通信インターフェース６８０は、一般的に、ユーザ入力とシステム出力を制御し、管理する。本発明は、特定のハードウェア配置上で動作するという制約はないので、ここでの基本的特徴は、ハードウェアまたはファームウェア配置が進歩すれば、改良されたハードウェアまたはファームウェア配置に容易に置き換えられてもよい。
【００４８】
本発明の範囲内の実施形態は、コンピュータ実行可能な命令または格納されたデータ構造を伝達、または、保持するコンピュータ可読媒体も含む。このようなコンピュータ可読媒体は、汎用または専用コンピュータによってアクセスできれば、どんな利用可能な媒体でもよい。限定ではなく一例として、このようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶装置、または、コンピュータ実行可能な命令、または、データ構造の形式で所望のプログラムコード手段を伝達、または、記憶するのに用いられる他の媒体でもよい。情報が、ネットワークまたは（有線、無線、またはその組み合わせのいずれかの）他の通信接続を介してコンピュータに伝達または提供される場合、コンピュータは、その接続をコンピュータ可読媒体として適切に捉える。このように、このような接続は、どれも、適切にコンピュータ可読媒体と呼ばれる。上記の組み合わせも、コンピュータ可読媒体の範囲に含まれるだろう。
【００４９】
コンピュータ実行可能な命令は、例えば、汎用コンピュータ、専用コンピュータまたは専用処理装置に、一定の機能または一連の機能を行わせる命令及びデータを含む。また、コンピュータ実行可能な命令は、スタンドアロン型またはネットワーク環境のコンピュータによって実行されるプログラムモジュールを含む。一般的に、プログラムモジュールは、特定のタスクを行う、または、特定の抽象データ型を実行するルーティン、プログラム、オブジェクト、コンポーネント及びデータ構造などを含む。コンピュータ実行可能な命令、関連するデータ構造及びプログラムモジュールは、ここに開示する方法のステップを実行するプログラムコード手段の例を表す。このような実行可能な命令または関連するデータ構造の特定の配列は、このようなステップに記載された機能を実行する、対応する動作例を表す。
【００５０】
当業者は、本発明の他の実施形態を、パソコン、携帯端末、マルチプロセッサシステム、マイクロプロセッサを用いた、または、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、様々なコンピュータシステム構成を含むネットワーク演算環境で実施してもよいことが分かるだろう。また、実施形態を、タスクが、通信環境を介して、（有線リンク、無線リンク、または、その組み合わせのいずれかによって）連結されたローカル及びリモート処理装置によって行われる、分散演算環境で実施してもよい。分散演算環境では、プログラムモジュールは、ローカル及びリモートメモリ記憶装置の両方にあってもよい。
【００５１】
上記の説明は、具体的な詳細を含んでいるが、請求の範囲を限定すると解釈されるべきではない。本発明の記載された実施形態の他の構成は、本発明の範囲の一部である。従って、添付の請求の範囲及びそれらの法的な同等物は、本発明を定義しているだけであり、具体的な例ではない。
【図１】
2010515155.tif 000003
【図２Ａ】
2010515155.tif 000004
【図２Ｂ】
2010515155.tif 000005
【図２Ｃ】
2010515155.tif 000006
【図２Ｄ】
2010515155.tif 000007
【図３】
2010515155.tif 000008
【図４Ａ】
2010515155.tif 000009
【図４Ｂ】
2010515155.tif 000010
【図５】
2010515155.tif 000011
【図６】
2010515155.tif 000012
【国際調査報告】
2010515155.tif 000013