信箱伺服器儲存設計

 

適用版本： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上次修改主題的時間： 2009-04-03

擁有足夠容量很重要。 當資料庫磁碟的空間不足時，資料庫會離線。 當交易記錄磁碟的空間不足時，會造成該儲存群組中的所有資料庫離線。 提供額外空間通常很難快速達成，而執行離線壓縮以收回空間會花費很久的時間。 在大部分情況下，磁碟空間不足會導致一或多個資料庫有一段期間無法使用，而這段期間通常超過大部分的復原時間目標 (RTO)。

本主題提供下列相關資訊：

• Exchange 2007 的信箱儲存計算器

• 資料庫 LUN 容量

• 記錄 LUN 容量

• 交易 I/O

• 預測 Exchange 2007 基準 IOPS

• 非交易 I/O

• LUN 及實體磁碟

• 連續複寫對儲存設計的影響

Exchange 2007 的信箱儲存計算器

Exchange Server 2007 Mailbox Server Role 儲存需求計算器 (儲存計算器) 可讓您根據一組輸入要素來決定儲存需求 (I/O 效能及容量) 及最佳邏輯單元編號 (LUN) 配置。 在您為 Exchange 2007 Mailbox Server 設計最佳儲存解決方案之前，需要納入許多輸入要素。 這些輸入要素會透過此主題加以說明。

儲存計算器可以讓您輸入組織專用的值，及提供對於 I/O 需求、容量需求及最佳 LUN 配置的建議。

如需儲存計算器的相關資訊，包括其用法的詳細資訊，請參閲 Exchange 團隊部落格上的 Exchange 2007 Mailbox Server Role 儲存需求計算器 (您也可以在此下載計算器)。

附註：
UNRESOLVED_TOKEN_VAL(exBlog)

資料庫 LUN 容量

您可利用數個資料點來決定估算資料庫邏輯單元編號 (LUN) 大小的方式。 此外，還有其他因素要考慮。 在考慮及計算過所有因素之後，建議為資料庫 LUN 納入 20% 的額外負荷因素。 此值將說明在計算信箱大小和空白字元時，資料庫中不一定會顯示的其他資料。 例如，資料庫內的資料結構 (資料表、檢視和內部索引) 會加到資料庫的整體大小中。 例如，如果您在閱讀下列數節之後決定所需的是 120 GB，建議您提供 144 GB，為儲存群組的資料庫 LUN 預留 20% 的安全額外負荷。

信箱配額

要了解的第一個量值是信箱大小。 知道使用者在信箱中可以儲存的資料量之後，就可以決定伺服器可容納的使用者數目。 雖然最終信箱大小和配額會變更，但是先有目標是決定所需容量的第一步。 例如，如果在伺服器上有 5,000 位使用者，而每位使用者的信箱配額為 250 (MB)，那麼您至少需要 1.25 TB 的磁碟空間。 如果未硬性設定信箱配額限制，則很難預估您需要的容量。

資料庫空白字元

實體磁碟上的資料庫大小不只是使用者數目乘以使用者配額。 當大多數使用者都未接近其信箱配額時，資料庫會耗用較少空間，此時空白字元不會造成容量問題。 整個資料庫中總是會到處散佈空白頁面或空白字元。 在線上維護期間，會移除標示為要從資料庫移除的項目，進而釋放這些頁面。 空白字元的百分比會不斷變更，百分比最高的時候是緊接在線上維護之後，最低的時候就在線上維護的前一刻。

資料庫中的空白字元大小，可由使用者在資料庫中使用信箱傳送和接收的郵件數來估算。 舉例來說，如果資料庫中有一百個 2 GB 的信箱 (總共 200 GB)，使用者每天平均傳送和接收 10 MB 的郵件，則空白字元大約為 1 GB (100 個信箱 × 每個信箱 10 MB)。

如果線上維護無法完成完整作業，則空白字元可能會超過此預估值。 因此，您的作業活動務必包含足夠時間以便每晚執行線上維護，讓完整作業能在一星期內完成。

資料庫暫放

每個資料庫都有一個暫放空間可儲存虛刪除的項目。 依預設，會將項目儲存在 Microsoft Exchange Server 2007 14 天。 這些項目包括已從 [刪除的郵件] 資料夾移除的項目。 依預設，與 Exchange Server 2003 相較，Exchange 2007 會增加資料庫暫放所耗用的額外負荷，這是因為現在儲存所刪除郵件的時間是原來的兩倍。暫放的實際量會視每個項目的大小以及組織的特定保留設定而定。

超過保留期限之後，會根據線上維護週期，從資料庫移除這些項目。 最後會達到穩定狀態，在該狀態下暫放大小會等於兩週的內送/外寄郵件量，以資料庫大小的百分比計算。 確切百分比取決於刪除的郵件量和個別信箱大小。

暫存會對資料庫加上某個百分比的額外負荷，視信箱大小和該信箱的郵件傳遞率而定。 例如，以每週 52 MB 的固定郵件傳遞率而言，250 MB 的非常大量設定檔信箱大約會在暫放中儲存 104 MB 的資料，增加 41% 的額外負荷。 而同樣是在暫放中儲存 104 MB 的資料，1 GB 信箱會增加 10% 的額外負荷。

實際信箱大小

當時間一久，使用者的信箱達到信箱配額時，需要刪除的郵件量就等於內送郵件量，以維持低於信箱配額的數量。 這表示暫放的大小會增加到等於兩週內送/外寄郵件量的最大值。 如果大多數使用者未達到信箱配額，則只會刪除部分內送/外寄郵件，造成暫放與信箱大小一同成長。 例如，每週接收 52 MB 郵件的 250 MB 非常大量郵件設定檔信箱 (平均郵件大小為 50 KB)，同時會在暫放中耗用 104 MB (41%) 的空間，再加上 7.3 MB 的空白字元，信箱總大小為 360 MB。 另一個例子是，每週接收 52 MB 郵件的 2 GB 非常大量郵件設定檔信箱，同時會在暫放中耗用 104 MB (5%) 的空間，再加上 7.3 MB 的空白字元，信箱總大小為 2.11 GB。 儲存群組中有五十個 2 GB 信箱，信箱總大小就等於 105.6 GB。

