Kapitel 6 Data Service Development Library

Dieses Kapitel bietet einen Überblick über die Anwendungsprogrammierschnittstellen, aus denen sich die Data Service Development Library (DSDL) zusammensetzt. Die DSDL ist in der libdsdev.so-Bibliothek implementiert und im Sun Cluster-Paket enthalten.

Dieses Kapitel behandelt die folgenden Themen:

• Überblick über die DSDL

• Verwalten von Konfigurationseigenschaften

• Starten und Stoppen eines Datendienstes

• Implementieren eines Fehler-Monitors

• Zugreifen auf Netzwerkadressinformationen

• Beheben von Fehlern bei der Ressourcentypimplementierung

• Aktivieren von hoch verfügbaren lokalen Dateisystemen

Überblick über die DSDL

Die DSDL-API befindet sich auf der RMAPI (Resource Management Application Programming Interface, Ressourcenverwaltungs-Anwendungsprogrammierschnittstelle). Als solche ersetzt die DSDL-API die RMAPI nicht, sondern kapselt sie ein und erweitert die RMAPI-Funktionen. Die DSDL vereinfacht die Datendienstentwicklung, indem sie vorentwickelte Lösungen für bestimmte Sun Cluster-Integrationsfragen bereitstellt. Folglich können Sie den Großteil der Entwicklungszeit den Themen der hohen Verfügbarkeit und Skalierbarkeit ihrer Anwendung widmen. Sie verbringen weniger Zeit mit der Integration der Anwendungsstart-, -beendigungs- und -überwachungsverfahren in Sun Cluster.

Verwalten von Konfigurationseigenschaften

Alle Rückmeldemethoden setzen den Zugriff auf die Konfigurationseigenschaften voraus. Die DSDL unterstützt den Zugriff auf die Eigenschaften durch Folgendes:

• Initialisieren der Umgebung,

• Bereitstellen eines Satzes praktischer Funktionen zum Abrufen von Eigenschaftswerten.

Die scds_initialize()-Funktion, die zu Beginn jeder Rückmeldemethode aufgerufen werden muss, führt folgende Aktionen aus:

• Sie prüft und verarbeitet die Befehlszeilenargumente (argc und argv[]), die von RGM an die Rückmeldemethode übergeben werden, so dass Sie keine Befehlszeilen-Parsing-Funktion schreiben müssen.

• Sie konfiguriert interne Datenstrukturen, die von anderen DSDL-Funktionen verwendet werden können. So speichern zum Beispiel die Funktionen, die Eigenschaftswerte von RGM abrufen, die Werte in diesen Strukturen. Auf ähnliche Weise werden Werte der Befehlszeile, die vor Werten Vorrang haben, die von RGM abgerufen werden, in diesen Datenstrukturen gespeichert.

• Initialisiert die Protokollierungsumgebung und validiert die Testsignaleinstellungen des Fehler-Monitors.

Für die Validate-Methode parst scds_initialize () die Eigenschaftswerte, die in der Befehlszeile übergeben werden, sodass Sie keine Parse-Funktion für Validate schreiben müssen.

Die DSDL bietet Sätze von Funktionen, um Ressourcentyp-, Ressourcen- und Ressourcengruppeneigenschaften sowie häufig verwendete Erweiterungseigenschaften abzurufen. Diese Funktionen standardisieren den Zugriff auf die Eigenschaften unter Berücksichtigung der folgenden Konventionen:

• Jede Funktion übernimmt nur ein Handle-Argument (zurückgegeben von scds_initialize()).

• Jede Funktion entspricht einer bestimmten Eigenschaft. Der Rückgabewerttyp der Funktion entspricht dem Typ des abgerufenen Eigenschaftswerts.

• Funktionen geben keine Fehler zurück, da die Werte von scds_initialize() vorberechnet wurden. Funktionen rufen Werte von RGM ab, es sei denn, es wird ein neuer Wert an die Befehlszeile übergeben.

