clusterware启动顺序——OHASD

Clusterware启动顺序

[root@ebsdb1 etc]# crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

根据以上输出，集群大概可分为 4 个层次：

层次 1 ： OHAS 层面，负责集群的初始化资源和进程。

层次 2 ： CSS 层面，负责构建集群并保证集群的一致性。

层次 3 ： CRS 层面，负责管理集群的各种应用程序资源。

层次 4 ： EVM 层面，负责在集群节点间传递集群事件。

接下来详细地介绍每一个层面的启动过程：

OHASD 层面

该层面主要负责启动集群的初始化资源和进程，具体的过程如下：

1./etc/inittab 中的以下行被调用

$cat /etc/inittab|grep init.d | grep –v grep
h2:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2. 操作系统进程 init.ohasd run 被启动，该进程负责启动 ohasd.bin 守护进程

[root@ebsdb1 etc]# ps -ef | grep ohasd | grep -v grep

root3813     1  0 Feb03 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

root56333     1  0 Feb03 ?        01:03:52 /ebsdb/grid/11.2.0/bin/ohasd.bin reboot

而 init.ohasd 在启动 ohasd.bin 守护进程之前需要执行以下的操作。

1） 集群自动启动是否被禁用

2） GI home 所在文件系统是否被正常挂载

3） 管道文件（ npohasd ）是否能够被访问

