待命連續複寫：具有待命叢集的站台回復性

  • 發行項

 

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

上次修改主題的時間： 2008-11-18

本主題詳述 Contoso, Ltd. 這家公司如何在站台回復性案例中使用待命連續複寫 (SCR)。主要資料中心失敗，而 Contoso, Ltd. 決定啟動次要資料中心。啟動次要資料中心之後，會重新設定主要資料中心，最後再透過受控制的切換將其還原為主要資料中心。Contoso, Ltd. 擁有兩個資料中心：主要資料中心 (Active Directory SITEA) 及次要備份資料中心 (Active Directory SITEB)。SITEA 位在奧勒崗州的波特蘭，而 SITEB 則位在加州的聖荷西。

SITEA 包含下列基礎結構元件：

  • 目錄伺服器 (DC1)，也提供安全的 Active Directory 整合式網域名稱系統 (DNS) 服務

  • Client Access Server (CAS1)

  • Hub Transport Server (HUB1)

  • 叢集信箱伺服器 (EXCMS1)，執行於包含 NODEA 及 NODEB 的雙節點單一副本叢集 (SCC) (EXCLUS1) 中。請注意：

    • 容錯移轉叢集中的節點是執行於 Windows Server 2008 作業系統上，且容錯移轉叢集是設定為具有節點及磁碟多數仲裁。

    • 叢集信箱伺服器之網路名稱資源的 DNS 存留時間 (TTL) 值是設定為五分鐘。這已藉由執行下列命令，然後停止並啟動叢集信箱伺服器進行設定。

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300
      note附註：
      HostRecordTTL 內容只適用於執行 Windows Server 2008 的容錯移轉叢集上。此命令無法用於在 Windows Server 2003 作業系統上執行的容錯移轉叢集。

SITEB 包含下列基礎結構元件：

  • 目錄伺服器 (DC2)，也提供安全的 Active Directory 整合式 DNS 服務

  • Client Access Server (CAS2)

  • Hub Transport Server (HUB2)

  • 單一節點叢集 (DRCLUS1)，作為待命容錯移轉叢集。請注意：

    • 此叢集中的節點 (NODEC) 是待命容錯移轉叢集中的唯一節點，而且執行 Windows Server 2008。此待命容錯移轉叢集是設定為具有節點多數仲裁。

      note附註：
      在執行 Windows Server 2003 的容錯移轉叢集中，單一節點待命容錯移轉叢集會設定為具有本機仲裁。

    • 被動 Mailbox server role 是使用與 EXCLUS1 相同的安裝路徑安裝在 NODEC 上。需要這樣做才能在 SCR 目標啟動處理程序時，使用 Setup /RecoverCMS 執行伺服器復原。若要使用伺服器復原處理程序，SCR 來源電腦與 SCR 目標電腦的 Exchange Server 安裝路徑必須相同。如果 Exchange Server 是安裝至 SCR 來源電腦的 %ProgramFiles%\Microsoft\Exchange Server 中，則也必須將其安裝至將作為 SCR 來源伺服器之 SCR 目標的所有電腦上的 %ProgramFiles%\Microsoft\Exchange Server 中。如果這些安裝路徑不相符，則因為登錄中的安裝路徑會不符合 Active Directory 中 Mailbox Server 物件的 msExchInstallPath 屬性值，所以伺服器復原處理程序會失敗。

    • 使用 Active Directory 使用者和電腦嵌入式管理單元，可以將 DRCLUS1 的電腦帳戶設定為具有 EXCMS1 電腦物件的完整權限。在因為 SITEA 失敗而啟動 SITEB 的事件中，這樣做可讓 DRCLUS1 重設 EXCMS1 的電腦帳戶。

      note附註：
      此步驟僅適用於執行 Windows Server 2008 的容錯移轉叢集上。這是因為叢集服務是在本機系統的安全性內容中執行。如果此容錯移轉叢集與執行 Windows Server 2003 的容錯移轉叢集使用相同的叢集服務帳戶，則在後者上就不需要此步驟。

兩個 Active Directory 站台中的所有伺服器都設定為使用 Active Directory 整合式 DNS 伺服器。而兩個 Active Directory 站台的 Active Directory 複寫間隔則設定為 15 分鐘。

設定 SCR，讓交易記錄檔從 EXCMS1 的三個儲存群組複寫至 NODEC 的 SCR 目標中。而這是使用下列命令進行設定：

Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC
note附註：
若要同時啟用 EXCMS1 上的所有儲存群組進行 SCR，請執行下列命令： Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

