没有稳定的硬件，任何程序都会失败。支持不良硬件带来的挫败感和费用会耗尽一个组织，延误进度并使所有相关人员感到沮丧。在斯坦福直线加速器中心 (SLAC)，我们创建了一种测试方法，可以帮助我们的团队 SLAC 计算机服务部 (SCS) 淘汰潜在的不良硬件，并以尽可能低的成本购买最好的硬件。商品硬件经常更换，因此每次我们购买系统时都会进行新的评估。我们每年大约对集群的修订系统进行两次小的重新评估。这个通用框架帮助 SCS 进行准确、高效的评估。

本文概述了我们的计算机测试方法和系统验收标准。我们将基本思想扩展到其他评估，例如存储。本文概述的方法帮助我们选择比以前购买的硬件更稳定、更易于支持的硬件。我们发现商品硬件的质量参差不齐，因此系统化的硬件评估方法和工具是必要的。本文基于一次硬件采购实例，但这些指南适用于为生产计算工作采购商品计算机系统的普遍问题。

在不断增长的集群环境中维护系统同质性是困难的，因为用于构建系统的硬件经常更换。这会产生负面影响，即增加管理、新硬件的软件支持和系统稳定性的复杂性。此外，引入新硬件可能会引入新的硬件错误。为了限制变更并有效管理我们的系统，SCS 开发了许多工具和要求，以使新硬件能够轻松适应我们的管理和计算框架。我们将功能减少到最少的程度，以适应我们的管理基础设施，并且仍然使用我们的代码产生有效的结果。这是我们的需求列表

制定需求清单是我们硬件评估项目的首要步骤之一。仅列出必备项而不是锦上添花项使小组脚踏实地。它还减缓了功能蔓延、硬件的无用添加以及执行任务的供应商特定方法。这个简单的要求淘汰了可能的供应商，并减少了在不需要的地方增加复杂性的趋势。通过这个简单的列表，我们选择了 11 家供应商参与我们的测试/投标过程。一些供应商提出了不止一种型号，因此总共评估了 13 种型号。

我们选择的 11 家供应商包括大型系统构建商到小型螺丝刀商店。参与评估的两个标准是满足基本要求列表并发送三台系统进行测试。我们想要测试系统 90 天。在许多情况下，我们不需要系统那么长时间，但有时间彻底调查硬件是很好的。

对于每个系统评估，三台系统中的两台被安装到机架上，第三台被放置在桌子上进行目视检查和测试。桌子上的系统被移除盖子并进行数码拍照。稍后，桌子上的系统用于电源和散热测试以及目视检查。另外两个系统以与我们所有集群系统相同的方式集成到机架中，但它们没有加入生产系统池。一些系统具有独特的物理尺寸和机架限制，这阻止了我们使用它们。

每个型号的系统都有一个评分表。评分表发布在我们工作组的网页上。每个问题都在网站上注明，我们尝试联系供应商以解决任何问题。通过这种方式，我们测试了系统和供应商与我们合作并解决问题的意愿。

我们在评估的所有系统中都有各种各样的经验。一些供应商只是向我们运送了另一种型号，一些供应商与我们一起解决了问题。其他人回应说这不是问题，还有一两个忽略了我们。这很快缩小了我们认为可管理的系统范围。

在整个测试期间，如果系统未完成特定任务，则它正在运行硬件测试脚本或老化脚本。每个系统都运行老化至少 30 天。没有供应商会进行超过 72 小时的老化，这使我们能够看到长期故障。其他实验室报告说，他们也在长期测试周期中看到了问题。

总的来说，我们希望评估所有系统的多个方面：物理工程质量、操作、稳定性和系统性能。最后，我们评估了每个供应商的合同、支持和响应能力。

放置在桌子上的系统根据以下几个标准进行评估：构造质量、物理设计、可访问性、电源质量和散热设计。首先，系统的构造质量差异很大。我们发现了弯曲、卡住的带状电缆、堵塞的气流、柔性机箱和廉价的多螺丝访问点，对于专业产品来说，这些都难以置信地糟糕。我们发现了糟糕的设计决策，包括电源开关偏移到系统背面，一旦系统安装到机架上，几乎无法访问。从积极的方面来看，我们遇到了一些精心设计的系统。

我们的评估包括气流和散热质量、机架安装性、尺寸/重量和系统布局。诸如前部的驱动器托架之类的功能也将被记录下来。气流是发热 x86 CPU 的一个大问题，尤其是在受限空间（如 1U 机架系统）中。一些系统有堵塞的气流或几乎没有循环。热量会导致系统不稳定并缩短运行寿命，因此良好的气流至关重要。

机箱的刚性、没有锋利的边缘、系统如何组装在一起以及布线也属于这一类。在您被系统机箱划伤或因为托运人处理不当且机箱太弱而导致大量“到货即坏”之前，这些因素可能看起来很小且无趣。我们必须使用这些系统很多年；一个简单但明显的错误是一个痛苦，并且可能在维护方面很昂贵。

免工具访问应该是所有集群系统的标准配置。当您有数千个系统时，您总是在维修其中一些系统。为了保持较低的维修成本，零件应该可以快速且轻松地更换。拧下和拧上六到八个微小的机械螺钉会减慢对硬件的访问速度。零件的安装方式使一个零件不必取出即可到达另一个零件，并且可以轻松访问驱动器，这些都是优点。我们没有要求的一些功能，例如机箱前部的键盘和显示器连接，很好，但不是真正必要的。

