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，那么一年的停机时间就成了五分钟!为了达到这个数字，你首先需要避免系统失效，而不是试图从中恢复。看一看图4-1，让你有个视觉感受。

　　图4-1：9的个数表。(每年的成本是按照每小时意外停机损失10万美元计算)。

　　所以你认为需要容错

　　术语高可用性和容错能力在所有的时间都在交替使用，这会导致混乱。传统的HA解决方案通常包括数据复制或旨在从失效中恢复的集群。然而，在这些情况中，系统失效确实发生了。为了从失效中恢复，应用要在一个健康的系统上重新启动。在大多数情况下，这需要应用具有集群感知，这可能包含你IT人员编写的脚本。在容错服务器中，每一个组件为双份并在各自的硬件中同步地运行。这意味着这些组件在同一个CPU时钟周期上处理相同的指令。如果某一部分出现故障，它的对应伙伴能保持正确的处理。这就是为什么一个容错的服务器系统并没有故障切换或重新启动。

　　容错也保证了所有的数据是可用的，甚至当硬件组件故障，数据写入了磁盘或是内存(称为飞行中的数据)。

　　不是所有的容错结构都相同。一些虚拟化方案用软件模拟容错，但这有几处缺点。首先，它本质上创建了另一个影子虚拟机(VM)，在一个基于软件的环境中步调一致地处理指令。软件仿真会引发硬件大量的开销。这会大大地影响性能，因为CPU不得不处理这种负载。至于对过去单一CPU内核能力的扩展也会有限制，肯定不适合那些高消耗的业务应用和数据库。

　　相比之下，有些体系结构是基于全功能的硬件容错。这种系统从一开始就作为容错平台而设计。应用程序能够充分利用多核对称多处理的优势。硬件容错确保了性能最大、正常运行时间最长和数据保护最全。

　　硬件容错等于正常运行时间