企业备份&容灾系列 — 使用AWS为本地数据中心实现Cold backup & Pilot light容灾解决方案

转自亚马逊AWS官方博客

该方案讲述了常见的企业IT基础架构及应用系统从On-premise环境到AWS云端的两种灾备场景。

SLA

Cold Backup RTO = 24小时, RPO = 24小时 

Pilot Light RTO = 4小时, RPO = 4小时

架构图

• 数据复制关系：其中黄色线条代表Cold backup复制，蓝色线条代表Pilot light复制 
• 网络：为了进行数据复制与同步，需要将本地IDC网络与云端VPC进行连接，采用以下选项：
  • VPN：使用托管VPN服务，通过互联网建立 Site to Site VPN 进行连接
  • 专线：使用Direct Connect服务进行专线连接，提供 1Gb 至 10Gb 带宽。亦可通过合作伙伴提供小于1Gb带宽的专线连接。
• 本地IDC基础架构:
  • VMware/Hyper-V:
    • Web服务器
    • 常见单机或2层架构办公系统，如OA
  • 物理服务器：
    • Redis
    • MySQL数据库
    • 文件服务器
• Pilot Light部分:
  • MySQL数据库

解决方案

非结构化数据服务：NAS（文件共享） 利用AWS Storage Gateway File Gateway模式来实现非结构化数据的同步与灾备

• 将Storage Gateway虚拟机镜像部署于本地 IDC VMWare 虚拟化平台
• 定期rsync将NAS服务器文件拷贝至Storage Gateway
• Storage Gateway自动将文件同步至S3存储桶
• 云端虚拟机使用s3fs将S3存储桶挂载至本机卷进行文件访问

结构化数据服务(MySQL数据库)

• Cold冷备份模式
  • 利用XtraBackup工具或者原生备份工具对MySQL数据库进行定时备份并备份文件上传至云端
• Pilot Light模式
  • 通过MySQL Binlog复制实现较好的RPO指标

Web服务器镜像

• 可将本地IDC中运行于vmware中的虚拟机导出成.ova格式，使用 ec2 import 命令行导入至云端
• 在应用简单的情况下也可在云端重新部署

常见单机办公系统或者2层架构，如OA等

• AWS SMS（Server Migration Services) 支持 VMware 与 Hyper-V 环境，可以使用SMS迁移目前虚拟环境当中的虚拟机直接到AWS平台中成为AMI
• 在AWS平台中可以方便使用AMI进行恢复或者进行灾难演练

云上快速恢复的脚本已经上传至 GitHub。

执行步骤:

1. 建立本地与云中的复制关系
   1. 数据库复制
      • Cold Backup
        • 安装 XtraBackup 工具，进行全量、增量备份及还原，具体步骤可参考
        • 将生成的备份文件存入NAS文件服务器
        • 由Storage Gateway同步至S3存储桶
      • Pilot Light
        • 配置步骤参考：Mysql主从复制搭建及详解
        • 开启本地MySQL服务器的Binlog
        • 开启本地MySQL服务器GTID
        • 配置云端RDS MySQL的主节点为本地MySQL服务器
        • 开始进行Binlog同步
   2. 使用VM Import方式进行镜像复制
      • 在 VMWare vSphere 中将虚拟机导出为OVF格式，参考 VMWare 在线文档
      • 将导出的 OVF 格式虚拟机及磁盘文件上传至S3存储桶
      • 使用 import-image 命令导入镜像及磁盘文件
   3. 在线虚拟机复制方式 – AWS SMS：
      • 参考以下文档，配置IAM Role权限
      • 在 on-premise 环境中 VSPHERE/HYPER-V 建立Connector
      • 对要容灾的 VM 进行设置，在控制台进行复制
   4. 非结构化数据复制
      • 使用 rsync 将 NAS 存储中数据定时同步至 Storage Gateway，进一步同步至S3, 参考文档
2. 故障切换，以具有 MySQL, Redis 环境为例
   1. 如果云中部署 AD，请将 Active Directory 切换 FSMO
   2. 将 RDS MySQL 由从节点更改为主节点，中断 Binlog 复制
   3. 启动 ElastiCache 集群
   4. 调整 Auto Scaling Group 节点数量启动 EC2 Web 服务器
   5. 调整应用配置
   6. 验证与测试
   7. 切换 DNS 记录
3. 内部系统故障切换，以SMS、VM Import等备份成AMI为例：
   1. 确保VPN，专线到AWS VPC畅通，以保证后续内部系统的访问
   2. 启动VM Import，SMS等系统的AMI
   3. 调整应用配置
   4. 对系统进行验证
   5. 切换DNS记录，使用容灾系统
4. 系统回切
   1. 确保和验证IDC与云上网络的连通性
   2. 等待Active Directory的数据同步，切换FSMO到本地Active Directory服务器
   3. 从RDS MySQL进行备份，恢复至本地数据中心
   4. 配置从RDS MySQL到本地MySQL的主从复制(GTID)
   5. 系统验证与测试
   6. 切换DNS记录
   7. 调整云端Web服务器数量
   8. 终止 ElastiCache 集群

成本分析

企业备份&容灾系列 – AWS 多区域 Cold Backup 容灾设计

