HA技术概况

Edna

HA技术概况 - [技术资料]2007-05-16高可用性（HA）集群通过一组计算机系统提供透明的冗余处理能力，从而实现不间断应用的目标。 高可用性（High Availability，简称HA）集群是共同为客户机提供网络资源的一组计算机系统。其中每一台提供服务的计算机称为节点(Node)。当一个节点不可用或者不能处理客户的请求时，该请求会及时转到另外的可用节点来处理，而这些对于客户端是透明的，客户不必关心要使用资源的具体位置，集群系统会自动完成。

HA集群系统硬件拓扑形式

基于共享磁盘的HA集群系统通过共享盘柜实现集群中各节点的数据共享，包含主服务器、从服务器、存储阵列三种主要设备，以及设备间的心跳连接线。

而基于磁盘镜像的HA集群系统不包含存储阵列。集群中两种服务器的本地硬盘通过数据镜像技术，实现集群中各节点之间的数据同步，从而实现集群的功能。

实际应用中，将节点1配置成“主服务器”，节点2配置成“从服务器”，主从服务器有各自的IP地址，通过HA集群App控制，主从服务器有一个共同的虚拟IP地址，客户端仅需使用这个虚拟IP，而不需要分别使用主从IP地址。这种措施是HA集群的首要技术保证，该技术确保集群服务的切换不会影响客户IP层的访问。

公网（Public Network）是应用系统实际提供服务的网络，私网（Private Network）是集群系统内部通过心跳线连接成的网络。

心跳线是HA集群系统中主从节点通信的物理通道，通过HA集群App控制确保服务数据和状态同步。不同HA集群App对于心跳线的处理有各自的技巧，有的采用专用板卡和专用的连接线，有的采用串并口或USB口处理，有的采用TCP/IP网络处理，其可靠性和成本都有所不同。近几年，基于TCP/IP技术的心跳线因其成本低、性能优异而被广泛采用。具体实现中主从服务器上至少各需配置两块网卡。

HA集群App体系结构

HA集群App是架构在操作系统之上的程序，其主要由守护进程、应用程序代理、管理工具、开发脚本等四部分构成，应用服务系统是为客户服务的应用系统程序，比如MS SQL Server，Oracle，Sybase，DB2 UDB，Exchange，Lotus Notes等应用系统App。

不是每一个应用程序都能够实现HA集群管理，也不是每一个HA集群App可以管理所有的应用程序，这是因为其代理模块(Agent)有不同的功能。HAApp的代理模块一般支撑使用频度最高的App，如上述所列举的数据库系统和邮件系统，但为了能够支撑更多应用实现HA集群，有的HAApp开放二次开发接口。

主从节点资源配置

HA集群App的本质是当主服务器出现故障时，从服务器及时接管主服务器的资源，这些资源包括处理器、内存进程和磁盘数据。接管进程意味着接管该服务进程的内存数据列表，采用共享磁盘技术方式的集群无需做存储数据接管，采用磁盘镜像技术方式的集群则使用本机的存储数据。

主从服务器的资源（处理器、内存、磁盘）配置具有科学性和技巧性。系统物理内存过低，会使系统频繁使用效率低下的“虚拟内存”，导致系统反应迟钝，也使得客户端响应缓慢，甚至出现“系统服务超时（Timeout）”形态的系统报错，没有达到高可靠的目的。所以，HA集群系统要求从服务器（故障切换节点）的内存容量应不小于主服务器的内存容量，其内存配置应该至少为应用系统对内存的基本需求。

从节点服务器需要的CPU数量应以不间断客户服务为目的。其CPU处理能力应不小于主服务器的CPU处理能力，若板卡、CPU等型号相同，从服务器的CPU个数应不少于主服务器的CPU个数。

采取磁盘镜像的从服务器存储空间应不小于主服务器存储空间。

