test

Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Kapitel 7 Entwerfen von Ressourcentypen

Dieses Kapitel erläutert, wie die DSDL in der Regel beim Entwurf und der Implementierung von Ressourcentypen eingesetzt wird. Das Kapitel geht auch darauf ein, wie der Ressourcentyp entworfen werden muss, um die Ressourcenkonfiguration zu validieren sowie die Ressource zu starten, zu stoppen und zu überwachen. Zuletzt wird beschreiben, wie die DSDL beim Implementieren der Rückmeldemethoden des Ressourcentyps verwendet werden kann.

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

Um diese Aufgaben ausführen zu können, benötigen Sie Zugriff auf die Eigenschaftseinstellungen der Ressource. Das DSDL-Dienstprogramm scds_initialize() vereinheitlicht den Zugriff auf die Ressourceneigenschaften. Diese Funktion ist dafür ausgelegt, zu Beginn jeder Rückmeldemethode aufgerufen zu werden. Die Dienstprogrammfunktion ruft alle Eigenschaften einer Ressource aus dem Cluster Framework ab und stellt sie der Familie der scds_getName()-Funktionen zur Verfügung.

Dieses Kapitel behandelt die folgenden Themen:

Die RTR-Datei

Die Ressourcentyp-Registrierungsdatei (RTR-Datei) ist ein wesentlicher Bestandteil eines Ressourcentyps. Diese Datei gibt die Details des Ressourcentyps für Sun Cluster an. Diese Details umfassen Informationen wie die Eigenschaften, die von der Implementierung benötigt werden, die Datentypen der Eigenschaften, die Standardwerte der Eigenschaften, den Dateisystempfad für die Rückmeldemethoden der Ressourcentypimplementierung sowie verschiedene Einstellungen für die systemdefinierten Eigenschaften.

Die Beispiel-RTR-Datei, die mit der DSDL geliefert wird, dürfte für die meisten Ressourcentypimplementierungen ausreichen. Sie brauchen lediglich einige grundlegende Elemente zu bearbeiten, wie zum Beispiel den Ressourcentypnamen und den Pfadnamen der Rückmeldemethoden für den Ressourcentyp. Wenn für die Implementierung des Ressourcentyps eine neue Eigenschaft benötigt wird, können Sie diese als Erweiterungseigenschaft in der Ressourcentyp-Registrierungsdatei (RTR-Datei) der Ressourcentypimplementierung deklarieren und dann über das DSDL-Dienstprogramm scds_get_ext_property() auf die neue Eigenschaft zugreifen.

Die Validate-Methode

Die Validate-Methode einer Ressourcentypimplementierung wird von RGM in zwei Szenarien aufgerufen: 1) wenn eine neue Ressource des Ressourcentyps erstellt wird, und 2) wenn eine Eigenschaft der Ressource bzw. der Ressourcengruppe aktualisiert wird. Diese beiden Szenarios können durch die Befehlszeilenoption -c (creation, Erstellung) bzw. -u (update, Aktualisierung) unterschieden werden, die an die Validate-Methode der Ressource übergeben werden.

