MQ 虎の巻 : 11. 高可用性設計

 View Only
Tue December 28, 2021 02:02 AM

11. 高可用性設計

11.1   MQの可用性を高める構成

キュー・マネージャーの高可用性を実現するためには、次の3つの構成方法があります。

 1.MQクラスター構成

 2.高可用性のためのソフトウェアを利用したフェールオーバー構成

 3.マルチインスタンス・キューマネージャー構成

その他、SYSPLEX環境のホストシステムでは、複数のキュー・マネージャーで1つのキューを共用できる”共用キュー構成”をとることも出来ます(この章で詳細のは説明しません。)。

これら3つの構成を選択する際のポイントを簡単に説明します。
お客様の環境で要求されるサービス・レベルに応じて、適切な構成を選択してください。

ノン・パーシステント・メッセージを利用している場合は、キュー・マネージャーをクローン化して1のMQクラスター構成をとることで、水平拡張を実現します。MQクラスター構成では、クラスター・キューへの送信メッセージの振り分けを行い、障害時には振り分け停止を自動で行います。

パーシステント・メッセージを利用している場合は、2または3の構成によってキュー・マネージャーを別サーバーにフェールオーバーすることで、メッセージの消失をなくします。

2と3の選択ポイントは、切り替えの時間とネットワーク・アドレスの引継ぎです。2の高可用性ソフトウェアを利用すると共有ディスクとネットワークアドレスも引き継ぐことができますが、切り替え時間は分単位になります。障害時に解消しなければいけないトランザクション量にもよりますが、例えばHACMPで分程度見込んでおく必要があります。一方、3のマルチインスタンス・キュー・マネージャーは、数十秒で切り替わりますが、ネットワーク・アドレスは引き継ぎません。

フェールオーバー中はキュー・マネージャーが停止しますので、2や3の構成にMQクラスター構成を組み合わせて、さらに可用性を高めることも可能です。

キュー・マネージャーの高可用性実現構成方法

詳細はInfoCenterの
「MQクラスター」については、「キュー・マネージャー・クラスター」を、
「HA構成」については、

あるいは

を、

をご参照ください。


11.2 MQクラスター

MQクラスターとは、複数のキュー・マネージャーを論理的に関連付ける事によって様々なメリットを提供する仕組みです。MQクラスターは主に次のようつのメリットを提供します。詳細についてはInfoCenterの、「キュー・マネージャー・クラスター」をご参照ください。

①MQメッセージレベルの負荷分散
同一MQクラスターに属する複数のキューマネージャーが同一名のクラスターキューを有する場合、そのクラスターキューに対するメッセージ送信をラウンドロビン等の方式で負荷分散する事が可能となります。原則アプリケーションへの影響はなく、MQの定義だけで実現できることが特長です。


②高可用性の実現
上記MQメッセージレベルの負荷分散を行っている場合、キューマネージャーの高可用機能を提供し、単一のキューマネージャー障害がシステム全体の障害とならないような構成を取ることが可能です。障害を起こしたキューマネージャーは自動的にメッセージ送信対象から外され、かつ、そのキューマネージャーが復旧した際にはチャネルの再接続のみで再びメッセージ送信対象に加えることが可能です。高可用性ソフトウェアが不要で、運用も簡素である事が特長です。

③MQオブジェクト定義管理の省力化
従来のMQメッセージ転送と比較して、必要となるオブジェクト定義が簡素化されます。例えば、リモートキュー定義が不要であること、転送キューはMQクラスター専用の単一の転送キューを共用するため接続先が増えても追加定義が不要であること、必要最小限のチャネル定義以外は自動生成される事がメリットとして挙げられます。特に大規模なMQネットワークにおいて運用負荷低減の効果が大きくなります。

この節では、MQクラスターのメリットのうち、「②高可用性の実現」について詳しく説明していきます。

まず、MQクラスターを使用した典型的な冗長構成例と、正常稼働時の動作を図1に示します。

MQクラスターを使用した典型的な冗長構成例と正常稼働時の動作

図1では、QMA、QMB、QMC、QMDが同一のMQクラスターに属しているキューマネージャーです。メッセージを送信するアプリケーションは、QMAと接続しており、クラスターキューQ1に対して複数のメッセージを送信します。これらのメッセージは一時的にQMA上のクラスター転送キューに保持されます。QMB~Dは同一名称のクラスターキューQ1を有しており、Q1は送信アプリからQMAを経由して送信されてくるメッセージの宛先となっています。QMAから送信される複数のメッセージは、QMB~D上のQ1に自動的に振り分けが行われ、クラスターチャネルというMQクラスター専用のチャネルを通じて転送されます。Q1に保持されたメッセージは、QMB~Dに接続した受信アプリによって受信され、後続の処理が行われます。

なお、QMAからQMB~Dへメッセージが送信される際の振分け方法として複数の方式が指定可能です。一般には、QMB上のQ1、QMC上のQ1、QMD上のQ1へとラウンドロビン送信する方式が使用されますが、MQ V6以降では重み付けや優先順位を考慮した振分け方式を指定することも可能になりました。

