12.2. 手順
12.2.1. Data Grid クラスター
この章の文脈では、Site-A は動作状態に回復しているプライマリーサイトであり、Site-B は実稼働環境で実行されているセカンダリーサイトです。
プライマリーサイトの Data Grid がオンラインに戻り、クロスサイトチャネルに参加したら (Data Grid デプロイメントを検証する方法については、Data Grid Operator を使用した HA 用の Data Grid のデプロイ#verifying-the-deployment を参照)、セカンダリーサイトから状態転送を手動で開始する必要があります。
プライマリーサイトの状態をクリアした後、セカンダリーサイトからプライマリーサイトへの完全な状態の遷移を実行します。プライマリーサイトが受信リクエストの処理を開始するには、この遷移が完了している必要があります。
完全な状態の遷移を実行すると、応答時間やリソースの使用量が増加し、Data Grid クラスターのパフォーマンスに影響を与える可能性があります。
最初の手順は、プライマリーサイトから古いデータを削除することです。
- プライマリーサイトにログインします。
Red Hat build of Keycloak をシャットダウンします。この操作により、Red Hat build of Keycloak のキャッシュをすべてクリアし、Red Hat build of Keycloak の状態と Data Grid との同期ずれを防ぎます。
Red Hat build of Keycloak Operator を使用して Red Hat build of Keycloak をデプロイした場合、Red Hat build of Keycloak カスタムリソース内の Red Hat build of Keycloak インスタンスの数を 0 に変更します。
Data Grid CLI ツールを使用して Data Grid クラスターに接続します。
コマンド:
oc -n keycloak exec -it pods/infinispan-0 -- ./bin/cli.sh --trustall --connect https://127.0.0.1:11222
Data Grid クラスターのユーザー名とパスワードが要求されます。これらの認証情報は、Data Grid Operator を使用した HA 用の Data Grid のデプロイ の章にある認証情報の設定セクションで設定したものです。
出力:
Username: developer Password: [infinispan-0-29897@ISPN//containers/default]>
注記Pod 名は、Data Grid CR で定義したクラスター名によって異なります。接続は、Data Grid クラスター内の任意の Pod で行うことができます。
次のコマンドを実行して、プライマリーサイトからセカンダリーサイトへのレプリケーションを無効にします。これにより、クリアリクエストがセカンダリーサイトに到達してキャッシュされた正しいデータがすべて削除されるのを防ぎます。
コマンド:
site take-offline --all-caches --site=site-b
出力:
{ "offlineClientSessions" : "ok", "authenticationSessions" : "ok", "sessions" : "ok", "clientSessions" : "ok", "work" : "ok", "offlineSessions" : "ok", "loginFailures" : "ok", "actionTokens" : "ok" }レプリケーションのステータスが
offlineであることを確認します。コマンド:
site status --all-caches --site=site-b
出力:
{ "status" : "offline" }ステータスが
offlineでない場合は、前のステップを繰り返します。警告レプリケーションが
offlineあることを確認してください。そうでない場合、クリアデータによって両方のサイトがクリアされます。次のコマンドを使用して、プライマリーサイトのキャッシュデータをすべてクリアします。
コマンド:
clearcache actionTokens clearcache authenticationSessions clearcache clientSessions clearcache loginFailures clearcache offlineClientSessions clearcache offlineSessions clearcache sessions clearcache work
これらのコマンドは何も出力しません。
プライマリーサイトからセカンダリーサイトへのクロスサイトレプリケーションを再度有効にします。
コマンド:
site bring-online --all-caches --site=site-b
出力:
{ "offlineClientSessions" : "ok", "authenticationSessions" : "ok", "sessions" : "ok", "clientSessions" : "ok", "work" : "ok", "offlineSessions" : "ok", "loginFailures" : "ok", "actionTokens" : "ok" }レプリケーションのステータスが
onlineであることを確認します。コマンド:
site status --all-caches --site=site-b
出力:
{ "status" : "online" }
これで、セカンダリーサイトからプライマリーサイトに状態を転送する準備が整いました。
- セカンダリーサイトにログインします。
Data Grid CLI ツールを使用して Data Grid クラスターに接続します。
コマンド:
oc -n keycloak exec -it pods/infinispan-0 -- ./bin/cli.sh --trustall --connect https://127.0.0.1:11222
Data Grid クラスターのユーザー名とパスワードが要求されます。これらの認証情報は、Data Grid Operator を使用した HA 用の Data Grid のデプロイ の章にある認証情報の設定セクションで設定したものです。
出力:
Username: developer Password: [infinispan-0-29897@ISPN//containers/default]>
注記Pod 名は、Data Grid CR で定義したクラスター名によって異なります。接続は、Data Grid クラスター内の任意の Pod で行うことができます。
セカンダリーサイトからプライマリーサイトへの状態転送をトリガーします。
コマンド:
site push-site-state --all-caches --site=site-a
出力:
{ "offlineClientSessions" : "ok", "authenticationSessions" : "ok", "sessions" : "ok", "clientSessions" : "ok", "work" : "ok", "offlineSessions" : "ok", "loginFailures" : "ok", "actionTokens" : "ok" }すべてのキャッシュのレプリケーションステータスが
onlineであることを確認します。コマンド:
site status --all-caches --site=site-a
出力:
{ "status" : "online" }すべてのキャッシュに対する
push-site-statusコマンドの出力を確認して、状態転送が完了するまで待ちます。コマンド:
site push-site-status --cache=actionTokens site push-site-status --cache=authenticationSessions site push-site-status --cache=clientSessions site push-site-status --cache=loginFailures site push-site-status --cache=offlineClientSessions site push-site-status --cache=offlineSessions site push-site-status --cache=sessions site push-site-status --cache=work
出力:
{ "site-a" : "OK" } { "site-a" : "OK" } { "site-a" : "OK" } { "site-a" : "OK" } { "site-a" : "OK" } { "site-a" : "OK" } { "site-a" : "OK" } { "site-a" : "OK" }考えられるステータス値は、クロスサイトのドキュメントにあるこちらのセクション の表を参照してください。
エラーが報告された場合は、その特定のキャッシュに対して状態転送を再度実行します。
コマンド:
site push-site-state --cache=<cache-name> --site=site-a
以下のコマンドで状態転送ステータスをクリア/リセットします。
コマンド:
site clear-push-site-status --cache=actionTokens site clear-push-site-status --cache=authenticationSessions site clear-push-site-status --cache=clientSessions site clear-push-site-status --cache=loginFailures site clear-push-site-status --cache=offlineClientSessions site clear-push-site-status --cache=offlineSessions site clear-push-site-status --cache=sessions site clear-push-site-status --cache=work
出力:
"ok" "ok" "ok" "ok" "ok" "ok" "ok" "ok"
- プライマリーサイトにログインします。
Red Hat build of Keycloak を起動します。
Red Hat build of Keycloak Operator を使用して Red Hat build of Keycloak をデプロイした場合、Red Hat build of Keycloak カスタムリソース内の Red Hat build of Keycloak インスタンスの数を元の値に変更します。
両方の Data Grid クラスターが同期し、セカンダリーサイトからプライマリーサイトへのスイッチオーバーを実行できるようになります。
12.2.2. AWS Aurora データベース
リージョン内のマルチ AZ Aurora デプロイメントの場合、アベイラビリティーゾーン間の遅延と通信を回避するために、現在のライターインスタンスが、アクティブな Red Hat build of Keycloak クラスターと同じリージョン内にあるはずです。
Aurora のライターインスタンスを切り替えると、短いダウンタイムが発生します。他のサイトのライターインスタンスは、遅延が若干長くても、デプロイメントによっては許容可能な場合があります。したがって、このような状況は、デプロイメントの環境によっては、メンテナンス期間まで保留されるか、無視されることがあります。
ライターインスタンスを変更するには、フェイルオーバーを実行します。この変更により、データベースが短期間利用できなくなります。Red Hat build of Keycloak は、データベース接続を再確立する必要があります。
ライターインスタンスを他の AZ にフェイルオーバーするには、次のコマンドを発行します。
aws rds failover-db-cluster --db-cluster-identifier ...
12.2.3. Route53
ヘルスエンドポイントの変更によってセカンダリーサイトへのスイッチオーバーがトリガーされた場合は、正しいエンドポイント (health/live) を参照するように AWS のヘルスチェックを編集します。数分後、クライアントが変更を認識し、トラフィックが徐々にセカンダリーサイトに移動します。
