共用方式為

瞭解 Exchange 2010 中的負載平衡

  • 發行項

 

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2016-11-28

負載平衡是一種管理伺服器接收流量的方式。負載平衡提供容錯移轉備援，可確保您的使用者在電腦發生故障的情形下，仍然能夠持續接收 Exchange 服務。 它也能讓您的部署處理超過一部伺服器所能處理的流量，同時為您的用戶端提供單一主機名稱。

除了負載平衡之外，Microsoft Exchange Server 2010 也提供幾個轉換和容錯移轉備援的解決方案。 這些解決方案包括：

  • 高可用性和站台恢復   您可以在不同地理位置部署兩個 Active Directory 站台、保持兩者之間信箱資料的同步，以及在某個站台故障時，讓另一個站台處理整個負載。Exchange 2010 使用資料庫可用性群組 (DAG) 來保持不同伺服器上多份信箱複本的同步。

  • 線上信箱移動   在線上信箱移動中，使用者在移動期間可以存取其電子郵件帳戶。 只有在程序結束時 (開始進行最後的同步處理時)，使用者才會有一小段時間無法存取帳戶。 Exchange 2010 資料庫之間和 Exchange Server 2007 Service Pack 3 (SP3) 或 Exchange 2007 以上版本和 Exchange 2010 資料庫之間都支援線上信箱移動。您可以跨樹系或在相同樹系中執行線上信箱移動。

  • 陰影備援   陰影備援可在傳輸郵件時保護郵件的可用性和復原能力。 使用陰影備援時，從傳輸資料庫刪除郵件時會發生延遲，直到傳輸伺服器驗證該郵件的所有下一個躍點都已完成為止。 如果在報告成功傳遞之前有任何下一個躍點失敗，便會重新提交郵件以便遞送至未完成的躍點。

目錄

負載平衡概觀

了解 Exchange 2010 流量負載

了解負載平衡選項

負載平衡建議

相似性選項

負載平衡概觀

負載平衡有兩個主要的用途。 它可降低您其中一個 Active Directory 站台中單一 Client Access Server 失敗所造成的影響。 此外，負載平衡可確保您的 Client Access Server 和 Hub Transport 電腦的平均分散。

Exchange 2010 負載平衡的架構變更

Exchange 2010 中的數項變更使負載平衡對您的組織而言，十分重要。Client Access server role 上的 Exchange RPC 用戶端存取服務和 Exchange 通訊錄服務可改善信箱容錯移轉期間的使用者體驗，其方法是將信箱存取的連線端點從 Outlook 和其他 MAPI 用戶端移至 Client Access server role，而非 Mailbox server role。在舊版的 Exchange 中，Outlook 會直接連線至主控使用者信箱的信箱伺服器，並透過 Mailbox server role 來 Proxy 處理目錄連線，或直接將目錄連線轉介到特定的 Active Directory 通用類別目錄伺服器。 現在這些連線是由 Client Access server role 處理，外部和內部 Outlook 連線在部署跨 Client Access Server 的陣列時必須符合負載平衡的情況，以達到容錯的效果。

建議為每個 Active Directory 站台及每個版本的 Exchange 採用 Client Access Server 的負載平衡陣列。Client Access Server 的負載平衡陣列無法在多個 Active Directory 站台中共用，也無法在同一個陣列中混合不同 Exchange 版本或 Exchange Service Pack 版本。

當您在現有的組織中安裝 Exchange 2010，並為了要與舊版的 Exchange 共存而設定傳統命名空間時，您的用戶端將會自動連線至 Exchange 2010 Client Access Server 或伺服器陣列。接著 Exchange 2010 Client Access Server 或 Client Access Server 陣列會將舊版 Exchange 上用戶端的信箱要求 Proxy 處理或重新導向至 Exchange 2003 前端伺服器或符合信箱版本的 Exchange 2007 Client Access Server。 如需詳細資訊，請參閱瞭解升級到 Exchange 2010。

注意事項附註：
當您將快速檢修 (QFE) 和更新彙總套件套用至整個陣列或其中某些部分時，可以將這兩者混合進行。 建議您將 QFE 和更新彙總套件套用至陣列中所有的電腦。

