Exchange Online 迁移性能和最佳做法

 

适用于:Exchange Online, Exchange Server, Exchange Server 2013

上一次修改主题:2017-04-09

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

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

Exchange Online 是 Office 365 的一部分,基于 Microsoft Exchange Server 为组织提供基于云的邮件解决方案。Exchange Online 支持通过多种方法将电子邮件、日历和联系人数据从现有邮件环境迁移到 Office 365。

有关 Office 365 网络和性能的详细信息,请转到我们的性能和调整部分

常用的迁移方法

迁移方法 描述 资源

IMAP 迁移

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

有关详细信息,请参阅 IMAP 迁移

直接转换迁移

使用直接转换迁移,在几天内便可将所有本地邮箱都迁移到 Exchange Online。如果计划将整个电子邮件组织移动到 Office 365 并在 Office 365 中管理用户帐户,您可以使用此迁移类型。您可以使用直接转换迁移将最多 2,000 个邮箱从本地 Exchange 组织迁移到 Exchange Online。还将迁移本地 Exchange 组织中的邮件联系人和通讯组。

有关详细信息,请参阅 直接转换 Exchange 迁移

暂存迁移

若计划将组织的所有邮箱最终迁移到 Exchange Online,可使用暂存迁移。使用暂存迁移可在数周或数月的时间内将成批本地邮箱迁移到 Exchange Online。您的目标将会是将电子邮件组织永久移动到 Office 365。

有关详细信息,请参阅 暂存 Exchange 迁移

混合部署

混合部署使组织可以将随其现有本地 Microsoft Exchange 组织提供的功能丰富的体验和管理控制扩展到云。混合部署可在本地 Exchange Server 2013 或 2010 组织与 Microsoft Office 365 中的 Exchange Online 之间提供单个 Exchange 组织的无缝外观。此外,混合部署还可以充当中间步骤,以完全移动到 Exchange Online 组织。

有关详细信息,请参阅Exchange Server 混合部署

第三方迁移

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

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

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

  • BitTitan   迁移到 Exchange Online 的解决方案提供商。

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

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

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

  • TransVault   Exchange Online 的迁移解决方案提供商。

下表对将邮箱和邮箱数据迁移到 Office 365 中的 Exchange Online 的不同迁移方法的性能观察结果进行了比较。这些结果基于内部测试和客户到 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(MRS 代理))1

第三方 MAPI 迁移

4-12 GB(20 个并发)3

第三方 EWS 迁移

5-10 GB(20 个并发)2

客户端上载(从 Outlook PST)

0.5 GB

1 观察到的单一邮箱移动吞吐量范围是每小时 0.3–1.0 GB。在可以保持小于 2% 瞬时失败停滞时间和小于 100ms 网络延迟的网络中,可以实现大于每个邮箱 1000 MB/h 的吞吐率。可以使用更多个并发邮箱迁移,实现更高的数据迁移速率。当内部部署 CAS (MRSProxy) 服务器达到硬件容量时,如果网络带宽不够或者网络延迟太高,单一邮箱移动吞吐量将会下降。请考虑添加更多服务器或暂时改进网络连接,以加快迁移速度。

2 观察到的单一 EWS 迁移吞吐量范围是每小时 0.2–0.5 GB。可以使用更多个并发迁移,实现更高的数据迁移速率。例如,如果有 100 20 个并发迁移,整体吞吐量范围将为每小时 20–5010-14 GB。当本地服务器或网络达到容量时,单一 EWS 迁移吞吐量将会下降。

3 观察到的单一 MAPI 迁移吞吐量范围是每小时 0.1-0.5 GB。可以使用更多个并发迁移,实现更高的数据迁移速率。当本地服务器或网络达到容量时,单一 MAPI 迁移吞吐量将会下降。

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

下表列出了影响迁移性能的常见因素。关于各迁移方法的相应部分中包含更多详细信息。

 

因素 描述 示例

数据源

用于托管要迁移的数据的设备或服务。由于硬件规格、最终用户工作量和后端维护任务的原因,数据源可能会有诸多限制。

Google Mail 限制了在特定时间段内可提取的数据量。

数据类型和密度

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

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

迁移服务器

很多迁移解决方案都使用“跳线盒”类型的迁移服务器或工作站来完成迁移。

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

迁移引擎

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

Microsoft Exchange 邮箱复制服务 (MRS) 有其自己的功能和限制。

本地网络设备

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

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

Office 365 服务

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

用户限制策略具有默认设置,并限制整体最大数据传输速率。

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

在部署 Office 365 服务之前,已部署 ffice 365 网络分析工具以帮助分析与网络有关的问题:每个实例设计为用于使用 Office 365 中的测试终结点测试特定区域。

为了更加直接、全面地测试从您的网络上的客户端计算机到您的 Office 365 服务的连接,可以在静默模式下,以固定时间间隔从多个工作站安装和运行 Microsoft Exchange 客户端性能分析工具。

