论文阅读-多级检查点重新启动MPI应用的共同设计

论文名称：Co-Designing Multi-Level Checkpoint Restart for MPI Applications

摘要—高性能计算（HPC）系统继续通过包含更多硬件组件来支持更大的应用部署来扩展。关键是，这种扩展往往会减少故障之间的平均时间，从而使容错成为一个越来越重要的挑战。在HPC中容错的标准做法是检查点/重新启动。已经有一些重要但独立的工作来创建快速的应用层检查点恢复技术和MPI层的快速恢复技术。然而，这些技术是独立操作的，虽然它们彼此预设，但它们并没有被设计成共同优化端到端的应用恢复。

我们提出了FRAME，一种容错解决方案，通过首次将异步多级检查点库（称为容错接口（FTI））与MPI的在线容错解决方案（称为Reinit）相结合，显著减少了应用程序恢复时间。我们的方法共同设计了加速应用程序恢复的优化。具体来说，FRAME利用Reinit启用的MPI来提取故障拓扑，并优化FTI中的检查点检索，以节省识别和获取系统中最新可用检查点的重要开销。与基线FTI相比，FRAME优化可将检查点检索时间减少高达67%。包括基于Reinit的MPI恢复的结果表明，我们的方法在恢复32,768个MPI进程的大规模执行部署中，当恢复1.3TB的检查点数据时，端到端恢复时间最多可以缩短360%。

关键词—容错、检查点重新启动、MPI

I. 引言

现代HPC系统集成了大量节点，每个节点包含异构计算设备，如CPU、GPU、多个网络接口和分层存储系统，包括固态硬盘（SSD）和实现并行文件系统（PFS）的专用节点。HPC系统通过增加这些组件的数量来扩展，也增加了系统发生故障的可能性。因此，现有系统中故障间隔时间（MTBF）已经从几天的顺序减少到几小时的顺序。长时间运行并利用大部分系统资源的HPC应用程序最容易受到故障的影响。因此，容错是现代HPC系统和软件的重要设计方面。

使用MPI进行HPC应用程序的容错的典型做法是检查点重新启动（C/R），如图1中的灰色箭头时间轴所示。在执行期间，应用程序周期性地写入其状态的检查点（应用程序检查点）。当发生故障时，执行中止，拆除MPI进程的现有部署，并通过两个步骤重新启动计算：i) 重新部署应用程序以恢复MPI进程及其相互通信（MPI恢复），以及ii) 通过检索最新的检查点，读取它并恢复计算（应用程序恢复）。在优化这两个步骤中已经付出了重大努力，但没有同时进行。

最先进的容错技术要么专注于应用程序恢复，要么专注于MPI层恢复。我们的方法（FRAME）通过执行跨层优化，显著缩短了MPI应用程序的恢复时间。

具体而言，以前的工作[8]–[11]致力于优化MPI恢复，目标是在线恢复MPI，而无需拆除和重新部署MPI执行以节省开销。Reinit [9]–[11]支持全局重新启动恢复，类似于标准的应用程序C/R。用户级容错（ULFM）[8]也支持在线恢复，但提供了一个更复杂的API来开发应用程序定制的MPI恢复策略。尽管如此，这些最先进的MPI恢复方法中的任何一个都假定了应用程序级的检查点，尽管它们对其操作一无所知。最先进的应用程序恢复基于多级异步检查点技术，其中检查点存储在具有不同延迟和容错特性的存储设备（本地或远程RAM-Disk/SSD、PFS等）的层次结构中。从故障中恢复时，多级检查点技术假定MPI执行已恢复。对于应用程序恢复，检索检查点需要通过复杂的过程，其中包括耗时的全对全通信和I/O操作，以识别、验证和读取最新一致的检查点位置以恢复应用程序状态。尽管异步检查点存储和复制最大程度地减少了对应用程序执行的干扰，但检索检查点的性能缩放差，且根据故障的严重程度和频率，可能成为瓶颈。

