2.8.1　クラスタの概要

(1)　分散キューイングの概念

クラスタを使用しない場合，キューマネジャは相互に独立し，分散キューイングを使用して通信します。あるキューマネジャがほかのキューマネジャにメッセージを送信する場合，送信側キューマネジャには，次に示す定義が必要です。

• 転送キュー

• リモートキューマネジャへのチャネル

• メッセージを送信したい各キューのリモートキューのローカル定義

分散キューイングのシステム構成について，次の図に示します。

図2‒38　分散キューイングのシステム構成

ページの先頭へ

(2)　クラスタの概念

キューマネジャをクラスタにまとめた場合，キューマネジャは，自分が保持しているキューを，クラスタ内のすべての他キューマネジャに利用させることができます。すべてのキューマネジャは，明示的なチャネル定義，リモートキューのローカル定義，および各あて先の転送キューがなくても，同じクラスタのほかのキューマネジャにメッセージを送信できます。クラスタ内のすべてのキューマネジャは，クラスタのほかのキューマネジャにメッセージを転送できる一つのクラスタ転送キューを持っています。クラスタの各キューマネジャは，次について定義します。

• メッセージを受信するための一つのクラスタレシーバチャネル

• 自分をクラスタに紹介し，情報を取得するための一つのクラスタセンダチャネル

• クラスタ環境のシステムキュー

CLUSTERというクラスタのシステム構成について，次の図に示します。

図2‒39　クラスタのシステム構成

• このクラスタにはQM1，QM2，およびQM3という三つのキューマネジャがあります。

• QM1とQM2は，クラスタ内のキューマネジャ情報のリポジトリを保持し，管理しています。これらは，フルリポジトリキューマネジャといいます（TP1/Message Queueはフルリポジトリキューマネジャとしての動作をサポートしていません）。

  QM3は自キューマネジャ情報のほかにQM1とQM2から得た，他キューマネジャ情報を保持しています。QM3をパーシャルリポジトリキューマネジャといいます。

• QM2とQM3は，クラスタに参加しているほかのキューマネジャがアクセスできる幾つかのキューを保持しています。これらをクラスタキューといいます。

分散キューイングの場合と同様に，アプリケーションはMQPUT命令を使用して，メッセージを任意のキューマネジャのクラスタキューに登録します。アプリケーションは，MQGET命令を使用して，ローカルキューマネジャのクラスタキューからメッセージを取り出します。

• 各キューマネジャには，メッセージを受信するためのTO.QMx（x：1〜3）というチャネルの受信端の定義があります。これは，クラスタレシーバチャネルです。クラスタレシーバチャネルは，分散キューイングで使用されるレシーバチャネルのようなものですが，メッセージを転送する以外に，クラスタについての情報を通信することもできます。

• また，各キューマネジャには，一つのフルリポジトリキューマネジャのクラスタレシーバチャネルに接続する，チャネルの送信端の定義もあります。これは，クラスタセンダチャネルです。QM1とQM3は，TO.QM2に接続しているクラスタセンダチャネルを持っています。QM2は，TO.QM1に接続しているクラスタセンダチャネルを持っています。クラスタセンダチャネルとは，分散キューイングで使用されるセンダチャネルのようなものですが，このチャネルは，メッセージを転送するほかに，クラスタについての情報を通信することもできます。

  チャネルのクラスタレシーバ端とクラスタセンダ端の両方が定義されれば，チャネルは自動的に開始されます。

ページの先頭へ

(3)　クラスタの長所

クラスタを使用すると，次に示す利点が得られます。

ページの先頭へ

(4)　クラスタの考慮事項

• クラスタを最大限に活用するためには，ネットワークのすべてのキューマネジャが，クラスタをサポートしているプラットフォーム上にある必要があります。すべてのシステムが，クラスタをサポートしているプラットフォームに移植されるまで，クラスタの外のキューマネジャは，手作業で追加を定義してクラスタキューにアクセスすることがあります。

• 同じ名前の二つのクラスタがマージされた場合，それらを再度二つに分けることはできません。したがって，すべてのクラスタをユニークな名前にすることをお勧めします。

• クラスタに参加するキューマネジャ名は，参加する各クラスタ内でユニークな名前にする必要があります。

• キューマネジャにメッセージが到着したときに，そのキューマネジャにメッセージを受信するキューがない場合，分散キューイングと同様に，デッドレターキューに登録されます。デッドレターキューがない場合，送信処理は失敗し，mqtalccha定義コマンドの-b bretrymcpオペランドがyesのときチャネル確立再試行が発生します。

• 永続的メッセージの一貫性は保持されます。クラスタを使用した結果，メッセージが重複したり，喪失したりすることはありません。

• クラスタを使用すれば，システム管理が軽減されます。クラスタは，分散キューイングを使用するよりも，多くのキューマネジャと大きなネットワークの接続を容易にします。しかし，分散キューイングの場合と同様に，クラスタのすべてのキューマネジャ間での通信を有効にしようとした場合，ネットワークリソースが過度に消費されることがあります。