每個儲存群組的 SCR 健康狀況及狀態，已在 Exchange 管理命令介面中使用 Test-ReplicationHealth 及 Get-StorageGroupCopyStatus 指令程式進行驗證。例如：

Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

叢集信箱伺服器的移動，以及備份及記錄檔截斷，都已驗證如預期運作。

主要站台失敗及備份站台啟動

波特蘭突然沒有預警地發生大地震。雖然沒有任何人員受到嚴重傷害，但是嚴重損害了 SITEA，因而必須中斷重要公用事業服務 (如電源、水及天然瓦斯)。因為 Contoso, Ltd. 可能需要幾個月的時間才能再使用 SITEA，所以決定手動啟動 SITEB，並從該站台提供所有的郵件資料及服務。

啟動 SITEB 時，一開始會先驗證目錄服務及 DNS 解析。因為 SITEB 已經包含同時主控 Active Directory 整合式 DNS 的目錄伺服器，所以這些服務會是健康及最新的，而且不會因 SITEA 中斷而受到些微影響。驗證目錄服務及 DNS 之後，下一步是開始啟動 SCR 目標以及復原叢集信箱伺服器。這可以透過依序執行下列步驟完成：

  1. 在 NODEC 上開啟 Exchange 管理命令介面，並執行下列命令以準備 SCR 目標進行裝載。

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force
    important重要事項：
    無法使用 SCR 來源時，一律必須指定 Force 參數。
    note附註：
    另一種執行步驟 1 中所示之三個不同 Restore-StorageGroupCopy 命令的方式，是使用 Microsoft Exchange Server 2007 Service Pack 1 (SP1) 提供的新指令碼 (稱為 GetSCRSources.ps1)，並如下所示將指令碼輸出以管道送至單一 Restore-StorageGroupCopy 工作： GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force

  2. 使用 DNS 管理嵌入式管理單元，從 DNS 移除 EXCMS1 的現有 DNS 記錄。

    note附註：
    此步驟僅適用於執行 Windows Server 2008 的容錯移轉叢集上。這是因為叢集服務是在本機系統的安全性內容中執行。如果此容錯移轉叢集與執行 Windows Server 2003 的容錯移轉叢集使用相同的叢集服務帳戶，則在後者上就不需要此步驟。

  3. 已停用所有儲存群組的 SCR，以準備 /RecoverCMS 處理程序。如果未停用所有儲存群組的 SCR，Setup /RecoverCMS 就會失敗。您可以使用下列命令來停用 SCR：

    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False

  4. 使用安裝程式的 /RecoverCMS 選項，復原叢集信箱伺服器 (EXCMS1)。在 NODEC 上使用下列命令來執行復原後，就會立即進行復原：

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    注意下列事項：

    • 上述命令中的 CMSIPAddress 值，可能是與 EXCMS1 的原始 IP 位址不同的 IP 位址。這是因為 EXCMS1 是在站台外進行復原。亦即，它一開始是主控於 SITEA 中，而現在則是要復原至 SITEB。

    • 進行 DNS 複寫且清除復原伺服器 (NODEC) 的 DNS 快取之後，Setup /RecoverCMS 就會順利完成。如果安裝程式失敗，則應該使用網域主控站 (PDC) 及 NODEC 的 NSLookup 來驗證正確的 IP 位址是解析為 NODEC，然後在驗證之後重新執行安裝程式。

    • 在執行 Windows Server 2003 的容錯移轉叢集上，會在 Setup /RecoverCMS 處理程序期間重設 EXCMS1 的電腦物件。這項重設作業需要複寫至本機 Active Directory 站台，安裝程式才能順利完成。如果 PDC 不是位在本機 Active Directory 站台中，請確定 PDC 與本機 Active Directory 站台之間的 Active Directory 站台連結運作中。

    • 完成安裝程式復原處理程序之後，EXCMS1 已復原至 SITEB，而且現在是主控於單一節點 SCC (稱為 DRCLUS1) 中的 NODEC 上。

    • 因為進行叢集信箱伺服器復原作業，所以 EXCMS1 的 DNS TTL 已還原為預設值 20 分鐘。請執行下列命令，然後停止並啟動叢集信箱伺服器，將它設回五分鐘。

      Cluster.exe res EXCMS1 /priv HostRecordTTL=300

  5. 接下來，會使用 Mount-Database 工作來裝載這三個儲存群組中的資料庫。

  6. 因為 CAS2 及 HUB2 已存在於 SITEB 中，所以在此案例中不需要執行其他伺服器角色 (具體而言，即 Client Access 及 Hub Transport) 的復原作業。

    note附註：
    在進行 Client Access Server 的復原作業時，需要重新設定外部 URL，使其指向 SITEB 中的 Client Access Server。
    note附註：
    此範例案例不包含復原 Edge Transport Server。如果 Edge Transport Server 存在於 SITEA 上，而且也在站台失敗時遺失，則需要讓新的 Edge Transport Server 在 SITEB 上線，而且需要更新 Contoso 簡易郵件傳送通訊協定 (SMTP) 網域的郵件交換程式 (MX) DNS 記錄，使其指向新的 Edge Transport Server。

  7. 如果 Contoso 組織包含額外的 Active Directory 站台，則郵件會佇列至主要 Active Directory 站台。將 EXCMS1 的站台成員資格資訊複寫至其他所有 Active Directory 站台之後，就可以手動重試保有要送至主要站台之郵件的 SMTP 佇列 (如果未進行手動重試，則傳輸引擎會在 12 小時後自動重試佇列)。這樣會重新分類郵件。郵件重新分類之後，就會傳遞至 SITEB 中的 EXCMS1。

