“案例分析：Einstein@OSG”的版本间差异
小 （修改Open Science Grid翻译，并添加Open Science Grid官方网站链接） |
|||
| 第9行： | 第9行： | ||
[[Image:einsteinathome.jpg|frame|right|Einstein@Home 的屏保截图。<br>图片由 Einstein@Home 项目方提供。]] | [[Image:einsteinathome.jpg|frame|right|Einstein@Home 的屏保截图。<br>图片由 Einstein@Home 项目方提供。]] | ||
| − | 在过去 5 年里，一群志愿者通过基于 [[BOINC]] 的 [[Einstein@Home]] 程序，把他们机器的空闲时间，用来分析 [[LIGO]] 和 [[GEO-600]] 项目的数据。现在，一种称为“Einstein@OSG”的封装程序 (wrapper)，让 Einstein@Home 能运行在名为“[[ | + | 在过去 5 年里，一群志愿者通过基于 [[BOINC]] 的 [[Einstein@Home]] 程序，把他们机器的空闲时间，用来分析 [[LIGO]] 和 [[GEO-600]] 项目的数据。现在，一种称为“Einstein@OSG”的封装程序 (wrapper)，让 Einstein@Home 能运行在名为“[[Open Science Grid]]”的网格计算平台上。 |
虽然 Einstein@OSG 只运行了 6 个月，但却已经是 Einstein@Home 的最大贡献者。它完成了大约 10% 的 Einstein@Home 计算量。 | 虽然 Einstein@OSG 只运行了 6 个月，但却已经是 Einstein@Home 的最大贡献者。它完成了大约 10% 的 Einstein@Home 计算量。 | ||
| 第47行： | 第47行： | ||
2009 年 9 月，Condor-G 也投入运行了，并且迅速开上了快车道。“通常，每时每刻都有 5000 至 8000 个任务在我们的网格中运行，”安格尔说道：“在那之前（应该是指 2009 年 9 月），网格的负载量只有不到 500 个任务。 | 2009 年 9 月，Condor-G 也投入运行了，并且迅速开上了快车道。“通常，每时每刻都有 5000 至 8000 个任务在我们的网格中运行，”安格尔说道：“在那之前（应该是指 2009 年 9 月），网格的负载量只有不到 500 个任务。 | ||
| + | |||
| + | == 相关链接 == | ||
| + | *[http://www.opensciencegrid.org/ Open Science Grid 官方网站] | ||
[[Category:Einstein@Home 相关文献]] | [[Category:Einstein@Home 相关文献]] | ||
2013年10月29日 (二) 13:05的最新版本
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 项目方提供。
在过去 5 年里，一群志愿者通过基于 BOINC 的 Einstein@Home 程序，把他们机器的空闲时间，用来分析 LIGO 和 GEO-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 提供。
在安格尔展开 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 个任务。