作者：高翔（Sean）、唐僧

前不久有位朋友問我，隨著近些年來企業儲存的發展，每個階段大致可以達到什麼效能水平？直到前兩天，我才想起來5年多前寫過一篇《SPC-1：快閃記憶體 vs.磁碟新舊勢力的戰場》（連結http://storage.chinabyte.com/264/12249264.shtml），從一個側面分析了企業級SSD大範圍應用前夜的產品技術格局。到今天我想再補充一個簡單的圖表：

上面數值除了最右邊的SDS（軟體定義儲存）/超融合之外，仍然參考自幾份SPC-1測試報告，具體數字進行了一定模糊處理，以免大家對號入座：）SDS/超融合一項選擇了其它測試方法獲得的混合讀寫IOPS，一方面目前參與SPC-1測試的分散式

簡單來說，早期磁碟陣列IOPS受限於HDD機械硬碟的平均訪問時間，到了SSD時代介質的瓶頸相對容易解決。我給出的參考值不能充分代表所有廠商，也並不是每家廠商都積極參與SPC-1這樣的軍備競賽，因為效能不是儲存的全部。比如同樣是全快閃記憶體高階多控陣列（AFA），有的可能只是在4K讀IOPS達到200萬，而這並不能簡單評價為“效能差”，因為它同時還打開了重複資料刪除和壓縮等資料服務。

在初創的All-Flash Array廠商中，有些已經是分散式控制器的架構。隨著多副本和糾刪碼技術的流行，人們也慢慢開始不再對

如今，我們看到在一些使用標準伺服器硬體的軟體定義儲存，其每節點貢獻的效能已經開始不遜於專門優化的快閃記憶體陣列控制器，並且具有更好彈性的和擴充套件性。有了這些再加上逐漸的成熟，越來越多的傳統儲存使用者開始青睞SDS和超融合（HCI）。

下面開始介紹本次測試的內容，大體上分為前後兩部分，包括隨機IOPS、順序頻寬這些基準測試結果，以及模擬SQL Server OLTP的表現。

第一部分：IOPS、頻寬和SSD效能的發揮

從

注：上表中的延時都是在虛擬機器中直接收集的（如無特別說明，以下同），相當於使用者/應用最實際的感受。

我們部署了一個4節點SDS/超融合叢集，每節點上除了系統盤之外，有7塊SATA SSD參與組建分散式儲存，並採用最常見的3副本配置。每臺物理機上使用20個虛擬機器（共80 VM）進行測試。

我們測出的4節點4KB隨機讀最大效能為1,587,480 IOPS，平均每節點接近40萬IOPS，此時的平均延時為3.23ms。總共28個SSD平均貢獻56,595IOPS，這裡使用的Intel SSD S3610官方標稱4KB隨機讀IOPS為84,000，分散式儲存軟體的效率還不錯吧？

如果要看低延時IOPS，在0.36ms的IOPS為864,843，平均每節點也超過了20萬。我們雖然沒有使用NVMe SSD，但可以給大家看一個之前的測試參考——在《Intel Optane P4800X評測(3)：Windows綁核優化篇》中Intel P3700在128佇列深度下達到46萬IOPS的峰值，對應的延時為226μs。初步預計換成NVMe SSD將有更好的表現（CPU等配置可能也需要升級）。

上圖為在2節點上進行4K隨機讀測試的最高效能，每節點貢獻44萬IOPS反映出了SDS/超融合的線性擴充套件能力和本地讀優化（後面我還會細談這個主題）。另外此時從物理機OS看到的儲存讀延時只有0.28ms，可見虛擬機器中的延時很大一部分是由於佇列，高I/O壓力對VM內CPU有明顯的開銷。

這時讀者朋友可能會問，你們測試的是哪家SDS？先彆著急，再看看隨機寫的表現。

如上圖，在每個虛擬機器設定QD=32時測出的433,620 4K隨機寫IOPS已經接近4節點叢集的峰值。按照這時的數字來計算，落到每個SSD上的IOPS就達到了15,486 x 3=46459（因為是3副本），已經超過了IntelSSD S3610官方標稱的27,000穩態隨機寫IOPS？

上面是我們在開始測試時SSD簡單摸底的成績——Intel SATA 1.6TB的54,491 4KB隨機寫並未達到穩態。對這一點我們並不是太在意，因為本次測試考察的是SDS儲存軟體的效率，SSD寫表現快一點不是壞事吧：）

同理，由於企業級SSD是有帶掉電保護的寫快取，所以在較低佇列深度下SDS/超融合叢集也能有較好的表現——330,264 100%隨機寫對應的延時只有0.48ms。

如果在物理節點上看，寫延時也降低了不少。大家都知道直接在物理節點中測試SDS效果更好，但由於本文評估的是虛擬化&超融合環境，所以仍然以應用感知的VM內延時結果為準。

再談副本數量與可靠性

有的朋友可能記得我寫過一篇《為什麼ScaleIO和VSAN不要求三副本？》，其中提到VSAN“不打散”所以雙副本可用，而ScaleIO通過保護域和故障集的配合、以及重構速度來保障2副本可靠性。

也就是說雙副本的應用不是完全沒有限制的，包括Ceph在內的更多強一致性分散式儲存軟體，大多建議生產環境使用三副本。我在這裡想說的一點就是，在POC等效能測試中，對於建議三副本的SDS產品使用雙副本測試固然能看到更好的數字，但實際使用又是另一種情況。

對於宣稱良好支援雙副本的分散式儲存，也要像我上面提到的2款那樣有相應的理論設計基礎到充分的測試和實踐驗證。畢竟對於企業儲存產品來說，資料可靠性重於一切，如果不能保證穩定跑再快也沒用。

微軟S2D測試環境：100Gb/s RoCE網路成亮點

每節點2顆E5-2640 v4 10核CPU只能算是Intel XeonE5系列中的主流配置，不屬於“跑分很漂亮”但更接近大多數使用者的環境。

以上就是本次微軟S2D（Storage Spaces Direct）的測試平臺——在上海的戴爾客戶解決方案中心（CSC）進行，並特邀相關領域專家高翔親自操刀。

高翔（Sean）上海維賽特網路系統有限公司 副總工程師

早在3年前，高翔老師就主持過微軟SOFS（Windows Server 2012 Storage Spaces）的測試及相關專案實踐，可以說是國內為數不多精通微軟Storage Spaces的專家。

關於RDMA網路對分散式儲存效能的影響，我們先稍後再談。

除了2節點叢集，微軟建議S2D使用者配置3副本（另有部分用途適合糾刪碼）。

我們測出4節點S2D叢集的順序讀頻寬為10951MB/s，平均每個SSD達到391MB/s，對比下前面列出的裸盤效能效率也不低了。至於2626MB/s的順序寫，考慮到3副本的開銷，平均每節點的底層SSD總寫入量依然達到了1969MB/s。

第二部分、SQL Server資料庫OLTP模擬I/O測試

在下面的測試中，我們選擇繼續使用DiskSpd + VM Fleet產生儲存壓力。其中DiskSpd是微軟提供的一個類似fio和Iometer的工具，而VM Fleet則是配合DiskSpd使用的一套指令碼，便於同時使用多個虛擬機器進行測試。在後續的文章中我們也會用到其它工具，而總的原則如下：

1、儘量避免因儲存之外的配置造成測試瓶頸；

2、通用性強，易於對比。雖然我們在本文中不做橫向比較，但測試過程和結果方便復現，能夠為使用者和技術同行提供參考價值。

我們也考慮過在資料庫中模擬交易/查詢的測試方法，但其結果受多方面因素影響，包括：執行的SQL複雜（優化）程度、CPU效能、讀寫比例、記憶體命中率等等。想要跑出好看的TPS（TPM）/QPS，許多時候瓶頸會出在CPU核心數x主頻而不是儲存上，而使用者的業務模型又是千差萬別的。所以最終還是決定用微軟官方建議的SQL Server儲存效能評估方法。

上圖截自《UsingDiskspdforSQLServer》文件中的範例，在聽取幾位朋友的意見之後，我們覺得40%的寫入比例相對於各種OLTP使用者平均的情況還是偏高了，因此選擇了更有代表性的8KB 70%隨機讀/30%隨機寫。

對於實際應用來說，SQL Server資料庫虛機機在每臺物理伺服器上的部署數量往往不會很多，但每個VM內的IO併發/佇列深度卻可能比較大，最終給儲存帶來的壓力應該是同等效果。根據上面圖表，在每臺物理機80 QD時達到48萬讀寫混合IOPS，延時為0.66ms；當每臺物理機總QD達到640測出接近最高的62萬IOPS（平均每節點超過15萬），對應的延時在5ms以內。

以上都是4個節點上的虛擬機器同時壓測。如果資料庫只是執行在單個虛擬機器，或者是1-2個物理機上，底層儲存仍然由4節點Windows Server 2016超融合叢集提供，這時又會是什麼樣的效能表現呢？

單VM即可發揮一半效能：“另類”S2D擴充套件性驗證

由於這裡想壓測出單個虛擬機器在S2D上的最大效能，“1 VM”用的計算尺寸比較大，是16 Core、56GB記憶體，相當於Azure上的D5V2配置。而其它測試每臺物理機上20個VM用的是A2例項——2 Core、3.5GB記憶體。

注：S2D其實也是源自Azure公有云中的儲存技術。

對於1個虛擬機器中的165,405 8KB混合讀寫IOPS結果，我們比較滿意。採用不同節點數量對S2D叢集（仍為3副本）加壓，2節點混合讀寫IOPS大約是單節點的1.5倍，4節點大約是單節點2倍。

上面的標題為什麼稱“另類”擴充套件性驗證呢？因為人們普遍用整個叢集、大量虛擬機器來壓測超融合的儲存，而往往容易忽略單一負載的效率表現？我除了想驗證這一點，還有伺服器計算資源對效能發揮的影響（前提是網路在測試環境中不是瓶頸）。不得不承認，3x-4x萬IOPS在VM內（客戶端）加上SDS分散式儲存軟體本身的開銷，對於2顆主頻一般的10核CPU已經夠忙活了：）

換句話說，如果改用更好的CPU和NVMe SSD，就應該能達到下面的測試結果：

4節點S2D跑到3百萬隨機讀IOPS，這應該是我目前看到過平均每節點跑得最快的一個分散式儲存測試報告，當然盤的配置也比我們實測要高不少——2個Intel P3700做快取層，8個同樣NVMe的P3500做容量層。

從超融合本地讀優化到分離式部署

通過更多測試，我們觀察到S2D在3副本配置的情況下，寫入資料時會全域性打散到所有節點，而在讀資料時一旦有副本在本地節點就優先從本地讀取，對於超融合應用有助於減少網路的開銷（儘管本文的測試環境網路不是瓶頸）。

上面只是我們配置過程中的一個截圖，可以看到S2D上4個用於測試的CSV（叢集共享卷）Onwer分別指向了不用的節點，這樣在對應伺服器上加壓時就可以享受到本地讀的效果。如果某個Onwer節點故障，會重新選舉新的Onwer接管CSV。

不知是否有朋友會問：我的Hyper-V伺服器平均儲存壓力沒有這麼大，S2D如此效能水平可否支援為叢集外面的主機提供服務？答案是肯定的。

上圖我在以前的文章中列出過，右邊就是Hyper-V叢集和SOFS on S2D叢集分離部署（非超融合）。應用主機和儲存節點通過SMB3協議網路連線，依然可以選用RDMA。

根據IDC的預測，“在2017年到2021年期間，全球軟體定義儲存市場的複合年增長率將達到13.5%，到2021年收入接近162億美元。HCI不僅增長最快，複合年增長率為26.6%，同時也是最大的子領域，到2021年收入將達到71.5億美元。在預測期內，物件儲存的複合年增長率將達到10.3%，而檔案儲存和塊儲存的複合年增長率將分別達到6.3%和4.7%。”

除了技術之外，再談一下微軟S2D在銷售策略上的特點：與VMware VSAN、NSX單獨銷售不同的是，微軟將Windows Server 2016資料中心版定位成軟體定義資料中心的基礎，將所需功能整合，一個License就搞定OS許可+Hypervisor+SDS+SDN。Windows Server 2016三種部署方式：圖形化介面、Server Core 和 Nano Server 均支援S2D。

更多應用針對性的S2D測試資料，我們將在後續的文章中繼續分享。敬請關注：）

最後，特別感謝上海戴爾客戶解決方案中心Tony Wang對本次測試的大力支援！

附1：RDMA效能影響、SSD混合儲存規則

筆者之前還寫過2篇S2D相關的東西：

現在看來，一年多之前由於資料有限，當時寫的一些技術點還不夠準確。比如一位微軟的朋友就曾指出：“Built-In Cache”和“ReFS Real-Time Tiering”在S2D裡可以都看成是快取技術，區別主要在於後者是先將資料寫入副本分層來改善糾刪碼的效能。

回過來接著看前面的架構圖：本次測試使用了4臺Dell PowerEdgeR630伺服器，比較豪華的一點是100Gb/sRDMA作為S2D叢集互連網路，包括Mellanox ConnentX-4雙埠100Gb網絡卡和Dell Networking S6100-ON交換機。

上圖來自微軟提供的參考資料，啟用RDMA之後，S2D的IOPS和延時效能都有明顯的改善。如果說在RDMA網路下S2D的效率才能充分發揮，換個角度也證明微軟於RDMA（包括SMB Direct）方面在業內較早地進行了比較充分的優化。

