經過測試的 Exchange 2010 解決方案：在 Cisco 整合運算系統刀鋒伺服器與 EMC CLARiiON Storage 上運行 Hyper-V 的三個站台中的 32400 個信箱

  • 發行項

 

上次修改主題的時間： 2016-12-14

Microsoft Exchange 專案經理 Rob Simpson；EMC 的 Exchange Solutions Engineering 資深解決方案工程師 Boris Voronin；Cisco 的 Microsoft 解決方案架構師 Mike Mankovsky

日期

2011 年 6 月

Exchange 2010 已測試解決方案

在 Exchange 2010 已測試解決方案中，Microsoft 及參與的伺服器、儲存和網路合作夥伴檢查了常見的客戶案例，以及面對規劃部署 Microsoft Exchange Server 2010 的客戶時的關鍵設計決策點。透過這一系列的白皮書，我們提供了部分伺服器、儲存和網路合作夥伴部署於硬體上，設計優良且具成本效益的 Exchange 2010 解決方案範例。

您可從 Microsoft 下載中心下載此文件。

套用至

Microsoft Exchange Server 2010 含 Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

目錄

  • 簡介

  • 解決方案摘要

  • 客戶需求

    • 信箱設定檔需求

    • 地理位置需求

    • 伺服器和資料保護需求

  • 設計假設

    • 伺服器組態假設

    • 儲存組態假設

  • 解決方案設計

    • 決定高可用性策略

    • 預估信箱儲存容量需求

    • 預估信箱 I/O 需求

    • 決定儲存類型

    • 決定是否偏好 DAS 或 SAN 儲存解決方案

    • 選擇儲存解決方案

    • 預估信箱記憶體需求

    • 計算需要的資料庫快取

    • 預估信箱 CPU 需求

    • 摘要說明信箱需求

    • 決定伺服器機型

    • 計算伺服器機型的 CPU 容量

    • 決定所需的實體信箱伺服器數目

    • 決定正常運作和失敗案例情況下每部信箱伺服器的主動信箱數目

    • 決定是否將 Client Access Role 和 Hub Transport Server Role 部署到不同的實體伺服器上

    • 決定需要的實體 Client Access Server 和 Hub Transport Server 組合數目

    • 決定所需的實體伺服器總數

    • 決定是否將使用伺服器虛擬化

    • 判斷虛擬化是否可用來減少實體伺服器的數目

    • 計算 Hyper-V 根伺服器的 CPU 容量

    • 調整虛擬化負荷的可用 MHz

    • 決定虛擬機器的 CPU 容量

    • 驗證主要信箱伺服器虛擬機器的 CPU 容量

    • 驗證次要信箱伺服器虛擬機器的 CPU 容量

    • 決定每部主要信箱伺服器虛擬機器所需的記憶體

    • 決定每部次要信箱伺服器虛擬機器所需的記憶體

    • 決定每個 Client Access Server 和 Hub Transport Server 組合所需的記憶體

    • 決定每部 Hyper-V 根伺服器所需的記憶體

    • 設計資料庫可用性群組

    • 設計資料庫副本配置

    • 資料中心啟動協調模式

    • 決定檔案共用見證的位置

    • 規劃命名空間

    • 決定 Client Access Server 陣列和負載平衡策略

    • 決定硬體負載平衡模型

    • 決定儲存設計

  • 解決方案概觀

    • 邏輯解決方案圖

    • 實體解決方案圖

    • Hyper-V 根伺服器組態摘要

    • Client Access 和 Hub Transport Server 組態

    • 信箱伺服器組態

    • 資料庫配置

    • 儲存硬體摘要

    • 儲存組態

  • 解決方案驗證方法

    • 儲存設計驗證方法

    • 伺服器設計驗證

    • 功能驗證測試

    • 資料庫轉換驗證

    • 伺服器轉換驗證

    • 伺服器容錯移轉驗證

    • 資料中心轉換驗證

    • 主要資料中心服務還原驗證

    • 測試設備

  • 解決方案驗證結果

    • 功能驗證結果

    • 儲存設計驗證結果

    • 伺服器設計驗證結果

  • 結論

  • 其他資訊

簡介

本文件提供如何針對在 Cisco Unified Computing System 刀鋒型伺服器和 EMC CLARiiON 儲存解決方案上部署了 32,400 個信箱的客戶環境中，設計、測試和驗證執行 Windows Server 2008 R2 Hyper-V 技術之 Exchange Server 2010 解決方案的範例。設計較大型 Exchange 2010 環境所面臨的關鍵挑戰之一在於，檢查目前可用的伺服器和儲存選項並且選擇正確的硬體，以便在預期的解決方案生命週期內提供最大的價值。我們將依照本文件中的逐步方法，說明有助於解決這些關鍵挑戰的重要設計決策點，同時確保符合客戶的核心業務需求。為這位客戶決定最佳解決方案之後，解決方案會經過一項標準驗證程序，確認它能夠承受正常運作、維護和錯誤情況下的模擬生產工作負載。

Exchange 2010 已測試解決方案

解決方案摘要

下列各表摘要說明這個解決方案的重要 Exchange 和硬體元件。

Exchange 元件

Exchange 元件 值或描述

目標信箱個數

32400

目標平均信箱大小

2 GB (初始大小為 600 MB 的精簡佈建)

目標平均郵件設定檔

每日 100 封郵件

資料庫副本計數

3

磁碟區陰影複製服務 (VSS) 備份

無

站台恢復

是

站台數目

3

資料庫可用性群組 (DAG) 模型

主動/主動分配 (多個 DAG)

虛擬化

Hyper-V

Exchange 伺服器計數

4 部虛擬機器 (VM)

實體伺服器計數

2

硬體元件

硬體元件 值或描述

伺服器合作夥伴

Cisco

伺服器機型

M200

伺服器類型

刀鋒型伺服器

處理器

Intel Xeon X5570

儲存合作夥伴

EMC

儲存機型

CX4-480

儲存類型

儲存區域網路 (SAN)

磁碟類型

450 GB 15,000 SAS 3.5"

負載平衡合作夥伴

Cisco

硬體負載平衡模型

Ace

Exchange 2010 已測試解決方案

客戶需求

Exchange 解決方案設計中最重要的前幾個步驟之一，就是確切地摘要說明業務和技術需求，這些都是有助於做出正確設計決策的關鍵所在。以下各節概述這個解決方案的客戶要求。

Exchange 2010 已測試解決方案

信箱設定檔需求

盡可能精確地判斷信箱設定檔需求，因為這些需求可能影響所有其他設計元件。如果您是 Exchange 的新手，可能需要在了解之後做幾項猜測。如果您有現有的 Exchange 環境，可以使用 Microsoft Exchange Server Profile Analyzer 工具協助您收集這些資訊。以下各表摘要說明此解決方案的信箱設定檔需求。

信箱個數需求

信箱個數需求 值

信箱個數 (包括資源信箱的信箱總數)

30000

規劃的信箱個數增長百分比 (%) (在解決方案生命週期內規劃的信箱個數增量)

8%

預期的信箱並行性 % (任意時間的使用中信箱數目上限)

100%

目標信箱個數 (包括成長 x 預期並行的信箱個數)

32400

信箱大小需求

信箱大小需求 值

平均信箱大小 (以 MB 為單位)

600 MB

平均信箱封存大小 (以 MB 為單位)

不適用

規劃的信箱大小 (以 MB 為單位) 增長 (%) (在解決方案生命週期內規劃的信箱大小增量)

230%

目標平均信箱大小 (以 MB 為單位)

2,048 MB

信箱設定檔需求

信箱設定檔需求 值

目標郵件設定檔 (每位使用者每天平均傳送和接收的郵件總數)

每日 100 封郵件

目標平均郵件大小 (以 KB 為單位)

75

MAPI 快取模式下的 %

100

MAPI 線上模式下的 %

0

Outlook Anywhere 快取模式下的 %

0

Microsoft Office Outlook Web App 下的 % (Exchange 2007 和舊版中的 Outlook Web Access)

0

Exchange ActiveSync 下的 %

0

Exchange 2010 已測試解決方案

地理位置需求

制定高可用性和站台恢復相關設計決策時，務必了解信箱使用者和資料中心的分布情形。

下表概述使用 Exchange 系統之人員的地理分布情形。

人員的地理分布情形

信箱使用者站台需求 值

包含信箱使用者的主要站台數

3

站台 1 中的信箱使用者數目

10800

站台 2 中的信箱使用者數目

10800

站台 3 中的信箱使用者數目

10800

下表概述可能支援 Exchange 電子郵件基礎結構之資料中心的地理分布情形。

資料中心的地理分布情形

資料中心站台需求 值

資料中心總數

3

靠近資料中心 1 的使用中信箱數目

10800

靠近資料中心 2 的使用中信箱數目

10800

靠近資料中心 3 的使用中信箱數目

10800

Exchange 位於多個資料中心的需求

是

Exchange 2010 已測試解決方案

伺服器和資料保護需求

同樣重要的是定義環境的伺服器和資料保護需求，因為這些需求將支援有關高可用性和站台恢復的設計決策。

下表列出伺服器保護需求。

伺服器保護需求

伺服器保護需求 值

站台內同時發生的伺服器或虛擬機器失敗數目

1

站台失敗時同時發生的伺服器或虛擬機器失敗數目

0

下表列出資料保護需求。

資料保護需求

資料保護需求 值或描述

在 Exchange 環境外維護 Exchange 資料庫備份的需求 (例如，協力廠商備份解決方案)

否

在 Exchange 環境內維護 Exchange 資料庫副本的需求 (例如，Exchange 原生資料保護)

是

在主要資料中心維護多份信箱資料副本的需求

是

在次要資料中心維護多份信箱資料副本的需求

否

維護任何 Exchange 資料庫延遲副本的需求

否

延遲副本的保留天數

不適用

目標資料庫副本數目

3

[刪除的郵件] 資料夾的保留天數

14

Exchange 2010 已測試解決方案

設計假設

本節包括通常不專為客戶需求而收集，但是對於設計和驗證設計的方法至關緊要的資訊。

Exchange 2010 已測試解決方案

伺服器組態假設

下表描述正常運作情況下，以及站台伺服器失敗或伺服器維護情況下的尖峰 CPU 使用率目標。

伺服器使用率目標

目標伺服器 CPU 使用率設計假設 值

正常運作的信箱伺服器

<70%

正常運作的 Client Access Server

<70%

正常運作的 Hub Transport Server

<70%

正常運作的多個伺服器角色 (Client Access Server、Hub Transport Server 和 Mailbox Server)

<70%

正常運作的多個伺服器角色 (Client Access Server 和 Hub Transport Server)

<70%

信箱伺服器的節點失敗

<80%

Client Access Server 的節點失敗

<80%

Hub Transport Server 的節點失敗

<80%

多個伺服器角色 (Client Access Server、Hub Transport Server 和 Mailbox Server) 的節點失敗

<80%

多個伺服器角色 (Client Access Server 和 Hub Transport Server) 的節點失敗

<80%

信箱伺服器的站台失敗

<80%

Client Access Server 的站台失敗

<80%

Hub Transport Server 的站台失敗

<80%

多個伺服器角色 (Client Access Server、Hub Transport Server 和 Mailbox Server) 的站台失敗

<80%

多個伺服器角色 (Client Access Server 和 Hub Transport Server) 的站台失敗

<80%

Exchange 2010 已測試解決方案

儲存組態假設

下列各表摘要說明設計儲存組態時，在資料組態和輸入/輸出 (I/O) 方面所做的一些假設。

資料組態假設

資料組態假設 值或描述

資料負荷因數

20%

每週信箱移動

1%

專屬的維護或還原邏輯單元編號 (LUN)

否

LUN 的可用空間

20%

啟用記錄傳送壓縮

是

啟用記錄傳送加密

是

I/O 組態假設

I/O 組態假設 值或描述

I/O 負荷因數

20%

額外的 I/O 需求

無

Exchange 2010 已測試解決方案

解決方案設計

下節提供用於設計此解決方案的逐步方法。這個方法會採用客戶需求和設計假設，並且逐步解說設計 Exchange 2010 環境時需要制定的關鍵設計決策點。

Exchange 2010 已測試解決方案

決定高可用性策略

設計 Exchange 2010 環境時，許多高可用性策略的設計決策點會影響其他設計元件。建議您將決定高可用性策略做為設計程序的首要步驟。強烈建議您在開始進行此步驟之前，先行檢閱下列資訊：

步驟 1：決定是否需要站台恢復

如果您擁有多個資料中心，則必須決定是將 Exchange 基礎結構部署到單一資料中心，還是將它發佈至兩個或多個資料中心。組織的復原服務等級協定 (SLA) 應該定義主要資料中心失敗後所需的服務等級為何。此資訊應做為這項決策的基礎。

*設計決策點*

這個解決方案中有三個實際的資料中心位置。SLA 指出，包括電子郵件在內的所有關鍵服務都需要資料中心恢復。Exchange 2010 設計將以多重站台部署為基礎，搭配訊息服務和資料的站台恢復。

步驟 2：決定信箱使用者的位置和資料中心位置之間的關係

在這個步驟中，我們將決定讓所有信箱使用者主要位於單一站台上，還是分布到多個站台，以及這些站台是否與資料中心相關聯。如果要讓他們分布到多個站台，而且有些資料中心會與這些站台相關聯，您就需要決定是否有必要維護信箱使用者以及與該站台相關聯之資料中心之間的相似性。

*設計決策點*

在這個範例中，三個資料中心都與地區辦公室共置。因此有必要在正常運作的情況下，維護使用者位置與其使用中主要信箱副本的位置之間的相似性。

步驟 3：決定資料庫分配模型

由於客戶已決定將 Exchange 基礎結構部署到多個實體位置，因此客戶需決定最符合組織需要的資料庫分配模型。有三個資料庫分配模型：

  • 主動/被動分配   主動信箱資料庫副本會部署於主要資料中心，只有被動資料庫副本部署於次要資料中心。次要資料中心是待命資料中心，在正常運作情況下，該資料中心內不會裝載任何主動信箱。發生影響主要資料中心的中斷情況時，會手動轉換至次要資料中心，並且於該處裝載主動資料庫，直到主要資料中心恢復連線。

    主動/被動分配

  • 主動/主動分配 (單一 DAG)   主動信箱資料庫同時部署於主要和次要資料中心。對應的被動副本位於替代資料中心。所有信箱伺服器都是單一 DAG 的成員。在這個模型中，兩個資料中心之間的廣域網路 (WAN) 連線可能是單一失敗點。遺失 WAN 連線導致其中一個資料中心內的信箱伺服器因為失去仲裁而失敗。

    主動/主動分配 (單一 DAG)

  • 主動/主動分配 (多個 DAG)   這個模型利用多個 DAG 移除成為單一失敗點的 WAN 連線。其中一個 DAG 將主動資料庫副本放在第一個資料中心內，並且將其對應的被動資料庫副本放在第二個資料中心內。第二個 DAG 將主動資料庫副本放在第二個資料中心內，並且將其對應的被動資料庫副本放在第一個資料中心內。發生 WAN 連線遺失的情況時，每個站台中的主動副本都會繼續對本機信箱使用者提供資料庫可用性。

    主動/主動分配 (多個 DAG)

*設計決策點*

在這個範例中，由於主動信箱資料庫將部署於這三個資料中心位置，因此資料庫分配模型將會是主動/主動，具有多個 DAG。部署具有多個 DAG 的主動/主動資料庫分配模型時，還有一些額外的設計考量，將在稍後的步驟中說明。

步驟 4：決定備份和資料庫恢復策略

Exchange 2010 包含了幾種新功能和核心變更，如果正確部署與設定，就可以提供原生資料保護，而不再需要進行傳統的資料備份。傳統上，備份是用於嚴重損壞修復、復原意外刪除的項目、長期資料儲存，以及時間點資料庫復原。Exchange 2010 可以解決上述所有情況，而不需要傳統的備份：

  • 嚴重損壞修復   當硬體或軟體故障時，DAG 中有多個資料庫副本能夠提供高可用性，可快速容錯轉移，而且不會遺失任何資料。DAG 可以延伸到數個站台，並可讓資料中心從故障中恢復。

  • 復原意外刪除的項目   有了 Exchange 2010 全新的 [可復原的項目] 資料夾，以及可套用至資料夾的保留原則，就可以將所有遭刪除與修改的資料保留一段指定的時間，讓復原這些項目變得更簡單、更快速。如需相關資訊，請參閱郵件原則及符合性、了解可復原的項目與瞭解保留標記和保留原則。

  • 長期資料儲存   有時候備份也可做為封存使用。通常會使用磁帶，依規範的需求長時間保存資料的時間點快照。Exchange 2010 中新的封存、多信箱搜尋與訊息保留功能提供了一種機制，能夠以使用者可存取的方式有效率地長期保留資料。如需相關資訊，請參閱瞭解個人封存、瞭解多信箱搜尋與瞭解保留標記和保留原則。

  • 時間點資料庫快照   如果您的組織要求需有信箱資料的過去時間點副本，則 Exchange 能夠讓您在 DAG 環境中建立遲延副本。當有邏輯損毀複寫到整個 DAG 內的資料庫，造成需要回到過去的時間點時，這個功能會很有用，雖然這種狀況鮮少發生。如果系統管理員不小心刪除信箱或使用者資料，這也會很有幫助。

使用 Exchange 2010 內建的功能取代傳統備份之前，需要先考量一些技術原因與問題。做出這項決定之前，請先參閱瞭解備份、還原和嚴重損壞修復。

*設計決策點*

在這個範例中，使用目前的 Exchange 實作時，傳統備份解決方案的主要用途在於復原不小心刪除的郵件項目。要求復原單一郵件的情況中，有百分之八十是要求復原未超過 15 天的郵件。因此，刪除郵件的保留期間是 14 天。由於還原單一郵件不需要傳統的 VSS 備份，而且這些備份不符合復原時間的目標，因此 [Exchange 原生資料保護] 和 [刪除的郵件] 資料夾保留功能將會用作資料庫恢復策略。

步驟 5：決定所需的資料庫副本數目

定義資料庫恢復策略的下一個重要決策，是決定要部署的資料庫副本數目。在取代傳統的資料庫保護形式 (例如獨立磁碟容錯陣列 (RAID) 或傳統 VSS 備份) 之前，強烈建議您至少部署三個信箱資料庫副本。

做出這項決定之前，請先參閱瞭解信箱資料庫複本。

*設計決策點*

在這個範例中，由於未部署傳統的 VSS 備份，因此至少將會部署三個資料庫副本，以確保符合復原時間目標和復原點目標的需求。其中兩個副本將位於主要資料中心內，第三個副本則位於替代資料中心內，以提供站台恢復。

步驟 6：決定資料庫副本類型

資料庫副本有兩種類型：

  • 高可用性資料庫副本   這個資料庫副本的重新顯示延遲時間會設定為零。顧名思義，高可用性資料庫副本會由系統保持在最新狀態、可自動由系統啟動，且用來為信箱服務和資料提供高可用性。

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

*設計決策點*

在這個範例中，三個信箱資料庫副本全都會部署為高可用性副本。SLA 不需要資料的延遲副本。由於過去尚未發生邏輯損毀，而且不會使用操作郵件資料的其他應用程式，因此不需要延遲副本。唯一需要延遲副本的情況可能是提供復原單一已刪除郵件的能力，但是使用 [刪除的郵件] 資料夾保留功能就能輕鬆符合這項需求，而且符合成本效益。

步驟 7：決定信箱伺服器恢復策略

Exchange 2010 已針對信箱恢復功能重新設計。現在，自動容錯移轉保護是在信箱資料庫層級提供，而不是在伺服器層級提供。您可以策略性地將主動和被動資料庫副本發佈到 DAG 內的信箱伺服器。決定每部伺服器上要啟動的資料庫副本數目，是 Exchange 2010 容量規劃的重要部分。您可以部署不同的資料庫分配模型，但一般我們會建議下列其中一種：

  • 啟動所有副本的設計   在此模型中，Mailbox server role 的大小會調整為能夠容納在伺服器上啟動所有資料庫副本。例如，信箱伺服器可能主控四個資料庫副本。在正常運作的情況下，伺服器可能有兩個主動資料庫副本和兩個被動資料庫副本。在失敗或維護的情況下，四個資料庫副本都會在信箱伺服器上變成主動。此解決方案通常會成對部署。例如，如果部署四部伺服器，第一對伺服器為 MBX1 和 MBX2，而第二對伺服器為 MBX3 和 MBX4。此外，設計這個模型時，您將調整每一部信箱伺服器的大小，使其在正常運作的情況下不超過可用資源的 40%。在擁有三個資料庫副本和六部伺服器的站台恢復部署中，可以三部伺服器為一組部署此模型，其中第三部伺服器位於次要資料中心內。此模型為使用主動/被動站台恢復模型的解決方案提供了一個包含三部伺服器的建置組塊。

    此模型可以在下列案例中使用：

    • 主動/被動多重站台組態，其中失敗網域 (例如，機架、刀鋒型設備和儲存陣列) 需要能夠輕鬆隔離主要資料中心內的資料庫副本

    • 主動/被動多重站台組態，其中預期的增長可保證能夠輕鬆加入邏輯調整單位

    • 不需要承受 DAG 中任意兩部信箱伺服器之同步損失的組態

    此模型需要在單一站台部署中成對部署伺服器，在多重站台部署中則以三部伺服器為一組進行部署。下表說明此模型的範例資料庫配置。

    啟動所有副本的設計

    上表會套用下列各項：

    • C1 = 正常運作時的主動副本 (啟動喜好設定值為 1)

    • C2 = 正常運作時的被動副本 (啟動喜好設定值為 2)

    • C3 = 站台失敗時的被動副本 (啟動喜好設定值為 3)

  • 目標失敗案例的設計   在此模型中，Mailbox server role 設計為能夠容納在伺服器上啟動資料庫副本的子集。子集中的資料庫副本數目取決於做為設計目標的特定失敗案例。此設計的主要目標在於將主動資料庫負載平均分配到 DAG 中其餘的信箱伺服器。

    此模型應在下列案例中使用：

    • 擁有三個或多個資料庫副本的所有單一站台組態

    • 需要承受 DAG 中任意兩部信箱伺服器之同步損失的組態

    此模型的 DAG 設計需要 3 到 16 部信箱伺服器。下表說明此模型的範例資料庫配置。

    目標失敗案例的設計

    上表會套用下列各項：

    • C1 = 正常運作時的主動副本 (啟動喜好設定值為 1)

    • C2 = 正常運作時的被動副本 (啟動喜好設定值為 2)

    • C3 = 正常運作時的被動副本 (啟動喜好設定值為 3)

