test

Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Kapitel 5 Beispieldatendienst

Dieses Kapitel beschreibt einen Sun Cluster-Beispieldatendienst, HA-DNS, für die in.named-Anwendung. Der in.named-Dämon ist die Solaris-Implementierung von DNS (Domain Name Service). Der Beispieldatendienst zeigt, wie eine Anwendung mithilfe der Ressourcenverwaltungs-API hoch verfügbar gemacht wird.

Die Ressourcenverwaltungs-API unterstützt eine Shell-Skriptschnittstelle und eine C-Programmschnittstelle. Die Beispielanwendung in diesem Kapitel wurde unter Verwendung der Shell-Skriptschnittstelle geschrieben.

In diesem Kapitel finden Sie folgende Informationen:

Überblick über den Beispieldatendienst

Der Beispieldatendienst wird gestartet, gestoppt, neu gestartet und verschiebt die DNS-Anwendung zwischen den Knoten des Clusters als Reaktion auf Cluster-Ereignisse wie Verwaltungsaktionen, Anwendungsfehler oder Knotenfehler.

Der Anwendungsneustart wird von PMF (Process Monitor Facility) verwaltet. Wenn die Anwendungsausfälle den Fehlschlagzähler im Fehlschlagzeitfenster überschreiten, führt der Fehler-Monitor für die Ressourcengruppe mit der Anwendungsressource ein Failover auf einen anderen Knoten aus.

Im Beispieldatendienst sorgt die PROBE-Methode für die Fehlerüberwachung. Diese Methode verwendet den nslookup-Befehl, um sicherzustellen, dass die Anwendung fehlerfrei läuft. Wenn das Testsignal feststellt, dass ein DNS-Dienst hängt, wird versucht, den Fehler durch einen lokalen Neustart der DNS-Anwendung zu korrigieren. Wenn dadurch der Fehler nicht behoben werden kann und das Testsignal wiederholt Probleme mit dem Dienst feststellt, wird versucht, ein Failover des Datendienstes auf einen anderen Knoten im Cluster auszuführen.

Dieser Beispieldatendienst setzt sich aus folgenden Komponenten zusammen:

Definieren der Ressourcentyp-Registrierungsdatei

Die Ressourcentyp-Registrierungsdatei (RTR-Datei) in diesem Beispiel definiert die statische Konfiguration des DNS-Ressourcentyps. Ressourcen dieses Typs übernehmen die in der RTR-Datei definierten Eigenschaften.

Die Informationen in der RTR-Datei werden von RGM gelesen, wenn der Cluster-Verwalter den HA-DNS-Datendienst registriert.

Überblick über RTR-Dateien

Die RTR-Datei ist in einem klar definierten Format aufgebaut. In der Datei werden zuerst Ressourcentypeigenschaften definiert, dann systemdefinierte Ressourceneigenschaften und zuletzt Erweiterungseigenschaften. Weitere Informationen finden Sie in der Online-Dokumentation unter rt_reg(4) und unter Einstellen der Ressourcen- und Ressourcentypeigenschaften.

Dieser Abschnitt beschreibt die spezifischen Eigenschaften in der RTR-Beispieldatei. Verschiedene Teile der Datei werden aufgelistet. Eine vollständige Auflistung des Inhalts der RTR-Beispieldatei finden Sie unter Auflistung der Ressourcentyp-Registrierungsdatei.

Ressourcentypeigenschaften in der RTR-Beispieldatei

Die RTR-Beispieldatei beginnt mit Kommentaren, gefolgt von Ressourcentypeigenschaften zur Definition der HA-DNS-Konfiguration, wie in der folgenden Auflistung gezeigt. 

#
# Copyright (c) 1998-2004 Sun Microsystems, Inc.
# Alle Rechte vorbehalten.
#
# Registrierungsinformationen für DNS (Domain Name Service)
#

#pragma ident   “@(#)SUNW.sample   1.1   00/05/24 SMI”

RESOURCE_TYPE = “Beispiel”;
VENDOR_ID = SUNW;
RT_DESCRIPTION = “Domain Name Service auf Sun Cluster”;

RT_VERSION =”1.0”;
API_VERSION = 2;
FAILOVER = TRUE;

RT_BASEDIR=/opt/SUNWsample/bin;
PKGLIST = SUNWsample;

START         =   dns_svc_start;
STOP          =   dns_svc_stop;

VALIDATE      =   dns_validate;
UPDATE        =   dns_update;

MONITOR_START =   dns_monitor_start;
MONITOR_STOP  =   dns_monitor_stop;
MONITOR_CHECK =   dns_monitor_check;
Tipp –

Als ersten Eintrag in der RTR-Datei müssen Sie die Resource_type-Eigenschaft deklarieren. Andernfalls schlägt die Registrierung des Ressourcentyps fehl.

Hinweis –

RGM unterscheidet bei Eigenschaftsnamen nicht zwischen Groß- und Kleinschreibung. Die Konvention für Eigenschaften in von Sun gelieferten RTR-Dateien, mit Ausnahme der Methodennamen, ist Großschreibung des ersten Buchstabens und Kleinschreibung der restlichen Buchstaben des Namens. Methodennamen werden — ebenso wie Eigenschaftsattribute — ganz in Großbuchstaben geschrieben.

Es folgen einige Informationen zu diesen Eigenschaften.

Ressourcentypeigenschaften, die nicht in dieser RTR-Datei angegeben sind, wie Single_instance, Init_nodes und Installed_nodes, rufen ihre Standardwerte ab. Eine vollständige Liste der Ressourcentypeigenschaften mit den jeweiligen Standardwerten finden Sie in Tabelle A–1.

Der Cluster-Verwalter kann die für Ressourcentypeigenschaften in der RTR-Datei angegebenen Werte nicht ändern.

Ressourceneigenschaften in der RTR-Beispieldatei

Der Konvention gemäß werden Ressourceneigenschaften in der RTR-Datei nach den Ressourcentypeigenschaften deklariert. Ressourceneigenschaften sind sowohl die von Sun Cluster bereitgestellten systemdefinierten Eigenschaften als auch vom Benutzer definierte Erweiterungseigenschaften. Für jeden Typ können Sie eine Reihe von Eigenschaftsattributen angeben, die Sun Cluster vorgibt, wie zum Beispiel “minimum”, “maximum” und Standardwerte.

Systemdefinierte Eigenschaften in der RTR-Datei