• 配布リストは，一回のMQPUT命令で同じメッセージを複数のあて先に送信することを目的とします。配布リストはクラスタ環境でも使用できます。システム管理者にとっては，配布リストを使用する場合，複数のチャネルや転送キューを手作業で定義する必要がないという利点があります。しかし，リモートのクラスタキューへメッセージを登録する目的で配布リストを使用する場合は，あて先ごとにメッセージが処理されます。ネットワークトラフィックの観点では，分散キューイング環境と比べて，利点があまりありません。

• 負荷分散のためにクラスタを使用する場合，自分のアプリケーションを調査して，メッセージが特定のキューマネジャまたは特定のシーケンスで処理されることがアプリケーションで必要でないか調べる必要があります。そのようなアプリケーションは，メッセージ類似性を持つといいます。複雑なクラスタで使用する前に，アプリケーションの修正が必要になることもあります。

• メッセージが特定のあて先に送信されるようにMQOPEN命令でMQOO_BIND_ON_OPENオプションを使用した場合，あて先のキューマネジャが利用できないとき，そのメッセージは転送されません。複製の危険があるので，ほかのキューマネジャに向けてメッセージの送信経路が設定されることはありません。

• クラスタに参加するキューマネジャのクラスタセンダチャネルではmqtalccha定義コマンドの-oオプションに，フルリポジトリキューマネジャのホスト名またはIPアドレスを指定します。しかし，DHCPを使用する場合は，IPアドレスが変更される可能性があります。システムの再開始時にDHCPが新しいIPアドレスを割り当てることがあるからです。そのため，この場合はクラスタセンダチャネルのmqtalccha定義コマンドの-oオプションにIPアドレスを指定しないでください。すべてのクラスタセンダチャネルでIPアドレスではなくホスト名を指定しても十分な信頼性はありません。DHCPはホストのDNSディレクトリエントリを新しいアドレスで更新するとは限らないからです。

  注

  DNSディレクトリが最新状態に更新されるよう保証するソフトウェアをインストールしていない場合は，DHCPを使用するシステム上のキューマネジャをフルリポジトリに割り当てないでください。

• メッセージの取り出しはローカルのクラスタキューだけから可能ですが，メッセージの登録はクラスタ内のすべてのキューへ可能です。MQGET命令を使用するためにキューをオープンする場合は，キューマネジャはローカルキューだけを使用します。

• クラスタに新規に参加する場合，または再参加する場合，アプリケーションで使用するクラスタキューの情報がないことがあります。この状態で，クラスタキューへアクセスするアプリケーションを開始すると，MQOPEN命令でエラーが発生することがあります。そのため，自システムで使用するクラスタキューに対してMQOPEN命令を発行するだけのアプリケーションを作成し，事前にクラスタキューの情報を収集することをお勧めします。

ページの先頭へ

(5)　まとめ

TP1/Message QueueはIBM MQのクラスタにパーシャルリポジトリとして参加できます。クラスタに参加する場合，システム管理者は，対応する送信チャネルとキューマネジャ上のリモートキューのローカル定義を作成する必要がなくなります。これらはキューマネジャによって自動的に作成されます。

クラスタに参加するすべてのキューマネジャは，自身および保持するキューについての情報をフルリポジトリキューマネジャに送信し，クラスタ内のほかのキューマネジャについての情報を受信します。

各キューマネジャにあるクラスタ転送キューは，情報をシステムメッセージとして送受信するときに使用されます。また，ユーザメッセージを送受信するときにも使用されます。

情報は，各キューマネジャのリポジトリに格納されます。また，クラスタ内のフルリポジトリキューマネジャでは，すべてのキューマネジャとキューについての情報をフルリポジトリとして管理します。

クラスタレシーバチャネルは，レシーバチャネルに似ています。クラスタレシーバチャネルの定義の実行時には，キューマネジャ上にオブジェクトが作成されるだけではなく，保持するチャネルとキューマネジャについての情報もリポジトリに格納されます。クラスタレシーバチャネルの定義は，クラスタに対するキューマネジャの初期通知動作です。いったん定義すると，ほかのキューマネジャは対応するクラスタセンダ端の定義を自動的に作成できます。

クラスタセンダチャネルはセンダチャネルに似ています。クラスタセンダチャネルはほかのクラスタキューマネジャと通信するときに，対応するクラスタレシーバチャネルの定義を参照して，自動的に作成されます。しかし，各キューマネジャには最初にクラスタに接続するための事前定義クラスタセンダチャネルが一つ必要です。

クラスタをサポートするキューマネジャが，クラスタの一部になる必要はありません。クラスタを使用する代わりに，分散キューイングの手法を使い続けることができます。

ページの先頭へ