Workflow Condor作业使用DAG，某些作业需要运行同一主机

我有一个计算任务，它被分割成几个独立的程序执行，具有依赖性。我使用Condor7作为任务调度器（使用Vanilla Universe，由于程序上的do限制超出了我的能力范围，因此不涉及检查点），因此DAG看起来是一个自然的解决方案。但是，有些程序需要在同一台主机上运行。我在秃鹰手册中找不到如何做到这一点的参考资料

示例DAG文件：

JOB  A  A.condor 
JOB  B  B.condor 
JOB  C  C.condor    
JOB  D  D.condor
PARENT A CHILD B C
PARENT B C CHILD D

我需要表示B和D需要在同一个计算机节点上运行，而不破坏B和C的并行执行

---

谢谢你的帮助

我不知道答案，但你应该在Condor用户邮件列表上问这个问题。支持Condor中DAG功能的人员会监视它并做出响应。有关订阅信息，请参阅。交通量相当少

在Condor中，如果不事先将两个作业锁定到特定主机（DAG或无DAG），则通常很难将两个作业保持在同一主机上。实际上，我想不出一个真正可行的方法来做到这一点，那就是让B在C之前启动，或者让C在B之前启动。如果你愿意强制B必须总是在C之前启动，你可以让作业B在开始运行时所做的部分工作变成修改作业C的ClassAd的部分，这样它就有一个“Machine==”字符串，其中是B降落的机器的名称。这还要求作业C在B运行之前被提交或根本不提交，B还必须将其作为启动工作的一部分进行发布

这很复杂

所以我有一个想法：你可以使用Condor的DynamicStartD/slots功能，折叠你的DAG来实现你想要的。在DAG中，当前有两个单独的节点B和C，可以将其折叠为一个节点B'，当它在机器上启动时，该节点B'将并行运行B和C。作为工作要求的一部分，您需要注意，一台机器上需要2个CPU。切换startd以使用动态插槽配置，以便机器公布其所有资源，而不仅仅是静态分配的插槽。现在，B和C总是在一台机器上同时运行。当队列中有几个多CPU作业和许多单CPU作业时，动态插槽会出现一些饥饿问题，但这至少是一个更容易解决的问题

另一个选项是使用特殊作业属性标记B'：

MultiCPUJob = True

并将其锁定在机器上的插槽1：

Requirements = Slot == 1 &&  ...your other requirements...

并且有一个静态插槽startd策略，该策略说，“如果MultiCPUJob=True的作业试图在我的插槽1上运行，则抢占该机器插槽2中的任何作业，因为我知道该作业将需要2个内核/CPU”

这是低效的，但是可以用6.8.x版本的Condor来完成。实际上，我在自己的静态分区农场中使用了这种类型的设置，因此，如果作业需要一台单独的机器进行基准测试，则无需重新配置机器

---

如果您有兴趣了解更多有关该抢占选项的信息，请告诉我，我可以向您介绍condor用户列表归档中的一些进一步配置阅读。

condor没有任何简单的解决方案，但至少有一个难题可以解决：

---

让B在execute节点上留下一些状态，可能是以文件的形式，比如说

MyJobRanHere=UniqueIdentifier”

。使用检测到这一点，并在机器类AD中公布它。让D使用

Requirements=MyJobRanHere==“UniqueIdentifier“

。作为D最终清理的一部分，或者可能是一个新节点E，它会删除状态。如果正在通过运行大量作业，可能需要偶尔清理剩余状态。

这里的解决方案是使用这样一个事实，即只要DAGMan尚未提交节点，即使DAGMan正在运行，也可以修改提交描述。假设一个简单的DAG为

a->B->C

。如果希望所有节点在同一台主机上运行，可以执行以下操作：

在节点a上定义POST脚本

post脚本搜索已完成节点A的集群ID。类似于

condor_history-l-attribute LastRemoteHost-m1$JOB_ID…

您需要清理输出等等，但您将只剩下运行节点A的主机

然后，post脚本搜索并修改相关作业提交文件，并在提交文件顶部插入作业要求。只要确保你逐步建立你的工作需求，这样他们就会接受这个新的需求

post脚本完成后，DAGMan将查看submit ready节点，在本例中，我们有一个节点：

B

。B的提交现在将使用您在步骤3中添加的新需求完成，这样它将在与

A

相同的执行主机上运行

---

我现在做很多工作。它非常有效。

如果我得到有意义的回答，邮件将在这里总结。列表中没有答案：-（也许这是不可行的。我会解决这个问题。是的，这听起来很难，对我来说是不可能的。这是一个很好的技巧。我采用了一种类似的简单的方法，最后：作业B和D都在同一个脚本中运行，但D等待C在共享驱动器上的已知位置创建一个文件。