Office 365 迁移性能和最佳做法

可通过多种方式将数据从本地电子邮件组织迁移到 Microsoft Office 365。当规划到 Office 365 的迁移时,常见的问题之一是如何提高数据迁移的性能和优化迁移速度。

注意: 本主题中列出的性能信息不适用于 Office 365 服务专用订阅计划。有关专用计划的详细信息,请参阅 Office 365 专用计划服务说明

本主题内容

将电子邮件迁移到 Office 365 的概述

将多个电子邮件帐户迁移到 Office 365 的方法中所述,Office 365 支持通过多种方法将电子邮件、日历和联系人数据从现有邮件环境迁移到 Office 365。

有关 Office 365 网络和性能的详细信息,请参阅 Office 365 的网络规划和性能优化

常用的迁移方法

迁移方法

说明

资源

Internet 消息访问协议 (IMAP) 迁移

可以使用 Exchange 管理中心 或 Exchange 命令行管理程序将用户邮箱内容从 IMAP 邮件系统迁移到 Office 365 邮箱。其中包括从其他托管电子邮件服务(如 Gmail 或 Yahoo Mail)迁移邮箱。

将 IMAP 邮箱迁移到 Office 365

直接转换迁移

使用直接转换迁移,可在几天内将所有本地邮箱都迁移到 Office 365。如果计划将整个电子邮件组织移到 Office 365,并在 Office 365 中管理用户帐户,请使用直接转换迁移。使用直接转换迁移可将最多 2,000 个邮箱从本地 Exchange 组织迁移到 Office 365。但是建议的邮箱数量为 150    个。超过此数量,性能会受到影响。本地 Exchange 组织中的邮件联系人和通讯组也将进行迁移。

直接转换迁移到 Office 365

暂存迁移

若计划将组织的所有邮箱最终迁移到 Office 365,请使用暂存迁移。使用暂存迁移可在数周或数月内将本地邮箱成批迁移到 Office 365。

有关使用暂存迁移将电子邮件迁移到 Office 365 的注意事项

混合部署

混合部署使组织可以将其现有本地 Exchange 组织拥有的功能丰富的体验和管理控制扩展到云。混合部署可在本地 Exchange Server 2013 或 Microsoft Exchange Server 2010 与 Office 365 之间实现无缝对接,使二者在外观和感觉都融为一个 Exchange 组织。此外,混合部署还可以充当完全迁移到 Office 365 组织的中间步骤。

Exchange Server 2013 混合部署

第三方迁移

第三方提供了许多可用的工具。这些工具使用独特的协议和方法从 IBM Lotus Notes 和 Novell GroupWise 等电子邮件平台进行电子邮件迁移。

以下是有助于从第三方平台进行 Exchange 迁移的一些第三方迁移工具和合作伙伴:

  • Binary Tree   跨平台邮件迁移和共存软件提供商,其产品用于基于 IBM Lotus Notes 和 Domino、Exchange 和 SharePoint 的本地与联机企业邮件环境和协作环境的分析,以及它们之间的共存和迁移。

  • BitTitan   迁移到 Office 365 的解决方案提供商。

  • Dell   本地和托管迁移与共存软件(包括预迁移分析和完整的用户和应用程序共存)提供商。从本地 Exchange、IBM Domino、Novell GroupWise、Zimbra 和其他环境到 Office 365 和 SharePoint Online 的完整功能的迁移。

  • Metalogix   迁移到 Office 365 和 SharePoint Online 的解决方案提供商。

  • SkyKick自动化迁移解决方案的提供商,可用于将本地 Exchange、Gmail、POP3、IMAP、Lotus Notes 迁移到 Office 365。该工具为端到端的迁移工具,可帮助合作伙伴销售、规划、迁移、管理和现场实施迁移项目。

  • TransVault   迁移到Office 365 的解决方案提供商。

迁移方法的性能

