Compartilhar via

CAS 陣列物件大解謎 - 第 2 部分

  • Artigo

英文原文已於 2012 年 3 月 29 日星期四發佈

歡迎回來！在 CAS 陣列物件大解謎 - 第 1 部分中，我們釐清了有關 Exchange Server 2010 中 CAS 陣列物件的三項疑點。

  1. CAS 陣列物件不會平衡負載您的流量
  2. CAS 陣列物件不會服務 OWA、ECP、EWS、自動探索、IMAP、SMTP 或 POP
  3. CAS 陣列物件不需要包含在 SSL 憑證中

在第 2 部分中，我們將討論剩下的三項要點，一口氣掃空 CAS 陣列物件的所有疑雲，協助您更正現有的部署及/或更周延地計畫未來的部署。

  1. CAS 陣列物件不應透過 DNS 由外部用戶端解析
  2. CAS 陣列物件不應在建立 Exchange Server 2010 信箱資料庫和將信箱移入資料庫後才進行設定或變更
  3. 即使您只有一個 CAS 或單一個多角色伺服器，也應設定 CAS 陣列物件。

4. CAS 陣列物件不應透過 DNS 由外部用戶端解析

如我在第 1 部分所提及的 (至少提過兩次，我懶得算了)，您的 CAS 陣列物件 FQDN 不應該和其他服務 (例如 OWA、ECP、EWS、EAS、自動探索或 Outlook 無所不在外部主機名稱) 用一樣的 FQDN。

關於這點最主要的原因是「Outlook 無所不在」的用戶端會先嘗試透過 DNS 解析 CAS 陣列物件 FQDN，以便判斷是否還需要再嘗試 RPC (over TCP) 連線，或是直接選擇 HTTPS。您允許 RPC (over TCP) 連線直接由網際網路連入您的內部網路嗎？希望沒有，如果有的話，您的 Exchange 風險與健全狀況評估方案 (可能為英文網頁) 報告上會出現一個大大的紅色旗標。假如客戶端因為可以成功解析 CAS 陣列物件 FQDN，而首先嘗試了透過 RPC (over TCP) 連線的話，他們可能要經歷一段明顯的延遲，才會退回來嘗試以 HTTPS 連線至「Outlook 無所不在」的 Proxy URL。如果使用者因延遲而感到效能不彰及/或以為服務中斷的話，可能導致您的服務台接到大量的來電。

若要避免此情況其實很簡單，只要確保您的內部 CAS 陣列物件 FQDN 在內部 DNS 中是獨一無二的，比方說像 outlook.corp.contoso.com，而您其他非 RPC (over TCP) 服務 URL 則採用類似 mail.contoso.com 透過分割 DNS 區分內部與外部。

若您尚未使用過分割 DNS，它的做法是讓您用一組內部和外部 DNS 伺服器來處理同一個正向對應區域，例如 contoso.com 的要求。而這兩個 DNS 基礎結構是完全區隔開來的。之間沒有區域傳輸，也不會運用彼此做為 DNS 正向對應。這樣的設定能讓內部使用者得以運用內部 DNS 基礎結構，將主機 mail.contoso.com 解析為要進入負載平衡器 VIP 的內部 IP 位址 (例如 192.168.1.10)；而外部使用者則會將其解析為公用 IP 位址，它可能指向您的周邊網路中面向網際網路的 Forefront TMG/UAG 基礎結構。雖然 CAS 陣列物件 IP 位址和非 RPC (over TCP) 服務 URL (OWA、ECP、EWS 等等) 的內部 IP 位址常有可能用到相同的負載平衡器 VIP，但它們會採用不同的「維持運作」檢查，來進行合適的服務狀態偵測。

您的 DNS 提供萬用回應服務嗎？

我至少遇過一位客戶採用外部 DNS 伺服器，會以萬用記錄來回應所有來自不存在之主機名稱的查詢要求。這意謂著您可以送出任何某個不存在的名稱.contoso.com 的 DNS 要求，而 DNS 伺服器會一律傳回他們公司網站的 IP 位址。(以網際網路標準的觀點來看，萬用記錄完全是合法的。如需編輯器的詳細資料，請參閱 RFC 1034 (可能為英文網頁) 的 4.3.3 一節)。

