test

Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Kapitel 5 Beispieldatendienst

In diesem Kapitel wird ein Sun Cluster-Beispieldatendienst, HA-DNS, für die in.named-Anwendung beschrieben. Der in.named-Dämon ist die Solaris-Implementierung des Domain Name Service (DNS). 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.

Dieses Kapitel behandelt die folgenden Themen:

Ü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 und Knotenfehler.

Der Anwendungsneustart wird von PMF (Process Monitor Facility) verwaltet. Wenn die Anzahl der Anwendungen, die nicht mehr ausgeführt werden, die Fehleranzahl innerhalb des Fehlerzeitfensters überschreitet, führt der Fehler-Monitor einen Failover der Ressourcengruppe, die die Anwendungsressource enthält, an einen anderen Knoten aus.

Der Beispieldatendienst bietet eine Fehlerüberwachung in Form einer PROBE-Methode, die den nslookup-Befehl verwendet, um sicherzustellen, dass die Anwendung in fehlerfreiem Zustand ist. Wenn der Test einen DNS-Dienst entdeckt, der sich aufgehängt hat, versucht er, die Situation zu korrigieren, indem die DNS-Anwendung lokal neu gestartet wird. Wenn die Situation durch einen Neustart der DNS-Anwendung nicht verbessert werden kann und der Test wiederholt auf Probleme mit dem Dienst stößt, unternimmt der Test einen Failover-Versuch an einen anderen Knoten im Cluster.

Der Beispieldatendienst umfasst insbesondere folgende Elemente:

Definieren der Ressourcentyp-Registrierungsdatei

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

Die Informationen in der RTR-Datei werden von Resource Group Manager (RGM) gelesen, sobald der Cluster-Administrator den HA-DNS-Datendienst registriert.

Überblick über die RTR-Datei

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 im Abschnitt Einstellen der Ressourcen- und Ressourcentypeigenschaften.

In den folgenden Abschnitten werden die speziellen Eigenschaften der RTR-Beispieldatei beschrieben. Diese Abschnitte enthalten Listen mit den verschiedenen Teilen der Datei. Eine vollständige Liste 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.

Hinweis –

Die Eigenschaftsnamen der Ressourcengruppen, Ressourcen und Ressourcentypen unterliegen nicht der Groß-/Kleinschreibung. Bei der Eingabe von Eigenschaftsnamen können Sie jede beliebige Kombination aus Groß- und Kleinbuchstaben verwenden. 

#
# Copyright (c) 1998-2005 by Sun Microsystems, Inc.
# All rights reserved.
#
# Registration information for Domain Name Service (DNS)
#

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

Resource_type = “sample”;
Vendor_id = SUNW;
RT_description = “Domain Name Service on 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.

Folgende Informationen liefern eine Beschreibung dieser Eigenschaften:

Ressourcentypeigenschaften, die in dieser RTR-Datei nicht angegeben sind, wie Single_instance, Init_nodes und Installed_nodes werden auf ihre Standardwerte zurückgesetzt. Der Abschnitt Ressourcentypeigenschaften enthält eine vollständige Liste mit Ressourcentypeigenschaften, einschließlich ihrer Standardwerte.

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

Ressourceneigenschaften in der RTR-Beispieldatei

Der Konvention gemäß werden Ressourceneigenschaften in der RTR-Datei nach den Ressourcentypeigenschaften deklariert. Ressourceneigenschaften umfassen systemdefinierte Eigenschaften, die von der Sun Cluster-Software und den von Ihnen definierten Erweiterungseigenschaften geliefert werden. Sie können für jeden Typ eine Vielzahl von Eigenschaftsattributen angeben, die von der Sun Cluster-Software geliefert werden, z.B. Mindest-, Maximal- und Standardwerte.

Systemdefinierte Eigenschaften in der RTR-Datei

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

# A list of bracketed resource property declarations follows the
# resource type declarations. The property-name declaration must be
# the first attribute after the open curly bracket of each entry.

# The <method>_timeout properties set the value in seconds after which
# the RGM concludes invocation of the method has failed.

# The MIN value for all method timeouts is set to 60 seconds. This
# prevents administrators from setting shorter timeouts, which do not
# improve switchover/failover performance, and can lead to undesired
# RGM actions (false failovers, node reboot, or moving the resource group
# to ERROR_STOP_FAILED state, requiring operator intervention). Setting
# too-short method timeouts leads to a *decrease* in overall availability
# of the data service.
{  
   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;
}

