存儲區域網絡可能很復雜。如果管理不善時，情況更加嚴重。故障排除非常困難，因為很少有好的設計，而且光纖通道標準的寬松程度會使互操作性成為問題。

光纖通道(FC)存儲區域網絡已被iSCSI SAN取代，成為很多數據中心的塊存儲選擇。然而，盡管iSCSI是成本更低的替代方案、更易于管理，還可使用熟悉的以太網網絡技術，并且可以共享現有的LAN，但是當需要高性能塊存儲時，FC仍然是首選協議。因此，盡管出現其他替代方案，它仍然是大多數企業中重要的存儲替代方案。

對于FC SAN，重要的是要了解常見問題，以便弄清楚如何診斷和解決問題，或者首先是如何防止出現問題。

[[341908]]

常見問題

在復雜的存儲網絡中，很多事情都可能出錯。FC是從零開始構建，以支持網絡存儲系統，因此，對于管理，除了需要常規網絡知識，還需要大量的專業化知識。同時，還應注意，在過去的幾年中，通過自動化某些功能并減少LUN配置等的所需步驟，FC SAN供應商已經簡化陣列管理。

也就是說，保持FC SAN的性能仍然是一個挑戰，但是根據問題的不同，你可以將問題縮小到潛在的原因，以加快故障排除和解決的速度。主要常見問題包括以下：

1. 兼容性問題

盡管FC SAN已經存在近三十年，但并不是所有設備都能很好地兼容。我們經常會看到很多SAN問題源自不兼容的組件。所有存儲供應商都會發布某種形式的支持矩陣(通常稱為硬件兼容性列表(HCL))，其中他們會記錄存儲陣列微碼、SAN交換機固件和主機硬件/軟件的經過測試和受支持的配置。使用HCL以外的硬件或軟件，SAN可能會在一段時間內正常運行，但是這種做法存在風險，這會使故障排除性能問題變得更加困難。

2. 超出容量限制

顯然，飽和的SAN端口會導致瓶頸問題，而這些瓶頸問題可能會轉變成難以診斷的應用程序問題。通常，我們很容易查看SAN的主機或存儲端口，并確定它是否100%繁忙，但我們很難確定過載的交換機間鏈接(ISL)是否是問題根源。有時I / O本身不是瓶頸，而是限制問題(例如風扇比率-分區到存儲端口的主機總線適配器(HBA)的數量)-以及超過架構中交換機的數量，從而導致連接問題。

FC交換機供應商通常會提供軟件，以幫助檢測瓶頸問題，甚至可能提出解決方案。另外還有可用的第三方應用程序，例如SolarWinds系列產品、NetApp的OnCommand應用程序和用于SAN的IntelliMagic Vision，它們可以洞悉SAN的運行情況以跟蹤和緩解瓶頸。這些第三方工具通常支持多種不同的存儲品牌和型號，因此它們在混合供應商環境中可能特別有用。這類工具已經存在一段時間，最初統稱為存儲資源監視器;這些工具在開始時并沒有引起關注，因為它們很復雜，但現在它們已經精簡，并已增加功能和提高可用性。

3. 錯誤配置或分區

糟糕或不正確分區是SAN問題的最常見原因之一。也許是因為我們最經常更改SAN分區。這也可能很常見，因為區域包含那些棘手的16位十六進制全球通用名稱(WWN)。

4. 易出故障的連接和電纜

當光纖電纜發生故障時，似乎很少會完全失效。通常它們會出現間歇性問題，并緩慢失效。在這個過程中，應用程序和管理員會適應間歇性問題。由于大多數SAN環境支持多種電纜類型，這些問題可能會更加復雜，因此監控工具會有所幫助，它們可從各種電纜介質返回準確結果。

5. 存儲陣列配置問題

每個品牌的存儲陣列的管理方式略有不同，但是它們都基于一些基本概念。LUN必須通過前端SAN端口創建并分配給HBA。當存儲管理員在配置陣列時輸入錯誤時，經常會出現問題。手動創建LUN是繁瑣的過程，因此容易出錯。

6. 主機配置問題

服務器方面很容易出現問題。網絡環境中的服務器代表著SAN組件堆棧的很大部分，其中包括卷管理器、操作系統、多路徑軟件、HBA驅動程序、HBA固件和HBA硬件。所有組件都必須根據存儲供應商的規范進行配置;與供應商規范的任何偏差都可能導致問題。在大多數企業中，服務器虛擬化顯著增加運行服務器的數量。除了增加服務器配置問題外，由于有大量其他服務器，虛擬服務器可能還需要服務器管理員進行一些特殊設置。

