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

3.7. マルチクラスターデプロイメントの概念

同期レプリケーションを使用したマルチクラスターのデプロイメントを説明します。

このトピックでは、高可用性マルチクラスターセットアップと想定される動作を説明します。高可用性アーキテクチャーの要件を概説し、その利点と欠点を説明します。

3.7.1. このセットアップを使用すべき状況
リンクのコピー

このセットアップは、OpenShift クラスターの障害に耐え、ダウンタイムが発生する確率を減らすことができる Red Hat build of Keycloak デプロイメントを提供するために使用できます。

3.7.2. デプロイメント、データストレージ、キャッシュ
リンクのコピー

異なるサイトで実行されている 2 つの独立した Red Hat build of Keycloak デプロイメントを、低遅延のネットワーク接続で接続します。ユーザー、レルム、クライアント、セッション、およびその他のエンティティーを、2 つのサイト間で同期的にレプリケートされるデータベースに保存します。データは、ローカルキャッシュとして Red Hat build of Keycloak Infinispan キャッシュにもキャッシュされます。一方の Red Hat build of Keycloak インスタンスでデータが変更されると、そのデータがデータベース内で更新され、work キャッシュを使用して無効化メッセージが他方のサイトに送信されます。

以下の段落と図における Data Grid のデプロイへの言及は、外部 Data Grid を対象としています。

3.7.3. データとサービスの損失の原因
リンクのコピー

このセットアップは高可用性の実現を目的としたものですが、それでも次の状況ではサービスまたはデータの損失が発生する可能性があります。

  • Red Hat build of Keycloak サイト障害により、障害の発生からロードバランサーによる検出までの間に、障害が発生したサイトにリクエストがルーティングされてリクエストが失敗する可能性があります。
  • サイト間の通信で障害が発生した場合、機能が低下したセットアップを再同期するために手動の手順が必要になります。
  • セットアップの機能が低下すると、別のコンポーネントにさらに障害が発生した場合にサービスまたはデータの損失が発生する可能性があります。セットアップの機能低下を検出するには監視が必要です。

3.7.4. このセットアップが耐えられる障害
リンクのコピー

Expand
障害復元RPO1RT2

データベースノード

ライターインスタンスに障害が発生した場合、データベースは同じサイトまたは別のサイトのリーダーインスタンスを新しいライターにプロモートすることができます。

データ損失なし

数秒から数分 (データベースによって異なる)

Red Hat build of Keycloak ノード

複数の Red Hat build of Keycloak インスタンスが各サイトで実行されます。1 つのインスタンスが失敗すると、一部の受信リクエストがエラーメッセージを受信するか、数秒間遅延する可能性があります。

データ損失なし

30 秒未満

Data Grid ノード

複数の Data Grid インスタンスが各サイトで実行されます。1 つのインスタンスに障害が発生した場合、他のノードが変化を認識するまでに数秒かかります。エンティティーが少なくとも 2 つの Data Grid ノードに保存されるため、1 つのノードの障害によってデータが失われることはありません。

データ損失なし

30 秒未満

Data Grid クラスターの障害

いずれかのサイトで Data Grid クラスターに障害が発生すると、Red Hat build of Keycloak はそのサイト上の外部 Data Grid と通信できなくなり、Red Hat build of Keycloak サービスが使用できなくなります。/lb-check がエラーを返すと、ロードバランサーが状況を検出し、すべてのトラフィックを他のサイトに転送します。

Data Grid クラスターが復元され、データが再同期されるまで、セットアップの機能が低下します。

データ損失なし 3

数秒から数分 (ロードバランサーの設定によって異なる)

接続性 Data Grid

2 つのサイト間の接続が失われると、データを他のサイトに送信できなくなります。受信リクエストがエラーメッセージを受信するか、数秒遅延する場合があります。Data Grid は他のサイトをオフラインとしてマークし、データの送信を停止します。接続が復元され、2 つのサイト間でデータが再同期されるまで、ロードバランサー内でいずれかのサイトをオフラインにする必要があります。ブループリントでは、これの自動化方法を示しています。

データ損失なし 3

数秒から数分 (ロードバランサーの設定によって異なる)

接続性データベース

2 つのサイト間の接続が失われると、同期レプリケーションは失敗します。一部のリクエストがエラーメッセージを受信するか、数秒遅延する場合があります。データベースによっては手動操作が必要な場合があります。

データ損失なし 3

数秒から数分 (データベースによって異なる)

