瞭解傳輸方面的 SMTP 容錯移轉和負載平衡

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

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

當組織中有多個 Hub Transport Server 時，Exchange 會將郵件流量自動散發至組織中的所有 Hub Transport Server。當所有伺服器皆可使用時，平均散發負載的負載分散才會成功。不過，如果有一個或多個伺服器無法使用，剩餘伺服器上的負載分散可能會變得不平均，尤其是當組織是跨多個 Active Directory 站台散發時更是如此。

在 Microsoft Exchange Server 2010 Service Pack 1 (SP1) 中，已針對在集線傳輸伺服器間散發負載的決策機制進行數項改善措施。

要尋找與郵件路由相關的管理工作嗎？請參閱管理郵件路由。

目錄

Exchange Server 2010 RTM 行為

Exchange 2010 SP1 改良功能

運用傳輸伺服器的 Windows 網路負載平衡或協力廠商負載平衡解決方案

Exchange Server 2010 RTM 行為

在 Exchange 2010 的量產發行 (RTM) 版本中，當傳輸伺服器需要將數個訊息路由到相同目的地時，伺服器一開始會決定那些訊息的下一個躍點。如果下一個躍點有多個目標伺服器，它會將用來傳遞訊息的連線平均地負載平衡到使用由增強型網域名稱系統 (DNS) 提供的循環配置資源方法的目標伺服器上。例如，假設有一個拓撲，其中有兩個 Active Directory 站台，每個站台各有三個 Hub Transport Server (如下圖所示)。當站台 A 中的 Hub Transport Server (例如 Hub02) 必須傳送訊息至站台 B 時，則該訊息的下一個躍點是站台 B。因此，下一個躍點有三個可能目標：Hub04、Hub05 及 Hub06。伺服器會將連線數平均散發至那三個目標 (如下圖所示)。此動作會使訊息隨著時間平均散發至所有連線。

Exchange Server 2010 RTM 中的負載平衡

同樣地，站台 B 中的 Hub Transport Server 會將傳送到站台 A 的收件者的訊息平均散發到 Hub01、Hub02 和 Hub03。而且，由於站台 A 訂閱 Edge01，因此傳送到網際網路之訊息的下一個躍點目標為 Hub01、Hub02 及 Hub03。

如果下一個躍點中有一或多個伺服器無法使用，則會發生問題。例如，假設站台 B 中的 Hub04 因為排程維護而無法使用。站台 A 中的伺服器並未保有站台 B 中每個伺服器的可用性狀態。站台 A 中的伺服器會將指向站台 B 的負載散發到該站台中的三個 Hub Transport Server 上。然而，那些連線約有三分之一會傳送到 Hub04，但不會成功。這些連線將會容錯移轉到下一個可用的伺服器，而站台 B 中的其中一個 Hub Transport Server 將會比其他伺服器處理更多負載 (如下圖所示)。

不平均的負載平衡

只要擁有兩個以上目標的下一個躍點中有無法使用的伺服器，就可能發生這個非預期的行為。如上述範例所示，下一個躍點可以是另一個 Active Directory 站台，或者是擁有多個 Hub Transport Server 列為來源伺服器的連接器 (例如上圖顯示的拓撲中，訂閱的 Edge Transport Server 的傳送連接器)。

這並不是信箱伺服器的郵件提交問題。郵件提交服務將會偵測站台中無法使用的 Hub Transport Server，而且不會嘗試傳遞到那些伺服器。在前述的範例中，雖然站台 B 中的其中一個 Hub Transport Server 可能會有較重的站台間流量負載，但是由站台 B 中的信箱伺服器產生的負載將會平均分攤到 Hub05 和 Hub06。

Exchange Server 2010 RTM 行為

Exchange 2010 SP1 改良功能

