案例分析:Einstein@OSG

来自中国分布式计算总站
(重定向自Case Study: Einstein@OSG
跳转至: 导航搜索

Case Study: Einstein@OSG
案例分析:Einstein@OSG


原载:International Science Grid This Week
作者:Miriam Boon, iSGTW
日期:2010年3月17日
概要:一种新的应用 Einstein@OSG 将志愿者计算引入 Open Science Grid,目前 Einstein@OSG 已运行六个月,完成了 Einstein@Home 项目 10% 的工作量。


Einstein@Home 的屏保截图。
图片由 Einstein@Home 项目方提供。

在过去 5 年里,一群志愿者通过基于 BOINCEinstein@Home 程序,把他们机器的空闲时间,用来分析 LIGOGEO-600 项目的数据。现在,一种称为“Einstein@OSG”的封装程序 (wrapper),让 Einstein@Home 能运行在名为“Open Science Grid”的网格计算平台上。

虽然 Einstein@OSG 只运行了 6 个月,但却已经是 Einstein@Home 的最大贡献者。它完成了大约 10% 的 Einstein@Home 计算量。

罗伯特•安格尔 (Robert Engel) 是 Einstein@OSG 项目的负责人,他说:“网格非常适合运行这类程序。BOINC 会从我们提供的每一颗 CPU 中获益。随着 CPU 数量成千上万地增长,完成的计算任务也将成千上万倍地增长。”

把 Einstein@Home 搬到网格上运行并非一帆风顺。通常,志愿者下载并安装好程序后,程序就会不断地从服务器下载数据分析,并把结果返还给服务器。说白了,就是 Einstein@Home 的程序在志愿者的计算机上赖着不走了!

但是,网格有网格特色。网格任务不能无休止地运行下去,每一个 Einstein@OSG 进程都有一个时限约束。

“一旦时间到了,Einstein@Home 进程就必须结束。紧接着,Einstein@OSG 进程会把 Einstein@Home 程序的运行结果,保存到一个外部存储区”,安格尔解释道“当下一次启动 Einstein@OSG 时,它很可能会跑到一个异构机器上去运行。”

因此,Einstein@OSG 启动后,如果发现 Einstein@Home 程序需要从断点接续运行,它就会找出新环境有什么变化,比如机器架构、位置、软件版本、网络情况等,然后补充完整那些缺失的软件。在确认运行 Einstein@Home 所需的一切条件都满足后,它才启动 Einstein@Home 进程。前一次运行的结果将从远端的存储器载入,Einstein@Home 的程序就可以从存盘点接着运行了。

安格尔认为在网格中运行程序,碰到宕机的机率比桌面程序 (比如Einstein@Home) 高得多。这是因为网格是如此的复杂,而要完成的工作又是极其艰巨。

一般的 Einstein@Home 用户,数月也难得碰上一次计算出错。要真碰上了,顶多就是用任务管理器杀杀进程罢了。而 Einstein@OSG 运行在上万个 CPU 核心,每分钟都会遭遇一堆错误!但 Einstein@OSG 能自动地解决这些问题,保证系统和谐稳定。不然,用人工来处理这些问题,还不如用人工去分析那些数据算了...

安格尔说:“机器不知疲倦的特点,使得我们得以完成大量工作。它们不像我们 (人类),需要休息。”

横轴表示运行 Einstein@OSG 的集群数,纵轴表示所有集群中的 CPU 核心数量总和。每个方块区域表示从 2009 年 6 月到 2010 年 2 月间的一个星期。方块的颜色表示这周完成的计算任务量,从计算量最少的蓝色到最高的红色。从图中标示的日期可以看出计算任务量的增加,以及集群和 CPU 核心数目的增加。
图片由 Einstein@OSG 提供。

在安格尔展开 Einstein@OSG 工作之前,他曾是一个研究小组的成员。这个研究小组在托马斯•雷德克 (Thomas Radke) 的带领下,在普朗克研究院 (Max Plank Institute) 里从事引力方面的研究。在2006年,雷德克的队伍也为 Einstein@Home 创建了一个封装程序,以便 Einstein@Home 能运行在网格计算平台之上。这个平台被称为“德国网格力量 (German Grid Initiative)”,简称D-Grid。安格尔的其中一部分工作,是负责设计一个界面,以便用户有效地监控数以千计的 Einstein@Home 进程。

安格尔回忆道:“在我完成的工作中,包括了一个命令行工具。这个工具程序会用一个屏幕的篇幅,向用户简要说明所有在网格中运行的 Einstein@Home 的 进程情况。”现在,这个工具不但记录下进程的活动情况,还借此收集错误统计数据。最后,连同其它数据一起,错误统计数据将被列在一个内部网页上。

倒霉的是,雷德克研究组的封装程序不能直接用于 OSG 项目。

安格尔解释说:“OSG 迥异与德国网格。比如,那个德国网格完全依赖于 Globus。”

安格尔和他的团队测试了能让 Einstein@Home 在 OSG 上运行的各种方案,并找出最合适的方案是 Condor-G,一种 Condor 和 Globus 的混合体。由于实现 Condor-G 的工作量太大,拖延了 Einstein@Home 在 OSG 的上线时间。

另一方面,在实现一个 Condor-G 方案之前,Globus' GRAM 只花两周就搞定了。这就是安格尔团队选择实现 Globus 的原因。早搞定的好处就是及早发现问题。很快,他们发现了一个 GRAM 的严重问题。

安格尔说:“它的规模达不到要求。如果你试着在指定的资源上运行超过 100 个任务,那个资源就崩溃了。”

在改变了工作方式后,安格尔还是实现了 GRAM。他说:“这意味着我们可以在 OSG 上开跑了。”

2009 年 9 月,Condor-G 也投入运行了,并且迅速开上了快车道。“通常,每时每刻都有 5000 至 8000 个任务在我们的网格中运行,”安格尔说道:“在那之前(应该是指 2009 年 9 月),网格的负载量只有不到 500 个任务。

相关链接