Capítulo 6 Biblioteca de desarrollo del servico de datos (DSDL)

Este capítulo proporciona información general sobre las interfaces de programación de aplicaciones que componen la Biblioteca de desarrollo del servicio de datos o DSDL. Ésta se implementa en la biblioteca libdsdev.so y está incluida en el paquete de Sun Cluster.

En este capítulo se tratan los temas siguientes:

• Información general sobre DSDL

• Gestión de las propiedades de configuración

• Inicio y parada de un servicio de datos

• Implementación de un supervisor de fallos

• Acceso a la información de dirección de la red

• Depuración de la implementación del tipo de recurso

Información general sobre DSDL

La API de DSDL está estratificada sobre RMAPI. De este modo no anula ésta, sino que encapsula y amplía sus funciones. DSDL simplifica el desarrollo de servicios de datos aportando soluciones predeterminadas a cuestiones concretas de integración de Sun Cluster. Así, es posible dedicar la mayor parte del tiempo de desarrollo a las cuestiones de alta disponibilidad y escalabilidad intrínsecas a la aplicación y evitar malgastar mucho tiempo en la integración de los procedimientos de encendido, apagado y supervisión en Sun Cluster.

Gestión de las propiedades de configuración

Todos los métodos de rellamada requieren acceso a las propiedades de configuración. DSDL admite el acceso a las propiedades mediante:

• La inicialización del entorno

• El suministro de un conjunto de funciones prácticas para recuperar los valores de las propiedades

La función scds_initialize, que se debe invocar al principio de todos los métodos de rellamada:

• Comprueba y procesa los argumentos de la línea de órdenes (argc y argv[]) que RGM pasa al método de rellamada, para evitar la necesidad de escribir una función de análisis de la línea de órdenes.

• Configura las estructuras de datos internos para que las utilicen otras funciones de DSDL. Por ejemplo, las funciones prácticas que recuperan los valores de propiedad de RGM guardan los valores en estas estructuras. También se almacenan en ellas los valores de la línea de órdenes, que priman sobre otros valores recuperados de RGM.

Para el método Validate, scds_initialize analiza los valores de propiedad que se pasan en la línea de órdenes, lo que evita tener que escribir una función de análisis para Validate.

La función scds_initialize inicializa también el entorno del registro y valida la configuración del análisis del supervisor de fallos.

DSDL proporciona conjuntos de funciones para recuperar las propiedades de recursos, tipos y grupos de recursos, además de las propiedades de extensión de uso común. Estas funciones estandarizan el acceso a las propiedades, con las convenciones siguientes.

• Cada función toma sólo un argumento de manejo (devuelto por scds_initialize).

• Cada función corresponde a una propiedad determinada. El tipo de valor de retorno de la función concuerda con el de la propiedad que recupera.

• Las funciones no devuelven errores, porque scds_initialize ha calculado previamente los valores. Las funciones recuperan valores de RGM salvo que se pase un nuevo valor a la línea de órdenes.

Inicio y parada de un servicio de datos

Se espera que un método Start realice las acciones necesarias para iniciar un servicio de datos en un nodo del clúster. Generalmente, esto incluye la recuperación de las propiedades de recurso, la localización de los archivos de configuración y ejecutables específicos de la aplicación y la ejecución de la aplicación con los argumentos de línea de órdenes correctos.

La función scds_initialize recupera la configuración de recursos. El método Start puede utilizar funciones convenientes de la propiedad para recuperar valores para propiedades específicas, como Confdir_list, que identifican los archivos y directorios de configuración para que se ejecute la aplicación.

Un método Start puede invocar scds_pmf_start para ejecutar una aplicación controlada por la Prestación del supervisor de procesos (PMF) que permite especificar el nivel de supervisión aplicable a los procesos y reiniciar éstos en caso de un fallo. Consulte Método xfnts_start para ver un ejemplo de un método Start implementado con DSDL.

Un método Stop debe ser idempotente para que salga de forma satisfactoria, aunque se invoque en un nodo cuando la aplicación no esté en ejecución. Si el método Stop falla, el recurso que se está parando se configura al estado STOP_FAILED, lo que puede llevar a un reinicio forzado del clúster.

Para evitar poner el recurso en el estado STOP_FAILED, el método Stop debe intentar detener el recurso como sea posible. La función scds_pmf_stop permite intentar detener el recurso gradualmente. En primer lugar intenta detenerlo con la señal de SIGTERM; si eso falla, utiliza una señal de SIGKILL. Consulte scds_pmf_stop(3HA) para obtener más detalles.