下列是以 2 GB 信箱來計算資料庫大小的公式：

信箱大小 = 信箱配額 + 空白字元 + (每週內送郵件量 × 2)

信箱大小 = 2,048 MB + (7.3 MB) + (52 MB × 2)

2,159 MB = 2,048 MB + 7.3 MB +104 MB (大於配額 5%)

在您決定所規劃的實際信箱大小後，您可以使用該值來判斷每個資料庫的使用者數目上限。 將所規劃的信箱大小除以建議的資料庫大小上限。 這也有助於判斷您需要多少資料庫來處理規劃的使用者數目 (假設是完全植入的資料庫)。 請注意，因為非交易輸入/輸出 ( I/O) 或硬體限制的原因，您可能必須修改單一伺服器上的使用者數目。 有些系統管理員偏好使用較多的資料庫來進一步縮小資料庫大小。 這種方式對備份和還原視窗有幫助，但會增加在每個伺服器上管理多個資料庫的複雜性。

內容索引

內容索引會建立索引或目錄，可讓使用者輕易且快速地搜尋其郵件項目而不必手動搜尋整個信箱。Exchange 2007 會建立約佔資料庫總大小 5% 的索引，該索引放在與資料庫相同的 LUN 上。 因此，計算資料庫 LUN 大小時，需針對內容索引部分額外計入容量的 5%。

維護

需要離線修復或壓縮的資料庫，所需的容量將等於目標資料庫大小加 10%。 不管您為單一資料庫、儲存群組或備份組配置的空間是否足夠，都要有額外空間來執行這些作業。

復原儲存群組

如果您計劃使用復原儲存群組作為嚴重損壞修復計劃的一部份，則需要足夠容量才能夠依您的期望同時還原該伺服器上的所有資料庫。

備份至磁碟

許多系統管理員都運用線上資料流備份的方式，將資料備份至磁碟目標。 如果您的備份和還原設計需要將資料備份至磁碟，則伺服器上要有足夠容量來存放備份。 根據使用的備份類型，這個容量可以像資料庫和記錄那麼小，或像資料庫及自上次執行完整備份以來的所有記錄那麼大。

記錄 LUN 容量

交易記錄檔在記錄資料庫引擎執行的每筆交易。 所有交易都會先寫入記錄，然後慢慢地寫入資料庫。 和 Exchange 的舊版不同，Exchange 2007 中的交易記錄檔大小已從 5 MB 減少為 1 MB。 此變更的目的是為了支援連續複寫功能，以及盡量減少主要儲存故障時遺失的資料量。

下表可用來預估會在 Exchange 2007 Mailbox Server 上產生的交易記錄數目，其平均郵件大小為 50 KB。

每一個信箱設定檔產生的交易記錄數目

信箱設定檔	郵件設定檔	產生的記錄 / 信箱
基本	傳送 5 封/接收 20 封	6
平均	傳送 10 封/接收 40 封	12
大量	傳送 20 封/接收 80 封	24
非常大量	傳送 30 封/接收 120 封	36
超大量	傳送 40 封/接收 160 封	48

對於郵件大小如何影響記錄產生速度，請參閱下列指導方針：

• 如果平均郵件大小加倍而變成 100 KB 時，則每個信箱產生的記錄會以 1.9 的係數增加。 此數字代表包含附件和郵件表格 (郵件內文和附件) 的資料庫百分比。

• 此後，當郵件大小加倍超過 100 KB 時，每個信箱的記錄產生速度也會加倍。

例如：

• 如果您有大量的信箱設定檔且平均郵件大小為 100 KB，則每個信箱產生的記錄為 24 × 1.9 = 46。

• 如果您有大量的信箱設定檔且平均郵件大小為 200 KB，則每個信箱產生的記錄為 24 × 3.8 = 91。

備份及還原因素

每天晚上執行完整備份的大部分企業，會將大約 3 天份的記錄檔容量配置到交易記錄 LUN 上的儲存群組中。 這是為了防止因備份失敗造成記錄磁碟機填滿，迫使儲存群組卸載的情況。

決定記錄 LUN 的大小仍然要根據備份和還原設計。 例如，如果您的設計可讓您回到兩週前並重新顯示之後產生的所有記錄，則您需要兩週的記錄檔空間。 如果您的備份設計包括每週執行完整備份及每日執行差異備份，則記錄 LUN 必須大於整週份的記錄檔空間，才能在還原期間進行備份和重新顯示。

移動信箱作業

移動信箱是大型信箱部署的主要容量因素。 許多大型公司會每晚或每週將某個百分比的使用者移至不同的資料庫、伺服器或站台。 如果您的組織這樣做，您會發現需要提供記錄 LUN 額外的容量以應付使用者遷移作業。 雖然來源伺服器會記載記錄的刪除，而且都不大，但目標伺服器必須先將所有傳輸的資料寫入交易記錄。 如果 1 天內產生 10 GB 記錄檔，並且保留 3 天的緩衝 (30 GB)，則移動五十個 2 GB 信箱 (100 GB) 會填滿目標記錄 LUN 而造成停機。 在這種狀況下，您可能必須為記錄 LUN 配置更多容量以應付移動信箱作業。

記錄成長係數

針對大多數部署，我們建議您在建立記錄 LUN 時於記錄大小中增加 20% 的額外負荷係數 (在考慮所有其他係數之後)，以確保在非預期記錄產生的時候備有所需的容量。

信箱容量規劃範例

以下範例說明在叢集連續複寫 (CCR) 環境的單一叢集信箱伺服器上擁有 4,000 個 1 GB 非常大量的郵件設定檔信箱的環境中，估算適當的大小。 這些信箱每週收到平均 52 MB 的郵件，平均郵件大小為 50 KB。 下表提供判斷實際信箱大小的範例值。

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

信箱大小	暫放大小 (2 週)	空白字元	磁碟總大小
1 GB	104 MB (2 × 52 MB)	7.3 MB	1.11 GB (+ 11%)

在這個環境中，每個使用者耗用 1.11 GB 的磁碟空間。 由於 CCR 環境中的建議資料庫大小上限為 200 GB，因此伺服器上每個資料庫主控的信箱最好不要超過 180 個。 若要支援 4,000 個信箱，必須有 23 個資料庫，而在此環境中，也要有 23 個儲存群組。 因為 CCR 環境的每個儲存群組需要一個資料庫，每個資料庫都位於自己的儲存群組中。 這會導致每個儲存群組的最終信箱計數為 174。根據信箱的數目以及信箱的實際大小，資料庫大小為 193 GB，如下表所示。

資料庫容量需求

每個資料庫的信箱	資料庫總數	資料庫大小需求
174	23	193 GB

若要確保 Mailbox Server 不會因為空間配置問題而遭受中斷，交易記錄也需要調整大小，才能容納在備份組期間產生的所有記錄。 許多組織在備份失敗時，會使用為每日記錄產生速度三倍的每日完整備份策略。 如果使用每週完整備份，然後再使用差異或增量備份，則至少需要一週份的記錄容量才能進行還原。 您知道一個非常大量郵件設定檔信箱每天平均產生 42 筆交易記錄，所以 4,000 個信箱伺服器每天將產生 168,000 筆交易記錄。 這表示每個儲存群組會產生 7,304 筆記錄。 每週的某一天 (星期六) 會移動 10% 的信箱，而備份方式包括每週進行完整備份及每日增量備份。 此外，伺服器可以在三天之內不將記錄截斷。 如下表所示，此伺服器的每個儲存群組都需要 38.8 GB 的空間。

記錄容量需求

每個儲存群組的記錄	記錄檔大小	每日記錄大小	移動信箱大小	增量還原大小	記錄大小需求
7,304	1 MB	7.13 GB	17 GB (17 × 1 GB)	21.4 GB (3 × 7.13 GB)	38.8 GB (17.4 + 21.4)

交易記錄 LUN 必須有足夠大小，才能處理信箱移動作業所產生的記錄，以及需要有足夠空間還原整週份的記錄。

交易 I/O

交易 I/O 是由使用者使用伺服器所造成的磁碟 I/O。 例如，接收、傳送和刪除郵件會造成磁碟 I/O。不當磁碟延遲會直接影響未使用 Exchange 快取模式 (離線) 的 Microsoft Outlook 使用者，而這在儲存設計中是最重要的考量之一。 在儲存方面，交易 I/O 需求已減少，因此在連續複寫方面，高可用性不再表示必須使用昂貴的光纖通道儲存 (雖然它仍然是好的解決方案)。

了解 IOPS

在舊版的 Exchange Server 中，決定儲存大小所需的其中一個重要量值是每位使用者耗用的每秒資料庫 I/O (IOPS) 量。 若要測量使用者 IOPS，請取得儲存群組在資料庫 LUN 上的 I/O 量 (包括讀取和寫入)，然後將該數量除以儲存群組中的使用者數目。 例如，1,000 個使用者在資料庫 LUN 上執行 1,000 次 I/O，表示每個使用者的 IOPS 是 1.0。

測量基準 IOPS

如果您使用舊版的 Exchange Server，而且已計算基準 IOPS，請注意，Exchange 2007 會以下列方式影響此基準：

• 伺服器上的使用者數目會影響每位使用者的整體資料庫快取。

• RAM 數量會影響資料庫快取能增大多少，越大的資料庫快取會導致越多的快取點擊，因而減少資料庫讀取 I/O。

關鍵在於，知道特定伺服器上的 IOPS 仍不足以規劃整個企業，因為每個伺服器的 RAM 數量、使用者數目及儲存群組數目可能不同。 有了實際 IOPS 數目後，一定要將 20% 的 I/O 額外負荷係數套用到您的計算中，以增加一些保留空間。 您不會希望使用者因為活動量高於正常情況而有不好的經驗。

資料庫快取

執行 64 位元版本 Exchange 2007 的 64 位元 Windows Server 作業系統可大幅增加虛擬位址空間，使 Exchange 得以增加其資料庫快取、減少資料庫讀取 I/O，並讓每個伺服器最多有 50 個資料庫。

資料庫讀取量減少取決於伺服器可用的資料庫快取數量和使用者郵件設定檔。 如需記憶體和儲存群組的指導，請參閲 規劃處理器組態。 遵循該主題的指導最多可以減少 Exchange 2003 之 70% 的交易 I/O。 每個使用者的資料庫快取數量是造成 I/O 實際減少的關鍵因素。

下表示範在比較 Exchange 2003 中的預設 900 MB 與 Exchange 2007 中每位使用者 5 MB 資料庫快取時，每位使用者實際增加的資料庫快取量。 就是這個額外的資料庫快取，使得快取讀取點擊次數提高，進而減少了磁碟層級的資料庫讀取活動。

以信箱個數為基礎的資料庫快取大小

信箱個數	Exchange 2003 資料庫快取/信箱 (MB)	Exchange 2007 資料庫快取/信箱 (MB)	超過 Exchange 2003 的資料庫快取增加量
4,000	0.225	5	23 倍
2,000	0.45	5	11 倍
1,000	0.9	5	6 倍
500	1.8	5	3 倍

預測 Exchange 2007 基準 IOPS

可用來預測 Exchange 2007 資料庫 IOPS 的兩大因素是每位使用者的資料庫快取量，以及每位使用者每天傳送和接收的郵件數目。 以下公式是以在 Exchange 快取模式 (離線) 中使用 Office Outlook 2007 的標準工作者為基礎，經過測試後，其精準度在 +20% 或 -20% 的範圍之內。 其他用戶端類型和使用案例可能會產生不精準的結果。 此預測只對介於 2 MB 到 5 MB 大小的使用者資料庫快取有效。 此公式尚未針對每天傳送和接收超過 150 封郵件的使用者進行驗證。 通過公式驗證的平均郵件大小為 50 KB，但郵件大小並非 IOPS 的主要因素。

下表提供每位使用者的 IOPS 預估值，您可用來預測基準 Exchange 2007 IOPS 需求。

以使用者設定檔和郵件活動為基礎的資料庫快取和預估 IOPS

使用者類型 (使用設定檔)	每天大約傳送/接收 50 KB 的郵件大小	每位使用者的資料庫快取	每位使用者的預估 IOPS
基本	傳送 5 封/接收 20 封	2 MB	0.11
平均	傳送 10 封/接收 40 封	3.5 MB	0.18
大量	傳送 20 封/接收 80 封	5 MB	0.32
非常大量	傳送 30 封/接收 120 封	5 MB	0.48
超大量	傳送 40 封/接收 160 封	5 MB	0.64

