JP2005234931A - リソース探索方法、及び、クラスタマネージャ装置 - Google Patents

Abstract

【課題】クラスタ間リソース融通のためのリソース探索において、探索にかかる通信量と処理量の低減。
【解決手段】各クラスタの静的リソース情報格納手段を読み出し、条件に該当するリソースを持っている一つ以上の候補クラスタを探索する候補クラスタ探索ステップＳ２０と、上記一つ以上の候補クラスタの各動的リソース情報測定手段による測定を行い、条件に該当するリソースを探索する該当リソース探索ステップＳ３０とを備える。
【選択図】 図４

Description

本発明は、クラスタシステムにおけるリソースの融通を行うためのリソース探索方法、及び、クラスタマネージャ装置に関する。

クラスタシステムは、計算機やディスクなどのリソースを一括管理して、必要に応じてアプリケーションへの割り当てを行なうことで、信頼性・処理性能・リソースの利用率などの向上を図るシステムである。そして、クラスタシステムは、クラスタ内の一台または複数台の計算機上でミドルウェアまたはＯＳの一モジュールとしてクラスタマネージャを動かしてリソースの管理をさせる形態で実現される。

通常のクラスタシステムは、一つのクラスタ内に閉じたリソースの割り当てを行なうものである。しかし近年、処理対象のデータの増大やコスト低減要求によって、一つのクラスタ内だけではリソースが足りない場合に、クラスタ間でリソースの融通を行なうことで、リソース不足に対処したいという要求が現れている。

一般に、アプリケーションを動作させるには、特定のＣＰＵや特定のＯＳが要求される。計算機などのリソースは、この要求を満たすものでなければ利用できない。そのためクラスタ間でリソース融通を行なう場合、利用可能なリソースを、クラスタをまたがって探索する機構が必要になる。探索の際には、アプリケーションが要求するＣＰＵやＯＳの種類などのリソースについての情報(リソース情報)を条件として指定する。

この条件の中には、ＣＰＵの種類のように条件を満たすか満たさないかに二分される離散的条件と、ＣＰＵのクロック数のように最低条件を満たした上でなるべく大きいものがよいといった連続的な条件とがある。これらの情報は、事前に設定ファイルなどの形で記述可能な静的リソース情報である。

これに対し、リソースを借りる側のクラスタとネットワーク的に近い位置にあるリソースといった、リソースを借りる側のクラスタに応じて変化するものや、現在のＣＰＵ負荷といった、時間経過によって変化するものもある。これらの情報は、リソース探索の際にその場で測定する必要がある動的リソース情報である。

従来の単一クラスタ内でのリソース探索については、希望する条件を細かく指定し、その条件に該当するリソースをあらゆるリソースの中から探索するという手法が取られている。現在検討されているクラスタ間リソース融通は、上記のような単一クラスタ内でのリソース探索方法をそのままクラスタ間に拡大したものである。具体的には、借りる側のクラスタが希望するリソースの条件を細かく指定して、その条件に該当するリソースをあらゆるクラスタのあらゆるリソースから探索するというものである。

一方、上記動的リソース情報を利用して最適なリソースを探索する方法として、各クラスタの使用状況、及び、ネットワークリソースの使用状況を時間で正規化してパラメータ化し、該当パラメータ値に基づきアプリケーションジョブを振り分けるクラスタ装置を動的に設定するというものがある（例えば、特許文献１参照。）。
特開２００２−２５９３５３号公報（頁４−頁６、図２、図８）

上述した単一クラスタ内でのリソース探索方法をそのままクラスタ間に拡大したものでは、クラスタをまたがる融通においてリソースの条件を細かく指定し、その条件に該当するあらゆるリソースの情報をあらゆるクラスタについてやりとりするため、通信量や処理量が大きいという問題点があった。特に、上記動的リソース情報を条件としてリソースを探索する場合、リソース探索の際にその場で測定する必要があるため、このような測定をあらゆる探索の際に毎回行うのは、測定のコストが高いという問題点もあった。そのため、事前記述可能な静的リソース情報のみに限定して融通を行うか、それとも高いコストをかけて動的リソース情報までを条件として探索するかの何れかが必要であった。

一方、上記特許文献１には、動的リソース情報だけを利用する技術が記載されており、リソースを借りるクラスタのクラスタノードマネージャ装置がアプリケーションジョブを分配するクラスタを判断するため、他のクラスタの動的リソース情報やネットワークリソースの使用状況の更新が必要となる。これらの情報更新は、各クラスタのノードマネージャ装置において周期的に行われることであるため、通信量や処理量が大きくなるという問題点がある。

従って、本発明は上記問題点を解決するためになされたもので、クラスタ間でのリソースの融通において、リソース探索にかかる通信量と処理量を低減できるリソース探索方法、及び、クラスタマネージャ装置を提供することを目的とする。

