Exchange 2010 Mailbox Server Role 設計範例

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

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

本主題舉例說明如何判定適合信箱伺服器角色及其架構的記憶體、容量、I/O 與 CPU 效能需求。

您可以使用 Exchange Server 2010 信箱伺服器角色需求計算器，輸入一些因素，來判定信箱伺服器角色的適當需求。計算器可以判定此範例中所討論的需求。如需計算器的詳細資訊 (並下載)，請參閱 Exchange Server 團隊部落格文章：Exchange 2010 信箱伺服器角色需求計算器。

附註：
每個網誌的內容及其 URL 如有變更，恕不另行通知。每個網誌的內容係依「現狀」提供，不為瑕疵責任擔保且不賦予任何權力。使用內含的指令碼範例或程式碼係受限於 Microsoft 使用條款中所指定的條款。

如需信箱伺服器角色儲存設計的詳細資訊，請參閱信箱伺服器儲存設計。

本範例的案例是一個有三個資料庫複本的解決方案，使用 JBOD (一群磁碟機，just a bunch of disks) 儲存裝置。就此範例而言，會考慮以下架構需求：

• 在單一資料庫可用性群組 (DAG) 中加入六個信箱伺服器

• Exchange 信箱伺服器也會主控集線傳輸角色與用戶端存取伺服器角色

• 三個高可用性的信箱資料庫副本，沒有遲延的資料庫副本

• 採用 7.2 K (7,200 RPM)，1-TB SATA 磁針數

• JBOD 儲存裝置組態 (1 個邏輯單元編號 (LUN) / 資料庫 LUN 架構)

• 針對備份架構，使用透過單一項目復原與信箱恢復力提供的原生資料保護功能

• 部署還原 LUN 以進行維護與復原作業

• 每個 LUN 至少 20% 可用空間

• 此解決方案應可安然渡過雙重伺服器故障事件

• 唯一安裝的伺服器角色是信箱伺服器角色

目錄

信箱容量需求

資料庫副本需求

信箱記憶體需求

信箱 I/O 需求

信箱 CPU 需求

信箱容量需求

下例說明調整以下環境的適當大小：有 24,000 個 2-GB 大，每日設定檔信箱 100 筆訊息，散佈在 6 個信箱伺服器，這些信箱伺服器加入 DAG 內，DAG 的每個資料庫有三個副本。以每週 5 個工作天來算，這些信箱每週平均收到 37 MB 的郵件，平均郵件大小為 75 KB。已啟用單一項目復原功能，刪除的項目有 14 天的保留期限。下列計算方式用來判定信箱大小:

信箱的大小 = 信箱限制 + 空白字元 + 暫放

空白字元 = 每天 100 筆訊息 x 75/1024 MB = 7.32 MB

暫放 = (每天 100 筆訊息 x 75/1024 MB * 14 天) + (2048 MB x 0.012) + (2048 MB x 0.03) = 188.6 MB

判斷磁碟上實際信箱大小的範例值

由於這種環境利用 JBOD 儲存裝置，所以能夠部署的最大資料庫大小是視磁碟的大小而定。若要測定 JBOD 案例的最大資料庫大小，請使用下列公式，在這公式中，1TB 磁碟格式化後的容量是 931 GB、可用空間百分比需求是百分之 20、且內容索引百分比是百分之 10：

最大資料庫大小 = [格式化後的磁碟容量 x (1 – 可用空間百分比需求)] / (1 + 內容索引百分比)

= [931 GB x (1 - .2)] / ( 1+ .10)

= 744.8 GB / 1.1

= 677 GB

在這個環境中，每位使用者的信箱耗用 2.25 GB 的磁碟空間。為了支援 24,000 個信箱，677 GB 的資料庫大小，必須有 102 個資料庫。這項需求導致每個資料庫最終可容納 235 個信箱。

然而，因為此解決方案利用 JBOD 儲存結構，所以務必確定每個資料庫的信箱數未超過可在單一磁碟上達到的隨機 I/O 數量。因為此解決方案利用大外觀尺寸的 7.2K SATA 磁針數，所以磁針完全利用時，可達到每秒 55 隨機 I/O (IOPS) 數的上限。納入 20% 的 I/O 常設成長緩衝區的因素，這表示磁針可處理總計 44 隨機 IOPS。

如果使用者群每日的設定檔有 100 筆訊息，則每個信箱預計會耗用 0.1 IOPS；因此磁碟可支援此 IOPS 設定檔最多有 440 個信箱。因為容量計算判定可支援的信箱數上限為 235 個，這低於根據 IOPS 設定檔判定的 440 個信箱，所以此解決方案可以部署在單一磁碟上。

若要判定實際的資料庫大小，請使用下列公式：

資料庫大小 = 信箱數 x 磁碟上的信箱大小 x 資料庫常設成長係數

根據信箱數、信箱實際大小與 20% 的資料庫成長常設係數所得的資料庫大小為 619 GB，如下表所示。

資料庫容量需求

若要確保信箱伺服器不會因為空間配置問題而遭受中斷，交易記錄也需要調整大小，才能容納在備份組期間產生的所有記錄。如果此架構運用信箱恢復力與單一項目復原功能作為備份架構，則當失敗副本未經修復達三天時，記錄容量應該撥出三倍的每日記錄產生速率(任何失敗的副本都會防止記錄截斷的發生)。