总之，从节点资源的各项指标应该不低于主节点资源的各项指标。若系统采用多个主节点向一个从节点容灾时（N+1模式），从节点资源的配置策略需要依据系统管理员对整个系统定义的容灾安全级别来确定。假如主节点的个数为M，从节点的个数为1，系统管理员定义允许同时容忍N（N≤M）个主节点宕机，那么从节点的资源配置应为最大前N个主节点资源的各项指标之和。

HA集群部署模式

主/主 英文名称“Active/Active”，这是最常用的集群模型。它提供了高可用性，并且在只有一个节点在线时提供可以接受的性能。该模型允许最大程度利用硬件资源。每个节点都通过网络对客户机提供资源，每个节点的容量被定义好，使得性能达到最优，并且每个节点都可以在故障转移时临时接管另一个节点的工作。所有的服务在故障转移后仍保持可用，但是性能通常都会下降。



主/从 英文名称“Active/Standby”，或者“Active/Passive”。为了提供最大的可用性，以及对性能的最小影响，“主/从”模型需要一个节点在正常工作时处于备用状态，主节点处理客户机的请求，而备用节点处于空闲状态。当主节点出现故障时，备用节点会接管主节点的工作，继续为客户机提供服务，并且不会有任何性能上的影响。

混合型（Hybrid） 是上面两种模型的结合，只针对关键应用进行故障转移，这样可以对这些应用实现可用性的同时让非关键的应用在正常运作时也可以在服务器上运行。当出现故障时，出现故障服务器上的不太关键的应用就不可用了，但是那些关键应用会转移到另一个可用的节点上，从而达到性能和容错两方面的平衡。

不同HA集群App支撑不同的部署模式，一般有以下三种情况:

双机模式 非常普遍使用的一种方式，俗称“双机热备”。使用在应用系统单一、要求可用性高的环境中，由一个主服务器、一个从服务器和一个存储阵列等三个设备组成。

1+I模式 系统由一个主节点、若干个（I个）从节点以及一些辅助设备（存储阵列）等组成。使用在应用系统单一，要求可用性能极高的核心业务系统中。

N+I模式 系统由多个主节点、若干个从节点以及一些辅助设备（存储阵列、交换机）等组成。在实际应用中，一些用户并不满足上述两种模式，认为“冗余设备”太多，需要多个主节点（N个）可以灾备到任意多个（I个）节点上。根据应用的级别，调整从节点的数量，可以为一个，也可以为多个。主节点的数量可以为一个或者多个，根据应用需要随时调整搭配，但主节点为多个并不是同一个应用的“并行处理”，而是不同的应用。

集群系统状态监测和故障响应

1 网卡故障

集群结构中每个节点都通过双网卡与工作网络相连，即一主（H）一备（B）两条链路。在各节点正常工作的时候，工作网络除用于传递工作数据外，也用于传递H-B信号。同时心跳网络只传递H-B信号。即每隔一段时间各节点之间相互传递H-B信号，确认各节点都处于正常工作状态。

因此，有了H-B后，集群可以很轻易地发现节点的网卡故障，因为一旦某块网卡发生故障，发往该块网卡的H-B就会丢失。此时节点上的集群管理App会产生一个网卡互换的事件，即将主备网卡互换，包括各种地址的互换和工作状态的互换。并通知集群中各节点及工作网络。网卡互换通常在几秒内就可完成，并且这种转换对应用来说是透明的，只发生延迟但连接并不中断。

2 网络故障

如果发往某一个节点双网卡上的H-B包全都丢失，而心跳网络上的H-B仍然存在，那么集群App可以断定集群节点仍然正常，是工作网络发生故障。此时集群App则只能发出告警，并提供系统一个中断入口，可以通过该入口确定系统实行其他网络恢复的操作。

3 节点故障

如果不仅工作网络上的H-B信号全部丢失，而且心跳网络上的H-B也丢失，那么集群App将断定该节点发生故障。放在共享存储上的资源将由其他节点接管（根据N节点配置和N+1节点配置的不同，接管的节点将不同），接管的操作将由集群App和节点的操作系统共同配合来完成。

当整个节点发生故障时，集群App将故障节点的工作地址转移到接管节点上，对于网络上的Client来讲，服务地址没有发生变化。