PMI：可扩展并行进程管理A Scalable Parallel Process-Management.docx

PMI：A Scalable Parallel Process-Management可扩展并行进程管理摘要。大规模系统的并行编程模型要求一种可扩展的系统来管理 组成了执行并行程序 的进程。process management必须能够很快地启动拥有数以百万计进程的并行程序，并且必须提供进程交换信息的机制以使它们彼此连通。 MPICH2及其衍生版本通过一个精心定义的接口来实现这个功能，叫PMI，它允许不同的process manager用标准化的方式和MPI库交互。在本文中，我们描述了PMI的功能。我们描述了PMI-1（目前的为MPICH2及其所有衍生版本通用的），也描述了PMI-2.， 第二代的PMI（消除了PMI-1的各种缺陷）。除了接口本身，我们还分别描述了在新的MPICH2 process management架构（叫Hydra）中PMI-1和PMI-2的参考实现，并比较它们在运行千个MPI作业时的性能。1 引言虽然process management是高性能计算（HPC）的一个组成部分系统，但是它没得到同水平其他方面并行系统软件的关注，却是由来已久了。在百个节点的系统中，process management的可扩展性并不令人关注。随着HPC系统变得越来越大，系统上千个节点和数万的处理内核越来越普遍; 事实上，世界上最大的系统已经使用几十万处理内核。对于这样的系统，process management基础架构的可扩展设计成为了各个方面的关键，这些方面包括启动和管理并行应用程序，可调试和管理工具。process management系统必须，也理所当然的，以可扩展的方式的启动和停止进程。此外，它必须提供机制让并行的进程交换信息，以建立它们之间的通信。虽然HPC系统规模的日益扩大需要 并行编程库（如MPI）和过程管理器（process manager） 之间的密切交互，但这两个部件之间的适当的分离是必要的。这种分离不仅使得他们可以独立开发和改进，也保持并行编程库足以通用于任何process management框架。同时，这两个组件必须共享足够的信息，以便允许并行编程库利用其所运行系统的具体特点的优势。考虑到这些要求，我们最初设计了PMI，一个为并行应用程序的通用process management接口。在本文中，我们首先描述第一代的PMI（PMI-1）。 PMI-1被广泛用于MPICH2 1和从它派生的其他MPI实现，如MVAPICH2 4，英特尔MPI 6，SiCortex MPI 12，以及微软的MPI 7（编程库部分），以及许多process-management框架，包括MPICH2的内部process-management（Hydra，MPD，SMPD，Gforker，Remshell），外部process-management，如SLURM 15，OSC mpiexec9，OSU mpirun 13（process-management部分）。虽然非常成功，PMI-1有一些局限性，特别是当应用于现代HPC系统。这些限制包括涉及到的问题有大量核心在单个节点上的可扩展性，MPI和线程混合编程模型的高效交互，其他。基于我们PMI-1的经验，我们最近设计了一个二代接口（PMI-2），克服PMI-1的缺点。该本文的第二部分介绍了描述了在新的MPICH2 process management架构（叫Hydra）中PMI-1和PMI-2的参考实现。我们也通过阐述大约6000进程规模上的性能测试结果，比较PMI-2同PMI-1以及其他process management接口的能力。2 process-management接口需求在这个部分，我们提供了一个简要概述来描述在大规模系统中可扩展的并行程序管理的process management接口。2.1 解耦Process Manager和Process-Management interface在我们的模型中，过程管理包括三个主要部分：（1）并行编程库（例如MPI），（2）PMI库，和（3）process manager。这些组件就是在图1中举例示，不同的MPI库，PMI库和process managers。进程管理器（process manager）是一个逻辑上中心进程（但往往实际上是分布式的一组进程），用于管理（1）进程启动（包括启动/停止进程中，为每个进程提供的环境信息，标准输入/输出/ ERR转发，传播信号）和（2）信息在并行应用程序之间传递（例如，建立交流信道）。几个可用的process managers（例如，PBS8，SUN Grid Engine 14, and SSH），已经提供这样的能力。PMI库提供了PMI API。然，PMI库的实现，可能依赖于系统本身。某些情况下，诸如用于IBM Blue Gene/L (BG/L)3，PMI库没准使用的系统特定功能来PMI提供服务。还有，比方说用在典型的商品集群中，PMI库和process manager通信用的是滴滴专车（例如，TCP）。PMI库可以任性的被实现，只要特定的实现乐意，在PMI-1和PMI-2有一个商量好的“连线协议（wire protocol）”，是数据交换socket接口。使用这种协议的优点是，任何应用使用PMI API并遵守预定义PMI“连线协议”的程序能兼容任何P接受了PMI“连线协议”的PMI process manager。我们注意到，PMI API和PMI“连线协议”是独立的实体。一个实现可以选择实现两者，或它们中的一个。例如，在BG/L的PMI库提供PMI API，但不使用基于socket的连线协议。因此，该库兼容任何这个PMI API库的程序，但是它不兼容接受了基于socket的PMI连线协议的process managers。2.2概述第一代PMI（PMI-1）并行应用程序的进程需要相互进行通信。建立这种交流通常需要发布一个联系地址，没准是个IP地址，一个远程访问存储器段，其它互连的特定标识符啥的。由于process manager知道所有的进程在哪里，也没准它管理一些掌握的标准I/O（标准输入，标准输出和stderr）进程的通信，所以自然，它拥有process management系统还提供了用于信息交换的基本设施。这就是我们process management的关键功能，PMI一种认同，即这两个功能是紧密相关的，并且可以通过一个单一的服务被有效地提供。虽然PMI本身是通用的任何并行编程模型，而不仅仅是MPI，为了便于讨论，我们只考虑在MPI编程这里模型。在MPI的情况下，PMI处理各种乱七八糟的，例如提供给每个MPI进程它自己的信息（如它的rank），以及程序中有关其他进程的信息（如MPI_COMM_WORLD的size）。此外，每个启动并行应用程序的PMI process manager被期望维护一个包含所有这些信息的数据库。 PMI定义了一个可移植的接口，使得MPI程序通过将信息添加到数据库（put操作）和查询程序中其他进程增添的信息（“get”操作）与process manager交互。PMI的功能被转化成由PMI供应商库中相应的连线协议，然后和process manager交流。大部分数据库是通过使用键值对交换数据的。除了“put”与“get”的操作，PMI还提供了集体的“fence”操作可以让有效地进行集体的数据交换（如何使用fence更详细的在第2.3节）。一个MPI库和PMI库和之间的交互示例,这时候process manager管理着并行应用程序有两个进程，P0和P1，其中P0要数据发送到P1。是介样婶滴， MPI初始化的过程中，每个MPI程序都添加自己的信息到PMI数据库，这样其他进程可以联系到它。当P0调用MPI_Send到P1时，MPI库可以从PMI数据库查阅有关P1，通过使用该信息连接到P1（如果需要的话），并发送数据。2.3 PMI Requirements 之于Process Manager的PMI需求在process managemen的设计过程中，对于process manager有两个主要的需求。首先，需要仔细功能划分，以便于尽可能低开销的耗费在自身process manager分层上。这种要求的出现是因为许多系统已经有某种形式的一个紧密绑定到系统的process manager（通常与资源管理器集成）。可移植的PMI必须有效地利用这些现有的而不需要额外开销的系统（例如，无需原系统之外的额外进程）。例如，接口需要数据异步处理或中断来管理数据可能导致额外的开销，就算是它们不与PMI服务交互;这可能是在大规模系统的一个主要问题。其次，一个可扩展的键值系统的数据交换方式是必须的。这第二个要求具有若干方面。要弄一种系统，其中每一个进程在并行作业开始的过程中，产生一个“联络id”，并希望使它对并行作业中的其他进程可用。一个简单的方法来做到这一点，进程以向中央服务器提供数据，例如，将数据表示为（键，值）对存到一个简单的数据库中。如果P进程都存放到中央服务器，时间复杂性为O（p）;当时所有进程都只提取一个单一的值也是O（P）。这种做法显然是不可扩展的。这时使用多台服务器就行，但引入了另个问题。我们以PMI的解决方案是提供一个集体抽象，允许使用高效率的集体算法，以提供更具可扩展性的行为。在此模型中，进程将数据放入一个键值空间（KVS）。然后，他们共同执行一个fence操作。继fence完成后，所有的进程对KVS可以执行get操作。这样的设计允许多种实现。最重要的，fence步骤，这是对所有进程的集体操作，提供一个极好的机会来实现分发数据，这些数据通过一个可伸缩的方式put操作来提供。3 第二代PMI (PMI-2)虽然PMI-1的基本设计被广泛采用了大量的PMI库和process managmers，但因为我们弄到更高级功能的MPI以及较大的系统上，PMI-1的若干限制浮出水面。第二代的PMI（PMI-2）解决了这些限制。PMI-2接口的完整信息（包括函数名），和连线协议都放在网上了10，11。为了避免啰嗦，我们在本文中就不提了。我们还是说说PMI-2比PMI-1改进了啥。缺乏查询功能：PMI-1提供了一个简单的key-value数据库用于存取。虽然process manager最有能力了解各种系统的具体细节，然PMI-1并不允许它与MPI进程来分享这些信息。换句话说，process manager本身无法把系统具体信息的键值添加到数据库中;从而MPI进程不能从process manager查询这些信息。一个这个限制的例子就是，在多核和多处理器的系统， MPI实现必须确定哪些进程驻留在同一SMP节点上（例如，创建共享存储器段或用于分层聚集）。每个进程通过获取所有其他MPI进程的联系信息，收集这一信息，并确定哪里是自己的安身之地。虽然这种方法很行得通，它是非常低效的，因为PMI获取每个MPI进程的操作是O（P） （整个操作O（P2）。PMI-2引入了作业的属性的概念，它是Process manager提供的预定义的键。使用这样的密钥，process manager可以传递系统的具体资料给MPI进程;也就是说，这些键是process manager直接添加到键值库的，允许每个MPI程序用一个操作就能以获取有关的所有MPI进程中的布局信息。另外，由于process manager知道这样的属性是只读的，它可以通过缓存在本地代理副本优化其存储，因此把PMI查询请求从O（P2）（在PMI-1里）降到接近零（在PMI-2里）。数据库信息范围(scope)：PMI-1采用了扁平的key-value数据库。也就是说，一个MPI进程不能限制它添加到数据库中的一个键的范围(scope)，所有的信息是全局的。因此，如果某些信息只想给本地进程的一个子集，PMI-1就提供不了任何机制让MPI进程告诉process manager这么干。例如， 仅和本节点上进程有关的shared-memory keys的信息，但process manager不知道往哪儿存放或者复制这样的信息更好。为了解决这个问题， PMI-2引入了节点级别和全局级别的“scope”的键（PMI-2更严格的scope限制不支持，这虽失一般性却有利于简洁）。例如，对于共享内存段的键可以被限制为节点级范围，从而使process manager来更好地提取。MPI+线程的程序：PMI-1不是线程安全的。因此，在多线程MPI程序情况下，MPI实现调用PMI-1时必须使用适当的锁定机制保护。这种锁往往是粗粒度，并且PMI库和process manager之间是序列化通信。也就是说，PMI库发送一个查询给process manager一直到得到了它的响应（一个往返通信），没有其他的线程可以在同一socket上通信。 PMI-2允许线程安全的PMI功能。因此，多个线程可以更细粒度的方式与服务器通信，从而管道请求更好，提高了性能。动态进程：在PMI-1的每个进程组维护一个单独的数据库和进程不允许查询整个数据库的信息。对于动态产生的进程，这是一个严重的限制，因为它需要这些进程自己去交换他们的数据库信息，并加载它们到单独的数据库中。此过程是繁琐和高消耗（性能和内存使用）。 PMI-2理念中的job，可以是互相关联的多个应用程序或者是一个从另一个spawn出来的。这使得这样job分享数据库中的信息，而无需明确地复制。容错：PMI-1当故障发生时，不指定任何重生进程机制。请注意，这是和生产MPI-2动态进程说的是两回事，因为spawn进程将形成其自身的进程组（MPI_COMM_WORLD），而不仅仅是取代现有的进程组中的进程。 PMI-2提供重生理念，其中一个新的进程本质上取代同一进程组内的原进程。在MPICH2中，PMI-2已实现新的process management框架的一部分，称为Hydra5。4 Experimental Evaluation and Analysis4实验评价与分析在这部分，我们阐述了一些PMI-1和PMI-2的性能对比实验结果。4.1 系统信息查询功能正如上面第三部分描述的，PMI-1仅提供了简单的键值数据库用于存取，所以process manager不能为MPI进程提供系统信息的查询。因此为了确定哪些进程处在同一SMP节点上，需要O(p2) PMI操作。使用PMI-2s作业属性, 这个性能降低到几乎为零。这个是MPI程序启动时间的反馈。图示2（左）展示的是简单MPI应用（只调用MPI_Init和MPI_Finalize）,在PMI-1和PMI-2分别在5670核SiCortex系统的表现。如图所示，在PMI-1里，总的启动时间随着系统规模增大而迅速增长。而PMI-2，明显少了很多。图2显示了从process manager收到PMI请求数目的视角，对于两个PMI实现更多的分析。此图说明了两者之间性能区别的原因：PMI-1比PMI-2的PMI请求多了几个数量级。4.2 新增功能对本地process manager的影响如3.2部分所述，一些系统拥有一个process manager（往往和resource manager合体），和系统紧密绑定。而有的process manager自身就提供了PMI的功能，有的则没有。高效执行的PMI接口须有效的利用这些本地process manager，不再需额外的开销（例如，通过要求唤醒其他进程心跳操作，而干扰核心计算）。在这节中，我们以1600核的SiCortex系统和NAS并行C类标准在两种模式下评估这种“噪音影响”：（1）利用系统本地process manager， SLURM-已经提供了PMI-1的服务，（2）使用Hydra process manager，内部使用SLURM进程启动和管理，但在额外的守护进程之上提供PMI服务。如图3所示，附加的PMI（传说中的Hydra）在本地process manager（传说中的SLURM）之上，对系统的影响并没有太多的开销。图3（左）显示对运行时间的影响，对开销毫无赶脚。图3（右）示出了大量的应用程序运行时，最高和最低的执行时间差异（百分比表示）。还是，在多数情况下，毫无差别（0%），最大也不过EP应用有0.5%的差异。如此低开销的一个最大的原因就是PMI的设计完全靠同步动作，所以呢没有不同步的PMI的服务deamon进程。也就是说，一旦初始化结束，只要MPI进程不发PMI请求，就没有额外的开销了。4.3 多线程MPI应用程序的性能随着每个节点上核数量的增长，人们开始研究把MPI和线程放在一起用，MPI可能被一个进程的多个线程调用。由于PMI-1不是线程安全的，所以所有的PMI调用必须以粗粒度的附加锁保护；所以在某时间内只能有一个线程和process manager联系。而我们说PMI-2允许多个线程和process manager以细粒度的方式通信。在该实验中，我们使用基准评价（不断对process manager的发布和撤销服务）来测量PMI操作的并发性。PMI-1每个线程获得一个锁，发送发布服务的请求，然后就等着process manager的响应，然后释放锁。PMI-2,每个PMI的请求都有一个线程ID；故，PMI库可以发完一个请求就释放锁（让别的线程也能发请求）就算是没收到响应。当process manager响应了发布请求时，它就把原来的线程ID发回来，传递给相应的线程。图4是这样线程支持的示意，就像图里看到的，PMI-1中，增加线程的数量并不能减少单次MPI请求的平均时间，因为全部的请求都是串行的 (所有线程的总工作量是固定的). 在PMI-2中,多线程进行PMI并行请求时，所有的请求都是细粒度的方式，能获得更好的并发性。所以平均PMI每个线程延迟是较小的。我们注意单线程的例子，比起PMI-1，PMI-2有额外开销。这不是期望的结果，我们正研究咋回事。4.4 可选Process management框架的比较在本节中，我们比较了实现了PMI-2接口的可选process management框架，OpenRTE。OpenRTE2（ORTE）是Open MPI 所使用的process management系统。它为并行Process management提供稳健和透明的支持。 和PMI一样，它包括“键值对”系统用于MPI进程和process management系统之间沟通。图5比较了MPI应用程序的启动时间， 分别是PMI-2实现的Hydra和OpenRTE的。如该图所示，PMI-2性能比ORTE3这796-核心商品集群上略胜一筹。5 相关工作改进并行编程模型的process-management框架是老生常谈了。然而，大多数努力都集中在改进Process manager本身如何启动和管理进程。OSC的mpiexec9，OSU的mpirun（也称为SceLA13，和SLURM 15就是这样的例子。OSC mpiexec的是一个MPI应用程序的process manager其内部用PBS 8启动和管理作业。这是一个集中式的process manager使用多种process management连线协议通信，包括PMI-1。俄勒冈州立大学（OSU）的mpirun是基于SSH的;它采用分层的方法来启动进程，并与PMI-1交互。SLURM 15不同于其他主流process manager，因为它提供一个完整的基础设施，启动和管理进程;它也提供了其自己的与进程进行交互的PMI-1实现。而所有这些实现寻求提高对大型系统的process management，我们的工作的不同点在于不去学习这些实现接口（MPI库和process manager之间）的需求和限制，而是PMI API和连线协议。ORTE提供了一种机制用于MPI进程同集成process manager交互。然而，它并没有明确分离这些功能，就像PMI和其相关的连线协议。总之，我们的工作不同于其他process-management系统的功能和底层架构。与此同时，PMI-2起到了和这些系统的互补作用，它可以与之同时使用。6结束语本文中，我们阐述了通用的process management接口，PMI，它使得不同的process management框架能够和并行编程库交互（如MPI）。我们首先描述了目前MPICH2及其衍生产品使用的PMI-1。继而我们描述了新的第二代PMI，PMI2，它克服了现今HPC系统中PMI-1的缺点：包括单机器上大量内核的扩展性问题，MPI和多线程混合编程的有效交互。结合PMI-1和PMI-2设计细节, 本文还描述了MPICH2上的一个新的process management框架名叫Hydra的设计实现。我们的性能结果Our performance results证明了显著的性能提升从PMI-1到PMI-2.参考文献1. Argonne National Laboratory: MPICH2. /research/projects/mpich22. Castain, R., Woodall, T., Daniel, D., Squyres, J., Barrett, B., Fagg, G.: The OpenRun-Time Environment (OpenRTE): A transparent multi-cluster environment forhigh-performance computing. In: Recent Advances in Parallel Virtual Machine andMessage Passing Interface. pp. 225232. Springer (2005)3. Gara, A., Blumrich, M., Chen, D., Chiu, G., Coteus, P., Giampapa, M., Haring,R., Heidelberger, P., Hoenicke, D., Kopcsay, G., Liebsch, T., Ohmacht, M., SteinmacherBurow,B., Takken, T., Vranas, P.: Overview of the Blue Gene/L systemarchitecture. IBM Journal of Research and Development 49(2/3) (2005)4. Huang, W., Santhanaraman, G., Jin, H., Gao, Q., , Panda, D.: Design of high performanceMVAPICH2: MPI2 over InfiniBand. In: Proceedings of the sixth IEEEInternational Symposium on Cluster Computing an