*設計決策點*

上一個步驟中決定部署擁有多個 DAG 的主動/主動資料庫分配模型。由於此模型中每個 DAG 的主動/被動組態在主要資料中心內都只有兩個高可用性資料庫副本，因此針對所有啟動之副本設計的信箱伺服器恢復策略最為理想。

步驟 8：決定資料庫可用性群組數目

DAG 是內建於 Exchange 2010 的高可用性和站台恢復架構的基礎元件。DAG 是最多包含 16 部信箱伺服器的群組，它主控一組複寫資料庫，並且可在發生影響個別伺服器或資料庫的失敗時，提供自動的資料庫層級復原。

DAG 是信箱資料庫複寫、資料庫與伺服器轉換及容錯移轉，以及名為 Active Manager 之內部元件的界限。Active Manager 是 Exchange 2010 的元件，負責管理轉換和容錯移轉。Active Manager 會在 DAG 中的每部伺服器上執行。

從規劃的觀點來看，您應該盡可能減少部署的 DAG 數目。應在出現下列情況時考慮多個 DAG：

  • 您部署超過 16 部信箱伺服器。

  • 您在多個站台中擁有主動信箱使用者 (主動/主動站台組態)。

  • 您需要獨立的 DAG 層級系統管理界限。

  • 您的信箱伺服器分佈在不同的網域中 (DAG 是以網域為界限)。

*設計決策點*

上一個步驟中決定部署主動/主動資料庫分配模型。您可以部署每一個站台中都有主動信箱使用者的單一 DAG。不過，如果某一個站台中的 DAG 成員暫時與另一個站台的 DAG 成員失去聯繫，該站台中的叢集將會遺失仲裁而且無法正常運作。基於這個理由，將會部署三個 DAG。每個 DAG 將包含來自主要資料中心的信箱伺服器，該資料中心將主控主要和次要資料庫副本。每個 DAG 還會包含其中一個替代資料中心的伺服器，該資料中心會主控第三個資料庫副本。產生的設計為三個主動/被動 DAG，其中每個資料中心會主控其中一個 DAG 的主要和次要副本，以及來自另一個 DAG 的第三個副本。

步驟 9：決定每個 DAG 的信箱伺服器數目

在這個步驟中，您需要決定支援 DAG 設計所需的信箱伺服器數目下限。這個數目可能會與支援工作負載所需的伺服器數目不同，因此在稍後的步驟中才會最終決定伺服器數目。

*設計決策點*

上一個步驟中決定部署三個主動/被動 DAG，並且針對所有啟動之副本設計伺服器恢復策略。每個 DAG 都必須以三部伺服器為遞增單位進行部署 (兩部位於主要站台，一部位於替代站台)。由於部署了三個 DAG，因此支援 DAG 設計的伺服器數目下限為九部。依照支援工作負載所需的伺服器數目而定，解決方案將擁有 9、18 或 27 部伺服器。下表概述可能的組態。

每個 DAG 的信箱伺服器數目

DAG1 主要資料中心 DAG1 次要資料中心 DAG2 主要資料中心 DAG2 次要資料中心 DAG3 主要資料中心 DAG3 次要資料中心 信箱伺服器總數

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27
注意事項附註：
在擁有三個節點的 DAG 模型中，如果您遺失主要資料中心內的兩個節點，叢集將遺失仲裁和自動啟動功能。次要資料中心內的第三個副本將提供額外的資料可用性，但是復原次要資料中心內的服務則需要手動進行。

Exchange 2010 已測試解決方案

預估信箱儲存容量需求

許多因素都會影響 Mailbox server role 的存儲容量需求。如需相關資訊，建議您檢閱瞭解信箱資料庫及記錄檔容量的因素。

以下步驟概述如何計算信箱容量需求。這些需求將會用來決定哪些儲存解決方案選項符合容量需求。稍後的章節中將涵蓋額外的計算，幫助您在選定的儲存平台上設計出適當的儲存配置。

Microsoft 建立了 Mailbox Server Role 需求計算器，可為您分擔大部分的工作。若要下載計算器，請參閱 E2010 Mailbox Server Role 需求計算器。如需有關使用計算器的詳細資訊，請參閱 Exchange 2010 Mailbox Server Role 需求計算器。

步驟 1：計算磁碟上的信箱大小

嘗試決定總儲存需求之前，應先了解未來磁碟上的信箱大小。1 GB 配額的完整信箱需要超過 1 GB 的磁碟空間，因為您必須將禁止傳送/接收限制、使用者每天傳送或接收的郵件數目、[刪除的郵件] 資料夾保留期限 (啟用或未啟用行事曆版本記錄和單一項目復原功能)，以及每個信箱平均每天的資料庫變化納入考量。Mailbox Server Role 需求計算器會為您執行這些計算。您也可以使用下列資訊手動進行這些計算。

下列計算可用來決定此解決方案中擁有 2 GB 信箱限制的信箱在磁碟上的信箱大小：

  • 空白字元 = 每天 100 封郵件 × 75 ÷ 1024 MB = 7.3 MB

  • 暫放 = (每天 100 封郵件 × 75 ÷ 1024 MB × 14 天) + (2048 MB × 0.012) + (2048 MB × 0.058) = 246 MB

  • 磁碟上的信箱大小 = 信箱限制 + 空白字元 + 暫放

    = 2048 + 7.3 + 246

    = 2,301 MB

步驟 2：計算資料庫儲存容量需求

這個步驟會決定所有信箱資料庫所需的高儲存容量。計算的容量包括資料庫大小、類別目錄索引大小和 20% 可用空間。

若要決定所有資料庫所需的儲存容量，請使用下列公式：

  • 資料庫大小 = (信箱數 × 磁碟上的信箱大小 × 資料庫負荷增長因數) + (20% 資料負荷)

    = (32400 × 2301 × 1) + (14910480)

    = 89,462,880 MB

    = 87,366 GB

  • 資料庫索引大小 = 資料庫大小的 10%

    = 87366 × 0.10

    = 8,737 GB

  • 資料庫總容量 = (資料庫大小) + (索引大小) ÷ 0.80 再加上 20% 磁碟區可用空間

    = (87366 + 8737) ÷ 0.8

    = 120,128 GB

步驟 3：計算交易記錄檔儲存容量需求

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

若要決定所有交易記錄檔所需的儲存容量，請使用下列公式：

  • 記錄檔大小 = (記錄檔大小 × 每個信箱每天的記錄檔數目 × 取代失敗的基礎結構所需的天數 × 信箱使用者數目) + (1% 信箱移動負荷)

    = (1 MB × 20 × 4 × 32400) + (32400 × 0.01 × 2048 MB)

    = 3,255,552 MB

    = 3,179 GB

  • 記錄檔總容量 = (記錄檔大小) ÷ 0.80 再加上 20% 磁碟區可用空間

    = (3179) ÷ 0.80

    = 3974

步驟 4：決定總儲存容量需求

下表摘要說明此解決方案的高儲存容量需求。在稍後步驟中，您將使用這項資訊決定要部署的儲存解決方案。接著將在後續步驟中深入了解特定儲存需求。

儲存容量需求的摘要

磁碟空間需求 值

磁碟上的平均信箱大小 (MB)

2301

所需資料庫容量 (GB)

120128

所需記錄檔容量 (GB)

3974

所需總容量 (GB)

124102

三個資料庫副本所需的總容量 (GB)

372306

三個資料庫副本所需的總容量 (TB)

364

每個站台所需的總容量 (TB)

122

Exchange 2010 已測試解決方案

預估信箱 I/O 需求

設計 Exchange 環境時，您需要了解資料庫和記錄檔效能因數。建議您檢閱瞭解資料庫與記錄檔效能因素。

步驟 1：計算總信箱 I/O 需求

因為這是適當調整儲存大小所需的一個關鍵交易 I/O 度量，因此您應了解每一位信箱使用者每秒使用的資料庫 I/O (IOPS) 大小。純循序 I/O 作業未考慮每部信箱伺服器計算的 IOPS，因為儲存子系統會以比隨機 I/O 更有效的方式處理循序 I/O。這些作業包括背景資料庫維護、記錄交易式 I/O 及記錄複寫 I/O。在這個步驟中，您會使用下列資訊計算支援所有信箱使用者所需的總 IOPS：

  • 每位信箱使用者預估的 IOPS = 0.10

  • 所需的總 IOPS = 每位信箱使用者的 IOPS × 信箱數 × I/O 負荷因數

    = 0.10 × 32400 × 1.2

    = 3888

注意事項附註：
若要決定不同郵件設定檔的 IOPS 設定檔，請參閱瞭解資料庫與記錄檔效能因素中的「以郵件活動為基礎的資料庫快取和各信箱的預估 IOPS」表。

步驟 2：計算每個站台的總信箱 I/O 需求

由於這是多重站台部署，因此您必須考量各站台的 IOPS 需求，以便正確設定每個站台的儲存大小。上一個步驟中決定每個站台會主控來自主要 DAG 的主要和次要資料庫副本，以及來自替代 DAG 的第三個資料庫副本。在此模型中，最糟情況的案例會是單一站台失敗，而該站台中的儲存上主要 DAG 的 10,800 個信箱和替代 DAG 的 10,800 個信箱是主動的。使用下列計算：

  • 每個站台所需的總 IOPS = 每位信箱使用者的 IOPS × 信箱數 × I/O 負荷因數

    = 0.10 × 21600 × 1.2

    = 2592

Exchange 2010 已測試解決方案

決定儲存類型

Exchange 2010 包含了效能、可靠性和高可用性方面的改善，可讓組織在各種不同的儲存選項上執行 Exchange。

檢查可用的儲存選項時，平衡效能、容量、管理能力和成本需求的能力是獲得成功的 Exchange 儲存解決方案所不可或缺的。

如需為 Exchange 2010 選擇儲存解決方案的相關資訊，請參閱信箱伺服器儲存設計。

Exchange 2010 已測試解決方案

決定是否偏好 DAS 或 SAN 儲存解決方案

有各式各樣的儲存選項可供 Exchange 2010 使用。藉由決定偏好部署直接連接儲存 (DAS) 解決方案 (包括使用本機磁碟) 或 SAN 解決方案，就可縮小選擇清單的範圍。這兩種選擇背後都各有許多支持的理由，因此您應與偏好的儲存廠商共同決定符合您的業務和總購置成本 (TCO) 需求的解決方案。

*設計決策點*

在此範例中，將會部署 SAN 基礎結構，並且使用 SAN 儲存環境中的所有資料。因此將繼續使用 SAN 儲存解決方案，並且將探討部署 Exchange 2010 的選項。

Exchange 2010 已測試解決方案

選擇儲存解決方案

請使用下列步驟選擇儲存解決方案。

步驟 1：確定慣用的儲存廠商

在這個範例中，EMC 儲存已使用多年，因此 EMC 儲存解決方案將用於 Exchange 2010 部署。EMC Corporation 提供高效能儲存陣列，諸如 CLARiiON 和 Symmetric。

步驟 2：檢閱偏好廠商提供的可用選項

EMC CLARiiON 系列提供多層儲存，例如企業快閃磁碟機、光纖通道和 Serial ATA (SATA)，它可降低成本的原因在於可由單一管理介面管理多層。

CLARiiON Virtual Provisioning 提供了超越傳統精簡佈建的優點，包括簡化的儲存管理和改善的容量使用率。您可以對主機呈現大量容量，然後視需要從共用集區耗用空間。

CLARiiON CX4 Series 提供四種模型，包含了彈性的容量、功能和效能層級。各模型的功能如下表所述。

CLARiiON CX4 Series 功能

Feature CX4 model 120 CX4 model 240 CX4 model 480 CX4 model 960

磁碟數上限

120

240

480

960

儲存處理器

2

2

2

2

每個儲存處理器的實體記憶體

3 GB

4 GB

8 GB

16 GB

寫入快取上限

600 MB

1.264 GB

4.5 GB

10.764 GB

每個系統的啟動器數目上限

256

512

512

1024

高可用性主機

128

256

256

512

最小外觀尺寸

6U

6U

6U

9U

標準 LUN 數目上限

1024

1024

4096

4096

SnapView 快照

是

是

是

是

SnapView 複製

是

是

是

是

SAN 副本

是

是

是

是

MirrorView/S

是

是

是

是

MirrorView/A

是

是

是

是

RecoverPoint/S

是

是

是

是

RecoverPoint/A

是

是

是

是

步驟 3：選取磁碟類型

此範例中會選取 450 GB 光纖通道 15,000 rpm 磁碟。此等磁碟可提供良好的 I/O 效能和容量，以滿足初始 Exchange 使用者需求。

注意事項附註：
從測試時開始，600 GB 10,000 rpm 磁碟的成本已降低，而且相當適合此部署。

步驟 4：選取陣列

在這個範例中，解決方案需要提供 122 TB 可用儲存及 2,592 IOPS。上表中的任何選項都能處理 IOPS 需求，因此將依據容量需求做出決定。CLARiiON CX4 model 240 僅提供約 100 TB 可用容量，包括 RAID-5 組態中的 450 GB 磁碟。因此會選取 EMC CLARiiON CX4 model 480，它提供了必要的容量和 I/O 效能，可支援所有 Exchange 2010 需求。

Exchange 2010 已測試解決方案

預估信箱記憶體需求

正確設定記憶體大小是設計狀況良好 Exchange 環境的重要步驟。建議您檢閱瞭解記憶體組態和 Exchange 效能和瞭解信箱資料庫快取。

Exchange 2010 已測試解決方案

計算需要的資料庫快取

可延伸儲存引擎 (ESE) 使用資料庫快取來減少 I/O 作業。一般而言，可用的資料庫快取越大，Exchange 2010 信箱伺服器上產生的 I/O 就越少。不過，到達某一個點之後，加入額外的資料庫快取不再能夠大幅減少 IOPS。因此，在未決定所需的最佳資料庫快取數量的情況下於 Exchange 伺服器中加入大量實體記憶體，可能導致成本增加，效能卻不如預期。

您在前一個步驟中完成的 IOPS 預估會假設每個信箱的最小資料庫快取數量。這些最小數量摘要說明於瞭解信箱資料庫快取的「以郵件活動和信箱資料庫快取為基礎的每個信箱的預估 IOPS」表中。

下表概述不同郵件設定檔的每位使用者資料庫快取。

每位使用者的資料庫快取

每日每個信箱傳送或接收的郵件 (平均郵件大小約 75 KB) 每位使用者的資料庫快取 (MB)

50

3 MB

100

6 MB

150

9 MB

200

12 MB

在這個步驟中，您會決定整個環境的進階記憶體需求。後續步驟中，您會使用這個結果決定每部信箱伺服器需要的實體記憶體數量。使用下列計算：

  • 資料庫快取 = 設定檔專用資料庫快取 × 信箱使用者數目

    = 6 MB × 32400

    = 194,400 MB

    = 190 GB

Exchange 2010 已測試解決方案

預估信箱 CPU 需求

與舊版 Exchange 相較之下，信箱伺服器容量規劃因為 Exchange 2010 中提供的全新信箱資料庫恢復模型而有了相當大的改變。如需相關資訊，請參閱信箱伺服器處理器容量規劃。

在下列步驟中，您將計算主動和被動資料庫副本的高層級 MHz 需求。這些需求將在後續步驟中，用來決定支援工作負載所需的信箱伺服器數目。請注意，需要的信箱伺服器數目也取決於信箱伺服器恢復模型和資料庫副本配置。

使用 MHz 需求決定 Exchange 信箱伺服器可支援的信箱使用者數目並不確實。有許多因素都會在測試和生產環境中造成無法預期的 MHz 結果。MHz 只應用來概算 Exchange 信箱伺服器可支援的信箱使用者數目。在設計程序中進行容量規劃時，最好採取較保守而非積極的方式。

下列計算是以發佈的 MHz 預估為基礎，如下表中摘要說明。

MHz 預估

每日每個信箱傳送或接收的郵件 主動信箱資料庫之每個信箱的 MHz 遠端被動式信箱資料庫之每個信箱的 MHz 每個本機被動式信箱的 MHz

50

1

0.1

0.15

100

2

0.2

0.3

150

3

0.3

0.45

200

4

0.4

0.6

步驟 1：計算主動信箱 CPU 需求

在這個步驟中，您將使用下列方式計算支援主動資料庫副本所需的 MHz：

  • 需要的主動信箱 MHz = 設定檔專用 MHz × 信箱使用者數目

    = 2 × 32400

    = 64800

步驟 2：計算主動信箱遠端資料庫副本 CPU 需求

在每個資料庫擁有三個副本的設計中，會有與傳送記錄相關聯的處理器額外負荷，這些記錄是維護遠端伺服器上的資料庫副本所需。這個額外負荷通常是服務的每個遠端副本之主動信箱 MHz 的 10%。使用下列方式計算需求：

  • 需要的遠端副本 MHz = 設定檔專用 MHz × 信箱使用者數目 × 遠端副本數目

    = 0.1 × 32400 × 2

    = 6480

步驟 3：計算本機被動式信箱 CPU 需求

在每個資料庫擁有三個副本的設計中，會有與維護每個資料庫的本機被動副本相關聯的處理器額外負荷。這個步驟中將會計算支援本機被動資料庫副本所需的高層級 MHz。這些數字將在後續步驟中進一步調整，以便符合伺服器恢復策略和資料庫副本配置。使用下列方式計算需求：

  • 需要的本機被動式信箱 MHz = 設定檔專用 MHz × 信箱使用者數目 × 被動副本數目

    = 0.3 × 32400 × 2

    = 19440

步驟 4：計算總 CPU 需求

使用下列方式計算總需求：

  • 所需的總 MHz = 主動信箱 + 遠端被動 + 本機被動

    = 64800 + 6480 + 19440

    = 90720

    每個信箱的平均 MHz = 90720 ÷ 32400 = 2.8

Exchange 2010 已測試解決方案

摘要說明信箱需求

下表摘要說明此環境所需的概略 MHz 和資料快取。這些資訊將在後續步驟中用來決定解決方案中部署的伺服器。

信箱需求摘要

信箱 CPU 需求 值

整個環境所需的總 MHz

97200

整個環境所需的資料庫快取總數

190 GB

Exchange 2010 已測試解決方案

決定伺服器機型

您可以使用下列步驟決定伺服器機型。

步驟 1：確定慣用的伺服器廠商

在此解決方案中，偏好的伺服器平台是 Cisco Unified Computing System，這是將運算、網路、儲存存取和虛擬化整合為一套系統的資料中心平台，專為降低 TCO 和提高靈活度所設計。這套系統整合了低延遲的 10 GB 乙太網路整合網路結構與企業級的 x86 架構伺服器。透過系統的方式提供架構、技術、合作關係和服務，Cisco Unified Computing System 簡化了資料中心資源、延伸了服務傳遞，並且減少了需要安裝、管理、供電、冷卻和佈線的裝置數目。

步驟 2：檢閱偏好廠商提供的可用選項

Cisco Unified Computing System 是一套刀鋒型伺服器系統，由四個主要系統元件組成。這些系統元件為結構互連、底座、結構擴充工具 (I/O 模組) 和刀鋒型伺服器。

下列刀鋒型伺服器機型為此解決方案的可能選項。

選項 1：B200 刀鋒型伺服器

Cisco Unified Computing System B200 刀鋒型伺服器是半寬式的雙槽刀鋒型伺服器。這套系統使用兩顆 Intel Xeon 5500 或 5600 系列處理器、高達 96 GB 的 DDR3 記憶體、兩台選購的可熱交換小型 SAS 磁碟機，以及單夾層連接器，可提供高達每秒 20 GB (Gbps) 的 I/O 輸送量。這部伺服器在實際執行等級虛擬化和其他主流資料中心負載的簡單性、效能及密度之間取得平衡。