# The number of retries to be done within a certain period before concluding 
# that the application cannot be successfully started on this node.
{
   PROPERTY = Retry_count;
   MIN=0;
   MAX=10;
   DEFAULT=2;
   TUNABLE = ANYTIME; 
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of 
# retries (Retry_count).
{
   PROPERTY = Retry_interval;
   MIN=60;
   MAX=3600;
   DEFAULT=300;
   TUNABLE = ANYTIME;
}

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

Obwohl die Sun Cluster-Software die systemdefinierten Eigenschaften liefert, können Sie mithilfe von Ressourceneigenschaftsattributen verschiedene Standardwerte festlegen. Eine vollständige Liste mit Attributen, die Ihnen zum Anwenden auf Ressourceneigenschaften zur Verfügung stehen, finden Sie im Abschnitt Ressourceneigenschaftsattribute.

Beachten Sie die folgenden Punkte zu den systemdefinierten Ressourceneigenschaften in der RTR-Beispieldatei:

Erweiterungseigenschaften in der RTR-Datei

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

# Extension Properties

# The cluster administrator must set the value of this property to point to the
# directory that contains the configuration files used by the application.
# For this application, DNS, specify the path of the DNS configuration file on
# PXFS (typically named.conf).
{
   PROPERTY = Confdir;
   EXTENSION;
   STRING;
   TUNABLE = AT_CREATION;
   DESCRIPTION = “The Configuration Directory Path”;
}

# Time out value in seconds before declaring the probe as failed.
{
   PROPERTY = Probe_timeout;
   EXTENSION;
   INT;
   DEFAULT = 120;
   TUNABLE = ANYTIME;
   DESCRIPTION = “Time out value for the probe (seconds)”;
}

Die RTR-Beispieldatei definiert zwei Erweiterungseigenschaften, Confdir und Probe_timeout. Die Confdir-Eigenschaft gibt den Pfad des DNS-Konfigurationsverzeichnisses 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 zu prüfen, ob auf das Konfigurationsverzeichnis und die in.named-Datei zugegriffen werden kann, bevor der DNS gestartet wird.

Nach Konfigurieren des Datendienstes überprüft die Validate-Methode, ob auf das neue Verzeichnis zugegriffen werden kann.

Die PROBE-Methode des Beispieldatendienstes ist keine Sun Cluster-Rückmeldemethode, sondern eine benutzerdefinierte Methode. Deshalb liefert Sun Cluster keine Probe_timeout-Eigenschaft dafür. Sie müssen eine Erweiterungseigenschaft in der RTR-Datei definieren, um einem Cluster-Administrator die Konfiguration eines Probe_timeout-Werts zu ermöglichen.

Bereitstellen gemeinsamer Funktionalität für alle Methoden

In diesem Abschnitt wird die Funktionalität beschrieben, 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 Methodenskript des Beispieldatendienstes identifiziert den Befehlsinterpreter wie folgt: 

#!/bin/ksh

Alle Methodenskripts der Beispielanwendung exportieren den Pfad der Sun Cluster-Binärdateien und -Bibliotheken, anstatt sich auf die PATH-Einstellungen des Benutzers zu verlassen. 

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

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

Deklarieren der VariablenPMF_TAG und SYSLOG_TAG

Alle Methodenskripts mit Ausnahme von Validate verwenden pmfadm, um den Datendienst oder den Monitor zu starten oder zu stoppen und den Namen der Ressource zu übergeben. Jedes Skript definiert eine Variable, PMF_TAG, die an pmfadm übergeben werden kann, um entweder den Datendienst oder den Monitor zu identifizieren.

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

Alle Methoden definieren SYSLOG_TAG auf dieselbe Weise, wie im folgenden Beispielcode dargestellt. Die dns_probe-, dns_svc_start -, dns_svc_stop- und dns_monitor_check-Methoden definieren PMF_TAG wie folgt (die Verwendung von pmfadm und logger stammt von der Methode dns_svc_stop). 

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

PMF_TAG=$RESOURCE_NAME.named

SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME

   # Send a SIGTERM signal to the data service and wait for 80% of the
   # total timeout value.
   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 (die Verwendung von pmfadm stammt von der Methode dns_monitor_stop): 

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

PMF_TAG=$RESOURCE_NAME.monitor
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
...
# See if the monitor is running, and if so, kill it. 
if pmfadm -q $PMF_TAG.monitor; then
   pmfadm -s $PMF_TAG.monitor KILL

Analysieren der Funktionsargumente

RGM führt alle Rückmeldemethoden mit Ausnahme von Validate wie folgt aus: 

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. In der RTR-Datei des Beispieldatendienstes sind das Basisverzeichnis und die Methodennamen wie folgt angegeben: 

RT_basedir=/opt/SUNWsample/bin;
Start = dns_svc_start;
Stop =  dns_svc_stop;
...

Alle Argumente für Rückmeldemethoden werden wie folgt als Flag-Werte übergeben: Das Argument -R gibt den Namen der Ressourceninstanz an. Das Argument -T gibt den Ressourcentyp an. Das Argument -G gibt die Gruppe an, 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, die Eigenschaftswerte der Ressource und Ressourcengruppe, für die sie aufgerufen wird. Weitere Informationen finden Sie im Abschnitt Bearbeiten von Eigenschaftsaktualisierungen.

Jede Rückmeldemethode benötigt eine Funktion zum Analysieren der Argumente, mit denen die Funktion übergeben wird. 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 Beispiel wird die parse_args()-Funktion dargestellt, die für die Rückmeldemethoden in der Beispielanwendung verwendet wird. 

#########################################################################
# Parse program arguments.
#
function parse_args # [args ...]
{
      typeset opt

      while getopts 'R:G:T:' opt
      do
             case "$opt" in
             R)
                  # Name of the DNS resource.
                  RESOURCE_NAME=$OPTARG
                  ;;
             G)
                  # Name of the resource group in which the resource is
                  # configured.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
             T)
                  # Name of the resource type.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
             *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                  "ERROR: Option $OPTARG unknown"
                  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. Deshalb enthält diese Methode eine Analysefunktion, die mit derjenigen identisch ist, die von den anderen Rückmeldemethoden verwendet wird.

