JP4028847B2 - 共通作業キュー環境における最適格サーバ - Google Patents

Description

本発明は、一般に、並列処理環境に関し、より詳細には、共用キュー（sharedqueue）を用いた並列処理システムに関する。

現在のデータ処理環境では、１つまたは複数のクライアントの処理要求を処理するために複数のシステムを備えることは珍しくない。例えば、トランザクション処理システムなど２つ以上のシステムが、通信ネットワークを介して１つまたは複数のクライアントに接続（interface）され得る。この環境では、クライアントがそれらのシステムのうちの１つで実施すべきタスクを有するときには、そのクライアントは、そのシステムで実行中のアプリケーションによる処理を要求するために、所望のシステムに、入力メッセージを送信する。対象システムはそのメッセージをキュー（queue；待ち行列）に入れ、処理のためにそのアプリケーションにメッセージを提供する。処理が完了すると、アプリケーションは、ネットワークを介してクライアントに送信するために出力メッセージをキューに入れる。

この環境のマルチプロセッシングの態様を利用して、最初にクライアント、システムＡによってタスクを割り当てられたシステムは、そのキューから入力メッセージを取り出し、その入力メッセージを処理のために第２のシステム、システムＢに転送することができる。システムＢによって処理が完了すると、応答（出力メッセージ）がシステムＡに転送され、クライアントへの送信のためにシステムＡのキューに入れられる。したがって、このようにして、複数のシステムを利用して多数のクライアントからの処理要求を処理することが可能である。

しかしながら、この構成にはいくつかの欠点がある。例えば、システムＡに障害が起こった場合には、システムＡのキュー上のどの作業にもアクセスすることができない。したがって、クライアントは、そのトランザクションを処理させるのをシステムＡがオンライン状態に復旧するまで待たざるを得ない。

これらの欠点に対応するために、複数のデータ処理システムのうちのいずれかによる処理のために入力メッセージをストアする共用（shared）、または共通（commnon）のキューを設けることができる。共通キュー・サーバは、それらのメッセージを受け取り、共用キューに入れる、その結果それらのメッセージを処理するのに利用可能な能力を有するシステムが取り出すことができる。動作に際して、利用可能な能力を有するシステムは、キューに入れられたメッセージを取り出し、必要な処理を実行し、適当な応答メッセージを共用キューに戻す。したがって、共用キューは、処理を要求しているクライアントとその処理を実行するデータ処理システムの間の両方向に送信されるメッセージをストアする。

それらのメッセージは、共用キューにエンキュー（enqueue）されるので、それらのメッセージはその共用キューにアクセスしている複数のシステムのうちのいずれかで実行中のアプリケーションによって処理できる。したがって、それら複数のシステム間での自動ワークロード（workload）管理が実現される。また、その共用キューに接続されたシステムのうちのいずれもメッセージを処理し得るので、処理冗長性（processingredundancy）の利点も得られる。メッセージを処理している特定のアプリケーションに障害が起きる（fail）場合には、別のアプリケーションが共用キューからそのメッセージを取り出し、クライアントに元のアプリケーションがオンライン状態に復旧するのを待たせる必要なしに処理を実行し得る。これは、そのデータ処理環境のクライアントに処理冗長性を提供する。

共通作業キュー（common work queue）を利用するとき、その共通キューに要求を処理依頼する（submit）すべてのクライアントは、その作業要求が妥当な時間内に完了されるであろうという期待を持つ。すべてのサーバがすべての要求を処理するのに適格であるとは限らない環境では、いつでも、そのキュー上にある作業要求の一部または全部を処理するのに適格なサーバがない可能性がある。作業要求が同期しているときには、その要求を処理依頼したクライアントに、その同期要求（synchronousrequest）を処理するのに適格なサーバがないことが通知されることは重要である。

