这篇说说 ALB 健康检查的工作机制、各项参数含义,以及如何在控制台配置和修改健康检查。
一、前提条件
·已创建应用型负载均衡 ALB 实例。如未创建,请参见 创建 ALB 实例。
·已创建目标组并向目标组中添加了后端服务。如未创建,请参见 创建和管理目标组。
二、健康检查工作机制
ALB 以目标组为维度配置健康检查,每个目标组可独立开启并配置健康检查策略。其工作机制如下:
·开启健康检查后,ALB 通过健康探测源 IP 周期性地向目标组内每个后端服务发起探测请求,根据响应结果判定后端服务的健康状态。
·后端服务需连续多次(健康阈值)探测成功才会被判定为健康,以避免网络抖动造成的误判;连续多次(不健康阈值)探测失败则被判定为异常。
·当某台后端服务被判定为异常时,ALB 自动将其从流量分发中剔除,新的请求会按调度策略分发到其他健康的后端服务;当其恢复正常后,ALB 自动将其重新纳入流量分发。
·健康检查为短连接探测,每次探测完成后连接即关闭。
·当目标组内所有后端服务均为异常时,ALB 仍会按调度策略尝试将请求转发至这些后端服务,以最大程度避免业务完全中断。
注意:说明:
注意:权重为0的后端服务不接收新请求,也不参与健康检查。
三、健康检查方式
ALB 目标组支持以下健康检查方式。检查方式的可选项与目标组的后端协议联动:
·后端协议选择 HTTP、HTTPS 时,检查方式支持 TCP、HTTP、HTTPS;
·后端协议选择 gRPC 时,检查方式支持 TCP、gRPC;
·后端协议选择 gRPCs 时,检查方式支持 TCP、gRPCs。
| 检查方式 | 检查原理 | 适用场景 |
| TCP | 通过向后端服务发起 TCP 三次握手(SYN 包)来探测端口是否存活,仅校验端口连通性,不感知应用层状态。 | 后端为通用 TCP 服务或仅需确认端口可达的场景。性能开销小,是默认的检查方式。 |
| HTTP | 通过向后端服务发送 HTTP 请求(HEAD 或 GET),根据返回的 HTTP 状态码判定后端应用是否正常。 | 后端为 HTTP 应用,需要从应用层确认服务可用性的场景。 |
| HTTPS | 通过向后端服务发送基于 TLS 加密的 HTTP 请求,根据返回的 HTTP 状态码判定后端应用是否正常。 | 后端为 HTTPS 应用,需要在加密链路上确认服务可用性的场景。 |
| gRPC | 通过向后端服务发送 gRPC 健康检查请求,根据返回的 gRPC 状态码判定后端应用是否正常。 | 后端为 gRPC 应用的场景。 |
| gRPCs | 通过向后端服务发送基于 TLS 加密的 gRPC 健康检查请求,根据返回的 gRPC 状态码判定后端应用是否正常。 | 后端为加密 gRPCs 应用的场景。 |
四、配置健康检查
健康检查可在创建目标组时配置,也可在目标组创建后进行编辑。本节以创建目标组流程中的健康检查步骤为例。
1. 登录 应用型负载均衡控制台,在左侧导航栏选择应用型负载均衡 ALB > 目标组管理。
2. 在页面上方选择地域后,单击新建,在创建目标组窗口中完成基本信息配置,单击下一步:健康检查。
3. 在健康检查步骤中,按下表配置健康检查参数,配置完成后单击完成。
基础参数
| 参数 | 说明 |
| 健康检查 | 是否开启健康检查。开启后 ALB 会自动检查并移除异常的后端服务。建议保持开启。 |
| 检查方式 | 选择健康检查使用的协议。可选项随目标组后端协议联动:后端协议选择 HTTP、HTTPS 时,检查方式支持 TCP、HTTP、HTTPS;后端协议选择 gRPC 时,检查方式支持 TCP、gRPC;后端协议选择 gRPCs 时,检查方式支持 TCP、gRPCs。 |
| 检查端口 | 健康检查探测使用的端口。默认为后端服务的端口;若后端服务的健康检查端口与业务端口不同,可在此指定特定端口。除特殊需要外建议留空。 |
HTTP/HTTPS 检查方式专属参数
当检查方式选择 HTTP 或 HTTPS 时,除基本参数外还需配置以下应用层参数:
| 参数 | 说明 |
| 检查域名 | 长度限制:1 – 80个字符。默认为转发域名。不支持正则表达式,当你的转发域名为通配域名时,需要指定某一固定域名(非正则)为健康检查域名。支持的字符集为:a-z 0-9 . -。 |
| 检查路径 | 健康检查路径可设置为后端服务器根目录或指定的 URL:长度限制:1 – 200个字符。默认为 /,且必须以 / 开头。不支持正则表达式,建议指定某个固定 URL 路径(静态页面)进行健康检查。支持的字符集为:a-z A-Z 0-9 . – _ / = ?。 |
| HTTP 请求方式 | 健康检查选择 HTTP 请求方式,可选:GET 或 HEAD,默认为 HEAD。若使用 HEAD 方法,服务器仅返回 HTTP 头部信息,可降低后端开销,提升请求效率,对应的后端服务需支持 HEAD。若使用 GET 方法,则后端服务支持 GET 即可。 |
| HTTP 状态码检测 | 判定后端服务存活的响应状态码集合,探测返回命中其中任一即视为存活。可勾选 http_1xx、http_2xx、http_3xx、http_4xx、http_5xx。当返回状态码命中所勾选的任一类别时,认为后端服务器存活。 |
gRPC/gRPCs 检查方式专属参数
当检查方式选择 gRPC 或 gRPCs 时,除基本参数外还需配置以下参数:
| 参数 | 说明 |
| 检查域名 | 长度限制:1 – 80个字符。默认为转发域名。不支持正则表达式,当你的转发域名为通配域名时,需要指定某一固定域名(非正则)为健康检查域名。支持的字符集为:a-z 0-9 . -。 |
| 检查路径 | 健康检查选择 gRPC 协议时,路径默认为/TCLOUD.CLB/healthcheck,同时可按/Package.Class/method格式进行自定义设置。 |
| gRPC 状态码检测 | 判定后端服务存活的 gRPC 状态码,默认值为12,数值范围为0 – 99。输入值可为单个数值、多个数值、范围以及相互组合,如20、20,25、0-99或12,25,30-40的组合。当 gRPC 返回状态码与设置的状态码匹配时,认为后端服务器存活。 |
高级选项
单击显示高级选项,可通过滑块调整健康检查的探测频率与判定阈值:
| 参数 | 说明 | 取值范围 | 默认值 |
| 响应超时 | 单次健康检查的最大等待时间。若后端服务在该时间内未正确响应,则判定本次探测失败。 | 2 – 60 秒 | 2 秒 |
| 检测间隔 | 相邻两次健康检查之间的时间间隔。间隔越短,异常发现越及时,但探测开销越大。 | 2 – 300 秒 | 5 秒 |
| 不健康阈值 | 连续探测失败达到该次数后,将后端服务判定为异常并剔除流量。 | 2 – 10 次 | 3 次 |
| 健康阈值 | 连续探测成功达到该次数后,将后端服务判定为健康并恢复流量。 | 2 – 10 次 | 3 次 |
注意:说明:
注意:响应超时时间应小于检测间隔。若后端服务启动较慢,可适当增大检测间隔或不健康阈值,避免服务启动期间被误判为异常;若网络延迟较高,可适当增大响应超时时间。
五、查看健康检查状态
为目标组开启健康检查并将其关联到监听器后,你可在监听器管理页面中查看各后端服务的健康检查状态。
1. 登录 应用型负载均衡控制台,进入目标实例,
2. 进入目标实例后,切换到监听器管理页面,在健康状态列中可见健康状态。后端服务的健康检查状态含义如下:
| 状态 | 说明 |
| 健康 | 后端服务连续通过健康检查(达到健康阈值),正常参与流量分发。 |
| 异常 | 后端服务连续未通过健康检查(达到不健康阈值),已被剔除出流量分发。 |
| 未知 | 绑定的目标组内无后端服务。 |
| 探测中 | 新绑定的后端服务器在检查间隔 × 健康阈值时间内的状态。 |
| 已关闭 | 关闭健康检查。ALB 向所有后端服务转发流量。 |
六、修改健康检查
目标组创建后,你可随时修改健康检查配置。
1. 在目标组管理列表中单击目标组 ID 进入详情页。
2. 在基本信息页的健康检查区域单击编辑。
3. 修改完成后,单击保存。