サポートコンソール開発者トライアルの開始お問い合わせ

4.11. 高可用性およびメッセージの移行

4.11.1. 高可用性

高可用性という用語は、そのシステムの一部に障害が発生したりシャットダウンしている場合でも、稼働を継続できるシステムを指します。AMQ Broker on OpenShift Container Platform の場合、ブローカー Pod が失敗した場合にメッセージングデータの整合性と可用性を確保したり、デプロイメントを意図的にスケールダウンしてシャットダウンします。

OpenShift Container Platform の AMQ Broker の高可用性を確保するには、ブローカークラスターで複数のブローカー Pod を実行します。各ブローカー Pod は、永続ボリューム要求 (PVC) で使用するために要求する利用可能な永続ボリューム (PV) にメッセージデータを書き込みます。ブローカー Pod が失敗するか、シャットダウンされた場合、PV に保存されているメッセージデータはブローカークラスターの別の利用可能なブローカー Pod に移行されます。他のブローカー Pod はメッセージデータを独自の PV に保存します。

以下の図は、StatefulSet ベースのブローカーのデプロイメントを示しています。この場合、ブローカークラスターの 2 つのブローカー Pod は引き続き実行されます。

ahocp Pod のドレイン

ブローカー Pod がシャットダウンすると、AMQ Broker Operator は、ブローカークラスターで実行中の別のブローカー Pod へのメッセージ移行を実行するスケールダウンコントローラーを自動的に開始します。このメッセージの移行プロセスは、Pod のドレインとしても知られています。以降のセクションでは、メッセージの移行について説明します。

4.11.2. メッセージの移行

メッセージの移行は、デプロイメントの意図的なスケールダウンによりクラスター化されたデプロイメント内のブローカーがシャットダウンした場合に、メッセージングデータの整合性を確保する方法です。このプロセスは、Pod のドレインとしても、シャットダウンしたブローカー Pod からのメッセージの削除および再分配を指します。

注記
  • メッセージ移行を実行するスケールダウンコントローラーは、単一の OpenShift プロジェクト内でのみ動作します。コントローラーは、別のプロジェクトのブローカー間でメッセージを移行できません。
  • メッセージの移行を使用するには、デプロイメントに 2 つ以上のブローカーが必要です。デフォルトでは 2 つ以上のブローカーを持つブローカーはクラスター化されます。

Operator ベースのブローカーのデプロイメントでは、デプロイメントのメインブローカーカスタムリソースで messageMigration を true に設定して、メッセージの移行を有効にします。

メッセージ移行プロセスは、次の手順を実行します。

  1. デプロイメントの意図的なスケールダウンにより、デプロイメント内のブローカー Pod がシャットダウンすると、Operator は自動的にスケールダウンコントローラーを起動してメッセージ移行の準備をします。縮小コントローラーは、ブローカークラスターと同じ OpenShift プロジェクト名で実行されます。
  2. 縮小コントローラーは、それ自体を登録し、プロジェクトの Persistent Volume Claim (永続ボリューム要求、PVC) に関連する Kubernetes イベントをリッスンします。

  3. 孤立した永続ボリューム (PV) の有無を確認するには、縮小コントローラーはボリューム要求上の序数を探します。コントローラーは、ボリューム要求の序数を、プロジェクトの StatefulSet (ブローカークラスター) で実行されているブローカー Pod と比較します。

    ボリューム要求の序数がブローカー Pod の序数よりも高くなる場合、スケールダウンコントローラーは、その序数のブローカー Pod がシャットダウンされ、メッセージングデータが別のブローカー Pod に移行する必要があるかどうかを判断します。

  4. 縮小コントローラーはドレイン Pod を起動します。ドレイン Pod はブローカーを実行し、メッセージ移行を実行します。次に、ドレイン Pod は孤立したメッセージを移行する代替ブローカー Pod を識別します。

    注記

    メッセージの移行を可能にするには、少なくとも 1 つ以上のブローカー Pod がデプロイメントで実行されている必要があります。

以下の図は、スケールダウンコントローラー (ドレインコントローラーとしても知られる) がメッセージを稼働中のブローカー Pod に移行する方法を示しています。

ahocp Pod ドレイン 3

メッセージを運用ブローカー Pod に正常に移行した後、ドレイン Pod はシャットダウンし、スケールダウンコントローラーは孤立した PV の PVC を削除します。PV は Released の状態に戻ります。

注記

ブローカーデプロイメントを 0 (ゼロ) にスケールダウンする場合、メッセージングデータを移行できる稼働中のブローカー Pod がないため、メッセージ移行は行われません。ただし、デプロイメントをゼロにスケールダウンしてから、元のデプロイメントよりも小さいサイズに再び戻すと、シャットダウンされたブローカーについてのドレイン Pod が起動します。

