造成 Exchange 磁碟 I/O 的原因

  • 發行項

 

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

上次修改主題的時間： 2010-05-31

Microsoft Exchange Server 2007 中的伺服器角色有 Hub Transport 和 Edge Transport (統稱為傳輸伺服器)、Client Access、Unified Messaging 及 Mailbox。每個伺服器角色都有不同的儲存需求及不同的備份和還原需求，因為它們各自執行不同的功能：

  • Hub Transport 和 Edge Transport Server 提供：

    • 傳遞郵件進/出組織。

    • 傳遞郵件進/出 Mailbox Server。

    • 傳遞語音信箱訊息 (由 Unified Messaging Server 所提交)。

  • Client Access Server 是 Exchange 的用戶端通訊協定伺服器，提供 Microsoft Outlook Web Access、Exchange ActiveSync、Outlook 無所不在及其他網際網路通訊協定。

  • Unified Messaging Server 提供 Outlook 語音存取以及傳入傳真的支援。

  • Mailbox Server (Exchange Server 的核心) 是儲存使用者信箱及公用資料夾的位置。

  • 信箱叢集或單一複本叢集 (SCC) 會以共用磁碟主動/被動組態使用叢集服務。

  • 連續複寫會將記錄檔傳送至替代位置，此替代位置可以在使用本機連續複寫 (LCR) 的獨立伺服器上、在使用叢集連續複寫 (CCR) 的叢集中，或者在使用待命連續複寫 (SCR) 的遠端伺服器上。

Mailbox server role

Exchange 2007 Mailbox server role 是建置所有其他伺服器角色之前，必須先建置的核心伺服器角色。決定您的信箱設定檔後 (包括每秒使用者輸入/輸出 (I/O) 及容量)，就可開始規劃部署。您在 Exchange 伺服器上放置的使用者數目通常取決於防範硬體瓶頸及提供符合服務等級協定 (SLA) 之備份及還原資料能力間的平衡。

必須平衡三個儲存需求，才能達到成功的 Exchange 2007 部署。第一個需求是交易 I/O，也就是使用儲存時，每個 I/O 都必須達到的效能 (以延遲來測量)。第二個需求是備份及還原輸送量，也就是與備份媒體之間移動資料的速度。第三個需求是容量，或者確定您為生產邏輯單元編號 (LUN) 所選擇的獨立磁碟容錯陣列 (RAID) 組態上及目標備份媒體上都有足夠的空間。

如需如何使用信箱分析調整磁碟 I/O 需求大小的相關資訊，請參閱信箱伺服器儲存設計。例如，您想在具有每秒 0.4 個 I/O (IOPS) 的設定檔及 2 GB 信箱的伺服器上放置 3,000 位使用者。您的效能需求會是 1,200 IOPS。您必須確定可以備份及還原 6 TB 的資訊。如果您的備份 SLA 是四小時，您就必須在一小時內備份 1.5 TB 的資料 (或每秒 417 MB)。如果您的備份解決方案每秒只能備份 300 MB，就必須減少 28% 的信箱大小或使用者數。

在 Exchange 2000 Server 中，因為受到虛擬記憶體限制的影響，最佳作法是使用五個資料庫填滿儲存群組之後，再建立另一個儲存群組。在 Exchange Server 2003 中已大幅減少了這些限制，因此最佳作法是為每個新資料庫各新增一個儲存群組，直到達到儲存群組數目上限為止。使用 Exchange 2007 時，因為可延伸儲存引擎 (ESE) (Exchange Server 使用的基礎資料庫引擎) 的增強功能，所以 I/O 支配會減少。

核心可延伸儲存引擎增強功能

因為 ESE 中數項主要的設計變更，Exchange 2007 減少了 Exchange Server 的整體 I/O 支配：

  • 64 位元作業系統及 64 位元 Exchange Server 應用程式可運用較大的資料庫快取，而根據系統記憶體總數，可從 900 MB 增加到數十 GB 不等。

  • 資料庫讀取作業也因為許多新的快取最佳化功能而受惠。從 64 KB 增加到 1 MB 的 I/O 聯合藉由提高讀寫較大筆 I/O 的機會，進一步減少磁碟 I/O。

  • 沒有任何資料流資料庫檔案，且已移除可安裝的檔案系統 (IFS)。

