NetApp EF570 全閃存陣列評測

大約在去年的這個時候，NetApp 在其大數據分析產品組合中推出了幾款新產品。 在宣布的產品中，有公司最新的全閃存陣列 (AFA)，即 NetApp EF570。 EF570 是一款中端 AFA，專為 2U 系統的高性能、高可用性、簡單性和強大的性價比而設計。 

大約在去年的這個時候，NetApp 在其大數據分析產品組合中推出了幾款新產品。 在宣布的產品中，有公司最新的全閃存陣列 (AFA)，即 NetApp EF570。 EF570 是一款中端 AFA，專為 2U 系統的高性能、高可用性、簡單性和強大的性價比而設計。 

NetApp 表示 EF570 具有“極端”性能，雖然我們不喜歡誇大其詞，但該公司引用了一些非常令人印象深刻的數字。 NetApp 表示，該陣列可以達到 21 萬以上的 IOPS 和 100GB/s 的連續帶寬，所有這些都具有低於 32 微秒的延遲。 所有這些性能都專門針對混合工作負載環境，包括大數據分析。 除了承諾的性能之外，該陣列還支持多種高速主機接口，包括 25Gb 光纖通道、100Gb iSCSI、12Gb InfiniBand、100Gb SAS 和 XNUMXGb NVMe over InfiniBand。 這不僅有助於達到標稱速度，還有助於保護存儲網絡投資向前發展。

與其他幾個 NetApp 系統一樣，高可用性是內置的； 在這裡，EF570 也不例外。 該陣列沒有單點故障，並帶有完全冗餘的 I/O 路徑和自動故障轉移。 它還附帶報告的六個 9 的可用性。 憑藉這些功能，EF570 還提供了常見的數據管理功能，包括快照、卷複製和鏡像。 同時，SANtricity OS 確保數據完整性，同時防止靜默數據損壞。 該陣列能夠通過後台監控和廣泛的診斷數據和分析來檢測和解決大多數問題。

NetApp EF570 採用模塊化設計，易於擴展。 一個 2U 系統可以支持高達 367TB 的容量，加上四個擴展架可以使總容量高達 1.8PB。 通過 SANtricity GUI，用戶可以在不增加管理複雜性的情況下進行擴展，並在 10 分鐘內訪問他們的數據。 這種易於擴展和高容量使 EF570 具有很強的性價比。 擴展到 1.8PB 的能力也使該陣列成為一個有吸引力的選擇，可以幫助避免未來的叉車式升級。

NetApp EF570 規格

設計和建造

如前所述，EF570 是一個 2U AFA。 與絕大多數 NetApp 產品（至少是最近的產品）一樣，邊框看起來與時尚的裸金屬蓋和左側的通風和 NetApp 品牌相同。 擋板下方是二十四個 2.5 英寸驅動器托架，垂直穿過陣列的前部。 陣列的右側有 NetApp 品牌，左側有電源、注意和定位按鈕和 LED。

翻轉到設備背面，可以清楚地看到高可用性/冗餘設計。 該陣列是從左到右的鏡像。 底部充滿了 PSU。 上半部分有兩個控制器。 控制器配置有四端口 32Gb HIC（主機接口卡），每個控制器利用兩個 ASIC。 未使用板載 FC 端口，這將為每個控制器提供一個額外的 ASIC 路徑。 對於我們的測試，我們在雙 32Gb 交換機上使用了最佳實踐佈局。

管理

在我們之前的 NetApp 評論中，我們研究了該公司的 ONTAP 操作系統。 雖然 ONTAP 是更流行和知名的操作系統，但 EF 系列實際上由 SANtricity 操作系統提供支持。 

SANtricity 的主屏幕為管理員提供了整個系統的佈局。 可以很容易地看到性能（可以分解為 IOPS、MB/s 和 CPU，或者按不同的時間範圍查看）、容量以及存儲層次結構。 屏幕左側是選項卡：主頁、存儲、硬件、設置和支持。 

在“存儲”主選項卡下，有幾個選項可供選擇以深入了解存儲正在做什麼，包括：池和卷組、卷、主機、性能、快照、異步鏡像和同步鏡像。 

單擊 Pools & Volume Groups，我們可以查看所有容量或保留容量。 從那裡，用戶可以創建新的池或卷組，向它們添加容量，或編輯它們。 

在卷下，用戶可以創建或編輯卷以及獲取有關當前卷的信息，例如名稱、狀態、是否啟用精簡配置、分配位置、有多少 LUN、它們屬於哪個池或卷組，以及容量。

性能一直是我們感興趣的話題，對於想要了解其存儲性能的管理員，他們可以查看存儲下的性能部分。 在這裡，用戶會根據某些指標獲得一些不同的性能視圖，並且可以將其視為邏輯視圖、物理視圖或應用程序和工作負載視圖。 還有一個選項可以從整個 AFA 向下鑽取到池和卷組或僅卷。 

深入了解物理性能，可以選擇查看控制器、通道或驅動器的性能。 

正如預期的那樣，“硬件”選項卡顯示硬件及其運行方式。 在正面，用戶可以檢查驅動器以查看是否一切正常運行以及是否需要更換某些東西（用顏色表示，藍色表示正常）。 

硬件的背麵類似，只是這次控制器和 PSU 有顏色編碼，以確保它們正常運行或需要解決。 

“設置”選項卡顯示有關係統和 iSCSI 設置或用戶想要添加的其他設置的一般信息。 此選項卡下還有各種配置選項。 

性能

應用程序工作負載分析

NetApp EF570 的應用程序工作負載基準包括通過 SysBench 的 MySQL OLTP 性能和使用模擬 TPC-C 工作負載的 Microsoft SQL Server OLTP 性能。 在每個場景中，我們都為陣列配置了 26 個 Toshiba PX04SV SAS 3.0 SSD，並配置了兩個 12 驅動器 RAID10 磁盤組，每個控制器固定一個。 這留下了 2 個 SSD 作為備用。 然後創建了兩個 5TB 的捲，每個磁盤組一個。 在我們的測試環境中，這為我們的 SQL 和 Sysbench 工作負載創建了平衡負載。

SQL Server 性能

每個 SQL Server VM 都配置有兩個虛擬磁盤：100GB 卷用於啟動，500GB 卷用於數據庫和日誌文件。 從系統資源的角度來看，我們為每個虛擬機配置了 16 個 vCPU、64GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。 雖然我們之前測試的 Sysbench 工作負載在存儲 I/O 和容量方面使平台飽和，但 SQL 測試正在尋找延遲性能。

此測試使用在 Windows Server 2014 R2012 來賓虛擬機上運行的 SQL Server 2，並由 Quest 的數據庫基準工廠進行壓力測試。 雖然我們對該基準的傳統用法是在本地或共享存儲上測試 3,000 規模的大型數據庫，但在本次迭代中，我們專注於在 NetApp EF1,500 上均勻分佈四個 570 規模的數據庫（每個控制器兩個虛擬機）。

SQL Server 測試配置（每個虛擬機）

• 在Windows Server 2012 R2
• 存儲空間：分配 600GB，使用 500GB
• SQL Server 2014的
  • 數據庫大小：1,500 規模
  • 虛擬客戶端負載：15,000
  • 內存緩衝區：48GB
• 測試時長：3 小時
  • 2.5 小時預處理
  • 30分鐘採樣期

SQL Server OLTP Benchmark Factory LoadGen 設備

• 戴爾易安信 PowerEdge R740xd 虛擬化 SQL 4 節點集群
  • 8 個 Intel Xeon Gold 6130 CPU，用於集群中的 269GHz（每個節點兩個，2.1GHz，16 核，22MB 緩存）
  • 1TB RAM（每個節點 256GB，16GB x 16 DDR4，每個 CPU 128GB）
  • 4 個 Emulex 16GB 雙端口 FC HBA
  • 4 個 Mellanox ConnectX-4 rNDC 25GbE 雙端口網卡
  • VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU

對於 SQL Server，NetApp EF570 以快速且一致的方式執行，在所有四個虛擬機上測得 3,160 TPS 和變化，總計為 12,642.245 TPS。

查看延遲，所有虛擬機均以一致的 3 毫秒響應時間執行。

系統性能

每 系統平台 VM 配置了三個虛擬磁盤，一個用於啟動 (~92GB)，一個用於預構建數據庫 (~447GB)，第三個用於測試中的數據庫 (270GB)。 從系統資源的角度來看，我們為每個虛擬機配置了 16 個 vCPU、60GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。 Load gen 系統是 Dell R740xd 服務器。

Dell PowerEdge R740xd 虛擬化 MySQL 4 節點集群

• 8 個 Intel Xeon Gold 6130 CPU，用於集群中的 269GHz（每個節點兩個，2.1GHz，16 核，22MB 緩存）
• 1TB RAM（每個節點 256GB，16GB x 16 DDR4，每個 CPU 128GB）
• 4 個 Emulex 16GB 雙端口 FC HBA
• 4 個 Mellanox ConnectX-4 rNDC 25GbE 雙端口網卡
• VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU

Sysbench 測試配置（每個虛擬機）

• 中央操作系統 6.3 64 位
• 存儲空間：1TB，已使用 800GB
• Percona XtraDB 5.5.30-rel30.1
  • 數據庫表：100
  • 數據庫大小：10,000,000
  • 數據庫線程：32
  • 內存緩衝區：24GB
• 測試時長：3 小時
  • 2 小時預處理 32 個線程
  • 1 小時 32 個線程

對於 Sysbench，我們測試了幾組 VM，包括 8、16 和 32 個 VM。 這些測試的目的是展示給定陣列在中度至完全飽和工作負載下的性能表現。 在性能結果方面，並非所有評論都讓我們大吃一驚，但 NetApp EF570 做到了這一點。 在 8VM 負載下，EF570 測得 22,951 TPS，超過了大多數陣列的峰值。 EF16 選擇多達 570 個虛擬機，沒有任何放緩的跡象，上升到令人難以置信的 39,635 TPS。 但是，在 32 個 VM 時，EF570 簡直就是一個怪物，峰值高達 57,347 TPS，並且不是因為缺少 I/O 而停止，而是完全飽和了我們 8 台主機上的 CPU。 說 EF570 很快是委婉的說法； 它是一個怪物。

查看我們的 8、16 和 32 VM 工作負載的平均延遲，NetApp EF570 繼續給我們留下深刻印象。 在 8 個虛擬機時，它測得的時間很低，只有 11.15 毫秒，當負載增加到 16 個虛擬機時，它會增加到只有 12.98 毫秒。 在大多數陣列開始失去動力的 32vms 處，EF570 回升至僅 17.98ms。

查看第 99 個百分位數的延遲，NetApp EF570 的本色開始閃耀。 它不僅能夠保持強大的吞吐量，而且峰值延遲非常低。 這將向您表明，即使這個數組壓垮了 I/O，它也是以一種可預測且一致的方式進行的。

VDBench 工作負載分析

在對存儲陣列進行基準測試時，應用程序測試是最好的，綜合測試排在第二位。 雖然不能完美代表實際工作負載，但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線，從而可以輕鬆地在競爭解決方案之間進行同類比較。 這些工作負載提供了一系列不同的測試配置文件，包括“四個角”測試、常見的數據庫傳輸大小測試，以及來自不同 VDI 環境的跟踪捕獲。 所有這些測試都利用通用的 vdBench 工作負載生成器，以及一個腳本引擎來自動化和捕獲大型計算測試集群的結果。 這使我們能夠在各種存儲設備上重複相同的工作負載，包括閃存陣列和單個存儲設備。 在陣列端，我們使用 Dell PowerEdge R740xd 服務器集群：

簡介：

• 4K 隨機讀取：100% 讀取，128 個線程，0-120% 重複率
• 4K 隨機寫入：100% 寫入，64 線程，0-120% iorate
• 64K 順序讀取：100% 讀取，16 線程，0-120% 迭代
• 64K 順序寫入：100% 寫入，8 個線程，0-120% 迭代
• 綜合數據庫：SQL 和 Oracle
• VDI 完整克隆和鏈接克隆跟踪

在 4K 峰值讀取性能中，EF570 以亞毫秒級延遲開始，並在 1K IOPS 左右短暫地超過 510ms，然後回落到 1ms 以下，直到接近 1 萬 IOPS。 該陣列的峰值約為 1.03 萬次 IOPS，延遲為 2 毫秒，然後下降了一些。

對於 4K 隨機寫入性能，EF570 在打破 200 毫秒之前達到了剛剛超過 1K IOPS。 EF570 繼續達到約 223K IOPS 的峰值，延遲為 4 毫秒，然後略有下降。

切換到 64K 順序工作負載時，EF570 具有亞毫秒級延遲性能，直到大約 190K IOPS 或 12GB/s，然後以 247,692ms 的延遲達到 15.5 IOPS 或 2.1GB/s 的峰值。

對於 64K 寫入，AFA 在接近結束或 80K IOPS (5GB/s) 之前具有亞毫秒級延遲。 該陣列在 80,675 毫秒的延遲時達到 5.04 IOPS 或 3.2GB/s 的峰值。

繼續我們的 SQL 工作負載，EF570 能夠達到 1,029,910 IOPS 的峰值，延遲為 818μs。

對於 SQL90-10，陣列峰值為 876,833 IOPS，延遲為 957μs。

SQL 80-20 是第一個在峰值附近超過 1 毫秒的 SQL 測試，峰值性能為 740,691 IOPS，延遲為 1.2 毫秒。

接下來是我們的 Oracle 工作負載。 EF570 再次在峰值附近超過 1 毫秒，最高性能為 721,615 IOPS，延遲為 1.35 毫秒。 

Oracle 90-10 始終具有亞毫秒級延遲性能，峰值得分為 875,567 IOPS，延遲為 675μs。

Oracle 80-20 始終保持亞毫秒延遲性能，峰值得分為 738,238 IOPS，延遲為 808μs。

