API 文档

健康检查概述

最近更新时间:2021-06-29 18:13:55

负载均衡通过健康检查来判断后端服务的可用性,避免后端服务异常影响前端业务,从而提高业务整体可用性。

  • 开启健康检查后,无论后端 CVM 权重是多少(包括权重为0),负载均衡实例都会进行健康检查。
    • 当后端 CVM 实例被判定为异常后,负载均衡实例自动将新的请求转发给其他正常的 CVM,而不会转发到异常的 CVM。
    • 当异常实例恢复正常后,负载均衡将其恢复至负载均衡服务中,重新转发请求给此实例。
    • 若健康检查探测到所有后端服务都有异常时,请求将会被转发给所有后端 CVM。
  • 关闭健康检查,负载均衡将向所有后端服务器转发流量(包括异常的后端服务器),因此强烈建议您打开健康检查,允许负载均衡帮您自动检查并移除异常的后端服务器。

健康检查状态

根据健康检查探测情况,后端 CVM 的健康检查状态如下所示:

状态 说明 是否转发流量
探测中 新绑定的后端 CVM 在检查间隔 × 健康阈值时间内的状态,例如,检查间隔2s,健康阈值3次,则是6s内的状态。 CLB 不向处于“探测中”的后端服务转发流量。
健康 后端服务正常 CLB 向“健康”的后端服务转发流量。
异常 后端服务异常
  • CLB 不向“异常”的后端服务转发流量。
  • 在一个四层监听器或者七层 URL 规则下,如果 CLB 探测到所有后端服务都不健康,将会激活全死全活逻辑,即请求将会转发给所有后端服务。
  • 已关闭 关闭健康检查 CLB 向后端服务转发流量。

    TCP 健康检查

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

    TCP 健康检查机制如下:

    1. 负载均衡向后端 CVM(内网IP 地址+健康检查端口)发送 SYN 连接请求报文。
    2. 后端 CVM 收到 SYN 请求报文后,若相应端口处于正常监听状态,则会返回 SYN+ACK 响应报文。
    3. 若在响应超时时间内,负载均衡收到后端 CVM 返回的 SYN+ACK 响应报文,则表示服务运行正常,判定健康检查成功,并向后端 CVM 发送 RST 复位报文中断 TCP 连接。
    4. 若在响应超时时间内,负载均衡未收到后端 CVM 返回的 SYN+ACK 应报文,则表示服务运行异常,判定健康检查失败,并向后端 CVM 发送 RST 复位报文中断 TCP 连接。

    UDP 健康检查

    针对四层 UDP 监听器,您可以配置 UDP 健康检查,通过Ping命令和向健康检查端口发送 UDP 探测报文来获取健康状态。您还可以通过自定义协议的请求内容和返回结果来获取后端 CVM 的状态信息。

    UDP 健康检查机制如下:

    1. 负载均衡向后端 CVM 的内网 IP 地址发起Ping命令;
    2. 负载均衡向后端 CVM(内网 IP 地址+健康检查端口)发送 UDP 探测报文;
    3. Ping成功,且在响应超时时间内,后端 CVM 未返回port XX unreachable的报错信息,则表示服务正常,判定健康检查成功;
    4. Ping失败,或者在响应超时时间内,系统收到后端 CVM 返回的port XX unreachable报错信息,则表示服务异常,判定健康检查失败;
    注意:

    1. UDP 健康检查依赖 ICMP 协议,需要后端 CVM 开放回复 ICMP 包(支持Ping)、开放回复 ICMP 端口不可达包(支持探测端口);
    2. 如果后端 CVM 是 Linux 服务器,在大并发场景下,由于 Linux 有防 ICMP 攻击保护机制,会限制服务器发送 ICMP 的速度。此时,即使后端服务已经出现异常,但由于无法向 CLB 返回port XX unreachable,CLB 由于没收到 ICMP 应答进而判定健康检查成功,最终导致后端服务的真实状态与健康检查不一致。
      解决方案:在配置 UDP 健康检查时,配置自定义输入和输出,向后端服务器发送您指定的字符串,且 CLB 收到您指定的应答后才判断健康检查成功。此方案依赖后端服务器,后端服务器需处理健康检查输入并返回指定输出。

    HTTP 健康检查

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

    HTTP 健康检查机制如下:

    1. 负载均衡根据健康检查配置,向后端 CVM(内网IP 地址+健康检查端口+检查路径)发送 HTTP 请求(可选择设置检查域名)。
    2. 后端 CVM 收到请求后返回相应的 HTTP 状态码。
    3. 若在响应超时时间内,负载均衡收到了后端 CVM 返回的 HTTP 状态码,若与设置的 HTTP 状态码匹配成功,则判定健康检查成功,反之则判定健康检查失败。
    4. 若在响应超时时间内,负载均衡未收到后端 CVM 的响应,则判定健康检查失败。
    说明:

    针对七层 HTTPS 监听器,当 HTTPS 监听器的转发规则中的后端协议选择 HTTP 时,健康检查使用 HTTP 健康检查;当选择 HTTPS 时,健康检查使用 HTTPS 健康检查。
    HTTPS 健康检查与 HTTP 健康检查 基本类似,不同的是 HTTPS 健康检查是通过发送 HTTPS 请求,根据返回的 HTTPS 状态码判断后端 CVM 的状态信息。

    健康检查时间窗

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

    健康检查配置 说明 默认值
    响应超时
    • 健康检查响应的最大超时时间。
    • 如果后端云服务器在超时时间内没有正确响应,则判定为健康检查异常。
    • 可配置范围:2 - 60秒。
    2 - 60秒
    检测间隔
    • 负载均衡进行健康检查的时间间隔。
    • 可配置范围:5 - 300秒。
    5秒
    不健康阈值
    • 如果连续 n 次(n 为填写的数值)收到的健康检查结果失败,则识别为不健康,控制台显示为**异常**。
    • 可配置范围:2 - 10次。
    3次
    健康阈值
    • 如果连续 n 次(n 为填写的数值)收到的健康检查结果为成功,则识别为健康,控制台显示为**健康**。
    • 可配置范围:2 - 10次。
    3次

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

    说明:

    四层健康检查,即 TCP 健康检查或 UDP 健康检查,无论检查成功还是响应超时,前后两次之间发包的检查间隔都是已设置的检查间隔。

    • 健康检查失败时间窗 = 检查间隔 ×(不健康阈值 - 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。
    • 四层(TCP、UDP、TCP SSL)监听器的健康检查请求中会带“HEALTH CHECK”标识。
    • 七层(HTTP、HTTPS)监听器的健康检查请求 Header 中的 user-agent 为“clb-healthcheck”。
      说明:

      • 传统型内网负载均衡,健康检查源 IP 为 169.254.128.0/17 网段。
      • 基础网络内网负载均衡,健康检查源 IP 为服务器物理 IP。

    相关文档

    目录