下表针对将邮箱和邮箱数据迁移到 Office 365 的不同迁移方法的性能观察结果进行了对比。这些结果是根据内部测试和客户迁移到 Office 365 的实际情况得出的。

重要: 由于执行迁移的方式和时间不同,因此实际迁移速度可能会较慢或较快。

迁移方法

Office 365 用户限制

Office 365 迁移服务限制

Office 365 基于资源运行状况的限制

观察到的每个客户端每小时的平均吞吐量(如果适用)

IMAP 迁移

10-14 千兆字节 (GB)(20 个并发)

直接转换迁移

10-14 GB(20 个并发)

暂存迁移

10-14 GB(20 个并发)

混合迁移

10-14 GB(每个具有 20 个并发移动的本地 Exchange 2013 或 2010 CAS(Microsoft Exchange 邮箱复制服务,即 MRSProxy 服务)1

第三方 MAPI 迁移

4-12 GB(20 个并发)2

第三方 Exchange Web 服务迁移

5-10 GB(20 个并发)3

客户端上传(从 Outlook .pst 文件)

0.5 GB

1观察到的单个邮箱移动吞吐量在每小时 0.3–1.0 GB 范围内。在可以让瞬间失败停滞时间低于 2%,并且网络延迟低于 100 毫秒的网络中,可以实现每个邮箱大于 1000 MB/小时的吞吐速度。可以使用更多个并发邮箱迁移来实现更高的数据迁移速度。当本地 CAS(MRSProxy 服务)服务器达到硬件容量上限时,如果网络带宽不足,或者网络延迟过高,单个邮箱的移动吞吐量会降低。建议添加更多服务器或暂时改进网络连接,以便提高迁移速度。

2观察到的单个 MAPI 在每小时 0.1-0.5 GB 范围内。可以使用更多并发迁移来实现更高的数据迁移速度。当本地服务器或网络达到容量上限时,单个 MAPI 迁移吞吐量会降低。

3观察到的单个 Exchange Web 服务迁移吞吐量在每小时 0.2–0.5 GB 范围内。可以使用更多并发迁移来实现更高的数据迁移速度。例如,如果有 20 个并发迁移,则总吞吐量将在每小时 4-10 GB 范围内。当本地服务器或网络达到容量上限时,单个 Exchange Web 服务迁移吞吐量会降低。

影响迁移性能的因素

电子邮件迁移过程中有几个可能影响迁移性能的常见因素。

影响迁移性能的常见因素

下表列出了影响迁移性能的常见因素。每个迁移方法的说明部分中含有更多详细信息。

影响因素

说明

示例

数据源

用于托管要迁移的数据的设备或服务。由于硬件规格、最终用户工作负载以及后端维护任务的原因,数据源可能会受到很多限制。

Gmail 限制了特定时间段内可以提取的数据量。

数据类型和密度

由于客户业务的独特性,邮箱内的邮件类型和组合差异很大。

如果一个 4 GB 的邮箱中包含 400 封邮件,每封邮件带有 10 兆字节 (MB) 的附件,那么此邮箱的迁移速度会快于包含 100,000 封较小邮件的 4-GB 邮箱。

迁移服务器

许多迁移解决方案都使用“jump box”类型的迁移服务器或工作站来完成迁移。

客户通常使用低性能的虚拟机来托管 MRSProxy 服务,以进行混合部署或客户端电脑的非混合迁移。

迁移引擎

负责从源服务器提取数据的数据迁移引擎会根据需要转换数据。然后,该引擎通过网络传输数据,并将数据注入到 Office 365 邮箱中。

MRSProxy 服务有其自己的功能和限制。

本地网络设备

端到端网络性能(从数据源到 Exchange Online 客户端访问服务器)将影响迁移性能。

本地组织的防火墙配置和规格。

Office 365 服务

Office 365 具有管理迁移工作负载的内置支持和功能。

用户限制策略有默认设置,并且会限制总体的最大数据传输速率。

影响网络性能的因素

本部分介绍在迁移过程中提高网络性能的最佳做法。此讨论是常规性讨论,因为迁移过程中对网络性能的最大影响与第三方硬件和 Internet 服务提供商 (ISP) 有关。

部署 Office 365 服务之前,先部署 Office 365 网络分析工具帮助分析与网络有关的问题。每个实例都使用 Office 365 中的测试终结点来专门测试某个特定区域。

使用 Exchange Analyzer 更深入地了解与 Office 365 的网络连接。若要在支持和恢复助手中运行 Exchange Analyzer 测试,请转到“高级诊断”>“Exchange Online”>“检查 Exchange Online 网络连接”>“是”。请参阅使用 Office 365 支持和恢复助手修复 Outlook 和 Office 365 问题了解支持和恢复助手的详细信息。

影响因素

说明

最佳做法

网络容量

将邮箱迁移到 Office 365 所需的时间量由网络的可用容量和最大容量决定。

  • 确定可用网络容量和最大上传容量。

  • 联系 ISP 以确认分配的带宽,并获得有关限制的详细信息(如在特定时间段内可传输的数据总量)。

  • 使用工具来评估实际网络容量。务必测试从本地数据源到 Microsoft 数据中心网关服务器的端到端数据流。

  • 识别网络上可能影响网络容量的其他负载(例如备份实用程序和定期维护)。

网络稳定性

网络速度快并不意味着迁移速度就一定快。如果网络不稳定,那么数据传输可能因错误纠正而需要更长时间。错误纠正可能会显著影响迁移性能,具体取决于迁移类型。

网络硬件和驱动程序问题通常会导致网络稳定性问题。请与硬件供应商协作以了解网络设备,并应用供应商建议的最新驱动程序和软件更新。

网络延迟

网络防火墙上配置的入侵检测功能通常会导致严重的网络延迟并影响迁移性能。

将数据迁移到 Office 365 邮箱依赖于 Internet 连接。Internet 延迟会影响总体迁移性能。

此外,同一公司中的用户可能具有位于不同地理位置的数据中心中的云邮箱。迁移性能可能有所不同,具体取决于客户的 ISP。

  • 对所有可能的 Microsoft 数据中心进行网络延迟评估,以确保结果的一致性。(这还有助于确保最终用户体验的一致性)。请与 ISP 协作以解决 Internet 相关问题。

  • 将 Microsoft 数据中心服务器的 IP 地址添加到允许列表中,或者从网络防火墙中绕过所有与迁移相关的通信。有关 Office 365 IP 范围的详细信息,请参阅 Office 365 URL 和 IP 地址范围

有关环境内迁移的更深入分析,请查看我们的移动分析博客文章。文章中包含有一个脚本,可帮助分析移动请求。

Office 365 限制

Office 365 使用各种限制机制来确保安全性和服务可用性。以下三种限制类型可能影响迁移性能:

  • 用户限制

  • 迁移服务限制

  • 基于资源运行状况的限制

注意: 这三种类型的 Office 365 限制不会对所有迁移方法造成影响。

Office 365 用户限制

用户限制将影响大多数第三方迁移工具和客户端上传迁移方法。这些迁移方法使用客户端访问协议,如通过 HTTP 进行的远程过程调用 (RPC) 协议,将邮箱数据迁移到 Office 365 邮箱。这些工具通常用于从 IBM Lotus Domino 和 Novell GroupWise 等平台迁移数据。

用户限制是 Office 365 中最严格的限制方法。由于用户限制设置为针对单独的最终用户,因此任何应用程序级使用都很容易超出限制策略,从而导致数据迁移变慢。

Office 365 迁移服务限制

迁移服务限制将影响所有 Office 365 迁移工具。迁移服务限制管理 Office 365 迁移解决方案的迁移并发和服务资源分配。

迁移服务限制将影响使用以下迁移方法执行的迁移:

  • IMAP 迁移

  • 直接转换 Exchange 迁移

  • 暂存 Exchange 迁移

  • 混合迁移(混合环境中基于 MRSProxy 服务的移动)

迁移服务限制的示例之一是控制在简单 Exchange 迁移和 IMAP 迁移期间同时迁移的邮箱数量。默认值为 10。这意味着所有迁移批处理中的任何特定时间最多可迁移 10 个邮箱。可以在 Exchange 控制面板或 Windows PowerShell 中增加迁移批处理的并发邮箱迁移数。有关如何优化此设置的详细信息,请参阅在 Office 365 中管理迁移批处理

Office 365 基于资源运行状况的限制

所有迁移方法都受可用性限制的约束,但 Office 365 服务限制对 Office 365 迁移的影响没有上述其他限制类型的影响大。

基于资源运行状况的限制是最保守的限制方法。只有当存在影响最终用户和关键服务操作的服务可用性问题时才会实施。

例如,如果在混合迁移过程中出现服务事件,并且服务降级到导致最终用户性能降低的程度,那么混合迁移将会进行排队,直到性能恢复并且服务返回到低于限制阈值的水平。

下面是 Exchange 迁移统计报告中的一个示例。它显示了超出服务限制阈值时生成的条目。

  • 2012/1/25 凌晨 12:56:01 [BL2PRD0410CA012] 复制进度:723/1456 封邮件, 225.8 MB(236,732,045 字节)/416.5 MB(436,712,733 字节)。

  • 2012/1/25/ 凌晨 12:57:53 [BL2PRD0410CA012] 邮箱 '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' 的移动已停止,因为 DataMoveReplicationConstraint 不满足数据库 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication)。失败的原因:数据库 edbf0766-1f2a-4552-9115-bb3a53a8380b 不满足约束 SecondDatacenter。没有可用的状态良好的数据库副本。将等待至 2012/1/25 凌晨 1:27:53。

  • 2012/1/25 凌晨 12:58:24 [BL2PRD0410CA012] 请求不再停止,将继续操作。

