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服务器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 测试配置（每个虚拟机）

• CentOS 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订阅