Идеальный планировщик задач с открытым исходным кодом

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

Я могу планировать сценарии в нашей системе Unix с помощью cron и в наших системах Windows с помощью планировщика задач, но ни один из них не является устойчивым — если машина, на которой выполняются эти задачи cron, выйдет из строя, мои задачи не будут выполнены.

Вышедшая из строя машина может вернуться в сеть достаточно быстро – и если бы я запустил расширенный cron, такой как «anacron», он мог бы наверстать упущенное, – но задача, запланированная для запуска каждый час, вероятно, не будет выполнена вовремя, и догоняющее действие может усугубить ситуацию. Что мне нужно, так это какое-то аварийное переключение, чтобы в случае сбоя одной машины другая своевременно выполняла свои задачи.

Мы реализовали такую ​​систему для клиента на паре компьютеров Linux, используя Heartbeat и блочное устройство аварийного восстановления (DRBD). Этот клиент запускает два набора служб на этих двух машинах, по одному на каждой машине в нормальных условиях.

Если одна машина выйдет из строя, ее службы перейдут на другую. Мы используем Heartbeat, чтобы каждая машина могла контролировать другую, чтобы в случае сбоя она могла взять на себя свои услуги. Частью этого переключения служб является простая кластерная файловая система, реализованная с использованием DRBD.

Мы используем Heartbeat, чтобы каждая машина могла контролировать другую, чтобы в случае сбоя она могла взять на себя свои услуги. Частью этого переключения служб является простая кластерная файловая система, реализованная с использованием DRBD.

При нормальной работе каждая машина считывает и записывает свою собственную копию файлов каждой службы, а DRBD копирует эти изменения на другую машину, так что в случае аварийного переключения службы, перешедшие при сбое, будут иметь доступ к актуальным копиям своих файлов. (обычно каждая машина видит только файлы своих служб и не видит файлы на другой машине).

Эта комбинация Heartbeat и DRBD хорошо работает для таких сервисов, как веб-обслуживание (основное приложение), но также возникла необходимость в обеспечении переключения различных регулярных задач с одного компьютера на другой. Мы реализовали это, поместив один и тот же файл crontab на каждую машину, чтобы каждый знал, какие задачи ему придется выполнить в случае аварийного переключения, и имел их сценарии в своей файловой системе.

Затем мы предваряем каждую задачу сценарием, который проверяет, присутствует ли сервисная задача: поскольку каждая машина обычно видит только файлы для своих собственных служб, файлы задач другой машины будут видны только в том случае, если происходит аварийное переключение. Эта довольно сложная схема позволяет нам реализовать устойчивый cron, но здесь есть и свои проблемы.

Во-первых, система сложна, а во-вторых, она не защищена от человека: когда требуется новая задача, нужно не забыть добавить ее на обе машины. В-третьих, существуют всевозможные граничные условия, относящиеся к тому, что происходит с выполняемыми задачами в случае сбоя или, что еще хуже, когда происходит сбой и службы «отказываются» в середине запланированного задания.

Наконец, он не масштабируем — он может отказывать в обслуживании с одного узла на другой, но для большой фермы серверов, состоящей из идентичных машин с потенциальными множественными сбоями, это не сработает.

В этом последнем пункте вы видите реальную проблему решения на основе cron. Cron и планировщик задач были разработаны только для выполнения обычных задач по обслуживанию на одной машине, но когда вы предоставляете услугу на нескольких машинах, каждая отдельная машина представляет собой единую точку отказа.
Кроме того, cron не очень хорош для ведения записей — как можно легко определить, успешно ли выполнялась задача в прошлый раз или в предыдущий? Cron может отправлять электронные письма людям, когда возникает проблема, но когда они вам нужны больше всего, вы можете быть уверены, что они окажутся в необслуживаемых учетных записях.

Итак, если cron и планировщик задач не идеальны, что именно нам нужно от решения для планирования задач? Нам нужно централизованное, распределенное решение с единым интерфейсом управления, в котором мы можем видеть все регулярные задачи, которые необходимо выполнять, и оно должно быть распределено, чтобы мы никогда не полагались полностью на работу какой-либо одной машины. Например, если задачу необходимо запускать каждый час, мы хотим настроить ее через единый интерфейс управления, но сказать, что она может запускаться с любой из машин.

