倒金字塔式的厄运

3-2-1 系统架构模型在当今极为常见，而且几乎总是与企业所需、甚至所想要的恰恰相反——如果企业肯花时间把自己的业务目标写下来，而不是从技术优先的视角去着手设计架构的话。设计一个解决方案需要从业务需求出发，否则我们不仅会面临架构被设计得不适合该企业的风险，而是简直可以预料到必然如此。

这个名称指的是三台（这一点并不固定，往往是两台或更多）冗余的虚拟化主机服务器，连接到两台（或可能更多）冗余的交换机，再连接到单台存储设备，通常是一台 SAN（不过 DAS 或 NAS 在这里也是适用的）。之所以说它是倒金字塔，是因为真正重要的部分——虚拟化主机——完全依赖于网络，而网络反过来又完全依赖于那单台 SAN 或其替代存储设备。于是一切都建立在一台单点故障设备之上，而所有的保护和冗余都被越来越多地堆砌在那个脆弱的根基之上。与一座拥有宽阔稳固底座、顶端收为一点的正常金字塔不同，这座金字塔把所有的脆弱都建在了底部。（人们在试图解释这为什么不是单点故障时，常常会抛出那套“独角兽放屁”式的营销说辞——“SAN 是魔法，因为有双控制器所以不会出故障”——但它在任何意义上都是一个单点故障。）

因此，这种常被称为 3-2-1 设计的解决方案，也可以被称为“倒金字塔式的厄运”，因为它是一座头朝下的金字塔，脆弱得难以运行，而且就其所交付的东西而言又极其昂贵。所以，与许多其他脆弱的模型不同，它代价高昂、灵活性不强，而且其可靠性还不如干脆什么都不做、只用一台优质的单服务器。

确实有 3-2-1 说得通的时候，但这些大多是极端的边缘情况——人们刻意需要一个脆弱的环境，并且需要高水平的共享存储以及海量的处理能力——这些都不是你会在 SMB 世界里见到的东西，在其他地方也非常罕见。

对于那些并不了解整个架构的人来说，比如管理者和业务人员，倒金字塔看起来很棒。有许多盒子，许多线缆，通常还有一些被标注为“HA”的软件组件，这在外行的观察者看来，会让人觉得整个解决方案必定是高度可靠的。倒金字塔之所以受欢迎，是因为它从营销的角度提供了“HA”，把一切都说得天花乱坠，同时又把总体成本控制在合理范围内，于是它看起来几乎像是一个奇迹——既许下高可用的承诺，又不必付出传统的代价。某些组件额外的“冗余”对营销而言再好不过。由于可靠性很难衡量，业务人员和技术人员往往都退而谈论冗余而非可靠性，因为冗余是显而易见的。倒金字塔对这些人很有说服力，因为它提供了冗余却没有可靠性。冗余并不在最要紧的地方。务必牢记：冗余不是一个用来打勾的复选框，冗余也不是目标，它是一种用来获得可靠性提升的工具。不当的冗余毫无价值。一辆在后备箱里放着备用方向盘的汽车有什么用？一架在第一架坠毁时你就丧命的备用飞机有什么用？当那唯一的一台 SAN 化为青烟、你的业务瘫痪、数据丢失时，一台备用服务器又有什么用？

倒金字塔是技术销售中所运用的“皇帝的新装”里最明显、最普遍的例子之一。因为它通过推动高利润的销售、尽量减少低利润的销售，满足了经销商和供应商的需求；又因为几乎每一家供应商都因其对卖方的财务优势而推广它——它已被广泛接受为一种绝佳的解决方案，原因恰恰在于它复杂、技术化到足以让大规模的否定不会发生，再加上从受益于该架构的众多供应商那里涌来的巨大市场压力，它已经成为现状，几乎没有人会停下来质疑整个架构是否有任何价值。再加上一个事实：与仅仅十年前的系统相比，如今所有系统都高度可靠，致使故障已罕见到这种程度——以至于它们比本应出现的频率更高这一事实、以及统计上的故障率并不会在各个 SMB 之间共享——这意味着该架构得以蓬勃发展，并已成为大多数 SMB 事实上的标准解决方案集。

归根结底，倒金字塔的做法毫无道理可言——它远比更简单的解决方案（哪怕只是一台独立运行的单服务器）更不可靠，而成本却高出许多倍。如果成本是关键的考量因素，就应当将它彻底排除。如果可靠性是关键的考量因素，就应当将它彻底排除。只有当成本和可靠性都让位于灵活性、退居非常靠后的位置时，它才有可能被摆上台面；而即便如此，在预期的灵活性范围之内，一个成本更低、更可靠的解决方案在整体灵活性上不与之相当的情况也很罕见。最好是干脆完全避开它。

最初以删节形式发表于 Spiceworks：http://community.spiceworks.com/topic/312493-the-inverted-pyramid-of-doom