你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure NetApp 文件的资源限制
了解 Azure NetApp 文件的资源限制，可帮助你管理卷。
资源限制
下表描述 Azure NetApp 文件的资源限制：
| 资源 | 默认限制 | 可通过支持请求进行调整 |
|---|---|---|
| 每个订阅的区域容量配额 | 25 TiB | 是 |
| 每个 Azure 区域每个订阅的 NetApp 帐户数 | 10 | 是 |
| 每个 NetApp 帐户的容量池数 | 25 | 是 |
| 每个订阅的卷数 | 500 | 是 |
| 每个容量池的卷数 | 500 | 是 |
| 每个卷的快照数 | 255 | 否 |
| 虚拟网络中（包括立即对等互联的 VNet）访问 Azure NetApp 文件托管 VNet 的卷的 IP 的数量 |
|
否 |
| 单个容量池的最小大小 | 1 TiB* | 否 |
| 单个容量池的最大大小 | 1000 TiB | 是 |
| 单个常规卷的最小大小 | 100 GiB | 否 |
| 单个常规卷的最大大小 | 100 TiB | 否 |
| 单个大型卷的最小大小 | 102,401 GiB | 否 |
| 大型卷大小增加 | 30% 的最低预配大小 | 是 |
| 单个大型卷的最大大小 | 500 TiB | 否 |
| 单个文件的最大大小 | 16 TiB | 否 |
| 单个目录中目录元数据的最大大小 | 320 MB | 否 |
| 单个目录中的文件数上限 | 大约 400 万。 参阅确定目录是否将达限制大小。 |
否 |
每个卷的最大文件数 maxfiles |
106,255,630 | 是 |
| 每个卷的最大导出策略规则数 | 5 | 否 |
| 每个卷的最大配额规则数 | 100 | 否 |
| 分配给手动 QoS 卷的最小吞吐量 | 1 MiB/s | 否 |
| 分配给手动 QoS 卷的最大吞吐量 | 4,500 MiB/s | 否 |
| 跨区域复制数据保护卷（目标卷）的数量 | 50 | 是 |
| 跨区域复制数据保护卷（目标卷）的数量 | 50 | 是 |
| 每个卷的基于策略（计划）备份的最大数量 |
每小时、每日、每周和每月备份保留计数组合最大值为 1019。 |
否 |
| 保护卷的大小上限 | 100 TiB | 否 |
| 每个订阅可备份的卷的最大数目 | 20 | 是 |
| 每天每个卷的手动备份最大数量 | 5 | 否 |
| 每个区域每个订阅支持冷访问的最大卷数 | 10 | 是 |
* 如果容量池中的所有卷都使用标准网络功能，则只能利用 1 TiB 最小值。 1 TiB 容量池已推出正式版。 在使用该功能之前，必须注册该功能。 如果任何卷都使用基本网络功能，则最小大小为 4 TiB。
有关详细信息，请参阅容量管理的常见问题解答。
了解与 Azure NetApp 文件网络功能相关的限制和约束，请参阅 Azure NetApp 文件网络规划指南。
确定目录是否将达限制大小
可以从客户端使用 stat 命令来查看目录是否即将达到目录元数据的最大大小限制 (320 MB)。 如果达到 Azure NetApp 文件的单个目录的最大大小限制，则会发生错误 No space left on device。
对于 320-MB 的目录，块数为 655360，每个块的大小为 512 字节。 （即 320x1024x1024/512。）根据此数字，相当于一个 320-MB 的目录最多可包含大约 400 万个文件。 但是，实际的最大文件数目可能更小，具体取决于多种因素，例如，目录中包含非 ASCII 字符的文件数。 因此，应按如下所示使用 stat 命令来确定目录是否接近其限制。
示例：
[makam@cycrh6rtp07 ~]$ stat bin
File: 'bin'
Size: 4096 Blocks: 8 IO Block: 65536 directory
[makam@cycrh6rtp07 ~]$ stat tmp
File: 'tmp'
Size: 12288 Blocks: 24 IO Block: 65536 directory
[makam@cycrh6rtp07 ~]$ stat tmp1
File: 'tmp1'
Size: 4096 Blocks: 8 IO Block: 65536 directory
限制Maxfiles
Azure NetApp 文件卷有一个名为 maxfiles 的限制。 maxfiles 限制是一个卷可以包含的文件数。 Linux 文件系统将此限制称为 Inode。 Azure NetApp 文件卷的 maxfiles 限制是基于卷的大小（配额）编制索引。 卷的 maxfiles 限制按照每 TiB 预配的卷大小 21,251,126 个文件的速率递增或递减。
服务基于其预配的大小动态调整卷的 maxfiles 限制。 例如，最初配置为 1 TiB 大小的卷的 maxfiles 限制将为 21,251,126。 对卷大小的后续更改会根据以下规则自动重新调整 maxfiles 限制：
对于大小高达 100 TiB 的卷：
| 卷大小（配额） | maxfiles 限制的自动重新调整 |
|---|---|
| <= 1 TiB | 21,251,126 |
| > 1 TiB 但 <= 2 TiB | 42,502,252 |
| > 2 TiB 但 <= 3 TiB | 63,753,378 |
| > 3 TiB 但 <= 4 TiB | 85,004,504 |
| > 4 TiB 但 <= 100 TiB | 106,255,630 |
重要
如果卷的大小（配额）超过 4 TiB，并且你想增加 maxfiles 限制，则必须发起支持请求。
对于 100 TiB 或以下的卷，如果已为卷分配至少 5 TiB 的配额，则可发起支持请求以将 maxfiles (Inode) 限制提高到 106,255,630 以上。 每增加 106,255,630 个文件（或低于此数量），需要将相应的卷配额增加 5 TiB。 例如，如果将 maxfiles 限制从 106,255,630 个文件增加到 212,511,260 个文件（或二者之间的任意数量），则需要将卷配额从 5 TiB 增加到 10 TiB。
对于 100 TiB 或以下的卷，如果卷配额至少为 25 TiB，则可以将 maxfiles 限制增加到 531,278,150。
重要
将文件或文件夹分配给 Azure NetApp 文件卷时，它们将计入 maxfiles 限制。 如果删除了文件或文件夹，maxfiles 分配的内部数据结构将保持不变。 例如，如果卷中使用的文件增加到 63,753,378 和 100,000 个文件，maxfiles 分配保持在 63,753,378。
卷超过 maxfiles 限制后，即使减少了实际使用的文件计数，也无法将卷大小减小到与该 maxfiles 限制对应的配额以下。 例如，2 TiB 卷的 maxfiles 限制为 63,753,378。 如果在该卷中创建的文件超过 63,753,378 个，则卷配额不能减少到其相应的索引 2 TiB 以下。
对于大型卷：
| 卷大小（配额） | maxfiles 限制的自动重新调整 |
|---|---|
| > 50 TiB | 2,550,135,120 |
可以使用支持请求将 maxfiles 限制增加到 2,550,135,120 以上。 每增加 2,550,135,120 个文件（或低于此数量），需要将相应的卷配额增加 120 TiB。 例如，如果将 maxfiles 限制从 2,550,135,120 个文件增加到 5,100,270,240 个文件（或二者之间的任意数量），则需要将卷配额增加到至少 240 TiB。
500 TiB 卷的最大 maxfiles 值为 10,625,563,000 个文件。
不能通过配额请求为数据保护卷设置 maxfiles 限制。 Azure NetApp 文件会自动增加数据保护卷的 maxfiles 限制，以适应复制到卷的文件数。 当数据保护卷发生故障转移时，maxfiles 限制将保留故障转移前的最后一个值。 在这种情况下，可以提交卷的 maxfiles配额请求。
请求调高限制
可创建 Azure 支持请求以上调资源限制表中的可调整限制。
注意
根据区域中的可用资源以及请求增加的限制，Azure 支持可能需要其他信息来确定该请求的可行性。
转到“支持 + 故障排除”下的“新建支持请求”。
在“问题描述”选项卡下，提供必要的信息：
- 对于“问题类型”，选择“服务和订阅限制(配额)”。
- 对于“订阅”，请选择自己的订阅。
- 对于“配额类型”，选择“存储: Azure NetApp 文件限制”。
在“其他详细信息”选项卡下，在“请求详细信息”字段中选择“输入详细信息” 。
若要请求增加限额，请在显示的“配额详细信息”窗口中提供以下信息：
在“配额类型”中，选择要增加的资源类型。
例如：- 每个订阅的区域容量配额 (TiB)
- 每个 Azure 区域每个订阅的 NetApp 帐户数
- 每个订阅的卷数
在“请求的区域”中，选择你的区域。
当前和默认大小显示在“配额状态”下。输入一个值，请求增加指定的配额类型。
选择“保存并继续”。 选择“查看 + 创建”，以创建请求。