Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

3.14. 使用 Data Grid Operator 部署用于 HA 的 Data Grid

在 OpenShift 上的多可用区部署 Data Grid 以实现高可用性。

本章论述了在多集群环境（跨站点）中部署 Data Grid 所需的步骤。为了简单起见，本主题使用最小的配置，允许红帽构建 Keycloak 与外部 Data Grid 一起使用。

本章假定两个 OpenShift 集群名为 Site-A 和 Site-B。

这是一个构建块，它遵循 多集群部署 一章中介绍的概念。如需了解概述，请参阅 多集群部署 章节。

重要

对于外部 Data Grid 部署，只支持 Data Grid 版本 8.5.3 或最新的补丁版本。

3.14.1. 架构
复制链接

此设置会在具有低延迟网络连接的两个站点中部署两个同步复制 Data Grid 集群。例如，在这种情况下，可能是一个 AWS 区域的两个可用区。

为了简单起见，红帽构建的 Keycloak, loadbalancer 和 database 已从下图中删除。

3.14.2. 先决条件
复制链接

3.14.3. 流程
复制链接

  1. 安装 Data Grid Operator

  2. 配置用于访问 Data Grid 集群的凭证。

    红帽构建的 Keycloak 需要此凭证才能与 Data Grid 集群进行身份验证。以下 identity.yaml 文件使用 admin 权限设置用户名和密码 

    credentials:
  - username: developer
    password: strong-password
    roles:
      - admin

    identity.yaml 可以在 secret 中设置为以下之一：

    • 作为 OpenShift 资源：

      凭证 Secret

      apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: connect-secret
  namespace: keycloak
data:
  identities.yaml: Y3JlZGVudGlhbHM6CiAgLSB1c2VybmFtZTogZGV2ZWxvcGVyCiAgICBwYXNzd29yZDogc3Ryb25nLXBhc3N3b3JkCiAgICByb2xlczoKICAgICAgLSBhZG1pbgo=
      1

      1
      前面示例 base64 编码中的 identity .yaml。

    • 使用 CLI 

      oc create secret generic connect-secret --from-file=identities.yaml

      如需了解更多详细信息，请参阅配置身份验证文档。https://docs.redhat.com/en/documentation/red_hat_data_grid/8.5/html-single/data_grid_operator_guide/index#configuring-authentication

      这两个 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

      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

      在 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

    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)"

      将 Site-A 令牌部署到 Site-B

      oc create secret generic -n keycloak xsite-token-secret \
  --from-literal=token="$(cat Site-A-token.txt)"

  4. 创建 TLS secret

    在本章中，Data Grid 使用 OpenShift 路由进行跨站点通信。它使用 TLS 的 SNI 扩展将流量定向到正确的 Pod。为达到此目的，JGroups 使用 TLS 套接字，这需要一个含有正确证书的 Keystore 和 Truststore。

    如需更多信息，请参阅安全 跨站点连接 文档或本 红帽开发人员指南。

    上传 OpenShift Secret 中的 Keystore 和 Truststore。secret 包含文件内容、访问它的密码以及存储的类型。创建证书和存储的说明超出了本章的讨论范围。

    要将 Keystore 作为 Secret 上传，请使用以下命令：

    部署密钥存储

    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

    1
    文件名和到密钥存储的路径。
    2
    用于访问密钥存储的密码。
    3
    Keystore 类型。

    要将 Truststore 上传为 Secret，请使用以下命令：

    部署 Truststore

    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

    1
    文件名和到 Truststore 的路径。
    2
    访问 Truststore 的密码。
    3
    Truststore 类型。
    注意

    keystore 和 Truststore 必须在两个 OpenShift 集群中上传。

  5. 为启用了跨站点的 Data Grid 创建一个集群

    设置跨站点 文档提供了关于如何在启用了跨站点的情况下创建和配置 Data Grid 集群的所有信息，包括前面的步骤。

    本章提供了一个基本示例，它使用前面步骤中命令创建的凭据、令牌和 TLS Keystore/Truststore。

    Site-A的 Infinispan 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

    1
    集群名称
    2
    允许 Prometheus 监控集群。
    3
    如果使用自定义凭证，请在此处配置 secret 名称。
    4
    本地站点的名称，本例中为 Site-A。
    5
    使用 OpenShift Route 公开跨站点连接。
    6 9
    上一步中定义的 Keystore 所在的 secret 名称。
    7 10
    Keystore 中证书的别名。
    8 11
    上一步中定义的密钥存储的机密密钥(filename)。
    12
    Truststore 存在于上一步中定义的 secret 名称。
    13
    上一步中定义的密钥存储的 Truststore 密钥(filename)。
    14
    远程站点的名称，本例中为 Site-B。您可以在红帽构建的 Keycloak 选项 cache-remote-backup-sites 中使用这个值来创建自动缓存。
    15
    来自远程站点的 Data Grid 集群的命名空间。
    16
    远程站点的 OpenShift API URL。
    17
    带有访问令牌的 secret，以向远程站点进行身份验证。

    对于 Site-B，Infinispan CR 类似于上述内容。请注意点 4、11 和 13 的不同。

    Site-B的 Infinispan 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

  6. 为红帽构建的 Keycloak 创建缓存。

    如果不存在，Red Hat build of Keycloak 会自动在第一次启动时创建所需的缓存。

    重要

    它要求红帽构建的 Keycloak 部署到两个集群中，因为红帽构建的 Keycloak 不会启动，直到两个集群中都存在所有缓存。

    要 缓存 CR 是在 OpenShift 中继续进行的建议方法。为了生效，必须在任何红帽构建的 Keycloak Pod 启动前部署 Cache CR。

    以下示例显示了 Site-A 的 Cache CR。

    1. 在 Site-A 中，为上述每个缓存创建一个缓存 CR，其内容如下：

      cache 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"

      Cache 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"

      缓存 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"

      缓存 工作

      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"

      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。它将抛出一个错误，允许安全回滚事务。当发生这种情况时，红帽构建的 Keycloak 将尝试重试。

    transaction.locking: PESSIMISTIC 是唯一支持的锁定模式；由于网络成本，不建议使用 OPTIMISTIC。相同的设置也会阻止在一个站点更新，而其他站点无法访问。

    backup.strategy: SYNC 确保数据在完成红帽构建的 Keycloak 请求时可见并存储在其他站点。

    注意

    在死锁场景中，可以将 locking.acquireTimeout 减少为快速失败。backup.timeout 必须始终高于 locking.acquireTimeout。

    对于 Site-B，缓存 CR 非常相似，但 backup.& lt;name> 在上图的第 3 点概述。

    Site-B中的 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-a:
    3 
    
          backup:
            strategy: "SYNC"
    4 
    
            timeout: "4500"
    5 
    
            failurePolicy: "FAIL"
    6 
    
            stateTransfer:
              chunkSize: "16"

    == 验证部署

