第2章 OpenShift Container Platform での AMQ Broker のデプロイメントのプランニング
このセクションでは、Operator ベースのデプロイメントを計画する方法について説明します。
Operator は、OpenShift アプリケーションのパッケージ化、デプロイ、および管理を可能にするプログラムです。多くの場合、Operator は共通タスクまたは複雑なタスクを自動化します。通常、Operator は以下を提供することを目的としています。
- 一貫性のある繰り返し可能なインストール
- システムコンポーネントのヘルスチェック
- OTA (Over-the-air) 更新
- 管理アップグレード
Operator は、デプロイメントの設定に使用したカスタムリソース (CR) インスタンスへの変更を常にリッスンしているため、ブローカーインスタンスの実行中に変更を加えることができます。CR に変更を加えると、Operator は既存のブローカーデプロイメントの変更を調整し、変更を反映するためにデプロイメントを更新します。さらに、Operator は、メッセージングデータの整合性を維持するメッセージ移行機能を提供します。クラスター化されたデプロイメント内のブローカーが、デプロイメントの意図的なスケールダウンによりシャットダウンした場合、この機能により、同じブローカークラスター内でまだ実行されているブローカー Pod にメッセージが移行されます。
2.1. 高可用性 (HA) の概要
高可用性という用語は、そのシステムの一部に障害が発生したりシャットダウンしている場合でも、稼働を継続できるシステムを指します。OpenShift Container Platform 上の AMQ Broker の場合、これは、ブローカー Pod、Pod が実行されているノード、またはクラスターに障害が発生した場合に、メッセージングデータのインテグリティーと可用性を確保することを意味します。
AMQ Broker は、OpenShift Container Platform で提供される HA 機能を使用して、Pod およびノードの失敗を軽減します。
- AMQ Broker で永続ストレージが有効になっている場合、各ブローカー Pod は、永続ボリューム要求 (PVC) を使用して要求した永続ボリューム (PV) にデータを書き込みます。Pod が削除された後でも PV は引き続き利用可能です。ブローカー Pod に障害が発生した場合、OpenShift は同じ名前で Pod を再起動し、メッセージングデータを含む既存の PV を使用します。
クラスター内で複数のブローカー Pod を実行し、ノード障害から回復するために Pod を別々のノードに分散できます。各ブローカー Pod はメッセージデータを独自の PV に書き込みます。このメッセージデータは、ブローカー Pod が別のノードで再起動された場合に、そのブローカー Pod で使用できます。
OpenShift クラスターのノード障害から回復するための平均修復時間 (MTTR) が AMQ Broker のサービス可用性要件を満たさない場合は、より迅速な修復を実現するためにリーダー/フォロワーデプロイメントを作成できます。リーダー/フォロワーデプロイメントは、クラスターまたはより広範なデータセンターの障害から保護するために使用することもできます。詳細は、「高可用性のためのリーダー/フォロワーブローカーデプロイメントの設定」 を参照してください。
関連情報
永続ストレージの使用方法については、「Operator デプロイメントノート」 を参照してください。
ブローカー Pod を別々のノードに分散する方法については、「容認を使用した Pod の配置の制御」 を参照してください。
