Мы используем cron столько, сколько я себя помню, чтобы справляться со всеми нашими потребностями в планировании заданий. Все, от клонов / моментальных снимков хранилища до отчетов по базам данных, ежедневных системных отчетов и проверок мониторинга, планируется через cron на нескольких сотнях серверов.
Недостатки довольно очевидны: сложно управлять заданиями, нелегко создавать зависимости (особенно между разными серверами), и, конечно, неизбежно, что кто-то «временно» пропускает задание, но позже забывает удалить комментарий.
Мы пробовали коммерческое предложение, но в конце концов оно было сочтено слишком дорогим, поскольку это шаг вперед по сравнению с cron.
Я вижу другие варианты, такие как SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor, которые, по-видимому, ориентированы на более крупные, более однородные кластерные среды с заданиями, которые будут выполняться на любом количестве подобных узлов: сеточные вычисления и тому подобное. Наша среда довольно смешанная (разные Linux, AIX и FreeBSD), и нам нужно создать зависимости для разных типов систем (например, задание в Linux может потребовать определения, должно ли выполняться задание в AIX).
Есть ли у кого-нибудь опыт перехода с cron на предложение с более централизованным управлением? Какие-нибудь советы по выбору программного обеспечения или что лучше: с открытым исходным кодом или коммерческим?
Condor, OGE и Torque могут помочь вам в этом, но только Condor имеет встроенное управление зависимостями с ним. Инструмент DAGMan. DAGMan позволяет настроить ориентированный ациклический граф который описывает ваш рабочий процесс, а менеджер заботится о перемещении по заданиям в вашем рабочем процессе и оценивает результаты «годен / не годен» на каждом этапе потока. Condor относительно не зависит от платформы, что означает, что DAGMan тоже, и вы, безусловно, можете запустить один дочерний шаг в AIX, когда родительский этап работает в Linux или Windows. DAGMan не заботится о том, где выполняются задания, просто коды выхода проходят или не проходят.
Какие-нибудь советы по выбору программного обеспечения или что лучше: с открытым исходным кодом или коммерческим?
С некоторыми оговорками, я думаю, что на бесплатные сообщества в этой области стоит обратить внимание.
НГЕ сейчас в странном пространстве. Вариант GE, созданный Oracle, больше не является бесплатным, и Oracle больше не вносит код, который он записывает обратно в GE SCC, но существует несколько ответвлений кода, которые пытаются использовать как бесплатные проекты с открытым исходным кодом. Univa, в частности, возглавила, нанимая бывших разработчиков Sun GE для продолжения работы над свободно доступным вариантом GE с открытым исходным кодом. У Grid Engine есть две вещи: его легко настроить, он может обрабатывать короткие (менее 2 минут) задания, не накладывая на них много накладных расходов на планирование, которые снижают пропускную способность. Большой недостаток - не очень хорошая поддержка Windows. Некоторые из нас много лет назад приложили некоторые усилия для того, чтобы портировать его для работы на Cygwin, но это точно не так хорошо, как нативный.
Теперь Condor - моя любимая из трех упомянутых вами технологий. Вокруг Condor существует сильное сообщество, а программное обеспечение очень зрелое (ему уже более 20 лет). Встроенная поддержка ОС Windows и POSIX означает, что он отлично работает повсюду. Вышеупомянутый DAGMan - лишь одна из многих замечательных вещей, которые поставляются с Condor. Это может быть немного сложно настроить, но как только он будет запущен и заработает, он станет прочным. У него невероятно гибкий язык для выполнения задания <-> машинного сопоставления и построения правил использования ваших ресурсов. Он также поддерживает динамическое выделение ресурсов на машинах, позволяя заданиям выбирать, сколько машинных ресурсов им нужно, а затем повторно объявлять разницу как доступную. Он поддерживает глобальные счетчики ресурсов, поэтому вы можете ограничивать такие вещи, как лицензии на программное обеспечение. И, конечно же, у него есть DAGMan, невероятно мощный инструмент для управления рабочим процессом. Обратной стороной Condor является то, что накладные расходы на планирование краткосрочных заданий могут быть обременительными. В идеале вам нужны задания, которые выполняются дольше 2 минут, иначе планирование станет важной частью времени выполнения задания в системе.
Крутящий момент чуть больше нишевый. Я меньше знаю об этом, боюсь. Он больше похож на Grid Engine, чем на Condor. Есть платные дополнения, о которых упоминал @warren, которые могут расширить возможности базового бесплатного Torque.
Если вы хотите опробовать три технологии и посмотреть, как они работают с вашими конкретными рабочими нагрузками, CycleCloud может запускать безопасные виртуализированные пулы, предварительно настроенные с помощью Condor, GridEngine или Torque - так что вам не нужно тратить время на выяснение этих вещей. Было бы несколько долларов, чтобы развернуть небольшие пулы каждой технологии и опробовать их с репрезентативными рабочими нагрузками. (Отказ от ответственности: я работаю в Cycle Computing, мы делаем CycleCloud)
Хронос выглядит очень многообещающе.
Chronos - это замена Airbnb для cron. Это распределенный и отказоустойчивый планировщик, работающий поверх Apache Mesos. Вы можете использовать его для организации заданий. Он поддерживает настраиваемые исполнители Mesos, а также исполнитель команд по умолчанию. Таким образом, по умолчанию Chronos выполняет сценарии sh (в большинстве систем bash). Chronos можно использовать для взаимодействия с такими системами, как Hadoop (включая EMR), даже если на подчиненных устройствах Mesos, на которых происходит выполнение, не установлен Hadoop. Включенные сценарии оболочки позволяют передавать файлы и выполнять их на удаленном компьютере в фоновом режиме и использовать асинхронные обратные вызовы для уведомления Chronos о завершении или сбоях задания.
Я также добился большого личного успеха, используя Jenkins в качестве замены cron. Он прекрасно справляется с выполнением заданий на удаленных серверах. Вот запись об этом: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/
Последние 4,5 года я работал с платформой серверной автоматизации HP (в девичестве Opsware) и остальной частью пакета Business Technology Optimization (сетевая автоматизация, оркестровка операций и т. Д.).
Для достаточно большой среды управление заданиями через SA является очень жизнеспособным (и желательным) инструментом. В сочетании с ОО заданиями можно управлять с помощью управления изменениями, продажи билетов и т. Д.
Вот что не очень весело: это дорого (очень дорого). Вы можете проверить некоторые предложения в аналогичном вопросе, который я задал некоторое время назад: Инструменты управления и аудита серверов FLOSS.
Я бы также сказал, что Torque / Maui / Moab (от Адаптивные вычисления) являются очень круто: не уверен в ценах, но это тоже очень гибкие инструменты.
НОТА Совершенно другой взгляд на проблему!
cron является старый и неуклюжий в определенном смысле.
Если вы действительно ищете новые способы составления расписания, я бы попробовал что-нибудь на основе событий с промежуточным программным обеспечением для обмена сообщениями. Подумайте о RabbitMQ с клиентами на каждом сервере.
Зависимости между хостами могут быть решены с помощью «очередей уведомлений».
События, основанные на «реальном» времени, немного сложнее, на самом деле cron для этого (и неплохо справляется, по крайней мере, в небольших средах). Сложно осознать эту идею, так это предотвратить заеды. Как в: каждую ночь в 01:00 делайте снимок. В этот самый момент вы можете увидеть скачки нагрузки или множество неудачных попыток входа в систему через всю вашу инфраструктуру. Если у вас есть подход, основанный на очереди, вы получите хоть какое-то отклонение бесплатно (хотя это не гарантируется - если это не реализует какая-то логика).
Надо сказать, что без заданий, основанных на реальном времени, нельзя полагаться на такие вещи, как: да, мои резервные копии начнутся в 02:00, а если они все еще будут выполняться в 04:00, что-то не так. Что проще сделать, так это убедиться, что никакие 2 задания, которые мешают, не выполняются одновременно. Просто создайте блокирующий агент, который будет использовать только одно задание за раз.
Управляющая часть могла бы быть приятным веб-интерфейсом, в котором задания можно было бы отправлять либо по запросу, либо - теперь он возвращается в «cron» или в вашу любимую его реализацию, планировщик кварца Java имеет детализацию в секундах AFAIK - для временная часть, просто используйте старый добрый cron :)
Пожалуйста, не опускайте меня за то, что я ОТ - это довольно грубая концепция, но поскольку вопрос не исключает денег, можно было бы с тем же успехом потратить деньги, чтобы получить решение для точных внутренних требований, создав что-то, а не тратя деньги, купив что-то там, где продавец считает, что это удовлетворяет некоторым требованиям :)
Я использовал эспрессо (кибермацию) от CA. Не уверен, как они это называют сейчас. Я также использовал UC4. Они оба работают, стоят больших денег (насколько я понимаю) и могут быть медвежьими в обслуживании, но они делают то, что написано на банке. / Edit - пропустил, что вы сказали, что коммерческие приложения слишком дороги. Я определенно могу согласиться, но для некоторых компаний это того стоит, особенно когда речь идет о бизнес-приложениях, которые приносят прибыль.
Я работал с Планировщик заданий с открытым исходным кодом как вариант для замены центрального crontab на 2000+ строк в производственной среде. С cron все стало настолько сложно, что мы не могли определить, какие были окна простоя или как бороться с межсерверными зависимостями. Этот продукт помог, но его было немного сложно настроить.