Die Analysefunktion wird in MAIN wie folgt aufgerufen: 

parse_args “$@”

Generieren von Fehlermeldungen

Rückmeldemethoden sollten die syslog()-Funktion für die Ausgabe von Fehlermeldungen an Endbenutzer verwenden. Alle Rückmeldemethoden im Beispieldatendienst verwenden den Befehl scha_cluster_get zum Abrufen der Nummer der syslog()-Funktion, die für das Cluster-Protokoll verwendet wird, wie folgt: 

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`

Der Wert wird in einer Shell-Variablen, SYSLOG_FACILITY, gespeichert und kann als Option des logger-Befehls verwendet werden, um Meldungen im Cluster-Protokoll aufzuzeichnen. So ruft z.B. die Start-Methode des Beispieldatendienstes die syslog()-Funktion ab und protokolliert eine Meldung, dass der Datendienst gestartet wurde, wie folgt: 

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`
...
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi

Weitere Informationen finden Sie in der Online-Dokumentation zu 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 sowohl systemdefinierte Eigenschaften als auch Erweiterungseigenschaften zur Verfügung. Systemdefinierte Eigenschaften sind vordefiniert. Die Erweiterungseigenschaften definieren Sie in der RTR-Datei.

Wenn Sie scha_resource_get() verwenden, um den Wert einer systemdefinierten Eigenschaft abzurufen, geben Sie den Namen der Eigenschaft mit der Option -O an. Der Befehl gibt nur den Wert der Eigenschaft zurück. Zum Beispiel muss die Monitor_start-Methode des Beispieldatendienstes das Testprogramm finden, damit es ausgeführt werden kann. Das Testprogramm befindet sich im Basisverzeichnis des Datendienstes, auf das mit der Eigenschaft RT_basedir verwiesen wird. Die Monitor_start-Methode ruft den Wert von RT_basedir ab und fügt ihn wie folgt in die RT_BASEDIR-Variable ein: 

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

Für die Erweiterungseigenschaften müssen Sie die Option -O verwenden, um anzugeben, dass die Eigenschaft eine Erweiterungseigenschaft ist. Sie müssen auch den Namen der Eigenschaft als letztes Argument angeben. Im Falle von Erweiterungseigenschaften gibt der Befehl sowohl den Typ als auch den Wert der Eigenschaft zurück. Beim Beispieldatendienst ruft z.B. das Testprogramm den Typ und den Wert der Probe_timeout-Erweiterungseigenschaft ab und verwendet den awk-Befehl wie folgt, um den Wert lediglich in die PROBE_TIMEOUT-Shell-Variable einzufügen: 

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 zum Aktivieren des Anwendungsdämons im Cluster sowie eine Stop- oder Postnet_stop-Methode zum Stoppen des Anwendungsdämons im Cluster bereitstellen. Der Beispieldatendienst implementiert eine Start- und eine Stop-Methode. Im Abschnitt Verwendung von Start- und Stop-Methoden erhalten Sie Informationen darüber, wann Prenet_start und Postnet_stop verwendet werden sollen.

