充分利用你的倒金字塔之灾

3-2-1 架构（即倒金字塔之灾）由于种种原因，已经成为 IT 行业人人避之不及的对象。可悲的是，对许多公司而言，它们往往是在组件已经到货、资金已经从账户流出之后，才了解到与这一设计相关的危险。

有些公司是幸运的，能够及早发现这一错误，从而得以退还所购产品，并在采购新的硬件和软件之前重新进行恰当的设计与决策环节。然而，这只是一种理想且十分罕见的情况。在最好的情况下，我们通常也只能预期需要支付一定的退货手续费；而更为常见的是，设备根本无法退回，或者手续费高昂到使退货变得毫无意义。

大多数公司所面临的，是一种需要在现有局面下「尽量做到最好」的处境。其中一个最大的隐忧在于：相关方——无论是刚刚为新硬件花费了大笔资金的财务利益相关者，还是因为允许采购这套设备而如今颜面无光的技术利益相关者——会陷入情绪化的反应，从而屈服于沉没成本谬误。至关重要的一点是，绝不能让这种情绪化、缺乏逻辑的反应占据上风，因为它会破坏关键的决策过程。

必须认识到，花在倒金字塔之灾上的钱已经花出去了，再也回不来了。这笔钱是否被浪费、浪费了多少，与此刻的决策毫无关系。这套系统是别人赠送的，还是花了十亿美元买来的，都无关紧要——那笔钱已经没了，现在我们只能用手头已有的东西将就着办。这里可以采用的一个潜在「技巧」，是请来一位像首席财务官（CFO）这样的财务决策者，先说明大家即将对一笔已经花出去的钱产生情绪化反应，并在讨论真正的问题之前先谈一谈沉没成本谬误，这样人们就会有所警觉、保持理性，而那位（我们希望）受过专门训练、最善于处理此类情形的人也已在场并做好准备，以便及时遏制沉没成本所引发的情绪。妥善处理这种可能由情绪驱动的反应非常重要。此时绝不应试图去掩盖财务上或技术上的失误，而掩盖恰恰是情绪化反应所导致的结果。各方必须保持沟通，并保持超然与理性，才能真正应对需求。有些公司在这方面处理得很好，但许多公司则做不到，结果陷入困境，硬着头皮在已经做出的错误决策上一意孤行，多半是寄希望于不出什么乱子、没有人记得或察觉。要对抗这种反应。每个人都会有这种反应，它是杏仁核「战斗或逃跑」情绪反应的自然产物。

既然我们已经准备好去对抗对这一问题的情绪化反应，那么就可以开始着手解决「我们从这里该往哪儿走」的问题了。好消息是，我们当前所处的境况通常是「东西太多」而非「东西太少」。因此，我们有机会发挥一些创造力。值得庆幸的是，通常存在一些不错的选择，能让我们朝多个方向前进。

有一点非常重要，需要特别指出：我们所考察的解决方案，无一例外都比我们要替换掉的那套既定的倒金字塔之灾架构更加可靠，而非更不可靠。IPOD 是一种极其脆弱且危险的设计，我们大可以长篇大论地阐述诸如风险分析、单点故障、虚假冗余的谬误、关注冗余而非可靠性、依赖链等概念，但所有各方绝对必须理解的一点是：一台采用本地存储运行的单台服务器，比整套 IPOD 基础架构都更可靠。这一点如此重要，以至于必须再说一遍：如果一台单台服务器属于「标准可用性」，那么 IPOD 的可用性还要低于此。风险更高。如果在此阶段还有任何人因最终方案「缺乏冗余」或「缺乏复杂性」而感到担忧，我们就必须回到这一点上来——我们将要讨论的任何方案，其风险都不及此前已经设计并采购的那套方案。如果对未来的风险存有任何恐惧，那么在我们提升设计的可靠性之前，这种恐惧本应更甚。这一点怎么强调都不为过。IPOD 之所以畅销，是因为它很容易迷惑那些未受过风险分析训练的人，看上去很可靠，而实际上恰恰相反。

理解了上述内容，并运用一种称为「回读」（reading back）所接受的 IPOD 架构的技巧，我们就能得知：相关公司在采购 IPOD 之时，实际上已经接受了不具备高可用性（甚至连标准可用性都没有）这一事实。也许他们以为自己获得了这种可用性，但该架构根本无法提供。因此，在向前推进时，我们便有了一个选择：仅用一台采用自身本地存储运行的单台服务器来「将就」。这既简单又轻松，而且几乎在每一个方面都优于原定的 IPOD 设计。它运行和维护的成本更低，往往速度更快，复杂程度也低得多，同时可靠性还略高一些。

