Implementación de los métodos de rellamada

Esta sección proporciona información relativa a la implantación de los métodos de rellamada en general.

Acceso a la información de las propiedades de los recursos y grupos de recursos

Generalmente, los métodos de rellamada requieren acceso a las propiedades del recurso. RMAPI proporciona comandos de shell y funciones de C que se pueden usar en métodos de rellamada para acceder a las propiedades de los recursos, tanto las de extensión como las definidas por el sistema. Consulte las páginas de comando man scha_resource_get(1HA) y scha_resource_get(3HA).

DSDL proporciona un conjunto de funciones de C (una para cada propiedad) para acceder a propiedades definidas por el sistema y una función para acceder a las propiedades de extensión. Consulte las páginas de comando man scds_property_functions(3HA) y scds_get_ext_property(3HA).

No se puede utilizar el mecanismo de propiedad para almacenar información de estado dinámico para un servicio de datos porque no hay funciones de API disponibles para establecer las propiedades de recursos (aparte de para establecer Status y Status_msg). En su lugar, se debe almacenar la información de estado dinámico en los archivos globales.

El administrador del clúster puede establecer determinadas propiedades de recurso con el comando scrgadm o, si los tiene disponibles, con un comando o una interfaz administrativos gráficos. Sin embargo, no invoque scrgadm desde ningún método de rellamada porque scrgadm falla durante la reconfiguración de clúster, es decir, cuando RGM invoca el método.

Idempotencia de métodos

En general, RGM no llama a un método más de una vez seguida en el mismo recurso y con los mismos argumentos. Sin embargo, si un método Start falla, RGM podría llamar a un método Stop en un recurso, aunque éste no se haya iniciado nunca. Del mismo modo, un daemon de recurso podría terminarse de forma autónoma y RGM podría aún invocar su método Stop en él. Lo mismo se aplica a los métodos Monitor_start y Monitor_stop.

Por esta causa, se debe aplicar la idempotencia a los métodos Stop y Monitor_stop. Repetidas llamadas de Stop o Monitor_stop en el mismo recurso con los mismos parámetros logran los mismos resultados que una sola llamada.

Una implicación de la idempotencia es que Stop y Monitor_stop debe devolver 0 (satisfactorio) aunque el recurso o supervisor ya esté detenido y no haya ninguna tarea que realizar.

Los métodos Init, Fini, Boot y Update debe ser también idempotentes. No es necesario que lo sea el método Start.