System Center應用控制器與虛擬機管理器模塊協同工作，為虛擬化環境帶來更加強大的控制機制。

在之前的一系列評測中，我們已經對Orchestrator與配置管理器兩大System Center 2012模塊進行了一番探討。但在今天的議題中，我們的研究對象則是應用控制器、虛擬機管理器以及數據保護管理器——它們更為精致，在某些情況下功能也更加強大。

其中最有趣的組合當數新的應用控制器與虛擬機管理器(簡稱VMM)這對搭檔。兩款模塊可謂相得益彰、水乳交融。應用控制器的作用是在設施中部署虛擬機，其應用范圍涵蓋私有云、舊式本地管理環境或者公共云，當然Windows Azure也包括在內。

盡管VMM本身在控制能力上不像Citrix及VMware等工具在自家平臺上表現得那么深入，但用戶可以通過這些微軟管理工具將微軟Hyper-V、Citrix XenServer以及VMware vSphere等來自不同廠商的平臺雜糅成混合型業務環境，從這個角度來看VMM同樣具備很強的存在感。

最后也是最“無聊”的模塊就是數據保護管理器了，之所以說它無聊，是因為數據保護機制是任何一款系統都必不可少的組成部分——但這絕不代表它在功能上馬馬虎虎。數據保護管理器由一系列監控備份組件構成，專為微軟應用及服務器提供保護。盡管缺乏驚喜，但我們仍然高興地發現其中包含的一項新功能：裸機還原。這項功能不僅能幫設備回到初始狀態，更可以幫助用戶在緊急時刻有效減少損失。

上述組件都要通過Unified Installer進行安裝;安裝向導會提醒用戶最好不要單獨安裝這些模塊。與其它System Center 2012應用一樣，它們的運行也需要微軟SQL Server 2008 Review或其它SQL Server的支持(后者作為后備方案)。

在我們的測試中，最具吸引力也最具全局特性的功能要數VMM對Citrix XenServer及VMware vSphere ESXi基礎設施的綜合控制能力。雖然我們已經有Hyper-V，鑒于測試對象是Hyper-V的兩大主要競爭對手，且運行的服務器實例負載相當之高，因此我們還是決定看看VMM的表現。我們還從微軟那里搞來了Azure賬戶，專門用于此次云控制測試。

在準備過程中，我們不得不根據實際情況做出數項調整。舉例來說，我們在戴爾Compellent SAN中托管的大型存儲池采用的是網絡文件系統(簡稱NFS)，但要使用這些資源池，VMM要求我們將資源屬性變更為“可讀寫”——這么干會給我們的工作流帶來安全隱患。然而為了弄清楚VMM 2012的真實水平(并通過應用控制器實現進一步管理)，我們權衡再三還是決定進行修改。

接下來，我們按名稱引導VMM找到我們的Citrix與ESXi管理程序設備;VMM反應神速，很快找到了各種服務器類型下的活躍虛擬機及已經關閉的虛擬機合集。XenServer與VMware所對應的每種資源類型都被啟用，逐步安裝各種相關工具，并針對交互結構調整了虛擬機布局。將活躍虛擬機從一個平臺遷移到另一個并不現實，但在特定情況下將其從一種結構類型中遷移到另一種同類管理程序下則可以實現。

經過我們對概念可行性的驗證，XenServer到XenServer與vSphere到vSphere兩種遷移均獲得了成功。這并不代表像資源匹配及高級存儲池優化等高級管理程序基礎設施功能也行得通，事實證明它們無法正常工作。但我們發現某些簡單功能還是能夠實現的，例如微軟公布的“單窗口面板”控制，它在三套托管著Windows 2008 R2服務器實例的不同管理程序中都能順利起效。

總體來說，概念還是能夠實現的——盡管某些高級功能(尤其是在VMware vSphere方面)仍然無法執行。

VMM 2012還有另一種安裝方案，即通過IIS訪問一套自助門戶。選擇這種安裝方案會給配置工作帶來新的難題，新管理層的介入使我們不得不定義更多角色、配置更多資源。但如此一來我們就實現了通過Web進行虛擬機配置，同時獲得了類似于接入裝置的服務角色，也算是物有所值。

VMM 2012中用于定位虛擬機的內部基礎設施通路大部分處于隱藏狀態，從而實現了對類裝置及應用實例部署的進一步支持。服務通過特定的提供方式幫助用戶自主檢測已經部署完成的裝置或虛擬機合集，但Active Directory用戶角色則必須通過相當復雜的組策略對象登記來接受控制，這就要求我們對自助門戶進行嚴格管理以避免濫用情況的發生。

