MQ設計虎の巻: 第6回「MQ運用管理と監視」

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

成瀬 晶子, ISE, IBM

2008年 2月 28日
更新 2009年 6月 15日

今回は、実際にMQをシステムで利用する場合の運用方針およびMQの監視項目に関する概要について説明します。

1 MQ運用管理と監視について

MQの起動/停止、バックアップ/リカバリなどの運用サイクルや、実装方法を検討します。
またMQシステムの監視と障害対応について検討します。

より詳細な検討のためには、MQのマニュアルも参照してください。

• システム管理ガイド
• クライアント（MQクライアントの管理について）
• セキュリティー（MQのセキュリティー、チャネルセキュリティー（SSL）などについて）
• プログラマブル・コマンド・フォーマットおよび管理インターフェース（PCFコマンドについて）
• MQSCコマンド・リファレンス（MQSCコマンドについて）
• WebSphere MQモニター（MQのイベントについて）

上に戻る

2 運用タイムテーブルを作成する

MQが稼動しているサーバーの運用時間のタイムテーブルを作成します。

一般的な運用タイムテーブルは、以下の処理項目から構成されます。

• 起動処理
• サービス時間帯
• 停止処理
• 運用処理（バックアップ取得、バッチ処理など）

各項目の実装内容や実装方法は、システムの運用時間要件を考慮して、検討する必要があります。
そのため、まずMQが稼動しているサーバーのタイムテーブルを作成します。

ここでは例として、日次バックアップを行うサーバーと、週次バックアップを行うサーバーのタイムテーブルを記載します。

サーバー運用 タイムテーブル　（例）

上に戻る

3 運用手順書を作成する

「2 運用タイムテーブルを作成する」の処理項目のうち、以下のMQの運用作業について、実行手順や自動化の仕組みを検討します。
それらを運用手順書としてまとめます。

• 起動処理
• 停止処理
• 運用処理（バックアップ取得）

起動処理

必要なMQコンポーネントを起動します。

キュー・マネージャー開始 -> リスナー開始　(*1) -> チャネル開始

*1．v6からはMQリスナーをLISTENERオブジェクトとして作成することにより、キュー・マネージャー起動時に自動起動させることも可能です。また、UNIXの場合、MQリスナーはinetdでも代替可能です。

終了処理

稼動中のMQコンポーネントを停止します。

チャネル切断 -> キュー・マネージャー停止　（*2） -> リスナー停止

*2．MQリスナーを自動起動に設定している場合は、キュー・マネージャーが停止するときに自動的に停止します。制御コマンドで起動したときはコマンドでの停止が必要です。

バックアップ処理

バックアップを取得します。
事前にバックアップ対象や取得頻度を検討する必要があります。

バックアップの例として、以下に各バックアップの取得目的と取得タイミング、取得頻度についてまとめます。

例）

• メディア・イメージの取得（リニア・ログ取得時のみ）
  オブジェクト損傷時にメディア・イメージ取得時の状態に戻し、また不要ログを切り離すために取得。
  キュー・マネージャー稼動中に取得。
  日次で取得。
  
  チャネル切断 -> アプリケーション停止（キューマネージャーは稼動継続） -> メディアイメージ取得
  
  
• MQディレクトリ全体のバックアップ
  ディスク全体の損傷に備えて、MQディレクトリ全体のバックアップを取得。
  MQの初期構成後にMQディレクトリ全体のバックアップを取得し、さらにmqs.iniファイルの変更やキュー・マネージャーの追加などを行なったときに取得。
  キュー・マネージャー停止時に取得。
  
  キューマネージャー停止 -> キューファイル（/var/mqm以下)保管
  
  
• キューマネージャー毎のバックアップ
  障害時にキュー・マネージャーをバックアップから再作成するために、必要な情報のバックアップを取得。
  キュー・マネージャー停止時に取得。
  日次で取得。
  
  キューマネージャー停止 -> キューマネージャー関連のファイルの保管（/var/mqm/mqs.ini、/var/mqm/qmgrs/キューマネージャー名以下、/var/mqm/log/キューマネージャー名以下）
  
  
