JP3915950B2

JP3915950B2 - 分散システムにおけるリソース情報処理方法

Info

Publication number: JP3915950B2
Application number: JP05400998A
Authority: JP
Inventors: 伸宏木村; 光瀬社家
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 1998-03-05
Filing date: 1998-03-05
Publication date: 2007-05-16
Anticipated expiration: 2018-03-05
Also published as: JPH11249997A

Description

【０００１】
【発明の属する技術分野】
本発明は、１つの計算機上で動作するアプリケーション（単にＡＰという）が、他の計算機上で動作するＡＰと連携をとりながら処理を行う分散構成システムに関し、特に、連携するＡＰが搭載している計算機のリソース情報を把握し、その値に応じた処理をＡＰ毎に行う必要がある分散構成システムにおけるリソース情報処理方法に関する。
【０００２】
【従来の技術】
システムに対する要求の多様化、信頼性向上に対応するため、システム構成の分散化が行われている。各計算機にそれぞれ異なった機能を有するＡＰを配備し、それぞれのＡＰ間で連携をとることで、多種多様なサービスが提供されている。また、分散構成システムにおいて、無中断かつ、処理遅延のない、信頼性のあるサービスが求められている。しかし、このように計算機間にまたがってＡＰの通信を行う場合、通信先のリソース情報（ＣＰＵ，メモリーなどの稼働状況、例えば、使用率）を把握せず通信を行った場合、通信先のＡＰが動作している計算機で処理過多によるリソースの枯渇が生じていると、その枯渇を更に助長することになる。このようなリソースの枯渇の助長を回避するため、ＡＰは通信を行う前に通信先の計算機のリソース情報を収集し、それに応じた処理を行う必要がある。
【０００３】
この通信先のリソース情報を収集する方法として従来から幾つかの方法が知られている。
汎用ＯＳ（Ｏperating Ｓystem）のＵＮＩＸでは、計算機のリソース情報を収集できるvmstatやsarなどのコマンドを提供し、計算機に閉じたリソース情報収集が可能であり、さらに、他の計算機のリソース情報を収集を行う場合、やはりＵＮＩＸが提供するrshコマンドを併用することにより、通信先計算機のリソース情報の取得が可能である（以下、従来技術１という）。
【０００４】
また、計算機間にまたがるリソース情報の取得方法として、ＳＮＭＰ（Ｓimple Ｎetwork Ｍanagement Ｐrotocol）を用いた方法がある。本手法は、一つの計算機にマネージャを配備するとともに、マネージャを配備した計算機を含め、複数の計算機に情報収集用のエージェントを配備し、各エージェントがマネージャの要求に応じてリソース情報を取得(get)する方法（以下、従来技術２という）、あるいは、エージェントが一定間隔でリソース情報を自律的にマネージャに通知(trap)する方法（以下、従来技術３という）によって情報を収集するようにしたものである。
【０００５】
ＡＰの要求に対してリソース情報を取得する方法の場合、ＡＰは、マネージャに対してリソース情報要求を行なった後、リソース情報収集の応答を受信するまで処理を中断して待つことになる。リソース情報収集には、リソース情報収集要求を受信したマネージャが、各計算機上のエージェントにリソース収集要求を行い、それぞれのエージェントがリソース情報を収集し、その収集された情報を応答する方法となる。また、リソース情報を一定間隔で通知する方法の場合、ＡＰが当該のリソース情報項目の必要性の有無を問わず、エージェントはマネージャにリソース情報を一定間隔毎に通知し、マネージャはその情報をＡＰからの要求時に応答することになる。
【０００６】
【発明が解決しょうとする課題】
上記のように、分散構成システムでは、１つの計算機上で動作するＡＰが、他の計算機上で動作するＡＰと連携を行っている。そこで、連携をとるため、通信を行う相手先のＡＰが動作する計算機のリソースが枯渇している場合、更に、枯渇状態を助長することになり、サービス遅延が発生し、システム全体の信頼性低下につながる。そこで、ＡＰは、通信を行う前に、通信ＡＰが動作する計算機のリソース情報を取得する必要性が生じる。
【０００７】
従来技術１を用いて、通信を行う前に通信先計算機のリンース情報を取得するには、ＵＮＩＸが提供するコマンドを用いる必要があるが、このＵＮＩＸのコマンドは、処理に時間がかかり、即時処理を要求されるＡＰの通信情報発行遅延の要因となる。また、リソースの枯渇状態か否かに関係なく、計算機間をまたがるリソース情報の収集を行う場合や、異なるＡＰが同一のリソース情報を収集する際にそれぞれ計算機間にまたがるリソース情報収集を行う場合には、分散構成システム全体に負荷をかけることになる。
【０００８】
また、従来技術２を用いた場合、上記従来技術１と同様に、ＡＰがリソース情報の要求時に、リソース情報を収集するため、ＡＰのリソース情報の要求を受信したマネージャは、エージェントにそのリソース情報を収集させ、その結果をＡＰに返すため、リソース情報の収集の時間は、ＡＰの処理中断となり、即時処理を求められるＡＰの遅延の要因となる。そして、上記従来技術１と同様に、リソースの枯渇状態か否かに関係なく、計算機間をまたがるリソース情報の収集を行う場合や、異なるＡＰが同一のリソース情報を収集する際にそれぞれ計算機間にまたがるリソース情報収集を行う場合には、分散構成システム全体に負荷をかけることになる。
【０００９】
さらに、従来技術３を用いた場合、分散構成システム配下の各計算機に配置されたエージェントは予め決められたリソース情報を一定間隔で収集し、上位のマネージャに情報収集の度に通知を行われる。従って、情報の収集の度に、計算機間に収集情報が発行されるため、不必要に計算機のリソース情報を使用してしまい、分散構成システム全体への負荷となる。また、ＡＰのリソース情報要求に対して、マネージャは応答を即座に返せるが、この場合もマネージャとＡＰ間に情報のやり取りがあるため、わずかであるがＡＰの処理中断が必要である。
つまり、従来の技術では、ＡＰからのリソース情報収集要求に対する即時応答性に欠け、同一項目の収集複数収集や不必要なリソース情報の通知によるシステムリソースの無駄使いが行われる。
【００１０】
本発明の目的は、上記問題点を解消し、ＡＰが要求したリソース情報の参照をリアルタイムに参照できるように、共有メモリにリソース情報値を書き込むとともに、その共有メモリを参照できる手段を提供し、また、複数のＡＰから同一のリソース情報項目が登録された場合、同一の共有メモリを参照するようＡＰに提示することやある特定の値を超えた場合のみ計算機間に収集されたリソ一ス情報の通知を行う方法を採用することで、システムリソースの使用を必要最小限とする分散構成システム上で動作するＡＰの通信先のリソース情報処理方法を提供することにある。
【００１１】
【課題を解決するための手段】
上記目的を達成するために、本発明のリソース情報処理方法は、１つの計算機上で動作するＡＰが他の計算機で動作するＡＰと通信を行う時、ＡＰ（図１の１ｈ、１ｉ、１ｊ、１ｋ、１ｌ、１ｍのアプリケーション）が、そのＡＰが動作する計算機、もしくはその他の計算機のリソース情報を収集するため、収集したいリソース情報項目を登録するステップと、その登録されたリソース情報項目の情報を一定間隔毎に収集（同、１ｅ、１ｇの情報収集処理ブロック）するステップと、収集した情報値がある特定のしきい値を超えた場合に、該情報値を計算機間に流通するステップ（同、１ｄ、１ｆの情報管理処理ブロック）と、流通された情報値を当該リソース情報項目を登録したＡＰが随時参照できるよう共有メモリに書き込むステップ（図６のステップ）と、前記ＡＰが登録した情報項目を解除するステップを有することを特徴としている。
【００１２】
また、本発明のリソース情報処理方法は、１つの計算機で動作するＡＰが、他の計算機上で動作するＡＰに通信する時、通信元ＡＰが、通信先ＡＰが動作する計算機、もしくはその他の計算機の１つのリソース情報を収集するため、収集したいリソース情報項目を登録するステップ（図７〜図１１のステップ）と、その登録された情報項目を一定間隔で収集するステップと、個々のリソース情報項目毎に、収集した情報値が特定のしきい値を超えるか否かを判定するステップ（第１２図のステップ）と、収集した情報値が前記特定のしきい値を超えた場合、当該情報値を計算機間に流通するステップと、リソース情報項目を登録したＡＰが該リソース情報を参照するステップ（図１３のステップ）と、当該ＡＰの要求により、登録した情報収集要求を解除するステップ（図１４のステップ）を有することを特徴としている。
【００１５】
【発明の実施の形態】
以下に、図面を参照しながら本発明の実施例について説明する。
図１は、本発明を、１つの計算機上で動作するアプリケーション（ＡＰ）が、他の計算機上で動作するＡＰと連携をとりながら処理を行う分散構成システムに適用した構成概略図である。
【００１６】
図１において、１ａは複数の計算機によって構成される分散構成システム、１ｂおよび１ｃは計算機、１ｄおよび１ｆは各計算機上のＡＰから登録されるリソース情報項目の管理を行う情報管理処理ブロック、１ｅおよび１ｇは登録されたリソース情報を一定間隔で収集し、特定のしきい値を超えた場合のみ、リソース情報を上位の情報管理処理ブロック１ｄおよび１ｆに通知する情報収集処理ブロック、１ｈ，１ｉ，１ｊ，１ｋ，１ｌ，および１ｍは分散構成システム１ａで提供するサービスを処理するＡＰ（アプリケーション）である。
【００１７】
図２は、ＡＰが収集したい情報項目を登録する時、それぞれの計算機上の情報管理処理ブロックが、付与する登録識別子の対応をとる登録識別子対応テーブルである。同図において、２ａ，２ｃ，２ｅは登録識別子、２ｂ，２ｄ，２ｆは次の情報のアドレスであり、登録識別子と次の情報のアドレスを一組にして管理している。まず、情報管理処理ブロックが動作する計算機上で管理している登録識別子を２ａに登録し、次の情報のアドレス２ｂに最終を示す値を設定する。ＡＰからの新たな登録要求に対し、同一のリソース情報項目を保持していない場合、新たに登録識別子を払い出す（すなわち、後述するように、登録識別子２ｃおよび次の情報のアドレス２ｄの組を１つ追加し、次のアドレス２ｂに登録識別子２ｃのアドレスを、２ｄに最終の情報を示す値を付与する）。
【００１８】
図３は、システムに一意な登録識別子のフォーマットを示す図である。同図において、３ａは計算機識別子、３ｂは情報管理処理ブロック内識別子である。分散構成システム１ａを構成する計算機個々に保持され、分散構成システム１ａ内で一意となる識別子としてＵＮＩＸの計算機識別子３ａを登録識別子の一構成番号として用い、さらに、それぞれの計算機内で一意とするため、情報管理処理ブロック内で一意となる情報管理処理ブロック内識別子３ｂを新たなリソース情報登録毎に付与する。この２つの識別子を組合わせて登録識別子を構成することで、分散構成システム内に一意な登録識別子を作成する。例えば、情報管理処理ブロック内識別子として情報管理処理ブロック内で付与される通番、例えば登録毎に１，２，３，・・・のように付与される番号を用い、この情報管理処理ブロック内識別子だけでは他の計算機における情報管理処理ブロック内識別子と区別できないため、これと計算機識別子と組み合わせることによってシステムに一意な登録識別子とする。
【００１９】
計算機１ｂ上のＡＰ１ｈから情報管理処理ブロック１ｄに登録されたリソース情報項目と同一の項目、すなわち、同じ計算機における同じリソース情報が、計算機１ｃ上のＡＰ１ｋから情報管理処理ブロック１ｆに同時に登録された場合、別々に登録識別子が払い出される。計算機１ｃ上の情報管理処理ブロック１ｆはＡＰからの通信先の計算機のリソース情報の登録要求受信後、図４に登録されているリソース情報項目を参照し、当該通信先の計算機のリソース情報が登録されていなければ、新たに共有メモリアドレスを確保し、登録識別子を付与し、その登録識別子と共有メモリの先頭アドレスをＡＰに返すとともに、管理テーブル４０に、通信先の計算機とそのリソース情報を、測定先計算機識別子４３とリソース情報項目４２として登録し、計算機１ｂ上の情報管理処理ブロック１ｄにリソース情報項目（通信先の計算機のリソース情報）と登録識別子を通知する。そして、登録通知を受信した情報管理処理ブロック１ｄは、計算機１ｃ上で動作する情報管理処理ブロック１ｆから通知されたリソース情報項目（通信先の計算機のリソース情報）と登録識別子について、自情報管理処理ブロック内で管理する同一の情報項目（同一通信先の計算機の同一リソース情報）に対する登録識別子と異なる場合、１つのリソース情報項目（通信先の計算機のリソース情報）に対して登録識別子を関連づけするため、次の情報のアドレス２ｂに２ｃのアドレスを設定し、この２ｃに登録識別子を追加する。順次、登録された同一の情報項目（同一通信先の計算機の同一リソース情報）に対し、異なった登録識別子が付与された場合、登録識別子管理テーブルに追加していき、最後の登録識別子の次の情報のアドレス２ｆに、最後の情報を示す値を設定する。
【００２０】
図７〜図１１は、ＡＰのリソース情報収集要求の登録の処理フローチャートである。
図７はＡＰのリソース情報登録時の情報管理処理ブロック１ｄの登録要求受信時の処理フローチャートである。
まず、ＡＰ１ｈ，ＡＰ１ｉ，ＡＰ１ｊの何れかから通信先の計算機のリソース情報項目の登録要求通知を受信すると（ステップ１０１）、その登録要求された通信先計算機のリソース情報項目が以前に登録されていて、共有メモリのアドレスを保持しているかどうかを図４の管理テーブルによりチェックする（ステップ１０２）。
【００２１】
図４は、ＡＰが登録要求した通信先の計算機のリソース情報項目と情報値を書き込む共有メモリのアドレスとの対応関係を管理するために、情報管理処理ブロック１ｄおよび１ｆが保持する管理テーブル４０の例である。同図に示すように、管理テーブル４０は、登録識別子ポインタ４１，リソース情報項目４２，測定先計算機識別子４３，ユーザ数４４，共有メモリアドレス４５から構成される。登録識別子ポインタ４１は、登録された情報項目に対する、図２の登録識別子対応テーブルの最初の登録識別子が設定されたアドレスを示すポインタである。リソース情報項目４２は、ＡＰから登録要求された通信先計算機のリソース情報項目である。測定先計算機識別子４３は、リソース情報項目の収集先すなわち通信先計算機で、例えば、分散構成システム配下の全計算機もしくは特定の計算機を指定する識別子である。ユーザ数４４は、その通信先・収集先計算機のリソース情報項目を登録要求したＡＰの数で、登録毎に１増加させ、登録解除毎に１減少させ、０になった時点で当該の情報項目を管理テーブル４０から削除する。共有メモリアドレス４５は、ＡＰが登録要求した通信先・収集先計算機のリソース情報項目の情報値を書き込む共有メモリの先頭のアドレスである。同図は、登録識別子ポインタ４１として“0X004430”，リソース情報項目４２として“ＣＰＵ使用率”，測定先計算機識別子４３として“01（計算機識別子）”，ユーザ数４４として“２”，共有メモリアドレス４５として“0X001110”が登録された場合を示している。
【００２２】
計算機１ｂ上のＡＰ１ｈが、収集したい通信先計算機のリソース情報項目の登録要求を情報管理処理ブロック１ｄに対して行った場合を考える。この登録要求を受信した情報管理処理ブロック１ｄは、図４の管理テーブル４０を照合し、同一の通信先・収集先計算機のリソース情報項目とその共有メモリのアドレスが存在するか否かをチェックする（ステップ１０２）。両方が存在する場合（ステップ１０２；リソース情報項目あり，共用メモリのアドレスあり）、当該通信先・収集先計算機のリソース情報項目のユーザ数４４を１つ増加させ（ステップ１０７）、登録識別子と共有メモリのアドレスを、登録要求してきたＡＰ１ｈに応答すなわち返送する（ステップ１０８）。
【００２３】
管理テーブル４０に同一の通信先・収集先計算機のリソース情報項目が存在しない場合（ステップ１０２；リソース情報項目なし，共用メモリのアドレスなし）、要求された通信先・収集先計算機のリソース情報項目を登録し、新たに共用メモリを確保する（ステップ１０３）。また、同一の通信先・収集先計算機のリソース情報項目があってもその共有メモリのアドレスが存在しない場合（ステップ１０２；リソース情報項目あり，共用メモリのアドレスなし）、共有メモリのブロックを確保する（ステップ１０４）。そして、計算機１ｃ上の情報管理処理ブロック１ｆへ、ＡＰ１ｈから登録されたリソース情報項目の登録要求通知（ステップ１０５）と計算機１ｂ配下の情報収集処理ブロック１ｅへ登録要求通知を行った後（ステップ１０６）、上述したステップ１０７，１０８を行なう。すなわち、図４の管理テーブルの当該通信先・収集先計算機のリソース情報項目のユーザ数を１つ増やし（ステップ１０７）、ＡＰ１ｈに対して、当該項目の登録識別子とリソース情報項目の共有メモリの先頭アドレスを応答する（ステップ１０８）。
これにより、ＡＰは、応答（返送）されてきたアドレスを参照することにより所望のリソース情報を取得することができるようになる。
【００２４】
図８は、ＡＰのリソース情報登録時の他計算機１ｃ上の情報管理処理ブロック１ｆの登録要求通知受信時の処理フローチャートである。
まず、情報管理処理ブロック１ｆはリソース情報項目の登録要求通知（ステップ１０５から）を受信し（ステップ２０１）、図４の管理テーブル４０に当該リソース情報項目の登録の有無の判定を行い（ステップ２０２）、当該リソース情報項目の登録がない場合（ステップ２０２：Ｎ）、リソース情報項目の登録を行い（ステップ２０３）、計算機１ｃ配下の情報収集処理ブロック１ｇに情報項目の登録要求通知を行う（ステップ２０４）。リソース情報項目の登録がある場合（ステップ２０２：Ｙ）、リソース情報項目に対して通知された登録識別子と自情報管理処理ブロック内で管理する（図２）登録識別子が異なるか判定し（ステップ２０５）、その登録識別子が異なる場合（ステップ２０５：Ｎ）、図２の登録識別子の関連付けを行う（ステップ２０６）。そして、図４の管理テーブル４０内の当該登録識別子項目のユーザ数４４を１つ増やす（ステップ２０７）。
【００２５】
図９は、ＡＰのリソース情報登録時の情報収集処理ブロック１ｅもしくは１ｇの登録要求受信時の処理フローチャートである。
まず、リソース情報項目の登録要求通知（ステップ２０５もしくはステップ１０６から）を受信し（ステップ３０１）、情報収集処理ブロックが保持する収集情報通知のためのしきい値判定用の情報収集管理テーブルに登録する。
【００２６】
図５は、情報収集管理テーブル５０の一例である。同図に示すように、しきい値判定用の情報収集管理テーブル５０は、登録識別子５１，リソース情報項目５２，収集の可否５３，１回前の情報値５４，２回前の情報値５５，しきい値５６，しきい値増加量５７，増減率５８から構成される。しきい値５６の値，しきい値の増加量５７の値，および増減率５８の値は初めに設定しておくものとする。
【００２７】
登録識別子５１は、ＡＰがリソース情報項目を登録要求する時、情報管理処理ブロックが付与したものを使用する。すなわち、上記図９のステップ３０１で情報収集処理ブロックが受信する情報管理処理ブロックからのリソース情報項目の登録要求通知（ステップ２０５もしくはステップ１０６から）には、この登録識別子５１の情報も付与される。リソース情報項目５２は、ＡＰから登録された収集するリソース情報項目である。収集の可否５３は、ユーザから登録されたリソース情報項目毎に収集の可否を保持するものである。
【００２８】
情報収集管理テーブル５０に登録後、初回の情報値収集を行い（ステップ３０２）、収集した情報数とそれぞれの情報値を上位の情報管理処理ブロックに応答する（ステップ３０３）。登録後，一定間隔毎にリソース情報項目を収集し、上位の情報管理処理ブロックに通知するための以下の情報を保持する。１回前の情報値５４および２回前の情報値５５には、それぞれ１回前に収集された情報値と２回前に収集された情報値を保持する。しきい値５６は、同一の計算機の情報管理処理ブロック（図１の１ｃであれば１ｄのこと）へ通知するしきい値を示す。情報値の収集毎に図１２の通知判定ロジックを行い、該当する場合、上位の情報管理処理ブロックに通知をする。しきい値の増加量５７（以下増加量と記す）は、しきい値から増加量を足すことでしきい値のリソースレベル分けをして、リソースレベルが変わる毎に情報値の通知を行うとともに、しきい値の値を変えていく。具体的には、後述する例のように、しきい値の初期値が４０％の場合、収集した情報値がしきい値の初期値を超えた場合、上位の情報管理処理ブロックに収集した情報値を通知し、図５のしきい値５６をしきい値５６プラス増加量５７（すなわち５０％＝４０％＋１０％）に変える。同様に、次の情報収集でしきい値を下回った場合、上位の情報管理処理ブロックに収集した情報値を通知し、しきい値５６をしきい値５６マイナス増加量５７（すなわち４０％＝５０％−１０％）に変える。なお、しきい値がしきい値の初期値の場合、しきい値５６マイナス増加量５７をしきい値とせず、しきい値の初期値のままとする。さらに、増減率５８は増加量より小さい値を用い、２回の情報値の差の絶対値との比較により、情報値の通知を判定する際に使用する（その詳細は、図１２において説明する）。
【００２９】
図５の例は、登録識別子５１として“01001”，リソース情報項目５２として“ＣＰＵ使用率”，収集の可否５３として“可能”，１回前の情報値５４として“３０％”，２回前の情報値５５として“２６％”，しきい値５６として“４０％”，しきい値増加量５７として“１０％”，増減率５８として“３％”が登録された場合を示している。
【００３０】
図１０は、ＡＰのリソース情報登録時の他計算機の情報管理処理ブロック１ｆの登録応答フローチャートである。
情報管理処理ブロック１ｆは、情報収集処理ブロック１ｇから登録の応答（ステップ３０３から）を受信し（ステップ４０１）、その情報数と情報値を登録した情報管理処理ブロック１ｄに登録応答する（ステップ４０２）。
【００３１】
図１１は、ＡＰのリソース情報登録時の情報管理処理ブロック１ｄの登録応答フローチャートである。
ＡＰ１ｈからリソース情報項目の登録要求を受けた情報管理処理ブロック１ｄは、リソース情報項目の登録応答（ステップ３０３またはステップ４０２から）を受信し（ステップ５０１）、その情報値を共有メモリに書き込む。ＡＰのリソース情報参照方法は共有メモリを使用し、情報管理処理ブロックが当該項目の情報値を共有メモリに書き込み、登録要求したＡＰがその共有メモリ上の値を参照できるようにする。
【００３２】
図６は、１つのリソース情報項目の登録に対して、複数のリソース情報の値が存在する場合に対処可能とするためのリソース情報値格納の共有メモリチェーン構造の図である。
情報管理処理ブロックは、情報収集処理ブロックもしくは他計算機の情報管理ブロックから１つのリソース情報項目に対し、０以上のリソース情報値の通知を受信する。１つのリソース情報項目に対して、収集されるリソース情報値の名前をラベル名とする。３つの情報値が存在する場合、１つ目の情報を共有メモリのブロック６ａのリソース情報値６ｄ、計算機識別子６ｅ、ラべル名６ｆを格納し、次の情報値の共有メモリのアドレス情報６ｇに共有メモリのブロック６ｂの先頭アドレスを格納する。同様に、２つ目の情報を共有メモリのブロック６ｂの情報値６ｈ、計算機識別子６ｉ、ラべル名６ｊを格納し、次の情報値の共有メモリのアドレスの情報６ｋに共有メモリのブロック６ｃの先頭アドレスを格納する。３つ目の情報を共有メモリのブロック６ｃの情報値６ｌ、計算機識別子６ｍ、ラべル名６ｎを格納し、次の情報値の共有メモリのアドレスの情報６ｏに最後の情報を示す値を格納する。
ＡＰは、これらを順次参照していくことによって、複数の情報値を取得できる。
【００３３】
図１２は、情報収集処理ブロックが収集したリソース情報の情報値の上位の情報管理処理ブロックへの通知処理のフローチャートである。
上位の情報管理処理ブロックへの通知ロジックとして、まず、現在の情報値と１回前の情報値がテーブル５０のしきい値５６としきい値５６プラス増加量５７の間にあるか判定し（ステップ６０１）、異なる場合、１回前の情報値と現在の情報値の差の絶対値と増減率（図５の増減率）の比較を行う（ステップ６０８）。
増減率が小さい場合（１回前の情報値と現在の情報値の差の絶対値の方が大きい場合）、上位の情報管理処理ブロックに通知する（ステップ６０９）。
増減率が大きい場合（１回前の情報値と現在の情報値の差の絶対値の方が小さい場合）、上位の情報管理処理ブロックに通知しない（ステップ６１０）。
【００３４】
現在の情報値と１回前の情報値が同じしきい値としきい値プラス増加量の間の場合（ステップ６０１：Ｙ）、さらに、２回前の情報値がしきい値としきい値プラス増加量の間にあるか判定し（ステップ６０２）、間にある場合（ステップ６０２：Ｙ）、上位の情報管理処理ブロックに情報値を通知しない（ステップ６０３）。
２回前の情報値がしきい値としきい値プラス増加量の間にない場合（ステップ６０２：Ｎ）、次に、２回前の情報値と１回前の情報値の差の絶対値と増減率（図５の増減率）を比較し（ステップ６０５）、増減率が小さい場合（２回前の情報値と１回前の情報値の差の絶対値の方が大きい場合）、既に１回前の時に通知しているため、現在の情報値を通知しない（ステップ６０６）。
増減率の方が大きい場合（２回前の情報値と１回前の情報値の差の絶対値の方が小さい場合）、１回前には通知していないため、現在の情報値を通知する（ステップ６０７）。
【００３５】
情報収集処理ブロックから通知を受けた上位の情報管理処理ブロックは、通知を受けた情報値を登録のある計算機（図４の計算機のユーザ数に該当する計算機）の情報管理処理ブロックに通知をする。
【００３６】
図１３は、ＡＰのリソース情報参照のフローチャートである。
情報管理処理ブロックがＡＰの登録時共用メモリの先頭アドレス（６ａ）をＡＰに渡していた場合、ＡＰはそのアドレスを参照し（ステップ７０１）、情報値６ｄ，計算機識別子６ｅ，ラべル名６ｆ，次の情報値のアドレス６ｇを取得する（ステップ７０２）。次の情報値のアドレス６ｇに書き込まれているのがアドレス情報か最終を示す値かチェックする（ステップ７０３）。今の場合、アドレス情報であるから、アドレス６ｇから共有メモリブロック６ｂを参照し、情報値６ｈと計算機識別子６ｉ、ラべル名６ｊ、次の情報のアドレス６ｋを取得する。同様に、次の情報のアドレス６ｋから共有メモリブロック６ｃの情報値６ｌ、計算機識別子６ｍ、ラべル名６ｎ、次の情報のアドレス６ｏを取得し、次の情報のアドレス６ｏに今度は最終を示すの値が書き込まれているため、その情報のチェーン構造の最後のブロックであることを認識する。
【００３７】
図１４は、ＡＰのリソース情報要求の解除のフローチャートである。
ＡＰは、必要の無くなったリソース情報登録の解除要求を行う。情報管理処理ブロックは、自計算機のＡＰもしくは他計算機の情報管理処理ブロックから登録識別子による登録解除を受信した際（ステップ８０１）、登録解除要求が自計算機のＡＰもしくは他計算機の情報管理処理ブロックかを判定し（ステップ８０２）、自計算機のＡＰの場合、計算機の情報管理処理ブロックへ登録識別子による登録解除要求を通知する（ステップ８０３）。そして、図４の管理テーブル４０の当該登録識別子項目のユーザ数を１つ減らし（ステップ８０４）、当該登録識別子のユーザ数がゼロになった判定する（ステップ８０５）。
【００３８】
判定の結果、ユーザ数が０の場合、情報管理処理ブロックと情報収集処理ブロックの管理テーブルから当該登録識別子のレコードを削除する（ステップ８０６）。
【００３９】
【発明の効果】
以上述べたように、本発明のリソース情報処理方法によれば、分散環境下の各計算機のリソース情報をＡＰに処理負荷を与えることなく収集し監視することが可能になり、また、リソース情報収集によるシステムに与える負荷を最小限におさえているので、あるＡＰが他の計算機上のＡＰと連携処理を行う場合、ＡＰは、連携処理を行なうＡＰが動作する計算機のリソース情報値に応じた処理を実施できる。
【図面の簡単な説明】
【図１】本発明を分散構成システムに適用した構成概略図である。
【図２】本発明における、登録識別子の対応をとる登録識別子対応テーブルを示す図である。
【図３】本発明における、分散構成システム内に一意となる登録識別子のフォーマット例を示す図である。
【図４】本発明における、登録識別子とリソース情報と共有メモリ対応をとるため、情報管理処理ブロックが保持する管理テーブルを示す図である。
【図５】本発明における、情報収集処理ブロックが保持する収集情報通知のためのしきい値判定用収集管理テーブルを示す図である。
【図６】本発明における、１つのリソース情報項目の登録に対して、複数のリソース情報の値が存在する場合に対処可能とするためのリソース情報値格納の共有メモリチェーン構造の図である。
【図７】本発明における、ＡＰのリソース情報登録時の情報管理処理ブロック登録受信フローチャートである。
【図８】本発明における、ＡＰのリソース情報登録時の他計算機の情報管理処理ブロック登録受信フローチャートである。
【図９】本発明における、ＡＰのリソース情報登録時の情報収集処理ブロック登録受信フローチャートである。
【図１０】本発明における、ＡＰのリソース情報登録時の他計算機の情報管理処理ブロック登録応答フローチャートである。
【図１１】本発明における、ＡＰのリソース情報登録時の情報管理処理ブロックの登録応答フローチャートである。
【図１２】本発明における、情報収集処理ブロックが収集したリソース情報の情報値の上位の情報管理処理ブロックへの通知処理のフローチャートである。
【図１３】本発明における、ＡＰのリソース情報参照のフローチャートである。
【図１４】本発明のおける、ＡＰのリソース情報要求の解除のフローチャートである。
【符号の説明】
１ａ：分散処理システム
１ｂ，１ｃ：計算機
１ｄ，１ｆ：情報管理処理ブロック
１ｅ，１ｇ：情報収集処理ブロック
１ｈ，１ｉ，１ｊ，１ｋ，１ｌ，１ｍ：アプリケーション
２ａ，２ｃ，２ｅ：登録識別子
２ｂ，２ｄ，２ｆ：次の情報のアドレス
３ａ：計算機識別子
３ｂ：情報管理処理ブロック内識別子
６ａ：共有メモリブロック