MPI恢复和应用程序恢复的优化工作通常是分开研究的。因此，缺乏关于它们如何共同工作以及如何共同设计优化以加速端到端恢复的实验数据。本文填补了这一空白。具体而言，我们提出了一种名为FRAME（Fault toleRAnt Mpi with chEckpoint-restart）的解决方案，它加速了端到端的应用程序恢复。它结合了多级异步检查点和在线MPI恢复技术，从而继承了它们的优化 - 无需额外开销 - 同时通过共同设计一个用于应用程序恢复的检查点检索优化来加速恢复。

作为一个激励性的例子，图2对使用三种不同策略的基准HPCCG所花费的容错时间进行了对比：i）使用FTI进行多级异步检查点和通过重新部署进行MPI恢复，ii）使用Reinit作为MPI恢复的同步检查点方法，以及iii）FRAME。FRAME从FTI和Reinit继承了快速检查点和MPI恢复，同时通过减少约40％的时间显著加速了检查点检索。

在使用 1024 个节点执行 HPCCG 任务且检查点大小为 1 TB 时，容错操作所花费的时间。

更详细地说，我们的贡献包括：

1. 我们提出了FRAME的设计和实现，这是一种通过首次将在线MPI恢复（使用Reinit）与多级异步应用程序C/R（使用FTI）相结合的解决方案，加速了应用程序的故障恢复。
2. 我们共同设计了一种优化方法，通过将故障拓扑信息从MPI恢复传递到应用程序恢复，以优化故障后的检查点检索。这些信息加速了检查点检索算法，以找到、验证并读取不同可用检查点级别和节点中最近可用的检查点。利用故障拓扑，我们的方法避免了在应用程序恢复期间发生的昂贵的集体通信和验证过程。
3. 我们进行了大规模评估，使用了多达1024个节点和32768个MPI进程，运行了三个HPC代理应用程序（HPCCG、CoMD、LULESH）。评估模拟了不同类型的故障，这些故障需要从不同的检查点级别检索检查点，具体取决于故障的严重程度和数量。与仅使用FTI和Reinit进行对比的结果显示，FRAME的检查点检索优化可以将应用程序恢复时间减少高达67％，而包括Reinit而不是重新部署MPI恢复的端到端恢复时间则快高达360％。值得注意的是，在文献中对这种规模的容错方法进行评估是罕见的。

II. 背景

A. 系统错误类型

硬件错误可分为可恢复和不可恢复两种。 可恢复错误，例如DRAM或磁盘中的位翻转[15]，由硬件（例如，纠错码（ECC）[16]）或操作系统处理。不可恢复错误可分为软错误和硬错误。软错误导致故障但不影响硬件可用性，例如，不可纠正的双重DRAM位翻转会引发软件异常[17]。这些错误被视为软故障。不可恢复的硬错误包括处理单元、主板和电源供应故障[15]，[18]。这些错误导致节点不可用。

FRAME专注于导致一个或多个节点受影响的不可恢复硬件错误，从而导致软或硬故障。正式地，我们将故障拓扑（F）定义为一组唯一标识的失败节点。故障的严重程度等于失败节点的数量，表示为|F|。先前的研究[12]，[17]–[19]表明，单节点故障更为频繁，占大型系统故障的85%以上。然而，在过去的故障发生后，另一个故障发生的可能性很高，表明尽管系统中的MTBF很高，但存在多节点故障的强烈可能性。

B. 应用程序检查点

最先进的多级检查点[12]–[14]将检查点存储在不同级别的层次结构中，这些层次结构具有增加的存储延迟或数据编码成本，同时也增加了它们的弹性。表I显示了文献中报告的现有多级检查点方法[12]，[13]以及它们的弹性特征。简而言之，L1是最快的检查点级别，但是弹性最低，而级别L4是最慢但最有弹性的。每个检查点级别都能从未受这些故障影响的数据重建检查点数据，从而恢复不同严重程度的故障。当故障的严重程度需要至少级别k的检查点才能成功恢复时，我们将故障称为Lk-故障。

