在采访小企业的IT专业人士时，他们之所以犹豫不决、不愿部署虚拟化技术，主要因素之一来自一种心态，这种心态可以描述为“别把所有鸡蛋都放在一只篮子里”。
我能明白为什么会有这样的顾虑。虚拟化让许多访客操作系统可以在单单一个物理系统里面运行。万一这个物理系统遇到硬件故障，驻留在上面的所有访客系统就会立马同时无法正常运行。
这听起来很糟，但是也许不如我们最初设想的那么糟。
持鸡蛋和篮子理论的人觉得，我们不该同时让所有资源面临险境。这个理论一般适用于投资领域，鼓励投资者分散风险，投资于多家公司和多种类型的证券，比如债券、股票、基金和大宗商品。以鸡蛋(或货币)为例，我们谈论的是可以互换的商品。一个鸡蛋与另一个鸡蛋基本上没什么差别。一批鸡蛋自然是多余的。
假设我们有一打鸡蛋，打碎了六个，我们照样可以做一份煎蛋饼，可能小点而已，但是我们仍可以吃。吃小点的煎蛋饼可能几乎跟吃大点的煎蛋饼一样能填饱肚子——无论如何，我们吃后不会觉得饿。
把已经多余的鸡蛋放到多只篮子里让我们可以两面下注、获得双保险。没错，装在两只篮子里意味着，我们关注其中一只篮子的时间就比较少，所以这增加了丢失部分鸡蛋的风险，但是也减小了丢失全部鸡蛋的几率。
拿鸡蛋来说，这的确是明智的做法。同样，这也是你准备拿退休金投资的明智方法。
这套理论随后未经认真分析或充分认识就被搬到了毫不相干的领域，比如服务器虚拟化。不过，服务器却不像鸡蛋。
服务器、尤其是小公司的服务器是很少可以互换的商品：不是说只要有6台(而不是通常的12台)在工作就够好了。服务器通常各自扮演独特的角色，它们对确保公司业务的正常运转而言都相对很重要。
如果某台服务器不重要，那么当初也就不太可能证明有必要花成本来购置和维护这台服务器了，所以它恐怕根本就不会存在。(当服务器可以互换时，比如在大型的无状态Web服务器场或计算集群，它们采用这样的配置是为了扩大计算容量，而不是仅限于单单一台物理服务器，所以这不在本文探讨的范围之内。)
公司中的IT服务通常“依赖整条链”，至少从某种程度上来说是这样。也就是说，它们相互依赖，某一项服务的丢失可能会影响其他服务。之所以会这样，是由于它们在技术上相互依赖(比如某业务应用程序依赖数据库)，或者是由于在工作流程方面相互依赖(办公室员工需要文件服务器正常运行才能进行协作)。
这种情况下，丢失了单单一项关键的服务(比如电子邮件、网络验证或文件服务)，可能会导致工作能力严重丧失。如果共有十项关键的服务，有一项服务停运，那么从IT服务的角度来看，公司生产力的下降幅度就可能远不止10%，在极端情况下有可能接近100%。
并非总是这种情况——在一些独特的情况下，某项服务停运后，员工还是能够找到有效的“变通办法”，但是这种情况很少见。就算员工仍能正常工作，他们的工作效率可能比平常要低得多。
面对物理服务器时，每台服务器各自就是一个故障点。所以，如果我们有十台服务器，那么出现停运的可能性是如果我们只有一台这样的服务器时的十倍。我们添加的每一台服务器都会带来各自的风险。
如果每次故障的停运系数是2.5——也就是说，给公司带来的经济损失占某段时间(比如一天)收入的25%，那么十年下来总的平均影响相当于2.5次总的网站停运。
我在这里使用系数和平均这个概念是为了简化这个问题。没有必要确定平均停运事件的时间长度或平均停运事件的影响，因为我们只要确定这种情况下的相对影响，就可以比较场景。
这只是拿一种事件与另一种事件对停运事件的累积经济影响进行比较，不需要具体的数字——这不会帮助你确定你应该花多少钱，确定的只是相对可靠性。
虚拟化和整合
借助虚拟化，我们显然能够整合资源。在本例中，我们将假设：可以把这现有的十台服务器全部整合到一台服务器上。我们在这么做的时候，常常会引起“别把所有鸡蛋放在一只篮子里”的反应。
但是如果我们分析一下风险，就会发现这通常仅仅是害怕和不确定的心理，并不是数学上得到支持的风险。如果我们假设存在与上述例子中一样的风险，那么我们的一台服务器平均会带来仅仅一次总的网站停运，每十年一次。
将这与造成危害相当于2.5次总的网站停运的第一个例子比较一下，会发现虚拟化整合解决方案带来的风险只有传统解决方案的40%。
现在牢记一点，这基于这个假设：丢失一些服务意味着造成的经济损失大于丢失的那项服务的绝对价值，几乎总是这种情况。即使丢失的服务只是丢失了这一项服务，我们也只是得失相当，无需担心。
在很少见的情况下，丢失一个系统带来的影响也非常小，这通常是由于人们随机应变，面对失效系统，能够想到变通办法——比如要是即时通讯出了故障，人们只要转而使用电子邮件，直到即时通讯服务恢复正常。但是这种情况很少见，其影响通常仅限于多个系统中的少数几个系统;万一出现停运事件，大多数系统会带来极大的负面影响，比如企业资源规划(ERP)、客户关系管理(CRM)和电子邮件。
所以我们在这里看到的是，在通常情况下，把十项服务从十台服务器上迁移到一台服务器上通常可以降低我们的风险，而不是增加风险——这与“鸡蛋和篮子”理论径直形成了鲜明对照。而这纯粹是从硬件故障的角度来考虑的。不过，整合带来了可靠性方面的另外几个重要因素，它们对我们的案例研究会带来重大影响。
通过整合，我们可以减少需要IT部门加以监控和管理的硬件数量。服务器数量较少，这意味着可以把更多的时间和注意力放到剩余的那些服务器上。更多的注意力意味着，更有机会及早发现问题，有更多的机会准备好零部件。监控和维护工作改善了，可靠性也就更高了。
#p#
节省成本?
不过，整合方面可能最重要的因素是，可以大幅节省成本;如果做法得当，这可以为提高可靠性带来机会。由于服务器的总成本显著降低，企业忍不住会继续确保预算较少，试图直接利用节省下来的成本。
这是可以理解的;对一些公司来说，这可能是正确的做法。但是在驳斥鸡蛋和篮子理论时，我不会推荐采用这种做法。
相反，通过采用一种更稳健的做法——保持大幅节省成本的同时，仍增加单台服务器方面的开支(相对而言)，那样你就能获得一台更高端(言外之意更可靠)的服务器，使用更好的零部件，拥有现场备件，等等。
虚拟化节省下来的成本常常可以直接转化为提高可靠性，进而更有利于支持采用单一服务器这个做法。
正如前面所述，一间砖房比一间或两间草房更有可能抵挡得住风暴。拥有更多的系统未必是更可靠的选择。
这些好处纯粹来自虚拟化的整合方面，而不是来自虚拟化本身。虚拟化还另外提供了缓解风险的功能。系统镜像和快速恢复以及可恢复到不同硬件，这些都是大多数虚拟化平台的主要优点。这在灾难恢复策略中可以起到重要作用。
当然，我提到的所有概念表明了一点：单一服务器虚拟化和整合可以胜过传统的“一台服务器一个应用程序”这种做法，仍可以节省费用——这表明，鸡蛋和篮子这个例子有误导性，并不适合虚拟化这种场景。基于这些因素，企业可以比较放心地从传统环境直接迁移到虚拟化环境。
值得一提的是，虚拟化随后可以提高传统大众化硬件的可靠性，提供类似大型机的故障切换功能，这种功能是非虚拟化平台无力提供的。这使得大众化硬件更加与比较大、比较贵的RISC平台靠齐。
这些功能可以带来极高的保护级别，但是超出了开始迁离非故障切换的遗留硬件服务器环境的IT部门的正常需要。高可用性是一项出色的功能，但是常常成本高昂，而且往往没有必要，特别是公司从过去相对不太可靠的环境迁移到如今更可靠的环境时。
考虑到我们已经提高了可靠性，超过了过去被认为必要的可靠性，现在很可能不需要极大幅度地提高可靠性。但是由于高可用性成本大幅下降，完全有可能在以前无法为高可用性证明成本合理性的情况下证明合理性。
虚拟化仍是太新的技术?
同样，虚拟化常常让人不安，因为大家觉得它是一项未得到证实的新技术。其实并非这样，但是小企业和大众化硬件领域存在这样一种印象。
不过实际上，虚拟化早在上世纪60年代最先由IBM推出，此后一直是高端大型机和RISC服务器的主要功能——那些系统需要最佳可靠性。在大众化服务器领域，虚拟化是个比较大的技术挑战，经历了漫长的时间后才被高效地实施，以便在实际环境下用起来卓有成效。
但是即便在大众化硬件领域，虚拟化也自从上世纪90年代末以来就存在了，也就是说它大概有15年左右的历史，早就不是什么新兴技术——在IT行业，它绝对称得上是古董级技术。
大众化平台虚拟化是个成熟的领域，有一些备受推崇、极其先进的厂商和产品。使用虚拟化作为几乎所有服务器应用软件的一个标准，这是早就确立并认可的“企业模式”，现在很容易被大大小小的公司所采用。
也许出人意料的是，虚拟化实际上是可靠性策略中一个至关重要的组成部分。虚拟化非但不会增加风险，几乎还可以看成是一种降低风险的平台——这套工具可用于通过诸多途径来提高贵公司计算平台的可靠性。
http://www.datamation.com/data-center/smb-virtualization-all-your-eggs-in-one-basket-1.html
