本文提供有关为 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 文件同步服务器的使用情况评估卷可用空间百分比和日期策略“天数”。 例如，如果您期望最近 7 天的数据缓存在服务器上，则可以将日期策略设置为 7 天，并确保卷上的总卷大小和当前可用空间允许过去 7 天的内容变动（新的内容和由于访问已分层内容而被召回的数据在召回时缓存）。 假设卷大小为 100 GiB，而过去 7 天的变动量约为 10 GiB，则卷必须允许缓存最新的 10 GiB 并将剩余数据分层到云中。 在这种情况下，卷可用空间为 20% 是公平的，因为 Azure 文件同步将尝试保留 20%（即 20 GiB 可用空间），以便在 7 天内支持 10 GiB 的新内容，并为文件系统开销和缓存提供一些额外的空间，并偶尔缓存多余的数据。
设置非常大的可用空间可以显著减少服务器上本地保存的数据量。 这意味着你预期几乎所有文件都被分级存储。 如果本地缓存仅包含一小部分工作数据集，则用户可能会从 Azure 获得更频繁的召回。 这可能会增加访问延迟，并可能导致 Azure 文件存储产生额外的事务和数据传输成本。
由于卷可用空间策略优先于日期策略，因此 Azure 文件同步将根据需要对文件进行分层，以达到配置的可用空间目标，而不考虑最近访问这些文件的时间。 同样，为日期策略阈值配置小日计数可能会导致文件在处于非活动状态后不久进行分层，即使卷可用空间策略不强制过度分层也是如此。
Microsoft建议采用以下方法：
- 配置卷可用空间策略，该策略与要缓存在服务器上的卷容量和预期工作集保持一致。
- 选择反映实际文件使用模式的日期策略。 此设置是可选的。
- 监视当前可用空间、缓存命中率、召回大小、数据分层大小和总体工作负荷性能，以微调可用空间策略或总卷大小。
此方法有助于在本地性能和云存储利用率之间保持适当的平衡。
标准操作过程
- 初次通过 Azure 文件同步迁移到 Azure 文件时，云分层功能取决于初始上传过程
- 云分层每60分钟检查卷空间剩余量及日期策略的合规性
- 在迁移文件时在 Robocopy 上使用 /LFSM 开关将允许文件在初始上传期间同步和云分层以留出空间
- 如果在形成热度地图之前进行分层，文件将按上次修改的时间戳进行分层