より詳細には、共用作業キュー環境では、要求を出す１つまたは複数のクライアントと、それらの要求を処理する１つまたは複数のサーバがある。要求を処理するサーバのうちのすべてのサーバが、共通作業キュー上の各要求を処理する能力を持つとは限らない。これは、（ａ）サーバが特定のタイプの要求のみを処理するように構成されている、または（ｂ）サーバが特定のタイプの要求を処理するのに必要とされるリソースにアクセスすることができないことの結果として生じ得る。ケース（ａ）の一例としては、一部のサーバは特定のクライアントからの要求だけを処理するように構成され、他のサーバはすべての要求を処理するように構成されることが考えられる。ケース（ｂ）の一例としては、一部の要求が、すべてのサーバが接続できるとは限らない特定のストレージ・プール（記憶域プール）へのアクセスを必要とすることが考えられる。必要とされるストレージ・プールに接続できるサーバだけがそれらの要求を処理できる。

加国特許出願公開第２２８２９３１号（マイクロログ社（MICROLOG CORP））、「多種類の媒体タイプのコンタクトを処理することの可能なコンタクト・センター・システムおよび同システムを使用する方法（ACONTACT CENTER SYSTEM CAPABLE OF HANDLING MULTIPLE MEDIA TYPES OF CONTACTS ANDMETHOD FOR USING THE SAME）」には、異なる媒体タイプのコンタクトを受け取ることのできるキュー・コンポーネントを含み、それら異なる媒体タイプのコンタクトを共通キューに維持する、複数のエージェント・ワークステーションを用いたコンタクト・センター・システムおよび方法が提示されている。このシステムは、コンタクトの基準、エージェントの基準、またはそれら両方に基づいて、キューに入れられたコンタクトをエージェントまで経路指定する経路指定コンポーネントをさらに含む。

国際特許出願公開第９４２０９０４号（ロルム社（ROLM CO））、「キュー管理システムおよび方法（QUEUEMANAGING SYSTEM AND METHOD）」には、異なるクライアント・タイプを表す複数のクライアントにサービスするためのキュー管理システムが提示されている。キュー管理機能はクライアントを、そのクライアントのタイプにマッチする処理キューに入れる。電話システムの環境では、クライアントはメッセージであり、クライアントのタイプは様々な宛先に向けたメッセージでの符号化（coding）である。

欧州特許出願公開第１１２６３７１号（ソニー株式会社；株式会社次世代情報放送システム研究所（日本）（SONY CORP; INFORMATION BROADCASTING LAB I(JP)）、「サービス提供装置送信装置、受信装置、および受信方法（Serviceproviding apparatus transmitting apparatus, receiving apparatus, and receivingmethod）」には、サービスのディレクトリをクライアントに同報通信する（broadcast）クライアント／サーバ・システムが提示されている。クライアントは、サービスを提供するサーバを選択するために、それが受信したサービスのディレクトリをサーチする。

米国特許第５８８７１６８号（ベティ・ジェイ・パターソンら（PATTERSONBETTY J ET AL））、「データ保全性のための共用キュー構造用コンピュータ・プログラム製品（COMPUTER PROGRAM PRODUCT FORA SHARED QUEUE STRUCTURE FOR DATA INTERGRITY）」には、複数のシステムのうちのいずれかがクライアントによって受け取られたメッセージを処理できるようにする共用キューが提供されている。使用可能な処理能力を有する複数のシステムのうちのいずれかは、共用キューからメッセージを取り出し、そのメッセージを処理することができる。必要に応じて、クライアントに戻すために、メッセージへの応答が共用キューにエンキューされる。このキューを実装するために固有のリスト構造が提供される。このリスト構造は、複数のサブリスト、またはキュー・タイプから構成される。
加国特許出願公開第２２８２９３１号 国際特許出願公開第９４２０９０４号 欧州特許出願公開第１１２６３７１号 米国特許第５８８７１６８号

本発明の一目的は、共通キューを使用して、一部または全部のタイプの要求を処理するように適合されたサーバにより作業要求を処理する、米国特許第第５８８７１６８号のシステムのようなデータ処理システムを、異なるタイプのそれぞれでの適格性の状況、すなわち、それらのサーバのうちの少なくとも１つがそれぞれの前記異なるタイプの処理に適格であるかどうかを維持することによって改善することである。

