企业官网建设流程全解析

简介：本资源是深信服科技大客户服务部官方发布的《负载均衡AD日常维护手册簿》，面向企业网络运维工程师、系统管理员及IT技术支持人员，聚焦SANGFOR AD设备的标准化巡检与故障排查实践。手册按日、周两级维护周期组织内容，涵盖硬件状态灯与接口指示灯检查、CPU运行监控、控制台账号安全加固、配置文件备份、远程维护关闭等关键操作，并针对“无法登录控制台”“虚拟服务不可访问”“DNS策略不生效”等7类高频问题提供分步排错指引。资源为单个Word文档（.doc），大小519KB，结构清晰、图文结合，含修订历史、目录索引与版权声明，便于现场查阅与知识沉淀。目前已有249人学习下载，适合需快速掌握AD设备日常保障要点与应急处置能力的中级以上运维人员。

1. 这不是“手册簿”，而是深信服AD负载均衡设备的日常运维操作地图

很多人拿到《深信服负载均衡AD日常维护手册簿.doc》第一反应是：点开、打印、束之高阁。但真实场景里，它根本不是用来“读完”的文档——而是故障发生前30分钟你该翻哪一页、参数改哪一项、日志查哪个路径的即时索引。深信服AD（Application Delivery）系列设备（如AD1000/2000/3000等）在企业出口、Web应用前置、SSL卸载等关键链路中承担真实流量调度，其“日常维护”本质是三件事：状态可观测、配置可回滚、变更可验证。它不解决“怎么部署一台新AD”，而是聚焦于“已上线AD如何避免因DNS解析异常、会话保持失效、健康检查误判导致业务抖动”。适用对象非常明确：持有设备管理员权限、需对HTTP/HTTPS/TCP类业务SLA负责的网络工程师、SRE或混合云运维人员；新手能按步骤执行基础巡检，5年以上从业者则需关注session persistence timeout与real server health check interval的耦合影响、DNS proxy mode切换时的缓存残留风险等隐性边界。

2. 深信服AD负载均衡核心组件与运维视角下的功能映射

深信服AD的“负载均衡”能力并非单一模块，而是由虚拟服务（Virtual Service）、节点池（Node Pool）、健康检查（Health Check）、会话保持（Persistence）、DNS代理（DNS Proxy）五大组件协同实现。日常维护必须理解每个组件在运维动作中的实际作用域，而非仅记忆界面位置。

2.1 虚拟服务：流量入口的精确控制点

虚拟服务是对外暴露的IP:Port组合，所有客户端请求首先进入此处。运维中需重点关注三项配置：

• 协议类型与端口映射：HTTP/HTTPS需启用SSL卸载时，必须绑定证书并设置Client SSL Profile；TCP类服务（如数据库代理）则需关闭SSL处理以降低延迟。
• 调度算法选择：Weighted Least Connections适用于后端节点性能差异大的场景；Source IP Hash在需保持客户端源IP会话时不可替代，但要注意NAT环境下的哈希失真问题。
• 连接限制策略：Max Connections Per Client防止单IP耗尽连接数；Connection Rate Limit应对突发流量冲击，单位为connections/sec，建议初始值设为当前峰值的1.5倍并持续观察告警日志。

提示：修改虚拟服务配置后，必须点击“立即生效”按钮（非保存），否则变更仅存于草稿区。深信服AD的配置提交采用两阶段确认机制，这是高频误操作点。

2.2 节点池与真实服务器：健康检查的执行主体

节点池定义后端真实服务器（Real Server）列表，其稳定性直接决定业务可用性。运维关键在于健康检查配置的合理性：

• 检查方式选择：HTTP服务优先用HTTP GET，路径设为/healthz（需后端应用提供轻量接口）；TCP服务用TCP Connect，超时时间建议≤3秒；ICMP仅作辅助探测，不能替代应用层检查。
• 检查参数调优：Interval（检查间隔）与Retries（失败重试次数）需匹配后端响应特性。例如Java应用冷启动慢，Interval=10s+Retries=3比默认5s/2更稳妥；而Go微服务响应快，可设为3s/1加速故障剔除。
• 权重动态调整：通过CLI命令可实时修改节点权重，无需重启服务：

