第2章 OpenShift Container Platform での AMQ Broker のデプロイメントのプランニング

このセクションでは、Operator ベースのデプロイメントを計画する方法について説明します。

Operator は、OpenShift アプリケーションのパッケージ化、デプロイ、および管理を可能にするプログラムです。多くの場合、Operator は共通タスクまたは複雑なタスクを自動化します。通常、Operator は以下を提供することを目的としています。

Operator は、デプロイメントの設定に使用したカスタムリソース (CR) インスタンスへの変更を常にリッスンしているため、ブローカーインスタンスの実行中に変更を加えることができます。CR に変更を加えると、Operator は既存のブローカーデプロイメントの変更を調整し、変更を反映するためにデプロイメントを更新します。さらに、Operator は、メッセージングデータの整合性を維持するメッセージ移行機能を提供します。クラスター化されたデプロイメント内のブローカーが、デプロイメントの意図的なスケールダウンによりシャットダウンした場合、この機能により、同じブローカークラスター内でまだ実行されているブローカー Pod にメッセージが移行されます。

2.1. 高可用性 (HA) の概要

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

AMQ Broker は、OpenShift Container Platform で提供される HA 機能を使用して、Pod の失敗を軽減します。

• AMQ Broker で永続ストレージが有効になっている場合、各ブローカー Pod は、永続ボリューム要求 (PVC) を使用して要求した永続ボリューム (PV) にデータを書き込みます。Pod が削除された後でも PV は引き続き利用可能です。ブローカー Pod が失敗した場合、OpenShift Container Platform は同じ名前で Pod を再起動し、メッセージングデータを含む既存の PV を使用します。
• クラスター内で複数のブローカー Pod を実行し、ノードの障害から保護するために Pod を別個のノードに分散することができます。クラスターでは、各ブローカー Pod はメッセージデータを独自の PV に書き込みます。メッセージデータは、ブローカー Pod が別のノードで再起動された場合に、当該ブローカー Pod で使用できます。

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

関連情報

永続ストレージの使用方法については、「Operator デプロイメントノート」 を参照してください。

ブローカー Pod を別個のノードに分散する方法については、「容認を使用した Pod の配置の制御」 を参照してください。