此時，只要用戶端及其他伺服器使用的 DNS 伺服器具有 EXCMS1 的正確 IP 位址，則所有用戶端應該都可以使用其原始存取方法 (例如，Microsoft Outlook Web Access、Exchange ActiveSync 及 Microsoft Office Outlook) 來存取其信箱。

主要站台重新設定

因為次要站台 (SITEB) 現在是作為主要資料中心，所以必須重新設定原始主要資料中心 (SITEA)，讓現在主控於 SITEB 的服務不會與在 SITEA 準備就緒可以啟動以供再次使用之後所啟動的服務產生衝突。您應該使用下列步驟，以系統管理員控制的方式讓 SITEA 恢復連線：

  1. 先讓目錄服務及 DNS 名稱解析服務恢復連線，方法是讓 DC1 恢復連線。

  2. 讓 DC1 恢復連線之後，請讓 CAS1 及 HUB1 恢復連線。

    請注意，讓 HUB1 恢復連線之後，系統管理員應該驗證其佇列中的所有郵件都已送出。如果郵件卡在佇列中，則使用下列命令，就可以重新進行提交。

    Retry-queue [queue name] -Resubmit $True

  3. 讓主控叢集 EXCLUS1 的節點恢復連線。在此案例中，是先讓 NODEA 恢復連線，然後再讓 NODEB 恢復連線。

  4. 兩個節點都恢復連線之後，叢集信箱伺服器仍然會保持在離線狀態。這包含構成叢集信箱伺服器的所有資源，尤其是它的網路名稱資源。因為 EXCMS1 已經恢復連線，而且使用相同的網路名稱，所以該資源無法恢復連線。讓 EXCMS1 在 NODEA 或 NODEB 上恢復連線，會導致網路上發生名稱衝突。

  5. 在目前擁有的資源群組中包含叢集信箱伺服器的節點上，系統管理員必須從容錯移轉叢集中清除叢集信箱伺服器及其資源。若要這樣做，系統管理員會先從含有叢集信箱伺服器的叢集群組中移除所有的非 Exchange 資源。然後，系統管理員會在 NODEA 上執行下列命令：

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

    請注意：

    • 從 EXCLUS1 中清除叢集信箱伺服器及其資源之後，建議您使用叢集系統管理員或容錯移轉叢集管理嵌入式管理單元，以驗證已移除所有叢集信箱伺服器資源。

    • EXCLUS1 現在是具有兩個被動節點 (NODEA 及 NODEB) 的容錯移轉叢集，而每個被動節點都已經安裝被動 Mailbox server role。此時，EXCLUS1 中沒有叢集信箱伺服器。

  6. 因為叢集節點正在執行 Windows Server 2008，在執行 Setup /ClearLocalCMS 之後，虛擬電腦物件 (VCO) 將會停用。若要重新啟用 VCO，請按一下 [開始]，依序指向 [所有程式] 及 [系統管理工具]，然後按一下 [Active Directory 使用者和電腦]。依序展開網域及 [電腦]，在 EXCMS1 VCO 上按一下滑鼠右鍵，然後按一下 [啟用帳戶]。

  7. 若要準備從 SITEB 至 SITEA 的受控制切換，則在 SITEB 中，會針對 NODEA 製作主控於 EXCMS1 之儲存群組的 SCR 目標。作法是在 NODEC 上使用下列命令：

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA
    note附註：
    如果原始容錯移轉叢集使用的儲存未受 SITEA 失敗影響，而且這三個儲存群組的原始資料庫及其交易記錄仍然存在於 NODEA 上，則可能可以使用它們來進行連續複寫，而不需要針對 NODEA 上的每個儲存群組執行完整重新植入。如果無法使用現有檔案，或原始叢集信箱伺服器設定了循環記錄，則必須執行 Update-StorageGroupCopy 指令程式，對每個儲存群組執行完整重新植入。

