共用方式為

瞭解容量計劃中的多個伺服器角色組態

  • 發行項

 

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

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

伺服器硬體中有幾個趨勢合乎 Microsoft Exchange Server 2010 時程。其中一個趨勢是處理器效能大幅提升，以及實體處理器上支援的處理器核心數目增加。這表示，在擁有多核心處理器的標準伺服器上部署單一 Exchange 伺服器角色，可能會讓可用 CPU 的一大部分無法獲得充分利用。有些客戶期望伺服器虛擬化能更有效地利用伺服器 CPU 資源。而有些客戶則想要將 Exchange 伺服器角色合併到同一部實體伺服器上。這兩種都是有效的解決方案。

另一個趨勢是擁有多核心處理器與 10 到 16 個內部磁碟之伺服器模型的可用性。如果您考量 10 到 16 個磁碟所提供的每秒輸入/輸出異動量 (IOPS) 能夠支援的信箱數目，信箱伺服器角色本身所利用的資源通常不會超過可用 CPU 資源的一半。而在這部伺服器上加入 Client Access server role 和 Hub Transport server role，將能更有效地利用伺服器容量。

您可以使用本主題中的資訊做為指引，了解何時部署多重角色伺服器組態，以及如何正確規劃多重角色伺服器組態。以下範例將說明如何決定多重角色伺服器之伺服器大小的程序。

目錄

建議使用多重角色組態的原因

建議使用多重角色組態的情況

不建議使用多重角色組態的情況

多重角色伺服器的硬體建議

在 DAG 中部署多重角色伺服器

Exchange 2010 多重角色案例的調整大小範例

建議使用多重角色組態的原因

首先，最重要的，相較於我們的基準處理器組態，在今日您所能取得的硬體皆具備相當快速的處理器，可產生 5,000-6,000 Megacycles。配置包含 2 x 4 核心 Intel Xeon x5470 3.33 GHz 處理器。(您可以於 信箱伺服器處理器容量規劃 中的「信箱伺服器的容量規劃範例」一節中瞭解我們的基準處理器組態之更多資訊。)如果您要使用現今巿面上的處理器更換在您環境中的處理器架構，並將其他所有的環境要素保持相同，則您會看到處理器使用率大幅減少。

若要有效地降低您所購買的伺服器之擁有權總成本，您應該確保系統具有高效率的使用率，這意謂著系統於尖峰負載時最壞的失敗模式期間，必須達到和維持近 80% 的 CPU 使用率。以下有四種方式能讓您能有效率地利用現今巿面上所能取得的處理器：

  • 藉由在每台伺服器上部署更多的作用中信箱，以增加工作量。

  • 引進虛擬層，並部署信箱角色作為來賓機器，與部署額外的來賓機器。

  • 在系統上部署額外的 Exchange 伺服器。

  • 結合上述方法，以找出最佳的設定來將硬體運用得淋漓盡致。

部署具有多重角色架構的 Exchange 2010 可提供數種優勢：

  • 多重角色架構變成了以建置組塊為基礎的架構。有了多重角色架構，在 Exchange 環境中的所有伺服器 (不含整合通訊和邊際傳輸) 皆完全相同—相同的硬體、相同的組態等等。這種統一性能夠簡化硬體的訂購程序及伺服器的維護與管理作業。  

    • 從成本面而言，整體目標是確保從 CPU 方面與磁碟方面能獲得平衡的架構。在不同的機器上部署伺服器角色可能會造成長期成本的不利條件，因為您可能會購買到比您實際使用需求更多的 CPU、磁碟與記憶體資源。例如，考量僅主控用戶端存取伺服器角色的伺服器。許多伺服器能讓您以非常經濟的方式增添特定數量的磁碟—當您部署那些數量的磁碟，而更重要的是使用它們，基本上是零成本。但是，如果您所部署的伺服器角色使用的程度遠遠少於特定的磁碟數量，您便是將金錢耗費在未被充分利用或完全不被利用的磁碟控制器上。

  • 在許多情況下，使用多重角色架構能讓您在環境中擁有更少的實體 Exchange 伺服器。更少的實體伺服器即意謂著更低的成本，原因分述如下：

    • 營運支出幾乎總是高於資本支出。在伺服器的產品壽命期間的管理費用已超出其購買的成本。

    • 您購買更少的 Exchange 伺服器授權。多重角色伺服器對於一台 Exchange 伺服器及一個作業系統僅需要一個授權，而將角色分開則需要多個 Exchange 伺服器授權，並可能需要多個作業系統授權。如需相關資訊，請參閱關於授權：虛擬環境之授權 (英文)。

    • 部署更少的伺服器會在其餘的基礎設施上產生涓滴效應。例如，部署更少的實體伺服器可能會減少 Exchange 基礎設施所需的整體機架與佔地空間，進而減少電力與冷卻成本。

  • 相較於部署單一角色伺服器，多重角色架構能將工作量完美地分配至大量的伺服器上，因為所有的信箱伺服器也變成了集線傳輸伺服器與用戶端存取伺服器。此種架構提供了兩項優勢：

    • 從延展性方面來看，您正將工作量分配至大量的實體機器上。在失敗事件期間，在剩餘的伺服器上增加的工作量僅會遞增地增加，這確保不會對該伺服器所執行的其他功能帶來不利的影響。

    • 從恢復性方面來看，該解決方案能自多數集線傳輸與用戶端存取角色 (或服務) 失敗情況中倖免，並持續提供服務。

