本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

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 網路與效能,我們效能與調整] 區段中head 一段的詳細資訊。

常用的移轉方法

移轉方法 描述 資源

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 online 企業訊息和共同作業環境之間移轉之產品的提供者。

  • 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)

混合移轉

每個內部部署 Exchange 2013 的 10 14 GB 或 2010 CAS (MRS Proxy) 與 20 個同時移動1

協力廠商 MAPI 移轉

4-12 GB (並行數目 20) 3

協力廠商 EWS 移轉

5-10 GB (並行數目 20) 2

用戶端上傳 (從 Outlook PST)

0.5 GB

1觀察到單一信箱移動輸送量處於 0.3 – 1.0 GB/小時範圍。大於 1000 MB/h 個別信箱輸送量速度與可以維持小於 2%暫時性失敗區位時間和小於 100ms年網路延遲網路,可達到更大。更多並行信箱移轉可用來達到更高的資料移轉率。當內部 CA (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 限制特定期間內可擷取的資料量。

資料類型和密度

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

含有 400 個項目且每個項目含有 10 MB 附件的 4-GB 信箱,會比含有 100,000 個較小項目的 4-GB 信箱移轉得更快。

移轉伺服器

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

客戶通常使用低效能的虛擬機器來裝載 MRSProxy 以進行混合部署或用戶端 PC 非混合移轉。

移轉引擎

負責從來源伺服器提取資料的資料移轉引擎,會視需要轉換資料、透過網路傳送資料,以及在 Exchange Online 信箱中插入資料。

Microsoft Exchange 信箱複寫服務 (MRS) 有其專屬功能和限制。

內部部署網路設備

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

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

Office 365 服務

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

使用者節流原則具有預設設定,並限制整體最大資料傳送速率。

本節說明在移轉期間提升網路效能的最佳作法。此為一般性討論,因為對移轉期間之網路效能最大的影響與協力廠商硬體和網際網路服務提供者 (ISP) 有關。

部署 Office 365 網路分析工具來協助分析網路相關問題部署 Office 365 服務之前:。每個這些執行個體的設計測試使用 Office 365 中的測試的結束點的特定區域。

較直接且徹底測試您網路上的用戶端電腦從您的 Office 365 服務、 Microsoft Exchange 用戶端效能 Analyzer 可安裝及執行從多個工作站及以無訊息模式固定時間間隔。

為了協助您診斷與本機電腦上修正 Outlook 365 的問題,您可以下載Microsoft 支援與 Office 365 的助理復原

 

因素 描述 最佳作法

網路容量

將信箱移轉至 Exchange Online 所需的時間取決於網路的可用容量和最大容量。

  • 識別您可用的網路容量,並判斷其最大上傳容量。

  • 請連絡您的 ISP 以確認配置的頻寬並取得有關限制的詳細資訊,例如特定期間內可傳送的總資料量。

  • 使用工具評估實際網路容量。請務必測試從內部部署資料來源到 Microsoft 資料中心閘道伺服器的端對端資料流程。

  • 識別網路上會影響網路容量的其他負載 (例如備份公用程式和排程維護)。

網路穩定性

高速網路不一定能產生高速移轉。若網路不穩定,會由於錯誤修正,而使資料傳送花費較長的時間。根據移轉類型,錯誤修正可能會對移轉效能造成顯著影響。

網路硬體和驅動程式問題通常會導致網路穩定性問題。請與硬體廠商合作以了解您的網路裝置,並套用廠商建議的最新驅動程式和軟體更新。

網路延遲

在網路防火牆設定的入侵偵測功能通常會導致網路大幅延遲,進而影響移轉效能。

將資料移轉至 Exchange Online 信箱需仰賴網際網路連線。網際網路延遲會影響整體移轉效能。

此外,相同公司的使用者可能會在不同地理位置的資料中心擁有雲端信箱。因此根據客戶的 ISP,可能會有不同的移轉效能。

  • 評估對所有潛在 Microsoft 資料中心的網路延遲,以協助確保結果一致。(這麼做也有助確保使用者擁有一致的經驗)。請與 ISP 合作以解決網際網路的相關問題。

  • 新增至 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。這表示的三個信箱的最大值都會在移轉期間任何特定時間移轉。您可以增加的並行的信箱移轉 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).失敗原因:Database edbf0766-1f2a-4552-9115-bb3a53a8380b doesn’t satisfy constraint SecondDatacenter.沒有可用的正常資料庫副本。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指令程式。如需詳細資訊,請參閱Exchange Workoad 管理

