集群启动问题总结

某移动公司PMS系统 和 管信门户系统 都出现过集群无法启动的现象，通过对这两次问题的分析，总结如下：

一、首先，回顾一下两次问题的现象

• PMS系统

          数据库版本为10.2.0.4，主机组更换网卡后系统无法正常启动，回退。

          1、主机启动后crs集群无法正常启动，

         2、使用crsctl start crs命令启动集群时无报错且 crsd.log、ocssd.log、evmd.log、alertpmsora01.log 无任何报错信息。

• 管信门户系统

        数据库版本为11.2.0.4

           1、系统启动时ohasd进程不会自动启动

          2、crsctl start crs时报如下错误：

          CRS-4124: Oracle High Availability Services startup failed.

          CRS-4000: Command Start failed, or completed with errors.

          3、即使集群启动，集群alert日志还是报错，如下：

          2015-09-15 14:49:30.919: 

          [ohasd(9392)]CRS-0715:Oracle 高可用**在等待 init.ohasd 启动时超时

         4、 主机端也明显有异常现场：

          重启系统时 /var/adm/messages 日志无任何输出

二、问题处理过程

• PMS系统

          由于 crsd.log、ocssd.log、evmd.log、alertpmsora01.log 无任何报错信息，进入 $ORA_CRS_HOME/log/`hostname`/ 目录下使用 ls -lR 命令查看该目录及其子目录下的文件信息，查看启动CRS后时间点最新的文件，发现如下报错    

cat css202.log Oracle Database 10g CRS Release 10.2.0.4.0 Production Copyright 1996, 2008 Oracle.  All rights reserved. 2015-05-08 01:32:05.615:  [ CSSCLNT][1]clsssInitNative: connect failed, rc 9

在网上查看到一篇类似报错的文章： https://support.symantec.com/en_US/article.TECH127874.html

问题原因是由于 /etc/inittab进程未被系统调用导致集群无法启动，root用户执行init q手动调用后启动正常启动。

遇到这个问题后，我在MOS上找到了一篇关于集群启动的论坛：

