Office 365 移轉效能和最佳做法

有許多途徑可將資料從內部部署電子郵件組織移轉到 Microsoft Office 365。規劃移轉到 Office 365 時,如何改善資料移轉效能並最佳化移轉速度是相當常見的問題。

附註: 本主題中列出的效能資訊不適用於專用訂閱方案的 Office 365 服務。如需有關專用方案的詳細資訊,請參閱 Office 365 專用方案服務描述

本主題內容

將電子郵件移轉到 Office 365 的概觀

將多個電子郵件帳戶移轉到 Office 365 的方法所述,Office 365 支援多種將電子郵件、行事曆和連絡人資料從您現有的郵件環境移轉到 Office 365 的方法。

如需有關 Office 365 網路和效能的詳細資訊,請參閱 Office 365 的網路規劃與效能調整

常用移轉方法

移轉方法

描述

資源

網際網路訊息存取通訊協定 (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;每個內部移轉 Exchange 2013 或 2010 CAS (Microsoft Exchange 信箱複寫服務 (MRSProxy 服務)),具備 20 個並行移轉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 會限制一段特定時間內可擷取的資料量。

資料類型和密度

由於客戶業務的獨特性質,信箱內的郵件項目類型和組合會有很大的差異。

一個具有 400 個項目的 4 GB 信箱 (每個項目各有 10 MB 的附件),會比一個具有 100,000 個較小項目的 4 GB 信箱移轉得更快。

移轉伺服器

許多移轉解決方案會使用 "Jump Box" 類型的移轉伺服器或工作站來完成移轉。

客戶通常會使用低效能的虛擬機器來託管 MRSProxy 服務,以進行混合式部署或用戶端電腦非混合式移轉。

移轉引擎

負責從來源伺服器提取資料的資料移轉引擎,會視需要轉換資料。接著,引擎會透過網路傳輸資料,以及將資料插入到 Office 365 信箱。

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

內部部署網路設備

端對端網路效能 (從資料來源到 Exchange Online 用戶端存取伺服器) 會影響移轉效能。

內部部署組織上的防火牆設定和規格。

Office 365 服務

Office 365 具有可管理移轉工作量的內建支援和功能。

使用者節流原則有預設的設定,而且會限制整體資料傳送速率的上限。

網路效能因素

本節描述改善移轉期間網路效能的最佳做法。此為一般性討論,因為對移轉期間網路效能的最大影響是與協力廠商硬體和網際網路服務提供者 (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 信箱需仰賴網際網路連線。網際網路延遲會影響整體的移轉效能。

此外,同一間公司的使用者可能會有位於不同地理位置之資料中心的雲端信箱。移轉效能可能會視客戶的 ISP 而有所不同。

  • 評估所有 Microsoft 資料中心潛在的網路延遲,以協助確保結果一致 (這也有助於確保使用者的體驗一致)。與您的 ISP 合作處理網際網路相關問題。

  • 將 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 AM [BL2PRD0410CA012] 複製進度:723/1456 封郵件,225.8 MB (236,732,045 位元組)/416.5 MB (436,712,733 位元組)。

  • 2012/1/25 12:57:53 AM [BL2PRD0410CA012] 已停止移動信箱 '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx',因為無法滿足資料庫 'NAMPRD04DG031-db081' (代理程式 MailboxDatabaseReplication) 的 DataMoveReplicationConstraint。失敗原因:資料庫 edbf0766-1f2a-4552-9115-bb3a53a8380b 不符合條件約束 SecondDatacenter。沒有可用的正常資料庫份數。將等候至 2012/1/25 1:27:53 AM。

  • 2012/1/25 12:58:24 AM [BL2PRD0410CA012] 要求不再停止且將繼續。

解決方案和做法   

如果您遇到類似的情形,請等候 Office 365 服務復原。如需詳細資訊,請參閱 Office 365 入口網站的「服務健康情況」一節。

非混合式部署移轉的效能因素和最佳做法

本節描述使用網際網路訊息存取通訊協定 (IMAP)、完全移轉或分段移轉方法時影響移轉的因素。本節也找出改善移轉效能的最佳做法。

因素 1:資料來源

下表說明您目前電子郵件組織中的來源伺服器對移轉的影響,並且降低對移轉影響的最佳做法。

檢查清單

描述

最佳做法

系統效能

資料擷取是耗用大量資源的工作。來源系統必須有足夠的資源 (例如 CPU 時間和記憶體),以提供最佳移轉效能。就一般使用者工作量而言,在移轉期間,來源系統通常會接近滿載。如果系統資源不足,移轉所引起的額外工作量可能會影響使用者。

在試驗移轉測試期間監控系統效能。如果系統忙碌,建議避免特定系統的激烈移轉排程,因為可能會導致移轉緩慢和服務可用性問題。請盡可能增加硬體資源以提升來源系統效能,並將工作和使用者移轉到未包含在移轉中的其他伺服器以降低系統負載。

如需詳細資訊,請參閱:

從有多個信箱伺服器的內部部署 Exchange 組織進行移轉時,建議您建立平均散佈於多個信箱伺服器的移轉使用者清單。根據個別伺服器效能而定,可進一步微調清單以達到最大的輸送量。

例如,如果伺服器 A 的資源可用性比伺服器 B 多出 50%,則在同一個移轉批次中伺服器 A 多出 50% 的使用者是合理的。可將類似做法套用到其他來源系統。請在伺服器有最大資源可用性時執行移轉,例如在數小時之後或在週末和假日時。

後端工作

其他後端工作會在移轉期間執行。因為最佳做法是在營業時間之後執行移轉,所以移轉很常與在內部部署伺服器上執行的維護工作產生衝突,例如資料備份。

檢閱可能會在移轉期間執行的其他系統工作。建議您在未執行其他耗用大量資源的工作時執行資料移轉。

附註   :針對使用內部部署 Exchange 的客戶,備份解決方案和 Exchange 儲存庫維護是常見的後端工作。

節流原則

使用節流原則保護電子郵件系統是很常見的做法,它會設定一段特定時間內可從系統擷取資料量之速度的特定限制。

請確認您的電子郵件系統所部署的節流原則。例如,Google Mail 會限制一段特定時間內可擷取的資料量。

視版本而定,Exchange 具有會限制網際網路訊息存取通訊協定 (IMAP) 內部部署郵件服器 (網際網路訊息存取通訊協定 (IMAP) 移轉時使用) 和經由 HTTP 通訊協定存取的 RPC (Exchange 完全移轉和 Exchange 分段移轉時使用) 存取的原則。

若要檢查 Exchange 2013 組織中的節流設定,請執行 Get-ThrottlingPolicy Cmdlet。如需詳細資訊,請參閱 Exchange 工作量管理

如需有關網際網路訊息存取通訊協定 (IMAP) 節流的詳細資訊,請參閱將 IMAP 信箱移轉到 Office 365

如需有關經由 HTTP 通訊協定節流的 RPC 之詳細資訊,請參閱:

因素 2:移轉伺服器

網際網路訊息存取通訊協定 (IMAP)、完全移轉和分段移轉是由雲端發起的資料提取移轉方法,因此不需要專用移轉伺服器。不過,網際網路對應通訊協定主機 (網際網路訊息存取通訊協定 (IMAP) 或經由 HTTP 通訊協定的 RPC) 可當做移轉伺服器,將信箱和信箱資料移轉到 Office 365。因此,有關您目前電子郵件組織之資料來源伺服器的移轉效能因素和最佳做法 (如上一節所述),也適用於網際網路 Edge Server。針對 Exchange 2007、Exchange 2010 和 Exchange 2013 組織,用戶端存取伺服器可當做移轉伺服器。

如需詳細資訊,請參閱:

因素 3:移轉引擎

網際網路訊息存取通訊協定 (IMAP)、完全移轉和分段移轉 Exchange 是使用 Exchange 系統管理中心的移轉儀表板執行。這會受到 Office 365 移轉服務節流限制。

解決方案和做法   

現在客戶可以使用 Windows PowerShell 指定移轉並行數目 (例如,要同步移轉的信箱數量)。預設值為 20 個信箱。建立移轉批次後,您可以使用下列 Windows PowerShell Cmdlet 將這增加到最多 100 個。

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

如需詳細資訊,請參閱管理 Office 365 中的移轉批次

附註: 如果您的資料來源沒有足夠的資源可以處理所有連線,建議避免使用大量的並行數目。請從小量的並行數值開始,例如 10。請隨著監控資料來源效能逐漸增加此數字,以免產生使用者存取問題。

因素 4:網路

驗證測試   

視移轉方法而定,您可以嘗試下列驗證測試:

  • 網際網路訊息存取通訊協定 (IMAP) 移轉   :使用範例資料預先填入來源信箱。接著,請從網際網路 (您的內部部署網路之外) 連線到來源信箱,使用 Microsoft Outlook 等標準網際網路訊息存取通訊協定 (IMAP) 電子郵件用戶端,然後判定從來源信箱下載所有資料需要多久時間,以測量網路效能。假設沒有其他限制,輸送量應該會類似於客戶使用 Office 365 中的網際網路訊息存取通訊協定 (IMAP) 移轉工具可獲得之輸送量。

  • 完全移轉和分段移轉 Exchange   :使用範例資料預先填入來源信箱。然後,透過經由 HTTP 通訊協定的 RPC,使用 Outlook 從網際網路 (您的內部部署網路之外) 連線到來源信箱。請確認您使用快取模式進行連線。檢查從來源信箱同步處理所有資料需要多久時間,以測量網路效能。假設沒有其他限制,輸送量應該會類似於客戶使用 Office 365 中的 Exchange 簡易移轉工具可獲得之輸送量。

附註: 在實際網際網路訊息存取通訊協定 (IMAP)、完全移轉或分段移轉 Exchange 期間,會有一些額外負荷。不過,實際輸送量應該會類似這些驗證測試的結果。

因素 5:Office 365 服務

Office 365 資源健康情況節流會影響使用原生 Office 365 簡易移轉工具的移轉。請參閱 Office 365 資源健康情況節流一節。

Office 365 服務中的移動要求

如需有關取得移動要求之狀態資訊的一般資訊,請參閱檢視移動要求內容

在 Office 365 服務中 (不像在內部部署 Exchange 2010 中),租用戶之間會共用針對移轉所配置的移轉佇列和服務資源。此共用會影響在移轉處理程序的每個階段要如何處理移動要求。

Office 365 中有兩種類型的移動要求:

  • 上線移動要求   :會將新客戶移轉視為上線移動要求。這些要求有標準的優先順序。

  • 資料中心內部移動要求   :這些是由資料中心作業小組所發起的信箱移動要求。這些要求的優先順序較低,因為如果移動要求延遲,使用者體驗並不會受到影響。

對於狀態為「已佇列」和「正在進行」的移動要求會有潛在影響和延遲。

  • 已佇列的移動要求   :此狀態指定移轉已經進入佇列,而且正在等候由 Exchange 信箱複寫服務接續。針對 Exchange 2003 移動要求,使用者仍可在此階段存取其信箱。

    影響信箱複寫服務會接續哪個要求的兩項因素如下:

    • 優先順序   :會先接續優先順序較高的已佇列移動要求,然後再接續優先順序較低的移動要求。這有助於確保一律先處理客戶移動要求,然後再處理資料中心內部移動要求。

    • 佇列中的位置   :如果移動要求具有相同的優先順序,要求愈早進入佇列,信箱複寫服務就會愈早接續處理它。因為同時可能會有多個客戶執行信箱移轉,新移動要求在獲得處理前會維持在佇列中,這是正常的現象。

      在規劃移轉期間,通常不會考慮到信箱要求獲得處理前在佇列中等候的時間。這會導致未分配足夠的時間讓客戶完成所有規劃的移轉。

  • 正在進行的移動要求   :此指定的狀態移動仍在進行中。如果這是線上信箱移轉,使用者仍可存取信箱。如果是離線信箱移轉,使用者的信箱則會無法存取。

    在信箱移動要求的狀態為「正在進行」之後,優先順序不再重要,而且在現有「正在進行」移動要求完成之前不會處理新的移動要求,即使新移動要求具有較高的優先順序。

最佳做法

規劃   :如先前所述,由於 Exchange 2003 使用者在混合式移轉期間會失去存取,Exchange 2003 客戶通常比較擔憂要何時排定移轉以及移轉會需要多久的時間。

當您規劃要在一段特定時間內移轉的信箱數量時,請考量下列事項:

  • 包含移動要求在佇列中等候的時間。使用下列公式進行計算:

    (要移轉的信箱總數量) = ((總時間) - (平均佇列時間)) * (移轉輸送量)

    其中移轉輸送量等於每個小時可移轉的信箱總數量。

    例如,假設您有六小時的空檔可以移轉信箱。如果平均佇列時間為一小時,而您有每小時 100 個信箱的移轉輸送量,您可以在六小時的時間範圍內移轉 500 個信箱:500 = (6 - 1) * 100。

  • 比一開始的規劃更早開始進行移轉,以降低佇列中的時間。當信箱進入佇列時,Exchange 2003 使用者仍可存取其信箱。

判定佇列時間   :佇列時間會一直變化,因為 Microsoft 不會管理客戶的移轉排程。

若要判定可能的佇列時間,客戶可以嘗試將測試移轉排定在實際移轉開始的數小時之前。然後,根據觀察到要求處於佇列中的時間,客戶可以更完善地估算要在何時開始進行移轉,以及在一段特定時間內可移轉的信箱數量。

例如,如果測試移轉已在規劃的移轉開始前四小時完成。客戶會判定測試移轉的佇列時間為大約一小時。然後,客戶應考慮比原本規劃的早一小時開始進行移轉,以確保有足夠的時間可以完成所有移轉。

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) 移轉時使用) 和經由 HTTP 通訊協定存取的 RPC (Exchange 完全移轉和 Exchange 分段移轉時使用) 存取的原則。

