侏罗纪公园效应

“如果允许我说几句……嗯，我来告诉你们，你们在这里所使用的这种科学力量，问题出在哪里：获得它根本不需要任何自律。你们读了别人已经做过的成果，然后迈出了下一步。你们并没有自己去赢得这份知识，所以你们对它不承担任何责任。你们站在天才的肩膀上，以最快的速度去实现某样东西，而在你们甚至还没搞清楚自己拥有的是什么之前，就给它申请了专利、把它包装起来、贴到塑料午餐盒上，如今……” —— Ian Malcolm 博士，《侏罗纪公园》

在考虑搭建存储服务器或 NAS 时，人们普遍有一种感觉，认为自己所需要的是一个“NAS 操作系统”。我发现这是一种奇怪的反应，因为 NAS 这个术语的含义不过是“带有专用存储接口的文件服务器”。换句话说，就是一个对外暴露功能有限的文件服务器而已。我们之所以选择物理 NAS 设备，是为了获得集成式的支持，有时也是为了某些特殊的专有功能（NetApp 就是一个典型例子，它提供广泛的 SMB 和 NFS 集成以及一些非常独特的 RAID 和文件系统选项；又如 Exablox 提供完全托管的横向扩展文件存储和 RAIN 式的保护）。用 NAS 取代传统文件服务器，在很大程度上是一种相当晚近才出现的现象，而我发现这种现象往往源于一种误解，或者源于这样一种印象——以为管理文件服务器（IT 中最基础的工作负载之一）是一件特殊或困难的事情。文件服务器通常被认为是最基础的服务器形态，而且传统上人们使用“服务器”一词时，如果不加额外说明，所指的往往就是文件服务器；它也是唯一一种普遍集成到桌面系统中的服务器形态（每一台 Mac、Windows 和 Linux 桌面机都可以充当文件服务器，而且这样做非常常见）。

当然，转而使用 NAS 而非传统文件服务器来满足你的存储需求并没有什么不妥，尤其是因为一些现代 NAS 选项（如 Exablox）提供了横向扩展以及大多数操作系统所不具备的存储选项。但看起来，使用 NAS 取代文件服务器这一趋势，已经导致 IT 专业人员在重新转回考虑文件服务器时出现了一些奇怪的行为。我怀疑这是一种连锁效应：人们遗忘了 NAS 有时之所以受青睐的原因以及目标层面的思考，只剩下“我应该有一个 NAS”这个念头残留下来，以至于当重新审视文件服务器选项时，会产生一种“要拥有一个 NAS”的冲动，而不管对此是否存在合乎逻辑的理由。

首先我们必须认识到，NAS 的总体概念其实很简单：拿一台传统文件服务器，通过移除各种选项来加以简化，并将其与所有必要的硬件打包在一起，做成一个简化的设备，从接口一直到旋转的磁盘以及两者之间的一切，都包含完整的支持。当用户需要确定 RAID 级别、磁盘类型、进行有效监控等等时，存储可能会很棘手。NAS 通过将硬件集成到平台之中来解决这一问题。这使事情变得简单，但也会增加风险，因为你的支持选项更少，自己修复或更换部件的能力也更弱。从文件服务器转向 NAS 设备，几乎完全是关于“支持”，并且通常意味着对单一供应商的强烈承诺。你选择 NAS 路线，是因为你希望在一切事务上都依赖某个供应商。

当我们转向文件服务器时，走的是相反的方向。文件服务器就是一台传统的企业级服务器，与其他任何服务器并无二致。你从一家供应商（HP、Dell、IBM 等）购买服务器硬件，从另一家供应商（Microsoft、Red Hat、Suse 等）购买操作系统。你指定所需的部件和配置，于是你拥有的就是适用于整个 IT 领域的最常见的计算模式。借助这一模式，你通常使用的是标准化的通用部件，从而能够轻松地在硬件供应商之间以及软件供应商之间迁移。你拥有“供应商冗余”选项，而且通常一切都是使用开放的标准协议完成的。你获得了极大的灵活性，可以像管理服务器集群中的任何其他成员一样去管理和监控你的文件服务器，包括将其完全虚拟化。你放弃了 NAS 的纵向集成，换来了横向的灵活性与标准化。

