JPH1166018A

JPH1166018A - 分散資源管理システムおよび分散資源管理方法

Info

Publication number: JPH1166018A
Application number: JP9216113A
Authority: JP
Inventors: Mayumi Tomikawa; 真弓冨川; Takeshi Aoki; 武司青木
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1997-08-11
Filing date: 1997-08-11
Publication date: 1999-03-09

Abstract

(57)【要約】【課題】分散環境下において、個々のユーザの要求を
反映したきめの細かい資源配分制御、分散的かつ分権的
な資源配分制御、さらには資源の輻輳状態に対応した動
的な適応性をもった資源配分制御を実現できるようにす
ることを課題とする。【解決手段】エージェントＡＧにおいて、アプリケー
ションＡＰの実行に必要な資源ＲＳについてユーザが要
求するＱＯＳレベルで需要関数を求め、その需要関数を
資源ＲＳを管理するリソースマネージャＲＭにおいて、
その需要関数に基づいて資源ＲＳの輻輳度を求め、再び
エージェントＡＧにおいて、その輻輳度からつぎの要求
を決定するというサイクルを繰り返し実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、分散資源管理シ
ステムに関し、詳細には、複数のユーザ間で共有される
ネットワークバンド幅，ＣＰＵ，メモリ，ディスクなど
の計算機の資源を配分および管理する分散資源管理シス
テムおよび分散資源管理方法に関する。

【０００２】近年、ネットワーク環境の整備、パーソナ
ルコンピュータの普及などから、インターネットへの接
続が容易になってきた。また、Ｗｅｂページのブラウザ
やホームページ作成ツールの種類も豊富になり、誰でも
簡単にインターネットを利用できるようになったことか
ら、ここ数年、ネットワークの利用が急増している。ま
た、Ｗｅｂによるネットワーク利用の他に、音声やビデ
オなどのリアルタイムなマルチメディア通信を行うアプ
リケーションの利用も盛んになっていきている。

【０００３】しかし、現在のコンピュータシステムおよ
びネットワーク環境では、資源が輻輳した場合に、音声
がとぎれたり、ビデオ画像が乱れるなど、サービス品質
（ＱＯＳ）が保証されていなかった。今後、リアルタイ
ムアプリケーションを本格的に運用していくためには、
資源が輻輳した場合にも、音声のとぎれや画像の乱れの
ない、ユーザに不快感を与えないＱＯＳを保証する必要
がある。

【０００４】

【従来の技術】現在の多くの分散資源管理システムが、
リアルタイムアプリケーションに対して、十分なサービ
ス品質を保証できない。これは、リアルタイムアプリケ
ーション（テレビ中継など）／非リアルタイムアプリケ
ーション（電子メールなど）の区別や各ユーザの要求す
るサービス品質の高低に関わらず、均等に各資源の配分
を行っているからである。

【０００５】しかし、ユーザの要求するＱＯＳは、サー
ビスの内容やユーザの持つ好みの違いなどによって様々
である。また、ユーザがサービスから得る満足感は、配
分された資源の絶対量や、絶対的に高いＱＯＳによって
決まるのではなく、自分が要求した品質に対して、最終
的にどれだけの品質を受け取ることができたかによって
決まる。ゆえに、ユーザの要求を反映した資源配分制御
が必要である。

【０００６】これまでに行われているユーザの要求が関
与する資源配分の方法として、ＨａｌＲ．Ｖａｒｉａｎ
によるインターネットに対する価格付けの研究（１）、
ニュージーランドで実際に行われているインターネット
の課金例（２）、Ｒ．Ｃｏｃｃｈｉらの研究（３）など
がある。

【０００７】上記研究（１）の方法について、Ｖａｒｉ
ａｎは使用量に基づいた価格付けを提唱している。この
方法は、ネットワーク輻輳時に起こるパケット転送遅延
やパケット廃棄などのコストを反映した価格で課金する
ことにより、ネットワーク資源の効率的な配分を行うも
のである。

【０００８】上記課金例（２）の方法について、ニュー
ジーランドのインターネットでも、基本的に使用量に基
づいた課金が行われているが、利用の少ない夜間や、優
先度の低いサービスにはディスカウントが行われる。そ
のディスカウントにより利用の分散が図られている。

【０００９】また、上記研究（３）の方法について、Ｃ
ｏｃｃｈｉらは、遅延とパケットロスに対してＨｉｇ
ｈ，Ｌｏｗの優先度を設定し、優先度ごとに価格付けを
行っている。ユーザが優先度を選択する際に、価格とい
う動機付けがあるため、性能に敏感でないユーザは、低
い優先度を選択し、一方、敏感なユーザは設定された価
格を払ってでも高い優先度を選択する。

【００１０】

【発明が解決しようとする課題】しかしながら、上述し
たニュージーランドのシステム（課金例（２））やＣｏ
ｃｃｈｉらの方法（研究（３））においては、ユーザが
プロバイダやシステムによりあらかじめ設定されたサー
ビスクラスを選ぶという範囲でしか要求を表すことがで
きないという問題があった。

【００１１】また、ユーザの数が増えてシステムの規模
が大きくなると、ユーザの要求に関する情報を集中管理
し、中央集権的に資源配分制御を行うことは、効率が悪
いばかりでなく、実現することが困難である。また、資
源管理の方針は個々の資源や資源を管理する組織によっ
ても異なるので、唯一の方針ですべての資源を集中的に
管理することは適切ではないという問題があった。

【００１２】さらに、ユーザのサービス要求は、時間や
通信相手などによって変化し、資源の輻輳状態も様々な
要因で動的に変動するため、そのサービス要求には静的
な制御方法で対応することができないという問題があっ
た。

【００１３】この発明は、上述した従来例による問題を
解消するため、分散環境下において、個々のユーザの要
求を反映したきめの細かい資源配分制御、分散的かつ分
権的な資源配分制御、さらには資源の輻輳状態に対応し
た動的な適応性をもった資源配分制御を実現することが
可能な分散資源管理システムおよび分散資源管理方法を
提供することを目的とする。

【００１４】なお、近似技術の一例として、特開平５−
２３３５９６号公報がある。特開平５−２３３５９６号
公報には、資源を使用するユーザエージェントから資源
を管理する資源管理エージェントに対して要求値となる
価格を基に資源毎の割り当て要求を行うという技術が開
示されている。

【００１５】

【課題を解決するための手段】上述した課題を解決し、
目的を達成するため、請求項１の発明に係る分散資源管
理システムは、各エージェントにおいて、アプリケーシ
ョンに必要な注目資源の要求度を示す需要関数を作成
し、その作成された需要関数を注目資源を管理するリソ
ースマネージャに発信して、その発信された需要関数と
この需要関数に対応してリソースマネージャから通知さ
れた輻輳度とに基づいて注目資源の要求値を決定し、各
リソースマネージャにおいては、発信されてきたすべて
の需要関数に基づいて輻輳度を算出し、その算出された
輻輳度をすべてのエージェントに通知するようにしたも
のである。

【００１６】この請求項１の発明によれば、アプリケー
ション（エージェント）側でサービスの要求度を資源の
需要関数として表し、その需要関数を直接資源（リソー
スマネージャ）に対して示すことから、個々のアプリケ
ーションの要求を反映したきめの細かい資源配分制御が
可能である。また、個々のアプリケーション（エージェ
ント）が独立に資源（リソースマネージャ）と交渉する
ことから、分散的な制御が可能となり、同時に、アプリ
ケーションや資源のおかれた環境の管理方針に従った分
権的な制御が可能である。

【００１７】また、請求項２の発明に係る分散資源管理
システムは、請求項１の発明において、注目資源に複数
の実行モードが割り当てられていた場合、任意に実行モ
ードを切り替えて需要関数の変更を行うようにしたもの
である。

【００１８】この請求項２の発明によれば、需要関数の
変更によりアプリケーション（エージェント）と資源
（リソースマネージャ）との交渉を繰り返し実行するよ
うにしたので、資源の輻輳状態に対応した動的な適応性
をもった資源配分制御を実現することが可能である。

【００１９】また、請求項３の発明に係る分散資源管理
システムは、請求項２において、実行すべきアプリケー
ションが画像データの伝送であった場合には、ネットワ
ークが輻輳し、ＣＰＵが輻輳していない場合に圧縮あり
のモードを用いてＣＰＵの需要量を増やし、一方、ＣＰ
Ｕが輻輳し、ネットワークが輻輳していない場合に圧縮
なしのモードを用いてネットワークの需要量を増やす需
要関数へ変更するものである。

【００２０】この請求項３の発明によれば、ネットワー
クが輻輳していてもＣＰＵの需要量を増すことで、十分
に画像データを圧縮することができ、一方、ＣＰＵが輻
輳していてもネットワークの需要量を増すことで、圧縮
に必要なＣＰＵの需要量を削減することが可能である。

【００２１】また、請求項４の発明に係る分散資源管理
システムは、請求項１〜３のいずれか一つにおいて、各
リソースマネージャにおいて、各エージェントから発信
されてきた需要関数をエージェント別に管理し、その管
理内容をすでに管理対象となっているエージェントから
発信されてくる需要関数を用いて更新するものである。

【００２２】この請求項４の発明によれば、各リソース
マネージャでは、該当する資源を共有するエージェント
からの最新の需要関数を管理するようにしたので、常に
現時点での輻輳状況を各エージェントに提供することが
可能である。

