共用方式為

叢集連續複寫

  • 發行項

 

適用版本： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上次修改主題的時間： 2008-03-21

叢集連續複寫 (CCR) 是 Microsoft Exchange Server 2007 的高可用性功能，結合了 Exchange 2007 內建的非同步記錄傳送與重新顯示技術以及叢集服務所提供的容錯移轉與管理功能。

CCR 的設計用意在於提供 Exchange 2007 Mailbox Server 的高可用性，方法是提供可符合下列需求的解決方案：

  • 沒有單一失敗點。
  • 沒有特殊的硬體需求。
  • 沒有共用儲存需求。
  • 可部署於一個或兩個資料中心組態。
  • 可降低完整備份頻率、降低備份資料總量及縮短自第一次失敗所需復原時間的服務等級協定 (SLA)。

CCR 使用 Exchange 2007 的資料庫失敗復原功能，可以資料庫主動副本所發生之變更對資料庫的第二個副本進行連續和非同步更新。CCR 環境中的被動節點安裝期間，會將每個儲存群組及其資料庫從主動節點複製到被動節點。此作業稱為「植入」，它提供資料庫複寫的基準。執行初始植入後，就會連續執行記錄複製與重新顯示。

在 CCR 環境中，複寫能力會與叢集服務整合，以提供高可用性解決方案。除了提供資料與服務可用性之外，CCR 也可為排定的中斷做好準備。必須安裝更新或執行維護時，系統管理員可將「叢集信箱伺服器」(舊版 Exchange Server 中稱為 Exchange 虛擬伺服器) 手動移至被動節點。移動作業完成後，系統管理員可接著執行需要的維護。

移動作業的執行方式是在 Exchange 管理命令介面中使用 Move-ClusteredMailboxServer 指令程式。Microsoft Exchange Server 2007 Service Pack 1 (SP1) 在 Exchange 管理主控台中也包括一個新的「管理叢集信箱伺服器精靈」，您可以利用它來移動叢集信箱伺服器。這些工作使用的邏輯會執行必要的強制動作，以確保信箱資料不會在移動過程中遺失。這些工作也會在移動前執行檢查，以確定被動節點上的複寫已準備就緒可迅速啟動。

CCR 的主要論據如下：

  • 連續複寫是非同步的   關閉記錄且 Mailbox Server 不再使用記錄時，才會複製記錄。這代表被動節點通常不會擁有主動節點上每一個記錄檔的副本。一個例外是當系統管理員對主動節點啟動排定的中斷以套用更新或執行一些其他維護時。
  • 正常作業期間，連續複寫幾乎不會對主動節點造成 CPU 與輸入/輸出 (I/O) 負載   CCR 使用被動節點複製及重新顯示記錄。被動節點會透過安全的檔案共用存取記錄。
  • 叢集存留期間內，會自動指定主動與被動節點的變更   例如，在容錯移轉後，主動與被動的指定會反轉過來。這代表複寫的方向會逆轉。不需要進行管理動作即可逆轉複寫。系統會自動管理複寫逆轉。
  • 容錯移轉及排定的中斷在功能與效能上是對稱的   例如，從 Node1 容錯移轉至 Node2 與從 Node2 容錯移轉至 Node1 所花的時間相同。容錯移轉所花的時間通常不到兩分鐘。在較大型的伺服器上，排定的中斷所花的時間通常不到四分鐘。容錯移轉與排定的中斷間的時間差，與進行排定的中斷時執行主動節點的控制性關機所花的時間有關。未來的 Service Pack 可能會降低此效能差異。
  • 支援被動節點上的磁碟區陰影複製服務 (VSS) 備份   這可讓系統管理員從主動節點卸載備份並延伸備份視窗。此外，效能需求不會要求較大的組態必須具有硬體 VSS 支援才得以使用 VSS 備份。被動節點上的工作量主要是記錄複製與記錄重新顯示，兩者都不像主動節點上的叢集信箱伺服器一樣會受到即時的限制。例如，主動節點必須適時回應用戶端要求。被動節點沒有即時回應限制，資料庫及信箱大小可較大，因此可使用較長的備份視窗。
  • 降低備份媒體上的資料總量   CCR 被動副本提供損毀與資料遺失的第一道防線。因此，要發生雙重失敗才需要進行備份。從第一次失敗復原的 SLA 相當短，因為不需要還原。從第二次失敗復原的 SLA 較長。因此，可配合每日增量備份策略執行每週完整備份。這可減少必須放在備份媒體上的資料總量。
  • CCR 可以與待命連續複寫 (SCR) 結合   CCR 可以與 SCR 結合，以在主要資料中心 (使用 CCR 以取得高可用性) 以本機方式，以及在次要或備份資料中心 (使用 SCR 以取得站台回復性) 以遠端方式來複寫儲存群組。次要資料中心可在裝載 SCR 目標的容錯移轉叢集中包含一個被動節點。此類型的叢集稱為待命叢集，因為待命叢集不包含任何叢集信箱伺服器，但是在復原情況下可以快速提供替代叢集信箱伺服器給待命叢集。如果主要資料中心故障或遺失，則裝載在此待命叢集中的 SCR 目標可以快速地在待命叢集上啟動。

