API 文档

文档中心 > 负载均衡 > 常见问题 > 健康检查异常排查

健康检查异常排查

最近更新时间:2021-01-12 10:03:15

负载均衡(CLB)通过健康检查来判断后端服务的可用性。若您遇到健康检查异常,可参考以下方式进行排查。

说明:

  • 当健康检查探测到异常时,CLB 将不再向异常后端服务转发流量。
  • 当健康检查探测到所有后端服务都有异常时,请求将会被转发给所有后端服务。
  • 健康检查原理可参考 健康检查

检查后端服务器的公网带宽

  • 传统账户类型,负载均衡绑定的后端 CVM 需要配置公网带宽,否则会导致健康检查异常。因为该账户的带宽属性在 CVM 上,而非 CLB 上。
  • 标准账户类型,负载均衡绑定的后端 CVM 无需配置公网带宽,且不会影响负载均衡服务 。
    说明:

    • 若您无法确定账户类型,请参见 判断账户类型
    • 传统账户类型的负载均衡不收取任何流量或带宽费用。负载均衡服务产生的公网流量费用,由绑定的后端 CVM 收取。
    • 您可在不分配公网 IP 的情况下,为 CVM 购买公网带宽。

检查安全组配置

检查负载均衡实例是否开启安全组默认放通功能。如果未开启,则需在 CVM 的安全组上放通来源 IP。如果您的 CLB 服务支持任意 IP 的访问,则在安全组的入站规则中配置来源 IP 为0.0.0.0/0。详情请参考 配置负载均衡安全组

检查四层监听器

说明:

  • TCP 协议下,负载均衡使用 SYN 包进行探测。
  • UDP 协议下,负载均衡使用 ping 命令进行探测。

在页面查看 CLB 后端服务器端口的健康状态,状态为异常时的排查方法如下:

  • 确定 CLB 后端服务器是否配置了安全组导致影响服务。后端服务器可通过安全组进行访问控制从而保证服务正常运行,详情请参考 后端云服务器安全组配置说明
  • 使用 netstat 命令,检查后端服务器的端口是否有进程在监听。若未发现进程,则重新启动服务。

检查七层协议

针对七层(HTTP 协议)服务,当某一监听出现健康检查“异常”时,可以通过以下方面进行排查:

  • 由于负载均衡的七层健康检查服务与后端 CVM 之间通过内网通信,您需要登录服务器检查应用服务器端口是否正常监听在内网地址上,如果没有监听在内网地址,请将应用服务器端口监听到内网上,从而确保负载均衡系统和后端 CVM 之间的正常通信。
    假设负载均衡前端端口是80,CVM 后端端口也是80,CVM 内网 IP 是:1.1.1.10

    • Windows 系统服务器使用如下命令:
      netstat -ano | findstr :80
    • Linux 系统服务器使用如下命令:
      netstat -anp | grep :80
      如果可以看到1.1.1.10:80的监听或0.0.0.0:80的监听则说明此配置正常。
  • 请确保后端服务器开启了您在负载均衡监听器中配置的后端端口。

    • 如果是四层负载均衡,只要后端端口 telnet 有响应即可,可以使用telnet 1.1.1.10 80来测试。
    • 如果是七层负载均衡,需要 HTTP 状态码是200 等代表正常的状态码,检验方法如下:
      • Windows 系统可以直接在 CVM 内的浏览器输入内网 IP 测试是否正常,本例为:http://1.1.1.10
      • Linux 系统可以通过curl -I命令查看状态是否为 HTTP/1.1 200 OK,本例为:curl -I 1.1.1.10
  • 检查后端 CVM 内部是否有防火墙或其他安全类防护软件,这类软件很容易将负载均衡系统的本地 IP 地址屏蔽,从而导致负载均衡系统无法跟后端服务器进行通信。
    检查服务器内网防火墙是否放行80端口,可以暂时关闭防火墙进行测试。

    • Windows 系统可以在运行输入firewall.cpl命令关闭。
    • Linux 系统可以输入/etc/init.d/iptables stop命令关闭(CenOS 7.x 系统请运行 systemctl stop firewalld命令)。
  • 检查负载均衡健康检查参数设置是否正确,建议参考 健康检查 提供的健康检查参数默认值进行设置。

  • 健康检查指定的检测文件,建议是以 HTML 形式的简单页面,只用于检查返回结果。不建议使用 PHP 等动态脚本语言。

  • 检查后端是否有较高负载导致 CVM 对外提供服务响应慢。

  • 检查 HTTP 请求方式。

    • 如果使用 HEAD 方法,则后端服务一定要支持 HEAD。
    • 如果是 GET 方法,则后端服务一定要支持 GET。
  • 如果同时开启了 TCP 的快速回收(tcp_tw_recycle)和时间戳(tcp_timestamps)可能导致健康检查异常,建议关闭 tcp_tw_recycle,详见 原因分析

健康检查探测频率过高

控制台设置5s接收1次探测包,实际后端 RS 发现1s内收到1次甚至多次健康检查请求,导致健康检查探测频率过高的原因主要是和负载均衡的后端健康探测实现机制有关:
假设100万的 Client 端请求,会分散在4台 CLB 后端物理机上,再转发给云服务器。 健康检查探测是在 CLB 的各个后端物理机上分别进行探测,因此,CLB 实例设置5s1次的探测请求时,实际上 CLB 后端的每台物理机都会每5s发送一次探测。此时后端云服务器上可能会在5s中收到4次探测请求。

该方案的优势是效率高,探测精准,避免误剔除。例如,CLB 实例集群的8台物理机中,其中1台判断失败,那么仅此台机器不再转发流量,另外7台仍然正常转发流量。

如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响,您可以通过增大探测时间间隔的方式来降低对业务的影响(例如设置为15s探测一次)。

目录