Starten und Stoppen eines Datendienstes

Eine Start-Methode führt die Aktionen durch, die zum Starten eines Datendienstes auf einem Cluster-Knoten erforderlich sind. In der Regel beinhaltet dies das Abrufen der Ressourceneigenschaften, das Auffinden anwendungsspezifischer ausführbarer Dateien und Konfigurationsdateien sowie das Starten der Anwendung mit den richtigen Befehlszeilenargumenten.

Die scds_initialize()-Funktion ruft die Ressourcenkonfiguration ab. Die Start-Methode kann Eigenschaftsfunktionen zum Abrufen von Werten für bestimmte Eigenschaften, wie Confdir_list, verwenden, die die Konfigurationsverzeichnisse und Dateien für das Starten der Anwendung identifizieren.

Eine Start-Methode kann scds_pmf_start() aufrufen, damit eine Anwendung unter PMF gestartet wird. Mit PMF können Sie die Überwachungsebene für den Prozess angeben. Außerdem bietet sie die Möglichkeit, den Prozess im Falle eines Fehlers neu zu starten. Unter xfnts_start-Methode finden Sie ein Beispiel für eine in DSDL implementierte Start-Methode.

Eine Stop-Methode muss überall identisch sein, sodass sie erfolgreich beendet wird, selbst wenn sie an einem Knoten aufgerufen wird, wenn die Anwendung nicht ausgeführt wird. Wenn die Stop-Methode fehlschlägt, wird die angehaltene Ressource in den Zustand STOP_FAILED versetzt, was zu einem harten Neustart des Clusters führen kann.

Um zu vermeiden, dass die Ressource in den Zustand STOP_FAILED versetzt wird, muss die Stop-Methode alles versuchen, um die Ressource zu stoppen. Die scds_pmf_stop()-Funktion bietet einen in Phasen aufgeteilten Versuch, die Ressource zu stoppen. Diese Funktion versucht zunächst, die Ressource mit dem Signal SIGTERM zu stoppen und verwendet bei einem Fehlschlag das Signal SIGKILL. Weitere Informationen finden Sie in der Online-Dokumentation zu scds_pmf_stop(3HA).

Implementieren eines Fehler-Monitors

Die DSDL bietet den hohen Grad an Komplexität, der mit der Implementierung eines Fehler-Monitors einhergeht, in Form eines bereits definierten Modells. Eine Monitor_start-Methode startet den Fehler-Monitor unter PMF, wenn die Ressource an einem Knoten gestartet wird. Der Fehler-Monitor wird in einer Schleife ausgeführt, solange die Ressource an dem Knoten ausgeführt wird. Die Logik eines DSDL-Fehler-Monitors lautet wie folgt:

• Die scds_fm_sleep()-Funktion verwendet die Eigenschaft Thorough_probe_interval, um den Zeitabstand zwischen den Testsignalen zu bestimmen. Sämtliche Anwendungsprozessfehler, die von PMF während dieses Zeitraums entdeckt werden, führen zu einem Neustart der Ressource.

• Das Testsignal selbst gibt einen Wert zurück, der den Schweregrad der Fehler angibt, von 0, kein Fehler, bis 100, Totalfehlschlag.

• Der Test-Rückgabewert wird an die scds_action()-Funktion gesendet, die ein kumulatives Fehlerprotokoll innerhalb des Zeitraums der Retry_interval-Eigenschaft verwaltet.

• Die scds_action()-Funktion ermittelt, wie im Falle eines Fehlers vorzugehen ist, wie folgt:

  • Wenn der kumulative Fehler unter 100 liegt, geschieht nichts.

  • Wenn der kumulative Fehler 100 (Totalfehlschlag) erreicht, starten Sie den Datendienst neu. Wenn Retry_interval überschritten ist, wird die Historie zurückgesetzt.

  • Wenn die Anzahl der Neustarts den Wert der Retry_count -Eigenschaft innerhalb des von Retry_interval festgelegten Zeitraums überschreitet, führen Sie einen Failover des Datendienstes durch.