Die Validate-Methode wird auf jedem Knoten einer Knotengruppe aufgerufen, wobei die Knotengruppe durch den Wert der Ressourcentypeigenschaft INIT_NODES definiert wird. Wenn INIT_NODES auf RG_PRIMARIES eingestellt ist, wird Validate auf jedem Knoten aufgerufen, der Host (Primärknoten) der die Ressource enthaltenden Ressourcengruppe sein kann. Wenn INIT_NODES auf RT_INSTALLED_NODES eingestellt ist, wird Validate auf jedem Knoten aufgerufen, auf dem die Ressourcentypsoftware installiert ist. Das sind normalerweise alle Knoten im Cluster. Der Standardwert für INIT_NODES ist RG_PRIMARIES (siehe rt_reg(4). Zu dem Zeitpunkt, an dem die Validate-Methode aufgerufen wird, hat RGM die Ressource noch nicht erstellt (im Fall einer Rückmeldungserstellung) bzw. hat die aktualisierten Werte der zu aktualisierenden Eigenschaften noch nicht angewendet (im Fall einer Rückmeldungsaktualisierung). Der Zweck der Validate-Rückmeldemethode einer Ressourcentypimplementierung ist es zu prüfen, ob die vorgeschlagenen Ressourceneinstellungen (angegeben durch die vorgeschlagenen Eigenschaftseinstellungen für die Ressource) für den Ressourcentyp akzeptabel sind.

Hinweis –

Wenn Sie von HAStoragePlus verwaltete lokale Dateisysteme verwenden, wird mit dem Befehl scds_hasp_check der Zustand der HAStoragePlus-Ressource überprüft. Diese Informationen werden aus dem Zustand (online oder anderweitig) aller SUNW.HAStoragePlus(5)-Ressourcen abgerufen, von denen die Ressource abhängt, und zwar unter Verwendung der für die Ressource definierten Systemeigenschaften Resource_dependencies oder Resource_dependencies_weak. .Unter scds_hasp_check(3HA) finden Sie eine vollständige Liste der vom scds_hasp_check-Aufruf zurückgegebenen Statuscodes.

Die DSDL-Funktion scds_initialize() verfährt in diesen Situationen folgendermaßen:

Angenommen, die Funktion, welche die Validierung der Eigenschaften einer Ressource implementiert, wird als svc_validate() bezeichnet und verwendet die scds_get_Name()-Funktionsfamilie zum Untersuchen der Eigenschaft, die validiert werden soll. Ferner wird angenommen, dass eine akzeptable Ressourceneinstellung durch einen Rückgabecode von 0 von dieser Funktion dargestellt wird. Die Validate-Methode kann dann durch das folgende Codefragment dargestellt werden: 


int
main(int argc, char *argv[])
{
   scds_handle_t handle;
   int rc;

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Initialisierungsfehler */
   }
   rc = svc_validate(handle);
   scds_close(&handle);
   return (rc);
}

Die Validierungsfunktion muss auch den Grund für den Fehlschlag der Ressourcenvalidierung protokollieren. Ohne auf weitere Einzelheiten einzugehen (im folgenden Kapitel sehen Sie eine realistischere Darstellung einer Validierungsfunktion), kann ein einfaches Beispiel einer svc_validate()-Funktion folgendermaßen implementiert werden: 


int
svc_validate(scds_handle_t handle)
{
   scha_str_array_t *confdirs;
   struct stat    statbuf;
   confdirs = scds_get_confdir_list(handle);
   if (stat(confdirs->str_array[0], &statbuf) == -1) {
   return (1);   /* Ungültige Ressourceneigenschaftseinstellung */
   }
   return (0);   /* Akzeptable Einstellung */
}

Der Ressourcentypentwickler muss sich also nur um die Implementierung der svc_validate()-Funktion kümmern. Ein typisches Beispiel für eine Ressourcentypimplementierung wäre die Prüfung, ob eine Anwendungskonfigurationsdatei mit dem Namen app.conf unter der Confdir_list-Eigenschaft vorhanden ist. Sie kann einfach durch einen stat()-Systemaufruf an den entsprechenden Pfadnamen, abgeleitet aus der Confdir_list-Eigenschaft, implementiert werden.

Die Start-Methode

Die Start-Rückmeldemethode einer Ressourcentypimplementierung wird von RGM auf einem bestimmten Cluster-Knoten aufgerufen, um die Ressource zu starten. Der Ressourcengruppenname, der Ressourcenname und der Ressourcentypname werden an die Befehlszeile übergeben. Die Start-Methode soll die erforderlichen Aktionen ausführen, um eine Datendienstressource auf dem Cluster-Knoten zu starten. In der Regel müssen hierfür die Ressourceneigenschaften abgerufen, die anwendungsspezifischen ausführbaren Dateien und/oder Konfigurationsdateien gesucht und die Anwendung mit den entsprechenden Befehlszeilenargumenten gestartet werden.

Bei Einsatz der DSDL wird die Ressourcenkonfiguration bereits von dem scds_initialize()-Dienstprogramm abgerufen. Die Startaktion für die Anwendung kann in einer svc_start()-Funktion enthalten sein. Eine weitere Funktion, svc_wait(), kann aufgerufen werden, um zu überprüfen, dass die Anwendung tatsächlich startet. Der vereinfachte Code für die Start-Methode sieht folgendermaßen aus: 


int
main(int argc, char *argv[])
{
   scds_handle_t handle;

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Initialisierungsfehler */
   }
   if (svc_validate(handle) != 0) {
   return (1);   /* Ungültige Einstellungen */
   }
   if (svc_start(handle) != 0) {
   return (1);   /* Start fehlgeschlagen */
   }
   return (svc_wait(handle));
}