続いて図2に、QMBが障害を起こして利用不能になった場合の動作について示します。

QMBが障害を起こして利用不能になった場合の動作

QMBが稼働しているサーバーがダウンすると、QMAとQMBを接続しているクラスターチャネルがネットワーク障害により切断されます。この後はQMB上のQ1は自動振分の対象から外れ、残りの正常に稼働しているキューマネージャーQMCとQMDへとメッセージが送信されます。障害を起こしたサーバーが復旧し、QMBが起動後、QMAとQMB間のクラスターチャネルの接続が再確立されると、QMB上のQ1は再び自動振分の対象となり、図1の状態へと復旧します。
また、通常運用において特定のキューマネージャー上のクラスターキュー、特定のキューマネージャーを受信対象から外したい場合はコマンドによる操作も可能となっています。

MQクラスターはMQの標準機能だけで実現できるシンプルで強力な機能ですが、いくつか考慮点がありますので言及しておきます。

①フル・リポジトリを持つキューマネージャー2つ構成すること

MQクラスターに参加しているキューマネージャーはMQクラスターに関する情報を保持するためのリポジトリを有しています。リポジトリのタイプには、MQクラスターに関する全ての情報を保持するフルリポジトリーと、そのキューマネージャーに必要な情報のみを保持するパーシャル・リポジトリがあります。MQクラスター内には必ず1つフルリポジトリーを有したキューマネージャーを構成する必要がありますが、可用性を考慮してフルリポジトリーを有する2つのキューマネージャーを構成する事を推奨します。また3つ以上のキューマネージャーにフルリポジトリーを持たせる構成は、定義が煩雑になることや、ランタイムのクラスター関連情報2つのフル・リポジトリーにのみ保管され3つ以上のフルリポジトリーが存在する事の意義が薄いことから、推奨していません。

例外として、大規模な構成(例:3000キュー・マネージャー/クラスター) の場合は、負荷を分散する目的で、フル・リポジトリ3つ以上構成するケースもあります。

参考文献:サポートパックMD05 MQSeries - Design considerations for large Clusters

また、フルリポジトリの配置に関する次の推奨事項も検討して下さい。

  • フル・リポジトリを配置するサーバーのプラットフォーム、MQのバージョン・メンテナンスレベルを一致させる。
  • MQクラスターに属するキューマネージャーのうち、最も可用性の高いプラットフォームで稼働するキューマネージャーにフル・リポジトリを配置する

②MQクライアントについて

MQクラスターの負荷分散機能や高可用性を利用できるのは、図1の通り送信アプリケーションが接続しているQMAとQMB~Dのクラスターチャネル接続の箇所になります。つまり、送信アプリケーションが直接QMB~Dに対してMQクライアント接続を行うような構成ではMQクラスターの負荷分散機能や高可用性を利用できない事になります。MQクライアント接続を使用した場合の高可用構成は送信側アプリケーション実装によるラウンドロビンやチャネル定義テーブルを活用した代替キューマネージャーへの再接続によって実装する事になります。また、MQ V7.0.1以降では、後の節で説明するマルチインスタンス・キューマネージャーの機能を利用する事も可能です。

③メッセージの順序性に関する留意点

MQクラスターによる転送でメッセージレベルの負荷分散を行うと、メッセージの順序性を維持する事ができません。図1で言えば、QMB~Cに振分送信されてしまった時点で、元のメッセージ生成順序など関知せずに受信アプリが処理を行ってしまうからです。
MQクラスターにおいて順序性を保証したい場合は、複数クラスターキューへの振分を行わずに送信するキューマネージャーを固定してしまう方法(MQOPEN時にOPENオプションMQOO_BIND_ON_OPENを指定)と、アプリケーションレベルで採番を行うことによって順序性をアプリケーション的に保証する方法等が考えられます。前者は実装は簡単ですが、特定のキューマネージャーに処理が集中してしまう恐れがある一方、後者はアプリケーションの設計が複雑になってしまうというデメリットが生じてしまいます。よって、どのようにメッセージの順序性を保証するかは、環境に応じて検討する必要があります。

また、パーシステントメッセージを利用している場合は、障害発生時にキューマネージャーが保持していたパーシステントメッセージは、そのキューマネージャーが再始動するまで利用不能である事も重要な点です。順序性を守らねばならない処理の場合は、障害キューマネージャーが復旧するまで、該当の処理は事実上停止せざるを得ないからです。少しでもこの処理停止時間を短縮したいという要件がある場合は、後の節で説明するマルチインスタンス・キューマネージャーとの組み合わせを検討しても良いでしょう。

11.3   高可用性ソフトウェアを利用した構成

高可用性のためのソフトウェアを利用して、障害時にキュー・マネージャーをフェールオーバーすることが出来ます。

高可用性のソフトウェアとは、ディスクやネットワークアドレスを他のサーバーに引き継ぐことができるもので、次のような製品があります。