上記目的を達成するために、本発明のリソース探索方法は、一つ以上のリソースを有するクラスタを複数備えたコンピュータシステムのリソース探索方法であって、リソース探索される各クラスタに設けられた自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段を参照し、静的リソース情報の条件に該当するリソースを持っている一つ以上の候補クラスタを探索する候補クラスタ探索ステップと、前記候補クラスタに設けられた自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段によって測定された値を参照し、動的リソース情報の条件に該当するリソースを探索する該当リソース探索ステップとを備えることを特徴とする。

また、本発明のクラスタマネージャ装置は、一つ以上のリソースを有するクラスタを複数備えたコンピュータシステムのクラスタマネージャ装置であって、自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段と、自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段と、リソース探索するクラスタマネージャ装置から受信したクラスタ探索要求に応答して前記静的リソース情報格納手段を参照して静的リソース情報の条件に該当するリソースがあるか否かを探索し、該当するリソースがある場合には候補クラスタの情報を前記リソース探索するクラスタマネージャ装置に通知し、前記リソース探索するクラスタマネージャ装置から受信した該当リソース探索要求に応答して前記静的リソース情報格納手段を参照して前記静的リソース情報の条件に該当するリソースを探索し、そのリソースの中で自クラスタ内の前記動的リソース情報測定手段によって測定した値を参照して動的リソース情報の条件に該当するリソースを探索して前記リソース探索するクラスタマネージャ装置へ送信する処理手段とを備えることを特徴とする。

本発明によれば、クラスタ探索によって絞り込んだクラスタを対象にリソース探索を行うため、クラスタ間リソース融通のためのリソース探索にかかる通信量と処理量を低減することができる。

以下、本発明の実施の形態を、図面を参照しながら説明する。
（第１の実施形態）
図１は、第１の実施形態によるクラスタシステムの全体構成を示す。第１の実施形態のクラスタシステムは複数のクラスタ１、２、…、ｎとそれを管理する１つのグリッドマネージャ５０ａが動作する計算機５０とを有し、それらがネットワーク４０によって接続されている。複数の同様なクラスタ１、２、３、…、ｎの中で、クラスタ１を中心にクラスタの構成を説明する。

クラスタ１はクラスタマネージャ１ａが動作する計算機１１とクラスタマネージャ１ａによって管理されるリソース１２、１３を備える。リソース１２、１３は本実施形態では計算機であって、各クラスタ１、２、…、ｎには一つ以上のリソースが含まれている。クラスタマネージャ１ａは、自クラスタ内のリソースについての静的リソース情報を格納する静的リソース情報格納手段１ｂと、自クラスタ内のリソースについての動的リソース情報を測定する動的リソース情報測定手段１ｃとを持つ。これら２つの手段は、クラスタ間融通ではリソースを貸し出せるかどうかを判定する際にのみ利用され、リソースを借りる際には利用されない。本実施形態に示す動作例では、クラスタ１が他のクラスタ２、３、…、ｎからリソースを借りることを想定しているので、クラスタ１の静的リソース情報格納手段１ｂと動的リソース情報測定手段１ｃは利用されない。なお、クラスタマネージャ１ａは、図１のようにリソース１２、１３とは別の計算機上で動作させてもよいし、リソース１２又は１３の計算機上で動作させてもよい。

クラスタ２、３、…、ｎの構成も上述したクラスタ１と同様であるので、その説明は省略する。

本実施形態では、相互にリソース融通を行うクラスタ群全体をグリッドと呼ぶ。本実施形態のグリッド１００にはグリッドマネージャ５０ａを有する計算機５０が設けられ、クラスタ１、２、…、ｎ間のリソース融通の仲介を行なう。グリッドマネージャ５０ａは、ミドルウェアまたはＯＳの一モジュールとして実現される。なお、グリッドマネージャ５０ａは、図１のようにクラスタ１、２、…、ｎに属さない独立した計算機上で動作させてもよいし、クラスタに属する計算機で動作させてもよい。

グリッドマネージャ５０ａは自分が管理する各クラスタ１、２、…、ｎのクラスタマネージャ１ａ、２ａ、…、ｎａへのポインタを保持しており、必要に応じてそのポインタを利用してクラスタマネージャ１ａ、２ａ、…、ｎａに接続することができる。ポインタはグリッドマネージャ５０ａの設定ファイルなどに記述しておいて、グリッドマネージャ５０ａの計算機５０が起動時に読み込んでもよい。または、クラスタ１、２、…、ｎがグリッド１００に参加する際に、クラスタマネージャ１ａ、２ａ、…、ｎａがグリッドマネージャ５０ａに対して参加要求を送信して知らせてもよい。ポインタとしては、たとえばＴＣＰ／ＩＰプロトコルの場合はＩＰアドレスとポート番号が利用できる。

