1 / 31

机群检查点技术研究

硕士生毕业论文中期考核. 机群检查点技术研究. 学生：蔡景南 导师：孙凝晖 2010 年 1 月 14 日. 提纲. 1. 学位论文研究情况 2. 已取得的阶段性成果 3. 下一步的工作计划 4. 课程完成情况. 1. 学位论文研究情况. 检查点. 对更高计算能力的需求使得高性能计算机的处理器个数迅速增加，而处理器个数与节点数的增加同时带来了 MTBF 的迅速降低。 在故障概率一定的条件下，如果不使用检查点，程序平均执行时间随其有效执行时间呈指数增长，而使用固定间隔的检查点则呈线性增长。. 曙光 6000 的容错需求. 程序面对的挑战

cicero
Download Presentation

机群检查点技术研究

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 硕士生毕业论文中期考核 机群检查点技术研究 学生：蔡景南 导师：孙凝晖 2010年1月14日

  2. 提纲 • 1.学位论文研究情况 • 2.已取得的阶段性成果 • 3.下一步的工作计划 • 4.课程完成情况

  3. 1.学位论文研究情况

  4. 检查点 • 对更高计算能力的需求使得高性能计算机的处理器个数迅速增加，而处理器个数与节点数的增加同时带来了MTBF的迅速降低。 • 在故障概率一定的条件下，如果不使用检查点，程序平均执行时间随其有效执行时间呈指数增长，而使用固定间隔的检查点则呈线性增长。

  5. 曙光6000的容错需求 • 程序面对的挑战 • 曙光6000高性能计算机设计目标每秒浮点运算达到千万亿次，需要节点超过一万个，预计单节点平均无故障运行时间为100000小时，则整个机群的平均无故障运行时间小于10小时。 • 检查点系统面对的挑战： • 透明性：对应用程序的透明容错需求。 • 扩展性：数千个节点之间检查点的同步问题。 • 自动化的故障处理：自动故障检测与故障恢复。

  6. 开题以来的相关研究进展 • ORCM (The Open Resilient Cluster Manager ) • Maintain operation of running applications in the face of single or multiple failures of any given process within that application. • Proactively detect incipient failures (hardware and/or software) and respond appropriately to maintain overall system operation. • Support both MPI and non-MPI applications. • Provide a research platform for exploring new concepts and methods in resilient systems.

  7. 模块关系图 自动化的故障恢复 自动化的故障检测 + 自动化的检查点系统 基于IB通信的MPI程序检查点 TCP并行程序检查点系统 TCP通信检查点补丁 MVAPICH2-1.4 BLCR

  8. 2.已取得的阶段性成果

  9. 自动化检查点框架 • 主要解决的问题 • 透明性 • 应用程序不需要知道容错机制的存在，只要平台上有我们的容错系统，就可以对运行中的应用程序进行检查点容错 • 扩展性-曙光6000对容错的要求 • 规模 • 支持x86和龙芯处理器 • 支持TCP/IP和IB通信 • 故障检测 • 自动化检测故障并进行相应的处理 • 高效性，稳定性，正确性

  10. 基于TCP/IP的并行程序透明检查点 单进程检查点 并行程序检查点 BLCR TCP通信检查点 DCRD BLCR TCP通信检查点 DCRD GCTRL … BLCR TCP通信检查点 DCRD

  11. TCP通信检查点 Application (3) (2) (4) Origin Receive OutOfOrder (1) TCP Net Interface Send/Retransmit (8) Vars S/R OOO ICI (5) (7) (6) Receive OutOfOrder TCP Network path to peer Send/Retransmit Send/Retransmit ACK Destination (9) (10) Application

  12. 透明性 • 透明的级别 • 不需要修改应用程序的源代码 • 不需要重新编译和链接 • 不需要非标准函数库的支持 • 不需要其它中间件的支持 • 得益于DCR简单的设计和TCP/IP在并行应用程序中的优势，DCR可以应用到各种规模的计算环境中，从单节点单CPU环境到机群系统。 user DCRD APP KCR Kernel

  13. 龙芯平台的检查点 • 内核级的透明检查点操作需要保存和恢复CPU寄存器相关的信息，这是架构相关的工作。 • 成功将BLCR进程检查点移植到龙芯平台上，首次实现龙芯平台的内核级检查点功能。 • 使得我们的整个检查点架构不仅可以同时支持TCP/IP和IB的通信还可以同时支持X86和龙芯的CPU，扩大了适用范围。

  14. 自动化检查点框架 • 自动检查点 • 任务类型 • TCP/IP 网络程序 • 基于IB的MPI程序 • 加载模式 • MPD进程管理器 • mpirun_rsh加载模式 • 预设检查点时间间隔，处理检查点前后框架状态的更新。

  15. 自动化检查点框架 • 自动故障检测 • 在操作系统正常状态下检测任务程序崩溃或异常 • 故障检测依据 • 任务进程树状态 • 任务通信状态 • 任务进程CPU使用情况 • 任务结果输出文件等 • 故障出现时关闭自动检查点和自动检测模块并自动启用故障恢复模块

  16. 自动化检查点框架 • 自动故障恢复 • 根据故障类型进行相应资源准备 • 根据任务类型执行相应的检查点恢复流程 • 恢复后重新启动自动检测和自动检查点流程 • 故障恢复后，整个任务以及检查点框架的状态将与上一次检查点时刻一致 • 故障恢复可能会失败!

  17. 自动化检查点框架 生成文件 • 映象文件管理 • 通过内存中暂存文件降低检查点过程的任务中止时间开销和恢复过程中的读取映象文件时间开销。 • 通过特定规则的映射表，将映象文件备份到其它节点，以支持节点故障恢复和节点替换。 存于内存 任务运行 写入硬盘 冗余备份

  18. GCTRL 自动检测； 自动检查点； 自动恢复； 映象管理； 控制网络、通信网络 DCRD APP 对InfiniBand及MPI环境的检查点及恢复； MVAPICH2 KCR 内核级进程检查点；对龙芯的支持；TCP通信检查点； 组件关系图

  19. 控制流程和数据传输 GCtrl 控制流 数据流 Node_1 Node_n User Level User Level 自动检查点 NPB/ Linpack/ MM5 NPB/ Linpack/ MM5 自动故障检测 DCRD DCRD … 自动故障恢复 映象文件管理 Task Task KCR KCR Image Kernel Level Kernel Level

  20. 已完成的测试结果 • 基于TCP/IP的跨节点的自动检测和自动恢复。 • 扩展性：支持IPoIB环境下50个刀片节点512进程的Linpack和NPB测试 • 透明性：通过在内核修改TCP/IP协议栈代码达到对基于 TCP/IP 的并行应用程序的透明性 • 存储控制：已完成映像文件的压缩存储和读取 • 自动检测自动恢复：目前已完成自动检查点框架 • 实现基于IB的MPI程序的跨节点的自动检测和自动恢复的功能性测试。 • 实现龙芯平台的单节点进程检查点功能性测试。 • 模拟的网络环境下(在一个节点上运行多个DCRD)自动检查点框架对个位数节点至四位数以上的节点平稳支持。

  21. 测试数据说明 程序正常运行 A/C D B/E/G A B 程序运行过程中 作一次检查点 D E C 检查点操作导致的通信吞吐量变化趋势 恢复后 F B/E/G F G 一次检查点总开销为： CE – AB 恢复的总开销为： FG – ( AB - CD ) 恢复过程中通信吞吐量变化趋势

  22. 部分测试结果 **表中数据为上限值，且不包括读写磁盘开销

  23. 性能因素(NPB:cg 16节点 256进程) Checkpoint overhead Image size ( MB ) Sockets(#) 2000 Image size per node Sockets per node Time(s) 6 1600 1200 5 800 4 400 3 0 cg.A.256 cg.B.256 cg.C.256 cg.D.256

  24. 性能因素(NPB: BT, 256进程，16~40节点)

  25. 扩展性规模测试 节点1 DCRD_0 DCRD_1 DCRD_m-1 … 节点2 无差别的DCRD。 每次命令的分发都会自动根据当前命令的目的节点集合动态进行分组， 然后再依据分组后的路径多级递送和收集消息。 DCRD_m DCRD_m+1 DCRD_2m-1 … DCRD_2m DCRD_2m+1 DCRD_3m-1 … GCtrl DCRD_3m DCRD_3m+1 DCRD_4m-1 … DCRD_4m DCRD_4m+1 DCRD_4m-1 … … DCRD_nm DCRD_nm+1 …

  26. 与开题的对比 • 内容与目标基本一致，没有明显的变动。

  27. 3.下一步的工作计划

  28. 下一步的工作计划 • 针对机器崩溃需要进行节点替换的情况，已完成理论分析和大部分的编码。 • 映象备份策略，正在尝试分析和增加各种不同的解决方案。 • 扩展性方面，由于前期所有设计都充分考虑这一点，在框架整体完成后会进行更加系统化的测试和进一步的理论分析。 • 整合前面所有工作，形成一个紧密的界面良好的容错系统。

  29. 4.课程完成情况

  30. 课程完成情况 • 总共选修课程：38 学分 • 其中学位课：22 学分 • 部分课程列表 • 英语A • 计算机网络 • 软件理论基础 • 人工智能原理 • 网络攻击与防范 • 计算机系统性能评价 • 并行处理 • 高性能并行计算 • Internet服务质量控制

  31. 谢谢!

More Related