JPH07295843A - 負荷分散化プラットフォーム及びその負荷分散処理方法 - Google Patents
負荷分散化プラットフォーム及びその負荷分散処理方法Info
- Publication number
- JPH07295843A JPH07295843A JP8316094A JP8316094A JPH07295843A JP H07295843 A JPH07295843 A JP H07295843A JP 8316094 A JP8316094 A JP 8316094A JP 8316094 A JP8316094 A JP 8316094A JP H07295843 A JPH07295843 A JP H07295843A
- Authority
- JP
- Japan
- Prior art keywords
- unit
- platform
- load
- processing
- application program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Multi Processors (AREA)
Abstract
(57)【要約】
【目的】 分散化されたユニットプラットフォームが協
調して負荷の分散を図ることでシステムの高性能化、即
ちタスクの待ち時間の短縮を目指した、負荷分散化プラ
ットフォーム及びその負荷分散処理方法を提供する。 【構成】 ＤＢインタフェーサ１８、Ｍインタフェーサ
１７、及びＡＰインタフェーサ１３により、データベー
スＤＢ１、タスクモジュールＭ、アプリケーションプロ
グラムＡＰとユニットＰＦ１とを接続し、アクセッサ１
６によりアプリケーションプログラムからのアクセス要
求を管理し、データコレクタ１４により自分の負荷状態
を認識すると共に、ネゴシエータ１５により各ユニット
ＰＦ同士が負荷状態を通知し合って、ユニットＰＦ間の
負荷状態を平準化するように制御する。さらに、各デー
タベース、各タスクモジュール、各アプリケーションプ
ログラムは、全ての或いは複数のユニットプラットフォ
ームに接続される。
調して負荷の分散を図ることでシステムの高性能化、即
ちタスクの待ち時間の短縮を目指した、負荷分散化プラ
ットフォーム及びその負荷分散処理方法を提供する。 【構成】 ＤＢインタフェーサ１８、Ｍインタフェーサ
１７、及びＡＰインタフェーサ１３により、データベー
スＤＢ１、タスクモジュールＭ、アプリケーションプロ
グラムＡＰとユニットＰＦ１とを接続し、アクセッサ１
６によりアプリケーションプログラムからのアクセス要
求を管理し、データコレクタ１４により自分の負荷状態
を認識すると共に、ネゴシエータ１５により各ユニット
ＰＦ同士が負荷状態を通知し合って、ユニットＰＦ間の
負荷状態を平準化するように制御する。さらに、各デー
タベース、各タスクモジュール、各アプリケーションプ
ログラムは、全ての或いは複数のユニットプラットフォ
ームに接続される。
Description
【０００１】
【産業上の利用分野】本発明は、通信分野、事務分野等
において使用されるネットワークの管理、運用等におい
て、データベースとアプリケーションプログラムの結合
や、各種複数のシステム間結合に使用するための負荷分
散化プラットフォーム及びその負荷分散処理方法に関す
るものである。
において使用されるネットワークの管理、運用等におい
て、データベースとアプリケーションプログラムの結合
や、各種複数のシステム間結合に使用するための負荷分
散化プラットフォーム及びその負荷分散処理方法に関す
るものである。
【０００２】
【従来の技術】従来、図２に示すようにデータベースを
用いて一連の仕事を行なうアプリケーションプログラム
（以下、ＡＰと称する）とデータベース（以下、ＤＢと
称する）は直結されていたため、ＤＢのデータベースの
流通が困難であったり、ＤＢを変更するとＡＰも変更す
る必要が有った。即ち、ＡＰ（１）で、データ群１とデ
ータ群２を使用して、一連の仕事を行なうことが出来
ず、新規にＡＰまたは、システムを作成し直す必要があ
った。
用いて一連の仕事を行なうアプリケーションプログラム
（以下、ＡＰと称する）とデータベース（以下、ＤＢと
称する）は直結されていたため、ＤＢのデータベースの
流通が困難であったり、ＤＢを変更するとＡＰも変更す
る必要が有った。即ち、ＡＰ（１）で、データ群１とデ
ータ群２を使用して、一連の仕事を行なうことが出来
ず、新規にＡＰまたは、システムを作成し直す必要があ
った。
【０００３】また、図３のように特定の仕事を行なうタ
スクモジュールにおいても、ＡＰとタスクモジュールは
直結していた。このため、タスクモジュールを変更する
とＡＰも変更する必要が有った。さらに、複数のタスク
モジュールと複数のＤＢを使用するＡＰの場合の変更は
非常に複雑であった。
スクモジュールにおいても、ＡＰとタスクモジュールは
直結していた。このため、タスクモジュールを変更する
とＡＰも変更する必要が有った。さらに、複数のタスク
モジュールと複数のＤＢを使用するＡＰの場合の変更は
非常に複雑であった。
【０００４】これを解消する手段として、図４に示す様
に、ＡＰとＤＢ、ＡＰとタスクモジュールを直結しない
で分離し、それらの結合部であるプラットフォーム（以
下、ＰＦと略す）を介在させて構成する事で、データの
流通を図ると共に、ＤＢやタスクモジュールの変更がＡ
Ｐへ及ぼす影響を軽減する事が可能である。ここで、プ
ラットフォームは複数のＤＢやタスクモジュールとＡＰ
を接続するためのソフトウェアであり、例えば、電子情
報通信学会VOL.E76-B,No.4,April 1993,pp.391-401のN.
Kashima et al. "Optical cable network operation in
subscriber loops"で議論されている。各ＡＰ、ＤＢ、
タスクモジュールは、プラットフォームと接続されてい
る。
に、ＡＰとＤＢ、ＡＰとタスクモジュールを直結しない
で分離し、それらの結合部であるプラットフォーム（以
下、ＰＦと略す）を介在させて構成する事で、データの
流通を図ると共に、ＤＢやタスクモジュールの変更がＡ
Ｐへ及ぼす影響を軽減する事が可能である。ここで、プ
ラットフォームは複数のＤＢやタスクモジュールとＡＰ
を接続するためのソフトウェアであり、例えば、電子情
報通信学会VOL.E76-B,No.4,April 1993,pp.391-401のN.
Kashima et al. "Optical cable network operation in
subscriber loops"で議論されている。各ＡＰ、ＤＢ、
タスクモジュールは、プラットフォームと接続されてい
る。
【０００５】
【発明が解決しようとする課題】しかし、図４に示すよ
うに多数のＤＢ、タスクモジュール、ＡＰが１か所のプ
ラットフォームを介して結合する集中的な状況から、分
散化して処理する必要の生じることがある。例えば、装
置の処理能力の関係や、設置場所の関係、信頼性の確保
などから分散化の必要が生じる。図５〜図７に図４の基
本構成を分散化した例を示す。ここでユニットＰＦは、
図４のプラットフォーム（ＰＦ）の機能全部をユニット
プラットフォーム（ユニットＰＦ）として分散化したも
のである。
うに多数のＤＢ、タスクモジュール、ＡＰが１か所のプ
ラットフォームを介して結合する集中的な状況から、分
散化して処理する必要の生じることがある。例えば、装
置の処理能力の関係や、設置場所の関係、信頼性の確保
などから分散化の必要が生じる。図５〜図７に図４の基
本構成を分散化した例を示す。ここでユニットＰＦは、
図４のプラットフォーム（ＰＦ）の機能全部をユニット
プラットフォーム（ユニットＰＦ）として分散化したも
のである。
【０００６】このように分散化されたＰＦでも、システ
ム全体として出来るだけ良好な特性を発揮させる必要が
ある。例えば、何も制御しないと１つのユニットＰＦに
のみ負荷が集中し、そのユニットＰＦに接続されている
ＡＰが非常に長い間待ち状態になる時、他のユニットＰ
Ｆは軽負荷で動作する状況が生じてしまう。
ム全体として出来るだけ良好な特性を発揮させる必要が
ある。例えば、何も制御しないと１つのユニットＰＦに
のみ負荷が集中し、そのユニットＰＦに接続されている
ＡＰが非常に長い間待ち状態になる時、他のユニットＰ
Ｆは軽負荷で動作する状況が生じてしまう。
【０００７】一方、分散化されたシステムに対して、高
性能化を行なうための手段として、分散協調の考え方が
提案されている。例えば、１９８４年のR.E.Filman and
D.P.Friedman のCoordinated Computing （協調型計算
システム）の著書や、１９９２年日経インテリジェント
システムの”自律動作が可能な「エージェント指向」が
浮上”の記事で開示されている。即ち、自律的に動作す
る実行単位であるエージェントが互いに協調しつつ処理
を進めるという考え方である。
性能化を行なうための手段として、分散協調の考え方が
提案されている。例えば、１９８４年のR.E.Filman and
D.P.Friedman のCoordinated Computing （協調型計算
システム）の著書や、１９９２年日経インテリジェント
システムの”自律動作が可能な「エージェント指向」が
浮上”の記事で開示されている。即ち、自律的に動作す
る実行単位であるエージェントが互いに協調しつつ処理
を進めるという考え方である。
【０００８】本発明の目的は上記の問題点に鑑み、分散
化されたユニットプラットフォームが協調して負荷の分
散を図ることでシステムの高性能化、即ちタスクの待ち
時間の短縮を目指した、負荷分散化プラットフォーム及
びその負荷分散処理方法を提供することにある。
化されたユニットプラットフォームが協調して負荷の分
散を図ることでシステムの高性能化、即ちタスクの待ち
時間の短縮を目指した、負荷分散化プラットフォーム及
びその負荷分散処理方法を提供することにある。
【０００９】
【課題を解決するための手段】本発明は上記の目的を達
成するために請求項１では、データベース群と、タスク
モジュール群と、前記２群を用いて所定のタスクを実行
するアプリケーションプログラム群と、前記３群間相互
の結合部であるユニットプラットフォーム群とで構成さ
れた分散型処理システムにおいて、各ユニットプラット
フォームは、データベースとタスクモジュールとアプリ
ケーションプログラムとに対してインタフェースをとる
インタフェース手段と、アプリケーションプログラムか
らのアクセス要求を管理するアクセス管理手段と、各ユ
ニットプラットフォームが、自分の負荷状態を認識する
処理状況収集手段と、各ユニットプラットフォーム同士
が、上記負荷状態を通知し合って、ユニットプラットフ
ォーム間の負荷状態を平準化するように制御する分散協
調処理手段とから構成され、各データベース、各タスク
モジュール、各アプリケーションプログラムが複数のユ
ニットプラットフォームに接続されてなる負荷分散化プ
ラットフォームを提案する。
成するために請求項１では、データベース群と、タスク
モジュール群と、前記２群を用いて所定のタスクを実行
するアプリケーションプログラム群と、前記３群間相互
の結合部であるユニットプラットフォーム群とで構成さ
れた分散型処理システムにおいて、各ユニットプラット
フォームは、データベースとタスクモジュールとアプリ
ケーションプログラムとに対してインタフェースをとる
インタフェース手段と、アプリケーションプログラムか
らのアクセス要求を管理するアクセス管理手段と、各ユ
ニットプラットフォームが、自分の負荷状態を認識する
処理状況収集手段と、各ユニットプラットフォーム同士
が、上記負荷状態を通知し合って、ユニットプラットフ
ォーム間の負荷状態を平準化するように制御する分散協
調処理手段とから構成され、各データベース、各タスク
モジュール、各アプリケーションプログラムが複数のユ
ニットプラットフォームに接続されてなる負荷分散化プ
ラットフォームを提案する。
【００１０】また、請求項２では、データベース群と、
タスクモジュール群と、前記２群を用いて所定のタスク
を実行するアプリケーションプログラム群と、前記３群
間相互の結合部であるユニットプラットフォーム群とで
構成された分散型処理システムにおけるプラットフォー
ムの負荷分散処理方法であって、各ユニットプラットフ
ォームが、ユニットプラットフォーム間に共通した、テ
ストタスクモジュールにアクセスするテストアプリケー
ションプログラムを定期的に起動実行し、その処理時間
Ｔ1 を求めて、自分の処理状況を認識する第１過程と、
上記処理時間Ｔ1 が設定時間Ｔ0 を越えたユニットプラ
ットフォーム＃１が、自分に接続されている他のユニッ
トプラットフォームに該処理時間Ｔ1 を通知する第２過
程と、前記ユニットプラットフォーム＃１以外の各ユニ
ットプラットフォームが、自分のテストアプリケーショ
ンプログラムの処理時間Ｔ2 と前記処理時間Ｔ1 との大
小関係を比較して、Ｔ2 ＜Ｔ1 の場合に限り、前記ユニ
ットプラットフォーム＃１に返答する第３過程と、前記
ユニットプラットフォーム＃１が、自分に接続されてい
る一部のアプリケーションプログラムを、他のユニット
プラットフォームから受け取った処理時間のうち最小値
を返答してきたユニットプラットフォームに接続切替え
して、自分の負荷の一部を分散し協調処理させる第４過
程とによって、各ユニットプラットフォームの負荷状態
を定期的に見直して、ユニットプラットフォーム全体に
ついて負荷状態を平準化するプラットフォームの負荷分
散処理方法を提案する。
タスクモジュール群と、前記２群を用いて所定のタスク
を実行するアプリケーションプログラム群と、前記３群
間相互の結合部であるユニットプラットフォーム群とで
構成された分散型処理システムにおけるプラットフォー
ムの負荷分散処理方法であって、各ユニットプラットフ
ォームが、ユニットプラットフォーム間に共通した、テ
ストタスクモジュールにアクセスするテストアプリケー
ションプログラムを定期的に起動実行し、その処理時間
Ｔ1 を求めて、自分の処理状況を認識する第１過程と、
上記処理時間Ｔ1 が設定時間Ｔ0 を越えたユニットプラ
ットフォーム＃１が、自分に接続されている他のユニッ
トプラットフォームに該処理時間Ｔ1 を通知する第２過
程と、前記ユニットプラットフォーム＃１以外の各ユニ
ットプラットフォームが、自分のテストアプリケーショ
ンプログラムの処理時間Ｔ2 と前記処理時間Ｔ1 との大
小関係を比較して、Ｔ2 ＜Ｔ1 の場合に限り、前記ユニ
ットプラットフォーム＃１に返答する第３過程と、前記
ユニットプラットフォーム＃１が、自分に接続されてい
る一部のアプリケーションプログラムを、他のユニット
プラットフォームから受け取った処理時間のうち最小値
を返答してきたユニットプラットフォームに接続切替え
して、自分の負荷の一部を分散し協調処理させる第４過
程とによって、各ユニットプラットフォームの負荷状態
を定期的に見直して、ユニットプラットフォーム全体に
ついて負荷状態を平準化するプラットフォームの負荷分
散処理方法を提案する。
【００１１】
【作用】本発明の請求項１によれば、各ユニットプラッ
トフォームにおいて、インタフェース手段により、デー
タベースとタスクモジュールとアプリケーションプログ
ラムとに対してユニットプラットフォームとの間のイン
タフェースがとられ、これらとの間が接続される。ま
た、アクセス管理手段によりアプリケーションプログラ
ムからのアクセス要求が管理され、処理状況収集手段に
より自分の負荷状態が認識されると共に、分散協調処理
手段により各ユニットプラットフォーム同士が、上記負
荷状態を通知し合って、ユニットプラットフォーム間の
負荷状態を平準化するように制御される。さらに、各デ
ータベース、各タスクモジュール、各アプリケーション
プログラムが複数のユニットプラットフォームに接続さ
れる。これにより、図８及び図９に示すように、各ユニ
ットプラットフォームの処理状況収集手段が該ユニット
プラットフォームの負荷状況の認識を行い、各ユニット
プラットフォームの分散協調処理手段により他のユニッ
トプラットフォームに対して負荷分散のための要求、返
答の処理、負荷分散のための処理依頼が行われ、各ユニ
ットプラットフォームは、過負荷になった場合に他のユ
ニットプラットフォームに負荷の分散のための要求を出
し、他の全てのユニットプラットフォームはこの要求を
受け取り、必要に応じて返答を返し、最終的にどのユニ
ットプラットフォームに過負荷の分担を依頼するかが決
定される。従って、過負荷状態のユニットプラットフォ
ームが、他の最小負荷状態のユニットプラットフォーム
に負荷の一部を依頼することが可能となる。
トフォームにおいて、インタフェース手段により、デー
タベースとタスクモジュールとアプリケーションプログ
ラムとに対してユニットプラットフォームとの間のイン
タフェースがとられ、これらとの間が接続される。ま
た、アクセス管理手段によりアプリケーションプログラ
ムからのアクセス要求が管理され、処理状況収集手段に
より自分の負荷状態が認識されると共に、分散協調処理
手段により各ユニットプラットフォーム同士が、上記負
荷状態を通知し合って、ユニットプラットフォーム間の
負荷状態を平準化するように制御される。さらに、各デ
ータベース、各タスクモジュール、各アプリケーション
プログラムが複数のユニットプラットフォームに接続さ
れる。これにより、図８及び図９に示すように、各ユニ
ットプラットフォームの処理状況収集手段が該ユニット
プラットフォームの負荷状況の認識を行い、各ユニット
プラットフォームの分散協調処理手段により他のユニッ
トプラットフォームに対して負荷分散のための要求、返
答の処理、負荷分散のための処理依頼が行われ、各ユニ
ットプラットフォームは、過負荷になった場合に他のユ
ニットプラットフォームに負荷の分散のための要求を出
し、他の全てのユニットプラットフォームはこの要求を
受け取り、必要に応じて返答を返し、最終的にどのユニ
ットプラットフォームに過負荷の分担を依頼するかが決
定される。従って、過負荷状態のユニットプラットフォ
ームが、他の最小負荷状態のユニットプラットフォーム
に負荷の一部を依頼することが可能となる。
【００１２】また、請求項２によれば、各ユニットプラ
ットフォームにより、ユニットプラットフォーム間に共
通した、テストタスクモジュールにアクセスするテスト
アプリケーションプログラムが定期的に起動実行され、
その処理時間Ｔ1 が求められて、各ユニットプラットフ
ォームにおいて自分の処理状況が認識され、上記処理時
間Ｔ1 が設定時間Ｔ0 を越えたユニットプラットフォー
ム＃１によって、自分に接続されている他のユニットプ
ラットフォームに該処理時間Ｔ1 が通知され、前記ユニ
ットプラットフォーム＃１以外の各ユニットプラットフ
ォームにより、自分のテストアプリケーションプログラ
ムの処理時間Ｔ2 と前記処理時間Ｔ1 との大小関係が比
較されて、Ｔ2 ＜Ｔ1 の場合に限り、前記ユニットプラ
ットフォーム＃１に返答される。この返答の結果に基づ
いて、前記ユニットプラットフォーム＃１により、該ユ
ニットプラットフォーム＃１に接続されている一部のア
プリケーションプログラムが、他のユニットプラットフ
ォームから受け取った処理時間のうち最小値を返答して
きたユニットプラットフォームに接続切替えされ、該ユ
ニットプラットフォーム＃１の負荷の一部が分散されて
協調処理され、各ユニットプラットフォームの負荷状態
が定期的に見直されて、ユニットプラットフォーム全体
について負荷状態が平準化される。
ットフォームにより、ユニットプラットフォーム間に共
通した、テストタスクモジュールにアクセスするテスト
アプリケーションプログラムが定期的に起動実行され、
その処理時間Ｔ1 が求められて、各ユニットプラットフ
ォームにおいて自分の処理状況が認識され、上記処理時
間Ｔ1 が設定時間Ｔ0 を越えたユニットプラットフォー
ム＃１によって、自分に接続されている他のユニットプ
ラットフォームに該処理時間Ｔ1 が通知され、前記ユニ
ットプラットフォーム＃１以外の各ユニットプラットフ
ォームにより、自分のテストアプリケーションプログラ
ムの処理時間Ｔ2 と前記処理時間Ｔ1 との大小関係が比
較されて、Ｔ2 ＜Ｔ1 の場合に限り、前記ユニットプラ
ットフォーム＃１に返答される。この返答の結果に基づ
いて、前記ユニットプラットフォーム＃１により、該ユ
ニットプラットフォーム＃１に接続されている一部のア
プリケーションプログラムが、他のユニットプラットフ
ォームから受け取った処理時間のうち最小値を返答して
きたユニットプラットフォームに接続切替えされ、該ユ
ニットプラットフォーム＃１の負荷の一部が分散されて
協調処理され、各ユニットプラットフォームの負荷状態
が定期的に見直されて、ユニットプラットフォーム全体
について負荷状態が平準化される。
【００１３】
【実施例】以下、図面に基づいて本発明の一実施例を説
明する。図１は本発明の一実施例のユニットＰＦを示す
構成図である。図において、１はユニットＰＦで、その
内部には、テストアプリケーションプログラムＡＰ（Ｔ
ＥＳＴ）１１、テストタスクモジュールＭ（ＴＥＳＴ）
１２、アプリケーションプログラムＡＰ（１），ＡＰ
（２）とインタフェースをとるＡＰインタフェーサ１
３、処理状況収集機能を有するデータコレクタ１４、分
散協調処理機能を有するネゴシエータ１５、アクセッサ
１６、オペレーションタスクモジュールＭ（１），Ｍ
（２）とインタフェースをとるＭインタフェーサ１７、
及びデータベース（ＤＢ）とインタフェースをとるＤＢ
インタフェーサ１８を内蔵している。
明する。図１は本発明の一実施例のユニットＰＦを示す
構成図である。図において、１はユニットＰＦで、その
内部には、テストアプリケーションプログラムＡＰ（Ｔ
ＥＳＴ）１１、テストタスクモジュールＭ（ＴＥＳＴ）
１２、アプリケーションプログラムＡＰ（１），ＡＰ
（２）とインタフェースをとるＡＰインタフェーサ１
３、処理状況収集機能を有するデータコレクタ１４、分
散協調処理機能を有するネゴシエータ１５、アクセッサ
１６、オペレーションタスクモジュールＭ（１），Ｍ
（２）とインタフェースをとるＭインタフェーサ１７、
及びデータベース（ＤＢ）とインタフェースをとるＤＢ
インタフェーサ１８を内蔵している。
【００１４】アクセッサ１６は、ＡＰインタフェーサ１
３を介して複数のアプリケーションプログラムＡＰ
（１），ＡＰ（２）からのアクセス要求を管理するアク
セス管理機能を有するもので、例えばアプリケーション
プログラムに優先順位を予め決めておき、この優先順位
に基づき優先順位アクセス制御（プライオリティアクセ
ス制御）を行なう。
３を介して複数のアプリケーションプログラムＡＰ
（１），ＡＰ（２）からのアクセス要求を管理するアク
セス管理機能を有するもので、例えばアプリケーション
プログラムに優先順位を予め決めておき、この優先順位
に基づき優先順位アクセス制御（プライオリティアクセ
ス制御）を行なう。
【００１５】次に、前述の構成よりなる本実施例の動作
を図１０及び図１１に基づいて説明する。ユニットＰＦ
１は、データコレクタ１４及びネゴシエータ１５によっ
て、テストアプリケーションプログラムＡＰ（ＴＥＳ
Ｔ）１１とテストタスクモジュールＭ（ＴＥＳＴ）１２
を定期的に起動実行し、テストアプリケーションＡＰ
（ＴＥＳＴ）１１の処理時間Ｔ1 を測定する（Ｓ１）。
テストアプリケーションＡＰ（ＴＥＳＴ）１１は図１０
に示すようにテストタスクモジュールＭ（ＴＥＳＴ）１
２へのアクセスを依頼するものとする。
を図１０及び図１１に基づいて説明する。ユニットＰＦ
１は、データコレクタ１４及びネゴシエータ１５によっ
て、テストアプリケーションプログラムＡＰ（ＴＥＳ
Ｔ）１１とテストタスクモジュールＭ（ＴＥＳＴ）１２
を定期的に起動実行し、テストアプリケーションＡＰ
（ＴＥＳＴ）１１の処理時間Ｔ1 を測定する（Ｓ１）。
テストアプリケーションＡＰ（ＴＥＳＴ）１１は図１０
に示すようにテストタスクモジュールＭ（ＴＥＳＴ）１
２へのアクセスを依頼するものとする。
【００１６】これにより、ユニットＰＦ１の負荷状態
は、テストアプリケーションＡＰ（ＴＥＳＴ）１１の起
動開始時刻とテストタスクモジュールＭ（ＴＥＳＴ）１
２からの返答完了時刻との差Ｔ1 として、テストアプリ
ケーションＡＰ（ＴＥＳＴ）１１実行により測定でき
る。
は、テストアプリケーションＡＰ（ＴＥＳＴ）１１の起
動開始時刻とテストタスクモジュールＭ（ＴＥＳＴ）１
２からの返答完了時刻との差Ｔ1 として、テストアプリ
ケーションＡＰ（ＴＥＳＴ）１１実行により測定でき
る。
【００１７】即ち、測定時間Ｔ1 はユニットＰＦ１の負
荷状態を反映している。例えば、アクセス制御（プライ
オリティアクセス制御）の優先順位を５段階に設定した
場合、テストアプリケーションＡＰ（ＴＥＳＴ）１１の
優先順位をＸ＝３と設定すれば、中位的な優先順位のア
プリケーションＡＰの処理時間を測定することになる。
ユニットＰＦ１へのアクセス回数が多くなると、優先順
位に基づいた制御でアプリケーションＡＰは待ち状態と
なり、処理時間が長くなる。
荷状態を反映している。例えば、アクセス制御（プライ
オリティアクセス制御）の優先順位を５段階に設定した
場合、テストアプリケーションＡＰ（ＴＥＳＴ）１１の
優先順位をＸ＝３と設定すれば、中位的な優先順位のア
プリケーションＡＰの処理時間を測定することになる。
ユニットＰＦ１へのアクセス回数が多くなると、優先順
位に基づいた制御でアプリケーションＡＰは待ち状態と
なり、処理時間が長くなる。
【００１８】この処理時間Ｔ1 がテストアプリケーショ
ンＡＰ（ＴＥＳＴ）によってデータコレクタ１４に申告
され、データコレクタ１４によって処理時間Ｔ1 が予め
設定されている基準時間Ｔ0 以内であるか否かが判定さ
れる（Ｓ２）。
ンＡＰ（ＴＥＳＴ）によってデータコレクタ１４に申告
され、データコレクタ１４によって処理時間Ｔ1 が予め
設定されている基準時間Ｔ0 以内であるか否かが判定さ
れる（Ｓ２）。
【００１９】この判定の結果、処理時間Ｔ1 があらかじ
め設定した時間Ｔ0 を越えた場合に、ネゴシエータ１５
を介して、接続されている他の全てのユニットＰＦ１に
処理時間Ｔ1 が通知される（Ｓ３）。この通知の受け取
りも各ユニットＰＦのネゴシエータ１５によって行なわ
れる。
め設定した時間Ｔ0 を越えた場合に、ネゴシエータ１５
を介して、接続されている他の全てのユニットＰＦ１に
処理時間Ｔ1 が通知される（Ｓ３）。この通知の受け取
りも各ユニットＰＦのネゴシエータ１５によって行なわ
れる。
【００２０】この後、通知を受けた各ユニットＰＦ１は
自分のテストアプリケーションＡＰ（ＴＥＳＴ）の処理
時間Ｔ2 と通知された処理時間Ｔ1 とを比較し（Ｓ４，
Ｓ５）、この比較の結果、処理時間Ｔ2 が処理時間Ｔ1
より短い場合に限り、処理時間Ｔ1 を通知してきたユニ
ットＰＦ１（オーバーロードを申告したユニットＰＦ
１）に処理時間Ｔ2 を返答する（Ｓ６，Ｓ７）。
自分のテストアプリケーションＡＰ（ＴＥＳＴ）の処理
時間Ｔ2 と通知された処理時間Ｔ1 とを比較し（Ｓ４，
Ｓ５）、この比較の結果、処理時間Ｔ2 が処理時間Ｔ1
より短い場合に限り、処理時間Ｔ1 を通知してきたユニ
ットＰＦ１（オーバーロードを申告したユニットＰＦ
１）に処理時間Ｔ2 を返答する（Ｓ６，Ｓ７）。
【００２１】これにより、処理時間Ｔ1 のユニットＰＦ
１（オーバーロードを申告したユニットＰＦ１）は、最
小処理時間を返答したユニットＰＦ１に一部の負荷（処
理）を依頼し（Ｓ８）、該当するアプリケーションプロ
グラムＡＰを最小処理時間を返答したユニットＰＦ１に
接続し直す（Ｓ９）。
１（オーバーロードを申告したユニットＰＦ１）は、最
小処理時間を返答したユニットＰＦ１に一部の負荷（処
理）を依頼し（Ｓ８）、該当するアプリケーションプロ
グラムＡＰを最小処理時間を返答したユニットＰＦ１に
接続し直す（Ｓ９）。
【００２２】前述したように、過負荷状態のユニットＰ
Ｆ１は適切な他のユニットＰＦ１に処理の一部を依頼す
る事が可能となる。これにより、システム全体について
負荷の平均化が行なえ、高性能化が達成できる。また、
負荷がある閾値を越えた場合にのみに分散協調を行なっ
ているので、通信のためのオーバーヘッドが少なくな
り、高速処理が可能となる。
Ｆ１は適切な他のユニットＰＦ１に処理の一部を依頼す
る事が可能となる。これにより、システム全体について
負荷の平均化が行なえ、高性能化が達成できる。また、
負荷がある閾値を越えた場合にのみに分散協調を行なっ
ているので、通信のためのオーバーヘッドが少なくな
り、高速処理が可能となる。
【００２３】さらに、各ユニットＰＦは同格であり、負
荷がある閾値を越えて負荷軽減のための依頼を行いたい
ユニットＰＦが存在する場合に初めて、このユニットＰ
Ｆが主体となってシステム全体について協調処理を行
い、ハイアラーキが生じる。この協調処理が終了する
と、再び同格関係となる。この同格性のため、一つのユ
ニットＰＦが故障してもシステム全体への影響が少ない
と共に、システムの拡張性に優れるという特徴がある。
荷がある閾値を越えて負荷軽減のための依頼を行いたい
ユニットＰＦが存在する場合に初めて、このユニットＰ
Ｆが主体となってシステム全体について協調処理を行
い、ハイアラーキが生じる。この協調処理が終了する
と、再び同格関係となる。この同格性のため、一つのユ
ニットＰＦが故障してもシステム全体への影響が少ない
と共に、システムの拡張性に優れるという特徴がある。
【００２４】次に、図１２に基づいてユニットＰＦの数
ｎ＝３の場合の動作例を説明する。ユニットＰＦ＃１〜
＃３、アプリケーションプログラムＡＰ（１），ＡＰ
（２）、オペレーションタスクモジュールＭ１〜Ｍ３及
びデータベースＤＢ１が、イーサネットで代表されるＬ
ＡＮ（Local Area Network) の様なＤＣＮ（Data Commu
nication Network: データ転送ネットワーク）によって
接続されている（図１２の(a)）。論理的には図１２の
(b) に示すように、ＤＢ１，Ｍｉ（ｉ＝１，２，３）は
ユニットＰＦ＃１，ユニットＰＦ＃２，ユニットＰＦ＃
３に接続されている。
ｎ＝３の場合の動作例を説明する。ユニットＰＦ＃１〜
＃３、アプリケーションプログラムＡＰ（１），ＡＰ
（２）、オペレーションタスクモジュールＭ１〜Ｍ３及
びデータベースＤＢ１が、イーサネットで代表されるＬ
ＡＮ（Local Area Network) の様なＤＣＮ（Data Commu
nication Network: データ転送ネットワーク）によって
接続されている（図１２の(a)）。論理的には図１２の
(b) に示すように、ＤＢ１，Ｍｉ（ｉ＝１，２，３）は
ユニットＰＦ＃１，ユニットＰＦ＃２，ユニットＰＦ＃
３に接続されている。
【００２５】当初、アプリケーションプログラムＡＰは
実線で示すように、ユニットＰＦ＃１にのみ接続されて
いるとする。図１２の(b) に図示していないが他のアプ
リケーションプログラムＡＰ群はユニットＰＦ＃２やユ
ニットＰＦ＃３にも接続されているとする。これら全て
のアプリケーションプログラムＡＰは、他のユニットＰ
Ｆに接続する機能を有しているとする。
実線で示すように、ユニットＰＦ＃１にのみ接続されて
いるとする。図１２の(b) に図示していないが他のアプ
リケーションプログラムＡＰ群はユニットＰＦ＃２やユ
ニットＰＦ＃３にも接続されているとする。これら全て
のアプリケーションプログラムＡＰは、他のユニットＰ
Ｆに接続する機能を有しているとする。
【００２６】ユニットＰＦ＃１が図１１のフローチャー
トに示す処理において過負荷と測定した場合（Ｔ1 ＞Ｔ
0 ）、ユニットＰＦ＃１からユニットＰＦ＃２、或いは
ユニットＰＦ＃３に対して処理依頼が出される。図１１
のアルゴリズムに従って、処理依頼先のユニットＰＦが
決定される（例えばユニットＰＦ＃２とする）。
トに示す処理において過負荷と測定した場合（Ｔ1 ＞Ｔ
0 ）、ユニットＰＦ＃１からユニットＰＦ＃２、或いは
ユニットＰＦ＃３に対して処理依頼が出される。図１１
のアルゴリズムに従って、処理依頼先のユニットＰＦが
決定される（例えばユニットＰＦ＃２とする）。
【００２７】ユニットＰＦ＃１は、アプリケーションプ
ログラムＡＰ群の内の一部のアプリケーションプログラ
ムＡＰを選択（例えば待ち行列の後からカウントして待
ち状態にあるＡＰの半分）して、アプリケーションプロ
グラムＡＰに接続先の変更を通知する。通知を受けたア
プリケーションプログラムＡＰは、ユニットＰＦ＃１か
らユニットＰＦ＃２へ依頼先を変更する。これによって
全体として処理時間の短縮が可能となる。
ログラムＡＰ群の内の一部のアプリケーションプログラ
ムＡＰを選択（例えば待ち行列の後からカウントして待
ち状態にあるＡＰの半分）して、アプリケーションプロ
グラムＡＰに接続先の変更を通知する。通知を受けたア
プリケーションプログラムＡＰは、ユニットＰＦ＃１か
らユニットＰＦ＃２へ依頼先を変更する。これによって
全体として処理時間の短縮が可能となる。
【００２８】尚、処理時間Ｔ2 に関し、処理時間Ｔ1 と
処理時間Ｔ2 との大小関係を比較する直前に測定したテ
ストアプリケーションプログラム処理時間を記憶してお
き、この値を用いるようにしても良い。
処理時間Ｔ2 との大小関係を比較する直前に測定したテ
ストアプリケーションプログラム処理時間を記憶してお
き、この値を用いるようにしても良い。
【００２９】
【発明の効果】以上説明したように本発明の請求項１記
載の負荷分散化プラットフォームによれば、ユニットプ
ラットフォーム内にプラットフォーム自身の処理状況収
集手段と、分散協調処理手段を設けているため、負荷が
ある閾値を越えた際に他のユニットプラットフォームに
通知し、前記閾値を越えた分の負荷が他のユニットプラ
ットホームに分散されて処理されるので、分散協調しな
いアルゴリズムを前記分散協調処理手段に実装すること
が可能となり、分散処理にありがちな処理の遅延を避け
ることができると共に、通信のためのオーバーヘッドを
減らし、処理の高速化を図ることができる。さらに、本
発明の構成では、各ユニットプラットフォームは同格で
あるため、１つのユニットプラットフォームが故障して
も、システム全体への影響が少ないと共に、システムの
拡張性に優れるという特徴がある。
載の負荷分散化プラットフォームによれば、ユニットプ
ラットフォーム内にプラットフォーム自身の処理状況収
集手段と、分散協調処理手段を設けているため、負荷が
ある閾値を越えた際に他のユニットプラットフォームに
通知し、前記閾値を越えた分の負荷が他のユニットプラ
ットホームに分散されて処理されるので、分散協調しな
いアルゴリズムを前記分散協調処理手段に実装すること
が可能となり、分散処理にありがちな処理の遅延を避け
ることができると共に、通信のためのオーバーヘッドを
減らし、処理の高速化を図ることができる。さらに、本
発明の構成では、各ユニットプラットフォームは同格で
あるため、１つのユニットプラットフォームが故障して
も、システム全体への影響が少ないと共に、システムの
拡張性に優れるという特徴がある。
【００３０】また、請求項２記載のプラットフォームの
負荷分散処理方法によれば、過負荷状態のユニットプラ
ットフォームは適切な他のユニットプラットフォームに
処理の一部を依頼する事が可能となり、システム全体に
ついて負荷の平均化が行なえ、高性能化が達成できる。
また、負荷がある閾値を越えた場合にのみに分散協調が
行なわれるので、通信のためのオーバーヘッドが少なく
なり、高速処理が可能となる。さらに、各ユニットプラ
ットフォームは同格であり、負荷がある閾値を越えて負
荷軽減のための依頼を行いたいユニットプラットフォー
ムが存在する場合に初めて、このユニットプラットフォ
ームが主体となってシステム全体について協調処理を行
っているので、一つのユニットプラットフォームが故障
してもシステム全体への影響が少ないと共に、システム
の拡張性に優れるという特徴を有している
負荷分散処理方法によれば、過負荷状態のユニットプラ
ットフォームは適切な他のユニットプラットフォームに
処理の一部を依頼する事が可能となり、システム全体に
ついて負荷の平均化が行なえ、高性能化が達成できる。
また、負荷がある閾値を越えた場合にのみに分散協調が
行なわれるので、通信のためのオーバーヘッドが少なく
なり、高速処理が可能となる。さらに、各ユニットプラ
ットフォームは同格であり、負荷がある閾値を越えて負
荷軽減のための依頼を行いたいユニットプラットフォー
ムが存在する場合に初めて、このユニットプラットフォ
ームが主体となってシステム全体について協調処理を行
っているので、一つのユニットプラットフォームが故障
してもシステム全体への影響が少ないと共に、システム
の拡張性に優れるという特徴を有している
【図１】本発明の一実施例を示す構成図
【図２】従来の技術を説明する図
【図３】従来の技術を説明する図
【図４】従来の技術を説明する図
【図５】従来の技術を説明する図
【図６】従来の技術を説明する図
【図７】従来の技術を説明する図
【図８】本発明の概要を説明するための構成図
【図９】本発明の概要を説明するための構成図
【図１０】本発明の一実施例の動作を説明する図
【図１１】本発明の一実施例の動作を説明するフローチ
ャート
ャート
【図１２】本発明の一実施例を説明する図
１…ユニットプラットフォーム、１１…テストアプリケ
ーションプログラムＡＰ（ＴＥＳＴ）、１２…テストタ
スクモジュールＭ（ＴＥＳＴ）、１３…ＡＰインタフェ
ーサ、１４…データコレクタ（処理状況収集手段）、１
５…ネゴシエータ（分散協調処理手段）、１６…アクセ
ッサ、１７…Ｍインタフェーサ、１８…ＤＢインタフェ
ーサ。
ーションプログラムＡＰ（ＴＥＳＴ）、１２…テストタ
スクモジュールＭ（ＴＥＳＴ）、１３…ＡＰインタフェ
ーサ、１４…データコレクタ（処理状況収集手段）、１
５…ネゴシエータ（分散協調処理手段）、１６…アクセ
ッサ、１７…Ｍインタフェーサ、１８…ＤＢインタフェ
ーサ。
Claims (2)
- 【請求項１】 データベース群と、タスクモジュール群
と、前記２群を用いて所定のタスクを実行するアプリケ
ーションプログラム群と、前記３群間相互の結合部であ
るユニットプラットフォーム群とで構成された分散型処
理システムにおいて、 各ユニットプラットフォームは、データベースとタスク
モジュールとアプリケーションプログラムとに対してイ
ンタフェースをとるインタフェース手段と、 アプリケーションプログラムからのアクセス要求を管理
するアクセス管理手段と、 各ユニットプラットフォームが、自分の負荷状態を認識
する処理状況収集手段と、 各ユニットプラットフォーム同士が、上記負荷状態を通
知し合って、ユニットプラットフォーム間の負荷状態を
平準化するように制御する分散協調処理手段とから構成
され、 各データベース、各タスクモジュール、各アプリケーシ
ョンプログラムが複数のユニットプラットフォームに接
続されてなることを特徴とする負荷分散化プラットフォ
ーム。 - 【請求項２】 データベース群と、タスクモジュール群
と、前記２群を用いて所定のタスクを実行するアプリケ
ーションプログラム群と、前記３群間相互の結合部であ
るユニットプラットフォーム群とで構成された分散型処
理システムにおけるプラットフォームの負荷分散処理方
法であって、 各ユニットプラットフォームが、ユニットプラットフォ
ーム間に共通した、テストタスクモジュールにアクセス
するテストアプリケーションプログラムを定期的に起動
実行し、その処理時間Ｔ1 を求めて、自分の処理状況を
認識する第１過程と、 上記処理時間Ｔ1 が設定時間Ｔ0 を越えたユニットプラ
ットフォーム＃１が、自分に接続されている他のユニッ
トプラットフォームに該処理時間Ｔ1 を通知する第２過
程と、 前記ユニットプラットフォーム＃１以外の各ユニットプ
ラットフォームが、自分のテストアプリケーションプロ
グラムの処理時間Ｔ2 と前記処理時間Ｔ1 との大小関係
を比較して、Ｔ2 ＜Ｔ1 の場合に限り、前記ユニットプ
ラットフォーム＃１に返答する第３過程と、 前記ユニットプラットフォーム＃１が、自分に接続され
ている一部のアプリケーションプログラムを、他のユニ
ットプラットフォームから受け取った処理時間のうち最
小値を返答してきたユニットプラットフォームに接続切
替えして、自分の負荷の一部を分散し協調処理させる第
４過程とによって、 各ユニットプラットフォームの負荷状態を定期的に見直
して、ユニットプラットフォーム全体について負荷状態
を平準化することを特徴とするプラットフォームの負荷
分散処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8316094A JPH07295843A (ja) | 1994-04-21 | 1994-04-21 | 負荷分散化プラットフォーム及びその負荷分散処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8316094A JPH07295843A (ja) | 1994-04-21 | 1994-04-21 | 負荷分散化プラットフォーム及びその負荷分散処理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH07295843A true JPH07295843A (ja) | 1995-11-10 |
Family
ID=13794508
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8316094A Pending JPH07295843A (ja) | 1994-04-21 | 1994-04-21 | 負荷分散化プラットフォーム及びその負荷分散処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH07295843A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08235127A (ja) * | 1995-02-28 | 1996-09-13 | Chugoku Nippon Denki Software Kk | 自動負荷分散方法および装置 |
| WO2004056054A1 (ja) * | 2002-12-17 | 2004-07-01 | Fujitsu Limited | 負荷分散方法及びその装置 |
| US7657653B2 (en) | 2002-12-17 | 2010-02-02 | Fujitsu Limited | Load decentralization method and apparatus thereof |
| US7689129B2 (en) | 2004-08-10 | 2010-03-30 | Panasonic Corporation | System-in-package optical transceiver in optical communication with a plurality of other system-in-package optical transceivers via an optical transmission line |
-
1994
- 1994-04-21 JP JP8316094A patent/JPH07295843A/ja active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08235127A (ja) * | 1995-02-28 | 1996-09-13 | Chugoku Nippon Denki Software Kk | 自動負荷分散方法および装置 |
| WO2004056054A1 (ja) * | 2002-12-17 | 2004-07-01 | Fujitsu Limited | 負荷分散方法及びその装置 |
| JPWO2004056054A1 (ja) * | 2002-12-17 | 2006-04-20 | 富士通株式会社 | 負荷分散方法及びその装置 |
| US7657653B2 (en) | 2002-12-17 | 2010-02-02 | Fujitsu Limited | Load decentralization method and apparatus thereof |
| US7689129B2 (en) | 2004-08-10 | 2010-03-30 | Panasonic Corporation | System-in-package optical transceiver in optical communication with a plurality of other system-in-package optical transceivers via an optical transmission line |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107545338B (zh) | 业务数据处理方法及业务数据处理系统 | |
| CA2203534C (en) | Dynamically controlled routing using dynamic management of intra-link traffic to virtual destination nodes | |
| Lin et al. | A dynamic load-balancing policy with a central job dispatcher (LBC) | |
| CA2471594C (en) | Method and apparatus for web farm traffic control | |
| US6662207B2 (en) | Agent system and information processing method for same | |
| CN108965014B (zh) | QoS感知的服务链备份方法及系统 | |
| JPH07282013A (ja) | 分散処理システム | |
| US7856572B2 (en) | Information processing device, program thereof, modular type system operation management system, and component selection method | |
| JPH08289012A (ja) | 信号伝送リンクのトラフィックを転換する方法 | |
| CN106657416B (zh) | 一种控制器负载均衡方法及装置 | |
| CN110086726A (zh) | 一种自动切换Kubernetes主节点的方法 | |
| CN115202580B (zh) | 一种多路径设备检测方法、装置、设备、存储介质 | |
| CN119728592A (zh) | 一种云容器集群的分布式管理系统及方法 | |
| CN119766864B (zh) | 基于数据感知的微服务伸缩与请求路由更新方法、系统及设备 | |
| CN118535309A (zh) | 多集群系统及其弹性伸缩方法、计算设备集群和介质 | |
| CN119583555A (zh) | 电力多网系资源融合方法、装置、设备及介质 | |
| CN106576260A (zh) | Nfv系统中的策略协调方法和装置 | |
| EP0863680B1 (en) | Method and apparatus for improved call control scheduling in a distributed system with dissimilar call processors | |
| JPH07295843A (ja) | 負荷分散化プラットフォーム及びその負荷分散処理方法 | |
| CN116614499A (zh) | 算力网络广域资源协同调度方法 | |
| CN113742030B (zh) | 跨区服务配置方法、装置和存储介质 | |
| CN120811982A (zh) | 基于动态一致性哈希的跨域交换引擎设备负载均衡方法 | |
| CN115118666B (zh) | 一种负载重新分配方法及装置 | |
| CN116820756A (zh) | 面向多云架构的计算资源智能调度方法、系统及设备 | |
| CN118900249B (zh) | 资源调度方法及装置 |