第3章　构建高可用集群

可用性是指系统在执行任务期间，可以按照既定要求正常工作的可能性。可用性是工业界用来衡量系统故障率的通用方法，在信息计算领域有广泛的应用。不同计算机系统依据支持的业务不同，而对可用性有不同的需求。比如，对于某些在同一时区集中办公的中小型公司，面向其内部的管理平台可能只需要保证在上班时间的可用性；而面向全球用户的互联网应用，对可用性的要求就立刻提升至24X7。系统可用性低，意味着系统功能失效时间占比高，而任何时刻的系统功能失效带来的都是直接经济损失和潜在的客户流失。在互联网世界，系统可用性故障往往会在社交媒体上造成较大的负面影响，降低客户对品牌的信任度，进而间接影响潜在客户的转换。公有云服务的每一次大规模宕机实践，都是社交媒体的一次狂欢，其产生的客户流失及直接经济损失，均可按照既定公式量化。

量化系统可用性指标是评估系统可用性对业务影响的第一步。针对不同行业，系统可用性在业界有基于相似评估指标的计算公式。以互联网应用为例，其计算公式可简化为如图3-1 所示的公式，系统可用性指标（Ao）等于系统故障间隔时间（Mean Time Between Failure，MTBF）除以系统故障间隔时间和平均故障修复时间（Mean Time To Repair，即MTTR）的总和。

MTBF 是指两次故障的平均间隔时间，也就是平均正常工作时间，该值越高，代表系统的可用时长越长。MTTR 是指平均故障修复时间，其越短，代表出现故障后系统恢复所需要的时间越短。显而易见，构建高可用应用的两个主要目标就是提升 MTBF 和降低MTTR，即减少故障、提升故障恢复效率。

可用性的期望可以通过N 个 “9” 来表示。表3-1 展示了不同可用性级别的系统，在一年时间跨度中允许的最长宕机时间。比如，对于 “4 个9” 的系统，一年内系统最长不可用时间为50min；对于互联网应用，影响可用性最大的可能因素是系统变更，如变更中引入的硬件不兼容、软件bug、配置错误，甚至人为失误。特别是一些高并发的场景，虽然服务只停了几分钟，但对整个公司业务的影响可能是非常大的，造成的经济损失可能是巨大的，从而大多数互联网应用将 “4 个9” 或 “5 个9” 设定为目标。由于互联网应用要求快速迭代、频繁变更，加之变更可能引起系统的可用性故障，因此把高可用控制在一定预期是最经济的决策。

为了实现高可用（High Availability，即HA）的目标，对基础云设施来说，在设计和搭建集群时应该考虑两个方面：在某个故障发生后，服务是否依然可用；灾难性故障造成服务不可用时，能否通过故障转移或者数据修复手段恢复服务。具体地，高可用要求服务具有较高的容灾和数据备份能力。服务容灾能力能够降低或消除故障的影响；数据备份能够保障服务快速恢复成可用状态。下面具体讲一下容灾和数据备份的策略和方法。

1.容灾

在计算机领域，故障可以划分为硬件故障和软件故障：

（1）硬件故障（Hardware Failure）。

工业界使用 “浴盆曲线” 来描述硬件故障，通常硬件故障率随着时间会呈U 型曲线。具体来说，在设备投产初期，由于兼容性、配置等问题会有较高的故障率。而随着时间推移，故障率会逐渐降低，转为出现概率相对平稳的随机故障。随着设备老化，硬件的后期故障又会逐渐增加。设备标明的MTBF 通常是平稳期的数值，无法体现整个生命周期的故障率。因此，为保证系统的整体高可用，会对硬件有固定的替换周期。数据中心有其固定的硬件更新（Technical Refresh）周期。通常的做法是：间隔数年，重新购买和更换设备。硬件故障还受外部环境的影响，例如断电、地震、火灾或者光纤被挖断等。

（2）软件故障（Software Failure）。

软件会越来越复杂和庞大。软件的故障率与人息息相关。在软件项目构建与发展的过程中，人为错误难以避免，下文只列出最关键的几点：

● 开发团队技能水平：经验丰富的工程师往往能在早期发现和规避问题，减少不必要的后期变更。

● 代码复杂度：简单的代码有助于提升代码质量。

● 软件开发和运营变更流程控制：设计和代码审查、系统变更控制等。

对于云计算平台，构建高可用集群是核心目标，就是防止局部硬件或软件故障影响整个云平台，以及保证运行在云平台上的用户应用的可用性。通俗地讲，高度可用的系统在任何给定的时刻都能正常工作，具有极强的自愈能力。

2.数据备份

云上的数据确保安全、健全和可用。在灾难性故障发生后，支持任意时间点数据的快速恢复。这就涉及云基础平台提供的数据加密能力、备份能力、校验能力和恢复速度。通常来说，云平台上提供的多种备份方案，还可以采用几种备份方案相结合的方式来保护云上服务的备份数据。在数据备份时，应该避免如下三个问题：

（1）备份策略笨重。

传统备份方案有全量、增量和差异备份等方式。在选用备份方式时，应考虑系统的存储开销。在云场景中，数据量相较于传统服务大出十倍甚至上千倍。备份的开销影响到业务的性能和安全，显然是不合适的。

（2）恢复速度慢。

一旦数据规模很大的时候，恢复速度慢会使系统宕机事件增长。

（3）数据划分粒度粗。

在传统的物理机数据中心时代，关键业务都可能是共享数据库的。在发生灾难性故障时，需要恢复的数据量大。在云场景中，应尽可能考虑微服务，并且对数据进行独立存储和备份。