共用方式為

舊版Exchange Server的高可用性和月臺復原能力變更

  • 發行項

Exchange Server 2013 和更新版本使用 DAG 和信箱資料庫複本 (以及其他功能，例如單一專案復原、保留原則和延遲的資料庫複本) ，以提供高可用性、網站復原能力和 Exchange 原生資料保護。 自 Exchange 2010 起，已增強高可用性平臺、Exchange 資訊存放區和可延伸儲存引擎 (ESE) ，以提供可用性和較不復雜的管理，並降低成本。 這些增強功能包括：

  • 減少 IOPS：這可讓您盡可能有效率地在容量和 IOPS 方面使用較大的磁片。

  • 受控可用性：使用受控可用性時，內部監視和復原導向功能會緊密整合，以協助防止失敗、主動還原服務，以及自動啟動伺服器容錯移轉，或警示系統管理員採取動作。 將重點放在監控與管理使用者體驗，而非僅著重於伺服器與元件存留時間，才可協助確保服務持續可用。

  • 受控存放區：受控存放區是 Exchange 2013 或更新版本中重寫資訊存放區進程的名稱。 受控存放區是以 C# 撰寫，並與 Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 緊密整合，透過改善的復原能力來提供更高的可用性。

  • 每個磁片支援多個資料庫：增強功能可讓您支援多個資料庫， (在相同磁片上) 使用主動和被動複本的混合，藉此盡可能有效率地在容量和 IOPS 方面使用較大的磁片。

  • AutoReseed：自動重新植入功能可讓您在磁片失敗後快速還原資料庫備援。 如果磁碟故障，儲存在該磁碟上的資料庫副本會從主動資料庫副本被複製到備用磁碟的同一個伺服器上。 若多個資料庫複本儲存於故障的磁碟上，可於備用磁碟上全部自動重新植入。 這樣可啟用更快速的重新植入，因使用中的資料庫可能位於多個伺服器上，且資料為平行複製。

  • 自動從儲存故障復原：此功能持續展現 Exchange 2010 中的創新技術，允許系統復原會影響備援的故障。 Exchange 現在包含較長 I/O 時間的更多復原行為、MSExchangeRepl.exe的過度記憶體耗用量，以及系統處於無法排程執行緒的不良狀態的嚴重情況。

  • 延遲的複製增強功能：延遲的複本現在可以使用自動記錄播放，在一定程度上自行小心。 延遲的複本會在各種情況下自動播放記錄檔，例如頁面修補和磁碟空間不足的案例。 如果系統偵測到延遲的複本需要進行頁面修補，記錄將會自動重新執行到延遲的複本中，以進行頁面修補。 Lagged copies will also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time. 此外，延遲的複本可以使用 Safety Net，讓復原或啟用變得更容易。

  • 單一複製警示增強功能：Exchange 2010 中導入的單一複製警示不再是個別的排程腳本。 現在，它已和系統中受管理可用性元件整合在一起，屬於 Exchange 內的原生功能之一。

  • DAG 網路自動設定：系統可以根據組態設定自動設定 DAG 網路。 除手動設定選項外，DAG 也可區分 MAPI 與複寫網路，並自動設定 DAG 網路。

減少 IOPS

在 Exchange 2010 中，被動資料庫複本具有低檢查點深度，這是快速容錯移轉所需的。 此外，被動複製會主動預先讀取資料，以跟上 5 MB (MB) 檢查點深度。 由於使用低檢查點深度並執行這些積極式預先讀取作業，被動資料庫複本的 IOPS 等於 Exchange 2010 中主動複製的 IOPS。

在 Exchange 2013 或更新版本中，系統可以在被動複製上使用高檢查點深度時提供快速容錯移轉 (100 MB) 。 因為被動副本擁有 100-MB 的檢查點深度，所以它們已經被反調整，不再如此積極。 由於增加檢查點深度並取消微調主動式預先讀取，被動複製的 IOPS 大約是主動複製 IOPS 的 50%。

