了解并优化 Azure 文件共享性能

Azure 文件存储可满足大多数应用程序和用例的性能要求。 本文介绍了可能影响文件共享性能的不同因素，还介绍了如何针对工作负载优化 Azure 文件共享的性能。

管理模型	计费模式	媒体层	冗余	中小型企业 (SMB)	网络文件系统(NFS)
Microsoft.Storage	预配版本 v1	SSD（高级）	本地 (LRS)
Microsoft.Storage	预配版本 v1	SSD（高级）	区域 (ZRS)
Microsoft.Storage	即用即付	HDD（标准）	本地 (LRS)
Microsoft.Storage	即用即付	HDD（标准）	区域 (ZRS)
Microsoft.Storage	即用即付	HDD（标准）	异地 (GRS)
Microsoft.Storage	即用即付	HDD（标准）	GeoZone （GZRS）

在阅读本文之前，了解与存储性能相关的一些关键术语会很有帮助：

• 每秒 IO 操作次数 (IOPS)

  IOPS（每秒输入/输出操作数）衡量的是每秒进行的文件系统操作数。 在 Azure 文件存储文档中，术语“IO”可与术语“操作”和“事务”互换。

• I/O 大小

  I/O 大小（有时称为块大小）是指应用程序用于对存储执行单个输入/输出 (I/O) 操作的请求大小。 根据应用程序的不同，I/O 尺寸的范围可以从较小的 4 KiB 到更大尺寸。 I/O 大小在可实现的吞吐量中起着重要作用。

• 吞吐量

  吞吐量衡量每秒从存储读取或写入存储的位数，以每秒兆字节（MiB/秒）度量。 若要计算吞吐量，请将 IOPS 和 I/O 大小相乘。 例如，10,000 IOPS * 1 MiB I/O 大小 = 10 GiB/秒，而 10,000 IOPS * 4 KiB I/O 大小 = 38 MiB/秒。

• 延迟

  延迟是延迟的同义词，以毫秒为单位（ms）。 有两种类型的延迟：端到端延迟和服务延迟。 有关详细信息，请参阅延迟。

• 队列深度

  队列深度是存储资源在任何时间可处理的挂起 I/O 请求数。 有关详细信息，请参阅队列深度。

Azure 文件提供两个存储媒体层，可用于平衡性能和价格：SSD 和 HDD。 在存储帐户级别选取文件共享的媒体层，在特定的媒体层中创建存储帐户后，无需 手动迁移到新的文件共享，就无法移动到另一个。

在 SSD 和 HDD 文件共享之间进行选择时，请务必了解计划在 Azure 文件上运行的预期使用模式的要求。 如果需要大量的 IOPS、快速数据传输速度或低延迟，则应选择 SSD 文件共享。

下表汇总了 SSD 和 HDD 文件共享之间的预期性能目标。 有关详细信息，请参阅 Azure 文件存储可伸缩性和性能目标。

SSD 文件共享提供一种预配模型，可保证以下基于共享大小的性能特性。 有关详细信息，请参阅预配的 v1 模型。

无论是评估新工作负荷还是现有工作负荷的性能要求，了解使用模式都有助于实现可预测的性能。

• 延迟敏感度： 对读取延迟敏感且对最终用户具有较高可见性的工作负荷更适用于 SSD 文件共享，这可以为读取和写入作提供单毫秒延迟（< 对于小型 I/O 大小为 2 毫秒）。

• IOPS 和吞吐量要求： SSD 文件共享支持比 HDD 文件共享更大的 IOPS 和吞吐量限制。 有关详细信息，请参阅文件共享扩缩目标。

• 工作负荷持续时间和频率： 与长时间运行的、经常发生的工作负荷相比，短（分钟）和不频繁（每小时）工作负荷不太可能达到 HDD 文件共享的上限。 在 SSD 文件共享上，当根据预配的存储、IOPS 和吞吐量决定要使用的正确性能配置文件时，工作负载持续时间非常有用。 一个常见错误是仅运行性能测试几分钟，这通常具有误导性。 若要获取真实的性能视图，请务必按足够高的频率测试足够长的时间。

