Implementieren von Rückmeldemethoden

Dieser Abschnitt liefert allgemeine Informationen, die sich auf die Implementierung von Rückmeldemethoden beziehen.

Zugreifen auf Informationen über Ressourcen- und Ressourcengruppeneigenschaften

Im Allgemeinen ist für Rückmeldemethoden Zugriff auf die Ressourceneigenschaften erforderlich. Die RMAPI stellt sowohl Shell-Befehle als auch C-Funktionen bereit, die Sie in Rückmeldemethoden für den Zugriff auf systemdefinierte und Erweiterungseigenschaften von Ressourcen verwenden können. Weitere Informationen finden Sie in der Online-Dokumentation unter scha_resource_get(1HA) und scha_resource_get(3HA).

Die DSDL bietet einen Satz C-Funktionen (eine Funktion für jede Eigenschaft), um auf systemdefinierte Eigenschaften zuzugreifen, sowie eine Funktion für den Zugriff auf Erweiterungseigenschaften. Weitere Informationen finden Sie in der Online-Dokumentation unter scds_property_functions(3HA) und scds_get_ext_property(3HA).

Sie können den Eigenschaftenmechanismus nicht zum Speichern von dynamischen Zustandsinformationen für einen Datendienst verwenden, weil keine API-Funktionen zum Festlegen von anderen Ressourceneigenschaften als Status und Status_msg zur Verfügung stehen. Stattdessen müssen Sie dynamische Zustandsinformationen in globalen Dateien speichern.

Der Cluster-Administrator kann bestimmte Ressourceneigenschaften mit dem scrgadm-Befehl oder über einen grafischen Verwaltungsbefehl oder eine Schnittstelle festlegen. Rufen Sie jedoch scrgadm nicht von einer Rückmeldemethode auf, weil scrgadm während der Cluster-Neukonfiguration, d.h. beim Aufrufen der Methode durch RGM, fehlschlägt.

Idempotenz für Methoden

Im Allgemeinen ruft RGM keine Methode mehr als einmal nacheinander für die gleiche Ressource mit den gleichen Argumenten auf. Wenn jedoch eine Start-Methode fehlschlägt, könnte RGM für eine Ressource eine Stop-Methode aufrufen, obwohl die Ressource niemals gestartet wurde. Genauso könnte ein Ressourcendämon von selbst anhalten und RGM weiterhin die Stop-Methode dafür ausführen. Dieselben Szenarien gelten für die Monitor_start- und Monitor_stop-Methoden.

Aus diesem Grund müssen Sie in die Stop- und Monitor_stop-Methoden Idempotenz integrieren. Wiederholte Aufrufe von Stop oder Monitor_stop für dieselbe Ressource mit denselben Argumenten führen zu denselben Ergebnissen wie ein einzelner Aufruf.

Eine Auswirkung der Idempotenz ist, dass Stop und Monitor_stop 0 (Erfolg) zurückgeben müssen, auch wenn die Ressource bzw. der Monitor bereits gestoppt ist und keine Aufgabe ausgeführt wird.

Die Init-, Fini-, Boot- und Update-Methoden müssen ebenfalls idempotent sein. Eine Start-Methode muss nicht idempotent sein.