解决方案和做法   

如果遇到类似情况,请等待 Office 365 服务恢复。有关详细信息,请参阅 Office 365 门户中的“服务运行状况”部分。

非混合部署迁移的性能因素和最佳做法

本节介绍使用 IMAP、直接转换或暂存迁移方法的迁移的影响因素,并介绍提高迁移性能的最佳做法。

影响因素 1:数据源

下表介绍了通过当前电子邮件组织中的源服务器执行迁移的影响,以及缓解对迁移的影响的最佳做法。

清单

说明

最佳做法

系统性能

数据提取是一项资源密集型任务。源系统需要有足够的资源(如 CPU 时间和内存)才能提供最佳迁移性能。迁移过程中,在常规最终用户工作负载方面,源系统通常会接近于最大容量。如果系统资源不足,那么迁移产生的其他工作负载可能会影响最终用户。

在试点迁移测试过程中监视系统性能。如果系统繁忙,建议不要对特定系统执行很占用资源的迁移计划,因为这可能导致迁移变慢和服务可用性问题。如果可能,应通过增加硬件资源和减少系统中的负载(通过将任务和用户移至迁移未涉及的其他服务器)来提高源系统性能。

有关详细信息,请参阅:

从存在多个邮箱服务器的本地 Exchange 组织进行迁移时,建议创建在多个邮箱服务器中均匀分布的迁移用户列表。根据各个服务器的性能,可以对该列表进一步微调以达到最大吞吐量。

