Как выполнить аварийное переключение заданий cron?

Используя два сервера Debian, мне нужно настроить сильную среду аварийного переключения для заданий cron, которую можно вызывать только на одном сервере за раз.

Перемещение файла в /etc/cron.d должно помочь, но есть ли простое решение HA для выполнения такого действия? И по возможности не с сердцебиением;)

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

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

Когда задание выполняется на втором сервере, оно может проверить наличие маркера и прервать его, если оно есть.

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

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

2. Если все машины являются приемлемыми основными цветами (например, в кластере), то используется некоторая блокировка. С помощью общей базы данных или файла PID. Только одна машина когда-либо получает статус блокировки и те, которые не выходят тихо.

Короче говоря, вы должны превратить свои cron-скрипты в некие кластерные приложения. Будучи реализацией настолько легковесной или настолько тяжелой, насколько вам нужно, им все равно нужно одно - иметь возможность правильно возобновить / перезапустить действие (или восстановить свое состояние) после отработки отказа основного узла. Тривиальный случай состоит в том, что они являются программами без состояния (или «программами без состояния»), которые могут быть просто перезапущены в любое время и будут работать нормально. Это, вероятно, не ваш случай. Обратите внимание, что для программ без сохранения состояния вам не нужно переключаться при сбое, потому что вы можете просто запустить их параллельно на всех узлах.

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

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

Вот почему я начал проект CronBalancer. работает точно так же, как обычный сервер cron, за исключением того, что он распределен, сбалансирован по нагрузке и HA (когда закончено). В настоящее время первые 2 пункта завершены (бета) и работают со стандартным файлом crontab.

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

http://sourceforge.net/projects/cronbalancer/

зажимной патрон

Я использовал обработчик событий 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 в /etc/cron.d, как вы предлагаете, либо он будет постоянно находиться в /etc/cron.d, но сам скрипт выполнит проверку отработки отказа и решит, выполнять ли.

Общей (отсутствующей) частью в обоих из них является то, как скрипт проверяет, запущен ли скрипт на другом компьютере.

Без дополнительной информации о том, что вы пытаетесь сделать, на это трудно ответить.

Я предпочитаю Rcron для этой конкретной проблемы. У вас есть файл состояния, который просто говорит «активный» или «пассивный», и если он активен, ваш cron будет работать на определенной машине. Если файл состояния установлен в пассивное состояние, он не будет работать. Просто как тот.

Теперь вы можете использовать RedHat Cluster Suite или любое другое промежуточное ПО для кластеризации для управления файлами состояния в вашем кластере, или вы можете вручную активировать определенный узел и все.