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 年里，一群志愿者通过基于 BOINC 的 Einstein@Home 程序，把他们机器的空闲时间，用来分析 LIGO 和 GEO-600 项目的数据。现在，一种称为“Einstein@OSG”的封装程序 (wrapper)，让 Einstein@Home 能运行在名为“开放科学网格”的网格计算平台上。

虽然 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 程序的运行结果，保存到一个外部存储区(an external storage location)”，安格尔解释道“当下一次启动 Einstein@OSG 时，它很可能会跑到一个异构机器上去运行。”

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

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

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

安格尔说：“机器不知疲倦的特点，使得我们得以完成大量工作(that mechanism that we were able to scale up)。它们不像我们（人类），需要休息。”

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

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

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

倒霉的是，雷德克研究组的封装程序(wrapper)不能直接用于 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 个任务。