通过

选择云分层策略

  • 项目

本文提供有关为 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 卷时的默认群集大小。

Volume size 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 开关，会使文件可以进行同步和云分层，以在初始上传过程中腾出空间
  • 如果在构造热度地图之前进行分层，则文件会按上次修改时间戳进行分层

后续步骤