您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

规划 Azure 文件同步部署Planning for an Azure File Sync deployment

介绍 Azure 文件同步的访谈和演示 - 单击即可播放!Interview and demo introducing Azure File Sync - click to play!

Azure 文件同步是一项服务,可用于在本地 Windows Server 或云 VM 上缓存多个 Azure 文件共享。Azure File Sync is a service that allows you to cache a number of Azure file shares on an on-premises Windows Server or cloud VM.

本文介绍 Azure 文件同步的相关概念和功能。This article introduces you to Azure File Sync concepts and features. 在对 Azure 文件同步有了一定了解后,可参照 Azure 文件同步部署指南,试用此服务。Once you are familiar with Azure File Sync, consider following the Azure File Sync deployment guide to try out this service.

文件将存储在云中的 Azure 文件共享中。The files will be stored in the cloud in Azure file shares. 可以通过两种方式使用 Azure 文件共享:直接装载这些无服务器 Azure 文件共享 (SMB),或使用 Azure 文件同步功能在本地缓存 Azure 文件共享。所选择的部署方式决定了规划部署时需要考虑的事项。Azure file shares can be used in two ways: by directly mounting these serverless Azure file shares (SMB) or by caching Azure file shares on-premises using Azure File Sync. Which deployment option you choose changes the aspects you need to consider as you plan for your deployment.

  • 直接装载 Azure 文件共享 :由于 Azure 文件存储提供 SMB 访问权限,可以使用 Windows、macOS 和 Linux 中提供的标准 SMB 客户端在本地或在云中装载 Azure 文件共享。Direct mount of an Azure file share : Since Azure Files provides SMB access, you can mount Azure file shares on-premises or in the cloud using the standard SMB client available in Windows, macOS, and Linux. 由于 Azure 文件共享是无服务器式的,因此在部署生产方案时不需要管理文件服务器或 NAS 设备。Because Azure file shares are serverless, deploying for production scenarios does not require managing a file server or NAS device. 这意味着无需应用软件修补程序或换出物理磁盘。This means you don't have to apply software patches or swap out physical disks.

  • 使用 Azure 文件同步在本地缓存 Azure 文件共享 :借助 Azure 文件同步,可以在 Azure 文件存储中集中管理组织的文件共享,同时又能保留本地文件服务器的灵活性、性能和兼容性。Cache Azure file share on-premises with Azure File Sync : Azure File Sync enables you to centralize your organization's file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server. Azure 文件同步可将本地(或云中的)Windows Server 转换为 Azure 文件共享的快速缓存。Azure File Sync transforms an on-premises (or cloud) Windows Server into a quick cache of your Azure file share.

管理概念Management concepts

Azure 文件同步部署有三个基本管理对象:An Azure File Sync deployment has three fundamental management objects:

  • Azure 文件共享 :Azure 文件共享是一种无服务器云文件共享功能,它提供具有“Azure 文件同步”同步关系的云终结点。Azure file share : An Azure file share is a serverless cloud file share, which provides the cloud endpoint of an Azure File Sync sync relationship. Azure 文件共享中的文件可以直接通过 SMB 或 FileREST 协议进行访问,但在将 Azure 文件共享与 Azure 文件同步一起使用时,建议通过 Windows Server 缓存来访问文件。这是因为 Azure 文件存储目前缺少一种 Windows Server 所具有的那种高效的更改检测机制,如果直接对 Azure 文件共享进行更改,需要经过一段时间之后才能传播回服务器终结点。Files in an Azure file share can be accessed directly with SMB or the FileREST protocol, although we encourage you to primarily access the files through the Windows Server cache when the Azure file share is being used with Azure File Sync. This is because Azure Files today lacks an efficient change detection mechanism like Windows Server has, so changes to the Azure file share directly will take time to propagate back to the server endpoints.
  • 服务器终结点 :与 Azure 文件共享进行同步的 Windows Server 上的路径。Server endpoint : The path on the Windows Server that is being synced to an Azure file share. 它可以是某个卷上的特定文件夹,也可以是卷的根目录。This can be a specific folder on a volume or the root of the volume. 如果命名空间不重叠,多个服务器终结点可存在于同一个卷。Multiple server endpoints can exist on the same volume if their namespaces do not overlap.
  • 同步组 :用于定义 云终结点 或 Azure 文件共享与服务器终结点之间的同步关系的对象。Sync group : The object that defines the sync relationship between a cloud endpoint , or Azure file share, and a server endpoint. 同步组中的终结点保持彼此同步。Endpoints within a sync group are kept in sync with each other. 例如,如果想使用 Azure 文件同步管理两组不同文件,需创建两个同步组并在每个同步组中添加不同的终结点。If for example, you have two distinct sets of files that you want to manage with Azure File Sync, you would create two sync groups and add different endpoints to each sync group.

Azure 文件共享管理相关概念Azure file share management concepts

Azure 文件共享将部署到存储帐户。存储帐户是代表存储共享池的顶级对象。 Azure file shares are deployed into storage accounts, which are top-level objects that represent a shared pool of storage. 此存储池可用于部署多个文件共享和其他存储资源,例如 Blob 容器、队列或表。This pool of storage can be used to deploy multiple file shares, as well as other storage resources such as blob containers, queues, or tables. 部署到存储帐户中的所有存储资源共享应用于该存储帐户的限制。All storage resources that are deployed into a storage account share the limits that apply to that storage account. 若要查看存储帐户的当前限制,请参阅 Azure 文件存储的可伸缩性和性能目标To see the current limits for a storage account, see Azure Files scalability and performance targets.

对于 Azure 文件存储部署,将使用两种主要类型的存储帐户:There are two main types of storage accounts you will use for Azure Files deployments:

  • 常规用途版本 2 (GPv2) 存储帐户:使用 GPv2 存储帐户可以在标准的/基于硬盘(基于 HDD)的硬件上部署 Azure 文件共享。General purpose version 2 (GPv2) storage accounts: GPv2 storage accounts allow you to deploy Azure file shares on standard/hard disk-based (HDD-based) hardware. 除了存储 Azure 文件共享以外,GPv2 存储帐户还可以存储其他存储资源,例如 Blob 容器、队列或表。In addition to storing Azure file shares, GPv2 storage accounts can store other storage resources such as blob containers, queues, or tables.
  • FileStorage 存储帐户:使用 FileStorage 存储帐户可以在高级/基于固态磁盘(基于 SSD)的硬件上部署 Azure 文件共享。FileStorage storage accounts: FileStorage storage accounts allow you to deploy Azure file shares on premium/solid-state disk-based (SSD-based) hardware. FileStorage 帐户只能用于存储 Azure 文件共享;其他存储资源(Blob 容器、队列、表等)都不能部署在 FileStorage 帐户中。FileStorage accounts can only be used to store Azure file shares; no other storage resources (blob containers, queues, tables, etc.) can be deployed in a FileStorage account. 只有 FileStorage 帐户可同时部署 SMB 和 NFS 文件共享。Only FileStorage accounts can deploy both SMB and NFS file shares.

在 Azure 门户、PowerShell 或 CLI 中,可能会遇到一些其他的存储帐户类型。There are several other storage account types you may come across in the Azure portal, PowerShell, or CLI. 两种存储帐户类型(BlockBlobStorage 和 BlobStorage 存储帐户)不能包含 Azure 文件共享。Two storage account types, BlockBlobStorage and BlobStorage storage accounts, cannot contain Azure file shares. 可能会看到的其他两个存储帐户类型为常规用途版本 1 (GPv1) 和经典存储帐户,二者都可以包含 Azure 文件共享。The other two storage account types you may see are general purpose version 1 (GPv1) and classic storage accounts, both of which can contain Azure file shares. 尽管 GPv1 和经典存储帐户可以包含 Azure 文件共享,但 Azure 文件存储的大多数新功能只能在 GPv2 和 FileStorage 存储帐户中使用。Although GPv1 and classic storage accounts may contain Azure file shares, most new features of Azure Files are available only in GPv2 and FileStorage storage accounts. 因此,我们建议仅将 GPv2 和 FileStorage 存储帐户用于新部署,而升级 GPv1 和经典存储帐户的前提是它们已经存在于环境中。We therefore recommend to only use GPv2 and FileStorage storage accounts for new deployments, and to upgrade GPv1 and classic storage accounts if they already exist in your environment.

Azure 文件同步管理相关概念Azure File Sync management concepts

存储同步服务 中会部署同步组,这些组是顶层对象,用于注册要与 Azure 文件同步一起使用的服务器,并包含同步组关系。Sync groups are deployed into Storage Sync Services , which are top-level objects that register servers for use with Azure File Sync and contain the sync group relationships. 存储同步服务资源是存储帐户资源的对等物,可按类似方式部署到 Azure 资源组。The Storage Sync Service resource is a peer of the storage account resource, and can similarly be deployed to Azure resource groups. 存储同步服务可以创建同步组,这些组包含多个存储帐户和多个已注册的 Windows 服务器中的 Azure 文件共享。A Storage Sync Service can create sync groups that contain Azure file shares across multiple storage accounts and multiple registered Windows Servers.

需要先向存储同步服务注册 Windows Server,然后才能在存储同步服务中创建同步组。Before you can create a sync group in a Storage Sync Service, you must first register a Windows Server with the Storage Sync Service. 该步骤会创建一个 已注册的服务器 对象,表示服务器或群集与存储同步服务之间的信任关系。This creates a registered server object, which represents a trust relationship between your server or cluster and the Storage Sync Service. 若要注册存储同步服务,需要先在服务器上安装 Azure 文件同步代理。To register a Storage Sync Service, you must first install the Azure File Sync agent on the server. 一个服务器或群集一次只能注册一个存储同步服务。An individual server or cluster can be registered with only one Storage Sync Service at a time.