• その他の情報
  

  その他、運用手順書にはトラブルや障害が発生した際の対処方法を記述します。 また、運用担当者にMQの豊富な知識がない場合は、MQの基本的な操作方法、使用頻度の高いコマンド、また発生頻度の高いエラーについても記載があると便利です。

  運用手順書内容（例）

  • 使用するシステムの環境
    • MQ構成図
    • MQ構成オブジェクト一覧
  • 運用体制
    • 監視対象と監視方法
    • システム停止時の対処方法
    • 運用シェル処理内容
  • MQ基本情報
    • MQ基本操作手順
    • よくあるエラーと対処方法
    • エラーログ保存箇所

  など

上に戻る

4 障害個所を特定し、監視対象を決定する

MQのサービス時間帯は、MQが正常稼動し、メッセージの処理が正常に行なわれていることを監視します。
起こり得る障害を洗い出し、何を監視対象とするかを決定します。

監視を行う対象と起こり得る障害は一般的に以下のパターンが考えられます。

（*1） 相手先停止および相手側キューFULLの場合は、相手側での対応が必要になります。

（*2） GETプログラムに異常がある場合の対処方法は、原因を回復した後、アプリケーションを再起動します。

その他、パフォーマンス監視や、サーバー・リソース監視（CPU使用率、メモリの使用状況、I/O発生状況、ディスクの空きスペース）なども必要に応じて監視対象とします。

	例）	受信側アプリケーションで障害が発生したケース
		拡大図

1. 受信アプリケーションの異常
2. キューFull
3. 受信チャネルがダウン
4. 送信チャネルがダウン
5. トランスミッション・キューがFull
6. 送信アプリケーションがMQPUTエラー

受信アプリケーションの異常でメッセージをGETできなくなったり、GETの処理が遅れだすと受信キューにメッセージが滞留します。
メッセージが滞留し、キューFullになると受信チャネルはメッセージを受信できなくなります。
最終的は、送信側のキューもキューFullになる可能性もあります。

現実的には、送信側から受信側の障害を即座に検知するは難しいので、別途、監視ツール等を組み合わせた、トータルな監視体制を実現できるような運用監視設計を検討する必要があります。
また、障害時に早期の回復を行なうため、自動リカバリの仕組みを持つ、リカバリ手順書を作成するなど、障害回復手順を確立しておくことも必要です。

上に戻る

5 運用に関する検討を行い、指針を作成する

MQの運用を検討します。
MQを利用したシステムを構築する場合、システム設計、アプリケーション設計がそのまま運用設計と深く関わっています。
設計の手戻りをなるべく最小化するために、システム・アプリケーションの設計は運用の事も考慮しつつ実施することが大切です。

運用検討時には、下記の資料を用意しておきます。

• システム構成図（H/W、S/W、N/W）（例）
  
  
  
  
  
  
• リカバリとMQログの検討
  

  障害発生時などにおけるMQのリカバリーでは、MQログが使用されます。
  MQログには、大きく、リニアログと循環ログの2種類があり、それぞれ特徴があります。どちらのログを利用するかは、システム構成、運用体制、障害時のリカバリ手順等に大きく関わってきますので、事前に十分な検討をしておく必要があります。
  （それぞれのログの概要については、補足を参照してください）

• 運用タイムテーブル 「2 運用タイムテーブルを作成する」で作成したもの

運用設計の検討例

1. 関連するシステムの稼働時間を調査します。
   システム構成図をもとに、システム稼働時間を調査し、予想される計画停止についても調査します。
2. MQ資源のサービス時間を決定します。
   前述のシステムの稼動時間と、事前検討した運用タイムテーブルからMQ資源のサービス時間を決めます。 たとえば、オンラインの閉局運用では、キュー属性の変更「PUT(DISABLED)」による運用や、チャネル停止による運用が考えられます。
3. サービス目標を決定します。
   アプリケーション毎にMQのサービス目標を決定します。
   例)
   • クライアント接続時： 接続先システムの稼働時間、N/W利用可能時間がそのままサービス時間となります。
   • キューマネージャー間接続： 接続先システムの稼働時間まで考慮する必要があるのか、ローカルシステムの稼働時間のみ考慮すれば良いのか、業務ごとに検討します。
4. 稼働時間による制約と対応の可否を検討し、対応の実装方法を決定します。
   例）
   • 接続先システム計画停止中の滞留メッセージの扱いなど