若要預估資料庫快取大小，請從 Exchange 伺服器安裝的記憶體總數中減去 2,048 MB (若使用本機連續複寫 (LCR) 則減去 3,072 MB)，然後將該數量除以使用者數目。 例如，就擁有 3,000 個使用者及 16 GB RAM 的伺服器來說，減掉系統所佔的 2 GB 後，剩下 14 GB 的 RAM 或每位使用者 4.66 MB (14 GB ÷ 3,000 = 4.66 MB)。

現在知道每位使用者的平均資料庫快取大小為 4.66 MB，且每天平均傳送和接收的郵件量為 60 後，您就可以預估資料庫的讀取和寫入次數：

• 資料庫讀取   將每天 60 封郵件乘以 0.0048 後，得到 0.288。 接下來，算出每個信箱之資料庫快取量 (4.66 MB) 的 -0.65 次方 (5 ^ -0.65) 為 0.3622。 最後，將兩個數字相乘，會得到每位使用者的資料庫讀取次數為 0.104 (0.288 × 0.3622 = 0.104)。

• 資料庫寫入   將每位使用者的郵件數 (60) 乘以 0.00152，得到每位使用者的資料庫寫入次數為 0.0912。

使用的公式為：

((0.0048 × M) × (D^ -0.65)) + (0.00152 × M) = 資料庫 IOPS 總數

其中 M 是每個使用者的郵件數，而 D 是每個使用者的資料庫快取。 每個使用者的資料庫 IOPS 總數就是讀取和寫入的相加，在此範例中為 0.189 IOPS：

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

下圖示範當具有 4,000 個 250 MB 信箱的 Outlook 2007 模擬在 Exchange 快取模式 (離線) 下執行 Exchange 2007 時，所達到的資料庫讀取和寫入減少成果及所建議的伺服器記憶體。

跟 Exchange Server 2003 相較，Exchange Server 2007 的 IOPS 減少情形

線上模式用戶端的影響

與 Exchange 快取模式 (離線) 用戶端不同的是，所有線上模式用戶端作業都是在資料庫中發生。 因此，讀取 I/O 作業會針對資料庫增加。 所以，若大部分用戶端會以線上模式作業，請參閱下列指導方針：

• 與 Exchange 快取模式 (離線) 用戶端相較之下，250 MB 線上模式用戶端會以 1.5 的係數增加資料庫讀取作業。 250 MB 以下的用戶端，其影響則微乎其微。

• 當信箱大小加倍時，則資料庫讀取 IOPS 也會加倍 (假設相等的郵件通訊群組在主要的資料夾之間保持相同)。

下圖說明以信箱大小為依據的 IOPS。

當信箱大小增加，資料庫讀取 IOPS 會跟著增加

測試結果也已顯示，增加資料庫快取超過每個信箱 5 MB 的話，並不會大幅降低資料庫讀取 I/O 需求。 下圖描述使用線上模式用戶端的 2-GB 信箱，以及增加快取超過 5 MB 對於降低資料庫讀取 I/O 需求的影響。

當每個信箱快取大小增加時，資料庫讀取 IOPS 會減少

由於此資料的原因，可提出兩個建議：

• 視需要部署快取模式用戶端。 如需相關資訊，請參閱下一節「每個資料夾的項目個數」。

• 請確保在設計資料庫儲存時，將 I/O 需求列入考量。

至於其他 IOPS 因素，例如協力廠商用戶端，請參閱最佳化 Exchange Server 2003 儲存 (英文)。

資料庫讀取/寫入比率

在 Exchange 2003 中，資料庫讀取/寫入比率通常是 2:1 或 66% 讀取率。 就 Exchange 2007 而言，資料庫快取變大會減少磁碟上的資料庫讀取次數，造成讀取次數佔總 I/O 的百分比縮小。如果您遵循我們建議的記憶體手冊並使用 Exchange 快取模式 (離線)，則讀取/寫入比率應該接近 1:1 或 50% 讀取率。

在線上模式使用 Outlook 時，或使用桌面搜尋引擎時，讀取端的讀取/寫入比率會略增 (取決於信箱大小)。 選擇會因寫入活動帶來高昂成本的獨立磁碟容錯陣列 (RAID) 類型 (例如 RAID5 或 RAID6) 時，寫入次數佔總 I/O 百分比變高，代表特別的含意。 如需為伺服器選擇適當 RAID 解決方案的相關資訊，請參閱儲存技術。

記錄對資料庫比率

在 Exchange 2003 中，儲存群組的交易記錄所需的 I/O 約為該儲存群組中之資料庫的 10%。 例如，如果資料庫 LUN 使用 1,000 次 I/O，則記錄 LUN 會使用大約 100 次 I/O。 在 Exchange 2007 中，綜合資料庫讀取次數減少、記錄檔變小以及可擁有的儲存群組變多等特徵，記錄對資料庫的寫入比率大約是 3:4。例如，如果資料庫 LUN 耗用 500 次寫入 I/O，則記錄 LUN 會耗用大約 375 次寫入 I/O。

在測量或預測交易記錄 I/O 之後，請套用 20% 的 I/O 額外負荷因素，以確保當遇到比正常期間更忙碌的時段時，能有足夠的空間。 此外，當使用連續複寫時，必須讀取已關閉的交易記錄，再將之傳送至第二個位置。 此額外負荷是記錄讀取次數的額外 10%。 如果儲存群組的交易記錄耗用 375 次寫入 I/O，那麼當使用連續複寫時，您可預期額外的 37.5 次讀取 I/O。

每個資料夾的項目個數

了解高項目計數和限制檢視對效能的影響說明重要資料夾中的項目數以及使用的用戶端類型和模式會如何影響某些使用者的磁碟效能。