Die folgende Auflistung zeigt die systemdefinierten Eigenschaften in der RTR-Beispieldatei. 

# Eine Liste von Ressourceneigenschaftsdeklarationen in Klammern
# folgt auf die Ressourcentypdeklarationen. Die Eigenschaftsnamensdeklaration
# muss das erste Attribut nach der geöffneten geschweiften Klammer für jeden Eintrag sein.

# Die <Methode>_timeout-Eigenschaften stellen den Wert in Sekunden ein,
# nachdem RGM schließt, dass der Methodenaufruf fehlgeschlagen ist.

# Der MIN-Wert für alle Methoden-Zeitüberschreitungen ist auf 60 Sekunden eingestellt.
# So können die Verwalter keine kürzen Zeitüberschreitungen einstellen, die keine
# Verbesserung der Switchover-/Failover-Leistung bewirken würden und unerwünschte RGM-
# Aktionen zur Folge haben könnten (falsche Failover, Knotenneustart oder Verschieben der
# Ressourcengruppe in den Zustand ERROR_STOP_FAILED, was einen Bedienereingriff
# erforderlich macht). Wenn zu kurze Methoden-Zeitüberschreitungen eingestellt werden,
# führt dies zu einem *Absinken* der Datendienstverfügbarkeit insgesamt.
{
   PROPERTY = Start_timeout;
   MIN=60;
   DEFAULT=300;
}

{
   PROPERTY = Stop_timeout;
   MIN=60;
   DEFAULT=300;
}
{
        PROPERTY = Validate_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Update_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Stop_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Thorough_Probe_Interval;
        MIN=1;
        MAX=3600;
        DEFAULT=60;
        TUNABLE = ANYTIME;
}

# Die Anzahl der Wiederholversuche, die innerhalb eines bestimmten Zeitraums
# ausgeführt werden, bevor geschlossen wird, dass die Anwendung auf diesem
# Knoten nicht erfolgreich gestartet werden kann.
{
        PROPERTY = Retry_Count;
        MIN=0;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME;
}

# Retry_Interval als Vielfaches von 60 einstellen, da der Wert von
# Sekunden in Minuten konvertiert und aufgerundet wird. Ein Wert von 50
# (Sekunden) wird zum Beispiel zu einer Minute aufgerundet. Diese Eigenschaft
# verwenden, um die Anzahl der Wiederholversuche festzustellen (Retry_Count).
{
        PROPERTY = Retry_Interval;
        MIN=60;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

{
        PROPERTY = Network_resources_used;
        TUNABLE = AT_CREATION;
        DEFAULT = ““;
}

Sun Cluster stellt zwar die systemdefinierten Eigenschaften bereit. Sie können jedoch mithilfe der Ressourceneigenschaftsattribute andere Standardwerte einstellen. Eine vollständige Auflistung der Attribute, die für Ressourceneigenschaften zur Verfügung stehen, finden Sie unter Ressourceneigenschaftsattribute.

Beachten Sie folgende Aspekte der systemdefinierten Ressourceneigenschaften in der RTR-Beispieldatei:

Erweiterungseigenschaften in der RTR-Datei

Am Ende der RTR-Datei befinden sich die Erweiterungseigenschaften, die in der folgenden Auflistung gezeigt werden. 

# Erweiterungseigenschaften

# Der Cluster-Verwalter muss den Wert dieser Eigenschaft so einstellen, dass
# er auf das Verzeichnis zeigt, das die von der Anwendung verwendeten
# Konfigurationsdateien enthält. Für diese Anwendung, DNS, wird der Pfad der
# DNS-Konfigurationsdatei auf PXFS angegeben (in der Regel named.conf).
{
   PROPERTY = Confdir;
   EXTENSION;
   STRING;
   TUNABLE = AT_CREATION;
   DESCRIPTION = “Pfad zum Konfigurationsverzeichnis”;
}

# Zeitüberschreitungswert in Sekunden, bevor das Testsignal als fehlgeschlagen
# deklariert wird.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Zeitüberschreitungswert für das Testsignal (Sekunden)”;
}

Die RTR-Beispieldatei definiert zwei Erweiterungseigenschaften, Confdir und Probe_timeout. Confdir gibt den Pfad zum DNS-Konfigurationsverzeichnis an. Dieses Verzeichnis enthält die in.named-Datei, die der DNS für einen erfolgreichen Betrieb benötigt. Die Start- und Validate-Methoden des Beispieldatendienstes verwenden diese Eigenschaft, um vor dem Starten von DNS zu überprüfen, ob auf das Konfigurationsverzeichnis und die in.named-Datei zugegriffen werden kann.

Nach Konfigurieren des Datendienstes überprüft die Validate-Methode, ob das neue Verzeichnis zugänglich ist.

Bei der PROBE-Methode des Beispieldatendienstes handelt es sich nicht um eine Sun Cluster-Rückmeldemethode, sondern um eine benutzerdefinierte Methode. Daher stellt Sun Cluster keine Probe_timeout-Eigenschaft für sie bereit. Der Entwickler hat eine Erweiterungseigenschaft in der RTR-Datei definiert, mit deren Hilfe der Cluster-Verwalter einen Probe_timeout-Wert konfigurieren kann.

Bereitstellen gemeinsamer Funktionalität für alle Methoden

Dieser Abschnitt beschreibt die Funktionalität, die in allen Rückmeldemethoden des Beispieldatendienstes verwendet wird:

Identifizieren des Befehlsinterpreters und Exportieren des Pfads

Die erste Zeile eines Shell-Skripts muss den Befehlsinterpreter identifizieren. Jedes der Methodenskripts im Beispieldatendienst identifiziert den Befehlsinterpreter wie folgt:


#!/bin/ksh

Alle Methoden-Skripts in der Beispielanwendung exportieren den Pfad zu den Sun Cluster-Binärdateien und -Bibliotheken, anstatt sich auf die PATH-Einstellungen der Benutzer zu verlassen. 


#######################################################################
# MAIN
#######################################################################

export PATH=/bin:/usr/bin:/usr/cluster/bin:/usr/sbin:/usr/proc/bin:$PATH

Deklarieren der Variablen PMF_TAG und SYSLOG_TAG

