规划 Azure 文件同步部署

文件将存储在云中的 Azure 文件共享中。 可以通过两种方式使用 Azure 文件共享：直接装载这些无服务器 Azure 文件共享 (SMB)，或使用 Azure 文件同步功能在本地缓存 Azure 文件共享。所选择的部署方式决定了规划部署时需要考虑的事项。

• 直接装载 Azure 文件共享：因为 Azure 文件存储提供 SMB 访问权，因此可以使用 Windows、macOS 和 Linux 中提供的标准 SMB 客户端在本地或云中装载 Azure 文件共享。 由于 Azure 文件共享是无服务器的，因此针对生产方案进行部署不需要管理文件服务器或 NAS 设备。 这意味着无需应用软件修补程序或换出物理磁盘。

• 使用 Azure 文件同步在本地缓存 Azure 文件共享：借助 Azure 文件同步，可以在 Azure 文件存储中集中管理组织的文件共享，同时又能保留本地文件服务器的灵活性、性能和兼容性。 Azure 文件同步可将本地（或云中的）Windows Server 转换为 Azure 文件共享的快速缓存。

管理概念

Azure 文件同步部署有三个基本管理对象：

• Azure 文件共享：Azure 文件共享是一种无服务器云文件共享功能，它提供具有“Azure 文件同步”同步关系的云终结点。 Azure 文件共享中的文件可以直接通过 SMB 或 FileREST 协议进行访问，但在将 Azure 文件共享与 Azure 文件同步一起使用时，建议通过 Windows Server 缓存来访问文件。这是因为 Azure 文件存储目前缺少一种 Windows Server 所具有的那种高效的更改检测机制，如果直接对 Azure 文件共享进行更改，需要经过一段时间之后才能传播回服务器终结点。
• 服务器终结点：与 Azure 文件共享进行同步的 Windows Server 上的路径。 它可以是某个卷上的特定文件夹，也可以是卷的根目录。 如果命名空间不重叠，多个服务器终结点可存在于同一个卷。
• 同步组：用于定义云终结点或 Azure 文件共享与服务器终结点之间的同步关系的对象。 同步组中的终结点保持彼此同步。 例如，如果想使用 Azure 文件同步管理两组不同文件，需创建两个同步组并在每个同步组中添加不同的终结点。

Azure 文件共享管理相关概念

Azure 文件共享将部署到存储帐户。存储帐户是代表存储共享池的顶级对象。 此存储池可用于部署多个文件共享和其他存储资源，例如 Blob 容器、队列或表。 部署到存储帐户中的所有存储资源共享应用于该存储帐户的限制。 若要了解当前存储帐户限制，请参阅 Azure 文件存储的可伸缩性和性能目标。

对于 Azure 文件存储部署，将使用两种主要类型的存储帐户：

• 常规用途版本 2 (GPv2) 存储帐户：使用 GPv2 存储帐户可以在标准的/基于硬盘（基于 HDD）的硬件上部署 Azure 文件共享。 除了存储 Azure 文件共享以外，GPv2 存储帐户还可以存储其他存储资源，例如 Blob 容器、队列或表。
• FileStorage 存储帐户：使用 FileStorage 存储帐户可以在高级/基于固态磁盘（基于 SSD）的硬件上部署 Azure 文件共享。 FileStorage 帐户只能用于存储 Azure 文件共享；其他存储资源（Blob 容器、队列、表等）都不能部署在 FileStorage 帐户中。 只有 FileStorage 帐户可同时部署 SMB 和 NFS 文件共享。

在 Azure 门户、PowerShell 或 CLI 中，可能会遇到一些其他的存储帐户类型。 两种存储帐户类型（BlockBlobStorage 和 BlobStorage 存储帐户）不能包含 Azure 文件共享。 可能会看到的其他两个存储帐户类型为常规用途版本 1 (GPv1) 和经典存储帐户，二者都可以包含 Azure 文件共享。 尽管 GPv1 和经典存储帐户可以包含 Azure 文件共享，但 Azure 文件存储的大多数新功能只能在 GPv2 和 FileStorage 存储帐户中使用。 因此，我们建议仅将 GPv2 和 FileStorage 存储帐户用于新部署，而升级 GPv1 和经典存储帐户的前提是它们已经存在于环境中。

Azure 文件同步管理相关概念

存储同步服务中会部署同步组，这些组是顶层对象，用于注册要与 Azure 文件同步一起使用的服务器，并包含同步组关系。 存储同步服务资源是存储帐户资源的对等物，可按类似方式部署到 Azure 资源组。 存储同步服务可以创建同步组，这些组包含多个存储帐户和多个已注册的 Windows 服务器中的 Azure 文件共享。

需要先向存储同步服务注册 Windows Server，然后才能在存储同步服务中创建同步组。 该步骤会创建一个已注册的服务器对象，表示服务器或群集与存储同步服务之间的信任关系。 若要注册存储同步服务，需要先在服务器上安装 Azure 文件同步代理。 一个服务器或群集一次只能注册一个存储同步服务。

同步组包含一个云终结点或 Azure 文件共享，以及至少一个服务器终结点。 服务器终结点对象包含用于配置云分层功能的设置，该功能可实现 Azure 文件同步的缓存功能。为了与 Azure 文件共享进行同步，包含 Azure 文件共享的存储帐户必须与存储同步服务位于同一 Azure 区域。

考虑所需存储同步服务的计数

前面的一个部分讨论了要为 Azure 文件同步配置的核心资源：存储同步服务。 一个 Windows 服务器只能注册到一个存储同步服务。 因此，通常最好只部署一个存储同步服务并在其上注册所有服务器。

仅在以下情况下创建多个存储同步服务：

• 你有不同的服务器集，这些集不得互相交换数据。 在这种情况下，你需要对系统进行设计，以排除某些服务器集，这些服务器集将与 Azure 文件共享同步，但该共享已在另一个存储同步服务中用作同步组中的云终结点。 也可以采用另一种方式对此进行思考：注册到不同存储同步服务的 Windows 服务器无法与同一 Azure 文件共享同步。
• 需要的注册服务器数或同步组数超过单个存储同步服务可以支持的数量。 如需更多详细信息，请参阅 Azure 文件同步缩放目标。

计划均衡的同步拓扑