減少伺服器 I/O 的一種方法，是在 Exchange 快取模式 (離線) 下使用 Outlook 2007。 初始信箱同步處理是成本高昂的作業，但日後隨著信箱大小的增加，磁碟子系統負擔會從 Exchange 伺服器轉移到 Outlook 用戶端。 這表示使用者的收件匣內有大量郵件，或使用者搜尋信箱，對伺服器將沒有什麼影響。 這也表示具有大型信箱的 Exchange 快取模式 (離線) 使用者可能比具有小型信箱的使用者需要更快速的電腦 (視個別使用者可接受的效能閾值而定)。 當您部署在快取 Exchange 模式下執行 Outlook 2007 的電腦時，請考慮下列信箱 /.OST 大小：

• 最多 5 GB：此種大小在大部分硬體上應可提供良好使用者體驗。

• 介於 5 GB 和 10 GB：此種大小通常依硬體不同，而有不同效能。 因此，如果您的硬碟速度很快而且有很多 RAM，將會有比較好的體驗。 然而，速度較慢的硬碟 (如可攜式電腦上常用的磁碟機或是早期的固態硬碟 (SSD)) 在回應時偶而會遇到應用程式暫停情形。

• 超過 10 GB：此種大小在大部分硬體上會開始出現短暫的暫停。

• 非常大 (如 25 GB 或更大)：此種大小會提高短暫的暫停頻率，尤其是當您在下載新電子郵件時。 此外，您可以使用傳送/接收群組來手動同步處理郵件。

附註：
此準則是以 Outlook 2007 Service Pack 1 或更新版本的累積更新安裝為基礎，如 Microsoft 知識庫文章 961752 Outlook 2007 Hotfix 套件 (Outlook.msp) 的描述：2009 年 2 月 24 日 所述。

如果您的 Outlook 2007 在快取 Exchange 模式部署時發生效能相關問題，請參閱知識庫文章 940226 如何疑難排解 Outlook 2007 的效能問題。

線上模式的 Outlook Web Access 和 Outlook 都會將索引儲存在伺服器的資料副本上，並在該副本進行搜尋。 對於中度大小的信箱來說，這個作法所產生的每個信箱的 IOPS，約為同等大小 Exchange 快取模式 (離線) 用戶端的兩倍。 大型信箱的每個信箱的 IOPS 甚至更高。 當您第一次以新方式排序檢視時，系統會建立索引，造成資料庫 LUN 中出現許多讀取 I/O。 後續對作用中索引進行排序時，所花費的讀取 I/O 成本並不高。

當使用者擁有超過 Exchange 所能儲存的索引數目時 (在 Exchange 2007 中是 11)，情況會變得很棘手。 如果使用者選擇以新方式排序，而建立第 12 個索引，則會造成額外的磁碟 I/O。因為該索引並未儲存，每次排序完成後就會產生此磁碟 I/O 成本。由於這種情況下可能會產生高 I/O，因此我們強烈建議您不要在 [收件匣] 和 [寄件備份] 資料夾這類核心資料夾中儲存超過 20,000 個郵件。 只要所有資料夾中的郵件數目都不超過 20,000 個，則建立更多頂層資料夾，或在 [收件匣] 和 [寄件備份] 資料夾之下建立子資料夾，都能大幅減少此索引建立動作所帶來的成本。如需郵件個數如何影響信箱伺服器效能的相關資訊，請參閱建議的信箱大小限制 (英文) 和了解高項目計數和限制檢視對效能的影響。

附註：
UNRESOLVED_TOKEN_VAL(exBlog)

如需改良的相關資訊，請參閱知識庫文章 968009 Outlook 2007 在 2009 年 2 月累積更新中的改良功能。

非交易 I/O

交易 I/O 的發生是為了回應直接使用者動作，且通常具有最高優先順序，為儲存設計的焦點。 交易 I/O 減少後，非交易 I/O 就顯得更加重要。 在大型信箱方面 (特別是在 2 GB 信箱的情況)，許多企業不會將使用者容量加倍，但在某些情況下，卻將它增加十倍。 其中一個例子，就是從 200 MB 移到 2 GB。 如果您遇到這類磁碟資料量暴增的情況，則必須在規劃儲存設計時考慮到非交易 I/O。

內容索引

在 Exchange 2007 中，收到郵件時就會建立其索引，並產生少量的磁碟 I/O 額外負荷。 在 Exchange 2007 中，進行索引搜尋的速度比在 Exchange 2003 中快大約 30 倍。

通訊記錄管理

「通訊記錄管理」(MRM) 是 Exchange 2007 的新功能，可協助系統管理員和使用者管理其信箱。 可以設定原則來移動或刪除符合特定閾值 (例如保留天數) 的郵件。 MRM 是一項排定好的編目作業，它會以類似備份和線上維護的同步讀取作業對資料庫執行。 MRM 的磁碟成本取決於需要進行動作 (例如刪除或移動) 的郵件數目。

建議不要讓 MRM 與備份或線上維護作業同時執行。 如果您使用連續複寫，可以將大量陰影複製服務 (VSS) 備份卸載至被動副本，讓線上維護和 MRM 有更多時間執行，使它們不會影響彼此或使用者。

線上維護

當資料庫執行線上維護時會執行許多動作，例如永久移除刪除的郵件並執行資料庫的線上磁碟重組。 維護會造成讀取活動，而線上磁碟重組則會造成讀取和寫入活動。 完成維護所需的時間與資料庫大小呈正比，而且可能會限制資料庫能夠增大多少。 如需線上維護的相關資訊，請參閱＜儲存區背景處理程序第一部分＞(英文)。

附註：
UNRESOLVED_TOKEN_VAL(exBlog)

備份與還原

系統管理員可使用許多不同的備份和還原方法。 備份與還原方面的主要量值是輸送量，也就是可以複製到工作 LUN 以及從工作 LUN 複製的每秒 MB 數。 決定輸送量之後，您需要判斷此值是否足以符合備份與還原的服務等級協定 (SLA)。 例如，如果需要能夠在 4 小時內完成備份，您可能必須增加其他硬體來達到目標。 在某些硬體組態下，變更配置單位大小或許有幫助。 這樣可以同時改善資料流線上備份，以及在 VSS 備份期間執行的 Exchange 伺服器資料庫公用程式 (Eseutil.exe) 完整性檢查。