每日設定檔信箱 100 筆訊息，每天平均會產生 20 筆交易記錄，因此 24,000 個信箱的環境每日將產生 576,000 筆交易記錄。因此，每個資料庫每日將會產生 5,647 筆記錄。每一週會有一天 (星期六) 移動 1% 信箱。解決方案會利用 Exchange 內的原生資料保護功能，因此不會執行備份，且會調整大小以容忍三天不修復失敗副本，而不會截斷記錄。

如下表所示，此伺服器的每個資料庫副本都需要 23 GB 的空間。

記錄容量需求

如果這是有三個副本的信箱恢復與 JBOD 組態，則每個資料庫及其相對應的交易記錄會放置在同一個 LUN。所需的 LUN 大小為：

LUN 容量 = 資料庫大小 ÷ (1 - 可用空間百分比需求)

= (資料庫大小 + 交易記錄大小 + 內容索引大小) ÷ (1 - 0.2)

= (619 GB + 23 GB + 61.9 GB) / 0.8

= 879 GB

判定所需的 LUN 大小

回到頁首

資料庫副本需求

如果總共需要有 102 個資料庫以支援 24,000 個信箱，且每個資料庫有三個副本，則 DAG 將支援總共 306 個資料庫。306 個資料庫分散到 6 個信箱伺服器，這表示每個信箱伺服器裝載 51 個資料庫副本。資料庫副本應分散到整個 DAG 內的伺服器中，如此一來，若發生伺服器等級的故障，使用中資料庫會儘可能容錯移轉至其餘的伺服器上 (資料庫副本未以對稱的方式分散)。

為了讓加入 DAG 的信箱伺服器發揮最大的效率，使用中資料庫將平均地分散至所有的信箱伺服器上。因此，當 6 個信箱伺服器全都在運作時，每個伺服器應裝載 17 個使用中資料庫副本。

當一個信箱伺服器故障時，17 個資料庫會重新分散到其餘的信箱伺服器，讓每個伺服器的使用中資料庫副本數目增加到 21 個。

當兩個信箱伺服器故障時，34 個資料庫將重新分散至其餘的信箱伺服器，讓每個伺服器的使用中資料庫副本數目增加到 26 個。此使用中副本數目將用於調整信箱伺服器記憶體大小與 CPU 需求。

如欲瞭解更多有關如何透過信箱伺服器發佈資料庫副本，請參閱 資料庫副本佈局設計。

回到頁首

信箱記憶體需求

當訊息設定檔每日有 100 筆訊息時，每個信箱支援資料庫快取所需最低記憶體大小為 6 MB。最糟的狀況是每個伺服器的主動信箱資料庫數目為 26 個，每個伺服器總共可裝載 6,110 個即時信箱。此外，每個伺服器總共有 51 個資料庫。信箱伺服器最少需要 12 GB 的資料庫快取。因此，支援資料庫快取所需的記憶體數量是：

所需最小資料庫快取 = 最大值((即時信箱數目 x 需要的記憶體 / 信箱), 資料庫最小記憶體)

= 最大值(6110 x 6/1024 GB, 12 GB)

= 最大值(36 GB, 12 GB)

= 36 GB

當部署一個多角色架構時，根據 瞭解信箱資料庫快取 中的表格，支援此組態所需的實體記憶體總數為 64 GB。

回到頁首

信箱 I/O 需求

每個信箱每日傳送或接收 100 筆訊息。因此，每個信箱有 0.1 的 IOPS 設定檔。每個資料庫裝載了 235 個信箱。因此，資料庫磁碟區 I/O 總數是：

資料庫磁碟區 I/O = 信箱數目 x IOPS 設定檔 x (1 + I/O 常設成長係數)

= 235 x 0.1 x 1.2

= 28.2 IOPS

此架構的資料庫讀取 I/O 百分比數目為 60%。因此，每個資料庫磁碟區會產生讀取 I/O 的 16.92 IOPS，寫入 I/O 的 11.28 IOPS。

在此架構中，每個記錄串流會產生 50% 的資料庫寫入 I/O，因此每個磁碟區的記錄寫入 I/O 為 5.64 IOPS。

26 個使用中資料庫副本也會產生記錄讀取 I/O，此記錄讀取 I/O 是記錄寫入 I/O 的 10%，因此這些資料庫的記錄讀取 I/O 是 0.56 IOPS。

因為每個大的外觀尺寸 7.2K SATA 磁碟會產生 55 隨機 IOPS，因此不必擔心磁碟無法處理資料庫的 I/O 需求。

回到頁首

信箱 CPU 需求

發生雙重伺服器故障事件時，其餘的伺服器每個會裝載 26 個資料庫，每個伺服器總計有 6,110 個主動信箱。根據 信箱伺服器處理器容量規劃 中的計算方式，每個伺服器有下列 CPU 兆赫需求。

判定 CPU 兆赫需求

如果選擇的伺服器平台可支援總共 26,400 兆赫，則伺服器 CPU 平台在雙重伺服器故障事件期間可支援環境。

回到頁首

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