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

使用 Azure 文件同步从网络附加存储迁移 (NAS) 到混合云部署Migrate from Network Attached Storage (NAS) to a hybrid cloud deployment with Azure File Sync

Azure 文件同步适用于直接附加存储 (DAS) 位置,并且不支持 (NAS) 位置同步到网络连接存储。Azure File Sync works on Direct Attached Storage (DAS) locations and does not support sync to Network Attached Storage (NAS) locations. 这种情况会迁移你需要的文件,本文将指导你完成此类迁移的计划和执行。This fact makes a migration of your files necessary and this article guides you through the planning and execution of such a migration.

迁移目标Migration goals

目标是将你在 NAS 设备上的共享移动到 Windows 服务器。The goal is to move the shares that you have on your NAS appliance to a Windows Server. 然后利用混合云部署的 Azure 文件同步。Then utilize Azure File Sync for a hybrid cloud deployment. 此迁移需要在迁移期间保证生产数据的完整性和可用性的方式进行。This migration needs to be done in a way that guarantees the integrity of the production data as well as availability during the migration. 后者需要将停机时间保持在最少,使其适应或仅略超过定期维护时段。The latter requires keeping downtime to a minimum, so that it can fit into or only slightly exceed regular maintenance windows.

迁移概述Migration overview

如 Azure 文件 迁移概述一文中所述,使用正确的复制工具和方法非常重要。As mentioned in the Azure Files migration overview article, using the correct copy tool and approach is important. 你的 NAS 设备直接在本地网络上公开 SMB 共享。Your NAS appliance is exposing SMB shares directly on your local network. RoboCopy (内置于 Windows Server)是在此迁移方案中移动文件的最佳方式。RoboCopy, built-into Windows Server, is the best way to move your files in this migration scenario.

阶段1:确定需要多少个 Azure 文件共享Phase 1: Identify how many Azure file shares you need

在此步骤中,你将评估你需要多少个 Azure 文件共享。In this step, you're evaluating how many Azure file shares you need. 单个 Windows Server 实例 (或群集) 可以同步最多30个 Azure 文件共享。A single Windows Server instance (or cluster) can sync up to 30 Azure file shares.

你的卷上可能有更多文件夹在本地作为 SMB 共享本地共享到用户和应用。You might have more folders on your volumes that you currently share out locally as SMB shares to your users and apps. 若要解决此问题,最简单的方法是构想将1:1 映射到 Azure 文件共享的本地共享。The easiest way to picture this scenario is to envision an on-premises share that maps 1:1 to an Azure file share. 如果你的数字足够小,则对于单个 Windows Server 实例低于30,我们建议使用1:1 映射。If you have a small enough number, below 30 for a single Windows Server instance, we recommend a 1:1 mapping.

如果共享超过30个,通常不需要将本地共享1:1 映射到 Azure 文件共享。If you have more shares than 30, it's often unnecessary to map an on-premises share 1:1 to an Azure file share. 请考虑以下选项。Consider the following options.

共享分组Share grouping

例如,如果人力资源 (人事) 部门总共有15个共享,则可以考虑将所有 HR 数据存储在一个 Azure 文件共享中。For example, if your human resources (HR) department has a total of 15 shares, you might consider storing all of the HR data in a single Azure file share. 如果将多个本地共享存储在一个 Azure 文件共享中,则不会阻止你在本地 Windows Server 实例上创建常见的15个 SMB 共享。Storing multiple on-premises shares in one Azure file share doesn't prevent you from creating the usual 15 SMB shares on your local Windows Server instance. 这只意味着将这些15个共享的根文件夹组织为公用文件夹下的子文件夹。It only means that you organize the root folders of these 15 shares as subfolders under a common folder. 然后,将此公用文件夹同步到 Azure 文件共享。You then sync this common folder to an Azure file share. 这样一来,就只需要将云中的单个 Azure 文件共享用于此组本地共享。That way, only a single Azure file share in the cloud is needed for this group of on-premises shares.

卷同步Volume sync

Azure 文件同步支持将卷的根同步到 Azure 文件共享。Azure File Sync supports syncing the root of a volume to an Azure file share. 如果同步根文件夹,则所有子文件夹和文件都将发送到相同的 Azure 文件共享。If you sync the root folder, all subfolders and files will go to the same Azure file share.

同步卷的根目录并非总是最好的答案。Syncing the root of the volume isn't always the best answer. 同步多个位置有一些好处。There are benefits in syncing multiple locations. 例如,这样做有助于使每个同步作用域的项数保持较低。For example, doing so helps keep the number of items lower per sync scope. 尽管我们使用100000000项来测试 Azure 文件共享和 Azure 文件同步 (文件和文件夹) 每个共享,最佳做法是尝试在单个共享中保留低于20000000或30000000的数字。While we test Azure file shares and Azure File Sync with 100 million items (files and folders) per share, a best practice is to try to keep the number below 20 million or 30 million in a single share. 使用较少数量的项目设置 Azure 文件同步不仅对文件同步有利。项目数量越少,还会受益于以下方案:Setting up Azure File Sync with a lower number of items isn't only beneficial for file sync. A lower number of items also benefits scenarios like these:

  • 在命名空间开始出现在已启用 Azure 文件同步的服务器上之前,初始扫描云内容可以更快地完成。Initial scan of the cloud content before the namespace can start to appear on an Azure File Sync-enabled server can complete faster.
  • 从 Azure 文件共享快照进行云端还原将会更快。Cloud-side restore from an Azure file share snapshot will be faster.
  • 本地服务器的灾难恢复可以显著提高速度。Disaster recovery of an on-premises server can speed up significantly.
  • 在 Azure 文件共享中直接进行的更改 (可以检测到外部同步) 并能更快地同步。Changes made directly in an Azure file share (outside sync) can be detected and synced faster.