本文详细介绍了如何在AWS上实现跨区域的冷备方案，可以在不增加额外闲置成本的情况下恢复因区域故障导致的生产宕机。在此套环境下，除了网络基础架构预配置外，只做数据定期快照向灾备环境拷贝，其余所有的组件都是灾难发生后通过脚本动态创建，一旦某个生产区域出现故障，用户通过预先定义好的灾备脚本做灾备切换，在灾备区域快速构建 AWS 资源恢复生产环境。

前提假设

该方案是模拟一个 WordPress cluster 部署在 AWS 上进行 multi-region pilot light 灾备的方案。生产区域组件选择如下。本文也提供了一键部署的模板可以用来进行方案验证。

• RDS MySQL: WordPress 数据库
• ElastiCache: 使用 Redis Object Cache 插件，使得 WordPress 支持Redis 作为缓存，提高用户访问体验
• S3: WordPress 的文件存储在 S3 上，通过 S3FS 软件挂载到EC2
• EC2: 安装 WordPress 应用，通过Auto Scaling Group 实现弹性伸缩
• ELB: 作为负载均衡，将接收到的流量转发给后端的 WordPress 集群
• NAT Gateway: WordPress 经由 NAT 网关主动访问外网

灾备架构

解决方案概述

为了实现冷备环境的搭建以及自动化启动，我们将分别从数据库，应用层，文件服务，自动化脚本这几个方面做展开。

数据库：snapshot备份

Amazon RDS 在数据库实例的备份窗口中创建数据库自动备份的事件, 可以发送到CloudWatch Event。自动化解决方案可以通过CloudWatch Rule定时触发Lambda, 调用AWS API定时进行数据库快照拍摄并将新创建的 Snapshot 自动拷贝到灾备区域。  Amazon RDS 创建数据库实例的存储卷快照，并备份整个数据库实例而不仅仅是单个数据库。可通过从该数据库快照还原来创建数据库实例。还原数据库实例时，需要提供用于还原的数据库快照的名称，然后提供还原后所新建的数据库实例的名称。无法从数据库快照还原到现有数据库实例；在还原时，将创建一个新的数据库实例。 

应用层：AMI备份

当北京区域新建AMI后，可以按时对实例进行快照拍摄，并将新建的AMI复制到宁夏区域。有两种方式可以实现AMI的复制。

• 手动触发复制过程 
• 通过脚本自动化整个过程。 在 CloudWatch Event 中设定时任务，触发 Lambda 捕捉某段时间内新建的AMI，通过简单的 AWS API 调用把新建的AMI复制到到宁夏区域。请根据项目实时性的需求为定时任务设定合适的执行频率。

应用层：应用配置

在EC2的启动配置中设置 user-data，使 EC2 内应用程序在启动后能够获取所需的配置，例如 RDS Mysql 和 Redis 的endpoint 等等。启动配置已经包含在灾难恢复的脚本中。

媒体文件：S3跨区域备份

静态文件及其它需要同步到灾备region的文件存放在S3上。开启S3 Cross Region Replication，实现S3文件的跨Region自动复制。S3 通过S3FS挂载到 EC2, 作为 WorkPress 媒体文件库。

灾备脚本

按照上述方案，在GitHub aws-dr-samples repo上提供了基于Terraform的可执行脚本，该套脚本可以帮助用户快速构建灾备环境。用户根据所需创建的资源写成脚本文件。执行脚本时，Terraform 通过调用 AWS API 来快速构建 AWS 资源。下文有如何使用的详细步骤描述。 在本方案中，设定Redis不包含持久化数据。因此无需实现复制，只需在灾难恢复时通过脚本创建新实例即可。 当灾难发生后，按照以下顺序进行灾难恢复：

1. 手动将RDS数据库快照还原为数据库实例.
2. 执行脚本创建容灾集群。
3. 进行健康检查，确定容灾集群能够正常运行。
4. 执行DNS切换，把用户访问切换到容灾集群。

接下来，我们会详细描述该方案的实施步骤和脚本运行执行过程。

价格

以宁夏区为例，按照上述灾备方案，假定需要的灾备资源及产生的费用为：

