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

3.3. 动态进程管理

历史动态进程管理API反映了大容量同步编程模型(如MPI-3标准)的需求，这些模型要求操作作为一个集合执行，所有指定的进程在声明操作完成之前参与操作。最近，编程库已经开始向异步模型的方向发展，在异步模型中，进程定期聚合成组，然后在完成一些操作之后解散。这些新方法将受益于通知其他进程希望聚合的功能，并允许聚合进程本身异步进行。

PMIx通过引入在以前PMI实现中找到的“Connect”和“Disconnect”调用的修改形式，解决了这些不断变化的需求。通过利用pmix_info_t结构的数组来控制行为，这些修改允许将来的扩展而无需更改API。默认情况下，将为参与进程的组分配一个新的命名空间以标识该组，并且为每个进程分配该组中的新rank-这两个值都将返回给参与进程。

通过定义几个属性键，可以提供对所需异步操作的支持。

• PMIX_CONNECT_NOTIFY_EACH：请求在每次进程连接时，所有参与进程都会收到一个事件通知，每次进程断开连接时，都会收到另一个事件。
• PMIX_CONNECT_NOTIFY_REQ：通知每个指定的进程请求连接。
• PMIX_CONNECT_OPTIONAL：参与是可选的-如果PMIx_Connect调用中包含的进程在未连接的情况下终止，则不返回错误。
• PMIX_CONNECT_EARLY_TERM_ALLOWED：如果已连接的进程在不断开连接的情况下终止，则不会生成错误。 主机RM和PMIx服务器负责调整此名称空间在任何正在进行的集合或将来的集合上的完成要求。
• PMIX_CONNECT_XCHG_ONLY:确保所有参与的进程都有来自每个命名空间的作业级信息的副本，但是不要将新的名称空间和rank分配给连接的组。

注意，任何单个进程都可以同时参与多个连接操作。对于可伸缩性，PMIx不使用集合来为connect操作分配标识符。相反，预期所提供的进程id数组将用于标识特定的PMIx_Connect操作。不考虑数组内进程的顺序。可以使用PMIX_RANK_WILDCARD来指示给定名称空间中的所有进程的参与，而不是枚举名称空间中的完整进程列表。

多个PMIx_Connect操作可能会并行地涉及同一组进程。示例可能包括来自不同线程或应用程序包含的不同库的调用。相应地，PMIX_CONNECT_ID属性被定义为允许应用程序提供自己的操作字符串标识符。此标识符将与参与流程标识符数组一起使用，作为唯一标识多个并行操作的方法。注意，所有参与者都需要使用相同的PMIX_CONNECT_ID属性值调用PMIx_Connect。

连接操作也可能跨越多个集群上的进程，每个集群由独立的资源管理器实例控制。在这种情况下，不能再保证命名空间在集群中是惟一的，从而导致进程标识符中的潜在混淆。因此，PMIx定义了一种方法来解决潜在的名称空间重叠问题，方法是修改给定进程标识符的名称空间值，使之包含“集群标识符”——主机RM通过PMIX_CLUSTER_ID属性提供的集群字符串名称。如果一个进程已知存在于一个远程集群上，则集群标识符应该被前缀到名称空间中，以冒号分隔。提供宏来帮助组装和解析组合标识符。

当然，要指定可能在远程集群上执行的应用程序的集群标识符和命名空间，首先需要确定情况是否如此，然后获得所需的标识符值。PMIx和主机RM没有提供解决这个问题的直接机制。相反，应用程序被定向到PMIx_Publish和PMIx_Lookup函数，以便在应用程序之间执行适当的会合协议(有关此特性，请参阅RFC中的示例)。

3.4. 柔性资源分配

近年来，由于新的编程模型和对Extreme Scale系统中更高的故障率的关注，人们对资源动态管理的兴趣有所增加。作为回应，另一个PMIx工作组专注于实现应用程序导向的动态资源更改，例如：

• 请求分配额外资源。这是以一种非阻塞的方式完成的，这样应用程序就可以在等待资源可用的同时继续进行。请注意，新分配将与请求者的分配脱节（即不隶属于），因此一个分配的终止并不一定会影响另一分配；
• 根据调度的可用性和优先级，延长对当前分配资源的保留。这包括延长当前资源的时间限制，以及/或请求将额外资源分配给请求作业。任何额外分配的资源将被视为当前分配的一部分，因此将同时予以释放；
• 释放当前分配的不再需要的资源。这是为了支持资源的部分释放，因为所有资源通常在作业终止时释放。确定的用例包括跨工作流离散步骤的资源变化，以及产生子作业和/或随时间动态增长/缩减的应用程序；以及
• 将资源“借给”调度器，期望在作业的某个稍后时间将资源收回。这可以是一种主动操作(例如，在暂时不需要资源时节省计算成本)，或者响应调度器请求而不是抢占。也有相应的能力“重新获得”以前发布的资源。

