Guía de administración y planificación de servicios de datos de Oracle® Solaris Cluster 4.3

Salir de la Vista de impresión

Actualización: Agosto de 2016
 
 

Ajuste de los supervisores de fallos para los servicios de datos de Oracle Solaris Cluster

Cada servicio de datos proporcionado con el producto Oracle Solaris Cluster tiene un supervisor de fallos integrado. El supervisor de fallos realiza las siguientes funciones:

  • Detectar la finalización inesperada de procesos para el servidor del servicio de datos.

  • Comprobar el estado del servicio de datos.

El supervisor de fallos reside en el recurso que representa la aplicación para la que se escribió el servicio de datos. Este recurso se crea al registrar y configurar el servicio de datos. Para obtener más información, consulte la documentación del servicio de datos.

Las propiedades estándar y las propiedades de extensión de este recurso controlan el comportamiento del supervisor de fallos. Los valores predeterminados de estas propiedades determinan el comportamiento preestablecido del supervisor de fallos. El comportamiento preestablecido debe ser adecuado para la mayoría de las instalaciones de Oracle Solaris Cluster. Por lo tanto, debe ajustar un supervisor de fallos solo si debe modificar este comportamiento preestablecido.

El ajuste de un supervisor de fallos incluye las siguientes tareas:

Realice estas tareas cuando registre y configure el servicio de datos. Para obtener más información, consulte la documentación del servicio de datos.


Notas -  El supervisor de fallos de un recurso se inicia cuando se pone en línea el grupo que contiene el recurso. No es necesario iniciar el supervisor de fallos de forma explícita.

Definición del intervalo entre sondeos del supervisor de fallos

Para determinar si un recurso funciona correctamente, el supervisor de fallos sondea este recurso periódicamente. El intervalo entre los sondeos del supervisor de fallos afecta la disponibilidad del recurso y el rendimiento del sistema de la siguiente manera:

  • El intervalo entre los sondeos del supervisor de fallos afecta el tiempo necesario para detectar un fallo y responder a él. Por lo tanto, si reduce el intervalo entre los sondeos del supervisor de fallos, también disminuye el tiempo necesario para detectar un fallo y responder a él. Esta disminución mejora la disponibilidad del recurso.

  • Cada sondeo del supervisor de fallos consume recursos del sistema, como ciclos del procesador y memoria. Por lo tanto, si reduce el intervalo entre los sondeos del supervisor de fallos, también disminuye el rendimiento del sistema.

El intervalo óptimo entre los sondeos del supervisor de fallos también depende del tiempo necesario para responder a un fallo en el recurso. Este tiempo depende de la manera en que la complejidad del recurso afecta el tiempo necesario para las operaciones, como el reinicio del recurso.

Para definir el intervalo entre los sondeos del supervisor de fallos, establezca la propiedad estándar Thorough_probe_interval del recurso en el intervalo en los segundos requeridos.

Definición del timeout de los sondeos del supervisor de fallos

El timeout de los sondeos del supervisor de fallos especifica el tiempo que espera un supervisor de fallos para recibir una respuesta de un recurso a un sondeo. Si el supervisor de fallos no recibe una respuesta dentro de este timeout, considera que el recurso es defectuoso. El tiempo que un recurso necesita para responder a un sondeo del supervisor de fallos depende de las operaciones que el supervisor de fallos realiza para sondear el recurso. Para obtener información sobre las operaciones que el supervisor de fallos de un servicio de datos realiza para sondear un recurso, consulte la documentación del servicio de datos.

El tiempo necesario para que un recurso responda también depende de factores que no están relacionados con el supervisor de fallos ni la aplicación, por ejemplo:

  • Configuración del sistema

  • Configuración del cluster

  • Carga del sistema

  • Cantidad de tráfico de red

Para definir el timeout de los sondeos del supervisor de fallos, establezca la propiedad de extensión Probe_timeout del recurso en el timeout en segundos requerido.

