规划 Azure 文件同步部署

文件存储在云中的 Azure 文件共享中。 可以通过以下两种方式使用 Azure 文件共享。 所选择的部署方式决定了规划部署时需要考虑的事项。

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

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

管理概念

在 Azure 中，资源是在 Azure 订阅和资源组中创建和配置的可管理项。 资源由资源提供程序提供，后者是提供特定类型资源的管理服务。 若要部署 Azure 文件同步，需要使用两个关键资源：

• 资源提供程序提供的存储帐户Microsoft.Storage。 存储帐户是表示存储、IOPS 和吞吐量共享池的顶级资源，你可以根据存储帐户类型在其中部署经典文件共享或其他存储资源。 部署到存储帐户中的所有存储资源共享应用于该存储帐户的限制。 经典文件共享同时支持 SMB 和 NFS 文件共享协议，但你只能将 Azure 文件同步与 SMB 文件共享一起使用。

  注意

  Azure 文件存储还支持通过 Microsoft.FileShares 资源提供程序将文件共享部署为 Azure 顶级资源。 但是，由于这些文件共享目前仅支持 NFS 协议，因此 Azure 文件同步不支持它们。

• 存储同步服务，由 Microsoft.StorageSync 资源提供程序提供。 存储同步服务充当管理容器，使你可以注册 Windows 文件服务器并定义 Azure 文件同步的同步关系。

Azure 文件共享管理相关概念

经典文件共享或部署在存储帐户中的文件共享是为 Azure 文件存储部署文件共享的传统方法。 它们支持 Azure 文件存储支持的所有关键功能，包括每个区域中的 SMB 和 NFS、SSD 和 HDD 介质层、每个冗余类型。 若要详细了解经典文件共享，请参阅经典文件共享。

有两种用于经典文件共享部署的主要存储帐户：

• 预配的存储帐户：使用 FileStorage 存储帐户类型区分预配的存储帐户。 预配的存储帐户允许在基于 SSD 或 HDD 的硬件上部署预配的经典文件共享。 预配的存储帐户只能用于存储经典文件共享，不能用于存储其他存储资源，例如 Blob 容器、队列和表。 建议对所有新的经典文件共享部署使用预配的存储帐户。
• 即用即付存储帐户：即用即付存储帐户通过 StorageV2 存储帐户类型来区分。 使用即用即付存储帐户，可以在基于 HDD 的硬件上部署即用即付文件共享。 即用即付存储帐户可用于存储经典文件共享和其他存储资源，例如 Blob 容器、队列或表。

Azure 文件同步管理相关概念

在存储同步服务中，你可以部署：

• 已注册的服务器，表示与存储同步服务具有信任关系的 Windows 文件服务器。 已注册的服务器可以是单个服务器或群集，但是一个服务器/群集一次只能向一个存储同步服务注册。

• 同步组，定义云终结点与一个或多个服务器终结点之间的同步关系。 同步组中的终结点保持彼此同步。 例如，如果想使用 Azure 文件同步管理两组不同文件，需创建两个同步组并在每个同步组中添加不同的终结点。

  • 云终结点，表示 Azure 文件共享。
  • 服务器终结点，表示已同步到 Azure 文件存储的已注册服务器上的路径。 已注册的服务器可以包含多个服务器终结点，前提是它们的命名空间不重叠。

所需存储同步服务的数量

存储同步服务是 Azure 文件同步的根 Azure 资源管理器资源。它管理 Windows Server 安装与 Azure 文件共享之间的同步关系。 每个存储同步服务可以包含多个同步组和多个已注册的服务器。

每个 Windows Server 实例只能向一个存储同步服务注册。 注册后，服务器可以通过资源管理器主体在服务器上创建服务器终结点，从而在该存储同步服务中加入多个同步组。

