不適合虛擬化的10個專案

jinqibingl發表於2016-04-25

不適合虛擬化的10個專案

來源地址: 

不適合虛擬化的10個專案

日期:2013-8-21 來源:

導讀:本文盤點應該保留在物理環境中,而不應該用於虛擬化的10項內容。

關鍵詞: 

虛擬化毋庸置疑地為企業IT帶來了舉不勝舉的好處——成本節約、系統整合、資源利用效率提升、管理能力改善——但是要記住重要的一點,支援業務需求才是IT部門存最重要的工作。在不進行詳細分析與考量的情況下,就對所有的系統進行虛擬化,並不是一個好策略。

任何虛擬化戰略的第一步,都應該包括如何處理預想中的——如果CIO把所有內容都放在一個處於開放環境下的容器裡。那就想象一下如果整個環境當機的話需要怎麼做——網路裝置、動態目錄域控制器、郵件伺服器等等。假如管理員已經設定了將會把自己鎖定在系統管理許可權之外的迴圈依存項的話,會發生什麼?再例如,如果配置管 理伺服器依賴於動態目錄進行身份驗證的話,只要有一個可用的域控制器它就可以正常工作下去。但是,如果虛擬化域控制器出現故障,問題就來了。當然,也可以 為vCenter設定一個本地登入帳戶,或者在虛擬系統和物理系統之間分割域控制器,但是上述情況是一個很好的例子說明如何有可能會讓CIO自己陷入困境 當中。

以IT自由撰稿人Scott Matteson的經驗,很多東西並不那麼適合於虛擬化環境,以下是其羅列出應該保留在物理環境中的10項內容:

1、任何帶有或要求帶有加密鎖的物理硬體

這一點毫無疑問,而且被無數次地重複,但這就像是消防安全提示一樣,只因為它就是一個口號而顯得並不那麼重要。不管你相信與否,現在仍然有一些專案仍然要求有附加的硬體(例如加密鎖)。某些專案許可要求有這種硬體才能正常工作(為了防止盜版)。

舉 個具體例子:一個客戶的HVAC系統執行在一個很老的桌上型電腦上。加熱和冷卻的程式要求使用一個序列連線的加密鎖以監控溫度和風扇等。我們嘗試在 VMware ESXi 4.0環境中虛擬化這套系統,使用串列埠實現直通,甚至是使用USB適配卡,但不管用。(聽說這種功能在中是起效的)諷刺的是,使用VMware工作站而不是ESX環境(允許直通功能)的時候,這種方法起到了很好的作用。但是在PC上託管虛擬機器時候作用不大,因此需要對物理系統重新做了遷移。

這 條規則也適用於像防火牆這種使用ASIC(應用專用積體電路)以及使用GBIC(千兆介面轉換器)這樣的網路裝置。目前還沒有找到關於這些如何切換到虛擬 環境的相關資訊。即使能找到到些東西可以讓它工作起來的話,冒著當機的風險和管理難題、做這種一次性的設定真的就值得嗎?

2、要求極高效能的系統

佔 用RAM、磁碟I/O以及CPU(或者要求有多個CPU)的計算機或者應用,也許並不是虛擬化的理想選擇。這種例子包括,影片流、備份、資料庫和事務處理 系統。因為這個原因,在日常工作中都應將其視為物理裝置。但是一個執行在主機系統一個層中的虛擬程式或者虛擬機器,總會因為所涉及的開銷而在某種程度上犧牲 效能,而且在物理環境下這種犧牲很可能被均衡了。

CIO也許會嘗試使用一臺只執行一個程式的主機或者伺服器專門解決這個問題,但是這就折損了虛擬化允許你在一個專用物理伺服器上執行做個影像的優勢。

3、不允許進行虛擬化的帶有許可或支援協議的應用及作業系統

這一點是不言自明的。在進行虛擬化之前,CIO應檢查一下許可和支援協議,然後可能會發現只根據這個協議是無法做到虛擬化的,或者假如繼續下去的話,當遇到需要電話支援的時候就會出現一些問題。

如果這是一個例如列印銘牌這樣的小程式的話,支援協議不包括(或者未提及)虛擬化版本,CIO就需要權衡風險再決定是否繼續進行。如果是任務關鍵型應用的話,那麼還是保留在物理環境中吧。

4、任何沒有經過測試的關鍵任務

如 果沒有在虛擬平臺上做過測試的話,就不要急於遷向虛擬化。即使需要花費時間,也要先測試了再說。對源進行複製,然後制定測試計劃,確保所有程式或者伺服器 如預期的運轉。如果需要的話,在下班時間進行這一切。畢竟,在晚上11點發現問題總比在早上9點強。將原始原始碼保持離線(僅僅是關掉,但不要斷開/刪除 /解除安裝),直到確保如預期那樣朝著新目標進發。

5、物理環境所依賴的東西

對於任何虛擬機器來說,有兩個故障點——虛擬機器本身和它的主機。如果有軟體執行在這樣一種虛擬機器上:在一套讀取器上刷卡之後可以解鎖辦公室的門,那麼只有當虛擬機器和母系統都是處於正常運準的情況下才能允許操作。

想像一下星期一早上8點,辦公室外面站著一大群人,“門禁卡不管用了!”CIO會推測是系統中的某一環出現了問題。現在怎麼辦?管理者會希望主金鑰不是放在了資料中心的密碼箱裡,否則就會打電話給安全軟體供應商了。

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要確保明白主機所需求的東西和映像所求的東西之間的差異和分歧,並持續關注虛擬化服務商所提供的最新升級。

結論

隨 著歲月變遷,這些規則也會發生變化。對於計劃在物理和虛擬計算中取得最佳平衡的問題來說,好的說明性資料、訓練和對環境的深入瞭解是至關重要的。虛擬化是 個好東西。但是如果物理主機出現當機,其影響會是致命的——這甚至可能會讓人渴望回到“每項功能一個物理伺服器”的時代,仔細分析一下怎樣做會對公司和用 戶有用,並決定用何種最佳的方式解決可能會出現的突發問題吧。

Topics: 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9606200/viewspace-2088052/,如需轉載,請註明出處,否則將追究法律責任。

相關文章