创立于 2008 年 · 数字版 · 2026年6月15日

SMB IT Journal

面向小型企业的信息技术资源

中文
架构

虚拟的鸡蛋与篮子

在与小型企业的 IT 专业人士交谈时,对部署虚拟化心存犹豫的关键因素之一,源自人们所说的“不要把所有鸡蛋放在一个篮子里”。

我能理解这种顾虑从何而来。虚拟化允许将许多客户机操作系统装入单个物理系统之中,而一旦发生硬件故障,驻留其上的所有客户机系统便会一同失效,全部在同一时刻宕机。这听起来很糟糕,但或许并不像我们最初设想的那么糟。

“鸡蛋与篮子”这一俗语的本意是,我们不应让自己的所有资源同时面临风险。它通常被应用于投资领域,鼓励投资者实现多元化,投资于许多不同的公司以及债券、股票、基金和大宗商品等不同类型的证券。就鸡蛋(或金钱)而言,我们谈论的是一种可互换的商品。一个鸡蛋和另一个一样好。一组鸡蛋天然具有冗余性。

如果我们有一打鸡蛋,打碎了六个,我们仍然可以做一份煎蛋卷,也许小一点,但我们仍然有得吃。吃一份小一点的煎蛋卷,其满足感很可能与吃一份大的几乎无异——无论如何我们都不会挨饿。把本就具有冗余性的鸡蛋放进多个篮子,让我们得以分散押注。诚然,提着两个篮子意味着我们能分给每个篮子的注意力更少,因此会增加损失部分鸡蛋的风险,但却降低了损失全部鸡蛋的概率。就鸡蛋而言,这的确是个明智之举。同样,这也是为退休生活做准备的明智方式。

这套理论由于被当作俗语反复传诵,却缺乏审慎的分析或恰当的理解,于是便被套用到了诸如服务器虚拟化这样毫不相干的领域。然而,服务器并不像鸡蛋。服务器,尤其是在较小型企业中,很少是可互换的商品——很少是那种本该有十二台、如今有六台在运行也就够用了的东西。通常每台服务器都扮演着独特的角色,而且对企业的运转而言全都相对关键。如果一台服务器并不关键,那么它首先就不太可能有理由证明获取和维护自身的成本是值得的,因此它很可能根本就不会存在。当服务器确实可以互换时,例如在大型、无状态的 Web 服务器集群或计算集群中,它们之所以被如此配置,是作为一种将容量扩展到超越单个物理机箱限制的手段,因此不在本讨论的范围之内。

企业中的 IT 服务通常在某种程度上是一种“链式依赖”。也就是说,它们相互依赖,单个服务的丧失可能会影响其他服务,这或是因为它们在技术上相互依赖(例如某个业务线应用程序依赖于一个数据库),或是因为它们在工作流程上相互依赖(例如一位办公人员需要文件服务器正常工作,以便提供一份他需要编辑的文件,而编辑时要用到来自某封电子邮件的信息,与此同时还要通过电话或即时通讯工具讨论这些改动)。在这些情况下,电子邮件、网络身份验证或文件服务等单个关键服务的丧失,可能会造成工作能力不成比例的损失。如果有十项关键服务,其中一项宕机,那么从 IT 服务的角度来看,公司的生产力下降幅度很可能远超百分之十,在极端情况下甚至可能接近百分之百。这并非总是如此,在某些特殊情况下,员工能够有效地“绕开”所丧失的服务继续工作,但这非常罕见。即便人们还能继续工作,他们的生产力也很可能远低于平常。

在处理物理服务器时,每台服务器都代表着它自身的一个故障点。因此,如果我们有十台服务器,那么与只有这十台中的一台相比,我们发生故障中断的可能性就是十倍。我们每增加一台服务器,都会随之带来它自身的风险。如果每次故障的中断系数为 2.5——也就是说,在财务上对企业造成相当于其某一天百分之二十五营收的影响——那么在十年间,我们的总平均影响就相当于两次半的整站中断。我在这里使用系数和平均值的概念是为了简化说明,确定一次平均中断的时长或一次平均中断的影响并非必要,因为在本例中我们只需确定相对影响,以便对各种情形进行比较。这只是一种在无需具体数字的情况下,将一种事件类型与另一种事件类型的累积中断财务影响进行比较的手段——它无助于你确定应该花多少钱,只能用于比较相对的可靠性。

借助虚拟化,我们显然具备了整合的能力。在本例中,我们假设可以把现有的全部十台服务器合并到单独一台服务器上。当我们这样做时,往往会触发“把所有鸡蛋放在一个篮子里”的反应。但如果我们进行一些风险分析,就会发现这通常只是恐惧和不确定,而非有数学支撑的风险。如果我们假设其风险与上例相同,那么我们这台单独的服务器平均每十年只会发生一次整站中断。

将此与第一个例子相比较,后者造成的损害相当于两次半的整站中断——虚拟化整合方案的风险仅为传统方案的百分之四十。

