變更至與舊版不同的高可用性與站台回復性

適用於：Exchange Server 2013 SP1

Exchange 2013 使用 DAG 和信箱資料庫副本，以及單一項目搜索、保留原則和遲延資料庫副本等其他功能，來提供可用性、站台恢復及 Exchange 原生資料保護。 已增強高可用性平臺、Exchange 資訊存放區和可延伸儲存引擎 (ESE) ，以提供更高的可用性和更輕鬆的管理，並降低成本。 這些增強功能包括：

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

• 受管理的可用性：有了受管理的可用性，內部監視和以復原為導向的功能可緊密整合，協助防止故障、主動復原服務，並自動初始化伺服器的容錯移轉或警告系統管理員採取行動。 將重點放在監控與管理使用者體驗，而非僅著重於伺服器與元件存留時間，才可協助確保服務持續可用。

• 受控存放區：受控存放區是 Exchange 2013 中新重寫資訊存放區進程的名稱。 全新的 Managed Store 使用 C# 編寫，且與 Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 緊密整合，以透過更強大的備援提供更高可用性。

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

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

• 從記憶體失敗自動復原：這項功能會繼續Exchange 2010中引進的創新功能，讓系統能夠從影響復原或備援的失敗中復原。 除了 Exchange 2010 Bug 檢查行為之外，Exchange 2013 還包含較長 I/O 時間的額外復原行為、MSExchangeRepl.exe 的過度記憶體耗用量，以及系統處於無法排程線程的不良狀態的嚴重狀況。

• 延遲的複製增強功能：延遲的複本現在可以使用自動記錄播放，在一定程度上自行小心。 延遲的復本會在各種情況下自動播放記錄檔，例如頁面修補和磁碟空間不足的案例。 若系統偵測到頁面修補需要遲延副本，記錄會自動重新顯示遲延副本以執行頁面修補。 延遲的復本也會在達到低磁碟空間閾值時，以及在偵測到延遲的複本為特定期間內唯一可用的複本時，叫用此自動重新執行功能。 此外，延遲的復本可以使用 Safety Net，讓復原或啟用更容易。

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

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

減少 Exchange 2010 的 IOPS

在 Exchange 2010 中，被動資料庫複本具有低檢查點深度，這是快速故障轉移的必要專案。 此外，被動副本會執行積極性預先讀取資料作業，以保持 5 MB 的檢查點深度。 由於使用低檢查點深度並執行這些積極性預先讀取作業，被動資料庫複本的 IOPS 等於 Exchange 2010 中主動複製的 IOPS。

在 Exchange 2013 中，系統可提供快速容錯移轉，同時在被動副本上使用高檢查點深度 (100 MB)。 由於被動復本具有 100 MB 的檢查點深度，因此會將其取消調整為不再如此積極。 因為增加檢查點深度並反調整積極性預先讀取，所以在 Exchange 2013 中，被動副本的 IOPS 大約是主動副本 IOPS 的 50%。

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

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

由於這些變更，Exchange 2013 的 IOPS 比 Exchange 2010 明顯減少許多。

受管理的可用性

受管理的可用性整合內建、主動監視和 Exchange 2013 高可用性平台。 受管理的可用性可讓系統根據服務健全狀況，決定資料庫的容錯移轉時機。 受管理的可用性是一種內部基礎結構，部署在 Exchange 2013 的 Client Access 和 Mailbox server role 上。 受管理的可用性包括持續工作的三個主要非同步元件。 第一個元件是探查引擎，負責在伺服器上測量以及收集資料。 這些測量的結果會流入第二個元件，監視器。 監視器會根據所收集的資料，依據健全狀況列出系統使用的所有商務邏輯。 與模式識別引擎類似，監視器會尋找所有收集到的測量資料上的各種不同模式，接著判斷某個項目是否應視為健全。 最後，還有負責復原動作的回應者引擎。 若某個元件狀況不良，第一個動作就是嘗試復原該元件。 這可能包括多階段復原動作；例如，首次嘗試可能是重新啟動應用程式集區，第二次可能是重新啟動服務，第三次嘗試可能是重新啟動伺服器，而下一步嘗試可能是使該伺服器離線，讓其不再接受流量。 若復原動作不成功，系統將透過事件記錄檔通知將問題呈報給使用者。

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

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

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

受管理的可用性使用持續性儲存空間以執行其功能：

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

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

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

如需受管理可用性的相關資訊，請參閱受管理的可用性。

受管理的儲存區

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

