Azure Blob 存储上 NFS 3.0 的性能基准测试建议
本文提供 Azure Blob 存储上 NFS 3.0（网络文件系统版本 3）的基准测试建议和结果。 由于 NFS 3.0 主要用于 Linux 环境，因此本文仅重点介绍 Linux 工具。 在许多情况下，可以使用其他操作系统，但工具和命令可能会更改。
概述
存储性能测试用于评估和比较不同的存储服务。 有多种执行方法，但最常见的三种方法是：
- 使用标准 Linux 命令，通常是 cp 或 dd，
- 使用性能基准工具，如 fio、vdbench、ior 等，
- 使用生产中使用的实际应用程序。
无论采用哪种方法，了解环境中的其他潜在瓶颈并确保它们不会影响结果总是非常重要的。 例如，在测量写入性能时，我们需要确保源磁盘能够像预期的写入性能一样快速地读取数据。 相同的原则适用于读取性能。 理想情况下，在这些测试中可以使用 RAM 磁盘。 我们需要对网络吞吐量、CPU 使用率等进行类似的考虑。
使用标准 Linux 命令是最简单的性能基准测试方法，但也是最不推荐的方法。 方法很简单，因为每个 Linux 环境中都存在工具，并且用户熟悉它们。 必须对结果进行仔细分析，因为许多方面都会影响结果，而不仅仅是存储性能。 通常使用的两个命令：
- 使用
cp命令进行测试会将一个或多个文件从源复制到目标存储服务，并测量完全完成操作所需的时间。 此命令执行缓冲，而不是直接 IO，具体取决于缓冲区大小、操作系统、线程模型等。另一方面，一些实际应用程序的行为方式类似，有时表示良好的用例。 - 第二个常用命令是
dd。 命令是单线程的，在大规模带宽测试中，结果受限于单个 CPU 核心的速度。 可以同时运行多个命令并将其分配给不同的核心，但这会使测试和聚合结果复杂化。 运行起来也比一些性能基准测试工具要简单得多。
使用性能基准工具代表综合性能测试，这在比较不同的存储服务时很常见。 工具已正确设计为利用可用的客户端资源，以最大程度地提高存储吞吐量。 大多数工具都是可配置的，并且允许模拟现实世界中的应用程序，至少是那些较简单的应用程序。 模拟真实世界的应用程序需要详细了解应用程序的行为以及理解它们的存储模式。
使用实际应用程序始终是最佳方法，因为它测量的是用户在存储服务之上运行的真实工作负载的性能。 但是，此方法通常不实用，因为它需要生产环境和最终用户的副本才能在系统上生成适当的负载。 一些应用程序确实具有负载生成能力，应该用于性能基准测试。
| 测试方法 | 优点 | 缺点 |
|---|---|---|
| 标准 linux 命令 | - 简单 - 在任何 Linux 平台上可用 - 熟悉工具 |
- 未设计用于性能测试 - 不可配置 - 通常受 CPU 核心限制 |
| 性能基准工具 | - 针对性能测试进行优化 - 高度可配置 - 简单的多节点测试 |
- 设置真实世界的测试很复杂 |
| 实际应用程序 | - 提供准确的最终用户体验 | - 通常最终用户运行测试 - 需要生产环境的副本 - 可以是主观的 |
尽管使用实际应用程序进行性能测试是最佳选择，但由于测试设置简单，最常见的方法是使用性能基准测试工具。 我们显示了使用 NFS 3.0 在 Azure Blob 存储上运行性能测试的建议设置。
提示
大多数性能测试方法都侧重于单个客户端性能。 若要进行横向扩展测试，请使用可协调多客户端测试（如 fio、vdbench 等）的性能基准工具，或生成自定义编排层。
选择虚拟机大小
若要正确执行性能测试，第一步是正确调整测试中使用的虚拟机的大小。 虚拟机充当运行性能基准测试工具的客户端。 在选择用于此测试的虚拟机大小时，最重要的方面是可用网络带宽。 选择的虚拟机越大，能够获得的结果就越好。 如果在Azure中运行测试，建议使用一种常规用途虚拟机。
使用 NFS 3.0 创建存储帐户
选择虚拟机后，需要创建将在测试中使用的存储帐户。 请按照我们的操作指南逐步进行。 建议测试之前先阅读 Azure Blob 存储中 NFS 3.0 的性能注意事项。
其他注意事项
- 具有 NFS 3.0 终结点的虚拟机和存储帐户必须位于同一区域，
- 运行测试应用程序的虚拟机应仅用于测试，以确保其他正在运行的服务不会影响结果，
- 装载 NFS 3.0 终结点必须使用 AzNFS 装载帮助程序客户端进行可靠的访问。
执行性能基准
在 Linux 环境中可以使用多个性能基准测试工具。 其中任何方法都可以用来评估性能，我们推荐使用 FIO（灵活的 I/O 测试器）的方法。 FIO 可以通过每个 Linux 分发版的标准包管理器获得，或者作为源代码获得。 它可用于许多测试方案。 本文介绍推荐用于 Azure 存储的方案。 有关进一步自定义和不同的参数，请参阅 FIO 文档。
以下参数用于测试：
| 工作负荷 | 指标 | 块大小 | 线程 | IO 深度 | 文件大小 | nconnect | 直接 IO |
|---|---|---|---|---|---|---|---|
| 顺序程序 | 带宽 | 1 MiB | 8 | 1024 | 10 GiB | 16 | 是 |
| 顺序程序 | IOPS | 4 KiB | 8 | 1024 | 10 GiB | 16 | 是 |
| Random | IOPS | 4 KiB | 8 | 1024 | 10 GiB | 16 | 是 |
我们的测试设置是在客户端虚拟机类型为 D32ds_v5 且文件大小为 10 GB 的区域中完成的。 所有测试都运行了 100 次，结果显示为平均值。 测试是在标准存储帐户和高级存储帐户上完成的。 有关两种类型的存储帐户之间的差异的详细信息，请参阅此处。
测量顺序带宽
读取带宽
fio --name=seq_read_bw --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=1M --readwrite=read --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
写入带宽
fio --name=seq_write_bw --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=1M --readwrite=write --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
结果
测量顺序 IOPS
读取 IOPS
fio --name=seq_read_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=read --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
写 IOPS
fio --name=seq_write_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=write --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 –group_reporting –time_based=1
结果
注意
顺序IOPS测试的结果显示的值大于每秒请求数的存储帐户限制。 IOPS 是在客户端测量的，较大的值是由于服务优化和测试的顺序性质造成的。
测量随机 IOPS
读取 IOPS
fio --name=rnd_read_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=randread --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
写 IOPS
fio --name=rnd_write_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=randwrite --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 –group_reporting –time_based=1
结果
注意
添加随机测试的结果是为了完整性，Azure Blob 存储上的 NFS 3.0 终结点不是推荐用于随机写入工作负载的存储服务。