CLB健康检查原理及异常排查

一、七层健康检查

七层健康检查，使用HTTP协议，支持GET、HEAD两种请求方法，HEAD只获取头部信息，不获取实际内容，更加轻量的探测，两种方式，都是依赖RS返回的HTTP CODE与设置的健康状态码比对(默认为1xx、2xx、3xx、4xx)，如果不在健康状态码范围内或者在响应超时时间内没有返回任何状态码并且达到不健康阈值次数，则判定为不健康。

抓包可以看到，三次握手建联后，第12号包发起HEAD请求，第19号包RS正常响应附带HTTP状态码200 OK，CLB拿到200状态码后，和状态码检测勾选的范围做对比，比对在范围内，视为健康。

且七层监听器下，CLB到RS相当于一个反向代理的过程，这一段链路使用短连接，每次请求RS都要新建连接；

同时从上图可以看出，探测后不会正常和RS挥手，而是RST,ACK中断连接，这样做可以节省正常握手多出来的部分流量。

二、四层健康检查

TCP/HTTP

四层监听器的健康检查支持TCP、HTTP、自定义协议三种，其中前两种为主流用法：

四层监听器，顾名思义传输层协议，为IP:PORT的探测方式，检查端口如不填写，则默认为后端RS的监听端口，检查逻辑很简单，探测端口是否正常连通：

CLB发出SYN包请求握手，拿到对端的SYN,ACK后则视为健康，并不需要握手成功，接着RST,ACK中断连接；

四层TCP监听器也同样支持HTTP的探测方式，和七层监听器的探测原理一样。

UDP

udp探测分为检查端口和ping探测：

1.检查端口的探测逻辑

检查请求、检查返回结果不填写的情况下，当以下两个条件同时满足，则认为健康检查正常，否则异常：

Ping探测正常
UDP探测端口，RS没有回显xxx Port Unreachable

2.指定回显文本的探测逻辑

当检查请求、检查返回结果填写了文本或十六进制，CLB探测时将携带填写的内容去探测RS端口，当RS返回包中携带特定内容时，则视为健康，否则不健康：

使用socat测试，LB请求携带什么，RS就回显什么：

socat -v udp-l:2115,fork exec:'/bin/cat'

RS上抓包：

健康检查置为正常：

三、健康检查异常排查步骤

1.确保安全组、`iptables`等不会成为阻碍

CLB探测默认会携带自己的VIP去请求RS，如果RS没放通VIP或健康检查端口，CLB在超时范围内拿不到预期之类的响应，则会判断为超时，正确做法：

确保RS安全组是否放通VIP，如果开启安全组直通功能，则从LB进来的请求不会再去看RS的安全组；
确保iptables等软件是否正常放通来源，即使开启安全组直通功能，OS层面的软件依然可以拦截请求，如未放通可使用如下命令放通： iptables -I INPUT -s [clb vip] -d 0.0.0.0/0 -j ACCEPT ，放通CLB的请求，这只能确保VIP的探测请求能到达RS，client访问CLB时，CLB会携带client的IP给RS，如果不想限制client访问，则放通某个网段或者所有网段: iptables -I INPUT -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT，或者直接清空iptables规则：

iptables-sve > iptables-rules.bak  #清空前可保存一份
iptables -F
iptables -X

2.如果是传统账户，公网LB，确保RS有公网带宽

关于账号属性，可参考官方文档:

传统账户的带宽计费是在具体实例上管理的，因此如果是公网CLB，健康检查探测用的是公网VIP，那么需要保证绑定的后端RS也要有公网能力，即使没有公网IP也可以购买公网带宽，cvm控制台-->资源调整-->调整网络：

3.确保检查端口是否正常监听

例如判断健康检查80端口是否正常监听：

netstat -lntup|grep 80
lsof -i :80
ss -lntup|awk '$5~/80/{print $5}'

如没有正常监听，检查对应服务是否正常运行。

原文地址：https://cloud.tencent.com/developer/article/1866646