设计 Azure 文件同步拓扑时，请确保在存储同步服务级别清楚地隔离数据。 例如，如果企业需要为两个不同的业务部门提供单独的 Azure 文件同步环境，并且这两个部门之间需要严格的数据隔离，则应为每个部门创建专用的存储同步服务。 避免将两个业务部门的同步组放在同一个存储同步服务中，因为此配置无法确保完全隔离。

有关在 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 文件共享，而不是一个。 使用此方法，可以使每个文件共享的文件数和文件夹数在服务器之间保持平衡。 还可以拆分本地共享并在更多的本地服务器上同步，从而增加每个额外服务器再同步 30 个 Azure 文件共享的能力。

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

创建映射表

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

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

下载命名空间映射模板。

Windows 文件服务器的注意事项

若要在 Windows Server 上启用同步功能，需要安装可下载的 Azure 文件同步代理。 Azure 文件同步代理提供两个主要组件：

• FileSyncSvc.exe，后台 Windows 服务，负责监视服务器终结点的更改并启动同步会话
• StorageSync.sys，文件系统筛选器，可实现云分层和快速灾难恢复

操作系统要求

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

我们建议使用 Windows 更新提供的最新更新，将用于 Azure 文件同步的所有服务器保持最新。

最低系统资源要求

Azure 文件同步需要一台物理服务器或虚拟服务器，且该服务器需具备以下所有属性：

• 至少一个 CPU。
• 最低 2 GiB 内存。 如果服务器在启用了动态内存的虚拟机中运行，请为虚拟机配置至少 2,048 MiB 内存。
• 使用 NTFS 文件系统进行了格式化的本地附加卷。

对于大多数生产工作负载，我们不建议仅使用最低要求来配置 Azure 文件同步中的同步服务器。

推荐使用的系统要求

与任何服务器功能或应用程序一样，部署的规模决定了 Azure 文件同步的系统资源要求。服务器上的部署规模越大，所需的系统资源就越多。

对于 Azure 文件同步，服务器终结点上的对象数和数据集上的流失数决定了规模。 单个服务器可以在多个同步组中拥有服务器终结点。 下表中列出的对象数量，包含了服务器所附加的完整命名空间。

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

出于性能原因，命名空间数据存储在内存中。 由于此配置，更大的命名空间需要更多内存来维持良好的性能。 更多的流失需要更多的 CPU 来处理。

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

*不建议同步超过 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 文件系统功能的互操作性状态：

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

本地磁盘上的可用空间

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

使用 Azure 文件同步时，需要考虑以下项会在本地磁盘上占用空间：

• 如果启用云分层：

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

• 如果禁用云分层：

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

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

• NTFS 为每个分层文件分配一个群集大小：

  100 万个文件 * 4 KiB 群集大小 = 4,000,000 KiB (4 GiB)

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

• 同步元数据的每个项都占用一个群集大小：

  （100 万个文件 + 10 万个目录）* 4 KiB 群集大小 = 4,400,000 KiB (4.4 GiB)

• Azure 文件同步热存储的每个文件占用 1.1 KiB：

  100 万个文件 * 1.1 KiB = 1,100,000 KiB (1.1 GiB)

• 卷可用空间策略为 20%：

  1000 GiB * 0.2 = 200 GiB

在这种情况下，对于此命名空间，Azure 文件同步大约需要 209,500,000 KiB (209.5 GiB) 空间。 将此数量添加到你认为此磁盘可能需要的任何可用空间。

故障转移群集

Azure 文件同步支持“通用文件服务器”部署选项的 Windows Server 故障转移群集。 有关如何在故障转移集群上配置“通用文件服务器”角色的详细信息，请参阅部署双节点群集文件服务器。

Azure 文件同步支持的唯一方案是具有群集磁盘的 Windows Server 故障转移群集。 故障转移群集在横向扩展文件服务器、群集共享卷 (CSV) 或本地磁盘上不受支持。

若要使同步正常工作，必须在故障转移群集中的每个节点上安装 Azure 文件同步代理。

重复数据删除

Windows Server 2025、Windows Server 2022、Windows Server 2019 和 Windows Server 2016

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

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

在某些安装了数据重复删除的情况下，触发重复数据删除垃圾回收后，可用卷空间可能会超过预期增加。 以下示例介绍卷空间的工作原理：

1. 云分层的可用空间策略设置为 20%。
2. 当可用空间不足时（假设为 19%），Azure 文件同步会收到通知。
3. 分层确定需要释放 1% 的空间，但你想要额外释放 5%，因此你会分层达到 25%（例如 30 GiB）。
4. 文件会分层，直到达到 30 GiB。
5. 作为与数据重复删除的互操作的一部分，Azure 文件同步会在分层会话结束时启动垃圾回收。

卷节省仅适用于服务器。 Azure 文件共享中的数据不会重复删除。

Windows Server 2012 R2

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

说明

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

• 如果在启用云分层后在卷上启用数据重复删除，则初始重复数据删除优化作业会对卷上尚未分层的文件进行优化。 此作业对云分层有以下影响：

  • 可用空间策略继续根据卷上的可用空间使用热度地图对文件进行分层。
  • 日期策略会跳过对可能符合分层条件的文件的分层，因为重复数据删除优化作业正在访问这些文件。

• 对于正在进行的重复数据删除优化作业，如果文件尚未分层，则数据重复删除 MinimumFileAgeDays 设置会使用数据策略延迟云分层。

  • 例如，如果 MinimumFileAgeDays 设置是 7 天，而云分层的日期策略是 30 天，则日期策略会在 37 天后对文件进行分层。
  • Azure 文件同步对文件进行分层后，重复数据删除优化作业会跳过该文件。

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

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

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

分布式文件系统

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

DFS-N

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

DFS-R

因为 DFS-R 和 Azure 文件同步都是复制解决方案，所以在大多数情况下建议将 DFS-R 替换为 Azure 文件同步。 但在以下场景中，应同时使用 DFS-R 和 Azure 文件同步：

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

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

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

有关详细信息，请参阅 DFS 命名空间和 DFS 复制概述。

Sysprep

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

Windows Search

如果在服务器终结点上启用了云分层，则 Windows 搜索会跳过已分层的文件，并且不会对其进行索引。 Windows 搜索会对未分层的文件正确进行索引。

Windows 客户端会在搜索文件共享时导致撤回（如果在客户端计算机上启用了“始终搜索文件名和内容”设置）。 默认情况下，此设置处于禁用状态。

其他 HSM 解决方案

不应将任何其他分层存储管理 (HSM) 解决方案与 Azure 文件同步一起使用。

性能和可伸缩性

由于 Azure 文件同步代理在连接到 Azure 文件共享的 Windows Server 计算机上运行，因此有效的同步性能取决于基础结构中的以下因素：

• Windows Server 和基础磁盘配置
• 服务器与 Azure 存储之间的网络带宽
• 文件大小
• 数据集的总大小
• 数据集上的活动

Azure 文件同步在文件级别运行。 基于 Azure 文件同步的解决方案的性能特征更适合用每秒处理的对象（文件和目录）数来度量。

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

标识

注册服务器并创建云终结点的管理员必须是存储同步服务的管理角色 Azure 文件同步管理员、所有者或参与者的成员。 你可以在存储同步服务的 Azure 门户页面上的访问控制 (IAM) 下配置此角色。

分配 Azure 文件同步管理员角色时，请按照以下步骤确保最低权限。

1. 在“条件”选项卡下，选择“允许用户仅将所选角色分配给所选主体”（权限更少）。

2. 单击 选择角色和主体 ，然后在 Condition #1 下选择 添加操作。

3. 选择“ 创建角色分配”，然后单击“ 选择”。

4. 选择 “添加表达式”，然后选择“ 请求”。