7. SAN硬件故障

在常見的SAN問題中，硬件故障排在最后，這是因為，盡管它通常是我們關注的首要問題，但實際很少發生這種問題。現在的SAN硬件非常可靠，但硬件確實偶爾會出現故障。影響主機訪問的常見故障是SFP端口故障、端口卡故障和整個交換機故障。

8. 緩慢的存儲響應時間

存儲網絡是復雜的環境，其中包含很多組件，必須正確設置和仔細監視，但是性能問題也可能是由存儲設備本身引起。數據存儲介質將對整體SAN性能產生深遠影響。現在，大多數存儲陣列至少都包含SSD，因此，性能調整可能涉及切換到固態存儲或添加更多的SSD。如果很多應用程序都需要高性能，則可能需要使用全閃存陣列。如果你堅持使用僅硬盤驅動器的陣列，那么就需要擠出額外的性能，但傳統的調整(例如，短暫敲擊磁盤驅動器)可能會帶來額外的麻煩。

問題確定

當你對SAN進行故障排除時，你需要深入了解特定系統的所需配置和預期行為。當發生問題時，通過排除SAN、主機和存儲中正常運行的組件，可以更好地瞄準問題。

• SAN。最近是否發生SAN變更?詢問一下其他人員，檢查SAN日志，然后將正在運行的配置與文檔進行比較。SAN報告時間或錯誤是否相關?查找失效端口、最近端口注銷或架構重建。
• 主機。其他主機能否看到有問題的存儲?該主機能否看到其他存儲?HBA是否日志記錄在架構中?最近是否發生任何主機更改?主機的系統消息日志中是否有與SAN相關的消息?
• 存儲。其他主機能否看到有問題的存儲?存儲端口是否日志記錄到架構中?最近是否發生任何存儲更改?是否有存儲陣列日志報告錯誤?

如果使用變更管理軟件，則將顯著簡化上述所有檢查工作。變更管理應用程序還可以幫助提醒支持人員注意可能被孤立或不包含在備份操作中的任何服務器或數據存儲。

避免將來出現問題

檢查支持矩陣

請定期檢查存儲供應商的HCL和其他支持材料，以對比當前支持的內容與你的配置。并且，制造商不斷通過新代碼修復漏洞，你還應檢查是否有任何更新，并保持軟件版本最新和受支持-這將有助于避免很多問題。

(1) 記錄SAN

這個很重要。在解決問題時，了解原始的SAN環境設計意圖非常重要。請確保文檔記錄了主機、HBA、WWN及其連接位置。其中應包括存儲、存儲端口及其WWN。最后，SAN文檔應描述架構、ISL、區域集、區域和區域成員。

如果沒有原始設計文檔，則你應該能夠使用SAN管理或變更管理應用程序來發現和記錄所有網絡設備-而且，在很多情況下，還應該記錄關鍵配置信息，例如網絡地址。

(2) 基準化SAN性能

除非你記錄每天發生的事情，否則很難確定繁忙的端口是正常情況還是問題的罪魁禍首。請至少記錄SAN中每個端口的平均端口利用率。如果你使用SAN監視工具，則它可能可以做到這一點-實際上，在建立可接受的性能閾值后，當出現異常時，大多數監視應用程序都會發送電子郵件或文本警報。SAN監視應用程序還提供儀表板，以實時了解網絡狀態和單個網絡組件。

(3) 計劃你的變更

為避免管理員引起的中斷，請使用SAN文檔來定義變更，然后再進行變更。如果你在執行變更時才決定要做什么，那么你就錯了。而且，在變更發生后很容易忘記記錄變更。某些變更管理應用程序還將使你能夠進行“假設分析”，以測試預期的變更對SAN環境或與其連接的存儲系統的影響。

(4) 備份配置

在每天SAN變更后，請備份并安全地存儲交換機配置。當交換機出故障或在變更期間完全混亂，這將確保你可以從備份中快速回滾變更。為了更加安全，請配置備份應用程序，以在日常數據備份操作期間定期備份所有關鍵配置文件。

當某些事情在控制之中且網絡環境被很好地映射，解決SAN問題可能是相對容易的過程。 請將這些最佳做法作為日常SAN健康方案的一部分，以避免當出現故障時造成更大的問題。