首頁 Enterprise NetApp AFF A800 NVMeOF 評測

NetApp AFF A800 NVMeOF 評測

by StorageReview 企業實驗室
NetApp AFF A800 NVMeoF

NetApp AFF A800 會很好地滿足那些在市場上尋找高性能全閃存存儲陣列的人的需求。 端到端 NVMe 陣列提供強大的性能,來自 NetApp 強大的 AFF 陣列系列。 我們之前已經通過光纖通道審查了 A800,發現它是獲得我們編輯選擇獎的表演者的野獸。 對於本次審查,我們僅在這次利用 NVMe over Fabrics (NVMeOF) 測試同一陣列。


NetApp AFF A800 會很好地滿足那些在市場上尋找高性能全閃存存儲陣列的人的需求。 端到端 NVMe 陣列提供強大的性能,來自 NetApp 強大的 AFF 陣列系列。 我們之前已經通過光纖通道審查了 A800,發現它是獲得我們編輯選擇獎的表演者的野獸。 對於本次審查,我們僅在這次利用 NVMe over Fabrics (NVMeOF) 測試同一陣列。

由於這是後續審核,我們不會涉及設計和構建、規範或管理等內容。 我們的 初步審查 很好地進入了這些領域中的每一個。 審查的設置與不同的網絡接口基本相同,以查看性能差異。 應該注意的是,這不完全是同類比較。 該陣列為不同用戶的需求提供了各種連接,我們正在審查不同的類型,以便讓這些用戶了解對哪種連接選項有什麼期望。

NVMeOF 於 2014 年首次推出,其概念是通過網絡使用傳輸協議,而不是僅通過 PCIe 總線利用 NVMe 設備。 NVM Express, Inc. 於 2016 年發布了 NVMeOF 標準。NVMeOF 允許 NVMe 主機連接到 NVMe 目標存儲,同時保持低延遲。 一般的想法是在不顯著增加延遲的情況下獲得更高的性能。 迄今為止,來自不同供應商的許多方法都支持協議,或者可以同時在多種模式下運行。 配備 ONTAP 的 AFF A800 能夠同時運行 CIFS、NFS、iSCSI、FCP 和 FC NVMeOF,所有這些都毫不費力。 並非所有平台都是以這種方式構建的,即使是 NetApp EF600(設計時考慮到的目標略有不同)也可以在 FCP 或 FC NVMeOF 中運行,但不能同時在兩者中運行。

性能配置

我們的 NetApp AFF A800 配置包括 8 個 32Gb FC 端口,安裝了 24 個 1.92TB NVMe SSD。 在我們的 A24 中部署的 1.92 個 800TB SSD 中,我們將它們分成兩個 RAID-DP 聚合,實際上使用了 23 個 SSD 和兩個半分區作為熱備用。 每個 SSD 的一半被分配給兩個控制器,因此每個控制器都可以利用所有安裝的 SSD 的性能。 該陣列通過兩個 Brocade G32 交換機以 620Gb 連接,然後有 16 個 32Gb 鏈接到 12 個運行 SLES 740 SP12 的 Dell PowerEdge R4xd 服務器。

每台服務器都配備了 2 個 350GB LUN,總存儲空間為 8.4TB。

性能 

在對存儲陣列進行基準測試時,應用程序測試是最好的,綜合測試排在第二位。 雖然不能完美代表實際工作負載,但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線,從而可以輕鬆地在競爭解決方案之間進行同類比較。 這些工作負載提供了一系列不同的測試配置文件,包括“四個角”測試、常見的數據庫傳輸大小測試,以及來自不同 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

NVMeOF 與 A800 的主要性能優勢是提高讀取性能和降低延遲。 我們之前的測試重點關注 VMware 內部使用 FCP 協議的性能,VMDK 附加到多個虛擬機,我們的 NVMeOF 測試重點關注裸機性能。 因此,您無法與我們現有的數據進行直接的一對一比較。 還需要注意的是,為了在我們所有的存儲陣列中進行一致的測試,我們保持每個存儲陣列的線程數相同。 通過在 A800 上進行 NVMeOF 測試,我們確實注意到在延遲顯著增加之前完成測試的一些區域。 首先,這表明該平台的性能非常出色,以令人印​​象深刻的性能統計數據實現了低延遲。 不利的一面是,一些性能被擱置在桌面上。 NetApp 表示,在某些情況下,A800 可以驅動比我們測量的更高的性能。

從 4K 讀取開始,採用 NVMeOF 的 A800 以 217,460 IOPS 的速度開始,延遲僅為 196.8µs,然後以 2,184,220 IOPS 的速度達到峰值,延遲為 1.22ms。

對於 4K 寫入,該陣列以 48,987 IOPS 和 196 微秒的延遲開始,然後以 465,445 IOPS 的峰值達到 2.44 毫秒的延遲。

接下來是我們的 64K 順序工作負載。 對於 64K 讀取,A800 能夠始終保持亞毫秒級延遲,峰值性能約為 403K IOPS 或 25GB/s,延遲為 800µs,然後略有下降。

對於 64K,使用 NVMeOF 寫入 A800 開始很強,一直保持在 1ms 以下,直到大約 110K IOPS 或大約 7GB/s,然後以 120,314 IOPS 或 7.52GB/s 達到峰值,延遲為 1.48ms。

我們的下一批基準是我們的 SQL 測試。 在 SQL 中,A800 始終保持在 1 毫秒以下,峰值為 1,466,467 IOPS,延遲僅為 496.6 微秒,令人印象深刻。

對於 SQL 90-10,採用 NVMeOF 的 A800 再次表現出令人印象深刻的亞毫秒級延遲性能,從 139,989 IOPS 開始,峰值為 1,389,645 IOPS,延遲僅為 539.6µs。

SQL 80-20 再次出現亞毫秒級延遲,峰值為 1,108,068 IOPS,延遲為 658µs。

繼續我們的 Oracle 工作負載,採用 NVMeOF 的 A800 保持在 1 毫秒以下,峰值得分為 1,057,570 IOPS,延遲為 860.4 微秒。

在 Oracle 90-10 中,A800 以 118,586 IOPS 開始,峰值為 1,140,178,​​397.6 IOPS,延遲為 XNUMXµs。

在 Oracle 80-20 中,我們再次看到 A800 從 104,206 IOPS 開始一直具有亞毫秒級延遲,並在 1,003,577µs 延遲時達到 468.8 IOPS 的峰值。

結論

NetApp AFF A800 是一個 4U 的全閃存陣列,支持塊和文件訪問,以及端到端 NVMe 支持。 A800 針對那些需要大量性能和大量存儲的最苛刻工作負載的用戶,最大有效容量為 316.8PB。 雖然我們的第一個 獲獎評論 通過傳統光纖通道查看此陣列,這篇評論利用 NVMe over Fabrics 來了解情況如何。

對於我們的 VDBench 工作負載,NetApp AFF A800 全面提供了一組令人印象深刻的數字。 在我們基本的四個角落運行中,我們看到了 4 萬 IOPS 讀取和 2.2K IOPS 寫入的隨機 465K 峰值性能。 在我們連續的 64K 工作負載中,我們看到 25GB/s 的讀取速度和 7.52GB/s 的寫入速度。 在我們的 SQL 工作負載中,我們看到了 1.5 萬 IOPS 的峰值,SQL 90-10 看到了 1.4 萬 IOPS,SQL 80-20 看到了 1.1 萬 IOPS。 我們的 Oracle 測試顯示了令人印象深刻的 1.1 萬 IOPS,Oracle 90-10 給了我們 1.14 萬 IOPS,而 Oracle 80-20 有 1 萬 IOPS。 更令人印象深刻的是 SQL 和 Oracle 工作負載始終保持在 1 毫秒以下的延遲。

儘管我們在為 NVMeOF 配置的 A800 上看到了很好的結果,尤其是在讀取性能方面,但值得注意的是,該系統仍有更多優勢。 在我們的測試中,負載生成服務器都是基於 VMware 管理程序的,這又增加了一層複雜性。 此外,VMware 目前並不完全支持 NVMeOF。 對於希望通過 NetApp 系統充分利用 NVMeOF 的主流企業,裸機將帶來最佳性能。 也就是說,許多人希望在混合配置中使用 NVMeOF ONTAP 系統,同時使用結構和標準光纖通道連接。 無論哪種情況,NetApp 在採用和部署領先一代技術方面繼續處於領先地位,以確保他們的陣列隨時準備好滿足客戶的任何需求。 A800 在這方面做得特別好,這就是我們在初步審查中授予它編輯選擇獎的原因。 NVMeOF 增加了巨大的性能提升,這應該會吸引那些需要最大吞吐量和微秒級延遲的企業,以實現其關鍵業務應用程序。

在 Reddit 上討論