2.8.10 クラスタの管理

ここでは次に示すシステム管理者のための情報を提供します。

<この項の構成>
(1) クラスタ設計の検討事項
(2) クラスタ管理の検討事項

(1) クラスタ設計の検討事項

新しいクラスタをどのように設計するか説明します。

(a) フルリポジトリを保持するキューマネジャの選択

各クラスタで,フルリポジトリを保持するためには,少なくとも一つ,できれば二つ以上のフルリポジトリキューマネジャを選択する必要があります。クラスタは一つのフルリポジトリキューマネジャでも問題なく動作しますが,二つ使用すると可用性が向上します。その場合,フルリポジトリキューマネジャ間のクラスタセンダチャネルを定義することによって,相互接続します。

図2-53 一般的な2フルリポジトリキューマネジャのトポロジ

[図データ]

これは,一般的な2フルリポジトリキューマネジャのトポロジを表しています。モデルになるクラスタのシステム構成については,「2.8.1(2) クラスタの概念」を参照してください。

キューマネジャが自分自身についての情報を送信したり,ほかのキューマネジャについての情報を要求したりすると,その情報や要求は二つのフルリポジトリキューマネジャに送信されます。クラスタセンダチャネル定義上で指定されているフルリポジトリキューマネジャが,可能な場合要求を処理しますが,選択されたフルリポジトリキューマネジャが利用できない場合,ほかのフルリポジトリキューマネジャが使用されます。最初のフルリポジトリキューマネジャが再度利用可能になると,そのフルリポジトリキューマネジャは最新の変更された情報を収集し,遅れを取り戻します。

とても巨大なクラスタでは千単位のキューマネジャがあり,二つより多くのフルリポジトリキューマネジャが必要になります。その場合,例えば,次に示すようなトポロジにできます。

図2-54 フルリポジトリキューマネジャをハブアンドスポーク構成にした配置

[図データ]

図2-55 複雑なフルリポジトリキューマネジャのトポロジ

[図データ]

すべてのフルリポジトリキューマネジャが同時に使用不能になる場合,自キューマネジャはパーシャルリポジトリにある情報を使用して処理を続行します。新しい情報と更新要求は処理されません。フルリポジトリキューマネジャがネットワークに再接続するとき,すべてのリポジトリ(フルおよびパーシャル)を最新にするようメッセージが交換されることになります。

(b) クラスタを構成

フルリポジトリを保持するための幾つかのキューマネジャを選択したら,どのキューマネジャをどのフルリポジトリとリンクするか決める必要があります。クラスタセンダチャネル定義は,クラスタのほかのフルリポジトリが見つかるフルリポジトリキューマネジャにリンクします。そのあと,キューマネジャは,メッセージを二つのフルリポジトリキューマネジャに送信します。この時,必ず最初にクラスタセンダチャネル定義を持っているフルリポジトリキューマネジャに送信します。どのフルリポジトリキューマネジャを選んだかは問題になりません。しかし,自分の構成のトポロジを検討する必要があります。また,キューマネジャの物理的,地理的位置も検討する必要があります。すべてのクラスタ情報は二つのフルリポジトリキューマネジャに送信されるので,2番目のクラスタセンダチャネル定義を作成したいような場合があります。多数のフルリポジトリが広範囲に広がるクラスタで,自分の情報がどのフルリポジトリキューマネジャに送信されるかコントロールするために定義します。

(c) 命名規則

新しいクラスタを設定する場合に,キューマネジャの命名規則を検討します。すべてのキューマネジャは,異なる名前を持つ必要があります。なお,似たような名前を付ければ,どのキューマネジャがグループになっているか覚えやすくなります。

また,すべてのクラスタレシーバチャネルは,ユニークな名前を持つように設定してください。この場合,キューマネジャ名の前にTOを付けるのも,一つの方法です(例えば,TO.QM1,TO.QM2など)。同じキューマネジャへの複数のチャネルを持っており,それぞれの優先度が異なり,異なるプロトコルを使用している場合にはTO.QM1.A1,TO.QM1.N3,およびTO.QM1.T4などの名前を使用して命名規則を拡張できます。