如需 IMAP 節流的詳細資訊,請參閱將電子郵件從 IMAP 伺服器遷移至 Exchange Online 信箱

如需有關 RPC over HTTP 節流的詳細資訊,請參閱:

IMAP、轉換和分段移轉是雲端啟動的資料提取移轉方法,因此不需要專用移轉伺服器。但是,網際網路對向通訊協定主機 (IMAP 或 RPC over HTTP) 會擔任移轉伺服器,將信箱和信箱資料移轉至 Office 365。因此,上一節所述有關目前電子郵件組織資料來源伺服器的移轉效能因素和最佳作法也適用於網際網路 Edge Server。對於 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 遷移   預先以範例資料填入來源信箱。然後從網際網路 (內部部署網路外部),使用 Microsoft Outlook 等標準 IMAP 電子郵件用戶端連線至來源信箱,再判斷從來源信箱下載所有資料所需的時間,以測量網路效能。若無其他限制,輸送量會類似客戶使用 Office 365 的 IMAP 遷移工具所可取得的輸送量。

  • Cutover 與分段的 Exchange 遷移  預先填入範例資料的來源信箱。然後 (您的內部網路以外) 網際網路連線至來源信箱透過 Microsoft Outlook 使用 RPC over HTTP。協助確保您正在使用快取模式連接。度量網路效能藉由檢查同步處理來自來源信箱的所有資料所需的時間長度。輸送量會類似新客戶能使用 Office 365 中使用的簡易 Exchange 移轉工具假設有其他條件約束。

注意事項注意事項:
雖然實際 IMAP、轉換或分段 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 至網際網路;內部網路為 1 GB 加上 10 GB 光纖骨幹。

  • 硬體  兩部用戶端存取/中樞 (實體) 伺服器的規格:

    • CPU:Intel® Xeon® CPU E5520 @ 2.27 GHz 2.26 GHz (2 個處理器)。

    • RAM:24 GB。

    • 磁碟:八個,每個磁碟 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 授權。

信箱複寫服務 Proxy (MRSProxy)

MRS Proxy 會搭配 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 組織中的 MRS Proxy 服務的詳細資訊,請參閱 <啟動遠端的用戶端存取伺服器上的 MRSProxy 服務

驗證測試

若為 Exchange 2013 和 2010 客戶,可透過執行多個測試信箱移轉來完成混合移轉的網路效能測試。或者,您可使用 -SuspendWhenReadyToComplete 選項移轉實際使用者信箱,以取得移轉效能的指示。測試完成之後,請移除該移動要求以避免影響使用者。

如需 Exchange 2013 移動要求的詳細資訊,請參閱 New-MoveRequest

如需 Exchange 2010 移動要求的詳細資訊,請參閱New-moverequest

Office 365 資源狀況節流會影響使用 Office 365 混合部署移轉執行的移轉。如需詳細資訊,請參閱以上的「Office 365 資源狀況節流」一節。

如需取得移動要求的狀態資訊的一般資訊,請參閱 < View Move Request Properties