舊版 Exchange 中單一 Store 實例的另一項挑戰是，可延伸儲存引擎 (ESE) 可調整為 8-12 個處理器核心，但除此之外，跨處理器通訊和快取同步處理問題會導致負規模。 假設現今的伺服器有16個以上的核心系統可用，這會造成管理ESE 8-12核心的同構型，以及使用其他核心進行非市集程式的管理挑戰 (例如Assistants、Search Foundation、Managed Availability 等 ) 。 此外，先前的架構會限制市集程序的相應增加。

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

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

每個磁碟區多個資料庫

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

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

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

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

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

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

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

增加儲存容量的趨勢仍持續存在，預計 8 TB 磁碟機即將可以使用。 搭配 Exchange 資料庫大小上限最佳做法指導方針(2 TB) 使用 8 TB 磁碟機，浪費的磁碟空間超過 5 TB。 其中一個解決方案是將資料庫放大，但這會禁止管理性，因為它會造成長時間重新隔離的時間，包括在某些情況下，操作上無法管理的重新隔離時間，以及透過網路複製該數據量的可靠性會受到危害。

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

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

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

上述組態提供對稱性設計。 所有四部伺服器都有相同的四個資料庫，全部在每部伺服器的單一磁碟上主控。 關鍵在於您擁有的每一個資料庫的副本數目必須等於每一個磁碟上的資料庫副本數目。 在上述的範例中，每個資料庫有四個副本：一個主動副本、兩個被動副本和一個延遲的副本。 因為每一個資料庫有四個副本，所以適當的組態為每個磁碟區有四個副本。 此外，已設定了啟動喜好設定，每一個 DAG 和每一部伺服器之間可以取得平衡。 例如，主動複製的啟用喜好設定值為 1、第一個被動複製的啟用喜好設定值為 2、第二個被動複製的啟用喜好設定值為 3，而延遲的複本的啟用喜好設定值為 4。

除了在現有的磁碟區間能具有較好的使用者分配情形外，每部磁碟機使用多個資料庫的另一項好處在於，如果出現需要重新植入的故障 (例如，磁碟故障)，能減少恢復資料保護的時間量。

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

至於每個磁碟一個單一資料庫副本的情況，植入作業的來源繫結更有效率，因為始終從單一來源植入磁碟。 藉由將磁碟區分割成多個資料庫複本，並將被動資料庫的主動復本儲存在個別 DAG 成員上的指定磁碟區上。 系統已不再是重新系結磁碟內容中的來源。 故障磁碟更換後，可從多個來源重新植入。 這可讓系統在較短的時間內重新儲存和還原這些資料庫的數據保護。

當每個磁碟區使用多個資料庫時，建議您依照下列最佳作法和需求：

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

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

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

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

AutoReseed

自動重新植入或 AutoReseed 功能取代通常是回應磁碟故障、資料庫損毀事件或資料庫副本必須重新植入等其他問題的管理員驅動動作。 AutoReseed 專為磁碟故障後，使用佈建在系統上的備用磁碟自動還原資料庫備援而設計。

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

從儲存故障中自動復原

自動從儲存故障復原可持續展現 Exchange 2010 中的創新技術，允許系統復原影響恢復或備援的故障。 除了 Exchange 2010 Bug 檢查行為之外，Exchange 2013 還包含長時間 I/O 的額外復原行為、Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 的過度記憶體耗用量，以及無法排程線程的嚴重案例。

即使是在 JBOD 環境下，儲存陣列控制器仍然可能發生當機或懸置等問題。 Exchange 2010 包含懸置 I/O 偵測和提供增強恢復的復原功能。 下表列出這些功能。

Exchange 2013 藉由納入其他嚴重情況的新行為，來增強伺服器和儲存的回復性。 下表說明了這些情況和行為。

延遲的副本增強功能

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

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

隨著 Safety Net 的推出，啟用延遲的資料庫複本會變得更容易。 例如，假設遲延副本的重新顯示遲延時間為 2 天。 在這種情況下，您可以設定 2 天的安全網。 如果您必須使用遲延副本，可以擱置對其複寫，並將它複製兩次 (以保留資料庫的遲延性質，以及視需要建立額外副本)。 然後加以複製並捨棄所有記錄檔，但要求範圍內者除外。 掛接對安全網觸發自動要求的副本，以重新傳遞過去兩天的郵件。 使用安全網，您無需搜尋損毀位置。 您取得過去兩天的郵件，免除了遺失容錯移轉的經常性資料遺失情況。

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