較高的被動副本檢查點深度還會導致其他變更。 在 Exchange 2010 中執行容錯移轉時，當資料庫從被動副本轉換為主動副本，資料庫快取會被清除。 從 Exchange 2013 開始，已重寫 ESE 記錄，以便透過從被動轉換為主動來保存快取。 因為 ESE 不需要清除快取，而能快速容錯移轉。

另一項改變是針對背景資料庫維護 (BDM) 程序。 BDM 現在每秒可以針對每個副本處理大約 1-2 MB。

由於這些變更，Exchange 現在可大幅減少 Exchange 2010 上的 IOPS。

受管理的可用性

受控可用性是內建、主動監視和 Exchange 高可用性平臺的整合。 受管理的可用性可讓系統根據服務健全狀況，決定資料庫的容錯移轉時機。 受控可用性是部署在信箱伺服器上用戶端存取 (前端) 服務和後端服務的內部基礎結構。 受控可用性包含三個主要的非同步裝置，這些元件會持續執行工作：

  1. 第一個元件是探查引擎，負責在伺服器上進行測量並收集資料。 這些測量的結果會流入第二個元件，監視器。

  2. 監視器會根據所收集的資料，依據健全狀況列出系統使用的所有商務邏輯。 與模式識別引擎類似，監視器會尋找所有收集到的測量資料上的各種不同模式，接著判斷某個項目是否應視為健全。

  3. 最後，回應者引擎負責復原動作。

若某個元件狀況不良，第一個動作就是嘗試復原該元件。 這可能包括多階段復原動作;例如：

  1. 重新啟動應用程式集區。

  2. 重新開機服務。

  3. 重新啟動伺服器。

  4. 讓伺服器離線，使其不再接受流量。

若復原動作不成功，系統將透過事件記錄檔通知將問題呈報給使用者。

受管理的可用性以下列兩種服務形式實作：

  • Exchange Health Manager 服務 (MSExchangeHMHost.exe) ：這是用來管理背景工作進程的控制器進程。 用途視需要分為建立、執行以及啟動與停止工作者處理序。 也可用於復原工作者處理序，以於處理程序當機時避免工作者處理序成為單一失敗點。

  • Exchange Health Manager 背景工作進程 (MSExchangeHMWorker.exe) ：這是負責執行執行時間工作的背景工作進程。

Managed 可用性會使用永續性儲存體來執行其功能：

  • XML 設定檔案用於在工作者處理序的啟動期間初始化工作項目定義。

  • 登錄用於儲存執行階段資料，例如書籤。

  • Crimson Channel 事件記錄檔基礎結構用於儲存工作項目結果。

如需受控可用性的詳細資訊，請參閱 受控可用性。

受管理的儲存區

Exchange 2010 和舊版支援在信箱伺服器角色上執行資訊存放區進程 (Store.exe) 的單一實例。 這個單一 Store 實例會裝載伺服器上的所有資料庫：主動、被動、延遲和復原。 在這些 Exchange 架構中，信箱伺服器上裝載的不同資料庫之間幾乎沒有隔離。 單一信箱資料庫的問題可能會對所有其他資料庫造成負面影響，而信箱損毀所造成的損毀可能會影響該伺服器上裝載資料庫之所有使用者的服務。

單一 Store 實例的另一個挑戰是，可延伸儲存引擎 (ESE) 的處理器延展性不足。 ESE 可妥善調整為 8-12 個處理器核心，但除此之外，跨處理器通訊和快取同步處理問題會導致負效能。 假設現今的伺服器有 16 個以上的核心系統可用，這會造成管理 ESE 的 8-12 核心親和性，以及針對非市集程式使用其他核心的系統管理挑戰 (例如助理、搜尋基礎、受控可用性等) 。 此外，先前的架構會限制市集程式的相應增加。