在这篇文章里我们会对11gR2 GI 的启动顺序进行介绍，并且对常见的GI启动时遇到的问题和对应的解决办法进行介绍。    基本上我们可以把GI的启动过程分成3个阶段，ohasd阶段，构建集群阶段，启动资源阶段。   首先，ohasd阶段。 1． /etc/inittab文件中的脚本 h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null  被调用，产生下面的进程   root 4865 1 0 Dec02 ? 00:01:01 /bin/sh /etc/init.d/init.ohasd run   所以如果说你没有发现这个进程，那么说明 +init.ohasd 脚本可能没有被调用 + os运行在不正确的级别 + 一些S* ohasd脚本挂起， 例如S96ohasd + GI没有配置自动启动（crsctl enable crs） 之后，ohasd.bin 进程会被启动，这个时候OLR会被访问，所以，如果ohasd.bin不能正常工作，就需要查看OLR是否存在而且能够被正常访问。OLR存放在$GRID_HOME/cdata/${HOSTNAME}.olr   2. ohasd.bin进程会启动对应的agents(orarootagent, oraagent, cssdagnet 和 cssdmonitor) 来启动集群的初始化资源。如果说，您发现这些agent进程不能启动，很多时候都是由于路径$GRID_HOME/bin 下的可执行文件存在问题，例如，文件权限设置有问题，文件corruption.    接下来，构建集群阶段 1． Mdnsd 进程透过多播（Multicast）发现集群中的节点和所有的网卡信息。所以，一定要确定集群中的网卡支持多播。而且节点间的通信正常。 2． Gpnpd 进程启动，发布构建集群所需要的bootstrap 信息，并且在集群的所有节点之间同步gpnp profile。当然，同步是透过mdnsd实现的。所以，如果是这个进程存在问题，您需要确认节点间的通信正常，而且gpnp profile （<gi_home>/gpnp/profiles/peer/profile.xml）存在而且可以被访问。 3． Gipcd 进程启动，这个进程负责管理集群中所有的私网（cluster interconnect）网卡。当然，私网信息是通过gpnpd获得的，所以，如果这个进程存在问题，您需要确认gpnpd 进程正常运行。 4． Ocssd.bin 进程启动。这个进程首先通过gpnp profile中的信息发现表决盘(Voting Disk)，之后通过gpnpd 进程获得集群私网信息，和其他的节点建立连接。所以，如果ocssd.bin 不能正常运行，您需要确认一下的信息   + gpnp profile 存在而且可以被访问。 + gpnpd 进程正常运行。 + 表决盘所在的asm disk 或设备能够正常被访问。 + 节点私网间的通信正常。   5． 启动其他的初始化进程：ora.ctssd, ora.asm, ora.cluster_interconnect.haip, ora.crf, ora.crsd 等。 注意：以上的过程是同时进行的。也就是说ocssd.bin, gpnpd.bin 和 gipcd.bin 同时启动，直到gpnpd.bin正常运行，ocssd.bin 和 gipcd.bin 才能获得相应的信息，在gpnpd.bin没有正常运行之前,ocssd.bin 和 gipcd.bin 中出现的无法访问gpnp profile错误是可以忽略掉的。   最后，资源启动阶段 在这个阶段，主要是通过crsd进程启动各个资源。 1． Crsd进程启动。这个进程需要访问OCR，如果您的OCR是存放在ASM上，需要确保ASM实例正常运行，并且OCR所在的ASM磁盘组已经装载。如果OCR存放在裸设备上，那么需要确保对应的设备正常运行。 2． Crsd 启动对应的agents(orarootagent, oraagent_<rdbms_owner>, oraagent_<gi_owner> )。如果agent不能启动，很多时候都是由于路径$GRID_HOME/bin 下的可执行文件存在问题，例如，文件权限设置有问题，文件corruption. 3． 所有的资源启动。  ora.net1.network : 网络资源，这个资源负责管理集群的公网，scanvip, vip, listener资源都依赖于这个资源。所以，如果这个资源存在问题，vip, scanvip 和listener 都会offline，您需要检查公网是否存在问题。   ora.<scan_name>.vip：scan对应的vip资源，最多可以有3个。 ora.<node_name>.vip : 节点对应的vip 资源 ora.<listener_name>.lsnr: 监听程序资源。在这里我们要注意，从11gR2开始，listener.ora文件会自动生成，不再需要手动修改。 ora.LISTENER_SCAN<n>.lsnr: scan 监听程序。 ora.<磁盘组名>.dg: ASM 磁盘组资源。这个资源会在磁盘组被mount时创建，dismount时删除。   ora.<数据库名>.db: 数据库资源。在11gR2中实例资源已经不再存在了，新的数据库资源会管理rac 数据库的所有实例，而数据库包含哪些实例，是通过资源参数“USR_ORA_INST_NAME@SERVERNAME(<node name> )”来决定的。另外，如果您的数据库存储在ASM磁盘上，那么数据库资源会依赖于对应的磁盘组资源，这个dependency是自动添加的。但是，如果数据库被转移到了其他的磁盘组之后，原有的dependancy不会被自动删除，需要手动删除(crsctl modify res ……)。 ora.<服务名>.svc：数据库服务资源。从11gR2 开始，这个资源只有一个了，不会像10gR2一样，每个数据库服务资源包含，srv 和cs 两个资源。 ora.cvu ：这个资源从11.2.0.2被引入，定期对集群执行cluvfy操作，验证集群是否存在一些配置上的问题 ora.ons : ONS资源，和之前版本的功能，基本相同。   另外，我们对诊断GI启动问题所需要查看的文件进行简单的介绍   $GRID_HOME/log/<node_name>/ocssd <== ocssd.bin 日志 $GRID_HOME/log/<node_name>/gpnpd <== gpnpd.bin 日志 $GRID_HOME/log/<node_name>/gipcd <== gipcd.bin 日志 $GRID_HOME/log/<node_name>/agent/crsd <== crsd.bin 日志 $GRID_HOME/log/<node_name>/agent/ohasd <== ohasd.bin 日志 $GRID_HOME/log/<node_name>/mdnsd <== mdnsd.bin 日志 $GRID_HOME/log/<node_name>/client <== 用户使用GI 工具(ocrdump, crsctl, ocrcheck, gpnptool等等)对集群进行操作的日志。 $GRID_HOME/log/<node_name>/ctssd <== ctssd.bin 日志  $GRID_HOME/log/<node_name>/crsd <== crsd.bin 日志 $GRID_HOME/log/<node_name>/cvu <== cluvfy 日志 $GRID_HOME/bin/diagcollection.sh <== 通过这个脚本获得更全面的诊断日志。   最后，集群的套接字文件(/var/tmp/.oracle 或 /tmp/.oracle)，由于集群中很多进程之间的通信都是通过ipc实现的，所以，这些套接字文件一定要存在而且权限正确。 以上，我们对GI启动的顺序和基本的诊断方法进行了简单的介绍，希望能够为大家在诊断GI启动问题时能够提供一些帮助。 可以用下面的命令来查看GI相关的deamon的启动情况： #ps -ef|grep init #ps -ef|grep d.bin #crsctl stat res -t -init #crsctl check crs 1. #ps -ef|grep init， 对于11gR2，这个命令只会返回init.ohasd的信息， 如果没有类似于下面的信息显示，说明init.ohasd并没有启动，问题可能出现在/etc/init.d/init.ohasd脚本没有被调用。 root      7305     1  0 Mar05 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run 2. #ps -ef|grep d.bin， 这个命令可以帮我们找到有哪些daemon已经产生，例如crsd.bin, ocssd.bin 等等。 3. #crsctl stat res -t -init，这个命令用于查看哪些 init 资源被启动了(所谓的init资源是指由 ohasd 启动的资源)。 如果要查看集群的其他资源，可以用命令 crsctl stat res -t 4. #crsctl check crs , 这个命令主要是验证，ohasd, css, crs 和 evm 这几个层面的健康型。对于我们了解问题出现在哪个层面是有帮助的。 以下10g部分是我问到后oracle人员的回答 对于10g, 过程要简单很多。 1. 首先， /etc/inittab(不同平台文件名可能不同)，文件中的下面3行被调用。 h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null   这三个脚本是被同时调用的，每个脚本负责启动对应的守护进程。     2. 接下来，init.cssd 脚本负责把 ocssd.bin 守护进程启动并确认它正常工作， 之后crsd.bin 守护进程在发现ocssd.bin 正常云信之后，开始完成自己的启动，并开始启动集群的各个资源。 3. 最后，当crsd.bin 正常工作之后， evmd.bin 后台进程也就可以被正常启动并运行了。   所以， 虽然那3个脚本是同时被调用，但是守护进程之间是有依赖关系的， ocssd.bin --> crsd.bin --> evmd.bin

