前四篇处理的是本地 ADC请求已经来到 VIP设备怎样选节点、做保持、处理源地址和 TLS。GSLB 再往前一步它决定客户端应该拿到哪个站点的地址。看起来只是一次 DNS 回答背后牵着的却是整个数据中心的入口。因此GSLB 迁移不能只看设备策略。权威 DNS、递归 DNS、域名委派、TTL、站点健康和客户端缓存都在同一条链路上。任何一环没有处理好都会出现那种最让人焦虑的场面设备上看着一切正常监控也没有明显告警偏偏还有一部分用户固执地访问旧站点。一、先画清 DNS 查询链至少要回答业务域名的 A、AAAA、CNAME 和 NS 关系是什么哪台设备或 DNS 服务器是权威上级域如何委派企业内网是否使用独立 DNS 视图客户端使用哪些递归 DNS当前 TTL 和实际缓存时间是多少GSLB 返回的地址在哪台防火墙做 NAT每个站点的业务 VIP 由谁承载。建议从客户端执行一次完整解析再分别查询递归 DNS、权威 DNS 和 GSLB 监听地址确认每一步的返回结果。只看管理界面的域名状态不够。二、GSLB 配置应该怎么翻译不同厂商名称不同但迁移对象大致可以归为原环境对象迁移后的业务含义Wide IP/GSLB vserver/Zone对外提供解析的业务域名Pool/Service/Address候选站点或业务地址Site/Data Center数据中心或云区域Monitor/Health Check本地或远程业务探测Topology/Policy地域、运营商、优先级、权重等选择规则Persistence同一来源在一段时间内保持站点一致TTLDNS 结果可缓存时间Fallback/Backup主站点不可用时的备用返回逻辑翻译时不要只记录“域名对应两个 IP”。还要写清哪些条件选择主数据中心哪些地区或运营商进入第二数据中心健康检查失败几次后停止返回全部站点异常时返回什么站点恢复后自动回切还是人工确认会话和应用数据是否允许用户切换站点。三、站点健康不能只检查本地端口GSLB 判断站点是否可用最好基于能代表真实业务的探测。只探测本地 ADC 的 443 端口无法发现后端应用、数据库或关键依赖已经异常。探测设计要平衡两个问题太浅端口正常业务已经不可用太深检查本身依赖数据库、认证或第三方接口容易产生误判和额外压力。比较稳妥的做法是提供轻量业务健康接口既能反映应用关键依赖又不执行真实交易。跨数据中心还要防止单点探测误判。探测源、网络路径和站点本身要分开观察否则一条探测链路异常可能导致整个站点被错误摘除。四、双数据中心不是 DNS 切过去就结束GSLB 只负责把用户送到站点入口。站点是否真正能接管还取决于应用和数据是否同步用户会话能否跨站点防火墙和公网 NAT 是否完整证书、域名和回源配置是否一致第三方回调和白名单是否包含两个站点站点容量能否承接故障流量监控能否区分 DNS、入口和应用故障。如果应用只能单中心写入GSLB 的“自动切换”就不能单独决定。切换策略必须与数据库、存储和业务连续性设计一致。五、整体替换还是平滑迁移复用原 DNS 入口整体切换在维护窗口中停止旧 GSLB由新设备接管原监听地址或域名委派。地址改动少但风险集中对配置准确性和回退速度要求高。适合域名少、策略简单、缓存可控并且已经完成充分演练的环境。使用新入口平滑迁移为深信服 AD 规划新的 GSLB 地址或测试子域名先验证解析、探测和站点切换再分批调整 CNAME、NS 委派或业务域名。出现以下情况时优先考虑平滑迁移域名和站点数量多存在地域、运营商或拓扑规则内外网使用不同 DNS 视图无法确认所有递归 DNS 的缓存行为应用跨站点切换还需要人工确认一个域名承载多个关键业务。六、TTL 怎么处理正式切换前可以按计划逐步降低 TTL缩短新查询获取旧结果的时间。但不要把 TTL 当成精确倒计时。DNS 世界很少像秒表一样准时它更像潮水大部分结果会按预期退去总有一些缓存会晚一点。部分递归 DNS、操作系统和应用会延长缓存客户端也可能保留已有连接。权威记录已经更新不等于所有用户立即拿到新结果。建议的操作顺序是提前一个以上原 TTL 周期降低 TTL验证各主要递归 DNS 已看到新 TTL在切换窗口更新委派或记录同时观察旧、新站点流量保留旧入口直到缓存和连接基本收敛稳定后再恢复正常 TTL。七、平滑迁移的实施步骤1. 建立基线记录现有域名解析、站点流量、探测状态、TTL、错误率和切换时间。对关键地区和运营商分别保存解析结果。2. 构建新 GSLB先创建站点、服务地址和健康检查再建立域名、调度策略、保持和备用逻辑。不要先发布正式域名再补探测。3. 使用测试子域名通过测试子域名验证各地区、运营商、站点故障和恢复。确认返回地址、TTL 和应用访问都符合预期。4. 小流量切换选择非关键域名、测试用户或部分区域先迁移观察 DNS 查询、站点入口、应用错误和响应时间。5. 分批迁移正式域名每批域名设独立观察窗口。不要一次修改全部委派。分批看起来慢却能让团队在每一步都知道流量去了哪里一口气全切出了问题只会面对一团混在一起的策略、缓存和站点故障。6. 过完观察期再下线旧入口旧设备、旧监听地址和旧委派保留到缓存和业务连接收敛。确认不再有有效查询和流量后再进入下线流程。八、故障和回退怎么测至少演练单个后端节点故障本地 ADC 故障站点出口链路故障整个数据中心不可用远程探测链路异常主站点恢复后的回切两个站点同时不可用DNS 返回正确但应用交易失败。每个场景记录探测发现时间、停止返回时间、递归 DNS 缓存影响、客户端恢复时间和业务错误率。回退方案要写清恢复哪条 NS、CNAME 或 A 记录旧设备多久能恢复权威服务以及怎样证明主要递归 DNS 已重新获得旧结果。九、整个系列最终解决什么问题五篇文章从不同层次处理同一件事第一篇先把网络、业务和依赖查清第二篇从 F5 Virtual Server 追踪 Profile、Policy 和 iRule第三篇从 A10 端口配置追踪 Service Group 和 Template第四篇还原 NetScaler Policy/Action 的绑定和执行顺序第五篇把本地应用负载扩展到 DNS、站点和双数据中心。无论替换的是哪一家设备判断项目是否具备割接条件最后还是看三件事正常流量是否按预期进入正确目标故障时业务行为是否经过验证出问题后能否在规定时间内恢复原路径。做完最后一次验证、看到旧设备流量真正归零的时候项目团队才可以放心松一口气。配置对象数量相同从来不是标准业务行为可验证、故障路径可控制、运维团队能接管才算把这次替换做完整了。参考资料NetScaler GSLB Content Switching深信服 AD 网络部署
前四篇处理的是本地 ADC请求已经来到 VIP设备怎样选节点、做保持、处理源地址和 TLS。GSLB 再往前一步它决定客户端应该拿到哪个站点的地址。看起来只是一次 DNS 回答背后牵着的却是整个数据中心的入口。因此GSLB 迁移不能只看设备策略。权威 DNS、递归 DNS、域名委派、TTL、站点健康和客户端缓存都在同一条链路上。任何一环没有处理好都会出现那种最让人焦虑的场面设备上看着一切正常监控也没有明显告警偏偏还有一部分用户固执地访问旧站点。一、先画清 DNS 查询链至少要回答业务域名的 A、AAAA、CNAME 和 NS 关系是什么哪台设备或 DNS 服务器是权威上级域如何委派企业内网是否使用独立 DNS 视图客户端使用哪些递归 DNS当前 TTL 和实际缓存时间是多少GSLB 返回的地址在哪台防火墙做 NAT每个站点的业务 VIP 由谁承载。建议从客户端执行一次完整解析再分别查询递归 DNS、权威 DNS 和 GSLB 监听地址确认每一步的返回结果。只看管理界面的域名状态不够。二、GSLB 配置应该怎么翻译不同厂商名称不同但迁移对象大致可以归为原环境对象迁移后的业务含义Wide IP/GSLB vserver/Zone对外提供解析的业务域名Pool/Service/Address候选站点或业务地址Site/Data Center数据中心或云区域Monitor/Health Check本地或远程业务探测Topology/Policy地域、运营商、优先级、权重等选择规则Persistence同一来源在一段时间内保持站点一致TTLDNS 结果可缓存时间Fallback/Backup主站点不可用时的备用返回逻辑翻译时不要只记录“域名对应两个 IP”。还要写清哪些条件选择主数据中心哪些地区或运营商进入第二数据中心健康检查失败几次后停止返回全部站点异常时返回什么站点恢复后自动回切还是人工确认会话和应用数据是否允许用户切换站点。三、站点健康不能只检查本地端口GSLB 判断站点是否可用最好基于能代表真实业务的探测。只探测本地 ADC 的 443 端口无法发现后端应用、数据库或关键依赖已经异常。探测设计要平衡两个问题太浅端口正常业务已经不可用太深检查本身依赖数据库、认证或第三方接口容易产生误判和额外压力。比较稳妥的做法是提供轻量业务健康接口既能反映应用关键依赖又不执行真实交易。跨数据中心还要防止单点探测误判。探测源、网络路径和站点本身要分开观察否则一条探测链路异常可能导致整个站点被错误摘除。四、双数据中心不是 DNS 切过去就结束GSLB 只负责把用户送到站点入口。站点是否真正能接管还取决于应用和数据是否同步用户会话能否跨站点防火墙和公网 NAT 是否完整证书、域名和回源配置是否一致第三方回调和白名单是否包含两个站点站点容量能否承接故障流量监控能否区分 DNS、入口和应用故障。如果应用只能单中心写入GSLB 的“自动切换”就不能单独决定。切换策略必须与数据库、存储和业务连续性设计一致。五、整体替换还是平滑迁移复用原 DNS 入口整体切换在维护窗口中停止旧 GSLB由新设备接管原监听地址或域名委派。地址改动少但风险集中对配置准确性和回退速度要求高。适合域名少、策略简单、缓存可控并且已经完成充分演练的环境。使用新入口平滑迁移为深信服 AD 规划新的 GSLB 地址或测试子域名先验证解析、探测和站点切换再分批调整 CNAME、NS 委派或业务域名。出现以下情况时优先考虑平滑迁移域名和站点数量多存在地域、运营商或拓扑规则内外网使用不同 DNS 视图无法确认所有递归 DNS 的缓存行为应用跨站点切换还需要人工确认一个域名承载多个关键业务。六、TTL 怎么处理正式切换前可以按计划逐步降低 TTL缩短新查询获取旧结果的时间。但不要把 TTL 当成精确倒计时。DNS 世界很少像秒表一样准时它更像潮水大部分结果会按预期退去总有一些缓存会晚一点。部分递归 DNS、操作系统和应用会延长缓存客户端也可能保留已有连接。权威记录已经更新不等于所有用户立即拿到新结果。建议的操作顺序是提前一个以上原 TTL 周期降低 TTL验证各主要递归 DNS 已看到新 TTL在切换窗口更新委派或记录同时观察旧、新站点流量保留旧入口直到缓存和连接基本收敛稳定后再恢复正常 TTL。七、平滑迁移的实施步骤1. 建立基线记录现有域名解析、站点流量、探测状态、TTL、错误率和切换时间。对关键地区和运营商分别保存解析结果。2. 构建新 GSLB先创建站点、服务地址和健康检查再建立域名、调度策略、保持和备用逻辑。不要先发布正式域名再补探测。3. 使用测试子域名通过测试子域名验证各地区、运营商、站点故障和恢复。确认返回地址、TTL 和应用访问都符合预期。4. 小流量切换选择非关键域名、测试用户或部分区域先迁移观察 DNS 查询、站点入口、应用错误和响应时间。5. 分批迁移正式域名每批域名设独立观察窗口。不要一次修改全部委派。分批看起来慢却能让团队在每一步都知道流量去了哪里一口气全切出了问题只会面对一团混在一起的策略、缓存和站点故障。6. 过完观察期再下线旧入口旧设备、旧监听地址和旧委派保留到缓存和业务连接收敛。确认不再有有效查询和流量后再进入下线流程。八、故障和回退怎么测至少演练单个后端节点故障本地 ADC 故障站点出口链路故障整个数据中心不可用远程探测链路异常主站点恢复后的回切两个站点同时不可用DNS 返回正确但应用交易失败。每个场景记录探测发现时间、停止返回时间、递归 DNS 缓存影响、客户端恢复时间和业务错误率。回退方案要写清恢复哪条 NS、CNAME 或 A 记录旧设备多久能恢复权威服务以及怎样证明主要递归 DNS 已重新获得旧结果。九、整个系列最终解决什么问题五篇文章从不同层次处理同一件事第一篇先把网络、业务和依赖查清第二篇从 F5 Virtual Server 追踪 Profile、Policy 和 iRule第三篇从 A10 端口配置追踪 Service Group 和 Template第四篇还原 NetScaler Policy/Action 的绑定和执行顺序第五篇把本地应用负载扩展到 DNS、站点和双数据中心。无论替换的是哪一家设备判断项目是否具备割接条件最后还是看三件事正常流量是否按预期进入正确目标故障时业务行为是否经过验证出问题后能否在规定时间内恢复原路径。做完最后一次验证、看到旧设备流量真正归零的时候项目团队才可以放心松一口气。配置对象数量相同从来不是标准业务行为可验证、故障路径可控制、运维团队能接管才算把这次替换做完整了。参考资料NetScaler GSLB Content Switching深信服 AD 网络部署
![[PSOC Edge] 【英飞凌 Edgi Talk评测】1.小智Agent语音助手](http://pic.xiahunao.cn/yaotu/[PSOC Edge] 【英飞凌 Edgi Talk评测】1.小智Agent语音助手)
