En este capítulo, se explica cómo configurar una política óptima de failover en un complejo de bibliotecas, cómo ajustar el intervalo de pingpong por defecto para evitar eventos de failback no deseados y cómo registrarse para recibir notificaciones por correo electrónico de eventos de failover.
El agente de ACSLS HA constantemente supervisa la comunicación entre ACSLS y las bibliotecas conectadas. Dicha comunicación es crítica para la operación continua 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 la comunicación correcta 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 interrumpe 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 es false, el agente de ACSLS HA no inicia una acción de failover del cluster al nodo alternativo, incluso cuando se ha producido un error de comunicación con ACS y no se puede 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 por defecto es false para cualquier ACS no incluido en este archivo.
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.
Pingpong_interval de failoverEl 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.
Esta es una propiedad que el usuario puede modificar para el grupo de recursos ACSLS. El valor por defecto 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 modificar la configuración por defecto de esta propiedad, modifique el número por defecto en el archivo $ACS_HOME/acslsha/pingpong_interval. Ese número se expresa en segundos.
El valor por defecto de 1.200 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 1.800 (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.
Los cambios realizados aquí tienen efecto hasta que se vuelve a configurar ACSLS HA con el comando acsAgt configure.
# cd /opt/ACSLSHA/util # ./acsAgt configure
Este comando se puede confirmar incluso si el grupo de recursos acsls-rg ya está activo. Registra la nueva configuración por defecto sin afectar la operación normal de HA.
La configuración pingpong_interval se puede cambiar dinámicamente para realizar pruebas mediante acsAgt pingpong. El valor establecido con este comando permanece vigente hasta que se reinicia el grupo de recursos con acsAgt configure.
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 de 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.