你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
针对冗余进行设计的建议
适用于此 Azure Well-Architected 框架可靠性清单建议:
RE:05 | 在不同级别添加冗余,尤其是对于关键流。 根据确定的可靠性目标,将冗余应用于计算、数据、网络和其他基础结构层。 |
---|
相关指南:使用可用性区域和区域进行高可用性多区域设计 |
本指南介绍在不同工作负荷层上在整个关键流中添加冗余的建议,以优化复原能力。 通过将适当级别的冗余应用于计算、数据、网络和其他基础结构层,满足定义的可靠性目标的要求。 应用此冗余,为工作负载提供坚实可靠的基础。 在没有基础结构冗余的情况下构建工作负载时,可能会因 潜在故障而延长停机时间。
定义
术语 | 定义 |
---|---|
冗余 | 工作负载组件的多个相同实例的实现。 |
多语言持久化 | 通过同一应用程序或解决方案使用不同的存储技术来利用每个组件的最佳功能的概念。 |
数据一致性 | 给定数据集在多个存储中同步或不同步的度量值。 |
分区 | 以物理方式将数据划分为单独的数据存储的过程。 |
分片 | 支持具有通用架构的多个存储实例的水平数据库分区策略。 数据不会在所有实例中复制。 |
关键设计策略
在可靠性方面,使用冗余来包含影响单个资源的问题,并确保这些问题不会影响整个系统的可靠性。 使用你确定的有关关键流和可靠性目标的信息,做出每个流冗余所需的明智决策。
例如,你可能同时运行多个 Web 服务器节点。 如果存在影响整个池的问题(例如区域性服务中断),则它们可能要求所有流都具有准备好接受流量的副本。 或者,由于大规模问题很少见,并且部署整个副本集的成本很高,因此可以部署有限数量的副本,以便流在解决问题之前以降级状态运行。
在性能效率的上下文中设计冗余时,请将负载分散到多个冗余节点,以确保每个节点都以最佳方式执行。 在可靠性方面,构建备用容量以吸收影响一个或多个节点的故障或故障。 确保备用容量可以在恢复受影响节点所需的整个时间内吸收故障。 考虑到这一区别,这两种策略需要协同工作。 如果为了提高性能,将流量分散到两个节点,并且它们都以 60% 的利用率运行,而一个节点发生故障,则剩余节点将面临不堪重负的风险,因为它无法以 120% 的速度运行。 使用另一个节点分散负载,以确保维持性能和可靠性目标。
权衡:
- 工作负载冗余越多,成本就越多。 请仔细考虑添加冗余,并定期查看体系结构,以确保管理成本,尤其是在使用过度预配时。 将过度预配用作复原策略时,请将其与定义完善的 缩放策略 进行平衡,以最大程度地降低成本效率。
- 在高度冗余中生成时,可能会有性能权衡。 例如,跨可用性区域或区域分布的资源可能会影响性能,因为必须通过冗余资源(如 Web 服务器或数据库实例)之间的高延迟连接发送流量。
- 同一工作负载中的不同流可能具有不同的可靠性要求。 特定于流的冗余设计可能会给整体设计带来复杂性。
冗余体系结构设计
设计冗余体系结构时,请考虑两种方法:主动-主动或主动-被动。 根据基础结构组件支持的用户流和系统流的重要性选择方法。 在可靠性方面,多区域主动-主动设计可帮助你实现最高级别的可靠性,但与主动-被动设计相比,它的成本要高得多。 确定适当的地理区域将成为下一个关键选择。 还可以通过使用可用性区域将这些设计方法用于单个区域。 有关详细信息,请参阅 针对高可用性多区域设计的建议。
部署标记和缩放单元
无论是在主动-主动还是主动-被动模型中部署,都遵循 部署标记设计模式 ,以确保以可重复、可缩放的方式部署工作负载。 部署标记是将工作负荷交付给给定客户子集所需的资源分组。 例如,子集可以是区域子集,也可以是具有与工作负载相同的数据隐私要求的子集。 将每个缩放单元视为可以复制的 缩放单元 ,以便水平缩放工作负荷或执行蓝绿部署。 使用部署标记设计工作负载,以优化主动-主动或主动-被动实现,提高复原能力和管理负担。 规划多区域横向扩展对于克服区域中潜在的临时资源容量限制也很重要。
Azure 区域中的可用性区域
无论是部署主动-主动还是主动-被动设计,都利用主动区域中 的可用性区域 来充分优化复原能力。 许多 Azure 区域提供多个可用性区域,这些区域是一个区域内独立的数据中心组。 根据 Azure 服务,可以通过跨区域冗余地部署工作负载元素或将元素固定到特定区域来利用可用性区域。 有关详细信息,请参阅 使用可用性区域和区域的建议。
基础结构层指南
计算资源
为工作负载选择适当的 计算服务 。 根据你设计的工作负载类型,可能有多个可用选项。 研究可用的服务,并了解哪些类型的工作负载在给定的计算服务上效果最佳。 例如,SAP 工作负载通常最适合基础结构即服务 (IaaS) 计算服务。 对于容器化应用程序,请确定需要控制的特定功能,以确定是使用 Azure Kubernetes 服务 (AKS) 还是平台即服务 (PaaS) 解决方案。 云平台完全管理 PaaS 服务。
如果要求允许,请使用 PaaS 计算选项。 Azure 完全管理 PaaS 服务,可减轻管理负担,并内置了记录的冗余程度。
如果需要 (VM) 部署虚拟机,请使用 Azure 虚拟机规模集。 使用 虚拟机规模集,可以跨可用性区域自动均匀分布计算。
使计算层 保持任何状态的清洁 ,因为随时可能会删除、出错或替换处理请求的单个节点。
尽可能使用区域冗余服务,在不增加操作负担的情况下提供更高的复原能力。
过度预配关键资源以缓解冗余实例的故障(甚至在自动缩放操作开始之前),因此系统在组件故障后继续运行。 将过度预配合并到冗余设计中时,计算故障的可接受效果。 与冗余决策过程一样,可靠性目标和财务权衡决策决定了通过过度预配添加备用容量的程度。 过度预配是指 横向扩展,这意味着添加给定计算资源类型的额外实例,而不是增加任何单个实例的计算功能。 例如,如果将 VM 从较低层 SKU 更改为较高层 SKU。
在要在其中实现解决方案的每个可用性区域或区域中手动或通过自动化部署 IaaS 服务。 某些 PaaS 服务具有跨可用性区域和区域自动复制的内置功能。
数据资源
确定工作负荷的功能是否需要同步或异步数据复制。 为了帮助你做出此决定,请参阅 有关使用可用性区域和区域的建议。
考虑数据的增长率。 对于容量规划,请规划数据增长、数据保留和存档,以确保在解决方案中的数据量增加时满足可靠性要求。
根据服务支持,按地理位置分发数据,以最大程度地减少地理上本地化故障的影响。
跨地理区域复制数据,为区域性中断和灾难性故障提供复原能力。
在数据库实例发生故障后自动执行故障转移。 可以在多个 Azure PaaS 数据服务中配置自动故障转移。 支持多区域写入的数据存储(如 Azure Cosmos DB)不需要自动故障转移。 有关详细信息,请参阅 设计灾难恢复策略的建议。
为数据使用最佳 数据存储 。 采用多语言持久性或混合使用数据存储技术的解决方案。 数据不仅包括持久化的应用程序数据。 还包括应用程序日志、事件、消息和缓存。
考虑数据一致性要求,并在要求允许时使用 最终一致性 。 分发数据时,使用适当的协调来强制实施强一致性保证。 协调可能会降低吞吐量并使系统紧密耦合,从而使其更加脆弱。 例如,如果某个操作更新两个数据库,而不是将其放入单个事务范围,则最好是系统能够适应最终一致性。
将数据分区以实现可用性。 数据库分区 可提高可伸缩性,还可以提高可用性。 如果一个分片出现故障,其他分片仍可访问。 一个分片中的故障只会中断总事务的子集。
如果无法选择分片,可以使用 命令和查询责任分离 (CQRS) 模式 来分隔读写和只读数据模型。 添加更多冗余只读数据库实例以提供更高的复原能力。
了解所使用的有状态平台服务的内置复制和冗余功能。 有关有状态数据服务的特定冗余功能,请参阅 相关链接。
网络
确定可靠且可缩放的网络拓扑。 使用中心辐射型模型或 Azure 虚拟 WAN模型来帮助以逻辑模式组织云基础结构,使冗余设计更易于生成和缩放。
选择适当的 网络服务 以平衡和重定向区域内或跨区域的请求。 尽可能使用全局或区域冗余负载均衡服务来满足可靠性目标。
确保在虚拟网络和子网中分配了足够的 IP 地址空间,以考虑计划的使用情况,包括横向扩展要求。
确保应用程序可以在所选应用程序托管平台的端口限制内缩放。 如果应用程序启动多个出站 TCP 或 UDP 连接,它可能会耗尽所有可用端口,并导致应用程序性能不佳。
选择 SKU 并配置可满足带宽和可用性要求的网络服务。 VPN 网关的吞吐量因 SKU 而异。 区域冗余的支持仅适用于某些负载均衡器 SKU。
确保构建用于处理 DNS 的设计侧重于复原能力并支持冗余基础结构。
Azure 便利化
Azure 平台通过以下方式帮助你优化工作负载的复原能力和增加冗余:
通过许多 PaaS 和软件即服务提供内置冗余, (SaaS) 解决方案,其中一些解决方案是可配置的。
允许使用 可用性区域 和区域间冗余来设计和实现区域内冗余。
提供副本 (replica) 感知负载均衡服务,例如 Azure 应用程序网关、Azure Front Door 和 Azure 负载均衡器。
为 Azure SQL 数据库提供易于实现的异地复制解决方案,例如活动异地复制。 使用 Azure Cosmos DB 实现 全局分发 和透明复制。 Azure Cosmos DB 提供了两个用于 处理冲突写入的选项。 选择最适合工作负荷的选项。
为许多 PaaS 数据服务提供时间点还原功能。
通过 Azure NAT 网关或Azure 防火墙缓解端口耗尽问题。
特定于 DNS 的 Azure 辅助功能
对于内部名称解析方案,请使用具有内置区域冗余和异地冗余的 Azure DNS 专用区域。 有关详细信息,请参阅 Azure DNS 专用区域复原。
对于外部名称解析方案,请使用具有内置区域冗余和异地冗余的 Azure DNS 公共区域。
公共和专用 Azure DNS 服务是可复原区域中断的全局服务,因为区域数据在全球可用。
对于本地和云环境之间的混合名称解析方案,请使用 Azure DNS 专用解析程序。 如果工作负荷位于支持可用性区域的区域中,则此服务支持区域冗余。 区域范围的中断不需要在区域恢复期间执行任何操作。 该服务会自动自我愈合和重新平衡,以利用正常区域。 有关详细信息,请参阅 Azure DNS 专用解析程序中的复原能力。
若要消除单一故障点并跨区域实现更具弹性的混合名称解析,请跨不同区域部署两个或多个 Azure DNS 专用解析程序。 在条件转发方案中,DNS 故障转移是通过分配解析程序作为主 DNS 服务器来实现的。 将不同区域中的另一个解析程序分配为辅助 DNS 服务器。 有关详细信息,请参阅 使用专用解析程序设置 DNS 故障转移。
示例
有关多区域冗余部署的示例,请参阅 基线高可用性区域冗余 Web 应用程序。
下图显示了另一个示例:
相关链接
若要详细了解冗余,请参阅以下资源:
可靠性清单
请参阅完整的一组建议。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