共用方式為

瞭解高可用性和站台恢復

  • 發行項

 

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2016-11-28

信箱資料庫及其所包含的資料，是所有 Exchange 組織最重要的元件之一 (可能是最重要的元件)。在 Microsoft Exchange Server 2010 中，您可以為高可用性和站台回復性設定信箱資料庫，以保護信箱資料庫及其所包含的資料。Exchange 2010  可降低部署高可用性和站台恢復通訊解決方案的成本和複雜度，同時還提供高階端對端可用性並支援大型信箱。Exchange Server 2007 中的新高可用性架構是建立在 Exchange 2010 中引進的原生複寫功能上，針對高可用性和嚴重損壞修復提供簡化的統一架構。Exchange 2010 將高可用性整合至 Exchange 的核心架構中，可讓所有規模和所有部門的客戶以經濟實惠的方式，在其組織中部署郵件持續性服務。

要尋找與高可用性和站台恢復相關的管理工作嗎？請參閱管理高可用性及站台恢復。

目錄

重要詞彙

Exchange Server 2010 解決方案的主要特性

資料庫行動力

增量部署

資料庫可用性群組

信箱資料庫副本

Active Manager

舊版 Exchange 之高可用性的變更

非 Mailbox Server Role 的高可用性

站台回復性

端對端可用性

重要詞彙

適用下列術語：

  • 通訊錄服務
    Client Access Server 上的一項服務，可針對 Microsoft Outlook 用戶端提供目錄存取端點。
  • 連續複寫 - 區塊模式
    SP1 中連續複寫的一種全新形式，其中每項更新都會寫入到主動資料庫副本的使用中記錄緩衝區，同時也會傳送到每個被動信箱副本上的記錄緩衝區。當記錄緩衝區已滿時，每個資料庫副本都會依產生順序來建置、檢查及建立下一個記錄檔。
  • 連續複寫 - 檔案模式
    Exchange 2010 量產發行 (RTM) 版本中連續複寫原始形式的名稱，其中已關閉的交易記錄檔會從主動資料庫副本發送到一或多個被動資料庫副本。
  • 資料庫可用性群組 (DAG)
    最多 16 個 Exchange 2010 信箱伺服器的群組，主控一組已複寫的資料庫。
  • 資料庫行動力
    複寫所在和掛接在其他 Exchange 2010 信箱伺服器上之單一 Exchange 2010 信箱資料庫的能力。
  • 嚴重損壞修復
    用於以手動方式從失敗中復原的任何處理程序。可以是影響單一項目的失敗，或是影響整個實體位置的失敗。
  • 交換協力廠商複寫 API
    Exchange 所提供的 API，可使用資料庫可用性群組的協力廠商同步複寫，來代替連續複寫。
  • 高可用性
    提供影響服務或資料 (例如網路、儲存或伺服器失敗) 的服務可用性、資料可用性和故障自動復原之解決方案。
  • 增量部署
    Exchange 2010 安裝後部署高可用性和站台回復性的能力。
  • 延遲的信箱資料庫副本
    記錄檔重新執行延隔時間大於 0 的被動信箱資料庫副本。
  • 信箱資料庫副本
    信箱資料庫 (.edb 檔和記錄檔) 為主動或被動。
  • 信箱恢復功能
    Exchange 2010 中整合高可用性和站台回復性解決方案的名稱。
  • RPC 用戶端存取服務
    Client Access Server 上的一項服務，可針對 Microsoft Outlook 用戶端提供 MAPI 端點。
  • 站台回復性
    當主要資料中心再也無法提供充分的服務水準，以達成組織要求時，可使用手動嚴重損壞修復程序來啟用替代或待命資料中心。也包含用於重新啟用已回復、儲存或重新建立的主要資料中心之程序。您可以使用 Exchange 2010 的內建功能，為高可用性和啟用站台回復性設定您的通訊解決方案。
  • 陰影備援
    提供郵件在整個傳送過程中，郵件備援的傳輸伺服器功能。
  • [*over] (讀成 "star over")
    [switchovers] (轉換) 和 [failovers] (容錯移轉) 的簡寫。轉換是指一或多個資料庫副本的手動啟動。容錯移轉是指一或多個資料庫副本發生故障後的自動啟動。

回到頁首

Exchange Server 2010 解決方案的主要特性

