第十六回 個人經驗：幾家 Storage 遇過最常見的幾個問題，以EMC 和 IBM 為例

EMC 這家儲存設備廠商所製造的各個型號的 Storage ，在效能和穩定度上的水準一直是不錯的，平台支援度也挺完整的，不過就我常遇到的 CX 等級的機器，其實是有一些問題存在，不過這些問題其實也是個瑕不掩瑜的問題。

首先無論在哪個 Storage 平台都一樣，在安裝之前，請務必參考該 Storage 提供的 Checklist 仔細核對你要使用的平台的作業系統版本及對應的 MultiPath 驅動程式的版本和必須安裝的 Patch 及平台配合需調整的參數，才能在使用時，將問題降到最低。

狀況一：Storage 陷入不明的 Busy 狀態，造成 CPU Load 增加，因為全部都在 I/O Wait 狀態，Application Hang 住，之前就是平台驗證未做好，相對的參數也沒對應好，有過到類似的狀況。後來將 Patch Level 更新後，就沒發生過類似狀況。

另外第二點，既然是 Multipath 的狀態下，請注意你的路徑安裝的方式及 Storage 提供的 MultiPath 使用方式，EMC 的 CLARiiON 及 Symmetrix 的 MultiPath 使用方法是不太一樣的，就如同 IBM 在 DS4 和 DS8 的 MultiPath 亦是不同，所以在 Zoning 和接線方式是要注意的，以免你的 Path 亂掉造成 Storage Controller 誤判而將控制權自行更動。

狀況二：在 IBM DS4 系列曾遇到安裝的工程師在調整 SAN Switch 設定時，接光纖線接錯，造成某張光纖卡故障時，Controller 誤判一直在做切換動作，剛好所屬的 LUN 是在 Cluster 架構下，使得所有同時 Access 到該組 LUN 的 Server 的路徑一起也被切換，使得 I/O 一直不停的 Busy 。因為為了處理這個問題我曾不小心將某全球雙 A 品牌之一的 Mail Server 關閉了半個小時後才回復。

狀況三：在 EMC CX 比較常見，在Disk 被Access 的狀態下，如果突然所有線路直接被拔除，不是瞬斷馬上恢復那種，是真的實體線路連接斷線時，CX 的 Powerpath 下所屬的那個 Path 的 Disk 有非常大的機會會被 Controller Lock 住，此時會有一種狀況，該 Disk 就算線路己經連接回來，你仍然無法使用該 Disk ，有時在 Navigator 下面就可以看到該磁碟的狀況是有些異常的，通常將該 Disk Unassign 再 Assign 後會回復正常，但少數狀況可能需要將目地端主機設備重開，這個問題我在 AIX 上面連接 EMC CX 時經常遇到。

CLARiiON系列的MetaLun在很多場合真的是非常好的一項特性，尤其是原本就有 LVM 架構下的 AIX ，更是強大，幾乎可以不需花費什麼風險就任意的將一個 Disk 放大，不像 DS4 系列號稱可以如此，但是卻是必須要連續空間才有辦法如此使用。

另外 CLARiiON 的前五顆 DISK ，預設是放置 Flare Code OS 用的，這五顆 Disk 內置了整座 CX 的設定及作業系統，系統預設當這五顆 Disk 其中有一顆發生損壞時，是非常危急的一件事，預設第一件事就是要通知所有的人，所以當這五顆 Disk 其中有一顆發生損壞時，就會將 Write Cache 關閉，Write Cache 一關閉，所有接續在本座 CX 儲存設備的系統主機的效能馬上就會陷入無比的低落。

狀況四：EMC CX 系列的前五顆硬碟，只要損壞其中一顆，預設 Controller 的 Write Cache 就會被關閉，此時在使用這個子儲存系統的主機都會發現效能變差，當然在尚未修復前可以透過設定將 Write Cache 再度啟動，讓系統效能恢復，不過 Flare Code OS 所屬的 Disk 故障務必儘速報修將之修復，以免發生遺憾的事情。

狀況五：非常類似 EMC 狀況三的情形，在其他家 Storage 也是會發生的，在 IBM 過去的 ESS 系列，也就是 SHARK 和 DS8000 上面使用 SDD 時會有類似情形，就是當有個 LUN 原本是屬於某個系統存取時，忽然該系統被關閉，緊急改用另一個作業系統接手，而你又未將 LUN 設定在這兩個作業系統都可存取，僅是後來才變更設定，該 LUN 就會被第一個 Access 的作業系統鎖住。在 DS8000 和 ESS 下的 SDD 有個工具叫 lquerypr 可以將這個 Lock 解除。相對的其他廠商也會有類似的工具可以處理類似的問題。