更新时间:2024-04-18 GMT+08:00

健康检查介绍

负载均衡器会定期向后端服务器发送请求以测试其运行状态,这些测试称为健康检查。通过健康检查来判断后端服务器是否可用。

负载均衡器如果判断后端服务器健康检查异常,就不会将流量分发到异常后端服务器,而是分发到健康检查正常的后端服务器,从而提高了业务的可靠性。当异常的后端服务器恢复正常运行后,负载均衡器会将其自动恢复到负载均衡服务中,承载业务流量。

如果您的业务对负载比较敏感,过于频繁的健康检查报文可能会对您的正常业务产生影响。您可以根据实际的业务情况,通过增大健康检查间隔,或者将七层健康检查改为四层健康检查等方式来降低对业务的影响。如果您的业务系统自身有健康检查机制,也可以关闭负载均衡器的健康检查,但是为了保障业务的持续可用,不建议这样做。

健康检查协议

您可以在创建后端服务器组和创建监听器时为后端服务器组配置健康检查,通常,使用默认的健康检查配置即可,也根据业务需要选择不同的健康检查协议。

您也可以在后端服务器组创建后修改健康检查,详情可见修改健康检查配置

后端服务器组的后端协议与支持的健康检查协议存在匹配关系,详情请参见表1

表1 后端服务器组支持的健康检查协议(独享型)

后端服务器组的后端协议

健康检查协议

TCP

TCP、HTTP、HTTPS

UDP

UDP

QUIC

UDP

HTTP

TCP、HTTP、HTTPS

HTTPS

TCP、HTTP、HTTPS

TCP健康检查

对于四层(TCP)和七层(HTTP/HTTPS)后端协议,您可以配置TCP健康检查,通过发起TCP三次握手来获取后端服务器的状态信息,如图1所示。

图1 TCP健康检查

TCP健康检查的机制如下:

  1. ELB节点根据健康检查配置,向后端服务器(IP+健康检查端口)发送TCP SYN报文。
  2. 后端服务器收到请求报文后,如果相应的端口已经被正常监听,则会返回SYN+ACK报文。
    • 如果在超时时间内没有收到后端服务器的SYN+ACK报文,则判定健康检查失败。随后发送RST报文给后端服务器中断TCP连接。
    • 如果在超时时间内收到了SYN+ACK报文,则判定健康检查成功,并进一步发送ACK报文给后端服务器。随后发送RST报文给后端服务器中断TCP连接。

正常的TCP三次握手后,会进行数据传输,但是在健康检查时会发送RST中断建立的TCP连接。该实现方式可能会导致后端服务器中的应用认为TCP连接异常退出,并打印错误信息,如“Connection reset by peer”。解决方案如下:

UDP健康检查

对于四层(UDP)后端协议,默认配置UDP健康检查,通过发送UDP探测报文获取后端服务器的状态信息,如图2所示。

图2 UDP健康检查

UDP健康检查机制如下:

  1. 四层ELB节点根据健康检查配置,向后端服务器发送ICMP Echo Request报文。
    • 如果在超时时间内没有收到ICMP Echo Reply报文,则判定健康检查失败。
    • 如果在超时时间内收到了ICMP Echo Reply报文,则向后端服务器发送UDP探测报文。
  2. 如果在超时时间内没有收到后端服务器返回的ICMP Port Unreachable报文,则判定健康检查成功。否则,判定健康检查失败。

HTTP健康检查

对于四层(TCP)和七层(HTTP/HTTPS)后端协议,您可以配置HTTP健康检查,通过HTTP GET请求来获取状态信息。检查原理如图3所示。

图3 HTTP健康检查

HTTP健康检查机制如下:

  1. ELB节点根据健康检查配置,向后端服务器(IP+端口+检查路径)发出HTTP GET请求(可以选择设置域名)。
  2. 后端服务器收到请求后,根据服务的情况返回相应的HTTP状态码。
    • 如果七层ELB节点在响应超时时间内收到了后端服务器的响应,将HTTP状态码与预置的状态码进行对比,如果匹配则认为健康检查成功,后端服务器运行正常。
    • 如果七层ELB节点在响应超时时间内没有收到后端服务器的响应,则判定健康检查失败。

HTTPS健康检查

对于四层(TCP)和七层(HTTP/HTTPS)后端协议,您也可以配置HTTPS健康检查。HTTPS健康检查首先通过TLS握手建立SSL连接,再通过发送加密的HTTP GET请求来获取后端服务器的状态信息。检查原理如图4所示。

图4 HTTPS健康检查

HTTPS健康检查机制如下:

  1. ELB节点向后端服务器发送Client Hello请求,与后端服务器建立SSL连接。
  2. ELB节点收到后端服务器返回Server Hello报文后,根据健康检查配置,向后端服务器(IP+端口+检查路径)发出加密的HTTP GET请求(可以选择设置域名)。
  3. 后端服务器收到请求后,根据服务的情况返回相应的HTTP状态码。
    • 如果七层ELB节点在响应超时时间内收到了后端服务器的响应,将HTTP状态码与预置的状态码进行对比,如果匹配则认为健康检查成功,后端服务器运行正常。
    • 如果七层ELB节点在响应超时时间内没有收到后端服务器的响应,则判定健康检查失败。

健康检查时间窗

健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有连续多次检查成功或失败后,才会进行状态切换。

健康检查时间窗由表2中的三个因素决定:

表2 健康检查时间窗的影响因素

影响因素

说明

检查间隔

每隔多久进行一次健康检查。

超时时间

等待服务器返回健康检查的时间。

健康检查阈值

判定健康检查结果正常或异常时,所需的健康检查连续成功或失败的次数。

健康检查时间窗的计算方法如下:

  • 健康检查成功时间窗 = 超时时间×健康检查正常阈值 + 检查间隔×(健康检查正常阈值-1)
  • 健康检查失败时间窗 = 超时时间×健康检查异常阈值 + 检查间隔×(健康检查异常阈值-1)

图5所示:

  • 检查间隔:4s
  • 超时时间:2s
  • 健康检查异常阈值:3次
健康检查检测到后端服务器从正常到失败状态,健康检查失败时间窗 = 超时时间×健康检查异常阈值+检查间隔×(健康检查异常阈值-1) = 2 x 3+4 x (3-1) = 14s。
图5 健康检查失败时间窗

健康检查异常排查

如果您的健康检查异常,排查方法请参考健康检查异常如何排查