Diese Start-Methodenimplementierung ruft svc_validate()auf, um die Ressourcenkonfiguration zu validieren. Falls sie fehlschlägt, entspricht entweder die Ressourcenkonfiguration nicht der Anwendungskonfiguration, oder es besteht zurzeit auf diesem Cluster-Knoten ein Problem bezüglich des Systems. Es kann zum Beispiel sein, dass ein für die Ressource erforderliches globales Dateisystem zurzeit auf diesem Cluster-Knoten nicht verfügbar ist. In diesem Fall ist jeder Startversuch der Ressource auf diesem Cluster-Knoten zwecklos. Stattdessen sollte RGM versuchen, die Ressource auf einem anderen Knoten zu starten. Beachten Sie jedoch, dass in obigem Beispiel davon ausgegangen wird, dass svc_validate () ausreichend konservativ ist, also nur die Ressourcen auf dem Cluster-Knoten prüft, die für die Anwendung unbedingt erforderlich sind. Andernfalls kann der Start der Ressource auf allen Cluster-Knoten fehlschlagen, und sie wird in den START_FAILED-Zustand versetzt. In scswitch( 1M) und Sun Cluster Data Services Planning and Administration Guide for Solaris OS finden Sie eine Erläuterung dieses Zustands.

Die svc_start()-Funktion muss 0 für ein erfolgreiches Starten der Ressource auf dem Knoten zurückgeben. Wenn die Startfunktion auf ein Problem stößt, muss sie einen Wert ungleich Null zurückgeben. Bei Fehlschlagen dieser Funktion versucht RGM, die Ressource auf einem anderen Cluster-Knoten zu starten.

Um die DSDL so weit wie möglich zu nutzen, kann die svc_start()-Funktion das Dienstprogramm scds_pmf_start() verwenden, um die Anwendung unter PMF (Process Management Facility) zu starten. Dieses Dienstprogramm setzt auch die Fehlschlag-Rückmeldeaktion von PMF ein (siehe Aktions-Flag -a in pmfadm( 1M)), um die Prozessfehlschlagerkennung zu implementieren.

Die Stop-Methode

Die Stop-Rückmeldemethode einer Ressourcentypimplementierung wird von RGM auf einem Cluster-Knoten aufgerufen, um die Anwendung zu stoppen. Für die Rückmeldesemantik der Stop-Methode gelten folgende Voraussetzungen:

Das DSDL-Dienstprogramm scds_pmf_stop() düfte für die meisten Anwendungen ausreichend sein. Es versucht zunächst, die Anwendung weich zu stoppen (mithilfe von SIGTERM), wobei sie davon ausgeht, dass die Anwendung unter PMF über scds_pmf_start() gestartet wurde. Darauf folgt SIGKILL, um das Beenden des Prozesses zu erzwingen. Einzelheiten zu diesem Dienstprogramm finden Sie unter PMF-Funktionen.

Dem bislang hier verwendeten Codemodell entsprechend, und ausgehend von der Annahme, dass die anwendungsspezifische Funktion zum Stoppen der Anwendung svc_stop() ist (ob die Implementierung von svc_stop() die scds_pmf_stop()-Methode verwendet, spielt hier keine Rolle, und hängt davon ab, ob die Methode unter PMF über die Start-Methode gestartet wurde), kann die Stop-Methode folgendermaßen implementiert werden: 

if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR)
{
   return (1);   /* Initialisierungsfehler */
}
return (svc_stop(handle));

Die svc_validate()-Methode wird in der Implementierung der Stop-Methode nicht verwendet, denn die Stop-Methode muss selbst bei einem aktuellen Systemproblem versuchen, die Anwendung auf diesem Knoten zu stoppen.

Die Monitor_start-Methode

RGM ruft die Monitor_start-Methode auf, um einen Fehler-Monitor für die Ressource zu starten. Fehler-Monitore überwachen die Fehlerfreiheit der Anwendung, die von der Ressource verwaltet wird. Ressourcentypimplementierungen implementieren einen Fehler-Monitor in der Regel als eigenen Dämon, der im Hintergrund ausgeführt wird. Die Monitor_start-Rückmeldemethode wird verwendet, um diesen Dämon mit den entsprechenden Argumenten zu starten.

