工作负载的高可用性设计

IBM Cloud 支持在单个区域、多区域中的多个区域以及多个区域之间部署高可用性应用程序。

故障域决定了每种部署方案对基础设施故障的保护程度。 部署在单个区域中的应用程序实例不受该区域故障的影响。 部署在多个可用性区域的应用程序实例可免受单个区域故障的影响。 多个可用性区域位于同一城市区域内，并通过低延迟网络链接连接起来，以便在各区域间同步复制数据。 部署在多个区域的应用程序实例可免受整个区域故障的影响。 不同地区位于不同国家或一个国家的不同地区。 区域之间的距离通常只允许异步复制数据。

下表列出了基于公共云可用故障域的应用程序部署选项。

高可用性部署选项及其各自的可用性、故障域、维护成本和复杂性。
部署 可用性 故障域 成本和复杂性
单区，
单区 		低/中 虚拟服务器/物理主机 低
多区，
单区 		高 区域 中
多区域，
多区域 		非常高 区域 高

单区部署

在单区部署中，多个应用程序实例部署在一个区中。 如果应用程序实例在单个虚拟服务器中运行，安置组 允许在单独的物理主机中配置这些虚拟服务器。 VPC Autoscale 可用于根据工作负载变化进行动态容量调整。 单区部署可提供经济高效的解决方案，基础设施可用率高达 99.9。 这种部署可能适合非生产环境或非关键业务应用。 但是，单区部署无法防止区中断。

在使用此部署模型时，避免区域性失衡是最佳实践。 区域不平衡是指资源容量（例如 VPC 虚拟服务器实例（VSI））在各个区域之间分布不均的情况。 假设有一个工作负载，其VSI容量的70%部署在第1区，20%部署在第2区，10%部署在第3区。 如果第 1 区发生故障，工作负载可能仍可正常运行，但其容量将仅为原来的 30%。 一种解决方案是在第1区发生故障时分配更多资源，但该故障可能会导致其余区域的容量需求出现异常激增。 更好的解决方案是消除这种不平衡，确保所需容量在各区域之间合理分配，并在每个区域额外预留约17%的冗余，以弥补任何单个区域可能出现的损失。 这可确保即使某个区域发生故障，工作负载仍能保持可用并以满负荷运行。

多区、单区域部署

在多区域、单区域部署中，多个应用程序实例部署在区域内的两个或多个可用性区域中。 当应用程序部署在三个可用区时，多区、单区域部署可提供高达 99.99 %的基础设施可用性。 此部署方案可保护应用程序免受区域故障的影响，适用于对可用性要求高于 99.9 %的生产级企业工作负载。 实际的应用程序可用性取决于应用程序的高可用性设计。

使用此部署模型时，请避免区域间的不平衡。 当容量（例如，IBM Cloud® Virtual Servers for Virtual Private Cloud s（VSIs））在各区域之间分布不均时，就会出现区域不平衡。 假设有一个工作负载，其 VSI 容量的 70% 部署在第 1 区，20% 部署在第 2 区，10% 部署在第 3 区。 如果第 1 区发生故障，工作负载可能仍可正常运行，但其容量将仅剩 30%。 虽然可以在发生故障时调配更多资源，但故障可能会导致其余区域的容量需求出现异常激增。 相反，应通过将所需容量均匀分配到各个区域来消除这种不平衡，同时每个区域额外预留约17%的冗余，以弥补任何单个区域可能出现的损失。 这可确保即使某个区域发生故障，工作负载仍能保持可用，并能以满负荷运行。

多区域、多地区部署

多区、多区域部署可防止区域中断。 建议有持续或接近持续可用性要求的关键任务应用程序采用这种部署方式。 这种部署还支持区域外灾难恢复和业务连续性，适用于有跨地域或特定分离距离要求的应用。

多区部署依赖于跨可用区的应用感知数据复制，并支持主动-主动和主动-备用架构模式。 多区域、多地区部署支持具有持续可用性和始终在线要求的企业应用程序的架构模式。 下表显示了不同部署选项的比较和建议使用方法。

高可用性部署建议
部署 可用性 描述 建议使用
单专区 99.9%
  • 一个区域中的多个计算实例
  • 防止基础设施故障
  • 低成本/中等成本
  • 中低优先级应用
  • 非关键生产工作负载
多区、单区域 99.99%
  • 跨 2 个或更多可用性区域的多个计算实例
  • 跨区域同步数据复制
  • 防止区域中断
  • 中/高成本
  • 核心业务应用程序
  • 具有严格弹性要求的生产级工作负载
  • 具有国家边界或地理数据居住地限制的业务连续性政策
多区、多区域

99.99%
  • 跨 2 个或更多区域的多个可用性区域的多个计算实例
  • 区域间异步数据复制
  • 防止区域中断
  • 高成本
  • 具有持续或接近持续可用性要求的关键任务应用
  • 具有跨地域或特定分离距离要求的业务连续性政策
  • 灾难恢复

以下架构框架提供了在 IBM Cloud Virtual Private Cloud (VPC) 基础架构上部署弹性应用程序的设计考虑因素和架构决策。 它涵盖以下解决方案方面和领域：

  • 网络负载平衡、域名系统
  • 安全性： 数据安全
  • 恢复能力高可用性、备份和恢复、灾难恢复
  • 服务管理： 监控、日志、审计、警报

VPC 弹性架构设计范围
VPC 弹性架构设计范围

架构设计框架 通过解决一系列方面和领域的需求，为设计云解决方案提供了一致的方法。 这些领域是任何企业解决方案（无论采用何种技术）都需要考虑的架构领域。

高可用性应用程序的客户端重试逻辑

您有责任构建能有效处理临时错误的客户端程序。 临时错误包括网络错误和服务高可用性实施带来的临时故障，如区域服务从分区故障中恢复。 有关特定 IBM Cloud 服务的更多信息，请参阅 高可用性和灾难恢复的服务文档。

许多 IBM Cloud SDK 都建立在支持自动重试的 IBM Cloud SDK 通用 上，自动重试旨在处理特定的 HTTP 错误，如 429 和 503 错误。 SDK 不会自动处理所有错误。 要利用重试逻辑，必须正确配置 SDK。

某些 IBM Cloud 服务支持开源协议，因此可以使用开源 SDK。 检查这些 SDK，以确定它们是否对您的应用程序有用，并提供合适的重试功能。

重试逻辑因 IBM Cloud 服务类型和操作类型而异。 一些失败的操作会产生重试友好的状态代码，而另一些操作则不会产生重试友好的状态代码。 失败的读取和 HTTP GET 操作一般可通过使用固定时间段的指数回退进行重试。 指数后退是一种重试策略，用于管理操作（如网络请求或 API 调用）失败后的重试。 它以指数模式逐渐增加重试之间的延迟，从而降低了系统超载的风险。 应重试的故障取决于故障类型和特定的 IBM Cloud 服务。 更多信息，请参阅各 IBM Cloud 服务 SDK 和文档。

失败的写入、HTTP PUT、POST、DELETE 和其他操作很可能无法通过简单的重试机制恢复，除非很明显操作没有完成，并且记录的客户端逻辑表明重试是合适的。 当改变系统状态的操作（如创建资源）失败时，往往不清楚失败的原因。 由于存在这种不确定性，因此不能依靠简单的重试逻辑来解决问题。 请使用专为 IBM Cloud 服务设计的更高级方法。

客户端重试可提高单个客户端的可用性，而工作负载可能由多个客户端组成。 将客户端故障记录到 IBM Cloud Logs 等集中式日志服务中，可对整个工作负载进行故障和可用性分析。