應用控制器則將資源(包括公共或者私有托管下的資源)分割后分配到設施內部。我們通過微軟提供的Azure賬戶進行了虛擬機實例由私有網絡向Azure實例遷移的測試，結果發現只要完成初始設定(包括Azure證書、密鑰以及網絡連接)，就可以通過拖拽的方式輕松把虛擬機實例資源從本地遷移到Azure資源端。這種做法的缺點在于需要占用大量網絡流量，由此帶來的成本要高于在Azure尤其是SQL Server中直接建立實例。

應用控制器還能夠將虛擬機群組打包成一個對象，以實現對多個虛擬機實例的管理目的，例如由幾臺網絡服務器及一套數據庫或服務應用后端所構成的完整環境。應用控制器與PowerShell命令也能夠順利協作，通過腳本的方式將多種管理指令整合在一起，實現添加及刪除用戶角色等過程的自動化全局操作。

Shell腳本可以無限次重復使用，使頻繁點擊UI的操作實現自動化。但缺點在于不同PowerShell腳本多少有些自文檔化，其代碼可能并不符合標準化最佳實踐，進而導致應用控制器對這些腳本產生依賴性。

除此之外，我們還可以通過Windows部署服務(簡稱WDS)在裸機中部署虛擬機。該功能借助PXE(即預啟動執行環境)從根本上實現了虛擬機通過本地網絡的全面部署。依照程序，一套虛擬機在被激活后會向DHCP服務器發出PXE信號，而服務器則反過來根據設置將事先選定的鏡像加載到虛擬機當中。這項功能必須在本地網絡中實現(而且據我們得到的消息，僅支持IPv4);當然，大家也可以對路由器進行編程來將初始PXE流量發送至其它目的地，進而完成虛擬機的網絡啟動請求。初始化完成后，服務器即可通過各種途徑訪問并加載其它應用程序或者資源本身。

總體而言，我們經常通過修改虛擬硬盤(簡稱VHD)將虛擬機鏡像遷移至PXE啟動服務器(簡稱WDS)——但就喜好來說，我們更傾向于利用實驗室中的NFS，它對于各種操作系統的良好支持讓裸機有了更多選擇。

應用控制器2012與VMM 2012的組合相當強大，而且能夠以非常簡潔的方式將所有受控制資源合并到System Center 2012當中。我們并不認為該組合會替代現有產品中的同類功能，而且Windows Server 2012各版本的推出與System Center 2012服務包的發布也會讓這兩款功能性模塊迎來新的改變。很多原本費時費力的虛擬機及其管理成本問題都會隨著新版本的出爐而得到解決。#p# 

System Center 2012數據保護管理器(簡稱DPM)

DPM的此次升級版本更專注于對微軟應用的處理，例如SharePoint服務、SQL Server以及Exchange等。隨著磁帶這一分級存儲方案的逐漸落伍，我們終于能夠擺脫令人頭痛的磁帶存儲測試，進而更輕松地在實驗室中研究SAN存儲。

合規性、監管機制及訴訟支持已經成為企業在面對在線聯機檢索事務時的首要訴求。DPM在對應用程序的“行為”記錄方面表現出色，當然僅限于微軟應用。DPM目前還無法擴展到其它操作系統或文件系統當中。

根據流程，DPM會首先分配保護組，然后分配存儲池。DPM存儲池也可以采用自定義分卷分配。微軟公司建議用戶將存儲池的大小設定為需要“保護”的數據量的兩倍。我們可以建立數據恢復點，但每個對象的總恢復點數量不能超過64個——這一限制不針對應用數據，僅僅約束快照恢復點的最大數量。根據系統規劃指南上的說明，我們每一天可以為每個保護組設定八個計劃恢復點，這個數量還是比較合理的。

微軟建議每臺DPM服務器的最大數據快照存儲數量不要超過9000個，這些快照可以來自客戶端、服務器或者基于服務器的各類應用程序。官方推薦用戶根據變量公式計算需要保留的磁盤空間，具體情況要看企業數據的變動頻率以及網絡結構中檢索活動跨越所帶來的速度限制。我們還發現，微軟針對各類用戶在備份、檢索、恢復等方面的需要給出了一系列建議，大家需要以實際情況為基礎決定使用什么樣的組合、存儲、網絡及頻率以滿足可用性及數據恢復方面的要求。

我們強烈建議大家利用Unified Installer進行DPM及其它System Center 2012模塊的安裝，SQL Server 2008 R2同樣不可或缺。事實上，我們嘗試的第一個備份項目就是SQL Server 數據庫。盡管數據庫及表單的體積并不大，但設置過程還是要比單純拷貝慢得多。

我們在Compellent SAN中單獨劃分出一部分作為SQL Server R2的iSCSI目標，以作為測試之用。在五天的檢測過程中，我們發現DPM 2012的保護政策會自動保留五個快照文件。如果需要，這些快照的生成時間可以設定在業務不太繁忙的時段，但我們根據建議花了15分鐘進行增量同步。

