Exchange 2010 SP1 中的新高可用性和站台恢復功能

 

適用版本: Exchange Server 2010 SP1

上次修改主題的時間: 2015-03-09

Microsoft Exchange Server 2010 Service Pack 1 (SP1) 包含了一些新的功能,並對 Exchange 2010 的量產發行 (RTM) 版本中所引進的功能予以增強。 新的和改進的功能進一步延伸案例,讓您達成 Exchange 2010 環境的資料和服務可用性。

Exchange 2010 SP1 提供下列新的高可用性功能和對現有高可用性功能的改進:

  • 連續複寫 - 區塊模式

  • 使用中信箱資料庫重新發佈

  • 增強的資料中心啟動協調模式支援

  • 全新和加強的管理與監視指令碼

  • Exchange 管理主控台使用者介面的增強功能

  • 容錯移轉效能的改良功能

  • 復原無反應 I/O 上的可延伸儲存引擎

這些功能將在稍後詳細說明。

連續複寫 - 區塊模式

在 Exchange 2010 的 RTM 版本和 Exchange Server 2007 的所有版本中,連續複寫的運作方式是將主動資料庫副本產生的記錄檔複本傳送到被動資料庫副本。 從 Exchange 2010 SP1 開始,這種連續複寫形式稱為*「連續複寫 - 檔案模式」。 Exchange 2010 SP1 也引進了一種全新形式的連續複寫,稱為「連續複寫 - 區塊模式」*。 在區塊模式中,每項更新都會寫入到主動資料庫副本的主動記錄緩衝區,同時也會傳送到每個被動信箱副本上的記錄緩衝區。 當記錄緩衝區已滿時,每個資料庫副本會依產生順序建置、檢查和建立下一個記錄檔。 若是故障對主動副本造成影響,將以多數或所有最新的更新來更新被動副本。 主動副本不會等待複寫完成,以防止複寫問題影響用戶端體驗。

只有在檔案模式的連續複寫已經是最新時,才能使用連續複寫 - 區塊模式。 記錄檔複製器會自動執行進入及離開區塊模式的轉換作業。 區塊模式可動態縮短從對主動副本進行變更到將變更複寫到被動副本的延遲時間。 除了複寫個別的記錄檔寫入之外,區塊模式也會變更被動副本的啟動程序。 如果發生失敗狀況時副本正處於區塊狀態,系統就會使用啟動程序中可用的任何局部記錄內容。 如此即可避免讓主動副本上目前的記錄檔變成單一失敗點。

使用中信箱資料庫重新發佈

Exchange 2010 SP1 包含名為 RedistributeActiveDatabases.ps1 的指令碼,可由系統管理員定期執行,根據系統管理員設定的啟動喜好設定,將主動資料庫副本平衡分配到資料庫可用性群組 (DAG)。 此外,Active Manager 最佳副本選擇程序還新增了副本分配偵測功能。 具體來說,在針對無失真轉換進行第一輪最佳副本選取時,現在會根據喜好設定而非最低失真度來排序可能的目標。

增強的資料中心啟動協調模式支援

Exchange 2010 RTM 包含名為資料中心啟動協調 (DAC) 模式的設定模式,可支援 DAG 站台復原。 在 DAC 模式中,您可使用 Exchange 指令程式來執行資料中心轉換。 在 RTM 版本中,DAC 模式限於至少有三個成員,且至少有兩個或以上的成員在主要資料中心的 DAG。

在 Exchange 2010 SP1 中,DAC 模式則可延伸支援具有兩個成員且在不同資料中心各有一個成員的 DAG。 支援兩個成員 DAG 的 DAC 模式使用見證伺服器提供進一步仲裁。 此外,DAC 模式也延伸支援將所有成員部署在單一 Active Directory 站台中的 DAG,包括已延伸到多個位置的單一 Active Directory 站台。

全新和加強的管理與監視指令碼

Exchange 2010 SP1 包含幾個新增和增強的指令碼,可大幅提升管理和監視體驗:

  • CheckDatabaseRedundancy.ps1 (新增)   您可以使用此指令碼檢查複寫資料庫的備援,如果發現資料庫復原能力處於危險狀態 (例如,只有一份正常的複寫資料庫副本),就會產生事件。 此指令碼伴隨 Microsoft System Center Operations Manager 2007 管理組件變更,可用來監視不具備援的資料庫,這在沒有 RAID 的環境中特別有用。

  • StartDagServerMaintenance.ps1 和 StopDagServerMaintenance.ps1 (新增)   您可以使用 StartDagServerMaintenance.ps1 讓 DAG 成員停止服務來進行維護。 這會將主動資料庫移出伺服器,並防止資料庫移到該伺服器。 此外也可確定該伺服器上的所有重要 DAG 支援功能 (例如,Primary Active Manager PAM 角色) 移到其他伺服器,並防止再移回該伺服器。 另一個指令碼 StopDagServerMaintenance.ps1 則可供完成作業並移除封鎖。

  • CollectOverMetrics.ps1 (增強)   您可以使用此指令碼來收集轉換和容錯移轉資料。 Exchange 2010 SP1 增強了此指令碼,以加入連續複寫 - 區塊模式的計量,以及複寫和重新顯示管線的更多詳細資料。 此外,報告功能也有增強。

  • CollectReplicationMetrics.ps1 (增強)   此指令碼會在執行時即時收集關於連續複寫的計量,所以是一種主動形式的監視。 指令碼支援可讓您自訂指令碼行為和輸出的參數。

