規劃叢集連續複寫

 

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

上次修改主題的時間: 2008-07-23

雖然部署叢集連續複寫 (CCR) 與部署本機連續複寫 (LCR) 類似,也與部署單一副本叢集 (SCC) 類似,但是仍有一些重要的差異必須納入考量。CCR 有一些必須符合的一般需求,也有必須符合的硬體、軟體、網路功能及叢集需求。

叢集連續複寫的一般需求

在您部署 CCR 之前,請確定符合以下全系統的需求:

  • 每個儲存群組必須使用單一的資料庫。在 CCR 環境中建立儲存群組時,只能包含一個資料庫。這個方法可以建立更容易管理的 Microsoft Exchange 儲存拓撲,以增加復原能力。

  • 必須執行網域名稱系統 (DNS)。理想的情況是,DNS 伺服器應接受動態更新。如果 DNS 伺服器不接受動態更新,您必須為每一個叢集信箱伺服器建立一個 DNS 主機 (A) 記錄,並為叢集本身建立一個 DNS 主機 (A) 記錄。否則,Exchange 無法正常運作。如需如何設定 Exchange 所需之 DNS 的相關資訊,請參閱 Microsoft 知識庫文章 322856 如何設定 Exchange Server 所需的 DNS

  • 如果您的叢集節點所屬之目錄命名服務區的名稱與電腦所加入的 Active Directory 目錄服務網域名稱不同,依預設,DNSHostName 內容將不包含子網域名稱。在此情況下,您可能需要變更 DNSHostName 內容以確保某些服務可正常運作,例如「檔案複寫服務」(FRS)。如需相關資訊,請參閱知識庫文章 240942 Active Directory DNSHostName 內容不包含子網域

  • 所有叢集節點必須是相同網域中的成員伺服器。在同時也是 Active Directory 伺服器的節點,或是不同 Active Directory 網域之成員的節點上,Microsoft Exchange Server 2007 不受支援。

  • 必須在安裝 Exchange 2007 之前形成叢集。如需形成 Windows Server 2008 容錯移轉叢集的相關資訊,請參閱在 Windows Server 2008 上安裝叢集連續複寫。如需形成 Windows Server 2003 容錯移轉叢集的相關資訊,請參閱安裝單一複本叢集

  • 叢集信箱伺服器 (CMS) 名稱必須在 15 個字元以內。

  • 安裝 Exchange 2007 的叢集中不能包含 Exchange Server 2003、Exchange 2000 Server 或任何版本的叢集感知 Microsoft SQL Server。不支援在具有這些任一應用程式的叢集裡執行 Exchange 2007。您可以在具有 SQL Server 2005 Express Edition 或其他資料庫應用程式 (例如 Microsoft Office Access) 的叢集中執行 Exchange 2007,條件是資料庫應用程式未經叢集處理。

  • 安裝 Exchange 2007 前,請先確定要安裝 Exchange 資料的資料夾是空的。

  • 您必須針對叢集中設為叢集信箱伺服器主機的所有節點上,安裝相同版本的 Exchange 2007。此外,叢集中所有節點的作業系統和 Exchange 檔案必須安裝在相同的路徑和磁碟機上。這需要所有電腦都具有類似 (但不相同) 的磁碟組態。

  • 叢集服務帳戶必須是能主控叢集信箱伺服器之每一個節點上的本機 Administrators 群組的成員。

  • 請勿從預設叢集群組安裝、建立或移動任何資源到包含叢集信箱伺服器的資源群組。此外,請勿從包含叢集信箱伺服器的群組安裝、建立或移動任何資源到預設叢集群組。預設叢集群組應該只包含叢集 IP 位址、網路名稱及仲裁資源。對預設叢集群組移動或結合資源都是不受支援的。

    important重要事項:
    執行舊版 Exchange 的叢集需要 Microsoft Distributed Transaction Coordinator (MSDTC) 的叢集執行個體。Exchange 2007 移除了對叢集 MSDTC 資源的需求。CCR 環境中的叢集信箱伺服器不使用 MSDTC 資源,也不需在容錯移轉叢集中安裝此資源。協力廠商應用程式可能會因 COM+ 相依性而需要 MSDTC 資源。在 Windows Server 2003 中,MSDTC 叢集資源在叢集中必須使用共用儲存。不建議您將共用儲存新增至 CCR 環境中。Windows Server 2008 所提供的本機、非叢集 MSDTC 執行個體,可免除在 Windows Server 2008 容錯移轉叢集中使用共用儲存的必要。如需 Windows Server 2008 中之 MSDTC 變更的相關資訊,請參閱 Windows Server 2008 說明。

叢集連續複寫的硬體需求

