Назад | Перейти на главную страницу

ПО для управления пакетными процессами в unix

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

У нас есть хороший набор пакетных операций, которые должны выполняться по разным графикам. Эти пакетные операции иногда имеют зависимости, так как журналы обрабатываются пакетным заданием A, а затем пакетные задания B и C могут выполняться с полученными данными. Использование ресурсов (балансировка заданий между нашими пакетными машинами), вероятно, не такая большая проблема, хотя было бы приятным бонусом.

Сегодня мы справимся с этим с помощью комбинации сценариев fcron и оболочки. Но, конечно, довольно сложно отслеживать, какие задания запланированы для выполнения на каких машинах. Также не всегда очевидно, когда какое-то задание зависло (или выполняется намного дольше, чем ожидалось) или даже просто не работает.

Для нас это не может быть уникальной проблемой. Фактически у нас было собственное решение в предыдущей компании, но никогда не было открытого исходного кода. Есть у кого-нибудь хорошее решение?

Есть множество решений, на которые вы можете захотеть взглянуть:

Крутящий момент - Это вариант исходного кода PBS (Portable Batch Scheduler). Они называют это диспетчером ресурсов, потому что технически он не заботится о планировании заданий, хотя включает в себя несколько планировщиков. Однако он позаботится об управлении и распределении ЦП, памяти, файлов и других расходных ресурсов вашего вычислительного узла. Если у вас есть что-то большее, чем очень простые потребности в планировании, вы, вероятно, захотите дополнить его Планировщик кластеров Maui. Я знаю об этом больше всего, потому что мы его используем. Это может быть немного грубо, потому что это в основном разработано сообществом, и большинство разработчиков - системные администраторы, а не инженеры-программисты. Есть коммерческий продукт, созданный на основе той же кодовой базы PBS, которая называется PBS Professional который кажется более зрелым и доступен за относительно небольшую плату.

Sun Grid Engine - Подобно системам на основе PBS, но написано Sun. Менеджер ресурсов и планировщик более интегрированы в эту систему, и она предлагает несколько различных режимов работы и распределения ресурсов. Несмотря на то, что это продукт Sun, он, по-видимому, хорошо работает в Linux и других операционных системах, а не только в Solaris.

Платформа LSF - Еще одно популярное коммерческое предложение в том же пространстве.

Кондор - Еще одна система планирования партии, более подходящая для высокой пропускной способности, тонны коротких заданий.

SLURM - Еще одно предложение с открытым исходным кодом. Он не такой зрелый, как продукты на основе PBS, но у него более приятная архитектура, основанная на плагинах, и его легко установить, если вы используете дистрибутив CAOS NSA Linux и диспетчер кластеров Perceus. Посмотри это Журнал Linux статья для примера того, как легко начать работу.

Какой из них вы выберете, во многом зависит от ваших предпочтений и соответствия вашим требованиям. Я бы сказал, что Torque и SGE имеют небольшое отклонение от многопользовательских кластеров в среде научных вычислений. Судя по тому, что я видел от Altair's PBS Professional, похоже, что он гораздо больше подходит для коммерческой среды и имеет лучший набор инструментов для разработки рабочих процессов для конкретных продуктов. То же самое и с LSF.

SLURM и Condor, вероятно, легче всего установить и запустить, и если ваши требования относительно скромны, они могут подойти лучше всего. Однако, если вам нужны более сложные политики планирования и многие пользователи отправляют задания в ваши системы, они могут отсутствовать в этом отношении без добавления внешнего планировщика.

Вы заглянули в Gearman?

Приложение на базе Gearman состоит из трех частей: клиента, исполнителя и сервера заданий. Клиент отвечает за создание задания для запуска и отправку его на сервер заданий. Сервер заданий найдет подходящего работника, который сможет выполнить задание, и перенаправит его дальше. Рабочий выполняет работу, запрошенную клиентом, и отправляет ответ клиенту через сервер заданий. Gearman предоставляет клиентские и рабочие API-интерфейсы, которые ваши приложения вызывают для взаимодействия с сервером заданий Gearman (также известным как gearmand), поэтому вам не нужно заниматься сетью или отображением заданий.

http://gearman.org/

Ура

Это может быть преувеличено для вашего случая, но проверяли ли вы пакетный планировщик Torque с открытым исходным кодом для кластеров? Обычно он используется в вычислительных сетях и больших кластерах: О крутящем моменте.

Возможно, я не понимаю сложности того, чего вам нужно достичь, но в случаях, над которыми я работаю, это делается следующим образом. Вы определяете место для запуска задания cron на основе конца источника данных. Сценарий, запускаемый с машины, имеющей данные для обработки, собирает то, что нужно обработать, и в конце этого сценария использует scp для отправки в следующую систему и ssh для выполнения сценария во второй системе. Вы можете выполнить удаленный скрипт по ssh с помощью:

ssh имя хоста "/ usr / local / path / to / script"

Вторая система выполняет свою работу с данными, а в конце этого скрипта выполняет дальнейшие scp данных и ssh в следующей системе и т. Д. Таким образом, возникает цепочка событий, и задействован только один cron. С одним заданием cron на исходной машине нет никаких сомнений в том, можно ли безопасно запустить второй cron в определенное время в зависимости от того, завершился ли первый cron. Вам просто нужно настроить несколько записей .ssh / authorized_keys, и вперед. О результатах любых сбоев сообщает начальный cron на первой машине, даже если они происходят ниже по течению.