在 Office 365 服務中執行移動要求時,與一般內部部署 Exchange 2010 組織有一個顯著不同。在 Office 365 中,會在不同的租用戶之間共用移轉佇列和針對移轉所配置的服務資源。此會影響移動程序的每個階段中處理移動要求的方式。

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

  • 佈建移動要求  新客戶移轉作業會被視為佈建移動要求。這些要求具有一般優先順序。

  • 資料中心內部移動要求  這些是資料中心作業小組啟動的信箱移動要求。這些要求的優先順序較低,因為使用者經驗不會受到移動要求延遲的影響。

  • 已佇列的移動要求  此狀態表示移動已進入佇列並等候 Microsoft Exchange 信箱複寫服務的挑選。若為 Exchange 2003 移動要求,使用者在此階段仍可存取其信箱。

    有兩個因素會影響信箱複寫服務挑選的要求:

    • 優先順序  優先順序較高的已佇列移動要求會比優先順序較低的移動要求先獲得挑選。這可協助確保客戶移轉的移動要求一律會比資料中心內部的移動要求獲得優先處理。

    • 佇列中的位置  若移動要求的優先順序相同,越早進入佇列的要求會越早由信箱複寫服務挑選進行處理。由於可能會有多個客戶同時執行信箱移轉,因此有新的移動要求留在佇列中等著被處理很正常。

      在移轉規劃期間,通常不會考量信箱要求在獲處理前於佇列中等候的時間。而此會導致配置給客戶完成所有規劃移轉的時間不夠。

  • 進行中的移動要求  此狀態表示移動仍在進行中。如果是線上信箱移動,使用者仍可存取信箱。如果是離線信箱移動,則使用者的信箱將無法使用。

    一旦信箱移動要求處於「進行中」狀態,則優先順序便無關緊要,新的移動要求會等到現有進行中的移動要求完成之後才會開始處理,即使新移動要求的優先順序較高亦然。

規劃   如上所述,由於 Exchange 2003 使用者在混合移轉期間無法進行存取,因此 Exchange 2003 客戶通常比較關心排程移轉的時機以及移轉所需的時間。

規劃特定期間內可移轉的信箱數目時,請考慮下列事項:

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

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

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

    例如,假設您有六小時的時間可以移轉信箱。若平均佇列時間為一小時,且移轉輸送量為每小時 100 個信箱,則在六個小時的時間內可以移轉 500 個信箱:500 = (6 – 1) * 100.

  • 請比初始規劃的移轉時間更早開始移轉,以減輕佇列時間的影響。信箱進入佇列之後,Exchange 2003 使用者仍可存取其信箱。

判斷佇列時間   由於 Microsoft 不會管理客戶的移轉排程,因此佇列時間會不斷變更。

客戶若要判斷可能的佇列時間,可以嘗試安排在實際移轉開始的數小時前測試移動。接著,依據觀察到的要求停留在佇列中的時間,客戶可以更準確地估計何時開始移轉,以及特訂期間內所能移動的信箱數目。

例如,假設在開始規劃移轉的四個小時前測試完移轉。客戶判斷測試移轉的佇列時間約為一小時。則客戶應該考慮比原來規劃的時間早一個小時開始移轉,以協助確保有足夠時間可完成所有移轉。

協力廠商工具最常用於與 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。這些工具通常都需要一部移轉伺服器。來源伺服器的系統效能、後端工作及節流原則等因素適用於這些移轉伺服器。

注意事項注意事項:
某些協力廠商的移轉解決方案是以雲端架構服務形式託管於網際網路,因此不需內部部署移轉伺服器。

解決方案與作法

若要提升使用移轉伺服器時的移轉效能,請套用<資料來源伺服器>一節中所述的相同最佳作法。

協力廠商移轉工具最常用的通訊協定為 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 使用者節流的限制。我們收到的報告指出,許多企業客戶必須設定 40 部以上的移轉伺服器,以取得每小時 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. 從移轉伺服器連線至 Office 365 信箱透過 Microsoft Outlook 使用 RPC over HTTP;確定您不是使用快取模式

  2. 將含有範例資料的大型 PST 檔案匯入 Exchange Online 信箱。

  3. 可透過計算上傳 PST 檔案所需的時間,以測量移轉效能。若無其他限制,移轉輸送量應與客戶從使用 RPC over HTTP 的協力廠商移轉工具取得的輸送量類似。實際移轉期間會有額外負荷,因此輸送量可能會稍微不同。

Office 365 資源狀況節流會影響使用協力廠商移轉工具執行的移轉。如需詳細資訊,請參閱以上的「Office 365 資源狀況節流」一節。

 
顯示: