我們已經討論過了 用它取笑你，現在我們終於交付了帶有 Intel Optane Review 的 VMware vSAN。 這將標誌著對 vSAN 的第三次主要審查，從 混合 vSAN 6.0 的多部分回顧 隨後是 vSAN 6.2 的全閃存回顧. 這一次，我們沒有利用我們的 Dell PowerEdge R730xd 集群，而是使用運行 vSAN 2029 的 Supermicro 的 24U-TN4R2T+ 24U、6.7 托架服務器。 對於存儲，我們使用全 NVMe 配置，寫入層採用 Intel Optane P4800X (375GB) SSD，容量層採用 Intel P4500 (2TB) SSD。
我們已經討論過了 用它取笑你，現在我們終於交付了帶有 Intel Optane Review 的 VMware vSAN。 這將標誌著對 vSAN 的第三次主要審查，從 混合 vSAN 6.0 的多部分回顧 隨後是 vSAN 6.2 的全閃存回顧. 這一次，我們沒有利用我們的 Dell PowerEdge R730xd 集群，而是使用運行 vSAN 2029 的 Supermicro 的 24U-TN4R2T+ 24U、6.7 托架服務器。 對於存儲，我們使用全 NVMe 配置，寫入層採用 Intel Optane P4800X (375GB) SSD，容量層採用 Intel P4500 (2TB) SSD。
對於那些不熟悉 vSAN 的人來說，VMware 的超融合基礎架構針對 vSphere 進行了優化，更傾向於存儲。 換句話說，vSAN 是軟件定義數據中心構建塊的一個步驟，旨在簡化存儲和存儲管理，同時提供更好的性能。 vSAN 通常通過稱為 VMware vSAN ReadyNodes 的認證計劃進行銷售，該計劃是經過認證的硬件與 VMware 軟件的組合。 大多數主要服務器供應商都提供 ReadyNode 配置，有些還提供 vSAN 作為設備。
與 ReadyNode 想法類似的是英特爾的 Select Solutions。 英特爾精選解決方案是經過驗證的硬件和軟件堆棧，符合英特爾提出的要求。 主要服務器供應商投放市場的解決方案必須能夠複製或超過英特爾概述的基準性能，並且他們必須為客戶提供詳細的部署指南。 我們用於本次審核的設置屬於此類，具體來說，它是一個面向 VMware vSAN 的英特爾精選解決方案。 顧名思義，該解決方案專為 VMware 環境設計。
面向 VMware vSAN 的英特爾精選解決方案有兩種配置：“基本”和“增強型”。 我們的配置位於這些配置的中間位置； 它基本上是具有升級 CPU 的基本配置。 通過將 Optane SSD 用於寫入層，我們的系統旨在滿足關鍵業務應用程序的延遲需求。
Supermicro 2029U-TN24R4T+ 規格：
- Supermicro 2029U-TN24R4T+ 服務器 (x4)
- CPU：2 x Intel Xeon Gold 6152 處理器，2.10 GHz，22 核
- 內存：384GB RAM（12 x 32 GB 2,666 MHz DDR4 DIMM）
- vSAN 磁盤組，每個節點 2 個：
- vSAN 緩存層：2 個 375GB Intel Optane SSD DC P4800X 系列 NVMe SSD
- vSAN 容量層：4 個 2TB Intel DC P4500 系列 NVMe SSD
- 網絡：
- 英特爾以太網融合網絡適配器 X710 10/40 GbE（vSAN 專用鏈路，vMotion/VM 流量/管理拆分到其自己的 VLAN）。
- 性能
- 4KB 隨機，隊列深度 16，R/W：高達 550/500K IOPS
- 4KB 隨機，隊列深度 16，混合 70/30 R/W：高達 500K IOPS
- DWPD：30
- 性能
- 順序讀取：3200MB/s
- 順序寫入：1050MB/s
- 隨機 4K 讀取：490,000 IOPS
- 隨機 4K 寫入：38,000 IOPS
- DWPD 0.75 隨機； 4.62順序
應用程序工作負載分析
第一個基準包括 通過 SysBench 的 MySQL OLTP 性能 Microsoft SQL Server OLTP 性能 具有模擬的 TPC-C 工作負載。
每個 SQL Server VM 配置有兩個虛擬磁盤，一個 100GB 用於啟動，另一個 500GB 用於數據庫和日誌文件。 從系統資源的角度來看，我們為每個虛擬機配置了 16 個 vCPU、64GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。 這些測試旨在監控對延遲敏感的應用程序如何在具有適度但不過分的計算和存儲負載的集群上執行。
SQL Server 測試配置（每個虛擬機）
- 在Windows Server 2012 R2
- 存儲空間：分配 600GB，使用 500GB
- SQL Server 2014的
- 數據庫大小：1,500 規模
- 虛擬客戶端負載：15,000
- 內存緩衝區：48GB
- 測試時長：3 小時
- 2.5 小時預處理
- 30分鐘採樣期
在超融合平台上的 SQL Server TPC-C 測試中，我們研究了混合模式、全閃存 (AF) 模式和全閃存數據縮減 (AF DR) 下整個集群的工作負載平衡。 不出所料，Optane 的 AF 模式表現稍好，總得分為 12,605 TPS，單個虛擬機的得分在 3,148.56 TPS 到 3,152.66 TPS 之間。 這總體上略好於總得分為 12,472 TPS 的非 Optane 版本的 vSAN。 在啟用 DR 的情況下，我們看到 Optane 的總得分達到 12,604 TPS（僅比關閉 DR 時低一個 TPS），單個虛擬機的得分在 3,148.7 TPS 到 3,153.5 TPS 之間。 與 DR 的總得分為 11,969 TPS 的非 Optane 版本相比，這是一個相當大的飛躍。 這裡值得注意的是，Gold CPU 可能是一個限制因素，而對於 Platinum CPU，還有更多優勢。
對於SQL Server TPC-C測試，我們最關注的變量是平均延遲。 交易性能中的小差距不會顯示完整的故事。 在我們的平均延遲測試中，AF Optane 的總得分僅為 16.5 毫秒，單個虛擬機的延遲時間範圍為 14 毫秒至 21 毫秒。 在 Optane 版本上使用 DR 後，聚合的延遲僅為 17 毫秒，單個虛擬機的延遲為 13 毫秒至 21 毫秒。 與非 Optane vSAN 相比，這是一個很大的改進，在沒有 DR 的情況下總得分為 52.5ms，在有 DR 的情況下為 261ms。
系統性能
每個 Sysbench VM 配置了三個虛擬磁盤：一個用於引導 (~92GB)，一個用於預構建數據庫 (~447GB)，第三個用於測試中的數據庫 (400GB)。 從系統資源的角度來看，我們為每個虛擬機配置了 16 個 vCPU、64GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。
Sysbench 測試配置（每個虛擬機）
- 中央操作系統 6.3 64 位
- 存儲空間：1TB，已使用 800GB
- Percona XtraDB 5.5.30-rel30.1
- 數據庫表：100
- 數據庫大小：10,000,000
- 數據庫線程：32
- 內存緩衝區：24GB
- 測試時長：12 小時
- 6 小時預處理 32 個線程
- 1 小時 32 個線程
- 1 小時 16 個線程
- 1 小時 8 個線程
- 1 小時 4 個線程
- 1 小時 2 個線程
對於 Sysbench OLTP，我們查看每個的 8VM 配置。 Optane AF 的總得分為 10,699 TPS，是非 Optane 版本 4,273 TPS 的兩倍多。 啟用 DR 後，Optane 達到 8,668 TPS，而非 Optane 的 DR 為 3,625 TPS。
對於 Sysbench 平均延遲，基於 Optane 的 vSAN 在啟用 DR 的情況下確實能夠以 23.95 毫秒和 29.62 毫秒的總分脫穎而出。 這與啟用 DR 的非 Optane 的 60.05ms 和 71.05ms 相比。 在這兩種情況下，Optane 的延遲都不到一半。
平均第 99 個百分位數的延遲再次表明基於 Optane 的 vSAN 在 DR 開啟時的總得分分別為 42.9 毫秒和 55.63 毫秒，而非 Optane 的 126.02 毫秒和 DR 開啟時為 212.42 毫秒。
VDBench 工作負載分析
在對存儲陣列進行基準測試時，應用程序測試是最好的，綜合測試排在第二位。 雖然不能完美代表實際工作負載，但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線，從而可以輕鬆地在競爭解決方案之間進行同類比較。 這些工作負載提供了一系列不同的測試配置文件，包括“四個角”測試、常見的數據庫傳輸大小測試，以及來自不同 VDI 環境的跟踪捕獲。 所有這些測試都利用通用的 vdBench 工作負載生成器，以及一個腳本引擎來自動化和捕獲大型計算測試集群的結果。 這使我們能夠在各種存儲設備上重複相同的工作負載，包括閃存陣列和單個存儲設備。
簡介：
- 4K 隨機讀取：100% 讀取，128 個線程，0-120% 重複率
- 4K 隨機寫入：100% 寫入，64 線程，0-120% iorate
- 64K 順序讀取：100% 讀取，16 個線程，0-120% 迭代
- 64K 順序寫入：100% 寫入，8 個線程，0-120% 迭代
- 綜合數據庫：SQL 和 Oracle
- VDI 完整克隆和鏈接克隆跟踪
對於 VDBench 測試，我們將只查看 vSAN 的 Optane Supermicro 版本，我們將查看是否啟用 DR（從此處稱為 DR）或關閉（從此處稱為 Raw）。 在我們對峰值 4K 隨機讀取的第一次測試中，Raw 在大約 440K IOPS 之前具有亞毫秒延遲，並以 521,599 毫秒的延遲達到 4.65 IOPS 的峰值。 DR 在超過 1 毫秒之前開始，峰值為 406,322 IOPS，延遲為 7.32 毫秒。
對於 4K 隨機寫入，Raw 運行在 1ms 線下，但一直保持在 150K IOPS 左右，並達到 202,081 IOPS 的峰值，延遲為 8.4ms。 DR 達到約 114K IOPS，延遲為亞毫秒級，峰值為 183,947 IOPS，延遲為 1.43 毫秒，然後性能急劇下降，延遲激增。
接下來我們看看 64K 順序工作負載。 對於讀取，Raw 具有亞毫秒級延遲性能，直到大約 54K IOPS 或 3.5GB/s，峰值為 85,319 IOPS 或 5.33GB/s，延遲為 4.69ms。 DR 在 1 毫秒以上開始，峰值為 73,583 IOPS 或 4.6GB/s，延遲為 4.23 毫秒。
對於 64K 寫入，Raw 在突破 12 毫秒之前僅達到約 1K IOPS，然後以 40,869 IOPS 或 2.55GB/s 的峰值達到 5.58 毫秒的延遲。 DR 始終具有亞毫秒級延遲性能，但峰值僅為 7,303 IOPS 或 456MB/s，延遲為 623μs。
繼續我們的 SQL 工作負載，Raw 在大約 330K IOPS 之前具有亞毫秒級延遲，並以 385,159 毫秒的延遲達到 2.34 IOPS 的峰值。 DR 幾乎一直保持在 1 毫秒以上，峰值顯示為 321,504 IOPS，延遲為 3.02 毫秒。
對於 SQL 90-10，Raw 在突破 300 毫秒之前達到了大約 1K IOPS，並以 363,550 的延遲達到 2.52 IOPS 的峰值。 DR 的峰值為 299,132 IOPS，延遲為 3.26 毫秒。
我們的 SQL 80-20 測試發現 Raw 在不到 277 毫秒的時間內運行超過 1K IOPS，峰值為 332,949 IOPS，延遲為 2.79 毫秒。 DR 的峰值為 285,010 IOPS，延遲為 3.42 毫秒。
接下來是我們的 Oracle 工作負載。 Raw 在大約 262K IOPS 之前具有亞毫秒級延遲，峰值為 323,706 IOPS，延遲為 3.27 毫秒。 DR 達到 211,993 IOPS 的峰值，延遲為 2.07 毫秒，然後再次出現性能下降和延遲峰值。
對於 Oracle 90-10，Raw 在大約 315K IOPS 之前具有亞毫秒級延遲性能，並以 354,590 毫秒的延遲達到 1.67 IOPS 的峰值。 DR 的峰值為 279,356 IOPS，延遲為 2.24 毫秒。
在 Oracle 80-20 測試中，Raw 在 1 毫秒內運行直到大約 273K IOPS，峰值為 322,616 IOPS，延遲為 1.85 毫秒。 DR 能夠達到 263,425 IOPS 的峰值和 2.36 毫秒的延遲。
接下來，我們切換到我們的 VDI 克隆測試，完整和鏈接。 對於 VDI Full Clone Boot，Raw 具有亞毫秒級的延遲性能，直到大約 240K IOPS，然後達到 293,335 IOPS 的峰值和 3.3 毫秒的延遲。 DR 在下降前達到 181,527 IOPS 的峰值和 5.31 毫秒的延遲。
VDI FC Initial Login 的 Raw 開始時間接近 1 毫秒，然後迅速通過並達到 153,513 IOPS 的峰值，延遲為 5.6 毫秒，然後略有下降。 DR 在性能下降和延遲激增之前達到了大約 68K IOPS 和 5.3ms 延遲的峰值。
使用 VDI FC Monday Login，Raw 在大約 58K IOPS 之前具有亞毫秒級延遲，然後以 152,660 毫秒的延遲達到 3.14 IOPS 的峰值。 DR 具有更好的峰值延遲 (1.64ms)，但僅達到 64,201 IOPS 的峰值性能。
對於 VDI LC 引導，Raw 的運行延遲為亞毫秒級，直到大約 170K IOPS，峰值為 209,676 IOPS，延遲為 2.21 毫秒。 使用 DR，它達到 119,036 IOPS 的峰值和 3.99 毫秒的延遲。
轉到 VDI LC 初始登錄，Raw 在 1K IOPS 之前保持在 29ms 以下，並以 92,951ms 的延遲達到 2.62 IOPS 的峰值。 對於 DR，它在略低於 64K IOPS 時達到峰值，延遲大約為 2.3 毫秒，然後下降。
最後，通過查看 VDI LC Monday Login，Raw 在突破 35 毫秒之前達到了大約 1K IOPS，並以 101,997 毫秒的延遲達到 4.65 IOPS 的峰值。 使用 DR，峰值約為 47K IOPS，延遲為 1.82 毫秒，然後性能下降。
結論
VMware 的超融合存儲解決方案有多種形式； 此特定迭代使用四台 Supermicro 2029U-TN24R4T+ 服務器進行計算。 對於存儲，此版本的 vSAN 利用英特爾傲騰 P4800X SSD 形式的英特爾傲騰和英特爾 P4500 固態硬盤形式的 NVME 存儲。 此特定構建是英特爾新精選解決方案的一部分，尤其是面向 VMware vSAN 的英特爾精選解決方案。 它可以被視為經過 VMware 和 Intel 認證的 vSAN ReadyNode，以達到必要的性能指標。
在性能方面，在我們的應用程序工作負載分析中，我們將 vSAN 的 Optane 版本與我們之前在戴爾/東芝設備上測試的 vSAN 全閃存版本進行了對比。 對於 SQL Server，Optane 配置在打開和關閉數據縮減 (DR) 時的得分幾乎相同，總得分為 12,605 TPS（無 DR）和 12,604 TPS（有 DR）。 這標誌著與啟用 DR (11,969 TPS) 的全閃存、非 Optane 版本相比有了相當大的飛躍。 在延遲方面，Optane 版本顯示出顯著改善，無 DR 時的總得分僅為 16.5 毫秒，啟用 DR 時僅為 17 毫秒，不到 vSAN 6.2 上 SAS 全閃存版本延遲的一半。 借助 Sysbench，vSAN 的 Optane 版本的 TPS 是全閃存版本的兩倍多，總得分為 10,699 TPS Raw 和 8,668 TPS（啟用 DR）。 這種趨勢隨著延遲和最壞情況的延遲而持續，在這兩種情況下都不到一半，總得分分別為 DR 的平均 24 毫秒和 30 毫秒，以及最壞情況的 60 毫秒和 71 毫秒。
對於我們的 VDBench，Optane vSAN 在原始性能方面有幾個亮點，包括 4K IOPS 的 522K 讀取、4K IOPS 的 202K 寫入、64GB/s 的 5.33K 讀取和 64GB/s 的 2.55K 寫入。 啟用 DR 後，我們看到 vSAN 在 406K 讀取時達到 4K IOPS，寫入時達到 184K IOPS（隨後急劇下降），在 4.6K 時讀取速度為 64GB/s，在 456K 時寫入速度僅為 64MB/s，但延遲低於 1ms。 vSAN 繼續表現強勁，SQL 達到 385K IOPS，364-90 達到 10K IOPS，333-80 達到 20K IOPS，DR 達到 322K IOPS，299-90 達到 10K IOPS，285-80 達到 20K IOPS。 在 Oracle 中，Raw 在 324-355 中具有 90K IOPS、10K IOPS 和 323-80 中的 20K IOPS 的相當強勁的性能。 Oracle 中的 DR 也很強大，峰值為 212K IOPS（下降前），279-90 為 10K IOPS，263-80 為 20K IOPS。
包含 Optane SSD 顯然對 vSAN 的寫入性能有很大影響。 這甚至考慮到驅動器只有 375GB，而 vSAN 支持 600GB 的寫入層驅動器容量。 因此，我們有可能通過擁有更大的驅動器來獲得更多的寫入性能。 這些 Intel 配置也有相當大的上行潛力，因為更快的互連是合格的，並且使用了更激進的 RAM 和 CPU 配置，就像在 Plus 選項中一樣。 英特爾現在還為讀取層提供了更快/更好的驅動器； P4510 是對 P4500 的重大改進。 重點是，與其將這些數據作為 Optane 的最佳表現，不如將這些數據更多地用於設置中端服務器配置的基線，如果場合需要，這些配置還有更多的東西可以提供。 同樣重要的是要考慮到 vSAN 處於有利地位，可以在新的存儲和服務器技術進入市場時繼續從中獲益——這對於傳統設備供應商來說要實現得多。
然而，要點很明顯，隨著 vSAN 的成熟，VMware 明智地走在了英特爾傲騰固態硬盤等新興技術的前沿。 這使 vSAN 在 HCI 市場的性能方面具有顯著優勢。 雖然許多 HCI 解決方案很樂意滿足具有中等性能配置文件的 ROBO 用例的需求，但 vSAN 繼續尋找最佳合作夥伴來創建在邊緣同樣令人滿意的解決方案，因為它們正在為下一代數據中心奠定基礎看起來像在 SDDC 世界中。 基於 Optane 的 vSAN 集群非常適合後者，為所有應用程序工作負載提供盡可能最佳的寫入延遲。
