高可用性和月臺復原能力Exchange Server

您可以設定 Exchange 伺服器和資料庫以獲得高可用性和月臺復原能力，以保護您的Exchange Server信箱資料庫及其包含的資料。 Exchange Server可將部署高可用性和復原性傳訊解決方案的成本和複雜性降至最低，同時提供高階的服務和資料可用性，以及對非常大型信箱的支援。

Exchange Server可讓所有大小和所有區段的客戶，藉由建置 Exchange 2010 中引進的原生複寫功能和高可用性架構，在其組織中大規模部署傳訊持續性服務。 如需 Exchange 2010 之後的變更清單，請參閱 舊版的高可用性和月臺復原能力變更。

重要詞彙

下列重要術語對於了解高可用性或站台回復性相當重要：

Active Manager

在 Microsoft Exchange 複寫服務內部運作的一個內部 Exchange 元件，主要負責透過在資料庫可用性群組 (DAG) 中容錯移轉的失敗監視和修正動作。

AutoDatabaseMountDial

信箱伺服器的內容設定，用以確定是否將被動資料庫副本自動裝載為新的主動副本，根據裝載副本所遺失的記錄檔數目而定。

連續複寫 - 區塊模式

在區塊模式中，每項更新都會寫入到主動資料庫副本的主動記錄緩衝區，同時也會傳送到封鎖模式下每個被動信箱副本上的記錄緩衝區。 當記錄緩衝區已滿時，每個資料庫副本會依產生順序建置、檢查和建立下一個記錄檔。

連續複寫 - 檔案模式

在檔案模式中，會從主動資料庫副本推送已關閉交易記錄檔至一個或多個被動資料庫副本。

資料庫可用性群組

最多 16 部 Exchange 伺服器的群組，裝載一組複寫的資料庫。

資料庫行動力

Exchange Server信箱資料庫複寫至其他 Exchange 伺服器並掛接在其他 Exchange 伺服器上的能力。

Datacenter

通常，這是指 Active Directory 站台，但是也可以指實體站台。 在此文件的內容中，資料中心等同於 Active Directory 站台。

資料中心啟動協調模式

DAG 設定的內容於啟用時會強制 Microsoft Exchange 複寫服務取得權限，以在啟動時裝載資料庫。

災害復原

用於以手動方式從失敗中復原的任何處理程序。 可以是影響單一項目的失敗，或是影響整個實體位置的失敗。

交換協力廠商複寫 API

Exchange 所提供的 API，可使用 DAG 的協力廠商同步複寫，來代替連續複寫。

高可用性

提供影響服務或資料 (例如網路、儲存或伺服器失敗) 的服務可用性、資料可用性和故障自動復原之解決方案。

增量部署

安裝Exchange Server後部署高可用性和月臺復原能力的能力。

延遲的信箱資料庫副本

記錄檔重新執行延隔時間大於 0 的被動信箱資料庫副本。

信箱資料庫副本

信箱資料庫 (.edb 檔和記錄檔) 為主動或被動。

信箱恢復功能

Exchange Server中統一高可用性和月臺復原解決方案的名稱。

受管理的可用性

由探查、監視和回應程式所組成的一組內部程序，結合了所有伺服器角色和所有通訊協定的監視與高可用性。

*over (發音為「star over」)

[switchovers] (轉換) 和 [failovers] (容錯移轉) 的簡寫。 轉換是指一或多個資料庫副本的手動啟動。 容錯移轉是指一或多個資料庫副本發生故障後的自動啟動。

安全網

先前稱為傳輸傾印機，這是傳輸服務的一項功能，可儲存 X 天的所有訊息複本。 預設值為 2 天。

陰影備援

一種傳輸伺服器功能，在郵件的整個傳送過程中提供郵件備援。

站台回復性

此組態可將郵件基礎結構擴充至多個 Active Directory 站台，當發生會影響任一站台的故障時，可為郵件系統提供運作持續性。

資料庫可用性群組 (DAG)