就因為如此，他們的「Outlook 無所不在」用戶端一律都會解析 CAS 陣列物件 FQDN，而且會先嘗試 RPC (over TCP) 連線，才切換到 HTTPS。假設您的情況也類似如此，採用了會以萬用回應來處理特定正向對應區域的外部 DNS 伺服器，我建議您的「Outlook 無所不在」Proxy URL 儘量避免用到那個正向對應區域。

一點題外話提醒您，不要忘記為您的負載平衡解決方案設定好合適的健全狀況監視器。有關監視結果的最佳服務方法，請連絡您的負載平衡解決方案廠商。Exchange Server 2010 負載平衡器部署 (可能為英文網頁) 中列有一些已通過 Exchange 2010 解決方案測試的負載平衡器廠商，以及他們對 Exchange 2010 的相關網頁連結。請注意，此處所列的「不是」可支援負載平衡廠商的確切名單。純粹只是 Microsoft 為解決方案之測試與支援所選擇直接合作的幾家廠商名單而已。

粗略地舉個例，假設您的 HTTPS 服務類型 FQDN 在碰到 TCP/443 回應時執行了「保持運作」測試，而負載平衡解決方案不再傳送新的用戶端流量到任何在 TCP/443 上停止回應的客戶端存取伺服器。CAS 陣列物件的 RPC (over TCP) 服務 FQDN 可能會在 TCP/135 的「RPC 端點對應程式」上，以及您為「RPC 用戶端存取服務」和「通訊錄」服務選擇的兩個固定 TCP 連接埠上 (可能為英文網頁)，進行「保持運作」測試。假如某用戶端存取伺服器的這三個連接埠中，有任何一個停止回應，負載平衡解決方案將不再傳送新的用戶端流量到該 CAS 進行 RPC (over TCP)，直到所有連接都再次開始回應為止。若您未設有靜態 TCP 連接埠，則 Exchange 會在啟動時為每項服務選擇一個動態 TCP 連接埠，讓某些負載平衡解決方案的「保持運作」測試變得更加困難，甚至完全不可能。

5. CAS 陣列物件不應在建立 Exchange Server 2010 資料庫後才進行設定

許多時候我們急著安裝信箱伺服器，建立信箱資料庫，希望能開始進行 Jetstress (可能為英文網頁) 存儲解決方案的驗證測試。聽我的勸，現在慢一點省得日後更麻煩。雖然許多人都認為信箱伺服器是最重要的伺服器角色，但要是前門被鎖死了，那也沒有用，因為您沒辦法從用戶端存取伺服器連到它們。

如果您在 CAS 陣列物件尚未就位時，就開始建立信箱資料庫，您會看到每個資料庫的 RpcClientAccessServer 屬性都具有一個隨機的用戶端存取伺服器，而它們的 Active Directory 網站都相同。

原本正確的樣子應該像這樣 (使用 CAS 陣列物件的 FQDN)


圖 1：若已建立 CAS 陣列物件，信箱資料庫的 RpcClientAccessServer 屬性即會填入該 CAS 陣列物件的 FQDN

而它卻會變成這樣：


圖 2：若未建立 CAS 陣列物件，則信箱資料庫的 RpcClientAccessServer 屬性將會填入用戶端存取伺服器的 FQDN

而用戶端設定檔看來如下...


圖 3：若未建立 CAS 陣列物件，Outlook 用戶端會設成用戶端存取伺服器的 FQDN

用戶端的連線會像這樣...


圖 4：用戶端連線到用戶端存取伺服器的 FQDN

乍看之下好像沒什麼不對，一切都運作正常，但您這樣可是會種下未來的禍源。當您要以此設定開始移動信箱到 Exchange Server 2010 時，Outlook 會取用使用者設定檔中「伺服器」欄位的 CAS 名稱。這是可行的，除非不提供用戶端存取伺服器，或者日後被解除委任，換成另一個名稱不同的伺服器。那個時候，您不會寧可利用一個用戶端存取伺服器的負載平衡集區嗎？當然會！

您可能會想說：「那又怎樣，要是真有那麼一天，大不了我再建立一個 CAS 陣列物件，然後修正資料庫上的 RpcClientAccessServer，不就天下太平了？」我得警告您，在如此的前提下，那種做法只能適用於您移到 Exchange 2010 的信箱。假設有一位使用者現有的 Outlook 設定檔設成指到某個 CAS 名稱而非 CAS 陣列物件的話，他就會繼續連線到 CAS 名稱，而不會自行更新為採用 CAS 陣列物件 FQDN。