因此，奇怪的是，当人们回归通用模式时，却又去寻求一种俗称为 NAS OS 的东西。这类东西的常见例子包括 NAS4Free、FreeNAS 和 OpenFiler。这一类产品通常不过是在一个标准操作系统（通常是 FreeBSD，因为它有理想的许可证条款；或者是 Linux，因为它广为人知）之上加了一个“存储接口”，并没有任何在普通操作系统中不存在的特殊或额外功能。理论上，它们是一种“单一功能”的操作系统，只做一件事。但事实并非如此。它们其实是通用操作系统，只是在顶部额外加了一层 GUI 管理层。有人或许会说，大多数物理 NAS 产品本身也是如此，但它们通常即便在存储层面也包含定制化的工程设计、特殊功能，而最重要的是，包含集成式的支持栈以及对底层操作系统“通用性”的真正隔离。“NAS OS”并不是通用操作系统的一个更简单的版本，而是一个更复杂、却功能更弱的版本。

另一个奇怪之处在于，通用操作系统除极少数例外情况外，本身就已经自带了非常简单、极为人熟知且获得完整支持的存储接口。例如，几乎每一个版本的 Windows 或 Linux 服务器，很久以来都已经为这些功能内置了简单的图形界面。系统管理员往往对这些内置的 GUI 嗤之以鼻，认为对于一台简单的文件服务器而言它们太过“笨重且不必要”。因此，更令人费解的是，人们竟会希望再去添加一个第三方 GUI——一个并非由操作系统团队打补丁和测试、也并非标准化地为人所知和受支持的 GUI——因为这与使用服务器的通行理念和实践背道而驰。

而这正是侏罗纪公园效应登场的地方——操作系统供应商（Red Hat、Microsoft、Oracle、FreeBSD、Suse、Canonical 等等）都是拥有惊人工程团队、代码审查、测试、监督以及企业级支持生态系统的巨人。而“NAS OS”供应商通常是非常小的公司，有些甚至只有一名兼职人员，他们站在这些巨人的肩膀上，构建出某样他们明知自己能做的东西，却从未停下来问一句他们是否应该做。其结果是，这些产品相比其纯粹的操作系统对应物完全是负面的——它们既没有让系统管理变得更容易，也没有填补市场服务供给中的任何空白。稳固、可靠、易于使用的存储早已唾手可得，市场上的这个位置并不需要更多的供应商来填补。

人们在考量 NAS OS 时经常套用的逻辑是它们“易于安装”。这或许成立，也或许并不成立，因为这里的“易”必然是一个相对的概念。要想具有任何价值，NAS OS 就必须是相对于同一操作系统的标准版本而言易于使用。因此，就 FreeNAS 而言，这就意味着要与 FreeBSD 相比。FreeNAS 必须在实现相同的专用功能时，明显比 FreeBSD 更易于安装设置。而这一点很容易成立，安装一个 NAS OS 通常相当简单。但这种轻松只是一剂治标的安慰药，而且是 IT 专业人员需要高度警惕的一剂。在 IT 中，让某样东西易于安装并不是优先事项；真正重要的是，让某样东西易于运维、并在出现问题时易于修复。易于安装固然不错，但如果它的代价是让你无法理解系统是如何配置的，并使运维修复变得更加困难，那它就是一件非常、非常糟糕的事情。NAS OS 产品往往会危险地让人轻而易举地将一个产品投入生产环境去承担存储角色——而存储角色几乎总是任何环境中任何服务器最关键或近乎最关键的角色——可 IT 团队对维护、运维，乃至最重要的、在出问题时进行修复，却毫无经验，也很可能毫无相应技能。我们所需要的恰恰相反，是一个易于运维和修复的系统。这才是要紧的事。于是我们就有了第二个“站在巨人肩膀上”的案例：构建出一个我们明知自己能做、却并不知道自己是否应该做的系统。

使这一问题雪上加霜的是，那些恰恰觉得自己需要求助于 NAS OS 来“让存储变简单”的人，由于 NAS OS 本身的性质，正是对其而言运维支持和系统修复最为困难的那群人。对底层操作系统驾轻就熟的系统管理员，自然不会把 NAS OS 视为一种好处，并且在大多数情况下会对其避而远之。偏偏是那些运行一个并未被完全理解的存储平台对其而言最为危险的人，最有可能去尝试它。而且，正如我们所能预料的那样，大多数 NAS OS 供应商赚钱的方式，正是来自那些客户在部署后、一旦进入生产环境便陷入困境时所拨打的安装后支持电话——这样客户就只能任由供应商收取高昂得离谱的支持费用而无可奈何。让产品易于安装、却难以修复，符合这些供应商的利益。在这里，一切都在与 IT 专业人员作对。

