規劃待命連續複寫

  • 發行項

 

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

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

雖然部署待命連續複寫 (SCR) 與部署本機連續複寫 (LCR) 類似，但是仍有一些重要的差異必須納入考量。SCR 有一些必須符合的一般需求。

待命連續複寫的一般需求

在為任何儲存群組啟用 SCR 之前，建議您先熟悉 SCR 來源及目標的下列需求：

  • 一個來源可以有多個目標。例如，來源可以有一個目標存在於與來源相同的資料中心，也可以有第二個目標存在於分隔的資料中心。每個來源可以擁有的目標數量，並没有限制。然而，建議每個來源不要使用四個以上的目標。如果設定四個以上的目標，則需要驗證對來源伺服器造成的額外影響，並視情況進行規劃。

  • 每個目標都可以有多個來源伺服器。來源及目標系統都必須執行 Exchange 2007 SP1。作業系統可以是 Exchange 2007 SP1 支援的任何作業系統 (例如，Windows Server 2008 或 Windows Server 2003)；不過，所有 SCR 目標電腦所執行的作業系統必須與其 SCR 來源電腦相同。不支援 SCR 來源及其目標使用不同的作業系統 (例如，SCR 來源是 Windows Server 2003，而 SCR 目標是 Windows Server 2008，反之亦然)。

  • SCR 目標電腦上必須已安裝 Exchange 2007 SP1 Mailbox server role。如果 SCR 目標電腦是叢集節點，則節點必須是被動節點 (例如，已安裝被動叢集信箱角色)，而叢集不能包含任何叢集信箱伺服器。

  • 在使用 SCR 時，若您打算使用待命叢集和叢集信箱伺服器復原功能 (Setup /RecoverCMS) 作為 SCR 目標的啟動程序的一部份，就必須更小心規劃 Exchange Server 安裝路徑。若要使用伺服器復原處理程序，SCR 來源電腦與 SCR 目標電腦的 Exchange Server 安裝路徑必須相同。如果 Exchange Server 是安裝至 SCR 來源電腦的 %ProgramFiles%\Microsoft\Exchange Server 中，則也必須將其安裝至將作為 SCR 來源伺服器之 SCR 目標的所有電腦上的 %ProgramFiles%\Microsoft\Exchange Server 中。如果這些安裝路徑不相符，Setup /RecoverCMS 會安裝失敗，因為登錄中的安裝路徑不符合 Active Directory 目錄服務中 Mailbox Server 物件的 msExchInstallPath 屬性值。

  • 如果啟動程序包含復原叢集信箱伺服器，在使用 Setup /RecoverCMS 作為啟動程序的一部分之前，您必須先停用叢集信箱伺服器上所有儲存群組的 SCR。如果未停用所有儲存群組的 SCR，Setup /RecoverCMS 就會失敗。

  • SCR 來源及所有目標上的儲存群組及資料庫路徑，不得與任何其他儲存群組或資料庫路徑有衝突。使用 SCR 時，必須更小心地規劃儲存群組及資料庫路徑，因為 SCR 來源所使用的儲存群組及資料庫路徑會用於來源之所有 SCR 目標上的儲存群組及資料庫副本。

  • SCR 來源及 SCR 目標電腦都必須在相同的 Active Directory 網域中，但是它們可以位於相同或不同的 Active Directory 站台中。

  • 當使用 Exchange 2007 Enterprise Edition 時，每個目標電腦最多支援 50 個 SCR 目標 (50 個複寫的儲存群組)，而當使用 Exchange 2007 Standard Edition 時，最多則支援 5 個 SCR 目標。

對 SCR 目標電腦的限制

當被動節點或獨立 Mailbox Server 設定為 SCR 目標時，下列功能會遭到封鎖：

  • 指定為 SCR 目標的獨立 Mailbox Server 不能對任何儲存群組啟用 LCR。Microsoft Exchange 複寫服務並未設計或修改為可以同時管理 LCR 及其他來源的複寫。

  • 已指定為 SCR 目標的被動節點必須是没有任何叢集信箱伺服器的容錯移轉叢集的成員之一。這指的是「待命叢集」。如需待命叢集的相關資訊，請參閱高可用性。

SCR 及公用資料夾資料庫

SCR 與公用資料夾複寫是兩項形式迥異的 Exchange 內建複寫功能。受限於連續複寫與公用資料夾複寫之間的交互操作性限制，如果 Exchange 組織中的多個 Mailbox Server 具有公用資料夾資料庫，則會啟用公用資料夾複寫，而 SCR 環境中不應有公用資料夾資料庫。

note附註：
因為資料庫可攜性只可以與信箱資料庫搭配使用，所以公用資料夾資料庫之 SCR 目標副本的啟用只有在伺服器或叢集信箱伺服器復原作業時才能執行 (例如，Setup /m:recoverServer 或 Setup /recoverCMS)。

在 Exchange 組織中使用公用資料夾資料庫與 SCR 時，建議您考量下列組態：

  • 如果 Exchange 組織中有單一 Mailbox Server，且該 Mailbox Server 是 SCC 中的獨立 Mailbox Server 或叢集信箱伺服器，則 Mailbox Server 可以主控公用資料夾資料庫，而且可以針對 SCR 啟用含有公用資料夾資料庫的儲存群組，但前提是未針對 LCR 啟用該儲存群組。在此組態中，Exchange 組織中有單一的公用資料夾資料庫。因此，會停用公用資料夾複寫。在此案例中，公用資料夾資料庫的備援是使用 SCR 來達成，SCR 會維持兩份公用資料夾資料庫。

  • 如果您有多部 Mailbox Server，但只有一部 Mailbox Server 包含公用資料夾資料庫，而且該 Mailbox Server 是 SCC 中的獨立 Mailbox Server 或叢集信箱伺服器，則 Mailbox Server 可以主控公用資料夾資料庫，而且可以針對 SCR 啟用含有公用資料夾資料庫的儲存群組，但前提是未針對 LCR 啟用該儲存群組。在此組態中，Exchange 組織中有單一的公用資料夾資料庫。因此，會停用公用資料夾複寫。在此案例中，公用資料夾資料庫的備援也是使用 SCR 來達成。

  • 如果要將公用資料夾的資料遷移至針對 SCR 啟用的儲存群組，您可以使用公用資料夾複寫，將公用資料夾資料庫的內容從 SCC 中的獨立 Mailbox Server 或叢集信箱伺服器移至啟用 SCR 的 儲存群組。複寫順利完成後，所有位於啟用 SCR 之儲存群組外的公用資料夾資料庫均應移除，且 Exchange 組織中不應有任何其他的公用資料夾資料庫。

  • 如果要將公用資料夾的資料遷移出針對 SCR 啟用的儲存群組，您可以使用公用資料夾複寫，將公用資料夾資料庫的內容從儲存群組移至 SCC 中的獨立 Mailbox Server 或叢集信箱伺服器。複寫順利完成後，所有啟用 SCR 之儲存群組內的所有公用資料夾資料庫均應移除，且所有後續的公用資料夾資料庫皆不應保存在啟用 SCR 的儲存群組中。

在 Exchange 組織中有多個公用資料夾資料庫以及一或多個公用資料夾資料庫主控於針對 SCR 啟用之儲存群組的任何期間，如果 SCR 來源儲存群組發生失敗，且需要啟動 SCR 目標公用資料夾資料庫，則只有在可以取得主控公用資料夾資料庫之儲存群組的所有記錄時，才可以進行裝載。如果任何記錄因 SCR 來源失敗而遺失或無法取得，則您將無法啟動公用資料夾資料庫的 SCR 目標副本。此時，必須使 SCR 來源上線以確保不會遺失任何資料，或是必須在 SCR 來源上重新建立公用資料夾資料庫，而且必須使用公用資料夾複寫從非 SCR 目標副本的公用資料夾資料庫中復原其內容。

SCR 和備份

您無法備份 SCR 目標副本。LCR 和 CCR 都支援從主動及被動副本中備份。SCR 只支援 SCR 來源的備份。若對 SCR 來源儲存群組進行支援的備份，則會更新 SCR 目標的資料庫標頭並截斷記錄檔。若對 CCR 或 LCR 啟用了 SCR 來源儲存群組，則在對 SCR 來源儲存群組的主動或被動副本進行備份時，會更新 SCR 目標的資料庫標頭並截斷記錄檔。

SCR 和還原

當 SCR 來源資料庫是以舊版的資料庫來取代時，您必須分別使用 Suspend-StorageGroupCopy 及 Resume-StorageGroupCopy 先暫停然後繼續儲存群組的連續複寫。必須執行此程序，才能以正確的記錄檔產生資訊更新 Microsoft Exchange 複寫服務。如果未先暫停然後繼續連續複寫，複寫服務將會有過時的記錄檔產生資訊並停止複寫記錄檔。

SCR 和記錄檔截斷