如需一般硬體規劃資訊,請參閱規劃處理器組態規劃磁碟儲存。CCR 環境特有的硬體需求如下:

  • 在 Windows Server 2003 上將多數節點集 (MNS) 仲裁與檔案共用見證搭配使用時,叢集中只能有兩個節點。如果叢集中只有一個節點或是超過兩個節點,則無法使用 MNS 仲裁的檔案共用見證功能。您必須改用叢集中必須有三個或超過三個節點的傳統 MNS 仲裁。

  • 在 Windows Server 2008 上使用節點及檔案共用多數仲裁時,叢集裡只能有兩個節點。如果叢集中只有一個節點或是超過兩個節點,則無法使用節點及檔案共用多數仲裁。您必須改用叢集中必須有三個或超過三個節點的節點多數仲裁。

    note附註:
    我們建議使用雙節點的容錯移轉叢集,這使用 MNS 仲裁的檔案共用見證或是節點及檔案共用多數仲裁。如此便不需要在叢集中有第三個 Voter 節點。
  • 使用的伺服器必須列在其將安裝所在作業系統的「已測試產品的 Microsoft Windows Server Catalog」。然而,如果叢集中未使用共用儲存,伺服器便不需要列在「叢集」類別中。

  • 主控 Mailbox server role 的兩部伺服器必須相當,但下列各項不同:

    • CPU

    • 記憶體

    • 輸入/輸出 (I/O) 容量

    • 網路功能

    • 廠商

    • 可用的磁碟儲存,包括空間和 I/O 作業能力

叢集連續複寫的仲裁需求

一般說來,叢集應用程式不會察覺其安裝所在叢集使用的仲裁類型。在設定您 CCR 環境的仲裁元件時,請了解下列建議與需求:

  • 在 Windows Server 2008 上,強烈建議的 CCR 仲裁類型為節點及檔案共用多數仲裁。

  • 在 Windows Server 2003 上,強烈建議的 CCR 仲裁類型為具有檔案共用見證的 MNS 仲裁。

如果針對 CCR 使用了前述任一種仲裁類型,節點不必列於「已測試產品的 Microsoft Windows Server Catalog」。

如果針對 CCR 使用共用儲存仲裁,則整個系統必須列於「已測試產品的 Microsoft Windows Server Catalog」。

在 Exchange Server 2007 Service Pack 1 (SP1) 中,如果未設定檔案共用見證或檔案共用多數,則安裝程式會封鎖兩個節點的叢集組態。這是因為組態將無法處理叢集中遺失一個節點的情況 (因為無法維持多數),而導致叢集離線。

叢集連續複寫的軟體需求

CCR 環境的軟體需求如下:

  • 叢集中的兩個節點必須使用相同的開機和系統磁碟機代號,在每個叢集節點上安裝 Windows Server 2008 Enterprise 作業系統或 Windows Server 2003 Enterprise Edition 作業系統。叢集中不能有一個節點執行 Windows Server 2008 而另一個節點執行 Windows Server 2003。不支援在容錯移轉叢集中混合作業系統版本。

  • 如果在 Windows Server 2003 上使用 Exchange 2007 的量產發行 (RTM) 版本建置 CCR 環境,則容錯移轉叢集中的兩個節點都必須安裝 Windows Server 2003 Service Pack 2 (SP2),或 Windows Server 2003 SP1 以及知識庫文章 921181 有更新可將檔案共用見證功能及可設定的叢集活動訊號功能新增到 Windows Server 2003 Service Pack 1 型伺服器叢集 (英文) 中的 Hotfix。此 Hotfix 隨附於 Windows Server 2003 SP2 中。如果使用 Exchange 2007 SP1 在 Windows Server 2003 上建置 CCR 環境,則容錯移轉叢集中的兩個節點都必須安裝 Windows Server 2003 SP2。

  • 該叢集必須是含有傳統 MNS 仲裁的三節點叢集,或是具有含檔案共用見證之 MNS 仲裁的二個節點叢集。一般而言,假設在 Windows Server 2003 上,兩個節點的叢集將使用具有檔案共用見證的 MNS 仲裁,而在 Windows Server 2008 上,兩個節點的叢集將使用節點及檔案共用多數仲裁。

  • MNS 仲裁的檔案共用見證或檔案共用多數仲裁不需要在專用電腦上。它可以在任何執行 Windows Server 的電腦上。不過,建議您在由 Exchange 系統管理員控制的 Hub Transport Server (或其他 Exchange Server) 上主控檔案共用見證。

  • 叢集內只能安裝 Mailbox server role。其他的伺服器角色都不能安裝在屬於容錯移轉叢集一部份的電腦上。

叢集連續複寫的網路需求

