Exchange 佇列問題與解答負載平衡、Edge Transport 和其他
Henrik Walther
問：在我們的企業生產環境中部署了好幾部執行 Microsoft® Office SharePoint® Server 的伺服器。這些伺服器分別都需要透過 Hub Transport (HT) Server 在我們新部署的 Exchange Server 2007 基礎結構中轉送外寄郵件。由於 SharePoint Server 只讓我們在 [管理中心] | [作業] | [外寄電子郵件設定] 頁面下指定單一 SMTP (Exchange) Server 的完整網域名稱 (FQDN)，如 [圖 1] 所示，我想知道我們要如何刪除此單一失敗點？
[圖 1] SharePoint 管理中心頁面上的外寄電子郵件設定 (按一下以放大影像)
答：這個問題很好，因為很多組織都只著重高可用性，因此不接受企業生產環境中的任何單一失敗點。尤其是訊息與共同作業服務更是如此。
Exchange 2007 HT Server 在預設情況下很有彈性。也就是說，如果您在 Active Directory® 站台中部署的 HT Server 不只一部，當該 Active Directory 站台中的 HT Server 無法使用時，嘗試傳遞訊息的來源 HT Server 便會前往 Active Directory 站台中下一個可用的 HT Server。這是透過使用循環配置資源 DNS 機制來完成的 (如果清單中的第一個 HT Server 沒有回應，就會嘗試下一個)。
因此當它到達所有 HT 至 HT 和信箱伺服器至 HT (即組織內部) 通訊時，我們就無須擔心高可用性 (或此時的負載平衡) 的問題，因為這是原生 Exchange 2007 功能。不過請記得，如果您在也安裝了 Mailbox server role 的電腦上安裝 HT server role，當 Microsoft Exchange 郵件提交服務送出訊息時，Mailbox server role 永遠會偏好本機 HT Server 勝過 Active Directory 站台上的其他 HT Server (即使當本機安裝的 HT Server 無法使用時)。
上述資訊不見得對 SharePoint Server 有用，但是在往下繼續討論之前先了解這點是很重要的。由於 HT Server 在預設情況下很有彈性，因此無論是使用硬體負載平衡器或 Windows® 網路負載平衡 (WNLB) 功能，都不支援 Exchange 2007 中各部 HT Server 進行負載平衡內部組織通訊。
事實上，將輸入 SMTP 流量負載平衡到以 Exchange 2007 RTM 版本為基礎的 HT Server 也沒有受到任何支援。但是 Exchange 2007 SP1 改變了這點。藉由 SP1，您仍然無法使用負載平衡器或 WNLB 功能來負載平衡內部組織通訊 (不過您本來就沒有理由這麼做)，但是您可以負載平衡來自非 Exchange 來源 (例如 SharePoint Server) 和 Exchange 用戶端 (例如使用 HT Server 上的預設用戶端接收連接器來提交輸出訊息到 Exchange 2007 組織的 IMAP 或 POP 用戶端) 的輸入 SMTP 流量。
因此為了將 SharePoint Server 設為透過 Exchange 2007 SP1 組織轉送訊息，您只要在 Active Directory DNS 上建立一個 DNS 記錄，再將它指向硬體負載平衡器，硬體負載平衡器接著就可以將流量分散到多部 HT Server 上，或使用 WNLB 功能來完成此目標。若要使用第二種方法，請使用虛擬 IP 位址和 FQDN (例如 mail.contoso.com) 來設定 WNLB 叢集，然後在 [連接埠規則] 索引標籤下加入連接埠 25 (來自非 Exchange Server 的輸入 SMTP 流量) 及 587 (來自 IMAP 和 POP 等 Exchange 用戶端的輸入 SMTP)。[圖 2] 顯示 [連接埠規則] 索引標籤在此設定下的模樣。您也要確保您指派特定虛擬 NLB 叢集 IP 位址到這兩個規則，而非選取所有 IP 位址。
[圖 2] 定義的連接埠規則 (按一下以放大影像)
設定 NLB 叢集之後，您必須建立新的接收連接器，這個接收連接器應設定為接聽連接埠 25，而且只允許要求它使用此連接器轉送訊息的伺服器。此外，確認此連接器使用之前建立的虛擬 NLB 叢集 IP 位址。
問：我們的通訊基礎架構是以 Exchange Server 2007 為基礎。為了讓 Exchange 2007 信箱伺服器在硬體和存放層級備援，它們全是以叢集連續複寫 (CCR) 技術為基礎的叢集信箱伺服器。各個 CCR 叢集中的主動和被動節點都位於相同的實體資料中心。現在我們已經將 Exchange 2007 伺服器升級到 SP1，我們想要使用 Exchange 2007 SP1 隨附的新待命連續複寫 (SCR) 技術將信箱資料庫複寫到第二個站台的信箱伺服器，藉此運用服務及資料可用性。
我們知道 SCR 來源可以是以 CCR 或單一複本叢集 (SCC) 技術為基礎的 Exchange 2007 SP1 獨立式信箱伺服器或叢集信箱伺服器 (CMS)。但是 SCR 目標伺服器呢？
答：SCR 目標伺服器 (亦稱為 SCR 端點) 必須是獨立式信箱伺服器，該獨立式信箱伺服器的本機連續複寫 (LCR) 不能針對任何儲存群組或是已安裝 Mailbox server role 的 Windows 容錯移轉叢集 (前身為 Microsoft Cluster Server) 中的被動節點啟用。這表示您可以組成您的容錯移轉叢集，接著在該容錯移轉叢集的被動節點上安裝 Mailbox server role，但是您無法使用叢集信箱伺服器當作 SCR 目標。
問：我們的組織使用 Exchange 2007 當作訊息平台。我們甚至決定將周邊網路中的舊反垃圾郵件/防毒解決方案替換成安裝了 Forefront™ Security for Exchange 的 Exchange 2007 Edge Transport Server 架構解決方案，好讓我們受益於多層訊息保障和安全性。我們打算最近再部署至少兩部 Edge Transport Server。
但問題來了，我們要如何將輸入 SMTP 連線負載平衡到 Exchange 2007 Edge Transport 架構的郵件檢疫解決方案，進而分散負載並使它完全備援呢？
答：如果您周邊網路中的 Edge Transport Server 是網際網路面向 SMTP 伺服器，那麼您可以使用類似 Microsoft 資訊科技 (Microsoft IT) 小組中所用的方法。Microsoft IT 部署了六部 Edge Transport Server (三部在里德蒙，三部在矽谷)，用來處理每日超過 160 萬封的輸入郵件 (而且篩選出超過 130 萬封的垃圾郵件)。
Microsoft IT 針對 Microsoft.com 網域具有總共三筆郵件交換 (MX) 記錄。包括：maila.microsoft.com、mailb.microsoft.com 及 mailc.microsoft.com (見 [圖 3])。每筆 MX 記錄都將喜好設定設為 10，因此會使用 DNS 循環配置資源的方法來隨機選取 MX 記錄。此外，兩個 IP 位址 (郵件主機) 都與每個 MX 記錄相關聯。
[圖 3] Microsoft.com 的 MX 記錄和網際網路郵件主機 (按一下以放大影像)
為什麼每個 MX 記錄有兩個 IP 位址？因為無論您為網域設定了多少 MX 記錄，有些郵件傳輸代理程式 (MTA) 永遠會選取相同的 MX 記錄。在 Exchange Server 方面，多年來這都不成問題 (在 Exchange 2000 出現之前)，但遺憾的是，市面上還是有包含這個設計缺陷的 MTA。因此，無論哪個 MTA 嘗試傳遞郵件到 Microsoft.com 位址，所有 SMTP 連線都是結合使用 DNS 循環配置資源與負載平衡來分散。
問：我們的 Active Directory 網域是以 Windows Server® 2003 網域控制站 (DC) 為基礎。我們目前正在規劃將 Windows Server 2003 DC 轉換成 Windows Server 2008，並將 Exchange 2003 郵件環境轉換成 Exchange Server 2007。我們能否透過將所有執行 Windows Server 2003 的伺服器升級到 Windows Server 2008，然後將郵件環境從 Exchange Server 2003 轉換到 Exchange 2007，藉此將 Active Directory 網域轉換成 Windows Server 2008？
答：可以，Exchange Server 2003 SP2 在由 Windows Server 2008 DC 構成的 Active Directory 網域中受到完全支援，因此您大可放手執行您的計劃。不過請記得，若您打算使用 Windows Server 2008 唯讀網域控制站 (RODC)，就不應該將 Exchange 收件者更新服務 (RUS) 設為使用 RODC。
Henrik Walther 是一位微軟認證架構設計師：不僅是傳訊 (新手) 和 Exchange MVP ，而且在 IT 產業擁有 14 年以上的經驗。他在 Interprise Consulting 擔任技術架構設計師，同時也是 Biblioso Corp. 的技術文件作家。
© 2008 Microsoft Corporation and CMP Media, LLC.著作權所有，並保留一切權利。未經許可，不得部分或全部重製。