利用针对本地检查点的卸载程序模型的制作方法

利用针对本地检查点的卸载程序模型的制作方法
【专利说明】利用针对本地检查点的卸载程序模型
【背景技术】
[0001] 近些年对高性能计算(HPC)的使用和兴趣显著增加。历史上，HPC通常与所谓的"超 级计算机"相关联。超级计算机在20世纪60年代被引入，最先并且在数十年来主要由控制数 据公司（CDC)的Seymour Cray、Cray研究所以及带有Cray的名字或字母组合的后来的公司 制造。尽管20世纪70年代的超级计算机仅使用几个处理器，但是在20世纪90年代，开始出现 了具有上千个处理器的机器，并且最近已经实现了具有数十万"现成的"处理器的大规模并 行超级计算机。
[0002] 存在许多类型的HPC架构，既有被实现的也面向研究的，其具有各种级别的规模和 性能。然而，共同线程是诸如处理器和/或处理器核的大量计算单元(也被称为计算实体或 本文中的计算实体)来以并行的方式共同地执行任务的互连。根据最近的片上系统(SoC)设 计方案和提议，使用二维（2D)阵列、环面、环或其它配置来在单个SoC上实现数十个处理器 核等。另外，研究者已经提议了3D SoC，根据所述3D SoC，数百或甚至数千个处理器核以3D 阵列互连。单独的多核处理器和SoC还可以在服务器板上具有小间距(closely-spaced)，继 而被互连经由底板等进行通信。另一种普遍的方法是在服务器(例如，刀片服务器和模块） 的机架中对计算单元进行互连。声称一度是世界最快的超级计算机的IBM的Sequoia包括96 个服务器刀片/模块的机架，共1，572,864个核，并且当操作在峰值性能下时，消耗巨大的 709兆瓦。
[0003] HPC使用并行处理方法来使得用于解决复杂作业或任务的作业载荷能够被分布在 多个计算实体间;这可能需要使用数千甚至数十万个实体。考虑到实体失败的统计分布，随 着用于HPC作业的实体的数量的增加，在HPC作业期间发生实体失败的速率指数地增长。这 个指数性的失败速率已经在HPC界以及商业的云服务提供者之间成为热点。
[0004] 为了解决实体失败的可能，可以以如下方式执行HPC作业:使得能够从这种失败恢 复，而不需要重做该作业(或该作业的重要部分）。这通常通过检查点重启方案来完成。根据 一个常规方法，以频繁的速率(检查点之间的时间段被称为历元(epoch))和同步的方式周 期地取检查点，其中，对于每一个历元，停止对检查点组中的所有实体的处理，对每一个实 体执行检查点操作，以及重启实体。检查点组的粒度是相当分层次的，并且可能涉及数百或 数千个实体。
[0005] 在每一个检查点期间，数据被写入某种形式的非易失性存储设备(例如，通过网络 访问的大型存储设备或这种设备的阵列）。数据包括作业处理状态信息和经由在每一个实 体上的软件的执行而产生的作为输出的数据二者。这导致显著量的存储消耗，并且整体处 理带宽的显著部分被有效地浪费了。在一些实例中，相关联的存储消耗和该常规的检查点 重启策略的执行限制使得实际的结果不那么可持续或甚至不那么实际。
【附图说明】
[0006] 由于通过参照以下详细描述可以更好地理解本发明的前述方面和许多其附带的 优点，因此，当结合附图来理解时，本发明的前述方面和许多其附带的优点将被更容易地理 解，其中，除非特别说明，否则贯穿各个视图，相似的参考标记指示相似的部件：
[0007] 图1是示出了用在HPC环境中的常规并行处理方案的简化视图的示意图；
[0008] 图2是示出了用于处理与可执行作业相对应的代码段的卸载程序模型的简单实现 的不意图；
[0009] 图3是示出了由源和宿以及故障转移(failover)心跳监控器执行的操作和逻辑的 组合流程图和消息流图；
[0010] 图4是示出了卸载域拓扑的第一示例的示意图，所述卸载域拓扑包括连接到在单 域中实现的多个宿的源；
[0011] 图5是示出了卸载域拓扑的第二示例的示意图，所述卸载域拓扑包括连接到一对 源的作业调度器，所述一对源继而被连接到在单域中实现的多个宿；
[0012]图6是示出了卸载域拓扑的第三示例的示意图，所述卸载域拓扑包括连接到一对 源的作业调度器，所述一对源继而被连接到在第一域和第二域中实现的多个宿；
[0013]图7是示出了卸载域拓扑的第四示例的示意图，所述卸载域拓扑包括经由作业调 度架构连接到多个源的作业调度器，以及其中，所述源经由卸载架构连接到第一域和第二 域中的宿；
[0014]图8是示出了包括模块化数据中心(pod)、机架、托盘以及托架的数据中心物理层 次的示意框图；
[0015] 图9是双插槽服务器平台的示意图，在其中实现了多个MIC，以及包括被实现为第 一源的第一主机处理器，和被配置为作为第二源操作的第二主机处理器；
[0016] 图10是示出了根据利用Inter? Xeon Phi? MIC协处理器的一个实施例的软件架 构的示意框图，其包括MIC协处理器PCIe卡1002上实现的软件部件，该软件部件包括MIC协 处理器软件和主机软件；
[0017] 图11是用来得到MIC中引擎的数量和得到第一引擎的句柄的指令的伪代码列表；
[0018] 图12a和12b使用C0I进程分别地示出了用于卸载函数的示例性源侧和宿侧伪代码 列表；以及
[0019] 图13a和13b分别地示出了用于设置和使用缓冲器的示例性源侧和宿侧伪代码列 表。
【具体实施方式】
[0020] 本文描述了用于利用针对本地检查点的卸载程序模型的方法、装置以及系统的实 施例。在下文描述中，阐述了大量具体细节，以便提供对本发明的实施例的透彻理解。然而， 相关领域技术人员将认识到的是，可以在不具有具体细节中的一个或多个的情况下实践本 发明，或者利用其它方法、部件、材料等来实践本发明。在其它实例中，没有详细地示出或描 述众所周知的结构、材料或操作，以便避免模糊本发明的方面。
[0021] 贯穿本说明书所引用的"一个实施例"或"实施例"意指结合该实施例描述的特定 的特征、结构或特性被包括在本发明的至少一个实施例中。因此，在贯穿本说明书的不同地 方出现的短语"在一个实施例中"或"在实施例中"不必全都指代同一个实施例。此外，特定 的特征、结构或特性可以以任何适当的方式组合在一个或多个实施例中。
[0022] 为了清楚，本文附图中的单独部件还可以通过其在附图中的标签进行指代，而不 是由特定的附图标记来指代。另外，指代特定类型的部件的附图标记（与特定部件不同）可 以使用后接"(typ)"（其意味着"典型的"）的附图标记来示出。应当理解的是，这些部件的配 置是可能存在但为了简洁及清楚而未在附图中示出的类似部件的典型配置，或者未用不同 的附图标记进行标记的类似部件的典型配置。相反，"(typ)"不应被解释为表示该部件、元 件等典型地用于其公开的功能、实现、目的等。
[0023]根据本文公开的实施例，并且结合本地检查点方案来使用卸载程序模型，所述本 地检查点方案满足高可靠性要求同时改善了性能和减少了存储和/或与常规的检查点相关 联的网络业务。在一方面中，该方法针对在HPC环境中的实现，尤其是针对大规模HPC作业是 有优势的。然而，其在异构计算环境中也极为好用，所述异构计算环境中的运行实体可以从 小型手持设备一直延伸到高容量服务器。
[0024]图1示出了用在HPC环境中的常规并行处理方案的简化视图。如在图1中所示，由第 一计算实体托管的作业调度器100经由互连104耦合到多个计算实体102。通常，HPC环境将 被用于使用并行处理方法来解决整体作业或任务，根据所述并行处理方法，整体作业或任 务被划分为在大量计算实体上并行执行的较小的作业。如下面描述的，作业调度器负责将 较小的作业调度到计算实体并且协调检查点。此外，大的任务可以涉及以层次等配置的多 个作业调度器。可以通过各种术语来指代针对层次中的给定等级的计算实体的聚集，诸如 集群、作业组以及其它术语，尽管作业组可能包括多个集群。
[0025]通常，计算说明可以包括能够执行对应于作业或任务的软件的任何实体。计算实 体包括但不受限于服务器、计算机、计算设备、处理器以及处理器中的核。互连104是代表包 括网络链路(例如，以太网、无限宽带（InfiniBand)等）、高速串行互连(例如，外围部件互连 快速(PCI Express或PCIe))以及在处理器片上系统(SoC)内的互连的各种类型的互连的一 般互连。此外，在异构环境中，计算实体可以经由包括不同类型的互连的一个或多个互连连 接到作业调度器和/或其它计算实体。
[0026] 如在图1中进一步所示，作业调度器100将作业106调度到相应的计算实体102。通 常，每一个作业106可以包括要被计算实体执行的可执行代码。作业106还可以包括要被操 作的数据和/或代码，所示代码本身可以指代要由计算实体从存储设备取回、经由代码的执 行而被操纵以及随后被存储的数据。出于说明性的目的，数据被存储在网络存储设备108 中，其可以包括单个存储设备、存储阵列、或者本领域公知的其它储存装置。实体的集群或 计算实体本身还可以包括其中存储有作业相关的数据的本地存储设备。另外，可以使用各 种超高速缓存方案来增强系统性能。
[0027] 在图1中示出了分配给计算实体102-1的作业A的抽象的描述。该作业包括可执行 代码，所述可执行代码包括主循环，所述主循环包括被标记为F 〇〇()、Bar()…以及Qux〇的 多个函数。给定的作业可以包括完全的可执行的应用（例如，独立的应用）、或者可以包括代 码模块等。根据一些实现，作业调度器可以首先将可执行的应用或模块调度到计算实体，并 且随后发送要由该可执行的应用或模块操作的数据(或以其它方式，标识数据的位置）。为 了简单起见，作业106的集合被示为调度到相应的计算实体102。在实际中，新的作业可以当 处理整体作业或任务时被动态地生成，并且被异步地调度到各个计算实体。根据一个通用 的方案，计算实体"公告"其可用性，并且作业调度器基于诸如可用性、处理能力以及存储器 资源的考虑来动态地确定向哪些计算实体发送给定的作业。
[0028] 由于并行处理架构的特性，所有作业成功地完成是关键的，否则整体任务将失败。 由于某些作业的输出供给随后作业的输入，因此甚至单个计算实体的失败可能导致整体失 败。存在用于解决该问题的各种方法，包括将同一个作业调度到多个实体，并且将作业的最 先成功的完成用于随后的作业。然而，该方法是浪费的，这是因为从事不被最先完成的作业 的实体的处理带宽(来自被调度同一个作业的其它实体之间）最终没有被使用。
[0029] 另一个方法利用周期检查点/重启序列。根据一个常规检查点方案，执行下面的操 作:首先，做出（例如，由调度器或在层次中较高的实体)检查点应该在何时和在哪被取的确 定。随后，将"停顿"请求发布给批量作业内的每一个运行实体。在进行下去之前，进程等待 所有的实体确认停顿请求并且暂停其运行(或以其它方式，确认其处于暂停的状态）。这时， 所有实体将其状态(也被称为"上下文"）写出到存储设备。在所有实体确认对存储设备写入 的完成期间，发生第二等待。这使得完成被用信号发送到实体。
[0030] 在用信号发送检查点完成之后，重启序列开始。首先，将作业重新调度进新分配的 实体(g卩，被调度到新的计算实体）。每一个实体随后从存储设备中读取其保存的上下文，并 且确认其准备就绪以重新开始。等待时段继而发生，直到所有实体确认其准备就绪，这时， 将重新开始信号发送到每一个实体以重新开始。
[0031] 前述的常规方法具有许多问题，随着规模变大，它们中的一些问题会恶化。第一， 仅在向实体发送指令以及返回状态中就涉及大量的网络业务开销。第二，当针对每一个实 体的上下文被保存时，在每一个历元期间存在突发存储操作。典型的网络存储方案具有有 限的输入/输出（10)带宽，并且能够提供到存储设备的同时存取。相反的，注意到各种超高 速缓存方案通常被用于改善性能，必须以顺序的方式来处置每一个存储设备存取请求。此 外，写出每一个实体的上下文需要大量的存储空间，尤其是对于大规模作业。
[0032] 本文公开的实施例的方面利用了不同的方法。实施例使用卸载程序模型，与根据 常规的检查点/重启方案，通过应用编码器和/或操作人员手动的插入相比，所述卸载程序 模型自动地以及机会性地定义合适的检查点。其还不暂停运行实体，这产生增强的性能，这 是因为由处理器暂停导致的处理带宽丢失不再存在。相对于根据常规方案的全局和冗长的 同步开销，同步量(如果存在的话)被显著地减少。状态/上下文保存操作可以被分解并且可 以通过整体作业执行来展开。这显著地减少了可能争夺存储带宽以及存储空间的突发存储 10操作。
[0033] 根据一方面，在域形成期间执行智能的预规划存储设置。这允许计算实体的最佳 拓扑布置并且允许存储设备解决大的并行作业规模问题。所保存的状态/上下文的大小显 著更小，这是因为其不要求存储完整的进程图像。这使得使用更少的空间以及针对重启的 更好的成功率。
[0034] 建在卸载程序模型之上，所公开的方法将批量作业分解为更小的虚拟作业载荷 域。每一个域进行其自己的本地检查点。此外，可以以递归的方式实现该方法。从卸载程序 范例继承，该方法针对异构计算环境是尤其有利的，在所述异构计算环境中，所集聚的计算 实体可以由不同的CPU架构组成和/或由不同的操作系统支持。
[0035] 作为概述，图2描绘了用于对与给定作业相对应的代码段进行处理的卸载程序模 型的简单的实现的说明。包括主机机器并且操作为"源"200的处理实体经由互连208耦合与 包括"宿" 202、204以及206的三个卸载机器耦合通信。在这个示例中，图1中的针对作业A的 三个函数FooO、Bar()以及QuxO的执行被从源200卸载到相应的宿202、204以及206。
[0036]进一步参照图3中的流程图和消息流图300,如下实现了根据一个实施例的卸载程 序模型检查点方案。图3中示出的实体包括源302、故障转移心跳监控器304以及包括宿306 的卸载实体。尽管未示出，但是实际的实现将包括多个宿实体。通常，可以在除了源或宿的 任何宿之外的源或单独的实体(未示出）中实现故障转移心跳监控器304。
[0037]针对源302描绘的操作在块308中开始，在所述块308中，源具有基于卸载程序模型 的可执行结构。随后针对可执行结构中的每一个卸载代码段描绘了主循环，如由启动循环 块310和结束循环块312所描绘的。随后针对每一个经卸载的代码段来循环地、持续地执行 在块314、316以及318中描绘的操作。
[0038] 首先，在块314中，构造了卸载上下文。通常，卸载上下文应当包含用于卸载在请求 时能重启的足够信息。其应当包含诸如下列信息：宿标识、程序二进制参考或库参考、缓冲 器数据、环境变量和/或与作业载荷相关的函数参数。在一个实施例中，卸载上下文包括(要 执行卸载代码的宿的）链路地址、程序代码段二进制参考或包括与卸载的代码段相对应的 一个或多个函数的先前分布的库的参考、环境变量、函数参数以及缓冲器映射信息。可选择 地，如下面描述的，可以提前配置缓冲器映射的一些方面。接下来，存在一对被异步地执行 的相关操作。在块316中，在块314中生成的卸载上下文被发送到如由宿306描绘的可应用宿 设备。与之结合，在块318中，与在块314中生成的卸载上下文相对应的上下文对象被推给诸 如由网络存储设备108描绘的非易失性存储设备。可选择地，上下文对象可以被推给由源平 台提供的板载存储设备。根据另一个方案，上下文对象被写到与网络存储设备成镜像的板 载存储设备。
[0039] 为了简单起见，被卸载的代码段被描绘为发送到宿306。在实际的实现中，被卸载 的代码段会被发送到多个宿，其中给定的宿可能在整体作业的执行期间接收多个被卸载的 代码段。
[0040] 如在块320和宿306的决定块332中描述的，宿设备包括监听来自于源302的请求的 监听器。例如，这样的监听器是本领域公知的，并且可以包括监听用于与源302通信的特定 端口，或者以其它方式监听来自于源302的通信(例如，使用针对产生自源302的通信的源地 址来检测的）。一旦经由所检测的请求接收到卸载上下文，就由宿306运行（即，执行)在卸载 上下文代码中定义的函数或多个函数直到完成，如由块324和完成块326描述的。
[0041] 当代码段完成时，将与函数结果相对应的函数结果数据328返回到源，如上面参照 图2讨论的。在一些实施例中，通过直接地向由卸载上下文标识的存储器缓冲器写入数据来 将数据返回。在其它实施例中，如当宿远离源时，结果数据328被以分组的方式返回并且包 含所分组的数据可以用来确