Comment effectuer le basculement des tâches cron?

En utilisant deux serveurs Debian, j'ai besoin de configurer un environnement de basculement solide pour les tâches cron qui ne peuvent être appelées que sur un serveur à la fois.

Le déplacement d'un fichier dans /etc/cron.d devrait faire l'affaire, mais existe-t-il une solution HA simple pour exécuter une telle action? Et si possible pas avec le rythme cardiaque;)

Je pense que le rythme cardiaque / pacemaker serait la meilleure solution, car ils peuvent prendre en charge beaucoup de conditions de course, d'escrime, etc. pour vous afin de garantir que le travail ne fonctionne que sur un hôte à la fois. Il est possible de concevoir quelque chose vous-même, mais cela ne tiendra probablement pas compte de tous les scénarios de ces packages, et vous finirez par remplacer la plupart, sinon la totalité, de la roue.

Si vous ne vous souciez pas vraiment de ces choses et que vous souhaitez une configuration plus simple. Je suggère d'échelonner les tâches cron sur les serveurs de quelques minutes. Ensuite, lorsque le travail démarre sur le primaire, il peut en quelque sorte laisser un marqueur sur la ressource partagée sur laquelle les travaux opèrent (vous ne le spécifiez pas, donc je suis intentionnellement vague). S'il s'agit d'une base de données, ils peuvent mettre à jour un champ dans une table ou si c'est sur un système de fichiers partagé verrouiller un fichier.

Lorsque le travail s'exécute sur le deuxième serveur, il peut vérifier la présence du marqueur et abandonner s'il est là.

Nous utilisons deux approches en fonction des besoins. Les deux impliquent que les crons soient présents et exécutés sur toutes les machines, mais avec un peu de vérification de l'intégrité:

1. Si les machines sont dans une relation primaire et secondaire (il peut y avoir plus d'un secondaire), les scripts sont modifiés pour vérifier si la machine sur laquelle ils s'exécutent est un état principal. Sinon, ils sortent simplement tranquillement. Je n'ai pas de configuration HB à portée de main pour le moment mais je pense que vous pouvez interroger HB pour ces informations.

2. Si toutes les machines sont des primaires éligibles (comme dans un cluster), un certain verrouillage est utilisé. Au moyen d'une base de données partagée ou d'un fichier PID. Une seule machine obtient le statut de verrouillage et celles qui ne sortent pas tranquillement.

Pour faire court, vous devez transformer vos scripts cron en une sorte d'applications compatibles avec les clusters. Étant donné que l'implémentation est aussi légère ou lourde que vous le souhaitez, ils ont encore besoin d'une chose - être en mesure de reprendre / redémarrer correctement l'action (ou de récupérer leur état) après le basculement du nœud principal. Le cas trivial est que ce sont des programmes sans état (ou des programmes "assez sans état"), qui peuvent être simplement redémarrés à tout moment et feront très bien l'affaire. Ce n'est probablement pas votre cas. Notez que pour les programmes sans état, vous n'avez pas besoin de basculement car vous pouvez simplement les exécuter en parallèle sur tous les nœuds.

Dans un cas normalement compliqué, vos scripts doivent se trouver sur le stockage partagé du cluster, doivent y stocker leur état dans des fichiers, ne doivent changer l'état stocké sur le disque que de manière atomique, et devraient être en mesure de poursuivre leur action à partir de tout état transitoire qu'ils détecteront au démarrage.

En fait, il n'y a pas de solution satisfaisante dans ce domaine. Nous les avons tous essayés. solutions de script, cron avec rythme cardiaque / stimulateur cardiaque et plus encore. La seule solution, jusqu'à récemment, était une solution de réseau. naturellement, ce n'est pas ce que nous voulons voir, car une solution de grille est un peu plus que excessive pour le scénario.

C'est pourquoi j'ai commencé le projet CronBalancer. fonctionne exactement comme un serveur cron normal, sauf qu'il est distribué, à charge équilibrée et HA (une fois terminé). Actuellement, les 2 premiers points sont terminés (bêta) et fonctionne avec un fichier crontab standard.

le cadre HA est en place. il ne reste que la signalisation nécessaire pour déterminer les actions de basculement et de récupération.

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

mandrin

J'avais utilisé le gestionnaire d'événements Nagios comme une solution simple.

Sur le serveur 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

N'oubliez pas d'ajouter l' nagiosutilisateur au groupe sudoers:

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

et désactiver requiretty:

Defaults:nagios !requiretty

Sur le serveur 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
}

commandes.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

mais j'ai changé pour utiliser Pacemaker et Corosync car c'est la meilleure solution pour s'assurer que la ressource ne s'exécute que sur un nœud à la fois.

Voici les étapes que j'ai faites:

Vérifiez que le script crond init est compatible LSB . Sur mon CentOS, je dois changer le statut de sortie de 1 à 0 (si démarrer une course ou arrêter une arrêtée) pour correspondre aux exigences:

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

il peut ensuite être ajouté au stimulateur cardiaque en utilisant:

# 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"

statut GRC

============
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 du basculement en arrêtant Pacemaker et Corosync sur 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  ]

puis vérifiez l'état du cluster sur le 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

Le faire exécuter / ne pas exécuter sur une machine particulière est trivial. Soit un script place un travail cron dans /etc/cron.d, comme vous le suggérez, soit un script permanent dans /etc/cron.d, mais laissez le script lui-même effectuer la vérification de basculement et décider s'il doit s'exécuter.

La partie commune (manquante) dans ces deux cas est la façon dont le script vérifie si le script sur l'autre machine est en cours d'exécution.

Sans plus d'informations sur ce que vous essayez de faire, il est difficile de répondre.

Je préfère Rcron pour ce problème particulier. Vous avez un fichier d'état, qui dit simplement "actif" ou "passif", et s'il est actif, votre cron s'exécutera sur une certaine machine. Si le fichier d'état est défini sur passif, il ne s'exécutera pas. Aussi simple que cela.

Maintenant, vous pouvez utiliser RedHat Cluster Suite ou tout autre middleware de clustering pour gérer les fichiers d'état sur votre cluster, ou vous pouvez définir manuellement actif sur un certain nœud et c'est tout.