是否應該虛擬化 Exchange 2007 SP1?

 

上次修改主題的時間: 2009-03-02

隨著具備 Hyper-V 技術之 Windows Server 2008 和 Microsoft Hyper-V Server 2008 的發行,虛擬的 Microsoft Exchange Server 2007 Service Pack 1 (SP1) 伺服器不再侷限於只能在實驗室中進行,而是可以部署於生產環境中,並接受 Microsoft 的完整支援。Microsoft 於 2008 年 8 月發佈虛擬 Exchange 的支援原則與建議事項。本文將解答原則性的問題:Exchange 到底適不適合進行虛擬?

如果考量 Exchange Server 的效能和業務需求,將 Exchange 伺服器角色部署在實體伺服器上能獲得最多效果。不過,有時候在硬體虛擬環境中執行 Exchange 可以獲得空間、電力和部署彈性方面的優點。本文內容包括:

  • 案例   本節討論四個適合進行 Exchange 2007 SP1 虛擬的案例。

  • 技術檢查清單   本節提供檢查清單,可協助您評估基礎結構的目前負載是否可實作虛擬。

案例

本節討論四個案例:

  • 需要高可用性的小型辦公室

  • 需要高可用性的遠端辦公室或分公司

  • 嚴重損壞修復

  • Mobile LAN

需要高可用性的小型辦公室

有些組織很小,但仍需要企業等級的可用性。例如,Contoso, Ltd. 這家虛構公司認為電子郵件是很重要的服務。Contoso 有數個小型分公司辦公室,共有 250 名使用者。基於法律因素,Contoso 希望維持電子郵件環境,而且希望能有完整的備援電子郵件系統。Contoso 的平均使用者郵件設定檔提供 2 GB 信箱。

如果使用實體硬體而想做到完整備援所有的 Exchange 伺服器角色,則 Contoso 需要部署七部伺服器:兩部伺服器用於 Active Directory 和 DNS、一部伺服器用於檔案和列印服務、兩部伺服器執行 Client Access 和 Hub Transport server role,以及兩部伺服器在叢集連續複寫 (CCR) 環境中執行 Mailbox server role。假設這些伺服器都具有兩個四核心處理器,以及根據 Microsoft 對每種安裝角色的建議 RAM 數量。每個 CCR 節點有 4 GB RAM,而其他每部伺服器具備至少 2 GB RAM,才足夠支援使用者和流量模式。以平均使用者郵件設定檔而言,八核心伺服器上的一般負載應會使用 35%-45% 的 CPU。

但是如果改用虛擬,Contoso 只需要具備三部伺服器,就能提供相同水準的備援和可用性。每部實體伺服器將以來賓機器的形式執行多部虛擬伺服器。在此例中,三部實體伺服器 (分別具有兩個四核心處理器以及 16 GB RAM) 就能提供足夠的容量來服務 Contoso 的使用者。每部虛擬伺服器都設定為具有兩個虛擬 CPU。除了 RAM 和處理器,伺服器還需要多張網路介面卡和多餘的儲存路徑。因為 Contoso 要管理的 Exchange Server 數目仍然相同,所以在操作和維護方面無法獲得好處,但在空間、電力和系統冷卻方面卻能獲益甚多。

下圖說明本案例。

可能的小型分公司設計

note附註:
在 CCR 環境中主控檔案共用見證 (FSW) 的 Hub Transport Server,是與叢集任一節點不同之 Hypervisor 根機器上的來賓機器。這麼做的用意是為了避免叢集解決方案發生單一失敗點,以便提供真正的叢集功能。

在本案例中,從七部實體伺服器改為三部實體伺服器和七部虛擬伺服器,每年可以節省 25,754 度電和 $22,516 美元。Microsoft 虛擬工具 (英文) 收集了相關的數字報告。

Microsoft HyperGreen 報告 7-至-3

在硬體虛擬環境中調整 Exchange 大小的方法,與在實體伺服器中調整 Exchange 大小一樣。無論您使用的是實體或虛擬伺服器,每個 CCR 節點都需要 4 GB 的 RAM 和能支援資料庫的 48 IOPS 和交易記錄檔的 19 IOPS 的儲存裝置。本案例的 IOPS 需求很低,在虛擬環境中應該能夠維持。由於虛擬 Exchange Server 控管的使用者人數很少,所以本解決方案使用固定虛擬硬碟就已足夠。如果使用者人數較多,Microsoft 建議使用外部儲存裝置。

回到頁首

需要高可用性的遠端辦公室或分公司