[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle

total 4

srwxr-xr-x 1 grid    oinstall 0 Feb  3 10:41 mdnsd

-rwxrwxrwx 1 grid    oinstall 6 Feb  3 10:41 mdnsd.pid

prwxrwxrwx 1 root    root0 Oct 26 15:43 npohasd

对于 ohasd.bin 进程，他需要经过以下过程才能够正常运行。

1） 确认 OLR 存在，而且能够被正常访问

[grid@ebsdb1 ~]$ ls -l $GRID_HOME/cdata/

total 2928

drwxr-xr-x 2 grid oinstall      4096 Feb 14 10:21 ebsdb1

-rw------- 1 root oinstall 272756736 Feb 14 15:02 ebsdb1.olr

drwxrwxr-x 2 grid oinstall      4096 Jan 25 13:11 ebsdb-cluster

drwxr-xr-x 2 grid oinstall      4096 Oct 26 15:38 localhost

2） ohasd 所使用的套接字文件（ socket file ）存在

[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle/*HAS*

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sebsdb1DBG_OHASD

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11

-rwxrwxrwx 1 root root 0 Oct 26 15:43 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11_lock

srwxrwxrwx 1 root root 0 Feb  3 10:41 /var/tmp/.oracle/sOHASD_UI_SOCKET

3） ohasd 对应的日志文件能够被正常访问

[grid@ebsdb1 11.2.0]$ ls -l $GRID_HOME/log/ebsdb1/ohasd

total 106192

-rw-r--r-- 1 root root 10579981 Feb 12 16:01 ohasd.l01

-rw-r--r-- 1 root root 10520765 Feb  5 20:22 ohasd.l02

-rw-r--r-- 1 root root 10547596 Jan 24 14:24 ohasd.l03

-rw-r--r-- 1 root root 10544559 Jan 22 18:01 ohasd.l04

-rw-r--r-- 1 root root 10546879 Jan 20 21:42 ohasd.l05

-rw-r--r-- 1 root root 10551400 Jan 19 01:21 ohasd.l06

-rw-r--r-- 1 root root 10552985 Jan 17 04:50 ohasd.l07

-rw-r--r-- 1 root root 10550884 Jan 15 08:21 ohasd.l08

-rw-r--r-- 1 root root 10548055 Jan 13 11:52 ohasd.l09

-rw-r--r-- 1 root root 10548999 Jan 11 15:09 ohasd.l10

-rw-r--r-- 1 root root  3171780 Feb 14 17:03 ohasd.log

-rw-r--r-- 1 root root     1260 Feb3 10:41 ohasdOUT.log

 

如果发现 init.ohasd 进程没有出现，那么说明操作系统进程没有成功地调用 /etc/init.d/init.ohasd run 命令，比较常见的原因可能如下：

原因 1 ：操作系统运行在了错误的 runlevel （可使用 who –r 查看当前的运行级别）

原因 2:/etc/rc<n>.d 当中有些脚本被挂起，导致了 S<nn>ohasd 没有被调用

原因 3 ： GI 的自动启动功能被关闭（ crsctl disable crs ）

而对应的解决办法如下：

办法 1 ：重新启动操作系统到正确的运行级别

办法 2 ：手工运行 init.ohasd 脚本（例如：  nohup /etc/init.d/ohasd run & ）

办法 3 ：启动 GI 自动启动功能（ crsctl enable crs ）

 

如果发现 init.ohasd 已经启动，但是 ohasd.bin 没有被正常启动，比较常见的原因如下：

原因 1 ： OLR 不能被访问或者已经丢失。

原因 2 ： ohasd 对应的套接字文件无法访问或者已经丢失

原因 3 ： ohasd 对应的日志文件无法被访问

而对应的解决办法如下：

办法 1: 从 OLR 备份中恢复 OLR （默认情况下，在集群安装结束后， OLR 会备份 <$GRID_HOME/cdata/< 节点名 >/backup_< 时间 >.olr> ）

ocrconfig –local –restore <OLR 备份文件 >

办法 2 ：重新启动 GI ，以便重建套接字文件

crsctl stop crs

crsctl start crs

办法 3 ：修改 ohasd 日志文件的属性，确认它能够被访问到

-rw-r--r-- 1 root root 3171780 Feb 14 17:03 ohasd.log

当然，如果遇到了其他问题，那就需要查看 ohasd.log 来进行问题分析了

 

3.ohasd.bin 开始启动集群的初始化资源和进程

根据前面的介绍， ohasd.bin 会启动 4 个代理进程来启动所有的集群初始化资源。

oraagnet ：启动 ora.asm 、 ora.evmd 、 ora.gipcd 、 ora.gpnpd 、 ora.mdnsd 等

orarootagent ：启动 ora.crsd 、 ora.ctssd 、 ora.cluster_interconnect.haip 、 ora.crf 、 ora.diskmon 等

cssdagnet ：启动 ora.cssd

cssdmonitor ：启动 ora.cssdmonitor

如果对应的代理进程无法启动的话，那么以上的集群初始化资源也就无法启动，而代理进程无法启动的主要原因有以下两种：

原因 1 ：代理进程对应的二进制文件损坏

原因 2 ：代理进程的日志文件无法访问

[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oraagent_grid

total 109976

……

-rw-r--r-- 1 grid oinstall  6895201 Feb 14 19:28 oraagent_grid.log

……

 

[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/orarootagent_root

total 112468

……

-rw-r--r-- 1 root root  9467315 Feb 14 19:30 orarootagent_root.log

……

 

[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdagent_root

total 852

-rw-r--r-- 1 root root 865091 Feb 14 16:04 oracssdagent_root.log

 

[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdmonitor_root

total 844

-rw-r--r-- 1 root root 856526 Feb 14 19:25 oracssdmonitor_root.log

 

对应的解决办法如下：

办法 1 ：将有问题节点的代理进程二进制文件和健康节点的文件进行比较，发现不同后，把健康节点的文件复制到问题节点的对应位置。

办法 2 ：确认代理进程的日志文件能够被对应的用户访问。

 

4. 集群的初始化资源开始启动

虽然 ohasd 的代理进程会同时启动所有的集群初始化资源，但是它们之间还是有依赖关系的，集群初始化资源的启动依赖关系如下：

有些对集群不重要的初始化资源，在上图中并没有显示

从上面的途中大家可以看到 gipcd 、 gpnpd 、 mdnsd 负责完成集群的 bootstrap 过程； cssdagent 和 cssdmonitor 负责启动和监控 cssd 守护进程；而集群的其他初始化资源都要依赖于 cssd 。

下面对集群的 bootstrap 过程进行简单的介绍（详细的过程在 css 管理中）

1） mdnsd 守护进程被启动，并启动 mdns 服务，以便 gpnpd 能够通过 mdns 在节点之间传输 gpnp profile 文件。

2） gpnpd 守护进程被启动， gpnpd 开始读取本地节点的 gpnp profile ，之后和远程节点的 gpnpd 守护进程通信，以便获得集群中最新的 gpnp profile 信息。

3） gpnpd 启动完毕，向本地节点的其他集群初始化资源提供 gpnp profile 服务。

4） gipcd 守护进程被启动，从 gpnpd 守护进程获得集群的私网信息，并和远程节点的 gpipcd 守护进程通信，最后开监控本地节点的私网。

5） cssdagent 代理进程启动 ocssd.bin 守护进程。

6） cssdmonitor 守护进程启动，并开始监控 ocssd.bin 守护进程的状态。

在整个过程中，可能导致集群的 bootstrap 过程无法成功的主要原因如下。

原因 1 ：集群中有其他的 mdns 软件运行，这会导致 GI 的 mdnsd 服务无法正常工作。

原因 2 ： gpnp profile 文件中的信息出现错误，这会导致集群的 bootstrap 过程无法完成。

[grid@ebsdb1 peer]$ gpnptool get

或

[grid@ebsdb1 peer]$  cat $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml

原因 3 ：节点之间的网络通信存在问题，这会导致 gpnp profile 无法正常传输。

原因 4 ： gpnp 的一些线程被挂起，这会导致 gpnpd 守护进程无法成功完成启动任务。

原因 5 ：集群的私网网卡出现问题，这会导致 gipcd 无法和其他节点的 gipcd 进行通信或者集群没有可用的私网进行通信。

原因 6 ： gipcd 存在问题，这会导致它错误地认为集群私网网卡存在问题。

原因 7 ：以上守护进程的套接字文件丢失。

对应的解决方法如下。

方法 1 ：停止并禁用其他的 mdns 软件。

方法 2 ：如果 gpnp profile 只是在集群的某一个节点上出现了错误，可以从集群的其他节点将其复制过来。如果集群所有几点的 gpnp pfile 都出现了问题，那么就需要使用 gpnp 工具来进行修正。

下面的例子演示了如何使用 gpnp tool 修改 gpnp profile 中集群的私网信息。

1）   检查当前的 gpnp profile ，确认 gpnpd 能够通过 mdns 找到集群的其他节点。

[grid@ebsdb1 peer]$ gpnptool get

[grid@ebsdb1 peer]$ gpnptool find

2）   创建一个工作路径以用于编辑 gpnp profile

mkdir /home/grid/gpnp

export GPNPDIR=/home/grid/gpnp

$GRID_HOME/bing/gpnptool get -o=$GPNPDIR/profile.original

3）   创建一个用于修改的 gpnp profile 副本

cp $GPNPDIR/profile.original $GPNPDIR/p.xml

4）   查看 gpnp profile 的序列号和私网信息

$gpnptool getpval -p=$GPNPDIR/p.xml -prf_sq -o-

$gpnptool getpval -p=$GPNPDIR/p.xml -net -o-

5）   修改集群私网的网卡信息

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=< 当前序列号 +1> -net< 私网编号 >:net_ada=< 私网网卡名 >

例如：

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=9 -net2:net_ada=eth2

6）   确认之前的修改

gpnptool sign -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -w=cw-fs:peer

7）   将修改后的 gpnp profile 应用到 gpnpd 守护进程中。

gpnptool put -p=$GPNPDIR/p.xml

8）   将改变后的 gpnp profile 推送到集群的其他节点

gpnptool find -c=< 集群名 >

gpnptool rget -c=< 集群名 >

方法 3 ：确认件私网通信正常（例如：使用 ping 、 traceroute 等命令确认集群私网的连通性）

方法 4 ：在操作系统层面重新启动 gpnp 守护进程，例如： kill -9 <gpnp 进程 ID>

当 gpnpd 守护进程被总之之后，对应的 ohasd 代理进程 oraagent 会及时发现这一情况，并启动新的 gpnpd 守护进程。

方法 5 ：确认集群私网通信正常（例如：使用 ping 、 traceroute 等命令确认集群私网的连通性）

方法 6 ：在操作系统层面重新启动 gipcd 守护进程，例如： kill -9 <gipcd 进程 ID>

当 gipcd 守护进程被总之之后，对应的 ohasd 代理进程 oraagent 会及时发现这一情况，并启动新的 gipcd 守护进程。

方法 7 ：重新启动 GI ，以便重建套接字文件。

crsctl stop crs

crsctl start crs