您的負載平衡組態會直接影響用來連線的用戶端和所使用安全通訊端層 (SSL) 憑證的主機名稱。 如需 Exchange 2010 憑證的詳細資訊，請參閱瞭解數位憑證和 SSL。

設定 Client Access Server 陣列

您可以在每個 Active Directory 站台內設定一個 Client Access Server 陣列。 只要設定 Client Access Server 陣列，您就可以將信箱資料庫設定為使用 Client Access Server 陣列作為 MAPI 端點，而非特定的 Client Access Server。

如需 Client Access Server 陣列及如何將信箱資料庫設定為使用特定 Active Directory 站台的 Client Access Server 陣列有關的詳細資訊，請參閱瞭解 RPC Client Access。

了解 Exchange 2010 流量負載

在您設定負載平衡之前，應該了解 Exchange 2010 Client Access Server 上的負載情形。Exchange 2010 Client Access Server 會接收下列三種類型的流量：

  • 來自外部用戶端的流量

  • 來自內部用戶端的流量

  • 來自其他 Client Access Server 的 Proxy 流量

來自其他 Client Access Server 的 Proxy 流量原本是從外部或內部用戶端傳送給某一部 Client Access Server，但隨即被 Proxy 處理至另一部 Client Access Server 的流量。 有幾個原因造成這種情形發生，但通常是因為原始用戶端無法直接與目的地 Client Access Server 連線。 使用者嘗試從網際網路存取信箱，但信箱位於非網際網路方向的 Active Directory 站台時，會發生這種情形。 如需 Proxy 處理的詳細資訊，請參閱了解 Proxy 與重新導向。

Client Access Server 所接收的每種流量類型包括通訊協定清單的要求，並且來自不同特性的用戶端裝置和電腦。 這些差異會影響可使用的負載平衡策略。

回到頁首

了解負載平衡選項

不同的負載平衡解決方案之間有幾種主要的技術差異。

  • 效能   解決方案每秒可以處理多少要求？

  • 管理性   設定及部署負載平衡解決方案有多簡單？

  • **容錯移轉自動化及偵測   **負載平衡器在偵測 Client Access Server 或服務失敗時有多發揮多少智慧效能？

  • **相似性   **哪些類型的用戶端對 Client Access Server 相似性支援負載平衡解決方案？

了解相似性

當負載平衡解決方案提供用戶端對 Client Access Server 相似性時，表示特定用戶端和特定 Client Access Server 之間存在一種長期的關係。用戶端可以是在膝上型電腦上執行的 Outlook、在行動裝置上執行的 Microsoft Exchange ActiveSync、Microsoft Office Outlook Web App, Exchange Web 服務或任何用戶端應用程式。

這種長期關係 (或相似性) 可確保所有由用戶端傳送的要求會傳至相同的 Client Access Server。某些 Exchange 2010 通訊協定需要相似性，而其他 Exchange 通訊協定則不需要。

Windows 網路負載平衡

Windows 網路負載平衡 (WNLB) 是最常用於 Exchange 伺服器的軟體負載平衡器。以 Microsoft Exchange 部署 WNLB 有幾項相關的限制。

  • 也將使用信箱 DAG 的 Exchange 伺服器上不能使用 WNLB，因為 WNLB 與 Windows 容錯移轉叢集不相容。如果使用的是 Exchange 2010 DAG 且想要使用 WNLB，您必須在個別伺服器上執行 Client Access server role 和 Mailbox server role。

  • 由於效能問題，不建議在一個由 WNLB 提供負載平衡的陣列中放置超過八部 Client Access Server。

  • WNLB 不會偵測服務中斷情形。 WNLB 只會藉由 IP 位址偵測伺服器中斷情形。 這表示如果特定的 Web 服務 (如 Outlook Web App) 失敗，但伺服器仍在運作中，則 WNLB 不會偵測故障情形，且仍會將要求路由到該 Client Access Server。 此時需要手動介入，從負載平衡集區中移除中斷的 Client Access Server。

  • WNLB 組態可能會造成連接埠氾濫的情形，這可能會使網路癱瘓。

  • 由於 WNLB 只會使用來源 IP 位址來執行用戶端相似性，因此當來源 IP 集區很少時不是有效的解決方案。 來源 IP 集區是來自遠端網路的子網路，或您的組織使用網路位址轉譯時，都會發生這種情形。

