资源管理、高可用与自动化（中）

比资源管理更贴近最终用户的是一系列的服务，可以是普通的邮件服务、文件服务、数据库服务，也可能是针对大数据分析的Hadoop集群等服务。对于配置这些服务来说，软件定义数据中心的独特优势是自动化。例如VMware的vCAC（vCloud Automation Center）就可以按照管理员预先设定的步骤，自动部署几乎任何传统服务，从数据库到文件服务器。绝大多数部署的细节都是预先定义的，管理员只需要调整几个参数就能完成配置。即使有个别特殊的服务（例如用户自己开发的服务），没有事先定义的部署流程，也可以通过图形化的工具来编辑工作流程，并且反复使用。

从底层硬件到提供服务给用户，资源经过了分割（虚拟化）、重组（资源池）、再分配（服务）的过程，看似增加了许多额外的层次。从这个角度看，“软件定义”不是免费的。但层次化的设计，有利于各种技术并行发展和协同工作。这与网络协议的发展非常类似。TCP/IP协议簇正是因为清晰地定义了各协议层次的职责和互相的接口，才能够使参与的各方都能协同发展。研究以太网的可以关注提高传输速度和链路状态的维护，研究IP层的则可以只关心与IP路由相关的问题。让专家去解决他们领域内的专业问题，无疑是效率最高的。

软件定义的数据中心的每一个层次都涉及许多关键技术。有些技术由来已久，但是被重新定义和发展了的，例如软件定义的计算、统一的资源管理、安全计算和高可靠等；有些技术则是全新的，并仍在迅速发展，例如软件定义的存储、软件定义的网络、自动化的流程控制。这些技术是软件定义数据中心赖以运转的关键，也是软件定义数据中心的核心优势。

高可用性（Availability）指的是一个系统在约定的时间段内能够为用户提供服务满足或超过约定的服务级别，如访问接入、任务调度、任务执行、结果反馈、状态查询等。而服务级别通常表述为系统不可用的时间低于某个阈值（Threshold）。如果任何一个关键环节出错或停止响应，则称目前系统状态为不可用。通常将系统处于不可用状态的时间称为停机时间（宕机时间）。可用性的量化衡量：可用性通常表述为系统可用时间占衡量时间段的百分比，通常可以采用一年或一个月作为衡量时间段，具体选择取决于服务合约、计量收费等实际需求。下表中给出了不同的可用性指标（由表可见，宣称达到7个9甚至11个9的系统，每年的宕机时间低到3s—0.3ms，殊为惊人，业界通常将5个9以上的系统称为零宕机时间系统）。

表：系统可用性与停机时间对照

可用性	停机时间/年	停机时间/月	停机时间/日
90%	36.5天	72小时	16.8小时
95%	18.25天	36小时	8.4小时

续表

可用性	停机时间/年	停机时间/月	停机时间/日
99%（2个9）	3.65天	7.2小时	1.68小时
99.9%（3个9）	8.76小时	43.8分钟	10.1分钟
99.99%（4个9）	52.6分钟	4.3分钟	1.0分钟
99.999%（5个9）	5.26分钟	25.9秒	6.05秒
99.9999%（6个9）	31.5秒	2.59秒	0.605秒
…	…
99.999999999%	0.3毫秒	25微秒	＜1微秒

零宕机时间（Zero-Down-Time）系统设计意味着一个系统的平均失效间隔时间大大超过了系统的维护周期（宕机时间）。在这样的系统中，平均失效间隔时间通过合理的建模与模拟执行计算得到。零停机时间通常需要大规模的组件冗余，在软件、硬件、工程领域屡见不鲜。例如，我们熟知的全球卫星定位系统（GPS）通常使用5个或以上的卫星来实现定位、时间与系统冗余就是一个典型的例子。类似的还有悬索桥（Suspension Bridge）的多根竖索就是典型的高冗余设计。