図２には、静的リソース情報格納手段１ｂ、２ｂ、…、ｎｂに格納される静的リソース情報の例を示し、図３には、動的リソース情報測定手段１ｃ、２ｃ、…、ｎｃによって測定される動的リソース情報の例を示す。それぞれの左の列がリソース情報名、右の列が対応する値を示す。

図２の静的リソース情報の例では、ＣＰＵの種類、ＣＰＵのクロック速度、ＯＳの種類、ＲＡＭ容量がそれぞれ記述されている。図２は一つのリソースについての記述であって、各リソース１２、１３、…、ｎ２、ｎ３についてそれぞれこのような静的リソース情報が静的リソース格納手段１ｂ、２ｂ、…、ｎｂに格納されている。そして、リソース１２
、１３、…、ｎ２、ｎ３はそれぞれ一意な識別子で管理される。一意性の範囲は各クラスタ内であってもよいが、他のクラスタへ融通する際に識別子の変更を行なわずに済ませるためには全クラスタで一意な識別子とした方が望ましい。たとえばＴＣＰ／ＩＰプロトコルで接続される計算機であれば、ＩＰアドレスなどを全クラスタで一意な識別子として利用することができる。

図３の動的リソース情報の例では、ＣＰＵ負荷、自クラスタへのホップ数がそれぞれ記述されている。動的リソース情報については、後で具体的に説明する。

次に、図１乃至図４を参照して、本実施形態のリソース探索方法を説明する。図４、は第１のリソース探索方法の動作を示すフローチャートである。図４の一番左の列は、他のクラスタからリソースを借りるクラスタ１のクラスタマネージャ１ａの動作を示しており、その隣の列はグリッドマネージャ５０ａの動作を示している。グリッドマネージャ５０ａの右側の複数のクラスタマネージャは自分のリソースをクラスタ１に貸すクラスタ２、３、…、ｎのクラスタマネージャ２ａ、３ａ、…、ｎａの動作を示している。

図４のリソース探索方法は二つのステップ、即ち候補クラスタ探索ステップＳ２０と該当リソース探索ステップＳ３０より成る。まず、候補クラスタ探索ステップＳ２０を説明する。

クラスタ１のクラスタマネージャ１ａは、静的リソース情報を設定したクラスタ探索要求をグリッドマネージャ５０ａに対して発行する。グリッドマネージャ５０ａは、自分が管理するクラスタのうち、クラスタ探索要求を発行したクラスタ１以外のリソース探索される側のクラスタ２、３、…、ｎのクラスタマネージャ２ａ、３ａ、…、ｎａに前記ポインタを利用してクラスタ探索要求を転送する。

このクラスタ探索要求を受け取ったクラスタマネージャ２ａ、３ａ、…、ｎａでは、それぞれの静的リソース情報格納手段２ｂ、３ｂ、…、ｎｂを探索して、自クラスタ内の貸し出し可能なリソースの有無を判定する。この際、クラスタ探索要求の静的リソース情報に該当するリソースが無ければ貸し出し可能なリソースが無いことは勿論であるが、たとえクラスタ探索要求の静的リソース情報に該当するリソースが有っても、そのリソースを自クラスタで利用したいなどの理由でそれを貸し出し可能なリソースとしないとすることもできる。

このような判定の結果、貸し出し可能なリソースが存在するクラスタ２、３のクラスタマネージャ２ａ、３ａは自クラスタが候補クラスタである旨、貸し出し可能なリソースが存在しないクラスタｎのクラスタマネージャｎａは候補クラスタでない旨の候補クラスタ情報をグリッドマネージャ５０ａに返す。本実施形態では、例としてクラスタ２、３、ｎに限定して候補クラスタ探索と該当リソース探索の動作を説明しており、他のクラスタの場合は説明の簡略化のためにその記載を省略している。

次に、グリッドマネージャ５０ａはクラスタマネージャ２ａ、３ａから受け取った候補クラスタ情報を、クラスタ探索要求を発行したクラスタマネージャ１ａに返す。

なお、グリッド１００に非常に多くのクラスタが参加している場合で、自クラスタが候補クラスタでない場合には、候補クラスタ情報の送信を省略し、自クラスタが候補クラスタである場合にのみ候補クラスタ情報を送信するようにして、候補クラスタ情報による通信量および処理量を削減してもよい。

なお、図４では候補クラスタ情報はグリッドマネージャ５０ａを経由してクラスタ探索
要求を発行したクラスタマネージャ１ａに送っているが、候補クラスタからクラスタ探索要求を発行したクラスタマネージャ１ａへ直接候補クラスタ情報を送る構成としてもよい。

