负载均衡 健康检查

·开启健康检查后，无论后端服务器权重是多少（包括权重为0），负载均衡实例都会进行健康检查。你可在实例列表页面的“健康状态”列查看健康检查状态，或者在监听器的绑定后端服务详情页面查看健康检查状态。

·当后端服务器实例被判定为异常后，负载均衡实例自动将新的请求转发给其他正常的后端服务器，而不会转发到异常的后端服务器。

·当异常实例恢复正常后，负载均衡将其恢复至负载均衡服务中，重新转发请求给此实例。

·若健康检查探测到所有后端服务都有异常时，请求将会被转发给所有后端服务器。

·关闭健康检查，负载均衡将向所有后端服务器转发流量（包括异常的后端服务器），因此强烈建议你打开健康检查，允许负载均衡帮你自动检查并移除异常的后端服务器。

·默认被动健康检查，针对四层 TCP SSL 监听器、七层 HTTP/HTTPS 监听器，将默认配置被动健康检查能力（默认开启，不支持关闭）。CLB 向后端服务转发流量的同时并记录后端服务的健康状态。若转发失败则重试将流量转发至其他后端服务上，同时累计此后端服务失败次数1次，累计失败达到3次，则屏蔽该后端服务10秒，屏蔽时间结束后，恢复流量转发并继续记录后端服务的健康状态。

一、单监听器健康检查状态说明

根据健康检查探测情况，后端服务器的健康检查状态如下所示：

二、列表页健康检查状态说明

根据实例下所有监听器的健康探测情况综合展示。

三、TCP 健康检查

针对四层 TCP 监听器，你可以配置 TCP 健康检查，通过 SYN 包即发起 TCP 三次握手来获取后端服务器的状态信息。你还可以通过自定义协议的请求内容和返回结果来获取后端服务器的状态信息。

TCP 健康检查机制如下：

1. 负载均衡向后端服务器（内网 IP 地址+健康检查端口）发送 SYN 连接请求报文。

2. 后端服务器收到 SYN 请求报文后，若相应端口处于正常监听状态，则会返回 SYN+ACK 响应报文。

3. 若在响应超时时间内，负载均衡收到后端服务器返回的 SYN+ACK 响应报文，则表示服务运行正常，判定健康检查成功，并向后端服务器发送 RST 复位报文中断 TCP 连接。

4. 若在响应超时时间内，负载均衡未收到后端服务器返回的 SYN+ACK 响应报文，则表示服务运行异常，判定健康检查失败，并向后端服务器发送 RST 复位报文中断 TCP 连接。

四、UDP 健康检查

针对四层 UDP 监听器，你可以配置 Ping 探测和自定义探测。若你选择了 Ping 探测方式，则只是用 ICMP ECHO 报文进行探测。

健康检查机制如下：

1. 负载均衡向后端服务器的内网 IP 地址发起Ping命令；

2. 若Ping成功，则表示服务正常，判定健康检查成功；

3. 若Ping失败，则表示服务异常，判定健康检查失败；

若你选择了自定义探测方式，则可以细分为以下两种情况：

·第一种，如果仅配置“检查请求”的内容，没有配置“检查返回结果”，则使用 ICMP ECHO 报文+ UDP 探测报文。

健康检查机制如下：

3.1 负载均衡向后端服务器的内网 IP 地址发起Ping命令；

3.2 负载均衡向后端服务器（内网 IP 地址+健康检查端口）发送 UDP 探测报文；

3.3 若Ping成功，且在响应超时时间内，后端服务器未返回port XX unreachable的报错信息，则表示服务正常，判定健康检查成功；

3.4 若Ping失败，或者在响应超时时间内，系统收到后端服务器返回的port XX unreachable报错信息，则表示服务异常，判定健康检查失败；

·第二种，如果同时配置了“检查请求”和“检查返回结果”的内容，则仅使用 UDP 探测报文， 判断 RS 健康状态的条件为：收到 UDP 返回的报文，且与“检查返回结果”的内容匹配。

健康检查机制如下：

3.1 负载均衡向后端服务器（内网 IP 地址 + 健康检查端口）发送 UDP 探测报文；

3.2 若收到 UDP 返回的报文，且与“检查返回结果”的内容匹配，则表示服务正常，判定健康检查成功；

3.3 若在响应超时时间内，未收到 UDP 返回的报文或与“检查返回结果”的内容未匹配，则表示服务异常，判定健康检查失败；

五、HTTP 健康检查

针对四层 TCP 监听器和七层 HTTP/HTTPS 监听器，你可以配置 HTTP 健康检查，通过发送 HTTP 请求来获取后端服务器的状态信息。

HTTP 健康检查机制如下：

1. 负载均衡根据健康检查配置，向后端服务器（内网 IP 地址+健康检查端口+检查路径）发送 HTTP 请求（可选择设置检查域名）。

2. 后端服务器收到请求后返回相应的 HTTP 状态码。

3. 若在响应超时时间内，负载均衡收到了后端服务器返回的 HTTP 状态码，若与设置的 HTTP 状态码匹配成功，则判定健康检查成功，反之则判定健康检查失败。

4. 若在响应超时时间内，负载均衡未收到后端服务器的响应，则判定健康检查失败。

注意：说明：

六、健康检查时间窗

负载均衡的健康检查机制有效提高了业务的可用性。为了避免频繁的健康检查失败引起的切换对系统可用性的冲击，健康检查只有在健康检查时间窗内连续多次检查成功或失败后，才会进行健康或异常的状态切换。健康检查时间窗由以下因素决定：

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

注意：说明：

·健康检查失败时间窗 = 检查间隔 ×（不健康阈值 – 1）
下图以健康检查响应超时时间为2s，检查间隔为5s，不健康阈值为3次为例，健康检查失败时间窗 = 5 x（3-1）= 10s。


·健康检查成功时间窗 = 检查间隔 ×（健康阈值 – 1）
下图以健康检查成功响应时间为1s，检查间隔为5s，健康阈值为3次为例，健康检查成功时间窗 = 5 x（3-1）= 10s。


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

·健康检查失败时间窗 = 响应超时时间 × 不健康阈值 + 检查间隔 ×（不健康阈值 – 1）
下图以健康检查响应超时时间为2s，检查间隔为5s，不健康阈值为3次为例，健康检查失败时间窗 = 2 x 3 + 5 x（3-1）= 16s。


·健康检查成功时间窗 = 健康检查成功响应时间 × 健康阈值 + 检查间隔 ×（健康阈值 – 1）
下图以健康检查成功响应时间为1s，检查间隔为5s，健康阈值为3次为例，健康检查成功时间窗 = 1 x 3 + 5 x（3-1）= 13s。


七、健康检查探测标识

在 CLB 开启健康检查后，后端服务器除接收正常的业务请求外，还会接收到健康检查探测请求。健康检查探测请求有如下标识：

·健康检查探测请求的源 IP 是 CLB 的 VIP 或100.64.0.0/10网段。

·四层（TCP、UDP、TCP SSL）监听器的健康检查方式若为自定义，且检查请求为空，则默认请求中会带“HEALTH CHECK”标识。

·七层（HTTP、HTTPS）监听器的健康检查请求 Header 中的 user-agent 为“clb-healthcheck”。

注意：说明：

八、相关文档

·配置健康检查

·配置健康检查日志

·配置告警策略

·健康检查异常排查