检查点级别及其弹性。

通过异步方法可以优化存储检查点，在异步方法中，应用程序进程将检查点数据写入快速的本地存储（RAM、SSD），而后台检查点管理器进程将这些数据转换（编码和复制）到更高的检查点级别。例如，在伙伴检查点中，后台进程将检查点从本地存储复制到伙伴节点的存储，将其从L1检查点转换为L2检查点。

C. 故障恢复

故障发生后，恢复和恢复应用程序执行有两个步骤。首先，MPI恢复恢复应用程序的MPI进程及其互通，以重新启动应用程序的执行。其次，应用程序恢复检索和加载应用程序状态的最新一致检查点，以从该点继续计算。

MPI恢复。MPI恢复的标准做法是在发生故障时中止执行，从而终止现有的MPI应用程序，并在无故障的节点集上重新启动应用程序。通常，用户创建一个作业脚本，检查应用程序的退出状态。如果退出状态表明执行被中止，作业脚本将通过重新部署重新启动应用程序。尽管这种方法很直接，但会带来很高的开销，并且扩展性较差。

为了节省MPI重新部署的开销，在线MPI恢复技术避免中止应用程序。相反，它们扩展MPI以进行故障检测，并为开发人员提供MPI恢复的API。Reinit扩展了MPI运行时以检测MPI进程的故障并重新生成失败的MPI排名到现有节点集，在软故障的情况下，或者在硬故障的情况下，重新生成到作业分配时预配的备用节点集。另一种在线MPI恢复方法是ULFM，它使用一组低级原语扩展MPI。这些原语使应用程序开发人员能够实现应用程序定制的MPI恢复，包括但不限于标准C/R中的典型重启方法。然而，大多数高性能计算（HPC）应用程序遵循批量同步编程（BSP）范式，并且为了容错实现了标准C/R方法。先前的研究[9]–[11]表明，Reinit有效地取代了标准C/R，需要较少的侵入性代码重构，并且比ULFM表现更好，因此我们选择以Reinit为基础来构建FRAME。

应用程序恢复。在MPI恢复之后，应用程序恢复检索最新的一致检查点，以快速前进应用程序的计算。

D. 重新初始化和FTI

重新初始化需要程序员将应用程序的操作封装在一个 resilient_main 函数中，该函数在发生故障时作为幸存进程的回滚点。它通过使用 MPI 的 API 扩展了 MPI_Reinit 函数的调用，该函数以 resilient_main 函数的函数指针作为参数。列表 1 显示了接口。resilient 函数接受一个额外的参数，指示进程的状态（第一次执行时为 NEW，如果是回滚的幸存进程则为 REINITED，如果进程替换了一个失败的进程则为 RESPAWNED）。当检测到故障时，幸存的 MPI 进程回滚并重新执行 resilient_main，而重新生成的 MPI 进程从程序的主函数开始初始化 MPI。在重新生成的进程进行 MPI 初始化和幸存进程进行重新初始化后，执行将继续使用由 Reinit 修复的有效 MPI_COMM_WORLD 通信器。Reinit 模仿了标准 C/R 的重启过程，但不需要终止 MPI 执行，只针对失败的 MPI 进程进行有针对性的重新部署。

Reinit 假设 MPI 执行具有分层部署。在层次结构的顶部是根进程，它启动一些 MPI 守护进程，每个节点上启动一个守护进程，用于应用程序的作业分配。依次，这些守护进程在它们的主机节点上生成一些子 MPI 应用进程。根进程通过从进程的父 MPI 守护进程接收故障通知来检测软故障。通过检测节点上的 MPI 守护进程是否失败来检测硬故障。当根进程检测到故障时，它通过向所有幸存的 MPI 守护进程广播 Reinit 命令来启动恢复。值得注意的是，Reinit 对故障处理进行序列化，以协调恢复，因此多节点故障按先进先出的顺序处理。

