维持业务持续性对于企业至关重要, 关键业务系统宕机可能会对企业带来重大影响，企业声誉、客户满意度或公司的财务的状况都可能受到难于挽回的重大损失。 因此，构建高可用高容灾的IT系统和建设IT灾备系统，具有显而易见的价值。 在灾备解决方案的选定上，企业需要先制定好两个重要指标：恢复时间RTO（故障恢复时间），和恢复点RPO（可忍受数据损失的时间点）。基于这两个关键业务指标，企业 IT部门可以设计相应的应用架构、备份架构和灾备体系，通过使用一系列镜像/快照等技术手段，来实现相应系统的连续性服务水平。 在传统做法中，实施较高要求的容灾和灾备系统，往往不光要求企业花费大量时间和精力，而且部署复杂且价格昂贵。这对于多数企业，特别是中小型企业，都是一个巨大的负担。使用公有云的 基础设施来实现数据保护、备份归档和灾难备份，拥有传统IT无法比拟的巨大优势。 本文首先对灾备的基本概念做概况介绍，之后将利用wordpress模板模拟经典web hosting架构的应用场景，给出基于AWS的不同指标的4种备份/灾备方案，并做关键指标的对比。 本文概括介绍了在AWS上搭建容灾备份系统的四大方案。每一种方案都给出了具体的解决方案、架构图、成本估算、具体执行步骤 和 自动化脚本。 企业可结合自己对应用系统PTO和PRO的要求以及成本预算，选择适合自己的灾备方案。

 

本文目录

  1. 关键指标 RPO & RTO
  2. 灾备类型
  3. 模拟内容
  4. AWS 组件的计费模型
  5. 不同场景下的解决方案
  6. 脚本下载
  7. 总结

关键指标 RPO & RTO

  1. RTO (Recovery Time Objective，复原时间目标)是指灾难发生后，从IT系统当机导致业务停顿之时开始，到IT系统恢复至可以支持 各部门运作、恢复运营之时，此两点之间的时间段称为RTO。比如说灾难发生后半天内便需要恢复，RTO值就是十二小时。
  2. RPO (Recovery Point Objective，复原点目标)是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，恢复得来 的数据所对应时的间点。如果现时企业每天凌晨零时进行备份一次，当服务恢复后，系统内储存的只会是最近灾难发生前那个凌晨零时的资料。
  3. 该图解释了 RTO 和 RPO 与时间轴的关系。 
 

灾备类型

不同的业务对于 RPO 和 RTO 的要求也不同。根据不同的要求，我们大概可以将灾备归类 Cold Backup , Pilot Light , Warm Standby 和 Hot Site. 以下将介绍四种灾备类型的架构设计和灾中切换过程。

  1. Cold Backup是指定期导出并上传业务数据；当灾难发生时，启动数据层和应用层资源，并导入数据。 例如 MySQL 利用 mysqldump 工具进行定期的全量备份或增量备份。
  2. Pilot Light 是指实时异步复制业务数据；当灾难发生时，启动应用层资源。  
  3. Warm Standby是指实时复制业务数据，应用层保持小规模资源配置；当灾难发生时，迅速扩大应用层资源。 
  4. Hot Site是指实时同步/异步双向复制业务数据，应用层资源保持一定规模的配置，DNS 按权重 解析到两个站点；当灾难发生时，DNS解析到单个站点, 并迅速扩大应用层资源。 

不同的备份方式所产生的成本也不同，以下是4种类型适合业务类型和成本对比:

 

Cold

Pilot Light

Warm

Hot Standby

用户场景非核心业务关键业务核心业务核心业务不受影响, 自动恢复
RTO & RPO 要求天小时级分钟级秒级
成本$$$$$$
 

模拟内容

本专题是模拟一个典型的Web Hosting 场景，即 WordPress Cluster 在不同场景下进行不同类型的备份。通过此模拟场景，提供 不同场景下，不同类型的灾备 解决方案、架构图、成本估算、 执行步骤 和 自动化脚本 。 我们假设 WordPress Cluster 组件如下：

  • MySQL: WordPress 数据库
  • Redis: 使用 Redis Object Cache 插件，使得 WordPress 支持Redis 作为缓存，提高用户访问体验
  • 共享存储: WordPress 的文件存储在共享存储上，每一台 WordPress 实例都可以访问相同的共享存储
  • 应用服务器: 安装 WordPress 应用
  • 负载均衡: 将接收到的流量转发给后端的 WordPress 集群