# 登录AD设备SSH终端（需开启SSH管理） [admin@AD]# config system node-pool [admin@AD-node-pool]# edit "web_pool" [admin@AD-node-pool-web_pool]# set node "192.168.10.101" weight 80 [admin@AD-node-pool-web_pool]# end

此命令将节点192.168.10.101在web_pool中的权重设为80（默认100），适用于灰度发布或单节点压测场景。

2.3 DNS代理服务：深信服AD作为DNS解析中枢的运维要点

标题中“DNS”高频出现，正因其在AD中承担双重角色：对外提供DNS解析服务（DNS Proxy）和对内依赖DNS完成后端域名解析（如节点池使用FQDN）。运维需区分两种模式：

• DNS Proxy模式：AD自身作为DNS服务器响应客户端查询。需在网络 > DNS代理中启用，并配置转发器（Forwarder）指向上游DNS（如运营商DNS或内部BIND）。关键参数：
  • Cache TTL：默认300秒，高变更率域名（如CDN地址）建议降至60秒；
  • EDNS Support：必须开启，否则无法解析大于512字节的DNS响应（如含多IP的AAAA记录）。
• FQDN节点解析：当节点池添加www.example.com而非IP时，AD需主动发起DNS查询。此时需检查系统 > 网络 > DNS设置中的DNS服务器地址是否可达，且DNS查询超时建议设为5秒（避免阻塞健康检查）。

注意：DNS Proxy与FQDN解析共用同一套DNS配置，但故障现象不同——前者表现为客户端nslookup超时，后者表现为节点池状态显示Resolving或Down。排查时务必先用ping和dig @<AD_IP> www.example.com确认AD自身DNS连通性。

3. 日常巡检与故障定位：从告警到根因的标准化路径

深信服AD的日常维护不是被动响应告警，而是建立“指标监控→日志溯源→配置验证→快速回滚”的闭环。以下为一线工程师验证过的四步法，覆盖85%以上常见问题。

3.1 关键指标巡检：5分钟完成健康快照

登录Web管理界面后，按顺序检查以下4个页面，每项停留≤30秒：

1. 首页概览：确认CPU利用率<70%、内存使用率<85%、当前连接数未达最大连接数阈值（可在系统 > 配置 > 系统参数中查看）。若CPU持续>85%，需进入监控 > 性能监控查看SSL握手耗时是否异常升高（可能证书链过长或CRL校验失败）。
2. 虚拟服务列表：筛选状态为Down的服务，点击进入查看当前会话数是否为0（确认是否真无流量）及最后更新时间是否停滞（判断是否配置未生效）。
3. 节点池状态：对状态为Down的节点，检查健康检查结果列——若显示Timeout，立即用telnet <节点IP> <端口>验证网络连通性；若显示HTTP Status 5xx，需联系应用方确认/healthz接口返回码。
4. DNS代理统计：在网络 > DNS代理 > 统计信息中，观察拒绝查询数是否突增。若拒绝原因为Query Refused，大概率是ACL策略拦截；若为Server Failure，则上游DNS不可达。

3.2 日志深度分析：定位配置漂移与时间窗口

深信服AD日志分为系统日志（设备级）和安全日志（策略级），日常维护重点在系统日志的CONFIG和HEALTH类别：

• CONFIG日志：记录所有配置变更，格式为[2024-03-15 14:22:03] [admin] CONFIG: modify virtual-server "vs_web" port 443。当业务异常时，首先筛选变更时间点前后30分钟的日志，确认是否有误操作（如删除了健康检查模板）。
• HEALTH日志：记录节点状态变化，关键字段为node-down和node-up。例如：

  [2024-03-15 14:25:18] HEALTH: node "192.168.10.102" in pool "web_pool" changed to DOWN (reason: HTTP status 503)

  此日志表明节点因返回503被剔除，需立即检查该节点应用日志，而非调整AD健康检查参数。

3.3 配置一致性验证：防止UI与CLI状态错位

深信服AD存在UI配置未同步至底层的情况（尤其在批量导入/导出后）。验证方法：

# 通过SSH登录，导出当前运行配置 [admin@AD]# show running-config | grep "virtual-server vs_web" # 输出应包含完整虚拟服务定义，包括调度算法、节点池引用等 # 若缺失关键行（如"persistence source-ip"），说明UI配置未生效

更彻底的方式是比对running-config与startup-config：

[admin@AD]# compare startup-config running-config # 输出差异即为未保存的临时配置，需执行`write memory`固化

3.4 快速回滚机制：基于配置版本的时间机器

深信服AD支持最多10个配置版本快照，默认每24小时自动保存一次。回滚步骤：

1. 进入系统 > 配置 > 配置版本，找到故障发生前的版本（时间戳+描述）；
2. 勾选该版本，点击恢复；
3. 关键动作：在弹出的确认框中，务必勾选恢复后立即生效，否则仅保存不激活；
4. 观察首页配置版本显示已切换，等待1分钟确认业务恢复。

提示：建议在重大变更（如升级、证书更新）前手动创建版本，命名规则为YYYYMMDD_变更内容_操作人（如20240315_ssl_renewal_zhangsan），避免版本描述模糊。

4. 升级客户端与DNS服务配置：两个高频操作的避坑指南

标题中“升级客户端”与“DNS”并列，实指两类强关联操作：AD设备固件升级后的管理客户端兼容性和DNS服务在升级后的配置继承问题。这两者常被当作独立任务，但实际存在隐性依赖。

4.1 AD固件升级后管理客户端适配方案

深信服AD升级固件（如从AD7.0.12升至AD7.1.0）后，旧版Web管理界面可能因JavaScript框架变更而功能异常（典型症状：节点池编辑页空白、健康检查参数无法保存）。解决方案分三级：

• 一级适配（推荐）：使用Chrome/Edge最新版，清除浏览器缓存（Ctrl+Shift+Del→ 勾选“缓存图片和文件”），访问https://<AD_IP>/login.jsp?clearcache=1强制刷新资源。
• 二级适配：若仍异常，下载对应固件版本的离线管理包（官网搜索“AD <版本号> 管理工具”），解压后运行ad_admin_tool.exe，该工具内置适配该版本的JS库。
• 三级适配（应急）：通过CLI执行关键操作，例如重置健康检查：

[admin@AD]# config system health-check [admin@AD-health-check]# edit "hc_http" [admin@AD-health-check-hc_http]# set http-method GET [admin@AD-health-check-hc_http]# set http-url "/healthz" [admin@AD-health-check-hc_http]# next [admin@AD-health-check]# end

4.2 DNS服务升级后的配置继承验证表

固件升级可能重置DNS相关参数，下表列出必须人工核验的5项配置（升级后30分钟内完成）：

注意：执行set命令后，必须输入end退出配置模式，再执行write memory保存。遗漏write memory会导致重启后恢复默认配置。

4.3 DNS解析异常的快速诊断命令集

当业务反馈“域名解析慢”或“解析失败”时，按以下顺序执行CLI命令，5分钟内定位根因：

# 1. 确认AD自身DNS连通性 [admin@AD]# execute ping 114.114.114.114 # 2. 测试AD向上游DNS发起查询的能力 [admin@AD]# execute nslookup www.baidu.com 114.114.114.114 # 3. 检查AD DNS缓存中是否存在该域名（排除缓存污染） [admin@AD]# execute show dns-cache | grep "www.baidu.com" # 4. 若缓存存在但返回错误，清空指定域名缓存（不重启服务） [admin@AD]# execute clear dns-cache www.baidu.com # 5. 验证DNS Proxy是否正常响应客户端查询（从客户端IP测试） [admin@AD]# execute debug dns-proxy packet-filter src-ip <客户端IP> # 观察后续日志中是否有"query accepted"和"response sent"

