瞭解高可用性的因素

 

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

上次修改主題的時間: 2015-03-09

規劃高可用性信箱伺服器和資料庫架構時,必須考量設計決策,例如:

  • 您將部署多個資料庫副本嗎?

  • 您將部署多少資料庫副本?

  • 您將會有提供站台恢復的架構嗎?

  • 您將部署何種信箱伺服器恢復模型?

  • 您將部署多少信箱伺服器?

  • 您將如何散發資料庫副本?

  • 您將使用哪個備份模型?

  • 您將使用哪個存放結構?

Microsoft Exchange Server 2010 可讓您使用獨立信箱伺服器或已設定信箱恢復功能的信箱伺服器,來部署您的信箱伺服器基礎結構。已設定信箱恢復功能的信箱伺服器採用資料庫可用性群組 (DAG),將多個資料庫副本有效率地散發到整個 DAG。藉由部署多個資料庫副本,您可以:

  • 設計一個解決方案來減少因最常見原因而要使用備份的機會。資料庫副本可提供對硬體、軟體和資料中心失敗的防護。

  • 將資料庫大小增加到 2 TB,因為您的復原機制是另一個資料庫副本,而不是從備份還原。

  • 如果您部署三個或更多資料庫副本,請考慮使用傳統 RAID 組態的替代存放結構,例如僅部分磁碟 (JBOD)。結合使用 JBOD 和較便宜的磁碟,可為您的組織帶來成本節省。

透過將使用中資料庫散發到參與 DAG 的所有伺服器上,可以讓硬體發揮最大的效率。

如需詳細資訊,請參閱規劃高可用性及站台恢復瞭解備份、還原和嚴重損壞修復

目錄

規劃要部署的資料庫副本數目

資料庫副本類型

站台恢復

規劃信箱伺服器恢復模型

規劃要部署的信箱伺服器數目

規劃資料庫副本配置

規劃備份模型架構

規劃儲存模型架構

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

規劃要部署的資料庫副本數目

瞭解信箱資料庫複本中所討論,DAG 成員可以裝載每個信箱資料庫的一份副本,且在產品的 Enterprise Edition 中每一伺服器最多能有 100 個資料庫 (使用中副本和被動副本均計入此限制)。這表示 16 個成員的 DAG 所支援的資料庫數目限制在 1,600 個 (每一伺服器 100 個資料庫副本 × 每一 DAG 16 部伺服器 ÷ 每一資料庫一份副本 = 每一 DAG 1,600 個資料庫)。

在高可用性組態中,部署資料庫單一副本是沒有價值的,因為它不會提供資料備援。您可以使用公式來確定特定 DAG 可支援的資料庫數目。例如,若您選擇 D 作為要部署的資料庫數目、C 作為每個資料庫的副本數、S 作為伺服器數目,則適用下列公式:

  • D × C = DAG 中的資料庫副本總數

  • (D × C) ÷ S = 每一伺服器的資料庫副本數

注意事項附註:
產生的每一伺服器資料庫數目在使用 Enterprise Edition 時必須為 100 或以下,使用 Standard Edition 時則必須為 5 或以下。

例如,假設您的 DAG 有 6 部伺服器和 84 個信箱資料庫,且每個資料庫有 3 份副本(請注意 6 部伺服器是 3 份副本的整數倍數)。適用下列規則:

  • 84 個資料庫 × 3 份副本 = 總計 252 個資料庫

  • 252 個資料庫 ÷ 6 部伺服器 = 每一伺服器 42 個資料庫副本

在另一個範例中,您的 DAG 有 4 部伺服器和 136 個信箱資料庫,且每個資料庫有 3 份副本。適用下列規則:

  • 136 個資料庫 × 3 份副本 = 總計 408 個資料庫

  • 408 個資料庫 ÷ 4 部伺服器 = 每一伺服器 102 個資料庫副本

由於 102 大於 100,因此提議的案例不是有效的 DAG 設計。

回到頁首

資料庫副本類型

資料庫副本有兩種類型:

  • 高可用性資料庫副本

  • 延遲的資料庫副本

高可用性資料庫副本是重新執行延隔時間設定為零的副本。顧名思義,高可用性資料庫副本會由系統保持在最新狀態、可自動由系統啟動,且可用來為信箱服務和資料提供高可用性。