• 工作负荷并行化： 对于并行执行作的工作负荷（例如，在同一客户端上通过多个线程、进程或应用程序实例），SSD 文件共享比 HDD 文件共享具有明显的优势：SMB 多通道。 有关详细信息，请参阅提高 SMB Azure 文件共享性能。

• API操作分布：元数据密集型工作负载（例如对大量文件执行读取操作的工作负载）更适合 SSD 文件共享。 请参阅元数据或命名空间工作负载繁重。

在考虑延迟时，请务必先了解如何使用 Azure 文件存储确定延迟。 最常见的度量是与端到端延迟和服务延迟指标关联的延迟。 使用这些事务指标可以确定应用程序流量在传入和传出客户端的过程中花费的时间，从而帮助识别客户端延迟和/或网络问题。

• 端到端延迟 (SuccessE2ELatency) 是指事务执行完整往返所花费的总时间（完整往返从客户端开始，跨网络，传到 Azure 文件存储服务，然后返回客户端的）。

• 服务延迟（SuccessServerLatency） 是指事务仅在 Azure 文件内往返所需的时间。 这不包括任何客户端或网络延迟。

  

SuccessE2ELatency 值和 SuccessServerLatency 值之间的差异是可能由网络或客户端引起的延迟。

将客户端延迟与服务延迟（在此情况下，是 Azure 文件存储性能）相混淆的情况很常见。 例如，如果服务延迟报告低延迟，而端到端报告了非常高的请求延迟，则表明所有时间都花在了传入和传出客户端的过程中，而不是花在 Azure 文件存储服务中。

此外，如图所示，离服务越远，延迟体验越慢，实现任何云服务的性能缩放限制就越困难。 从本地访问 Azure 文件存储时尤其如此。 虽然 ExpressRoute 等选项非常适合本地，但它们仍然与仅在同一 Azure 区域中运行的应用程序（计算 + 存储）的性能不匹配。

队列深度是存储资源可处理的未完成 I/O 请求数。 随着存储系统使用的磁盘已从 HDD 主轴（IDE、SATA、SAS）演变为固态设备（SSD、NVMe），它们也演变为支持更高队列深度。 队列深度较低的一个示例是由单个客户端组成的工作负载与大型数据集中的单个文件串行交互。 相比之下，支持多个线程和多个文件的并行的工作负载可以轻松实现高队列深度。 由于 Azure 文件存储是跨数千个 Azure 群集节点的分布式文件服务，旨在大规模运行工作负载，因此建议生成和测试队列深度较高的工作负载。

可通过多种不同的方式与客户端、文件和线程结合使用来实现高队列深度。 若要确定工作负载的队列深度，请将客户端数、文件数和线程数相乘（客户端数 * 线程数 * 线程数 = 队列深度）。

下表说明了可用于实现更高队列深度的各种组合。 虽然可超过最佳队列深度 64，但建议不要超过它。 如果这样做，你将看不到更多性能提升，并且由于 TCP 饱和，延迟可能会增加。

Azure 文件存储最适合多线程应用程序。 要了解多线程对工作负载的性能影响，最简单的方法是按 I/O 来演练方案。 在以下示例中，有一个工作负载需要将 10,000 个小文件尽快复制到 Azure 文件共享或从 Azure 文件共享复制。

此表根据按 4 KiB 块大小写入的单线程应用程序，细分在 Azure 文件共享上创建单个 16 KiB 文件所需的时间（以毫秒为单位）。

在此示例中，通过 6 个操作创建单个 16 KiB 文件大约需要 14 ms。 如果单线程应用程序想要将 10,000 个文件移动到 Azure 文件共享，则相当于 140,000 ms (14 ms * 10,000) 或 140 秒，因为每个文件均按顺序一次移动一个。 请记住，服务每个请求的时间主要取决于计算和存储之间的距离，如上一部分所述。

通过使用 8 个线程而不是 1 个线程，上述工作负载可以从 140,000 ms（140 秒）缩短到 17,500 ms（17.5 秒）。 如下表所示，当你并行移动 8 个文件，而不是一次移动一个文件时，移动相同的数据量可节省 87.5% 的时间。

• 排查 Azure 文件共享性能问题
• 监视 Azure 文件存储
• 规划 Azure 文件部署
• 了解 Azure 文件存储计费
• Azure 文件存储定价