开发者社区> 问答> 正文

健康检查原理



概述


负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。
开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。
如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。

健康检查过程


负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。
LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作,相互之间没有关联及影响,如下图所示。

当前进行健康检查的IP地址段为负载均衡系统地址段,包括100.64.0.0/10、10.158.0.0/16、10.159.0.0/16和10.49.0.0/16。如果后端ECS启用了iptables等访问控制,需要在内网网卡上针对上述地址设置放行。

健康检查机制



HTTP/HTTPS监听


针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。


对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。


七层监听的检查机制如下:

  1. Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。

  2. 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。

  3. 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。

  4. 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。


TCP监听


针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。

TCP监听的检查机制如下:

  1. LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。

  2. 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。

  3. 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。

  4. 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。

注意:正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。
该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息(如“Connection reset by peer”)。
解决方案:
  • TCP监听采用HTTP方式进行健康检查。
  • 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。


UDP监听


针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图示。

UDP监听的检查机制如下:

  1. LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。

  2. 如果后端ECS相应端口未正常监听,则系统会返回类似返回 “port XX unreachable”的ICMP报错信息;反之不做任何处理。

  3. 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。

  4. 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。

注意:当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题:
如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回“portXX unreachable”报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。
解决方案:
负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。


健康检查时间窗


健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换(判定为健康检查成功或失败)。健康检查时间窗由以下三个因素决定:
  • 健康检查间隔 (每隔多久进行一次健康检查)
  • 响应超时时间 (等待服务器返回健康检查的时间)
  • 检查阈值 (健康检查连续成功或失败的次数)

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

  • 健康检查失败时间窗=(检查间隔+响应超时时间)×检查阈值

  • 健康检查成功时间窗=检查间隔×检查阈值

对于TCP、HTTP、HTTPS监听,默认的健康检查失败时间窗为21秒,成功时间窗为6秒;UDP监听的默认健康检查失败时间窗为45秒,成功时间窗为15秒。
健康检查状态对请求转发的影响如下:

  • 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。

  • 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。

  • 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
      

展开
收起
行者武松 2017-10-17 15:20:24 3521 0
0 条回答
写回答
取消 提交回答
问答排行榜
最热
最新

相关电子书

更多
流量太大容易挂?接入Sentinel让N个9成为可能! 立即下载
流量太大容易挂?接入 Sentinel 让 N 个 9 成为可能! 立即下载
流量太大容易挂?接入Sentinel让N个9成为可能 立即下载