Da beim Monitor-Dämon selbst ebenfalls Fehler auftreten können (er könnte zum Beispiel versagen und die Anwendung unüberwacht zurücklassen), wird empfohlen, den Monitor-Dämon über PMF zu starten. Das DSDL-Dienstprogramm scds_pmf_start() verfügt über integrierte Unterstützung für das Starten von Fehler-Monitoren. Dieses Dienstprogramm verwendet den relativen Pfadnamen (relativ zum RT_basedir für den Speicherort der Ressourcentyp-Rückmeldemethodenimplementierungen) des Monitor-Dämonprogramms. Es verwendet die von der DSDL verwalteten Erweiterungseigenschaften Monitor_retry_interval und Monitor_retry_count, um zu verhindern, dass der Dämon eine unbegrenzte Anzahl von Malen neu gestartet wird. Dabei ist die gleiche Befehlszeilensyntax, die für alle Rückmeldemethoden definiert ist (also -R Ressource -G Ressourcengruppe -T Ressourcentyp) auch für den Monitor-Dämon verbindlich, auch wenn dieser nie direkt von RGM aufgerufen wird. Dadurch wird es der Monitor-Dämonimplementierung selbst ermöglicht, das scds_initialize()-Dienstprogramm zum Konfigurieren der eigenen Umgebung einzusetzen. Die Hauptarbeit besteht im Entwerfen des Monitor-Dämons selbst.

Die Monitor_stop-Methode

RGM ruft die Monitor_stop-Methode zum Stoppen des Fehler-Monitor-Dämons auf, der über die Monitor_start-Methode gestartet wurde. Ein Fehlschlag dieser Rückmeldemethode wird genauso wie ein Fehlschlag der Stop-Methode behandelt; daher muss die Monitor_stop-Methode idempotent und robust wie die Stop-Methode sein.

Wenn Sie das Dienstprogramm scds_pmf_start() zum Starten des Fehler-Monitor-Dämons verwenden, müssen Sie scds_pmf_stop() verwenden, um ihn zu stoppen.

Die Monitor_check-Methode

Die Monitor_check-Rückmeldemethode für eine Ressource wird auf einem Knoten für die angegebene Ressource aufgerufen, um sicherzstellen, dass der Cluster-Knoten in der Lage ist, die Ressource zu unterstützen, dass heißt, dass die von der Ressource verwalteten Anwendungen auf dem Knoten erfolgreich ausgeführt werden können.). In der Regel muss dabei sichergestellt werden, dass die von der Anwendung benötigten Systemressourcen auch tatsächlich auf dem Cluster-Knoten verfügbar sind. Wie unter Die Validate-Methode erläutert, muss die vom Entwickler implementierte svc_validate()-Funktion zumindest diesen Punkt überprüfen.

Abhängig von der spezifischen Anwendung, die von der Ressourcentypimplementierung verwaltet wird, kann die Monitor_check-Methode für das Ausführen einiger weiterer Aufgaben geschrieben werden. Die Monitor_check-Methode muss so implementiert werden, dass sie nicht im Konflikt mit anderen gleichzeitig ausgeführten Methoden gerät. Wenn die Entwickler die DSDL einsetzen, wird empfohlen, für die Monitor_check-Methode die svc_validate()-Funktion zu nutzen, die eigens zur Implementierung der anwendungsspezifischen Validierung von Ressourceneigenschaften geschrieben wurde.

Die Update-Methode

RGM ruft die Update-Methode einer Ressourcentypimplementierung auf, um alle Änderngen anzuwenden, die vom Systemverwalter an der Konfiguration einer aktiven Ressource vorgenommen wurden. Die Update-Methode wird nur auf denjenigen Knoten aufgerufen, auf denen die Ressource aktuell online ist (falls zutreffend).

Die zuvor an der Ressourcenkonfiguration vorgenommenen Änderungen sind mit Sicherheit für die Ressourcentypimplementierung akzeptabel, da RGM die Validate-Methode des Ressourcentyps vor der Update-Methode ausführt. Die Validate-Methode wird aufgerufen, bevor die Ressourcen- bzw. Ressourcengruppeneigenschaften geändert werden, und die Validate-Methode kann die vorgeschlagenen Änderungen ablehnen. Die Update-Methode wird aufgerufen, nachdem die Änderungen angewendet wurden, damit die aktive (sich online befindende) Ressource auf die neuen Einstellungen aufmerksam gemacht wird.