Alle Methoden-Skripts mit Ausnahme von Validate verwenden pmfadm zum Starten bzw. Stoppen des Datendienstes oder des Monitors, indem sie den Ressourcennamen übergeben. Jedes Skript definiert eine Variable, PMF_TAG, die an pmfadm übergeben werden kann, um entweder den Datendienst oder den Monitor zu identifizieren.

Ebenso verwendet jedes Methodenskript den logger-Befehl, um Meldungen im Systemprotokoll zu protokollieren. Jedes Skript definiert eine Variable, SYSLOG_TAG, die mit der Option -t an logger übergeben werden kann, um den Ressourcentyp, die Ressourcengruppe und den Ressourcennamen der Ressource, für die eine Meldung protokolliert wird, zu identifizieren.

Alle Methoden definieren SYSLOG_TAG auf die gleiche Art und Weise, wie im folgenden Beispiel gezeigt. Die dns_probe-, dns_svc_start-, dns_svc_stop- und dns_monitor_check-Methoden definieren PMF_TAG wie folgt, wobei die Verwendung von pmfadm und logger der dns_svc_stop-Methode entnommen wird: 


#########################################################################
# MAIN
#########################################################################

PMF_TAG=$RESOURCE_NAME.named

SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME

   # SIGTERM-Signal an den Datendienst senden und  80% des
   # gesamten Zeitüberschreitungswerts warten.
   pmfadm -s $PMF_TAG.named -w $SMOOTH_TIMEOUT TERM
   if [ $? -ne 0 ]; then
      logger -p ${SYSLOG_FACILITY}.info \
          -t [$SYSLOG_TAG] \
          “${ARGV0} Failed to stop HA-DNS with SIGTERM; Retry with \
           SIGKILL”

Die dns_monitor_start-, dns_monitor_stop- und dns_update-Methoden definieren PMF_TAG wie folgt, wobei die Verwendung von pmfadm der dns_monitor_stop-Methode entnommen wird: 


#########################################################################
# MAIN
#########################################################################

PMF_TAG=$RESOURCE_NAME.monitor
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
...

# Feststellen, ob der Monitor läuft, und ggf. Beenden erzwingen.
if pmfadm -q $PMF_TAG.monitor; then
   pmfadm -s $PMF_TAG.monitor KILL

Analysieren der Funktionsargumente

RGM ruft alle Rückmeldemethoden — mit Ausnahme der Validate-Methode — folgendermaßen auf. 


Methodenname -R Ressourcenname -T Ressourcentypname -G Ressourcengruppenname

Der Methodenname ist der Pfadname des Programms, das die Rückmeldemethode implementiert. Ein Datendienst gibt den Pfadnamen für jede Methode in der RTR-Datei an. Diese Pfadnamen beziehen sich auf das Verzeichnis, das ebenfalls in der RTR-Datei von der Rt_basedir-Eigenschaft angegeben wird. Zum Beispiel werden das Basisverzeichnis und die Methodennamen in der RTR-Datei des Beispieldatendienstes wie folgt angegeben. 


RT_BASEDIR=/opt/SUNWsample/bin;
START = dns_svc_start;
STOP =  dns_svc_stop;
...

Alle Rückmeldemethodenargumente werden als Werte mit Flags übergeben, wobei -R den Namen der Ressourceninstanz, -T den Ressourcentyp und -G die Gruppe angibt, in der die Ressource konfiguriert wird. Weitere Informationen zu Rückmeldemethoden finden Sie in der Online-Dokumentation unter rt_callbacks(1HA).

Hinweis –

Die Validate-Methode wird mit zusätzlichen Argumenten aufgerufen, das heißt, mit den Eigenschaftswerten der Ressource und Ressourcengruppe, in denen sie aufgerufen wird. Weitere Informationen finden Sie unter Bearbeiten von Eigenschaftsaktualisierungen.

Jede Rückmeldemethode benötigt eine Funktion zum Analysieren der Argumente, die ihr übergeben werden. Da an alle Rückmeldemethoden die gleichen Argumente übergeben werden, stellt der Datendienst eine einzige Analysefunktion bereit, die für alle Rückmeldungen in der Anwendung eingesetzt wird.

Im Folgenden wird die parse_args()-Funktion gezeigt, die für alle Rückmeldemethoden in der Beispielanwendung verwendet wird. 


#########################################################################
# Programmargumente analysieren.
#
function parse_args # [args ...]
{
      typeset opt

      while getopts 'R:G:T:' opt
      do
             case "$opt" in
             R)
                  # Name der DNS-Ressource.
                  RESOURCE_NAME=$OPTARG
                  ;;
             G)
                  # Name der Ressourcengruppe, in der die Ressource
                  # konfiguriert ist.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
             T)
                  # Name des Ressourcentyps.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
             *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                  "FEHLER: Option $OPTARG unbekannt"
                  exit 1
                      ;;
             esac
    done
}

Hinweis –

Die PROBE-Methode in der Beispielanwendung ist zwar benutzerdefiniert, also keine Sun Cluster-Rückmeldemethode, wird jedoch mit den gleichen Argumenten wie die Rückmeldemethoden aufgerufen. Daher enthält diese Methode genau die gleiche Analysefunktion wie die anderen Rückmeldemethoden.

Die Analysefunktion wird in MAIN wie folgt aufgerufen: 


parse_args “$@”

Generieren von Fehlermeldungen

Für Rückmeldemethoden wird empfohlen, syslog für die Ausgabe von Fehlermeldungen an die Endbenutzer zu verwenden. Alle Rückmeldemethoden im Beispieldatendienst verwenden die Funktion scha_cluster_get(), um die Nummer des als Cluster-Protokoll verwendeten syslog wie folgt abzurufen: 


SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`

Der Wert wird in einer Shell-Variablen, SYSLOG_FACILITY, gespeichert und kann im logger-Befehl verwendet werden, um Meldungen im Cluster-Protokoll zu protokollieren. So ruft zum Beispiel die Start-Methode im Beispieldatendienst syslog ab und protokolliert eine Meldung, dass der Datendienst gestartet wurde: 


SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`
...

if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS erfolgreich gestartet"
fi

Weitere Informationen finden Sie in der Online-Dokumentation unter scha_cluster_get(1HA).

Abrufen von Eigenschaftsinformationen

Die meisten Rückmeldemethoden benötigen Informationen über die Ressourcen- und Ressourcentypeigenschaften des Datendienstes. Die API stellt zu diesem Zweck die scha_resource_get()-Funktion bereit.