同步组包含一个云终结点或 Azure 文件共享,以及至少一个服务器终结点。A sync group contains one cloud endpoint, or Azure file share, and at least one server endpoint. 服务器终结点对象包含用于配置云分层功能的设置,该功能可实现 Azure 文件同步的缓存功能。为了与 Azure 文件共享进行同步,包含 Azure 文件共享的存储帐户必须与存储同步服务位于同一 Azure 区域。The server endpoint object contains the settings that configure the cloud tiering capability, which provides the caching capability of Azure File Sync. In order to sync with an Azure file share, the storage account containing the Azure file share must be in the same Azure region as the Storage Sync Service.

管理指南Management guidance

部署 Azure 文件同步时,建议执行以下操作:When deploying Azure File Sync, we recommend:

  • 部署的 Azure 文件共享与 Windows 文件共享的比例应为 1:1。Deploying Azure file shares 1:1 with Windows file shares. 通过使用服务器终结点对象,能够在具有同步关系的服务器端非常灵活地设置同步拓扑。The server endpoint object gives you a great degree of flexibility on how you set up the sync topology on the server-side of the sync relationship. 为了简化管理,请使服务器终结点的路径与 Windows 文件共享的路径匹配。To simplify management, make the path of the server endpoint match the path of the Windows file share.

  • 尽可能少地使用存储同步服务。Use as few Storage Sync Services as possible. 这在配置了包含多个服务器终结点的同步组的情况下可以简化管理,因为 Windows Server 一次只能注册一个存储同步服务。This will simplify management when you have sync groups that contain multiple server endpoints, since a Windows Server can only be registered to one Storage Sync Service at a time.

  • 部署 Azure 文件共享时,应注意存储帐户的 IOPS 限制。Paying attention to a storage account's IOPS limitations when deploying Azure file shares. 理想情况下,会将文件共享与存储帐户以 1:1 的比例进行映射,但由于存在来自于你的组织和 Azure 的各种限制,这并非总是可能的。Ideally, you would map file shares 1:1 with storage accounts, however this may not always be possible due to various limits and restrictions, both from your organization and from Azure. 如果无法做到在一个存储帐户中只部署一个文件共享,可以考虑哪些共享会非常活跃,哪些共享不会那么活跃,以此确保不会将使用率最高的那些文件共享放置在同一存储帐户中。When it is not possible to have only one file share deployed in one storage account, consider which shares will be highly active and which shares will be less active to ensure that the hottest file shares don't get put in the same storage account together.

Windows 文件服务器注意事项Windows file server considerations

若要在 Windows Server 上启用同步功能,需要安装可下载的 Azure 文件同步代理。To enable the sync capability on Windows Server, you must install the Azure File Sync downloadable agent. Azure 文件同步代理提供两个主要组件:FileSyncSvc.exe,这是负责监视服务器终结点上所做更改和启动同步会话的后台 Windows 服务,以及 StorageSync.sys,这是可实现云分层功能和快速灾难恢复的文件系统筛选器。The Azure File Sync agent provides two main components: FileSyncSvc.exe, the background Windows service that is responsible for monitoring changes on the server endpoints and initiating sync sessions, and StorageSync.sys, a file system filter that enables cloud tiering and fast disaster recovery.

操作系统要求Operating system requirements

以下 Windows Server 版本支持 Azure 文件同步:Azure File Sync is supported with the following versions of Windows Server:

版本Version 支持的 SKUSupported SKUs 支持的部署选项Supported deployment options
Windows Server 2019Windows Server 2019 Datacenter、Standard 和 IoTDatacenter, Standard, and IoT “完整”和“核心”Full and Core
Windows Server 2016Windows Server 2016 Datacenter、Standard 和 Storage ServerDatacenter, Standard, and Storage Server “完整”和“核心”Full and Core
Windows Server 2012 R2Windows Server 2012 R2 Datacenter、Standard 和 Storage ServerDatacenter, Standard, and Storage Server “完整”和“核心”Full and Core

将来的 Windows Server 版本将在发布后添加。Future versions of Windows Server will be added as they are released.

重要

我们建议使用 Windows 更新提供的最新更新,将用于 Azure 文件同步的所有服务器保持最新。We recommend keeping all servers that you use with Azure File Sync up to date with the latest updates from Windows Update.

最低系统资源要求Minimum system resources

Azure 文件同步需要使用服务器(物理或虚拟),服务器需配有至少一个 CPU 和至少 2 GiB 的内存。Azure File Sync requires a server, either physical or virtual, with at least one CPU and a minimum of 2 GiB of memory.

重要

如果服务器要在启用了动态内存的虚拟机中运行,应至少为虚拟机配置 2048 MiB 的内存。If the server is running in a virtual machine with dynamic memory enabled, the VM should be configured with a minimum of 2048 MiB of memory.

对于大多数生产工作负荷,不建议使用按最低要求配置的“Azure 文件同步”同步服务器。For most production workloads, we do not recommend configuring an Azure File Sync sync server with only the minimum requirements. 有关详细信息,请参阅推荐使用的系统资源See Recommended system resources for more information.

与其他任何服务器功能或应用程序一样,Azure 文件同步的系统资源要求取决于部署的规模;服务器上的部署规模越大,需要的系统资源就越多。Just like any server feature or application, the system resource requirements for Azure File Sync are determined by the scale of the deployment; larger deployments on a server require greater system resources. 就 Azure 文件同步而言,相应的部署规模取决于所有服务器终结点上的对象数和数据集上的代码改动情况。For Azure File Sync, scale is determined by the number of objects across the server endpoints and the churn on the dataset. 一个服务器可以在多个同步组中设置服务器终结点,且下表中列出的对象的数量会影响服务器所附加到的完整命名空间的规模。A single server can have server endpoints in multiple sync groups and the number of objects listed in the following table accounts for the full namespace that a server is attached to.

例如,具有 1 千万个对象的服务器终结点 A + 具有 1 千万个对象的服务器终结点 B = 2 千万个对象。For example, server endpoint A with 10 million objects + server endpoint B with 10 million objects = 20 million objects. 对于这样一个部署,建议配置 8 个 CPU,16 GiB 的稳态内存,并为初始迁移配置 48 GiB 内存(如有可能)。For that example deployment, we would recommend 8 CPUs, 16 GiB of memory for steady state, and (if possible) 48 GiB of memory for the initial migration.

出于性能原因,命名空间数据存储在内存中。Namespace data is stored in memory for performance reasons. 因此,命名空间越大,需要的内存越多,这样才能保持良好的性能,更多的代码改动也需要更多的 CPU 来处理。Because of that, bigger namespaces require more memory to maintain good performance, and more churn requires more CPU to process.

下表中提供了命名空间的大小以及转换为常规用途的典型文件共享后的容量,其平均文件大小为 512 KiB。In the following table, we have provided both the size of the namespace as well as a conversion to capacity for typical general purpose file shares, where the average file size is 512 KiB. 如果你的文件大小比上述数据小,请考虑为同一容量增加额外的内存。If your file sizes are smaller, consider adding additional memory for the same amount of capacity. 应根据命名空间的大小来配置内容容量。Base your memory configuration on the size of the namespace.

命名空间大小 - 文件和目录(百万)Namespace size - files & directories (millions) 典型容量 (TiB)Typical capacity (TiB) CPU 内核数CPU Cores 建议的内存 (GiB)Recommended memory (GiB)
33 1.41.4 22 8(初始同步)/ 2(典型代码改动)8 (initial sync)/ 2 (typical churn)
55 2.32.3 22 16(初始同步)/ 4(典型代码改动)16 (initial sync)/ 4 (typical churn)
1010 4.74.7 44 32(初始同步)/ 8(典型代码改动)32 (initial sync)/ 8 (typical churn)
3030 14.014.0 88 48(初始同步)/ 16(典型代码改动)48 (initial sync)/ 16 (typical churn)
5050 23.323.3 1616 64(初始同步)/ 32(典型代码改动)64 (initial sync)/ 32 (typical churn)
100*100* 46.646.6 3232 128(初始同步)/ 32(典型代码改动)128 (initial sync)/ 32 (typical churn)

*目前不建议同步超过 1 亿个文件和目录。*Syncing more than 100 million files & directories is not recommended at this time. 这是基于我们测试的阈值的软限制。This is a soft limit based on our tested thresholds. 有关详细信息,请参阅 Azure 文件存储可伸缩性和性能目标For more information, see Azure Files scalability and performance targets.

提示

命名空间的初始同步是一种密集型操作,建议在初始同步完成之前分配较多内存。Initial synchronization of a namespace is an intensive operation and we recommend allocating more memory until initial synchronization is complete. 这不是必需的,但这样做有可能加快初始同步的速度。This isn't required but, may speed up initial sync.

通常,每日代码改动量占命名空间更改量的 0.5%。Typical churn is 0.5% of the namespace changing per day. 如果代码改动量较大,应考虑添加更多 CPU。For higher levels of churn, consider adding more CPU.

  • 使用 NTFS 文件系统进行了格式化的本地附加卷。A locally attached volume formatted with the NTFS file system.

评估 cmdletEvaluation cmdlet

在部署 Azure 文件同步之前,应当使用 Azure 文件同步评估 cmdlet 评估它是否与你的系统兼容。Before deploying Azure File Sync, you should evaluate whether it is compatible with your system using the Azure File Sync evaluation cmdlet. 此 cmdlet 用于检查文件系统和数据集的潜在问题,例如不受支持的字符或不受支持的操作系统版本。This cmdlet checks for potential issues with your file system and dataset, such as unsupported characters or an unsupported operating system version. 其检查涵盖了下面提到的大多数但并非全部功能;建议你仔细读完本部分的剩余内容,以确保你的部署顺利进行。Its checks cover most but not all of the features mentioned below; we recommend you read through the rest of this section carefully to ensure your deployment goes smoothly.

可以通过安装 Az PowerShell 模块来安装评估 cmdlet,该模块可按照以下说明进行安装:安装和配置 Azure PowerShellThe evaluation cmdlet can be installed by installing the Az PowerShell module, which can be installed by following the instructions here: Install and configure Azure PowerShell.

使用情况Usage

可以采用以下多种不同的方式调用评估工具:可以执行系统检查、数据集检查或者同时执行这两种检查。You can invoke the evaluation tool in a few different ways: you can perform the system checks, the dataset checks, or both. 若要同时执行系统和数据集检查,请使用以下命令:To perform both the system and dataset checks:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

