存儲性能瓶頸的成因、定位與排查

介紹

企業數據存儲性能瓶頸常常會發生在端口，控制器和磁盤，難點在於找出引起擁塞的單元，往往需要應用多重工具以及豐富的經驗來查找並解決。

本文詳細闡述存儲瓶頸發生最常見的四種情況，可能發生的擁塞點，需要監控的參數指標，以及部署存儲系統的最佳實踐。

數據存儲瓶頸的四個常見場景：

以下是儲瓶頸發生最常見的四種典型情況：

1. 當多個用戶同時訪問某一業務應用，無論是郵件服務器，企業資源規劃（ERP）系統或數據庫，數據請求會累積在隊列中。單個I/O的響應時間開始增長，短暫延時開始轉變成為漫長的等待。
   這類響應時間敏感型應用的特征是，很多隨機請求，讀取比寫入更多，I/O較小。最好的方法是：將負載分布在多塊磁盤上，否則可能造成性能瓶頸。
   如果應用增加了更多用戶，或應用IOPS請求增加，則可能需要在RAID組中添加更多磁盤，或數據可能需要跨越更多磁盤，在更多層級做條帶化。
   存儲在這樣的情況下往往首先被懷疑，但大多數情況下並非存儲引發，原因可能在於網絡、應用或服務器。

2. 帶寬敏感型應用——如數據備份，視頻流或安全登錄，這類應用當多個用戶同時訪問大型文件或數據流時可能造成瓶頸。
   定位這一問題存儲管理員應當從備份服務器開始一路向下檢查至磁盤，原因可能存在於這一通路的任何地方。
   問題不一定發生在存儲，可能是由於備份應用創建的方式或是磁帶系統的工作方式引起的。如果瓶頸定位於存儲，那麼可能是由於服務I/O的磁盤數量不足，在控制器造成爭用，或是陣列前端口帶寬不足。
   性能調優需要針對不同應用程序負載來完成。針對大型文件和流數據的調優並不適合於小型文件，反之亦然。這也就是為什麼在大多數存儲系統中往往做一個平衡，需要用戶嘗試並找出系統的折中。用戶通常需要優化吞吐量或IOPS，但並不需要對兩者同時優化。

3. RAID組中的磁盤故障。特別是在RAID 5中會造成性能的下降，因為系統需要重建校驗數據。相比數據讀寫操作，重建會對性能造成更大影響。
   即便壞盤是造成故障的根源，但控制器還是可能成為瓶頸，因為在重建過程中它需要不停地服務數據。當重建完成時，性能才會恢復正常。

4. 部署了一種新的應用，而卷存在於處理繁忙郵件系統的同一磁盤。如果新的應用變得繁忙，郵件系統性能將會遭受影響。額外的流量最終會將磁盤完全覆蓋。

存儲瓶頸常發區域:

存儲區域網絡（Storage-area network, SAN）/陣列前端口

存儲部署於集中化SAN環境時，需考慮服務器和SAN之間的潛在網絡瓶頸。例如，運行多部虛擬機的整合服務器可能不具備支持工作負載要求的足夠網絡端口。添加網絡端口或轉移網絡密集型工作負載至其他服務器可解決這一問題。如前所述，對於帶寬集中型應用，需考慮NFS有多少Fiber Channel 端口, or iSCSI 端口 or Ethernet 端口，需要用戶站在帶寬的角度來考量整個架構。

可能發生的問題包括：

• 如果陣列中端口數量不夠，就會發生過飽和/過度使用。
• 虛擬服務器環境下的過量預定
• 端口間負載不均衡
• 交換機間鏈路爭用/流量負荷過重
• 如某一HBA端口負載過重將導致HBA擁塞。使用虛擬機會導致問題更加嚴重。

存儲控制器

一個標准的主動——被動或主動——主動控制器都有一個性能極限。接近這條上限取決於用戶有多少塊磁盤，因為每塊磁盤的IOPS和吞吐量是固定的。

可能出現的問題包括：

• 控制器I/O過飽和，使得從緩存到陣列能夠處理的IOPS受到限制
• 吞吐量“淹沒“處理器
• CPU過載/處理器功率不足
• 性能無法跟上SSD

Cache

由於服務器內存和CPU遠比機械磁盤快得多，需為磁盤添加高速內存以緩存讀寫數據。例如，寫入磁盤的數據存儲在緩存中直到磁盤能夠跟上，同時磁盤中 的讀數據放入緩存中直到能被主機讀取。Cache比磁盤快1000倍，因此將數據寫入和讀出Cache對性能影響巨大。智能緩存算法能夠預測你需要查找的 數據，你是否會對此數據頻繁訪問，甚至是將訪問頻繁的隨機數據放在緩存中。

