Enhancing Fault Tolerance in MPI for Modern InfiniBand
Chapter 2 ：一个多通信通道检查点/重启MPI框架设计
2.1 背景简介
用户请求设置检查点，由全局CR管理器形成“检查点请求”并把该请求发送给本地CR管理器（控制本地进程）。本地CR管理器通知InfiniBand通信通道（它是MPI进程的一部分）。InfiniBand通信通道管理器锁住所有通信，包括输出和缓存所有正在传输的信息和释放网络资源。然后调用本地CR管理器表明获得单独的检查点是很安全的。本地CR管理器命令CR库为进程设置检查点。我们的实现使用了BLCR包作为CR库。进程状态设置检查点易后，本地CR管理器告知InfiniBand通信通道管理器网络通信恢复活动。相似的，为了重启MPI任务，全局CR管理器向所有本地CR管理器发送“重启请求”。本地CR管理器获得该请求后，通过BLCR启动MPI进程并且通知InfiniBand通信管理器恢复网络。如我们所见，除了保存本地进程状态，协调检查点很重要的一步是处理通信通信通道保证所有单独的检查点达到一个一直状态。
2.2 检查点多通信通道MPI框架
本文提出的方法基于协调检查点协议。
CR层负责接收从任务管理器的请求，告知每一个通信层挂起/重启传输，决定一个已知的时间使用CR库（本文中使用BLCR）处理本地检查点操作。另外CR层需要跟踪进程的位置。。例如，如果两个在相同节点上的进程需要在不同的节点上重启，就应该检测到拓扑变化并且根据内部节点对网络的共享内存改变通信通道。为了保证在转换通信通道的时候按次序的消息传递，CR层保持两个重要的队列，最好的发送队列和暂时接收队列。设置检查点阶段开始，所有即将发送的操作就会被放到最好的发送队列中。与此同时，所有的通道发送完正在发送的数据并提供给临时接收队列。这样，设置检查点期间通信通道离没有生育信息。所以，在重启之后转换通信通道是安全的。
每一个在设置检查点期间需要挂起的管道需要实现这些功能并通过一个标准接口为CR层提供挂起/重启挂钩。CR层在需要的时候名这些接口，并且不需要考虑这些管道的详细设计规范。
2.3 详细设计与挑战
2.3.1 点对点通信
新的CR框架为每一个通信通道提供挂钩来注册框架的回收功能。每一个通信通道的回收函数在设置检查点进程期间由框架命令启动。这个框架允许每一个通道注册两个回收函数为了提供设置点对点通信检查点的能力。这两个函数，命名为“Suspend callback”函数和“Resume callback”。
SuspendCallback function
在CR库使用检查点之前，设置检查点期间由CR框架命令挂起该回收函数。这个函数的任务是设置检查点之前准备通道。协调检查点使用以后，挂起路线用来保证这个通道不会再处理发送的信息并且没有信息正在发送过程中（in flight）。这可以保证所有的进程在一致状态。
ResumeCallback function
在CR库使用检查点之后，设置检查点期间由CR框架命令挂起该回收函数。同时CR库存储从硬盘中得到的先前设置检查点的进程。
2.3.3 Checkpointing Collective Operations
为集合操作设置检查点，使用两种回收函数请求：检查点回收函数请求和完成回收检查点。
Requestto Checkpoint Callback function
Request to Checkpoint Callback function 在设置检查点请求发生时有本地CR管理器命令。调用告知检查点请求的集合并立即返回。调用返回后，本地CR管理器等到集合表明他们已经准备好被设置检查点的通知。
在内部节点操作中设计的进程停止他们的通信并自动添加一个特殊领域的共享内存区域。每个进程添加完之后继续检查这个领域。当它的数量与本地节点进程的数量相等是，表明所有的进程已经停止集合通信。这时，所有本地进程达到一致状态。选择一个leader复制共享内存区域里的内容存入本地缓冲区并且超出集合的共享内存区域。这些完成以后，这个节点上的所有进程吊桶CTC（Clear to Checkpoint）并等到设置检查点完成。
在RTC调用期间通过指针被传送给集合的（Clear to Checkpoint 函数）CTC接收所有通知。当准备好被设置检查点时，集合调用CTC。
CR框架现在就可以命令CR库执行设置检查点操作。
CheckpointComplete Callback function
检查点设置完以后，或者进程已经从先前设置的检查点重启，框架命令Checkpoint Complete Callback function（CC）表示CR操作完成。
当CC被命令，等待检查点完成的集合操作里的进程复活。Leader进程利用集合的共享内存区域并存储在本地缓冲区中存储的数据结构。一旦leader完成创建共享内存区域，所有的进程从callback中返回。
这是，系统状态与RTC被激发之前的状态一致。因此，所有通道上的通信正常运行。