接下來，我們切換到我們的 VDI 克隆測試，完整和鏈接。 對於 VDI 完整克隆啟動，EF570 在 835 毫秒內達到了大約 1K IOPS，並以 841,945 毫秒的延遲達到了 1.2 IOPS 的峰值。 

通過 VDI FC 初始登錄，EF570 在打破 250 毫秒之前達到了 1K IOPS。 它繼續達到 262,141 IOPS 的峰值，延遲為 3.3 毫秒。

對於 VDI FC Monday Login，EF570 在大約 300K IOPS 之前具有亞毫秒級延遲，然後以 331,146 毫秒的延遲達到 1.5 IOPS 的峰值。

對於 VDI LC 引導，EF570 始終具有亞毫秒級延遲，峰值得分為 519,975 IOPS，延遲為 980μs。

VDI LC 初始登錄再次看到延遲保持在 1 毫秒以下，峰值得分為 269,995 IOPS，延遲為 944 微秒。

對於 VDI LC 星期一登錄，EF570 能夠將延遲保持在 1 毫秒以下，直到大約 270K IOPS 並達到 299,663 IOPS 的峰值，延遲為 1.7 毫秒。 

結論

NetApp EF570 是針對中端的 2U 全閃存陣列。 EF570 採用模塊化設計，使其具有高可用性並能夠輕鬆擴展。 該陣列的一個非常有趣的方面是它的性能。 NetApp 表示，EF570 可以達到高達 21 萬次的 IOPS 和高達 100GB/s 的順序帶寬。 該公司繼續表示，所有這些都可以在不到 XNUMXμs 的時間內完成。 這種高性能，加上其在管理和擴展方面的高可用性和簡單性，使其成為從性價比角度來看的一個有吸引力的選擇。

在應用程序性能方面，NetApp EF570 從出色的性能到為我們實驗室創造的新記錄不等。 SQL Server 性能表明 EF570 能夠提供非常嚴格和一致的性能，根據 Benchmark Factory 的測量，我們的四個 SQL VM 的測量時間為 3 毫秒。 在我們的縮放 Sysbench 基準測試中，EF570 得分如此之高，以至於我們在陣列用完可用 I/O 之前就已經飽和了我們的計算集群。 在 8 個虛擬機上，我們測得 22.9K TPS，或者我們測試過的大多數閃存陣列開始耗盡的大致水平。 在 16 個虛擬機上，EF570 達到了 39.6K TPS，打破了我們在 RAID0 NVMe-oF 閃存陣列上測得的 Sysbench 測試中的先前最高記錄。 在 32 個虛擬機上，我們達到了測試集群的峰值，達到了創紀錄的 57.3K TPS 結果。 在所有這些中，平均和第 99 個百分位數的延遲都很低且非常平滑。 不用說，我們印象深刻。

在我們的 VDBench 結果中，EF570 表現強勁，在一些基準測試中突破了 1 萬次 IOPS，包括 4K 讀取（1.03 萬次，延遲僅為 2 毫秒）和 SQL（1,029,910 IOPS，延遲僅為 818μs）。 在順序方面，EF570 能夠分別以 15.5 毫秒和 5.04 毫秒的延遲達到 2.1GB/s 的讀取速度和 3.2GB/s 的寫入速度。 該陣列還有其他一些值得一提的高性能/低延遲數字。 在 SQL 90-10 中，它達到了 877K IOPS（957μs），在 SQL 80-20 中，它達到了 741K IOPS（1.2ms），在 Oracle 中，我們看到了 722K IOPS（1.35ms），在 Oracle 90-10 中，我們註冊了 876K IOPS (675μs)，對於 Oracle 80-20，我們記錄了 738K IOPS (808μs)，對於 VDI FC Boot，我們記錄了 842K IOPS (1.2ms)，對於 VDI LC Boot，我們看到了 520K IOPS (980μs)。

NetApp 將 EF570 定位於中端市場，但這主要是因為可擴展性。 通常，當我們想到中端市場時，該術語會讓人聯想到“足夠好”以完成工作的價格價值和性能。 讓我們在這裡說清楚； EF570 的價格可能處於中端市場，但它提供的企業級性能配置文件讓我們在實驗室中看到的一切都大吃一驚。 此外，在一些測試（32VM Sysbench）中，我們達到了我們的計算集群的頂峰，這意味著可能會有更多的性能。 當涉及要求苛刻的塊存儲工作負載（如分析和新興的 AI 式用例）時，延遲和可用性意味著金錢，擁有專為該工作設計的存儲工具非常重要。 NetApp EF570 是適用於這些工作負載的完美解決方案，它可以讓那些要求苛刻的數據庫以我們迄今見過的最快方式交付智能。

NetApp 閃存陣列

討論這篇評論

註冊 StorageReview 時事通訊