你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 存储移动程序的缩放和性能目标
存储迁移服务的性能是任何迁移的关键方面。 在本文中，我们共享性能测试结果，尽管Azure 存储 Mover 是一项新服务，因此你的体验可能会有所不同。
缩放目标
已使用 1 亿个命名空间项（文件和文件夹）对 Azure 存储移动程序进行测试，这些项已从 Azure 中支持的源迁移到支持的目标。
测试方法
Azure 存储移动程序是一个混合云服务。 混合服务包含云服务组件，以及服务管理员在其企业环境中运行的基础结构组件。 对于存储移动程序，该混合组件是一个迁移代理。 代理是在源存储附近的主机上运行的虚拟机。
只有代理是性能测试服务的相关部分。 为了免除隐私和性能忧虑，数据直接从存储移动程序代理传送到 Azure 中的目标存储。 只会将控制和遥测消息发送到云服务。
性能基线
这些测试结果是在理想条件下得出的。 它们表示存储移动程序服务和代理可以直接影响的组件的基线。 此项测试未考虑源设备、磁盘和网络连接的差异。 实际性能各不相同。
执行从 SMB 装载到 Azure 文件共享测试的迁移，如下所示：
下表描述了生成从 SMB 装载到 Azure 文件共享的性能测试结果的测试环境的特征。
| 测试否。 | 不是。 文件 | 文件总权重 | 文件大小 | 文件夹结构 |
|---|---|---|---|---|
| 1 | 1200 万 | 12 GB | 每个知识库(KB) 1 个 | 12 个文件夹，每个文件夹包含 100 个子文件夹，其中包含 10,000 个文件 |
| 2 | 30 | 20 GB | 1 个文件夹 | |
| 3 | 1 百万 | 100 GB | 每个知识库(KB) 100 个 | 1,000 个文件夹，每个文件夹包含 1,000 个文件 |
| 4 | 1 | 4 TB | ||
| 5 | 1.17 亿 | 117 GB | 每个知识库(KB) 1 个 | 117 个文件夹，每个文件夹包含 100 个子文件夹，其中包含 10,000 个文件 |
| 6 | 1 | 1 TB | ||
| 7 | 330 万 | 45 GB | 每个知识库(KB) 13 个 | 200,000 个文件夹，每个文件夹包含 16\17 个文件 |
| 8 | 5000 万 | 1 TB | 每个知识库(KB) 20 个 | 2,940,000 个文件夹，每个文件夹包含 17 个文件 |
| 9 | 1 亿 | 2 TB | 每个知识库(KB) 20 个 | 5,880,000 个文件夹，每个文件夹包含 17 个文件 |
在 SMB 终结点上测试不同的代理资源配置：
Minspec：4 个 CPU/8 GB RAM 4 个虚拟 CPU 核心，每个内核为 2.7 GHz，8 GiB 内存（RAM）是Azure 存储 Mover 代理的最低规范。
测试否。 执行时间 扫描时间 6 16 分钟，42 秒 1.2 秒 7 55 分钟，4 秒 1 分钟，17 秒 8 9 启动：8 个 CPU/16 GiB RAM 8 虚拟 CPU 内核，每个内核为 2.7 GHz，16 GiB 内存（RAM）是Azure 存储 Mover 代理的最低规范。
结果：标准存储帐户
测试否。 执行时间 扫描时间 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 更大的文件要长。 - 命名空间形状
宽文件夹层次结构比窄或深目录结构更适合并行处理。 文件与文件夹的比率也很关键。 - 命名空间变动率
每次运行从同一个源到同一个目标的复制后，有多少文件、文件夹和元数据发生了更改。 - Network
- 源与迁移代理之间的带宽和延迟
- 迁移代理与 Azure 中目标之间的带宽和延迟
- 迁移代理资源
迁移代理上的内存 (RAM) 量、计算核心数甚至可用本地磁盘容量，都会对迁移速度产生深远影响。 更多的计算资源有助于优化可用带宽的利用，尤其是在迁移中需要处理大量小文件时。
例如，传统迁移需要通过一种策略来最大程度地减少所要迁移的、依赖于存储的工作负载的停机时间。 Azure 存储移动程序支持这种策略。 这称为收敛的 n 次迁移。
在此策略中，需要多次从源复制到目标。 在复制迭代期间，源仍然可用于读取和写入工作负载。 在最后一次复制迭代之前，需要将源脱机。 最后一次复制的完成速度预期比前几次复制（例如首次复制）要快，花费的时间与倒数第二次复制大致相当。 最后一次复制后，工作负载将故障转移，以便在 Azure 中使用新的目标存储，并再次可供使用。
在首次从源复制到目标期间，目标可能是空的，而所有源内容必须传送到目标。 因此，首次复制受可用网络资源限制的可能性最大。
如果在迁移快要结束时已将源多次复制到目标，则自上次复制以来只有少量文件、文件夹和元数据发生了更改。 在这最后一次复制迭代中，比较源和目标中的每个文件以查看它是否需要更新将消耗更多的计算资源和更少的网络资源。 此后期迁移阶段中的复制运行通常受计算资源的限制程度更大。 存储 Mover 代理的适当资源变得越来越重要。
后续步骤
以下文章可帮助你成功完成 Azure 存储移动程序部署。