淺談RAC -- 節點reboot問題的調查方法

淺談RAC – 節點reboot問題的調查方法

我們在上面的博文中介紹了CSS組件，今天我們繼續圍繞CSS組件的節點排除問題來總結一下常用的故障調查方法，

我們都知道CSS組件維護集群關系的兩個最重要的手段就是NHB和DHB，這也就意味著如果CSS組件的NHB和DHB的任何一個出現問題，都沒有辦法讓集群確認到各個節點的關聯資訊，那么CSS組件會被Abort掉，節點會被排除出集群，

1.丟失NHB

各個節點的CSS組件之間丟失NHB又可分為私網通信故障和節點夯兩個場景，

1.1 私網通信故障

我們以兩個節點node1和node2構成的RAC為例，當節點間的私網通信出現故障時，node1上的CSSD無法與node2上的CSSD通信，同時node2上的CSSD也無法與node1上的CSSD通信，所以在兩個節點的GI告警日志中都會分別列印出丟失NHB的資訊，最終其中一個子集群會被排除出集群，

例如在節點2上會列印如下資訊，

[OCSSD(9187)]CRS-1612: Network communication with node node1(1) has been missing for 50% of the timeout interval.  If this persists, removal ... from cluster will occur in xxxx seconds
[OCSSD(9187)]CRS-1611: Network communication with node node1 (1) has been missing for 75% of the timeout interval.  If this persists, removal ...  from cluster will occur in xxx seconds
[OCSSD(9187)]CRS-1610: Network communication with node node1 (1) has been missing for 90% of the timeout interval.  If this persists, removal ... from cluster will occur in xxxx seconds

同時在節點1上的GI告警日志中也會出現列印這樣的資訊，

如果我們查看被排除節點的CSSD的追蹤日志，就會發現CSSD因為丟失NHB而被Abort的資訊，

例如:

[CSSD]clssnmvDHBValidateNcopy: node 1, node1, has a disk HB, but no network HB, DHB has rcfg xxxx, wrtcnt, xxxx, LATS xxxx, lastSeqNo xxxx, uniqueness xxxx, timestamp xxxx
[CSSD]clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 2 nodes with leader 2, node2, is smaller than cohort of 2 nodes led by node 1, node1, based on map type 2
...
[CSSD]###################################
[CSSD]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread
[CSSD]###################################
[CSSD]clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

看到這里，其實我們就可以說大概率上來說是由于網路問題引起的了，為了佐證我們的判斷，這時候我們需要查看OS命令監控到的私網通信的資訊，很多朋友可能習慣性的去用ping命令來查看私網通信問題，這是非常不嚴謹的，因為在私網通信時可能存在丟包的現象，ping命令沒有問題，但是丟包現象卻能引起CSSD之間無法正確確認到NHB，所以我們在查看私網通信問題時往往使用的命令是netstat -s，比如查看netstat -s的以下專案是否有問題則是非常有幫助的，

“udpInOverflowsudpInOverflows”,“packet receive errors”, “fragments dropped” 或者 “outgoing packet drop”

另外GI重啟時都會去掃描/etc/oracle/lastgasp 或者 /var/opt/oracle/lastgasp的log，并將節點重啟的資訊列印到GI告警日志中，

1.2 節點夯

我們依然以兩個節點node1和node2構成的RAC為例，當node1夯住時，node2的CSSD無法與node1上的CSSD進行NHB，這時候node2的GI告警日志中依然會列印CRS-1612等與node1之間丟失NHB的資訊，但是節點1中，因為節點夯，所以CSSD被夯住而無法正常作業，所以節點1的GI告警日志中就不會輸出任何丟失NHB的資訊，那么最終節點1會被排除出集群，

這里面的節點夯其實也分為幾個場景，

1.2.1 OS資源不足造成CSSD無法作業，但是cssdagent或者cssdmonitor都還可以正常作業，這時候cssdagent或者cssdmonitor向CSSD發送LHB(local heart beat)時發生LHB丟失，這時候cssdagent或者cssdmonitor會將CSSD強制停止，那么在GI告警日志中會輸出掃描lastgasp 日志的資訊，

例如:

CRS-8011:reboot advisory message from host: node1, component: cssagent, with timestamp: xxxxxx

1.2.2 如果cssdagent和cssdmonitor都無法作業的時候，代表整個集群的任何行程都被夯住，這時候從GI的日志中已經無法查看到任何有用的資訊，我們只能從其它節點的GI日志去查看節點是否被集群排除掉的資訊，

當然，調查節點重啟時，查看GI的日志只是輔助的資訊，最侄訓是需要查看OS資源監測的資訊來確定，

2.丟失DHB

CSSD定期向共享磁盤上的投票盤發送DHB，Linux作業系統中，一般使用ioctl命令對投票盤進行IO操作，如果投票盤IO丟失時，在集群的告警日志中會有CRS-1615，CRS-1614，CRS-1613的告警資訊輸出，他們分別代表投票盤IO丟失時間超過了timeout值的50%, 75%, 90%，

CRS-1615:No I/O has completed after 50% of the maximum interval. Voting file "string" will be considered not functional in "number" milliseconds
CRS-1614:No I/O has completed after 75% of the maximum interval. Voting file "string" will be considered not functional in "number" milliseconds
CRS-1613:No I/O has completed after 90% of the maximum interval. Voting file "string" will be considered not functional in "number" milliseconds

當超過半數的投票盤的IO丟失都達到了設定的timeout值時，CSS會被abort，

ERROR: clssnmDiskPMT: Aborting, 2 of 3 voting disks unavailable
ERROR: ###################################
ERROR: clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
ERROR: ###################################

這個時候從OS的角度我們需要查看iostat命令的資訊來佐證上面的結果是否是一個真實的IO問題，

3.其他原因

除了丟失NHB和DHB造成CSSD被Abort之外，一些阻塞CSSD行程的配置或者命令也會造成節點重啟，比如在較低版本中，pstack命令會阻塞CSSD行程，另外THP(Transport Huge Page)也會阻塞CSSD行程，所以在RAC環境中，我們不能配置THP，

當然CSS上面也并不排除bug的存在，但是在高版本的RAC中，CSS上的bug幾乎已經看不到了，

4.關于OS資源監測工具

我們在調查GI問題時，OS資源監測資訊是特別重要的，甲骨文為我們提供了OSWatcher監測工具，所以在任何RAC環境中，安裝并運行OSWatcher則是非常必要的，有些用戶在出現問題時往往無法提供OS資源監測的任何資訊卻試圖通過GI日志來做結論性判斷其實是本末倒置，

如果RAC環境中沒有安裝OSWatcher的時候，有時候也可以使用CHMOS資訊來進行調查，CHMOS可以監控CPU,記憶體，網路通信等資訊，但是CHMOS只是對OSWatcher的一個補充工具，有時候無法替代OSW的作用，另外CHMOS的資訊也是有保存期限的，所以一旦出現reboot問題，如果想要通過CHMOS調查OS的資訊，要急時使用以下命令獲取CHMOS的資訊，

oclumon dumpnodeview -allnodes -v -s "start time" -e "end time" > /tmp/chm.log

今天先寫到這里，希望今天的內容能對關注RAC實戰的同學有所幫助，