FTI。FTI 中多级应用程序 C/R 的操作与其他方法类似。列表 2 展示了 FTI 的接口。通过称为 FTI_Init 的函数对库进行初始化（第 1 行）。该函数负责在应用程序启动之前执行所有必要的操作。FTI 读取并验证配置文件选项，然后识别每个 MPI 进程所在的节点 id 以及当前执行的类型 - 是否需要恢复（正常执行） - 通过读取存储在配置文件中的变量的值。

在恢复情况下，FTI_Init 执行额外的步骤。具体来说，它使用迭代算法来识别、验证并从使应用程序恢复的最低检查点级别加载检查点。算法 1 展示了伪代码中的过程，所有 MPI 应用程序进程都执行。每个进程从最低检查点级别迭代到最高检查点级别，并在本地验证不损坏并且具有足够信息以进行恢复（第 3 行）。然后进行一轮全对全通信（第 4 行）。所有进程交换当前级别检查点的本地有效信息，并通过逻辑与所有本地有效数据的逻辑合并达成全局有效一致性。如果有共识（第 5 行），迭代停止，并且所有进程从此级别加载检查点（第 6 行）到临时内存位置，并成功返回。否则，过程继续到下一个检查点级别。如果过程在任何级别未找到任何有效检查点，则无法执行应用程序恢复，并且恢复过程返回一个为应用程序处理的零值。

根据故障的严重程度，这种迭代过程可能执行多次验证和全对全通信轮次，直到达成共识，增加恢复时间。这种开销对大规模应用程序来说很高，在频繁故障的情况下会积累。检查点检索是我们协同设计恢复优化的目标。用户可以使用 FTI_Protect 函数（第 2 行）定义连续的内存区域。在检查点期间，该区域存储在 C/R 文件中，而在恢复期间，数据加载到指定的内存区域。FTI_Snapshot 的功能取决于执行的类型。在恢复时，FTI_Snapshot（第 3 行）将数据从在 FTI_Init 调用期间读取的临时内存位置复制到适当的应用程序内存位置。在成功恢复后，该函数将执行类型设置为正常执行。在正常执行期间，FTI_Snapshot 负责存储检查点。是否进行检查点取决于配置文件中定义的用户指定的检查点频率。最后，FTI_Finalize（第 4 行）检查所有未完成的检查点，释放任何 FTI 内部数据结构，并将配置文件中的执行模式变量设置为正常执行。

III. 框架操作与优化

本节详细介绍了框架（FRAME），包括在 Reinit 和 FTI 中支持联合操作和优化所需的必要扩展，以及用于检查点检索的联合优化的协同设计优化的设计和操作，以及有关FRAME内部和如何使用它的实现细节。

A. 使用框架及其扩展

框架利用 Reinit 的编程接口进行 MPI 恢复和 FTI 进行应用程序恢复，提供了一个统一的容错解决方案。此外，它扩展了这些接口，以从 Reinit 传播故障拓扑信息到 FTI 并优化检查点检索。

列表 3 展示了使用框架的示例，以绿色突出显示协同设计检索优化中的扩展。解析此示例，开发人员将应用程序操作封装在 resilient_main 函数中，以使用启用了 Reinit 的 MPI 恢复。此函数的指针作为参数传递给 MPI_Reinit 调用（第 15 行），并携带参数 argc、argv，这些参数反映了程序主函数的初始化参数，以转发到 resilient_main。除了这些初始化参数外，resilient 函数还接受一个额外的参数，如第 II-D 节所讨论的。框架扩展了 Reinit 接口和实现，以将故障拓扑信息传播到 resilient_main。具体而言，框架添加了存储失败等级数量的参数 NumFailed，并且指向一个失败的 MPI 等级标识符数组的参数 FailedRanks。框架使用这些添加的参数来计算故障的严重程度和拓扑。框架要求在 resilient_main 函数内调用 FTI_Init（第 5 行），以在发生故障时使用修复后的 MPI_COMM_WORLD 通信器初始化 FTI。相反，在 resilient_main 执行完成并在 MPI 结束之前，调用 FTI_Finalize（第 16 行）。对于检查点数据的检查点操作（line 7）是 resilient_main 中弹性操作的一部分。FTI_Snapshot（line 9）的调用再次位于 resilient_main 中，并且特别是位于应用程序的主计算循环中以读取或写入检查点。框架扩展了 FTI_Init，以转发由启用 Reinit 的 MPI 运行时传递给 resilient_main 函数的故障信息的参数 NumFailed 和 FailedRanks。FTI 包括将 MPI 等级映射到主机节点的内部数据结构，因此它可以计算故障的拓扑和失败节点的数量（F、|F|）。这些故障信息是协同设计检查点检索优化的基础。