若要帮助诊断和修复本地计算机上的 Outlook 365 的问题,可以下载适用于 Office 365 的 Microsoft 支持和恢复助手

 

因素 说明 最佳做法

网络容量

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

  • 识别可用网络容量并确定最大上载容量。

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

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

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

网络稳定性

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

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

网络延迟

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

将数据迁移到 Exchange Online 邮箱的操作依赖于您的 Internet 连接。Internet 延迟会影响总体迁移性能。

此外,同一公司的用户可能具有驻留在不同地理位置数据中心中的云邮箱。根据客户 ISP 的不同,迁移性能可能不同。

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

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

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

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

  • 用户限制

  • 迁移服务限制

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

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

用户限制将影响大多数第三方迁移工具和客户端上载迁移方法。这些迁移方法使用客户端访问协议(如 RPC over HTTP)将邮箱数据迁移到 Exchange Online 邮箱。这些工具通常用于从 IBM Lotus Domino 和 Novell GroupWise 等平台迁移数据。

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

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

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

  • IMAP 迁移

  • 直接转换 Exchange 迁移

  • 暂存 Exchange 迁移

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

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

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

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

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

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

  • 1/25/2012 12:56:01 AM [BL2PRD0410CA012] Copy progress:723/1456 messages, 225.8 MB (236,732,045 bytes)/416.5 MB (436,712,733 bytes).

  • 1/25/2012 12:57:53 AM [BL2PRD0410CA012] Move for mailbox '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication).Failure Reason:Database edbf0766-1f2a-4552-9115-bb3a53a8380b doesn’t satisfy constraint SecondDatacenter.There are no available healthy database copies.Will wait until 1/25/2012 1:27:53 AM.

  • 1/25/2012 12:58:24 AM [BL2PRD0410CA012] Request is no longer stalled and will continue.

解决方案和实践

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

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

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

 

检查表 说明 最佳做法

系统性能

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

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

有关详细信息,请参阅:

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

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

后端任务

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

查看在迁移期间可能会运行的其他系统任务。我们建议在没有运行其他占用资源较多的任务时执行数据迁移。

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

限制策略

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

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

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

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

有关 IMAP 限制的详细信息,请参阅将邮箱从 IMAP 服务器迁移到 Exchange Online 邮箱

有关 RPC over HTTP 限制的详细信息,请参阅以下资源:

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

有关详细信息,请参阅:

  1. Exchange 2013 工作负载管理

  2. Exchange 2010:客户端访问服务器计数器

  3. Exchange 2007:监视客户端访问服务器

解决方案和实践

为获得更好的迁移性能,应该应用之前描述的同一最佳做法。

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

解决方案和实践

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

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

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

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

验证测试

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

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

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

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

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

混合部署迁移支持本地 Exchange 2003、Exchange 2007、Exchange 2010 和 Exchange 2013 服务器与 Office 365 中的 Exchange Online 之间的顺利迁移。

混合部署迁移是到目前为止将邮箱数据迁移到 Office 365 的最快迁移方法。我们看到在实际客户部署期间吞吐量高达 100 GB/小时。下表列出了适用于本机 Office 365 混合迁移方案的因素。

 

检查表 说明 最佳做法

系统性能

数据提取是一项非常占用资源的任务。源系统必须具有足够的资源(如 CPU 时间和内存)才能提供更佳的迁移性能。在迁移时,源系统通常接近于最大容量,以便为常规最终用户工作负载提供服务 - 其他迁移工作负载有时甚至会因为缺少系统资源而妨碍最终用户访问。

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

有关详细信息,请参阅:

当从存在多个邮箱服务器和多个数据库的本地 Exchange 组织迁移时,我们建议创建在多个邮箱服务器和数据库之间均匀分布的迁移用户列表。根据各个服务器的性能,可以对该列表进一步微调以最大限度地增加吞吐量。

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

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

后端任务

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

查看在迁移期间可能会运行的其他系统任务。我们建议在没有运行其他占用资源较多的任务时执行数据迁移。

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

混合部署迁移是云发起的数据提取/推送迁移,Exchange 2013 或 Exchange 2010 SP3 混合服务器充当迁移服务器。这一点经常被忽略,客户会使用规模较小的虚拟机充当混合服务器。这将导致迁移性能降低

最佳做法

除了应用之前描述的最佳做法之外,我们还测试了以下最佳做法,这些做法提高了实际客户迁移的迁移性能:

  • 对 Exchange 2013 和 2010 混合服务器使用强大的服务器类物理计算机而不是虚拟机。

  • 使用多台位于客户的网络负载平衡器之后的混合服务器。

例如,在实际客户迁移中,我们已通过以下配置达到了一致的 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 个。

混合部署迁移使用本机 Office 365 工具。它受 Office 365 迁移服务限制的约束。

Exchange 2003 和 Exchange 2007 SP2、Exchange 2010 SP3 和 Exchange 2013 SP1