在 Exchange 2007 RTM 中，已強制實施規則，因此，在連續複寫環境中，除非已經備份記錄檔並將它重新顯示至資料庫的副本，否則就不會刪除記錄檔。使用 SCR 時會修改此規則。SCR (引進多個資料庫副本的概念) 允許 SCR 來源的記錄檔一旦被所有 SCR 目標電腦發現之後即截斷。SCR 來源上的記錄截斷作業會等到所有記錄都重新顯示至所有 SCR 目標之後才會進行，因為 SCR 目標副本可以設定為具有較久的記錄重新顯示延遲。但是，如果一或多個儲存群組的 SCR 目標關機，則 SCR 來源上的記錄檔截斷將不會發生。為了在 SCR 來源上截斷記錄，SCR 目標電腦必須先上線，且可供來源存取。

在 SCR 目標上，背景執行緒每三分鐘執行一次，以判斷是否有任何記錄檔需要截斷。如果符合下列三個條件，就會截斷 SCR 目標上的記錄檔：

  • SCR 來源上的記錄檔已截斷。

  • 記錄檔產生順序低於儲存群組的記錄檔檢查點。

  • 記錄檔比 ReplayLagTime + TruncationLagTime 更舊 (如需這些參數的說明，請參閱主題待命連續複寫中＜SCR 的指令程式更新＞)。

在以 SCR 擴充的 LCR 或 CCR 環境中，如果符合下列三個條件，則 LCR 或 CCR 環境中的主動和被動副本上的記錄檔就會遭到截斷：

  • 已備份記錄檔。

  • 記錄檔產生順序低於儲存群組的記錄檔檢查點。

  • 所有 SCR 目標都發現到記錄檔。

針對 SCR 最佳化 Windows 2003 網路

雖然在 Windows Server 2008 上使用 SCR 時不需要網路最佳化，但是在 Windows Server 2003 上使用 SCR 時，建議您針對特定網路連結的速度和延遲來最佳化 Windows Server TCP/IP 設定。尤其是，您可能需要在 SCR 來源電腦及其 SCR 目標電腦上，調整傳輸控制通訊協定 (TCP) 接收視窗大小及要求建議 (RFC) 1323 視窗調整選項。此外，您會發現它對設定位址解析通訊協定 (ARP) 快取到期設定，及停用 Windows 登錄中 Windows Server 2003 可調整網路套件 (SNP) 的進階 TCP/IP 選項有所幫助。

除了這些建議之外，如果您的環境中包含 IP 安全性 (IPsec) 通訊協定的使用，建議您在整個 SCR 環境中一致設定 IPsec。SCR 來源及其所有的 SCR 目標都應使用 IPsec，或者 SCR 來源或其任何的目標都不應使用 IPSec。如果只有一個節點設定為使用 IPsec，IPsec 安全性關聯程序可能會導致封包延遲或封包遺失。

TCP 接收視窗及 RFC 1323 調整選項

TCP 接收視窗大小為一個連線一次可以接收的最大資料量 (以位元組為單位)。在等候來自接收方電腦之認可及 TCP 視窗更新之前，傳送方電腦只能傳送該最大資料量。調整此設定，以提高記錄傳送期間的輸送量可能會對有所幫助。

若要最佳化 TCP 輸送量，傳送方電腦應該傳輸足夠的封包，以填滿傳送方與接收方之間的管線。網路管線的容量是根據管線的頻寬與其延遲 (來回時間) 而定。因為在認可之間有更多時間可以傳送資料，所以延遲愈高，容量就愈多。增加 TCP 視窗大小，系統就可以利用認可之間的時間來傳送更多資料。

TCP/IP 標準最多可讓接收視窗大小達到 65,535 八位元資料組，這是在 16 位元 TCP 視窗大小欄位中可以指定的最大值。為改善高頻寬、高延遲網路的效能，藉由使用如 RFC 1323 中所述「高效能的 TCP 延伸」的可調整視窗，Windows Server TCP/IP 即可支援通告大小大於 65,535 八位元組資料的接收視窗。在使用視窗調整時，交談中的主機可以交涉允許多個大型封包 (例如通常用於檔案傳送通訊協定的那些封包) 的視窗大小，以擱置於使用者的緩衝區。RFC 1323 詳述一種方法，可透過允許 TCP 在連線建立時交涉視窗大小的調整因素，以支援較大的接收視窗大小。

您可以藉由修改兩個登錄項目，最佳化位於執行 Windows Server 2003 之電腦上的 TCP 接收視窗大小及 RFC 1323 視窗調整選項：TCPWindowSize 及 TCP1323Opts。如需這些功能的相關資訊，請參閱 Microsoft 知識庫文章 224829 Windows 2000 及 Windows Server 2003 TCP 功能的說明。

