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

根據(jù)以上輸出，集群大概可分為 4 個層次：

層次 1 ： OHAS 層面，負責集群的初始化資源和進程。

層次 2 ： CSS 層面，負責構(gòu)建集群并保證集群的一致性。

層次 3 ： CRS 層面，負責管理集群的各種應用程序資源。

層次 4 ： EVM 層面，負責在集群節(jié)點間傳遞集群事件。

接下來詳細地介紹每一個層面的啟動過程：

OHASD 層面

該層面主要負責啟動集群的初始化資源和進程，具體的過程如下：

1./etc/inittab 中的以下行被調(diào)用

$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. 操作系統(tǒng)進程 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 守護進程之前需要執(zhí)行以下的操作。

1） 集群自動啟動是否被禁用

2） GI home 所在文件系統(tǒng)是否被正常掛載

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 進程，他需要經(jīng)過以下過程才能夠正常運行。

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

如果發(fā)現(xiàn) init.ohasd 進程沒有出現(xiàn)，那么說明操作系統(tǒng)進程沒有成功地調(diào)用 /etc/init.d/init.ohasd run 命令，比較常見的原因可能如下：

原因 1 ：操作系統(tǒng)運行在了錯誤的 runlevel （可使用 who –r 查看當前的運行級別）

原因 2:/etc/rc<n>.d 當中有些腳本被掛起，導致了 S<nn>ohasd 沒有被調(diào)用

原因 3 ： GI 的自動啟動功能被關(guān)閉（ crsctl disable crs ）

而對應的解決辦法如下：

辦法 1 ：重新啟動操作系統(tǒng)到正確的運行級別

辦法 2 ：手工運行 init.ohasd 腳本（例如：  nohup /etc/init.d/ohasd run & ）

辦法 3 ：啟動 GI 自動啟動功能（ crsctl enable crs ）

如果發(fā)現(xiàn) init.ohasd 已經(jīng)啟動，但是 ohasd.bin 沒有被正常啟動，比較常見的原因如下：

原因 1 ： OLR 不能被訪問或者已經(jīng)丟失。

原因 2 ： ohasd 對應的套接字文件無法訪問或者已經(jīng)丟失

原因 3 ： ohasd 對應的日志文件無法被訪問

而對應的解決辦法如下：

辦法 1: 從 OLR 備份中恢復 OLR （默認情況下，在集群安裝結(jié)束后， OLR 會備份 <$GRID_HOME/cdata/< 節(jié)點名 >/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 開始啟動集群的初始化資源和進程

根據(jù)前面的介紹， 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 ：將有問題節(jié)點的代理進程二進制文件和健康節(jié)點的文件進行比較，發(fā)現(xiàn)不同后，把健康節(jié)點的文件復制到問題節(jié)點的對應位置。

辦法 2 ：確認代理進程的日志文件能夠被對應的用戶訪問。

4. 集群的初始化資源開始啟動

雖然 ohasd 的代理進程會同時啟動所有的集群初始化資源，但是它們之間還是有依賴關(guān)系的，集群初始化資源的啟動依賴關(guān)系如下：

有些對集群不重要的初始化資源，在上圖中并沒有顯示

從上面的途中大家可以看到 gipcd 、 gpnpd 、 mdnsd 負責完成集群的 bootstrap 過程； cssdagent 和 cssdmonitor 負責啟動和監(jiān)控 cssd 守護進程；而集群的其他初始化資源都要依賴于 cssd 。

下面對集群的 bootstrap 過程進行簡單的介紹（詳細的過程在 css 管理中）

1） mdnsd 守護進程被啟動，并啟動 mdns 服務，以便 gpnpd 能夠通過 mdns 在節(jié)點之間傳輸 gpnp profile 文件。

2） gpnpd 守護進程被啟動， gpnpd 開始讀取本地節(jié)點的 gpnp profile ，之后和遠程節(jié)點的 gpnpd 守護進程通信，以便獲得集群中最新的 gpnp profile 信息。

3） gpnpd 啟動完畢，向本地節(jié)點的其他集群初始化資源提供 gpnp profile 服務。

