前言：可以说健康检查机制是负载均衡的一个必须功能，我们本篇就来详细的讲述。

    本篇有点长，为了使得看的不累，特此将文章拆分为上下篇：

    本篇议题如下：

基本的健康检查

基于应用的健康检查

应用的依赖性

 

系列文章：

 

 

      通过健康检查来确定服务器和应用的健康状况是负载均衡器器一个非常重要的功能。没有负载均衡器，客户端可能会将请求发送到已经停机的服务器上。网络管理员必须手动干预替换这台服务器，或者排除服务器的故障。有时服务器可能没有停机，但是因为某种原因，比如软件的漏洞，服务器上面运行的应用系统已经不能正常工作。比如Web应用可能正常运行，但它返回的页面却是错误的内容。负载均衡器能够检测这些情况并立即将客户请求导向到正常的服务器而不需要管理员的干预。

 

      总的来说，健康检查分有两类：带内健康检查和带外健康检查。带内健康检查就是负载均衡器观察客户端跟服务器之间的流量判断服务器是否健康。例如，如果负载均衡器发送一个客户端的SYN数据包到真实服务器，但是没有收到SYN ACK数据包回应，负载均衡器就会怀疑这台真实服务器有问题。负载均衡器也可以直接发送健康检查的数据包来检验真实服务器是否健康，这种数据包是由负载均衡器自己产生的。

 

1 基本的健康检查

 

    负载均衡器可以提供多种健康检查方式，能够在OSI不同层面进行基本的健康检查：

    二层的健康检查就是发送一个ARP请求查找给定IP地址的MAC地址。负载均衡器上面配置了真实服务器的IP地址，它会给每个IP地址都发送一个ARP请求，以找到其对应的MAC地址。服务器会响应这个ARP请求，除非它已经停机。

 

    三层的健康检查就是发送一个”PING”包到每个真实服务器的IP地址。”PING”是一个常用的程序，用来确认一个IP地址是否在网络中存在，或者用来确认主机是否运行。

 

   四层的健康检查，负载均衡器会尝试连接到服务器上面应用程序运行的特定的TCP或UDP端口。举例来说，假定真实服务器通过80端口来提供Web应用，负载均衡器会尝试建立一个到真实服务器80端口的连接。负载均衡器发送一个TCP SYN请求包到每个真实服务器的80端口，检查是否接收到回应的TCP SYN ACK数据包，如果没有收到，负载均衡器就认定相应服务器的80服务有故障。

 

    负载均衡器有必要针对服务器的每个应用端口分别做健康检查，比如，RS1的80服务可能有故障，但是21端口还能正常工作，负载均衡器可以继续利用这个服务器的21端口提供FTP服务，但是把WEB应用标记为停机状态。这样一来就提供了一个高效率的负载均衡解决方案，精细的健康检查有效地提高了服务器的处理能力。

 

2 基于应用的健康检查

 

    负载均衡器能够对常用的应用进行七层或者应用级的健康检查。针对应用级的健康检查没有统一的规范，而且不同的负载均衡产品也有不同的健康检查方法，让我们通过几个例子看一下应用健康检查包含哪些内容。

 

    针对Web服务器，负载均衡器可以发送针对某一特定URL的HTTP GET或者HTTP HEAD请求。可以让负载均衡器检查HTTP响应状态码，这样就可以检测到“404 Object not found”之类的错误响应。对于DNS服务器，负载均衡器可以发送DNS查询请求，把指定的域名解析成IP地址，并将结果与期望的结果做比对。对于FTP服务器，负载均衡器可以使用一个特定的账号和密码登陆到FTP服务器，来确认其是否正常工作。

 

3 应用的依赖性

 

    有时侯我们可能在真实服务器上面运行多个互相关联的应用。例如，WEB服务器在它的80端口提供购物车的Web应用，443端口则运行另外一个使用SSL协议的应用。SSL可以在通信过程中对信用卡信息等敏感内容进行加密，保证客户端和服务器之间通信的安全性。客户端首先浏览网页，把商品放进购物车，然后按下结帐的按钮。浏览器就会跳转到SSL应用，即提交信用卡信息来购买购物车中的商品。SSL应用通过WEB应用获取购物车的内容，如果SSL应用出现故障，那么WEB应用也应该停止服务。否则，就可能出现用户可以在购物车中增加商品但是不能访问SSL应用从而无法结帐的情况。

 

    许多负载均衡产品支持端口分组的功能，就是将多个TCP或者UDP端口组合在一起。如果这个组中任何一个应用出现故障，负载均衡器就认为这台真实服务器的所有应用都出现故障。这样就可以保证用户被导向到能够正常完成所有应用的服务器，从而保证交易的完整性。

 

另外，有关负载均衡的健康检查机制的实战使用，可以参看这篇文章（ ），具体的实现原理涉及到“内容检查”我们下一篇讲述。