17、云服务灾难恢复策略全解析

rust6ferris

于 2025-10-08 15:40:54 发布

阅读量105

点赞数

CC 4.0 BY-SA版权

分类专栏：云架构：从理论到实践文章标签：云服务灾难恢复 IaaS

本文链接：https://blog.youkuaiyun.com/rust6ferris/article/details/153112122

云架构：从理论到实践专栏收录该内容

21 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

云服务灾难恢复策略全解析

在当今的科技时代，技术故障是不可避免的。尤其是在分布式环境中，如许多基于云的解决方案，系统的任何部分都可能随时出现故障。应对这些故障的关键在于提前做好规划，设计出能够抵御各种故障的系统。接下来，我们将深入探讨云服务不同模式下的灾难恢复策略。

1. 灾难恢复的关键考量因素

在制定灾难恢复策略时，需要从业务角度考虑三个重要变量：
- 恢复时间目标（RTO） ：指业务要求服务恢复并重新运行的时间。例如，高流量的电子商务网站，每一分钟的停机都可能导致数千美元的损失，其RTO可能设定为五分钟或更短。而公司的报告系统，由于对收入和客户满意度的影响较小，在灾难发生时，其RTO可能为几天甚至一周。
- 恢复点目标（RPO） ：即可以容忍的数据丢失时间。以电子商务系统为例，处理金融交易的部分对数据丢失的容忍度通常为零或接近零。而具有社交功能的部分，公司可能能够容忍较长时间的数据丢失。
- 价值：衡量公司为减轻灾难情况所投入的价值。这受到多种因素的影响，例如：
- 客户因素 ：云服务的客户会极大地影响恢复的价值。当数字激励平台最初推出时，面对小型家族杂货店客户，“足够好”的恢复方案（在一两个小时内恢复到另一个可用区）就足够了。但当与顶级零售商合作时，就需要实时恢复，这促使公司投资建设跨多个可用区的完全冗余虚拟数据中心。
- 服务关键性 ：如果服务对患者的生命或公民的安全至关重要，恢复的价值可能非常高。此外，公众认知也会影响服务的关键性。例如，在互联网音乐领域竞争的公司，如果被认为比其他公司更不可靠，将极难竞争。

公司应针对架构的每个功能区域确定RTO、RPO和恢复价值，这些值将指导IT部门的投资，以提供适当的恢复水平。

2. IaaS灾难恢复策略

基础设施即服务（IaaS）的灾难恢复策略比平台即服务（PaaS）和软件即服务（SaaS）更为复杂，因为云服务消费者（CSC）负责应用程序栈，而公共IaaS解决方案中，CSC依赖云服务提供商（CSP）管理物理数据中心。以下是一些应对IaaS灾难的策略：
- 跨区域冗余 ：亚马逊等公共IaaS云提供商多年来都经历过服务中断。亚马逊有区域和可用区，历史上AWS的中断通常发生在单个可用区。构建跨多个可用区的冗余可以在AWS出现故障时保持系统正常运行。但有时API故障可能影响多个区域，例如亚马逊弹性块存储（EBS）出现问题时，跨区域冗余可以解决这一问题。不过，跨区域冗余比跨可用区冗余更复杂和昂贵，需要平衡成本与业务确定的恢复价值、RTO和RPO。
- 混合云解决方案 ：
- 与亚马逊合作 ：可以利用支持亚马逊API的私有云供应商，如Eucalyptus。但需要注意，Eucalyptus仅支持AWS提供给客户的部分API。为了使系统的所有部分都可恢复，架构师应限制使用Eucalyptus平台支持的AWS API。
- Rackspace ：提供公共和私有IaaS功能，可以使用开源云软件（如Open Stack）创建混合云解决方案，在公共云和私有云运行相同的云软件，私有云可以位于任何数据中心。
- 利用多个公共云供应商 ：要有效利用多个公共云供应商，系统的构建不能依赖于特定的IaaS供应商。这说起来容易做起来难，因为AWS等IaaS提供商提供的大量API可以快速构建应用程序。为了实现云无关性，需要避免使用专有API，或者隔离调用IaaS API的代码区域，并设计逻辑来检测使用哪个IaaS供应商并执行相应的API。最好的方法是在两个公共IaaS提供商中使用开源云解决方案（如Open Stack）。

许多公司认为在AWS可用区之间构建冗余是足够的灾难恢复策略，但需要注意的是，即使AWS区域有多个可用区，它们仍位于同一大致位置。如果发生重大灾难，所有可用区都可能受到影响。

3. 主数据中心灾难恢复方法

下面是这四种恢复方法的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{选择恢复方法}:::decision
    B -->|经典备份和恢复方法| C(创建备份并存储):::process
    C --> D(出现灾难时恢复备份):::process
    B -->|主动 - 被动冷备| E(准备脚本):::process
    E --> F(灾难发生时执行脚本创建服务器):::process
    F --> G(恢复数据库和其他服务器):::process
    B -->|主动 - 被动热备| H(数据库始终同步):::process
    H --> I(灾难发生时启动其他服务器):::process
    B -->|主动 - 主动热备| J(数据库主 - 从复制):::process
    J --> K(主数据中心故障时切换主数据库):::process
    K --> L(故障数据中心恢复后同步数据):::process
    D --> M([结束]):::startend
    G --> M
    I --> M
    L --> M

