4. 使用示例

在本节中，我们提出了一个PMIx接口的实际用例，该用例基于用户级故障缓解(ULFM)规范来支持开放MPI中的容错，该规范加强了检测并协调对故障事件的响应。

响应故障是一个复杂的问题，因为系统中的各种组件都可能报告事件，例如网络驱动程序、来自故障MPI通信的带内检测、MPI进程资源环境、系统范围的资源管理器RAS服务、交换机和SNMP陷阱。类似地，多个组件可能对错误事件感兴趣并作出响应，从而需要协调它们的响应。

许多Open MPI组件已经具有错误管理子系统，但是每个组件的行为都经过硬编码，以中止应用程序过程。现在已对这些组件进行了修改，以使用PMIx事件通知框架发布检测到的事件。一旦由客户端组件发布，PMIx服务器将通知其本地子进程，并将事件传递到其主机RM，以将事件传播到事件范围内的其他PMIx服务器（默认情况下是作业范围，即MPI Universe）。然后，每个PMIx服务器将事件传递给已订阅了匹配事件的它自己的本地客户端。因此，不仅应用程序进程被告知MPI库检测到的故障事件，而且其他实体(如RM)也被告知。相反，可以发布RM或RAS系统检测到的带外故障，从而由应用程序进程以一致的方式捕获这些故障。

在Open MPI体系结构中，主要客户端是Open RTE守护进程，负责管理在节点上的MPI进程生命周期。守护进程订阅各种故障相关事件(例如，意外的进程断开、进程被信号终止、无法将消息传递到进程等)，并合并这些事件以产生进程故障事件，该事件表示故障性质以及哪些MPI进程受到了影响。然后将此事件发布到本地客户端作用域(即节点本地进程)，从而触发客户端MPI库中适当的故障处理程序。

在MPI应用程序进程中，通过PMIx在组件之间进行优先级和状态传播的机制允许协调故障响应。弹性组件将故障事件登记为高优先级，从而仅在无法以令人满意的方式纠正故障的情况下，才允许事件默认为中止过程的组件。 在Open MPI的非弹性版本中，仅默认处理程序（中止应用程序）被注册。在ULFM版本中，该处理程序保持注册状态，但是在顶部安装了弹性的MPI错误处理程序，然后该处理程序触发MPI异常以进行持续通信以报告故障。

5. 未来方向

PMIx工作组继续根据确定的应用程序-SMS协调需求定义新功能。 工作组是非正式的，独立运作，成员跨越多个组织。 因此，活跃工作组的列表是不固定的，有关活动的信息可以在PMIx社区网站上找到。

5.1. 调试器和工具支持

越来越多的工具表示有兴趣连接到PMIx服务器，以获取关于应用程序进程信息(例如，位置、状态和标识)，以及队列和一般系统状态的信息。这包括为并行调试器提供支持。将PMIx用于这些目的的主要优势在于工具的可移植性。基于PMIx的工具可以与任何支持PMIx的系统一起使用，而不必考虑供应商。

调试器/工具工作组正在定义属性，开发示例，并协助定义PMIx接口以支持：

• 可伸缩的工具启动和连接，包括与应用程序共同启动守护进程。这包括向调试器守护程序提供应用程序的作业级信息和关于本地应用程序进程的详细信息(例如，PID和绑定位置)，以及跨守护程序本身的端点连接信息。
• 进程发现和附着与编程模型无关，因此调试器可用于MPI，OpenMP，混合应用程序和其他编程库。
• 利用PMIx_Query API获取关于系统配置、网络带宽利用率等方面的信息，以便调试器能够显示与其网络位置相关的进程，识别拥塞点，以及其他高级特性。
• 使用PMIx_Job_control API来终止和重新启动特定的进程，并允许应用程序在遇到问题时请求调试器附加到它。
• 通过PMIx_Log API可伸缩地将“跟踪”信息作为记录存储在系统的作业历史记录中。
• 支持从调试器守护进程向用户转发标准输出和错误通道，以及从用户向指定接收者转发stdin。工具可以请求从应用程序本身接收输出的副本，也可以在附加到作业时直接捕获该输出。

调试器和工具可以使用PMIx_Spawn函数直接通过本地资源管理器启动目标应用程序，也可以使用同一接口通过诸如mpiexec的启动器间接启动应用程序。在标准中定义了属性以指示后一种情况，并定义了事件以支持工具与启动器之间的协调。这允许工具在启动目标应用程序之前提供细化应用程序执行的指令。示例包括在生成应用程序进程之前指定替换fork / exec代理或请求内存拦截器库的LD_PRELOAD。

另外还提供了对请求修改、添加和删除应用程序进程环境变量的额外支持。可以使用指令使用指定的分隔符向变量添加前置或附加内容、删除变量、用新值覆盖任何现有变量，或者在没有找到现有变量的情况下添加变量。

 