すべてのクラスタセンダチャネルは,対応のクラスタレシーバチャネルと同じ名前を持つことを覚えておいてください。

(d) マルチクラスタ

複数のクラスタをまとめてマルチクラスタを構成できます。次に示す場合にマルチクラスタの作成を検討してください。

キューマネジャが複数のクラスタのメンバである場合,定義の数を減らすためにネームリストを利用できます。ただし,TP1/Message Queue 07-01ではネームリストをサポートしていません。そのため次に示す項目に注意してください。

複数のクラスタがネットワークにある場合,それぞれに異なる名称を付ける必要があります。同じ名称の二つのクラスタをいったん合併した場合は,分離できません。クラスタ,およびチャネルに異なる名称を付け,mqrlsコマンドの出力を参照する時に容易に区別できるようにすることをお勧めします。正常動作をするためには,キューマネジャ名はクラスタ内でユニークである必要があります。

(e) オブジェクト

クラスタを使用するには次に示すオブジェクトが必要です。

SYSTEM.CLUSTER.REPOSITORY.QUEUE
各キューマネジャは,SYSTEM.CLUSTER.REPOSITORY.QUEUEというローカルキューを持っています。このキューは,すべてのリポジトリ情報を保存するのに使用されます。
このキューのメッセージは削除しないでください。削除した場合,OpenTP1が異常終了することがあります。また,削除したことによって,以前のクラスタ参加情報が失われるため,再度クラスタに参加する必要があります。
SYSTEM.CLUSTER.COMMAND.QUEUE
クラスタの各キューマネジャは,SYSTEM.CLUSTER.COMMAND.QUEUEというローカルキューを持っています。このキューは,メッセージをフルリポジトリに転送するのに使用されます。キューマネジャはこのキューをあて先として使用して,自分についての新しい情報または変更された情報をフルリポジトリキューマネジャに送信したり,ほかのキューマネジャについての情報の要求を送信します。
また,要求した情報の応答,および取得済みの情報の変更された情報を受信するキューとして使用します。
SYSTEM.CLUSTER.TRANSMIT.QUEUE
各キューマネジャは,SYSTEM.CLUSTER.TRANSMIT.QUEUEというローカルキューを持っています。これは,クラスタ内のすべてのキューやキューマネジャへのすべてのメッセージに使用されるクラスタ転送キューです。
注意
SYSTEM.CLUSTER.TRANSMIT.QUEUEには,ユーザメッセージとともにシステム制御用のシステムメッセージが登録されます。ユーザメッセージを削除する必要がある際には,システムメッセージを削除しないように注意してください。

(2) クラスタ管理の検討事項

システム管理者に関係する検討事項を説明します。

(a) キューマネジャのリフレッシュ

キューマネジャが保持するクラスタについての情報をリフレッシュできます。ただし,通常の運用ではほとんど実行する必要がありません。リフレッシュするにはmqrrefreshコマンドを入力します。自システム以外のキューマネジャに関連するすべてのクラスタキューマネジャオブジェクトとすべてのクラスタキューオブジェクトを,パーシャルリポジトリから削除できます。また,このコマンドはクラスタ転送キューにメッセージがなく,フルリポジトリキューマネジャに接続されていない自動定義クラスタチャネルを削除します。

