Microsoft Exchange 2010 年：設立虛擬 Exchange 2010 資料中心
規劃和部署虛擬 Exchange 基礎結構時，有一些最佳作法您應該仿效。
柯米。 Posey
伺服器虛擬化已經成為標準，但虛擬化規劃仍是一種藝術形式的東西。 你打算 Exchange 伺服器虛擬化時尤其如此。 你要部署 Exchange 性能和容錯能力，銘記。 添加要挑戰的是大多數 Exchange 伺服器部署跨跨多個伺服器。
您應該注意這裡提出的所有建議都都基於 HYPER-V 虛擬化平臺。 這並不是說你不能使用其他的虛擬化平臺。 官方的 Microsoft 支援政策指出您可以運行 Exchange 管理"任何協力廠商程式，已根據 Windows 伺服器虛擬化驗證程式驗證。"目前，Citrix 系統公司，VMware 公司。 和許多其他虛擬化供應商參與此計畫。
父磁碟分割
當規劃和部署虛擬 Exchange 伺服器基礎架構，很重要分配足夠的資源來父分區 （其中運行管理作業系統）。 未能預留足夠的資源可以影響所有主機伺服器上運行的虛擬伺服器。
Microsoft 建議保留至少 1 GB 的記憶體為父分區和管理作業系統。 如果您在運行 HYPER-V 完整的 Windows Server 2008 或 Windows Server 2008 R2 安裝的頂部，則應考慮保留 2 GB 的記憶體管理，確保作業系統 OS 從來沒有資源消耗殆盡。
Microsoft 還建議私人網路絡介面控制器 （NIC） 管理的目的。 如果您計畫使用即時遷移，您應將 NIC 獻給即時遷移過程。 這是值得注意的微軟不為郵箱伺服器角色支援即時遷移，是否郵箱伺服器是資料庫可用性組 (山) 的成員。
虛擬磁片配置
Exchange 伺服器和 HYPER-V 都非常靈活的存儲資源調配。 即便如此，有一些 Microsoft 推薦的最佳做法有關配置存儲虛擬化的 Exchange 伺服器。
預設情況下，HYPER-V 創建精簡調配虛擬硬碟 (Vhd)。 這就是無論多大你創建你的 VHD，HYPER-V 最初創建一個 VHD 檔，是少於 gb 的大小。 添加資料時，此 VHD 檔動態擴展。
儘管精簡資源調配，可以説明減少佔用的磁碟空間，精簡調配虛擬硬碟不要執行，以及固定長度的磁片中。 在這情況下，Microsoft 建議您對 Exchange 虛擬伺服器使用固定長度只有磁片。
您應該使用的實際磁片配置會有所不同，取決於伺服器角色，但有一些通用的準則，所有伺服器角色為都真。 對於初學者，Microsoft 建議您將一個物理磁片 (LUN) 獻給管理作業系統。 這樣做可以確保作業系統將不能參加與虛擬機器 (Vm) 的磁片資源的管理。
Microsoft 還建議為每個虛擬伺服器上的 OS 提供專門的 LUN。 包含來賓作業系統的 VHD 要足夠大，以存儲 Windows 伺服器和分頁檔。 分頁檔的大小通常是相同的記憶體分配給虛擬機器。
為此，Microsoft 建議是記憶體的給來賓 OS 15 GB，再加上相當於空間分配給虛擬機器量。 因此，4 gb RAM 的 Exchange 虛擬伺服器將從理論上講需要包含作業系統的卷約 19 GB 的磁碟空間。
在開始實際分配磁片資源之前，有幾個需要考慮的事情。 你會發現我沒有提到的 Exchange 伺服器二進位檔案佔用的空間。 15 GB 要求考慮到這。 Windows Server 2008 需要 10 GB 的磁碟空間最少。 預設多 Exchange 伺服器安裝最初消耗約 2.5 GB 的磁碟空間 （它可以更改為您來回移動的東西）。
它仍然是一個好主意，使您的訪客作業系統卷有點大，原因有二。 第一，15 GB 的建議只滿足了 Windows Server 2008 的最小磁片需求。 Windows Server 2008 的系統要求專門推薦 40 GB 或更多。 超過 16 GB 的 RAM 的電腦將需要額外的磁碟空間用於分頁、 休眠和轉儲檔。
未雨綢繆
虛擬伺服器是非常靈活的硬體設定。 您可以添加記憶體上一時興起的虛擬伺服器。 這種情況下，它是開始有較大的 VHD 比你真的需要，所以您可以輕鬆適應未來的記憶體擴展的好主意。 這些建議適用于包含客戶機作業系統和 Exchange 二進位檔案的 VHD。 Microsoft 還建議創建一個或多個附加 Vhd 用於資料存儲。
例如，如果您創建在集線器傳輸伺服器，您想創建輔助 VHD 容納的郵件佇列。 虛擬郵箱伺服器，則應創建兩個額外的 Vhd — — 一個郵箱資料庫和事務日誌檔。
微軟似乎並不強調除外的實際存儲硬體，對郵箱伺服器。 為此，Microsoft 建議使用虛擬 SCSI。 首選的方法涉及使用 SCSI 傳遞，但固定的磁片也可以接受。
Exchange 郵箱伺服器還支援 iSCSI 存儲。 如果您選擇 iSCSI 存儲，Microsoft 建議您配置的 iSCSI 啟動器內管理作業系統，而不是在客戶機上。 Microsoft 支援使用 iSCSI 啟動器在來賓機，但這樣做將取消巨型幀支援。 它還導致較低的性能比你如果在父分區中運行 iSCSI 啟動器。
當您設置 iSCSI 啟動器在父分區中時，可以將連接的 iSCSI 目標向來賓作業系統。 那些應視為直通 SCSI 磁片的 iSCSI 目標配置。
容錯能力
HYPER-V 和 Exchange 2010 年每個提供自己的故障容錯機制。 HYPER-V 支援基於主機的容錯移轉群集。 Exchange 2010 提供了 DAGs。 這些兩個故障容錯解決方案工作方式完全不同，因此很重要的是選擇最適合您的組織的故障容錯解決方案。
如果你熟悉 DAGs，這是 Exchange 2010 機制，在其中可以組合多達 16 個郵箱伺服器到一個組。 您可以將單個郵箱資料庫複製到山的議員，從而保護故障事件中的任何。
相比之下，HYPER-V 基於主機的群集工作通過將多個 HYPER-V 伺服器連結到一個群集共用卷。 主機伺服器發生故障，事件中駐留在故障的主機上的虛擬機器可以故障切換到備用主機。
所以你用哪種容錯解決方案？ 首先考慮的是保護級別每個都提供。 DAGs 提供 Exchange 本機資料保護，提供自動容錯移轉功能在資料庫級別的控制。 為此，DAGs 可以防止伺服器、 網路和資料庫的故障。
基於超 V 主機的容錯移轉群集在虛擬化主機級別運行。 它不是 Exchange 感知的解決方案，所以它不能防止資料庫失敗。 它可以只針對伺服器或網路故障保護。 群集共用卷上的依賴意味著在適當的情況下，共用的存儲可以成為一個單點故障。
雖然這些因素可能會更偏愛使用 DAGs，還有其他注意事項。 一是 DAGs 只能容納郵箱伺服器 — — 他們提供任何其他 Exchange 伺服器的角色不能保護。這並不是說你不能達到某種程度的其他伺服器角色的 Exchange 級容錯能力。 Exchange 將自動使用任何可用的冗余集線器傳輸伺服器。 您可以載入平衡邊緣傳輸伺服器和用戶端訪問伺服器 (CAS) 使用 DNS 輪羅賓的安裝程式，但沒有好交換級解決方案的容錯能力，這些角色。
鑒於非郵箱的 Exchange 伺服器的漏洞，您最好的選擇可能是兩倍。 達格 · 哈郵箱伺服器創建和使用基於主機的容錯移轉群集來保護其他 Exchange 伺服器角色。 不過，實現這種類型不是保護的那麼簡單的。
啟動虛擬化山成員時，您會遇到一些限制。 首先，你不能承載 HYPER-V 伺服器是基於主機的容錯移轉群集的成員上虛擬化的山成員。 交換不會阻止您這樣做，但這不是一個受支援的配置。 事實上，微軟不利於混合 DAGs 和基於主機的容錯移轉群集。
另外一點是你真的不掉了放到單個主機伺服器上的山多個成員。 這樣做會完全破壞山提供的保護。 如果主要伺服器出現故障，主機上的每個郵箱伺服器，也不能。 在此配置中，主機伺服器成為單點故障，有可能迫使整個山離線。
有沒有堅定的 Microsoft 指南關於虛擬化的 Exchange 伺服器的安排，以提供最佳的容錯能力，但有好幾種選擇。 嘗試創建基於主機的容錯移轉群集，並使用它來承載您的邊緣傳輸伺服器和 CAS。 如果您需要提供負載平衡，這些伺服器角色，可以考慮創建額外的基於主機的容錯移轉群集並主辦的邊緣傳輸伺服器和每個分類中的 CA。 你可以使用 DNS 輪羅賓和冗余的 MX 記錄相結合以平衡之間的可用的虛擬伺服器的負載。
您可能已經注意到統一消息沒有提及。 現在，Microsoft 不支援虛擬化統一消息伺服器。 然而，Exchange 2010 SP2 會添加該支援。
您也可以考慮創建非聚集 HYPER-V 伺服器。 每個非群集伺服器應主機郵箱伺服器和集線器傳輸伺服器。 使山成員的每個郵箱伺服器，並創建每個 Active Directory 網站中的至少兩個虛擬的集線器傳輸伺服器。
使用此配置，DAGs 將會防止郵箱伺服器或單個郵箱資料庫失敗。 冗余的集線器傳輸伺服器提供傳輸級冗余。
這種體系結構中缺失的一件事是一個公用資料夾伺服器。 一段時間的微軟一直在說公用資料夾會消失。 如果可以的話，這將開始逐步取消他們很開心。 如果您必須繼續使用公用資料夾，您需要理解為什麼山不能保護公用資料夾資料庫。 為公用資料夾伺服器提供容錯能力的唯一方法是，將公用資料夾複製到多個郵箱伺服器。
正如您所看到的有很多的規劃進入構建虛擬化的 Exchange 基礎結構，與您的硬體設定和容錯能力的主要考慮事項。 牢記這些因素將説明指導您開發固體、 可靠的基礎設施。
.jpg)
**柯米。 Posey**是微軟最有價值的專業和技術與成千上萬的文章和書給他的信用數十個自由撰稿人。 您可以訪問他的網站 brienposey.com。
相關內容