如需有關 IMAP 節流的詳細資訊,請參閱最佳化 IMAP 移轉的相關提示

如需有關經由 HTTP 通訊協定節流的 RPC 之詳細資訊,請參閱:

如需有關如何設定 Exchange Web 服務節流的詳細資訊,請參閱 Exchange 2010:了解用戶端節流原則

因素 2:移轉伺服器

大部分的 Office 365 協力廠商工具是初始化用戶端,而且會將資料推送到 Office 365。這些工具通常會需要移轉伺服器。來源伺服器的系統效能、後端工作和節流原則等因素適用於這些移轉伺服器。

附註: 某些協力廠商移轉解決方案是做為雲端服務在網際網路上受到託管,而且不需要內部部署移轉伺服器。

解決方案和做法   

若要在使用移轉伺服器時改善移轉效能,請套用如因素 1:資料來源一節中所述相同的最佳做法。

因素 3:移轉引擎

針對協力廠商移轉工具,最常見的通訊協定為 Exchange Web 服務和經由 HTTP 通訊協定的 RPC。

Exchange Web 服務   

Exchange Web 服務是移轉到 Office 365 時建議使用的通訊協定,因為它支援大量資料批次,而且有更好的服務導向節流。在 Office 365 中於模擬模式使用時,使用 Exchange Web 服務的移轉不會耗用使用者的 Office 365 Exchange Web 服務預算資源量,而是會耗用預算資源的複本:

  • 同一個系統管理員帳戶執行的所有 Exchange Web 服務模擬呼叫都會與適用於此系統管理員帳戶的預算分開計算。

  • 針對每個模擬工作階段,會建立實際使用者預算的陰影複製。此特定工作階段的所有移轉都會耗用此陰影複製。

  • 模擬下的節流會隔離到每個使用者移轉工作階段。

