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`

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.