Работа Кондора с использованием DAG с некоторыми заданиями, требующими запуска одного и того же хоста

Question

У меня есть вычислительная задача, которая разбита на несколько отдельных программ, с зависимостями. Я использую Condor 7 в качестве планировщика задач (с Unilla Vanilla, из-за ограничений на программы, которые мне недоступны, поэтому контрольные точки не используются), поэтому 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.

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

Answer 1

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

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

Answer 2

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

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

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

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

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

В настоящее время я делаю это с многочисленными работами. Отлично работает.

Answer 3

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

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

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

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

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

MultiCPUJob = True

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

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

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

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

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