CCR 核心結構

CCR 會結合下列元素：

  • Microsoft 容錯移轉叢集所提供的容錯移轉及虛擬功能
  • 多數型容錯移轉叢集仲裁模型，使用檔案共用作為叢集活動的見證
  • Exchange 2007 中的交易記錄複寫及重新顯示功能
  • Hub Transport Server 的訊息佇列功能 (稱為傳輸暫放)

Windows 容錯移轉叢集

如下圖所示，在 Exchange 2007 SP1 中，CCR 會使用加入單一容錯移轉叢集 (執行 Windows Server 2003 Service Pack 2 或 Windows Server 2008) 的兩部電腦 (稱為「節點」)。容錯移轉叢集中的節點會主控單一叢集信箱伺服器。目前執行叢集信箱伺服器的節點稱為「主動」節點，而未執行叢集信箱伺服器 (但仍是叢集一部分) 且是連續複寫之目標的節點則稱為「被動」節點。因為進行排定的維護及未排定的中斷，所以在容錯移轉叢集的整個存留時間，會多次變更節點的主動或被動指定。

叢集連續複寫架構

容錯移轉叢集是使用叢集服務及特定類型的叢集仲裁模型所建立的：

檔案共用見證

前面的兩種仲裁模型都使用第三部電腦上的檔案共用作為見證。在這些仲裁模型中，會使用第三部電腦上的檔案共用，來避免叢集內出現「網路磁碟分割」(也稱為「分割腦症候群」)。當指定進行內部叢集通訊的所有網路都失敗時，會發生分割腦症候群，節點彼此間將無法收到活動訊號。藉由一律要求這兩個節點中的大多數節點及檔案共用都可以使用，且可與要操作的叢集信箱伺服器互動，來防止核心分裂的狀況。當大部分電腦正在進行通訊時，表示叢集具有「仲裁」。檔案共用見證的檔案共用可以在任何執行 Windows Server 的電腦上控管。主控檔案共用之 Windows Server 作業系統的版本，並不需要符合 CCR 環境的作業系統。不過，建議您使用包含叢集信箱伺服器之 Active Directory 目錄服務站台中的 Hub Transport Server 來主控檔案共用，因為這可讓郵件系統管理員維護檔案共用的控制權。

note附註：
檔案共用見證所使用的檔案共用不可以主控於分散式檔案系統 (DFS) 環境中。

檔案共用見證會使用叢集外部之電腦上的檔案共用，來作為形成叢集之兩個節點活動的見證。見證是由兩個節點使用，來追蹤叢集是由哪個節點支配。只有在兩個節點無法互相通訊時，才需要記事板。請考慮有一台由 Node1 及 Node2 組成的雙節點叢集信箱伺服器。在這種情況下，Node1 是能夠支配記事板的節點，因此也能支配叢集並顯示叢集信箱伺服器。如果 Node2 可以運作但無法與 Node1 通訊，Node2 就會嘗試支配記事板，但會失敗。Node2 無法控制記事板，表示它不應該顯示叢集信箱伺服器。

如果兩個節點能夠彼此互動，就不需要記事板且可將之離線。不過，如果無法使用檔案共用見證，則當任一節點稍後失敗時，叢集信箱伺服器就無法連線。

檔案共用只會維持先前描述的狀態。因此，所有的叢集組態資訊會在這兩個節點之間交換。您必須了解的是，這表示當 Node1 可以使用而 Node2 無法使用時，除非 Node2 能與 Node1 通訊，否則就無法使用 Node2 (即使它能夠與檔案共用見證進行通訊也一樣)。

