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 是的
随机 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

读取 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

结果

随机IOPS测试结果的截图。

注释

为完整性添加了随机测试结果,Azure Blob 存储上的 NFS 3.0 终结点不推荐用于随机写入工作负荷的存储服务。

后续步骤