管理待命連續複寫

Exchange 2007
 

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

上次修改主題的時間: 2008-11-19

除了每日管理與 Microsoft Exchange 組織管理的工作外,還有待命連續複寫 (SCR) 特定的工作。一般來說,SCR 的系統管理工作為:

  • 設定 SCR 磁碟儲存及管理磁碟區。

  • 啟用及停用 SCR。

  • 監視複寫活動。

  • 裝載、卸載、建立及移除資料庫。

  • 當儲存群組已啟用 SCR 時,移動儲存群組或資料庫檔案的儲存位置。

  • 驗證 SCR 目標的健康狀況。

  • 管理複寫及重新顯示活動。

  • 從損毀中復原。

這些工作會在本主題稍後加以討論。

SCR 只能使用 Exchange 管理命令介面加以啟用及管理。Exchange 管理主控台無法用來啟用或停用 SCR、檢視 SCR 狀態或管理 SCR 的各方面。

SCR 不需要經過特殊設定的磁碟儲存。SCR 需要能夠提供足夠容量的儲存。應該對相同儲存群組之已設定的所有 SCR 目標設定同等儲存解決方案,建議您遵循儲存廠商所提供的組態程序來完成組態。

管理 SCR 環境時,可能必須管理與 Exchange 伺服器連線的磁碟區。例如,因為維護或其他理由,可能需要從系統中暫時中斷連線磁碟區。如果需要在含有儲存群組主動副本的磁碟區上執行維護工作,則應該將儲存群組主動副本中的資料庫卸載。如果需要在含有儲存群組被動副本的磁碟區上執行維護工作,則應該終止複寫來停止該磁碟區上所有的輸入/輸出 (I/O)。如需管理磁碟區的相關資訊,請參閱使用 SCR 時如何準備磁碟管理活動

您只能使用 Exchange 管理命令介面及執行 New-StorageGroup 指令程式或 Enable-StorageGroupCopy 指令程式來啟用 SCR。這兩個指令程式都包含一些在 Microsoft Exchange Server 2007 Service Pack 1 (SP1) 引進的新參數:

  • -StandbyMachine 此參數是用來指定包含 SCR 目標之電腦的名稱。此參數的值是設定為針對 SCR 啟用之儲存群組的 msExchStandbyCopyMachines 屬性值的一部分。msExchStandbyCopyMachines 屬性是一個多重值 Unicode 字串,當 Exchange 2007 SP1 引進至 Exchange 組織時,該字串會新增至 Active Directory 目錄服務架構中。

  • -ReplayLagTime 此參數是用來指定 Microsoft Exchange 複寫服務在重新顯示已複製到 SCR 目標電腦的記錄檔之前應該等待的時間量。此參數的格式為 (Days.Hours:Minutes:Seconds)。此值的預設設定是 24 個小時。而此值的允許上限設定是 7 天。允許的下限設定為 0 秒,不過如果將這個值設定為 0,並不會影響 50 個記錄檔的記錄檔重新顯示活動的預設延遲。設定此參數的值之後,如果不是透過先停用再啟用 SCR 的方式,就無法變更此值。

  • -TruncationLagTime   此參數是用來指定在截斷已複製到 SCR 目標電腦的記錄檔及重新顯示至資料庫副本之前,Microsoft Exchange 複寫服務應該等待的時間量。在記錄檔順利重新顯示至資料庫副本之後,此時段即開始。此參數的格式為 (Days.Hours:Minutes:Seconds)。而此值的允許上限設定是 7 天。允許的下限設定為 0 秒,不過如果將這個值設定為 0,將會有效排除記錄檔截斷活動中的任何延遲。設定此參數的值之後,如果不是透過先停用再啟用 SCR 的方式,就無法變更此值。

  • -SeedingPostponed 此參數可用來略過 SCR 目標的初始植入作業。如果使用此參數,系統管理員必須使用 Update-StorageGroupCopy 指令程式,手動植入 SCR 目標。此參數只能與 Enable-StorageGroupCopy 指令程式一起使用。它不能與 New-StorageGroup 指令程式一起使用,因為此時沒有任何來源資料庫存在。

    important重要事項:
    若要變更重新顯示或截斷延遲設定,您必須先停用 SCR,然後使用這些設定的新值啟用 SCR。

除了系統管理員設定的重新顯示延遲 (使用 ReplayLagTime 參數指定) 之外,不論 ReplayLagTime 的值是什麼,Exchange 也可以使用下列公式來防止固定數量的記錄檔重新顯示在 SCR 目標上:

("ReplayLagTime 的值" 或 "X 個記錄檔") 的上限

