懷疑私網(wǎng)網(wǎng)卡多播問(wèn)題導(dǎo)致crs無(wú)法正常啟動(dòng)

一個(gè) rac 只能啟動(dòng)一個(gè)節(jié)點(diǎn) crs 的問(wèn)題，目前懷疑是多播問(wèn)題造成。

前幾日在歷史庫(kù)測(cè)試 PSU 升級(jí)，在完成一個(gè)節(jié)點(diǎn)軟件升級(jí)后對(duì)第二節(jié)點(diǎn) GI 進(jìn)行升級(jí)時(shí)， CRS 可以正常成功關(guān)閉，之后報(bào)出了 Error : The opatch Applicable check failed ，于是嘗試重新啟動(dòng) CRS ，但很明顯 CRS 無(wú)法正常啟動(dòng)。

通過(guò)日志查看，發(fā)現(xiàn) CRS-5818:Aborted command 'start' for resource 'ora.cssd'. 在啟動(dòng) CSSD 資源無(wú)法成功，并且從當(dāng)前的進(jìn)程情況可以確認(rèn) CSS 存在問(wèn)題。

于是從當(dāng)時(shí)的 CSSD 日志可以看出， CSSD 在啟動(dòng)時(shí)，在準(zhǔn)備與遠(yuǎn)程節(jié)點(diǎn)的過(guò)程中創(chuàng)建本地通信接口時(shí)失敗了，具體的日志分析如下：

1. 從 gpnp profile 中獲取集群的私網(wǎng)信息。

2. 以下開始準(zhǔn)備和遠(yuǎn)程節(jié)點(diǎn)通信，并 created local interface for node 'nghis-db2', 但在進(jìn)行綁定 endpoint (localAddr 'mcast://224.0.0.251:42424/192.169.1.40') 失敗了，該本地地址為一個(gè) mcast 地址。

當(dāng)時(shí)看到 No buffer space available (74) ，認(rèn)為是懷疑是 udp_sendspace 和 udp_recvspace 不夠大，查詢發(fā)現(xiàn)分別為 65536 和 655360 ，這實(shí)際應(yīng)用是足夠了。不出意料，將該兩個(gè)參數(shù)調(diào)大之后重啟 CRS 依然無(wú)法解決，而在 MOS 上關(guān)于該錯(cuò)誤的大部分都指向了 BUG,11gR2 Grid Infrastructure Node May not Join the Cluster After Evicted With Error sgipcnUdpSend "No buffer space available (74)" ( 文檔 ID 1352887.1) 。

但當(dāng)前的現(xiàn)象與該文檔描述不符合，

當(dāng)前的操作是 sgipcnMctBind

文檔中的是 sgipcnUdpSend

3. 更新接口狀態(tài)，依然無(wú)法創(chuàng)建本地接口，即無(wú)法與遠(yuǎn)程節(jié)點(diǎn)通信，于是執(zhí)行了 disable interface 并 clean disabled insterface

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

5. 之后連續(xù)每隔 1 分鐘報(bào)出了 has a disk HB, but no network HB ，說(shuō)明此時(shí)私網(wǎng)上應(yīng)該出現(xiàn)了聯(lián)通性的故障。

于是我們測(cè)試了私網(wǎng)地址的聯(lián)通是否有問(wèn)題，使用 traceroute 檢查，然而并沒(méi)有聯(lián)通性問(wèn)題。

于是就很不理解了，在心跳網(wǎng)卡既然沒(méi)有問(wèn)題，為何無(wú)法檢測(cè)到網(wǎng)絡(luò)心跳。此時(shí)問(wèn)題應(yīng)該還是出現(xiàn)在以上出現(xiàn) No buffer space available (74) 的 gipcmodNetworkProcessBind 的過(guò)程，對(duì)比了節(jié)點(diǎn) 1 正常啟動(dòng) gipchaWorkerCreateInterface 的過(guò)程，一共添加了 4 個(gè)地址：

1. udp://192.169.1.39:13034    ------ 私網(wǎng)地址

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         ------- 廣播地址

很明顯節(jié)點(diǎn) 2 在以上的過(guò)程中應(yīng)該是在添加第二個(gè)地址，多播地址 mcast://224.0.0.251:42424/192.169.1.40 時(shí)出現(xiàn)了問(wèn)題。

通過(guò)多播檢測(cè)工具檢測(cè)私網(wǎng)網(wǎng)卡的多播地址聯(lián)通性，發(fā)現(xiàn)都是檢測(cè)失敗，而測(cè)試節(jié)點(diǎn) 1 的是成功的，于是懷疑問(wèn)題應(yīng)該是出現(xiàn)在節(jié)點(diǎn) 2 的多播地址上。

有懷疑是 HAIP 問(wèn)題，于是嘗試將 HAIP disable 掉，并將私網(wǎng)網(wǎng)卡上的 169 ip 依然無(wú)法解決。

禁止 haip 命令：

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

最后同事提議使出殺手锏 --- 重啟主機(jī)，由于這套庫(kù)是歷史庫(kù)，沒(méi)有實(shí)時(shí)的業(yè)務(wù)，確定無(wú)影響后就進(jìn)行了重啟主機(jī)，重啟主機(jī)后 CRS 能正常啟動(dòng)， CSS 也正常通過(guò)過(guò)了 gipchaWorkerCreateInterfac 步驟。

再次檢測(cè)私網(wǎng)網(wǎng)卡的多播地址聯(lián)通性，這次是成功了。

至此，問(wèn)題解決了，但因?yàn)槭峭ㄟ^(guò)重啟主機(jī)解決，始終感覺(jué)這并不是最終的原因。多播檢測(cè)不通，是否意味著網(wǎng)絡(luò)確實(shí)是存在問(wèn)題？這點(diǎn)也不敢斷論。