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
h1: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 root3171780 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=eth1
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
<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">