1.4 业务系统高可用性概述

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

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系列大型机例外。

1.4.2 业务系统容灾恢复

HA与DR是有区别的，HA更多的是强调本地系统的高可用，即将某个应用系统运行在数据中心的多个服务器上，当其中的任一服务器出现任意故障时，应用程序和系统能迅速切换到其他服务器上运行从而保证业务系统的高可用性，其实现过程主要是本地系统的集群和数据的热备份，从设计上来讲，HA往往通过共享存储来实现数据的同步，因此通常RPO＝0，而更多要考虑的是RTO的设计。

DR则更多的是强调异地灾备中心的容灾恢复，即DR通常被认为是在另一数据中心重构恢复当前出现灾难数据中心的计划或过程。灾难（Disaster）是指由于人为或自然灾害致使当前数据中心内的IT系统受到严重破坏或者直接瘫痪，并最终导致相应的业务系统功能访问中断或者服务水平不可接受且达到特定时间的突发性、严重性、灾难性的事件，灾难的出现通常迫使当前数据中心的系统不得不切换到备用数据中心运行。容灾恢复即当灾难发生且生产数据中心受到严重程度破坏时在异地数据中心内恢复数据、应用或者业务的能力。容灾恢复的前提是企业具备容灾能力。容灾是指企业除了日常的生产数据中心以外，在异地还有备份的数据中心随时可以接管生产中心的业务系统，例如IBM倡导的“两地三中心”容灾方案，就是在同城建立备份中心，然后在地理位置更远的异地再建个容灾中心。衡量容灾系统的两个指标，仍然是RTO和RPO。图1-18显示了影响业务系统恢复时RTO和RPO的数据恢复方式与业务系统的恢复方式。

从图1-18中可以看到，如果数据中心之间进行的是数据的同步复制，则容灾恢复过程中的RPO是秒级别的，即几乎不丢失数据，而如果是通过带库之类的备份恢复，则可能会丢失几天到几周不等的数据。同时，如果业务系统建立有HA，则恢复过程几乎是秒级别的，而如果是通过热备数据中心来恢复，则可能需要几个小时到几天不等。容灾恢复总体上可以分为数据级别、应用级别、业务级别：

❑数据级别。数据级别的容灾通常是建立异地容灾中心，通过数据的远程备份来实现，数据级别的容灾可以确保在灾难发生之后原有的数据不会丢失或者遭到破坏。但在发生灾难时应用是会中断的，因为数据级的容灾方式其实就是一个远程的数据备份中心，并不具有业务恢复的能力，此外，数据级容灾的恢复时间比较长，但是相比其他容灾级别来讲它的费用比较低，而且构建实施也相对简单，即RTO最长，总体拥有成本（TCO）最低。

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

❑业务级别。几乎就是生产数据中心的模板复制，全部业务系统都做了应用级别的灾备，同时除了必要的IT相关人员和技术，还要求具备全部的基础设施。在严重灾难发生后，原有的办公场所都会受到破坏，在业务级别的容灾环境下，除了数据和应用的恢复，业务系统的正常开展也要被恢复。当然，这一级别的容灾恢复RTO是最低的，同时TCO是最昂贵的。