延遲的資料庫副本是設定為延遲交易記錄檔重新顯示一段時間的副本。延遲的資料庫副本的設計目的是要提供時間點保護,可用於從儲存邏輯損毀、管理錯誤 (例如,刪除或清除中斷連線的信箱) 和自動化錯誤 (例如,大量清除中斷連線的信箱) 中復原。

通常,延遲的資料庫副本不會由於 Active Manager 最佳副本選擇演算法而啟動。因為部署延遲的資料庫副本是為了減輕操作風險,因此不應加以啟動。如果加以啟動且發出裝載要求,則記錄檔重新顯示會開始,並重新顯示所有要求的記錄檔,以使資料庫處於最新及正常關機狀態,因而失去時間點功能。

如需如何針對一個或多個資料庫副本在信箱伺服器層級封鎖啟動或擱置啟動,以防止自動啟動資料庫副本 (例如延遲的資料庫副本) 的詳細資訊,請參閱 Set-MailboxServerSuspend-MailboxDatabaseCopy

回到頁首

站台恢復

您的環境可能由多個資料中心組成。在 Exchange 2010 設計過程中,請決定您要在單一資料中心中部署 Exchange 基礎結構,或是跨兩個或多個資料中心散發它。您組織的復原服務等級協定 (SLA) 應該定義主要資料中心失敗後所需的服務等級為何。

如果您的 Exchange 部署將會跨多個資料中心以支援站台恢復目標,請考量適用哪個使用者散發模型。根據與資料中心相關的信箱位置,有兩種類型的使用者散發模型:

  • 主動/被動使用者散發模型

  • 主動/主動使用者散發模型

如果使用者信箱主要位在單一資料中心內 (或者如果使用者透過單一資料中心存取其資料),而且存在使用者在正常作業期間繼續透過主要資料中心存取其資料的 SLA 需求,則您的架構是主動/被動使用者散發模型。

如果使用者信箱分散在不同資料中心,而且存在使用者在正常作業期間繼續透過主要資料中心存取其資料的 SLA 需求,則您的架構是主動/主動使用者散發模型。

在主動/被動使用者散發模型中,您可如下圖所示部署您的架構,其中作用中信箱是由主要資料中心來裝載,但資料庫副本是部署在次要資料中心中。

具有兩個資料中心的主動/被動使用者散發模型

主動/主動使用者分配模型

下圖所示的架構可能會用於主動/主動使用者散發模型。

具有兩個資料中心的主動/主動使用者散發模型

主動/被動分配模型

不過,上圖中所示的架構存有風險。廣域網路 (WAN) 是 DAG 的單一失敗點。遺失 WAN 會導致第二資料中心中 DAG 成員的仲裁遺失。在此範例中,Windows 容錯移轉叢集總共有五票 (四個 DAG 成員加上見證伺服器),若要使容錯移轉叢集維持正常運作,必須隨時有三票可用。有三票位在 Redmond 資料中心,還有兩票位在波特蘭資料中心。遺失 WAN 連線會造成波特蘭資料中心只主控兩票,因而不足以維持仲裁。Redmond 資料中心有三票,因此可維持仲裁並繼續服務作用中信箱 (只要這三票正常運作)。

為了減輕主動/主動使用者散發模型的風險,我們建議部署兩個 DAG,如下圖中所示。

主動/主動使用者散發模型的兩個 DAG

跨兩個主動資料中心的兩個 DAG

DAG1 裝載 Redmond 資料中心的作用中信箱,且實作為主動/被動使用者散發模型,並在波特蘭資料中心部署被動資料庫副本。DAG2 裝載波特蘭資料中心的作用中信箱,且實作為主動/被動使用者散發模型,並在 Redmond 資料中心部署被動資料庫副本。

此架構可安然渡過 WAN 遺失情況:

  • 在 Redmond 資料中心,DAG2 的信箱伺服器成員會由於遺失仲裁而進入失敗狀態,不過 DAG1 的作用中信箱伺服器成員會維持正常運作,並服務使用者。

  • 在波特蘭資料中心,DAG1 的信箱伺服器成員會由於遺失仲裁而進入失敗狀態,不過 DAG2 的作用中信箱伺服器成員會維持正常運作,並服務使用者。

如需相關資訊,請參閱規劃高可用性及站台恢復

回到頁首

規劃信箱伺服器恢復模型

Exchange 2010 信箱伺服器容量規劃的一個關鍵因素,是在設定信箱恢復功能時,決定您計劃在每一伺服器上啟動多少資料庫副本。雖然有一系列設計可供選擇,但建議使用下列各節中所述的兩個模型。

