Задание Condor, использующее DAG, при этом для некоторых заданий требуется запуск одного и того же хоста

У меня есть вычислительная задача, которая разделена на несколько отдельных программ с зависимостями. Я использую Condor 7 в качестве планировщика задач (с Vanilla Universe из-за ограничений на программы вне моей досягаемости, поэтому контрольные точки не используются), поэтому DAG выглядит естественным решением. Однако некоторые программы необходимо запускать на одном хосте. Я не смог найти ссылку, как это сделать, в мануалах Condor.

Пример файла 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.

Спасибо за вашу помощь.


person gurney alex    schedule 26.02.2010    source источник


Ответы (3)


У Condor нет простых решений, но есть как минимум один кладж, который должен работать:

Попросите B оставить какое-то состояние на исполняемом узле, возможно, в виде файла, который говорит что-то вроде MyJobRanHere=UniqueIdentifier". Для обнаружения это рекламирует его в машине ClassAd. Пусть D использует Requirements=MyJobRanHere=="UniqueIdentifier". Часть окончательной очистки D или, возможно, новый узел E, он удаляет состояние. Если вы выполняете большое количество заданий, вам, вероятно, придется время от времени очищать оставшееся состояние.

person Alan De Smet    schedule 03.09.2010
comment
Хороший трюк. Наконец, я пошел по аналогичному и немного более простому способу: задания B и D запускаются в одном сценарии, но D ждет, пока C создаст файл в известном месте на общем диске. - person gurney alex; 06.09.2010

Я не знаю ответа, но вы должны задать этот вопрос в списке рассылки пользователей Condor. Люди, которые поддерживают функциональность DAG в Condor, следят за ней и ответят. См. эту страницу для получения информации о подписке. Это довольно низкий трафик.

Как правило, довольно сложно поддерживать две задачи вместе на одном хосте в Condor без предварительной привязки их к определенному хосту, DAG или без DAG. На самом деле я не могу придумать действительно жизнеспособный способ сделать это, чтобы позволить B начинать раньше C или C начинать раньше B. при запуске изменяет Требования часть ClassAd задания C, чтобы в ней была строка «Machine ==», где указано имя машины, на которую приземлился B. Это также потребует, чтобы задание C было отложено или не было отправлено вообще до тех пор, пока B не будет запущено, B также должен будет освободить его как часть своей работы по запуску.

Это довольно сложно ...

Так что у меня просто возникла мысль: вы можете использовать динамические функции startd / slots Condor и свернуть DAG для достижения того, чего хотите. В вашем DAG, где у вас в настоящее время есть два отдельных узла, B и C, вы бы свернули его в один узел B ', который будет запускать как B, так и C параллельно, когда он запускается на машине. В рамках требований к работе вы отмечаете, что на машине требуется 2 ЦП. Переключите свои startd на использование динамической конфигурации слотов, чтобы машины объявляли все свои ресурсы, а не только статически выделенные слоты. Теперь у вас есть B и C, работающие одновременно на одной машине. Есть некоторые проблемы с динамическими слотами, когда у вас есть несколько многопроцессорных задач в очереди с большим количеством однопроцессорных задач, но это, по крайней мере, более легко решаемая проблема.

Другой вариант - пометить B 'специальным атрибутом задания:

MultiCPUJob = True

И нацелите его только на слот 1 на машинах:

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

И иметь статическую политику startd слота, которая гласит: «Если задание с MultiCPUJob = True пытается выполнить на мне слот 1, вытесняйте любое задание, которое оказывается в слоте 2 на этом компьютере, потому что я знаю, что для этого задания потребуется 2 ядра / ЦП. ".

Это неэффективно, но может быть выполнено с любой версией Condor после 6.8.x. На самом деле я использую этот тип настройки в своих собственных статически разделенных фермах, поэтому, если для выполнения задания требуется отдельная машина для тестирования, это может происходить без перенастройки машин.

Если вам интересно узнать больше об этой опции вытеснения, дайте мне знать, и я могу указать вам на дополнительную информацию о конфигурации в архивах списков пользователей condor.

person Ian C.    schedule 09.03.2010
comment
письмо отправлено, подведу итог здесь, если я получу содержательные ответы - person gurney alex; 24.03.2010
comment
В списке нет ответов :-( Может быть, это просто невозможно. Я буду работать над этой проблемой. - person gurney alex; 17.04.2010
comment
Да, для меня это звучит достаточно сложно, чтобы быть невозможным. - person Ian C.; 21.04.2010

Решение здесь состоит в том, чтобы использовать тот факт, что вы можете изменять описания отправки, даже когда DAGMan работает, пока DAGMan еще не отправил узел. Предположим, простой DAG A -> B -> C. Если вы хотите, чтобы все узлы работали на одном хосте, вы можете сделать следующее:

  1. Определите сценарий POST на узле A.

  2. Сценарий публикации ищет condor_history ClusterId завершенного узла A. Что-то вроде condor_history -l -attribute LastRemoteHost -m1 $JOB_ID ... Вам нужно будет очистить вывод, а что нет, но вы останетесь с узлом, на котором запущен узел A.

  3. Затем сценарий публикации ищет и изменяет файлы отправки зависимых заданий, вставляя в них требования задания в верхней части файла отправки. Просто убедитесь, что вы строите свои требования к должности постепенно, чтобы они уловили это новое требование, если оно присутствует.

  4. Когда сценарий публикации завершится, DAGMan будет искать готовые узлы, из которых в этом примере у нас есть один: B. Отправка B будет теперь выполняться с новым требованием, которое вы добавили на шаге 3, так что он будет работать на том же хосте выполнения, что и A.

Я делаю это в настоящее время с множеством работ. Работает отлично.

person Louis Marascio    schedule 21.12.2014