面向E级高性能计算的软件栈（二）

2. PMIx 社区

PMIx社区由横跨一般HPC领域的行业、政府和学术界成员组成，专门关注应用程序启动和执行的编排。社区的出现源于对两个问题的共同关注，一个是与机器规模的不断扩大相关的问题，另一个是支持HPC编程领域不断增长的创新浪潮的能力。

在如此多样化的集合中组成联盟绝非易事，一个关键因素是早期达成的协议，即任何SMS子系统都保留对任何请求返回“不支持”响应的权利。因此，与会者基本上同意将竞争的重点从API转移到对标准的质量和广度的支持上。然后，将向客户呈现一致的API，对于该API，很容易检查特定实施中是否存在对所需功能的支持，从而告知客户选择系统软件的过程，并反过来促进供应商改善支持。

本节的其余部分将描述社区形成背后的动机，其定义PMIx标准的过程，以及其适用的范围。

2.1 动机

Exascale的启动时间是一个值得关注的问题，因为预计会有大量的节点和进程，通常范围是50-100k个不同的节点，支持多达100万个单独的、也可能是多线程的进程。无论编程模型如何，几乎肯定需要这些进程之间的高速通信，因此要求提供一种可伸缩的连接进程的方法。

正确利用这样大的集群要求应用程序和系统管理堆栈(SMS)一起工作，以协调不断发展的资源需求，并识别和响应故障。这增加了SMS开发人员的负担，他们不仅要充分支持这样的努力，还要提供适当的基础设施，以方便那些被证明是成功的应用程序的广泛采用。这一负担分布在所有的SMS组件上——就本文而言，这些组件将被定义为:

• 工作负载管理器（WLM），负责调度作业的资源分配；
• 资源管理器(RM)，负责生成和监视应用程序进程，并跟踪/管理这些进程的资源使用情况;
• 用作群集永久存储的全局文件系统(FS)。FS经常包含多个元素，包括用于输入和输出数据文件的并行文件系统(PFS)，以及通常包含主目录、可执行文件和支持库的网络文件系统(NFS)。除了大规模后端存储之外，文件系统可以包括缓存元素，其形式或者是位于集群外围的“burst buffers”，或者位于分布在整个集群中的非易失性RAM(NVRAM)的存储体中；
• 结构管理器（FM），负责监督高速网络，为节点间通信定义地址和路由模式。这包括每个计算节点上的一个或多个本地网络接口卡（NIC）；以及
• 可靠性和生存性（RAS）子系统，用于监视硬件和固件故障并提供警报。

 

除了供应商专有的实现之外，这些组件在历史上都是由独立的组开发的，因此得到的包最多只包含少量的集成。每个类别中产品的多样性进一步增加了集成工作的复杂性，因为每个产品都维护自己独特的接口和数据结构定义。

PMIx社区试图通过提供一组抽象的标准化接口来解决集成问题，同时将这些接口的实现留给其他人。社区主要关注四个方面:启动支持、内存效率、跨编程模型的支持和工具。

2.1.1 启动支持

在RoadRunner项目期间进行的研究为深入了解启动期间所花费的时间提供了宝贵的见解。虽然从那时起，详细的时间发生了变化，但是启动期间的总体分布和事件顺序仍然是相对一致的。一个典型的并行应用的启动可以分为六个不同的阶段，如图1所示:

第一阶段：用户向WLM提交作业（以脚本或交互会话请求的形式）。请求通常包括对作业所需资源的类型和数量的描述。历史上，资源请求一经分配就被认为是不可变的，但对动态可修改的资源分配的需求和支持正在增长。

第二阶段：根据资源可用性、相对优先级和调度算法，在将来的某个时候，WLM将资源分配给请求的作业，并通知控制这些资源分配的RM守护进程。WLM还可以考虑诸如网络拓扑之类的因素，通常基于配置文件中提供的信息(手动构建或由结构管理器输出)。RM守护进程用于派生其本地应用程序进程的步骤的精确顺序各不相同，但总体结果是从FS检索应用程序二进制可执行文件，在计算节点上实例化并执行。此时，任何动态库依赖关系都将导致从FS检索相应库的调用。

