Share via

Exchange Server Multi-Site 資料複寫的部署指導方針

  • 發行項

 

上次修改主題的時間： 2006-09-01

複寫技術可為 Microsoft® Exchange Server 資料提供高可用性。本主題旨在協助您更了解複寫儲存技術，以及如何在 Exchange 伺服器環境中使用它。

複寫所支援的高可用性是藉由在多站台擁有多餘資料，但是它無法防止資料損毀發生。如果任何錯誤資料寫入主要儲存裝置而造成資料庫損毀，則相同的錯誤資料將複寫到遠端站台並損毀遠端站台的資料庫。因此，資料複寫無法取代一些資料庫維護程序，例如，定期確認資料庫完整性的資料庫備份。

本主題所討論的資料類型是執行 Exchange 服務 (如 Exchange 程序所提出的寫入 I/O 要求) 所存取的資料。在此不討論系統/OS 資料複寫。

Microsoft 對於各種類型的複寫方案具有支援原則。如需這些支援原則的詳細資訊，請參閱 Microsoft 知識庫文章 895847＜Multi-site data replication support for Exchange 2003 and Exchange 2000＞(Exchange 2003 和 Exchange 2000 的多站台資料複寫支援)。

note附註：
下載《Microsoft Exchange Server 多站台資料複寫的部署指導方針》(英文) 進行離線列印或閱讀。

複寫機制

使用資料複寫目的是要維護遠端站台目前的資料複本。Exchange 伺服器可在主要位置的儲存區或站台中斷的事件中，使用遠端站台的複本來提供連續性的電子郵件服務。資料複寫可以同步或非同步方式傳播。根據定義，在本機和遠端位置認可 I/O 寫入時，若資料同步複寫，主機將只從儲存區取得寫入完成回應。換句話說，在主機確認寫入已成功之前，本機和遠端儲存區必須執行此變更。在非同步模式中，當本機儲存區已認可寫入時，不需等待遠端儲存區的確認，它也會更新複本，而主機將會從儲存區取得寫入完成。

非同步複寫

一般而言，相較於同步複寫模式，在使用非同步複寫時，主應用程式對於複寫距離所增加的寫入延遲較不敏感。不過，當您部署非同步複寫時，應注意下列問題：

  • 資料遺失   依資料複寫的頻率而定，遠端站台的資料變更可能會落後於主要站台中的變更。如果主要站台中斷，遠端站台複本將無法完全更新。雖然此延遲在大多數儲存解決方案中是可設定的，但您應注意此問題可能會導致資料遺失。
  • 資料完整性 (寫入順序保存) Exchange 的資料庫和其相關交易記錄之間的寫入順序有依存關係。Exchange 永遠會先將變更寫入記錄檔，再認可那些變更到資料庫檔案。在同步複寫模式中，應用程式會控制寫入順序。不過，在非同步模式中，複寫解決方案則控制何時要複寫資料。如果解決方案不會保留複寫期間的寫入順序，其可能會損毀資料庫檔案，而且在損壞發生時將無法裝載資料庫。
  • 效能影響   許多廠商宣稱他們的非同步解決方案不會影響儲存效能，但事實上，執行非同步複寫時效能會降低。根據解決方案實作而定，沒有單一編號可描述效能期望。因此，客戶應妥善測試解決方案後再進行部署，以驗證解決方案可為 Exchange 使用者提供足夠的儲存效能。

有些解決方案提供者使用各種技術來解決寫入順序保留問題。若要成功部署非同步複寫方案，客戶必須與廠商合作，以確保其非同步技術符合下列需求：

  • 它可維護儲存群組中所有裝置的寫入順序一致性，包括和彼此之間的連續一致性；
  • 已證實其為可復原，最好同時在測試和生產環境中；
  • 它正由廠商為複寫的資料提供適當的支援計劃。

同步複寫

Exchange 部署中同步複寫的主要考量與效能有關。測試顯示用戶端經驗主要為寫入延遲。使用同步複寫解決方案，每個 Exchange 伺服器可以裝載的信箱數目會減少。效能影響主要取決於複寫距離、複寫連結頻寬和使用量。同步複寫最多可降低 75 % 的信箱/伺服器延展性。當您在研究 Exchange 容量規劃方法時，應考慮此延展性降低因素。如需詳細資訊，請參閱本主題之後的＜同步複寫的部署規劃＞。

同步複寫通常被視為可防止資料遺失的解決方案，因為複本與主要儲存資料檔案完全同步。不過，與此一般看法相反的是，也有同步複寫解決方案遺失資料的案例。以下範例說明這種案例。

