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

2.7. シングルクラスターデプロイメントの概念

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

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

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

このセットアップを使用して、Red Hat build of Keycloak を OpenShift クラスターにデプロイします。

2.7.2. シングルまたは複数のアベイラビリティーゾーン
リンクのコピー

Red Hat build of Keycloak デプロイメントの動作と高可用性パフォーマンスは、最終的には OpenShift クラスターの設定によって決まります。通常、OpenShift クラスターはシングルのアベイラビリティーゾーンにデプロイされますが、フォールトトレランスを高めるために、複数のアベイラビリティーゾーンにまたがってクラスターをデプロイ することも可能です。

Red Hat build of Keycloak Operator は、可能な限り Red Hat build of Keycloak Pod を別々のノードおよびアベイラビリティーゾーンにデプロイするために、デフォルトで次のトポロジー分散制約を定義します。 

      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: "ScheduleAnyway"
          labelSelector:
            matchLabels:
              app: "keycloak"
              app.kubernetes.io/managed-by: "keycloak-operator"
              app.kubernetes.io/instance: "keycloak"
              app.kubernetes.io/component: "server"
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: "ScheduleAnyway"
          labelSelector:
            matchLabels:
              app: "keycloak"
              app.kubernetes.io/managed-by: "keycloak-operator"
              app.kubernetes.io/instance: "keycloak"
              app.kubernetes.io/component: "server"
Copy to Clipboard Toggle word wrap
重要

複数のアベイラビリティーゾーンを使用して高可用性を設定するには、データベースがゾーン障害にも耐えられることが重要です。これは、Red Hat build of Keycloak が、可用性を維持するために基盤となるデータベースに依存しているためです。

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

Red Hat build of Keycloak をシングルゾーン内のシングルクラスターにデプロイした場合、複数のアベイラビリティーゾーンまたがってデプロイした場合、または必要なネットワーク遅延とデータベース設定を持つデータセンターにデプロイした場合では、高可用性の特性が大きく変わります。したがって、これらのアーキテクチャーは個別に検討します。

2.7.3.1. シングルゾーン
リンクのコピー

高可用性の シングルクラスターデプロイメント のテスト中に、記述されたイベントについて以下の復旧時間を観測しました。

Expand
障害復元RPO1RT2

Red Hat build of Keycloak Pod

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

データ損失なし

30 秒未満

OpenShift ノード

クラスター内では複数の Red Hat build of Keycloak Pod が実行されます。ホストのノードが停止した場合、そのノード上のすべての Pod に障害が発生し、一部の受信リクエストがエラーメッセージを受信するか、数秒間遅延する可能性があります。

データ損失なし

30 秒未満

Red Hat build of Keycloak のクラスタリング接続

OpenShift ノード間の接続が失われた場合、それらのノード上でホストされている Red Hat build of Keycloak Pod 間でデータを送信できなくなります。受信リクエストがエラーメッセージを受信するか、数秒遅延する可能性があります。Red Hat build of Keycloak は最終的に、到達不可能な Pod をローカルビューから削除し、その Pod へのデータ送信を停止します。

データ損失なし

数秒から数分

表の脚注:

1 テスト済みの目標復旧時点。この事象が発生した時点でセットアップのすべての部分が健全であったと仮定した場合。
2 最大観測復旧時間。

2.7.3.2. 複数のゾーン
リンクのコピー

高可用性 マルチクラスターデプロイメント のテスト中に、記述されたイベントについて以下の復旧時間を観測しました。

Expand
障害復元RPO1RT2

データベースノード3

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

データ損失なし

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

Red Hat build of Keycloak Pod

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

データ損失なし

30 秒未満

OpenShift ノード

クラスター内では複数の Red Hat build of Keycloak Pod が実行されます。ホストのノードが停止した場合、そのノード上のすべての Pod に障害が発生し、一部の受信リクエストがエラーメッセージを受信するか、数秒間遅延する可能性があります。

データ損失なし

30 秒未満

アベイラビリティーゾーンの障害

アベイラビリティーゾーンに障害が発生すると、そのゾーンでホストされているすべての Red Hat build of Keycloak Pod にも障害が発生します。アベイラビリティーゾーンの数と同数以上の Red Hat build of Keycloak レプリカをデプロイしていれば、リクエストを処理できる他の Pod が存在するため、データが失われず、ダウンタイムが最小限に抑えられます。

データ損失なし

秒

接続性データベース

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

データ損失なし 3

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

Red Hat build of Keycloak のクラスタリング接続

OpenShift ノード間の接続が失われた場合、それらのノード上でホストされている Red Hat build of Keycloak Pod 間でデータを送信できなくなります。受信リクエストがエラーメッセージを受信するか、数秒遅延する可能性があります。Red Hat build of Keycloak は最終的に、到達不可能な Pod をローカルビューから削除し、その Pod へのデータ送信を停止します。

データ損失なし

数秒から数分

表の脚注:

1 テスト済みの目標復旧時点。この障害が発生した時点でセットアップのすべての部分が健全であると仮定した場合。
2 最大観測復旧時間。
3 データベースも複数のアベイラビリティーゾーンにまたがってレプリケートされていると仮定した場合。

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

  1. Red Hat build of Keycloak アップグレードのロールアウト中のダウンタイム

    この問題は、パッチリリースの場合、ローリング更新が可能かどうかを確認 する機能を有効にすることで解消できます。

  2. 複数のノード障害が発生した際に、ノード障害の件数が、キャッシュに設定された num_owners (デフォルトでは 2) 以上の場合、authenticationSessions、loginFailures、および actionTokens キャッシュからのエントリーが失われる可能性があります。

  3. whenUnsatisfiable: ScheduleAnyway が指定されたデフォルトの topologySpreadConstraints を使用するデプロイメントでは、障害が発生したノード/ゾーンに複数の Pod がスケジュールされている場合、ノード/アベイラビリティーゾーンの障害時にデータ損失が発生する可能性があります。

    ユーザーは、topologySpreadConstraints に whenUnsatisfiable: DoNotSchedule を定義して、常にゾーンおよびノード全体に Pod を均等にスケジュールさせることで、この状況を緩和できます。ただし、この制約を満たすことができない場合、一部の Red Hat build of Keycloak インスタンスがデプロイされない可能性があります。

    Infinispan はキャッシュエントリーを配布するときにネットワークトポロジーを認識しません。そのため、キャッシュされたデータの num_owner 個のコピーが、すべて障害が発生したノード/ゾーンに保存されている場合、ノード/アベイラビリティーゾーンの障害時にデータ損失が発生する可能性があります。ノードおよびアベイラビリティーゾーンに対して requiredDuringSchedulingIgnoredDuringExecution を定義することで、利用可能なノードまたはゾーンの数に応じて、Red Hat build of Keycloak インスタンスの合計数を制限できます。ただし、プロビジョニングできる Red Hat build of Keycloak インスタンスの数が、OpenShift クラスター内のノード/アベイラビリティーゾーンの数に制限されるため、スケーラビリティーが犠牲になります。

    カスタムのアンチアフィニティー topologySpreadConstraints ポリシーを設定する方法は、Operator の 高度な設定 の詳細を参照してください。

  4. Operator は Pod 内でサイトの名前 (分散キャッシュの設定 を参照) を設定しません。サイトの名前は、Downward API 経由では取得できないためです。マシン名オプションは、Pod がスケジュールされるノードの spec.nodeName を使用して設定されます。

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

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat