【運維實戰】Dell PowerScale OneFS 9.12 SupportAssist 斷線排障全紀錄：從原廠卡關到打通 L3 雙向路由
📚 延伸閱讀：相關技術系列
底層基礎架構異常排查：回顧我們之前處理 VMware ESXi (CVE-2018-3646) 的紫屏修復紀錄，掌握虛擬化與硬體交界的除錯細節。 點此閱讀
【運維實戰】Dell PowerScale OneFS 9.12 SupportAssist 斷線排障全紀錄：從原廠卡關到打通 L3 雙向路由
在企業級儲存環境中，各種跨網段、跨設備的連線障礙往往是系統工程師與網管的日常。本次任務是要解決叢集中的 Dell PowerScale Isilon SupportAssist 服務長期處於 Disconnected 的異常狀態。
這不是一個簡單的設定問題，這場戰役歷經了 Dell 二線工程師的卡關、防火牆日誌的深度挖掘、實體層的排查，甚至還要與 OneFS 9.12 版本中大改版的指令語法搏鬥。以下是毫無保留的完整排障實錄。
階段一：陷入死胡同的原廠設定與防火牆日誌反殺
事件的開端，是 Dell 原廠的二線工程師在遠端處理 SupportAssist 連線時卡關了。無論在 Isilon 介面上怎麼測試，封包就是無法成功回報至 Dell 後端的 SCG 伺服器，整個排障進度完全停滯。
當介面無法告訴我們真相時，唯一的解法就是從網路底層抓封包。我們決定不盲目修改 Isilon，而是直接登入 FortiGate 防火牆的 Log Server 尋找線索。
關鍵的錯誤日誌：
在茫茫的日誌中，我們精準捕捉到了來自 Isilon 節點 192.168.46.161 的異常流量。
- 目的地 IP：192.168.46.254（這是防火牆的本機介面 IP）
- 通訊埠口：9443
- 防火牆動作：Deny 或 Connection Refused（觸發了 Policy ID 0 隱含阻斷）
真相大白：這條日誌直接打臉了原先的設定邏輯。原來在之前的設定中，被誤將連線的目的地填成了網路閘道 IP。因為防火牆本機根本沒有跑 9443 服務，且這也完全不是通往 SCG 伺服器的正確路徑，所以封包在出門的第一站就被無情彈回。這個 9443 Refused 成為了我們推翻既有設定的最強證據。
階段二：回到物理層，排除 Cisco N7K 的隱患
在準備修正邏輯設定前，我們踩了個煞車。因為近期內部網路曾經有過跳線異動，部分節點通訊並不穩定，我們必須確保底層的實體鏈路是健康的。
我們登入核心交換器 Cisco Nexus 7000 進行排查。
- 首先執行 show interface brief 與 show log。
- 接著針對負責傳輸 SCG 流量的埠口 Eth104/1/5-8 進行觀察。
- 發現確實有部分埠口曾出現不穩定的 Link Flap 紀錄。經過機房端重新理線，並確認介面狀態穩固在 connected 後，我們才放心地回到邏輯層。
階段三：修正應用層設定與驚見路由黑洞
實體層穩固後，我們登入 Isilon 終端機，修正階段一發現的錯誤目的地。
將目的地指向真正的 SCG 伺服器 192.168.50.200 後，我們原以為大功告成，於是執行了 Netcat 測試。
封包又迷路了？我們敲下 netstat -4rn 攤開 IPv4 路由表，發現了極度嚴重的路由缺失問題。
- Isilon 的 Default Gateway 是一條指向 VLAN 45 的 mce2 介面。
- 但是，我們往 SCG 的流量必須從 VLAN 46 的 bge0 介面出去。
- 整個路由表中，完全找不到通往 192.168.50.x 的紀錄。這意味著系統根本不知道要把封包送往哪個閘道。
抉擇時刻：改預設路由對決新增靜態路由
當時我們面臨一個選擇：要不要直接去修改子網的優先級，把 VLAN 46 變成整台 Isilon 的預設路由？經過嚴密評估，我們否決了這個想法。因為 Isilon 上還有依賴 VLAN 45 的 WDA 業務，如果貿然更改預設路由，絕對會引發非對稱路由，導致現有服務大斷線。
結論很明確：我們必須補上一條靜態路由 Static Route。
階段四：與 OneFS 9.12 指令的慘烈搏鬥
既然知道要加路由，我們熟練地在終端機敲下指令，沒想到迎來的卻是 OneFS 9.12 的無情報錯。
回合一：
回合二，嘗試改變順序：
回合三，嘗試省略 groupnets：
山不轉路轉，切換至 Web GUI
新版 OneFS 9.12 對指令階層進行了大幅整併，與其在這裡跟語法死磕，我們果斷切換戰場，登入 Isilon Web GUI。
- 動作一：導航至 Cluster management 然後 Network configuration。
- 動作二：找到對應的 scg 子網點擊 View/Edit。
- 動作三：展開最下方的 Advanced settings。
- 動作四：找到 Static routes 欄位，順利填入 Destination 為 192.168.50.0/24，Gateway 為 192.168.46.254。我們特別選擇了網段而非單一 IP，以涵蓋未來 SCG 環境可能的備援機制。
按下 Save 後，再回去查 netstat -4rn，漂亮的 UGS 靜態路由紀錄終於出現了。
階段五：雙向打通與最終的成功連線
路由補足後，我們再度進行測試。
接著，配合網管端將 FortiGate 的 Policy 307 與 Policy 247 調整為雙向通訊，允許 Dell 後端能主動發起遠端支援連線。
到了最關鍵的 9443 埠口測試。
看到 succeeded 的那一刻，宣告了我們正式突破了最初在 Log Server 上看到的 Connection Refused 困境。
階段六：應用層重新握手與結案
網路層完全暢通後，我們需要讓 SupportAssist 重新發起註冊握手。當然，OneFS 9.12 的指令又變了，不再是 isi supportassist，而是整合進了 connectivity。
敲下最後的確認指令：
- ✅ 永遠相信底層的日誌：當介面說不通，且連原廠都卡關時，防火牆的 Deny 日誌就是最誠實的證人。
- ✅ 多網卡環境的路由思維：不要隨便更動 Default Gateway，善用 Static Route 才是避免業務大混亂的王道。
- ✅ 靈活應變版本差異：當終端機指令因為作業系統升級而頻繁報錯時，不要死鑽牛角尖，Web GUI 的 Advanced Settings 會是你最好的退路。
寫技術文章不容易，若這篇教學對您有幫助：
- 分享 給您的同事或社群
- 留言 讓我知道這篇文有用
- 回報 任何操作上的問題
留言
張貼留言