Exchange 2007 透過引進技術 (例如本機連續複寫 (LCR)、叢集連續複寫 (CCR) 和待命連續複寫 (SCR))，降低了高可用性的成本，並使站台恢復更加經濟。不過，仍然有一些挑戰：

  • Windows 容錯移轉叢集可能會因為其複雜性而令人困惑。

  • 要達到高層級的執行時間，可能需要高層級的系統管理員進行操作。

  • 每種類型的連續複寫是以不同方式分別管理。

  • 在大型信箱伺服器上從單一資料庫的失敗復原，可能導致信箱伺服器上所有使用者的服務暫時中斷。

  • Hub Transport Server 的傳輸暫放功能只能在 CCR 環境中保護寄至信箱的郵件。如果 Hub Transport Server 在處理郵件時失敗且無法復原，則可能導致資料遺失。

Exchange 2010 包含重要的核心變更，在架構中整合了高可用性，比舊版的 Exchange 成本更低、更易於部署與維護。Exchange 2010 包含用於高可用性和站台恢復的全新整合平台。

使用 Exchange 2010 的重要核心變更，當使用連續複寫時，建議的信箱資料庫大小上限值，從 Exchange 2007 的 200 GB 增加至 Exchange 2010 的 200 TB。隨著越來越多公司以大型信箱 (2 GB 到10 GB) 實現更大價值，很快即可實現超大型資料庫大小。支援大型資料庫，意謂著逐漸捨棄傳統的復原機制，例如備份和還原，並轉移到更新、更快的保護形式，例如資料複寫和伺服器備援。您的信箱資料庫的大小最終取決於許多您在 Exchange 2010 規劃程序時所取得的因素。如需規劃信箱與信箱伺服器的詳細指引，請參閱 信箱伺服器儲存設計。

Exchange 2010 將 CCR 和 SCR的關鍵可用性和恢復功能組合成單一解決方案，可同時處理現場和離站資料複寫。信箱伺服器可以定義為 DAG 的一部分，在信箱資料庫層級 (而非伺服器層級) 提供自動復原。Exchange 2010 中還引進了其他的新高可用性概念，例如*「資料庫行動性」和「增量部署」*。

回到頁首

資料庫行動力

Exchange 2007 引進了許多新的架構變更，其設計目的是要讓針對 Exchange 部屬高可用性和站台恢復解決方案更加快速且簡單。這些改進包含了整合式安裝經驗、最佳化的組態設定，而且能夠使用原生 Exchange 管理工具來管理大多數層面的高可用性解決方案。

不過，Exchange 2007 高可用性解決方案的管理需要複雜的叢集概念，例如移動網路識別和管理叢集資源的概念。此外，在針對有關叢集信箱伺服器的問題進行疑難排解時，必須使用 Exchange 工具和叢集工具，才能從以下兩個不同來源檢閱並關聯記錄檔和事件：一個來源是 Exchange，另一個來源是叢集。

根據客戶意見評估，並修訂了 Exchange 2007 架構的其他兩個限制層面：

  • 叢集 Exchange 2007 伺服器需要專用的硬體。叢集中的節點只能安裝信箱伺服器角色。也就是說，若要達到部署之主要元件的完整備援，最少需要四個 Exchange 伺服器，例如，核心伺服器角色 (信箱、集線傳輸及用戶端存取)。

  • 在 Exchange 2007 中，叢集信箱伺服器的容錯移轉是發生在伺服器層級。因此，如果發生單一資料庫失敗，系統管理員必須將整個叢集信箱伺服器容錯移轉至叢集中的另一個節點 (這會導致伺服器上所有使用者短暫的停機，而且不僅止於使用受影響資料庫上之信箱的使用者)，或者在從備份還原資料庫期間，讓失敗之資料庫上的使用者離線 (可能需要數小時)。

Exchange 2010 的設計理念是源自資料庫行動性的概念。透過將資料庫複寫到多個不同且分配至相同群組的伺服器，資料庫行動性擴充了系統對於連續複寫的使用。此模型可提供更好的資料庫保護和更高的可用性。在這種模式下，自動容錯移轉保護和手動轉換控制是在信箱資料庫層級提供，而非伺服器層級。

如果發生失敗，具有資料庫副本的其他伺服器就可以裝載資料庫。由於這種變更和其他結構的變更，容錯移轉動作現在比舊版的 Exchange 更快完成。例如，在 CCR 環境下執行 Exchange 2007 的叢集信箱伺服器之容錯移轉，大約 2 分鐘完成 (假設站台內部容錯移轉其叢集信箱伺服器的 IP 位址不變)。相較之下，Exchange 2010 環境中的信箱資料庫容錯移轉則在 30 秒內完成 (從偵測到失敗的時間算起，到資料庫副本完成裝載為止；前提是副本的狀況良好而且使用記錄檔重新顯示為最新狀態)。資料庫層級容錯移轉結合明顯加快的容錯移轉時間，改進了組織的整體執行時間。

回到頁首

增量部署

