【IT168 专稿】Web集群服务器随着越来越多的商业网站的采用变得逐渐流行起来，而商业网站一个重要的前提就是必须具备高可用性，保证24×7小时正常运行。因此研究Web集群服务器的可用性具有重要的意义，但以前对Web 集群服务器的研究主要集中在高性能和可扩展性方面，提供高可用性仅仅通过软硬件冗余，并没有进行更深入的研究。

    Linux 高可用项目在这方面做了一些工作，对后端节点组（back-end nodes）使用了MON 进行故障检测，但实用性不高。本文从这点出发把后端节点组作为研究对象提出了一种新的故障检测与恢复方法。

    系统的可用性(availability)一般由系统的正常运行时间(uptime)来度量，一般表示为：

uptime = MTBF/ (MTBF + MTTR)   （1）

    式（1）中MTBF 是平均无故障时间；MTTR 是平均故障修复时间。节点的MTBF一般固定，所以提高可用性就是通过减少MTTR来实现。

Web 集群服务器的结构和特点

     一个简单的Web 集群服务器主要由负载均衡器和一组后端节点构成，并用Ethernet 交换机相连。负载均衡器配置两个网卡：一个用来与客户进行通信；另一个用来与后端节点组进行通信，为客户提供单一的入口点，并把客户的请求均衡地分发到所有的后端节点中，图1是一个简单Web 集群服务器。 

图1  Web 集群服务器结构

    集群服务器的特点：

(1) http 是无状态的协议，没有上下文，不维护连接的状态信息，到达负载均衡器的每个请求都要分发到某个后端节点上。这就要求在转发每个请求时，负载平衡器要知道后端节点的实时状态信息，从而避免向发生故障的后端节点发送请求；

(2) 在集群服务器中，后端节点是请求的执行者，负载均衡器通过停止向发生故障或超负荷的后端节点转发请求可以向客户屏蔽Web 集群服务器中的故障。

存在的问题

     Linux高可用的MON 模块驻留在负载均衡器上，如图2(a)所示。每隔一定的时间间隔执行ping 命令，来测试各后端节点的状态是“死”还是“活”，并通过发送测试页面来检测后端节点Web 服务的可用性。当检测出故障时发出告警信息并停止向该后端节点发送请求。这种方法有以下不足：

(1)  由于MON 模块驻留在负载均衡器上定期检测和接收后端节点的状态信息，占用了负载均衡器的资源，特别在系统负载过重时这种方法会降低了负载均衡器调度和转发请求的速度；

(2)  只有当后端节点发生故障，才能真正诊断到故障；故障诊断时间过长；

(3)  在负载均衡器中，一个新的请求到达就会发生一次调度和转发。这样调度的时间间隔要远小于检测服务器状态的时间间隔，造成大部分请求在调度时所基于的后端节点状态信息是过时的，有可能产生调度错误。

 (a) MON的结构

 (b) 改进方法的结构

改进的方案

    新的改进方案中，在每个后端节点中驻留一个检测进程，在负载均衡器LB 中仅有一个状态接收进程，负责接收由检测进程发送的对应后端节点的状态信息，并用状态信息来修改负载均衡器的调度参数，如图2(b)。 检测进程采用动态调整的时间间隔来发送后端节点的状态信息，时间间隔的调整根据后端节点的负载，通过检测后端节点的请求连接数，来确定下一次发送状态信息的时间间隔。新的方法中引入了故障猜测状态，这时对应后端节点达到最大连接数，这种情景下若再转发请求给该后端节点，后端节点可能会丢弃请求。

    具体方法如下：在负载均衡器中为每个后端节点状态信息表项增加一个计数器，每隔一定时间(如经验值200ms)，计数器加1。当接收到某个后端节点的状态信息，如果状态信息是不正常的，如httpd进程处于非活动状态，这时会修改调度参数，停止对该后端节点转发请求，否则计数器清零。这样对应后端节点的负载就反映在每个计数器的值上。

    计数器共设置两个阈值：第1个阈值对应的是后端节点已达到最大连接数(设置为10) ；第2个阈值对应的是确认服务器真正发生故障(设置为50)。当计数器到达第1个阈值，认为该后端节点进入故障猜测状态，负载均衡器停止向该后端节点发送新的请求。当计数器达到第2 阈值，认为该后端节点进入故障状态。当负载均衡器确认后端节点处于故障状态，启动故障恢复动作。根据故障的情景，如果后端节点没有停机，可以采用远程启动Web 服务；如果后端节点已停机，可以采用智能硬件远程启动后端节点，如使用wake-online 或IPMI，然后启动Web 服务。

    连接数可以反映正在处理和等待的请求数目，在一定程度上可以指示后端节点的实时负载。检测程序，主要检测状态信息，如CPU、 内存磁盘的利用率、后端节点的连接数(real_conn)和apache服务器的守护进程httpd的状态。

    后端节点的最大连接数max_conn可以测试出，first_threshold是预设的第1个阈值对应的时间间隔(2s)。我们采用下面的方法简单的计算检测状态的下一时间间隔：