在部署任何资源之前，请务必计划好要在本地服务器上同步的内容，以及要使用的 Azure 文件共享。 制定计划将有助于确定所需的存储帐户、Azure 文件共享和同步资源的数量。 即使数据目前不在 Windows Server 上或你要长期使用的服务器上，也需要考虑这些注意事项。 若要确定适用于你的情况的迁移路径，可参阅“迁移”部分。

在此步骤中，你将决定需要多少个 Azure 文件共享。 单个 Windows Server 实例（或群集）可以同步最多 30 个 Azure 文件共享。

卷上可能有更多文件夹当前作为 SMB 共享在本地共享给用户和应用。 描述此场景的最简单方法是设想 1:1 映射到 Azure 文件共享的本地共享。 如果共享数目够小，即单个 Windows Server 实例低于 30 个时，建议使用 1:1 映射。

如果共享数目超过 30 个，通常不需要将本地共享 1:1 映射到 Azure 文件共享。 请考虑以下选项。

共享分组

例如，如果人力资源 (HR) 部门有 15 个共享，则可以考虑将所有 HR 数据存储在一个 Azure 文件共享中。 将多个本地共享存储在一个 Azure 文件共享中不会阻止你在本地 Windows Server 实例上创建常规的 15 个 SMB 共享。 这只是意味着将这 15 个共享的根文件夹组织为公用文件夹下的子文件夹。 然后将此公用文件夹同步到 Azure 文件共享。 这样，这组本地共享便只需要云中的单个 Azure 文件共享。

卷同步

Azure 文件同步支持将卷的根同步到 Azure 文件共享。 如果同步卷根，则所有子文件夹和文件都会转到相同的 Azure 文件共享。

同步卷的根并非总是最佳选项。 同步多个位置有很多好处。 例如，这样做可帮助降低每个同步范围的项目数。 我们测试了 Azure 文件共享和 Azure 文件同步，每个共享有 1 亿个项目（文件和文件夹）。 但是，在单个共享中，最好试着将数目控制在 2000 万或 3000 万以下。 使用较少数量的项目设置 Azure 文件同步不只是对文件同步有利。在下面这些场景中，项目数量较少的优势也是显而易见的：

• 对云内容的初始扫描可以更快地完成，这会减少命名空间出现在启用 Azure 文件同步的服务器上的等待时间。
• 从 Azure 文件共享快照进行云端还原会更快。
• 本地服务器的灾难恢复可以显著提高速度。
• 可以更快地检测和同步在 Azure 文件共享中直接进行的更改（在同步之外）。

部署映射的结构化方法

在稍后的步骤中部署云存储之前，请务必在本地文件夹与 Azure 文件共享之间创建映射。 此映射会告知，你要预配哪些 Azure 文件同步“同步组”资源以及具体数量。 同步组会将 Azure 文件共享和服务器上的文件夹关联在一起，并建立同步连接。

若要确定需要多少个 Azure 文件共享，请参考以下限制和最佳做法。 这样做有助于优化映射。

• 安装了 Azure 文件同步代理的服务器可与最多 30 个 Azure 文件共享同步。

• Azure 文件共享部署在存储帐户中。 这样安排会使存储帐户成为 IOPS 和吞吐量等性能指标的缩放目标。

  部署 Azure 文件共享时，应注意存储帐户的 IOPS 限制。 理想情况下，应该将文件共享按 1:1 与存储帐户映射。 但由于组织和 Azure 同时施加各种限制和制约，不一定始终能够实现这种映射。 如果无法在一个存储帐户中只部署一个文件共享，可考虑哪些共享会非常活跃和哪些将不会那么活跃，以确保不会将使用率最高的文件共享放置在同一存储帐户中。

  如果计划将应用提升到将在本机使用 Azure 文件共享的 Azure，则可能需要提高 Azure 文件共享的性能。 如果现在甚至以后都可以这样使用，最好在其自己的存储帐户中创建一个标准 Azure 文件共享。

• 每个 Azure 区域的每个订阅的存储帐户限制为 250 个。

最佳实践是使每个同步范围的项目数保持较低。 这是在将文件夹映射到 Azure 文件共享时要考虑的重要因素。 Azure 文件同步对每个共享使用 1 亿个项目（文件和文件夹）进行测试。 但是，在单个共享中，最好将项目数控制在 2000 万或 3000 万以下。 如果开始超过这些数量，请将命名空间拆分为多个共享。 如果一直大致低于这些数量，则可以继续将多个本地共享分组到相同 Azure 文件共享中。 这种做法可为你提供增长空间。

在这种情况下，可能能够以逻辑方式将一组文件夹同步到相同的 Azure 文件共享（使用前面提到的新的公用根文件夹方法）。 但是，重新分组文件夹使它们同步到两个（而不是一个）Azure 文件共享中可能会更好。 可以使用此方法使每个文件共享的文件和文件夹数在服务器间保持平衡。 还可以拆分本地共享并在更多的本地服务器上同步，从而增加每个额外服务器再同步 30 个 Azure 文件共享的能力。

常见文件同步方案和注意事项

