11gR2 叢集管理軟體（GI） 啟動順序和診斷方法簡介

在這篇文章裡我們會對11gR2 GI 的啟動順序進行介紹，並且對常見的GI啟動時遇到的問題和對應的解決辦法進行介紹。

 

基本上我們可以把GI的啟動過程分成3個階段，ohasd階段，構建叢集階段，啟動資源階段。

 

首先，ohasd階段。

 

1． /etc/inittab檔案中的指令碼

 

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1  

被呼叫，產生下面的程式

 

root 4865 1 0 Dec02 ? 00:01:01 /bin/sh /etc/init.d/init.ohasd run

 

所以如果說你沒有發現這個程式，那麼說明

 

+init.ohasd 指令碼可能沒有被呼叫

 

+ os執行在不正確的級別

 

+ 一些S* ohasd指令碼掛起， 例如S96ohasd

 

+ GI沒有配置自動啟動（crsctl enable crs）

 

之後，ohasd.bin 程式會被啟動，這個時候OLR會被訪問，所以，如果ohasd.bin不能正常工作，就需要檢視OLR是否存在而且能夠被正常訪問。OLR存放在$GRID_HOME/cdata/${HOSTNAME}.olr

 

 

2. ohasd.bin程式會啟動對應的agents(orarootagent, oraagent, cssdagnet 和 cssdmonitor) 來啟動叢集的初始化資源。如果說，您發現這些agent程式不能啟動，很多時候都是由於路徑$GRID_HOME/bin 下的可執行檔案存在問題，例如，檔案許可權設定有問題，檔案corruption. 

 

接下來，構建叢集階段。

 

1． Mdnsd 程式透過多播（Multicast）發現叢集中的節點和所有的網路卡資訊。所以，一定要確定叢集中的網路卡支援多播。而且節點間的通訊正常。

 

2． Gpnpd 程式啟動，釋出構建叢集所需要的bootstrap 資訊，並且在叢集的所有節點之間同步gpnp profile。當然，同步是透過mdnsd實現的。所以，如果是這個程式存在問題，您需要確認節點間的通訊正常，而且gpnp profile （/gpnp/profiles/peer/profile.xml）存在而且可以被訪問。

 

3． Gipcd 程式啟動，這個程式負責管理叢集中所有的私網（cluster interconnect）網路卡。當然，私網資訊是透過gpnpd獲得的，所以，如果這個程式存在問題，您需要確認gpnpd 程式正常執行。

 

4． Ocssd.bin 程式啟動。這個程式首先透過gpnp profile中的資訊發現表決盤(Voting Disk)，之後透過gpnpd 程式獲得叢集私網資訊，和其他的節點建立連線。所以，如果ocssd.bin 不能正常執行，您需要確認一下的資訊

 

+ gpnp profile 存在而且可以被訪問。

 

+ gpnpd 程式正常執行。

 

+ 表決盤所在的asm disk 或裝置能夠正常被訪問。

 

+ 節點私網間的通訊正常。

 

5． 啟動其他的初始化程式：ora.ctssd, ora.asm, ora.cluster_interconnect.haip, ora.crf, ora.crsd 等。

 

注意：以上的過程是同時進行的。也就是說ocssd.bin, gpnpd.bin 和 gipcd.bin 同時啟動，直到gpnpd.bin正常執行，ocssd.bin 和 gipcd.bin 才能獲得相應的資訊，在gpnpd.bin沒有正常執行之前,ocssd.bin 和 gipcd.bin 中出現的無法訪問gpnp profile錯誤是可以忽略掉的。

 

最後，資源啟動階段。在這個階段，主要是透過crsd程式啟動各個資源。

 

1． Crsd程式啟動。這個程式需要訪問OCR，如果您的OCR是存放在ASM上，需要確保

 

ASM例項正常執行，並且OCR所在的ASM磁碟組已經裝載。如果OCR存放在裸裝置上，那麼需要確保對應的裝置正常執行。

 

2． Crsd 啟動對應的agents(orarootagent, oraagent_, oraagent_ )。如果agent不能啟動，很多時候都是由於路徑$GRID_HOME/bin 下的可執行檔案存在問題，例如，檔案許可權設定有問題，檔案corruption.

 

3． 所有的資源啟動。

 

 ora.net1.network : 網路資源，這個資源負責管理叢集的公網，scanvip, vip, listener資源都依賴於這個資源。所以，如果這個資源存在問題，vip, scanvip 和listener 都會offline，您需要檢查公網是否存在問題。

 

ora..vip：scan對應的vip資源，最多可以有3個。

 

ora..vip : 節點對應的vip 資源

 

ora..lsnr: 監聽程式資源。在這裡我們要注意，從11gR2開始，listener.ora檔案會自動生成，不再需要手動修改。

 