負載平衡建議

負載平衡有數個可用的選項。 您所使用的選項取決於網路的大小和組態。

Windows 網路負載平衡包含來源 IP 相似性

第一個負載平衡選項是包含來源 IP 相似性的 WNLB。 您的每個 Active Directory 站台中具有一部以上但小於八部 Client Access Server 時，適用這個解決方案。這個解決方案內建在 Windows 中，而且不需要其他的電腦。

在兩種情形下，您不會想要使用 WNLB。

  • 您的組織擁有直接與 Client Access Server 通訊，而非透過 WNLB 虛擬 IP 位址與 Client Access Server 通訊的反向 Proxy 伺服器。 反向 Proxy 伺服器會隱藏來自 Client Access Server 陣列的用戶端 IP 位址。 因此，來源 IP 相似性不會如預期般運作。 不過，您可能仍想要使用 WNLB 來使內部流量獲得負載平衡。

  • 您的組織有許多用戶端透過非常小組的 IP 位址來存取您的 Client Access Server。 WNLB 會讓整個類別 C 的子網路與一部 Client Access Server 產生關聯。

硬體負載平衡

如果您在單一 Active Directory 站台中有超過八部 Client Access Server，則您的組織將需要更強固的負載平衡解決方案。儘管有更強固的軟體負載平衡解決方案可以使用，但硬體負載平衡解決方案可提供最大的容量。如需 Exchange 2010 伺服器負載平衡解決方案的詳細資訊，請參閱 Microsoft Unified Communications 硬體負載平衡部署 (英文)。

硬體負載平衡器支援非常高的流量輸送量，且可以設定為許多方式的負載平衡。 大部分的硬體負載平衡器廠商會提供如何使他們的產品搭配 Exchange 2010 運作的詳細文件。 設定硬體負載平衡器最簡單的方法是建立相似性方法的後援清單，該清單會由負載平衡器套用。例如，負載平衡器會先嘗試 Cookie 型相似性，然後嘗試 SSL 工作階段識別碼，接著嘗試來源 IP 相似性。

反向 Proxy 解決方案

如果您的反向 Proxy 解決方案可以為發佈至網際網路的伺服器執行負載平衡，如 Microsoft Forefront Threat Management Gateway (TMG) 或 Forefront Unified Access Gateway (UAG)，建議您使用它。

由於流量會透過反向 Proxy 伺服器到達您的 Client Access Server，因此會以反向 Proxy 伺服器的 IP 位址取代用戶端的原始 IP 位址。 這會中斷來源 IP 相似性。 有許多方法可解決此問題，包括將反向 Proxy 伺服器設定為其進行 Proxy 處理之子網路的預設閘道。

不過，最新的反向 Proxy 伺服器可以為發佈至網際網路的服務執行負載平衡。 這些反向 Proxy 伺服器支援負載平衡器為支援此功能的 Exchange 服務所建立的 Cookie 型負載平衡。 此解決方案會比來源 IP 負載平衡更可靠。 若要使其運作，反向 Proxy 伺服器必須能夠讀取和修改 HTTP 資料流。 如果您使用的是 SSL，這表示反向 Proxy 伺服器必須將流量解密以讀取內容，以及在資料流中建立 Cookie。 此解密步驟在某些情況下無法進行，例如當您使用用戶端憑證驗證，而用戶端連線到 Client Access Server 時。

回到頁首

相似性選項

不同的負載平衡解決方案提供不同的方法來讓用戶端與特定 Client Access Server 產生關聯。 不同的負載平衡產品 (硬體和軟體) 中有幾種常見的相似性可用。 並非所有類型的相似性都可用於每個負載平衡選項，如下列範例所述：

  • WNLB 只支援來源 IP 相似性或不使用相似性。

  • 個別伺服器陣列中的軟體負載平衡器可以使用負載平衡器為支援 Cookie 的通訊協定所建立的 Cookie，並且針對其他通訊協定使用 IP 相似性。

  • 使用 SSL 卸載的硬體負載平衡器可讓您設定更複雜的行為。 例如，您可以設定一組現有的 Cookie，這些 Cookie 將對支援那些 Cookie 的通訊協定生效，並設定負載平衡器建立的 Cookie、SSL 工作階段識別碼和來源 IP。