• AMI 20G: 镜像文件在宁夏区存储的费用
• S3 1T 不频繁访问：由于是灾备访问，平时不会被使用，推荐不频繁访问
• RDS Read Replica: 跨区域可读实例
• 跨区域网络传输 200G: 每月 200G S3 数据拷贝，含 WordPress 文件, AMI, DB Snapshot首次从北京区备份到宁夏区需要全量备份，会产生 1 TB 的流量费用，及 600.3 RMB.
  

  服务	类型	单价	1 年价格
  AMI 20G		0.277/GB/月	66.48
  S3 不频繁访问 1T		0.1030029/GB/月	1265.7
  跨区域流量 200 G		0.6003/GB	120.06
  		Total	1452.24
  		Total with tax	1539.3744

  以上仅做参考，实际配置情况，应该根据工作负载合理配置。

  terraform目录结构

  terraform脚本请点击此处获取。 项目内有三个文件夹，basic, database, app 。以下为此repo的目录说明。

  • basic: 基础结构。可用于构建基础网络架构, 基础安全配置等等。 包含如下资源：
    • VPC
    • Subnet (包含 public subnet, private subnet)
    • Security Group
    • DB Subnet Group
    • Cache Subnet Group
    • Route Table
  • database: 数据库架构。用于自动创建 RDS 实例。包含如下资源：
    • Database Parameter Group
    • Database 实例
  • app：应用相关资源。可用于自动构建缓存，应用及更新配置文件。包含如下资源:
    • Redis
    • Application Load Balancer
    • NAT
    • Route Table (给私有子网增加 NAT 路由)
    • Launch Template
    • Auto Scaling Group
    • Application Load Balancer
    • Listener, Target Group
    • 自动生成配置文件
    • S3FS 自动挂载到 EC2 作为 WordPress 的 Media Library

  准备工作

  1. 本文使用 AWS China Region, 如使用 AWS Global Region，需要修改镜像地址和 region 信息。
  2. 提前提升好 limits. 每一项 AWS 服务都有 limits，确保灾备切换时，能否启动足够的资源来支撑应用。
  3. 本文架构部署使用 Terraform 一键部署AWS 资源， 请在本机安装 Terraform, 并配置好AWS Credentials
  4. Terraform 可以将信息存储在 S3 和 DynamoDB 中，创建用于存储 Terraform 状态的 S3 Bucket和 DynamoDB Table（由于使用的很少，DynamoDB 建议使用 On-Demand 收费方式）, 该 DynamoDB 的 primary key 必须为 LockID，类型为 string。在本环境中，该 DynamoDB Table名称 为tf-state。请勿在生产环境部署灾备切换需要的 S3 bucket和DynamoDB指定的Table，防止 Region Down 之后，无法使用 Terraform。
  5. 在生产区域制作 AMI, 并拷贝到灾备区域。 出于演示的目的，已经提前在 AWS 中国区域部署了 WordPress 5.2.2 版本的AMI. WordPress 应用程序位 于 /var/www/html 目录下，可直接使用。
     • 北京区域 AMI: ami-0eebef1aaa174c852
     • 宁夏区域 AMI: ami-0cbbf10eaeaf0f9c3

     由于 WordPress 会记录域名，请勿使用ELB的域名直接访问, 为 WordPress 配置自定义域名。

  6. 将使用到的 SSL 证书提前导入 IAM。
  7. 修改 <project>/index.tf 和 <project>/variables.tf. <project>代表basic, database, app三个相应folder的泛指，请分别进行修改。
     • index.tf 是状态信息保存的地方, 需要使用到之前提到的 DynamoDB 和 S3。
     • variables.tf 是模板的变量, 根据实际情况修改。
  8. 配置好 AWS Credentials. 该 credentials 需要具备访问 S3, DynamoDB 及自动创建相关资源的权限。
  9. 中国大陆地区执行 terraform init 下载 aws provider 会比较慢，可提前手动下载, 并解压到<project>/.terraform/plugins/<arch>/ 目录下。<arch> 为本机的系统和CPU架构, 如 darwin_amd64, linux_amd64。 >>>点击此处手动下载 Terraform AWS Provider<<<

  详细步骤

  1. (可选)创建模拟生产环境

  Note: 如果对现有生产环境进行操作，直接跳过此步骤。

  该步骤创建模拟的生产环境，用于演示。可以选择手动创建，或者利用脚本快速创建。使用脚本的好处是， 在演示结束后，我们可以快速销毁演示环境。 创建基础环境

  1. 修改 basic/variables.tf 和 basic/index.tf
  2. 在 basic 目录下执行 terraform init
  3. 执行 terraform workspace new prod 创建 模拟生产环境的 workspace. 我们使用 workspace 来区分是模拟生产环境或者灾备环境
  4. 执行 terraform apply 创建基础网络环境

  创建数据库

  1. 修改 database/variables.tf 和 database/index.tf
  2. 在 database 目录下执行 terraform init
  3. 执行 terraform workspace new prod 创建 模拟生产环境的 workspace.
  4. 执行 terraform apply 创建数据库相关资源

  创建应用层

  1. 在模拟生产区域创建 S3 Bucket, 并启用 versioning 功能，用于存储 WordPress media 文件
  2. 修改 app/variables.tf 和 app/index.tf
  3. 在 app 目录下执行 terraform init
  4. 执行 terraform workspace new prod 创建模拟生产环境的 workspace
  5. 执行 terraform apply 创建APP相关资源

  2. 灾备环境准备工作

  我们需要提前在灾备环境创建基础网络架构，来使得灾难发生时可以快速切换。推荐使用脚本创建，这样可以提高自动化的水平。在使用以下脚本的时候注意参数的配置。 如果已经在第一步 创建模拟生产环境 中修改了 index.tf 文件，无需修改该文件。 拷贝镜像

  1. 手动操作方式：
     1. 在生产区域中选择 EC2, 创建镜像文件
     2. 拷贝的镜像文件, 拷贝到灾备区域
  2. 自动化方案：本方案中我们会自动按时进行镜像制作并拷贝到灾备区域
     1. 在Lambda创建界面，选择 从头开始创作，运行语言选择Python3.7。 在 权限 – 执行角色 中选择 创建具有基本Lambda权限的角色 
     2. 填入代码 在该Lambda函数界面中，将以下代码粘贴进函数代码中，并修改RDS相关参数： 

        import json
        import boto3
        import time
        
        def lambda_handler(event, context):
            # TODO implement
            clientEC2 = boto3.client('ec2')
            name='testami'+time.strftime("%Y-%m-%d-%H-%M-%S", time.localtime())
            instanceId = "i-07a15e9a0d139ee5f"
            response = clientEC2.create_image(
                InstanceId=instanceId,
                Name = name
            )
            ImageId=response['ImageId']
            time.sleep(60)
            clientbej = boto3.client('ec2','cn-north-1')
            newname='bejtestami'+time.strftime("%Y-%m-%d-%H-%M-%S", time.localtime())
            response = clientbej.copy_image(
                Name=newname,
                SourceImageId=ImageId,
                SourceRegion='cn-northwest-1'
            )
        
            return {
                'statusCode': 200,
                'body': json.dumps('Hello from Lambda!')
            }
        

     3. 添加iam role 权限在下方 执行界面 中，点击 查看your_iam_role角色 , 进入该角色的摘要中。 
     4. 在摘要界面中，选择 附加策略 ，AmazonRDSFullAcess。
     5. 添加触发器 在该Lambda函数界面，选择 添加触发器 
     6. 配置触发器 在 触发器配置 中，选择 CloudWatch Events，规则选择 创建新规则 ，规则类型选择 计划表达式，按规则填入(e.g. 每两小时则为rate(2 hours), 详情参见规则的计划表达式) 

  创建基础环境

  1. 修改 basic/dr.tfvars 和 basic/index.tf
  2. 在 basic 目录下执行 terraform init
  3. 执行 terraform workspace new dr 创建灾备环境的 workspace. 我们使用 workspace 来区分是模拟生产环境或者灾备环境
  4. 执行 terraform apply --var-file=dr.tfvars 创建基础网络环境

  开启 S3 Cross Region Replication 进行数据同步

  1. 在灾备区域中创建 S3 Bucket, 并启用 versioning 功能，用于备份 WordPress 的 Media 文件
  2. 利用 AWS CLI 将已存在的文件拷贝到灾备区域，aws s3 sync s3://SOURCE_BUCKET_NAME s3://TARGET_BUCKET_NAME
  3. 在 S3 Console 中选择生产区域的 S3 Bucket, 点击 Management, 选择 Replication
  4. 点击 Add Rule, 选择 Entire bucket, 并点击 Next
  5. 选择在灾备区域中选择的目标桶，点击 Next
  6. 在 IAM Role 中选择 Create new role, 输入 Rule name, 选择 Next。 
  7. 选择 Save 保存复制规则。

  开启 S3 Cross Region Replication 的更多资料，请参考这里。

  RDS 数据备份 RDS默认每24h在备份时段打一次快照，本章节介绍如何自定义备份时间间距（如每2h）并通过serverless的方式自动化打快照。

  1. 创建基础的Lambda 在Lambda创建界面，选择 从头开始创作，运行语言选择Python3.7。 在 权限 – 执行角色 中选择 创建具有基本Lambda权限的角色 
  2. 填入代码 在该Lambda函数界面中，将以下代码粘贴进函数代码中，修改参数：
  • 第四行 MAX_SNAPSHOTS : 您想保存最大的副本数量(最大100)
  • 第五行 DB_INSTANCE_NAME ：您想应用该脚本的RDS实例名称, 或者一组名称然后选择右上角 保存。

    import boto3
    import time
    def lambda_handler(event, context):
      MAX_SNAPSHOTS = 5
      DB_INSTANCE_NAMES = ['your_db_name']
      clientRDS = boto3.client('rds')
      for DB_INSTANCE_NAME in DB_INSTANCE_NAMES:
         db_snapshots = clientRDS.describe_db_snapshots(
             SnapshotType='manual',
             DBInstanceIdentifier= DB_INSTANCE_NAME
         )['DBSnapshots']
         for i in range(0, len(db_snapshots) - MAX_SNAPSHOTS + 1):
             oldest_snapshot = db_snapshots[0]
             for db_snapshot in db_snapshots:
                 if oldest_snapshot['SnapshotCreateTime'] > db_snapshot['SnapshotCreateTime']:
                     oldest_snapshot = db_snapshot
             clientRDS.delete_db_snapshot(DBSnapshotIdentifier=oldest_snapshot['DBSnapshotIdentifier'])
             db_snapshots.remove(oldest_snapshot)
         DBSnapshot=clientRDS.create_db_snapshot(
             DBSnapshotIdentifier=DB_INSTANCE_NAME + time.strftime("%Y-%m-%d-%H-%M-%S", time.localtime()),
             DBInstanceIdentifier=DB_INSTANCE_NAME
         )
         newarn=DBSnapshot['DBSnapshot']['DBSnapshotArn']
         bejclientRDS = boto3.client('rds','cn-north-1')
         time.sleep(180)
         response = bejclientRDS.copy_db_snapshot(
             SourceDBSnapshotIdentifier=newarn,
         TargetDBSnapshotIdentifier="rds_snapshot_bej"+ time.strftime("%Y-%m-%d-%H-%M-%S", time.localtime()),
         SourceRegion='cn-northwest-1'
         )
    

    直接使用可能会有缩进问题，建议在编译器当中先确保没有缩进问题之后再copy到lambda当中

  • 添加IAM Role权限 在下方 执行界面 中，点击 查看your_iam_role角色 , 进入该角色的摘要中。 在摘要界面中，选择 附加策略 ，AmazonRDSFullAcess。 
  • 添加触发器 在该Lambda函数界面，选择 添加触发器。 
  • 在触发器配置中，选择 CloudWatch Events，规则选择 创建新规则 ，规则类型 选择 计划表达式，按规则填入(e.g. 每两小时则为rate(2 hours), 详情参见规则的计划表达式) 

  修改灾备应用脚本启动参数

  1. 将跨区域只读库的 endpoint 更新到 app/dr.tfvars
  2. 修改 app/dr.tfvars, app/index.tf(如之前未修改)
  3. 在 app 目录下执行 terraform init
  4. 执行 terraform workspace new dr 创建灾备环境的 workspace.

  修改灾备脚本参数时，要谨慎核对参数。

  3. 故障转移

  强烈建议在完成数据同步之后，进行一次故障转移的演练。

  1. 创建基础环境
     1. 修改 basic/variables.tf 和 basic/index.tf
     2. 在 basic 目录下执行 terraform init
     3. 执行 terraform workspace new prod 创建 模拟生产环境的 workspace. 我们使用 workspace 来区分是模拟生产环境或者灾备环境
     4. 执行 terraform apply 创建基础网络环境
  2. 用快照还原数据库实例
     1. 在灾备区域将快照还原为实例 如下图点击还原快照 
     2. 在 Create DB instance页面，选择 Destination DB subnet group 为 db-group(在 basic 模板中自动创建) 
     3. 根据需要，vpc为DR(在 basic 模板中自动创建) 并根据需要选择instance class
     4. 在 Settings 中 DB instance identifier 中输入数据库实例名称
     5. 其他设置保持默认, 选择还原数据库实例，等待灾备区域的数据库实例启动完成
     6. 记录endpoint
     7. 由于我们需要手动修改数据库的安全组。在 RDS Console 选择进入数据库实例，选择右上角 Modify
     8. 在 Network & Security 选择 DB_SG(在 basic 模板中自动创建), 选择右下角 Continue 
     9. 在 Scheduling of modifications 选择 Apply immediately
     10. 选择 Modify DB Instance
  3. 创建灾备区域的应用层
     1. 修改灾备应用脚本启动参数 包括拷贝到备用区域的ami-id 新启用的数据库实例endpoint等 在dr.tfvar文件中
     2. 修改 app/dr.tfvars, app/index.tf(如之前未修改)
     3. 在 app 目录下执行 terraform init
     4. 执行 terraform workspace new dr 创建灾备环境的 workspace. 修改灾备脚本参数时，要谨慎核对参数。
     5. 执行app的terraform的创建
        • 在灾难发生后，执行故障转移, 请确保 app 目录下的 terraform workspace 是 dr。
        • 可以通过 terraform workspace list 来确认当前 workspace, 或者通过 terraform workspcae select dr来切换到 dr workspace。
     6. 执行 terraform apply --var-file=dr.tfvars 来启动资源
  4. 测试。功能测试应该在之前测试过，这里主要测试连通性
  5. 切换 DNS

  4. 灾后恢复

  灾后恢复请务必咨询架构师!!! 灾后的恢复工作非常重要，当灾难过后，需要制定好恢复的计划，执行脚本等等。灾后恢复的大致过程和 灾备切换 的过程相同。

  1. S3 的数据可以通过 AWS CLI Sync 命令来完成
  2. RDS 需要将原 region 的数据库拆除，并新建可读节点进行同步
  3. 找一个合适的时间，重启业务，让数据写入到原 region
  4. 切换DNS

  5. （可选）销毁演示环境

  可以通过以下步骤快速销毁演示环境。 销毁灾备环境 以下都是 dr terraform workspace

  1. 在灾备区域 AWS RDS 控制台删除数据库实例
  2. 在 app 目录下执行 terraform destroy --var-file=dr.tfvars
  3. 在 basic 目录下执行 terraform destroy --var-file=dr.tfvars, 请在数据库实例删除后执行

  销毁演示生产环境 以下都是 prod terraform workspace, 可以通过 terraform workspace select prod 切换。

  1. 在 app 目录下执行 terraform destory
  2. 在 database 目录下执行 terraform destroy
  3. 在 basic 目录下执行 terraform destory

  如需要，可手动删除 WordPress Media 文件 S3 Bucket, 以及 Terraform backend.

  脚本故障排查

  Terraform 故障排查 可以通过在 Terraform 命令之前添加环境变量，来使 Terraform 输出更多的日志信息来帮助故障排查，如:

  TF_LOG=DEBUG terraform init
  

  注意事项和RPO说明

  1. S3 Cross Region Replication是以异步复制的方式进行。大多数对象会在 15 分钟内复制， 但有时候可能需要两三个小时。极少数情况下，复制可能需要更长时间。因此，当进行灾难恢复时， 您需要关注部分没有得到复制的数据对您业务所造成的影响，并做出相应的调整。
  2. 容灾方案中的Redis节点是冷启动，启动后内存中没有恢复已有缓存的数据。因此您需要关注灾难 恢复后数据库可能会遭受来自客户端重试导致瞬间的读写冲击。您应该在应用代码中实施类如熔断等机 制以减少冲击。
  3. 在本次方案中，您需要在灾难恢复时填写保存在宁夏区域的AMI ID，以作为AutoScaling Launch Template中EC2启动的镜像。如果您在北京区域对EC2进行了变更，请及时把北京区域的AMI复制到宁夏 区域，以保证宁夏区域的AMI保持最新状态。

  总结

  本文详细介绍了如何在AWS上实现跨区域的cold backup的灾备方案，并提供了terraform模板进行可行性验证。利用本文所述方法，在主区域发生故障后，自动化脚本会自动执行，完成新区域整套环境的启动，以最大程度的节省成本。