其中 X=50。這是對於在連續複寫環境 (例如本機連續複寫 (LCR) 或叢集連續複寫 (CCR)) 中的 SCR 來源發生遺失容錯移轉,並使用 Restore-StorageGroupCopy 指令程式連線時,需要重新植入儲存群組的多一層保護。透過在 SCR 目標上延遲重新顯示活動,當 SCR 來源發生遺失容錯移轉時,可使需要重新植入 SCR 副本的機會減至最低,因為 SCR 來源上的資料遺失性質會及時使兩個副本彼此靠得更近。

important重要事項:
內建的 50 個記錄檔的延遲時間及 ReplayLagTime 參數的值具有建立初始 SCR 目標資料庫的隱含意義。要等到 50 個交易記錄檔都複寫到 SCR 目標電腦,而且經過 ReplayLagTime 指定的期間 (或預設 ReplayLagTime 24 小時) 過後之後,才會建立 SCR 目標資料庫。

當您對儲存群組啟用 SCR 時,會在 SCR 目標電腦上自動建立及維護儲存群組 (系統檔案、記錄檔和資料庫檔案) 的副本,並使用與 SCR 來源上的儲存群組相同的路徑。

啟用 SCR 之後,我們建議使用 Test-ReplicationHealth 指令程式監視每一個儲存群組的健康狀況和狀態。如需如何啟用 SCR 的詳細步驟,請參閱如何啟用現有儲存群組的待命連續複寫如何啟用新儲存群組的待命連續複寫

因為您無法建立 SCR 目標資料庫的備份,所以 SCR 記錄檔截斷並不是以備份時間為根據。相反地,記錄檔截斷是由 SCR 來源的檢查點和 TruncationLagTime 的值來決定。

如果 SCR 來源是 CCR 環境中的叢集信箱伺服器 (CMS),則記錄檔截斷邏輯包括所有 SCR 目標均順利複製及檢查所有記錄檔。這表示如果 SCR 目標無法使用,則就算使用備份,記錄檔截斷也不會發生在 SCR 來源上。

在 SCR 環境中,如果所需的所有記錄檔都可供使用,則根據下列資訊,停用後又重新啟用的 SCR 目標就不需要重新植入:

  • 如果對儲存群組啟用了循環記錄,則刪除記錄檔將因為記錄檔順序不連續而導致已啟用的 SCR 目標需要重新植入。

  • 如果使用的備份包括記錄檔截斷,則刪除記錄檔將因為記錄檔順序不連續而導致已啟用的 SCR 目標需要重新植入。

如果透過前述任一方法都未能截斷記錄檔,則停用又啟用 SCR 時就不需要重新植入。在此情況下,需要刪除在 SCR 目標的記錄檔,但會從 SCR 來源中再次複寫它們。

如果您計劃啟用先前停用的 SCR 目標,我們建議最好不要先執行任何記錄檔截斷作業 (例如,啟用循環記錄或執行記錄檔截斷備份),直到啟用 SCR 目標,且啟用之後的設定變更複寫到整個 Active Directory 為止。

您只能使用 Disable-StorageGroupCopy 指令程式和 StandbyMachine 參數來停用 SCR。停用 SCR 時,您一定要包括 StandbyMachine 參數的適當值。如果 SCR 來源儲存群組也已啟用 LCR,但您未將 StandbyMachine 參數併入為此命令的一部分,則會對該儲存群組停用 LCR。

需要停用 SCR 才能變更 ReplayLagTimeTruncationLogDelay 參數的值。啟用 SCR 時,無法修改這些值。因為,若要變更重新顯示或截斷延遲設定,您必須先停用 SCR,然後使用這些設定的新值再次啟用它。

如需如何停用儲存群組之 SCR 的詳細步驟,請參閱如何停用儲存群組的待命連續複寫

雖然 SCR 不需要特別監視,仍建議您定期監視每個儲存群組,以確認它是否正確複寫記錄檔。Microsoft Exchange Server 2007 Management Pack for Microsoft Operations Manager 2005 包含與 SCR 環境相關之數個重要問題的警示:

  • Microsoft Exchange 複寫服務未執行。請注意,停止服務之後,產生這個警示的事件將不會重複出現,因此,如果清除這個警示,將會遺失任何關聯的警示。

  • SCR 目標副本的狀態為「失敗」。

  • SCR 目標副本的狀態為「正常」,但在記錄檔複製方面是落後的。

您應該儘快調查及解決 Exchange 2007 Management Pack 之前所產生的任何警示。