正確地設定用戶端與叢集通訊時使用的網路組態是相當重要的。本節提供用於驗證私人和公用網路設定是否正確之必要程序的連結。此外,您必須確定網路連線順序已針對叢集正確地設定。在設計 CCR 環境的網路基礎結構時,請考慮下列各項:

  • 每個節點必須至少有兩個網路介面卡可用於 Windows 叢集。用戶端及其他伺服器都必須能夠從這兩個網路介面卡中的一個來存取節點。其他的網路介面卡則是用於叢集內部的通訊。建議的組態是使私人網路專供內部叢集通訊使用,而將公用網路指定為混合。

  • 叢集公用網路應該提供對其他 Exchange 伺服器及其他服務 (例如 Active Directory 和 DNS) 的連線。您可以使用網路介面卡聯組或類似的技術,以避免這成為單點失敗。

  • 必須提供個別的叢集私人網路。私人網路是用於叢集活動訊號。私人網路不需要 DNS。

  • 活動訊號需求並不是雙資料中心組態最嚴格的公用網路頻寬及延遲需求。您必須評估網路總負載 (包括用戶端存取、Active Directory、傳輸、連續複寫和其他應用程式流量) 來判定環境所需的網路需求。

  • 建議您在 CCR 環境使用 Gigabit Ethernet,以充分延長重新植入時間。如需有關為何建議 Gigabit Ethernet 的詳細資訊,請參閱本主題稍後的<資料庫大小及叢集連續複寫>。

  • 在 Exchange 2007 RTM 中,包含叢集信箱伺服器的資源群組只能有一個網路名稱資源。Exchange 2007 RTM 不支援包含叢集信箱伺服器的資源群組有多個網路名稱資源。然而,Exchange 2007 SP1 並沒有此項限制。叢集信箱伺服器升級到 Exchange 2007 SP1 後,包含叢集信箱伺服器的資源群組可以有多個網路名稱資源。

在 Windows Server 2008 上安裝 CCR 的網路需求

在 Windows Server 2008 上安裝 CCR 的網路需求,與在 Windows Server 2003 上安裝 CCR 的需求略有不同。與 Windows Server 2003 相同,在 Windows Server 2008 上安裝 CCR 時,兩個節點與叢集信箱伺服器 (CMS) 都必須要有足夠的 IP 位址可使用。但 Windows Server 2008 另外具有某些在 Windows Server 2003 上無法使用的選項:

  • 叢集節點可位於不同的子網路上。在 Windows Server 2003 中,每個節點上各個網路的網路介面都必須與其他節點上的對應網路位於相同的子網路上。Windows Server 2008 則無此需求。因此,容錯移轉叢集內的節點可透過各個網路路由器進行通訊,而不需使用虛擬 LAN (VLAN) 技術連接節點。

  • 在 CCR 環境中使用多重子網路時,若節點間的 CMS 出現容錯移轉或遞交的情形,DNS 複寫即可能影響到用戶端重新連接至 CMS 的功能。與已變更 IP 位址的叢集信箱伺服器通訊的用戶端與其他伺服器,必須在 DNS 已使用新的 IP 位址進行更新,且本機 DNS 快取已更新後,才能重新建立與叢集信箱伺服器的通訊。若要盡可能縮短用戶端與其他伺服器辨識 DNS 存留時間 (TTL) 變更所需的時間,建議您將叢集信箱伺服器之網路名稱資源的 DNS TTL 值設定為五分鐘。在大部分的環境中,建議您僅設定 CMS 網路名稱資源的 DNS TTL 值。但環境中若有非 Exchange 管理工具使用叢集名稱連接至叢集以進行管理作業,建議您為叢集的網路名稱資源設定較低的 TTL 值。如需如何為網路名稱資源設定 DNS TTL 值,以供多重子網路 CMS 或待命叢集部署使用,請參閱如何為網路名稱資源設定 DNS TTL 值

  • 在 Windows Server 2008 容錯移轉叢集,叢集 IP 位址資源可以從 動態主機設定通訊協定 (DHCP) 伺服器取得其位址,也可以透過靜態項目取得。如果叢集節點本身已設定為從 DHCP 伺服器取得 IP 位址,則預設會自動為所有叢集 IP 位址資源取得 IP 位址。如果叢集節點已靜態地指派 IP 位址,則也必須以靜態 IP 位址來設定叢集 IP 位址資源。因此,叢集 IP 位址資源 IP 位址指派遵循實體節點和節點上每一個特定介面的組態。建議您不要對叢集信箱伺服器使用 DHCP。建議您對 CMS 使用 DHCP 之前,應考量下列事項:

    • 叢集服務在 IP 位址變更後,將不會使已啟用 DHCP 的 IP 位址資源上線。

    • DHCP 伺服器應進行設定,為叢集信箱伺服器所使用的所有 DHCP 指派位址授與無限制租用權。

  • Windows Server 2008 及其叢集服務亦支援網際網路通訊協定第 6 版 (IPv6)。這包括在叢集中單獨或同時支援 IPv6 IP 位址資源和 IPv4 IP 位址資源。此外,容錯移轉叢集也支援站台內部自動通道位址通訊協定 (Intra-Site Automatic Tunneling Addressing Protocol, ISATAP),但僅支援允許在 DNS 中動態登錄的 IPv6 (AAAA 主機記錄和 IP6.ARPA 反向查閱區)。只有在 Exchange 2007 SP1 已部署在執行 Windows Server 2008 的電腦上、該電腦已啟用 IPv6 與 IPv4,且網路同時支援這兩個 IP 位址版本時,才支援使用 IPv6 位址和 IP 位址範圍。如果在此組態中部署 Exchange 2007 SP1,則所有伺服器角色都可以對使用 IPv6 位址的裝置、伺服器及用戶端來傳送資料和接收資料。Windows Server 2008 的預設安裝會啟用對 IPv4 和 IPv6 的支援。如果 Exchange 2007 SP1 安裝在 Windows Server 2003 上,則不支援 IPv6 位址。如需 Exchange 2007 SP1 對 IPv6 位址的支援的相關資訊,請參閱 Exchange 2007 SP1 和 SP2 中的 IPv6 支援

