请推荐一种替代微软HPC的方案。

6
我们的目标是在集群上实现一个分布式系统,该系统将进行资源密集型的基于图像的计算并具有重型存储I/O,具有以下特点:
  1. 有一个专用的管理计算机节点和多达100个计算节点。集群必须易于扩展。
  2. 它是围绕作业任务概念构建的。一个作业可能有1到100,000个任务。
  3. 由用户在管理节点上启动的作业会在计算节点上创建任务。
  4. 任务会即时创建其他任务。
  5. 一些任务可能运行几分钟,而其他任务可能需要几个小时。
  6. 任务按照依赖层次结构运行,该结构可以即时更新。
  7. 作业可以暂停并稍后恢复。
  8. 每个任务都需要特定的资源,包括CPU(核心)、内存和本地硬盘空间。当调度任务时,管理器应该知道这一点。
  9. 任务向管理器报告其进度和结果。
  10. 管理器知道任务是否存活或挂起。
我们发现Windows HPC Server 2008(HPCS)R2的概念非常接近我们所需的内容。然而,存在一些关键缺点:
  1. 随着任务数量的增加,任务创建变得越来越慢。提交超过数千个任务在时间上是难以承受的。
  2. 任务无法向管理器报告其进度,只有作业可以。
  3. 在任务运行期间没有与任务通信,这使得检查任务是否正在运行或可能需要重新启动变得不可能。
  4. HPCS只知道节点、CPU核心和内存作为资源单位。我们无法引入我们自己的资源单位(如可用磁盘空间、自定义硬件设备等)。
我的问题是:有人知道和/或有使用过分布式计算框架可以帮助我们吗?我们正在使用Windows。

注意:这绝对不是为了服务器故障而存在的。我正在寻找一个编程框架。 - Pavel Radzivilovsky
有什么原因Condor不适合吗?就我所知,它符合您提出的所有14个要求。 - Andrew Walker
很遗憾,您只能使用Windows作为平台。我相信SLURM可以满足您的大部分需求,并且一些与之集成的高级集群作业调度框架也可以。SLURM已经部署在越来越多的HPC和超级计算机集群上,包括两个拥有百万亿次运算能力的计算机系统。 - Joel Hoff
虽然您的要求大多数可以通过集群/作业调度框架来解决,但您所描述的一些作业/任务交互更适合于高级分布式计算框架,例如Hadoop。 您是否已经考虑过并拒绝了后者? - Joel Hoff
8个回答

6
我会查看Condor高吞吐量计算项目。它支持Windows(以及Linux和OSX)客户端和服务器,使用DAGman处理任务之间的复杂依赖关系,并可以暂停(甚至移动)任务。我有基于Condor的系统的经验,可以扩展到跨越大学校园数千台机器。

3

Platform LSF可以满足您的所有需求。它可以在Windows上运行。这是商业软件,可购买并获得支持。

是的。1.有一个专用的管理计算机节点和最多100个计算节点。集群必须易于扩展。

是的。2.它基于作业-任务概念构建。一个作业可能有1到100,000个任务。

是的。3.用户在管理节点上启动作业,结果在计算节点上创建任务。

是的。4.任务会即时创建其他任务。

是的。5.一些任务可能运行几分钟,而其他任务可能需要几个小时。

是的。6.任务按照依赖层次结构运行,可以即时更新。

是的。7.作业可以暂停并稍后恢复。

是的。8.每个任务需要特定的CPU(核心)、内存和本地硬盘空间资源。调度任务时,管理员应该注意这一点。

是的。9.任务将其进度和结果告知管理员。

是的。10.管理员知道任务是否存活或挂起。


0

