1 集群架构图
整体集群架构图如下：
1 数据库启动顺序OHASD层面
操作系统进程init.ohasd run启动ohasd.bin
init.ohasd run
- 集群自动启动是否被禁用 crsctl enable has/crs
- GIHOME所在文件系统是否被正常挂载。
- 管道文件npohasd是否能够被访问， cd /var/tmp/.oracle/ (管道文件目录)
- 手动执行run脚本 nohup /etc/init.d/init.ohasd run &.
ohasd.bin
- 确认OLR存在而且能够正常被访问。($GI_HOME/crsdata/tjnrmsdb1/olr/,或者使用./ocrcheck -local
- ohasd所使用的嵌套字文件socket file存在。
- 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-daemon22477： Withdrawing address record？for *.*.*.* on bond1. Oct 6 22：52：58 test1？avahi-daemon22477： Leaving mDNS multicast group on interface？bond1.IPv4 with address *.*.*.*. Oct 6 22：52：58 test1？avahi-daemon22477： Joining mDNS multicast group on interface？bond1.IPv4 with address 169.254.180.94. Oct 6 22：52：58 test1 avahi-daemon22477： Withdrawing address record for 169.254.180.94 on bond1. Oct 6 22：52：58 test1？avahi-daemon22477： 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找到集群的其他节点。
\
2）创建一个工作路径以用于编辑gpnp profile。
mkdir /home/grid/gpnp
export GPNPDIR=/home/grid/gpnp
\
3）创建一个用于修改的gpnp profile副本。
cp GPNPDIR/profile.original $GPNPDIR/p.xml
4）查看gpnp profile的序列号和私网信息。
\
5）修改集群私网的网卡信息。
\
例如：
gpnptool edit -p=GPNPDIR/p.xml -o=GPNPDIR/p.xml -ovr -prf_sq=9 -net2：net_ada=eth1
6）确认之前的修改。
\
7）将修改后的gpnp profile应用到gpnpd守护进程中。
\
8）将改变后的gpnp profile推送到集群的其他节点。
\
方法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对应的进程架构图