确认 Data Grid 集群已形成，且跨站点连接已在 OpenShift 集群之间建立。

等待 Data Grid 集群被形成

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

3.14.4. 使用红帽构建的 Keycloak 连接 Data Grid
复制链接

现在，Data Grid 服务器正在运行，以下是需要与红帽构建的 Keycloak CR 更改相关的红帽构建，以将其连接到红帽构建的 Keycloak。在使用 Operator 部署 Red Hat build of HA 中， 需要这些更改。

  1. 使用用户名和密码创建一个 Secret，以连接到外部 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'

  2. 使用 additionalOptions 扩展 Red Hat build of Keycloak 自定义资源，如下所示。

    注意

    所有内存、资源和数据库配置都会从 CR 跳过，因为 使用 Operator 部署红帽构建的 Keycloak for HA 所述。管理员应使这些配置保持不变。 

    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
    1 1
    远程 Data Grid 集群的主机名。
    2 2
    远程 Data Grid 集群的端口。这是可选的，默认为 11222。
    3 3
    带有 Data Grid 用户名凭证的 Secret 名称和 密钥。
    4 4
    使用 Data Grid 密码凭证的机密名称和密钥。
    5 5
    （可选）远程站点的名称。只有在缓存不存在时，才会创建缓存。
    重要

    使用 cache-remote-backup-sites 选项仅在本地站点中创建缓存。您还必须在其他集群中部署 KeycloakCR，才能创建缓存，否则红帽构建的 Keycloak 无法启动，直到它们存在为止。

3.14.4.1. 架构
复制链接

这使用 TLS 1.3 保护的 TCP 连接将 Keycloak 的红帽构建连接到 Data Grid。它使用红帽构建的 Keycloak 的信任存储来验证 Data Grid 的服务器证书。因为红帽构建的 Keycloak 是使用 OpenShift 在下面列出的先决条件中的 Operator 部署，Operator 已将 service-ca.crt 添加到用于为 Data Grid 的服务器证书签名的信任存储中。在其他环境中，将所需的证书添加到红帽构建的 Keycloak 的信任存储中。

3.14.5. 后续步骤
复制链接

在部署并运行 AWS Aurora 数据库和 Data Grid 后，请使用 使用 Operator 部署红帽构建的 Keycloak for HA 中的步骤来部署红帽构建的 Keycloak，并将其连接到之前创建的构建块。

3.14.6. 相关选项
复制链接

Expand
 value

cache-remote-backup-sites

配置备份站点名称列表到外部 Infinispan 集群备份 Keycloak 数据的位置。

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

仅在设置远程主机时可用

 

cache-remote-host

外部 Infinispan 集群的主机名。

仅在设置功能 多站点 或无 集群 时才可用。

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

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部