【总结】利用AWS实现高可用性和云灾备

下载地址：下载完整MP4视频

1. 邱洋的总结

• 企业用云可以从灾备云开始

• 为了让应用具备高可用和灾备能力，云平台自身针对基础设施以及云服务都应提供灾备与HA机制，例如：

  1. 云平台自身：云的分布式存储、虚拟机HA、控制器容灾、SDN网络容灾、虚拟机数据保护
  2. 云提供具备灾备的云服务
     – EC2（虚拟机可以漂移）、EC2实例恢复
     – AMI（虚拟机模板备份）
     – EBS（数据2+份拷贝）、EBS快照/恢复
     – S3（数据2+份拷贝）
     – ELB（负载均衡到多数个EC2实例）
     – RDS（读写分离、主主部署）
     – CloudFormation（多区域一致化部署）
     – AutoScale（自动伸缩服务器规模）
     – EIP（EC2的实例IP可漂移）

• 云可以为物理机应用提供灾备能力，例如：
  – 将应用、数据库数据放入S3（可能需要开发），提供高可靠保障
  – 将数据放入灾备服务（如爱数的服务）中，需要时恢复到本地
  – 将物理机P2V（例如使用爱数的服务）到EC2中，需要时恢复到云中
  – 将数据库数据复制一份到云中的RDS（采用mysql、oracle、sqlserver的复制工具）

• 企业实施云灾备可以“逐步”的方式

  1. 单纯备份恢复数据
  2. 指示灯（应用冷备份）
  3. 暖待机 （云中存放减配的应用运行资源）
  4. 热待机 （云中和物理机中1:1热备）

2. 容灾与可用性概述

2.1 云和传统方法的数据中心对比

传统方法	云
数据中心建立灾备系统，成本昂贵	低成本：低廉的总体拥有成本
存储、归档、备份和恢复的工具和流程都产生费用	统一流程工具：高扩展性的存储、跨AWS区域和可用区的统一流程工具
容量设计规划、设备采购等面临挑战	弹性：不需要精细的规划

2.2 什么会造成系统中断？

包括：
- 人为(60%以上的原因)
- 死机停机
- 设备故障
- 自然灾害
- 安全事故
- …

典型人为事故：（虽然有A，B备份机制）某人用root权限删除A中的文件权限（结果rm -rf /）了。虽然B机接管，但是忙中出错用B恢复A的时候，用A恢复了B

2.3 高可用HA和容错FT的定义

• 都是是业务连续性计划的一部分
• 不是有或无，而是可以定制
• 当意外发生时，希望做到的效果包括：业务7*24运行、确保数据安全、大灾难后恢复应用运行）

2.4 灾难备份的序列图

• 复原时间目标（RTO出了问题后多久恢复？）、复原点目标（RPO可以恢复到哪个原来的时间点？）
  

• 传统IT的方法：在另一个物理环境建立灾备中心
  -低端灾备：同城异地备份
  -高端灾备：异地双活灾备

3 用AWS实施灾备

3.1 用AWS 备份和灾备的好处

可靠/持久、简化基础设施、按需付费、全球部署、高扩展/易缩放、安全

3.1 高可用的目标

减少灾备预算50%、减少本地部署IT系统30+、不需要第二个物理中心、不用光盘带库

3.2 容灾设计的基本原理

• 目标：即使物理硬件坏了，被移走或替换，应用能够继续正常运行
• 原理：避免单点故障、假设所有器件都会坏、准备好复原过程

3.3 高可用性和容错的服务

• 多数AWS服务具备高可用很容错性
  – S3、SQS、RDS、DynamoDB、ELB、Router53
• 服务可以用来构建高可用性的应用app
  – 可用区设计、ElasticIP、EBS、EBS快照、ELB、AS、Router53
  – EC2(保留实例)、AMIs

3.4 AWS的全球化基础设施

• 11个区域Regions（美国的某个州、中国、欧洲等）这些地域对数据有安全的要求等（例如中国区数据不能去其他地方，账号也独立）
• 30个可用区Availableility Zones （每个Region，有多个可用区），相当于同城异地，每个可用区之间不超过100公里，延迟小于3毫秒
• 53个边缘

3.5 在AWS实现灾备1–多可用区

• AWS各类服务具备高可用性设计
• EC2、RDS多可用区（muli-az）的部署
• 使用EIP(弹性IP)
• 使用ELB和AS
• 使用AMI满足RTO要求
• EC2（预留实例–打折很厉害，保证有实例用）

3.6 在AWS实现灾备2-跨区域部署（相当于远程异地，两地三中心）

• 使用CloudFormation实现自动化部署
• 跨区S3、EBS快照、AMI复制
• 块存储复制工具（常见工具：Rsync、Xcopy、Robcopy）
• Route53、AutoScaling
• 跨区域RDS和MySQL replicas
  
• 建立跨区域主-主数据库（数据库自带工具：MySQL Multi-master、MS SQL Always On Cluster、OracleMulti-master）

3.7 AWS存储选项

• EBS（高性能块存储）
• S3（高扩展的对象存储，11个9的持久性）

4 常用灾备架构模式

4.1 AWS灾备模式概述

AWS云存储特别适合备份和灾备

• S3（云存储）
  – 高持久对象存储
  – 生命周期管理
  – 特别适合备份归档
• EBS（云硬盘）
  – 为EC2实例使用的持久性存储
  – 在单个可用区域(AZ)复制
  – 镜像提供持久备份、可用区域(Regions)内分享复制
• Glacier（冰河）
  – 长期归档存储
  – 恢复需要3到5个小时

4.2 备份和复原模式

A.特点

• 简单备份和复原的优势
  – 简单快速启动
  – 基地的备份成本（主要是存储费用）
