红帽全球峰会3.7. 多集群部署的概念
通过同步复制了解多集群部署。
本主题描述了高度可用的多集群设置，以及预期的行为。它概述了高可用性架构的要求，并描述了优点和权衡。
3.7.1. 何时使用此设置
使用此设置来提供红帽构建的 Keycloak 部署，以容许 OpenShift 集群故障，从而减少停机时间的可能性。
3.7.2. 部署、数据存储和缓存
在不同站点中运行的 Keycloak 部署的两个独立的红帽构建与低延迟网络连接连接。用户、域、客户端、会话和其他实体存储在同步在两个站点之间复制的数据库中。数据也缓存在红帽构建的 Keycloak Infinispan 缓存中，作为本地缓存。当数据在一个红帽构建的 Keycloak 实例中更改时，该数据会在数据库中更新，并使用 工作 缓存将无效消息发送到其他站点。
在以下段落和图表中，部署数据网格的参考适用于外部 Data Grid。
3.7.3. 数据丢失的原因
虽然此设置旨在实现高可用性，但以下情况仍然可以导致服务或数据丢失：
- 红帽构建的 Keycloak 站点失败可能会导致请求在故障和 loadbalancer 检测它之间失败，因为请求可能仍然路由到失败的站点。
- 当站点之间的通信出现问题后，需要手动步骤来重新同步降级设置。
- 如果其他组件失败，降级设置可能会导致服务或数据丢失。监控需要检测降级设置。
3.7.4. 此设置可以存活的故障
| 失败 | 恢复 | RPO1 | RT2 |
|---|---|---|---|
| 数据库节点 | 如果写入器实例失败，数据库可以提升相同或其他站点中的读取器实例，使其成为新的写入器。 | 没有数据丢失 | 分钟的秒数（取决于数据库） |
| Red Hat build of Keycloak 节点 | 多个红帽构建的 Keycloak 实例在每个站点上运行。如果一个实例失败，一些传入的请求可能会收到错误消息，或者延迟几秒钟。 | 没有数据丢失 | 少于 30 秒 |
| Data Grid 节点 | 在每个站点中运行多个 Data Grid 实例。如果一个实例失败，则其他节点需要几秒钟才能注意到更改。实体至少存储在两个 Data Grid 节点上，因此单个节点故障不会造成数据丢失。 | 没有数据丢失 | 少于 30 秒 |
| Data Grid 集群故障 |
如果 Data Grid 集群在其中一个站点中失败，红帽构建的 Keycloak 将无法与该站点的外部 Data Grid 通信，并且红帽构建的 Keycloak 服务将不可用。loadbalancer 将检测到情况，因为 设置会降级，直到 Data Grid 集群恢复且数据被重新同步。 | 没有数据丢失3 | 秒数（取决于负载均衡器设置） |
| 连接数据网格 | 如果两个站点之间的连接丢失，则无法将数据发送到其他站点。传入的请求可能会收到错误消息，或者延迟（以秒为单位）。Data Grid 将标记其他站点离线，并将停止发送数据。其中一个站点需要在负载均衡器中离线，直到恢复连接并在两个站点间重新同步数据。在蓝图中，我们展示了如何进行自动化。 | 没有数据丢失3 | 秒数（取决于负载均衡器设置） |
| 连接数据库 | 如果两个站点之间的连接丢失，同步复制将失败。有些请求可能会收到错误消息，或延迟几秒钟。根据数据库，可能需要手动操作。 | 没有数据丢失3 | 分钟的秒数（取决于数据库） |
| 站点失败 | 如果没有红帽构建的 Keycloak 节点可用，则 loadbalancer 将检测到中断，并将流量重定向到其他站点。有些请求可能会收到错误消息，直到 loadbalancer 检测到失败。 | 没有数据丢失3 | 少于两分钟 |
表注：
1 测试的恢复点目标，假设设置的所有部分都健康。
2 Maximum Recovery Time observed.
3 3 Manual operations to restore the degraded setup。
语句 "No data loss" 依赖于之前失败中的设置，包括完成任何待处理的手动操作来重新同步站点之间的状态。
3.7.5. 已知限制
- 站点故障
- 成功故障转移需要设置不会从以前的故障中降级。所有手动操作（如在上一个故障后重新同步）都必须完成，以防止数据丢失。使用监控确保及时检测和处理降级。
- 不同步站点
- 当同步 Data Grid 请求失败时，站点可能会不同步。这种情况目前很难监控，可能需要完全重新同步 Data Grid 才能恢复。监控站点中的缓存条目数量，以及 Red Hat build of Keycloak 日志文件时，可以在需要重新同步时显示。
- 手动操作
- 在站点间重新同步 Data Grid 状态的手动操作将发布完整状态转移，这将给系统带来压力。
- 两个站点限制
- 此设置只适用于两个站点。每个额外站点都会增加整体延迟，因为数据需要同步写入每个站点。此外，网络故障的可能性也会增加。因此，我们不支持超过两个站点，因为我们认为部署具有低端稳定性和性能。
3.7.6. 问题和答案
- 为什么要进行同步数据库复制？
- 同步复制的数据库可确保在站点失败后，在一个站点写入的数据始终会在其他站点中可用，且没有数据丢失。它还确保下一个请求不会返回过时的数据，与其提供服务的站点无关。
- 为什么要进行同步的 Data Grid 复制？
- 同步复制的 Data Grid 可确保在站点出现故障时，缓存的数据始终会在其他站点上可用，且不会丢失数据。它还确保下一个请求不会返回过时的数据，与其提供服务的站点无关。
- 为什么在站点间需要低延迟网络？
- 同步复制会延迟对调用者的响应，直到数据在其他站点收到为止。对于同步数据库复制和同步数据网格复制，因此当数据更新时，每个请求在站点间可能有多个交互，这会放大延迟。
- 同步集群是否低于异步集群？
异步设置会安全地处理站点之间的网络故障，而同步设置会延迟请求，并将抛出错误到调用者，异步设置会延迟到 Data Grid 或另一站点上的数据库。但是，因为两个站点永远不会完全更新，所以这个设置可能会导致失败过程中数据丢失。这包括：
- 丢失了导致用户无法使用旧密码登录的更改，因为在使用异步数据库时数据库更改不会复制到其他站点。
- 无效的缓存导致用户使用旧密码登录，因为在使用异步 Data Grid 复制时，无效的缓存不会传播到其他站点的故障点。
因此，高可用性和一致性之间存在权衡。本主题的重点是，与红帽构建的 Keycloak 相比，确定一致性优先级。
3.7.7. 后续步骤
继续阅读 构建块多集群部署 一章，以查找不同构建块的蓝图。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}