企业备份&容灾系列 – AWS 多区域 Pilot Light 容灾设计

本文详细介绍了如何在AWS上实现跨区域的pilot light灾备方案，由于部分闲置的AWS组件会给客户增加额外的成本，因此在整个方案中，除了VPC预配置和RDS热备外，其余所有的组件 都是灾难发生后通过脚本动态创建，达到最小的Infra cost。当发生灾难时，用户通过预先定义好的灾备脚本，在灾备 区域快速构建 AWS 资源。

前提假设

该方案是模拟一个 WordPress cluster 部署在 AWS 上进行 multi-region pilot light 灾备的方案。生产区域组件选择如下：

• RDS MySQL: WordPress 数据库
• ElastiCache: 使用 Redis Object Cache 插件，使得 WordPress 支持Redis 作为缓存，提高用户访问体验
• S3: WordPress 的文件存储在 S3 上，通过 S3FS 软件挂载到EC2
• EC2: 安装 WordPress 应用，通过Auto Scaling Group 实现弹性伸缩
• ELB: 作为负载均衡，将接收到的流量转发给后端的 WordPress 集群
• NAT Gateway: WordPress 经由 NAT 网关主动访问外网

架构

根据 Pilot Light 的需求，我们需要将 WordPress 的文件存储，和数据库异步同步到其他其他区域。架构图如下：  以下为各个组件的介绍。 RDS MySQL 数据备份  RDS Mysql 配置Cross Region Replica，实现数据库的异步复制。如何配置跨Region只读副本，请参考文档。 当灾难发生后，通过提升只读副本为独立的数据库实例，使其能够执行正常的写入操作。在本方案中，会使用脚本实现 提升只读副本的操作。 S3 Bucket 数据备份(WordPress Media File) 开启S3 Cross Region Replication，实现S3文件的跨Region自动复制。关于如何开启S3跨区域复制， 请参考文档。 应用镜像  当北京区域新建AMI后，需要把新建的AMI复制到宁夏区域。您可以手动触发复制过程 也可以通过脚本自动化整个过程，例如在CloudWatch Event中设定时任务，触发lambda捕捉某段时间内 新建的AMI，通过简单的AWS api调用把新建的AMI复制到到宁夏区域。请根据项目实时性的需求为定时任务 设定合适的执行频率。 应用配置  在EC2的启动配置中设置user-data，使EC2内应用程序在启动后能够获取所需的配置，例如RDS Mysql和 Redis的endpoint等等。启动配置已经包含在灾难恢复的脚本中。 灾备脚本  按照上述方案，在GitHub aws-dr-samples上提供了基于 Terraform 的可执行脚本，该套脚本可以帮助用户快速构建模拟生产环境和灾备环境。 用户根据所需创建的资源写成脚本文件。执行脚本时，Terraform 通过调用 AWS API 来快速构建 AWS 资源。下文有如何使用的详细步骤描述。 在本方案中，设定Redis不包含持久化数据。因此无需实现复制，只需在灾难恢复时通过脚本创建新实例即可。 当灾难发生后，按照以下顺序进行灾难恢复：

