サンプル・クラスター
最初に規模がもっとも小さい事例として、2 つのキュー・マネージャーから成るクラスターを示します。 2 番目と 3 番目の例では、3 つのキュー・マネージャーから成るクラスターの 2 つのバージョンを示します。
最小規模のクラスターでは、それに含まれるキュー・マネージャーは 2 つだけです。 この場合は、両方のキュー・マネージャーが完全リポジトリーを保有します。 クラスターのセットアップに必要な定義がごくわずかで済むにもかかわらず、各キュー・マネージャーに高度の自律性があります。
- キュー・マネージャーには、
LONDONやNEWYORKなどのロング・ネームを付けることができます。![[z/OS]](ngzos.gif)
IBM® MQ for z/OS® では、キュー・マネージャー名は4文字までに制限されている。 - 各キュー・マネージャーは、通常別個のマシンで構成します。 ただし、同じマシンに複数のキュー・マネージャーを配置することもできます。
同様のクラスター例のセットアップ手順については、 新規クラスターのセットアップを参照してください。
CLSTR1というクラスターのコンポーネントを示しています。- このクラスターには、
QM1、QM2、QM3という 3 つのキュー・マネージャーがあります。 QM1およびQM2では、クラスター内のすべてのキュー・マネージャーとクラスター関連オブジェクトに関する情報のリポジトリーをホストしています。 このようなキュー・マネージャーを完全リポジトリー・キュー・マネージャー といいます。 リポジトリーは、図の中で陰影の付いた円柱で示されています。QM2およびQM3では、このクラスター内にあるその他のキュー・マネージャーからアクセスできるいくつかのキューをホストしています。 このクラスター内にあるその他のキュー・マネージャーからアクセスできるキューをクラスター・キュー といいます。 図の中で陰影の付いたキューの部分がクラスター・キューを表します。 クラスター・キューへはクラスター内のどこからでもアクセスできます。 IBM MQ クラスタリング・コードにより、クラスター・キューのリモート・キュー定義が、それらを参照するすべてのキュー・マネージャー上に作成されます。分散キューイングの場合と同様に、アプリケーションは MQPUT 呼び出しを使用してクラスター内の任意のキュー・マネージャーにあるクラスター・キューにメッセージを書き込みます。 アプリケーションは MQGET 呼び出しを使用して、キューが存在するキュー・マネージャーのみにあるクラスター・キューからメッセージを取り出します。
- 各キュー・マネージャーには、メッセージを受信できる cluster_name. queue_manager_name と呼ばれるチャネルの受信側に対して、手動で作成された定義があります。 受信側のキュー・マネージャーでは、cluster_name. queue_manager_name はクラスター受信側チャネルです。 クラスター受信側チャネルは分散キューイングで使用されている受信側チャネルに似ており、キュー・マネージャーのメッセージを受信します。 さらに、クラスターについての情報も受け取ります。
図2： 複数のキュー・マネージャーで構成されるクラスター 
- 図 3 では、各キュー・マネージャーには、チャネルの送信側の定義もあります。 送信側のチャネルは、いずれかの完全リポジトリー・キュー・マネージャーのクラスター受信側チャネルに接続しています。 送信側キュー・マネージャーでは、
cluster_name. queue_manager_nameはクラスター送信側チャネルです。QM1およびQM3のクラスター送信側チャネルはCLSTR1.QM2に接続されています。点線「2
」を参照してください。QM2のクラスター送信側チャネルはCLSTR1.QM1に接続されています。点線「3
」を参照してください。 クラスター送信側チャネルは、分散キューイングで使用されている送信側チャネルに似ており、受信側キュー・マネージャーにメッセージを送信します。 さらに、クラスターについての情報も送信します。クラスター受信側チャネルとクラスター送信側チャネルの両方の定義が終わると、自動的にチャネルが始動します。
ローカル・キュー・マネージャーにクラスター送信側チャネルを定義すると、キュー・マネージャーがいずれかの完全リポジトリー・キュー・マネージャーで認識されます。 これにより、その完全リポジトリー・キュー・マネージャーは完全リポジトリーの情報を更新します。 そして、元のキュー・マネージャー宛てのクラスター送信側チャネルを自動的に作成して、そのキュー・マネージャーにクラスターの情報を送信します。 このように、キュー・マネージャーとクラスターは相互に認識できます。
図 2をもう一度見てください。 例えば、キュー・マネージャー QM3 に接続されているアプリケーションから QM2 のキューにメッセージを送信するとします。 QM3 が初めてそれらのキューにアクセスする際には、完全リポジトリーを参照して、キューを見つけることができます。 この場合の完全リポジトリーは QM2 で、このリポジトリーへは送信側チャネル CLSTR1.QM2 を使用してアクセスします。 リポジトリーからの情報を使用して、それらのキュー用にリモート定義を自動的に作成することができます。 キューが QM1 にある場合でも、QM2 が完全リポジトリーであるため、このメカニズムは引き続き機能します。 完全リポジトリーは、クラスター内のすべてのオブジェクトの完全なレコードを保持しています。 後者の事例では、QM3 は自動的に QM1 のクラスター受信側チャネルに対応するクラスター送信側チャネルを作成することもでき、これら 2 つの間で直接通信が可能になります。
CLSTR1.QM3 につながっている 2 本の破線で示されています。 また、この図に示されているクラスター伝送キュー SYSTEM.CLUSTER.TRANSMIT.QUEUE は、QM1 がメッセージを送信するときに使用するキューです。 クラスター伝送キューは、クラスター内のどのキュー・マネージャーにもあります。このキューにより、各キュー・マネージャーは同じクラスター内のその他のキュー・マネージャーにメッセージを送信することができます。