一般而言，儲存資料複寫解決方案在下列兩種方式處理複寫連結失敗：

  • 僅繼續認可寫入 I/O 到主要儲存裝置、記錄在記錄檔使用複寫連結之所有裝置的變更，並將記錄儲存在主要儲存區。
  • 寫入作業失敗，讓應用程式以處理磁碟失敗的方式來處理。

如果複寫解決方案使用第一個處理方法，資料可能就會遺失。在主要站台失敗後不久的連結失敗情況期間，將不會複寫自連結失敗後認可的資料；因此，資料會隨主要儲存區失敗而遺失。當您在設計儲存區複寫解決方案時，請記住這類的失敗情況，以建立系統來減少這類事件。在此範例中，客戶可能會考慮部署多餘複寫連結，以減少資料遺失的機會。

同步複寫解決方案

同步複寫解決方案以複寫發生的位置來分類，可能是主機複寫或儲存區複寫。主機複寫通常使用主機軟體 (篩選器驅動程式) 來中斷 I/O 資料流以管理複寫。儲存區複寫發生在儲存區裝置層級的離線主機。這兩個複寫解決方案都可部署為下列其中一部分：

  • 地理位置分散的叢集 (Geocluster)   在此類別中，隸屬於同一叢集的節點會放置在不同站台。一般而言，Exchange 伺服器是在主要站台由節點主動裝載。解決方案提供 Exchange 資料至遠端站台的同步複寫。如果主要站台損壞，Exchange 虛擬伺服器會容錯移轉到遠端站台的被動節點，並使用複寫的 Exchange 資料連線。
    Microsoft Windows® Server Catalog 有一項類別是地理位置分散的叢集解決方案。您可以搜尋 Windows Hardware Qualified Labs 符合 WHQL 的地理位置分散之叢集解決方案，網址在：https://go.microsoft.com/fwlink/?LinkId=28572。
  • 其他   此類別包括不使用地理位置分散之叢集的所有其他類型同步複寫部署。這些解決方案在主要站台失敗的事件中，依賴其他方法來利用遠端站台的複寫 Exchange 資料 (例如，待命解決方案；配合損壞修復程序的複寫)。

Microsoft 強烈建議客戶從其複寫方案廠商取得有關下列問題的保證：

  • 解決方案的類別是否為地理位置分散的叢集解決方案？如果是，是否為 WHQL 認證？如果它不是這種解決方案，是否為 Windows Server Catalog＜叢集方案，地理位置分散的叢集方案＞一節所描述之解決方案中列出的儲存裝置？
  • 複寫方案是否可避免所有站台同時中斷而遺失資料的可能性？
  • 執行容錯移轉和錯誤後回復的程序為何？
  • 複寫解決方案和預期的延遲可以處理規劃的 Exchange 使用者負載，並提供有品質的用戶端經驗嗎？

要複寫的 Exchange 資料

Exchange 是一個資料中心伺服器應用程式。將 Exchange 資料複寫到次要站台，以在發生儲存區相關失敗時提供備援。決定複寫何種類型的資料屬於商業決策。您應該評估您的企業對於遺失此處所描述之各種資料的容錯能力。

要複寫的必要資料

下列是必須複寫的資料：

  • Exchange 信箱資料庫檔案會儲存郵件資料。每個資料庫包含兩個檔案：
    • 資料庫檔案 (.edb)，保留郵件與 MAPI 內容。
    • 資料流檔案 (.stm)，保留非 MAPI 原生內容。
  • 交易記錄檔 (.log)，記錄資料庫認可的每筆交易。
  • 檢查點檔案 (.chk)，包含已寫入磁碟的記錄檔項目資訊。

對於向用戶端提供其信箱伺服器及記憶體中所保留資料庫變更的軟復原之存取，或如果 Exchange 伺服器的儲存區未正確關閉 (如電源中斷) 而造成遺失，這些檔案都是很重要的。因為這些檔案的重要層面，所以必須複寫這個資料集。資料庫檔案路徑是在資料庫內容頁指定的，每個資料庫有它自己的路徑。交易記錄檔路徑和檢查點檔案路徑是在儲存群組內容頁指定的，該儲存群組中的所有資料庫都依存於這些路徑。

複寫公用資料夾資料庫是更複雜的決策。是否要這樣做則視部署的 Exchange 拓撲設計而定。與信箱資料不同的是，公用資料夾可直接由 Exchange 伺服器複寫。您可以讓公用資料夾的多個複本儲存複寫變更 (內容)。此資料複寫不會以同步方式執行。