Para los sondeos del supervisor de fallos de la mayoría de los tipos de recursos, también puede configurar la propiedad Timeout_threshold para que envíe una notificación cuando el tiempo de ejecución de sondeo esté cerca del límite de timeout. Estas notificaciones pueden ayudarlo a identificar timeouts de sondeo demasiado bajos, que pueden provocar un failover falso. Para obtener más información acerca de la propiedad Timeout_threshold, consulte la página del comando man r_properties(5).

Definición de los criterios de fallos persistentes

Para minimizar la interrupción que ocasionan los fallos temporales en un recurso, el supervisor de fallos reinicia el recurso en respuesta a dichos fallos. Para los fallos persistentes, es necesario realizar acciones que generan más interrupciones que el reinicio del recurso:

  • Para un recurso de failover, el supervisor de fallos realiza un failover del recurso en otro nodo.

  • Para un recurso escalable, el supervisor de fallos pone el recurso fuera de línea.

Un supervisor de fallos considera que un fallo es persistente si la cantidad de errores completos de un recurso supera un recuento de reintento especificado por la propiedad estándar Retry_count. Definir los criterios de los fallos persistentes permite definir el recuento y el intervalo de reintento para adaptarse a las características de rendimiento del cluster y los requisitos de disponibilidad.

En esta sección, se describen los siguientes temas:

Errores completos y parciales de un recurso

Un supervisor de fallos considera algunos fallos como un error completo de un recurso. Un error completo generalmente provoca una pérdida total del servicio. Los siguientes errores son ejemplos de errores completos:

  • Finalización inesperada del proceso de un servidor del servicio de datos.

  • Imposibilidad de un supervisor de fallos de conectarse con un servidor del servicio de datos.

Un error completo hace que el supervisor de fallos incremente en uno el número de errores completos en el intervalo de reintento.

Un supervisor de fallos considera otros fallos como un error parcial de un recurso. Un error parcial se considera menos grave que uno completo y generalmente provoca una degradación del servicio, pero no una pérdida total de él. Un ejemplo de un error parcial es una respuesta incompleta de un servidor del servicio de datos antes del timeout de un sondeo del supervisor de fallos.

Un error parcial hace que el supervisor de fallos incremente en una fracción el número de errores completos en el intervalo de reintento. Los errores parciales se siguen acumulando durante el intervalo de reintento.

Las siguientes características de los errores parciales dependen del servicio de datos:

  • Los tipos de fallos que el supervisor de fallos considera como un error parcial.

  • La fracción que cada error parcial suma al número de errores completos.

Para obtener información sobre los fallos que detecta el supervisor de fallos de un servicio de datos, consulte la documentación del servicio de datos.

Dependencias del recuento y el intervalo de reintento en otras propiedades

El tiempo máximo necesario para un reinicio único de un recurso defectuoso es la suma de los valores de las siguientes propiedades:

  • Propiedad del sistema Thorough_probe_interval

  • Propiedad de extensión Probe_timeout

Para garantizar que haya tiempo suficiente para alcanzar el recuento de reintento en el intervalo de reintento, utilice la siguiente expresión para calcular los valores del intervalo de reintento y recuento de reintento:

retry_interval >= 2 x retry_count × (thorough_probe_interval + probe_timeout)

La multiplicación por dos considera los errores de sondeo parciales que no provocan una desconexión o un failover inmediatos del recurso.

Propiedades estándar para definir el recuento de reintentos y el intervalo de reintentos

Para definir recuento de reintento y el intervalo de reintento, establezca las siguientes propiedades estándar para el recurso:

  • Para definir el recuento de reintento, establezca la propiedad estándar Retry_count en el número máximo permitido de errores completos.

  • Para definir el intervalo de reintento, establezca la propiedad estándar Retry_interval en el intervalo en los segundos requeridos.

Especificación del comportamiento de failover de un recurso

El comportamiento de failover de un recurso determina cómo responde RGM a los siguientes fallos:

  • Fallo del recurso al iniciarse

  • Fallo del recurso al detenerse

  • Fallo del supervisor de fallos del recurso al detenerse

Para especificar el comportamiento de failover de un recurso, establezca la propiedad estándar Failover_mode del recurso. Para obtener información sobre los posibles valores de esta propiedad, consulte la descripción de la propiedad estándar Failover_mode standard property in the r_properties(5).