因上述因素，在多數情況下，我們建議的 Exchange 2010 部署策略即是多重角色伺服器組態。

建議使用多重角色組態的情況

以下為建議在多數情況下使用多重角色組態的原因：

  • 簡單的調整單位   預期信箱數目將有所成長的組織，應考慮部署多重角色伺服器。因為每一部多重角色伺服器都代表一個建置基礎，而這個模型方便未來加入建置基礎，以支援容量增加的需要。

  • 需要利用現代處理器的大規模部署   根據量產發行 (RTM) 版本 Exchange 2010 之前執行的延展性測試，多重角色伺服器可以在單一伺服器內有效使用六核心 (或更高) 的處理器。藉由此功能，大型組織可以不必將 Mailbox server role、Hub Transport server role 以及 Client Access server role 分別部署在處理器核心較少的伺服器上，而是改為合併這些角色，從而減少了伺服器的數量。此方式可利用先前描述的建置組塊模型，為大規模部署提供建置組塊平台，同時減少了所需伺服器的總數。在進行生產部署之前，應先藉由實驗室測試對核心較多的系統之多重角色組態的延展性進行驗證。

  • 具備內部儲存能力的伺服器部署   時下有許多伺服器都具備兩個實體多核心處理器和 10 到 16 個內部磁碟。Exchange 2010 中所提供的多項改進功能可降低 I/O 需求，讓這些伺服器成為經濟實惠的解決方案。根據使用者設定檔和磁碟類型而定，這些伺服器通常支援多達 4,000 個信箱。建議您在這些伺服器上加入 Client Access server role 和 Hub Transport server role 以便運用額外的 CPU，並且讓伺服器成為自給自足的建構基礎。

  • 降低風險的案例，其中信箱伺服器上裝載的信箱數目有所限制   對於風險管理原則限制信箱伺服器上可部署之信箱數目的部署而言，多重角色伺服器是一種解決方案。例如，擁有 10,000 個信箱的組織規定單一伺服器中斷所影響的信箱，不能超過環境中所有信箱的 25%。此需求會將每一部信箱伺服器的信箱數目限制在 2,500 個。該伺服器上的其他容量可透過將 Client Access server role 和 Hub Transport server role 加入伺服器的方式加以運用。

  • 小型組織與分公司部署   除以下註明外，當使用 Windows 網路負載平衡功能時，對於主要目標為盡量減少要管理的實體伺服器、作業系統執行個體及 Exchange 伺服器數目的部署而言，建議採用多重角色部署的解決方案。在同一部實體伺服器上執行 Client Access、Hub Transport 及 Mailbox server 色能夠提供必要的角色備援，而且僅需要兩部或三部實體伺服器。

建議使用多重角色組態的原因

不建議使用多重角色組態的情況

