6.MQ運用管理と監視
6.1 MQ運用管理と監視について
今回は、MQの運用/監視について説明します。
MQの起動/停止、バックアップ/リカバリなどの運用サイクルや、実装方法を検討します。
またMQシステムの監視と障害対応について検討します。
より詳細な検討のためには、MQのマニュアルも参照してください。
－システム管理ガイド
－クライアント （MQクライアントの管理について）
－セキュリティー （MQのセキュリティー、チャネルセキュリティー（SSL）などについて）
－プログラマブル・コマンド・フォーマットおよび管理インターフェース （PCFコマンドについて）
－MQSCコマンド・リファレンス（MQSCコマンドについて）
－WebSphere MQモニター （MQのイベントについて）
6.2 運用タイムテーブルを作成する
MQが稼動しているサーバーの運用タイムテーブルを作成します。
一般的な運用タイムテーブルは、以下の処理項目から構成されます。
- 起動処理
- サービス時間帯
- 停止処理
- 運用処理（バックアップ取得、バッチ処理など）
各項目の実装内容や実装方法は、システムの運用時間要件を考慮して、検討する必要があります。
そのため、まずMQが稼動しているサーバーのタイムテーブルを作成します。
ここでは例として、日次バックアップを行うサーバーと、週次バックアップを行うサーバーのタイムテーブルを記載します。
サーバー運用タイムテーブル （例）
6.3 運用手順書を作成する
「6.2 運用タイムテーブルを作成する」Notes Link の処理項目のうち、以下のMQの運用作業について、実行手順や自動化の仕組みを検討します。
それらを運用手順書としてまとめます。
- バッチ処理（ユーザー処理）
- バックアップ処理
バックアップを取得します。事前にバックアップ対象や取得頻度を検討する必要があります。
バックアップの例として、以下に各バックアップの取得目的と取得タイミング、取得頻度についてまとめます。
例：
【メディア・イメージの取得（リニア・ログ取得時のみ）】
オブジェクト損傷時にメディア・イメージ取得時の状態に戻し、また不要ログを切り離すために取得。
キュー・マネージャー稼動中に取得。日次で取得。
チャネル切断 → アプリケーション停止（キューマネージャーは稼動継続） → メディアイメージ取得
【MQディレクトリ全体のバックアップ】
ディスク全体の損傷に備えて、MQディレクトリ全体のバックアップを取得。
MQの初期構成後にMQディレクトリ全体のバックアップを取得し、さらにmqs.iniファイルの変更やキュー・マネージャーの追加などを行なったときに取得。キュー・マネージャー停止時に取得。
キューマネージャー停止 → キューファイル（/var/mqm以下)保管
【キューマネージャー毎のバックアップ】
障害時にキュー・マネージャーをバックアップから再作成するために、必要な情報のバックアップを取得。キュー・マネージャー停止時に取得。日次で取得。
キューマネージャー停止 → キューマネージャー関連のファイルの保管（/var/mqm/mqs.ini、/var/mqm/qmgrs/キューマネージャー名以下、/var/mqm/log/キューマネージャー名以下）
【その他の情報】
その他、運用手順書にはトラブルや障害が発生した際の対処方法を記述します。
また、運用担当者にMQの豊富な知識がない場合は、MQの基本的な操作方法、使用頻度の高いコマンド、また発生頻度の高いエラーについても記載があると便利です。
運用手順書内容の例）
- 運用体制
- 監視対象と監視方法
- システム停止時の対処方法
- 運用シェル処理内容
- MQ基本情報
- MQ基本操作手順
- よくあるエラーと対処方法
- エラーログ保存箇所
など
6.4 起こりうる障害個所を特定し、監視対象を決定する
MQのサービス時間帯は、MQが正常稼動し、メッセージの処理が正常に行なわれていることを監視します。
起こり得る障害を洗い出し、何を監視対象とするかを決定します。
監視を行う対象と起こり得る障害は一般的に以下のパターンが考えられます。
(*1) 相手先停止および相手側キューFULLの場合は、相手側での対応が必要になります。
(*2) GETプログラムに異常がある場合の対処方法は、原因を回復した後、アプリケーションを再起動します。
その他、パフォーマンス監視や、サーバー・リソース監視（CPU使用率、メモリの使用状況、I/O発生状況、ディスクの空きスペース）なども必要に応じて監視対象とします。
- 影響範囲（キューマネージャー障害、ネットワーク障害、ディスク障害、ファイル障害）の検討
これらの障害は、接続先アプリケーションや相手先チャネルなどに影響を与えます。下図にあるように、キューマネージャー間接続のシステムでは、いずれかの個所で発生した障害は、他の障害へとつながり、最終的に相手先のアプリケーションへも影響を及ぼします。
例）受信側アプリケーションで障害が発生したケース
①受信アプリケーションの異常
②キューFull
③受信チャネルがダウン
④送信チャネルがダウン
⑤トランスミッション・キューがFull
⑥送信アプリケーションがMQPUTエラー
受信アプリケーションの異常でメッセージをGETできなくなったり、GETの処理が遅れだすと受信キューにメッセージが滞留します。メッセージが滞留し、キューFullになると受信チャネルはメッセージを受信できなくなります。
最終的は、送信側のキューもキューFullになる可能性もあります。
現実的には、送信側から受信側の障害を即座に検知するは難しいので、別途、監視ツール等を組み合わせた、トータルな監視体制を実現できるような運用監視設計を検討する必要があります。
また、障害時に早期の回復を行なうため、自動リカバリの仕組みを持つ、リカバリ手順書を作成するなど、障害回復手順を確立しておくことも必要です。
上記の障害が発生した後の一般的な障害回復手順としては、以下のような方法がとられます。
例）
チャネル停止 → アプリケーション停止 → 障害の原因調査（エラーログの内容確認、FDCファイル発生の確認）→ 障害回復作業（それぞれの障害に応じた回復手順はNotes Link （6.7 障害回復手順書を作成する）を参照してください）→ MQレベルの確認（チャネル状況RUNNINGの確認、メッセージのPUT/GETによる確認）→ 業務処理再開
6.5 運用に関する検討を行い、指針を作成する
MQの運用を検討します。
MQを利用したシステムを構築する場合、システム設計、アプリケーション設計がそのまま運用設計と深く関わっています。
設計の手戻りをなるべく最小化するために、システム、アプリケーションの設計は運用の事も考慮しつつ実施することが大切です。
-
- システム構成図（H/W、S/W、N/W）
例）
-
- リカバリとMQログの検討
障害発生時などにおけるMQのリカバリーでは、MQログが使用されます。
MQログには、大きく、リニアログと循環ログ種類があり、それぞれ特徴があります。どちらのログを利用するかは、システム構成、運用体制、障害時のリカバリ手順等に大きく関わってきますので、事前に十分な検討をしておく必要があります。（それぞれのログの概要については、補足を参照してください）
１．関連するシステムの稼働時間を調査します。
システム構成図をもとに、システム稼働時間を調査し、予想される計画停止についても調査します。
２．MQ資源のサービス時間を決定します。
前述のシステムの稼動時間と、事前検討した運用タイムテーブルからMQ資源のサービス時間を決めます。
たとえば、オンラインの閉局運用では、キュー属性の変更「PUT(DISABLED)」による運用や、チャネル停止による運用が考えられます。
３．サービス目標を決定します。
アプリケーション毎にMQのサービス目標を決定します。
例）
【クライアント接続時】
接続先システムの稼働時間、N/W利用可能時間がそのままサービス時間となります。
【キューマネージャー間接続】
接続先システムの稼働時間まで考慮する必要があるのか、ローカルシステムの稼働時間のみ考慮すれば良いのか、業務ごとに検討します。
４．稼働時間による制約と対応の可否を検討し、対応の実装方法を決定します。
例）接続先システム計画停止中の滞留メッセージの扱いなど
５．バックアップとログの管理方針を決定する
MQ障害時のリカバリ方法を検討し、バックアップ方針とログ管理方針を決定します。
MQでは2種類のリカバリをサポートします。
【リスタート・リカバリ/クラッシュ・リカバリ】
正常終了、または予期せぬ障害によって異常終了したキュー・マネージャーを再起動したときのリカバリです。
トランザクションの整合性を回復します。
【メディア・リカバリ】
キューなどのオブジェクト定義が損傷を受けたときのリカバリです。
コマンド、または自動にて破損したオブジェクト定義を回復します。
MQのログタイプは循環ログとリニア・ログ種類があります。
このログタイプはキューマネージャー作成時に選択する必要があり、作成後は変更できません。
メディア・リカバリはリニア・ログのみ可能となります。
いずれのリカバリもログを元に行なわれますので、ログが損傷した場合は、キュー･マネージャーの再作成か、バックアップを戻す必要があります。そのため、ログはRAIDなど重化ディスクで保護する必要があります。
６．MQの処理を洗い出し、自動化の範囲を決定する
MQとして必要な開始処理/終了処理/バックアップ処理を洗い出し、この中で、自動化できる範囲を決定します。
【補足：MQログの特徴について】
MQのログのタイプは2種類あります。
リカバリ方針に応じて、いずれかを選択します。