Azure 文件存储在云中提供完全托管的文件共享，这些共享可通过服务器消息块 (SMB) 和网络文件系统 (NFS) 文件系统协议进行访问。 本文讨论了 Azure 文件和 Azure 文件同步的可伸缩性和性能目标。
此处列出的目标可能受部署中的其他变量的影响。 例如，文件的 I/O 性能可能受 SMB 客户端的行为和可用网络带宽的影响。 你应该对使用模式进行测试，以确定 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 即用即付 |
|---|---|---|
| 存储帐户类型 | FileStorage | 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 |
| 最大吞吐量 | 10,340 MiB /秒（取决于预配） | 可达存储帐户限制 |
| 共享快照的最大数目 | 200 个快照 | 200 个快照 |
| 最大文件名长度3（完整路径名，包括所有目录、文件名和反斜杠字符） | 2,048 个字符 | 2,048 个字符 |
| 单个路径名组件的最大长度2（在路径 \A\B\C\D 中，每个字母代表一个目录或文件，该目录或文件是一个单独组件） | 255 个字符 | 255 个字符 |
| 硬链接限制（仅限 NFS） | 178 | 空值 |
| SMB 多路通道的最大数量 | 4 | 空值 |
| 每个文件共享的存储的访问策略的最大数目 | 5 | 5 |
3 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 个专用终结点 | 是 |
| 每个同步组的云终结点数 | 1 个云终结点 | 是 |
| 每个同步组的服务器终结点数 | 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 文件同步，性能在两个阶段至关重要：
- 初始一次性预配： 若要优化初始预配的性能，请参阅使用 Azure 文件同步加入来了解最佳部署详细信息。
- 持续同步：在 Azure 文件同步中初次植入数据后，Azure 文件同步会使多个终结点保持同步。
注意
当同一个同步组中的许多服务器终结点同时同步时，它们会争用云服务资源。 因此，上传性能会受影响。 在极端情况下，某些同步会话将无法访问资源，因此会失败。 但是，在拥塞缓解后，这些同步会话将很快恢复，最终会成功。
为帮助你规划每个阶段的部署（初始一次性预配和持续同步），下面提供了在采用以下配置的系统上进行内部测试期间观察到的结果：
| 系统配置 | 详细信息 |
|---|---|
| CPU | 64 个带 64 MiB L3 高速缓存的虚拟内核 |
| 内存 | 128 GiB |
| 磁盘 | 采用 RAID 10 且带有以电池供电的高速缓存的 SAS 磁盘 |
| 网络 | 1 Gbps 网络 |
| 工作负荷 | 常规用途文件服务器 |
| 初始的一次性预配 | 详细信息 |
|---|---|
| 对象数 | 2500 万个对象 |
| 数据集大小 | ~4.7 TiB |
| 平均文件大小 | ~200 KiB（最大的文件：100 GiB） |
| 初始云更改枚举 | 每秒 80 个对象 |
| 上传吞吐量 | 每个同步组每秒 20 个对象 |
| 命名空间下载吞吐量 | 每秒 400 个对象 |
初始云更改枚举：创建新的同步组后，初始云更改枚举是会执行的第一个步骤。 在此过程中，系统将枚举 Azure 文件共享中的所有项。 在此过程中，不会有同步活动。 不会将任何项从云终结点下载到服务器终结点，并且不会将任何项从服务器终结点上传到云终结点。 初始云更改枚举完成后，同步活动才会继续。
性能速率为每秒 80 个对象。 可通过确定云共享中的项目数并使用以下公式获取时间（以天为单位）来估算完成初始云更改枚举所需的时间。
初始云枚举的时间（以天为单位）=（云终结点中的对象数）/(80 * 60 * 60 * 24)
将数据从 Windows Server 初始同步到 Azure 文件共享：许多 Azure 文件同步部署是从一个空的 Azure 文件共享开始，因为所有数据都在 Windows Server 上。 在这些情况下，初始云更改枚举速度很快，并且时间主要花费在将 Windows Server 中的更改同步到 Azure 文件共享中。
同步将数据上传到 Azure 文件共享时，本地文件服务器不会停机，管理员可设置网络限制来限制用于后台数据上传的带宽量。
初始同步通常受每个同步组每秒 20 个文件的初始上传速率限制。 客户可使用以下公式来估算将其所有数据上传到 Azure 所需的时间（以天为单位）：
同步组上传文件所需的时间（以天为单位）=（服务器终结点中的对象数）/(20 * 60 * 60 * 24)
将数据拆分到多个服务器终结点和同步组可加快此初始数据上传速度，因为多个同步组可以以每秒 20 项的速率并行上传。 因此，两个同步组将以每秒 40 项的组合速率运行。 完成的总时间将会是需要同步最多文件的同步组的预估时间。
命名空间下载吞吐量：将新服务器终结点添加到现有同步组时，Azure 文件同步代理不会从云终结点下载任何文件内容。 它将首先同步整个命名空间，然后触发后台调用来将文件整体下载，或者根据服务器终结点上设置的云分层策略进行下载（如果启用了云分层）。
| 持续同步 | 详细信息 |
|---|---|
| 同步的对象数 | 125,000 个对象（~1% 的改动） |
| 数据集大小 | 50 GiB |
| 平均文件大小 | ~500 KiB |
| 上传吞吐量 | 每个同步组每秒 20 个对象 |
| 完整下载吞吐量* | 每秒 60 个对象 |
*如果启用了云分层，则性能可能更好，因为只会下载一部分文件数据。 只有当已缓存文件的数据在任何终结点上发生更改时，Azure 文件同步才会下载这些数据。 对于任何已分层的或新创建的文件，代理不会下载文件数据，而仅会将命名空间同步到所有服务器终结点。 代理还支持在用户访问已分层文件时下载这些文件的一部分。
注意
这些数字并不表明你将体验的性能。 实际性能将取决于本部分开头列出的多个因素。
作为常规部署指南，请记住以下几点：
- 对象吞吐量大约按服务器上的同步组数量成比例缩放。 在服务器上将数据拆分到多个同步组会实现更好的吞吐量，吞吐量还受限于服务器和网络。
- 对象吞吐量与每秒 MiB 数这一吞吐量成反比。 对于较小的文件，每秒处理的对象数这一吞吐量较高，但每秒 MiB 数这一吞吐量较低。 相反，对于较大的文件，每秒处理的对象数较少，但每秒 MiB 数这一吞吐量较高。 每秒 MiB 数这一吞吐量受限于 Azure 文件规模目标。