本発明の別の目的は、同期要求を処理依頼しているクライアントに、その要求を処理するのに適格なサーバがあるかどうかを通知し、その要求を処理するのに適格なサーバがない場合にはそのクライアントが共用キューからその要求を削除できるようにすることである。

本発明のさらに別の目的は、それを処理するのに適格なサーバがない同期要求が処理依頼されるのを防ぐことである。

上記その他の目的は、本発明によって提供される、特許請求の範囲の請求項１、９および１３に記載のサーバを管理するシステム、方法およびプログラムを用いて達成される。このシステムは、メッセージを処理する複数のサーバと、サーバとの間でメッセージを送信し、受信する少なくとも１つのクライアントと、サーバのうちの少なくとも１つがメッセージ処理するのに適格であるかどうかを示すリストを維持するプロセッサ手段とを含む。好ましくは、サーバは、異なるタイプのメッセージを処理するように適合され、プロセッサ手段は前記リスト上に、異なるタイプのメッセージのそれぞれについて、サーバのうちの少なくとも１つがそれら異なるタイプのメッセージのそれぞれを処理するのに適格であるかどうかを示す手段を含む。

また、好ましい実施形態では、クライアントのそれぞれは、サーバのうちの少なくとも１つが所与のタイプのメッセージを処理するのに適格であるかどうか判定するために、そのクライアントがその所与のタイプのメッセージをサーバのうちの１つに送信する前にリストを読み取る手段も含む。さらに、プロセッサ手段は、リストに変更が加えられたときにクライアントに通知することができ、クライアントのそれぞれは、メッセージを処理するのに適格なサーバがなくなった場合には、共通キューからメッセージを削除する手段を含み得る。キュー・サーバは共通キューに必要なインターフェイスを提供する。任意の適当なキュー・サーバを使用することが可能であるが、共通キュー・サーバは、インターナショナル・ビジネス・マシーンズ・コーポレーションから市販されているzSeries処理環境で使用可能なカップリング・ファシリティ（Coupling Facility（結合機能））とすることが好ましい。

本発明のその他の利益および利点は、本発明の好ましい実施形態を詳細に図示する添付の図面を参照して提示される、以下の詳細な説明を考察すれば明らかになるであろう。

本発明は、一般に、複数の処理システムのうちのいずれかが、１つまたは複数のクライアントのためのメッセージを処理できるようにするシステムおよび方法に関するものである。好ましい実施形態では、複数のシステムでのクライアント・メッセージをキューに入れるために、共用キューなどの構造化外部記憶装置（structured external storage device）が設けられる。クライアントから入力メッセージが受け取られると、それらのメッセージはキューに入れられる。複数のシステムのうちの１つが使用可能な処理能力を有しているときには、そのシステムがメッセージを取り出し、メッセージを処理し、応答をキューに入れる。

図１は、クライアント／サーバ環境１０での共用キューを示すブロック図である。このクライアント／サーバ環境は、１つまたは複数のネットワーク１６を介して複数の処理システム１４に接続される１つまたは複数のクライアント１２を含む。クライアント１２が処理すべきトランザクションを有する時には、そのクライアントは共用キュー２０にメッセージをエンキューする。各クライアントから追加のメッセージが受け取られると、それらも共用キューにエンキューされる。各メッセージは、それが処理のためにシステム１４の１つによって取り出されるまで共用キュー２０上に留まる。

システム１４が、それが別のトランザクションを処理する能力があると判定したときには、そのシステム１４は、共用キュー２０からメッセージをデキュー（dequeue）する。次いで、システム１４は、そのメッセージを処理し、その入力メッセージを生成したクライアントへの適当な応答を共用キュー２０に入れる。共通キュー・サーバ２２は、共用キュー２０とシステム１４の間の必要なインターフェイスを提供する。入力メッセージが共用キュー２０にエンキューするために共通キュー・サーバによって受け取られると、キュー・サーバ２２はそのメッセージを１つまたは複数のバッファに入れ、次いで、このデータを共用キューに転送する。本発明の実施には、任意の適当な共通キューおよび共通キュー・サーバが使用され得る。ただし、この共通キュー・サーバは、インターナショナル・ビジネス・マシーンズ・コーポレーションから市販されているzSeries処理環境で使用可能なカップリング・ファシリティとすることが好ましい。このカップリング・ファシリティは、本発明の好ましい実装形態で使用される様々な機能（feature）を提供する。