【００２３】また、請求項５の発明に係る分散資源管理
システムは、請求項１〜４のいずれか一つにおいて、注
目資源に関して任意に指定された実行レベルをこの実行
レベルに対応する需要量に変換するための変換関数を作
成し、その変換関数に従って需要量と輻輳度との関係を
示す需要関数を作成するものである。

【００２４】この請求項５の発明によれば、注目資源の
実行レベルを需要量に変換する変換関数から需要量と輻
輳度との関係を示す需要関数を作成するようにしたの
で、実行レベルを実現するのに必要な需要量を示す需要
関数を得ることが可能である。

【００２５】また、請求項６の発明に係る分散資源管理
システムは、請求項１〜５のいずれか一つにおいて、実
行すべきアプリケーションに複数の資源が必要な場合、
複数の資源をすべて注目資源としてそれぞれに関する需
要関数を作成するものである。

【００２６】この請求項６の発明によれば、実行すべき
アプリケーションに必要な資源をすべて注目資源として
需要関数を作成するようにしたので、一つの注目資源の
輻輳度から得られた要求値だけでなく、全体としてバラ
ンスがよく、適切な要求度でアプリケーションを実行さ
せることが可能である。

【００２７】また、請求項７の発明に係る分散資源管理
システムは、請求項１において、すべての需要関数と注
目資源についてあらかじめ設定された供給可能量とに基
づいて輻輳度を算出するものである。

【００２８】この請求項７の発明によれば、輻輳度の算
出に、需要関数だけでなく、注目資源についてあらかじ
め設定した供給可能量を加味するようにしたので、同じ
注目資源でも与える供給可能量の違いから輻輳の状況を
変動させることが可能である。

【００２９】また、請求項８の発明に係る分散資源管理
システムは、請求項１〜７のいずれか一つにおいて、前
記需要関数は不連続な関数であることを特徴とする。

【００３０】この請求項８の発明によれば、需要関数を
不連続な関数で表したので、輻輳度の増加方向で段階的
に需要量を表現することが可能である。

【００３１】また、請求項９の発明に係る分散資源管理
方法は、各エージェントにより複数のアプリケーション
のうちで実行すべきアプリケーションに必要な注目資源
に関する需要関数を作成し、各エージェントで作成され
た需要関数をこの需要関数に対する注目資源を管理する
リソースマネージャに発信し、各リソースマネージャに
おいて発信されてきたすべての需要関数に基づいて輻輳
度を算出し、各リソースマネージャで算出された輻輳度
を複数のエージェントのうちで発信元であるすべてのエ
ージェントに通知し、各エージェントにおいて発信され
た需要関数とこの需要関数に対応してリソースマネージ
ャから通知された輻輳度とに基づいて需要関数に対する
注目資源の要求値を決定する工程よりなるものである。

【００３２】この請求項９の発明によれば、アプリケー
ション（エージェント）側でサービスの要求度を資源の
需要関数として表し、その需要関数を直接資源（リソー
スマネージャ）に対して示すことから、個々のアプリケ
ーションの要求を反映したきめの細かい資源配分制御が
可能である。また、個々のアプリケーション（エージェ
ント）が独立に資源（リソースマネージャ）と交渉する
ことから、分散的な制御が可能となり、同時に、アプリ
ケーションや資源のおかれた環境の管理方針に従った分
権的な制御が可能である。

【００３３】また、請求項１０の発明に係る分散資源管
理方法は、請求項９において、複数の実行モードのうち
で任意に実行モードを切り替えて需要関数の変更を行う
工程をさらに含んだものである。

【００３４】この請求項１０の発明によれば、需要関数
の変更によりアプリケーション（エージェント）と資源
（リソースマネージャ）との交渉を繰り返し実行するよ
うにしたので、資源の輻輳状態に対応した動的な適応性
をもった資源配分制御を実現することが可能である。

【００３５】

【発明の実施の形態】以下に添付図面を参照して、この
発明に係る分散資源管理システムおよび分散資源管理方
法の好適な実施の形態を詳細に説明する。

【００３６】まず、システム構成について説明する。図
１はこの発明の実施の形態による分散資源管理システム
を示すシステム構成図である。図１に示した分散資源管
理システムは、ネットワークＮＥＴに一例として３台の
ホストコンピュータ１，２，３を接続させた構成であ
る。なお、システムの規模に応じて、１台、２台、もし
くは、４台以上のホストコンピュータを接続してもよ
く、その接続数については設計事項となる。

【００３７】ホストコンピュータ１は、自ホスト内に設
けられた資源すなわち自ＣＰＵのリソースマネージャで
あるＣＰＵマネージャＲＭ１，資源（自ＣＰＵ，ネット
ワーク）を用いて実行するアプリケーションＡＰ１，ア
プリケーションＡＰ１で使用する資源（自ＣＰＵ，ネッ
トワーク）を管理する各リソースマネージャ（ＣＰＵマ
ネージャＲＭ１，ネットワークマネージャＲＭ３）に対
して使用上の交渉を行うエージェントＡＧ１などにより
構成される。

【００３８】ホストコンピュータ２は、自ホスト内に設
けられた資源すなわち自ＣＰＵのリソースマネージャで
あるＣＰＵマネージャＲＭ２，資源（自ＣＰＵ，ネット
ワーク）を用いて実行するアプリケーションＡＰ２，資
源（自ＣＰＵ）を用いて実行するアプリケーションＡＰ
３，アプリケーションＡＰ２で使用する資源（自ＣＰ
Ｕ，ネットワーク）を管理する各リソースマネージャ
（ＣＰＵマネージャＲＭ２，ネットワークマネージャＲ
Ｍ３）に対して使用上の交渉を行うエージェントＡＧ
２，アプリケーションＡＰ３で使用する資源（自ＣＰ
Ｕ）を管理するリソースマネージャ（ＣＰＵマネージャ
ＲＭ２）に対して使用上の交渉を行うエージェントＡＧ
３などにより構成される。

【００３９】ホストコンピュータ３は、自ネットワーク
のリソースマネージャであるネットワークマネージャＲ
Ｍ３などにより構成される。このネットワークマネージ
ャＲＭ３は、ネットワークＮＥＴに関する資源交渉の管
理を行うリソースマネージャである。

【００４０】ここで、上述したＣＰＵマネージャは、Ｃ
ＰＵに関する資源配分交渉を管理するリソースマネージ
ャなので、ホストコンピュータ毎に設置される。なお、
ホストコンピュータ３については、説明上、図示が省略
されている。また、ネットワークマネージャはネットワ
ーク毎に設置されるので、ネットワークＮＥＴにはネッ
トワークマネージャＲＭ３だけが設置される。

【００４１】上述した分散資源管理システムにおいて、
アプリケーションＡＰ１，ＡＰ２，ＡＰ３は、それぞれ
実行する際に、１又は複数の資源を必要とする。図１に
は、資源としてネットワークとＣＰＵとが一例として挙
げられている。アプリケーションＡＰ１およびアプリケ
ーションＡＰ２においては、ネットワークと自ホスト内
のＣＰＵとを資源として確保する必要がある。また、ア
プリケーションＡＰ３においては、自ホスト内のＣＰＵ
のみを資源として確保する必要がある。

【００４２】各アプリケーションＡＰ１，ＡＰ２，ＡＰ
３は、実行の際に単に資源を確保するのではなく、実行
に必要な資源の需要量を確保することになる。すなわ
ち、ネットワークについては、バンド幅がネットワーク
需要量として確保され、ＣＰＵについては、ＣＰＵ使用
率がＣＰＵ需要量として確保される。

【００４３】したがって、エージェントＡＧ１は、自ホ
スト内の伝送路を介してＣＰＵマネージャＲＭ１に対し
てＣＰＵを資源として利用するための要求を行い、ネッ
トワークＮＥＴを介してネットワークマネージャＲＭ３
に対してネットワークを資源として利用するための要求
を行う。エージェントＡＧ２は、自ホスト内の伝送路を
介してＣＰＵマネージャＲＭ２に対してＣＰＵを資源と
して利用するための要求を行い、ネットワークＮＥＴを
介してネットワークマネージャＲＭ３に対してネットワ
ークを資源として利用するための要求を行う。そして、
エージェントＡＧ３は、自ホスト内の伝送路を介してＣ
ＰＵマネージャＲＭ２に対してのみＣＰＵを資源として
利用するための要求を行う。

【００４４】続いて、上述した分散資源管理システムに
おける資源交渉の原理について説明する。図２は資源交
渉モデルを説明する図である。図２において、アプリケ
ーションＡＰ１，ＡＰ２，ＡＰ３をモデル化したものが
アプリケーションＡＰであり、エージェントＡＧ１，Ａ
Ｇ２，ＡＧ３をモデル化したものがエージェントＡＧで
ある。また、ＣＰＵマネージャＲＭ１，ＲＭ２およびネ
ットワークマネージャＲＭ３をモデル化したものがリソ
ースマネージャＲＭであり、そのリソースマネージャＲ
Ｍが管理する対象モデルが資源ＲＳである。

【００４５】図２に示した資源交渉は、アプリケーショ
ンＡＰを実行させるため、資源ＲＳが必要となる例であ
る。このため、エージェントＡＧは、資源ＲＳを管理す
るリソースマネージャＲＭに対してその資源ＲＳの利用
について直接交渉する。その際、エージェントＡＧは、
リソースマネージャＲＭに対して単に資源ＲＳの要求値
を送るのではなく、ユーザが所要の資源に対して要求度
を示す実行レベル（以下にＱＯＳレベルと称する）に基
づいて資源ＲＳの需要量を関数で表現した需要関数を求
め、その需要関数を送る。

