クラスター化された MQ に接続するクラスター化された Websphere アプリケーション サーバーを構成しようとしています。
ただし、私が持っている情報は、ホスト名が異なる MQ の 2 つのインスタンス、サーバー チャネル、および同じ MQ クラスター名に属するキュー マネージャーの詳細です。
Websphere コンソールで、ホスト名、キュー マネージャー、およびサーバー チャネルの入力フィールドを確認できますが、複数の MQ 詳細を指定できるものは見つかりません。
MQ の詳細の 1 つを選択した場合、MQ クラスタリングは機能しますか? そうでない場合、詳細を考慮して MQ クラスタリングを有効にするにはどうすればよいですか?
WebSphere MQ クラスタリングは、キュー マネージャーが相互に対話する方法の動作に影響を与えます。アプリケーションがキュー マネージャーに接続または対話する方法は変更されないため、尋ねられた質問は、WMQ には存在しないある種のクラスタリング動作を想定しているようです。
アプリケーション・サーバーを 2 つのアドレスでセットアップするには、複数インスタンス値を使用して接続ファクトリーを構成する方法について、WAS v7 ナレッジ・センターのWebSphere MQ メッセージング・プロバイダーのカスタム・プロパティーを使用した複数インスタンス・キュー・マネージャー接続の構成を参照してください。CONNAME
Connection Factory で有効な QMgr 名を指定し、アプリが接続する QMgr にその特定の名前がない場合、接続は拒否されます。通常、マルチインスタンスCONNAMEは、マルチインスタンス QMgr に接続するために使用されます。これは、2 つの異なる IP アドレスのいずれかに配置できる単一の高可用性キュー マネージャーであるため、その場合は実際の QMgr 名を使用できます。ただし、アプリが接続している QMgr が 2 つの別個の異なる名前のキュー マネージャーである場合は、ここで*説明されているように、接続ファクトリでキュー マネージャー名としてアスタリスク (文字) を指定する必要があります。このようにして、アプリは接続を取得したときに QMgr の名前をチェックしません。
MQ の詳細の 1 つを選択した場合、MQ クラスタリングは機能しますか? そうでない場合、詳細を考慮して MQ クラスタリングを有効にするにはどうすればよいですか?
「クラスタリング」の意味によって異なります。2 つのキュー マネージャーによってホストされている 1 つの論理キューがアプリに表示されると思われる場合は、いいえ。それは WMQ クラスタリングの仕組みではありません。クラスター化されたキューをホストする各キュー マネージャーは、そのキューに送信されたメッセージのサブセットを取得します。したがって、そのキューから取得するすべてのアプリは、ローカル サブセットのみを認識します。
しかし、「クラスタリング」によって、2 つのキュー マネージャーのいずれかに交互に接続し、同じクラスター内にあるが、接続先の 2 つの QMgr のいずれにもホストされていないキューにメッセージを送信する場合は、そうです。うまくいきます。接続ファクトリーが 2 つの QMgr のうちの 1 つしか認識していない場合、その QMgr にのみ接続し、クラスターへのメッセージの送信は引き続き機能します。しかし、私が提供したリンクで説明されているように設定すると、アプリは 2 つの QMgr のいずれかに接続できるようになり、接続先のチャネルを停止し、もう一方のチャネルに接続することを確認することで、簡単にテストできます。 1。
幸運を！
アップデート：
明確にするために、提供される詳細は、hostname01、qmgr01、queueA、serverchannel01 に似ています。もう 1 つは、hostname02、qmgr02、queueA、serverchannel02 です。
WMQ クライアントは、次の場合CONNAMEにのみ、マルチインスタンスを使用して 2 つの異なる QMgr に接続します...
*文字) またはスペースを使用します。クライアント接続定義テーブル (CCDT とも呼ばれます) を使用して、チャネル名がそれぞれ異なる複数の異なるキュー マネージャーの 1 つに WMQ を接続させることができます。CCDT は、チャネルMQSCを定義するコマンドを使用して作成するコンパイル済みアーティファクトです。CLNTCONNクライアントが接続できる各 QMgr のエントリが含まれています。それぞれが異なる QMgr 名、ホスト、ポート、およびチャネルを持つことができます。ただし、CCDT管理者を定義するときに、QMgr 名がアプリケーションの高レベル修飾子に置き換えられるように、すべてのエントリを定義します。たとえば、Payroll アプリは 3 つの異なる QMgr のいずれかに接続する必要があります。WMQ 管理者は、3 つのエントリを持つ CCDT を定義しますがPAY01、、、PAY02およびPAY03QMgr 名の場合。これは実際の QMgr 名と一致する必要はないことに注意してください。次に、アプリケーションはPAY*、CCDT で 3 つすべての QMgr を選択する QMgr 名を指定します。
CCDT について詳しくは、WebSphere MQ classes for JMS でのクライアント・チャネル定義テーブルの使用を参照してください。
MQ クラスターはアプリケーション サーバー クラスターと似ていませんか?
いいえ、まったくありません。
2 つの子ノードがクラスターに接続されています。また、F5 URL は、各ノードに負荷を分散するために使用されます。WMQ には、メッセージを送信するだけのクラスター URL / f5 が付属しており、メッセージのパーティショニングは透過的ではありませんか?
いいえ。WMQ クラスターは、アプリケーションと QMgr がキューやトピックなどの非ローカル オブジェクトを解決できる名前空間を提供します。WebSphere MQ クラスターに接続する唯一のものは、キュー マネージャーです。アプリケーションと人間のユーザーは、常に特定のキュー マネージャーに接続します。CCDT などと交換可能な一連のキュー マネージャーが存在する場合がありますが、それぞれは独立しています。
WAS を使用すると、メッセージング エンジンは複数のノードで実行できますが、アプリケーションがメッセージを取得できる単一の論理キューを提供します。WMQ を使用すると、そのキューをホストする各ノードがメッセージのサブセットを取得し、それらのメッセージを消費するアプリケーションはそのサブセットのみを認識します。
HTTP はステートレスであるため、F5 URL はうまく機能します。セッションを維持する場合、そのセッションは主に接続オーバーヘッドを最適化するために存在し、短命になる傾向があります。WMQ クライアント チャネルはステートフルで、1 フェーズと 2 フェーズの両方の作業単位を調整します。UOW 中にアプリケーションが別の QMgr にフェイルオーバーした場合、その UOW を調整する方法はありません。
WMQ 接続の性質上、QMgr 間で F5 が使用されることはありません。これはクライアントと QMgr の間でのみ接続のバランシングに使用され、メッセージ トラフィックのバランシングには使用されません。さらに、MQ クラスターの有無は、アプリケーションに対して完全に透過的であり、いずれの場合も、QMgr に接続してメッセージを取得および/または送信するだけです。マルチインスタンスCONNAMEまたは CCDT ファイルを使用すると、クライアントが接続できる複数の同等の QMgr を提供することで、その接続がより堅牢になりますが、WMQ クラスタリングとは何の関係もありません。
それは役に立ちますか？
参照してください：