Exchange 2010 引進了增量部署的概念，此概念可讓您在安裝 Exchange 之後，部署所有信箱伺服器和資料庫的服務和資料可用性。透過使用 Exchange 2010 中的新功能 (例如 DAG 和資料庫副本)，可以達成服務與資料備援。

在舊版 Exchange 中，信箱伺服器角色的服務可用性是透過在 Windows 容錯移轉叢集中部署 Exchange 而達成。若要在叢集中部署 Exchange，首先必須建立容錯移轉叢集，然後安裝 Exchange 程式檔案。此處理序會建立稱為叢集信箱伺服器 (或在舊版 Exchange 中稱為 Exchange 虛擬伺服器) 的特殊信箱伺服器。如果您已經在非叢集伺服器上安裝了 Exchange 程式檔案，而且您決定要具備叢集信箱伺服器，則必須使用新硬體來建立叢集，或從現有伺服器移除 Exchange、安裝容錯移轉叢集，並重新安裝 Exchange。

回到頁首

資料庫可用性群組

DAG 是建置於 Exchange 2010 的高可用性和站台回復性架構之基礎元件。DAG 是一組多達 16 個信箱伺服器的群組，可主控資料庫集，並提供從影響個別資料庫的失敗中自動進行資料庫層級復原的功能。DAG 中的任何伺服器都可以主控來自 DAG 中任何其他伺服器的信箱資料庫副本。當伺服器新增至 DAG 後，它即可與 DAG 中其他的伺服器搭配使用，以便針對影響信箱資料庫的失敗 (例如磁碟故障或伺服器失敗) 進行自動復原功能。

Exchange 2007 引進了稱為連續複寫的內建資料複寫技術。連續複寫有三種形式可用：本機、叢集和待命，大幅降低高可用的 Exchange 基礎結構之部署成本，並提供更加改善的舊版 Exchange 之部署和管理體驗。即使有了這些成本節省和改善，但因為 Exchange 和 Windows 容錯移轉叢集之間的整合不完備，所以仍然需要許多時間和專業知識，才能夠執行高可用的 Exchange 2007 基礎結構。此外，客戶希望有一種更簡單的方法將電子郵件資料複寫到遠端位置，以保護其 Exchange 環境免受站台層級的損壞。

Exchange 2010 使用與 Exchange 2007 相同的連續複寫技術。Exchange 2010 將現場資料複寫和 (CCR) 和離站資料複寫 (SCR) 組合成稱為 [資料庫可用性群組] (DAG) 的單一架構。伺服器新增至 DAG 之後，您可以遞增複寫的資料庫副本 (總計最多 16 個)，而且 Exchange 2010 在這些副本之間自動切換以維護可用性。

不像 Exchange 2007，其叢集信箱伺服器需有專用的硬體，DAG 中的信箱伺服器可主控其他 Exchange 角色 (用戶端存取、集線傳輸和整合通訊)，只需兩部伺服器，即可提供 Exchange 服務的完整備援。

這種全新的高可用性架構還提供各種失敗 (磁碟層級、伺服器層級和資料中心層級) 的簡易復原，並且可在各種儲存類型中部署架構。

如需 DAG 的詳細資訊，請參閱瞭解資料庫可用性群組。

回到頁首

信箱資料庫副本

Exchange 2007 中第一次採用的高可用性和站台回復性功能用於 Exchange 2010，可建立和維護資料庫副本，以便您可以在 Exchange 2010 中達成可用性目標。Exchange 2010 還採用資料庫行動性的概念，是 Exchange 受管的資料庫層級容錯移轉。

資料庫行動性會中斷資料庫與伺服器的連線，新增單一資料庫最多達 16 個副本的支援，及提供新增資料庫副本至資料庫的原生經驗。在 Exchange 2007 中，名為資料庫可攜性的功能還可讓您在伺服器之間移動信箱資料庫。不過，資料庫可攜性和資料庫行動性之間的重要區別在於，資料庫的所有副本都具有相同的 GUID。

設定資料庫副本作為主動信箱資料庫，即稱為 [轉換]。當發生失敗影響資料庫，且新資料庫成為主動副本時，此處理程序稱為 [容錯移轉]。此處理程序還涉及伺服器故障，一個或多個伺服器讓以前在故障伺服器上的線上資料庫處於線上狀態。當發生轉換或容錯移轉，其他 Exchange 2010 server role 幾乎立即得知轉換，並將用戶端和通訊流量重新導向至新的主動資料庫。

例如，如果 DAG 的主動資料庫因基礎存放區故障而失敗，Active Manager 會自動復原，其方法是透過在 DAG 的另一個信箱資料庫上容錯移轉至資料庫副本。如果資料庫不符自動裝載準則而無法自動裝載，您可以手動執行資料庫容錯移轉。

