16.3. 高可用性の実装
ブローカークラスターの作成後に、高可用性 (HA) を実装してその信頼性を強化できます。HA では、1 つ以上のブローカーがオフラインになっても、ブローカークラスターは機能し続けます。
HA の実装には、複数のステップが関係します。
- ライブバックアップグループの概要を理解し、要件に最も適した HA ポリシーを選択する必要があります。Understanding how HA works in AMQ Broker を参照してください。
適切な HA ポリシーを選択したら、クラスター内の各ブローカーに HA ポリシーを設定します。以下を参照してください。
- フェイルオーバーを使用するようにクライアントアプリケーションを設定します。
高可用性用に設定されたブローカークラスターをトラブルシューティングする必要がある場合は、クラスターでブローカーを実行している各 Java Virtual Machine (JVM) インスタンスにガベージコレクション (GC) ロギングを有効にすることが推奨されます。JVM で GC ログを有効にする方法については、JVM で使用される Java Development Kit (JDK) バージョンの公式ドキュメントを参照してください。AMQ Broker がサポートする JVM バージョンの詳細は、Red Hat AMQ 7 Supported Configurations を参照してください。
16.3.1. High Availability Deployment and Usage
AMQ Broker では、クラスターでブローカーを ライブバックアップグループ にグループ化して、高可用性 (HA) を実装します。ライブバックアップグループでは、ライブブローカーはバックアップブローカーにリンクされ、失敗した場合はライブブローカーを引き継ぐことができます。AMQ Broker は、ライブバックアップグループ内のフェイルオーバー ( HA ポリシー と呼ばれる ) にいくつかの異なるストラテジーも提供します。
16.3.1.1. ライブバックアップグループがどのように高可用性を提供するか
AMQ Broker では、クラスターにブローカーをリンクして高可用性 (HA) を実装し、ライブバックアップグループ を形成します。ライブバックアップグループは フェイルオーバー を提供します。つまり、1 つのブローカーが失敗すると、別のブローカーがメッセージ処理を引き継ぐことができます。
ライブバックアップグループは、1 つ以上のバックアップブローカー ( スレーブ ブローカーとも呼ばれる ) にリンクされた 1 つのライブブローカー ( マスター ブローカーとも呼ばれる ) で設定されます。ライブブローカーはクライアント要求に対応し、バックアップブローカーはパッシブモードで待機します。ライブブローカーが失敗すると、バックアップブローカーはライブブローカーに置き換わり、クライアントが再接続し、作業を続行します。
16.3.1.2. 高可用性ポリシー
高可用性 ( HA ) ポリシーは、ライブバックアップグループでのフェイルオーバーの発生方法を定義します。AMQ Broker では、複数の HA ポリシーが提供されます。
- 共有ストア ( 推奨 )
ライブおよびバックアップブローカーは、メッセージングデータを共有ファイルシステム上の共通ディレクトリー ( 通常は Storage Area Network (SAN) または Network File System (NFS) サーバー ) に保存します。また、JDBC ベースの永続を設定している場合は、ブローカーデータを指定されたデータベースに保存することもできます。共有ストアでは、ライブブローカーが失敗すると、バックアップブローカーは共有ストアからメッセージデータを読み込み、失敗したライブブローカーに対して引き継ぎします。
ほとんどの場合、レプリケーションの代わりに共有ストアを使用する必要があります。共有ストアはネットワーク経由でデータを複製しないため、通常はレプリケーションよりもパフォーマンスが向上します。共有ストアは、ライブブローカーとそのバックアップが同時に行われるという問題である、ネットワーク分離 (スプリットブレインとも呼ばれる) を回避します。
- レプリケーション
ライブおよびバックアップブローカーは、そのメッセージングデータをネットワーク経由で継続的に同期します。ライブブローカーが失敗すると、バックアップブローカーは同期データを読み込み、失敗したライブブローカーに対して引き継ぎます。
ライブブローカーとバックアップブローカー間のデータ同期により、ライブブローカーが失敗してもメッセージングデータが失われないようにします。ライブブローカーおよびバックアップブローカーが最初に結合すると、ライブブローカーはネットワーク経由ですべての既存データをバックアップブローカーに複製します。この最初のフェーズが完了すると、ライブブローカーは永続データを、ライブブローカーが受信時にバックアップブローカーに複製します。つまり、ライブブローカーがネットワークから切断されると、バックアップブローカーには、ライブブローカーが受信したすべての永続データが含まれます。
レプリケーションはネットワーク経由でデータを同期するため、ネットワーク障害により、ライブブローカーとそのバックアップが同時に存続するネットワーク分離が発生する可能性があります。
- ライブのみ ( 限定 HA)
ライブブローカーが正常に停止されると、メッセージとトランザクションの状態を別のライブブローカーにコピーし、シャットダウンします。その後、クライアントは他のブローカーに再接続し、メッセージの送受信を続行します。
関連情報
- ライブバックアップグループ内のブローカー間で共有される永続メッセージデータの詳細については、次を参照してください。「ジャーナルベースの永続性」 .
16.3.1.3. レプリケーションポリシーの制限
ネットワーク分離 ( スプリットブレインと呼ばれることもあります ) は、レプリケーションの高可用性 (HA) ポリシーの制限です。その発生方法、およびその回避方法を理解している必要があります。
ライブブローカーとそのバックアップが接続を失うと、ネットワーク分離が発生する可能性があります。この場合、ライブブローカーとそのバックアップの両方を同時にアクティブにすることができます。具体的には、バックアップブローカーがクラスター内のライブブローカーの半分以上に接続できる場合は、アクティブになります。この状況では、ブローカー間でメッセージレプリケーションがないため、各ブローカーはクライアントとプロセスメッセージに、他のメッセージを認識せずに提供します。この場合、各ブローカーは完全に異なるジャーナルを持ちます。この状況からの復元は非常に困難であり、場合によっては不可能です。
ネットワーク分離を回避するには、以下の点を考慮してください。
- ネットワーク分離の可能性を なくす には、共有ストア HA ポリシーを使用します。
レプリケーション HA ポリシーを使用する場合は、少なくとも 3 つのライブ / バックアップのペア を使用することで、ネットワーク分離が発生する可能性を軽減 ( ただし除外しない ) できます。
少なくとも 3 つのライブ / バックアップのペアを使用することで、ライブ / バックアップブローカーのペアでレプリケーションが中断された場合に発生する クォーラム票 で過半数の結果を得ることができます。
レプリケーション HA ポリシーを使用する場合の追加に関する考慮事項は以下のとおりです。
- ライブブローカーが失敗し、バックアップがライブに移行すると、新しいバックアップブローカーがライブに割り当てられるまで、または元のライブブローカーへのフェイルバックが発生するまでレプリケーションは行われません。
- ライブバックアップグループでバックアップブローカーが失敗すると、ライブブローカーはメッセージを提供します。ただし、メッセージは別のブローカーがバックアップとして追加されるか、または元のバックアップブローカーが再起動されるまで複製されません。この間、メッセージはライブブローカーにのみ永続化されます。
- ライブバックアップペアの両方のブローカーが以前にシャットダウンしたが、再起動できるようになったとします。この場合、メッセージが失われないようにするには、最初にアクティブなブローカーを再起動する必要があります。最近アクティブなブローカーがバックアップブローカーであった場合は、このブローカーをマスターブローカーとして手動で再設定し、最初に再起動できるようにする必要があります。