1. 手动提升RDS只读副本为独立的数据库实例.
2. 执行脚本创建容灾集群。
3. 进行健康检查，确定容灾集群能够正常运行。
4. 执行DNS切换，把用户访问切换到容灾集群。

接下来，我们会详细描述该方案的实施步骤和脚本运行执行过程。

价格

以宁夏区为例，按照上述灾备方案，假定需要的灾备资源及产生的费用为：

• • AMI 20G: 镜像文件在宁夏区存储的费用
  • S3 1T 不频繁访问：由于是灾备访问，平时不会被使用，推荐不频繁访问
  • RDS Read Replica: 跨区域可读实例
  • 跨区域网络传输 2T: 包括S3 跨区域拷贝，Read Replica 跨区域复制等等

以上仅做参考，实际配置情况，应该根据工作负载合理配置。

terraform脚本目录

terraform脚本请点击此处获取。 项目内有三个文件夹，basic, database, app。

• • • basic: 基础结构。可用于构建基础网络架构, 基础安全配置等等。 包含如下资源：
      • VPC
      • Subnet (包含 public subnet, private subnet)
      • Security Group
      • DB Subnet Group
      • Cache Subnet Group
      • Route Table
    • database: 数据库架构。用于自动创建 RDS 实例。包含如下资源：
      • Database Parameter Group
      • Database 实例
    • app：应用相关资源。可用于自动构建缓存，应用及更新配置文件。包含如下资源:
      • Redis
      • Application Load Balancer
      • NAT
      • Route Table (给私有子网增加 NAT 路由)
      • Launch Template
      • Auto Scaling Group
      • Application Load Balancer
      • Listener, Target Group
      • 自动生成配置文件
      • S3FS 自动挂载到 EC2 作为 WordPress 的 Media Library

