有许多路径可将数据从本地电子邮件组织迁移到 Microsoft 365 或 Office 365。 规划迁移时，一个常见问题是如何提高数据迁移的性能并优化迁移速度。 本文讨论 Exchange 混合部署的迁移性能。 有关其他迁移方法的性能信息，请参阅 Microsoft 365 和Office 365迁移性能和最佳做法。
混合部署迁移支持在本地 Exchange 服务器与 Microsoft 365 或 Office 365 中的Exchange Online之间顺利迁移。
混合部署迁移是迄今为止将邮箱数据迁移到 Microsoft 365 或 Office 365 最快的迁移方法。 在实际客户部署期间，吞吐量高达 100 GB/小时。 下表提供了适用于本机 Microsoft 365 和Office 365混合迁移方案的因素列表。
如果你的本地环境在分散的地理位置中包含多个站点，可以通过创建地理位置邻近感应的迁移终结点来提高迁移性能。 这是因为在这样的情况下迁移使用 Microsoft 的网络，而不使用集中式迁移终结点（使用本地网络）。
因素 1：数据源 (Exchange Server)
| 清单 | 说明 | 最佳做法 |
|---|---|---|
| 系统性能 | 数据提取是一项非常占用资源的任务。 源系统必须具有足够的资源（如 CPU 时间和内存）才能提供更佳的迁移性能。 在迁移时，源系统通常已接近满容量，为常规最终用户工作负载提供服务。 由于缺少系统资源，额外的迁移工作负载有时甚至会降低最终用户的访问权限。 | 在试点迁移测试过程中监视系统性能。 如果系统繁忙，我们建议不要对特定系统执行很占用资源的迁移计划，因为这可能导致迁移变慢和服务可用性问题。 如果可能，应通过增加硬件资源和减少系统中的负载（通过将任务和用户移至迁移未涉及的其他服务器）提高源系统性能。 有关详细信息，请参阅： 询问性能专家：Sizing Exchange 2016 Deployments（调整 Exchange 2016 部署的大小） 当从存在多个邮箱服务器和多个数据库的本地 Exchange 组织迁移时，我们建议创建在多个邮箱服务器和数据库之间均匀分布的迁移用户列表。 根据各个服务器的性能，可以对该列表进一步微调以最大限度地增加吞吐量。 例如，如果服务器 A 的资源可用性比服务器 B 高 50%，那么在同一个迁移批处理中让服务器 A 中多包含 50 % 的用户较为合理。 类似的做法可应用于其他源系统。 在服务器具有最大资源可用性时（如下班后或周末和假日）执行迁移。 |
| 后端任务 | 在迁移期间运行的其他后端任务。 最佳做法是在下班之后执行迁移，因此经常会遇到迁移与您的内部部署服务器上运行的其他维护任务（如数据备份）相冲突的情况。 | 查看在迁移期间可能会运行的其他系统任务。 建议在没有运行其他资源密集型任务时执行数据迁移。 注意：对于使用本地 Microsoft Exchange 的客户，常见的后端任务是备份解决方案和 Exchange 存储维护 。 |
因素 2：迁移服务器
混合部署迁移是云发起的数据提取/推送迁移，Exchange 混合服务器充当迁移服务器。 而这一点经常被忽略，且客户会使用规模较小的虚拟机充当混合服务器。 这会导致迁移性能降低
迁移服务器最佳做法
除了应用之前描述的最佳做法之外，我们还测试了以下最佳做法，这些做法提高了实际客户迁移的迁移性能：
- 为 Exchange 混合服务器使用强大的服务器类物理计算机来替代虚拟机。
- 使用多台位于客户的网络负载平衡器之后的混合服务器。
例如，在实际客户迁移中，我们已通过以下配置达到了一致的 30 GB/小时的吞吐量：
- 网络：500 mb 出站管道到 Internet;具有 10-GB 光纤主干的 1 GB 内部网络。
-
硬件：两个客户端访问/中心 (物理) 服务器的规范如下：
- CPU：Intel® Xeon® CPU E5520 @ 2.27 GHz 2.26 GHz（两个处理器）。
- RAM：24 GB。
- 磁盘：每个磁盘 8×146 GB。 RAID 5 配置 = 960 GB 总原始空间。
- MRSProxy：配置的并发为 100。
因素 3：迁移引擎
混合部署迁移使用本机 Microsoft 365 和 Office 365 工具。 它受 Microsoft 365 的限制，Office 365迁移服务限制。
Exchange 2003 和更高版本的 Exchange
从 Exchange 2003 进行迁移时，存在最终用户体验的重大差异。 与 Exchange 的更高版本不同，Exchange 2003 最终用户无法在迁移数据时访问其邮箱。 因此，Exchange 2003 客户通常更关注何时安排迁移以及迁移所需的时间（尤其是在因邮箱较大或网速较慢而导致迁移性能降低时）。
Exchange 2003 迁移对中断也非常敏感。 例如，在实际客户迁移中，在迁移 10GB 邮箱期间，邮箱迁移完成 50% 时发生了服务事件。 处理数据迁移的 Office 365 客户端访问服务器必须重新启动才能解决问题。 在这种情况下，必须重新启动该邮箱的迁移，这意味着客户必须再次迁移所有 10GB 数据。 不能从停止的点恢复迁移。 但 Exchange 2010 和更高版本的 Exchange 却能在中断后恢复迁移。
迁移引擎最佳做法
有些客户选择对规模较大且敏感的 Exchange 2003 邮箱执行两跳迁移：
- 第一跃点：将邮箱从 Exchange 2003 迁移到 Exchange 2010 或更高版本服务器，该服务器通常是混合服务器。 第一个跃点是脱机移动，但通常是通过本地网络执行的速度极快的迁移。
- 第二跃点：将邮箱从 Exchange 2010 或更高版本迁移到 Microsoft 365 或 Office 365。
第二个跃点是联机移动，会提供更好的用户体验和容错功能。 这两个跃点方法需使用临时本地用户邮箱的 Exchange 许可证。
邮箱复制服务代理 (MRSProxy)
MRS 代理是本地迁移功能，适用于在 Microsoft 365 和 Office 365 端运行的邮箱复制服务。 有关详细信息，请参阅了解移动请求。
MRSProxy 最佳做法
可以为本地 Exchange 混合服务器 配置最大数量的 MRSProxy 连接。 运行以下 Windows PowerShell 命令。
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
注意
对于大多数客户迁移，无需更改默认 MRSMaxConnections 值。 如果需要保护源服务器以免迁移负载过大，客户可以减少连接数。 此设置按每个 MRSProxy 服务器进行设置。 如果客户有两个 MRSProxy 服务器，每个服务器都设置为 10 个连接，它们的总 MRSProxy 连接数将为 20 (2 x 10)。 有关在本地 Exchange 2010 组织中配置 MRSProxy 服务的详细信息，请参阅在远程客户端访问服务器上启动 MRSProxy 服务。
因素 4：网络
验证测试
对于运行 Exchange 2010 或更高版本的客户，可通过执行多个测试邮箱迁移完成对混合迁移网络性能的测试。 或者，也可以使用 -SuspendWhenReadyToComplete 选项迁移实际用户邮箱，以满足迁移性能指标。 测试完成时，删除移动请求，以避免影响最终用户。
有关移动请求的详细信息，请参阅 New-MoveRequest。
因素 5：Office 365 服务
Microsoft 365 和 Office 365 基于资源运行状况的限制会影响使用 Microsoft 365 或 Office 365 混合部署迁移的迁移。 有关更多详细信息，请参阅上面的 因素 3：迁移引擎 部分。