作為 64 位元應用程式，Exchange 2007 沒有像 32 位元應用程式的虛擬記憶體限制。Exchange 2007 Mailbox Server 最多支援 50 個資料庫及 50 個儲存群組，而且您最多可以在每個儲存群組中放置五個資料庫。不過，每部 Exchange 2007 Mailbox Server 最多可擁有 50 個資料庫。

每個儲存群組會建立自己的個別交易記錄，而儲存群組是備份及還原的基本單位。如果快取不會不足，則 ESE 在寫入資料庫前可寫入交易記錄的最大資料量是稱為檢查點深度的快取。在儲存群組中使用單一資料庫，可將完整的檢查點深度配置給該資料庫，增加了在快取中對某個資料庫頁面執行多個更新，並只將最後一個更新寫入資料庫的可能性，進而減少了 I/O。

Exchange 信箱資料元件

下表說明 Mailbox server role 活動，以及每一項活動對磁碟 I/O 的影響。

Exchange 2007 中的 Mailbox server role 活動

活動 活動如何影響磁碟 I/O

ESE 資料庫 (.edb 檔)

Mailbox Server 會將所有郵件儲存在 ESE 資料庫中。ESE 資料庫會受到隨機存取，並使用 8 KB 的分頁大小 (雖然 I/O 聯合可能會產生較大的 I/O)。基於可靠性，以及某些狀況下的效能考量，資料庫應該位於不含交易記錄的磁碟上。

交易記錄檔 (.log 檔案)

對資料庫所做的所有變更會先認可至交易記錄，這是對磁碟的連續寫入動作。寫入的大小範圍從 512 位元組到記錄緩衝區大小，各有不同。

內容索引

內容索引是隨機的工作量，應該放置在與資料庫相同的 LUN 上，且通常只有 5 % 的資料庫大小。因為內容索引會在背景中執行 (對到達的郵件編製索引)，所以對磁碟 I/O 的影響是很小的。

分頁

如果處理程序要求記憶體中的分頁而系統在要求的位置找不到分頁，就會發生分頁錯誤。如果分頁在記憶體中其他位置，則錯誤為軟分頁錯誤。如果分頁必須從磁碟擷取，則錯誤為硬分頁錯誤。大部分的處理器可處理大量的軟分頁錯誤而不受影響。不過，硬分頁錯誤可能會造成顯著的延遲。持續的高度磁碟分頁表示記憶體不足。

內容轉換

在 Exchange 中用於儲存資料的原生方法會使用以傳輸中性封裝格式 (TNEF) 封裝的 MAPI 郵件。如此一來，將會透過 SMTP 傳輸 MAPI 郵件，並提供 MAPI 郵件給 MAPI 用戶端，如 Microsoft Outlook。非 MAPI 用戶端要求郵件為 MIME 格式。此格式會要求 Exchange 執行從 TNEF / MAPI 至 MIME 格式的內容轉換處理程序。大部分的內容轉換是在 Client Access Server 和 Hub Transport Server 上執行。

但是，傳統的網頁分工編寫及版本管理 (WebDAV) 應用程式 (如 Microsoft Entourage) 會直接存取 Mailbox Server。在此案例中，內容轉換處理程序會直接發生於 Exchange 2007 Mailbox Server 上。當傳統的 WebDAV 用戶端要求必須在 Client Access Server 上轉換資料時，會透過存取 /Exchange 虛擬目錄進而從 Exchange 2007 Mailbox Server 存取資料 (有些工具會存取 /ExAdmin 虛擬目錄以存取資料)。資料會在 Mailbox Server 的 Tmp 目錄中進行轉換，然後傳送至 Client Access Server。

在非 MAPI 用戶端使用者移到新伺服器之後，往往會出現大量使用 Tmp 目錄的情形。因為當使用者第一次連線至信箱時，可能會有大量的內容轉換，所以才會出現此種行為。

