12.2. 流程
12.2.1. Data Grid 集群
对于本章的上下文中,site -A
是主站点,恢复为操作,site -B
是生产中运行的次要站点。
在主站点中的 Data Grid 返回后,并已加入跨站点频道(请参阅 带有 Data Grid Operator Deploy Data Griding-the-deployment on the Data Griddeployment)的 Deploy Data Griding-the-deployment on the Data Grid deployment,必须从二级站点手动启动。
在清除主站点中的状态后,它会将完整状态从次要站点传输到主站点,并且必须在主站点开始处理传入请求之前完成。
通过增加响应时间和/或资源使用量,传输完整状态可能会影响 Data Grid 集群执行。
第一个步骤是从主站点中删除任何过时的数据。
- 登录到主站点。
关闭红帽构建的 Keycloak。此操作将清除所有红帽构建的 Keycloak 缓存,并防止红帽构建的 Keycloak 状态与数据网格不同步。
当使用红帽构建的 Keycloak Operator 部署红帽 Keycloak 时,将红帽构建的 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 的 Deploy Data Grid for HA 一章中设置的。
输出:
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" }
如果状态未
脱机
,请重复上一步。警告确保复制
离线
,否则清除数据将清除这两个站点。使用以下命令清除主站点中的所有缓存数据:
命令:
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" }
检查复制状态是否为
在线
。命令:
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 的 Deploy Data Grid for HA 一章中设置的。
输出:
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" }
检查所有缓存的复制状态是否
在线
。命令:
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" }
检查本节中的表 ,了解 Cross-Site Documentation 中的可能状态值。
如果报告错误,请为该特定缓存重复状态传输。
命令:
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"
- 登录到主站点。
启动红帽构建的 Keycloak。
当使用红帽构建的 Keycloak Operator 部署红帽 Keycloak 时,将红帽构建的 Keycloak 实例的数量改为原始值。
两个 Data Grid 集群都同步,可以执行从次要到主站点的切换。
12.2.2. AWS Aurora 数据库
假设区域 multi-AZ Aurora 部署,当前写入器实例应与有效的红帽构建的 Keycloak 集群位于同一个区域,以避免跨可用区的延迟和通信。
切换 Aurora 的写器实例会导致短暂的停机时间。在某些部署中,其他站点中的写入器实例可能会接受延迟稍长。因此,这个情况可能会延迟到维护窗口或跳过,具体取决于部署的情况。
要更改写器实例,请运行故障转移。此更改将使数据库在短时间内不可用。红帽构建的 Keycloak 需要重新建立数据库连接。
要将 writer 实例切换到其他 AZ,请运行以下命令:
aws rds failover-db-cluster --db-cluster-identifier ...
12.2.3. Route53
如果通过更改健康端点触发了切换到二级站点,请编辑 AWS 中的健康检查以指向正确的端点(health/live
)。几分钟后,客户端会注意到更改,流量将逐渐移到次要站点。