NetApp AFF C190 評測

NetApp C190 是一款全閃存統一存儲陣列，面向 SMB 和邊緣用例，採用緊湊的 2U 外形。 C190 使用 NetApp 功能豐富的 ONTAP 軟件，可提供 NetApp 用戶所喜愛的強大數據服務。 該陣列專為渠道設計，在競爭激烈的入門級存儲市場中為經銷商提供低成本選擇，且無需犧牲數據縮減等高級功能。

NetApp C190 是一款全閃存統一存儲陣列，面向 SMB 和邊緣用例，採用緊湊的 2U 外形。 C190 使用 NetApp 功能豐富的 ONTAP 軟件，可提供 NetApp 用戶所喜愛的強大數據服務。 該陣列專為渠道設計，在競爭激烈的入門級存儲市場中為經銷商提供低成本選擇，且無需犧牲數據縮減等高級功能。

去年夏天推出的 NetApp C190 試圖實現兩個目標。 首先，C190 幫助 NetApp 的大客戶在邊緣滿足數據存儲需求。 這是一種運行完整 ONTAP 堆棧的經濟高效的解決方案。 C190 的第二個目標是吸引那些認為 NetApp 解決方案可能過於昂貴的小型客戶。 在這兩種情況下，NetApp 似乎都在 C190 上運行良好。 聽起來大約一半的 C190 銷售額是 NetApp 的淨新客戶。 這顯然分裂了 NetApp 的雙模式策略的差異。

為了幫助保持 C190 的成本效益，NetApp 做了一些事情。 首先，他們已經對 960GB NVMe SSD 進行了標準化，這意味著他們不需要庫存和支持大量 SKU。 其次，雖然它運行 ONTAP 並且沒有刪除任何服務，但 C190 無法在物理上擴展到其 24 個托架之外。 這在它和 NetApp 的主線 A 系列陣列（如 A200 系列）之間提供了一些緩衝。 即便如此，假設數據縮減率為 3:1，客戶仍然可以期望從裝有 55 個 SSD 的 C190 中獲得約 24TB 的容量。 C190 也可以配置更少的驅動器，因為還提供 8、12 和 18 個驅動器配置。

如果容量是一個問題，NetApp 有很多選擇，包括支持雲分層和基於雲的捲。 C190 支持所有主要的公共雲，例如 Google Cloud、Amazon Web Services (AWS)、Microsoft Azure、IBM Storage Cloud 和阿里雲。 最終結果是客戶可以利用低成本的雲產品來擴展他們的 C190 的容量，從而減輕他們的數據增長速度可能超過 C190 物理處理能力的擔憂。

考慮到目標以及 C190 的許多客戶都是 NetApp 的新客戶這一事實，設置和管理的簡單性是關鍵。 即使渠道合作夥伴進行初始安裝，簡化 C190 的上線過程對於潤滑車輪以減少摩擦也很重要。 NetApp 聲稱可以在 10 分鐘內配置工作負載，並且它們提供 一張三頁的海報，讓系統上線. 我們的實驗室可能不是最好的比較對象，因為我們已經在實驗室中看到了六個 ONTAP 系統，所以我們從拆箱到 LUN 配置的速度要快一些。 NetApp 提供了一個快速上線的嚮導，以及適用於 Oracle、Microsoft SQL、MySQL、MongoDB 和 VMware 等流行應用程序的內置工作流。

對於我們的審查系統，我們有一個 C190，其中一半裝有 960GB SSD。 雙控制器通過 10GbE（無交換機）電纜連接在一起，我們通過八個板載 16GB 光纖通道端口共享存儲，每個控制器四個。 雖然 NetApp 沒有列出這些系統的建議價格，但我們被告知這些系統的售價不到 20,000 美元。

NetApp AFA C190 規格

NetApp C190 設計和構建

當 NetApp 選擇他們喜歡的設計時，他們會真正堅持下去。 陣列的前部有明顯的灰色驅動器托架，NetApp 以此聞名。 24 盤位配置在陣列的前面填滿了盤位，但根據客戶為其型號選擇購買的 SSD 數量，您會發現填充的和空白的驅動器盒混合在一起。

翻到後面，根據網絡的配置方式，有兩種不同的設計； 我們使用了統一的、無開關的配置。 每個主機的背面中間都有一個裂口，兩側各有一個鏡像。 底部有風扇和 PSU。 每側的頂部是網絡和互連，以及右側的管理端口和 USB 端口。

在每個控制器內部，我們看到 NetApp 和其他一級供應商以其密集而緊湊的設計而聞名。 沒有閒置的空間，可見對冷卻、熱管理和電源保護的關注。 對於入門級全閃存陣列，客戶無需擔心各種操作條件下的平台穩定性。

NetApp C190 性能

NetApp AFF C190 測試配置