准备工作

• • 1. 本文使用 AWS China Region, 如使用 AWS Global Region，需要修改镜像地址和 region 信息。
    2. 提前提升好 limits. 每一项 AWS 服务都有 limits，确保灾备切换时，能否启动足够的资源来支撑应用。
    3. 本文架构部署使用 Terraform 一键部署AWS 资源， 请在本机安装 Terraform, 并配置好AWS Credentials
    4. Terraform 可以将信息存储在 S3 和 DynamoDB 中，创建用于存储 Terraform 状态的 S3 Bucket和 DynamoDB Table（由于使用的很少，DynamoDB 建议使用 On-Demand 收费方式）, 该 DynamoDB 的 primary key 必须为 LockID，类型为 string。在本环境中，该 DynamoDB Table名称 为tf-state。
       

       请勿在生产区域部署 S3, DynamoDB，防止 Region Down 之后，无法使用 Terraform。

    5. 在生产区域制作 AMI, 并拷贝到灾备区域。 出于演示的目的，已经提前在 AWS 中国区域部署了 WordPress 5.2.2 版本的AMI. WordPress 应用程序位 于 /var/www/html 目录下，可直接使用。
       • 北京区域 AMI: ami-0eebef1aaa174c852
       • 宁夏区域 AMI: ami-0cbbf10eaeaf0f9c3

       由于 WordPress 会记录域名，请勿使用ELB的域名直接访问, 为 WordPress 配置自定义域名。

    6. 将使用到的 SSL 证书提前导入 IAM。
    7. 修改 <project>/index.tf 和 <project>/variables.tf. <project>代表basic, database, app三个相应folder的泛指，请分别进行修改。
       • index.tf 是状态信息保存的地方, 需要使用到之前提到的 DynamoDB 和 S3。
       • variables.tf 是模板的变量, 根据实际情况修改。
    8. 配置好 AWS Credentials. 该 credentials 需要具备访问 S3, DynamoDB 及自动创建相关资源的权限。
    9. 中国大陆地区执行 terraform init 下载 aws provider 会比较慢，可提前手动下载, 并解压到<project>/.terraform/plugins/<arch>/ 目录下。<arch> 为本机的系统和CPU架构, 如 darwin_amd64, linux_amd64。 >>>点击此处手动下载 Terraform AWS Provider<<<