例如,如果服务器 A 的资源可用性比服务器 B 高 50%,那么在同一个迁移批处理中让服务器 A 中多包含 50 % 的用户较为合理。类似的做法可应用于其他源系统。在服务器具有最大资源可用性(如下班后或周末和假日)时执行迁移。

后端任务

迁移期间运行的其他后端任务。最佳做法是在下班之后执行迁移,因此经常会出现迁移与本地服务器上运行的其他维护任务(如数据备份)相冲突的情况。

查看在迁移期间可能会运行的其他系统任务。建议在没有运行其他资源密集型任务时执行数据迁移。

注意      对于使用本地 Exchange 的客户,常见的后端任务是备份解决方案和 Exchange 存储维护

限制策略

使用限制策略保护电子邮件系统是一种常用做法,限制策略可设置在一定时间内从系统中提取数据的速度和数量的特定限制。

验证是否为电子邮件系统部署了限制策略。例如,Google Mail 会限制在一段时间内可提取的数据量。

Exchange 具有限制对本地邮件服务器(用于 IMAP 迁移)进行 IMAP 访问的策略以及限制 RPC over HTTP 协议访问(用于直接转换 Exchange 迁移和暂存 Exchange 迁移)的策略,具体取决于软件版本。

若要查看 Exchange 2013 组织中的限制设置,请运行 Get-ThrottlingPolicy cmdlet。有关详细信息,请参阅 Exchange 工作负载管理