• ONTAP 9.7P6
• 12 個 960GB SSD（兩個 RAID-DP 聚合）
• 8 個 16Gb FC 連接

SQL Server 性能

StorageReview 的 Microsoft SQL Server OLTP 測試協議採用事務處理性能委員會的基準 C (TPC-C) 的最新草案，這是一種模擬複雜應用程序環境中活動的在線事務處理基準。 TPC-C 基準比綜合性能基準更接近於衡量數據庫環境中存儲基礎設施的性能優勢和瓶頸。

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

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

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

• 在Windows Server 2012 R2
• 存儲空間：分配 600GB，使用 500GB
• SQL Server 2014的

• • 數據庫大小：1,500 規模
  • 虛擬客戶端負載：15,000
  • 內存緩衝區：48GB

• 測試時長：3 小時

• • 2.5 小時預處理
  • 30分鐘採樣期

對於我們的平均延遲 SQL Server 基準測試，我們同時測試了 4 個虛擬機和 8 個虛擬機，總分分別為 29 毫秒和 72.5 毫秒。

Sysbench MySQL 性能

我們的第一個本地存儲應用程序基準測試包括通過 SysBench 測量的 Percona MySQL OLTP 數據庫。 該測試測量平均 TPS（每秒事務數）、平均延遲和平均 99% 延遲。

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

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

• 中央操作系統 6.3 64 位
• Percona XtraDB 5.5.30-rel30.1

• • 數據庫
    • 桌子：100
    • 大小：10,000,000
    • 主題：32
  • 內存緩衝區：24GB

• 測試時長：3 小時

• • 2 小時預處理 32 個線程
  • 1 小時 32 個線程

使用 Sysbench OLTP，我們測試了 8 個虛擬機，總得分為 7,863 TPS，單個虛擬機的運行速度從 980 TPS 到 987 TPS。

對於 Sysbench 平均延遲，我們看到總得分為 32.6 毫秒，單個虛擬機的範圍從 32.4 毫秒到 32.67 毫秒不等。

對於我們最壞情況下的延遲（第 99 個百分位），C190 的總延遲為 96.4 毫秒，單個虛擬機的延遲範圍為 95.13 毫秒到 98.05 毫秒。

VDBench 工作負載分析

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

簡介：

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

對於隨機 4K 讀取，NetApp C190 以亞毫秒延遲開始，直到約 200K IOPS，然後以約 260K IOPS 和 13ms 延遲達到峰值，然後略有下降。

4K 隨機寫入也在 1 毫秒以下開始，然後以大約 25K IOPS 超過並繼續以 74,410 毫秒的延遲達到 27.4 IOPS 的峰值。

接下來我們看看我們的 32K 隨機 I/O 測試。 對於讀取，C190 在達到約 50K IOPS 之前具有亞毫秒級延遲性能，並以 100,894 毫秒的延遲達到 7.7 IOPS 的峰值。

32K 隨機寫入短暫地看到延遲低於 1 毫秒，並在 29,772 毫秒的延遲下達到 17.2 IOPS 的峰值。

接下來是我們研究 64K 的順序工作負載。 對於 64K 讀取，陣列保持在 1ms 以下，直到大約 35K IOPS 或 2.2GB/s。 C190 在 66,472 毫秒的延遲時達到 4.2 IOPS 或 11.1GB/s 的峰值。

對於 64K 寫入，我們看到峰值為 23,365 IOPS 或 1.5GB/s，延遲為 44ms。

我們的下一組測試是我們的 SQL 工作負載：SQL、SQL 90-10 和 SQL 80-20。 從 SQL 開始，NetApp C190 保持在 1 毫秒以下，直到超過 100K IOPS，然後達到 167,531 IOPS 的峰值和 5.9 毫秒的延遲。

SQL 90-10 的峰值為 139,602 IOPS，延遲為 7.03 毫秒。 C190 在這裡有亞毫秒延遲，直到大約 80K IOPS。

使用 SQL 80-20，我們看到了亞毫秒級的延遲性能，直到大約 60K IOPS 和 119,757 IOPS 的峰值，延遲為 8.2 毫秒。

接下來是我們的 Oracle 工作負載：Oracle、Oracle 90-10 和 Oracle 80-20。 從 Oracle 開始，C190 保持低於 1 毫秒的延遲，直到大約 50K IOPS，然後以 112,597 IOPS 達到峰值，延遲為 10.4 毫秒。

Oracle 90-10 在大約 80K IOPS 之前看到亞毫秒延遲，在 139,851 毫秒的延遲下達到 4.3 IOPS 的峰值。

對於 Oracle 80-20，陣列以低於 1 毫秒的延遲運行，直到略低於 60K IOPS，然後繼續為我們提供 118,669 IOPS 的峰值性能和 5.2 毫秒的延遲。