若要仅测试数据集,请使用以下命令:To test only your dataset:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

若要仅测试系统要求,请使用以下命令:To test system requirements only:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

若要以 CSV 格式显示结果,请使用以下命令:To display the results in CSV:

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

文件系统兼容性File system compatibility

仅支持在直接附加的 NTFS 卷上使用 Azure 文件同步。Azure File Sync is only supported on directly attached, NTFS volumes. Windows Server 上设置有直连存储 (DAS) 意味着由 Windows Server 操作系统提供文件系统。Direct attached storage, or DAS, on Windows Server means that the Windows Server operating system owns the file system. 可以通过以物理方式将磁盘附加到文件服务器、通过将虚拟磁盘附加到文件服务器虚拟机(例如由 Hyper-v 托管的虚拟机),甚至可以通过 ISCSI,来提供 DAS。DAS can be provided through physically attaching disks to the file server, attaching virtual disks to a file server VM (such as a VM hosted by Hyper-V), or even through ISCSI.

仅支持 NTFS 卷;不支持 ReFS、FAT、FAT32 和其他文件系统。Only NTFS volumes are supported; ReFS, FAT, FAT32, and other file systems are not supported.

下表显示 NTFS 文件系统功能的互操作状态:The following table shows the interop state of NTFS file system features:

FeatureFeature 支持状态Support status 说明Notes
访问控制列表 (ACL)Access control lists (ACLs) 完全支持Fully supported Windows 样式随机访问控制列表由 Azure 文件同步功能负责留存,并由 Windows Server 在服务器终结点上强制实施。Windows-style discretionary access control lists are preserved by Azure File Sync, and are enforced by Windows Server on server endpoints. 当直接装载 Azure 文件共享时,也可以强制实施 ACL,但这需要额外配置。ACLs can also be enforced when directly mounting the Azure file share, however this requires additional configuration. 请参阅“标识”部分以了解详细信息。See the Identity section for more information.
硬链接Hard links 已跳过Skipped
符号链接Symbolic links 已跳过Skipped
装入点Mount points 部分支持Partially supported 装入点可能是服务器终结点的根,但如果包含在服务器终结点的命名空间内,则跳过此装入点。Mount points might be the root of a server endpoint, but they are skipped if they are contained in a server endpoint's namespace.
交接点Junctions 已跳过Skipped 例如,分布式文件系统中的 DfrsrPrivate 和 DFSRoots 文件夹。For example, Distributed File System DfrsrPrivate and DFSRoots folders.
重分析点Reparse points 已跳过Skipped
NTFS 压缩NTFS compression 完全支持Fully supported
稀疏文件Sparse files 完全支持Fully supported 稀疏文件会进行同步(不受阻),但作为完整文件同步到云。Sparse files sync (are not blocked), but they sync to the cloud as a full file. 如果在云中(或在其他服务器上)更改文件内容,则下载更改时,文件不再是稀疏文件。If the file contents change in the cloud (or on another server), the file is no longer sparse when the change is downloaded.
备用数据流 (ADS)Alternate Data Streams (ADS) 保留但不同步Preserved, but not synced 例如,由文件分类基础结构创建的分类标记就不会同步。For example, classification tags created by the File Classification Infrastructure are not synced. 每个服务器终结点的文件上的现有分类标记都保留不变。Existing classification tags on files on each of the server endpoints are left untouched.

Azure 文件同步还会跳过某些临时文件和系统文件夹:Azure File Sync will also skip certain temporary files and system folders:

文件/文件夹File/folder 注意Note
pagefile.syspagefile.sys 特定于系统的文件File specific to system
Desktop.iniDesktop.ini 特定于系统的文件File specific to system
thumbs.dbthumbs.db 缩略图的临时文件Temporary file for thumbnails
ehthumbs.dbehthumbs.db 媒体临时文件的缩略图Temporary file for media thumbnails
~$*.*~$*.* Office 临时文件Office temporary file
*.tmp*.tmp 临时文件Temporary file
*.laccdb*.laccdb Access DB 锁定文件Access DB locking file
635D02A9D91C401B97884B82B3BCDAEA.*635D02A9D91C401B97884B82B3BCDAEA.* 内部同步文件Internal Sync file
\系统卷信息\System Volume Information 特定于卷的文件夹Folder specific to volume
$RECYCLE.BIN$RECYCLE.BIN FolderFolder
\SyncShareState\SyncShareState 用于同步的文件夹Folder for Sync

故障转移群集Failover Clustering

Windows Server 故障转移群集受 Azure 文件同步支持,用于“一般用途文件服务器”部署选项。Windows Server Failover Clustering is supported by Azure File Sync for the "File Server for general use" deployment option. 不可在“适用于应用程序数据的横向扩展文件服务器”(SOFS) 或群集共享卷 (CSV) 上使用故障转移群集。Failover Clustering is not supported on "Scale-Out File Server for application data" (SOFS) or on Clustered Shared Volumes (CSVs).

备注

必须在故障转移群集中的每个节点上安装 Azure 文件同步代理,才能正常进行同步。The Azure File Sync agent must be installed on every node in a Failover Cluster for sync to work correctly.

重复数据删除Data Deduplication

Windows Server 2016 和 Windows Server 2019 Windows Server 2016 and Windows Server 2019
Windows Server 2016 和 Windows Server 2019 上启用了云分层的卷支持重复数据删除。Data Deduplication is supported on volumes with cloud tiering enabled on Windows Server 2016 and Windows Server 2019. 在启用了云分层的卷上启用重复数据删除后,即可在本地缓存更多文件,而无需预配更多存储。Enabling Data Deduplication on a volume with cloud tiering enabled lets you cache more files on-premises without provisioning more storage.

在启用了云分层的卷上启用重复数据删除后,将根据云分层策略设置,按与普通文件类似的方式,对服务器终结点位置中经过“重复数据删除”优化的文件进行分层。When Data Deduplication is enabled on a volume with cloud tiering enabled, Dedup optimized files within the server endpoint location will be tiered similar to a normal file based on the cloud tiering policy settings. 将经过“重复数据删除”优化的文件进行分层后,重复数据删除垃圾回收作业将自动运行,通过删除卷上不再被其他文件引用的、不必要的区块来回收磁盘空间。Once the Dedup optimized files have been tiered, the Data Deduplication garbage collection job will run automatically to reclaim disk space by removing unnecessary chunks that are no longer referenced by other files on the volume.

请注意,卷空间节省效果仅适用于服务器;不会对 Azure 文件共享中的数据执行“重复数据删除”。Note the volume savings only apply to the server; your data in the Azure file share will not be deduped.

备注

若要支持在 Windows Server 2019 上对启用了云分层的卷执行重复数据删除,需要安装 Windows 更新 KB4520062,并且需要使用 9.0.0.0 版或更新版本的 Azure 文件同步代理。To support Data Deduplication on volumes with cloud tiering enabled on Windows Server 2019, Windows update KB4520062 must be installed and Azure File Sync agent version 9.0.0.0 or newer is required.

Windows Server 2012 R2Windows Server 2012 R2
Azure 文件同步不支持在 Windows Server 2012 R2 上的同一卷上启用重复数据删除和云分层。Azure File Sync does not support Data Deduplication and cloud tiering on the same volume on Windows Server 2012 R2. 如果在卷上启用了重复数据删除,则必须禁用云分层。If Data Deduplication is enabled on a volume, cloud tiering must be disabled.

说明Notes

  • 如果在安装 Azure 文件同步代理之前安装了重复数据删除,则需要重新启动才能支持在同一卷上使用重复数据删除和云分层。If Data Deduplication is installed prior to installing the Azure File Sync agent, a restart is required to support Data Deduplication and cloud tiering on the same volume.

  • 如果重复数据删除是在启用云分层之后在卷上启用的,则初始重复数据删除优化作业将优化卷上尚未分层的的文件,这会对云分层产生以下影响:If Data Deduplication is enabled on a volume after cloud tiering is enabled, the initial Deduplication optimization job will optimize files on the volume that are not already tiered and will have the following impact on cloud tiering:

    • 可用空间策略将使用热度地图,根据卷上的可用空间,继续对文件进行分层。Free space policy will continue to tier files as per the free space on the volume by using the heatmap.
    • 由于重复数据删除优化作业会访问文件,日期策略会跳过对本来可能有资格进行分层的文件进行分层。Date policy will skip tiering of files that may have been otherwise eligible for tiering due to the Deduplication optimization job accessing the files.
  • 对于正在进行的重复数据删除优化作业,如果文件尚未分层,启用了日期策略的云分层操作会因“重复数据删除”的 MinimumFileAgeDays 设置而延迟执行。For ongoing Deduplication optimization jobs, cloud tiering with date policy will get delayed by the Data Deduplication MinimumFileAgeDays setting, if the file is not already tiered.

    • 示例:如果 MinimumFileAgeDays 设置为 7 天,而云分层日期策略设置为 30 天,则日期策略将在 37 天后对文件分层。Example: If the MinimumFileAgeDays setting is seven days and cloud tiering date policy is 30 days, the date policy will tier files after 37 days.
    • 注意:一旦 Azure 文件同步对某个文件进行分层后,重复数据删除优化作业将立即跳过该文件。Note: Once a file is tiered by Azure File Sync, the Deduplication optimization job will skip the file.
  • 如果某个服务器正在运行 Windows Server 2012 R2 且安装了 Azure 文件同步代理,当它升级到 Windows Server 2016 或 Windows Server 2019 后,需要执行以下步骤,才能支持在同一卷上启用重复数据删除和云分层:If a server running Windows Server 2012 R2 with the Azure File Sync agent installed is upgraded to Windows Server 2016 or Windows Server 2019, the following steps must be performed to support Data Deduplication and cloud tiering on the same volume:

    • 卸载适用于 Windows Server 2012 R2 的 Azure 文件同步代理并重新启动服务器。Uninstall the Azure File Sync agent for Windows Server 2012 R2 and restart the server.
    • 下载适用于新服务器操作系统版本(Windows Server 2016 或 Windows Server 2019)的 Azure 文件同步代理。Download the Azure File Sync agent for the new server operating system version (Windows Server 2016 or Windows Server 2019).
    • 安装 Azure 文件同步代理并重新启动服务器。Install the Azure File Sync agent and restart the server.

    注意:卸载并重新安装代理时,会保留服务器上的 Azure 文件同步配置设置。Note: The Azure File Sync configuration settings on the server are retained when the agent is uninstalled and reinstalled.

