Когда Cron подводит / Комментарии / Хабр

VlK 30 ноя 2020 в 10:29

Какой знакомый путь :-) Хотя у нас в Badoo/Bumble в результате выработались собственные решения для управлениях графами из задач.

fu22ybear 30 ноя 2020 в 10:59

в Badoo неравнодушны к авторским решениям, один LSD чего стоит))
возможно, это потому что приходится разбираться с проблемами, для которых еще нет стабильных решений в opensource

VlK 30 ноя 2020 в 12:28

Ну, сейчас, наверное, мы бы тоже просто взяли Airflow, но в свое время схожих публичных инструментов еще не было.

LSD, кстати, это замена проблемного и слабоподдерживаемого Facebook Scribe, так что не совсем прям авторское решение. :-)

Tanner 30 ноя 2020 в 11:39

Говорят, systemd решает именно эту задачу.

kt97679 30 ноя 2020 в 12:08

Кластеризованный планировщик на systemd не построить.

Tanner 30 ноя 2020 в 13:47

Тут половина статьи посвящена недостаткам cron. Так вот, systemd, на мой взгляд, лучшая замена cron, решающая многие, если не все, вышеописанные недостатки.

А кластеризованный планировщик на systemd тоже, говорят, есть. Называется fleet.

fu22ybear 30 ноя 2020 в 14:14

говорят, fleet больше не поддерживается и рекомендуют использовать kubernetes

tmin10 30 ноя 2020 в 13:48

А кто-то пробовал с Airflow на Prefect перейти? Есть плюсы?

9660 3 дек 2020 в 11:00

Cron гарантирует запуск задачи строго один раз в указанный в расписании момент

Дальше читать не стал, извините.

-3

gecube 1 янв 2021 в 12:03

Но сервер с Cron'ом состоит из одного узла. Сервер может выйти из строя в момент выполнения задачи или, что вероятнее, его просто отключили для проведения каких-либо профилактических работ. А у Cron'а нет механизма резервирования состояния запущенных задач. После восстановления сервера задача, выполнение которой прервалось, не будет перезапущена. Остается только ждать следующего запуска по расписанию или запускать руками

Потому что крон не для этого. Либо писать долгоживущий сервис-демон для отчетов со всей этой логикой, либо, как более простое решение, — systemd timers. Очень странно, что никто про них не пишет.
Для распределённых отчетов же — да, нужны распределенные планировщики вроде того же airflow, но загвоздка в том, что он только-только подползает к такой реализации, которой реально не страшно пользоваться )))

Примерно" означает, что в момент предполагаемого запуска задача может быть запущена более одного раза или не запущена вообще. Такое ограничение обязывает делать задачи идемпотентными.

Ради справедливости — если использовать обычный cron даже на одном узле, то все эти требования есть. Просто они неявные и их несоблюдение не так очевидно больно, хотя всегда есть граничные случаи, когда они «стреляют»

Связка Airflow + KubernetesPodOperator + Kubernetes подходит нам по функциональности и надёжности планирования и запуска задач, позволяя спать ночами спокойно, зная, что в это время в меру дотошный и исполнительный Airflow проконтролирует выполнение всей необходимой работы на мощностях Kubernetes, который может быть запущен как и на соседней серверной стойке, так и в другом дата-центре или на стороне облачного провайдера.

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