规划 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 文件分享)进行更改,首先需要通过 Azure 文件同步更改检测作业来发现更改。 每 24 小时仅针对云终结点启动一次更改检测作业。 有关详细信息,请参阅 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 文件共享中直接进行的更改(在同步之外)。

提示

如果你不知道你有多少个文件和文件夹,请使用 JAM Software GmbH 提供的 TreeSize 工具来确认。

部署映射的结构化方法

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

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

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

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

    理论上,一个标准 Azure 文件共享可以让存储帐户可提供的最大性能达到饱和。 如果将多个共享放置在单个存储帐户中,会为这些共享创建一个 IOPS 和吞吐量共享池。 如果计划仅将 Azure 文件同步附加到这些文件共享,则将多个 Azure 文件共享分组到相同存储帐户中不会产生问题。 请查看 Azure 文件共享性能目标,深入了解相关指标。 这些限制不适用于高级存储,高级存储为每个共享显式预配并保证性能。

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

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

提示

考虑到这一点,通常需要将卷上的多个顶级文件夹分组到一个新的公用根目录中。 随后将这个新的根目录以及分组到其中的所有文件夹都同步到单个 Azure 文件共享。 此方法使你可以维持在每台服务器 30 个 Azure 文件共享同步的限制范围内。

在公用根下进行这种分组不会对数据访问产生影响。 你的 ACL 将保持原样。 只需要调整你在本地服务器文件夹上的任何共享路径(如 SMB 或 NFS 共享),现在你已将这些文件夹更改为公用根。 无其他更改。

重要

Azure 文件同步最重要的缩放矢量是需要同步的项目数(文件和文件夹)。 如需更多详细信息,请参阅 Azure 文件同步缩放目标

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

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

创建映射表

显示映射表的示例的关系图。下载以下文件以体验并使用此图像的内容。

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

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


Excel icon that sets the context for the download. 下载命名空间映射模板。

Windows 文件服务器注意事项

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

操作系统要求

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

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

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

重要

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

最低系统资源要求

Azure 文件同步需要使用服务器(物理或虚拟),服务器需配有至少一个 CPU 和至少 2 GiB 的内存。

重要

如果服务器要在启用了动态内存的虚拟机中运行,应至少为虚拟机配置 2048 MiB 的内存。

对于大多数生产工作负荷,不建议使用按最低要求配置的“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 文件同步规模目标

提示

命名空间的初始同步是一种密集型操作,建议在初始同步完成之前分配较多内存。 这不是必需的,但这样做有可能加快初始同步的速度。

通常,每日代码改动量占命名空间更改量的 0.5%。 如果代码改动量较大,应考虑添加更多 CPU。

  • 使用 NTFS 文件系统进行了格式化的本地附加卷。

评估 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 压缩 完全支持
稀疏文件 完全支持 稀疏文件会进行同步(不受阻),但作为完整文件同步到云。 如果在云中(或在其他服务器上)更改文件内容,则下载更改时,文件不再是稀疏文件。
备用数据流 (ADS) 保留但不同步 例如,由文件分类基础结构创建的分类标记就不会同步。 每个服务器终结点的文件上的现有分类标记都保留不变。

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

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

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

规划使用 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 分配。 因此,它不会显示在任何 UI 中。 3. 同步元数据的每个项都占用一个群集大小。 (100 万个文件 + 10 万个目录)* 4 KiB 群集大小 = 4,400,000 KiB (4.4 GiB) 4. Azure 文件同步热存储的每个文件占用 1.1 KiB。 100 万个文件 * 1.1 KiB = 1,100,000 KiB (1.1 GiB) 5. 卷可用空间策略为 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) 或本地磁盘上使用故障转移群集。

备注

必须在故障转移群集中的每个节点上安装 Azure 文件同步代理,才能正常进行同步。

重复数据删除

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

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

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

备注

若要支持在 Windows Server 2019 上对启用了云分层的卷执行重复数据删除,需要安装 Windows 更新 KB4520062 - 2019 年 10 月或之后的每月汇总更新,并且需要使用 12.0.0.0 版或更新版本的 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 2012 R2 的 Azure 文件同步代理并重新启动服务器。
    • 下载适用于新服务器操作系统版本(Windows Server 2016 或 Windows Server 2019)的 Azure 文件同步代理。
    • 安装 Azure 文件同步代理并重新启动服务器。

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

分布式文件系统 (DFS)

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

DFS 命名空间 (DFS-N) :Azure 文件同步在 DFS-N 服务器上完全受支持。 可以在一个或多个 DFS-N 成员上安装 Azure 文件同步代理,以在服务器终结点与云终结点之间同步数据。 有关详细信息,请参阅 DFS 命名空间概述

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 只读复制文件夹上配置服务器终结点。

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

