Я ищу хорошее решение с открытым исходным кодом для управления множеством пакетных заданий в кластере машин. Я просмотрел решения, указанные в этом Почта но это не совсем то, что я ищу, или, возможно, упомянутые проекты просто имеют очень плохую документацию.
У нас есть хороший набор пакетных операций, которые должны выполняться по разным графикам. Эти пакетные операции иногда имеют зависимости, так как журналы обрабатываются пакетным заданием 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), поэтому вам не нужно заниматься сетью или отображением заданий.
Ура
Это может быть преувеличено для вашего случая, но проверяли ли вы пакетный планировщик Torque с открытым исходным кодом для кластеров? Обычно он используется в вычислительных сетях и больших кластерах: О крутящем моменте.
Возможно, я не понимаю сложности того, чего вам нужно достичь, но в случаях, над которыми я работаю, это делается следующим образом. Вы определяете место для запуска задания cron на основе конца источника данных. Сценарий, запускаемый с машины, имеющей данные для обработки, собирает то, что нужно обработать, и в конце этого сценария использует scp для отправки в следующую систему и ssh для выполнения сценария во второй системе. Вы можете выполнить удаленный скрипт по ssh с помощью:
ssh имя хоста "/ usr / local / path / to / script"
Вторая система выполняет свою работу с данными, а в конце этого скрипта выполняет дальнейшие scp данных и ssh в следующей системе и т. Д. Таким образом, возникает цепочка событий, и задействован только один cron. С одним заданием cron на исходной машине нет никаких сомнений в том, можно ли безопасно запустить второй cron в определенное время в зависимости от того, завершился ли первый cron. Вам просто нужно настроить несколько записей .ssh / authorized_keys, и вперед. О результатах любых сбоев сообщает начальный cron на первой машине, даже если они происходят ниже по течению.