次に、クラスタマネージャ１ａは、各クラスタマネージャ２ａ、３ａ、…、ｎａからの候補クラスタ情報が揃うのを待つ。グリッド１００内のクラスタの数があらかじめ分っていれば、クラスタ数分だけの候補クラスタ情報を待てばよいが、クラスタ数が不明な場合には、一定時間内に受け取った候補クラスタ情報のみを利用するタイムアウト方式なども可能である。特に、自クラスタが候補クラスタでない場合、候補クラスタ情報の送信を省略する方式を採用した場合には、タイムアウト方式が必須となる。

また、一定数の候補クラスタ情報を受け取った時点で待つのを打ち切るという方法を採ることで、全クラスタからの候補クラスタ情報が送られて来るまで待つことや、タイムアウトが生じるまで待つことを止め、高速化を図ることもできる。

なお、グリッドマネージャ５０ａが個別に候補クラスタ情報を送らず、候補クラスタ情報が揃ってから一括してクラスタ探索要求を発行したクラスタマネージャ１ａに送るという方式も可能である。

以上の候補クラスタ探索ステップＳ２０で候補クラスタ情報を受け取ったクラスタマネージャ１ａは、該当リソース探索ステップＳ３０に入る。

この該当リソース探索ステップＳ３０の最初にクラスタマネージャ１ａは、候補クラスタの全部または一部に対して、リソース探索要求を送信する。図４では、二つのクラスタ２、３が候補クラスタとなっているため、どちらのクラスタへもリソース探索要求が送信されているが、一般には候補クラスタとなっている一部のクラスタのみへリソース探索が送信される。

より多くの候補クラスタに対してリソース探索要求を送信することで、連続的な条件をより満たすリソースを見つけたい場合は、全部または多数の候補クラスタにリソース探索を送信すればよい。しかしながら、リソース探索の送信および処理のコストを重視する場合は、少数の候補クラスタにリソース探索要求を送信すればよい。

このリソース探索要求には、静的リソース情報に加えて、動的リソース情報が含まれる。リソース探索要求を受け取ったクラスタマネージャ２ａ、３ａは、まずリソース探索要求の静的リソース情報を読み出して、クラスタ探索時と同様の方法で静的リソース情報格納手段２ｂ、３ｂから自クラスタ内の該当するリソースを検索する。更に、クラスタマネージャ２ａ、３ａは該当するリソースについて、自クラスタ内の動的リソース情報測定手段２ｃ、３ｃによってリソース探索要求の動的リソース情報に記述された条件を満たすかどうかを判定する。

図３の動的条件のうち、ＣＰＵの負荷は時間経過によって変化する動的リソース情報である。これは、例えば動的リソース情報測定手段２ｃがＯＳに対してシステムコールを発行し、スケジューラ内の現在実行可能なプロセスまたはスレッドの個数、あるいはその一定時間範囲の平均値などを読み出すことによって測定できる。

図３のもう1つの動的条件である自クラスタへのホップ数(経路上のルータの個数)は、どのクラスタへの融通を行なうかによって変化する動的リソース情報である。ホップ数は、リソース探索要求を送信したクラスタマネージャ１ａに対して自クラスタマネージャからＩＣＭＰ ＥＣＨＯパケットを送るといった、既存のネットワーク測定方法を動的リソ
ース情報測定手段１ｃ、２ｃ、…、ｎｃで実現することによって測定することができる。

自クラスタへのホップ数は、ネットワーク的距離を測定するために指定する動的リソース情報であるが、ネットワーク的距離の測定方法としてはこの他に、現在の空き帯域幅、応答時間(round trip time)などもあり、これらを動的リソース情報測定手段１ｃ、２ｃ、…、ｎｃで測定して動的リソース情報として扱うこともできる。

リソース探索要求を受信したクラスタマネージャ２ａ、３ａは、上記の方法で条件を満たすリソースの自クラスタ内での探索を行ない、該当するリソースの静的および動的リソース情報を該当リソース情報としてリソース探索要求を送信したクラスタマネージャ１ａに送信する。

該当リソース情報を受け取ったクラスタマネージャ１ａでは、該当するリソースのうち一つを選択する。連続的なリソース情報が条件に含まれている場合には、もっとも優れた該当リソース情報のリソースを選択する方法が一般的であるが、早く受け取った該当リソース情報のリソースを選択することや、任意のリソースを不作為に選択することもできる。

したがって、この本実施形態によれば、クラスタ探索によって絞り込んだクラスタを対象にリソース探索を行うため、クラスタ間リソース融通のためのリソース探索にかかる通信量と処理量を低減することができる。

次に、リソース探索方法の変形例について説明する。

図５は、第２のリソース探索方法の動作を示すフローチャートである。図５において、候補クラスタ探索ステップＳ２０は図４の候補クラスタ探索ステップＳ２０と同じであるので、その説明は省略する。

