【摘要】本文結合實踐剖析儲存系統的架構及執行原理，深入分析各種儲存效能瓶頸場景，並提出相應的效能最佳化手段，希望對同行有一定的借鑑和參考價值。

【作者】陳萍春，現就職於保險行業，擁有多年的系統、儲存以及資料備份等運維工作經驗。

前言

可靠性、安全性和效能是 IT 系統最重要的三個評價維度。對於 IT 系統來說，可靠性和安全性是基礎，系統故障或資料洩露等造成的破壞性是顯而易見的；而效能則是核心能力，代表著 IT 系統的服務水平，效能瓶頸會制約企業業務的發展，嚴重影響使用者體驗。

儲存系統是企業 IT 基礎架構重要的組成部分，為企業內部眾多的 IT 系統提供資料儲存服務。隨著數字化轉型的深入，企業的 IT 系統建設也進一步加快，這一方面帶來了資料量的急劇增長，另一方面也提高了資料的訪問頻率，儲存的效能瓶頸的影響也會被進一步放大。本文將結合個人運維實踐，剖析儲存系統的架構及執行原理，深入分析各種儲存效能瓶頸場景，並提出相應的效能最佳化手段，希望對同行有一定的借鑑和參考價值。

1. 儲存系統概述

瞭解儲存系統的架構及其執行原理是效能分析與最佳化的入門課，才能去全域性分析解決儲存效能問題。經過多年的技術演進和架構變化，儲存系統可大致分為 SAN 儲存、 NAS 儲存以及分散式儲存這三類，它們有類似之處，又各有特點。下文將分別詳細剖析這三類儲存架構及其執行原理。

1.1 SAN 儲存

SAN （ Storage Area Network ）本身是一個承擔資料儲存任務的儲存網路，與業務 LAN 網相互隔離。SAN 儲存則是一種基於儲存塊的儲存系統，一般使用 FC 、 ISCSI 、 NVMe 等通訊協議。

架構層面看， SAN 儲存一般是儲存控制器後端掛載磁碟陣列，資料最終儲存在磁碟陣列，而磁碟陣列則包括了多個 RAID 組。N 個磁碟組成一個 RAID 組，在 RAID 組之上又會被劃分出邏輯儲存單元 LUN ，也就是共享儲存池的邏輯磁碟，這些 LUN 會透過 SAN 網路與伺服器的 HBA 卡相連，從而會被伺服器的作業系統識別為磁碟，並被分割槽和格式化後使用，其架構如圖 1 所示。

圖 1.SAN 儲存架構圖

從儲存的資料 IO 流角度來看，以常用的 FC-SAN 儲存為例，伺服器作業系統一般會使用檔案系統管理檔案，檔案系統是建立在儲存 LUN 之上，檔案的讀寫會對應著儲存的 IO 操作；檔案會被分為多個 Block ， Block 大小固定，一般是 4KB-16KB ；資料 Block 塊會被髮送到伺服器的 HBA 卡， HBA 卡再將其轉換為 FC 協議的資料幀（ Data frame ），並透過 SAN 網路傳輸到儲存系統的前埠；儲存的前埠繼續將這些資料幀重新封裝成資料 Block ， Block 大小一般為 4KB ，並將這些資料 Block 塊傳輸到儲存控制器中；儲存控制器中會有儲存快取（ Cache ），分為讀快取與寫快取，根據快取的演算法規則，部分快取命中的 IO 資料流會立刻返回 IO 確認，快取未命中的 IO 資料流則會需要繼續訪問磁碟陣列；由於多個磁碟組成了 RAID 組，一個資料 IO 流實際上對應著多個磁碟的併發讀寫。整個過程如圖 2 所示：

圖 2.FC-SAN 儲存的資料 IO 流圖

1.2 NAS 儲存

NAS （ Network Attached Storage ）儲存一般也可認為是網路檔案儲存，使用者資料大多數以檔案形式存在，透過乙太網訪問模式走 NFS/CIFS 協議，提供了廣泛相容性易用性的共享能力。相比於 SAN 儲存， NAS 儲存不以磁碟形式提供儲存服務，不需要分割槽和格式化，可以直接提供可以直接掛載的網路檔案系統。