サイトの障害

Red Hat build of Keycloak ノードが利用できない場合、ロードバランサーは停止を検出し、トラフィックを別のサイトにリダイレクトします。ロードバランサーが障害を検出するまで、一部のリクエストがエラーメッセージを受信する可能性があります。

データ損失なし 3

2 分未満

表の脚注:

1 テスト済みの目標復旧時点。この障害が発生した時点でセットアップのすべての部分が健全であると仮定した場合。
2 最大観測復旧時間。
3 機能が低下したセットアップを復元するには手動操作が必要。

“データ損失なし” は、以前の障害によってセットアップの機能が低下していないことを条件としています。これには、サイト間の状態を再同期する保留中の手動操作が完了していることも含まれます。

3.7.5. 既知の制限
リンクのコピー

サイトの障害
フェイルオーバーを正常に実行するには、以前の障害によってセットアップの機能が低下していない必要があります。データ損失を防ぐために、前回の障害後の再同期などの手動操作をすべて完了する必要があります。モニタリングを使用して、機能低下をタイムリーに検出して処理してください。
同期していないサイト
Data Grid 同期リクエストが失敗すると、サイトの同期が取れなくなることがあります。この状況を監視することは現時点では困難であり、回復するには Data Grid をすべて手動で再同期する必要があります。両方のサイトのキャッシュエントリーの数と Red Hat build of Keycloak ログファイルを監視すると、再同期が必要なタイミングを把握できます。
手動操作
サイト間で Data Grid の状態を再同期する手動操作を行うと、完全な状態の転送が実行され、システムに負荷がかかります。
2 サイト制限
このセットアップは 2 サイトの場合のみテストおよびサポートされています。サイトを追加すると、サイトごとにデータを同期的に書き込む必要があるため、サイトを追加するたびに全体的な遅延が増加します。さらに、ネットワーク障害の可能性が増加し、結果的にダウンタイムも増加します。そのため、3 つ以上のサイトではデプロイメントの安定性とパフォーマンスの低下につながると考え、サポート対象外としています。

3.7.6. 質問と回答
リンクのコピー

データベース同期レプリケーションを使用するのはなぜですか?
データベースを同期的にレプリケートすると、サイトに障害が発生しても、一方のサイトに書き込まれたデータをもう一方のサイトで使用でき、データを失うことはありません。また、どのサイトにデータが提供されるかにかかわらず、次のリクエストで古いデータが返されることもありません。
Data Grid 同期レプリケーションを使用するのはなぜですか?
Data Grid を同期的にレプリケートすると、サイト障害が発生しても、一方のサイトでキャッシュされたデータをもう一方のサイトで使用できるため、データを失うことはありません。また、どのサイトにデータが提供されるかにかかわらず、次のリクエストで古いデータが返されることもありません。
サイト間に低遅延ネットワークが必要なのはなぜですか?
同期レプリケーションでは、もう一方のサイトでデータが受信されるまで、呼び出し元へのレスポンスを延期します。データベース同期レプリケーションと Data Grid 同期レプリケーションでは、データの更新時に各リクエストでサイト間のやり取りが複数回発生し、遅延が増大する可能性があるため、低遅延が必要です。
同期クラスターは非同期クラスターよりも安定性に劣りますか?

非同期セットアップでは、サイト間のネットワーク障害がグレースフルに処理されます。一方、同期セットアップでは、非同期セットアップなら別のサイトの Data Grid またはデータベースへの書き込みが延期されるような状況でも、リクエストが遅延し、呼び出し元に対してエラーが出力されます。ただし、2 つのサイトが完全に最新の状態になることはないため、このセットアップでは障害発生時にデータが失われる可能性があります。データ損失には次のものが含まれます。

  • 非同期データベースを使用した場合、データベースの変更が障害発生時にもう一方のサイトにレプリケートされないため、変更が失われ、ユーザーが古いパスワードでログインできます。
  • Data Grid 非同期レプリケーションを使用した場合、無効化されたキャッシュは障害発生時にもう一方のサイトに伝播されないため、無効なキャッシュが原因でユーザーが古いパスワードでログインできます。

したがって、高可用性と整合性の間にはトレードオフが存在します。このトピックの焦点は、Red Hat build of Keycloak の可用性よりも整合性を優先することです。

3.7.7. 次のステップ
リンクのコピー

各構成要素のブループリントを確認するには、続けて マルチクラスターデプロイメントの構成要素 の章を参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat