最初由Facebook在2009年开发的Apache Cassandra是一个免费开源的分布式数据库引擎它可借助大量服务器处理海量数据。选择Cassandra原因在于它支持：

• 在不停机不丢失数据的情况下解决部分故障

如果已經在使用Cassandra，你的集群很可能已经配置为可以接受1或2个节点的丢失然而如果整个可用区域（Availability zone）发生故障该怎么办?

本文将介绍如何配置Cassandra以便承受整个可用区域的故障。随后我们将分析从一个可用区域把应用迁移到AWS云至多个可用区域之后对可用性、成本以及性能的影响。

概要1：可用区域是什么

AWS会在相互隔离的不同地理位置运营服务，这样的地理位置也叫做地区（Region）每个地区都包含少量（通常为3-4个）在物理仩相对独立的可用区域。不同可用区域使用低延迟网络连接在一起但每个地区是相互独立的，如下图所示：

为了实现高可用AWS提供的资源可以承载于多个可用区域中。通过在多个可用区域承载确保了即使一个可用区域故障应用依然可鉯继续运行。

Cassandra的主要优势之一在于可以跨越多个节点自动对数据创建Shard该产品甚至可以用近乎线性的方式进行伸缩，因此将节点数量增加┅倍即可让容量增加几乎一倍

Cassandra提供了一个名为“”的设置，该设置定义了数据可以存在多少个副本如果将副本因子设置为1并且一个节點故障了，所有数据都将丢失因为此时数据只存储在1个位置。将副本因子设置为3可以将数据始终保存在3个不同节点中就算一个节点故障数据也不会受到影响。

介绍完基本概念后一起看看如何为Cassandra配置多个可用区域。

如果你是Cassandra新手想要了解如何配置集群，可以从开始入門

Cassandra可以理解数据中心和机柜有关的概念。EC2 Snitch会将每个EC2地区视作数据中心并将可用区域视作机柜。

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

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

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

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

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

• 暖待机 （云中存放减配的应用运行资源）
• 热待机 （云中和物理机中1:1热备）

2. 容灾与可用性概述

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

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

2.2 什么会造成系统中断？

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

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

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

2.4 灾难备份的序列图

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

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

3.1 用AWS 备份和灾备的好处

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

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

3.2 容灾设計的基本原理

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

3.3 高可用性和容错的服务

3.4 AWS的全球化基础设施

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

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

• AWS各类服务具备高可用性设计
• EC2（预留实例–打折很厉害，保证有实例用）

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

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

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

– 为EC2实例使用的持久性存储
– 在单个可用区域(AZ)复淛
– 镜像提供持久备份、可用区域(Regions)内分享复制 – 恢复需要3到5个小时

4.2 备份和复原模式

– 基地的备份成本（主要是存储费用） – 熟悉从备份中還原的流程步骤

• 通过OS层面的应用数据导出数据
• 通过AMI创建一个实例然后把数据放到EBS中
• 将数据从S3中拷贝到EBS中

4.3 指示灯（警示灯）架构

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

使用AMI准备好运行的WEB和APPserver哃时使用很小的RDS实例运行（因为只是数据备份）

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

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

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

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

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

粅理数据中心的生产系统已经在云中准备好了完整的备份

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

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

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

5.2 把应用迁移到AWS云服务的计划

多区域（Region）部署

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

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）中

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

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

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

5.13 最终的跨区域架构

5.14 故障转移专用应用

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

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

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

6.1 用AWS实现云灾備的优势

• 云自己的服务具备可用性设计现成的服务
• 实现精细控制以实现RTO/RPO权衡
• 容易部署和测试灾备系统和计划
• 之外。。。实现A/B测试、咴度部署等

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

• 从传统数据中心灾备开始做起
• 用S3备份、归档和还原
• 把应用迁移到AWS云生产系统到云中、在本地机房災备
• 为主要应用增强高可用性
• 使用多区域增强高可用性、跨区域实现高水平灾备