高可用性的前生今世

题记：今天是2018年1月1日，这是一个特殊的日子，民间称为“三头”，意思是周头、月头、年头；我把它称为“3A”，指Kerberos协议的3A。无独有偶的是今年也是狗年，智能时代冥府门前的看门狗也进化为先进的机器人三头狗了。今天讨论的就是其中的一个A--Availability.

高可用性（High Availability，简写为HA）是一个有着很长历史的话题。随着时间的推移，各种各样的方法被发明并被使用，以保证应用、服务、数据库、网络和存储是可用的、可靠的，可以为企业提供及时的服务支持。由于企业越来越依赖于信息技术，因而对信息技术服务的可用性需求也在不断地提高。

大多数的HA解决方案主要依赖于硬件的冗余以及那些具有特殊目的的、被设计为更好地利用硬件的软件，虚拟化和云计算平台就属于早期的实现高可用性的方法。组织应该了解虚拟化的访问、应用、处理、网络和存储，这样更容易产生高可用性解决方案。他们还应该知道，作为HA解决方案的一部分，虚拟化使得离线云主机的使用变得更为容易。

HA解决方案可能是很昂贵的，在企业的方案组合中，并不是所有的业务都需要处于同一个可用性水平，关键业务功能可能需要较高水平的可用性，而那些业务支持功能可能就不需要那么高的可用性。下面介绍一些方法，企业可以根据自身需求为每一类工作负载选择适当的可用性实现方法。

--------------------------------------

集群网络的发展

HA的历史可以回溯到20世纪60年代，UI、应用逻辑、存储管理、数据管理和网络功能都在同一台主机上，这一时期，大家更多关注的是“容错”。随着大型主机系统使用多处理器、内存堆栈、存储适配器和网络适配器，开发出了监控单个组件运行状态的系统固件，并且在一个组件发生故障或者没有响应的时候将负载转移到幸存的其它组件上。IBM公司曾使用“并行系统综合体”这一特别的市场化名词来描述这类系统。

“并行系统综合体”的故障转移时间仅有几毫秒或者几微秒，使用这样系统的用户通常不会感到系统故障。但是这种解决方案通常非常贵，仅仅应用于最最重要的业务。IBM连续处理的大型机配置在今天依然可用。

与大型机连续处理系统一样，一些小型的计算机系统由冗余组件和专用固件组成，它们检测故障并快速转移工作负载，以便连续不断地处理数据。故障切换也可以实现仅需几毫秒，用户几乎察觉不到故障发生。与现有的微型计算机方案相比，这种方法也相当昂贵。HP集成和Stratus系统至今仍然可以满足这些业务需求。

期望满足性能、可靠性和可用性要求的供应商希望能够创建更多面向软件的解决方案，而不是只关注特殊目的的硬件和软件。一些公司聚焦集群和负载管理软件，他们策划了要么使用现成的网络解决方案要么使用具有特殊目的的集群网络解决方案。尽管集群系统可能早在20世纪60年代就被研究人员创造出来，但第一次商业应用却是在1977年Datapoint ARCnet系统，并在80年代获得了巨大的成功，一直应用至今。

客户集群网络，以解决最初的处理能力需求、访问可用性、应用可用性、数据库可用性、甚至于存储器可用性。硬件的配置可以有多种不同的方式，每一种方式都有一个不同的目标，这可以被认为是最早的访问、应用、处理、网络和存储虚拟化技术。下面的图描述了一个典型的具有2个结点的HA集群结构。

图1一个典型的双结点HA集群

--------------------------------------

访问集群

在访问集群时，最基本的硬件配置通过使用现在认为是“访问虚拟化”的技术保证整个系统的可用性。应用程序被安装在几个集群结点上，如果一个支持用户集群工作的结点出故障，访问负载就可以从故障结点转移到另外的集群结点。

这一点和下面的应用程序集群很相似，故障和工作负载管理都是在访问这一层面控制而不是在应用层面控制。应用程序本身感觉不到这一技术的存在，因而不需要特殊的API函数或者特别的结构设计以防止这种故障的发生。

这类集群依赖于将数据保存一个独立的用于存储访问服务的集群部分、或者需要另外一个集群来提供存储服务，或者依赖于一个SAN提供存储服务。只有这样才能保证即使应用程序运行系统本身出现故障，数据访问服务仍然是可用的。

访问虚拟化是这类集群的主要虚拟化技术，应用程序和存储宿主机可能部署在相同或者不同的数据中心。希捷、微软和VMware都提供这种技术。

--------------------------------------

应用程序集群

在应用程序集群中，基本集群硬件配置是通过现在被认为是“应用程序虚拟化”技术来实现的，以保证应用程序或应用程序组件可用。

应用程序虚拟化技术主要用于封装应用程序或应用程序组件，并对这些组件的访问进行控制。当用户提出使用这些应用程序请求，负载管理组件会检查系统处理能力的可用性，基于访问策略和处理能力的可用性选择一个系统来执行应用程序，然后启动应用程序或者发送用户请求给一个已经在运行的应用程序实例。

如果一个系统失败，用户负载可以自动地转移到集群中的另外一个系统，或者与已经运行在另一个系统上的负载相连接。

这与访问集群也很相似，故障转移和工作负载管理运行在应用程序组件上，应用程序必须架构在与应用程序虚拟化的工作负载管理工具共同工作的水平上，以保证负载监测、管理和迁移工作顺利进行。与访问集群不同的是，应用程序非常了解这一技术的存在，并且必须使用特殊的API函数或者是专门的结构设计以应对故障转移的发生。