前述のように、共通作業キューが使用されるときに発生し得る１つの問題は、いつでも、キュー上の作業要求の一部または全部を処理するのに適格なサーバがない可能性があることである。この要求に対応するために、本発明は「最適格サーバ」と呼ばれる機能を利用する。この最適格サーバとは、要求を処理するもっとも優れた能力を有するサーバである。最適格サーバの状況を知ることによって、クライアントは、その要求を処理するのに適格なサーバの有無に基づいて共通作業キューに要求を処理依頼することができる。

それを処理するのに適格なサーバがない同期要求が処理依頼されるのを防ぐために、「最適格サーバ状況（ＭＥＳＳ：Most Eligible Server Status）」レコードが維持される。このＭＥＳＳレコードは、要求を処理するのに適格なサーバの有無を示し、サーバがある場合には、どのタイプの要求が処理するのに適格であるかを示す。適格なサーバの数は維持する必要はないが、維持することができる。ＭＥＳＳレコードは、要求を処理するのに適格な少なくとも１つのサーバがあることを示し、そのため、各要求が無期限にキュー上に留まることはない。要求を処理依頼する前に、クライアントは、瞬時にＭＥＳＳレコードを読み取ってその要求を処理するのに適格なサーバがあるかどうか判定する。サーバがある場合には、そのクライアントはその要求をキューに入れる。

好ましくは、ＭＥＳＳレコードに変更があった場合には、クライアントにその変更が通知される。ＭＥＳＳがその前の状況より低い、すなわち、適格なサーバがない、または特定のタイプの要求が処理できなくなった場合には、そのクライアントは、処理するのに適格なサーバがなくなったその要求をキューから削除する選択肢を有する。

図２に、最適格サーバ状況レコードが使用され得る環境を示す。一例として、２つのサーバ３２、３４が共通作業キュー３６からの要求を処理しているものとする。両サーバともディスク・プール４０に接続されるが、テープ・プール４２にはそれらのサーバのうちの一方だけしか接続され得ない。サーバ３４は、テープ・リソースを必要とする要求を処理し得る唯一のサーバである。サーバ３４が利用可能である間は、ＭＥＳＳレコードは、テープを必要とする要求を処理するのに使用可能なサーバがあることを示す。サーバ３４が使用可能でないときには、ＭＥＳＳレコード４４は、テープ要求を処理するのに使用可能なサーバがないことを示すように更新され、クライアント４６および５０は既存の未処理のテープ要求を実行しないで、しかるべく新しい要求を処理依頼することができる。

図３に、最適格サーバ状況レコードを更新する手順を示す。ステップ６０および６２で表すように、サーバは、それが共通作業キューに接続されると、それが要求を処理する適格性が、現在ＭＥＳＳレコードに反映されているものより大きいかどうか判定する。そうである場合には、ステップ６４でＭＥＳＳレコードが更新され、そうでない場合には、ステップ６６で表すように、ＭＥＳＳレコードに変更は加えられない。また、このレコードは、接続されたサーバの適格性に変更があった場合にも更新され得る。この判定を行うために、各サーバの適格性状況のレコードが維持され得る。サーバが共通作業キューから切断されたときに、ＭＥＳＳの状況が変更されている場合には、ＭＥＳＳレコードが更新され得る。