并在MOS上找到一些关于集群启动的文档：

Grid Infrastructure 启动的五大问题 (文档 ID 1526147.1)

诊断 Grid Infrastructure 启动问题 (文档 ID 1623340.1)

11gR2 Clusterware and Grid Home - What You Need to Know (文档 ID 1053147.1)

Crs Components Are Not Starting After Server Reboot (文档 ID 1152653.1)

• 管信门户系统

         有了PMS的经验分析管信门户系统问题的时候就相对容易一些，具体分析过程看昨天的邮件《 管信系统门户集群无法启动现象说 明 》，通过报错直接定位为系统层的问题，经过主机组分析处理后集群正常启动。

三、总结

          如果主机重启后无法没有正常启动

1、先查看相关进程是否正常启动

10g:

ps -ef | grep init | grep -v grep

11g:

ps -ef | grep ohasd | grep -v grep

2、确保 /etc/inittab文件配置是否正常(不同平台文件名可能不同，10g和11g是不同的)

10g:

h1: 35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null

h2: 35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null

h3: 35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

11g:

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null  

备注： CRS 需要 OS 运行在 run level 3 或 5；请注意，由于操作系统的不同，CRS 启动需要的 OS 的 run level 也会不同

3、其他情况不一一列举，参考上面MOS文档

4、如发现进程未运行，尝试手动启动进程，启动正常的话就ok，如果启动异常，查看日志，针对报错进行分析。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29953799/viewspace-1800883/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29953799/viewspace-1800883/