ohasd-->ohasd agents-->daemons (gipcd, mdnsd, gpnpd,ctssd, ocssd, crsd, evmd asm etc),
然后 crsd-->crsd agents--> user resources (database, SCAN, listener etc)
1 故障解析方法
1 strace ./crsctl start crs
2 lsof -p 1233 查看进程占用得文件是否正常。
<1> 集群启动主要分为4个层面
层次1:OHASD层面,负责集群的初始化资源和进程。
层次2:CSS层面,负责构建集群并保障一致性。
层次3:CRS层面,负责管理集群各种应用程序资源。
层次4:EVM层面,负责在集群节点之间传递集群事件。
<1.1> OHASD层面
该层面负责启动集群初始化资源和进程,具体过程如下。
1 /etc/inittab中以下行被行被调用
h1:35:respawn:/etc/init.d/init.ohasd run > /dev/null 2>&1 </dev/null
◆在init.ohasd在启动ohasd.bin之前会执行如下操作
1 集群自动启动是否被禁用。
2 GI HOME所在文件系统是否被正常挂载。
3 管道文件(npohasd或者可能npohasd2)是否能被访问。
cd /var/tmp/.oracle。
◆/etc/init.d/init.ohasd run 启动失败常见的原因:
1 操作系统运行了错误的level(使用who -r查看当前的运行级别)
2 /etc/rc<N>.d当中的脚本被挂起,导致S(nn)ohasd没有被调用。
nohup /etc/init.d/init.ohasd run &
3 GI自动启动被关闭。
◆对于ohasd.bin它需要经过如下过程才能够正常运行
1 确认OLR存在且能够正常访问。
2 ohasd使用的嵌套字文件存在(socket file)
3 ohasd对应的日志文件能够被正常访问。
如果发现init.ohasd正常启动,但是ohasd.bin没有正常启动,比较常见原因如下:
1 OLR丢失或者不能访问。(ocrconfig -local -restore <OLR备份文件>)
2 ohasd对应的嵌套字无法访问或者创建。(重启crs)
3 ohasd对应的日志无法访问。
◆对于ohasd.bin启动集群初始化资源和进程。
1 ohasd.bin会启动4个代理进程来启动所有初始化资源和进程。
★oraagent:启动ora.asm、ora.evmd、ora.gipcd、ora.gpnpd、ora.mdnsd等。
★orarootagent:启动ora.crsd、ora.ctssd、ora.cluster_interconnect.haip、ora.crf等。
★cssdagent:启动ora.cssd
★cssdmonitor:启动ora.cssdmonitor
如果代理进程无法启动,则对应的资源和进程无法启动,常见进程无法启动原因如下
1 代理进程对应的二进制文件损坏。(将健康节点二进制文件比较,或者将健康文件复制到不良节点 )
2 代理进程的日志文件无法访问。
◆集群初始化资源启动
ohasd的代理进程会同时启动所有的初始化资源,但是它们之间还是存在依赖关系的。如下图
1 gipcd、gpnpd、mdnsd负责完成集群的bootstrap过程。
2 cssdagent和cssdmonitor负责启动和监控cssd进程,而其他集群的初始化进程都依赖于cssd。
bootstrap过程
1 mdns进程启动并启动mdns服务,以便gpnp能够通过mdns在节点之间同步gpnp profile。
2 gpnp进程启动并开始读取本地gpnp profile,之后和远程节点的gpnp守护进程通信,以便获取更新的gpnp profile。
3 gpnp服务启动完毕,向其他集群初始化资源提供gpnp profile服务。
4 gipcd守护进程启动,从gpnp守护进程获取集群私网信息,并和远程的gipcd通信,最后开始监控本地节点的私网。
5 cssdagent启动ocssd守护进程。
6 cssdmonitor守护进程启动,开始监控ocssd.bin状态。
无法bootstrap成功常见原因如下:
1 集群中存在其他mdns软件,例如avahi。
2 gpnp profile存在问题。
3 节点之间通信存在问题,导致gpnp profile无法正常传输。
4 gpnp的一些线程挂起,导致gpnp进程无法成功完成启动任务。
5 集群私网出现问题导致gipcd无法和其他节点通信。
6 gipc本身进程问题,导致错误认为网卡存在问题。
7 上述进程嵌套字文件丢失。