#	同步方案	支持	注意事项（或限制）	解决方案（或解决方法）
1	将包含多个磁盘/卷和多个共享的文件服务器同步到同一目标 Azure 文件共享（合并）	否	目标 Azure 文件共享（云终结点）仅支持与一个同步组同步。 同步组仅支持在每个已注册服务器上使用一个服务器终结点。	1) 首先将一个磁盘（其根卷）同步到目标 Azure 文件共享。 从最大的磁盘/卷开始将有助于满足本地存储要求。 配置云分层以将所有数据分层到云，从而释放文件服务器磁盘上的空间。 将其他卷/共享中的数据移到正在同步的当前卷。 继续逐个执行这些步骤，直到所有数据已分层到云/完成迁移。 2) 每次以一个根卷（磁盘）为目标。 使用云分层将所有数据分层到目标 Azure 文件共享。 从同步组中删除服务器终结点，使用下一个根卷/磁盘重新创建终结点，执行同步，然后重复该过程。 注意：可能需要重新安装代理。 3) 建议使用多个目标 Azure 文件共享（根据性能要求使用相同或不同的存储帐户）
2	将包含单个卷和多个共享的文件服务器同步到同一目标 Azure 文件共享（合并）	是	在同步到同一目标 Azure 文件共享的每个注册服务器上不能有多个服务器终结点（同上）	同步包含多个共享或顶级文件夹的卷的根目录。 有关详细信息，请参阅共享分组概念和卷同步。
3	将包含多个共享和/或卷的文件服务器同步到单个存储帐户下的多个 Azure 文件共享（1:1 共享映射）	是	单个 Windows Server 实例（或群集）可以同步最多 30 个 Azure 文件共享。 存储帐户是性能缩放目标。 IOPS 和吞吐量在文件共享之间共享。 将每个同步组的项数保持在每个共享包含 1 亿个项（文件和文件夹）以内。 理想情况下，最好在每个共享中包含不超过 2 千万到 3 千万个项。	1) 使用多个同步组（同步组数量 = 要同步到的 Azure 文件共享数量）。 2) 在此方案中，每次只能同步 30 个共享。 如果该文件服务器上的共享数超过 30 个，请使用共享分组概念和卷同步来减少源上的根目录或顶级文件夹数量。 3) 使用本地的其他文件同步服务器并将数据拆分/移到这些服务器，以解决源 Windows 服务器上的限制。
4	将包含多个共享和/或卷的文件服务器同步到其他存储帐户下的多个 Azure 文件共享（1:1 共享映射）	是	单个 Windows Server 实例（或群集）最多可以同步 30 个 Azure 文件共享（相同或不同的存储帐户）。 将每个同步组的项数保持在每个共享包含 1 亿个项（文件和文件夹）以内。 理想情况下，最好在每个共享中包含不超过 2 千万到 3 千万个项。	方法同上
5	将包含单个根卷或共享的多个文件服务器同步到同一目标 Azure 文件共享（合并）	否	同步组不能使用已在另一个同步组中配置的云终结点（Azure 文件共享）。 尽管同步组可以在不同的文件服务器上具有服务器终结点，但文件不能不同。	请遵循上述方案 #1 中的指导，并注意每次以一个文件服务器为目标的附加要点。

创建映射表

使用前面的信息来确定所需的 Azure 文件共享数目，以及现有数据的哪些部分最终会出现在哪个 Azure 文件共享中。

创建一个表来记录你的想法，这样你就可以在需要时进行参考。 保持井然有序非常重要，因为当你同时预配许多 Azure 资源时，可能会很容易丢失映射计划的详细信息。 下载以下 Excel 文件用作模板，以帮助创建映射。

下载命名空间映射模板。

Windows 文件服务器注意事项

若要在 Windows Server 上启用同步功能，需要安装可下载的 Azure 文件同步代理。 Azure 文件同步代理提供两个主要组件：FileSyncSvc.exe，这是负责监视服务器终结点上所做更改和启动同步会话的后台 Windows 服务，以及 StorageSync.sys，这是可实现云分层功能和快速灾难恢复的文件系统筛选器。

操作系统要求

以下 Windows Server 版本支持 Azure 文件同步：

版本	支持的 SKU	支持的部署选项
Windows Server 2022	Azure、Datacenter、Standard 和 IoT	“完整”和“核心”
Windows Server 2019	Datacenter、Standard 和 IoT	“完整”和“核心”
Windows Server 2016	Datacenter、Standard 和 Storage Server	“完整”和“核心”
Windows Server 2012 R2*	Datacenter、Standard 和 Storage Server	“完整”和“核心”

*需要下载并安装 WINDOWS 管理框架 (WMF) 5.1。 需下载和安装的 Windows Server 2012 R2 的相应包为 Win8.1AndW2K12R2-KB*******-x64.msu。

将来的 Windows Server 版本将在发布后添加。

最低系统资源要求

Azure 文件同步需要使用服务器（物理或虚拟），服务器需配有至少一个 CPU、至少 2 GiB 的内存，以及一个使用 NTFS 文件系统进行了格式化的本地附加卷。

对于大多数生产工作负载，不建议仅使用最低要求配置 Azure 文件同步服务器。 有关详细信息，请参阅推荐使用的系统资源。

推荐使用的系统要求

与其他任何服务器功能或应用程序一样，Azure 文件同步的系统资源要求取决于部署的规模；服务器上的部署规模越大，需要的系统资源就越多。 就 Azure 文件同步而言，相应的部署规模取决于所有服务器终结点上的对象数和数据集上的代码改动情况。 一个服务器可以在多个同步组中设置服务器终结点，且下表中列出的对象的数量会影响服务器所附加到的完整命名空间的规模。

例如，具有 1 千万个对象的服务器终结点 A + 具有 1 千万个对象的服务器终结点 B = 2 千万个对象。 对于这样一个部署，建议配置 8 个 CPU，16 GiB 的稳态内存，并为初始迁移配置 48 GiB 内存（如有可能）。

出于性能原因，命名空间数据存储在内存中。 因此，命名空间越大，需要的内存越多，这样才能保持良好的性能，更多的代码改动也需要更多的 CPU 来处理。

下表提供了命名空间的大小以及典型常规用途文件共享的容量转换，其中平均文件大小为 512 KiB。 如果你的文件大小比上述数据小，请考虑为同一容量增加额外的内存。 应根据命名空间的大小来配置内容容量。

命名空间大小 - 文件和目录（百万）	典型容量 (TiB)	CPU 内核数	建议的内存 (GiB)
3	1.4	2	8（初始同步）/ 2（典型代码改动）
5	2.3	2	16（初始同步）/ 4（典型代码改动）
10	4.7	4	32（初始同步）/ 8（典型代码改动）
30	14.0	8	48（初始同步）/ 16（典型代码改动）
50	23.3	16	64（初始同步）/ 32（典型代码改动）
100*	46.6	32	128（初始同步）/ 32（典型代码改动）

*不建议同步超过 1 亿个文件和目录。 这是基于我们测试的阈值的软限制。 有关详细信息，请参阅 Azure 文件同步规模目标。

评估 cmdlet

在部署 Azure 文件同步之前，应当使用 Azure 文件同步评估 cmdlet 评估它是否与系统兼容。 此 cmdlet 用于检查文件系统和数据集的潜在问题，例如不受支持的字符或不受支持的操作系统版本。 这些检查涵盖了下面提到的大多数但并非全部功能；建议仔细读完本部分的剩余内容，以确保部署顺利进行。