為了解決前一節所描述的問題，Exchange 2010 SP1 中新增了一個稱為狀況良好伺服器選取器的新元件。狀況良好伺服器選取器會維護一個無法使用之伺服器的清單。增強型 DNS 在套用負載平衡的循環配置資源邏輯時，會使用此清單篩選出任何無法使用的伺服器。若要示範狀況良好伺服器選取器如何協助負載平衡，請考量上圖所顯示的問題條件。在 Exchange 2010 SP1 中，增強型 DNS 會先編譯下一個躍點 (站台 B) 中的可能目標清單。然後，它會要求狀況良好伺服器選取器篩選該清單。狀況良好伺服器選取器將會報告下一個躍點站台 B 的 Hub04 狀況不良。增強型 DNS 會將 Hub04 從下一個躍點站台 B 的可能目標清單中移除，並只在 Hub05 和 Hub06 之間使用循環配置資源負載平衡 (如下圖所示)。

具備狀況良好伺服器選取器的負載平衡

狀況良好伺服器選取器

在其最簡單的形式中，狀況良好伺服器選取器會追蹤視為狀況不良的伺服器，如此一來，循環配置資源負載平衡中就不會包括那些伺服器。從狀況良好伺服器選取器角度來看，狀況不良伺服器的定義是連線嘗試傳回任何 Windows 通訊端 (Winsock) 錯誤碼的伺服器。

對於每一個狀況不良伺服器，狀況良好伺服器選取器會保有下列資訊：

• 伺服器 IP 位址

• 重試計數

• 上次重試時間

重試行為

當某個伺服器標記為狀況不良時，狀況良好伺服器選取器會在該伺服器恢復線上時，確保再次嘗試與該特定伺服器的連線進行偵測。狀況良好伺服器選取器會使用下列設定來決定狀況不良伺服器之連線的重試頻率：

• QueueGlitchRetryInterval 與 QueueGlitchRetryCount   這些設定會決定當特定伺服器第一次標記為狀況不良時，良好伺服器選取器要重試其連線的次數及間隔。這些設定是設定於 EdgeTransport.exe.config 檔案中。這些設定的預設值是 1 分鐘和 4 次重試嘗試。這些值表示，在預設組態中，每分鐘會嘗試與狀況不良伺服器的連線四次。

• TransientFailureRetryInterval 與 TransientFailureRetryCount   如果狀況不良伺服器無法使用，則狀況良好伺服器選取器會使用這些設定來決定下一組重試嘗試的頻率。這些設定是針對每個傳輸伺服器而設定。預設值是 5 分鐘 (Edge Transport Server 上是 10 分鐘) 及 6 次重試嘗試。這些值表示，在預設組態中的前四分鐘之後，每五分鐘會嘗試與狀況不良伺服器的連線六次。

• OutboundConnectionFailureRetryInterval   如果狀況不良伺服器無法使用，狀況良好伺服器選取器會根據此參數指定的頻率繼續重試連線。此設定是針對每個傳輸伺服器而設定。預設值是 10 分鐘 (Edge Transport Server 上是 30 分鐘)。此值表示，在預設組態中的前 34 分鐘之後，每隔 10 分鐘會嘗試與狀況不良伺服器的連線。

如需如何設定這些設定的逐步指示，請參閱設定郵件重試、重新提交及到期間隔。

當嘗試連線的時間到時，狀況良好伺服器選取器只會允許一個與狀況不良伺服器的連線嘗試。如果該連線成功，SMTP 外寄元件將會通知狀況良好伺服器選取器該連線成功。屆時，狀況良好伺服器選取器會將該伺服器從狀況不良伺服器清單移除。

狀況良好伺服器選取器與陰影備援

傳輸的陰影備援元件包括活動訊號功能。活動訊號是一個簡單的 SMTP 連線，用來查詢先前提交給目標伺服器的訊息狀態。狀況良好伺服器選取器篩選不會防止陰影備援管理員發出活動訊號連線嘗試。如果伺服器具有提交給狀況不良之伺服器的陰影訊息，它會嘗試進行與該伺服器的活動訊號連線。如果與狀況不良伺服器的活動訊號連線成功，狀況良好伺服器選取器會立即從狀況不良伺服器清單移除該目標伺服器。