有关 IMAP 限制的详细信息,请参阅将 IMAP 邮箱迁移到 Office 365

有关 RPC over HTTP 协议的详细信息,请参阅:

影响因素 2:迁移服务器

IMAP、直接转换和暂存迁移是云发起的数据拉取迁移方法,因此不需要专用的迁移服务器。但是,面向 Internet 的协议主机(IMAP 或 RPC over HTTP 协议)将作为用于将邮箱和邮箱数据迁移到 Office 365 的迁移服务器。因此,上述部分中关于当前电子邮件组织的数据源服务器的迁移性能影响因素和最佳做法也适用于 Internet 边缘服务器。对于 Exchange 2007、Exchange 2010 和 Exchange 2013、组织,客户端访问服务器将作为迁移服务器。

有关详细信息,请参阅:

影响因素 3:迁移引擎

在 Exchange 管理中心 中使用迁移仪表板执行 IMAP、直接转换和暂存 Exchange 迁移。此工具受 Office 365 迁移服务限制的约束。

解决方案和做法   

客户现在可以使用 Windows PowerShell 指定迁移并发(例如要同时迁移的邮箱数)。默认值为 20 个邮箱。创建迁移批处理后,可使用以下 Windows PowerShell cmdlet 将此默认值增加到最大值 100。

Set-MigrationEndPoint <Identity> –MaxConcurrentMigrations <value between 1 and 100>

有关详细信息,请参阅在 Office 365 中管理迁移批处理

注意: 如果数据源没有足够的资源来处理所有连接,建议不要使用高并发值。应该先使用较低的并发值,例如 10。然后在监视数据源性能期间增加此值,以避免最终用户访问问题。

影响因素 4:网络

验证测试   

根据迁移方法,可以尝试以下验证测试:

  • IMAP 迁移      使用示例数据预填充源邮箱。然后使用标准 IMAP 电子邮件客户端(如 Microsoft Outlook)从 Internet(本地网络外部)连接到源邮箱,然后通过确定从源邮箱下载所有数据所需的时间来评测网络性能。在没有其他限制的情况下,吞吐量应近似于客户在 Office 365 中使用 IMAP 迁移工具时达到的吞吐量。

  • 直接转换和暂存 Exchange 迁移      使用示例数据预填充源邮箱。然后使用 RPC over HTTP 协议从 Internet(本地网络外部)连接到采用 Outlook 的源邮箱。确保使用缓存模式进行连接。通过检查从源邮箱同步所有数据所需的时间来评测网络性能。在没有其他限制的情况下,吞吐量应近似于客户在 Office 365 中使用简单 Exchange 迁移工具时达到的吞吐量。

注意: 在实际的 IMAP、直接转换或暂存 Exchange 迁移过程中可能存在一定开销。但实际的吞吐量应近似于这些验证测试的结果。

影响因素 5:Office 365 服务

Office 365 基于资源运行状况的限制将影响使用本机 Office 365 简单迁移工具的迁移。请参阅 Office 365 基于资源运行状况的限制部分。

Office 365 服务中的移动请求