【００４６】リソースマネージャＲＭは、エージェント
ＡＧから送られてくる需要関数を受け付けると、その需
要関数から資源ＲＳの輻輳度を求め、その輻輳度をエー
ジェントＡＧに通知する。エージェントＡＧは、リソー
スマネージャＲＭから輻輳度の通知を受け取ると、その
輻輳度からＱＯＳレベルおよび要求値を決定するが、要
求するＱＯＳレベルが得られるように、アプリケーショ
ンの実行モードを換えて交渉を繰り返し実行することも
できる。

【００４７】つぎに、エージェント機能について説明す
る。図３は分散資源管理システムに適用されるエージェ
ントの構成を機能的に示すブロック図である。図３にお
いて、エージェント機能は、需要関数作成部１０１，要
求発信部１０２，通知受付部１０４，要求値決定部１０
３などにより構成される。

【００４８】需要関数作成部１０１は、ユーザインタフ
ェースによるＱＯＳレベルの指定に応じて需要関数を作
成する。要求発信部１０２は、需要関数作成部１０１で
作成した需要関数もしくはアプリケーションの終了要求
を所要のリソースマネージャに発信する。通知受付部１
０４は、所要のリソースマネージャから回答される輻輳
度の通知を受け付ける。要求値決定部１０３は、通知受
付部１０４に受け付けられた輻輳度に従って要求値を決
定する。この要求値決定部１０３は、アプリケーション
の実行モードを変更する必要があれば、需要関数作成部
１０１に実行モードに応じた需要関数の変更を指示し、
アプリケーションの終了の際には、要求発信部１０２に
対して需要関数の発信先であるリソースマネージャへの
終了要求を指示する。

【００４９】つぎに、リソースマネージャ機能について
説明する。図４は分散資源管理システムに適用されるリ
ソースマネージャの構成を機能的に示すブロック図であ
る。図４において、リソースマネージャ機能は、要求受
付部２０１，エージェント要求処理部２０２，輻輳算出
部２０３，通知部２０４などにより構成される。

【００５０】要求受付部２０１は、要求元のエージェン
トから需要関数の新規又は更新要求や交渉の終了要求を
受け付ける。エージェント要求処理部２０２は、新規エ
ージェントからの需要関数の新規受付処理、すでに受付
済みのエージェントからの需要関数の更新受付処理、要
求元のエージェントに関する終了処理などを実行する。
輻輳度算出部２０３は、要求元のすべてのエージェント
の需要関数から輻輳度を算出する。通知部２０４は、輻
輳度算出部２０３で算出された輻輳度を要求元のすべて
のエージェントに通知する。

【００５１】つぎに、ホストコンピュータ１，２，３の
ハードウェア構成について説明する。図５はホストコン
ピュータの代表的なハードウェア構成を示すブロック図
である。図５には、代表例として、ホストコンピュータ
１の内部構成が示されている。ホストコンピュータ１
は、ＣＰＵ１０，メインメモリ１１，ＲＡＭ１２，キー
ボード１３，マウス１４，ディスプレイ１５，通信ユニ
ット１６，各部を接続してアドレス，データ，制御信号
などを伝送するバス１７などにより構成される。

【００５２】ＣＰＵ１０は、メインメモリ１１に格納さ
れた各種プログラムに従って装置全体を制御する。メイ
ンメモリ１１は、ＣＰＵマネージャＲＭ１，エージェン
トＡＧ１，アプリケーションＡＰ１などのプログラムを
格納している。ＲＡＭ１２は、ワークエリアの他に、各
種プログラムを実行する際に記憶すべき変換関数，需要
関数，管理リストをそれぞれ格納するバッファ１２ａ，
１２ｂ，１２ｃなどを設けている。

【００５３】キーボード１３はユーザがＱＯＳレベルを
指定する場合などで操作するキーを備えている。マウス
１４は、ディスプレイ１５上の位置入力を行うポインテ
ィングデバイスである。このマウス１４については、ユ
ーザがＱＯＳレベルを指定する場合にキーボード１３と
合わせて操作する仕様にしてもよい。ディスプレイ１５
は、、ユーザがＱＯＳレベルを指定する場合の操作画面
などを形成する場合などで表示を行う。通信ユニット１
６は、ネットワークＮＥＴを介して他のホストコンピュ
ータ２，３と通信を行うためのユニットである。

【００５４】また、ホストコンピュータ２，３は、上述
したホストコンピュータ１と同様の構成を有しており、
その違いはメインメモリに格納されるプログラムの種類
にある。ホストコンピュータ２では、メインメモリにア
プリケーションＡＰ２，ＡＰ３、エージェントＡＧ２，
ＡＧ３、およびＣＰＵマネージャＲＭ２などのプログラ
ムが格納され、ホストコンピュータ３では、メインメモ
リにネットワークマネージャＲＭ３などのプログラムが
格納される。

【００５５】つぎに、動作について説明する。まず、エ
ージェント側の動作について説明する。図６はエージェ
ントの動作の流れを説明するフローチャート、図７はＱ
ＯＳレベルから需要関数への変換をグラフを用いて説明
する図、そして、図８は需要度と輻輳度との関係をグラ
フ化して示す図である。ここでは、ホストコンピュータ
１の動作を例に挙げる。

【００５６】エージェント側においては、アプリケーシ
ョンを実行するのに必要な資源を確保するため、交渉が
必要な資源数ｎ（ｎは自然数）を“０”に初期化する処
理が実行される（ステップＳ３０１）。そして、例えば
ディスプレイ１５にＱＯＳレベルの設定画面が形成され
ると、ユーザはキーボード１３やマウス１４の操作で任
意にＱＯＳレベルを指定する。このようにしてＱＯＳレ
ベルが指定されると、そのＱＯＳレベルを実現するのに
必要な資源の需要量（ＣＰＵ需要量，ネットワーク需要
量）を関数で表現した変換関数が作成される。このと
き、資源数ｎには、アプリケーションの実行に必要な資
源数Ｎが設定される（ステップＳ３０２）。

【００５７】この変換関数は一つの資源について必ずし
も唯一ではなく、アプリケーションに複数の実行モード
が存在する場合には、複数の変換関数を作成することが
できる。例えば、動画の発信アプリケーションを実行す
る場合には、動画情報を非圧縮状態で発信する場合と圧
縮状態で発信する場合との２つの実行モードが考えられ
る。この場合、変換関数は実行モードに対応して２通り
存在する。これら２つの実行モードは、注目する資源の
輻輳度に応じて使い分けされ、その使い分けに伴って変
換関数も使い分けられる。

【００５８】続いて、アプリケーションの実行に必要な
資源の順番を管理するためのワークカウンタｉが“０”
に初期化される（ステップＳ３０３）。そして、まず、
アプリケーションの実行に必要な一つめの資源の需要関
数が作成される。その際に、ワークカウンタｉは一つイ
ンクリメントされ、ｉ＝１となる（ステップＳ３０
４）。

【００５９】上述した変換関数および需要関数について
一例を挙げる。変換関数は、図７（ａ）に示したよう
に、ユーザが要求するＱＯＳレベル（要求ＱＯＳ）が大
きくなるに従って注目する資源の需要量が大きくなって
いく曲線を持つ関数である。この変換関数のデータはＲ
ＡＭ１２のバッファ１２ａに格納される。

【００６０】ＱＯＳレベルと輻輳度との関係について
は、図７（ｂ）に示したように、注目する資源の輻輳度
が大きくなるに従ってＱＯＳレベルを落としていく曲線
となる。したがって、図７（ｃ）に示した需要量と輻輳
度との関係のように、注目する資源の輻輳度が大きくな
るに従って需要量を落としていく需要関数が作成され
る。この需要関数のデータはＲＡＭ１２のバッファ１２
ｂに格納される。

【００６１】一つめの資源（ｉ＝１）に対する需要関数
が作成されると、ワークカウンタｉがチェックされ、ワ
ークカウンタｉが資源数ｎ（ｎ＝Ｎ）に達していない間
は、処理は再びステップＳ３０４に戻り、同様の需要関
数作成を繰り返し実行する（ステップＳ３０５）。ここ
では、ＣＰＵとネットワークとが資源となることから、
一例としてＮ＝２とする。

【００６２】このステップＳ３０４およびステップＳ３
０５のループでは、アプリケーションの実行に必要なＣ
ＰＵ，ネットワークそれぞれについて需要関数を作成す
る処理が実行される。ステップＳ３０４においては、一
つの資源に複数の変換関数が存在する場合であっても、
ユーザが指定したＱＯＳレベルに対応する需要関数だけ
が作成される。

【００６３】このようにして各資源（ＣＰＵ，ネットワ
ーク）に対応する需要関数が作成されると（ステップＳ
３０５）、ＲＡＭ１２のバッファ１２ｂには、資源の種
類（ＣＰＵ，ネットワーク）に対応させて需要関数が格
納される。

【００６４】続いて、ワークカウンタｉが再び“０”に
初期化され（ステップＳ３０６）、一つめの資源の需要
関数がバッファ１２ｂから読み出され、その資源を管理
するリソースマネージャに対して需要関数が発信され
る。その際に、ワークカウンタｉは一つインクリメント
され、ｉ＝１となる（ステップＳ３０７）。このように
需要関数が発信されると、リソースマネージャには、ま
ず新規エージェントとして要求が受け付けられる。