由于我們的測試環境并不繁忙，因此流量測試在最低強度下逐步執行。為了充分利用本地網絡流量優勢，企業用戶可以根據需要添加額外的DPM服務器;但在SQL Server流量過大或者連接到DPM服務器的存儲類型過多時，大家恐怕也得再加幾臺設備。

某些企業能夠容忍同線路傳輸及網絡iSCSI流量，但對于其它一些希望SAN設施專物專用或者對DPM存儲連接速度要求極高的企業而言，似乎還需要更好的解決方案。微軟公司建議用戶在通過廣域網連接使用DPM時保持至少512Kbps的帶寬，但除非這條鏈接專門用于DPM傳輸或者數據傳輸量極小，否則必然會面臨嚴重的數據堵塞。

在實驗室中，我們利用3Mbps的網絡連接通過DPM實例對一套Windows 7虛擬機及一臺筆記本中的數據進行備份，傳輸目標則是位于70英里之外的網絡運營中心。兩套備份內容的數據量都在21GB上下。運營中心里使用的主機是惠普DL 580、16核心處理器、兩套虛擬機實例并與另一套SQL Server和閑置System Center 2012模塊相連通。而在實驗室中，我們使用的是戴爾Compellent SAN——前面已經提到過了。

在單獨運行的情況下，DPM在完整備份Windows 7實例工作上花費了94分鐘。接著是對兩套內容的同時備份，耗時為109分鐘。同時進行三個備份任務的成績為126分鐘。最后，我們同時開啟四個備份任務的總計耗時為177分鐘，這時候實驗室里幾乎所有有用的信息都被備份了一遍。

大家也可以把網卡整合起來為DPM服務，不過因為帶寬有限，這樣做對于我們的廣域網連接性能并不會帶來什么提升。但在其它比較強力的千兆以太網LAN環境中或者DPM所在的服務器場附近，把網卡“組隊”的主意還是很有價值的。

數據保護管理器2012的運作方式比其它System Center 2012模塊更加自主，不過它的存在就是一種額外的負擔，所以獨立出來也很正常。當然，對于大多數管理員來說，獨立存在的備份機制令人頭痛而且極為無聊——但也沒有辦法。

這種與其它模塊間的集成化欠缺使得數據保護管理器的使用方式也與應用控制器加VMM的組合有所不同。我們無法針對任何模塊直接理解其備份機制、需要注意的恢復點以及其存在的理由。然而拋開集成不談，DPM在微軟自家的系統結構中所承擔的工作確實枯燥而繁重。正如其它模塊一樣，DPM要求管理員根據各類Windows系統流程及自身需求做出規則，進而將恢復、存儲池、網絡流量、虛擬機池以及流程對象等全部內容涵蓋在保護之下。

裸機恢復早在Windows 2008系列版本中也得到了支持，但支持系統狀態保護快照的Windows XP到2003則不具備此功能(我們仍在檢測2003 R2的支持能力)。為了實現裸機恢復，我們利用新保護組創建向導在受保護服務器組中添加了一臺額外的測試服務器。

復制/備份分卷擁有額外的存儲空間，默認為30GB，并可根據需要進一步添加。參照官方的說明，已經設定好的額外空間也可以隨時變更，但我們的測試很簡單：拿出準備好的Windows 2008 R2服務器實例并通過裸機恢復將其安裝到新設備當中。這時會出現向導程序，允許我們選擇需要的備份文件，幾下點擊、一杯咖啡，恢復工作就結束了。

總結

在本次測試中，我們只在PowerShell版本中使用了獨立的命令操作，而沒有將其整合到腳本當中。之所以回避腳本，是因為我們害怕搞錯標簽或者把它們弄丟。腳本命令在帶來強大操作便捷性的同時，也需要管理員進行更嚴格的控制。也許腳本生成器會把它們放在元數據中以便于調用，但這無疑會給測試帶來難以預估的影響。

System Center 2012雖然可以進行最小化部署，但每位用戶都不應該與其卓越的功能模塊失之交臂，更何況最小化方案還會給重復安裝帶來其它麻煩。在微軟基礎設施(尤其是Hyper-V云)上砸下大筆資金的中型乃至大型企業會很快發現應用控制器與VMM 2012這一組合將成為業務流程中不可或缺的至寶。

System Center 2012軟件包囊括了非常全面的控制機制(包括Orchestrator與配置管理器組件，二者都能被數據保護管理器的備份功能所覆蓋)，用戶根本不可能在缺乏詳細規劃及培訓順利適應其強大功能。根據官方的建議，服務器的最低數量為九臺;不過我們完全可以將它們通通納入同一套虛擬服務器當中(需要DPM實例)。而且還要再次強調，雖然這是一套專為Windows量身訂做的控制方案，但在其它各系統平臺上的表現同樣可圈可點。

原文鏈接：

http://www.networkworld.com/reviews/2012/092412-microsoft-system-center-test-262332.html