啟動所有資料庫複本的設計

您可以設計伺服器架構,以處理變成主動的所有已裝載資料庫副本。例如,如果您的伺服器裝載了 35 個資料庫副本,則您可設計處理器與記憶體,以容納所有 35 個在使用者活動尖峰時間為主動的資料庫。此解決方案通常會成對部署。例如,如果部署四部伺服器,一對是伺服器 1 和 2,第二對是伺服器 3 和 4。此外,針對此案例設計時,您將每部伺服器的大小調整為不超過正常執行階段作業之可用資源的 40%。

在本主題所討論的兩個模型中,此模型有較高的伺服器計數。

針對故障案例的設計

您可以設計伺服器架構,以在您規劃處理最糟失敗案例期間處理作用中信箱負載。此模型有許多考量因素,包括站台恢復功能、RAID 儲存區與 JBOD、DAG 大小,以及資料庫副本計數。此容量規劃模型能夠在資金成本、可用性與用戶端效能特性之間取得平衡。

假設資料庫副本會隨機平均散發:

  • 針對自動、單一成員伺服器失敗所設計,該失敗發生於每一信箱資料庫有兩個高可用性資料庫副本之兩個成員或三個成員的 DAG 組態中。

  • 針對雙成員伺服器失敗 (在第二次失敗後手動啟動) 所設計,該失敗發生於每一信箱資料庫有三個高可用性資料庫副本之三個成員的 DAG 組態中。

  • 針對自動、雙成員伺服器失敗所設計,其中 DAG 有四個或多個成員,且每一信箱資料庫有三個或多個高可用性資料庫副本。

如果您選擇此容量規劃模型,強烈建議您限制每一伺服器可啟動的資料庫數目,以便單一伺服器不會變得超載,而提供不良的用戶端體驗。

您可以設定主動資料庫上限,來限制資料庫數目。您可以在 Exchange 管理命令介面中執行 Set-MailboxServer -MaximumActiveDatabases,來設定此限制。在 DAG 中的每部伺服器上設定此限制,以符合您的部署所支援的最大作用中資料庫數。

如需詳細資訊,請參閱資料庫可用性群組設計範例

回到頁首

規劃要部署的信箱伺服器數目

決定要部署的信箱伺服器數目時,請使用要部署之資料庫副本數的倍數。例如,如果計劃部署三個資料庫副本,請使用 3、6、9、12 或 15 部伺服器來開始設計。

確定 DAG 中伺服器數目的起點後,請根據信箱數目、失敗設計模型,以及其他可能增加或減少所需信箱伺服器數目的設計限制,適當地調整 DAG 成員數。

許多組織會遇到的一個設計限制,是可放在伺服器上的信箱數目上限。例如,如果組織有 20,000 個信箱,且只有 25% 會受失敗事件影響,那麼可在單一伺服器上部署的信箱數目上限為 5,000。這最少需要部署四部信箱伺服器。

選取的伺服器硬體和儲存模型也可能導致需要調整每部伺服器上部署的信箱數目或資料庫副本數目,這可能影響信箱伺服器的總數。

多重角色伺服器與獨立角色伺服器的比較

在 Exchange Server 2007 中,Client Access 和 Hub Transport server role 需要位在與叢集信箱伺服器不同的伺服器上。在 Exchange 2010 中,叢集信箱伺服器已不存在,因此這項限制也不再適用。Client Access 和 Hub Transport server role 可裝載在 DAG 成員上,提供改良的部署選項。

部署多重角色伺服器 (Mailbox、Client Access 和 Hub Transport server role 都在相同伺服器上) 時,會簡化大部分的架構。除了 Edge Transport 和 Unified Messaging server 外,所有 Exchange 2010 伺服器可以相同。這些伺服器可以有相同的硬體、軟體安裝程序和組態選項。不同伺服器間的一致性可簡化 Exchange 實作的管理。

多重角色伺服器 (在高規模環境中) 可允許更有效率地使用高核心計數伺服器,以提供高 Megacycle 功能。每個角色在個別部署時,建議最多有兩個填入的處理器通訊端。當結合角色時,建議的處理器通訊端數目上限為四個。伺服器可以有較大的工作負載,以減少組織中的整體伺服器數目。部署較少的伺服器可減少管理這些伺服器的成本,因為多重角色伺服器可將成本從週期性營運費用變更為一次性資本費用。減少伺服器計數可大幅降低電力、冷卻和資料中心空間的需求,因而進一步減少週期性營運費用。