ora.LISTENER_SCAN.lsnr: scan 監聽程式。

 

ora.<磁碟組名>.dg: ASM 磁碟組資源。這個資源會在磁碟組被mount時建立，dismount時刪除。

 

ora.<資料庫名>.db: 資料庫資源。在11gR2中例項資源已經不再存在了，新的資料庫資源會管理rac 資料庫的所有例項，而資料庫包含哪些例項，是透過資源引數“USR_ORA_INST_NAME@SERVERNAME( )”來決定的。另外，如果您的資料庫儲存在ASM磁碟上，那麼資料庫資源會依賴於對應的磁碟組資源，這個dependency是自動新增的。但是，如果數 據庫被轉移到了其他的磁碟組之後，原有的dependancy不會被自動刪除，需要手動刪除(crsctl modify res ……)。

 

ora.<服務名>.svc：資料庫服務資源。從11gR2 開始，這個資源只有一個了，不會像10gR2一樣，每個資料庫服務資源包含，srv 和cs 兩個資源。

 

ora.cvu ：這個資源從11.2.0.2被引入，定期對叢集執行cluvfy操作，驗證叢集是否存在一些配置上的問題

 

ora.ons : ONS資源，和之前版本的功能，基本相同。

 

另外，我們對診斷GI啟動問題所需要檢視的檔案進行簡單的介紹

 

$GRID_HOME/log//ocssd <== ocssd.bin 日誌

 

$GRID_HOME/log//gpnpd <== gpnpd.bin 日誌

 

$GRID_HOME/log//gipcd <== gipcd.bin 日誌

 

$GRID_HOME/log//agent/crsd <== crsd.bin 日誌

 

$GRID_HOME/log//agent/ohasd <== ohasd.bin 日誌

 

$GRID_HOME/log//mdnsd <== mdnsd.bin 日誌

 

$GRID_HOME/log//client <== 使用者使用GI 工具(ocrdump, crsctl, ocrcheck, gpnptool等等)對叢集進行操作的日誌。

 

$GRID_HOME/log//ctssd <== ctssd.bin 日誌

 

$GRID_HOME/log//crsd <== crsd.bin 日誌

 

$GRID_HOME/log//cvu <== cluvfy 日誌

 

$GRID_HOME/bin/diagcollection.sh <== 透過這個指令碼獲得更全面的診斷日誌。

 

最後，叢集的套接字檔案(/var/tmp/.oracle 或 /tmp/.oracle)，由於叢集中很多程式之間的通訊都是透過ipc實現的，所以，這些套接字檔案一定要存在而且許可權正確。

可以用下面的命令來檢視GI相關的deamon的啟動情況：
#ps -ef|grep init
#ps -ef|grep d.bin
#crsctl stat res -t -init
#crsctl check crs
關於這些命令，再詳細解釋一下。

1. #ps -ef|grep init， 對於11gR2，這個命令只會返回init.ohasd的資訊， 如果沒有類似於下面的資訊顯示，說明init.ohasd並沒有啟動，問題可能出現在/etc/init.d/init.ohasd指令碼沒有被呼叫。
root      7305     1  0 Mar05 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

2. #ps -ef|grep d.bin， 這個命令可以幫我們找到有哪些daemon已經產生，例如crsd.bin, ocssd.bin 等等。

3. #crsctl stat res -t -init，這個命令用於檢視哪些 init 資源被啟動了(所謂的init資源是指由 ohasd 啟動的資源)。 如果要檢視叢集的其他資源，可以用命令
crsctl stat res -t

4. #crsctl check crs , 這個命令主要是驗證，ohasd, css, crs 和 evm 這幾個層面的健康型。對於我們瞭解問題出現在哪個層面是有幫助的。

對於10g, 過程要簡單很多。

1. 首先， /etc/inittab(不同平臺檔名可能不同)，檔案中的下面3行被呼叫。

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1

h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1

這三個指令碼是被同時呼叫的，每個指令碼負責啟動對應的守護程式。

2. 接下來，init.cssd 指令碼負責把 ocssd.bin 守護程式啟動並確認它正常工作， 之後crsd.bin 守護程式在發現ocssd.bin 正常雲信之後，開始完成自己的啟動，並開始啟動叢集的各個資源。

3. 最後，當crsd.bin 正常工作之後， evmd.bin 後臺程式也就可以被正常啟動並執行了。

所以，雖然那3個指令碼是同時被呼叫，但是守護程式之間是有依賴關係的， ocssd.bin --> crsd.bin --> evmd.bin

以上，我們對GI啟動的順序和基本的診斷方法進行了簡單的介紹，希望能夠為大家在診斷GI啟動問題時能夠提供一些幫助。