檔案共用見證支援可提供檔案共用見證的定期存取檢查。如果存取檢查失敗，就會產生事件。監視系統會偵測、收集並回報事件。這可讓操作人員在發生第二次同時失敗而導致中斷之前，先修正問題。

在下列情況下，會存取檔案共用：

  • 在叢集節點上線，但只有一個叢集節點可用時。
  • 發生網路連線問題而使先前可存取的節點無法與叢集進行通訊時。
  • 有叢集節點離開叢集時。
  • 定期驗證時。可以設定頻率。

由上可知，檔案共用的負載很輕。結果就是，單一伺服器可以為多個 CCR 環境提供檔案共用。不過，在此伺服器上，每個 CCR 環境都應該要有它自己的專用資料夾及共用。

檔案共用見證注意事項

CCR 是雙節點環境，它使用具有檔案共用見證的 MNS 仲裁，或節點及檔案共用多數仲裁，而非傳統 MNS 叢集中所需的叢集第三節點 (或更多節點)。散佈各地的 CCR 環境是一個雙資料中心部署，其主動節點部署在主要資料中心，被動節點部署在次要資料中心。因此，在散佈各地的 CCR 環境中，檔案共用的放置有兩個選項：放在主要資料中心，或放在第三個資料中心。

第一個選項是在主要資料中心的 Hub Transport Server 上設定檔案共用。建議使用 Hub Transport Server，因為它可讓傳訊系統管理員管理及監視檔案共用的中斷情形。我們的經驗和客戶的意見指出，最常見的網路服務中斷類型是發生在廣域網路 (WAN) 拓撲中。將檔案共用放在主要資料中心很有幫助，因為它可防止因兩個資料中心之間發生網路失敗而中斷服務。使用此組態表示萬一主要資料中心中斷，將不會發生自動容錯移轉。不過，它可確保容錯移轉叢集的大部分節點不受到主要和次要資料中心之間網路失敗的影響。

第二個選項是在第三個實體站台內的受管理伺服器角色上設定檔案共用。受管理伺服器角色是一種伺服器，其受支援及維護的程度類似於對傳遞郵件服務很重要的其他伺服器。主要資料中心的 Hub Transport Server 即受管理伺服器角色的範例之一。這第三個實體站台可以是分公司或第三個資料中心。此組態的需求是第三個站台必須有主要資料中心和次要資料中心的網路基礎結構，具有低延遲和高可靠性。

交易記錄複寫及重新顯示

交易記錄複寫及重新顯示是用來複製已變更的資料，以及更新被動副本的資料庫。複寫會利用由可延伸儲存引擎 (ESE) 所產生的變更歷程。此變更歷程是以一系列固定大小的 1 MB 記錄檔來表示。在產生每個記錄檔時，複寫功能會將記錄檔複製到被動節點。複寫機制與線上資料庫是非同步的。當記錄檔抵達被動節點時，會檢查記錄檔是否有損毀，然後重新顯示到被動節點所儲存的資料庫副本中。重新顯示程序會進行被動節點之資料庫變更記錄中所描述的變更，而使被動節點的資料庫符合實際執行資料庫，其中僅有些微的時距。

因為資料是在節點之間進行複寫，所以叢集信箱伺服器可以對叢集中的任一個節點進行操作。此功能可提高可用性，因為一個節點的排定中斷和失敗，不會造成叢集信箱伺服器中斷時間延長。此外，某個節點上的儲存服務中斷不會影響其他節點及叢集信箱伺服器的可用性。假設檔案共用仍可使用，且能與被動節點進行通訊，則主動節點的中斷會導致叢集信箱伺服器移至剩餘的節點，並繼續運作。

在 CCR 環境中，主動節點上的交易記錄檔資料夾是使用標準 Windows 檔案共用來共用。儲存群組的物件全域唯一識別碼 (GUID) 會用來作為共用名稱，並在共用結尾處加入貨幣符號 ($)。被動節點上的 Microsoft Exchange 複寫服務會連結到主動節點上的共用，然後使用「伺服器訊息區 (SMB)」通訊協定來複製或提取記錄檔。然後被動節點會確認記錄檔，並將它重新顯示到被動節點上的資料庫副本中。

