你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
存储迁移服务的性能是任何迁移的关键方面。 在本文中，我们共享性能测试结果，不过，由于 Azure 存储移动器是一项新服务，因此你的体验可能会有所不同。
缩放目标
Azure 存储移动器使用 5 亿个命名空间项（文件和文件夹）进行测试，这些项从受支持的源迁移到 Azure 中 受支持的目标 。
如何测试
Azure 存储迁移服务是一个混合云服务。 混合服务具有云服务组件和服务管理员在其企业环境中运行的基础结构组件。 对于存储移动器，该混合组件是迁移代理。 代理是在源存储附近的主机上运行的虚拟机。
只有代理是性能测试服务的相关部分。 为了省略隐私和性能问题，数据直接从存储移动器代理传送到 Azure 中的目标存储。 仅将控制和遥测消息发送到云服务。
性能基线
这些测试结果是在理想条件下创建的。 它们表示存储移动程序服务和代理可以直接影响的组件的基线。 此测试中不考虑源设备、磁盘和网络连接的差异。 实际性能各不相同。
按照如下操作步骤，执行从 SMB 装载迁移到 Azure 文件共享的测试：
下表描述了生成从 SMB 装载到 Azure 文件共享的性能测试结果的测试环境的特征。
| 测试编号。 | 否。 文件数 | 文件总权重 | 文件大小 | 文件夹结构 |
|---|---|---|---|---|
| 1 | 1200 万 | 12 GB | 每个 1 KB | 12 个文件夹，每个文件夹包含 100 个子文件夹，其中包含 10,000 个文件 |
| 2 | 30 | 20 GB | 1 个文件夹 | |
| 3 | 1 百万 | 100 GB | 每个 100 KB | 1,000 个文件夹，每个文件夹包含 1,000 个文件 |
| 4 | 1 | 4 TB | ||
| 5 | 1.17 亿 | 117 GB | 每个 1 KB | 117 个文件夹，每个文件夹包含 100 个子文件夹，其中包含 10,000 个文件 |
| 6 | 1 | 1 TB（兆字节） | ||
| 7 | 330 万 | 45 GB | 每个 13 KB | 200,000 个文件夹，每个文件夹包含 16\17 个文件 |
| 8 | 5000 万 | 1 TB（兆字节） | 每个 20 KB | 2,940,000 个文件夹，每个文件夹包含 17 个文件 |
| 9 | 1 亿 | 2兆字节 | 每个 20 KB | 5,880,000 个文件夹，每个文件夹包含 17 个文件 |
在 SMB 终结点上测试不同的代理资源配置：
Minspec：4 个 CPU/8 GB RAM 4 个虚拟 CPU 核心（每个 2.7 GHz）和 8 GiB 内存（RAM）是 Azure 存储移动器代理的最低规范。
测试编号。 执行时间 扫描时间 6 16 分钟，42 秒 1.2 秒 7 55 分钟，4 秒 1 分钟，17 秒 8 9 Bootspec：8 个 CPU/16 GiB RAM 8 虚拟 CPU 核心（每个 2.7 GHz）和 16 GiB 内存（RAM）是 Azure 存储移动器代理的最低规范。
结果：标准存储帐户
测试编号。 执行时间 扫描时间 1 15 小时， 59 分钟 2 小时， 36 分钟， 34 秒 2 1 分钟，54 秒 3.34 秒 3 1 小时， 19 分钟， 27 秒 57.62 秒 4 1 小时， 5 分钟， 57 秒 2.89 秒 结果：启用了大型文件的标准存储帐户
测试编号。 执行时间 扫描时间 1 3 小时， 51 分钟， 31 秒 41 分钟和 45 秒 5 25 小时， 47 分钟 23 小时， 35 分钟 6 11 分钟，11 秒 0.7 秒 7 55 分钟，10 秒 1 分钟，3 秒 8 9 结果：高级存储帐户
测试编号。 执行时间 扫描时间 1 2 小时， 35 分钟， 14 秒 24 分钟，46 秒 5 23 小时， 34 分钟 21 小时， 34 分钟
迁移性能为何不同
从根本上说，网络质量和处理文件、文件夹及其元数据的能力会影响迁移速度。
在网络和计算的两个核心领域，多个方面都有影响：
-
迁移方案
与具有内容的目标相比，复制到空目标更快。 此行为是由于迁移引擎不仅评估源，还评估目标以做出复制决策。 -
命名空间项计数
迁移 1 GiB 的小文件所需的时间比迁移 1 GiB 更大的文件要长。 -
命名空间形状
宽文件夹层次结构比窄目录结构或深度目录结构更适合并行处理。 文件与文件夹的比率也起作用。 -
命名空间变动率
从同一源到同一目标的两次复制运行之间有多少文件、文件夹和元数据发生了更改。 -
网络
- 源代理和迁移代理之间的带宽和延迟
- 迁移代理与 Azure 中目标之间的带宽和延迟
-
迁移代理资源
内存量（RAM）、计算核心数，甚至可用量，迁移代理上的本地磁盘容量可能会对迁移速度产生深远的影响。 更多的计算资源有助于优化可用带宽的利用率，尤其是在迁移中需要处理大量较小的文件时。
例如，传统迁移需要一种策略，以最大程度地减少依赖于要迁移的存储的工作负荷的停机时间。 Azure 存储移动程序支持此策略，称为聚合，多次迁移。
在此策略中，需要多次从源复制到目标。 在复制迭代期间，源仍然可用于读取和写入工作负载。 在最后一次复制迭代之前，需要将源脱机。 最终副本的完成速度预计会比你创建的第一个副本快，并且大约需要和紧接其前的那个副本相同的时间。 最后一次复制后，工作负载将故障转移，以便在 Azure 中使用新的目标存储，并再次可供使用。
在第一次从源复制到目标的过程中，目标可能是空的，因此所有源内容都必须转移到目标。 因此，第一个副本很可能最受可用网络资源的限制。
在迁移接近尾声时，将源复制到目标数次后，在最后一次复制后，只修改了几个文件、文件夹和元数据。 在此最后一次复制迭代中，比较源和目标中的每个文件，以确定它是否需要更新，需要更多的计算资源和更少的网络资源。 复制作业在迁移的后期阶段通常更受计算资源限制。 为存储移动程序代理提供适当的资源变得越来越重要。
后续步骤
以下文章可帮助成功部署 Azure 存储移动器。