為了改善效能，TMP 目錄不應與分頁檔或作業系統位於同一 LUN 上。

資料庫維護

Exchange 2007 資料儲存庫需要定期的線上維護，才能配合每個資料庫執行。影響磁碟 I/O 的兩項工作是實刪除比設定之保留原則還舊的郵件和信箱，以及資料庫線上磁碟重組。因為備份資料庫會終止該資料庫可能發生的所有線上磁碟重組，所以必須謹慎分配時間，讓備份及資料庫維護視窗都有時間完成工作。

備份與還原

備份資料的處理程序需要從資料庫及交易記錄檔磁碟區中讀取資料。這項額外的 I/O 會影響到使用者的回應時間，所以應該避免在上班時間進行備份。軟修復的處理程序需要 ESE 重播所有交易記錄檔。這樣會造成 I/O 設定檔成為循序讀取資料流。因此，如果交易記錄檔位於能夠提供快速循序磁碟存取的磁碟上，修復效能會有所改善。避免發生此問題的其中一種方式是使用連續複寫，讓您將磁碟區陰影複製服務 (VSS) 型備份從資料庫的主動副本卸載至資料庫的被動副本。

清除刪除的資料庫頁面

如果您設定 Mailbox Server 清除已刪除的資料庫頁面，則在您每次刪除資料庫中的一個項目時，會刪除多個頁面。然後 Exchange 會以零覆寫刪除的頁面。在 Microsoft Exchange Server 2007 的量產發行 (RTM) 版本中，這項功能只會在資料流線上備份時執行，而且會在備份過程中造成較多的實體磁碟 I/O。在 Exchange Server 2007 Service Pack 1 (SP1) 中，可以在線上維護視窗期間啟用這項功能。

除了資料庫檔案存取之外，還有其他活動會造成磁碟 I/O。下表列出這些其他活動和活動對磁碟 I/O 的影響。

影響磁碟 I/O 的其他活動

活動 活動如何影響磁碟 I/O

資料夾中的項目數目

核心信箱資料夾中的項目數目增加時，使用線上模式之 Outlook 使用者執行某些工作的實體磁碟成本也會增加。索引和搜尋是在使用 Outlook 時於 Exchange 快取模式下執行。第一次依大小將收件匣排序需要建立新索引，這項工作需要許多磁碟 I/O。後續依大小排序收件匣的成本會很高。您能夠擁有的索引數目是固定的，因此時常以許多不同方式將資料夾排序的使用可能超過這個限制，造成更多的磁碟 I/O。

BlackBerry

如需 BlackBerry 和 Exchange 2007 的相關資訊，請檢視 Research In Motion (RIM) 網站的 BlackBerry Enterprise Server for Microsoft Exchange 網頁上的效能評定指南。

note附註：
UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

公用資料夾

如果公用資料夾位於伺服器上，會產生額外的 I/O 負載。但是，如果伺服器上沒有資料夾內容的複本，則因為擁有公用資料夾資料庫產生的 I/O 與使用者信箱存取產生的 I/O 相比，就並不重要。

備份

進行信箱備份需要仔細的規劃。下列各節提供 VSS 及資料流線上備份的一些考量。每個解決方案都有影響成本、時間及可靠性之變數的好壞處。大多數系統管理員都會定義線上資料庫維護、磁碟重組及作業系統維護的時間。這些活動會與備份爭用時間。在平衡備份、維護及生產環境負載時必須小心謹慎。較大的信箱可能導致會無法按照 SLA 的規定完成每日的完整備份策略。為了減少完整夜間備份的影響，一般的策略是執行一週的完整備份及每日的差異備份。採用此策略時，您需要復原完整備份，然後復原最後一個差異備份。

磁碟區陰影複製服務

如需 Exchange 2003 之 VSS 基礎及 VSS 最佳作法的詳細資訊，建議您閱讀使用磁碟區陰影複製服務搭配 Exchange Server 2003 的最佳作法。除了該文章中所含的資訊外，還必須考慮 Exchange 2007 中兩項主要的 VSS 相關考量：

  • 較大的信箱

  • 備份 CCR 及 LCR 副本的能力