提示

如果你不确定有多少文件和文件夹,请查看 Database 工具的卡纸软件 GmbH。If you're unsure how many files and folders you have, check out the TreeSize tool from JAM Software GmbH.

部署映射的结构化方法A structured approach to a deployment map

在稍后的步骤中部署云存储之前,请务必在本地文件夹和 Azure 文件共享之间创建映射。Before you deploy cloud storage in a later step, it's important to create a map between on-premises folders and Azure file shares. 然后,此映射会通知要预配多少个 Azure 文件同步 同步组 资源。This mapping will then inform how many and which Azure File Sync sync group resources you'll provision. 同步组会将服务器上的 Azure 文件共享和文件夹连接在一起,并建立同步连接。A sync group ties the Azure file share and the folder on your server together and establishes a sync connection.

若要确定需要多少个 Azure 文件共享,请查看以下限制和最佳实践。To make the decision about how many Azure file shares you need, review the following limits and best practices. 这样做有助于优化地图。Doing so will help you optimize your map.

  • 安装了 Azure 文件同步代理的服务器可与最多30个 Azure 文件共享同步。A server with the Azure File Sync agent installed can sync with up to 30 Azure file shares.

  • Azure 文件共享部署在存储帐户中。An Azure file share is deployed inside a storage account. 这会使存储帐户成为性能数字(如 IOPS 和吞吐量)的缩放目标。That makes the storage account a scale target for performance numbers such as IOPS and throughput.

    两个标准 (不是高级) Azure 文件共享理论上可以在存储帐户可提供的最大性能上饱和。Two standard (not premium) Azure file shares can theoretically saturate the maximum performance that a storage account can deliver. 如果你计划仅将 Azure 文件同步附加到这些文件共享,则将多个 Azure 文件共享分组到相同的存储帐户不会产生问题。If you plan to only attach Azure File Sync to these file shares, grouping several Azure file shares into the same storage account won't create a problem. 查看 Azure 文件共享性能目标,深入了解要考虑的相关指标。Review the Azure file share performance targets for deeper insight into the relevant metrics to consider.

    如果你计划将应用程序提升到 Azure,以便在本地使用 Azure 文件共享,则你可能需要从 Azure 文件共享获得更高的性能。If you plan on lifting an app to Azure that will use the Azure file share natively, you might need more performance from your Azure file share. 如果这种类型的使用是一种可能的情况,则在将来的情况下,最好将 Azure 文件共享映射到其自己的存储帐户。If this type of use is a possibility, even in the future, then mapping an Azure file share to its own storage account is best.

  • 单个 Azure 区域中,每个订阅的存储帐户数限制为250。There's a limit of 250 storage accounts per subscription in a single Azure region.

提示

考虑到此信息,通常需要将卷上的多个顶级文件夹分组到一个公用的新根目录中。With this information in mind, it often becomes necessary to group multiple top-level folders on your volumes into a common, new root directory. 然后,将这个新的根目录以及您分组到其中的所有文件夹同步到单个 Azure 文件共享。You then sync this new root directory, and all the folders you grouped into it, to a single Azure file share. 此方法允许你在每台服务器30个 Azure 文件共享同步的限制范围内保持不变。This technique allows you to stay within the limit of 30 Azure file share syncs per server.

在公用根下进行此分组不会对数据访问产生任何影响。This grouping under a common root has no impact on access to your data. 你的 Acl 保持原样。Your ACLs stay as is. 只需调整 SMB 或 NFS 共享所 (的任何共享路径) 你可能已将服务器文件夹更改为公用根目录。You would only need to adjust any share paths (like SMB or NFS shares) you might have on the server folders that you now changed into a common root. 无其他更改。Nothing else changes.

重要

Azure 文件同步的最重要缩放矢量是需要同步 (文件和文件夹) 的项目数。The most important scale vector for Azure File Sync is the number of items (files and folders) that need to be synchronized.

Azure 文件同步最多支持将100000000项同步到单个 Azure 文件共享。Azure File Sync supports syncing up to 100 million items to a single Azure file share. 此限制可能会超出,并仅显示 Azure 文件同步团队定期测试的内容。This limit can be exceeded and only shows what the Azure File Sync team tests on a regular basis.