注意
通常,mqrrefreshコマンドを入力する必要はありません。mqrrefreshコマンドを入力するのは,フルリポジトリキューマネジャが保持するリポジトリ情報とTP1/Message Queueがパーシャルリポジトリで保持するリポジトリ情報とに不整合が発生した場合です。次に示す場合にコマンドを入力します。
  • リポジトリ情報の破棄
    フルリポジトリキューマネジャと通信するリポジトリ情報が破棄された場合です。例えば,運用やアプリケーションの誤りによってSYSTEM.CLUSTER.COMMAND.QUEUEのメッセージを削除した場合や,SYSTEM.CLUSTER.COMMAND.QUEUEに登録すべき自キューマネジャあてのメッセージが,他キューマネジャのSYSTEM.CLUSTER.TRANSMIT.QUEUEから削除された場合です。
  • 米国IBM社からの指示
    米国IBM社によってREFRESH CLUSTERコマンドを入力することが指示された場合です。
  • クラスタレシーバチャネル名の重複解消
    クラスタ内の複数のキューマネジャに,同じ名前のクラスタレシーバチャネルがある場合,意図しないキューマネジャにメッセージが転送されることがあります。この場合,クラスタレシーバチャネルの名前を重複しないように変更したあと,重複したクラスタレシーバチャネルを使用している他キューマネジャからmqrrefreshコマンドまたはREFRESH CLUSTERコマンドを入力する必要があります。
  • RESET CLUSTERコマンドの誤入力
    誤ってRESET CLUSTER ACTION(FORCEREMOVE)コマンドを入力した場合です。
  • 復元後のキューマネジャ再開始
    キューファイルのバックアップを復元するなどして,キューマネジャを最後に終了した時点よりも前の状態で再度開始した場合です。
(b) キューマネジャの脱退

キューマネジャをクラスタから脱退できます。ただし,通常の運用ではほとんど実行する必要がありません。

脱退するにはmqrremoveコマンドを入力します。自システムのクラスタレシーバチャネルについてフルリポジトリに削除依頼を送信します。

注意
通常,mqrremoveコマンドを入力する必要はありません。mqrremoveコマンドを入力するのは,使用されなくなるTP1/Message Queue環境を削除する場合や,フルリポジトリキューマネジャが保持するリポジトリ情報とTP1/Message Queueがパーシャルリポジトリで保持するリポジトリ情報に不整合が発生した場合です。次に示す場合にコマンドを入力します。
  • 復元後のキューマネジャ再開始
    キューファイルのバックアップを復元するなどして,キューマネジャを最後に終了した時点よりも前の状態で再度開始した場合です。
  • クラスタセンダチャネルの情報の消滅
    システム時刻を戻したことなどによってクラスタセンダチャネルの情報が消滅し,リポジトリ情報をフルリポジトリに送信できない場合です。
  • SYSTEM.CLUSTER.TRANSMIT.QUEUEに障害が発生した場合
  • SYSTEM.CLUSTER.REPOSITORY.QUEUEに障害が発生した場合
  • SYSTEM.CLUSTER.COMMAND.QUEUEに障害が発生した場合
(c) クラスタ転送キューの保守

クラスタ転送キューの可用性とパフォーマンスは,クラスタのパフォーマンスにとって重要です。満杯にならないようにする必要があります。また,mqasetコマンドを間違って発行して取り出し不可や登録不可にしないように注意してください。なお,クラスタ転送キューが格納されるキューファイルは,満杯にならないように注意してください。

(d) キューマネジャ失敗時の処理

メッセージがバッチ転送によって特定のキューマネジャに送信されたがそのキューマネジャが利用不可になった場合,次に示すような対策ができます。

(e) リポジトリへの登録失敗時の処理

クラスタ情報は,SYSTEM.CLUSTER.COMMAND.QUEUEというローカルキューを介してパーシャルリポジトリに反映されます。このキューが満杯の状態である場合,リポジトリ管理サーバは動作を停止しているので,クラスタ情報メッセージはデッドレターキューに転送されます。ログメッセージから発生がわかったら,デッドレターキューからメッセージを回復し,それを正しいあて先へと転送し直すアプリケーションを実行する必要があります。

リポジトリ情報はSYSTEM.CLUSTER.REPOSITORY.QUEUEというローカルキューに格納されています。このキューが満杯の状態である場合,クラスタ情報の追加と更新ができないでエラーログが出力されます。その場合,キューマネジャを停止し,キューの容量を拡大したあと,開始してください。

キューを再作成した場合は,以前のクラスタ参加情報は失われ,再度クラスタ参加を実行します。この場合,mqrsupとmqrsppの起動をする前に,フルリポジトリキューマネジャからRESET CLUSTERコマンドを実行して,自キューマネジャをクラスタから削除してください。

