test

Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Definieren eines Fehler-Monitors

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:

Testsignalprogramm

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 ist in PROBE-Programm enthalten.

Überblick über Testsignal

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.

Abrufen von Eigenschaftswerten

Dieses Programm benötigt die Werte der folgenden Eigenschaften:

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_NAMÈ

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_NAMÈ

RETRY_COUNT=`scha_resource_get -O RETRY_COUNT -R $RESOURCE_NAME
-G\
 $RESOURCEGROUP_NAMÈ

RETRY_INTERVAL=`scha_resource_get -O RETRY_INTERVAL -R $RESOURCE_NAME
-G\
 $RESOURCEGROUP_NAMÈ

RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G\
 $RESOURCEGROUP_NAMÈ

Hinweis –

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.

Überprüfen der Zuverlässigkeit des Dienstes

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:

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

Abwägen von Neustart und Failover

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

Neustarten des Datendienstes

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. 


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
}

Testsignal-Beendigungsstatus

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

Monitor_start-Methode

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.

Überblick über Monitor_start

Diese Methode verwendet PMF (pmfadm) zum Starten des Testsignals.

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

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.

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.

Überblick über Monitor_stop

Diese Methode verwendet PMF (pmfadm), um festzustellen, ob das Testsignal läuft und es gegebenenfalls zu stoppen.

Stoppen des Monitors

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

Achtung – Achtung –

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.

Monitor_stop-Beendigungsstatus

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.

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