在 Windows Server 2003 上安裝 CCR 的網路需求

如果要在 Windows Server 2003 上安裝 CCR,則在雙節點 CCR 環境中建立叢集信箱伺服器時,必須要有足夠數量的靜態 IP 位址可用。叢集與叢集信箱伺服器都必須要有 IP 位址。此外,各節點的公用及私人網路也都需要 IP 位址:

  • 私人位址   每個節點都需要一個靜態 IP 位址,以供用於叢集私人網路的每個網路介面卡使用。您必須使用不在相同子網路或網路上的靜態 IP 位址,作為公用網路的其中一個靜態 IP 位址。建議您使用 10.10.10.10 及 10.10.10.11 搭配 255.255.255.0 子網路遮罩,分別作為兩個節點的私人 IP 位址。如果您的公用網路使用 10.x.x.x 網路及 255.255.255.0 子網路遮罩,建議您使用其他私人網路 IP 位址及子網路遮罩。如果設定多個私人網路,則每一個私人網路介面卡和網路都需要唯一的位址和子網路。

  • 公用位址   每個節點都需要一個靜態 IP 位址,以供用於叢集公用網路的每個網路介面卡使用。此外,伺服器叢集及叢集信箱伺服器也需要靜態 IP 位址,以便用戶端及系統管理員可以對他們進行存取。您必須使用不在相同子網路或網路上的靜態 IP 位址,作為私人網路的其中一個靜態 IP 位址。

叢集中所有節點的私人網路必須位於相同的子網路上,但是您可以在兩個節點之間的相互連線上使用 VLAN 交換器。若您使用 VLAN,則點對點的來回延遲必須小於 0.5 秒。此外,從節點上執行的 Windows Server 2003 作業系統角度來看,兩個節點之間的連結必須是單一的點對點連線。為了避免發生單點失敗,請使用獨立的 VLAN 硬體來在節點之間提供不同的路徑。相同的子網路限制並不適用於在 Windows Server 2008 上執行的容錯移轉叢集。

叢集裡所有節點的公用網路必須位於相同的子網路上,但必須使用與用於私人網路之子網路不同的子網路。相同的子網路限制並不適用於在 Windows Server 2008 上執行的容錯移轉叢集。

您必須設定 Windows 中的叢集網路連線順序,使公用網路位於連線順序清單的最上方,而叢集中的網路優先順序則應設成私人網路是列為最優先的順序。

如果在多資料中心組態的 Windows Server 2003 上安裝 CCR:

  • 用戶端存取用的所有網路必須提供足夠的頻寬,且延遲必須夠低,才能讓用戶端從任一資料中心存取叢集信箱伺服器。

  • 用來複寫交易記錄的所有網路也必須提供足夠的頻寬,且延遲必須夠低,才能即時地複製記錄檔,以便儘可能地避免記錄檔積存。

  • 用於叢集活動訊號的網路必須能夠在所要求的重試設定次數之內,傳送及接收活動訊號封包。如果要將 CCR 安裝在 Windows Server 2003 SP2 或 Windows Server 2003 SP1 以及知識庫文章 921181 有更新可將檔案共用見證功能及可設定的叢集活動訊號功能新增到 Windows Server 2003 Service Pack 1 型伺服器叢集 (英文) 中的 Hotfix,則遺失的介面活動訊號重試及遺失的節點活動訊號重試會公開為叢集組態內容。如果是在 Windows Server 2008 上安裝 CCR,則不需要此更新。在這兩種情況下,仍會每 1.2 秒傳送一次活動訊號,但是可將叢集設定為必須發生更多的遺失事件 (無論是因為捨棄封包、延遲過多、介面故障或節點故障),才能採取任何復原動作。內容值的單位為遺失的活動訊號,而不是經歷的時間。所以不能將叢集設定為 5 秒之後懷疑介面故障。您可以將它設定為 5 次遺失之後懷疑介面故障,而依據在活動訊號期間實際發生故障的時間點,5 次遺失大約是 5 到 6 秒。這兩個設定所允許的最小值為 2 秒,最大值為 20 秒。