大规模地处理由来自大量节点的多个进程（几乎同时请求一个库）引起的库检索风暴一直是一个重要的研究课题。一些系统简单的利用静态构建来完全避免风暴，而另一些系统则将第一个请求缓存在中间位置（例如，“突发缓冲区”），然后服务于来自缓存的所有后续请求（例如，SPINDLE[16]）。

第三阶段：一旦实例化，应用程序中的每个进程都必须发现与其对等进程交互所需的本地信息。该信息至少包括进程等级和通信端点(例如，IP地址和TCP套接字编号)，但通常包括已应用的任何进程亲和性、本地网络能力以及可能影响应用程序的优化配置(例如，通信算法的选择)的其他因素。一旦在本地发现了信息，该进程就可以将该信息发布到分配给其节点的本地代理(通常由本地RM守护程序、由诸如mpiexec的专用启动器提供的守护程序或该节点上排名最低的应用程序进程)。

第四阶段：然后，通过通常在管理以太网上执行的集体操作(由所有进程或它们的每个节点代理直接执行)来执行已发布信息的全局交换(通常称为名片交换或BCX)。此阶段通常是最大的应用程序启动时间部分。因此，减少启动时间的努力主要集中在为这一阶段开发更有效的算法上，最近则集中在将集合转移到高速结构上。当节点被分配到单个应用程序时，后者通常是可以接受的，但这可能与将来的实践不兼容。此外，尽管这两种方法都降低了端点交换问题的严重性，但它们并没有消除它，而且其扩展性仍然取决于节点和/或进程的数量。

第五阶段：信息交换后，程序库通常会基于该信息组装必要的基础结构，例如将通信通道映射到对等方（peers）。这再次在很大程度上衡量了库的效率及其对架构的选择。这里的主要关注点是从本地代理服务器(如果存在)检索连接和其他所需信息所花费的时间，以及每个进程配置其本地NIC库以使用这些信息进行操作所需的时间。

第六阶段：最后，执行屏障(同样，通常是通过管理以太网)，以确保所有进程都准备好进行通信。这确认所有进程都已完成其设置，并且本地高速网络已准备好接收消息。解除这一屏障被认为是对应用程序开始包括通信在内的操作的最终批准。虽然屏障不涉及任何数据，因此比以前的BCX操作更快，但它仍然会消耗开始配置文件中的下一个最大的时间块。启动改进工作包括将BCX优化扩展到此阶段。

PMIx社区致力于减少或消除在这些阶段花费的时间，以实现在30秒内启动和连接亿级应用程序的总体目标。为了跟踪这一目标，社区采用了基线测试如下：启动应用程序和完成MPI_Init所需的时间，所有进程在此时都具有通信所需的所有信息，使用50k节点的应用程序大小支持最多1M个独立进程。

2.1.2 内存效率

图1中概述的处理导致在每个节点上的代理（如果使用代理）中或在每个单独的处理中（如果应用程序直接执行交换）的所有相关数据的完整副本的聚合。使用代理方法的系统通常仍然要求每个应用程序进程获取其所需的每个数据元素的副本。因此，数据复制可谓相当广泛。考虑到节点趋向于越来越多的核，在exascale应用程序的每个进程中重复SMS状态可能会在用户可用内存方面造成严重的损失。

PMIx社区正在解决这个新出现的问题，方法是确保相关定义的接口有助于共享和/或分布式内存方法。此处的目的是确保PMIx实现具有充分的自由度，以便与主机SMS环境和各种编程库协调，在访问成本和缓存所需信息的内存消耗之间进行权衡。

2.1.3 编程模型

