AFF A800 是 NetApp 的顶级 ONTAP 全闪存存储阵列，在推出时提供了行业首创的端到端 NVMe/FC over 32Gb FC，以及 100GbE 连接。 迄今为止，我们一直在研究全闪存 AFF 产品线，首先是强大的 A200 （此后被 A220 取代）以及 A300. 我们之前评论过的两个单元都获得了编辑选择奖。 今天，我们将关注基于 NVMe 的 A800 powerhouse，它提供与之前审查过的模型相同的 ONTAP 优势，以及成倍增长的性能和更低的延迟。 虽然这篇初步评论侧重于光纤通道上的系统性能，但后续文章将深入探讨 A800 的端到端 NVMe over Fabrics (NVMeoF) 支持。
AFF A800 是 NetApp 的顶级 ONTAP 全闪存存储阵列，在推出时提供了行业首创的端到端 NVMe/FC over 32Gb FC，以及 100GbE 连接。 迄今为止，我们一直在研究全闪存 AFF 产品线，首先是强大的 A200 （此后被 A220 取代）以及 A300. 我们之前评论过的两个单元都获得了编辑选择奖。 今天，我们将关注基于 NVMe 的 A800 powerhouse，它提供与之前审查过的模型相同的 ONTAP 优势，以及成倍增长的性能和更低的延迟。 虽然这篇初步评论侧重于光纤通道上的系统性能，但后续文章将深入探讨 A800 的端到端 NVMe over Fabrics (NVMeoF) 支持。
与专为中端市场的不同细分市场打造的 A200 和 A300 不同，A800 专为需要最高性能的工作负载（例如 AI 和深度学习）而设计，同时还包括 ONTAP 所提供的一组强大的企业数据服务闻名。 明确一点，NetApp 在 EF 全闪存系列中拥有一系列真正快速的存储，例如中端 EF570 我们之前回顾过。 回到 A800，NetApp 声称该系统可以在低于 1.3 微秒的延迟和高达 500GB/s 的吞吐量下达到 34 万次 IOPS，使用 HA 对。 在规模上，这意味着 NAS 集群可以在 11.4 毫秒的延迟和 1 GB/s 的吞吐量下提供高达 300M 的 IOPS。 SAN 集群可以在 7.8µs 延迟和 500GB/s 吞吐量下提供高达 204M IOPS。
与其他 AFF A 系列系统一样，NVMe A800 可以在 NAS 配置的集群中扩展到 24 个（12 个 HA 对）4U 双控制器节点。 因为这是一个基于 NVMe 的系统，所以在驱动器缩放方面存在一些细微差别。 例如，中端 A300 支持 4608 个驱动器，而 A800 最高为 2880 个。虽然在部署时不太可能成为功能问题，但我们强调这一点只是为了表明基于 NVMe 的系统在考虑 JBOD 扩展架时面临不同的工程挑战基于 SAS 的系统，因此我们不能假设随着产品线的升级一切都会变得更大。 在 SAN 配置中，NVMe A800 可扩展到 12 个节点（6 个 HA 对），支持 1,440 个驱动器。 也就是说，如果用户使用 15.3TB NVMe SSD，他们可以在 2.5U 占用空间中扩展到 4PB。 启用数据效率（假设 5:1）后，A800 在 315 节点 NAS 集群中支持超过 24PB，在 SAN 集群中支持超过 160TB。
虽然 NetApp 已经在其他 AFF 系统中启用了前端 NVMe 支持，但 A800 提供了所谓的端到端 NVMe 支持。 如前所述，我们不会在这篇评论中深入探讨这意味着什么。 可以说 A800 是第一个实现这一目标的全闪存 NVMe 阵列就足够了。 实际上，这意味着组织可以利用当今新兴的 NVMeoF 功能浪潮，同时仍然通过 FC 为其更传统的工作负载提供服务。 以前，想要利用 NVMeoF 的组织通常被降级为“科学项目”类型的部署，这些部署虽然速度很快，但在规模和数据服务方面存在局限性。 NetApp 的实施解决了这些缺点，同时还支持 FC 和以太网中的标准连接选项。
当然，我们不能不强调云连接性和 A800 NetApp 数据结构. ONTAP 固有的是与领先的云提供商的深度连接，使客户能够将数据放在最有意义的地方，无论是在 A800 本地还是其他地方。 NetApp 支持与 Amazon Web Services、Microsoft Azure、Google Cloud Platform 等的云和多云连接。 广泛的云支持让 NetApp 客户在管理数据足迹时拥有所需的灵活性，并根据需要灵活地移动数据以利用云经济、新功能或形状类型等。
我们的特定构建包括一个 A800，带有 24 个 1.92TB NVMe SSD，每个控制器连接两个四端口 32Gb FC 端口（总共 8 个端口），并安装了 ONTAP 9.5RC1。
NetApp A800 规格
| 最大横向扩展 | 2-24 个节点（12 个 HA 对） |
| 最大SSD | 2880 |
| 最大有效容量 | 316.3PB |
| 每系统双活双控制器 | |
| 控制器外形 | 4U |
| PCIe 扩展槽 | 8 |
| FC 目标端口（32Gb 自动量程） | 32 |
| FC 目标端口（16Gb 自动量程） | 32 |
| 100GbE 端口（40GbE 自动量程） | 20 |
| 10GbE 端口 | 32 |
| 支持存储网络 | NVMe/光纤通道 FC iSCSI NFS的 磷酸化NFS CIFS/中小企业 |
| 操作系统版本 | ONTAP 9.4 RC1 或更高版本 |
| 货架和媒体 | NVMe 驱动器包 |
| 支持主机/客户端操作系统 | Windows 2000 Windows服务器2003的 Windows服务器2008的 Windows服务器2012的 Windows服务器2016的 Linux 甲骨文Solaris AIX HP-UX Mac OS VMware的 ESX |
设计与建造
NetApp AFF A800 是一个 4U 阵列，外观与 AFF 系列中的其他阵列非常相似。 在包含通风和 NetApp 品牌的时尚边框下方，是两排用于 SSD 的蓝色 2.5 英寸驱动器托架。
看看 NVMe 驱动器本身，NetApp 支持多种容量选项，包括 1.9TB、3.8TB、7.6TB 和 15.3TB SSD。 在撰写本文时，NetApp 将所有这些驱动器作为采用 AES-256 加密的自加密 (SED) 进行交付。 此外，对于使用 ONTAP 9.4 初始化的系统，启用了快速驱动器归零。
翻转到设备的后部，有两个控制器：一个像镜像一样堆叠在另一个之上。 我们的配置包括四种不同风格的连接接口。 这四张卡位于最右侧和中间的 PCIe 插槽中。 它们包括四端口 32Gb FC 卡（左上）、双端口 25GbE 网卡（左下）、双端口 100GbE 网卡（右上）和四端口 10GbE 网卡（右下）。
卸下其中一个控制器，我们可以看到与设备其余部分的连接，以及排列在控制器前部的风扇。
翻到后控制器，左侧有用于每个控制器的双冗余 PSU 以及 HA 互连端口和集群互连端口。 每个控制器的右下角还有 1HA 和集群互连端口。 其余大部分被 PCIe 插槽（五个）占用，这些插槽可以填充网络端口 100GbE、10GbE 或 32Gb 光纤通道或上述配置的某种组合。 中间底部是管理端口和两个 USB 3.0 端口。
控制器非常容易打开，非常易于维修。
我们可以看到两个 CPU、20 个 DIMM 插槽（装有 20 个 32GB DIMM 内存）和两个 NVDIMM 插槽。 从这里也可以轻松访问 PCIe 网络 AIC。
多年来，ONTAP GUI 已经取得了长足的进步，从 8.2 及更早版本的支持 Java 的 GUI 到现代且设计良好的 Web 驱动的 ONTAP 9.5。 NetApp 对 GUI 进行了重大改进，使其越来越多地用于日常管理功能之外的用途。
仪表板：
登录后，您会看到仪表板，它将让您快速了解系统正在发生的事情。 就您能够看到的内容而言，仪表板非常简单。 每个小部件都允许快速浏览警报、性能、容量、效率和保护。 如需更详细的查看和长期趋势，建议使用 NetApp（免费）的 OnCommand Unified Manager for ONTAP 指标。
云层：
通过添加 NetApp Cloud 选项 Fabric Pool，GUI 可以轻松连接到公有云，包括 NDAS 以及本地 StorageGRID。
支持向量机：
在此选项卡中，您可以创建、编辑、删除和启动/停止 ONTAP 集群上的所有数据协议 SVM，以及编辑各种设置。
聚合和存储池：
聚合和存储池选项卡允许直接创建和管理聚合和存储池。
卷和 LUN：
卷和 LUN 管理页面为您提供了多种创建和管理 FlexVol、FlexGroup 和 LUN，甚至每个 SVM 的 igroup 和映射的方法。
服务质量：
多年来，QoS 在 ONTAP 上取得了长足的进步，因为您现在可以为每个工作负载配置上限和下限，并将它们配置为适应不断变化的工作负载。 QoS 可以应用于 ONTAP 内部的各种对象，例如卷、文件和 LUN 以及一些其他对象。
网络配置：
所有基本网络配置和管理都在 GUI 中：IP 空间、广播域、端口、LIF、FC 和现在的 NVMe。
对等：
在 ONTAP 的最后几个版本之前，您需要仅通过 CLI 创建对等关系； 但是，现在您也可以在 GUI 中创建集群节点，甚至 SVM 节点。 配置对等互连后，您甚至可以直接在卷创建向导中创建 SnapMirror 关系。
集群更新：
ONTAP 升级变得越来越容易。 9.4 中添加的一个小但非常有用的功能使进行 ONTAP 更新变得更加容易。 我们当然都喜欢命令行，但这使得与客户合作升级他们的文件变得非常容易。 没有更多的 http/ftp 服务器可以搞砸了； 只需直接上传 .tgz 文件并运行自动集群更新。
性能
对于性能，我们将比较 A800 和 A300。 这用于显示 NetApp AFF 模型的性能随着您在系列中的升级而扩展的程度。 在我们所有的测试中，我们都启用了数据缩减服务，这意味着启用了内联重复数据删除和压缩。 正如我们在过去的评论中指出的那样，NetApp ONTAP 提供了强大的灾难恢复功能，同时将开销或性能影响降至最低。
我们的 NetApp AFF A800 配置包括 8 个 32Gb FC 端口，安装了 24 个 1.92TB NVMe SSD。 在我们的 A24 中部署的 1.92 个 800TB SSD 中，我们将它们分成两个 RAID-DP 聚合，使用 11 个 SSD，一个作为热备用。 该阵列通过两个 Brocade G32 交换机通过 620Gb 连接，然后有 16 个 16Gb 链接到我们的 Dell PowerEdge R740xd 服务器。
对于使用 VDbench 和 Sysbench 的综合基准测试，我们配置了 32 个 600GB 卷，均匀分布在控制器和磁盘组中。 对于 SQL Server，我们使用了额外的四个 1.1TB 卷，每个控制器两个卷来保存用于基准测试的 VM。 考虑到数据缩减后，我们测试期间使用的总占用空间相当于每个聚合的利用率略低于 50%。
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 事务性能，A800 的总得分为 12,635.5 TPS，单个 VM 的运行速度从 3,158.6 TPS 到 3,159.3 TPS（比 A300 的 12,628.7 TPS 和 A200 的 12,583.8 TPS 小幅提升）。
查看 SQL Server 平均延迟，我们发现 A800 的改进更大，因为它下降到 5 毫秒聚合和所有 VM 上的 5 毫秒（比 A300 的 8 毫秒和 A200 的 25 毫秒好得多）。
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，我们测试了几组 VM，包括 8、16 和 32，并且我们运行 Sysbench，同时数据缩减都处于“开启”状态。 A800 能够达到 15,750.8VM 的 8TPS、22,170.9VM 的 16TPS 和 44,149.8VM 的 32TPS。 这些比之前的要高得多，几乎是 A300 在 32VM、22,313 TPS 上的两倍。
对于 Sysbench 平均延迟，A800 在 16.3VM 时达到 8ms，在 23.1VM 时达到 16ms，在 23.2VM 时达到 32ms。 这比较小的 AFF 模型要好得多。
在我们的最坏情况（第 99 个百分位数）延迟中，A800 31.3VM 达到 8ms，48.5VM 达到 16ms，48.1VM 达到 32ms。
VDBench 工作负载分析
在对存储阵列进行基准测试时，应用程序测试是最好的，综合测试排在第二位。 虽然不能完美代表实际工作负载，但综合测试确实有助于为具有可重复性因素的存储设备建立基线，从而可以轻松地在竞争解决方案之间进行同类比较。 这些工作负载提供了一系列不同的测试配置文件，包括“四个角”测试、常见的数据库传输大小测试，以及来自不同 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
- VDI 完整克隆和链接克隆跟踪
从峰值随机 4K 读取性能开始，A800 以 118,511 IOPS 开始，延迟为 217.5μs。 A800 保持在 1 毫秒以下，直到它达到约 1.07 万次 IOPS，然后以 1,219.829 毫秒的延迟达到 3.3 IOPS 的峰值。 与延迟为 300 毫秒的 A635,342 的 6.4 IOPS 峰值性能相比，这是一个显着差异。
看看 4K 写入性能，A800 以 45,676 IOPS 开始，延迟为 213.1μs。 A800 在达到约 410K IOPS 之前一直具有亚毫秒级延迟性能，然后以约 439K IOPS 的峰值达到峰值，延迟为 4.4ms，然后下降了一些。 相比之下，A300 的峰值性能为 208,820 IOPS，延迟为 9.72 毫秒。
切换到顺序工作负载，我们查看峰值 64K 读取性能，此处 A800 以 29,589 IOPS 或 1.85GB/s 开始，延迟为 166.1μs。 A300 具有亚毫秒延迟，直到大约 300K IOPS 或 18.5GB/s，在 302,668ms 延迟时达到 18.9 IOPS 或 1.7GB/s 的峰值。 A300 的峰值约为 84,766K IOPS 或 5.71GB/s，延迟为 3.64ms，然后略有下降。
对于 64K 顺序写入性能，A800 以 8,103 IOPS 或 506.4MB/s 开始，延迟为 304.8μs。 该阵列在运行结束之前一直保持在 1 毫秒以下，或者大约 80K IOPS 或 5GB/s，然后以 80,536 IOPS 或 5.03GB/s 的峰值达到峰值，延迟为 3.1ms。 对于峰值性能，我们看到 A300 在 48,883 毫秒的延迟下达到 3.1 IOPS 或 4.8GB/s。
我们的下一批基准是我们的 SQL 测试。 在 SQL 中，A800 以 138,007 IOPS 开始，延迟为 255.2 微秒，延迟为亚毫秒，直到大约 650K IOPS，在延迟为 697,603 毫秒时达到 1.5 IOPS 的峰值。 相比之下，A300 的峰值为 488,488 IOPS，延迟为 2.1 毫秒。
在 SQL 90-10 中，A800 以 70,867 IOPS 开始，延迟为 277.3 微秒，一直保持在 1 毫秒以下，直到大约 640K IOPS，然后以 730,567 IOPS 和 1.4 毫秒的延迟达到峰值。 另一方面，A300 的峰值性能为 416,370 IOPS，延迟为 2.46 毫秒
对于 SQL 80-20，A800 以 56,391 IOPS 开始，延迟为 256.6 微秒，延迟为亚毫秒，直到大约 480K IOPS。 A800 的峰值为 623,557 IOPS，延迟为 1.6 毫秒。 这大约是 A300 的 360,642 IOPS 的两倍，延迟为 2.82 毫秒。
继续我们的 Oracle 工作负载，我们看到 A800 从 64,020 IOPS 开始，延迟为 254.7 微秒，一直保持在 1 毫秒以下，直到大约 470K IOPS。 A800 在 656,438 毫秒的延迟时达到 1.9 IOPS 的峰值。 同样，A800 的性能几乎是 A300 得分 340,391 IOPS 的两倍，延迟为 3.6 毫秒。
对于 Oracle 90-10，A800 以 75,710 IOPS 和 242.5μs 延迟启动。 该阵列始终管理亚毫秒级延迟性能，在 759,117 微秒延迟时达到 839.2 IOPS 的峰值——比 A300 的峰值 417,869 IOPS 和 1.53 毫秒的延迟高出一大步。
借助 Oracle 80-20，A800 保持了亚毫秒级延迟性能，从 65,505 IOPS 和 254.5μs 延迟到 666,556 IOPS，943.1μs 峰值。 A300 的峰值为 362,499 IOPS，延迟为 1.62 毫秒。
接下来我们切换到我们的 VDI 克隆测试，完整和链接。 对于 VDI 完整克隆启动，A800 在达到约 535K IOPS 之前具有亚毫秒级延迟，并以 579,786 毫秒的延迟达到 1.8 IOPS 的峰值。 A300 的峰值为 300,128 IOPS，延迟为 3.46 毫秒。
使用 VDI 完整克隆初始登录时，A800 保持在 1 毫秒以下，直到大约 200K IOPS，并以 254,888 毫秒的延迟达到 3.5 IOPS 的峰值。 这与 A300 形成鲜明对比，峰值为 123,984 IOPS，延迟为 7.26 毫秒。
VDI FC Monday Login 显示 A800 具有亚毫秒延迟性能，直到大约 180K IOPS 和 228,346 IOPS 的峰值，延迟为 2.2 毫秒。 与延迟为 300 毫秒的 A131,628 的 3.89 IOPS 相比，这是一个巨大的飞跃。
切换到 VDI 链接克隆 (LC)，在启动测试中，A800 的延迟几乎始终低于 1 毫秒，在大约 1K IOPS 时突破了 440 毫秒的障碍，并以 460,366 毫秒的延迟达到 1.1 IOPS 的峰值。 A300 的峰值为 215,621 IOPS，延迟为 2.28 毫秒。
在 VDI LC 初始登录中，A800 再次出现长时间的亚毫秒延迟，直到大约 158K IOPS，峰值为 166,224 IOPS，延迟为 1.5 毫秒。 相比之下，A300 的峰值为 95,296 IOPS，延迟为 2.68 毫秒。
最后，我们查看 VDI LC Monday Login，其中 A800 以 15,287 IOPS 和 299.3μs 的延迟启动。 该阵列保持在 1 毫秒以下，直到大约 130K IOPS，并以 164,684 毫秒的延迟达到 3.1 IOPS 的峰值。 A300 峰值为 94,722 IOPS，延迟为 5.4 毫秒
结语
NetApp AFF A800 是一款 4U 的全闪存存储阵列，具有顶级性能。 A800 配备所有 NVMe 闪存，旨在满足最苛刻的工作负载。 除了支持所有 NVMe（以及每个容量高达 15.3TB 的 NVMe SSD）外，AFF A800 还具有可选的 100GbE 连接，可在性能绝对必要时使用。 根据 NetApp 的说法，AFF A800 应该能够以低于 1.4 微秒的延迟达到 500 万次 IOPS。 与 A 系列中的其他 NetApp 阵列一样，A800 由 ONTAP 提供支持。
为了提高性能，我们运行了由 SQL Server 和 Sysbench 组成的应用程序分析工作负载，以及 VDBench 工作负载。 对于我们的应用程序工作负载分析，A800 的事务性 SQL Server 得分总计为 12,835.5 TPS，平均延迟为 5 毫秒。 与 A300 的 12,628.7 TPS 和 8 毫秒的平均延迟相比，这是性能的一大进步。 使用 Sysbench，A800 为我们提供了 15,750.8VM 8TPS，22,170.9VM 16 TPS，44,149.8VM 32 TPS，16.3VM 的平均延迟为 8ms，23.1VM 为 16ms，23.2VM 为 32ms，最坏情况下的延迟为31.3VM 为 8ms，48.5VM 为 16ms，48.1VM 为 32ms。 在某些情况下，A800 能够将 TPS 提高一倍，同时将延迟大约减半。
对于我们的 VDBench 工作负载，NetApp AFF A800 继续表现出色。 亮点包括 1.2K 读取 4 万 IOPS、439K 写入 4K IOPS、顺序 18.9K 读取 64GB/s 和 5.03K 写入 64GB/s。 所有这些数字都是在 5 毫秒的延迟下达到的。 在我们的 SQL 测试中，该阵列在 SQL 698-731 中达到 90K IOPS，在 SQL 10-624 中达到 80K IOPS，在 SQL 20-800 中达到 656K IOPS。 在 Oracle 中，A90 达到 10K IOPS，而在 Oracle 80-20 和 Oracle 759-667 中，阵列始终具有亚毫秒级延迟，峰值分别为 800K IOPS 和 580K IOPS。 在我们的 VDI 克隆测试中，A460 能够达到完整克隆 4.4K IOPS 和链接克隆 XNUMXK IOPS 的启动分数。 我们所有测试中的最高峰值延迟仅为 XNUMX 毫秒。
与我们之前评测过的中端市场 ONTAP 系统一样，NetApp 再次凭借以企业为中心的 A800 脱颖而出。 性能配置文件非常强大，在 ONTAP 系列中处于领先地位。 如前所述，此测试是典型的光纤通道工作； 我们还没有剥离 NVMeoF 配置中可用的内容，这应该很好玩。 在审查硬件时，有时会有一个琐碎的担忧，即较老的存储供应商不像初创公司那样快速和灵活，而且“遗留代码”无法跟上步伐。 我们在 NetApp 产品组合的任何地方都没有看到这些问题的迹象，而且，A800 以对企业实用的方式采用 NVMe 和 NVMeoF，而不会牺牲多年来 ONTAP 固有的数据保护和可用性功能。 NetApp 在 A800 中对 NVMe 有很好的处理，我们很高兴看到这些学习如何在其他阵列中找到它们的方式。
