JPH07302242A - 負荷分散方式 - Google Patents
負荷分散方式Info
- Publication number
- JPH07302242A JPH07302242A JP6114557A JP11455794A JPH07302242A JP H07302242 A JPH07302242 A JP H07302242A JP 6114557 A JP6114557 A JP 6114557A JP 11455794 A JP11455794 A JP 11455794A JP H07302242 A JPH07302242 A JP H07302242A
- Authority
- JP
- Japan
- Prior art keywords
- business
- load
- processing
- business server
- server
- 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
- Computer And Data Communications (AREA)
Abstract
(57)【要約】
【目的】 ネットワ−ク上に接続されたクライアントと
サ−バの間でトランザクション処理を行うオンライント
ランザクション処理システムにおいて,負荷情報やその
通信量を減らし,トランザクションの処理を効率化,高
速化し,システム全体としての処理効率を向上させる負
荷分散を行うことを目的とする. 【構成】 従来のクライアントサ−バ−モデルのクライ
アントまたはサ−バに付加機能を加えたものから構成さ
れるシステムまたはそのシステムと負荷分散のためのマ
ネ−ジャから構成されるシステム.
サ−バの間でトランザクション処理を行うオンライント
ランザクション処理システムにおいて,負荷情報やその
通信量を減らし,トランザクションの処理を効率化,高
速化し,システム全体としての処理効率を向上させる負
荷分散を行うことを目的とする. 【構成】 従来のクライアントサ−バ−モデルのクライ
アントまたはサ−バに付加機能を加えたものから構成さ
れるシステムまたはそのシステムと負荷分散のためのマ
ネ−ジャから構成されるシステム.
Description
【0001】
【産業上の利用分野】この発明は、ネットワーク上に接
続された業務クライアントと業務サーバの間でトランザ
クション処理を行うオンライントランザクション処理シ
ステムにおける、負荷分散方式に関するものである。
続された業務クライアントと業務サーバの間でトランザ
クション処理を行うオンライントランザクション処理シ
ステムにおける、負荷分散方式に関するものである。
【0002】
【従来の技術】本発明の第1,第2の発明に最も近い公
知例として、特開昭62−279433公報記載の「動
的タスク変更方式」がある。
知例として、特開昭62−279433公報記載の「動
的タスク変更方式」がある。
【0003】従来のオンライントランザクション処理シ
ステムにおいて、負荷の変化を監視し、その変化に計算
機資源の状態を追従させて性能向上を図る方法として
は、図53に示すような方式が提案されている。この図
は特開昭62−279433公報記載の発明の実施例の
ブロック図であり、図において4501はトランザクシ
ョン処理システム、4502は端末、4503はデータ
ベース、4511はトランザクション監視手段、451
2はタスク数変更判定手段、4513はタスク数変更手
段、4514はトランザクション負荷情報格納領域、4
515はタスク数判定テーブル、4516a,4516
b,4516cは例としてのタスクである。トランザク
ション処理管理部4510は、トランザクション監視手
段4511、タスク数変更判定手段4512、タスク数
変更手段4513、トランザクション負荷情報格納領域
4514、タスク数判定テーブル4515から構成され
る。
ステムにおいて、負荷の変化を監視し、その変化に計算
機資源の状態を追従させて性能向上を図る方法として
は、図53に示すような方式が提案されている。この図
は特開昭62−279433公報記載の発明の実施例の
ブロック図であり、図において4501はトランザクシ
ョン処理システム、4502は端末、4503はデータ
ベース、4511はトランザクション監視手段、451
2はタスク数変更判定手段、4513はタスク数変更手
段、4514はトランザクション負荷情報格納領域、4
515はタスク数判定テーブル、4516a,4516
b,4516cは例としてのタスクである。トランザク
ション処理管理部4510は、トランザクション監視手
段4511、タスク数変更判定手段4512、タスク数
変更手段4513、トランザクション負荷情報格納領域
4514、タスク数判定テーブル4515から構成され
る。
【0004】従来の負荷分散方式は、上記のように構成
されているので、トランザクション監視手段4511が
トランザクションの負荷を監視してトランザクション負
荷情報格納領域4514に格納し、タスク数変更判定手
段4512は、その格納された負荷に基づき、必要なタ
スク数をタスク数判定テーブル4515の内容を参照し
て取得し、この取得したタスク数と現在のタスク数との
比較によりタスク数を変更する必要の有無を判定して、
タスク4516a,4516b,4516cの数を増減
する。端末4502から要求のあったトランザクション
を処理する場合には、トランザクション処理管理部45
10が、タスク4516a〜4516cに空きがあるか
どうかを判断し、空きがなければそのトランザクション
を待ち状態とし、空きがあれば空いているタスクにその
トランザクション処理を行うよう指示する。
されているので、トランザクション監視手段4511が
トランザクションの負荷を監視してトランザクション負
荷情報格納領域4514に格納し、タスク数変更判定手
段4512は、その格納された負荷に基づき、必要なタ
スク数をタスク数判定テーブル4515の内容を参照し
て取得し、この取得したタスク数と現在のタスク数との
比較によりタスク数を変更する必要の有無を判定して、
タスク4516a,4516b,4516cの数を増減
する。端末4502から要求のあったトランザクション
を処理する場合には、トランザクション処理管理部45
10が、タスク4516a〜4516cに空きがあるか
どうかを判断し、空きがなければそのトランザクション
を待ち状態とし、空きがあれば空いているタスクにその
トランザクション処理を行うよう指示する。
【0005】本発明の第1,第2の発明に対する従来の
負荷分散方式は、上記のように処理を行うので、入力と
なるトランザクションが増大した場合には、その要求を
複数のタスク、すなわち業務サーバプロセスで処理する
ための振り分け処理が必要となり、その振り分け処理に
よるオーバーヘッドがシステム全体としての処理効率を
低下させるという問題点があった。
負荷分散方式は、上記のように処理を行うので、入力と
なるトランザクションが増大した場合には、その要求を
複数のタスク、すなわち業務サーバプロセスで処理する
ための振り分け処理が必要となり、その振り分け処理に
よるオーバーヘッドがシステム全体としての処理効率を
低下させるという問題点があった。
【0006】入力となるトランザクションの処理が多い
ときにも、その要求を複数の業務サーバプロセスで処理
するための振り分け処理を不要にするための改良された
負荷分散方式が必要である。
ときにも、その要求を複数の業務サーバプロセスで処理
するための振り分け処理を不要にするための改良された
負荷分散方式が必要である。
【0007】本発明の第3,4,5の発明に最も近い公
知例として、日経エレクトロニクス1993.12.2
0、p.143〜154記載の「タスクブローカ」があ
る。
知例として、日経エレクトロニクス1993.12.2
0、p.143〜154記載の「タスクブローカ」があ
る。
【0008】従来の負荷分散方式としては、図54に示
すような方式が提案されている。この図は日経エレクト
ロニクス1993.12.20、p.143〜154記
載の「タスクブローカ」記載の実施例を示す図であり、
図において1はクライアント計算機、2はサーバ計算
機、4605はクライアント計算機1内で、サーバプロ
グラムに処理を要求するクライアントプログラム、46
06はクライアント内で、最適なサーバプログラムを探
索するための手段を提供するタスクブローカ・クライア
ントデーモン、4607〜4609は各サーバ計算機内
でクライアントが要求する処理を提供可能なサーバプロ
グラム、4610〜4612は各サーバ計算機内でサー
バプログラムの負荷などを監視してクライアントプログ
ラムからの要求を受諾できる度合いを評価する処理受諾
度評価部である。
すような方式が提案されている。この図は日経エレクト
ロニクス1993.12.20、p.143〜154記
載の「タスクブローカ」記載の実施例を示す図であり、
図において1はクライアント計算機、2はサーバ計算
機、4605はクライアント計算機1内で、サーバプロ
グラムに処理を要求するクライアントプログラム、46
06はクライアント内で、最適なサーバプログラムを探
索するための手段を提供するタスクブローカ・クライア
ントデーモン、4607〜4609は各サーバ計算機内
でクライアントが要求する処理を提供可能なサーバプロ
グラム、4610〜4612は各サーバ計算機内でサー
バプログラムの負荷などを監視してクライアントプログ
ラムからの要求を受諾できる度合いを評価する処理受諾
度評価部である。
【0009】従来の負荷分散方式は、上記のように構成
されているので、クライアントプログラム4605が処
理要求を行う際に、その要求内容をタスクブローカ・ク
ライアントデーモン4606に提出し、タスクブローカ
・クライアントデーモン4606は各サーバ2a〜2c
に対してその要求内容に対する処理受諾度を評価するよ
う要求する。各サーバ内の処理受諾度評価部4610〜
4612は、計算機の負荷、サーバプログラムに滞留し
ている他のクライアントプログラムからの要求数などに
応じて、要求された処理を受諾できる度合い、すなわち
処理受諾度を評価して、タスクブローカ・クライアント
デーモン4606にその処理受諾度とサーバ計算機のア
ドレスを返す。タスクブローカ・クライアントデーモン
4606は、最も高い処理受諾度を返したサーバを選択
して、そのサーバのアドレスにクライアントプログラム
4605からの処理要求を転送する。
されているので、クライアントプログラム4605が処
理要求を行う際に、その要求内容をタスクブローカ・ク
ライアントデーモン4606に提出し、タスクブローカ
・クライアントデーモン4606は各サーバ2a〜2c
に対してその要求内容に対する処理受諾度を評価するよ
う要求する。各サーバ内の処理受諾度評価部4610〜
4612は、計算機の負荷、サーバプログラムに滞留し
ている他のクライアントプログラムからの要求数などに
応じて、要求された処理を受諾できる度合い、すなわち
処理受諾度を評価して、タスクブローカ・クライアント
デーモン4606にその処理受諾度とサーバ計算機のア
ドレスを返す。タスクブローカ・クライアントデーモン
4606は、最も高い処理受諾度を返したサーバを選択
して、そのサーバのアドレスにクライアントプログラム
4605からの処理要求を転送する。
【0010】本発明の第3,4の発明に対する従来の負
荷分散方式は、上記のように処理を行うので、負荷情報
を収集したり、サーバに処理受諾度を問い合わせるため
の処理のオーバーヘッドがかえってシステム全体として
の処理効率を低下させるという問題点があった。さら
に、サーバの負荷情報はわかるものの、ネットワークの
負荷情報を得る手段がなかったため、結果として最適な
サーバを選択することにつながらないことがあった。
荷分散方式は、上記のように処理を行うので、負荷情報
を収集したり、サーバに処理受諾度を問い合わせるため
の処理のオーバーヘッドがかえってシステム全体として
の処理効率を低下させるという問題点があった。さら
に、サーバの負荷情報はわかるものの、ネットワークの
負荷情報を得る手段がなかったため、結果として最適な
サーバを選択することにつながらないことがあった。
【0011】負荷情報を収集したり、負荷情報を問い合
わせるための処理に関する無駄を抑制するための改良さ
れた負荷分散方式が必要である。
わせるための処理に関する無駄を抑制するための改良さ
れた負荷分散方式が必要である。
【0012】本発明の第5の発明に対する従来の負荷分
散方式は、上記のように処理を行うので、同じ処理を依
頼するクライアントが多数存在した場合にも、それぞれ
のクライアントが同じような問い合わせをサーバに行う
という無駄があった。
散方式は、上記のように処理を行うので、同じ処理を依
頼するクライアントが多数存在した場合にも、それぞれ
のクライアントが同じような問い合わせをサーバに行う
という無駄があった。
【0013】同じ処理を依頼するクライアントが多数存
在した場合にも、それぞれのクライアントが同じような
問い合わせをサーバに行うという無駄を抑制するための
改良された負荷分散方式が必要である。
在した場合にも、それぞれのクライアントが同じような
問い合わせをサーバに行うという無駄を抑制するための
改良された負荷分散方式が必要である。
【0014】本発明の第6および7の発明に関する従来
例として、オンライントランザクション処理システムに
おける従来の負荷分散処理技術では、特開昭58−19
960のような負荷分散システムにおける縮退運転方式
が提案されている。図55はこの方式におけるシステム
構成を示し、図において,4701a,4701bは演
算装置、4702a,4702bは記憶装置である。演
算装置1 4701aには機能Aが、演算装置2 47
01bには機能Bが配置され、更に演算装置14701
aには機能Bの一部機能を有する簡易サーバ機能B’
が、演算装置24701bには機能Aの一部機能を有す
る簡易サーバ機能A’が配置されている。なお,図55
は本発明に係わる部分のみを表示している.
例として、オンライントランザクション処理システムに
おける従来の負荷分散処理技術では、特開昭58−19
960のような負荷分散システムにおける縮退運転方式
が提案されている。図55はこの方式におけるシステム
構成を示し、図において,4701a,4701bは演
算装置、4702a,4702bは記憶装置である。演
算装置1 4701aには機能Aが、演算装置2 47
01bには機能Bが配置され、更に演算装置14701
aには機能Bの一部機能を有する簡易サーバ機能B’
が、演算装置24701bには機能Aの一部機能を有す
る簡易サーバ機能A’が配置されている。なお,図55
は本発明に係わる部分のみを表示している.
【0015】この様な構成で,平常運転時は,演算装置
1 4701aでは機能Aと簡易サ−バ機能B’が動作
する.同様に,演算装置2 4701bでは機能B,サ
−バ機能A’が動作する.何れの場合も,平常運転時は
機能A,Bが処理をするので,簡易サ−バ機能A’,
B’は記憶装置へのアクセスはしない.いま,演算装置
1 4701aがダウンすればシステムは自動的に縮退
運転に入り,演算装置24701bの簡易サ−バ機能
A’がバックアップに入り,記憶装置へのアクセスも行
う.演算装置1 4701a が復旧したら機能Aがそ
の上で動作し平常運転に戻る.逆に,演算装置2 47
01bがダウンした場合は,同じ様に,演算装置1の簡
易サ−バ機能B’がバックアップする縮退運転に入り,
記憶装置へのアクセスも行う.演算装置2 4701b
が復旧したら平常運転に戻る.
1 4701aでは機能Aと簡易サ−バ機能B’が動作
する.同様に,演算装置2 4701bでは機能B,サ
−バ機能A’が動作する.何れの場合も,平常運転時は
機能A,Bが処理をするので,簡易サ−バ機能A’,
B’は記憶装置へのアクセスはしない.いま,演算装置
1 4701aがダウンすればシステムは自動的に縮退
運転に入り,演算装置24701bの簡易サ−バ機能
A’がバックアップに入り,記憶装置へのアクセスも行
う.演算装置1 4701a が復旧したら機能Aがそ
の上で動作し平常運転に戻る.逆に,演算装置2 47
01bがダウンした場合は,同じ様に,演算装置1の簡
易サ−バ機能B’がバックアップする縮退運転に入り,
記憶装置へのアクセスも行う.演算装置2 4701b
が復旧したら平常運転に戻る.
【0016】本発明に対する従来の負荷分散方式は、多
くのマネージメント・サービスから構成され、実行時に
は非常に多くのメモリ領域を必要とする。サーバは、マ
ルチ・クライアント対応で、かつシステム障害時の代替
作業を行うことを考慮し、同機能サーバもしくは簡易サ
ーバを用意している。しかし、これはサーバの過負荷状
態時には、メモリ中のスワップ領域が不足してしまいシ
ステム障害を起こすという問題があった。
くのマネージメント・サービスから構成され、実行時に
は非常に多くのメモリ領域を必要とする。サーバは、マ
ルチ・クライアント対応で、かつシステム障害時の代替
作業を行うことを考慮し、同機能サーバもしくは簡易サ
ーバを用意している。しかし、これはサーバの過負荷状
態時には、メモリ中のスワップ領域が不足してしまいシ
ステム障害を起こすという問題があった。
【0017】システム上のサーバ稼働状況を管理するこ
とにより、ハードウェア・ネックによるシステム障害の
防止と、システムの安定した負荷管理を図る負荷分散方
式が必要である。
とにより、ハードウェア・ネックによるシステム障害の
防止と、システムの安定した負荷管理を図る負荷分散方
式が必要である。
【0018】従来のシステムは、クライアントからの処
理を受け付ける簡易サーバを他のサーバ上に用意するこ
とによって、演算処理装置のいずれかに障害が生じた場
合、障害の起こらない演算装置に配置されている簡易サ
ーバが、障害から復旧するまで処理を代行するという手
段をとっている。しかし、この方法では、障害を未然に
防止するための技術については考慮されていないという
問題がある。
理を受け付ける簡易サーバを他のサーバ上に用意するこ
とによって、演算処理装置のいずれかに障害が生じた場
合、障害の起こらない演算装置に配置されている簡易サ
ーバが、障害から復旧するまで処理を代行するという手
段をとっている。しかし、この方法では、障害を未然に
防止するための技術については考慮されていないという
問題がある。
【0019】処理作業を分担している分散型オンライン
・トランザクション処理システムにおいて、前記のよう
に,ある演算処理装置に障害が発生した場合は、その装
置上で動作していたサーバの簡易サーバを別の装置上に
用意することによって、復旧するまでの一時的な救済処
置は行える。しかし、障害原因によっては復旧に長時間
を要する場合もあり、簡易サーバの処理では業務を継続
して遂行するには問題となる。
・トランザクション処理システムにおいて、前記のよう
に,ある演算処理装置に障害が発生した場合は、その装
置上で動作していたサーバの簡易サーバを別の装置上に
用意することによって、復旧するまでの一時的な救済処
置は行える。しかし、障害原因によっては復旧に長時間
を要する場合もあり、簡易サーバの処理では業務を継続
して遂行するには問題となる。
【0020】サーバの一部機能を有する代行サーバの使
用によって、システム障害の防止とサーバの負荷の軽減
を行い、かつ処理効率を向上することを図る負荷分散方
式が必要である。
用によって、システム障害の防止とサーバの負荷の軽減
を行い、かつ処理効率を向上することを図る負荷分散方
式が必要である。
【0021】本発明の第8の発明に関する従来の負荷分
散方式としては、「特開昭63−75868」や「特開
平2−93836」にあるような方式が提案されてい
る。
散方式としては、「特開昭63−75868」や「特開
平2−93836」にあるような方式が提案されてい
る。
【0022】図56は、従来のこの種の負荷分散方式の
構成を示すもので、業務クライアント1と業務サーバ2
a,2b、負荷監視マネージャ4803が伝送路480
4によって接続されている。業務サーバ2a,2bは、
トランザクション要求と応答を送受信するトランザクシ
ョン要求送受信部4805と、トランザクション要求を
処理するトランザクション処理部4806と、業務サー
バの負荷を検出する負荷検出部4807と、負荷監視マ
ネージャに業務サーバの負荷を報告する負荷報告部48
08を備え、負荷監視マネージャ4803は、業務サー
バ2a,2bから業務サーバの負荷を収集するサーバ負
荷検出部4809と、サーバの負荷情報を基に業務サー
バ2からのトランザクション要求を負荷の少ない業務サ
ーバ2に割り振るトランザクション要求分配部4810
を備えている。
構成を示すもので、業務クライアント1と業務サーバ2
a,2b、負荷監視マネージャ4803が伝送路480
4によって接続されている。業務サーバ2a,2bは、
トランザクション要求と応答を送受信するトランザクシ
ョン要求送受信部4805と、トランザクション要求を
処理するトランザクション処理部4806と、業務サー
バの負荷を検出する負荷検出部4807と、負荷監視マ
ネージャに業務サーバの負荷を報告する負荷報告部48
08を備え、負荷監視マネージャ4803は、業務サー
バ2a,2bから業務サーバの負荷を収集するサーバ負
荷検出部4809と、サーバの負荷情報を基に業務サー
バ2からのトランザクション要求を負荷の少ない業務サ
ーバ2に割り振るトランザクション要求分配部4810
を備えている。
【0023】負荷監視マネージャ4803は、業務クラ
イアント1からのトランザクション要求が特定の業務サ
ーバ2に集中しないように、業務サーバの負荷を監視
し、業務クライアント1からのトランザクション要求を
適切な業務サーバ2に割り振っている。
イアント1からのトランザクション要求が特定の業務サ
ーバ2に集中しないように、業務サーバの負荷を監視
し、業務クライアント1からのトランザクション要求を
適切な業務サーバ2に割り振っている。
【0024】しかし、従来の方式では、一箇所の負荷監
視マネージャ4803にクライアントのトランザクショ
ン要求が集中した場合、負荷監視マネージャ4803の
処理が分散処理システムのボトルネックになるという問
題がある。また、負荷監視マネージャ4803の為に、
ポーリングやイベントによる監視のための通信が必要で
あり、監視トラフィックが増大するという問題点があ
る。
視マネージャ4803にクライアントのトランザクショ
ン要求が集中した場合、負荷監視マネージャ4803の
処理が分散処理システムのボトルネックになるという問
題がある。また、負荷監視マネージャ4803の為に、
ポーリングやイベントによる監視のための通信が必要で
あり、監視トラフィックが増大するという問題点があ
る。
【0025】業務クライアントが、トランザクションを
処理するサーバ候補をトランザクション要求に添付し、
サーバ候補間でトランザクションを一回り回覧し、回覧
リストの最後のサーバが最も負荷の低いサーバにトラン
ザクションの処理を依頼することによって、負荷監視マ
ネージャ4803および負荷監視の為の通信を不要にし
て通信トラフィックの減少を計ることが必要である。
処理するサーバ候補をトランザクション要求に添付し、
サーバ候補間でトランザクションを一回り回覧し、回覧
リストの最後のサーバが最も負荷の低いサーバにトラン
ザクションの処理を依頼することによって、負荷監視マ
ネージャ4803および負荷監視の為の通信を不要にし
て通信トラフィックの減少を計ることが必要である。
【0026】本発明の第9の発明に関する従来の負荷分
散方式としては、「特開平1−267765」にある方
式が提案されている。
散方式としては、「特開平1−267765」にある方
式が提案されている。
【0027】図57は、従来のこの種の負荷分散方式を
示すもので、伝送路上4901に接続される一つのネッ
トワーク管理計算機,負荷監視マネ−ジャ4902と複
数の分散処理計算機,業務サ−バ2a,2b,・・・か
ら構成される。
示すもので、伝送路上4901に接続される一つのネッ
トワーク管理計算機,負荷監視マネ−ジャ4902と複
数の分散処理計算機,業務サ−バ2a,2b,・・・か
ら構成される。
【0028】各分散処理計算機,業務サ−バ2a,2
b,・・・により自己の処理負荷率をモニタリングしつ
つ負荷が設定値,閾値以上となった時にネットワーク管
理計算機,負荷監視マネ−ジャ4902に対して分散処
理要求を発するようにし、これを受ける上記ネットワー
ク管理計算機,負荷監視マネ−ジャ4902はネットワ
ークを介して接続されている負荷の低い他の分散処理計
算機,業務サ−バ2を選択して分散処理命令を発してい
た。
b,・・・により自己の処理負荷率をモニタリングしつ
つ負荷が設定値,閾値以上となった時にネットワーク管
理計算機,負荷監視マネ−ジャ4902に対して分散処
理要求を発するようにし、これを受ける上記ネットワー
ク管理計算機,負荷監視マネ−ジャ4902はネットワ
ークを介して接続されている負荷の低い他の分散処理計
算機,業務サ−バ2を選択して分散処理命令を発してい
た。
【0029】しかし、従来の方法では、分散処理計算
機,業務サ−バ2がその処理負荷の閾値を越えてからネ
ットワーク管理計算機,負荷監視マネ−ジャ4902に
高負荷を報告し処理を他の分散処理計算機,業務サ−バ
2に依頼するため、高負荷になってから処理を他の分散
処理計算機,業務サ−バ2に依頼するまでの間、高負荷
の状態が持続するという問題点がある。
機,業務サ−バ2がその処理負荷の閾値を越えてからネ
ットワーク管理計算機,負荷監視マネ−ジャ4902に
高負荷を報告し処理を他の分散処理計算機,業務サ−バ
2に依頼するため、高負荷になってから処理を他の分散
処理計算機,業務サ−バ2に依頼するまでの間、高負荷
の状態が持続するという問題点がある。
【0030】単位時間当たりの処理負荷の増減傾向を用
い、処理負荷の増加傾向から、一定時間後に閾値を越え
ると予測される場合は、当該分散処理計算機,業務サ−
バ2の負荷が高いと判断し、逆に処理負荷の減少傾向か
ら、一定時間後に閾値内に入ると予想される場合は、当
該分散処理計算機,業務サ−バ2の負荷が通常と判断す
ることによって、複数の分散処理計算機,業務サ−バ2
の処理効率を高めることが必要である。
い、処理負荷の増加傾向から、一定時間後に閾値を越え
ると予測される場合は、当該分散処理計算機,業務サ−
バ2の負荷が高いと判断し、逆に処理負荷の減少傾向か
ら、一定時間後に閾値内に入ると予想される場合は、当
該分散処理計算機,業務サ−バ2の負荷が通常と判断す
ることによって、複数の分散処理計算機,業務サ−バ2
の処理効率を高めることが必要である。
【0031】本発明の第10,11の発明に関する従来
の負荷分散方式としては、「特開平1−267765」
にある方式が提案されている。
の負荷分散方式としては、「特開平1−267765」
にある方式が提案されている。
【0032】図58は、従来のこの種の負荷分散方式の
構成を示すもので、伝送路5001上に接続される一つ
の負荷マネージャ5002と複数の業務サーバ2a,2
b,・・・から構成される。
構成を示すもので、伝送路5001上に接続される一つ
の負荷マネージャ5002と複数の業務サーバ2a,2
b,・・・から構成される。
【0033】負荷監視マネージャ5002は、各業務サ
ーバ2a,2b,・・・に対して一定の時間間隔でポー
リングを行うことによって、或いは業務サーバ2a,2
b,・・・から負荷監視マネージャ5002に負荷増大
の警報を通知することによって、業務サーバ2a,2
b,・・・の負荷を検出していた。
ーバ2a,2b,・・・に対して一定の時間間隔でポー
リングを行うことによって、或いは業務サーバ2a,2
b,・・・から負荷監視マネージャ5002に負荷増大
の警報を通知することによって、業務サーバ2a,2
b,・・・の負荷を検出していた。
【0034】しかし、従来の方法では、負荷監視マネー
ジャから各業務サーバ2a,2b,に対する最適なポー
リング間隔を設定することが難しい上に、管理される業
務サーバが増大した時やポーリング間隔が短い時には、
管理オーバヘッドが増大するという問題点があった。ま
た,この様な技術において発生する問題点に対して,業
務クライアント(図示なし)は負荷監視マネージャ50
02に監視機能を委ね,専ら処理の依頼をするのみであ
り,問題解決に働かなかった.
ジャから各業務サーバ2a,2b,に対する最適なポー
リング間隔を設定することが難しい上に、管理される業
務サーバが増大した時やポーリング間隔が短い時には、
管理オーバヘッドが増大するという問題点があった。ま
た,この様な技術において発生する問題点に対して,業
務クライアント(図示なし)は負荷監視マネージャ50
02に監視機能を委ね,専ら処理の依頼をするのみであ
り,問題解決に働かなかった.
【0035】サーバに対しては、マネージャからポーリ
ングベースでサーバの負荷状況を監視し、クライアント
からマネージャに対して、サーバの処理速度劣化をイベ
ントベースで報告させ、負荷監視をサーバとクライアン
トの両面から行うことによって、レスポンス性能向上な
どサービスの品質を向上し、さらにクライアントとサー
バ間のネットワークの障害も検出することが必要であ
る。
ングベースでサーバの負荷状況を監視し、クライアント
からマネージャに対して、サーバの処理速度劣化をイベ
ントベースで報告させ、負荷監視をサーバとクライアン
トの両面から行うことによって、レスポンス性能向上な
どサービスの品質を向上し、さらにクライアントとサー
バ間のネットワークの障害も検出することが必要であ
る。
【0036】本発明の第12,13の発明に関する従来
の負荷分散方式としては、特開平4−34640号公報
の方法が提案されている。その構成を図59に示す。5
101はマネージャ、2は業務サーバ、1は業務クライ
アントで構成される。業務クライアント1と業務サーバ
2は複数存在することができるが、マネージャ5101
は1つのみ存在する。
の負荷分散方式としては、特開平4−34640号公報
の方法が提案されている。その構成を図59に示す。5
101はマネージャ、2は業務サーバ、1は業務クライ
アントで構成される。業務クライアント1と業務サーバ
2は複数存在することができるが、マネージャ5101
は1つのみ存在する。
【0037】次に動作について説明する。マネージャ5
101は常時、業務サーバ2の負荷情報を収集してい
る。業務クライアント1はどの業務サーバ2に処理を要
求するか決定するためにマネージャ5101にアクセス
する。マネージャ5101は、収集した負荷情報を用い
て業務クライアント1がどの業務サーバ2にアクセスさ
せるかを決定し業務クライアント1に通知する。業務ク
ライアント1は決定した業務サーバ2に処理を要求す
る。業務サ−バ2は処理を行う。
101は常時、業務サーバ2の負荷情報を収集してい
る。業務クライアント1はどの業務サーバ2に処理を要
求するか決定するためにマネージャ5101にアクセス
する。マネージャ5101は、収集した負荷情報を用い
て業務クライアント1がどの業務サーバ2にアクセスさ
せるかを決定し業務クライアント1に通知する。業務ク
ライアント1は決定した業務サーバ2に処理を要求す
る。業務サ−バ2は処理を行う。
【0038】本発明の従来の負荷分散方式は、上記のよ
うに処理を行うので、常に負荷情報を収集しなければな
らないので、マネージャ5101や業務サーバ2に負荷
がかかり、またトラフィック量も大きくなってしまう問
題があった。
うに処理を行うので、常に負荷情報を収集しなければな
らないので、マネージャ5101や業務サーバ2に負荷
がかかり、またトラフィック量も大きくなってしまう問
題があった。
【0039】常に負荷情報を収集しなければならないの
で、マネージャや業務サーバに負荷がかかり、またトラ
フィック量も大きくなってしまう問題があったことは前
記の通りであるが,これに加えて,マネージャは必ずど
れかの業務サーバ名を業務クライアントに返すので、す
べての業務サーバが負荷が高いときも業務サーバを割り
振ってしまう。そのため、すべての業務サーバが高負荷
のためダウンする可能性があるという問題点があった。
で、マネージャや業務サーバに負荷がかかり、またトラ
フィック量も大きくなってしまう問題があったことは前
記の通りであるが,これに加えて,マネージャは必ずど
れかの業務サーバ名を業務クライアントに返すので、す
べての業務サーバが負荷が高いときも業務サーバを割り
振ってしまう。そのため、すべての業務サーバが高負荷
のためダウンする可能性があるという問題点があった。
【0040】従来のものよりマネージャや業務サーバに
負荷とトラフィック量も減らし、負荷を分散することが
必要である。
負荷とトラフィック量も減らし、負荷を分散することが
必要である。
【0041】換言すれば,従来のものよりマネージャや
業務サーバに負荷とトラフィック量も減らすことと、業
務サーバの負荷が高い時業務クライアントの業務サーバ
へのアクセスを減らし負荷分散を行うことが必要であ
る。
業務サーバに負荷とトラフィック量も減らすことと、業
務サーバの負荷が高い時業務クライアントの業務サーバ
へのアクセスを減らし負荷分散を行うことが必要であ
る。
【0042】本発明の第14の発明に関する従来の負荷
分散方式としては、株式会社ソフト・リサーチ・センタ
ー発行の「TCP/IP〜ネットワーク・プロトコルと
インプリメント〜」の129ページに記載されているよ
うに、TCPの帯域外通信が上げられる。この方法は緊
急なデータを通常のソケットの送信待ち行列に入れない
で即座に送信するものである。即ち,送信側ユ−ザが受
信側に緊急に処理して貰いたいデ−タがある場合にTC
Pに対して送信要求を行う際に緊急デ−タであることを
知らせる.送信側TCPはそれを受け取ると,ユ−ザが
指定した緊急デ−タのセグメント内での終了位置を示す
ポインタ(Urgentポインタ)と,緊急情報である
ことを示すUrgent flagをヘッダ内につけて
送信する.受信側TCPはそのセグメントを受信する
と,Urgentポインタで指定されているデ−タを即
座に受信ユ−ザに知らせる.
分散方式としては、株式会社ソフト・リサーチ・センタ
ー発行の「TCP/IP〜ネットワーク・プロトコルと
インプリメント〜」の129ページに記載されているよ
うに、TCPの帯域外通信が上げられる。この方法は緊
急なデータを通常のソケットの送信待ち行列に入れない
で即座に送信するものである。即ち,送信側ユ−ザが受
信側に緊急に処理して貰いたいデ−タがある場合にTC
Pに対して送信要求を行う際に緊急デ−タであることを
知らせる.送信側TCPはそれを受け取ると,ユ−ザが
指定した緊急デ−タのセグメント内での終了位置を示す
ポインタ(Urgentポインタ)と,緊急情報である
ことを示すUrgent flagをヘッダ内につけて
送信する.受信側TCPはそのセグメントを受信する
と,Urgentポインタで指定されているデ−タを即
座に受信ユ−ザに知らせる.
【0043】本発明の第14の発明に関する従来の負荷
分散方式は、上記のように処理を行うので、緊急データ
に複数のランクづけがなされていないため緊急度の度合
いによる送信量の調節ができないという問題点があっ
た。
分散方式は、上記のように処理を行うので、緊急データ
に複数のランクづけがなされていないため緊急度の度合
いによる送信量の調節ができないという問題点があっ
た。
【0044】緊急度に応じてデータを選択でき、緊急度
の高いデータが少ない場合は、より緊急度の低いデータ
さえも出力できることが必要である。
の高いデータが少ない場合は、より緊急度の低いデータ
さえも出力できることが必要である。
【0045】本発明の第15,16,17の発明に関す
る従来の負荷分散方式としては,日経オ−プンシステム
1992年10月創刊前特別1号の64ページから65
ページに掲載されている方法がある。その構成を図60
に示す。1は業務クライアント、2a,2bは業務サー
バ、5203はデータベースである。ただし業務クライ
アント1と業務サーバ2は複数存在することができるが
データベースは一つである。次に動作について説明す
る。業務クライアント1は業務サーバ(2aまたは2
b)にアクセスする。業務サーバ(2aまたは2b)は
データベース5203のデータを使用し業務クライアン
ト1に要求された処理を行う。
る従来の負荷分散方式としては,日経オ−プンシステム
1992年10月創刊前特別1号の64ページから65
ページに掲載されている方法がある。その構成を図60
に示す。1は業務クライアント、2a,2bは業務サー
バ、5203はデータベースである。ただし業務クライ
アント1と業務サーバ2は複数存在することができるが
データベースは一つである。次に動作について説明す
る。業務クライアント1は業務サーバ(2aまたは2
b)にアクセスする。業務サーバ(2aまたは2b)は
データベース5203のデータを使用し業務クライアン
ト1に要求された処理を行う。
【0046】本発明の第15,16,17の発明に関す
る従来の負荷分散方式は、上記のように処理を行うの
で、記憶場所であるたった一つのデータベース5203
にすべての業務サーバ2がアクセスする。そのためデー
タベース5203への通信が集中する問題点があった。
また、データベース5203の性能が悪いと業務サーバ
2の動作が止まってしまい業務サーバ2を有効に負荷分
散できなくなる問題点があった。 このため,従来の
ものより業務サーバの負荷を分散し、トラフィック量も
減らすことが必要である。
る従来の負荷分散方式は、上記のように処理を行うの
で、記憶場所であるたった一つのデータベース5203
にすべての業務サーバ2がアクセスする。そのためデー
タベース5203への通信が集中する問題点があった。
また、データベース5203の性能が悪いと業務サーバ
2の動作が止まってしまい業務サーバ2を有効に負荷分
散できなくなる問題点があった。 このため,従来の
ものより業務サーバの負荷を分散し、トラフィック量も
減らすことが必要である。
【0047】
【発明が解決しようとする課題】従来の技術は以上の様
に構成されているので,トランザクションが多くなると
負荷分散制御,処理の過負荷により,負荷分散システム
に障害が発生するという問題があった.
に構成されているので,トランザクションが多くなると
負荷分散制御,処理の過負荷により,負荷分散システム
に障害が発生するという問題があった.
【0048】本発明はこのような課題を解決するための
ものであり,トランザクションが増大し,負荷分散制
御,処理等の負荷が増大しても負荷分散システムに障害
を及ぼさない負荷分散方式を提供することを目的とす
る.
ものであり,トランザクションが増大し,負荷分散制
御,処理等の負荷が増大しても負荷分散システムに障害
を及ぼさない負荷分散方式を提供することを目的とす
る.
【0049】
【課題を解決するための手段】この発明の第1の発明に
係わる負荷分散方式では,トランザクションの負荷を監
視する負荷監視手段と、該負荷監視手段が監視した結果
を基にして業務サーバプロセスの数を決める業務サーバ
プロセス数変更手段と、該業務サ−バプロセス数変更手
段の該制御に基いて各業務サーバプロセスが処理要求を
受け付けるべき業務クライアントを決定する業務クライ
アント決定手段と、各業務サーバプロセスが処理要求を
受け付ける業務クライアントを管理する業務クライアン
ト管理テーブルとを設けたものである。
係わる負荷分散方式では,トランザクションの負荷を監
視する負荷監視手段と、該負荷監視手段が監視した結果
を基にして業務サーバプロセスの数を決める業務サーバ
プロセス数変更手段と、該業務サ−バプロセス数変更手
段の該制御に基いて各業務サーバプロセスが処理要求を
受け付けるべき業務クライアントを決定する業務クライ
アント決定手段と、各業務サーバプロセスが処理要求を
受け付ける業務クライアントを管理する業務クライアン
ト管理テーブルとを設けたものである。
【0050】この発明の第2の発明に係わる負荷分散方
式では,トランザクションの負荷を監視する負荷監視手
段と、該負荷監視手段が監視した結果を基にして業務サ
ーバプロセスの数を決める業務サーバプロセス数変更手
段と、該業務サ−バプロセス数変更手段の該制御に基い
て各業務サーバプロセスが処理をするデ−タを決定する
管理デ−タ決定手段と、各業務サーバプロセスが処理の
対象とするデ−タを管理するデ−タ管理テーブルとを設
けたものである。
式では,トランザクションの負荷を監視する負荷監視手
段と、該負荷監視手段が監視した結果を基にして業務サ
ーバプロセスの数を決める業務サーバプロセス数変更手
段と、該業務サ−バプロセス数変更手段の該制御に基い
て各業務サーバプロセスが処理をするデ−タを決定する
管理デ−タ決定手段と、各業務サーバプロセスが処理の
対象とするデ−タを管理するデ−タ管理テーブルとを設
けたものである。
【0051】この発明の第3の発明に係わる負荷分散方
式では,業務クライアントの処理依頼の送信から処理結
果の受信までの間の任意の処理の任意の時点の時刻を刻
印する時刻刻印手段と,該時刻刻印手段が打刻した該任
意の処理の内,指定した処理の指定した時点の時刻から
指定した処理の指定時点間の所要時間を算出する所要時
間算出手段と,を備えたものである.
式では,業務クライアントの処理依頼の送信から処理結
果の受信までの間の任意の処理の任意の時点の時刻を刻
印する時刻刻印手段と,該時刻刻印手段が打刻した該任
意の処理の内,指定した処理の指定した時点の時刻から
指定した処理の指定時点間の所要時間を算出する所要時
間算出手段と,を備えたものである.
【0052】この発明の第4の発明に係わる負荷分散方
式では,業務クライアントからの依頼データを業務サ−
バが受信したデータ受信時刻を刻印するデータ受信時刻
刻印手段と、業務サーバプロセスにおいてトランザクシ
ョン処理の開始時刻と該処理終了時刻とを刻印するトラ
ンザクション処理開始終了時刻刻印手段と,該処理結果
を返信した時刻を刻印する返信時刻刻印手段と,業務ク
ライアントが該処理結果を受信した時刻を刻印する処理
結果刻印手段と,これらの任意の時刻から所要時間を算
出する所要時間算出手段を備えたものである。
式では,業務クライアントからの依頼データを業務サ−
バが受信したデータ受信時刻を刻印するデータ受信時刻
刻印手段と、業務サーバプロセスにおいてトランザクシ
ョン処理の開始時刻と該処理終了時刻とを刻印するトラ
ンザクション処理開始終了時刻刻印手段と,該処理結果
を返信した時刻を刻印する返信時刻刻印手段と,業務ク
ライアントが該処理結果を受信した時刻を刻印する処理
結果刻印手段と,これらの任意の時刻から所要時間を算
出する所要時間算出手段を備えたものである。
【0053】この発明の第5の発明に係わる負荷分散方
式では,各業務サーバの処理内容とそのネットワーク上
のアドレスの対応表を保持している名前サーバと、名前
サーバにおいて問い合わせのあった処理を提供している
業務サーバのアドレスを応答として返信するサーバアド
レス応答データ送信手段と、該サーバアドレス応答デ−
タ送信手段において該返信する業務サ−バのアドレスを
複数の業務クライアントに対して放送通信する放送通信
手段と,を備えたものである。
式では,各業務サーバの処理内容とそのネットワーク上
のアドレスの対応表を保持している名前サーバと、名前
サーバにおいて問い合わせのあった処理を提供している
業務サーバのアドレスを応答として返信するサーバアド
レス応答データ送信手段と、該サーバアドレス応答デ−
タ送信手段において該返信する業務サ−バのアドレスを
複数の業務クライアントに対して放送通信する放送通信
手段と,を備えたものである。
【0054】この発明の第6の発明に係わる負荷分散方
式では,業務サ−バは,使用メモリ容量の閾値を保持
し,プロセスのメモリ占有量が閾値を超過したらプロセ
スを退避させて縮退運転に移り,プロセスがメモリを開
放してメモリの占有量が該閾値を下回ったら退避した該
プロセスを復旧させて平常運転に移る制御を行う制御部
を備えるものである。
式では,業務サ−バは,使用メモリ容量の閾値を保持
し,プロセスのメモリ占有量が閾値を超過したらプロセ
スを退避させて縮退運転に移り,プロセスがメモリを開
放してメモリの占有量が該閾値を下回ったら退避した該
プロセスを復旧させて平常運転に移る制御を行う制御部
を備えるものである。
【0055】この発明の第7の発明に係わる負荷分散方
式では,業務サ−バは,負荷の閾値を保持し,トランザ
クションの処理負荷が該閾値を超過したらトランザクシ
ョンを処理していた業務サーバプロセスを退避し,その
処理機能を代行する代行業務サーバプロセスを生成して
縮退運転に移り,業務サ−バプロセスが処理を終了して
実行待ちになり,負荷が該閾値を下回れば,該代行業務
サ−バプロセスを消去して前記の退避した業務サ−バプ
ロセスを復旧する制御を行う制御部を備えるものであ
る.
式では,業務サ−バは,負荷の閾値を保持し,トランザ
クションの処理負荷が該閾値を超過したらトランザクシ
ョンを処理していた業務サーバプロセスを退避し,その
処理機能を代行する代行業務サーバプロセスを生成して
縮退運転に移り,業務サ−バプロセスが処理を終了して
実行待ちになり,負荷が該閾値を下回れば,該代行業務
サ−バプロセスを消去して前記の退避した業務サ−バプ
ロセスを復旧する制御を行う制御部を備えるものであ
る.
【0056】この発明の第8の発明に係わる負荷分散方
式では,トランザクションの処理要求をできる業務サー
バに回覧し要求を処理する業務サ−バを決めるためのト
ランザクション回覧を作成するトランザクション回覧発
生部とトランザクション処理要求にそのトランザクショ
ン回覧を添付して送信するトランザクション要求送受信
部を設けた業務クライアントと、それらのトランザクシ
ョン要求とトランザクション回覧を送受信する送受信部
と自業務サ−バの処理負荷を検出するサーバ負荷検出部
と回覧リストを解析し負荷検出部の処理負荷を回覧リス
トに記入し該送受信部により最も処理負荷の低い業務サ
ーバにトランザクション処理要求を回覧する処理負荷ト
ランザクション回覧手段を設けた業務サ−バと,を備え
るものである。
式では,トランザクションの処理要求をできる業務サー
バに回覧し要求を処理する業務サ−バを決めるためのト
ランザクション回覧を作成するトランザクション回覧発
生部とトランザクション処理要求にそのトランザクショ
ン回覧を添付して送信するトランザクション要求送受信
部を設けた業務クライアントと、それらのトランザクシ
ョン要求とトランザクション回覧を送受信する送受信部
と自業務サ−バの処理負荷を検出するサーバ負荷検出部
と回覧リストを解析し負荷検出部の処理負荷を回覧リス
トに記入し該送受信部により最も処理負荷の低い業務サ
ーバにトランザクション処理要求を回覧する処理負荷ト
ランザクション回覧手段を設けた業務サ−バと,を備え
るものである。
【0057】この発明の第9の発明に係わる負荷分散方
式では,業務サ−バは業務サーバの処理負荷閾値を記憶
する負荷閾値記憶手段と、業務サーバの処理負荷を検出
する処理負荷検出手段と、業務サーバの時系列的な処理
負荷履歴を記憶する負荷履歴記憶手段と、業務サーバの
処理負荷履歴から処理負荷を予測する負荷傾向検出手段
と、負荷傾向検出手段が算出した処理負荷の予測値と負
荷閾値記憶手段に格納された負荷閾値からトランザクシ
ョン要求を当該業務サーバで行うかどうかを判定する業
務判定手段を備えるものである。
式では,業務サ−バは業務サーバの処理負荷閾値を記憶
する負荷閾値記憶手段と、業務サーバの処理負荷を検出
する処理負荷検出手段と、業務サーバの時系列的な処理
負荷履歴を記憶する負荷履歴記憶手段と、業務サーバの
処理負荷履歴から処理負荷を予測する負荷傾向検出手段
と、負荷傾向検出手段が算出した処理負荷の予測値と負
荷閾値記憶手段に格納された負荷閾値からトランザクシ
ョン要求を当該業務サーバで行うかどうかを判定する業
務判定手段を備えるものである。
【0058】この発明の第10の発明に係わる負荷分散
方式では,業務クライアントはトランザクション処理要
求を発行してから処理結果を受信するまでの最大待ち時
間の閾値を記憶するトランザクション処理閾時間記憶手
段と,トランザクション処理要求を発行して処理結果を
受信するまでの経過時間を計測して前記の閾値と比較
し,経過時間が閾値を超過したら任意の指定処理をする
トランザクション処理時間検出手段と,を備えたもので
ある.
方式では,業務クライアントはトランザクション処理要
求を発行してから処理結果を受信するまでの最大待ち時
間の閾値を記憶するトランザクション処理閾時間記憶手
段と,トランザクション処理要求を発行して処理結果を
受信するまでの経過時間を計測して前記の閾値と比較
し,経過時間が閾値を超過したら任意の指定処理をする
トランザクション処理時間検出手段と,を備えたもので
ある.
【0059】この発明の第11の発明に係わる負荷分散
方式では,業務クライアントはトランザクション要求を
発行してから処理結果を受信するまでの最大待ち時間を
閾値として記憶するトランザクション処理閾時間記憶手
段と、トランザクション毎の処理要求発行の時点から処
理結果を受信するまでの経過時間を計測し該経過時間と
前記の閾値との比較を行い、該経過時間が前記の閾値よ
りも大きいときには負荷監視マネージャに警報を発行す
るトランザクション処理時間検出手段とを備えている.
業務サーバは負荷監視マネージャからの負荷の照会を受
信しそれに応答する管理要求送受信手段を備えている.
そして,負荷監視マネージャは、業務クライアントから
の前記の警報または業務サ−バに対して同業務サ−バの
負荷に応じて加減された間隔でなされる前記の負荷の照
会に対する回答などによりトランザクション処理システ
ムの異常部分を検出するクライアント・サーバ統括管理
手段を備えるものである。
方式では,業務クライアントはトランザクション要求を
発行してから処理結果を受信するまでの最大待ち時間を
閾値として記憶するトランザクション処理閾時間記憶手
段と、トランザクション毎の処理要求発行の時点から処
理結果を受信するまでの経過時間を計測し該経過時間と
前記の閾値との比較を行い、該経過時間が前記の閾値よ
りも大きいときには負荷監視マネージャに警報を発行す
るトランザクション処理時間検出手段とを備えている.
業務サーバは負荷監視マネージャからの負荷の照会を受
信しそれに応答する管理要求送受信手段を備えている.
そして,負荷監視マネージャは、業務クライアントから
の前記の警報または業務サ−バに対して同業務サ−バの
負荷に応じて加減された間隔でなされる前記の負荷の照
会に対する回答などによりトランザクション処理システ
ムの異常部分を検出するクライアント・サーバ統括管理
手段を備えるものである。
【0060】この発明の第12の発明に係わる負荷分散
方式では,業務サ−バプロセスは業務サ−バプロセスの
負荷を把握し高負荷になれば該業務サ−バプロセスの作
成をマネ−ジャに要求する負荷監視部と、マネ−ジャか
ら受けた業務サ−バプロセスの条件を満たせば該業務サ
ーバプロセスの自己消去を行う自己消去部とを備えてい
る.マネ−ジャは業務サ−バプロセスを起動するサ−バ
起動部と,業務サ−バプロセスの条件を保存し,業務ク
ライアントまたは該負荷監視部からの要求に基いて業務
サ−バプロセスの条件を付し,サ−バ起動部を介して該
業務サ−バプロセスを起動するサーバ振り分け処理部と
を備えるものである。
方式では,業務サ−バプロセスは業務サ−バプロセスの
負荷を把握し高負荷になれば該業務サ−バプロセスの作
成をマネ−ジャに要求する負荷監視部と、マネ−ジャか
ら受けた業務サ−バプロセスの条件を満たせば該業務サ
ーバプロセスの自己消去を行う自己消去部とを備えてい
る.マネ−ジャは業務サ−バプロセスを起動するサ−バ
起動部と,業務サ−バプロセスの条件を保存し,業務ク
ライアントまたは該負荷監視部からの要求に基いて業務
サ−バプロセスの条件を付し,サ−バ起動部を介して該
業務サ−バプロセスを起動するサーバ振り分け処理部と
を備えるものである。
【0061】この発明の第13の発明に係わる負荷分散
方式では,業務サ−バは業務サーバの負荷状態を知る負
荷監視部と、業務クライアントのアクセス優先順位を制
御する情報と該負荷監視部の情報により業務クライアン
トへアクセス権を付与するアクセス権付与決定部とを備
えるものである。
方式では,業務サ−バは業務サーバの負荷状態を知る負
荷監視部と、業務クライアントのアクセス優先順位を制
御する情報と該負荷監視部の情報により業務クライアン
トへアクセス権を付与するアクセス権付与決定部とを備
えるものである。
【0062】この発明の第14の発明に係わる負荷分散
方式では,データ量制御装置は,データを入力する入力
手段、処理条件の設定変更削除の情報を入出力する管理
情報入出力手段,該管理情報入出力手段の設定した条件
により該入力手段からの入力データの重要度を識別し絶
対出力デ−タと任意出力デ−タに分類する重要度識別手
段、前記の絶対出力デ−タの時間あたりの数をカウント
するカウント手段、前記カウント手段の時間当りの絶対
出力デ−タの数と該管理情報入出力手段の設定条件に基
き前記任意出力データを取捨選択する取捨選択手段、出
力データを出力する出力手段、とを備える。
方式では,データ量制御装置は,データを入力する入力
手段、処理条件の設定変更削除の情報を入出力する管理
情報入出力手段,該管理情報入出力手段の設定した条件
により該入力手段からの入力データの重要度を識別し絶
対出力デ−タと任意出力デ−タに分類する重要度識別手
段、前記の絶対出力デ−タの時間あたりの数をカウント
するカウント手段、前記カウント手段の時間当りの絶対
出力デ−タの数と該管理情報入出力手段の設定条件に基
き前記任意出力データを取捨選択する取捨選択手段、出
力データを出力する出力手段、とを備える。
【0063】この発明の第15の発明に係わる負荷分散
方式では,時刻を取得する時刻取得部と、データを記憶
する記憶部と、他の業務サ−バからのデ−タを該記憶部
に格納し,該時刻取得部の時刻が所定のデ−タ移動時刻
になれば該記憶部のデータを他の業務サ−バに移動する
データ移動処理部と、業務クライアントの要求の処理を
行うクライアント要求処理部とを設けた業務サ−バを備
えるものである。
方式では,時刻を取得する時刻取得部と、データを記憶
する記憶部と、他の業務サ−バからのデ−タを該記憶部
に格納し,該時刻取得部の時刻が所定のデ−タ移動時刻
になれば該記憶部のデータを他の業務サ−バに移動する
データ移動処理部と、業務クライアントの要求の処理を
行うクライアント要求処理部とを設けた業務サ−バを備
えるものである。
【0064】この発明の第16の発明に係わる負荷分散
方式では,業務サ−バは上位業務サ−バと下位業務サ−
バよりなっている.下位業務サ−バは時刻を取得する時
刻取得部と、データを記憶する下位記憶部と、上位業務
サ−バからのデ−タを該下位記憶部に格納し,該時刻取
得部の時刻が上位業務サ−バの指定のデ−タ移動時刻に
なれば該下位記憶部のデータを上部業務サ−バに移動す
るデータ移動処理部と、業務クライアントのデ−タに係
わる要求の処理を行うクライアント要求処理部とを備え
ている.そして,上位業務サ−バはデータを記憶する上
位記憶部、データの移動時刻を指定して該上位記憶部か
ら該下位記憶部への移動処理及び該指定移動時刻になれ
ば該下位記憶部からのデ−タを上位記憶部に保存するデ
ータ移動処理部と、業務クライアントの要求の処理を行
う上部クライアント要求処理部とを備える。
方式では,業務サ−バは上位業務サ−バと下位業務サ−
バよりなっている.下位業務サ−バは時刻を取得する時
刻取得部と、データを記憶する下位記憶部と、上位業務
サ−バからのデ−タを該下位記憶部に格納し,該時刻取
得部の時刻が上位業務サ−バの指定のデ−タ移動時刻に
なれば該下位記憶部のデータを上部業務サ−バに移動す
るデータ移動処理部と、業務クライアントのデ−タに係
わる要求の処理を行うクライアント要求処理部とを備え
ている.そして,上位業務サ−バはデータを記憶する上
位記憶部、データの移動時刻を指定して該上位記憶部か
ら該下位記憶部への移動処理及び該指定移動時刻になれ
ば該下位記憶部からのデ−タを上位記憶部に保存するデ
ータ移動処理部と、業務クライアントの要求の処理を行
う上部クライアント要求処理部とを備える。
【0065】この発明の第17の発明に係わる負荷分散
方式では,業務サ−バは,業務クライアントのデ−タに
係わる処理要求に対して自記憶部のデ−タで対応出来な
いときは,他の業務サ−バのデ−タを使用して該業務ク
ライアントの要求を処理する分散トランザクション処理
を行うクライアント要求処理部を備えるものである.
方式では,業務サ−バは,業務クライアントのデ−タに
係わる処理要求に対して自記憶部のデ−タで対応出来な
いときは,他の業務サ−バのデ−タを使用して該業務ク
ライアントの要求を処理する分散トランザクション処理
を行うクライアント要求処理部を備えるものである.
【0066】
【作用】この発明の第1の発明における負荷分散方式で
は,負荷監視手段はトランザクション負荷を監視し、負
荷の大小により業務サーバプロセス数変更手段は業務サ
ーバプロセスの数を決める.該業務サ−バプロセス数変
更手段の決めたプロセスの数に基いて,業務クライアン
ト決定手段は各業務サーバプロセスが処理要求を受け付
けるべき業務クライアントを決定し,それらを管理する
業務クライアント管理テーブルに保存する。
は,負荷監視手段はトランザクション負荷を監視し、負
荷の大小により業務サーバプロセス数変更手段は業務サ
ーバプロセスの数を決める.該業務サ−バプロセス数変
更手段の決めたプロセスの数に基いて,業務クライアン
ト決定手段は各業務サーバプロセスが処理要求を受け付
けるべき業務クライアントを決定し,それらを管理する
業務クライアント管理テーブルに保存する。
【0067】この発明の第2の発明における負荷分散方
式では,負荷監視手段はトランザクション負荷を監視
し、負荷の大小により業務サーバプロセス数変更手段は
業務サーバプロセスの数を決める.該業務サ−バプロセ
ス数変更手段の決めたプロセスの数に基いて,管理デ−
タ決定手段は各業務サーバプロセスが処理の対象とする
デ−タを決定し,それらを管理するデ−タ管理テーブル
に保存する。
式では,負荷監視手段はトランザクション負荷を監視
し、負荷の大小により業務サーバプロセス数変更手段は
業務サーバプロセスの数を決める.該業務サ−バプロセ
ス数変更手段の決めたプロセスの数に基いて,管理デ−
タ決定手段は各業務サーバプロセスが処理の対象とする
デ−タを決定し,それらを管理するデ−タ管理テーブル
に保存する。
【0068】本発明の第3の発明においては、時刻刻印
手段は業務クライアントの処理依頼の送信から処理結果
の受信までの間の任意の処理の任意の時点の時刻を刻印
し,所要時間算出手段は該時刻刻印手段が打刻した該任
意の処理の内,指定した処理の指定した時点から指定し
た処理の指定時点間の所要時間を算出する.
手段は業務クライアントの処理依頼の送信から処理結果
の受信までの間の任意の処理の任意の時点の時刻を刻印
し,所要時間算出手段は該時刻刻印手段が打刻した該任
意の処理の内,指定した処理の指定した時点から指定し
た処理の指定時点間の所要時間を算出する.
【0069】本発明の第4の発明においては、データ受
信時刻刻印手段は業務クライアントからの依頼データを
業務サ−バが受信したデータ受信時刻を刻印し、トラン
ザクション処理開始終了時刻刻印手段は業務サーバプロ
セスのトランザクション処理の開始時刻と該処理終了時
刻とを刻印し,返信時刻刻印手段は該処理結果を返信し
た時刻を刻印し,処理結果刻印手段は業務クライアント
が該処理結果を受信した時刻を刻印し,所要時間算出手
段はこれらの任意の時刻から指定の所要時間を算出す
る。
信時刻刻印手段は業務クライアントからの依頼データを
業務サ−バが受信したデータ受信時刻を刻印し、トラン
ザクション処理開始終了時刻刻印手段は業務サーバプロ
セスのトランザクション処理の開始時刻と該処理終了時
刻とを刻印し,返信時刻刻印手段は該処理結果を返信し
た時刻を刻印し,処理結果刻印手段は業務クライアント
が該処理結果を受信した時刻を刻印し,所要時間算出手
段はこれらの任意の時刻から指定の所要時間を算出す
る。
【0070】本発明の第5の発明において、名前サーバ
は各業務サーバの処理内容とそのネットワーク上のアド
レスの対応表を保持している.名前サーバにおいて問い
合わせのあった処理を提供している業務サーバのアドレ
スをサーバアドレス応答データ送信手段は応答として返
信するが、放送通信手段はこのとき,その返信する業務
サ−バのアドレスを複数の業務クライアントに対して放
送通信する.
は各業務サーバの処理内容とそのネットワーク上のアド
レスの対応表を保持している.名前サーバにおいて問い
合わせのあった処理を提供している業務サーバのアドレ
スをサーバアドレス応答データ送信手段は応答として返
信するが、放送通信手段はこのとき,その返信する業務
サ−バのアドレスを複数の業務クライアントに対して放
送通信する.
【0071】この発明の第6の発明において,業務サ−
バの制御部は,使用メモリ容量の閾値を保持し,プロセ
スのメモリ占有量が閾値を超過したらプロセスを退避さ
せて縮退運転に移り,プロセスがメモリを開放してメモ
リの占有量が該閾値を下回ったら退避した該プロセスを
復旧させて平常運転に移る制御を行う。
バの制御部は,使用メモリ容量の閾値を保持し,プロセ
スのメモリ占有量が閾値を超過したらプロセスを退避さ
せて縮退運転に移り,プロセスがメモリを開放してメモ
リの占有量が該閾値を下回ったら退避した該プロセスを
復旧させて平常運転に移る制御を行う。
【0072】本発明の第7の発明においては、業務サ−
バの制御部は,負荷の閾値を保持し,トランザクション
の処理負荷が該閾値を超過したらトランザクションを処
理していた業務サーバプロセスを退避し,その処理機能
を代行する代行業務サーバプロセスを生成して縮退運転
に移り,業務サ−バプロセスが処理を終了して実行待ち
になり,負荷が該閾値を下回れば,該代行業務サ−バプ
ロセスを消去して前記の退避した業務サ−バプロセスを
復旧する制御を行う.
バの制御部は,負荷の閾値を保持し,トランザクション
の処理負荷が該閾値を超過したらトランザクションを処
理していた業務サーバプロセスを退避し,その処理機能
を代行する代行業務サーバプロセスを生成して縮退運転
に移り,業務サ−バプロセスが処理を終了して実行待ち
になり,負荷が該閾値を下回れば,該代行業務サ−バプ
ロセスを消去して前記の退避した業務サ−バプロセスを
復旧する制御を行う.
【0073】本発明の第8の発明においては、業務クラ
イアントでは,トランザクション回覧発生部はトランザ
クションの処理要求をできる業務サーバに回覧し要求を
処理する業務サ−バを決めるためのトランザクション回
覧を作成し,トランザクション要求送受信部はトランザ
クション処理要求にそのトランザクション回覧を添付し
て送信する.一方,業務サ−バでは,送受信部はそれら
のトランザクション要求とトランザクション回覧を送受
信し,負荷検出部は自業務サーバの処理負荷を検出し,
処理負荷トランザクション回覧手段は回覧リストを解析
し自業務サーバの負荷検出部の処理負荷を回覧リストに
記入し該送受信部により最も処理負荷の低い業務サーバ
にトランザクション処理要求を回覧する。
イアントでは,トランザクション回覧発生部はトランザ
クションの処理要求をできる業務サーバに回覧し要求を
処理する業務サ−バを決めるためのトランザクション回
覧を作成し,トランザクション要求送受信部はトランザ
クション処理要求にそのトランザクション回覧を添付し
て送信する.一方,業務サ−バでは,送受信部はそれら
のトランザクション要求とトランザクション回覧を送受
信し,負荷検出部は自業務サーバの処理負荷を検出し,
処理負荷トランザクション回覧手段は回覧リストを解析
し自業務サーバの負荷検出部の処理負荷を回覧リストに
記入し該送受信部により最も処理負荷の低い業務サーバ
にトランザクション処理要求を回覧する。
【0074】本発明の第9の発明においては、業務サ−
バでは,負荷閾値記憶手段は業務サーバの処理負荷閾値
を記憶し,処理負荷検出手段は業務サ−バの処理負荷を
検出し、負荷履歴記憶手段は処理負荷検出手段から負荷
を得て時系列的な同処理負荷履歴を記憶し、負荷傾向検
出手段は業務サーバの処理負荷履歴から処理負荷傾向を
検出し予測値を算出する.そして,業務判定手段は負荷
傾向検出手段が算出した処理負荷の予測値と負荷閾値記
憶手段に格納された負荷閾値との比較により発生したト
ランザクション要求を当該業務サーバで行うかどうかを
判定する。
バでは,負荷閾値記憶手段は業務サーバの処理負荷閾値
を記憶し,処理負荷検出手段は業務サ−バの処理負荷を
検出し、負荷履歴記憶手段は処理負荷検出手段から負荷
を得て時系列的な同処理負荷履歴を記憶し、負荷傾向検
出手段は業務サーバの処理負荷履歴から処理負荷傾向を
検出し予測値を算出する.そして,業務判定手段は負荷
傾向検出手段が算出した処理負荷の予測値と負荷閾値記
憶手段に格納された負荷閾値との比較により発生したト
ランザクション要求を当該業務サーバで行うかどうかを
判定する。
【0075】本発明の第10の発明においては,業務ク
ライアントでは,トランザクション処理閾時間記憶手段
はトランザクション処理要求を発行してから処理結果を
受信するまでの最大待ち時間の閾値を記憶し,トランザ
クション処理時間検出手段はトランザクション処理要求
を発行して処理結果を受信するまでの経過時間を計測し
て前記の閾値と比較し,閾値を超過したら任意の指定処
理をする.
ライアントでは,トランザクション処理閾時間記憶手段
はトランザクション処理要求を発行してから処理結果を
受信するまでの最大待ち時間の閾値を記憶し,トランザ
クション処理時間検出手段はトランザクション処理要求
を発行して処理結果を受信するまでの経過時間を計測し
て前記の閾値と比較し,閾値を超過したら任意の指定処
理をする.
【0076】本発明の第11の発明においては、業務ク
ライアントでは,トランザクション処理閾時間記憶手段
はトランザクション要求を発行してから処理結果を受信
するまでの最大待ち時間を閾値として記憶る.そして,
トランザクション処理時間検出手段はトランザクション
毎の処理要求発行の時点から処理結果を受信するまでの
経過時間を計測しており,その経過時間と前記の閾値と
の比較を行い、該経過時間が前記の閾値を超過したとき
には負荷監視マネージャに警報を発行する.一方,業務
サーバでは,管理要求送受信手段は負荷監視マネージャ
からの負荷の照会を受信しそれに応答する.そして,負
荷監視マネージャでは、クライアント・サーバ統括管理
手段は業務サ−バに対して同業務サ−バの負荷に応じて
加減した間隔でなされる前記の負荷の照会に対する回答
あるいは業務クライアントからの前記の警報などにより
トランザクション処理システムの異常部分を検出する.
ライアントでは,トランザクション処理閾時間記憶手段
はトランザクション要求を発行してから処理結果を受信
するまでの最大待ち時間を閾値として記憶る.そして,
トランザクション処理時間検出手段はトランザクション
毎の処理要求発行の時点から処理結果を受信するまでの
経過時間を計測しており,その経過時間と前記の閾値と
の比較を行い、該経過時間が前記の閾値を超過したとき
には負荷監視マネージャに警報を発行する.一方,業務
サーバでは,管理要求送受信手段は負荷監視マネージャ
からの負荷の照会を受信しそれに応答する.そして,負
荷監視マネージャでは、クライアント・サーバ統括管理
手段は業務サ−バに対して同業務サ−バの負荷に応じて
加減した間隔でなされる前記の負荷の照会に対する回答
あるいは業務クライアントからの前記の警報などにより
トランザクション処理システムの異常部分を検出する.
【0077】この発明の第12の発明においては,業務
サ−バプロセスでは負荷監視部は業務サ−バプロセスの
負荷を把握し高負荷になれば該業務サ−バプロセスの作
成をマネ−ジャに要求し、自己消去部はマネ−ジャから
受けた業務サ−バプロセスの条件を満たせば該業務サー
バプロセスの自己消去を行う.マネ−ジャではサ−バ起
動部は業務サ−バプロセスを起動し,サーバ振り分け処
理部は業務サ−バプロセスの条件を保存し,業務クライ
アントまたは該負荷監視部からの要求に基いて業務サ−
バプロセスの条件を付し,サ−バ起動部を介して該業務
サ−バプロセスを起動する。
サ−バプロセスでは負荷監視部は業務サ−バプロセスの
負荷を把握し高負荷になれば該業務サ−バプロセスの作
成をマネ−ジャに要求し、自己消去部はマネ−ジャから
受けた業務サ−バプロセスの条件を満たせば該業務サー
バプロセスの自己消去を行う.マネ−ジャではサ−バ起
動部は業務サ−バプロセスを起動し,サーバ振り分け処
理部は業務サ−バプロセスの条件を保存し,業務クライ
アントまたは該負荷監視部からの要求に基いて業務サ−
バプロセスの条件を付し,サ−バ起動部を介して該業務
サ−バプロセスを起動する。
【0078】この発明の第13の発明においては,業務
サ−バでは負荷監視部は業務サーバの負荷状態を知り、
アクセス権付与決定部は業務クライアントのアクセス優
先順位を制御する情報と該負荷監視部の情報により業務
クライアントへアクセス権を付与する。
サ−バでは負荷監視部は業務サーバの負荷状態を知り、
アクセス権付与決定部は業務クライアントのアクセス優
先順位を制御する情報と該負荷監視部の情報により業務
クライアントへアクセス権を付与する。
【0079】この発明の第14の発明においては,デー
タ量制御装置は次ぎの各手段を備える.即ち,入力手段
はデータを入力し、重要度識別手段は管理情報入出力手
段の設定した条件により該入力手段からの入力データの
重要度を識別し絶対出力デ−タと任意出力デ−タに分類
し、カウント手段は前記の絶対出力デ−タの時間あたり
の数をカウントする.そして,取捨選択手段は前記カウ
ント手段の時間当りの絶対出力デ−タの数と該管理情報
入出力手段の設定条件に基き前記の重要度識別手段の出
力した任意出力データを取捨選択し、出力手段は取捨選
択手段が選択した出力データを出力する。
タ量制御装置は次ぎの各手段を備える.即ち,入力手段
はデータを入力し、重要度識別手段は管理情報入出力手
段の設定した条件により該入力手段からの入力データの
重要度を識別し絶対出力デ−タと任意出力デ−タに分類
し、カウント手段は前記の絶対出力デ−タの時間あたり
の数をカウントする.そして,取捨選択手段は前記カウ
ント手段の時間当りの絶対出力デ−タの数と該管理情報
入出力手段の設定条件に基き前記の重要度識別手段の出
力した任意出力データを取捨選択し、出力手段は取捨選
択手段が選択した出力データを出力する。
【0080】この発明の第15の発明においては,業務
サ−バでは,時刻取得部は時刻を取得し、記憶部はデー
タを記憶し、データ移動処理部は他の業務サ−バからの
デ−タを該記憶部に格納し,該時刻取得部の時刻が所定
のデ−タ移動時刻になれば該記憶部のデータを他の業務
サ−バに移動し、クライアント要求処理部は業務クライ
アントの要求の処理を行う。
サ−バでは,時刻取得部は時刻を取得し、記憶部はデー
タを記憶し、データ移動処理部は他の業務サ−バからの
デ−タを該記憶部に格納し,該時刻取得部の時刻が所定
のデ−タ移動時刻になれば該記憶部のデータを他の業務
サ−バに移動し、クライアント要求処理部は業務クライ
アントの要求の処理を行う。
【0081】この発明の第16の発明においては,業務
サ−バは上位業務サ−バと下位業務サ−バよりなってい
る.下位業務サ−バでは,時刻取得部は時刻を取得し、
下位記憶部はデータを記憶し、データ移動処理部は上位
業務サ−バからのデ−タを下位記憶部に格納し,該時刻
取得部の時刻が上位業務サ−バの指定のデ−タ移動時刻
になれば該下位記憶部のデータを上部業務サ−バに移動
し、クライアント要求処理部は業務クライアントの要求
の処理を行う.そして,上位業務サ−バでは,上位記憶
部はデータを記憶し、データ移動処理部は該データ移動
時刻を指定して該上位記憶部から該下位記憶部への移動
処理及び該指定移動時刻になれば該下位記憶部からのデ
−タを上位記憶部に保存し、クライアント要求処理部は
業務クライアントの要求の処理を行う.
サ−バは上位業務サ−バと下位業務サ−バよりなってい
る.下位業務サ−バでは,時刻取得部は時刻を取得し、
下位記憶部はデータを記憶し、データ移動処理部は上位
業務サ−バからのデ−タを下位記憶部に格納し,該時刻
取得部の時刻が上位業務サ−バの指定のデ−タ移動時刻
になれば該下位記憶部のデータを上部業務サ−バに移動
し、クライアント要求処理部は業務クライアントの要求
の処理を行う.そして,上位業務サ−バでは,上位記憶
部はデータを記憶し、データ移動処理部は該データ移動
時刻を指定して該上位記憶部から該下位記憶部への移動
処理及び該指定移動時刻になれば該下位記憶部からのデ
−タを上位記憶部に保存し、クライアント要求処理部は
業務クライアントの要求の処理を行う.
【0082】この発明の第17の発明においては,業務
サ−バでは,クライアント要求処理部は業務クライアン
トのデ−タに係わる処理要求に対して自記憶部のデ−タ
で対応出来ないときは,他の業務サ−バの記憶部のデ−
タを使用して該業務クライアントの要求を処理する分散
トランザクション処理を行うものである.
サ−バでは,クライアント要求処理部は業務クライアン
トのデ−タに係わる処理要求に対して自記憶部のデ−タ
で対応出来ないときは,他の業務サ−バの記憶部のデ−
タを使用して該業務クライアントの要求を処理する分散
トランザクション処理を行うものである.
【0083】
実施例1.本発明の第1の発明の1実施例である実施例
1について図1〜4を参照して説明する.図1は本発明
の第1の発明により、各業務サーバプロセスが、処理要
求を受け付ける業務クライアントを分担することによ
り、システム全体としての処理効率を向上させることが
できることを示す実施例のブロック図を示したものであ
る。図1において、1はトランザクション処理を要求す
る計算機としての業務クライアント,2〜3は業務クラ
イアントから要求された処理を行う計算機としての業務
サーバ、9〜10は各業務サーバ2,3上で同じ内容の
トランザクション処理を実行する業務サーバプロセス、
11は業務サーバプロセス9と業務サーバプロセス10
の負荷を監視する負荷監視手段、12は負荷監視手段1
1による監視結果に基づいて業務サーバプロセス数の設
定,変更等を制御する業務サーバプロセス数変更手段、
13は各業務サーバプロセスが要求を受け付けるべき業
務クライアント1を決定する業務クライアント決定手
段、14〜15は各業務サーバプロセスが要求を受け付
けるべき業務クライアント1を管理する業務クライアン
ト管理テーブル、16は負荷監視手段11と業務サーバ
プロセス数変更手段12と業務クライアント決定手段1
3を実現するトランザクション処理管理部である。
1について図1〜4を参照して説明する.図1は本発明
の第1の発明により、各業務サーバプロセスが、処理要
求を受け付ける業務クライアントを分担することによ
り、システム全体としての処理効率を向上させることが
できることを示す実施例のブロック図を示したものであ
る。図1において、1はトランザクション処理を要求す
る計算機としての業務クライアント,2〜3は業務クラ
イアントから要求された処理を行う計算機としての業務
サーバ、9〜10は各業務サーバ2,3上で同じ内容の
トランザクション処理を実行する業務サーバプロセス、
11は業務サーバプロセス9と業務サーバプロセス10
の負荷を監視する負荷監視手段、12は負荷監視手段1
1による監視結果に基づいて業務サーバプロセス数の設
定,変更等を制御する業務サーバプロセス数変更手段、
13は各業務サーバプロセスが要求を受け付けるべき業
務クライアント1を決定する業務クライアント決定手
段、14〜15は各業務サーバプロセスが要求を受け付
けるべき業務クライアント1を管理する業務クライアン
ト管理テーブル、16は負荷監視手段11と業務サーバ
プロセス数変更手段12と業務クライアント決定手段1
3を実現するトランザクション処理管理部である。
【0084】図2、図3および図4は本発明の第1の発
明の同実施例の動作を説明するための図であり、図2は
負荷増大前の状態を表す図、図3は負荷増大後の状態を
表す図である.図1と同一符号は同一または相当の部分
である.なお,業務クライアント管理テ−ブル14,1
5内にアドレス表示の業務クライアント1〜6は業務ク
ライアント1a〜1fに対応している.図4はトランザ
クション処理管理部の処理例を示す流れ図である。
明の同実施例の動作を説明するための図であり、図2は
負荷増大前の状態を表す図、図3は負荷増大後の状態を
表す図である.図1と同一符号は同一または相当の部分
である.なお,業務クライアント管理テ−ブル14,1
5内にアドレス表示の業務クライアント1〜6は業務ク
ライアント1a〜1fに対応している.図4はトランザ
クション処理管理部の処理例を示す流れ図である。
【0085】なお,本実施例のトランザクション処理と
はネットワーク上に接続された単数または複数の業務ク
ライアントと単数または複数の業務サーバの間でトラン
ザクション処理を行うオンライントランザクション処理
システムを指す.このことは他の実施例でも同様であ
る.
はネットワーク上に接続された単数または複数の業務ク
ライアントと単数または複数の業務サーバの間でトラン
ザクション処理を行うオンライントランザクション処理
システムを指す.このことは他の実施例でも同様であ
る.
【0086】次に動作を図2,3,4を用いて説明す
る。図2は負荷増大前の状態を示した図である。業務サ
ーバ7は、業務クライアント1a〜1fからの処理要求
を受け付け、業務サーバプロセス9にて要求されたトラ
ンザクションを実行する。業務サーバプロセス9の業務
クライアント管理テーブル14には、業務クライアント
1a〜1fの計算機アドレスが格納されている。
る。図2は負荷増大前の状態を示した図である。業務サ
ーバ7は、業務クライアント1a〜1fからの処理要求
を受け付け、業務サーバプロセス9にて要求されたトラ
ンザクションを実行する。業務サーバプロセス9の業務
クライアント管理テーブル14には、業務クライアント
1a〜1fの計算機アドレスが格納されている。
【0087】図4は負荷増大時或は減少時のトランザク
ション処理管理部16の処理の流れの例を示した図であ
る。負荷監視手段11は、定期的に業務クライアント1
でのトランザクション発生比率情報を収集するなどし
て、トランザクションの負荷情報を収集する(ステップ
401)。負荷が高まり、負荷監視手段11にて負荷が
一定以上になったと検知すると(ステップ402)、業
務サ−バ数変更手段12はその負荷より必要な業務サー
バプロセス数を判定する(ステップ403)。その数
が、存在する業務サーバプロセス数より多い場合は、業
務サーバプロセス数変更手段12が、新たな業務サーバ
プロセス10を起動する(ステップ404)。同時に業
務クライアント決定手段13が、各業務サーバプロセス
が処理を受け付けるべき業務クライアントを決定する
(ステップ405)。例えば、業務サーバプロセス9が
業務クライアント1a〜1cからの処理要求を、業務サ
ーバプロセス10が業務クライアント1d〜1fからの
処理要求を受け付けるとすると、業務サーバプロセス9
の業務クライアント管理テーブル14には、業務クライ
アント1a〜1cの計算機アドレスが、業務サーバプロ
セス10の業務クライアントテーブル15には、業務ク
ライアント1d〜1fの計算機アドレスが、格納される
ことになる。図3は、負荷増大に伴い,これらの制御結
果の状態を示す図である。
ション処理管理部16の処理の流れの例を示した図であ
る。負荷監視手段11は、定期的に業務クライアント1
でのトランザクション発生比率情報を収集するなどし
て、トランザクションの負荷情報を収集する(ステップ
401)。負荷が高まり、負荷監視手段11にて負荷が
一定以上になったと検知すると(ステップ402)、業
務サ−バ数変更手段12はその負荷より必要な業務サー
バプロセス数を判定する(ステップ403)。その数
が、存在する業務サーバプロセス数より多い場合は、業
務サーバプロセス数変更手段12が、新たな業務サーバ
プロセス10を起動する(ステップ404)。同時に業
務クライアント決定手段13が、各業務サーバプロセス
が処理を受け付けるべき業務クライアントを決定する
(ステップ405)。例えば、業務サーバプロセス9が
業務クライアント1a〜1cからの処理要求を、業務サ
ーバプロセス10が業務クライアント1d〜1fからの
処理要求を受け付けるとすると、業務サーバプロセス9
の業務クライアント管理テーブル14には、業務クライ
アント1a〜1cの計算機アドレスが、業務サーバプロ
セス10の業務クライアントテーブル15には、業務ク
ライアント1d〜1fの計算機アドレスが、格納される
ことになる。図3は、負荷増大に伴い,これらの制御結
果の状態を示す図である。
【0088】負荷が増大して、業務サーバプロセス間で
業務クライアント1の再分担を行ったとしても業務クラ
イアント1d〜1fはそれを知らないので、再分担後こ
れらの業務クライアント1d〜1fからの最初のアクセ
スは、前に分担の業務サーバプロセス9に処理を要求す
ることがある。そのような場合には、業務サーバプロセ
ス9からの応答として、業務サーバプロセス10が処理
を要求すべき新たな業務サーバプロセスであることを業
務クライアント管理テ−ブル14から判断・指示し、以
降業務サーバプロセス10に処理要求を発行させること
になる。
業務クライアント1の再分担を行ったとしても業務クラ
イアント1d〜1fはそれを知らないので、再分担後こ
れらの業務クライアント1d〜1fからの最初のアクセ
スは、前に分担の業務サーバプロセス9に処理を要求す
ることがある。そのような場合には、業務サーバプロセ
ス9からの応答として、業務サーバプロセス10が処理
を要求すべき新たな業務サーバプロセスであることを業
務クライアント管理テ−ブル14から判断・指示し、以
降業務サーバプロセス10に処理要求を発行させること
になる。
【0089】次ぎに、負荷監視手段11にて負荷が一定
以下になったと検知されると、業務サーバプロセス数変
更手段12が業務サーバプロセス10を消去し(ステッ
プ406)、同時に業務クライアント決定手段13が、
各業務サーバプロセスが処理を受け付けるべき業務クラ
イアント1を再決定する(ステップ407)。例えば、
業務サーバプロセス9が業務クライアント1a〜1fか
らの処理要求を受け付けるとすると、業務クライアント
決定手段13により業務サーバプロセス9の業務クライ
アント管理テーブル14には、図2に示す様に業務クラ
イアント1a〜1fの計算機アドレスが格納されること
になる。
以下になったと検知されると、業務サーバプロセス数変
更手段12が業務サーバプロセス10を消去し(ステッ
プ406)、同時に業務クライアント決定手段13が、
各業務サーバプロセスが処理を受け付けるべき業務クラ
イアント1を再決定する(ステップ407)。例えば、
業務サーバプロセス9が業務クライアント1a〜1fか
らの処理要求を受け付けるとすると、業務クライアント
決定手段13により業務サーバプロセス9の業務クライ
アント管理テーブル14には、図2に示す様に業務クラ
イアント1a〜1fの計算機アドレスが格納されること
になる。
【0090】このように、業務サーバプロセス間で、処
理要求を受け付ける業務クライアント1を分担すること
が可能となる.これらの制御は各トランザクション処理
要求毎に割り振りをするのではなく,トランザクション
の負荷が所定の範囲外になった時にのみ業務サ−バプロ
ッセスの生成/消去,クライアンの分担調整を行うの
で,負荷に比例してオ−バヘッド増が発生することもな
く,結果として全体の処理効率が向上し,負荷の増加に
よるトランザクション処理システムへの障害も抑制され
る.
理要求を受け付ける業務クライアント1を分担すること
が可能となる.これらの制御は各トランザクション処理
要求毎に割り振りをするのではなく,トランザクション
の負荷が所定の範囲外になった時にのみ業務サ−バプロ
ッセスの生成/消去,クライアンの分担調整を行うの
で,負荷に比例してオ−バヘッド増が発生することもな
く,結果として全体の処理効率が向上し,負荷の増加に
よるトランザクション処理システムへの障害も抑制され
る.
【0091】上記の業務クライアント1の分担処理にお
いて、業務クライアント管理テーブルに格納されていた
のは、業務クライアント1の計算機アドレスであった
が、業務を実行する利用者名を格納してもよい。
いて、業務クライアント管理テーブルに格納されていた
のは、業務クライアント1の計算機アドレスであった
が、業務を実行する利用者名を格納してもよい。
【0092】また,上記のトランザクション分担におい
て、業務サーバプロセス毎に負荷監視手段11と業務プ
ロセス数変更手段12と業務クライアント決定手段13
を持ち、業務サーバプロセス9,10のレベルで負荷に
応じて、さらに子としての業務サーバプロセス10を生
成して、それまでその業務プロセス9,10のそれぞれ
業務クライアント管理テーブル14,15に格納されて
いた業務クライアント1の一部を子の業務サーバプロセ
スの業務クライアント管理テーブルに格納させて、それ
らの業務クライアント1からの処理要求を受け付けさせ
てもよい。
て、業務サーバプロセス毎に負荷監視手段11と業務プ
ロセス数変更手段12と業務クライアント決定手段13
を持ち、業務サーバプロセス9,10のレベルで負荷に
応じて、さらに子としての業務サーバプロセス10を生
成して、それまでその業務プロセス9,10のそれぞれ
業務クライアント管理テーブル14,15に格納されて
いた業務クライアント1の一部を子の業務サーバプロセ
スの業務クライアント管理テーブルに格納させて、それ
らの業務クライアント1からの処理要求を受け付けさせ
てもよい。
【0093】以上のように第1の発明によれば、オンラ
イントランザクション処理における業務サーバプロセス
を、絶えず変化するトランザクションの付加に応じて変
化させ、さらに処理依頼を受け付ける業務クライアント
1をそれらの間で分担・統合するので、業務サーバプロ
セス間でのトランザクションの振り分け処理を行うこと
なく、トランザクションの応答性を保証し、トランザク
ション処理負荷の増大に伴うシステムへの障害を回避出
来,かつ,システム資源の有効性を図ることができる効
果がある。また,本発明の第1の発明は,これから説明
する第2以後の発明と組み合せて実施出来るものはそう
して,更なる効果を実現させてもよい.このことは,第
2以後の発明につても同様であることはいうまでもな
い.
イントランザクション処理における業務サーバプロセス
を、絶えず変化するトランザクションの付加に応じて変
化させ、さらに処理依頼を受け付ける業務クライアント
1をそれらの間で分担・統合するので、業務サーバプロ
セス間でのトランザクションの振り分け処理を行うこと
なく、トランザクションの応答性を保証し、トランザク
ション処理負荷の増大に伴うシステムへの障害を回避出
来,かつ,システム資源の有効性を図ることができる効
果がある。また,本発明の第1の発明は,これから説明
する第2以後の発明と組み合せて実施出来るものはそう
して,更なる効果を実現させてもよい.このことは,第
2以後の発明につても同様であることはいうまでもな
い.
【0094】実施例2.前記の実施例1は、各業務サー
バプロセスで要求を受け付ける業務クライアント1を分
担する本発明の第1の発明の実施例であったが、実施例
2は本発明の第2の発明により、各業務サーバプロセス
が扱うデータを分担することにより、システム全体とし
ての処理効率を向上させることができる実施例である.
バプロセスで要求を受け付ける業務クライアント1を分
担する本発明の第1の発明の実施例であったが、実施例
2は本発明の第2の発明により、各業務サーバプロセス
が扱うデータを分担することにより、システム全体とし
ての処理効率を向上させることができる実施例である.
【0095】以下,本発明の第2の発明の1実施例であ
る実施例2を図5〜8を参照して説明する.図5は本実
施例の構成を示すブロック図である。図5において、図
1〜3と同一又は相当の部分は同一符号を付し,説明を
したのでこれらの説明は省略する.図6、図7および図
8は第2の発明による同実施例の動作を説明するための
図であり、図6は負荷増大前の状態を表す図、図7は負
荷増大後の状態を表す図である.図6のデ−タ管理テ−
ブル14内に示すデ−タ(Alan〜Mark)は業務
クライアント1a〜1fからアクセスされる可能性のあ
るデ−タである.図7でも同様である.図8はトランザ
クション処理管理部の処理例を示す流れ図である。
る実施例2を図5〜8を参照して説明する.図5は本実
施例の構成を示すブロック図である。図5において、図
1〜3と同一又は相当の部分は同一符号を付し,説明を
したのでこれらの説明は省略する.図6、図7および図
8は第2の発明による同実施例の動作を説明するための
図であり、図6は負荷増大前の状態を表す図、図7は負
荷増大後の状態を表す図である.図6のデ−タ管理テ−
ブル14内に示すデ−タ(Alan〜Mark)は業務
クライアント1a〜1fからアクセスされる可能性のあ
るデ−タである.図7でも同様である.図8はトランザ
クション処理管理部の処理例を示す流れ図である。
【0096】次に上記実施例2の動作を図6〜7を用い
て説明する。図6は負荷増大前の状態を示した図であ
る。業務サーバ2は、業務クライアント1a〜1fから
の処理要求を受け付け、業務サーバプロセス9にて要求
されたトランザクションを実行する。業務サーバプロセ
ス2は、業務クライアント1a〜1fからの処理要求を
受け付け、扱うデータとしてAで始まるデータからMで
始まるデータまでを管理しており、そのデータ管理テー
ブル14には、扱うデータの一覧が格納されている。
て説明する。図6は負荷増大前の状態を示した図であ
る。業務サーバ2は、業務クライアント1a〜1fから
の処理要求を受け付け、業務サーバプロセス9にて要求
されたトランザクションを実行する。業務サーバプロセ
ス2は、業務クライアント1a〜1fからの処理要求を
受け付け、扱うデータとしてAで始まるデータからMで
始まるデータまでを管理しており、そのデータ管理テー
ブル14には、扱うデータの一覧が格納されている。
【0097】図8は負荷増大時のトランザクション処理
管理部16の処理の流れの例を示した図である。負荷監
視手段11は、定期的に業務クライアント1でのトラン
ザクション発生比率情報を収集するなどして、トランザ
クションの負荷情報を収集する(ステップ801)。負
荷が高まり、負荷監視手段11にて負荷が一定以上にな
ったと検知すると(ステップ802)、業務サ−バプロ
セス数変更手段12はその負荷より必要な業務サーバプ
ロセス数を判定する(ステップ803)。その数が、存
在する業務サーバプロセス数より多い場合は、業務サー
バプロセス変更手段12が、新たな業務サーバプロセス
10を起動する(ステップ804)。同時に管理テーブ
ル決定手段13が、各業務サーバプロセスが扱うべきデ
ータを決定する(ステップ805)。例えば、業務サー
バプロセス9がAで始まるデータからHで始まるデータ
までを、業務サーバプロセス10がIで始まるデータか
らMで始まるデータまでを扱うとすると、業務サーバプ
ロセス9のデータ管理テーブル14にはAで始まるデー
タからHで始まるデータの一覧が、業務サーバプロセス
10のデータ管理テーブル15にはIで始まるデータか
らMで始まるデータまでの一覧が、格納されることにな
る。図7は、負荷増大に伴うこれらの処理結果の状態を
示す図である。
管理部16の処理の流れの例を示した図である。負荷監
視手段11は、定期的に業務クライアント1でのトラン
ザクション発生比率情報を収集するなどして、トランザ
クションの負荷情報を収集する(ステップ801)。負
荷が高まり、負荷監視手段11にて負荷が一定以上にな
ったと検知すると(ステップ802)、業務サ−バプロ
セス数変更手段12はその負荷より必要な業務サーバプ
ロセス数を判定する(ステップ803)。その数が、存
在する業務サーバプロセス数より多い場合は、業務サー
バプロセス変更手段12が、新たな業務サーバプロセス
10を起動する(ステップ804)。同時に管理テーブ
ル決定手段13が、各業務サーバプロセスが扱うべきデ
ータを決定する(ステップ805)。例えば、業務サー
バプロセス9がAで始まるデータからHで始まるデータ
までを、業務サーバプロセス10がIで始まるデータか
らMで始まるデータまでを扱うとすると、業務サーバプ
ロセス9のデータ管理テーブル14にはAで始まるデー
タからHで始まるデータの一覧が、業務サーバプロセス
10のデータ管理テーブル15にはIで始まるデータか
らMで始まるデータまでの一覧が、格納されることにな
る。図7は、負荷増大に伴うこれらの処理結果の状態を
示す図である。
【0098】負荷が増大して、業務サーバプロセス間で
扱うデータの再分担を行ったとしても業務クライアント
1はそれを知らないので、業務クライアント1からMで
始まるデータに関する処理に関する1回目の要求は、業
務サーバプロセス9に要求されることになる。そのよう
な場合には、業務サーバプロセス9からの応答として、
業務サーバプロセス10が処理を要求すべき新たな業務
サーバプロセスであることを業務クライアント管理テ−
ブル14から判断・指示し、以降業務サーバプロセス1
0に処理要求を発行させることになる。
扱うデータの再分担を行ったとしても業務クライアント
1はそれを知らないので、業務クライアント1からMで
始まるデータに関する処理に関する1回目の要求は、業
務サーバプロセス9に要求されることになる。そのよう
な場合には、業務サーバプロセス9からの応答として、
業務サーバプロセス10が処理を要求すべき新たな業務
サーバプロセスであることを業務クライアント管理テ−
ブル14から判断・指示し、以降業務サーバプロセス1
0に処理要求を発行させることになる。
【0099】負荷監視手段11にて負荷が一定以下にな
ったと検知されると、業務サーバプロセス数変更手段1
2が業務サーバプロセス10を消去し(ステップ80
6)、同時に管理データ決定手段13が、各業務サーバ
プロセスが扱うべきデータを再決定する(ステップ80
7)。例えば、業務サーバプロセス9がAで始まるデー
タからMで始まるデータまでを管理するとすると、図6
に示すように業務サーバプロセス9のデータ管理テーブ
ル14には、Aで始まるデータからMで始まるデータの
一覧が格納されることになる。
ったと検知されると、業務サーバプロセス数変更手段1
2が業務サーバプロセス10を消去し(ステップ80
6)、同時に管理データ決定手段13が、各業務サーバ
プロセスが扱うべきデータを再決定する(ステップ80
7)。例えば、業務サーバプロセス9がAで始まるデー
タからMで始まるデータまでを管理するとすると、図6
に示すように業務サーバプロセス9のデータ管理テーブ
ル14には、Aで始まるデータからMで始まるデータの
一覧が格納されることになる。
【0100】このように、業務サーバプロセス間で、処
理要求を受け付ける扱うデータを分担することが可能と
なる.これらの制御は個々のトランザクション要求毎に
するのではなく,トランザクションの負荷が所定の範囲
外になった時にのみ業務サ−バプロセスの生成/消去,
扱うデ−タの分担調整を行うので,不要なオ−バヘッド
が発生することもなく,結果として全体の処理効率が向
上し,負荷の増加によるトランザクション処理システム
の障害も抑制される.
理要求を受け付ける扱うデータを分担することが可能と
なる.これらの制御は個々のトランザクション要求毎に
するのではなく,トランザクションの負荷が所定の範囲
外になった時にのみ業務サ−バプロセスの生成/消去,
扱うデ−タの分担調整を行うので,不要なオ−バヘッド
が発生することもなく,結果として全体の処理効率が向
上し,負荷の増加によるトランザクション処理システム
の障害も抑制される.
【0101】本実施例2において、業務サーバプロセス
毎に負荷監視手段と業務サ−バプロセス数変更手段12
と管理データ決定手段13を持ち、業務サーバプロセス
のレベルで負荷に応じて、さらに子としての業務サーバ
プロセスを生成して、それまでその業務プロセスのデー
タ管理テーブルに格納されていたデータの一覧の一部を
子の業務サーバプロセスのデータ管理テーブルに格納さ
せて、それらのデータに関する処理要求を受け付けさせ
てもよい。
毎に負荷監視手段と業務サ−バプロセス数変更手段12
と管理データ決定手段13を持ち、業務サーバプロセス
のレベルで負荷に応じて、さらに子としての業務サーバ
プロセスを生成して、それまでその業務プロセスのデー
タ管理テーブルに格納されていたデータの一覧の一部を
子の業務サーバプロセスのデータ管理テーブルに格納さ
せて、それらのデータに関する処理要求を受け付けさせ
てもよい。
【0102】以上のように第2の発明によれば、オンラ
イントランザクション処理における業務サーバプロセス
を、絶えず変化するトランザクションの付加に応じて変
化させ、さらに処理の対象となるデータをそれらの間で
分担・統合するので、業務サーバプロセス間でのトラン
ザクションの振り分け処理を行うことなく、トランザク
ションの応答性を保証し、かつ、システム資源の有効利
用を図ることができる効果がある。
イントランザクション処理における業務サーバプロセス
を、絶えず変化するトランザクションの付加に応じて変
化させ、さらに処理の対象となるデータをそれらの間で
分担・統合するので、業務サーバプロセス間でのトラン
ザクションの振り分け処理を行うことなく、トランザク
ションの応答性を保証し、かつ、システム資源の有効利
用を図ることができる効果がある。
【0103】実施例3.実施例2は、各業務サーバプロ
セスで扱うデータを分担する第2の発明の実施例であっ
たが、本実施例3は第3,4の発明により、業務クライ
アントが業務サーバおよびネットワークの負荷を予測
し,負荷分散する例である.以下,図9〜10を用いて
実施例3を説明する.
セスで扱うデータを分担する第2の発明の実施例であっ
たが、本実施例3は第3,4の発明により、業務クライ
アントが業務サーバおよびネットワークの負荷を予測
し,負荷分散する例である.以下,図9〜10を用いて
実施例3を説明する.
【0104】図9は実施例3の構成を示すブロック図で
ある。図9において、1はトランザクション処理の要求
を発行する計算機としての業務クライアントである.な
お,業務クライアント1は図示していないが,後記の時
刻管理手段903と同様の手段をもっている.2は業務
クライアント1から要求されたトランザクションを実行
する計算機としての業務サーバ、903は現在の時刻を
保持する時刻管理手段、904は業務クライアントから
依頼されたデータを受信する処理依頼データ受信手段、
905は処理依頼データ受信手段904においてデータ
にデータ受信時刻情報を付加することにより、データ受
信時刻を刻印するデータ受信時刻刻印手段、906は実
際にクライアントから要求されたトランザクションを実
行する業務サーバプロセス、907は業務サーバプロセ
ス906においてトランザクション処理の開始時刻と終
了時刻に関する情報を付加することにより、トランザク
ション処理の開始時刻と終了時刻とを刻印するトランザ
クション処理開始/終了時刻刻印手段、908はデータ
ベースにアクセスするなどして実際のトランザクション
処理を行うトランザクション処理実行部、909は処理
結果を業務クライアント1に返信する処理結果データ送
信手段である。910は業務サ−バ−2の記憶装置であ
る.図10は本発明の動作を説明するための図である。
ある。図9において、1はトランザクション処理の要求
を発行する計算機としての業務クライアントである.な
お,業務クライアント1は図示していないが,後記の時
刻管理手段903と同様の手段をもっている.2は業務
クライアント1から要求されたトランザクションを実行
する計算機としての業務サーバ、903は現在の時刻を
保持する時刻管理手段、904は業務クライアントから
依頼されたデータを受信する処理依頼データ受信手段、
905は処理依頼データ受信手段904においてデータ
にデータ受信時刻情報を付加することにより、データ受
信時刻を刻印するデータ受信時刻刻印手段、906は実
際にクライアントから要求されたトランザクションを実
行する業務サーバプロセス、907は業務サーバプロセ
ス906においてトランザクション処理の開始時刻と終
了時刻に関する情報を付加することにより、トランザク
ション処理の開始時刻と終了時刻とを刻印するトランザ
クション処理開始/終了時刻刻印手段、908はデータ
ベースにアクセスするなどして実際のトランザクション
処理を行うトランザクション処理実行部、909は処理
結果を業務クライアント1に返信する処理結果データ送
信手段である。910は業務サ−バ−2の記憶装置であ
る.図10は本発明の動作を説明するための図である。
【0105】次に動作を図10により説明する。処理依
頼データ受信手段904が業務クライアント1からの処
理要求データを受信すると、データ受信時刻刻印手段9
05がその時点での時刻t1を時刻管理手段903から
取得し、処理要求データにデータ受信時刻t1を含む情
報を付加する。処理を実行すべき業務サーバプロセス9
06が決定され、処理要求データに関するトランザクシ
ョン処理を開始する時点で、トランザクション処理開始
/終了時刻刻印手段907が、その時点での時刻t2を
時刻管理手段903から取得し、処理要求データにトラ
ンザクション処理開始時刻t2を含む情報を付加する。
処理を実行した業務サーバプロセス906において、処
理要求データに関するトランザクション処理が完了した
時点で、再びトランザクション処理開始/終了時刻刻印
手段907が、その時点での時刻t3を時刻管理手段9
03から取得し、データ受信時刻t1、トランザクショ
ン処理開始時刻t2および処理結果を含む応答データ
に、トランザクション処理終了時刻t3を含む情報を付
加する。結果として、データ受信時刻t1を含む情報と
トランザクション処理開始時刻t2を含む情報とトラン
ザクション処理終了時刻t3を含む情報が付加された応
答データが、処理結果データ送信手段909から、業務
クライアント1に送信されることになる。
頼データ受信手段904が業務クライアント1からの処
理要求データを受信すると、データ受信時刻刻印手段9
05がその時点での時刻t1を時刻管理手段903から
取得し、処理要求データにデータ受信時刻t1を含む情
報を付加する。処理を実行すべき業務サーバプロセス9
06が決定され、処理要求データに関するトランザクシ
ョン処理を開始する時点で、トランザクション処理開始
/終了時刻刻印手段907が、その時点での時刻t2を
時刻管理手段903から取得し、処理要求データにトラ
ンザクション処理開始時刻t2を含む情報を付加する。
処理を実行した業務サーバプロセス906において、処
理要求データに関するトランザクション処理が完了した
時点で、再びトランザクション処理開始/終了時刻刻印
手段907が、その時点での時刻t3を時刻管理手段9
03から取得し、データ受信時刻t1、トランザクショ
ン処理開始時刻t2および処理結果を含む応答データ
に、トランザクション処理終了時刻t3を含む情報を付
加する。結果として、データ受信時刻t1を含む情報と
トランザクション処理開始時刻t2を含む情報とトラン
ザクション処理終了時刻t3を含む情報が付加された応
答データが、処理結果データ送信手段909から、業務
クライアント1に送信されることになる。
【0106】処理の結果を受信した業務クライアント1
は、処理結果を受信した時刻と、業務サーバでのトラン
ザクション処理終了時刻t3の差分から、処理結果の転
送時間911を知ることができ、ネットワーク負荷を予
測することができる。また、データ受信時刻t1とトラ
ンザクション処理開始時刻t2の差分から、業務サーバ
2における処理受け付けから処理開始までの時間912
を知ることができ、この時間912は業務サーバ2の負
荷に比例するので,その負荷予測に利用することができ
る。
は、処理結果を受信した時刻と、業務サーバでのトラン
ザクション処理終了時刻t3の差分から、処理結果の転
送時間911を知ることができ、ネットワーク負荷を予
測することができる。また、データ受信時刻t1とトラ
ンザクション処理開始時刻t2の差分から、業務サーバ
2における処理受け付けから処理開始までの時間912
を知ることができ、この時間912は業務サーバ2の負
荷に比例するので,その負荷予測に利用することができ
る。
【0107】業務クライアント1においては、このよう
な負荷の予測を各業務サーバ2に対して行っておくこと
により、同じ要求を実行可能な業務サーバ2の中から実
際に要求を行う業務サーバ2を選択する際に最も負荷の
軽い業務サーバ2を選択することが可能となる。また、
予測したネットワークの負荷から、ネットワーク経由で
他の業務サーバ2に処理を依頼するか、業務クライアン
ト1と同じ計算機内の業務サーバプロセスに処理を依頼
するか(デ−タへの時刻刻印に業務サ−バプロセス名を
併記)の選択の際の参考情報とすることができる。この
ようにして,トランザクションの負荷が増大し,トラン
ザクション処理システムの障害発生を抑制することが出
来る.
な負荷の予測を各業務サーバ2に対して行っておくこと
により、同じ要求を実行可能な業務サーバ2の中から実
際に要求を行う業務サーバ2を選択する際に最も負荷の
軽い業務サーバ2を選択することが可能となる。また、
予測したネットワークの負荷から、ネットワーク経由で
他の業務サーバ2に処理を依頼するか、業務クライアン
ト1と同じ計算機内の業務サーバプロセスに処理を依頼
するか(デ−タへの時刻刻印に業務サ−バプロセス名を
併記)の選択の際の参考情報とすることができる。この
ようにして,トランザクションの負荷が増大し,トラン
ザクション処理システムの障害発生を抑制することが出
来る.
【0108】本実施例において、処理結果を返信するす
べてのデータにデータ受信時刻t1、トランザクション
処理開始時刻t2、トランザクション処理終了時刻t3
という時刻情報を含めていたが、それをいくつかの処理
結果返信データのうちの一つに入れるという方法を採っ
てもよい。また、業務クライアント1から送られた処理
要求データにデータ受信時刻t1、トランザクション処
理開始時刻t2を付加するのではなく、それらをテーブ
ルに蓄積しておいて、応答データ作成の時にそのテーブ
ルを参照することにより付加してもよい。
べてのデータにデータ受信時刻t1、トランザクション
処理開始時刻t2、トランザクション処理終了時刻t3
という時刻情報を含めていたが、それをいくつかの処理
結果返信データのうちの一つに入れるという方法を採っ
てもよい。また、業務クライアント1から送られた処理
要求データにデータ受信時刻t1、トランザクション処
理開始時刻t2を付加するのではなく、それらをテーブ
ルに蓄積しておいて、応答データ作成の時にそのテーブ
ルを参照することにより付加してもよい。
【0109】本実施例の刻印する処理の時刻例として,
処理要求受信t1,要求トランザクション処理開始t
2,要求トランザクション処理終了t3について説明し
たが,これらに限定されることはない.これ以外に任意
に選んだ処理(例えば,デ−タベ−スへのアクセス要求
時刻,アクセス結果の取得時刻など)の時刻デ−タを収
集し,処理或は待ちなどの時間を計算して必要な時間情
報を得,業務サ−バ2,ネットワ−クなどの処理,待ち
時間などを多角的,詳細に,分析,予測できることはい
うまでもない.例えば,処理待ち,処理時間などについ
てトランザクション処理負荷の大小,処理内容,ネット
ワ−ク構成,ピ−ク時期等の相関分析などが容易にな
り,システムの分析評価も容易になる.
処理要求受信t1,要求トランザクション処理開始t
2,要求トランザクション処理終了t3について説明し
たが,これらに限定されることはない.これ以外に任意
に選んだ処理(例えば,デ−タベ−スへのアクセス要求
時刻,アクセス結果の取得時刻など)の時刻デ−タを収
集し,処理或は待ちなどの時間を計算して必要な時間情
報を得,業務サ−バ2,ネットワ−クなどの処理,待ち
時間などを多角的,詳細に,分析,予測できることはい
うまでもない.例えば,処理待ち,処理時間などについ
てトランザクション処理負荷の大小,処理内容,ネット
ワ−ク構成,ピ−ク時期等の相関分析などが容易にな
り,システムの分析評価も容易になる.
【0110】以上のように第3,4の発明によれば、負
荷収集のための処理,或は通信トラフイックなどのオ−
バヘッドによる処理効率低下を招くことなく、しかも業
務クライアント1がネットワークの負荷と業務サーバプ
ロセスの負荷を知ることができるため、業務クライアン
ト1が最適な業務プロセスを選択することが可能とな
り、システム資源の有効性を図りつつ、システム全体の
処理効率向上を図る。
荷収集のための処理,或は通信トラフイックなどのオ−
バヘッドによる処理効率低下を招くことなく、しかも業
務クライアント1がネットワークの負荷と業務サーバプ
ロセスの負荷を知ることができるため、業務クライアン
ト1が最適な業務プロセスを選択することが可能とな
り、システム資源の有効性を図りつつ、システム全体の
処理効率向上を図る。
【0111】実施例4.実施例3は、業務サーバ2と業
務クライアント1間で交換されるデータに様々な時刻情
報を含ませることにより、最適なサーバ選択を可能にす
ることを示す第3,4の発明の実施例であったが、本実
施例4は第5の発明により、サーバからの応答を全クラ
イアントで共有することを示す例である.以下,実施例
4を図11〜12を参照して説明する.
務クライアント1間で交換されるデータに様々な時刻情
報を含ませることにより、最適なサーバ選択を可能にす
ることを示す第3,4の発明の実施例であったが、本実
施例4は第5の発明により、サーバからの応答を全クラ
イアントで共有することを示す例である.以下,実施例
4を図11〜12を参照して説明する.
【0112】図11は本発明の構成例を示すブロック図
である。 図11において、1はトランザクション処理
の要求を行う業務クライアント、2は業務クライアント
から要求にしたがってトランザクション処理を行う業務
サーバ、4は各業務サーバの処理内容とそのネットワー
ク上のアドレスの対応表を保持してその対応を業務クラ
イアント1に教える名前サーバ、1104は名前サーバ
4において保持されている各業務サーバの処理内容とそ
のネットワーク上のアドレスの対応表、1105は名前
サーバ4において問い合わせのあった処理を提供してい
る業務サーバ2のアドレスを応答として返信するサーバ
アドレス応答データ送信手段、1106はサーバアドレ
ス応答送信手段1105において送信すべきデータを業
務クライアント1aを含む複数の業務クライアント1に
対して放送通信する放送通信手段である。図12は本発
明による実施例の動作を説明するための図である。
である。 図11において、1はトランザクション処理
の要求を行う業務クライアント、2は業務クライアント
から要求にしたがってトランザクション処理を行う業務
サーバ、4は各業務サーバの処理内容とそのネットワー
ク上のアドレスの対応表を保持してその対応を業務クラ
イアント1に教える名前サーバ、1104は名前サーバ
4において保持されている各業務サーバの処理内容とそ
のネットワーク上のアドレスの対応表、1105は名前
サーバ4において問い合わせのあった処理を提供してい
る業務サーバ2のアドレスを応答として返信するサーバ
アドレス応答データ送信手段、1106はサーバアドレ
ス応答送信手段1105において送信すべきデータを業
務クライアント1aを含む複数の業務クライアント1に
対して放送通信する放送通信手段である。図12は本発
明による実施例の動作を説明するための図である。
【0113】次に本実施例の動作を図12,図11に基
づいて説明する。業務サーバ2は、業務サーバプロセス
A1201にて在庫データ更新処理という処理を提供し
ており、名前サーバ4がその処理内容と業務サーバ2の
ネットワーク上のアドレスの対応表1104を保持して
いる。名前サーバ4は、業務クライアント1aからの在
庫データ更新処理という処理を提供しているサーバアド
レスの問い合わせ1202を受けると、業務サーバ2の
アドレスを応答データ1203として、サーバアドレス
応答データ送信手段1105にその送信を要求する。そ
の際、サーバアドレス応答送信手段1105は、放送通
信手段1106を利用して応答データ1203を送信す
る。
づいて説明する。業務サーバ2は、業務サーバプロセス
A1201にて在庫データ更新処理という処理を提供し
ており、名前サーバ4がその処理内容と業務サーバ2の
ネットワーク上のアドレスの対応表1104を保持して
いる。名前サーバ4は、業務クライアント1aからの在
庫データ更新処理という処理を提供しているサーバアド
レスの問い合わせ1202を受けると、業務サーバ2の
アドレスを応答データ1203として、サーバアドレス
応答データ送信手段1105にその送信を要求する。そ
の際、サーバアドレス応答送信手段1105は、放送通
信手段1106を利用して応答データ1203を送信す
る。
【0114】このため、サーバアドレス問い合わせを行
った業務クライアント1a以外の例えば業務クライアン
ト1fもサーバアドレス応答データ1203を受信する
ことが可能となる。その業務クライアント1fが在庫デ
ータ更新処理という処理を業務サーバに依頼したい場
合、名前サーバ4に対して同じ問い合わせを行う必要が
なく、直接業務サーバ2に処理を依頼すればよい様にな
る。また、一般に放送通信はネットワークの負荷を高め
るものであるが、ある処理を提供している業務サーバ2
のアドレスに関する問い合わせはいずれかの業務クライ
アント1がやれば他の業務クライアントはそれを行う必
要がないので、この放送通信の行われる頻度は少なく、
ネットワークへの負荷はあまり高くない。特に,対象と
なる業務クライアント1が多くしかも,それぞれのトラ
ンザクション処理要求が多いときには本発明の効果は大
きい.
った業務クライアント1a以外の例えば業務クライアン
ト1fもサーバアドレス応答データ1203を受信する
ことが可能となる。その業務クライアント1fが在庫デ
ータ更新処理という処理を業務サーバに依頼したい場
合、名前サーバ4に対して同じ問い合わせを行う必要が
なく、直接業務サーバ2に処理を依頼すればよい様にな
る。また、一般に放送通信はネットワークの負荷を高め
るものであるが、ある処理を提供している業務サーバ2
のアドレスに関する問い合わせはいずれかの業務クライ
アント1がやれば他の業務クライアントはそれを行う必
要がないので、この放送通信の行われる頻度は少なく、
ネットワークへの負荷はあまり高くない。特に,対象と
なる業務クライアント1が多くしかも,それぞれのトラ
ンザクション処理要求が多いときには本発明の効果は大
きい.
【0115】なお,業務サ−バ2の業務サ−バプロセス
の内容によってサ−ビスをする業務クライアント1が限
定されているときは,アドレスの対応表1104に各業
務サ−バの処理内容,業務サ−バプロセスのアドレスに
加えて,対象の業務クライアント1の情報を付加し,問
い合わせに対して該当の各業務クライアント1に限定し
て放送通信する様にしてもよい.
の内容によってサ−ビスをする業務クライアント1が限
定されているときは,アドレスの対応表1104に各業
務サ−バの処理内容,業務サ−バプロセスのアドレスに
加えて,対象の業務クライアント1の情報を付加し,問
い合わせに対して該当の各業務クライアント1に限定し
て放送通信する様にしてもよい.
【0116】以上のように第5の発明によれば、ある業
務クライアント1が名前サーバ4に対して問い合わせた
業務サーバ2に関する情報を、他の業務クライアント1
も共有することができるため、それらの業務クライアン
ト1が名前4サーバに対して同じサーバに関する問い合
わせを行う無駄を抑制することができるため、システム
の処理効率向上を図ることができるという効果がある。
務クライアント1が名前サーバ4に対して問い合わせた
業務サーバ2に関する情報を、他の業務クライアント1
も共有することができるため、それらの業務クライアン
ト1が名前4サーバに対して同じサーバに関する問い合
わせを行う無駄を抑制することができるため、システム
の処理効率向上を図ることができるという効果がある。
【0117】実施例5.本発明の第6の発明に係わる本
実施例5は高負荷時にメモリ容量の制約によりシステム
のオ−バフロ−等の障害を未然に防止し負荷分散する事
例であり,以下図13〜図19を用いて説明する。
実施例5は高負荷時にメモリ容量の制約によりシステム
のオ−バフロ−等の障害を未然に防止し負荷分散する事
例であり,以下図13〜図19を用いて説明する。
【0118】図13は、当発明の一実施例である実施例
5の全体構成図である。図13において、2a、2bは
業務サーバ、1a、1b、1cは業務クライアント、1
303a、1303bは業務サーバ2a、2bの記憶装
置である。
5の全体構成図である。図13において、2a、2bは
業務サーバ、1a、1b、1cは業務クライアント、1
303a、1303bは業務サーバ2a、2bの記憶装
置である。
【0119】図14は図13の業務サーバ2a、2bの
構成図である。図14で2は業務サーバ、1411a〜
bは業務クライアント1a〜cの要求を処理する手段を
持つ業務サーバプロセス、1421は業務サーバ2のメ
モリ領域を管理する手段を持つメモリ管理部、1422
はプロセスの実行等を制御する手段を持つプロセス制御
部、1423はプロセスの実行、或いは実行待ちなどの
状態を管理する手段をもつプロセス管理部、1424は
プロセス管理部1423のための記憶部、1425はメ
モリ管理部1421のための記憶部である。
構成図である。図14で2は業務サーバ、1411a〜
bは業務クライアント1a〜cの要求を処理する手段を
持つ業務サーバプロセス、1421は業務サーバ2のメ
モリ領域を管理する手段を持つメモリ管理部、1422
はプロセスの実行等を制御する手段を持つプロセス制御
部、1423はプロセスの実行、或いは実行待ちなどの
状態を管理する手段をもつプロセス管理部、1424は
プロセス管理部1423のための記憶部、1425はメ
モリ管理部1421のための記憶部である。
【0120】図15はプロセス管理部1423が備え、
起動中の業務サーバプロセス1411の状態を管理する
起動プロセス管理テーブル1460の構成を示す。同図
中、1461は業務サーバプロセス名、1462はプロ
セスID、1463は複製プロセス数、1464は業務
サ−バプロセス1411の処理回数を示すアクセス回
数,1465は業務サ−バプロセス1411の優先順
位,1466は業務サ−バプロセス1411が縮退対象
か否かを示す縮退対象,である。図16はメモリ管理部
1421の、図17はプロセス制御部1422の、それ
ぞれフロ−チャ−トである.図18はプロセス管理部1
423の動作を示すフローチャートである。図19はプ
ロセス管理部1423内でプロセス制御部1422に対
応する動作を示すフロ−チャ−トである.
起動中の業務サーバプロセス1411の状態を管理する
起動プロセス管理テーブル1460の構成を示す。同図
中、1461は業務サーバプロセス名、1462はプロ
セスID、1463は複製プロセス数、1464は業務
サ−バプロセス1411の処理回数を示すアクセス回
数,1465は業務サ−バプロセス1411の優先順
位,1466は業務サ−バプロセス1411が縮退対象
か否かを示す縮退対象,である。図16はメモリ管理部
1421の、図17はプロセス制御部1422の、それ
ぞれフロ−チャ−トである.図18はプロセス管理部1
423の動作を示すフローチャートである。図19はプ
ロセス管理部1423内でプロセス制御部1422に対
応する動作を示すフロ−チャ−トである.
【0121】つぎに上記実施例の動作を図15〜19を
参照しながら説明する。メモリ管理部1421の動作、
プロセス制御部1422の動作、プロセス管理部142
3の動作の順に説明する。
参照しながら説明する。メモリ管理部1421の動作、
プロセス制御部1422の動作、プロセス管理部142
3の動作の順に説明する。
【0122】まず、メモリ管理部1421の動作につい
て図16により説明する。はじめに、残メモリサイズの
閾値を設定する(ステップ1501)。最大メモリサイ
ズ、使用メモリサイズを入力し(ステップ1502)、
残メモリサイズを測定後、閾値と比較しメモリの負荷状
況を判断する(ステップ1503)。その結果、閾値以
上の場合、プロセス制御部1422に対して縮退運転要
求を送信しステップ1502に戻り、結果が閾値以下の
場合(ステップ1503)は、処理を行なわずステップ
1502に戻る。
て図16により説明する。はじめに、残メモリサイズの
閾値を設定する(ステップ1501)。最大メモリサイ
ズ、使用メモリサイズを入力し(ステップ1502)、
残メモリサイズを測定後、閾値と比較しメモリの負荷状
況を判断する(ステップ1503)。その結果、閾値以
上の場合、プロセス制御部1422に対して縮退運転要
求を送信しステップ1502に戻り、結果が閾値以下の
場合(ステップ1503)は、処理を行なわずステップ
1502に戻る。
【0123】次にプロセス制御部1422の動作につい
て図17により説明する。プロセス制御部1422は常
にメモリ管理部1421からのメモリ負荷状況の入力待
ち状態にある(ステップ1601)。メモリ管理部14
21から負荷状況が通知された場合、負荷状況を判断し
(ステッブ1602)、その結果が閾値以上の場合は、
プロセス管理部1423に対して、縮退運転命令を通知
し、優先順位が付けられた処理待ち状態である業務サー
バプロセス1411(以下、処理待ち状態である業務サ
ーバプロセスを不活性プロセスと呼ぶ)の情報を受信す
る(ステップ1603)。この詳細は後に図19で説明
する.そして、当該の消去プロセスを記憶部1425に
記録し(ステップ1604)、優先順位の低い順に不活
性プロセスである業務サーバプロセス1411をメモリ
から消去する(ステップ1605)。また、メモリ負荷
が閾値以下と判断された場合は、先にステップ1605
で消去された業務サーバプロセス1411が存在するか
をプロセス管理部1423に照会し,存在しなければス
テップ1601に移る.存在すれば,後述の図19のス
テップ1455〜1456の処理を経て,復旧する消去
プロセスの情報を得,復旧運転命令を実行する(ステッ
プ1606〜1608).
て図17により説明する。プロセス制御部1422は常
にメモリ管理部1421からのメモリ負荷状況の入力待
ち状態にある(ステップ1601)。メモリ管理部14
21から負荷状況が通知された場合、負荷状況を判断し
(ステッブ1602)、その結果が閾値以上の場合は、
プロセス管理部1423に対して、縮退運転命令を通知
し、優先順位が付けられた処理待ち状態である業務サー
バプロセス1411(以下、処理待ち状態である業務サ
ーバプロセスを不活性プロセスと呼ぶ)の情報を受信す
る(ステップ1603)。この詳細は後に図19で説明
する.そして、当該の消去プロセスを記憶部1425に
記録し(ステップ1604)、優先順位の低い順に不活
性プロセスである業務サーバプロセス1411をメモリ
から消去する(ステップ1605)。また、メモリ負荷
が閾値以下と判断された場合は、先にステップ1605
で消去された業務サーバプロセス1411が存在するか
をプロセス管理部1423に照会し,存在しなければス
テップ1601に移る.存在すれば,後述の図19のス
テップ1455〜1456の処理を経て,復旧する消去
プロセスの情報を得,復旧運転命令を実行する(ステッ
プ1606〜1608).
【0124】次にプロセス管理部1423の動作につい
て図14、図15、図18、図19を用いて説明する。
図14,図15,図18において,初めに、業務サーバ
プロセス1411a,bが起動された時、業務サーバプ
ロセス名1461、業務サーバプロセスのプロセスID
1462、複製プロセスの数1463、各複製プロセス
のプロセスID1462を起動プロセス管理テ−ブル1
460に通知する(ステップ1701)。複製プロセス
の数とはメモリ上に複製され、同一内容のプロセスが別
タスクとして実行されるプロセスの数である。
て図14、図15、図18、図19を用いて説明する。
図14,図15,図18において,初めに、業務サーバ
プロセス1411a,bが起動された時、業務サーバプ
ロセス名1461、業務サーバプロセスのプロセスID
1462、複製プロセスの数1463、各複製プロセス
のプロセスID1462を起動プロセス管理テ−ブル1
460に通知する(ステップ1701)。複製プロセス
の数とはメモリ上に複製され、同一内容のプロセスが別
タスクとして実行されるプロセスの数である。
【0125】プロセス管理部1423内では、図15に
示す起動プロセス管理テーブル1460を用いて起動中
の業務サーバプロセス情報を管理する。この手続きは、
業務サーバプロセス1411が起動される時に必ず行な
われる。続いて、業務サーバプロセス1411a〜bか
らの処理要求待ち状態に入る(ステップ1702)。業
務サーバプロセス1411a〜bからその機能の開始通
知が来た場合は、同時に業務サ−バプロセス名146
1,プロセスID1462を受信し(ステップ170
3)、起動プロセス管理テーブル1460の業務サーバ
プロセスのアクセス回数1464を加算する(ステップ
1704)。このアクセス回数1464の集計結果か
ら、各業務サーバプロセス1411a〜bの優先順位1
465を決定する。優先順位1465は、アクセス回数
1464の値の多い業務サ−バプロセス1411ほど負
荷も大きいので,高い(ステップ1705)。
示す起動プロセス管理テーブル1460を用いて起動中
の業務サーバプロセス情報を管理する。この手続きは、
業務サーバプロセス1411が起動される時に必ず行な
われる。続いて、業務サーバプロセス1411a〜bか
らの処理要求待ち状態に入る(ステップ1702)。業
務サーバプロセス1411a〜bからその機能の開始通
知が来た場合は、同時に業務サ−バプロセス名146
1,プロセスID1462を受信し(ステップ170
3)、起動プロセス管理テーブル1460の業務サーバ
プロセスのアクセス回数1464を加算する(ステップ
1704)。このアクセス回数1464の集計結果か
ら、各業務サーバプロセス1411a〜bの優先順位1
465を決定する。優先順位1465は、アクセス回数
1464の値の多い業務サ−バプロセス1411ほど負
荷も大きいので,高い(ステップ1705)。
【0126】また、ステップ1702の結果、業務サー
バから機能の終了通知が来た場合は、ステップ1703
と同様に,業務サ−バプロセス名1461,プロセスI
D1462を受信し(ステップ1706)、起動プロセ
ス管理テーブル1460のアクセス回数1464を減算
する(ステップ1707)。続いて、業務サーバプロセ
ス1411の優先順位1463を再設定し(ステップ1
708),ステップ1702に戻る.
バから機能の終了通知が来た場合は、ステップ1703
と同様に,業務サ−バプロセス名1461,プロセスI
D1462を受信し(ステップ1706)、起動プロセ
ス管理テーブル1460のアクセス回数1464を減算
する(ステップ1707)。続いて、業務サーバプロセ
ス1411の優先順位1463を再設定し(ステップ1
708),ステップ1702に戻る.
【0127】次に,プロセス管理部1423内で,プロ
セス制御部1422に対応する動作を図19,図17を
用いて説明する.図17において,ステップ1602の
メモリ負荷の判断に続く閾値以上のときのステップ16
03と閾値以下のステップ1606の実行が図19のス
テップ1451に繋がる.プロセス管理部1423で
は,プロセス制御部1422より縮退運転命令が実行さ
れる旨通知されると(ステップ1451),起動プロセ
ス管理テ−ブル1460において,優先順位1465が
最も低く,且つ縮退対象1466に縮退のマ−クが付い
ていない業務サ−バプロセス名1461等を検索する
(ステップ1452).そして,当該の業務サ−バプロ
セス名1461の縮退対象1466に縮退のマ−クを付
け(ステップ1453),業務サ−バプロセス名146
1及びプロセスID1462をプロセス制御部1422
に通知し(ステップ1454),図17に示すプロセス
制御部1422の処理のステップ1603に繋がる.一
方,ステップ1451のプロセス制御部1422からの
受信が,縮退した業務サ−バプロセス1411の復旧運
転命令を実行する旨の場合は,起動プロセス管理テ−ブ
ル1460を検索し,縮退対象1466にマ−クがなさ
れ,且つ優先順位1465の高いプロセスの業務サ−バ
プロセス名1461,プロセスID1462を得る(ス
テップ1455).そして,当該業務サ−バプロセス名
1461の縮退対象1466の縮退マ−クを削除し(ス
テップ1456),ステップ1454に移って,検索し
た業務サ−バプロセス名1461,プロセスID146
2をプロセス制御部1422に通知し,図17のステッ
プ1606に繋げる.
セス制御部1422に対応する動作を図19,図17を
用いて説明する.図17において,ステップ1602の
メモリ負荷の判断に続く閾値以上のときのステップ16
03と閾値以下のステップ1606の実行が図19のス
テップ1451に繋がる.プロセス管理部1423で
は,プロセス制御部1422より縮退運転命令が実行さ
れる旨通知されると(ステップ1451),起動プロセ
ス管理テ−ブル1460において,優先順位1465が
最も低く,且つ縮退対象1466に縮退のマ−クが付い
ていない業務サ−バプロセス名1461等を検索する
(ステップ1452).そして,当該の業務サ−バプロ
セス名1461の縮退対象1466に縮退のマ−クを付
け(ステップ1453),業務サ−バプロセス名146
1及びプロセスID1462をプロセス制御部1422
に通知し(ステップ1454),図17に示すプロセス
制御部1422の処理のステップ1603に繋がる.一
方,ステップ1451のプロセス制御部1422からの
受信が,縮退した業務サ−バプロセス1411の復旧運
転命令を実行する旨の場合は,起動プロセス管理テ−ブ
ル1460を検索し,縮退対象1466にマ−クがなさ
れ,且つ優先順位1465の高いプロセスの業務サ−バ
プロセス名1461,プロセスID1462を得る(ス
テップ1455).そして,当該業務サ−バプロセス名
1461の縮退対象1466の縮退マ−クを削除し(ス
テップ1456),ステップ1454に移って,検索し
た業務サ−バプロセス名1461,プロセスID146
2をプロセス制御部1422に通知し,図17のステッ
プ1606に繋げる.
【0128】このように、不活性プロセスの強制消滅に
よる空きメモリ領域の一時的確保やプロセス数の減少な
どにより、メモリのオーバ・フロー,システム・ダウン
などの障害も未然に防ぐことが出来,障害回復に時間を
要することもない。また、各種サーバも必要なメモリ領
域を確保することが出来る。更に、システム障害を予測
し、それに備えて予め用意する複製サーバプロセスの数
を制限し、通常のシステムのパフォーマンスを低下させ
ることもなくなり,トランザクション負荷の増大に伴う
システムの障害が回避される。
よる空きメモリ領域の一時的確保やプロセス数の減少な
どにより、メモリのオーバ・フロー,システム・ダウン
などの障害も未然に防ぐことが出来,障害回復に時間を
要することもない。また、各種サーバも必要なメモリ領
域を確保することが出来る。更に、システム障害を予測
し、それに備えて予め用意する複製サーバプロセスの数
を制限し、通常のシステムのパフォーマンスを低下させ
ることもなくなり,トランザクション負荷の増大に伴う
システムの障害が回避される。
【0129】第6の発明によれば、高負荷時にあっても
各種業務サーバの縮退運転機能によって、自動的に空き
メモリ領域が確保される。そのため、ハードウェアの制
限からくるシステム・ダウン等の障害も未然に防止する
ことができる。また、システム障害を予測して、予め用
意する同一機能サーバの数を制限し消極的に見積もる必
要がなく一定化でき、資源の利用効率を向上させる。
各種業務サーバの縮退運転機能によって、自動的に空き
メモリ領域が確保される。そのため、ハードウェアの制
限からくるシステム・ダウン等の障害も未然に防止する
ことができる。また、システム障害を予測して、予め用
意する同一機能サーバの数を制限し消極的に見積もる必
要がなく一定化でき、資源の利用効率を向上させる。
【0130】実施例6.本実施例6は本発明の第7の発
明に係わる実施例で,過負荷時においても負荷分散す
る。以下,本実施例6を図20〜図25を用いて説明す
る.
明に係わる実施例で,過負荷時においても負荷分散す
る。以下,本実施例6を図20〜図25を用いて説明す
る.
【0131】図20は、本実施例6の構成図で,図13
の業務サーバ2aもしくは2bと同じ業務サ−バ2の内
部構成を表す。図20において、1は業務クライアン
ト、1811は業務サーバプロセス、1812は業務サ
ーバプロセス1811の機能群を構成する機能、182
1は、過負荷時に発生させる代行業務サーバプロセス
(後記)を制御するサーバ管理部である.業務サーバプ
ロセス1811はサーバ管理部1821によって管理さ
れる。業務サーバプロセス1811は、上記のように1
つ以上の機能から構成される機能群の集合体であり、生
成および消滅はサーバ管理部1821によって実施され
る。1822は、プロセスの状態を管理するプロセス管
理部であり、1824はサーバ管理部1821の記憶部
であり、1823はプロセス管理部1822の記憶部で
ある。
の業務サーバ2aもしくは2bと同じ業務サ−バ2の内
部構成を表す。図20において、1は業務クライアン
ト、1811は業務サーバプロセス、1812は業務サ
ーバプロセス1811の機能群を構成する機能、182
1は、過負荷時に発生させる代行業務サーバプロセス
(後記)を制御するサーバ管理部である.業務サーバプ
ロセス1811はサーバ管理部1821によって管理さ
れる。業務サーバプロセス1811は、上記のように1
つ以上の機能から構成される機能群の集合体であり、生
成および消滅はサーバ管理部1821によって実施され
る。1822は、プロセスの状態を管理するプロセス管
理部であり、1824はサーバ管理部1821の記憶部
であり、1823はプロセス管理部1822の記憶部で
ある。
【0132】また図21は,図20の平常負荷状態か
ら、業務サーバプロセスの過負荷時に、業務サーバプロ
セスの1機能群の業務を遂行するための代行業務サーバ
プロセス(業務サ−バプロセスの内,必要機能に絞った
構成)が発生した状態の構成を示す図である。図におい
て,1911は代行業務サーバプロセスである。191
2は代行業務サーバプロセス1911の構成を示すもの
で、実体は代行業務サーバプロセス1911である。な
お,図22はサーバ管理部1821が持つ業務サーバプ
ロセスのアドレス情報を保持しているアドレス管理テー
ブル1850で,業務サーバプロセス名1851、機能
群名1852、アドレス情報1853などにより構成さ
れる。図23はプロセス管理部1822が持つ業務サー
バ管理テーブル1860で、業務サーバプロセス名18
61、機能群名1862、閾値1863、機能名186
4,アクセス回数1865,縮退運転1866により構
成される.これらの内,アクセス回数1865は業務サ
−バプロセス1811の実行タスク数を意味する.図2
4はプロセス管理部1822の、図25はサーバ管理部
1821の何れも内部動作を示すフローチャートであ
る。
ら、業務サーバプロセスの過負荷時に、業務サーバプロ
セスの1機能群の業務を遂行するための代行業務サーバ
プロセス(業務サ−バプロセスの内,必要機能に絞った
構成)が発生した状態の構成を示す図である。図におい
て,1911は代行業務サーバプロセスである。191
2は代行業務サーバプロセス1911の構成を示すもの
で、実体は代行業務サーバプロセス1911である。な
お,図22はサーバ管理部1821が持つ業務サーバプ
ロセスのアドレス情報を保持しているアドレス管理テー
ブル1850で,業務サーバプロセス名1851、機能
群名1852、アドレス情報1853などにより構成さ
れる。図23はプロセス管理部1822が持つ業務サー
バ管理テーブル1860で、業務サーバプロセス名18
61、機能群名1862、閾値1863、機能名186
4,アクセス回数1865,縮退運転1866により構
成される.これらの内,アクセス回数1865は業務サ
−バプロセス1811の実行タスク数を意味する.図2
4はプロセス管理部1822の、図25はサーバ管理部
1821の何れも内部動作を示すフローチャートであ
る。
【0133】次に上記実施例の動作を図20,図22,
図24、25を用いて説明する。業務クライアント1か
ら処理の要求があつた時の動作、プロセス管理部182
2の動作、業務サーバ管理部1821の動作を順に説明
する。
図24、25を用いて説明する。業務クライアント1か
ら処理の要求があつた時の動作、プロセス管理部182
2の動作、業務サーバ管理部1821の動作を順に説明
する。
【0134】全体動作の前提になる処理を主に図20,
図22により説明する.まず,任意の業務クライアント
1a〜cより、業務サーバプロセス1811に対して処
理要求,アクセス要求が生じた場合は、まずサーバ管理
部1821に対して業務サーバプロセス1811と通信
を行なうためのアドレス情報の獲得要求をする。サーバ
管理部1821は、図22に示すアドレス管理テーブル
1850を持ち、各機能群毎のアドレス情報1853を
管理している。サーバ管理部1821は、業務サーバプ
ロセス1811のアドレス管理テーブル1850を検索
し、要求した業務クライアント1に対して検索結果を返
送し,業務クライアント1は業務サ−バプロセス181
1へのアクセスが可能になる。
図22により説明する.まず,任意の業務クライアント
1a〜cより、業務サーバプロセス1811に対して処
理要求,アクセス要求が生じた場合は、まずサーバ管理
部1821に対して業務サーバプロセス1811と通信
を行なうためのアドレス情報の獲得要求をする。サーバ
管理部1821は、図22に示すアドレス管理テーブル
1850を持ち、各機能群毎のアドレス情報1853を
管理している。サーバ管理部1821は、業務サーバプ
ロセス1811のアドレス管理テーブル1850を検索
し、要求した業務クライアント1に対して検索結果を返
送し,業務クライアント1は業務サ−バプロセス181
1へのアクセスが可能になる。
【0135】次にプロセス管理部1822の動作につい
て図24を用いて説明する。初めに、プロセス管理部1
822の業務サーバ管理テーブル1860には予め業務
サーバプロセス名1861と、その業務サーバプロセス
が保有する機能群1862、機能名1864、及び機能
群の閾値1863の設定を行なう(ステップ200
1)。機能群の閾値1863とは、ある機能群に対する
処理要求,アクセス要求が集中した場合、その業務サー
バプロセス1811がボトルネック状態となり、他の機
能群への処理要求を妨げる状態となることを未然に防ぐ
ために予め設定するアクセス回数の限度数である。この
閾値1863の設定値を越えた場合は、代行業務サーバ
1911が起動される。
て図24を用いて説明する。初めに、プロセス管理部1
822の業務サーバ管理テーブル1860には予め業務
サーバプロセス名1861と、その業務サーバプロセス
が保有する機能群1862、機能名1864、及び機能
群の閾値1863の設定を行なう(ステップ200
1)。機能群の閾値1863とは、ある機能群に対する
処理要求,アクセス要求が集中した場合、その業務サー
バプロセス1811がボトルネック状態となり、他の機
能群への処理要求を妨げる状態となることを未然に防ぐ
ために予め設定するアクセス回数の限度数である。この
閾値1863の設定値を越えた場合は、代行業務サーバ
1911が起動される。
【0136】次いで、業務サーバプロセス1811が起
動された時、業務サーバプロセス名、業務サーバプロセ
スのプロセスID、複製プロセスの数、各複製プロセス
のプロセスIDを既述の図15の起動プロセス管理テー
ブル1460と同様のテーブルに登録する(ステップ2
002)。なお,このテ−ブルは処理が終了したら登録
プロセスを削除する.プロセス管理部1822内では、
図23に示す業務サーバ管理テーブル1860を用いて
各業務サーバ1811の情報を管理する。続いて、業務
サーバプロセス1811は処理要求,アクセス要求待ち
状態に入る(ステップ2003)。
動された時、業務サーバプロセス名、業務サーバプロセ
スのプロセスID、複製プロセスの数、各複製プロセス
のプロセスIDを既述の図15の起動プロセス管理テー
ブル1460と同様のテーブルに登録する(ステップ2
002)。なお,このテ−ブルは処理が終了したら登録
プロセスを削除する.プロセス管理部1822内では、
図23に示す業務サーバ管理テーブル1860を用いて
各業務サーバ1811の情報を管理する。続いて、業務
サーバプロセス1811は処理要求,アクセス要求待ち
状態に入る(ステップ2003)。
【0137】業務サーバプロセス1811から機能の開
始通知が来た場合は、同時に機能群名1862および機
能名1864を受信し(ステップ2004)、その機能
群へのアクセス回数1865を増加させる(ステップ2
005)。続いて、業務サーバプロセス1811内の機
能群の負荷状況を、アクセス回数,その時の全体の使用
可能なメモリ領域,タスク数などを考慮して計算する
(ステップ2006)。その結果から、負荷状況を判断
し(ステップ2007)、全体のメモリ領域,タスク数
などを考慮した機能群へのアクセス回数1865が閾値
1863以上となった場合は、業務サ−バ管理テ−ブル
1860で縮退運転マ−クがなく,且つアクセス回数1
865が最大の業務サ−バプロセス名1861を検索
し,サーバ管理部1821に対して対応業務サ−バプロ
セス1811の縮退運転命令を送る.また,同時に縮退
対象の業務サ−バプロセス1811の縮退運転1866
に縮退のマ−クをする.(ステップ2008)。機能群
へのアクセス回数1865が閾値1863以下の場合は
(ステップ2003)に戻る。
始通知が来た場合は、同時に機能群名1862および機
能名1864を受信し(ステップ2004)、その機能
群へのアクセス回数1865を増加させる(ステップ2
005)。続いて、業務サーバプロセス1811内の機
能群の負荷状況を、アクセス回数,その時の全体の使用
可能なメモリ領域,タスク数などを考慮して計算する
(ステップ2006)。その結果から、負荷状況を判断
し(ステップ2007)、全体のメモリ領域,タスク数
などを考慮した機能群へのアクセス回数1865が閾値
1863以上となった場合は、業務サ−バ管理テ−ブル
1860で縮退運転マ−クがなく,且つアクセス回数1
865が最大の業務サ−バプロセス名1861を検索
し,サーバ管理部1821に対して対応業務サ−バプロ
セス1811の縮退運転命令を送る.また,同時に縮退
対象の業務サ−バプロセス1811の縮退運転1866
に縮退のマ−クをする.(ステップ2008)。機能群
へのアクセス回数1865が閾値1863以下の場合は
(ステップ2003)に戻る。
【0138】また、ステップ2003の結果、業務サー
バプロセス1811から機能の終了通知が来た場合は、
機能群および機能名を受信し(ステップ2009)、そ
の機能群のアクセス回数1865を減少させる(ステッ
プ2010)。続いて、業務サーバプロセス内の機能群
の負荷状況を計算する(ステップ2011)。その結果
から、負荷状況を判断し(ステップ2012)、機能群
へのアクセス回数1865が閾値1863以下に下がっ
た場合は、サーバ管理部1821に対してステップ20
08でおこなった業務サーバプロセスの縮退運転を解消
するため復旧運転命令を送り,縮退運転1866の縮退
のマ−クを削除する(ステップ2013)。機能群への
アクセス回数1865が閾値1863以上の場合はステ
ップ2003に戻る。
バプロセス1811から機能の終了通知が来た場合は、
機能群および機能名を受信し(ステップ2009)、そ
の機能群のアクセス回数1865を減少させる(ステッ
プ2010)。続いて、業務サーバプロセス内の機能群
の負荷状況を計算する(ステップ2011)。その結果
から、負荷状況を判断し(ステップ2012)、機能群
へのアクセス回数1865が閾値1863以下に下がっ
た場合は、サーバ管理部1821に対してステップ20
08でおこなった業務サーバプロセスの縮退運転を解消
するため復旧運転命令を送り,縮退運転1866の縮退
のマ−クを削除する(ステップ2013)。機能群への
アクセス回数1865が閾値1863以上の場合はステ
ップ2003に戻る。
【0139】次にサーバ管理部1821の動作を図25
を用いて説明する。サーバ管理部1821は、常にプロ
セス管理部1822からの処理要求,アクセス要求を受
け入れる機能を用意しているが(ステップ2101),
これは図24のプロセス管理部1822の処理であるス
テップ2008,ステップ2013から繋がる。プロセ
ス管理部1822からの命令が、縮退運転命令である
か、もしくは復旧運転命令であるかを判断し(ステップ
2102)、縮退運転命令の場合は、代行業務サーバプ
ロセス1911の生成、及び代行業務サーバプロセス1
911のアドレス情報の獲得を行ない(ステップ210
3)、過負荷な機能群の代行業務サーバプロセス191
1への移行を行なう(ステップ2104)。そして、機
能群を移行した業務サーバプロセス1811に対して、
移行した機能群にサスペンド命令を出して当該の業務サ
−バプロセス1811を記憶部1824に退避させる.
また、ステップ2103によって得られたアドレス情報
を基に、図22のアドレス管理テーブル1850中の機
能群のアドレス情報1853の変更を行ない(ステップ
2105)、ステップ2101に戻る。それ以降の業務
クライアント1a〜cからの移行した機能群への処理要
求に対しては、代行業務サーバプロセス1911のアド
レス情報1853を通知し,以後,それがアクセスされ
る。
を用いて説明する。サーバ管理部1821は、常にプロ
セス管理部1822からの処理要求,アクセス要求を受
け入れる機能を用意しているが(ステップ2101),
これは図24のプロセス管理部1822の処理であるス
テップ2008,ステップ2013から繋がる。プロセ
ス管理部1822からの命令が、縮退運転命令である
か、もしくは復旧運転命令であるかを判断し(ステップ
2102)、縮退運転命令の場合は、代行業務サーバプ
ロセス1911の生成、及び代行業務サーバプロセス1
911のアドレス情報の獲得を行ない(ステップ210
3)、過負荷な機能群の代行業務サーバプロセス191
1への移行を行なう(ステップ2104)。そして、機
能群を移行した業務サーバプロセス1811に対して、
移行した機能群にサスペンド命令を出して当該の業務サ
−バプロセス1811を記憶部1824に退避させる.
また、ステップ2103によって得られたアドレス情報
を基に、図22のアドレス管理テーブル1850中の機
能群のアドレス情報1853の変更を行ない(ステップ
2105)、ステップ2101に戻る。それ以降の業務
クライアント1a〜cからの移行した機能群への処理要
求に対しては、代行業務サーバプロセス1911のアド
レス情報1853を通知し,以後,それがアクセスされ
る。
【0140】また、ステップ2102の結果が復旧運転
命令の場合は、機能群を移行した業務サーバプロセス1
811に対してサスペンド状態の解除命令(ステップ2
106)を出し、代行業務サーバプロセス1911を強
制消去し,ステップ2105で退避した業務サ−バプロ
セス1811を記憶部1824から復帰させる(ステッ
プ2107)。そして、アドレス管理テーブル1850
中の機能群のアドレス情報1853を復帰する業務サ−
バプロセス1811のアドレスに修正をし機能群の復旧
運転を終了する(ステップ2108)。 サーバ管理部
1821は、それ以降の業務クライアント1a〜cの処
理要求に対しては、通常の業務サーバプロセス1811
のアドレス情報1853を返送する。
命令の場合は、機能群を移行した業務サーバプロセス1
811に対してサスペンド状態の解除命令(ステップ2
106)を出し、代行業務サーバプロセス1911を強
制消去し,ステップ2105で退避した業務サ−バプロ
セス1811を記憶部1824から復帰させる(ステッ
プ2107)。そして、アドレス管理テーブル1850
中の機能群のアドレス情報1853を復帰する業務サ−
バプロセス1811のアドレスに修正をし機能群の復旧
運転を終了する(ステップ2108)。 サーバ管理部
1821は、それ以降の業務クライアント1a〜cの処
理要求に対しては、通常の業務サーバプロセス1811
のアドレス情報1853を返送する。
【0141】このように、第7の発明によれば、過負荷
時においても代行業務サーバへの処理の移行によって、
ボトルネック現象を防止し、業務サーバプロセスの円滑
な処理を継続することが出来る。また、業務サーバ資源
に対する処理の応答性や利用効率を向上させることが出
来、従来システム障害によって行なってきた復旧作業に
要する時間および作業が発生しなくなり、メンテナンス
時間も短縮することが出来る。従って,過負荷により発
生するトランザクションシステムの障害が未然に抑制さ
れる.
時においても代行業務サーバへの処理の移行によって、
ボトルネック現象を防止し、業務サーバプロセスの円滑
な処理を継続することが出来る。また、業務サーバ資源
に対する処理の応答性や利用効率を向上させることが出
来、従来システム障害によって行なってきた復旧作業に
要する時間および作業が発生しなくなり、メンテナンス
時間も短縮することが出来る。従って,過負荷により発
生するトランザクションシステムの障害が未然に抑制さ
れる.
【0142】実施例7.本実施例7は本発明の第8の発
明に係る一実施例で以下図26〜図28を参照して説明
する.
明に係る一実施例で以下図26〜図28を参照して説明
する.
【0143】この実施例の目的は、負荷を制御するマネ
ージャと、それにともなう負荷監視のための通信を不要
にして通信トラフィックの減少を計り,また,マネ−ジ
ャの監視負荷を軽減し,更には,負荷の増大に対してシ
ステムの障害発生を防止することである。
ージャと、それにともなう負荷監視のための通信を不要
にして通信トラフィックの減少を計り,また,マネ−ジ
ャの監視負荷を軽減し,更には,負荷の増大に対してシ
ステムの障害発生を防止することである。
【0144】図26は本実施例の構成を示す。図におい
て、2201は伝送路、1はトランザクション要求をす
る業務クライアントである.2は業務クライアント1の
要求を処理する業務サ−バである.業務クライアント1
と業務サーバ1(2a)、業務サーバ2(2b)は、伝
送路2201を介して通信を行う。2204はトランザ
クション要求の送受信処理を行なうトランザクション要
求送受信部、2204aと2204bはトランザクショ
ン要求の送受信処理を行なう業務サーバ2のトランザク
ション要求送受信部、2205はトランザクション要求
の種類によって回覧リストを発生するトランザクション
回覧発生部、2206aと2206bは回覧リストを解
析する業務サーバのトランザクション回覧部、2207
aと2207bは業務サーバ2の負荷を検出するサーバ
負荷検出部、2208aと2208bはトランザクショ
ン要求を処理する業務サーバ2のトランザクション処理
部である。
て、2201は伝送路、1はトランザクション要求をす
る業務クライアントである.2は業務クライアント1の
要求を処理する業務サ−バである.業務クライアント1
と業務サーバ1(2a)、業務サーバ2(2b)は、伝
送路2201を介して通信を行う。2204はトランザ
クション要求の送受信処理を行なうトランザクション要
求送受信部、2204aと2204bはトランザクショ
ン要求の送受信処理を行なう業務サーバ2のトランザク
ション要求送受信部、2205はトランザクション要求
の種類によって回覧リストを発生するトランザクション
回覧発生部、2206aと2206bは回覧リストを解
析する業務サーバのトランザクション回覧部、2207
aと2207bは業務サーバ2の負荷を検出するサーバ
負荷検出部、2208aと2208bはトランザクショ
ン要求を処理する業務サーバ2のトランザクション処理
部である。
【0145】図27は業務サーバ回覧リストの構成を示
す。図において、2209はトランザクション要求時に
トランザクション回覧発生部2205が発行し、トラン
ザクション要求を処理する業務サーバ2の候補をリスト
アップした業務サーバ回覧リストであり,ここでは、業
務サーバ1(2a)と業務サーバ2(2b)が記載され
ているものとする。業務サーバ回覧リスト2209に
は、システム起動時には予め業務サーバ候補の欄と処理
負荷の欄に既定値が設定されている.図28は、業務サ
ーバ2の動作を示すフローチャートを示す。
す。図において、2209はトランザクション要求時に
トランザクション回覧発生部2205が発行し、トラン
ザクション要求を処理する業務サーバ2の候補をリスト
アップした業務サーバ回覧リストであり,ここでは、業
務サーバ1(2a)と業務サーバ2(2b)が記載され
ているものとする。業務サーバ回覧リスト2209に
は、システム起動時には予め業務サーバ候補の欄と処理
負荷の欄に既定値が設定されている.図28は、業務サ
ーバ2の動作を示すフローチャートを示す。
【0146】次ぎに,図28を用いて動作を説明する.
業務クライアント1がトランザクション回覧発生部22
05において、トランザクション要求を処理することの
できる業務サーバ2のリスト,業務サ−バ回覧リスト2
209を生成し、業務サ−バ回覧リスト2209とトラ
ンザクション要求をトランザクション要求送受信部22
04を介して業務サーバ1(2a)に送信する。
業務クライアント1がトランザクション回覧発生部22
05において、トランザクション要求を処理することの
できる業務サーバ2のリスト,業務サ−バ回覧リスト2
209を生成し、業務サ−バ回覧リスト2209とトラ
ンザクション要求をトランザクション要求送受信部22
04を介して業務サーバ1(2a)に送信する。
【0147】業務サーバ1(2a)では、トランザクシ
ョン要求送受信部2204aにて業務クライアント1か
ら業務回覧リスト2209とトランザクション要求を受
信する(ステップ2401)。
ョン要求送受信部2204aにて業務クライアント1か
ら業務回覧リスト2209とトランザクション要求を受
信する(ステップ2401)。
【0148】業務サ−バ回覧リスト2209を受け取っ
た業務サーバ1(2a)は、それが既に該当の業務サ−
バ2(2b)の回覧を終了していたら,トランザクショ
ン処理部2208aにてトランザクションを処理し、ト
ランザクション要求送受信部2204aを介して業務ク
ライアント1に応答を返す(ステップ2402,240
3)。
た業務サーバ1(2a)は、それが既に該当の業務サ−
バ2(2b)の回覧を終了していたら,トランザクショ
ン処理部2208aにてトランザクションを処理し、ト
ランザクション要求送受信部2204aを介して業務ク
ライアント1に応答を返す(ステップ2402,240
3)。
【0149】回覧リスト2209に記載されている業務
サーバ2への回覧後に他の業務サーバ2への回覧がすべ
て終了していない場合、サーバ負荷検出部2207aが
検出した業務サーバ1(2a)の処理負荷を回覧リスト
2209に書き込んだ後、回覧リスト2209の中で最
も処理負荷の低い業務サーバ2にトランザクション要求
と回覧リストを送信する(ステップ2404,240
5)。もし、回覧リスト2209を受信した業務サーバ
2の負荷がすべて同じならば、最後に受信した業務サー
バで処理を行なう。
サーバ2への回覧後に他の業務サーバ2への回覧がすべ
て終了していない場合、サーバ負荷検出部2207aが
検出した業務サーバ1(2a)の処理負荷を回覧リスト
2209に書き込んだ後、回覧リスト2209の中で最
も処理負荷の低い業務サーバ2にトランザクション要求
と回覧リストを送信する(ステップ2404,240
5)。もし、回覧リスト2209を受信した業務サーバ
2の負荷がすべて同じならば、最後に受信した業務サー
バで処理を行なう。
【0150】トランザクション回覧部2206aで、業
務サ−バ回覧リスト2209に記載されている業務サー
バ2への回覧が終了していなければ、サーバ負荷検出部
2207aが検出した業務サーバ1(2a)の処理負荷
を業務サ−バ回覧リスト2209の処理負荷欄に書き込
んだ後、それに記載された順番通り(この実施例では次
ぎの業務サーバ2 (2b))にトランザクション要求
送受信部2204aからトランザクション要求と業務サ
−バ回覧リスト2209を送信する(ステップ240
4,2406,2407)。
務サ−バ回覧リスト2209に記載されている業務サー
バ2への回覧が終了していなければ、サーバ負荷検出部
2207aが検出した業務サーバ1(2a)の処理負荷
を業務サ−バ回覧リスト2209の処理負荷欄に書き込
んだ後、それに記載された順番通り(この実施例では次
ぎの業務サーバ2 (2b))にトランザクション要求
送受信部2204aからトランザクション要求と業務サ
−バ回覧リスト2209を送信する(ステップ240
4,2406,2407)。
【0151】以上のように第8の発明によれば、回覧リ
スト2209に記載された業務サーバ2間でトランザク
ションの回覧を行い、最も負荷の低い業務サーバ2でト
ランザクションを処理するので、負荷を制御するマネー
ジャと、それにともなう負荷監視のための通信を不要に
して通信トラフィックの減少を計ることができる。この
ため,トランザクション処理負荷が増大しても制御負
荷,制御用の通信トラフイック増によるシステム障害を
回避出来る.
スト2209に記載された業務サーバ2間でトランザク
ションの回覧を行い、最も負荷の低い業務サーバ2でト
ランザクションを処理するので、負荷を制御するマネー
ジャと、それにともなう負荷監視のための通信を不要に
して通信トラフィックの減少を計ることができる。この
ため,トランザクション処理負荷が増大しても制御負
荷,制御用の通信トラフイック増によるシステム障害を
回避出来る.
【0152】実施例8.本実施例8は本発明の第9の発
明に係わる実施例で,以下図29,図30を用いて説明
する.
明に係わる実施例で,以下図29,図30を用いて説明
する.
【0153】この実施例の目的は、急激にトランザクシ
ョン処理の負荷が変動するトランザクション処理システ
ムにおいて、すべての業務サーバの負荷を均一化し、ト
ランザクション処理システムの処理を効率化を図り,負
荷増に伴うシステムの障害を回避することにある。
ョン処理の負荷が変動するトランザクション処理システ
ムにおいて、すべての業務サーバの負荷を均一化し、ト
ランザクション処理システムの処理を効率化を図り,負
荷増に伴うシステムの障害を回避することにある。
【0154】図29は本実施例の構成を示す.図におい
て,2501は伝送路、1はトランザクション要求を発
行する業務クライアント、2はトランザクション要求を
処理する業務サーバ、2504はトランザクション要求
の送受信処理を行うトランザクション要求送受信部、2
505はトランザクション要求を処理するトランザクシ
ョン処理部、2506は業務サーバの処理負荷を検出す
る処理負荷検出部、2507は業務サーバの処理負荷の
履歴を記憶する負荷履歴記憶部、2508は業務サーバ
の処理負荷の傾向を計算する負荷傾向検出部、2509
は業務サーバの処理負荷の上限値を記憶する負荷閾値記
憶部、2510はトランザクション要求を処理するかど
うかを判別する業務判定部である。図30は業務サーバ
2の動作を示すフローチャートを示す。
て,2501は伝送路、1はトランザクション要求を発
行する業務クライアント、2はトランザクション要求を
処理する業務サーバ、2504はトランザクション要求
の送受信処理を行うトランザクション要求送受信部、2
505はトランザクション要求を処理するトランザクシ
ョン処理部、2506は業務サーバの処理負荷を検出す
る処理負荷検出部、2507は業務サーバの処理負荷の
履歴を記憶する負荷履歴記憶部、2508は業務サーバ
の処理負荷の傾向を計算する負荷傾向検出部、2509
は業務サーバの処理負荷の上限値を記憶する負荷閾値記
憶部、2510はトランザクション要求を処理するかど
うかを判別する業務判定部である。図30は業務サーバ
2の動作を示すフローチャートを示す。
【0155】業務クライアント1と業務サーバ2は、伝
送路2501を介して通信を行う。
送路2501を介して通信を行う。
【0156】業務サーバ2の動作を図30を参照して説
明する.業務開始時に負荷閾値記憶部2509に処理負
荷の上限値(閾値)Wtが記憶されている(ステップ2
601)。業務クライアント1は、トランザクション要
求送受信部2504から業務サーバ2にトランザクショ
ン要求を発行する。
明する.業務開始時に負荷閾値記憶部2509に処理負
荷の上限値(閾値)Wtが記憶されている(ステップ2
601)。業務クライアント1は、トランザクション要
求送受信部2504から業務サーバ2にトランザクショ
ン要求を発行する。
【0157】業務サーバ2では、処理負荷検出部250
6がトランザクション処理部2505の処理負荷を定期
的に検出しており(ステップ2602)、検出した処理
負荷を時系列順に負荷履歴記憶部2507に記憶してい
る(ステップ2603)。さらに負荷傾向検出部250
8が、負荷履歴記憶部2507に記憶されている時刻と
処理負荷の関係から負荷傾向Trを以下の式によって計
算する(ステップ2604)。 Tr=(W2−W1)/(T2−T1)
なお、この式において、時刻T1における処理負荷
をW1、時刻T2における処理負荷をW2とし、T2>
T1である。また、処理負荷検出部2506は、予めシ
ステム起動時に負荷を検出する時間間隔が決められてい
るが、負荷傾向を分析することによって負荷を検出する
時間間隔を学習的に最適化してもよい。すなわち、Tr
が大きい時はT2−T1を小さくし、Trが小さい時は
T2−T1を大きくすることによって、負荷を検出する
時間間隔を最適化する。
6がトランザクション処理部2505の処理負荷を定期
的に検出しており(ステップ2602)、検出した処理
負荷を時系列順に負荷履歴記憶部2507に記憶してい
る(ステップ2603)。さらに負荷傾向検出部250
8が、負荷履歴記憶部2507に記憶されている時刻と
処理負荷の関係から負荷傾向Trを以下の式によって計
算する(ステップ2604)。 Tr=(W2−W1)/(T2−T1)
なお、この式において、時刻T1における処理負荷
をW1、時刻T2における処理負荷をW2とし、T2>
T1である。また、処理負荷検出部2506は、予めシ
ステム起動時に負荷を検出する時間間隔が決められてい
るが、負荷傾向を分析することによって負荷を検出する
時間間隔を学習的に最適化してもよい。すなわち、Tr
が大きい時はT2−T1を小さくし、Trが小さい時は
T2−T1を大きくすることによって、負荷を検出する
時間間隔を最適化する。
【0158】業務サーバ2は、トランザクション要求送
受信部2504にてトランザクション要求を受け取る
(ステップ2605)。業務判定部2510では、負荷
傾向検出部2508から得られる負荷傾向Trと、負荷
閾値記憶部2509から得られる処理負荷の閾値Wtか
ら、一定時間Ti後に処理負荷予測値が閾値を越えない
と判断した場合、すなわち以下の式が成り立つ場合は、 Tr・Ti≦Wt 業務判定部2510はトランザクション要求部2504
が受け取ったトランザクション要求をトランザクション
処理部2505に渡し、トランザクション要求を処理
し、トランザクション要求送受信部2504から業務ク
ライアント2502にトランザクション応答を返す(ス
テップ2607)。
受信部2504にてトランザクション要求を受け取る
(ステップ2605)。業務判定部2510では、負荷
傾向検出部2508から得られる負荷傾向Trと、負荷
閾値記憶部2509から得られる処理負荷の閾値Wtか
ら、一定時間Ti後に処理負荷予測値が閾値を越えない
と判断した場合、すなわち以下の式が成り立つ場合は、 Tr・Ti≦Wt 業務判定部2510はトランザクション要求部2504
が受け取ったトランザクション要求をトランザクション
処理部2505に渡し、トランザクション要求を処理
し、トランザクション要求送受信部2504から業務ク
ライアント2502にトランザクション応答を返す(ス
テップ2607)。
【0159】逆に、業務判定部2510にて負荷予測値
が閾値を越えると予測される場合、すなわち以下の式が
成り立つ場合は、 Tr・Ti>Wt
当該業務サーバ2でのトランザクション処理
を拒否し、トランザクション要求送受信部2504から
業務クライアント1にトランザクション処理の拒否を伝
える(ステップ2606)。なお、これに代えて、実施
例7に記載した方法によって(回覧リストの内容を各業
務サーバが記憶しておく)、自業務サーバ2よりも負荷
の低い他の業務サーバ2にトランザクション処理を依頼
するようにしてもよい。
が閾値を越えると予測される場合、すなわち以下の式が
成り立つ場合は、 Tr・Ti>Wt
当該業務サーバ2でのトランザクション処理
を拒否し、トランザクション要求送受信部2504から
業務クライアント1にトランザクション処理の拒否を伝
える(ステップ2606)。なお、これに代えて、実施
例7に記載した方法によって(回覧リストの内容を各業
務サーバが記憶しておく)、自業務サーバ2よりも負荷
の低い他の業務サーバ2にトランザクション処理を依頼
するようにしてもよい。
【0160】このように時刻T1,T2における処理負
荷ではなく、時間Ti後の処理負荷を予測して負荷を分
散するので、急激にトランザクション処理の負荷が変動
するトランザクション処理システムにおいて、処理負荷
の集中を回避し、すべての業務サーバの負荷を均一化
し、トランザクション処理システムの処理を効率化し,
負荷の増大に伴うシステムの障害を防ぐ。
荷ではなく、時間Ti後の処理負荷を予測して負荷を分
散するので、急激にトランザクション処理の負荷が変動
するトランザクション処理システムにおいて、処理負荷
の集中を回避し、すべての業務サーバの負荷を均一化
し、トランザクション処理システムの処理を効率化し,
負荷の増大に伴うシステムの障害を防ぐ。
【0161】以上のように第9の発明によれば、急激に
トランザクション処理の負荷が変動するトランザクショ
ン処理システムにおいて、すべての業務サーバの負荷を
均一化し、トランザクション処理システムの処理を効率
化するという効果がある。
トランザクション処理の負荷が変動するトランザクショ
ン処理システムにおいて、すべての業務サーバの負荷を
均一化し、トランザクション処理システムの処理を効率
化するという効果がある。
【0162】実施例9.図31は、本発明の第10,1
1の発明の一実施例である実施例9を図31〜図34に
より説明する.
1の発明の一実施例である実施例9を図31〜図34に
より説明する.
【0163】本実施例の目的は、業務サーバにポーリン
グをかけて管理情報を収集すると共に、業務クライアン
トから最大待ち時間の経過を報告させることによって、
負荷増大の原因が業務サーバにあるのか、業務クライア
ントにあるのか、中継する伝送路にあるのかを判別する
ことが可能となり、速やかに負荷増大への対処を可能に
し,システムの障害を回避することにある。
グをかけて管理情報を収集すると共に、業務クライアン
トから最大待ち時間の経過を報告させることによって、
負荷増大の原因が業務サーバにあるのか、業務クライア
ントにあるのか、中継する伝送路にあるのかを判別する
ことが可能となり、速やかに負荷増大への対処を可能に
し,システムの障害を回避することにある。
【0164】図31は本実施例の主要構成を示すブロッ
ク図である.図において,2701は伝送路、1はトラ
ンザクション要求を発行する業務クライアント、270
3はトランザクション要求の処理を行うトランザクショ
ン要求送受信部、2704は業務クライアント1におけ
るトランザクション処理経過時間を計測するトランザク
ション処理時間検出部、2705は業務クライアント1
においてトランザクション要求から応答までの最大待ち
時間を記憶するトランザクション処理閾時間記憶部、2
706は管理通信を処理する管理要求送受信部である.
なお,トランザクション要求送受信部2703は業務ク
ライアント1と後記の業務サ−バ2に設けられている.
ク図である.図において,2701は伝送路、1はトラ
ンザクション要求を発行する業務クライアント、270
3はトランザクション要求の処理を行うトランザクショ
ン要求送受信部、2704は業務クライアント1におけ
るトランザクション処理経過時間を計測するトランザク
ション処理時間検出部、2705は業務クライアント1
においてトランザクション要求から応答までの最大待ち
時間を記憶するトランザクション処理閾時間記憶部、2
706は管理通信を処理する管理要求送受信部である.
なお,トランザクション要求送受信部2703は業務ク
ライアント1と後記の業務サ−バ2に設けられている.
【0165】2はトランザクション要求を処理する業務
サーバ、2706は管理情報を送受信する管理要求送受
信部,2708はトランザクション要求を処理するトラ
ンザクション処理部、2709は業務サーバ2の管理情
報を収集する管理情報収集部である.2710は業務サ
ーバと業務クライアントを監視する負荷監視マネージャ
であり,その中の2711は業務クライアントを管理す
るクライアント管理部、2712は業務サーバを管理す
るサーバ管理部、2713はクライアント管理部271
1の管理情報とサーバ管理部2712の管理情報を統括
するクライアント・サーバ統括管理部である。
サーバ、2706は管理情報を送受信する管理要求送受
信部,2708はトランザクション要求を処理するトラ
ンザクション処理部、2709は業務サーバ2の管理情
報を収集する管理情報収集部である.2710は業務サ
ーバと業務クライアントを監視する負荷監視マネージャ
であり,その中の2711は業務クライアントを管理す
るクライアント管理部、2712は業務サーバを管理す
るサーバ管理部、2713はクライアント管理部271
1の管理情報とサーバ管理部2712の管理情報を統括
するクライアント・サーバ統括管理部である。
【0166】図32は業務サーバ2における動作を示す
フローチャートを示す。図33は、業務クライアント1
における動作を示すフローチャートを示す。図34は、
負荷監視マネージャ2710における動作を示すフロー
チャートを示す。
フローチャートを示す。図33は、業務クライアント1
における動作を示すフローチャートを示す。図34は、
負荷監視マネージャ2710における動作を示すフロー
チャートを示す。
【0167】業務クライアント1と業務サーバ2、負荷
監視マネージャ2710は、伝送路2701を介して通
信を行う。
監視マネージャ2710は、伝送路2701を介して通
信を行う。
【0168】図33において,業務クライアント1は、
予めトランザクション処理閾時間記憶部2705にトラ
ンザクション要求を発行してから応答が返ってくるまで
の最大待ち時間を記憶している(ステップ2901)。
予めトランザクション処理閾時間記憶部2705にトラ
ンザクション要求を発行してから応答が返ってくるまで
の最大待ち時間を記憶している(ステップ2901)。
【0169】業務クライアント1は、トランザクション
要求送受信部2703からトランザクション要求を業務
サーバ2に発行すると同時に、トランザクション処理時
間検出部2704がトランザクション要求発行時刻から
の経過時間の測定を開始する(ステップ2902)。
要求送受信部2703からトランザクション要求を業務
サーバ2に発行すると同時に、トランザクション処理時
間検出部2704がトランザクション要求発行時刻から
の経過時間の測定を開始する(ステップ2902)。
【0170】トランザクション処理閾時間記憶部270
5に記憶された最大待ち時間以内に応答が返ってこなか
った場合は、管理要求送受信部2703を介して負荷監
視マネージャ2710に処理遅延を報告する(ステップ
2903,2904)。なお,処理遅延の場合監視マネ
−ジャ2710への報告以外に,例えばユ−ザの指示待
ち,中断など任意の処理,制御をするように出来ること
はいう迄もない.
5に記憶された最大待ち時間以内に応答が返ってこなか
った場合は、管理要求送受信部2703を介して負荷監
視マネージャ2710に処理遅延を報告する(ステップ
2903,2904)。なお,処理遅延の場合監視マネ
−ジャ2710への報告以外に,例えばユ−ザの指示待
ち,中断など任意の処理,制御をするように出来ること
はいう迄もない.
【0171】次ぎに図32において,業務サーバ2は、
業務クライアント1からのトランザクション要求をトラ
ンザクション要求送受信部2703にて受信し、トラン
ザクション処理部2708がトランザクション要求を処
理する。
業務クライアント1からのトランザクション要求をトラ
ンザクション要求送受信部2703にて受信し、トラン
ザクション処理部2708がトランザクション要求を処
理する。
【0172】また、業務サーバ2は、定期的に管理情報
収集部2709がトランザクション処理部2708とト
ランザクション要求送受信部2703から要求処理負荷
の発生と処理状況などに関する管理情報を収集しており
(ステップ2801)、負荷監視マネージャ2710か
ら管理情報収集要求を受信すると(ステップ280
2)、管理要求送受信部2706を介して管理情報を応
答する(ステップ2803)。
収集部2709がトランザクション処理部2708とト
ランザクション要求送受信部2703から要求処理負荷
の発生と処理状況などに関する管理情報を収集しており
(ステップ2801)、負荷監視マネージャ2710か
ら管理情報収集要求を受信すると(ステップ280
2)、管理要求送受信部2706を介して管理情報を応
答する(ステップ2803)。
【0173】負荷監視マネージャ2710は、ポーリン
グによって業務サーバ2を管理し、図33のステップ2
904のようなイベントによって業務クライアント1を
管理する。
グによって業務サーバ2を管理し、図33のステップ2
904のようなイベントによって業務クライアント1を
管理する。
【0174】図34において,サーバ管理部2712
は、管理要求送受信部2706を介して業務サーバ2に
管理情報収集要求(ポーリング)を行なう.(ステップ
3001)。ポーリングの時間間隔はクライアント・サ
−バ統轄管理部2713がポーリングによって得られた
業務サーバの負荷傾向を分析することによってポーリン
グの時間間隔を学習的に最適化する。すなわち、ポーリ
ングによって得られた負荷の変動が小さい場合にはポー
リングの時間間隔を大きくし、逆に変動が大きい場合に
は時間間隔を小さくして負荷状況を頻繁に監視すること
により、ポーリングの時間間隔を最適化する。なお、ポ
ーリングの時間間隔には、システム起動時に予め規定値
を設定してもよい.
は、管理要求送受信部2706を介して業務サーバ2に
管理情報収集要求(ポーリング)を行なう.(ステップ
3001)。ポーリングの時間間隔はクライアント・サ
−バ統轄管理部2713がポーリングによって得られた
業務サーバの負荷傾向を分析することによってポーリン
グの時間間隔を学習的に最適化する。すなわち、ポーリ
ングによって得られた負荷の変動が小さい場合にはポー
リングの時間間隔を大きくし、逆に変動が大きい場合に
は時間間隔を小さくして負荷状況を頻繁に監視すること
により、ポーリングの時間間隔を最適化する。なお、ポ
ーリングの時間間隔には、システム起動時に予め規定値
を設定してもよい.
【0175】クライアント管理部2711は、業務クラ
イアント1から非同期に送信される管理報告を管理要求
送受信部2706を介して受信する。
イアント1から非同期に送信される管理報告を管理要求
送受信部2706を介して受信する。
【0176】ポーリングの結果、業務サーバ1に異常が
発見され、クライアント管理部2711において管理報
告を受信した時は、クライアント・サーバ統括管理部2
713は、業務サーバ2に障害が発生したと判断する
(ステップ3002,3003,3004)。
発見され、クライアント管理部2711において管理報
告を受信した時は、クライアント・サーバ統括管理部2
713は、業務サーバ2に障害が発生したと判断する
(ステップ3002,3003,3004)。
【0177】ポーリングの結果、業務サーバ2に異常が
発見され、クライアント管理部2711において管理報
告を受信していないときは、クライアント・サーバ統括
管理部2713は、業務サーバ2707および伝送路2
701に障害が発生したと判別する(ステップ300
2,3003,3005)。
発見され、クライアント管理部2711において管理報
告を受信していないときは、クライアント・サーバ統括
管理部2713は、業務サーバ2707および伝送路2
701に障害が発生したと判別する(ステップ300
2,3003,3005)。
【0178】ポーリングの結果、業務サーバ2に異常が
発見されず、クライアント管理部2711において管理
報告を受信した時は、クライアント・サーバ統括管理部
2713は、伝送路2701に障害が発生したと判別す
る(ステップ3002,3006,3007)。
発見されず、クライアント管理部2711において管理
報告を受信した時は、クライアント・サーバ統括管理部
2713は、伝送路2701に障害が発生したと判別す
る(ステップ3002,3006,3007)。
【0179】上記以外の場合は、クライアント・サーバ
統括管理部2713は、システムが正常であると判断す
る。このように、業務クライアント1からマネージャへ
高負荷検出のイベントを送信して業務サーバ2の負荷状
況を監視することができるので、業務サーバ2に対する
ポーリング間隔を短くしなくても業務サーバ2の負荷を
迅速に検出することが可能になり、さらに業務クライア
ント1と業務サーバ2間のネットワークの障害も検出す
ることもできる。この様にして,負荷増に伴うトランザ
クション処理の障害を未然に防止対策をとることができ
る.
統括管理部2713は、システムが正常であると判断す
る。このように、業務クライアント1からマネージャへ
高負荷検出のイベントを送信して業務サーバ2の負荷状
況を監視することができるので、業務サーバ2に対する
ポーリング間隔を短くしなくても業務サーバ2の負荷を
迅速に検出することが可能になり、さらに業務クライア
ント1と業務サーバ2間のネットワークの障害も検出す
ることもできる。この様にして,負荷増に伴うトランザ
クション処理の障害を未然に防止対策をとることができ
る.
【0180】以上のように第10,11の発明によれ
ば、業務サーバにポーリングをかけて管理情報収集する
と共に、業務クライアントから最大待ち時間の経過を報
告させることによって、負荷増大の原因が業務サーバに
あるのか、業務クライアントにあるのか、中継する伝送
路にあるかを判別することが可能となり、速やかに負荷
増大への対処を施すことができるという効果がある。
ば、業務サーバにポーリングをかけて管理情報収集する
と共に、業務クライアントから最大待ち時間の経過を報
告させることによって、負荷増大の原因が業務サーバに
あるのか、業務クライアントにあるのか、中継する伝送
路にあるかを判別することが可能となり、速やかに負荷
増大への対処を施すことができるという効果がある。
【0181】実施例10.本実施例10は本発明の第1
2の実施例である.以下,図35〜40を参照して説明
する.
2の実施例である.以下,図35〜40を参照して説明
する.
【0182】本実施例は,従来の技術と異なり,業務サ
ーバプロセスを増減するのに負荷情報を常時収集しない
で負荷分散するものである。
ーバプロセスを増減するのに負荷情報を常時収集しない
で負荷分散するものである。
【0183】図35は本発明の第12の発明における一
実施例の構成を示したものである。図において、310
1はマネージャである。その内部の3102はマネージ
ャ3101の管理情報を入出力する手段を持つマネージ
ャ管理情報入出力処理部、3103は業務サーバプロセ
スを起動する手段を持つサーバ起動部、3104は業務
クライアントからの要求を業務サーバプロセスに振り分
ける手段を持つサーバ振り分け処理部、3105は通信
を行う手段を持つ通信処理部である。
実施例の構成を示したものである。図において、310
1はマネージャである。その内部の3102はマネージ
ャ3101の管理情報を入出力する手段を持つマネージ
ャ管理情報入出力処理部、3103は業務サーバプロセ
スを起動する手段を持つサーバ起動部、3104は業務
クライアントからの要求を業務サーバプロセスに振り分
ける手段を持つサーバ振り分け処理部、3105は通信
を行う手段を持つ通信処理部である。
【0184】2は業務サーバである。3116は業務サ
−バプロセスで,それは次ぎにより構成される.即ち,
3112はサーバの負荷状態を知り,高負荷判定基準を
持つ負荷監視部、3113は業務クライアントの要求の
処理を行う手段を持つクライアント要求処理部、311
4はサーバの自己消去を行う手段を持つ自己消去部、3
115は通信する手段を持つ通信処理部である。なお,
業務サ−バ2は図35では1台であるが,複数でもよ
い.
−バプロセスで,それは次ぎにより構成される.即ち,
3112はサーバの負荷状態を知り,高負荷判定基準を
持つ負荷監視部、3113は業務クライアントの要求の
処理を行う手段を持つクライアント要求処理部、311
4はサーバの自己消去を行う手段を持つ自己消去部、3
115は通信する手段を持つ通信処理部である。なお,
業務サ−バ2は図35では1台であるが,複数でもよ
い.
【0185】1は業務クライアントである。その内部の
3122はクライアント処理を行う手段を持つクライア
ント処理部、3123は通信する手段を持つ通信処理部
である。図35では1台であるが,複数でもよい.図3
6はマネ−ジャ3101のサ−バ振り分け処理部310
4内のサ−バプロセス管理テ−ブルcの構成を示し,そ
れを構成するものがプロセス名3151,作成条件31
52(例えば,1度に作成のプロセス数他),高負荷を
決定する条件3153(例えば,トランザクションのキ
ュ−の数,高負荷と判定する基準ロ−ドなど他),自己
消去する条件3154(例えば,作成後消去する時間
他),登録されたサ−バプロセスのアドレス3155な
どである.なお,登録されたサ−バプロセスのアドレス
3155には生成されている業務サ−バプロセス311
6のアドレスが書き込まれる.図37はマネ−ジャ31
01の振り分けテ−ブル3160の構成でプロセス名3
161,振り分けを再開する時刻3162よりなる.な
お,時刻を測定する手段は構成図に図示していないが,
業務サ−バプロセス3116,マネ−ジャ3101は共
にこれをもっている.
3122はクライアント処理を行う手段を持つクライア
ント処理部、3123は通信する手段を持つ通信処理部
である。図35では1台であるが,複数でもよい.図3
6はマネ−ジャ3101のサ−バ振り分け処理部310
4内のサ−バプロセス管理テ−ブルcの構成を示し,そ
れを構成するものがプロセス名3151,作成条件31
52(例えば,1度に作成のプロセス数他),高負荷を
決定する条件3153(例えば,トランザクションのキ
ュ−の数,高負荷と判定する基準ロ−ドなど他),自己
消去する条件3154(例えば,作成後消去する時間
他),登録されたサ−バプロセスのアドレス3155な
どである.なお,登録されたサ−バプロセスのアドレス
3155には生成されている業務サ−バプロセス311
6のアドレスが書き込まれる.図37はマネ−ジャ31
01の振り分けテ−ブル3160の構成でプロセス名3
161,振り分けを再開する時刻3162よりなる.な
お,時刻を測定する手段は構成図に図示していないが,
業務サ−バプロセス3116,マネ−ジャ3101は共
にこれをもっている.
【0186】次に上記実施例の動作を図36,37,3
8,39,40を参照しながら説明する。図38はマネ
ージャ3101の、図39は業務サーバプロセス311
6の、図40は業務クライアント1のフローチャートで
ある。マネージャ3101の動作、業務サーバプロセス
3116の動作、業務クライアント1の動作の順に説明
する。
8,39,40を参照しながら説明する。図38はマネ
ージャ3101の、図39は業務サーバプロセス311
6の、図40は業務クライアント1のフローチャートで
ある。マネージャ3101の動作、業務サーバプロセス
3116の動作、業務クライアント1の動作の順に説明
する。
【0187】マネージャ3101の動作について説明す
る。初期化、業務サーバプロセス3116から受信した
時の動作、業務クライアント1から受信したときの動作
の順に説明する。
る。初期化、業務サーバプロセス3116から受信した
時の動作、業務クライアント1から受信したときの動作
の順に説明する。
【0188】図38において,マネージャ3101の初
期化の動作について説明する(ステップ3202)。マ
ネージャ3101は起動時に、マネージャ管理情報入出
力処理部3102より、新たに業務サーバプロセス31
16を作成し実行可能状態にするよう要求があった場
合,それを作る条件(例えば作成する個数)、サーバが
高負荷と判定する条件(例えばCPUのロードアベレー
ジ、トランザクションの発生数)、新たに発生する業務
サーバプロセス3116が自己消去する条件(例えば決
められた一定の時間が経過したら自己消去する)を入力
し,図36のプロセス管理テーブルc 3150をサ−
バ振り分け処理部3104に設定する。これらの条件は
マネージャ管理情報入出力部3102により変更でき
る。なおマネージャ管理情報入出力部3102によりこ
れらの条件や各部状況を出力できる(ステップ320
2)。
期化の動作について説明する(ステップ3202)。マ
ネージャ3101は起動時に、マネージャ管理情報入出
力処理部3102より、新たに業務サーバプロセス31
16を作成し実行可能状態にするよう要求があった場
合,それを作る条件(例えば作成する個数)、サーバが
高負荷と判定する条件(例えばCPUのロードアベレー
ジ、トランザクションの発生数)、新たに発生する業務
サーバプロセス3116が自己消去する条件(例えば決
められた一定の時間が経過したら自己消去する)を入力
し,図36のプロセス管理テーブルc 3150をサ−
バ振り分け処理部3104に設定する。これらの条件は
マネージャ管理情報入出力部3102により変更でき
る。なおマネージャ管理情報入出力部3102によりこ
れらの条件や各部状況を出力できる(ステップ320
2)。
【0189】マネージャ3101が業務クライアント1
から受信した時の動作について説明する。マネージャ3
101の通信処理部3105が業務クライアント1から
受信したら(ステップ3203)、その内容をサーバ振
り分け処理部3104に渡す。振り分け処理部3104
はプロセス管理テ−ブルc 3150のプロセス名31
51によりアクセスできる業務サーバプロセス3116
が登録されているか確認する(ステップ3204)。
から受信した時の動作について説明する。マネージャ3
101の通信処理部3105が業務クライアント1から
受信したら(ステップ3203)、その内容をサーバ振
り分け処理部3104に渡す。振り分け処理部3104
はプロセス管理テ−ブルc 3150のプロセス名31
51によりアクセスできる業務サーバプロセス3116
が登録されているか確認する(ステップ3204)。
【0190】登録されていれば、登録されている業務サ
ーバプロセス3116からランダムに選択し業務クライ
アント1に通知する(ステップ3206)。
ーバプロセス3116からランダムに選択し業務クライ
アント1に通知する(ステップ3206)。
【0191】登録されていない場合(ステップ320
4)は、サーバ起動部3103に業務サーバプロセス3
116を起動することを要求する。サーバ起動部310
3は業務サーバプロセス3116に存在できる時間,自
己消去する条件3154と高負荷を決定する条件315
4を与えて起動を業務サ−バ2に対して起動をかける.
起動をかけた業務サ−バプロセス3116のアドレスを
受信し,マネ−ジャ管理情報入出力処理部3102,振
り分け処理部3104はそのアドレスをプロセス管理テ
−ブルc 3150の登録されたサ−バプロセスのアド
レス3155に登録する(ステップ3205)。そして
業務クライアント1に通信処理部3105を用いて通知
する(ステップ3206)。
4)は、サーバ起動部3103に業務サーバプロセス3
116を起動することを要求する。サーバ起動部310
3は業務サーバプロセス3116に存在できる時間,自
己消去する条件3154と高負荷を決定する条件315
4を与えて起動を業務サ−バ2に対して起動をかける.
起動をかけた業務サ−バプロセス3116のアドレスを
受信し,マネ−ジャ管理情報入出力処理部3102,振
り分け処理部3104はそのアドレスをプロセス管理テ
−ブルc 3150の登録されたサ−バプロセスのアド
レス3155に登録する(ステップ3205)。そして
業務クライアント1に通信処理部3105を用いて通知
する(ステップ3206)。
【0192】次ぎに,マネージャ3101が業務サーバ
プロセス3116から受信したときの動作について説明
する(ステップ3203)。マネージャ3101の通信
処理部3105は業務サ−バプロセス3116の要求を
受信するとサーバ振り分け処理部3104に渡す。
プロセス3116から受信したときの動作について説明
する(ステップ3203)。マネージャ3101の通信
処理部3105は業務サ−バプロセス3116の要求を
受信するとサーバ振り分け処理部3104に渡す。
【0193】もし処理依頼が消去であれば(ステップ3
207)、サーバ振り分け処理部3104はその業務サ
ーバプロセス3116の登録をプロセス管理テ−ブルc
3150から解除し、解除したことを通信処理部31
05を使用し業務サーバプロセス3116に通知する
(ステップ3208)。
207)、サーバ振り分け処理部3104はその業務サ
ーバプロセス3116の登録をプロセス管理テ−ブルc
3150から解除し、解除したことを通信処理部31
05を使用し業務サーバプロセス3116に通知する
(ステップ3208)。
【0194】もし依頼内容が起動であれば(ステップ3
207)、サーバ振り分け処理部3104はサーバ起動
部3103を使用し、新たな業務サーバプロセス311
6を存在する時間の条件即ち,自己消去する条件と高負
荷を判断する条件を与え起動する。起動された業務サ−
バプロセス3116のアドレスを受信し,サーバ振り分
け処理部3104はそのアドレスを登録されたサ−バプ
ロセスのアドレス3155に登録する(ステップ320
9)。
207)、サーバ振り分け処理部3104はサーバ起動
部3103を使用し、新たな業務サーバプロセス311
6を存在する時間の条件即ち,自己消去する条件と高負
荷を判断する条件を与え起動する。起動された業務サ−
バプロセス3116のアドレスを受信し,サーバ振り分
け処理部3104はそのアドレスを登録されたサ−バプ
ロセスのアドレス3155に登録する(ステップ320
9)。
【0195】次に業務サーバプロセス3116の動作に
ついて説明する。初期化、業務クライアント1の処理要
求を受信した時の動作、負荷が高いときの動作、自己消
去条件を満たしたときの動作の順に説明する。
ついて説明する。初期化、業務クライアント1の処理要
求を受信した時の動作、負荷が高いときの動作、自己消
去条件を満たしたときの動作の順に説明する。
【0196】図39において,初期化ではマネージャ3
101に自己消去する条件と高負荷を判断する条件をサ
−バ振り分け処理部3104から与えられ起動される
(ステップ3302)。
101に自己消去する条件と高負荷を判断する条件をサ
−バ振り分け処理部3104から与えられ起動される
(ステップ3302)。
【0197】業務クライアント1の処理要求を受信した
ときの動作について説明する(ステップ3303)。業
務クライアント1より処理要求を受信すると業務サーバ
プロセス3116は、クライアント要求処理部3113
に渡し要求を処理する(ステップ3304)。業務クラ
イアント1へ処理結果を返信する(ステップ330
5)。
ときの動作について説明する(ステップ3303)。業
務クライアント1より処理要求を受信すると業務サーバ
プロセス3116は、クライアント要求処理部3113
に渡し要求を処理する(ステップ3304)。業務クラ
イアント1へ処理結果を返信する(ステップ330
5)。
【0198】業務サーバプロセス3116が高負荷にな
った時の動作を説明する。業務サーバプロセス3116
は負荷監視部3112から得た負荷が高負荷の判定条件
を満たしたら(ステップ3306)、通信処理部311
5を使用してマネージャ3101に新たな業務サーバプ
ロセス3116の作成を要求し,図38のステップ32
09の処理がなされる(ステップ3307)。
った時の動作を説明する。業務サーバプロセス3116
は負荷監視部3112から得た負荷が高負荷の判定条件
を満たしたら(ステップ3306)、通信処理部311
5を使用してマネージャ3101に新たな業務サーバプ
ロセス3116の作成を要求し,図38のステップ32
09の処理がなされる(ステップ3307)。
【0199】業務サーバプロセス3116が自己消去す
る時の動作について説明する。業務サーバプロセス31
16は自己消去する条件3154を満たすと(ステップ
3308)、マネージャ3101に自己消去することを
通知し返信を得る(ステップ3309)。なお,この時
マネ−ジャ3101は図38のステップ3208の処理
をする.そして業務サーバプロセス3116は自己消去
部3114を使用し自己消去する(ステップ331
0)。
る時の動作について説明する。業務サーバプロセス31
16は自己消去する条件3154を満たすと(ステップ
3308)、マネージャ3101に自己消去することを
通知し返信を得る(ステップ3309)。なお,この時
マネ−ジャ3101は図38のステップ3208の処理
をする.そして業務サーバプロセス3116は自己消去
部3114を使用し自己消去する(ステップ331
0)。
【0200】なおフローチャート図39では、業務クラ
イアント1の処理要求を受信した時の動作、負荷が高い
時の動作、自己消去条件を満たした時の動作の順に説明
しているが、この順番は変更してもよい。
イアント1の処理要求を受信した時の動作、負荷が高い
時の動作、自己消去条件を満たした時の動作の順に説明
しているが、この順番は変更してもよい。
【0201】次に業務クライアント1の動作について図
40により説明する。業務クライアント1はマネージャ
3101のアドレス情報を得るなどの初期化を行う(ス
テップ3402)。クライアント処理部3122は業務
サーバプロセス3116に処理を要求する場合、通信処
理部3123を用い、どの業務サーバプロセス3116
にアクセスするか情報を得るため、まずマネージャ31
01にアクセスし情報を得る(ステップ3403)。こ
の時,マネ−ジャ3101は図38のステップ3204
〜3206の処理をする.業務クライアント1はその業
務サーバプロセス3116に通信処理部3123を用い
てアクセスする(ステップ3404)。
40により説明する。業務クライアント1はマネージャ
3101のアドレス情報を得るなどの初期化を行う(ス
テップ3402)。クライアント処理部3122は業務
サーバプロセス3116に処理を要求する場合、通信処
理部3123を用い、どの業務サーバプロセス3116
にアクセスするか情報を得るため、まずマネージャ31
01にアクセスし情報を得る(ステップ3403)。こ
の時,マネ−ジャ3101は図38のステップ3204
〜3206の処理をする.業務クライアント1はその業
務サーバプロセス3116に通信処理部3123を用い
てアクセスする(ステップ3404)。
【0202】このようにすることにより、従来のように
業務サーバプロセス3111を増減するのに負荷情報を
常時、収集することがないのでマネージャ3101や業
務サーバプロセス2に負荷を軽くし、また通信トラフィ
ック量も小さくでき、負荷分散ができる。
業務サーバプロセス3111を増減するのに負荷情報を
常時、収集することがないのでマネージャ3101や業
務サーバプロセス2に負荷を軽くし、また通信トラフィ
ック量も小さくでき、負荷分散ができる。
【0203】上記実施例ではランダムに業務サーバプロ
セス3116を振り分けた。しかし、新しい業務サーバ
プロセス3116ほどキューに溜っているトランザクシ
ョンの数が少ないと考えられるので、負荷の低い新しい
業務サーバプロセス3116ほど振り分ける確率を高く
すると,より良い負荷分散ができる。
セス3116を振り分けた。しかし、新しい業務サーバ
プロセス3116ほどキューに溜っているトランザクシ
ョンの数が少ないと考えられるので、負荷の低い新しい
業務サーバプロセス3116ほど振り分ける確率を高く
すると,より良い負荷分散ができる。
【0204】上記実施例ではランダムに業務サーバプロ
セス3116を振り分けたが、新しい業務サーバプロセ
ス3116bを作ることを要求した業務サーバプロセス
3116aには指定された時間の間、業務クライアント
1の要求を振り分けない方法をとることにより、きめ細
かく実効を上げより良い負荷分散ができる。即ち,業務
サ−バプロセスプロセス3116aは通常高負荷である
ため,新しい業務サ−バプロセス3116bの作成を要
求する.このため,指定時間内は業務サ−バプロセス3
116aへの業務クライアント1の要求振り分けを保留
し,負荷の増大を抑える.具体的にはマネージャ310
1のサ−バ振分処理部3104が図37の振り分けテー
ブル3160を持つ。業務サーバプロセス3116aか
ら新たな業務サーバプロセス3116bを作るように要
求があったらマネージャ3101は現在時刻にあらかじ
め決められた一定の時間を加えてテーブルに書き込みそ
れを振り分け再開時刻とする。振り分ける時、そのプロ
セス3116aが振り分け再開時刻を経過していなけれ
ばそれに振り分けずに他の業務サーバプロセス3116
bに振り分ける。このようにすることにより、新しく作
成し,未だ負荷の低い業務サーバプロセス3116bに
負荷を分散できる。
セス3116を振り分けたが、新しい業務サーバプロセ
ス3116bを作ることを要求した業務サーバプロセス
3116aには指定された時間の間、業務クライアント
1の要求を振り分けない方法をとることにより、きめ細
かく実効を上げより良い負荷分散ができる。即ち,業務
サ−バプロセスプロセス3116aは通常高負荷である
ため,新しい業務サ−バプロセス3116bの作成を要
求する.このため,指定時間内は業務サ−バプロセス3
116aへの業務クライアント1の要求振り分けを保留
し,負荷の増大を抑える.具体的にはマネージャ310
1のサ−バ振分処理部3104が図37の振り分けテー
ブル3160を持つ。業務サーバプロセス3116aか
ら新たな業務サーバプロセス3116bを作るように要
求があったらマネージャ3101は現在時刻にあらかじ
め決められた一定の時間を加えてテーブルに書き込みそ
れを振り分け再開時刻とする。振り分ける時、そのプロ
セス3116aが振り分け再開時刻を経過していなけれ
ばそれに振り分けずに他の業務サーバプロセス3116
bに振り分ける。このようにすることにより、新しく作
成し,未だ負荷の低い業務サーバプロセス3116bに
負荷を分散できる。
【0205】上記実施例の新たな業務サーバプロセス3
116が消去する条件としては、ある一定時間後に自己
消去、トランザクションをある回数だけ実行後に自己消
去する、トランザクション処理を受け付けなくなってか
ら一定時間後に自己消去するなどの条件がある。
116が消去する条件としては、ある一定時間後に自己
消去、トランザクションをある回数だけ実行後に自己消
去する、トランザクション処理を受け付けなくなってか
ら一定時間後に自己消去するなどの条件がある。
【0206】上記実施例では業務サーバプロセス311
6はある条件で自己消滅してしまうが、業務サーバプロ
セス3116がマネージャ3101に消去することを通
知する時に負荷監視部3112から得た負荷が高いとき
はそれも併せて通知し,マネージャ3101のサーバ振
り分け処理部3104が業務サーバプロセス3116の
存在時間を延長することを通信処理部3115を用いて
業務サーバプロセス3116に通知するようにしてもよ
い。この方法をとると負荷が高い状態が続くとき、業務
サーバプロセス3116が自動的に消去され再立ち上げ
をするための無駄な時間を減らすことができる。
6はある条件で自己消滅してしまうが、業務サーバプロ
セス3116がマネージャ3101に消去することを通
知する時に負荷監視部3112から得た負荷が高いとき
はそれも併せて通知し,マネージャ3101のサーバ振
り分け処理部3104が業務サーバプロセス3116の
存在時間を延長することを通信処理部3115を用いて
業務サーバプロセス3116に通知するようにしてもよ
い。この方法をとると負荷が高い状態が続くとき、業務
サーバプロセス3116が自動的に消去され再立ち上げ
をするための無駄な時間を減らすことができる。
【0207】以上のように第12の発明によれば、従来
と違い負荷情報を常に収集しなくても、サーバプロセス
の数を増減し、適度に負荷を分散できるので負荷が増大
してもシステムの障害を抑制する効果がある。
と違い負荷情報を常に収集しなくても、サーバプロセス
の数を増減し、適度に負荷を分散できるので負荷が増大
してもシステムの障害を抑制する効果がある。
【0208】実施例11.本発明の第13の発明の1実
施例である実施例11を図41〜45を用いて説明す
る.本実施例のポイントは負荷情報を収集するためのマ
ネージャやサーバの負荷とトラフィック量も減らすこと
と、サーバの負荷が高い時業務クライアントのサーバへ
のアクセスを減らし負荷分散を行うことにある。
施例である実施例11を図41〜45を用いて説明す
る.本実施例のポイントは負荷情報を収集するためのマ
ネージャやサーバの負荷とトラフィック量も減らすこと
と、サーバの負荷が高い時業務クライアントのサーバへ
のアクセスを減らし負荷分散を行うことにある。
【0209】図41は第13の発明における一実施例を
示したものである。図において、3501はアクセス制
御装置である。その内部の3502はアクセス制御装置
の管理情報を入出力する手段を持つアクセス制御管理情
報入出力処理部、3503はアクセス制御を行う手段を
持つアクセス制御処理部、3504は通信を行う手段を
持つ通信処理部である。
示したものである。図において、3501はアクセス制
御装置である。その内部の3502はアクセス制御装置
の管理情報を入出力する手段を持つアクセス制御管理情
報入出力処理部、3503はアクセス制御を行う手段を
持つアクセス制御処理部、3504は通信を行う手段を
持つ通信処理部である。
【0210】2は業務サーバである。その内部の351
2は業務サーバの管理情報を入出力する手段を持つサー
バ管理情報入出力処理部、3513は業務サーバの負荷
状態を知る手段を持つ負荷監視部、3514は業務クラ
イアントへアクセス権の付与を決定する手段を持つアク
セス権付与決定部、3515は業務クライアントの要求
の処理を行う手段を持つクライアント要求処理部、35
16は通信する手段を持つ通信処理部である。1は業務
クライアントである。その内部は3522は業務クライ
アント処理を行う手段を持つクライアント処理部、35
23は通信する手段を持つ通信処理部である。図42は
業務サ−バ2のサ−バ管理情報入出力処理部3512の
アクセス制御テ−ブル3550の構成を示す.
2は業務サーバの管理情報を入出力する手段を持つサー
バ管理情報入出力処理部、3513は業務サーバの負荷
状態を知る手段を持つ負荷監視部、3514は業務クラ
イアントへアクセス権の付与を決定する手段を持つアク
セス権付与決定部、3515は業務クライアントの要求
の処理を行う手段を持つクライアント要求処理部、35
16は通信する手段を持つ通信処理部である。1は業務
クライアントである。その内部は3522は業務クライ
アント処理を行う手段を持つクライアント処理部、35
23は通信する手段を持つ通信処理部である。図42は
業務サ−バ2のサ−バ管理情報入出力処理部3512の
アクセス制御テ−ブル3550の構成を示す.
【0211】次に上記実施例の動作を図43,44,4
5を参照しながら説明する。図43はアクセス制御装置
3501の、図44は業務サーバ2の、図45 は業務
クライアント1のフローチャートである。アクセス制御
装置3501の動作、業務サーバ2の動作、業務クライ
アント1の動作の順に説明する。
5を参照しながら説明する。図43はアクセス制御装置
3501の、図44は業務サーバ2の、図45 は業務
クライアント1のフローチャートである。アクセス制御
装置3501の動作、業務サーバ2の動作、業務クライ
アント1の動作の順に説明する。
【0212】まず、図43によりアクセス制御装置35
01の動作について説明する。アクセス制御装置350
1の通信処理部3504が業務クライアント1から受信
したら(ステップ3602)、その内容をアクセス制御
処理部3503に渡す。アクセス制御処理部3503は
業務クライアント1がどの業務サーバ2にアクセスでき
るかを調べる。その結果、アクセスできる業務サーバ2
があれば(ステップ3603)、当該業務サ−バ2にア
クセスできることを証明する証明チケットを業務クライ
アント1に通信処理部3504を用いて送信する(ステ
ップ3604)。アクセスできる業務サーバ2がなけれ
ば(ステップ3603)、アクセスできる業務サ−バ2
はないことを業務クライアント1に送信しる(ステップ
3605)。
01の動作について説明する。アクセス制御装置350
1の通信処理部3504が業務クライアント1から受信
したら(ステップ3602)、その内容をアクセス制御
処理部3503に渡す。アクセス制御処理部3503は
業務クライアント1がどの業務サーバ2にアクセスでき
るかを調べる。その結果、アクセスできる業務サーバ2
があれば(ステップ3603)、当該業務サ−バ2にア
クセスできることを証明する証明チケットを業務クライ
アント1に通信処理部3504を用いて送信する(ステ
ップ3604)。アクセスできる業務サーバ2がなけれ
ば(ステップ3603)、アクセスできる業務サ−バ2
はないことを業務クライアント1に送信しる(ステップ
3605)。
【0213】もし業務サーバ2から受信したら(ステッ
プ3602)、アクセス制御装置3501の通信処理部
3504はアクセス制御処理部3503にその情報を渡
す。アクセス制御処理部3503はその業務サーバ2に
アクセスできる業務クライアント1を変更する(ステッ
プ3606)。この変更処理は次ぎに詳述する.
プ3602)、アクセス制御装置3501の通信処理部
3504はアクセス制御処理部3503にその情報を渡
す。アクセス制御処理部3503はその業務サーバ2に
アクセスできる業務クライアント1を変更する(ステッ
プ3606)。この変更処理は次ぎに詳述する.
【0214】次に業務サーバ2の動作について図44,
42を用いて説明する。初期化、業務クライアント1の
処理要求を受信したときの動作、アクセスできる業務ク
ライアント1の範囲を変更するときの動作の順に説明す
る。
42を用いて説明する。初期化、業務クライアント1の
処理要求を受信したときの動作、アクセスできる業務ク
ライアント1の範囲を変更するときの動作の順に説明す
る。
【0215】業務サーバ2の初期化(ステップ370
2)について,業務サーバ2はサーバ管理情報入出力処
理部3512内で、図42に示すアクセス制御テーブル
3550の業務クライアント1のアクセスの優先順位が
入力設定される。即ち,図のサ−バ名3551毎にクラ
イアントのアクセス優先順位3552と,負荷の程度に
応じてアクセス出来る業務クライアント1の範囲を示す
負荷3553が入力される.その情報をアクセス権付与
決定部3514におくる。なお,サーバ管理情報入出力
部3512によりこれらの条件や各部状況を出力でき
る。
2)について,業務サーバ2はサーバ管理情報入出力処
理部3512内で、図42に示すアクセス制御テーブル
3550の業務クライアント1のアクセスの優先順位が
入力設定される。即ち,図のサ−バ名3551毎にクラ
イアントのアクセス優先順位3552と,負荷の程度に
応じてアクセス出来る業務クライアント1の範囲を示す
負荷3553が入力される.その情報をアクセス権付与
決定部3514におくる。なお,サーバ管理情報入出力
部3512によりこれらの条件や各部状況を出力でき
る。
【0216】業務サーバ2は通信処理部3516が業務
クライアント1からの要求を受け取ったら(ステップ3
703)、クライアント要求処理部3515に渡す。ク
ライアント処理部3515では証明チケットが正しいか
を確認し、正しければ(ステップ3704)業務クライ
アント1の要求を処理し(ステップ3705)、クライ
アントへ処理結果を返信する(ステップ3706)。証
明チケットが正しくなければ(ステップ3704)業務
クライアント1の要求処理を行わない。
クライアント1からの要求を受け取ったら(ステップ3
703)、クライアント要求処理部3515に渡す。ク
ライアント処理部3515では証明チケットが正しいか
を確認し、正しければ(ステップ3704)業務クライ
アント1の要求を処理し(ステップ3705)、クライ
アントへ処理結果を返信する(ステップ3706)。証
明チケットが正しくなければ(ステップ3704)業務
クライアント1の要求処理を行わない。
【0217】次に業務サーバ2が業務クライアント1に
アクセス権を付与する時の動作を説明する。業務サーバ
2のアクセス権付与決定部3514は負荷監視部351
3から負荷情報をもらう。その負荷情報とプロセス制御
テ−ブル3550が設定している負荷に応じてアクセス
できる業務クライアント1の条件により、アクセス権付
与決定部3514はアクセスできる業務クライアント1
を決定し(ステップ3707)、負荷の増減により業務
クライアント1のアクセス範囲に変更があれば(ステッ
プ3708)その情報を通信処理部3516を用いて、
アクセス制御装置3501に送る(ステップ370
9)。これは,図43のアクセス制御装置3501の動
作のステップ3606に繋がる.これにより,アクセス
制御装置3501が業務スライアント1からの要求に対
して正確に前記の証明チケットを発行する.
アクセス権を付与する時の動作を説明する。業務サーバ
2のアクセス権付与決定部3514は負荷監視部351
3から負荷情報をもらう。その負荷情報とプロセス制御
テ−ブル3550が設定している負荷に応じてアクセス
できる業務クライアント1の条件により、アクセス権付
与決定部3514はアクセスできる業務クライアント1
を決定し(ステップ3707)、負荷の増減により業務
クライアント1のアクセス範囲に変更があれば(ステッ
プ3708)その情報を通信処理部3516を用いて、
アクセス制御装置3501に送る(ステップ370
9)。これは,図43のアクセス制御装置3501の動
作のステップ3606に繋がる.これにより,アクセス
制御装置3501が業務スライアント1からの要求に対
して正確に前記の証明チケットを発行する.
【0218】なおフローチャート図44では、業務クラ
イアント1の処理要求を受信した時の動作、アクセスで
きる業務クライアント1の範囲を変更する時の動作の順
であるがこの順番は変更してもよい。
イアント1の処理要求を受信した時の動作、アクセスで
きる業務クライアント1の範囲を変更する時の動作の順
であるがこの順番は変更してもよい。
【0219】次に業務クライアント1の動作を図45に
より説明する。業務クライアント1はアクセス制御装置
3501のアドレスを得るなどの初期化作業を行う(ス
テップ3802)。クライアント処理部3522は業務
サーバ2に処理を要求する場合、通信処理部3521を
用いどの業務サーバ2にアクセスするかの情報を得るた
めまずアクセス制御装置3501にアクセスする(ステ
ップ3803)。そして業務クライアント1は証明チケ
ットを渡されたら、その業務サーバ2に通信処理部35
16を用いてアクセスする(ステップ3804)。
より説明する。業務クライアント1はアクセス制御装置
3501のアドレスを得るなどの初期化作業を行う(ス
テップ3802)。クライアント処理部3522は業務
サーバ2に処理を要求する場合、通信処理部3521を
用いどの業務サーバ2にアクセスするかの情報を得るた
めまずアクセス制御装置3501にアクセスする(ステ
ップ3803)。そして業務クライアント1は証明チケ
ットを渡されたら、その業務サーバ2に通信処理部35
16を用いてアクセスする(ステップ3804)。
【0220】このようにすることにより、業務サーバ2
は負荷が高い時は狭い範囲の業務クライアント1のみの
要求を受け付け、負荷が低いときは広い範囲の業務クラ
イアント1の要求を受け付ける。このため業務サーバ2
の負荷が高い時業務クライアント1の業務サーバ2への
アクセスを減らし負荷の低い業務サーバ2に負荷を分散
できる。また従来のように負荷情報を常に収集しないの
でアクセス制御装置3501や業務サーバ2の負荷とト
ラフィック量も減らすことができる。また、すべての業
務サーバ2の負荷が高い場合にも、業務クライアント1
からの要求を受け付けてしまうこともあったが、業務サ
ーバ2にアクセスする前にアクセス制御装置3501に
より割り当てられないため、業務サーバ2が業務クライ
アント1の要求を拒絶する作業の負荷がなくなった。こ
のようにして,トランザクション処理負荷が増大して
も,システムへの障害が未然に防げる.
は負荷が高い時は狭い範囲の業務クライアント1のみの
要求を受け付け、負荷が低いときは広い範囲の業務クラ
イアント1の要求を受け付ける。このため業務サーバ2
の負荷が高い時業務クライアント1の業務サーバ2への
アクセスを減らし負荷の低い業務サーバ2に負荷を分散
できる。また従来のように負荷情報を常に収集しないの
でアクセス制御装置3501や業務サーバ2の負荷とト
ラフィック量も減らすことができる。また、すべての業
務サーバ2の負荷が高い場合にも、業務クライアント1
からの要求を受け付けてしまうこともあったが、業務サ
ーバ2にアクセスする前にアクセス制御装置3501に
より割り当てられないため、業務サーバ2が業務クライ
アント1の要求を拒絶する作業の負荷がなくなった。こ
のようにして,トランザクション処理負荷が増大して
も,システムへの障害が未然に防げる.
【0221】上記実施例では、業務サーバ2と業務クラ
イアン1は各々1つの場合を考えたがそれぞれ複数あっ
ても構わない。
イアン1は各々1つの場合を考えたがそれぞれ複数あっ
ても構わない。
【0222】以上のように第13の発明によれば、従来
のものよりマネージャやサーバの負荷とトラフィック量
も減らして負荷分散ができる効果がある。
のものよりマネージャやサーバの負荷とトラフィック量
も減らして負荷分散ができる効果がある。
【0223】実施例12.本発明の第14の発明の実施
例12を図46〜47を用いて説明する.本実施例12
のポイントはユーザデータの少ない時間を使用して、軽
度な障害の情報、負荷分散を行うための負荷情報,管理
情報の詳細等を得ることにある。
例12を図46〜47を用いて説明する.本実施例12
のポイントはユーザデータの少ない時間を使用して、軽
度な障害の情報、負荷分散を行うための負荷情報,管理
情報の詳細等を得ることにある。
【0224】図46は本実施例の構成を示したものであ
る。図において、3901はデータ量制御装置である。
その内部の3902は各部の初期条件の設定や条件の変
更の情報を入出力する手段を持つ管理情報入出力部、3
903はデータを入力する手段を持つデータ入力部、3
904は入力されたデータの重要度を識別する手段を持
つ重要度識別部、3905はデータの時間あたりの数を
カウントする手段とデータカウント部、3906はデー
タを取捨選択する手段を持つデータ取捨選択部、390
7はデータを出力する手段を持つデータ出力部、390
8はデータ取捨選択部により捨てられたデータを廃棄す
る手段を持つデータ廃棄部である。
る。図において、3901はデータ量制御装置である。
その内部の3902は各部の初期条件の設定や条件の変
更の情報を入出力する手段を持つ管理情報入出力部、3
903はデータを入力する手段を持つデータ入力部、3
904は入力されたデータの重要度を識別する手段を持
つ重要度識別部、3905はデータの時間あたりの数を
カウントする手段とデータカウント部、3906はデー
タを取捨選択する手段を持つデータ取捨選択部、390
7はデータを出力する手段を持つデータ出力部、390
8はデータ取捨選択部により捨てられたデータを廃棄す
る手段を持つデータ廃棄部である。
【0225】次に上記実施例の動作を図47を参照しな
がら説明する。まず初期化について説明し、次に通常の
動作について説明する。
がら説明する。まず初期化について説明し、次に通常の
動作について説明する。
【0226】初期化の動作について説明する(ステップ
4002)。データ量制御装置3901は、管理情報入
出力部3902を使用することにより、重要度識別部3
904が重要度を識別する条件、データ取捨選択部39
06が、データを取捨する条件を入力する。これらの条
件は管理情報入出力部3902により随時変更できる。
なお管理情報入出力装置3902によりこれらの条件や
各部状況を出力できる。
4002)。データ量制御装置3901は、管理情報入
出力部3902を使用することにより、重要度識別部3
904が重要度を識別する条件、データ取捨選択部39
06が、データを取捨する条件を入力する。これらの条
件は管理情報入出力部3902により随時変更できる。
なお管理情報入出力装置3902によりこれらの条件や
各部状況を出力できる。
【0227】次に通常の動作を説明する。データはデー
タ入力部3903より入力され(ステップ4003)、
重要度識別部3904に送られる。そのデータは重要度
識別部3904により、重要度のランクづけをされる
(ステップ4004)。絶対に出力しなければならない
データは(ステップ4005)、データカウント部39
05に送られる。それ以外のデータはデータ取捨選択部
3906に送られる。データカウント部3905は送ら
れてくるデータの単位時間当たりの数を測定し、データ
をデータ出力部3907に送る。測定した単位時間当た
りの数をデータ取捨選択部3906に送る(ステップ4
006)。データ取捨選択部3906は送られてきた単
位時間当たりの数というデータとデータを取捨する条件
によりデータを取捨し廃棄するか決めるが,単位時間当
りのデ−タ数が多いと重要度の高いデ−タが出力されて
それが低いデ−タは廃棄され,デ−タ数が少ないと需要
度の低いデ−タも出力される(ステップ4007)。廃
棄されたデータはデータ廃棄部3908に送られ廃棄さ
れる(ステップ4009)。廃棄されなかったデータは
データ出力部3907に送られる。データ出力部390
7では送られてきたデータを出力する(ステップ400
8)。
タ入力部3903より入力され(ステップ4003)、
重要度識別部3904に送られる。そのデータは重要度
識別部3904により、重要度のランクづけをされる
(ステップ4004)。絶対に出力しなければならない
データは(ステップ4005)、データカウント部39
05に送られる。それ以外のデータはデータ取捨選択部
3906に送られる。データカウント部3905は送ら
れてくるデータの単位時間当たりの数を測定し、データ
をデータ出力部3907に送る。測定した単位時間当た
りの数をデータ取捨選択部3906に送る(ステップ4
006)。データ取捨選択部3906は送られてきた単
位時間当たりの数というデータとデータを取捨する条件
によりデータを取捨し廃棄するか決めるが,単位時間当
りのデ−タ数が多いと重要度の高いデ−タが出力されて
それが低いデ−タは廃棄され,デ−タ数が少ないと需要
度の低いデ−タも出力される(ステップ4007)。廃
棄されたデータはデータ廃棄部3908に送られ廃棄さ
れる(ステップ4009)。廃棄されなかったデータは
データ出力部3907に送られる。データ出力部390
7では送られてきたデータを出力する(ステップ400
8)。
【0228】この発明を業務サーバまたは業務クライア
ントに取り付けることにより、トランザクション処理の
ユーザデータと負荷情報・障害情報・管理情報・診断情
報等のデータを扱うことが考えられる。上記の実施例で
いうと絶対出力しなければならないデータはユーザデー
タとユーザデータ以外の非常に重要な情報のみである。
データ取捨選択部3906に送られるデータは重要度の
ランクを付けられる。データカウント部3905の送ら
れたデータの単位時間の数により、その数が多いときは
データ取捨選択部3906に送られたデータのうち重要
度の高いデータのみを出力し、少ないときは重要度の低
いデータも出力する。このように、ユーザデータが単位
時間当たりの多いときはユーザデータを多く出力でき、
少ないときは他の情報も送ることができる。このため、
ユーザデータの少ない時間を使用して、軽度な障害の情
報、負荷情報の詳細等を送ることができる。
ントに取り付けることにより、トランザクション処理の
ユーザデータと負荷情報・障害情報・管理情報・診断情
報等のデータを扱うことが考えられる。上記の実施例で
いうと絶対出力しなければならないデータはユーザデー
タとユーザデータ以外の非常に重要な情報のみである。
データ取捨選択部3906に送られるデータは重要度の
ランクを付けられる。データカウント部3905の送ら
れたデータの単位時間の数により、その数が多いときは
データ取捨選択部3906に送られたデータのうち重要
度の高いデータのみを出力し、少ないときは重要度の低
いデータも出力する。このように、ユーザデータが単位
時間当たりの多いときはユーザデータを多く出力でき、
少ないときは他の情報も送ることができる。このため、
ユーザデータの少ない時間を使用して、軽度な障害の情
報、負荷情報の詳細等を送ることができる。
【0229】以上のように請求項14の発明によれば、
重要なデータの単位時間の発生具合により、データを重
要度に応じて取捨選択し出力でき,トランザクション負
荷が増大してもその処理が阻害されない。
重要なデータの単位時間の発生具合により、データを重
要度に応じて取捨選択し出力でき,トランザクション負
荷が増大してもその処理が阻害されない。
【0230】実施例13.本発明の第15,16,17
の発明の1実施例である実施例13を図48〜52を用
いて説明する.本実施例13のポイントは従来のように
一つのデータベースにアクセスが集中するのを防ぎ、従
来のものより業務サーバの負荷を分散し、トラフィック
量も減らすことにある。
の発明の1実施例である実施例13を図48〜52を用
いて説明する.本実施例13のポイントは従来のように
一つのデータベースにアクセスが集中するのを防ぎ、従
来のものより業務サーバの負荷を分散し、トラフィック
量も減らすことにある。
【0231】一般に,デ−タの精度,整合性等の維持の
ためには集中管理が便利である.一方,デ−タへのアク
セスは例えば,混雑時期の乗物の指定券の発売当初,或
は企業内デ−タの昼間と夜間の様に,アクセス負荷のピ
−クが発生するが,ある時期を過ぎればアクセス負荷は
減少して平常或は低負荷に戻る場合が多い.本発明は,
この様に時間的要因の下で,デ−タの集中管理をしなが
らピ−ク時には一時的にデ−タを分散し,アクセス負荷
を分散して,レスポンス性能の維持を図る.このよう
に,集中と分散という実際には多くの場面で発生し相反
する要求を満たすものである.
ためには集中管理が便利である.一方,デ−タへのアク
セスは例えば,混雑時期の乗物の指定券の発売当初,或
は企業内デ−タの昼間と夜間の様に,アクセス負荷のピ
−クが発生するが,ある時期を過ぎればアクセス負荷は
減少して平常或は低負荷に戻る場合が多い.本発明は,
この様に時間的要因の下で,デ−タの集中管理をしなが
らピ−ク時には一時的にデ−タを分散し,アクセス負荷
を分散して,レスポンス性能の維持を図る.このよう
に,集中と分散という実際には多くの場面で発生し相反
する要求を満たすものである.
【0232】図48は第15,16,17の発明の構成
例を示したものである。図において、2は上位業務サー
バである。その内部の4102はデータ情報を入出力す
る手段を持つデータ情報入出力部、4103は時刻を取
得する手段を持つ時刻取得部、4104はデータの移動
処理を行う手段を持つデータ移動処理部、4105はデ
ータを記憶する手段を持つ記憶部、4106は業務クラ
イアントの要求の処理を行う手段を持つクライアント要
求処理部、4107は通信する手段を持つ通信処理部で
ある。
例を示したものである。図において、2は上位業務サー
バである。その内部の4102はデータ情報を入出力す
る手段を持つデータ情報入出力部、4103は時刻を取
得する手段を持つ時刻取得部、4104はデータの移動
処理を行う手段を持つデータ移動処理部、4105はデ
ータを記憶する手段を持つ記憶部、4106は業務クラ
イアントの要求の処理を行う手段を持つクライアント要
求処理部、4107は通信する手段を持つ通信処理部で
ある。
【0233】3a,bは下位業務サーバである。その内
部の4112a,4112bは時刻を取得する手段を持
つ時刻取得部、4113a,4113bはデータの移動
処理を行う手段を持つデータ移動処理部、4114a,
4114bはデータを記憶する手段を持つ記憶部、41
15a,4115bは業務クライアントの要求の処理を
行う手段を持つクライアント要求処理部、4116a,
4116bは通信する手段を持つ通信処理部である。
部の4112a,4112bは時刻を取得する手段を持
つ時刻取得部、4113a,4113bはデータの移動
処理を行う手段を持つデータ移動処理部、4114a,
4114bはデータを記憶する手段を持つ記憶部、41
15a,4115bは業務クライアントの要求の処理を
行う手段を持つクライアント要求処理部、4116a,
4116bは通信する手段を持つ通信処理部である。
【0234】1a,1b,1cは業務クライアントであ
る。その内部の4122a,4122b,4122cは
業務クライアント処理を行う手段を持つクライアント処
理部、4123a,4123b,4123cは通信する
手段を持つ通信処理部である。図49はチケットデ−タ
情報4250の構成を示し,例えば,乗物の座席予約な
ら,品名は便名,等級区分などからなり,在庫は座席番
号と予約のフラッグ等のセットの一覧等,上位サ−バに
デ−タを移動する時刻は上位業務サ−バ2にデ−タを移
動する設定時刻で通常アクセス負荷が減少する時刻等か
らなる.
る。その内部の4122a,4122b,4122cは
業務クライアント処理を行う手段を持つクライアント処
理部、4123a,4123b,4123cは通信する
手段を持つ通信処理部である。図49はチケットデ−タ
情報4250の構成を示し,例えば,乗物の座席予約な
ら,品名は便名,等級区分などからなり,在庫は座席番
号と予約のフラッグ等のセットの一覧等,上位サ−バに
デ−タを移動する時刻は上位業務サ−バ2にデ−タを移
動する設定時刻で通常アクセス負荷が減少する時刻等か
らなる.
【0235】次に上記実施例の動作を図50、図51、
図52を参照しながら説明する。図50は上位業務サー
バ2の、図51は下位業務サーバの3a〜bの、図52
は業務クライアント1a〜cのフローチャートである。
本発明が適用されるデータは限定されないが,ここでは
例えば座席予約のチケットの例を説明する。動作の概略
はまず上位サーバ2が下位サーバ3a〜bにチケットデ
ータを配布する。決められた時間を経過すると下位サー
バ3a〜bが上位サーバ2にチケットデータを移動し,
在庫を引き渡す。また、全業務サーバ2,3a〜bは業
務クライアント1a〜cの要求を処理する。
図52を参照しながら説明する。図50は上位業務サー
バ2の、図51は下位業務サーバの3a〜bの、図52
は業務クライアント1a〜cのフローチャートである。
本発明が適用されるデータは限定されないが,ここでは
例えば座席予約のチケットの例を説明する。動作の概略
はまず上位サーバ2が下位サーバ3a〜bにチケットデ
ータを配布する。決められた時間を経過すると下位サー
バ3a〜bが上位サーバ2にチケットデータを移動し,
在庫を引き渡す。また、全業務サーバ2,3a〜bは業
務クライアント1a〜cの要求を処理する。
【0236】詳細な動作を上位業務サーバ2の動作、下
位業務サーバの3a〜bの動作、業務クライアント1a
〜cの動作の順に説明する。
位業務サーバの3a〜bの動作、業務クライアント1a
〜cの動作の順に説明する。
【0237】まず上位業務サーバ2の動作について図5
0により説明する。初期化、下位業務サーバ3a〜bへ
データを配布するときの動作、業務クライアント1a〜
c処理の要求を受けた時の動作の順に説明する。
0により説明する。初期化、下位業務サーバ3a〜bへ
データを配布するときの動作、業務クライアント1a〜
c処理の要求を受けた時の動作の順に説明する。
【0238】上位業務サーバ2が下位業務サーバ3a〜
bに図49に示すチケットデータ情報4250を配布す
る初期化動作について説明する(ステップ4202)。
上位業務サーバ2にはデータ情報入出力部4102から
チケットデータ情報(品名、どの下位業務サーバ3a〜
bに何枚配布するかの在庫(ここでは予約可能座席
数)、下位業務サーバ3a〜bから上位業務サーバ2に
データの在庫を移動する時刻等)を入力する。データ移
動処理部4104はチケットデータ情報4250を通信
処理部4107を使用して下位業務サーバ3a〜bに与
え,その分は上位業務サ−バ2の在庫から差し引く(ス
テップ4203)。
bに図49に示すチケットデータ情報4250を配布す
る初期化動作について説明する(ステップ4202)。
上位業務サーバ2にはデータ情報入出力部4102から
チケットデータ情報(品名、どの下位業務サーバ3a〜
bに何枚配布するかの在庫(ここでは予約可能座席
数)、下位業務サーバ3a〜bから上位業務サーバ2に
データの在庫を移動する時刻等)を入力する。データ移
動処理部4104はチケットデータ情報4250を通信
処理部4107を使用して下位業務サーバ3a〜bに与
え,その分は上位業務サ−バ2の在庫から差し引く(ス
テップ4203)。
【0239】次に上位業務サーバ2が業務クライアント
1a〜cから座席予約のチケット発行処理を要求された
時の上位業務サーバ2の動作を説明する。以下では業務
クライアント1aに上位業務サーバ2が処理を要求され
た例について述べる(ステップ4204)。上位業務サ
ーバ2の通信処理部4107はクライアント要求処理部
4106に業務クライアント1の要求をわたす。
1a〜cから座席予約のチケット発行処理を要求された
時の上位業務サーバ2の動作を説明する。以下では業務
クライアント1aに上位業務サーバ2が処理を要求され
た例について述べる(ステップ4204)。上位業務サ
ーバ2の通信処理部4107はクライアント要求処理部
4106に業務クライアント1の要求をわたす。
【0240】クライアント要求処理部4106は記憶部
4105を利用して上位業務サーバ4101の在庫で足
りれば,即ち,空席があれば(ステップ4205)、業
務クライアント1aの要求を処理する(ステップ420
9)。
4105を利用して上位業務サーバ4101の在庫で足
りれば,即ち,空席があれば(ステップ4205)、業
務クライアント1aの要求を処理する(ステップ420
9)。
【0241】もし上位業務サーバ2の在庫で必要な予約
可能座席が不足し(ステップ4205),かつ時刻取得
部4103の時刻と記憶部4105に保持するチケット
デ−タ情報4250の上位業務サ−バにデ−タを移動す
る時刻との比較により,在庫移動時刻を経過していると
判定すれば(ステップ4206)、全下位業務サーバ3
a〜bにも在庫がないので在庫不足であると業務クライ
アント1aに通知する(ステップ4210)。なぜなら
ば、在庫移動時刻を経過すると全下位業務サーバ3a〜
bから上位業務サーバ2に在庫が移動する。そのためチ
ケットの在庫が存在するとすれば上位業務サーバ2のみ
である。その上位業務サーバ2にも在庫がなければ全サ
ーバにも在庫がないためである。
可能座席が不足し(ステップ4205),かつ時刻取得
部4103の時刻と記憶部4105に保持するチケット
デ−タ情報4250の上位業務サ−バにデ−タを移動す
る時刻との比較により,在庫移動時刻を経過していると
判定すれば(ステップ4206)、全下位業務サーバ3
a〜bにも在庫がないので在庫不足であると業務クライ
アント1aに通知する(ステップ4210)。なぜなら
ば、在庫移動時刻を経過すると全下位業務サーバ3a〜
bから上位業務サーバ2に在庫が移動する。そのためチ
ケットの在庫が存在するとすれば上位業務サーバ2のみ
である。その上位業務サーバ2にも在庫がなければ全サ
ーバにも在庫がないためである。
【0242】上位業務サーバ2の在庫で不足し(ステッ
プ4205)、かつ在庫移動時刻を経過していない場合
(ステップ4206)、他の全下位業務サーバ3a〜b
に在庫引当を確保するため分散トランザクションを行う
(ステップ4207)。分散トランザクションを行った
結果、在庫が足りれば(ステップ4208)業務クライ
アント1aの要求を処理し(ステップ4209)し、在
庫が足りなければ(ステップ4208)在庫不足である
と業務クライアント1aに送信する(ステップ421
0)。
プ4205)、かつ在庫移動時刻を経過していない場合
(ステップ4206)、他の全下位業務サーバ3a〜b
に在庫引当を確保するため分散トランザクションを行う
(ステップ4207)。分散トランザクションを行った
結果、在庫が足りれば(ステップ4208)業務クライ
アント1aの要求を処理し(ステップ4209)し、在
庫が足りなければ(ステップ4208)在庫不足である
と業務クライアント1aに送信する(ステップ421
0)。
【0243】以上、業務クライアント1aにから処理要
求があった場合について述べたが、業務クライアント1
b〜cについても同様である。
求があった場合について述べたが、業務クライアント1
b〜cについても同様である。
【0244】次に下位業務サーバ3a〜bの動作につい
て図51により説明する。ここでは、下位業務サーバ3
aを例にとり説明する。下位業務サーバ3aの動作は大
きく分けると業務クライアント1a〜bから処理を要求
された時の動作、在庫移動時刻を経過した時の動作、他
の業務サーバ2,3bから処理の要求があった時の動作
の順に説明する。
て図51により説明する。ここでは、下位業務サーバ3
aを例にとり説明する。下位業務サーバ3aの動作は大
きく分けると業務クライアント1a〜bから処理を要求
された時の動作、在庫移動時刻を経過した時の動作、他
の業務サーバ2,3bから処理の要求があった時の動作
の順に説明する。
【0245】下位業務サーバ3aが業務クライアント1
a〜cから座席予約のチケット発行処理を要求された時
の動作を説明する。ここでは業務クライアント1aから
処理を要求された時の例を述べる。下位業務サーバ3a
の通信処理部4116aはクライアント要求処理部41
15aに処理要求をわたす(ステップ4302)。
a〜cから座席予約のチケット発行処理を要求された時
の動作を説明する。ここでは業務クライアント1aから
処理を要求された時の例を述べる。下位業務サーバ3a
の通信処理部4116aはクライアント要求処理部41
15aに処理要求をわたす(ステップ4302)。
【0246】クライアント要求処理部4115aは記憶
部4114aを利用して自己の在庫で足りれば(ステッ
プ4303)、業務クライアント1aの要求を処理する
(ステップ4309)。
部4114aを利用して自己の在庫で足りれば(ステッ
プ4303)、業務クライアント1aの要求を処理する
(ステップ4309)。
【0247】下位業務サーバ3aの在庫で足りなく(ス
テップ4303)、かつ時刻取得部4112aの時刻と
記憶部4114aに保持するチケットデ−タ情報425
0の上位サ−バにデ−タを移動する時刻との比較によ
り,在庫移動時刻を経過していないと判断した場合(ス
テップ4304)、全サーバ2,3bに在庫を確保する
ため分散トランザクションを行う(ステップ430
5)。下位業務サーバ3aの在庫で足りなく(ステップ
4303)かつ在庫移動時刻を経過している場合(ステ
ップ4304)、他の全ての下位業務サーバ3a〜bに
は在庫がないので、上位業務サーバ2のみに在庫を確保
するため分散トランザクションを行う(ステップ430
6)。
テップ4303)、かつ時刻取得部4112aの時刻と
記憶部4114aに保持するチケットデ−タ情報425
0の上位サ−バにデ−タを移動する時刻との比較によ
り,在庫移動時刻を経過していないと判断した場合(ス
テップ4304)、全サーバ2,3bに在庫を確保する
ため分散トランザクションを行う(ステップ430
5)。下位業務サーバ3aの在庫で足りなく(ステップ
4303)かつ在庫移動時刻を経過している場合(ステ
ップ4304)、他の全ての下位業務サーバ3a〜bに
は在庫がないので、上位業務サーバ2のみに在庫を確保
するため分散トランザクションを行う(ステップ430
6)。
【0248】分散トランザクションをした結果、在庫を
確保できれば(ステップ4307)業務クライアント1
aの要求を処理し(ステップ4309)、在庫が確保で
きなければ在庫不足であると要求があった業務クライア
ントaに送信する(ステップ4308)。
確保できれば(ステップ4307)業務クライアント1
aの要求を処理し(ステップ4309)、在庫が確保で
きなければ在庫不足であると要求があった業務クライア
ントaに送信する(ステップ4308)。
【0249】以上業務クライアント1aから処理を要求
された下位業務サーバ3aの例について述べたが業務ク
ライアント1b〜cについても同様である。
された下位業務サーバ3aの例について述べたが業務ク
ライアント1b〜cについても同様である。
【0250】次ぎに,下位業務サーバ3aが上位業務サ
ーバ2に在庫データを移動する動作について説明する。
デ−タ移動処理部4113aは時刻取得部4112aか
ら時刻を入手し、記憶部4114aに保存のチケットデ
−タ情報4250を上位業務サ−バにデ−タを移動する
時刻との比較で在庫移動時刻になったと判定すれば(ス
テップ4311)、在庫を上位業務サーバ2に移動する
(ステップ4312)。つまり、移動後の下位業務サー
バ3aのチケットデータ情報4250の在庫フィールド
は0となり、上位業務サーバ2のチケットデータ情報4
250の在庫のフィールドは下位業務サーバ3aの持っ
ていた枚数分増加する。
ーバ2に在庫データを移動する動作について説明する。
デ−タ移動処理部4113aは時刻取得部4112aか
ら時刻を入手し、記憶部4114aに保存のチケットデ
−タ情報4250を上位業務サ−バにデ−タを移動する
時刻との比較で在庫移動時刻になったと判定すれば(ス
テップ4311)、在庫を上位業務サーバ2に移動する
(ステップ4312)。つまり、移動後の下位業務サー
バ3aのチケットデータ情報4250の在庫フィールド
は0となり、上位業務サーバ2のチケットデータ情報4
250の在庫のフィールドは下位業務サーバ3aの持っ
ていた枚数分増加する。
【0251】下位業務サーバ3bが他の業務サーバ2,
3bから処理要求があった時(ステップ4302)の動
作について説明する。処理要求が上位業務サーバ2から
のデータの配布であれば(ステップ4321)、そのデ
ータを記憶する(ステップ4322)。処理要求が他の
業務サーバ2,3bから分散トランザクション処理の要
求であれば(ステップ4321)、分散トランザクショ
ン処理を実行させられる(ステップ4323)。これ
は,図50の上位業務サ−バ2のフロ−でステップ42
07の処理に繋がっている.
3bから処理要求があった時(ステップ4302)の動
作について説明する。処理要求が上位業務サーバ2から
のデータの配布であれば(ステップ4321)、そのデ
ータを記憶する(ステップ4322)。処理要求が他の
業務サーバ2,3bから分散トランザクション処理の要
求であれば(ステップ4321)、分散トランザクショ
ン処理を実行させられる(ステップ4323)。これ
は,図50の上位業務サ−バ2のフロ−でステップ42
07の処理に繋がっている.
【0252】以上下位業務サーバ3aについて説明した
が、下位業務サーバ3bについても同様である。また,
在庫移動時刻は必要により,年月日或は指定の時点から
の経過時間(単位は任意)を組み合せた時刻でもよい.
また,在庫移動時刻はチケットデ−タ情報4250によ
り通知しているが,他の方法によって指定,通知しても
よい.例えば,上位業務サ−バ2からチケットデ−タと
は別に通知,或はネットワ−クに接続の任意の計算機か
ら通知,特定の計算機が移動された各サ−バの在庫の残
数を把握して一定の残数以下になれば在庫を移動させえ
る,更に,時間指定ではなく直接移動を指示する等の方
法でもよい.
が、下位業務サーバ3bについても同様である。また,
在庫移動時刻は必要により,年月日或は指定の時点から
の経過時間(単位は任意)を組み合せた時刻でもよい.
また,在庫移動時刻はチケットデ−タ情報4250によ
り通知しているが,他の方法によって指定,通知しても
よい.例えば,上位業務サ−バ2からチケットデ−タと
は別に通知,或はネットワ−クに接続の任意の計算機か
ら通知,特定の計算機が移動された各サ−バの在庫の残
数を把握して一定の残数以下になれば在庫を移動させえ
る,更に,時間指定ではなく直接移動を指示する等の方
法でもよい.
【0253】次に業務クライアント1a〜cの動作につ
いて図52により説明する。業務クライアント1aは業
務サーバ2,3a〜bのアドレスを得るなどの初期化を
行う(ステップ4402)。この詳細は本発明に直接関
係ないので省略する.クライアント処理部4122aが
通信処理部4123aを使用しサーバに処理を依頼する
(ステップ4403)。以上業務クライアント1aにつ
いて述べたが、業務クライアントb,cについても同様
である。
いて図52により説明する。業務クライアント1aは業
務サーバ2,3a〜bのアドレスを得るなどの初期化を
行う(ステップ4402)。この詳細は本発明に直接関
係ないので省略する.クライアント処理部4122aが
通信処理部4123aを使用しサーバに処理を依頼する
(ステップ4403)。以上業務クライアント1aにつ
いて述べたが、業務クライアントb,cについても同様
である。
【0254】このように各サーバが記憶部4105,4
114を持つので従来のように一つのデータベースのよ
うな記憶部にアクセスが集中するのを防ぎ、従来のもの
より業務サーバの負荷を分散できる。またチケットの在
庫データのような時間が経過するにつれて減少するデー
タを扱うと在庫が分散されているので在庫がどこに存在
するかわからなくなる可能性がある。しかし本方法では
時間が経過すると一箇所のサーバに在庫が集中するため
在庫管理も容易である.また,下位業務サ−バ3を任意
の群に区分し,群ごとに在庫移動時刻を設定すれば,時
間により各サーバが分散トランザクションを行う通信相
手も限られてきて通信量が減り、サーバの負荷も減少で
きる。この場合,図50のステップ4206,図51の
ステップ4304,4311等における在庫移動時刻の
判定では,下位業務サ−バ群毎に判定する.また,図5
0のステップ4207,図51のステップ4305,4
323等の分散トランザクション処理でも下位業務サ−
バ群を基に処理をする.
114を持つので従来のように一つのデータベースのよ
うな記憶部にアクセスが集中するのを防ぎ、従来のもの
より業務サーバの負荷を分散できる。またチケットの在
庫データのような時間が経過するにつれて減少するデー
タを扱うと在庫が分散されているので在庫がどこに存在
するかわからなくなる可能性がある。しかし本方法では
時間が経過すると一箇所のサーバに在庫が集中するため
在庫管理も容易である.また,下位業務サ−バ3を任意
の群に区分し,群ごとに在庫移動時刻を設定すれば,時
間により各サーバが分散トランザクションを行う通信相
手も限られてきて通信量が減り、サーバの負荷も減少で
きる。この場合,図50のステップ4206,図51の
ステップ4304,4311等における在庫移動時刻の
判定では,下位業務サ−バ群毎に判定する.また,図5
0のステップ4207,図51のステップ4305,4
323等の分散トランザクション処理でも下位業務サ−
バ群を基に処理をする.
【0255】上記実施例での下位業務サーバ3a〜bの
下にさらに下位業務サーバのある階層化でもよい。階層
化することによりさらに分散することができる。また,
これとは逆に業務サ−バを上位,下位の構成ではなく,
各業務サ−バを対等にする構成でもよい.
下にさらに下位業務サーバのある階層化でもよい。階層
化することによりさらに分散することができる。また,
これとは逆に業務サ−バを上位,下位の構成ではなく,
各業務サ−バを対等にする構成でもよい.
【0256】上記実施例では、座席予約のチケットデー
タを扱ったが、物流在庫などの流通で使用されるデータ
などを扱うことができることはいうまでもない。
タを扱ったが、物流在庫などの流通で使用されるデータ
などを扱うことができることはいうまでもない。
【0257】以上のように第15,16,17の発明に
よれば、従来のものよりサーバの負荷を分散し、トラフ
ィック量も減らす効果がある。
よれば、従来のものよりサーバの負荷を分散し、トラフ
ィック量も減らす効果がある。
【0258】
【発明の効果】以上の様にこの発明によりトランザクシ
ョンの処理要求が多くなっても負荷分散システムに対す
る障害が回避出来るという効果がある.
ョンの処理要求が多くなっても負荷分散システムに対す
る障害が回避出来るという効果がある.
【図1】図1はこの発明の第1の発明による一実施例の
ブロック図である。
ブロック図である。
【図2】図2はこの発明の第1の発明による一実施例の
動作を説明する図である。
動作を説明する図である。
【図3】図3はこの発明の第1の発明による一実施例の
動作を説明する図である。
動作を説明する図である。
【図4】図4はこの発明の第1の発明による一実施例に
おける処理例を示す流れ図である。
おける処理例を示す流れ図である。
【図5】図5はこの発明の第2の発明による一実施例の
ブロック図である。
ブロック図である。
【図6】図6はこの発明の第2の発明による一実施例の
動作を説明する図である。
動作を説明する図である。
【図7】図7はこの発明の第2の発明による一実施例の
動作を説明する図である。
動作を説明する図である。
【図8】図8はこの発明の第2の発明による一実施例に
おける処理例を示す流れ図である。
おける処理例を示す流れ図である。
【図9】図9はこの発明の第3,4の発明による一実施
例のブロック図である。
例のブロック図である。
【図10】図10はこの発明の第3,4の発明による一
実施例の動作を説明する図である。
実施例の動作を説明する図である。
【図11】図11はこの発明の第5の発明による一実施
例のブロック図である。
例のブロック図である。
【図12】図12はこの発明の第5の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図13】図13はこの発明の第6の発明による一実施
例のブロック図である。
例のブロック図である。
【図14】図14はこの発明の第6の発明による一実施
例のブロック図である。
例のブロック図である。
【図15】図15はこの発明の第6の発明による一実施
例の構成を示す図である.
例の構成を示す図である.
【図16】図16はこの発明の第6の発明による一実施
例の動作を示す図である.
例の動作を示す図である.
【図17】図17はこの発明の第6の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図18】図18はこの発明の第6の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図19】図19はこの発明の第6の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図20】図20はこの発明の第7の発明による一実施
例のブロック図である。
例のブロック図である。
【図21】図21はこの発明の第7の発明による一実施
例のブロック図である。
例のブロック図である。
【図22】図22はこの発明の第7の発明による一実施
例の構成を示す図である.
例の構成を示す図である.
【図23】図23はこの発明の第7の発明による一実施
例の構成を示す図である.
例の構成を示す図である.
【図24】図24はこの発明の第7の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図25】図25はこの発明の7の発明による一実施例
の動作を説明する図である。
の動作を説明する図である。
【図26】図26はこの発明の第8の発明による一実施
例のブロック図である。
例のブロック図である。
【図27】図27はこの発明の第8の一実施例の内、回
覧リストを示す図である。
覧リストを示す図である。
【図28】図28はこの発明の第8の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図29】図29はこの発明の第9の発明による一実施
例のブロック図である。
例のブロック図である。
【図30】図30はこの発明の第9の発明による一実施
例の動作を説明する図である。
例の動作を説明する図である。
【図31】図31はこの発明の第10,11の発明によ
る一実施例のブロック図である。
る一実施例のブロック図である。
【図32】図32はこの発明の第10,11の発明によ
る一実施例の動作を説明する図である。
る一実施例の動作を説明する図である。
【図33】図33はこの発明の第10,11の発明によ
る一実施例の動作を説明する図である。
る一実施例の動作を説明する図である。
【図34】図34はこの発明の第10,11の発明によ
る一実施例の動作を説明する図である。
る一実施例の動作を説明する図である。
【図35】図35はこの発明の第12の発明による一実
施例のブロック図である。
施例のブロック図である。
【図36】図36はこの発明の第12の発明による一実
施例のプロセス管理テ−ブルcの内容を示す図である.
施例のプロセス管理テ−ブルcの内容を示す図である.
【図37】図37はこの発明の第12の発明による一実
施例の振り分けテ−ブルの内容を示す図である.
施例の振り分けテ−ブルの内容を示す図である.
【図38】図38はこの発明の第12の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図39】図39はこの発明の第12の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図40】図40はこの発明の第12の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図41】図41はこの発明の第13の発明による一実
施例のブロック図である。
施例のブロック図である。
【図42】図42はこの発明の第13の発明の一実施例
のアクセス制御テ−ブルの内容を示す図である.
のアクセス制御テ−ブルの内容を示す図である.
【図43】図43はこの発明の第13の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図44】図44はこの発明の第13の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図45】図45はこの発明の第13の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図46】図46はこの発明の第14の発明による一実
施例のブロック図である。
施例のブロック図である。
【図47】図47はこの発明の第14の発明による一実
施例の動作を説明する図である。
施例の動作を説明する図である。
【図48】図48はこの発明の第15,16,17の発
明による一実施例のブロック図である。
明による一実施例のブロック図である。
【図49】図49はこの発明の第15,16,17の発
明による一実施例のチケットデ−タ情報の内容を示す図
である.
明による一実施例のチケットデ−タ情報の内容を示す図
である.
【図50】図50はこの発明の第15,16,17の発
明による一実施例の動作を説明する図である。
明による一実施例の動作を説明する図である。
【図51】図51はこの発明の第15,16,17の発
明による一実施例の動作を説明する図である。
明による一実施例の動作を説明する図である。
【図52】図52はこの発明の第15,16,17の発
明による一実施例の動作を説明する図である。
明による一実施例の動作を説明する図である。
【図53】図53はこの発明の第1の発明と第2の発明
の従来図である。
の従来図である。
【図54】図54は第3と第4と第5の発明の従来図で
ある。
ある。
【図55】図55はこの発明の第6,7の発明の従来図
である。
である。
【図56】図56はこの発明の第8の発明の従来図であ
る。
る。
【図57】図57はこの発明の第9の発明の従来図であ
る。
る。
【図58】図58はこの発明の第10,11の発明の従
来図である。
来図である。
【図59】図59はこの発明の第12と第13の発明の
従来図である。
従来図である。
【図60】図60はこの発明の第15,16,17の発
明の従来図である。
明の従来図である。
1 業務クライアント 2〜3 業務サーバ 4 名前サ−バ 9〜10 業務サーバプロセス 11 負荷監視手段 12 業務サーバプロセス数変更手段 13 業務クライアント決定手段 14〜15 業務クライアント管理テーブル 16 トランザクション処理管理部 509〜510 業務サーバプロセス 511 負荷監視手段 512 業務サーバプロセス数変更手段 513 管理データ決定手段 514〜515 データ管理テーブル 516 トランザクション処理管理部 903 時刻管理手段 904 処理依頼データ受信手段 905 データ受信時刻刻印手段 906 業務サーバプロセス 907 トランザクション処理開始/終了時刻刻印手段 908 トランザクション処理実行部 909 処理結果データ送信手段 910 処理結果の転送時間 911 処理受け付けから処理開始までの時間 1103 名前サーバ 1104 各業務サーバの処理内容とそのネットワーク
上のアドレスの対応表 1105 サーバアドレス応答データ送信手段 1106 放送通信手段 1201 業務サーバプロセス 1202 ある処理を提供しているサーバアドレスの問
い合わせ 1203 名前サーバからの応答データ 1303a,1303b 記憶装置 1411a,1411b 業務サーバプロセス 1421 メモリ管理部 1422 プロセス制御部 1423 プロセス管理部 1424,1425 記憶部 1811 業務サーバプロセス 1821 サーバ管理部 1822 プロセス管理部 1823,1824 記憶部 1911 代行サーバプロセス 2201 伝送路 2204 トランザクション要求送受信部 2204a 業務サーバ1のトランザクション要求送受
信部 2204b 業務サーバ2のトランザクション要求送受
信部 2205 トランザクション回覧発生部 2206a 業務サーバ1のトランザクション回覧部 2206b 業務サーバ2のトランザクション回覧部 2207a 業務サーバ1の負荷を検出するサーバ負荷
検出部 2207b 業務サーバ2の負荷を検出するサーバ負荷
検出部 2208a 業務サーバ1のトランザクション処理部 2208b 業務サーバ2のトランザクション処理部 2209 業務サーバ回覧リスト 2501 伝送路 2504 トランザクション要求送受信部 2505 トランザクション処理部 2506 処理負荷検出部 2507 負荷履歴記憶部 2508 負荷傾向検出部 2509 負荷閾値記憶部 2510 業務判定部 2701 伝送路 2703 トランザクション要求送受信部 2704 トランザクション処理時間検出部 2705 トランザクション処理閾時間記憶部 2706 管理要求送受信部 2708 トランザクション処理部 2709 管理情報収集部 2710 負荷監視マネージャ 2711 クライアント管理部 2712 サーバ管理部 2713 クライアント・サーバ統括管理部 3101 マネージャ 3102 マネージャ管理情報入出力処理部 3103 サーバ起動部 3104 サーバ振り分け処理部 3105 通信処理部 3111 業務サーバプロセス 3112 負荷監視部 3113 クライアント要求処理部 3114 自己消去部 3115 通信処理部 3122 クライアント処理部 3123 通信処理部 3501 アクセス制御装置 3502 アクセス制御管理情報入出力処理部 3503 アクセス制御処理部 3504 通信処理部 3512 サーバ管理情報入出力処理部 3513 負荷監視部 3514 アクセス権付与決定部 3515 クライアント要求処理部 3516 通信処理部 3522 クライアント処理部 3523 通信処理部 3901 データ量制御装置 3902 管理情報入出力部 3903 データ入力部 3904 重要度識別部 3905 データカウント部 3906 データ取捨選択部 3907 データ出力部 3908 データ廃棄部 4102 データ情報入出力処理部 4103 時刻取得部 4104 データ移動処理部 4105 記憶部 4106 クライアント要求処理部 4107 通信処理部 4112a,4112b 時刻取得部 4113a,4113b データ移動処理部 4114a,4114b 記憶部 4115a,4115b クライアント要求処理部 4116a,4116b 通信処理部 4122a,4122b,4122cクライアント処理
部 4123a,4123b,4123c 通信処理部 e
上のアドレスの対応表 1105 サーバアドレス応答データ送信手段 1106 放送通信手段 1201 業務サーバプロセス 1202 ある処理を提供しているサーバアドレスの問
い合わせ 1203 名前サーバからの応答データ 1303a,1303b 記憶装置 1411a,1411b 業務サーバプロセス 1421 メモリ管理部 1422 プロセス制御部 1423 プロセス管理部 1424,1425 記憶部 1811 業務サーバプロセス 1821 サーバ管理部 1822 プロセス管理部 1823,1824 記憶部 1911 代行サーバプロセス 2201 伝送路 2204 トランザクション要求送受信部 2204a 業務サーバ1のトランザクション要求送受
信部 2204b 業務サーバ2のトランザクション要求送受
信部 2205 トランザクション回覧発生部 2206a 業務サーバ1のトランザクション回覧部 2206b 業務サーバ2のトランザクション回覧部 2207a 業務サーバ1の負荷を検出するサーバ負荷
検出部 2207b 業務サーバ2の負荷を検出するサーバ負荷
検出部 2208a 業務サーバ1のトランザクション処理部 2208b 業務サーバ2のトランザクション処理部 2209 業務サーバ回覧リスト 2501 伝送路 2504 トランザクション要求送受信部 2505 トランザクション処理部 2506 処理負荷検出部 2507 負荷履歴記憶部 2508 負荷傾向検出部 2509 負荷閾値記憶部 2510 業務判定部 2701 伝送路 2703 トランザクション要求送受信部 2704 トランザクション処理時間検出部 2705 トランザクション処理閾時間記憶部 2706 管理要求送受信部 2708 トランザクション処理部 2709 管理情報収集部 2710 負荷監視マネージャ 2711 クライアント管理部 2712 サーバ管理部 2713 クライアント・サーバ統括管理部 3101 マネージャ 3102 マネージャ管理情報入出力処理部 3103 サーバ起動部 3104 サーバ振り分け処理部 3105 通信処理部 3111 業務サーバプロセス 3112 負荷監視部 3113 クライアント要求処理部 3114 自己消去部 3115 通信処理部 3122 クライアント処理部 3123 通信処理部 3501 アクセス制御装置 3502 アクセス制御管理情報入出力処理部 3503 アクセス制御処理部 3504 通信処理部 3512 サーバ管理情報入出力処理部 3513 負荷監視部 3514 アクセス権付与決定部 3515 クライアント要求処理部 3516 通信処理部 3522 クライアント処理部 3523 通信処理部 3901 データ量制御装置 3902 管理情報入出力部 3903 データ入力部 3904 重要度識別部 3905 データカウント部 3906 データ取捨選択部 3907 データ出力部 3908 データ廃棄部 4102 データ情報入出力処理部 4103 時刻取得部 4104 データ移動処理部 4105 記憶部 4106 クライアント要求処理部 4107 通信処理部 4112a,4112b 時刻取得部 4113a,4113b データ移動処理部 4114a,4114b 記憶部 4115a,4115b クライアント要求処理部 4116a,4116b 通信処理部 4122a,4122b,4122cクライアント処理
部 4123a,4123b,4123c 通信処理部 e
フロントページの続き (72)発明者 中川路 哲男 鎌倉市大船五丁目1番1号 三菱電機株式 会社情報システム研究所内
Claims (17)
- 【請求項1】 トランザクション処理システムにおい
て,トランザクションの負荷を監視する負荷監視手段
と、該負荷監視手段による監視結果に基づいて業務サー
バプロセス数を制御する業務サーバプロセス数変更手段
と、該業務サ−バプロセス数変更手段を該制御に基いて
各業務サーバプロセスが処理要求を受け付けるべき業務
クライアントを決定する業務クライアント決定手段と、
各業務サーバプロセスが処理要求を受け付ける業務クラ
イアントを管理する業務クライアント管理テーブルとを
設けたことを特徴とする負荷分散方式。 - 【請求項2】 トランザクション処理システムにおい
て、トランザクションの負荷を監視する負荷監視手段
と、該負荷監視手段による監視結果に基づいて業務サー
バプロセス数を制御する業務サーバプロセス数変更手段
と、該業務サ−バプロセス数変更手段の該制御に基いて
各業務サーバプロセスが処理の対象とするデータを決定
する管理データ決定手段と、各業務サーバプロセスにお
いて処理の対象とするデータを管理するデータ管理テー
ブルとを備えたことを特徴とする負荷分散方式。 - 【請求項3】 トランザクション処理システムにおい
て、業務クライアントの処理依頼の送信から処理結果の
受信までの間の任意の処理の任意の時点の時刻を刻印す
る時刻刻印手段と,該時刻刻印手段が刻印した該任意の
処理の内指定した処理の指定した時点の時刻から指定し
た処理の指定した時点間の所要時間を算出する所要時間
算出手段と,を備えたことを特徴とする負荷分散方式. - 【請求項4】 トランザクション処理システムにおい
て、業務クライアントからの依頼データを業務サ−バが
受信したデータ受信時刻を刻印するデータ受信時刻刻印
手段と、業務サーバプロセスにおいてトランザクション
処理の開始時刻と該処理終了時刻とを刻印するトランザ
クション処理開始終了時刻刻印手段と,該処理結果を返
信した時刻を刻印する返信時刻刻印手段と,業務クライ
アントが該処理結果を受信した時刻を刻印する処理結果
刻印手段と,これらの任意の時刻から所要時間を算出す
る所要時間算出手段を備えたことを特徴とする負荷分散
方式。 - 【請求項5】 トランザクション処理システムにおい
て、各業務サーバの処理内容とそのネットワーク上のア
ドレスの対応表を保持している名前サーバと、名前サー
バにおいて問い合わせのあった処理を提供している業務
サーバのアドレスを応答として返信するサーバアドレス
応答データ送信手段と、該サーバアドレス応答デ−タ送
信手段において該返信する業務サ−バのアドレスを複数
の業務クライアントに対して放送通信する放送通信手段
と,を備えたことを特徴とする負荷分散方式。 - 【請求項6】 トランザクション処理システムにおい
て、業務サ−バは,使用メモリ容量の閾値を保持し,プ
ロセスのメモリ占有量が閾値を超過したらプロセスを退
避させて縮退運転に移り,プロセスがメモリを開放して
メモリの占有量が該閾値を下回ったら退避した該プロセ
スを復旧させて平常運転に移る制御を行う制御部を備え
ることを特徴とする負荷分散方式。 - 【請求項7】 トランザクション処理システムにおい
て、業務サ−バは,負荷の閾値を保持し,トランザクシ
ョンの処理負荷が該閾値を超過したらトランザクション
を処理していた業務サーバプロセスを退避し,その処理
機能を代行する代行業務サーバプロセスを生成して縮退
運転に移り,業務サ−バプロセスが処理を終了して実行
待ちになり,負荷が該閾値を下回れば,該代行業務サ−
バプロセスを消去して前記の退避した業務サ−バプロセ
スを復旧する制御を行う制御部を備えることを特徴とす
る負荷分散方式。 - 【請求項8】 トランザクション処理システムにおい
て、トランザクションの処理要求をできる業務サーバに
回覧し要求を処理する業務サ−バを決めるためのトラン
ザクション回覧を作成するトランザクション回覧発生部
とトランザクション処理要求に該トランザクション回覧
を添付して送信するトランザクション要求送受信部を設
けた業務クライアントと、該トランザクション要求と該
トランザクション回覧を送受信する送受信部と自業務サ
ーバの処理負荷を検出するサーバ負荷検出部と回覧リス
トを解析し業務サーバの処理負荷を回覧リストに記入し
該送受信部を介して最も処理負荷の低い業務サーバにト
ランザクション処理要求を回覧する処理負荷トランザク
ション回覧手段を設けた業務サ−バと,を備えることを
特徴とする負荷分散方式。 - 【請求項9】 トランザクション処理システムにおい
て、業務サ−バは,業務サーバの負荷閾値を記憶する負
荷閾値記憶手段と、業務サーバの処理負荷を検出する処
理負荷検出手段と、業務サーバの時系列的な処理負荷履
歴を記憶する負荷履歴記憶手段と、処理負荷履歴から負
荷傾向を検出し予測値を算出する負荷傾向検出手段と、
負荷傾向検出手段が算出した処理負荷の予測値と負荷閾
値記憶手段に記憶された負荷閾値との比較によりトラン
ザクション要求を当該業務サーバで行うかどうかを判定
する業務判定手段と,を備えることを特徴とする負荷分
散方式。 - 【請求項10】 トランザクション処理システムにおい
て、業務クライアントはトランザクション要求を発行し
てから処理結果を受信するまでの最大待ち時間を閾値と
して記憶するトランザクション処理閾時間記憶手段と、
トランザクション毎の処理要求発行の時点から処理結果
を受信するまでの経過時間を計測し該経過時間と前記の
閾値との比較を行い、該経過時間が前記の閾値よりも大
きいときには任意の指定処理をするトランザクション処
理時間検出手段と、を備えたことを特徴とする負荷分散
方式。 - 【請求項11】 業務クライアントと業務サ−バと負荷
監視マネ−ジャとからなるトランザクション処理システ
ムにおいて、業務クライアントはトランザクション要求
を発行してから処理結果を受信するまでの最大待ち時間
を閾値として記憶するトランザクション処理閾時間記憶
手段と、トランザクション毎の処理要求発行の時点から
処理結果を受信するまでの経過時間を計測し該経過時間
と前記の閾値との比較を行い、該経過時間が前記の閾値
よりも大きいときには負荷監視マネージャに警報を発行
するトランザクション処理時間検出手段と、を備え,業
務サーバは負荷監視マネージャからの負荷の照会を受信
しそれに応答する管理要求送受信手段を備え、負荷監視
マネージャは、業務サ−バに対して同業務サ−バの負荷
に応じて増減された間隔でなされる前記の負荷の照会に
対する回答または業務クライアントからの前記の警報に
よりトランザクション処理システムの異常部分を検出す
るクライアント・サーバ統括管理手段を備える,ことを
特徴とする負荷分散方式。 - 【請求項12】 業務クライアントと業務サ−バプロセ
スとマネ−ジャとからなるトランザクション処理システ
ムにおいて、業務サ−バプロセスは,業務サ−バプロセ
スの負荷を把握し高負荷になれば該業務サ−バプロセス
の作成をマネ−ジャに要求する負荷監視部と、マネ−ジ
ャから受けた業務サ−バプロセスの条件を満たせば該業
務サーバプロセスの自己消去を行う自己消去部とを備
え、マネ−ジャは,業務サ−バプロセスを起動するサ−
バ起動部と,業務サ−バプロセスの条件を保存し,業務
クライアントまたは該負荷監視部の要求に基いて,業務
サ−バプロセスの前記の保存された条件を付し,サ−バ
起動部を介して該業務サ−バプロセスを起動させるサー
バ振り分け処理部とを備える,ことを特徴とする負荷分
散方式。 - 【請求項13】 トランザクション処理システムにおい
て、業務サ−バは業務サーバの負荷状態を知る負荷監視
部と、業務クライアントのアクセス優先順位を制御する
情報と該負荷監視部の情報により業務クライアントへア
クセス権を付与するアクセス権付与決定部とを備えるこ
とを特徴とする負荷分散方式。 - 【請求項14】 トランザクション処理システムにおい
て,データ量制御装置は,データを入力する入力手段、
処理条件の設定変更削除の情報を入出力する管理情報入
出力手段,該管理情報入出力手段の設定した条件により
該入力手段からの入力データの重要度を識別して絶対出
力デ−タと任意出力デ−タに分類する重要度識別手段、
前記の絶対出力デ−タの時間あたりの数をカウントする
カウント手段、前記カウント手段の時間当りの絶対出力
デ−タの数と該管理情報入出力手段の設定条件に基き前
記任意出力データを取捨選択する取捨選択手段、出力デ
ータを出力する出力手段、とを備えることを特徴とする
負荷分散方式。 - 【請求項15】 トランザクション処理システムにおい
て、時刻を取得する時刻取得部と、データを記憶する記
憶部と、他の業務サ−バからのデ−タを該記憶部に格納
し,該時刻取得部の時刻が所定のデ−タ移動時刻になれ
ば該記憶部のデータを他の業務サ−バに移動するデータ
移動処理部と、業務クライアントの要求の処理を行うク
ライアント要求処理部と,を設けた業務サ−バを備える
ことを特徴とする負荷分散方式。 - 【請求項16】 トランザクション処理システムにおい
て、業務サ−バは上位業務サ−バと下位業務サ−バより
なり,下位業務サ−バは時刻を取得する時刻取得部と、
データを記憶する下位記憶部と、上位業務サ−バからの
デ−タを該下位記憶部に格納し,該時刻取得部の時刻が
上位業務サ−バの指定のデ−タ移動時刻になれば該下位
記憶部のデータを上部業務サ−バに移動するデータ移動
処理部と、業務クライアントの要求の処理を行うクライ
アント要求処理部と,を備え,上位業務サ−バはデータ
を記憶する上位記憶部、データの移動時刻を指定して該
上位記憶部から該下位記憶部への移動処理及び該指定移
動時刻になれば該下位記憶部からのデ−タを上位記憶部
に保存するデータ移動処理部と、業務クライアントの要
求の処理を行うクライアント要求処理部と,を備えるこ
とを特徴とする負荷分散方式。 - 【請求項17】 業務サ−バのクライアント要求処理部
は業務クライアントのデ−タに係わる処理要求に対して
自記憶部のデ−タで対応出来ないときは,他の業務サ−
バのデ−タを使用して該業務クライアントの要求を処理
する分散トランザクション処理を行うことを特徴とする
請求項15または請求項16に記載の負荷分散方式.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP6114557A JPH07302242A (ja) | 1994-04-30 | 1994-04-30 | 負荷分散方式 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP6114557A JPH07302242A (ja) | 1994-04-30 | 1994-04-30 | 負荷分散方式 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH07302242A true JPH07302242A (ja) | 1995-11-14 |
Family
ID=14640793
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP6114557A Pending JPH07302242A (ja) | 1994-04-30 | 1994-04-30 | 負荷分散方式 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH07302242A (ja) |
Cited By (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09269925A (ja) * | 1996-04-02 | 1997-10-14 | Nri & Ncc Co Ltd | 負荷制御を行う大規模クライアントサーバーシステム |
JPH1091609A (ja) * | 1996-09-10 | 1998-04-10 | Mitsubishi Electric Corp | 分散シミュレーションシステム |
JPH10275126A (ja) * | 1997-03-31 | 1998-10-13 | Nri & Ncc Co Ltd | 負荷分散制御を行うクライアントサーバーシステム |
JPH10275125A (ja) * | 1997-03-31 | 1998-10-13 | Nri & Ncc Co Ltd | 多数のコンピュータが参加する情報分配応答システム |
JPH11110360A (ja) * | 1997-09-30 | 1999-04-23 | Hitachi Software Eng Co Ltd | トランザクション分配方法およびシステムおよびトランザクション分配処理用記録媒体 |
JPH11250021A (ja) * | 1998-03-05 | 1999-09-17 | Nippon Telegr & Teleph Corp <Ntt> | ネットワーク上での分散処理方法及びそのシステム並びに分散処理プログラムを記録した媒体 |
JPH11265365A (ja) * | 1997-10-29 | 1999-09-28 | Lucent Technol Inc | 分散型実時間制御システムのモジュールにおける過負荷応答方法 |
JPH11265366A (ja) * | 1997-10-29 | 1999-09-28 | Lucent Technol Inc | 分散型実時間制御システムのモジュールにおける過負荷応答方法 |
JP2000259539A (ja) * | 1999-03-12 | 2000-09-22 | Hitachi Information Technology Co Ltd | トランザクション分配方法及び装置 |
JP2001092766A (ja) * | 1999-09-20 | 2001-04-06 | Hitachi Ltd | クライアントサーバシステムおよびネーミングサービス方法 |
JP2001109638A (ja) * | 1999-10-06 | 2001-04-20 | Nec Corp | 推定伸長率に基づくトランザクション負荷分散方法及び方式並びにコンピュータ可読記録媒体 |
JP2001273225A (ja) * | 2001-02-15 | 2001-10-05 | Hitachi Ltd | 代理サーバ選択装置および代理サーバ |
JP2002091631A (ja) * | 2000-09-20 | 2002-03-29 | Pfu Ltd | ネットワークシステム |
JP2002091937A (ja) * | 2000-07-27 | 2002-03-29 | Hewlett Packard Co <Hp> | スペアサーバを自動でアクティブにするサーバ |
JP2002189650A (ja) * | 2000-12-20 | 2002-07-05 | Hitachi Ltd | 計算機制御方法及び装置並びにその処理プログラムを格納した記録媒体 |
JP2002222123A (ja) * | 2001-01-25 | 2002-08-09 | Ibm Japan Ltd | 接続受付システム、受付サーバ、クライアント端末、接続受付管理方法、記憶媒体、コンピュータプログラム |
JP2003256394A (ja) * | 2002-03-05 | 2003-09-12 | Nec Corp | トランザクション処理の負荷分散方法およびそのシステム |
JP2003295983A (ja) * | 2002-03-18 | 2003-10-17 | Internatl Business Mach Corp <Ibm> | コンピュータ・サーバの電力消費を管理する方法およびプログラム |
WO2004006116A1 (ja) * | 2002-07-08 | 2004-01-15 | Fujitsu Limited | 並列演算プログラム、並列演算システムおよび並列演算管理装置 |
US7062768B2 (en) | 2001-03-21 | 2006-06-13 | Nec Corporation | Dynamic load-distributed computer system using estimated expansion ratios and load-distributing method therefor |
JP2006178851A (ja) * | 2004-12-24 | 2006-07-06 | Nec Corp | 障害監視方法、障害監視システムおよびプログラム |
JP2006245993A (ja) * | 2005-03-03 | 2006-09-14 | Mitsubishi Electric Corp | ネットワーク診断装置 |
JP2007042083A (ja) * | 2005-06-30 | 2007-02-15 | Hitachi Ltd | データベース管理システム構築方法、装置、プログラム及び記録媒体 |
WO2007088728A1 (ja) * | 2006-01-31 | 2007-08-09 | Hewlett-Packard Development Company, L.P. | 多層分散処理システム |
JP2009151381A (ja) * | 2007-12-18 | 2009-07-09 | Ns Solutions Corp | 情報処理装置、情報処理方法及びプログラム |
WO2009093329A1 (ja) * | 2008-01-25 | 2009-07-30 | Fujitsu Limited | 仮想記憶装置,同装置の制御部及び制御方法 |
JP2009258777A (ja) * | 2008-04-11 | 2009-11-05 | Toshiba Corp | 医用画像管理サーバおよび医用画像管理システム |
US7617309B2 (en) | 2001-12-27 | 2009-11-10 | Fuji Xerox Co., Ltd. | Network system, information management server, and information management method |
JP2009301581A (ja) * | 1998-05-20 | 2009-12-24 | Alcatel-Lucent | タスクを割り当てる方法、データ処理システム、クライアントデータ処理ノードおよび機械可読記憶媒体 |
JP2010282348A (ja) * | 2009-06-03 | 2010-12-16 | Nec System Technologies Ltd | 情報収集装置および情報収集方法 |
JP2011076470A (ja) * | 2009-09-30 | 2011-04-14 | Nomura Research Institute Ltd | 負荷管理装置、情報処理システムおよび負荷管理方法 |
JP2011076469A (ja) * | 2009-09-30 | 2011-04-14 | Nomura Research Institute Ltd | 負荷管理装置、情報処理システムおよび負荷管理方法 |
JP2011129071A (ja) * | 2009-12-21 | 2011-06-30 | Mitsubishi Heavy Ind Ltd | 計算機管理装置、計算機管理方法及び計算機管理プログラム |
JP2011154631A (ja) * | 2010-01-28 | 2011-08-11 | Fujitsu Ltd | 確定クロック判定プログラム及び方法、並びにノード装置 |
JP2011204128A (ja) * | 2010-03-26 | 2011-10-13 | Nomura Research Institute Ltd | 運用管理装置および運用管理方法 |
JP2012053899A (ja) * | 2011-10-26 | 2012-03-15 | Nomura Research Institute Ltd | 運用管理装置および情報処理システム |
JP2012203661A (ja) * | 2011-03-25 | 2012-10-22 | Toshiba Corp | サーバ装置、通信方法およびプログラム |
JP2013030863A (ja) * | 2011-07-27 | 2013-02-07 | Nec Corp | スイッチ装置の制御システム、その構成制御装置および構成制御方法 |
JP2013533556A (ja) * | 2010-07-08 | 2013-08-22 | シマンテック コーポレーション | ゲスト仮想機械とやり取りするための技法 |
JP2014052680A (ja) * | 2012-09-05 | 2014-03-20 | Fujitsu Ltd | プロセス数制御プログラム、プロセス数制御方法、および情報処理装置 |
US8909763B2 (en) | 2011-03-31 | 2014-12-09 | Mitsubishi Heavy Industries, Ltd. | Computing-device management device, computing-device management method, and computing-device management program |
US9576061B2 (en) | 2013-06-13 | 2017-02-21 | Fujitsu Limited | Information processing system and data update control method |
US9996372B2 (en) | 2015-03-27 | 2018-06-12 | Fujitsu Limited | Information processing apparatus, information processing system and program |
US11487587B2 (en) | 2018-05-30 | 2022-11-01 | Fujitsu Limited | Information processing system and method for controlling information processing system |
-
1994
- 1994-04-30 JP JP6114557A patent/JPH07302242A/ja active Pending
Cited By (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09269925A (ja) * | 1996-04-02 | 1997-10-14 | Nri & Ncc Co Ltd | 負荷制御を行う大規模クライアントサーバーシステム |
JPH1091609A (ja) * | 1996-09-10 | 1998-04-10 | Mitsubishi Electric Corp | 分散シミュレーションシステム |
JPH10275126A (ja) * | 1997-03-31 | 1998-10-13 | Nri & Ncc Co Ltd | 負荷分散制御を行うクライアントサーバーシステム |
JPH10275125A (ja) * | 1997-03-31 | 1998-10-13 | Nri & Ncc Co Ltd | 多数のコンピュータが参加する情報分配応答システム |
JPH11110360A (ja) * | 1997-09-30 | 1999-04-23 | Hitachi Software Eng Co Ltd | トランザクション分配方法およびシステムおよびトランザクション分配処理用記録媒体 |
JPH11265365A (ja) * | 1997-10-29 | 1999-09-28 | Lucent Technol Inc | 分散型実時間制御システムのモジュールにおける過負荷応答方法 |
JPH11265366A (ja) * | 1997-10-29 | 1999-09-28 | Lucent Technol Inc | 分散型実時間制御システムのモジュールにおける過負荷応答方法 |
JPH11250021A (ja) * | 1998-03-05 | 1999-09-17 | Nippon Telegr & Teleph Corp <Ntt> | ネットワーク上での分散処理方法及びそのシステム並びに分散処理プログラムを記録した媒体 |
JP2009301581A (ja) * | 1998-05-20 | 2009-12-24 | Alcatel-Lucent | タスクを割り当てる方法、データ処理システム、クライアントデータ処理ノードおよび機械可読記憶媒体 |
JP2000259539A (ja) * | 1999-03-12 | 2000-09-22 | Hitachi Information Technology Co Ltd | トランザクション分配方法及び装置 |
JP2001092766A (ja) * | 1999-09-20 | 2001-04-06 | Hitachi Ltd | クライアントサーバシステムおよびネーミングサービス方法 |
US6986139B1 (en) | 1999-10-06 | 2006-01-10 | Nec Corporation | Load balancing method and system based on estimated elongation rates |
JP2001109638A (ja) * | 1999-10-06 | 2001-04-20 | Nec Corp | 推定伸長率に基づくトランザクション負荷分散方法及び方式並びにコンピュータ可読記録媒体 |
JP2002091937A (ja) * | 2000-07-27 | 2002-03-29 | Hewlett Packard Co <Hp> | スペアサーバを自動でアクティブにするサーバ |
JP2002091631A (ja) * | 2000-09-20 | 2002-03-29 | Pfu Ltd | ネットワークシステム |
JP2002189650A (ja) * | 2000-12-20 | 2002-07-05 | Hitachi Ltd | 計算機制御方法及び装置並びにその処理プログラムを格納した記録媒体 |
US8224963B2 (en) | 2001-01-25 | 2012-07-17 | International Business Machines Corporation | Managing requests for connection to a server |
US8396975B2 (en) | 2001-01-25 | 2013-03-12 | International Business Machines Corporation | Managing requests for connection to a server |
JP2002222123A (ja) * | 2001-01-25 | 2002-08-09 | Ibm Japan Ltd | 接続受付システム、受付サーバ、クライアント端末、接続受付管理方法、記憶媒体、コンピュータプログラム |
JP2001273225A (ja) * | 2001-02-15 | 2001-10-05 | Hitachi Ltd | 代理サーバ選択装置および代理サーバ |
US7062768B2 (en) | 2001-03-21 | 2006-06-13 | Nec Corporation | Dynamic load-distributed computer system using estimated expansion ratios and load-distributing method therefor |
US7617309B2 (en) | 2001-12-27 | 2009-11-10 | Fuji Xerox Co., Ltd. | Network system, information management server, and information management method |
US8069237B2 (en) | 2001-12-27 | 2011-11-29 | Fuji Xerox Co., Ltd. | Network system, information management server, and information management method |
JP2003256394A (ja) * | 2002-03-05 | 2003-09-12 | Nec Corp | トランザクション処理の負荷分散方法およびそのシステム |
JP2003295983A (ja) * | 2002-03-18 | 2003-10-17 | Internatl Business Mach Corp <Ibm> | コンピュータ・サーバの電力消費を管理する方法およびプログラム |
WO2004006116A1 (ja) * | 2002-07-08 | 2004-01-15 | Fujitsu Limited | 並列演算プログラム、並列演算システムおよび並列演算管理装置 |
JP2006178851A (ja) * | 2004-12-24 | 2006-07-06 | Nec Corp | 障害監視方法、障害監視システムおよびプログラム |
JP2006245993A (ja) * | 2005-03-03 | 2006-09-14 | Mitsubishi Electric Corp | ネットワーク診断装置 |
JP2007042083A (ja) * | 2005-06-30 | 2007-02-15 | Hitachi Ltd | データベース管理システム構築方法、装置、プログラム及び記録媒体 |
JP4595892B2 (ja) * | 2005-06-30 | 2010-12-08 | 株式会社日立製作所 | データベース管理システム構築方法、装置、プログラム及び記録媒体 |
JPWO2007088728A1 (ja) * | 2006-01-31 | 2009-06-25 | ヒューレット−パッカード デベロップメント カンパニー エル.ピー. | 多層分散処理システム |
GB2449037A (en) * | 2006-01-31 | 2008-11-05 | Hewlett Packard Development Co | Multilayer distributed processing system |
GB2449037B (en) * | 2006-01-31 | 2011-04-13 | Hewlett Packard Development Co | Multilayer distributed processing system |
US9015308B2 (en) | 2006-01-31 | 2015-04-21 | Hewlett-Packard Development Company, L.P. | Multilayer distributed processing system |
WO2007088728A1 (ja) * | 2006-01-31 | 2007-08-09 | Hewlett-Packard Development Company, L.P. | 多層分散処理システム |
JP2009151381A (ja) * | 2007-12-18 | 2009-07-09 | Ns Solutions Corp | 情報処理装置、情報処理方法及びプログラム |
WO2009093329A1 (ja) * | 2008-01-25 | 2009-07-30 | Fujitsu Limited | 仮想記憶装置,同装置の制御部及び制御方法 |
JP2009258777A (ja) * | 2008-04-11 | 2009-11-05 | Toshiba Corp | 医用画像管理サーバおよび医用画像管理システム |
JP2010282348A (ja) * | 2009-06-03 | 2010-12-16 | Nec System Technologies Ltd | 情報収集装置および情報収集方法 |
JP2011076470A (ja) * | 2009-09-30 | 2011-04-14 | Nomura Research Institute Ltd | 負荷管理装置、情報処理システムおよび負荷管理方法 |
JP2011076469A (ja) * | 2009-09-30 | 2011-04-14 | Nomura Research Institute Ltd | 負荷管理装置、情報処理システムおよび負荷管理方法 |
JP2011129071A (ja) * | 2009-12-21 | 2011-06-30 | Mitsubishi Heavy Ind Ltd | 計算機管理装置、計算機管理方法及び計算機管理プログラム |
JP2011154631A (ja) * | 2010-01-28 | 2011-08-11 | Fujitsu Ltd | 確定クロック判定プログラム及び方法、並びにノード装置 |
JP2011204128A (ja) * | 2010-03-26 | 2011-10-13 | Nomura Research Institute Ltd | 運用管理装置および運用管理方法 |
JP2013533556A (ja) * | 2010-07-08 | 2013-08-22 | シマンテック コーポレーション | ゲスト仮想機械とやり取りするための技法 |
JP2012203661A (ja) * | 2011-03-25 | 2012-10-22 | Toshiba Corp | サーバ装置、通信方法およびプログラム |
US9026584B2 (en) | 2011-03-25 | 2015-05-05 | Kabushiki Kaisha Toshiba | Server device, communication method, and program product for processing the transfer of screen changes |
US8909763B2 (en) | 2011-03-31 | 2014-12-09 | Mitsubishi Heavy Industries, Ltd. | Computing-device management device, computing-device management method, and computing-device management program |
JP2013030863A (ja) * | 2011-07-27 | 2013-02-07 | Nec Corp | スイッチ装置の制御システム、その構成制御装置および構成制御方法 |
JP2012053899A (ja) * | 2011-10-26 | 2012-03-15 | Nomura Research Institute Ltd | 運用管理装置および情報処理システム |
JP2014052680A (ja) * | 2012-09-05 | 2014-03-20 | Fujitsu Ltd | プロセス数制御プログラム、プロセス数制御方法、および情報処理装置 |
US9329902B2 (en) | 2012-09-05 | 2016-05-03 | Fujitsu Limited | Information processing method of controlling variation in a number of processes, storage medium, and information processing device |
US9576061B2 (en) | 2013-06-13 | 2017-02-21 | Fujitsu Limited | Information processing system and data update control method |
US9996372B2 (en) | 2015-03-27 | 2018-06-12 | Fujitsu Limited | Information processing apparatus, information processing system and program |
US11487587B2 (en) | 2018-05-30 | 2022-11-01 | Fujitsu Limited | Information processing system and method for controlling information processing system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH07302242A (ja) | 負荷分散方式 | |
US7523454B2 (en) | Apparatus and method for routing a transaction to a partitioned server | |
US7047360B2 (en) | Method and apparatus for adjusting performance of logical volume copy destination | |
US9218153B2 (en) | Servicing a print request from a client system | |
US8484348B2 (en) | Method and apparatus for facilitating fulfillment of web-service requests on a communication network | |
CN100397341C (zh) | 管理计算环境中的工作负载的方法和*** | |
US20060069761A1 (en) | System and method for load balancing virtual machines in a computer network | |
JP5041805B2 (ja) | データストレージシステムのサービス品質コントローラ及びサービス品質方法 | |
EP2108154B1 (en) | Distributed task system and distributed task management method | |
JP3172423B2 (ja) | プロセッサ資源を管理するための装置および方法 | |
JPWO2018180369A1 (ja) | センサネットワークシステム | |
US9462077B2 (en) | System, method, and circuit for servicing a client data service request | |
EP1679595A1 (en) | Information system, load control method, load control program, and recording medium | |
US8171060B2 (en) | Storage system and method for operating storage system | |
US10305724B2 (en) | Distributed scheduler | |
US20060224785A1 (en) | Device and method for input and output of data | |
JP2001084195A (ja) | イベント制御手段を備えたネットワーク管理システム | |
US7600229B1 (en) | Methods and apparatus for load balancing processing of management information | |
US7664917B2 (en) | Device and method for caching control, and computer product | |
JPH05216842A (ja) | 資源管理装置 | |
Chatterjee et al. | A new clustered load balancing approach for distributed systems | |
JPWO2020161788A1 (ja) | 情報処理装置、情報処理システム、プログラム及び情報処理方法 | |
EP0954796B1 (en) | Procedure to detect and disperse convoys for queued gate servers | |
JPH09138776A (ja) | トランザクション処理の負荷分散方式 | |
CN114090256A (zh) | 一种基于云计算的应用交付负载管理方法及其*** |