在过去的十年中，高性能计算 (HPC) 一直由数千台通过统一网络基础设施连接的 Linux 服务器主导。HPC 集群的定义主题在于集群的统一性。这种统一性在应用层最为重要：集群中所有系统之间的通信必须相同，硬件必须相同，操作系统必须相同。任何这些特性的差异都必须作为用户的选择呈现。在 HPC 集群上运行软件的统一性和一致性至关重要，并将 HPC 集群与其他 Linux 集群区分开来。

这种统一性也随着时间推移而持续存在。升级和安全修复绝不应影响应用程序的正确性或性能。然而，HPC 环境中的安全问题需要及时应用更新。这两个要求是冲突的，需要通过有据可查的流程进行管理，这些流程包括测试和定期停机。

环境分子科学实验室 (EMSL) 在过去十年中开发了一个管理这些要求的流程。EMSL 为美国能源部 (DOE) 和开放科学界提供 HPC 支持。这个流程使 EMSL 在维护一个安全平台方面具有优势，该平台用于大型计算化学模拟，以补充 EMSL 进行的仪器研究。

EMSL 开发的维护 HPC 集群的流程根植于标准软件测试模型。该流程包括三个阶段：构建测试、集成测试和生产。这些阶段在硬件、软件和组织方面都有自己的要求。其他重要的系统包括配置管理、持续监控和存储库管理。所有这些系统都在整个流程中发挥着明确的作用，并且需要专用的硬件（不属于生产集群）来支持它们。

构建集成阶段需要两个主要组件：软件包存储库管理和持续集成软件。这两个组件相互作用，使软件开发人员和系统管理员能够在更新影响集成测试之前了解各个软件中的错误。这种形式的测试对于关键应用程序的自动化非常重要，因为它有助于促进运营和开发团队之间的沟通。

集成测试阶段需要一个测试集群，该集群应尽可能接近生产集群。对于 HPC 而言，生产集群和测试集群之间的主要区别在于规模。测试集群应该具有较少的节点，但至少应包含生产集群中每种 Linux 主机的一个节点，包括配置管理和持续监控。此外，Linux 主机应尽可能与生产配置匹配。生产集群和测试集群在硬件和软件方面的任何配置偏差都应有据可查。该文档将有助于定义在生产中断期间可能遇到的可接受的技术风险。

生产集群是构建和测试阶段所有准备工作的最终成果。在计划停机之前，应确定停机期间记录的任务以及计划的操作系统升级。这些文档的存储应便于开发人员和管理层查看，并便于运营人员修改和跟踪问题。除了计划之外，还应遵循将配置管理和持续监控从测试转移到生产的记录流程。

我们已经确定了一些所需的基础设施，用于支持和自动化管理您自己的 Linux HPC 操作系统的流程。在构建集成阶段，需要一个专用的构建系统以及软件包管理和持续集成软件。集成测试阶段需要测试集群硬件以及持续监控和配置管理软件。最后，生产集群也应与配置管理和持续监控软件集成。

这里未涵盖几个系统，但它们对于集成到流程中至关重要。应考虑为流程的每个阶段提供特定于站点的备份解决方案。此外，还应考虑将自动化配置系统与此流程结合使用。在 EMSL，我们同时使用了这两种系统，但这当然不是流程所必需的；它只是让人晚上睡得更好。

构建阶段是流程的开始。系统有三个输入：二进制软件包、源代码软件包和工单。这三个输入产生三个输出：一组基本存储库、一组用于上游贡献的补丁和一个修改软件包的覆盖存储库。这些输入和输出提供了您的站点所需的操作系统修复程序，同时将它们贡献回支持它们的社区。为了完全理解这个流程，请允许我分解组件并讨论它们的要求。