Exchange 2007 SP1 引進一個稱為 Test-ReplicationHealth 的新指令程式。此指令程式是為了主動監控連續複寫 (LCR、CCR 和 SCR) 和連續複寫管線而設計的。Test-ReplicationHealth 指令程式會檢查複寫、叢集服務、儲存群組複寫和重新顯示狀態等各方面,以提供複寫系統的完整概觀。具體而言,Test-ReplicationHealth 指令程式會執行下表所說明的測試。

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

測試 描述

叢集網路狀態

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

仲裁群組狀態

驗證包含仲裁資源的叢集群組狀態正常。此測試僅適用於 CCR 環境。

檔案共用仲裁狀態

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

叢集信箱伺服器群組狀態

確認群組中的所有資源都在線上,以驗證 CMS 的狀態正常。此測試僅適用於 CCR 環境。

節點狀態

驗證叢集中的節點皆不處於暫停狀態。此測試僅適用於 CCR 環境。

DNS 註冊狀態

驗證所有已設定「需進行 DNS 登錄才能繼續」的叢集管理網路介面,皆已通過網域名稱系統 (DNS) 登錄。此測試僅適用於 CCR 環境。

複寫服務狀態

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

儲存群組副本已擱置

檢查是否有擱置任何儲存群組的連續複寫。

儲存群組副本失敗

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

儲存群組複寫佇列長度

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

  • Warning   佇列長度為 3–5 個記錄檔。

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

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

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

您有時必須在 SCR 環境中裝載或卸載資料庫。如果 SCR 來源儲存群組或資料庫需要重新設定或維護,則您必須在活動發生時,封鎖與這兩者互動的服務。執行重新設定或者更正伺服器或資料庫的問題時,可能需要這樣做。當資料庫卸載之後,即無法存取它。

您可以變更資料庫在已啟用 SCR 的儲存群組中的位置。SCR 環境中有兩個資料庫檔案,各有一個副本。移動儲存群組檔案或資料庫檔案時,兩個副本的位置必須一前一後變更。

note附註:
在 SCR 來源和所有 SCR 目標上,儲存群組檔案和資料庫檔案的完整路徑必須符合。

您可以使用類似的程序來重新設定儲存群組記錄及系統檔案的位置,以及 SCR 環境中資料庫檔案的位置。如需如何變更已啟用 SCR 之儲存群組中記錄檔及系統檔案位置的詳細步驟,請參閱如何在待命連續複寫環境中移動儲存群組。如需如何變更 SCR 環境中資料庫檔案位置的詳細步驟,請參閱如何在待命連續複寫環境中移動資料庫

important重要事項:
資料庫不能放在磁碟區的根目錄。

所有監控和狀態都是使用 Exchange 管理命令介面來執行。Exchange 管理主控台不會顯示關於 SCR 的副本狀態或任何其他資訊。啟用儲存群組的 SCR 之後,您可以使用 Exchange 管理命令介面,來檢視儲存群組及其資料庫的 SCR 特定組態設定。

Exchange 2007 會針對 SCR 副本發佈不同的狀態資訊。下表描述已啟用 SCR 之儲存群組可能會有的狀態資訊。如需說明如何取得狀態資訊的詳細步驟,請參閱如何檢視待命連續複寫的狀態

note附註:
下表會以內容出現在 Get-StorageGroupCopyStatus 指令程式之完整輸出的順序來列出內容。

已啟用 SCR 之儲存群組可用的狀態資訊

屬性 描述

Identity

查詢之儲存群組的伺服器及名稱。

StorageGroupName

查詢之儲存群組的名稱。

SummaryCopyStatus

SCR 副本目前的整體狀態。可能的值為:

  • Not Supported   目前的組態不支援連續複寫。

  • Disabled   電腦尚未指定為目標。如果目標電腦尚未讀取指定它是目標電腦的 Active Directory 中的已更新資訊,它會報告「Disabled」狀態。如果您已啟用此目標電腦來進行 SCR,但它報告「Disabled」狀態,請檢查 Active Directory 複寫是否有任何問題或延遲。

  • Failed   驗證失敗 (資料庫或記錄檔彼此不相容),或儲存群組的 SCR 設定不正確。

  • Seeding   資料庫植入正在進行中。

  • Initializing   系統正在連線,但複寫尚未開始。系統將維持為此狀態,直到產生交易記錄檔為止。

  • Service Down Microsoft Exchange 複寫服務未執行。

  • Suspended   交易記錄複製及重新顯示已停止。

  • Synchronizing   系統偵測到容錯移轉,但它會更正任何發生的分岐。

  • Healthy   狀態良好且正常,沒有封鎖別人或被封鎖的項目。

