懷疑私網網卡多播問題導致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 步驟。

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

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