4） gipcd 守護進程被啟動，從 gpnpd 守護進程獲得集群的私網(wǎng)信息，并和遠程節(jié)點的 gpipcd 守護進程通信，最后開監(jiān)控本地節(jié)點的私網(wǎng)。

5） cssdagent 代理進程啟動 ocssd.bin 守護進程。

6） cssdmonitor 守護進程啟動，并開始監(jiān)控 ocssd.bin 守護進程的狀態(tài)。

在整個過程中，可能導致集群的 bootstrap 過程無法成功的主要原因如下。

原因 1 ：集群中有其他的 mdns 軟件運行，這會導致 GI 的 mdnsd 服務無法正常工作。

原因 2 ： gpnp profile 文件中的信息出現(xiàn)錯誤，這會導致集群的 bootstrap 過程無法完成。

[grid@ebsdb1 peer]$ gpnptool get

或

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

原因 3 ：節(jié)點之間的網(wǎng)絡通信存在問題，這會導致 gpnp profile 無法正常傳輸。

原因 4 ： gpnp 的一些線程被掛起，這會導致 gpnpd 守護進程無法成功完成啟動任務。

原因 5 ：集群的私網(wǎng)網(wǎng)卡出現(xiàn)問題，這會導致 gipcd 無法和其他節(jié)點的 gipcd 進行通信或者集群沒有可用的私網(wǎng)進行通信。

原因 6 ： gipcd 存在問題，這會導致它錯誤地認為集群私網(wǎng)網(wǎng)卡存在問題。

原因 7 ：以上守護進程的套接字文件丟失。

對應的解決方法如下。

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

方法 2 ：如果 gpnp profile 只是在集群的某一個節(jié)點上出現(xiàn)了錯誤，可以從集群的其他節(jié)點將其復制過來。如果集群所有幾點的 gpnp pfile 都出現(xiàn)了問題，那么就需要使用 gpnp 工具來進行修正。

下面的例子演示了如何使用 gpnp tool 修改 gpnp profile 中集群的私網(wǎng)信息。

1）   檢查當前的 gpnp profile ，確認 gpnpd 能夠通過 mdns 找到集群的其他節(jié)點。

[grid@ebsdb1 peer]$ gpnptool get

[grid@ebsdb1 peer]$ gpnptool find

2）   創(chuàng)建一個工作路徑以用于編輯 gpnp profile

mkdir /home/grid/gpnp

export GPNPDIR=/home/grid/gpnp

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

3）   創(chuàng)建一個用于修改的 gpnp profile 副本

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

4）   查看 gpnp profile 的序列號和私網(wǎng)信息

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

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

5）   修改集群私網(wǎng)的網(wǎng)卡信息

gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=< 當前序列號 +1> -net< 私網(wǎng)編號 >:net_ada=< 私網(wǎng)網(wǎng)卡名 >

例如：

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 推送到集群的其他節(jié)點

gpnptool find -c=< 集群名 >

gpnptool rget -c=< 集群名 >

方法 3 ：確認件私網(wǎng)通信正常（例如：使用 ping 、 traceroute 等命令確認集群私網(wǎng)的連通性）

方法 4 ：在操作系統(tǒng)層面重新啟動 gpnp 守護進程，例如： kill -9 <gpnp 進程 ID>

當 gpnpd 守護進程被總之之后，對應的 ohasd 代理進程 oraagent 會及時發(fā)現(xiàn)這一情況，并啟動新的 gpnpd 守護進程。

方法 5 ：確認集群私網(wǎng)通信正常（例如：使用 ping 、 traceroute 等命令確認集群私網(wǎng)的連通性）

方法 6 ：在操作系統(tǒng)層面重新啟動 gipcd 守護進程，例如： kill -9 <gipcd 進程 ID>

當 gipcd 守護進程被總之之后，對應的 ohasd 代理進程 oraagent 會及時發(fā)現(xiàn)這一情況，并啟動新的 gipcd 守護進程。

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

crsctl stop crs

crsctl start crs