无论是将OpenMP线程操作与MPI相结合的混合应用程序，还是基于将问题分解为大量小型并行任务的新工作流范例，还是全新的并行计算方法，HPC社区都见证了应用程序体系结构的新方法的大量涌现，因为研究人员正在探索在艾级级别执行的最佳方法。目前还没有明确的答案，但迄今为止所有的方法都有一个共同的互连支持需求，并且越来越需要通过SMS来协调它们的操作。

然而，考虑参与这一领域的研究团队在进入该领域方面面临着重大障碍。由于大多数SMS环境不提供这些努力所需的动态支持，因此团队必须承担开发将主机SMS隐藏在自定义抽象层后面的完整“虚拟”环境的高成本，或者通过利用专有接口与支持必要功能的系统管理堆栈进行交互而缺乏可移植性。

PMIx可以通过为早期研究人员提供抽象和可移植的SMS交互功能来帮助支持和鼓励这种探索。社区正在与几个小组合作，以确保PMIx标准具有足够的灵活性，以满足其不断发展的需求，并确定跨模型交互所需的额外支持，包括在编程模型之间共享和分配处理器核心和网络资源。

2.1.4 工具支持

虽然PMIx的主要目的是提供一种机制，通过这种机制，应用程序可以与它们的主机SMS进行交互，但是有时非应用程序进程(例如命令行工具)也希望与SMS或应用程序进行通信。历史上，由于这些工具的接口是定制的和/或专有的，所以它们是特定于其环境的。

PMIx提供了创建可移植工具的可能性，这些工具可以在多个PMIx支持的SMS环境中操作，而无需修改。由于工具通常在命令行提示符处启动，而不是由SMS启动，因此PMIx标准定义了一个属性，通过该属性，主机SMS可以引导本地PMIx服务器接受工具连接，从而使PMIx服务器在已知位置发布必要的会合连接信息。该标准包括hooks，通过这些hooks，SMS可以验证工具的连接请求，并确保对工具请求进行适当的授权。

PMIx接口还可用于支持shell脚本与应用程序的交互。例如，PMIx_Publish API提供了将信息发布到SMS托管的键值存储的能力，从而控制所提供数据的访问权限和持久性，包括在应用程序停止执行后保留的指令以及在首次访问时删除的指令。相应地，可以指示PMIx_Lookup API在请求的数据变得可用时或在达到提供的超时限制时返回。这两个接口的组合为执行控制的数据异步交换提供了丰富的层，使应用程序能够发布关于其完成状态的详细信息，该信息适合于通过控制作业脚本引导后续执行路径。

调试器和性能分析器等工具在扩展到exascale 时面临与应用程序类似的问题。并且越来越多地被要求支持更广泛的编程库和范例。标准化SMS交互路径使工具供应商能够访问更广泛的信息和功能，同时支持更好的可移植性和扩展到exascale级的简易性。同样，PMIx接口允许工具通过与模型无关的接口与应用程序交互，从而允许研究人员在新的编程模型上使用已知的调试环境，而无需进行广泛的集成工作。

2.2 标准流程

以前实现启动性能目标并为工具和编程模型提供支持的方法主要关注与特定开发团队相关的特定编程模型实现。这导致了可移植性的缺乏，并对SMS供应商的采用造成了障碍。类似地，对SMS的应用程序集成不应该局限于特定的SMS环境或编程库。用户希望能够在HPC社区中支持一组“标准”的、不可知的接口。因此,PMIx社区采用了基于标准的方法(仿照互联网工程任务组)定义PMIx API和相应的属性，该方法依赖于提交和审核详细说明建议的修改或扩展的请求注解(RFC)，以及原型实现。PMIx倡议的活动涉及多个领域，每个领域都由一个小型的非正式贡献者工作组领导。审批的最后决定通常在社区的每周电话会议上做出。