関連情報

  • ブローカーのデプロイメントをスケールダウンする際のメッセージ移行の例については、縮小後のメッセージの移行 を参照してください。

4.11.3. スケールダウン時のメッセージの移行

ブローカーデプロイメントの縮小時にメッセージを移行するには、メインブローカーカスタムリソース (CR) を使用してメッセージの移行を有効にします。AMQ Broker Operator は、クラスター化されたブローカーデプロイメントをスケールダウンする際に、専用のスケールダウンコントローラーを自動的に実行し、メッセージ移行を実行します。

メッセージ移行を有効にすると、Operator 内のスケールダウンコントローラーがブローカー Pod のシャットダウンを検出し、ドレイン Pod を開始し、メッセージ移行を実行します。ドレイン Pod は、クラスター内の他のライブブローカー Pod の 1 つに接続し、メッセージをそのライブブローカー Pod に移行します。移行が完了すると、スケールダウンコントローラーがシャットダウンします。

注記
  • 縮小コントローラーは、単一の OpenShift プロジェクト内でのみ機能します。コントローラーは、別のプロジェクトのブローカー間でメッセージを移行できません。
  • ブローカーデプロイメントを 0 (ゼロ) にスケールダウンする場合、メッセージングデータを移行できる稼働中のブローカー Pod がないため、メッセージ移行は行われません。ただし、デプロイメントをゼロブローカーにスケールダウンし、元のデプロイメントに含まれていた一部のブローカーのみに戻っても、シャットダウンされたブローカーのドレイン Pod が起動します。

以下の手順の例は、スケールダウンコントローラーの動作を示しています。

前提条件

手順

  1. 当初ダウンロードおよび抽出した Operator リポジトリーの deploy/crs ディレクトリーで、メインブローカー CR の broker_activemqartemis_cr.yaml を開きます。

  2. メインブローカー CR では、messageMigration および persistenceEnabled を true に設定します。

    これらの設定は、クラスターブローカーデプロイメントのサイズを後でスケールダウンすると、Operator はスケールダウンコントローラーが自動的に起動し、メッセージを実行中のブローカー Pod に移行することができます。

  3. 既存のブローカーデプロイメントで、実行中の Pod を確認します。 

    $ oc get pods

    以下のような出力が表示されます。 

    activemq-artemis-operator-8566d9bf58-9g25l   1/1   Running   0   3m38s
ex-aao-ss-0                                  1/1   Running   0   112s
ex-aao-ss-1                                  1/1   Running   0   8s

    上記の出力では、3 つの Pod が実行されていることが示されています。1 つはブローカー Operator 自体用で、デプロイメントの各ブローカーに個別の Pod が実行されていることを示しています。

  4. 各 Pod にログインし、各ブローカーにメッセージを送信します。

    1. Pod ex-aao-ss-0 にクラスター IP アドレスが 172.17.0.6 である場合は、以下のコマンドを実行します。 

      $ /opt/amq/bin/artemis producer --url tcp://172.17.0.6:61616 --user admin --password admin

    2. Pod ex-aao-ss-1 にクラスター IP アドレスが 172.17.0.7 である場合は、以下のコマンドを実行します。 

      $ /opt/amq/bin/artemis producer --url tcp://172.17.0.7:61616 --user admin --password admin

      前述のコマンドは、各ブローカーに TEST というキューを作成し、各キューに 1000 個のメッセージを追加します。

  5. クラスターを 2 つのブローカーにスケールダウンします。

    1. メインブローカー CR broker_activemqartemis_cr.yaml を開きます。
    2. CR で、deploymentPlan.size を 1 に設定します。

    3. コマンドラインで変更を適用します。 

      $ oc apply -f deploy/crs/broker_activemqartemis_cr.yaml

      Pod ex-aao-ss-1 がシャットダウンを開始したことを確認します。縮小コントローラーは、同じ名前の新しいドレイン Pod を起動します。このドレイン Pod は、ブローカー Pod ex-aao-ss-1 からクラスター内の他のブローカー Pod にすべてのメッセージを移行した後にシャットダウンします (ex-aao-ss-0)。

  6. ドレイン Pod がシャットダウンされたら、ブローカー Pod ex-aao-ss-0 の TEST キューのメッセージ数を確認します。キューのメッセージ数が 2000 であることを確認できます。これは、ドレイン Pod がシャットダウンするブローカー Pod から 1000 個のメッセージを正常に移行しました。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.