高可用和灾备方案

基础知识

高可用 （High Availability，简称 HA

高可用性是指提供在本地系统单个组件故障情况下，能继续访问应用的能力
有两个维度的成本：RTO （Recovery Time Objective）和 RPO（Recovery Point Objective）

• RTO 是服务恢复的时间，最佳的情况是 0，这意味着服务立即恢复；最坏是无穷大意味着服务永远恢复不了
• RPO 是切换时向前恢复的数据的时间长度，0 意味着使用同步的数据，大于 0 意味着有数据丢失

HA 的计算公式是[ 1 - (宕机时间)/（宕机时间 + 运行时间）]，我们常常用几个 9 表示可用性：

2 个9：99% = 1% * 365 = 3.65 * 24 小时/年 = 87.6 小时/年的宕机时间
4 个9: 99.99% = 0.01% * 365 * 24 * 60 = 52.56 分钟/年
5 个9：99.999% = 0.001% * 365 = 5.265 分钟/年的宕机时间，也就意味着每次停机时间在一到两分钟。
11 个 9：几乎就是几年才宕机几分钟。 据说 AWS S3 的设计高可用性就是 11 个 9

服务的分类

• 有状态服务：后续对服务的请求依赖于之前对服务的请求
• 无状态服务：对服务的请求之间没有依赖关系，是完全独立的

HA 的种类

HA 需要使用冗余的服务器组成集群来运行负载，包括应用和服务

• Active/Passive HA：集群只包括两个节点简称主备
• Active/Active HA：集群只包括两个节点时简称双活，包括多节点时成为多主（Multi-master）

云环境的 HA

云环境包括一个广泛的系统，包括硬件基础设施、IaaS层、虚机和应用
云环境的 HA 将包括：

• 应用的 HA
• 虚机的 HA
• 云控制服务的 HA
• 物理IT层：包括网络设备比如交换机和路由器，存储设备等
• 基础设施，比如电力、空调和防火设施等

灾难恢复 （Disaster Recovery）

• 数据级
  指通过建立异地容灾中心，做数据的远程备份，在灾难发生之后要确保原有的数据不会丢失或者遭到破坏
  在数据级容灾这个级别，发生灾难时应用是会中断的
  在数据级容灾方式下，所建立的异地容灾中心可以简单地把它理解成一个远程的数据备份中心
  数据级容灾的恢复时间比较长，但是相比其他容灾级别来讲它的费用比较低，而且构建实施也相对简单。
  但是，“数据源是一切关键性业务系统的生命源泉”，因此数据级容灾必不可少

• 应用级
  在数据级容灾的基础之上，在备份站点同样构建一套相同的应用系统，通过同步或异步复制技术，这样可以保证关键应用在允许的时间范围内恢复运行，尽可能减少灾难带来的损失，让用户基本感受不到灾难的发生，这样就使系统所提供的服务是完整的、可靠的和安全的

• 业务级
  全业务的灾备，除了必要的 IT 相关技术，还要求具备全部的基础设施
  其大部分内容是非IT系统（如电话、办公地点等），当大灾难发生后，原有的办公场所都会受到破坏，除了数据和应用的恢复，更需要一个备份的工作场所能够正常的开展业务

HA 和 DR 的关系

• HA 往往指本地的高可用系统，表示在多个服务器运行一个或多种应用的情况下，应确保任意服务器出现任何故障时，其运行的应用不能中断，应用程序和系统应能迅速切换到其它服务器上运行，即本地系统集群和热备份。HA 往往是用共享存储，因此往往不会有数据丢失（RPO = 0），更多的是切换时间长度考虑即 RTO

• DR 是指异地（同城或者异地）的高可用系统，表示在灾害发生时，数据、应用以及业务的恢复能力。异地灾备的数据灾备部分是使用数据复制，根据使用的不同数据复制技术（同步、异步、Strectched Cluster 等），数据往往有损失导致 RPO >0；而异地的应用切换往往需要更长的时间，这样 RT0 >0

• 从故障角度，HA 主要处理单组件的故障导致负载在集群内的服务器之间的切换，DR 则是应对大规模的故障导致负载在数据中心之间做切换

• 从网络角度，LAN 尺度的任务是 HA 的范畴，WAN 尺度的任务是 DR 的范围。

• 从云的角度看，HA 是一个云环境内保障业务持续性的机制，DR 是多个云环境间保障业务持续性的机制

• 从目标角度，HA 主要是保证业务高可用，DR 是保证数据可靠的基础上的业务可用

OpenStack HA

OpenStack 部署环境中，各节点可以分为几类：

• Cloud Controller Node （云控制节点）：安装各种 API 服务和内部工作组件（worker process）
  同时，往往将共享的 DB 和 MQ 安装在该节点上
• Neutron Controller Node （网络控制节点）：安装 Neutron L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等 Neutron 组件
• Storage Controller Node （存储控制节点）：安装 Cinder volume 以及 Swift 组件
• Compute node （计算节点）：安装 Nova-compute 和 Neutron L2 Agent，在该节点上创建虚机
  构建准则：
• 能 A/A 尽量 A/A，不能的话则 A/P （RedHat 认为 A/P HA 是 No HA）
• 有原生（内在实现的）HA方案尽量选用原生方案，没有的话则使用额外的HA 软件比如 Pacemaker 等
• 需要考虑负载均衡
• 方案尽可能简单，不要太复杂

云控制节点 HA

云控制节点的 A/A HA 方案

云控制节点的 A/P HA方案

可以使用 Pacemaker + Corosync 搭建两节点集群实现 A/P HA 方案

存储控制节点 HA

计算节点和虚机 HA