分布式文件系统 (DFS)Distributed File System (DFS)

Azure 文件同步支持与 DFS 命名空间 (DFS-N) 和 DFS 复制 (DFS-R) 进行互操作。Azure File Sync supports interop with DFS Namespaces (DFS-N) and DFS Replication (DFS-R).

DFS 命名空间 (DFS-N) :Azure 文件同步在 DFS-N 服务器上完全受支持。DFS Namespaces (DFS-N) : Azure File Sync is fully supported on DFS-N servers. 可以在一个或多个 DFS-N 成员上安装 Azure 文件同步代理,以在服务器终结点与云终结点之间同步数据。You can install the Azure File Sync agent on one or more DFS-N members to sync data between the server endpoints and the cloud endpoint. 有关详细信息,请参阅 DFS 命名空间概述For more information, see DFS Namespaces overview.

DFS 复制 (DFS-R) :因为 DFS-R 和 Azure 文件同步都是复制解决方案,所以在大多数情况下建议将 DFS-R 替换为 Azure 文件同步。不过在以下几个方案中,可能需要同时使用 DFS-R 和 Azure 文件同步:DFS Replication (DFS-R) : Since DFS-R and Azure File Sync are both replication solutions, in most cases, we recommend replacing DFS-R with Azure File Sync. There are however several scenarios where you would want to use DFS-R and Azure File Sync together:

  • 从 DFS-R 部署迁移至 Azure 文件同步部署。You are migrating from a DFS-R deployment to an Azure File Sync deployment. 有关详细信息,请参阅将 DFS 复制 (DFS-R) 部署迁移至 Azure 文件同步For more information, see Migrate a DFS Replication (DFS-R) deployment to Azure File Sync.
  • 需要文件数据副本的本地服务器并非都能直接连接到 Internet。Not every on-premises server that needs a copy of your file data can be connected directly to the internet.
  • 分支服务器将数据合并至单个中心服务器,你希望在该服务器中使用 Azure 文件同步。Branch servers consolidate data onto a single hub server, for which you would like to use Azure File Sync.

让 Azure 文件同步和 DFS-R 并行工作:For Azure File Sync and DFS-R to work side by side:

  1. 必须在包含 DFS-R 复制文件夹的卷上禁用 Azure 文件同步云分层。Azure File Sync cloud tiering must be disabled on volumes with DFS-R replicated folders.
  2. 不应在 DFS-R 只读复制文件夹上配置服务器终结点。Server endpoints should not be configured on DFS-R read-only replication folders.

有关详细信息,请参阅 DFS 复制概述For more information, see DFS Replication overview.

SysprepSysprep

不支持在安装了 Azure 文件同步代理的服务器上使用 sysprep,此操作会导致意外结果。Using sysprep on a server that has the Azure File Sync agent installed is not supported and can lead to unexpected results. 应该在部署服务器映像并完成 sysprep 迷你安装后再安装代理和注册服务器。Agent installation and server registration should occur after deploying the server image and completing sysprep mini-setup.

如果在服务器终结点上启用了云分层功能,则已分层的文件将被跳过,并且不会由 Windows 搜索进行索引。If cloud tiering is enabled on a server endpoint, files that are tiered are skipped and not indexed by Windows Search. 非分层文件会适当进行索引。Non-tiered files are indexed properly.

其他分层存储管理 (HSM) 解决方案Other Hierarchical Storage Management (HSM) solutions

其他 HSM 解决方案均无法使用 Azure 文件同步。No other HSM solutions should be used with Azure File Sync.

标识Identity

Azure 文件同步可处理基于 AD 的标准标识,且只需要设置同步,而无需任何其他特殊设置。当使用 Azure 文件同步时,一般情况下,大多数访问是通过 Azure 文件同步缓存服务器而不是通过 Azure 文件共享来完成的。Azure File Sync works with your standard AD-based identity without any special setup beyond setting up sync. When you are using Azure File Sync, the general expectation is that most accesses go through the Azure File Sync caching servers, rather than through the Azure file share. 由于服务器终结点位于 Windows Server 上,并且 Windows Server 长期以来一直支持 AD 和 Windows 样式 ACL,因此,只要确保将注册了存储同步服务的 Windows 文件服务器加入域就行了,除此之外无需执行任何其他操作。Since the server endpoints are located on Windows Server, and Windows Server has supported AD and Windows-style ACLs for a long time, nothing is needed beyond ensuring the Windows file servers registered with the Storage Sync Service are domain joined. Azure 文件同步会将 ACL 存储在 Azure 文件共享中的文件上,并将其复制到所有服务器终结点。Azure File Sync will store ACLs on the files in the Azure file share, and will replicate them to all server endpoints.

即使直接对 Azure 文件共享所做的更改需要更长的时间才能同步到同步组中的服务器终结点,你可能还是想确保自己能够在云中直接对文件共享强制实施 AD 权限。Even though changes made directly to the Azure file share will take longer to sync to the server endpoints in the sync group, you may also want to ensure that you can enforce your AD permissions on your file share directly in the cloud as well. 为此,需要将存储帐户以“域加入”的方式加入本地 AD 中,就像 Windows 文件服务器的域加入方式一样。To do this, you must domain join your storage account to your on-premises AD, just like how your Windows file servers are domain joined. 若要详细了解如何将存储帐户“域加入”到客户拥有的 Active Directory,请参阅 Azure 文件存储 Active Directory 概述To learn more about domain joining your storage account to a customer-owned Active Directory, see Azure Files Active Directory overview.

重要

若要成功部署 Azure 文件同步,无需将存储帐户“域加入”到 Active Directory。这是一个可选步骤,可让 Azure 文件共享在用户直接装载 Azure 文件共享的情况下强制实施本地 ACL。Domain joining your storage account to Active Directory is not required to successfully deploy Azure File Sync. This is a strictly optional step that allows the Azure file share to enforce on-premises ACLs when users mount the Azure file share directly.

网络Networking

Azure 文件同步代理使用 Azure 文件同步 REST 协议和 FileREST 协议与存储同步服务和 Azure 文件共享功能进行通信,这两种协议始终通过端口 443 使用 HTTPS。The Azure File Sync agent communicates with your Storage Sync Service and Azure file share using the Azure File Sync REST protocol and the FileREST protocol, both of which always use HTTPS over port 443. SMB 从不用于在 Windows Server 和 Azure 文件共享之间上载或下载数据。SMB is never used to upload or download data between your Windows Server and the Azure file share. 由于大多数组织都允许通过端口 443 传递 HTTPS 流量,这是访问大多数网站时的一个要求,因此通常不需要特殊网络配置就能部署 Azure 文件同步。Because most organizations allow HTTPS traffic over port 443, as a requirement for visiting most websites, special networking configuration is usually not required to deploy Azure File Sync.

根据组织的策略或独特的法规要求,与 Azure 的通信可能需要设置更严格的限制,因此 Azure 提供了多种网络配置机制。Based on your organization's policy or unique regulatory requirements, you may require more restrictive communication with Azure, and therefore Azure File Sync provides several mechanisms for you configure networking. 根据你的要求,你可以:Based on your requirements, you can:

  • 通过 ExpressRoute 或 Azure VPN 进行隧道同步和传递文件上传/下载流量。Tunnel sync and file upload/download traffic over your ExpressRoute or Azure VPN.
  • 利用 Azure 文件存储和 Azure 网络功能,如服务终结点和专用终结点。Make use of Azure Files and Azure Networking features such as service endpoints and private endpoints.
  • 配置 Azure 文件同步以支持环境中的代理。Configure Azure File Sync to support your proxy in your environment.
  • 限制 Azure 文件同步的网络活动。Throttle network activity from Azure File Sync.

若要详细了解 Azure 文件同步和网络,请参阅 Azure 文件同步网络注意事项To learn more about Azure File Sync and networking, see Azure File Sync networking considerations.

加密Encryption

使用 Azure 文件同步时,需要考虑三个不同的加密层:对 Windows Server 的静态存储进行加密、在 Azure 文件同步代理与 Azure 之间的传输中进行加密,以及在 Azure 文件共享中对数据进行静态加密。When using Azure File Sync, there are three different layers of encryption to consider: encryption on the at-rest storage of Windows Server, encryption in transit between the Azure File Sync agent and Azure, and encryption at rest of your data in the Azure file share.

Windows Server 静态加密Windows Server encryption at rest

对于 Azure 文件同步,有两个基本适用的关于 Windows Server 上加密数据的策略:一种是可对文件系统和写入其中的所有数据进行加密的文件系统下加密策略,另一种是文件格式内部的加密策略。There are two strategies for encrypting data on Windows Server that work generally with Azure File Sync: encryption beneath the file system such that the file system and all of the data written to it is encrypted, and encryption within the file format itself. 这些方法不是互斥的;如果需要,可以将它们一起使用,因为加密的目的不同。These methods are not mutually exclusive; they can be used together if desired since the purpose of encryption is different.

为了在文件系统下提供加密,Windows Server 提供了 BitLocker 收件箱。To provide encryption beneath the file system, Windows Server provides BitLocker inbox. BitLocker 对 Azure 文件同步是完全透明的。使用 BitLocke 这样的加密机制的主要原因是,阻止想窃取磁盘的人造成本地数据中心数据的物理泄漏,并防止有人通过旁加载未授权的操作系统来对数据执行未经授权的读取/写入操作。BitLocker is fully transparent to Azure File Sync. The primary reason to use an encryption mechanism like BitLocker is to prevent physical exfiltration of data from your on-premises datacenter by someone stealing the disks and to prevent sideloading an unauthorized OS to perform unauthorized reads/writes to your data. 若要了解有关 BitLocker 的详细信息,请参阅 BitLocker 概述To learn more about BitLocker, see BitLocker overview.