note附註：
交易記錄檔複寫的 SMB 流量並未加密。如有需要，您可以使用「網際網路通訊協定安全性 (IPsec)」來加密這個流量。使用 SMB 通訊協定時，只會發生交易記錄檔複寫。使用 ESE 備份應用程式發展介面 (API) (未加密通訊) 時，會重新植入被動副本。如有需要，可使用 IPSec 對此資料進行加密。

備援叢集網路上的連續複寫

在 Microsoft Exchange Server 2007 的量產發行 (RTM) 版本中，CCR 環境中的所有交易記錄檔複製與植入都在公用網路上發生。此組態有下列限制：

  • 當被動節點持續數小時無法使用時，將會累積大量需要傳送的記錄檔。當被動節點可用時，應該儘快移動這些記錄檔。在公用網路上複製記錄檔時，移動記錄檔會爭奪用戶端流量。這會影響用戶端流量，導致重新同步變慢。
  • 當公用網路失敗時，即使還有記錄資料，容錯移轉仍有損失。
  • 使用隔離網路來傳送記錄檔可以保護郵件資料，不必使用加密，也不會降低效能。
  • 在某些情況下可能會發生記錄檔風暴。發生這種情況時，系統會遭受異常沈重的複寫壓力。如果必須在與其他用戶端通訊的同一網路上傳送記錄資料，將會造成用戶端資源枯竭。

這些問題發生的週期不會全部相同。不過，因為被動節點會離線來進行定期維護活動，所以第一個問題每隔幾個月一定會發生一次。

Exchange 2007 SP1 可讓系統管理員在叢集中建立一或多個混合網路 (同時支援內部叢集活動訊號流量和用戶端流量的叢集網路) 來傳送記錄檔，將前述問題所造成的影響降到最低。Exchange 2007 SP1 也可讓系統管理員為植入作業指定一個專用的混合網路。

note附註：
用來傳送和植入記錄檔的叢集網路必須設定成混合網路。混合網路是指同時為叢集 (活動訊號) 和用戶端存取流量而設定的任何叢集網路。此外，在利用連續複寫主機名稱設定的網路介面卡上，系統管理員必須清除 [進階 TCP/IP] 內容對話方塊中的 [在 DNS 中登錄這個連線網路的位址] 核取方塊，並使用每個節點上的靜態 DNS 項目或主機檔案項目，對每個節點的新建主機名稱進行名稱解析。網路介面卡使用的 DNS 伺服器可位於公用或私人網路上；但不管它在什麼位置，都必須可供這兩個節點存取，才能進行主機名稱解析。此外，在 Windows Server 2008 上，用於記錄傳送或植入的網路介面卡需要啟用 NetBIOS。

使用一個叫作 Enable-ContinuousReplicationHostName 的新指令程式，可以設定支援透過混合網路來複製記錄檔。同樣地，您也可以使用 Disable-ContinuousReplicationHostName 指令程式關閉此功能。

當叢集信箱伺服器出現在 CCR 環境中之後，系統管理員可以在叢集的兩個節點上執行 Enable-ContinuousReplicationHostName，並且指定額外的 IP 位址和主機名稱，每一個節點關聯的專用叢集群組中將會建立這些項目。執行此工作之後，一旦順利設定並確認新網路可運作時，Microsoft Exchange 複寫服務會立即開始使用新建立的網路來複製記錄檔。如果建立多個新網路，Microsoft Exchange 複寫服務會隨機選擇其中一個。如果指定的網路無法使用，Microsoft Exchange 複寫服務會自動開始使用其他複寫網路，如果也都無法使用，則會在五分鐘之內開始使用公用網路來傳送記錄檔。(Microsoft Exchange 複寫服務網路搜索每隔五分鐘執行一次。)當偏好使用的複寫網路重新回復運作時，Microsoft Exchange 複寫服務會自動恢復以此網路來傳送記錄檔。

如需這些指令程式的相關資訊，請參閱 Enable-ContinuousReplicationHostName 和 Disable-ContinuousReplicationHostName。

利用 Update-StorageGroupCopy 指令程式可以設定為支援透過備援叢集網路進行植入，Exchange 2007 SP1 已更新此指令程式，增加新的參數 DataHostNames。此參數可指定用來進行植入的叢集網路。如需 Exchange 2007 SP1 對於 Update-StorageGroupCopy 指令程式的變更的相關資訊，請參閱 Update-StorageGroupCopy。