如图5所示，可以从调试器守护进程本身和目标应用程序中的一个或两个请求stdout和/或stderr的转发。在任何一种情况下，启动程序的守护进程(宿主RM或来自mpiexec)负责从每个进程上指定的通道收集数据，并将其传输到承载PMIx服务器的节点，该工具被附加到该节点。此时，数据通过PMIx_server_IOF_deliver API传递到PMIx服务器，然后通过PMIx连接发送到显示工具。PMIx客户机将在输出之前对输出进行格式化(按通道标记输出、按时间戳标记输出或格式化为XML)。指令允许工具从指定的通道接收数据的副本，或者将数据从指定的通道重定向到它们。在后一种情况下，数据将不再返回到其原始目标—例如，stdout将不再打印到输出设备，而是在请求工具中终止。一旦该工具调用PMIx_IOF_deregister来断开与IOF通道的连接，就会恢复正常的数据流。

通过两种方式提供对stdin转发的支持。首先，该工具可以收集stdin本身，并使用PMIx_IOF_PUSH API将其推送到PMIx中进行路由和交付。该函数允许调用者为数据指定目标接收者的数组，从而允许该工具在每次调用该函数时对接收者进行细粒度控制。希望预处理输入(可能根据用户输入将数据定向到特定目标)的工具应使用此方法。

或者，该工具可以请求PMIx库收集stdin，并通过使用PMIX_IOF_PUSH_STDIN指令调用PMIx_IOF_PUSH，将其自动转发到一组指定的目标。在这种情况下，将继续收集stdin并将其转发给接收者，直到使用PMIX_IOF_COMPLETE指令第二次调用PMIx_IOF_PUSH。希望将键盘输入透明地转发给目标接收者的工具可能会发现这种方法更方便。

 

为在PMIx下使用而启动的工具守护进程应在启动期间调用PMIx_tool_init。这不仅向他们提供相关信息(例如，他们要附加和调试的作业)，而且还可以完全访问PMIx功能集。如图6所示，PMIx API可用于向本地PMIx服务器查询本地或全局可处理表（进程位置，pid和其他数据的数组），并指示服务器向进程传递信号和PMIx事件。此外，如果应用程序进程注册了适当的回调函数，则工具守护程序可以查询应用程序进程以获取诸如内部性能计数器状态之类的信息。后者的查询流从工具守护程序流向本地PMIx服务器，然后在本地将其转发到目标应用程序进程进行服务。无法注册相应的回调函数会导致向调用者返回“不可用”错误。

利用这些功能，工作组开发了一些工具，这些工具现在随PMIx参考实现一起分发。这些工具包括用于从命令行将事件发送到应用程序的pevent工具，以及用于检索应用程序发布的数据以进行工作流控制的plookup工具。

5.2. 混合应用程序支持

混合应用程序工作组正在研究使用PMIx来协调混合应用程序(即例如，一个MPI应用程序也使用OpenMP)。这项工作的重点是让用户能够试验混合应用程序的“最佳实践”，目前这仍然是一个研究重点。工作组的第一步是定义一种机制，通过这种机制，每个库可以可靠地确定另一个库正在运行。目前寻找环境变量的常见实践被认为是不可靠的，因为资源管理器通常会设置这些变量，“以防”应用程序需要它们。同样，要求用户在执行之前声明他们想要的编程模型似乎过于繁琐，不太可能得到用户的普遍接受。实际上，在用户执行打包软件(即不是他们自己编写的应用程序或库)的情况下，软件包所采用的编程模型的明确信息对于用户可能不可用或不可见。因此，需要一种确定活动编程模型的动态方式。

鉴于初始化模型的调用顺序是未知的，并且它们之间的初始化方法有所不同，因此，只要编程模型声明自己处于活动状态，标识方法就必须允许某种形式的异步通知。PMIx事件通知系统是异步的，并且支持缓存的事件，因此非常适合此角色。相同的机制还允许库共享彼此的资源信息和预期的资源利用率。因此，工作组正在尝试让OpenMP和MPI库都声明它们的存在并注册事件以进行库间协调。

这两个库都调用PMIx_Init的附带好处是它们每个都可以访问主机环境提供的所有作业级别信息，并且可以利用PMIx API来协调它们之间的资源选择/分配。目前的研究集中在后一种上，使用PMIx事件通知系统在其他库的资源需求变化时向其发出警报。

5.3. 存储系统的交互

下一代系统旨在访问存储在一系列存储媒介中的信息，从离线存档到流式数据流。这种“分层存储”体系结构对努力实现高系统效率和性能的应用程序开发人员和系统管理人员提出了挑战。存储工作组（SWG）试图通过定义基于PMIx API和数据结构的抽象层来定义允许实现厂商独立性的灵活解决方案。