設定檔無法自行更新，因為用戶端不會收到來自 CAS 的 ecWrongServer 回應。為什麼收不到回應呢？因為對於任何透過 RPC (over TCP) 的信箱資料庫而言，所有的 CAS 都是有效的連線點，這樣用戶端才可以因應資料中心的轉換/容錯移轉事件，而無需重新設定。系統管理員的任務，只要查閱 CAS 陣列物件的 DNS 記錄，再指到 CAS 剩餘存活的集區即可。現階段要修正信箱設定檔的唯一方法，就是在 Outlook 內部手動進行設定檔修復，也就是透過 GPO 發佈 Office PRF 檔案 (對於未加入網域的機器無效)，或著藉由解除委任使用者設定檔中指名的 CAS 伺服器，停用端點。這項終極的手段 (一定要測試啊！) 將會觸發 Outlook 2007 或 Outlook 2010 的「自動探索」開始一次完整的設定檔修復。Outlook 2003 只能透過設定檔修復或 PRF 檔才能修復。截至我寫這篇文章為止，「自動探索」更新「Outlook 無所不在」設定並為其他功能 (如 OOF 管理、空閒/忙碌，以及收件匣規則管理等) 找尋 EWS URL 的標準流程內，尚未包含更新設定檔到新伺服器名稱這個動作。

這也意謂著如果您從某個使用了 CAS 陣列物件 (假設名叫 Boston-CASArray 好了) 的 AD Site-A，將信箱從資料庫移入 AD Site-B 時 (假設它使用的 CAS 陣例物件名稱為 Redmond-CASArray)，設定檔將不會更新，且伺服器名稱欄位仍會是 Boston-CASArray 的 FQDN。假如您有一群使用者因職位變更，或在解決方案週期的某個階段必須大規模將內部信箱移動到其他網站時，請務必謹記這一點。如果您真的在建立 Exchange 2010 資料庫時發現 CAS 陣列物件尚未建立，一定要趕緊回頭修正資料庫的 RpcClientAccessServer 屬性，改成使用 CAS 陣列物件，才可以將信箱移入資料庫。

6. 即使您只有一個 CAS 伺服器或一個多角色伺服器，也應該設定 CAS 陣列物件

回頭複習一下前面講過的重點。若您在後期才新增 CAS 陣列物件的話，用戶端不會自行更新為使用 CAS 陣列物件。那麼如果您只有一個 CAS 呢？您可能會想說那就無所謂了吧。我想在這個當下，它確實是無所謂沒錯，但如果能未雨綢繆，一勞永逸的話，又何樂而不為呢？萬一過了一年之後您發現那個 CAS 不得不換掉呢？要是您所有的用戶端設定檔都指到某個 CAS 名稱，那時要轉換它們可就免不了發生中斷或一番苦戰了。您得在新增 CAS 後，選用上面提過的其中一種方法修復他們的設定檔；不然就是得解除委任現有的 CAS，再引入一個主機名稱相同的新 CAS，也就是說必須停機一段時間。而對我來說，這兩種選擇都很糟。

又萬一日後您的業務需求有所變動，用戶端存取必須要具有很高的可用性呢？為達成這個目標您只能增加第二個 CAS 和負載平衡解決方案。此時噩夢又要重演了，您得依我們教過的方法再一次修改每個人的設定檔。這種選擇我也不能接受。

要我說的話，我會建議您在一開始就建立好 CAS 陣列物件。沒有負載平衡器又只有單一個 CAS 時該怎麼處理？簡單！就用一般的做法設定 CAS 陣列物件就行了。命名、AD Site 還有 FQDN，然後只要將 DNS 的 A 記錄指到您當時唯一擁有的 CAS 或多角色伺服器的 IP 即可。這麼一來就再無後顧之憂了，就算哪天您得更換這唯一的 CAS 或多角色伺服器，您要做的只是建立新的伺服器，然後變更 DNS 記錄的 IP 位址，一切都不會因此中斷。萬一未來需要提高可用性，也只要啟動您的負載平衡解決方案，然後將 CAS 陣列物件的 DNS 記錄 IP 位址改成指到負載平衡解決方案的 VIP 即可。不賴吧！

希望這篇文章有助您釐清一些有關 CAS 陣列物件的誤解，讓大家能朝向更良好的 Exchange Server 2010 移轉邁進。

Brian Day
首席實務工程師，訊息部門

這是翻譯後的部落格文章。英文原文請參閱 Demystifying the CAS Array Object - Part 2