详细步骤

1. (可选)创建模拟生产环境

如果对现有生产环境进行操作，直接跳过此步骤。

该步骤创建模拟的生产环境，用于演示。可以选择手动创建，或者利用脚本快速创建。使用脚本的好处是， 在演示结束后，我们可以快速销毁演示环境。 创建基础环境

• • 1. 修改 basic/variables.tf 和 basic/index.tf
    2. 在 basic 目录下执行 terraform init
    3. 执行 terraform workspace new prod 创建 模拟生产环境的 workspace. 我们使用 workspace 来区分是模拟生产环境或者灾备环境
    4. 执行 terraform apply 创建基础网络环境

创建数据库

• • 1. 修改 database/variables.tf 和 database/index.tf
    2. 在 database 目录下执行 terraform init
    3. 执行 terraform workspace new prod 创建 模拟生产环境的 workspace.
    4. 执行 terraform apply 创建数据库相关资源

创建应用层

• • 1. 在模拟生产区域创建 S3 Bucket, 并启用 versioning 功能，用于存储 WordPress media 文件
    2. 修改 app/variables.tf 和 app/index.tf
    3. 在 app 目录下执行 terraform init
    4. 执行 terraform workspace new prod 创建模拟生产环境的 workspace
    5. 执行 terraform apply 创建APP相关资源

2. 灾备环境准备工作

我们需要提前在灾备环境创建基础网络架构，来使得灾难发生时可以快速切换。在使用以下脚本的时候 注意参数的配置。推荐使用脚本创建，这样可以提高自动化的水平。 如果已经在创建模拟生产环境中修改了 index.tf 文件，无需修改该文件。 拷贝镜像

• • 1. 在生产区域中选择 EC2, 创建镜像文件
    2. 需要拷贝的镜像文件, 拷贝到灾备区域

创建基础环境

• • 1. 修改 basic/dr.tfvars 和 basic/index.tf
    2. 在 basic 目录下执行 terraform init
    3. 执行 terraform workspace new dr 创建灾备环境的 workspace. 我们使用 workspace 来区分是模拟生产环境或者灾备环境
    4. 执行 terraform apply --var-file=dr.tfvars 创建基础网络环境

S3 数据同步

• • 1. 在灾备区域中创建 S3 Bucket, 并启用 versioning 功能，用于备份 WordPress 的 Media 文件
    2. 利用 AWS CLI 将已存在的文件拷贝到灾备区域，aws s3 sync s3://SOURCE_BUCKET_NAME s3://TARGET_BUCKET_NAME
    3. 在 S3 Console 中选择生产区域的 S3 Bucket, 点击 Management, 选择 Replication
    4. 点击 Add Rule, 选择 Entire bucket, 并点击 Next
    5. 选择在灾备区域中选择的目标桶，点击 Next
    6. 在 IAM Role 中选择 Create new role, 输入 Rule name, 选择 Next。 
    7. 选择 Save 保存复制规则。

有关于开启 S3 Cross Region Replication 的更多资料，请参考这里。

RDS 数据同步

• • 1. 在生产区域中选中 RDS 实例，点击右上角 Actions, 选择 Create read replica。 如果该按钮显示为灰色，请先 Take Snapshot, 等快照创建完毕后，再创建跨区域只读副本
    2. 在 Create read replica DB instance页面，选择 Destination region 为灾备区域， 选择 Destination DB subnet group 为 db-group(在 basic 模板中自动创建) 
    3. 根据需要，选择 instance class 和 Multi-AZ deployment
    4. 在 Settings 中 DB instance identifier 中输入数据库实例名称
    5. 其他设置保持默认, 选择 Create read replica，等待灾备区域的数据库实例启动完成
    6. 由于创建跨区域只读库无法选择安全组，因此我们需要手动跨区域只读节点的安全组。在 RDS Console 选择进入可读节点，选择右上角 Modify
    7. 在 Network & Security 选择 DB_SG(在 basic 模板中自动创建), 选择右下角 Continue 
    8. 在 Scheduling of modifications 选择 Apply immediately
    9. 选择 Modify DB Instance