除了不同負載平衡解決方案支援的選項之外，您也可以將這些步驟中的某些步驟設定為只套用至某些 Exchange 通訊協定和服務。 因為每個通訊協定的行為不同，這有助於將效能最佳化。

識別用戶端及將其與特定 Client Access Server 產生關聯的最可靠方式是使用現有的 Cookie 或 HTTP 標頭。 這些 Cookie 和標頭是由用戶端或伺服器所建立，而成為通訊協定的一部分。 此選項也不需要負載平衡器修改流量，這對效能有助益。

當您使用此相似性選項時，請注意下列幾點：

  • 您的負載平衡器必須支援這種類型的相似性。 目前只有硬體負載平衡器支援此相似性。

  • 此相似性只適用於 HTTP 上傳輸流量的通訊協定。

  • 在通訊協定中，用戶端工作階段期間必須有保持不變的現有的 Cookie 或標頭，而且這個 Cookie 或標頭對每個特定用戶端或小組用戶端而言是唯一的。

  • 負載平衡器解決方案必須能夠讀取及解譯 HTTP 資料流。 如果您使用的是 SSL，這表示負載平衡器必須將流量解密以讀取內容。 有時這會導致負載平衡器上的負載增加。 同時，此解密步驟在某些情況下無法進行，例如當您將用戶端憑證驗證用於 SSL 工作階段，而用戶端連線到 Client Access Server 時。

Exchange 2010 通訊協定中現有適用於負載平衡的 Cookie 和 HTTP 標頭如下：

  • HTTP 基本驗證授權標頭   此標頭會在使用 HTTP 基本驗證時運作。 基本驗證是 Exchange ActiveSync 預設且最常用的驗證類型。 此標頭在其他通訊協定及驗證方法中非常少見。基本驗證授權標頭會將所有使用基本驗證及從特定使用者傳送到相同 Client Access Server 的流量。 經由 HTTP 完全傳送 Outlook 流量，且用戶端位於反向 Proxy 伺服器之後，也會使用這個標頭。

  • HTTP OWA UserContext Cookie   這個 Cookie 適用於 Outlook Web App，只有用戶端會使用它。您使用表單型驗證 (FBA) 搭配 Outlook Web App 時 (這是預設的組態)，會在建立 UserContext Cookie 之前的 Outlook Web App 工作階段開始時建立一小組要求。 若要確保那些要求會使用相似性來將用戶端連線至相同的 Client Access Server (因此需要表單型驗證能夠運作)，當您使用 UserContext Cookie 時必須有後援相似性選項。 建議您在負載平衡器取得要使用的 UserContext Cookie 之前，使用 SSL 工作階段識別碼或來源 IP 相似性作為後援，以便為那些初始要求提供相似性。

    注意事項附註：
    使用明確登入以存取特定信箱的 Outlook Web App 要求會導致以不同的名稱和 ID 來使用 UserContext Cookie。Cookie 是以 UserContext 為起始，而其後會附加用於識別個別信箱的字串。 這使得負載平衡與 UserContext Cookie 變得複雜，因為負載平衡器必須先找到以 UserContext 為起始的 Cookie。 如此可能會導致效能降低。

  • HTTP Exchange 控制台 msExchEcpCanary Cookie   此 Cookie 僅適用於 Exchange 控制台。

  • HTTP Outlook 2010 OutlookSession Cookie   硬體負載平衡器支援 OutlookSession Cookie 以及其他一般 Cookie。 下表說明 Outlook RPC/HTTP 的 OutlookSession 用戶端 Cookie 支援需求：

    Windows XP

    Windows Vista

    Windows 7

    Outlook 2003

    不支援

    不支援

    不支援

    Outlook 2007

    不支援

    不支援

    不支援

    Outlook 2007 Hosting Pack (KB2544404)

    不支援

    支援

    支援

    Outlook 2010

    不支援

    支援

    支援
    注意事項附註：
    在 Windows XP 上執行的 Microsoft Outlook 不支援負載平衡的 OutlookSession Cookie。在此情況中，我們建議您使用 IP 負載平衡。

  • HTTP 遠端 PowerShell MS-WSMAN Cookie   這個方法只適用於遠端 PowerShell。

