背景與核心爭議
Oracle RAC 的 Interconnect（集群心跳與緩存融合網絡）物理連接方式直接影響集群高可用性。兩種方案：
- 交換機連接：兩節點各通過網線接入同一交換機。
- 直連：兩節點網卡直接用網線相連，無交換機。
社區討論核心觀點：
觀點 A（biti）：直連存在腦裂風險
- 交換機模式：拔掉節點 A 網線，交換機端口 Down，節點 B 感知鏈路正常，A 感知故障 → B 繼續服務，A 自動下線，符合預期。
- 直連模式：網線故障導致雙方網卡鏈路狀態同時異常，OS 向 Oracle 回報「雙方網卡均不正常」 → 可能觸發雙節點同時下線（腦裂），服務全中斷。
觀點 B（kamus）：9i RAC 有主備節點機制
- 9i RAC 按啟動順序區分 Primary/Secondary 節點。
- Interconnect 故障時，RAC 通過競爭機制下線 Secondary，保留 Primary 存活。
- 腦裂現象多見於無 Quorum Disk 的傳統集群（如串口通訊的 HACMP），RAC 有投票磁盤機制。
觀點 C（支持 biti）：競爭機制與 OS 通知延遲
- Interconnect 故障時，Oracle 啟動競爭機制決定哪個實例下線。若下線的是正常節點，導致雙雙下線。
- 9i 引入等待機制：競爭前等待 OS 通知網卡狀態。超時前收到通知 → 下線故障節點；否則進入競爭。
- 交換機模式：OS 通常能及時感知端口 Down，通知 Oracle，保留正常節點（但仍有 OS 通知延遲導致雙下線風險）。
- 直連模式：雙方網卡狀態同時異常，OS 無法區分 → 必然進入競爭 → 高概率雙下線。
技術原理深度解析
1. Oracle RAC 故障檢測機制
- 心跳網絡：Interconnect 傳輸心跳包，默認 1 秒間隔，超時通常 30-60 秒（參數
_crs_misscount 控制）。
- 網卡狀態感知：Oracle 依賴 OS 提供的網卡鏈路狀態（Link Status）。交換機模式下，交換機端口 Down 即通知 OS；直連模式下，對端網卡 Down 或網線斷開，本端網卡鏈路也會 Down。
- I/O Fencing / Voting Disk：存儲層面的仲裁機制，防止腦裂。即使雙節點心跳中斷，只有獲得投票磁盤多數票的節點才能繼續服務。
2. 直連模式的實際風險
- 單點故障：網線、網卡、驅動程序故障直接導致心跳中斷。
- 無法區分「對端故障」與「本端故障」：雙方同時感知 Link Down。
- 依賴投票磁盤仲裁：若存儲網絡同時故障，極端情況下可能雙雙失去仲裁 → 服務不可用。
3. 交換機模式優勢
- 獨立故障域：單節點網卡/網線故障不影響另一節點鏈路狀態。
- 可擴展性：輕鬆擴展到 3+ 節點叢集。
- 可管理性：交換機提供端口監控、VLAN 隔離、QoS 保障 Interconnect 流量優先級。
- 生產環境最佳實踐：Oracle 官方文檔、MaaS 最佳實踐均推薦專用交換機。
生產環境建議配置
- 專用交換機：至少雙交換機冗余（雙平面），每節點雙網卡分別接入兩台交換機，配置 Bonding/Teaming 或 Oracle HAIP (Highly Available IP)。
- 獨立 VLAN：Interconnect 流量隔離，避免與業務/管理流量爭用帶寬。
- Jumbo Frames (MTU 9000)：減少 CPU 開銷，提升緩存融合傳輸效率。
- 監控告警：監控交換機端口狀態、錯誤計數器、延遲、丟包率；OS 層監控網卡 Link 狀態、驅動錯誤。
- 定期測試：計劃性拔網線/關交換機端口演練，驗證故障切換時間與業務影響。
結論
強烈建議生產環境使用專用交換機（雙平面冗余）。直連僅適合開發/測試環境或極簡兩節點 PoC，且必須配置可靠的投票磁盤並充分測試故障場景。交換機方案雖增加硬件成本，但顯著降低腦裂風險，提升可管理性與擴展性，是企業級 RAC 部署的標準選擇。
