全部产品
存储与CDN 数据库 安全 应用服务 数加·人工智能 数加·大数据基础服务 互联网中间件 视频服务 开发者工具 解决方案 物联网 钉钉智能硬件
负载均衡

健康检查常见问题

更新时间:2017-12-08 16:37:37

1. 健康检查的原理是什么?

负载均衡通过健康检查来探测后端ECS实例的可用性。开启健康检查功能后,当后端某个ECS实例健康检查出现异常时,来自客户端的新请求将不会再被转发到该ECS实例,直到该ECS实例恢复正常。

负载均衡健康检查的实现机制,如下图所示。

健康检查机制

LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发及健康检查职责。当前集群服务器IP段为负载均衡系统IP地址段包括:100.64.0.0/10、10.158.0.0/16、10.159.0.0/16和10.49.0.0/16。如果后端ECS实例启用了iptables等访问控制,需要在内网网卡上针对上述IP段做访问放行。

根据负载均衡转发策略,客户端相关访问请求被均分到LVS集群内不同服务器(如果是七层服务,相关请求被进一步转发到Tengine集群)。

更多详细信息,参考负载均衡健康检查原理

2. 健康检查的参数配置是否有相对合理的推荐值?

  • 关于TCP/HTTP/HTTPS健康检查,建议使用如下配置:

    此配置有利于用户服务及应用状态的尽快收敛。如果您有更高要求,可以适当地降低响应超时时间值,但必须先保证服务在正常状态下的处理时间小于这个值。

    • 健康检查失败时间窗=(2秒检查间隔+5秒响应超时时间)×3次检查=21秒
    • 健康检查成功时间窗=5秒检查间隔×3次检查=15

      配置推荐值
      响应超时时间5秒
      健康检查间隔2秒
      不健康阈值3
      健康阈值3
  • 关于UDP健康检查,建议使用如下配置:

    此配置有利于用户服务及应用状态的尽快收敛。如果您有更高要求,可以适当地降低响应超时时间值,但必须先保证服务在正常状态下的处理时间小于这个值。

    • 健康检查失败时间窗=(5秒检查间隔+10秒响应超时时间)×3次检查=45秒
    • 健康检查成功时间窗=5秒检查间隔×3次检查=15秒

      配置推荐值
      响应超时时间10秒
      健康检查间隔5秒
      不健康阈值3
      健康阈值3

3. 是否可以关闭健康检查?

  • HTTP/HTTPS监听,可以关闭健康检查。

    说明:如果关闭健康检查,当后端某个ECS实例健康检查出现异常时,负载均衡还是会把请求转发到该异常的ECS实例上,造成部分业务不可访问。建议您不要关闭健康检查。

    具体操作,参考如何关闭健康检查

  • TCP/UDP监听,无法关闭健康检查。

4. TCP监听如何选择健康检查方式?

TCP监听支持HTTP和TCP两种健康检查方式:

  • TCP模式的健康检查基于网络层探测,利用传统的三次握手机制来判断后端服务是否异常。

  • HTTP模式的健康检查是Tengine节点服务器通过发送HTTP Head请求,对比返回码来校验后端服务是否异常。

TCP健康检查方式对服务器的性能资源消耗相对要少一些。如果您对后端服务器的负载高度敏感,则选择TCP健康检查;如果负载不是很高,则选择HTTP健康检查。

5. ECS实例权重设置为零对健康检查有什么影响?

将负载均衡后端ECS实例的权重置为零,相当于将该ECS实例移出负载均衡。一般是在ECS实例进行重启、配置调整等主动运维时将其权重设置为零。由于该状态下,负载均衡不会再将流量转发给该ECS实例,所以其健康检查会显示异常。

6. HTTP监听向后端ECS实例执行健康检查使用的方法是什么?

HEAD方法。

如果后端ECS实例的服务关闭HEAD方法,会导致健康检查失败。建议在ECS实例上用HEAD方法访问自已IP地址进行测试:

echo -e “HEAD /test.html HTTP/1.0\r\n\r\n” | nc -t LAN_IP port