Funktionsweise der Start-Methode

RGM führt die Start-Methode auf einem Cluster-Knoten aus, 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 an diesem Knoten.

Dieser Abschnitt beschreibt die Hauptteile der Start-Methode für die Beispielanwendung. 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 Start-Methode finden Sie im Abschnitt Auflistung des Start-Methodencodes.

Die Start-Methode

Bevor Sie versuchen, DNS zu starten, prüft die Start-Methode des Beispieldatendienstes, ob das Konfigurationsverzeichnis und die Konfigurationsdatei (named.conf) zugänglich und verfügbar sind. Die Informationen in der Datei named.conf sind für einen erfolgreichen Betrieb des DNS erforderlich.

Diese Rückmeldemethode verwendet PMF (pmfadm), um den DNS-Dämon (in.named) zu starten. Wenn der DNS abstürzt oder nicht gestartet werden kann, versucht PMF, den DNS-Dämon so häufig wie vorgeschrieben innerhalb eines angegebenen Intervalls zu starten. Die Anzahl der Wiederholversuche und das Intervall werden von den 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. Deshalb führt die Start-Methode einige Tests durch, die prüfen, ob auf das Verzeichnis und die Datei zugegriffen werden kann, bevor der Versuch unternommen wird, den DNS zu starten.

Die Confdir-Erweiterungseigenschaft stellt den Pfad zum Konfigurationsverzeichnis bereit. Die Eigenschaft selbst ist in der RTR-Datei definiert. Der Cluster-Administrator legt den tatsächlichen Ort jedoch bei der Konfiguration des Datendienstes fest.

Beim Beispieldatendienst ruft die Start-Methode den Ort 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. Mit dem Befehl awk wird lediglich der Wert abgerufen und in eine Shell-Variable, CONFIG_DIR , eingefügt. 

# find the value of Confdir set by the cluster administrator 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 the
# extension properties. Get only the value of the extension property 
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

Die Start-Methode verwendet den Wert von CONFIG_DIR, um zu prüfen, ob auf das Verzeichnis zugegriffen werden kann. Ist dies nicht der Fall, protokolliert die Start-Methode eine Fehlermeldung und wird mit einem Fehlerstatus beendet. Weitere Informationen finden Sie unter Start-Beendigungsstatus. 