選項 2：B250 刀鋒型伺服器

Cisco Unified Computing System B250 延伸記憶體刀鋒型伺服器為全寬的雙槽刀鋒型伺服器，採用了 Cisco 延伸記憶體技術。這套系統支援兩顆 Intel Xeon 5500 或 5600 系列處理器、高達 384 GB 的 DDR3 記憶體、兩台選購的小型 SAS 磁碟機，以及兩個夾層連接，可提供高達 40 Gbps 的 I/O 輸送量。這部伺服器提高了虛擬化和大量資料集工作負載的效能和容量。

選項 3：B440 刀鋒型伺服器

Cisco Unified Computing System B440 刀鋒型伺服器是專為支援企業應用程式所設計，包括大型資料集和交易密集的資料庫、企業資源規劃 (ERP) 程式，以及決策支援系統 (DSS)。Cisco Unified Computing System B440 採用 Intel Xeon 7500 系列處理器，可以提供可延展的效能和可靠性功能，有助於擴大工作負載虛擬化的範圍，以及在整合式的簡化基礎結構內統一效能密集的獨立應用程式。Cisco Unified Computing System B440 最多可支援 32 顆處理核心及 256 GB 主要記憶體，具有合併高達 40 Gbps 的 I/O 輸送量。

步驟 3：選取伺服器機型

之所以選取搭配了 Intel Xeon X5570 處理器的 Cisco Unified Computing System B200，是因為這部刀鋒型伺服器對於這個部署來說，擁有處理能力、記憶體容量和外觀尺寸上的最佳平衡。根據包括延展性和成本在內的所有相關因素，雙槽伺服器平台經常是 Exchange 2010 部署的不錯選擇。Cisco Unified Computing System B250 支援較高的記憶體組態和較高的 I/O 輸送量，不過並非解決方案所需。

注意事項附註：
從測試時開始，600 GB 10,000 rpm 磁碟的成本已降低，而且相當適合此部署。

Exchange 2010 已測試解決方案

計算伺服器機型的 CPU 容量

在前述步驟中，您已計算出支援主動信箱使用者數目所需的 MHz。接下來的步驟中，您將決定伺服器機型和處理器可支援的可用 MHz 數目，進而決定每部伺服器可支援的主動信箱數目。

步驟 1：決定伺服器和處理器的基準值

由於 MHz 需求是依據基準伺服器和處理器模型而定，因此您需要依據基準調整伺服器的可用 MHz。做法是使用標準效能評估公司 (SPEC) 所提供的獨立效能評定標準。SPEC 是非營利組織，成立的目的在於建立、維護及註記適用於新一代高效能電腦的一套標準化相關評定標準。

為了協助簡化為伺服器和處理器取得基準值的程序，建議您使用 Exchange 處理器查詢工具。這項工具會自動化手動步驟，判斷出您所規劃處理器的 SPECint 2006 評定值。若要執行這項工具，您的電腦必須連接到網際網路。這項工具是使用您規劃的處理器機型做為輸入值，然後對標準效能評估公司網站執行查詢，然後傳回該特定處理器機型的所有測試結果資料。另外還會依據每部信箱伺服器中規劃使用的處理器數目計算平均 SPECint 2006 評定值。使用下列計算：

  • 處理器 = Intel X5570 2.93 GHz

  • SPECint_rate2006 值 = 256

  • 每個處理器核心的 SPECint_rate2006 值 = 256 ÷ 8

    = 32

步驟 2：計算調整後的 MHz

在前述步驟中，您已依據每個信箱預估的 MHz 計算出整個環境所需的 MHz。這些預估是依據基準系統 (HP DL380 G5 x5470 3.33 GHz，8 核心) 所測量，其 SPECint_rate2006 值為 150 (針對 8 核心伺服器)，每個核心為 18.75。

在這個步驟中，您需要依據基準處理器調整所選伺服器和處理器的可用 MHz，以便使用所需的 MHz 進行容量規劃。

若要決定 Cisco B200-M1 Intel X5570 2.93 GHz 平台的 MHz，請利用下列公式：

  • 每個核心調整後的 MHz = (新平台每個核心值) × (基準平台每個核心的 Hz) ÷ (基準每個核心值)

    = (32 × 3330) ÷ 18.75

    = 5683

  • 每部伺服器調整後的 MHz = 每個核心調整後的 MHz × 核心數

    = 5683 × 8

    = 45466

步驟 3：計算每部信箱伺服器可用的 MHz

得知每部伺服器調整後的 MHz 之後，您需要調整目標最大處理器使用率。上一節中已決定尖峰期工作負載或失敗案例期間的處理器使用率不超過 80%。使用下列計算：

  • 調整後的可用 MHz = 每部伺服器的可用 MHz × 目標最大處理器使用率

    = 45466 × 0.80

    = 36372

每部伺服器的可用容量為 36,372 MHz。

Exchange 2010 已測試解決方案

決定所需的實體信箱伺服器數目

您可以利用下列步驟決定所需的實體信箱伺服器數目。

步驟 1：決定單一信箱伺服器支援的主動信箱數目上限

若要決定信箱伺服器支援的主動信箱數目，請使用下列計算：

  • 主動信箱數 = 每部伺服器可用的 MHz ÷ 每個信箱的 MHz

    = 36372 ÷ 2.8

    = 12990

步驟 2：決定每個站台所需的信箱伺服器數目下限，以支援每個 DAG 所需的工作負載

每個 DAG 擁有 10,800 個主動信箱。若要決定支援 DAG 中所有信箱所需的信箱伺服器數目下限，請使用下列計算：

  • 所需伺服器數目 = 每個 DAG 的總信箱計數 ÷ 每部伺服器的主動信箱數目

    = 10800 ÷ 12990

    = 0.83

每個 DAG 最少需要一部信箱伺服器來支援 10,800 個信箱的工作負載。

步驟 3：決定支援每個 DAG 的信箱恢復策略所需的伺服器數目

上一個步驟決定為主動/被動 DAG 中啟動的所有副本進行設計。這個模型需要以三個為一組的方式為每個 DAG 部署 Mailbox server role。

信箱伺服器和 DAG 的數目

DAG1 主要資料中心 DAG1 次要資料中心 DAG2 主要資料中心 DAG2 次要資料中心 DAG3 主要資料中心 DAG3 次要資料中心 信箱伺服器總數

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

根據 DAG 設計而定，每個 DAG 中至少需要三部實體信箱伺服器，而全部三個 DAG 總共需要至少九部實體信箱伺服器。

Exchange 2010 已測試解決方案

決定正常運作和失敗案例情況下每部信箱伺服器的主動信箱數目

您可以利用下列步驟決定正常運作和失敗案例情況下，每部信箱伺服器的主動信箱數目。

步驟 1：決定正常運作情況下每部信箱伺服器的主動信箱數目

若要決定正常運作情況下每部信箱伺服器主控的主動信箱數目，請使用下列計算：

  • 每部伺服器的信箱數 = DAG 中的總信箱數 ÷ 主要資料中心內的信箱伺服器數目

    = 10800 ÷ 2

    = 5400

步驟 2：決定主要資料中心內某一部信箱伺服器失敗時，每部信箱伺服器的主動信箱數目

在主要資料中心內的某一部信箱伺服器失敗時，失敗之伺服器上的 5,400 個主動信箱將在其餘伺服器上變成主動。在這種情況下，其餘的信箱伺服器將有 10,800 個主動信箱。

步驟 3：決定主要資料中心內兩部信箱伺服器都失敗時，每部信箱伺服器的主動信箱數目

在主要資料中心離線時，主要資料中心內的 10,800 個主動信箱將會在次要資料中心內啟動。在這種情況下，次要資料中心內的單一伺服器將會擁有 10,800 個主動信箱。

Exchange 2010 已測試解決方案

決定是否將 Client Access Role 和 Hub Transport Server Role 部署到不同的實體伺服器上

決定在擁有較少數伺服器的環境中部署的 Client Access server role 和 Hub Transport server role 數目時，您可能會考慮將兩個角色部署在同一部實體電腦上。這樣可減少需要管理的實體電腦數目、需要更新和維護的伺服器作業系統數目，以及需要購買的 Windows 和 Exchange 授權數目。結合 Client Access server role 和 Hub Transport server role 的另一項優點是簡化設計程序。單獨部署角色時，建議您為每四個信箱伺服器邏輯處理器部署一個 Hub Transport Server 邏輯處理器，以及為每四個信箱邏輯處理器部署三個 Client Access Server 邏輯處理器。這種情況可能造成混淆，尤其是您將發生多個實體伺服器失敗或維護案例時提供足夠的 Client Access Server 和 Hub Transport Server 納為重要的因素時。在類似實體伺服器或 VM 上部署 Client Access Server 和 Hub Transport Server 以及信箱伺服器時，您可以為站台中的每部信箱伺服器部署一個 Client Access Server 和 Hub Transport Server 的組合。

*設計決策點*

此解決方案已決定讓 Hub Transport server role 和 Client Access server role 位於同一部實體電腦上。這樣將減少需要管理的作業系統數目，並且讓伺服器恢復的規劃工作更容易。

Exchange 2010 已測試解決方案

決定需要的實體 Client Access Server 和 Hub Transport Server 組合數目

在上一個步驟中，您決定每一個站台需要三部信箱伺服器 (兩部來自 DAG 的信箱伺服器主控該站台的主動信箱，一部來自替代 DAG 的信箱伺服器支援該 DAG 的主要資料中心發生失敗時的站台恢復)。

建議您為每一部信箱伺服器部署一個 Client Access Server 和 Hub Transport Server 組合，如下表所示。

需要的實體 Client Access Server 和 Hub Transport Server 組合數目

伺服器角色組態 建議的處理器核心比率

信箱：Client Access 和 Hub Transport combined server role

1:1

如果相同站台中有多個 DAG，則需先檢查最糟情況案例，才能決定需要的 Client Access Server 和 Hub Transport Server 組合數目。在此解決方案中，最糟情況案例會是喪失主要 DAG 中兩部信箱伺服器的其中一部，同時站台上發生其他失敗，使得其他站台的主動信箱現在主控於同一個站台上。在此案例中，您的站台中會有 21,600 個主動信箱在兩部信箱伺服器上執行，因此每個站台至少需要兩個 Client Access Server 和 Hub Transport Server 組合，如下圖中所示。

Client Access Server 和 Hub Transport Server

Exchange 2010 已測試解決方案

決定所需的實體伺服器總數

目前為止，您已決定需要 15 部實體伺服器來支援三個資料中心內 32,400 個主動信箱的 Client Access server role、Hub Transport server role 和 Mailbox server role，如下圖中所示。

所需的實體伺服器數目

Exchange 2010 已測試解決方案

決定是否將使用伺服器虛擬化

考慮 Exchange 的伺服器虛擬化時，有幾個因素很重要。如需支援之虛擬化組態的相關資訊，請參閱 Exchange 2010 系統需求。

請考慮搭配 Exchange 使用虛擬化，原因如下：

  • 如果您預期伺服器容量無法獲得充分利用，並且希望更充分利用，可以藉由虛擬化達到購買更少伺服器的結果。

  • 在同一部實體伺服器上部署 Client Access server role、Hub Transport server role 和 Mailbox server role 時，您可能想要使用 Windows 網路負載平衡 (NLB)。

  • 如果您的組織在所有伺服器基礎結構中使用虛擬化，您可能想要使用虛擬化搭配 Exchange 以符合公司的標準原則。

若要決定是否應在此環境中使用虛擬化，請考慮預期的處理器使用率並且判斷伺服器是否可能無法獲得充分利用。

步驟 1：決定正常運作情況下預期的信箱伺服器 CPU 使用率

若要決定單一信箱伺服器上 5,400 個主動信箱的 CPU 使用率，請使用下列計算：

  • 處理器百分比 (尖峰正常運作) = 需要的 MHz ÷ 可用的 MHz

    = (5400 × 2.8) ÷ 45466

    = 33.2%

步驟 2：計算最糟失敗情況下預期的信箱伺服器 CPU 使用率

若要決定單一信箱伺服器上 10,800 個主動信箱的 CPU 使用率，請使用下列計算：

  • 處理器百分比 (尖峰失敗情況) = 需要的 MHz ÷ 可用的 MHz

    = (10800 × 2.8) ÷ 45466

    = 66.5%

*設計決策點*

由於伺服器在最糟失敗情況下規劃為低於 80% 使用率目標，因此使用虛擬化或許能夠減少伺服器數目。這將在後續步驟中進一步探討。

Exchange 2010 已測試解決方案

判斷虛擬化是否可用來減少實體伺服器的數目

在下列步驟中，您將判斷虛擬化是否可用來減少此解決方案所需的實體伺服器數目。Microsoft Hyper-V 將用作虛擬化平台。

步驟 1：將虛擬化加入現有的實體伺服器計數

在測試時，Microsoft Hyper-V 最多可支援每部虛擬機器中的四個虛擬處理器。在實際設計中，主要 DAG 的 Mailbox server role 會跨兩部實體伺服器部署，總共擁有 16 個邏輯處理器。加入虛擬化之後，主要 DAG 的 Mailbox server role 現在部署於四部虛擬機器中，每部虛擬機器擁有四個虛擬處理器，因此總共擁有 16 個虛擬處理器。

在實際設計中，替代 DAG 的 Mailbox server role 會部署到擁有八個邏輯處理器的單一實體伺服器上。加入虛擬化之後，替代 DAG 的 Mailbox server role 現在部署於兩部虛擬機器中，每部虛擬機器擁有四個虛擬處理器，因此總共擁有八個虛擬處理器。

在實際設計中，Client Access Server 和 Hub Transport Server 組合會部署到兩部實體伺服器上，總共擁有 16 個邏輯處理器。加入虛擬化之後，Client Access Server 和 Hub Transport Server 組合現在部署於四部虛擬機器中，每部虛擬機器擁有四個虛擬處理器，因此總共擁有 16 個虛擬處理器。

使用擁有八個邏輯處理器的 Hyper-V 根伺服器時，最好的做法是在每一部 Hyper-V 根伺服器上部署一部信箱伺服器虛擬機器和一部 Client Access Server 和 Hub Transport Server 組合虛擬機器。

現在解決方案在每一個站台上擁有在五部實體伺服器上執行的 10 部虛擬機器，如下圖中所示。

虛擬機器

步驟 2：減少實體伺服器數目

根據上述步驟的計算，您預期最糟情況工作負載的 MHz 需求可以由四部實體伺服器處理。在這個步驟中，您會將實體伺服器數目從五部減少為四部，並且將替代 DAG 中的信箱伺服器重新分配至其餘四部實體伺服器。為了維持四部實體伺服器的對稱性，您需要將兩部信箱伺服器虛擬機器 (擁有四個虛擬處理器) 變更為四部信箱伺服器虛擬機器 (擁有兩個虛擬處理器)。

這樣一來，每一個站台上就會有在四部實體伺服器上執行的 12 部虛擬機器，如下圖中所示。

虛擬機器

虛擬機器

步驟 3：決定指派給每部虛擬機器的虛擬處理器數目

在這個步驟中，您將預估每部虛擬機器需要的虛擬處理器數目。在下列步驟中，您將執行計算來驗證這些假設。

主要 DAG 中的四部信箱伺服器虛擬機器中，每一部在正常運作情況下都將支援 DAG 中 10,800 個主要信箱的 25%，也就是各支援 2,700 個信箱。在伺服器失敗的情況下，剩餘的信箱伺服器虛擬機器將需支援 5,400 個主動信箱。

在站台失敗的情況下，主要 DAG 的四部信箱伺服器虛擬機器中，每一部都將支援 DAG 中 10,800 個主動信箱的 25%，也就是各支援 2,700 個信箱。在這種情況下，信箱將在第三個和最後一個資料庫副本上執行。在伺服器或虛擬機器失敗的情況下，剩餘的虛擬機器將不需支援 5,400 個主動信箱。信箱數目的上限將永遠是 2,700 個。

這種情況很合哩，因為替代 DAG 中的虛擬機器擁有的虛擬處理器數目是主要 DAG 中虛擬機器擁有的一半。在此解決方案中，將四個虛擬處理器指派給主要 DAG 中的虛擬機器，並且將兩個虛擬處理器指派給替代 DAG 中的虛擬機器。

如果您讓邏輯處理器與虛擬處理器維持 1:1 的比率，就會留給每個 Client Access Server 和 Hub Transport Server 組合兩個虛擬處理器。因為您想要讓信箱伺服器核心與 Client Access Server 和 Hub Transport Server 組合核心維持 1:1 比率，所以請指派四個虛擬處理器給每個 Client Access Server 和 Hub Transport Server 組合。結果會是根伺服器上虛擬處理器的數目超過實體處理器的數目。這種情況稱為*「過度訂閱」*(Oversubscription)。在大部分情況下，建議您不要使用過度訂閱。不過在此解決方案中，替代 DAG 中的信箱伺服器虛擬機器只會在站台失敗時使用。因為這種情況發生的機率很低，所以稍微過度訂閱不會有問題。

下表說明建議的虛擬處理器配置。

虛擬處理器配置

虛擬機器 虛擬處理器計數

Client Access 和 Hub Transport 組合

3

信箱 (主要 DAG)

4

信箱 (替代 DAG)

2

總計

9

Exchange 2010 已測試解決方案

計算 Hyper-V 根伺服器的 CPU 容量

在前述步驟中，您已計算出支援主動信箱使用者數目所需的 MHz。接下來的步驟中，您將決定伺服器機型和處理器可支援的可用 MHz 數目，以便決定每部虛擬伺服器可支援的主動信箱數目。

Exchange 2010 已測試解決方案

調整虛擬化負荷的可用 MHz

在根伺服器上部署虛擬機器時，必須考慮支援 Hypervisor 和虛擬堆疊所需的 MHz。這項負荷依伺服器和不同的工作負載而有所差異。將會使用保守預估的 10% 可用 MHz，如下列計算所示：

  • 調整後的可用 MHz = 可用的 MHz × 0.90

    = 45466 × 0.90

    = 40919

每部伺服器的虛擬機器可用容量為 40,919 MHz。

每個邏輯處理器的可用容量為 5,115 MHz。

Exchange 2010 已測試解決方案

決定虛擬機器的 CPU 容量

在上一個步驟中，您決定了三種虛擬機器類型的虛擬處理器配置，如下表中所示。

虛擬處理器配置

虛擬機器 虛擬處理器計數

Client Access 和 Hub Transport 組合

3

信箱 (主要 DAG)

4

信箱 (替代 DAG)

2

總計

9

步驟 1：決定每個虛擬處理器可用的 MHz

由於有九個虛擬處理器在擁有八個邏輯處理器的根伺服器上執行，因此虛擬處理器的 MHz 容量不等於邏輯處理器的 MHz 容量。在這個步驟中，計算每個虛擬處理器可用的 MHz：

  • 每個虛擬處理器的 MHz = 每個邏輯處理器的 MHz × (邏輯處理器數目 ÷ 虛擬處理器數目)

    = 5115 × (8 ÷ 9)

    = 4547

步驟 2：決定每部虛擬機器可用的 MHz

在這個步驟中，請參考下表決定每部虛擬機器可用的 MHz。

每部虛擬機器可用的 MHz

虛擬機器 虛擬處理器計數 每個虛擬處理器的 MHz 可用的 MHz

Client Access 和 Hub Transport 組合

3

4547

13641

信箱 (主要 DAG)

4

4547

18188

信箱 (替代 DAG)

2

4547

9094

步驟 3：決定每部虛擬機器的目標可用 MHz

由於設計假設中表示不超過 80% 處理器使用率，因此請調整可用 MHz 以反映 80% 的目標，如下表中所示。

每部虛擬機器的目標可用 MHz

虛擬機器 可用的 MHz 最大處理器使用率 目標可用 MHz

Client Access 和 Hub Transport 組合

13641

80%

10913

信箱 (主要 DAG)

18188

80%

14550

信箱 (替代 DAG)

9094

80%

7275

Exchange 2010 已測試解決方案

驗證主要信箱伺服器虛擬機器的 CPU 容量

若要驗證主要信箱伺服器虛擬機器的 CPU 容量，請利用下列步驟。

步驟 1：決定最糟情況工作負載下的 MHz 需求

主要信箱伺服器的最糟情況工作負載是指主要信箱伺服器上的 5,400 個信箱都為主動，而第二個和第三個遠端副本處於維護狀態的伺服器失敗或維護案例 (例如，要更新被動副本，但是主動信箱尚未移回目標伺服器的復原事件之後)。在這個步驟中，您會使用下列計算決定主要信箱伺服器虛擬機器的 MHz 需求：

  • 所需的信箱 MHz = (信箱使用者數 × 設定檔專用 MHz) + 遠端資料庫副本數 × (信箱使用者數 × 設定檔專用 MHz × 10%)

    = (5400 × 2) + 2 × (5400 × 2 × 0.1)

    = 10800 + 2160

    = 12960

步驟 2：決定主要信箱伺服器虛擬機器是否可支援最糟情況案例工作負載

在這個步驟中，您將決定可用 MHz 是否大於所需的 MHz。您需要 12,960 MHz 且擁有 14,550 MHz，因此主要信箱伺服器虛擬機器擁有足夠的容量可支援 5,400 個主動信箱。

Exchange 2010 已測試解決方案

驗證次要信箱伺服器虛擬機器的 CPU 容量

若要驗證次要信箱伺服器虛擬機器的 CPU 容量，請利用下列步驟。

步驟 1：決定最糟情況工作負載下的 MHz 需求

次要信箱伺服器的最糟情況工作負載是指次要信箱伺服器上的 2,700 個信箱都為主動，而第二個和第三個遠端副本處於維護狀態的站台失敗案例 (例如，在原始站台恢復上線之後，原始的主要和次要副本都要更新，但是主動信箱尚未移回原始站台)。在這個步驟中，您會使用下列計算決定次要信箱伺服器虛擬機器的 MHz 需求：

  • 所需的信箱 MHz = (信箱使用者數 × 設定檔專用 MHz) + 遠端資料庫副本數 × (信箱使用者數 × 設定檔專用 MHz × 10%)

    = (2700 × 2) + 2 × (2700 × 2 × 0.1)

    = 5400 + 1080

    = 6480

步驟 2：決定主要信箱伺服器虛擬機器是否可支援最糟情況案例工作負載

在這個步驟中，您將決定可用 MHz 是否大於所需的 MHz。您需要 6,480 MHz 且擁有 7,275 MHz，因此次要信箱伺服器虛擬機器擁有足夠的容量可支援 2,700 個主動信箱。

Exchange 2010 已測試解決方案

決定每部主要信箱伺服器虛擬機器所需的記憶體

您可以利用下列步驟決定每部主要信箱伺服器虛擬機器所需的記憶體。

步驟 1：決定最糟失敗案例情況下每部伺服器的資料庫快取需求

在上一個步驟中，您決定所有信箱的資料庫快取需求為 190 GB 且每個主動信箱所需的平均快取為 6 MB。

為了針對最糟失敗案例進行設計，您將依據其餘信箱伺服器虛擬機器上的 5,400 個主動信箱計算所需的資料庫快取：

  • 資料庫快取所需的記憶體 = 主動信箱數目 × 每個信箱的平均快取

    = 5400 × 6 MB

    = 32,400 MB

    = 31.6 GB

步驟 2：決定最糟失敗案例情況下每部信箱伺服器虛擬機器的總記憶體需求

在這個步驟中，請參考下表決定建議的記憶體組態。

記憶體需求

伺服器實體記憶體 (RAM) 資料庫快取大小 (僅適用 Mailbox server role)

24 GB

17.6 GB

32 GB

24.4 GB

48 GB

39.2 GB

支援 Mailbox server role 的 31.6 GB 資料庫快取的建議記憶體組態為 48 GB。

Exchange 2010 已測試解決方案

決定每部次要信箱伺服器虛擬機器所需的記憶體

您可以利用下列步驟決定每部次要信箱伺服器虛擬機器所需的記憶體。

步驟 1：決定最糟失敗案例情況下每部伺服器的資料庫快取需求

在上一個步驟中，您決定所有信箱的資料庫快取需求為 190 GB 且每個主動信箱所需的平均快取為 6 MB。

為了針對最糟失敗案例進行設計，您將依據位於次要信箱伺服器虛擬機器上的 2,700 個主動信箱計算所需的資料庫快取：

  • 資料庫快取所需的記憶體 = 主動信箱數目 × 每個信箱的平均快取

    = 2700 × 6 MB

    = 16,200 MB

    = 15.8 GB

步驟 2：決定最糟失敗案例情況下每部信箱伺服器虛擬機器的總記憶體需求

在這個步驟中，請參考下表決定建議的記憶體組態。

記憶體需求

伺服器實體記憶體 (RAM) 資料庫快取大小 (僅適用 Mailbox server role) 資料庫快取大小 (多個伺服器角色，例如 Mailbox server role 和 Hub Transport server role)

24 GB

17.6 GB

14 GB

32 GB

24.4 GB

20 GB

48 GB

39.2 GB

32 GB

支援 Mailbox server role 的 15.8 GB 資料庫快取的建議記憶體組態為 24 GB。

Exchange 2010 已測試解決方案

決定每個 Client Access Server 和 Hub Transport Server 組合所需的記憶體

若要決定 Client Access Server 和 Hub Transport Server 組合虛擬機器的記憶體組態，請參考下表。

根據已安裝之伺服器角色的 Exchange 2010 伺服器記憶體組態

Exchange 2010 伺服器角色 最低支援 建議的最大值

Client Access 及 Hub Transport 組合 server role (在相同實體伺服器上執行的 Client Access server role 及 Hub Transport server role) 的 MHz

4 GB

每個核心 2 GB (最小值 8 GB)

由於 Client Access Server 和 Hub Transport Server 組合虛擬機器擁有三個虛擬處理器，因此會配置 6 GB 記憶體給每部 Client Access Server 和 Hub Transport Server 組合虛擬機器。

Exchange 2010 已測試解決方案

決定每部 Hyper-V 根伺服器所需的記憶體

若要決定每部 Hyper-V 根伺服器所需的記憶體，請使用下列計算：

  • 根伺服器記憶體 = 根作業系統記憶體 + Client Access Server 和 Hub Transport Server 組合虛擬機器記憶體 + 主要信箱伺服器虛擬機器記憶體 + 次要信箱伺服器虛擬機器記憶體

    = 4 GB + 6 GB + 48 GB + 24 GB

    = 82 GB

根伺服器的實體記憶體需求為 82 GB。為了符合建議的實體記憶體組態，伺服器將填入 96 GB。

Exchange 2010 已測試解決方案

設計資料庫可用性群組

在上一個步驟中，您決定解決方案會包含三個 DAG，而且每個 DAG 會跨三個實體位置中的兩個。現在您已決定支援工作負載和 DAG 需求所需的信箱伺服器數目，因此可繼續進行 DAG 設計。

DAG 設計

Exchange 2010 已測試解決方案

設計資料庫副本配置

請使用下列步驟設計資料庫副本配置。

步驟 1：決定 DAG 中的唯一 Exchange 資料庫數目

若要決定要部署的 Exchange 資料庫的最佳數目，請使用 Exchange 2010 Mailbox Server Role 需求計算器。在 [輸入] 索引標籤上輸入適當的資訊，並且針對 [自動計算資料庫/DAG 數目] 選取 [是]。在 [信箱大小限制] 欄位中，使用完整佈建的信箱配額 2,048 MB。

DAG 中的 Exchange 資料庫

在 [角色需求] 索引標籤上，會出現建議的資料庫數目。針對這個解決方案，計算器會建議每個 DAG 最少擁有 24 個唯一資料庫。

*設計決策點*

依照計算器的建議，將會為每個 DAG 部署 24 個資料庫。

步驟 2：決定正常運作情況下的資料庫配置

由於每個 DAG 有 24 個唯一資料庫且 DAG 中有八部伺服器，因此在正常運作情況下，主要站台中四部伺服器之任意一部都會主控六個主動資料庫副本。

請從將主動資料庫副本加入四部伺服器開始，如下表中所示。

正常運作情況下的資料庫配置

Database MBX1 MBX2 MBX3 MBX4

DB1-6

A1

DB7-12

A1

DB13-18

A1

DB19-24

A1

上表會套用下列各項：

  • A1 = 主動資料庫副本

在上一個步驟中，您決定要設計信箱伺服器恢復策略以達到運作效率。信箱伺服器會成對部署。

由於 DAG 中有四部信箱伺服器，因此伺服器 1 和 2 會結合為一對，伺服器 3 和 4 為另一對。在這個步驟中，您會將被動資料庫副本 (P1) 加入至每一對中的替代伺服器，如下表中所示。

正常運作情況下使用被動副本的資料庫配置

Database MBX1 MBX2 MBX3 MBX4

DB1-6

A1

P1

DB7-12

P1

A1

DB13-18

A1

P1

DB19-24

P1

A1

上表會套用下列各項：

  • A1 = 主動資料庫副本

  • P1 = 被動資料庫副本

步驟 3：決定站台中發生伺服器失敗或維護情況時的資料庫配置

發生伺服器失敗或維護事件時，替代伺服器上的 P1 副本便會啟動。下表說明 MBX2 和 MBX4 關閉進行維修時的這種情況。

站台中發生伺服器失敗或維護情況時的資料庫副本配置

上表會套用下列各項：

  • A1 = 主動資料庫副本

  • P1 = 被動資料庫副本

步驟 4：將資料庫副本加入次要資料中心以支援站台恢復

在這個步驟中，將第三個資料庫副本加入次要資料中心內的 DAG 成員中以提供站台恢復，如下表中所示。

加入至次要資料中心以支援站台恢復的資料庫副本

Database SiteA MBX1 SiteA MBX2 SiteA MBX3 SiteA MBX4 SiteB MBX5 SiteB MBX6 SiteB MBX7 SiteB MBX8

DB1-6

A1

P1

P2

DB7-12

P1

A1

P2

DB13-18

A1

P1

P2

DB19-24

P1

A1

P2

上表會套用下列各項：

  • A1 = 主動資料庫副本

  • P1 = 本機被動資料庫副本

  • P2 = 遠端被動資料庫副本

步驟 5：決定站台失敗情況下的資料庫配置

發生主要資料中心失敗的情況時，次要站台中的 P2 副本將會啟動，如下表中所示。請注意，在主要站台恢復上線之前，只會有一個資料庫副本。

站台失敗情況下的資料庫配置

上表會套用下列各項：

  • A1 = 主動資料庫副本

  • P1 = 被動資料庫副本

  • P2 = 被動資料庫副本

Exchange 2010 已測試解決方案

資料中心啟動協調模式

資料中心啟動協調 (DAC) 模式用來控制當發生影響 DAG 的嚴重失敗 (例如其中一個資料中心完全失敗) 時啟動 DAG 的行為。當 DAC 模式未啟用，且發生影響 DAG 中多部伺服器的失敗，在大多數的 DAG 成員在失敗後還原時，DAG 將會重新啟動並嘗試裝載資料庫。在多重資料中心組態中，此行為會引起核心分裂的狀況，在所有網路都失敗時就會發生此狀況，而且 DAG 成員無法接收彼此的活動訊號。當資料中心之間的網路連線中斷時，也會發生核心分裂的狀況。藉由要求大多數 DAG 成員 (如果 DAG 成員的數量為偶數，則為 DAG 見證伺服器) 為可用狀態，且可與要操作的 DAG 互動，可以避免發生核心分裂的狀況。如需相關資訊，請參閱了解資料中心啟動協調模式。

*設計決策點*

環境中的三個 DAG 都會啟用 DAC 模式，以避免發生核心分裂的狀況。

Exchange 2010 已測試解決方案

決定檔案共用見證的位置

在 Exchange 2010 中，DAG 會使用 Windows 容錯移轉叢集中最少的一組元件。其中一個元件是仲裁資源，它提供了判斷叢集狀態和決定成員資格時的仲裁方式。每個 DAG 成員對於如何設定 DAG 基礎叢集擁有一致的觀點非常重要。仲裁是所有與叢集相關之組態資訊的最終存放庫。仲裁也用於突破僵局，以避免發生核心分裂的狀況。核心分裂的狀況是當 DAG 成員間無法相互進行通訊，但各自正常運作時發生的狀況。您可以透過一律要求大部分的 DAG 成員 (如果 DAG 成員的數量為偶數，則為 DAG 見證伺服器) 可以使用，且可與要操作的 DAG 互動，來避免發生核心分裂的狀況。

*「見證伺服器」*是 DAG 之外的裝載檔案共用見證的伺服器，可在 DAG 成員的數量為偶數時，用於達成及維護仲裁。成員數為奇數的 DAG 不使用見證伺服器。建立 DAG 時，預設會將檔案共用見證加入至相同站台中的 Hub Transport Server (未安裝 Mailbox server role) 做為 DAG 的第一個成員。如果您的 Hub Transport Server 執行所在的虛擬機器與執行 Mailbox server role 的虛擬機器位於相同的根伺服器上，建議您將檔案共用見證的位置移到另一部具備高可用性的伺服器上。您可以將檔案共用見證移到網域控制站，但是基於安全性隱憂，請將這個位置當作最後手段。

在 DAG 橫跨多個站台的解決方案中，建議您為次要站台定義替代檔案共用見證。這樣將可讓叢集在啟用 DAC 模式的站台失敗時維護仲裁。

*設計決策點*

由於已決定部署三個 DAG，而且所有 DAG 將包含多個站台的成員，因此需要定義三個主要見證目錄和三個替代見證目錄。這些目錄將位於每個站台內的檔案伺服器上。

Exchange 2010 已測試解決方案

規劃命名空間

規劃 Exchange 2010 組織時，必須做的其中一項最重要決定是如何安排組織的外部命名空間。命名空間是邏輯結構，通常以使用網域名稱系統 (DNS) 的網域名稱表示。您在定義命名空間時，必須考慮用戶端和儲存其信箱的伺服器所在的不同位置。除了用戶端的實體位置之外，您還必須評估它們連線至 Exchange 2010 的方式。這些問題的答案將決定您必須有多少命名空間。命名空間一般都會與 DNS 組態一致。針對具有一個或多個面對網際網路的 Client Access Server 之區域中的每個 Active Directory 站台，建議要有一個唯一的命名空間。這個命名空間通常在 DNS 中以 A 記錄來表示，例如 mail.contoso.com 或 mail.europe.contoso.com。

如需詳細資訊，請參閱瞭解用戶端存取伺服器命名空間。

安排外部命名空間的方式有許多種，但是通常使用下列其中一種命名空間模型就能滿足您的需求：

  • 合併資料中心模型   此模型是由單一實體站台組成。所有伺服器都位於這個站台內，而且有單一命名空間，例如 mail.contoso.com。

  • 單一命名空間及 Proxy 站台   此模型包含多個實體站台。只有一個站台包含網際網路對向的 Client Access Server。其他站台則不會公開至網際網路。在此模型中，站台只會有一個命名空間，例如 mail.contoso.com。

  • 單一命名空間及多個站台   此模型包含多個實體站台。每個站台可以有一部網際網路對向的 Client Access Server。或者，只有一個包含網際網路對向 Client Access Server 的站台。在此模型中，站台只會有一個命名空間，例如 mail.contoso.com。

  • 地區命名空間   此模型包含多個實體站台與多個命名空間。例如，位於紐約市的站台會具有命名空間 mail.usa.contoso.com、位於多倫多的站台會具有命名空間 mail.canada.contoso.com，而位於倫敦的站台則會具有命名空間 mail.europe.contoso.com。

  • 多個樹系   此模型包含具有多個命名空間的多個樹系。使用此模型的組織可能是由兩家協力公司組成，例如 Contoso 和 Fabrikam。命名空間可能包括 mail.usa.contoso.com、mail.europe.contoso.com、mail.asia.fabrikam.com 和 mail.europe.fabrikam.com。

*設計決策點*

這個案例會選取地區命名空間模型，因為它最適合在多個站台擁有主動信箱的組織。

此模型的優點在於減少 Proxy，因為大部分使用者將能夠連線至與其信箱伺服器位於相同 Active Directory 站台中的 Client Access Server。這將可以改善使用者經驗與效能。對於在沒有網際網路對向之 Client Access Server 的站台中具有信箱的使用者，系統仍會對其進行 Proxy 處理。

此解決方案還有下列組態需求：

  • 必須管理多個 DNS 記錄。

  • 必須取得、設定及管理多個憑證。

  • 管理安全性較為複雜，因為每個網際網路對向的站台都需要 Microsoft Forefront Threat Management Gateway 電腦或其他反向 Proxy 或防火牆解決方案。

  • 使用者必須連線到自己的地區命名空間。這樣可能會造成需要額外的支援服務諮詢與訓練。

Exchange 2010 已測試解決方案

決定 Client Access Server 陣列和負載平衡策略

在 Exchange 2010 中，Client Access server role 中引進了 RPC 用戶端存取服務和 Exchange 通訊錄服務，以便改善主動信箱資料庫副本移至另一部信箱伺服器時的信箱使用者體驗 (例如，在信箱資料庫失敗或維護事件時)。Microsoft Outlook 和其他 MAPI 用戶端的信箱存取連線端點已從 Mailbox server role 移至 Client Access server role。因此，現在站台中所有 Client Access Server 上的內部和外部 Outlook 連線都必須達到負載平衡，以達成容錯。若要將 MAPI 端點與 Client Access Server 群組而不是特定 Client Access Server 產生關聯，您可以定義 Client Access Server 陣列。每個 Active Directory 站台只能設定一個陣列，而且一個陣列無法跨越多個 Active Directory 站台。如需詳細資訊，請參閱瞭解 RPC Client Access及Understanding Load Balancing in Exchange。

*設計決策點*

由於這是一個三個站台的部署，每個站台中有四部執行 Client Access server role 的伺服器，因此總共會有三個 Client Access Server 陣列。硬體負載平衡解決方案將在各站台中用來跨 Client Access Server 陣列分配負載。

Exchange 2010 已測試解決方案

決定硬體負載平衡模型

使用下列步驟來決定硬體負載平衡模型。

步驟 1：確定慣用的硬體負載平衡廠商

此例中慣用的廠商為 Cisco，因為已針對此解決方案的伺服器、網路及儲存連線元件選取 Cisco Application Control Engine (ACE) 產品線搭配使用 Cisco Unified Computing System。

Cisco ACE 產品線提供高可用性且可擴充的資料中心解決方案，可讓 Exchange 2010 應用程式環境從中獲益。Cisco ACE 產品提供互通性，具有以下優勢：

  • 效能、延展性、輸送量及應用程式可用性

  • 以標準為基礎的設計

  • 具有裝置資料分割的虛擬架構

  • 以角色為基礎的管理與集中式管理

  • 安全性服務，採用深度封包檢查、存取控制清單 (ACL)、單點傳播反向路徑轉送，以及網路位址轉譯 (NAT)/連接埠位址轉譯

步驟 2：檢閱偏好廠商提供的可用選項

Cisco ACE 產品線包含兩種不同的硬體負載平衡模型，符合高可用性及可延展的資料中心解決方案需求，適用於 Exchange 2010 應用程式環境。這些產品為 Cisco ACE 4710 裝置與 Cisco Catalyst 6500/Cisco 7600 路由平台中的整合式服務模組。

Cisco ACE 4710 裝置在單一機架裝置 (1RU) 外觀尺寸中提供高達 4 Gbps 的輸送量，可透過軟體授權升級，保護長期投資並具有延展性。在該基礎上，4710 採用 1U 機架式機殼，其中內含 Cavium Nitrox Octeon 加速卡，提供 4 個 GB 乙太網路連接埠，可搭配使用 Cisco EtherChannel 並連接到交換器上。根據預設，Cisco ACE 4710 支援使用一個系統管理員裝置及四個使用者裝置進行虛擬，具有 1-Gbps 頻寬、每秒 1,000 次安全通訊端層 (SSL) 交易，以及每秒 100 MB (Mbps) 的壓縮能力。此解決方案可透過下列軟體授權升級，不需新的設備即可進行擴充：

  • 輸送量可將預設的 1 Gbps 輸送量提升至 2 或 4 Gbps。

  • 虛擬裝置可將虛擬裝置的數目從 5 個虛擬裝置增加到 20 個虛擬裝置。

  • 每秒 SSL 交易次數可將每秒 SSL 交易次數值從 1,000 增加到 5,000 或 7,500。

  • 壓縮可將壓縮增加到輸送量的 500 Mbps 或 1 或 2 Gbps。

  • 以角色為基礎的存取控制可經由 Application Network Manager GUI 或命令列介面 (CLI) 提供以角色以為基礎的集中式管理。

  • 高可用性支援備援組態 (內部裝置和不同內容)。

Cisco Catalyst 6500 Series Switches 或 Cisco 7600 Series Routers 的 Cisco ACE 模組在一個插槽模組的外觀尺寸 (如 ACE 4710 裝置) 中提供高達 16 Gbps 的輸送量，可透過軟體授權進行升級。在單一 Cisco Catalyst 6500 Series Switch 或 Cisco 7600 Series Router 中最多可安裝四個 Cisco ACE 模組。每個模組可支援多個業務流程，獨立的業務單位可以使用供交換器或路由器使用的許多連線選項。系統管理員可判斷應用程式需求並指派適當的網路服務做為虛擬內容。每個內容包含自己的一組原則、介面、資源及管理員：

  • 輸送量負載平衡服務提供最高 16 Gbps 的輸送量，以及每秒 345,000 個第 4 層連線。

  • 虛擬裝置可將虛擬裝置的數目從 5 個增加到 250 個。

  • 每秒 SSL 交易次數可透過授權增加每秒 SSL 交易次數，在 ACE20 模組上可增加到 15,000 個 SSL 工作階段，在 ACE30 模組上可增加到 30,000 個 SSL 工作階段。

  • 壓縮可在 ACE30 模組上將壓縮增加到 6 Gbps。

  • 以角色為基礎的存取控制可經由 Application Network Manager GUI 或 CLI 提供以角色為基礎的集中式管理。

  • 高可用性支援備援組態 (機殼內部、不同機殼，以及不同內容)。