5. バックアップとログの管理方針を決定する
   MQ障害時のリカバリ方法を検討し、バックアップ方針とログ管理方針を決定します。

   MQでは2種類のリカバリをサポートします。

   【リスタート・リカバリ/クラッシュ・リカバリ】
   正常終了、または予期せぬ障害によって異常終了したキュー・マネージャーを再起動したときのリカバリです。
   トランザクションの整合性を回復します。

   【メディア・リカバリ】
   キューなどのオブジェクト定義が損傷を受けたときのリカバリです。 コマンド、または自動にて破損したオブジェクト定義を回復します。

   MQのログタイプは循環ログとリニア・ログの2種類があります。
   このログタイプはキューマネージャー作成時に選択する必要があり、作成後は変更できません。
   メディア・リカバリはリニア・ログのみ可能となります。

   いずれのリカバリもログを元に行なわれますので、ログが損傷した場合は、キュー･マネージャーの再作成か、バックアップを戻す必要があります。
   そのため、ログはRAIDなどの2重化ディスクで保護する必要があります。

6. MQの処理を洗い出し、自動化の範囲を決定する
   MQとして必要な開始処理/終了処理/バックアップ処理を洗い出し、この中で、自動化できる範囲を決定します。

【補足：MQログの特徴について】

MQのログのタイプは2種類あります。
リカバリ方針に応じて、いずれかを選択します。

	循環ログ	リニア・ログ
特徴	ログ・ファイルを循環して使用	ログ・ファイルを随時アロケーションしながら使用（ログ・ファイルは増加し続ける）
オブジェクト定義の損傷時	オブジェクト定義の再作成、またはバックアップからのリカバリ	メディア・リカバリが使用可能
指定方法	crtmqmコマンドの-lc オプション、または、 mqs.iniファイルにLogType=CIRCULARを指定	crtmqmコマンドの-llオプション、または、 mqs.iniファイルにLogType=LINEARを指定
運用	特に考慮は不要	増え続けるログを削除するための運用が必要になる

※備考

• MQログは、キューマネージャー作成時に指定する必要があります。変更するには、キューマネージャーの再作成が必要ですので注意してください。
• 2次ログは長時間、同期点処理を完了しないトランザクションがあり、ログ・スペースが不足すると一時的にアロケーションされ、使用されるものです。

【補足：リニアログの特徴について】