架構層面看， NAS 儲存一般也是基於磁碟陣列（也有基於叢集檔案系統或分散式儲存的實現方式）實現的，在磁碟陣列之上會有 NAS 機頭來建立和管理檔案系統；NAS 機頭是 NAS 儲存的核心邏輯部件，是典型的 C/S 架構風格，是對外提供網路檔案服務的 Server 端；其他 client 端在獲得授權後，可透過掛載檔案系統、對映網路磁碟或 HTTP 、 FTP 等方式就可以共享訪問 NAS 檔案系統上的檔案，其架構如圖 3 所示：

圖 3.NAS 儲存架構圖

從儲存的資料 IO 流角度來看，以 NFS 為例， NAS 儲存是有著明顯異於 SAN 儲存的特點，比如客戶端快取、 Server 的無狀態性等。首先客戶端並不是直接訪問 NAS 檔案系統，而是客戶端快取，是服務端的檔案系統目錄樹對映到了客戶端，實際在檔案讀寫時，需要迴圈讀寫固定大小的頁面，比如 64KB ；而 Server 端的無狀態性體現在不需要維護客戶端的協議狀態資訊，客戶端透過 RPC 呼叫操作 Server 端的檔案系統資料，但也不能獲取 Server 端的狀態，當連線中斷時，可以不停地連線重試。如圖 4 所示，基於 TCP 的應用層協議的 NAS 儲存資料 IO 流會更加靈活，適配性較強，但資料 IO 路徑更長，資料一致性較差，還會存在資料洩露等安全問題，資料傳輸效率也不高。

圖 4.nfs 協議下的 NAS 儲存資料 IO 流圖

1.3 分散式儲存

分散式儲存系統是採用可擴充套件的叢集架構，透過資料副本演算法將資料分散儲存在多臺獨立的裝置上，分散式叢集之間一般透過通用 TCP/IP 網路連線。相比於其傳統的集中式儲存陣列，分散式儲存系統可以透過多臺儲存伺服器來分擔儲存負荷，可以滿足大規模儲存應用的需要。常見的分散式儲存系統的形式包括分散式檔案系統（如 HDFS ）和物件儲存（如 Ceph ）。

從架構層面來看，與集中式儲存系統相比，分散式儲存系統的部署架構相對簡單，一般是通用伺服器網路互聯的方式，但其邏輯架構更加複雜。分散式儲存系統的核心設計思想是去中心化， 去中心化的難點主要在於是主控節點的去中心化，有主控節點的架構比如 HDFS 的架構設計思路是 map-reduce ，化大為小，分而治之，再合併處理，其架構中需要主控節點來協調，只是主控節點的負載都分發到了資料節點，資料節點上則存放著資料副本，每個資料副本又都分佈在三個不同的資料節點上，如圖 5 所示；而無中心化的最大優點是解決了主節點本身的瓶頸，其架構設計思路則是均衡設計，這種架構只有資料節點，但是需要抽象出更多的邏輯功能元件，並均衡分佈在不同節點上。以 Ceph 塊儲存的使用方式為例，除了 Mon 等叢集管理監控元件之外， Ceph 中 OSD 元件用於管理物理磁碟，基於 OSD 去構建 PG ，而 PG 上存放著資料物件，資料物件則對應著 Ceph 塊裝置， Ceph 塊裝置可被格式化分割槽，從而被應用使用，其架構圖如圖 6 所示。

圖 5. 有主控節點的分散式儲存架構

圖 6. 無主控節點的 Ceph 儲存架構

從儲存的 IO 資料流來看，不同於集中式儲存較少的資料通道，分散式儲存的資料入口可以更多更寬，但叢集內部的資料流也更多。還是以 Ceph 的塊儲存為例，客戶端應用訪問的檔案系統對應的是 Ceph 塊裝置， Block 資料透過網路訪問 Ceph 叢集 RBD 服務，最終對應於三副本 OSD 的磁碟讀寫，流程如圖 7 所示。對於三副本的分散式儲存系統，為保障資料的強一致性，一個寫 IO ，一般需要主副本和另外兩個從副本都寫完後，才能最終確認寫完成。

