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. 手順

  1. Data Grid Operator をインストールします。
  2. Data Grid クラスターにアクセスするための認証情報を設定します。

    Red Hat build of Keycloak が Data Grid クラスターで認証できるようにするには、この認証情報が必要です。次の identities.yaml ファイルで、管理者権限を持つユーザー名とパスワードを設定します。

    credentials:
      - username: developer
        password: strong-password
        roles:
          - admin
    Copy to Clipboard Toggle word wrap

    identities.yaml は、次のいずれかの方法でシークレットに設定できます。

    • OpenShift リソースの場合

      認証情報シークレット

      apiVersion: v1
      kind: Secret
      type: Opaque
      metadata:
        name: connect-secret
        namespace: keycloak
      data:
        identities.yaml: Y3JlZGVudGlhbHM6CiAgLSB1c2VybmFtZTogZGV2ZWxvcGVyCiAgICBwYXNzd29yZDogc3Ryb25nLXBhc3N3b3JkCiAgICByb2xlczoKICAgICAgLSBhZG1pbgo= 
      1
      Copy to Clipboard Toggle word wrap

      1
      Base64 でエンコードした上記の例の identities.yaml
    • CLI の使用

      oc create secret generic connect-secret --from-file=identities.yaml
      Copy to Clipboard Toggle word wrap

      詳細は、認証の設定 ドキュメントを参照してください。

      これらのコマンドは両方の OpenShift クラスターで実行する必要があります。

  3. サービスアカウントを作成します。

    クラスター間の接続を確立するには、サービスアカウントが必要です。Data Grid Operator は、これを使用してリモートサイトからネットワーク設定を検査し、それに応じてローカル Data Grid クラスターを設定します。

    詳細は、マネージドのクロスサイトレプリケーション ドキュメントを参照してください。

    1. 次のように service-account-token シークレットタイプを作成します。同じ YAML ファイルを両方の OpenShift クラスターで使用できます。

      xsite-sa-secret-token.yaml

      apiVersion: v1
      kind: Secret
      metadata:
        name: ispn-xsite-sa-token 
      1
      
        annotations:
          kubernetes.io/service-account.name: "xsite-sa" 
      2
      
      type: kubernetes.io/service-account-token
      Copy to Clipboard Toggle word wrap

      1
      シークレットの名前。
      2
      サービスアカウントの名前。
    2. サービスアカウントを作成し、両方の 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.txt
      Copy to Clipboard Toggle word wrap

      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.txt
      Copy to Clipboard Toggle word wrap

    3. 次に、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)"
      Copy to Clipboard Toggle word wrap

      Site-A のトークンを Site-B にデプロイする

      oc create secret generic -n keycloak xsite-token-secret \
        --from-literal=token="$(cat Site-A-token.txt)"
      Copy to Clipboard Toggle word wrap

  4. 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" \ 
    1
    
      --from-literal=password=secret \ 
    2
    
      --from-literal=type=pkcs12 
    3
    Copy to Clipboard Toggle word wrap

    1
    ファイル名とキーストアへのパス。
    2
    キーストアにアクセスするためのパスワード。
    3
    キーストアのタイプ。

    トラストストアをシークレットとしてアップロードするには、次のコマンドを使用します。

    トラストストアのデプロイ

    oc -n keycloak create secret generic xsite-truststore-secret \
            --from-file=truststore.p12="./certs/truststore.p12" \  
    1
    
            --from-literal=password=caSecret \  
    2
    
            --from-literal=type=pkcs12  
    3
    Copy to Clipboard Toggle word wrap

    1
    ファイル名とトラストストアへのパス。
    2
    トラストストアにアクセスするためのパスワード。
    3
    トラストストアのタイプ。
    注記

    キーストアとトラストストアは、両方の OpenShift クラスターにアップロードする必要があります。

  5. クロスサイトを有効にして Data Grid のクラスターを作成する

    クロスサイトの設定 ドキュメントに、上記の手順を含め、クロスサイトを有効にして Data Grid クラスターを作成および設定する方法に関するすべての情報が記載されています。

    この章では、上記の手順のコマンドによって作成された認証情報、トークン、および TLS キーストア/トラストストアを使用した基本的な例を示します。

    Site-AInfinispan CR

    apiVersion: infinispan.org/v1
    kind: Infinispan
    metadata:
      name: infinispan 
    1
    
      namespace: keycloak
      annotations:
        infinispan.org/monitoring: 'true' 
    2
    
    spec:
      replicas: 3
      jmx:
        enabled: true
      security:
        endpointSecretName: connect-secret 
    3
    
      service:
        type: DataGrid
        sites:
          local:
            name: site-a 
    4
    
            expose:
              type: Route 
    5
    
            maxRelayNodes: 128
            encryption:
              transportKeyStore:
                secretName: xsite-keystore-secret 
    6
    
                alias: xsite 
    7
    
                filename: keystore.p12 
    8
    
              routerKeyStore:
                secretName: xsite-keystore-secret 
    9
    
                alias: xsite 
    10
    
                filename: keystore.p12 
    11
    
              trustStore:
                secretName: xsite-truststore-secret 
    12
    
                filename: truststore.p12 
    13
    
          locations:
            - name: site-b 
    14
    
              clusterName: infinispan
              namespace: keycloak 
    15
    
              url: openshift://api.site-b 
    16
    
              secretName: xsite-token-secret 
    17
    Copy to Clipboard Toggle word wrap

    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-BInfinispan CR も上記と同様です。ポイント 4、11、13 の違いに注意してください。

    Site-BInfinispan CR

    apiVersion: infinispan.org/v1
    kind: Infinispan
    metadata:
      name: infinispan 
    1
    
      namespace: keycloak
      annotations:
        infinispan.org/monitoring: 'true' 
    2
    
    spec:
      replicas: 3
      jmx:
        enabled: true
      security:
        endpointSecretName: connect-secret 
    3
    
      service:
        type: DataGrid
        sites:
          local:
            name: site-b 
    4
    
            expose:
              type: Route 
    5
    
            maxRelayNodes: 128
            encryption:
              transportKeyStore:
                secretName: xsite-keystore-secret 
    6
    
                alias: xsite 
    7
    
                filename: keystore.p12 
    8
    
              routerKeyStore:
                secretName: xsite-keystore-secret 
    9
    
                alias: xsite 
    10
    
                filename: keystore.p12 
    11
    
              trustStore:
                secretName: xsite-truststore-secret 
    12
    
                filename: truststore.p12 
    13
    
          locations:
            - name: site-a 
    14
    
              clusterName: infinispan
              namespace: keycloak 
    15
    
              url: openshift://api.site-a 
    16
    
              secretName: xsite-token-secret 
    17
    Copy to Clipboard Toggle word wrap

  6. Red Hat build of Keycloak 用のキャッシュを作成します。

    Red Hat build of Keycloak は、必要なキャッシュが存在しない場合は、最初の起動時に自動的に作成します。

    重要

    すべてのキャッシュが両方のクラスターに存在するまで Red Hat build of Keycloak は起動しないため、両方のクラスターに Red Hat build of Keycloak をデプロイする必要があります。

    Cache CR を使用することが、OpenShift で続行するための推奨される方法です。有効にするには、Red Hat build of Keycloak Pod が起動する前に Cache CR をデプロイする必要があります。

    次の例は、Site-ACache CR を示しています。

    1. Site-A で、上記の各キャッシュに対して次の内容の Cache CR を作成します。

      キャッシュ actionTokens

      apiVersion: infinispan.org/v2alpha1
      kind: Cache
      metadata:
        name: actiontokens
        namespace: keycloak
      spec:
        clusterName: infinispan
        name: actionTokens
        template: |-
          distributedCache:
            mode: "SYNC"
            owners: "2"
            statistics: "true"
            remoteTimeout: "5000"
            encoding:
              media-type: "application/x-protostream"
            locking:
              acquireTimeout: "4000"
            transaction:
              mode: "NON_DURABLE_XA" 
      1
      
              locking: "PESSIMISTIC" 
      2
      
            stateTransfer:
              chunkSize: "16"
            backups:
              site-b: 
      3
      
                backup:
                  strategy: "SYNC" 
      4
      
                  timeout: "4500" 
      5
      
                  failurePolicy: "FAIL" 
      6
      
                  stateTransfer:
                    chunkSize: "16"
      Copy to Clipboard Toggle word wrap

      キャッシュ authenticationSessions

      apiVersion: infinispan.org/v2alpha1
      kind: Cache
      metadata:
        name: authenticationsessions
        namespace: keycloak
      spec:
        clusterName: infinispan
        name: authenticationSessions
        template: |-
          distributedCache:
            mode: "SYNC"
            owners: "2"
            statistics: "true"
            remoteTimeout: "5000"
            encoding:
              media-type: "application/x-protostream"
            locking:
              acquireTimeout: "4000"
            transaction:
              mode: "NON_DURABLE_XA" 
      1
      
              locking: "PESSIMISTIC" 
      2
      
            stateTransfer:
              chunkSize: "16"
            indexing:
              enabled: true
              indexed-entities:
              - keycloak.RootAuthenticationSessionEntity
            backups:
              site-b: 
      3
      
                backup:
                  strategy: "SYNC" 
      4
      
                  timeout: "4500" 
      5
      
                  failurePolicy: "FAIL" 
      6
      
                  stateTransfer:
                    chunkSize: "16"
      Copy to Clipboard Toggle word wrap

      キャッシュ loginFailures

      apiVersion: infinispan.org/v2alpha1
      kind: Cache
      metadata:
        name: loginfailures
        namespace: keycloak
      spec:
        clusterName: infinispan
        name: loginFailures
        template: |-
          distributedCache:
            mode: "SYNC"
            owners: "2"
            statistics: "true"
            remoteTimeout: "5000"
            encoding:
              media-type: "application/x-protostream"
            locking:
              acquireTimeout: "4000"
            transaction:
              mode: "NON_DURABLE_XA" 
      1
      
              locking: "PESSIMISTIC" 
      2
      
            stateTransfer:
              chunkSize: "16"
            indexing:
              enabled: true
              indexed-entities:
              - keycloak.LoginFailureEntity
            backups:
              site-b: 
      3
      
                backup:
                  strategy: "SYNC" 
      4
      
                  timeout: "4500" 
      5
      
                  failurePolicy: "FAIL" 
      6
      
                  stateTransfer:
                    chunkSize: "16"
      Copy to Clipboard Toggle word wrap

      キャッシュ work

      apiVersion: infinispan.org/v2alpha1
      kind: Cache
      metadata:
        name: work
        namespace: keycloak
      spec:
        clusterName: infinispan
        name: work
        template: |-
          distributedCache:
            mode: "SYNC"
            owners: "2"
            statistics: "true"
            remoteTimeout: "5000"
            encoding:
              media-type: "application/x-protostream"
            locking:
              acquireTimeout: "4000"
            transaction:
              mode: "NON_DURABLE_XA" 
      1
      
              locking: "PESSIMISTIC" 
      2
      
            stateTransfer:
              chunkSize: "16"
            backups:
              site-b: 
      3
      
                backup:
                  strategy: "SYNC" 
      4
      
                  timeout: "4500" 
      5
      
                  failurePolicy: "FAIL" 
      6
      
                  stateTransfer:
                    chunkSize: "16"
      Copy to Clipboard Toggle word wrap

      1 1 1 1 1
      トランザクションモード。
      2 2 2 2 2
      トランザクションで使用されるロックモード。
      3 3 3 3 3
      リモートサイト名。
      4 4 4 4 4
      クロスサイト通信ストラテジー。この場合は SYNC
      5 5 5 5 5
      クロスサイトレプリケーションのタイムアウト。
      6 9 6 6 6 6
      クロスサイトレプリケーションの失敗ポリシー。

    上記の例は、最善のデータ整合性を実現するために推奨される設定です。

    背景情報

    アクティブ/アクティブ設定では、両方のサイトでエントリーが同時に変更されるため、デッドロックが発生する可能性があります。

    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> を除き、Cache CR は同じようになります。

    Site-BactionTokens キャッシュの例

    apiVersion: infinispan.org/v2alpha1
    kind: Cache
    metadata:
      name: actiontokens
      namespace: keycloak
    spec:
      clusterName: infinispan
      name: actionTokens
      template: |-
        distributedCache:
          mode: "SYNC"
          owners: "2"
          statistics: "true"
          remoteTimeout: "5000"
          encoding:
            media-type: "application/x-protostream"
          locking:
            acquireTimeout: "4000"
          transaction:
            mode: "NON_DURABLE_XA" 
    1
    
            locking: "PESSIMISTIC" 
    2
    
          stateTransfer:
            chunkSize: "16"
          backups:
            site-a: 
    3
    
              backup:
                strategy: "SYNC" 
    4
    
                timeout: "4500" 
    5
    
                failurePolicy: "FAIL" 
    6
    
                stateTransfer:
                  chunkSize: "16"
    Copy to Clipboard Toggle word wrap

    == デプロイメントの確認