Очевидно, нам также понадобится доступ к этому единому интерфейсу управления с более чем одной машины. Нам также хотелось бы, чтобы интерфейс управления предоставлял историю заданий, чтобы мы знали, не удалось ли выполнить какую-либо задачу и если да, то почему. Наконец, он должен быть безопасным и надежным и работать с нашими серверами Unix и Windows. Хотите верьте, хотите нет, но существует немало решений с открытым исходным кодом, соответствующих этому требованию: не все из них удовлетворяют нашим требованиям, но многие из них постоянно совершенствуются.

Почему бы не передать управление задачами на аутсорсинг?

Моя компания передала свою систему электронной почты Google Apps, большую часть поиска DNS — OpenDNS, а телефонную систему — компании VoIP, так почему бы нам не передать на аутсорсинг и управление обычными задачами?

Есть несколько компаний, которые предлагают «веб-сервисы cron», которые работают с внешних серверов, которые получают доступ к страницам на ваших собственных веб-серверах в необходимое время. Будем надеяться, что они решат проблему устойчивости своих собственных систем и будут иметь собственные интерфейсы централизованного управления.

Такие услуги идеально подходят для людей, которые используют веб-хостинг и поэтому не имеют доступа к таким средствам, как cron. Мы можем повысить устойчивость службы на нашей стороне, если страницы, к которым они обращаются, обслуживаются через балансировщики нагрузки и, следовательно, распределяются по всей нашей ферме серверов.

Мы рассматривали возможность использования одной из этих служб, но не сделали этого по двум причинам. Во-первых, выполнение некоторых задач, которые нам нужно выполнить, может занять довольно много времени, и может случиться так, что веб-соединение не может оставаться открытым достаточно долго, поэтому мы не будем уверены, что удаленная служба действительно зарегистрировалась. успех или неудача правильно.

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

Ortro: веб-замена cron

Отказавшись от внешнего веб-решения, мы задумались, можно ли использовать систему с открытым исходным кодом. Мы столкнулись с Ortro, веб-системой, в которой задачи настраиваются через веб-интерфейс, а вся конфигурация хранится в базе данных.

Это решает ряд проблем, поскольку мы можем хранить эту базу данных конфигурации на нашем реплицируемом сервере базы данных и запускать ее веб-интерфейс с нескольких компьютеров.

Для реализации базового процесса планирования Ortro использует cron, чтобы запустить себя. Поскольку для работы он использует cron, работающий на одной машине, он должен иметь некоторые средства для запуска задач на других машинах, что он может выполнить либо путем доступа к веб-страницам, либо путем запуска удаленных оболочек через SSH.
Существуют также удобные средства для настройки простых рабочих процессов, например, «запустите этот процесс, и если он работает, запустите этот процесс или запустите тот».

В Ортро все работает хорошо. Мы настроили SSH на наших внутренних балансировщиках нагрузки и использовали его для планирования работы в кластере и «пропуска» любой вышедшей из строя машины. Однако были две вещи, которые нам не понравились. Мы не могли легко получить историю того, что было выполнено заданием — например, если оно выполнялось ночью, произошло ли оно сбой в час ночи, но нормально ли оно работало в 2 часа ночи, в 3 часа ночи и так далее?

Однако самая большая проблема заключалась в том, чтобы избежать единой точки отказа: Ortro полагается на то, что один главный процесс выполняется через cron на одной машине, и не было простого способа поддерживать работу двух главных машин в режиме активный + резервный. .

Планировщики, написанные на Java

Когда мы нашли Ortro, мы также столкнулись с большой коллекцией систем на основе Java, которые изначально отвергли, поскольку они были написаны на Java. Мы не имеем ничего против языка как такового: скорее, Java — это то, что используют другие люди, но не мы. Справедливости ради надо сказать, что мы используем редактор Eclipse, написанный на Java, но нечасто использовали его на наших серверах.

Мы также используем пакет администратора сервера Dell PowerEdge, который на различных этапах использует Java, но мы не используем его для предоставления услуг. Однако, как только мы решили, что Ortro нам не подходит, мы решили отбросить наши предубеждения и попробовать Java.

Существует множество распределенных отказоустойчивых планировщиков, написанных на Java, некоторые из которых имеют действительно открытый исходный код, а также несколько «демонстрационных» версий коммерческих продуктов. Есть также несколько продуктов, предназначенных для крупных сетевых систем, которые мы не рассматривали. Мы опробовали две системы на базе Java: простую под названием OddJob и более сложную под названием Job Scheduler.

Одджоб легко настроить: загрузите ZIP-файл, и все готово. В отличие от Ortro, OddJob опирается на непрерывно работающий процесс, что соответствует многим нашим критериям: мы можем контролировать и отслеживать задания в нашей сети через графический интерфейс; мы могли бы планировать задания в зависимости от того, что происходит с другими заданиями; и вроде все работало.

Система по-прежнему должна иметь главный процесс со своей собственной базой данных, которая в настоящее время не является обычной базой данных SQL. Таким образом, хотя продукт нам понравился, он не совсем соответствовал всем требованиям.

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

Он поставляется с простым в использовании установщиком, он будет работать с любой достаточно взрослой базой данных SQL – в нашем случае MySQL, но известно, что он также работает с PostgreSQL и SQL Server – и его можно настроить с помощью активного узла планировщика и резервный узел.

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

Причина, по которой мы сдались, на самом деле была не по вине программного обеспечения, а по нашей вине. Мы используем cron, а другие люди используют аналогичное программное обеспечение для Windows, потому что это очень просто: нам не нужно каждый день настраивать запланированные задания, но когда мы это делаем, мы хотим, чтобы это было легко.

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

Ни одна из этих проблем не была непреодолимой, но я думаю, что в конечном итоге наши «глаза были больше, чем наши животы», и нам на самом деле не нужны были все его возможности вместе с теми функциями, которые нам были нужны.

Что дальше: GNUbatch

Пока дела шли плохо: мы отвергали все пакеты, которые рассматривали. Нам не нравились некоторые решения, потому что им не хватало устойчивости, а более устойчивое решение нам не нравилось, потому что оно было слишком сложным.

Затем мы обнаружили пакет под названием GNUbatch. Это зрелый продукт в области планирования заданий, но относительно новый для сообщества разработчиков ПО с открытым исходным кодом. Раньше это был коммерческий пакет под названием Xi-Batch, который активно разрабатывался с 1990 года, а в 2009 году стал открытым исходным кодом.

Прежде чем вы начнете торопиться за своим менеджером пакетов, имейте в виду, что вы, вероятно, не найдете GNUbatch в репозиториях, поэтому вам придется скачать исходный код и скомпилировать его самостоятельно.

GNUbatch — зрелый продукт в области планирования заданий, но относительно новый для сообщества разработчиков программного обеспечения с открытым исходным кодом.

Также имейте в виду, что это старое доброе программное обеспечение: GNUbatch не использует реляционную базу данных для хранения своей информации; он не написан на Java; и если вы хотите, вы можете управлять всем этим из командной строки, хотя у него также есть графический интерфейс, Windows и веб-интерфейсы.

Так что же может GNUbatch? Он позволяет вам настраивать задания для запуска на одной машине или на нескольких машинах, причем каждое задание может иметь время начала и повторяться с различными интервалами — немного подумав, вы также можете ограничить его рабочими днями, избегая выходных и праздники и позволить ему понять более сложные варианты планирования, такие как «последний день рабочего месяца».

Задания можно объединять в цепочки с дополнительными путями, основанными на ошибках, и эти цепочки можно создавать для охвата нескольких компьютеров. Например, у вас может быть задача создания отчетов, которая выполняется на группе компьютеров, а затем запускает одно задание на другом компьютере для агрегирования результатов в отчет.

Все результаты заданий записываются в виде текстовых файлов, и этими журналами можно манипулировать позже. В целом, мы обнаружили, что GNUbatch делает именно то, что мы хотели, и, хотя кривая обучения у него действительно была крутая, это смягчалось тем фактом, что у него есть значительная коллекция читаемых руководств.

Итак, в конце концов мы нашли решение для поиска пакета для планирования работы, после борьбы с классической проблемой открытого исходного кода, когда слишком много выбора. Если у вас схожая с нашей потребность, посмотрите Job Scheduler и GNUbatch.