雖然多重角色概念很有效率,但獨立伺服器角色仍可能適用。例如,在某些虛擬環境中或利用特定硬體架構時 (例如無法適當隔離硬體的 Blade Server 基礎結構),可能適用獨立角色部署。

部署多重角色伺服器時,必須正確設計處理器和記憶體架構。從處理器觀點,應該確認 Mailbox server role 不會在失敗模式期間耗用超過可用 Megacycle 的 40%,並保留 40% 給 Hub Transport 和 Client Access server role。為了確保有足夠的記憶體可供所有伺服器角色使用,請遵循瞭解信箱資料庫快取中所定義的記憶體指引。

如需詳細資訊,請參閱瞭解容量計劃中的多個伺服器角色組態

回到頁首

規劃資料庫副本配置

在高可用性設計過程中,您需要設計平衡的資料庫副本配置。規劃資料庫副本配置時,應使用下列設計原則:

  • 請確認您透過隔離每個副本,將特定信箱資料庫的多個資料庫副本失敗降到最低。例如,請不要將超過一個特定信箱資料庫的資料庫副本,放在相同的伺服器機架或相同的儲存陣列中。否則,機架或陣列失敗將導致相同資料庫的多個副本失敗,因而影響資料庫的可用性。

  • 請以一致、分散的方式配置資料庫副本,以確保在失敗後平均散發作用中信箱資料庫。任一特定伺服器上每個資料庫副本的啟動喜好設定總和必須相等或接近相等,因為這會在失敗後造成大約相等的散發,假設複寫保持在狀況良好及最新狀態的話。

如需詳細資訊,請參閱資料庫副本佈局設計

回到頁首

規劃備份模型架構

Exchange 2010 包含了幾種功能和架構變更,如果正確部署與設定,可以提供原生資料保護,不再需要進行傳統的資料備份。請使用下表來判斷您是否需要繼續使用傳統備份模型,或者可以在 Exchange 2010 中實作原生資料保護功能。

問題 減輕方式

軟體失敗

信箱恢復功能 (多個資料庫副本)

硬體失敗

信箱恢復功能 (多個資料庫副本)

站台或資料中心失敗

信箱恢復功能 (多個資料庫副本)

意外或惡意刪除項目

使用符合或超過項目復原 SLA 之間隔的單一項目復原和刪除項目保留

實體損毀案例

單一頁面還原 (高可用性資料庫副本)

邏輯損毀案例

單一項目復原

行事曆修復助理員

信箱移動

New-MailboxRepairRequest Cmdlet

時間點備份

管理錯誤

時間點備份

自動化錯誤

時間點備份

Rogue 系統管理員

時間點備份 (隔離)

企業或法規遵循需求

時間點備份 (隔離)

邏輯損毀通常是需要時間點備份的案例。不過,使用 Exchange 2010 時,有幾個可用於減少時間點備份需求的選項:

  • 使用單一項目復原時,如果使用者變更任何信箱資料夾中項目的特定內容,則在將修改寫入資料庫之前,會將一份項目儲存在 [可復原的項目] 資料夾中。如果修改郵件產生損毀的副本,則可還原原始項目。

  • 行事曆修復助理員會偵測並修正位於信箱伺服器上的信箱中,單一和週期性會議項目內發生的不一致,如此收件者就不會錯過會議通知或是收到不可靠的會議資訊。

  • 在信箱移動期間,Microsoft Exchange 信箱複寫服務會偵測損毀的項目,且不會將這些項目移至目標信箱資料庫。

  • Exchange 2010 Service Pack 1 (SP1) 引進了 New-MailboxRepairRequest Cmdlet,可用於修正搜尋資料夾、項目計數、資料夾檢視和父/子資料夾問題導致的損毀。

時間點備份可以是傳統備份或延遲的資料庫副本,兩者都提供相同的功能。如何在兩者中選擇取決於您的復原 SLA。復原 SLA 定義了復原點目標 (如果發生嚴重損壞,必須在特定時間範圍內還原資料),以及必須保留備份的時間長度。如果復原 SLA 為 14 天或以下,可以使用延遲的資料庫副本。如果復原 SLA 大於 14 天,則必須使用傳統備份。對於 Rogue 系統管理員或針對企業或法規遵循案例,時間點備份通常是與郵件基礎結構和郵件 IT 員工分開維護,郵件 IT 員工會指定傳統備份解決方案。