与 BitLocker 工作方式类似的第三方产品(即都在 NTFS 卷下运行),其工作方式也应对 Azure 文件同步完全透明。Third-party products that work similarly to BitLocker, in that they sit beneath the NTFS volume, should similarly work fully transparently with Azure File Sync.

用于加密数据的另一个主要方法是在应用程序保存文件时加密文件的数据流。The other main method for encrypting data is to encrypt the file's data stream when the application saves the file. 某些应用程序可能会以本机方式执行此操作,但这并不是常见的方式。Some applications may do this natively, however this is usually not the case. 用于加密文件数据流的方法的一个例子是 Azure 信息保护 (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RM。An example of a method for encrypting the file's data stream is Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. 使用 AIP/RMS 这类加密机制的主要原因是,阻止试图将文件共享中的数据复制到备用位置(如闪存驱动器)或试图通过电子邮件将其发送给未经授权的人员的人造成数据泄漏。The primary reason to use an encryption mechanism like AIP/RMS is to prevent data exfiltration of data from your file share by people copying it to alternate locations, like to a flash drive, or emailing it to an unauthorized person. 当文件的数据流加密为文件格式的一部分时,将继续在 Azure 文件共享中对此文件进行加密。When a file's data stream is encrypted as part of the file format, this file will continue to be encrypted on the Azure file share.

Azure 文件同步不与位于文件系统上的而是与位于文件数据流下的 NTFS 加密文件系统 (NTFS EFS) 或第三方加密解决方案进行互操作。Azure File Sync does not interoperate with NTFS Encrypted File System (NTFS EFS) or third-party encryption solutions that sit above the file system but below the file's data stream.

传输中加密Encryption in transit

备注

Azure 文件同步服务将于 2020 年 8 月 1 日删除对 TLS1.0 和 1.1 的支持。Azure File Sync service will remove support for TLS1.0 and 1.1 on August 1st, 2020. 默认情况下,所有支持的 Azure 文件同步代理版本已使用 TLS 1.2。All supported Azure File Sync agent versions already use TLS1.2 by default. 如果在服务器上禁用了 TLS 1.2 或使用了代理,则可能会使用较早版本的 TLS。Using an earlier version of TLS could occur if TLS1.2 was disabled on your server or a proxy is used. 如果使用了代理,建议检查代理配置。If you are using a proxy, we recommend you check the proxy configuration. 2020/5/1 之后添加的 Azure 文件同步服务区域将仅支持 TLS 1.2,将于 2020 年 8 月 1 日删除现有区域中对 TLS1.0 和 1.1 的支持。Azure File Sync service regions added after 5/1/2020 will only support TLS1.2 and support for TLS1.0 and 1.1 will be removed from existing regions on August 1st, 2020. 有关详细信息,请参阅故障排除指南For more information, see the troubleshooting guide.

Azure 文件同步代理使用 Azure 文件同步 REST 协议和 FileREST 协议与存储同步服务和 Azure 文件共享功能进行通信,这两种协议始终通过端口 443 使用 HTTPS。Azure File Sync agent communicates with your Storage Sync Service and Azure file share using the Azure File Sync REST protocol and the FileREST protocol, both of which always use HTTPS over port 443. Azure 文件同步不通过 HTTP 发送未加密的请求。Azure File Sync does not send unencrypted requests over HTTP.

Azure 存储帐户包含一个用于要求在传输过程中加密的开关,该开关在默认情况下为启用状态。Azure storage accounts contain a switch for requiring encryption in transit, which is enabled by default. 即使在存储帐户级别上禁用了此开关,也就是说可能会存在与 Azure 文件共享之间的未加密连接,Azure 文件同步仍将仅使用加密通道来访问文件共享。Even if the switch at the storage account level is disabled, meaning that unencrypted connections to your Azure file shares are possible, Azure File Sync will still only used encrypted channels to access your file share.

为存储帐户禁用传输中加密的主要原因是为了支持必须在更低版本的操作系统(例如,Windows Server 2008 R2 或更低版本的 Linux 发行版)上运行且直接与 Azure 文件共享通信的旧版应用程序。The primary reason to disable encryption in transit for the storage account is to support a legacy application that must be run on an older operating system, such as Windows Server 2008 R2 or older Linux distribution, talking to an Azure file share directly. 如果旧版应用程序与文件共享的 Windows Server 缓存进行通信,切换此设置将不起作用。If the legacy application talks to the Windows Server cache of the file share, toggling this setting will have no effect.

强烈建议确保启用了传输中数据的加密。We strongly recommend ensuring encryption of data in-transit is enabled.

有关传输中加密的详细信息,请参阅要求在 Azure 存储中进行安全传输For more information about encryption in transit, see requiring secure transfer in Azure storage.

Azure 文件共享静态加密Azure file share encryption at rest

使用 Azure 存储服务加密 (SSE) 对存储在 Azure 文件存储中的所有数据进行静态加密。All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). 存储服务加密的工作方式类似于 Windows 上的 BitLocker:在文件系统级别下对数据进行加密。Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. 由于数据在 Azure 文件共享的文件系统下加密,因此,在将数据编码到磁盘时,无需访问客户端上的基础密钥即可读取或写入 Azure 文件共享。Because data is encrypted beneath the Azure file share's file system, as it's encoded to disk, you don't have to have access to the underlying key on the client to read or write to the Azure file share. 静态加密同时适用于 SMB 和 NFS 协议。Encryption at rest applies to both the SMB and NFS protocols.

默认情况下,Azure 文件存储中存储的数据使用 Microsoft 管理的密钥进行加密。By default, data stored in Azure Files is encrypted with Microsoft-managed keys. 通过 Microsoft 管理的密钥,Microsoft 持有加密/解密数据的密钥,且负责定期轮换这些密钥。With Microsoft-managed keys, Microsoft holds the keys to encrypt/decrypt the data, and is responsible for rotating them on a regular basis. 你还选择管理你自己的密钥,这让你能够控制密钥轮换过程。You can also choose to manage your own keys, which gives you control over the rotation process. 如果你选择使用客户管理的密钥来加密你的文件共享,则 Azure 文件存储可访问你的密钥来执行来自你的客户端的读取和写入请求。If you choose to encrypt your file shares with customer-managed keys, Azure Files is authorized to access your keys to fulfill read and write requests from your clients. 通过客户管理的密钥,你可随时撤销此授权,但撤销意味着将无法再通过 SMB 或 FileREST API 访问你的 Azure 文件共享。With customer-managed keys, you can revoke this authorization at any time, but this means that your Azure file share will no longer be accessible via SMB or the FileREST API.

Azure 文件存储预其他 Azure 存储服务(例如 Azure Blob 存储)使用相同的机密方案。Azure Files uses the same encryption scheme as the other Azure storage services such as Azure Blob storage. 要详细了解 Azure 存储服务加密 (SSE),请参阅针对静态数据的 Azure 存储加密To learn more about Azure storage service encryption (SSE), see Azure storage encryption for data at rest.

存储层Storage tiers

Azure 文件存储提供了四种不同的存储层(高级、事务优化、热和冷存储层),因此你能够根据方案的性能和价格要求定制共享:Azure Files offers four different tiers of storage, premium, transaction optimized, hot, and cool to allow you to tailor your shares to the performance and price requirements of your scenario:

  • Premium:高级文件共享由固态硬盘 (SSD) 支持,并部署在 FileStorage 存储帐户类型中。Premium: Premium file shares are backed by solid-state drives (SSDs) and are deployed in the FileStorage storage account type. 高级文件共享提供稳定的高性能和低延迟,对于大多数 IO 操作和 IO 密集型工作负荷,延迟不到 10 毫秒。Premium file shares provide consistent high performance and low latency, within single-digit milliseconds for most IO operations, for IO-intensive workloads. 高级文件共享适合各种各样的工作负载,例如数据库、网站托管和开发环境。Premium file shares are suitable for a wide variety of workloads like databases, web site hosting, and development environments. 高级文件共享既可用于服务器消息块 (SMB) 协议,也可用于网络文件系统 (NFS) 协议。Premium file shares can be used with both Server Message Block (SMB) and Network File System (NFS) protocols.
  • 事务优化:事务优化文件共享可实现事务繁重的工作负载,这些工作负荷不需要高级文件共享提供的延迟。Transaction optimized: Transaction optimized file shares enable transaction heavy workloads that don't need the latency offered by premium file shares. 事务优化文件共享在硬盘驱动器 (HDD) 支持的标准存储硬件上提供,并部署在常规用途版本 2 (GPv2) 存储帐户类型中。Transaction optimized file shares are offered on the standard storage hardware backed by hard disk drives (HDDs) and are deployed in the general purpose version 2 (GPv2) storage account type. 虽然事务优化一直被称为“标准”层,但这指的是存储介质类型而不是层本身(热和冷存储层也是“标准”层,因为它们位于标准存储硬件上)。Transaction optimized has historically been called "standard", however this refers to the storage media type rather than the tier itself (the hot and cool are also "standard" tiers, because they are on standard storage hardware).
  • Hot:热文件共享提供针对常规用途文件共享方案(如团队共享和 Azure 文件同步)优化的存储。热文件共享在 HDD 支持的标准存储硬件上提供,并部署在常规用途版本 2 (GPv2) 存储帐户类型中。Hot: Hot file shares offer storage optimized for general purpose file sharing scenarios such as team shares and Azure File Sync. Hot file shares are offered on the standard storage hardware backed by HDDs and are deployed in the general purpose version 2 (GPv2) storage account type.
  • Cool:冷文件共享提供针对在线存档存储方案优化的经济高效的存储。Cool: Cool file shares offer cost-efficient storage optimized for online archive storage scenarios. Azure 文件同步可能也适用于低改动工作负载。Azure File Sync may also be a good fit for lower churn workloads. 冷文件共享在 HDD 支持的标准存储硬件上提供,并部署在常规用途版本 2 (GPv2) 存储帐户类型中。Cool file shares are offered on the standard storage hardware backed by HDDs and are deployed in the general purpose version 2 (GPv2) storage account type.