雖然您可以在生產資料或複製資料上進行 VSS 備份，但是建議您備份副本，以免影響到生產實體磁碟。

使用 LCR 時，Exchange 2007 會將交易記錄檔複寫到同一部伺服器的不同磁碟上。對副本使用 VSS 複製時，副本儲存應該要設在不同的實體磁碟上，這樣複製作業及檢查碼完整性才不會影響生產環境的實體磁碟。對副本使用 VSS 快照時，副本儲存應該要設在不同的實體磁碟上，這樣要記錄的檢查碼完整性及後續資料流才不會影響生產環境的實體磁碟。

使用 CCR 時，Exchange 2007 會將交易記錄檔複寫到不同的伺服器。此伺服器是叢集中的節點，但是目標副本不會留在共用儲存上。使用 VSS 複製時，您可對使用不同實體磁碟之被動節點上的副本執行總和檢查碼完整性，這樣就可隔離備份處理程序。使用 VSS 快照時，要記錄的總和檢查碼完整性及後續資料流不會影響生產環境的伺服器或實體磁碟。

資料流線上備份

與硬體型 VSS 備份不同的是，資料通常只在儲存應用裝置內移動，而在使用資料流備份時，則是由伺服器負責來移動資料。因為是在備份期間檢查每個分頁，所以總和檢查碼完整性程序的效能影響並不是問題。如果同時進行備份，則多重資料流會增加備份媒體的限制，不管是 Gigabit Ethernet 或光纖通道連接磁帶都一樣。對於許多客戶來說，備份 SLA 視窗的時間 (除以資料流備份媒體每分鐘的輸送量所得) 會限制允許的儲存群組大小。例如，如果 SLA 規定可花一小時在儲存群組上，且每秒最多可備份 100 MB，則最大的儲存群組大小會是 360 GB。

Client Access Server

Client Access Server 可卸載來自郵件伺服器 (假設這些角色安裝在不同的實體伺服器上) 的許多無狀態工作，並提供統一的命名空間，讓使用者只需指向單一名稱而無需注意所使用的郵件伺服器為何。Client Access Server 會提供網際網路通訊協定，如網際網路訊息存取通訊協定 4 (IMAP4)、郵局通訊協定 3 (POP3) 及 HTTP。Outlook 無所不在、ActiveSync、自動探索服務、可用性服務及 Web 服務是 Client Access Server 提供之功能服務的其他範例。

Client Access Server 可能會受到 CPU、記憶體及網路瓶頸的影響，但是它具有非常少的磁碟 I/O 支配。簡易郵件傳輸通訊協定 (SMTP) 流量、執行 Exchange 2003 及 Exchange 2000 之前端伺服器的潛在磁碟 I/O 考量，現在已專屬於 Hub Transport Server 及 Edge Transport Server。

下表說明 Client Access server role 活動，以及每個活動對磁碟 I/O 的影響。

Exchange 2007 中的 Client Access server role 活動

活動 活動如何影響磁碟 I/O

通訊協定記錄

通訊協定記錄是一種循序寫入，若啟用將造成效能問題，而且會因為儲存記錄而耗用磁碟空間。當您將選擇之通訊協定歷程保存於記錄中時，即可確認通訊協定是否按預期執行其工作或遇到通訊問題，並識別來自網際網路的攻擊。

內容轉換

所有 Exchange 2007 通訊協定的內容轉換會發生在 Client Access Server 上。傳統的 WebDAV 內容轉換會在 Exchange 2003 郵件伺服器上為傳統的 Outlook Web Access 用戶端來進行。當用戶端對 Client Access Server 要求必須轉換的資料時，會從 Exchange 2003 Mailbox Server 存取資料、在 Mailbox Server 的 TMP 資料夾中進行轉換，然後傳送至 Client Access Server。為了改善效能，TMP 資料夾不應與分頁檔及作業系統位於同一 LUN 上。

分頁

如果處理程序要求記憶體中的分頁而系統在要求的位置找不到分頁，就會發生分頁錯誤。如果分頁在記憶體中其他位置，則錯誤為軟分頁錯誤。如果分頁必須從磁碟擷取，則錯誤為硬分頁錯誤。大部分的處理器可處理大量的軟分頁錯誤而不受影響。不過，硬分頁錯誤可能會造成顯著的延遲。持續的高度磁碟分頁表示記憶體不足。