另外說明一點，在這階段測試中我們並未使用每臺伺服器上的1個NVMe SSD，因為不符合當前Windows Server 2016 S2D的規則。S2D支援SSD + HDD或者NVMe + SSD的快取配置，但要求Cache層SSD每節點不少於2個。關於混合S2D配置與全快閃記憶體的效能差異，後續我想在另一篇文章中給大家介紹。

附2：企業儲存系統發展的三個階段

1、5-10年前的傳統HDD磁碟陣列

相信許多朋友都看到過以下這組公式，根據硬碟的平均訪問（尋道+旋轉）延時來計算單盤的IOPS參考值：

15000rpm 硬碟  1000/(2+3.5)≈180

10000rpm 硬碟  1000/(3+3.5)≈150

7200rpm 硬碟   1000/(4.17+8)≈80

利用每塊硬碟的IOPS，乘以盤數（主軸數量）可以得到一個儲存系統的經驗IOPS值，比如設計合理的情況下256塊15K HDD可達4-6萬隨機讀IOPS，此時控制器的處理能力往往還不會是瓶頸。隨機寫的情況相對複雜一些，RAID 1的寫懲罰=2，RAID 5/6寫懲罰則是4/6，所以我們看到各儲存廠商在測試SPC-1這些交易型別的BenchMark時，大多會選擇RAID 1（雙副本映象）以獲得較好的表現。

上圖來自於6年前某高階儲存（8控制器）的SPC-1測試報告，在此只用於技術舉例無意提及品牌型號。它配置了1920塊15K HDD硬碟，按照總共45萬IOPS來計算，平均每塊盤貢獻大約230 IOPS。

為什麼比前面的經驗公式要高呢？我認為有以下幾個方面的原因

a．SPC-1測試負載中包括一部分順序讀寫；

b．陣列的預讀/寫快取有一定I/O合併效果（HDD陣列低於5ms延時也是因為Cache優化）；

c．有些參測陣列並未劃分全部容量，使實際的平均訪問時間低於全盤範圍（類似於短擊的效果，只針對機械硬碟）。

記得在《儲存極客：SPC-1負載分析與AFA壽命評估》一文中，我對SPC-1曾有過粗略研究，根據IOPS計算出寫入的資料量。

SPC-1是個比較複雜的混合負載，包括約39%的讀IO（應該主要是隨機）和61%的寫I/O，而後者當中至少有接近一半（佔整體28%）的日誌/順序寫入。在資料塊大小方面，分為4KB和SMIX兩種型別，SMIX是按照一定比例的混合塊，經計算其平均I/O大小為14.4KB。整體上看，讀I/O平均尺寸為6.76KB，寫I/O平均8.83KB。

注：後來推出的SPC-1 V3測試模型有所變化，以上僅針對SPC-1 V1討論。

2、當前的全快閃記憶體陣列

隨著基於NAND快閃記憶體SSD的普及，只需要數量少得多的驅動器就可達到以前“堆硬碟”的效果。中端雙控AFA陣列普遍能達到數十萬IOPS的水平，此時效能瓶頸已經從儲存介質轉到了控制器上，SPC-1測試平均到每個SAS SSD能貢獻2萬IOPS就算效率比較高的。再加上效能更高的雙埠NVMeSSD剛開始成熟，人們普遍更加看好Server SAN/分散式軟體定義儲存（SDS），特別是超融合（HCI）部署形態的發展。

3、分散式軟體定義儲存

如今雖然Server SAN/SDS廠商如雨後春筍般湧現，但參與SPC-1的熱度似乎不如以前高。SPC組織收費高昂是一方面，此外一位國內做儲存研發比較資深的朋友還告訴我一些限制：SPC-1 V1應該是隻支援UNIX和Windows客戶端；SPC-1 V3加入了Linux，但還是要求FC、iSCSI、iSER這些標準塊裝置連線協議，專用客戶端訪問的儲存產品無法參與測試。

這樣一來，像VMware VSAN、Dell EMC ScaleIO、微軟S2D（Storage Spaces Direct，基於SMB3協議）等主流軟體定義儲存產品就不太適合用SPC-1來測試。Ceph其實也是如此，iSCSI/FC閘道器顯然沒有原生的librbd效率高。

從效能角度來看，Server SAN/SDS的擴充套件性普遍不錯，而單節點IOPS並不是都能做到很高，達到10萬IOPS每節點就算比較好的了，這方面其實我也撰文討論過。