在开始讲CSS之前先同步一个背景这是“RAC管理”系列里关于集群软件的部分接前面两篇把RAC整体架构和集群件安装梳理完之后今天专门把集群软件里的CSS拎出来聊透。RAC、集群软件、CSS这三个词放在一起很多刚接触Oracle数据库集群的同行第一反应是“CSS不是网页样式表吗”——在RAC的世界里CSS全称是Cluster Synchronization Services集群同步服务它既不负责页面样式也不做任何渲染而是集群所有节点之间相互确认“谁还活着、谁有资格继续待在集群里”的那根定海神针。这篇内容适合两类人一类是刚接手RAC、对集群进程还停留在“会启动、会看STATUS”阶段的运维工程师另一类是已经操作过一段时间、但遇到节点被驱逐或脑裂时只能靠重启解决问题的朋友——我会把CSS的原理、日常操作、故障排查串起来讲尽量把那些文档里不会直说的经验补上。1. CSS在集群软件栈里的定位它不是“样式表”而是集群的“神经系统”1.1 先认清RAC集群软件里那几个常驻进程要理解CSS必须先弄清楚RAC的集群软件整体上由哪些角色组成。很多人习惯直接说“集群软件就是Oracle Grid InfrastructureGI”这个说法在11g之后的版本里基本成立GI栈里最核心的常驻进程有下面几个进程中文俗称主要职责ohasd集群守护进程系统启动后第一个起来的集群进程负责拉起其他关键进程相当于“开机引导员”cssdagent / cssdmonitorCSS代理/监控进程监控ocssd的健康状态发现问题时执行本地节点重启或驱逐动作ocssdCSS主进程维护节点成员关系、心跳检测、仲裁投票是CSS服务的真正执行者evmd事件进程负责集群内节点间事件消息的发布与订阅crsd资源进程管理VIP、Listener、数据库实例、ASM等资源的启动/停止/故障恢复从这张表能看出CSS并不代表某一个单独进程而是ocssd加上cssdagent、cssdmonitor这一整套机制的总称。这组进程在GI栈里的层级很低低到什么程度呢ohasd起来之后第一优先级要拉起来的就是cssd家族因为后面的evmd、crsd、ASM实例、数据库实例全都需要CSS先给出“节点是否具备集群成员资格”的结论。打个比方CRS管的是“基础设施里哪些服务该上班”EVM管的是“通知大家出了什么事”而CSS管的是“什么样的人才有资格站在这间会议室里”。如果CSS不给资格后面所有服务都无从谈起。1.2 CSS三个核心职责成员资格、磁盘判读、仲裁信号CSS具体忙些什么总结下来是三件大事。第一件维护节点成员资格表。每个节点启动后ocssd会通过私网交换心跳信息把“我上线了”“我还活着”的消息同步给其他节点这个成员表就是集群决定“谁是自家人”的依据。数据库实例启动之前也要向CSS确认当前节点身份只有拿到合法成员身份实例才会真正启动数据库相关进程。第二件仲裁谁有权访问共享存储。RAC所有节点都共享同一套数据文件、OCR、表决文件但共享不代表可以乱写。CSS负责保证在脑裂或者网络异常时持有合法票数的那一组节点才能继续访问OCR和表决文件另一组要么被驱逐、要么被本地重启防止两个节点同时对同一份数据文件写入造成永久损坏。这个机制确保了RAC最核心的红线同一时刻只有一群“最合法”的节点能操作共享存储。第三件对外提供仲裁信号。ASM实例和数据库实例启动、运行的过程中都需要从CSS拿到“当前集群状态稳定、可用节点数足够”的信号。如果CSS认为集群不安全ASM实例会拒绝挂载磁盘组数据库实例也会报出一些让人摸不着头脑的ORA错误。这也是为什么很多RAC故障表面上报错在数据库层真正病灶却在CSS层。理解CSS时最忌讳的就是把它单纯当成“一个心跳检测进程”。心跳只是它的手段它的真正价值是在任何异常情况下都能让集群快速收敛到一个合法的、唯一的状态。这个定位决定了CSS出问题时整个集群宁可重启节点、宁可短暂停服务也不能让数据完整性受损——这是RAC设计里最根本的取舍。2. 心跳、脑裂、投票CSS到底是怎么防止集群“精神分裂”的2.1 双心跳机制网络心跳和磁盘心跳各有分工CSS判定节点是否存活靠的不只是一条通道而是两条网络心跳和磁盘心跳。网络心跳走私网默认大概每秒钟发送一次报文用来确认其他节点的操作系统和网络协议栈是否正常响应。这一层反应最快一两个心跳周期收不到回复ocssd就开始怀疑对方出问题了。但网络心跳有个盲区它只能证明“另一个节点的心跳进程有没有回话”无法证明“这个节点是否已经失控、会不会去破坏共享数据”所以CSS还需要第二层保障。磁盘心跳走的是表决文件。每个存活的节点都会周期性地往表决文件里写入自己的状态信息同时读取其他节点的状态。即使两台服务器之间私网完全断了只要它们还能同时访问表决文件CSS就能通过磁盘心跳判断“谁还在场上”。这个设计非常关键私网断了不等于集群一定要脑裂只要共享存储链路还通节点之间依然可以凭磁盘状态维持一致性。两套心跳一起工作就引出了RAC界非常经典的故障场景——私网断开、存储正常时集群会尽量维持原有成员不踢人等待网络恢复但如果私网断开的同时某个节点又无法访问表决文件那这个节点就会很快被判定为“已经脱离集群”触发驱逐或重启流程。2.2 脑裂为什么必须“你死我活”集群最怕的状态不是某个节点挂了而是两个节点都觉得自己才是合法主体。想象一个双节点集群私网突然断开节点A和节点B都收不到对方心跳此时如果没有仲裁机制两边都会认为“我才是唯一活着的节点”然后同时尝试往共享存储上写数据——这就是脑裂。CSS应对脑裂的办法非常直接投票少数服从多数。表决文件在传统设计里由奇数个“投票磁盘”组成每个投票磁盘代表一票集群中每个节点平时都保持对全部表决文件的写入能力。脑裂发生时能访问到表决文件的节点会统计自己这边能访问的票数票数不过半的一组会被强制出局。三节点集群最常见的结局是两个节点能访问两个表决文件、组成“2票联盟”保留集群资格剩下那个节点即使还活着也会被fence栅栏隔离轻则触发本地重启重则直接关机目的就是杜绝它继续操作共享资源。这也是为什么很多老DBA常说“投票磁盘一定要配置奇数个”。2个或4个表决文件在均分时会出现票数相等谁也没法说服谁反而让局面僵住。奇数个核心里2对1、3对1、3对2都能快速分出胜负让集群迅速收敛到一个合法的赢家。到了12c之后的版本表决文件被整合进ASM磁盘组底层逻辑依然是“总票数必须过半才算赢”只是增加了一些如quorum磁盘、failure group的新玩法以适应更多跨机房部署场景但核心仲裁思想完全没有变。2.3 CSS重配置每个节点加入或离开都会触发的一场“重新组阁”当某个节点启动时想加入集群或者某个节点被判定离开时CSS并不会简单地说“好你走吧”或“你进来吧”。它会启动一次全局重配置流程把所有存活节点召集起来重新确认一遍成员列表、交换各自状态、同步配置版本整个过程日志里能看到“Reconfiguration started”和“Reconfiguration completed”两条关键记录。重配置期间所有涉及成员判断的操作都会暂停数据访问虽然不是完全停顿但新增资源调度会放缓。如果集群环境不稳定比如某节点反复崩溃、反复尝试加入就会触发连续重配置日志里出现一个又一个“reconfig”循环这对集群的伤害比单个节点宕机更严重因为每个节点都会跟着做一遍状态同步整个集群的性能和稳定性都会被拖垮。理解重配置机制对后期运维有三层价值第一看到节点加入或退出时不必惊慌关键是看重配置是否在预期时间内完成第二正常维护中增删节点必须选在业务低峰因为重配置过程本身有开销第三如果日志里频繁出现重配置一定是底层节点状态或网络在反复抖动这时候追根因比反复重启集群重要得多。3. 日常运维中与CSS打交道的正手动作3.1 检查CSS状态的三板斧三种命令对应三种视角接手一台RAC第一步不是去查数据库状态而是先确认CSS这个“神经中枢”是否健康。平时我基本上是三条命令打天下。# 在任一节点执行查看整个集群所有节点的CRS状态 crsctl check cluster -all # 单独检查CSS服务在当前节点的状态 crsctl check css # 查看集群初始化资源的运行情况重点关注cssd资源 crsctl status resource -t -init第一条命令返回“CRS-1009: The cluster is running in exclusive mode”之类的信息说明集群级状态正常注意“exclusive mode”在12c之后是正常现象不用当成异常。第二条命令更聚焦如果返回“CSS is active on all of the nodes”说明CSS层没问题如果某个节点通信异常它会直接列出不可达的节点名。第三条命令能看到cssd、cssdagent、cssdmonitor、evmd、crsd这一组初始化资源的当前状态正常情况下应该全是“ONLINE”。除了上述三个动作还有一条必须记住crsctl query css votedisk这条命令用于查看当前集群使用的表决文件位置、名称和状态。正常情况下每一行都是“ONLINE”如果出现“OFFLINE”或状态异常说明表决文件读写有问题这是CSS故障里最危险的一类后面场景三会详细讲。3.2 日志所在“病历本”都写在哪个目录CSS排障离不开日志密码就在GI_HOME的log目录下。以11gR2之后的典型布局为例日志主要在这几个位置# CSS主日志包含心跳、重配置、投票、驱逐等关键记录 $GRID_HOME/log/节点名/cssd/ocssd.log # 集群告警日志记录集群级的各类事件汇总 $GRID_HOME/log/节点名/alert节点名.log # CRS日志资源级别的启停与故障记录 $GRID_HOME/log/节点名/crsd/crsd.log # 集群命令执行日志适合查看命令层面的报错 $GRID_HOME/log/节点名/crsd/clusterware.log实际排障时我的习惯是先看alert日志确定“大概哪个时间段出问题”再进ocssd.log里找细节。ocssd.log里真正需要关注的关键词不算多重点抓这几个reconfiguration、vote、fence、kill、timeout、inaccessible。比如搜到“Reconfiguration completed”前后跟着某节点被标记为not reachable那就基本能锁定问题发生在网络或该节点自身。还有一个细节很容易踩坑很多环境里$GRID_HOME和$ORACLE_HOME不是同一个路径。CSS属于GI栈日志一定写在上海GI的log目录下不是数据库软件目录下。我刚带人的时候经常看到新手在$ORACLE_HOME/log里翻半天找不到ocssd.log实际是因为他看的是数据库实例的目录。先确认echo $ORACLE_HOME里的路径是不是GI的安装路径再去找log目录能省一大堆时间。3.3 想停CSS别只盯着它要停就停整个CRS栈CSS在GI栈里被设计成“受保护进程”日常管理中几乎不存在单独启停CSS的场景。如果你执行crsctl stop crs相当于停掉当前节点整个集群软件栈CSS、EVM、CRS会按顺序依次停止反过来crsctl start crs则会先起ohasd再由ohasd启动CSS然后才是EVM和CRS。为什么不要尝试单独kill ocssd进程因为CSS是集群的“生死判定者”它挂了之后其他节点会因为收不到心跳而认为该节点失联直接触发驱逐。结果就是你明明只想重启CSS最后却变成节点被集群强制重启还可能连带影响OCR和表决文件的访问。真要维护某个节点正手操作是下面这个次序# 在目标节点上先关应用层 srvctl stop database -d 数据库名 srvctl stop asm -n 节点名 # 再停整个集群软件栈 crsctl stop crs # 维护完成后重新启动 crsctl start crs # 确认状态 crsctl check cluster -all如果是整个集群计划内停机还有一种更简洁的姿态在任一节点上执行crsctl stop cluster -all所有节点会一起安静下来。需要强调的一点是能不停就别停能滚动停就滚动停。虽然很多时候我们改OS参数、换网卡不得不重启节点但每次CRS重启都是一次重新建立成员关系的过程停了再起如果底层的网络心跳或者存储链路本来就有隐患重启过程会把这些隐患加倍放大。4. 真实排障CSS相关三个典型场景与完整排查链路4.1 场景一节点被CSS判定失联反复重启或直接fence现象描述某天监控报警集群里的节点2状态异常操作系统层面显示服务器不断重启或者节点2没有重启但数据库日志里突然出现大量错误应用端彻底连不上该节点上的服务。此时另一个节点1上看crsctl check cluster -all显示节点2 unreachable。完整排查链路 第一步先看时间线。登录节点1打开集群告警日志和ocssd.log找到节点2出问题前最后几条记录看是“Network heartbeat lost”还是“Disk heartbeat lost”。这一步直接决定了后面排查方向。 第二步如果是网络心跳丢失重点看私网是否抖动。用ifconfig或ip link查看私网网卡状态看有没有大量丢包、错包、DOWN/UP切换记录再看交换机和网卡日志有没有CRC错误或协商速率变化。很多时候是私网网线松动、光模块劣化这类硬件问题。 第三步如果是磁盘心跳丢失重点看共享存储路径。检查节点访问表决文件对应磁盘的IO状态iostat -x 1看看有没有长时间await飙高同时确认多路径软件状态正常别是存储侧链路瞬断导致表决文件访问超时。 第四步确认根因后修复恢复网络或存储。再手动把被强制下线的节点的CRS服务拉起来crsctl start crs然后等它重新加入集群观察ocssd.log中是否出现重配置完成记录。这条链路里我最想强调的一点是不要一看到节点重启就急着把它加回去。节点重启是CSS的自我保护真正的问题是为什么触发保护。不找到根因就反复加节点只会让集群陷入“加进来—又掉线—又加进来”的循环重配置风暴比单个节点宕机更可怕。4.2 场景二ocssd.log里出现大量“IPC send timeout”或“heartbeat timeout”现象描述集群当前没有节点掉线业务也还跑着但日志里不断刷IPC send timeout、heartbeat timeout之类的告警节点间通信时快时慢偶尔还会出现资源组在节点间飘移。完整排查链路 第一步确认私网延迟和丢包。在节点间用ping测延迟但一定不要只ping几个包就下结论。至少连续ping 1000个包统计丢包率和最大延迟CSS要求的心跳周期非常短任何超过几十毫秒的延迟都可能被判定为危险信号。 第二步检查私网是否被误用。常见问题是有人把备份流量、日志同步流量、甚至SSH管理流量都走私有网络高峰时段把私网带宽打满。RAC私网是集群的生命线备份、OGG同步这类大流量必须走独立网络或服务网络。 第三步查看crsctl get css misscount这类参数但我要明确说一句这些参数在11gR2之后大多已经不用手工调整CSS会自适应心跳超时。老经验里改misscount的操作在新版本里不仅没用还可能让集群在真正脑裂时反应迟钝。真正需要做的是让私网负载回归正常。 第四步如果网络负载正常但问题依旧考虑私网网关配置或路由问题确认私网网段的连通性没有经过不必要的路由跳转如果配置了多个私网网卡还要检查它们是否属于同一子网或存在路由冲突。排这个故障时最颠覆我认知的一次经历是问题出在节点上某块网卡开启了节能模式低负载时一切正常高峰时网卡自动降速心跳就开始超时。后来在系统层把网卡节能彻底关闭问题才消失。这类问题用常规网络排查很难一眼发现必须结合日志时间点与网卡状态联动分析。4.3 场景三表决文件异常导致的CSS仲裁失败现象描述执行crsctl query css votedisk时某个votedisk状态不是ONLINEocssd.log中反复出现“Voting disk(s) inaccessible”或“Lost access to voting disk”的记录。严重时集群所有节点都不敢继续维持成员资格先后重启服务全停。完整排查链路 第一步用crsctl query css votedisk确认哪些表决文件脱机。这里的输出会列出磁盘路径、状态、票数先记录完整信息再动手。 第二步检查存储链路。如果表决文件放在ASM磁盘组里用asmcmd lsdg看磁盘组状态确认是否某块ASM磁盘故障导致ASM降级如果表决文件还放在裸设备或集群文件系统上直接用dd读测试磁盘设备看有没有IO error。 第三步检查权限与设备状态。确认GI运行用户对该磁盘设备有正确的读写权限有些环境重启后设备的属主或权限会变化导致CSS无法打开表决文件。同时确认多路径设备状态multipath -ll看看路径是否只剩一条Active/Active状态是否正常。 第四步修复表决文件。ASM磁盘组内的表决文件损坏时通常做法是从正常节点执行crsctl replace votedisk 复制的磁盘组名让OCR的自动备份能力重新生成表决文件。这个命令是有风险的执行前一定确认备份和磁盘组冗余度都在线操作完成后再次用crsctl query css votedisk验证全部状态变为ONLINE。这个场景是CSS故障里危险系数最高的因为表决文件是仲裁的“选票底稿”一旦损坏整个集群连合法的老大都选不出来。之前见过有同事想“省事”直接把故障磁盘从ASM里踢出去重建结果连OCR也一起损坏最后只能靠整库恢复兜底。这种操作绝对不可以贪图快诊断做得越细后面的恢复越稳。4.4 三条链路背后的共同排查思维把三个场景串起来看CSS排障其实就三句话先分网络还是存储再看日志时间线最后才动手改配置。我见过太多排查一上来就重启集群、重新配置votedisk的例子最后都把小问题搞成大事故。只要CSS日志还在它就把当时发生了什么写得明明白白——问题是你看没看、会不会看。5. 版本演进与维护边界CSS在不同版本里的角色转换5.1 从10g到19cCSS的形态变了但本质没变老DBA应该还记得10g时代集群软件叫CRSCSS服务还是单独的ocssd进程表决文件是几个裸设备每个节点上还要格外小心地维护设备权限。到了11gR2GI把OCR和表决文件整合进ASM磁盘组CSS的仲裁动作不再直接对着裸设备而是通过ASM来读写表决信息同时增加了cssdagent和cssdmonitor两个守护进程让ocssd本身也处于被监控状态整个保护链更完整。12c之后CSS继续演进支持在扩展集群或同质集群中加入quorum磁盘、failure group的概念仲裁算法可以更灵活地适应跨机房、跨地域的部署。到了19c我们日常看到的“exclusive mode”已经成为常态GI在单节点环境下也默认以集群方式运行CSS依然是最底层最核心的那根弦。这些版本变化容易让人产生一个错觉既然表决文件都进了ASMCSS是不是只是个“老古董”接口完全不是。版本不断演进的是存储方式和管理入口但CSS对节点成员资格的判定权、对脑裂时的话语权、对共享存储的保护权一点都没有削弱。你升级到19c遇到私网闪断CCS该驱逐的还是会驱逐该重启的还是重启和前代版本的行为逻辑完全一致。5.2 哪些日常操作会无意中“碰到CSS”维护RAC时很多动作表面上是网络、存储或系统层面的实际上都会牵动CSS的判断逻辑。第一类NTP时间同步问题。CSS对集群内时间漂移很敏感节点间时钟差一大心跳的时间戳就乱了脑裂判定容易被误触发。虽然有些环境下配置了CTSS负责时间同步但如果你额外手工改了系统时间或NTP配置动作一定不能只做一次要确认跨节点时间完全一致后再继续观察CSS日志看有没有异常重配置。第二类私网IP或主机名变更。做这类变更前至少要过一遍CSS思路改名或改IP之后节点还能不能通过原来的私网路径找到彼此OCR里记录的节点信息要不要同步更新很多集群变更加载之后出现节点无法加入根源就是只改了系统层没同步集群配置层。第三类动态增删表决文件。CSS支持在线增加或移除表决文件理论上可以在业务运行中执行crsctl add votedisk、crsctl delete votedisk但我强烈不建议高峰期做这类操作。表决文件的重配置同样涉及全局重配置过程一旦命令执行中遇到存储抖动影响范围不会只局限在一块磁盘上。第四类操作系统加固。给服务器做安全基线加固时最容易被忽略的就是对CSS相关进程、私网端口、共享存储设备权限的变更。一块权限收得过紧CSS进程就再也打不开表决文件一个私网端口被防火墙策略误封心跳立刻中断。每一次系统加固之后都应该顺手跑一遍crsctl check cluster -all这不是形式主义而是用最短时间验证CSS最关心的两件事——网络和存储——是否依然畅通。经验上我还有个土办法每次在RAC环境做任何变更前先截一个图表决文件和集群状态的基线变更完再截一次对比一下。别小看这个动作它曾经帮我快速定位过一次“加固脚本把ASM磁盘设备权限改错”的低级问题。CSS这东西平时看不出存在感但恰恰是这些看似不相关的操作会让它瞬间从“后台进程”变成“故障主角”。再补一个非常实际的小技巧CSS日志会滚动保留但历史文件同样是排障宝藏。遇到问题时不要只盯着当天的ocssd.log去翻一下前一天甚至前几天的滚动日志往往能发现故障发生前就存在的规律性异常比如每天晚上同一个时间段就出现几次心跳超时这通常是定时任务或备份流量在捣乱。能看到这层规律才是把CSS排障从“救火”上升到“防火”的关键一步。