高级文件共享只能在预配的计费模型下使用。Premium file shares are only available in a provisioned billing model. 有关高级文件共享的预配计费模型的详细信息,请参阅了解预配高级文件共享For more information on the provisioned billing model for premium file shares, see Understanding provisioning for premium file shares. 标准文件共享(包括事务优化、热和冷文件共享)以即用即付计费的形式提供。Standard file shares, including transaction optimized, hot, and cool file shares, are available through pay as you go billing.

热文件共享和冷文件共享在所有 Azure 公共区域和 Azure 政府区域中均可用。Hot and cool file shares are available in all Azure Public and Azure Government regions. 事务优化文件共享在所有 Azure 区域中可用,包括 Azure 中国和 Azure 德国区域。Transaction optimized file shares are available in all Azure regions, including Azure China and Azure Germany regions.

重要

可以在 GPv2 存储帐户类型中的各层(事务优化、热和冷)之间移动文件共享。You can move file shares between tiers within GPv2 storage account types (transaction optimized, hot, and cool). 共享在层间移动会产生事务:从较热层移动到较冷层会导致对共享中每个文件收取冷层的写入事务费用,而从较冷层移动到较热层会导致对共享中每个文件收取冷层的读取事务费用。Share moves between tiers incur transactions: moving from a hotter tier to a cooler tier will incur the cooler tier's write transaction charge for each file in the share, while a move from a cooler tier to a hotter tier will incur the cool tier's read transaction charge for each file the share.

让标准文件共享能够承受最多 100 TiB 的容量Enable standard file shares to span up to 100 TiB

默认情况下,虽然可将共享限制增加到 100 TiB,但标准文件共享只能跨越最多 5 TiB。By default, standard file shares can span only up to 5 TiB, although the share limit can be increased to 100 TiB. 为此,必须在存储帐户级别启用大文件共享功能。To do this, large file share feature must be enabled at the storage account-level. 高级存储帐户(FileStorage 存储帐户)没有大文件共享功能标志,因为所有高级文件共享都可以最高可预配到完整的 100 TiB 容量。Premium storage accounts (FileStorage storage accounts) don't have the large file share feature flag as all premium file shares are already enabled for provisioning up to the full 100 TiB capacity.

仅可在本地冗余或区域冗余标准存储帐户上启用大型文件共享功能。You can only enable large file shares on locally redundant or zone redundant standard storage accounts. 启用大型文件共享功能标志后,无法将冗余级别更改为异地冗余或异地区域冗余存储。Once you have enabled the large file share feature flag, you can't change the redundancy level to geo-redundant or geo-zone-redundant storage.

若要在现有存储帐户上启用大文件共享,请导航到存储帐户的目录中的“配置”视图,将大文件共享摇杆开关切换到“启用”:To enable large file shares on an existing storage account, navigate to the Configuration view in the storage account's table of contents, and switch the large file share rocker switch to enabled:

在 Azure 门户中启用大文件共享摇杆开关的屏幕截图

还可以通过 Set-AzStorageAccount PowerShell cmdlet 和 az storage account update Azure CLI 命令启用 100 TiB 文件共享。You can also enable 100 TiB file shares through the Set-AzStorageAccount PowerShell cmdlet and the az storage account update Azure CLI command. 有关启用大型文件共享的详细说明,请参阅启用和创建大型文件共享For detailed instructions on enabling large files shares, see enable and create large file shares.

要详细了解如何在新存储帐户上创建大型文件共享,请参阅创建 Azure 文件共享To learn more about how to create file shares on new storage accounts, see creating an Azure file share.

区域可用性Regional availability

具有 100 TiB 容量的标准文件共享存在一定限制。Standard file shares with 100 TiB capacity have certain limitations.

  • 当前,仅支持本地冗余存储 (LRS) 和区域冗余存储 (GRS) 帐户。Currently, only locally redundant storage (LRS) and zone redundant storage (ZRS) accounts are supported.
  • 启用大型文件共享功能后,无法将存储帐户转换为区域冗余存储 (GRS) 或异地区域冗余存储 (GZRS) 帐户。Once you enable large file shares, you cannot convert storage accounts to geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) accounts.
  • 启用大型文件共享后,不能禁用。Once you enable large file shares, you can't disable it.

Azure 文件同步区域可用性Azure file sync region availability

Azure 文件同步在以下区域中可用:Azure File Sync is available in the following regions:

Azure 云Azure cloud 地理区域Geographic region Azure 区域Azure region 区域代码Region code
公共Public 亚洲Asia 东亚East Asia eastasia
公共Public 亚洲Asia 东南亚Southeast Asia southeastasia
公共Public 澳大利亚Australia 澳大利亚东部Australia East australiaeast
公共Public 澳大利亚Australia 澳大利亚东南部Australia Southeast australiasoutheast
公共Public 巴西Brazil 巴西南部Brazil South brazilsouth
公共Public CanadaCanada 加拿大中部Canada Central canadacentral
公共Public CanadaCanada 加拿大东部Canada East canadaeast
公共Public 欧洲Europe 北欧North Europe northeurope
公共Public 欧洲Europe 西欧West Europe westeurope
公共Public 法国France 法国中部France Central francecentral
公共Public 法国France 法国南部*France South* francesouth
公共Public 印度India 印度中部Central India centralindia
公共Public 印度India 印度南部South India southindia
公共Public 日本Japan 日本东部Japan East japaneast
公共Public 日本Japan 日本西部Japan West japanwest
公共Public 韩国Korea 韩国中部Korea Central koreacentral
公共Public 韩国Korea 韩国南部Korea South koreasouth
公共Public 南非South Africa 南非北部South Africa North southafricanorth
公共Public 南非South Africa 南非西部*South Africa West* southafricawest
公共Public 阿拉伯联合酋长国UAE 阿联酋中部*UAE Central* uaecentral
公共Public 阿拉伯联合酋长国UAE 阿拉伯联合酋长国北部UAE North uaenorth
公共Public 英国UK 英国南部UK South uksouth
公共Public 英国UK 英国西部UK West ukwest
公共Public 美国US 美国中部Central US centralus
公共Public 美国US 美国东部East US eastus
公共Public 美国US 美国东部 2East US 2 eastus2
公共Public 美国US 美国中北部North Central US northcentralus
公共Public 美国US 美国中南部South Central US southcentralus
公共Public 美国US 美国中西部West Central US westcentralus
公共Public 美国US 美国西部West US westus
公共Public 美国US 美国西部 2West US 2 westus2
US GovUS Gov 美国US US Gov 亚利桑那州US Gov Arizona usgovarizona
US GovUS Gov 美国US US Gov 德克萨斯州US Gov Texas usgovtexas
US GovUS Gov 美国US US Gov 弗吉尼亚州US Gov Virginia usgovvirginia

Azure 文件同步仅支持与存储同步服务所在区域中的 Azure 文件共享进行同步。Azure File Sync supports syncing only with an Azure file share that's in the same region as the Storage Sync Service.

对于带星号的区域,需要与 Azure 支持部门联系,请求访问这些区域中的 Azure 存储。For the regions marked with asterisks, you must contact Azure Support to request access to Azure Storage in those regions. 此文档中介绍了相关流程。The process is outlined in this document.

冗余Redundancy

为了在 Azure 文件共享中保护数据以防数据丢失或损坏,所有 Azure 文件共享都在写入每个文件时存储了该文件的多个副本。To protect the data in your Azure file shares against data loss or corruption, all Azure file shares store multiple copies of each file as they are written. 可以根据工作负载的要求选择额外的冗余度。Depending on the requirements of your workload, you can select additional degrees of redundancy. Azure 文件存储目前支持以下数据冗余选项:Azure Files currently supports the following data redundancy options:

  • 本地冗余:本地冗余存储(通常称为 LRS)表示每个文件在 Azure 存储群集中存储三次。Locally redundant: Locally redundant storage, often referred to as LRS, means that every file is stored three times within an Azure storage cluster. 这可以防止由于硬件故障(例如磁盘驱动器损坏)而导致数据丢失。This protects against loss of data due to hardware faults, such as a bad disk drive.
  • 区域冗余:区域冗余存储(通常称为 ZRS)指的是每个文件在三个不同的 Azure 存储群集中存储三次。Zone redundant: Zone redundant storage, often referred to as ZRS, means that every file is stored three times across three distinct Azure storage clusters. 就像使用本地冗余存储一样,区域冗余会提供每个文件的三个副本,但这些副本位于不同的 Azure 可用性区域的三个不同存储群集中,它们在物理上是隔离的。Just like with locally redundant storage, zone redundancy gives you three copies of each file, however these copies are physically isolated in three distinct storage clusters in different Azure availability zones. 可用性区域是 Azure 区域中独特的物理位置。Availability zones are unique physical locations within an Azure region. 每个区域由一个或多个数据中心组成,这些数据中心配置了独立电源、冷却和网络。Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. 在将副本写入所有三个可用性区域的存储群集前,不允许将其写入存储。A write to storage is not accepted until it is written to the storage clusters in all three availability zones.
  • 异地冗余:异地冗余存储(通常称为 GRS)类似于本地冗余存储,因为文件在主要区域的 Azure 存储群集内存储三次。Geo-redundant: Geo-redundant storage, often referred to as GRS, is like locally redundant storage, in that a file is stored three times within an Azure storage cluster in the primary region. 所有写入都将异步复制到 Microsoft 定义的次要区域。All writes are then asynchronously replicated to a Microsoft-defined secondary region. 异地冗余存储在两个 Azure 区域之间提供 6 个数据副本。Geo-redundant storage provides 6 copies of your data spread between two Azure regions. 如果发生重大灾难(如由于自然灾害或其他类似事件而导致 Azure 区域永久性丢失),Microsoft 将执行故障转移,使有效的次要区域成为主要区域,为所有操作提供服务。In the event of a major disaster such as the permanent loss of an Azure region due to a natural disaster or other similar event, Microsoft will perform a failover so that the secondary in effect becomes the primary, serving all operations. 由于主要区域和次要区域之间的复制是异步的,因此,在发生重大灾难时,尚未复制到次要区域的数据将会丢失。Since the replication between the primary and secondary regions are asynchronous, in the event of a major disaster, data not yet replicated to the secondary region will be lost. 还可以执行异地冗余存储帐户的手动故障转移。You can also perform a manual failover of a geo-redundant storage account.
  • 异地区域冗余:异地区域冗余存储(通常称为 GZRS)类似于区域冗余存储,因为文件在主要区域的三个不同存储群集内存储三次。Geo-zone redundant: Geo-zone redundant storage, often referred to as GZRS, is like zone redundant storage, in that a file is stored three times across three distinct storage clusters in the primary region. 所有写入都将异步复制到 Microsoft 定义的次要区域。All writes are then asynchronously replicated to a Microsoft-defined secondary region. 异地区域冗余存储的故障转移过程与异地冗余存储的故障转移过程相同。The failover process for geo-zone-redundant storage works the same as it does for geo-redundant storage.