高可用性系统通常致力于最小化两个指标：系统停机时间（Down-Time）与数据丢失（Data-Loss）。高可用性系统至少需要保证在单个节点失败/停机的情况下，能够保持足够小的停机时间和数据丢失；同时在下一个可能的单节点失败出现之前，利用热备（Hot Standby）节点修复集群，将系统恢复到高可用性状态。

单点失效或单点瓶颈，即系统中任何一个独立的硬件或软件出现问题后，就会导致不可控的系统停机或者数据丢失。高可用性系统一个关键的职责就是要避免出现单点失效。为此，系统中的所有组件都要保证足够的冗余率，包括存储、网络、服务器、电源供应、应用程序等。更复杂的情况下，系统可能会出现多点失效，即系统中出现超过两个节点同时失效（失效时间段重叠，且互相独立）。很多高可用性系统在这种情况下无法幸存；当问题出现的时候，通常避免数据丢失具有更高的优先级，相对于系统停机时间而言。

为了达到99%甚至更高的可用性，高可用性系统需要一个快速的错误检测机制，以及保证相对很短的恢复时间。当然尽量长的平均失效间隔时间（MTBF）对保证高可用性也是至关重要的。简而言之，尽量减少出错的次数，出错后快速检测，检测到后尽快修复。

最常见的高可用性集群是两节点的集群，包括主节点与冗余节点各一个，也就是100%的冗余率，这也是集群构建的最小规模。主节点与冗余节点可以是单活（Active-Passive），也可以是双活（Active-Active）的，取决于应用程序的特性与性能需求。也有其他很多的集群采用了多节点的设计，有时达到几十甚至上百个节点的规模；多节点的集群设计起来相对复杂。常见的高可用性集群配置大致有以下几种。

·单活（Active-Passive）：冗余节点平时处于备用状态，并不对外提供服务。一旦主节点发生故障，冗余节点在最短的时间内上线并接管余下的任务。这种配置需要较高的设备冗余率，通常见于两节点集群。常见的备用方式有热备（Hot Standby）和冷备（Cold Standby）两种。以Hadoop系统的NameNode为例，采用的就是典型的Active-Passive策略，两个NameNode，主节点为Active，备用节点Hot Standby。

·双活或多活（Active-Active）：负载被复制或分发到所有的节点上；所有的节点都是活跃节点（或主节点）。对于完全复制的模式来说需要的节点相对较少，当运行结果出现不一致时可以采用多数投票生出原则（Vote Logic）。任何一个节点的失效都不会引起性能下降。此种模式也兼顾了负载均衡的考虑，当某个节点失效的时候，任务会被重新分配到其他活跃节点上。节点失效可能会带来一定的系统性能损失，具体比例则取决于宕机节点的数量，但不会引起全面宕机。以存储系统为例，EMC的VPLEX与NetApp MetroCluster都实现的是Active-Active高可用性。VPLEX甚至支持了三种不同模式：数据中心内的跨存储设备、跨数据中心同步以及跨数据中心异步的双活/多活、高可用与数据移动。

·单节点冗余（N+1）：类似于单活机制，提供一个处于备用状态的冗余节点。不同的是，主节点可能有多个；一旦某个主节点发生故障，冗余节点马上上线替换。这种模式多用于某些服务本来就需要多实例运行的用户系统。前面的单活模式实际上是这种模式的一种特例。

· 多节点冗余（N+M）：作为对单节点冗余机制的一种扩展，提供多个处于备用状态的冗余节点。这种模式适用于包含多种（多实例运行的）服务的用户系统。具体的冗余节点数取决于成本与系统可用性的权衡。

理论上还有其他一些设计模式，例如双活或多活与单/多节点冗余的结合，基于冗余率与性能保障的双重考虑。然而正如前文提到过的，增加冗余组件以及采用更复杂的系统设计，对整体的可用性来说未必是个好消息，某些时候负面效应甚至是主导的。因此在高可靠性系统设计的时候，还是要多遵循简单性原则。