B. 故障恢复和检查点检索优化

在本节中，我们详细描述了框架对 Reinit 和 FTI 执行的扩展。图 3 展示了从故障中恢复的框架的完整工作流程。红色框对应于由框架扩展的 Reinit 或 FTI 的步骤，蓝色框对应于框架引入的新功能。我们现在讨论每个单独的步骤（显示为步骤 X）。

第一步。在收到故障通知时，根节点启动故障处理，如算法 2 所示。它存储在应用程序层尚未处理的故障，通过将新故障 f 插入 F 中。在硬故障中，失败的 MPI 守护程序将被备用守护程序取代。最后，根节点广播 Reinit 命令和失败进程的标识符给守护程序。

第二步。MPI 守护程序接收 Reinit 命令以回滚幸存的 MPI 进程并重新生成失败的进程。故障拓扑被转发到幸存者和重新生成的 MPI 进程的 resilient_main 函数。

第三步。此时，所有 MPI 进程（旧的和新生成的）的执行控制都设置为 resilient_main 代码，并且应用程序执行已恢复。

第四步。此步骤扩展了 FTI_Init 的操作。框架通过检查 MPI_COMM_WORLD 等级是否包含在 FTI_Init（FailedRanks 中传递的包含失败进程的集合中）的参数中来确定执行 MPI 进程是幸存者还是新进程。幸存者进程清理故障之前使用的 FTI 内部数据结构，并清理用于检查点的任何数据，例如与异步检查点相关的数据。最后，框架通过使用失败进程的标识符和将 MPI 等级映射到主机节点的内部数据结构来计算节点故障的故障拓扑（F）。

第五步。在此步骤中，框架在 FTI_Init 的上下文中实现了检查点检索优化。优化通过检查故障拓扑并将其与确定检查点级别的一组故障约束进行对比，以确定应用程序恢复的最小可能检查点级别。通过此优化，FTI 跳过了几轮耗时的验证和所有节点通信，因为检查点级别不能在给定故障拓扑下恢复。

算法3展示了优化的恢复过程。每个进程创建一个检查点集合Gn，描述了哪些节点被分组以执行级别为n的检查点。Gn直接来源于表I中每个检查点级别的可恢复性描述。例如，在伙伴检查点中，G2包含一对标识符，即拥有检查点的等级的主机节点标识符和其伙伴节点的标识符。此外，FTI为每个级别n维护了可用性约束Cn。约束定义了不能从哪个故障节点数量开始，该检查点级别将无法恢复。例如，C2 = 2表示如果两个节点在同一个伙伴组G2中，则2个节点故障将使L2检查点无法使用。每个进程遍历可能的检查点级别，以找到可能恢复的最小检查点级别。每次迭代都会检查该检查点级别的组集合与故障拓扑的交集中节点数量是否小于该级别的约束（第4行）。进程进行一轮全互连通信来计算最大可恢复的检查点级别。

第6步。之后，所有进程使用算法1加载最新的有效检查点（由前一步骤识别）。

第7步。最后，MPI进程通知其父守护程序应用程序恢复已完成，然后守护程序通知根进程。当根进程收到所有守护程序的通知时，它清空保存故障信息的数据结构。

VI. 实验设置