# Check if $CONFIG_DIR is accessible.
if [ ! -d $CONFIG_DIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Directory $CONFIG_DIR is missing or not mounted"
   exit 1
fi

Vor dem Starten des Anwendungsdämons überprüft diese Methode abschließend, ob die named.conf-Datei vorhanden ist. Ist die Datei nicht vorhanden, protokolliert die Start-Methode eine Fehlermeldung und wird mit einem Fehlerstatus beendet. 

# Change to the $CONFIG_DIR directory in case there are relative
# pathnames in the data files.
cd $CONFIG_DIR

# Check that the named.conf file is present in the $CONFIG_DIR directory
if [ ! -s named.conf ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} File $CONFIG_DIR/named.conf is missing or empty"
   exit 1
fi

Starten der Anwendung

Bei dieser Methode wird Process Manager Facility (pmfadm) zum Starten der Anwendung verwendet. Mit dem Befehl pmfadm können Sie die Anzahl der Versuche festlegen, mit denen die Anwendung innerhalb eines bestimmten Zeitrahmens neu gestartet wird. Die RTR-Datei enthält zwei Eigenschaften: Retry_count legt die Anzahl der Versuche fest, die eine Anwendung neu gestartet wird, und Retry_interval den Zeitraum, innerhalb dessen die Versuche unternommen werden.

Die Start-Methode ruft die Werte von Retry_count und Retry_interval mithilfe der Funktion scha_resource_get () ab und speichert ihre Werte in den Shell-Variablen. Die Start -Methode übergibt diese Werte an pmfadm und verwendet dabei die Optionen - n und -t. 

# Get the value for retry count from the RTR file.
RETRY_CNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Get the value for retry interval from the RTR file. This value is in seconds
# and must be converted to minutes for passing to pmfadm. Note that the 
# conversion rounds up; for example, 50 seconds rounds up to 1 minute.
((RETRY_INTRVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# Start the in.named daemon under the control of PMF. Let it crash and restart
# up to $RETRY_COUNT times in a period of $RETRY_INTERVAL; if it crashes
# more often than that, PMF will cease trying to restart it.
# If there is a process already registered under the tag
# <$PMF_TAG>, then PMF sends out an alert message that the
# process is already running.
pmfadm -c $PMF_TAAG -n $RETRY_CNT -t $RETRY_INTRVAL \
    /usr/sbin/in.named -c named.conf

# Log a message indicating that HA-DNS has been started.
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi
exit 0

Start-Beendigungsstatus

Eine Start-Methode sollte nicht mit Erfolg beendet werden, bis die zugrunde liegende Anwendung tatsächlich ausgeführt wird und verfügbar ist, insbesondere wenn andere Datendienste davon abhängig sind. Eine Methode, den Erfolg zu prüfen, besteht darin, die Anwendung zu testen, um sicherzustellen, dass sie ausgeführt wird, bevor Sie die Start-Methode beenden. Für eine komplexe Anwendung, wie z.B. eine Datenbank, müssen Sie den Wert für die Start_timeout-Eigenschaft in der RTR-Datei so hoch setzen, dass genügend Zeit zur Verfügung steht, dass die Anwendung nach einem Absturz gestartet und wiederhergestellt werden kann.

Hinweis –

Da die Anwendungsressource (DNS) des Beispieldatendienstes schnell startet, fordert der Beispieldatendienst keine Prüfung, ob sie ausgeführt wird, bevor sie erfolgreich 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 legt die Failover_mode-Eigenschaft nicht ausdrücklich fest, sodass diese Eigenschaft den Standardwert NONE aufweist (es sei denn, der Cluster-Administrator überschreibt den Standardwert und legt einen anderen Wert fest). In diesem Fall ist die einzige Aufgabe von RGM, den Zustand des Datendienstes einzustellen. Der Cluster-Administrator muss an demselben Knoten einen Neustart initiieren oder einen Failover an einen anderen Knoten durchführen.

Funktionsweise der 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 an diesem Knoten.

Dieser Abschnitt beschreibt die Hauptteile der Stop-Methode für die Beispielanwendung. 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 Stop-Methode finden Sie im Abschnitt Auflistung des Stop-Methodencodes.

Die Stop-Methode

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 durch pmfadm ist die beste Methode für ein ordnungsgemäßes Herunterfahren.

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 Methode, den Datendienst in diesen Zustand zu versetzen, besteht darin, ein SIGKILL-Signal über pmfadm zu senden.

Die Stop-Methode dieses Beispieldienstes berücksichtigt beide Möglichkeiten. Zuerst sendet sie ein SIGTERM-Signal. Wenn der Datendienst nicht mit diesem Signal angehalten werden 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. Ist dies der Fall, verwendet Stop PMF (pmfadm), um den Prozess zu stoppen.

Diese Stop-Methode ist garantiert idempotent. Obwohl RGM eine Stop-Methode nicht zweimal aufrufen sollte, ohne zuerst den Datendienst über einen Aufruf seiner Start-Methode zu starten, könnte RGM eine Stop-Methode für eine Ressource selbst dann aufrufen, wenn die Ressource gar nicht gestartet oder abgebrochen wurde. 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: einen ordentlichen oder "sanften" Ansatz, bei dem ein SIGTERM-Signal über pmfadm gesendet wird und einen abrupten oder "harten" Ansatz, bei dem ein SIGKILL-Signal verwendet wird. Die Stop-Methode ruft den Stop_timeout-Wert ab (die Zeit, in der die Stop-Methode einen Wert zurückgeben muss). Stop weist dann 80% dieser Zeit dem sanften 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_NAME'
((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. Wird der DNS-Dämon ausgeführt, verwendet Stop zuerst pmfadm -s, um ein TERM-Signal zum Beenden des DNS-Prozesses zu senden. Falls dieses Signal den Prozess nach 80 Prozent des Zeitüberschreitungswertes nicht beendet, sendet Stop ein SIGKILL-Signal. Wenn dieses Signal den Prozess ebenfalls innerhalb von 15 Prozent des Zeitüberschreitungswertes beendet, protokolliert die Methode eine Fehlermeldung und wird mit einem 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. Im folgenden Code-Beispiel wird dargestellt, wie Stop mit pmfadm den DNS-Prozess stoppt. 

# See if in.named is running, and if so, kill it. 
if pmfadm -q $PMF_TAG; then
   # Send a SIGTERM signal to the data service and wait for 80% of the
   # total timeout value.
   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} Failed to stop HA-DNS with SIGTERM; Retry with \
           SIGKILL”
      
      # Since the data service did not stop with a SIGTERM signal, use 
      # SIGKILL now and wait for another 15% of the total timeout value.
      pmfadm -s $PMF_TAG -w $HARD_TIMEOUT KILL
      if [ $? -ne 0 ]; then
          logger -p ${SYSLOG_FACILITY}.err \
          -t [$SYSLOG_TAG] \
          “${ARGV0} Failed to stop HA-DNS; Exiting UNSUCCESSFUL”
         exit 1
      fi
fi
else 
   # The data service is not running as of now. Log a message and 
   # exit success.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “HA-DNS is not started”

   # Even if HA-DNS is not running, exit success to avoid putting
   # the data service resource in STOP_FAILED State.
   exit 0
fi

# Could successfully stop DNS. Log a message and exit success.
logger -p ${SYSLOG_FACILITY}.err \
    -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
    “HA-DNS successfully stopped”
exit 0

Stop-Beendigungsstatus

Eine Stop-Methode sollte so lange nicht mit Erfolg beendet werden, bis die zugrunde liegende Anwendung tatsächlich gestoppt wurde, insbesondere wenn andere Datendienste davon abhängig sind. 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 legt die Failover_mode-Eigenschaft nicht ausdrücklich fest, sodass diese Eigenschaft den Standardwert NONE aufweist (es sei denn, der Cluster-Administrator überschreibt den Standardwert und legt einen anderen Wert fest). In diesem Fall unternimmt RGM nur die Aktion, den Status des Datendienstes auf Stop_failed zu setzen. Der Cluster-Administrator muss die Anwendung erzwungenermaßen stoppen und den Status Stop_failed bereinigen.

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:

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:

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:

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 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 den Datendienst an demselben Knoten neu zu starten. Mit dieser Funktion wird die folgende Logik ausgeführt:

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

Bearbeiten von Eigenschaftsaktualisierungen

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

Funktionsweise der 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 auf, wenn die Ressourcen- oder Ressourcengruppeneigenschaften vom Cluster-Administrator geändert werden, nicht, wenn RGM die Eigenschaften festlegt oder ein Monitor die Ressourceneigenschaften Status und Status_msg festlegt.

Hinweis –

Die Monitor_check-Methode ruft auch die Validate-Methode explizit auf, wenn die PROBE-Methode einen Failover-Versuch des Datendienstes an einen neuen Knoten unternimmt.

Funktionsweise der Validate-Methode

RGM ruft Validate mit zusätzlichen Argumenten zu denjenigen auf, die an andere Methoden übergeben werden, einschließlich der Eigenschaften und Werte, die aktualisiert werden. Deshalb muss diese Methode des Beispieldatendienstes eine andere parse_args()-Funktion zum Verarbeiten von zusätzlichen Argumenten implementieren.

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 ausgeführt wird, wird die Confdir-Eigenschaft in der RTR-Datei als TUNABLE = AT_CREATION deklariert. Deshalb wird die Validate-Methode niemals aufgerufen, um die Confdir-Eigenschaft als Ergebnis eines Updates zu prüfen, sondern nur bei Erstellung der Datendienstressource.

Wenn Confdir eine der Eigenschaften darstellt, die von RGM an Validate übergeben werden, ruft die parse_args()-Funktion ihren Wert ab und speichert ihn. Validate prüft, ob auf das Verzeichnis, auf das mit dem neuen Wert von Confdir verwiesen wird, zugegriffen werden kann und ob die Datei named.conf in diesem Verzeichnis existiert und Daten enthält.

Wenn die parse_args()-Funktion den Wert von Confdir nicht von den Befehlszeilenargumenten abrufen kann, die von RGM übergeben werden, versucht Validate weiterhin, die Confdir-Eigenschaft zu validieren. Validate verwendet scha_resource_get(), um den Wert von Confdir aus der statischen Konfiguration abzurufen. Validate führt dieselben Prüfungen aus, um zu prüfen, ob auf das Konfigurationsverzeichnis zugegriffen werden kann und ob es die Datei named.conf enthält, die nicht leer ist.

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

Analysefunktion der Validate-Methode

Da RGM der Validate-Methode einen anderen Satz Argumente übergibt als die anderen Rückmeldemethoden, benötigt Validate eine andere Funktion für die Analyseargumente als die anderen Methoden. In der Online-Dokumentation zu rt_callbacks(1HA) finden Sie weitere Informationen über die Argumente, die an Validate und die anderen Rückmeldemethoden übergeben werden. Folgendes Codebeispiel zeigt die Validate parse_args()-Funktion. 

#########################################################################
# Parse Validate arguments.
#
function parse_args # [args...]
{

   typeset opt
   while getopts 'cur:x:g:R:T:G:' opt
   do
         case "$opt" in
         R)
                  # Name of the DNS resource.
                  RESOURCE_NAME=$OPTARG
                  ;;
         G)
                  # Name of the resource group in which the resource is
                  # configured.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
         T)
                  # Name of the resource type.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
         r)
                  # The method is not accessing any system defined
                  # properties so this is a no-op
                  ;;
         g)
                  # The method is not accessing any resource group
                  # properties, so this is a no-op
                  ;;
         c)
                  # Indicates the Validate method is being called while
                  # creating the resource, so this flag is a no-op.
                  ;;
         u)
                  # Indicates the updating of a property when the
                  # resource already exists. If the update is to the
                  # Confdir property then Confdir should appear in the
                  # command-line arguments. If it does not, the method must
                  # look for it specifically using scha_resource_get.
                  UPDATE_PROPERTY=1
                  ;;
         x)
                  # Extension property list. Separate the property and
                  # value pairs using "=" as the separator.
                  PROPERTY=`echo $OPTARG | awk -F= '{print $1}'`
                  VAL=`echo $OPTARG | awk -F= '{print $2}'`
                  # If the Confdir extension property is found on the
                  # command line, note its value.
                  if [ $PROPERTY == "Confdir" ]; then
                           CONFDIR=$VAL
                           CONFDIR_FOUND=1
                  fi
                  ;;
         *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$SYSLOG_TAG] \
                  "ERROR: Option $OPTARG unknown"
                  exit 1
                  ;;
         esac
   done
}