4. PaaS灾难恢复策略

公共PaaS中，整个平台（包括应用程序栈和基础设施）由供应商负责，消费者负责在平台上构建的应用程序。公共PaaS的优势是抽象了底层基础设施和应用程序栈的管理工作，使开发人员能够专注于业务需求。但缺点是，灾难发生时，消费者只能依赖PaaS供应商的灾难恢复计划，对于关键任务应用程序，这可能难以接受。例如，AWS可用区出现问题时，可能导致Heroku等公共PaaS提供商的服务中断，开发人员对此感到沮丧。

如果依赖公共PaaS进行灾难恢复风险过高，私有PaaS提供商是不错的选择。私有PaaS中，供应商抽象开发平台，使应用程序栈的安装和管理变得简单和自动化，但消费者需要管理基础设施。这看似不利，但在灾难发生时，消费者可以控制物理或虚拟基础设施。

公共PaaS的最佳灾难恢复策略是选择允许PaaS平台在任何数据中心（无论是本地还是公共云）运行的供应商。开源解决方案（如Red Hat的OpenShift和Cloud Foundry）提供混合云解决方案，消费者可以将这些PaaS解决方案安装在公共IaaS（如AWS或Rackspace）和本地数据中心。公共IaaS数据中心和私有IaaS数据中心都可以运行各种工作负载，并在主数据中心出现故障时作为二级数据中心。前面提到的四种恢复方法也适用于私有或混合PaaS场景。

5. SaaS灾难恢复策略

许多消费者没有考虑SaaS解决方案的灾难恢复策略，这可能在灾难发生时导致严重的业务影响。对于SaaS解决方案，如果数据或业务流程至关重要，必须制定在服务不可用时的运营计划。
- 软件托管 ：SaaS合同应包含软件托管条款，以保护买家在SaaS供应商倒闭或被收购并终止现有合同时的权益。软件托管将供应商的知识产权存放在独立第三方的托管区域，在特定情况下可以释放给买家，使买家拥有数据所有权。
- 手动流程 ：企业应记录并实践手动流程，以应对关键SaaS功能的重大中断。
- 使用多个SaaS供应商 ：在某些情况下，可以使用两个不同的SaaS供应商来防止服务中断。例如，电子商务网站可以使用两个SaaS解决方案，一个作为主要解决方案，另一个作为热备份。由于大多数SaaS解决方案按交易收费，热备份方法的成本并不高。

综上所述，不同的云服务模式（IaaS、PaaS、SaaS）在灾难恢复方面都有各自的挑战和策略。公司应根据自身业务需求、数据重要性和恢复价值，选择合适的灾难恢复策略，以确保在面对灾难时能够快速、有效地恢复服务。

云服务灾难恢复策略全解析（续）

6. 不同云服务模式灾难恢复策略对比

7. 灾难恢复策略选择流程

在选择合适的灾难恢复策略时，可以按照以下mermaid流程图进行：

graph TD
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{确定云服务模式}:::decision
    B -->|IaaS| C{评估恢复价值、RTO、RPO}:::decision
    C -->|高价值、低RTO、低RPO| D(选择主动 - 主动热备或跨区域冗余):::process
    C -->|中等价值、中等RTO、中等RPO| E(选择主动 - 被动热备或混合云方案):::process
    C -->|低价值、高RTO、高RPO| F(选择经典备份和恢复方法或主动 - 被动冷备):::process
    B -->|PaaS| G{评估对恢复的控制需求}:::decision
    G -->|控制需求高| H(选择私有PaaS或混合云PaaS):::process
    G -->|控制需求低| I(依赖公共PaaS供应商恢复计划):::process
    B -->|SaaS| J{评估数据和业务流程重要性}:::decision
    J -->|非常重要| K(采用软件托管、手动流程和多供应商策略):::process
    J -->|较重要| L(采用软件托管和手动流程):::process
    J -->|一般重要| M(关注供应商恢复计划):::process
    D --> N([结束]):::startend
    E --> N
    F --> N
    H --> N
    I --> N
    K --> N
    L --> N
    M --> N

8. 关键要点总结

明确关键变量 ：在进行灾难恢复规划时，要明确恢复时间目标（RTO）、恢复点目标（RPO）和恢复价值这三个关键变量，它们将指导后续策略的选择和投资决策。
IaaS策略考量 ：对于IaaS，可根据实际情况选择跨区域冗余、混合云解决方案或利用多个公共云供应商。同时，针对主数据中心的灾难，有经典备份和恢复、主动 - 被动冷备、主动 - 被动热备和主动 - 主动热备四种常见恢复方法，需根据恢复价值和时间要求进行选择。
PaaS应对方式 ：公共PaaS在灾难恢复时消费者缺乏控制权，可考虑私有PaaS或混合云PaaS方案，以增加对恢复过程的控制。
SaaS保障措施 ：对于SaaS，要确保合同中有软件托管条款，同时记录和实践手动流程，必要时使用多个SaaS供应商来保障服务的连续性。

通过遵循以上策略和流程，企业可以更好地应对云服务中的各种灾难情况，保障业务的稳定运行。在实际应用中，企业还需要根据自身的发展和变化，不断调整和优化灾难恢复策略，以适应不同阶段的需求。