从 Exchange 2003 进行迁移时,最终用户体验存在一个重大差异。与 Exchange 2007 SP2、Exchange 2010 SP3 和 Exchange 2013 SP1 不同,Exchange 2003 最终用户将无法在迁移数据时访问其邮箱。因此,Exchange 2003 客户通常更关注何时安排迁移以及迁移所需的时间,尤其是在因邮箱较大或网速较慢而导致迁移性能降低时。

Exchange 2003 迁移对中断也非常敏感。例如,在实际客户迁移中,在 10 GB 邮箱迁移期间,邮箱迁移完成 50% 时发生了服务事件。处理数据迁移的 Office 365 客户端访问服务器必须重新启动才能解决问题。在这种情况下,必须重新启动邮箱迁移,这意味着客户必须重新迁移所有 10 GB 的数据。此时迁移无法从停止的点恢复。但 Exchange 2007 SP2、Exchange 2010 SP3 和 Exchange 2013 SP1 却能在中断后恢复迁移。

最佳做法

有些客户选择对规模较大且敏感的 Exchange 2003 邮箱执行两跳迁移:

  • 第一个跳跃   将邮箱从 Exchange 2003 迁移到通常作为混合服务器的 Exchange 2010 SP3 服务器。第一个跳跃是脱机移动,但它通常是通过本地网络执行的速度极快的迁移。

  • 第二个跳跃   将邮箱从 Exchange 2010 SP3 迁移到 Office 365。

第二个跳跃是联机移动,提供更佳的用户体验和容错功能。这个两跳方法需要使用临时本地 Exchange 2010 用户邮箱的 Exchange 2010 许可证。

邮箱复制服务代理 (MRSProxy)

MRS 代理是与 Office 365 端运行的邮箱复制服务结合使用的本地迁移功能。有关详细信息,请参阅了解移动请求

最佳做法

可以为本地 Exchange 2010 SP3 配置最大数量的 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 服务

注意注意:
对于大多数客户迁移,无需更改默认 MRSMaxConnections 值。如果需要保护源服务器以免迁移负载过大,客户可以减少连接数。此设置按每个 MRSProxy 服务器进行设置。如果客户有两个 MRSProxy 服务器,每个服务器都设置为 10 个连接,它们的总 MRSProxy 连接数将为 20 (2 x 10)。有关在本地 Exchange 2010 组织中配置 MRSProxy 服务的详细信息,请参阅在远程客户端访问服务器上启动 MRSProxy 服务

验证测试

对于 Exchange 2013 和 2010 客户,可通过执行多个测试邮箱迁移完成对混合迁移网络性能的测试。或者,也可以使用 -SuspendWhenReadyToComplete 选项迁移实际用户邮箱以满足迁移性能指标。测试完成时,删除移动请求以避免影响最终用户。

有关 Exchange 2013 移动请求的详细信息,请参阅 New-MoveRequest

有关 Exchange 2010 移动请求的详细信息,请参阅 New-MoveRequest

基于 Office 365 资源运行状况的限制将影响使用 Office 365 混合部署迁移的迁移。请参阅上面的基于 Office 365 资源运行状况的限制部分,以了解更多详细信息。

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

在 Office 365 服务中,在执行移动请求时,一般本地 Exchange 2010 组织中存在一个重大差异。在 Office 365 中,为迁移分配的迁移队列和服务资源在多个租户之间共享。这将影响移动请求在移动过程中每个阶段的处理方式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

检查表 说明 最佳做法

系统性能

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

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

有关详细信息,请参阅:

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

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

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

后端任务

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

查看在迁移期间运行的其他系统任务。我们建议在没有其他占用资源较多的任务运行时为数据迁移创建清楚的时间范围。

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

限制策略

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

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

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

有关 IMAP 限制的详细信息,请参阅将邮箱从 IMAP 服务器迁移到 Exchange Online 邮箱

有关 RPC over HTTP 限制的详细信息,请参阅以下资源:

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

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

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

解决方案和实践

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

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

Exchange Web 服务

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

  • 同一管理员帐户发出的所有 EWS 模拟呼叫都独立于应用于此管理员帐户的预算进行计算。

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

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

最佳做法

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

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

RPC over HTTP

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

最佳做法

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

  • 在迁移工具开发阶段,应考虑迁移邮件所需的 RPC 操作的数量,这点很重要。为了说明这一点,我们收集了 Office 365 服务捕获的关于客户用于将邮箱迁移到 Office 365 的两个第三方迁移解决方案(由第三方公司开发)的日志。我们比较了第三方公司开发的这两个迁移解决方案。我们比较了在每个迁移解决方案下两个邮箱的迁移情况,并且还通过在 Microsoft 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 迁移相同数量的数据的速度慢很多。

最佳做法

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

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

  2. 将包含示例数据的大型 PST 文件导入 Exchange Online 邮箱。

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

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

 
显示: