4.總在正常運行
虛擬化的悖論是：它消除了對硬件的依賴，但同時也使硬件更為重要。虛擬機的合并更加依賴硬件的可靠性，因為更少的物理服務(wù)器現(xiàn)在要支持一個虛擬機的大集合。
關(guān)鍵業(yè)務(wù)應用對一個公司的運營是至關(guān)重要的。當一臺服務(wù)器必須支持多個工作負荷時，作為合并業(yè)務(wù)處理的一部分來看，甚至非關(guān)鍵應用也變得至關(guān)重要。
雖然有多種解決方案可以提高應用的可靠性，容錯提供了一種基于硬件的方法，能夠確保連續(xù)的正常運行時間。
9的個數(shù)
如果100%的是完美的話，那么99.999+%的可用性算佳了。解決方案怎么做才能達到這個指標?先試試最普通老的99%吧!這是正確的做法， x86服務(wù)器往往能讓其上運行的服務(wù)平均達到99%的可用性。這看起來相當不錯，直到你認為這對你的組織意味著什么。兩個9的可用性意味著系統(tǒng)在一年中的意外停機時間達到了87.6小時–而你決不會希望有這些小時!現(xiàn)在來考慮一下停機一小時的成本：一般公司的損失在10萬至15萬美元之間。你可以自己算算。
可以比較容易地達到三個9：99.9%。它所需要的一臺好服務(wù)器只需帶有冗余電源、風扇和一個磁盤陣列(RAID)，再加上最佳實踐。你可以得到三個9，相當于每年有8.76小時的意外停機時間。這看上去似乎是一個大的躍進，但在高峰處理時段的停機時間仍然嚴重地突破了你的底線。
再上一個等級為99.95%的正常運行時間往往需要集群技術(shù)。通常稱為高可用性(HA)解決方案。失效后，集群會在一個健康的系統(tǒng)上重啟應用。有些集群方案聲稱自己達到了99.99%，但一年只有52分鐘的停機時間方案需要一種真正精心打造的集群，使應用能夠非常迅速地進行故障切換。許多常見的集群應用，如數(shù)據(jù)庫無法迅速地進行故障切換，因為出現(xiàn)失效后，他們必須檢查文件的完整性和重放事務(wù)日志。
所以任何系統(tǒng)的最佳是五個9：即99.999%的可用性，它多增加了一個9，那么一年的停機時間就成了五分鐘!為了達到這個數(shù)字，你首先需要避免系統(tǒng)失效，而不是試圖從中恢復。看一看圖4-1，讓你有個視覺感受。
圖4-1：9的個數(shù)表。(每年的成本是按照每小時意外停機損失10萬美元計算)。
所以你認為需要容錯
術(shù)語高可用性和容錯能力在所有的時間都在交替使用，這會導致混亂。傳統(tǒng)的HA解決方案通常包括數(shù)據(jù)復制或旨在從失效中恢復的集群。然而，在這些情況中，系統(tǒng)失效確實發(fā)生了。為了從失效中恢復，應用要在一個健康的系統(tǒng)上重新啟動。在大多數(shù)情況下，這需要應用具有集群感知，這可能包含你IT人員編寫的腳本。在容錯服務(wù)器中，每一個組件為雙份并在各自的硬件中同步地運行。這意味著這些組件在同一個CPU時鐘周期上處理相同的指令。如果某一部分出現(xiàn)故障，它的對應伙伴能保持正確的處理。這就是為什么一個容錯的服務(wù)器系統(tǒng)并沒有故障切換或重新啟動。
容錯也保證了所有的數(shù)據(jù)是可用的，甚至當硬件組件故障，數(shù)據(jù)寫入了磁盤或是內(nèi)存(稱為飛行中的數(shù)據(jù))。
不是所有的容錯結(jié)構(gòu)都相同。一些虛擬化方案用軟件模擬容錯，但這有幾處缺點。首先，它本質(zhì)上創(chuàng)建了另一個影子虛擬機(VM)，在一個基于軟件的環(huán)境中步調(diào)一致地處理指令。軟件仿真會引發(fā)硬件大量的開銷。這會大大地影響性能，因為CPU不得不處理這種負載。至于對過去單一CPU內(nèi)核能力的擴展也會有限制，肯定不適合那些高消耗的業(yè)務(wù)應用和數(shù)據(jù)庫。
相比之下，有些體系結(jié)構(gòu)是基于全功能的硬件容錯。這種系統(tǒng)從一開始就作為容錯平臺而設(shè)計。應用程序能夠充分利用多核對稱多處理的優(yōu)勢。硬件容錯確保了性能最大、正常運行時間最長和數(shù)據(jù)保護最全。
硬件容錯等于正常運行時間