有关获取移动请求状态信息的常规信息,请参阅查看移动请求属性

与本地 Exchange 2010 中不同的是,在 Office 365 服务中,为迁移分配的迁移队列和服务资源在多个租户之间共享。这种共享会影响移动过程中每个阶段对移动请求的处理方式。

Office 365 中有两种类型的移动请求:

  • 新发起的移动请求      新客户迁移被视为新发起的移动请求。这些请求的优先级一般。

  • 数据中心内部移动请求      这些请求是由数据中心运营团队发起的邮箱移动请求。这些请求的优先级较低,因为移动请求延迟时,最终用户体验不会受到影响。

对状态为“已排队”和“正在进行”的移动请求可能造成的影响和延迟

  • 已排队的移动请求      此状态表明移动请求已排队,并且在等待 Exchange 邮箱复制服务选取。对于 Exchange 2003 移动请求,用户仍可在此阶段访问其邮箱。

    以下两个因素将影响邮箱复制服务对请求的选取:

    • 优先级      优先级较高的已排队移动请求会在优先级较低的移动请求之前被选取。这有助于确保客户迁移移动请求总是先于数据中心内部移动请求得到处理。

    • 队列中的位置      如果移动请求具有相同的优先级,那么请求进入队列的时间越早,邮箱复制服务选取它的时间就越早。由于同时可能有多个客户执行邮箱迁移,因此新移动请求在处理前留在队列中的情况很常见。

      通常,迁移规划过程中不会考虑邮箱请求在处理前在队列中等待的时间。这将导致客户分配不到足够时间来完成所有计划的迁移。

  • 正在进行的移动请求      此状态表明移动仍在进行中。如果是联机邮箱移动,用户仍可访问邮箱。对于脱机邮箱移动,用户邮箱将不可用。

    邮箱移动请求进入“正在进行”状态后,优先级不再重要,在现有的“正在进行”移动请求完成之前,将不会处理新移动请求,即使新移动请求具有较高的优先级也是如此。

最佳做法

规划      如上所述,由于 Exchange 2003 用户在混合迁移期间会失去访问权限,因此 Exchange 2003 客户通常更关注何时安排迁移以及迁移所需的时长。

计划要在特定时间段内进行迁移的邮箱数时,请考虑以下几点:

  • 请包括移动请求在队列中等待的时间。使用以下公式进行计算:

    (要迁移的邮箱总数) = ((总时间) – (平均排队时间)) * (迁移吞吐量)

    其中,迁移吞吐量等于每小时可迁移的邮箱总数。

    例如,假设有 6 小时来迁移邮箱。如果平均排队时间是 1 小时,迁移吞吐量为每小时 100 个邮箱,那么在 6 小时的时间内就能迁移 500 个邮箱:500 = (6 – 1) * 100.

  • 比最初计划更早地启动迁移以减少排队时间。邮箱排队时,Exchange 2003 用户仍可访问其邮箱。

确定排队时间      排队时间总是在变化,因为 Microsoft 不对客户的迁移计划进行管理。

若要确定可能的排队时间,客户可尝试在实际迁移开始之前的数小时安排一次测试移动。然后,根据观察到的请求排队时间,客户可以更准确地估计开始迁移的时间以及在指定时间段内可移动的邮箱数。

例如,假设测试迁移已在计划迁移开始之前 4 小时完成。客户确定测试迁移的排队时间约为 1 小时。然后,客户应考虑在最初计划时间的 1 小时前开始迁移,以确保有足够的时间完成所有迁移。

Office 365 迁移的第三方工具

第三方工具大多用于不涉及 Exchange 的迁移方案,如 Google Mail、IBM Lotus,Domino 和 Novell GroupWise。本部分将重点介绍第三方迁移工具使用的迁移协议,而不是实际产品和迁移工具。下表列出了适用于 Office 365 迁移方案的第三方工具的影响因素。

影响因素 1:数据源

清单

说明

最佳做法

系统性能