基准测试。我们使用CoMD、HPCCG和LULESH作为基准测试。这些基准测试旨在测试容错的不同方面。HPCCG（一个弱扩展应用程序）在每个节点的检查点大小保持不变时，识别了我们方法的好处。我们在相同数量的节点上执行LULESH，并使用不同的检查点大小。CoMD（一个强扩展应用程序）确定了我们方法在每个节点的检查点大小由于扩展而减小时的行为。表II总结了每个应用程序的详细信息。

度量标准。我们将FRAME与重新部署MPI恢复的FTI在以下方面进行比较：i）检查点开销：应用程序将检查点数据存储在本地RAM-Disk上所花费的时间。ii）检查点转换：后台进程将本地检查点转换为更高级别的检查点所花费的时间。iii）MPI恢复：执行MPI恢复所花费的时间。该时间对应于从故障发生点到应用程序恢复执行的时间。iv）应用程序恢复：应用程序用于识别正确的恢复级别、从该级别转换检查点并从中恢复所花费的时间。v）完全恢复：MPI恢复和应用程序恢复的累计时间。在FTI配置中，我们将每个后台检查点管理器设置为负责八个应用程序排名。

故障模拟。我们使用故障注入来模拟故障。为了测试从不同检查点级别恢复，我们注入不同类型的故障。因此，我们注入L1至L4级的故障。L1故障对应于软故障，L2对应于单节点故障，L3对应于损坏伙伴节点的硬故障，而L4故障则会损坏同一RS编码组的五个节点。对于软故障，一个随机的MPI进程引发SIGKILL信号杀死自己，而对于硬故障，一个MPI进程发送SIGKILL信号给其父守护进程，从而杀死所有节点的MPI进程，并使节点失败。

我们尝试了两种故障时序行为，模拟单事件翻转（SEU）或多事件多翻转（MEMU）。在SEU中，单个故障导致|F|个节点失败。在MEMU中，N个故障一个接一个地发生，给定|F|= N。第一个故障在正常执行期间注入。其余故障在MPI恢复后逐个注入，并且执行控制回到应用程序。SEU故障注入在执行重新部署MPI恢复时进行。MEMU故障注入到在线和重新部署MPI恢复实验中。因此，我们可以比较重新部署MPI恢复的最佳情况，即SEU故障导致单个MPI重新部署的情况，以及其最坏情况，即MEMU故障需要多次重新部署的情况。在线MPI恢复序列化故障处理，无论是SEU还是MEMU故障。

系统特性。所有实验都在Quartz超级计算机上进行。Quartz中的每个节点都配备有Intel Xeon E5-2695 v4 36核处理器、128GB DRAM内存和一个Lustre PFS。

V. 评估

我们的评估显示，FRAME：(i) 不会增加FTI的检查点时间，(ii) 不会增加Reinit的MPI恢复时间，(iii) 可以提高FTI的应用程序恢复能力。最后，当使用跨层恢复方法时，它展示了恢复的总体收益。

A. 检查点存储性能

图4描述了在使用FRAME和FTI在1024个节点上执行CoMD时的检查点开销和检查点转换时间。在所有检查点级别上，这两个框架表现出相同的性能。正如预期的那样，当存储检查点时，FRAME的性能与FTI一样好。

B. MPI恢复性能

FRAME vs Reinit。图5比较使用Reinit和FRAME执行MPI恢复所花费的时间，针对不同的故障。FRAME在Reinit上引入的扩展没有增加任何额外开销。两种解决方案都串行化了故障处理，因此随着故障严重程度的增加，执行MPI恢复所花费的时间也会增加。

FRAME vs 重新部署MPI恢复。图6、7、8展示了使用FRAME进行MPI恢复时时间的减少。Min线对应于从SEU故障中恢复时的性能改善。Max线对应于从MEMU故障中恢复时的性能改善。因此，两条线之间的空间勾勒出了FRAME的潜在改进范围，具体取决于故障的时序行为。