以下為不建議使用多重角色組態的情況：

  • 欲採用 Windows 網路負載平衡 (NLB) 的小型組織或分公司部署   多重角色伺服器對於其中部署兩部或三部多重角色伺服器作為資料庫可用性群組 (DAG) 成員的小型部署而言，不一定適用。如需 DAG 的詳細資訊，請參閱管理資料庫可用性群組。加入本身為 DAG 成員之信箱伺服器的叢集元件會阻止 NLB 安裝到伺服器上。如需負載平衡建議的詳細資訊，請參閱 瞭解 Exchange 2010 中的負載平衡。不過，仍然需要使輸入用戶端存取伺服器的流量獲得負載平衡。這種情況下可以選擇兩種主要的做法：

    • 購買硬體負載平衡裝置。雖然市面上的確有一些入門的 NLB 裝置，但是這種做法仍然可能所費不貲，尤其是對於較小型的環境而言。

    • 虛擬化 Exchange 伺服器角色。在某些環境中，有限的伺服器數目可能必須在 Exchange 2010 伺服器所在的實體硬體上部署網域控制站、檔案和列印伺服器，以及其他應用程式。建議您實作實體伺服器作為主機伺服器，並且在虛擬環境內隔離應用程式。有了這項隔離，您就可以針對虛擬機器上執行的用戶端存取伺服器執行 NLB。

  • 虛擬   虛擬機器所能主控的作用中信箱之最大數量可能會根據合併郵件設定檔與在多重角色組態中運行而減少。如果您具有輕度郵件傳遞使用者，多個伺服器角色同時位於一個虛擬機器中可能具有意義。然而，如果您具有重度郵件傳遞使用者，您位於虛擬機器內的資源可能受限，因此您可能需要減少每個信箱虛擬機器的信箱數量，或是將角色分開至不同的虛擬機器中。在這些情況下，較有效的方式是在每一部虛擬機器上部署單一 Exchange 伺服器角色，或是針對每一部信箱伺服器虛擬機器部署一個結合的用戶端存取與集線傳輸虛擬機器。

    注意事項附註：
    您無法在 Hypervisor 主機伺服器上安裝 Exchange 伺服器角色。主機伺服器上只可以部署管理軟體 (例如，防病毒軟體、備份軟體或虛擬機器管理軟體)。主機伺服器上不應該安裝其他伺服器應用程式 (例如，Exchange、Microsoft SQL Server 或 Active Directory)。主機伺服器應該專用於執行來賓虛擬機器。

如需相關資訊，請參閱 瞭解容量計劃中結合用戶端存取和集線傳輸的角色組態。

建議使用多重角色組態的原因

多重角色伺服器的硬體建議

一般而言，多重角色伺服器應調整為將可用處理器核心的一半用於信箱伺服器角色，另一半則用於 Client Access server role 和 Hub Transport server role。Microsoft 不會指定多重角色伺服器建議的處理器核心之最大數量。但會提供最多可裝入的處理器插槽數。這是指在連結多核心處理器之主機板上的處理器插槽數量。如需相關資訊，請參閱 瞭解處理器組態和 Exchange 效能。

除了考量處理器架構外，部署多核心組態時，也必須正確估量記憶體大小。如需相關資訊，請參閱 瞭解記憶體組態和 Exchange 效能。

在 DAG 中部署多重角色伺服器

當您在 DAG 中部署單一角色信箱伺服器時，請考慮單一和多重伺服器失敗的容量規劃與信箱伺服器負載之間的關係。如果您的 DAG 中有四部伺服器，請將信箱伺服器的容量調整為 50%，如此一來，在兩部信箱伺服器同時發生錯誤時，伺服器就能容納作用中使用者數目的兩倍。由於 Hub Transport Server 和 Client Access Server 位於不同的實體伺服器上，因此這些伺服器上的負載不會因為失去一或兩部信箱伺服器而受到影響。

當您在 DAG 中部署多重角色伺服器時，請考慮用戶端存取伺服器、集線傳輸伺服器和信箱伺服器負載的容量規劃。如果您的 DAG 中有四部多重角色伺服器，則務必確定有足夠的容量可容納可能倍增的 Hub Transport Server 和 Client Access Server 負載。由於多重角色組態會遵循伺服器角色的建議處理器核心比率，因此，如果您正確調整 Mailbox server role 的最大作用中資料庫大小，則 Hub Transport Server 和 Client Access Server 應該會符合此情況的效能目標。

建議使用多重角色組態的原因

Exchange 2010 多重角色案例的調整大小範例

以下範例說明如何決定多重角色伺服器之伺服器大小的程序。該範例的設計假設如下：

  • 信箱總數   24,000

  • 信箱設定檔   每天 100 封郵件 (例如，傳送 20 封和接收 80 封)

  • 每個信箱的資料庫快取   6 MB (根據每天 100 封郵件的設定檔)

  • 可用性需求   單一站台內的信箱恢復；在三個資料庫副本與兩部伺服器同時發生錯誤時受到保護

  • 資料庫需求   DAG 中有 120 個資料庫，每個資料庫有 200 個信箱

  • 伺服器平台   2 x 6 核心 2.26 GHz 處理器 (X5650) 伺服器 (12 個核心)