Es stehen zwei Arten von Ressourceneigenschaften zur Verfügung: systemdefinierte Eigenschaften und Erweiterungseigenschaften. Systemdefinierte Eigenschaften sind vordefiniert, während Sie Erweiterungseigenschaften in der RTR-Datei definieren.

Wenn Sie scha_resource_get() zum Abrufen des Wertes einer systemdefinierten Eigenschaft verwenden, geben Sie den Eigenschaftsnamen mit dem -O-Parameter an. Der Befehl gibt nur den Wert der Eigenschaft zurück. Im Beispieldatendienst benötigt zum Beispiel die Monitor_start-Methode den Speicherort des Testsignalprogramms, um es zu starten. Das Testsignalprogramm residiert im Basisverzeichnis für den Datendienst, auf das die RT_BASEDIR-Eigenschaft zeigt. Daher ruft die Monitor_start-Methode den Wert von RT_BASEDIR ab und legt ihn in der RT_BASEDIR-Variablen ab:


RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

Für Erweiterungseigenschaften müssen Sie mit dem -O-Parameter angeben, dass es sich um eine Erweiterungseigenschaft handelt, und den Eigenschaftsnamen als letzten Parameter angeben. Für Erweiterungseigenschaften gibt der Befehl sowohl den Typ als auch den Wert der Eigenschaft an. Im Beispieldatendienst ruft das Testsignalprogramm zum Beispiel den Typ und den Wert der probe_timeout-Erweiterungseigenschaft ab und verwendet dann awk, um nur den Wert in der PROBE_TIMEOUT.-Shell-Variablen abzulegen: 


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}'`

Steuern des Datendienstes

Ein Datendienst muss eine Start- oder Prenet_start-Methode bereitstellen, um den Anwendungsdämon auf dem Cluster zu aktivieren, sowie eine Stop- oder Postnet_stop-Methode zum Stoppen des Anwendungsdämons auf dem Cluster. Der Beispieldatendienst implementiert eine Start- und eine Stop-Methode. Bestimmen der zu verwendenden Start- und Stop-Methoden enthält Informationen darüber, in welchen Fällen möglicherweise die Verwendung von Prenet_start und Postnet_stop vorzuziehen wäre.

Start-Methode

RGM ruft die Start-Methode auf einem Cluster-Knoten auf, wenn die Ressourcengruppe, die den Datendienst enthält, auf diesem Knoten online gebracht wird bzw. wenn die Ressourcengruppe bereits online ist und die Ressource aktiviert wird. In der Beispielanwendung aktiviert die Start-Methode den in.named (DNS)-Dämon auf diesem Knoten.

Dieser Abschnitt beschreibt die Hauptteile der 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 Start-Methode ist in Start-Methode enthalten.

Überblick über Start

Vor dem Versuch, DNS zu starten, überprüft die Start-Methode des Beispieldatendienstes, ob das Konfigurationsverzeichnis und die Konfigurationsdatei (named.conf) zugänglich und verfügbar sind. Die Informationen in named.conf sind für einen erfolgreichen DNS-Betrieb entscheidend.

Diese Rückmeldemethode verwendet PMF (pmfadm ) zum Starten des DNS-Dämons (in.named). Wenn DNS abstürzt oder nicht startet, versucht PMF eine vorgeschriebene Anzahl von Malen, den Dienst während eines festgelegten Zeitintervalls zu starten. Die Anzahl der Wiederholungen und das Intervall sind durch Eigenschaften in der RTR-Datei des Datendienstes angegeben.

Überprüfen der Konfiguration

DNS benötigt für die Ausführung Informationen aus der named.conf-Datei im Konfigurationsverzeichnis. Daher führt die Start-Methode einige Gesundheits-Checks aus, um zu überprüfen, ob auf das Verzeichnis und die Datei zugegriffen werden kann, bevor DNS gestartet wird.

Die Confdir-Erweiterungseigenschaft stellt den Pfad zum Konfigurationsverzeichnis bereit. Die Eigenschaft selbst ist in der RTR-Datei definiert. Den Speicherort gibt jedoch der Cluster-Verwalter beim Konfigurieren des Datendienstes an.

Im Beispieldatendienst ruft die Start-Methode den Speicherort des Konfigurationsverzeichnisses mithilfe der Funktion scha_resource_get() ab.

Hinweis –

Da Confdir eine Erweiterungseigenschaft ist, gibt scha_resource_get() sowohl den Typ als auch den Wert zurück. Der awk-Befehl ruft lediglich den Wert ab und legt ihn in einer Shell-Variablen ab, CONFIG_DIR. 


# Den Wert von Confdir suchen, den der Cluster-Verwalter beim Hinzufügen
# der Ressource eingestellt hat.
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" für die
# Erweiterungseigenschaften zurück. Nur den Wert der Erweiterungseigenschaft abrufen.
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

Die Start-Methode verwendet dann den Wert von CONFIG_DIR, um zu überprüfen, ob das auf das Verzeichnis zugegriffen werden kann. Wenn kein Zugriff möglich ist, protokolliert Start eine Fehlermeldung und wird mit Fehlerstatus beendet. Weitere Informationen finden Sie unter Start-Beendigungsstatus. 


# Prüfen, ob Zugriff auf $CONFIG_DIR möglich ist.
if [ ! -d $CONFIG_DIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Verzeichnis $CONFIG_DIR fehlt oder ist nicht eingehängt"
   exit 1
fi

Vor dem Starten des Anwendungsdämons führt diese Methode eine abschließende Prüfung durch, um zu überprüfen, ob die named.conf-Datei vorhanden ist. Wenn sie nicht vorhanden ist, protokolliert Start eine Fehlermeldung und wird im Fehlerstatus beendet. 


# Wechsel zum $CONFIG_DIR-Verzeichnis, falls die
# Datendateien relative Pfadnamen enthalten.
cd $CONFIG_DIR

# Prüfen, ob die named.conf-Datei im $CONFIG_DIR-Verzeichnis vorhanden ist
if [ ! -s named.conf ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Datei $CONFIG_DIR/named.conf fehlt oder ist leer"
   exit 1
fi

Starten der Anwendung

Diese Methode verwendet PMF (pmfadm) zum Starten der Anwendung. Über den pmfadm-Befehl können Sie die Anzahl der Male einstellen, die eine Anwendung während eines angegebenen Zeitraums neu gestartet wird. Die RTR-Datei enthält dafür zwei Eigenschaften: Retry_count gibt die Anzahl von Malen an, für die der Neustart der Anwendung versucht wird, und Retry_interval den Zeitraum, in dem die Versuche stattfinden sollen.

Die Start-Methode ruft die Werte für Retry_count und Retry_interval mithilfe der Funktion scha_resource_get() ab und speichert sie in Shell-Variablen. Dann werden diese Werte an pmfadm übergeben. Dabei werden die Optionen -n und -t verwendet. 


# Wert für Wiederholversuchszähler aus der RTR-Datei abrufen.
RETRY_CNT=`scha_resource_get -O Retry_Count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Wert für das Wiederholungsintervall aus der RTR-Datei abrufen. Der
# Wert ist in Sekunden angegeben und muss für die Übergabe an pmfadm in Minuten
# konvertiert werden. Beachten Sie, dass die Konversion aufrundet; 50 Sekunden werden
# zu einer Minute aufgerundet.
((RETRY_INTRVAL=`scha_resource_get -O Retry_Interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# in.named-Dämon unter PMF-Steuerung starten. Abstürzen lassen und bis zu
# $RETRY_COUNT Male in einem Zeitraum von $RETRY_INTERVAL abstürzen lassen
# und neu starten. Wenn er öfter abstürzt, versucht PMF keinen Neustart mehr.
# Wenn unter der Markierung <$PMF_TAG> bereits ein Prozess registriert ist, sendet PMF
# eine Warnmeldung, dass der Prozess bereits läuft.
pmfadm -c $PMF_TAAG -n $RETRY_CNT -t $RETRY_INTRVAL \
    /usr/sbin/in.named -c named.conf

# Meldung protokollieren, dass HA-DNS gestartet wurde.
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS erfolgreich gestartet"
fi
exit 0

Start-Beendigungsstatus

Eine Start-Methode darf erst dann mit Erfolg beendet werden, wenn die zugrunde liegende Anwendung auch tatsächlich läuft und verfügbar ist, vor allem dann, wenn andere Datendienste von ihr abhängen. Eine Möglichkeit zum Überprüfen des Erfolgs besteht darin, ein Testsignal an die Anwendung zu senden, um festzustellen, ob sie läuft, bevor die Start-Methode beendet wird. Vergewissern Sie sich bei komplexen Anwendungen wie zum Beispiel Datenbanken, dass der Wert für die Start_timeout-Eigenschaft in der RTR-Datei ausreichend hoch eingestellt wird, damit die Anwendung genügend Zeit zum Initialisieren und Wiederherstellen nach einem Absturz hat.

Hinweis –

Da die Anwendungsressource (DNS) im Beispieldatendienst schnell startet, überprüft der Beispieldatendienst nicht, ob sie läuft, bevor die Methode mit Erfolg beendet wird.

Wenn diese Methode DNS nicht starten kann und mit einem Fehlerstatus beendet wird, prüft RGM die Failover_mode-Eigenschaft, die die Reaktion auf den Fehlerstatus festlegt. Der Beispieldatendienst stellt die Failover_mode-Eigenschaft nicht ausdrücklich ein. Daher hat sie den Standardwert NONE, es sei denn, der Cluster-Verwalter hat diesen Standardwert übersteuert und einen anderen Wert angegeben. In diesem Fall ist die einzige Aufgabe von RGM, den Zustand des Datendienstes einzustellen. Ein Bedienereingriff ist erforderlich, um auf demselben Knoten neu zu starten oder ein Failover auf einen anderen Knoten auszuführen.

Stop-Methode

Die Stop-Methode wird auf einem Cluster-Knoten aufgerufen, wenn die Ressourcengruppe mit der HA-DNS-Ressource auf diesem Knoten offline genommen wird bzw. wenn die Ressourcengruppe online bleibt, jedoch die Ressource deaktiviert wird. Diese Methode stoppt den in.named (DNS)-Dämon auf dem Knoten.

Dieser Abschnitt beschreibt die Hauptteile der 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 Stop-Methode ist in Stop-Methode enthalten.

Überblick über Stop

Zwei Punkte müssen beim Stoppen des Datendienstes vor allem beachtet werden. Als Erstes muss für ein ordnungsgemäßes Herunterfahren gesorgt werden. Das Senden eines SIGTERM-Signals über pmfadm ist die beste Möglichkeit, ein ordnungsgemäßes Herunterfahren zu erzielen.

Als Zweites muss sichergestellt werden, dass der Datendienst wirklich gestoppt wird, um zu vermeiden, dass er in den Stop_failed-Zustand versetzt wird. Die beste Möglichkeit hierzu ist das Senden eines SIGKILL-Signals über pmfadm.

Die Stop-Methode im Beispieldatendienst berücksichtigt diese beiden Punkte. Sie sendet zunächst ein SIGTERM-Signal. Wenn dieses Signal den Datendienst nicht stoppen kann, sendet die Methode ein SIGKILL-Signal.

Bevor versucht wird, DNS zu stoppen, überprüft die Stop-Methode, ob der Prozess tatsächlich läuft. Wenn der Prozess läuft, verwendet Stop PMF (pmfadm), um ihn zu stoppen.

Diese Stop-Methode ist garantiert idempotent. Auch wenn RGM eine Stop-Methode nicht zum zweiten Mal aufrufen sollte, ohne zuvor den Datendienst über einen Aufruf der entsprechenden Start-Methode gestartet zu haben, kann eine Stop-Methode für eine Ressource aufgerufen werden, obwohl diese nie gestartet wurde oder von selbst ausfiel. Diese Stop-Methode wird also mit Erfolg beendet, selbst wenn DNS nicht läuft.

Stoppen der Anwendung

Die Stop-Methode bietet zwei Möglichkeiten zum Stoppen des Datendienstes: eine geordnete oder weiche Art, bei der ein SIGTERM-Signal über pmfadm verwendet wird, und eine plötzliche oder harte Art, bei der ein SIGKILL-Signal eingesetzt wird. Die Stop-Methode ruft den Stop_timeout-Wert ab (den Zeitraum, in dem die Stop-Methode einen Wert zurückgeben muss). Stop weist dann 80% dieser Zeit dem weichen Stoppvorgang und 15% dem harten Stoppvorgang zu (5% werden zurückgehalten), wie im folgenden Beispiel gezeigt. 

STOP_TIMEOUT=`scha_resource_get -O STOP_TIMEOUT -R $RESOURCE_NAME
\

-G $RESOURCEGROUP_NAMÈ
((SMOOTH_TIMEOUT=$STOP_TIMEOUT * 80/100))

((HARD_TIMEOUT=$STOP_TIMEOUT * 15/100))

Die Stop-Methode verwendet pmfadm -q, um zu überprüfen, ob der DNS-Dämon läuft. Ist das der Fall, sendet Stop zunächst mit pmfadm -s ein TERM-Signal zum Beenden des DNS-Prozesses. Wenn dieses Signal den Prozess nach Ablauf von 80% des Zeitüberschreitungswertes nicht beenden konnte, sendet Stop ein SIGKILL-Signal. Wenn auch dieses Signal den Prozess nicht innerhalb von 15% des Zeitüberschreitungswertes beenden kann, protokolliert die Methode eine Fehlermeldung und wird mit Fehlerstatus beendet.

Wenn pmfadm den Prozess beendet, protokolliert die Methode eine Meldung, die besagt, dass der Prozess gestoppt wurde, und wird mit Erfolg beendet.

Wenn der DNS-Prozess nicht läuft, protokolliert die Methode eine diesbezügliche Meldung und wird dennoch mit Erfolg beendet. Das folgende Codebeispiel zeigt, wie Stop den pmfadm-Befehl zum Stoppen des DNS-Prozesses einsetzt. 

# Prüfen, ob if in.named läuft. Falls ja, Beenden erzwingen.
if pmfadm -q $PMF_TAG; then
   # SIGTERM-Signal an den Datendienst senden und 80% des gesamten
   # Zeitüberschreitungswertes warten.
   pmfadm -s $RESOURCE_NAME.named -w $SMOOTH_TIMEOUT TERM
   if [ $? -ne 0 ]; then
      logger -p ${SYSLOG_FACILITY}.err \
          -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
          “${ARGV0} HA-DNS konnte nicht mit SIGTERM gestoppt werden; Mit \
           SIGKILL erneut versuchen”

      # Da der Datendienst mit einem SIGTERM-Signal nicht gestoppt wurde, jetzt
      # SIGKILL verwenden und für weitere 15% des Zeitüberschreitungswertes warten.
      pmfadm -s $PMF_TAG -w $HARD_TIMEOUT KILL
      if [ $? -ne 0 ]; then
          logger -p ${SYSLOG_FACILITY}.err \
          -t [$SYSLOG_TAG]
          “${ARGV0} HA-DNS konnte nicht gestoppt werden; Beenden NICHT ERFOLGREICH”

          exit 1
      fi
fi
else
   # Der Datendienst läuft nun nicht. Meldung protokollieren und mit
   # Erfolg beenden.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “HA-DNS ist nicht gestartet”

   # Auch wenn HA-DNS nicht läuft, mit Erfolg beenden, damit die Datendienst-
   # ressource nicht in den STOP_FAILED-Zustand versetzt wird.

   exit 0

fi

# DNS konnte erfolgreich gestoppt werden. Meldung protokollieren und mit Erfolg beenden.
logger -p ${SYSLOG_FACILITY}.err \
    -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME]
\
    “HA-DNS erfolgreich gestoppt”
exit 0

Stop-Beendigungsstatus

Eine Stop-Methode darf erst dann mit Erfolg beendet werden, wenn die zugrundeliegende Anwendung auch tatsächlich gestoppt wurde, vor allem wenn andere Datendienste von ihr abhängen. Andernfalls können Daten beschädigt werden.

Vergewissern Sie sich für komplexe Anwendungen wie zum Beispiel Datenbanken, dass der Wert für die Stop_timeout-Eigenschaft in der RTR-Datei ausreichend hoch eingestellt wird, damit die Anwendung beim Stoppvorgang genügend Zeit zum Bereinigen hat.

Wenn diese Methode DNS nicht stoppen kann und mit Fehlerstatus beendet wird, prüft RGM die Failover_mode-Eigenschaft, die festlegt, welche Reaktion nun erfolgt. Der Beispieldatendienst stellt die Failover_mode-Eigenschaft nicht explizit ein. Daher hat sie den Standardwert NONE, es sei denn, der Cluster-Verwalter hat diesen übersteuert und einen anderen Wert angegeben. In diesem Fall ist die einzige Aufgabe von RGM, den Zustand des Datendienstes auf Stop_failed einzustellen. Ein Bedienereingriff ist erforderlich, um das Stoppen der Anwendung zu erzwingen und den Stop_failed-Zustand aufzuheben.

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.

Bearbeiten von Eigenschaftsaktualisierungen

Der Beispieldatendienst implementiert die Methoden Validate und Update, um die Eigenschaftsaktualisierung durch einen Cluster-Verwalter bearbeiten zu können.

Validate-Methode

RGM ruft die Validate-Methode auf, wenn eine Ressource erstellt wird und wenn die Eigenschaften einer Ressource bzw. deren Gruppe durch einen Verwaltungsbefehl aktualisiert werden. RGM ruft Validate auf, bevor die Erstellung bzw. Aktualisierung angewendet wird. Ein Fehlerbeendigungscode der Methode auf einem Knoten führt zum Abbruch der Erstellung bzw. Aktualisierung.

RGM ruft Validate nur dann auf, wenn Ressourcen- bzw. Gruppeneigenschaften über eine Verwaltungsaktion geändert werden, und nicht, wenn RGM Eigenschaften einstellt oder wenn ein Monitor die Ressourceneigenschaften Status und Status_msg einstellt.

Hinweis –

Die Monitor_check-Methode ruft auch ausdrücklich immer dann die Validate-Methode auf, wenn die PROBE-Methode versucht, ein Failover für den Datendienst auf einen neuen Knoten auszuführen.

Überblick über Validate

RGM ruft Validate mit zusätzlichen Argumenten zu denjenigen auf, die von anderen Methoden übergeben wurden, einschließlich der aktualisierten Eigenschaften und Werte. Daher muss diese Methode im Beispieldatendienst eine andere parse_args()-Funktion implementieren, um die zusätzlichen Argumente zu bearbeiten.

Die Validate-Methode im Beispieldatendienst überprüft eine einzige Eigenschaft, die Confdir-Erweiterungseigenschaft. Diese Eigenschaft zeigt auf das DNS-Konfigurationsverzeichnis, das für einen erfolgreichen DNS-Betrieb entscheidend ist.

Hinweis –

Da das Konfigurationsverzeichnis nicht geändert werden kann, während DNS läuft, wird die Confdir-Eigenschaft in der RTR-Datei als TUNABLE = AT_CREATION deklariert. Daher wird die Validate-Methode nie aufgerufen, um die Confdir-Eigenschaft nach einer Aktualisierung zu überprüfen, sondern nur bei Erstellung der Datendienstressource.

Wenn Confdir eine der Eigenschaften ist, die RGM an Validate übergibt, ruft die parse_args()-Funktion deren Wert ab und speichert ihn. Validate überprüft daraufhin, ob auf das Verzeichnis, auf das der neue Wert von Confdir zeigt, zugegriffen werden kann, und ob die named.conf-Datei in diesem Verzeichnis vorhanden ist und Daten enthält.

Wenn die parse_args()-Funktion den Wert von Confdir nicht aus den von RGM übergebenen Befehlszeilenargumenten abrufen kann, versucht Validate dennoch, die Confdir-Eigenschaft zu validieren. Validate verwendet scha_resource_get(), um den Wert von Confdir aus der statischen Konfiguration abzurufen. Dann führt die Funktion die gleichen Prüfungen aus, um zu überprüfen, ob auf das Konfigurationsverzeichnis zugegriffen werden kann und keine leere named.conf-Datei enthält.

Wenn Validate mit Fehlschlag beendet wird, schlägt die Aktualisierung bzw. Erstellung aller Eigenschaften fehl, nicht nur diejenige von Confdir.

Analysefunktion der Validate-Methode

RGM übergibt an die Validate-Methode einen anderen Satz Parameter als an die anderen Rückmeldemethoden. Daher benötigt Validate eine andere Funktion für die Argumentenanalyse als die anderen Methoden. In der Online-Dokumentation unter rt_callbacks(1HA) finden Sie weitere Informationen zu den an Validate und die anderen Rückmeldemethoden übergebenen Parametern. Im Folgenden wird die Validate parse_args()-Funktion gezeigt. 


#########################################################################
# Validate-Argumente analysieren.
#
function parse_args # [args...]
{

   typeset opt
   while getopts 'cur:x:g:R:T:G:' opt
   do
         case "$opt" in
         R)
                  # Name der DNS-Ressource.
                  RESOURCE_NAME=$OPTARG
                  ;;
         G)
                  # Name der Ressourcengruppe, in der die
                  # Ressource konfiguriert ist.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
         T)
                  # Name des Ressourcentyps.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
         r)
                  # Die Methode greift auf keine systemdefinierten
                  # Eigenschaften zu, so dass diese Option nicht besteht
                  ;;
         g)
                  # Die Methode greift auf keine Ressourcengruppen-
                  # eigenschaften zu, so dass diese Option nicht besteht
                  ;;
         c)
                  # Gibt an, dass die Validate-Methode bei Erstellen der Ressource
                  # aufgerufen wird, so dass dieses Flag nicht besteht.
                  ;;
         u)
                  # Gibt die Aktualisierung einer Eigenschaft an, wenn die Ressource
                  # bereits vorhanden ist. Wenn die Confdir-Eigenschaft aktualisiert wird,
                  # sollte Confdir in den Befehlszeilenargumenten stehen. Andernfalls
                  # muss die Methode ausdrücklich mit scha_resource_get danach
                  # suchen.
                  UPDATE_PROPERTY=1
                  ;;
         x)
                  # Erweiterungseigenschaftsliste. Eigenschafts- und Wertepaare mit
                  # "=" als Trennzeichen voneinander trennen.
                  PROPERTY=`echo $OPTARG | awk -F= '{print $1}'`
                  VAL=`echo $OPTARG | awk -F= '{print $2}'`
                  # Wenn die Confdir-Erweiterungseigenschaft an der Befehls-
                  # zeile gefunden wird, Wert festhalten.
                  if [ $PROPERTY == "Confdir" ]; then
                           CONFDIR=$VAL
                           CONFDIR_FOUND=1
                  fi
                  ;;
         *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$SYSLOG_TAG] \
                  "FEHLER: Option $OPTARG unbekannt"
                  exit 1
                  ;;
         esac
   done
}

Genau wie die parse_args()-Funktion für andere Methoden verfügt diese Funktion über ein Flag (R) zum Erfassen des Ressourcennamens, (G) zum Erfassen des Ressourcengruppennamens und (T) zum Erfassen des Ressourcentyps, die von RGM übergeben werden.

Das r-Flag (für systemdefinierte Eigenschaften), g-Flag (für Ressourcengruppeneigenschaften) und das c-Flag (das angibt, dass die Validierung bei Ressourcenerstellung stattfindet) werden ignoriert, da diese Methode aufgerufen wird, um eine Erweiterungseigenschaft bei Aktualisierung der Ressource zu validieren.

Das u-Flag stellt den Wert der UPDATE_PROPERTY-Shell-Variablen auf 1 (TRUE) ein. Das x-Flag erfasst die Namen und Werte der aktualisierten Eigenschaften. Wenn Confdir eine der aktualisierten Eigenschaften ist, wird ihr Wert in der CONFDIR-Shell-Variablen abgelegt, und die Variable CONFDIR_FOUND wird auf 1 (TRUE) eingestellt.

Validieren von Confdir

In der MAIN-Funktion setzt Validate zunächst die CONFDIR-Variable auf die leere Zeichenkette sowie UPDATE_PROPERTY und CONFDIR_FOUND auf 0. 


CONFDIR=""
UPDATE_PROPERTY=0
CONFDIR_FOUND=0

Anschließend ruft Validate die parse_args()-Funktion auf, um die von RGM übergebenen Argumente zu analysieren. 


parse_args “$@”

Dann prüft Validate, ob Validate als Ergebnis der Aktualisierung von Eigenschaften aufgerufen wird und ob die Confdir-Erweiterungseigenschaft an der Befehlszeile stand. Dann überprüft Validate, ob die Confdir-Eigenschaft einen Wert hat. Andernfalls wird mit Fehlerstatus und einer Fehlermeldung beendet. 


if ( (( $UPDATE_PROPERTY == 1 )) &&  (( CONFDIR_FOUND == 0 )) ); then
         config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
            -G $RESOURCEGROUP_NAME Confdir`
         CONFDIR=`echo $config_info | awk '{print $2}'`
fi

# Überprüfen, ob die Confdir-Eigenschaft einen Wert hat. Andernfalls Fehlschlag,
# und mit Status 1 beenden
if [[ -z $CONFDIR ]]; then
         logger -p ${SYSLOG_FACILITY}.err \
            "${ARGV0} Validate-Method für Ressource "$RESOURCE_NAME " fehlgeschlagen"
         exit 1
fi

Hinweis –

Der obige Code prüft vor allem, ob Validate als Ergebnis einer Aktualisierung aufgerufen wird ($UPDATE_PROPERTY == 1) und ob die Eigenschaft nicht an der Befehlszeile gefunden wurde (CONFDIR_FOUND == 0); in diesem Fall wird der vorhandene Wert von Confdir mithilfe von scha_resource_get() abgerufen. Wenn Confdir an der Befehlszeile gefunden wurde (CONFDIR_FOUND == 1), stammt der Wert für CONFDIR von der parse_args()-Funktion, nicht von scha_resource_get().

Die Validate-Methode verwendet dann den Wert von CONFDIR, um zu überprüfen, ob auf das Verzeichnis zugegriffen werden kann. Wenn kein Zugriff möglich ist, protokolliert Validate eine Fehlermeldung und wird mit Fehlerstatus beendet. 


# Prüfen, ob Zugriff auf $CONFDIR möglich ist.
if [ ! -d $CONFDIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Verzeichnis $CONFDIR fehlt oder ist nicht eingehängt."
   exit 1
fi

Vor dem Validieren der Aktualisierung der Confdir-Eigenschaft führt Validate eine letzte Prüfung durch, um festzustellen, ob die named.conf-Datei vorhanden ist. Andernfalls protokolliert die Methode eine Fehlermeldung und wird mit Fehlerstatus beendet. 


# Prüfen, od die named.conf-Datei im Confdir-Verzeichnis vorhanden ist
if [ ! -s $CONFDIR/named.conf ]; then
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Datei $CONFDIR/named.conf fehlt oder ist leer"
         exit 1
fi

Wenn diese letzte Prüfung erfolgreich war, protokolliert Validate eine Erfolgsmeldung und wird mit Erfolgsstatus beendet. 


# Meldung protokollieren, die angibt, dass die Validate-Methode erfolgreich war.
logger -p ${SYSLOG_FACILITY}.err \
   -t [$SYSLOG_TAG] \
   "${ARGV0} Validate-Methode für Ressource "$RESOURCE_NAME \
   " erfolgreich beendet"

exit 0

Validate-Beendigungsstatus

Wenn Validate mit Erfolg (0) endet, wird Confdir mit dem neuen Wert erstellt. Wenn Validate mit Fehlschlag (1) endet, werden weder Confdir noch irgendeine andere Eigenschaft erstellt, und eine Meldung mit Angabe der Gründe wird an den Cluster-Verwalter gesendet.

Update-Methode

RGM ruft die Update-Methode auf, um eine laufende Ressource darüber zu benachrichtigen, dass ihre Eigenschaften geändert wurden. RGM ruft Update auf, nachdem eine Verwaltungsaktion die Eigenschaften einer Ressource bzw. deren Gruppe erfolgreich eingestellt hat. Diese Methode wird auf den Knoten aufgerufen, auf denen die Ressource online ist.

Überblick über Update

Die Update-Methode aktualisiert keine Eigenschaften — das ist Aufgabe von RGM. Stattdessen benachrichtigt sie laufende Prozesse davon, dass eine Aktualisierung stattgefunden hat. Der einzige im Beispieldatendienst von einer Eigenschaftsaktualisierung betroffene Prozess ist der Fehler-Monitor. Daher wird dieser Prozess von der Update-Methode gestoppt und neu gestartet.

Die Update-Methode muss überprüfen, ob der Fehler-Monitor läuft und dann dessen Beenden mithilfe von pmfadm erzwingen. Die Methode ruft den Pfad des Testsignalprogramms ab, das den Fehler-Monitor implementiert, und startet ihn dann mithilfe von pmfadm neu.

Stoppen des Monitors mit Update

Die Update-Methode verwendet pmfadm -q, um zu überprüfen, ob der Monitor läuft. Wenn dies der Fall ist, erzwingt sie das Beenden mit pmfadm -s TERM. Wenn der Monitor erfolgreich beendet wurde, wird eine entsprechende Meldung an den Verwaltungsbenutzer gesendet. Wenn der Monitor nicht gestoppt werden kann, wird Update mit Fehlerstatus beendet und sendet eine Fehlermeldung an den Verwaltungsbenutzer. 


if pmfadm -q $RESOURCE_NAME.monitor; then

# Beenden des bereits laufenden Monitors erzwingen
pmfadm -s $PMF_TAG TERM
    if [ $? -ne 0 ]; then
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$SYSLOG_TAG] \
                 "${ARGV0} Monitor konnte nicht gestoppt werden"
       exit 1
    else
    # DNS konnte erfolgreich gestoppt werden. Meldung protokollieren.
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                 "Monitor für HA-DNS erfolgreich gestoppt"
    fi

Neustarten des Monitors

Um den Monitor neu zu starten, muss die Update-Methode das Skript finden, mit dem das Testsignalprogramm implementiert wird. Das Testsignalprogramm residiert im Basisverzeichnis des Datendienstes, auf das die Rt_basedir-Eigenschaft zeigt. Update ruft den Wert von Rt_basedir ab und speichert ihn in der RT_BASEDIR-Variablen, wie im Folgenden gezeigt.


RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

Dann verwendet Update den Wert von RT_BASEDIR mit pmfadm, um das dns_probe-Programm neu zu starten. Wenn dieser Vorgang erfolgreich ist, wird Update mit Erfolg beendet und sendet eine entsprechende Meldung an den Verwaltungsbenutzer. Wenn pmfadm das Testsignalprogramm nicht starten kann,wird Update mit Fehlerstatus beendet und protokolliert eine Fehlermeldung.

Update-Beendigungsstatus

Ein Fehlschlagen der Update-Methode versetzt die Ressource in einen Zustand “Aktualisierung fehlgeschlagen”. Dieser Zustand hat keine Auswirkung auf die RGM-Verwaltung der Ressource, gibt jedoch den Fehlschlag der Aktualisierungsaktion über die syslog-Funktion an Verwaltungstools an.