Data Grid クラスターが形成され、OpenShift クラスター間にクロスサイト接続が確立されていることを確認します。

Data Grid クラスターが形成されるまで待機する

oc wait --for condition=WellFormed --timeout=300s infinispans.infinispan.org -n keycloak infinispan
Copy to Clipboard Toggle word wrap

Data Grid のクロスサイト接続が確立されるまで待機する

oc wait --for condition=CrossSiteViewFormed --timeout=300s infinispans.infinispan.org -n keycloak infinispan
Copy to Clipboard Toggle word wrap

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 をデプロイする の章で必要になります。

  1. 外部 Data Grid デプロイメントに接続するためのユーザー名とパスワードを使用してシークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: remote-store-secret
      namespace: keycloak
    type: Opaque
    data:
      username: ZGV2ZWxvcGVy # base64 encoding for 'developer'
      password: c2VjdXJlX3Bhc3N3b3Jk # base64 encoding for 'secure_password'
    Copy to Clipboard Toggle word wrap
  2. 以下に示すように、additionalOptions を使用して Red Hat build of Keycloak カスタムリソースを拡張します。

    注記

    メモリー、リソース、データベース設定は、Operator を使用して HA 用に Red Hat build of Keycloak をデプロイする の章で説明したため、以下の CR では省略されています。管理者はこれらの設定をそのままにしておく必要があります。

    apiVersion: k8s.keycloak.org/v2alpha1
    kind: Keycloak
    metadata:
      labels:
        app: keycloak
      name: keycloak
      namespace: keycloak
    spec:
      additionalOptions:
        - name: cache-remote-host 
    1
    
          value: "infinispan.keycloak.svc"
        - name: cache-remote-port 
    2
    
          value: "11222"
        - name: cache-remote-username 
    3
    
          secret:
            name: remote-store-secret
            key: username
        - name: cache-remote-password 
    4
    
          secret:
            name: remote-store-secret
            key: password
        - name: cache-remote-backup-sites
          value: "site-2" 
    5
    Copy to Clipboard Toggle word wrap
    1 1
    リモート Data Grid クラスターのホスト名。
    2 2
    リモート Data Grid クラスターのポート。これはオプションであり、デフォルトは 11222 です。
    3 3
    Data Grid のユーザー名認証情報を含むシークレットの name および key
    4 4
    Data Grid のパスワード認証情報を含むシークレットの name および key
    5 5
    リモートサイトの名前 (オプション)。キャッシュは、まだ存在しない場合にのみ作成されます。
    重要

    オプション 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. 関連するオプション