圖 7.Ceph 儲存 IO 資料流圖

2. 儲存效能分析

儲存效能分析是效能最佳化的基礎，雖然存在多種型別多種設計方案的儲存系統，但效能分析方法卻具有一定的通用性。儲存效能分析方法可分為定性與定量兩種方式，通常在接觸瞭解、技術選型的初期可能並不具備定量分析的條件，則主要採用定性分析方法來評估儲存系統的效能；而一旦進入 POC 測試、系統運維等階段，則應以定量分析為主，透過實際的效能指標資料來判斷儲存效能瓶頸。

2.1 定性分析

定性分析是結合個人的運維經驗，來分析儲存系統的效能是否能滿足應用系統的需求，來分析儲存系統是否存在效能瓶頸，而這些都取決於對應用資料型別和儲存系統的熟悉程度。

2.1.1 應用資料 IO 分析

瞭解應用資料 IO 的型別，是儲存效能分析的基礎。不同應用資料 IO 訪問存在著差異，主要體現在 IO 大小、順序或隨機讀寫、讀寫比例等方面，如表 1 所示。

表 1. 應用程式的資料 IO 型別

IO 大小

應用資料型別的差異會帶來不同大小的資料檔案，也對應著不同的資料 IO 大小。假設儲存系統 IO 處理能力是固定的，顯然單位時間內大 IO 處理的資料更多，那麼合併小 IO 會更有效率；而假設儲存系統每次處理資料 IO 大小有上限，那麼每次處理大 IO 前都需要拆分，顯然 IO 處理效率會下降。比如 SAN 儲存具有很高的 IO 處理能力，但單次處理的 IO 偏小，那麼更適宜效能要求高的、小 IO 應用系統，而處理大 IO 應用資料時，效率反而會下降。

讀寫比例

讀寫比例是應用資料的重要特徵之一， IO 讀和寫操作存在著較大的差異。一般來說寫操作對於儲存效能的消耗更大，寫 IO 處理能力、延時都較高，對快取的需求差異也較大。對於分散式儲存來說，多副本機制可以最佳化讀操作，但卻不利於寫操作，寫確認路徑較長，需要最佳化資料傳輸路徑、配置更多的寫快取，更適宜於讀比例較高的應用系統。

順序或隨機讀寫

順序或隨機讀寫的差異主要表現在磁碟介質特性、預讀取機制、快取命中率等方面。對於機械硬碟來說，順序讀寫的 IO 可以減少磁碟尋道時間，隨機讀寫的 IO 則響應時間變長，可以透過提高快取命中率的方式，將快取中的資料轉化為順序讀寫到磁碟；而 SSD 硬碟則不存在機械尋道，隨機讀寫能力會大大優於機械硬碟。

2.1.2 效能瓶頸分析

儲存效能分析的關鍵是對效能瓶頸進行分析，包括兩方面的內容：一是觸發效能瓶頸的因素；二是效能瓶頸的定位，找出儲存 IO 擁塞的位置。

1)觸發效能瓶頸的因素

儲存熱點：儲存熱點是規劃設計中的缺陷，典型場景包括資料 IO 負載過於集中在某個儲存節點、埠、磁碟等，儲存資源爭用、鎖競爭，軟硬體引數的限制等。

效能尖峰：常見於資料 IO 高併發、效能需求短時間集中釋放的場景，效能尖峰更會充分暴露出存在的熱點問題，從而觸發儲存效能瓶頸，典型場景包括虛擬桌面啟動風暴、秒殺類業務等。

服務能力下降：常見於故障場景，儲存服務能力下降疊加資料 IO 繁忙階段，會導致觸發儲存效能瓶頸。典型的故障場景包括 SAN 儲存單儲存控制器故障、磁碟 rebuild 等；分散式儲存更容易出現效能抖動，主要也是由於某個節點或磁碟掉線或重建資料副本或某個資料副本響應變慢；客戶端伺服器的 CPU 、記憶體資源不足等。

2)效能瓶頸的定位

儲存效能瓶頸的定位需要結合儲存系統的架構來分析，按照儲存系統的構成大致可分為以下幾類效能瓶頸位置：

