★ FEATURED ARTICLE 1. 为什么RAC环境的IPV6改造不能照搬单机思路RACReal Application Clusters这套架构单机数据库改IPV6和它完全不是一个量级的事。单机你只要把网卡地址、监听、客户端连接串这三样对齐基本就能跑起来RAC不一样它多了一层集群心跳和节点间私有通信任何一个地址族的变动都会牵动CRSCluster Ready Services的整套寻址逻辑。我见过不少团队在单机环境把IPV6跑通了信心满满地往RAC上套结果集群起不来、节点互相看不见、VIP漂移失败排查一圈才发现是私有网络那一段没跟着改。先把结论摆前面RAC的IPV6改造核心难点不在能不能配IPV6地址而在集群各层组件对IPV6的支持边界和公私网地址族的混搭策略。你得先搞清楚哪些网络必须统一地址族、哪些可以混跑、哪些组件压根不支持IPV6再动手。盲目全量切换轻则集群重启失败重则节点被踢出集群恢复起来相当折腾。这篇文章面向的是已经有一定RAC运维基础、正在或即将做IPV6改造的DBA和系统工程师。我会从改造前的评估、公私网的地址族规划、监听与VIP的处理、客户端连接串的调整一直到改造后的验证和常见坑按实际动手的顺序讲清楚。中间涉及参数和配置的地方我会把为什么这么设讲透而不是甩一堆命令让你自己猜。需要提前说明的是不同版本的集群件对IPV6的支持程度差异很大早期版本对IPV6的支持是残缺的某些组件甚至明确不支持。所以改造的第一步永远是确认你的版本能力边界这一点我在第二节会展开。另外本文涉及的地址、主机名、实例名一律用示意值你实际环境里要替换成自己的规划。2. 动手前必须确认的版本能力与组件支持边界改造RAC的IPV6最忌讳的就是先改了再说。我踩过的最深的坑就是在一个对IPV6支持不完整的集群版本上强行切换公网地址族结果监听起来了但集群资源状态一直异常最后只能回滚。所以这一节先把评估做扎实。2.1 集群件版本对IPV6的支持差异不同大版本的集群件对IPV6的支持是分阶段演进的。早期版本基本只支持IPV4IPV6要么完全不认要么只在极有限的场景下能用中期版本开始支持IPV6但对公私网混搭、VIP的IPV6地址支持有诸多限制较新的版本才逐步做到公私网都能跑IPV6、VIP也支持IPV6地址。你在评估阶段要确认三件事第一当前集群件版本是否支持IPV6公网第二是否支持IPV6的VIP这点很关键很多版本公网能跑IPV6但VIP不行第三私有网络心跳网是否支持IPV6。这三项能力决定了你的改造是全量切换还是公私网混搭。我一般会建议先在测试环境用crsctl query crs activeversion确认集群活动版本再对照官方文档的支持矩阵逐项核对。别嫌麻烦这一步省下来的时间后面排查故障时十倍还回去。2.2 哪些组件是IPV6改造的硬骨头RAC里对地址族敏感的组件主要有这么几块我按改造难度从高到低排一下组件对IPV6的敏感度改造注意点私有网络心跳高地址族切换影响节点间通信需全网统一VIP资源高部分版本不支持IPV6 VIP需重点确认SCAN监听中高SCAN的IPV6解析与客户端匹配要一致本地监听中相对独立可单独调整客户端连接串中地址族写法与解析顺序影响连接私有网络是硬骨头里的硬骨头。RAC节点之间靠私有网络做心跳和缓存融合Cache Fusion这块通信对延迟和稳定性极其敏感。如果公私网地址族不一致或者私有网内部混用地址族集群件在寻址时可能出现解析歧义表现为节点间ping得通但集群资源状态异常。我的经验是私有网络要么全IPV4、要么全IPV6不要在一个私有网里混地址族这是最稳妥的做法。VIP这块要特别提醒。VIP的作用是客户端连接失败时能快速漂移到另一个节点它的地址族必须和公网一致否则漂移逻辑会出问题。如果你的版本不支持IPV6 VIP那就只能让公网保持IPV4、或者接受VIP功能受限这个取舍要在规划阶段就定下来别改到一半发现VIP起不来。2.3 用最小化验证摸清环境底细评估阶段我习惯做一个最小化验证在测试环境里先只改一个节点的公网地址族观察集群资源状态、监听注册、节点间通信是否正常确认没问题再推进到全量。这个单点试探的做法能帮你快速暴露版本层面的兼容性问题而不至于一上来就全量切换导致大面积故障。具体操作上可以先在测试库上把某个节点的公网网卡加一个IPV6地址保留原IPV4地址然后观察crsctl stat res -t里各资源的状态变化重点看网络资源ora.net1.network和VIP资源有没有异常。如果加地址后集群就开始报网络资源异常那基本可以判定这个版本对IPV6公网的支持有问题得换思路。3. 公私网地址族的规划策略统一还是混搭评估做完接下来是规划。这一步的决策直接决定后面所有配置的走向我把它单独拎出来讲因为太多人在这里拍脑袋。3.1 三种可选方案及其适用场景RAC的IPV6改造本质上是在公私网两个维度上做地址族选择组合下来有三种主流方案方案一公私网全IPV6。最彻底也最考验版本支持度。适合新部署环境或者版本支持完整、且上下游客户端、中间件、监控都已具备IPV6能力的场景。优点是架构干净、没有地址族转换的开销缺点是对生态要求高任何一个环节不支持IPV6都会卡住。方案二公网IPV6、私网IPV4。这是我见得最多的一种折中方案。公网面向客户端改成IPV6满足对外服务要求私有网络保持IPV4因为心跳网通常只在集群内部改不改对外部无感知而私有网改IPV6的风险和收益不成正比。这个方案的关键是确认集群件允许公私网地址族不一致——大部分中后期版本是允许的但早期版本可能有限制。方案三公网双栈、私网IPV4。公网同时保留IPV4和IPV6地址客户端按需连接。适合过渡期既能满足IPV6接入要求又不影响还在用IPV4的老客户端。缺点是配置复杂度上升监听要同时注册两个地址族连接串也要考虑解析顺序。我的建议是如果没有强制要求私有网也上IPV6优先选方案二或方案三。私有网改IPV6的收益很低风险却不小除非你有明确的合规或架构要求否则没必要动它。3.2 地址族混搭时的解析顺序陷阱选了混搭方案就要面对一个隐蔽的坑主机名解析顺序。当一台主机同时有IPV4和IPV6地址、且主机名能解析到两个地址族时集群件和客户端到底先用哪个取决于系统的解析配置比如/etc/hosts的顺序、名称服务的优先级、以及系统的地址族偏好设置。我遇到过这样的情况公网配了双栈/etc/hosts里IPV4写在前面结果集群件优先用IPV4注册监听客户端却用IPV6去连连不上还以为是防火墙问题排查了半天才发现是解析顺序不一致。解决办法是让集群各节点、以及客户端的解析行为保持一致——要么统一优先IPV6要么统一优先IPV4别让不同节点各用各的。具体到配置上/etc/hosts里同一主机名的多条记录顺序要统一如果用了名称服务要确认返回顺序在各节点一致。这个细节不起眼但它是混搭方案里最容易翻车的地方之一。3.3 私有网络改造的额外约束如果你确实要动私有网有几个额外约束得记住。私有网的网卡通常不止一块冗余心跳改的时候要保证所有私有网卡地址族一致不能一块IPV4一块IPV6。另外私有网的子网规划要重新核对IPV6的地址段划分和IPV4逻辑不同别把心跳地址和公网地址规划到同一个段里造成混淆。还有一点私有网改地址族后集群的节点间通信要重新验证。我一般会用集群自带的网络检查工具比如cluvfy类的组件跑一遍节点连通性检查确认所有私有网卡之间都能正常通信再继续后面的步骤。这个检查能提前发现地址配置错误比等集群起不来再排查高效得多。4. 监听、VIP与SCAN的IPV6落地配置规划和评估都到位了进入实际配置环节。这一节按本地监听→VIP→SCAN监听的顺序讲因为它们的依赖关系是从下往上的。4.1 本地监听的地址族调整本地监听LISTENER负责接收客户端到本实例的连接。改它的地址族核心是让监听在正确的地址上注册。如果公网改IPV6监听就要监听IPV6地址如果双栈监听要同时覆盖两个地址族。配置上监听的主机名解析结果决定了它绑定的地址。所以改监听之前先确保主机名能正确解析到目标地址族。我通常的做法是先在/etc/hosts里把主机名对应的IPV6地址补上双栈场景保留IPV4然后用监听控制工具重建或重配监听让它按新的解析结果注册。这里有个实操心得改监听不要直接改配置文件再重启而是用监听控制工具重新配置。直接改配置文件容易漏掉集群注册信息导致监听起来了但集群资源状态不对。用工具重配集群会自动同步注册信息省心很多。改完之后用监听状态查询命令确认监听确实在IPV6地址上监听并且服务注册正常。如果看到监听状态里服务是READY而不是BLOCKED说明注册没问题。4.2 VIP的IPV6配置与漂移验证VIP是RAC里最容易出问题的部分。前面说过先确认版本支持IPV6 VIP。支持的话VIP的配置要跟着公网地址族走。VIP的配置要点在于VIP地址必须和公网在同一网段IPV6里叫同一前缀否则漂移和路由会出问题。配置时通过集群资源管理工具修改VIP资源的地址改完要验证两件事一是VIP能在节点间正常漂移二是客户端通过VIP能连上。漂移验证我一般会手动触发一次VIP切换把VIP从一个节点切到另一个节点观察切换是否平滑、切换后客户端连接是否正常。这一步别省VIP漂移失败是RAC改造后最常见的故障之一提前验证能避免上线后才发现。如果版本不支持IPV6 VIP那就得接受公网保持IPV4、或者用其他方式比如负载均衡层做地址转换来满足IPV6接入需求。这个取舍在规划阶段就该定这里只是执行。4.3 SCAN监听的IPV6适配SCANSingle Client Access Name是客户端连接的统一入口它背后是SCAN监听。SCAN的IPV6适配关键是SCAN名称要能解析到IPV6地址且SCAN监听要在这些地址上正常注册。SCAN通常对应多个IP三个是常见配置改IPV6时这些IP都要是IPV6地址且解析要一致。配置上先更新SCAN名称的解析记录让它指向IPV6地址然后重配SCAN监听确认它在所有SCAN IP上都能正常监听。这里有个容易忽略的点SCAN的IPV6地址和客户端连接串里的地址族要匹配。如果SCAN只配了IPV6客户端却用IPV4去解析SCAN名称就会解析失败或连到错误地址。所以SCAN改造要和客户端改造协同推进不能各改各的。5. 客户端连接串与中间件的适配细节数据库端改完客户端连不上等于白改。这一节讲客户端侧要跟着做的调整以及中间件层的注意事项。5.1 连接串里IPV6地址的正确写法IPV6地址在连接串里的写法和IPV4不同最直观的区别是IPV6地址里带冒号而连接串本身也用冒号分隔字段所以IPV6地址通常要用方括号包起来避免解析歧义。比如连接串里指定地址时IPV6地址要写成带方括号的形式。除了写法还要注意连接串里用的是主机名还是IP。用主机名的话解析结果决定实际连哪个地址族用IP的话直接指定地址族。我一般建议用主机名或SCAN名称让解析层去处理地址族选择这样客户端配置更灵活也便于后续调整。如果客户端同时有IPV4和IPV6能力连接串的解析顺序会影响它先尝试哪个地址族。这个顺序要和数据库端的监听注册保持一致否则可能出现客户端连IPV6、数据库只监听IPV4的错配。5.2 中间件连接池的地址族感知应用通过中间件连接池、应用服务器连数据库时中间件对地址族的处理也要确认。有些连接池组件在建立连接时会缓存解析结果如果数据库端地址族变了但连接池缓存没刷新就会出现连到旧地址的情况。改造后我一般会建议重启中间件或刷新连接池确保它重新解析地址。另外连接池的健康检查配置也要确认能覆盖新的地址族别让健康检查还用旧地址探测导致误判数据库不可用。5.3 防火墙与访问控制的同步调整地址族变了防火墙规则和访问控制列表也得跟着改。IPV6的防火墙规则和IPV4是分开管理的很多人改完数据库忘了改防火墙结果连接被拦还以为是数据库问题。改造清单里要明确列出公网IPV6地址段的放行规则、SCAN IPV6地址的放行、VIP IPV6地址的放行以及客户端所在网段到数据库的IPV6访问策略。这些规则要在改造前就准备好改造时同步生效避免出现数据库改好了但连不上的尴尬。6. 改造后的验证链路与回滚预案改完不等于成功验证和回滚预案是收尾的重头戏。我见过太多改造看起来成功了结果上线后各种间歇性故障。6.1 分层验证从集群到客户端逐级确认验证要分层做从底层往上逐级确认任何一层不过关都不能往下走集群层确认所有节点都在集群里、资源状态全部正常crsctl stat res -t全绿、节点间心跳正常。网络层确认公私网地址族符合规划、节点间能互相通信、VIP能正常漂移。监听层确认本地监听和SCAN监听都在目标地址族上监听、服务注册为READY。连接层用客户端实际连接串测试确认能连上、能执行查询。应用层通过中间件跑一轮业务验证确认连接池、健康检查都正常。这个顺序的逻辑是底层不通上层验证没有意义。我一般会把每一层的验证命令和预期结果列成清单逐项打勾避免遗漏。6.2 回滚预案要提前演练改造前必须准备好回滚预案而且要在测试环境演练过。回滚的核心是把地址族改回原状解析记录改回、监听重配回IPV4、VIP地址改回、防火墙规则恢复。回滚的难点在于集群状态。如果改造过程中集群已经处于异常状态回滚时可能要先修复集群再改地址。所以回滚预案里要包含集群异常时的恢复步骤比如如何强制清理异常资源、如何重新配置集群网络。我的经验是改造窗口要留足回滚时间别把窗口卡得太死。改造本身可能半小时但万一要回滚恢复集群状态可能要一两个小时。窗口留够心里不慌。6.3 改造后持续观察的指标改造上线后别急着收工要持续观察一段时间。重点看几个指标节点间心跳延迟有没有异常波动、VIP漂移是否正常、客户端连接成功率、监听日志里有没有地址解析相关的报错。IPV6改造后的一些问题不是立刻暴露的可能运行几天后在某些特定场景下才出现比如某个节点重启后地址注册异常。所以改造后的一周内每天检查一遍集群资源和监听状态是比较稳妥的做法。7. 几个真实踩过的坑和应对经验最后分享几个我在RAC的IPV6改造里实际踩过的坑都是文档里不会写、但实际会遇到的。坑一改完公网忘了改私有网的解析。有一次公网改IPV6后/etc/hosts里私有网的主机名解析还指向IPV4结果集群启动时私有网寻址混乱节点起不来。教训是改解析记录要全局检查公私网的主机名解析都要过一遍。坑二VIP漂移测试在单节点上做没测跨节点。单节点上VIP能起来就以为没问题结果跨节点漂移时失败。原因是VIP的IPV6地址前缀配置有误跨节点路由不通。教训是VIP验证一定要做跨节点漂移别只测本节点。坑三客户端连接池缓存了旧解析结果。数据库端改完应用连不上排查半天发现是连接池缓存了IPV4的解析结果。重启连接池后恢复正常。教训是改造后主动刷新中间件缓存别等它自己过期。坑四防火墙规则只改了入站没改出站。IPV6环境下出站规则也要确认有些环境出站默认拒绝导致数据库主动发起的连接比如到其他服务失败。教训是防火墙规则入站出站都要过一遍。这几个坑的共同点是都不是技术难题而是以为改全了其实漏了。所以改造清单要做得细每一项都打勾确认比凭记忆靠谱得多。另外补充一个心得改造过程中多用集群自带的检查工具做连通性验证别只靠ping。ping通不代表集群通信正常集群有自己的网络检查逻辑用它来验证更准。改造这种牵一发动全身的事宁可多验证几遍也别图快。
阅读完成 · 觉得有帮助？
