PMI可扩展并行进程管理AScalableParallelProcess-Management

PMI：AScalableParallelProcess-Management可扩展并行进程管理摘要。大规模系统的并行编程模型要求一种可扩展的系统来管理组成了执行并行程序的进程。processmanagement必须能够很快地启动拥有数以百万计进程的并行程序，并且必须提供进程交换信息的机制以使它们彼此连通。MPICH2及其衍生版本通过一个精心定义的接口来实现这个功能，叫PMI，它允许不同的processmanager用标准化的方式和MPI库交互。在本文中，我们描述了PMI的功能。我们描述了PMI-1（目前的为MPICH2及其所有衍生版本通用的），也描述了PMI-2.，第二代的PMI（消除了PMI-1的各种缺陷）。除了接口本身，我们还分别描述了在新的MPICH2processmanagement架构（叫Hydra）中PMI-1和PMI-2的参考实现，并比较它们在运行千个MPI作业时的性能。1引言虽然processmanagement是高性能计算（HPC）的一个组成部分系统，但是它没得到同水平其他方面并行系统软件的关注，却是由来已久了。在百个节点的系统中，processmanagement的可扩展性并不令人关注。随着HPC系统变得越来越大，系统上千个节点和数万的处理内核越来越普遍;事实上，世界上最大的系统已经使用几十万处理内核。对于这样的系统，processmanagement基础架构的可扩展设计成为了各个方面的关键，这些方面包括启动和管理并行应用程序，可调试和管理工具。processmanagement系统必须，也理所当然的，以可扩展的方式的启动和停止进程。此外，它必须提供机制让并行的进程交换信息，以建立它们之间的通信。虽然HPC系统规模的日益扩大需要并行编程库（如MPI）和过程管理器（processmanager）之间的密切交互，但这两个部件之间的适当的分离是必要的。这种分离不仅使得他们可以独立开发和改进，也保持并行编程库足以通用于任何processmanagement框架。同时，这两个组件必须共享足够的信息，以便允许并行编程库利用其所运行系统的具体特点的优势。考虑到这些要求，我们最初设计了PMI，一个为并行应用程序的通用processmanagement接口。在本文中，我们首先描述第一代的PMI（PMI-1）。PMI-1被广泛用于MPICH2[1]和从它派生的其他MPI实现，如MVAPICH2[4]，英特尔MPI[6]，SiCortexMPI[12]，以及微软的MPI[7]（编程库部分），以及许多process-management框架，包括MPICH2的内部process-management（Hydra，MPD，SMPD，Gforker，Remshell），外部process-management，如SLURM[15]，OSCmpiexec[9]，OSUmpirun[13]（process-management部分）。虽然非常成功，PMI-1有一些局限性，特别是当应用于现代HPC系统。这些限制包括涉及到的问题有大量核心在单个节点上的可扩展性，MPI和线程混合编程模型的高效交互，其他。基于我们PMI-1的经验，我们最近设计了一个二代接口（PMI-2），克服PMI-1的缺点。该本文的第二部分介绍了描述了在新的MPICH2processmanagement架构（叫Hydra）中PMI-1和PMI-2的参考实现。我们也通过阐述大约6000进程规模上的性能测试结果，比较PMI-2同PMI-1以及其他processmanagement接口的能力。2process-management接口需求在这个部分，我们提供了一个简要概述来描述在大规模系统中可扩展的并行程序管理的processmanagement接口。2.1解耦ProcessManager和Process-Managementinterface在我们的模型中，过程管理包括三个主要部分：（1）并行编程库（例如MPI），（2）PMI库，和（3）processmanager。这些组件就是在图1中举例示，不同的MPI库，PMI库和processmanagers。进程管理器（processmanager）是一个逻辑上中心进程（但往往实际上是分布式的一组进程），用于管理（1）进程启动（包括启动/停止进程中，为每个进程提供的环境信息，标准输入/输出/ERR转发，传播信号）和（2）信息在并行应用程序之间传递（例如，建立交流信道）。几个可用的processmanagers（例如，PBS[8]，SUNGridEngine[14],andSSH），已经提供这样的能力。PMI库提供了PMIAPI。然，PMI库的实现，可能依赖于系统本身。某些情况下，诸如用于IBMBlueGene/L(BG/L)[3]，PMI库没准使用的系统特定功能来PMI提供服务。还有，比方说用在典型的商品集群中，PMI库和processmanager通信用的是滴滴专车（例如，TCP）。PMI库可以任性的被实现，只要特定的实现乐意，在PMI-1和PMI-2有一个商量好的“连线协议（wireprotocol）”，是数据交换socket接口。使用这种协议的优点是，任何应用使用PMIAPI并遵守预定义PMI“连线协议”的程序能兼容任何P接受了PMI“连线协议”的PMIprocessmanager。我们注意到，PMIAPI和PMI“连线协议”是独立的实体。一个实现可以选择实现两者，或它们中的一个。例如，在BG/L的PMI库提供PMIAPI，但不使用基于socket的连线协议。因此，该库兼容任何这个PMIAPI库的程序，但是它不兼容接受了基于socket的PMI连线协议的processmanagers。2.2概述第一代PMI（PMI-1）并行应用程序的进程需要相互进行通信。建立这种交流通常需要发布一个联系地址，没准是个IP地址，一个远程访问存储器段，其它互连的特定标识符啥的。由于processmanager知道所有的进程在哪里，也没准它管理一些掌握的标准I/O（标准输入，标准输出和stderr）进程的通信，所以自然，它拥有processmanagement系统还提供了用于信息交换的基本设施。这就是我们processmanagement的关键功能，PMI——一种认同，即这两个功能是紧密相关的，并且可以通过一个单一的服务被有效地提供。虽然PMI本身是通用的任何并行编程模型，而不仅仅是MPI，为了便于讨论，我们只考虑在MPI编程这里模型。在MPI的情况下，PMI处理各种乱七八糟的，例如提供给每个MPI进程它自己的信息（如它的rank），以及程序中有关其他进程的信息（如MPI_COMM_WORLD的size）。此外，每个启动并行应用程序的PMIprocessmanager被期望维护一个包含所有这些信息的数据库。PMI定义了一个可移植的接口，使得MPI程序通过将信息添加到数据库（put操作）和查询程序中其他进程增添的信息（“get”操作）与processmanager交互。PMI的功能被转化成由PMI供应商库中相应的连线协议，然后和processmanager交流。大部分数据库是通过使用键值对交换数据的。除了“put”与“get”的操作，PMI还提供了集体的“fence”操作可以让有效地进行集体的数据交换（如何使用fence更详细的在第2.3节）。一个MPI库和PMI库和之间的交互示例,这时候processmanager管理着并行应用程序有两个进程，P0和P1，其中P0要数据发送到P1。是介样婶滴，MPI初始化的过程中，每个MPI程序都添加自己的信息到PMI数据库，这样其他进程可以联系到它。当P0调用MPI_Send到P1时，MPI库可以从PMI数据库查阅有关P1，通过使用该信息连接到P1（如果需要的话），并发送数据。2.3PMIRequirements之于ProcessManager的PMI需求在processmanagemen的设计过程中，对于processmanager有两个主要的需求。首先，需要仔细功能划分，以便于尽可能低开销的耗费在自身processmanager分层上。这种要求的出现是因为许多系统已经有某种形式的一个紧密绑定到系统的processmanager（通常与资源管理器集成）。可移植的PMI必须有效地利用这些现有的而不需要额外开销的系统（例如，无需原系统之外的额外进程）。例如，接口需要数据异步处理或中断来管理数据可能导致额外的开销，就算是它们不与PMI服务交互;这可能是在大规模系统的一个主要问题。其次，一个可扩展的键值系统的数据交换方式是必须的。这第二个要求具有若干方面。要弄一种系统，其中每一个进程在并行作业开始的过程中，产生一个“联络id”，并希望使它对并行作业中的其他进程可用。一个简单的方法来做到这一点，进程以向中央服务器提供数据，例如，将数据表示为（键，值）对存到一个简单的数据库中。如果P进程都存放到中央服务器，时间复杂性为O（p）;当时所有进程都只提取一个单一的值也是O（P）。这种做法显然是不可扩展的。这时使用多台服务器就行，但引入了另个问题。我们以PMI的解决方案是提供一个集体抽象，允许使用高效率的集体算法，以提供更具可扩展性的行为。在此模型中，进程将数据放入一个键值空间（KVS）。然后，他们共同执行一个fence操作。继fence完成后，所有的进程对KVS可以执行get操作。这样的设计允许多种实现。最重要的，fence步骤，这是对所有进程的集体操作，提供一个极好的机会来实现分发数据，这些数据通过一个可伸缩的方式put操作来提供。3第二代PMI(PMI-2)虽然PMI-1的基本设计被广泛采用了大量的PMI库和processmanagmers，但因为我们弄到更高级功能的MPI以及较大的系统上，PMI-1的若干限制浮出水面。第二代的PMI（PMI-2）解决了这些限制。PMI-2接口的完整信息（包括函数名），和连线协议都放在网上了[10，11]。为了避免啰嗦，我们在本文中就不提了。我们还是说说PMI-2比PMI-1改进了啥。缺乏查询功能：PMI-1提供了一个简单的key-value数据库用于存取。虽然processmanager最有能力了解各种系统的具体细节，然PMI-1并不允许它与MPI进程来分享这些信息。换句话说，processmanager本身无法把系统具体信息的键值添加到数据库中;从而MPI进程不能从processmanager查询这些信息。一个这个限制的例子就是，在多核和多处理器的系统，MPI实现必须确定哪些进程驻留在同一SMP节点上（例如，创建共享存储器段或用于分层聚集）。每个进程通过获取所有其他MPI进程的联系信息，收集这一信息，，并确定哪里是自己的安身之地。虽然这种方法很行得通，它是非常低效的，因为PMI获取每个MPI进程的操作是O（P）（整个操作O（P^2））。PMI-2引入了作业的属性的概念，它是Processmanager提供的预定义的键。使用这样的密钥，processmanager可以传递系统的具体资料给MPI进程;也就是说，这些键是processmanager直接添加到键值库的，允许每个MPI程序用一个操作就能以获取有关的所有MPI进程中的布局信息。另外，由于processmanager知道这样的属性是只读的，它可以通过缓存在本地代理副本优化其存储，因此把PMI查询请求从O（P^2）（在PMI-1里）降到接近零（在PMI-2里）。数据库信息范围(scope)：PMI-1采用了扁平的key-value数据库。也就是说，一个MPI进程不能限制它添加到数据库中的一个键的范围(scope)，所有的信息是全局的。因此，如果某些信息只想给本地进程的一个子集，PMI-1就提供不了任何机制让MPI进程告诉processmanager这么干。例如，仅和本节点上进程有关的shared-memorykeys的信息，但processmanager不知道往哪儿存放或者复制这样的信息更好。为了解决这个问题，PMI-2