在建立連續複寫的叢集網路之後，對於已啟用連續複寫活動的叢集網路，您可以使用 Get-ClusteredMailboxServerStatus 指令程式來檢視更新的資訊。新的輸出詳細資料包括：

  • OperationalReplicationHostNames:{Host1,Host2,Host3}
  • FailedReplicationHostNames:{Host4}
  • InUseReplicationHostNames:{Host1,Host2}

如需 Exchange 2007 SP1 對於 Get-ClusteredMailboxServerStatus 指令程式的變更的相關資訊，請參閱 Get-ClusteredMailboxServerStatus。

傳輸暫放

在自動復原期間遺失的大量資料，稍後會由一個 Hub Transport Server 功能 (稱為「傳輸暫放」) 自動復原。特定資料庫的傳輸暫放可能位於含有叢集信箱伺服器之 Active Directory 站台的所有 Hub Transport Server 中。郵件通過 Hub Transport Server 而前往 CCR 環境中的叢集信箱伺服器時，除非過了複寫期間，否則都會在傳輸佇列 (mail.que) 中保留一份副本。傳輸暫放是 CCR 部署的必要元件。傳輸暫放會利用環境中的備援，來收回受到容錯移轉影響的部分資料。Hub Transport Server 會特別維護最近傳遞之郵件的佇列。這個佇列會受到保存郵件的時間量及使用的總空間所限制。如果發生不是 Lossless 的容錯移轉，叢集信箱伺服器上的 CCR 就會自動要求 Active Directory 站台中的每台 Hub Transport Server 重新提交傳輸暫放佇列中的郵件。資訊儲存庫會自動刪除重複的郵件，並重新傳遞遺失的郵件。

CCR 會啟用傳輸暫放，而在 Exchange 2007 SP1 中，本機連續複寫 (LCR) 也會啟用傳輸暫放。而 SCR 或單一副本叢集 (SCC) 則不會啟用傳輸暫放。對於 CCR，將電子郵件保留在傳輸暫放中的必要條件，就是至少要有一位收件者的信箱是位於 CCR 環境的叢集信箱伺服器上，如果是 SP1，則是在針對 LCR 啟用的信箱資料庫上。

傳輸暫放是設計來協助防止資料遺失，作法是為系統管理員提供選項來設定 CCR，讓叢集信箱伺服器能夠自動在另一個節點上連線，而不會遺失太多資料。發生這種狀況時，系統會利用傳輸暫放 (這台伺服器上所有已傳送給使用者的最新電子郵件仍儲存在這個位置上)，自動傳遞這些電子郵件。這有助於在大部分狀況中防止資料遺失。在 CCR 環境中，會自動要求從站台中所有 Hub Transport Server 上的傳輸暫放中重新傳遞。在 Exchange 2007 RTM 中，重試間隔已硬式編碼為七天。在 Exchange 2007 SP1 中，重試間隔等於針對 MaxDumpsterTime 所設定的值。在 LCR 環境中，要求從站台中所有 Hub Transport Server 中重新傳遞是 Restore-StorageGroupCopy 工作的一部分。

傳輸暫放無法緩和遺失資料的狀況包括：

  • 處於連線模式中任何 Microsoft Outlook 用戶端的草稿資料夾。
  • 約會、連絡人更新、內容更新、工作及工作更新。
  • 從用戶端傳輸到 Hub Transport Server 的外寄郵件。在某段時間內，電子郵件只會存在於寄件者的信箱伺服器上。

部署叢集連續複寫

部署 CCR 類似於部署獨立的 Exchange 伺服器，也與部署 SCC 類似。如需 SCC 的相關資訊，請參閱單一副本叢集。不過，部署 CCR 時也必須了解一些重要的差異。建議您在環境中設定和部署 CCR 之前，先檢閱下列主題：

當您準備好要部署 CCR 之後，即可執行下列其中一個主題所描述的各個安裝階段步驟，來開始此程序。

Exchange 2007 SP1 對 CCR 的加強功能

Exchange 2007 SP1 納入幾項 CCR 的加強功能，包括其他的 Exchange 管理主控台使用者介面元素、改進狀態和監視，以及改善效能。

Exchange 管理主控台加強功能

