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