如需信箱資料庫副本的詳細資訊，請參閱瞭解信箱資料庫複本。

回到頁首

Active Manager

在 Exchange 2007 與舊版中，Exchange 使用叢集資源管理模組，來安裝、實作和管理信箱伺服器高可用性解決方案。從之前的經驗來看，建立高度可用的信箱伺服器包含初次建立 Windows 容錯移轉叢集，然後在叢集模式下執行 Exchange 安裝。在此模式下，會註冊 Exchange 叢集資源 DLL 檔 exres.dll，並可建立叢集信箱伺服器 (舊版稱為 Exchange 虛擬伺服器)。部署舊版的共用儲存叢集或單一副本叢集時，容錯移轉叢集形成前後，以及叢集信箱伺服器和儲存群組形成後，需有額外的存放區設定步驟。

Exchange 2010 包含 [Active Manager] 的新元件，它提供取代資源模組和容錯移轉管理功能的功能，這些功能都是透過與舊版 Exchange 的叢集服務整合所提供。如需 Active Manager 的相關資訊，請參閱 瞭解 Active Manager。

回到頁首

舊版 Exchange 之高可用性的變更

Exchange 2010 的核心結構有許多變更，這些變更會直接影響您如何設定高可用性的 Exchange，以及直接影響您執行站台復原的方法。其中一個重大變更是移除叢集信箱伺服器，以及使用 Windows 容錯移轉叢集資源模組。其他重大變更包含資料庫的全球化，以及 Exchange 2007 初次採用的內建連續複寫技術之改善。

叢集信箱伺服器移除

在 Exchange 2010 中，Exchange 不再是叢集應用程式，叢集資源模組不再用於 Exchange 高可用性。Exres.dll 及其提供的所有 Exchange 叢集資源也不再存在，包含叢集信箱伺服器。相反地，Exchange 2010 會使用自己內部的高可用性模型。仍然使用 Windows 容錯移轉叢集的一些元件，但這些元件現在已由 Exchange 2010 整合至其他功能。

全球化的資料庫

在 Exchange 2010 中，每個資料庫會與單一、專用的記錄檔資料流相關聯，由一系列依序命名的 1 MB 的記錄檔表示。儲存群組的概念也已從 Exchange 2010 中移除。因為這些變更，Exchange 資料庫具有專用的記錄資料流，並且不再與其他資料庫共用記錄資料流。

不像舊版 Exchange，資料庫不再緊密繫結至特定信箱伺服器。此外，資料庫不再由其存放的信箱伺服器確認，伺服器名稱不再是資料庫識別的一部分。由於這些變更，資料庫現在是 Active Directory 和每一個 Exchange 組織中的通用物件。使用 Exchange 管理主控台時，資料庫現在由 [組織組態] 節點下的 [信箱] 節點管理。

每一部信箱伺服器最多可主控 100 個資料庫 (主動和被動資料庫合計)。資料庫總數等於伺服器上主動和被動資料庫的合計。復原資料庫不受 100 個資料庫的限制。

Exchange 2010 RTM 中連續複寫的變更

Exchange 2010 也提供 Exchange 2007 中引進的連續複寫技術。不過，這項功能已經大幅進展到可支援全新的高可用性功能和更大的延展性。一些基礎結構性變更包括：

  • 因為儲存群組已從 Exchange 2010 移除，連續複寫現在是在資料庫層級操作。Exchange 2010 仍然使用可延伸儲存引擎 (ESE) 資料庫，產生複寫至一或多個其他位置的交易記錄檔，並重新顯示為一或多個信箱資料庫的副本。每一個信箱資料庫最多可以有 16 個副本。

  • 記錄傳送不再使用伺服器訊息區 (SMB) 和 Windows 檔案系統通知。記錄傳送不再使用提取模式 (也就是被動副本會從作用中副本提取已關閉的記錄檔)。相反地，主動副本使用 TCP 型通知，以通知主動副本被動副本需要哪些記錄檔案。主動副本接著會透過 TCP 通訊端，將記錄檔案發送至每一個設定的被動副本。

  • Exchange 2010 連續複寫使用系統管理員定義的 TCP 連接埠來進行資料傳輸。此外，Exchange 2010 包含了針對資料流之網路加密和壓縮的內建選項。

  • 植入不再受限於只能使用作用中的資料庫副本。現在可以指定信箱資料庫的被動副本做為資料庫副本植入與重新植入的來源。

  • 資料庫副本僅適用於信箱資料庫。針對公用資料夾資料庫的備援和高可用性，建議您使用公用資料夾複寫。與 CCR (多個公用資料夾資料庫副本無法存在於同一個叢集) 不同的是，您可以使用公用資料夾覆寫在 DAG 中的伺服器之間覆寫公用資料夾資料庫。

  • 在 Exchange 2007 中，Microsoft Exchange 複寫服務負責重新顯示記錄到被動資料庫副本。當被動副本已啟動，會因重新顯示活動而在 Microsoft Exchange 資訊儲存服務裝載資料庫時，遺失由 Microsoft Exchange 複寫服務所建立的資料庫快取。這會將資料庫快取置於冷狀態 (cold state)。在此期間內用以快取讀取/寫入作業的資料庫快取大小很小 (冷)，因此能夠大幅減少讀取 I/O 作業。Exchange 2010 的被動副本重新顯示功能先前是由 Microsoft Exchange 複寫服務執行，已移至 Microsoft Exchange 資訊儲存服務。因此，會出現線上資料庫快取，並在發生容錯移轉或轉換時立即可供使用。