若要深入了解陰影備援與活動訊號，請參閱瞭解陰影備援。

診斷資訊

在 Exchange 2010 SP1 中，連線記錄檔包括狀況良好伺服器選取器的診斷資訊及增強的負載平衡功能。當狀況良好伺服器選取器新增一個伺服器至狀況不良伺服器清單時，該事件會記錄到連線記錄檔中。若要找到此事件，請在連線記錄檔中搜尋 MarkedUnhealthy 字詞。在包含此字詞的那一行上，可以找到下列資訊：

• 目標主機 IP 位址

• 目標主機完整網域名稱 (FQDN)

• 接收到的 Winsock 錯誤

• 狀態：MarkedUnhealthy

• 目前的失敗計數

• 下一次重試時間

從此項目中，您可以藉由評估 Winsock 錯誤碼來識別失敗的原因。如需 Winsock 錯誤碼的完整清單及其定義，請參閱 Windows Sockets 錯誤碼。

您也可以透過分析 Current Failure Count 和 Next Retry Time 欄位，判斷有多少連線嘗試已失敗，以及目標伺服器的下一個排程重試嘗試。

您的傳輸伺服器上必須已啟用連線記錄，才能夠檢視此診斷資訊。在 Hub Transport Server 與 Edge Transport Server 上，連線記錄預設是停用的。如需設定連線記錄的詳細資訊，請參閱設定連線記錄。

Exchange Server 2010 RTM 行為

運用傳輸伺服器的 Windows 網路負載平衡或協力廠商負載平衡解決方案

如同本主題先前所述，Exchange 2010 會自動在邊際傳輸、集線傳輸與使用增強型 DNS 的信箱伺服器之間進行所有組織內郵件流量的負載平衡。不過，這項功能不涵蓋針對從非 Exchange 來源收到的郵件進行負載平衡，例如外部郵件伺服器、協力廠商反垃圾郵件或防毒解決方案、Exchange 組織之外的任何內部郵件伺服器、企業營運 (LOB) 應用程式，以及 POP 或 IMAP 電子郵件用戶端。

如果您有一個或多個這類的郵件來源，您可選擇使用將外部電子郵件分散到組織內部傳輸伺服器的統一 SMTP 命名空間 (例如 smtp.contoso.com)，將傳入的 SMTP 流量予以負載平衡。Windows 網路負載平衡 (NLB) 或協力廠商的硬體型負載平衡解決方案皆受支援。如需通過廠商測試且經過 Microsoft 檢閱符合 Exchange 2010 需求的負載平衡器清單，請參閱Microsoft 整合通訊負載平衡器部署。

重要事項：
不支援使用負載平衡解決方案處理您組織中 Exchange 伺服器之間的訊息流量。您必須從在環境中部署的任何負載平衡解決方案中排除 Exchange 伺服器之間的訊息流量。

負載平衡 Edge Transport Server 間的輸入網際網路郵件

最常見的情況是處理從網際網路內送的郵件。您不需要部署負載平衡解決方案，即可將負載分散到 Edge Transport Server。如下圖所示，使用 DNS 循環配置以及具有相同喜好設定值的郵件交換記錄 (MX 記錄)，即可達成。

使用 DNS 循環配置及 MX 記錄負載平衡網際網路郵件

如果您選擇使用 Windows NLB 或硬體負載平衡解決方案來分散傳入的網際網路郵件，則您需要發佈指向負載平衡解決方案的單一 MX 記錄。如下圖所示，負載平衡器會將內送的郵件分散到其組態中所列的所有 Edge Transport Server。

使用負載平衡解決方案分散網際網路郵件

負載平衡 Hub Transport Server 間的非 Exchange 郵件

