4.6.2. メッセージの移行
デプロイメントの失敗や意図的なスケールダウンによってクラスターデプロイメントのブローカーがシャットダウンする場合に、メッセージの移行はメッセージングデータの整合性を確保することです。このプロセスは、Pod のドレインとしても、シャットダウンしたブローカー Pod からのメッセージの削除および再分配を指します。
- メッセージの移行は、AMQ Broker Operator に基づくデプロイメントでのみ利用できます。アプリケーションテンプレートをベースとするデプロイメントは、メッセージの移行機能はありません。
- メッセージ移行を実行するスケールダウンコントローラーは、単一の OpenShift プロジェクト内でのみ動作します。コントローラーは、別のプロジェクトのブローカー間でメッセージを移行できません。
- メッセージの移行を使用するには、デプロイメントに 2 つ以上のブローカーが必要です。デフォルトでは 2 つ以上のブローカーを持つブローカーはクラスター化されます。
Operator ベースのブローカーのデプロイメントでは、デプロイメントのメインブローカーカスタムリソースで messageMigration を true に設定して、メッセージの移行を有効にします。
メッセージ移行プロセスは、次の手順を実行します。
- デプロイメントのブローカー Pod がデプロイメントの失敗または意図的にスケールダウンによってシャットダウンすると、Operator はスケールダウンコントローラーを自動的に起動してメッセージ移行の準備を行います。縮小コントローラーは、ブローカークラスターと同じ OpenShift プロジェクト名で実行されます。
- 縮小コントローラーは、それ自体を登録し、プロジェクトの Persistent Volume Claim (永続ボリューム要求、PVC) に関連する Kubernetes イベントをリッスンします。
孤立した永続ボリューム (PV) の有無を確認するには、縮小コントローラーはボリューム要求上の序数を探します。コントローラーは、ボリューム要求の序数を、プロジェクトの StatefulSet (ブローカークラスター) で実行されているブローカー Pod と比較します。
ボリューム要求の序数がブローカー Pod の序数よりも高くなる場合、スケールダウンコントローラーは、その序数のブローカー Pod がシャットダウンされ、メッセージングデータが別のブローカー Pod に移行する必要があるかどうかを判断します。
縮小コントローラーはドレイン Pod を起動します。ドレイン Pod はブローカーを実行し、メッセージ移行を実行します。次に、ドレイン Pod は孤立したメッセージを移行する代替ブローカー Pod を識別します。
注記メッセージの移行を可能にするには、少なくとも 1 つ以上のブローカー Pod がデプロイメントで実行されている必要があります。
以下の図は、スケールダウンコントローラー (ドレインコントローラーとしても知られる) がメッセージを稼働中のブローカー Pod に移行する方法を示しています。
メッセージを運用ブローカー Pod に正常に移行した後、ドレイン Pod はシャットダウンし、スケールダウンコントローラーは孤立した PV の PVC を削除します。PV は Released の状態に戻ります。
ブローカーデプロイメントを 0 (ゼロ) にスケールダウンする場合、メッセージングデータを移行できる稼働中のブローカー Pod がないため、メッセージ移行は行われません。ただし、デプロイメントをゼロにスケールダウンしてから、元のデプロイメントよりも小さいサイズに再び戻すと、シャットダウンされたブローカーについてのドレイン Pod が起動します。
関連情報
- ブローカーのデプロイメントをスケールダウンする際のメッセージ移行の例については、縮小後のメッセージの移行 を参照してください。