Geocluster 解決方案需要同步複寫叢集中的公用資料夾。為使叢集在次要站台中完整運作，此需求是必要的。叢集中的信箱資料庫必須指向也裝載於叢集中的公用資料夾儲存區 (預設公用儲存區)，在叢集可在次要站台中使用後，用戶端才能立即登入。Geocluster 中的公用資料夾只需裝載階層，而非一定要裝載完整內容才能在失敗時使用信箱登入。裝載完整公用資料夾內容並在 Geocluster 裝載的公用資料夾中將其同步複寫，是一項商業決策。如果公用資料夾資料對核心商務非常重要，也就是只允許最少量的資料遺失，您應該考慮使用 Geocluster 解決方案，而非 Exchange 伺服器公用資料夾複寫機制。如果您不需要此層級的公用資料夾資料可用性，則可合併使用信箱資料的非 Geocluster 同步複寫方案，以及 Exchange 公用資料夾中的複寫機制。

建議複寫的資料

當 Exchange 伺服器處理簡易郵件傳送通訊協定 (SMTP) 本機佇列資料 (Mailroot 目錄) 時，是將它暫時保留於儲存區裝置中。此設計可避免伺服器失敗而導致資料遺失。例如，當目的伺服器無法存取時，應將郵件路由到要儲存的本機伺服器佇列目錄之伺服器中，直到可以將其傳遞為止。如果儲存佇列資料的磁碟失敗，就會遺失佇列中的所有郵件。由於佇列資料是暫時性的，因此郵件佇列不像 Exchange 伺服器資料庫一樣有定義的備份程序。為保留此佇列資訊的儲存區提供容錯及/或高可用性解決方案，可避免資料遺失的可能性。另外，建議您在不能因為站台失敗而遺失暫時郵件的環境中複寫 MTA 佇列資料 (MTADATA 目錄)。

SMTP Mailroot (包括每個虛擬伺服器執行個體佇列和 Badmail 目錄) 的路徑是在 Exchange 系統管理員 (ESM) 的 SMTP 虛擬伺服器內容頁中的 [郵件] 索引標籤上所指定，而 MTA 佇列路徑則在 X.400 內容頁中指定。您應該查看設定檔來決定是否有必要複寫 Exchange 佇列資料。如果您有現存的 Exchange 拓撲，則可決定是否可容許本機佇列中的資料遺失。在尖峰負載期間，您可使用效能監視器 (Perfmon.msc) 中的本機佇列長度，或 ESM 中的佇列檢視器，以衡量本機佇列中預期的資料量。如果必須複寫佇列資料，則測試複寫環境中郵件處理的效能是很重要的，這樣所產生的複寫延遲才不會對傳輸造成瓶頸。您可使用 Exchange Server Stress and Performance 2003 工具，在複寫佇列資料的同步複寫環境中測試傳輸輸送量。您可以從 Exchange Server Stress and Performance 2003 網站下載工具。

選擇性複寫的資料

郵件追蹤記錄包含 Exchange 伺服器所傳送、接收以及存放的所有郵件資訊。此資料對於診斷用途很重要。依照預設值，郵件追蹤為不啟用。不過，如果此資料對您企業很重要，可將它複寫以在避免損壞事件中遺失。郵件追蹤記錄的路徑是在 ESM 的 Exchange 伺服器內容頁指定。

設定複寫機制的最佳作法

每個廠商都有自己專屬的各種複寫機制實作方式，以提供不同的複寫選擇。您應該和特定廠商討論解決方案細節，以確定他們正在提議的解決方案是否最符合您的組織需求和損壞修復的服務等級協定 (SLA)。下列建議可以套用至特定複寫解決方案：

