在采訪小企業的IT專業人士時，他們之所以猶豫不決、不愿部署虛擬化技術，主要因素之一來自一種心態，這種心態可以描述為“別把所有雞蛋都放在一只籃子里”。
我能明白為什么會有這樣的顧慮。虛擬化讓許多訪客操作系統可以在單單一個物理系統里面運行。萬一這個物理系統遇到硬件故障，駐留在上面的所有訪客系統就會立馬同時無法正常運行。
這聽起來很糟，但是也許不如我們最初設想的那么糟。
持雞蛋和籃子理論的人覺得，我們不該同時讓所有資源面臨險境。這個理論一般適用于投資領域，鼓勵投資者分散風險，投資于多家公司和多種類型的證券，比如債券、股票、基金和大宗商品。以雞蛋(或貨幣)為例，我們談論的是可以互換的商品。一個雞蛋與另一個雞蛋基本上沒什么差別。一批雞蛋自然是多余的。
假設我們有一打雞蛋，打碎了六個，我們照樣可以做一份煎蛋餅，可能小點而已，但是我們仍可以吃。吃小點的煎蛋餅可能幾乎跟吃大點的煎蛋餅一樣能填飽肚子——無論如何，我們吃后不會覺得餓。
把已經多余的雞蛋放到多只籃子里讓我們可以兩面下注、獲得雙保險。沒錯，裝在兩只籃子里意味著，我們關注其中一只籃子的時間就比較少，所以這增加了丟失部分雞蛋的風險，但是也減小了丟失全部雞蛋的幾率。
拿雞蛋來說，這的確是明智的做法。同樣，這也是你準備拿退休金投資的明智方法。
這套理論隨后未經認真分析或充分認識就被搬到了毫不相干的領域，比如服務器虛擬化。不過，服務器卻不像雞蛋。
服務器、尤其是小公司的服務器是很少可以互換的商品：不是說只要有6臺(而不是通常的12臺)在工作就夠好了。服務器通常各自扮演獨特的角色，它們對確保公司業務的正常運轉而言都相對很重要。
如果某臺服務器不重要，那么當初也就不太可能證明有必要花成本來購置和維護這臺服務器了，所以它恐怕根本就不會存在。(當服務器可以互換時，比如在大型的無狀態Web服務器場或計算集群，它們采用這樣的配置是為了擴大計算容量，而不是僅限于單單一臺物理服務器，所以這不在本文探討的范圍之內。)
公司中的IT服務通常“依賴整條鏈”，至少從某種程度上來說是這樣。也就是說，它們相互依賴，某一項服務的丟失可能會影響其他服務。之所以會這樣，是由于它們在技術上相互依賴(比如某業務應用程序依賴數據庫)，或者是由于在工作流程方面相互依賴(辦公室員工需要文件服務器正常運行才能進行協作)。
這種情況下，丟失了單單一項關鍵的服務(比如電子郵件、網絡驗證或文件服務)，可能會導致工作能力嚴重喪失。如果共有十項關鍵的服務，有一項服務停運，那么從IT服務的角度來看，公司生產力的下降幅度就可能遠不止10%，在極端情況下有可能接近100%。
并非總是這種情況——在一些獨特的情況下，某項服務停運后，員工還是能夠找到有效的“變通辦法”，但是這種情況很少見。就算員工仍能正常工作，他們的工作效率可能比平常要低得多。
面對物理服務器時，每臺服務器各自就是一個故障點。所以，如果我們有十臺服務器，那么出現停運的可能性是如果我們只有一臺這樣的服務器時的十倍。我們添加的每一臺服務器都會帶來各自的風險。
如果每次故障的停運系數是2.5——也就是說，給公司帶來的經濟損失占某段時間(比如一天)收入的25%，那么十年下來總的平均影響相當于2.5次總的網站停運。
我在這里使用系數和平均這個概念是為了簡化這個問題。沒有必要確定平均停運事件的時間長度或平均停運事件的影響，因為我們只要確定這種情況下的相對影響，就可以比較場景。
這只是拿一種事件與另一種事件對停運事件的累積經濟影響進行比較，不需要具體的數字——這不會幫助你確定你應該花多少錢，確定的只是相對可靠性。
虛擬化和整合
借助虛擬化，我們顯然能夠整合資源。在本例中，我們將假設：可以把這現有的十臺服務器全部整合到一臺服務器上。我們在這么做的時候，常常會引起“別把所有雞蛋放在一只籃子里”的反應。
但是如果我們分析一下風險，就會發現這通常僅僅是害怕和不確定的心理，并不是數學上得到支持的風險。如果我們假設存在與上述例子中一樣的風險，那么我們的一臺服務器平均會帶來僅僅一次總的網站停運，每十年一次。
將這與造成危害相當于2.5次總的網站停運的第一個例子比較一下，會發現虛擬化整合解決方案帶來的風險只有傳統解決方案的40%。
現在牢記一點，這基于這個假設：丟失一些服務意味著造成的經濟損失大于丟失的那項服務的絕對價值，幾乎總是這種情況。即使丟失的服務只是丟失了這一項服務，我們也只是得失相當，無需擔心。
在很少見的情況下，丟失一個系統帶來的影響也非常小，這通常是由于人們隨機應變，面對失效系統，能夠想到變通辦法——比如要是即時通訊出了故障，人們只要轉而使用電子郵件，直到即時通訊服務恢復正常。但是這種情況很少見，其影響通常僅限于多個系統中的少數幾個系統;萬一出現停運事件，大多數系統會帶來極大的負面影響，比如企業資源規劃(ERP)、客戶關系管理(CRM)和電子郵件。
所以我們在這里看到的是，在通常情況下，把十項服務從十臺服務器上遷移到一臺服務器上通常可以降低我們的風險，而不是增加風險——這與“雞蛋和籃子”理論徑直形成了鮮明對照。而這純粹是從硬件故障的角度來考慮的。不過，整合帶來了可靠性方面的另外幾個重要因素，它們對我們的案例研究會帶來重大影響。
通過整合，我們可以減少需要IT部門加以監控和管理的硬件數量。服務器數量較少，這意味著可以把更多的時間和注意力放到剩余的那些服務器上。更多的注意力意味著，更有機會及早發現問題，有更多的機會準備好零部件。監控和維護工作改善了，可靠性也就更高了。
節省成本？
不過，整合方面可能最重要的因素是，可以大幅節省成本;如果做法得當，這可以為提高可靠性帶來機會。由于服務器的總成本顯著降低，企業忍不住會繼續確保預算較少，試圖直接利用節省下來的成本。
這是可以理解的;對一些公司來說，這可能是正確的做法。但是在駁斥雞蛋和籃子理論時，我不會推薦采用這種做法。
相反，通過采用一種更穩健的做法——保持大幅節省成本的同時，仍增加單臺服務器方面的開支(相對而言)，那樣你就能獲得一臺更高端(言外之意更可靠)的服務器，使用更好的零部件，擁有現場備件，等等。
虛擬化節省下來的成本常常可以直接轉化為提高可靠性，進而更有利于支持采用單一服務器這個做法。
正如前面所述，一間磚房比一間或兩間草房更有可能抵擋得住風暴。擁有更多的系統未必是更可靠的選擇。
這些好處純粹來自虛擬化的整合方面，而不是來自虛擬化本身。虛擬化還另外提供了緩解風險的功能。系統鏡像和快速恢復以及可恢復到不同硬件，這些都是大多數虛擬化平臺的主要優點。這在災難恢復策略中可以起到重要作用。
當然，我提到的所有概念表明了一點：單一服務器虛擬化和整合可以勝過傳統的“一臺服務器一個應用程序”這種做法，仍可以節省費用——這表明，雞蛋和籃子這個例子有誤導性，并不適合虛擬化這種場景。基于這些因素，企業可以比較放心地從傳統環境直接遷移到虛擬化環境。
值得一提的是，虛擬化隨后可以提高傳統大眾化硬件的可靠性，提供類似大型機的故障切換功能，這種功能是非虛擬化平臺無力提供的。這使得大眾化硬件更加與比較大、比較貴的RISC平臺靠齊。
這些功能可以帶來極高的保護級別，但是超出了開始遷離非故障切換的遺留硬件服務器環境的IT部門的正常需要。高可用性是一項出色的功能，但是常常成本高昂，而且往往沒有必要，特別是公司從過去相對不太可靠的環境遷移到如今更可靠的環境時。
考慮到我們已經提高了可靠性，超過了過去被認為必要的可靠性，現在很可能不需要極大幅度地提高可靠性。但是由于高可用性成本大幅下降，完全有可能在以前無法為高可用性證明成本合理性的情況下證明合理性。
虛擬化仍是太新的技術？
同樣，虛擬化常常讓人不安，因為大家覺得它是一項未得到證實的新技術。其實并非這樣，但是小企業和大眾化硬件領域存在這樣一種印象。
不過實際上，虛擬化早在上世紀60年代最先由IBM推出，此后一直是高端大型機和RISC服務器的主要功能——那些系統需要最佳可靠性。在大眾化服務器領域，虛擬化是個比較大的技術挑戰，經歷了漫長的時間后才被高效地實施，以便在實際環境下用起來卓有成效。
但是即便在大眾化硬件領域，虛擬化也自從上世紀90年代末以來就存在了，也就是說它大概有15年左右的歷史，早就不是什么新興技術——在IT行業，它絕對稱得上是古董級技術。
大眾化平臺虛擬化是個成熟的領域，有一些備受推崇、極其先進的廠商和產品。使用虛擬化作為幾乎所有服務器應用軟件的一個標準，這是早就確立并認可的“企業模式”，現在很容易被大大小小的公司所采用。
也許出人意料的是，虛擬化實際上是可靠性策略中一個至關重要的組成部分。虛擬化非但不會增加風險，幾乎還可以看成是一種降低風險的平臺——這套工具可用于通過諸多途徑來提高貴公司計算平臺的可靠性。
京公網安備 11010502049343號