この第２のリソース探索では、該当リソース探索ステップＳ４０が図４の該当リソース探索ステップＳ３０と相違する。具体的には、該当リソース探索ステップＳ４０は、クラスタマネージャ１ａからの該当リソース探索要求をグリッドマネージャ５０ａが受信して、候補クラスタであるクラスタマネージャ２ａ、３ａに配信する。そして、各クラスタマネージャ２ａ、３ａによって探索された該当リソース情報をグリッドマネージャ５０ａを介してクラスタマネージャ１ａに送信する。

図６は、第３のリソース探索方法の動作を示すフローチャートである。この第３のリソース探索方法では、図５の第２のリソース探索方法と同様に該当リソース探索ステップＳ５０にもグリッドマネージャ５０ａが仲介を行っているが、どのクラスタから融通を行うかの決定にグリッドマネージャ５０ａが関与することが相違する。即ち、グリッドマネージャ５０ａがクラスタマネージャ２ａ、３ａからの該当リソース情報を受信すると、その1つを選択してクラスタマネージャ１ａに送信する。

上記した第２及び第３のリソース探索方法であっても、図４の第１のリソース探索方法と同様な効果を奏することができる。
（第２の実施形態）
図７は、第２の実施形態に係るクラスタシステムのグリッド２００を示す。図７の全体構成は、グリッドマネージャが存在しない点以外、図１と同様である。多数のクラスタからなるグリッドの場合、第１の実施形態のようにリソース探索をグリッドマネージャ５０ａを経由して行なうと、グリッドマネージャ５０ａに負荷が集中して処理性能が低下してしまう場合がある。第２の実施形態では、このボトルネックを解消するため、グリッド２
００内にグリッドマネージャを設けず、クラスタマネージャ間の接続によるｐｅｅｒ−ｔｏ−ｐｅｅｒ型のリソース探索を行なう。

以下に、第２の実施形態によるリソースの探索方法を、図８を参照して説明する。図８は、本実施形態におけるリソース探索動作を示すフローチャートである。図７と図８において、図１と同じ構成要素には同じ図面符号が付いている。

図８の候補クラスタ探索ステップＳ６０において、リソースを借りる側（即ち、リソースを探索を行う側）のクラスタマネージャ１ａは、他のクラスタマネージャ（ここでは、クラスタマネージャ２ａとする。）に対して、図２と同様な静的リソース情報を付加してクラスタ探索要求を発行する。クラスタ探索要求を受け取ったクラスタマネージャ２ａは、そのクラスタ探索要求を他のいくつかのクラスタマネージャ３ａに、更にクラスタマネージャ３ａはそのクラスタ探索要求を他のいくつかのクラスタマネージャｎａに転送する。各クラスタマネージャ２ａ、３ａ、…、ｎａは、静的リソース情報格納手段２ｂ、３ｂ、…、ｎｂを検索して貸し出し可能なリソースがある場合、リソースありの候補クラスタをクラスタマネージャ１ａに送信する。これ以後の処理は図４の該当リソース検索ステップＳ３０と同様なステップが実行され、リソース情報の１つが選択される。

クラスタマネージャ１ａ、２ａ、…、ｎａ間をどのように接続してクラスタ探索要求の発行や転送を行なうかについては、既存のｐｅｅｒ−ｔｏ−ｐｅｅｒシステムの技術が利用できる。例えば、クラスタマネージャ１ａが一定数の他のクラスタマネージャ２ａ、３ａ、…、ｎａのポインタを保持しておけば、それらのクラスタマネージャ３ａ、…、ｎａへクラスタ探索要求を発行または転送することができる。無限にクラスタ探索要求が転送されつづける問題を防ぐには、同じクラスタ探索要求を再び受け取った場合にそれを無視する方式や、クラスタ探索要求に生存期間(time to live)を付与しておき、クラスタ探索要求の転送回数に上限を設ける方式が利用できる。

本実施形態についても第１の実施形態と同様、自クラスタが候補クラスタでない場合には候補クラスタ情報の送信を省略し、自クラスタが候補クラスタである場合のみ候補クラスタ情報を送信するようにして、候補クラスタ情報による通信量および処理量を削減してもよい。

以上に説明した第２の実施形態によれば、第１の実施形態と同様な効果を奏する他、グリッドマネージャを設けることなくリソース探索を行なうことができる。このため、多数のクラスタからなるグリッドの場合、グリッドマネージャのボトルネックによる処理性能の低下を低減することができる。
（第３の実施形態）
図９は、第３の実施形態に係るクラスタシステムのグリッド３００を示す。

この第３の実施形態では、クラスタ２，３、…、ｎの静的リソース情報を一括管理し、リソース探索を高速化する。

静的リソース情報は、ハードウェアの増設やＯＳの入れ替えなどのリソースへの大幅な改変が行なわれた場合にのみ変更される。このため、その変更頻度は低く、何日・何年も変更されないことも多い。そのため、複数のクラスタの静的リソース情報を一括管理することで、個々のクラスタマネージャへの問い合わせを省略して探索を高速化することが可能である。

