2.6. 質問と回答
- データベース同期レプリケーションを使用するのはなぜですか?
- データベースを同期的にレプリケートすると、プライマリーサイトに書き込まれたデータがフェイルオーバー時にセカンダリーサイトで常に利用可能になり、データが失われなくなります。
- Data Grid 同期レプリケーションを使用するのはなぜですか?
- Data Grid を同期的にレプリケートすると、プライマリーサイトで作成、更新、削除されたセッションがフェイルオーバー時にセカンダリーサイトで常に利用可能になり、データが失われなくなります。
- サイト間に低遅延ネットワークが必要なのはなぜですか?
- 同期レプリケーションでは、セカンダリーサイトでデータが受信されるまで、呼び出し元への応答を延期します。データベース同期レプリケーションと Data Grid 同期レプリケーションでは、データの更新時に各リクエストでサイト間のやり取りが複数回発生し、遅延が増大する可能性があるため、低遅延が必要です。
- なぜアクティブ/パッシブなのですか?
- データベースによっては、リーダーインスタンスを備えた単一のライターインスタンスをサポートしています。その場合、元のライターで障害が発生すると、リーダーインスタンスが新しいライターにプロモートします。このようなセットアップでは、現在アクティブな Red Hat build of Keycloak と同じサイトにライターインスタンスがあると、レイテンシーの点で有利です。Data Grid 同期レプリケーションでは、両方のサイトのエントリーが同時に変更されるとデッドロックが発生する可能性があります。
- このセットアップを使用できるのは 2 つのサイトだけですか?
- このセットアップは複数のサイトに拡張できます。たとえば 3 つのサイトを使用する場合、基本的な変更を加える必要はありません。サイトを追加すると、サイト間の全体的な遅延が増加し、ネットワーク障害が発生する可能性、つまり短いダウンタイムが発生する可能性も増加します。したがって、そのようなデプロイメントではパフォーマンスが低下および劣化すると予想されます。現在は、2 つのサイト用のブループリントのみを使用してテストおよびドキュメント化されています。
- 同期クラスターは非同期クラスターよりも安定性に劣りますか?
非同期セットアップでは、サイト間のネットワーク障害が正常に処理されます。一方、同期セットアップでは、非同期セットアップならセカンダリーサイトの Data Grid またはデータベースへの書き込みが延期されるような状況でも、リクエストが遅延し、呼び出し元に対してエラーが出力されます。しかし、セカンダリーサイトがプライマリーサイトと完全に同期した状態になることはないため、このセットアップではフェイルオーバー中にデータ損失が発生する可能性があります。データ損失には次のものが含まれます。
- ログアウトの喪失。つまり、セッションの Data Grid 非同期レプリケーションを使用した場合、フェイルオーバーの時点で、セッションがプライマリーサイトからはログアウトしていますが、セカンダリーサイトにはログインしている状態になります。
- 非同期データベースを使用した場合、データベースの変更がフェイルオーバー時にセカンダリーサイトにレプリケートされないため、変更が失われ、ユーザーが古いパスワードでログインできます。
- Data Grid 非同期レプリケーションを使用した場合、セカンダリーサイトへのフェイルオーバー時に無効化キャッシュが伝播されないため、無効なキャッシュによりユーザーが古いパスワードでログインできます。
したがって、高可用性と整合性の間にはトレードオフが存在します。このトピックの焦点は、Red Hat build of Keycloak の可用性よりも整合性を優先することです。
