设计备份和恢复
Tailwind Traders 等组织需要在他们的任务关键型应用中提供高度的可靠性。 为了实现本地应用所需的可靠性,通常需要购买更多的计算资源,例如服务器和存储。 购买更多的计算资源可以在本地基础结构中构建冗余。
在理想情况下,任何关键应用及其关联数据在发生故障后都能够恢复,这一点也至关重要。 这种可恢复性通常由备份、还原组件和过程提供。 对于在 Azure 中托管应用的组织或具有混合应用部署的组织而言,还有其他注意事项和选项。
可靠应用包括:
针对组件故障可复原。
具有高可用性,并且能够以正常状态运行,没有显著的故障时间。
若要实现所需的复原能力和高可用性,必须首先定义你的需求。
备注
本模块使用“复原能力”这一术语来描述系统妥善处理故障并且从故障中恢复的能力,包括意外发生的故障和恶意造成的故障。
定义要求
定义需求涉及以下方面:
确定你的业务需求。
构建你的复原计划以满足这些需求。
下表中的注意事项提供了有关此过程的指导。
注意事项 | 说明 |
---|---|
你有哪些工作负荷以及它们有哪些用途? | 从业务逻辑和数据存储要求的角度讲,工作负荷是逻辑上与其他任务截然不同的功能或任务。 对于可用性、可伸缩性、数据一致性和灾难恢复,每个工作负荷可能会有不同的需求。 |
工作负荷的使用模式是什么? | 使用模式可以确定你的需求。 确定关键时期和非关键时期内的需求差异。 为了确保运行时间,请跨多个区域计划冗余,以防一个区域发生故障。 相反,为了将非关键时期的成本降至最低,可以在单个区域中运行应用程序。 |
有哪些可用性指标? | 平均恢复时间 (MTTR) 和平均故障间隔时间 (MTBF) 是通常使用的指标。 MTBF 是指某个组件在两次中断之间按预期方式合理运行的持续时间。 MTTR 是指发生故障后,还原某个组件所需的平均时间。 使用这些指标来确定需要添加冗余的位置,并针对客户确定服务级别协议 (SLA)。 |
有哪些恢复指标? | 恢复时间目标 (RTO) 是指在某一事件后可以接受应用不可用的最长时间。 恢复点目标 (RPO) 是指发生灾难期间可接受数据丢失的最大持续时间。 还要考虑恢复级别目标 (RLO)。 此指标确定恢复的粒度。 换句话说,你是想必须能够恢复服务器场、Web 应用还是只恢复特定项即可。 若要确定这些值,请进行风险评估。 确保你了解组织中故障时间或数据丢失的成本和风险。 |
有哪些工作负荷可用性目标? | 为了帮助确保你的应用体系结构满足业务需求,请为每个工作负荷定义目标 SLA。 除了应用程序依赖关系以外,还应该考虑到满足可用性要求所需的成本与复杂性。 |
什么是你的 SLA? | 在 Azure 中,SLA 描述 Microsoft 在运行时间和连接性方面所做的承诺。 如果针对特定服务的 SLA 为 99.9%,则应该预期该服务在 99.9% 的时间内可用。 |
提示
如果高可用性方案中任何关键组件的 MTTR 超过了系统 RTO,那么系统中的故障可能会导致不可接受的业务中断。 换句话说,你无法在定义的 RTO 内还原系统。
通过回答上述问题,在你的解决方案中为每个工作负荷定义自己的 SLA。 这有助于确保体系结构满足你的业务需求。 例如,如果一个工作负荷需要 99.99% 的正常运行时间,但此工作负荷依赖于SLA 为 99.9% 的服务,则该服务不能是系统中的单一故障点。
定义恢复需求后,可以选择合适的恢复技术。