Failed

資料庫或記錄的驗證識別出不一致情況,造成複寫失敗。或者,主動或被動副本有組態或存取問題。可能的值為 True 及 False。

FailedMessage

指出造成複寫失敗之狀況的文字訊息。這可能不是唯一一個出現複寫問題的區域。

Seeding

植入正在進行中。可能的值為 True 及 False。

Suspend

已經終止被動副本的複寫 (及重新顯示)。這樣會造成資料庫不再繼續,並且停止複製記錄。可能的值為 True 及 False。

SuspendComment

選用的系統管理員註解,提供複寫活動終止的原因或附註。

CopyQueueLength

等候複製到被動副本記錄檔資料夾的交易記錄檔數。在檢查完副本是否有損毀後,副本才能夠視為完成。

ReplayQueueLength

已複製並等候重新顯示到被動副本的交易記錄檔數。

LatestAvailableLogTime

最近偵測到新交易記錄檔之來源儲存群組上的時間戳記。

LastCopyNotificationedLogTime

與作用中儲存群組最後產生之新記錄關聯,且副本已知的時間。

LastCopiedLogTime

上次順利複製交易記錄檔之來源儲存群組上的時間戳記。

LastInspectedLogTime

上次順利檢查交易記錄檔之來源儲存群組上的時間戳記。

LastReplayedLogTime

上次順利重新顯示交易記錄檔之來源儲存群組上的時間戳記。

LastLogGenerated

儲存群組的主動副本上產生之最後一個已知記錄的記錄產生編號。

LastLogCopied

上一個順利複製到被動副本記錄檔資料夾的記錄檔產生號碼。

LastLogNotified

由作用中儲存群組最後所產生,且副本已知的記錄產生編號。

LastLogInspected

上一個檢查有無一致性及損毀問題的記錄檔產生號碼。

LastLogReplayed

上一個順利重新顯示到儲存群組被動副本的記錄產生編號。

LatestFullBackupTime

最後一次執行完整備份的時間。

LatestIncrementalBackupTime

最後一次執行增量備份的時間。

SnapshotBackup

使用傳統資料流 API 或磁碟區陰影複製服務 (VSS) 進行備份。可能的值為 True 及 False。

您可藉由查看 SummaryCopyStatusCopyQueueLengthReplayQueueLengthLastInspectedLogTime 中的值,快速評估 SCR 副本的健康狀況。這些內容會顯示 SCR 副本是否運作正常,以及 SCR 副本在複製及重新顯示記錄中是否為最新。如果下列狀況發生,您應該判定原因並修正問題:

  • 副本長時間處於不正常的狀態。

  • 複製佇列長度超過 5。

  • 重新顯示佇列長度超過 20。

  • 上次檢查的記錄時間並不是顯示目前的時間。此問題有兩個可能原因:一是儲存群組並沒有多大的變更,二是複寫服務已停止。

重新顯示佇列長度及複製佇列長度值都有效能計數器。這些是 MSExchange Replication 效能物件底下的 CopyQueueLengthReplayQueueLength 效能計數器。

有極少數複寫狀態可能會造成誤導的案例。下列是這些案例的清單:

  • 非使用中 (亦即未變更) 的儲存群組會報告為狀況良好,但它可能並非狀況良好。發生這種情況可能是因為在重新顯示記錄之前,無法偵測到不正常的狀況。

  • 在複寫初始化期間,會評估複寫狀態,但可能不精確。在完成初始化時,狀態即會更新。

  • 卸載資料庫時,LastLogGenerated 欄位的值可能是錯的。不過,如果複寫儲存群組副本,則會複寫含有使用者內容的所有記錄檔。

  • 當記錄資料流的中間有一或多個遺失的記錄時,被動副本會繼續嘗試復原。這樣做時,複寫狀態會在失敗狀態與狀況良好狀態之間切換。重新顯示和複製佇列會持續成長。

  • 在一些非常少見的情況下,可順利驗證記錄,但該記錄仍無法重新顯示。在此情況下,系統會在其嘗試復原時,在失敗狀態與狀況良好狀態之間交替。重新顯示和複製佇列會持續成長。

當您使用 SCR 時,建議您定期對資料庫及交易記錄檔執行實體一致性檢查,以驗證每一個 SCR 目標副本的完整性。實體一致性檢查會檢驗交易記錄檔與資料庫檔案是否有損毀。您可以使用 Microsoft 磁碟區陰影複製服務工具 (VSSAdmin.exe) 和 Exchange Server 資料庫公用程式 (Eseutil.exe) 的命令列版本來執行此檢查。如需如何使用 VSSAdmin 和 Eseutil 檢查交易記錄檔及資料庫檔案是否有實體損毀的詳細步驟,請參閱如何驗證待命連續複寫副本

