Definieren eines Fehler-Monitors

Die Beispielanwendung implementiert einen einfachen Fehler-Monitor, der die Zuverlässigkeit der DNS-Ressource (in.named) überwacht. Der Fehler-Monitor besteht aus folgenden Elementen:

• dns_probe, ein benutzerdefiniertes Programm, das nslookup verwendet, um zu prüfen, ob die vom Beispieldatendienst gesteuerte DNS-Ressource ausgeführt wird. 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, die dns_probe startet. RGM ruft dns_monitor_start automatisch auf, nachdem der Beispieldatendienst bei aktivierter Überwachung online gebracht wurde.

• dns_monitor_stop, eine Rückmeldemethode, die dns_probe stoppt. RGM ruft dns_monitor_stop automatisch auf, bevor der Beispieldatendienst offline gebracht wird.

• dns_monitor_check, eine Rückmeldemethode, die die Validate-Methode aufruft, um zu prüfen, ob das Konfigurationsverzeichnis verfügbar ist, wenn das PROBE-Programm einen Failover des Datendienstes an einen neuen Knoten durchführt.

Funktionsweise des Testprogramms

Das dns_probe-Programm implementiert einen ständig ausgeführten Prozess, der überprüft, ob die vom Beispieldatendienst gesteuerte DNS-Ressource läuft. dns_probe wird über die dns_monitor_start-Methode gestartet, die von RGM automatisch ausgeführt wird, nachdem der Datendienst online gebracht wurde. Der Datendienst wird von der dns_monitor_stop-Methode gestoppt, die von RGM ausgeführt wird, bevor RGM den Beispieldatendienst offline bringt.

Dieser Abschnitt beschreibt die Hauptteile der PROBE-Methode für die Beispielanwendung. Es werden keine Funktionen beschrieben, die allen Rückmeldemethoden gemeinsam sind, wie die parse_args()-Funktion. In diesem Abschnitt wird ebenfalls nicht beschrieben, wie die syslog()-Funktion verwendet wird. Die gemeinsamen Funktionen werden im Abschnitt Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben.

Eine vollständige Auflistung der PROBE-Methode finden Sie im Abschnitt Auflistung des PROBE-Programmcodes.

Das Testsignalprogramm

Das Testsignal läuft in einer Endlosschleife. Es verwendet nslookup, um zu prüfen, ob die richtige DNS-Ressource ausgeführt wird. Falls DNS ausgeführt wird, ruht das Testsignal für einen vordefinierten Zeitraum (der durch die systemdefinierte Eigenschaft Thorough_probe_interval festgelegt ist) und prüft 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.

Abrufen von Eigenschaftswerten

Für dieses sind die Werte der folgenden Eigenschaften erforderlich:

• Thorough_probe_interval – Zum Einstellen des Zeitraums, während dem das Testsignal ruht.

• Probe_timeout – Zum Erzwingen des Zeitüberschreitungswerts des Testsignals für den nslookup-Befehl, der das Testsignal ausgibt

• Network_resources_used – Zum Abrufen der IP-Adresse, unter der DNS läuft

• Retry_count and Retry_interval – Zum Ermitteln der Anzahl an Neustartversuchen und des Zeitraums, innerhalb dessen diese gezählt werden

• RT_basedir – Zum Abrufen des Verzeichnisses, in dem sich das PROBE-Programm und das gettime-Dienstprogramm befinden