如果我们拿一个常见的例子——FreeNAS——来看，就能明白这是一种多么糟糕的“困难”错配。FreeNAS 就是在顶部额外加了一个界面的 FreeBSD。凡是 FreeNAS 能做的事，FreeBSD 都能做。转用 FreeBSD 并不会损失任何功能。无论在哪种情况下，一旦出现故障，系统管理员都必须对 FreeBSD 有良好的实操知识，才能进行修复。这是无法回避的。FreeBSD 知识在业内很常见，寻求外部帮助相对容易。使用 FreeNAS 则增加了若干复杂性，其中最大的一项在于：由 FreeNAS GUI 所做的任何及所有定制配置，都是排障时所需的专门知识，而这是叠加在运维 FreeBSD 本就已经需要的知识之上的。因此，这既是一套庞大的知识集合，也意味着更多可能出故障的环节。而且这还是一套相对不常见的知识集合，因为 FreeNAS 是一家小供应商出品的小众存储产品，而 FreeBSD 则是一个主流的企业级 IT 平台（再者，所有使用 FreeNAS 的场景都属于使用 FreeBSD，但在所有 FreeBSD 的使用中，只有极小一部分属于 FreeNAS）。由此可见，使用 NAS OS 只是一次又一次地增加风险。

同样的问题也延续到了围绕这些产品成长起来的社区之中。如果你向围绕 FreeBSD、Linux 或 Windows 的社区寻求指导和帮助，你接触到的是大量 IT 专业人员、技术娴熟的系统管理员，以及那些具备商业和企业经验的人。当然，业余爱好者、不明就里者和其他人也会参与其中，但这些都是企业级 IT 平台，在实施这些产品时，整个行业的知识都向你敞开。把这与一个 NAS OS 的社区作个对比。由于其本身的性质，只有那些在标准操作系统的管理和/或存储基础知识上苦苦挣扎的人，才会去考虑一个 NAS OS 软件包，因此这自然而然地过滤了其社区的成员构成，使其只包含了我们最好避免向其征求意见的那类人。这就在存储及存储产品周围催生出一种与世隔绝的错误信息和误解的文化。各种谬论层出不穷，所给出的指导往往变得鲁莽而危险，行业最佳实践被弃之不顾，仿佛数十年积累的经验从未发生过一样。

NAS OS 还通常会在打补丁和更新方面引入滞后。一个 NAS OS 几乎总是、也几乎必然地会在安全和稳定性更新上落后于其母操作系统，并且在重大功能上往往会落后数月乃至数年。在一个非常著名的案例中，OpenFiler 这款产品构建在一个上游的非企业级基础（RPath Linux）之上，而后者缺乏社区和供应商支持，最终失败并遭到遗弃，使下游用户——包括所有使用 OpenFiler 的人——在没有所需生态系统支撑的情况下被弃之不顾。使用一个 NAS OS 意味着你不仅要信任那个制作基础操作系统的、庞大的、企业级的、广为人知的主操作系统供应商，还要信任那个 NAS OS 供应商。而如果 NAS OS 供应商是以企业级的基础操作系统为基础来构建产品的，那么它失败的可能性要高出几个数量级。

存储是一项关键功能，不应被草率对待，也不应被忽视，仿佛它的关键性根本不存在似的。NAS OS 诱使我们快速安装然后抛诸脑后，指望着永远不会出岔子，或者指望我们能在坏事发生之前就彻底转去做其他角色或跳槽到其他公司。它把我们置于一种在失败最具破坏性之处必将失败的境地。当一台典型的应用服务器出现故障时，我们总能把文件从它的存储中拷出来，然后从头再来。而当存储出现故障时，数据会丢失，系统会宕机。

“John Hammond：所有大型主题公园都会有延误。1956 年迪士尼乐园开业时，什么都没法运转！

Ian Malcolm 博士：是啊，可是，John，加勒比海盗游乐项目要是坏了，那些海盗可不会把游客给吃了。”

当存储失败时，企业就会失败。在搭建存储时贪图省事的捷径、忽视长期的支持需求，并向那些已经把经验丰富的存储和系统工程师过滤出局的社区寻求建议，会大幅增加风险。可悲的是，NAS OS 的本质在于：人们之所以求助于它的那个理由（缺乏构建系统所需的深厚技术知识），恰恰就是他们必须避开它的那个理由（对支持的需求甚至更大）。而对于那些使用 NAS OS 实际上足够安全的人——即拥有非常深厚而广博的存储与系统知识的人——他们很少会考虑这些产品，因为对他们而言这些产品毫无益处可言。

归根结底，尽管 NAS OS 这一概念听起来很美妙，但它并非万灵药；NAS 的价值并不会从物理设备的世界延续到已安装操作系统的世界，而标准操作系统的价值实在太大，以至于 NAS OS 无法切实地带来真正的价值。

“Alan Grant 博士：Hammond，经过一番考虑，我决定，不为你的公园背书。

John Hammond：我也一样。”