Azure 文件存储在云中提供完全托管的文件共享，这些共享可通过服务器消息块 (SMB) 和网络文件系统 (NFS) 文件系统协议进行访问。 本文讨论了 Azure 文件和 Azure 文件同步的可伸缩性和性能目标。
部署中的其他变量可能会影响本文中列出的目标。 例如，SMB 客户端的行为和可用的网络带宽可能会影响 I/O 性能。 你应该对使用模式进行测试，以确定 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（标准） | 异地区域 (GZRS) |
|
|
Azure 文件共享将部署到存储帐户。存储帐户是代表存储共享池的顶级对象。 此存储池可用于部署多个文件共享。 因此需要考虑三个类别：存储帐户、Azure 文件共享和单个文件。
存储存储帐户规模目标应用于存储帐户级别。 有两种适用于 Azure 文件存储的主要类型的存储帐户：
FileStorage 存储帐户：使用 FileStorage 存储帐户可以使用预配的计费模型部署 Azure 文件共享。 FileStorage 帐户只能用于存储 Azure 文件共享；其他存储资源（Blob 容器、队列、表等）都不能部署在 FileStorage 帐户中。
常规用途版本 2 (GPv2) 存储帐户：使用 GPv2 存储帐户可以在基于 HDD 的硬件上部署即用即付文件共享。 除了存储 Azure 文件共享以外，GPv2 存储帐户还可以存储其他存储资源，例如 Blob 容器、队列或表。
| 属性 | SSD 预配 v1 | HDD 即用即付 |
|---|---|---|
| 存储帐户类型 | 文件存储 | StorageV2 |
| SKU |
|
|
| 每个订阅每个区域的存储帐户数 | 250 | 250 |
| 最大存储容量 | 100 TiB | 5 PiB |
| 最大文件共享数 | 1024（建议使用 50 或更少） | 无限制（建议使用 50 或更少） |
| 最大 IOPS | 102,400 IOPS | 20,000 IOPS |
| 最大吞吐量 | 10,340 MiB/秒 |
|
| 虚拟网络规则的数目上限 | 200 | 200 |
| IP 地址规则的数目上限 | 200 | 200 |
| 管理读取操作数目 | 每 5 分钟 800 次 | 每 5 分钟 800 次 |
| 管理写入操作数目 | 每秒 10 次/每小时 1200 次 | 每秒 10 次/每小时 1200 次 |
| 管理列出操作数目 | 每 5 分钟 100 次 | 每 5 分钟 100 次 |
以下区域增加了 HDD 即用即付存储帐户 (StorageV2) 的最大吞吐量：
- 中国东部 2
- 中国北部 3
Azure 文件共享缩放目标应用于文件共享级别。
| 属性 | SSD 预配 v1 | HDD 即用即付 |
|---|---|---|
| 存储预配单元 | 1 GiB | 空值 |
| IOPS 预配单元 | 空值 | 空值 |
| 吞吐量预配单元 | 空值 | 空值 |
| 最小存储大小 | 100 GiB（预配值） | 0 字节 |
| 最大存储大小 | 100 TiB | 100 TiB |
| 最大文件数 | 无限制 | 无限制 |
| 最大 IOPS （数据） | 102,400 IOPS（取决于预配） | 20,000 IOPS |
| 最大 IOPS （元数据） | 最多 35,000 IOPS | 最多 12,000 IOPS |
| 最大吞吐量 | 10,340 MiB /秒（取决于预配） | 可达存储帐户限制 |
| 共享快照的最大数目 | 200 个快照 | 200 个快照 |
| 最大文件名长度1 （完整路径名，包括所有目录、文件名和反斜杠字符） | 2,048 个字符 | 2,048 个字符 |
| 单个 pathname 组件的最大长度（在路径 \A\B\C\D 中，每个字母表示作为单个组件的目录或文件） | 255 个字符 | 255 个字符 |
| 硬链接限制（仅限 NFS） | 178 | 空值 |
| SMB 多路通道的最大数量 | 4 | 空值 |
| 每个文件共享的存储的访问策略的最大数目 | 5 | 5 |
1 Azure 文件强制实施目录和文件名的某些 命名规则 。
文件缩放目标适用于存储在 Azure 文件共享中的单个文件。
| 属性 | SSD 预配 v1 | HDD 即用即付 |
|---|---|---|
| 文件大小上限 | 4 TiB | 4 TiB |
| 每个文件的最大数据 IOPS | 8,000 IOPS | 1,000 IOPS |
| 每个文件的最大吞吐量 | 1,024 MiB/秒 | 60 MiB/秒 |
| 根目录的最大并发句柄数 | 10,000 个句柄 | 10,000 个句柄 |
| 每个文件和目录的最大并发句柄数 | 2,000 个句柄 | 2,000 个句柄 |
Azure 文件存储的一个常见用例是使用 FSLogix 或应用附加来存储 Azure 虚拟桌面的用户配置文件容器和磁盘映像。 如果在大规模 Azure 虚拟桌面部署中使用单个 Azure 文件共享，则可能会耗尽根目录或每个文件/目录的句柄。 本部分介绍各种类型的磁盘映像如何使用句柄。 它还根据您使用的技术提供规格指南。
如果将 FSLogix 与 Azure 虚拟桌面一起使用，则用户配置文件容器是虚拟硬盘 (VHD) 或 Hyper-V 虚拟硬盘 (VHDX) 文件，并且它们装载在用户上下文中，而不是系统上下文中。 每个用户将打开一个根目录句柄，该句柄应该指向文件共享。 假设你拥有文件共享 (\\storageaccount.file.core.windows.net\sharename) + 配置文件目录 (%sid%_%username%) + 配置文件容器 (profile_%username.vhd(x))，Azure 文件存储最多可支持 10,000 个用户。
如果达到根目录 10,000 个并发句柄的限制，或者用户发现性能不佳，请尝试使用额外的 Azure 文件共享并在共享之间分发容器。
警告
虽然 Azure 文件存储最多可支持来自单个文件共享的 10,000 名并发用户，但必须根据所使用的文件共享的大小和类型正确测试工作负荷。 你的要求可能因用户、配置文件大小和工作负载而异。
例如，如果有 2,400 个并发用户，则根目录上需要 2,400 个句柄（每个用户一个句柄），这低于 10,000 个打开句柄的限制。 对于 FSLogix 用户，几乎不可能达到 2,000 个打开的文件和目录句柄的限制。 如果每个用户只有一个 FSLogix 配置文件容器，则只需使用两个文件/目录句柄：一个用于配置文件目录，另一个用于配置文件容器文件。 如果用户各有两个容器（配置文件和 ODFC），则需要为 ODFC 文件多提供一个句柄。
如果使用 MSIX 应用附加或应用附加来动态附加应用程序，可以使用复合映像文件系统 (CimFS) 或 VHD/VHDX 文件作为磁盘映像。 无论哪种方式，规模限制都是针对每个装载映像的 VM，而不是针对每个用户。 计算规模限制时，用户数量无关紧要。 启动 VM 时，即使没有用户，也会装载磁盘映像。
如果使用 CimFS 进行应用附加，则磁盘映像仅使用磁盘映像文件上的句柄。 它们不使用根目录或包含磁盘映像的目录上的句柄。 但是，由于 CimFS 映像是 .cim 文件和至少两个其他文件的组合，因此对于装载磁盘映像的每个 VM，目录中的三个文件各需要一个句柄。 因此，如果有 100 个 VM，则需要 300 个文件句柄。
如果每个应用的 VM 数量超过 2,000，则文件句柄可能会耗尽。 在这种情况下，请使用额外的 Azure 文件共享。
如果对 VHD/VHDX 文件使用应用附加，则会将文件装载到系统上下文中，而不是用户上下文，并且它们是共享和只读的。 连接系统可以使用 VHDX 文件上的多个句柄。 若要保持在 Azure 文件存储规模限制范围内，VM 数量乘以应用数量必须小于 10,000，并且每个应用的 VM 数量不能超过 2,000。 因此，约束就是最先达到的数量。
在这种情况下，单个 VHD/VHDX 装载 2,000 个文件可能会达到每个文件/目录的限制。 或者，如果共享包含多个 VHD/VHDX 文件，可能最先达到根目录限制。 例如，100 个 VM 装载 100 个共享 VHDX 文件将达到 10,000 个句柄根目录限制。
再例如，100 个 VM 访问 20 个应用将需要 2,000 个根目录句柄 (100 x 20 = 2,000)，这完全在根目录句柄的 10,000 个限制范围内。 对于装载 VHD（X） 映像的每个 VM，还需要一个文件句柄和一个目录/文件夹句柄，因此在这种情况下，200 个句柄（100 个文件句柄 + 100 个目录句柄），这非常低于每个文件/目录的 2,000 个句柄限制。
如果达到根目录或每个文件/目录的最大并发句柄数限制，请使用额外的 Azure 文件共享。
下表指示哪个目标是软目标，表示 Microsoft 测试的边界；哪个目标是硬目标，表示强制实施的最大值：
| 资源 | 目标 | 硬限制 |
|---|---|---|
| 每个区域的存储同步服务数 | 100 个存储同步服务 | 是 |
| 每个订阅的存储同步服务数 | 15 个存储同步服务 | 是 |
| 每个存储同步服务的同步组数 | 200 个同步组 | 是 |
| 每个存储同步服务的已注册服务器 | 100 台服务器 | 是 |
| 每个存储同步服务的专用终结点 | 100 个专用终结点 | 是 |
| 每个同步组的云终结点数 | 一个云终结点 | 是 |
| 每个同步组的服务器终结点数 | 100 个服务器终结点 | 是 |
| 每个服务器的服务器终结点数 | 30 个服务器终结点 | 是 |
| 每个同步组的文件系统对象数（目录和文件） | 1 亿个对象 | 否 |
| 一个目录中的最大文件系统对象（目录和文件）数（非递归） | 500 万个对象 | 否 |
| 最大对象（目录和文件）安全描述符大小 | 64 KiB | 是 |
| 文件大小 | 100 GiB | 否 |
| 要进行分层的文件的最小文件大小 | 基于文件系统群集大小（双文件系统群集大小）。 例如，如果文件系统群集大小为 4 KiB，则最小文件大小为 8 KiB。 | 是 |
注意
Azure 文件同步终结点可以纵向扩展到 Azure 文件共享的大小。 如果达到 Azure 文件共享大小限制，同步将无法运行。
由于 Azure 文件同步代理在连接到 Azure 文件共享的 Windows Server 计算机上运行，有效的同步性能取决于基础结构中的许多因素，包括：
- Windows Server 和基础磁盘配置
- 服务器与 Azure 存储之间的网络带宽
- 文件大小
- 总数据集大小
- 数据集上的活动
由于 Azure 文件同步在文件级别工作，因此应按每秒处理的对象（文件和目录）数来度量基于 Azure 文件同步的解决方案的性能特征。
下表指出了 Azure 文件同步的性能目标：
| 情景 | 性能 |
|---|---|
| 初始云更改枚举 | 每个同步组每秒 150 个对象 |
| 上传吞吐量 | 每个同步组每秒 200 个对象 |
| 命名空间下载吞吐量 | 每个服务器终结点每秒 400 个对象 |
| 完整下载吞吐量 | 每个服务器终结点每秒 60 个对象 |
注意
实际性能将取决于本部分开头列出的多个因素。
作为常规部署指南，应当牢记以下几件事情：
- 对象吞吐量大约与服务器上的同步组数成比例缩放。 在服务器上将数据拆分到多个同步组会实现更好的吞吐量，吞吐量还受限于服务器和网络。
- 对象吞吐量与每秒 MiB 吞吐量成反比。 对于较小的文件，在每秒处理的对象数方面，吞吐量更高，但 MiB/秒吞吐量较低。 相反，对于较大的文件，每秒处理的对象更少，但每秒的 MiB 吞吐量更高。 每秒 MiB 数这一吞吐量受限于 Azure 文件规模目标。
- 当同一个同步组中的许多服务器终结点同时同步时，它们会争用云服务资源。 因此，上传性能会受影响。 在极端情况下，某些同步会话将无法访问资源，因此会失败。 但是，在拥塞缓解后，这些同步会话将很快恢复，最终会成功。
- 如果启用了云分层，则下载性能可能更好，因为只会下载一部分文件数据。 只有当已缓存文件的数据在任何终结点上发生更改时，Azure 文件同步才会下载这些数据。 对于任何已分层的或新创建的文件，代理不会下载文件数据，而仅会将命名空间同步到所有服务器终结点。 代理还支持在用户访问已分层文件时下载这些文件的一部分。