回到頁首

第二種讓用戶端工作階段與 Client Access Server 產生關聯的最可靠方式，是使用負載平衡器建立的 Cookie。 負載平衡器會新增 HTTP Cookie 到用戶端/伺服器通訊協定交談中，然後使用該 Cookie 來判斷哪部 Client Access Server 應處理連入要求。支援此方法的 Exchange 2010 應用程式有 Outlook Web App、Exchange 控制台和遠端 PowerShell。這種 Cookie 有數項限制。

  • 負載平衡器必須支援這種類型的相似性。 目前只有硬體負載平衡器和執行於不同伺服器層的軟體負載平衡器支援這種相似性。

  • 這個方法只適用於在 HTTP 上傳輸流量的通訊協定。您不能對 RPC 用戶端存取服務、Exchange 通訊錄服務、POP3 或 IMAP4 使用此方法。

  • 負載平衡器解決方案必須能夠讀取及解譯 HTTP 資料流。 如果您使用的是 SSL，這表示負載平衡器必須將流量解密以讀取內容。 有時這會導致負載平衡器上的負載更大。 在其他情況下，負載平衡器無法解譯 HTTP 資料流，例如當您在 Client Access Server 上使用用戶端憑證驗證時。

  • 用戶端必須能夠接收來自伺服器的任意 Cookie，然後必須將這些 Cookie 包含在所有從用戶端傳送至伺服器的未來要求中。Exchange ActiveSync 用戶端、Outlook Anywhere 用戶端和一些 Exchange Web 服務用戶端 (如 Microsoft Office Communications Server 2007 裝置) 不支援此方法。

SSL 工作階段識別碼

負載平衡是根據 SSL 工作階段識別碼來提供比來源 IP 相似性更詳細的資訊，可讓您分割不同用戶端的流量 (如果那些用戶端是來自於相同 IP 位址)。 SSL 工作階段識別碼負載平衡也具有可讓您在不需將 SSL 流量解密的情形下進行負載平衡的好處。 這在您使用用戶端憑證驗證及當您在 Client Access Server 上結束 SSL 連線時會需要用到。

不建議在下列兩種狀況下使用 SSL 工作階段識別碼相似性：

  • 某些用戶端 (如 Internet Explorer 8) 會為用戶端電腦上執行的每個瀏覽器工作階段重新建立 SSL 工作階段。 這會導致每個 Outlook Web App 視窗都有新的 SSL 工作階段。 由於這會中斷 Outlook Web App 的用戶端相似性，因此 Exchange 2010 不支援以此方法部署負載平衡。 某些行動裝置 (如 Apple iPhone) 也會為它們 Exchange ActiveSync 與 Exchange 的某部分通訊建立新的 SSL 工作階段。

    注意事項附註：
    當您使用用戶端憑證驗證時，瀏覽器將會為所有傳送給指定主機名稱的流量使用相同的 SSL 工作階段。 一旦啟用了用戶端憑證驗證，SSL 工作階段識別碼便是 Outlook Web App 和 Exchange 控制台的有效相似性選項。

  • 在使用 Outlook Anywhere 的情形下，Client Access Server 將使用 Windows RPC Proxy 元件來將 RPC_DATA_IN 與 RPC_DATA_OUT 連線配對。 這會嚴重影響效能。

來源 IP