Exchange 2007 連續複寫中所使用的幾個概念也保留在 Exchange 2010 中。這些包含容錯移轉管理和分歧的概念、使用自動資料庫裝載撥號，以及使用複寫和客戶存取 (MAPI) 網路。

Exchange 2010 SP1 中連續複寫的變更

在 Exchange 2010 的 RTM 版本和 Exchange Server 2007 的所有版本中，連續複寫的運作方式是將主動資料庫副本產生的記錄檔複本傳送到被動資料庫副本。從 Exchange 2010 SP1 開始，這種連續複寫形式稱為*「連續複寫 - 檔案模式」。SP1 也引進了一種全新形式的連續複寫，稱為「連續複寫 - 區塊模式」*。在區塊模式中，每項更新都會寫入到主動資料庫副本的主動記錄緩衝區，同時也會傳送到每個被動信箱副本上的記錄緩衝區。當記錄緩衝區已滿時，每個資料庫副本都會依產生順序來建置、檢查及建立下一個記錄檔。若是故障對主動副本造成影響，將以多數或所有最新的更新來更新被動副本。主動副本不會等待複寫完成，以防止複寫問題影響用戶端體驗。

區塊模式可動態縮短從對主動副本進行變更到將變更複寫到被動副本的延遲時間。除了複寫個別的記錄檔寫入之外，區塊模式也會變更被動副本的啟動程序。如果發生失敗狀況時副本正處於區塊狀態，系統就會使用啟動程序中可用的任何局部記錄內容。如此即可避免讓主動副本上目前的記錄檔變成單一失敗點。

初始的作業模式一定是檔案模式。只有在檔案模式的連續複寫已經是最新時，才能使用區塊模式。記錄檔複製器會自動執行進入及離開區塊模式的轉換作業。當被動副本要求目前的記錄檔時，它會指出連續複寫是最新的 (副本佇列長度是 0)，而且系統應該會自動從檔案模式切換到區塊模式。

您可以監視 [MSExchange 複寫] 效能物件底下的 Continuous replication – block mode Active 效能計數器，以判斷被動資料庫副本是否為區塊模式。每個資料庫副本都有這個計數器的個別專屬執行個體。當被動副本是區塊模式時，此計數器的值會設為 1，而當被動副本是檔案模式時，則會設為 0。您也可以使用 Get-Counter 或 Get-WMIObject 指令程式來判斷這個計數器的值，如下列範例所示：

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

從 Exchange 2007 變更為傳輸暫放

Exchange 2010 Hub Transport server role 包含初次在 Exchange 2007 中採用的傳輸暫放功能。傳輸暫放可維護最近傳送給信箱受 CCR 或 LCR 保護的使用者所有的電子郵件佇列，協助保護防止資料遺失。當這些環境之一發生失真故障時，通常大部分的資料都會遺失，傳輸暫放因此自動復原失敗。

傳輸暫放只用於複寫的信箱資料庫。它不保護傳送到公用資料夾的郵件，也不保護傳送給信箱資料庫但沒有複寫的收件人之郵件。特定信箱資料庫的傳輸暫放佇列，位於包含 DAG 的 Active Directory 站台之所有 Hub Transport Server 上。

在 Exchange 2007 中，郵件會保留在傳輸暫放中，直到達到系統管理員定義的時間限制或大小限制為止。在 Exchange 2010 中，傳輸暫放現在是從複寫管線接收意見，以判斷哪些郵件已傳遞和複寫。郵件通過集線傳輸伺服器而前往 DAG 中的已複寫的信箱資料庫時，除非交易記錄顯示郵件已順利複寫至信箱資料庫的所有副本，或由其檢查過，否則都會在傳輸佇列 (mail.que) 中保留一份副本。在記錄已順利複寫至信箱資料庫的所有副本，或由其檢查過後，這些記錄中的郵件即從傳輸暫放中被截斷。透過只維護交易記錄檔尚未複寫的郵件副本，可維持較小的傳輸暫放佇列。

