健康检查是负载均衡中最基本的功能，也是整个负载均衡处理过程中最重要的环节。为了确保后端应用的高可用性，负载均衡通过定义的健康检查方法实时的对后端服务器或应用的健康状态进行检测，当后台服务器发生故障的时候，负载均衡会发现这些问题，并把服务器从应用服务组中排出，以避免将正常的客户端请求转发至故障的服务器上，以确保用户的能够正常访问后端的应用。
有时候，虽然服务器仍在运行，但是因为某种原因，比如：软件编写的漏洞或着相关联的应用中间件或数据库出了问题，导致服务器上运行的应用系统已经不能正常工作。在这种情况下，就需要采用一些能够检测应用状态（有时也称作基于应用内容）的健康检查方法。
基于ICMP协议的健康检查
利用ICMP进行健康检查是负载均衡最常用也是最基本的健康检查方式。负载均衡向被检测的服务器发送一个ICMP Request，如果能收到服务器的ICMP Reply，则说明服务器当前正常运行。一般情况下，ICMP健康检查只能说明服务器正在运行，但是，对服务器上运行的应用却无任何感知，因此，ICMP健康检查常用于一些链路负载均衡的部署环境，在应用服务器负载均衡的环境中，ICMP是不太可靠的。
基于TCP协议的健康检查
常见的应用程序都会使用一个固定的监听端口，比如：HTTP运行在80端口，FTP运行在21/20端口、HTTPS运行在443端口等等。因此，TCP健康检查就是负载均衡与对应的服务器应用端口进行TCP三次握手，如果握手成功，则说明服务器上的应用正常工作，如果握手失败，则说明当前服务器运行情况不正常。
基于UDP协议的健康检查
相较于TCP，UDP是无连接的协议，尽管协议交互更加简单，但是健康检查方法却并不简单。因为对于TCP来说，只要无法正常建立TCP连接，即可说明服务器端应用服务不正常。但是，利用UDP进行通信时，却并无严格要求服务器在收到UDP请求报文时必须进行确认。因此，UDP健康检查主要是看在发送出UDP的健康检查报文后，是否会收到ICMP unreachable的报文。如果没收到这种报文，就说明应用正常运行；如果收到这种ICMP报文，则说明应用发送了故障。
基于应用内容的健康检查方法
利用常见的ICMP、TCP和UDP健康检查方法，尽管能够对服务器的健康状态进行检查，但是，我们有时候会发现，尽管仍然能与服务器建立TCP三次握手，但是，服务器却无法正常响应客户端请求。在这种情况下，我们需要更进一步，采用基于应用内容的健康检查方法。
例如，对于Web应用服务器，我们可以模拟客户端发送一个HTTP请求，根据响应的内容或响应状态码来判断Web应用服务器的健康状态。
基于脚本的健康检查方法
在某些情况下，由于用户的一些应用特殊性，无法用与常规的健康检查方法进行健康检查。例如：在某些链路健康状态检查时，必须采用指定的源地址进行链路的健康检查，在这些情况下，我们可以用一个简单的脚本来解决问题。
A10的AX上提供了丰富的健康检查方法，从简单的ICMP、TCP、UDP到基于应用内容检测的HTTP、HTTPS、FTP、SIP等等。下面，我们将以A10网络的AX负载均衡为例，来说明这些常见的负载均衡的配置方法。
AX上默认的健康检查方法
在AX上，默认会对服务器以及服务器上配置的端口进行健康检查。对服务器本身采用ICMP的方式进行健康检查，对于服务器上配置的端口，则根据端口的类型，采用TCP或UDP的健康检查方法。如下面的例子：
slb server rs-test 192.168.203.101
port 80 tcp
port 8080 tcp
后端服务器上开启了80端口的HTTP服务，但是，尽管在负载均衡上配置了8080端口，但在服务器上该端口并未部署任何服务。无需额外配置任何健康检查方法，AX已经检测出目前这些服务的健康状态：
ax-1#show health stat
Health monitor statistics
...<省略部分输出内容>...
IP address Port Health monitor Status Cause(Up/Down) Retry PIN
--------------------------------------------------------------------------------
192.168.203.101 default UP 11 /7 @8 7 0 /0 0
192.168.203.101 80 default UP 20 /0 @0 0 0 /0 0
192.168.203.101 8080 default DOWN 0 /81 @3 0 0 /0 0
ax-1#
从上面的输出可以看出，AX对于服务器及应用端口采用的是默认的健康检查方法。对于服务器与其上的80/8080端口，AX的检测结果为：
1) 服务器可“ping”通，因此状态为“UP”；
2) 80端口可建立TCP连接，因此状态为“UP”
3) 8080端口无法建立TCP连接，因此状态为“DOWN”。
此外，还需要特别指出的是，为了降低AX健康检查的资源消耗，如果AX对服务器上的健康检查失败的话，AX将不会再对端口进行健康检查。因此，在实际部署时，需要确认服务器可以正常响应ICMP请求，否则，将会影响应用的健康检查结果。
健康检查方法中的全局参数
AX上的健康检查方法，有几个共性的参数：
1) 检查间隔时间(Interval)：指明AX进行健康检查的时间间隔，间隔时间越小，检查越精确，但系统用于健康检查的开销越大。
2) 最大重试次数(Max Retry)：指明AX在健康检查失败后，在将应用或服务器标记为DOWN之前，需要进行的健康检查次数。
3) 超时时间(Timeout)：说明AX等待回包的最大超时时间，超过这个时间，则说明健康检查有问题。
4) 恢复前重试次数(Up-Retry)：当后端应用健康检查失败，AX已经把某个服务器标记为DOWN状态。此时，服务器恢复正常状态，Up-Retry是指AX需要尝试健康检查成功几次才能把服务器真正标记为UP状态。
上面这四个参数是AX上健康检查方法的全局参数，可以在全局模式下修改，也可以在单独的健康检查方法中进行定义。一般情况下，建议采用默认配置，不要做任何修改。
全局模式下的修改命令如下：
health global interval 10 timeout 3 retry 2 up-retry 2
关闭AX上默认的健康检查方法
虽然AX上默认的健康检查方法简化了配置，使用效果也不错，但是，如果由于某种原因，我们需要关闭这些健康检查方法，我们有两种方法来达成这个要求：
1) 直接在服务器或端口下用 no health-check来关闭默认的健康检查方法。这种方法适用于关闭单独的服务器上的健康检查方法。具体方法参见下面的配置示例：
slb server rs-test 192.168.203.101
no health-check
port 80 tcp
port 8080 tcp
no health-check
!
健康检查方法中的全局参数
AX上的健康检查方法，有几个共性的参数：
1) 检查间隔时间(Interval)：指明AX进行健康检查的时间间隔，间隔时间越小，检查越精确，但系统用于健康检查的开销越大。
2) 最大重试次数(Max Retry)：指明AX在健康检查失败后，在将应用或服务器标记为DOWN之前，需要进行的健康检查次数。
3) 超时时间(Timeout)：说明AX等待回包的最大超时时间，超过这个时间，则说明健康检查有问题。
4) 恢复前重试次数(Up-Retry)：当后端应用健康检查失败，AX已经把某个服务器标记为DOWN状态。此时，服务器恢复正常状态，Up-Retry是指AX需要尝试健康检查成功几次才能把服务器真正标记为UP状态。
上面这四个参数是AX上健康检查方法的全局参数，可以在全局模式下修改，也可以在单独的健康检查方法中进行定义。一般情况下，建议采用默认配置，不要做任何修改。
全局模式下的修改命令如下：
health global interval 10 timeout 3 retry 2 up-retry 2
关闭AX上默认的健康检查方法
虽然AX上默认的健康检查方法简化了配置，使用效果也不错，但是，如果由于某种原因，我们需要关闭这些健康检查方法，我们有两种方法来达成这个要求：
1) 直接在服务器或端口下用 no health-check来关闭默认的健康检查方法。这种方法适用于关闭单独的服务器上的健康检查方法。具体方法参见下面的配置示例：
slb server rs-test 192.168.203.101
no health-check
port 80 tcp
port 8080 tcp
no health-check
!
2) 利用real server template 或real port template来关闭默认的健康检查方法。这种方法适用于关闭所有（或批量）的服务器上的默认健康检查方法。
slb template server default
no health-check
!
!
slb template port default
no health-check
!
默认情况下，real server及其下面配置的port都会加载默认的server template和port template，除非你在real server下引用了其他自定义的template。但是，如果server或port下还定义了其它的健康检查方法，则server（或port）下的健康检查方法优先级要高于template中定义的健康检查方法。
使用自定义健康检查方法
在AX使用自定义的健康检查方法需要两个步骤。首先，需要先定义健康检查方法，其次，在需要采用该健康检查方法的服务器或端口下加载自定义的健康检查方法。具体方法请参考下面的示例：
health monitor hc-http
method http url GET /check.html expect response-code 200,300-304
!
slb server rs-test 192.168.203.101
port 80 tcp
health-check hc-http
!
尽管越高级、越复杂的健康检查对应用健康状态的感知越精确，但是，这些检查方法对负载均衡资源及应用系统的资源使用都带来了一定的压力。因此，在考虑修改AX上默认的健康检查方法时，一定要充分考虑这些健康检查对服务器或负载均衡所产生的影响，在检查精度与系统负荷之间选择一个平衡点。
责编：张鹏宇
微信扫一扫实时了解行业动态
微信扫一扫分享本文给好友
资深技术经理：无线网络设备导致信..
网上邻居九招特殊的应用.doc
