8 Ajuste de ACSLS HA

En este capítulo, se explica cómo configurar una política óptima de failover en caso de error de la biblioteca, cómo ajustar el intervalo de pingpong para evitar eventos de failback no deseados y cómo registrarse para recibir notificaciones por correo electrónico de eventos de failover.

Definición de una política de failover para comunicaciones de la biblioteca

El agente de ACSLS HA constantemente supervisa la comunicación entre ACSLS y las bibliotecas conectadas. Dicha comunicación es crítica para el funcionamiento continuo de ACSLS. Pero las medidas, si hubiera, que se deberían adoptar en caso de problemas de comunicación de la biblioteca dependen de una política determinada por el administrador local de ACSLS HA.

La tabla de políticas, $ACS_HOME/acslsha/ha_acs_list.txt, permite al administrador local definir la acción de failover deseada para cualquier ACS que necesita recuperación de HA. En caso de error de comunicación de la biblioteca, y según la directiva del administrador, el agente de ACSLS HA realiza un failover al nodo alternativo si se ha confirmado con éxito la comunicación de ACS en ese nodo.

En entornos de varios ACS, es posible que se prefiera que el sistema ACSLS HA realice un failover en caso de que falle la comunicación con un único ACS. Pero debido a que cualquier acción de failover interrumpirá la producción en todas las bibliotecas conectadas, es posible que el administrador prefiera limitar la acción de failover general a los ACS más críticos en el centro de datos. Se crea un registro de políticas en ha_acs_list.txt para cada ACS para el cual se requiere una acción de failover del cluster cuando se pierde la comunicación de la biblioteca. Cada registro tiene dos campos:

ACS Number   Fail-over Action (true or false)

El primer campo es el ID de ACS y el segundo campo es el valor booleano de true o false. La lógica de la configuración de la política es la siguiente:

• Cuando el segundo campo sea false, el agente de ACSLS HA no iniciará una acción de failover del cluster al nodo alternativo, incluso cuando se haya producido un error de comunicación con ACS y no se pueda restaurar.

• Cuando el segundo campo es true, el agente de ACSLS HA confirma la acción de failover del cluster después de que ha fallado cada intento de restablecer la comunicación desde el nodo principal. Se produce un failover del sistema solo si se ha confirmado el contacto de la biblioteca en el nodo alternativo.

La acción predeterminada es false para cualquier ACS no incluido en este archivo.

Bibliotecas con Redundant Electronics (RE)

En el caso de bibliotecas con Redundant Electronics (RE), el agente de ACSLS HA intenta conmutar la comunicación a la ruta alternativa de RE antes de recurrir a una acción de failover del cluster. Esta acción de conmutación de RE se aplica solamente a una biblioteca SL8500, SL3000 o 9310 anterior con LMU duales. La conmutación automática de RE no se intenta en ninguna biblioteca particionada.

Configuración de Pingpong_interval de failover

El Pingpong_interval de Solaris Cluster es una propiedad de timeout que evita una acción repetida de failover si no se puede restaurar la recuperación completa después del primer evento de failover del cluster.

Ésta es una propiedad que el usuario puede modificar para el grupo de recursos ACSLS. El valor predeterminado se configura en 20 minutos. Con esta configuración, el primer evento de failover se produce de inmediato cuando el agente de ACSLS HA solicita una acción de failover. Pero si la condición que podría disparar la acción de failover no se borra en el nuevo nodo de cluster, la acción de failover posterior se demora hasta que caduque el intervalo de pingpong definido. Esto evita la paginación excesiva innecesaria de control entre un nodo de cluster y el otro hasta resolver el problema de la raíz.

Para ajustar la configuración de esta propiedad, puede modificar el número predeterminado en el archivo $ACS_HOME/acslsha/pingpong_interval. Ese número se expresa en segundos.

El valor predeterminado de 1200 segundos es una configuración razonable para la mayoría de las configuraciones de biblioteca medianas a grandes. El valor óptimo de timeout para esta propiedad depende del número real de LSM y de las unidades de cinta que existen en la configuración de la biblioteca. Las configuraciones de bibliotecas más grandes pueden tardar más tiempo en recuperarse después de un evento de failover, y, por lo tanto, este número se debe establecer en un intervalo más prolongado para los sistemas configurados con más de diez LSM o cuarenta unidades, o ambos.

Se recomienda una configuración de 1800 (30 minutos) para una configuración de cuarenta LSM, mientras que se recomienda una configuración de 900 (15 minutos) para bibliotecas más pequeñas configuradas con uno a cuatro LSM.

Después de cambiar la propiedad en el archivo pingpong_interval, es necesario ejecutar la secuencia de comandos de inicio ACSLS HA.

start_acslsha.sh -h logical hostname -g IPMP group -z acslspool

Este comando de inicio se puede ejecutar aunque el sistema HA ya se esté ejecutando. Registra el nuevo pingpong_interval sin afectar la operación normal de HA.

Registro de notificación por correo electrónico de eventos del sistema

Los usuarios con tareas administrativas se pueden registrar para recibir notificaciones automáticas por correo electrónico de eventos del sistema, incluso los eventos de inicio del sistema y los eventos de failover del cluster de ACSLS HA.

A fin de registrarse para dichos eventos, los usuarios deben agregar su dirección de correo electrónico en los archivos respectivos del siguiente directorio:

$ACS_HOME/data/external/email_notification/
   boot_notification
   ha_failover_notification

Coloque la dirección de correo electrónico de cada destinatario en una única línea debajo de los comentarios del encabezado. Posteriormente, cada vez que el sistema se inicie o el cluster HA realice un failover al nodo en espera, cada usuario registrado recibirá una notificación por correo electrónico.

Esta capacidad asume que el servicio sendmail se ha activado en el servidor ACSLS y que las limitaciones del firewall de red permiten la comunicación por correo electrónico desde el centro de datos.