En este capítulo, se describen los diversos recursos disponibles para probar la instalación de ACSLS-HA y diagnosticar y solucionar problemas que pudieran surgir en el sistema.
Las actividades que se realizan durante un evento de inicio o switchover están ampliamente distribuidas en los dos nodos. Como consecuencia, el punto de vista elegido para observar la operación general durante el proceso de prueba puede determinar la posibilidad de ver los eventos a medida que ocurren. Utilidad ha_console.sh describe los procedimientos para configurar una vista completa.
Una configuración del panel de control recomendada para observar el comportamiento general de HA durante el proceso de prueba incluiría ocho ventanas de shell, cuatro de cada nodo.
Se debería reservar un shell de comando root en cada nodo para confirmar varios comandos, si fuera necesario
Configure una ventana en cada nodo para visualizar el final del archivo /var/adm/messages del sistema.
# tail -f /var/adm/messages
Solaris Cluster imprime todos los mensajes informativos en este archivo log.
Configure otra ventana en cada nodo para visualizar el final del recurso acsls-rs start_stop log.
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
Allí se muestran todos los mensajes publicados por la secuencia de comandos acsls_agt.sh.
Se debe configurar una tercera ventana en cada nodo para visualizar el final del log de sondeo acsls-rs.
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt
Una vez iniciada la aplicación, Solaris Cluster sondea el recurso ACSLS a cada minuto. Cada sondeo devuelve un código numérico al cluster, y los resultados se imprimen en el archivo probe_log.txt. Después de cada sondeo, uno de los cinco valores estándar devueltos se ve publicado en este log:
0 - The probe found that ACSLS is healthy and functioning normally. 1 - The probe may not have completed due to a functional error. 2 - The probe reports that ACSLS is in a transitional state. 3 - The ACSLS application has been intentionally placed offline. 201 - A condition was detected that requires fail-over action.
Solaris Cluster inicia la acción de failover solo en respuesta al código 201. Las condiciones que incitan tal acción se muestran en el capítulo Operación del cluster de ACSLS. Todos los demás códigos que devuelve el sondeo del cluster se consideran informativos y no confirman ninguna acción en respuesta por parte del cluster.
Se pueden realizar sondeos de prueba en cualquier momento desde la línea de comandos. Utilice el comando acsAgt probe:
#/opt/ACSLSHA/util/acsAgt probe
Todos los logs mencionados anteriormente reflejan una vista del sistema como la visualiza Solaris Cluster. Dos logs adicionales del directorio $ACS_HOME/log/ ofrecen una vista del nivel de la aplicación ACSLS. El archivo acsss_event.log informa todos los eventos importantes encontrados por ACSLS desde el momento en el que se inició la aplicación. Cualquier dificultad de inicio de ACSLS que encuentre SMF se registra en acsls_start.log.
Las utilidades de Solaris Cluster se encuentran en el directorio /usr/cluster/bin.
Para ver el estado actual del grupo de recursos ACSLS: clrg list -v.
Para ver el estado actual de los dos nodos del cluster: clrg status.
Para ver el estado de los grupos de recursos: clrs status.
Para obtener el estado detallado de los nodos, los dispositivos del quórum y los recursos del cluster: cluster status.
Para obtener una lista de componentes detallada en la configuración del cluster: cluster show.
Para ver el estado de cada nodo Ethernet en el grupo de recursos: clnode status -m.
Para ver el estado de los diferentes recursos acsls-rg en cada nodo: scstat -g.
Para ver el estado de los enlaces de red de latidos: clintr status.
Para ver el estado de IPMP: scstat -i.
Para ver el estado del nodo: scstat -n.
Para ver el estado y la configuración del quórum: scstat -q o clq status.
Para mostrar recursos del cluster detallados, incluso los valores de timeout: clresource show -v.
En esta sección, se explican las condiciones, la supervisión y las pruebas de recuperación y failover.
Existen diversas condiciones fatales del sistema que se pueden recuperar sin necesidad de un evento de failover del sistema. Por ejemplo, con IPMP, se puede producir un error en una conexión Ethernet en cada grupo por cualquier motivo, pero la comunicación se debe reanudar de manera ininterrumpida mediante la ruta alternativa.
La matriz de discos compartidos se debe conectar a los servidores con dos puertos diferentes en cada servidor. Si se interrumpe una ruta, la operación de E/S de disco se debe reanudar sin interrupción en la ruta alternativa.
ACSLS se compone de varios servicios de software supervisados por la utilidad de gestión de servicios (SMF) de Solaris. Como usuario acsss, muestre cada servicio acsss con el comando acsss status. Entre estos servicios, se encuentra la base de datos de PostgreSQL, el servidor de aplicaciones web de WebLogic y el software de la aplicación ACSLS. Si se produce un error en un servicio del sistema Solaris, la SMF debe reiniciar automáticamente ese servicio sin necesidad de realizar un failover del sistema.
El servicio acsls en sí mismo se compone de diversos procesos secundarios que son supervisados por el proceso principal acsss_daemon. Para mostrar los subprocesos de ACSLS, utilice el comando psacs (como usuario acsss). Si alguno de los procesos secundarios se cancela por algún motivo, el proceso principal debe reiniciar de inmediato ese proceso secundario y recuperar la operación normal.
La mejor ubicación para visualizar la recuperación de los recursos del sistema (como E/S de disco y conexiones Ethernet) es el log del sistema, /var/adm/messages.
La SMF mantiene un log específico para cada servicio de software que supervisa. Este log muestra eventos de inicio, reinicio y cierre. Para obtener la ruta completa al log de servicio, ejecute el comando svcs -l service-name. Los servicios ACSLS se pueden mostrar mediante el comando acsss: $ acsss status. Los subprocesos se pueden mostrar con el comando
$ acsss p-status
Para ver la recuperación de algún subproceso de ACSLS, puede supervisar acsss_event.log ($ACS_HOME/ACSSS/log/acsss_event.log). Este log muestra todos los eventos de recuperación que incluyen alguno de los subprocesos de ACSLS.
La lógica de Solaris IPMP debe reiniciar automáticamente las conexiones de red redundantes. Cualquier conexión de datos interrumpida a la matriz de discos compartidos debe ser reiniciada automáticamente por Solaris en la ruta de datos redundante. SMF debe reiniciar automáticamente los servicios controlados por la utilidad de gestión de servicios de Solaris.
En el caso de las pruebas que incluyen un evento de failover real, debe conocer la configuración de propiedades definida en el archivo: $ACS_HOME/acslsha/pingpong_interval. A pesar de las condiciones que pueden disparar un evento de failover, Solaris Cluster no inicia una acción de failover si se produce un evento de failover anterior dentro del pingpong_interval especificado.
Para ver o modificar dinámicamente el intervalo de pingpong, vaya al directorio /opt/ACSLSHA/util y ejecute acsAgt pingpong:
# ./acsAgt pingpong Pingpong_interval current value: 1200 seconds. desired value: [1200] 300 Pingpong_interval : 300 seconds.
Use alguna de las siguientes técnicas o todas ellas para evaluar la resiliencia de la instalación de HA:
Mientras ACSLS esté en funcionamiento, anule una conexión Ethernet de cada grupo IPMP en el nodo activo. Supervise el estado con # scstat -i.
Observe la reacción en /var/adm/messages. La operación de ACSLS no debe ser interrumpida por este procedimiento.
Asegúrese de que el cluster Failover_mode esté configurado en HARD. Mientras ACSLS está en funcionamiento, anule una conexión SAS o de fibra del servidor activo con el recurso de discos compartidos.
Observe la reacción en /var/adm/messages. La operación de ACSLS no debe ser interrumpida por este procedimiento.
Repita esta prueba con cada conexión de E/S redundante.
Cierre repentinamente ACSLS mediante la terminación de acsss_daemon. Use pkill acsss_daemon.
Ejecute svcs -l acsls para ubicar el log de servicio.
Vea el final del log una vez que acsss_daemon se detenga. Observe que SMF reinicia el servicio automáticamente. Se debe visualizar una acción similar al detener acsls con acsls shutdown.
Desactive el servicio acsls mediante SMF.
Esto se puede realizar como usuario root con svcadm disable acsls o se puede realizar como usuario acsss con acsss disable.
Debido a que SMF se encarga de este evento de cierre, no se intenta reiniciar el servicio acsls. Este es el comportamiento deseado. El servicio acsls se debe reiniciar mediante SMF. Como usuario root, use el comando svcadm enable acsls. De lo contrario, como usuario acsss, use el comando acsss-enable.
Desactive el servicio acsdb.
Como usuario acsdb, obtenga el archivo .acsls_env.
$ su acsdb $ . /var/tmp/acsls/.acsls_env
Ahora, desactive repentinamente la base de datos de PostgreSQL con el siguiente comando:
pg_ctl stop \
-D $installDir/acsdb/ACSDB1.0/data \
-m immediate
Esta acción debe desactivar la base de datos y, además, interrumpir los procesos acsls. Ejecute svcs -l acsdb para ubicar el log de servicio acsdb.
Visualice el final del log de servicio acsdb y el log de servicio acsls de la base de datos que se desactivó. Observe que, cuando se detiene el servicio acsdb, también se desactiva el servicio acsls. Ambos servicios deben ser reiniciados automáticamente por SMF.
Mientras ACSLS está en funcionamiento, ejecute psacs como usuario acsss para obtener una lista de los subprocesos en ejecución en acsss_daemon.
Detenga cualquiera de los siguientes subprocesos. Observe acsss_event.log para confirmar que se ha reiniciado el subproceso y que se ha invocado un procedimiento de recuperación.
El software Solaris Cluster supervisa el sistema Solaris y busca condiciones fatales que podrían necesitar un evento de failover del sistema. Estas condiciones incluyen failover iniciado por el usuario (acsAgt nodeSwitch o clrg switch -n), reinicio del sistema del nodo activo, bloqueo del sistema, fallo fatal de la memoria o comunicaciones de E/S irrecuperables en el nodo activo. Solaris Cluster, además, supervisa los agentes de HA que han sido diseñados para aplicaciones específicas. El agente de ACSLS HA solicita un evento de failover del sistema en los siguientes casos:
Se ha perdido la comunicación TCP/IP entre el nodo activo y el host lógico.
El sistema de archivos $ACS_HOME no está montado.
El sistema de archivos de copia de seguridad de base de datos ($ACS_HOME/.../backup) no está montado.
Se ha perdido la comunicación con la biblioteca correspondientes a un ACS incluido en el archivo $ACS_HOME/acslsha/ha_acs_list.txt cuyo estado deseado es en línea y donde switch lmu no se puede realizar con éxito.
En todo momento, puede supervisar el estado de failover de los respectivos nodos mediante el comando # clrg status.
También puede supervisar la actividad de failover observando el final de start_stop_log:
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
Podría resultar útil visualizar (tail -f) el archivo /var/adm/messages en ambos nodos cuando realiza operaciones de failover de diagnóstico. Consulte Supervisión de la operación del cluster de ACSLS.
El comando simple para iniciar un evento de failover del cluster es acsAgt nodeSwitch.
# acsAgt nodeSwitch
De lo contrario, use el comando equivalente del cluster:
# clrg switch -n <node name> acsls_rg
Esta acción debe desactivar la aplicación ACSLS y conmutar la operación del servidor activo al sistema en espera. Las opciones -M -e indican al servidor del cluster que active los servicios SMF en el nuevo nodo. Consulte Supervisión de la operación del cluster de ACSLS.
El reinicio del sistema en el nodo activo debe iniciar una conmutación de HA inmediata al nodo alternativo.
Con esta operación, ACSLS se debe ejecutar en el nuevo nodo activo. En el nodo en espera, observe el final del archivo /var/adm/messages mientras el sistema en espera asume su nuevo rol como nodo activo. También puede ejecutar periódicamente el comando # clrg status.
Mediante init 5, apague el nodo de servidor activo y verifique el failover del sistema.
Desconecte ambas líneas de datos entre el nodo de servidor activo y la matriz de almacenamiento de discos compartidos, y verifique la conmutación del sistema al nodo en espera.
Suponiendo que una biblioteca dada está incluida en el archivo de política ha_acs_list.txt, desconecte las líneas de comunicación Ethernet entre el nodo de servidor activo y esa biblioteca.
Verifique el failover del sistema al nodo en espera.
Si las unidades de inicio reflejadas se pueden conectar en caliente, puede desactivar una de las unidades de inicio y confirmar que el sistema sigue funcionando. Con una unidad de inicio desactivada, reinicie el sistema para verificar que el nodo proviene de la unidad de inicio alternativa. Repita esta acción para cada unidad de inicio en cada uno de los dos nodos.
Retire la fuente de alimentación del nodo activo, y el sistema debe permanecer en pleno funcionamiento con la fuente de alimentación alternativa.