在用戶端和 Client Access Server 間提供相似性的最常見方式是使用來源 IP 相似性。 負載平衡器會檢查用戶端的 IP 位址，並將所有來自特定來源 IP 的流量傳送到特定 Client Access Server。 這是 WNLB 唯一支援的相似性類型。 當您使用來源 IP 相似性時，需要考慮兩個重要的問題。

  • 當用戶端變更 IP 位址時，就會中斷相似性。 將膝上型電腦從有線區域網路移動到 Wi-Fi 或在不同的 Wi-Fi 網路間漫遊時，會發生這種情形。 當用戶端變更 IP 位址時，會影響到使用者。例如，使用者使用 Outlook Web App 時，必須在每次電腦取得新的 IP 位址時進行驗證。

  • 如果有許多用戶端會從相同 IP 位址存取您的負載平衡解決方案，則負載分散會變得不平衡。 這種情形造成的影響取決於有多少用戶端位於特定 IP 位址之後。 例如，若您有四部 Client Access Server，且有 50% 的用戶端會從相同的 IP 位址存取您的負載平衡器，則至少有 50% 的流量會進入某一部 Client Access Server，而其他三部 Client Access Server 將處理其餘的流量。 大多數用戶端會透過單一 IP 位址存取您 Exchange 組織的主要原因有兩種。

    • 網路位址轉譯器 (NAT) 或連出 Proxy 伺服器，如 Microsoft Forefront Threat Management Gateway (TMG)。 當您的用戶端與 Client Access Server 之間有 NAT 或連出 Proxy 伺服器存在時，會以 NAT 或連出 Proxy 伺服器的 IP 位址來取代原始的用戶端 IP 位址。

    • Client Access Server 對 Client Access Server 的 Proxy 流量。 在某些情況下，某一部 Client Access Server 會將流量 Proxy 處理至另一部 Client Access Server。 通常這種情形會在 Active Directory 站台間發生，因為用戶端必須存取與他們的信箱相同 Active Directory 站台中的 Client Access Server。 如需 Proxy 處理的詳細資訊，請參閱了解 Proxy 與重新導向。

不使用相似性

最後一種相似性類型是不使用相似性。 當您未使用相似性時，會將來自用戶端的各個要求指派給隨機的 Client Access Server。 在需要相似性的通訊協定或可從相似性提升效能的通訊協定中，不建議使用此選項。

在已設定 SSL 卸載且不需要相似性的通訊協定中，建議不要使用相似性。

回到頁首

負載平衡選項摘要

下表提供可用負載平衡選項的摘要。

解決方案 用戶端對 Client Access Server 的相似性 容錯移轉方法 容量 成本

硬體負載平衡器

根據通訊協定及用戶端，在下列各項間切換：

現有的 Cookie

負載平衡器建立的 Cookie

SSL 識別碼

來源 IP

用戶端停機時間最少的自動容錯移轉。 硬體負載平衡也能夠為特定通訊協定提供容錯移轉。

++++

$$$

位於個別伺服器層的軟體負載平衡器

附註： TMG 和 UAG 是對外部流量唯一可行的解決方案。

負載平衡器建立的 Cookie 或來源 IP，取決於通訊協定和用戶端。

用戶端停機時間最少的自動容錯移轉。

++

$$

與 Client Access Server (WNLB) 位於相同伺服器層的軟體負載平衡器

來源 IP。

用戶端停機時間最少的自動容錯移轉。

+

$

DNS 循環配置

每個用戶端會取得隨機的 Client Access Server 的 IP 位址。

偵測問題和復原的手動步驟。 即使在系統管理員已經執行復原之後，瀏覽器和作業系統 DNS 快取行為可能會阻止用戶端連線。 此解決方案會中斷許多通訊協定的相似性，包括 PRC 用戶端存取、Outlook Web App、Exchange Web 服務和 Exchange 控制台。

+++

$

不使用負載平衡器

為每個 Client Access Server 手動指派不同的主機名稱。

偵測問題和容錯移轉的手動步驟。 用戶端 DNS 快取會造成緩慢的容錯移轉。

+

不適用

這些選項各有幾個優缺點。

  • 硬體負載平衡器通常會包含效能及安全性功能，例如 SSL 卸載和流量檢查。

  • 位於不同伺服器層的軟體負載平衡器通常會包含在大型軟體套件中，並提供一些反向 Proxy 功能，例如預先驗證、SSL 卸載和廣泛的流量檢查。 軟體負載平衡器預先驗證使用者時，如果 Client Access Server 的相似性失敗，使用者便不需要重新進行驗證。 不過，某些軟體負載平衡器需要用戶端和反向 Proxy 伺服器之間維持相似性。 在這種情況下，您必須在反向 Proxy 伺服器的前端新增一個負載平衡層，以便在反向 Proxy 伺服器之前為您的 Client Access Server 執行維持負載平衡的工作。

 © 2010 Microsoft Corporation. 著作權所有，並保留一切權利。