软件包存储库管理系统在整个流程中使用，但首先出现在构建阶段。软件包存储库管理系统应能够从上游发行版下载二进制软件包存储库。它还应该能够使下载的存储库与上游发行版保持同步。第一组存储库应该是上游发行版的本地副本，包括每日同步的更新。作为一个附加功能，软件包存储库管理系统还应该能够有选择地删除某些软件包，使其不被下载。此功能补充了覆盖存储库的内容。覆盖存储库是放置软件包自定义构建版本以增强基本发行版的地方。

覆盖存储库的内容特定于发行版中需要单独管理的关键应用程序。例如，HPC 站点可能更关心内核构建、开放光纤企业发行版 (OFED) 和实现消息传递接口 (MPI) 的软件。然后，从基本发行版中删除此软件，并将其添加回覆盖存储库中。此外，可以有多个覆盖存储库。例如，安全问题可能要求内核与发行版的其余部分分开管理。将内核放在单独的覆盖存储库中意味着可以跳过测试阶段，影响最小，并且仍然可以维护安全的集群。

覆盖存储库中的软件包已打补丁，以满足组织的需求。应使用持续集成系统来修补特定的软件包，并使用未来的更新维护构建。这些补丁应连同需要此补丁的充分理由一起发布回上游发行版。其中一些补丁可能会被上游开发人员接受并进入发行版，而另一些补丁可能由于发行版维护人员的策略决策而需要数年才能进入。

持续集成系统的另一项工作是支持对发行版不支持的附加组件进行持续构建和测试。这些附加组件可能是特定于站点的应用程序或发行版不支持的开源软件。许多开源软件项目都支持与企业发行版的兼容性，但由于财务项目支持原因，它们不寻求发行版包含。

构建阶段的最后一部分是工单跟踪系统。该系统为软件包开发人员提供有关需要修复的内容以及修复方式的信息。这些工单可能直接来自用户或集群管理员。此外，用户和集群管理员可能使用完全不同的工单系统。流程的这一部分有助于促进组之间的沟通。拥有工单列表可以进行关于优先级的客观讨论，并确保工单不会被遗忘。工单可能会保持打开状态数年或数天，具体取决于优先级和工单创建速度。工单不会在软件包开发人员处停止；集群管理员在后续阶段使用此系统。

软件包管理和持续集成系统是自动化流程，而工单跟踪系统需要人工交互。这些系统可以部署在单个主机上。但是，流程的后续阶段要求存在软件包存储库的三个副本。此外，持续集成系统具有与工单跟踪系统集成的功能。启用此功能确实需要持续集成构建过程具有一定的稳定性。这些系统中的许多细节在此处未涵盖，将在后面介绍。

集成测试阶段需要软件包存储库管理、持续监控和配置管理系统。这三个系统有助于将测试集群维护在某种状态，以便可以通过一些自动化流程完成集成测试。此外，测试集群硬件配置应代表生产集群的所有关键方面，从而减轻生产集群的风险。

软件包存储库管理系统在流程的所有三个阶段都发挥着作用。这是流程的第一个阶段，在此阶段，带有附加组件的软件包在类似生产的配置中进行测试。每日存储库（包括覆盖存储库）将同步到一组测试存储库，以包含在测试集群中。此同步确保执行测试的一致环境。

每次将更新同步到测试存储库时，都应在测试集群上执行一组集成测试。这些测试应设计为模拟生产集群的使用情况。重要的是将测试重点放在关键用户级应用程序和您已替换并放入覆盖存储库的操作系统部分。持续集成系统可以运行这些测试并发出故障警报。

集成测试中的失败应在工单跟踪系统中报告。这是完成开发循环的路径之一。其他工单包括部署和重新安装问题。生产集群中复杂的内部基础设施也可能出现升级问题，这些问题也应被跟踪。测试集群也应按照与生产集群相同的程序进行管理。应在测试集群上实践这些程序，以最大限度地减少在更新部署到生产集群之前的工单数量。所有这些任务都应重复执行，直到新工单的添加减少到最大限度地降低生产集群的风险。