步驟 3：選取硬體負載平衡模型

已選取 Cisco ACE 4710 裝置，因為該裝置提供最佳的應用程式可用性、完整的應用程式安全性、虛擬化架構，以及投資價值與保護。

  • 最佳的應用程式可用性Cisco ACE 4710 有助於確保運作持續性，並透過具有高度擴充性的第 4 層負載平衡及第 7 層內容切換來為使用者提供服務，如此也可將應用程式或裝置失敗的影響降至最低。

  • 完整的應用程式安全性Cisco ACE 4710 可扮演伺服器防禦的最後一道防線，針對應用程式執行緒及拒絕服務的攻擊 (DoS) 提供保護，並具有如深度封包檢查、網路及通訊協定安全性，以及具有高度擴充性的存取控制能力等功能。

  • 虛擬化架構虛擬化架構是 Cisco ACE 的一項主要設計元素，相對於市場上的其他解決方案，其具有獨特的銷售主張。IT 管理員最多可在單一 Cisco ACE 4710 裝置上設定 20 個虛擬裝置。這麼做的好處是，不會因為應用程式部署的增加而管理較多的裝置，可大幅降低電力及冷卻的費用，以及針對新應用程式提供更快的服務時間。

Exchange 2010 已測試解決方案

決定儲存設計

設計良好的儲存解決方案是成功部署 Exchange 2010 Mailbox server role 的關鍵部分。如需詳細資訊，請參閱信箱伺服器儲存設計。

步驟 1：摘要說明儲存需求

下表摘要說明上一個設計步驟中計算及決定的儲存需求。

磁碟空間需求摘要

磁碟空間需求 值

2 GB 信箱在磁碟上的信箱大小 (MB)

2301

需要的資料庫總容量 (GB)

120128

需要的記錄總容量 (GB)

3974

所需總容量 (GB)

124102

三個資料庫副本所需的總容量 (GB)

372306

三個資料庫副本所需的總容量 (TB)

364

每個站台所需的總容量 (TB)

122

步驟 2：決定要使用虛擬或精簡佈建

許多客戶在移至 Exchange 2010 後都希望能大幅增加信箱配額。不過，信箱的大小需要一些時間才能從幾百個 MB 成長到 GB 的大小。在這種情況下，試圖將購買其他儲存裝置的時間推遲到將來的某個時間點，對某些組織而言是有利的，因為屆時磁碟儲存空間可能會更便宜。

許多儲存廠商提供某些類型的精簡佈建解決方案，使您可以提供比實際可用更多的儲存容量給 Exchange 伺服器，然後再動態增加實際的儲存，以滿足日益增加的需求，同時又不需讓伺服器中斷或停機。其藉由減少儲存容量的初始配置，以及降低支援成長所需的步驟來減化管理，使 TCO 降低。

精簡佈建的 EMC 整合儲存實作是由其虛擬佈建功能所提供，其支援熱運轉、主動式運轉、不具干擾性的精簡集區擴充，以及在精簡 LUN 及傳統的複雜 LUN 之間遷移而不需要停機的能力。此種彈性可將 EMC 整合儲存虛擬佈建與典型的精簡佈建實作分隔開來。

*設計決策點*

目前 Exchange 實作定義的信箱配額為 200 MB。在移至 Exchange 2010 後，信箱大小在前 12 到 18 個月內預計大約會成長 300%。其計劃是要購買足夠的儲存以容納 600 MB 的平均信箱大小。在 Exchange 2010 實作期間，平均信箱大小預計會接近 2 GB。由於 2 GB 信箱配額的費用很昂貴，因此會實作精簡佈建，此時可以部署 600 MB 的初始信箱配額。基礎的實體儲存將在日後的預算週期中擴增，以符合預期的需求。

步驟 3：決定記錄和資料庫是否要同時存在於相同的 LUN 上

在 Exchange 2010 部署的 EMC 整合儲存上使用精簡佈建時，最好的作法是將記錄檔與資料庫檔案分開存放。如果預期會成長的是信箱大小，而不是郵件設定檔 (傳送的郵件/每天接收的郵件)，您將需要逐步增加資料庫 LUN，而非記錄 LUN。這種情形下便不適合將記錄放在精簡佈建的 LUN 上。

將資料庫和記錄 LUN 分開存放時，也可以選擇將它們放在不同的磁碟類型或使用不同等級的 RAID。

*設計決策點*

依照 EMC 最佳作法，資料庫和記錄將存放在不同的 LUN 上。由於郵件設定檔預期在未來三年內將保持相對穩定的狀況，因此將記錄檔放在精簡佈建的 LUN 上並沒有任何好處。

步驟 4：決定每個 LUN 的資料庫數目

由於 VSS 式的備份和還原是在 LUN 層級上操作，因此每個 LUN 的資料庫數目通常是由備份策略所決定。在上一個步驟中已決定不將 VSS 式備份包含在資料庫恢復策略中。因此在決定每個 LUN 的資料庫數目時，必須考慮其他因素。最佳作法通常應該是為每個 LUN 部署單一資料庫。每個 LUN 擁有多個資料庫可能會導致下列情形：

  • 負載過重的資料庫，影響到正常的資料庫

  • 某個資料庫上的植入作業影響到正常的資料庫

  • 被動資料庫 I/O 影響到主動資料庫

*設計決策點*

由於沒有在每個 LUN 上部署多個資料庫的需求，因此會根據每個 LUN 上採用單一資料庫的模型進行儲存設計。

步驟 5：決定主要資料中心信箱伺服器的每部伺服器 LUN 數目

在上一個步驟中，您已確定每部主要信箱伺服器皆支援六個主動資料庫，以及六個被動資料庫。每部主要資料中心信箱伺服器總共會有 24 個 LUN，如下表所示。

每部郵件伺服器所需的 LUN 數目

LUN 類型 每部伺服器的 LUN

主動資料庫的 LUN

6

作用中記錄的 LUN

6

被動資料庫的 LUN

6

被動記錄的 LUN

6

LUN 總計

24

步驟 6：決定次要資料中心郵件伺服器的每部伺服器 LUN 數目

在上一個步驟中，您已確定每部次要信箱伺服器可支援六個被動資料庫。每部次要資料中心信箱伺服器總共會有 12 個 LUN，如下表所示。

每部郵件伺服器所需的 LUN 數目

LUN 類型 每部伺服器的 LUN

被動資料庫的 LUN

6

被動記錄的 LUN

6

LUN 總計

12

步驟 7：定義儲存建置組塊

為了簡化其餘的儲存設計步驟，採用建置組塊方法。在此解決方案中，每個資料庫支援 450 個使用中信箱。每部信箱伺服器在 6 個資料庫 LUN 和 6 個記錄 LUN 上支援 6 個資料庫或 2,700 個使用中信箱，因此將使用支援 2,700 個信箱增量的 12 個 LUN 建置組塊。

步驟 8：決定建置組塊的 IOPS 需求

在此步驟中將計算支援建置組塊中 2,700 個使用中信箱使用者所需的交易式 IOPS。在隨後的步驟中，您將會根據初始和完整佈建的信箱配額，使用 IOPS 需求來決定部署建置組塊的最小和最大磁針數。使用下列計算：

  • 建置組塊的 IOPS 所需的總交易數 = 每個信箱使用者的 IOPS × 信箱數目 × I/O 負荷係數

    = 0.10 × 2700 × 20%

    = 324 IOPS

步驟 9：決定磁碟上的初始信箱大小

在上一個步驟中，您計算了 2,048-MB 信箱配額限制在磁碟上的信箱大小為 2,301 MB。由於將使用精簡佈建，因此才要計算磁碟上的初始信箱大小。這個值將在稍後的步驟中用來決定初始容量需求。

下列計算會根據 600-MB 的信箱配額為此解決方案決定磁碟上的初始信箱大小。

  • 空白字元 = 每天 100 封郵件 × 75 ÷ 1024 MB = 7.3 MB

  • 暫放 = (每天 100 封郵件 x 75 ÷ 1024 MB × 14 天) + (600 MB x 0.012) + (600 MB x 0.058) = 144.2 MB

  • 磁碟上的信箱大小 = 信箱限制 + 空白字元 + 暫放

    = 600 MB + 7.3 MB + 144.2 MB

    = 752 MB

步驟 10：決定建置組塊的初始資料庫容量需求

若要決定 2,700 個信箱所需的初始儲存容量與 600 MB 的初始信箱配額，請使用下列計算：

  • 資料庫檔案容量 = (信箱數目 × 磁碟上的信箱大小 × 資料庫負荷增長因數) + (20% 資料負荷)

    = (2700 × 752 × 1) + (406080)

    = 2,436,480 MB

    = 2,379 GB

  • 資料庫目錄容量 = 資料庫檔容量的 10%

    = 238 GB

  • 資料庫總容量 = (資料庫檔案大小) + (索引大小) ÷ 0.80 以提供 20% 的磁碟區可用空間

    = (2379 + 238) ÷ 0.8

    = 3,271 GB

建置組塊中的六個資料庫需要 3,271 GB 的初始儲存容量。

步驟 11：決定建置組塊的完全佈建資料庫容量需求

若要決定 2,700 個信箱所需的完全佈建儲存容量與 2,048 MB 的信箱配額，請使用下列計算：

  • 資料庫檔案容量 = (信箱數目 × 磁碟上的信箱大小 × 資料庫負荷增長因數) + (20% 資料負荷)

    = (2700 × 2301 × 1) + (1242540)

    = 7,455,240 MB

    = 7,281 GB

  • 資料庫目錄容量 = 資料庫檔容量的 10%

    = 728 GB

  • 資料庫總容量 = (資料庫檔案大小) + (索引大小) ÷ 0.80 以提供 20% 的磁碟區可用空間

    = (7281 + 728) ÷ 0.8

    = 10,011 GB

建置組塊中的六個資料庫需要 10,011 GB 的完全佈建儲存容量。

步驟 12：決定建置組塊的記錄容量需求

若要決定建置組塊中 2,700 個信箱所需的記錄儲存容量，請使用下列計算：

  • 需要的建置組塊記錄容量 = 信箱使用者數目 × 每個信箱每天的記錄數目 × 記錄大小 × (更換失敗的基礎結構所需的天數) + (信箱移動的額外百分比)

    = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

    = 216,054 MB

    = 211 GB

  • 記錄總容量 = 記錄容量 ÷ 0.80 以提供 20% 的磁碟區可用空間

    = 211 ÷ 0.80

    = 264

建置組塊中的六組記錄需要 264 GB 的儲存容量。

注意事項附註：
由於並不會對記錄磁碟區進行精簡佈建，因此計算的儲存容量表示完全佈建環境的記錄容量需求。

步驟 13：決定支援建置組塊之 IOPS 需求所需的磁針數目

此步驟將決定支援 IOPS 需求所需的磁針數目。在下一個步驟中，您將會決定符合容量需求的磁針計數。

在上一個步驟中已確定支援 2,700 個信箱建置組塊所需的 IOPS 為 324。在此步驟中，將使用下列計算來計算符合 IOPS 需求所需的磁碟數目：

  • 磁碟計數 = (使用者 IOPS × 讀取比率) + 寫入效能下降 × (使用者 IOPS × 寫入比率) ÷ 所選磁碟類型的 IOPS 功能

    = (324 × 0.6) + 4 × (324 × 0.4) ÷ 155

    = 4.6

使用 RAID-5 組態中的五個磁碟即可滿足 IOPS 需求。

注意事項附註：
這些計算僅適用於此 EMC 解決方案。如需所選儲存解決方案的磁針需求的指導，請洽詢您的儲存廠商。

步驟 14：決定支援建置組塊之初始資料庫容量需求所需的磁針數目

在上一個步驟中，您已確定 2,700 個信箱建置組塊的 600 MB 初始佈建信箱需要 3,271 GB 的儲存容量。在 CX4 Model 480 上 RAID-5 組態中，每個 450 GB 磁針的可用容量大約為 402 GB。若要確定所需的磁碟數目，請使用下列計算：

  • 磁碟計數 = (所需的總容量) ÷ (採用 RAID-5 的每個磁針可用容量)

    = 3271 GB ÷ 402 GB

    = 8.1

使用九個磁碟即可符合初始資料庫容量需求。

在使用精簡佈建的 EMC 整合儲存上部署儲存的 EMC 最佳作法是設定以五個磁碟為倍數的 RAID-5 精簡集區。為 2,700 個信箱的建置組塊配置 10 個磁碟，以提供因應未來成長的空餘空間。

步驟 15：決定支援建置組塊之完全佈建資料庫容量需求所需的磁針數目

在上一個步驟中，您已確定 2,700 個信箱建置組塊的 2,048 MB 初始佈建信箱需要 10,011 GB 的儲存容量。在 CX4 Model 480 上 RAID-5 組態中，每個 450 GB 磁針的可用容量大約為 402 GB。若要確定所需的磁碟數目，請使用下列計算：

  • 磁碟計數 = (所需的總容量) ÷ (採用 RAID-5 的每個磁針可用容量)

    = 10011 GB ÷ 402 GB

    = 24.9

使用 25 個磁碟可以符合完全佈建資料庫容量需求。

步驟 16：決定支援建置組塊之記錄容量需求所需的磁針數目

在上一個步驟中，您已確定 2,700 個信箱建置組塊需要 264 GB 的記錄儲存容量。在 CX4-480 上使用 RAID-1/0 組態的兩個 450 GB 磁碟機可提供 402 GB 的可用儲存容量。建議的兩個磁碟組態符合 2,700 個信箱建置組塊的記錄容量需求。

步驟 17：決定精簡集區策略

現在我們已確定支援 IOPS 所需的磁針數目，以及建置組塊的容量需求，您需要決定當使用虛擬或精簡佈建時，在建置組塊的陣列上佈建 LUN 的最佳方式。

設計用於 Exchange 的精簡集區時，可以使用三種主要模型：

  • 單一儲存集區使用一個大型儲存集區供所有 Exchange 資料庫和記錄使用是最簡單的方法，而且可提供最佳的空間使用率。不過，當相同資料庫的多個副本位於相同實體陣列時，不建議使用單一精簡集區。

  • 每部伺服器使用一個儲存集區每部 Exchange 信箱伺服器使用一個儲存集區可在安排陣列上的 LUN 時提供更大的精細度。如果設計正確，就會將資料庫副本與磁針組隔離，可盡量減少如植入/重新植入、備份及線上維護 (背景資料庫維護) 等活動期間的磁碟爭用問題。不過，根據您所擁有的信箱伺服器數目，此模型可能需要使用多個精簡集區，因而造成管理上的困難。

  • 每個資料庫副本使用一個儲存集區每個資料庫副本使用一個儲存集區可確保每個副本會隔離在陣列上的不同磁針組上。由於大多數組織會部署二個到四個資料庫副本，因此精簡集區的數目會保持在可管理的數量上。在此模型中，多部信箱伺服器在相同精簡集區中擁有資料庫 LUN。這對於在信箱伺服器上執行如植入/重新植入、備份及線上維護 (背景資料庫維護) 等會影響其他信箱伺服器效能的活動而言是一個機會。

*設計決策點*

儘管每部伺服器使用一個儲存集區模型的優點非常吸引人，但此模型需要在每個站台中使用八個精簡集區，總共是 24 個精簡集區。為了簡單起見，將採用每個資料庫副本使用一個儲存集區模型，該模型需要在每個站台中使用三個精簡集區，並保證每個資料庫副本皆位於不同的磁針組上。此模型也可確保在發生需要新增其他儲存來因應成長的任何事件時，維護資料庫副本磁針的隔離性。

步驟 18：決定每個精簡集區的初始磁針數目

第一個精簡集區將內含 2,700 個信箱建置組塊，這些建置組塊來自站台中的四個主要資料中心信箱伺服器。在上一個步驟中已確定需要使用 10 個磁針來支援建置組塊的 IOPS 和容量需求。支援 10,800 個主動式信箱的第一個精簡集區將需要 40 個磁針。

第二個精簡集區也內含 2,700 個信箱建置組塊，這些建置組塊來自站台中的四個主要資料中心信箱伺服器。支援 10,800 個被動式信箱的第二個精簡集區將需要 40 個磁針。

第三個精簡集區也內含 2,700 個信箱建置組塊，這些建置組塊來自站台中的四個次要資料中心信箱伺服器 (這些伺服器是來自支援站台恢復資料副本的替代 DAG)。支援 10,800 個被動式信箱的第三個精簡集區將需要 40 個磁針。

每個站台共需要 120 個磁針，以支援初始資料庫容量需求。

步驟 19：決定每個精簡集區的完全佈建磁針數目

第一個精簡集區將內含 2,700 個信箱建置組塊，這些建置組塊來自站台中的四個主要資料中心信箱伺服器。在上一個步驟中已確定需要使用 25 個磁針以支援建置組塊的 IOPS 和完全佈建容量需求。支援 10,800 個主動式信箱的第一個精簡集區將需要 100 個磁針。

第二個精簡集區也內含 2,700 個信箱建置組塊，這些建置組塊來自站台中的四個主要資料中心信箱伺服器。支援 10,800 個被動式信箱的第二個精簡集區將需要 100 個磁針。

第三個精簡集區也內含 2,700 個信箱建置組塊，這些建置組塊來自站台中的四個次要資料中心信箱伺服器 (這些伺服器是來自支援站台恢復資料副本的替代 DAG)。支援 10,800 個被動式信箱的第三個精簡集區將需要 100 個磁針。

每個站台共需要 300 個磁針，以支援完全佈建資料庫容量需求。

步驟 20：決定支援所有記錄 LUN 所需的磁針數目

在上一個步驟中已確定每個內含 2,700 個信箱的建置組塊需要兩個磁針以支援記錄 LUN 需求。

主要資料中心信箱伺服器上共有四個支援主動式信箱資料庫的建置組塊。支援 10,800 個主動式信箱的記錄 LUN 需要八個磁針。

主要資料中心信箱伺服器上共有四個支援被動式信箱資料庫的建置組塊。支援 10,800 個被動式信箱的記錄 LUN 需要八個磁針。

次要資料中心信箱伺服器上共有四個支援被動式信箱資料庫的建置組塊。支援 10,800 個被動式信箱的記錄 LUN 需要八個磁針。

若要在單一站台中支援記錄 LUN 需求，則需要 24 個磁針。

步驟 21：驗證儲存陣列可支援的初始所需磁針計數

在此步驟中將使用下列計算驗證所選儲存陣列是否可支援所需的總磁針計數：

  • 每個站台所需的磁針總數 = 資料庫 LUN 所需的磁針數 + 記錄 LUN 所需的磁針數

    = 120 + 24

    = 144

一部配備 10 個磁碟陣列的 CX4-480 內含 150 個磁針，符合需求。

步驟 22：決定支援完全佈建環境所需的磁針數目

此步驟中將使用下列計算來計算支援完整佈建環境所需的磁針總數：

  • 每個站台所需的磁針總數 = 資料庫 LUN 所需的磁針數 + 記錄 LUN 所需的磁針數

    = 300 + 24

    = 324

一部配備有 22 個磁碟陣列設備的 CX4-480 內含 330 個磁針，符合需求。

Exchange 2010 已測試解決方案

解決方案概觀

上一節為您提供了在考慮採用 Exchange 2010 解決方案時做出設計決策的相關資訊。下一節將提供解決方案的概觀。

Exchange 2010 已測試解決方案

邏輯解決方案圖

此解決方案總共由 36 部以多網站拓撲方式部署的 Exchange 2010 伺服器組成。36 部伺服器中有 12 部伺服器同時執行 Client Access server role 和 Hub Transport server role。其他 24 部伺服器執行 Mailbox server role。每個站台中有一個 Client Access Server 陣列，其中內含四個 Client Access Server 和 Hub Transport Server 組合。共有三個 DAG，每個都內含 8 部信箱伺服器。每個站台中的檔案伺服器主控每個 DAG 的主要和替代檔案共用見證伺服器。

邏輯解決方案圖

Exchange 2010 已測試解決方案

實體解決方案圖

三個站台皆內含四部 Cisco B200 Blade Server，經由備援 Cisco Fabric Interconnect 6120 和 Cisco MDS 9134 交換器與 EMC CLARiiON CX4 Model 480 儲存陣列連接。備援 Cisco Nexus 5010 Ethernet 交換器提供了基礎的網路基礎結構。用戶端流量可經由備援 Cisco ACE 4710 負載平衡裝置在每個站台的 Client Access Server 陣列間進行負載平衡。

實體解決方案圖

Exchange 2010 已測試解決方案

Hyper-V 根伺服器組態摘要

下表摘要說明此解決方案中使用的實體伺服器硬體。

Cisco Unified Computing System (整合運算系統) 摘要

項目 描述

Blade Server

4 × B200 M1

處理器

2 × Intel Zeon x5570 (2.93 GHz)

記憶體