キューマネジャのリポジトリの共用メモリ不足が発生した場合(とてもまれな場合),共用メモリ確保エラーがログ出力されます。この場合,キューマネジャを停止し,使用共用メモリを拡大したあと,開始します。

(f) クラスタキュー登録不可時の処理

クラスタキューが登録不可になると,この状況は,そのキューに関係している各キューマネジャのフルリポジトリに反映されます。ワークロード管理機能は,可能な場合メッセージを登録できるあて先に送信しようとします。登録できるあて先がなく,ローカルキューもない場合,MQOO_BIND_ON_OPENを指定したMQOPEN命令はリターンコードMQRC_CLUSTER_PUT_INHIBITEDをアプリケーションに返します。MQOO_BIND_NOT_FIXEDが指定されている場合,またはローカルキューがある場合,MQOPEN命令は成功しますが,以後のMQPUT命令はリターンコードMQRC_PUT_INHIBITEDで失敗します。

(g) リポジトリ情報の保持期間

キューマネジャが,例えば,新しいキューの作成を通知するためフルリポジトリキューマネジャに,自分についての情報を送信すると,フルリポジトリキューマネジャおよびパーシャルリポジトリキューマネジャはその情報を30日間保管します。リポジトリの情報の期限が切れないように,キューマネジャは,27日後に自動的に自分についてのすべての情報を再送します。30日の有効期間の途中でパーシャルリポジトリから新しい情報を要求する場合,パーシャルリポジトリは有効期間の残数を確認します。有効期間が過ぎても,情報はリポジトリから即座には削除されません。60日の猶予期間で保管されます。猶予期間中に更新情報を受け取らなかった場合,情報は削除されます。有効期日にキューマネジャが一時的に使用不能になる可能性を考慮して猶予期間があります。キューマネジャが90日を超えてクラスタから切断された場合,キューマネジャはクラスタの一部ではなくなります。

リポジトリ情報の保持期間について次の図に示します。

図2-57 リポジトリ情報の保持期間

[図データ]

注※
90日以上経過したことでリポジトリ情報が削除され,パーシャルリポジトリキューマネジャはクラスタから除去されます。
OpenTP1開始時に,パーシャルリポジトリキューマネジャは参加した情報を保持しているため,開始時に参加メッセージを送信しないで,自マネジャ情報だけを送信します。そのため,mqrremoveコマンドによって脱退しないとクラスタに参加できません。

リポジトリ情報の有効期間が切れないように,キューマネジャは27日を経過したことを検出したときに,自動的に自分についてのすべての情報を,フルリポジトリに対応するクラスタセンダチャネルを使用して再送します。クラスタセンダチャネルで送信中は,チャネル状態は「チャネル動作中」になります。

なお,事前定義クラスタセンダチャネルやデフォルトチャネル定義のチャネルの確立方法(mqtalccha定義コマンド-iオプション指定値)にmanualを指定している場合,フルリポジトリに対するクラスタセンダチャネルが動作中でないとき自動的にはリポジトリ情報は再送されません。このためユーザがチャネルを動作させる必要があります。

最後のリポジトリ情報の送信から90日以上チャネルを確立しない場合(OpenTP1未開始など),リポジトリ情報は失われます。

TP1/Message Queueは次に示す契機に有効期間の確認を行い,有効期間が過ぎている場合は更新情報を送信します。

(h) クラスタチャネル

クラスタを使用すればチャネルを定義する必要がなくなりますが,分散キューイングで使われているのと同じチャネル技術が,クラスタのキューマネジャ間の通信に使用されています。次に示すことを理解しておいてください。

(i) WebSphere MQでSUSPEND QMGRコマンドを実行した場合

WebSphere MQのキューマネジャにSUSPEND QMGRコマンドを実行した場合,ワークロード管理機能は,該当するキューマネジャに対して,そこで処理する必要のあるメッセージだけを送信するようになります。その後,RESUME QMGRコマンドを実行すると,ワークロード管理機能は通常の動作に戻ります。