Wie im Falle der parse_args()-Funktion für andere Methoden, bietet diese Funktion das Flag (R) zum Erfassen des Ressourcennamens, (G) zum Erfassen des Ressourcengruppennamens und (T) zum Erfassen des Ressourcentyps, der von RGM übergeben wird.

Das r-Flag (das auf eine systemdefinierte Eigenschaft verweist), das g-Flag (das auf eine Ressourcengruppeneigenschaft verweist) und das c-Flag (das angibt, ob die Validierung während der Ressourcenerstellung stattfindet) werden ignoriert. Sie werden ignoriert, weil diese Methode zum Validieren einer Erweiterungseigenschaft aufgerufen wird, wenn die Ressource aktualisiert wird.

Das u-Flag stellt den Wert der UPDATE_PROPERTY-Shell-Variablen auf 1 (TRUE) ein. Das x-Flag erfasst die Namen und Werte der Eigenschaften, die aktualisiert werden. Wenn es sich bei Confdir um eine der aktualisierten Eigenschaften handelt, wird ihr Wert in die CONFDIR-Shell-Variable eingefügt und die Variable CONFDIR_FOUND auf 1 (TRUE) gesetzt.

Validieren von Confdir

In ihrer MAIN-Funktion setzt Validate die CONFDIR-Variable auf die leere Zeichenkette und UPDATE_PROPERTY und CONFDIR_FOUND auf 0. 

CONFDIR=""
UPDATE_PROPERTY=0
CONFDIR_FOUND=0

Validate ruft parse_args() auf, um die Argumente zu analysieren, die von RGM übergeben werden. 

parse_args “$@”

Validate prüft, ob Validate als Ergebnis einer Eigenschaftenaktualisierung aufgerufen wird. Validate prüft auch, ob die Confdir-Erweiterungseigenschaft in der Befehlszeile angegeben wurde. Validate prüft, ob die Confdir-Eigenschaft einen Wert enthält. Ist dies nicht der Fall, wird sie mit einem 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

# Verify that the Confdir property has a value. If not there is a failure
# and exit with status 1
if [[ -z $CONFDIR ]]; then
         logger -p ${SYSLOG_FACILITY}.err \
            "${ARGV0} Validate method for resource "$RESOURCE_NAME " failed"
         exit 1
fi
Hinweis –

Der oben stehende Code prüft insbesondere, ob Validate als Ergebnis einer Aktualisierung aufgerufen wird ($UPDATE_PROPERTY == 1) und ob die Eigenschaft auch nicht in der Befehlszeile angegeben ist ( CONFDIR_FOUND == 0). In diesem Fall ruft der Code den bereits vorhandenen Wert von Confdir unter Verwendung von scha_resource_get() ab. Wenn Confdir in der Befehlszeile gefunden wird (CONFDIR_FOUND == 1), stammt der Wert von CONFDIR von der parse_args()-Funktion, nicht von scha_resource_get().

Die Validate-Methode verwendet den Wert von CONFDIR, um zu prüfen, ob auf das Verzeichnis zugegriffen werden kann. Ist dies nicht der Fall, protokolliert Validate eine Fehlermeldung und wird mit einem Fehlerstatus beendet. 