note附註:
在對資料庫執行實體一致性檢查之前,您必須先暫時擱置儲存群組上所有的複寫活動。您可以在 Exchange 管理命令介面中使用 Suspend-StorageGroupCopy 指令程式來擱置複寫活動。完成一致性檢查時,可以使用 Resume-StorageGroupCopy 指令程式繼續交易記錄重新顯示活動。建議您在非營業時間執行驗證作業,以減少需要擱置重新顯示活動的時間。這是因為擱置儲存群組副本會終止 SCR 副本的所有更新作業,造成某些內容很容易就會失敗。

管理 SCR 環境中的記錄檔複寫及重新顯示主要牽涉到下列活動:

  • 終止對儲存群組副本的複寫

  • 重新啟動對儲存群組副本的複寫

  • 重新植入儲存群組

基於各種原因,您可能必須終止之後再重新啟動交易記錄檔複寫活動。發生交易記錄檔複寫的時機為:當 Microsoft Exchange 複寫服務正在執行中、已對儲存群組啟用 SCR,而且 SCR 來源和 SCR 目標均運作正常。如果來源或目標變成無法使用,則必須停止複寫。此外,某些系統管理工作 (例如植入) 需要您對於已啟用 SCR 的儲存群組擱置複寫。如果您需要停止所有對目標資料檔案的存取,就必須擱置複寫。

您有時必須控制 SCR 目標的活動。可能需要這樣做,才能執行重新設定或者更正伺服器或資料庫的問題。執行 SCR 目標的實體一致性檢查時,還需要終止記錄檔重新顯示。必須控制資料庫副本更新時,必須終止 SCR 目標的複寫。若基於某種原因而操作 SCR 目標記錄檔時,也可能需要終止複寫。

如需終止 SCR 副本之複寫變更的相關資訊,請參閱如何擱置待命連續複寫目標的變更。如需重新啟動 SCR 副本之複寫變更的相關資訊,請參閱如何繼續待命連續複寫目標的複寫。如需在被動副本的交易記錄及資料庫檔案上執行完整性檢查的相關資訊,請參閱如何驗證待命連續複寫副本

在 SCR 環境中植入和重新植入儲存群組副本,是使用 Update-StorageGroupCopy 指令程式與 StandbyMachine 參數來執行,該參數是 Exchange 2007 SP1 中所新增的參數。

如需如何植入或重新植入 SCR 目標的詳細步驟,請參閱如何植入待命連續複寫目標

在資料庫副本失敗或損毀後,您必須評估是否需要立即使用 SCR 目標繼續作業。SCR 會提供這項決定所需的重要輔助資訊:

  • 失敗時副本的健康狀況

  • 失敗時重新顯示佇列及複製佇列的健康狀況

  • 失敗時上次檢查的記錄時間

上述資訊可以透過使用 Get-StorageGroupCopyStatus 指令程式取得。如需如何取得這項資訊的詳細步驟,請參閱如何檢視待命連續複寫的狀態

note附註:
上次檢查的記錄時間會提供 SCR 來源的最新變更之相關資訊。此資訊有助於偵測未啟動 Microsoft Exchange 複寫服務時所發生的失敗,因為當 Microsoft Exchange 複寫服務停止時,佇列長度會不正確。

複製佇列長度含有 SCR 來源在失敗時的最佳可用資訊。您必須根據這項資訊及對失敗資料庫的復原時間評估,決定是否要啟動可用的 SCR 目標:

  • 如果重新顯示佇列長度很長,則復原作業可能會需要一些時間,但不表示將會大量遺失資料。

  • 如果複製佇列長度很長,則已經遺失許多記錄檔。如果已啟動資料庫,則資料庫會還原至接近上次複製記錄檔的時間 (Get-StorageGroupCopyStatus 指令程式也會提供)。

  • 如果上次檢查的記錄時間明顯早於失敗的時間,可能 Microsoft Exchange 複寫服務已停止,其他佇列資訊並不正確。

    note附註:
    由於 SCR 的本質以及外部延遲及通訊失敗等原因,複製佇列長度可能會不正確,這是因為主動副本目前的狀態是在非同步的情況下更新。一般而言,此不正確性限於失敗前後一刻的活動。
    note附註:
    失敗的資料庫無法用於植入 SCR 目標。
 
顯示: