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:
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:
Eine Ressourcentyp-Registrierungsdatei, in der die statischen Datendiensteigenschaften definiert werden.
Eine Start-Rückmeldemethode, die von RGM aufgerufen wird, um den in.named-Dämon zu starten, sobald die Ressourcengruppe mit dem HA-DNS-Datendienst online gebracht wird.
Eine Stop-Rückmeldemethode, die von RGM aufgerufen wird, um den in.named-Dämon zu stoppen, wenn die Ressourcengruppe mit HA-DNS offline gebracht wird.
Ein Fehler-Monitor, der die Verfügbarkeit des Dienstes prüft, indem er überprüft, ob der DNS-Server läuft. Der Fehler-Monitor wird durch eine benutzerdefinierte PROBE-Methode implementiert und von den Rückmeldemethoden Monitor_start und Monitor_stop gestartet bzw. gestoppt.
Eine Validate-Rückmeldemethode, die von RGM aufgerufen wird, um zu validieren, dass das Konfigurationsverzeichnis für den Dienst zugänglich ist.
Eine Update-Rückmeldemethode, die von RGM aufgerufen wird, um den Fehler-Monitor zu starten, wenn der Systemverwalter den Wert einer Ressourceneigenschaft ändert.
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.
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.
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;
Als ersten Eintrag in der RTR-Datei müssen Sie die Resource_type-Eigenschaft deklarieren. Andernfalls schlägt die Registrierung des Ressourcentyps fehl.
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.
Der Ressourcentypname kann entweder nur unter Verwendung der Resource_type-Eigenschaft angegeben werden (sample), oder zusammen mit Vendor_id als Präfix zwischen “.” als Trennzeichen vom Ressourcentyp (SUNW.sample).
Wenn Sie Vendor_id verwenden, nehmen Sie das Börsensymbol für das Unternehmen, das den Ressourcentyp definiert. Der Ressourcentypname muss im Cluster einmalig sein.
Die Rt_version-Eigenschaft identifiziert die Version des Beispieldatendienstes entsprechend der Angabe des Herstellers.
Die API_version-Eigenschaft identifiziert die Sun Cluster-Version. API_version = 2 gibt zum Beispiel an, dass der Datendienst unter Sun Cluster Version 3.0 ausgeführt wird.
Failover = TRUE gibt an, dass der Datendienst nicht in einer Ressourcengruppe ausgeführt werden kann, die auf mehreren Knoten gleichzeitig online sein kann.
RT_basedir zeigt auf /opt/SUNWsample/bin als den Verzeichnispfad zu vollständigen relativen Pfaden, wie zum Beispiel Rückmeldemethodenpfaden.
Start, Stop, Validate usw. stellen den Pfad zu dem jeweiligen von RGM aufgerufenen Rückmeldeprogramm bereit. Diese Pfade sind relativ zu dem Verzeichnis, das durch RT_basedir angegeben wird.
Pkglist identifiziert SUNWsample als das Paket, das die Beispiel-Datendienstinstallation enthält.
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.
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.
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:
Sun Cluster stellt für alle Zeitüberschreitungen einen Mindestwert (1 Sekunde) und einen Standardwert (3600 Sekunden) bereit. In der RTR-Beispieldatei wird der Mindestwert zu 60 und der Standardwert zu 300 Sekunden geändert. Der Cluster-Verwalter kann diesen Standardwert akzeptieren oder den Wert für die Zeitüberschreitung ändern (60 oder größer). Sun Cluster hat keinen zulässigen Höchstwert.
Für die Eigenschaften Thorough_Probe_Interval, Retry_count und Retry_interval wird das TUNABLE-Attribut auf ANYTIME eingestellt. Diese Einstellung bedeutet, dass der Cluster-Verwalter den Wert der betreffenden Eigenschaften ändern kann, auch wenn der Datendienst gerade läuft. Diese Eigenschaften werden vom Fehler-Monitor verwendet, der für den Beispieldatendienst implementiert wurde. Der Beispieldatendienst implementiert eine Update-Methode zum Starten und Stoppen des Fehler-Monitors, wenn diese oder andere Ressourceneigenschaften durch eine Verwaltungsaktion geändert werden. Weitere Informationen finden Sie unter Update-Methode.
Ressourceneigenschaften werden folgendermaßen klassifiziert:
Erforderlich — Der Cluster-Verwalter muss einen Wert angeben, wenn er eine Ressource erstellt.
Optional — Wenn der Verwalter keinen Wert angibt, stellt das System einen Standardwert bereit.
Bedingt — RGM erstellt die Eigenschaft nur, wenn sie in der RTR-Datei deklariert wurde.
Der Fehler-Monitor des Beispieldatendienstes verwendet die bedingten Eigenschaften Thorough_probe_interval, Retry_count, Retry_interval und Network_resources_used. Daher mussten diese vom Entwickler in der RTR-Datei deklariert werden. Weitere Informationen zur Klassifizierung von Eigenschaften finden Sie in der Online-Dokumentation unter r_properties(5) und unter Ressourceneigenschaften.
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.
Dieser Abschnitt beschreibt die Funktionalität, die in allen Rückmeldemethoden des Beispieldatendienstes verwendet wird:
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 |
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 |
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).
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 } |
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 “$@” |
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).
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}'` |
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.
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.
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.
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.
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 |
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 |
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.
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.
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.
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.
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 |
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.
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:
dns_probe, ein benutzerdefiniertes Programm, das nslookup verwendet, um zu überprüfen, ob die vom Beispieldatendienst gesteuerte DNS-Ressource läuft. Wenn DNS nicht läuft, versucht diese Methode einen lokalen Neustart. Je nach der Anzahl der Neustartversuche kann sie auch anfordern, dass RGM den Datendienst auf einen anderen Knoten verschiebt.
dns_monitor_start, eine Rückmeldemethode zum Starten von dns_probe. Wenn die Überwachung aktiviert ist, ruft RGM automatisch dns_monitor_start auf, nachdem der Beispieldatendienst online gebracht wurde.
dns_monitor_stop, eine Rückmeldemethode zum Stoppen von dns_probe. RGM ruft automatisch dns_monitor_stop auf, bevor der Beispieldatendienst offline gebracht wird.
dns_monitor_check, eine Rückmeldemethode, welche die Validate-Methode aufruft, um zu überprüfen, ob das Konfigurationsverzeichnis verfügbar ist, wenn das PROBE-Programm ein Failover des Datendienstes auf einen neuen Knoten ausführt.
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.
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.
Dieses Programm benötigt die Werte der folgenden Eigenschaften:
Thorough_probe_interval – Zum Einstellen des Zeitraums, während dem das Testsignal ruht.
Probe_timeout – Zum Durchsetzen des Zeitüberschreitungswertes für das Testsignal an den nslookup-Befehl, der den Test ausführt.
Network_resources_used – Zum Abrufen der IP-Adresse, unter der DNS läuft.
Retry_count und Retry_interval – Zum Festlegen der Anzahl von Neustartversuchen und des Zeitraums, über den die Versuche gezählt werden.
Rt_basedir – Zum Abrufen des Verzeichnisses, in dem das PROBE-Programm und das gettime-Dienstprogramm gespeichert sind
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È
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.
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:
Festlegen des Ruheintervalls für das Testsignal.
Verwenden von hatimerun zum Auslösen von nslookup durch Übergabe des Probe_timeout-Werts und Identifizieren des Zielhosts.
Festlegen der probefail-Variable, basierend auf dem Erfolg oder Fehlschlag des nslookup-Rückgabecodes.
Wenn probefail auf 1 (Fehlschlag) eingestellt ist, wird überprüft, ob die Antwort auf nslookup vom Beispieldatendienst und nicht von einem anderen DNS-Server kam.
Es folgt der while-Schleifencode.
while : do # 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 |
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 dies der erste Fehlschlag ist, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert und der Zähler in der retries-Variable weitergedreht.
Wenn es sich nicht um den ersten Fehlschlag handelt, aber das Zeitfenster überschritten wurde, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert, der Zähler zurückgesetzt und das Fenster verschoben.
Wenn das Zeitfenster noch nicht abgelaufen ist und der Wiederholversuchszähler überschritten wurde, wird ein Failover auf einen anderen Knoten ausgeführt. Wenn das Failover fehlschlägt, wird ein Fehler protokolliert und das Testsignalprogramm mit Status 1 (Fehlschlag) beendet.
Wenn das Zeitfenster noch nicht abgelaufen ist und der Wiederholversuchszähler nicht überschritten wurde, wird der Datendienst neu gestartet. Es wird eine Fehlermeldung protokolliert und der Zähler in der retries-Variable weitergedreht.
Wenn die Anzahl der Neustarts während des Zeitintervalls den Grenzwert erreicht, fordert die Funktion bei RGM das Verschieben des Datendienstes auf einen anderen Knoten an. Wenn die Anzahl der Neustarts den Grenzwert noch nicht erreicht hat, bzw. wenn das Zeitintervall abgelaufen ist und die Zählung von vorn beginnt, versucht die Funktion, DNS auf demselben Knoten neu zu starten. Beachten Sie Folgendes für diese Funktion:
Das gettime-Dienstprogramm wird zum Verfolgen der Zeit zwischen Neustarts verwendet. Dabei handelt es sich um ein C-Programm, das im (Rt_basedir)-Verzeichnis residiert.
Die systemdefinierten Ressourceneigenschaften Retry_count und Retry_interval legen die Anzahl der Neustartversuche und das Zeitintervall für die Zählung fest. Der Standardwert für diese Eigenschaften in der RTR-Datei liegt bei 2 Versuchen in einem Zeitraum von 5 Minuten (300 Sekunden). Der Cluster-Verwalter kann diese Werte jedoch ändern.
Die restart_service()-Funktion wird aufgerufen, um zu versuchen, den Datendienst auf demselben Knoten neu zu starten. Weitere Informationen zu dieser Funktion finden Sie im nächsten Abschnitt, Neustarten des Datendienstes.
Die API-Funktion scha_control() bringt die Ressourcengruppe, die den Beispieldatendienst enthält, mit der Option GIVEOVER offline und auf einem anderen Knoten wieder online.
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.
Sie stellt fest, ob der Datendienst noch unter PMF registriert ist. Wenn der Dienst noch registriert ist, geht die Funktion folgendermaßen vor:
Sie ruft den Stop-Methodennamen und den Stop_timeout-Wert für den Datendienst ab.
Sie verwendet hatimerun, um die Stop-Methode für den Datendienst zu starten, indem sie den Stop_timeout-Wert übergibt.
Wenn der Datendienst erfolgreich gestoppt wurde, ruft sie den Start-Methodennamen und den Start_timeout-Wert für den Datendienst ab.
Sie verwendet hatimerun, um die Start-Methode für den Datendienst zu starten, indem sie den Start_timeout-Wert übergibt.
Wenn der Datendienst nicht mehr unter PMF registriert ist, bedeutet dies, dass er die maximale Anzahl zulässiger Wiederholversuche unter PMF überschritten hat. Daher wird die scha_control()-Funktion mit der GIVEOVER-Option aufgerufen, um für den Datendienst ein Failover auf einen anderen Knoten auszuführen.
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 } |
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”.
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.
Diese Methode verwendet PMF (pmfadm) zum 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 |
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.
Diese Methode verwendet PMF (pmfadm), um festzustellen, ob das Testsignal läuft und es gegebenenfalls zu stoppen.
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 |
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.
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.
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.
Der Beispieldatendienst implementiert die Methoden Validate und Update, um die Eigenschaftsaktualisierung durch einen Cluster-Verwalter bearbeiten zu können.
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.
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.
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.
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.
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.
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 |
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 |
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.
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.
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.
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 |
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.
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.