Hitachi

OpenTP1 Version 7 OpenTP1 メッセージキューイング機能 TP1/Message Queue 使用の手引


2.8.3 クラスタのセットアップ

ここでは,具体的な作業例を挙げてクラスタ構築およびクラスタの使用方法について説明します。

TP1/Message Queueの環境を構築する手順については,4章の「TP1/Message Queueの環境作成手順」を参照してください。また,フルリポジトリを設定する場合は,IBM MQのマニュアルを参照してください。

例では,キューマネジャにLONDONやNEWYORKなどの名前を付けます。

〈この項の構成〉

(1) クラスタのセットアップ例の説明

作業で前提になる例について説明します。

(2) 作業を完了させるために必要な手順

このクラスタのセットアップは,次に示す手順に従って作業します。

  1. キューマネジャ(LONDON)をIBM MQで構築します。

  2. キューマネジャ(NEWYORK)をTP1/Message Queueで構築します。

    TP1/Message Queueの環境を構築する手順については,4章の「TP1/Message Queueの環境作成手順」を参照してください。

  3. クラスタの編成およびその名前を定義します。

    二つのキューマネジャ(LONDONとNEWYORK)へのリンクをクラスタ内に定義します。二つしかキューマネジャがリンクされていないクラスタでは,分散キューイングを使用するネットワークよりもそれほど有利ではありませんが,拡張の余地を残しておく点では,良い方法です。新しい支店を開店する場合には,クラスタに新しいキューマネジャを簡単に,かつ既存のネットワークに影響を与えないで追加できます。

    この場合,実行中のアプリケーションは在庫管理アプリケーションになり,クラスタ名はINVENTORYになります。

  4. フルリポジトリを保持するキューマネジャ(フルリポジトリキューマネジャ)を決定します。

    どのクラスタでも,フルリポジトリを保持する最低一つ(望ましいのは二つ)のキューマネジャを指定します。

    TP1/Message Queueはフルリポジトリをサポートしていないため,フルリポジトリをサポートしたIBM MQが必要です。この例では,キューマネジャ(LONDON)がフルリポジトリキューマネジャになります。

    ポイント

    以降の手順は,どの順序で実行してもかまいません。

  5. クラスタレシーバチャネルを定義します。

    クラスタ内の各キューマネジャ上で,参加するクラスタごとに,キューマネジャがメッセージを受信するためのクラスタレシーバチャネルを定義します。この定義によって,キューマネジャのネットワークアドレスが定義され,クラスタ内のほかのキューマネジャからメッセージを受信できることを通知する効果があります。

    この定義は,クラスタ内のほかのキューマネジャに通知されます。コンピュータのネットワークアドレスは,ほかのキューマネジャが参照できるリポジトリ内に格納されます。

    キューマネジャ(LONDON)での定義を次に示します。

    DEFINE CHANNEL(TO.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
    CONNAME(192.168.0.1) CLUSTER(INVENTORY)

    キューマネジャ(NEWYORK)での定義を次に示します。

    mqtalccha -c TO.NEWYORK -y"type=clusrcvr" \
              -r ipaddr=192.168.0.2           \
              -a "cluster = INVENTORY"

    詳細については,「2.8.9 クラスタ環境の通信構成」を参照してください。

  6. クラスタセンダチャネルを定義します。

    クラスタ内の各キューマネジャ上で,参加するクラスタごとに,クラスタセンダチャネルを一つ定義します。このクラスタセンダチャネルで,フルリポジトリキューマネジャの一つにメッセージを送信できます。この場合,フルリポジトリキューマネジャはLONDONです。パーシャルリポジトリキューマネジャはNEWYORKです。キューマネジャ(NEWYORK)には,キューマネジャ(LONDON)で定義されたクラスタレシーバチャネルを接続先とする事前定義クラスタセンダチャネル定義が必要です。事前定義クラスタセンダチャネル定義に指定するチャネル名は,対応するクラスタレシーバチャネル定義に指定された名前と一致していなければいけないので,注意が必要です。

    キューマネジャに,同じクラスタ内のクラスタレシーバチャネルとクラスタセンダチャネルの両方の定義が設定されると,クラスタセンダチャネルが開始します。

    キューマネジャ(NEWYORK)での定義を次に示します。

    mqtalccha -c TO.LONDON -y"type=clussdr" \
              -o oipaddr=192.168.0.1        \
                 oservname=listenerport     \
              -a "cluster = INVENTORY"

    詳細については,「2.8.9 クラスタ環境の通信構成」を参照してください。

  7. クラスタキューINVENTQを定義します。

    INVENTQキューをキューマネジャ(NEWYORK)で定義します。このキュー定義はクラスタのほかのキューマネジャに通知されます。

    キューマネジャ(NEWYORK)でのコマンド入力を次に示します。

    mqamkque -c INVENTORY INVENTQ モデルキューの定義名 キュー属性定義ファイル名
  8. MQAサービス定義に定義コマンドを追加します。

    次に示す項目をMQAサービス定義に追加します。

    • クラスタセンダプロセスおよびクラスタレシーバプロセスに対応するmqamqtnam定義コマンド

    • システムキューに対応するmqaquegrp定義コマンド

    これで,すべての定義が完了します。TP1/Message Queueを開始してください。

(3) 作業で構築されるクラスタ

この作業で構築されるクラスタについて,次の図に示します。

図2‒42 二つのキューマネジャがあるINVENTORYクラスタ

[図データ]

これは,とても小さなクラスタです。しかし,将来に向けての拡張性があります。

(4) 作業で構築したクラスタを使用する

INVENTQキューはクラスタに通知されているため,リモートキューのローカル定義は不要です。NEWYORK上で動作するアプリケーションとLONDON上で動作するアプリケーションは,メッセージをINVENTQキューに登録できます。また,これらのアプリケーションは,キューにメッセージを登録する時に,応答キューを提供し,その名前を指定することによって,メッセージに対する応答を受信することもできます。

次に示す例では,LONDONがINVENTQにメッセージを登録し,キューLONDON_replyに応答を受信します。

LONDON上で次に示すとおり動作します。

  1. LONDON_replyという名前のローカルキューを定義する。

  2. MQOPEN命令のオプションにMQOO_OUTPUTを設定する。

  3. MQOPEN命令を発行し,キューINVENTQを開く。

  4. メッセージ記述子のReplyToQにLONDON_replyを指定する。

  5. MQPUT命令を発行し,メッセージを登録する。

NEWYORK上で次に示すとおり動作します。

  1. MQOPEN命令のオプションにMQOO_BROWSEを設定する。

  2. MQOPEN命令を発行し,キューINVENTQを開く。

  3. MQGET命令を発行し,INVENTQからメッセージを取り出す。

  4. メッセージ記述子からReplyToQ名を取得する。

  5. オブジェクト記述子のObjectNameにReplyToQ名を指定する。

  6. オブジェクト記述子のObjectQMgrNameにキューマネジャ(LONDON)を指定する。

  7. MQOPEN命令のオプションにMQOO_OUTPUTを設定する。

  8. MQOPEN命令を発行し,キューマネジャ(LONDON)にあるLONDON_replyを開く。

  9. MQPUT命令を発行し,メッセージをLONDON_replyに登録する。

LONDON上で次に示すとおり動作します。

  1. MQOPEN命令のオプションにMQOO_BROWSEを設定する。

  2. MQOPEN命令を発行し,キューLONDON_replyを開く。

  3. MQGET命令を発行し,LONDON_replyからメッセージを取り出す。

    注意事項

    ローカルキューLONDON_replyの定義には,ClusterName属性は不要です。

(5) 既存のネットワークのクラスタへの変更

既存の分散キューイング環境を,このようなクラスタに変更した場合,「2.8.3(2) 作業を完了させるために必要な手順」の手順7では,既存のキューの定義を変更してください。また,LONDONで,INVENTQキューに対するリモートキューのローカル定義を必ず削除してください。