本文提供有关为 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 |
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 文件时,云分层功能取决于初始上传过程
- 云分层每60分钟检查卷空间剩余量及日期策略的合规性
- 在迁移文件时在 Robocopy 上使用 /LFSM 开关将允许文件在初始上传期间同步和云分层以留出空间
- 如果在形成热度地图之前进行分层,文件将按上次修改的时间戳进行分层