每个分配请求可以包含一个用户创建的“allocation ID”字符串。这允许发起者发出后续请求(例如，通过PMIx_Query函数更新状态)，或者发出后续调用来取消请求。调用取消分配请求而不指定分配ID将导致取消与请求者关联的所有未完成请求。请求可以标记为required，以指示如果指定的资源不可用，请求将被拒绝;或者可选标记为optional，以指示该规范是临时的。

当执行回调函数时，分配请求完成。但是，这只会发生在发起请求的进程中。其他进程可以使用PMIx_QUERY函数轮询请求的状态，或者可以在完成分配操作时注册事件通知。在任何一种情况下，请求进程都可以指定应用程序请求ID。在后一种情况下，未能注册特定的分配请求ID将导致通知与进程所属的应用程序相关联的所有分配请求。

3.5. 监控

除了外部故障外，在HPC应用程序中遇到的一个常见问题是由于计算中的某些内部冲突而导致进度失败。这些情况可能会导致大量资源浪费，因为SMS无法识别问题，因此无法终止作业。已经开发了各种各样的watchdog方法来检测这种情况，包括要求应用程序定期执行“心跳”，并监视指定文件的大小和/或修改时间的变化。

应SMS供应商和成员的要求，PMIx 2.0标准中包含了一个监视支持接口。定义的API允许应用程序请求监视、指示监视的内容、相关检查的频率、是否通知应用程序(通过事件通知子系统)失速检测以及操作的其他特性。此外，PMIx参考实现中包含了心跳和文件监控方法，但仅在请求时才激活。

3.6. 作业控制

当然，检测停滞的进程和接收外部故障的通知只是问题的一部分。应用程序必须与SMS一起工作，才能实际针对这种情况做一些事情。典型的当前实践是简单地终止受影响的应用程序，但未来的系统需要不那么苛刻的解决方案。

PMIx_Job_control API使应用程序和SMS能够协调对故障和其他事件的响应。这可以包括请求终止整个作业或作业内的进程子集，但也可以与其他PMIx功能(例如，分配支持和事件通知)结合使用，以获得更细微的响应。例如，被通知节点上出现初始过热情况的应用程序可以使用PMIx_Allocate接口请求更换节点，同时使用PMIx_Job_control接口指示将checkpoint事件传递到应用程序中的所有进程。如果替换资源不可用，应用程序可能会使用PMIx_Job_control接口来请求作业在较低的功率设置下继续，这可能足以避免过热故障。

当在诸如云的环境中或在为愿意被抢占的工作提供经济或其他激励措施的环境中运行时，应用程序还可以使用作业控制API将其自身注册为可抢占。注册可以包括指示为抢占提供了多少资源（例如，全部或仅一部分），应用程序是否需要时间准备抢占的属性，等等。请求警告的作业将收到一个事件，通知它们即将发生抢占(可能包括有关将被拿走的资源、在被抢占之前给予应用程序多长时间、抢占是暂停还是完全终止等信息)，这样他们就有机会保存他们的工作。一旦应用程序准备好，它就调用所提供的事件完成回调函数来指示SMS可以自由地挂起或终止它，并且可以包括关于任何所需重启的指令。

作业控制API的其他用途不断涌现。最近的新增功能包括：(a)注册临时文件和目录，以便在单个进程或整个应用程序终止时进行清理，以确保即使在异常终止条件下也能完成清理；(b)注册要执行的更通用的结束语；(c)协调checkpoint的执行；(d)将特定信号（kill, pause, resume等）传递给特定过程或整个应用程序；(e)请求在一个或多个节点上提供特定映像。

3.7. 查询和日志信息

随着应用程序与主机SMS之间的交互级别的增长，对于应用程序查询SMS的功能和状态信息的需求也随之增加。PMIx为此提供了一个通用的查询接口，以及一组支持一系列请求的标准化属性键。这包括确定调度队列和活跃分配状态的请求，SMS提供的API范围和属性支持，活跃作业的命名空间，作业进程的位置和信息以及有关可用资源的信息。

PMIx_Query API的示例用例是确保干净地完成作业。将作业分配给资源分配时，分时系统通常会施加最大运行时间。为了优雅地关闭，例如在终止之前编写checkpoint，应用程序必须定期查询资源管理器分配中剩余的时间。对于分配时间可能比原来的时间限制缩短或延长的系统，尤其如此。许多资源管理器都提供了用于动态获取此信息的API，但是每个API都是特定于资源管理器的。

PMIx定义了一个属性键(PMIX_TIME_REMAINING)，可以与PMIx_Query接口一起使用，以获得当前作业分配中剩余的秒数。请注意，可以选择使用PMIx_Register_event_handler API注册指示初始作业终止的事件，然后使用PMIx_Job_control API请求主机SMS在达到最大运行时间之前生成指定时间的事件。PMIx提供了这样的替代方法，作为最大化主机系统支持至少一种方法的可能性的方法，应用程序可以通过该方法获得所需的服务。