Exchange 2010 使用接收連接器來接受內送郵件。依預設，Exchange 2010 Hub Transport Server 透過 SMTP 從 TCP 通訊埠 25 接收電子郵件時，是由名為預設接收連接器的接收連接器處理。

POP 或 IMAP 用戶端將電子郵件提交至 Exchange 2010 Hub Transport Server 時，預設是從 TCP 通訊埠 587 提交郵件。這表示從 POP 或 IMAP 用戶端提交的電子郵件會由名為預設用戶端接收連接器的個別接收連接器處理。

如果您計畫將負載平衡解決方案置於 Hub Transport Server 前端，則應該針對該目的建立個別的接收連接器，並且確定只有該特定連接器所處理的流量才予以負載平衡。只要將額外的 IP 位址新增至 Hub Transport Server，並且將此 IP 位址與新的接收連接器相關聯，就能夠辦得到。此外，應該在接收連接器上停用 [Exchange Server 驗證] 選項，以確保 Exchange 流量不會透過它路由傳送。下圖顯示使用負載平衡器將從 POP3 或 IMAP4 用戶端以及非 Exchange SMTP 伺服器接收的郵件分散到兩個 Hub Transport Server 的組態。

負載平衡 Hub Transport Server 間的非 Exchange 郵件

Windows 網路負載平衡

Windows NLB 是 Exchange 伺服器最常用的軟體負載平衡器。針對 Windows Hub Transport Server 部署 Exchange 2010 NLB 有一些相關限制：

• Windows NLB 不可用於的 Hub Transport server role 及 Mailbox server role 共存而且伺服器也加入資料庫可用性群組 (DAG) 的 Exchange Server。

  這是因為 Windows NLB 功能與 Windows 容錯移轉叢集不相容。如果使用 Exchange 2010 DAG，而且想要使用 Windows NLB，則需要在個別電腦上執行 Hub Transport server role 及 Mailbox server role。此外，DAG 成員及 Hub Transport server role 共存於同一部伺服器時，Windows NLB 會影響郵件路由。若要深入了解，請參閱使用 DAG 時共存的 Hub Transport 和 Mailbox Server 角色。

• 不建議在一個由 Windows NLB 提供負載平衡的陣列中放置超過 8 部 Hub Transport Server。如果您需要將超過 8 部 Hub Transport Server 進行負載平衡，則應該部署硬體型解決方案。

• Windows NLB 不會偵測服務中斷情形。

  它只會藉由 IP 位址偵測伺服器中斷情形。如果 Exchange Transport 服務失敗，但伺服器仍在運作中，則 Windows NLB 不會偵測故障情形，並且仍會將傳入的電子郵件路由到該 Hub Transport Server。此時需要手動介入，從負載平衡集區中移除中斷的 Hub Transport Server。

• Windows NLB 組態可能會造成通訊埠氾濫的情形，而這可能會使網路癱瘓。

  這是由於 Windows NLB 的設計必須同時將所有傳入的用戶端封包傳遞至所有交換器連接埠。雖然如此的運作方式能夠使 Windows NLB 傳輸極高的輸送量，不過可能會造成大量切換佔用的情況。

如需設定 Windows NLB 的詳細步驟，請參閱設定 Hub Transport Server 的 Windows 網路負載平衡。

硬體負載平衡

如果有超過 8 部 Hub Transport Server 需要進行非 Exchange 郵件流量的負載平衡，則需要更有延展性的負載平衡解決方案。儘管有更強固的軟體負載平衡解決方案可以使用，但硬體負載平衡解決方案可提供最大的容量。

不同於 Windows NLB 僅依據 IP 位址偵測伺服器中斷，硬體負載平衡器可設定為偵測 Exchange Transport 服務的故障，並且能夠將傳入的電子郵件路由到其他 Hub Transport Server，完全不需要任何手動介入。

如需設定硬體負載平衡解決方案的詳細步驟，請參閱設定 Hub Transport Server 的硬體負載平衡。

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