Claims

１つの計算機上で動作するアプリケーション（ＡＰ）が、他の計算機上で動作するＡＰと連携をとりながら処理を行う分散構成システムにおけるリソース情報処理方法であって、
計算機上に配備されるあるＡＰが通信先の計算機のリソース情報を収集するため登録要求した、収集したいリソース情報項目を、当該ＡＰを配備した計算機において登録するステップと、
前記ＡＰを配備した計算機から前記通信先の計算機に対して、前記ＡＰから登録要求され登録したリソース情報項目の登録要求を行うステップと、
当該ＡＰを配備した計算機からのリソース情報項目の登録要求に応じて前記通信先の計算機において、当該リソース情報項目を登録するステップと、
前記リソース情報項目を登録した通信先の計算機において、登録したリソース情報項目の情報値を一定間隔毎に収集し、収集した情報値がある特定のしきい値を超えた場合に当該リソース情報を当該リソース情報項目の登録要求をした前記ＡＰを配備した計算機に通知するステップと、
当該通知されたリソース情報値を要求したＡＰを配備した計算機において、当該ＡＰが、当該リソース情報値を参照するステップと、
ＡＰの要求により、当該ＡＰを配備した計算機および前記通信先の計算機において、当該ＡＰからの登録要求に応じて登録したリソース情報項目を解除するステップからなることを特徴とする分散構成システムにおけるリソース情報処理方法。