1 集群架构图

整体集群架构图如下：

1 数据库启动顺序OHASD层面

操作系统进程init.ohasd run启动ohasd.bin

init.ohasd run

1. 集群自动启动是否被禁用 crsctl enable has/crs
2. GIHOME所在文件系统是否被正常挂载。
3. 管道文件npohasd是否能够被访问， cd /var/tmp/.oracle/ (管道文件目录)
4. 手动执行run脚本 nohup /etc/init.d/init.ohasd run &.

ohasd.bin

1.  确认OLR存在而且能够正常被访问。($GI_HOME/crsdata/tjnrmsdb1/olr/,或者使用./ocrcheck -local
2. ohasd所使用的嵌套字文件socket file存在。
3. ohasd对应的日志文件能够正常访问。

2 初始化集群初始资源

ohasd.bin会启动4个代理进程来启动所有的集群初始化资源。

oraagent负责启动资源：ora.asm,ora.evmd,ora.gipcd,ora.gpnpd,ora.mdnsd等。

orarootagent负责启动资源：ora.crsd\ora.ctssd\ora.cluster_interconnect.ha\ora.crf等。

cssdagent负责启动ora.cssd

cssdmonitor负责启动ora.cssdmonitor.  

常见失败汇总

1 二进制文件损坏

拷贝健康节点的二进制文件过来继续使用。

2 代理进程日志文件无法访问。

3 集群初始化资源开始启动

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

1 ）mdnsd守护进程被启动，并启动mdns服务，以便gpnpd能够通过mdns在节点之间传输gpnp profile文件。
2）gpnpd守护进程被启动，gpnpd开始读取本地节点的gpnp profile，之后和远程节点的gpnpd守护进程通信，以便获得集群中最新的gpnp profile信息。
3）gpnpd启动完毕，向本地节点的其他集群初始化资源提供gpnp profile服务。
4）gipcd守护进程被启动，从gpnpd守护进程获得集群的私网信息，并和远程节点的gipcd守护进程通信，最后开始监控本地节点的私网。
5）cssdagent代理进程启动ocssd.bin守护进程。
6）cssdmonitor守护进程启动，并开始监控ocssd.bin守护进程的状态。
在整个过程中，可能导致集群的bootstrap过程无法成功的主要原因如下。
原因1：集群中有其他的mdns软件运行（例如：avahi），这会导致GI的mdnsd服务无法正常工作。例如：
​​Oct  6 22：52：58 test1？avahi-daemon[22477]： Withdrawing address record？for *.*.*.* on bond1.
Oct  6 22：52：58 test1？avahi-daemon[22477]： Leaving mDNS multicast group on interface？bond1.IPv4 with address *.*.*.*.
Oct  6 22：52：58 test1？avahi-daemon[22477]： Joining mDNS multicast group on interface？bond1.IPv4 with address 169.254.180.94.
Oct  6 22：52：58 test1 avahi-daemon[22477]： Withdrawing address record for 169.254.180.94 on bond1.
Oct  6 22：52：58 test1？avahi-daemon[22477]： Interface bond1.IPv4 no longer relevant for mDNS.​​
原因2：gpnp profile文件中的信息出现错误，这会导致集群的bootstrap过程无法完成。例如：
​​[grid@test1 oraagent_grid]$ gpnptool get
Warning： some command line parameters were defaulted. Resulting command line：
         /u01/app/11.2.0/grid/bin/gpnptool.bin get -o-
......
gpnp-profile.xsd" ProfileSequence="13" ClusterUId="7d414c4a930cdfc4ff23e150c9acd5e0" ClusterName="test-cluster" PALocation=""><gpnp：Network-Profile><gpnp：HostNetwork id="gen" HostName="*">
<gpnp：Network id="net2" IP="*.*.*.0" Adapter="eth88" Use="cluster_interconnect"/>  <<<<<私网网卡信息错误
<gpnp：Network id="net1" Adapter="eth0" IP="*.*.*.0" Use="public"/>​​
原因3：节点之间的网络通信存在问题，这会导致gpnp profile无法正常传输。
原因4：gpnp的一些线程被挂起，这会导致gpnpd守护进程无法成功完成启动任务。
原因5：集群的私网网卡出现问题，这会导致gipcd无法和其他节点的gipcd进行通信或者集群没有可用的私网进行通信。
原因6：gipcd存在问题，这会导致它错误地认为集群私网网卡存在问题。
原因7：以上守护进程的套接字文件丢失。
而对应的解决方法如下。
方法1：停止并禁用其他的mdns软件。例如：
​​# /etc/rc.d/init.d/avahi-dnsconfd stop
# /etc/rc.d/init.d/avahi-daemon stop
# chkconfig avahi-dnsconfd off
# chkconfig avahi-daemon off​​
方法2：如果gpnp profile只是在集群的某一个节点上出现了错误，可以从集群的其他节点将其复制过来。如果集群所有节点的gpnp profile都出现了问题，那么就需要使用gpnp工具来进行修正。

---索引如果修改集群私网要备份gpnp profile文件 

下面的例子演示了如何使用gpnp tool修改集群的私网信息。
1）检查当前的gpnp profile，确认gpnpd能够通过mdns找到集群的其他节点。
​​$<gi_home>/bin/gpnptool get
$<gi_home>/bin/gpnptool find​​
2）创建一个工作路径以用于编辑gpnp profile。
​​$mkdir /home/grid/gpnp
$export GPNPDIR=/home/grid/gpnp
$<gi_home>/bin/gpnptool get -o=$GPNPDIR/profile.original​​
3）创建一个用于修改的gpnp profile副本。
​​$cp $GPNPDIR/profile.original $GPNPDIR/p.xml​​
4）查看gpnp profile的序列号和私网信息。
​​$<gi_home>/bin/gpnptool getpval -p=$GPNPDIR/p.xml -prf_sq -o-
$<gi_home>/bin/gpnptool getpval -p=$GPNPDIR/p.xml -net -o-​​
5）修改集群私网的网卡信息。
​​$<gi_home>/bin/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=eth1​​
6）确认之前的修改。
​​$<gi_home>/bin/gpnptool sign -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -w=cw-fs：peer​​
7）将修改后的gpnp profile应用到gpnpd守护进程中。
​​$<gi_home>/bin/gpnptool put -p=$GPNPDIR/p.xml​​
8）将改变后的gpnp profile推送到集群的其他节点。
​​$<gi_home>/bin/gpnptool find -c=<集群名>
$<gi_home>/bin/gpnptool rget -c=<集群名>​​
方法3：确认集群私网通信正常（例如：使用ping、traceroute等命令确认集群私网的连通性）。
方法4：在操作系统层面重新启动gpnp守护进程，例如：kill-9<gpnpd进程ID>。
注意
当gpnpd守护进程被终止之后，对应的ohasd代理进程会及时发现这一情况，并启动新的gpnpd守护进程。
方法5：确认集群私网通信正常（例如：使用ping、traceroute等命令确认集群私网的连通性）。
方法6：在操作系统层面重新启动gipcd守护进程，例如：kill-9<gipcd进程ID>。
注意
当gpicd守护进程被终止之后，对应的ohasd代理进程会及时发现这一情况，并启动新的gipcd守护进程。
方法7：重新启动GI，以便重建套接字文件。
​​#<gi_home>/bin/crsctl stop crs


#<gi_home>/bin/crsctl start crs​​

 2 AGENT对应的进程架构图