當使用者使用網際網路用戶端透過 POP3 或 IMAP4 通訊協定存取信箱資料時，就是磁碟 I/O 會造成 Client Access Server 之問題的情況。由於傳輸引擎會將所有內送郵件轉換為 MAPI，所以在將郵件傳送給 POP3 及 IMAP4 用戶端之前，必須先將該內容轉換回多用途網際網路郵件延伸標準 (MIME)。此轉換發生於 Client Access Server 上，如果郵件大於 64 KB，則會在磁碟上發生轉換。如果大多數使用者是使用 POP3 或 IMAP4，則發生轉換的暫存資料夾應該放在專用的快速磁碟上。

傳輸伺服器

Hub Transport Server 和 Edge Transport Server 是 Exchange 2007 的 Bridgehead 和閘道伺服器。它們主要的任務是傳送及接收郵件。許多企業會將傳輸伺服器分成兩組部署：

  • 反垃圾郵件和防毒保護 (Edge Transport Server)

  • 路由 (Hub Transport Server)

Edge Transport Server 主要的責任是防止含有垃圾郵件或病毒的郵件進入 Exchange 基礎結構。Hub Transport Server 則是將乾淨的郵件分類並傳遞到正確的信箱伺服器中。根據每秒處理的郵件數及這些郵件的平均大小，儲存對這些伺服器影響也會不同。

下表說明 Edge Transport Server 和 Hub Transport Server 活動，以及每個活動對磁碟 I/O 的影響。

Exchange 2007 中的 Edge Transport 和 Hub Transport server role 活動

活動 活動如何影響磁碟 I/O

ESE 資料庫 (mail.que 檔)

Exchange 2007 Edge Transport Server 及 Hub Transport Server 兩者都會將所有郵件儲存在 ESE 資料庫中。ESE 資料庫會受到隨機存取，並使用 8 KB 的分頁大小。基於可靠性，以及某些狀況下的效能考量，資料庫應該與交易記錄位於不同的磁碟上。

交易記錄檔 (.log 檔案)

對資料庫所做的所有變更會先認可至交易記錄，這是對磁碟的連續寫入動作。寫入的大小範圍從 512 位元組到記錄緩衝區大小，各有不同。

通訊協定記錄及郵件追蹤記錄

郵件追蹤及通訊協定記錄是一種循序寫入，若啟用將造成效能問題並會因為儲存記錄而耗用磁碟空間。當您將選擇之通訊協定歷程保存於記錄中時，即可確認通訊協定是否按預期執行其工作或遇到通訊問題，並識別來自網際網路的攻擊。

內容轉換

在 Hub Transport Server 上，來自網際網路的內送郵件會先轉換為 MAPI，才進行傳遞。這項內容轉換處理程序會發生在 TMP 資料夾中。為了改善效能，TMP 資料夾不應與分頁檔及作業系統位於同一 LUN 上。

分頁

如果處理程序要求記憶體中的分頁而系統在要求的位置找不到分頁，就會發生分頁錯誤。如果分頁在記憶體中其他位置，則錯誤為軟分頁錯誤。如果分頁必須從磁碟擷取，則錯誤為硬分頁錯誤。大部分的處理器可處理大量的軟分頁錯誤而不受影響。不過，硬分頁錯誤可能會造成顯著的延遲。持續的高度磁碟分頁表示記憶體不足。

代理程式

傳輸伺服器的自訂是透過在 Common Language Runtime 環境下執行並由事件觸發的程式碼 (稱為代理程式) 進行。某些代理程式會記錄資料，而此舉會影響磁碟效能並因為儲存記錄而耗用磁碟空間。

Unified Messaging Server

如需決定 Unified Messaging Server 大小的相關資訊，請參閱判斷 Exchange 2007 Unified Messaging Server 可以支援的使用者數目。

note附註：
UNRESOLVED_TOKEN_VAL(exBlog)