• ログ・ファイルは増加し続けます
  • ファイル名は"Snnnnnnn.LOG"となります(nは0から順にカウントアップ）。
  • /var/mqm/log/QmgrName/active ディレクトリーに随時作成されます。
  • 全オブジェクトのメディアイメージを定期的に取得し、不要なログを削除する運用を行う必要があります。
• メディア・リカバリーが可能です
  • 個々のキュー・オブジェクト(ファイル）に障害が発生した場合でも、障害直前のメッセージまで回復可能です。
  • オブジェクトに障害が発生した場合には、コマンドによってリカバリーを行います。
• チェック・ポイント取得時、AMQERR01.LOGに書かれるログ情報に、以下の2タイプがあります
  
  

  AMQ7467	キュー・マネジャー再始動に必要なログ番号	inactiveログ発生時、カウント・アップ 必ずディスク上に存在する必要あり
  AMQ7468	メディア・リカバリーに必要なログ番号	明示的にメディア・イメージを取得するとカウント・アップ メディア・リカバリー実行時のみディスク上に必要

  
  
  
  
  
  
  
  注） MQログは、キュー・マネジャー作成時に指定する必要があります。変更するには、キュー・マネジャーの再作成が必要ですので注意してください。

上に戻る

6 監視の実装方法を決定する

1. 監視目的とレベルを検討し、監視対象を決定します。
   業務がオンライン業務であるか、バッチ業務であるかにより、監視要件が変わってきます。 オンライン業務の場合は特に、障害・パフォーマンス劣化の検知のリアルタイム性が求められます。
   • 監視目的：障害監視、パフォーマンス監視（メッセージのスループット）、リソース監視（プロセス、ディスク、ネットワークなど）
   • 監視レベル：リアルタイム or バッチ
   • 監視対象：システムレベル or MQオブジェクト（参考 4. 障害個所を特定し、監視対象を決定する ）
2. 監視拠点を決定します。
   サーバーが複数台存在する/クライアント接続を行う/他社との接続を行う といった場合は、監視対象として漏れが無い様に検討する必要があります。
   • 監視拠点：監視の範囲：
   • 監視の範囲：自システムのみ or 接続先システムまで
   1、2を検討し、実施する項目に○をつけます。
   
   

   監視目的	障害監視		パフォーマンス監視		リソース監視
   監視レベル	リアルタイム		バッチ
   監視対象	システムレベル		MQオブジェクト
   監視拠点	集中		各拠点
   監視の範囲	自システム		接続先システム

   
   
   
3. それぞれの実施項目について、実装方法を検討します。
   作り込みあるいは専用ツールの検討は提案フェーズで決定しているべき内容です。ここでは、それぞれの方法による実装方法を検討します。
   • 作り込み：MQのイベントを利用したプログラム作成、OSレベルのコマンドやMQSCコマンドの定期的発行、エラーログ・ファイルやMQのシステム・プロセスを監視するユーザー開発アプリ
   • 専用ツール：新規導入または既存のMQ運用監視ツールによる対応

【参考：MQが提供する監視インターフェース】

• オンライン・モニタリング
  定期的にMQの状況照会コマンドを発行することで、異常の有無を確認することが可能。
  MQSCコマンド ・・・　チャネルの稼動状況やキューの滞留状況などの各種ステータスを照会するコマンドを提供。シェルでの実装が可能。
  PCFコマンド　 ・・・　コマンド・サーバー経由で監視を実施。監視プログラムの開発が必要。

  [解説]
  MQSCコマンドでの実装の方が、シェルで実装可能なため簡単ですが、MQSCコマンドの実行結果のパラメーター・キーワードの位置が、バージョンアップなどにより変更される可能性があります。
  また、MQSCコマンドの発行のたびにキュー・マネージャーとの接続/切断を繰り返すため、監視インターバルが短いと、キュー・マネージャーに負荷がかかる可能性があります。

• イベント・モニタリング
  MQのイベント設定のON/OFFにより、監視対象イベントが発生すると、MQメッセージでイベント発生を通知することが可能。
  監視アプリケーションは、イベント・メッセージを受信し、異常があれば監視システムに通知するように実装。
• エラー・ログ
  MQのアクティビティが記録されるエラー・ログを監視し、異常を検知することが可能。
  ただし、メッセージは固有のID(AMQnnnn）と共に出力されるが、情報のレベル（エラー、警告、インフォメーション）を識別する識別子は含まれない。
  エラー・ログを監視対象とするときは、監視対象とするエラー・メッセージの選別が必要。

その他、プロセス監視や、サーバーのリソース監視については、OSが提供する監視インターフェースなども利用して監視の実装方法を検討します。

【参考：MQ運用監視ツール一覧】

MQ管理ツールの一覧です。

-2009年5月現在-

上に戻る

7 障害回復手順書を作成する

障害が起きたときの対処方法を障害ケースごとに想定し、以下の順序で障害回復手順書を作成します。

• 障害発生箇所
• 障害により発生する事象
• 必要な対応
• 障害からの回復手順

• 通信障害
  
  

  障害個所	チャネル
  事象	チャネル切断
  対応	MQによる自動処理
  障害回復手順	通信障害回復後、MQのチャネルREtrY機能により自動的に再度接続を確立

  
  
  
• ディスク、キュー障害
  
  

  障害個所	/var/mqmおよび/var/mqm/log以下のファイルシステム
  事象	キュー・マネジャー停止
  対応	手動によるMQ開始処理
  障害回復手順	1.　MQファイルシステム障害発生
  	2.　管理ツールにて障害を検知
  	3.　MQ停止処理（MQ停止シェルを使用）
  	4.　/var/mqmおよび/var/mqm/logファイルシステムのバックアップよりリストア
  	5.　手動によるキュー・マネジャー起動処理
  	6.　手動によるリスナー起動処理
  	7.　手動によるチャネル・リセット処理
  	8.　手動によるチャネル開始処理
  	9.　手動によるチャネル確認処理（メッセージPUT/GET）

  
  
  
• プロセス障害
  
  

  障害個所	MQプロセス
  事象	キュー・マネジャー停止、MQ正常操作不能
  対応	管理ツールによる検知、回復
  障害回復手順	1.　MQプロセス障害発生
  	2.　管理ツールが検知
  	3.　MQ停止シェル発行
  	4.　MQ開始シェル発行

  
  
  

参考文献

• developerWorks Japan: WebSphere: WebSphereの日本の技術情報サイトです
  
  
• developerWorks: WebSphere(US) : WebSphereの英語の技術情報サイトです

著者について

		成瀬 晶子, ISE

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る