可以通过安装 Az PowerShell 模块来安装评估 cmdlet，该模块可按照以下说明进行安装：安装和配置 Azure PowerShell。

使用情况

可以采用以下多种不同的方式调用评估工具：可以执行系统检查、数据集检查或者同时执行这两种检查。 若要同时执行系统和数据集检查，请使用以下命令：

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

若要仅测试数据集，请使用以下命令：

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

若要仅测试系统要求，请使用以下命令：

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

若要以 CSV 格式显示结果，请使用以下命令：

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

文件系统兼容性

仅支持在直接附加的 NTFS 卷上使用 Azure 文件同步。 Windows Server 上设置有直连存储 (DAS) 意味着由 Windows Server 操作系统提供文件系统。 可以通过以物理方式将磁盘附加到文件服务器、通过将虚拟磁盘附加到文件服务器虚拟机（例如由 Hyper-v 托管的虚拟机），甚至可以通过 iSCSI，来提供 DAS。

仅支持 NTFS 卷；不支持 ReFS、FAT、FAT32 和其他文件系统。

下表显示 NTFS 文件系统功能的互操作状态：

Feature	支持状态	说明
访问控制列表 (ACL)	完全支持	Windows 样式随机访问控制列表由 Azure 文件同步功能负责留存，并由 Windows Server 在服务器终结点上强制实施。 当直接装载 Azure 文件共享时，也可以强制实施 ACL，但这需要额外配置。 请参阅“标识”部分以了解详细信息。
硬链接	已跳过
符号链接	已跳过
装入点	部分支持	装入点可能是服务器终结点的根，但如果包含在服务器终结点的命名空间内，则跳过此装入点。
交接点	已跳过	例如，分布式文件系统中的 DfrsrPrivate 和 DFSRoots 文件夹。
重分析点	已跳过
NTFS 压缩	部分支持	Azure 文件同步不支持进行了系统卷信息 (SVI) 目录压缩的卷上的服务器终结点。
稀疏文件	完全支持	稀疏文件会进行同步（不受阻），但作为完整文件同步到云。 如果在云中（或在其他服务器上）更改文件内容，则下载更改时，文件不再是稀疏文件。
备用数据流 (ADS)	保留但不同步	例如，由文件分类基础结构创建的分类标记不会同步。 每个服务器终结点的文件上的现有分类标记都保留不变。

Azure 文件同步还会跳过某些临时文件和系统文件夹：

文件/文件夹	注意
pagefile.sys	特定于系统的文件
Desktop.ini	特定于系统的文件
thumbs.db	缩略图的临时文件
ehthumbs.db	媒体临时文件的缩略图
~$*。*	Office 临时文件
*.tmp	临时文件
*.laccdb	Access DB 锁定文件
635D02A9D91C401B97884B82B3BCDAEA.*	内部同步文件
\系统卷信息	特定于卷的文件夹
$RECYCLE.BIN	Folder
\SyncShareState	用于同步的文件夹
.SystemShareInformation	Azure 文件共享中同步的文件夹

考虑本地磁盘需要多少可用空间

规划使用 Azure 文件同步时，请考虑计划启用服务器终结点的本地磁盘需要多少可用空间。

使用 Azure 文件同步时，需要考虑以下占用本地磁盘空间的情况：

• 如果启用云分层：

  • 分层文件的重分析点
  • Azure 文件同步元数据数据库
  • Azure 文件同步热存储
  • 热缓存中完整下载的文件（如果有）
  • 卷可用空间策略需求

• 如果禁用云分层：

  • 完整下载的文件
  • Azure 文件同步热存储
  • Azure 文件同步元数据数据库

我们将使用一个示例来说明如何估算所需的本地磁盘可用空间量。 假设你在 Azure Windows VM 上安装了 Azure 文件同步代理，并计划在磁盘 F 上创建服务器终结点。你有 100 万个文件并希望对所有文件进行分层，有 10 万个目录，并且磁盘群集大小为 4 KiB。 磁盘大小为 1000 GiB。 你希望启用云分层并将卷可用空间策略设置为 20%。

1. NTFS 为每个分层文件分配一个群集大小。 100 万个文件 * 4 KiB 群集大小 = 4,000,000 KiB (4 GiB)

   注意

   为了充分受益于云分层，建议使用较小的 NTFS 群集大小（小于 64KiB），因为每个分层文件会占用一个群集。 此外，分层文件占用的空间由 NTFS 分配。 因此，它不会显示在任何 UI 中。

2. 同步元数据的每个项都占用一个群集大小。 （100 万个文件 + 10 万个目录）* 4 KiB 群集大小 = 4,400,000 KiB (4.4 GiB)
3. Azure 文件同步热存储的每个文件占用 1.1 KiB。 100 万个文件 * 1.1 KiB = 1,100,000 KiB (1.1 GiB)
4. 卷可用空间策略为 20%。 1000 GiB * 0.2 = 200 GiB

在这种情况下，对于此命名空间，Azure 文件同步大约需要 209,500,000 KiB (209.5 GiB) 空间。 将此大小与所需的任何额外可用空间相加，就可以算出此磁盘需要多少可用空间。

故障转移群集

1. Windows Server 故障转移群集受 Azure 文件同步支持，用于“一般用途文件服务器”部署选项。 有关如何在故障转移集群上配置“通用文件服务器”角色的详细信息，请参阅部署双节点群集文件服务器。
2. Azure 文件同步支持的唯一方案是使用群集磁盘的 Windows Server 故障转移群集
3. 不可在“适用于应用程序数据的横向扩展文件服务器”(SOFS) 上或群集共享卷 (CSV) 或本地磁盘上使用故障转移群集。

重复数据删除

Windows Server 2022、Windows Server 2019、Windows Server 2016
支持重复数据删除，而不管是否在 Windows Server 2016、Windows Server 2019 和 Windows Server 2022 卷上的一个或多个服务器终结点上启用或禁用了云分层。 在启用了云分层的卷上启用重复数据删除后，即可在本地缓存更多文件，而无需预配更多存储。