增強的 Exchange 管理主控台使用者介面

Exchange 2010 SP1 包含 Exchange 管理主控台 (EMC) 增強功能來管理 DAG。 例如,EMC 現在可針對 DAG 支援管理 IP 位址以及替代見證伺服器設定。 您不再需要使用 Exchange 管理命令介面來進行這些設定。

改善的容錯移轉效能

Exchange 2010 SP1 包含變更來改善容錯移轉和轉換效能與行為。 在 Exchange 2010 RTM 版中,不論是發生容錯移轉或轉換,啟動的被動副本會立即停止重新顯示複製到該被動副本的記錄檔。 主動副本接著會卸載 (若尚未卸載),而且任何剩餘的記錄檔會複製到啟動的被動副本。 假設任何遺失資料都在自動資料庫裝載撥號設定內,被動副本會變成新的主動副本,而資料庫會在非正常關機狀態下裝載。 這時,複製到先前被動 (現為主動) 副本的所有記錄檔將重新顯示,以維持資料庫的一致性。

在 Exchange 2010 SP1 中,不論是發生容錯移轉或轉換,啟動的被動副本上的 Microsoft Exchange 複寫服務會繼續重新顯示複製到該被動副本的記錄檔,直到主動副本產生的最後一個記錄檔複製過去。 這可針對處於幾近一致狀態的資料庫執行裝載作業。

其他效能增強的變更還包括逾時和其他演算法詳細資料,以改善容錯移轉效能以及容錯移轉後的 I/O 效能。

復原無反應 I/O 上的可延伸儲存引擎

Exchange 2010 SP1 包含新的復原邏輯,會在某些狀況發生時利用內建 Windows 檢查錯誤行為。 特別是可延伸儲存引擎 (ESE) 已更新,以便在 I/O 無反應時進行偵測,並採取修正動作自動復原伺服器。 ESE 負責維護 IO 監控執行緒,它能偵測出經過特定時間後仍未完成作業的 I/O。 根據預設,若資料庫的 I/O 超過一分鐘仍未完成作業時,ESE 便會記錄下事件。 若資料庫的 I/O 超過 4 分鐘仍未完成動作,則 ESE 會在可行的狀況下將事件記錄成特定失敗事件。 ESE 事件 507、508、509 或 510 可能不會被記錄,這要視無反應 I/O 的性質而定。若是作業系統磁碟區受到影響或是寫入事件記錄的能力受到影響等此類的問題,則不會記錄該事件。 若已記錄下這些事件,則 Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 將會終止 wininit.exe 程序使 Windows 執行檢查錯誤。

在某些情況下,由於整個儲存堆疊可能受到中止的影響,而導致無法將失敗事件寫入 Crimson 通道或 Windows 事件記錄的其他任何區域。 ESE 也會透過驗證可寫入的事件記錄來監視 Crimson 通道。 若經過一段時間仍無法寫入事件記錄檔,MSExchangeRepl 便會終止 wininit.exe 而引發 Windows 檢查錯誤。當作業系統 I/O 無反應時,系統很顯然無法將任何 ESE 事件寫入事件記錄中。

注意事項附註:
應用程式與服務記錄是 Windows Server 2008 中的一種新事件記錄類別。 這些記錄儲存單一應用程式或元件中的事件,而非可能影響整個系統的事件。 事件記錄的這個新類別稱為應用程式的 Crimson 通道。 如需相關資訊,請參閱監視高可用性及站台恢復

Exchange 2010 SP1 中的這項基於檢查錯誤的新復原功能,其設計目的並非要進行重試或是等待儲存堆疊發出會造成容錯移轉的錯誤,而是要快速地將 I/O 無回應或控制器無回應的情形復原。 當檢查錯誤發生時,會出現如下的錯誤代碼:

CRITICAL_OBJECT_TERMINATION (f4)

重要的系統操作程序或執行緒已經意外結束或被終止。

警告警告:
出現此檢查錯誤錯誤碼不一定表示此錯誤是由 Exchange 所造成。 任何終止 wininit.exe 的動作 (包括管理員透過工作管理員或其他工作管理工作所執行的動作) 均會造成相同的檢查錯誤錯誤碼。

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