本実施形態では、複数クラスタ静的リソース情報格納手段５０ｂをグリッドマネージャ５０ａに配置し、クラスタ１、２、…、ｎの静的リソース情報格納手段１ｂ、２ｂ、…、
ｎｂと併用する構成としている。

以下に、本実施形態によるリソース探索方法を、図１０を参照して説明する。図１０は、本実施形態におけるリソース探索方法を示すフローチャートである。図９と図１０において、図１と同じ構成要素には同じ図面符号が付いている。

本実施形態では同じ静的リソース情報がクラスタ１、２、…、ｎの静的リソース情報格納手段１ｂ、２ｂ、…、ｎｂとグリッドマネージャ５０ａの複数クラスタ静的リソース情報格納手段５０ｂとに重複して格納される。このため、格納手段間で同じ情報の一貫性を確保するために、静的リソース情報の転送が必要になる。静的リソース情報は例えば一定時間ごとにクラスタ１、２、…、ｎの静的リソース情報格納手段１ｂ、２ｂ、…、ｎｂからグリッドマネージャ５０ａの複数静的リソース情報格納手段５０ｂに転送される。なお、リソース情報に更新日時を付与しておけば、前回の転送時から更新された情報のみを転送して、更新されていないリソースの転送を省略して転送量や処理量を減らすこともできる。

さらに、複数クラスタ静的リソース情報格納手段５０ｂと静的リソース情報格納手段１ｂ、２ｂ、…、ｎｂとで、単純に情報を重複させるのではなく、詳細なリソース静的リソース情報はクラスタ１、２、…、ｎの静的リソース情報格納手段１ｂ、２ｂ、…、３ｂにのみ格納し、複数クラスタ静的リソース情報格納手段５０ｂにはその概要のみを格納する方法もある。

そして、候補クラスタ探索ステップ７０では、クラスタマネージャ１ａからのクラスタ探索要求をグリッドマネージャ５０ａが受信すると、複数クラスタ静的リソース情報格納手段５０ｂを検索して貸し出し可能なリソースを見つけ候補クラスタ情報としてクラスタマネージャ１ａに送信する。この後の該当リソース探索ステップは図４と同じであるので、その説明は省略する。なお、該当リソース探索ステップは図５のステップＳ４０、図６のステップＳ５０を実行してもよい。

以上説明した第３の実施形態によれば、第１の実施形態と同様な効果を奏する他、複数クラスタ静的リソース情報格納手段をグリッドマネージャに設けることにより、各クラスタへの静的リソースの検索を省略することができる。
（第４の実施形態）
図１１は、第４の実施形態に係るクラスタシステムのグリッド４００を示す。

第４の実施形態では、例えばグリッドマネージャ５０ａとクラスタマネージャ１ａ、２ａの中間に上位クラスタマネージャ１０００ａを設け、その上位クラスタマネージャ１０００ａに複数クラスタ静的リソース情報格納手段１０００ｂを配置して構成する。他の上位クラスタマネージャ２０００ａ、…、Ｍ０００ａも同じ構成である。この上位クラスタマネージャ１０００ａ、２０００ａ、…、Ｍ０００ａは計算機１０００、２０００、…、Ｍ０００内に設けられている。

第３の実施形態の場合、クラスタの数が非常に多くなると、全クラスタの静的リソース情報を一つのグリッドマネージャ５０に定期的に転送して一つの複数クラスタ静的リソース情報格納手段５０ｂに格納する処理がボトルネックとなり、処理性能が低下する場合がある。

この問題に対処するため、第４の実施形態ではグリッドとクラスタとの中間に上位クラスタという階層を設け、それぞれ上位クラスタマネージャ１０００ａ、２０００ａ、…、Ｍ０００ａを設置する。図１１において、上位クラスタマネージャ１０００ａ、２０００
ａ、…、Ｍ０００ａには複数クラスタ静的リソース情報格納手段１０００ｂ、２０００ｂ、…、Ｍ０００ｂが設けられ、上位クラスタに属する全クラスタのリソースの静的リソース情報が格納されている。上位クラスタマネージャとクラスタとの関係は、第３の実施形態におけるグリッドマネージャとクラスタとの関係と同様である。

グリッドマネージャ５０ａは、受け取ったクラスタ探索を各上位クラスタマネージャ１０００ａ、２０００ａ、…、Ｍ０００ａに転送する。クラスタ探索を受け取った上位クラスタマネージャ１０００ａ、２０００ａ、…、Ｍ０００ａは、複数クラスタ静的リソース情報格納手段１０００ｂ、２０００ｂ、…、Ｍ０００ｂを用いて自上位クラスタ内の各クラスタに貸し出し可能リソースがあるかどうかを判定し、判定結果を候補クラスタ情報としてクラスタ探索を発行したクラスタマネージャに送る。

