负载均衡ADC替换(二):F5 BIG-IP LTM 到深信服 AD,配置应该怎么翻

负载均衡ADC替换(二):F5 BIG-IP LTM 到深信服 AD,配置应该怎么翻
上一篇解决的是“迁移前要查什么”。这一篇终于开始碰配置。也正是从这里开始很多原本看起来简单的业务会慢慢露出它真正的复杂度。F5 环境通常以 Virtual Server 为入口向外关联 Pool、Monitor、Persistence、SNAT、SSL/HTTP/TCP Profile、Local Traffic Policy 和 iRule。配置树越大越不能顺着文件一路往下抄。那样做很快却会在割接时用更长的时间偿还。比较踏实的办法是从每个 Virtual Server 出发把所有绑定关系追完整。一、先建立 F5 对象映射F5 对象深信服 AD 目标能力迁移重点Virtual Server虚拟服务/VIP地址、端口、协议、监听范围、默认池、SNAT 和策略Pool节点池成员、端口、权重、优先级组和最少可用成员Node/Pool Member业务主机/节点区分节点状态与服务端口状态Monitor业务健康检查请求内容、Host、响应判据、间隔、超时和状态翻转次数SNAT Automap/SNAT PoolSNAT/地址集地址选择、端口容量、回程和日志溯源Persistence Profile会话保持类型、Cookie 名称、超时、源地址掩码和故障重选Client SSL/Server SSLSSL 卸载/加密策略证书、SNI、协议套件、双向认证和回源校验HTTP/TCP ProfileHTTP/TCP 策略长连接、复用、空闲超时和协议解析差异Local Traffic Policy前置或七层策略匹配条件、动作、优先级和默认池iRule标准策略或 iPro 重构按事件、条件、动作和状态重新实现Route Domain/Partition路由或租户隔离地址重叠、路由表、权限和对象可见性这张表只能解决对象归属不能证明行为一致。尤其是 SNAT、Persistence、Profile 和 iRule默认值或执行阶段不同最终结果就可能不同。二、用一个 HTTPS 业务说明翻译顺序假设 F5 上有这样一个业务入口https://portal.polarsight.com.cn:443 前端卸载 TLS 选路/api/* 进入 api_pool其他请求进入 web_pool 源地址向后端插入 X-Forwarded-For 会话Cookie 保持 30 分钟 回源HTTPS并校验后端证书在深信服 AD 上不要先建一个 VIP 再到处补绑定。按依赖顺序配置创建 web_pool、api_pool 及成员为两个节点池建立应用级健康检查确认算法、权重、优先级和全部成员不可用时的行为导入站点证书、私钥和完整证书链创建 HTTPS 虚拟服务配置前端和后端 TLS创建/api/路径策略明确优先级与默认节点池清理不可信 XFF再写入真实客户端地址配置 Cookie 保持及超时分别测试普通路径、API、会话、成员故障和后端证书异常。这样做慢一点但依赖关系清楚。任何一步失败都能定位到具体层次而不是在一个已经绑定十几项策略的 VIP 上反复试错。割接窗口里的时间很贵前期多做的这些笨功夫到了现场都会还回来。三、Monitor 要翻译请求不是翻译名称F5 上的http、httpsMonitor 名称相同配置内容可能完全不同。迁移时至少记录请求方法和 URIHost Header发送和接收字符串检查间隔、超时成员下线和恢复条件HTTPS 检查是否校验证书。最常见的错误是把原来的/health检查改成 TCP 端口检查。端口正常但应用已经返回 500 时新设备仍会继续转发。四、SNAT 先看回程再看地址F5automap通常使用出口 Self IP 做源地址转换SNAT Pool 则从指定地址池选地址。翻译到深信服 AD 时要确认原环境为什么启用 SNAT回程是否必须经过 ADC地址池容量是否满足并发连接和端口使用服务器审计怎样获取真实客户端地址前面还有代理时XFF 信任链怎样处理。不要看到automap就机械选择“自动 SNAT”。如果目标拓扑已经改成路由模式源地址策略可能需要重新设计。五、Persistence 要测试故障后的行为Cookie、源地址、SSL Session 等保持类型不能混用。除了保持类型和超时还要检查Cookie 是 ADC 插入还是应用生成Cookie 名称、域、路径和安全属性源地址保持使用多大的掩码原成员故障后是否重新选成员备用保持策略是否存在。验证时不能只连续刷新。应先确认请求固定到同一成员再主动下线该成员观察业务是否按照设计重新分配。六、Client SSL 和 Server SSL 分开迁移F5 的 Client SSL 处理客户端到 ADCServer SSL 处理 ADC 到后端。迁移时要分别确认前端证书、证书链和 SNITLS 版本和密码套件是否要求客户端证书回源使用 HTTP 还是 HTTPS是否校验后端证书、主机名和 CA。只看到前端 HTTPS 就把回源改成 HTTP是替换中非常常见的错误。七、iRule 不要逐行翻译iRule 真正的依赖不只在代码正文里还包括触发事件、Data Group、变量、连接状态以及其他 Profile 和 Policy。最让人头疼的往往不是几百行的大脚本而是那段只有十几行、没有注释、大家又不敢删的旧逻辑。每条 iRule 先整理成项目内容触发阶段建连、HTTP 请求、选池、服务器响应等匹配条件地址、Host、URI、Header、Cookie、TLS 属性动作选池、选节点、改写、重定向、拒绝、SNAT外部依赖Data Group、DNS、文件或第三方系统状态连接变量、跨请求状态和超时失败路径无匹配、节点池不可用或脚本异常时怎么处理Host、URI、Header 选路通常可以改成标准七层策略。跨请求状态、外部查询和特殊协议处理先做 PoC不要直接承诺“一键转换”。八、割接前怎么验收至少完成以下测试各 Host、URI 和方法是否进入正确节点池XFF、Cookie、重定向地址和响应头是否一致前后端 TLS 是否符合安全要求单个成员和整个节点池故障时如何处理主备切换对长连接和登录状态有什么影响日志、监控和告警能否定位到业务对象。F5 迁移做到这里心里应该有一张清楚的依赖图一个请求从 Virtual Server 进来依次经过哪些 Profile、Policy 和 iRule最后为什么落到这个 Pool。只要这张图还说不清就不要急着约割接。下一篇转到 A10。它同样有 VIP、服务器组和模板但阅读配置时要再多留一个心眼很多关键参数藏在 Virtual Server 的具体端口下面。参考资料F5 BIG-IP Virtual ServerF5 BIG-IP SNAT