Exchange 2010 SP1 虛擬化大解惑

[アーティクル]
12/06/2011

英文原文已於 2011 年 10 月 11 日星期二發佈

自我們公告 Exchange 2010 虛擬化支援聲明的一些重大變更至今，已過了幾個月 (請參閱公告 Exchange 2010 的增強型硬體虛擬化支援 (可能為英文網頁))。在這段期間，有不少人提出了一些很好的問題，詢問關於特定部署方案，以及支援聲明變更對該部署的影響。有鑑於問題數量眾多，現在正是我們公佈一些其他資訊並釐清問題的好時機。

首先讓我說明一下事情的來龍去脈。我們變更支援聲明的主要原因，是想要確保我們的客戶不會因為使用了虛擬化部署，而導致 Exchange 服務的可用性降低。換句話說，我們想要確保透過虛擬平台的部署 Exchange 2010 產品，和透過實體部署一樣能達到高度的可用性。當然，我們還必須確定產品運作皆正常，並再三確認虛擬化堆疊提供的其他功能，在正常作業期間不會遺失任何 Exchange 的資料。

基於以上幾點，讓我們大致瀏覽一下這些變更，以及它們所造成的影響。

部署了 Exchange 2010 SP1 (或更新版本) 以後：

虛擬機器中將支援所有 Exchange 2010 伺服器角色 (包括 Unified Messaging)。

Unified Messaging 虛擬機器的特殊需求如下：

虛擬機器需要四個虛擬處理器。記憶體大小應符合標準最佳作法指南的要求。

每個擔任 Unified Messaging 角色的虛擬機器，都必須有四個可用的虛擬處理器核心隨時待命。此需求代表處理器無法超額配置。此需求會影響擔任 Unified Messaging 角色的虛擬機器使用實體處理器資源的能力。

Exchange 伺服器虛擬機器 (包括屬於 DAG 的 Exchange 信箱虛擬機器) 可以與主機型容錯移轉叢集和移轉技術合併，只要虛擬機器設定為不會在移動或離線時儲存和還原磁碟上的狀態即可。在目標節點上啟動虛擬機器時，所有容錯移轉活動最後都必須進行冷開機。所有規劃的移轉最後都必須進行關機和冷開機，或是使用 Hyper-V 即時移轉這類技術進行線上移轉。虛擬機器的 Hypervisor 移轉服務是由 Hypervisor 供應商所提供；因此，您必須確定 Hypervisor 供應商已測試過，並支援 Exchange 虛擬機器的移轉。Microsoft 支援這些虛擬機器的 Hyper-V 即時移轉。

讓我們查看一些定義，以確保我們對支援聲明中的術語有一致的理解。

冷開機這指的是將系統從關閉電源狀態進入直接從作業系統啟動的動作。在此情況下，不會保留作業中的系統狀態。
儲存的狀態關閉虛擬機器的電源時，Hypervisor 一般可以儲存虛擬機器在該時間點的狀態，因此，電腦在重新啟動時會回復為該狀態，而不是進入「冷開機」啟動。「儲存的狀態」會是 Hyper-V 中的「儲存」作業結果。
規劃的移轉系統管理員著手進行將虛擬機器從某部 Hypervisor 主機移至另一部 Hypervisor 主機的作業時，我們稱之為規劃的移轉。這可以是單次移轉，或是系統管理員可以設定一些自動化程序來定時移動虛擬機器，或設定當系統內發生某些事件 (非硬體或軟體失敗) 時，自動移動虛擬機器。這裡的重點是當 Exchange 虛擬機器已正常運作，而因為某種原因必須放到其他地方時 (可透過即時移轉或 vMotion 這類技術)，如果 VM 所在的 Exchange 虛擬機器或 Hypervisor 主機發生某種失敗情況，則結果將不會是破壞性的。

虛擬化 Unified Messaging Server

我們所作的其中一項變更是增加 Hyper-V 和其他已支援 Hypervisor 上的 Unified Messaging 角色支援。如本文一開始所提及，我們想要確定任何對支援聲明進行的變更都能保持產品功能完整運作，並提供使用者最佳的服務。因此，我們要求 Exchange Server 2010 SP1 必須要能支援 UM。原因很簡單。UM 角色必須依賴 Microsoft Lync 團隊提供的媒體元件。在發行 Exchange 2010 SP1 之前，我們的 Lync 合作夥伴已先進行了一些作業，以啟用虛擬部署中的高品質即時音訊處理，而在發行 Exchange 2010 SP1 時，我們更將變更一併整合進 UM 角色。完成之後，我們還做了一些額外測試，確定使用者將擁有最佳的使用經驗，才修改支援的聲明。

您可能會注意到，我們對執行 UM 之虛擬機器的 CPU 設定 (和 Hypervisor 主機) 有其特定需求。這將再次確保不會發生不良的使用經驗 (如語音品質低劣)。

主機型容錯移轉叢集和移轉

Exchange 2010 DAG 變更後的支援聲明中，有關主機型容錯移轉叢集和移轉技術組合詳細資料，造成了不少混淆。此處的指南其實相當簡單。

首先，讓我們談談我們是否支援第三方移轉技術 (如 VMware 的 vMotion) 這個問題。Microsoft 無法針對使用這些技術的第三方 Hypervisor 產品與 Exchange 2010 之整合作出「支援」聲明，因為這些技術不屬於伺服器虛擬化驗證方案 (可能為英文網頁) (Server Virtualization Validation Program, SVVP) - 當中涵蓋我們對第三方 Hypervisor 之支援的其他層面。我們在此處作出的支援聲明是通用的，但您必須要確定 Hypervisor 供應商支援其移轉/叢集技術與 Exchange 2010 的組合。簡單一句話：如果您的 Hypervisor 供應商的移轉技術支援 Exchange 2010，則我們的 Exchange 2010 也就支援他們的移轉技術。
其次，讓我們談談如何定義主機型容錯移轉叢集。這指的是任何能在主機層失敗時自動作出反應，並在替代伺服器上啟動受影響之 VM 的技術。我們提供的支援聲明內絕對支援使用此技術，有鑑於它能在出現失敗方案時，將 VM 在替代主機上冷開機啟動。我們希望確保 VM 絕不會從磁碟上保存的已儲存狀態啟動，因為它相對於 DAG 成員的其他成員已「過時」。
再者，當支援聲明中提及移轉技術時，我們所說的是任何可將 VM 從某部主機移至另一部主機的技術。此外，它可以是一項自動化作業，可啟動進行資源負載平衡 (但與系統中的失敗無關)。只要 VM 絕不會從磁碟上保存的已儲存狀態啟動，就一定會支援移轉。這表示 Exchange 2010 可搭配使用透過網路傳輸狀態和 VM 記憶體來移動 VM 的技術，而不會出現可察覺的停機時間。請注意，第三方的 Hypervisor 供應商必須支援移轉技術，而 Microsoft 會在此設定中使用 Exchange 時提供其支援。以 Microsoft Hyper-V 為例，這代表可支援即時移轉，而不支援快速移轉。

關於 Hyper-V，有一項重點必須注意，預設在 VM 上選取「移動」作業時，所執行的事實上是快速移轉。若要保持與 Exchange 2010 SP1 DAG 成員的支援模式，您必須依照下方顯示的 VM 設定，對該行為進行調整 (此處顯示的設定為部署 Hyper-V 的正確方式)：

圖 1：針對資料庫可用性群組成員的正確 Hyper-V 虛擬機器行為