每個 DAG 的 Active Manager 都會在每個被動資料庫副本上追蹤最後檢查的記錄時間。在 Hub Transport Server 上執行的 Active Manager 用戶端會從 DAG 的待機 Active Manager (SAM) 取得這項資訊，並將資訊轉換成以時間為基礎的限制標準。接著 Hub Transport Server 會將傳輸暫放中訊息的傳遞時間與此限制標準進行比較。如果訊息的傳遞時間早於限制標準，便會從傳輸暫放截斷該訊息。

傳輸暫放也增強了帳戶對 Mailbox server role 所做的變更，可讓單一信箱資料庫在 Active Directory 站台之間移動。DAG 可擴充至多個 Active Directory 站台，因此，一個 Active Directory 站台的單一信箱資料庫，可容錯移轉至另一個 Active Directory 站台。當發生這種情況時，所有傳輸暫放的重新遞送請求，會同時傳送至 Active Directory 站台：原始站台和新站台。

集線傳輸和信箱共存於 DAG 時之路由行為的變更

當 Hub Transport Server 與當做 DAG 成員的信箱伺服器共存時，路由行為會有變更，以確定兩個伺服器角色中的恢復功能會為該伺服器上之使用者傳送和接收的郵件提供必要的保護。如果 Hub Transport Server 也是 DAG 成員而且它在本機上裝載了信箱資料庫副本，那麼會修改 Hub Transport Server role，使它現在會嘗試將本機信箱伺服器的郵件重新路由到相同站台中的另一個 Hub Transport Server。系統會新增這個額外的躍點，以便將郵件放置在不同 Hub Transport Server 上的傳輸暫放中。

例如，EX1 主控 Hub Transport server role 和 Mailbox server role，而且是 DAG 的成員。當郵件抵達 EX1 的傳輸，而且 EX1 指向信箱也在 EX1 的收件者時，傳輸會將郵件重新路由至站台內的另一個 Hub Transport Server (例如 EX2)，而且該伺服器會將郵件傳遞到 EX1 上的信箱。

對於 Microsoft Exchange 郵件提交服務，還有第二個類似的行為變更。這個服務已經過修改，使得當信箱與 Hub Transport Server 是 DAG 的成員時，它不會將郵件提交到本機集線傳輸角色。在此案例中，傳輸的行為是在相同 Active Directory 站台中的其他 Hub Transport Server 載入平衡提交要求，而且如果在相同站台中沒有其他可用的 Hub Transport Server，則會回復為本機 Hub Transport Server。

回到頁首

非 Mailbox Server Role 的高可用性

Hub Transport、Edge Transport、Client Access 及 Unified Messaging server role 的高可用性，是透過伺服器重複、負載平衡、網域名稱系統 (DNS) 循環配置以及主動式伺服器、服務及基礎架構管理的結合來達成。一般而言，您可以使用下列策略及技術來達成 Client Access server role、Hub Transport server role、Edge Transport server role 及 Unified Messaging server role 的高可用性：

  • Edge Transport   您可以部署多個 Edge Transport Server 並使用多個 DNS MX 資源記錄，來平衡這些伺服器之間的活動負載。您也可以使用網路負載平衡 (NLB) 為 Edge Transport Server 提供負載平衡與高可用性。

  • Client Access   您可以使用 NLB 或協力廠商硬體型網路負載平衡裝置，以取得 Client Access Server 的高可用性。

  • Hub Transport 您可以部署多個 Hub Transport Server 以取得內部傳輸的高可用性。在 Hub Transport server role 中，已利用下列方式設計了恢復功能：

    • Hub Transport Server 至 Hub Transport Server (組織內部)   組織內的 Hub Transport Server 至 Hub Transport Server 通訊會自動在目標 Active Directory 站台中可用的 Hub Transport Server 之間進行負載平衡。

    • Mailbox Server 至 Hub Transport Server (Active Directory 站台內部)   Mailbox Server 上的 Microsoft Exchange 郵件提交服務會自動在相同 Active Directory 站台中所有可用的 Hub Transport Server 之間進行負載平衡。

    • Unified Messaging Server 至 Hub Transport Server   Unified Messaging Server 會自動針對相同 Active Directory 站台中所有可用 Hub Transport Server 之間的連線進行負載平衡。

    • Edge Transport Server 至 Hub Transport Server   Edge Transport Server 會自動針對 SMTP 流量進行負載平衡，而該流量是已訂閱 Edge Transport Server 之 Active Directory 站台中所有 Hub Transport Server 的流量。

    如需額外的備援 (例如，需要 SMTP 轉送的應用程式)，則可以建立 DNS 記錄 (例如，relay.company.com)、指派 IP 位址，以及使用硬體負載平衡器將該 IP 位址重新導向多部 Hub Transport Server。您也可以將 NLB 用於 Hub Transport Server 上的用戶端連接器。使用硬體負載平衡器時，需要確認沒有組織內部流量會跨過硬體負載平衡器，因為組織內部流量會使用內建的負載平衡演算法 (如前所述)。

  • Unified Messaging   部署多部 Unified Messaging Server，其中兩部或兩部以上位於單一撥號對應表，可使整合通訊部署變得更具迅速復原性。整合通訊支援的 Voice over IP (VoIP) 閘道可設定為將來電以循環配置的方式路由傳送到 Unified Messaging Server。此外，這些閘道可為撥號對應表從 DNS 擷取伺服器清單。在這兩種情況下，VoIP 閘道器都會將來電提交到 Unified Messaging Server，若不接受來電，則會將來電提交到另一部 Unified Messaging Server，在建立通話時提供備援。