當伺服器上有 2,000 位使用者時，從 200 MB 移至 2 GB 信箱會使資料庫大小增加十倍。 許多系統管理員不習慣在單一伺服器上處理大量的資料。 請考慮使用一部具有 2000 個 2 GB 信箱的伺服器。 加上前述的額外負荷，總共資料將超過 4 TB。 假設您可以達到每小時 175 GB (每分鐘 48 MB ) 的備份速率，備份這部伺服器至少要 23 個小時。 對於不使用 LCR 或 CCR 的伺服器而言，替代方法是每天對 1/7 個資料庫執行完整備份，並對剩餘的資料庫執行增量備份，如下表所示。

每週例行備份的範例

備份類型	第 1 天	第 2 天	第 3 天	第 4 天	第 5 天	第 6 天	第 7 天
完整	DB 1-2	DB 3-4	DB 5-6	DB 7-8	DB 9-10	DB 11-12	DB 13-14
增量	DB 3-14	DB 1-2 DB 5-14	DB 1-4 DB 7-14	DB 1-6 DB 9-14	DB 1-8 DB 11-14	DB 1-10 DB 13-14	DB 1-12

正如您在先前的表格中所見，這樣會使每晚約需備份 650 GB 的資料，假設速率是每小時 175 GB，則在 3.7 個小時內會完成備份。 有些解決方案可以達到更多或更少輸送量， 然而，大型信箱可能需要使用不同的方法。

使用 LCR 和 CCR 時，被動副本是防禦的第一線。 如果主動副本和被動副本都失敗或無法使用時，您只能從備份還原。 復原多天的增量記錄會增加復原所花的時間。 因此，快速復原解決方案 (例如 CCR 或 VSS 複製) 很少會使用增量備份。 就 VSS 複製而言，資料的復原速度很快，而讓備份時間保持在備份 SLA 之內，增加一點時間來重新顯示記錄是可以接受的。

資料流線上備份

使用資料流備份時，建議將資料流 I/O (來源和目標) 進行分隔，以確保要同時備份的多個儲存群組不會爭用相同的磁碟資源。 不管目標是磁碟或磁帶，每個硬體解決方案在實體磁碟和控制器方面都有獨特的輸送量限制。 可能需要將某些儲存群組彼此隔離，使同時備份作業數目和輸送量最大化，以便將備份視窗的大小最小化。 下表說明對 14 個資料庫同時執行兩個備份的範例。

同時進行例行備份的範例