note附註：
「複寫點」一詞定義為發生複寫的位置。視解決方案而定，此位置可以是主機篩選器驅動程式層級或儲存區陣列中的磁碟分割。
  • 在邏輯/裝載點磁碟區層級設定複寫。
    雖然需要複寫的資料保留在本主題＜要複寫的 Exchange 資料＞一節所述的檔案中，但您必須確定主機層級的邏輯/裝載點磁碟區單位已設定複寫。例如，如果信箱資料路徑是 G:\MDB1\MDB1.EDB，磁碟機 G 應為執行複寫的基本單位。因此，將會複寫磁碟機 G 上的所有資料。將複寫設定在檔案或子目錄層級容易有人為錯誤產生，而且 Microsoft 並不支援。
  • 建立多個複寫點。
    為減少指向相同複寫點的多重 I/O 佇列，請將儲存區設定為儘可能建立許多複寫點。負載平衡多個複寫點間的 I/O。視儲存區/複寫解決方案的不同，此方法因為減少了 I/O 佇列，因而可降低整體的 I/O 讀取/寫入延遲。
  • 在不同的邏輯磁碟區保留交易記錄。
    複寫資料時，每個寫入 I/O 要求會在複寫點層級排入佇列。Exchange 以序列模式寫入記錄，如果這些 I/O 指向相同的複寫點，則每個 I/O 都很有可能排入寫入佇列。這種情況會導致較長的記錄寫入回應時間，在 Exchange 效能/延展性中可能會是重大的負面因素。基於此原因，Microsoft 建議您將不同儲存群組中的交易記錄切割至具有不同複寫點的不同邏輯磁碟區中。
  • 使用多個複寫連結。
    您可藉由在主要和次要站台之間設定多個複寫連結，以經常性改進複寫解決方案的效能/延展性。這個方法的實作成本可能很高，而且對 Exchange 資料複寫而言並不需要。不過，對於給定的 Exchange 資料複寫解決方案，有些部署必須實作多個複寫連結來達成想要的效能/延展性。為了最佳化的複寫傳輸量，也可能需要負載平衡可用的複寫連結間的複寫點。
    因為 Exchange 的資料庫和其相關交易記錄之間具有寫入順序依存性，因此為備份儲存群組邏輯磁碟區 (其中包含資料庫邏輯單元數 (LUN) 與記錄 LUN) 的複寫點設定群組，以使用相同的複寫連結是很重要的。這個組態對於在儲存群組層級保存寫入順序是必要的，而對於失敗案例 (如連結失敗)，在遠端站台維持資料完整性則是相當重要。
    使用具有多個複寫點的多個複寫連結，是延展 Exchange 資料複寫解決方案的有效方法。這個方法也可以減少資料遺失的可能性，其在稍早的＜同步複寫＞一節範例中已討論過。

設定 Exchange 進行同步複寫的最佳作法

當 Exchange 部署在一個同步複寫環境中時，少數組態變更將會改進伺服器效能/延展性。在規劃階段了解這些變更是很重要的，以便在儲存區和複寫設計期間進行實作。組態的最佳作法建議如下所示：

  • 為每個 Exchange 伺服器建立最大量的儲存群組。
    藉由在多個邏輯磁碟區和後續 多個複寫點之間複寫平衡記錄寫入交易，以在同步複寫的 Exchange 解決方案中增加儲存群組的數量，而提高部署的效能/延展性。一般而言，將有更多的平行記錄寫入程序，其可在同步複寫環境中降低整體的交易記錄寫入延遲 (降低 I/O 佇列)。Exchange Server 2003 Enterprise Edition 允許每個 Exchange 伺服器有四個儲存群組。
  • 增加交易記錄檔緩衝區大小。
    Exchange 記錄寫入 I/O 延遲是同步複寫 Exchange 解決方案中的重要延展性因素。記錄寫入 I/O 是連續的單一執行緒，因此記錄 I/O 中的延遲可能會成為系統瓶頸。記錄 I/O 會先寫入記錄緩衝區，然後由 non-lazy 認可或容量認可來清除緩衝區。non-lazy 認可表示記錄緩衝區會立即寫入磁碟。容量認可表示緩衝區已滿時，記錄緩衝區會寫入磁碟。
    增加記錄緩衝區大小可降低容量清除的頻率、增加記錄寫入大小，並減少整體的記錄寫入延遲。減少記錄 I/O 寫入延遲，是提高 Exchange 部署的效能/延展性的重要方法。
    如果複寫是透過光纖通道，一般建議是將緩衝區大小增加到最多 9,000。對於低頻寬連結 (如 TCP/IP 連結)，決定此參數的最佳值並不容易。如果連結顯示增加的記錄寫入大小飽和度，將會顯示複寫，您應該做廣泛測試，來決定最小化記錄寫入延遲的最佳記錄緩衝區大小。若要了解如何修改此參數，請參閱知識庫文章 328466＜設定太小的 ESE 記錄緩衝區會導致 Microsoft Exchange 資訊儲存區服務停止回應＞(英文)。另外，請向您的解決方案提供者諮詢此設定的相關資訊。

同步複寫的部署規劃

即使同步複寫儲存解決方案依循上述所有建議，但若在部署之前未徹底測試解決方案，仍有可能造成 Exchange 用戶端的效能問題。關於實作 Exchange 同步複寫的延展性/效能負面影響，並沒有明確的規則。每個 Exchange 複寫解決方案都有不同的效能因素，可能包括下列但不僅限於此：站台間的距離、複寫傳輸機制、複寫連結數目、複寫點數目、Exchange 儲存群組數目、Exchange 資料庫/記錄組態設定、儲存區和複寫架構，以及 Exchange 用戶端設定檔。每個解決方案都是唯一的，並且需要廣泛規劃與測試才能成功部署。

