健康检查介绍

健康检查协议

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

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

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

TLS协议与GRPC协议陆续上线中，已发布区域请以控制台实际为准。

健康检查源IP

独享型负载均衡器以ELB后端子网内的IP为健康检查源地址，向后端服务器发起健康检查探测请求。为确保健康检查结果正常，请确保后端服务器的安全组规则配置放行ELB后端子网所属网段，详情见配置后端服务器的安全组。

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”。解决方案如下：

• 采用HTTP健康检查。
• 后端服务器忽略健康检查的连接错误。

UDP健康检查

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

图2 UDP健康检查

UDP健康检查机制如下：

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

在大并发场景下，UDP协议的健康检查结果可能存在服务真实状态不一致的问题：

如果后端服务器是Linux服务器，由于Linux的防ICMP攻击保护机制，会限制后端服务器发送ICMP的速度。此时如果后端服务已经出现异常，但由于无法返回Port Unreachable报文，会导致负载均衡实例收不到ICMP应答进行判定健康检查成功，最终导致后端服务的真实状态与健康检查结果不一致。

HTTP健康检查

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

图3 HTTP健康检查

HTTP健康检查机制如下：

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

• 当独享型ELB实例的TCP监听器选择HTTP健康检查时，ELB会使用HTTP1.0发起探测。HTTP1.0采用短连接通信模式，即ELB发送完请求之后收到服务端拆链报文才会解析HTTP响应内容，所以请确保服务端发送完响应内容后立即主动断开TCP连接，否则会导致健康检查探测异常。
• 在HTTP健康检查请求中，User-Agent头字段主要用于标识此类请求为健康检查发出的探测请求。User-Agent的值可能随业务需求而动态调整，建议客户的后端服务请勿根据此header头做检验和判断。
• 当选定为“使用后端服务器的内网IP为域名”为健康检查域名时，由于Host请求头可能为空值，建议客户的后端服务请勿根据Host请求头做检验和判断。

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节点在响应超时时间内没有收到后端服务器的响应，则判定健康检查失败。

• 在HTTPS健康检查请求中，User-Agent头字段主要用于标识此类请求为健康检查发出的探测请求。User-Agent的值可能随业务需求而动态调整，建议客户的后端服务请勿根据此header头做检验和判断。
• 当选定为“使用后端服务器的内网IP为域名”为健康检查域名时，建议客户的后端服务请勿根据Host请求头做检验和判断。

TLS健康检查

对于HTTP、HTTPS和TLS后端协议，您可以配置TLS健康检查，通过TLS 握手，发送Client Hello，解析服务端发送的Server Hello来获取后端服务器的状态。

图5 TLS健康检查

TLS健康检查的机制如下：

1. ELB节点根据健康检查配置，向后端服务器（IP+健康检查端口）发送TCP SYN报文。
   • 如果在超时时间内没有收到SYN+ACK报文，则判定健康检查失败。
   • 如果在超时时间内收到了SYN+ACK报文，则向后端服务器发送会发送Client Hello（SSL协商），协商的版本号包括了TLSv1.0、TLSv1.1、TLSv1.2、TLSv1.3。
2. 如果在超时时间内收到后端服务器返回的Server Hello报文，则判定健康检查成功。否则，判定健康检查失败。

GRPC健康检查

图6 GRPC健康检查

GRPC健康检查机制如下：

1. ELB节点根据健康检查配置，向后端服务器（IP+端口+检查路径）发出POST或GET请求（可以选择设置域名）。
2. 后端服务器收到请求后，根据服务的情况返回相应的状态码。
3. ELB通过读取HTTP/2头中的grpc-status的值作为返回的GRPC状态码。
   • 如果七层ELB节点在响应超时时间内收到了后端服务器的响应，将返回的GRPC状态码与自定义的健康检查返回码进行对比，如果匹配则认为健康检查成功，后端服务器运行正常。
   • 如果七层ELB节点在响应超时时间内没有收到后端服务器的响应，则判定健康检查失败。

健康检查时间窗

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

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

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

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

如图7所示：

• 检查间隔：4s
• 超时时间：2s
• 健康检查异常阈值：3次

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

图7 健康检查失败时间窗

健康检查异常排查

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