在L1和L2发生单一故障时，时序并不重要，恢复时间是相同的。在HPCCG（图6）中，随着应用程序规模的增加，性能改善逐渐增加。在L1故障中，FRAME恢复非常快（比重新部署快1200%），因为恢复重用相同的节点集来重新生成失败的进程。由于FRAME的故障串行化，多节点故障中的性能改善较少。最常见的故障是L1或L2类型，因此FRAME有效地处理了常见情况。

在LULESH（图7）中，随着检查点大小变大，对所有故障类型性能改善增加。检查点大小并不直接对应应用程序使用的资源（内存、文件描述符等），但它是资源使用的一个很好指标。重新部署MPI恢复在故障发生时中止执行并重新部署，因此它需要等待这些资源被释放并在程序终止和MPI重新部署时重新获取。这增加了其MPI恢复时间。相比之下，FRAME不会释放幸存节点上的任何资源，只为替换失败进程而产生的MPI进程重新获取资源。CoMD的结果在图8中显示，随着应用程序规模的增加，性能收益会减少。这是由于应用程序的强比例执行，因为随着规模的增加，MPI进程使用的资源更少。因此，收益减少。如果将LULESH的最大检查点大小（1TB）与在256个节点上执行的检查点大小为2.8TB的CoMD进行比较，由于CoMD的检查点大小显著更大，因此CoMD的收益显著更高。L3和L4之间的Min-Max线之间的空间随着应用程序规模的增加而变宽。因此，在大规模执行中，由于重新部署应用程序的开销随着MEMU故障严重程度的增加而累积，MEMU故障对恢复有着相当大的影响。

C. 应用程序恢复性能

图9、10展示了在HPCCG和LULESH中比较FTI和FRAME的应用程序恢复性能改善。在两个应用程序中，从L1故障中恢复时我们并未观察到任何收益。这是预期的，因为最小可恢复检查点级别与最低检查点级别相匹配。因此，FRAME没有优化检查点检索的空间。

对于HPCCG，当存在L2和L3故障时，随着应用程序（弱）扩展，FRAME的改进逐渐增加。FRAME的优化跳过了所有对所有通信和验证轮次，由于扩展而增加的开销。虽然在L3故障的情况下，优化跳过了更多轮次，但L3检查点级别的数据解码阶段耗时。因此，改进并不像对待L2故障那样高。在L4故障中，无论应用程序的扩展如何，我们观察到大约50%的持续收益。由于从L4故障中恢复时会从PFS读取检查点文件，因此在集群中共享对网络存储的访问权，预计会观察到性能收益的波动。

在图10中展示的LULESH中，我们增加应用程序问题规模，并保持扩展恒定。在L2和L3故障中，随着检查点执行规模变大，性能改善略微减少。转换和读取检查点所需的时间增加速度快于从最小检查点级别中节省的时间。因此，我们观察到性能改善减少。最后，在L4故障中，性能改善在45%至67%之间波动。

D. 完全恢复性能

在第V-B节和V-C节中，我们分别介绍了使用FRAME进行MPI恢复和应用程序恢复时的性能增益。图11展示了对于不同严重性故障的HPCCG完全恢复时间的性能改善。我们比较了使用重新部署MPI恢复包括FTI与FRAME进行恢复所花费的总时间。随着应用程序的弱扩展，FRAME提供了更高的性能收益，除了L1故障的情况，其中改进几乎是恒定的，稍微降低到更高的规模。L1应用程序恢复过程非常快，因为应用程序从RAM磁盘中读取数据，因此在各个排名之间进行通信的延迟对整体性能有较大影响，从而减少了FRAME的观察到的收益。此外，在小规模执行中，从FRAME进行的MPI恢复的性能改善组成部分不那么重要，占据整体执行时间的比例较低。因此，尽管改进很高，但却是恒定的。然而，当执行规模扩展到更大节点数量时，MPI恢复的时间更长，因此来自FRAME的改进也随之增加。