不同类型的备份所需策略也不同。上述 WordPress Cluster 场景，只有 MySQL 和 WordPress 文件存储内有持久化数据，将迁移的大致策略归纳总结如下：

 

备份策略

灾前准备工作

灾中切换

Cold1. 定期备份MySQL 2. 定期备份Wordpress文件1. 在灾备环境准备好网络等基础服务 2. 自动化启动数据层，应用层脚本1. 启动数据库，文件存储 2. 导入数据 3. 启动应用层 4. DNS 解析到灾备区域
Pilot Light1. 开启MySQL 只读副本 2. 异步持续备份WordPress 存储文件1. 在灾备环境准备好网络等基础服务 2. MySQL 只读部分，存储文件备份 3. 自动化启动应用层脚本1. 提升MySQL 只读副本为主库 2. 启动应用层 3. DNS 解析到灾备区域
Warm Standby1. 开启MySQL 只读副本 2. 异步持续备份WordPress 存储文件1. 在灾备环境准备好网络等基础服务 2. MySQL 只读部分，存储文件备份 3. 自动化启动应用层脚本 4. 启动小规模应用层1. 提升MySQL 只读副本为主库 2. 提升应用层规模 3. DNS 解析到灾备区域
Hot Standby1. MySQL 设置成互为主备 2. WordPress 存储文件双向拷贝1. 在灾备环境准备好网络等基础服务 2. MySQL 设置成互为主备模式 3. WordPress 文件双向拷贝 4. 启动应用层 5. DNS 根据预先设置的策略解析到两个站点1. 故障发生时，DNS 解析到单个站点
 

AWS 组件的计费模型

在模拟场景中将使用到一些 AWS 的常见服务，其计费模型如下:

功能

资源

费用说明

Web层ELB在灾备区按用量收费
EC2根据实际使用的类型按灾备区定价收费
EC2 AMI如果您使用由实例存储提供支持的 AMI，您需要为实例使用和在 Amazon S3 中存储 AMI 付费。使用由 Amazon EBS 支持的 AMI，您需要为实例使用、Amazon EBS 卷的存储和使用、以 Amazon EBS 快照形式存储 AMI 付费。
EBS快照按EBS的快照存储大小收费
EBS 卷单独使用的EBS卷的容量费用
应用层ELB在灾备区按用量收费
EC2根据实际使用的类型按灾备区定价收费
EC2 AMI如果您使用由实例存储提供支持的 AMI，您需要为实例使用和在 Amazon S3 中存储 AMI 付费。使用由 Amazon EBS 支持的 AMI，您需要为实例使用、Amazon EBS 卷的存储和使用、以 Amazon EBS 快照形式存储 AMI 付费。
EBS快照按EBS的快照存储大小收费
EBS 卷单独使用的EBS卷的容量费用
缓存层Redis 备份文件ElastiCache 允许您免费为每个活动 Redis 集群存储一个备份。对于所有区域，其他备份的存储空间按每月 0.085 美元/GB 的费率收费。对于创建备份或者将备份中的数据还原到 Redis 集群，没有数据传输费。拷贝到灾备区会产生备份文件存储费用<
数据库层数据库实例实例费用按使用的EC2类型收费
数据库存储按实际的数据量占用的空间收费
数据库快照当灾备的数据库进行备份或快照时会产生存储费用
S3对象存储文件存储服务根据存储量收取S3的存储费用
Internet流量数据流出到Internet费用按照云数据中心向Internet传输的流量计费，不限带宽
 

不同场景下的解决方案

根据原生产环境部署位置的不同，本文介绍相应的不同方案，比如AWS的多区域容灾，IDC到AWS的容灾，友商到AWS的容灾等。详细步骤请分别点击以下链接：

脚本下载

基于 WordPress Cluster 的设定场景，上述详细方案的执行脚本发布在 此GitHub Repo下。项目内有三个文件夹，basic, database, app 您可以根据需求修改具体参数，来满足对于业务持续性的需求。当做环境切换时，只需要一键启动此模板，即可轻松恢复生产环境。具体使用方法，请分别点击每篇文章查看。

总结

本文简述了常见的标准灾备方案，并在关键指标以及成本角度做了简单的对比。我们可以根据业务实际部署的情况，在AWS上选择适合自己的灾备方案。