Oracle教程：如何診斷節點重啟問題

本文對如何診斷RAC環境中節點重啟問題進行了介紹。適用於10gR2和11gR1.

首先我們對能夠導致節點重啟的CRS進程進行介紹。
1.ocssd : 它的主要功能是節點監控（Node Monitoring）和組管理(Group Management),它是CRS的核心進程之一。節點監控是指監控叢集中節點的健康，監控的方法是通過網路心跳(network heartbeat)和磁碟心跳（disk heartbeat）實現的，如果叢集中的節點連續丟失磁碟心跳或網路心跳，該節點就會被從叢集中驅逐，也就是節點重啟。組管理導致的節點重啟，我們稱之為node kill escalation（只有在11gR1以及以上版本適用）,我們會在後面的文章進行詳細介紹。重啟需要在指定的時間（reboot time,一般為3秒）內完成。

網路心跳:ocssd.bin進程每秒鐘向叢集中的各個節點通過私網發送網路心跳資訊，以確認各個節點是否正常。如果某個節點連續丟失網路心跳達到閥值，misscount（預設為30秒，如果存在其他叢集管理軟體則為600秒），叢集會通過表決盤進行投票，使丟失網路心跳的節點被主節點驅逐出叢集，即節點重啟。如果叢集只包含2個節點，則會出現腦裂，結果是節點號小的節點存活下來，即使是節點號小的節點存在網路問題。

磁碟心跳：ocssd.bin進程每秒鐘都會向所有表決盤（Voting File）註冊本節點的狀態資訊，這個過程叫做磁碟心跳。如果某個節點連續丟失磁碟心跳達到閥值，disk timeou(一般為200秒)，則該節點會自動重啟以保證叢集的一致性。另外，CRS只要求[N/2]+1個表決盤可用即可，其中N為表決盤數量，一般為奇數。

2.oclsomon：這個進程負責監控ocssd是否掛起，如果發現ocssd.bin存在效能問題，則重啟該節點。
3.oprocd：這個進程只在Linux和Unix系統，並且第三方叢集管理軟體未安裝的情況下才會出現。如果它發現節點掛起,則重啟該節點。

注意：以上的所有進程都是由指令碼init.cssd產生的。

接下來是診斷節點重啟問題是經常搜集的資訊。
1．作業系統日誌
2．<crs主目錄>/log/<節點名稱>/cssd/ocssd.log
3．oprocd.log(/etc/Oracle/oprocd/*.log.* 或 /var/opt/oracle/oprocd/*.log.*)
4．<crs主目錄>/log/<節點名稱>/cssd/oclsomon/oclsomon.log
5. Oracle OSWatcher 報告

接下來我們討論如何診斷節點重啟問題。
1．由ocssd導致的節點重啟。
如果在ocssd.log中出現以下錯誤，則表示節點重啟是由於丟失網路心跳。接下來需要查看和網路相關的資訊，如作業系統日誌，OSW報表（traceroute的輸出），以確定網路層面（cluster interconnect）是否存在問題，並確定最終的原因。
[ CSSD]2012-03-02 23:56:18.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 50% heartbeat fatal, eviction in 14.494 seconds
[ CSSD]2012-03-02 23:56:25.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 75% heartbeat fatal, eviction in 7.494 seconds
[ CSSD]2012-03-02 23:56:32.749 [3086] >WARNING: clssnmPollingThread: node <node_name>at 90% heartbeat fatal, eviction in 0.494 seconds
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE:   clssnmPollingThread: Eviction started for node <node_name>, flags 0x040d, state 3, wt4c 0
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE:   clssnmDiscHelper: <node_name>, node(4) connection failed, con (1128a5530), probe(0)
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE:   clssnmDiscHelper: node 4 clean up, con (1128a5530), init state 5, cur state 5
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE:   clssnmDoSyncUpdate: Initiating sync 196446491
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE:   clssnmDoSyncUpdate: diskTimeout set to (27000)ms

注意：如果在主節點的ocssd.log中出現以上資訊的時間點要晚於節點的重啟時間，則說明節點重啟的原因不是丟失網路心跳。

如果ocssd.log中出現以下錯誤，則表示節點重啟是由於丟失磁碟心跳。接下來需要查看作業系統日誌，OSWatcher報告（iostat的輸出），以確定i/o層面是否存在問題，並確定最終的原因。
2010-08-13 18:34:37.423: [    CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:34:37.423: [    CLSF][150477728]Opened hdl:0xf4336530 for dev:/dev/sdb8:
2010-08-13 18:34:37.429: [   SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error
Additional information: 4
Additional information: 720913
Additional information: -1)
)
2010-08-13 18:34:37.429: [    CSSD][150477728](:CSSNM00060: )clssnmvReadBlocks: read failed at offset 17 of /dev/sdb8
2010-08-13 18:34:38.205: [    CSSD][4110736288](:CSSNM00058: )clssnmvDiskCheck: No I/O completions for 200880 ms for voting file /dev/sdb8)
2010-08-13 18:34:38.206: [    CSSD][4110736288](:CSSNM00018: )clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################
2010-08-13 18:34:38.206: [    CSSD][4110736288]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################

2. 由oclsomon導致的節點重啟。
如果在oclsomon.log 中出現錯誤，則表示節點重啟是由於ocssd進程掛起，由於ocssd進程擁有即時（RT）優先順序，很可能此時作業系統存在資源（如cpu）競爭，接下來需要察看作業系統日誌，OSW報表（vmstat，top的輸出），以確定最終的原因。

3．由oprocd導致的節點重啟。
如果在oprocd日誌中出現以下資訊，則表明節點重啟是由oprocd進程導致。

Dec 21 16:15:30.369857 | LASTGASP | AlarmHandler:  timeout(2312 msec) exceeds interval(1000 msec)+margin(500 msec).   Rebooting NOW.

由於oprocd進程通過查看系統時間以確定作業系統是否掛起，正確的配置ntp（或其他時間同步軟體），調整diagwait=13 可以避免節點重啟，另外，如果需要大幅度修改系��時間，建議首先停止CRS，在修改完成之後再重新啟動。當然，我們也不排除作業系統掛起導致oprocd重啟節點，所以，也需要查看OSWatcher報告（vmstat，top的輸出），以確定最終的原因。

本文只是對診斷節點重啟問題的思路進行了介紹，在具體實際問題當中還需要靈活運用。

關於更多的資訊，請閱讀以下的MOS 文章。
Note 265769.1 ：Troubleshooting 10g and 11.1 Clusterware Reboots
Note 1050693.1 ：Troubleshooting 11.2 Clusterware Node Evictions (Reboots)