你可以通过使用Data Synapse Grid Server来解决这种问题。

  1. 集群包括一个专用的管理计算机节点和多达100个计算节点。该集群必须易于扩展。是的,Broker可以轻松处理2000个引擎。
  2. 它基于作业-任务的概念构建。一个作业可能有1到100,000个任务。是的,我已经排队超过250,000个任务而没有问题。最终您会耗尽内存。
  3. 用户在管理节点上启动作业,这将导致在计算节点上创建任务。是的
  4. 任务可以即时创建其他任务。可以做到,但我不推荐这种模型。
  5. 一些任务可能运行数分钟,而另一些可能需要几个小时。是的
  6. 任务根据依赖层次结构运行,该结构可能会即时更新。是的,但我会将其管理在网格计算基础架构之外。
  7. 作业可以暂停并稍后恢复。是的
  8. 每个任务需要特定的资源,例如CPU(核心)、内存和本地磁盘空间。当调度任务时,管理器应意识到这一点。是的
  9. 任务向管理器报告其进度和结果。是的

` 10. 经理知道任务是处于运行状态还是挂起状态。是的


0

你看过Beowulf吗?有很多发行版可以选择,也有很多自定义选项。你应该能够找到满足你需求的东西...


我需要一个Windows工具,因为它必须运行更多或少现有的代码。 - Pavel Radzivilovsky
Beowulf不是真正的集群或分布式计算框架,因为它只存在于概念上,而不是作为标准化的软件集合、API等。 - Joel Hoff
同样的话也适用于Linux,这就是为什么我提到了有特定的Beowulf发行版(就像有Linux发行版一样)。我没有推荐一个具体的发行版,因为(1)我对它们不太熟悉,而且(2)选择正确的发行版应该取决于提问者的需求,而不是我的。 - Craig Trader

0
我会推荐使用Beowulf,因为它的表现更像是一台单机而不是多个工作站。

Beowulf不是真正的群集或分布式计算框架,因为它只存在于概念上,而不是作为标准化软件、API等的集合。 - Joel Hoff
@JoelHoff:你所说的“仅存在于概念中”是什么意思?人们在Beowulf集群上进行HPC,对吧? - J D

0

试试GridGain。这将使节点的运行时添加变得非常容易,并且您可以使用JMX接口监视/管理集群。


似乎GridGain非常关注Java,并对任务的构建方式施加了严格的限制。 - Pavel Radzivilovsky

0

如果您不介意将项目托管在云中,您可能想看看Windows Azure / Appfabric。据我所知,它允许您通过工作流分发作业,并且您可以动态添加更多的工作机器来处理随着负载增加而产生的作业。


-1

你有没有研究过SunGrid Engine?我很久以前用过它,但从未充分利用过它,这是我的理解。

  1. 有一个专用的管理计算机节点和最多100个计算节点。集群必须易于扩展。是的
  2. 它建立在作业-任务概念之上。一个作业可能有1到100,000个任务。不确定
  3. 由用户在管理节点上启动的作业会导致在计算节点上创建任务。是的
  4. 任务会即时创建其他任务。我想是吧?
  5. 一些任务可能运行几分钟,而另一些任务可能需要几个小时。是的
  6. 任务按照依赖层次结构运行,该结构可能会即时更新。不确定
  7. 作业可以暂停并稍后恢复。不确定
  8. 每个任务需要特定的资源,包括CPU(核心)、内存和本地硬盘空间。当调度任务时,管理器应该知道这一点。非常确定
  9. 任务向管理器报告其进度和结果。非常确定

10. 管理器知道任务是否存活或挂起。是的


SunGrid Engine能否运行Windows软件?它似乎可以使用Unix服务在Windows上运行。尽管这不在要求列表中,但Paval在评论中说这是必须的。 - Vitor Py
2
@Vitor,@Paul:由于@Pavel的要求必须在Windows上运行,因此Grid Engine被排除在外。是的,您可以使用Unix服务作为提交主机在Windows上使用GE(即您可以从Windows机器向集群提交作业),但执行主机(即执行作业的网格)必须是Linux / Unix / Solaris系统。除此之外,GE几乎是理想的! - High Performance Mark
@High:唉,我本来希望它能在Windows上运行。叹气。 - Paul Nathan

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接