Exchange 2007 SP1 新增了幾個新的使用者介面元素，加強高可用性功能的管理體驗，其中也包括 CCR。這些改進包括：

  • 傳輸暫放使用者介面   對 [組織組態] 工作區下的集線傳輸節點新增了新的 [通用設定] 索引標籤。此索引標籤包括 [傳輸設定內容] 頁面，可用來設定組織的傳輸暫放設定：
    • 每個儲存群組的大小上限 (MB)   針對每個儲存群組指定傳輸暫放佇列的大小上限。
    • 保留時間上限 (天)   指定傳輸暫放佇列應該保留電子郵件的時間長度。
  • 連續複寫   Exchange 管理主控台新增了其他使用者介面控制項，可讓系統管理員暫停、繼續、更新及還原連續複寫。這些控制項相當於使用下列 Exchange 管理命令介面指令程式：
    • Suspend-StorageGroupCopy
    • Resume-StorageGroupCopy
    • Update-StorageGroupCopy
    • Restore-StoreGroupCopy
      您可以使用這些指令程式和對應的 Exchange 管理主控台工作，來管理 LCR 環境和 CCR 環境中的連續複寫。

狀態及監視加強功能

Exchange 2007 SP1 也引進幾項變更，這些變更是專門設計來加強 Exchange 2007 的管理性。這些變更改進 Exchange 2007 RTM 的叢集報告功能，並包含專門為主動監視連續複寫環境而設計的其他功能。具體來說，這些變更和加強功能更正 Get-StorageGroupCopyStatus 指令程式的已知缺失、引進一個稱為 Test-ReplicationHealth 的新指令程式，也更容易發覺傳輸暫放所遮蔽的遺失視窗。

Get-StorageGroupCopyStatus 指令程式的改良功能

在 Exchange 2007 RTM 中，在某些情況下，可能會出現 Get-StorageGroupCopyStatus 所報告的狀態與連續複寫效能計數器不正確或誤導的情形：

  • 非使用中 (例如未變更) 的儲存群組會報告為狀況良好，但實際上可能並非如此。之所以發生這種情況，可能是因為在重新顯示記錄之前無法偵測到不正常的狀況。
  • 在複寫初始化期間，會重新評估複寫狀態，但可能不會是正確的。在完成初始化時，狀態即會更新。
  • 卸載儲存群組中的資料庫時，LastLogGenerated 欄位的值可能不正確。
  • 當記錄資料流中有一或多個遺失的記錄檔時，被動副本會繼續嘗試復原，因而導致複寫狀態在失敗與正常狀態之間切換。出現這種情形時，重新顯示與複製佇列會持續成長。
  • 在少數情況下，記錄檔可順利驗證，但仍無法重新顯示。在這種情況下，系統在嘗試復原時會在失敗與正常狀態之間交替。出現這種情形時，重新顯示與複製佇列會持續成長。

Get-StorageGroupCopyStatus 指令程式也增強了，因為新增了 CCR 環境的新狀態資訊：

  • Get-StorageGroupCopyStatus 指令程式會在無法從網路存取目標電腦上的 Microsoft Exchange 複寫服務時，將 SummaryCopyStatus 回報為 ServiceDown。
  • Get-StorageGroupCopyStatus 指令程式會在目標電腦上的 Microsoft Exchange 複寫服務未完成其初始啟動檢查時，將 SummaryCopyStatus 回報為 Initializing。另已建立新的效能計數器，且會以布林值的形式顯示此狀態。
  • Get-StorageGroupCopyStatus 指令程式會在未完成增量重新植入時，將 SummaryCopyStatus 回報為 Synchronizing。

只有在使用 Exchange 2007 SP1 版的 Exchange 管理工具時，您才能看見 SummaryCopyStatus 值的新狀態。若您使用 Exchange 2007 RTM 版本的 Exchange 管理工具，任何前述狀態都將回報為「失敗」。

Test-ReplicationHealth 指令程式

Exchange 2007 SP1 引進一個稱為 Test-ReplicationHealth 的新指令程式。此指令程式是為主動監視連續複寫和連續複寫管線而設計。Test-ReplicationHealth 指令程式會檢查複寫、叢集服務和儲存群組複寫及重新顯示狀態的所有層面，以提供複寫系統的完整概觀。明確而言，當 Test-ReplicationHealth 指令程式執行於叢集內的節點上時，將會執行下表所述之測試。

Test-ReplicationHealth 指令程式所執行的測試

測試 描述

叢集網路狀態

驗證在本機節點上找到的所有叢集管理網路皆為執行中。此測試只有在 CCR 環境中進行。

仲裁群組狀態