我们使用 Dranetz-BMI 电源质量分析仪（参见侧边栏）测试了电源的质量。文献中经常提到电源校正，但我们看到的相对于公布的数字的测量值却大相径庭。例如，一个电源，其公布的功率因数校正为 0.96，实际上具有 0.49 的校正。当乘以 512 个系统时，这可能会产生可怕的后果。我们测试了系统在空闲和重负载下的情况。质量范围差异很大，是选择可管理系统的重要因素。

物理检查、功能、散热和电源质量测试在流程早期就淘汰了许多系统。立即消除这些系统减少了需要进行广泛测试的系统数量，从而减少了在整体测试上花费的时间。系统工程、设计和零件质量范围很广。

老化（通常称为烧机）是制造商用于对系统进行压力测试以在将故障硬件投入使用之前找到故障硬件的过程。许多开源老化程序可用。一个常见的程序是 Cerberus 测试控制系统 sourceforge.net/projects/va-ctcs。它是一系列测试和可配置的包装脚本，最初是为 VA Linux Systems 的制造而设计的。Cerberus 非常适合老化测试，但我们也根据我们对系统故障的了解开发了特定的测试。我们通过我们的脚本比单独使用更通用的工具更频繁地成功地使系统崩溃。通过使用从系统工作经验中开发的程序进行测试可能比单独使用 Cerberus 更有效，因此请考虑创建测试工具存储库。

仔细阅读说明，并理解老化程序可能会损坏系统；您运行 Cerberus 即表示您承担风险。此外，还有许多软件旋钮可以转动，因此在启动程序之前请考虑您正在做什么。但是，如果您要构建集群，则需要测试系统稳定性，而老化脚本旨在测试正是这种质量。

在我们测试系统时，我们小组的两名成员根据我们在生产系统中看到的一些问题编写了自己的老化脚本。基准测试试图衡量系统性能，并且通常具有复杂的方法，而老化脚本是简单的过程。系统在负载下运行，要么通过，要么失败。失败会使系统崩溃或报告错误；通过通常不报告信息。我们还运行了生产代码，这发现了更多问题。应尽可能运行生产代码。例如，通过了初始设计检查测试的系统之一在重负载下失败。

有大量的基准测试程序可用。最好的基准测试是运行将在生产中使用的代码，就像在老化期间运行生产代码一样。这并非总是可能的，因此一套标准的基准测试是一个不错的替代方案。此外，标准基准测试建立了系统之间的相对性能值，这是一个很好的信息。我们不期望商品芯片组和 CPU 的性能差异很大。但是，当涉及不同的芯片组和主板组合时，性能差异确实存在，这在本测试跟踪中就是这种情况。

我们还编写了一个包装器，用于许多标准基准测试工具，并将其打包到一个名为 HEPIX-Comp（高能物理 - 计算）的工具中。它是一个便利工具，而不是基准测试程序本身。它允许简单的make server或make network来测量系统的不同方面。例如，HEPIX-Comp 是以下工具（以及其他工具）的包装器：Bonnie++、IOZone、Netpipe、Linpack、NFS Connectathon 包和 streams。

理解在系统上运行的代码的特性对于使用标准基准测试进行评估至关重要。例如，如果您受到网络限制，则快速前端总线不如网络带宽或延迟重要。这些是测量系统不同方面的好基准测试。例如，streams 测量 I/O 内存子系统吞吐量，这对于具有分层内存架构的系统来说是一个重要的指标。Bonnie++ 测量 I/O 性能的不同类型的读/写组合。

许多供应商报告的性能给出了尽可能好的画面。例如，与随机的小写入相比，顺序写入作为 I/O 性能指标非常乐观，后者更接近我们的实际情况。在生产中使用的 Linux 安装下运行标准化的测试套件建立了基线测量。如果系统针对一个基准测试进行了调整，则它可能会以牺牲另一个系统性能因素为代价很好地执行该基准测试。例如，针对大块顺序写入调整的系统会损害小随机写入。基线基准测试套件至少显示了苹果对苹果的比较，尽管不是潜在的最佳性能。因此，这绝不是一个完美的系统，而是在表征系统性能的评估中的另一个数据点。

所有数据都被收集并放置在为评估创建并在小组之间共享的内部网页上。我们每周开会一次，并报告测试的进展情况。在我们的工程测试完成后，我们选择了一个系统。

非工程因素（合同协议、保修和条款）对于为生产工作引入新系统的成功至关重要。保修条款和期限会影响系统支持的长期成本。另一个考虑因素是供应商公司的财务健康状况。如果供应商不存在以兑现保修，则保修几乎没有用处。

验收标准也至关重要，尽管很少在为时已晚之前谈论。这些标准确定了部署中的时间点，在该时间点，供应商完成工作，并且组织愿意接受系统。这一点应以书面形式在您的采购订单中注明。如果供应商将系统放在路边，并且稍后在推出期间出现一些与硬件相关的问题，您需要在您的权利范围内要求供应商修复系统问题或移除系统。在供应商方面，需要明确区分什么是硬件问题或软件问题。供应商通常必须与客户合作才能确定问题的性质，因此需要将成本计入系统价格中。

本文概述的方法的成功之处在于，在进行如此广泛的评估后，运行我们选择的系统变得多么容易，因此也更便宜。我们还有其他系统是在没有进行此处概述的资格认证的情况下购买的。在进行更好的评估后，我们的问题更少，并且我们能够在其他领域完成更多工作，例如工具编写和基础设施开发。而且，我们和我们的研究人员都不那么沮丧了，因为生产中的硬件很好。