可能發生的問題包括：

• Cache memory不足
• Cache寫入過載，引起性能降低
• 頻繁訪問順序性數據引起cache超負荷
• Cache中需要持續不斷地寫入新數據，因此如果cache總是在refill，將無法從cache獲益。

磁盤

磁盤瓶頸與磁盤轉速有關, 慢速磁盤會引入較多延時。存儲性能問題的排查首先考慮的因素就是磁盤速度，同時有多少塊磁盤可進行並發讀寫。而另一因素是磁盤接口。采用更快的接口能夠緩 解磁盤瓶頸，但更重要的是在快速接口與相應更大的緩存大小以及轉速之間取得平衡。同樣，應避免將快速和慢速磁盤混入同一接口，因為慢速磁盤將會造成快速接 口與快速磁盤的性能浪費。

可能引發的問題包括：

• 過多應用命中磁盤
• 磁盤數量不足以滿足應用所需的IOPS或吞吐量
• 磁盤速度過慢無法滿足性能需求及支持繁重工作負荷
• Disk group往往是classic存儲架構的潛在性能瓶頸，這種結構下RAID最多配置在16塊磁盤。Thin結構通常每個LUN擁有更多磁盤，從而數據分布於更多spindle，因增加的並發性而減少了成為瓶頸的可能。

需要監控的指標：

曾經一度存儲廠商們強調的是IOPS和吞吐量，但現在重點逐漸轉變成為響應時間。也就是說，不是數據移動的速度有多快，而在於對請求的響應速度有多快。

正常情況下，15,000 rpm Fibre Channel磁盤響應時間為4ms，SAS磁盤響應時間約為5ms至6ms，SATA為10ms，而SSD少於1ms。如果發現Fibre Channel磁盤響應時間為12ms，或SSD響應時間變成5ms，那麼就說明可能產生了爭用，可能芯片發生了故障。

除了響應時間，其他需要監控的指標包括：

• 隊列長度，隊列中一次積累的請求數量，平均磁盤隊列長度；
• 平均I/O大小千字節數；
• IOPS （讀和寫，隨機和順序，整體平均IOPS）；
• 每秒百萬字節吞吐量；
• 讀寫所占比例；
• 容量（空閒，使用和保留）。

數據存儲性能最佳實踐：

性能調優和改進的方式有很多種，用戶當然可以通過添加磁盤，端口，多核處理器，內存來改善，但問題是：性價比，以及對業務是否實用。本文建議的方式 是在預算范圍內找尋性能最大化的解決方案。另外一個需要考慮的方面是環境並非一塵不變，系統部署方案要能夠適應環境的改變需求。

首先需要考慮刷數據的性能特征，需要了解IO工作情況是怎樣的。是否是cache友好型？是否是CPU集中型？業務數據很大數量很少，還是很小但數量很多？另外一方面就是構成存儲環境的組件。包括應用，存儲系統本身，網絡。。。瓶頸可能在哪裡，改善哪裡最有效？

以下是一些常規建議：

1. 不要僅僅根據空閒空間來分配存儲，而需要結合考慮性能需求，確保為吞吐量或IOPS分配足夠多的磁盤。
2. 在磁盤間均衡分布應用負載，以減少熱點地區的產生。
3. 理解應用負載類型，並針對負載選擇匹配的RAID類型。例如，寫密集型應用建議使用RAID 1而不是RAID 5。因為當寫入RAID 5時，需要計算校驗位，需耗費較多時間。而RAID 1，寫入兩塊磁盤速度快得多，無需計算。
4. 磁盤類型（Fibre Channel, SAS, SATA）與期望性能相匹配。對於關鍵業務應用部署高性能磁盤，例如15,000 rpm Fibre Channel。
5. 對於I/O密集型應用考慮采用SSD，但並不適用於寫性能重要型應用。只要沒有達到控制器瓶頸，SSD對讀性能提升顯著，但對寫性能提升並沒有明顯效果。
6. 采用端對端的監控工具，特別是虛擬服務器環境。虛擬端與物理端之間有一道防火牆，所以，需要穿透防火牆進行端到端的監控。
7. 有些性能分析工具涵蓋從應用到磁盤，有些僅局限於存儲系統本身。由於性能是一個連鎖反應包含很多變量，所以需要全面地分析數據。
8. 以數據僅寫入磁盤外部扇區的方式格式化磁盤。因減少數據定位時間而在高I/O環境下提升性能。負面作用是相當一部分磁盤容量未能得以使用。

應用於

存儲性能分析、定位與排查
閱讀原文
原文：http://wsgzao.github.io/post/storage-performence/