高可用性

内部的には、IBM MQ on Cloud のデプロイは、選択した特定の地理的リージョンで稼働する Kubernetes クラスター内にコンテナーとして構築およびデプロイされる、一連のコンポーネントを使用して行われます。 デプロイした有料キュー・マネージャーはそれぞれ、分離された独自のコンテナーに存在し、専用の CPU、RAM、およびディスクが割り振られます。

Kubernetes クラスターは、複数のワーカー・ノード (例えば、仮想マシン) で構成され、デプロイした複数のコンテナーはそれらのノード間で分散されます。コンテナーごとにヘルス・チェックと活性チェックが定義されていて、特定のタイプの障害が発生すると、Kubernetes は自動的にコンテナーを別のワーカーに移動させます。

現在のところ、MQ on Cloud インフラストラクチャーは、各リージョン内の単一のデータ・センター (「単一のアベイラビリティー・ゾーン」とも呼ばれる) にデプロイされるため、Kubernetes クラスター内の各ワーカーは 1 つのデータ・センター内に存在します。

キュー・マネージャーの持続状態 (定義されたキュー、それらのキューに入っている持続メッセージ、キュー・マネージャー・チャネルのチャネル・シーケンス状態など) は、コンテナー・イメージの外部に存在する永続ボリュームに保管されるため、キュー・マネージャー・コンテナーが別のワーカー・ノードで再始動しても、元のワーカー・ノードで実行されていたときとまったく同じ持続状態となります。

上記のアプローチは、IBM MQ on Cloud 内の高可用性の基礎を形成しており、クラスター内の個々のワーカーで障害が発生してもキュー・マネージャーが確実に稼働し続けることを可能にします。

HA キュー・マネージャー構成に必要なソリューション・アーキテクチャー

上記の MQ on Cloud のアーキテクチャーでは、基礎となるインフラストラクチャーの一部で障害が発生しても確実に稼働し続けることができるため、個々のキュー・マネージャーに対して優れたレベルの可用性が提供されます。それでも、各キュー・マネージャーが単一障害点であることには変わりません。つまり、あるキュー・マネージャーが障害回避のために新規ワーカーにフェイルオーバーされる場合や、そのキュー・マネージャーがセキュリティー・フィックスや機能更新の適用のために再始動する場合や、リージョン規模での障害が発生した場合などには、短時間の間、オフラインになります。

以下に箇条書きで示した項目では、IBM MQ on Cloud を使用して高可用性ソリューション・アーキテクチャーをデプロイする方法を示します。このアーキテクチャーでは、個々のキュー・マネージャーが一定時間オフラインになっても、サービス可用性が途切れることはありません。 このソリューション・アーキテクチャーでは、「IBM クラウド・サービス記述書」のセクション 3.2 で言及されている高可用性構成のために、IBM Cloud の契約上のサービス・レベル・アグリーメント (SLA) で規定されている、IBM MQ on Cloud の**「HA 識別構成」**も定義します。

• ユーザーは、リージョン規模の障害が発生した場合でも途切れなく可用性を確保できるように、複数のキュー・マネージャーを別々のデプロイメント・ロケーションにデプロイする必要があります (例えば、ロンドン・リージョンとフランクフルト・リージョン、あるいは、IBM Cloud のダラスと AWS の US East 1 など。それに対し、IBM Cloud のダラスに両方のキュー・マネージャーを配置するようなことはしません)。
• 各キュー・マネージャーは、同じ接続と一式のオブジェクト (キュー/トピック/チャネルなど) を使用して構成する必要があります。こうして、アプリケーションが処理を実行するためにいずれのキュー・マネージャーにも等しく接続できるようにします。
• 使用可能ないずれのキュー・マネージャーにも接続できるようにアプリケーションを構成する必要があります。
• いずれのキュー・マネージャーにも接続できるようにプロデューサー・アプリケーションを構成する必要があります (例えば、アクティブ/アクティブでワークロード・バランシング、またはアクティブ/パッシブで 1 番目のキュー・マネージャーが使用不可になった場合に 2 番目のキュー・マネージャーにフォールバック)。
• コンシューマー・アプリケーションの複数のインスタンスを、使用可能な複数のキュー・マネージャーにわたってデプロイして分散します。こうして、キュー/トピックの使用可能なインスタンスでメッセージがコンシュームされずに残ることがないようにします。
• 障害発生時にキュー・マネージャーへの接続が自動的に再確立されるように、アプリケーションの構成で自動再接続を設定する必要があります。

コールド災害復旧

上記のセクションでは、キュー・マネージャーが実行されている個々のワーカーで発生する可能性のある停止や障害に対処するために IBM MQ on Cloud がどのような高可用性を提供するかについて説明しました。しかし、より極端な障害シナリオとして、壊滅的な障害によって既存のインフラストラクチャーとデータがすべて使用不可になる、あるいは破壊されるようなシナリオも考えられます。 このような種類の障害の後にサービスを復元するプロセスを「コールド災害復旧」、その略称を「コールド DR」と呼びます。

例えば、大規模な自然災害などのために、ある特定のリージョンの MQ on Cloud インフラストラクチャーがデプロイされているデータ・センター全体がオフラインになった場合に、コールド DR シナリオが発生します。 この場合、キュー・マネージャーの実行時の状態が保管されている永続ボリュームは、使用できなくなります (単一のデータ・センター内に保管されているため)。したがってキュー・マネージャーを、壊滅的な障害が発生する前の元の状態に厳密に復元することはできません。