接下來，我們切換到我們的 VDI 克隆測試，完整和鏈接。 對於 VDI 完整克隆 (FC) 啟動，NetApp C190 的峰值為 93,335 IOPS，延遲為 11 毫秒。

對於 VDI FC 初始登錄，陣列峰值為 43,024 IOPS，延遲為 20.7 毫秒。

我們最後一次 VDI FC 基準測試是 Monday Login，我們看到峰值為 46,567 IOPS，延遲為 11 毫秒。

切換到 VDI 鏈接克隆 (LC) 啟動後，C190 啟動並保持在 1 毫秒以下，直到超過 30K IOPS 並達到 57,573 IOPS 的峰值，延遲為 8.7 毫秒。

VDI LC Initial Login 再次實現了亞毫秒級性能，這次達到了大約 15K IOPS。 該陣列繼續以 32,579 IOPS 和 7.7 毫秒的延遲達到峰值。

最後，VDI Monday Login 出現了 33,976 IOPS 的峰值和 14.4 毫秒的延遲。

結論

NetApp C190 是該公司針對 SMB 和邊緣用例的全閃存統一存儲陣列。 C190 是一個 2U 雙控制器平台，具有 ONTAP 必須提供的所有功能。 較小的新客戶會很高興地發現 C190 易於設置和管理，該公司聲稱可以在不到 10 分鐘的時間內配置工作負載。

就性能而言，我們運行了應用程序分析工作負載以及 VDBench 測試。 對於應用程序分析工作負載，我們運行了 SQL Server 平均延遲測試，C190 在 72.5 個虛擬機的情況下達到 8 毫秒，在 29 個虛擬機的情況下達到 4 毫秒。 使用 Sysbench，我們看到總得分為 7,863 TPS，平均延遲為 32.55 毫秒，最壞情況下的延遲為 96.38 毫秒。

對於 VDBench，該陣列以亞毫秒級延遲開始大多數基準測試，但所有測試都在 1 毫秒內完成。 在我們的隨機 4K 測試中，我們看到了 260K IOPS 讀取峰值和 74K IOPS 寫入峰值。 對於 32K 隨機數，我們看到了 101K IOPS 讀取峰值和 30K IOPS 寫入峰值。 對於順序，我們運行了 64K 測試並看到 2.2GB/s 讀取和 1.5GB/s 寫入。

對於 SQL，我們看到了 168K IOPS、SQL 80-90 中的 10K IOPS 和 SQL 120-80 中的 20K IOPS。 轉向 Oracle，我們看到 Oracle 113-140 的峰值為 90K IOPS、10K IOPS 和 Oracle 119-80 的 20K IOPS。 在我們的 VDI 克隆測試中，我們運行了完整克隆和鏈接克隆。 對於完整克隆，我們看到啟動峰值為 93K IOPS，初始登錄峰值為 43K IOPS，星期一登錄峰值為 47K IOPS。 在鏈接克隆中，我們看到 58K IOPS 用於啟動，33K IOPS 用於初始登錄，以及 34K IOPS 用於星期一登錄。

NetApp AFF C190 將 ONTAP 長期存在的深入企業數據功能帶入了一個新的、更小容量的平台。 C190 被設計為一種渠道播放方式，將 NetApp 解決方案推向更廣泛的受眾。 出於各種原因，這對 NetApp 來說是一件大事。 其中最主要的是，許多人沒有意識到可以以低於 20 萬美元的價格購買這樣的系統。 NetApp 渠道合作夥伴現在擁有一個企業系統，可以在由 NAS 系統或重新貼標的存儲控制器主導的擁擠的入門級存儲市場中展開競爭。 對於現有的 NetApp 客戶，C190 為他們提供了一個放置在邊緣的低成本解決方案，同時保持相同的 ONTAP 平台進行管理。

對 C190 的唯一打擊是 NetApp 降低了其擴展能力，緩衝了位於上方的 A190 系列中的 C200。 C190 提供有限的 SSD 選項，並且不能擴展到超過 24 個驅動器。 也就是說，通過數據縮減，一個完全填充的機箱可以提供大約 55TB 的有效容量（3:1 縮減）。 得益於 FabricPools 的冷數據分層，C190 的容量也可以通過雲輕鬆擴展。

歸根結底，C190 是 NetApp 的一個非常聰明的版本。 它不會像炫目的高端 NVMe 陣列那樣引起關注。 那不是 C190 的工作。 C190 旨在為競爭激烈的入門級存儲空間提供通道彈藥。 C190 在這裡提供了一個價格低廉但數據服務豐富的平台。 這種組合與強大的性能相結合，使 C190 成為我們在入門級存儲市場上的最愛之一。

NetApp C190 產品頁面

參與 StorageReview

電子通訊 | YouTube | 播客 iTunes/Spotify | Instagram | Twitter | Facebook | RSS訂閱