高可用性のソフトウェア共有ディスクにキュー・マネージャーのトランザクション・ログやキューファイルなどを配置し、フェールオーバー時にそれらを引き継ぐことで、キュー・マネージャーは障害前の状態からサービスを開始することができます。つまり、障害時にキューに滞留していたパーシステント・メッセージはそのまま処理することができ、仕掛かり中のトランザクションのin-doubt状態も解消されます。
ACTIVE-STANDBYのテイクオーバー構成

また、高可用性のソフトウェアにより、ネットワークアドレスも引き継がれるため、相手側のキュー・マネージャーやMQクライアント・アプリケーションは障害検知後に再接続するだけで、フェールオーバー後のキュー・マネージャーと接続することができます。

キュー・マネージャー間・MQクライアン接続

1.キュー・マネージャー間接続の場合

送信側がキュー・マネージャーの場合は、接続先の障害を検知すると送信チャネルが異常終了します。送信チャネルは一定間隔で再接続を試行し、フェールオーバーが完了するとチャネルは接続され、トランスミッション・キューに滞留しているメッセージの転送が開始されます。
この時、送信アプリケーションは、直接、宛先の障害を検知することなく、メッセージ送信を継続することができます。

2.MQクライアント接続の場合

送信側がMQクライアントの場合は、MQIコールのリターン・コード(MQRC_CONNECTION_BROKEN など)で接続先の障害を検知します。アプリケーションが一定間隔でMQCONNを再試行すればフェールオーバーが完了した時点でMQCONNが成功します。接続が回復するまでメッセージの送信はできません。

Active-Standbyでデフォルト構成の場合は、共有ディスクには/var/mqm以下を配置します。
Windowsではレジストリー情報などの引継ぎも必要で、構成方法はInfoCenterの「WebSphere MQ システム管理ガイド」の中のMicrosoft Cluster Service (MSCS) のサポートに記載されています。

また、UNIX環境でActive-Activeで相互にフェールオーバー構成をとる場合は、MQ構成のためにサポートパックが用意されています。

このサポート・パックにはAIXのHACMP, Sun SolarisのVeritas Cluster Server、HP-UXでのMC/ServiceGuardの構成方法が説明されています。ただし、MQ V7.0.1よりマルチ(複数)インスタンス・キュー・マネージャー機能が製品自体に追加されましたので、このサポートパックについてはそれ以前のレベルのMQとともに使用する場合とお考えください。

11.4   マルチインスタンス・キュー・マネージャー

マルチインスタンス・キュー・マネージャーは、HACMPなどの高可用性のためのソフトウェアなしにキュー・マネージャーの可用性を高めることができる機能です。
WebSphere MQ v7.0.1(2009年8月出荷)からサポートされました。詳細は、InfoCenterの「複数インスタンス・キュー・マネージャー」をご参照ください。

キュー・マネージャーは、Active-Standby(Warm)構成をとることができ、障害発生時は数十秒でフェールオーバー可能です。

NFS v4などでアクセスできるネットワークストレージにキュー・マネージャーのトランザクション・ログやキューファイルなどを配置し、フェールオーバー時にそれらを引き継ぐことで、キュー・マネージャーは障害前の状態からサービスを開始することができます。つまり、障害時にキューに滞留していたパーシステント・メッセージはそのまま処理することができ、仕掛かり中のトランザクションのin-doubt状態も解消されます。

1つのキュー・マネージャーは、アクティブ/スタンバイの2つのモードで、複数インスタンスとして稼動することが出来ます。スタンバイ・モードで起動したキュー・マネージャーは、メッセージング・サービスを提供することはできませんが、アクティブ・モードのキュー・マネージャーの稼動状況をチェックし、障害を検知したら自動でフェールオーバーし、自らがアクティブ・インスタンスとして起動します。コマンドでの明示的な切替もできます。

Active-Standbyマルチインスタンス・キューマネージャー構成

マルチインスタンス・キュー・マネージャー構成は、ネットワークアドレスを引き継ぐ機能はないため、フェールオーバー後のIPアドレスは変わってしまいます。
相手側キュー・マネージャーやMQクライアント・アプリケーションがMQ v7.0.1であれば、自動でフェールオーバー後のキュー・マネージャーと接続することができます。

キュー・マネージャー間・MQクライアント接続の場合

1.キュー・マネージャー間接続の場合
MQ v7.0.1から送信チャネルのCONNAME属性に複数の宛先情報を記述できるようになりました。CONNAMEにアクティブ/スタンバイ両方のIPアドレス(またはホスト名)を記述することにより、チャネルの自動再接続でスタンバイ・キューマネージャーへ接続されるようになります。

2.MQクライアント接続の場合
MQ v7.0.1のクライアントでは、クライアント・ライブラリーが障害を検知してキュー・マネージャーに自動再接続する機能を提供します。アプリケーションにエラーは返されないので、アプリケーションで再度MQCONNを出す必要はありません。また、障害前にオープンしていたキューなども、再接続後に自動的にオープンされます。この機能を利用するためには、アプリケーションが、MQCONNX でMQCNO_RECONNECT_xxx を指定する必要があります。

相手側キュー・マネージャーやMQクライアント・アプリケーションがMQ v7.0.1よりバージョンが低い場合は、相手側で宛先情報を切り替える仕組みが必要になります。