Sysprep

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

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

其他分层存储管理 (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 文件同步,无需将存储帐户“域加入”到 Active Directory。这是一个可选步骤,可让 Azure 文件共享在用户直接装载 Azure 文件共享的情况下强制实施本地 ACL。

网络

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

根据组织的策略或独特的法规要求,与 Azure 的通信可能需要设置更严格的限制,因此 Azure 提供了多种网络配置机制。 根据你的要求,你可以:

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

重要

Azure 文件同步不支持 Internet 路由。 Azure 文件同步支持默认网络路由选项 - Microsoft 路由。

若要详细了解 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 文件同步服务将于 2020 年 8 月 1 日删除对 TLS1.0 和 1.1 的支持。 默认情况下,所有支持的 Azure 文件同步代理版本已使用 TLS 1.2。 如果在服务器上禁用了 TLS 1.2 或使用了代理,则可能会使用较早版本的 TLS。 如果使用了代理,建议检查代理配置。 2020/5/1 之后添加的 Azure 文件同步服务区域将仅支持 TLS 1.2,将于 2020 年 8 月 1 日删除现有区域中对 TLS1.0 和 1.1 的支持。 有关详细信息,请参阅故障排除指南

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 文件存储提供了四种不同的存储层(高级、事务优化、热和冷存储层),因此你能够根据方案的性能和价格要求定制共享:

  • Premium:高级文件共享由固态磁盘 (SSD) 提供支持;对于 IO 密集型工作负载,它们提供稳定的高性能和低延迟(大多数 IO 操作的延迟低至几毫秒)。 高级文件共享适合各种各样的工作负载,例如数据库、网站托管和开发环境。 高级文件共享既可用于服务器消息块 (SMB) 协议,也可用于网络文件系统 (NFS) 协议。
  • 事务优化:事务优化文件共享可实现事务繁重的工作负载,这些工作负荷不需要高级文件共享提供的延迟。 可在由硬盘驱动器 (HDD) 提供支持的标准存储硬件上使用事务优化文件共享。 虽然事务优化一直被称为“标准”层,但这指的是存储介质类型而不是层本身(热和冷存储层也是“标准”层,因为它们位于标准存储硬件上)。
  • Hot:热文件共享提供针对常规用途文件共享方案(如团队共享)优化的存储。 可在由 HDD 提供支持的标准存储硬件上使用热文件共享。
  • Cool:冷文件共享提供针对在线存档存储方案优化的经济高效的存储。 可在由 HDD 提供支持的标准存储硬件上使用冷文件共享。

高级文件共享是在 FileStorage 存储帐户中部署的,仅可在预配账单模型中使用。 有关高级文件共享的预配计费模型的详细信息,请参阅了解预配高级文件共享。 标准文件共享(包括事务优化、热和冷文件共享)部署在常规用途版本 2 (GPv2) 存储帐户类型中,以即用即付计费的形式提供。

为工作负载选择存储层时,请考虑你的性能和使用要求。 如果工作负载要求延迟低至个位数,或者你正在使用本地 SSD 存储媒体,则可能最适合使用高级层。 如果低延迟不太重要,例如在使用从 Azure 本地装载或通过 Azure 文件同步本地缓存的团队共享时,则从成本的角度来看,标准存储可能更加适合。

在存储帐户中创建文件共享后,无法将该共享移动到专用于其他存储帐户类型的层级。 例如,若要将事务优化文件共享移到高级层,必须在 FileStorage 存储帐户中创建一个新的文件共享,然后再将原始共享中的数据复制到 FileStorage 帐户中的这个新的文件共享。 建议在 Azure 文件共享之间使用 AzCopy 来复制数据,但你也可使用工具,例如适合 Windows 的 robocopy,或者适合 macOS 和 Linux 的 rsync

无需创建新的存储帐户和迁移数据,即可在标准层(事务优化、热和冷)之间移动 GPv2 存储帐户中部署的文件共享,但在更改层级时将产生事务成本。 在将共享从更热的冷移动到更冷的层时,共享中每个文件将产生更冷层的写入事务费用。 如果将文件共享从更冷的层移动到更热的层,则共享中每个文件将更冷层的读取事务费用。

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

区域可用性

具有 100 TiB 容量的标准文件共享存在一定限制。

  • 目前仅支持本地冗余存储 (LRS) 帐户。
  • 启用大型文件共享后,不能将存储帐户转换为异地冗余存储 (GRS) 帐户。
  • 启用大型文件共享后,不能禁用。

Azure 文件同步区域可用性

有关区域可用性,请参阅可用产品(按区域)

冗余

为了在 Azure 文件共享中保护数据以防数据丢失或损坏,所有 Azure 文件共享都在写入每个文件时存储了该文件的多个副本。 可以根据工作负载的要求选择额外的冗余度。 Azure 文件存储目前支持以下数据冗余选项:

  • 本地冗余存储 (LRS) :使用 LRS 时,每个文件在 Azure 存储群集中存储三次。 这可以防止由于硬件故障(例如磁盘驱动器损坏)而导致数据丢失。 但是,如果数据中心发生火灾或洪灾等灾难,使用 LRS 的存储帐户的所有副本可能会丢失或不可恢复。
  • 异地冗余存储 (GRS):使用 GRS 时,有两个区域,即一个主要区域和一个次要区域。 文件在主要区域中的 Azure 存储群集中存储三次。 写入将异步复制到 Azure 定义的次要区域。 GRS 提供分布在两个 Azure 区域之间的六个数据副本。 如果发生重大灾难,例如由于自然灾害或其他类似事件而导致 Azure 区域永久性丢失,Azure 将执行故障转移,次要区域将成为主要区域,为所有操作提供服务。 由于主要区域和次要区域之间的复制是异步的,因此,在发生重大灾难时,尚未复制到次要区域的数据将会丢失。 还可以执行异地冗余存储帐户的手动故障转移。

不超过 5 TiB 的标准 Azure 文件共享支持所有冗余类型。 大于 5 TiB 的标准文件共享仅支持 LRS。 高级 Azure 文件共享仅支持 LRS。

常规用途版本 2 (GPv2) 存储帐户提供 Azure 文件存储不支持的额外冗余选项:读取访问异地冗余存储,通常称为“RA-GRS”。 可以在存储帐户中使用这些选项集预配 Azure 文件共享,但 Azure 文件存储不支持从次要区域读取。 部署到读取访问异地冗余存储帐户中的 Azure 文件共享会按异地冗余存储计费。

重要

如果使用异地冗余存储,可以将存储手动故障转移到次要区域。 当使用 Azure 文件同步时,建议不要在未发生灾难的情况下执行此操作,因为这样会增加数据丢失的可能性。 如果发生了灾难且需要启动对存储的手动故障转移,需要向 Azure 开立支持事例,以使 Azure 文件同步能够继续使用辅助终结点进行同步。

迁移

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

请参阅 Azure 文件同步和 Azure 文件共享迁移概述一文,其中提供了有关方案的详细指南。

防病毒

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

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

备注

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

警告

如果需要对源服务器或目标服务器上运行的 Azure 文件同步代理使用 Robocopy/B,请升级到 Azure 文件同步代理版本 v12.0 或更高版本。 对版本低于 v12.0 的代理使用 Robocopy/B 会导致在复制期间损坏分层文件。

备注

祼机 (BMR) 还原可能会导致意外的结果且当前不受支持。

备注

如果使用 Azure 文件同步代理版本 9,启用了云分层的卷上现在支持 VSS 快照(包括“以前的版本”选项卡)。 但是,必须通过 PowerShell 实现以前版本的兼容性。 了解操作方法

数据分类

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

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

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

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

Azure 文件同步代理更新策略

Azure 文件同步代理将定期更新,以便添加新功能和解决问题。 建议配置 Microsoft 更新,以便在 Azure 文件同步代理更新发布时获得这些更新。

主要与次要代理版本

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

升级路径

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

  1. (首选)将 Microsoft 更新配置为自动下载并安装代理更新。
    我们始终建议安装每项 Azure 文件同步更新,确保能够访问服务器代理的最新修补程序。 Microsoft 更新会自动下载并安装这些更新,以无缝完成此过程。
  2. 使用 AfsUpdater.exe 下载并安装代理更新。
    AfsUpdater.exe 位于代理安装目录中。 双击可执行文件可下载并安装代理更新。
  3. 使用 Microsoft 更新修补程序文件或 .msp 可执行文件修补现有 Azure 文件同步代理。可以从 Microsoft 更新目录下载最新的 Azure 文件同步更新包。
    运行 .msp 可执行文件将会升级 Azure 文件同步安装,所用的方法与上述升级路径中 Microsoft 更新使用的自动方法相同。 应用 Microsoft 更新修补程序会就地升级 Azure 文件同步安装。
  4. Microsoft 下载中心下载最新的 Azure 文件同步代理安装程序。
    若要升级现有的 Azure 文件同步代理安装,请卸载旧版本,然后使用下载的安装程序安装最新版本。 服务器注册、同步组和其他任何设置由 Azure 文件同步安装程序维护。

自动代理生命周期管理

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

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

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

打开 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

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

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

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

备注

安装附带过期警告的代理版本时会显示警告,但安装会成功。 不支持且会阻止安装或连接已过期的代理版本。

后续步骤