JP3762846B2 - サーバのグループに関する作業負荷管理を行うデータ処理装置および方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、１つのコンピューティング装置（クライアント）が別のコンピューティング装置（サーバ）に対してクライアントの作業の一部を実行するように要求する、分散形式のクライアント／サーバ・コンピューティング・システムに関する。
【０００２】
【従来の技術】
情報技術の世界では、ここ数年、クライアント／サーバ・コンピューティングがますます重要になっている。この形式の分散コンピューティングでは、１つの計算機がその作業の一部を、たとえばその作業を実行するのにより適していると考えられる別の計算機に代行させることができる。たとえば、サーバは、膨大な量のデータの記憶機構を管理するデータベース・プログラムを実行する高性能コンピュータであり、クライアントは、そのローカル・プログラムの１つで使用するためのそのデータベースに対して情報を要求する単なるデスクトップ・パーソナル・コンピュータ（ＰＣ）である。
【０００３】
今日のクライアント／サーバ・コンピュータ・ネットワークでは、メッセージ待ち行列化（メッセージ・ブローカリングとも呼ぶ）データ処理技法が普及している。この技法は、クライアントとサーバの両方がオペレーティング・システム、データ形式、および通信プロトコルに関して互いにきわめて異なっている場合であっても、クライアントがサーバと通信することができるようにする。さらに、この技法の非同期性のために、クライアントはサーバにメッセージを送り、サーバはそのメッセージを待ち行列に記憶し、そのメッセージを後で処理して応答することができる。これは、クライアントとサーバがリアルタイムで対話する必要があった（たとえば、クライアントはサーバが応答するのを待ってから、他のタスクに進む）同期クライアント／サーバ・モデルとはまったく異なる。
【０００４】
メッセージ待ち行列化と、その市販の製品については、「Messaging and Queuing Using the MQI」（B.Blakeley, H.Harris & R. Lewis, McGraw-Hill, 1994）およびＩＢＭコーポレイションから入手可能な刊行物「An Introduction to Messaging and Queuing」(ＩＢＭ資料番号 GC33-0805-00）および「MQSeries - Message Queue Interface Technical Reference」（ＩＢＭ資料番号 SC33-0850-01）に記載されている。「ＩＢＭ」および「ＭＱＳｅｒｉｅｓ」は、ＩＢＭコーポレイションの商標である。ＭＱＳｅｒｉｅｓメッセージング・ソフトウェア製品は、トランザクション・メッセージング・サポート機能を備え、システム障害または通信障害が発生した場合でも、確実な１回のみのメッセージ配信を行うメッセージング・プロトコルに従って、作業論理単位内でメッセージを同期させる。ＭＱＳｅｒｉｅｓ製品は、受信側システムによって無事に記憶されたことが確認されるまで、メッセージを送信側システム上の記憶域から最終的に削除しないことおよび高度な回復システムの使用によって確実な配信を実現する。正常な記憶を確認すると、メッセージの転送をコミットする前に、送信側システムの記憶域からのメッセージの削除と受信側システムにおける記憶域への挿入の両方が「不確か」な状態に維持され、万一障害が起こった場合には自動的にバックアウトすることができる。このメッセージ送信プロトコルとそれに付随するトランザクション概念および回復機能については、国際特許出願ＷＯ９５／１０８０５号および米国特許第５４６５３２８号に記載されている。
【０００５】
メッセージおよび待ち行列化ソフトウェア・アーキテクチャを使用するネットワークなどの非同期クライアント／サーバ・ネットワークでは、サーバのグループを設けて、そのグループの各サーバが或るクライアントの要求（以下「クライアント要求」、「作業要求」または「要求」とも称する）を満たすことができるようにすることが一般的になりつつある。このようにすると、１つのサーバがビジーの場合、要求を別のサーバに転送することができるため、或るクライアントの要求に対してより迅速に対処することができる。一般には、どのサーバに特定の要求の処理を割り当てるべきかに関する決定は、クライアント側の作業負荷管理ユニットが、各サーバからの使用可能性データを決定の根拠として使用して行う。このような使用可能性データのすべてがまだ入手可能でない場合、作業負荷管理ユニットは、そのようなデータを受け取るまで待ってから、完全なデータ・セットを使用してサーバを決定する。その後、クライアント要求は、作業負荷管理ユニットによって選択されたサーバの識別標識が付加されて、送信待ち行列に入れられ、選択されたサーバへの送信を待つ。また、クライアントは、選択されたサーバの識別標識を含む、待ち行列化された要求に関する何らかの情報をローカル記憶域に書き込み、それによって、送信されたクライアント要求をサーバが受け取らなかったというような送信上の問題が発生した場合には、クライアントからサーバへその要求を再送することができるようにする。
【０００６】
【発明が解決しようとする課題】
前述の公知技術が不利であるのは、作業負荷管理ユニットが、各サーバの使用可能性データの状態を絶えず調べて、そのようなデータをすべてのサーバから完全に受信した時点を決定しなければならない複雑なソフトウェア部分を含む必要があるためである。この複雑なソフトウェア・プログラミングによって、システム全体に多大な余分のコストが増える。
【０００７】
さらに、使用可能性データをまだ全部受け取っていない場合、サーバ・グループに要求を送信することができず、したがって、データ送信プロセスがクライアント側で停止する。これは、高速の送信速度がきわめて重要な環境では特に不利である。
【０００８】
【課題を解決するための手段】
第１の側面に従って、本発明は、非同期クライアント／サーバ・コンピューティング・システムにおけるクライアント内でサーバのグループに関する作業負荷管理を行うデータ処理装置を提供する。このデータ処理装置は、クライアント上で実行中のクライアント・アプリケーションから作業要求を受け取る手段と、この作業要求を最初に受け取ったときにグループ内のすべてのサーバに関する使用可能性データが入手可能でない場合であっても、そのときに現に入手可能なグループ内の各サーバに関する使用可能性データを調べ、当該使用可能性データに基づいて受け取った作業負荷要求を満たすために使用すべきグループ内の特定のサーバを選択する手段と、受け取った作業要求にその送信宛先が特定のサーバであることを示す識別標識を付加してクライアントの側の送信待ち行列に入れ、この作業要求が特定のサーバへ送信されるまで、この作業要求を送信待ち行列内で待機させる手段とを有する。
【０００９】
好ましくは、このデータ処理装置は、作業要求が最初に受け取られたときから特定のサーバへ送信されるまでの期間に、使用可能性データが変更されたか否かを決定する手段と、使用可能性データが変更された場合、当該変更された使用可能性データを調べ、当該変更された使用可能性データに基づいて受け取った作業要求を満たすために使用すべきグループ内の新しいサーバを選択する手段と、新しいサーバが特定のサーバと異なる場合、作業要求がグループ内の特定のサーバとは異なる新しいサーバに送られるように、送信待ち行列に入れられている作業要求の送信宛先を示す識別標識を更新する手段とを有する。
【００１０】
さらに好ましくは、変更された使用可能性データは、作業要求が最初に受け取られたときに入手可能でなかったグループ内のサーバに関する使用可能性データを含む。あるいは、変更された使用可能性データは、作業要求が最初に受け取られたときに入手可能であったグループ内のサーバに関する使用可能性データとは異なる変更済みの使用可能性データを含む。
【００１１】
第２の側面に従って、本発明は、前述したデータ処理装置の機能を実行する方法を提供する。
【００１２】
したがって、本発明によると、使用可能性データをすべて受け取ったか否かを絶えず調べる必要がないため、作業負荷管理ユニット・ソフトウェアが大幅に単純化される。その代わりに、単純なソフトウェア・アーキテクチャを使用して、すべてのクライアント要求を同様に取り扱うことができる。すなわち、或るクライアントによって要求が発行されるとただちに、使用可能性データの現状態を使用して決定が行われ、その要求が送信待ち行列に送られる。また、そのクライアント要求自体を記録するのと同じ動作の一部として、その要求の宛先が永続記憶域に記録される。
【００１３】
要求が送信待ち行列から選択されたサーバへ送信される前に新しい使用可能性データが入手可能になった場合、新たなサーバの選択を行うことができ、その要求を異なるサーバに送られるように更新することができる。しかし、要求が送信待ち行列から送信される前に新しい使用可能性データが入手可能でない場合、その要求は、グループ内の各サーバの使用可能性データが入手可能であるか否かに関係なく、選択されたサーバに送られる。したがって、本発明の追加の利点は、作業負荷管理ユニットが各サーバからの使用可能性データが入手可能になるまで待たなければならないことに起因する送信遅延がないということである。本発明は、作業要求を受け取った時点で入手可能な使用可能性データを使用して、グループ内のどのサーバを選択すべきかに関する最初の決定を行う。まれな状況でのみ新しい使用可能性データが現れ、その宛先の新たな記録を行う必要がある。
【００１４】
【発明の実施の形態】
図１では、クライアント１１が通信ネットワーク１３を介してサーバ（１２１、１２２、１２３）のグループ１２と通信を行う。クライアント１１とサーバ・グループ１２は、前述のＭＱＳｅｒｉｅｓなどのメッセージングおよび待ち行列化ソフトウェア製品を実行しており、それによってクライアントとサーバの間で非同期通信が行われる。すなわち、クライアントがサーバに作業要求を送るとき、サーバは動作可能状態でなくてもよい。要求は待ち行列に入れられ、サーバは後で動作可能になったときに、その待ち行列化された要求を取り出すことができる。メッセージングおよび待ち行列化製品は、クライアント１１がネットワーク１３を介してサーバ・グループ１２と対話することができるようにするために必要な通信プロトコル変換も行う。
【００１５】
好ましい実施形態では、クライアントとサーバは、ネットワーク１３によって接続された別々の処理ユニット内にあるが、本発明は、このアーキテクチャには限定されない。クライアントとサーバ・グループが同じデータ処理ユニット内にあってもよいからである。
【００１６】
クライアント１１は、クライアント・アプリケーション１１１とメッセージングおよび待ち行列化ソフトウェア・システム（以下「メッセージングおよび待ち行列化ソフトウェア」と称する）１１２とを含み、当該ソフトウェア１１２は、作業負荷管理ユニット１１２ａと送信待ち行列１１２ｂを含む。クライアント・アプリケーション１１１は、サーバに作業要求を発行する消費側ソフトウェア部分である。サーバが要求された作業を行うと、その結果がクライアント・アプリケーション１１１に返される場合がある。送信待ち行列１１２ｂは、メッセージングおよび待ち行列化ソフトウェアの一部であり、クライアント・アプリケーション１１１から受け取った作業要求を、ネットワーク１３を介してサーバ・グループ１２に伝える前に待ち行列化するために使用される。作業負荷管理ユニット１１２ａも、メッセージングおよび待ち行列化ソフトウェアの一部であり、クライアント・アプリケーション１１１から受け取った各作業要求ごとに、サーバ・グループ１２から１つのサーバ１２１、１２２、または１２３を選択する役割を果たすソフトウェア要素である。
【００１７】
作業負荷管理ユニット１１２ａは、ネットワーク１３を介してグループ内の各サーバ１２１、１２２、１２３に関するデータ（以下「使用可能性データ」と称する）を受け取る。この使用可能性データは、各サーバがクライアントからの新しい作業要求を受け入れる用意があるか否かに関する各サーバの現在の使用可能性を示す。作業負荷管理ユニットは、この使用可能性データを使用して、特定の作業要求を満たすためにどのサーバ１２１、１２２、または１２３を選択すべきかを決定する。
【００１８】
以下、図２のフローチャートを参照しながら、メッセージングおよび待ち行列化ソフトウェア１１２の動作を説明する。
【００１９】
ステップ２１で、メッセージングおよび待ち行列化ソフトウェア１１２は、クライアント・アプリケーション１１１から作業要求を受け取る。ステップ２２で、作業負荷管理ユニット１１２ａは、データ使用可能性テーブル（図３を参照）を調べて、受け取った作業要求を処理するグループ１２内のサーバの使用可能性を決定する。
【００２０】
図３で、作業要求を受け取った時点を時点１と称する。時点１で、使用可能性テーブルは、（時点１とサーバ１とが交点を成すボックス内で「使用可能」を表す文字Ａによって示されているように）作業要求を受け取るためにサーバ１（１２１）が使用可能であることを示すとともに、（時点１とサーバ２とが交点を成すボックス内の「使用不能」を表す文字ＮＡによって示されているように）サーバ２（１２２）が作業要求を受け取るために使用不能であることを示している。また、時点１で、図３の使用可能性テーブルにはサーバ３（１２３）の項目がなく、したがってサーバ３がその使用可能性データをクライアント１１のメッセージングおよび待ち行列化ソフトウェア１１２にまだ供給していないことを示していることに留意されたい。
【００２１】
時点１において使用可能性データがこの状態の場合、サーバ１は使用可能で、サーバ２は使用不能であり、サーバ３が使用可能であるか否かが不明である。このため、作業負荷管理ユニット１１２ａは、この作業要求に割り当てるためにサーバ１（１２１）を選択する（ステップ２３）。次に、この作業要求は、送信待ち行列１１２ｂに入れられ（ステップ２４）、そこで、この作業要求がサーバ１（１２１）に送られるべきであることを示す識別標識がこの作業要求に付加される。次に、この作業要求は、サーバ１（１２１）が要求を受け取る準備が整ったことを示すまで、送信待ち行列１１２ｂに入っている（場合によっては、サーバ１はクライアント１１とは異なる時間帯にあり、時点１で動作可能でない）。
【００２２】
時点１より少し後の時点２では、クライアント１１は更新された使用可能性データを受け取っており、ステップ２５で、その受信がメッセージングおよび待ち行列化ソフトウェア１１２によって決定される。したがって、制御はステップ２２にループして戻り、そこで、作業負荷管理ユニット１１２ａが再び使用可能性データを調べ、今度は、（時点２とサーバ１とが交点を成すボックスで「使用可能」を表す文字Ａによって示されているように）サーバ１がまだ使用可能であり、（時点２とサーバ２とが交点を成すボックスで「使用可能」を表す文字Ａによって示されているように）サーバ２が使用可能になっており、（時点２とサーバ２とが交点を成すボックスで「使用不能」を表す文字ＮＡによって示されているように）サーバ３は使用不能であることを決定する。したがって、時点１と時点２の間の期間に、サーバ・グループ１２からクライアント１１に新しい使用可能性データが送られており、サーバ２がその使用可能性を変え、前には使用可能性データを供給していなかったサーバ３が使用可能性データを供給している。
【００２３】
したがって、ステップ２３で、作業負荷管理ユニット１１２ａは、この更新された使用可能性データを使用して、３つのサーバのうちの１つを選択する。どのようなプログラム式作業負荷分散方式でも使用できるが、最も効率的なのは、２つのサーバが現に使用可能であり且つフローチャートの以前のパスでそのうちの一方のサーバがすでに選択されている場合、そのサーバがそのまま使用され、それによって送信待ち行列１１２ｂに入っている作業要求を変更する処理能力を費やさなくても済むようにする方式であろう。これによって、送信障害があった場合の回復のために、各作業要求ごとに選択されたサーバをローカル記憶域に記録しなければならないため、ローカル記憶域へのデータ書き込み動作も省かれる。したがって、この場合、ステップ２４の結果、待ち行列化された作業要求は更新されないことになる。
【００２４】
次に、時点２より後の時点３で、作業要求はまだ待ち行列１１２に入っており、新しい使用可能性データが受け取られている。ステップ２５で、そのようなデータの受信がメッセージングおよび待ち行列化ソフトウェア１１２によって通知される。したがって、制御はループしてステップ２２に戻り、そこで、図３の使用可能性テーブルを再び調べて、その新しい使用可能性データに基づいて選択されたサーバを変更する必要があるか否かが決定される。図３に示すように、今度はサーバ１が使用不能であり、サーバ２は依然として使用可能であり、サーバ３が使用可能になっている。したがって、ステップ２３で、作業負荷管理ユニット１１２ａは、サーバ２またはサーバ３の何れかを選択する。この場合も、この２つのサーバのどちらを使用するかを選択するために、任意の一般的な作業負荷分散アルゴリズムを使用することができる。「ラウンド・ロビン」方式によると、サーバ１の後の次の順番がサーバ２であるため、サーバ２が選択される（さらにその後の回ではサーバ３が次の順番になる）。
【００２５】
次に、ステップ２４で、送信待ち行列１１２ｂ内の作業要求が更新され、それによってその要求に、その宛先がサーバ１ではなくサーバ２であることを示す識別標識が付加される。このステップは、必要な場合、データ回復のための記録を提供するためにローカル記憶域への書き込みも行う必要がある。
【００２６】
この動作中のある時点で、選択されたサーバは送信待ち行列１１２ｂから作業要求を取り出し、その要求がネットワーク１３を介してサーバ２に送信され、したがって特定の作業要求についての図２の循環的な流れが終わる。
【００２７】
本発明の基本的前提条件は、使用可能性データがあまり頻繁に変化せず、ステップ２５で肯定の分岐をとってステップ２２に再びループし、図３のテーブルを再度調べる必要があるのはきわめてまれであるということである。したがって、サーバの最初の選択は、クライアント・アプリケーションによって要求が発行された後のきわめて早い時点で行われる。これによって作業要求が可能な限り迅速に送信待ち行列１１２ｂに入れられると同時に、現在入手可能な使用可能性データが使用され、それによってサーバ・グループへの送信のために要求を迅速かつ効率的に処理することができる。この初期サーバ選択を変更する必要があるのは、使用可能性データが変化した場合のみである。
【図面の簡単な説明】
【図１】本発明の好ましい実施形態が機能する基本的なクライアント／サーバ環境を示すブロック図である。
【図２】本発明の好ましい実施形態による、メッセージングおよび待ち行列化ソフトウェアによって行われるステップを示すフローチャートである。
【図３】本発明の好ましい実施形態による、メッセージングおよび待ち行列化ソフトウェアの作業負荷管理ユニットによって調べられる使用可能性データを示すテーブルである。
【符号の説明】
１１ クライアント
１１１ クライアント・アプリケーション
１１２ メッセージングおよび待ち行列化ソフトウェア
１１２ａ 作業負荷管理ユニット
１１２ｂ 送信待ち行列
１２ サーバ・グループ
１２１〜１２３ サーバ
１３ 通信ネットワーク

Claims (6)

1. 分散形式の非同期クライアント／サーバ・コンピューティング・システムにおけるクライアント内でサーバのグループに関する作業負荷管理を行うデータ処理装置であって、
   （ａ）前記クライアント上で実行中のクライアント・アプリケーションから作業要求を受け取る手段と、
   （ｂ）前記作業要求を最初に受け取ったときに前記グループ内のすべてのサーバに関する使用可能性データが入手可能でない場合であっても、そのときに現に入手可能な前記グループ内の各サーバに関する使用可能性データを調べ、当該使用可能性データに基づいて前記作業要求を満たすために使用すべき前記グループ内の特定のサーバを選択する手段と、
   （ｃ）前記作業要求にその送信宛先が前記特定のサーバであることを示す識別標識を付加して前記クライアントの側の送信待ち行列に入れ、前記作業要求が通信ネットワークを介して前記特定のサーバへ送信されるまで、前記作業要求を前記送信待ち行列内で待機させる手段と、
   （ｄ）前記作業要求が最初に受け取られたときから前記特定のサーバへ送信されるまでの期間に、前記使用可能性データが変更されているか否かを決定する手段と、
   （ｅ）前記使用可能性データが変更されている場合、当該変更された使用可能性データを調べ、当該変更された使用可能性データに基づいて前記作業要求を満たすために使用すべき前記グループ内の新しいサーバを選択する手段と、
   （ｆ）前記新しいサーバが前記特定のサーバと異なる場合、前記作業要求が前記特定のサーバとは異なる前記新しいサーバに送信されるように、前記送信待ち行列に入れられている前記作業要求の送信宛先を示す前記識別標識を更新する手段とを含み、
   前記手段（ｅ）は、前記変更された使用可能性データが前記グループ内の２つ以上のサーバが現に使用可能であることを示し且つ当該２つ以上のサーバのうちの１つのサーバが前記特定のサーバとしてすでに選択されている場合、前記特定のサーバをそのまま前記新しいサーバとして選択することを特徴とする、データ処理装置。
2. 前記変更された使用可能性データが、前記作業要求が最初に受け取られたときに入手可能でなかった前記グループ内の一のサーバに関する使用可能性データを含む、請求項１記載のデータ処理装置。
3. 前記変更された使用可能性データが、前記作業要求が最初に受け取られたときに入手可能であった前記グループ内の一のサーバに関する使用可能性データとは異なる変更済みの使用可能性データを含む、請求項１記載のデータ処理装置。
4. 分散形式の非同期クライアント／サーバ・コンピューティング・システムにおけるクライアント内でサーバのグループに関する作業負荷管理を行うデータ処理方法であって、
   （ａ）前記クライアント上で実行中のクライアント・アプリケーションから作業要求を受け取るステップと、
   （ｂ）前記作業要求を最初に受け取ったときに前記グループ内のすべてのサーバに関する使用可能性データが入手可能でない場合であっても、そのときに現に入手可能な前記グループ内の各サーバに関する使用可能性データを調べ、当該使用可能性データに基づいて前記作業要求を満たすために使用すべき前記グループ内の特定のサーバを選択するステップと、
   （ｃ）前記作業要求にその送信宛先が前記特定のサーバであることを示す識別標識を付加して前記クライアントの側の送信待ち行列に入れ、前記作業要求が通信ネットワークを介して前記特定のサーバへ送信されるまで、前記作業要求を前記送信待ち行列内で待機させるステップと、
   （ｄ）前記作業要求が最初に受け取られたときから前記特定のサーバへ送信されるまでの間に、前記使用可能性データが変更されているか否かを決定するステップと、
   （ｅ）前記使用可能性データが変更されている場合、当該変更された使用可能性データを調べ、当該変更された使用可能性データに基づいて前記作業要求を満たすために使用すべき前記グループ内の新しいサーバを選択するステップと、
   （ｆ）前記新しいサーバが前記特定のサーバと異なる場合、前記作業要求が前記特定のサーバとは異なる前記新しいサーバに送信されるように、前記送信待ち行列に入れられている前記作業要求の送信宛先を示す前記識別標識を更新するステップとを含み、
   前記ステップ（ｅ）は、前記変更された使用可能性データが前記グループ内の２つ以上のサーバが現に使用可能であることを示し且つ当該２つ以上のサーバのうちの１つのサーバが前記特定のサーバとしてすでに選択されている場合、前記特定のサーバをそのまま前記新しいサーバとして選択することを特徴とする、データ処理方法。
5. 前記変更された使用可能性データが、前記作業要求が最初に受け取られたときに入手可能でなかった前記グループ内の一のサーバに関する使用可能性データを含む、請求項４記載のデータ処理方法。
6. 前記変更された使用可能性データが、前記作業要求が最初に受け取られたときに入手可能であった前記グループ内の一のサーバに関する使用可能性データとは異なる変更済みの使用可能性データを含む、請求項４記載のデータ処理方法。

Images