料號：00Y5860 / 00RY384（IBM Storwize V5000 節點控制器）
八月初的一個下午，某數據中心的報障電話打過來，描述得很含糊：
「系統沒斷，但特別慢。」
儲存網上，卷都在，主機能讀能寫，沒有任何業務中斷告警。可前台點一下要等好幾秒，數據庫那邊隊列越排越長。
查主機、查多路徑、查交換機、查數據庫執行計劃——一圈下來什麼都沒查出來。
最後有人去機房看了一眼儲存櫃：兩塊節點控制器，其中一塊亮着故障燈。
為什麼少一塊控制器，會慢一百倍
V5000 的控制櫃裏有兩塊節點控制器，雙活。設計上壞一塊業務不中斷——這沒錯，業務確實沒中斷。
但還有一半的故事：
寫數據進來的時候，為了保證掉電或者單點故障時不丟數據，寫緩存必須在兩塊控制器之間做鏡像。一份寫在本節點，一份鏡像到夥伴節點，兩邊都落定了才告訴主機「寫完了」。
現在一塊控制器下線了，鏡像做不了。系統不可能拿只有一份、沒有冗餘的髒數據去冒險，所以它做了一個保守的選擇：
直接關掉寫緩存，每個寫操作直接落到後端磁碟，落完才返回。
於是寫延遲不再由記憶體決定，而是由硬碟決定。亞毫秒變成幾十毫秒——一百倍的差距就是這麼來的。
這不是故障擴散，是設計使然。系統在用性能換數據安全。
真正要緊的是另一件事
此時冗餘已經歸零。剩下那塊控制器再出問題，業務就真的停了。
所以單控運行狀態必須按小時計算響應時效，不能按天。很多人被「業務還在跑」麻痹，把它當成一個不緊急的工單——那是在裸奔。
換件時才發現的三個坑
一、零件基本都不含電池。 市面流通的 00Y5860 絕大多數是裸 canister，商品標題裏常常直接寫着 without Battery。V5000 的控制器裏有獨立電池負責掉電保護緩存。是裸件的話，現場就要把舊件上的電池拆下來移裝——這一步不提前確認，人和件都到了機房，活幹不下去。
二、固件版本要對得上。 新控制器插進去，如果代碼級別和網上那塊不一致，它不會直接上線，而是停在服務狀態等待。正常機制是由網上的夥伴節點把系統軟件推給它，自動同步。這個過程需要時間，別以為插上幾分鐘沒上線就是零件壞了。
三、這條是好消息：系統身份不在控制器裏。 WWNN 和集羣配置存放在控制櫃的背板上。換一塊新控制器，它會從機框讀取身份，主機側看到的 WWNN 不變——不需要重做集羣配置，也不需要在主機側重新分區。這能省掉大量協調成本。
還有一條鐵律
任何情況下，不能把兩塊節點控制器同時拔出來。
剩下那塊是此刻唯一在跑業務的節點。這句話看着像廢話，但在兩塊都需要檢查的時候，是真的有人會犯。
一個建議
監控要監控「性能」，不只監控「可用性」。
只監控儲存在不網上，這類故障會被完全漏掉——它一直網上。應該同時監控捲的寫延遲和緩存狀態，延遲突變本身就是最靈敏的告警。
文中的架構行為依據 IBM Storwize V5000 的公開資料整理；具體到某台設備的節點錯誤碼和處理動作，請以現場服務助手裏讀到的實際資訊為準。案例細節做過合併與匿名化處理。
手上有 V5000 相關料號需要核對配置或庫存的，可以直接留料號。
七小服 SEVEN SMALL SERVICES http://www.sevensmallservices.com · 微信 qixiaofu-com