過去,部分組織需在遠端辦公室或分公司安裝本機 Exchange Server,才能提供足夠效能給這些地點的使用者。現在有了 Exchange 快取模式和 Outlook 無所不在等改善功能,建議方法就變成將這些伺服器合併至集中的資料中心。

不過,如果遠端辦公室的網路連線能力不佳,則組織還是需要在這些辦公室安裝本機 Exchange Server。通常這些位置的使用者人數都不多,所以不需要配置專用的實體伺服器給 Exchange 環境。此案例的技術考量與上述「需要高可用性的小型辦公室」案例中的說明相同。如需本案例 (在 Hyper-V 環境中使用 Exchange 2007 SP1) 的公司範例,請下載<Windows Server 2008 客戶解決方案個案研究>中的 Caspian Pipeline Consortium (英文)。

嚴重損壞修復

如果想提供生產站台的站台回復性和備援能力,有些組織可能需要一個 Warm Site,內含主要生產 Exchange 2007 基礎結構的複本。這個 Warm Site 的用途是在主要站台遺失時,盡可能提供與主要站台同等級的功能。不過,為了待命目的而維持基礎結構複本在服務等級協定 (SLA) 要求很高時或許有用,但對某些組織來說過於昂貴。

為了降低成本,可以使用 Hyper-V 環境的來賓機器,提供整個主要站台的複本。使用實體 Exchange 2007 伺服器的典型 Warm Site 組態包括將一或多部伺服器設定為待命叢集,並將其他一或多部伺服器設定為 Client Access 和 Hub Transport server role。僅僅為了在 Warm Site 中達到郵件服務的備援,就需要用到四部實體伺服器。相較之下,虛擬解決方案只需要三部實體伺服器,提供給組織的 Warm Site 就能包內含兩部 CCR 環境中的 Mailbox Server,以及備援 Client Access 和 Hub Transport Server。因此,相較於在實體伺服器上部署相同設定的解決方案,在本例中虛擬 Exchange 可以提供更高等級服務給您的使用者,同時又能節省空間、硬體、電力和冷卻成本。

下圖說明此組態。

可能的 Warm Site 嚴重損壞修復組態

由於使用者人數較多以及郵件設定檔的要求較高,主要站台採用實體硬體。在本案例中,Warm Site 的設計是用來支援主要站台的所有使用者。即使只是暫時使用 Warm Site 且效能會稍微降低,但仍需仔細考慮環境的設定,一定要能支援所有使用者。

圖中顯示 Warm Site 包含待命叢集,其中一個節點設定為生產 CCR 環境的待命連續複寫 (SCR) 目標。並部署一對網域控制站,所以 SCR 目標是雙節點的待命叢集。如果發生站台失敗,會使用 Restore-StorageGroupCopy 啟動待命叢集,接著使用 Setup /recoverCMS 參數復原叢集信箱伺服器 (CMS)。雖然待命叢集是硬體虛擬環境中的來賓機器,但此案例仍舊會套用嚴重損壞後使用待命叢集進行復原的相同程序。待命叢集上線並從失敗站台接管 CMS 後,只要 DNS 和 Active Directory 複寫完成後就能還原用戶端對郵件服務和資料的存取。

當主要站台遺失時,虛擬 Warm Site 必須能夠提供足夠的服務等級給使用者,但您同時也需了解,由於 Warm Site 的 WAN/網際網路連結受限,所以服務等級可能會下降。由於 Warm Site 是專供緊急用途,使用期間短,所以下降的服務等級應該還能接受。不過請了解,當主要站台停機時,Warm Site 是沒有站台回復性的。

在本案例中,從八部實體伺服器改為三部實體伺服器和八部虛擬伺服器,每年可以節省 33,005 度電和 $28,225 美元。Microsoft 虛擬工具 (英文) 收集了相關的數字報告。

Microsoft HyperGreen 報告 8-至-3

回到頁首

Mobile LAN

公司、機構或政府部門有時候會需要立即將完整的網路基礎結構部署至特定地點。這種基礎結構可以透過衛星或其他遠端 WAN 技術,連線至組織網路。例如,某個非政府組織 (NGO) 需要因應一場嚴重災難,並設定本機伺服器來服務受影饗的社區。這個伺服器子集必須是完全獨立的,也能夠提供所有必要服務給位在目標地點的人員。

在這種情形中,Mobile LAN 必須易於搬運。它必須體積小、效率高、能提供所有本機使用者的必要服務,並盡可能不佔空間。部署 Mobile LAN 的地點除了要求可攜式遠端功能外,也必須提供容錯功能,以確保在備用零件難以取得的地點不會發生單一失敗點。