この第４の実施形態によれば、第１の実施形態と同様な効果を奏する他、上位クラスタを階層的に設けることにより分散したリソース探索を行なうことができる。

第１の実施形態に係るクラスタシステムの構成を示すブロック図である。 各実施形態に用いられる静的リソース情報の例を示す図である。 各実施形態に用いられる動的リソース情報の例を示す図である。 第１の実施形態に係る第１のリソース探索動作を示すフローチャート。 第１の実施形態の第２のリソース探索動作を示すフローチャート。 第１の実施形態の第３のリソース探索動作を示すフローチャート。 第２の実施形態に係るクラスタシステムの構成を示すブロック図である。 第２の実施形態のリソース探索動作を示すフローチャート。 第３の実施形態に係るクラスタシステムの構成を示すブロック図である。 第３の実施形態のリソース探索の動作を示すフローチャート。 第４の実施形態に係るクラスタシステムの構成を示すブロック図である。

符号の説明

１〜ｎ クラスタ（計算機）
１２、１３、２２、２３、３２、３３、ｎ２、ｎ３ リソース（計算機）
１ａ〜ｎａ クラスタマネージャ
１ｂ〜ｎｂ 静的リソース情報格納手段
１ｃ〜ｎｃ 動的リソース情報測定手段
１１、２１、３１、ｎ１、５０、１０００、２０００、Ｍ０００ 計算機
５０ａ グリッドマネージャ
５０ｂ 複数クラスタ静的リソース情報格納手段
１０００ａ〜Ｍ０００ａ 上位クラスタマネージャ
１０００ｂ〜Ｍ０００ｂ 複数クラスタ静的リソース情報格納手段

Claims (13)

1. 一つ以上のリソースを有するクラスタを複数備えたコンピュータシステムのリソース探索方法であって、
   リソース探索される各クラスタに設けられた自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段を参照し、該リソース探索の要求による静的リソース情報の条件に該当するリソースを持っている一つ以上の候補クラスタを探索する候補クラスタ探索ステップと、
   前記候補クラスタに設けられた自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段によって測定された値を参照し、該リソース探索の要求による動的リソース情報の条件に該当するリソースを探索する該当リソース探索ステップと
   を備えることを特徴とするリソース探索方法。
2. 前記該当リソース探索ステップは、前記動的リソース情報の条件に該当するリソースを探索する前に前記静的リソース情報格納手段を参照し、前記静的リソース情報の条件に該当するリソースを探索することを特徴とする請求項１に記載のリソース探索方法。
3. 前記静的リソース情報はＣＰＵの種類、ＣＰＵのクロック速度、ＯＳの種類及びＲＡＭ容量の少なくとも一つ以上を含み、前記動的リソース情報はＣＰＵ負荷及び又はネットワーク経路のホップ数を含むことを特徴とする請求項１又は請求項２に記載のリソース探索方法。
4. リソース探索するクラスタから前記複数のクラスタを管理するグリッドマネージャを介して前記リソース探索される各クラスタへ前記候補クラスタ探索ステップのクラスタ探索要求が発行されることを特徴とする請求項１又は請求項２に記載のリソース探索方法。
5. リソース探索するクラスタから前記複数のクラスタを管理する上位クラスタマネージャを介して前記リソース探索される各クラスタへ前記候補クラスタ探索ステップのクラスタ探索要求が発行されることを特徴とする請求項１又は請求項２に記載のリソース探索方法。
6. 一つ以上のリソースを有する複数のクラスタと前記複数のクラスタを管理するグリッドマネージャとを有するコンピュータシステムのリソース探索方法であって、
   リソース探索するクラスタから前記グリッドマネージャを介して送信されたクラスタ探索要求に応じて、リソース探索される各クラスタに設けられた自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段を参照し、該リソース探索の要求による静的リソース情報の条件に該当するリソースを持っている一つ以上の候補クラスタを探索する候補クラスタ探索ステップと、
   前記リソース探索するクラスタから直接又は前記グリッドマネージャを介して送信された該当リソース探索要求に応じて、前記候補クラスタの前記静的リソース情報格納手段を参照して前記静的リソース情報の条件に該当するリソースを探索し、そのリソースの中で自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段によって測定された値を参照して、該リソース探索の要求による動的リソース情報の条件に該当するリソースを探索する該当リソース探索ステップと
   を備えることを特徴とするリソース探索方法。
7. 一つ以上のリソースを有する複数のクラスタと前記複数のクラスタを管理するグリッドマネージャとを有するコンピュータシステムのリソース探索方法であって、
   前記グリッドマネージャに設けられた複数クラスタ静的リソース情報格納手段に前記複
   数のクラスタの静的リソース情報を格納するステップと、
   リソース探索するクラスタからのクラスタ探索要求に応じて、前記グリッドマネージャの前記複数クラスタ静的リソース情報格納手段を参照し、該リソース探索の要求による静的リソース情報の条件に該当するリソースを持っている一つ以上の候補クラスタを探索する候補クラスタ探索ステップと、
   前記リソース探索するクラスタからの該当リソース探索要求に応じて、前記候補クラスタに設けられた静的リソース情報格納手段を参照して前記静的リソース情報の条件に該当するリソースを探索し、そのリソースの中で自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段によって測定された値を参照して、該リソース探索の要求による動的リソース情報の条件に該当するリソースを探索する該当リソース探索ステップと
   を備えることを特徴とするリソース探索方法。