# Check if $CONFDIR is accessible.
if [ ! -d $CONFDIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Directory $CONFDIR missing or not mounted"
   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. Ist die Datei nicht vorhanden, protokolliert die Methode eine Fehlermeldung und wird mit einem Fehlerstatus beendet. 

# Check that the named.conf file is present in the Confdir directory
if [ ! -s $CONFDIR/named.conf ]; then
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} File $CONFDIR/named.conf is missing or empty"
         exit 1
fi

Wenn die endgültige Prüfung vorüber ist, protokolliert Validate eine Meldung, die einen Erfolg ausweist und wird mit einem Erfolgsstatus beendet. 

# Log a message indicating that the Validate method was successful.
logger -p ${SYSLOG_FACILITY}.err \
   -t [$SYSLOG_TAG] \
   "${ARGV0} Validate method for resource "$RESOURCE_NAME \
   " completed successfully"

exit 0

Validate-Beendigungsstatus

Wenn Validate mit Erfolg (0) beendet wird, wird Confdir mit dem neuen Wert erstellt. Wenn Validate mit einem Fehler beendet wird (1), werden weder Confdir noch andere Eigenschaften erstellt und es wird eine Meldung, die den Grund angibt, generiert.

Funktionsweise der Update-Methode

RGM führt die Update-Methode aus, um eine laufende Ressource darüber zu benachrichtigen, dass ihre Eigenschaften geändert wurden. RGM führt Update aus, nachdem ein Cluster-Administrator die Eigenschaften einer Ressource oder ihrer Gruppe erfolgreich ausführt. Diese Methode wird an Knoten ausgeführt, an denen die Ressource online ist.

Funktionsweise der Update-Methode

Die Update-Methode aktualisiert keine Eigenschaften. RGM aktualisiert Eigenschaften. Die Update-Methode benachrichtigt laufende Prozesse darüber, dass eine Aktualisierung stattgefunden hat. Der einzige Prozess des Beispieldatendienstes, der von einer Eigenschaftenaktualisierung beeinträchtigt wird, ist der Fehler-Monitor. Folglich ist der Fehler-Monitor-Prozess der Prozess, der von der Update-Methode gestoppt und neu gestartet wird.

Die Update-Methode muss prüfen, ob der Fehler-Monitor ausgeführt wird und ihn dann mit dem Befehl pmfadm beenden. Die Methode ruft den Speicherort des Testsignalprogramms ab, mit dem der Fehler-Monitor implementiert wird und startet es mit dem Befehl pmfadm neu.

Stoppen des Monitors mit Update

Die Update-Methode verwendet pmfadm -q, um zu prüfen, ob der Monitor ausgeführt wird. Ist dies der Fall, wird er mit pmfadm -s TERM beendet. Wenn der Monitor erfolgreich beendet wird, wird zu diesem Zweck eine Meldung an den Cluster-Administrator gesendet. Wenn der Monitor nicht gestoppt werden kann, wird Update mit einem Fehlerstatus beendet und eine Fehlermeldung an den Cluster-Administrator gesendet. 

if pmfadm -q $RESOURCE_NAME.monitor; then

# Kill the monitor that is running already
pmfadm -s $PMF_TAG TERM
    if [ $? -ne 0 ]; then
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$SYSLOG_TAG] \
                 "${ARGV0} Could not stop the monitor"
       exit 1
    else
    # could successfully stop DNS. Log a message.
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                 "Monitor for HA-DNS successfully stopped"
    fi

Neustarten des Monitors

Um den Monitor neu zu starten, muss die Update-Methode das Skript finden, mit dem das Testsignalprogramm implementiert wird. Das Testprogramm befindet sich im Basisverzeichnis des Datendienstes, auf das mit der Eigenschaft RT_basedir verwiesen wird. Update ruft den Wert von RT_basedir ab und speichert ihn wie folgt in der RT_BASEDIR-Variablen. 

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

Update verwendet den Wert von RT_BASEDIR mit pmfadm, um das dns_probe-Programm neu zu starten. Bei Erfolg wird Update mit Erfolg beendet und zu diesem Zweck eine Meldung an den Cluster-Administrator gesendet. Wenn pmfadm das Testsignalprogramm nicht starten kann, wird Update mit einem Fehlerstatus beendet und eine Fehlermeldung protokolliert.

Update-Beendigungsstatus

Ein Fehlschlagen der Update-Methode versetzt die Ressource in einen Zustand “Aktualisierung fehlgeschlagen”. Dieser Zustand hat keinerlei Auswirkung auf die RGM-Verwaltung der Ressource, weist jedoch die Verwaltungstools auf den Fehler der Aktualisierungsaktion über die Funktion syslog() hin.