備份號碼	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
第一個備份	儲存群組 (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
第二個備份	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

如果將儲存群組 (LUN) 彼此隔離，就可以同時執行資料流備份，每個 LUN 進行一個備份，如前表所示。 每個 LUN 的第一個儲存群組備份工作應該先完成，然後才開始進行第二個儲存群組的備份，以隔離備份資料流。 在同一個實體磁碟上進行兩個資料流備份的速度可能並不會快上兩倍，但就每秒 MB 數來看，應該會比單一資料流備份工作還要快。

VSS 備份

Exchange 2007 會使用 Windows Server 2003 中所包含的 VSS 來建立資料庫和交易記錄檔的磁碟區陰影複製。 如需 VSS 的相關資訊，包括複製和快照集技術，請參閱使用磁碟區陰影複製服務搭配 Exchange Server 2003 的最佳作法 (英文)。 Exchange 2007 的新功能是對 LCR 或 CCR 環境中的儲存群組被動副本進行 VSS 備份。 在上述環境中，於備份的總和檢查碼完整性階段以及磁帶或磁碟的後續副本期間，從被動副本執行 VSS 快照集會移除主動 LUN 上的磁碟負載。 同時也會在主動 LUN 上釋出更多時間以執行線上維護、MRM 和其他工作。

LUN 及實體磁碟

在許多情況下，作業系統所辨識的實體磁碟或 LUN 是取自硬體 (使用該硬體將硬碟呈現給作業系統)。 而針對效能及復原原因，重要的是一律將 LUN 及實體磁碟層次上的交易記錄檔與資料庫檔案分開放置。 混合相同實體磁碟上的隨機與循序磁碟 I/O 會明顯降低效能，而從復原觀點來看，分開放置儲存群組的記錄檔及資料庫檔案，可以確保其中一組實體磁碟的重大失敗不會造成同時遺失資料庫檔案及記錄檔。

在 Exchange 2007 中，最佳作法是將所有資料庫都放在相同實體 LUN 的儲存群組中。 而另一個最佳作法是每個儲存群組中只放置一個資料庫。Exchange 資料庫 I/O 是隨機的，而在實體磁碟執行相同的工作量時，這對大部分的儲存子系統有所助益。 會設計許多儲存陣列，以將許多實體磁碟先放至一組磁碟中，然後再利用該磁碟群組的可用空間建立 LUN，最後平均發佈至每個實體磁碟。 而備份儲存群組之資料庫 LUN 的實體磁碟也可以備份其他存放其他儲存群組及伺服器之資料庫的 LUN。 同樣地，即使遺失循序 I/O 會稍微影響效能，但是也不一定要將每個儲存群組的交易記錄 LUN 都隔離至不同的實體磁針。

如果在單一伺服器上設定了最大值的 50 個儲存群組，則每個儲存群組都應該有自己的交易記錄 LUN 及資料庫 LUN。 這樣會超出可用的磁碟機代號數目，而且必須使用 NTFS 檔案系統磁碟區掛接點。 而針對連續複寫所設定的五十個儲存群組需要 200 個 LUN，這會超出一些儲存陣列上限，特別是所有 200 個 LUN 都需要放在單一伺服器上的 LCR。 隨著 LUN 數目的增加，監視就會變得更加重要，因為耗盡磁碟空間會導致卸載該儲存群組。

LUN 設計

在許多情況下，作業系統辨識的 LUN 是取自磁碟後面的實體硬體。 為了提高效能和復原能力，不論是在 LUN 或實體磁碟層級，將交易記錄與資料庫分開放置都很重要。 就某些儲存陣列而言，在相同的實體磁碟上混合隨機與循序 I/O 會降低效能。 從復原能力的觀點來看，將儲存群組的交易記錄與資料庫分開放置，可確保當某一組實體磁碟嚴重故障時，不會造成資料庫和交易記錄同時遺失。

Exchange 資料庫 I/O 是隨機執行，當實體磁碟執行相同工作量時，大部分儲存子系統均可從中受惠。 許多儲存陣列使用虛擬儲存，將許多實體磁碟先集中成一組磁碟，然後在該磁碟群組的可用空間中建立 LUN，使 LUN 平均分散在各個實體磁碟上。 未使用連續複寫時，讓備份某個儲存群組之資料庫 LUN 的實體磁碟，同時也可以備份其他的 LLU (這些 LLU 存放其他儲存群組和伺服器的資料庫)，是可接受的作法。 同樣地，即使遺失循序 I/O 會稍微影響效能，但是也不一定要將每個儲存群組的交易記錄 LUN 都隔離至不同的實體磁針。 將來自相同儲存群組的記錄和資料庫 LUN 分隔到不同的實體磁碟上很重要。 如果您需要 30 IOPS 和 5% 的容量，卻讓兩個或四個 500 GB 實體磁碟專門存放單一儲存群組的交易記錄 LUN，就是不切實際的作法。

雖然在 Exchange 2007 中設計 LUN 的方法不少，但建議採用下列兩種設計以求簡化：

• 每個儲存群組兩個 LUN

• 每個備份組兩個 LUN

每個儲存群組兩個 LUN

一個儲存群組建立兩個 LUN (記錄和資料庫各一個) 是 Exchange 2003 的標準最佳作法。 在 Exchange 2007 中，以最多 50 個儲存群組而言，您提供的 LUN 數目取決於備份策略。 如果 RTO 很短，或您使用 VSS 複製進行快速復原，則最好將每個儲存群組放在其專屬的交易記錄 LUN 和資料庫 LUN 中。 但這麼做會超過可用的磁碟機代號數目，所以必須使用磁碟區掛接點。

這個策略的一些優點包括：

• 在儲存群組層級採用硬體型 VSS，提供單一儲存群組的備份及還原。

• 隔離儲存群組之間效能的彈性。

• 增加可靠性。 在單一 LUN 上所發生的容量、損毀或病毒問題只會影響一個儲存群組。

這個策略的一些考量包括：

• 使用連續複寫的 50 個儲存群組可能需要 200 個 LUN，這樣會超過某些儲存陣列上限，特別是在 LCR 的情況中，所有 200 個 LUN 都需要提供給單一伺服器。

• 一個儲存群組一個 LUN 會造成每個伺服器有更多 LUN，進而增加管理成本。

每個備份組兩個 LUN

備份組是在一晚中用完整備份的方式備份的資料庫數目。 能夠每天晚上對 1/7 的資料庫執行完整備份的解決方案，可透過將所有要備份的儲存群組放在相同記錄和資料庫 LUN 中來減低複雜性。 這樣可以減少伺服器上的 LUN 數目。

這個策略的一些優點包括：

• 因為要管理的 LUN 變少，所以能簡化儲存管理工作。

• 可能減少備份工作的數目。

這個策略的一些考量包括：

• 在採用硬體型 VSS 備份和復原方面會受到限制。

• 由於在主開機記錄 ( MBR) 分割的 2 TB 限制，會限制此策略的容量擴充能力。

磁碟區掛接點

在許多情況下，例如在多節點的單一副本叢集中 (SCC)，需要的 LUN 超過可用的磁碟機代號。 在這些情況下，您必須使用磁碟區掛接點。 磁碟機代號是用來辨識磁碟分割或磁碟的舊版 MS-DOS 作業系統功能，最好避免使用太多磁碟機代號。 將所有交易記錄和資料庫 LUN 放在磁碟區掛接點會更容易，而且更方便管理。 如果您有 20 個儲存群組，每個儲存群組都有一個資料庫，就會很難記住哪個磁碟機代號存放資料庫 17。下表說明使用磁碟區裝載點的範例。

使用磁碟區裝載點的資料夾配置範例

交易記錄 (L:)	資料庫 (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

在此範例中，L: 和 P: 為錨定 LUN，分別存放所有記錄和資料庫 LUN。 這些磁碟機上的每個資料夾都是個別 LUN 的磁碟區掛接點。

硬體型 VSS

使用硬體型 VSS 時，提供您將 Exchange 資料放在 LUN 的建議。 就硬體型 VSS 解決方案而言，每個交易記錄 LUN 和資料庫 LUN 中應該只存放來自選擇的備份組的檔案。 如果要還原儲存群組而不影響其他儲存群組，則每個儲存群組需要個別的交易記錄 LUN 和資料庫 LUN。 如果您願意為了還原單一資料庫而使其他資料庫和儲存群組離線，則可以將多個儲存群組放在單一交易記錄 LUN 和資料庫 LUN 上。

軟體型 VSS

使用軟體型 VSS 時 (特別是使用大型信箱和連續複寫時)，需採取兩個步驟的備份策略。 首先，需建立 VSS 快照集，然後將一般檔案傳輸至磁碟或磁帶。

LUN 可靠性

將儲存群組的交易記錄和資料庫放在個別實體磁碟一向很重要，這樣做可以增加可靠性。 就連續複寫而言，將主動與被動 LUN 分隔在完全不同的儲存上也很重要。 使用 CCR 和 LCR 時，您會希望當主要儲存發生重大失敗時，能夠還原儲存。

LUN 範例

請考慮下列以上述容量範例為基礎並將該資訊套用至 LUN 建立作業的案例。 在此範例中，備份方式是每天執行完整備份。 您希望啟用內容索引並將該索引放置在資料庫 LUN 上。 193 GB 的 5% 大約是 10 GB。 您需要將這個數目計入最後 LUN 大小。 193 GB 的成長係數應該是最終資料庫大小的 20%。 193 GB 的 20% 為 39 GB。 結果會顯示在下列表格中。

判斷資料庫 LUN 大小的範例值

資料庫大小	成長係數	內容索引	資料庫 LUN 大小
193 GB	39 GB	10 GB	241 GB

每個儲存群組每天建立 7.13 GB 記錄，您希望至少儲存 3 天份的記錄。

判斷記錄 LUN 大小的範例值

記錄 (1 天)	記錄 (3 天)
7.13 GB	21.4 GB

移動信箱

我們的範例組織每週移動其信箱的 10%，且在星期六執行所有移動作業。 因此，記錄 LUN 必須處理一整天的負載。 在 Microsoft 所使用的移動信箱策略，是將傳入的使用者平均分散到每個儲存群組中。 這表示擁有 4,000 位使用者的範例伺服器每個星期六大約要移動 400 位使用者。 一共有 23 個儲存群組，每個儲存群組必須接收 17 個 1GB 信箱，如下表所示。

判斷移動信箱記錄 LUN 大小的範例值

記錄 (3 天)	信箱移動	記錄 LUN 大小
21.4 GB	17.64 GB (17 個 1 GB 使用者)	46.6 GB (38.8 GB + 20%)

如果使用這樣的配置，您就無法在一天之內將 17 個以上的使用者移至儲存群組中。 因此，如果您需要在任一特定日子移動 10% 以上，那麼增加記錄 LUN 的大小會比較合理。

連續複寫對儲存設計的影響

連續複寫是 Exchange 2007 的新功能，會將儲存群組的資料庫及記錄檔複製到次要位置。 新的交易記錄關閉或已滿時，會將這些交易記錄複製到次要位置並進行驗證，然後重新顯示於資料庫的被動副本中。 為了達成儲存回復性，建議您將被動副本放到與即時生產 LUN 完全隔離的儲存陣列中。 因為您使用被動副本處理失敗時的生產負載，被動副本的儲存應該符合儲存群組之主動副本所用之儲存解決方案的效能及容量。

在使用連續複寫時，每個儲存群組都只能包含單一資料庫，因此資料庫的每個副本都會需要四個 LUN。 每個資料庫副本都會在自己的儲存群組中，而主動副本會需要不同的記錄及資料庫 LUN，被動副本也需要不同的記錄及資料庫 LUN。

最佳作法是：

• 在硬體層次將儲存分成個別的 LUN，而且不要在作業系統內建立 LUN 的多個邏輯磁碟分割。

• 分開交易記錄及資料庫，並將它們放在不同的實體磁碟，以增加容錯。

• 將主動及被動 LUN 分開放在完全不同的儲存陣列中，這樣儲存就不會是單一失敗點。

• 如果從多部叢集信箱伺服器裝載儲存群組或資料庫至相同的儲存陣列上，請確保每個 LUN 都是利用個別實體磁碟建立。

您的儲存設計也應該將儲存控制站分開放在不同的周邊元件連接 (PCI) 匯流排，這樣可擁有最大的容錯。此外，就容量及效能而言，也應該將被動副本的儲存設計成符合主動副本的儲存。 在主動副本的儲存發生重大失敗時，被動副本的儲存是防禦的第一線，而且在容錯移轉時，被動副本會變成主動副本。 將被動副本的 LUN 放在完全不同的儲存硬體上，就可以確保對被動副本所執行的任何動作都不會影響主動副本。

使用連續複寫時，會發生多個交易 I/O。 此因素必須在調整伺服器大小時列入考慮。 您也必須在關閉循序寫入的使用中交易記錄後讀取該記錄，並將它複製至複本交易記錄 LUN 隔離資料夾。 接著，必須在複本位置處檢查此記錄，並將它移至複本 LUN 上的最終目的地。 最後，會讀取此記錄並將它顯示在資料庫中。 使用中及複本交易記錄 LUN 必須讀取及寫入在獨立 Mailbox Server 上找到的近 100% 循序寫入活動。 此行為變更可能需要您評估儲存控制器上的快取設定。 在電池供電的儲存控制器上，建議使用 25% 讀取與 75% 寫入的設定。

連續複寫及資料庫大小

使用連續複寫時，可使用較大的資料庫大小上限。 就 Exchange 2007 而言，建議採用下列最大資料庫大小：

• 在 Mailbox Server 上主控的資料庫 (不使用連續複寫)： 100 GB

• 裝載在 Mailbox Server 上的資料庫 (使用連續複寫及 Gigabit Ethernet)： 200 GB

  附註：
  大型資料庫可能也需要較新的儲存技術，才能讓增加的頻寬來應付修復案例。

  重要事項：
  資料庫大小的真正上限，取決於組織中已有的 SLA。 決定可在組織 SLA 所指定之期間內備份及還原的最大資料庫大小，即決定了資料庫的大小上限。

LCR 儲存選項

LCR 可以啟用單一伺服器上的記錄傳送。 如果存放資料庫或記錄檔之主動副本的儲存發生重大失敗，系統管理員可以手動啟動資料庫的被動副本。 而被動副本的儲存應該與主動副本的儲存完全分開。 此外：

• 控制卡應該位在不同的 PCI 匯流排上。

• 每個儲存解決方案都應該有自己的不斷電供應系統 (UPS)。

• 每個儲存解決方案都應該位在不同的電源電路上。

CCR 儲存選項

CCR 會啟用主動/被動容錯移轉叢集中被動節點的記錄傳送。 將記錄傳送至完全不同伺服器上的被動副本中，以及維護完全不同伺服器上的被動副本，會減少對主動節點的操作影響，而且您會擁有伺服器上的容錯功能。

在分散各處的 CCR 部署中，被動副本可以位在與主動節點處於不同位置的節點上，以提供站台回復性。 雖然文章 Exchange Server 多站台資料複寫的部署準則 (英文) 中的資訊仍然適用，但是連續複寫的提取式技術則表示高延遲並不會影響使用者體驗。 這與分散各處的叢集解決方案中，同步複寫延遲會嚴重影響使用中伺服器，是明顯的對比。 使用 CCR 時，複寫程序可能會忙碌，因而增加主動副本及被動副本不同步的時間長短。 然而，如果嚴重損壞影響到主動副本，則因為 Hub Transport Server 具有傳輸暫放功能，所有將會復原未複寫至被動節點的郵件。

單一副本叢集儲存選項

用於 SCC 的硬體必須列在 Windows Server Catalog 的「叢集」類別中。 用於分散各處之 SCC 的硬體，必須列在要支援之 Windows Server Catalog 的「分散各處的叢集」類別中。

使用共用儲存的叢集信箱伺服器與獨立伺服器的基礎儲存考量相同。 使用同步複寫時，複寫程序可以手動增加磁碟延遲。 在最大化儲存陣列內的複寫點時，請特別小心。 如需 SCC 複寫的相關資訊，請參閱 Exchange Server 多站台資料複寫的部署準則 (英文)。