8. 前記該当リソース探索ステップで複数のリソースが得られた場合、前記リソース探索するクラスタ又は前記グリッドマネージャが１つのリソースを選択することを特徴とする請求項６又は請求項７のリソース探索方法。
9. 一つ以上のリソースを有するクラスタを複数備えたコンピュータシステムのリソース探索方法であって、
   リソース探索するクラスタからのクラスタ探索要求をリソース探索される各クラスタにシリアルに送信し、前記リソース探索される各クラスタに設けられた自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段を参照し、該クラスタ探索探索要求による静的リソース情報の条件に該当するリソースを持っている一つ以上の候補クラスタを探索する候補クラスタ探索ステップと、
   前記リソース探索するクラスタから送信された該当リソース探索要求に応じて、前記候補クラスタの前記静的リソース情報格納手段を参照して前記静的リソース情報の条件に該当するリソースを探索し、そのリソースの中で自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段によって測定された値を参照して、該リソース探索要求による動的リソース情報の条件に該当するリソースを探索する該当リソース探索ステップと
   を備えることを特徴とするリソース探索方法。
10. 一つ以上のリソースを有するクラスタを複数備えたコンピュータシステムの前記クラスタ間におけるリソース融通を制御するクラスタマネージャ装置であって、
    リソース探索対象の複数のクラスタマネージャ装置に対し静的リソース情報からなるクラスタ探索要求を発行し、前記クラスタ探索要求の条件に該当する一つ以上の候補クラスタ情報を受信する手段と、
    前記候補クラスタの前記クラスタマネージャ装置に対し動的リソース情報を含む該当リソース探索要求を発行し、前記該当リソース探索要求の条件に該当する一つ以上のリソース情報を受信する手段と
    を備えることを特徴とするクラスタマネージャ装置。
11. 一つ以上のリソースを有するクラスタを複数備えたコンピュータシステムのクラスタマネージャ装置であって、
    自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段と、
    自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段と、
    リソース探索するクラスタマネージャ装置から受信したクラスタ探索要求に応答して前記静的リソース情報格納手段を参照して該クラスタ探索要求による静的リソース情報の条
    件に該当するリソースがあるか否かを探索し、該当するリソースがある場合には候補クラスタの情報を前記リソース探索するクラスタマネージャ装置に通知し、前記リソース探索するクラスタマネージャ装置から受信した該当リソース探索要求に応答して前記静的リソース情報格納手段を参照して前記静的リソース情報の条件に該当するリソースを探索し、そのリソースの中で自クラスタ内の前記動的リソース情報測定手段によって測定した値を参照して、該リソース探索要求による動的リソース情報の条件に該当するリソースを探索して前記リソース探索するクラスタマネージャ装置へ送信する処理手段と
    を備えることを特徴とするクラスタマネージャ装置。
12. 一つ以上のリソースを有する複数のクラスタと前記複数のクラスタを管理するグリッドマネージャとを有するコンピュータシステムのクラスタマネージャ装置であって、
    自クラスタ内の前記リソースに関する静的リソース情報を格納する静的リソース情報格納手段と、
    自クラスタ内の前記リソースに関する動的リソース情報を測定する動的リソース情報測定手段と、
    前記静的リソース情報格納手段に格納された静的リソース情報を定期的に前記グリッドマネージャに送信し、リソース探索するクラスタマネージャ装置と前記グリッドマネージャとの交信により候補クラスタとなった場合に、前記リソース探索するクラスタマネージャ装置から受信した該当リソース探索要求に応答して前記静的リソース情報格納手段を参照して、該リソース探索要求による静的リソース情報の条件に該当するリソースを探索し、そのリソースの中で自クラスタ内の前記動的リソース情報測定手段によって測定した値を参照して動的リソース情報の条件に該当するリソースを探索して前記リソース探索する側のクラスタマネージャ装置へ送信する処理手段と
    を備えることを特徴とするクラスタマネージャ装置。
13. 前記静的リソース情報格納手段には、ＣＰＵの種類、ＣＰＵのクロック速度、ＯＳの種類、及びＲＡＭ容量の少なくとも一つ以上を含み、前記動的リソース情報は、ＣＰＵ負荷及び又はネットワーク経路のホップ数を含むことを特徴とする請求項１０乃至請求項１２のいずれか１項に記載のクラスタマネージャ装置。

Images