数据提取是一项资源密集型任务。源系统必须有足够的资源(如 CPU 时间和内存)才能提供最佳迁移性能。迁移过程中,在常规最终用户工作负载方面,源系统通常会接近于最大容量。如果系统资源不足,那么迁移产生的其他工作负载可能会影响最终用户。

在试点迁移测试过程中监视系统性能。如果系统繁忙,建议不要对特定系统执行很占用资源的迁移计划,因为这可能导致迁移变慢和服务可用性问题。如果可能,应通过增加硬件资源和减少系统中的负载来提高源系统性能。可通过将任务和用户移至未涉及迁移的其他服务器来减少系统负载。

有关详细信息,请参阅:

从存在多个邮箱服务器的本地 Exchange 组织进行迁移时,建议创建在多个邮箱服务器中均匀分布的迁移用户列表。根据各个服务器的性能,可以对该列表进一步微调以达到最大吞吐量。

例如,如果服务器 A 的资源可用性比服务器 B 高 50%,那么在同一个迁移批处理中让服务器 A 中多包含 50 % 的用户较为合理。类似的做法可应用于其他源系统。

在系统具有最大资源可用性时(如下班后或周末和假日)执行迁移。

后端任务

通常在迁移期间运行的其他后端任务。最佳做法是在下班之后执行迁移,因此经常会出现迁移与本地服务器上运行的其他维护任务(例如数据备份)相冲突的情况。

查看在迁移期间运行的其他系统任务。建议在没有其他占用资源较多的任务运行时,创建一个只针对数据迁移的明确的时间范围。

对于 Exchange 本地客户,常见任务是备份解决方案。有关详细信息,请参阅 Exchange 存储维护

限制策略

使用限制策略保护电子邮件系统是一种常用做法,该策略使用特定迁移方法设置在一定时间内从系统提取数据的速度和数量方面的特定限制。

验证是否为电子邮件系统部署了限制策略。例如,Google Mail 会限制在一段时间内可提取的数据量。

Exchange 具有限制对本地邮件服务器(用于 IMAP 迁移)进行 IMAP 访问的策略以及限制 RPC over HTTP 协议访问(用于直接转换 Exchange 迁移和暂存 Exchange 迁移)的策略,具体取决于软件版本。

有关 IMAP 限制的详细信息,请参阅优化 IMAP 迁移的方法

有关 RPC over HTTP 协议的详细信息,请参阅:

有关如何配置 Exchange Web 服务限制的详细信息,请参阅 Exchange 2010:了解客户端限制策略

影响因素 2:迁移服务器

大多数用于 Office 365 迁移的第三方工具由客户端发起,并会将数据推送到 Office 365。通常,这些工具需要迁移服务器。源服务器的系统性能、后端任务和限制策略等因素均适用于这些迁移服务器。

注意: 某些第三方迁移解决方案作为基于云的服务托管于 Internet 上,不需要本地迁移服务器。

解决方案和做法   

若要在使用迁移服务器时提高迁移性能,请应用影响因素 1:数据源部分中所述的最佳做法。

影响因素 3:迁移引擎

对于第三方迁移工具,最常用的协议是 Exchange Web 服务和 RPC over HTTP 协议。

Exchange Web 服务   

Exchange Web 服务是用于迁移到 Office 365 的推荐协议,因为它支持大型数据批处理,并且具有更好的面向服务的限制。在 Office 365 中,当在模拟模式下使用此协议时,使用 Exchange Web 服务的迁移不会消耗用户预算数量的 Office 365Exchange Web 服务资源,而是消耗预算资源的副本:

  • 同一管理员帐户发出的所有 Exchange Web 服务模拟呼叫都独立于对此管理员帐户使用的预算而进行计算。

  • 对于每个模拟会话,都创建了实际用户的预算卷影副本。此特定会话的所有迁移都将占用此卷影副本。

  • 模拟下的限制独立于每个用户迁移会话。