next_interval = real_conn / max_conn * first_threshold   （2）

    检测进程发送后端节点状态信息的过程如下：

(1)  检测程序检测后端节点的状态信息连接数和httpd 状态；

(2)  向负载均衡器的接收进程发送状态信息；

(3)  使用式(2)计算下一次发送状态信息的间隔next_interval；

(3) 检测程序等待next_interval 返回(1)执行。

    这样做的目的是为了当后端节点负载过重时，通过延长检测间隔，减少因检测和发送状态信息带给后端节点和负载均衡器资源的额外开销；同时，延长发送状态信息的时间间隔，可以变相地告知负载均衡器，后端节点负载过重，从而减少向后端节点转发请求。

改进方案的优点

    采用改进的方案，很好地解决了以上提到的问题。

    (1)  在新的方案中，检测进程根据后端节点的负载动态地调整发送的时间间隔。这样在系统负载过重时，负载均衡器接收状态信息的频率也减少，从而减少对负载均衡器资源的额外开销。同时原来MON中的检测后端节点和Web 服务状态的任务是由后端节点的检测进程完成。所以新方案与MON 中负载均衡器采用定期发送检测信息和接收后端节点的状态信息的方法相比，在负载过重时，减少了对负载均衡器性能的影响。

    (2)  在新的方法中，当负载均衡器的某个计数器达到第1个阈值，认为对应的后端节点达到故障猜测状态，负载均衡器中的调度程序立即停止向该后端节点发送请求，从而屏蔽故障。在MON 中负载均衡器只有检测到后端节点发生故障时，才告知调度程序进行故障屏蔽。所以新的方法与MON 相比，减少了MTTR ，从而提高可用性并保证整个系统处于稳定状态。

    (3)  在负载均衡器中为每个后端节点保存着一个计数器，该计数器与后端节点的负载存在实时的对应关系，改进了请求调度时状态信息过时的问题。

试验测试

    设计一个试验环境，结构如图1所示。所有的计算机使用10Mbps交换机相连。所有节点运行操作系统Linux 9.0内核是2.4.20-8。

    硬件配置：负载均衡器与2个后端节点的CPU为AMD xp2000+，内存256MB；两个客户端P Ⅲ 800MHz 内存128MB。

   为了模拟后端节点达到最大的连接数，把客户端1的IP设置为集群的内部IP，如表1 。这样客户端1可以不经过负载均衡器，向某个后端节点发送请求。试验中，每隔5min使用Httperf向后端节点1发送请求，使后端节点1超载，持续10s。

表1  各节点的IP配置

     客户端2 使用Httperf向Web 集群服务器发送请求，请求速率采用固定的值，不能使Web 集群服务器超载，保证在集群服务器在不发生故障的情景下，httperf 测试的总请求数和响应数相等。在我们测试的环境下当后端节点发生故障，负载均衡器未屏蔽故障前，发送到该故障的服务器的请求，不会返回响应；当后端节点超载，负载均衡器未屏蔽故障前，会使部分请求丢弃部分，请求返回响应。所以可以通过响应的请求个数来计算MTTR 和MTBF， 计算公式如下：

MTBF＝ 总响应数 / 响应速率

    假设测试1h，那么1h 中的MTTR 为：

MTTR ＝1h － MTBF

    分别把改进方法和Mon加入到试验环境进行测试。Mon中的初始设置为http 服务的检测间隔为2s，并立即告知调度程序；改进方案设置与前面提到的一致。分别测试1h 的MTTR 分别为27.74s 和45.39s 。与Mon 相比，使用该改进方案，MTTR 减少了63% 这充分说明改进方法是非常有效的。

小结

     后端节点是集群服务器中请求的真正处理者，研究后端节点的故障修复对提高整个集群服务器的可用性非常重要。本文针对现有的故障检测后端节点的不足，提出了新的改进方案。在模拟环境下测试，我们的算法非常显著地减少了MTTR， 提高了后端节点的可用性，从而提高了整个集群服务器的可用性。