• 备份和复原的准备工作
  – 备份现有系统
  – 将备份存储在S3
  – 熟悉从备份中还原的流程步骤

B.向云备份

• 多种存储方法到S3中
• 专线直连AWS Direct Connect
• 通过Internet
• AWS Import/Export（粗暴的邮寄硬盘到AWS，由管理员导出）
• AWS Storage Gateway

C.从云备份

• 通过OS层面的应用数据导出数据
• 通过AMI创建一个实例，然后把数据放到EBS中
• 将数据从S3中拷贝到EBS中
• 之后通过AWS Import/Export拷贝到本地数据中心
• or 通过AWS Direct Connect直连拷贝
• or 通过 AWS Storage Gateway拷贝到数据中心

4.3 指示灯（警示灯）架构

A.特点
只关注将核心数据备份下来，并且通过例如AMI、CloudFormation等方式准备好部署架构（但不运行），当灾难发生时将数据恢复到AWS资源（如EC2，EBS）中

B.指示灯架构
使用AMI准备好运行的WEB和APPserver，同时使用很小的RDS实例运行（因为只是数据备份）

C.指示灯–出现故障后的动作
当主数据中心的app出问题后，则可以立即启动云中的EC2实例

4.4 暖待机架构

A.特点
- 建造一个与生产系统环境类似，但规模缩小了的环境。当灾难发生时扩展AWS资源以满足生产需要
- 造价比“指示灯”贵，但是比“热待机”便宜，因为跟生产资源比缩小了，所以叫暖，而不是“热”（1：1）待机架构

B.暖待机架构
将生产环境的资源，按照缩小运行的比例（如生产环境是4cpu+8G内存，那么云中可以是2cpu+4G内存）放在云中运行

C.暖待机–出现故障后的动作
在生产环境出现问题后，备用环境可以立即运行，并且可以按需通过scale up或scale out方式提升处理能力

4.5 多点多活架构

A.特点
- 所有生产系统数据都同步/异步 到异地数据中心内，使用RI（保留的实例）实例保证容量
- 主系统可以在企业物理机上，也可以在云中

B.多点多活架构
物理数据中心的生产系统已经在云中准备好了完整的备份

C.多点多活架构–为云中的应用再做一次灾备
云中的系统可以再进行一次灾备（2个区域）

5. 通过流程demo一个灾备系统的创建

5.1 灾备目标

• 系统尽可能多的用AWS服务
• 尽可能使用已有数据的license
• 系统不产生收入，尽量降低成本
• 系统有较大的负载变化，需要根据流量缩放
• 服务水平达到99.99%，并且实现自动失效备援
• RPO：0-2分钟、RTO：0-15分钟

5.2 迁移服务的计划

灾备目标	使用的AWS服务
DNS/域名服务器	Amazon Router53
负载均衡器	Elastic LoadBalancing
Web/应用 服务器	AutoScaling
数据库服务器	多节点、集群部署
认证目录服务器	多节点部署
数据中心故障	多可用区（AZ）部署
灾难事故	多区域（Region）部署

5.3 AWS相关服务

5.4 区域选择

选择新加坡和东京2个大区（region）

5.5 设立VPC和子网

VPC也是高可用架构，通过多个VPN 实例建立多个连接点（可以建立跨VPC的连接）

同时需要考虑VPN的连接高可用，因此可以准备2个VPN的实例来保障两个VPC的连通性

5.6 选择WEB、应用和数据库实例类型

EC2实例类型包括：通用类型、计算优化（主频高）、存储和I/O优化（高性能本地磁盘）、GPU（带有GPU）、内存优化（计算与内存配比高）

5.7 考虑域名服务和负载均衡服务

• 域名服务可以使用router53（全球使用同一），负载均衡可以使用ELB（不同区各一个）
• 连接到的实例分别部署在东京和新加坡大区（region），同时在东京部署在2个可用区（AZ）中
  

5.8 部署RDP网关服务器（堡垒机）

• 将运行RDP网关的EC2实例放在公网VPC中，相当于堡垒机
• 远程访问各类私网VPC中的EC2实例必须通过这些堡垒机
  

5.9 域（AD）登陆权限控制

AD分别部署在东京和新加坡大区（region），同时在东京部署在2个可用区（AZ）中

5.10 web和应用服务器

• 生产环境在东京的2个AZ中部署
• 然后通过AMI复制到新加坡—暖待机模式

5.11 建立数据库

使用微软的WSFC and SQL AlwaysON来保障SQL数据库的多AZ和多区域数据复制

5.12 在一个大区中再多部署一个AD的备份

将使用AD的集群配置工具部署AD的多数据中心架构

5.13 最终的跨区域架构

5.14 故障转移专用应用

选择性部署：例如当东京大区除了问题后，新加坡大区在默认状态下还要运行一些内容初始化等，可以考虑用RI（保留实例）来做

5.15 如果大区的AZ1出了问题则切换到AZ2

5.16 假定大区整体出了问题，则发生跨区域故障转移

6 总结

6.1 用AWS实现云灾备的优势

• 云自己的服务具备可用性设计，现成的服务
• 实现精细控制以实现RTO/RPO权衡
• 容易部署和测试灾备系统和计划
• 实现全球部署
• 众多生态合作伙伴
• 之外。。。。。实现A/B测试、灰度部署等

6.2 逐步实现高可用性和灾难备份

• 从传统数据中心灾备开始做起
• 逐步实现云灾备
  
  1. 用S3备份、归档和还原
  2. 指示灯灾备
  3. 暖灾备
  4. 热灾备
• 迁移生产系统到云中、在本地机房灾备
• 在云里增加热灾备
• 为主要应用增强高可用性
• 使用多区域增强高可用性、跨区域实现高水平灾备