这类集群依赖于存储在一个独立的存储访问集群部分的数据，或者依赖于SAN，即使宿主应用程序系统本身失效，数据仍然可用。在这里，访问虚拟化技术也经常被利用，使用户访问负载可以很容易地自动从失效系统迁移到新系统。

应用程序虚拟化是在这类集群主要的虚拟化技术；存储主机可以部署在相同或不同的数据中心。APPZero、希捷、微软、Novell以及VMware都提供这种应用程序虚拟化产品。

--------------------------------------

处理集群

在处理集群中，基本的集群硬件配置用于保证整个系统镜像的可用性，是一种处理程序虚拟化技术。

应用程序及其组件被构造为访问一个集群管理器，由集群管理器来监控应用程序、或者在另外一个系统上重启、又或者将工作应用迁移到另一个系统，具体依赖于系统失效类型。工作负载管理和迁移由底层操作系统统一管理。

与其他类型集群一样，这种方法依赖于存储在独立的访问存储或SAN集群部分上的数据，即使宿主应用程序系统本身失败，它也仍然可用。此外，利用访问虚拟化技术，可以方便地将用户访问从故障系统自动迁移到新系统。

在这个案例中，处理虚拟化“集群和工作负载管理”是一种主要的虚拟化技术，存储主机可以部署在相同或者不同的数据中心。希捷、微软和VMware提供这一类型的处理虚拟化技术。

--------------------------------------

数据库和存储集群

传统集群配置的另一个用途是支持并行或面向网格的数据库或存储。集群管理器的能力可以支持专门设计的数据库，如Oracle RAC或IBM pureScale DB/2是典型的专为这种类型配置的数据库产品。虽然这一技术确实提高了数据库的可用性，但它的主要目的是提高数据库性能或可扩展性。新的NoSQL数据库，如Couchbase，FoundationDB和MongoDB也被设计为支持大规模集群。

另外，也可以使用这种技术构建具有特殊目的的SAN。一般地，通用系统通过专用的高速SAN访问存储于系统中数据。

--------------------------------------

虚拟机软件应运而生

处理虚拟化技术、虚拟机（VM）软件和操作系统虚拟化和分区技术已经成为当今HA战略的重点。整个系统被封装、工作负载监控和管理、以及与系统映像迁移技术相结合正在取代以往的集群形式。

在这些系统映像中运行的应用程序不需要被编写为需要使用集群API接口。如果一个虚拟系统由于硬件故障而出现安全问题，整个虚拟系统可以被转移到另一台主机。这是HA的一个非常简单又实用的方法，故障转移可以在几秒或几分钟内处理好。

无论怎样，连续处理系统对于关键业务功能都是很好的宿主机，故障转移可以发生在毫秒甚至于微秒的级别。

--------------------------------------

设计中心发生的变化

高可用性领域正处于一个重要的设计中心迁移的最后阶段。过去，设计中心通过使用专用硬件和固件来保证系统的可用性和可靠性。现在，设计中心正在使用虚拟化技术来确保应用程序及其底层组件的可用。

无论硬件是系统、网络组件还是存储组件，都会发生故障；而适当设计的软件可以提供一种低成本、简单易用的策略来解决硬件故障问题。

一旦系统映像被封装，它就可以托管在本地系统、另一个数据中心系统、或者云服务提供商的数据中心系统上。

--------------------------------------

你究竟需要多高的可用性？

现在的世界，企业越来越需要自己的系统不断地可用，同时还要以不断减少的IT预算和员工数量来完成最大的工作量，这确实是一项非常具有挑战性的工作。

建议企业对他们的应用程序组合进行检查，确定每个应用程序到底需要多高的可用性，而不是系统能够提供的可用性是多少。有些应用程序问题不能被视为失效，而其他一些应用程序有时不可用也没什么不可以。

关键业务应用程序最好托管在连续处理系统上，不太关键的应用程序可能会乐于在集群上执行，甚至在云中的某一个地方来执行。

我的建议是为每个应用程序选择HA策略权限，而不是使用“一刀切”的方法。

--------------------------------------

HA的未来---软件定义存储

到目前为止，高可用性一直是许多软件定义存储解决方案面临的挑战，因为传统的高可用性故障转移机制需要使用特殊的硬件，故障转移的过程可能很慢，如果故障转移时间太长，可能导致VMS锁定并需要重新启动。因此很慢的故障转移是不可行的。

扩展开放存储技术如Ceph和Gluster采取根本不同的方法，在改变存储过程。Ceph通过对分布在多个服务器集群中的数据的多个副本，以确保没有单点故障，实现高可用性。关闭任何节点，或在某些情况下甚至关闭多个节点，都不会发生宕机故障。这是可用性技术向前迈出的重要一步，因为不再需要专用硬件和定制硬件来实现快速可靠的故障转移。

最关键的是这两种技术都降低了高可用存储云部署的成本。用户不再需要购买昂贵的存储厂商提供的专有解决方案，就能得到速度、可靠性和功能保障，包括快照、克隆、自动精简配置和巨大的可扩展性、无厂商锁定、所有商品硬件可扩展内存、固态硬盘（SSD）加速吞吐量和IOPS性能。

在不远的将来，对分布式文件系统的深度整合会拥有更广泛的受众，可以方便地安装、管理和维护，方便虚拟化环境的实现，保证用户应用级别的高可用性需求得到满足。

--------------------------------------

参考文献：

宋明秋. 《软件安全开发-属性驱动模式》.电子工业出版社.2016.5

Daniel Kusnetzky.In-Depth,HighAvailability: Past, Present and Future. June 25, 2015.

Scott Arenson.The Future of High Availability in Software DefinedStorage: Ceph and GlusterFS.October 24, 2014.