当前的工作集中在两个不同的阶段：应用程序启动时间和用于工作流控制的运行时控制。在所有活动计算节点上实例化可执行文件及其依赖库的时间会显著影响应用程序的启动。因此，了解访问存储介质上的必要位并将其重新定位到计算节点所需的时间对于有效利用系统资源至关重要。工作组正在定义调度程序所使用的PMIx API：

• 可以获取提交作业所需的库和文件的列表，用户可以通过脚本级指令的定义将已知依赖项通知存储管理器，以及通过二进制文件自动检测到动态库的链接（例如，通过标准ldd工具和/或与库（如XALT）的集成）。
• 可以查询存储管理器以获得获取调度器指定的可执行文件、库和数据文件所需的估计时间，并将它们定位到调度器指定的位置。这对于具有可能具有长的相应检索时间的“冷”存储/归档系统的安装特别重要，因为它允许调度器将检索时间合并到调度算法中。
• 可以向存储管理器发出即将分配的警报，向存储管理器传递要检索的文件列表和要缓存这些文件的位置。预期这项能力将与档案的自动检索系统相结合。此外，该组还定义了一个PMIx事件，通过该事件，存储管理器可以在将位缓存到位置时通知调度程序。

如前所述，在这些领域已经做了大量工作，主要集中在创建分层的分发系统，以减少文件系统访问点的瓶颈。SWG认识到对所需文件和/或库的完美标识仍然不太可能，因此将上述措施视为对现有系统的补充。因此，目标是使研究人员能够在集群内缓存位置激增的情况下容易地探索适当的策略，并在确定有益的方法时对其进行标准化。

对存储选项的运行时控制，包括应用程序影响检查点和其他数据的位置、重定位和存储策略的能力(例如，跨越多个位置、热/暖/冷存储)也同样重要。因此，工作组正处于确定下列各点的初期阶段:

• 用于从应用程序向SMS传递存储策略指示的API和属性;
• 允许应用程序查询(通过现有的PMIx_Query API)支持的存储指令的属性，以及默认(或当前设置)的位置和存储策略;
• 应用程序可以用来指导文件异步移动的API和属性； 以及
• PMIx事件，指示基于应用程序的存储操作何时完成。

SWG才刚刚开始工作，它的目标是及时为PMIx v3标准提出一组初始的api和/或属性。

5.4. 扩展网络支持

PMIx标准的版本2提供了支持，资源管理器可以通过该支持请求给定分配的fabric配置信息，并将这些信息转发给已分配的节点，以便对其nic进行本地配置。这可以包括在生成用于指导网络库的应用程序进程之前要设置的环境变量，以及预先分配的端点信息和fabric通信所需的任何其他信息。

Fabric工作组正在努力将此集成扩展到标准的版本3，以便为工作负载管理器（用于调度目的）、资源管理器（用于故障检测）、工具（例如调试器）和应用程序提供对Fabric信息的更多访问和对fabric资源的更多控制。这包括定义：

• 用于查询用于调度和进程放置的网络拓扑和连接图（即点到点传输时间）的属性，以及用于应用程序调试、瓶颈识别和拓扑感知集合的流量报告；
• SMS可以通过其向结构管理器通知配置要求的API，例如给定分配的服务质量(QoS)变化和网络拓扑；
• PMIx事件，通过该PMIx事件，结构管理器可以向SMS和应用的其余部分发出网络事件的异步通知(例如，由于丢失或瓶颈链路而导致的路由改变)；
• 用于收集网络清单的API，包括交换机和网络接口信息。这包括寻址以及网络接口和处理器之间的相对距离；以及
• 用于流控的PMIx事件。

工作组的成员正在开发一个抽象层和插件，以便在PMIx参考实现中支持这些服务。

5.5. 广义数据存储

最后，另一个PMIx工作组正在研究一个通用的数据存储框架，该框架能够通过一个通用的抽象接口支持多个存储实现。这不会用于存储计算输出，而是提供一个抽象接口，用于研究跨SMS和应用程序存储和传播操作信息的各种方法。HIS可能包括任何与启动相关的数据，但也可以扩展为提供持久状态存储、PMIx_Log函数和PMIx发布/查找接口的后端支持。其目的主要是为研究人员提供一个平台，以调查不同的存储拓扑结构，例如分布式哈希表(DHT)和分层缓存(cold/warm/hot)，因为它们涉及SMS和应用程序社区感兴趣的用途。例如，研究人员正在研究如何使用dht来存储键值，而不是使用每个PMIx服务器本地缓存与作业相关的信息，以此来减少PMIx服务器的节点占用空间。