懷疑私網網路卡多播問題導致crs無法正常啟動

一個 rac 只能啟動一個節點 crs 的問題，目前懷疑是多播問題造成。

前幾日在歷史庫測試 PSU 升級，在完成一個節點軟體升級後對第二節點 GI 進行升級時， CRS 可以正常成功關閉，之後報出了 Error : The opatch Applicable check failed ，於是嘗試重新啟動 CRS ，但很明顯 CRS 無法正常啟動。

 

透過日誌檢視，發現 CRS-5818:Aborted command 'start' for resource 'ora.cssd'. 在啟動 CSSD 資源無法成功，並且從當前的程式情況可以確認 CSS 存在問題。

於是從當時的 CSSD 日誌可以看出， CSSD 在啟動時，在準備與遠端節點的過程中建立本地通訊介面時失敗了，具體的日誌分析如下：

 

1. 從 gpnp profile 中獲取叢集的私網資訊。

2. 以下開始準備和遠端節點通訊，並 created local interface for node 'nghis-db2', 但在進行繫結 endpoint (localAddr 'mcast://224.0.0.251:42424/192.169.1.40') 失敗了，該本地地址為一個 mcast 地址。

當時看到 No buffer space available (74) ，認為是懷疑是 udp_sendspace 和 udp_recvspace 不夠大，查詢發現分別為 65536 和 655360 ，這實際應用是足夠了。不出意料，將該兩個引數調大之後重啟 CRS 依然無法解決，而在 MOS 上關於該錯誤的大部分都指向了 BUG,11gR2 Grid Infrastructure Node May not Join the Cluster After Evicted With Error sgipcnUdpSend "No buffer space available (74)" ( 文件 ID 1352887.1) 。

但當前的現象與該文件描述不符合，

當前的操作是 sgipcnMctBind

文件中的是 sgipcnUdpSend

 

3. 更新介面狀態，依然無法建立本地介面，即無法與遠端節點通訊，於是執行了 disable interface 並 clean disabled insterface

4. 重新開始 add interface ，但仍然失敗。

 

5. 之後連續每隔 1 分鐘報出了 has a disk HB, but no network HB ，說明此時私網上應該出現了聯通性的故障。

 

於是我們測試了私網地址的聯通是否有問題，使用 traceroute 檢查，然而並沒有聯通性問題。

於是就很不理解了，在心跳網路卡既然沒有問題，為何無法檢測到網路心跳。此時問題應該還是出現在以上出現 No buffer space available (74) 的 gipcmodNetworkProcessBind 的過程，對比了節點 1 正常啟動 gipchaWorkerCreateInterface 的過程，一共新增了 4 個地址：

1. udp://192.169.1.39:13034    ------ 私網地址

2. mcast://224.0.0.251:42424/192.169.1.39 ----- 多播地址

3. mcast://230.0.1.0:42424/192.169.1.39  ----- 多播地址

4. udp://192.169.1.127:42424         ------- 廣播地址

很明顯節點 2 在以上的過程中應該是在新增第二個地址，多播地址 mcast://224.0.0.251:42424/192.169.1.40 時出現了問題。

透過多播檢測工具檢測私網網路卡的多播地址聯通性，發現都是檢測失敗，而測試節點 1 的是成功的，於是懷疑問題應該是出現在節點 2 的多播地址上。

 

有懷疑是 HAIP 問題，於是嘗試將 HAIP disable 掉，並將私網網路卡上的 169 ip 依然無法解決。

禁止 haip 命令：

oracle/app/11.2.0.4/grid/bin/crsctl  modify res ora.cluster_interconnect.haip -attr "ENABLED=0" -init

最後同事提議使出殺手鐧 --- 重啟主機，由於這套庫是歷史庫，沒有實時的業務，確定無影響後就進行了重啟主機，重啟主機後 CRS 能正常啟動， CSS 也正常透過過了 gipchaWorkerCreateInterfac 步驟。

 

再次檢測私網網路卡的多播地址聯通性，這次是成功了。

至此，問題解決了，但因為是透過重啟主機解決，始終感覺這並不是最終的原因。多播檢測不通，是否意味著網路確實是存在問題？這點也不敢斷論。