96 GB RAM (12 × 8 GB DIMM）

整合式網路介面卡

M71KR-Q (2 × 10 GB 乙太網路和 2 × 4 Gbps 光纖通道)

內部 Blade 儲存

2 × 146 GB SAS 10,000 RPM 磁碟 (RAID-1)

機殼

5108 (6RU)

Fabric Extender (光纖通道擴充模組)

2 × 2104XP

光纖互連

2 × 6120XP

光纖互連擴充模組

2 × 8 埠 4 Gbps 光纖通道

下表摘要說明此解決方案中使用的儲存和網路硬體。

LAN 和 SAN 交換器

項目 描述

10 GB 乙太網路 (GbE) 交換器

2 × Nexus 5010 (8 個固定式 1 GbE/10 GbE 連接埠，12 個固定式 10 GbE 連接埠，資料中心橋接)

光纖通道交換器

2 × MDS 9134 (32 個固定式 4 Gbps 連接埠)

下表提供此解決方案中使用的軟體相關資訊。

解決方案的軟體摘要

項目 描述

Hypervisor 主機伺服器

Windows Server 2008 R2 Hyper-V Enterprise

Exchange Server VM

Windows Server 2008 R2 Enterprise

Exchange Server 2010 Mailbox server role

Enterprise Edition RU2

Exchange Server 2010 Hub Transport 和 Client Access server role

Standard Edition RU2

多重路徑和 I/O 平衡

EMC PowerPath

Exchange 2010 已測試解決方案

Client Access 和 Hub Transport Server 組態

下表摘要說明此解決方案中使用的 Client Access 和 Hub Transport Server 組合的組態。

Client Access 和 Hub Transport Server 組態

元件 值或描述

實體或虛擬

Hyper-V VM

虛擬處理器

3

記憶體

8 GB

儲存裝置

根伺服器作業系統磁碟區上的虛擬硬碟

作業系統

Windows Server 2008 R2

Exchange 版本

Exchange Server 2010 Standard Edition

Exchange 更新層級

Exchange 2010 更新彙總套件 2

協力廠商軟體

無

Exchange 2010 已測試解決方案

信箱伺服器組態

下表摘要說明此解決方案中使用的主要信箱伺服器 (主控 DAG 之主要站台中的主要和次要資料庫副本) 組態。

主要信箱伺服器組態

元件 值或描述

實體或虛擬

Hyper-V VM

虛擬處理器

4

記憶體

53 GB

儲存裝置

根伺服器作業系統磁碟區上的虛擬硬碟
   

作業系統

Windows Server 2008 R2

Exchange 版本

Exchange Server 2010 Enterprise Edition

Exchange 更新層級

Exchange 2010 更新彙總套件 2

協力廠商軟體

無

下表摘要說明此解決方案中使用的次要信箱伺服器 (主控 DAG 之次要站台中的第三資料庫副本) 組態。

次要信箱伺服器組態

元件 值或描述

實體或虛擬

Hyper-V VM

虛擬處理器

2

記憶體

24 GB

儲存裝置

根伺服器作業系統磁碟區上的虛擬硬碟

作業系統

Windows Server 2008 R2

Exchange 版本

Exchange Server 2010 Enterprise Edition

Exchange 更新層級

Exchange 2010 更新彙總套件 2

協力廠商軟體

無

Exchange 2010 已測試解決方案

資料庫配置

下圖摘要說明此解決方案在一般作業情況下使用的資料庫副本配置。

資料庫副本配置：1

資料庫副本配置：2

資料庫副本配置：3

Exchange 2010 已測試解決方案

儲存硬體摘要

下表提供此解決方案中使用的儲存硬體相關資訊。

EMC Unified Storage NS-480 (整合 CLARiiON CX4-480)

項目 描述

儲存裝置

3 CLARiiON CX4-480 (每個站台 1 個)

儲存連線 (光纖通道、SAS、SATA、iSCSI)

光纖通道

儲存快取

32 GB (每個儲存連接埠具有 600 MB 的讀取快取和 10,160 MB 的寫入快取)

儲存控制器數目

每個儲存框架 2 個

可用或使用的儲存連接埠數目

每個儲存框架可用 8 個 (每個儲存連接埠 4 個)，使用 4 個 (每個儲存連接埠 2 個)

儲存與主機連線的最大頻寬

8 × 4 Gbps

解決方案中測試的磁碟總數

432 (360 為資料庫，72 為跨 3 個站台的記錄)

可以在儲存區中主控的磁針數目上限

單一儲存陣列中為 480 個

Exchange 2010 已測試解決方案

儲存組態

解決方案中使用的每個 CX4 Model 480 儲存陣列皆已設定為如下表所示的內容。

儲存組態

元件 值或描述

總儲存設備

3

每個站台的總儲存設備

1

每個設備的磁碟總數

150

每個設備的總儲存集區

3

每個儲存集區 (初始) 的磁碟總數

40

每個資料庫 LUN (初始) 的磁碟總數

10

每個記錄 LUN 的磁碟總數

2

每個設備使用的磁碟總數

144

資料庫的 LUN 大小 (初始)

4,020 GB

記錄的 LUN 大小

402 GB

資料庫的 RAID 等級

5

記錄的 RAID 等級

1/0

下表說明設計可用儲存的方式，以及三個 CX4 Model 480 儲存系統間的配置方式。

CX4 Model 480 儲存系統間的儲存組態

資料中心 DAG Database 陣列 1 陣列 2 陣列 3

1

1

DB1-24

C1、C2

C3

2

2

DB25-48

C3

C1、C2

3

3

DB49-72

C3

C1、C2

Exchange 2010 已測試解決方案

解決方案驗證方法

在實際執行環境中部署 Exchange 解決方案之前，請先驗證解決方案的設計、大小及設定是否正確。此項驗證必須包含確保系統正常運作的功能測試，以及確保系統可以處理所需的使用者負載的效能測試。本節說明用來驗證此解決方案的伺服器與儲存設計的方式與測試方法。其中會詳細定義下列各項測試：

  • 效能測試

    • 儲存效能驗證 (Jetstress)

    • 伺服器效能驗證 (Loadgen)

  • 功能測試

    • 資料庫轉換驗證

    • 伺服器轉換驗證

    • 伺服器容錯移轉驗證

    • 資料中心轉換驗證

Exchange 2010 已測試解決方案

儲存設計驗證方法

與 Exchange Mailbox server role 連接之儲存子系統的效能和可靠性層級對於 Exchange 部署的整體健康情況有重大的影響。此外，儲存效能不佳將會導致嚴重的交易延遲，主要會在存取 Exchange 系統時反映出用戶端體驗不佳的現象。若要確保最佳的用戶端體驗，請使用本節中所述的方法驗證儲存大小及組態。

工具集

若要驗證 Exchange 儲存大小和組態，建議您使用 Microsoft Exchange Server Jetstress 工具進行。Jetstress 工具的設計目的是透過直接與 ESE 進行互動，在資料庫層級模擬 Exchange I/O 工作負載。ESE 是一種資料庫技術，Exchange 使用它在 Mailbox server role 上儲存郵件資料。您可以設定 Jetstress，使其測試在 Exchange 的所需效能限制內可用於儲存子系統的最大 I/O 輸送量。Jetstress 也可接受使用者數與每一使用者 IOPS 的目標設定檔，並驗證儲存子系統能以此目標設定檔維持可接受的效能等級。測試期間是可調整的，可以執行一小段時間以驗證效能是否足夠，或執行較長的一段時間以驗證儲存子系統的可靠性。

Jetstress 工具可以從 Microsoft 下載中心取得，網址如下：

Jetstress 安裝程式隨附的文件說明如何在您的伺服器硬體上設定及執行 Jetstress 驗證測試。

儲存驗證方法

儲存組態共分為下列兩種主要類型：

  • DAS 或內部磁碟案例

  • SAN 案例

在 DAS 或內部磁碟案例中，只有一部伺服器會存取磁碟子系統，因此可以單獨驗證儲存子系統的效能。

在 SAN 案例中，解決方案所使用的儲存可能會與許多伺服器共用，而連接伺服器與儲存的基礎結構可能也具有共用相依性。這需要進一步的測試，必須對共用基礎結構上其他伺服器的影響進行充分的模擬，以驗證效能和功能。

儲存驗證測試案例

針對解決方案執行下列儲存驗證測試案例，並應考慮將其做為儲存驗證的起始點。特定的部署可能會有其他驗證需求以滿足額外的測試，所以此清單可能會有遺漏的項目：

  • 驗證最糟情況的資料庫轉換案例 在此測試案例中，預期將會由儲存子系統在最糟情況的轉換案例 (最少的伺服器上有最多數目的主動副本) 下為 I/O 層級提供服務。根據儲存子系統為 DAS 或 SAN，此項測試可能需要在多部主機上執行，以確保儲存子系統上的端對端解決方案負載能夠持續運作。

  • 驗證儲存失敗和復原案例 (例如，失敗的磁碟更換和重建) 下的儲存效能 此測試案例中會評估儲存子系統在失敗和重建案例期間的效能，以確保可以將效能維持在最佳化 Exchange 用戶端體驗所需的層級。針對 DAS 與 SAN 部署應注意的相同部分：如果有多部主機依存於共用的儲存子系統，則必須在測試中包含這些主機的負載，以模擬失敗和重建的完整效果。

分析結果

每項測試完成後，Jetstress 工具會產生一個報告檔。為了協助您分析報告，請使用 Jetstress 2010 Test Summary Reports中的指導方針進行。

具體來說，當您在報告的「測試結果」表中檢查資料時，應該依照下表中的指導方針進行。

Jetstress 結果分析

效能計數器執行個體 效能測試指導方針

I/O Database Reads Average Latency (msec)

平均值應低於 20 毫秒 (msec) (0.020 秒)，最大值應低於 50 毫秒。

I/O Log Writes Average Latency (msec)

記錄磁碟是以循序方式寫入，因此平均寫入延遲應低於 10 毫秒，最大寫入延遲則不超過 50 毫秒。

% Processor Time

平均應低於 80%，最大應低於 90%。

Transition Pages Repurposed/sec (Windows Server 2003、Windows Server 2008、Windows Server 2008 R2)

平均應該低於 100。

報告檔中會顯示 Exchange 系統所執行的各種 I/O 類別：

  • 交易式 I/O 效能 此表報告的 I/O 表示使用者對資料庫的活動 (例如，Outlook 產生的 I/O)。此資料是由測試期間測量到的總 I/O 減去背景維護 I/O 和記錄複寫 I/O 而產生。此資料提供實際產生的資料庫 IOPS 以及所需的 I/O 延遲測量，以判斷 Jetstress 效能測試是通過還是失敗。

  • 背景資料庫維護 I/O 效能 此表報告因為進行中 ESE 資料庫背景維護而產生的 I/O。

  • 記錄複寫 I/O 效能 此表報告從模擬的記錄複寫產生的 I/O。

  • 總 I/O 效能 此表報告 Jetstress 測試期間產生的總 I/O。

Exchange 2010 已測試解決方案

伺服器設計驗證

驗證儲存子系統的效能和可靠性之後，請確定已一併驗證郵件系統中所有元件的功能、效能和延展性。這表示要往上移動一個層次，驗證用戶端軟體與 Exchange 產品的互動，以及與 Exchange 互動的任何伺服器端產品。若要確保端對端的用戶端體驗是可以接受的，同時整個解決方案又可以維持所需的使用者負載，則可以針對伺服器設計驗證套用本節中所述的方法。

工具集

若要驗證端對端解決方案的效能和延展性，建議您使用 Microsoft Exchange Server Load Generator 工具 (Loadgen) 進行。Loadgen 的設計目的，是要對 Exchange 部署產生模擬的用戶端工作負載。此工作負載可用於評估 Exchange 系統的效能，也可用來評估當系統處於低負載狀態時，對整體解決方案之各種組態變更的影響。Loadgen 能夠模擬 Microsoft Office Outlook 2007 (線上和快取)、Office Outlook 2003 (線上和快取)、POP3、IMAP4、SMTP、ActiveSync 和 Outlook Web App (在 Exchange 2007 及舊版本中稱為 Outlook Web Access) 用戶端活動。它可用來產生單一通訊協定工作負載，也能合併這些用戶端通訊協定以產生多種通訊協定工作負載。

您可以從 Microsoft 下載中心取得 Loadgen 工具，網址如下：

Loadgen 安裝程式隨附的文件說明如何針對 Exchange 部署設定及執行 Loadgen 測試。

伺服器驗證方法

在驗證您的伺服器設計時，可在預期的尖峰工作負載情況下測試最糟情況的案例。根據來自 Microsoft IT 和其他客戶的資料集數目，尖峰負載通常會等於其餘工作日的兩倍平均工作負載。這稱為尖峰平均工作負載比率。

效能監視器

此效能監視器快照中顯示了各種計數器，代表隨著時間推移而在實際執行之信箱伺服器上執行的 Exchange 工作量，若以整天下來的作業進行平均計算，每秒執行 RPC 作業的平均值 (反白顯示) 大約為 2,386。此計數器的平均值在從 10:00 到 11:00 的尖峰期間大約為 4,971，假設尖峰平均比率為 2.08。

為了確保 Exchange 解決方案能夠維持尖峰平均期間所產生的工作負載，請將 Loadgen 設定修改為在尖峰平均層級上產生固定數量的負載，而不是將工作負載分散到整個模擬的工作日中。Loadgen 的工作型模擬模組 (如 Outlook 模擬模組) 會使用到工作設定檔，該設定檔定義在模擬的一天內，一般使用者的每個工作發生的次數。

在模擬的一天內需要執行的工作總數計算方式為使用者數目乘以設定的工作設定檔中工作的總數。然後 Loadgen 會針對設定的一組使用者決定其執行任務的速率，計算方式是將模擬的一天內執行的工作總數除以模擬的一天的長度。例如，若 Loadgen 在模擬的一天內需要執行 1,000,000 個工作，而模擬的一天等於 8 小時 (28,800 秒)，則 Loadgen 每秒必須執行 1,000,000 ÷ 28,800 = 34.72 個工作才能符合所需的工作負載定義。若要將負載量增加至所需的尖峰平均值，可將預設的模擬的一天的長度 (8 小時) 除以尖峰平均比率 (2)，並使用這個值做為新的模擬的一天的長度。

再計算一次工作比率，可得每秒執行 1,000,000 ÷ 14,400 = 69.44 個工作。這麼做可將模擬的一天的長度降低一半，並導致實際對伺服器執行的工作負載增加一倍，從而達到我們對於尖峰平均工作負載的目標。您不需在 Loadgen 組態中調整測試的執行期間。執行期間會指定測試的期間，不會影響到將對 Exchange 伺服器執行之工作的速率。

伺服器驗證的測試案例

針對解決方案執行下列伺服器設計驗證測試案例，並應考慮將其做為伺服器設計驗證的起始點。特定的部署可能會有其他驗證需求以滿足額外的測試，所以此清單可能會有遺漏的項目：

  • 一般作業情況 在此測試案例中會在其一般作業狀態下使用所有元件驗證解決方案的基本設計 (未模擬失敗情況)。其中會針對解決方案產生所需的工作負載，並針對所遵循的度量驗證解決方案的整體效能。

  • 單一伺服器失敗或單一伺服器維護 (站台內) 在此測試案例中會將某部伺服器關閉，以模擬伺服器發生非預期的失敗或伺服器需要進行已規劃的維護作業。正常應該由無法使用的伺服器處理的工作負載現在會由解決方案拓中的其他伺服器處理，藉此驗證解決方案的整體效能。

測試執行和資料收集

Exchange 的效能資料在測試回合內和測試回合之間會有一些自然的變化。建議您採用多次執行的平均值，以消除此變化 在 Exchange 測試解決方案中，至少有三個獨立的測試回合會在八個小時的期間內完成。效能資料將在八個小時的測試期間內進行收集。效能摘要資料會取自三個到四個小時的穩定期間 (排除測試的前兩個小時和測試的最後一個小時)。對於每種 Exchange Server 角色，效能摘要資料是取自每個測試回合的伺服器間的平均值，以便為每個資料點提供單一平均值。接著會對每個回合的值進行平均計算，以針對所有伺服器 (如所有測試回合中的伺服器角色) 提供單一資料點。

驗證預期的負載

在您查看任何效能計數器或開始進行效能驗證分析之前，請驗證預期執行的工作負載是否符合實際執行的工作負載。儘管有許多方式可以判斷模擬的工作負載是否符合預期的工作負載，但最簡單也最一致的方式即是查看郵件傳遞速率。

計算預期的尖峰郵件傳遞速率

每個郵件設定檔是由每天傳送郵件的平均數目加總和每天接收的郵件平均數目所組成。若要計算郵件傳遞速率，請從下表選取每天接收的郵件平均數目。

尖峰郵件傳遞速率

郵件設定檔 每天傳送的郵件 每天接收的郵件

50

10

40

100

20

80

150

30

120

200

40

160

以下範例假設每部信箱伺服器有 5,000 個使用中信箱，內含每天 150 封郵件的設定檔 (每天傳送 30 封郵件以及接收 120 封郵件)。

5,000 個使用中信箱的尖峰郵件傳遞速率

描述 計算 值

郵件設定檔

每天接收的郵件數目

120

每部信箱伺服器的使用中信箱數目

不適用

5000

每一天每部信箱伺服器接收的郵件總數

5000 × 120

600000

每部信箱伺服器每秒接收的郵件總數

600000 ÷ 28800

20.83

針對最大負載進行調整的郵件總數

20.83 × 2

41.67

您預期在每部執行 5,000 個使用中信箱的郵件伺服器 (具有每天在最大負載期間傳遞 150 封郵件的郵件設定檔) 上每秒傳遞 41.67 封郵件。

測量的實際郵件傳遞速率

實際的郵件傳遞速率可在每部郵件伺服器上使用下列計數器進行測量：MSExchangeIS Mailbox(_Total)\Messages Delivered/sec。如果測得的郵件傳遞速率與目標郵件傳遞速率每秒相差在一封或兩封郵件之內，則您可以確信所需的負載設定檔已順利執行。

伺服器驗證：效能和健康條件

本節說明一些效能監視器的計數器和閾值，這些計數器和閾值用來判斷 Exchange 環境的大小是否適當，以及在長時間的尖峰工作負載下是否能夠在正常狀態下執行。如需與 Exchange 效能相關之計數器的相關資訊，請參閱效能及延展性計數器和閾值。

Hyper-V 根伺服器

若要驗證 Hyper-V 根伺服器與在 VM 中執行之應用程式的效能和健康條件，您應該對 Hyper-V 架構以及其如何影響效能監控的內容進行基本的了解。

Hyper-V 有三個主要元件：虛擬堆疊、Hypervisor 和裝置。虛擬堆疊可處理模擬的裝置、管理 VM 和服務的 I/O。Hypervisor 可排程虛擬處理器、管理中斷、服務計數器，以及控制其他晶片等級的功能。Hypervisor 無法處理裝置或 I/O (例如，其中沒有 Hypervisor 驅動程式)。裝置是屬於根伺服器的一部分，或是安裝在來賓伺服器中做為整合服務的一部分。由於根伺服器可以完整檢視系統並控制 VM，因此也經由 Windows Management Instrumentation (WMI) 和效能計數器提供監視資訊。

處理器

在根伺服器上 (或在來賓 VM 中) 驗證實體處理器使用率時，標準的 Processor\% Processor Time 計數器不是非常有用。

您可以改為檢查 Hyper-V Hypervisor Logical Processor\% Total Run Time 計數器。此計數器顯示花費在來賓和 Hypervisor 執行階段的處理器時間百分比，應用於測量 Hypervisor 和根伺服器上執行之所有 VM 的總處理器使用率。此計數器不應超過 80% 或您所設計的任何最大使用率目標。

計數器 目標

Hyper-V Hypervisor Logical Processor\% Total Run Time

<80%

如果您有興趣知道花費在服務來賓 VM 的處理器時間百分比，可以檢查 Hyper-V Hypervisor Logical Processor\% Guest Run Time 計數器。如果想知道花費在 Hypervisor 中的處理器時間百分比，可以查看 Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time 計數器。此計數器應低於 5%。Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time 計數器顯示花費在虛擬堆疊中的處理器時間百分比。此計數器也應低於 5%。這兩種計數器可用來判斷目前用於支援虛擬的可用實體處理器時間百分比。

計數器 目標

Hyper-V Hypervisor Logical Processor\% Guest Run Time

<80%

Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time

<5%

Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time

<5%

記憶體

您必須確定 Hyper-V 根伺服器的記憶體足夠，以支援配置給 VM 的記憶體。Hyper-V 會自動為根作業系統保留 512 MB (這可能會因不同的 Hyper-V 版本而異)。如果記憶體不足，Hyper-V 將不會讓最後的 VM 啟動。一般情況下，不需擔心在 Hyper-V 根伺服器上驗證記憶體的問題，而是應該確保是否已配置足夠的記憶體給 VM，以支援各種 Exchange 角色。

應用程式健康情況

判斷所有 VM 是否皆處於正常狀態的一種簡單方法即是查看 Hyper-V Virtual Machine Health Summary 計數器。

計數器 目標

Hyper-V Virtual Machine Health Summary\Health OK

1

Hyper-V Virtual Machine Health Summary\Health Critical

0

信箱伺服器

在驗證信箱伺服器的大小是否適當時，請將重點放在處理器、記憶體、儲存和 Exchange 應用程式健康情況上。本節說明驗證這些元件的方法。

處理器

在設計過程中，您會計算伺服器或處理器平台的調整後 MHz 能力。接著您會決定伺服器支援的使用中信箱數目上限不超過可用 MHz 能力的 80%。您還會決定在一般作業情況及各種伺服器維護或失敗案例期間規劃的 CPU 使用率。

在驗證過程中，請驗證最糟情況案例的工作負載不會超過可用 MHz 的 80%。同時請驗證在一般作業情況及各種伺服器維護或失敗案例期間實際的 CPU 使用率是否接近預期的 CPU 使用率。

針對實體 Exchange 部署，請使用 Processor(_Total)\% Processor Time 計數器，並驗證此計數器是否低於平均的 80%。

計數器 目標

Processor(_Total)\% Processor Time

<80%

對於虛擬 Exchange 部署，可在 VM 中測量 Processor(_Total)\% Processor Time 計數器。在這種情況下，該計數器不會測量實際的 CPU 使用率，而是會測量 Hypervisor 所提供之虛擬 CPU 的使用率。因此，該計數器並沒有提供實體處理器的準確讀值，所以不應用在設計驗證用途。如需相關資訊，請參閱 Hyper-V：時鐘的謊言... 您可以信任哪一個效能計數器。

若要驗證執行在 Microsoft Hyper-V 上的 Exchange 部署，請使用 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 計數器。此計數器對於來賓作業系統使用之實體 CPU 的數量提供更準確的值。此計數器應低於平均的 80%。

計數器 目標

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<80%

記憶體

在設計過程中，您會計算在信箱伺服器上支援主動資料庫數目上限所需的資料庫快取數量。接著您會決定最佳的實體記憶體，以支援資料庫快取和系統記憶體需求。

驗證 Exchange 信箱伺服器的記憶體是否足以支援目標工作負載的工作並不簡單。使用可用記憶體計數器來檢視剩餘的實體記憶體並沒有幫助，因為 Exchange 中記憶體管理員的設計目的，是會使用幾乎所有的可用實體記憶體。資訊儲存庫 (store.exe) 會保留大部分的實體記憶體做為資料庫快取。資料庫快取用來在記憶體中儲存資料庫分頁。在記憶體中存取某個分頁時不需從磁碟擷取資訊，可減少讀取 I/O 的次數。資料庫快取也可用來對寫入 I/O 進行最佳化。

當資料庫分頁遭到修改時 (也稱為*「中途分頁」*)，該分頁會在快取中保留一段時間。在快取中停留的時間越長，該分頁在將這些變更寫入磁碟前遭到多次修改的機會就越大。在快取中保留中途分頁也會導致在相同作業中將多個分頁寫入磁碟 (也稱為 write coalescing (寫入聯合))。Exchange 會盡量使用系統中較多的可用記憶體，這也是為什麼 Exchange 信箱伺服器上沒有大量可用空間的緣故。

要確認 Exchange 信箱伺服器的記憶體組態是否太小是一件不容易的事。在大多數情況下，信箱伺服器仍會運作，但您的 I/O 設定檔可能會比預期的要高得多。較高的 I/O 可能會導致較高的磁碟讀取及寫入延遲，這將影響應用程式健康情況和用戶端使用者體驗。在結果區段中，沒有任何項目參考到記憶體計數器。在儲存驗證和應用程式健康情況結果區段中可能會發現潛在的記憶體問題，在這些區段中比較容易偵測到記憶體相關的問題。

儲存裝置

如果在使用 Exchange 信箱伺服器時出現效能問題，這些問題可能是與儲存相關的問題。儲存問題可能是因為磁碟數目不足以支援目標 I/O 需求、設計了超載或效能不佳的儲存連線基礎結構，或是因為變更如記憶體不足等目標 I/O 設定檔等因素所造成。

儲存驗證的第一個步驟是驗證資料庫延遲是否低於目標閾值。在舊版本中是由邏輯磁碟計數器來確定磁碟讀取和寫入延遲。在 Exchange 2010 中，您所監視的 Exchange 信箱伺服器可能會有混合的主動和被動信箱資料庫副本。主動和被動資料庫副本的 I/O 特性是不同的。由於被動副本上的 I/O 的大小較大，因此通常會在被動副本上出現較高的延遲現象。被動資料庫的延遲目標為 200 毫秒，這是主動資料庫副本目標的 10 倍。這不是太大的問題，因為被動資料庫上的高延遲對用戶端使用者體驗沒有影響。但如果您是使用傳統的邏輯磁碟計數器來測量延遲，則必須檢閱內含主動和被動資料庫的個別磁碟區和單獨的磁碟區。建議您改用 Exchange 2010 中新的 MSExchange Database 計數器。

在 Exchange 2010 信箱伺服器上驗證延遲時，建議您針對主動資料庫使用下表所列的計數器。

計數器 目標

MSExchange Database\I/O Database Reads (Attached) Average Latency

<20 毫秒

MSExchange Database\I/O Database Writes (Attached) Average Latency

<20 毫秒

MSExchange Database\IO Log Writes Average Latency

<1 毫秒

建議您針對被動資料庫使用下表所列的計數器

計數器 目標

MSExchange Database\I/O Database Reads (Recovery) Average Latency

<200 毫秒

MSExchange Database\I/O Database Writes (Recovery) Average Latency

<200 毫秒

MSExchange Database\IO Log Read Average Latency

<200 毫秒
注意事項附註：
若要在 [效能監視器] 中檢視這些計數器，您必須啟用進階的資料庫計數器。如需相關資訊，請參閱如何啟用延伸的 ESE 效能計數器。

當您在驗證執行於 Microsoft Hyper-V 之 Exchange 部署的磁碟延遲時，請注意 I/O Database Average Latency 計數器 (以及許多時間型的計數器) 可能不準確，因為 VM 中的時間概念與實體伺服器不同。下列範例顯示在相同的模擬工作負載下，I/O Database Reads (Attached) Average Latency 在 VM 中為 22.8，而在實體伺服器上為 17.3。如果時間型計數器的數值超過目標閾值，表示您的伺服器可能是正常運作中。檢閱所有健康條件以決定在 VM 中部署 Mailbox server role 信箱伺服器時，與伺服器健康情況有關的決定。

虛擬和實體信箱伺服器的磁碟延遲計數器值

計數器 虛擬信箱伺服器 實體信箱伺服器

MSExchange Database/

I/O Database Reads (Attached) / Average Latency

22.792

17.250

I/O Database Reads (Attached) / sec

17.693

18.131

I/O Database Reads (Recovery) / Average Latency

34.215

27.758

I/O Database Writes (Recovery) / sec

10.829

  8.483

I/O Database Writes (Attached) / Average Latency

  0.944

  0.411

I/O Database Writes (Attached)/sec

10.184

10.963

MSExchangeIS

    

RPC Averaged Latency

   1.966

   1.695

RPC Operations/sec

334.371

341.139

RPC Packets/sec

180.656

183.360

MSExchangeIS Mailbox

Messages Delivered/sec

2.062

2.065

Messages Sent/sec

0.511

0.514

除了磁碟延遲之外，請檢閱 Database\Database Page Fault Stalls/sec 計數器。這個計數器會指示因為資料庫快取沒有可用於配置的分頁，因而無法服務的分頁錯誤比率。此計數器在正常的伺服器上應為 0。

計數器 目標

Database\Database Page Fault Stalls/sec

<1

同時請檢閱 Database\Log Record Stalls/sec 計數器，該計數器指出因為記錄緩衝區已滿，而無法新增至每秒記錄緩衝區的記錄檔記錄數目。此計數器平均應小於 10。

計數器 目標

Database\Log Record Stalls/sec

<10

Exchange 應用程式健康情況

即使在使用處理器、記憶體和磁碟時沒有出現明顯的問題，建議您要監視應用程式健康情況計數器，以確保 Exchange 信箱伺服器是處於正常狀態。

MSExchangeIS\RPC Averaged Latency 計數器對於其他具有高資料庫延遲的計數器是否實際影響到 Exchange 健康情況和用戶端體驗的部分提供了最好的說明。通常高的 RPC 平均延遲會與 RPC 要求數目很多有關，該項數值應該隨時保持在 70 以下。

計數器 目標

MSExchangeIS\RPC Averaged Latency

平均 < 10 毫秒

MSExchangeIS\RPC Requests

永遠 < 70

接下來，請確保傳輸層的狀況正常。傳輸的任何問題或影響到傳輸層之傳輸下游的問題皆可以使用 MSExchangeIS Mailbox(_Total)\Messages Queued for Submission 計數器進行偵測。此計數器應隨時保持在 50 以下。如果此計數器出現臨時增加的情況，計數器值也不應隨著時間而成長，也不應持續超過 15 分鐘。

計數器 目標

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

永遠 < 50

接下來請確定資料庫副本的維護處於正常狀態。任何使用記錄傳送或記錄重新顯示的問題都可以使用 MSExchange Replication(*)\CopyQueueLength 和 MSExchange Replication(*)\ReplayQueueLength 計數器進行確認。複製佇列長度顯示等待複製至被動副本記錄檔資料夾的交易記錄檔數目，其值應隨時保持在 1 以下。重新顯示佇列長度顯示等候重新顯示至被動副本的交易記錄檔數目，其值應低於 5。執行遞交、容錯移轉或啟動時，高的值不會影響用戶端體驗，但會導致較長的儲存裝載時間。

計數器 目標

MSExchange Replication(*)\CopyQueueLength

<1

MSExchange Replication(*)\ReplayQueueLength

<5

Client Access Server

若要判斷 Client Access Server 是否正常，請檢閱處理器、記憶體和應用程式健康情況。如需重要計數器的完整清單，請參閱 Client Access Server 計數器。

處理器

對於實體 Exchange 部署，請使用 Processor(_Total)\% Processor Time 計數器。此計數器應低於平均的 80%。

計數器 目標

Processor(_Total)\% Processor Time

<80%

若要驗證執行在 Microsoft Hyper-V 上的 Exchange 部署，請使用 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 計數器。此計數器對於來賓作業系統使用之實體 CPU 的數量提供準確的值。此計數器應低於平均的 80%。

計數器 目標

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<80%

應用程式健康情況

若要判斷 MAPI 用戶端體驗是否可接受，請使用 MSExchange RpcClientAccess\RPC Averaged Latency 計數器進行。此計數器應低於 250 毫秒。高延遲現象可能是與大量的 RPC 要求有關。MSExchange RpcClientAccess\RPC Requests 計數器平均應低於 40。

計數器 目標

MSExchange RpcClientAccess\RPC Averaged Latency

<250 毫秒

MSExchange RpcClientAccess\RPC Requests

<40

傳輸伺服器

若要判斷傳輸伺服器是否正常，請檢閱處理器、磁碟和應用程式健康情況。如需重要計數器的完整清單，請參閱 傳輸伺服器計數器。

處理器

對於實體 Exchange 部署，請使用 Processor(_Total)\% Processor Time 計數器。此計數器應低於平均的 80%。

計數器 目標

Processor(_Total)\% Processor Time

<80%

若要驗證執行在 Microsoft Hyper-V 上的 Exchange 部署，請使用 Hyper-V Hypervisor Virtual Processor\% Guest Run Time 計數器。此計數器對於來賓作業系統使用之實體 CPU 的數量提供準確的值。此計數器應低於平均的 80%。

計數器 目標

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<80%

磁碟

若要判斷磁碟效能是否可以接受，請使用 Logical Disk(*)\Avg.Disk sec/Read 和 Logical Disk(*)\Avg. Disk sec/Write 計數器針對內含傳輸記錄和資料庫的磁碟區進行判斷。這兩個計數器都應該小於 20 毫秒。

計數器 目標

Logical Disk(*)\Avg.Disk sec/Read

<20 毫秒

Logical Disk(*)\Avg.Disk sec/Write

<20 毫秒

應用程式健康情況

若要判斷 Hub Transport Server 的大小是否適當，以及是否在正常狀態下執行，請檢查下表列出的 MSExchangeTransport Queues 計數器。這些佇列在不同的時間都會包含各種訊息。您想要確定佇列長度在一段時間內不會持續成長。如果出現較長的佇列長度，表示 Hub Transport Server 可能已超載。或者是網路問題或因為信箱伺服器已超載而無法接收新的郵件。此時您需要檢查 Exchange 環境的其他元件以進行驗證。

計數器 目標

MSExchangeTransport Queues(_total)\Aggregate Delivery

<3000

MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length

<250

MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length

<250

MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length

<100

MSExchangeTransport Queues(_total)\Submission Queue Length

<100

Exchange 2010 已測試解決方案

功能驗證測試

您可以使用下列各節中的資訊進行功能驗證測試。

Exchange 2010 已測試解決方案

資料庫轉換驗證

資料庫轉換是由個別使用中資料庫轉換至另一個資料庫副本 (被動副本) 的程序，而該資料庫副本會建立新的主動資料庫副本。資料庫轉換可能同時會在資料中心內部和之間發生。您可以使用 Exchange 管理主控台 (EMC) 或 Exchange 管理命令介面來進行資料庫轉換。

若要驗證資料庫的被動副本是否可以在另一部伺服器上順利啟用，請執行下列命令。

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

成功準則：在指定的目標伺服器上裝載使用中信箱資料庫。而這個結果可以透過執行下列命令來確認。

Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 已測試解決方案

伺服器轉換驗證

伺服器轉換是在一個或多個其他 DAG 成員上啟動 DAG 成員上的所有作用中資料庫的程序。和資料庫轉換類似，伺服器轉換可能會在一個資料中心內部和多個資料中心之間發生，而且可以藉由使用 EMC 和命令介面進行初始化。

  • 若要驗證資料庫的所有被動副本是否可以在另一部裝載被動副本的伺服器上順利啟用，請執行下列命令。

    Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>

    成功準則：在指定的目標伺服器上裝載使用中信箱資料庫。這可以透過執行下列命令來確認。

    Get-MailboxDatabaseCopyStatus <DatabaseName>

  • 若要驗證每個主動資料庫的某個副本是否可以在另一部裝載資料庫之被動副本的信箱伺服器上順利啟用，請執行下列動作將伺服器關閉。

    關閉目前使用中的伺服器。

    成功準則：已將使用中信箱資料庫裝載在 DAG 中的另一部信箱伺服器上。這可以透過執行下列命令來確認。

    Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 已測試解決方案

伺服器容錯移轉驗證

伺服器容錯移轉會在 DAG 成員無法再對 MAPI 網路提供服務，或當 DAG 成員上的叢集服務無法再聯繫其餘的 DAG 成員時發生。

若要驗證每個主動資料庫的某個副本是否可以在另一部裝載資料庫之被動副本的信箱伺服器上順利啟用，請執行下列其中一項動作將伺服器關閉。

  • 按住伺服器上的電源按鈕，直到伺服器電源關閉。

  • 將電源線從伺服器中拔出，如此將會使伺服器的電源關閉。

成功準則：已將使用中信箱資料庫裝載在 DAG 中的另一部信箱伺服器上。這可以透過執行下列命令來確認。

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Exchange 2010 已測試解決方案

資料中心轉換驗證

資料中心或站台失敗的管理方式不同於可能導致伺服器或資料庫容錯移轉的失敗。在高可用性組態中，自動復原是由系統啟動，而失敗通常會在完整功能狀態下離開郵件系統。相較之下，資料中心失敗會被視為是災難復原事件，因此必須手動執行和完成復原，以便讓用戶端服務還原並讓中斷結束。您執行的程序稱為資料中心轉換。和許多災難復原案例一樣，資料中心轉換的優先規劃和準備可以簡化復原程序，並縮短中斷的持續時間。

如需相關資訊，包括執行資料中心轉換的詳細步驟，請參閱資料中心轉換。

最初決定啟動次要資料中心之後，要完成四個基本步驟才能執行資料中心轉換：

  1. 終止部分執行 (失敗) 的資料中心。

  2. 驗證並確認次要資料中心的必要條件。

  3. 啟動信箱伺服器。

  4. 啟動 Client Access Server。

以下各節說明用來驗證資料中心轉換的步驟。

終止部分失敗的資料中心 (假設 DAG 處於 DAC 模式)

當 DAG 處於 DAC 模式時，需要根據失敗的資料中心狀態，執行終止主要資料中心內所有存在之 DAG 成員的特定行動。請執行下列其中一項：

  • 如果仍可以存取失敗的資料中心內部的信箱伺服器 (通常情況並非如此)，請在每一部信箱伺服器上執行下列命令。

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>

  • 如果無法存取失敗的資料中心內部的信箱伺服器，但 Active Directory 正在主要資料中心中作業，則需要在網域控制站上執行下列命令。

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
注意事項附註：
如果無法關閉失敗的資料中心內部的信箱伺服器，或是無法順利對伺服器執行 Stop-DatabaseAvailabilityGroup 命令，則兩個資料中心之間就有可能發生核心分裂的狀況。您可能需要透過電源管理裝置個別關閉電腦，以滿足此需求。

成功準則：失敗的站台中所有的信箱伺服器都處於停止狀態。您可以在失敗的資料中心內部的某部伺服器上執行下列命令以進行驗證。

Get-DatabaseAvailabilityGroup | Format-List

驗證和確認次要資料中心的必要條件

必須更新次要資料中心，才能顯示哪個主要資料中心伺服器已停止。在次要資料中心的伺服器上執行下列命令。

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

此步驟的目的是在還原服務時，通知次要資料中心的伺服器可以使用哪些信箱伺服器。

成功準則：失敗的資料中心內所有的信箱伺服器都處於停止狀態。若要確認這一點，請在次要資料中心的伺服器上執行下列命令。

Get-DatabaseAvailabilityGroup | Format-List

使用中信箱伺服器 (假設 DAG 是處於 DAC 模式)

在啟動次要資料中心的 DAG 成員之前，建議您驗證次要資料中心的基礎結構服務是否就緒並可供啟動通訊服務。

當 DAG 處於 DAC 模式時，在次要資料中心完成啟動信箱伺服器的步驟，如下所示：

  1. 在次要資料中心的每個 DAG 成員上停止叢集服務。您可以使用 Stop-Service Cmdlet 來停止服務 (例如，Stop-Service ClusSvc)，或從提升權限的命令提示字元使用 net stop clussvc。

  2. 若要啟用次要資料中心內的信箱伺服器，請執行下列命令。

    Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>

    如果此命令成功，則仲裁條件會縮小為次要資料中心的伺服器。如果該資料中心的伺服器數目是偶數，則 DAG 將轉成使用由 DAG 物件的設定所識別的替代見證伺服器。

  3. 若要啟用資料庫，請執行以下其中一個命令。

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>

    或

    Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>

  4. 檢查事件日誌並檢閱所有錯誤和警告訊息，以確定次要站台的狀態正常。在裝載資料庫之前，所有已指明的問題都應該加以處理和修正。

  5. 若要裝載資料庫，請執行下列命令。

    Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database

成功準則：已將使用中信箱資料庫裝載在次要站台的信箱伺服器上。若要進行確認，請執行下列命令。

Get-MailboxDatabaseCopyStatus <DatabaseName>

啟用 Client Access Server

用戶端會連線至服務端點，以存取 Exchange 服務和資料。因此，啟動能夠使用網際網路的 Client Access Server 就包括變更 DNS 記錄，以指向將針對新服務端點設定的新 IP 位址。接著，用戶端將會以下列其中一個方式自動連接到新服務端點：

  • 用戶端將繼續嘗試連接，而且應該會在原始 DSN 項目的存留時間 (TTL) 過期之後自動連接，以及在用戶端 DNS 快取的項目過期之後自動連接。使用者還可以從命令提示字元執行 ipconfig /flushdns 命令，手動清除其 DNS 快取。如果使用 Outlook Web App，網頁瀏覽器可能需要關閉再重新啟動，以清除瀏覽器使用的 DNS 快取。在 Exchange 2010 SP1 中，此瀏覽器快取問題可以藉由在 Outlook Web App 虛擬目錄 owa 上設定 FailbackURL 參數來解決。

  • 用戶端啟動或重新啟動時，會執行 DNS 查閱並取得服務端點的新 IP 位址；而此端點將是次要資料中心的 Client Access Server 或陣列。

若要驗證使用 Loadgen 的案例，請執行下列動作：

  1. 將 Client Access Server 陣列的 DNS 項目變更為指向次要站台中硬體負載平衡的虛擬 IP 位址。

  2. 在 Loadgen 伺服器上執行 ipconfig /flushdns 命令。

  3. 重新啟動 Loadgen 測試。

  4. 確認次要站台中的 Client Access Server 現在已為負載提供服務。

若要驗證使用 Outlook 2007 用戶端的案例，請執行下列動作：

  1. 將 Client Access Server 陣列的 DNS 項目變更為指向次要站台中硬體負載平衡的虛擬 IP 位址。

  2. 在用戶端或等待直到 TTL 過期時執行 ipconfig /flushdns 命令。

  3. 等待 Outlook 用戶端重新連接。

Exchange 2010 已測試解決方案

主要資料中心服務還原驗證

將服務還原至先前失敗之資料中心的處理程序稱爲「容錯回復」。執行資料中心容錯回復的步驟與執行資料中心轉換的步驟類似。其中的顯著差別在於，資料中心容錯回復是經過排程的動作，而且中斷的持續時間通常較短。

重要的是，除非 Exchange 的基礎結構相依性已經重新啟動、正在穩定操作且已經過驗證，否則不會執行容錯回復。如果這些相依性無法使用或狀況不良，容錯回復的處理程序就會比必要的中斷時間更久，且有可能會全部失敗。

Mailbox server role 應該是容錯回復到主要資料中心的第一個角色。下列步驟詳細說明 Mailbox server role 容錯回復過程 (假設 DAG 處於 DAC 模式)。

  1. 若要將 DAG 成員重新合併至主要站台，請執行下列命令。

    Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>

  2. 若要驗證主要資料中心的資料庫副本狀態，請執行下列命令。

    Get-MailboxDatabaseCopyStatus

當主要資料中心的 Mailbox Server 合併到 DAG 之後，這些 Mailbox Server 需要一些時間才能同步處理其資料庫副本。視失敗的性質、中斷的長度及管理員在中斷期間採取的動作而定，可能需要重新植入資料庫副本。例如，如果您在中斷期間，從失敗的主要資料中心移除資料庫副本，讓次要資料中心的剩餘主動副本發生記錄檔截斷，則需要重新植入。此時，可以分別對每個資料庫進行同步處理。如果主要資料中心的複寫資料庫副本狀況良好，您就可以繼續進行下一個步驟。

  1. 在資料中心轉換過程中，DAG 會設定為使用替代見證伺服器。若要將主要資料中心的 DAG 重新設定為使用見證伺服器，請執行下列命令。

    Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>

  2. 現在應該從次要資料中心卸載已在主要資料中心重新啟動的資料庫。執行下列命令。

    Get-MailboxDatabase | Dismount-Database

  3. 卸載資料庫之後，Client Access Server URL 就應該從次要資料中心移到主要資料中心。變更 DNS 記錄，讓 URL 指向主要資料中心的 Client Access Server 或陣列，即可完成此動作。

    重要事項重要事項：
    除非 Client Access Server URL 已移動，且 DNS TTL 及快取項目都已過期，否則請勿繼續進行下一個步驟。如果在 Client Access Server URL 移到主要資料中心之前，就啟動主要資料中心的資料庫，則會導致組態無效 (例如，裝載資料庫在自己的 Active Directory 站台中沒有 Client Access Server)。

  4. 若要啟用資料庫，請執行以下其中一個命令。

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>

    或

    Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>

  5. 若要裝載資料庫，請執行下列命令。

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database

成功準則：已將使用中信箱資料庫順利裝載在主要站台的信箱伺服器上。若要進行確認，請執行下列命令。

Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 已測試解決方案

測試設備

測試皆在 Microsoft Enterprise Engineering Center進行，這是位於美國華盛頓州雷蒙市 Microsoft 總部最先進的企業解決方案驗證實驗室。

擁有超過 1.25 億美元價值的硬體，並與領先業界的原始設備製造商 (OEM) 保持緊密的夥伴關係，幾乎所有的實際執行環境都可以在 EEC 複製。EEC 提供的環境，可讓客戶、合作夥伴和 Microsoft 工程師進行廣泛的合作。這有助於確保 Microsoft 端對端解決方案將符合客戶的高度期望。

Exchange 2010 已測試解決方案

解決方案驗證結果

下列各節將摘要說明功能和效能驗證測試的結果。

Exchange 2010 已測試解決方案

功能驗證結果

下表摘要說明功能驗證測試結果。

功能驗證結果

測試案例 結果 註解

資料庫轉換

成功

已完成，未發生錯誤

伺服器轉換

成功

已完成，未發生錯誤

伺服器失敗

成功

已完成，未發生錯誤

站台失敗

成功

已完成，未發生錯誤

Exchange 2010 已測試解決方案

儲存設計驗證結果

針對單一儲存框架上每一個站台的所有磁碟進行的測試顯示 CX4-480 可在八個 Exchange VM 間處理正好超過 8,000 次 Exchange 2010 交易 IOPS，該 Exchange VM 內含 150 個訊息的使用者設定檔為 .15 的 IOPS 與額外 20% 的空餘空間。效能超過此組態所需的 5,832 IOPS 目標基準，並為尖峰負載提供一些額外的空餘空間。根據 Microsoft 對 Exchange 2010 效能的最佳作法，磁碟延遲均在可接受的參數內。

儲存設計驗證結果

資料庫 I/O 目標值 4 部信箱伺服器，在一般作業情況下 (每部信箱伺服器 2,700 個使用者) 4 部信箱伺服器，在轉換情況 (每部信箱伺服器 5,400 個使用者) 總計

達成的交易 IOPS (I/O Database Reads/sec + I/O Database Writes/sec)

1944 / 3888

3576 IOPS

4488 IOPS

8064 IOPS

I/O Database Reads/sec

不適用

2193

2729

4922

I/O Database Writes/sec

不適用

1439

1703

3142

I/O Database Reads Average Latency (msec)

<20 毫秒

14

18

16

I/O Database Writes Average Latency (msec)

不是用戶端延遲的理想指標，因為資料庫寫入為非同步

14

18

16
   

I/O Log Writes/sec

不適用

1238

1560

2798

I/O Log Reads Average Latency (msec)

<10 毫秒

2

2

2

Exchange 2010 已測試解決方案

伺服器設計驗證結果

下表摘要說明測試案例的伺服器設計驗證結果。

Loadgen 驗證：測試案例

測試 描述

一般操作

在一個站台上模擬 10,800 個使用者的 100% 並行負載，每部信箱伺服器處理 2,700 個使用者。

單一伺服器失敗或單一伺服器維護 (站台內)

已模擬每個站台的單一 Hyper-V 主機伺服器失敗。針對單一 Hyper-V 主機執行 100% 的並行負載，一個 VM 處理 5,400 個使用者。只有三部 Client Access 和 Hub Transport Server 組合在處理負載。

站台失敗

已模擬站台失敗，並已在待機的信箱伺服器 VM 上啟用次要映像。在單一站台中針對 21,600 個使用者執行 100% 的並行負載。

測試案例：一般作業環境

這個測試案例表示一般作業環境下的尖峰負載。一般作業環境指的是一種狀態，其中所有使用中和被動資料庫皆位於其規劃執行的伺服器上。由於此測試案例不代表最糟狀況的負載，因此不是關鍵效能驗證測試。其對於發生伺服器失敗或維護事件時，此環境如何運作的良好指示。此測試的目標是要驗證在具有尖峰負載之一般作業環境下的整個 Exchange 環境。所有 Exchange VM 皆在一般作業情況下運作。Loadgen 已設定為模擬的尖峰負載。在尖峰模式下執行的 150 個郵件動作設定檔預期每秒會產生兩倍的傳送及傳遞郵件。

驗證預期的負載

郵件傳遞速率會驗證測試的工作負載是否符合目標的工作負載。郵件傳遞速率比目標稍高，產生了比所需設定檔稍高的負載。

計數器 目標 測試的結果

Message Delivery Rate Per Mailbox

15.0

15.2

驗證主要信箱伺服器

下表顯示主要信箱伺服器 VM 的驗證結果。

處理器

與預期相同，處理器使用率低於 70%。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<70%

69

儲存裝置

儲存結果正常。所有延遲都在目標值以內。

計數器 目標 測試的結果

MSExchange Database\I/O Database Reads (Attached) Average Latency

<20 毫秒

19

MSExchange Database\I/O Database Writes (Attached) Average Latency

<20 毫秒

<讀取平均

18

Database\Database Page Fault Stalls/sec

0

0

MSExchange Database\IO Log Writes Average Latency

<20 毫秒

5

Database\Log Record Stalls/sec

0

0

應用程式健康情況

Exchange 的狀況良好，而且所有用於判斷應用程式健康情況的計數器也都在目標值之內。

計數器 目標 測試的結果

MSExchangeIS\RPC Requests

<70

3.0

MSExchangeIS\RPC Averaged Latency

<10 毫秒

2.0

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

0

2.0

驗證次要信箱伺服器

下表顯示次要信箱伺服器 VM 的驗證結果。

處理器

與預期相同，處理器使用率低於 70%。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<70%

26

儲存裝置

儲存結果正常。所有延遲都在目標值以內。

計數器 目標 測試的結果

MSExchange Database\I/O Database Reads (Recovery) Average Latency

<100 毫秒

0

MSExchange Database\I/O Database Writes (Recovery) Average Latency

<100 毫秒

<讀取平均

16

Database\Database Page Fault Stalls/sec

0

0

MSExchange Database\IO Log Writes Average Latency

<20 毫秒

3

Database\Log Record Stalls/sec

0

0

應用程式健康情況

次要信箱伺服器只維護第三被動資料庫副本，因此標準的 Exchange 應用程式健康情況指標不適用於此案例。

計數器 目標 測試的結果

MSExchangeIS\RPC Requests

<70

不適用

MSExchangeIS\RPC Averaged Latency

<10 毫秒

不適用

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

0

不適用

驗證 Client Access 和 Hub Transport Server

下表顯示 Client Access 和 Hub Transport Server VM 的驗證結果。

處理器

處理器使用率很低，與預期相同。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<70%

48

儲存裝置

儲存結果看起來很正常。極低的延遲對郵件傳輸應該不會有任何影響。

計數器 目標 測試的結果

Logical/Physical Disk(*)\Avg.Disk sec/Read

<20 毫秒

0.001

Logical/Physical Disk(*)\Avg.Disk sec/Write

<20 毫秒

0.005

應用程式健康情況

低的 RPC Averaged Latency 值可確認 Client Access Server 正常，對用戶端體驗沒有影響 。

計數器 目標 測試的結果

MSExchange RpcClientAccess\RPC Averaged Latency

<250 毫秒

8

MSExchange RpcClientAccess\RPC Requests

<40

3

Transport Queues 計數器都在目標之內，表示 Hub Transport Server 正常，且能夠處理和傳遞所需的郵件。

計數器 目標 測試的結果

\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)

<3000

2.5

\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length

<250

0

\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length

<250

2.3

\MSExchangeTransport Queues(_total)\Submission Queue Length

<100

0

\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length

<100

0.3

驗證根伺服器的健康情況

下表顯示 Hyper-V 根伺服器的驗證結果。

處理器

和預期相同，處理器使用率非常低且都在目標閾值之內。

計數器 目標 測試的結果

Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time

<75%

66

Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time

<5%

2

Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time

<80%

68

Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time

<5%

3

應用程式健康情況

Virtual Machine Health Summary 計數器表示所有 VM 皆處於正常狀態。

計數器 目標 測試的結果

Hyper-V Virtual Machine Health Summary\Health Critical

0

0

測試案例：單一伺服器失敗或單一伺服器維護 (站台內)

此測試的目標是要驗證在具有尖峰負載之實體 Hyper-V 根伺服器失敗或維護作業情況下的整個 Exchange 環境。所有在站台內其中一部 Hyper-V 根伺服器上執行的 VM 皆已關機，以模擬主機維護情況。這樣會導致資料庫映像 (副本) 被移動至其他信箱伺服器 VM，從而建立每個信箱伺服器 VM 有 5,400 個使用者的作業情況。只有一半的 Client Access 和 Hub Transport Server 組合會處理用戶端存取和郵件傳遞。