適用下列程序：

  1. 算伺服器數目   需要四個節點的 DAG，才能在兩部伺服器同時發生錯誤時受到保護。然而，客戶已決定部署六部伺服器，在兩部伺服器失敗事件期間控制最大的作用中信箱數量。因此一開始的設計是在 DAG 內具有六部信箱伺服器。

  2. 根據啟動模型計算每一伺服器的作用中信箱上限   假設作用中的資料庫會平均分散到各節點，則最理想的情況是每個伺服器主控 4,000 個作用中信箱 (24,000 ÷ 6)。若要計算雙重節點失敗後的作用中信箱個數 (根據此例)，則要將信箱個數除以剩餘的四個節點，也就是等於每一節點 6,000 個作用中信箱 (24,000 ÷ 4)。

    在此範例中，Set-MailboxServer 指令程式上的 MaximumActiveDatabases 參數會設定為 30，以確保單一伺服器上變成作用中的資料庫不會超過 40%。

  3. 計算作用中信箱 CPU 需求   根據 瞭解信箱資料庫快取 中的以郵件活動和信箱資料庫快取為基礎的每個信箱的預估 IOPS 表格，將伺服器上作用中信箱的最大數目乘以每個作用中信箱的 Megacycle 數 (6,000 × 2 個 Megacycle = 12,000 個 Megacycle)。針對每個額外的資料庫副本，將此值乘以 10%。

    在此範例中，每一個資料庫有一個主動副本和三個被動副本，因此 12,000 個 Megacycle 增加了 30% (12,000 × 1.3 = 15,600 個 Megacycle)。如需詳細資訊，請參閱瞭解信箱資料庫快取中的＜資料庫快取計量＞。

  4. 計算被動信箱 CPU 需求   根據 瞭解信箱資料庫快取 中的以郵件活動和信箱資料庫快取為基礎的每個信箱的預估 IOPS 表格，將被動信箱數目 (當伺服器主控最大數目的作用中信箱時) 乘以每個被動信箱的 Megacycle 數 (10,000 × 0.3 個 Megacycle = 3,000 個 Megacycle)。如需詳細資訊，請參閱瞭解信箱資料庫快取中的＜資料庫快取計量＞。

  5. 加入主動和被動 CPU 需求以取得 CPU 總需求   在此範例中，15,600 作用中信箱 個 Megacycle + 3,000 被動信箱 個 Megacycle = 18,600 個 Megacycle 的 CPU 總需求。

  6. 將信箱 CPU 需求套用至硬體平台   此範例使用 2 x 6 核心 2.26-GHz 處理器 (x5650) 伺服器。根據 信箱伺服器處理器容量規劃 中的準則，這等同於 60,083 個 Megacycle。根據伺服器平台將需要的 MHz 除以可用的 MHz，以預估發生雙節點失敗之後尖峰期間的 CPU 使用率 (18,600 ÷ 60,083 = 31% 預估 CPU 使用率)。

    建議您將多重角色組態的信箱伺服器角色部分設計為在尖峰時段不超過 40% 使用率 (例如，兩個節點同時發生失敗)。此種設計將有足夠的空間容納用戶端存取伺服器和集線傳輸伺服器角色的 CPU 使用率，同時在尖峰時段將伺服器 CPU 總使用率維持在低於 80% (例如，兩個節點同時發生失敗)。

  7. 計算作用中信箱記憶體需求   作用中信箱數目乘以每個信箱需要的資料庫快取。在此範例中，有兩個伺服器失敗，其餘的伺服器將主控 6,000 個作用中信箱 (6,000 × 6 MB) ÷ 1,024 = 35.1 GB。資料庫快取需求是根據信箱設定檔而定。如需詳細資訊，請參閱瞭解信箱資料庫快取中的＜資料庫快取計量＞。

  8. 將總記憶體需求套用至硬體平台   所需記憶體總量以資料庫快取需求與伺服器設定 (專用或多重角色) 為基礎。如需詳細資訊，請參閱瞭解信箱資料庫快取中的預設信箱資料庫快取大小表格。在此範例中，多重角色伺服器的總記憶體需求是 52.2 GB ((4 GB + 35.1 GB) ÷ 0.75)。由於 52.2 GB 不是標準記憶體組態，因此請增加為 64 GB 或是伺服器支援的最接近記憶體組態。

    建議使用多重角色組態的原因

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