В настоящее время мы находимся в процессе создания кластер высокой доступности для NGINX (на Centos 7) под управлением PHP. Большая часть конфигурации отображена и должен хорошо работать в кластерной среде.
К сожалению, единственное, что мы не можем понять, чтобы хорошо играть с кластеризацией, - это cron вакансии (задания cron будут выполнять код PHP). Насколько мне известно, задания cron выполняются на каждом хосте индивидуально. Это означает, что мы либо:
Видя, как решение 3 поможет нам поддерживать среду высокой доступности, то есть предпочтительный метод. К сожалению, мы не очень хорошо знакомы с некоторыми из этих решений, поэтому мне нужны ваши знания, которые помогут нам найти подходящее решение для наших нужд. Мы не очень хорошо знакомы с машинами Linux (вся среда - это Windows, за исключением серверов NGINX) и мало знаем о работе с этими машинами (хотя до сих пор мы могли это понять).
Любая помощь по этому поводу приветствуется.
Я понимаю, что этот вопрос был задан перед, хотя он кажется довольно устаревшим (2011 г.), и с тех пор было создано много новых решений.
crond в RHEL / CentOS 7 включена поддержка кластеризации. Это на самом деле cronie, вилка маститого vixie-cron. Вот подробности со страницы руководства:
ПОДДЕРЖКА КЛАСТЕРИНГА
В этой версии Cron можно использовать смонтированный в сети общий / var / spool / cron в кластере хостов и указать, что только один из хостов должен запускать задания crontab в этом каталоге одновременно. Для этого нужно запустить Cron с параметром -c, а файл /var/spool/cron/.cron.hostname должен содержать только одну строку, которая представляет имя хоста того хоста в кластере, на котором должны выполняться задания. Если этот файл не существует или имя хоста в нем не совпадает с именем, возвращаемым gethostname (2), то все файлы crontab в этом каталоге игнорируются. Это не влияет на задания cron, указанные в файле / etc / crontab или на файлы в каталоге /etc/cron.d. Эти файлы всегда запускаются и считаются специфичными для хоста.
Вместо того, чтобы редактировать /var/spool/cron/.cron.hostname напрямую, используйте параметр -n в crontab (1) для указания хоста.
Вы должны убедиться, что все хосты в кластере и файловый сервер, с которого они монтируют общий каталог crontab, имеют точно синхронизированные часы, например, с помощью ntpd (8), иначе результаты будут очень непредсказуемыми.
На практике этот подход требует:
crond с -c флаг (поставить CRONDARGS=-c в / etc / sysconfig / crond); иcrontab -n взять на себя.Имейте в виду предупреждение: это решение кластеризует задания cron только в / var / spool / cron (т.е. установлено с помощью crontab -e). Каждый узел по-прежнему будет выполнять свои индивидуальные задания в / etc / crontab или /etc/cron.d.
Почему не ваш вариант (2), но он создает флаг во время выполнения. Задания cron будут запускаться на всех машинах с небольшими локальными вариациями времени, что означает, что один из них сначала создает флаг; другие затем видят, что флаг установлен, и выходят из строя, в то время как первый работает до завершения.
Вам нужно будет обратить внимание на атомарность установки / проверки флага (NFS также является вариантом здесь, с файлом блокировки), хотя, чтобы свести это к минимуму, также может быть некоторое значение в любом
я использую Дженкинс управлять около 140 запланированными сценариями.
Jenkins не предназначался для сервера в качестве замены cron, он предназначен для непрерывной интеграции, но с ним можно управлять почти всем.
Вот некоторые люди, которые добились успеха (как и я), перенося задания из cron в Jenkins.
Вот хорошее сравнение между Jenkins и cron