行业趋势与挑战
对于各行各业而言，用户数据、系统数据均是企业最核心、最重要的财富，业务的稳定运行、IT系统功能正常是企业最重要的发展诉求。而这些诉求常常因为一些不可预期不可力抗“天灾人祸”变得十分困难，例如：
综上，保障企业业务稳定、IT系统功能正常、数据安全十分重要，可以同时保障数据备份与系统、应用容灾的灾备解决方案应势而生，且发展迅速。说明：灾备是指容灾+备份：
- 备份的定义：指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或者多份拷贝，以增强数据的安全。
- 容灾的定义：指在相隔较远的两地（同城或者异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换。当一处系统因意外（天灾、人祸）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。据智研数据中心统计数据，灾备行业的市场规模已达百亿规模，且预计会逐年持续增长。
进行灾备解决方案设计时，需关注灾备的两个关键技术指标：
- RTO：RecoveryTime Object，恢复时间目标。指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。RTO是反映业务恢复及时性的指标，体现了企业能容忍的IT系统最长恢复时间。RTO值越小，代表容灾系统的恢复能力越强，但企业投资也越高。
- RPO：Recovery Point Object，恢复点目标。指灾难发生后，容灾系统进行数据恢复，恢复得来的数据所对应的时间点称为RPO。RPO是反映数据丢失量的指标，体现了企业能容忍的最大数据丢失量的指标。RPO值越小，代表企业数据丢失越少，企业损失越小。
阿里云灾备解决方案亮点
阿里云针对企业对灾备的需求，构建阿里云灾备解决方案，基于阿里云平台的灾备解决方案有以下亮点：
- 多数据中心：阿里云在全球分布有多个数据中心，用户可在就近、合适区域选购、部署阿里云产品。
- 稳定：每个区域及产品比较稳定，阿里云关键部件（SLB、ECS、RDS等）经多轮迭代具备比较完善的灾备能力，可以实现更细粒度的控制，可以通过更多已经产品化的功能模块实现容灾。
- 弹性：用户可根据业务需求横向、纵向扩缩容，按需购买使用的服务。
核心产品的灾备设计及技术指标
以一个最简IT系统为例，用户可使用以下阿里云产品：
- SLB：Server Load Balancer，是对多台云服务器进行流量分发的负载均衡服务，在整个IT系统中，SLB是服务的对外接口，流量入口。阿里云SLB可通过多可用区来消除单点故障，保障系统的稳定性。详细的灾备设计及技术指标见 SLB 章节。
- ECS：Elastic Compute Service，是一种简单高效、处理能力可弹性伸缩的计算服务，在整个IT系统中提供计算能力。ECS可使用镜像、快照进行备份，详细的设计及技术指标见 ECS 章节。
- RDS：Relational Database Service，是一种稳定可靠、可弹性伸缩的在线数据库服务。在整个IT系统中提供关系型数据库能力，详细的设计及技术指标见 RDS 章节。注意：本文所描述的阿里云灾备解决方案中的设计及技术指标均为2018年3月各产品版本测试支持情况，不作为SLA的参考特性及指标。
SLB
灾备设计
集群部署
阿里云SLB当前提供四层（TCP协议和UDP协议）和七层（HTTP和HTTPS协议）的负载均衡服务。负载均衡采用集群部署，可实现会话同步，以消除服务器单点故障，提升冗余，保证服务的稳定性。以四层负载均衡服务器为例： - 采用开源软件LVS（Linux Virtual Server）+ keepalived的方式实现负载均衡。
- LVS集群内的每台LVS都会进行会话，通过组播报文同步到该集群内的其它LVS机器上，从而实现LVS集群内各台机器间的会话同步。
当客户端向服务端传输数据包后：
- 在LVS1上建立的会话A开始同步到其它LVS机器上。
- 当LVS1出现故障或进行维护时，这部分流量会走到一台可以正常运行的机器LVS2上。可见，负载均衡集群支持热升级，并且可在机器故障和集群维护时最大程度对用户透明，不影响用户业务。注意：对于连接未建立（三次握手未完成），或者已建立连接但未触发会话同步机制，热升级不保证连接不中断，需要依靠客户端重新发起连接。
多可用区部署
在灾备场景下，SLB的Master&API控制系统与流量服务节点可部署在指定可用区，在多可用区部署的地域还支持主备可用区，当主可用区出现故障时，负载均衡可自动切换到备可用区上提供服务。以双机房部署为例：
转发节点发生故障通过BGP（Border Gateway Protocol，边界网关协议）路由进行切换，实现在故障时SLB实例能自动秒级将流量切换到另一机房。SLB在整体设计上让其可用性高达99.99%。且能够根据应用负载进行弹性扩容，在任意一台SLB故障或流量波动等情况下都能做到不中断对外服务。
应用场景
同城容灾：
- 多可用区部署SLB实例，在各个地域采用多物理机房部署。
- 若流量入口为互联网，则使用公网VIP；若流量入口为公共云内网，则使用私网VIP即可。
- 当转发节点发生故障时，通过BGP路由进行切换，将流量转发至另一机房。
- 通过权重进行后端流量分配；若业务对时延敏感，可将备可用区ECS的权重调整为0。
同城容灾场景下，也可在多可用区部署一个SLB实例，此种应用场景下，SLB无法做到实例级灾备切换，仅当整个可用区故障时，流量切换至另一个可用区。
异地容灾：
- 单可用区和多可用区SLB实例均可使用，两个地域要分别采购各自节点的SLB实例。
- 若流量入口为互联网，则使用公网VIP；若流量入口为公共云内网，则使用私网VIP即可。灾备场景下，SLB的配置请参考结合云解析实现跨地域负载均衡。
ECS
灾备设计
快照备份与回滚
快照备份：
阿里云ECS可使用快照进行系统盘、数据盘的备份。目前，阿里云提供快照2.0服务，提供了更高的快照额度、更灵活的自动任务策略，并进一步降低了对业务I/O的影响。使用快照进行备份时，第一次备份为全量备份，后续为增量备份，备份所需时间与待备份数据量有关。
例如，快照 1 、快照 2 和快照 3 分别是磁盘的第一个、第二个和第三个快照。文件系统对磁盘的数据进行分块检查，当创建快照时，只有变化了的数据块，才会被复制到快照中。阿里云ECS的快照备份可配置为手动备份，也可配置为自动备份。配置为自动备份后可以指定磁盘自动创建快照的时间（24个整点）、重复日期（周一到周日）和保留时间（可自定义，范围是1-65536天，或选择永久保留）。
快照回滚：
当系统出现问题，需要将一块磁盘的数据回滚到之前的某一时刻，可以通过快照回滚实现，前提是该磁盘已经创建了快照。注意：
- 回滚磁盘是不可逆操作，一旦回滚完成，原有的数据将无法恢复，请谨慎操作。
- 回滚磁盘后，从所使用的快照的创建日期到当前时间这段时间内的数据都会丢失。
镜像备份与恢复
镜像备份
镜像文件相当于副本文件，该副本文件包含了一个或多个磁盘中的所有数据，对于 ECS 而言，这些磁盘可以是单个系统盘，也可以是系统盘加数据盘的组合。使用镜像备份时，均是全量备份，且只能手动触发。
镜像恢复
阿里云ECS支持使用快照创建自定义镜像，将快照的操作系统、数据环境信息完整的包含在镜像中。然后使用自定义镜像创建多台具有相同操作系统和数据环境信息的实例。注意：创建的自定义镜像不能跨地域使用。ECS的快照与镜像配置请参考快照与镜像。
技术指标
RTO：与数据量大小有关，通常而言是小时级别RPO：与配置的自动快照策略、恢复用的快照生成时间有关，通常而言是小时级别
应用场景
备份恢复：
阿里云ECS可通过快照与镜像对系统盘、数据盘进行备份。如果存储在磁盘上的数据本身就是错误的数据，比如由于应用错误导致的数据错误，或者黑客利用应用漏洞进行恶意读写，此时就可以使用快照服务将磁盘上的数据恢复到期望的状态。另外ECS可通过镜像重新初始化磁盘或使用自定义镜像新购ECS实例。
容灾应用：
ECS可以从架构上来实现容灾场景下的应用，比如：在应用前端购买SLB产品，后端相同应用部署至少两台ECS服务器，或者是使用阿里云的弹性伸缩技术，根据自定义ECS自身资源的使用规则来进行弹性扩容。这样即便其中一台ECS服务器故障或者资源利用超负荷，也不会使服务对外终止，从而实现容灾场景下的应用。以同城两机房部署ECS集群为例：
- ECS在两机房均部署集群，接入侧通过SLB做两机房的接入流量负载均衡。
- 两机房部署的Region Master节点是对等的，单Region Master节点故障不影响ECS的管控功能。
- ECS的管控节点机房级故障切换，主要是对管控集群依赖的中间件域名重新绑定。如管控节点机房级故障，需重新将中间件域名绑定至另一个机房的管控节点。
RDS
灾备设计
双机热备
RDS 采用热备架构，物理服务器出现故障后服务秒级完成切换。整个切换过程对应用透明。多副本冗余
RDS 服务器中的数据构建于 RAID 之上，数据备份存储在 OSS 上。数据备份
RDS 提供自动备份的机制。用户可以设置自动备份的周期，还可以根据自身业务特点随时发起备份。数据恢复
支持按备份集和指定时间点的恢复。在大多数场景下，用户可以将 7 天内任意一个时间点的数据恢复到 RDS 临时实例或克隆实例上，数据验证无误后即可将数据迁回 RDS 主实例，从而完成数据回溯。应用场景
通用场景
RDS默认采用主备架构（备用实例正常情况下对用户不可见）：
- 两个实例位于不同服务器，自动同步数据。
- 主实例不可用时，系统会自动将数据库连接切换至备用实例。切换为分钟级别，且无需人工介入，由系统自动完成，应用系统也无需任何变更。这种架构足以满足90% 用户的高可用需求。
同城容灾
用户如果对系统可用性有更高的要求，希望可以做到机房容灾，阿里云RDS可以选择购买多可用区RDS。多可用区是在单可用区的级别上，将同一地域的多个单可用区组合成的物理区域。相对于单可用区RDS实例，多可用区RDS例可以承受更高级别的灾难。
- 前端对DB的访问连接由SLB+Proxy完成容灾切换，SLB的转发层可通过BGP路由完成自动切换。
- Proxy完成对后端DB Node的连接（长连接Session保持），实现防闪断（软切换不断连接），防SQL注入等功能，对硬件级切换无效。
- DB Node：双机房主备部署，主实例在主机房，备实例在备机房。
- 单台DB Node故障，HA自动检测故障并进行切换至另一机房的DB Node。
- 采用双HA服务器机制来判断是否发生机房级故障，双机房2台HA相互检测不到对方时判断发生机房级故障。一旦发生机房级故障，RDS系统将停止主切换，以避免发生数据不一致现象。
- RDS集群可采用Lossless Replication的配置方式（Aftersync）来保证主备库的数据一致性。
异地容灾
除了同城容灾之外，对于数据可靠性有强需求用户，比如是有监管需求的金融业务场景，RDS提供异地灾备实例，帮助用户提升数据可靠性。
- RDS通过数据传输服务（DTS）实现主实例和异地灾备实例之间的实时同步。
- 主实例和灾备实例均搭建主备高可用架构，当主实例所在区域发生突发性自然灾害等状况，主节点（Master）和备节点（Slave）均无法连接时，可将异地灾备实例切换为主实例，在应用端修改数据库链接地址后，即可快速恢复应用的业务访问。
典型应用场景
阿里云灾备解决方案可根据企业用户的灾备需求及IT系统现状进行企业灾备方案的定制设计，以下以三个典型的应用场景示例，基于阿里云平台不同灾备场景下的架构设计。
通用架构
中小型企业业务量不是特别大，对异地容灾要求不是特别强烈，在阿里云平台上可采用以下灾备方案：
- 在同一地域下选择购买云产品。建议在VPC网络环境下，选择同一可用区或者同地域不同可用区的云产品。
- 在前端购买SLB，提供负载功能，当后端ECS资源使用紧张时可以直接横向扩展，对业务无影响。
- 建议ECS服务器至少两台，避免单点故障。
- 数据库业务尽量不要和应用服务部署在同一台ECS上，防止不同服务之间资源抢占，同时方便日常管理和后期扩容。数据库服务器推荐直接购买RDS产品，数据安全有保障，同时也不需要花太多精力去运维管理。
同城容灾
对中大型用户来说，希望业务系统要求具备同城容灾的能力，可以采用以下同城灾备方案：
- 在同城不同可用区之间对原有应用架构做一套完整的备份，SLB、ECS、RDS等均在两个机房同时部署。
- 前端部署DNS解析，如果某个可用区出现像IDC机房断电或者火灾等机房级故障时，可以通过前端切换DNS来及时恢复业务。
- 非机房级故障（某个机房的单产品故障，如其中一个机房的ECS服务器损坏），故障切换保障由单产品的灾备设计保障。
异地容灾
对于一些大型企业在业务安全全性、服务可用性和数据可靠性方面既要求具备同城容灾又要求具备异地容灾时，可以采用以下异地灾备方案：
- 在不同地域、不同可用区中均对原有应用架构做一套完整的备份。
- 不同地域之间可以采用阿里云的高速通道进行私网通信，保障数据库之间的数据实时同步，将数据传输延迟降到最低。
- 故障发生时可以通过前端DNS实现秒级切换，及时恢复业务。
- 这种容灾架构方式既可以解决单机房故障也可以应对像地震等灾难性故障。
