1. DNS在设计高可用数据库集群时为何常常被低估做数据库运维这些年我越来越发现一个尴尬的事实很多团队在搭建Oracle RAC或者SQL Server集群时把大量精力放在存储选型、网络心跳、共享盘仲裁这些“硬核”环节上唯独对DNS配置的态度是“能解析就行”。结果一到故障切换、节点扩容或者客户端连不上排查到最后往往发现根子就在DNS上。先说一个我自己经历过的场景某客户的生产环境跑的是Oracle RAC三节点存储、操作系统、网格基础设施全都检查过一遍没毛病。但每次客户端从应用服务器连数据库时不时就报ORA-12545连接失败因为目标主机或对象不存在而且报错毫无规律。后来在grid用户下反复执行tnsping才发现SCAN对应的三个IP里面有一个已经被DNS悄悄摘掉了。DNS服务器管理员说“做了健康检查自动摘除”听起来很智能但对Oracle SCAN来说这恰恰是最糟糕的行为。类似的坑在SQL Server集群里也不少比如Windows故障转移集群依赖域控环境下的DNS动态注册域控的DNS回收策略设置不当集群注册的A记录被清理掉导致客户端通过虚拟网络名称VNN访问时明明集群状态正常却死活连不上。这篇文章我就把DNS在这两类集群场景中的实际运用拆开来讲包括SCAN为何要求返回顺序随机、SQL Server为何重度依赖域控DNS以及两套体系在DNS设计上的共性问题。文中涉及的命令、配置思路均来自我实际做过或参与排障过的项目涉及账号密码、真实域名等信息全部脱敏大家抄作业时记得替换成自己环境的值。2. Oracle集群SCAN为何离不开DNS它到底做了什么2.1 SCAN的引入是为了消灭“IP与节点绑定”的维护噩梦在Oracle 11g R2之前客户端连接RAC数据库时tnsnames.ora里写的是各个节点的VIP虚拟IP。假设集群三个节点那就得在连接描述符里依次列出node1-vip、node2-vip、node3-vip配合LOAD_BALANCEON和FAILOVERON来做负载均衡与故障切换。这套方案的问题在于客户端配置和节点拓扑强绑定。今天三节点明天扩一个变成四节点所有客户端的tnsnames.ora全部要改一遍删节点也一样。节点多到十个以上时这简直是一场运维灾难。SCANSingle Client Access Name集群单一客户端访问名出现的意义就是让客户端只认一个域名比如db-scan.example.com至于后面挂了几个节点、每台节点的IP是什么客户端完全不用关心。集群的节点增删只需要在DNS里增删SCAN对应的地址记录客户端的连接串可以几十年不动。这个设计思路实际上是把“集群成员变化”这件事从应用层下沉到了基础服务层让DNS承担了“集群入口路由器”的角色。SCAN需要至少解析出1个IP官方推荐3个能对应集群中的节点数最好。它是典型的“多对一”域名解析场景只是这里的“一”不是一台主机而是一个逻辑入口。DNS返回的IP越多客户端在建立连接时能尝试的路径就越多集群层面的高可用就越有意义。如果你只配一个IP那SCAN实际上是一个单点虽然SCAN监听器本身还能处理远端转发但DNS入口层面的冗余就没了。2.2 让Oracle SCAN真正高可用的3个DNS关键设置SCAN对DNS的要求真不是“能解析就行”这么简单。根据我踩过的坑和Oracle官方文档的建议以下三个设置是标配第一DNS必须开启轮询机制。以常见的Windows Server DNS或者Bind为例确认对SCAN区域设置了Round Robin并且保证默认返回顺序不是固定的。为什么因为Oracle客户端拿到多个IP后虽然自己也会做随机化和重试但如果你DNS层每次返回的顺序都一模一样客户端连接就会“粘”在第一个IP对应的节点上后面节点上的SCAN监听器形同虚设。在我接触过的环境里Windows DNS默认开启Round Robin但Bind需要显式配置即使开启了如果有多层DNS转发也要确保每一层都没有缓存固定顺序的问题。第二SCAN对应的IP不能配置成VIP的DNS记录。很多从单实例迁移到RAC的老手会犯这个错SCAN名字解析出来的地址直接写成了某台节点的VIP。这样配置后客户端虽然能连上但SCAN监听的负载均衡效果完全失效而且这违背了SCAN“独立于节点”的设计初衷。SCAN IP必须是集群规划中专门预留的、不属于任何节点的浮动地址通常在安装Grid Infastructure时在scan配置阶段指定。第三DNS记录TTL存活时间设置要保守。我见过有的客户为了故障切换快把SCAN记录的TTL设成0秒认为这样客户端每次解析都是最新的。实际效果恰恰相反TTL过短会让所有应用端的解析请求全部打到DNS服务器一来增加DNS负载二来一旦DNS服务器抖动所有客户端拿不到解析结果集群整体“失联”。而TTL过长比如一小时节点故障时客户端缓存里还残留着旧IP连接会持续失败很长时间。我的经验是SCAN的TTL设置在30到60秒之间配合客户端的连接重试机制既不会让DNS成为瓶颈也不会让故障切换延迟太久。2.3 SCAN监听器、GNS与DNS的协同关系理清了SCAN的基本要求还有一个容易被忽略的角色GNSGrid Naming Service。GNS是Oracle在11g R2时代跟SCAN一起推出的服务它本质上是一个“集群内部的动态DNS”。启用GNS之后集群的VIP、节点主机名、SCAN域名解析都不需要人工在外部DNS里维护了——集群各自节点启动时会通过GNS自动完成DNS注册。但GNS的引入也让运维多了一个隐藏依赖你必须在DNS里给GNS服务器的地址配置一条转发记录否则集群节点自己解析自己都费劲。实际项目中很多公司并没有启用GNS而是用传统静态DNS方式维护SCAN记录。这样做的优点是域名解析完全由公司DNS团队掌控排查链路更简单缺点是每次节点变更、VIP变更都要提工单改DNS。两种方式我都维护过我的建议是节点数量少不超过5个、变更频率低、DNS团队响应快的环境静态DNS更可控反之如果集群规模大、扩缩容频繁启用GNS能省不少事但相应地要确保DNS里的GNS转发记录永远健康。这里有一个被反复问到的细节SCAN监听器也就是SCAN Listener收到的连接请求为什么需要转发给本地监听器因为SCAN IP是浮动的它可能当前位于节点A上但客户端连接请求要访问的数据实例可能注册在节点B上。SCAN监听器会基于数据库服务的当前注册信息把连接请求转发给实际节点上的LOCAL_LISTENER这个转发过程对客户端完全透明。而这一切发生的第一个前提就是客户端通过DNS找到了SCAN监听器——也就是说网络路径上的第一步依然卡在DNS解析那里。3. SQL Server集群与域控DNS的绑定逻辑3.1 为什么SQL Server集群宁可“绑定”域控也要用DNSSQL Server的高可用方案无论是故障转移集群实例FCI还是AlwaysOn可用性组AG在Windows平台上都跟Active DirectoryAD域环境深度耦合。很多人不理解为什么微软不学Oracle那样搞一个独立于域控的域名入口非要让集群里的每台服务器都加域还要依赖域控的DNS来注册和解析集群相关地址这里面的根本原因是Windows故障转移集群WSFC从设计之初就默认“DNS是集群的地址簿”。集群的每个节点、每个集群网络名称CNO、每个可用性组监听器AG Listener和FCI的虚拟网络名称VNN它们要想被客户端稳定访问必须在AD域控DNS里有一条权威的A记录。域控DNS天然支持安全动态更新Secure Dynamic Update只有通过Kerberos认证的计算机账户才能更新自己的记录这样能防止无关设备在域内“冒名注册”。这个安全模型比大多数开源DNS的开放动态更新要严谨得多。在SQL Server 2016之前AG监听器走的是VNN要求有一个独立的DNS名称和IP。到了SQL Server 2016之后微软引入了DAG分布式可用性组和只读路由等能力但即便是在新版本里只要你是通过可用性组监听器Listener对外提供服务监听器名称就必须要能通过DNS解析到可用性组当前的主副本Primary Replica地址。换句话说可用性组每次发生故障转移Failover监听器背后的DNS记录都要随之“指向新主副本”这个动作虽然由Windows集群自动完成但前提是DNS区域允许集群计算机账户更新记录而且记录本身不能被域控的“陈旧记录清理”机制误删。3.2 故障转移后客户端为何依然连不上旧地址这类问题我排障的次数数都数不过来。现象描述通常惊人地一致主备切换成功了SQL Server报错日志里看不到任何异常集群仪表盘显示所有角色健康但应用端依然报“无法连接到服务器”或者“找不到服务器实例”。直接原因往往是DNS没有及时收敛。Windows集群做故障转移的时候会尝试用新主副本的IP地址更新监听器的DNS记录。如果监听器配置的是动态IPDHCP分配那么这个更新过程通常很快。但如果监听器配置的是静态IP而且该IP对应的DNS记录由管理员手工创建、没有勾选“允许经过身份验证的计算机更新此DNS记录”那么集群节点就会因为没有权限更新记录而静默失败。客户端连不上集群却不知道。另一个隐蔽点是客户端的DNS缓存。即使服务器端DNS记录已经更新了客户端机器上的解析缓存可能还保留着旧地址。Windows默认的DNS缓存时间跟记录TTL有关但对域内记录很多域控DNS会把权威记录的TTL设得很低甚至为0客户端机器上还有“DNS缓存服务”“连接性感知”之类的机制干扰。最后表现就是部分客户端秒级恢复部分客户端要等好几分钟才能重连。解决这类问题一个比较务实的做法是给客户端应用连接串里增加MultiSubnetFailoverTrue配合ApplicationIntentReadOnly做只读路由的话顺便也把ReadOnlyRoutingUrl检查一遍这样SQL Server Native Client/ODBC驱动会并发出连接尝试让访问不再依赖单一地址解析结果。3.3 可用性组监听器、只读路由与域控的“第三次握手”额外讲一个容易被忽略的域控DNS与AG的联动场景只读路由。配置了只读副本的可用性组在监听器上做读写分离时SQL Server需要根据连接字符串中的ApplicationIntent参数把只读流量路由到合适的只读副本。这个路由动作由监听器接收连接后由主副本去“找一个合适的只读副本”但它找副本的方式是通过集群的CMCluster Manager信息以及副本的计算机名再去解析副本地址。如果只读副本不在同一个DNS区域或者副本间的DNS解析存在隔离比如跨子网却没有做好DNS转发路由就可能失败。我亲眼见过一个案例主副本和只读副本分在两个网段公司网络团队为了保证安全在只读副本网段做了出向DNS策略导致只读副本能解析自己网段的设备却解析不了主副本网段的域控地址。结果应用程序尽管连上了可用性组监听器ApplicationIntentReadOnly的请求却始终报“无法访问目标只读副本”。后来在只读副本网段的DNS服务器上放了到主网段域控的“条件转发器”Conditional Forwarder这个问题才解除。所以SQL Server集群的环境中不仅仅是“一个域名对应一个IP”的解析还包含了跨网段、跨区域的解析策略设计这本质上就是DNS在全分布式场景下的基础设施能力。4. 两类集群对DNS的共性要求与核心差异对比4.1 一个表格看清Oracle SCAN与SQL Server AG对DNS的要求差异Oracle RAC SCAN和SQL Server AlwaysOn可用性组虽然都是数据库层面做高可用但它们对DNS的需求在技术实现上有相当大的差异。把它们放在一起对比对需要同时维护两套数据库环境的团队格外有用。维度Oracle RAC SCANSQL Server AG/ListenerDNS核心作用多IP轮询负载均衡提供统一集群入口单/双IP对应当前主副本支撑故障转移动态更新可选GNS启用时动态静态配置常见依赖域控安全动态更新客户端切换核心TTL建议30-60秒兼顾DNS负载与故障切换延迟尽量低可接受30秒内让故障转移尽早收敛是否会解析出多个IP必须至少1个推荐3个一般1个多子网场景可为多个对DNS轮询的依赖高轮询顺序直接影响负载分布低客户端驱动有MultiSubnetFailover机制最大风险SCAN记录被健康检查误摘除域控清理机制误删集群对象记录对应监听组件SCAN Listener Local ListenerAG ListenerVNN运维复杂度中等DNS与集群配置分离偏高需要与AD域控联动这张表不算面面俱到但足够说明一个问题SCAN是把DNS当作“多副本入口的平衡器”而SQL Server AG是把DNS当作“当前主副本的指向器”。平衡器要求的是“多个答案随机返回”指向器要求的是“当且仅当正确的答案”。两者的设计目标不同所以在配置DNS时的侧重点也就不同。4.2 两者都会踩的通用DNS坑虽然服务器端的技术体系不同但这两类集群在DNS使用上有几个共性问题几乎是无差别出现的。第一个共性问题是DNS服务器自身的高可用。很多数据库团队习惯把DNS看成一个“绝对可靠”的基础设施但实际故障中DNS服务器宕机、DNS区域传输失败、转发器递归超时这些情况每年都会遇到几次。无论Oracle还是SQL Server只要DNS不可用集群健康本身不受影响但所有依赖域名访问的客户端都会瘫痪。你会看到一份看起来“团伙作案”的故障现象所有应用连接都失败但数据库服务器本机的sqlplus或者SSMS连接却正常——因为本机连接走的是localhost或127.0.0.1绕开了DNS。第二个共性问题是多层DNS结构下的解析顺序漂移。企业网络通常不止一跳DNS应用服务器指向本机DNS缓存或内部DNS内部DNS再向上级DNS转发。每一跳都可能引入缓存和超时。当你在上级DNS改了SCAN的记录或者SQL Server监听器的记录后下层DNS要等缓存过期才会同步。如果你只检查了“权威DNS里记录对不对”没有检查实际客户端解析出来的结果那等于在雷区里裸奔。第三个共性问题是运维的“无主之地”。我在两家客户那里都见过类似的情况网络团队认为数据库集群的事情应该由DBA负责DBA认为DNS区域管理是网络团队的地盘。结果SCAN记录添加滞后、TTL配置不合理、监听器DNS权限没授权这些问题就成了无人认领的野狗。要根治这个问题不是技术手段能解决的而是必须建立跨团队的“集群DNS变更清单”每次数据库集群变更时把DNS相关操作一并纳入变更评估。5. 故障排查与急救清单从现象反推DNS病灶5.1 判断Oracle SCAN解析是否正常的3条命令遇到SCAN相关的连接问题我习惯性地在应用服务器上依次执行下面几条命令可以快速定位问题出在哪一环。第一条用nslookup或dig看SCAN完整解析结果nslookup db-scan.example.com正常输出应该是多个IP地址并且多次执行时IP顺序发生变化。如果输出只有一个IP说明DNS里SCAN地址数量配置不足如果多次执行IP顺序完全一致轮询没有生效需要检查DNS服务器上的Round Robin设置Windows DNS默认开启Bind需在配置中确认。第二条检查SCAN监听器的注册与状态lsnrctl status scan_listener # 或通过grid用户执行 srvctl status scan srvctl config scan这一步能看到SCAN监听器当前运行在哪个节点、监听端口是否正常。如果SCAN监听器处于OFFLINE状态即使DNS解析再正常客户端也会被拒绝连接。第三条在应用服务器不是DBA本机测试真实客户端视角的连接tnsping db-scan.example.com:1521这里有一个容易踩坑的细节tnsping走的是Oracle Net的重试逻辑它本身会尝试多个SCAN地址结果比nslookup更能反映“客户端实际体验”。如果nslookup正常但tnsping报错就要重点关注SCAN监听器所在的节点与客户端之间的网络策略。如果nslookup都不正常直接找DNS管理员核对区域记录即可。5.2 SQL Server集群DNS问题的排查路径SQL Server集群的DNS排查相比Oracle多一些Windows特有的步骤。首先要确认集群本身是否健康因为很多“DNS问题”其实是集群状态不佳的外在表现。在任意集群节点上用管理员权限执行Get-ClusterNode Get-ClusterResource Get-ClusterNetwork重点看节点状态是否Online集群核心资源如Cluster Name、IP Address资源是否正常。如果这里已经出现Offline先解决集群问题再谈DNS。其次检查监听器和虚拟网络名称的注册地址Resolve-DnsName ag-listener.example.com对比当前主副本Primary Replica所在节点。如果解析出来的IP跟主副本节点IP不一致说明DNS记录没有随故障转移更新。可以进一步检查AD域控中对应的计算机对象是否允许安全更新。在ADUCActive Directory 用户和计算机里找到集群CNO对应的计算机账户打开属性里的“安全”选项卡确认允许更新DNS记录相关权限。最后如果解析结果正确但客户端连接仍失败那么要在客户端机器上清缓存并实测ipconfig /flushdns sqlcmd -S tcp:ag-listener.example.com,1433 -E如果这里能连上说明问题在应用层的连接字符串如果连不上说明监听器本身或SQL Server实例服务有问题与DNS无关。这个“从server端到client端逐层往上走”的思路能避免在错误层级浪费时间。5.3 三个生产环境的典型故障复盘故障一DNS健康检查误删SCAN记录。客户环境引入了一个商业DNS管理平台开启了“基于ICMP ping失败自动摘除记录”的功能。SCAN IP是浮动地址同一时刻可能只有一台节点的网卡持有该IP另外两台节点的网卡并没有配置SCAN IP但DNS管理平台却要求所有记录都能ping通才算健康于是隔三差五把“不健康”的SCAN记录自动删除导致客户端间歇性连接失败。复盘结论DNS健康检查不能对集群浮动地址用简单的ICMP探测要么关闭自动摘除要么针对集群地址设计专门的探测逻辑比如探测对应端口的SCAN监听器是否响应否则宁可让DNS“全量返回”也不要自作聪明地删除记录。故障二域控DNS回收策略误删AG监听器记录。某客户的Active Directory域控设置了“删除无关联的DNS记录”和“清理过期记录”的自动化任务而AG监听器创建后因为某些网络组策略的原因集群计算机账户没有正常完成动态注册。几天后域控清理任务把这个“看起来没人用”的记录删掉了。可用性组本身没有任何异常但客户端全部通过监听器名称连接结果从“部分失败”演变成“全部失败”。复盘结论Windows集群的虚拟网络名称和AG监听器一定要确认其DNS记录处于“允许安全更新”的状态而且域控的清理策略最好把这类记录加入豁免列表。故障三多子网AG的网络优先级与DNS解析不一致。某客户配置了跨机房的AG一个子网对应主中心另一个对应灾备中心。正常工况下所有客户端连接都走主中心IP但某次机房链路抖动触发了一次切换客户端切到灾备后连接质量明显下滑部分应用出现超时。后来检查发现监听器在多子网模式下对DNS返回顺序有依赖由于Windows DNS轮询导致偶尔先返回灾备IP客户端驱动在MultiSubnetFailover模式下会“同时发起所有IP的连接尝试”虽然最终能连上但连接建立时间被拉长。复盘结论跨机房的AG监听器配置应当评估是否启用DNS轮询必要时关闭特定区域记录的轮询让主中心优先返回。6. 从实战出发的DNS配置最佳实践6.1 Oracle SCAN与SQL Server集群的DNS配置清单把散落各处的经验汇总成一份可以照着做的配置清单我个人在评估数据库集群DNS健康度时基本就是按这份清单逐项检查。对于Oracle RAC SCAN环境为SCAN规划专属IP地址段不与节点VIP、管理IP混用节点数量3个以内时分配3个地址超过3个时可分配3到5个。在DNS区域中添加SCAN名称的多个A记录设置TTL为30到60秒确认Round Robin已启用。不启用GNS时确保SCAN记录变更流程纳入数据库变更工单变更后必须用nslookup多次验证解析顺序达到“随机化”效果。定期检查SCAN监听器与本地监听器的注册状态特别是在节点维护后使用srvctl status scan确认SCAN回到Online。对于SQL Server AG/FCI环境确认所有集群节点已加入同一AD域并且DNS服务器地址配置统一指向域控或公司内部DNS。创建AG监听器时优先使用静态IP如果有条件并对该静态IP在DNS中提前创建记录同时勾选“允许计算机账户更新DNS记录”。将集群CNO对象、监听器对象的DNS记录加入域控“安全动态更新”的范畴避免被清理策略误删。如果监听器跨子网连接字符串中务必包含MultiSubnetFailoverTrue如果使用只读路由则同时检查ApplicationIntentReadOnly和只读路由列表的正确性。定期执行Resolve-DnsName检查监听器地址是否与当前主副本一致并将这一项纳入每次故障转移后的验证脚本。6.2 TTL到底怎么设才算合理TTL是最让人纠结的参数之一。设太短DNS压力大设太长故障切换时客户端反应慢。我给的建议是分角色对待。SCAN记录的TTL设置在30到60秒。这个区间内SCAN负载均衡的“新鲜度”可以接受同时DNS服务器的查询压力不会陡增。如果集群节点变更频繁可以用30秒如果变更少、追求稳定60秒更合适。SQL Server AG监听器的TTL可以设置得更保守一些甚至15到30秒。因为AG本身故障转移之后客户端依赖DNS快速指向新主副本TTL太长会让已经断连的客户端白白浪费重复连接的时间。但也不要设成0因为0会带来和SCAN一样“全部解析压力倾泻到DNS”的问题。唯一需要TTL0的场景可能是你正在做集群的割接演练需要所有客户端立刻看到新解析结果演练完以后赶紧改回正常TTL。这个操作属于“特殊时期特事特办”不建议作为长期配置。6.3 构建“DNS就绪度”自检脚本验证集群可用性与其每次靠人肉排查不如把常见检查项固化到脚本里。我自己在交付数据库集群时会提前写一个简单的Shell或PowerShell脚本在集群节点上跑一遍输出“DNS就绪度”报告。下面给出一个PowerShell SQL Server场景的简化版思路# 检查AG监听器解析是否指向主副本 $listenerName ag-listener.example.com $dnsResult Resolve-DnsName -Name $listenerName -Type A $primaryReplica Get-Content \\cluster\share\primary.txt if ($dnsResult.IPAddress -contains $primaryReplica) { Write-Host OK - DNS解析包含主副本地址 } else { Write-Host WARN - DNS解析与主副本不一致 }当然这个脚本在真实交付中会复杂得多核心思路就是三件事解析结果是否符合预期、判断过程是否与权威DNS一致、结论是否反映“作为一个客户端”的真实访问体验。其中最后一点我强调几次都不为过——大量的所谓“DNS故障”其实是DBA只在服务器本机验证了解析忽略了应用服务器的视角。任何脚本无论多完美都不如让团队里不同角色的人在各自网络视角下同时跑一次解析来得直观。6.4 关于DNS团队与DBA团队的协作边界最后讲一个跟工具无关的心得。DNS方案无论设计得多完善最终还是要靠人来维护。我在实际项目中见过太多“跨团队协作变成互相甩锅”的局面。要打破这个僵局我个人的体会是数据库集群所属的团队应当主动把DNS变更当作集群变更的一部分来管理。不要觉得“这是网络团队的事”毕竟SCAN监听器连不上、AG监听器切不动最终背锅的还是数据库侧。可以把需要网络团队配合的操作提前列成标准变更模板例如“新增SCAN记录”“调整SCAN记录TTL”“删除过期SCAN记录”“AG监听器DNS授权”“域控DNS清理豁免”等每次提起数据库集群变更需求时附带一份明确的DNS需求和验收标准。这样网络团队执行时不用猜数据库团队验收时有依据。合作顺畅的环境里往往只需要一个共享清单就能解决90%的沟通问题。就我个人来说DNS这类基础设施管得越细数据库集群在真正出故障的时候就越稳。它不像SQL调优那样能带来立竿见影的性能提升也不像存储双活那样会给领导层带来吹牛的素材但恰恰是这种“地基中的地基”决定了你在凌晨三点被电话叫醒时是花十分钟解决一个解析问题还是花三个小时在一堆日志里找一条被删掉的A记录。下次做集群变更时顺手把DNS检查也做进去你会感谢自己这个习惯的。