PUBLIC_IP_ADDRESSクラスター・ノードを接続する必要があります。このようなものは、NODE11とNODE12のどちらのログにも残っていなければなりません。node12]ログにあるチャネル名とは異なっている可能性があります。使用してクラスターに接続するのではなく、クラスターを分離する必要があります。クラスター化する必要があります。node22]ログにあるチャネル名とは異なっている可能性があります。次のように、テストを行ってください。移動し、最初の管理者ユーザーを作成します。移動し、管理者として管理コンソールにログインします。いずれかのノードに移動します。タブで同じセッションを表示できます。Keycloakの管理コンソールで変更(たとえば、ユーザーやレルムの更新など)を加えた後、その変更は、すぐに4つのノードのいずれかで表示され、キャッシュがどこでも適切に無効化される必要があります。必要に応じてserver.logsを確認してください。ノードに表示される必要があります。'false'クロスサイト・デプロイメントの管理このセクションでは、クロスサイト・レプリケーションに関連するヒントやオプションをご紹介します。データソース内で参照されたデータベースがすでに実行され、そのデータセンター内で使用可能である必要があります。よって参照されたInfinispanサーバーがすでに実行されてることが必要です。しないと、Keycloakサーバーは起動に失敗します。データベース・フェイルオーバーと高い信頼性をサポートする必要がある場合、すべてのデータセンターでより多くのデータベース・ノードを持たせます。データソースで必要な設定方法の詳細については、JDBCドライバーのドキュメントを参照してください。すべてのデータセンターで、より多くのInfinispanサーバーをクラスター内で実行することができます。これは、フェイルオーバーとフォールト・トレランスを強化する場合に便利です。Rodプロトコルには、InfinispanサーバーがInfinispanクラスターの変更について、Keycloakサーバーに新しいトポロジーを自動的に送信する機能を備えています。したがって、Keycloak側のリモートストアは、どのInfinispanサーバーに接続できるのかが分かります。詳細については、InfinispanとWildFlyドキュメントを参照してください。サイトのKeycloakサーバーも起動する前に、すべてのサイトでマスターInfinispanサーバーを実行することを強くお勧めします。両方を最初に起動します。Keycloakサーバーをそれでも実行する必要があり、バックアップ・サイトがオフラインである場合は、サイトをオフラインおよびオンラインにするでの説明のとおり、サイトのInfinispanサーバー上のバックアップ・サイトを手動でオフラインに切り替えることをお勧めします。使用できない状態のサイトをオフラインに手動で切り替えることができない場合、初回起動に失敗するか、起動時にいくつか例外が発生する可能性があります。これは、失敗した操作の設定数によってバックアップ・サイトが自動的にオフラインになるまでです。サイトをオフラインおよびオンラインにするたとえば、以下のようなシナリオを想定します。完全にオフラインです。間のネットワークが切断されていることを意味します。Keycloakサーバーにログインします。サーバー上のリモート・キャッシュにセッションを書き込もうとします。詳細については、コミュニケーションの詳細を参照してください。バックアップは失敗します。ログにスローされます。サーバーからKeycloakサーバーにも伝播されます。バックアップ・ポリシーの詳細については、バックアップ失敗ポリシーを参照してください。このエラーはKeycloak側でも発生し、ユーザーはログインを完了できない可能性もあります。使用している環境に応じて、サイト間のネットワークが利用できないか、一時的に壊れている(スプリット・ブレイン)可能性があります。サイトのサーバーへアクセスしようとするのを止めるため、バックアップの失敗は発生しません。サイトをオフラインにするサイトをオフラインにするには2つの方法があります。他のツールを使用して、いくつかのJMX操作を実行することで、手動で特定のサイトをオフラインにすることができます。これは、特に停止が計画されている場合に役立ちます。オフラインにすることができます。SYNCまたはASYNCバックアップで述べた他のすべてのKeycloakキャッシュについても、通常はこれらの手順を実行する必要があります。自動的にオフラインになります。要素の設定によって行われます。/>この例では、少なくとも3回連続して失敗したバックアップがあり、60秒以内にバックアップが成功しなかった場合、特定のシングルキャッシュに対してサイトが自動的にオフラインになることを示しています。自動的にサイトをオフラインにすることは、特に、サイト間の切断されたネットワークが計画外である場合に便利です。欠点は、ネットワークの停止が検出されるまで何らかのバックアップが失敗し、アプリケーション側で障害が起きてる可能性があります。一部のユーザーのログインに失敗したり、大きなログインタイムアウトが発生したりします。使用されている場合です。サイトがオフラインであるかどうかの追跡は、キャッシュごとに個別に行われます。お互いに通信することができたら、サイトをオンラインにする必要があります。これは、サイトをオフラインにするのと同じように、JMXまたはCLIを使用して手動で行う必要があります。再度キャッシュをすべてチェックし、オンラインにする必要があります。サイトをオンラインにしたら、通常は次のようにするのが良いです。ステート・トランスファーを行います。手動でキャッシュのクリアを行います。ステート・トランスファーステート・トランスファーは、手動で行う必要があります。Infinispanサーバーはこれを自動的には行いません。スプリット・ブレイン中は、誰がどのサイトを優先するかを管理者のみが決定することができます。単方向は行われません。発生していないので問題ありません。存在し、両方のサイトのスプリット・ブレイン中に更新されたエンティティーです。2番目のサイトがスプリット・ブレイン中に行った更新を上書きします。残念ながら、これに対する広く一般的な解決方法はありません。スプリット・ブレインやネットワークの停止は状態に過ぎず、サイト間で100%の一貫性のあるデータで100%正確に処理することは通常不可能です。Keycloakの場合、これは特に重大な問題ではありません。最悪の場合、ユーザーがクライアントに再度ログインするか、loginFailuresの不正カウント数をブルートフォース保護のために追跡する必要があります。スプリット・ブレインに対処するためのヒントについては、Infinispan/JGroupsドキュメントを参照してください。ステート・トランスファーは、JMXを介してInfinispanサーバー側でも行われます。状態をモニタリングしたり、プッシュ状態をキャンセルしたりするその他の操作はほとんどありません。キャッシュのクリアスプリット・ブレイン後は、Keycloakの管理コンソールで手動でキャッシュをクリアするのが安全です。転送されなかった可能性があるためです。Keycloakノードでは、キャッシュ内に古いデータがまだ残っている可能性があります。ネットワークが復旧したら、いずれかのサイトの1つのKeycloakノードでキャッシュをクリアするだけで十分です。キャッシュの無効化イベントは、それぞれのサイトの他のKeycloakノードすべてに送られます。すべてのキャッシュ(レルム、ユーザー、鍵)に対して実行する必要があります。Cachesを参照してください。Infinispanキャッシュ設定のチューニングこのセクションでは、JDGキャッシュを設定するためのヒントとオプションについて説明します。