IBM MQ サーバー接続および IBM MQ for z/OS 共有キューを使用した相互運用のネットワーク・トポロジー

これらの例は WebSphere® Application Server IBM MQ サーバー接続を使用して IBM MQ と相互運用できるようにする単純なトポロジーと複雑なトポロジー、および IBM MQ for z/OS 共有キューと IBM MQ サーバー接続を使用して可用性の高いメッセージング システムを作成するトポロジーを示しています。

完全を期すために、トピックで説明するトポロジーにはクラスター化されたトポロジーや可用性の高いトポロジーが含まれます。 クラスター化や高可用性に対応するには、製品の Network Deployment バージョンか z/OS バージョンを使用する必要があります。

IBM MQ サーバー接続を持つキュー型宛先

サービス統合バスに通常のキュー・タイプの宛先がある場合、キュー自体は WebSphere Application Server内のバス・メンバーにあります。 このバス・メンバーは、アプリケーション・サーバーとアプリケーション・サーバーのクラスターのいずれかにすることができます。 バス・メンバー内の 1 つ以上のメッセージング・エンジンがキューを管理します。 メッセージング・エンジンは、キューへのメッセージの投入や、キューからのメッセージの取得を行うことができます。また、必要であればメッセージのディスク・コピーを保持することもできます。 アプリケーションは、サービス統合バスに接続する際、キューが配置されていないメッセージング・エンジンに接続する場合があります。 その場合には、アプリケーションの接続先のメッセージング・エンジンがキューの配置場所であるメッセージング・エンジンと通信を行い、そのメッセージング・エンジンを使用します。

IBM MQ サーバー接続では、サービス統合バスキュータイプの宛先を設定できます。これにより、キュー自体が IBM MQ キューマネージャまたはキュー共有グループ内に配置されます。 この場合、キュー・マネージャーまたはキュー共有グループはバス・メンバーとしてサービス統合バスに組み込まれます。 サービス統合メッセージングエンジンは、バス内で IBM MQ キューマネージャと通信し、これを使用してキューにアクセスする。

IBM MQ サーバー接続では、アプリケーションが取得操作と書き込み操作の両方を実行できます。これに対し、 IBM MQ リンク接続では、アプリケーションは書き込み操作のみを実行できます。

IBM MQ サーバー接続は、バインディング接続(アタッチと呼ばれる)またはクライアント接続( TCP/IP 接続)のいずれかを使用できます。 バインディング接続を使用できるのは、アプリケーション・サーバーとキュー・マネージャー (またはキュー共有グループ) が、同じホストまたは同じ論理区画 (LPAR) で稼働している場合のみです。 アプリケーション・サーバーとキュー・マネージャー (またはキュー共有グループ) が異なるホストで稼働している場合は、クライアント接続を使用する必要があります。

単一の WebSphere Application Server アプリケーションサーバーが、単一の IBM MQ キューマネージャまたはキュー共有グループに接続されている

この基本的なシナリオでは、サービス統合バスを単一のメッセージング・エンジンと共に使用します。 このバスには、 IBM MQ の共有キューを使用するように設定されたキュー型の宛先が含まれています。 単一のアプリケーションは、サービス統合バスに接続し、キュー・タイプ宛先にアクセスします。

アプリケーションが宛先にメッセージを送信すると、メッセージングエンジンは IBM MQ キューマネージャと連携し、これを使用してメッセージを共有キューに追加します。 アプリケーションが宛先からメッセージを受信すると、メッセージングエンジンは IBM MQ キューマネージャと連携し、共有キューからメッセージを取得するためにこれを利用する。

アプリケーションが IBM MQ サーバー接続を介して IBM MQ と通信する場合、ローカルサービス統合メッセージングエンジンと通信していることのみを認識します。 メッセージングエンジンは、アプリケーションに代わって IBM MQ と通信します。 IBM MQ キューマネージャは、サービス統合メッセージングエンジンを IBM MQ クライアントとして扱います。

以下の図で、A とラベル付けされている接続線は、サービス統合メッセージング・エンジンにローカル・バスのメンバーとして認識される、キュー・マネージャーを示します。 B とラベル付けされている接続線は、キュー・マネージャーに別のキュー・マネージャーとして認識される、サービス統合メッセージング・エンジンを示します。

図1: WebSphere Application Server 内で稼働し、WebSphere MQ サーバー接続を使用して WebSphere MQ に接続する単一のアプリケーション。
この図は、 WebSphere Application Server 内で実行され、 WebSphere MQ サーバー接続を使用して WebSphere MQ に接続する単一のアプリケーションを示しています。

IBM MQ キューマネージャに接続された別々のアプリケーションサーバー上で実行される複数のアプリケーション

IBM MQ サーバー接続では、サービス統合メッセージングエンジンは、必要に応じて動的に IBM MQ キューマネージャへの個別の接続を確立します。 IBM MQ リンクを使用する場合のように、ゲートウェイメッセージングエンジンやゲートウェイキューマネージャーは存在しません。

以下の図は、WebSphere MQ サーバー接続を介して WebSphere MQ キュー・マネージャーに接続する、個々のアプリケーション・サーバー内で稼働する 2 つのアプリケーションを示したものです。 サービス統合バスには、2 つのメッセージング・エンジンと 1 つのキュー・マネージャーが組み込まれています。

図2: WebSphere MQ サーバー接続を介して WebSphere MQ キュー・マネージャーに接続する、個々のアプリケーション・サーバー内で稼働する 2 つのアプリケーション
この図は、 WebSphere MQ サーバー接続を介して WebSphere MQ キュー・マネージャーに接続する別個のアプリケーション・サーバー内で実行される 2 つのアプリケーションを示しています。

IBM の使用 MQ for z/OSIBM MQ サーバー接続を使用した共有キュー

IBM MQ サーバー接続により、 WebSphere Application Server アプリケーションは取得操作( IBM MQ キューからのメッセージ受信)を実行できます。 したがって、 IBM MQ サーバーを使用して IBM の MQ for z/OS® キュー共有グループに接続することで、メリットを得ることができます。 IBM MQ リンクは WebSphere Application Server アプリケーションをキュー共有グループに接続できますが、 IBM MQ リンクはアプリケーションがメッセージを送信する操作のみを可能とするため、アプリケーションは共有キューからメッセージを消費できず、共有キューの利点を十分に活用できません。

IBM MQ for z/OS キュー共有グループは、共有キューを使用することで大きな利点をもたらします。 複数のアプリケーションが、同じキュー共有グループ内の異なるキュー・マネージャーを使用することで、同じ共有キューとメッセージの送受信ができます。 これには、以下の利点があります。
  • 異なるアプリケーション (または同じアプリケーションの異なるインスタンス) が、同じキュー上のメッセージを処理しようと競合します。 メッセージをより短時間で処理できるインスタンス (インスタンスがより高性能なプロセッサーで実行される、または負荷が少ないプロセッサーで実行されるため) が、キュー上にあるメッセージを自動的に処理する割合が高いため、使用可能なリソースの使用効率が向上するほか、全体の応答時間も向上します。 これは、プル・ワークロード・バランシング と呼ばれます。
  • キュー共有グループの 1 つのキュー・マネージャーに障害が発生した場合、アプリケーションは別のキュー・マネージャーに接続して、同じ共有キューを引き続き使用することができます。 これによって、アプリケーションの可用性が向上します。 ピア・レベル・リカバリー と呼ばれる、キュー共有グループの特殊な機能が、アプリケーションが共有キューからメッセージを受信するものの、メッセージの処理が完了する前にキュー・マネージャーに障害が発生する状況に対応します。 アプリケーションがトランザクション・タイプである場合、同じキュー共有グループの別のキュー・マネージャーがメッセージをその共有キューに戻し、障害が発生したキュー・マネージャーがリカバリーするのを待たずに処理できるようにします。 ピア・レベル・リカバリーは、アプリケーションの可用性をさらに高めます。
  • キュー共有グループでは、サービス統合は、キュー共有グループ内のキュー・マネージャーのコレクションに対して単一のネットワーク・アドレスを使用することでキュー共有グループに接続することもできます。 この接続は、キュー共有グループ内の適切なキュー・マネージャーに自動的にリダイレクトされます。適切なキュー・マネージャーは、使用可能であるかどうか、および最短の応答時間を実現できるかが基準になります。 この機能により、アプリケーションの可用性およびパフォーマンスの両方を改善できます。

これらの利点をサービス統合アプリケーションに提供するには、キュー共有グループに属する IBM MQ サーバーが所有する共有キュー上にサービス統合宛先を定義します。 以下の図は、キュー共有グループ内の 1 つのキュー・マネージャー (QM1) に接続するサービス統合メッセージング・エンジンを示しています。 この接続により、サービス統合アプリケーションは共有キューからのメッセージをコンシュームできます。 同じアプリケーション・サーバーまたは異なるアプリケーション・サーバー上の他のサービス統合アプリケーションでは、異なる接続 (同じキュー共有グループ内の、QM2 や QM3 などの同じまたは異なるキュー・マネージャーへの接続) を使用して、同じ共有キューからのメッセージをコンシュームできます。

図3: キュー・マネージャーに接続してキュー共有グループにアクセスするメッセージング・エンジン (WebSphere MQ サーバー接続を使用)
この図は、キュー共有グループ内の 1 つのキュー・マネージャーに接続するサービス統合メッセージング・エンジンを示しています。

以下の図は、キュー共有グループ内のキュー・マネージャー (QM1) が一時的に使用不可である場合に、サービス統合が別のキュー・マネージャー (QM2) に接続してアプリケーションがキューからのメッセージの処理を続行できるようにすることを示しています。

図4: 使用していた元のキュー・マネージャーが失敗した後で 2 番目のキュー・マネージャーに接続してキュー共有グループにアクセスするメッセージング・エンジン
この図は、キュー共有グループ内の 1 つのキュー・マネージャーに接続しているサービス統合メッセージング・エンジンが一時的に使用不可になり、別のキュー・マネージャーに接続してアプリケーションが処理を続行できるようにする方法を示しています。