三十多年前，在高性能计算的初期，服务器领域还没有所谓的商品硬件。各个机构都有自己的专有平台，他们不得不尽可能地从这些平台上榨取更多的性能。可靠性通常是事后考虑的，因为考虑到当时的架构，你对可靠性没有什么办法。然而，由于那个时代的低数据量和有限的算法，早期的HPC架构是有效的。

随着超级计算机和HPC集群的不断发展，这些专有系统无法有效扩展，尤其是在其存储架构方面。两台计算机将组成一“对儿”，共享一个后端存储，但这些组成的“对儿”是为了相对隔离地运行。尝试将这些“对儿”扩展到数百个时，扩展就会暴露出架构弱点。

在快速发展的今天情况很明显：HPC正在为规模化的可靠性而努力。10多年前，谷歌证明了在软件定义系统的控制下，硬件对于超大规模处理来说既便宜又有效，但HPC市场仍然坚持其老派的、基于硬件的模式。也许这是由于普遍的行业势头或在既定做法的集体舒适区工作的原因。无论是哪种情况，以硬件为中心的存储弹性方法都需要改变。谷歌革命性的以软件为中心的扩展架构方法为更高的运营效率打开了大门，现在是时候让HPC世界学习谷歌的经验教训了。

谷歌拒绝了让人头疼的硬件

与HPC 世界不同的是，谷歌一开始拥有一支由分布式系统专家组成的工程团队，他们带来了不同的视角。当然，谷歌也有过失误，但在横向扩展计算方面，这家搜索巨头的成就毋庸置疑。

首先，谷歌改变了依赖专门的甚至是定制的服务器的趋势，这些服务器是按照严格的质量水平建造的，试图做到高度弹性（往往是不成功的）。相反，该公司实施了大量的商品、现成的服务器，通过软件实现集群级的弹性。这种平台方法被称为仓库级机器。从扩展的角度来看，这是一个明智的做法。随着系统的规模和复杂性的增加，它们的故障也变得越发普遍和昂贵。这就是为什么大多数HPC存储系统的故障导致的问题远远多于其他领域的类似故障，这些领域都是以软件为中心的架构。

谷歌认为讨论如何防止故障是毫无意义。相反，关键是要预测故障并减轻其影响。这一观点的转变完全破坏了以硬件为中心的范式。谷歌证明，有了商品硬件，就有可能超越试图桥接数百对儿计算机并且建立一个独立区域，其中任何一点的失败都是允许和可预期的。

2003 年推出并在HPC 环境中仍然非常流行的Lustre 文件系统说明了这一点。因为它是那个时代的产物，Lustre 要求在硬件中实现弹性。这增加了复杂性和难度，因为仅靠传统的RAID 控制器是不够的。为了跨越多台服务器，工程师必须对系统进行硬连线，以允许多台服务器查看、安装和共享彼此的驱动器——但一个驱动器永远不能由两个系统同时安装。因此，两台服务器必须能够相互关闭，而这需要有一个带有可管理电源插座的集线器。

当HPC 集群处理PB 级数据时，这种方法是可行的，但在处理达到数十或数百PB 的现代数据集时，扩展性会受到很大限制。以这种规模跨系统管理存储是一场噩梦，这是因为以硬件为中心的持续存在。谷歌意识到了这一点，并表明在软件中管理弹性变得更加容易。

卓越的软件

1989 年，计算机科学家莱斯利·兰波特(Leslie Lamport) 撰写了一篇论文，其中他定义了Paxos 算法，该算法以希腊岛屿命名，（虚构的）议会必须与议员们的讨论中得出结论和达成共识。这是继 Lamport 早期关于“拜占庭将军问题”（其解决方案将继续影响从现代飞行控制到比特币的一切）的工作之后，继续他对分布式系统容错的探索。Lamport 对Paxos 的第一次探索陷入停滞，但他在2001 年发表了一个简化的处理方法 ，获得了关注。

Google 在其Chubby 分布式锁服务中实现了Paxos 算法。Ceph、Apache Cassandra、Amazon Elastic Container Services 和其他公司纷纷效仿。在每种情况下，一个主要目标都是减轻硬件依赖性并允许软件管理跨机器的数据冗余，同时处理任何故障。现在，不再有高可用性服务器的小“孤岛”，一百甚至数千个节点可以作为一个单一的、有凝聚力的、自我修复的整体一起统一行动。

软件定义的弹性对于谷歌的扩展及其市场主导地位至关重要，源自基于软件的基础架构的运营效率取决于使人为干预成为例外。更新不应该需要人，掉线的系统不应该（立即）需要人。相反，最少的管理人员应该能够管理比以硬件为中心的弹性模型所能达到的更大数量级的集群资源。

同样，集群管理员应该能够独立于系统工作。在2021 年，没有人需要在凌晨4:00 亲自操作HPC 集群来关闭系统，只是为了执行更新。集群不应规定操作，也不应规定用户何时可以和不能使用系统。一旦您将维护与系统分离并允许软件自动化流程，所有相关人员的效率都会提高。

HPC，是时候建立一个更好的范例了

人们可以将这种硬件与软件的二分法视为一个运营模型问题，因为运营在很大程度上涉及人力成本。1990 年代以硬件为中心的HPC 解决方案证明了他们高昂的人力成本是合理的，因为当时的专用硬件非常昂贵。总的来说，这些成本被小型部署所控制。但是，当人力成本随系统规模线性增长时，以硬件为中心的模型显然会出现操作问题。数据负载继续呈指数级增长，但HPC 仍然存在20 年历史的存储架构以及随之而来的所有人力成本。

在HPC 世界之外，业界迁移到Hadoop 进行大规模数据分析，但Hadoop 可能比HPC 更适合谷歌类型的工作负载。同样，这也不是科学家使用MapReduce 运行他们的应用程序的理由。这是关于谷歌的战略，而不是它的战术。它是关于抛弃HPC 的传统架构，以实现提升可扩展的增长和运营效率。HPC 确实成功地采用了对象存储，因为它可用、可扩展、可管理且简单。现在，如果运营商接受基于真正的超大规模设计的系统，HPC 文件系统也可以这样做。

无需继续使用专有或传统的存储方法。如果您的HPC 工作仍然受到基于硬件的弹性和低效维护的限制，也许现在是时候效仿Google 的例子并向前迈进一大步了。

转自Bjorn Kolbeck, CEO of Quobyte