Параллельный пролог и эпилог в Grid Engine
У нас есть кластер, который используется для выполнения заданий MPI для клиента. Ранее этот кластер использовал Torque в качестве планировщика, но мы переходим к Grid Engine 6.2u5 (для некоторых других функций). К сожалению, у нас возникают проблемы с копированием некоторых наших сценариев обслуживания в среде Grid Engine.
В Torque у нас есть скрипт prologue.parallel, который используется для автоматической проверки работоспособности узла. Если этот сценарий возвращает условие сбоя, Torque автоматически отключит узел и поставит задачу в очередь для использования другой группы узлов.
Однако в Grid Engine очередь "пролог" работает только на головном узле задания. Мы можем вручную запустить наш пролог-скрипт из сценария инициализации startmpi.sh для параллельной среды mpi; но я не могу понять, как обнаружить состояние сбоя и выполнить ту же процедуру "пометить офлайн и повторно".
Какие-либо предложения?
3 ответа
В случае, если это полезно для других, вот что мы в итоге сделали:
Проверки работоспособности в течение длительного периода времени, которые не будут мешать потенциально перекрывающимся заданиям (т. Е. Проверять наличие проблем с оборудованием в системе хранения), были загружены в периодические задания cron. (Частоты зависят.)
Проверки работоспособности в течение длительного периода времени, но которые могут мешать выполнению заданий (проверки производительности памяти), были выгружены в задание SGE, отправляемое каждому узлу в "эксклюзивном" режиме и передаваемое ночью cron. В случае неудачи узел отключается до того, как могут появиться другие задания.
Проверки условий среды непосредственно перед запуском задания (поиск случайных процессов, заполнение памяти и т. Д.) Были включены в сценарий, который запускался из сценария запуска pe startmpi.sh. Команды передаются на узлы с использованием pdsh, а выходные коды возвращаются через STDOUT. (Не идеально, но...) Если один или несколько узлов отказывают, скрипт отключает их и запускает
qmod -r $JOB_IDперезапустить работу. (Обратите внимание, что задание должно быть указано как "повторно запускаемое" либо в его сценарии, либо по умолчанию.) Это вынуждает перестраивать список узлов до фактического запуска сценария задания.
В настоящее время мы работаем над созданием отказоустойчивости в этом, но основы были подтверждены для работы. Спасибо @kamil-kisiel и каналу #gridengine на synirc.net за предложения.
Не могу сказать, что пробовал, но, по крайней мере, сценарий пролога, возвращающий значение, отличное от 0, 99 или 100, должен перевести очередь в состояние ошибки. Вы можете использовать подобную тактику в start_proc_args скрипт.
Если это не сработает, я не уверен, что то, о чем вы просите, можно достичь с помощью скриптов пролога. Возможно, вы могли бы использовать задание cron для проверки работоспособности (или использовать выбранную вами систему мониторинга) для выполнения проверок и отключения очередей хоста в случае их сбоя?
Почему бы не создать датчик нагрузки, который работает на каждом узле и в зависимости от того, что вы проверяете, устанавливает комплекс?
При таком подходе вы можете запускать задания, которые не зависят, например, от межсоединения, если ваша сеть межсоединения не работает.