導致同步複寫解決方案的 I/O 寫入延遲是限制 Exchange 延展性的關鍵因素。這段增加的 I/O 延遲會對伺服器造成負載，而嚴重影響 Exchange 用戶端的使用情形。尤其是，高寫入延遲使 RPC 延遲增加，導致用戶端的速度更慢。同步複寫為 Exchange 資料提供高可用性，但也大幅降低 I/O 效能。I/O 寫入 (有時為讀取) 效能降低，是決定給定平台上可支援之最多使用者數目的重要因素。

在規劃階段，請依照下列步驟來驗證設計：

  1. 請參閱 Optimizing Storage for Exchange 2003 (Exchange 2003 的最佳化儲存)，以了解如何妥善設計和實作 Exchange 儲存區。
  2. 使用 Jetstress 測試來驗證已設定同步複寫的儲存區原始輸送量。如果要下載 Jetstress 工具，請參閱 Microsoft Exchange Server Jetstress Tool (Microsoft Exchange Server Jetstress 工具) 網站。
  3. 請執行為您的環境量身訂作的 Exchange Server Load Simulator 2003 (LoadSim) 測試，測量增加的寫入延遲對電子郵件用戶端的影響。若要下載 LoadSim，請參閱 Microsoft Exchange Server 2003 Load Simulator (LoadSim) 網站。
  4. 當您執行 LoadSim 時，會測量平均磁碟傳輸量。磁碟傳輸量必須等於或高於您所模擬的實際執行環境 (IOPS/信箱) 預期的尖峰平均傳輸量。如需如何測量尖峰平均磁碟傳輸量的詳細資訊，請參閱 Optimizing Storage for Exchange 2003 (Exchange 2003 的最佳化儲存)。
  5. 在您執行 LoadSim 測試之後，請密切注意伺服器的 RPC 平均延遲計數器和用戶端回應時間。當您分析測試結果時，請注意三個計數器都必須滿足下列條件。
    RPC 平均延遲
    這個計數器顯示處理單一遠端程序呼叫 (RPC) 要求所需的平均時間量。增加使用者負載或複寫距離將導致 RPC 延遲的平均值增加。平均值的最大限制為 50ms，且最大值應為 100ms。如果測試結果顯示的平均值超過 50ms，整體用戶端經驗預期將會很緩慢。如果平均值小於 50ms 但偶爾超過 100ms，在超過的期間用戶端經驗將非常緩慢。
    磁碟延遲計數器
    Microsoft Exchange 產品小組已測試幾個硬體同步複寫解決方案。結果會指出 RPC 平均延遲和磁碟延遲之間的關聯。一般指導方針是，解決方案能夠在資料庫讀取延遲平均值小於 20ms，且記錄讀取和寫入延遲平均值小於 20ms 時，處理給定負載。這些延遲的最大值應保持在 40 ms 以下。超過這些閾值，用戶端可能會經歷到很緩慢的回應。
    用戶端回應時間
    您可以藉由在所有用戶端電腦執行 lslog.exe，以確認整體用戶端經驗。此活動傳回第九十五百分位數的加權平均值；該值必須小於 1,000ms。lslog.exe 是 LoadSim 工具的一部分。LoadSim 文件討論如何使用 Islog.exe 並解譯它所提供的結果。
    如需有關效能的詳細資訊，請參閱Troubleshooting Exchange Server 2003 Performance (疑難排解 Exchange Server 2003 效能)。
  6. 針對您的信箱設定檔和規劃的複寫距離來測試解決方案。複寫連結距離有實體限制。距離增加，用戶端/伺服器回應時間會變慢，因為同步複寫會隨距離而增加寫入延遲。一般而言，100KM 被認為是 Exchange 伺服器資料同步儲存複寫的閾值。此閾值隨解決方案實作而不同。
  7. 建立定期驗證資料庫完整性的備份計劃。複寫不能取代備份程序。
  8. 請確定您有完整的損壞修復計劃，並已經過像解決方案複寫效能的徹底測試。復原 Exchange 資料、伺服器及站台各有不同的方法。您應該實作滿足您商務需求與服務等級協定的損壞修復計劃，以在發生損壞時引導您快速有效地完成修復階段。藉由在負載過重情況下，模擬於 Exchange 部署中使用同步複寫的多種類型之失敗狀況，來測試和驗證計劃。