Exchange Server中的負載平衡
Exchange 2016 和更新版本中的負載平衡是以 Exchange 2013 中提供的 Microsoft 高可用性和網路復原平臺為基礎。 當這結合協力廠商負載平衡解決方案 (硬體和軟體) 時，有多個選項可在您的 Exchange 組織中實作負載平衡。
Exchange 2013 中引進的 Exchange 架構變更引進了信箱伺服器和用戶端存取伺服器角色。 將此專案與 Exchange 2010 相比較，其中用戶端存取、信箱、中樞傳輸和整合郵件會在不同的伺服器上執行。
使用最少的伺服器角色，Exchange 2016 和 2019 提供：
使用執行用戶端存取服務和 Edge Transport Server 角色的信箱伺服器簡化部署。
傳輸管線中管理的郵件流程，也就是服務、連線、佇列和元件的集合，這些服務、連線、佇列和元件會將訊息路由傳送至信箱伺服器上的傳輸服務分類器。
藉由部署負載平衡器以分散用戶端流量來達到高可用性。
Exchange 2013 引進的 HTTP 通訊協定標準表示 Exchange 2016 和 Exchange 2019 不再需要會話親和性。 會話親和性允許啟用傳訊服務的持續連線，讓使用者不需要多次重新輸入其使用者名稱和密碼。
先前，Exchange 2007 和 Exchange 2010 支援 RPC over HTTP for Outlook Anywhere。 Exchange 2013 已透過 HTTP 引進 MAPI，但預設並未啟用。 現在預設會在 Exchange 2016 和 Exchange 2019 中啟用。
使用 HTTP 通訊協定後，所有原生用戶端都會使用 HTTP 和 Exchange Server 中的 HTTP 進行連線。 此標準通訊協定不需要親和性，這在先前是避免每當負載平衡將連線重新導向至不同伺服器時，使用者認證的新提示。
Exchange Server中的伺服器角色
Exchange 2016 和 Exchange 2019 的伺服器角色數目減少可簡化 Exchange 實作和硬體需求。 Exchange 2016 和 2019 中的伺服器角色數目從七個縮減為兩個：信箱伺服器和 Edge Transport Server。 信箱伺服器角色包含用戶端存取服務，而 Edge Transport Server 在 Exchange 2016 和 Exchange 2019 中提供安全的郵件流程，就像在舊版 Exchange 中一樣。
在 Exchange 2013 中，Client Access 伺服器角色確保當使用者嘗試存取其信箱時，伺服器會將要求代理回信箱伺服器，以主動服務使用者的信箱。 這表示先前稱為Outlook Web App) 的Outlook 網頁版 (等服務已在信箱本身呈現給使用者，而不需要任何親和性。
Exchange 2016 和 Exchange 2019 中仍保留相同的功能。 如果兩部信箱伺服器裝載不同的信箱，它們可以在必要時彼此 Proxy 流量。 裝載信箱使用中複本的信箱伺服器會為存取信箱的使用者提供服務，即使使用者連線到不同的信箱伺服器也一樣。
如需有關Exchange Server中伺服器角色變更的詳細資訊，請參閱Exchange Server架構一文。
| 伺服器角色 | 服務 |
|---|---|
| 信箱伺服器 | 使用 EdgeSync 管理從 Active Directory 到 Edge Transport Server 上 AD LDS 實例的單向收據和設定資訊複寫。 只複製讓 Edge Transport 執行反垃圾郵件並啟用端對端郵件流程所需的資訊。 |
| Edge Transport | 使用下列專案管理所有輸入和輸出網際網路郵件流程：
不是 Active Directory 樹系的成員。 |
雖然並非必要，但 Edge Transport Server 位於周邊網路中，如同舊版 Exchange，可為您的 Exchange 組織提供安全的輸入和輸出郵件流程。
如需有關傳輸服務的詳細資訊，請參閱 瞭解 Edge Transport Server 上的傳輸服務一文。
Exchange Server中的通訊協定
從 Exchange 2016 開始，所有原生 Exchange 用戶端都會使用 HTTP 通訊協定來連線到指定的服務，並使用用戶端存取服務 SSL 憑證在登入時提供給使用者的 HTTP Cookie。 登入的使用者可以在執行用戶端存取服務的不同信箱伺服器上繼續會話，而不需要重新驗證。 使用相同 SSL 憑證的伺服器可以解密用戶端驗證 Cookie。
HTTP 可讓您在 Exchange 網路中使用服務或應用程式健康情況檢查。 根據負載平衡器解決方案，您可以實作健康情況探查來檢查系統的不同元件。
用戶端僅限 HTTP 存取的效果是負載平衡也比較簡單。 如有需要，您可以使用 DNS 來平衡 Exchange 流量的負載。 您會為用戶端提供每個信箱伺服器的 IP 位址，而 HTTP 用戶端會處理這些工作。 如果 Exchange 伺服器失敗，通訊協定會嘗試連線到另一部伺服器。 不過，負載平衡對 DNS 有一些缺點，請參閱下一節Exchange Server中的負載平衡選項。
如需 HTTP 和Exchange Server的詳細資訊，請參閱 Exchange Server中的 MAPI over HTTP 一文。
Exchange Server中的負載平衡選項
在此所示的範例中，在資料庫可用性群組中設定的多部伺服器 (DAG) 裝載執行用戶端存取服務的信箱伺服器。 這會提供具有小型 Exchange 伺服器使用量的高可用性。 用戶端會連線到負載平衡器，而不是直接連線到 Exchange 伺服器。 負載平衡器配對不需要，但建議您在叢集中部署 以改善網路復原能力。
請注意，DAG 會使用 Microsoft 叢集服務。 這些服務無法在同一部伺服器上啟用，因為 Windows 網路負載平衡 (NLB) 。 因此，使用 DAG 時，Windows NLB 不是選項。 在此案例中，有協力廠商軟體和虛擬裝置解決方案。
使用 DNS 是負載平衡 Exchange 流量的最簡單選項。 使用 DNS 負載平衡時，您只需要為用戶端提供每個信箱伺服器的 IP 位址。 之後，DNS 迴圈配置資源會將該流量散發到您的信箱伺服器。 如果某個 Exchange 伺服器完全失敗，HTTP 用戶端就足以連線到另一部伺服器。
簡單是有代價的，但在此案例中，DNS 迴圈配置資源並不會真正平衡流量的負載，因為沒有程式設計方式可確保每部伺服器取得公平共用的流量。 此外，沒有服務等級監視，因此當單一服務失敗時，用戶端不會自動重新導向至可用的服務。 例如，如果Outlook 網頁版處於失敗模式，用戶端會看到錯誤頁面。
當您在外部發佈時，DNS 負載平衡需要更多外部 IP 位址。 這表示您組織中的每個個別 Exchange 伺服器都需要外部 IP 位址。
有更簡潔的解決方案可平衡流量的負載，例如使用傳輸層 4 或應用層 7 來協助分散用戶端流量的硬體。 負載平衡器會監視每個 Exchange 用戶端面向服務，如果發生服務失敗，負載平衡器可以將流量導向至另一部伺服器，並將問題伺服器離線。 此外，某些層級的負載散發可確保沒有任何單一信箱伺服器會 Proxy 處理大部分的用戶端存取。
負載平衡服務可以使用第 4 層或第 7 層或組合來管理流量。 每個解決方案都有優點和缺點。
第 4 層負載平衡器可在傳輸層工作，以在不檢查內容的情況下導向流量。
因為它們不會檢查流量內容，所以第 4 層負載平衡器可節省傳輸時間。 不過，這會帶來取捨。 第 4 層負載平衡器只知道 IP 位址、通訊協定和 TCP 埠。 只要知道單一 IP 位址，負載平衡器就只能監視單一服務。
第 4 層負載平衡優點包括：
需要較少的資源 (不需要內容檢查) 。
在傳輸層散發流量。
第 4 層解決方案的風險是，如果服務失敗，但伺服器仍然可用，用戶端可以連線到失敗的服務。 這表示復原第 4 層實作需要為每個服務設定多個具有個別 HTTP 命名空間的 IP 位址，例如，owa.contoso.com、eas.contoso.com、mapi.contoso.com，以允許服務層級監視。
第 7 層負載平衡器可在應用層工作，並可檢查流量內容並據以導向。
第 7 層負載平衡器會放棄第 4 層負載平衡的原始效能優點，以簡化單一命名空間，例如 mail.contoso.com 和個別服務監視。 第 7 層負載平衡器瞭解 HTTP 路徑，例如 /owa 或 /Microsoft-Server-ActiveSync 或 /mapi，而且可以根據監視資料將流量導向至工作伺服器。
第 7 層負載平衡的優點包括：
只需要單一 IP 位址。
檢查內容並可引導流量。
提供可離線之失敗服務的通知。
處理負載平衡器 SSL 終止。
在應用層散發流量，並瞭解目的地 URL。
SSL 應該會在負載平衡器終止，因為這會提供一個集中式位置來更正 SSL 攻擊。
需要負載平衡的埠包括一些埠，例如 IMAP4 或 POP3 的埠，甚至可能無法在您的 Exchange 組織中使用。
| TCP 通訊埠 | 角色 | 使用 |
|---|---|---|
| 25 | 信箱 | 輸入 SMTP |
| 587 | 信箱 | 用戶端的輸入 SMTP |
| 110 | 信箱 | POP3 用戶端 |
| 143 | 信箱 | IMAP4 用戶端 |
| 443 | 信箱 | HTTPS (Outlook 網頁版、自動探索、Web 服務、ActiveSync、 MAPI over HTTP， RPC over HTTP， OAB， EAC) |
| 993 | 信箱 | 保護 IMAP4 用戶端 |
| 995 | 信箱 | 保護 POP3 用戶端 |
Exchange Server中的負載平衡部署案例
Exchange 2016 為您的命名空間和負載平衡架構引進了顯著的彈性。 透過許多在 Exchange 組織中部署負載平衡的選項，從簡單的 DNS 到複雜的第 4 層和第 7 層解決方案，建議您根據組織的需求檢閱它們。
下列案例隨附優點和限制，並瞭解每個案例是實作最適合您 Exchange 組織之解決方案的關鍵：
案例 A 單一命名空間，沒有會話親和性：第 4 層或第 7 層
案例 B 單一命名空間，沒有會話親和性：第 7 層
案例 C 具有會話親和性的單一命名空間，第 7 層
案例 D 多重命名空間且沒有會話親和性，第 4 層
案例 A 單一命名空間，沒有會話親和性：第 4 層或第 7 層
在此第 4 層案例中，會針對 HTTP 通訊協定用戶端部署單一命名空間 mail.contoso.com。 負載平衡器不會維持會話親和性。 因為這是第 4 層解決方案，所以負載平衡器會設定為只檢查單一虛擬目錄的健康情況，因為它無法區分Outlook 網頁版要求與 RPC 要求。
從此範例中負載平衡器的觀點來看，健康情況是每部伺服器，而不是指定命名空間的個別通訊協定。 系統管理員必須選擇要作為健康情況探查目標的虛擬目錄;建議您選擇經常使用的虛擬目錄。 例如，如果您大部分的使用者都使用 Outlook 網頁版，請在健康情況探查中選擇Outlook 網頁版虛擬目錄。
只要Outlook 網頁版健康情況探查回應狀況良好，負載平衡器就會將目的地信箱伺服器保留在負載平衡集區中。 不過，如果Outlook 網頁版健康情況探查因為任何原因而失敗，則負載平衡器會針對與該命名空間相關聯的所有要求，從負載平衡集區中移除目的地信箱伺服器。 這表示，如果健康情況探查失敗，該命名空間的所有用戶端要求都會導向至另一部伺服器，而不論通訊協定為何。
案例 B 單一命名空間，沒有會話親和性：第 7 層
在此第 7 層案例中，會針對所有 HTTP 通訊協定用戶端部署單一命名空間 mail.contoso.com。 負載平衡器不會維持會話親和性。 由於負載平衡器是針對第 7 層設定的，因此會有 SSL 終止，且負載平衡器知道目的地 URL。
我們建議針對 Exchange 2016 和 Exchange 2019 使用此設定。 負載平衡器會設定為檢查負載平衡集區中目的地信箱伺服器的健康情況，並在每個虛擬目錄上設定健康情況探查。
例如，只要Outlook 網頁版健康情況探查回應狀況良好，負載平衡器就會將目的地信箱伺服器保留在Outlook 網頁版負載平衡集區中。 不過，如果Outlook 網頁版健康情況探查因為任何原因而失敗，則負載平衡器會針對Outlook 網頁版要求，從負載平衡集區中移除目標信箱伺服器。 在此範例中，健康情況是每個通訊協定，這表示如果健康情況探查失敗，只會將受影響的用戶端通訊協定導向至另一部伺服器。
案例 C 具有會話親和性的單一命名空間，第 7 層
在此第 7 層案例中，會針對所有 HTTP 通訊協定用戶端部署單一命名空間 mail.contoso.com。 因為負載平衡器是針對第 7 層設定，所以有 SSL 終止，而負載平衡器知道目的地 URL。 負載平衡器也會設定為檢查負載平衡集區中目標信箱伺服器的健康情況。 健康情況探查會在每個虛擬目錄上設定。
不過，啟用會話親和性會減少容量和使用率。 這是因為更相關的同質性選項、Cookie 型負載平衡或安全通訊端層 (SSL) 會話識別碼，需要更多處理和資源。 建議您洽詢廠商，瞭解會話親和性如何影響負載平衡延展性。
如同先前的案例，只要Outlook 網頁版健康情況探查回應狀況良好，負載平衡器就會將目的地信箱伺服器保留在Outlook 網頁版負載平衡集區中。 不過，如果Outlook 網頁版健康情況探查因為任何原因而失敗，則負載平衡器會針對Outlook 網頁版要求，從負載平衡集區中移除目標信箱伺服器。 在這裡，健康情況是每個通訊協定，這表示如果健康情況探查失敗，只會將受影響的用戶端通訊協定導向至另一部伺服器。
案例 D 多個命名空間，且沒有會話親和性
最後一個具有多個命名空間且沒有會話親和性的案例會提供每個通訊協定健康情況檢查和第 4 層電源。 每個 HTTP 通訊協定用戶端都會部署唯一的命名空間。 例如，您會將 HTTP 通訊協定用戶端設定為 mail.contoso.com、mapi.contoso.com 和 eas.contoso.com。
此案例提供每個通訊協定的健康情況檢查，同時不需要複雜的負載平衡邏輯。 負載平衡器會使用第 4 層，且未設定為維護會話親和性。 負載平衡器組態會檢查負載平衡集區中目的地信箱伺服器的健康情況。 在此設定中，健康狀態探查會設定為以每個虛擬目錄的健康情況為目標，因為每個虛擬目錄都有唯一的命名空間。 因為它是針對第 4 層設定的，所以負載平衡器並不知道 URL 正在存取，但結果會如同它知道一樣。 由於健康情況是每個通訊協定，如果健康情況探查失敗，則只會將受影響的用戶端通訊協定導向至另一部伺服器。
負載平衡和Exchange Server中的 Managed 可用性
監視可用的伺服器和服務是高可用性網路的關鍵。 由於某些負載平衡解決方案不知道目標 URL 或要求的內容，因此這會造成 Exchange 健康情況探查的複雜性。
Exchange 2016 和 Exchange 2019 包含內建的監視解決方案，稱為受控可用性。 受控可用性也稱為主動監視或本機主動監視，是內建監視和復原動作與 Exchange 高可用性平臺的整合。
Managed 可用性包含離線回應程式。 叫用離線回應程式時，會從服務中移除受影響的通訊協定 (或伺服器) 。
若要確保負載平衡器不會將流量路由傳送至已將受控可用性標示為離線的信箱伺服器，必須將負載平衡器健康情況探查設定為檢查 < virtualdirectory > /healthcheck.htm， <https://mail.contoso.com/owa/healthcheck.htm> 例如 。
深入瞭解受控 可用性中的受控可用性。