标准 Azure 文件共享支持所有四种冗余类型,而高级 Azure 文件共享仅支持本地冗余存储和区域冗余存储。Standard Azure file shares support all four redundancy types, while premium Azure file shares only support locally redundant and zone redundant storage.

常规用途版本 2 (GPv2) 存储帐户提供了两个 Azure 文件存储不支持的额外冗余选项:可读取访问的异地冗余存储(通常称为 RA-GRS)和可读取访问的异地区域冗余存储(通常称为 RA-GZRS)。General purpose version 2 (GPv2) storage accounts provide two additional redundancy options that are not supported by Azure Files: read accessible geo-redundant storage, often referred to as RA-GRS, and read accessible geo-zone-redundant storage, often referred to as RA-GZRS. 可以在存储帐户中使用这些选项集预配 Azure 文件共享,但 Azure 文件存储不支持从次要区域读取。You can provision Azure file shares in storage accounts with these options set, however Azure Files does not support reading from the secondary region. 部署到可读取访问的异地冗余存储帐户或异地区域冗余存储帐户中的 Azure 文件共享将分别以异地冗余存储或异地区域冗余存储方式计费。Azure file shares deployed into read-accessible geo- or geo-zone redundant storage accounts will be billed as geo-redundant or geo-zone-redundant storage, respectively.

重要

如果使用异地冗余存储和异地区域冗余存储,可以将存储手动故障转移到次要区域。Geo-redundant and Geo-zone redundant storage have the capability to manually failover storage to the secondary region. 当使用 Azure 文件同步时,建议不要在未发生灾难的情况下执行此操作,因为这样会增加数据丢失的可能性。We recommend that you do not do this outside of a disaster when you are using Azure File Sync because of the increased likelihood of data loss. 如果发生了灾难且需要启动对存储的手动故障转移,需要向 Microsoft 开立支持事例,以使 Azure 文件同步能够继续使用辅助终结点进行同步。In the event of a disaster where you would like to initiate a manual failover of storage, you will need to open up a support case with Microsoft to get Azure File Sync to resume sync with the secondary endpoint.

迁移Migration

如果已有 Windows 文件服务器,可以直接就地安装 Azure 文件同步,而无需将数据转移到新服务器。If you have an existing Windows file server, Azure File Sync can be directly installed in place, without the need to move data over to a new server. 如果计划在采用 Azure 文件同步的过程中迁移到新的 Windows 文件服务器,可以使用以下几种方法来移动数据:If you are planning to migrate to a new Windows file server as a part of adopting Azure File Sync, there are several possible approaches to move data over:

  • 为旧文件共享和新文件共享创建服务器终结点,并让 Azure 文件同步在服务器终结点之间同步数据。Create server endpoints for your old file share and your new file share and let Azure File Sync synchronize the data between the server endpoints. 这种方法的优点在于,通过它可以非常轻松地超额订阅新文件服务器上的存储,因为 Azure 文件同步可以感知云分层。The advantage to this approach is that it makes it very easy to oversubscribe the storage on your new file server, since Azure File Sync is cloud tiering aware. 准备就绪后,可以将最终用户转换为使用新服务器上的文件共享,并删除旧文件共享的服务器终结点。When you are ready, you can cut over end users to the file share on the new server and remove the old file share's server endpoint.

  • 仅在新文件服务器上创建服务器终结点,并使用 robocopy 将旧文件共享中的数据复制到其中。Create a server endpoint only on the new file server, and copy data into from the old file share using robocopy. 根据新服务器上文件共享的拓扑(每个卷上有多少共享空间,每个卷上有多少可用空间等),可能需要临时预配额外的存储空间,因为预期在本地数据中心内从旧服务器 robocopy 到新服务器的速度要快于 Azure 文件同步将数据移动到 Azure 的速度。Depending on the topology of file shares on your new server (how many shares you have on each volume, how free each volume is, etc.), you may need to temporarily provision additional storage as it is expected that robocopy from your old server to your new server within your on-premises datacenter will complete faster than Azure File Sync will move data into Azure.

还可以使用 Data Box 将数据迁移到 Azure 文件同步部署。It is also possible to use Data Box to migrate data into an Azure File Sync deployment. 大多数情况下,当客户想使用 Data Box 引入数据时,他们会这样做,因为他们认为这样会提高部署的速度,或者因为这样做有助于实施带宽受限的方案。Most of the time, when customers want to use Data Box to ingest data, they do so because they think it will increase the speed of their deployment or because it will help with constrained bandwidth scenarios. 尽管使用 Data Box 将数据引入到 Azure 文件同步部署中会降低带宽利用率,但大多数情况下,使用上述方法之一来实现联机数据上传可能会更快。While it's true that using a Data Box to ingest data into your Azure File Sync deployment will decrease bandwidth utilization, it will likely be faster for most scenarios to pursue an online data upload through one of the methods described above. 若要详细了解如何使用 Data Box 将数据引入 Azure 文件同步部署,请参阅使用 Azure Data Box 将数据迁移到 Azure 文件同步To learn more about how to use Data Box to ingest data into your Azure File Sync deployment, see Migrate data into Azure File Sync with Azure Data Box.

客户在将数据迁移到新的 Azure 文件同步部署时常犯的一个错误是直接将数据复制到 Azure 文件共享,而不是复制到其 Windows 文件服务器上。A common mistake customers make when migrating data into their new Azure File Sync deployment is to copy data directly into the Azure file share, rather than on their Windows file servers. 尽管 Azure 文件同步会标识 Azure 文件共享上的所有新文件,并将它们同步回 Windows 文件共享,但这通常比通过 Windows 文件服务器加载数据的速度要慢得多。Although Azure File Sync will identify all of the new files on the Azure file share, and sync them back to your Windows file shares, this is generally considerably slower than loading data through the Windows file server. 使用 Azure 复制工具(如 AzCopy)时,请务必使用最新版本。When using Azure copy tools, such as AzCopy, it is important to use the latest version. 检查 " 文件复制工具" 表 以获取 Azure copy 工具的概述,以确保可以复制文件的所有重要元数据,例如时间戳和 acl。Check the file copy tools table to get an overview of Azure copy tools to ensure you can copy all of the important metadata of a file such as timestamps and ACLs.

防病毒Antivirus

由于防病毒通过扫描文件中的已知恶意代码进行工作,因此防病毒产品可能导致重新调用分层文件,从而导致大量出口费用。Because antivirus works by scanning files for known malicious code, an antivirus product might cause the recall of tiered files, resulting in high egress charges. 在 Azure 文件同步代理 4.0 及更高版本中,分层文件已设置安全 Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS。In versions 4.0 and above of the Azure File Sync agent, tiered files have the secure Windows attribute FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS set. 我们建议你咨询软件供应商,以了解如何配置其解决方案以跳过读取已设置此属性的文件(许多解决方案会自动执行此操作)。We recommend consulting with your software vendor to learn how to configure their solution to skip reading files with this attribute set (many do it automatically).

Microsoft 的内部防病毒解决方案 Windows Defender 和 System Center Endpoint Protection (SCEP) 都会自动跳过读取设有此属性的文件。Microsoft's in-house antivirus solutions, Windows Defender and System Center Endpoint Protection (SCEP), both automatically skip reading files that have this attribute set. 我们已对这两个解决方案进行了测试并发现了一个小问题:向现有的同步组添加服务器时,在新服务器上会重新调用(下载)小于 800 字节的文件。We have tested them and identified one minor issue: when you add a server to an existing sync group, files smaller than 800 bytes are recalled (downloaded) on the new server. 这些文件将保留在新服务器上并且不会分层,因为它们不符合分层大小要求 (> 64kb)。These files will remain on the new server and will not be tiered since they do not meet the tiering size requirement (>64kb).

备注

防病毒供应商可以使用 Azure 文件同步防病毒兼容性测试套件(可从 Microsoft 下载中心下载)来检查其产品与 Azure 文件同步的兼容性。Antivirus vendors can check compatibility between their product and Azure File Sync using the Azure File Sync Antivirus Compatibility Test Suite, which is available for download on the Microsoft Download Center.

备份Backup

如果启用了云分层,则不应使用直接备份服务器终结点的解决方案或服务器终结点所在的 VM。If cloud tiering is enabled, solutions that directly back up the server endpoint or a VM on which the server endpoint is located should not be used. 云分层仅导致在服务器终结点上存储数据的一个子集,并将完整的数据集驻留在 Azure 文件共享中。Cloud tiering causes only a subset of your data to be stored on the server endpoint, with the full dataset residing in your Azure file share. 根据所使用的备份解决方案,将跳过或不备份分层文件 (因为它们 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 属性集) ,或者它们将被召回到磁盘,导致大量出口费用。Depending on the backup solution used, tiered files will either be skipped and not backed up (because they have the FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attribute set), or they will be recalled to disk, resulting in high egress charges. 建议使用云备份解决方案直接备份 Azure 文件共享。We recommend using a cloud backup solution to back up the Azure file share directly. 有关详细信息,请参阅 关于 azure 文件共享备份 或与备份提供商联系,查看他们是否支持备份 Azure 文件共享。For more information, see About Azure file share backup or contact your backup provider to see if they support backing up Azure file shares.

