《OpenStack高可用集群（上册）：原理与架构》—1.4 业务系统高可用性概述

1.4　业务系统高可用性概述

对于企业级用户而言，业务系统的高可用性（High Availability，HA）和容灾恢复（Disaster Recovery，DR），即通常所说的HADR是必须的，也是任何需要进入企业级应用的IT架构无法回避的问题，不管是传统IT架构，还是新型的云计算架构，都要面临如何实现HADR的过程。

图1-17　云计算进阶路线

1.4.1　业务系统高可用性

高可用性是确保企业重要业务系统持续性和非中断性运行的关键，高可用性是指本地系统在某个软硬件模块出现计划内停止运行或非计划内故障的情况下，基于本地系统的应用仍能继续提供访问的能力，并且这种非计划内的故障是随机的，可能是业务流程、物理设施或者IT软/硬件的故障。关于高可用性，最简单的描述就是企业某一台或几台服务器宕机了，但是企业用户却完全感觉不到应用访问上有何异常。通常，关键业务系统的高可用性需要由多台物理服务器提供的集群构成，一旦其中某台服务器宕机了，则在该服务器上运行的服务就会启动故障切换（Failover）。业界最常见的双机故障切换便是IBM的PowerHA，HA集群节点之间通过以太网络或者SAN网络（不是必须的）以及磁盘心跳进行彼此通信，一旦集群管理软件检测到某台服务器出现了网络或系统层面的故障，就会触发集群的Failover操作，将故障节点上的应用切至正常节点运行。在HA故障切换过程中，有两个切换成本维度是在设计高可用时必须考虑的：

RTO。RTO（Recovery Time Objective）是指故障恢复的时间，衡量的是故障恢复时间的快慢维度。RTO的最佳值是0，即故障被立即恢复，中间没有任何中断的时间；最坏情况便是无穷大，即故障后的服务永远恢复不了。通常RTO值为0和无穷大的情况都极少出现，RTO正常值的单位一般为秒和分钟，从几秒到几分钟不等，主要根据业务系统的软硬件和集群架构设计来决定。

RPO。RPO是指数据恢复的程度，衡量的是故障后数据恢复的完整性维度，数据恢复涉及企业的备份恢复及容灾策略，理想情况下，RPO的值为0，即没有任何数据丢失，恢复后使用的是同步的数据，如果RPO大于0，则意味着恢复后有数据丢失，例如RPO＝1，则意味着恢复后将会丢失一天的数据。

对于RTO和RPO而言，最理想的情况就是RTO＝RPO＝0，但是这几乎无法实现，或者说实现成本相当巨大，几乎很少有企业能够实现这类理想情况。从设计上来说，要保证RPO＝0，最简单的实现方式便是数据实时同步，即存储的数据对多个节点的读写来说都是完全一致的，不存在任意两个节点读取到不同数据的情况，具体的实现可以是共享存储，如开源的NFS或者IBM GPFS等都是这类共享存储的实现，另外一种实现方式就是存储硬件层面的实时同步，即不同节点可以读写不同存储，但是后端多台存储之间的数据一定是同步的，目前很多商业存储都能实现这点，如EMC的VPLEX Metro和IBM的SVC等产品。而对于RTO为0的实现，则是采用双活集群（Active/Active）和负载均衡的方式，多个节点上的应用随时都在对外服务，任何一个节点的故障都不会出现访问中断，而如果采用主备（Active/Passive）模式的HA集群，则需要谨慎考虑RTO的值，原则上是越小越好。关于业务系统的高可用性，一般通过全年的运行时间和宕机时间来计算，也即我们经常在各种公有云运营商SLA上面看到的几个9的可用性，高可用性的计算公式为：[1―（宕机时间）/（宕机时间＋运行时间）]，常见的主要有以下几个值：

1个9。即全年90.0%的可用性，全年365天的宕机时间即为36天12小时。

2个9。即全年99.0%的可用性，全年365天的宕机时间即为87小时36分钟。

3个9。即全年99.9%的可用性，全年365天的宕机时间即为8小时46分钟。

4个9。即全年99.99%的可用性，全年365天的宕机时间即为52分钟33秒。

5个9。即全年99.999%的可用性，全年365天的宕机时间即为5分钟35秒。

11个9。这个几乎是几年才宕机一次了，目前很少有云服务商能够做到这点，更不用说传统的IT架构了，当然IBM的z系列大型机例外。