• 達到低磁碟空間閾值時

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

• 當可用的狀況良好復本少於三個時， (僅限主動或被動;延遲的資料庫復本不會計算) 超過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 管理服務，讓變更生效。

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

單一副本警示增強功能

確定您的伺服器確實操作，且信箱資料庫副本正常，是每天 Exchange 2013 訊息作業的主要目標。 您必須主動監視硬體、Windows 作業系統和 Exchange 服務。 但是在 Exchange 2013 信箱恢復環境下執行時，監視健康狀況和 DAG 狀態及信箱資料庫副本相當重要。 執行資料備援風險管理並監視複寫資料庫關機期間對單一副本特別重要。 在不使用獨立磁碟備援陣列 (RAID) ，而是部署 JBOD 組態的環境中，這一點非常重要。 在 RAID 環境中，單一磁碟故障不會影響主動信箱資料庫副本。 不過，在 JBOD 環境中，單一磁碟失敗會觸發資料庫故障轉移。

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

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

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

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

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

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

原生功能仍會透過事件記錄檔通知來警示系統管理員，為了區分 Exchange 2013 警示與 Exchange 2010，Exchange 2013 使用下列事件標識符：

• 事件 4138 (紅色警示)

• 事件 4139 (綠色警示)

在 Exchange 2013 中，已增強原生功能來降低警示雜訊的等級，這在相同伺服器上的多個資料庫進入單一副本情況時便會發生。 在 Exchange 2010 中，單一副本警示會以每個資料庫層級來產生。 因此，當有影響多個資料庫和多個資料庫副本的全伺服器問題時，便可能出現警示風暴。 因為像控制器或記憶體問題等許多失敗都是全伺服器，所以每一個伺服器事件發生這種警示風暴的機率頗高。 在 Exchange 2013 中，現在是以每部伺服器為基礎產生警示。 如果中斷影響整部伺服器且多個資料庫副本的資料備援處於風險中，現在每部伺服器會產生單一警示。

DAG 網路自動設定

DAG 網路是用於複寫流量或 MAPI 流量的一或多個子網路的集合。 每個 DAG 皆包含最多一個 MAPI 網路和零個或更多的複寫網路。 在 Exchange 2010 中，系統所建立的初始 DAG 網路 (例如，DAGNetwork01 和 DAGNetwork02) 是以由叢集服務列舉之子網路為基礎。 如果使用多個網路並且指定網路 (例如 MAPI 網路) 的介面是在相同子網路的環境中，系統管理員必須執行一些額外的設定。 不過，如果指定網路的介面是在多個子網路的環境中，系統管理員必須執行收合 DAG 網路工作。

在 Exchange 2013 中，不再需要收合 DAG 網路。 Exchange 2013 仍然使用相同的偵測機制來區別 MAPI 和複寫網路，但現在會視需要而自動收合 DAG 網路。

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

變更最佳副本選擇

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

• 複製佇列長度

• 重新顯示佇列長度

• 資料庫的狀態

• 內容索引狀態

在 Exchange 2013 中，Active Manager 會執行相同的 BCS 檢查和階段，以判定複寫健全狀況，但現在還包括使用健全狀況狀態的降序條件約束。 由於這些變更，BCS 現在稱為最佳副本和伺服器選擇 (BCSS)。

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

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

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

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

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

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

DAG 管理服務

Exchange 2013 量產發行 (RTM) 版本的累計更新 2 (CU2) 在身為 DAG 成員的信箱伺服器上包含一項新服務。 這項服務稱為 Microsoft Exchange DAG 管理服務 (MSExchangeDAGMgmt)。 這項新服務包含先前在 Microsoft Exchange 複寫服務 (MSExchangeRepl) 內執行的內部 DAG 監控功能。

沒有叢集管理存取點的 DAG

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

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

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

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

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

• 無法使用故障轉移叢集管理工具來管理 Windows 故障轉移叢集。 它必須使用 Windows PowerShell 進行管理，而且必須對個別叢集成員執行 PowerShell Cmdlet。

在 Windows Server 2012 R2 或更新版本上執行時，Exchange 2013 Service Pack 1 (SP1) 和更新版本可讓您建立沒有叢集管理存取點的 DAG。 您可以使用 Exchange 系統管理中心或使用 Shell，在沒有系統管理存取點的情況下建立 DAG。 如需詳細資訊，請 參閱建立DAG 和 建立資料庫可用性群組。