在HPCCG中，观察到L2、L3、L4故障，使用FRAME减少MPI恢复时间和应用程序恢复时间的累积效应导致性能改善随着应用程序（弱）扩展而增加。在1024个节点上执行时，从L1到L4故障的恢复，FRAME的性能提高了360%、340%、135%和90%。

图12显示了LULESH完全恢复性能的改善。对于L1和L2故障，随着检查点大小的增加，改进减少。当使用小检查点大小恢复应用程序时，总恢复时间主要由执行MPI恢复所需的时间支配。随着检查点文件增大，执行应用程序恢复所需时间增加。因此，FRAME的改进MPI恢复的效果逐渐减少。恢复1TB数据时，我们观察到从L1到L4故障恢复的改进分别为250%、150%、23%和66%。

图13展示了CoMD的恢复性能改善。同样，FRAME的改进取决于故障类型，在这种情况下，应用程序强烈扩展，因此每个节点的检查点大小变小。这意味着总体恢复改进很高，但随着扩展可能略有减少，具体取决于故障类型。当使用32768个排名恢复2.8TB数据时，我们观察到L1、L2、L3和L4故障恢复的性能提高分别为230%、225%、65%和78%。

FRAME评估的关键见解：

1. FRAME在写入检查点时与最先进的多级检查点库（FTI）一样快。
2. FRAME在恢复MPI层时与最先进的MPI恢复库（Reinit）一样快。
3. 由于其检查点检索优化，FRAME在执行应用程序恢复时比FTI更快。
4. 应用程序利用的资源数量影响执行MPI恢复所需的时间。
5. 在FRAME中，当应用程序扩展弱时，性能改善增加。
6. 故障发生的时间可以显著降低重新部署MPI恢复的性能。
7. 当失败节点数量较少时，FRAME表现最佳。

 VI. 相关工作

C/R是最常见的故障容忍技术，在内核级别或用户级别实现[20]–[25]。已经付出了大量努力来降低C/R的开销，例如增量/差分检查点、检查点压缩和聚合[26]–[29]。为了避免I/O瓶颈，提出了无磁盘检查点[30]–[32]。多级检查点库[12]–[14]被认为是降低Exascale级别上检查点开销的关键元素[33]。已经提出了异步检查点，以利用额外的专用分段进程来隐藏C/R延迟[18]，[34]。所有这些优化仅关注于应用程序和写入检查点文件，而不关注它们的恢复。我们的工作侧重于恢复，并提供在线MPI恢复以恢复应用程序执行。

FT-MPI、HARNESS[35]、[36]是MPI恢复的最早尝试。故障检测和通信恢复是它们的一部分。MPI/FT[37]是一个类似的尝试，适用于主-工作和单程序多数据（SPMD）应用程序。ULFM[8]、[38]通过接口扩展了MPI，用于缩小或撤销通信器。应用程序使用相应的操作来实现恢复。在[39]中提出了一个可检查点的MPI解决方案，其中MPI状态在检查点中保存，并在失败时恢复。这项工作需要Exascale的进程管理接口（PMIx）和Slurm[40]、[41]来支持故障处理。

这些工作仅关注于MPI恢复，并假定存在应用程序的C/R支持。正如本工作所展示的，MPI和应用程序恢复的共同设计带来了显著的性能提升。

VII. 结论

我们提出了FRAME，一个新的故障容忍解决方案，通过将Reinit的在线MPI恢复与FTI中的多级异步检查点相结合，显著缩短了MPI应用程序在失败后的恢复时间。FRAME通过从Reinit传播故障信息到FTI来共同设计检查点检索优化，从而缩短了查找和加载正确检查点级别的时间。我们对FRAME在多个HPC代理应用程序的大规模执行中的评估表明，与没有FRAME优化的FTI相比，应用程序恢复速度提高了67％，由于在线MPI恢复和检查点检索优化，端到端的恢复速度提高了360％，与C/R的标准实践相比。文章来源地址https://www.toymoban.com/news/detail-844996.html

到了这里，关于论文阅读-多级检查点重新启动MPI应用的共同设计的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！