Come eseguire il failover dei processi cron?

Usando due server Debian, ho bisogno di configurare un ambiente di failover forte per i lavori cron che possono essere chiamati solo su un server alla volta.

Spostare un file in /etc/cron.d dovrebbe fare il trucco, ma esiste una semplice soluzione HA per eseguire tale azione? E se possibile non con il battito del cuore;)

Penso che il battito cardiaco / pacemaker sarebbe la soluzione migliore, dal momento che possono prendersi cura di molte condizioni di gara, scherma, ecc. Al fine di garantire che il lavoro venga eseguito solo su un host alla volta. È possibile progettare qualcosa da soli, ma probabilmente non terrà conto di tutti gli scenari di quei pacchetti, e alla fine finirai per sostituire la maggior parte, se non tutta, della ruota.

Se non ti interessa davvero queste cose e vuoi una configurazione più semplice. Suggerisco di scaglionare i lavori cron sui server di alcuni minuti. Quindi quando il lavoro inizia sul primario può in qualche modo lasciare un marcatore su qualunque risorsa condivisa su cui operano i lavori (non lo specifichi, quindi sono intenzionalmente vago). Se si tratta di un database, possono aggiornare un campo in una tabella o se si trova su un filesystem condiviso per bloccare un file.

Quando il lavoro viene eseguito sul secondo server, può verificare la presenza del marcatore e annullare se è presente.

Utilizziamo due approcci a seconda delle esigenze. Entrambi implicano che i croni siano presenti e funzionanti da tutte le macchine, ma con un po 'di controllo della sanità mentale coinvolti:

1. Se le macchine sono in una relazione primaria e secondaria (potrebbe esserci più di una secondaria), gli script vengono modificati per verificare se la macchina su cui sono in esecuzione è uno stato primario. Altrimenti, semplicemente escono in silenzio. Al momento non ho una configurazione HB a portata di mano, ma credo che tu possa interrogare HB per queste informazioni.

2. Se tutte le macchine sono primarie idonee (come in un cluster), viene utilizzato un blocco. Tramite un database condiviso o un file PID. Solo una macchina ottiene mai lo stato di blocco e quelli che non escono silenziosamente.

Per farla breve, devi trasformare i tuoi script cron in una sorta di applicazioni che supportano i cluster. Essendo l'implementazione leggera o pesante di cui hai bisogno, hanno ancora bisogno di una cosa: essere in grado di riprendere / riavviare correttamente l'azione (o ripristinare il loro stato) dopo il failover del nodo primario. Il caso banale è che sono programmi senza stato (o programmi "abbastanza apolidi"), che possono essere semplicemente riavviati in qualsiasi momento e andranno bene. Questo probabilmente non è il tuo caso. Si noti che per i programmi senza stato non è necessario il failover perché è possibile semplicemente eseguirli in parallelo su tutti i nodi.

In casi normalmente complicati, i tuoi script dovrebbero trovarsi nella memoria condivisa del cluster, dovrebbero archiviare il loro stato in file lì, dovrebbero cambiare lo stato archiviato sul disco solo atomicamente e dovrebbero poter continuare la loro azione da qualsiasi stato transitorio che rileveranno all'avvio.

In realtà non esiste una soluzione soddisfacente in questo settore. Li abbiamo provati tutti. soluzioni di scripting, cron con heartbeat / pacemaker e altro. L'unica soluzione, fino a poco tempo fa, era una soluzione di griglia. naturalmente questo non è ciò che vogliamo vedere come una soluzione di rete è un po 'più che eccessiva per lo scenario.

Ecco perché ho iniziato il progetto CronBalancer. funziona esattamente come un normale server cron tranne che è distribuito, bilanciato in base al carico e HA (al termine). Attualmente i primi 2 punti sono finiti (beta) e funziona con un file crontab standard.

il framework HA è attivo. tutto ciò che rimane è la segnalazione necessaria per determinare le azioni di failover e di recupero.

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

mandrino

Stavo usando il gestore di eventi Nagios come una soluzione semplice.

Sul server 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

Non dimenticare di aggiungere l' nagiosutente al gruppo sudoers:

nagios  ALL=(ALL)   NOPASSWD:/usr/lib64/nagios/plugins/, /etc/init.d/crond

e disabilita requiretty:

Defaults:nagios !requiretty

Sul server 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

ma sono passato a utilizzare Pacemaker e Corosync poiché è la soluzione migliore per garantire che la risorsa venga eseguita solo su un nodo alla volta.

Ecco i passaggi che ho fatto:

Verificare che lo script crond init sia conforme a LSB . Sul mio CentOS, devo modificare lo stato di uscita da 1 a 0 (se avviare una corsa o interrompere una fermata) per soddisfare i requisiti:

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

quindi può essere aggiunto al pacemaker usando:

# crm configure primitive Crond lsb:crond \
        op monitor interval="60s"

crm configura 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"

stato 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

Test del failover arrestando Pacemaker e Corosync su 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  ]

quindi controlla lo stato del cluster su 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

Farlo eseguire / non eseguire su una macchina particolare è banale. O uno script inserisce un processo cron in /etc/cron.d, come suggerisci, oppure lo script è permanentemente in /etc/cron.d, ma fai in modo che lo script esegua il controllo del failover e decida se eseguirlo.

La parte comune (mancante) in entrambi questi è il modo in cui lo script controlla se lo script sull'altro computer è in esecuzione.

Senza ulteriori informazioni su ciò che stai cercando di fare, è difficile rispondere a questa domanda.

Preferisco Rcron per questo particolare problema. Hai un file di stato, che dice semplicemente "attivo" o "passivo", e se è attivo il tuo cron verrà eseguito su un determinato computer. Se il file di stato è impostato su passivo, non verrà eseguito. Semplice come quella.

Ora, puoi usare RedHat Cluster Suite o qualsiasi altro middleware di clustering per gestire i file di stato nel cluster, oppure puoi impostare manualmente attivo su un determinato nodo e il gioco è fatto.