Implementación de un supervisor de fallos

DSDL absorbe una buena parte de la complejidad de implementar un supervisor de fallos, gracias a un modelo predeterminado. Un método Monitor_start ejecuta el supervisor de fallos, controlado por PMF, cuando el recurso se inicia en un nodo. El supervisor de fallos funciona en bucle mientras el recurso esté ejecutándose en el nodo. La lógica de alto nivel de un supervisor de fallos de DSDL es la siguiente:

• La función scds_fm_sleep utiliza la propiedad Thorough_probe_interval para determinar el tiempo entre análisis. Cualquier fallo de proceso de una aplicación que detecte PMF en ese intervalo provoca un reinicio del recurso.

• El análisis mismo devuelve un valor que indica la gravedad del fallo, de 0 (sin fallos) a 100 fallo total.

• El valor de retorno de la sonda se envia a la función scds_action, que mantiene un histórico de fallos acumulativo dentro del intervalo de la propiedad Retry_interval.

• La función scds_action determina lo que hay que hacer en caso de fallo, como se indica a continuación.

  • Si el fallo acumulativo está por debajo de 100, no hay que hacer nada.

  • Si el fallo acumulativo alcanza el valor de 100 (fallo total), se debe reiniciar el servicio de datos. Si se supera Retry_interval, hay que poner a cero el historial.

  • Si el número de reinicios supera el valor de la propiedad Retry_count, en el periodo que indica Retry_interval, se debe realizar una operación de recuperación de fallos del servicio de datos.

Acceso a la información de dirección de la red

DSDL proporciona funciones de conveniencia para devolver información de dirección de la red de recursos y grupos de recursos. Por ejemplo, scds_get_netaddr_list recupera los recursos de dirección de la red que utiliza un recurso, lo que permite que un supervisor de fallos analice la aplicación.

DSDL proporciona también un conjunto de funciones para la supervisión basada en TCP. Normalmente estas funciones establecen una conexión de zócalo simple con un servicio, leen y escriben datos al servicio y después desconectan del mismo. El resultado del análisis se puede enviar a la función scds_fm_action de DSDL para determinar qué acción hay que realizar.

Consulte Método xfnts_validate para ver un ejemplo de supervisión de fallos basada en TCP.

Depuración de la implementación del tipo de recurso

DSDL incorpora funciones integradas para ayudar a depurar el servicio de datos.

La utilidad scds_syslog_debug() de DSDL proporciona un marco básico para agregar instrucciones de depuración a la implementación del tipo de recurso. El nivel de depuración (un número entre 1-9) se puede establecer dinámicamente por implementación del tipo de recurso y el nodo del clúster. Un archivo con el nombre /var/cluster/rgm/rt/nombre_tipo_recurso/loglevel, que sólo contiene un número entero entre 1 y 9, lo leen todos los métodos de rellamada del tipo de recurso. La rutina DSDL scds_initialize() lee este archivo y establece internamente la depuración en el nivel especificado. El nivel predeterminado de depuración es 0: el servicio de datos no debe registrar ningún mensaje de depuración.

La función scds_syslog_debug() utiliza el recurso devuelto por la función scha_cluster_getlogfacility() con una prioridad de LOG_DEBUG. Estos mensajes de depuración se pueden configurar en /etc/syslog.conf.

Es posible convertir algunos mensajes de depuración en mensajes informativos para un funcionamiento habitual del tipo de recurso (tal vez en la prioridad LOG_INFO), mediante la utilidad scds_syslog. Si se observa la aplicación DSDL de ejemplo del Capítulo 8, se ve que utiliza de forma libre las funciones scds_syslog_debug y scds_syslog.

Habilitación de sistemas de archivos locales de alta disponibilidad

Se puede usar el tipo de recurso HAStoragePlus para hacer que un sistema de archivos local tenga una alta disponibilidad, dentro de un entorno Sun Cluster. Las particiones del sistema de archivos local deben ubicarse en grupos globales de disco. Se deben habilitar los conmutadores por afinidad y el entorno Sun Cluster debe configurarse para que admita la recuperación de fallos. Esta configuración permite que el usuario haga que todos los sistemas de archivos situados en discos con varios sistemas principales estén accesibles desde todos los sistemas conectados directamente a dichos discos. Se recomienda la utilización de un sistema de archivos local de alta disponibilidad para algunos servicios de datos de E/S intensiva. “Enabling Highly Available Local File Systems” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS contiene información sobre cómo configurar el recurso HAStoragePlus.