Die Beispielanwendung implementiert einen einfachen Fehler-Monitor, der die Zuverlässigkeit der DNS-Ressource (in.named) überwacht. Der Fehler-Monitor setzt sich aus folgenden Elementen zusammen:
dns_probe, ein benutzerdefiniertes Programm, das nslookup verwendet, um zu überprüfen, ob die vom Beispieldatendienst gesteuerte DNS-Ressource läuft. Wenn DNS nicht läuft, versucht diese Methode einen lokalen Neustart. Je nach der Anzahl der Neustartversuche kann sie auch anfordern, dass RGM den Datendienst auf einen anderen Knoten verschiebt.
dns_monitor_start, eine Rückmeldemethode zum Starten von dns_probe. Wenn die Überwachung aktiviert ist, ruft RGM automatisch dns_monitor_start auf, nachdem der Beispieldatendienst online gebracht wurde.
dns_monitor_stop, eine Rückmeldemethode zum Stoppen von dns_probe. RGM ruft automatisch dns_monitor_stop auf, bevor der Beispieldatendienst offline gebracht wird.
dns_monitor_check, eine Rückmeldemethode zum Aufrufen der Validate-Methode, die überprüft, ob das Konfigurationsverzeichnis verfügbar ist, wenn das PROBE-Programm für den Datendienst ein Failover auf einen neuen Knoten ausführt.
Das dns_probe-Programm implementiert einen ständig ausgeführten Prozess, der überprüft, ob die vom Beispieldatendienst gesteuerte DNS-Ressource läuft. Der dns_probe-Befehl wird von der dns_monitor_start-Methode ausgelöst, die wiederum automatisch von RGM aufgerufen wird, sobald der Beispieldatendienst online gebracht wurde. Der Datendienst wird von der dns_monitor_stop-Methode gestoppt, die RGM anschließend aufruft, bevor der Beispieldatendienst offline gebracht wird.
Dieser Abschnitt beschreibt die Hauptteile der PROBE-Methode für die Beispielanwendung. Die Funktionalität, die allen Rückmeldemethoden gemeinsam ist, wird nicht beschrieben, wie zum Beispiel die parse_args()-Funktion und das Abrufen von syslog (in Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben).
Eine vollständige Auflistung der PROBE-Methode finden Sie unter PROBE-Programm.
Das Testsignal läuft in einer Endlosschleife. Es verwendet nslookup, um zu überprüfen, ob die richtige DNS-Ressource läuft. Wenn DNS läuft, ruht das Testsignal während eines festgesetzten Zeitintervalls (eingestellt von der systemdefinierten Eigenschaft Thorough_probe_interval) und prüft dann erneut. Wenn DNS nicht läuft, versucht das Programm einen lokalen Neustart. Je nach der Anzahl der Neustartversuche kann es auch anfordern, dass RGM den Datendienst auf einen anderen Knoten verschiebt.
Dieses Programm benötigt die Werte der folgenden Eigenschaften:
Thorough_probe_interval – Zum Einstellen des Zeitraums, während dem das Testsignal ruht.
Probe_timeout – Zum Durchsetzen des Zeitüberschreitungswertes für das Testsignal an den nslookup-Befehl, der den Test ausführt.
Network_resources_used – Zum Abrufen der IP-Adresse, unter der DNS läuft.
Retry_count und Retry_interval – Zum Festlegen der Anzahl von Neustartversuchen und des Zeitraums, über den die Versuche gezählt werden.
RT_basedir – Zum Abrufen des Verzeichnisses, in dem das PROBE-Programm und das gettime-Dienstprogramm gespeichert sind
Die Funktion scha_resource_get() ruft die Werte dieser Eigenschaften ab und speichert sie folgendermaßen in Shell-Variablen:
PROBE_INTERVAL=`scha_resource_get -O THOROUGH_PROBE_INTERVAL \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME` probe_timeout_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAME Probe_timeout` PROBE_TIMEOUT=`echo $probe_timeout_info | awk '{print $2}'` DNS_HOST=`scha_resource_get -O NETWORK_RESOURCES_USED -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAME` RETRY_COUNT=`scha_resource_get -O RETRY_COUNT -R $RESOURCE_NAME -G\ $RESOURCEGROUP_NAME` RETRY_INTERVAL=`scha_resource_get -O RETRY_INTERVAL -R $RESOURCE_NAME -G\ $RESOURCEGROUP_NAME` RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G\ $RESOURCEGROUP_NAME`
Für systemdefinierte Eigenschaften wie Thorough_probe_interval gibt scha_resource_get() nur den Wert zurück. Für Erweiterungseigenschaften wie Probe_timeout gibt scha_resource_get() den Typ und den Wert zurück. Verwenden Sie den awk-Befehl, um nur den Wert abzurufen.
Das Testsignal selbst besteht aus einer while-Endlosschleife aus nslookup-Befehlen. Vor der while-Schleife wird eine temporäre Datei für die nslookup-Antworten eingerichtet. Die Variablen probefail und retries werden auf 0 initialisiert .
# Temporäre Datei für nslookup-Antworten konfigurieren. DNSPROBEFILE=/tmp/.$RESOURCE_NAME.probe probefail=0 retries=0 |
Die while-Schleife selbst hat folgende Aufgaben:
Festlegen des Ruheintervalls für das Testsignal.
Verwenden von hatimerun zum Auslösen von nslookup durch Übergabe des Probe_timeout-Werts und Identifizieren des Zielhosts.
Festlegen der probefail-Variable, basierend auf dem Erfolg oder Fehlschlag des nslookup-Rückgabecodes.
Wenn probefail auf 1 (Fehlschlag) eingestellt ist, wird überprüft, ob die Antwort auf nslookup vom Beispieldatendienst und nicht von einem anderen DNS-Server kam.
Es folgt der while-Schleifencode.
while : do # Das Intervall, in dem das Testsignal ausgeführt werden muss, wird in der # Eigenschaft THOROUGH_PROBE_INTERVAL angegeben. Daher wird das Ruhen # des Testsignals auf eine Dauer von THOROUGH_PROBE_INTERVAL eingestellt. sleep $PROBE_INTERVAL # nslookup-Befehl für die IP-Adresse des DNS ausführen. hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \ > $DNSPROBEFILE 2>&1 retcode=$? if [ $retcode -ne 0 ]; then probefail=1 fi # Sicherstellen, dass die Antwort auf nslookup vom HA-DNS- # Server und nicht von einem anderen in der /etc/resolv.conf-Datei # genannten Namensserver stammt. if [ $probefail -eq 0 ]; then # Namen des Servers abrufen,m der auf die nslookup-Abfrage geantwortet hat. SERVER=` awk ' $1=="Server:" { print $2 }' \ $DNSPROBEFILE | awk -F. ' { print $1 } ' ` if [ -z "$SERVER" ]; then probefail=1 else if [ $SERVER != $DNS_HOST ]; then probefail=1 fi fi fi |
Wenn die probefail-Variable ungleich 0 (Erfolg) ist, bedeutet dies, dass die Zeitüberschreitung für den nslookup-Befehl abgelaufen war oder dass die Antwort von einem anderen Server als dem Beispieldienst-DNS kam. In beiden Fällen funktioniert der DNS-Server nicht wie erwartet, und der Fehler-Monitor ruft die Funktion decide_restart_or_failover() auf, um festzulegen, ob der Datendienst lokal neu gestartet wird oder ob RGM aufgefordert wird, den Datendienst auf einen anderen Knoten zu verschieben. Wenn die probefail-Variable 0 ist, wird eine Meldung generiert, die besagt, dass das Testsignal erfolgreich war.
if [ $probefail -ne 0 ]; then decide_restart_or_failover else logger -p ${SYSLOG_FACILITY}.err\ -t [$SYSLOG_TAG]\ "${ARGV0} Testsignal für Ressource HA-DNS erfolgreich" fi |
Die Funktion decide_restart_or_failover() verwendet ein Zeitfenster (Retry_interval) und einen Fehlschlagzähler (Retry_count), um festzulegen, ob DNS lokal neu gestartet oder RGM aufgefordert wird, den Datendienst auf einen anderen Knoten zu verschieben. Sie implementiert den folgenden bedingten Code (siehe die Codeauflistung für decide_restart_or_failover() in PROBE-Programm).
Wenn dies der erste Fehlschlag ist, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert und der Zähler in der retries-Variable weitergedreht.
Wenn es sich nicht um den ersten Fehlschlag handelt, aber das Zeitfenster überschritten wurde, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert, der Zähler zurückgesetzt und das Fenster verschoben.
Wenn das Zeitfenster noch nicht abgelaufen ist und der Wiederholversuchszähler überschritten wurde, wird ein Failover auf einen anderen Knoten ausgeführt. Wenn das Failover fehlschlägt, wird ein Fehler protokolliert und das Testsignalprogramm mit Status 1 (Fehlschlag) beendet.
Wenn das Zeitfenster noch nicht abgelaufen ist und der Wiederholversuchszähler nicht überschritten wurde, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert und der Zähler in der retries-Variable weitergedreht.
Wenn die Anzahl der Neustarts während des Zeitintervalls den Grenzwert erreicht, fordert die Funktion bei RGM das Verschieben des Datendienstes auf einen anderen Knoten an. Wenn die Anzahl der Neustarts den Grenzwert noch nicht erreicht hat, bzw. wenn das Zeitintervall abgelaufen ist und die Zählung von vorn beginnt, versucht die Funktion, DNS auf demselben Knoten neu zu starten. Beachten Sie Folgendes für diese Funktion:
Das gettime-Dienstprogramm wird zum Verfolgen der Zeit zwischen Neustarts verwendet. Dabei handelt es sich um ein C-Programm, das im (RT_basedir-) Verzeichnis residiert.
Die systemdefinierten Ressourceneigenschaften Retry_count und Retry_interval legen die Anzahl der Neustartversuche und das Zeitintervall für die Zählung fest. Der Standardwert für diese Eigenschaften in der RTR-Datei liegt bei 2 Versuchen in einem Zeitraum von 5 Minuten (300 Sekunden). Der Cluster-Verwalter kann diese Werte jedoch ändern.
Die restart_service()-Funktion wird aufgerufen, um zu versuchen, den Datendienst auf demselben Knoten neu zu starten. Weitere Informationen zu dieser Funktion finden Sie im nächsten Abschnitt, Neustarten des Datendienstes.
Die API-Funktion scha_control() bringt die Ressourcengruppe, die den Beispieldatendienst enthält, mit der Option GIVEOVER offline und auf einem anderen Knoten wieder online.
Die restart_service()-Funktion wird von decide_restart_or_failover() aufgerufen, um einen Neustart des Datendienstes auf dem gleichen Knoten zu versuchen. Diese Funktion führt folgende Aufgaben aus.
Sie stellt fest, ob der Datendienst noch unter PMF registriert ist. Wenn der Dienst noch registriert ist, geht die Funktion folgendermaßen vor:
Sie ruft den Stop-Methodennamen und den Stop_timeout-Wert für den Datendienst ab.
Sie verwendet hatimerun, um die Stop-Methode für den Datendienst zu starten, indem sie den Stop_timeout-Wert übergibt.
Wenn der Datendienst erfolgreich gestoppt wurde, ruft sie den Start-Methodennamen und den Start_timeout-Wert für den Datendienst ab.
Sie verwendet hatimerun, um die Start-Methode für den Datendienst zu starten, indem sie den Start_timeout-Wert übergibt.
Wenn der Datendienst nicht mehr unter PMF registriert ist, bedeutet dies, dass er die maximale Anzahl zulässiger Wiederholversuche unter PMF überschritten hat. Daher wird die scha_control()-Funktion mit der GIVEOVER-Option aufgerufen, um für den Datendienst ein Failover auf einen anderen Knoten auszuführen.
function restart_service { # Um den Datendienst neu zu starten, wird zunächst überprüft, ob # der Datendienst selbst noch unter PMF registriert ist. pmfadm -q $PMF_TAG if [[ $? -eq 0 ]]; then # Da das Tag fur den Datendienst noch unter PMF registriert ist, # den Datendienst zunächst stoppen und dann wieder neu starten. # Stop-Methodenname und STOP_TIMEOUT-Wert für diese # Ressource abrufen. STOP_TIMEOUT=`scha_resource_get -O STOP_TIMEOUT \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ STOP_METHOD=`scha_resource_get -O STOP \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ hatimerun -t $STOP_TIMEOUT $RT_BASEDIR/$STOP_METHOD \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME if [[ $? -ne 0 ]]; then logger-p ${SYSLOG_FACILITY}.err -t [$SYSLOG_TAG] \ “${ARGV0} Stop-Methode fehlgeschlagen.” return 1 fi # START-Methodenname und START_TIMEOUT-Wert für diese # Ressource abrufen. START_TIMEOUT=`scha_resource_get -O START_TIMEOUT \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ START_METHOD=`scha_resource_get -O START \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ hatimerun -t $START_TIMEOUT $RT_BASEDIR/$START_METHOD \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME if [[ $? -ne 0 ]]; then logger-p ${SYSLOG_FACILITY}.err -t [$SYSLOG_TAG] \ “${ARGV0} Start-Methode fehlgeschlagen.” return 1 fi else # Das Fehlen des TAG für den Datendienst weist darauf # hin, dass der Datendienst bereits die maximale Anzahl # der unter PMF zulässigen Wiederholversuche überschritten hat. # Daher nicht versuchen, den Datendienst noch einmal neu # zu starten, sondern ein Failover auf einen anderen Knoten im # Cluster versuchen. scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \ -R $RESOURCE_NAME fi return 0 } |
Das PROBE-Programm des Datendienstes wird mit Fehlschlag beendet, wenn sowohl die lokalen Neustartversuche als auch die Failover-Versuche auf einen anderen Knoten fehlgeschlagen sind. Es protokolliert die Meldung “Failover-Versuch fehlgeschlagen”.
RGM ruft die Monitor_start-Methode auf, um die dns_probe-Methode zu starten, nachdem der Beispieldatendienst online gebracht wurde.
Dieser Abschnitt beschreibt die Hauptteile der Monitor_start-Methode für die Beispielanwendung. Die Funktionalität, die allen Rückmeldemethoden gemeinsam ist, wird nicht beschrieben, wie zum Beispiel die parse_args()-Funktion und das Abrufen von syslog (in Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben).
Eine vollständige Auflistung der Monitor_start-Methode finden Sie unter Monitor_start-Methode.
Diese Methode verwendet PMF (pmfadm) zum Starten des Testsignals.
Die Monitor_start-Methode ruft den Wert der RT_basedir-Eigenschaft ab, um den vollständigen Pfadnamen für das PROBE-Programm zu erstellen. Diese Methode startet das Testsignal mit der Endloswiederholversuchs-Option von pmfadm (-n -1, -t -1). Wenn also das Testsignal nicht startet, versucht PMF eine endlose Anzahl von Malen während eines endlosen Zeitraums zu starten.
# Wert der RT_BASEDIR-Eigenschaft der Ressource # abrufen, um herauszufinden, wo das Testsignalprogramm residiert. RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME` # Testsignal für den Datendienst unter PMF starten. Option der endlosen Wiederholversuche # zum Starten des Testsignals verwenden. Ressourcenname, -typ und -gruppe # an das Testsignalprogramm übergeben. pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \ $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME |
RGM ruft die Monitor_stop-Methode auf, um die Ausführung von dns_probe zu stoppen, wenn der Beispieldatendienst offline gebracht wird.
Dieser Abschnitt beschreibt die Hauptteile der Monitor_stop-Methode für die Beispielanwendung. Die Funktionalität, die allen Rückmeldemethoden gemeinsam ist, wird nicht beschrieben, wie zum Beispiel die parse_args()-Funktion und das Abrufen von syslog (in Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben).
Eine vollständige Auflistung der Monitor_stop-Methode finden Sie unter Monitor_stop-Methode.
Diese Methode verwendet PMF (pmfadm), um festzustellen, ob das Testsignal läuft und es gegebenenfalls zu stoppen.
Die Monitor_stop-Methode verwendet pmfadm -q, um festzustellen, ob das Testsignal läuft und es gegebenenfalls unter Verwendung von pmfadm -s zu stoppen. Wenn das Testsignal bereits gestoppt wurde, wird die Methode dennoch mit Erfolg beendet, was die Idempotenz der Methode sicherstellt.
# Feststellen, ob der Monitor läuft, und ggf. Beenden erzwingen. if pmfadm -q $PMF_TAG; then pmfadm -s $PMF_TAG KILL if [ $? -ne 0 ]; then logger -p ${SYSLOG_FACILITY}.err \ -t [$SYSLOG_TAG] \ "${ARGV0} Monitor für Ressource $RESOURCE_NAME"\ "konnte nicht gestoppt werden" exit 1 else # Monitor konnte erfolgreich gestoppt werde. Meldung protokollieren. logger -p ${SYSLOG_FACILITY}.err \ -t [$SYSLOG_TAG] \ "${ARGV0} Monitor für " $RESOURCE_NAME \ " erfolgreich gestoppt" fi fi exit 0 |
Stellen Sie sicher, dass das KILL-Signal mit pmfadm verwendet wird, um das Testsignal zu stoppen, und nicht ein maskierbares Signal wie TERM. Andernfalls kann die Monitor_stop-Methode für unbegrenzte Zeit hängen, bis schließlich die Zeit überschritten ist. Der Grund für dieses Problem ist, dass die PROBE-Methode scha_control() aufruft, wenn der Datendienst neu gestartet oder ein Failover ausgeführt werden muss. Wenn scha_control() die Monitor_stop-Methode als Teil des Prozesses zum Offline-bringen des Datendienstes aufruft und Monitor_stop ein maskierbares Signal verwendet, hängt die Methode, während sie darauf wartet, dass scha_control() endet, während scha_control() hängt und darauf wartet, dass Monitor_stop endet.
Die Monitor_stop-Methode protokolliert eine Fehlermeldung, wenn sie die PROBE-Methode nicht stoppen kann. RGM versetzt den Beispieldatendienst in den MONITOR_FAILED-Zustand auf dem Primärknoten, was den Knoten zum Absturz bringen kann.
Monitor_stop darf erst beendet werden, wenn das Testsignal gestoppt wurde.
RGM ruft die Monitor_check-Methode immer dann auf, wenn die PROBE-Methode versucht, für die Ressourcengruppe, die den Datendienst enthält, ein Failover auf einen neuen Knoten auszuführen.
Dieser Abschnitt beschreibt die Hauptteile der Monitor_check-Methode für die Beispielanwendung. Die Funktionalität, die allen Rückmeldemethoden gemeinsam ist, wird nicht beschrieben, wie zum Beispiel die parse_args()-Funktion und das Abrufen von syslog (in Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben).
Eine vollständige Auflistung der Monitor_check-Methode finden Sie unter Monitor_check-Methode.
Die Monitor_check-Methode muss so implementiert werden, dass sie keine Konflikte mit anderen, gleichzeitig laufenden Methoden bewirkt.
Die Monitor_check-Methode ruft die Validate-Methode auf, um zu überprüfen, ob das DNS-Konfigurationsverzeichnis auf dem neuen Knoten verfügbar ist. Die Confdir-Erweiterungseigenschaft zeigt auf das DNS-Konfigurationsverzeichnis. Daher ruft Monitor_check den Pfad und Namen für die Validate-Methode und den Wert für die Confdir-Methode ab. Dieser Wert wird an Validate übergeben, wie in der folgenden Auflistung gezeigt.
# Den vollständigen Pfad für die Validate-Methode aus # der RT_BASEDIR-Eigenschaft des Ressourcentyps abrufen. RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAMÈ # Namen der Validate-Methode für diese Ressource abrufen. VALIDATE_METHOD=`scha_resource_get -O VALIDATE \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ # Wert der Confdir-Eigenschaft abrufen, um den Datendienst zu starten. # Mithilfe des eingegebenen Ressourcennamens und der Ressourcengruppe # den Confdir-Wert abrufen, der bei Hinzufügen der Ressource eingestellt wurde. config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAME Confdir` # scha_resource_get gibt sowohl den Typ als auch den Wert von Erweiterungs- # eigenschaften zurück. awk verwenden, um nur den Wert der Erweiterungs- # eigenschaft abzurufen. CONFIG_DIR=`echo $config_info | awk `{print $2}'` # Validate-Methode aufrufen, damit für den Datendienst ein erfolgreiches # Failover auf den neuen Knoten ausgeführt werden kann. $RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR |
Unter Validate-Methode wird gezeigt, wie die Beispielanwendung die Eignung eines Knotens für das Hosten des Datendienstes überprüft.