最佳做法   

  • 使用 EWA 模擬的協力廠商移轉工具之客戶的移轉效能,會與其他租用戶之基於 Exchange Web 服務的移轉和服務資源使用量相互競爭。因此,移轉效能會有所差異。

  • 客戶應盡可能使用 Exchange Web 服務模擬的協力廠商移轉工具,因為它通常比較快,而且比使用經由 HTTP 通訊協定的 RPC 等用戶端通訊協定更有效率。

經由 HTTP 通訊協定的 RPC   

許多傳統移轉解決方案使用經由 HTTP 通訊協定的 RPC。此方法完全基於 Outlook 等用戶端存取模型,而且會限制擴充性和效能,因為 Office 365 服務節流存取是以使用者而不是應用程式的使用量為假設依據。

最佳做法   

  • 針對使用經由 HTTP 通訊協定的 RPC 之移轉工具,新增更多移轉伺服器並使用多個 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.9 MB

    3,297

    0:29:47

    15,775

    36.9987

    5.6447

    請注意,用戶端和服務處理程序時間是類似的,但解決方案 A 需要更多的 RPC 作業來移轉資料。由於每個作業都會耗用用戶端延遲時間和伺服器處理程序時間,解決方案 A 會比解決方案 B 與 Outlook 移轉相同的資料量慢很多。

因素 4:網路

最佳做法   

針對使用經由 HTTP 通訊協定的 RPC 之協力廠商移轉解決方案,有個好方法可以測量可能的移轉效能:

  1. 透過經由 HTTP 通訊協定的 RPC,從移轉伺服器使用 Outlook 連線到 Office 365 信箱。請確認您不是使用快取模式進行連線。

  2. 將含有範例資料的大型 .pst 檔案匯入到 Office 365 信箱。

  3. 計算上傳 .pst 檔案需要多久時間以測量移轉效能。假設沒有其他限制,移轉輸送量應與客戶從經由 HTTP 通訊協定的 RPC 協力廠商移轉工具取得的類似。在實際移轉期間有額外負荷,因此輸送量可能會稍微不同。

因素 5:Office 365 服務

Office 365 資源健康情況節流會影響使用協力廠商移轉工具的移轉。如需詳細資訊,請參閱 Office 365 資源健康情況節流

擴展您的技能
探索訓練
優先取得新功能
加入 Office 測試人員

這項資訊有幫助嗎?

感謝您的意見反應!

感謝您的意見反應! 我們將協助您與其中一位 Office 支援專員連絡以深入了解您的意見。

×