其中第5步是关键——它模拟客户端真实请求路径，能发现ACL策略、端口监听异常等UI界面无法呈现的问题。

5. 会话保持与健康检查的耦合优化：一个被低估的性能杠杆

深信服AD的会话保持（Persistence）与健康检查（Health Check）看似独立，但在高并发场景下存在深度耦合：当健康检查失败导致节点剔除时，若会话保持策略未及时失效，用户请求仍会被路由至已Down节点，造成业务中断。这并非配置错误，而是机制设计使然，需通过参数协同优化。

5.1 会话保持超时与健康检查间隔的黄金比例

默认情况下，Source IP Hash会话保持超时时间为3600秒（1小时），而健康检查间隔为5秒。这意味着：若某节点在t=0s被健康检查判定为Down，AD需等待最长3600s才释放其关联的会话。优化方案是将两者设为关联值：

• 计算公式：Persistence Timeout = Health Check Interval × Retries × 3
  例如健康检查设为Interval=10s, Retries=3，则Persistence Timeout应设为90秒（10×3×3）。
• 配置路径：虚拟服务 > 会话保持 > 源IP哈希 > 超时时间，输入计算值后保存。
• 验证效果：在节点Down后，执行show virtual-server vs_web session，观察对应源IP的会话条目在90±5秒内消失。

5.2 基于Cookie的会话保持在HTTPS卸载场景的特殊处理

当AD启用SSL卸载时，客户端与AD之间为HTTPS，AD与后端之间为HTTP。此时若使用HTTP Cookie会话保持，需确保：

• 后端应用生成的Set-Cookie头中Domain属性与AD虚拟服务域名一致（如Domain=app.example.com）；
• AD的Cookie Persistence配置中Cookie Name必须与后端写入的Cookie名完全匹配（区分大小写）；
• 关键参数：勾选Secure Cookie（强制Cookie仅通过HTTPS传输）和HttpOnly（防XSS窃取），但若后端HTTP服务不支持Secure属性，需取消勾选，否则Cookie被浏览器丢弃。

5.3 健康检查脚本化：用Python自动校验节点状态

对拥有数十个节点池的大型环境，人工巡检效率低下。以下Python脚本通过AD的REST API自动获取节点状态并发送企业微信告警：

# ad_health_check.py import requests import json import time # AD设备API配置 AD_URL = "https://192.168.1.100" USERNAME = "admin" PASSWORD = "your_password" HEADERS = {"Content-Type": "application/json"} # 获取会话Token login_data = {"username": USERNAME, "password": PASSWORD} resp = requests.post(f"{AD_URL}/auth/login", json=login_data, verify=False) token = resp.json()["data"]["token"] # 查询所有节点池状态 headers_with_token = {**HEADERS, "Authorization": f"Bearer {token}"} pools_resp = requests.get(f"{AD_URL}/api/v1/node-pool", headers=headers_with_token, verify=False) for pool in pools_resp.json()["data"]: for node in pool["nodes"]: if node["status"] != "UP": # 发送告警（此处简化为print，实际替换为企业微信API） print(f"ALERT: Node {node['ip']} in pool {pool['name']} is DOWN, reason: {node['health_reason']}") # 每5分钟执行一次 time.sleep(300)

逻辑说明：脚本首先通过/auth/login获取Bearer Token，再调用/api/v1/node-pool获取全量节点池数据。node["status"]字段为UP/DOWN/UNKNOWN，node["health_reason"]提供具体失败原因（如Connection refused）。参数说明：verify=False绕过SSL证书校验（生产环境应配置CA证书）；time.sleep(300)实现5分钟轮询，可根据需求改为Linux cron定时任务。

此脚本将人工巡检转化为自动化守护，且输出的health_reason直接对应深信服AD日志中的HEALTH事件，极大缩短MTTR（平均修复时间）。

本文还有配套的精品资源，点击获取