此案例使用 SCC 來進行示範。如果復原案例在叢集連續複寫 (CCR) 環境中改用叢集信箱伺服器，則建議執行額外的步驟，利用資料庫及記錄檔來分段被動節點，以另外為受控制切換準備被動節點。這個步驟只是要進行最佳化，以在將 CCR 環境移回 SITEA 之後，不需要再植入被動儲存群組。這項工作的執行方法有兩種：

  • 擱置這三個 SCR 目標的連線複寫，然後將儲存群組檔案及資料庫從 NODEA 複製至 NODEB 的適當位置。

  • 啟用 NODEB 作為 EXCMS1 的 SCR 目標。

受控制切換至原始主要站台

核准使用 SITEA 之後，就可以執行從 SITEB 至 SITEA 之資料及服務的手動及受控制切換。完成受控制切換所執行的步驟，實際上就是啟動 SITEB 時執行的反向步驟：

  1. 第一個步驟是卸載 EXCMS1 上的所有資料庫。這樣做是為了停止產生交易記錄檔，並準備在 NODEA 上啟動 SCR 目標。您可以使用 Exchange 管理主控台，或在 Exchange 管理命令介面中使用 Dismount-Database 指令程式，來卸載資料庫。

  2. 系統管理員在 NODEA 上準備要進行裝載的所有儲存群組。這項工作是透過執行下列命令來執行：

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA

    請注意：

    • 在上述三個命令中，因為可以使用 SCR 來源伺服器，所以沒有使用 Force 參數。因為未使用 Force 參數，所以工作會自動嘗試從 SCR 來源複製所有記錄檔。

    • 完成每個工作之後，系統管理員應該確認每個儲存群組的所有記錄檔都已經複製到 NODEA，而且已經停用 SCR。

    • 如果也已將 NODEB 設定為 SCR 目標，則需要先進行停用並還原，再繼續進行。在此案例中，建議您先後在 NODEB 及 NODEA 上執行 Restore-StorageGroupCopy，然後在 NODEA 上執行 Setup /RecoverCMS。

  3. 應該停止 DRCLUS1 上的叢集信箱伺服器 (EXCMS1)。此工作應該從 NODEC 執行，方法是使用 Exchange 管理主控台中的 [管理叢集信箱伺服器] 精靈，或在 Exchange 管理命令介面中使用 Stop-ClusteredMailboxServer 指令程式。

  4. 應該使用 DNS 管理嵌入式管理單元，從 DNS 移除 EXCMS1 的 A 記錄。

    note附註：
    只有在容錯移轉叢集是執行於 Windows Server 2008 時，才需要移除 EXCMS1 的 A 記錄。如果容錯移轉叢集是執行於 Windows Server 2003，則不需要執行此步驟。

  5. 使用安裝程式的 /RecoverCMS 選項，復原叢集信箱伺服器 (EXCMS1)。在 NODEA 上使用下列命令來執行復原後，就會立即進行復原：

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    請注意：

    • 上述命令中的 CMSIPAddress 值，可能是 EXCMS1 的原始 IP 位址。這是因為 EXCLUS1 會復原回它的原始位置。

    • 完成安裝程式復原處理程序之後，EXCMS1 已復原至 SITEA，而且現在是主控於雙節點 SCC (稱為 EXCLUS1) 中的 NODEA 上。

    note附註：
    同樣地，此案例使用 SCC 來進行示範。如果復原案例在 CCR 環境中改用叢集信箱伺服器，則可能需要執行額外的步驟。在此情況下，/RecoverCMS 作業會擱置從 NODEA 至 NODEB 的連續複寫。系統管理員必須執行 Resume-StorageGroupCopy，儲存群組才能再次建立複寫及重新顯示活動。然後，系統管理員應該確認該複寫活動是否已繼續進行。如果稍早所述的 NODEB 分段失敗，則需要重新植入儲存群組的被動副本。

    • 因為進行叢集信箱伺服器復原作業，所以 EXCMS1 的 DNS TTL 已還原為預設值 20 分鐘。請執行下列命令，然後停止並啟動叢集信箱伺服器，將它設回五分鐘：

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

  6. 使用 Mount-Database 指令程式來裝載這三個儲存群組中的資料庫。

  7. 因為 CAS1 及 HUB1 已存在於 SITEA 中，所以在此案例中不需要執行其他伺服器角色 (即 Client Access 及 Hub Transport) 的復原作業。

    note附註：
    在進行 Client Access Server 的復原作業時，需要重新設定外部 URL，使其指向 SITEA 中的 Client Access Server。
    note附註：
    此範例案例不包含復原 Edge Transport Server。如果 Edge Transport Server 在使用中，則需要更新 Contoso SMTP 網域的郵件交換程式 (MX) DNS 記錄，使其指向正確的 Edge Transport Server。

  8. 如果 Contoso 組織包含額外的 Active Directory 站台，則郵件會佇列於主要 Active Directory 站台中。將 EXCMS1 的站台成員資格資訊複寫至其他所有 Active Directory 站台之後，就可以手動重試保有要送至主要站台之郵件的 SMTP 佇列 (如果未進行手動重試，則傳輸引擎會在 12 小時後自動重試佇列)。這樣會重新分類郵件。郵件重新分類之後，就會傳遞至 SITEA 中的 EXCMS1。

  9. 此時，只要用戶端及其他伺服器使用的 DNS 伺服器具有 EXCMS1 的正確 IP 位址，則所有用戶端應該都可以使用其原始存取方法 (例如，Outlook Web Access、Exchange ActiveSync 及 Outlook) 來存取其信箱。此外，如果已將 DNS 變更複寫至 SITEB，而且已複寫 EXCMS1 的站台成員資格，則 Hub Transport Server 會將郵件路由傳送至正確的 Active Directory 站台。系統管理員也可以手動強制重新提交可能位在 HUB1 或 HUB2 之任何佇列中的郵件。而這項工作可以透過執行下列命令來執行：

    Retry-queue [queue name] -Resubmit $True