【００６５】この需要関数の発信も、前述した需要関数
の作成と同様に、一つめの資源（ｉ＝１）に対する需要
関数が発信されると、ワークカウンタｉがチェックさ
れ、ワークカウンタｉが資源数ｎ（ｎ＝Ｎ）に達してい
ない間は、処理は再びステップＳ３０７に戻り、同様の
需要関数作成を繰り返し実行する（ステップＳ３０
８）。すなわち、このステップＳ３０７およびステップ
Ｓ３０８のループでは、アプリケーションの実行に必要
な資源（ＣＰＵ，ネットワーク）のＣＰＵマネージャＲ
Ｍ１，ネットワークマネージャＲＭ３それぞれに対して
需要関数を発信する処理が実行される。

【００６６】このようにして各資源に対して需要関数の
発信が完了すると（ステップＳ３０８）、需要関数を発
信した各リソースマネージャ（ＣＰＵマネージャＲＭ
１，ネットワークマネージャＲＭ３）から輻輳度の通知
が届く状態がチェックされる（ステップＳ３０９）。そ
の間、アプリケーションの実行を中止するなどして資源
の利用が中止される場合には、ステップＳ３１２におい
て処理が終了と判断され、続くステップＳ３１３におい
て各リソースマネージャに終了要求が発信される。一
方、終了しない間は、処理はリソースマネージャからの
通知待ちとなる（ステップＳ３０９，ステップＳ３１
２）。

【００６７】その後、リソースマネージャから輻輳度の
通知が届くと（ステップＳ３０９）、そのリソースマネ
ージャがＣＰＵマネージャＲＭ１であれば、通知された
ＣＰＵ１０の輻輳度とバッファ１２ｂから読み出された
ＣＰＵマネージャＲＭ１が管理するＣＰＵ１０の需要関
数とに基づいてＣＰＵ１０の要求値（需要量）が決定さ
れる（ステップＳ３１０）。ここでは、ＱＯＳレベルも
求められるが、その詳細については後述する。図８に示
した需要関数において、ＣＰＵマネージャＲＭ１から通
知された輻輳度がｃｃであった場合、確保可能な需要量
はｒとなる。この需要量ｒが要求値として決定される。

【００６８】続いて、ＣＰＵ１０の需要関数の変更もな
く（ステップＳ３１１）、処理が続行され（ステップＳ
３１２）、ネットワークマネージャＲＭ３から輻輳度の
通知が届くと（ステップＳ３０９）、通知されたネット
ワークの輻輳度とバッファ１２ｂから読み出されたネッ
トワークマネージャＲＭ３が管理するネットワークの需
要関数とに基づいてネットワークの要求値（需要量）が
決定される（ステップＳ３１０）。

【００６９】このネットワークについても、需要関数に
おいて、通知された輻輳度に対する需要量から要求値が
決定される。なお、このようにして決定された各資源の
要求値は、実行しようとしているアプリケーションとそ
のアプリケーションの実行に必要な各資源に対して通知
される。

【００７０】また、ステップＳ３１１において、ＣＰ
Ｕ，ネットワークのいずれか一方、もしくはその両方の
需要関数を変更する指示がキーボード１３などにより操
作された場合には、処理はステップＳ３０２に戻り、同
一資源について存在する他の実行モードに対応する変換
関数を作成する。

【００７１】ここでは、現時点での輻輳状態から、余裕
があればさらに高い要求度の実行モードに変更すればよ
く、一方、要求ＱＯＳレベルでは資源の利用が不可能で
あればさらに低い要求度の実行レベルに変更すればよ
い。以降、ステップＳ３０３〜ステップＳ３１３におい
て、需要関数の作成，発信，通知された輻輳度に基づく
要求値の決定などが実行される。

【００７２】特に、エージェントが複数の資源を利用す
るために該当する各リソースマネージャに対して交渉を
行う場合には、各資源における確保可能な需要量が求め
られた後に、すべての需要量を基にしてその時点での実
行ＱＯＳレベルが決定される。これは、複数の資源を利
用する際のＱＯＳレベルの基準を統一するためである。
さらに、その統一された実行ＱＯＳレベルに基づいて資
源別に要求値（需要量）が求められ、各要求値（需要
量）が該当するアプリケーションと該当する資源とに通
知される。

【００７３】続いて、リソースマネージャ側の動作につ
いて説明する。図９はリソースマネージャの動作の流れ
を説明するフローチャート、図１０はリソースマネージ
ャの管理リストの内容の一例を示す図、そして、図１１
は輻輳度を求めるための需要量と輻輳度との関係をグラ
フ化して示す図である。ここでは、前述のエージェント
側の説明に合わせてＣＰＵマネージャＲＭ１の動作につ
いて説明する。なお、ネットワークマネージャＲＭ３の
動作も、ＣＰＵマネージャＲＭ１と同様のため、説明を
省略する。

【００７４】ＣＰＵマネージャＲＭ１では、まず準備段
階として、エージェントの要求を管理する管理リストの
バッファ１２ｃが初期化される（ステップＳ９０１）。
この管理リストのバッファ１２ｃとは、資源（この場合
には、ＣＰＵ）を利用するため、資源を共有するエージ
ェント毎の需要関数の新規受付，更新受付および終了受
付を管理するためのリストである。

【００７５】この管理リストのバッファ１２ｃは、図１
０に示したように、エージェントの種類（図中、ＡＧ
１）と需要関数（図中、Ｆ１）とを対応させて管理し、
その管理されるデータは各エージェントからの新規要求
で追加されたり終了要求で削除される。なお、ステップ
Ｓ９０１において管理リスト１２ｃが初期化されると、
そのデータはすべて削除される。

【００７６】続いて、処理はエージェントからの要求待
ちとなる（ステップＳ９０２）。そこで、前述したよう
に、エージェントＡＧ１からＣＰＵ１０を資源として使
用するために需要関数が発信されてくると、その要求内
容が判別される（ステップＳ９０２）。その要求が新規
エージェントからの受付要求であった場合には、処理は
ステップＳ９０３に移行し、その新規エージェントの需
要関数を管理リストのバッファ１２ｃに付加する。これ
により新規登録が完了する。ここでは、説明上、ＣＰＵ
マネージャＲＭ１に要求できるのはエージェントＡＧ１
だけなので、ステップＳ９０３においてエージェントＡ
Ｇ１の需要関数Ｆ１が管理リストのバッファ１２ｃに新
規登録される。

【００７７】また、すでに管理リストのバッファ１２ｃ
に要求元のエージェントの需要関数が登録済みであった
場合には、エージェントからの要求は需要関数の変更要
求として受け付けられる（ステップＳ９０２）。したが
って、管理リストのバッファ１２ｃ内の該当するエージ
ェントの登録内容はすでに登録されている需要関数から
今回送られてきた需要関数に更新される（ステップＳ９
０４）。これは、同一エージェントが実行モードを変え
て再度変更した需要関数を発信してくる場合に行うもの
である。

【００７８】また、要求元のエージェントから終了要求
があった場合には（ステップＳ９０２）、処理はステッ
プＳ９０５に移行し、管理リスト１２ｃから要求元のエ
ージェントに関する需要関数を削除する。以上の各要求
については、エージェント側で需要関数に要求の種別情
報（新規，更新，終了）を付加し、その種別情報をリソ
ースマネージャ側で判別するものとする。

【００７９】このようにしてエージェントの要求に応じ
た処理が終了すると、今度は輻輳度の算出を行うため、
処理はステップＳ９０６に移行する。ステップＳ９０６
では、管理リストのバッファ１２ｃに現在存在する需要
関数がすべて合計される。ホストコンピュータ１では、
ＣＰＵ１０を使用するアプリケーションがＡＰ１だけな
ので、交渉はアプリケーションＡＰ１とＣＰＵ１０との
１対１である。このため、ステップＳ９０６は、新たに
交渉するアプリケーションがホストコンピュータ１に設
けられるまでは不要となる。

【００８０】しかしながら、ホストコンピュータ２で
は、アプリケーションＡＰ２，ＡＰ３の２つが自ホスト
内のＣＰＵに対して交渉できることから、各エージェン
トＡＧ２，ＡＧ３からＣＰＵマネージャＲＭ２に対して
需要関数が発信される。このため、ＣＰＵマネージャＲ
Ｍ２では、ステップＳ９０６において２つの需要関数を
合計することになる。

【００８１】図１１（ａ）において、例えば、エージェ
ントＡＧ２から送られてきた需要関数がｄｆ１で示した
曲線で表され、エージェントＡＧ３から送られてきた需
要関数がｄｆ２で示した曲線で表された場合には、それ
ら２つの需要関数（曲線ｄｆ１，ｄｆ２）を合計した需
要関数はｄｆ３で示した曲線で表される。曲線ｄｆ３で
は、輻輳度が大きくなる方向で、Ｘ地点までは曲線ｄｆ
１とｄｆ２とを合計した曲線形状となるが、曲線ｄｆ２
がＸ地点までのため、そのＸ地点より先は曲線ｄｆ２と
同様の曲線形状となる。

【００８２】同様に、ホストコンピュータ３では、アプ
リケーションＡＰ１，ＡＰ２の２つが自ホストのネット
ワークに対して交渉できることから、各エージェントＡ
Ｇ１，ＡＧ２からネットワークマネージャＲＭ３に対し
て需要関数が発信される。このため、ネットワークマネ
ージャＲＭ３では、ステップＳ９０６において２つの需
要関数を合計することになる。

【００８３】続くステップＳ９０７において、リソース
マネージャすなわちＣＰＵマネージャＲＭ１の管理方針
に従ってＣＰＵ１０の供給可能な需要量（以下に供給可
能量と称する）が設定される。ここで、管理方針とし
て、資源の全量を供給可能量として設定するのか、それ
とも交渉が必要なアプリケーションのクラス（例えばリ
アルタイムクラス）と交渉が不要なアプリケーションの
クラス（例えば非リアルタイムクラス）に対して資源を
分けて管理して、リアルタイムクラスのための資源を供
給可能量とするかをあらかじめ任意に定義しておく。

【００８４】さらに続くステップＳ９０８において、ス
テップＳ９０６およびステップＳ９０７を経て得られた
需要関数と供給可能量とに基づいて資源すなわちＣＰＵ
１０の輻輳度が算出される。一例として、図１１（ａ）
に示した需要関数の曲線ｄｆ３を例に挙げると、需要関
数ｄｆ３において供給可能量がｓであったときの資源の
輻輳度はｃｃとなる。この輻輳度ｃｃは、該当する需要
関数（曲線ｄｆ３）に供給可能量ｓを与えることで求め
られる。

【００８５】そして、ＣＰＵマネージャＲＭ１は、ステ
ップＳ９０８により算出されたＣＰＵ１０の輻輳度を要
求元のすべてのエージェント（この場合には、エージェ
ントＡＧ１だけとなる）に対して通知する（ステップＳ
９０９）。この後、処理はステップＳ９０２に戻り、つ
ぎのエージェントからの要求の着信待ちとして待機す
る。

【００８６】このように、アプリケーション（エージェ
ント側）が資源（リソースマネージャ側）に対して要求
を表した需要関数を提示し、資源がその需要関数と供給
可能量とから、その時点での資源の輻輳度を求め、その
輻輳度をアプリケーションにフィードバックする。アプ
リケーションは、そのフィードバックされた資源の輻輳
度に応じて資源を使用する。

【００８７】つぎに、アプリケーションＡＰ１，ＡＰ
２，ＡＰ３を実行する場合についての具体例を挙げる。
図１に示した分散資源管理システムにおいて、アプリケ
ーションＡＰ１，ＡＰ２を、それぞれ音声，画像のマル
チメディアデータを送受信するリアルタイムアプリケー
ションとし、アプリケーションＡＰ３をその他のアプリ
ケーションとして以下に説明する。

【００８８】まず、アプリケーションＡＰ１，ＡＰ２の
ＱＯＳ要求について説明する。図１２はアプリケーショ
ン別のＱＯＳ要求を説明するグラフを示す図である。同
図（ａ），（ｂ）はそれぞれアプリケーションＡＰ１，
ＡＰ２のＱＯＳレベルと輻輳度との関係を不連続な関数
で示している。図１２（ａ）に示したアプリケーション
ＡＰ１のＱＯＳ要求では、扱うデータがＱＯＳレベルに
敏感であるため、資源が輻輳してきた場合にも高いＱＯ
Ｓレベル（Ｈｉｇｈ）を要求し続け、ある輻輳度に達し
たところで実行を中止する内容が示されている。

【００８９】これに対し、図１２（ｂ）に示したアプリ
ケーションＡＰ２のＱＯＳ要求では、扱うデータがＱＯ
Ｓレベルに寛容であるため、資源が輻輳してきた場合
に、ある輻輳度に達したところでＱＯＳレベルをＨｉｇ
ｈからＬｏｗに下げて実行を続ける内容が示されてい
る。このように、ＱＯＳレベルと輻輳度との関係につい
ては、アプリケーションが扱うデータ（コンテンツ）の
内容とユーザの要求とに応じて任意に設定することがで
きる。

【００９０】つぎに、エージェントＡＧ１，ＡＧ２によ
る需要関数の作成について説明する。これは、前述した
エージェント側のフロー（図６参照）でステップＳ３０
２〜ステップＳ３０５に相当する。図１３はＱＯＳレベ
ルから需要量への変換テーブルの一例を示す図、図１４
はネットワーク，ＣＰＵ別の需要関数を説明するグラフ
を示す図、図１５はＱＯＳレベルから需要量への変換テ
ーブルの他の例を示す図、図１６はネットワーク，ＣＰ
Ｕ別で圧縮なしの場合の需要関数を説明するグラフを示
す図そして、図１７はネットワーク，ＣＰＵ別で圧縮あ
りの場合の需要関数を説明するグラフを示す図である。

【００９１】アプリケーションＡＰ１，ＡＰ２をそれぞ
れ管理するエージェントＡＧ１，１Ｇ２は、資源の輻輳
に対して要求するＱＯＳレベルを、そのＱＯＳレベルを
実現するのに必要な資源量すなわち需要量に変換し、各
資源毎に需要関数を作成する。

【００９２】アプリケーションＡＰ１のエージェントＡ
Ｇ１は、図１３に示したような変換テーブルを作成し、
この変換テーブルに従って図１４（ａ），（ｂ）にそれ
ぞれ示したネットワーク，ＣＰＵの不連続な需要関数を
作成する。図１３に示した変換テーブルは、エージェン
ト側のフロー（図６参照）のステップＳ３０２で作成し
た変換関数をテーブル化したものである。この変換テー
ブルでは、ＱＯＳレベルがＨｉｇｈのとき、ネットワー
ク需要量はａとなり、ＣＰＵ需要量はｏとなる。また、
ＱＯＳレベルがＬｏｗのとき、ネットワーク需要量はｂ
となり、ＣＰＵ需要量はｐとなる。

【００９３】したがって、ネットワーク，ＣＰＵそれぞ
れの需要関数は、図１４（ａ），（ｂ）に示したグラフ
となる。すなわち、ネットワークについては（図１４
（ａ）参照）、需要量“ａ”のＱＯＳレベルがある輻輳
度に達するまでＨｉｇｈの状態で要求され、ある輻輳度
に達したところで需要量はゼロとなる。同様に、ＣＰＵ
については（図１４（ｂ）参照）、需要量“ｏ”のＱＯ
Ｓレベルがある輻輳度に達するまでＨｉｇｈの状態で要
求され、ある輻輳度に達したところで需要量はゼロとな
る。アプリケーションＡＰ１では、ＱＯＳレベル“Ｈｉ
ｇｈ”だけの要求となる。

【００９４】また、アプリケーションＡＰ２は、実行モ
ードとして圧縮モードを有している。この圧縮モードに
は、圧縮ありのモードと圧縮なしのモードとの２種類が
存在する。アプリケーションＡＰ２のエージェントＡＧ
２は、図１５に示したような変換テーブルを作成し、こ
の変換テーブルに従って図１６（ａ），（ｂ）にそれぞ
れ示したネットワーク，ＣＰＵの需要関数（圧縮モード
なし）、もしくは図１７（ａ），（ｂ）にそれぞれ示し
たネットワーク，ＣＰＵの需要関数（圧縮モードあり）
を作成する。

【００９５】図１５に示した変換テーブルでは、ＱＯＳ
レベルのＨｉｇｈ，Ｌｏｗがそれぞれさらに圧縮モード
なしと圧縮モードありとに細分化される。まず、圧縮モ
ードなしでは、ＱＯＳレベルがＨｉｇｈのとき、ネット
ワーク需要量はｃとなり、ＣＰＵ需要量はｑとなる。ま
た、ＱＯＳレベルがＬｏｗのとき、ネットワーク需要量
はｄとなり、ＣＰＵ需要量はｒとなる。

【００９６】一方、圧縮モードありでは、ＱＯＳレベル
がＨｉｇｈのとき、ネットワーク需要量はｄとなり、Ｃ
ＰＵ需要量はｓとなる。また、ＱＯＳレベルがＬｏｗの
とき、ネットワーク需要量はｅとなり、ＣＰＵ需要量は
ｑとなる。ここで、需要量の大小関係について言及する
と、ネットワーク側ではｃ＞ｄ＞ｅとなり、ＣＰＵ側で
はｓ＞ｑ＞ｒとなる。

【００９７】したがって、圧縮モードなしの場合には、
ネットワーク，ＣＰＵそれぞれの不連続な需要関数は、
図１６（ａ），（ｂ）に示したグラフとなる。すなわ
ち、ネットワークについては（図１６（ａ）参照）、需
要量ｃのＱＯＳレベルがある輻輳度に達するまでＨｉｇ
ｈの状態で要求され、ある輻輳度に達したところで需要
量はｄに下げられる。同様に、ＣＰＵについては（図１
６（ｂ）参照）、需要量ｑのＱＯＳレベルがある輻輳度
に達するまでＨｉｇｈの状態で要求され、ある輻輳度に
達したところで需要量はｒに下げられる。この圧縮モー
ドなしの場合には、ＱＯＳレベルを輻輳度に応じて段階
的に設定しているので、ＱＯＳレベルはＨｉｇｈ，Ｌｏ
ｗの２段階となる。

【００９８】一方、圧縮モードありの場合には、ネット
ワーク，ＣＰＵそれぞれの不連続な需要関数は、図１７
（ａ），（ｂ）に示したグラフとなる。すなわち、ネッ
トワークについては（図１７（ａ）参照）、需要量ｃの
ＱＯＳレベルがある輻輳度に達するまでＨｉｇｈの状態
で要求され、ある輻輳度に達したところで需要量はｄに
下げられ、さらに他のある輻輳度に達したところで需要
量はｅに下げられる。すなわち、ネットワークについて
は、ＱＯＳレベルがＬｏｗに移行すると、その段階でさ
らに１段レベルを下げる制御が行われる。

【００９９】同様に、ＣＰＵについては（図１７（ｂ）
参照）、まず、ＱＯＳレベルがＨｉｇｈの段階で、需要
量ｓのＱＯＳレベルがある輻輳度に達したことろで需要
量がｑに下げられ、さらに他のある輻輳度に達したとこ
ろでＱＯＳレベルがＬｏｗに移行することから、そこで
需要量はｒに下げられる。この圧縮モードありの場合に
は、ＱＯＳレベルを輻輳度に応じてＨｉｇｈ，Ｌｏｗの
段階でもさらに細分化して段階を設定しているので、Ｑ
ＯＳレベルを送受信するデータの種別に応じて細かく設
定することができる。

【０１００】特に、画像データの送受信では、ネットワ
ークのトラヒックが高くても、ＣＰＵが空いていれば画
像データを圧縮して伝送効率を優先することができる。
そのために、圧縮モードありの場合には、ネットワー
ク，ＣＰＵのいずれについても、一つのＱＯＳレベルを
長く要求する必要はなく、ネットワーク需要量について
は、低いＱＯＳレベルも許容できるようにし、一方、Ｃ
ＰＵ需要量については、さらに高めのＱＯＳレベルを設
定すればよい。

【０１０１】つぎに、アプリケーションＡＰ１，ＡＰ
２，ＡＰ３が順に動作を開始した場合の各資源交渉につ
いて説明する。この動作は、エージェント側のフロー
（図６参照）需要関数の発信，要求値の決定および需要
関数の変更と、リソースマネージャ側のフロー（図９参
照）エージェントの要求処理，輻輳度の算出および輻輳
度の通知とに相当する。

【０１０２】まず、アプリケーションＡＰ１が動作を開
始した場合について説明する。図１８はネットワーク，
ＣＰＵ別でアプリケーションＡＰ１が動作を開始したと
きの輻輳度を説明するグラフを示す図である。同図
（ａ）はネットワークについての需要量と輻輳度との関
係を示し、同図（ｂ）はＣＰＵについての需要量と輻輳
度との関係を示している。

【０１０３】アプリケーションＡＰ１のエージェントＡ
Ｇ１は図１４（ａ），（ｂ）に示した需要関数をそれぞ
れネットワークマネージャＲＭ３、自ホスト内のＣＰＵ
マネージャＲＭ１に発信する。ネットワークについて
は、エージェントＡＧ１からネットワークマネージャＲ
Ｍ３に発信された需要関数から、需要量ａが供給可能量
以下となる（図１８（ａ）参照）。また、ＣＰＵについ
ては、エージェントＡＧ１からＣＰＵマネージャＲＭ１
に発信された需要関数から、需要量ｏが供給可能量以下
となる（図１８（ｂ）参照）。

【０１０４】このように、ネットワーク，ＣＰＵのどち
らの需要量も供給可能量以下となることから、アプリケ
ーションＡＰ１の要求は通る。このため、ネットワーク
需要量ａとＣＰＵ需要量ｏとが得られ、アプリケーショ
ンＡＰ１はＱＯＳレベル“Ｈｉｇｈ”の状態で実行を開
始する。

【０１０５】つぎに、アプリケーションＡＰ２が動作を
開始した場合について説明する。図１９はネットワー
ク，ＣＰＵ別で第２アプリケーションが動作を開始した
ときの輻輳度を説明するグラフを示す図である。同図
（ａ）はネットワークについての需要量と輻輳度との関
係を示し、同図（ｂ）はＣＰＵについての需要量と輻輳
度との関係を示している。

【０１０６】アプリケーションＡＰ２のエージェントＡ
Ｇ２は、まず圧縮モードなしで実行を開始するため、図
１６（ａ），（ｂ）に示した需要関数をそれぞれネット
ワークマネージャＲＭ３、自ホスト内のＣＰＵマネージ
ャＲＭ２に発信する。ネットワークについては、エージ
ェントＡＧ１，ＡＧ２からそれぞれネットワークマネー
ジャＲＭ３に発信された需要関数が合計され、図１９
（ａ）に示したごとくグラフが得られる。このグラフに
対して供給可能量が設定された後、輻輳度が算出され
る。図１９（ａ）に示したように、輻輳度ｃｃが算出さ
れると、その輻輳度ｃｃはエージェントＡＧ１，ＡＧ２
に通知される。

【０１０７】一方、ＣＰＵについては、図１９（ｂ）に
示したように、需要量が供給可能量以下なので、輻輳度
は０となる。そして、各ＣＰＵマネージャＲＭ１，ＲＭ
２は、それぞれ該当するエージェントＡＰ１，ＡＰ２に
輻輳度を通知する。

【０１０８】続いて、各アプリケーションＡＰ１，ＡＰ
２の要求値について説明する。図２０はネットワーク，
ＣＰＵ別でアプリケーションＡＰ１の要求値を説明する
グラフを示す図、図２１はネットワーク，ＣＰＵ別でア
プリケーションＡＰ２の要求値を説明するグラフを示す
図、図２２はネットワーク，ＣＰＵ別で需要関数変更要
求を受けた際の輻輳度を説明するグラフを示す図、図２
３はネットワーク，ＣＰＵ別で輻輳度通知を受けた際の
アプリケーションＡＰ１の要求値を説明するグラフを示
す図、そして、図２４はネットワーク，ＣＰＵ別で輻輳
度通知を受けた際のアプリケーションＡＰ２の要求値を
説明するグラフを示す図である。

【０１０９】エージェントＡＧ１は、各資源に関する輻
輳度の通知を受けると、各資源の需要関数と通知された
輻輳度とから要求値を決定する。このとき、ネットワー
クの輻輳度はｃｃなので、確保できるネットワーク需要
量はａになり（図２０（ａ）参照）、ＣＰＵの輻輳度は
０（ゼロ）なので、確保できるＣＰＵ需要量はｏになる
（図２０（ｂ）参照）。したがって、ネットワークの混
雑がなく、ＣＰＵが空いていることから、アプリケーシ
ョンＡＰ１の実行可能なＱＯＳレベルはＨｉｇｈとな
る。

【０１１０】また、エージェントＡＧ２は、各資源に関
する輻輳度の通知を受けると、各資源の需要関数と通知
された輻輳度とから要求値を決定する。このとき、ネッ
トワークの輻輳度はｃｃなので、確保できるネットワー
ク需要量はｄになり（図２１（ａ）参照）、ＣＰＵの輻
輳度は０（ゼロ）なので、確保できるＣＰＵ需要量はｑ
になる（図２１（ｂ）参照）。したがって、ＣＰＵは空
いているが、ネットワークが混雑していることから、ア
プリケーションＡＰ２の実行可能なＱＯＳレベルはＬｏ
ｗとなる。

【０１１１】アプリケーションＡＰ２については、送受
信に関して圧縮モードなしから圧縮モードありへの切り
替えが可能である。そこで、エージェントＡＧ２は、輻
輳度“０”（空き）のＣＰＵを有効に利用して、ＱＯＳ
レベル“Ｈｉｇｈ”での実行を続けるため、圧縮モード
への切り替えを行う。この状態は、ネットワークが混雑
しているにも拘わらず、ＣＰＵが空き状態のときを想定
できる。この場合には、図１７（ａ），（ｂ）の需要関
数をそれぞれネットワークマネージャＲＭ３、ＣＰＵマ
ネージャＲＭ２に発信する。

【０１１２】これにより、ネットワークマネージャＲＭ
３，ＣＰＵマネージャＲＭ２は、それぞれエージェント
ＡＧ２からの需要関数の変更要求を受け付けて、同時に
送られてきた需要関数に基づいて輻輳度の再計算を行
う。このようにして得られた輻輳度は、該当する各エー
ジェントに対して通知される。ネットワークマネージャ
ＲＭ３では、エージェントＡＧ１，ＡＧ２から送られた
需要関数の合計と供給可能量とから、図２２（ａ）に示
したように、輻輳度ｃｄが算出される。また、図２２
（ｂ）において、ＣＰＵ需要量は供給可能量以下なの
で、輻輳度は０（ゼロ）になる。

【０１１３】ネットワークマネージャＲＭ３は各エージ
ェントＡＧ１，ＡＧ２に対して算出された輻輳度ｃｄを
通知し、ＣＰＵマネージャＲＭ２はエージェントＡＧ２
に対して輻輳度“０”（ゼロ）を通知する。

【０１１４】エージェントＡＧ１は、ネットワークマネ
ージャＲＭ３，ＣＰＵマネージャＲＭ１からそれぞれ輻
輳度の通知を受けると、各輻輳度と需要関数とから要求
値を決定する。エージェントＡＧ１に通知された輻輳度
はｃｄなので、確保できるネットワーク需要量すなわち
要求値はａになり（図２３（ａ）参照）、ＣＰＵの輻輳
度は０なので、ＣＰＵ需要量すなわち要求値はｏになる
（同図（ｂ））。したがって、アプリケーションＡＰ１
の実行可能なＱＯＳレベルはＨｉｇｈとなる。

【０１１５】エージェントＡＧ２は、ネットワークマネ
ージャＲＭ３，ＣＰＵマネージャＲＭ２からそれぞれ輻
輳度の通知を受けると、各輻輳度と需要関数とから要求
値を決定する。エージェントＡＧ２に通知された輻輳度
はｃｄなので、確保できるネットワーク需要量すなわち
要求値はｄになり（図２４（ａ）参照）、ＣＰＵの輻輳
度は０（ゼロ）なので、ＣＰＵ需要量すなわち要求値は
ｓになる（同図（ｂ）参照）。したがって、アプリケー
ションＡＰ２の実行可能なＱＯＳレベルは圧縮モードあ
りでＨｉｇｈとなる。

