排定與未排定的中斷
適用版本： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
上次修改主題的時間： 2007-10-29
排定與未排定的中斷，是叢集連續複寫 (CCR) 環境的兩種中斷形式。排定的中斷由系統管理員初始化，以修復故障或執行維護作業。未排定的中斷則指導致服務、資料或兩者皆無法使用的未預期事件。CCR 是專為處理排定與未排定的中斷所設計。
排定的中斷
CCR 可讓您排程特定節點的延伸系統中斷，而不需要叢集信箱伺服器 (CMS) 的延伸的中斷時間。CCR 的排定中斷功能設計，旨在確定主動節點上的所有記錄資料都已順利複製至被動節點。因此，排定的中斷一定不會遺失資料，即使非同步的複寫也一樣。失敗和產生的容錯移轉，會導致被動節點在連線時無法使用最近的記錄資料。
在 CCR 環境中，一次只能有一個節點離線。將一個以上的節點離線會造成服務中斷。在任何特定時間，含有多數節點集 (MNS) 仲裁 (具有檔案共用見證) 之檔案共用的電腦，或是容錯移轉叢集中的被動節點，皆可能因為軟硬體維護、更新及修復而離線。建議您在讓節點離線前一定先檢查其是否仍在使用中或正在主控資源。您可以使用叢集系統管理員來判斷它是否正在主控任何資源。您可以在 Exchange 管理命令介面中執行 Get-ClusteredMailboxServerStatus 指令程式，以檢查節點狀態。如需檢視 CMS 狀態的相關資訊，請參閱如何檢視叢集信箱伺服器的狀態。
.gif "note") 附註： |
|---|
| CCR 排程的中斷支援並未與 Windows Server 關機程序整合。您必須先將 CMS 移動至不同的節點，才能關閉主動節點。如需解釋如何將 CMS 從某個節點移至另一個節點的詳細步驟，請參閱如何在 CCR 環境中移動叢集信箱伺服器。 |
系統管理工作
排定的中斷由系統管理員初始化，以修復故障或執行維護作業。排定的中斷可讓系統將 CMS 從主動節點移至被動節點 (而使被動節點成為新的主動節點)，並裝載已複寫的資料庫與儲存群組。裝載之後，資料庫即成為日後所有複寫之全部後續更新的來源。兩份副本切換複寫的角色：產生資料庫變更的副本以及接收並套用資料庫變更的副本。
因為 CCR 使用非同步複寫，主動 CMS 由叢集中某個節點轉換到另一個節點，需要協調叢集與複寫支援。CCR 會執行此協調作業。系統管理員可以使用 Exchange 管理命令介面中的 Move-ClusteredMailboxServer 指令程式，來初始化排定的中斷。
| 附註： |
|---|
| 執行此作業會導致服務短暫中斷。此外，CMS 上所有儲存群組的所有備份也會停止。 |
Move-ClusteredMailboxServer 指令程式會驗證被動節點是否擁有有效且狀況良好的副本。此外，它還會檢查以確定此副本保持最新狀態。副本若不夠新，中斷可能會在複寫完成時延伸。這些檢查若順利完成，就會初始化轉換。移動時若無故障，當 CMS 於選取的節點上執行且所有資料庫都已裝載後，工作即告完成。處理時發生的故障會阻止轉換，或影響所有資料庫是否可以自動裝載。若發生此種狀況，即由未排定的中斷行為接管。
在某些情況下，排定的中斷是用以修復部分故障的伺服器。資料庫或記錄檔損毀的伺服器即是一例。在此狀況下，透過複寫系統傳送記錄的邏輯，會封鎖 Move-ClusteredMailboxServer 指令程式。系統管理員有簡易選項可管理此情況。系統管理員可以卸載有問題的資料庫，並發出具有選項的 Move-ClusteredMailboxServer 命令，這個命令會試複製與卸載資料庫關聯的記錄，但是如果全部記錄皆無法複製，也不會停止移動作業。結果是，即使是損毀儲存群組的復原，也可輕易地使用 Move-ClusteredMailboxServer 指令程式來完成。
Move-ClusteredMailboxServer 指令程式允許系統管理員記錄初始化此移動作業的原因。此原因會儲存在事件記錄中。此命令也會強制系統管理員指定用於主控 CMS 的節點。這會防止系統管理員在 CMS 受到正確控制時，誤移此物件。
Cluster.exe 命令列管理介面及叢集系統管理員圖形化使用者介面 (GUI) 皆有能力移動 CMS。使用這些方法將會觸發複寫的清除邏輯。但建議您不要使用上述方法的真正原因是：
- 這些方法不會驗證被動副本的健康狀況或狀態。因此，當節點執行必要作業使資料庫成為可裝載時，使用這些方法會導致延伸的中斷時間。
- 因為複寫不連續，這些方法可能也會讓資料庫無限期離線。
排程中斷後還原複寫活動
在主動節點排程中斷之後要還原 CCR 環境的處理程序，就是重新啟動節點。系統啟動時就會自動啟動複寫。有兩個需考量的情形：
- 排定的中斷完全順利，執行與排定中斷關聯的轉換時未顯示任何故障，而且所有資料庫都自動上線。在此情形下，系統管理員藉由確定這兩個節點的儲存群組與資料庫皆一致，以執行排定的中斷。結果就是節點可上線並可立即繼續複寫。藉由重新顯示記錄，副本會保持在最新狀態。不需要進行任何特殊動作。
- 排程中斷只有部分成功，或在排程中斷前某些資料庫已損毀。在此情形中，排程中斷無法確定在掛載資料庫前，目標是否可使用來源上的所有記錄。一般來說，發生此狀況的原因是在排程中斷前或排程中斷作業中發生失敗。因此，來源與目標資料庫並不一致。在某些狀況下，CCR 會自動復原部分不一致的情形。若出現這種狀況，就會啟動複寫並處理所有可用的記錄。若複寫無法自動復原，就會將此副本標記為損毀，並產生指出此問題的事件。假設儲存為可用，則主要的復原動作就是重新植入副本。如需更正上述問題程序的相關資訊，請參閱如何植入叢集連續複寫副本。
未排定的中斷
未排定的中斷發生於系統自動回應某類故障時。CCR 會將重點在一些故障問題上，因為這一類問題有許多可以改進的地方，且多數環境都需要自動復原。
未排定的中斷允許系統啟動被動節點上的 Mailbox server，從而使其成為主動節點，並裝載重複的資料庫及儲存群組。裝載之後，資料庫即成為日後所有複寫之全部後續更新的來源。兩份副本切換複寫的角色：產生資料庫變更的副本以及接收並套用資料庫變更的副本。
因為 CCR 會使用非同步的複寫，所以未排定的中斷表示會遺失部分資料。至少，復原活動就無法使用作用中之伺服器主動寫入的記錄。CCR 處理此問題的方法是，提供容錯移轉行為的系統管理控制，以及提供功能以協助索回可能受影響的大量資料。
發生容錯移轉時，CCR 一定會啟動剩餘被動節點上的 Mailbox server。系統控制與新的主動節點是否裝載有資料庫關聯。CCR 會提供系統管理控制以指定是否要裝載資料庫。預設位置為 Best availability。在此位置，系統會自動裝載與之前作用中工作資料庫同步的所有資料庫。Best availability 允許兩份副本在不一致上有較大的差異。Good availability 會使資料庫上線，若在這段期間內產生新記錄，則會複寫最後產生的記錄。Lossless 保證副本不會上線，除非確認資料完全不會遺失。若使用 Lossless，則只有當原始伺服器再次正常運作且所有記錄資料完好可用時，才會發生自動復原的情況。
| 附註： |
|---|
| 使用 Lossless 設定會導致延伸的中斷時間。系統管理員可以使用 Lossless 設定，然後對是否要裝載資料庫作出明確的決定。Lossless 設定很容易就會導致故障的延伸的中斷時間。 |
如果一或多個資料庫處於不自動裝載資料庫的設定條件下，系統管理員仍然可以明確決定以可用的內容裝載其副本。系統管理員必須檢查副本的狀態，然後發出兩個命令。第一個命令是通知複寫引擎，指出此副本應成為複寫來源 (變更來源)，也就是可裝載的副本。第二個命令是裝載資料庫。
如需 CCR 啟用時修復損毀或故障的其他資訊，請參閱管理叢集連續複寫。
系統管理控制
如果發生未排定的中斷，系統管理控制可控制此行為。CCR 為信箱伺服器提供了可用以控制未排定之中斷復原行為的屬性。AutoDatabaseMountDial 屬性有三個可能值：Lossless、Good availability 及 Best availability。
Lossless Lossless 表示未遺失任何記錄。當屬性設定為 Lossless 時，在大部分的情況下，系統都會等到故障的節點回到線上，才裝載資料庫。即使這種時候，故障的系統也必須傳回所有可存取且未損毀的記錄。故障之後，被動節點會成為主動節點，而Microsoft Exchange 資訊儲存庫服務會回到線上。它會檢查資料庫是否可予裝載，而不會遺失任何資料。如果可以，就會裝載資料庫。如果不可以，則系統會定期嘗試複製記錄。如果伺服器傳回完好無缺的記錄，即表示此嘗試最後一定會成功，而且也會裝載資料庫。如果伺服器沒有傳回完好無缺的記錄，即表示無法取得剩餘的記錄，也不會裝載受影響的資料庫。
附註：故障結束後，系統管理員隨時可以仲裁，並決定使用之前仍為被動節點時可使用的資料庫及記錄裝載。兩個步驟的簡單程序即可完成此工作。系統管理員通常會分析原始伺服器恢復運作所需時間，據此決定進行仲裁。故障時兩節點之間的複寫一致性，以及用戶端取得伺服器連線急迫性，也是此分析的部分因素。 Good availability Good availability 是遺失三個記錄檔。當複寫運作正常且以記錄產生的速率複製記錄時，Good availability 可提供完整的自動復原。
Best availability Best availability 是遺失六個記錄檔，此為預設設定。Best availability 的運作與 Good availability 相似，但複寫略有延遲時仍允許自動復原。因此，發生容錯移轉後，新主動節點的狀態可能略微落後舊主動節點，因而增加發生資料庫分歧的可能，而資料庫分歧需要進行完整重新植入才能更正。
如需中斷管理行為的相關資訊，請參閱如何調整叢集連續複寫的容錯移轉和裝載設定。
若要確保您目前閱讀的是最新資訊，並尋找其他的 Exchange Server 2007 說明文件，請造訪 Exchange Server 技術資源中心.