4.總在正常運行

　　虛擬化的悖論是：它消除了對硬件的依賴，但同時也使硬件更為重要。虛擬機的合并更加依賴硬件的可靠性，因為更少的物理服務器現在要支持一個虛擬機的大集合。

　　關鍵業務應用對一個公司的運營是至關重要的。當一臺服務器必須支持多個工作負荷時，作為合并業務處理的一部分來看，甚至非關鍵應用也變得至關重要。

　　雖然有多種解決方案可以提高應用的可靠性，容錯提供了一種基于硬件的方法，能夠確保連續的正常運行時間。

　　9的個數

　　如果100%的是完美的話，那么99.999+%的可用性算佳了。解決方案怎么做才能達到這個指標?先試試最普通老的99%吧!這是正確的做法， x86服務器往往能讓其上運行的服務平均達到99%的可用性。這看起來相當不錯，直到你認為這對你的組織意味著什么。兩個9的可用性意味著系統在一年中的意外停機時間達到了87.6小時–而你決不會希望有這些小時!現在來考慮一下停機一小時的成本：一般公司的損失在10萬至15萬美元之間。你可以自己算算。

　　可以比較容易地達到三個9：99.9%。它所需要的一臺好服務器只需帶有冗余電源、風扇和一個磁盤陣列(RAID)，再加上最佳實踐。你可以得到三個9，相當于每年有8.76小時的意外停機時間。這看上去似乎是一個大的躍進，但在高峰處理時段的停機時間仍然嚴重地突破了你的底線。

　　再上一個等級為99.95%的正常運行時間往往需要集群技術。通常稱為高可用性(HA)解決方案。失效后，集群會在一個健康的系統上重啟應用。有些集群方案聲稱自己達到了99.99%，但一年只有52分鐘的停機時間方案需要一種真正精心打造的集群，使應用能夠非常迅速地進行故障切換。許多常見的集群應用，如數據庫無法迅速地進行故障切換，因為出現失效后，他們必須檢查文件的完整性和重放事務日志。

　　所以任何系統的最佳是五個9：即99.999%的可用性，它多增加了一個9，那么一年的停機時間就成了五分鐘!為了達到這個數字，你首先需要避免系統失效，而不是試圖從中恢復?？匆豢磮D4-1，讓你有個視覺感受。

　　圖4-1：9的個數表。(每年的成本是按照每小時意外停機損失10萬美元計算)。

　　所以你認為需要容錯

　　術語高可用性和容錯能力在所有的時間都在交替使用，這會導致混亂。傳統的HA解決方案通常包括數據復制或旨在從失效中恢復的集群。然而，在這些情況中，系統失效確實發生了。為了從失效中恢復，應用要在一個健康的系統上重新啟動。在大多數情況下，這需要應用具有集群感知，這可能包含你IT人員編寫的腳本。在容錯服務器中，每一個組件為雙份并在各自的硬件中同步地運行。這意味著這些組件在同一個CPU時鐘周期上處理相同的指令。如果某一部分出現故障，它的對應伙伴能保持正確的處理。這就是為什么一個容錯的服務器系統并沒有故障切換或重新啟動。

　　容錯也保證了所有的數據是可用的，甚至當硬件組件故障，數據寫入了磁盤或是內存(稱為飛行中的數據)。

　　不是所有的容錯結構都相同。一些虛擬化方案用軟件模擬容錯，但這有幾處缺點。首先，它本質上創建了另一個影子虛擬機(VM)，在一個基于軟件的環境中步調一致地處理指令。軟件仿真會引發硬件大量的開銷。這會大大地影響性能，因為CPU不得不處理這種負載。至于對過去單一CPU內核能力的擴展也會有限制，肯定不適合那些高消耗的業務應用和數據庫。

　　相比之下，有些體系結構是基于全功能的硬件容錯。這種系統從一開始就作為容錯平臺而設計。應用程序能夠充分利用多核對稱多處理的優勢。硬件容錯確保了性能最大、正常運行時間最長和數據保護最全。

　　硬件容錯等于正常運行時間