Implementación de los métodos de rellamada

Esta sección proporciona información general sobre la implementación de los métodos de rellamada.

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

Normalmente, los métodos de rellamada necesitan acceder 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 la páginas de comando man scha_resource_get(1HA) y scha_resource_get(3HA).

DSDL proporciona un conjunto de funciones de C (una función para cada propiedad) para acceder a las 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 la información de estado dinámico del servicio de datos, ya que no hay disponible ninguna función de la API que permita establecer otras propiedades de recursos diferentes a 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 las propiedades de recursos con el comando scrgadm, o mediante una interfaz o comando administrativo gráfico. Sin embargo, no se debe invocar scrgadm desde ningún método de rellamada porque scrgadm fallará durante la reconfiguración del clúster, es decir, cuando RGM llame al 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 Start falla, RGM puede llamar al método Stop en un recurso, aunque éste nunca se haya iniciado. Del mismo modo, un daemon del recurso puede desactivarse espontáneamente y, aún así, RGM puede seguir ejecutando el método Stop en él. Esto mismo se aplica también a los métodos Monitor_start y Monitor_stop.

Por estos motivos, se puede lograr que los métodos Stop y Monitor_stop sean idempotentes. Varias llamadas de Stop or Monitor_stop en el mismo recurso con los mismos argumentos logran los mismos resultados que una única 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 deben también ser idempotentes. No es necesario que lo sea el método Start.