Wie führe ich ein Cron-Job-Failover durch?

Bei Verwendung von zwei Debian-Servern muss eine starke Failover-Umgebung für Cron-Jobs eingerichtet werden, die jeweils nur auf einem Server aufgerufen werden kann.

Das Verschieben einer Datei in /etc/cron.d sollte ausreichen, aber gibt es eine einfache HA-Lösung, um eine solche Aktion auszuführen? Und wenn möglich nicht mit Herzschlag;)

Ich denke, Herzschlag / Herzschrittmacher wäre die beste Lösung, da sie viele Rennbedingungen, Fechten usw. für Sie erledigen können, um sicherzustellen, dass der Job jeweils nur auf einem Host ausgeführt wird. Es ist möglich, etwas selbst zu entwerfen, aber es wird wahrscheinlich nicht alle Szenarien berücksichtigen, die diese Pakete ausführen, und Sie werden schließlich den größten Teil, wenn nicht den gesamten Teil des Rads ersetzen.

Wenn Sie sich nicht wirklich für solche Dinge interessieren und eine einfachere Einrichtung wünschen. Ich schlage vor, die Cron-Jobs auf den Servern um einige Minuten zu verschieben. Wenn der Job dann auf dem primären Job gestartet wird, kann er irgendwie eine Markierung auf der gemeinsam genutzten Ressource hinterlassen, auf der die Jobs ausgeführt werden (Sie geben dies nicht an, daher bin ich absichtlich vage). Wenn es sich um eine Datenbank handelt, können sie ein Feld in einer Tabelle aktualisieren oder wenn es sich in einem gemeinsam genutzten Dateisystem befindet, eine Datei sperren.

Wenn der Job auf dem zweiten Server ausgeführt wird, kann er das Vorhandensein des Markers überprüfen und abbrechen, wenn er vorhanden ist.

Abhängig von den Anforderungen verwenden wir zwei Ansätze. In beiden Fällen müssen die Cron von allen Maschinen aus vorhanden sein und ausgeführt werden, wobei jedoch ein wenig Überprüfung der Gesundheit erforderlich ist:

1. Wenn sich die Computer in einer primären und sekundären Beziehung befinden (es kann mehr als eine sekundäre Beziehung geben), werden die Skripts geändert, um zu überprüfen, ob der Computer, auf dem sie ausgeführt werden, ein primärer Status ist. Wenn nicht, dann verlassen sie einfach leise. Ich habe momentan kein HB-Setup zur Hand, aber ich glaube, Sie können HB nach diesen Informationen abfragen.

2. Wenn alle Computer berechtigte Primärdaten sind (z. B. in einem Cluster), wird eine gewisse Sperrung verwendet. Über eine gemeinsam genutzte Datenbank oder eine PID-Datei. Nur eine Maschine erhält jemals den Sperrstatus und diejenigen, die nicht leise austreten.

Um es kurz zu machen, müssen Sie Ihre Cron-Skripte in eine Art clusterfähige Anwendungen verwandeln. Da die Implementierung so leicht oder so schwer ist, wie Sie es benötigen, benötigen sie noch eines: Sie können die Aktion nach dem Failover des primären Knotens ordnungsgemäß fortsetzen / neu starten (oder ihren Status wiederherstellen). Der triviale Fall ist, dass es sich um zustandslose Programme (oder "zustandslose" Programme) handelt, die jederzeit einfach neu gestartet werden können und problemlos funktionieren. Dies ist wahrscheinlich nicht Ihr Fall. Beachten Sie, dass Sie für zustandslose Programme kein Failover benötigen, da Sie sie einfach auf allen Knoten parallel ausführen können.

In einem normalerweise komplizierten Fall sollten sich Ihre Skripte im gemeinsam genutzten Speicher des Clusters befinden, ihren Status in Dateien dort speichern, den auf der Festplatte gespeicherten Status nur atomar ändern und in der Lage sein, ihre Aktion von jedem vorübergehenden Status aus fortzusetzen, den sie beim Start erkennen.

Tatsächlich gibt es in diesem Bereich keine zufriedenstellende Lösung. Wir haben sie alle ausprobiert. Skriptlösungen, Cron mit Herzschlag / Schrittmacher und mehr. Die einzige Lösung war bis vor kurzem eine Netzlösung. Natürlich ist dies nicht das, was wir sehen wollen, da eine Grid-Lösung für das Szenario etwas mehr als übertrieben ist.

Deshalb habe ich das CronBalancer-Projekt gestartet. funktioniert genau wie ein normaler Cron-Server, nur dass er verteilt, ausgeglichen und HA ist (wenn er fertig ist). Derzeit sind die ersten 2 Punkte fertig (Beta) und funktionieren mit einer Standard-Crontab-Datei.

Das HA-Framework ist vorhanden. Alles, was übrig bleibt, ist die Signalisierung, die erforderlich ist, um die Failover- und Wiederherstellungsaktionen zu bestimmen.

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

Futter

Ich hatte Nagios Event Handler als einfache Lösung verwendet.

Auf dem NRPE-Server:

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

Vergessen Sie nicht, den nagiosBenutzer zur Sudoers-Gruppe hinzuzufügen:

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

und deaktivieren requiretty:

Defaults:nagios !requiretty

Auf dem Nagios-Server:

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
}

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

Ich habe jedoch auf Pacemaker und Corosync umgestellt, da dies die beste Lösung ist, um sicherzustellen, dass die Ressource jeweils nur auf einem Knoten ausgeführt wird.

Hier sind die Schritte, die ich getan habe:

Stellen Sie sicher, dass das crond init-Skript LSB-kompatibel ist . Auf meinem CentOS muss ich den Exit-Status von 1 auf 0 ändern (wenn ein Lauf gestartet oder ein Stopp gestoppt wird), um den Anforderungen zu entsprechen:

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

dann kann es dem Schrittmacher hinzugefügt werden, indem Folgendes verwendet wird:

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

============
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

Testen des Failovers durch Stoppen von Pacemaker und Corosync unter 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  ]

Überprüfen Sie dann den Clusterstatus auf 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

Es ist trivial, es auf einem bestimmten Computer ausführen / nicht ausführen zu lassen. Lassen Sie entweder ein Skript einen Cron-Job in /etc/cron.d ablegen, wie Sie vorschlagen, oder lassen Sie das Skript dauerhaft in /etc/cron.d, aber lassen Sie das Skript selbst die Failover-Prüfung durchführen und entscheiden, ob es ausgeführt werden soll.

Der gemeinsame (fehlende) Teil in beiden ist, wie das Skript prüft, ob das Skript auf dem anderen Computer ausgeführt wird.

Ohne weitere Informationen darüber, was Sie tun möchten, ist dies schwer zu beantworten.

Ich bevorzuge Rcron für dieses spezielle Problem. Sie haben eine Statusdatei, die einfach "aktiv" oder "passiv" sagt, und wenn sie aktiv ist, wird Ihr Cron auf einem bestimmten Computer ausgeführt. Wenn die Statusdatei auf passiv gesetzt ist, wird sie nicht ausgeführt. So einfach ist das.

Jetzt können Sie RedHat Cluster Suite oder eine andere Cluster-Middleware verwenden, um Statusdateien in Ihrem Cluster zu verwalten, oder Sie können manuell auf einem bestimmten Knoten aktiv setzen, und das war's.