尽管它严重依赖于当前PMIx社区的协作级别，但最终的过程已经证明足够敏捷，可以满足社区的需求。不涉及正式的投票过程，也不存在必须满足的成员资格要求，才能让某人在投票过程中有发言权。随着社区的成长和成熟，这种情况可能会改变。然而，预期标准到那时也会成熟，因此更慢、更正式的过程可能更合适。

PMIx社区进一步采纳了一项政策，即只有在极端情况下才允许修改现有发布的API。在努力避免引入任何此类向后不兼容的过程中，社区避免了大量API的定义，这些API每个都侧重于狭窄的功能范围，而是依赖于较少的通用API的定义，这些API包括用于“调优”函数行为的指令数组。因此，对PMIx标准的修改越来越多地包括新的键值属性的定义以及与其相关的API的描述以及与这些API一起使用时的预期行为。

实现可以同时支持规范的多个版本，但不是强制的。然而，强烈鼓励在PMIx服务器的实现中集成具有旧版PMIx API的向后兼容性模块，以及使用的API协议的自动协商，以实现旧版PMIx客户端组件和PMIx服务器之间的交叉操作。

当然，没有任何标准团体可以要求实现者支持标准文档中的某些内容，PMIx在这方面也没有什么不同。虽然PMIx库本身的实现者必须至少包括标准PMIx头并实例化每个函数，但对于他们选择不实现的任何函数，他们可以自由地返回“not supported”。

这也适用于主机环境。资源管理器和其他SMS组件保留决定是否支持特定功能的权利。PMIx社区继续寻找帮助SMS实现者进行决策的方法，强调对基本应用程序执行至关重要的功能(例如PMIx_Get)，同时保留针对目标市场细分量身定制供应商软件的灵活性。

这可能变得更加复杂的一个方面是关于向客户端进程提供指令和/或控制PMIx标准API的行为的属性。例如，PMIX_TIMEOUT属性可用于指定请求的操作超时之前的时间(以秒为单位)。此属性的目的是允许客户端避免请求中的“挂起”，该请求花费的时间比客户端希望等待的时间长，或者可能永远不会返回(例如，被阻止的参与者永远不会进入的PMIx_Fence)。

如果应用程序在调用PMIx_Fence时真正依赖于PMIX_TIMEOUT属性，则应该在pmix_info_t中为该属性设置“REQUIRED”标志。这会通知库及其SMS主机，如果不支持此属性，则必须返回即时错误。通过不设置标志，允许库和SMS主机将该属性视为可选，如果支持不可用，则静默忽略它。

因此，用户和应用程序实现者考虑是否需要给定的属性(相应地对其进行标记)并始终检查所有PMIx函数调用的返回状态，以确保存在支持并接受请求，这一点至关重要。注意，对于非阻塞API，返回PMIX_SUCCESS只表明请求没有明显的错误，并且正在处理中。最终的回调将返回所请求操作本身的状态。

虽然PMIx库实现者或SMS组件服务器可以选择支持特定的PMIx API，但并不要求它们支持可能适用于它的每个属性。这将对实现者造成很大的进入障碍，因为给定的API可能有广泛的适用属性，其中至少有一些可能很少在特定的市场领域中使用。PMIx社区试图通过在标准中指出通常使用的属性(因此，对支持的重要性更高)与“完整的实现”将支持的属性，来帮助区分这些属性。

2.3 范围和架构

PMIx标准的范围在用户和成员的请求驱动下随着时间的推移而发展。最初专注于减少启动时间，需要在多个SMS子系统之间进行集成以获得必要的支持-例如，将资源管理器(RM)与结构管理器(FM)集成以获取连接端点信息，或与文件系统(FS)集成以在作业开始之前预取和缓存二进制文件和库。这为扩展利用率提供了机会。为了换取供应商对缩短发布时间的支持，社区基于图2所示的体系结构定义了支持跨SMS子系统的广泛交互的抽象。