如果您選擇維護時間點備份,幾個設計層面可能會改變:

  • 部署延遲的資料庫副本可能會影響儲存。由於 ReplayLagTime 設定,必須為延遲的資料庫副本上的交易記錄檔配置額外空間。此外,延遲的資料庫副本的配置可能影響您的儲存架構(如需詳細資料,請參閱本主題稍後的<規劃儲存模型架構>)。

  • 根據大量陰影複製服務 (VSS) 解決方案的類型而定,部署傳統備份解決方案會對邏輯單元編號 (LUN) 配置造成影響,因為在硬體型 VSS 複製解決方案中,每一資料庫架構需要兩個 LUN。

視儲存架構而定,使用傳統備份解決方案可能需要大幅減少所要的使用者信箱大小,以符合您的備份與還原時間範圍 SLA。

部署 Exchange 原生資料保護時,可在信箱資料庫上啟用循環記錄。啟用循環記錄時,請確認將足夠的容量內建到系統中,以便解決方案可安然渡過防止記錄截斷的嚴重損壞事件。在最低限度下,您應該確認至少有三天的交易記錄檔容量 (不包含延遲的副本需求)。如需循環記錄如何與連續複寫搭配運作的詳細資訊,請參閱瞭解備份、還原和嚴重損壞修復

如需有關規劃備份的其他資訊,請參閱:

回到頁首

規劃儲存模型架構

Exchange 2010 提供儲存設計彈性。Exchange 2010 包含效能、可靠性和高可用性的改良,可讓組織在一系列儲存裝置上執行 Exchange。以 Exchange 2007 中引入的磁碟輸入/輸出 (I/O) 改良為基礎,最新版的 Exchange 需要較少的儲存效能,且更能容忍儲存失敗。

請選取可確保平衡容量需求與 I/O 需求的儲存平台,同時確保解決方案提供可接受的磁碟延遲,以及具有回應功能的使用者體驗。

RAID 或 JBOD

決定要使用 RAID 技術還是 JBOD 方法來實作儲存平台 (假設儲存平台允許 JBOD 組態)。從 Exchange 觀點,JBOD 表示將資料庫及其關聯的記錄檔都儲存在單一磁碟上。若要在 JBOD 上部署,必須至少部署三個高可用性資料庫副本。利用單一磁碟是單一失敗點,因為當磁碟失敗時,位在該磁碟上的資料庫副本會遺失。如果至少有三個資料庫副本,可確保一個副本 (或磁碟) 發生失敗時,能透過另外兩個副本提供容錯。不過,配置三個高可用性資料庫副本,以及使用延遲的資料庫副本,可能會影響儲存設計。下表顯示 RAID 或 JBOD 考量的指導方針。

RAID 或 JBOD 考量

資料中心伺服器 兩個高可用性副本 (總計) 三個高可用性副本 (總計) 每一資料中心兩個或多個高可用性副本 一個延遲的副本 每一資料中心兩個或多個延遲的副本

主要資料中心伺服器

RAID

RAID 或 JBOD (兩個副本)

RAID 或 JBOD

RAID

RAID 或 JBOD

次要資料中心伺服器

RAID

RAID (1 個副本)

RAID 或 JBOD

RAID

RAID 或 JBOD

若要使用主要資料中心伺服器在 JBOD 上部署,DAG 中需要有三個或多個高可用性資料庫副本。如果在裝載高可用性資料庫副本的相同伺服器上混合延遲的副本 (例如,不使用專用的延遲的資料庫副本伺服器),則至少需要兩個延遲的資料庫副本。

若要讓次要資料中心伺服器使用 JBOD,則次要資料中心內至少要有兩個高可用性資料庫副本。如果次要資料中心內的副本遺失,將不需要跨 WAN 進行重新植入,也不會在啟動次要資料中心時造成單一失敗點。如果在裝載高可用性資料庫副本的相同伺服器上混合延遲的資料庫副本 (例如,不使用專用的延遲的資料庫副本伺服器),則至少需要兩個延遲的資料庫副本。

針對專用的延遲的資料庫副本伺服器,資料中心內至少必須有兩個延遲的資料庫副本,才能使用 JBOD。否則,遺失磁碟會導致遺失延遲的資料庫副本,以及失去防護機制。

如需詳細資訊,請參閱瞭解儲存裝置組態

回到頁首

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