11 Registro, diagnóstico y prueba de cluster

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.

Registro de Solaris Cluster

Los mensajes de Solaris Cluster durante un evento de failover se escriben en el archivo /var/adm/messages. Este archivo tiene mensajes relacionados con funciones del cluster, errores de ACSLS y mensajes de información. Sólo el nodo activo escribe mensajes del cluster en el archivo /var/adm/messages.

Solaris Cluster supervisa el estado de ACSLS con un sondeo cada sesenta segundos. Puede ver el log de esta actividad de sondeo aquí:

/var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt

En el mismo directorio, hay un archivo que registra cada evento de inicio y detención si se produce una secuencia de failover.

/var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt

Log de eventos de ACSLS

El log de eventos de ACSLS es $ACS_HOME/log/acsss_event.log. Este log incluye mensajes relacionados con eventos de inicio y detención desde la perspectiva del software ACSLS. El log informa cambios del estado operativo de los recursos de la biblioteca y registra todos los errores detectados por el software ACSLS. El acsss_event.log se gestiona y se archiva automáticamente a partir de los parámetros definidos en la opción 2 de acsss_config.

Utilidades de supervisión del cluster

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 del grupo de recursos: scstat -g.
Para ver el estado del grupo de dispositivos: scstat -D.
Para ver el estado de los enlaces de red de latidos: scstat -D o 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.

Pruebas de recuperación y failover

En esta sección, se explican las condiciones, la supervisión y las pruebas de recuperación y failover.

Condiciones de recuperación

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, puede mostrar cada uno de los servicios 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.

Supervisión de recuperación

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.

Pruebas de recuperación

Las conexiones de red redundantes deben ser reiniciadas automáticamente por rutas múltiples de IP (IPMP) lógicas de Solaris. 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 iniciará una acción de failover si se produce un evento de failover anterior dentro del pingpong_interval especificado. Consulte "Configuración de Pingpong_interval de failover".

Para verificar la configuración actual de Pingpong_interval, utilice el comando del cluster:

clrg show -p Pingpong_interval

Los métodos de validación sugeridos de este comportamiento pueden incluir los siguientes:

Mientras ACSLS esté en funcionamiento, desconecte la 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.
Mientras ACSLS está en funcionamiento, desconecte la 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.
Desactive el ACSLS abruptamente; para ello, detenga acsss_daemon.

Ejecute svcs -l acsls para ubicar el log de servicio.

Visualice el final de este log cuando detiene acsss_daemon. Debe observar que el servicio es reiniciado automáticamente por SMF. Se debe observar una acción similar si detiene 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. Éste es el comportamiento deseado. Debe reiniciar el servicio acsls con SMF utilizando $ acsss enable o # svcadm enable acsls.
Desactive el servicio acsdb.

Como usuario acsdb, desactive abruptamente 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 del log de servicio acsls cuando desactiva la base de datos. Debe observar 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.

Condiciones de failover

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 (clrg switch), 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 /export/backup no está montado.
Se ha perdido la comunicación con 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.

Supervisión de failover

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.

Pruebas de failover

El método establecido para probar el failover del cluster implica utilizar el comando clrg switch:
```
# clrg switch -M -e -n <standby 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. Observe esta secuencia de eventos en cada nodo. Para hacerlo, visualice el final del archivo /var/adm/messages. También puede observar el final del log de inicio y detención:
```
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
```
Ejecute con frecuencia el comando # clrg status.
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 del 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.

Pruebas adicionales

Si las unidades de inicio reflejadas se pueden conectar en marcha, 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.