分散キューイングとクラスター

分散キューイングとは、あるキュー・マネージャーから別のキュー・マネージャーにメッセージを送信することです。 受信キュー・マネージャーは、同じマシン上に置くことも別のマシン上に置くこ ともでき、近くにあっても地球の裏側にあってもメッセージを受信できます。 ローカル・キュー・マネージャーと同じプラットフォームで実行することも、 IBM® MQでサポートされるいずれかのプラットフォームで実行することもできます。 分散キューイング環境ですべての接続を手動で定義することも、クラスターを作成して IBM MQ に接続詳細の大部分を定義させることもできます。

分散キュー

図1: 分散キューイングのコンポーネントの概要
分散キューイングのコンポーネント。 アプリケーションはキュー・マネージャーに接続して、別のキュー・マネージャーにメッセージを伝送するためにキューをオープンします。
図の説明:
  • アプリケーションは、MQCONN 呼び出しを使用してキュー・マネージャーに接続します。 次に、アプリケーションは、メッセージをキューに書き込めるように MQOPEN 呼び出しを使用してキューをオープンします。
  • キュー・マネージャーごとに、所有する各キューの定義を持っています。 ローカル・キュー (このキュー・マネージャーによってホストされるキュー) の定義と、リモート・キュー (他のキュー・マネージャーによってホストされるキュー) の定義を持つことができます。
  • リモート・キュー宛のメッセージは、ローカル・キュー・マネージャーが伝送キュー 上に保持し、伝送キューは、それらのメッセージをリモート・キュー・マネージャーに転送できるようになるまでメッセージ・ストアに保持します。
  • キュー・マネージャーにはそれぞれ移動サービス と呼ばれる通信ソフトウェアが備えられています。 このソフトウェアを介してキュー・マネージャーは他のキュー・マネージャーと通信することができます。
  • トランスポート・サービス は、キュー・マネージャーが関与しないサービスであり、次のいずれかになります (プラットフォームにより異なります)。
    • SNA APPC
    • 伝送制御プロトコル / インターネット・プロトコル (TCP/IP) (Transmission Control Protocol/Internet Protocol (TCP/IP))
    • NetBIOS
    • SPX

メッセージの送信に必要なコンポーネント

メッセージがリモート・キュー・マネージャーに送信される場合、ローカル・キュー・マネージャーには伝送キューチャネルに関する定義が必要です。 チャネルは、2 つのキュー・マネージャーをつなぐ一方向の通信リンクです。 チャネルを使用して、リモート・キュー・マネージャーの任意の数のキュー宛てのメッセージを送ることができます。

チャネルの両側には、例えば送信側や受信側として定義される独立した定義が備えられています。 簡単なチャネルは、ローカル・キュー・マネージャーの送信側 チャネル定義とリモート・キュー・マネージャーの受信側 チャネル定義から構成されます。 これらの 2 つの定義は同じ名前でなければならず、両方の定義を合わせて 1 つのチャネルが構成されます。

メッセージの送受信を処理するソフトウェアは、メッセージ・チャネル・エージェント (MCA) と呼ばれます。 チャネルの両側に、メッセージ・チャネル・エージェント (MCA) が 1 つずつあります。

それぞれのキュー・マネージャーには 送達不能キュー (未配布メッセージ・キュー とも呼びます) が入っていなければなりません。 メッセージを宛先に送達できない場合、メッセージはこのキューに書き込まれます。

次の図は、キュー・マネージャー、伝送キュー、チャネル、および MCA の関係を示しています。
図2: メッセージの送信
チャネルを介してメッセージを送信する。 送信側でメッセージは伝送キューに書き込まれ、チャネルを通して受信側のアプリケーション・キューに送信されます。 MCA は、メッセージの送受信を処理します。

メッセージが戻るために必要なコンポーネント

リモート・キュー・マネージャーからアプリケーションにメッセージを返す必要がある場合は、以下の図に示すように、キュー・マネージャー間で反対方向に機能する別のチャネルを定義する必要があります。
図3: 両方向のメッセージ送信
送信側と受信側の両方のキュー・マネージャーに伝送キューとアプリケーション・キューがあり、MCA が両方向でメッセージを送信できるようにします。 メッセージは、各キュー・マネージャーの伝送キューから、他方のキュー・マネージャーのアプリケーション・キューに送信できます。 チャネルは、各方向のメッセージ転送用に定義されます。

クラスター

分散キューイング環境内のすべての接続を手動で定義する代わりに、一連のキュー・マネージャーをクラスターにグループ化することができます。 こうすると、キュー・マネージャーのホストするキューは、宛先ごとに明示的なチャネル定義、リモート・キュー定義、または伝送キューを用意しなくても、クラスター内の他のキュー・マネージャーで使用できるようになります。 クラスター内のすべてのキュー・マネージャーは単一の伝送キューを備えており、その伝送キューによってクラスター内の別のキュー・マネージャーへメッセージが伝送されます。 キュー・マネージャーごとに、1 つのクラスター受信側チャネルと 1 つのクラスター送信側チャネルのみ定義する必要があります。 追加のチャネルはクラスターによって自動的に管理されます。

IBM MQ クライアントは、他のキュー・マネージャーに接続できるのと同様に、クラスターの一部であるキュー・マネージャーに接続できます。 手動で構成した分散キューイングと同様に、任意のキュー・マネージャーのキューにメッセージを書き込むには、MQPUT 呼び出しを使用します。 ローカル・キューからメッセージを取り出すには、MQGET 呼び出しを使用します。

クラスターをサポートするプラットフォーム上にあるキュー・マネージャーは、クラスター構成にしなくても構いません。 クラスターを使用せずに分散キューイングを手動で構成することも、クラスターを使用しながら分散キューイングの構成を行うこともできます。

クラスターを使用する利点

クラスター化には、次の 2 つの主な利点があります。
  • クラスターにより、 IBM MQ ネットワークの管理が単純化されます。通常、このネットワークでは、チャネル、送信キュー、およびリモート・キューを構成するために多数のオブジェクト定義が必要になります。 これは、多数のキュー・マネージャーを相互接続する必要があり、変更される可能性のある大規模ネットワークに特に当てはまります。 そのようなアーキテクチャーでは、構成や頻繁な保守が特に困難です。
  • また、クラスターを使用すると、クラスター内のキューおよびキュー・マネージャーの間でメッセージ・トラフィックのワークロードを分散させることができます。 このような分散により、1 つのキューのメッセージ・ワークロードを、複数のキュー・マネージャー上にあるそのキューの複数の同等インスタンスに分散させることができます。 ワークロードの分散は、システム障害に対する回復力、およびシステム内で特にアクティブなメッセージ・フローのスケーリング・パフォーマンスを向上させる上で役立ちます。 そのような環境では、分散キューの各インスタンスに、メッセージを処理するコンシューム側アプリケーションが存在します。 詳しくは、 ワークロード管理のためのクラスターの使用を参照してください。

クラスター内でメッセージが経路指定される方法

クラスターは、信頼できるシステム管理者によって管理されているキュー・マネージャーのネットワークと見なすことができます。 クラスター・キューを定義すると、システム管理者は対応するリモート・キューの定義を必要に応じて他のキュー・マネージャーに対して自動的に作成します。

IBM MQ はクラスター内の各キュー・マネージャーに伝送キューを提供するため、伝送キューを定義する必要はありません。 この単一の伝送キューにより、クラスター内のその他のキュー・マネージャーにメッセージを送信することができます。 伝送キューを 1 つしか使用できないという制限はありません。 キュー・マネージャーは複数のクラスターを使用して、クラスター内の各キュー・マネージャーにメッセージを別々に送信できます。 通常、1 つのキュー・マネージャーは 1 つのクラスター伝送キューを使用します。 キュー・マネージャー属性 DEFCLXQ を変更して、キュー・マネージャーがクラスター内のキュー・マネージャーごとに異なるクラスター伝送キューを使用するように設定することもできます。 クラスター伝送キューを手動で定義することもできます。

クラスターを構成するキュー・マネージャーはすべて、上述のような方法で処理を実行します。 各キュー・マネージャーは、各キュー・マネージャー自体に関する情報とホストしているキューに関する情報を送信し、同じクラスター内にあるその他のキュー・マネージャーに関する情報を受信します。

キュー・マネージャーが使用できなくなった場合に情報の損失を防ぐには、クラスター内の 2 つのキュー・マネージャーをフル・リポジトリー として動作するように指定します。 これらのキュー・マネージャーは、クラスター内のすべてのキュー・マネージャーとキューに関するすべての情報を保管します。 クラスター内の他のすべてのキュー・マネージャーは、これらのキュー・マネージャーに関する情報と、メッセージの交換に使用するキューに関する情報のみを保管します。 このようなキュー・マネージャーは、部分リポジトリー として知られています。 詳しくは、 クラスター・リポジトリーを参照してください。

クラスターの一部になるために、キュー・マネージャーには、クラスター送信側チャネルおよびクラスター受信側チャネルの 2 つのチャネルが必要です。
  • クラスター送信側チャネルとは、送信側チャネルに似た通信チャネルです。 キュー・マネージャーに手動で 1 つのクラスター送信側チャネルを作成し、既にクラスターのメンバーである完全リポジトリーに接続する必要があります。
  • クラスター受信側チャネルとは、受信側チャネルに似た通信チャネルです。 クラスター受信側チャネルを 1 つ手動で作成する必要があります。 このチャネルはキュー・マネージャーの仕組みとして機能し、クラスター通信を受信します。
このキュー・マネージャーとクラスターの他のメンバーとの通信に必要となる他のすべてのチャネルは自動的に作成されます。
以下の図は、CLUSTER というクラスターのコンポーネントを示しています。
図4: 複数のキュー・マネージャーで構成されるクラスター
この図は、3 つのキュー・マネージャーで構成される IBM MQ クラスターを示しています。そのうちの 2 つはフル・リポジトリーをホストしています。
  • CLUSTER には、QM1、QM2、および QM3 という 3 つのキュー・マネージャーが備えられています。
  • QM1 と QM2 は、クラスター内にあるキュー・マネージャーとキューに関する情報の全リポジトリーのホストです。
  • QM2 と QM3 は、いくつかのクラスター・キュー (つまり、このクラスター内にある別のキュー・マネージャーからアクセス可能なキュー) のホストです。
  • それぞれのキュー・マネージャーは、メッセージを受信する TO.qmgr というクラスター受信側チャネルを 1 つずつ備えています。
  • また、それぞれのキュー・マネージャーは、リポジトリー・キュー・マネージャーの 1 つに情報を送信するクラスター送信側チャネルも 1 つずつ備えています。
  • QM1 と QM3 は、QM2 のリポジトリーへ送信し、QM2 は QM1 のリポジトリーへ送信します。