你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文提供有关为 Azure 文件同步选择和调整云分层策略的指导。阅读本文之前，请确保了解云分层的工作原理。 有关云分层基础知识，请参阅 了解 Azure 文件同步云分层。 有关包含示例的云分层策略的深入说明，请参阅 Azure 文件同步云分层策略。
局限性
Windows 系统卷不支持云分层。
如果使用文件服务器资源管理器（FSRM）在服务器终结点上进行配额管理，我们建议在文件夹级别应用配额，而不是在卷级别应用配额。 如果有卷级别 FSRM 配额，仍可启用云分层。 设置 FSRM 配额后，调用的可用空间查询 API 会根据配额设置自动报告卷上的可用空间。 但是，当卷根上存在硬配额时，卷上的实际可用空间和卷上的配额受限空间可能不同。 如果 Azure 文件同步认为服务器终结点上没有足够的可用卷空间，这可能会导致无休止地分层。
要进行分层的文件的最小文件大小
文件的进行分层所需的最小文件大小取决于文件系统的簇大小。 适用于云分层的最小文件大小为群集大小的2倍，并且至少为8 KiB。 下表说明了可根据卷群集大小分层的最小文件大小：
| 卷群集大小 | 此大小或更大的文件可以进行分层 |
|---|---|
| 4 KiB 或更小（4,096 字节） | 8 KiB |
| 8 KiB （8,192 字节） | 16 KiB |
| 16 KiB （16,384 字节） | 32 KiB |
| 32 KiB （32,768 字节） | 64 KiB |
| 64 KiB （65,536 字节） | 128 KiB |
| 128 KiB （131,072 字节） | 256 KiB |
| 256 KiB （262,144 字节） | 512 KiB |
| 512 KiB （524,288 字节） | 1 MiB（兆字节） |
| 1 MiB （1,048,576 字节） | 2 MiB |
| 2 MiB （2,097,152 字节） | 4 MiB |
可以通过从管理命令提示符执行命令 fsutil fsinfo ntfsinfo volumedriveletter: 来找到卷群集大小。 “ 每个群集的字节 数”字段以字节为单位显示卷群集大小，以千字节为单位的值显示在括号中。
Azure 文件同步支持对群集大小最多 2 MiB 的卷进行云分层。
Windows 使用的所有文件系统都根据群集大小（也称为分配单元大小）组织硬盘。 群集大小表示可用于保存文件的最小磁盘空间量。 当文件大小不达到群集大小的偶数倍时，必须使用额外的空间来保存文件 - 最多保留群集大小的下一个倍数。
Windows Server 2012 R2 及更新的 NTFS 卷支持 Azure 文件同步。 下表介绍了使用 Windows Server 创建新的 NTFS 卷时的默认群集大小。
| 卷大小 | Windows Server |
|---|---|
| 7 MiB – 16 TiB | 4 KiB |
| 16 TiB – 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
可能是在创建卷时，您手动将卷格式化为不同的群集大小。 如果卷源自较早版本的 Windows，则默认群集大小也可能不同。 即使选择小于 4 KiB 的群集大小，8 KiB 限制作为可分层的最小文件大小仍适用。 （即使从技术上说，2 倍的群集大小也等于小于 8 KiB）。
绝对最小值的原因是 NTFS 存储极小文件的方式 - 1 KiB 到 4 KiB 大小的文件。 根据卷的其他参数，可能不会在磁盘的群集中存储小文件。 将这些文件直接存储在卷的主文件表或“MFT 记录”中可能更有效。 云分层重分析点始终存储在磁盘上，恰好占用一个群集。 分层此类小文件最终不会节省空间。 极端情况下，可能会导致在启用了云分层后使用更多空间。 为防范这种情况，对于 4 KiB 或更小的群集大小，云分层将进行分层的文件的最小大小为 8 KiB。
选择初始策略
通常，在服务器终结点上启用云分层时，应为每个单独的服务器终结点创建一个本地虚拟驱动器。 隔离服务器终结点可以更轻松地了解云分层的工作原理并相应地调整策略。 但是，即使在同一驱动器上有多个服务器终结点，Azure 文件同步也能正常工作，有关详细信息，请参阅 本地卷上的“多个服务器终结点 ”部分。 还建议在首次启用云分层时，将日期策略保持为已禁用状态，将卷可用空间策略保持为大约 10% 到 20%。 对于大多数文件服务器卷，20% 卷可用空间通常是最佳选项。
注释
在某些迁移场景中，如果你在 Windows Server 实例上预配的存储少于源实例上的存储，则可以在将文件分层迁移到云的过程中将卷可用空间临时设置为 99%，然后在迁移完成后将其设置为一个更有用的级别。
为简单起见并且清楚地了解项目的分层方式，建议主要调整卷可用空间策略，并将日期策略保持为已禁用状态（除非需要）。 建议这样做，因为大多数客户发现，使用尽可能多的热文件填充本地缓存并将其余文件分层到云中很有价值。 但是，如果想要主动释放本地磁盘空间，并且知道在日期策略中指定的天数之后访问的服务器终结点中的文件不需要在本地保留，则日期策略可能会很有用。 设置日期策略可为同一卷上的其他终结点释放宝贵的本地磁盘容量，以缓存其更多文件。
设置策略后，请相应地监视出口和调整这两个策略。 建议通过 Azure Monitor 中的指标查看 云分层召回大小 和 按应用程序划分的云分层召回大小 。 我们还建议监视服务器终结点的缓存命中率，以确定本地缓存中已打开的文件的百分比。 若要了解如何监视流出量，请参阅监视云流出量。
调整策略
如果经常从 Azure 中召回的文件数大于所需，则热文件的量可能会超出你在本地服务器卷上可用于保存它们的空间。 如果可能，请增加本地卷大小，并/或以较小增量减小卷可用空间策略百分比。 将卷可用空间百分比减小太多也可能会产生负面影响。 数据集中的高流失率需要更多存储空间 - 用于存储新文件和召回不常使用的文件。 分层开始时的延迟最多为一小时，随后需要处理时间，这便是为何应始终在卷上有足够闲空间。
保留更多的本地数据意味着降低出口成本，因为从 Azure 中召回的文件更少，但也需要大量本地存储，而本地存储则以自己的成本计算。
调整卷可用空间策略时，应保留本地的数据量取决于以下因素：带宽、数据集的访问模式和预算。 使用低带宽连接时，可能需要更多本地数据，以确保用户延迟最少。 反之，可以给定时间段内的变动率为依据。 例如，如果您知道 1 TiB 数据集中的 10% 每月更改或频繁访问，则可能需要将 100 GiB 保留在本地，这样您就不需要频繁回收文件。 如果卷为 2 TiB，建议在本地保留 5% (100 GiB)；也就是说，剩余 95% 是卷可用空间百分比。 不过，你应添加缓冲区，以将流失更高的时间段纳入考虑；也就是说，先设置较高的卷可用空间百分比，以后再根据需要进行调整。
标准操作过程
- 首次通过 Azure 文件同步迁移到 Azure 文件存储时，云分层依赖于初始上传
- 云分层会每六十分钟检查一次是否符合卷可用空间和日期策略
- 在迁移文件时在 Robocopy 上使用 /LFSM 开关将允许文件在初始上传期间同步和云分层以留出空间
- 如果在形成热度地图之前进行分层，文件将按上次修改的时间戳进行分层