请注意，这是一个概念模型，仅用于帮助指导标准过程-它并不代表任何PMIx实现的设计要求。相反，PMIx社区将该模型用作评估建议接口的试探板，以避免无意中对实现者施加约束。模型中内置的两个指导原则也反映在标准中。首先，PMIx以信使而不是实施者的模式运行，即PMIx的角色是提供不同参与者之间的通信，中继请求和返回响应。该标准的目的不是建议PMIx本身实际执行任何定义的操作-这留给各种SMS元素和/或应用程序。此规则的唯一例外是为了优化目的而合并请求时，或者在PMIx社区(与SMS子系统提供商合作)的少数情况下。已确定通过将其包含在PMIx参考库中可以最好地提供基础级别的支持。例如，PMIx服务器可以(取决于实现)选择在将所有本地PMIx_Figence调用传递到SMS进行全局执行之前将其聚合，或者包括对本地syslog的日志记录的支持。

因此，如图2所示，应用程序是针对PMIx客户端库构建的，该库包含用于与本地PMIx服务器交互的客户端API、属性定义和通信支持。在客户端级支持跨库交互，以避免服务器上不必要的负担。编排请求被发送到本地PMIx服务器，后者随后使用主机SMS在PMIx_SERVER_INIT期间注册的PMIx服务器回调函数将它们传递给主机SMS(这里由RM守护进程表示)。主机SMS可以通过简单地为相关联的回调函数提供NULL来指示其缺乏对任何操作的支持。

概念模型将满足请求的负担放在主机SMS上。这包括执行任何节点间通信，或与其他SMS元素交互。因此，客户端对网络流量报告的请求不是直接从客户端到FM，而是中继到PMIx服务器，然后传递到主机SMS以供执行。该体系结构反映了该标准的第二个原则，即通过本地PMIx服务器引导所有应用程序与SMS的交互来最小化连接性。

认识到这给SMS供应商带来的负担，PMIx社区包含了一些接口，通过这些接口，主机可以从本地SMS元素请求支持。一旦SMS将请求传送到适当的位置，就可以使用PMIx接口将请求传递到目标SMS子系统。例如，对网络流量统计的请求可以利用PMIx网络抽象来从FM检索信息。这将处理单个子系统接口的负担从SMS转移到PMIx社区，PMIx社区将继续与这些提供商合作开发必要的支持。

工具，无论是独立的还是嵌入在作业脚本中的，都是通信规则的一个例外，并且可以连接到任何PMIx服务器，前提是提供足够的集合信息。PMIx概念模型将PMIx服务器的集合视为类似于云的联合企业-即，可以向任何服务器发出编排和信息请求，而不管其位置如何。然而，工具经常在可能不容纳操作PMIx服务器的位置上执行-例如，用户笔记本计算机。因此，工具需要能够远程连接到PMIx服务器“云”。

因此，PMIx标准的范围跨越了这些交互的范围，从客户端到SMS，以及SMS子系统之间。再次注意，这并不要求任何给定的PMIx实现覆盖整个范围-实现者可以自由返回任何PMIx函数不支持的内容。

2.4 参考实现

PMIx的范围非常广泛，这对SMS供应商和编程库开发人员的采用构成了挑战。因此，PMIx社区已经开发并发布了PMIx“参考实现”，其中包含PMIx标准的完整实现，每个版本都直接绑定到标准的相应修订级别。参考实现本身不是PMIx标准的一部分，也不需要以任何方式使用它。它的存在完全是为了提供一条快速、方便的采用途径。

同样，PMIx社区发布了“基于PMIx的参考运行时环境”(PRRTE)-即包含参考实现并能够在主机SMS中操作的运行时环境。PRRTE提供了一种在启用PMIx的环境之外探索PMIx功能和测试基于PMIx的应用程序的简单方法。社区网站上提供了下载、安装和使用参考实现和PRRTE的说明。