MPICH故障容错与检查点：ULFM用户级容错如何实现

MPICH故障容错与检查点：ULFM用户级容错如何实现

【免费下载链接】mpichOfficial MPICH Repository项目地址: https://gitcode.com/gh_mirrors/mp/mpich

在大规模 HPC 计算中，节点崩溃是常态而非例外。MPICH 故障容错功能让你可以在单个进程失败后让 MPI 应用继续运行，而不是整体重启。本文将带你了解 MPICH 的两种容错机制：ULFM（User Level Fault Management，用户级容错）与基于 BLCR 的检查点（Checkpoint）技术，并给出可直接上手的配置步骤 🚀

什么是 ULFM 用户级容错？

传统 MPI 程序一旦有一个进程失败，整个作业就会跟着终止。MPICH 提供的容错方案改变了这一局面：

机制	工作原理	适用场景
ULFM 进程容错	应用检测到失败进程后，用缩小编译器等手段继续运行	交互式作业、长时运行任务
检查点 / 重启	周期性保存进程状态，故障后从检查点恢复	大规模批处理作业

ULFM 的核心思想是：把"进程是否失败"的判断权交给应用程序，由用户决定是缩小编译器继续跑，还是撤銷通信器退出。官方设计文档见 doc/wiki/design/Fault_Tolerance.md 与操作指南 doc/wiki/how_to/Fault_Tolerance.md。

快速启用 MPICH 故障容错的 2 个配置步骤

想要用上容错功能，编译与运行时各需要一个关键开关：

1. 编译时开启完整错误检查

   ./configure --enable-error-checking=all

   这会让 MPICH 在调用 MPI 操作时正确检查通信器状态，是容错行为的前提。

2. 运行时禁用自动清理

   mpiexec -n 4 -disable-auto-cleanup ./myapp

   Hydra 进程管理器默认会在任何进程异常退出时杀掉整个作业，-disable-auto-cleanup正是阻止这一行为的开关。

此外，还需在应用内把通信器的错误处理器设为MPI_ERRORS_RETURN（而非默认的MPI_ERRORS_ABORT），这样通信失败会返回错误码而不是终止程序。

⚠️ 注意：目前容错仅实现于ch3:tcp设备，其他网络设备需要额外改造才能正确向上层返回错误。

故障是如何被检测和广播的？

ULFM 的底层依赖 Hydra 进程管理器 + PMI（Process Manager Interface）的协同工作：

1. 本地检测：Hydra 通过 Unix 机制（本地 socket 关闭）发现某进程异常退出；
2. 信号通知：Hydra 向各 MPI 进程发送SIGUSR1信号，告知"有进程死了"；
3. 全组广播：通知同时发送给 PMI 服务器，广播到所有进程；
4. 清理资源：CH3 进度引擎捕获信号后，调用MPIDI_CH3U_Check_for_failed_procs从 PMI 服务器拉取最新失败列表，随后关闭失败进程的 VC 连接、清空收发队列，并向挂起的请求写入错误码。

失败进程列表通过 PMI 属性PMI_dead_processes传递（形如"1,3-5,11"的逗号分隔 rank 列表），解析逻辑可见 src/mpi/comm/ulfm_impl.c。

5 个实用 API：故障之后怎么办？

MPICH 暴露了一组MPIX_Comm_*扩展接口，覆盖了容错的完整生命周期：

• MPIX_Comm_get_failed(comm, &failedgrp)返回当前通信器中"本地已知"的失败进程组——容错的第一步就是先查清楚谁挂了；
• MPIX_Comm_failure_ack(comm)确认失败列表，之后的ANY_SOURCE通配接收才会重新启用；
• MPIX_Comm_shrink(comm, &newcomm)最有用的一个：自动排除失败进程，创建新的存活进程通信器，应用可以直接切到新通信器继续计算；
• MPIX_Comm_agree(comm, &flag)所有存活进程就某个整数值达成一致，顺便检测是否存在未确认的新故障；
• MPIX_Comm_revoke(comm)彻底废弃一个通信器，阻止后续误用。

接口定义位于 src/binding/c/comm_api.txt，shrink/agree的核心实现在 src/mpi/comm/ulfm_impl.c 中——例如shrink内部会最多重试 5 次，确保所有存活进程对"新通信器"达成一致（见 MPIR_Comm_shrink_impl）。

官方还附带了完整的容错测试套件，位于test/mpi/ft/目录，包含 shrink.c（模拟 rank 2 退出后 shrink 重建通信器）、agree.c、revoke_shrink.c 等 20 多个用例，是学习正确用法的最佳范例 📚

MPICH 检查点（Checkpoint）：BLCR 保存与恢复

除了"带伤继续跑"，另一条路线是"定期存档、死后复活"。MPICH 借助BLCR（Berkeley Lab Checkpoint/Restart）实现检查点：

配置阶段（BLCR 不在默认路径时需要显式指定）：

./configure --with-blcr=/path/to/blcr

运行阶段——两种触发方式任选：

# 方式一：每 3600 秒自动检查点一次 mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/app.ckpoint \ -ckpoint-interval 3600 -f hosts -n 4 ./app # 方式二：手动发送 SIGUSR1 信号给 mpiexec 立即触发

故障后从第 N 个检查点恢复：

mpiexec -ckpointlib blcr -ckpoint-prefix /tmp/app.ckpoint -ckpoint-num 2 -n 4 ./app

检查点也可用环境变量HYDRA_CKPOINTLIB、HYDRA_CKPOINT_PREFIX、HYDRA_CKPOINT_INTERVAL控制。原理上，Hydra 的 proxy 进程在每个节点发起 BLCR 检查点，MPI 进程在回调中先执行净空协议（发送标记、关闭网络模块），保存完成后再恢复网络继续运行——细节见 doc/wiki/design/Checkpointing_implementation.md。

💡 提示：BLCR 支持在新版 MPICH 中已被移除，使用检查点功能前请确认你使用的版本仍带 BLCR 支持（可用mpiexec -info查看 "Checkpointing libraries available" 一栏）。

局限性：这些"坑"要先知道

容错功能是实验性的，使用前三思：

• 仅ch3:tcp设备支持完整容错行为；
• 故障通知（SIGUSR1）机制不受官方支持，未来版本可能改变；
• 集合通信在含失败进程的通信器上，可能只在"部分"进程返回错误——MPI_SUCCESS仅表示该进程自己的部分完成了；
• 若MPIX_Comm_shrink连续 5 次重试仍无法收敛，说明系统状态已不一致，此时应放弃作业并返回错误。

总结：MPICH 的故障容错 = Hydra 检测 + PMI 广播 +MPIX_Comm_*容错 API + （可选）BLCR 检查点。配置两个开关、把错误处理器改为MPI_ERRORS_RETURN，你的 MPI 应用就能从"一损俱损"进化为"损一不亡" 💪

【免费下载链接】mpichOfficial MPICH Repository项目地址: https://gitcode.com/gh_mirrors/mp/mpich