隨著Exchange Server本身的演進，Store.exe程式在這幾年已大幅演進，但作為單一進程，其延展性最終會受到限制，且代表單一失敗點。 由於這些限制，Store.exe已在 Exchange 2013 中移除，並由受控存放區取代。

如需詳細資訊，請參閱 Managed Store。

每個磁碟區多個資料庫

雖然 Exchange 中的儲存體改進主要是針對 JBOD) 組態 (一堆磁片所設計，但所有支援的儲存體組態都可供使用。 其中一項功能是能夠在相同的磁碟區上主控多個資料庫。 此功能是有關針對大磁碟進行 Exchange 最佳化。 這些最佳化功能使得在容量、IOPS 和重新植入次數方面能更有效率地使用大型磁碟，其目的在於解決在 JBOD 儲存組態中執行相關的問題。

  • 資料庫大小必須可管理。

  • 重新植入操作必須快速且可靠。

  • 雖然儲存容量增加，但 IOPS 沒有增加。

  • 主控被動資料庫副本的磁碟在 IOPS 方面未得到充分利用。

  • 遲延的副本有非對稱儲存需求。

  • 從低磁碟空間狀態復原的靈活性受到限制。

儲存體容量增加的趨勢會持續。 例如，8 TB 磁片磁碟機上資料庫大小上限 (2 TB) 的 Exchange 最佳做法指導方針，表示您會浪費超過 5 TB 的磁碟空間。

解決方案是將資料庫放大，但這會抑制管理性，因為它可能會導致長時間重新隔離 (包括操作上無法管理的重新隔離時間) ，以及透過網路複製該資料量的可靠性受到危害。

此外，在 Exchange 2010 模式中，就 IOPS 而言，儲存被動副本的磁碟並未得到充分利用。 在被動副本遲延的情況下，不僅磁碟的 IOPS 未得到充分利用，而且相對於用來儲存主動和非遲延被動副本的磁碟，容量也不對稱。

Exchange 2013 和更新版本已優化，可更有效率地在 JBOD 設定中使用 (8 TB) 的大型磁片。 每個磁片都有多個資料庫，您現在可以擁有儲存多個資料庫複本的相同大小磁片，包括延遲的複本。 目標是促成使用者在已存在的不同磁碟區數目之間散佈，為您提供一個對稱設計，讓每一個 DAG 成員在正常操作期間，於相同的磁碟區上主控主動、被動和選擇性遲延副本。

以下範例說明了每個磁碟區使用多個資料庫的組態。

每個磁碟區使用多個資料庫設定

每個磁片區有多個資料庫。

圖表中的組態提供對稱式設計。 所有四部伺服器都有相同的四個資料庫，全部在每部伺服器的單一磁碟上主控。 關鍵在於您擁有的每一個資料庫的副本數目必須等於每一個磁碟上的資料庫副本數目。

在圖表的組態中，每個資料庫有四個複本：一個作用中複本、兩個被動複本，以及一個延遲的複本。 因為每一個資料庫有四個副本，所以適當的組態為每個磁碟區有四個副本。

此外，已設定了啟動喜好設定，每一個 DAG 和每一部伺服器之間可以取得平衡。 例如：

  • 使用中複本的啟用喜好設定值為 1。

  • 第一個被動複本的啟用喜好設定值為 2。

  • 第二個被動複本的啟用喜好設定值為 3。

  • 延遲的複本的啟用喜好設定值為 4。

除了在現有磁片區中擁有更好的使用者分佈之外，每個磁片使用多個資料庫的另一個優點是，還原資料保護所需的失敗時間，例如磁片失敗) (。

當資料庫越大，重新植入資料庫將耗時越久。 例如，2 TB 資料庫可能花 23 小時重新植入，而 8 TB 資料庫可能需要長達 93 小時 (幾乎 4 天)。 兩種植入每秒大約 20 MB。 這通常意味著超大型資料庫無法在合理的作業時間內植入。

至於每個磁碟一個單一資料庫副本的情況，植入作業的來源繫結更有效率，因為始終從單一來源植入磁碟。

透過將磁碟區分割成多個資料庫副本，以及讓指定磁碟區上被動資料庫的主動副本儲存在分離的 DAG 成員上，系統不再於重新植入磁碟的內容中進行來源繫結。 故障磁碟更換後，可從多個來源重新植入。 這讓系統可以在更短的時間內為這些資料庫重新植入並還原資料保護。

當您針對每個磁片區使用多個資料庫時，建議您遵循下列最佳做法和需求：

  • 每個實體磁碟必須使用單一邏輯磁碟分割。 請勿在磁碟上建立多個磁碟分割。 每個資料庫副本及其隨附的檔案 (例如，交易記錄和內容索引) 應在單一磁碟分割上的唯一目錄中進行管理。

  • 每個磁碟區設定的資料庫副本數目必須等於每個資料庫的副本數目。 例如，如果有四個資料庫副本，則每個磁碟區必須使用四個資料庫副本。

  • 資料庫複本應該有相同的芳鄰。 (例如，它們應該在每個伺服器上共用相同的磁片。)

  • DAG 間的啟動喜好設定應取得平衡，例如指定磁碟上的每個資料庫副本具有一個唯一的啟動喜好設定值。

AutoReseed

自動重新植入 (也稱為 AutoReseed) ，可取代通常由系統管理員驅動的動作，以回應磁片失敗、資料庫損毀事件或其他需要重新植入資料庫複本的問題。 AutoReseed 專為磁碟故障後，使用佈建在系統上的備用磁碟自動還原資料庫備援而設計。

如需詳細資訊，請參閱＜AutoReseed＞。 如需有關設定 AutoReseed 的詳細步驟，請參閱＜AutoReseed 的設定資料庫可用性群組＞。

從儲存故障中自動復原

從儲存體失敗自動復原可讓系統從影響復原或備援的失敗中復原。 除了 Exchange 2010 中導入的錯誤檢查行為之外，Exchange 現在還包含較長 I/O 時間的額外復原行為、Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 的過度記憶體耗用量，以及無法排程執行緒的嚴重案例。

即使是在 JBOD 環境下，儲存陣列控制器仍然可能發生當機或懸置等問題。 下表列出可提供無回應 I/O 偵測和復原功能的功能，以提供增強的復原能力。

名稱 支票 動作 臨界值
ESE 資料庫無回應 IO 偵測 ESE 會檢查未處理的 I/O 在深紅色通道中產生失敗專案以重新開機伺服器 240 秒
失敗專案通道活動訊號 確保失敗專案可以寫入至深紅色通道並從中讀取 複寫服務活動訊號深紅色通道，並在失敗時重新開機伺服器 30 秒
系統磁片活動訊號 驗證服務器的系統磁片狀態 定期將未緩衝的 I/O 傳送至系統磁片;在活動訊號逾時時重新開機伺服器 120 秒

Exchange 2013 和更新版本藉由包含其他嚴重狀況的行為，來增強伺服器和儲存體的恢復能力。 下表說明了這些情況和行為。

名稱 支票 動作 臨界值
系統不正確狀態 無法排程任何執行緒，包括非 Managed 執行緒 重新啟動伺服器 302 秒
長 I/O 時間 I/O 作業延遲測量 重新啟動伺服器 41 秒
複寫服務記憶體使用 測量MSExchangeRepl.exe的工作集 1：在具有服務終止要求的深紅色通道中記錄事件 4395
2：起始終止MSExchangeRepl.exe
3：如果服務終止失敗，請重新開機伺服器		 4 GB (GB)
系統事件 129 (匯流排重設) 在系統事件記錄檔中檢查事件 129 重新啟動伺服器 事件發生時
叢集資料庫停止回應 全域更新管理員更新遭到封鎖 重新啟動伺服器 事件發生時

延遲的副本增強功能

遲延副本增強功能包括與安全網整合，以及在某些情況下自動縮小記錄檔。 Security Net 是在 Exchange 2013 中引進，以取代稱為傳輸傾印機的 Exchange 2010 功能。 Safety Net 類似于傳輸傾印機，因為它是與信箱伺服器上的傳輸服務相關聯的傳遞佇列。 此佇列會儲存已成功傳遞至信箱伺服器之作用中信箱資料庫的郵件副本。 信箱伺服器上的每一個作用中信箱資料庫都有其自己的佇列，用於儲存已傳遞郵件的副本。 對於成功傳遞的郵件，您可以指定安全網儲存其副本的時間長度，經過這段時間後，副本將過期並自動加以刪除。

安全網將從 DAG 環境中的陰影備援承接一部分功能。 在 DAG 環境中，陰影備援等候已寄件郵件複寫到 DAG 中其他信箱伺服器的信箱資料庫被動副本時，不需要在陰影佇列中保留已寄件郵件的其他副本。 已寄件郵件的副本已經儲存於安全網，因此必要時可從安全網重新傳遞陰影備援。

使用 Safety Net 時，啟用延遲的資料庫複本會變得更容易。 例如，假設遲延副本的重新顯示遲延時間為 2 天。 在這種情況下，您可以設定 2 天的安全網。 如果您遇到需要使用延遲複本的情況，您可以：

  1. 暫停複寫。

  2. 複製兩次 (以保留資料庫的延遲本質，並建立額外的複本，以防您需要它) 。

  3. 取得複本並捨棄所有記錄檔，但必要範圍內的記錄檔除外。

  4. 掛接對安全網觸發自動要求的副本，以重新傳遞過去兩天的郵件。

使用安全網，您無需搜尋損毀位置。 您取得過去兩天的郵件，免除了遺失容錯移轉的經常性資料遺失情況。

延遲副本現在能在特定情況下呼叫自動記錄重新顯示來減少記錄檔數量以進行自我保護：

  • 達到低磁碟空間閾值時

  • 當延遲副本具有實體損毀，需要進行頁面修補時

  • 當超過 24 小時少於三個可用的正常副本 (僅限主動或被動，不計算延遲資料庫副本)。

在 Exchange 2010 中，頁面修補不能用於遲延副本。 在 Exchange 2013 或更新版本中，頁面修補可透過此自動播放功能，供延遲的複本使用。 若系統偵測到頁面修補需要遲延副本，記錄會自動重新顯示遲延副本以執行頁面修補。 遲延副本也將於達到磁碟空間過低閾值、或者偵測到該遲延副本為特定時間內唯一可用的副本時，啟用自動重新顯示功能。

遲延副本減少行為預設為停用，並可透過執行下列命令來予以啟用。

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

啟用之後，當副本少於三個時便會發生減少行為。 您可以修改下列 DWORD 登錄值來變更預設值 3。

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

若要啟用磁碟空間過低閾值的減少功能，您必須設定下列登錄項目。

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

設定上述任何登錄設定之後，重新啟動 Microsoft Exchange DAG 管理服務，讓變更生效。

例如，假設某個環境的指定資料庫有四個複本 (三個高可用性複本和一個延遲的複本) ，而預設設定則用於 ReplayLagManagerNumAvailableCopies。 如果非延遲副本因故而停止運作 (例如，因為暫停)，則延遲副本會在 24 小時內自動播放其記錄檔。

單一副本警示增強功能

確保您的伺服器可靠地運作，且信箱資料庫複本狀況良好，是每日 Exchange 傳訊作業的主要目標。 您必須主動監視硬體、Windows 作業系統和 Exchange 服務。

但在 Exchange 信箱復原環境中，請務必監視 DAG 和信箱資料庫複本的健康情況和狀態。 執行資料備援風險管理並監視複寫資料庫關機期間對單一副本特別重要。 在不使用獨立磁片備援陣列 (RAID) ，而是部署 JBOD 組態的環境中，這一點非常重要。 在 RAID 環境中，單一磁碟故障不會影響主動信箱資料庫副本。 但在 JBOD 環境中，單一磁碟故障會觸發資料庫容錯移轉。

CheckDatabaseRedundancy.ps1腳本是在 Exchange 2010 中引進的。 顧名思義，此指令碼可用來監視複寫信箱資料庫的備援 (藉由驗證目前至少已設定兩個正常的副本)，並在複寫資料庫只有單一的正常副本時，透過產生事件記錄檔來警示系統管理員。 在這種情況下，判斷備援時會將主動和被動同時列入計算。

單一副本情況包括但不僅限於：

  • 主動副本複寫至任何被動副本時失敗。

  • 所有被動副本失敗，其中包括正常狀態除外的 FailedAndSuspended 和 Failed 狀態，其副本落後於記錄複製或重新顯示。 如果延遲的複本在將記錄重新執行到延遲期間的 10 分鐘內，就不會被視為落後。

  • 系統無法準確知道主動副本目前的記錄檔產生作業。

因為了解何時下降到資料庫的單一正常副本是系統管理員的首要任務，已採用屬於受管理可用性之 DataProtection 健全設定的整合原生功能來取代 CheckDatabaseRedundancy.ps1 指令碼。

原生功能仍會透過事件記錄檔通知來警示系統管理員，而且為了區分 Exchange 2013 或更新版本的警示與 Exchange 2010，Exchange 現在會使用下列事件識別碼：

  • 事件 4138 (紅色警示)

  • 事件 4139 (綠色警示)

原生功能已增強，可減少當相同伺服器上的多個資料庫進入單一複製條件時所發生的警示雜訊。 在 Exchange 2010 中，單一副本警示會以每個資料庫層級來產生。 因此，影響多個資料庫和多個資料庫複本的全伺服器問題可能會導致警示暴失。 因為數個失敗是全伺服器的 (例如控制器或記憶體問題) ，所以每個伺服器事件都很有可能會發生警示 Storm。

警示現在會以每部伺服器為基礎產生。 當中斷影響整個伺服器，且資料備援對多個資料庫複本造成風險時，會產生單一每一伺服器警示。

DAG 網路自動設定

DAG 網路是用於複寫流量或 MAPI 流量的一或多個子網路的集合。 每個 DAG 皆包含最多一個 MAPI 網路和零個或更多的複寫網路。

在 Exchange 2010 中，初始 DAG 網路 (例如，DAGNetwork01 和 DAGNetwork02) 是由系統根據叢集服務所列舉的子網所建立。 例如，如果您有多個網路和指定網路 (的介面，則 MAPI 網路) 位於相同的子網上，則不需要進行其他設定。 不過，如果指定網路的介面位於多個子網上，您需要執行稱為折迭 DAG 網路的工作。

在 Exchange 2013 或更新版本中，不再需要折迭 DAG 網路。 Exchange 仍然使用相同的偵測機制來區分 MAPI 和複寫網路，但現在會視情況自動折迭 DAG 網路。

此外，依預設，系統現在會自動管理 DAG 網路。 若要使用 Exchange 系統管理中心 (EAC) 來檢視 DAG 網路屬性，您必須使用 EAC 修改 DAG 的屬性，或使用 Set-DatabaseAvailabilityGroup Cmdlet 將 ManualDagNetworkConfiguration 參數 $true 設定為 ，以進行手動網路控制。

變更最佳副本選擇

最佳副本選擇 (BCS) 是一種內部演算法程序，用於尋找要啟動的個別資料庫的最佳副本，提供用於啟動的可能副本清單及其健全狀況和狀態。 當現有主動資料庫副本失效或系統管理員執行無目標轉換時，Active Manager 會選取最佳可用 (且未封鎖) 副本作為新的主動資料庫副本。 在 Exchange 2010 中，BCS 處理程序已評估每個資料庫副本的各種面向，以判斷最適合啟用的副本。 其中包含：

  • 複製佇列長度

  • 重新顯示佇列長度

  • 資料庫的狀態

  • 內容索引狀態

在 Exchange 2013 或更新版本中，Active Manager 會執行相同的 BCS 檢查和階段來判斷複寫健康情況，但現在也包含使用健康狀態遞減順序的條件約束。 由於這些變更，BCS 現在稱為最佳副本和伺服器選擇 (BCSS)。

BCSS 包含數個新的健康情況檢查，這些檢查現在是 Exchange 中內建受控可用性監視元件的一部分。 Active Manager (會依) 執行的順序列出另外四項檢查：

  1. 全部狀況良好：檢查裝載受影響資料庫複本的伺服器，該資料庫的所有監視元件都處於狀況良好狀態。

  2. 最高標準狀況良好：檢查裝載受影響資料庫複本的伺服器，該資料庫的所有監視元件都具有狀況良好的正常優先順序。

  3. 全部優於來源：檢查裝載受影響資料庫複本的伺服器，其監視元件的狀態優於裝載受影響複本的目前伺服器。

  4. 與來源相同：檢查裝載受影響資料庫複本的伺服器，該資料庫的監視元件狀態與裝載受影響複本的目前伺服器相同。

如果 BCSS 是因受管理的可用性監控元件觸發容錯移轉而被叫用 (例如，透過容錯移轉回應程式)，則會實施另一個強制條件約束，也就是目標伺服器的元件健全狀況必須優於發生容錯移轉的伺服器。 例如，如果先前稱為 Outlook Web App) 的Outlook 網頁版 (失敗會透過容錯移轉回應程式觸發受控可用性容錯移轉，BCSS 必須選取裝載受影響資料庫複本的伺服器，Outlook 網頁版狀況良好。

DAG 管理服務

Exchange 2013 CU2 或更新版本包含 Microsoft Exchange DAG 管理服務 (MSExchangeDAGMgmt) 。 此服務包含先前在 Microsoft Exchange 複寫服務內的內部 DAG 監視功能， (MSExchangeRepl) 。

沒有叢集管理存取點的 DAG

在執行 Windows Server 2008 R2 或 Windows Server 2012 的 Exchange 伺服器上，所有 DAG 在 MAPI 網路中包含的每個子網上都需要至少一個 IP 位址。 具有叢集管理存取點 (也稱為叢集網路名稱) 的 DAG 叢集會使用指派給 DAG 的 IP 位址，以使用叢集名稱來啟用叢集的名稱解析和連線 (或更精確地說，是與目前擁有叢集核心資源群組之叢集成員的連線)。

Windows Server 2012 R2 或更新版本可讓您在沒有系統管理存取點的情況下建立容錯移轉叢集。 沒有管理存取點的 Windows 容錯移轉叢集具有下列特性：

  • 未將 IP 位址指派給叢集，因此叢集核心資源群組中沒有 IP 位址資源。

  • 未將網路名稱指派給叢集，因此叢集核心資源群組中沒有網路名稱資源。

  • 叢集名稱未在 DNS 中註冊，且無法在網路上解析叢集名稱。

  • 不會在 Active Directory 中建立 (CNO) 的叢集名稱物件。

  • 您無法使用容錯移轉叢集管理工具來管理 Windows 容錯移轉叢集。 相反地，您必須使用 Windows PowerShell，而且您需要針對個別叢集成員執行 PowerShell Cmdlet。

在 Exchange 上執行的 Exchange 2013 SP1 或更新版本Windows Server 2012 R2 或更新版本可讓您建立 DAG，而不需要叢集系統管理存取點。 如需詳細資訊，請 參閱建立 DAG 和 建立資料庫可用性群組。