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

• CentOS 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 IOPS 的峰值达到 1.2 毫秒的延迟。 

通过 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 微秒）。 在顺序方面，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 时事通讯