简介《深信服负载均衡AD日常维护手册簿》是一份由厂商大客户服务部整理的运维文档面向负责深信服AD负载均衡设备的网络管理员与运维工程师用于规范日常巡检、例行维护与常见故障排查。内含1个Word文档doc格式压缩包整体大小约519KB内容结构完整便于现场查阅与打印参考。目前已有250人学习下载。手册按时间维度组织每日检查涵盖设备状态灯、接口指示灯、CPU运行状态及异常状况每周检查包括控制台账号安全性、关闭远程维护与配置文件备份第3章集中梳理了无法登录控制台、虚拟服务无法访问、DNS解析异常、DNS策略与代理不生效等典型问题的排错思路。阅读后可建立清晰的AD设备维护清单降低因巡检疏漏或配置缺失导致的业务中断风险。1. 负载均衡AD设备的日常维护设备没坏流量却断了问题出在哪接手某厂商AD系列负载均衡设备下面统一叫AD的日常维护最常遇到的情况不是设备宕机而是后端服务明明健康节点池却显示一片红业务流量被强行摘掉或者主备切换时VIP没有漂移整段业务静默几分钟。这类“设备没坏、流量断了”的问题几乎都出在健康检查参数、双机心跳线和运维巡检习惯上。这份标题为《日常维护手册》的文档真正要解决的就是三件事新设备交付后怎么查基线、日常巡检看哪些指标不踩雷、故障出现时怎么快速定位。适合正在维护AD设备、准备接手设备的新人以及想把手头运维流程固化成制度的团队。2. 开局巡检新设备接流量前先核对这六个基线项设备上架、网络调通之后不要急着导配置、接业务。先花半小时把基线核对完后面日常维护会省掉很多半夜告警。我习惯把基线项分成设备自身状态和外部依赖两类逐项确认每项都留一条检查记录。2.1 双机状态与时间同步最容易埋雷的两个基础项双机热备是AD设备最常见的部署形态。登录Web控制台后第一件事看“双机状态”页面确认本机是主机还是备机、对端设备是否在线、备机的“同步进度”是不是100%。这里有个坑同步进度偶尔显示99.9%是正常的因为会话表在持续变化但如果在业务平稳期长期低于99%说明配置同步或会话同步有积压需要看日志确认是不是备机性能不足。心跳线的物理链路比任何参数都重要。强烈建议心跳口单独用一对光纤或网线直连不要和业务口共用链路更不要跨三层设备。心跳链路抖动是“双主”故障的头号原因后面避坑章节会单独展开。日常巡检时可以用命令行从设备侧ping对端心跳地址确认丢包率但更推荐在Web控制台的“双机状态”页面直接看心跳收发包统计。时间同步是另一个常被忽略的基线项。AD设备参与证书校验、日志审计和会话老化设备间时间偏差超过一定阈值会导致主备判断异常。在系统设置里配置NTP服务器后用测试按钮手动同步一次确认设备时间与标准时间偏差在一秒以内。这里注意如果公司内网有NTP服务器优先用内网的外网NTP在故障断网时反而会成为不稳定因素。2.2 路由回程、授权与告警通道业务没通和功能突然失效都藏在这里网络基线里最容易被漏掉的是后端服务器的回程路由。AD设备做流量转发时后端服务器返回数据包必须能回到AD设备常见做法是给后端服务器配置指向AD设备接口的路由或者在后端服务器上把AD设备的接口地址设为网关。巡检时可以选一台后端服务器从服务器上ping VIP地址能通说明回程路径基本没问题。如果ping不通优先查后端服务器的路由表而不是查AD设备——这个问题在开局阶段排查比业务上线后容易得多。授权基线和证书到期时间一起查。登录控制台后翻到授权管理页面确认序列号的有效期和已激活的特性模块。这里要留意授权到期不会让设备宕机但会让某些功能静默失效比如健康检查的高级特性或链路负载功能突然不生效排查时很难联想到授权。我的习惯是把授权到期时间记录在维护日历里提前一个月提醒续期。告警通道在开局阶段就要验证不要等到故障时才想起来。配置Syslog服务器和邮件告警后手工在设备上触发一条测试日志确认日志服务器能收到、邮件能发出来。这一步做完日常巡检才不会依赖人肉盯控制台。安全策略方面确认管理口访问白名单、AD之间的同步端口、AD到后端健康检查端口都放通并且写进防火墙变更记录。完成以上六项基线检查后再做一次全量配置备份这份备份文件就是后续所有变更的“后悔药”。备份文件导出后存放的位置要固定命名规则带日期便于回滚和追溯。3. 日常巡检实操Web控制台看状态命令行查深水区巡检体系分为两个层次日常在Web控制台做状态体检定期进命令行诊断模式查深水区指标。只盯控制台首页是不够的很多问题在指标趋势里不在瞬时数值里。3.1 Web控制台体检清单每天看状态每周看趋势控制台首页的核心指标是CPU、内存、会话数和节点状态。CPU和内存要看持续趋势不要被瞬时尖峰误导。瞬时尖峰通常是四层包转发峰值造成的如果是持续高位运行需要结合会话数判断是否达到设备处理瓶颈。这里有一个实用信号单台后端服务器的会话数如果持续远高于同节点的其他后端说明权重配置或调度算法有问题这个信号往往比CPU告警来得更早。每一天的巡检建议按下面的清单走一遍全部看完不超过十分钟巡检项查看位置正常标准异常动作设备CPU/内存系统概览持续低于70%查看会话数和流量分布VIP状态虚拟服务列表全部正常观察异常VIP对应节点池节点池状态真实服务器列表无红黄状态确认健康检查失败原因会话数会话管理页面未接近上限检查会话老化时间和均衡度双机状态双机热备页面主备清晰同步100%检查心跳链路授权到期授权管理页面剩余大于60天记录到期时间并提醒每周的巡检加两项翻一遍Syslog里的告警级别日志确认本周有没有被刷掉的告警看一次各链路入口的流量分布确认没有单链路打满的情况。每周五下午做这件事最合适既能覆盖工作日高峰的数据又不会占用周末时间。3.2 命令行诊断控制台不给看的信息在这查Web控制台适合看业务状态但遇到故障时控制台页面刷新不够快深水区信息需要通过命令行诊断模式获取。通常用SSH登录AD设备的管理地址进入诊断模式后先敲help看当前版本支持哪些查询命令。不同产品线的命令集有差异但常用的查询类命令大差不差保持只读操作# 查看系统整体健康状态 show system health # 查看所有虚拟服务的启停状态和流量统计 show slb vserver # 查看节点池内所有真实服务器的状态 show slb real-server # 查看当前会话表总数和分布 show session-table summary # 查看授权状态和剩余时间 show license以上命令只做查询不会改变配置可以放心执行。真正的运维纪律是查询类命令随便敲写操作类命令必须先在变更窗口内执行。诊断模式下最常用的是查看会话同步状态主备机上各执行一次会话统计命令对比两条设备上的会话总数差值越小说明同步越健康。如果差值持续扩大优先查心跳链路和同步端口不要急着重启设备。日志筛查建议结合时间段做控制台页面看实时日志诊断命令查历史日志。故障排查时先确定故障时间窗再拉该时间窗内的日志从VIP状态变化、健康检查失败记录、会话表老化记录三条线索顺藤摸瓜。日常运维中日志是定位问题最快的路径但前提是Syslog已经配置好并且日志没有被循环覆盖。4. 健康检查与调度参数三个参数调不好节点被误杀还说设备烂健康检查是日常维护里改动最频繁、也最容易翻车的部分。很多“后端服务明明正常但节点被摘掉”的故障根本原因不是设备判断逻辑有问题而是健康检查参数和业务真实场景不匹配。4.1 健康检查为什么会误判失败判定耗时要会算健康检查的判定逻辑可以用一句话概括连续失败次数达到阈值节点被标记为不可用连续成功次数达到阈值节点恢复可用。这里的核心是时间窗口的概念失败判定耗时 检查间隔 × 连续失败次数举个例子检查间隔5秒、连续失败3次那么设备需要15秒才能把节点判定为故障。如果业务高峰期网络有瞬间抖动第一次检查超时、第二次检查超时、第三次检查刚好赶上网卡处理延迟节点就被误摘了。反过来间隔设成30秒、失败次数设成3次判定耗时90秒故障影响时间又太长。调参的原则是优先调失败次数不要优先调大间隔。拉大失败次数可以容忍瞬时抖动同时保持故障发现速度不过于迟钝。对于一般TCP业务我常用的初始值是检查间隔5秒、超时3秒、失败3次、恢复2次。这个配置在多数场景下能平衡误杀和故障发现速度但上线后要结合业务实测情况再微调。4.2 健康检查参数表每个参数改的是什么要清楚健康检查参数之间是联动关系单独调一个参数而不看整体效果往往会造成新问题。下面这张表是我维护过程中整理的参考配置不同业务类型需要调整的侧重点不一样参数项作用常见初始值调整方向检查间隔两次健康检查之间的时间间隔5秒间隔越短发现故障越快但压力和误判概率越高超时时间单次检查等待响应的时间上限3秒后端响应慢的业务适当调大避免误杀连续失败次数达到该次数判定节点故障3次网络抖动敏感的业务加大到5-6次连续成功次数达到该次数判定节点恢复2次恢复速度要求高的业务可以设成1次检查端口健康检查连接的后端端口跟随服务端口必须与后端真实监听端口一致不能写管理端口检查端口写错是最低级的翻车现场。后端服务监听8443端口健康检查却配了443端口结果永远是失败节点永远处于不可用状态。配置检查任务时建议先在控制台用“手动测试”按钮验证一次确认返回结果正常再保存配置。4.3 调度算法与会话保持参数之间会打架调度算法的维护难点不是参数本身而是算法和会话保持策略的配合。加权轮询适合后端性能差异明显的场景最小连接数适合长连接业务源地址哈希适合需要会话粘滞的场景。但开了会话保持之后再固定的调度算法也会被会话保持逻辑“覆盖”掉——这是最常见的误用。一个典型的错配场景是业务用了会话保持同时后端权重调整想控制流量比例结果发现权重怎么调都没用。原因在于会话保持优先后续同一源地址的请求会持续被调度到同一台后端权重只对新建会话生效。遇到这种情况不要死磕权重参数先确认会话保持超时时间和调度算法是否匹配业务特征。会话保持超时时间也是日常维护不得不调的参数。超时太短用户频繁被重新调度表现为“登录后一会儿又被踢下线”超时太长后端服务器释放时还有大量会话保持记录造成节点权重失衡。判断依据很简单会话保持超时略大于业务的登录态有效期即可。比如业务登录态30分钟会话保持超时设成45分钟是合理的。连接超时参数关注度低但影响面大。四层业务的连接超时设置过短长轮询应用会被设备主动断开连接。排查时表现为“连接偶尔断一下、没有规律”把连接超时从30秒调到300秒后问题消失。这类问题日志里不一定有明确的报错需要靠排查经验积累。5. 维护避坑记录四次告警抖动四种“我以为”日常维护的坑绝大多数不是设备本身的功能缺陷而是对设备行为逻辑的理解偏差。这里记录四个典型的故障排查过程每一条都是“现象—原因—解决”的结构供排查时对照。5.1 健康检查全红业务访问却正常现象某个节点池内的所有后端服务器在控制台上全部显示不可用但直接访问后端服务器的业务端口完全正常。原因健康检查端口写错检查了后端没有监听的端口或者检查路径返回了预期外的状态码。最隐蔽的是HTTP健康检查配置了首页路径但该路径做了重定向每次检查返回301/302设备判定为失败。解决先用控制台的“手动测试”功能对目标后端发起一次健康检查观察返回内容确认检查端口与后端监听端口一致HTTP检查路径避开会做重定向的地址选用一个固定返回200的状态接口。改完之后观察两个检查周期确认节点状态恢复绿色。5.2 主备切换后VIP没有漂移变成了双主现象半夜心跳告警第二天早上看日志发现两台设备都变为主机状态VIP流量混乱。原因心跳链路存在单点隐患比如心跳线经过的交换机端口有间歇性丢包导致主备设备在一定时间内互相认为对方失联各自抢占主角色。解决把心跳口改为物理直连不经过任何交换设备在双机配置里降低心跳超时和重试次数让误判能更快恢复同时确认主备优先级配置正确避免出现两端优先级相同的情况。改造后做一次主动切换演练验证VIP漂移正常。5.3 后端服务器下电前没摘除连接全部RST现象发布窗口对一台后端服务器做下线操作直接关机后访问该业务的用户出现大量报错。原因没有先通过控制台把节点置为“禁用”状态设备仍在向这台服务器转发新连接服务器断电后TCP连接被RST终结用户请求失败。解决发布流程里增加“先摘除节点、再操作服务器、验证完恢复节点”的固定步骤。节点摘除后设备会停止向该节点调度新连接已在处理的连接会在超时后自然断开这一步做完再关机就安全了。这个流程应该写进发布规范而不只是依赖操作人员临时注意。5.4 版本升级后健康检查策略没生效现象设备版本升级完成后部分新建的健康检查任务没有生效节点池依然用旧的参数在运行。原因升级过程中部分配置分区的迁移不完整或者新版本的配置结构有变化旧备份里的策略无法直接对应到新版本。解决升级前确认当前运行版本与目标版本的兼容路径避免跨大版本直接升级升级前导出当前配置升级后逐项核对关键策略不要只看版本号就确认完成发现策略未生效时重新创建健康检查任务并手动测试不要反复导入旧配置。5.5 会话保持突然失效用户反复重新登录现象业务高峰期用户反馈频繁掉线需要反复登录后端服务器负载分布却非常均匀。原因会话保持超时参数被调短刚好短于业务登录态的有效时长导致用户会话频繁被重新调度。解决确认业务登录态的有效时长将会话保持超时设置高于该值同时检查是否在调整其他参数时误改了会话保持策略。会话保持相关参数改动后建议做一次持续连接测试模拟用户长在线场景确认不会中途断掉。6. 应急切换与配置备份维护手册里最值得练熟的两种保命操作日常维护手册里最有价值的不是那些“精致”的参数调优而是在故障窗口里能稳定执行的应急操作。主备切换演练和配置备份恢复是两项一定要练熟的动作。6.1 主备切换演练的正确顺序半年做一次主备切换演练确认VIP漂移和业务恢复能力不是停留在纸面上。演练要在业务低峰期进行流程是先确认备机同步进度为100%再在主机上手动触发切换用一段轮询脚本盯着VIP的漂移时间#!/bin/bash # 用法: ./failover_check.sh VIP地址 TARGET$1 echo 开始轮询 $TARGET 连通性 for i in {1..60}; do if ping -c 1 -W 1 $TARGET /dev/null 21; then echo [$(date %H:%M:%S)] VIP 可达切换完成 exit 0 else echo [$(date %H:%M:%S)] VIP 不可达等待漂移... sleep 2 fi done echo VIP 在 2 分钟内未漂移请检查双机状态 exit 1轮询脚本的意义是把“凭感觉等待”变成“量化观察”。VIP从不可达到可达的时间就是漂移时间正常应该在几秒到十几秒之间。如果超过30秒还未恢复需要立刻终止演练切回原主机并排查心跳和VIP绑定配置。演练完成后记录本次漂移时间、业务恢复时间、后端连接重建情况作为下次演练的对比基线。6.2 配置备份与恢复最容易被忽略的“后悔药”配置备份这件事重要性排在所有维护动作前面。每周导出一份配置文件到本地保留最近三份命名规则统一为“设备名_配置日期”。备份不只是为了防设备损坏更是为了给每一次变更留后路。变更配置前导出一份变更后确认无问题再导出一份回滚时就有两个明确的恢复点。恢复备份时要注意同版本内的备份恢复最稳定跨大版本恢复容易出现部分策略不兼容。恢复完成后按顺序检查授权状态、节点池状态、VIP状态、双机同步状态确认没有因恢复操作引起的次生问题。如果恢复后授权丢失或功能异常优先联系厂商技术支持确认版本兼容路径不要反复尝试导入旧配置。当年我第一次独立负责AD设备维护时觉得双机热备配好就万事大吉结果一次心跳线抖动让我体验了双主故障的滋味。从那以后我把“心跳口物理直连”和“每季度一次切换演练”写进了自己的维护清单再没出过同类问题。这套流程不难难的是每次都按流程走。希望帮到你。本文还有配套的精品资源点击获取