提供PMIx_Log接口以支持通过应用程序和SMS元素将信息发布到持久性存储。此函数不是用于输出计算结果，而是用于报告状态和保存状态信息，例如将计算进度报告插入到应用程序的SMS作业日志中（使用PMIX_LOG_JOB_RECORD指令）。有各种各样的通道可用来支持用例，例如远程监控应用程序进度（例如通过电子邮件），将错误报告输出到syslog以进行事后分析，以及缓存应用程序完成信息以供工作流中的后续应用程序使用。根据输出通道的选择，可以通过PMIx_Query接口检索记录的信息。

 

图4展示了PMIx参考实现的最新版本中包含的日志支持，以展示如何使用PMIx_Log接口。在本例中，应用程序进程可以将错误记录到本地节点的syslog中，或者记录到为此指定的某个中心服务器的syslog中。PMIx客户机将日志请求发送到它的本地服务器。如果请求中包含PMIX_LOG_LOCAL_SYSLOG属性，或者没有指定目的地，那么PMIx服务器将立即将消息输出到本地syslog。但是，如果指定了PMIX_LOG_GLOBAL_SYSLOG属性，那么PMIx服务器将把请求传输到其主机RM守护进程。主机RM守护程序负责将提供的数据传输到适当的位置-到达时，RM可以使用PMIx_Log函数将数据传送到其内嵌的PMIx服务器，以便在该节点上的本地syslog上输出，或者可以将数据写入syslog本身。提供了用于设置所需系统日志优先级的属性-默认值设置为LOG_INFO，表示报告信息性消息。

记录到stdout和stderr的消息可以选择使用时间戳(通过使用PMIX_LOG_TIMESTAMP_OUTPUT指令)和XML格式的输出(PMIX_LOG_XML_OUTPUT)。时间戳可以由调用者提供，也可以由PMIx库本身(使用PMIX_LOG_GENERATE_TIMESTAMP指令)在调用时生成。

3.8. 安全认证

应用程序和工具经常以需要验证发出请求的用户的身份以及访问该用户的相关授权的方式进行交互。当工具直接连接到可能在特权级别运行的系统级PMIx服务器时，这一点尤其重要。各种系统管理软件包提供这种服务，但是缺乏标准化的接口使得可移植性成为问题。

PMIx为此为主机SMS定义了两个客户端API和两个相应的服务器接口。这些最有可能由用户空间应用程序/工具使用，但不限于该领域-例如，系统级包的开发者可以选择使用PMIx作为抽象层，用于从所提供的凭证中提取用户授权。

因为主机SMS可能必须联系远程凭证服务，所以用于获得凭证的API被定义为非阻塞操作。该定义考虑了返回的凭证可以通过某种机制发送到驻留在使用不同安全机制的环境中的另一个应用程序的可能性。因此，为系统提供返回证书本身之外的并且对应用程序可见的附加信息(例如，发行代理的身份)。同样，API允许用户指定所请求的凭证的类型。

用于验证凭证的API再次被定义为非阻塞操作，因为主机SMS可能必须联系远程凭证服务。为系统提供了返回关于简单身份验证之外可能的授权限制的附加信息。至少，要求系统从凭据中返回有效的userid和groupid。

在SMS不支持凭证API的环境中，PMIx实现可以使用自己的内部安全插件来满足用户的请求。PMIx参考实现目前支持几种用于验证自己的客户端/服务器连接的安全协议-如果用户请求其中之一，或者主机SMS不提供自己的支持，则可以使用这些协议来生成和验证凭据。如果用户请求内部或主机SMS不支持的凭证类型，则PMIx库将立即通过其提供的回调函数向原始调用者返回PMIX_ERR_NOT_SUPPORTED响应。

3.9. 异构环境

PMIx标准有意避免了对实现的任何讨论，尤其是在支持诸如PMIx_Fence之类的操作所需的节点间通信方面。PMIx社区同样选择不将这种支持包含在其参考实现中，而是依靠其宿主SMS环境（通常是RM）在节点之间传输任何所需的数据和/或请求。这些操作经常涉及PMIx定义的包含二进制数据的公共数据结构。许多HPC群集是同质的，因此可以很简单地完成结构的传输。但是，在异构环境中需要付出更大的努力才能确保正确传输二进制数据。虽然PMIx不需要实现提供它们，但为此目的已经开发并验证了参考实现中的PMIx缓冲区操作功能，并且社区选择通过标准化接口将它们公开给主机环境，以简化PMIx的采用。除了标准的打包/解包例程外，PMIx还包括诸如PMIx_Data_print之类的功能，这些功能可打印出结构化数据项的内容，以利于调试。