DAG 是內建于Exchange Server的高可用性和月臺復原架構的基底元件。 DAG 是最多 16 部 Exchange 伺服器的群組，可裝載一組資料庫，並可從影響個別資料庫、網路或伺服器的失敗中自動復原資料庫層級。 DAG 中的任何伺服器都可以主控來自 DAG 中任何其他伺服器的信箱資料庫副本。 當伺服器新增至 DAG 後，它即可與 DAG 中其他的伺服器搭配使用，以便針對影響信箱資料庫的失敗 (例如磁碟故障或伺服器失敗) 進行自動復原功能。 如需 DAG 的詳細資訊，請參閱資料庫可用性群組。

信箱資料庫副本

Exchange 2010 中首次導入的高可用性和網站復原功能會用於Exchange Server來建立和維護資料庫複本。 Exchange Server也會利用資料庫行動性的概念，也就是 Exchange 管理的資料庫層級容錯移轉。

資料庫行動性可中斷資料庫與伺服器的連線，並新增對多達 16 份單一資料庫副本的支援。 它還提供建立資料庫副本的原生體驗。

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

例如，如果 DAG 中的使用中資料庫因為基礎儲存體失敗而失敗，Active Manager 會自動復原，方法是容錯移轉至 DAG 中另一部伺服器上的資料庫複本。 在Exchange Server中，受控可用性會提供從遺失對資料庫的通訊協定存取權中復原的行為，包括回收應用程式背景工作集區、重新開機服務和伺服器，以及起始資料庫容錯移轉。

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

Active Manager

Exchange Server利用 Active Manager 來管理資料庫和資料庫複製健康情況、狀態、連續複寫，以及高可用性的其他層面。 如需 Active Manager 的相關資訊，請參閱 Active Manager。

站台回復性

在 Exchange 2010 中，您可以跨兩個資料中心部署 DAG，並在第三個資料中心內主控見證，以及為任一個資料中心的 Mailbox Server Role 啟用容錯移轉。 但您並未取得解決方案本身的容錯移轉，因為非信箱伺服器角色仍需要手動變更命名空間。

在 Exchange 2016 和 Exchange 2019 中，命名空間不需要隨 DAG 一起移動。 Exchange 運用容錯移轉透過多重 IP 位址、負載平衡建立至命名空間 (如果需要的話，使用啟用伺服器和停用伺服器的功能)。 現代 HTTP 用戶端會自動使用此備援。 HTTP 堆疊接受多重 IP 位址作為完整網域名稱 (FQDN)，如果第一個 IP 位址嘗試硬故障 (亦即無法連接)，將嘗試清單中的下一個 IP 位址。 軟故障 (連線在工作階段建立後遺失，或許是因為服務發生間歇性故障，例如，裝置丟棄封包並且必須停用) 期間，使用者可能需要重新整理其瀏覽器。

這意味著命名空間不再是單一失敗點，因為它是在 Exchange 2010 中。 在 Exchange 2010 中，訊息系統上最大的單一失敗點或許是您提供給使用者的 FQDN，因為它會告訴使用者前往何處。 在 Exchange 2010 範例中，變更 FQDN 前往的位置並不容易，因為您必須變更 DNS，然後處理 DNS 延遲，其中某些部分極具挑戰性。 瀏覽器中的名稱快取通常需大約 30 分鐘或更多，也必須處理。

在Exchange Server中，用戶端有多個位置可供使用。 Exchange Server中幾乎所有的用戶端存取通訊協定都是以 HTTP 為基礎。 範例包括 Outlook、EAS、EWS、Outlook 網頁版 和 EAC) 。 所有支援的 HTTP 用戶端都能夠使用多個 IP 位址，藉此在用戶端提供容錯移轉。 您可以設定 DNS 以在名稱解析期間處理至用戶端的多重 IP 位址。 例如，用戶端要求 mail.contoso.com 並送回兩個 IP 位址或四個 IP 位址。 然而，用戶端取回的許多 IP 位址會由用戶端確實使用。 這可讓用戶端更上一步，因為如果其中一個 IP 位址失敗，用戶端就會有一或多個嘗試連線的替代 IP 位址。 如果用戶端嘗試其中一個並且失敗，會等候大約 20 秒，然後嘗試清單中的下一個。 因此，如果您遺失用戶端存取服務陣列的 VIP，用戶端的復原會在大約 21 秒內自動進行。

