你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
迁移到 NFS Azure 文件共享
本文介绍从 Linux 文件服务器迁移到 NFS Azure 文件共享的基本方面，这些文件共享仅可用作高级文件共享（FileStorage 帐户类型）。 我们还将比较开源文件复制工具 fpsync 和 rsync，以了解它们在将数据复制到 Azure 文件共享时的表现。
注意
Azure 文件存储不支持 NFS 访问控制列表 (ACL)。
适用于
| 文件共享类型 | SMB | NFS |
|---|---|---|
| 标准文件共享 (GPv2)、LRS/ZRS |  |
|
| 标准文件共享 (GPv2)、GRS/GZRS | |
|
| 高级文件共享 (FileStorage)、LRS/ZRS | |
 |
先决条件
至少需要一个装载到 Linux 虚拟机 (VM) 的 NFS Azure 文件共享。 若要创建一个，请参阅创建 NFS Azure 文件共享并将其装载到 Linux VM。 我们建议使用 nconnect 装载共享，以便使用多个 TCP 连接。 有关详细信息，请参阅提高 NFS Azure 文件共享性能。
迁移工具
许多开源工具都可用于将数据传输到 NFS 文件共享。 但是，与本地设置相比，并非所有工具都能在处理具有不同性能注意事项的分布式文件系统时保持高效。 在分布式文件系统中，每个网络调用都涉及到可能并非本地服务器的往返。 因此，优化网络调用所用的时间对于实现最佳性能和网络上的高效数据传输至关重要。
使用 fpsync 与 rsync
rsync 虽然是单线程的，但却是一种通用的开源文件复制工具。 它可以在本地复制、通过任何远程 shell 从/向另一台主机复制，或者从/向远程 rsync 守护程序复制。 它提供了许多选项，并支持灵活规范要复制的文件集。 但是，fpsync 是一个多线程应用程序，因此提供了一些优势，包括能够并行运行 rsync 作业。
在本文中，我们将使用 fpsync 将数据从 Linux 文件服务器移动到 NFS Azure 文件共享。
为了复制数据，fpsync 将使用 rsync（默认）、cpio 或 tar 工具。 它将计算源目录 src_dir/ 的子集并生成同步作业，以将其同步到目标目录 dst_dir/。 它会动态执行同步作业，同时对文件系统进行爬网，因此是一种可高效迁移大型文件系统并复制包含多个文件的大型数据集的有用工具。
注意
fpsync 仅同步目录内容，而不会同步源目录本身。 与 rsync 不同的是，fpsync 在源目录上强制实施最终的“/”，这意味着同步后不会在目标目录中获得具有源目录名称的子目录。
安装 fpart
若要使用 fpsync，需要安装 fpart 文件系统分区程序。 在所选 Linux 分发版上安装 fpart。 安装后，应会在 /usr/bin/ 下看到 fpsync。
将数据从源位置复制到目标位置
确保已将目标 Azure 文件共享装载到 Linux VM。 请参阅先决条件。
如果要执行完整迁移，你将分三个阶段复制数据：
- 基线复制：在目标位置没有数据时，从源位置复制到目标位置。 对于基线复制，我们建议使用 fpsync 和 cpio 作为复制工具。
- 增量复制：仅将增量更改从源位置复制到目标位置。 对于增量同步，我们建议使用 fpsync 和 rsync 作为复制工具。 该操作应多次执行，以便捕获所有更改。
- 最终传递：需要进行最终传递，以删除在目标位置存在但在源位置不存在的任何文件。
使用 fpsync 复制数据总会涉及以下命令的某些版本：
fpsync -m <specify copy tool - rsync/cpio/tar> -n <parallel transfers> <absolute source path> <absolute destination path>
基线复制
对于基线复制，请将 fpsync 与 cpio 配合使用。
fpsync -m cpio -n <parallel transfers> <absolute source path> <absolute destination path>
有关详细信息，请参阅 Cpio 和 Tar 支持。
增量复制
对于增量同步，请将 fpsync 与默认复制工具 (rsync) 配合使用。 为了捕获所有更改，建议多次运行此操作。
fpsync -n <parallel transfers> <absolute source path> <absolute destination path>
默认情况下，fpsync 将指定以下 rsync 选项：-lptgoD -v --numeric-ids。 你可以通过将 -o option 添加到 fpsync 命令来指定其他 rsync 选项。
最终传递
在进行多次增量同步后，你需要执行最后传递，以删除在目标位置存在但在源位置不存在的任何文件。 你可以使用 rsync --delete 手动执行此操作，以从 /data/dst/ 目录中删除多余的文件，也可以配合使用 fpsync 与 -E 选项来实现此目的。 有关详细信息，请参阅最终传递。
使用不同的数据集来比较 rsync 和 fpsync
本部分将使用不同的数据集来对 rsync 和 fpsync 的性能进行比较。
数据集和配置
下表列出了用于在不同工作负载下比较复制工具性能的不同数据集。
| 配置编号 | 复制类型 | 文件计数 | 目录计数 | 文件大小 | 总大小 |
|---|---|---|---|---|---|
| 1.1 | 基线复制 | 1 百万 | 1 | 0-32 KiB | 18 GiB |
| 1.2 | 增量（增量更改） | 1 百万 | 1 | 0-32 KiB | 18 GiB |
| 2 | 基线复制 | 191,345 | 3,906 | 0-32 KiB | 3 GiB |
| 3 | 基线复制 | 5,000 | 1 | 10 MiB | 50 GiB |
这些测试是在具有 8 个 vCPU、32 GiB 内存和 1 TiB 以上的大型数据集磁盘空间的 Azure Standard_D8s_v3 VM 上执行的。 对于目标，我们配置了预配大小超过 1 TiB 的 NFS Azure 文件共享。
试验和结果：rsync 与 fpsync
根据采用上述配置的试验，我们发现，对于使用 nconnect=8 装载的 Azure NFS 文件共享，fpsync 在使用 64 个线程（搭配 rsync）和 16 个线程（搭配 cpio）时表现最佳。 实际结果因配置和数据集而异。
注意
Azure 文件存储的吞吐量可能远高于以下图表中所示的数据。 为了简单起见，一些试验特意使用小型的数据集。
配置 1
对于包含 100 万个小文件（共 18 GiB）的单个目录，我们将此测试作为基线复制和增量复制运行。
在执行从源位置到目标位置的基线复制时，我们观察到了以下结果。
在执行增量复制（增量更改）时，我们观察到了以下结果。
配置 2
在执行总共涉及 3,906 个目录中的 191,345 个小型文件（总大小为 3 GiB）的基线复制时，我们观察到了以下结果。
配置 3
在执行总共涉及单个目录中的 5,000 个大型文件（每个 10 MiB，总大小为 50 GiB）的基线复制时，我们观察到了以下结果。
结果摘要
与单线程复制工具（如 rsync）相比，在迁移到 NFS Azure 文件共享时使用多线程应用程序（如 fpsync）可以提高吞吐量和 IOPS。 我们的测试显示：
- 跨目录分布数据有助于实现迁移过程并行化，从而获得更好的性能。
- 从更大的文件大小复制数据比从较小的文件大小复制数据的性能更好。
下表汇总了结果：
| 配置编号 | 文件计数 | 目录计数 | 文件大小 | 总大小 | rsync 持续时间 | rsync 吞吐量 | fpsync 持续时间 | fpsync 吞吐量 | 吞吐量增益 |
|---|---|---|---|---|---|---|---|---|---|
| 1.1（基线） | 1 百万 | 1 | 0-32 KiB | 18 GiB | 837.06 分钟 | 0.33 MiB/s | 228.16 分钟 | 1.20 MiB/s | 267% |
| 1.2（增量） | 1 百万 | 1 | 0-32 KiB | 18 GiB | 84.02 分钟 | 3.25 MiB/s | 7.5 分钟 | 36.41 MiB/s | 1,020% |
| 2（基线） | 191,345 | 3,906 | 0-32 KiB | 3 GiB | 191.86 分钟 | 0.27 MiB/s | 8.47 分钟 | 6.04 MiB/s | 2,164% |
| 3（基线） | 5,000 | 1 | 10 MiB | 50 GiB | 8.12 分钟 | 105.04 MiB/s | 2.76 分钟 | 308.90 MiB/s | 94% |
第三方信息免责声明
本文中提到的开源工具是众所周知的第三方解决方案。 这些工具并非由 Microsoft 直接或间接开发、拥有或提供支持。 客户有责任检查第三方文档中提供的软件许可证和支持声明。