重新設定備份站台

完成從 SITEB 至 SITEA 的手動受控制切換之後，可以將 SITEB 回復為其作業狀態，作為備份資料中心。這包含從 SITEB 的容錯移轉叢集中清除待命叢集信箱伺服器，以及針對 EXCMS1 上的三個儲存群組，將 NODEC 重新啟用為 SCR 目標。這可以透過依序執行下列步驟完成：

  1. 在受控制切換期間，已停止在 SITEB 的 DRCLUS1 中執行的叢集信箱伺服器，讓它可以在 SITEA 的 EXCLUS1 上恢復連線。在 EXCLUS1 上順利讓 EXCMS1 重新連線工作之後，需要從 DRCLUS1 中移除它的組態資訊。從含有叢集信箱伺服器的叢集群組中移除所有的非 Exchange 資源，然後執行下列命令，就可以清除組態資訊，以及從 DRCLUS1 中完全移除 EXCMS1：

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

  2. 因為叢集節點正在執行 Windows Server 2008，在執行 Setup /ClearLocalCMS 之後，VCO 將會停用。若要重新啟用 VCO，請按一下 [開始]，依序指向 [所有程式] 及 [系統管理工具]，然後按一下 [Active Directory 使用者和電腦]。依序展開網域及 [電腦]，在 EXCMS1 VCO 上按一下滑鼠右鍵，然後按一下 [啟用帳戶]。

  3. 從 DRCLUS1 中清除叢集信箱伺服器及其資源之後，系統管理員應該使用叢集系統管理員或容錯移轉叢集管理嵌入式管理單元，以驗證已移除所有叢集信箱伺服器資源。

  4. 設定 SCR，讓交易記錄檔從 EXCMS1 的三個儲存群組複寫至 NODEC 的 SCR 目標中。而這是使用下列命令進行設定：

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC
    note附註：
    在啟用 SCR 將儲存群組從 EXCMS1 複寫至 NODEC 之前，您必須確定沒有儲存群組或資料庫路徑衝突存在。您也必須確定已從原始路徑中移除任何舊的與不需要的儲存群組及資料庫檔案。

  5. 接著使用 Test-ReplicationHealth 及 Get-StorageGroupCopyStatus 指令程式，驗證每個儲存群組的 SCR 健康狀況及狀態。在節點之間的叢集信箱伺服器移動，以及備份及記錄檔截斷，也應該驗證是否如預期運作。就 Exchange 2007 郵件系統而言，在所有驗證完成之後，主要資料中心及次要資料中心現在都已回到它們的原始作業模式。