规划 Azure 文件同步部署

这些文件存储在 Azure 文件共享中的云中。 可以通过以下两种方式使用 Azure 文件共享。 选择哪个部署选项会更改在规划部署时需要考虑的方面。

• 使用服务器消息块（SMB）协议直接装载 Azure 文件共享：由于 Azure 文件提供 SMB 访问权限，因此可以使用 Windows、macOS 和 Linux 中提供的标准 SMB 客户端在本地或云中装载 Azure 文件共享。 由于 Azure 文件共享无服务器，因此部署生产方案不需要管理文件服务器或网络连接存储（NAS）设备。 此选项意味着无需应用软件修补程序或交换物理磁盘。

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

管理概念

在 Azure 中，资源是在 Azure 订阅和资源组中创建和配置的可管理项。 资源由资源提供程序提供，后者是提供特定类型资源的管理服务。

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

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 内存的 VM。
• 使用 NTFS 文件系统格式化的本地附加卷。

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

推荐使用的系统要求

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

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

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

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

下表提供命名空间的大小和对典型常规用途文件共享的容量的转换，其中平均文件大小为 512 KiB。 如果文件大小较小，请考虑为相同容量量添加更多内存。 应根据命名空间的大小来配置内容容量。

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

评估 cmdlet

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

可以通过安装 Az PowerShell 模块来安装评估 cmdlet。 有关说明，请参阅 安装 Azure PowerShell。

Usage

可以通过执行系统检查、数据集检查或同时执行两者来调用评估工具。 若要执行系统和数据集检查，请执行以下作：

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

文件系统兼容性

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

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

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

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

本地磁盘上的可用空间

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

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

• 如果启用云分层：

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

• 如果禁用云分层：

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

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

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

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

  为了完全受益于云分层，建议使用较小的 NTFS 群集大小（小于 64 KiB），因为每个分层文件占用群集。 此外，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 故障转移群集。 Scale-Out 文件服务器、群集共享卷（CSV）或本地磁盘上不支持故障转移群集。

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

数据重复消除

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

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

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

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

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

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

Windows Server 2012 R2

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

Notes

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

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

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

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

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

• 如果安装了 Azure 文件同步代理的运行 Windows Server 2012 R2 的服务器升级到 Windows Server 2025、Windows Server 2022、Windows Server 2019 或 Windows Server 2016，则必须执行以下步骤以支持同一卷上的重复数据删除和云分层：

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

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

分布式文件系统

Azure 文件同步支持与 DFS 命名空间（DFS-N）和 DFS 复制（DFS-R）的互作性。

DFS-N

DFS-N 实现完全支持 Azure 文件同步。 可以在一个或多个文件服务器上安装 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 文件同步规模目标

Identity

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

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 实例的域的详细信息，请参阅 Azure 文件存储标识的身份验证概述，以便进行 SMB 访问。

网络

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。 此方法通过端口 443 通过 QUIC 传输协议提供对 Azure 文件共享的 SMB 访问的零配置 VPN。 尽管 Azure 文件存储不支持通过 QUIC 直接支持 SMB，但可以使用 Azure 文件同步在 Windows Server 2022 Azure Edition VM 上创建 Azure 文件共享的轻型缓存。若要了解有关此选项的详细信息，请参阅 QUIC 中的 SMB。

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

Encryption

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

Windows Server 静态加密

Windows Server 上加密数据的两种策略通常适用于 Azure 文件同步：

• 文件系统下的加密，使文件系统和写入到文件系统的所有数据都已加密
• 文件格式本身中的加密

这些方法不是相互排斥的。 可以选择将它们一起使用，因为加密的目的不同。

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

• 有人窃取磁盘，防止从本地数据中心物理外泄数据
• 防止旁加载未经授权的 OS 以对数据执行未经授权的读取和写入

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

与 BitLocker 类似的合作伙伴产品（因为它们位于 NTFS 卷下）应与 Azure 文件同步完全透明地工作。

用于加密数据的另一个主要方法是在应用程序保存文件时加密文件的数据流。 某些应用程序可能本机执行此任务，但它们通常不执行。

加密文件数据流的示例方法是 Azure 信息保护、Azure Rights Management（Azure RMS）和 Active Directory Rights Management Services。 使用加密机制（如 Azure 信息保护或 Azure RMS）的主要原因是防止将数据复制到备用位置（如闪存驱动器）或将其通过电子邮件发送给未经授权的人员从文件共享中泄露数据。 当文件的数据流作为文件格式的一部分进行加密时，此文件将继续在 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管理的密钥，Azure 保存用于加密和解密数据的密钥。 Azure 负责定期轮换这些密钥。

你还选择管理你自己的密钥，这让你能够控制密钥轮换过程。 如果你选择使用客户管理的密钥来加密你的文件共享，则 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 文件同步区域可用性

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

Redundancy

为了帮助在 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 文件共享分别作为异地冗余或异地区域冗余计费。

Migration

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

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

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

Antivirus

由于防病毒通过扫描已知恶意代码的文件来工作，防病毒产品可能会导致召回分层文件和高出口费用。 分层文件具有安全的 Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 集。 建议咨询软件供应商，了解如何配置其解决方案，以跳过读取已设置此属性的文件。 （许多自动执行此作。

Microsoft防病毒解决方案 Windows 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 Update 使用的相同方法更新 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 个月，通过即将to-be 过期的代理为已注册的服务器发出警告。 可以在存储同步服务中检查已注册的服务器是否使用旧版代理。
• 次要代理版本的生存期受限于相关的主要版本。 例如，当代理版本 18.0.0.0 设置为过期时，代理版本 18.*.*.* 都一起过期。

相关内容

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