在考慮虛擬化環境時，時代特色造就了一種新趨勢，即將極為豐富的資源賦予一套單獨的物理服務器、并以此為基礎支持海量虛擬機系統。然而需要注意的是，硬件故障這一古老難題目前仍無法徹底扼制，將大量業務系統交給同一套設備負責往往令停機事件的影響范圍急劇擴張、最終徹底粉碎我們那樂觀但卻不切實際的理論規劃。

　　我們并不是說為一臺物理服務器配備128GB、256GB甚至是1TB的內存，16到48個CPU核心以及一系列10G接口有何不妥。這樣級別的強大服務器能夠很輕松地同時運行幾十套甚至上百套(取決于具體工作負載)虛擬機系統。在它的幫助下，我們完全可以把2004年需要三臺1U物理服務器機架才能搞定的處理任務交給如今的一臺1U服務器，而這確確實實是一場了不起的計算資源革命。但與此同時，這樣的趨勢也相當危險。由于系統密度的不斷走高，服務器一旦在特定情況下發生故障，那么其產生的嚴重后果遠大于九年前一臺1U服務器所帶來的影響。然而出于某種原因，這類風險一直沒能在虛擬化設施創建工作中受到足夠重視。

　　事實上，很多小型或中型企業都完全可以在一臺現代服務器上運行所有業務任務并實施服務器操作。只要業務虛擬機的總數量在四十到五十之間，那么單服務器支持是完全可行的。大多數企業會額外添加一臺服務器用于負載平衡及故障轉移，因此我們相當于是在四塊CPU、任意數量的內存以及四套供電設置下運行整個業務體系。這無異于回到了大型機時代，只不過基礎設施擁有RAS(即可靠性、可用性及可維護性)特性。內部系統故障、電源問題、系統升級等狀況都可能導致服務器無法運作，如此一來我們將不得不重新使用單一設備來滿足幾十套虛擬機系統的資源需求。

　　從積極的方面來看，這種情況并不多見；但從消極的角度分析，這種情況一旦出現很可能造成災難性的后果。最近一段時間，我發現很多技術團隊都喜歡把盡可能多的虛擬機系統塞進盡可能少的物理服務器當中，然后心滿意足地“打完收工”。其實更理想的解決方案在于降低單臺服務器中的資源分配，并將更多物理系統加入到整體設施當中。

　　誠然，授權許可成本算是造成這種現狀的重要原因。由于很多虛擬化框架許可都會按CPU及內存數量來計費，因此部署八套低配置服務器所帶來的許可成本要遠高于部署四套高配置服務器。然而極力壓榨物理平臺資源的做法必然導致我們失去了處理停機及物理服務器故障的能力。我們不會利用RAID 1來部署主線存儲機制，但很多雙服務器方案其實在本質上并無不同，都是在盡量壓縮設備數量。

　　我們經常聽到廠商宣揚現代服務器硬件擁有如何可觀的可靠性及資源彈性，冗余系統如何普及到從供電裝置到虛擬機管理程序的方方面面，我們又可以如何通過減少設備數量、提高設備配置來降低許可費用、能源消耗以及冷卻成本。但無論大家的基礎設施硬件“彈性”有多強，故障都是必定會出現的，這只是時間問題。

　　最典型的例子就是文件系統會在特定LUN鎖定服務器中的I/O子系統時出現故障，這時其它物理服務器中的虛擬服務器也可能會受到影響。這些受影響的服務器可能至少需要重啟或者從備份中恢復丟失或受損的虛擬機系統。一旦其它某些設備也出現狀況，管理人員面臨的壓力會更大，因為整套部署設施都面臨著極大危險。然而隨著服務器數量的增加，危險系數也將隨之分散，并令壓力逐步減輕。

　　大家千萬不要認為這是我故意捏造出來的極端情況——就在幾周之前，我就真正面對過這樣的情況。幸運的是整個集群擁有八臺服務器，修復問題的同時我還不得不為三臺服務器進行了備份。不必將幾十套虛擬機的損失一一分類有效降低了找出故障根本原因需要投入的資源。

　　如果大家發現自己更偏向于使用少數大型設備而非多臺小型設備，請務必記得，有時候少未必就好。盡管較低服務器數量能夠更輕松地支持起虛擬化負載，但卻很可能給未來的修復及升級工作帶來潛在困擾。由于數量有限，我們將不得不費盡心思來收拾殘局。就我個人而言，無論何時都堅持認為八臺小設備比三臺大設備更合適，因為在這幫小家伙的幫助下，我的每個夜晚都能過得更踏實、更安心。