Die scha_resource_get()-Funktion ruft die Werte dieser Eigenschaften ab und speichert sie wie folgt in den 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`

---

Hinweis –

Im Falle von systemdefinierten Eigenschaften, wie Thorough_probe_interval , gibt die scha_resource_get()-Funktion lediglich den Wert zurück. Im Falle von Erweiterungseigenschaften, wie Probe_timeout, gibt die scha_resource_get()-Funktion den Typ und den Wert zurück. Verwenden Sie den awk-Befehl, um lediglich den Wert abzurufen.

---

Überprüfen der Zuverlässigkeit des Dienstes

Das Testsignal selbst ist eine while-Endlosschleife von 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.

# Set up a temporary file for the nslookup replies.
DNSPROBEFILE=/tmp/.$RESOURCE_NAME.probe
probefail=0
retries=0

Die while-Schleife führt folgende Aufgaben durch:

• Festlegen des Ruheintervalls für das Testsignal

• Verwenden von hatimerun zum Starten von nslookup, Übergeben des Wertes Probe_timeout und Identifizieren des Ziel-Hosts

• Festlegen der probefail-Variablen, 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
   # The interval at which the probe needs to run is specified in the
   # property THOROUGH_PROBE_INTERVAL. Therefore, set the probe to sleep
   # for a duration of THOROUGH_PROBE_INTERVAL.
   sleep $PROBE_INTERVAL

   # Run an nslookup command of the IP address on which DNS is serving.
   hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \
   > $DNSPROBEFILE 2>&1

      retcode=$?
      if [ $retcode -ne 0 ]; then
            probefail=1
      fi

   # Make sure that the reply to nslookup comes from the HA-DNS
   # server and not from another nameserver mentioned in the 
   # /etc/resolv.conf file.
   if [ $probefail -eq 0 ]; then
# Get the name of the server that replied to the nslookup query.
   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

Vergleichen von Neustart und Failover

Wenn die Variable probefail einen anderen Wert als 0 (Erfolg) aufweist, fand unter dem nslookup-Befehl eine Zeitüberschreitung statt bzw. die Antwort kam von einem anderen Server als vom DNS des Beispieldienstes. 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 lautet, wird eine Meldung generiert, dass das Testsignal erfolgreich ist.

   if [ $probefail -ne 0 ]; then
         decide_restart_or_failover
   else
         logger -p ${SYSLOG_FACILITY}.err\
         -t [$SYSLOG_TAG]\
         "${ARGV0} Probe for resource HA-DNS successful"
   fi

Die decide_restart_or_failover()-Funktion verwendet ein Zeitfenster (Retry_interval) und einen Fehlerzähler (Retry_count), um zu ermitteln, ob DNS lokal neu gestartet werden soll oder um anzufordern, dass RGM den Datendienst an einen anderen Knoten umleitet. Mit dieser Funktion wird die folgende bedingte Logik implementiert. Die Code-Auflistung für decide_restart_or_failover() im Abschnitt Auflistung des PROBE-Programmcodes enthält den Code.

• Wenn dies der erste Fehlschlag ist, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert und der Zähler in der retries-Variablen 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, findet ein Failover an einen anderen Knoten statt. Wenn der Failover nicht erfolgreich ist, wird ein Fehler protokolliert und das Testsignalprogramm wird mit dem Status 1 (Fehler) beendet.

• Wenn das Zeitfenster noch nicht abgelaufen ist und der Wiederholversuchszähler nicht überschritten wurde, wird der Datendienst neu gestartet. Protokollieren Sie eine Fehlermeldung und setzen Sie den Zähler der retries-Variablen zurück.

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. Dies ist ein C-Programm, das sich im Verzeichnis (RT_basedir ) befindet.

• Die systemdefinierten Ressourceneigenschaften Retry_count und Retry_interval legen die Anzahl der Neustartversuche und das Zeitintervall fest, innerhalb dessen gezählt wird. Diese Eigenschaften werden standardmäßig auf zwei Versuche innerhalb eines Zeitraums von 5 Minuten (300 Sekunden) in der RTR-Datei zurückgesetzt, obwohl der Cluster-Administrator diese Werte ändern kann.

• Die restart_service()-Funktion wird aufgerufen, um zu versuchen, den Datendienst auf demselben Knoten neu zu starten. Weitere Informationen über diese Funktion finden Sie im nächsten Abschnitt Neustarten des Datendienstes.

• Die scha_control()-API-Funktion, mit der Option GIVEOVER, bringt die Ressourcengruppe, die den Beispieldatendienst enthält, offline und online an einem anderen Knoten wieder zurück.

Neustarten des Datendienstes

Die restart_service()-Funktion wird von decide_restart_or_failover () aufgerufen, um den Datendienst an demselben Knoten neu zu starten. Mit dieser Funktion wird die folgende Logik ausgeführt:

• Es wird ermittelt, ob der Datendienst weiterhin unter PMF registriert ist. Falls der Dienst weiterhin registriert ist, führt die Funktion die folgenden Aktionen aus:

  • Sie ruft den Stop-Methodennamen und den Stop_timeout-Wert für den Datendienst ab

  • Sie verwendet hatimerun zum Starten der Stop-Methode für den Datendienst und übergibt den Stop_timeout-Wert

  • Wenn der Datendienst erfolgreich angehalten wird, 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 und den Wert Start_timeout zu übergeben

• Wenn der Datendienst unter PMF nicht mehr registriert ist, hat der Datendienst wohl die maximale Anzahl der unter PMF zulässigen Wiederholversuche überschritten. Die scha_control()-Funktion wird mit der Option GIVEOVER aufgerufen, um einen Failover des Datendienstes an einen anderen Knoten durchzuführen.

function restart_service
{

        # To restart the data service, first verify that the 
        # data service itself is still registered under PMF.
        pmfadm -q $PMF_TAG
        if [[ $? -eq 0 ]]; then
                # Since the TAG for the data service is still registered under
                # PMF, first stop the data service and start it back up again.

                # Obtain the Stop method name and the STOP_TIMEOUT value for
                # this resource.
                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 method failed.”
                        return 1
                fi

                # Obtain the START method name and the START_TIMEOUT value for
                # this resource.
                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 method failed.”
                        return 1
                fi


        else
                # The absence of the TAG for the dataservice 
                # implies that the data service has already
                # exceeded the maximum retries allowed under PMF.
                # Therefore, do not attempt to restart the
                # data service again, but try to failover
                # to another node in the cluster.
                scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
                        -R $RESOURCE_NAME
        fi

        return 0
}

Testsignal-Beendigungsstatus

Das PROBE-Programm des Beispieldatendienstes wird mit einem Fehler beendet, wenn die Versuche für einen lokalen Neustart und einen Failover an einen anderen Knoten fehlschlagen. Dieses Programm protokolliert die Meldung Failover attempt failed.

Funktionsweise der Monitor_start-Methode

RGM ruft die Monitor_start-Methode auf, um die dns_probe -Methode zu starten, nachdem der Beispieldatendienst online gebracht wurde.

In diesem Abschnitt werden die wichtigsten Bestandteile der Monitor_start-Methode für die Beispielanwendung beschrieben. In diesem Abschnitt werden keine Funktionen beschrieben, die allen Rückmeldemethoden gemeinsam sind, wie die parse_args()-Funktion. In diesem Abschnitt wird ebenfalls nicht beschrieben, wie die syslog()-Funktion verwendet wird. Die gemeinsamen Funktionen werden im Abschnitt Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben.

Eine vollständige Liste der Monitor_start-Methode finden Sie unter Auflistung des Monitor_start-Methodencodes.

Funktionsweise der Monitor_start-Methode

Bei dieser Methode wird PMF (pmfadm) zum Starten des Testsignals verwendet.

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. Bei dieser Methode wird das Testsignal mithilfe der unendlichen Wiederholoption von pmfadm (-n -1, -t -1) gestartet. Dies bedeutet, dass PMF bei einem Fehlschlag des Testsignals versucht, dieses über einen endlosen Zeitraum unendlich häufig zu starten.

# Find where the probe program resides by obtaining the value of the
# RT_basedir property of the resource.
RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

# Start the probe for the data service under PMF. Use the infinite retries
# option to start the probe. Pass the resource name, type, and group to the
# probe program. 
pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \
   $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME

Funktionsweise der Monitor_stop-Methode

RGM ruft die Monitor_stop-Methode auf, um die Ausführung von dns_probe zu stoppen, wenn der Beispieldatendienst offline gebracht wird.

In diesem Abschnitt werden die wichtigsten Bestandteile der Monitor_stop-Methode für die Beispielanwendung beschrieben. In diesem Abschnitt werden keine Funktionen beschrieben, die allen Rückmeldemethoden gemeinsam sind, wie die parse_args()-Funktion. In diesem Abschnitt wird ebenfalls nicht beschrieben, wie die syslog()-Funktion verwendet wird. Die gemeinsamen Funktionen werden im Abschnitt Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben.

Eine vollständige Auflistung der Monitor_stop-Methode finden Sie unter Auflistung des Monitor_stop-Methodencodes.

Funktionsweise der Monitor_stop-Methode

Diese Methode verwendet PMF (pmfadm), um zu prüfen, ob das Testsignal ausgeführt wird. Ist dies der Fall, wird es gestoppt.

Stoppen des Monitors

Die Monitor_stop-Methode verwendet pmfadm -q, um festzustellen, ob das Testsignal läuft, und um 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.

---

Achtung –

Verwenden Sie auf jeden Fall das KILL-Signal mit pmfadm, um das Testsignal zu stoppen, und kein Signal, das maskiert werden kann, wie TERM. Andernfalls kann die Monitor_stop-Methode endlos hängen und schließlich eine Zeitüberschreitung stattfinden. Der Grund besteht darin, dass die PROBE-Methode scha_control() aufruft, wenn der Datendienst neu gestartet werden soll oder ein Failover des Datendienstes stattfinden soll. Wenn scha_control() Monitor_stop als Teil des Prozesses aufruft, der den Datendienst offline bringt, und wenn Monitor_stop ein Signal verwendet, das maskiert sein kann, hängt Monitor_stop und wartet, bis scha_control() vollständig ausgeführt wurde, und scha_control() hängt und wartet, bis Monitor_stop vollständig ausgeführt wurde.

---

# See if the monitor is running, and if so, kill it.
if pmfadm -q $PMF_TAG; then
   pmfadm -s $PMF_TAG KILL
   if [ $? -ne 0 ]; then
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Could not stop monitor for resource " \
            $RESOURCE_NAME
           exit 1
   else
         # could successfully stop the monitor. Log a message.
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Monitor for resource " $RESOURCE_NAME \
            " successfully stopped"
   fi
fi
exit 0

Monitor_stop-Beendigungsstatus

Die Monitor_stop-Methode protokolliert eine Fehlermeldung, wenn sie die PROBE-Methode nicht stoppen kann. RGM versetzt den Beispieldatendienst am Primärknoten in den Zustand MONITOR_FAILED, wodurch am Knoten Panik entstehen kann.

Monitor_stop darf erst beendet werden, wenn das Testsignal gestoppt wurde.

Funktionsweise der Monitor_check-Methode

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 an einen neuen Knoten auszuführen.

In diesem Abschnitt werden die wichtigsten Bestandteile der Monitor_check-Methode für die Beispielanwendung beschrieben. In diesem Abschnitt werden keine Funktionen beschrieben, die allen Rückmeldemethoden gemeinsam sind, wie die parse_args()-Funktion. In diesem Abschnitt wird ebenfalls nicht beschrieben, wie die syslog()-Funktion verwendet wird. Die gemeinsamen Funktionen werden im Abschnitt Bereitstellen gemeinsamer Funktionalität für alle Methoden beschrieben.

Eine vollständige Liste der Monitor_check-Methode finden Sie unter Auflistung des Monitor_check-Methodencodes.

Die Monitor_check-Methode muss so implementiert werden, dass sie nicht mit anderen gleichzeitig ausgeführten Methoden in Konflikt steht.

Die Monitor_check-Methode ruft die Validate-Methode auf, um zu prüfen, ob das DNS-Konfigurationsverzeichnis am neuen Knoten zur Verfügung steht. Die Confdir-Erweiterungseigenschaft verweist auf das DNS-Konfigurationsverzeichnis. Deshalb ruft Monitor_check den Pfad und den Namen für die Validate-Methode und den Wert von Confdir ab. Dieser Wert wird an Validate übergeben, wie in der folgenden Auflistung gezeigt.

# Obtain the full path for the Validate method from
# the RT_basedir property of the resource type.
RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME \
   -G $RESOURCEGROUP_NAMÈ

# Obtain the name of the Validate method for this resource.
VALIDATE_METHOD=`scha_resource_get -O Validate \
   -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ

# Obtain the value of the Confdir property in order to start the
# data service. Use the resource name and the resource group entered to
# obtain the Confdir value set at the time of adding the resource.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
 -G $RESOURCEGROUP_NAME Confdir`

# scha_resource_get returns the type as well as the value for extension
# properties. Use awk to get only the value of the extension property.
CONFIG_DIR=`echo $config_info | awk `{print $2}'`

# Call the validate method so that the dataservice can be failed over
# successfully to the new node.
$RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR

Im Abschnitt Funktionsweise der Validate-Methode finden Sie Informationen darüber, wie die Beispielanwendung die Eignung eines Knotens zum Hosten des Datendienstes überprüft.