驗證預期的負載

實際的郵件傳遞速率已符合目標。

計數器 目標 測試的結果

每個伺服器的郵件傳遞速率

30

30

驗證主要信箱伺服器

下表顯示主要信箱伺服器 VM 的驗證結果。

處理器

處理器使用率剛好超過目標。此項測試案例表示在尖峰負載的失敗或維護案例，因此這會是很少發生的事件。您不想讓處理器使用率在這麼高的情況下持續一段時間。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<80%

83

儲存裝置

儲存結果看起來可以接受。平均讀取延遲剛好超過目標。平均資料庫寫入延遲高於喜好值。這是在尖峰負載下的最糟情況案例，因此很少會發生。高延遲不會讓應用程式健康情況超過目標值，所以使用者體驗應該還是可以接受。您不想讓延遲在這麼高的情況下持續一段時間。

計數器 目標 測試的結果

MSExchange Database\I/O Database Reads (Attached) Average Latency

<20 毫秒

20.5

MSExchange Database\I/O Database Writes (Attached) Average Latency

<20 毫秒

23

Database\Database Page Fault Stalls/sec

0

0

MSExchange Database\IO Log Writes Average Latency

<20 毫秒

8

Database\Log Record Stalls/sec

0

0

應用程式健康情況

計數器顯示 Exchange 仍然可以視為正常。某些郵件佇列在尖峰負載下開始出現了。您不想要讓這種情況持續一段時間。

計數器 目標 測試的結果

MSExchangeIS\RPC Requests

<70

9.0

MSExchangeIS\RPC Averaged Latency

<10 毫秒

2.0

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

0

77

驗證次要信箱伺服器

下表顯示次要信箱伺服器 VM 的驗證結果。

處理器

與預期相同，處理器使用率低於 70%。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<70%

21

儲存裝置

儲存結果正常。所有延遲都在目標值以內。

計數器 目標 測試的結果

MSExchange Database\I/O Database Reads (Recovery) Average Latency

<100 毫秒

0

MSExchange Database\I/O Database Writes (Recovery) Average Latency

<100 毫秒

<讀取平均

21

Database\Database Page Fault Stalls/sec

0

0

MSExchange Database\IO Log Writes Average Latency

<20 毫秒

3

Database\Log Record Stalls/sec

0

0

應用程式健康情況

次要信箱伺服器只維護第三被動資料庫副本，因此標準的 Exchange 應用程式健康情況指標不適用於此案例。

計數器 目標 測試的結果

MSExchangeIS\RPC Requests

<70

不適用

MSExchangeIS\RPC Averaged Latency

<10 毫秒

不適用

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

0

不適用

驗證 Client Access 和 Hub Transport Server

下表顯示 Client Access 和 Hub Transport Server VM 的驗證結果。

處理器

與預期相同，處理器使用率低於 80%。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<80%

74

儲存裝置

儲存結果看起來很正常。極低的延遲對郵件傳輸應該不會有任何影響。

計數器 目標 測試的結果

Logical/Physical Disk(*)\Avg.Disk sec/Read

<20 毫秒

0.001

Logical/Physical Disk(*)\Avg.Disk sec/Write

<20 毫秒

0.008

應用程式健康情況

低的 RPC Averaged Latency 值可確認 Client Access Server 正常，對用戶端體驗沒有影響 。

計數器 目標 測試的結果

MSExchange RpcClientAccess\RPC Averaged Latency

<250 毫秒

18

MSExchange RpcClientAccess\RPC Requests

<40

14

Transport Queues 計數器都在目標之內，表示 Hub Transport Server 正常，且能夠處理和傳遞所需的郵件。

計數器 目標 測試的結果

\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)

<3000

49

\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length

<250

0

\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length

<250

43

\MSExchangeTransport Queues(_total)\Submission Queue Length

<100

53

\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length

<100

4

驗證根伺服器的健康情況

下表顯示 Hyper-V 根伺服器的驗證結果。

處理器

處理器使用率已接近目標閾值，這預期會在尖峰負載下出現的失敗或維護案例。

計數器 目標 測試的結果

Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time

<75%

77

Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time

<5%

2

Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time

<80%

79

Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time

<5%

3

應用程式健康情況

Virtual Machine Health Summary 計數器表示所有 VM 皆處於正常狀態。

計數器 目標 測試的結果

Hyper-V Virtual Machine Health Summary\Health Critical

0

0

測試案例：站台失敗和轉換

此測試案例模擬站台失敗，方法是將主要站台的主動資料庫切換到次要站台的被動資料庫，使站台產生 21,600 個使用中信箱。剩餘站台的四部主要信箱伺服器 VM 皆在 2,700 個使用中信箱的一般工作負載下運作。剩餘站台的四部次要信箱伺服器 VM 目前執行 2,700 個使用中信箱。每部 Hyper-V 根伺服器主控 5,400 個使用中信箱。

驗證預期的負載

郵件傳遞速率比目標稍高，產生了比所需設定檔稍高的負載。

計數器 目標 測試的結果

每個伺服器的郵件傳遞速率

15

15.1

驗證主要信箱伺服器

下表顯示主要信箱伺服器 VM 的驗證結果。

處理器

主要信箱伺服器 VM 正在一般工作負載下執行，處理器使用率未超過目標，和預期相同。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<70%

63

儲存裝置

儲存結果正常。所有延遲都在目標值以內。

計數器 目標 測試的結果

MSExchange Database\I/O Database Reads (Attached) Average Latency

<20 毫秒

12

MSExchange Database\I/O Database Writes (Attached) Average Latency

<20 毫秒

13

Database\Database Page Fault Stalls/sec

0

0

MSExchange Database\IO Log Writes Average Latency

<20 毫秒

4

Database\Log Record Stalls/sec

0

0

應用程式健康情況

Exchange 的狀況良好，而且所有用於判斷應用程式健康情況的計數器也都在目標值之內。

計數器 目標 測試的結果

MSExchangeIS\RPC Requests

<70

3.0

MSExchangeIS\RPC Averaged Latency

<10 毫秒

2.0

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

0

3

驗證次要信箱伺服器

下表顯示次要信箱伺服器 VM 的驗證結果。

處理器

處理器使用率剛好超過目標的 80%。這種情況已超過喜好值，但似乎不會影響其他的 Exchange 健康情況計數器。由於此項測試表示尖峰負載在極少發生失敗的期間出現尖峰，因此不會有問題。您不希望在這種等級的處理器使用率下持續一段時間。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<80%

84

儲存裝置

儲存結果正常。所有延遲都在目標值以內。

計數器 目標 測試的結果

MSExchange Database\I/O Database Reads (Attached) Average Latency

<20 毫秒

17

MSExchange Database\I/O Database Writes (Attached) Average Latency

<20 毫秒

<讀取平均

12

Database\Database Page Fault Stalls/sec

0

0

MSExchange Database\IO Log Writes Average Latency

<20 毫秒

3

Database\Log Record Stalls/sec

0

0

應用程式健康情況

計數器顯示 Exchange 是正常的。其中有少量的佇列處理情形。

計數器 目標 測試的結果

MSExchangeIS\RPC Requests

<70

3

MSExchangeIS\RPC Averaged Latency

<10 毫秒

2

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission

0

106

驗證 Client Access 和 Hub Transport Server

下表顯示 Client Access 和 Hub Transport Server VM 的驗證結果。

處理器

與預期相同，處理器使用率低於 80%。

計數器 目標 測試的結果

Hyper-V Hypervisor Virtual Processor\% Guest Run Time

<70%

63

儲存裝置

儲存結果看起來很正常。極低的延遲對郵件傳輸應該不會有任何影響。

計數器 目標 測試的結果

Logical/Physical Disk(*)\Avg.Disk sec/Read

<20 毫秒

0.002

Logical/Physical Disk(*)\Avg.Disk sec/Write

<20 毫秒

0.003

應用程式健康情況

低的 RPC Averaged Latency 值可確認 Client Access Server 正常，對用戶端體驗沒有影響 。

計數器 目標 測試的結果

MSExchange RpcClientAccess\RPC Averaged Latency

<250 毫秒

9

MSExchange RpcClientAccess\RPC Requests

<40

7

Transport Queues 計數器都在目標之內，表示 Hub Transport Server 正常，且能夠處理和傳遞所需的郵件。

計數器 目標 測試的結果

\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)

<3000

5

\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length

<250

0

\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length

<250

4

\MSExchangeTransport Queues(_total)\Submission Queue Length

<100

0

\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length

<100

1

驗證根伺服器的健康情況

下表顯示 Hyper-V 根伺服器的驗證結果。

處理器

處理器使用率超過目標的 80%。由於此項測試表示尖峰負載在極少發生失敗的期間出現尖峰，因此不會有問題。您不希望在這種等級的處理器使用率下持續一段時間。

計數器 目標 測試的結果

Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time

<75%

85

Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time

<5%

2

Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time

<80%

87

Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time

<5%

3

應用程式健康情況

Virtual Machine Health Summary 計數器表示所有 VM 皆處於正常狀態。

計數器 目標 測試的結果

Hyper-V Virtual Machine Health Summary\Health Critical

0

0

Exchange 2010 已測試解決方案

結論

此白皮書為如何針對部署在 Cisco 和 EMC 硬體上，於多個站台中具有 32,400 個信箱的客戶環境設計、測試及驗證 Exchange 2010 解決方案提供範例。本文件中的逐步方法詳細說明的重要設計決策點，有助於解決關鍵挑戰，同時亦確保能滿足核心業務需求。

Exchange 2010 已測試解決方案

其他資訊

如需完整的 Exchange 2010 文件，請參閱 Exchange Server 2010。

如需與 Cisco 和 EMC 相關的其他資訊，請參閱下列資源：

本文件依其「原狀」提供。此文件中的資訊和意見 (包括 URL 及其他網際網路網站參照)，如有變更恕不另行通知。貴用戶須自行承擔使用風險。

本文件不對任何 Microsoft 產品的智慧財產權提供合法權利。您可複製本文件供內部參考使用。

Exchange 2010 已測試解決方案