針對 CCR 最佳化 Windows 2003 網路

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

除了這些建議之外,如果您的環境還使用 IP 安全性 (IPsec) 通訊協定,則建議您在整個 CCR 環境中將 IPsec 設定為一致。這兩個節點都應該使用 IPsec,或這兩個節點都不應該使用 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 視窗調整選項:TCPWindowSizeTCP1323Opts。如需這些功能的相關資訊,請參閱 Microsoft 知識庫文章 224829 Windows 2000 及 Windows Server 2003 TCP 功能的說明

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

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 作業系統上執行之 CCR 環境的所有功能。您可以按照下列程序停用這些功能:

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

容錯移轉多重子網路容錯移轉叢集中的叢集信箱伺服器後的 Outlook 行為

分散各處之多重子網路容錯移轉叢集中所部署的 CMS 在移動或進行容錯移轉作業時,將會保留 CMS 的名稱。但不會保留指定給該名稱的 IP 位址。對於用戶端與其他伺服器,此伺服器的可用性取決於在整個 DNS 傳播的新 IP 位址。可能需要經過一些時間,DNS 傳播才會開始。因此,我們建議您將 CMS DNS 主機記錄的「存活時間」(TTL) 值設定為 5 分鐘 (300 秒)。如需如何設定 CMS 之 DNS TTL 值的詳細步驟,請參閱如何為網路名稱資源設定 DNS TTL 值。設定 CMS 的 DNS TTL 值後,您必須停止 CMS 再加以啟動,變更才會生效。

雖然內部 Microsoft Office Outlook 用戶端不需要新的或重新設定的設定檔,即可使用新的 IP 位址進行連線,但這些用戶端仍然必須等待其本機 DNS 快取清除完畢,才可以讓 CMS 名稱的名稱解析從舊的 IP 位址移至新的 IP 位址。在 IP 位址傳播至適當的 DNS 伺服器後,即可在用戶端上使用命令提示字元執行下列命令,以清除 Outlook 用戶端上的 DNS 快取:

ipconfig /flushdns

下列各節說明 Outlook 在不同組態中的行為。

Windows Server 2003 上的延伸 CCR (一個子網路)

在此組態中,會有一個網路名稱資源,以及一個與網路名稱資源相依存的 IP 位址資源。在 DNS 中,網路名稱會與 IP 位址關聯。所有資源 (包含 IP 位址資源) 都可以在叢集的兩個節點之間移動。從 Outlook 的觀點,因為容錯移轉上的唯一網路變更是 IP 位址與電腦 MAC 位址的關聯 (用戶端可以看到此作業),所以 IP 位址未變更。

Windows Server 2008 上的延伸 CCR (兩個子網路,採用 IPv4)

在此組態中,會有一個網路名稱資源,以及兩個作為邏輯 OR、與網路名稱相依存的 IP 位址。在 DNS 中,網路名稱會與目前的連線 IP 位址關聯。在容錯移轉期間,當網路名稱資源連線時,叢集服務會將網路名稱的 DNS 項目更新為第二個 IP 位址 (對應到另一個子網路)。這項記錄更新必須在整個 DNS 傳播。從 Outlook 的觀點,Outlook 不需要新的或重新設定的設定檔,但確實需要等待清除它的本機 DNS 快取,以將網路名稱解析為另一個 IP 位址。這可以在用戶端上手動執行,方法是執行:

IPConfig /flushdns

本機 CCR 與遠端站台中的 SCR (一或兩個子網路)

在此組態中,會有一個網路名稱資源,以及一個與網路名稱相依存的 IP 位址資源。所有資源 (包含 IP 位址) 都可以在叢集的兩個節點之間移動。在藉由執行 Setup.com /recoverCMS 啟動 SCR 目標的站台容錯移轉上,CMS 會移動至不同的站台/叢集。在執行此命令時,您要提供應該與遠端站台中的網路名稱相關聯的 IP 位址。Setup 會建立網路名稱和 IP 位址資源,而且叢集服務會將 DNS 更新為新的 IP 位址。這項 DNS 更新必須在整個 DNS 傳播。從 Outlook 的觀點,Outlook 不需要新的或重新設定的設定檔,但確實需要等待清除它的本機 DNS 快取,以將網路名稱解析為另一個 IP 位址。這可以在用戶端上手動執行,方法是執行:

IPConfig /flushdns

叢集連續複寫的儲存需求

CCR 的設計是要避免在 Windows 叢集中共用儲存的需要。共用儲存是舊版 Exchange 的一項需求。CCR 唯一的儲存需求,就是要有 Windows 支援儲存所提供的足夠效能及容量。

CCR 不會對儲存群組和資料庫所使用的儲存造成額外的 I/O 顧慮。在設計 CCR 儲存解決方案時,我們建議您遵循以下的最佳作法:

  • 儲存群組和資料庫在所有叢集節點上的位置都必須相同。

  • 將資料庫檔案和交易記錄檔儲存在不同的邏輯單元編號 (LUN)。

  • 使用 NTFS 檔案系統磁碟區裝載點,讓磁碟區可供作業系統使用。

  • 使用可直接且明顯與主控之儲存群組或資料庫繫結的可識別名稱。如果使用不同的磁碟區來存放記錄和資料庫,其路徑應該要能夠識別資料類型。這種方法有助於避免隨著資料庫和儲存群組的數量增加,而發生的人為錯誤。如果執行預設安裝,儲存群組和資料庫會建立在 Exchange 2007 的安裝位置下。

    note附註:
    Exchange 2007 不支援將交易記錄或資料庫檔案放在磁碟區的根目錄。

CCR 環境需要能夠提供足夠效能及容量的儲存。您應為每個儲存群組及資料庫使用同等的位置 (磁碟機代號及路徑),在這兩個節點上設定效能及容量相等的儲存。

資料庫大小及叢集連續複寫

防止 CCR 因災禍而造成儲存體故障或實體資料庫損壞的第一防線,就是恢復被動的資料副本,而不是從備份還原資料。如此一來,需仰賴從封存或磁帶還原的縮短復原時間目標 (RTO) 就不是那麼重要了。您不是從磁帶還原,而是啟動資料庫的被動副本,不需要好幾小時,而是只需要幾分鐘的時間,就能使用資料了。以此概念來看,可將 CCR 視為一種快速復原機制,與使用 Exchange Server 2003 中之磁碟區陰影複製服務 (VSS) 來建立的硬體式快照及複製,可歸類在同一類別。

因為備份不良的關係 (例如:磁帶不良,或是還原失敗),系統管理員經常需要執行離線資料庫作業,例如:修復作業。有了 CCR,即可避免這種情形,而且必須對資料庫執行修復動作的機會也大幅降低。雖然必須執行修復動作的機率大幅減少,但是有時仍有其必要。在決定資料庫大小時,請務必考慮您對最糟停機情況的容忍度。

CCR 讓您有較長的線上維護窗口。由於 CCR 可讓您從儲存群組的被動副本來製作備份,您可以在主動叢集節點上,延伸您的線上維護窗口。在許多情況下,您都可以獲得倍增的維護窗口,因而讓您擁有更大的信箱及資料庫。

Exchange 2007 的另一項功能叫做「遺失記錄檔恢復 (LLR)」,可大幅減少因為記錄檔遺失而導致資料庫不一致的情形。一般來說,系統管理員會需要修復資料庫,大多是因為當必要的記錄檔遺失或損毀時,會無法裝載資料庫,所以系統管理員必須讓資料庫前後的狀態保持一致。LLR 為許多這種記錄檔遺失及損毀的情形提供恢復能力,讓您不需要執行修復動作,也能夠裝載資料庫。如需 LLR 的相關資訊,請參閱Exchange 2007 中的遺失記錄檔恢復及交易記錄活動

就這點看來,連續複寫似乎可以讓您盡情增大資料庫,而不會有風險。不過,並不是這樣。每個資料庫都需要合理的時間來完成線上維護,這仍是會限制資料庫大小的因素。但是使用 CCR,需要重新植入資料庫的可能性也成了一項限制因素。CCR 有提供資料庫備援功能,所以如果資料庫的主動副本遺失或損毀,則可啟動資料庫的被動副本來快速完成復原。CCR 透過一種叫做「容錯移轉」的程序,來提供自動啟動功能。

進行容錯移轉之後,只會留下一份資料庫副本,也就是新的主動副本。因為被動副本不復存在,所以資料庫恢復能力會減弱。但是您應該仍保有您的備份。若要再次啟用回復性,則需要移除遺失或損毀的資料庫,而且需要建立新的資料庫被動副本,並從主動副本重新植入。依據您的資料庫大小,這可能需要一段時間。最糟的情況是所有主動副本全都遺失或損毀,這時就必須重新植入所有的被動副本。這種情況就是為什麼我們建議在 CCR 環境中使用 Gigabit Ethernet 的原因之一。

在 CCR 環境中,您應該會看到在沒有磁碟或處理器瓶頸的情況下,使用 Gigabit Ethernet 會得到下列速率:

  • 單一資料庫重新植入:每秒大約 25 MB

  • 多個資料庫重新植入 (平行):每秒大約 100 MB (受限於網路頻寬)