但是，仅仅退回到单台服务器，并寄望于在「别处」为其余已采购的设备找到用途，多半并不是我们的最佳选择。在某些情形下，如果 IPOD 原本只打算用于单一工作负载或一组工作负载，而企业的其他领域同样也需要设备，那么对原定的 IPOD 工作负载采用「单台服务器」方案，并将剩余设备用于企业的其他地方，会是非常有益的做法。

对 IPOD 堆栈进行再利用时，最常见的做法是将两个（或更多）计算节点重新配置为各自包含自身存储的全栈节点。这一步可能无需任何采购，具体取决于已经采购了哪些存储——可能只需在各系统之间调配硬盘，或者通常只需为此目的相对小额地采购一些额外的硬盘。

随后，可以将这些节点配置为两种高可用性模型之一。过去，出于成本方面的考虑，一种常见的设计选择是采用异步复制模型（通常称为 Veeam 方式），该模型会在节点之间复制虚拟机，并允许虚拟机被极为迅速地启动，从而将从计算节点发生故障到恢复之间的停机时间缩短到短短几分钟。

如今，完全同步的容错能力已经如此普遍地免费提供，以至于它在几乎所有情况下都已切实取代了异步模型。在这种模型中，存储会在计算节点之间以完全实时的方式进行复制，使得故障切换能够即时发生，而非延迟几分钟，并且实现零数据丢失，而非存在一个小的数据丢失窗口（例如 RPO 为零）。

在这一点上，人们似乎普遍会对复制产生一种反应，即担心复制会导致存储容量的损失。当然，这是事实。但必须理解的是，正是这种在原始 IPOD 设计中所缺失的复制，才为高可靠性奠定了坚实的基础。如果跳过这种复制，高可用性便是一个无法企及的梦想，而以「独立」模式使用本地存储的各个独立计算节点，反倒是最可靠的潜在选择。高可用性解决方案依赖复制与冗余来构建必要的可靠性，从而达到高可用性的资格。

这解决了如何处理我们的计算节点的问题，但仍留下一个问题：我们能拿外部共享存储设备——也就是那个单点故障，或者说倒金字塔设计的那个「尖点」——怎么办。要回答这个问题，我们应当先来看看这块存储可能是什么。

在倒金字塔设计中可能会用到三种常见类型的存储设备：DAS、SAN 和 NAS。我们可以把 DAS 和 SAN 归为一类，因为它们都是块存储的两个不同侧面，在我们的讨论中基本可以互换使用——二者的区别仅在于是否存在交换功能，而这种交换功能在我们的设计中可以按需添加或移除。NAS 的不同之处在于它是文件存储，而非块存储。

无论是块存储（DAS 或 SAN）还是文件存储（NAS），这一如今多余的设备最常见的用途之一，就是作为我们新虚拟化基础架构的备份目标。在许多情况下，该设备对于这项任务而言可能有些大材小用，其性能和功能通常都远超一个简单的备份目标所需，但对于任何关键的业务基础架构而言，良好的备份存储都很重要，宁可配置过剩也未必是坏事。企业往往试图在备份基础架构上偷工减料，而这恰恰是一个无需额外花钱便可大举投入其中的机会。

与备份存储同理，这块外部存储设备也可以被再利用为归档存储，或其他无需高可用性的「较低层级」存储。这是一种较不常见的做法，通常是因为每家企业都需要一套良好的备份系统，但只有部分企业才有办法善用归档存储层。

除了这两种常见而通用的存储模型之外，外部存储设备——尤其是当该设备为 NAS 时——还有一个常见用例，就是发挥其本职作用，作为一台独立于虚拟化基础架构之外的文件服务器来加以利用。对许多企业而言，文件服务并不像核心虚拟化基础架构那样对正常运行时间至关重要，而且其备份也远更易于维护和管理。通过将文件服务卸载到一台已经采购的 NAS 设备上，既可以减少需要在虚拟化基础架构上运行的虚拟机数量，从而降低对虚拟化基础架构的文件服务需求，又可以把通常属于存储最大用户之一的负载迁移到一台独立设备上，从而既能降低虚拟化基础架构的性能需求，也能降低其容量需求。如前所述，这样做有可能减少我们为计算节点上的本地存储采购必要的额外硬盘的成本，因此这对许多公司来说，都可能是一种非常受欢迎的、用以满足再利用需求的方法。

每家公司都是独一无二的，从实验室到归档、再到分层存储，备用存储设备有可能在许多地方得到有效利用。运用一点创造力、跳出固有思维框架，便可以将你独有的这套可用设备与你企业独有的一系列需求和诉求结合起来，找到使用这些设备的最佳去处——既让它与核心、关键的虚拟化基础架构相解耦，又仍能为组织带来价值。通过避开倒金字塔之灾，我们便能从已经投资购入的设备中获取最大价值，而不是去制造新的技术债务，进而不得不去做不必要的努力来加以克服。