優點包括下列各項：

• 在Exchange Server中，如果您遺失主要月臺中的負載平衡器，只要將它關閉 (，或是關閉 VIP) 並修復或取代它即可。 尚未在次要資料中心內使用 VIP 的用戶端會自動容錯移轉至次要 VIP，名稱空間和 DNS 都不會有任何變更。 這不僅意味著您不再須要執行轉換，也意味著不須要執行通常與資料中心轉換復原相關的作業。 在 Exchange 2010 中，您必須處理 DNS 延遲 (因此，建議將存留時間 (TTL) 設定為 5 分鐘，並使用容錯回復 URL)。 在 Exchange 2016 和 Exchange 2019 中，您不需要這麼做，因為您 (20 秒) 在 VIP 與資料中心) 之間的命名空間 (快速容錯移轉。

• 因為可以在資料中心之間容錯移轉命名空間，實現資料中心容錯移轉所需的只是跨資料中心 Mailbox server role 的容錯移轉機制。 若要為 DAG 自動容錯移轉，您只需要架構解決方案，讓 DAG 在兩個資料中心之間均分，然後在第三個位置放置見證伺服器，以便任何一個資料中心內的 DAG 成員均可仲裁，而不論含有 DAG 成員的資料中心之間的網路狀態為何。 如果您只有兩個資料中心，且第三個實體位置無法使用，您可以將見證伺服器放在 Microsoft Azure 虛擬機器上。 如需詳細資訊，請參閱 使用 Microsoft Azure VM 作為 DAG 見證伺服器 。

• 在此案例中，系統管理員僅專注於修復問題，而不是花時間還原服務。 您只需修復失敗項；儘管服務已經執行，仍會保持資料完整性。 修復損壞裝置時的緊迫性和壓力程度與還原服務時的緊迫性和壓力不同。 對一般使用者而言，壓力更適當；對系統管理員而言，壓力更小。

您可以允許容錯移轉，而不必執行轉換 (有時會誤稱為容錯回復)。 如果您遺失主要資料中心的伺服器，導致用戶端中斷 20 秒，您甚至可能不在意容錯回復。 此時，您應該專注在修復核心問題 (例如，更換故障的負載平衡器)。 回復上線並正常運作後，部分用戶端將可開始使用，其他用戶端可能維持經由第二個資料中心作業。

Exchange Server也提供可讓系統管理員處理間歇性失敗的功能。 間歇性故障表現為，例如，可進行初始 TCP 連線，但之後沒有任何反應。 間歇性故障需要採取某種形式的額外管理動作，因為它可能是由於更換投入使用的裝置所造成。 進行此修復程序時，裝置可能需要開機並接受一些要求，但必須在執行必要的設定步驟之後，才會確實準備好向用戶端提供服務。 在此案例中，系統管理員只需從 DNS 針對被更換的裝置移除 VIP，即可執行命名空間轉換。 在該服務期間，沒有用戶端可以嘗試與其連線。 更換程序完成後，系統管理員可以將 VIP 新增回 DNS，用戶端才最終可以開始使用。

如需規劃和部署月臺復原能力的詳細資訊，請參閱 規劃高可用性和月臺復原 能力和 部署高可用性和月臺復原能力。

協力廠商複寫 API

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

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

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

如果您是尋找協力廠商 API 資訊的合作夥伴，請連絡您的 Microsoft 代表。

高可用性和站台回復性文件

下表包含主題的連結，可協助您瞭解和管理 DAG、信箱資料庫複本，以及備份和還原Exchange Server。