负载均衡ADC替换（三）：A10 Thunder ADC 到深信服AD

上一篇从 F5 Virtual Server 向外追踪 Pool、Profile、Policy 和 iRule。到了 A10，思路看起来差不多，真正动手时却很容易漏东西：大量生效参数挂在 slb virtual-server 的具体端口下面。只盯着 VIP 地址看，往往会得到一份"看起来很完整"的残缺配置。

同一个 VIP 的 80、443 和其他端口，可能分别绑定不同的 service-group、source NAT、Persistence、HTTP 和 SSL Template。只导出一张 VIP 清单，迁移一定会漏配置。

一、以"VIP + 端口 + 协议"为迁移单元

A10 对象	深信服 AD 目标能力	迁移重点
slb virtual-server + port	虚拟服务/VIP	VIP 与端口级配置一起读取
slb server	业务主机	核对服务器级和端口级状态
slb service-group	节点池	成员、端口、算法、优先级和健康检查
health monitor	业务健康检查	四层/七层请求内容和成功判据
source-nat auto/pool	SNAT/地址集	回程、地址池容量和端口耗尽风险
template persist	会话保持	类型、Cookie、源地址和超时
client-ssl/server-ssl	SSL 卸载/加密策略	证书链、SNI、TLS 和双向认证
template http/policy	HTTP/前置策略	Host、URL、Header 与目标 service-group
aFleX	标准策略或 iPro 重构	按业务意图重建并覆盖每个分支
partition	租户或管理隔离	地址重叠、权限和路由边界

二、顺着端口绑定把依赖找全

假设 A10 配置中看到：

text 复制代码

slb virtual-server portal-vip 10.10.10.10
  port 443 https
    source-nat auto
    service-group sg443
    template persist persist-cookie
    template client-ssl portal-client-ssl
    template http portal-http

不能到这里就开始在深信服 AD 上创建 HTTPS 虚拟服务。还要继续追：

sg443 有哪些成员、端口、权重和健康检查；
persist-cookie 是插入 Cookie 还是读取应用 Cookie；
portal-client-ssl 绑定哪些证书、协议和密码套件；
portal-http 是否包含 Host/URI 选路、Header 插入或连接参数；
source-nat auto 实际使用哪个地址，服务器怎样记录客户端 IP。

Template 只是在配置文件里存在，不代表它正在承载业务。旧设备运行久了，配置里总会留下些历史对象。它们像机房角落里没人认领的线缆：不能看见就拔，也没必要原样搬到新机柜。先确认绑定和流量，再决定去留。

三、Service Group 不只是服务器列表

迁移 slb service-group 时要记录：

服务协议和端口；
成员与权重；
调度算法；
健康检查绑定；
优先级或备用成员；
成员禁用、慢启动和连接限制；
节点池全部不可用时的处理。

同一个 slb server 可能在不同 service-group 中以不同端口提供服务。不要把服务器级状态和端口级状态合并。

四、Health Monitor 要恢复真实探测内容

A10 Monitor 迁移到深信服 AD 时，重点不是它叫 HTTP、HTTPS 还是 TCP，而是实际发了什么、期待收到什么。

对于 HTTP/HTTPS 检查，要确认 URI、Host、方法、Header、状态码和响应关键字。对于需要认证或特殊 SNI 的后端，还要把认证和 TLS 条件一起迁移。

如果旧设备通过响应正文判断应用状态，新设备只检查 200，就可能把统一错误页当成健康响应。

五、Source NAT 要计算端口容量

source-nat auto 迁移后经常被理解成"勾选自动 SNAT"。实际上还要看：

单臂环境是否依赖 SNAT 保证回程；
自动地址来自哪个接口；
是否有专用 NAT Pool；
峰值连接下端口是否够用；
后端日志怎样还原客户端地址；
长连接会不会长期占用地址端口。

如果旧设备使用较大的 SNAT Pool，新设备改成单地址自动 SNAT，压测不充分时很容易在高峰出现端口不足。

六、SSL Template 分客户端侧和服务器侧

template client-ssl 处理客户端到 A10，template server-ssl 处理 A10 到后端。翻译时分别核对：

站点证书、私钥和证书链；
SNI 和多域名绑定；
TLS 版本、密码套件；
是否要求客户端证书；
后端证书是否校验；
回源主机名和 CA。

证书能导入不代表 TLS 行为已经一致，必须通过握手和异常证书场景验证。

七、HTTP Template 和 Policy 先还原选路

A10 可以在 HTTP Template 或 Policy 中按 Host、URL、Header 等条件选择 service-group。迁移时整理成自然语言：

text 复制代码

Host 为 portal.polarsight.com.cn 且 URI 以 /api/ 开头时，
进入 api-service-group；
其他请求进入 web-service-group；
api-service-group 全部不可用时返回维护页面。

然后再在深信服 AD 上建立条件、动作、优先级和默认路径。不要只记录"配置了 URL Switching"。

八、aFleX 的处理原则

aFleX 与 F5 iRule 一样，不能逐行翻译。先拆出触发事件、条件、动作、变量、外部依赖和异常路径。

简单选池和 Header 处理可优先使用标准策略。涉及跨请求状态、动态限速、外部查询或特殊协议的逻辑，单独做 PoC，并为每一个分支准备测试用例。

九、A10 迁移的验收重点

每个 VIP 端口是否绑定正确节点池和模板；
没有使用的历史 Template 是否被误迁；
Source NAT 地址和端口容量是否满足峰值；
Cookie、源地址保持及故障重选是否一致；
Host、URI、Header 选路顺序是否一致；
前后端 TLS 是否符合设计；
aFleX 的每个逻辑分支是否有验证证据。

A10 迁移最容易漏的，就是端口下面那几行看似普通的模板绑定。等到每个端口的 Service Group、SNAT、Persistence、HTTP 和 SSL 都能对上，心里才算真正有底。

下一篇转到 NetScaler。那里的麻烦不只是谁绑定了谁，还包括策略在哪里执行、先执行哪条，以及命中之后到底停不停。

参考资料

A10 Networks ADC 配置对象示例