建議您使用第 13 版或更新版本的 Exchange 2007 Mailbox Server Role 儲存需求計算器，以根據網路連結與網路延遲來決定這些登錄項目的最佳化設定。若要下載計算器，請參閱 Exchange 團隊部落格中的 Exchange 2007 Mailbox Server Role 儲存需求計算器 (英文)。儲存計算器也包含在伺服器上輸入登錄值的逐步指示。

note附註：
UNRESOLVED_TOKEN_VAL(exBlog)

ARP 快取到期

ARP 快取是一個記憶體內部表格，可以將 IP 位址對應到媒體存取控制 (MAC) 位址。ARP 快取中的項目會在每次輸出封包傳送至項目中的 IP 位址時加以參照。依預設，Windows Server 2003 會自動調整 ARP 快取的大小，以符合系統需求。如果項目持續兩分鐘未由任何外送資料包使用，該項目就會從 ARP 快取中移除。正在參照的項目會在十分鐘之後從 ARP 快取中移除。手動新增的項目不會自動從快取中移除。

Microsoft 內部 IT 部門所進行的內部測試顯示，預設的 ARP 快取到期設定會導致 CCR 及 SCR 環境中的封包遺失。發生封包遺失時，傳送方伺服器必須再次傳輸遺失的資料。在連續複寫的環境中，由於遺失的封包對記錄傳送輸送量有負面的影響，因此盡快將記錄檔複製到被動節點，並再次傳輸資料很重要。

您可以修改 Windows 登錄中的 ArpCacheMinReferencedLife TCP/IP 參數來控制 ARP 快取到期。此參數可決定在刪除受參照的項目之前，必須將它保留在 ARP 快取表中的時間。Microsoft 內部發現 ArpCacheMinReferencedLife 登錄值的最佳化設定，是使用與網路上的路由器用於 ARP 快取到期的相同值，也就是 4 小時。

在您自己的環境中修改 ArpCacheMinReferencedLife 值之前，建議使用 Microsoft Network Monitor 或類似的擷取工具，收集和分析用來將記錄從主動節點複製到被動節點之網路介面上的網路流量。如需修改 ArpCacheMinReferencedLife 登錄值的詳細步驟，請參閱 Appendix A: TCP/IP Configuration Parameters (英文)。

可調整網路套件進階 TCP/IP 功能

Windows Server 2003 可調整網路套件 (SNP) 是針對 Windows Server 2003 的個別更新，包含了可設定狀態及無狀態的卸載，以加速 Windows 網路堆疊。更新包含 TCP Chimney 卸載、接收端調整 (RSS)，以及 Network Direct Memory Access (NetDMA)。

TCP Chimney 是一種可設定狀態的卸載。TCP Chimney 卸載可讓 TCP/IP 處理卸載至可在硬體中處理 TCP/IP 處理的網路介面卡。

RSS 及 NetDMA 為無狀態的卸載。在具有多個 CPU 的單一電腦中，Windows 網路堆疊會將「接收」通訊協定處理限制在單一 CPU。RSS 透過將自網路介面卡接收的封包平均分配給多個 CPU 解決了此問題。NetDMA 可允許周邊元件連接 (PCI) 匯流排上有直接記憶體存取 (DMA) 引擎。TCP/IP 堆疊可以使用 DMA 引擎來複製資料，而不會中斷 CPU 來處理複製作業。相關的元件 TCPA 是另一個卸載功能，在此可以使用 PCI 匯流排上的硬體 DMA 引擎，來協助接收程序。

雖然這些功能在某些環境中可提供網路效能方面的優點，但是在某些情況下卻無法使用，因為使用到其他技術。例如，如果使用了下列任何技術，TCP Chimney 卸載及 NetDMA 就會無法使用：

  • Windows 防火牆

  • 網際網路通訊協定安全性 (IPsec)

  • 網際網路通訊協定網路位址轉譯 (IPNAT)

  • 協力廠商防火牆

  • NDIS 5.1 中繼驅動程式

此外，在某些環境 (包含使用 Microsoft Exchange 的環境) 中有已知的問題，使用這些功能時網路效能會降低。如需其中部份問題的詳細資訊，請參閱 Exchange 團隊部落格的張貼，Windows 2003 可調整網路套件以及對 Exchange 可能的影響 (英文)。

note附註：
UNRESOLVED_TOKEN_VAL(exBlog)

建議您針對系統中的作業系統及每個網路介面卡 (NIC)，將在 Windows Server 2003 作業系統上執行之 SCR 環境的所有功能停用。您可以按照下列程序停用這些功能：

如需 SNP 的相關資訊，請參閱知識庫文章 912222 Microsoft Windows Server 2003 可調整網路套件版本，以及可調整網路 (英文) 網站。