虛擬化技術(shù)已經(jīng)給數(shù)據(jù)中心帶來顛覆性變革，但極力壓縮服務(wù)器虛擬化主機(jī)數(shù)量、過度提高虛擬機(jī)密度的做法并非最佳選擇。

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

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

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

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

誠(chéng)然，授權(quán)許可成本算是造成這種現(xiàn)狀的重要原因。由于很多虛擬化框架許可都會(huì)按CPU及內(nèi)存數(shù)量來計(jì)費(fèi)，因此部署八套低配置服務(wù)器所帶來的許可成本要遠(yuǎn)高于部署四套高配置服務(wù)器。然而極力壓榨物理平臺(tái)資源的做法必然導(dǎo)致我們失去了處理停機(jī)及物理服務(wù)器故障的能力。我們不會(huì)利用RAID 1來部署主線存儲(chǔ)機(jī)制，但很多雙服務(wù)器方案其實(shí)在本質(zhì)上并無(wú)不同，都是在盡量壓縮設(shè)備數(shù)量。

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

最典型的例子就是文件系統(tǒng)會(huì)在特定LUN鎖定服務(wù)器中的I/O子系統(tǒng)時(shí)出現(xiàn)故障，這時(shí)其它物理服務(wù)器中的虛擬服務(wù)器也可能會(huì)受到影響。這些受影響的服務(wù)器可能至少需要重啟或者從備份中恢復(fù)丟失或受損的虛擬機(jī)系統(tǒng)。一旦其它某些設(shè)備也出現(xiàn)狀況，管理人員面臨的壓力會(huì)更大，因?yàn)檎撞渴鹪O(shè)施都面臨著極大危險(xiǎn)。然而隨著服務(wù)器數(shù)量的增加，危險(xiǎn)系數(shù)也將隨之分散，并令壓力逐步減輕。

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

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