回到頁首

站台回復性

Exchange 2010 包含適用於高可用性和站台恢復的整合平台。結合 Microsoft Exchange 2010 的原生站台失敗恢復支援與適當規劃後，就能迅速利用次要資料中心為失敗的資料中心用戶端提供服務。資料中心或站台失敗的管理方式不同於可能導致伺服器或資料庫容錯移轉的失敗。在高可用性組態中，自動復原是由系統初始化，而失敗通常會讓郵件系統處於功能完整的狀態。相反地，資料中心失敗會被視為是災難復原事件，因此必須手動執行和完成復原，以便讓用戶端服務還原並讓中斷結束。您執行的程序稱為「資料中心轉換」。與許多災害復原的案例一樣，資料中心轉換的優先規劃和準備可以簡化復原程序，並縮短中斷的持續時間。

如需有關站台恢復規劃與部署的詳細資訊，請參閱規劃高可用性及站台恢復、部署高可用性及站台恢復以及資料中心轉換。

回到頁首

端對端可用性

Exchange 2010 也包含許多設計用來增加系統之端對端可用性的功能。這些功能包括：

  • 陰影備援

  • 線上移動信箱

  • 靈活的信箱保護

  • 增量重新同步處理

  • 協力廠商複寫 API

陰影備援

除了傳輸暫放功能和先前描述的路由行為增強功能外， 也新增了名為 *「陰影備援」*的 Hub Transport Server 新功能。在郵件的整個傳輸過程中，陰影備援提供郵件的備援。這項解決方案包含與傳輸暫放類似的技術。使用陰影備援，從傳輸資料庫刪除郵件的動作，會延遲到傳輸伺服器確認該郵件的所有下一個躍點皆已完成，才進行刪除。如果在報告成功傳遞之前有任何下一個躍點失敗，便會重新提交郵件以便遞送至下一個躍點。如需陰影備援的詳細資訊，請參閱瞭解陰影備援。

線上移動信箱

Exchange 2010 包含可讓您以非同步方式移動信箱的新功能。在 Exchange 2007 中，當您使用 Move-Mailbox 指令程式移動信箱時，指令程式會登入來源資料庫和目標資料庫，並將內容從一個信箱移至另一個信箱。以指令程式執行移動作業有幾個缺點：

  • 通常，信箱移動需要數小時才能完成，而在移動期間，使用者無法存取他們的信箱。

  • 如果用來執行 Move-Mailbox 指令程式的命令提示視窗關閉，那麼移動會終止，必須從頭重新啟動。

  • 用來執行移動的電腦會參與資料傳輸。如果系統管理員從其工作站執行指令程式，則信箱資料會從來源伺服器移到系統管理員的工作站，然後再到目標伺服器。

Exchange 2010 中 New-MoveRequest 指令程式可以用來執行非同步移動。與 Exchange 2007 不同的是，指令程式不會執行實際的移動。移動是由 Microsoft Exchange 信箱複寫服務執行；這是在 Client Access server 上執行的新服務。New-MoveRequest 指令程式會傳送要求至 Microsoft Exchange 信箱複寫服務。如需線上信箱移動的詳細資訊，請參閱瞭解移動要求。

靈活的信箱保護

Exchange 2010 的核心結構有數個變更會直接影響您保護信箱資料庫及它們所含信箱的方法。

其中一個重大變更是移除了儲存群組。在 Exchange 2010 中，每個資料庫會與單一記錄檔資料流相關聯，由一系列 1 MB 的記錄檔表示。每一部伺服器最多可以裝載 100 個資料庫。

