可以修改会话老化时间

配置下长连接就好了

1. 优化健康检查机制（核心排查）

• 检查健康检查协议：确认是否将应用层（HTTP/HTTPS）健康检查误配为了传输层（TCP）检查。TCP检查仅能探测端口连通性，当后端服务进程崩溃但端口仍开放时，负载均衡器会错误判定节点健康并持续转发流量。
• 调整健康检查参数：如果健康检查间隔过短或超时时间阈值过小，在网络抖动或节点重启恢复的短暂延迟期间，容易将正常波动误判为节点故障，导致节点被频繁摘除；反之，若超时时间过长，则可能导致真实故障节点无法被及时剔除。

2. 排查会话保持与连接状态丢失

• 服务器扩容或哈希重算影响：如果使用的是基于源IP哈希的四层会话保持，服务器重启或新增会打破现有哈希分布，造成大面积会话迁移，导致原会话中断。
• 长连接超时断开机制：为了有效管理资源，负载均衡器在开启会话保持后会设置连接超时时间（例如TCP默认900秒）。如果连接长时间无数据传输，负载均衡器会静默断开连接，客户端通常需要依赖应用层超时机制或 TCP Keepalive 来感知这种断开。

3. 排查网络层与底层资源异常

• 网络连通性未恢复：检查防火墙规则、安全组策略、路由表项或NAT映射是否在重启后未能正确加载或同步。
• 资源耗尽或进程异常：节点重启后，后端应用可能因内存泄漏、OOM（内存溢出）终止、配置文件损坏或依赖缺失等原因反复崩溃。这通常表现为连接被提前关闭或拒绝连接，导致负载均衡器无法获取有效响应。
• 连接跟踪表满：如果压测或高并发时出现请求超时，可能是后端服务器的连接跟踪表（如 nf_conntrack）已满，导致丢弃新建连接的数据包。

4. 检查配置一致性与高可用架构

• 配置漂移或不一致：集群内各节点间的配置（如权重、SSL协议版本、ACL规则）未保持同步，重启后加载了错误或旧版配置，会导致流量路由异常或访问控制失效。
• 高可用架构缺陷：如果采用单点部署无冗余，或VRRP心跳链路故障引发脑裂，会导致节点重启后集群无法完成正常的状态协商与流量调度，使服务持续不可用。

H3C AD 负载均衡：数据库长连接，后端服务器重启，LB 保留旧会话、无法新建有效连接故障

现象：数据库长连接业务，后端 RS 服务器重启；负载均衡设备仍然保留旧的 TCP 会话 / 会话保持表项，应用继续复用这条失效旧连接，传输数据失败；新的数据库连接无法正常调度。 核心根因：实服务器故障动作默认 keep（保留旧连接，不主动发 RST 清理）+ 会话保持表项老化时间过长 + 健康检查没有及时把 RS 置为 down，RS 重启后 LB 会话表没有清理，应用持续复用已经死亡的旧四元组会话。

一、故障原理

1. RS 服务器重启，服务器内核 TCP 会话全部清空，但负载均衡四层会话表 + 会话保持（persistence）表还保留在 LB 中。
2. LB 默认故障处理策略：keep，服务器故障后不主动断开已有 TCP 会话，LB 继续把报文转发给已经重启后的 RS。
3. RS 收到报文，内核找不到对应的 TCP socket，回复 RST。但客户端连接池不识别 RST，反复复用旧连接，不新建连接。
4. 会话保持表长期不老化，客户端源 IP 匹配会话保持，继续调度到该故障恢复后的 RS，不会触发新连接调度。

二、分步处理方案（H3C AD V7）

1. 修改实服务器组故障动作（关键！）

实服务池里面，当 RS 探测为 down 时，对存量连接执行 reset，主动发送 TCP RST 清理旧失效会话。

• keep（默认）：保留旧连接，不主动断，就是现场当前故障；
• reset：RS 故障检测到后，LB 主动向客户端和服务器双向发送 RST，销毁旧 TCP 会话，强制客户端重建新连接。

2. 优化健康检查（提前识别服务器重启）

数据库场景，不能只用 ICMP ping，必须用应用层健康检查（TCP 端口 / 数据库探测），服务器数据库进程重启后，及时把 RS 状态置为 down。

绑定到 server-pool。

仅 ping 探测会出现：服务器 OS 正常启动，但数据库服务未就绪，LB 判定 RS UP，转发旧会话，业务报错。

3. 会话保持（persistence）优化，数据库场景

数据库连接池长连接，建议使用源 IP 会话保持，缩短会话保持老化时间，不要设置永不老化。

❌严禁数据库业务会话保持设置为永久不老化，服务器重启后表项不会自动清除。

4. TCP 长连接空闲超时（四层会话老化）

调整 TCP ESTABLISHED 状态会话老化，配合应用层 TCP keepalive：

数据库侧操作系统开启 TCP keepalive（linux net.ipv4.tcp_keepalive_time），两端配合探测死连接。

5. 临时应急清理命令（故障发生时）

三、运维规范：服务器重启操作流程（规避该问题）

1. 重启前：把该 RS 设置平滑退出 / 软关机，不再接收新连接，等待存量连接自然老化。
2. 确认连接耗尽后，再重启数据库服务 / 服务器。
3. 服务器启动、数据库进程完全就绪后，再把 RS 恢复启用。

错误操作：直接硬重启服务器，LB 来不及清理会话，直接复现该故障。

四、区分两个坑

1. 四层会话表：TCP 四元组转发表；fail-action reset 用来清理这个。
2. 会话保持表（persistence）：用来保证同一客户端持续调度到同一台 RS；老化时间过长，就算旧会话断了，新连接依然调度到原 RS。

简短总结

1. 根因：LB 实服务器池默认fail-action keep，服务器重启 LB 不主动发送 RST 清理旧 TCP 会话；会话保持老化时间过长，应用复用失效旧连接。
2. 核心修复：修改fail-action reset，RS 故障时 LB 主动 RST 踢掉旧连接；使用应用层健康检查（TCP / 数据库探测，不要只用 ping）；缩短会话保持老化时间，禁止永久会话保持。
3. 运维规范：数据库服务器重启前先平滑下线 RS，等连接排空再重启。
4. 应急：reset loadbalance connection 清理存量失效会话。