資料傳輸網路：儲存外接和內接資料傳輸網路的頻寬、埠速率、傳輸協議、傳輸路徑的負載均衡度

儲存控制器：控制器的 CPU 處理能力

快取：主要分為客戶端快取和儲存快取，包括快取大小、快取命中率、讀寫快取的分配比例

磁碟：主要分為機械硬碟、快閃記憶體盤等磁碟介質，包括磁碟轉速、單盤讀寫的 IOPS 、磁碟容量大小、磁碟數量、磁碟冗餘（ RAID 、副本或糾刪碼）演算法

客戶端：體現在客戶端的 CPU 、記憶體等資源的使用情況、其他應用對儲存資源的佔用等外部環境的影響

2.2 定量分析

定量分析是從資料指標角度來分析解決問題，既可以從儲存側來度量儲存系統的服務能力，也可以從使用者應用側來衡量儲存 IO 體驗。一般來說，儲存側的定量分析排除了儲存網路和客戶端的影響，效能資料能說明儲存系統本身是否存在效能瓶頸，可用於儲存系統的效能監控；而使用者應用側的定量分析主要用於一些效能測試場景，透過基準測試工具，可以形成當前系統環境的效能基線。

2.2.1 三大效能指標

無論是儲存側還是使用者應用側的定量分析，都離不開三大儲存效能資料指標：IOPS 、吞吐量（ Throughput ）、延時（ Latency ）。因此有必要弄清楚三個效能資料指標的含義及其關聯關係。

IOPS ：代表儲存每秒所處理的 IO 運算元量。對於儲存系統來說，我們在效能分析時，既需要關注整體的 IOPS ，有時也需要分析單個控制器、單個 LUN 或者單個磁碟的 IOPS ，甚至可能還需要區分讀或者寫的 IOPS 。

吞吐量（ Throughput ）：代表儲存每秒所處理的 IO 資料量大小，也就是儲存資料傳輸所佔用的頻寬，與 IOPS 類似，也可以細分讀或者寫，可以單獨元件分析。

延時（ Latency ）：代表儲存系統處理 IO 操作所需要的時間，通常情況下，是最重要的儲存效能指標，與 IOPS 類似，也可以細分讀或者寫，可以單獨元件分析。

三大效能指標分析中，對於 大 IO 的應用使用吞吐量來評測效能更加科學；而小 IO 的應用，比如資料庫，則需要透過 IOPS 和延時的指標來評測效能，高 IOPS 和低延時同時滿足的情況下，才能應對高併發且快速的資料庫訪問。

2.2.2 效能測試分析

儲存效能測試可以更好地理解儲存的效能指標，以某個儲存效能測試為例，儲存壓測工具 vdbench （可針對裸盤與檔案兩種訪問方式的壓測），測試背景是儲存上分配了 5 個 lun 給主機，主機對這五塊裸盤做隨機讀寫測試， 80% 讀 20 寫，逐漸調整 IO 的大小進行測試，三大效能資料指標如下表：

表 2. 儲存效能測試資料

該儲存效能測試的結論如下：

1) 該儲存的控制器 CPU 使用率峰值在 20%-45% ，說明該儲存控制器還可以承受更高的 IO 負載，如圖 8 所示。

圖 8. 儲存控制器 CPU 使用率

2) 該測試也未達到主機的系統效能瓶頸， CPU 使用了低於 20% ，這一點在儲存效能分析中也很重要。

圖 9. 主機系統的 CPU 使用率

3) 儲存效能基線 ：表 2 中的測試資料就是特定的主機使用該儲存的 5 個 lun 在不同 IO 負載下的效能基線資料，在實際執行過程中，考慮到其他應用的 IO 、讀寫 IO 大小不均等因素，一般 IOPS 峰值在基線值的 50% 。

4) 吞吐量和 IOPS：吞吐量 =IOPS*IO 大小，相同的業務場景，一般 IO 大小不會有明顯變化，那麼極限測試下的吞吐量與 IOPS 會呈正比關係，但吞吐量受限於網路頻寬， IOPS 又受限於儲存 lun 的處理能力；