Expand
 

cache-remote-backup-sites

外部 Infinispan クラスターが Keycloak データをバックアップするバックアップサイト名のリストを設定します。

CLI: --cache-remote-backup-sites
Env: KC_CACHE_REMOTE_BACKUP_SITES

リモートホストが設定されている場合にのみ使用可能です。

 

cache-remote-host

外部 Infinispan クラスターのホスト名。

multi-site または clusterless 機能が設定されている場合にのみ使用可能です。

CLI: --cache-remote-host
Env: KC_CACHE_REMOTE_HOST

 

cache-remote-password

外部 Infinispan クラスターへの認証用のパスワード。

セキュアではない外部 Infinispan クラスターに接続する場合はオプションです。オプションを指定する場合は、cache-remote-username も必要です。

CLI: --cache-remote-password
Env: KC_CACHE_REMOTE_PASSWORD

リモートホストが設定されている場合にのみ使用可能です。

 

cache-remote-port

外部 Infinispan クラスターのポート。

CLI: --cache-remote-port
Env: KC_CACHE_REMOTE_PORT

リモートホストが設定されている場合にのみ使用可能です。

11222 (デフォルト)

cache-remote-tls-enabled

TLS サポートを有効にして、保護されたリモート Infinispan サーバーと通信します。

実稼働環境では有効にすることを推奨します。

CLI: --cache-remote-tls-enabled
Env: KC_CACHE_REMOTE_TLS_ENABLED

リモートホストが設定されている場合にのみ使用可能です。

true (デフォルト)、false

cache-remote-username

外部 Infinispan クラスターへの認証用のユーザー名。

セキュアではない外部 Infinispan クラスターに接続する場合はオプションです。オプションを指定する場合は、cache-remote-password も必要です。

CLI: --cache-remote-username
Env: KC_CACHE_REMOTE_USERNAME

リモートホストが設定されている場合にのみ使用可能です。

 
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat