新しいクラスタをどのように設計するか説明します。
各クラスタで,フルリポジトリを保持するためには,少なくとも一つ,できれば二つ以上のフルリポジトリキューマネジャを選択する必要があります。クラスタは一つのフルリポジトリキューマネジャでも問題なく動作しますが,二つ使用すると可用性が向上します。その場合,フルリポジトリキューマネジャ間のクラスタセンダチャネルを定義することによって,相互接続します。
図2-53 一般的な2フルリポジトリキューマネジャのトポロジ
これは,一般的な2フルリポジトリキューマネジャのトポロジを表しています。モデルになるクラスタのシステム構成については,「2.8.1(2) クラスタの概念」を参照してください。
キューマネジャが自分自身についての情報を送信したり,ほかのキューマネジャについての情報を要求したりすると,その情報や要求は二つのフルリポジトリキューマネジャに送信されます。クラスタセンダチャネル定義上で指定されているフルリポジトリキューマネジャが,可能な場合要求を処理しますが,選択されたフルリポジトリキューマネジャが利用できない場合,ほかのフルリポジトリキューマネジャが使用されます。最初のフルリポジトリキューマネジャが再度利用可能になると,そのフルリポジトリキューマネジャは最新の変更された情報を収集し,遅れを取り戻します。
とても巨大なクラスタでは千単位のキューマネジャがあり,二つより多くのフルリポジトリキューマネジャが必要になります。その場合,例えば,次に示すようなトポロジにできます。
図2-54 フルリポジトリキューマネジャをハブアンドスポーク構成にした配置
図2-55 複雑なフルリポジトリキューマネジャのトポロジ
すべてのフルリポジトリキューマネジャが同時に使用不能になる場合,自キューマネジャはパーシャルリポジトリにある情報を使用して処理を続行します。新しい情報と更新要求は処理されません。フルリポジトリキューマネジャがネットワークに再接続するとき,すべてのリポジトリ(フルおよびパーシャル)を最新にするようメッセージが交換されることになります。
フルリポジトリを保持するための幾つかのキューマネジャを選択したら,どのキューマネジャをどのフルリポジトリとリンクするか決める必要があります。クラスタセンダチャネル定義は,クラスタのほかのフルリポジトリが見つかるフルリポジトリキューマネジャにリンクします。そのあと,キューマネジャは,メッセージを二つのフルリポジトリキューマネジャに送信します。この時,必ず最初にクラスタセンダチャネル定義を持っているフルリポジトリキューマネジャに送信します。どのフルリポジトリキューマネジャを選んだかは問題になりません。しかし,自分の構成のトポロジを検討する必要があります。また,キューマネジャの物理的,地理的位置も検討する必要があります。すべてのクラスタ情報は二つのフルリポジトリキューマネジャに送信されるので,2番目のクラスタセンダチャネル定義を作成したいような場合があります。多数のフルリポジトリが広範囲に広がるクラスタで,自分の情報がどのフルリポジトリキューマネジャに送信されるかコントロールするために定義します。
新しいクラスタを設定する場合に,キューマネジャの命名規則を検討します。すべてのキューマネジャは,異なる名前を持つ必要があります。なお,似たような名前を付ければ,どのキューマネジャがグループになっているか覚えやすくなります。
また,すべてのクラスタレシーバチャネルは,ユニークな名前を持つように設定してください。この場合,キューマネジャ名の前にTOを付けるのも,一つの方法です(例えば,TO.QM1,TO.QM2など)。同じキューマネジャへの複数のチャネルを持っており,それぞれの優先度が異なり,異なるプロトコルを使用している場合にはTO.QM1.A1,TO.QM1.N3,およびTO.QM1.T4などの名前を使用して命名規則を拡張できます。
すべてのクラスタセンダチャネルは,対応のクラスタレシーバチャネルと同じ名前を持つことを覚えておいてください。
複数のクラスタをまとめてマルチクラスタを構成できます。次に示す場合にマルチクラスタの作成を検討してください。
キューマネジャが複数のクラスタのメンバである場合,定義の数を減らすためにネームリストを利用できます。ただし,TP1/Message Queue 07-01ではネームリストをサポートしていません。そのため次に示す項目に注意してください。
複数のクラスタがネットワークにある場合,それぞれに異なる名称を付ける必要があります。同じ名称の二つのクラスタをいったん合併した場合は,分離できません。クラスタ,およびチャネルに異なる名称を付け,mqrlsコマンドの出力を参照する時に容易に区別できるようにすることをお勧めします。正常動作をするためには,キューマネジャ名はクラスタ内でユニークである必要があります。
図2-56 サービス階層
クラスタを使用するには次に示すオブジェクトが必要です。
システム管理者に関係する検討事項を説明します。
キューマネジャが保持するクラスタについての情報をリフレッシュできます。ただし,通常の運用ではほとんど実行する必要がありません。リフレッシュするにはmqrrefreshコマンドを入力します。自システム以外のキューマネジャに関連するすべてのクラスタキューマネジャオブジェクトとすべてのクラスタキューオブジェクトを,パーシャルリポジトリから削除できます。また,このコマンドはクラスタ転送キューにメッセージがなく,フルリポジトリキューマネジャに接続されていない自動定義クラスタチャネルを削除します。
キューマネジャをクラスタから脱退できます。ただし,通常の運用ではほとんど実行する必要がありません。
脱退するにはmqrremoveコマンドを入力します。自システムのクラスタレシーバチャネルについてフルリポジトリに削除依頼を送信します。
クラスタ転送キューの可用性とパフォーマンスは,クラスタのパフォーマンスにとって重要です。満杯にならないようにする必要があります。また,mqasetコマンドを間違って発行して取り出し不可や登録不可にしないように注意してください。なお,クラスタ転送キューが格納されるキューファイルは,満杯にならないように注意してください。
メッセージがバッチ転送によって特定のキューマネジャに送信されたがそのキューマネジャが利用不可になった場合,次に示すような対策ができます。
クラスタ情報は,SYSTEM.CLUSTER.COMMAND.QUEUEというローカルキューを介してパーシャルリポジトリに反映されます。このキューが満杯の状態である場合,リポジトリ管理サーバは動作を停止しているので,クラスタ情報メッセージはデッドレターキューに転送されます。ログメッセージから発生がわかったら,デッドレターキューからメッセージを回復し,それを正しいあて先へと転送し直すアプリケーションを実行する必要があります。
リポジトリ情報はSYSTEM.CLUSTER.REPOSITORY.QUEUEというローカルキューに格納されています。このキューが満杯の状態である場合,クラスタ情報の追加と更新ができないでエラーログが出力されます。その場合,キューマネジャを停止し,キューの容量を拡大したあと,開始してください。
キューを再作成した場合は,以前のクラスタ参加情報は失われ,再度クラスタ参加を実行します。この場合,mqrsupとmqrsppの起動をする前に,フルリポジトリキューマネジャからRESET CLUSTERコマンドを実行して,自キューマネジャをクラスタから削除してください。
キューマネジャのリポジトリの共用メモリ不足が発生した場合(とてもまれな場合),共用メモリ確保エラーがログ出力されます。この場合,キューマネジャを停止し,使用共用メモリを拡大したあと,開始します。
クラスタキューが登録不可になると,この状況は,そのキューに関係している各キューマネジャのフルリポジトリに反映されます。ワークロード管理機能は,可能な場合メッセージを登録できるあて先に送信しようとします。登録できるあて先がなく,ローカルキューもない場合,MQOO_BIND_ON_OPENを指定したMQOPEN命令はリターンコードMQRC_CLUSTER_PUT_INHIBITEDをアプリケーションに返します。MQOO_BIND_NOT_FIXEDが指定されている場合,またはローカルキューがある場合,MQOPEN命令は成功しますが,以後のMQPUT命令はリターンコードMQRC_PUT_INHIBITEDで失敗します。
キューマネジャが,例えば,新しいキューの作成を通知するためフルリポジトリキューマネジャに,自分についての情報を送信すると,フルリポジトリキューマネジャおよびパーシャルリポジトリキューマネジャはその情報を30日間保管します。リポジトリの情報の期限が切れないように,キューマネジャは,27日後に自動的に自分についてのすべての情報を再送します。30日の有効期間の途中でパーシャルリポジトリから新しい情報を要求する場合,パーシャルリポジトリは有効期間の残数を確認します。有効期間が過ぎても,情報はリポジトリから即座には削除されません。60日の猶予期間で保管されます。猶予期間中に更新情報を受け取らなかった場合,情報は削除されます。有効期日にキューマネジャが一時的に使用不能になる可能性を考慮して猶予期間があります。キューマネジャが90日を超えてクラスタから切断された場合,キューマネジャはクラスタの一部ではなくなります。
リポジトリ情報の保持期間について次の図に示します。
図2-57 リポジトリ情報の保持期間
リポジトリ情報の有効期間が切れないように,キューマネジャは27日を経過したことを検出したときに,自動的に自分についてのすべての情報を,フルリポジトリに対応するクラスタセンダチャネルを使用して再送します。クラスタセンダチャネルで送信中は,チャネル状態は「チャネル動作中」になります。
なお,事前定義クラスタセンダチャネルやデフォルトチャネル定義のチャネルの確立方法(mqtalccha定義コマンド-iオプション指定値)にmanualを指定している場合,フルリポジトリに対するクラスタセンダチャネルが動作中でないとき自動的にはリポジトリ情報は再送されません。このためユーザがチャネルを動作させる必要があります。
最後のリポジトリ情報の送信から90日以上チャネルを確立しない場合(OpenTP1未開始など),リポジトリ情報は失われます。
TP1/Message Queueは次に示す契機に有効期間の確認を行い,有効期間が過ぎている場合は更新情報を送信します。
クラスタを使用すればチャネルを定義する必要がなくなりますが,分散キューイングで使われているのと同じチャネル技術が,クラスタのキューマネジャ間の通信に使用されています。次に示すことを理解しておいてください。
WebSphere MQのキューマネジャにSUSPEND QMGRコマンドを実行した場合,ワークロード管理機能は,該当するキューマネジャに対して,そこで処理する必要のあるメッセージだけを送信するようになります。その後,RESUME QMGRコマンドを実行すると,ワークロード管理機能は通常の動作に戻ります。