5. 在“属性源”下，选择“角色定义 ID”在“属性”下，然后在“运算符”下选择“ForAnyOfAnyValues：GuidEquals”。

6. 选择 “添加角色”。 添加 读取者和数据访问、 存储文件数据特权参与者和 存储帐户参与者 角色，然后选择“ 保存”。

Azure 文件同步可处理基于 Active Directory 的标准标识，且只需要设置同步，而无需任何其他特殊设置。使用 Azure 文件同步时，一般情况下，大多数访问是通过 Azure 文件同步缓存服务器而不是通过 Azure 文件共享来完成的。 由于服务器终结点位于 Windows Server 上，且 Windows Server 支持 Active Directory 和 Windows 样式的 ACL，因此你只需确保已向存储同步服务注册的 Windows 文件服务器加入到域即可。 Azure 文件同步将 ACL 存储在 Azure 文件共享中的文件上，并将这些 ACL 复制到所有服务器终结点。

即使直接对 Azure 文件共享所做的更改需要更长的时间才能同步到同步组中的服务器终结点，你可能还想确保自己能够在云中直接对文件共享强制实施 Active Directory 权限。 如果要进行此配置，必须将存储帐户以“域加入”的方式加入本地 Active Directory 实例中，就像 Windows 文件服务器的域加入方式一样。 若要详细了解如何将存储帐户“域加入”到客户拥有的 Active Directory 实例，请参阅 适用于 SMB 访问的 Azure 文件存储基于标识的身份验证概述。

网络

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

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

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

如果希望通过 SMB 与 Azure 文件共享通信，但端口 445 被阻止，可考虑通过 QUIC 使用 SMB。 此方法提供零配置 VPN，可通过 443 端口上的 QUIC 传输协议，实现对 Azure 文件共享的 SMB 访问。 尽管 Azure 文件存储不直接支持基于 QUIC 的 SMB，但可以使用 Azure 文件同步在 Windows Server 2022 Azure Edition VM 上创建 Azure 文件共享的轻量级缓存。若要详细了解此选项，请参阅通过 QUIC 使用 SMB。

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

加密

Azure 文件同步提供了三层加密：对 Windows Server 的静态存储进行加密、在 Azure 文件同步代理与 Azure 之间的传输中进行加密，以及在 Azure 文件共享中对数据进行静态加密。

Windows Server 静态加密

Windows Server 上加密数据的两种策略通常可与 Azure 文件同步配合使用：

• 文件系统之下的加密，这使得文件系统及其写入的所有数据均会被加密
• 文件格式本身内的加密

这些方法并不相互排斥。 你可以选择同时使用它们，因为加密的用途不同。

为了在文件系统下提供加密，Windows Server 提供了 BitLocker 收件箱。 BitLocker 对 Azure 文件同步完全透明。使用 BitLocker 之类的加密机制的主要原因是：

• 防止有人从本地数据中心窃取磁盘而造成数据被物理窃取
• 防止旁加载未经授权的操作系统以对你的数据进行未经授权的读取和写入

若要了解详细信息，请参阅 BitLocker 概述。

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

用于加密数据的另一个主要方法是在应用程序保存文件时加密文件的数据流。 一些应用程序可能会原生执行此任务，但通常情况下不会。

文件数据流加密的示例方法包括 Azure 信息保护、Azure 权限管理 (Azure RMS) 和 Active Directory 权限管理服务。 使用 Azure 信息保护或 Azure RMS 之类的加密机制的主要原因是防止有人将文件共享中的数据复制到其他位置（如 U 盘）或通过电子邮件发送给未授权人员，从而避免数据从文件共享中泄露。 当文件的数据流加密为文件格式的一部分时，将继续在 Azure 文件共享中对此文件进行加密。

Azure 文件同步不与 NTFS 加密文件系统或位于文件系统上方但文件数据流下方的合作伙伴加密解决方案互操作。

传输中加密

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

Azure 存储帐户包含一个用于要求在传输过程中加密的开关。 该开关在默认情况下为启用状态。 即使禁用存储帐户级别的开关，并且有可能建立与 Azure 文件共享的未加密连接，Azure 文件同步仍只会使用加密通道来访问文件共享。

禁用存储帐户的传输中加密的主要原因是支持与 Azure 文件共享直接通信的旧版应用程序。 此类应用程序必须运行在较旧的操作系统（如 Windows Server 2008 R2 或更旧的 Linux 发行版）上。 如果旧版应用程序连接到文件共享的 Windows Server 缓存，则更改此设置不会产生任何影响。

我们强烈建议你启用传输中的数据加密。 有关传输中加密的详细信息，请参阅要求进行安全传输以确保连接安全。

Azure 文件共享静态加密

使用 Azure 存储服务端加密 (SSE) 对存储在 Azure 文件存储中的所有数据进行静态加密。 SSE 的工作方式类似于 Windows 上的 BitLocker：在文件系统级别下对数据进行加密。

数据在 Azure 文件共享的文件系统下加密，因此，在将数据编码到磁盘时，无需访问客户端上的基础密钥即可读取或写入 Azure 文件共享。 静态加密同时适用于 SMB 和 NFS 协议。

默认情况下，Azure 文件存储中存储的数据使用 Microsoft 管理的密钥进行加密。 Microsoft 通过 Microsoft 管理的密钥保存用于加密和解密数据的密钥。 Microsoft 负责定期轮换这些密钥。

你还选择管理你自己的密钥，这让你能够控制密钥轮换过程。 如果你选择使用客户管理的密钥来加密你的文件共享，则 Azure 文件存储可访问你的密钥来执行来自你的客户端的读取和写入请求。 有了客户管理的密钥，你可以随时撤销此授权。 但是，如果没有此授权，Azure 文件共享将无法再通过 SMB 或 FileREST API 进行访问。

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

存储层

Azure 文件存储提供两个介质层存储：固态磁盘 (SSD) 和硬盘驱动器 (HDD)。 通过这些层，你可以根据方案的性能和价格要求定制共享：

• SSD（高级）：高级文件共享对 IO 密集型工作负载提供一致的高性能和低延迟，对于大多数 IO 操作，延迟不到 10 毫秒。 SSD 文件共享适合各种工作负载，例如数据库、网站托管和开发环境。

  可以将 SSD 文件共享与 SMB 和 NFS 协议一起使用。 SSD 文件共享在预配的 v2 和预配的 v1 计费模型中可用。 SSD 文件共享提供比 HDD 文件共享更高的可用性 SLA。

• HDD（标准）：HDD 文件共享为常规用途文件共享提供了经济高效的存储选项。 HDD 文件共享可用于预配的 v2 和即用即付计费模型，尽管我们建议对新的文件共享部署使用预配的 v2 模型。 有关 SLA 的信息，请参阅联机服务的 Azure SLA 页面。

为工作负载选择介质层时，请考虑性能和使用要求。 如果工作负荷需要一位数的延迟，或者在本地使用 SSD 存储介质，则 SSD 文件共享可能最合适。 如果低延迟并不算严重问题，则从成本的角度来看 HDD 文件共享可能更合适。 例如，对于从 Azure 装载在本地或通过 Azure 文件同步缓存的团队共享，低延迟可能不太算是个严重问题。

在存储帐户中创建文件共享后，无法直接将其移动到其他介质层。 例如，要将 HDD 文件共享移动到 SSD 介质层，必须创建新的 SSD 文件共享，并将原始共享中的数据复制到新的文件共享。

可以在了解 Azure 文件存储计费模型和了解和优化 Azure 文件共享性能中找到有关 SSD 和 HDD 介质层的详细信息。

Azure 文件同步区域可用性

有关区域可用性，请参阅产品可用性（按区域）并搜索“存储帐户”。

以下区域要求你先请求 Azure 存储的访问权限，然后才能使用 Azure 文件同步：

• 法国南部
• 南非西部
• 阿拉伯联合酋长国中部

若要针对这些区域来请求访问权限，请按照此文章中的过程进行操作。

冗余

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

• 本地冗余存储 (LRS)：使用本地冗余时，每个文件在 Azure 存储群集中存储三次。 此方法有助于防止硬件故障（例如磁盘驱动器错误）导致的数据丢失。 但如果数据中心内发生火灾或洪水等灾难，则使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。

• 区域冗余存储（ZRS）：使用区域冗余，存储每个文件的三个副本。 但这些副本以物理方式隔离在不同 Azure 可用性区域的三个不同的存储群集中。 可用性区域是 Azure 区域中独特的物理位置。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源以及散热和网络设备。 在将副本写入所有三个可用性区域的存储群集前，不允许将其写入存储。

• 异地冗余存储 (GRS)：使用异地冗余时，你会拥一个主要区域和一个次要区域。 文件在主要区域中的 Azure 存储群集中存储三次。 写入将异步复制到 Microsoft 定义的次要区域。

  异地冗余在两个 Azure 区域之间提供 6 个数据副本。 如果由于自然灾害或其他类似事件导致重大灾难（如某个 Azure 区域永久丢失），Microsoft 将会执行故障转移。 在这种情况下，次要区域将成为主要区域，以满足所有操作需求。

  由于主要区域和次要区域之间的复制是异步的，因此，在发生重大灾难时，尚未复制到次要区域的数据将会丢失。 还可以执行异地冗余存储帐户的手动故障转移。

• 异地区域冗余存储 (GZRS)：使用异地区域冗余时，文件在主要区域中的三个不同的存储群集中存储三次。 所有写入都将异步复制到 Microsoft 定义的次要区域。 异地区域冗余的故障转移过程与异地冗余的故障转移过程相同。

HDD 文件共享支持所有四种冗余类型。 SSD 文件共享仅支持 LRS 和 ZRS。

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

迁移

如果现有文件服务器运行的是 Windows Server 2012 R2 或更高版本，可以直接就地安装 Azure 文件同步。 无需将数据移到新服务器。

如果计划在采用 Azure 文件同步的过程中迁移到新的 Windows 文件服务器，或者数据目前位于 NAS 上，则可以使用几种可能的迁移方法将 Azure 文件同步用于此数据。 应选择哪种迁移方法取决于数据当前所在的位置。

有关详细指导，请参阅迁移到 SMB Azure 文件共享。

防病毒

由于防病毒通过扫描文件中的已知恶意代码进行工作，因此防病毒产品可能导致重新调用分层文件和流出费用过高。 分层文件设置了安全的 Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS。 我们建议你与软件供应商联系，了解如何配置其解决方案以跳过读取设置了此属性的文件。 许多人会自动这样做。

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

防病毒供应商可以通过 Microsoft 下载中心中的 Azure 文件同步防病毒兼容性测试套件来检查其产品与 Azure 文件同步的兼容性。

备份

如果启用了云分层，请勿使用直接备份服务器终结点或包含服务器终结点的 VM 的解决方案。

云分层会导致服务器终结点上仅存储部分数据。 完整数据集驻留在 Azure 文件共享中。 根据你使用的备份解决方案，分层文件会发生以下两种情况之一：

• 被跳过且不会备份，因为它们设置了 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 属性
• 被撤回到磁盘，从而导致高额流出费用

建议使用云备份解决方案直接备份 Azure 文件共享。 有关详细信息，请参阅关于 Azure 文件存储备份。 或者，询问备份提供商是否支持备份 Azure 文件共享。

如果首选使用本地备份解决方案，则应在已禁用云分层的同步组中的服务器上执行备份。 确保没有分层文件。

执行还原时，使用卷级别或文件级还原选项。 通过文件级还原选项还原的文件将同步到同步组中的所有终结点。 现有文件将替换为从备份还原的版本。 卷级别的还原不会替换 Azure 文件共享或其他服务器终结点中的较新文件版本。

数据分类

如果安装了数据分类软件，启用云分层会因为以下两个原因增加成本：

• 启用云分层后，最常用的文件会缓存在本地。 最不常用的文件会在云中的 Azure 文件共享中进行分层。 如果数据分类定期扫描文件共享中的所有文件，则每当扫描时，都必须撤回已分层到云中的文件。
• 如果数据分类软件使用某个文件的数据流中的元数据，则必须完整撤回该文件，软件才能检测分类。

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

Azure 文件同步代理更新策略

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

主要与次要代理版本

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

更新路径

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

• 使用 Azure 文件同步自动更新功能安装代理更新：Azure 文件同步代理会自动更新。 可以选择在最新代理版本发布时安装最新代理版本，或在当前安装的代理即将过期时安装更新。 有关详细信息，请参阅下一节代理生命周期的自动管理。
• 配置 Microsoft 更新以自动下载并安装代理更新：我们建议安装每个 Azure 文件同步更新，以确保你可以访问服务器代理的最新修补程序。 Microsoft 更新通过自动下载并安装更新，使此过程顺畅完成。
• 使用 AfsUpdater.exe 下载并安装代理更新： 文件位于代理安装目录中。AfsUpdater.exe 双击可执行文件可下载并安装代理更新。 可能需要重启服务器，具体取决于发布版本。
• 使用 Microsoft 更新修补程序文件或 .msp 可执行文件修补现有的 Azure 文件同步代理：你可以从 Microsoft 更新目录下载最新的 Azure 文件同步更新程序包。 运行 .msp 可执行文件会使用 Microsoft 更新自动使用的方法来更新你的 Azure 文件同步安装。 应用 Microsoft 更新补丁会就地更新 Azure 文件同步安装。
• 下载最新的 Azure 文件同步代理安装程序：你可以在 Microsoft 下载中心获取安装程序。 若要更新现有的 Azure 文件同步代理安装，请卸载旧版本，然后使用下载的安装程序安装最新版本。 卸载 Azure 文件同步代理时，会保留代理设置（例如服务器注册和服务器终结点）。

代理生命周期的自动管理

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

• 默认设置会尝试防止代理过期。 在公布的代理到期日期到来后，代理会在 21 天内尝试自行更新。 在到期之前的 21 天内，它会每周在选定的维护时段内尝试一次更新。 请注意，此选项并不能免除安装常规 Microsoft 更新补丁的需求。

• 你可以选择让代理在新版本发布后立即自动更新。 此功能目前不适用于群集服务器。

  此更新会在选定的维护时段内进行，使得你的服务器可以在新功能和改进正式发布时立即获得它们。 这是一种无忧设置，也是推荐的设置，它会为你的服务器提供主要代理版本和定期更新补丁。 每个发布的代理都处于 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 文件同步代理版本仅在有限的时间内受支持。 为了简化部署，以下规则可保证用户在变更管理过程中获得足够的时间来适应代理更新并收到相应的通知：

• 至少支持主要代理版本 12 个月（从初始版本发布日期算起）。
• 主要代理版本的支持期之间至少有 3 个月的重叠。
• 在代理过期之前的至少 3 个月，我们会在已注册的服务器中使用代理即将过期消息来发出警告。 你可以在存储同步服务的有关注册的服务器的部分中检查注册的服务器是否正在使用旧版本的代理。
• 次要代理版本的生存期受限于相关的主要版本。 例如，当代理版本 18.0.0.0 即将到期时，代理版本 18.*.*.* 会一起到期。

相关内容

• Azure 文件同步代理和防火墙设置
• 创建 SMB Azure 文件共享
• 部署 Azure 文件同步
• 监视 Azure 文件同步