Используя два сервера Debian, мне нужно настроить надежную среду аварийного переключения для заданий cron, которые можно вызывать только на одном сервере за раз.
Перемещение файла в /etc/cron.d должно помочь, но есть ли простое решение высокой доступности для выполнения такого действия? И по возможности не с биением сердца;)
Я думаю, что сердцебиение / кардиостимулятор было бы лучшим решением, так как они могут позаботиться о многих условиях гонки, ограждении и т. Д., Чтобы гарантировать, что работа выполняется только на одном хосте за раз. Можно что-то спроектировать самостоятельно, но это, скорее всего, не будет учитывать все сценарии, которые выполняют эти пакеты, и в конечном итоге вы замените большую часть, если не все, колеса.
Если вас не волнуют такие вещи и вы хотите более простую настройку. Я предлагаю увеличить количество заданий cron на серверах на несколько минут. Затем, когда задание начинается на первичном, оно может каким-то образом оставлять маркер на любом общем ресурсе, на котором работают задания (вы не указываете это, поэтому я намеренно неясен). Если это база данных, они могут обновить поле в таблице или заблокировать файл в общей файловой системе.
Когда задание выполняется на втором сервере, оно может проверить наличие маркера и прервать его, если он есть.
Я использовал Nagios обработчик события как простое решение.
На сервере NRPE:
command[check_crond]=/usr/lib64/nagios/plugins/check_procs -c 1: -C crond
command[autostart_crond]=sudo /etc/init.d/crond start
command[stop_crond]=sudo /etc/init.d/crond stop
Не забудьте добавить nagios пользователь в группу sudoers:
nagios ALL=(ALL) NOPASSWD:/usr/lib64/nagios/plugins/, /etc/init.d/crond
и отключить requiretty:
Defaults:nagios !requiretty
На сервере Nagios:
services.cfg
define service{
use generic-service
host_name cpc_3.145
service_description crond
check_command check_nrpe!check_crond
event_handler autostart_crond!cpc_2.93
process_perf_data 0
contact_groups admin,admin-sms
}
commands.cfg
define command{
command_name autostart_crond
command_line $USER1$/eventhandlers/autostart_crond.sh $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ $ARG1$
}
autostart_crond.sh
#!/bin/bash
case "$1" in
OK)
/usr/local/nagios/libexec/check_nrpe -H $4 -c stop_crond
;;
WARNING)
;;
UNKNOWN)
/usr/local/nagios/libexec/check_nrpe -H $4 -c autostart_crond
;;
CRITICAL)
/usr/local/nagios/libexec/check_nrpe -H $4 -c autostart_crond
;;
esac
exit 0
но я перешел на использование Pacemaker и Corosync поскольку это лучшее решение, гарантирующее, что ресурс будет работать только на одном узле за раз.
Вот шаги, которые я сделал:
Убедитесь, что crond сценарий инициализации совместим с LSB. На моем CentOS мне нужно изменить статус выхода с 1 на 0 (если начать работу или остановить остановку), чтобы соответствовать требованиям:
start() {
echo -n $"Starting $prog: "
if [ -e /var/lock/subsys/crond ]; then
if [ -e /var/run/crond.pid ] && [ -e /proc/`cat /var/run/crond.pid` ]; then
echo -n $"cannot start crond: crond is already running.";
failure $"cannot start crond: crond already running.";
echo
#return 1
return 0
fi
fi
stop() {
echo -n $"Stopping $prog: "
if [ ! -e /var/lock/subsys/crond ]; then
echo -n $"cannot stop crond: crond is not running."
failure $"cannot stop crond: crond is not running."
echo
#return 1;
return 0;
fi
затем его можно добавить в кардиостимулятор с помощью:
# crm configure primitive Crond lsb:crond \
op monitor interval="60s"
crm configure show
node SVR022-293.localdomain
node SVR233NTC-3145.localdomain
primitive Crond lsb:crond \
op monitor interval="60s"
property $id="cib-bootstrap-options" \
dc-version="1.1.5-1.1.el5-01e86afaaa6d4a8c4836f68df80ababd6ca3902f" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"
crm статус
============
Last updated: Fri Jun 7 13:44:03 2013
Stack: openais
Current DC: SVR233NTC-3145.localdomain - partition with quorum
Version: 1.1.5-1.1.el5-01e86afaaa6d4a8c4836f68df80ababd6ca3902f
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ SVR022-293.localdomain SVR233NTC-3145.localdomain ]
Crond (lsb:crond): Started SVR233NTC-3145.localdomain
Тестирование аварийного переключения путем остановки Pacemaker и Corosync на 3.145:
[root@3145 corosync]# service pacemaker stop
Signaling Pacemaker Cluster Manager to terminate: [ OK ]
Waiting for cluster services to unload:...... [ OK ]
[root@3145 corosync]# service corosync stop
Signaling Corosync Cluster Engine (corosync) to terminate: [ OK ]
Waiting for corosync services to unload:. [ OK ]
затем проверьте статус кластера на 2.93:
============
Last updated: Fri Jun 7 13:47:31 2013
Stack: openais
Current DC: SVR022-293.localdomain - partition WITHOUT quorum
Version: 1.1.5-1.1.el5-01e86afaaa6d4a8c4836f68df80ababd6ca3902f
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ SVR022-293.localdomain ]
OFFLINE: [ SVR233NTC-3145.localdomain ]
Crond (lsb:crond): Started SVR022-293.localdomain
На самом деле в этой области нет удовлетворительного решения. Мы перепробовали их все. скриптовые решения, cron с heartbeat / pacemaker и многое другое. До недавнего времени единственным решением была сетка. естественно, это не то, что мы хотим видеть, поскольку сеточное решение является немного большим, чем излишним для сценария.
Вот почему я начал проект CronBalancer. работает точно так же, как обычный сервер cron, за исключением того, что он распределен, сбалансирован по нагрузке и HA (по завершении). В настоящее время завершены первые 2 пункта (бета), и они работают со стандартным файлом crontab.
структура высокой доступности уже есть. все, что осталось, - это сигнализация, необходимая для определения действий по переключению и восстановлению.
http://sourceforge.net/projects/cronbalancer/
чак
Короче говоря, вы должны превратить ваши cron-скрипты в своего рода кластерные приложения. Поскольку они являются настолько легкими или тяжелыми, насколько вам нужно, им по-прежнему нужно одно - иметь возможность правильно возобновлять / перезапускать действия (или восстанавливать свое состояние) после аварийного переключения основного узла. Тривиальный случай состоит в том, что они являются программами без состояния (или программами, не имеющими состояния), которые можно просто перезапустить в любое время, и с ними все будет хорошо. Вероятно, это не ваш случай. Обратите внимание, что для программ без сохранения состояния вам не нужна отработка отказа, потому что вы можете просто запустить их параллельно на всех узлах.
В обычном сложном случае ваши скрипты должны находиться в общем хранилище кластера, должны хранить там свое состояние в файлах, должны изменять состояние, хранящееся на диске, только атомарно и должны иметь возможность продолжать свои действия из любого переходного состояния, которое они обнаружат при запуске.
Мы используем два подхода в зависимости от требований. Оба требуют наличия и запуска кронов со всех машин, но с небольшой проверкой работоспособности:
Если машины находятся в первичном и вторичном (может быть более одного вторичного) отношения, то сценарии изменяются, чтобы проверить, является ли машина, на которой они работают, первичным состоянием. Если нет, то они просто тихо уходят. На данный момент у меня нет под рукой установки HB, но я считаю, что вы можете запросить эту информацию у HB.
Если все машины являются подходящими первичными (например, в кластере), то используется некоторая блокировка. С помощью общей базы данных или файла PID. Только одна машина когда-либо получает статус блокировки, и те, которые не выходят тихо.
Заставить его выполнять / не выполнять на конкретной машине - тривиально. Либо пусть сценарий помещает задание cron в /etc/cron.d, как вы предлагаете, либо пусть сценарий постоянно находится в /etc/cron.d, но пусть сам сценарий выполняет проверку переключения и решает, выполнять ли его.
Общей (отсутствующей) частью в обоих случаях является то, как сценарий проверяет, запущен ли сценарий на другом компьютере.
Без дополнительной информации о том, что вы пытаетесь сделать, на это трудно ответить.
Я предпочитаю Rcron для этой конкретной проблемы. У вас есть файл состояния, в котором просто написано «активный» или «пассивный», и если он активен, ваш cron будет работать на определенной машине. Если файл состояния установлен в пассивный режим, он не запустится. Просто как тот.
Теперь вы можете использовать RedHat Cluster Suite или любое другое промежуточное программное обеспечение кластеризации для управления файлами состояния в вашем кластере, или вы можете вручную сделать активным на определенном узле и все.