5) 延時和 IOPS：可以看出測試資料中延時和 IOPS 呈現出反比關係，即 IOPS 越低，延時反而越高，這是由於不同的 IO 大小的測試場景下，儲存的負載壓力不一樣，即大 IO 的情況下，儲存負載變大， IOPS 下降，延時加大。而儲存系統正常執行狀態下的 IOPS 和延時關係如圖 10 所示，大多數情況下儲存的負載壓力變大， IOPS 增加，延時也開始變大，一旦 延時過高就會影響業務系統的效能。所以大多數情況下，延時是最重要的儲存效能指標，一般效能要求較高的業務系統，儲存的延時需要低於 5ms 。

圖 10. 正常執行狀態下的儲存 IOPS 和延時

3. 儲存效能最佳化

儲存效能分析與最佳化是一項長期、複雜而重要的工作，需要明晰儲存效能最佳化目標，做好詳細效能分析，並制定階段性的最佳化方案和驗證方案，以確儲存儲效能最佳化工作的持續開展。

3.1 最佳化策略

儲存效能最佳化工作具有一定的策略性，科學的最佳化策略才能指導制定更加合理的儲存效能最佳化方案。

1) 通盤考慮：儲存效能問題是一個全域性性問題，需要通盤考慮 IO 路徑上的效能瓶頸，分析效能最佳化方案中可能出現的連鎖反應，以提高效能最佳化決策的正確性。

2) 最佳化的價效比：制定合理的效能最佳化目標，在多種效能最佳化方案的選擇上，要綜合考慮方案成本、實施複雜性、收益等。

3) 規劃更重要：相比於儲存效能最佳化帶來的最佳化改造成本，提前做好合理的規劃更為重要。比如兼顧業務效能需求的儲存選型，系統上線前的儲存效能測試的基線資料及效能容量管理，儲存擴容要關注 效能容量指標（評估擴容後，儲存的 IOPS/GB 是否有較大變化），以及儲存效能負載的均衡分佈等。

4) 完善效能監控：端到端的儲存效能也是非常重要的，對整個資料 IO 路徑進行監控，基於儲存效能基線來分析實際執行中的效能資料，從而及時發現儲存效能瓶頸，也能驗證儲存最佳化的成果。

3.2 最佳化方案

儲存效能最佳化方案可以大致分為以下幾類：

1) 硬體升級

單塊機械硬碟的 IOPS 在 100 左右，延時在 5ms 以上，而單塊 SSD 的 IOPS 在 1 萬以上，延時小於 1ms ，傳統機械硬碟替換為全快閃記憶體儲存，效能可以得到極大的提升；NVMe 、 RDMA 等技術的應用，最佳化了底層通訊框架，可以極大提高資料傳輸效率，降低儲存延時；儲存控制節點的橫向或縱向擴充套件，可以有效增加儲存負載能力；客戶端的硬體升級，也能消除客戶端的 CPU 、記憶體、網路等帶來的效能瓶頸。

硬體升級是一種非常有效的儲存效能最佳化手段，但是很多情況下需要比較高的硬體成本，投入產出比還需要仔細評估。

2) 上層應用最佳化

上層應用最佳化手段也比較豐富，主要目標是減少上層應用帶給儲存的 IO 負載，比如資料傳輸前啟用重複資料刪除或資料壓縮；最佳化 IO 併發，將大量的小 IO 聚合成大 IO ；資料庫的索引最佳化、 SQL 語句最佳化。

3) 調整效能負載

調整效能負載主要針對的儲存效能熱點問題，方案包括最佳化磁碟分佈方式，調整磁碟負載；調整儲存網路埠負載；調整儲存控制器負載；新增儲存，將部分負載調整到新的儲存上。

4) 資料快取最佳化

資料快取是儲存系統中非常重要的效能模組，一般快取都採用記憶體或快閃記憶體等速度更快的儲存介質，遠遠快於一般的磁碟。很多儲存效能問題都因快取而起，也經快取最佳化而終結。資料快取分為客戶端本地快取和儲存快取。比如客戶端本地快取對於一些分散式檔案系統非常重要，增加快取大小，可以有效提高快取命中率；儲存的快取也極為重要，多層級的資料快取技術可將熱點資料存放在更快的儲存介質上，降低儲存延時。