Als Ressourcentypentwickler müssen Sie sich genau überlegen, welche Eigenschaften zur dynamischen Aktualisierung fähig sein sollen, und diese mit der TUNABLE = ANYTIME-Einstellung in der RTR-Datei markieren. In der Regel können Sie angeben, dass jede Eigenschaft einer Ressourcentypimplementierung, die vom Fehler-Monitor-Dämon verwendet wird, dynamisch aktualisiert werden kann. Voraussetzung dafür ist, dass die Update-Methodenimplementierung zumindest den Monitor-Dämon neu startet.

Mögliche Kandidaten sind:

Diese Eigenschaften wirken sich auf die Art und Weise aus, in der ein Fehler-Monitor-Dämon die Fehlerfreiheit des Dienstes prüft, wie oft dies geschieht, welches Historienintervall zum Verfolgen der Fehler verwendet wird und welche Neustart-Grenzwerte von PMF eingestellt werden. Zum Implementieren dieser Eigenschaften wird in der DSDL das Dienstprogramm scds_pmf_restart () bereitgestellt.

Wenn Sie eine Ressourceneigenschaft dynamisch aktualisieren müssen, die Änderung dieser Eigenschaft sich jedoch auf die laufende Anwendung auswirken könnte, müssen Sie die entsprechenden Aktionen implementieren, damit die Aktualisierungen der Eigenschaft für alle laufenden Instanzen dieser Anwendung korrekt angewendet werden. Derzeit ist dies nicht über die DSDL möglich. An Update werden die geänderten Eigenschaften nicht an der Befehlszeile übergeben (wie dies bei Validate der Fall ist).

Die Init-, Fini- und Boot-Methoden

Dies sind einmalige Aktionsmethoden, entsprechend der Definition in den Spezifikationen der Ressourcenverwaltungs-API. Die Beispielimplementierung für die DSDL zeigt die Verwendung dieser Methoden nicht. Alle Funktionen der DSDL stehen jedoch auch für diese Methoden zur Verfügung, wenn der Ressourcentypentwickler die Methoden benötigen sollte. In der Regel dienen die Init- und die Boot-Methode dem gleichen Zweck für eine Ressourcentypimplementierung, um eine einmalige Aktion zu implementieren. Die Fini-Methode führt in der Regel eine Aktion zum Rückgängigmachen der Aktionen einer Init- oder Boot-Methode aus.

Entwerfen des Fehler-Monitor-Dämons

Ressourcentypimplementierungen, welche die DSDL verwenden, verfügen in der Regel über einen Fehler-Monitor-Dämon mit folgenden Aufgaben:

Die DSDL-Dienstprogramme sind so ausgelegt, dass die Hauptschleife des Fehler-Monitor-Dämons durch den folgenden Pseudocode dargestellt werden kann.

Für Fehler-Monitore, die unter Verwendung der DSDL implementiert wurden, gilt:

In den meisten Fällen kann die anwendungsspezifische Gesundheits-Checkaktion in einem eigenständigen Dienstprogramm (zum Beispiel svc_probe()) implementiert und in diese generische Hauptschleife integriert werden. 


for (;;) {

   / * Für die Dauer von thorough_probe_interval zwischen den
   *  einzelnen Testsignalen ruhen. */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));

   /* Jetzt alle verwendeten IP-Adressen testen. Schleife über:
   * 1. Allen verwendeten Netzwerkressourcen.
   * 2. Allen IP-Adressen in einer bestimmten Ressource.
   * Für jede getestete IP-Adresse
   * Fehlschlaghistorie berechnen. */
   probe_result = 0;
   /* Für alle Ressourcen wiederholen, um jede IP-Adresse
    * für den Aufruf von svc_probe() abzurufen */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Hostname und Port für Überwachung der
   * Fehlerfreiheit erfassen.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS unterstützt nur einen Port. Daher den
   * Port-Wert aus dem ersten Eintrag im
   * Port-Array abrufen.
   */
   ht1 = gethrtime(); /* Testsignal-Startzeit festhalten */
   probe_result = svc_probe(scds_handle,

   hostname, port, timeout);
   /*
   * Testsignalhistorie des Dienstes aktualisieren,
   * bei Bedarf Aktionen ausführen.
   * Testsignal-Endzeit festhalten.
   */
   ht2 = gethrtime();
   /* In Millisekunden konvertieren */
   dt = (ulong_t)((ht2 - ht1) / 1e6);

   /*
   * Fehlschlaghistorie berechnen und
   * bei Bedarf Aktionen ausführen
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Jede Netzwerkressource */
   }       /* Endlos weitertesten */