现在请记住,这是基于这样一个假设:丧失部分服务所意味着的财务损失,要大于所丧失服务本身的严格价值,而这几乎总是事实。即便所丧失的服务造成的损失不超过单项服务本身,我们也只是处于盈亏平衡,无需担忧。在极少数情况下,丧失单个系统所造成的影响可能小于其“在整体中所占的那一份”,这通常是因为人们具有灵活性,能够绕开失效的系统继续工作——比如即时通讯失效后,人们干脆改用电子邮件,直到即时通讯恢复,但这类情况很罕见,而且通常只局限于众多系统中的少数几个,大多数系统(比如 ERP、CRM 和电子邮件)一旦中断都会造成不成比例的巨大影响。

所以我们在这里看到的是,在通常情况下,把十项服务从十台服务器迁移到一台服务器上的十项服务,一般会降低我们的风险,而非增加风险——这与“鸡蛋放在一个篮子里”的理论恰恰相反。而这还纯粹是从硬件故障的角度来看的。不过,整合还带来了其他几个重要的可靠性因素,它们能对我们的案例研究产生重大影响。

借助整合,我们减少了 IT 部门需要监控和管理的硬件数量。服务器更少意味着可以把更多的时间和精力投入到那些保留下来的服务器上。更多的关注意味着更有可能及早发现问题,也有更多机会备好零部件。更好的监控和维护带来更好的可靠性。

然而,整合可能最重要的一个因素在于,它能带来可观的成本节约,而这种节约如果处理得当,便能为提升可靠性创造机会。随着服务器总成本的大幅降低,人们可能会忍不住继续把预算压得很紧,试图纯粹地直接利用这些成本节约。这可以理解,对某些企业来说这或许也是正确的做法。但在与“鸡蛋与篮子”这一观念抗衡时,这并不是我会推荐的做法。

相反,通过采取一种更为折中的做法——既保留可观的成本节约,但相对而言在单独一台服务器上花费更多——你便能购置一台更高端(亦即:更可靠)的服务器,使用更好的部件,配备现场备件,等等。虚拟化所节约的成本往往可以直接转化为可靠性的提升,从而进一步使天平向单服务器方案倾斜。

正如我在另一篇文章中所言,一座砖房比一座或两座草房都更有可能在暴风中幸存下来。拥有更多数量的某样东西,未必就能使其成为更可靠的选择。

这些好处纯粹来自虚拟化的整合层面,而非来自虚拟化本身。虚拟化还单独提供了扩展的风险缓解功能。系统镜像与快速恢复,以及恢复到不同硬件上的能力,是几乎任何虚拟化平台的主要优势。这在灾难恢复策略中可以发挥重要作用。

当然,所有这些观点纯粹是为了证明:单机虚拟化与整合能够胜过传统的“一个应用对应一台服务器”的做法,并且仍然能省钱——从而表明“鸡蛋与篮子”的例子具有误导性,并不适用于这种情形。基于这些因素,从传统环境直接迁移到虚拟化环境,应当不会有多少顾虑。

应当指出的是,虚拟化随后还能扩展传统商用硬件的可靠性,提供类似大型机的故障切换功能,这些功能超出了非虚拟化平台所能提供的范畴。这使得商用硬件更稳固地跻身于更大型、更昂贵的 RISC 平台之列。这些功能能够带来极高级别的保护,但对于那些刚刚从无故障切换、采用传统硬件的服务器环境迁移过来的 IT 部门而言,往往超出了适宜的范围。高可用性是一项很棒的功能,但往往代价高昂,而且常常并非必需,尤其是当企业从我们已经看到的、过去相对不可靠的环境迁移到如今更可靠的环境时更是如此。鉴于我们已经把可靠性提升到了超出过去所认为之必要的水平,如今很有可能并不需要在可靠性上实现极端的跃升,但由于高可用性的成本大幅下降,它如今很可能在成本上是合理的,而这在以往是无法实现的。

同样地,虚拟化常常令人心生畏惧,因为它被视为一项新生的、未经验证的技术。这显然并非事实,但在小型企业和商用服务器领域确实存在这样一种印象。然而实际上,虚拟化最早由 IBM 在 20 世纪 60 年代引入,自那以后便一直是高端大型机和 RISC 服务器——那些对可靠性要求最高的系统——的中流砥柱。在商用服务器领域,虚拟化是一项更大的技术挑战,过了很长时间才得以高效实现,使其在现实世界中切实可用。但即便在商用服务器领域,虚拟化自 20 世纪 90 年代末起便已可用,因此如今大约已有十五年的历史,早已远远越过了一项新生技术的阶段——在 IT 的世界里,它绝对称得上是元老级的了。商用平台虚拟化是一个成熟的领域,拥有若干备受推崇、极为先进的厂商和产品。将虚拟化作为所有或几乎所有服务器应用的标准,是一种确立已久并被广泛接受的“企业模式”,如今任何规模、每一种规模的公司都能轻松采纳它。

或许有违直觉的是,虚拟化实际上是可靠性策略中一个极为关键的组成部分。虚拟化非但不会增加风险,几乎可以被视作一个风险缓解平台——一个通过多种途径提升你计算平台可靠性的工具集。

标签redundancy reliability risk

广告

SMB IT Journal — the IT resource for small business