使用連續複寫時,可使用較大的資料庫大小上限。就 Exchange 2007 而言,建議採用下列最大資料庫大小:

  • 在 Mailbox Server 上主控的資料庫 (不使用連續複寫):100 GB

  • 在 Mailbox Server 上主控的資料庫 (使用連續複寫及 Gigabit Ethernet):200 GB

    note附註:
    大型資料庫可能也需要較新的儲存技術,才能讓增加的頻寬來應付修復案例。
    important重要事項:
    資料庫大小的真正上限,取決於組織中現行的服務等級協定 (SLA)。決定可在組織 SLA 所指定之期間內備份及還原的最大資料庫大小,即決定了資料庫的大小上限。

叢集連續複寫的 Active Directory 需求

CCR 具有獨立伺服器擁有之與 Active Directory 基礎結構相同的所有需求,再加上其他的需求。在多重資料中心的解決方案中,兩個資料中心都必須具有足夠的 Active Directory 基礎結構支援,因為在任何時刻,任一個資料中心都可能主控叢集信箱伺服器。即時其他資料中心都無法使用時,也必須具備這項能力。此外,叢集內的所有節點必須位於相同的網域,且叢集服務帳戶必須具有適當的權限。

note附註:
因為叢集中的所有節點都必須是相同站台的成員,所以,地域上散佈各地之叢集中的信箱伺服器需要有單一的 Active Directory 站台綿延在資料中心之間。不過,兩個資料中心內的任何其他伺服器均不需位於相同的子網路上或相同的 Active Directory 站台中。

叢集連續複寫的服務帳戶需求

如果是在 Windows Server 2008 上安裝 CCR,叢集服務帳戶並須以 LocalSystem (SYSTEM) 帳戶的身分執行。

如果是在 Windows Server 2003 上安裝 CCR,必須為叢集服務帳戶使用網域帳戶。叢集中的所有節點必須為同一網域的成員,並且叢集中的所有節點必須使用相同的叢集服務帳戶。叢集服務帳戶也必須是能主控叢集信箱伺服器之每一個節點上的本機 Administrators 群組的成員。

叢集服務帳戶會負責在資源上線時,建立及維護容錯移轉叢集網路名稱資源所識別及相關聯的電腦帳戶。若要確保叢集服務帳戶具有適當的權限,請參閱知識庫文章 307532 如何排解叢集服務帳戶修改電腦物件時所遇到的疑難。您也可以在知識庫文章 251335 網域使用者無法將工作站或伺服器加入網域中找到其他資訊。

叢集連續複寫與公用資料夾資料庫

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

在 Exchange 組織中使用公用資料夾資料庫與 CCR 時,建議您考量下列注意事項:

  • 如果 Exchange 組織中有單一的 Mailbox Server,而該 Mailbox Server 為 CCR 環境中的叢集信箱伺服器,則該 Mailbox Server 會主控公用資料夾資料庫。在此組態中,Exchange 組織中有單一的公用資料夾資料庫。因此,會停用公用資料夾複寫。在此案例中,公用資料夾資料庫備援是使用 CCR 來達成,而 CCR 會維護兩份公用資料夾資料庫。

  • 如果您擁有多部 Mailbox Server,則可以將公用資料夾資料庫裝載在 CCR 環境中,但前提是整個 Exchange 組織中只有一個公用資料夾資料庫。在此案例中,公用資料夾資料庫的備援也是使用 CCR 來達成。在此組態中,Exchange 組織中有單一的公用資料夾資料庫。因此,會停用公用資料夾複寫。

  • 如果要將公用資料夾的資料遷移至 CCR 環境中,您可以使用公用資料夾複寫,將公用資料夾資料庫的內容從 SCC 中的獨立 Mailbox Server 或叢集信箱伺服器移至 CCR 環境中的叢集信箱伺服器。在 CCR 環境中建立公用資料夾資料庫後,額外的公用資料夾資料庫在您的公用資料夾資料完全複寫至 CCR 環境後即不應存在。複寫順利完成後,所有位於 CCR 環境外的公用資料夾資料庫均應移除,且 Exchange 組織中不應有任何其他的公用資料夾資料庫。

  • 如果要將公用資料夾的資料遷移至 CCR 環境以外,您可以使用公用資料夾複寫,將公用資料夾資料庫的內容從 CCR 環境中的叢集信箱伺服器移至 SCC 中的獨立 Mailbox Server 或叢集信箱伺服器。在 CCR 環境以外建立額外的公用資料夾資料庫後,CCR 環境中的公用資料夾資料庫在您的公用資料夾資料完全複寫至額外的公用資料夾資料庫後即不應存在。複寫順利完成後,所有 CCR 環境內的所有公用資料夾資料庫都必須移除,且所有後續的公用資料夾資料庫皆不應保存在啟用連續複寫的儲存群組中。