7. HTTP监听向后端ECS实例执行健康检查的IP地址是什么?

负载均衡系统IP地址段为:100.64.0.0/10、10.158.0.0/16、10.159.0.0/16和10.49.0.0/16。

8. 为什么健康检查监控频率与web日志记录不一致?

负载均衡健康检查服务也是集群方式的,这样可以避免单点故障。负载均衡的代理分布到很多节点上,因此看到的健康检查日志访问频率和控制台设置的频率不一致,这是正常现象。

9. 为什么出现502 Bad Gateway错误提示并且健康检查提示异常?

问题现象:

访问负载均衡服务提示502 Bad Gateway并且健康检查提示异常。但是,ECS实例内网测试应用可以正常访问,检查ECS实例内部80端口监听正常,但Web日志提示404。

问题原因:

明配置的健康检查页面不存在,导致健康检查异常。

解决方案:

修改健康检查配置。

10. 健康检查是否会消耗系统资源?

HTTP模式的健康检查对后端ECS实例的资源消耗不大。

11. 为什么负载均衡后端ECS实例频繁收到UA为KeepAliveClient的请求?

问题现象:

负载均衡后端的ECS实例即使在没有用户访问时也会频繁收到GET请求,来源的IP是阿里云的内网IP,User-Agent显示为KeepAliveClient

问题原因:

查看负载均衡的监听配置中,是否监听协议选择的是TCP,而健康检查选择了HTTP协议。如果是则会出现该异常,此时负载均衡对后端ECS实例的健康检查就是以GET方式来进行,而不是HEAD方式了。

解决方案:

建议您将监听协议和健康检查协议统一设置为同一个协议,比如HTTP协议,这样负载均衡就会以HEAD方式来进行健康检查了(此时客户端的真实IP会被放置在HTTP头的X-Forwarded-For参数中),或者统一改为TCP,这样健康检查就是以三次握手加一个reset结束,对后端ECS实例的开销也是比较小的。

12. 负载均衡因后端数据库故障导致健康检查失败,如何处理?

问题现象:

ECS实例内配置了两个WEB站点,www.test.com是静态网站,app.test.com是动态网站,都配置了负载均衡。后端数据库服务异常,导致访问www.test.com静态网站出现502错误。

问题原因:

负载均衡健康检查配置的检查域名是app.test.com,RDS或者自建数据库故障导致app.test.com访问异常,所以健康检查失败。

解决方案:

将负载均衡健康检查域名配置为www.test.com即可。

13. 负载均衡服务TCP端口健康检查成功,为什么在后端业务日志中出现网络连接异常信息?

问题现象:

负载均衡后端配置TCP服务端口后,后端业务日志中频繁出现类似如下网络连接异常错误信息。经进抓包分析,发现相关请求来自负载均衡服务器,同时负载均衡主动向服务器发送了RST数据包。

a

问题原因:

该问题和负载均衡的健康检查机制有关。

由于TCP对上层业务状态无感知,同时,为了降低负载均衡健康检查成本和对后端业务的冲击,当前负载均衡针对TCP协议服务端口的健康检查只会做简单的TCP三次握手,而后直接发送RST包断开TCP连接。数据交互流程如下:

  1. 负载均衡服务器向后端负载均衡服务端口发送SYN请求包;

  2. 后端服务器收到请求后,如果端口状态正常,则按照正常的TCP机制返回相应的SYN+ACK应答包;

  3. 负载均衡服务器成功收到后端服务端口应答后,则认为端口监听是正常的,判定健康检查成功;

  4. 负载均衡服务器向相应TCP服务端口直接发送RST包主动关闭连接,结束本次健康检查操作,且没有继续发送业务数据。

如上所述,由于健康检查成功后,负载均衡服务器直接发送TCP RST包中断了连接,并没有做进一步的业务数据交互,导致上层业务(比如Java连接池等)认为相应的连接是异常的,所以会出现Connection reset by peer等错误信息。

解决方案

  • 更换TCP协议为HTTP协议。

  • 在业务层面,对来自SLB服务器IP地址段的相关请求做日志过滤,忽略相关错误信息。

