[EAH]案例分析：Einstein@OSG

碧城仙

来源：http://www.distributedcomputing.info/news.html
原载：International Science Grid This Week http://www.isgtw.org/?pid=1002386
标题：Case Study: Einstein@OSG - 志愿者计算案例分析
作者：Miriam Boon, iSGTW
日期：2010年3月17日
概要：一种新的应用 Einstein@OSG 将志愿者计算引入 Open Science Grid，目前 Einstein@OSG 已运行六个月，完成了 Einstein@Home 项目 10% 的工作量。

有愿意帮助翻译的，请直接回帖（可以先占座，再翻译或编辑）

refla

在过去 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 能很好地解决这些问题，保证系统稳定和谐。不然，用人工来处理这些问题，还不如人工分析那些数据算了。。。。

“这是唯一的！因为我们拥有使网格不断扩展的机制”安格尔说道，“有台机器不知疲倦地侦测并处理异常情况。（它）不像我，晚上需要与佳人共度良宵。”



未完，待续

Youth

感谢翻译，有几处小建议~~

这里wrapper的意思就是把原来的应用程序包装（封装？）一下，适应某个具体网格比如OSG的接口。

With Einstein@OSG running on up to 10,000 cores, however, there are errors every couple of minutes.

确切点说，应该是运行在上万个cpu核心上，而不是管理着上万个cpu核心，einstein@osg只是网格上的一个应用，管理软件是另外的软件。

Fixing these manually simply isn’t practical, so Einstein@OSG eventually automated the process.

这句的意思似乎没译出来，大概就是说einstein@osg将错误处理的过程自动化了。

“It was only because of that mechanism that we were able to scale up,” Engel said. “A computer never gets tired looking for errors and fixing them, unlike me, who likes to sleep at night and spend time with his family.”

这段的意思也没说太清楚，并不是说有一台具体的机器在那里专门负责查错什么的，而是泛指的机器和人做比较，比如计算机不会像人那样感到累。

refla

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

安格尔回忆道：“在我完成的工作中，包括了一个命令行工具。在（报告的）最后一页，这个工具会向用户简要说明(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 个任务。”

refla

回复 3# Youth

好的，感谢 Youth。

1
wrapper 我也不知道该怎么翻译好。根据后文的解释，“@OSG 是一个营造运行 @Home 环境的程序”，我觉得 @OSG 是在照顾 @Home，所以就把它叫做“程序保姆”了。不过，我在后文掉了个，改为“保姆程序”了。

2
With Einstein@OSG running on up to 10,000 cores, however, there are errors every couple of minutes.

你说的对，应该译作“运行在上万个cpu核心上”。
我当时看到 @OSG 要自动处理错误情况，就误以为它是个管理程序，却忘了它是个 wrapper。。。。

3
Fixing these manually simply isn’t practical, so Einstein@OSG eventually automated the process.

这句话，我翻译成这样：
但 Einstein@OSG 能很好地解决这些问题，保证系统稳定和谐。不然，用人工来处理这些问题，还不如人工分析那些数据算了。。。。

就是把“so Einstein@OSG eventually automated the process”提前翻了，因为我想扩展一下“Fixing these manually simply isn’t practical”这句话

考虑到 Einstein@OSG 是个程序，而且上下文也是与手工操作对比，所以，我就不再强调它能自动工作了，而是换了种说法。

4
“It was only because of that mechanism that we were able to scale up,” Engel said. “A computer never gets tired looking for errors and fixing them, unlike me, who likes to sleep at night and spend time with his family.”

好的，我明白了。这段话翻译成下面这样你看如何？

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

refla

回复 3# Youth

后半部我也放上来了，帮看看

Youth

回复 5# refla


    1. 8好意思，我前面没说清楚，直接叫封装程序或包装程序之类的是不是比保姆程序更像个技术词汇？

Youth

回复 4# refla


    翻译得挺好 只有一句“在（报告的）最后一页”，这个我好像没看出这个意思来？

refla

回复 7# Youth

那就叫封装程序吧。“封装”这个词，在面向对象里很常见，而且概念上也相近，都是屏蔽一些细节啊、包揽一些事务什么的

refla

回复 8# Youth

对啊，我当时翻这句也觉得挺别扭的。

原文在这：
a command line tool that would summarize all activities on the Grid on a single terminal page,” Engel said.

我猜它的意思是想说，这个工具（程序）会输出一堆信息，简报网格里的活动程序只是其中部分内容，并且是放在最后一页输出。就是黑体字那段话。

Youth

哦，原来这里有个terminal，才看到，不过应该是指终端的意思吧

refla

回复 11# Youth

确实应该翻译为“终端”才对！

terminal 这词比较少见，尤其是在口语中。

refla

回复 11# Youth

确实应该翻译为“终端”才对！

terminal 这词比较少见，尤其是在口语中。

我现在翻译为“一个屏幕的篇幅(a single terminal page)”

refla

前言：修正 Youth 前面提到的问题，并把两部分连接起来，成为一篇完整的文章。


在过去 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 工作之前，他曾是一个研究小组的成员。这个研究小组在托马斯•雷德克(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 个任务。

refla

回复  refla
    翻译得挺好  ...
Youth 发表于 2010-3-20 17:01