【总结】利用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可以恢复到哪个原来的时间点?)
    RTP和RTO示意图

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

3 用AWS实施灾备

3.1 用AWS 备份和灾备的好处

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

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的全球化基础设施

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
    RDS多中心部署示意图
  • 建立跨区域主-主数据库(数据库自带工具:MySQL Multi-master、MS SQL Always On Cluster、OracleMulti-master)

3.7 AWS存储选项

  • EBS(高性能块存储)
  • S3(高扩展的对象存储,11个9的持久性)

4 常用灾备架构模式

4.1 AWS灾备模式概述

AWS灾备模式

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

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

AWS存储服务

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相关服务

各类AWS服务

5.4 区域选择

选择新加坡和东京2个大区(region)
2个区

5.5 设立VPC和子网

VPC也是高可用架构,通过多个VPN 实例建立多个连接点(可以建立跨VPC的连接)
跨vpc连接

同时需要考虑VPN的连接高可用,因此可以准备2个VPN的实例来保障两个VPC的连通性
vpn节点故障后的动作

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

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

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

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

5.8 部署RDP网关服务器(堡垒机)

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

5.9 域(AD)登陆权限控制

AD分别部署在东京和新加坡大区(region),同时在东京部署在2个可用区(AZ)中
AD部署

5.10 web和应用服务器

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

web和应用服务器

5.11 建立数据库

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

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

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

5.13 最终的跨区域架构

最终架构

5.14 故障转移专用应用

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

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

故障转移AZ

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

故障转移大区

6 总结

6.1 用AWS实现云灾备的优势

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

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

  • 从传统数据中心灾备开始做起
  • 逐步实现云灾备
    1. 用S3备份、归档和还原
    2. 指示灯灾备
    3. 暖灾备
    4. 热灾备
  • 迁移生产系统到云中、在本地机房灾备
  • 在云里增加热灾备
  • 为主要应用增强高可用性
  • 使用多区域增强高可用性、跨区域实现高水平灾备
  • 8
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值