3.14. Data Grid Operator を使用して HA 用に Data Grid をデプロイする
OpenShift 上の複数のアベイラビリティーゾーンで高可用性を実現するために、Data Grid をデプロイします。
この章では、マルチクラスター (クロスサイト) 環境に Data Grid をデプロイするために必要な手順を説明します。わかりやすくするために、このトピックでは、Red Hat build of Keycloak を外部 Data Grid で使用できる最小限の設定を使用します。
この章では、Site-A および Site-B という名前の 2 つの OpenShift クラスターを想定しています。
これは、マルチクラスターデプロイメントの概念 の章で説明されている概念に基づく構成要素です。概要は、マルチクラスターデプロイメント の章を参照してください。
外部 Data Grid デプロイメントでは、Data Grid バージョン 8.5.3 以降の最新パッチリリースのみがサポートされます。
3.14.1. アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
このセットアップでは、低遅延のネットワーク接続で接続された 2 つのサイトに、同期的にレプリケートする 2 つの Data Grid クラスターがデプロイされています。このようなシナリオの例としては、2 つのアベイラビリティーゾーンがある 1 つの AWS リージョンが考えられます。
わかりやすくするために、Red Hat build of Keycloak、ロードバランサー、およびデータベースは次の図から削除されています。
3.14.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift クラスターが実行されている。
- Data Grid Operator を理解している。
3.14.3. 手順 リンクのコピーリンクがクリップボードにコピーされました!
- Data Grid Operator をインストールします。
Data Grid クラスターにアクセスするための認証情報を設定します。
Red Hat build of Keycloak が Data Grid クラスターで認証できるようにするには、この認証情報が必要です。次の
identities.yamlファイルで、管理者権限を持つユーザー名とパスワードを設定します。credentials: - username: developer password: strong-password roles: - admincredentials: - username: developer password: strong-password roles: - adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow identities.yamlは、次のいずれかの方法でシークレットに設定できます。OpenShift リソースの場合
認証情報シークレット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 でエンコードした上記の例の
identities.yaml。
CLI の使用
oc create secret generic connect-secret --from-file=identities.yaml
oc create secret generic connect-secret --from-file=identities.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、認証の設定 ドキュメントを参照してください。
これらのコマンドは両方の OpenShift クラスターで実行する必要があります。
サービスアカウントを作成します。
クラスター間の接続を確立するには、サービスアカウントが必要です。Data Grid Operator は、これを使用してリモートサイトからネットワーク設定を検査し、それに応じてローカル Data Grid クラスターを設定します。
詳細は、マネージドのクロスサイトレプリケーション ドキュメントを参照してください。
次のように
service-account-tokenシークレットタイプを作成します。同じ YAML ファイルを両方の OpenShift クラスターで使用できます。xsite-sa-secret-token.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントを作成し、両方の OpenShift クラスターでアクセストークンを生成します。
Site-Aでサービスアカウントを作成するoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-A-token.txtoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-A-token.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow Site-Bでサービスアカウントを作成するoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-B-token.txtoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-B-token.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、
Site-AからSite-Bにトークンをデプロイしてから、その逆を行います。Site-BのトークンをSite-Aにデプロイするoc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-B-token.txt)"
oc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-B-token.txt)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Site-AのトークンをSite-Bにデプロイするoc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-A-token.txt)"
oc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-A-token.txt)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TLS シークレットを作成します。
この章では、Data Grid でクロスサイト通信に OpenShift ルートを使用します。この OpenShift ルートは、TLS の SNI 拡張を使用してトラフィックを正しい Pod に送信します。これを実現するために、JGroups は TLS ソケットを使用します。これには、正しい証明書を備えたキーストアとトラストストアが必要です。
詳細は、クロスサイト接続のセキュリティー保護 ドキュメントまたはこちらの Red Hat Developer Guide を参照してください。
キーストアとトラストストアは、OpenShift シークレットでアップロードします。シークレットには、ファイルの内容、ファイルにアクセスするためのパスワード、およびストアのタイプを含めます。証明書とストアを作成する手順は、この章では説明しません。
キーストアをシークレットとしてアップロードするには、次のコマンドを使用します。
キーストアのデプロイ
oc -n keycloak create secret generic xsite-keystore-secret \ --from-file=keystore.p12="./certs/keystore.p12" \ --from-literal=password=secret \ --from-literal=type=pkcs12
oc -n keycloak create secret generic xsite-keystore-secret \ --from-file=keystore.p12="./certs/keystore.p12" \1 --from-literal=password=secret \2 --from-literal=type=pkcs123 Copy to Clipboard Copied! Toggle word wrap Toggle overflow トラストストアをシークレットとしてアップロードするには、次のコマンドを使用します。
トラストストアのデプロイ
oc -n keycloak create secret generic xsite-truststore-secret \ --from-file=truststore.p12="./certs/truststore.p12" \ --from-literal=password=caSecret \ --from-literal=type=pkcs12oc -n keycloak create secret generic xsite-truststore-secret \ --from-file=truststore.p12="./certs/truststore.p12" \1 --from-literal=password=caSecret \2 --from-literal=type=pkcs123 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記キーストアとトラストストアは、両方の OpenShift クラスターにアップロードする必要があります。
クロスサイトを有効にして Data Grid のクラスターを作成する
クロスサイトの設定 ドキュメントに、上記の手順を含め、クロスサイトを有効にして Data Grid クラスターを作成および設定する方法に関するすべての情報が記載されています。
この章では、上記の手順のコマンドによって作成された認証情報、トークン、および TLS キーストア/トラストストアを使用した基本的な例を示します。
Site-AのInfinispanCRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター名。
- 2
- Prometheus によるクラスターの監視を許可します。
- 3
- カスタムの認証情報を使用する場合は、ここでシークレット名を設定します。
- 4
- ローカルサイトの名前。この場合は
Site-Aです。 - 5
- OpenShift ルートを使用したクロスサイト接続の公開。
- 6 9
- 前のステップで定義したキーストアが存在するシークレット名。
- 7 10
- キーストア内の証明書のエイリアス。
- 8 11
- 前のステップで定義したキーストアの秘密鍵 (ファイル名)。
- 12
- 前のステップで定義したトラストストアが存在するシークレット名。
- 13
- 前のステップで定義したキーストアのトラストストアキー (ファイル名)。
- 14
- リモートサイトの名前 (この場合は
Site-B)。自動キャッシュ作成のために、Red Hat build of Keycloak オプションcache-remote-backup-sitesでこの値を使用できます。 - 15
- リモートサイトの Data Grid クラスターの namespace。
- 16
- リモートサイトの OpenShift API URL。
- 17
- リモートサイトで認証するためのアクセストークンを含むシークレット。
Site-BのInfinispanCR も上記と同様です。ポイント 4、11、13 の違いに注意してください。Site-BのInfinispanCRCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat build of Keycloak 用のキャッシュを作成します。
Red Hat build of Keycloak は、必要なキャッシュが存在しない場合は、最初の起動時に自動的に作成します。
重要すべてのキャッシュが両方のクラスターに存在するまで Red Hat build of Keycloak は起動しないため、両方のクラスターに Red Hat build of Keycloak をデプロイする必要があります。
CacheCR を使用することが、OpenShift で続行するための推奨される方法です。有効にするには、Red Hat build of Keycloak Pod が起動する前にCacheCR をデプロイする必要があります。次の例は、
Site-AのCacheCR を示しています。Site-Aで、上記の各キャッシュに対して次の内容のCacheCR を作成します。キャッシュ
actionTokensCopy to Clipboard Copied! Toggle word wrap Toggle overflow キャッシュ
authenticationSessionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow キャッシュ
loginFailuresCopy to Clipboard Copied! Toggle word wrap Toggle overflow キャッシュ
workCopy to Clipboard Copied! Toggle word wrap Toggle overflow
上記の例は、最善のデータ整合性を実現するために推奨される設定です。
背景情報
アクティブ/アクティブ設定では、両方のサイトでエントリーが同時に変更されるため、デッドロックが発生する可能性があります。
transaction.mode: NON_DURABLE_XAでは、そのようになった場合にデータの整合性を保ちながらトランザクションがロールバックされます。この場合、backup.failurePolicy: FAILを設定する必要があります。トランザクションを安全にロールバックするためのエラーが出力されます。この状況が発生すると、Red Hat build of Keycloak は再試行を試みます。transaction.locking: PESSIMISTICは唯一サポートされているロックモードです。OPTIMISTICはネットワークコストが高いため推奨されません。同じ設定により、一方のサイトにアクセスできない間にもう一方のサイトが更新されることも防止されます。backup.strategy: SYNCでは、Red Hat build of Keycloak のリクエストが完了したときに、データが他のサイトで表示および保存されます。注記locking.acquireTimeoutを短くすると、デッドロックシナリオでフェイルファストを実行できます。backup.timeoutは必ずlocking.acquireTimeoutよりも大きくなければなりません。Site-Bの場合、上図のポイント 3 に示されているbackups.<name>を除き、CacheCR は同じようになります。Site-BのactionTokensキャッシュの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow == デプロイメントの確認
Data Grid クラスターが形成され、OpenShift クラスター間にクロスサイト接続が確立されていることを確認します。
Data Grid クラスターが形成されるまで待機する
oc wait --for condition=WellFormed --timeout=300s infinispans.infinispan.org -n keycloak infinispan
oc wait --for condition=WellFormed --timeout=300s infinispans.infinispan.org -n keycloak infinispan
Data Grid のクロスサイト接続が確立されるまで待機する
oc wait --for condition=CrossSiteViewFormed --timeout=300s infinispans.infinispan.org -n keycloak infinispan
oc wait --for condition=CrossSiteViewFormed --timeout=300s infinispans.infinispan.org -n keycloak infinispan
3.14.4. Red Hat build of Keycloak と Data Grid を接続する リンクのコピーリンクがクリップボードにコピーされました!
この時点で Data Grid サーバーは実行されています。ここでは、それを Red Hat build of Keycloak に接続するために必要な Red Hat build of Keycloak CR の変更をて説明します。以下の変更は、Operator を使用して HA 用に Red Hat build of Keycloak をデプロイする の章で必要になります。
外部 Data Grid デプロイメントに接続するためのユーザー名とパスワードを使用してシークレットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に示すように、
additionalOptionsを使用して Red Hat build of Keycloak カスタムリソースを拡張します。注記メモリー、リソース、データベース設定は、Operator を使用して HA 用に Red Hat build of Keycloak をデプロイする の章で説明したため、以下の CR では省略されています。管理者はこれらの設定をそのままにしておく必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要オプション
cache-remote-backup-sitesを使用すると、ローカルサイトにのみキャッシュが作成されます。他のクラスターにもKeycloakCRをデプロイして、そこにキャッシュを作成する必要があります。そうしないと、キャッシュが存在するまで Red Hat build of Keycloak は起動に失敗します。
3.14.4.1. アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
この設定では、TLS 1.3 で保護された TCP 接続を使用して、Red Hat build of Keycloak を Data Grid に接続します。Red Hat build of Keycloak のトラストストアを使用して、Data Grid のサーバー証明書を検証します。Red Hat build of Keycloak は、下記の前提条件に基づいて OpenShift 上の Operator を使用してデプロイされます。そのため、Data Grid のサーバー証明書への署名に使用されるトラストストアに service-ca.crt が Operator によってすでに追加されています。その他の環境では、Red Hat build of Keycloak のトラストストアに必要な証明書を追加してください。
3.14.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
AWS Aurora データベースと Data Grid をデプロイして実行したら、Operator を使用して HA 用に Red Hat build of Keycloak をデプロイする の章の手順を使用して、Red Hat build of Keycloak をデプロイし、以前に作成したすべての構成要素に接続します。
3.14.6. 関連するオプション リンクのコピーリンクがクリップボードにコピーされました!
| 値 | |
|---|---|
|
CLI: リモートホストが設定されている場合にのみ使用可能です。 | |
|
CLI: | |
|
CLI: リモートホストが設定されている場合にのみ使用可能です。 | |
|
CLI: リモートホストが設定されている場合にのみ使用可能です。 | (デフォルト) |
|
CLI: リモートホストが設定されている場合にのみ使用可能です。 |
|
|
CLI: リモートホストが設定されている場合にのみ使用可能です。 |