我对使用startcluster/qsub/grid引擎来运行并行作业还很陌生，我还试着阅读了其他几篇关于这个问题的文章。我仍然不确定如何为我的特定需求构建一个可扩展的解决方案。在我继续进行同样的工作之前，我想再听取一些建议。
以下是我的要求：
我有一个巨大的tar文件[~40-50 gb，它可以上升到100gb]--->这里我能做的不多。我接受一个巨大的tar文件作为输入。
我必须解压它---->我运行tarxvf tarfilename.tar | parallel pbzip-d来解压它。
这种解压的输出是几十万个文件，大约500000个文件。
必须处理这些未压缩的文件。我有模块化的代码，可以在每一个单独的文件，并处理它和输出5个不同的文件。
tar文件-----并行解压缩--->解压缩文件-----并行处理--->每个处理的文件有5个输出文件
我现在有一个并行python脚本，它运行在一个16核、16gb内存上，接收这个未压缩文件列表并并行处理相同的文件。
问题是如何无缝伸缩。例如，如果我的代码已经运行了10个小时，并且我想再添加一个8核机器，我就不能用并行python来完成，因为我必须事先知道处理器的数量。
同时，当我向当前集群动态添加更多节点时，数据可访问性和读/写操作如何？
所以，我开始阅读星团和qsub的基础实验。虽然我看到我可以通过qsub提交多个作业，但如何从未压缩的输入文件夹中获取输入文件？
例如，我可以编写一个script.sh，在for循环中逐个选择文件名并将其提交给qsub命令吗？还有其他有效的解决方案吗？
比方说，如果有3台机器，每台机器有16个CPU，如果我向队列提交48个作业，qsub是否会在集群的不同CPU中自动启动它们，或者我是否必须使用诸如-np orte命令之类的并行环境参数来分别设置每个集群中的CPU数量。有必要使我的python脚本mpi可执行吗？
作为一个总结，我有几十万个文件作为输入，我想把它们提交到一个多核机器的作业队列中。如果我动态地添加更多的机器，作业应该会自动分配。
另一个主要的挑战是，我需要把50多万次行动的所有产出汇总到最后？有没有关于如何在输出被写出来时聚合并行作业的输出的建议？
我正在测试运行几个场景，但我想知道是否有人谁在类似的场景进行了实验。
使用hadoop插件有什么建议吗？http://star.mit.edu/cluster/docs/0.93.3/plugins/hadoop.html
提前谢谢你
2条答案
按热度按时间hxzsmxv21#
i/o和数据共享。如果i/o不足，可以将数据留在主节点上，并使用nfs在节点之间共享数据。如果您有很多i/o，我建议您使用s3存储桶。
分发：启动多个qsub的bash脚本是正确的做法。这取决于你要么在单个文件上调用它，要么同时在几个文件上调用它。
缩放：将集群上运行的并行作业视为不同的任务。由您在每个节点上运行一个或多个应用程序示例。例如：如果使用cr1.8XL节点，则有32个核。你可以使用32核启动1个应用示例，或者使用8核启动4个应用示例。请参阅开放网格引擎中每个节点的“插槽”配置(如果你更愿意运行一个大的应用程序示例，将多个节点的核心结合起来，我从来没有这样做过，所以我不能帮你。）然后，要添加一个节点，你可以使用starcluster的“addnode”命令。一旦节点启动，ogs也会自动在那里分发作业。您还可以使用starcluster loadbalancer自动添加/删除节点。
所以，这是我的建议。1将文件解压缩到s3。2发射星团3。使用bashscript，qsub为每几个文件分配一个作业（一个作业处理10个文件可能比为每个文件分配一个作业更有效）4。应用程序必须将i/o连接到s3。5当队列为空时，让脚本查看结果以确保所有作业都运行良好。当输出丢失时，可以重新安排作业。
我不知道你的汇总是怎么做的，所以我不知道。
我从没用过hadoop，所以我也没办法。
您不需要使python脚本mpi可执行。
如果您使用异构集群，那么您从一开始就知道每个节点上有多少内核可用。
如果您将一个具有32个核心的节点定义为具有4个插槽，那么您应该使作业每个最多使用8个核心。
ni65a41a2#
在研究了动态伸缩的各种可用选项之后，我决定使用队列机制将作业分配给多个工作者。
作业管理器-读取输入，构造作业，将作业添加到队列sqs队列是队列服务工作进程-侦听队列并处理输出。
输入/输出驱动器是nfs，可供所有服务器/客户机使用。
要动态扩展，请在/exports中添加nfs客户端信息并重新启动服务器。活动客户机在其各自的fstab中具有rw、hard和intr配置。通过在新客户机中启动n个工作进程，可以向进程添加更多的工作进程。
到目前为止，它是可靠的，可扩展性好。我能够在3台机器上启动近90名工人，在不到5小时内处理200000个文件。早些时候，由于我无法在多个节点上分发数据和运行worker，因此需要将近24小时。