Exchange 2010 的另一個重要變更是，資料庫不再緊密繫結至特定信箱伺服器。透過將資料庫複寫到多個不同的伺服器，資料庫行動性擴充了系統對於連續複寫的使用。這可提供更好的資料庫保護和更高的可用性。如果發生失敗，具有資料庫副本的其他伺服器就可以裝載資料庫。

讓多部伺服器裝載多個資料庫副本的功能，意味著如果您有足夠數目的資料庫副本，就可以使用這些副本做為備份。如需此策略的相關資訊，請參閱 瞭解備份、還原和嚴重損壞修復。

增量重新同步處理

Exchange 2007 引進了遺失記錄檔恢復和增量重新植入的概念。遺失記錄檔恢復是 ESE 的內部元件，可讓您復原 Exchange 信箱資料庫，即使一或多個最近產生的交易記錄檔已遺失或損毀也一樣可以復原。即使最近產生的記錄檔無法使用，遺失記錄檔恢復依然可讓信箱資料庫能夠裝載。遺失記錄檔恢復的運作方式是將資料庫寫入作業延遲到建立所指定數量的記錄檔產生時才執行。遺失記錄檔恢復會短暫延後資料庫檔案的最近更新。延遲寫入的時間長度會根據產生記錄的速度而定。

Exchange 2007 還採用重新植入的概念，透過遺失的記錄檔恢復之延遲重新顯示，提供交易記錄檔資料流在來源和目標儲存群組之間正確分岐的能力。在分歧的記錄已重新顯示之後，增量重新植入不提供在資料庫的被動副本中修正分歧的方法，此時必須執行完整重新植入。與 Exchange 2007 不同的是，Exchange 2010 中並沒有任何記錄檔遺失量需要進行完整重新植入。

在 Exchange 2010 中，*「增量重新同步處理」*是在以下條件下，自動修正資料庫副本中之分歧功能的新名稱：

  • 在所有已設定之資料庫副本的自動容錯移轉之後

  • 當已啟用新副本，且某些資料庫和記錄檔已存在於副本位置時

  • 當 Microsoft Exchange 複寫服務暫停或重新啟動之後恢復複寫時，

由於這些變更，所有 Exchange 2010 信箱資料庫遺失的記錄檔恢復，現在已硬式編碼為一個記錄檔。

當偵測到作用中資料庫和該資料庫的副本之間有分歧時，增量重新同步處理會執行以下工作：

  • 會搜尋過去的記錄檔資料流，以找到分歧點。

  • 會在分岐的副本上尋找變更過的資料庫分頁。

  • 會從作用中副本讀取已變更的分頁，然後從作用中副本複製必要的記錄檔。

  • 會將資料庫分頁變更套用至分歧的副本。

  • 會在分歧的副本上執行復原，並將必要的記錄檔重新顯示到資料庫副本中。

協力廠商複寫 API

Exchange 2010 還包含一個新的協力廠商複寫 API，它可讓組織使用協力廠商的同步複寫解決方案，代替內建的連續複寫功能。Microsoft 可支援使用此 API 的協力廠商解決方案，前提是解決方案需提供必要的功能來取代因為使用 API 而停用的所有原生連續複寫功能。只有當 DAG 在內部使用此 API 來管理及啟動信箱資料庫副本時，才支援解決方案。不支援在這些界限以外使用 API。此外，解決方案還必須符合適用的 Windows 硬體支援需求 (測試驗證並不是支援的必要條件)。

請注意，在部署使用內建協力廠商複寫 API 的解決方案時，解決方案廠商必須負責提供解決方案的主要支援。不論是複寫或非複寫的解決方案，Microsoft 都可支援 Exchange 資料。使用資料複寫的解決方案必須遵守 Microsoft 對於資料複寫的支援原則，如 Microsoft 知識庫文章 895847 Exchange Server 的多站台資料複寫支援 (機器翻譯) 所述。此外，利用 Windows 容錯移轉叢集資源模組的解決方案必須符合 Windows 叢集支援性需求，如 Microsoft 知識庫文章 943984 Microsoft 對於 Windows Server 2008 容錯移轉叢集的支援原則 所述。

Microsoft 對於使用協力廠商複寫 API 型解決方案之部署的備份與還原支援原則，與原生連續複寫部署相同。

如果您是尋找協力廠商 API 資訊的合作夥伴，請連絡您的 Microsoft 代表。如需 Exchange 2010 合作夥伴產品的詳細資訊，請參閱 Microsoft 合作夥伴 網站 (英文)。

回到頁首

 © 2010 Microsoft Corporation. 著作權所有，並保留一切權利。