【０１１６】つぎに、アプリケーションＡＰ３が動作を
開始した場合について説明する。図２５はネットワー
ク，ＣＰＵ別でアプリケーションＡＰ３が動作を開始し
たときの需要関数を説明するグラフを示す図、図２６は
ＣＰＵの輻輳度を説明するグラフを示す図、図２７はＣ
ＰＵで輻輳度の通知を受けた際のアプリケーションＡＰ
２の要求値を説明するグラフを示す図、そして、図２８
はＣＰＵで輻輳度の通知を受けた際のアプリケーション
ＡＰ３の要求値を説明するグラフを示す図である。

【０１１７】アプリケーションＡＰ３は、図２５に示し
たように、ある輻輳度まで需要量ｔでＱＯＳレベルを要
求し続ける需要関数を有している。この需要関数は、ア
プリケーションＡＰ３の実行開始時にホストコンピュー
タ２のＣＰＵマネージャＲＭ２に発信される。

【０１１８】ＣＰＵマネージャＲＭ２は、エージェント
ＡＧ２およびＡＧ３から送られてきた需要関数を合計し
て、図２６に示したような不連続な需要関数を得ると、
その需要関数に対して供給可能量を設定する。そして、
その合計された需要関数と供給可能量とから、輻輳度ｃ
ｅが算出される。この輻輳度ｃｅは、エージェントＡＧ
２，ＡＧ３に通知される。

【０１１９】まず、エージェントＡＧ２は、ＣＰＵマネ
ージャＲＭ２から輻輳度の通知を受けると、その輻輳度
と需要関数とから要求値を決定する。エージェントＡＧ
２に通知されたＣＰＵの輻輳度はｃｅなので、確保でき
るＣＰＵ需要量すなわち要求値はｐになる（図２７参
照）。

【０１２０】したがって、ＣＰＵにおいては、圧縮モー
ドありでもＱＯＳレベルでの実行は不可能となる。この
場合には、圧縮モードありのままＱＯＳレベル“Ｌｏ
ｗ”で実行を行うか、それとも、圧縮モードありでのＱ
ＯＳレベル“Ｌｏｗ”で実行を行うために、需要関数を
変更して再度交渉を行うか、ユーザによって任意に選択
される。

【０１２１】また、エージェントＡＧ３は、ＣＰＵマネ
ージャＲＭ２から輻輳度の通知を受けると、その輻輳度
と需要関数とから要求値を決定する。エージェントＡＧ
２に通知されたＣＰＵの輻輳度はｃｅなので、確保でき
るＣＰＵ需要量すなわち要求値はｔになる（図２８参
照）。したがって、アプリケーションＡＰ３の実行可能
なＱＯＳレベルはＨｉｇｈとなる。

【０１２２】以上説明したように、実施の形態によれ
ば、アプリケーションＡＰ１，ＡＰ２，ＡＰ３（エージ
ェントＡＧ１，ＡＧ２，ＡＧ３）側でサービスの要求度
をＣＰＵ，ネットワークの需要関数として表し、その需
要関数を直接ＣＰＵ，ネットワーク（ＣＰＵマネージャ
ＲＭ１，ＲＭ２およびネットワークマネージャＲＭ３）
に対して示すことから、個々のアプリケーションＡＰ
１，ＡＰ２，ＡＰ３の要求を反映したきめの細かい資源
配分制御が可能である。

【０１２３】また、個々のアプリケーションＡＰ１，Ａ
Ｐ２，ＡＰ３（エージェントＡＧ１，ＡＧ２，ＡＧ３）
が独立にＣＰＵ，ネットワーク（ＣＰＵマネージャＲＭ
１，ＲＭ２およびネットワークマネージャＲＭ３）と交
渉することから、分散的な制御が可能となり、同時に、
アプリケーションや資源（ＣＰＵ，ネットワーク）のお
かれた環境の管理方針に従った分権的な制御が可能であ
る。

【０１２４】また、需要関数の変更によりアプリケーシ
ョン（エージェント）とＣＰＵ，ネットワーク（リソー
スマネージャ）との交渉を繰り返し実行するようにした
ので、資源（ＣＰＵ，ネットワーク）の輻輳状態に対応
した動的な適応性をもった資源配分制御を実現すること
が可能である。

【０１２５】また、図１のシステムにおいて、マルチメ
ディアデータ（動画像データ、音声データの両方を含ん
でいる）画像データを伝送する場合、ネットワークＮＥ
Ｔが輻輳していてもホストコンピュータ１やホストコン
ピュータ２のＣＰＵの需要量を増すことで、十分にデー
タを圧縮することができ、一方、ＣＰＵが輻輳していて
もネットワークＮＥＴの需要量を増すことで、圧縮に必
要なＣＰＵの需要量を削減することが可能である。

【０１２６】また、ＣＰＵマネージャＲＭ１，ＲＭ２や
ネットワークＲＭ３では、該当する資源を共有するエー
ジェントからの最新の需要関数を管理するようにしたの
で、常に現時点での輻輳状況を資源を共有する各エージ
ェントに提供することが可能である。

【０１２７】また、注目資源の実行レベルを需要量に変
換する変換テーブルから需要量と輻輳度との関係を示す
需要関数を作成するようにしたので、実行レベルを実現
するのに必要な需要量を示す需要関数を得ることが可能
である。

【０１２８】また、各エージェントにおいて、実行すべ
きアプリケーションに必要な資源をすべて注目資源とし
て需要関数を作成するようにしたので、一つの注目資源
の輻輳度から得られた要求値だけでなく、全体としてバ
ランスがよく、適切なＱＯＳレベルでアプリケーション
を実行させることが可能である。

【０１２９】また、各リソースマネージャにおいて、輻
輳度の算出に、需要関数だけでなく、注目資源について
あらかじめ設定した供給可能量を加味するようにしたの
で、同じ注目資源でも与える供給可能量の違いから輻輳
の状況を変動させることが可能である。

【０１３０】また、需要関数を不連続な関数で表したの
で、輻輳度の増加方向で段階的に需要量を表現すること
が可能である。

【０１３１】

【発明の効果】以上説明したように、請求項１の発明に
係る分散資源管理システムによれば、アプリケーション
（エージェント）側でサービスの要求度を資源の需要関
数として表し、その需要関数を直接資源（リソースマネ
ージャ）に対して示すことから、個々のアプリケーショ
ンの要求を反映したきめの細かい資源配分制御が可能で
ある。また、個々のアプリケーション（エージェント）
が独立に資源（リソースマネージャ）と交渉することか
ら、分散的な制御が可能となり、同時に、アプリケーシ
ョンや資源のおかれた環境の管理方針に従った分権的な
制御が可能である。

【０１３２】また、請求項２の発明によれば、請求項１
の発明において、需要関数の変更によりアプリケーショ
ン（エージェント）と資源（リソースマネージャ）との
交渉を繰り返し実行するようにしたので、資源の輻輳状
態に対応した動的な適応性をもった資源配分制御を実現
することが可能である。

【０１３３】また、請求項３の発明によれば、請求項２
において、ネットワークが輻輳していてもＣＰＵの需要
量を増すことで、十分にデータを圧縮することができ、
一方、ＣＰＵが輻輳していてもネットワークの需要量を
増すことで、圧縮に必要なＣＰＵの需要量を削減するこ
とが可能である。

【０１３４】また、請求項４の発明によれば、請求項１
〜３のいずれか一つにおいて、各リソースマネージャで
は、該当する資源を共有するエージェントからの最新の
需要関数を管理するようにしたので、常に現時点での輻
輳状況を各エージェントに提供することが可能である。

【０１３５】また、請求項５の発明によれば、請求項１
〜４のいずれか一つにおいて、注目資源の実行レベルを
需要量に変換する変換関数から需要量と輻輳度との関係
を示す需要関数を作成するようにしたので、実行レベル
を実現するのに必要な需要量を示す需要関数を得ること
が可能である。

【０１３６】また、請求項６の発明によれば、請求項１
〜５のいずれか一つにおいて、実行すべきアプリケーシ
ョンに必要な資源をすべて注目資源として需要関数を作
成するようにしたので、一つの注目資源の輻輳度から得
られた要求値だけでなく、全体としてバランスがよく、
適切な要求度でアプリケーションを実行させることが可
能である。

【０１３７】また、請求項７の発明によれば、請求項１
において、輻輳度の算出に、需要関数だけでなく、注目
資源についてあらかじめ設定した供給可能量を加味する
ようにしたので、同じ注目資源でも与える供給可能量の
違いから輻輳の状況を変動させることが可能である。

【０１３８】また、請求項８の発明によれば、請求項１
〜７のいずれか一つにおいて、需要関数を不連続な関数
で表したので、輻輳度の増加方向で段階的に需要量を表
現することが可能である。

【０１３９】また、請求項９の発明に係る分散資源管理
方法によれば、アプリケーション（エージェント）側で
サービスの要求度を資源の需要関数として表し、その需
要関数を直接資源（リソースマネージャ）に対して示す
ことから、個々のアプリケーションの要求を反映したき
めの細かい資源配分制御が可能である。また、個々のア
プリケーション（エージェント）が独立に資源（リソー
スマネージャ）と交渉することから、分散的な制御が可
能となり、同時に、アプリケーションや資源のおかれた
環境の管理方針に従った分権的な制御が可能である。