在 Exchange 組織中有多個公用資料夾資料庫,且 CCR 環境中有一或多個公用資料夾資料庫的情況下 (如前述的遷移案例),請考量已排定中斷 (不會造成資料遺失) 與非排定中斷 (會造成資料遺失) 之間的行為差異。

  • 若發生成功的排定 Lossless 中斷,公用資料夾資料庫會上線且公用資料夾複寫應該會依預期繼續進行。

  • 若發生未排定的中斷,則在原始伺服器可用且主控公用資料夾資料庫之儲存群組的所有記錄檔均可用之前,公用資料夾資料庫將無法回到線上作業。若因中斷而遺失任何資料,在公用資料夾複寫啟用時,CCR 將不會允許公用資料夾資料庫上線。在此情況下必須使原始節點上線,以確保不會造成資料遺失,或必須在 CCR 環境中的叢集信箱伺服器上重新建立公用資料夾資料庫,並且使用公用資料夾複寫,從 CCR 環境以外的公用資料夾資料庫復原該資料庫的內容。

備份和還原以及叢集連續複寫

實際執行及副本儲存群組及資料庫都支援使用 VSS 技術的 Exchange 感知的備份。資料流備份只能從主動節點來支援。

note附註:
在 Exchange 感知的備份期間有一項常見的工作,就是在順利完成備份之後截斷交易記錄檔。CCR 中的複寫功能保證不會刪除尚未複寫的記錄檔。此行為的涵義是,以會刪除記錄檔的模式執行備份時,如果複寫的進度大幅落後其記錄檔的複製,則實際上可能不會釋出空間。

您可以使用資料流或 VSS 備份解決方案來將 Exchange 感知還原為主動副本。不支援被動副本的 Exchange 感知還原。

note附註:
執行還原之前,應該從被動儲存群組副本中移除所有儲存群組及資料庫檔案。

將資料庫從備份還原至 CCR 環境中的儲存群組時,您必須分別使用 Suspend-StorageGroupCopyResume-StorageGroupCopy 先暫停後再繼續儲存群組的連續複寫。必須執行此程序,才能以正確的記錄檔產生資訊更新 Microsoft Exchange 複寫服務。如果未先暫停然後繼續連續複寫,Microsoft Exchange 複寫服務將會有過時的記錄檔產生資訊並停止複寫記錄檔。

Exchange 2007 SP1 中的線上維護資料庫總和檢查和資料庫頁面清空

總和檢查是檢查資料庫完整性的程序。頁面刪除是在資料流備份結束時,清空資料庫的程序。Exchange 2007 RTM 會在執行資料庫的線上完整資料流備份時,對整個資料庫進行總和檢查。如前所述,在連續複寫環境中,資料流備份只能對資料庫的主動副本進行。您不能對資料庫的被動副本進行資料流備份。VSS 可以用來進行完整快照,或是製作被動副本的完整複製,完整快照和複製也能夠進行總和檢查。但通常在連續複寫環境中,只有一份資料庫副本 (主動或被動) 可以進行總和檢查而不需要系統管理員介入和關閉時間。這是因為:

  • 進行資料庫主動副本的資料流備份會造成負擔,進行相同資料庫被動副本的 VSS 備份也會。

  • 雖然 VSS 可以用於主動和被動資料庫副本,這麼做會與將備份作業從主動副本卸載到被動副本的建議相反。

  • 可能會暫時危及恢復,因為使用 Exchange 伺服器資料庫公用程式 (Eseutil) 手動執行完整性檢查需要暫停連續複寫。

為了在所有資料庫副本上啟用頁面刪除和資料庫總和檢查,而不遭遇或不必避開前述的問題,Exchange 2007 SP1 引進了兩項新功能:「線上維護資料庫總和檢查」和「線上維護資料庫頁面清空」。這些功能讓系統管理員能開啟資料庫的背景頁面刪除及背景總和檢查。您可以個別啟用每項功能,或是一起啟用,方法是手動設定包含要掃描之資料庫的 Mailbox Server 上的登錄值,然後重新啟動 Microsoft Exchange Information Store 服務。登錄值是在 Microsoft Exchange 資訊儲存庫層級設定。因此在啟用後,Mailbox Server 上的所有資料庫會執行設定的背景活動。可用的登錄項目稍後會在本主題說明。

Caution請注意:
UNRESOLVED_TOKEN_VAL(exRegistry)

啟用線上維護資料庫總和檢查

位置:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

名稱:Online Maintenance Checksum

類型:REG_DWORD

值:0x00000001

啟用線上維護資料庫頁面清空

位置:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

名稱:Zero Database Pages During Checksum

類型:REG_DWORD

值:0x00000001

節流線上維護資料庫總和檢查

位置:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

名稱:Throttle Checksum

類型:REG_DWORD

值:0x00000000 (毫秒)