14. 为什么业务本身没有异常但是监控检查显示异常?

问题现象:

负载均衡HTTP方式的健康检查始终失败,但测试curl -I得到的状态码是正常的。健康检查使用的命令如下:

echo -e ‘HEAD /test.html HTTP/1.0\r\n\r\n’ | nc -t 192.168.0.1 80

问题原因:

如果返回的状态与控制台配置的正常状态码不一致,则判定健康检查异常。如果您配置的正常状态码为http_2xx,则所有返回的非HTTP 2xx状态码均被认为是健康检查失败。

Tengine/Nginx配置会发现curl没有问题,但是echo测试会匹配到默认站点,导致测试文件test.html返回404错误,如下图所示。

1

解决方案:

  • 修改主配置文件,将默认站点注释掉。

  • 在健康检查配置中添加检查域名。

15. 如何排查负载均衡健康检查异常?

您可以通过以下方法进行排查:

  1. 查看后端ECS实例是否能够正常提供服务。如果配置了HTTP模式的健康检查,确保服务返回的状态码与负载均衡控制台配置的正常状态码一致。

  2. 负载均衡健康检查与后端ECS实例之间通过内网通信。登录服务器检查应用服务器端口是否正常监听在内网地址上,如果没有监听在内网地址,将应用服务器端口监听到内网上。

  3. 确保ECS实例上10.0.0.0/8,100.64.0.0/10和11.0.0.0/8网段的路由配置的下一跳为内网网关。如果ECS实例只有内网地址,确保默认路由(0.0.0.0/0)指向内网网关。

    各操作系统的路由配置如下:

    • Windows: 登录ECS实例实例,下载Windows添加路由工具,双击执行下载文件。

    • Liunx: 登录ECS实例实例,下载Linux添加路由工具,执行bash linux_add_routes.sh命令。

    • FreeBSD:登录ECS实例实例,下载FreeBSD添加路由工具, 执行bash freebsd_add_routes.sh命令。

      运行添加路由工具后内网路由显示正常,如下图所示。

      9

  4. 确保后端服务器开启了相应的端口,该端口必须与您在负载均衡监听配置中配置的后端端口保持一致。

  5. 查看后端ECS实例权重值是否为零,如果权重值设置为零,会导致健康检查显示异常。

  6. 检查后端ECS实例内部是否有防火墙或其他的安全类防护软件,这类软件可能屏蔽负载均衡系统的本地IP地址(100.64.0.0/10、10.158.0.0/16、10.159.0.0/16和10.49.0.0/16),导致负载均衡系统无法和后端ECS实例通信。建议关闭防火墙或者卸载安全类防护软件进行测试。

  7. 查看后端业务本身的响应时间是否超出健康检查设置的响应超时时间。

    执行以下命令查看四层健康检查的业务响应时间:

    time telnet <SLB IP address> <SLB Port>

    执行以下命令查看七层健康检查的业务响应时间:

    time echo -e ‘HEAD <健康检查的检查路径> HTTP/1.0\r\n\r\n’|nc -t <端口>

    在同账号同地域下的另外一台机器上执行该命令。比如健康检查的检查路径为/,ECS实例内网IP为192.168.0.1,端口为80,则您使用的命令为: time echo -e ‘HEAD / HTTP/1.0\r\n\r\n’ | nc -t 192.168.0.1 80

    0

    当结果中显示的real的参数值超过健康检查中配置的响应超时时间,健康检查就会提示异常。

    解决方案:

    • 优化应用或者程序,减少响应时间。

    • 增加监控检查中设置的响应超时时间。

  8. 七层的健康检查,执行echo -e “HEAD /test.html HTTP/1.0\r\n\r\n” |nc -t LAN_IP 80查看返回值是不是2XX或者3XX。

    说明:其中/test.html是健康检查配置的检查路径,需要根据实际情况进行替换。

  9. 检查后端ECS实例资源是否有较高负载导致ECS实例对外提供服务响应时间过长。

  10. 建议提供健康检查的文件使用HTML静态文件,只用于检查返回结果,不建议使用PHP等动态脚本语言。

本文导读目录