Как можно организовать кластерный аналог CRON?

Question

[Sinot]

Всем привет!

Имеется машина в сети (Linux), на которой по расписанию (CRON) запускаются разнообразные скрипты/программы (дерагют REST, выгружают из БД отчеты, шлют почту и т.п.).

Задача организовать некий кластер из 2-3 машин, в котором на любой доступной машине будет запускаться эти скрипты. Чтобы можно было безболезненно выключить один из узлов на обслуживание (или при аварийном отключении), а планировщик самостоятельно переехал на другой доступный узел.

Собственно вопрос в том какими средствами это можно сделать?

Спасибо.

UDP
Подытожим.

• Готового простого решения если и есть, то никто о нем не в курсе. (Самое близкое - это Kubernetes Cron Jobs, но слишком много "лишнего")
  
• Можно реализовать кластеризацию в самих скриптах.
  
• Можно организовать через кластер контейнеров/виртуалок. (Опять же из "пушки по воробьям")
  

Для себя нашел компромиссный вариант:

1. Поднимаем кластер etcd или что угодно аналогичное. (Очень просто, особенно если отказаться от защитных мер)
   
2. Раскидываем скрипты по всем узлам.
   
3. В задаче CRON указываем условие запуска скрипта только на мастере etcd. (Проверка - примитивный bash с парой grep и сравнение мастера с текущим узлом)
   
4. Задачи CRON раскидываем на все узлы.
   

Подход не универсальный и вредный. Но в моем случае - достаточен. Скритпы и задачи CRON не обновляются часто (практически никогда), сеть изолирована.

Answer 1

[ky0]

Чтобы "можно было безболезненно выключить один из узлов на обслуживание (или при аварийном отключении), а планировщик самостоятельно переехал на другой доступный узел" - добавляют абстракцию между железом и ОС в виде виртуализации/контейнеров.

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

Answer 2

[paran0id]

Кластер Kubernetes и Kubernetes Cron Jobs. Хотя это сложно и для небольших задач может оказаться оверкиллом.

UPD: тут предлагают решение на corosync+pacemaker. Этим можно вдохновляться, только я бы отдельный cron под эту задачу завел, чтобы системные джобы не стопать на ожидающей ноде.

Comments

[Sinot]

Натыкался на это решение в своих поисках. Понадеялся, что есть вариант по проще.
Но спасибо за совет.

[Алексей Черемисин]

Развертывание кластера kubernets, corosync или чего-то подобного - залача зело сложная для простого рсспределенного cron....
Как бывший развертыватель corosync/pacemaker, не рекомендовал бы это решение.
Да оно и не поможет в предложеннлй задаче, уаы...

Answer 3

[shellnet]

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

Для этого можно использовать распределённые планировщики заданий, такие как:

Quartz Scheduler – Java-библиотека для управления расписаниями задач.
Celery – Python-фреймворк для асинхронных задач и очередей сообщений.
Airflow – платформа для оркестрации рабочих процессов, которая поддерживает CRON-подобную конфигурацию задач.

Answer 4

[Алексей Черемисин]

Ну, самый простой способ, чтобы все было хорошо и кудряво - поставить очередь сообщений!
Например rabbitmq или kafka.
Скрипты из cron переписываются таким образом, чтобы они публиковали сообщения в нужные топики.
А скрипты, которые выполняют работу, запускались бы по приходу сообщений в нужный топик.
Если делать на kafka, то скрипты в одной очереди из одной группы будут получать сообщения попеременно. Единственное - нужно задать нужное количество партиций в топике, согласно количеству воркеров (ну или серверов, где это будет крутиться).
На почитать - https://learn.conduktor.io/kafka/kafka-consumers-i...

И да, при это можно обойтись стандартными консольными командами.

Answer 5

[lioncub]

Попроще kubernetes, можно через docker swarm
https://github.com/crazy-max/swarm-cronjob