驗證包含仲裁資源的叢集群組狀態正常。此測試只有在 CCR 環境中進行。

檔案共用仲裁狀態

驗證具有檔案共用見證的多數節點集仲裁所使用的 FileSharePath 值為可存取狀態。此測試只有在 CCR 環境中進行。

叢集信箱伺服器群組狀態

確認群組中所有的資源皆在線上，以驗證叢集信箱伺服器的狀態正常。此測試只有在 CCR 環境中進行。

節點狀態

驗證叢集中的節點皆不處於暫停狀態。此測試只有在 CCR 環境中進行。

DNS 註冊狀態

確認已設定 [需要成功註冊 DNS] 的所有叢集管理網路介面都已通過 DNS 註冊。此測試只有在 CCR 環境中進行。

複寫服務狀態

確認本機電腦上的 Microsoft Exchange 複寫服務的健康狀況良好。

儲存群組副本已擱置

檢查已啟用連續複寫的任何儲存群組，其連續複寫是否已擱置。

儲存群組副本失敗

檢查是否有任何儲存群組副本的狀態為「失敗」。

儲存群組複寫佇列長度

檢查是否有任何儲存群組的複寫副本佇列長度大於最佳作法閾值。目前，這些閾值為：

  • Warning   佇列長度為 3–5 個記錄檔。
  • Failure   佇列長度為 6 個 (含) 以上的記錄檔。

資料庫在容錯移轉之後卸載

檢查在發生容錯移轉之後是否有任何資料庫卸載或失敗。此測試只會檢查因為容錯移轉而失敗的資料庫。

效能增強功能

Exchange 2007 SP1 中已改進高可用性部署的效能。這些改進包括：

  • 在連續複寫環境中，儲存群組被動副本所在的磁碟減少 I/O 次數   在 Exchange 2007 SP1 中，已修改連續複寫架構的設計，在記錄檔重新顯示活動批次之間，現在會在被動節點上保存資料庫快取。在記錄檔重新顯示活動批次之間保存資料庫快取，可讓 Microsoft Exchange 複寫服務利用 ESE 的資料庫快取功能，進而減少被動副本的邏輯單元編號 (LUN) 上發生的磁碟 I/O 次數。相較之下，在 Exchange 2007 RTM 中，每一批記錄檔重新顯示活動會建立新的資料庫快取，在某些情況下，這會導致被動節點的磁碟 I/O 活動比主動節點的磁碟 I/O 活動高出兩倍到三倍。
  • 在 CCR 環境中，節點之間的叢集信箱伺服器移動更快   這些改進可在兩分鐘以內完成在節點之間移動叢集信箱伺服器。這包括系統管理員執行的移動 (使用 Move-ClusteredMailboxServer 指令程式) 和叢集服務所管理的容錯移轉。為了在 CCR 環境中快速完成移動，資料庫會直接離線而不清除資料庫快取。此作法可縮短叢集信箱伺服器移至另一個節點時所需的停機時間。

使用待命連續複寫與 CCR

SCR 是 Exchange 2007 SP1 中引進的新功能。SCR 會擴充現有的連續複寫功能，以及啟用 Exchange 2007 Mailbox Server 的新資料可用性案例。SCR 也會利用 LCR 及 CCR 所使用的相同記錄傳送及重新顯示技術，提供新增的部署選項及組態。

SCR 可讓您使用連續複寫，複寫 SCC 或 CCR 環境中獨立 Mailbox Server (含或不含 LCR) 或叢集信箱伺服器中的 Mailbox Server 資料。

啟動 SCR 所建立及維護之 Mailbox Server 資料副本的處理程序是手動的，而且是設計成只有在發生重大失敗時才使用 (並不適用於只要重新開機或透過其他快速方法就可恢復的單純伺服器中斷)。您可以使用資料庫可攜性、伺服器復原選項 (Setup /m:RecoverServer) 來啟動 SCR 目標，如果 Mailbox Server 已叢集化，您也可以使用叢集信箱伺服器復原選項 (Setup /RecoverCMS)。您選擇的選項視您的組態和發生的失敗類型而定。

如需 SCR 的相關資訊，請參閱待命連續複寫。

相關資訊

下列主題範圍討論使用 CCR 作為高可用性及站台回復性計畫的時機及方法：

若要確保您目前閱讀的是最新資訊，並尋找其他的 Exchange Server 2007 說明文件，請造訪 Exchange Server 技術資源中心.