虛擬化毋庸置疑地為企業IT帶來了舉不勝舉的好處——成本節約、系統整合、資源利用效率提升、管理能力改善——但是要記住重要的一點,支持業務需求才是IT部門存最重要的工作。在不進行詳細分析與考量的情況下,就對所有的系統進行虛擬化,并不是一個好策略。
任何虛擬化戰略的第一步,都應該包括如何處理預想中的災難恢復——如果CIO把所有內容都放在一個處于開放環境下的容器里。那就想象一下如果整個環境宕機的話需要怎么做——網絡設備、動態目錄域控制器、郵件服務器等等。假如管理員已經設置了將會把自己鎖定在系統管理權限之外的循環依存項的話,會發生什么?再例如,如果配置VMware vCenter管理服務器依賴于動態目錄進行身份驗證的話,只要有一個可用的域控制器它就可以正常工作下去。但是,如果虛擬化域控制器出現故障,問題就來了。當然,也可以為vCenter設置一個本地登錄帳戶,或者在虛擬系統和物理系統之間分割域控制器,但是上述情況是一個很好的例子說明如何有可能會讓CIO自己陷入困境當中。
以IT自由撰稿人Scott Matteson的經驗,很多東西并不那么適合于虛擬化環境,以下是其羅列出應該保留在物理環境中的10項內容:
1、 任何帶有或要求帶有加密鎖的物理硬件
這一點毫無疑問,而且被無數次地重復,但這就像是消防安全提示一樣,只因為它就是一個口號而顯得并不那么重要。不管你相信與否,現在仍然有一些項目仍然要求有附加的硬件(例如加密鎖)。某些項目許可要求有這種硬件才能正常工作(為了防止盜版)。
舉個具體例子:一個客戶的HVAC系統運行在一個很老的臺式機上。加熱和冷卻的程序要求使用一個串行連接的加密鎖以監控溫度和風扇等。我們嘗試在VMware ESXi 4.0環境中虛擬化這套系統,使用串行端口實現直通,甚至是使用USB適配卡,但不管用。(聽說這種功能在ESXi 5中是起效的)諷刺的是,使用VMware工作站而不是ESX環境(允許直通功能)的時候,這種方法起到了很好的作用。但是在PC上托管虛擬機時候作用不大,因此需要對物理系統重新做了遷移。
這條規則也適用于像防火墻這種使用ASIC(應用專用集成電路)以及使用GBIC(千兆接口轉換器)這樣的網絡設備。目前還沒有找到關于這些如何切換到虛擬環境的相關信息。即使能找到到些東西可以讓它工作起來的話,冒著宕機的風險和管理難題、做這種一次性的設置真的就值得嗎?
2、 要求極高性能的系統
占用RAM、磁盤I/O以及CPU(或者要求有多個CPU)的計算機或者應用,也許并不是虛擬化的理想選擇。這種例子包括,視頻流、備份、數據庫和事務處理系統。因為這個原因,在日常工作中都應將其視為物理設備。但是一個運行在主機系統一個層中的虛擬程序或者虛擬機,總會因為所涉及的開銷而在某種程度上犧牲性能,而且在物理環境下這種犧牲很可能被均衡了。
CIO也許會嘗試使用一臺只運行一個程序的主機或者服務器專門解決這個問題,但是這就折損了虛擬化允許你在一個專用物理服務器上運行做個圖像的優勢。
3、 不允許進行虛擬化的帶有許可或支持協議的應用及操作系統
這一點是不言自明的。在進行虛擬化之前,CIO應檢查一下許可和支持協議,然后可能會發現只根據這個協議是無法做到虛擬化的,或者假如繼續下去的話,當遇到需要電話支持的時候就會出現一些問題。
如果這是一個例如打印銘牌這樣的小程序的話,支持協議不包括(或者未提及)虛擬化版本,CIO就需要權衡風險再決定是否繼續進行。如果是任務關鍵型應用的話,那么還是保留在物理環境中吧。
4、 任何沒有經過測試的關鍵任務
如果沒有在虛擬平臺上做過測試的話,就不要急于遷向虛擬化。即使需要花費時間,也要先測試了再說。對源進行拷貝,然后制定測試計劃,確保所有程序或者服務器如預期的運轉。如果需要的話,在下班時間進行這一切。畢竟,在晚上11點發現問題總比在早上9點強。將原始源代碼保持離線(僅僅是關掉,但不要斷開/刪除/卸載),直到確保如預期那樣朝著新目標進發。
5、物理環境所依賴的東西
對于任何虛擬機來說,有兩個故障點——虛擬機本身和它的主機。如果有軟件運行在這樣一種虛擬機上:在一套讀取器上刷卡之后可以解鎖辦公室的門,那么只有當虛擬機和母系統都是處于正常運準的情況下才能允許操作。
想像一下星期一早上8點,辦公室外面站著一大群人,“門禁卡不管用了!”CIO會推測是系統中的某一環出現了問題?,F在怎么辦?管理者會希望主密鑰不是放在了數據中心的密碼箱里,否則就會打電話給安全軟件供應商了。
6、任何虛擬環境所依賴的東西
就如開篇部分所提到的,一旦發生不可避免的宕機情況,循環依賴(如虛擬域控制器被要求登錄到虛擬環境中)就會將系統置于極大的風險之中——就算處在集群和冗余環境中,這一天也會到來的。在這里,電力是一個很大的影響因素。如果像Scott Matteson一樣居住在美國東北部的話,就一定也同樣經歷了過去五年中次數不斷增多的停電事故。
把這一條從前一條中單獨拿出來,是因為這需要不同的思考方式。有鑒于CIO需要構想出物理環境的布局,以保持攝像機的正常運行,這需要設計出個性化的虛擬環境,包括主系統、虛擬映像、認證、網絡、存儲甚至電氣連接。將每一個條目從這個集合中拿出來,隨后設想一下會產生什么樣的影響。設置冗余物理環境(例如另一個域控制器)來保護基礎設施。
7、任何必須要保證安全的內容
這條與第5條有些許不同。如果對任何含有管理者不想讓其他員工接觸到的安全信息的系統進行虛擬化,也許就會構成一定安全風險。管理者可以在虛擬機器上設置訪問許可,防止其他人能夠進行控制,但是如果那些員工有能力控制主機系統,那么這種控制手段也許就被規避了。他們也許依然能夠在任何地方復制VMware文件,進行關閉服務器等操作。
這一點并不是說CIO應該懷疑自己的IT員工,但是應該制定指導準則或規則制度,禁止除IT團隊之外的任何人涉及對相關程序/數據/操作系統的控制權限。
8、任何對同步有時間點要求的東西
在虛擬環境中進行時間同步——例如,VMware可以通過VMware工具應用同步虛擬機器與主ESX Server的時間,當然操作系統自身也可以進行時間同步配置。但是如果操作系統出現遺漏,或主ESX Server的時間是錯誤的會發生什么呢?曾經,一組虛擬鏡像必須要有GMT(格林威治標準時間),其處理軟件才能運行,但是EXS主機時間是錯誤的,這著實引發了一陣令人沮喪的折騰,以及試圖分析出虛擬系統時間錯誤原因的工作。
通過確保所有物理主機使用NTP將時鐘標準化,這個問題可以得到控制,但是錯誤依然會發生,重啟后設置會丟失或遺忘。在其他場合,這個問題已經在數個VMware EXS領域中發生,例如在安裝補丁之后。如果系統必須絕對得到正確的時間,將其置于虛擬化環境之外也許是個更好的選擇。
9、正常運行的桌面機
在推進VDI(虛擬桌面基礎架構)的過程中,一些公司可能會有些頭腦發熱地將“應該虛擬化的東西”理解為“任何東西都可以虛擬化”。如果辦公室里有不少用了兩三年的個人電腦,就不要浪費時間將它們轉變為VDI系統,并用瘦客戶端來替代他們了。這種作法不會產生任何收益或節省開支,事實上這是對虛擬化的無效濫用。
10、任何已經一團糟或無法挽救的東西
很多人將物理設備轉變為虛擬機,隨之它就可以被復制或存儲了。在某些情況下,這種做法是有用的,但是在其他特殊情況下,這種做法實際上只是讓一些雜亂無序的舊操作系統維持了更長的使用時間而已,它們早已超過了應有的使用期限。例如,一個已經使用了幾年的Windows XP電腦被轉換成了虛擬鏡像。照這種情況來說,該系統已經歷了無數次的軟件升級、刪除內容等操作。又有幾年過去后(以及伴隨著更多的系統變更),無疑的是,現在這個XP系統將表現出嚴重的CPU過載及反應時間過慢等問題。其實,更好的決策是從頭創造一個全新的映像,并以有序方式安裝必要軟件,而不是讓這個千瘡百孔的操作系統轉為一個虛擬系統重新上線。
這同樣適用于那些稱之為“令人傷感”的東西。公司服務器上的標簽打印軟件是不是已有15年的時間沒換過了?將它丟掉然后說再見吧。不要受潮流誘惑將其轉為虛擬機器以防萬一(突然發現“以防萬一”算得上IT界同時最有用也最有害的三個詞之一了),除非它根本不可能被其他軟件替換掉。但是,如果是這種情況,請不要忘記回去查看本文第3條。
物理機托管虛擬系統
加入這條是為了提醒CIO們,必須做好購買物理硬件的準備,并要了解服務器的規格、性能、存儲需求、網絡連接性能,以及其他能讓服務器——隨之是虛擬系統——保持在巔峰狀態的細節問題。CIO要確保明白主機所需求的東西和映像所求的東西之間的差異和分歧,并持續關注虛擬化服務商所提供的最新升級。
結論
隨著歲月變遷,這些規則也會發生變化。對于計劃在物理和虛擬計算中取得最佳平衡的問題來說,好的說明性資料、訓練和對環境的深入了解是至關重要的。虛擬化是個好東西。但是如果物理主機出現宕機,其影響會是致命的——這甚至可能會讓人渴望回到“每項功能一個物理服務器”的時代,仔細分析一下怎樣做會對公司和用戶有用,并決定用何種最佳的方式解決可能會出現的突發問題吧。