ＭＥＳＳレコードを維持し、更新するのに必要とされる処理は、任意の適当なプロセッサ手段によって実行され得る。例えば、キュー・サーバ２２を使用してこのリストを維持し、更新することもでき、処理システム１４のうちの１つまたは複数をこの目的のために使用することもでき、これらの機能を実施するために別個の装置を備えることも可能である。また、本発明が用いられる具体的環境に応じて、このプロセッサ手段は、単一のプロセッサを含むことも複数のプロセッサを含むこともできる。例えば、本発明が使用される具体的システムに応じて、ＭＥＳＳレコードは、単一の処理装置を備える標準的パーソナル・コンピュータによって、あるいは、例えば、複数または多重の処理装置を備えるコンピュータを含む、他の任意の適当なタイプのコンピュータによって維持され、更新され得る。さらに、必要とされる処理は、必要に応じて、主にソフトウェアによっても、主にハードウェアによっても、あるいはソフトウェアとハードウェアの組み合わせによっても実行され得ることが理解され得るであろう。

クライアント／サーバ環境における共用キューを示すブロック図である。 最適格サーバ状況レコードが使用される共用キュー処理環境を示す図である。 最適格サーバ状況レコードを更新する手順を示す図である。

Claims (6)

1. 共用キュー（２０）との間でメッセージを送信し、応答メッセージを受信する少なくとも１つのクライアント（１２）と、異なるタイプのメッセージを処理するように適合され、前記共用キュー（２０）からのクライアント・メッセージを処理し、前記共用キュー（２０）に応答メッセージを送信する複数のサーバ（１４）とを含み、前記サーバ（１４）のうちの少なくとも１つが、前記異なるタイプのメッセージのそれぞれを処理するのに適格であるサーバを示す最適格サーバ状況レコード（４４）を維持するサーバ管理システム（１０）であって、
   新たなサーバが前記共用キューに接続され、前記新たなサーバにおける異なるタイプのメッセージのそれぞれについて処理する適格性が前記最適格サーバ状況レコードにある適格性より高い場合には、前記最適格サーバ状況レコードを更新するプロセッサ手段と、
   前記クライアント（１２）のそれぞれが、前記サーバ（１４）のうちの少なくとも１つが所与のタイプのメッセージを処理するのに適格であるかどうか判定するために、前記クライアント（１２）が前記共用キュー（２０）に前記所与のタイプのメッセージを送信する前に前記最適格サーバ状況レコード（４４）を読み取る手段と、
   を有する、前記サーバ管理システム（１０）。
2. 前記共用キュー（２０）が維持される共通キュー・サーバ（２２）をさらに含む請求項１に記載のサーバ管理システム（１０）。
3. 前記最適格サーバ状況レコード（４４）が前記共通キュー・サーバ（２２）で維持される請求項２に記載のサーバ管理システム（１０）。
4. 前記クライアント（１２）のそれぞれが、所与のタイプのメッセージを処理するのに適格なサーバ（１４）がなくなった場合には前記共用キュー（２０）から前記メッセージを削除する手段を含む請求項１に記載のサーバ管理システム（１０）。
5. 少なくとも１つのクライアント（１２）を使用して共用キュー（２０）との間でメッセージを送信し、応答メッセージを受信するステップと、異なるタイプのメッセージを処理するように適合され、前記共用キューからのクライアント・メッセージを処理し、前記共用キューに応答メッセージを送信する複数のサーバ（１４）を準備するステップからなり、前記サーバ（１４）のうちの少なくとも１つが、前記異なるタイプのメッセージのそれぞれを処理するのに適格であるサーバを示す最適格サーバ状況レコード（４４）を維持するサーバ（１４）管理の方法であって、
   新たなサーバが前記共用キューに接続され、前記新たなサーバにおいて、異なるタイプのメッセージのそれぞれについて処理する適格性が前記最適格サーバ状況レコードにある適格性より高い場合には、前記最適格サーバ状況レコードを更新するステップと、
   前記クライアント（１２）のそれぞれが、前記共用キュー（２０）に前記所与の異なるタイプのメッセージを送信する前に前記最適格サーバ状況レコード（４４）を読み取るステップとを含む、前記サーバ管理（１４）管理の方法。
6. 前記クライアント（１２）のそれぞれが、所与のタイプのメッセージを処理するのに適格なサーバ（１４）がなくなった場合には前記共用キュー（２０）からメッセージを削除するステップをさらに含む請求項５に記載の方法。
   ５に記載の方法。

Images