最佳做法是保持每个同步范围内的项的数目较低。It's a best practice to keep the number of items per sync scope low. 这是在将文件夹映射到 Azure 文件共享时要考虑的重要因素。That's an important factor to consider in your mapping of folders to Azure file shares. 尽管我们使用100000000项来测试 Azure 文件共享和 Azure 文件同步 (文件和文件夹) 每个共享,最佳做法是尝试在单个共享中保留低于20000000或30000000的数字。While we test Azure file shares and Azure File Sync with 100 million items (files and folders) per share, a best practice is to try to keep the number below 20 million or 30 million in a single share. 如果开始超过这些数字,请将命名空间拆分为多个共享。Split your namespace into multiple shares if you start to exceed these numbers. 如果你一直在这两个数字下面,你可以继续将多个本地共享组合到同一个 Azure 文件共享中。You can continue to group multiple on-premises shares into the same Azure file share if you stay roughly below these numbers. 这种做法将为你提供增加空间。This practice will provide you with room to grow.

在这种情况下,可以使用) 前面所述的新的通用根文件夹方法,以逻辑方式将一组文件夹同步到相同的 Azure 文件共享 (。In your situation, it's possible that a set of folders can logically sync to the same Azure file share (using the new, common root folder approach mentioned earlier). 但最好是重新组合文件夹,使它们同步到两个(而不是一个) Azure 文件共享。But it might still be better to regroup folders such that they sync to two instead of one Azure file share. 您可以使用此方法来使每个文件共享的文件和文件夹数在服务器之间保持平衡。You can use this approach to keep the number of files and folders per file share balanced across the server.

创建映射表Create a mapping table

映射表的示例。下载以下文件以体验并使用此映像的内容。An example of a mapping table. Download the following file to experience and use the content of this image.

结合使用前面的概念来帮助确定所需的 Azure 文件共享的数量,以及现有数据的哪些部分最终会在哪个 Azure 文件共享位置结束。Use a combination of the previous concepts to help determine how many Azure file shares you need, and which parts of your existing data will end up in which Azure file share.

创建记录你的想法的表,以便可以在需要时对其进行引用。Create a table that records your thoughts so you can refer to it when needed. 保持井然有序非常重要,因为当你同时预配许多 Azure 资源时,可能会很容易丢失映射计划的详细信息。Staying organized is important because it can be easy to lose details of your mapping plan when you're provisioning many Azure resources at once. 为了帮助你创建完整的映射,你可以下载 Microsoft Excel 文件作为模板。To help you create a complete mapping, you can download a Microsoft Excel file as a template.


Microsoft Excel file icon that helps to set the context for the type of file download for the link next to it. 下载命名空间映射模板。 Download a namespace-mapping template.

阶段2:在本地预配适用于 Windows Server 的 Windows ServerPhase 2: Provision a suitable Windows Server on-premises

  • 创建 Windows Server 2019-以最小2012R2 为虚拟机或物理服务器。Create a Windows Server 2019 - at a minimum 2012R2 - as a virtual machine or physical server. 还支持 Windows Server 故障转移群集。A Windows Server fail-over cluster is also supported.

  • 与 NAS 相比,预配或添加直接附加存储 (DAS,这在) 不受支持。Provision or add Direct Attached Storage (DAS as compared to NAS, which is not supported).

    如果使用 Azure 文件同步 云分层 功能,预配的存储量可能会小于你当前在 NAS 设备上使用的存储量。The amount of storage you provision can be smaller than what you are currently using on your NAS appliance, if you use Azure File Syncs cloud tiering feature. 但是,当你将文件从较大的 NAS 空间复制到较小的 Windows 服务器卷时,你将需要批量工作:However, when you copy your files from the larger NAS space to the smaller Windows Server volume in a later phase, you will need to work in batches:

    1. 移动一组容纳在磁盘上的文件Move a set of files that fits onto the disk
    2. 允许文件同步和云分层let file sync and cloud tiering engage
    3. 在卷上创建更多可用空间时,请继续执行下一批文件。when more free space is created on the volume, proceed with the next batch of files.

    可以通过在 NAS 设备上设置文件所占用的 Windows Server 上的等效空间来避免这种批处理方法。You can avoid this batching approach by provisioning the equivalent space on the Windows Server that your files occupy on the NAS appliance. 考虑在 NAS/Windows 上进行重复数据删除。Consider deduplication on NAS / Windows. 如果你不想将此大量存储永久提交给 Windows Server,可以在迁移后和调整云分层策略之前减小卷大小。If you don't want to permanently commit this high amount of storage to your Windows Server, you can reduce the volume size after the migration and before adjusting the cloud tiering policies. 这会创建更小的 Azure 文件共享本地缓存。That creates a smaller on-premises cache of your Azure file shares.

部署的 Windows Server (计算和 RAM) 的资源配置主要取决于要同步) (文件和文件夹的项数。The resource configuration (compute and RAM) of the Windows Server you deploy depends mostly on the number of items (files and folders) you will be syncing. 如果有任何问题,建议采用更高的性能配置。We recommend going with a higher performance configuration if you have any concerns.

了解如何根据需要同步) (文件和文件夹的项数调整 Windows Server 的大小。Learn how to size a Windows Server based on the number of items (files and folders) you need to sync.

备注

之前链接的文章显示了一个表,其中包含服务器内存 (RAM) 的范围。The previously linked article presents a table with a range for server memory (RAM). 你可以为服务器的更小数量方向,但会预计初始同步可能需要更长时间。You can orient towards the smaller number for your server but expect that initial sync can take significantly more time.

阶段3:部署 Azure 文件同步云资源Phase 3: Deploy the Azure File Sync cloud resource

在此步骤中,需要你的 Azure 订阅凭据。In this step, you need your Azure subscription credentials.

要为 Azure 文件同步配置的核心资源称为 存储同步服务The core resource to configure for Azure File Sync is called a Storage Sync Service . 建议只为当前或将来同步同一组文件的所有服务器部署一个服务器。We recommend that you deploy only one for all servers that are syncing the same set of files now or in the future. 仅当你有不同的服务器集,而这些服务器必须永不交换数据时,才创建多个存储同步服务。Create multiple Storage Sync Services only if you have distinct sets of servers that must never exchange data. 例如,你可能有一些服务器必须从不同步同一个 Azure 文件共享。For example, you might have servers that must never sync the same Azure file share. 否则,单个存储同步服务是最佳实践。Otherwise, a single Storage Sync Service is the best practice.

选择与你所在位置接近的存储同步服务的 Azure 区域。Choose an Azure region for your Storage Sync Service that's close to your location. 所有其他云资源必须部署在同一区域中。All other cloud resources must be deployed in the same region. 若要简化管理,请在订阅中创建一个包含同步和存储资源的新资源组。To simplify management, create a new resource group in your subscription that houses sync and storage resources.

有关详细信息,请参阅关于部署 Azure 文件同步一文中 有关部署存储同步服务的部分 。请仅关注本文的这一部分。For more information, see the section about deploying the Storage Sync Service in the article about deploying Azure File Sync. Follow only this part of the article. 稍后的步骤中将提供文章的其他部分的链接。There will be links to other sections of the article in later steps.

阶段4:部署 Azure 存储资源Phase 4: Deploy Azure storage resources

在此阶段中,请参阅阶段1中的映射表,并使用它来设置正确的 Azure 存储帐户和其中的文件共享数。In this phase, consult the mapping table from Phase 1 and use it to provision the correct number of Azure storage accounts and file shares within them.

Azure 文件共享存储在云中的 Azure 存储帐户中。An Azure file share is stored in the cloud in an Azure storage account. 这里有另一个性能注意事项。There's another level of performance considerations here.

如果有高度活跃的共享 (多个用户和/或应用程序) 使用的共享,则两个 Azure 文件共享可能会达到存储帐户的性能限制。If you have highly active shares (shares used by many users and/or applications), then two Azure file shares might reach the performance limit of a storage account.

最佳做法是部署具有一个文件共享的存储帐户。A best practice is to deploy storage accounts with one file share each. 可以将多个 Azure 文件共享共用到相同的存储帐户,以防有存档共享或预计其中的日常活动较低。You can pool multiple Azure file shares into the same storage account, in case you have archival shares or you expect low day-to-day activity in them.

这些注意事项更适用于通过 Azure VM) 直接访问云访问 (,而不是 Azure 文件同步。如果你计划仅在这些共享上使用 Azure 文件同步,则可以将多个组分组到单个 Azure 存储帐户中。These considerations apply more to direct cloud access (through an Azure VM) than to Azure File Sync. If you plan to use Azure File Sync only on these shares, then grouping several into a single Azure storage account is fine.

如果已创建共享列表,则应将每个共享映射到它将驻留的存储帐户。If you've made a list of your shares, you should map each share to the storage account that it will reside in.

在上一阶段中,您确定了适当数量的共享。In the previous phase, you determined the appropriate number of shares. 在此步骤中,您已创建了存储帐户到文件共享的映射。In this step, you have a created a mapping of storage accounts to file shares. 现在,部署适当数量的 azure 存储帐户,其中包含合适数量的 Azure 文件共享。Now deploy the appropriate number of Azure storage accounts with the appropriate number of Azure file shares in them.

请确保每个存储帐户的区域相同,并且与已部署的存储同步服务资源的区域相匹配。Make sure the region of each of your storage accounts is the same and matches the region of the Storage Sync Service resource you've already deployed.

注意

如果创建的 Azure 文件共享的 TiB 限制为100,则该共享只能使用本地冗余存储或区域冗余存储冗余选项。If you create an Azure file share that has a 100-TiB limit, that share can only use locally redundant storage or zone-redundant storage redundancy options. 使用 100-TiB 文件共享之前,请考虑你的存储冗余需求。Consider your storage redundancy needs before using 100-TiB file shares.

默认情况下,默认情况下,将创建具有 5 TiB 限制的 Azure 文件共享。Azure file shares are still created with a 5-TiB limit by default. 由于你要创建新的存储帐户,因此请确保遵循相关 指南来创建允许具有 100 TiB 限制的 Azure 文件共享的存储帐户Because you're creating new storage accounts, make sure to follow the guidance to create storage accounts that allow Azure file shares with 100-TiB limits.

部署存储帐户时的另一个注意事项是 Azure 存储的冗余。Another consideration when you're deploying a storage account is the redundancy of Azure Storage. 请参阅 Azure 存储冗余选项See Azure Storage redundancy options.

资源的名称也很重要。The names of your resources are also important. 例如,如果将 HR 部门的多个共享分组到一个 Azure 存储帐户中,则应适当地命名存储帐户。For example, if you group multiple shares for the HR department into an Azure storage account, you should name the storage account appropriately. 同样,命名 Azure 文件共享时,应使用与用于本地对应项的名称类似的名称。Similarly, when naming your Azure file shares, you should use names similar to the ones used for their on-premises counterparts.

阶段5:部署 Azure 文件同步代理Phase 5: Deploy the Azure File Sync agent

在本部分中,会在 Windows Server 实例上安装 Azure 文件同步代理。In this section, you install the Azure File Sync agent on your Windows Server instance.

部署指南说明了需要关闭 Internet Explorer 增强的安全配置The deployment guide illustrates that you need to turn off Internet Explorer Enhanced Security Configuration . 此安全措施不适用于 Azure 文件同步。关闭后,可以在 Azure 中进行身份验证,而不会出现任何问题。This security measure isn't applicable with Azure File Sync. Turning it off allows you to authenticate to Azure without any issues.

打开 PowerShell,然后使用以下命令安装所需的 PowerShell 模块。Open PowerShell, and install the required PowerShell modules by using the following commands. 请确保在出现提示时安装完整的模块和 NuGet 提供程序。Make sure to install the full module and the NuGet provider when you're prompted.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

如果从服务器进入 internet 时遇到任何问题,现在就可以解决这些问题。If you have any issues reaching the internet from your server, now is the time to solve them. Azure 文件同步使用到 internet 的任何可用网络连接。Azure File Sync uses any available network connection to the internet. 还支持要求代理服务器访问 internet。Requiring a proxy server to reach the internet is also supported. 你可以立即配置计算机范围的代理,也可以指定只有 Azure 文件同步在代理安装过程中将使用的代理。You can either configure a machine-wide proxy now or specify a proxy that only Azure File Sync will use, during agent installation.

如果配置代理,则意味着需要为此服务器打开防火墙,这种方法可能是可以接受的。If configuring a proxy means you need to open your firewalls for this server, that approach might be acceptable to you. 在服务器安装结束时,在完成服务器注册后,网络连接报告将显示 Azure 中的确切终结点 Url,Azure 文件同步需要与所选区域的通信。At the end of the server installation, after you've completed server registration, a network connectivity report will show you the exact endpoint URLs in Azure that Azure File Sync needs to communicate with for the region you've selected. 该报表还会告诉您需要进行通信的原因。The report also tells you the reason why communication is needed. 可以使用报表将此服务器上的防火墙锁定到特定的 Url。You can use the report to lock down the firewalls around this server to specific URLs.

你还可以遵循更保守的方法,在这种情况下,你不会在其中打开防火墙,而是限制服务器与更高级别 DNS 命名空间进行通信。You can also follow a more conservative approach in which you don't open the firewalls wide, but instead limit the server to communicate with higher-level DNS namespaces. 有关详细信息,请参阅 Azure 文件同步代理和防火墙设置For more information, see Azure File Sync proxy and firewall settings. 遵循自己的网络最佳实践。Follow your own networking best practices.

在服务器安装向导结束时,将打开一个服务器注册向导。At the end of the server installation wizard, a server registration wizard will open. 从前面的存储同步服务的 Azure 资源注册服务器。Register the server to your Storage Sync Service's Azure resource from earlier.

部署指南中更详细地介绍了这些步骤,其中包含首先应该安装的 PowerShell 模块: Azure 文件同步代理安装These steps are described in more detail in the deployment guide, which includes the PowerShell modules that you should install first: Azure File Sync agent installation.

使用最新的代理。Use the latest agent. 你可以从 Microsoft 下载中心下载: Azure 文件同步代理You can download it from the Microsoft Download Center: Azure File Sync Agent.

成功安装和服务器注册后,可以检查是否已成功完成此步骤。After a successful installation and server registration, you can check that you've successfully completed this step. 中转到 Azure 门户中的存储同步服务资源。Go to the Storage Sync Service resource in the Azure portal. 在左侧菜单中,请参阅 " 已注册的服务器 "。On the left menu, go to Registered servers . 你将看到你的服务器已在此处列出。You'll see your server listed there.

阶段6:在 Windows Server 上配置 Azure 文件同步Phase 6: Configure Azure File Sync on the Windows Server

已注册的本地 Windows 服务器必须已准备就绪,并且已连接到 internet 以执行此过程。Your registered on-premises Windows Server must be ready and connected to the internet for this process.

此步骤将在前面的步骤中设置在 Windows Server 实例上的所有资源和文件夹结合在一起。This step ties together all resources and folders you've set up on your Windows Server instance during the previous steps.

  1. 登录 Azure 门户Sign in to the Azure portal.
  2. 找到你的存储同步服务资源。Locate your Storage Sync Service resource.
  3. 在每个 Azure 文件共享的存储同步服务资源中创建新的 同步组Create a new sync group within the Storage Sync Service resource for each Azure file share. 在 Azure 文件同步术语中,Azure 文件共享将成为同步拓扑中的一个 云终结点,该终结点 是你在创建同步组时所描述的。In Azure File Sync terminology, the Azure file share will become a cloud endpoint in the sync topology that you're describing with the creation of a sync group. 创建同步组时,请为它提供一个熟悉的名称,以便在此处识别要同步的文件集。As you're creating the sync group, give it a familiar name so that you recognize which set of files syncs here. 请确保引用具有匹配名称的 Azure 文件共享。Make sure you reference the Azure file share with a matching name.
  4. 创建同步组后,该同步组的行会出现在同步组列表中。After the sync group is created, a row for it will appear in the list of sync groups. 选择链接) (的名称以显示同步组的内容。Select the name (a link) to display the contents of the sync group. 你将在 云终结点 下看到你的 Azure 文件共享。You'll see your Azure file share under Cloud endpoints .
  5. 找到 " + 添加服务器终结点 " 按钮。Locate the + Add Server Endpoint button. 你预配的本地服务器上的文件夹将成为此 服务器终结点 的路径。The folder on the local server that you've provisioned will become the path for this server endpoint .

重要

云分层是一项 AFS 功能,它使本地服务器的存储容量比存储在云中的存储容量少,同时还提供完整的命名空间。Cloud tiering is the AFS feature that allows the local server to have less storage capacity than is stored in the cloud, yet have the full namespace available. 本地关注的数据也会在本地缓存以实现快速访问性能。Locally interesting data is also cached locally for fast access performance. 云分层是每个 Azure 文件同步 "服务器终结点" 的一项可选功能。Cloud tiering is an optional feature per Azure File Sync "server endpoint".

警告

如果在 Windows server 卷上预配的存储空间小于在 NAS 设备上使用的数据,则必须使用云分层) (。If you provisioned less storage on your Windows server volume(s) than your data used on the NAS appliance, then cloud tiering is mandatory. 如果未启用云分层,服务器将不会释放空间来存储所有文件。If you do not turn on cloud tiering, your server will not free up space to store all files. 将你的分层策略设置为临时迁移到99% 卷可用空间。Set your tiering policy, temporarily for the migration, to 99% volume free space. 请确保在迁移完成后返回到云分层设置,并将其设置为更长期的有用级别。Be sure to return to your cloud tiering settings after the migration is complete, and set it to a more long-term useful level.

为需要配置为进行同步的所有 Azure 文件共享/服务器位置重复创建同步组并添加匹配的服务器文件夹作为服务器终结点的步骤。Repeat the steps of sync group creation and addition of the matching server folder as a server endpoint for all Azure file shares / server locations, that need to be configured for sync.

创建所有服务器终结点后,同步将正常运行。After the creation of all server endpoints, sync is working. 你可以创建一个测试文件,并查看它是否从服务器位置同步到连接的 Azure 文件共享 (如同步组中的云终结点) 所述。You can create a test file and see it sync up from your server location to the connected Azure file share (as described by the cloud endpoint in the sync group).

在这两个位置中,服务器文件夹和 Azure 文件共享都为空,并在任一位置等待数据。Both locations, the server folders and the Azure file shares are otherwise empty and awaiting data in either location. 在下一步中,你将开始将文件复制到 Windows Server,以便 Azure 文件同步将它们移到云中。In the next step, you will begin to copy files into the Windows Server for Azure File Sync to move them up to the cloud. 如果已启用云分层,则服务器将开始对文件进行分层,以确定本地卷 () 上的容量不足。In case you've enabled cloud tiering, the server will then begin to tier files, should you run out of capacity on the local volume(s).

阶段7: RoboCopyPhase 7: RoboCopy

基本迁移方法是从 NAS 设备到 Windows Server 的 RoboCopy,并 Azure 文件同步到 Azure 文件共享。The basic migration approach is a RoboCopy from your NAS appliance to your Windows Server, and Azure File Sync to Azure file shares.

运行 Windows Server 目标文件夹的第一个本地副本:Run the first local copy to your Windows Server target folder:

  • 确定 NAS 设备上的第一个位置。Identify the first location on your NAS appliance.
  • 标识已在 Windows Server 上配置了 Azure 文件同步的匹配文件夹。Identify the matching folder on the Windows Server, that already has Azure File Sync configured on it.
  • 使用 RoboCopy 开始复制Start the copy using RoboCopy

以下 RoboCopy 命令会将文件从 NAS 存储复制到 Windows Server 目标文件夹。The following RoboCopy command will copy files from your NAS storage to your Windows Server target folder. Windows Server 会将其同步到 Azure 文件共享 (s) 。The Windows Server will sync it to the Azure file share(s).

如果在 Windows Server 上预配的存储空间少于 NAS 设备上的文件占用的存储空间,则已配置云分层。If you provisioned less storage on your Windows Server than your files take up on the NAS appliance, then you have configured cloud tiering. 当本地 Windows Server 卷已满时, 云分层 将开始,并且已成功同步的层文件已成功同步。As the local Windows Server volume gets full, cloud tiering will kick in and tier files that have successfully synced already. 云分层将生成足够的空间,以便从 NAS 设备继续复制。Cloud tiering will generate enough space to continue the copy from the NAS appliance. 云分层检查一小时以查看已同步的内容,并释放磁盘空间以达到99% 的可用空间。Cloud tiering checks once an hour to see what has synced and to free up disk space to reach the 99% volume free space. 此 RoboCopy 可以更快地移动文件,而不能在本地同步到云和层,从而用尽了本地磁盘空间。It is possible, that RoboCopy moves files faster than you can sync to the cloud and tier locally, thus running out of local disk space. RoboCopy 将失败。RoboCopy will fail. 建议你按阻止该操作的顺序浏览共享。It is recommended that you work through the shares in a sequence that prevents that. 例如,不是同时为所有共享启动 RoboCopy 作业,或者只是在 Windows Server 上移动适合当前可用空间量的共享来提几个。For example, not starting RoboCopy jobs for all shares at the same time, or only moving shares that fit on the current amount of free space on the Windows Server, to mention a few.

Robocopy /MT:32 /UNILOG:<file name> /TEE /B /MIR /COPYALL /DCOPY:DAT <SourcePath> <Dest.Path>

背景色:Background:

/MT/MT

允许 RoboCopy 运行多线程。Allows for RoboCopy to run multi-threaded. 默认值为8,最大值为128。Default is 8, max is 128.

/UNILOG:<file name>/UNILOG:<file name>

将状态作为 UNICODE 输出到日志文件 (覆盖现有日志) 。Outputs status to LOG file as UNICODE (overwrites existing log).

/TEE/TEE

输出到控制台窗口。Outputs to console window. 与输出一起用于日志文件。Used in conjunction with output to a log file.

/B/B

在备份应用程序使用的相同模式下运行 RoboCopy。Runs RoboCopy in the same mode a backup application would use. 它允许 RoboCopy 移动当前用户没有权限的文件。It allows RoboCopy to move files that the current user does not have permissions to.

/MIR/MIR

允许按顺序在同一目标/目标上多次运行此 RoboCopy 命令。Allows to run this RoboCopy command several times, sequentially on the same target / destination. 它标识在之前已复制的内容并将其省略。It identifies what has been copied before and omits it. 仅会处理自上次运行后发生的更改、添加和 删除 操作。Only changes, additions and "deletes" will be processed, that occurred since the last run. 如果命令之前未运行,则不会省略任何内容。If the command wasn't run before, nothing is omitted. 对于仍在使用和变化的源位置, /MIR 标志是一个极佳的选项。The /MIR flag is an excellent option for source locations that are still actively used and changing.

/COPY: copyflag [s]/COPY:copyflag[s]

文件副本的保真度 (默认值为/COPY: DAT) 、复制标志: D = 数据、A = 属性、T = 时间戳、S = 安全 = NTFS Acl、O = 所有者信息、U = 审核信息fidelity of the file copy (default is /COPY:DAT), copy flags: D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info

/COPYALL/COPYALL

将所有文件信息复制 (等效于/COPY: DATSOU) COPY ALL file info (equivalent to /COPY:DATSOU)

/DCOPY: copyflag [s]/DCOPY:copyflag[s]

目录副本的保真度 (默认值为/DCOPY: DA) ,复制标志: D = 数据,A = 属性,T = 时间戳fidelity for the copy of directories (default is /DCOPY:DA), copy flags: D=Data, A=Attributes, T=Timestamps

阶段8:用户缩减Phase 8: User cut-over

首次运行 RoboCopy 命令时,您的用户和应用程序仍将在 NAS 上访问文件,并有可能更改这些文件。When you run the RoboCopy command for the first time, your users and applications are still accessing files on the NAS and potentially change them. 有可能是,RoboCopy 处理了一个目录,移到下一个目录,然后在源位置 (NAS) 添加、更改或删除将不会在当前的 RoboCopy 运行中处理的文件。It is possible, that RoboCopy has processed a directory, moves on to the next and then a user on the source location (NAS) adds, changes, or deletes a file that will now not be processed in this current RoboCopy run. 这是预期的行为。This behavior is expected.

第一次运行是将大量数据移到 Windows 服务器,并通过 Azure 文件同步将数据移动到云中。此第一个副本可能需要较长时间,具体取决于:The first run is about moving the bulk of the data to your Windows Server and into the cloud via Azure File Sync. This first copy can take a long time, depending on:

  • 下载带宽your download bandwidth
  • 上传带宽the upload bandwidth
  • 本地网络速度和 RoboCopy 线程数与之匹配的最佳方式the local network speed and number of how optimally the number of RoboCopy threads matches it
  • 需要由 RoboCopy 和 Azure 文件同步处理) (文件和文件夹的项数the number of items (files and folders), that need to be processed by RoboCopy and Azure File Sync

初始运行完成后,再次运行该命令。Once the initial run is complete, run the command again.

第二次它将更快完成,因为它只需要传输自上次运行后发生的更改。The second time it will finish faster, because it only needs to transport changes that happened since the last run. 在第二次运行期间,新更改可能会累积。During this second run, still, new changes can accumulate.

重复此过程,直到你满足完成某个特定位置的 RoboCopy 所需的时间量在可接受的时间范围内。Repeat this process until you are satisfied that the amount of time it takes to complete a RoboCopy for a specific location is within an acceptable window for downtime.

如果你认为可接受的停机时间,并且你已准备好使 NAS 位置脱机:为了使用户脱机访问,你可以选择更改共享根目录上的 Acl,使用户无法再访问该位置,或采取任何其他适当的措施来阻止内容在 NAS 上的此文件夹中发生更改。When you consider the downtime acceptable and you are prepared to take the NAS location offline: In order to take user access offline, you have the option to change ACLs on the share root such that users can no longer access the location or take any other appropriate step that prevents content to change in this folder on your NAS.

运行最后一个 RoboCopy 轮。Run one last RoboCopy round. 它将选取任何更改,这些更改可能已丢失。It will pick up any changes, that might have been missed. 这最后一步所花费的时间取决于 RoboCopy 扫描的速度。How long this final step takes, is dependent on the speed of the RoboCopy scan. 您可以通过测量上一次运行所用的时间来估算与停机时间) (。You can estimate the time (which is equal to your downtime) by measuring how long the previous run took.

在 Windows Server 文件夹上创建一个共享,并且可能会调整你的 DFS N 部署以指向该文件夹。Create a share on the Windows Server folder and possibly adjust your DFS-N deployment to point to it. 请确保设置与 NAS SMB 共享上相同的共享级别权限。Be sure to set the same share-level permissions as on your NAS SMB share. 如果你有一个企业级已加入域的 NAS,则用户 Sid 将自动匹配,因为用户存在于 Active Directory 中,RoboCopy 会完全保真地复制文件和元数据。If you had an enterprise-class domain-joined NAS, then the user SIDs will automatically match as the users exist in Active Directory and RoboCopy copies files and metadata at full fidelity. 如果在 NAS 上使用了本地用户,则需要将这些用户重新创建为 Windows Server 本地用户,并将现有的 Sid RoboCopy 移到 Windows Server 上,并将其映射到新的 Windows Server 本地用户的 Sid。If you have used local users on your NAS, you need to re-create these users as Windows Server local users and map the existing SIDs RoboCopy moved over to your Windows Server to the SIDs of your new, Windows Server local users.

你已完成将共享/共享组迁移到公共根或卷中。You have finished migrating a share / group of shares into a common root or volume. (具体取决于你在阶段1中的映射) (Depending on your mapping from Phase 1)

可以尝试并行运行其中几个副本。You can try to run a few of these copies in parallel. 建议一次处理一个 Azure 文件共享的作用域。We recommend processing the scope of one Azure file share at a time.

警告

将所有数据从 NAS 移动到 Windows Server 并完成迁移后:返回到 Azure 门户中的 所有 _ 同步组,并将云分层卷可用空间百分比值调整为更适合缓存利用率的内容,例如20%。Once you have moved all the data from you NAS to the Windows Server, and your migration is complete: Return to *all _ sync groups in the Azure portal and adjust the cloud tiering volume free space percent value to something better suited for cache utilization, say 20%.

云分层卷可用空间策略作用于可能有多个服务器终结点从中同步的卷级别。The cloud tiering volume free space policy acts on a volume level with potentially multiple server endpoints syncing from it. 如果忘记调整甚至一个服务器终结点上的可用空间,同步将继续应用最严格的规则,并尝试保留99% 的可用磁盘空间,从而使本地缓存不会像预期的那样运行。If you forget to adjust the free space on even one server endpoint, sync will continue to apply the most restrictive rule and attempt to keep 99% free disk space, making the local cache not performing as you might expect. 除非您的目标只是只包含很少访问的卷的命名空间、存档数据,并且您保留另一方案的存储空间的剩余部分。Unless it is your goal to only have the namespace for a volume that only contains rarely accessed, archival data and you are reserving the rest of the storage space for another scenario.

疑难解答Troubleshoot

最可能遇到的问题是,RoboCopy 命令在 Windows Server 端上出现 "卷已满" * 的情况下失败。The most likely issue you can run into, is that the RoboCopy command fails with _"Volume full"* on the Windows Server side. 云分层每小时进行一次,用于从已同步的本地 Windows Server 磁盘撤走内容。Cloud tiering acts once every hour to evacuate content from the local Windows Server disk, that has synced. 其目标是在卷上达到99% 的可用空间。Its goal is to reach your 99% free space on the volume.

让同步进度和云分层释放磁盘空间。Let sync progress and cloud tiering free up disk space. 您可以在 Windows Server 上的文件资源管理器中观察。You can observe that in File Explorer on your Windows Server.

当你的 Windows 服务器有足够的可用容量时,重新运行该命令将解决此问题。When your Windows Server has sufficient available capacity, rerunning the command will resolve the problem. 如果遇到这种情况,您可以放心地继续操作。Nothing breaks when you get into this situation and you can move forward with confidence. 再次运行该命令是一个后果。Inconvenience of running the command again is the only consequence.

请查看以下部分中的链接,以了解 Azure 文件同步问题的疑难解答。Check the link in the following section for troubleshooting Azure File Sync issues.

后续步骤Next steps

有关 Azure 文件共享和 Azure 文件同步的详细信息,请阅读。以下文章可帮助了解高级选项、最佳做法和故障排除帮助。There is more to discover about Azure file shares and Azure File Sync. The following articles help understand advanced options, best practices and also contain troubleshooting help. 这些文章链接到相应的 Azure 文件共享文档These articles link to Azure file share documentation as appropriate.