Zugreifen auf Netzwerkadressinformationen

Die DSDL stellt praktische Funktionen bereit, mit denen Netzwerkadressinformationen für Ressourcen und Ressourcengruppen zurückgegeben werden. Zum Beispiel ruft scds_get_netaddr_list() die Netzwerkadressressourcen ab, die von einer Ressource verwendet werden, wodurch einem Fehler-Monitor das Testen der Anwendung ermöglicht wird.

Die DSDL enthält auch einen Satz Funktionen für die TCP-basierte Überwachung. In der Regel stellen diese Funktionen eine einfache Socket-Verbindung mit einem Dienst her, lesen und schreiben Daten an den Dienst und trennen die Verbindung vom Dienst. Das Testergebnis kann an die DSDL-Funktion scds_fm_action() gesendet werden, um über die auszuführende Aktion zu entscheiden.

Unter xfnts_validate-Methode finden Sie ein Beispiel für die TCP-basierte Fehlerüberwachung.

Beheben von Fehlern bei der Ressourcentypimplementierung

Die DSDL verfügt über integrierte Funktionen zum Beheben von Datendienstfehlern.

Das DSDL-Dienstprogramm scds_syslog_debug() bietet einen grundlegenden Rahmen, in dem der Ressourcentypimplementierung Fehlerbehebungsanweisungen hinzugefügt werden können. Die Stufen (von 1 bis 9) zur Fehlerbehebung können für jede Ressourcentypimplementierung an jedem Cluster-Knoten dynamisch festgelegt werden. Eine Datei namens /var/cluster/rgm/rt/rtname/loglevel, die lediglich eine Ganzzahl zwischen 1 und 9 enthält, wird von allen Ressourcentyp-Rückmeldemethoden gelesen. Die DSDL-Funktion scds_initialize() liest diese Datei und legt die Debug-Stufe intern auf die angegebene Stufe fest. Die Standard-Debug-Stufe 0 gibt an, dass der Datendienst keine Debug-Meldungen protokollieren soll.

Die scds_syslog_debug()-Funktion verwendet die Option, die von der scha_cluster_getlogfacility()-Funktion zurückgegeben wird, mit einer Priorität von LOG_DEBUG. Sie können diese Debug-Meldungen in der Datei /etc/syslog.conf konfigurieren.

Sie können einige Debug-Meldungen zum Zwecke eines normalen Betriebs des Ressourcentyps in Informationsmeldungen umwandeln (vielleicht mit der Priorität LOG_INFO), indem Sie die scds_syslog()-Funktion verwenden. Beachten Sie, dass in der DSDL-Beispielanwendung in Kapitel 8, Beispielressourcentyp-Implementierung mit DSDL die Funktionen scds_syslog_debug() und scds_syslog() sehr freizügig verwendet werden.

Aktivieren von hoch verfügbaren lokalen Dateisystemen

Sie können den HAStoragePlus -Ressourcentyp verwenden, um ein lokales Dateisystem innerhalb einer Sun Cluster-Umgebung hoch verfügbar zu machen. Die Partitionen des lokalen Dateisystems müssen sich auf globalen Plattengruppen befinden. Affinitäts-Switchover müssen aktiviert werden und die Sun Cluster-Umgebung muss für einen Failover konfiguriert werden. Mit diesem Setup kann der Cluster-Administrator jedes beliebige Dateisystem erstellen, das sich auf Multihost-Platten befindet, auf die von jedem beliebigen Host zugegriffen werden kann, der mit diesen Multihost-Platten direkt verbunden ist. Für einige E/A-intensive Datendienste wird die Verwendung eines hoch verfügbaren lokalen Dateisystems dringend empfohlen. Enabling Highly Available Local File Systems in Sun Cluster Data Services Planning and Administration Guide for Solaris OS enthält Informationen zur Konfiguration des Ressourcentyps HAStoragePlus.