LVS 本身不提供负载状态反馈机制，其反馈依赖外部组件协同实现：通过连接级健康检测、conntrack 连接数统计、keepalived 主动检查及外挂监控系统共同完成动态规则更新。

LVS 本身不直接提供负载状态反馈机制，它作为内核态的四层负载均衡器，核心职责是按调度算法转发数据包，不感知后端服务器（RS）的 CPU、内存、连接数等运行指标，也不主动探测服务健康状况。所谓“负载状态反馈”，实际需要外部组件协同实现，而非 LVS 内置功能。

---

LVS 负载状态反馈依赖的关键机制

LVS 的“反馈”本质是基于连接或响应行为的间接判断，主要通过以下方式体现：

• 连接级健康检测（被动反馈）
  当 RS 异常（如进程崩溃、端口未监听），客户端新建连接会失败（SYN 超时或 RST 响应）。LVS 默认不会自动剔除该 RS，但可通过 ipvsadm 配合脚本实现：

  • 定期用 telnet 或 nc 检测 RS 端口是否可达；
  • 若连续失败，执行 ipvsadm -d -t VIP:PORT -r RIP:PORT 删除节点；
  • 恢复后重新添加（ipvsadm -a -t ...）。

• 内核连接跟踪表（conntrack）辅助判断
  LVS 在 NAT/DR 模式下维护连接状态（如 ESTABLISHED、TIME_WAIT）。可通过：

  • ipvsadm -Lcn 查看当前活跃连接数（每 RS 的 ActiveConn / InActConn）；
  • 结合 wlc（加权最少连接）算法，LVS 会优先将新连接分发给 （ActiveConn × 256 + InActConn）/ weight 值最小的 RS —— 这本身就是一种基于连接负载的动态反馈。

• 与 keepalived 协同实现主动健康检查
  这是最常用、最可靠的方案：

  • keepalived 在用户空间运行，可配置 TCP/HTTP/SSL 检查（如 check_http 或 tcp_check）；
  • 检测失败时，自动调用 ipvsadm 删除对应 RS 规则；
  • 检测恢复后，自动重新添加；
  • 同时管理 VIP 高可用（VRRP），避免单点故障。

---

实际配置中需注意的细节

• 调度算法选择影响反馈效果

  • rr/wrr 是静态算法，完全无视实时负载；
  • lc/wlc 才真正利用连接数做动态决策，必须配合健康检查才能避免把流量打到已宕机但连接未超时的 RS 上。

• DR 模式下无法获取 RS 真实响应延迟
  因响应不经过 LVS，LVS 无法统计 RTT 或错误率。若需此类指标，必须在 RS 侧埋点并上报至监控系统（如 Prometheus），再由外部控制器调整权重或剔除节点。

• 无内置 metrics 接口，需外挂监控
  LVS 不暴露 /metrics 或 SNMP 数据。常见做法：

  • 解析 ipvsadm -L --stats 输出，提取 Conns、InPkts、OutPkts；
  • 使用 collectd 或自定义脚本定时采集，推送至 Grafana 展示；
  • 关键指标：各 RS 的 ActiveConn 偏差率、InPkts 突增/归零、OutPkts 明显低于 InPkts（可能丢包或响应异常）。

---

总结一句话

LVS 的负载状态反馈不是“自动感知”，而是“规则驱动 + 外部探测 + 动态规则更新”的组合结果。它靠 wlc 算法响应连接负载变化，靠 keepalived 或自定义脚本响应服务可用性变化，靠运维脚本或监控系统响应性能指标变化。没有这些配合，LVS 就只是个“盲转”转发器。