OpenTP1 メッセージキューイング機能 TP1/Message Queue 使用の手引
クラスタについての詳細とその機能について説明します。内容は次に示すとおりです。
クラスタの構成要素がどのように連携して機能を果たすのか,クラスタの構成要素と機能について説明します。
クラスタの構成要素について,次の図に示します。
図2-44 クラスタの構成要素
すべてのクラスタには最低一つのフルリポジトリキューマネジャがあります。フルリポジトリキューマネジャはクラスタ内のキューマネジャ,キュー,およびチャネルについての全情報(フルリポジトリ)を保持しています。また,クラスタ内のほかのキューマネジャから情報更新の要求があった場合も,その要求はフルリポジトリキューマネジャが保持します。
フルリポジトリキューマネジャ以外のキューマネジャ(パーシャルリポジトリキューマネジャ)はそれぞれの部分情報(パーシャルリポジトリ)を保持します。パーシャルリポジトリにはキューおよび通信する必要のあるキューマネジャの部分集合についての情報があります。キューマネジャは別のキューまたはキューマネジャにアクセスする必要が発生すると,フルリポジトリキューマネジャに問い合わせてパーシャルリポジトリを構築し,それ以降そのキューまたはキューマネジャについて新しい情報を通知するよう要求します。
各キューマネジャはSYSTEM.CLUSTER.REPOSITORY.QUEUEというキューにあるメッセージにリポジトリ情報を格納します。キューマネジャはSYSTEM.CLUSTER.COMMAND.QUEUEというキューにあるメッセージでリポジトリ情報を交換します。
クラスタのメンバである各キューマネジャは,一つのフルリポジトリキューマネジャにあるクラスタレシーバチャネルに対応した,クラスタセンダチャネルを定義します。これで,キューマネジャは,クラスタ内のどのキューマネジャがフルリポジトリを保持するかを知ることになります。以降,キューマネジャは,どのリポジトリにでも情報を要求できます。キューマネジャが自分自身についての情報を送信する場合(例えば,新しいクラスタキューを作成した場合),この情報は事前定義クラスタセンダチャネルが接続するフルリポジトリキューマネジャのほかにもう一つのフルリポジトリキューマネジャがあれば,そこにも送信されます。
フルリポジトリキューマネジャが,リンクされているキューマネジャの一つから情報を受信すると,フルリポジトリは更新されます。新しい情報は,フルリポジトリキューマネジャがリポジトリを更新できない場合のリスクを減らすため,別のフルリポジトリキューマネジャにも送信されます。すべての情報が2回送信されます。情報の各項目には,複製を識別するためのシーケンス番号が付いています。同じシーケンス番号である場合,フルリポジトリキューマネジャは2回目に受信した情報を破棄します。同様に,二つのフルリポジトリキューマネジャがある場合にパーシャルリポジトリキューマネジャに同じ情報が通知されたとき,シーケンス番号が同じであればパーシャルリポジトリは情報を破棄します。このように,すべてのリポジトリはメッセージを交換することによって内容を整合させます。
クラスタキューを保持するキューマネジャは,自分のキューをクラスタに通知します。キューの作成時にmqamkqueコマンドの-cオプションに指定したクラスタに対しリポジトリ管理サーバの開始時に通知します。
キューがいったん通知されると,クラスタ内のどのキューマネジャもそのクラスタキューにメッセージを登録できます。メッセージをクラスタキューに登録するには,キューマネジャは該当するクラスタキューを保持するキューマネジャをフルリポジトリから見つける必要があります。それからメッセージに送信経路情報を付けて,クラスタ転送キューにそのメッセージを登録します。
各クラスタキューマネジャはSYSTEM.CLUSTER.TRANSMIT.QUEUEというクラスタ転送キューを持っています。
クラスタの一部であるキューマネジャは,クラスタ転送キュー上のメッセージを同一クラスタ内のどのキューマネジャにも送信できます。
キューマネジャは,クラスタの一部でない別のキューマネジャと通信することもできます。そのためにキューマネジャは,分散キューイング環境の場合と同様に,相手キューマネジャに対して転送キューとチャネルを定義する必要があります。
名称解決の間,クラスタ転送キューはデフォルトの転送キューに対して優先権を持ちます。クラスタの一部でないキューマネジャがリモートキューにメッセージを登録する場合,あて先キューマネジャに対応する転送キューがなければ,デフォルトアクションとしてデフォルトの転送キューが使用されます。クラスタの一部である送信側キューマネジャの場合,あて先キューマネジャと同名の転送キューがなければ,デフォルトアクションとしてSYSTEM.CLUSTER.TRANSMIT.QUEUEが使用されます(ただし,あて先キューがクラスタ内にない場合を除きます)。つまり,通常の名称解決では,キュー名がフルリポジトリを使って解決される場合にSYSTEM.CLUSTER.TRANSMIT.QUEUEが使用されます。
クラスタ内では,クラスタレシーバチャネル定義とクラスタセンダチャネル定義という特殊なチャネルを使用して,キューマネジャ間でメッセージの送受信が行われます。
クラスタレシーバチャネル定義では,自キューマネジャがメッセージを受信できるチャネルを定義します。クラスタへの参加によって定義情報がフルリポジトリキューマネジャに保持されます。保持される主な内容は,連絡属性が「あり」の属性です。詳細については,「3.3.2(3) チャネルデータ定義ブロック(dcmtcq_uoc_mqcd)」を参照してください。これによって,ほかのキューマネジャは対応するクラスタセンダチャネル定義をそのキューマネジャに対して自動定義できます。ただし,最初は各キューマネジャでフルリポジトリキューマネジャ向けの事前定義クラスタセンダチャネルを手作業で定義する必要があります。この定義によってキューマネジャは,参加するクラスタに自システムの情報を送信できます。
クラスタでは,同じクラスタ内のリモートキューに対応する,リモートキューのローカル定義が自動的にキューマネジャに作成されます。そのため,リモートキューのローカル定義を手作業で作成する必要はありません。クラスタキューマネジャはフルリポジトリキューマネジャからリモートキューの格納場所についての情報を取得します。格納場所が分かったら,送信経路情報をメッセージに追加して,クラスタ転送キューにメッセージを登録します。
分散キューイングを使用する場合,キューマネジャがリモートのあて先へメッセージを送信するときに,センダチャネルの定義が必要です。
しかし,キューマネジャがクラスタセンダチャネル定義とクラスタレシーバチャネル定義を作成してクラスタに参加することによって,クラスタ内のほかのキューマネジャに対応するチャネル定義を作成する必要がなくなります。
クラスタセンダチャネル定義は必要に応じて自動的に作成されます。自動定義されたクラスタセンダチャネルは,受信側キューマネジャの持つクラスタレシーバチャネル定義に指定された属性を引き継ぎます。手作業で定義されたクラスタセンダチャネル(事前定義クラスタセンダチャネル)の場合もクラスタレシーバチャネル定義に指定された属性を引き継ぎ,対応するクラスタレシーバチャネル定義との一致が保たれます。また,メッセージ編集出口UOCを使用すると,クラスタセンダチャネルまたはクラスタレシーバチャネルの属性を変更できます。
クラスタ転送キューにメッセージが登録され,そのメッセージを送信するクラスタセンダチャネルが存在しない場合は,クラスタセンダチャネルが自動定義され開始されます。自動定義されたチャネルは,設定された値の切断条件になるまで「チャネル動作中」状態が保持されます。
クラスタチャネルの状態はmqtlschaコマンドによって確認できます。
クラスタセンダチャネルの定義には,キューマネジャをフルリポジトリキューマネジャに紹介する効果があります。フルリポジトリキューマネジャはそれによってフルリポジトリ内の情報を更新します。フルリポジトリキューマネジャはそのキューマネジャに対してクラスタセンダチャネルを作成し,クラスタについてのキューマネジャ情報を送信します。こうして,キューマネジャはクラスタについての情報が得られ,クラスタはキューマネジャについての情報が得られます。
クラスタのシステム構成については,「2.8.11(1) リポジトリ管理の構成」を参照してください。キューマネジャQM1はQM2にあるキューへメッセージを送信するとします。QM2がQM1に対してクラスタセンダチャネルを定義し,自分自身を紹介しているので,QM1はQM2でどのようなキューが利用できるかがわかっています。QM1はQM2に対してクラスタセンダチャネルを定義しているので,そのチャネルを使用してメッセージを送信できます。
QM3は自分自身をQM2に紹介します。QM1もフルリポジトリを保持しているので,QM2はQM3についてのすべての情報をQM1に渡しています。したがって,QM1はQM3ではどのキューが利用できるか,およびQM3が定義したクラスタレシーバチャネルがどれであるかを認識します。QM1がQM3にあるキューへメッセージを送信したい場合には,QM3のクラスタレシーバチャネルと接続するクラスタセンダチャネルを自動的に作成します。
同一のクラスタおよび自動的に作成された二つのクラスタセンダチャネルについて,次の図に示します。これらは,クラスタレシーバチャネルTO.QM3へと合流する2本の破線によって表されています。また,QM1がメッセージ送信のために使用するクラスタ転送キューSYSTEM.CLUSTER.TRANSMIT.QUEUEもあります。クラスタ内のすべてのキューマネジャはクラスタ転送キューを持っていて,クラスタ転送キューから同一クラスタ内のどのキューマネジャに対してもメッセージを送信できます。
図2-45 自動定義のチャネルのあるキューマネジャのクラスタ
クラスタセンダチャネルの自動定義は,必要な時に自動的に定義されるので,クラスタの機能および効率にとってとても重要です。しかし,クラスタを機能させるために何を定義する必要があるかを示すため,この図では手作業で定義の対象になるチャネル(またはチャネルの受信側)だけを示します。
別名にはキューマネジャの別名,応答キューの別名,および別名キューがあります。これらは分散キューイング環境だけでなくクラスタ環境にも適用されます。ここでは別名がクラスタとの関連でどのように使用されるかを説明します。
キューマネジャの別名は,MQAサービス定義のmqaremque定義コマンドの-rオプションの指定値を省略する場合に,コマンド引数であるリモートキューのローカル定義で指定され,次に示す用途があります。
MQOPEN命令で指定したキューマネジャ名を別のキューマネジャに再マッピングするようキューマネジャの別名を使用できます。これは,クラスタキューマネジャでも可能です。例えば,キューマネジャは次に示すキューマネジャの別名を指定できます。
mqaremque -m CLUSQM YORK
これによってCLUSQMというキューマネジャに対する別名として使用できるキューマネジャ名としてYORKが定義されます。この定義をしたキューマネジャ上のアプリケーションがキューマネジャYORKに対してメッセージを送信すると,ローカルキューマネジャはそれをCLUSQMという名称に解決します。ローカルキューマネジャがCLUSQMという名称でない場合には,メッセージをクラスタ転送キューに登録し(そのあとCLUSQMへ転送される),転送ヘッダをYORKではなくCLUSQMに変更します。
この別名を使用してクラスタを非クラスタシステムと結合できます。例えば,クラスタITALY内のキューマネジャがPALERMOというキューマネジャ(クラスタの外部にある)と通信できるようにするには,クラスタ内のキューマネジャのうちの一つがゲートウェイとして機能する必要があります。このキューマネジャで次に示すとおり定義します。
mqaremque -c ITALY -m PALERMO -x X ROME
これはキューマネジャの別名の定義であり,ROMEをキューマネジャとして定義し通知します。クラスタITALY内のどのキューマネジャからのメッセージもROMEの名前でPALERMOのあて先に到着します。オープンハンドルにキューマネジャ名としてROMEを設定してオープンされたキューに登録されたメッセージは,別名の定義元であるゲートウェイのキューマネジャに送信されます。メッセージがそこに届くと,転送キューXに登録され,通常の非クラスタチャネルによってキューマネジャPALERMOへ転送されます。
この例ではROMEという名前を選択していますが,これには特に意味がありません。リモートキューのローカル定義名と-mオプションの指定値は同じでもかまいません。
メッセージを受信すると,キューマネジャは転送ヘッダを参照し,あて先のキューとキューマネジャの名前を調べます。参照したキューマネジャと同じ名前のキューマネジャの別名の定義を持つ場合には,転送ヘッダ内のキューマネジャ名を対応するリモートキューマネジャ名で置き換えます。
キューマネジャ別名をこのように使用するには次に示す二つの理由があります。
クラスタ外から送信されたメッセージに対する処理を負荷分散できます。
キューEDINBURGHがクラスタ内の一つ以上のキューマネジャにあるとします。クラスタ外のキューマネジャには,転送キュー,およびクラスタ内のキューマネジャに対するセンダチャネルが必要です。このクラスタ内のキューマネジャをゲートウェイキューマネジャといいます。キューEDINBURGHをゲートウェイキューマネジャ以外に配置することによって,クラスタの負荷分散機能が有効になります。
詳細については,「(d) クラスタ内での別名の使用例」の「●クラスタ外のキューマネジャによるキューへのメッセージ登録(別名使用)」を参照してください。
応答キューの別名の定義は,応答情報に代替名を指定する場合に使用します。応答キューの別名の定義は分散キューイング環境と同様にクラスタでも使用できます。例えば,次に示すような用途があります。
ReplyToQ="QUEUE" ReplyToQMgr=""
mqaremque -r OTHERQ -m PISA QUEUE
-mオプションの指定値がクラスタキューマネジャである場合でも,-mオプションとリモートキューのローカル定義名に同じ名前を指定してもかまいません。
別名キューの属性定義は,キューを識別する別名を作成するために使用します。例えば,アプリケーションを変更しないで別のキューを使用したい場合に使用します。または,メッセージが登録されるキューの本当の名前を何らかの理由でアプリケーションに知らせたくない場合や,キューの定義に使用されるものと異なる命名規則がある場合にも使用します。
キューマネジャ上の別名キューの属性定義を作成します。例えば,次に示す定義コマンドによって,PUBLICというキューがクラスタC内のキューマネジャに対して通知されます。
mqaalsque -c C PUBLIC LOCAL
PUBLICは実際はLOCALという名前のキューとして解決される別名です。PUBLICへ送信されたメッセージはLOCALという名前のキューへ送信されます。
別名キューの属性定義を使用してクラスタキューとしてキュー名を解決することもできます。例えば,次に示す定義コマンドを使用すると,PUBLICという名前でクラスタ内の別のところで通知されているキューに対して,キューマネジャがPRIVATEという名前を使用してアクセスできます。
mqaalsque PRIVATE PUBLIC
この定義にはClusterName属性は含まれないので,作成したキューマネジャでだけ適用されます。
DEMOというクラスタの外にあるQM3というキューマネジャについて,次の図に示します。QM3はクラスタをサポートしないキューマネジャでもかまいません。QM3はQ3というキューを保持しています。
クラスタ内にはQM1とQM2という二つのキューマネジャがあります。QM2はQ2というクラスタキューを保持しています。
クラスタ外のキューマネジャと通信するにはクラスタ内の一つ以上のキューマネジャがゲートウェイとして機能する必要があります。この例ではゲートウェイはQM1です。
図2-46 クラスタ外のキューマネジャからの登録
クラスタ外のキューマネジャがクラスタ内のQM2にあるキューQ2にどのようにメッセージを登録するかを説明します。
クラスタ外のキューマネジャ(QM3)は,メッセージを登録したいクラスタ内の各キューに対してリモートキューのローカル定義を持つ必要があります。例えば,次に示すとおり定義します。
mqaremque -r Q2 -m QM2 -x QM1 Q2
この図のQM3上にこのリモートキューQ2が示されています。
QM3はクラスタの一部ではないので,分散キューイングの方法で通信する必要があります。そのため,QM3はQM1に対応するセンダチャネルと転送キューを持つことになります。QM1には対応するレシーバチャネルが必要です。ただし,この図ではチャネルと転送キューは明示的には示していません。
QM3にあるアプリケーションがメッセージをQ2に登録するためにMQPUT命令を発行する場合,リモートキューのローカル定義によってメッセージはゲートウェイキューマネジャQM1を通って送信されます。
応答用の通信路を形成するため,ゲートウェイ(QM1)はクラスタ外のキューマネジャに対してキューマネジャの別名を通知します。QM1はクラスタ属性をキューマネジャの別名の定義に付けることによって,この別名をクラスタ全体に対して通知します(-rオプションが省略されていることに注意してください)。例えば,次に示すとおり定義します。
mqaremque -c DEMO -m QM3 -x X QM3
QM3はクラスタの一部ではないので,分散キューイングの方法で通信する必要があります。したがって,QM1はQM3に対してセンダチャネルと転送キューXを持つ必要があります。QM3には対応するレシーバチャネルが必要です。この図ではチャネルと転送キューは明示的には示していません。
QM2にあるアプリケーション(app2)がQM3にあるQ3へ応答を送信するためにMQPUT命令を発行すると,その応答はゲートウェイへ送信されます。ゲートウェイではキューマネジャの別名を使用して,あて先キューとキューマネジャの名前を決定します。
クラスタ外のキューマネジャからメッセージをキューに登録する別の方法があります。ゲートウェイキューマネジャ上で,例えば,ANY.CLUSTERというキューマネジャの別名を定義します。
mqaremque ANY.CLUSTER
これによって,キューマネジャANY.CLUSTERに対するどのような応答でも"null"とマッピングされます。つまり,クラスタ外のキューマネジャ内のリモートキューのローカル定義がキューマネジャ名ANY.CLUSTERを使用できるので,正確なキューマネジャ名を使用する必要がなくなります。したがって,クラスタ外のキューマネジャ上では,次に示す定義ができます。
mqaremque -r Q2 -m ANY.CLUSTER -x QM1 Q2
この定義によってメッセージは最初にQM1へ送信され,そこからクラスタキューQ2を保持するクラスタ内のキューマネジャへ転送されます。
クラスタ外へのメッセージの登録について次の図に示します。
図2-47 クラスタ外のキューマネジャへの登録
ここでQM2(クラスタ内)からメッセージをQM3にあるキューQ3(クラスタ外)に登録する方法について検討します。
ゲートウェイ(この例ではQM1)はリモートキューのローカル定義を持ち,リモートキュー(Q3)をクラスタに対して次に示すとおり通知します。
mqaremque -r Q3 -c DEMO -m QM3 Q3
QM1のゲートウェイは,クラスタ外にあるキューマネジャに対するセンダチャネルと転送キューも持っています。QM3には対応するレシーバチャネルがありますが,この図ではこれらを示していません。
メッセージをキューに登録するため,QM2にあるアプリケーションは対象キュー名(Q3)を指定し,さらに応答のあて先になるキューの名前(Q2)を指定してMQPUT命令を発行します。メッセージはQM1に送信され,QM1はリモートキューのローカル定義を使用してQM3にあるQ3にキューの名称を解決します。
QM3がクラスタ内部のキューマネジャに応答を送信するためには,通信したいクラスタ内の各キューマネジャに対してキューマネジャの別名を持つ必要があります。このキューマネジャの別名はメッセージが経由するゲートウェイの名前,つまりゲートウェイキューマネジャへの転送キューの名前を指定する必要があります。この例では,QM3はQM2に対して次に示すようなキューマネジャの別名の定義が必要です。
mqaremque -m QM2 -x QM1 QM2
QM3もQM1に対するセンダチャネルと転送キューが必要であり,QM1には対応するレシーバチャネルが必要です。
QM3にあるアプリケーション(app3)はMQPUT命令を発行し,キュー名(Q2)とキューマネジャ名(QM2)を指定して応答をQM2に送信できます。
すべてのキューマネジャを一つの大きなグループにまとめる代わりに,複数の小さなクラスタを構築できます。各クラスタでは一つ以上のキューマネジャを橋渡し役として動作させます。この方法では,利用できるキューおよびキューマネジャをクラスタ間で制限できます。この構成をマルチクラスタといいます。
別名を使用してキューおよびキューマネジャの名称を変えることによって,名称の衝突を回避したり,ローカルの命名規則に合わせることができます。
クラスタ間の橋渡しとなるキューマネジャについて次の図に示します。
図2-48 クラスタ間の橋渡し
QM1から,別クラスタ(WINDSOR)に参加しているキューマネジャ(QM3)のクラスタキュー(Q3)へメッセージを登録する例を次に示します。
QM3ではQ3を次に示すとおり作成します。
mqamkque -c WINDSOR Q3 モデルキューの定義名
QM2は両方のクラスタに参加しており,両者の橋渡し役でもあります。QM2を介して認識させる必要があるキューごとに,QM2に別名キューの属性定義(mqaalsque定義コマンド)が必要です。この図の例では,QM2で次に示す定義が必要です。Q3の別名キュー名として,MYQ3を指定します。
mqaalsque -w not_fixed -c CORNISH MYQ3 Q3
この定義によってクラスタ(CORNISH)内のキューマネジャ(例えばQM1)で動作するアプリケーションは,MYQ3という名前で参照するキューにメッセージを登録できます。このメッセージはクラスタ(WINDSOR)内のキューマネジャ(QM3)のQ3に送信されます。
キューをオープンするときには,バインディングオプションにMQOO_BIND_NOT_FIXEDまたはMQOO_BIND_AS_Q_DEFを指定する必要があります。MQOO_BIND_ON_OPENを指定した場合,キューマネジャは別名キューの属性定義を橋渡し役のキューマネジャ(QM2)に解決し,QM2はメッセージを転送しないからです。
この図は,橋渡し役として動作するキューマネジャが一つある二つのクラスタです。二つ以上のキューマネジャを橋渡し役として設定することもできます。
QM2が動作するコンピュータでは,次に示すとおり定義します。
mqttcpcs -p tcp … mqtalccha -c チャネル名1 -y "type=clussdr" -a"cluster=CORNISH" … mqtalced mqtalccha -c チャネル名2 -y "type=clussdr" -a"cluster=WINDSOR" … mqtalced
mqttcpcr -p tcp … mqtalccha -c チャネル名3 -y "type=clusrcvr" -a"cluster=CORNISH" … mqtalced
mqttcpcr -p tcp … mqtalccha -c チャネル名4 -y "type=clusrcvr" -a"cluster=WINDSOR" … mqtalced
mqamqtnam MQTサーバ名1 mqttcpcs 255 mqamqtnam MQTサーバ名2 mqttcpcr 100 mqamqtnam MQTサーバ名3 mqttcpcr 100
All Rights Reserved. Copyright (C) 2006, 2011, Hitachi, Ltd.
(C) Copyright International Business Machines Corporation 1999, 2002. All rights reserved.