修改灾备应用脚本启动参数

• • 1. 将跨区域只读库的 endpoint 更新到 app/dr.tfvars
    2. 修改 app/dr.tfvars, app/index.tf(如之前未修改)
    3. 在 app 目录下执行 terraform init
    4. 执行 terraform workspace new dr 创建灾备环境的 workspace.

修改灾备脚本参数时，要谨慎核对参数。

3. 故障转移

强烈建议在完成数据同步之后，进行一次故障转移的演练。

在灾难发生后，执行故障转移, 请确保 app 目录下的 terraform workspace 是 dr。 可以通过 terraform workspace list 来确认当前 workspace, 或者通过 terraform workspcae select dr 来切换到 dr workspace。

• • 1. 执行 terraform apply --var-file=dr.tfvars 来启动资源
    2. 在 灾备区域 RDS Console 将 RDS Instance 提升为 master （可与上一步同时执行)。在灾备区域 RDS 控制台选择实例， 点击 Actions, 选择 Promote，在弹出的对话中选择 Continue 
    3. 测试。功能测试应该在之前测试过，这里主要测试连通性
    4. 切换 DNS

4. 灾后恢复

灾后恢复请务必咨询架构师！

• • 1. S3 的数据可以通过 AWS CLI Sync 命令来完成
    2. RDS 需要将原 region 的数据库拆除，并新建可读节点进行同步
    3. 找一个合适的时间，重启业务，让数据写入到原 region
    4. 切换DNS

5.（可选）销毁演示环境

可以通过以下步骤快速销毁演示环境。 销毁灾备环境 以下都是 dr terraform workspace

• • 1. 在灾备区域 AWS RDS 控制台删除数据库实例
    2. 在 app 目录下执行 terraform destroy --var-file=dr.tfvars
    3. 在 basic 目录下执行 terraform destroy --var-file=dr.tfvars, 请在数据库实例删除后执行

销毁演示生产环境 以下都是 prod terraform workspace, 可以通过 terraform workspace select prod 切换。

• • 1. 在 app 目录下执行 terraform destory
    2. 在 database 目录下执行 terraform destroy
    3. 在 basic 目录下执行 terraform destory

如需要，可手动删除 WordPress Media 文件 S3 Bucket, 以及 Terraform backend.

脚本故障排查

Terraform 故障排查 可以通过在 Terraform 命令之前添加环境变量，来使 Terraform 输出更多的日志信息来帮助故障排查，如:

TF_LOG=DEBUG terraform init

注意事项和RPO说明

• • 1. S3 Cross Region Replication是以异步复制的方式进行。大多数对象会在 15 分钟内复制， 但有时候可能需要两三个小时。极少数情况下，复制可能需要更长时间。因此，当进行灾难恢复时， 您需要关注部分没有得到复制的数据对您业务所造成的影响，并做出相应的调整。
    2. RDS Mysql Cross Region Replication采用异步复制的方式进行。Replica和Master之间 的lag主要取决于事务的大小以及Master负荷。当进行灾难恢复时，您需要关注没有得到复制的数据 对您业务所造成的影响。您可以自行检查数据表的情况进行了解，或者在 Amazon CloudWatch 中通 过查看 Amazon RDS ReplicaLag 监控指标来大致了解复制滞后的程度。
    3. 容灾方案中的Redis节点是冷启动，启动后内存中没有恢复已有缓存的数据。因此您需要关注灾难 恢复后数据库可能会遭受来自客户端重试导致瞬间的读写冲击。您应该在应用代码中实施类如熔断等机 制以减少冲击。
    4. 在本次方案中，您需要在灾难恢复时填写保存在宁夏区域的AMI ID，以作为AutoScaling Launch Template中EC2启动的镜像。如果您在北京区域对EC2进行了变更，请及时把北京区域的AMI复制到宁夏 区域，以保证宁夏区域的AMI保持最新状态。

总结

本文详细介绍了如何在AWS上实现跨区域的pilot light灾备方案，并提供了terraform模板进行可行性验证。在整个方案中，除了VPC预配置和RDS热备外，其余所有的组件 都是灾难发生后通过脚本动态创建，达到最小的Infra cost。当发生灾难时，用户通过预先定义好的灾备脚本，在灾备 区域快速构建 AWS 资源。

本文转载亚马逊云科技官方博客《企业备份&容灾系列 – AWS 多区域 Pilot Light 容灾设计》

企业备份&灾备专题

维持业务持续性对于企业至关重要, 关键业务系统宕机可能会对企业带来重大影响，企业声誉、客户满意度或公司的财务的状况都可能受到难于挽回的重大损失。 因此，构建高可用高容灾的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种类型适合业务类型和成本对比:

模拟内容

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

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

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

AWS 组件的计费模型

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

不同场景下的解决方案

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

• AWS 多区域灾备 Pilot Light Backup
• AWS 多区域 Cold Backup
• On-premise 到 AWS Cold Backup & Pilot Light
• 其他云服务商到 AWS Cold Backup

脚本下载

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

总结

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