【０１４０】また、請求項１０の発明によれば、請求項
９記載の発明において、需要関数の変更によりアプリケ
ーション（エージェント）と資源（リソースマネージ
ャ）との交渉を繰り返し実行するようにしたので、資源
の輻輳状態に対応した動的な適応性をもった資源配分制
御を実現することが可能である。

【図面の簡単な説明】

【図１】この発明の実施の形態による分散資源管理シス
テムを示すシステム構成図である。

【図２】資源交渉モデルを説明する図である。

【図３】分散資源管理システムに適用されるエージェン
トの構成を機能的に示すブロック図である。

【図４】分散資源管理システムに適用されるリソースマ
ネージャの構成を機能的に示すブロック図である。

【図５】ホストコンピュータの代表的なハードウェア構
成例を示すブロック図である。

【図６】エージェントの動作の流れを説明するフローチ
ャートである。

【図７】エージェント側においてＱＯＳレベルから需要
関数への変換をグラフを用いて説明する図である。

【図８】エージェント側において需要度と輻輳度との関
係をグラフ化して示す図である。

【図９】リソースマネージャの動作の流れを説明するフ
ローチャートである。

【図１０】管理リストの内容の一例を示す図である。

【図１１】リソースマネージャ側において輻輳度を求め
るための需要量と輻輳度との関係をグラフ化して示す図
である。

【図１２】アプリケーション別のＱＯＳ要求を説明する
グラフを示す図である。

【図１３】ＱＯＳレベルから需要量への変換テーブルの
一例を示す図である。

【図１４】ネットワーク，ＣＰＵ別の需要関数を説明す
るグラフを示す図である。

【図１５】ＱＯＳレベルから需要量への変換テーブルの
他の例を示す図である。

【図１６】ネットワーク，ＣＰＵ別で圧縮なしの場合の
需要関数を説明するグラフを示す図である。

【図１７】ネットワーク，ＣＰＵ別で圧縮ありの場合の
需要関数を説明するグラフを示す図である。

【図１８】ネットワーク，ＣＰＵ別で第１アプリケーシ
ョンが動作を開始したときの輻輳度を説明するグラフを
示す図である。

【図１９】ネットワーク，ＣＰＵ別で第２アプリケーシ
ョンが動作を開始したときの輻輳度を説明するグラフを
示す図である。

【図２０】ネットワーク，ＣＰＵ別で第１アプリケーシ
ョンの要求値を説明するグラフを示す図である。

【図２１】ネットワーク，ＣＰＵ別で第２アプリケーシ
ョンの要求値を説明するグラフを示す図である。

【図２２】ネットワーク，ＣＰＵ別で需要関数変更要求
を受けた際の輻輳度を説明するグラフを示す図である。

【図２３】ネットワーク，ＣＰＵ別で輻輳度の通知を受
けた際のアプリケーションの要求値を説明するグラフを
示す図である。

【図２４】ネットワーク，ＣＰＵ別で輻輳度の通知を受
けた際のアプリケーションの要求値を説明するグラフを
示す図である。

【図２５】ネットワーク，ＣＰＵ別で第３アプリケーシ
ョンが動作を開始したときの需要関数を説明するグラフ
を示す図である。

【図２６】ＣＰＵの輻輳度を説明するグラフを示す図で
ある。

【図２７】ＣＰＵで輻輳度通知を受けた際の第２アプリ
ケーションの要求値を説明するグラフを示す図である。

【図２８】ＣＰＵで輻輳度通知を受けた際の第３アプリ
ケーションの要求値を説明するグラフを示す図である。

【符号の説明】

１，２，３ホストコンピュータ１０ＣＰＵ１１メインメモリ１２ＲＡＭ１３キーボード１４マウス１５ディスプレイ１６通信ユニット１７バス１０１需要関数作成部１０２要求発信部１０３通知受付部１０４要求値決定部２０１要求受付部２０２エージェント要求処理部２０３輻輳度算出部２０４通知部ＡＧ，ＡＧ１，ＡＧ２，ＡＧ３エージェントＡＰ，ＡＰ１，ＡＰ２，ＡＰ３アプリケーションＮＥＴネットワークＲＭリソースマネージャＲＭ１，ＲＭ２ＣＰＵマネージャＲＭ３ネットワークマネージャＲＳ資源

Claims

【特許請求の範囲】

【請求項１】各種の資源を管理する複数のリソースマ
ネージャと前記各リソースマネージャとの交渉を通じて
実行すべきアプリケーションへの資源配分を制御する複
数のエージェントとをネットワークに接続させ、複数の
アプリケーション間で共有される前記各種の資源の配分
および管理を行う分散資源管理システムにおいて、前記各エージェントは、前記複数のアプリケーションのうちで実行すべきアプリ
ケーションに必要な注目資源の要求度を示す需要関数を
作成する需要関数作成手段と、前記需要関数作成手段により作成された需要関数を当該
需要関数に対する前記注目資源を管理するリソースマネ
ージャに発信する発信手段と、前記発信手段により発信された需要関数と当該需要関数
に対応して前記リソースマネージャから通知された輻輳
度とに基づいて前記需要関数に対する前記注目資源の要
求値を決定する要求値決定手段と、を有し、前記各リソースマネージャは、前記発信手段により発信されてきたすべての需要関数に
基づいて輻輳度を算出する輻輳度算出手段と、前記輻輳度算出手段により算出された輻輳度を前記複数
のエージェントのうちで前記発信手段の発信元であるす
べてのエージェントに通知する輻輳度通知手段と、を有することを特徴とする分散資源管理システム。
【請求項２】前記各エージェントは、前記注目資源に
複数の実行モードが割り当てられていた場合、前記複数
の実行モードのうちで任意に実行モードを切り替えて需
要関数の変更を行う変更手段を、さらに有することを特
徴とする請求項１に記載の分散資源管理システム。
【請求項３】前記注目資源が少なくとも一つのＣＰＵ
と１システム当たり一つ用意されるネットワークとの２
種類存在していた際に、前記変更手段は、前記ネットワ
ークが輻輳し、前記ＣＰＵが輻輳していない場合に圧縮
ありのモードを用いて前記ＣＰＵの需要量を増やし、一
方、前記ＣＰＵが輻輳し、前記ネットワークが輻輳して
いない場合に圧縮なしのモードを用いて前記ネットワー
クの需要量を増やす需要関数へ変更することを特徴とす
る請求項２に記載の分散資源管理システム。
【請求項４】前記各リソースマネージャは、前記各エ
ージェントから前記発信手段により発信されてきた需要
関数をエージェント別に管理する管理手段と、前記管理
手段の管理内容をすでに管理対象となっているエージェ
ントから発信されてくる需要関数を用いて更新する更新
手段とを、さらに有することを特徴とする請求項１〜３
のいずれか一つに記載の分散資源管理システム。
【請求項５】前記需要関数作成手段は、前記注目資源
に関して任意に指定された実行レベルを当該実行レベル
に対応する需要量に変換するための変換関数を作成し、
前記変換関数に従って需要量と輻輳度との関係を示す前
記需要関数を作成することを特徴とする請求項１〜４の
いずれか一つに記載の分散資源管理システム。
【請求項６】前記需要関数作成手段は、前記実行すべ
きアプリケーションに複数の資源が必要な場合、前記複
数の資源をすべて注目資源としてそれぞれに関する需要
関数を作成することを特徴とする請求項１〜５のいずれ
か一つに記載の分散資源管理システム。
【請求項７】前記輻輳度算出手段は、前記すべての需
要関数と前記注目資源についてあらかじめ設定された供
給可能量とに基づいて輻輳度を算出することを特徴とす
る請求項１に記載の分散資源管理システム。
【請求項８】前記需要関数は不連続な関数であること
を特徴とする請求項１〜７のいずれか一つに記載の分散
資源管理システム。
【請求項９】各種の資源を管理する複数のリソースマ
ネージャと前記各リソースマネージャとの交渉を通じて
実行すべきアプリケーションへの資源配分を制御する複
数のエージェントとをネットワークに接続させ、複数の
アプリケーション間で共有される前記各種の資源の配分
および管理を行う分散資源管理システムに適用される分
散資源管理方法において、前記各エージェントにより前記複数のアプリケーション
のうちで実行すべきアプリケーションに必要な注目資源
に関する需要関数を作成する第１工程と、前記各エージェントの前記第１工程により作成された需
要関数を当該需要関数に対する前記注目資源を管理する
リソースマネージャに発信する第２工程と、前記各リソースマネージャにおいて前記第２工程により
発信されてきたすべての需要関数に基づいて輻輳度を算
出する第３工程と、前記各リソースマネージャの前記第３工程により算出さ
れた輻輳度を前記複数のエージェントのうちで前記発信
手段の発信元であるすべてのエージェントに通知する第
４工程と、前記各エージェントにおいて前記第２工程により発信さ
れた需要関数と当該需要関数に対応して前記リソースマ
ネージャから通知された輻輳度とに基づいて前記需要関
数に対する前記注目資源の要求値を決定する第５工程
と、を含むことを特徴とする分散資源管理方法。
【請求項１０】前記各エージェントは、前記注目資源
に複数の実行モードが割り当てられていた場合、前記複
数の実行モードのうちで任意に実行モードを切り替えて
需要関数の変更を行う第６工程を、さらに含むことを特
徴とする請求項９に記載の分散資源管理方法。