配置管理和持续监控系统在测试环境和生产环境之间以类似的方式设置。这两个系统有助于维护生产状态，防止意外的硬件或软件更改，因此，在进行有意的更改时需要对其进行测试。这些更改需要轻松集成到生产环境中。因此，将这两个系统的配置维护在支持分支和合并的源代码管理存储库中也是明智之举。这允许使用标准流程进行更改，并在测试环境和生产环境之间推送这些更改。

当工单数量减少并且是时候将更改推送到生产集群时，此阶段会产生五个结果：一组更新的软件包存储库、一组需要在停机期间完成的任务、要在生产集群上使用的更新程序、需要合并到生产环境的配置管理和持续监控系统的更改。软件包开发人员和集群管理员都需要在程序更改和停机任务上进行协作。这种协作在两个组内部的 Wiki 环境中效果良好。这些输出结束了流程的集成测试阶段。

流程的生产阶段采用集成测试阶段的结果，并将其应用于生产集群。此阶段使用与测试阶段相同的所有流程，但有一些修改。此外，此阶段是用户可以影响流程更改的阶段。组之间通过软件进行的更正式的沟通方法也增加了。此阶段的最终输出也会反馈回来，以帮助完成开发和测试周期。在此阶段完成后，流程完成，更新后的生产环境将可维护。

此阶段的第一部分是复制软件包存储库所做的工作。但是，此阶段要求生产存储库的副本与集成测试存储库同步。这是流程所需的最后一组软件包存储库。此外，还应从各自系统的集成测试配置中创建持续监控和配置管理系统的生产配置。

生产集群的用户在此阶段获得流程的输入。根据用户的要求，这可能是工单跟踪系统的不同实例，也可能是软件包开发人员和集群管理员使用的同一实例。无论哪种方式，跟踪此输入非常重要，以确保它在流程中顺利进行而不会被遗忘。

沟通是流程此部分的关键。从测试阶段，我们知道需要在生产集群停机期间完成哪些任务，以及预计需要多长时间。这有助于管理层确定停机的成本和收益，以确定前进的道路。当生产集群和测试集群之间的差异带来意外问题时，还需要持续沟通。应迅速缓解这些问题，但应发出工单以确保正确解决问题，以便问题不再发生。

为生产集群停机做好准备始终很重要。但是，不可能为每种可能的意外情况做好充分准备。测试集群和生产集群配置之间的差异将有助于定义任何特定停机的最高风险。在停机之前，将这些风险以及可能受这些风险影响的任何更改传达给管理层至关重要。

这里描述的流程看起来确实有很多开销，并且可能看起来不适用于您的情况。但是，该流程确实有可以跳过测试阶段的特定情况。此外，此流程足够通用，可以根据您的需求进行扩展。有许多开源或专有软件可以满足此流程的要求。

通过将关键应用程序拉入单独的覆盖存储库中，可以轻松跳过测试阶段流程，以便可以单独管理它们。然后确保将获取更新的流程放入持续集成系统中。这可能只是一个网站下载，将相应的软件拉入其各自的覆盖存储库中。然后只需将覆盖存储库同步到测试环境，然后再同步到生产环境。立即完成此操作，以将安全更新推送到生产系统。

与生产配置更改类似，许多时候，停机期间的意外问题要求直接对生产系统进行配置更改。这些更改应该可以直接在生产配置管理系统中进行，然后在停机结束后合并回测试环境。如果对生产环境的更改需要进行更通用的开发，则应在构建和集成测试阶段进行。然后，最终解决方案应在停机期间推送到生产环境。

总之，此处描述的流程本质上只是建议性的。如果需要修改流程才能使事情再次正常运行，请这样做。但是，在修复问题后，请记住问题相关的流程部分，并将已完成的工作注入到流程中。此流程是通用的且灵活的，可以管理这些类型的更改，并在通过明确定义的系统管理通信的同时保持系统更新。