在本例中可以使用 Hyper-V 伺服器,在小型裝置中主控 Exchange 服務、檔案伺服器服務和網域基礎結構服務。

note附註:
虛擬 Exchange 2007 SP1 要求不能在根伺服器安裝 IO 作業密集的應用程式。

下圖說明主控 Exchange 2007 和網域基礎結構系統的 Hyper-V 伺服器可能組態。基於本案例的特性,Exchange 伺服器角色未合併在同一部來賓機器上。

可能的 Mobile LAN 組態

不論何地點,圖中針對需在本機提供所有必要伺服器服務的組織,提供完整的網路解決方案。本例盡可能維持在小型解決方案,同時容許高度的容錯和系統可用性。

在這個架構中,您還需要足夠的網路基礎結構設備,以支援 Hypervisor 根伺服器和工作站。Hypervisor 根系統會使用 iSCSI 或光纖通道 SAN。SAN 應提供足夠磁針,以提供來賓系統的所需效能。在本例中,所有必要項目都能放在一個 42U 機架中。

在本案例中,從 14 部實體伺服器改為 3 部實體伺服器和 14 部虛擬伺服器,每年可以節省 91,012 度電和 $73,891 美元。Microsoft 虛擬工具 (英文) 收集了相關的數字報告。

Microsoft HyperGreen 報告 14-至-3

回到頁首

技術檢查清單

在上述每個案例中,如果將 Exchange 部署在實體硬體上,將無法充分利用資源。您可使用下列檢查清單,協助判斷您的 Exchange 環境是否適合進行合併。如果下列檢查清單顯示您的硬體未受到充分利用,則應考慮採取下列動作:

  • 如果是小型組織,可以使用虛擬,將實體伺服器支配量降低至三部實體伺服器,並擁有 Exchange 角色的完整備援。

  • 如果未充分利用的硬體位於無法合併至集中資料中心的分公司或遠端辦公室,您可使用虛擬降低該地點的實體伺服器支配量。

  • 若是其他情形,則可重新探討伺服器容量與使用者負載的相符程度,讓 Exchange 環境更加精實。您可以降低實體伺服器的數目,將使用率提升至理想等級。此狀況不需要使用虛擬。

請記住,未充分使用的硬體僅代表 Exchange 環境容量過多。這種情形可能是故意設計的 (為了容納用量尖峰或預期日後用量成長),也可能不是故意的。有一些多餘容量是合理的,以下檢查清單已納入此考量因素。

note附註:
判斷是否要使用 Exchange 虛擬時,硬體使用率不是唯一的考量因素。在 Exchange 環境中加入虛擬功能,會增加某些領域的複雜程度,比如備份、監視和儲存組態。如需相關資訊,請參閱硬體虛擬環境中 Exchange Server 的 Microsoft 支援原則和建議 (英文)。

檢查清單 #1 – 效能計數器

下列檢查清單概述要監視的效能計數器,這些效能計數器可以指出您的 Exchange 環境是否未充分利用。您需從實體 Exchange Server 收集這些計數器,而不是從虛擬 Exchange Server 收集。由於 Exchange 基礎結構的規劃是根據 Mailbox server role 而定,所以下列檢查清單大部分採用 Mailbox Server 計量值。

建議您最少一星期一次定期收集每個計數器。資料收集完成後,就可以將結果和預期值做比較。如果觀測值小於下列預期值,就表示您的伺服器硬體未予以充分利用。

檢查清單中的計數器來自不使用 System Center Operations Manager 進行監視 (英文)。請確定在將伺服器納入生產環境後才監視這些伺服器。

note附註:
建議您監視 Windows Server 2008 的處理器效能,確認作業系統未拖慢處理器頻率。這種情形會讓您以為 CPU 使用率很高,然而事實上您的 CPU 使用率很低,而處理器只是為了節省電力而調整減速。

效能計數器檢查清單

類別 指標 預期值 目前值

通用效能計數器 (所有 Exchange Server)

Processor% Total

平均應該小於 40 %。

[ ]

System\Processor Queue Length (所有執行個體)

每個處理器不應該大於 5。

[ ]

Network Interface(*)\Bytes Total/sec

如果是 1000-Mbps 的網路介面卡,則應該低於 30-35 Mbps。

[ ]

Mailbox Server 專屬效能計數器

MSExchangeIS Client (*)\RPC Average Latency

平均應該小於 30 毫秒。

[ ]

Process(Microsoft.Exchange.Search.ExSearch)\% Processor time

一般應該小於整體 CPU 的 1%,而且不應該維持高於 3%。

[ ]

MSExchange Store Interface(_Total)\RPC Latency average (msec)

應該永遠小於 100 毫秒。

[ ]

MSExchange Store Interface(_Total)\RPC Requests outstanding

應該永遠為 0。

[ ]

CCR、LCR 和 SCR Mailbox Server 專屬效能計數器

MSExchange Replication(*)\CopyQueueLength

如果是 CCR 和 SCR,應該永遠小於 10。

如果是本機連續複寫 (LCR),則應該永遠小於 1。

[ ]

回到頁首

檢查清單 #2 – 使用者設定檔因素

另外一個判斷您的伺服器是否未充分利用的較省時 (也較不精確) 方法,是採用規劃處理器及記憶體組態 (英文) 中提供的一般調整大小指導方針,對處理器核心和使用者設定檔進行比較。若要判斷組織的使用者設定檔,請參閱該文章中的使用者設定檔表格 (亦轉載於下方供您參考)。

使用者類型 (使用設定檔) 每天大約傳送/接收 50 KB 的郵件大小

基本

傳送 5 封/接收 20 封

平均

傳送 10 封/接收 40 封

大量

傳送 20 封/接收 80 封

非常大量

傳送 30 封/接收 120 封

規劃處理器及記憶體組態 (英文) 中所述,調整大小有個經驗法則,是每 1,000 個使用中平均設定檔信箱需要一個處理器核心。例如,具有平均使用設定檔且有 4,000 個信箱的伺服器,需要 4 個處理器核心。大量使用設定檔需要的處理器循環高於平均設定檔,因此基於規劃用途,請針對每個處理器核心使用 750 個使用中大量設定檔信箱。透過此邏輯,即可歸納出下列檢查清單,查驗需要多少個使用者才能充分利用一個處理器核心:

使用者設定檔因素檢查清單

類別 指標 預期值 目前值

輕量使用者設定檔

建議數目 \ 處理器核心 = 2000

≤1,000

[ ]

平均使用者設定檔

建議數目 \ 處理器核心 = 1000

≤500

[ ]

大量使用者設定檔

建議數目 \ 處理器核心 = 750

≤375

[ ]

非常大量使用者設定檔

建議數目 \ 處理器核心 = 500

≤250

[ ]

因為平均使用者的建議數目是每個處理器核心 1,000 名,因此使用中使用者人數為 500 人或更少的平均設定檔信箱,表示沒有使用者不足以充分利用一個 Mailbox Server 處理器核心。請記住,若是實體 Exchange Server,八個處理器核心是 Mailbox server role 可以有效使用的最大數目 (請參閱規劃處理器及記憶體組態 (英文))。在有 8 個核心以上的伺服器上部署信箱,無法大幅改善延展性。

經由本檢查清單來評估 Mailbox Server 處理器核心的數目,是檢視其他 Exchange 伺服器角色的絕佳起始點,因為 Hub Transport 和 Client Access Server 的 Exchange 基礎結構規劃方法,也有部分是根據 Mailbox Server 的處理器比率 (Mailbox:Hub and Mailbox:CAS)。例如,如果 Hub Transport Server 正在傳輸防毒軟體,則 Mailbox:Hub 伺服器比率為 5:1;如果 Hub Transport Server 未執行傳輸防毒軟體,則此比率為 7:1。因此,如果使用者人數無法充分利用一個 Mailbox Server 處理器核心,則也不可能充分利用 Hub Transport 處理器核心。這項發現也代表支持對 Hub Transport 和/或 Client Access Server 使用虛擬功能。

結論

隨著具 Hyper-V 技術的 Windows Server 2008 以及最近的 Microsoft Hyper-V Server 2008 之發行,部署 Exchange Server 2007 SP1 有了新的選項。在許多情況中,將 Exchange 保留在實體硬體上比起使用虛擬,前者可以提供較佳的管理性和較低的擁有權總成本 (TCO)。然而,某些情形中的虛擬 Exchange 基礎結構可以讓您了解空間、電力和部署彈性方面的優點。

因此您目前硬體未被充分利用的程度就成為關鍵因素,用於判斷虛擬所帶來的好處是否優於在 Exchange 之下加入一層虛擬層所帶來的複雜性。當 Exchange 部署過小以致於無法完全利用基礎伺服器時,虛擬的好處通常在這種時候最能發揮。小型 Exchange 部署、連線能力不佳的遠端站台、某些嚴重損壞修復案例,以及 Mobile LAN 部署都是適用虛擬的極佳範例。

在大部分組織中,Exchange 都是重要的應用程式。在設計虛擬環境時請謹記這點,並遵循 Microsoft 對於虛擬 Exchange Server 的支援原則和建議,您就能成功設定虛擬。

相關資訊