在启用了云分层的卷上启用重复数据删除后，将根据云分层策略设置，按与普通文件类似的方式，对服务器终结点位置中经过“重复数据删除”优化的文件进行分层。 将经过“重复数据删除”优化的文件进行分层后，重复数据删除垃圾回收作业将自动运行，通过删除卷上不再被其他文件引用的、不必要的区块来回收磁盘空间。

请注意，卷空间节省效果仅适用于服务器；不会对 Azure 文件共享中的数据执行“重复数据删除”。

Windows Server 2012 R2
Azure 文件同步不支持在 Windows Server 2012 R2 上的同一卷上启用重复数据删除和云分层。 如果在卷上启用了重复数据删除，则必须禁用云分层。

说明

• 如果在安装 Azure 文件同步代理之前安装了重复数据删除，则需要重新启动才能支持在同一卷上使用重复数据删除和云分层。

• 如果重复数据删除是在启用云分层之后在卷上启用的，则初始重复数据删除优化作业将优化卷上尚未分层的的文件，这会对云分层产生以下影响：

  • 可用空间策略将使用热度地图，根据卷上的可用空间，继续对文件进行分层。
  • 由于重复数据删除优化作业会访问文件，日期策略会跳过对本来可能有资格进行分层的文件进行分层。

• 对于正在进行的重复数据删除优化作业，如果文件尚未分层，启用了日期策略的云分层操作会因“重复数据删除”的 MinimumFileAgeDays 设置而延迟执行。

  • 示例：如果 MinimumFileAgeDays 设置为 7 天，而云分层日期策略设置为 30 天，则日期策略将在 37 天后对文件分层。
  • 注意：一旦 Azure 文件同步对某个文件进行分层后，重复数据删除优化作业将立即跳过该文件。

• 如果某个服务器正在运行 Windows Server 2012 R2 且安装了 Azure 文件同步代理，当它升级到 Windows Server 2016、Windows Server 2019 或 Windows Server 2022 后，需要执行以下步骤，才能支持在同一卷上启用重复数据删除和云分层：

  • 卸载适用于 Windows Server 2012 R2 的 Azure 文件同步代理并重新启动服务器。
  • 下载适用于新服务器操作系统版本（Windows Server 2016、Windows Server 2019 或 Windows Server 2022）的 Azure 文件同步代理。
  • 安装 Azure 文件同步代理并重新启动服务器。

  注意：卸载并重新安装代理时，会保留服务器上的 Azure 文件同步配置设置。

分布式文件系统 (DFS)

Azure 文件同步支持与 DFS 命名空间 (DFS-N) 和 DFS 复制 (DFS-R) 进行互操作。

DFS 命名空间 (DFS-N)：Azure 文件同步在 DFS-N 实现中完全受支持。 可以在一个或多个文件服务器上安装 Azure 文件同步代理，以在服务器终结点和云终结点之间同步数据，然后使用 DFS-N 提供命名空间服务。 有关详细信息，请参阅 DFS 命名空间概述和 DFS 命名空间与 Azure 文件存储。

DFS 复制 (DFS-R) ：因为 DFS-R 和 Azure 文件同步都是复制解决方案，所以在大多数情况下建议将 DFS-R 替换为 Azure 文件同步。不过在以下几个方案中，可能需要同时使用 DFS-R 和 Azure 文件同步：

• 正在从 DFS-R 部署迁移至 Azure 文件同步部署。 有关详细信息，请参阅将 DFS 复制 (DFS-R) 部署迁移至 Azure 文件同步。
• 需要文件数据副本的本地服务器并非都能直接连接到 Internet。
• 分支服务器将数据合并至单个中心服务器，你希望在该服务器中使用 Azure 文件同步。

让 Azure 文件同步和 DFS-R 并行工作：

1. 必须在包含 DFS-R 复制文件夹的卷上禁用 Azure 文件同步云分层。
2. 不应在 DFS-R 只读复制文件夹上配置服务器终结点。
3. 只有一个服务器终结点可以与 DFS-R 位置重叠。 多个服务器终结点与其他活动 DFS-R 位置重叠可能会导致冲突。

有关详细信息，请参阅 DFS 复制概述。

Sysprep

不支持在已安装 Azure 文件同步代理的服务器上使用 sysprep，因为此操作会导致意外结果。 应该在部署服务器映像并完成 sysprep 迷你安装后再安装代理和注册服务器。

Windows 搜索

如果在服务器终结点上启用了云分层功能，则已分层的文件将跳过，并且不会由 Windows Search 进行索引。 非分层文件会适当进行索引。

其他分层存储管理 (HSM) 解决方案

其他 HSM 解决方案均无法使用 Azure 文件同步。

性能和可伸缩性

因为 Azure 文件同步代理在连接到 Azure 文件共享的 Windows Server 计算机上运行，所以实际的同步性能取决于基础结构中的许多元素：Windows Server 和基础磁盘配置、服务器与 Azure 存储之间的网络带宽、文件大小、总数据集大小以及数据集上的活动。 由于 Azure 文件同步在文件级别工作，因此可以更好地通过每秒处理的对象数（文件和目录）这一指标来度量基于 Azure 文件同步的解决方案的性能特征。

与对服务器终结点所做的更改不同，使用 Azure 门户或 SMB 对 Azure 文件共享所做的更改不会立即检测到并复制。 Azure 文件没有更改通知或日记，因此无法在文件更改时自动启动同步会话。 在 Windows Server 上，Azure 文件同步使用 Windows USN 日志在文件更改时自动启动同步会话

为了检测对 Azure 文件共享所做的更改，Azure 文件同步有一个称为“更改检测作业”的计划作业。 更改检测作业枚举文件共享中的每个文件，然后将它与该文件的同步版本进行比较。 当更改检测作业确定文件已更改时，Azure 文件同步会启动同步会话。 更改检测作业每 24 小时启动一次。 由于更改检测作业的工作原理是枚举 Azure 文件共享中的每个文件，因此大命名空间用时会长于较小的命名空间。 对于大命名空间，用时可能超过每 24 小时一次，才能确定哪些文件已更改。

有关详细信息，请参阅 Azure 文件同步性能指标和 Azure 文件同步规模目标

标识

Azure 文件同步可处理基于 AD 的标准标识，且只需要设置同步，而无需任何其他特殊设置。使用 Azure 文件同步时，一般情况下，大多数访问是通过 Azure 文件同步缓存服务器而不是通过 Azure 文件共享来完成的。 由于服务器终结点位于 Windows Server 上，并且 Windows Server 长期以来一直支持 AD 和 Windows 样式 ACL，因此，只要确保将注册了存储同步服务的 Windows 文件服务器加入域就行了，除此之外无需执行任何其他操作。 Azure 文件同步会将 ACL 存储在 Azure 文件共享中的文件上，并将其复制到所有服务器终结点。

即使直接对 Azure 文件共享所做的更改需要更长的时间才能同步到同步组中的服务器终结点，你可能还想确保自己能够在云中直接对文件共享强制实施 AD 权限。 为此，需要将存储帐户以“域加入”的方式加入本地 AD 中，就像 Windows 文件服务器的域加入方式一样。 若要详细了解如何将存储帐户“域加入”到客户拥有的 Active Directory，请参阅 Azure 文件存储 Active Directory 概述。

网络

Azure 文件同步代理使用 Azure 文件同步 REST 协议和 FileREST 协议与存储同步服务和 Azure 文件共享功能进行通信，这两种协议始终通过端口 443 使用 HTTPS。 SMB 从不用于在 Windows Server 和 Azure 文件共享之间上载或下载数据。 由于大多数组织都允许通过端口 443 传递 HTTPS 流量，这是访问大多数网站时的一个要求，因此通常不需要特殊网络配置就能部署 Azure 文件同步。

根据贵组织的策略或独特的法规要求，可能需要与 Azure 进行更严格的通信，因此 Azure 文件同步为配置网络提供了多种机制。 根据你的要求，你可以：

• 通过 ExpressRoute 或 Azure VPN 进行隧道同步和传递文件上传/下载流量。
• 利用 Azure 文件存储和 Azure 网络功能，如服务终结点和专用终结点。
• 配置 Azure 文件同步以支持环境中的代理。
• 限制 Azure 文件同步的网络活动。

若要详细了解 Azure 文件同步和网络，请参阅 Azure 文件同步网络注意事项。

加密

使用 Azure 文件同步时，需要考虑三个不同的加密层：对 Windows Server 的静态存储进行加密、在 Azure 文件同步代理与 Azure 之间的传输中进行加密，以及在 Azure 文件共享中对数据进行静态加密。

Windows Server 静态加密

对于 Azure 文件同步，有两个基本适用的关于 Windows Server 上加密数据的策略：一种是可对文件系统和写入其中的所有数据进行加密的文件系统下加密策略，另一种是文件格式内部的加密策略。 这些方法并不互斥；如果需要，它们可以一起使用，因为加密的目的不同。

为了在文件系统下提供加密，Windows Server 提供了 BitLocker 收件箱。 BitLocker 对 Azure 文件同步是完全透明的。使用 BitLocke 这类加密机制的主要原因是，阻止想窃取磁盘的人造成本地数据中心数据的物理泄漏，并防止有人通过旁加载未授权的操作系统来对数据执行未经授权的读取/写入操作。 若要了解有关 BitLocker 的详细信息，请参阅 BitLocker 概述。

与 BitLocker 工作方式类似的第三方产品（即都在 NTFS 卷下运行），其工作方式也应对 Azure 文件同步完全透明。