最佳做法   

  • 使用采用 EWA 模拟的第三方迁移工具的客户的迁移性能与基于 Exchange Web 服务的迁移和其他租户的服务资源使用量相当。因此,迁移性能将会不同。

  • 如有可能,客户应使用采用 Exchange Web 服务模拟的第三方迁移工具,因为这样通常比使用客户端协议(如 RPC over HTTP 协议)速度更快、效率更高。

RPC over HTTP 协议   

很多传统迁移解决方案都使用 RPC over HTTP 协议。此方法完全基于客户端访问模型(如 Outlook),可伸缩性和性能将受到限制,因为 Office 365 服务限制了访问(基于使用资源的是用户而不是应用程序的假设)。

最佳做法   

  • 对于使用 RPC over HTTP 协议的迁移工具,常见做法是通过添加更多迁移服务器并使用多个 Office 365 管理用户帐户来增加迁移吞吐量。此做法可实现并行的数据注入并获得较高的数据吞吐量,因为每个管理用户都受 Office 365 用户限制的约束。我们收到了一些报告,其中显示很多企业客户都必须安装 40 个以上的迁移服务器才能获得每小时 20-30 GB 的迁移吞吐量。

  • 在迁移工具开发阶段,考虑迁移邮件所需的 RPC 操作的数量非常重要。为了说明这一点,我们收集了 Office 365 服务捕获的日志,日志内容关于客户使用两个第三方迁移解决方案(由第三方公司开发)将邮箱迁移到 Office 365。我们比较了第三方公司开发的这两个迁移解决方案。我们比较了在每个迁移解决方案下两个邮箱的迁移情况,并且还通过在 Outlook 中上传一个 .pst 文件进行了比较。下面是比较的结果。

    方法

    邮箱大小

    项目计数

    迁移时间

    RPC 事务总数

    平均客户端延迟(毫秒)

    AvgCasRPCProcessingTime(毫秒)

    解决方案 A(邮箱 1)

    376.9 MB

    4,115

    4:24:33

    132,040

    48.4395

    18.0807

    解决方案 A(邮箱 2)

    249.3 MB

    12,779

    10:50:50

    423,188

    44.1678

    4.8444

    解决方案 B(邮箱 1)

    618.1 MB

    4,322

    1:54:58

    12,196

    37.2931

    8.3441

    解决方案 B(邮箱 2)

    56.7 MB

    2,748

    0:47:08

    5,806

    42.1930

    7.4439

    Outlook

    201.9MB

    3,297

    0:29:47

    15,775

    36.9987

    5.6447

    请注意,客户端处理时间和服务处理时间相似,但解决方案 A 迁移数据时执行了更多的 RPC 操作。由于每个操作都要消耗客户端延迟时间和服务器处理时间,因此,与解决方案 B 和 Outlook 相比,解决方案 A 迁移相同数量的数据的速度慢很多。

影响因素 4:网络

最佳做法   

对于使用 RPC over HTTP 协议的第三方迁移解决方案,下面提供一个评测潜在迁移性能的好方法:

  1. 从迁移服务器中,使用 RPC over HTTP 协议连接到使用 Outlook 的 Office 365 邮箱。确保连接时未使用缓存模式

  2. 将包含示例数据的大型 .pst 文件导入 Office 365 邮箱。

  3. 通过计算上传 .pst 文件所需的时间来评测迁移性能。在没有其他限制的情况下,迁移吞吐量应近似于客户从使用 RPC over HTTP 协议的第三方迁移工具获得的吞吐量。在实际迁移过程中存在其他开销,因此吞吐量可能稍有差异。

影响因素 5:Office 365 服务

Office 365 基于资源运行状况的限制将影响使用第三方迁移工具的迁移。请参阅 Office 365 基于资源运行状况的限制了解更多详细信息。

扩展你的技能
了解培训
抢先获得新功能
加入 Office 预览体验计划

此信息是否有帮助?

谢谢您的反馈!

谢谢你的反馈! 可能需要转接到 Office 支持专员。

×