如果希望使用本地备份解决方案,则应在禁用云分层的同步组中的服务器上执行备份。If you prefer to use an on-premises backup solution, backups should be performed on a server in the sync group that has cloud tiering disabled. 执行还原时,使用卷级别或文件级还原选项。When performing a restore, use the volume-level or file-level restore options. 使用文件级别还原选项还原的文件将同步到同步组中的所有终结点,现有文件将被替换为从备份还原的版本。Files restored using the file-level restore option will be synced to all endpoints in the sync group and existing files will be replaced with the version restored from backup. 卷级别的还原不会替换 Azure 文件共享或其他服务器终结点中较新的文件版本。Volume-level restores will not replace newer file versions in the Azure file share or other server endpoints.

备注

祼机 (BMR) 还原可能会导致意外的结果且当前不受支持。Bare-metal (BMR) restore can cause unexpected results and is not currently supported.

备注

如果使用 Azure 文件同步代理版本 9,启用了云分层的卷上现在支持 VSS 快照(包括“以前的版本”选项卡)。With Version 9 of the Azure File Sync agent, VSS snapshots (including Previous Versions tab) are now supported on volumes which have cloud tiering enabled. 但是,必须通过 PowerShell 实现以前版本的兼容性。However, you must enable previous version compatibility through PowerShell. 了解操作方法Learn how.

Azure 文件同步代理更新策略Azure File Sync agent update policy

Azure 文件同步代理将定期更新,以便添加新功能和解决问题。The Azure File Sync agent is updated on a regular basis to add new functionality and to address issues. 建议配置 Microsoft 更新,以便在 Azure 文件同步代理更新发布时获得这些更新。We recommend you configure Microsoft Update to get updates for the Azure File Sync agent as they're available.

主要与次要代理版本Major vs. minor agent versions

  • 主要代理版本通常包含新的功能,并且版本号的第一个组成部分会递增。Major agent versions often contain new features and have an increasing number as the first part of the version number. 例如:*2.*.**For example: *2.*.**
  • 次要代理版本也称为“修补”,其发布频率高于主要版本。Minor agent versions are also called "patches" and are released more frequently than major versions. 它们通常包含 bug 修复和小幅的改进,但不包含新功能。They often contain bug fixes and smaller improvements but no new features. 例如:**.3.**For example: **.3.**

升级路径Upgrade paths

可以通过四种经过批准和测试的方法来安装 Azure 文件同步代理更新。There are four approved and tested ways to install the Azure File Sync agent updates.

  1. (首选)将 Microsoft 更新配置为自动下载并安装代理更新。(Preferred) Configure Microsoft Update to automatically download and install agent updates.
    我们始终建议安装每项 Azure 文件同步更新,确保能够访问服务器代理的最新修补程序。We always recommend taking every Azure File Sync update to ensure you have access to the latest fixes for the server agent. Microsoft 更新会自动下载并安装这些更新,以无缝完成此过程。Microsoft Update makes this process seamless, by automatically downloading and installing updates for you.
  2. 使用 AfsUpdater.exe 下载并安装代理更新。Use AfsUpdater.exe to download and install agent updates.
    AfsUpdater.exe 位于代理安装目录中。The AfsUpdater.exe is located in the agent installation directory. 双击可执行文件可下载并安装代理更新。Double-click the executable to download and install agent updates.
  3. 使用 Microsoft 更新修补程序文件或 .msp 可执行文件修补现有 Azure 文件同步代理。可以从 Microsoft 更新目录下载最新的 Azure 文件同步更新包。Patch an existing Azure File Sync agent by using a Microsoft Update patch file, or a .msp executable. The latest Azure File Sync update package can be downloaded from the Microsoft Update Catalog.
    运行 .msp 可执行文件将会升级 Azure 文件同步安装,所用的方法与上述升级路径中 Microsoft 更新使用的自动方法相同。Running a .msp executable will upgrade your Azure File Sync installation with the same method used automatically by Microsoft Update in the previous upgrade path. 应用 Microsoft 更新修补程序会就地升级 Azure 文件同步安装。Applying a Microsoft Update patch will perform an in-place upgrade of an Azure File Sync installation.
  4. Microsoft 下载中心下载最新的 Azure 文件同步 agent 安装程序。Download the newest Azure File Sync agent installer from the Microsoft Download Center.
    若要升级现有的 Azure 文件同步代理安装,请卸载旧版本,然后使用下载的安装程序安装最新版本。To upgrade an existing Azure File Sync agent installation, uninstall the older version and then install the latest version from the downloaded installer. 服务器注册、同步组和其他任何设置由 Azure 文件同步安装程序维护。The server registration, sync groups, and any other settings are maintained by the Azure File Sync installer.

自动代理生命周期管理Automatic agent lifecycle management

使用代理版本6,文件同步团队引入了一个代理自动升级功能。With agent version 6, the file sync team has introduced an agent auto-upgrade feature. 你可以选择两种模式之一,并指定要在其上尝试在服务器上进行升级的维护时段。You can select either of two modes and specify a maintenance window in which the upgrade shall be attempted on the server. 此功能旨在帮助你实现代理生命周期管理,方法是提供一个 guardrail,以防止代理过期或允许无障碍,并保持最新的设置。This feature is designed to help you with the agent lifecycle management by either providing a guardrail preventing your agent from expiration or allowing for a no-hassle, stay current setting.

  1. 默认设置将尝试防止代理过期。The default setting will attempt to prevent the agent from expiration. 在代理的发布到期日期21天内,代理将尝试自行升级。Within 21 days of the posted expiration date of an agent, the agent will attempt to self-upgrade. 它将在过期之前的21天内,一周内开始升级一次,并在选定的维护时段内升级一次。It will start an attempt to upgrade once a week within 21 days prior to expiration and in the selected maintenance window. 此选项不会消除定期 Microsoft 更新修补程序的需求。This option does not eliminate the need for taking regular Microsoft Update patches.
  2. 或者,你可以选择在新的代理版本可用 (当前不适用于) 的群集服务器时,代理将自动自动升级。Optionally, you can select that the agent will automatically upgrade itself as soon as a new agent version becomes available (currently not applicable to clustered servers). 此更新将在选定的维护时段内发生,并使你的服务器能够在公开发布后立即受益于新功能和改进。This update will occur during the selected maintenance window and allow your server to benefit from new features and improvements as soon as they become generally available. 这是建议的无需担心的设置,它将为你的服务器提供主要代理版本以及定期更新修补程序。This is the recommended, worry-free setting that will provide major agent versions as well as regular update patches to your server. 每个发布的代理都处于 GA 质量。Every agent released is at GA quality. 如果选择此选项,Microsoft 将向你飞行最新的代理版本。If you select this option, Microsoft will flight the newest agent version to you. 排除群集服务器。Clustered servers are excluded. 试验完成后,代理也将在 Microsoft 下载中心 aka.ms/AFS/agent 上变为可用。Once flighting is complete, the agent will also become available on Microsoft Download Center aka.ms/AFS/agent.
更改自动升级设置Changing the auto-upgrade setting

以下说明介绍了在完成安装程序后如何更改设置(如果需要进行更改)。The following instructions describe how to change the settings after you've completed the installer, if you need to make changes.

打开 PowerShell 控制台,导航到在其中安装了同步代理的目录,然后导入服务器 cmdlet。Open a PowerShell console and navigate to the directory where you installed the sync agent then import the server cmdlets. 默认情况下,如下所示:By default this would look something like this:

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

您可以运行 Get-StorageSyncAgentAutoUpdatePolicy 来检查当前策略设置并确定是否要对其进行更改。You can run Get-StorageSyncAgentAutoUpdatePolicy to check the current policy setting and determine if you want to change it.

若要将当前策略设置更改为延迟更新跟踪,你可以使用:To change the current policy setting to the delayed update track, you can use:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

若要将当前策略设置更改为立即更新跟踪,你可以使用:To change the current policy setting to the immediate update track, you can use:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

代理生命周期和变更管理保证Agent lifecycle and change management guarantees

Azure 文件同步是一种云服务,它持续引入新功能和改进。Azure File Sync is a cloud service, which continuously introduces new features and improvements. 这意味着,特定的 Azure 文件同步代理版本只在有限的时间内受到支持。This means that a specific Azure File Sync agent version can only be supported for a limited time. 为了便于部署,以下规则确保你有足够的时间和通知,以便在你的更改管理过程中适应代理更新/升级:To facilitate your deployment, the following rules guarantee you have enough time and notification to accommodate agent updates/upgrades in your change management process:

  • 至少支持主要代理版本六个月(从初始版本发布日期算起)。Major agent versions are supported for at least six months from the date of initial release.
  • 我们保证至少提供三个月的缓冲期来支持不同的主要代理版本。We guarantee there is an overlap of at least three months between the support of major agent versions.
  • 在代理过期之前的至少三个月,我们会在已注册的服务器中使用代理即将过期消息来发出警告。Warnings are issued for registered servers using a soon-to-be expired agent at least three months prior to expiration. 可以在存储同步服务的“已注册服务器”部分下检查已注册的服务器是否在使用旧版代理。You can check if a registered server is using an older version of the agent under the registered servers section of a Storage Sync Service.
  • 次要代理版本的生存期受限于相关的主要版本。The lifetime of a minor agent version is bound to the associated major version. 例如,发布代理版本 3.0 后,代理版本 2.* 将设置为一起过期。For example, when agent version 3.0 is released, agent versions 2.* will all be set to expire together.

备注

安装附带过期警告的代理版本时会显示警告,但安装会成功。Installing an agent version with an expiration warning will display a warning but succeed. 不支持且会阻止安装或连接已过期的代理版本。Attempting to install or connect with an expired agent version is not supported and will be blocked.

后续步骤Next steps