用于加密数据的另一个主要方法是在应用程序保存文件时加密文件的数据流。 有些应用程序可能会在本机上执行此操作，但通常情况并非如此。 用于加密文件数据流的方法的一个例子是 Azure 信息保护 (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RM。 使用 AIP/RMS 这类加密机制的主要原因是，阻止试图将文件共享中的数据复制到备用位置（如闪存驱动器）或试图通过电子邮件将其发送给未经授权的人员的人造成数据泄漏。 当文件的数据流加密为文件格式的一部分时，将继续在 Azure 文件共享中对此文件进行加密。

Azure 文件同步无法与位于文件系统上方但位于文件数据流下方的 NTFS 加密文件系统 (NTFS EFS) 或第三方加密解决方案进行互操作。

传输中加密

Azure 文件同步代理使用 Azure 文件同步 REST 协议和 FileREST 协议与存储同步服务和 Azure 文件共享功能进行通信，这两种协议始终通过端口 443 使用 HTTPS。 Azure 文件同步不通过 HTTP 发送未加密的请求。

Azure 存储帐户包含一个用于要求在传输过程中加密的开关，该开关在默认情况下为启用状态。 即使在存储帐户级别上禁用了此开关，也就是说可能会存在与 Azure 文件共享之间的未加密连接，Azure 文件同步仍将仅使用加密通道来访问文件共享。

为存储帐户禁用传输中加密的主要原因是为了支持必须在更低版本的操作系统（例如，Windows Server 2008 R2 或更低版本的 Linux 发行版）上运行且直接与 Azure 文件共享通信的旧版应用程序。 如果旧版应用程序与文件共享的 Windows Server 缓存进行通信，切换此设置将不起作用。

强烈建议确保启用了传输中数据的加密。

有关传输中加密的详细信息，请参阅要求在 Azure 存储中进行安全传输。

Azure 文件共享静态加密

使用 Azure 存储服务加密 (SSE) 对存储在 Azure 文件存储中的所有数据进行静态加密。 存储服务加密的工作方式类似于 Windows 上的 BitLocker：在文件系统级别下对数据进行加密。 由于数据在 Azure 文件共享的文件系统下加密，因此，在将数据编码到磁盘时，无需访问客户端上的基础密钥即可读取或写入 Azure 文件共享。 静态加密同时适用于 SMB 和 NFS 协议。

默认情况下，Azure 文件存储中存储的数据使用 Microsoft 管理的密钥进行加密。 使用 Microsoft 托管密钥，Azure 保存用于加密/解密数据的密钥，并负责定期轮换这些密钥。 你还选择管理你自己的密钥，这让你能够控制密钥轮换过程。 如果你选择使用客户管理的密钥来加密你的文件共享，则 Azure 文件存储可访问你的密钥来执行来自你的客户端的读取和写入请求。 通过客户管理的密钥，你可随时撤销此授权，但撤销意味着将无法再通过 SMB 或 FileREST API 访问你的 Azure 文件共享。

Azure 文件存储预其他 Azure 存储服务（例如 Azure Blob 存储）使用相同的机密方案。 要详细了解 Azure 存储服务加密 (SSE)，请参阅针对静态数据的 Azure 存储加密。

存储层

Azure 文件存储提供两个不同的存储层：SSD（固态磁盘）和 HDD（硬盘驱动器），使你能够根据方案的性能和价格要求定制共享：

• SSD（高级）：对于大多数 IO 操作和大多数 IO 密集型工作负荷，SSD 文件共享可以提供稳定的高性能和 10 毫秒以下的低延迟。 SSD 文件共享适合于各种各样的工作负荷，例如数据库、网站托管和开发环境。 SSD 文件共享可与服务器消息块 (SMB) 和网络文件系统 (NFS) 协议结合使用。 SSD 文件共享在预配的 v1 计费模型中可用。 SSD 文件共享提供比 HDD 文件共享更高的可用性 SLA（请参阅“Azure 文件存储高级层”）。

• HDD（标准）：HDD 文件共享为通用文件共享提供了一种经济高效的存储选项。 HDD 文件共享可用于 即用即付计费模型。

为工作负载选择介质层时，请考虑性能和使用要求。 如果你的工作负荷要求延迟不超过 10 毫秒，或者你在本地使用 SSD 存储介质，则 SSD 文件共享层可能是最合适的。 如果低延迟不那么令人担忧，例如从 Azure 在本地安装团队共享或使用 Azure 文件同步在本地缓存，则从成本角度来看，HDD 文件共享可能更合适。

在存储帐户中创建文件共享后，你无法直接将其移到其他介质层。 例如，要将 HDD 文件共享移到 SSD 介质层，你必须创建新的 SSD 文件共享，并将数据从原始共享复制到 FileStorage 帐户中的新文件共享。 建议在 Azure 文件共享之间使用 AzCopy 来复制数据，但你也可使用工具，例如适合 Windows 的 robocopy，或者适合 macOS 和 Linux 的 rsync。

有关详细信息，请参阅了解 Azure 文件存储计费。

Azure 文件同步区域可用性

有关区域可用性，请参阅可用产品（按区域）。

冗余

为了在 Azure 文件共享中保护数据以防数据丢失或损坏，Azure 文件存储会在写入每个文件时存储该文件的多个副本。 根据你的需求，可以选择不同程度的冗余。 Azure 文件存储目前支持以下数据冗余选项：

• 本地冗余存储 (LRS) ：使用 LRS 时，每个文件在 Azure 存储群集中存储三次。 这可以防止由于硬件故障（例如磁盘驱动器损坏）而导致数据丢失。 但如果数据中心内发生火灾或洪水等灾难，则使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。
• 区域冗余存储 (ZRS)：使用 ZRS，每个文件会存储三个副本。 但这些副本以物理方式隔离在不同 Azure 可用性区域的三个不同的存储群集中。 可用性区域是 Azure 区域中独特的物理位置。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源、冷却和网络。 在将副本写入所有三个可用性区域的存储群集前，不允许将其写入存储。
• 异地冗余存储 (GRS)：使用 GRS 时，你会拥有两个区域，即一个主要区域和一个次要区域。 文件在主要区域中的 Azure 存储群集中存储三次。 写入将异步复制到 Azure 定义的次要区域。 GRS 提供分布在两个 Azure 区域之间的六个数据副本。 如果由于自然灾害或其他类似事件导致重大灾难（如某个 Azure 区域永久丢失），Azure 会执行故障转移。 在这种情况下，次要区域将成为主要区域，以满足所有操作需求。 由于主要区域和次要区域之间的复制是异步的，因此，在发生重大灾难时，尚未复制到次要区域的数据将会丢失。 还可以执行异地冗余存储帐户的手动故障转移。
• 异地区域冗余存储 (GZRS)：可以将 GZRS 视为具有异地冗余的 ZRS。 使用 GZRS，文件在主要区域的三个不同存储群集中存储三次。 所有写入都将异步复制到 Microsoft 定义的次要区域。 GZRS 的故障转移过程的工作原理与 GRS 相同。

不超过 5 TiB 的标准 Azure 文件共享支持全部 4 种冗余类型。 大于 5 TiB 的标准文件共享仅支持 LRS 和 ZRS。 高级 Azure 文件共享仅支持 LRS 和 ZRS。

常规用途版本 2 (GPv2) 存储帐户提供了 Azure 文件存储不支持的另外两个冗余选项：读取可访问的异地冗余存储 (RA-GRS) 和读取可访问的异地区域冗余存储 (RA-GZRS)。 可以在存储帐户中使用这些选项集预配 Azure 文件共享，但 Azure 文件存储不支持从次要区域读取。 部署到 RA-GRS 或 RA-GZRS 存储帐户中的 Azure 文件共享分别按 GRS 或 GZRS 计费。

迁移

如果已有 Windows 文件服务器 2012R2 或更新版本，可以直接就地安装 Azure 文件同步，而无需将数据转移到新服务器。 如果计划在采用 Azure 文件同步的过程中迁移到新的 Windows 文件服务器，或者数据目前位于网络附加存储 (NAS) 上，则可以使用几种可能的迁移方法将 Azure 文件同步用于此数据。 应选择哪种迁移方法取决于数据当前所在的位置。

有关详细指导，请参阅 Azure 文件同步和 Azure 文件共享迁移概述文章。

防病毒

由于防病毒通过扫描文件中的已知恶意代码进行工作，因此防病毒产品可能导致重新调用分层文件，结果就是出口费用过高。 分层文件已设置安全 Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS。建议咨询软件供应商，了解如何配置其解决方案以跳过读取已设置此属性的文件（许多解决方案会自动执行此操作）。

Microsoft 的内部防病毒解决方案 Windows Defender 和 System Center Endpoint Protection (SCEP) 都会自动跳过读取设有此属性的文件。 我们已对这两个解决方案进行了测试并发现了一个小问题：向现有的同步组添加服务器时，在新服务器上会重新调用（下载）小于 800 字节的文件。 这些文件将保留在新服务器上，不会进行分层，因为它们不满足分层大小要求 (>64kb)。

备份

如果启用了云分层，则不应使用直接备份服务器终结点或其所在的 VM 的解决方案。 云分层会导致在服务器终结点上仅存储数据的一个子集，而完整的数据集则驻留在 Azure 文件共享中。 根据所使用的备份解决方案，系统会跳过分层文件且不对其进行备份（因为它们设置了 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 属性），或者会将它们回调到磁盘，导致出口费用过高。 建议使用云备份解决方案直接备份 Azure 文件共享。 有关详细信息，请参阅关于 Azure 文件共享备份，或与备份提供商联系，看其是否支持备份 Azure 文件共享。

如果首选使用本地备份解决方案，则应在已禁用云分层的同步组中的服务器上执行备份，并确保没有分层文件。 执行还原时，使用卷级别或文件级还原选项。 使用文件级别还原选项还原的文件将同步到同步组中的所有终结点，现有文件将被替换为从备份还原的版本。 卷级别的还原不会替换 Azure 文件共享或其他服务器终结点中的较新文件版本。

数据分类

如果已安装数据分类软件，启用云分层可能会由于以下两个原因而导致成本增大：

1. 启用云分层后，最热的文件将在本地缓存，最冷的文件将分层到云中的 Azure 文件共享中。 如果数据分类定期扫描文件共享中的所有文件，则每当扫描时，都必须撤回已分层到云中的文件。

2. 如果数据分类软件使用某个文件的数据流中的元数据，则必须完整撤回该文件，才能使软件看到分类。

撤回次数以及撤回数据量的增大可能导致成本增大。

Azure 文件同步代理更新策略

Azure 文件同步代理将定期更新，以便添加新功能和解决问题。 建议在新版本发布时更新 Azure 文件同步代理。

主要与次要代理版本

• 主要代理版本通常包含新的功能，并且版本号的第一个组成部分会递增。 例如：17.0.0.0
• 次要代理版本也称为“修补”，其发布频率高于主要版本。 它们通常包含 bug 修复和小幅的改进，但不包含新功能。 例如：17.2.0.0

升级路径

可以通过五种经过批准和测试的方法来安装 Azure 文件同步代理更新。

1. 使用 Azure 文件同步代理自动升级功能来安装代理更新。 Azure 文件同步代理将自动升级。 可以选择在最新代理版本发布时安装最新代理版本，或在当前安装的代理即将过期时安装更新。 若要了解详细信息，请参阅自动的代理生命周期管理。
2. 将 Microsoft 更新配置为自动下载并安装代理更新。 我们建议安装每项 Azure 文件同步更新，确保能够访问服务器代理的最新修补程序。 Microsoft 更新通过自动下载并安装更新，使此过程顺畅完成。
3. 使用 AfsUpdater.exe 下载并安装代理更新。 AfsUpdater.exe 位于代理安装目录中。 双击可执行文件可下载并安装代理更新。 可能需要重启服务器，具体取决于发布版本。
4. 使用 Microsoft 更新修补文件或 .msp 可执行文件修补现有的 Azure 文件同步代理。 可以从 Microsoft 更新目录下载最新的 Azure 文件同步更新包。 运行 .msp 可执行文件将会升级 Azure 文件同步安装，所用的方法与 Microsoft 更新自动使用的方法相同。 应用 Microsoft 更新修补程序会就地升级 Azure 文件同步安装。
5. 从 Microsoft 下载中心下载最新的 Azure 文件同步代理安装程序。 若要升级现有的 Azure 文件同步代理安装，请卸载旧版本，然后使用下载的安装程序安装最新版本。 服务器注册、同步组和其他任何设置由 Azure 文件同步安装程序维护。

自动代理生命周期管理

Azure 文件同步代理将自动升级。 有两种模式可供选择，你可以指定一个维护时段，将在该维护时段内在服务器上尝试升级。 此功能提供一个护栏，可防止代理过期，或允许无障碍，并保持最新设置，旨在帮助你完成代理生命周期管理。

1. 默认设置将尝试防止代理过期。 在公布了代理的到期日期后，代理将在 21 天内尝试自行升级。 在过期之前的 21 天内，一周内尝试一次升级，也会在选定的维护时段内尝试升级。 即时采用了该选项，也需要定期获取 Microsoft 更新补丁。
2. 或者，你可以选择让代理在新代理版本可用时自行自动升级（目前不适用于群集服务器）。 此更新将在选定的维护时段内进行，并且一旦新功能和改进正式发布，你服务器便可以立即获得。 这是一种无忧设置，也是建议的设置，将为你的服务器提供主要代理版本以及定期更新补丁。 每个发布的代理都处于 GA 质量。 如果选择此选项，Microsoft 将向你发布最新的代理版本以进行外部测试。 群集服务器不包括在内。 在外部测试完成后，代理将在 Microsoft 更新和Microsoft 下载中心中提供。

更改自动升级设置

以下说明介绍了在完成安装程序后如何更改设置（如果需要进行更改）。

打开 PowerShell 控制台，导航到在其中安装了同步代理的目录，然后导入服务器 cmdlet。 默认情况下，如下所示：

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

可以运行 Get-StorageSyncAgentAutoUpdatePolicy 来检查当前策略设置并确定是否要对其进行更改。

要将当前策略设置更改为延迟更新跟踪，可以使用：

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

要将当前策略设置更改为立即更新跟踪，可以使用：

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

代理生命周期和变更管理保证

Azure 文件同步是一种云服务，它将持续引入新功能和改进。 这意味着，特定的 Azure 文件同步代理版本只在有限的时间内受到支持。 为了简化部署，以下规则可保证用户在变更管理过程中获得足够的时间来适应代理更新/升级并收到相应的通知：

• 至少支持主要代理版本六个月（从初始版本发布日期算起）。
• 我们保证至少提供三个月的缓冲期来支持不同的主要代理版本。
• 在代理过期之前的至少三个月，我们会在已注册的服务器中使用代理即将过期消息来发出警告。 可以在存储同步服务的“已注册服务器”部分下检查已注册的服务器是否在使用旧版代理。
• 次要代理版本的生存期受限于相关的主要版本。 例如，当代理版本 17.0.0.0 即将过期时，代理版本 17.*.*.* 将一起过期。

后续步骤

• 考虑防火墙和代理设置
• 部署 Azure 文件
• 部署 Azure 文件同步
• 监视 Azure 文件同步