根本原因是OCR/voting disk所在LUN未被所有节点一致识别为可读写、可锁定，导致CRS无法通信；需检查multipath设备权限（应为grid:asmadmin）、SCSI-3 Persistent Reservations支持性及PR状态是否为空。
crs无法探测到共享存储，根本原因往往不是存储没挂上，而是ocr/voting disk所在的lun未被所有节点一致识别为可读写、可锁定——这直接导致crsctl check crs报crs-4535: cannot communicate with cluster ready services或crs-0184: cannot communicate with the crs daemon。
检查/dev/mapper/下multipath设备是否全部可见且权限正确
Oracle 11g RAC依赖ASM访问共享LUN，而ASM必须能对设备加锁（如DLM锁）。若multipath设备在某个节点上权限为root:disk而非grid:asmadmin，ASM进程将无法打开设备，进而无法完成voting disk注册。
- 在所有节点执行：
ls -l /dev/mapper/mpath*，确认输出中属主组是grid:asmadmin；若显示root:disk，说明权限未生效 - 立即修复：
chown grid:asmadmin /dev/mapper/mpath*（注意：仅作用于当前会话，重启后失效） - 永久生效必须写入
/etc/rc.local（CentOS/RHEL 6/7）或对应systemd服务（RHEL 8+），否则每次重启后crsctl start crs必失败 - 特别注意：
/dev/dm-*原始设备权限无需手动改——ASM不直接使用它们，只认/dev/mapper/下的别名设备
验证LUN是否真正支持并发读写与SCSI reservation
即使设备存在且权限正确，若底层存储不支持SCSI-3 Persistent Reservations（PR），OCR/voting disk就无法完成集群级锁定，CSSD进程启动时会静默失败。
- 用
sg_persist -i -d /dev/mapper/mpathX检查PR能力（需安装sg3_utils包）；正常应返回PR generation=xxx及PERSISTENT RESERVE IN数据 - 若报
SG_ERR_INVALID_OP_CODE或无输出，说明存储不支持PR，需联系厂商启用MetroMirror、Quorum Witness等特性，或更换为支持PR的LUN类型（如IBM DS8K的PPRC同步LUN） - 在AIX平台还需确认
reserve_lock属性已设为yes：lsattr -El hdiskX | grep reserve
排查ocrcheck -local和crsctl query css votedisk失败的根源
这两个命令看似简单，但失败时暴露的是最底层的I/O通路问题：不是“找不到设备”，而是“能看见但打不开”。
-
ocrcheck -local失败且报ORA-15031: disk specification matches no disks，先确认ASM磁盘字符串（asm_diskstring）是否包含/dev/mapper/mpath*，而非/dev/dm-*或/dev/sd* -
crsctl query css votedisk返回Unable to retrieve voting disk information，说明CSSD进程未成功初始化设备句柄——此时查$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，搜索IO error或open failed，90%指向设备权限或PR不支持 - 不要跳过
dd if=/dev/zero of=/dev/mapper/mpathX bs=1M count=100 oflag=direct测试：若某节点写失败或超时，说明该节点到LUN的路径存在隐性故障（如多路径错配、HBA固件bug）
最容易被忽略的是：OCR/voting disk所在LUN的PR状态在集群启动前必须为空。如果之前异常关机导致某个节点残留了reservation，新节点CSSD会因无法获取锁而卡死——此时需在所有节点卸载ASM磁盘组后，用sg_persist -C -d /dev/mapper/mpathX清除reservation。这个操作没有回滚，务必确认集群完全停止后再执行。
