viernes, 4 de abril de 2014
PowerHA: Application Monitor tests
Hola,
he seguido haciendo algunas pruebas con los Application Servers/Controllers y sus monitores en un cluster con PowerHA7.1.2 y he encontrado algunos problemas a los que un administrador se puede enfrentar y que, con un poco de intuición, son fáciles de solucionar.
1) Crear un Application Server/Controller (ver post anterior)
http://jorgelopezaragoneses.blogspot.com.es/2014/04/powerha-application-servercontroller.html
2) Crear un Application Monitor
Yo he creado un "Custom Monitor" ya que quería controlar todo el proceso. Para ver los tipos de monitor y sus atributos podéis profundizar en esta página:
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.powerha.admngd%2Fha_admin_config_multiple_app_mons.htm
# smitty sysmirror --> Cluster Applications and Resources --> Resources --> Configure User Applications (Scripts and Monitors) --> Application Monitors --> Configure Custom Application Monitors --> Add a Custom Application Monitor
[Entry Fields]
* Monitor Name App_mon
Application Controller(s) to Monitor App_control_Jorge +
* Monitor Mode [Long-running monitoring] +
* Monitor Method [/tmp/jorge/monitor.ksh]
Monitor Interval [20] #
Hung Monitor Signal [9] #
* Stabilization Interval [10] #
Restart Count [3] #
Restart Interval [99] #
* Action on Application Failure [notify] +
Notify Method []
Cleanup Method [/tmp/jorge/stop_script.ksh] /
Restart Method [/tmp/jorge/start_script.ksh] /
3) Pruebas/Errores
Prueba 1: kill del proceso que controla el monitor dejando el cleanup script con exit 1
NOTA: script_infinito es un script con un bucle while cuyo ejecución es controlada por el monitor, es decir, el script debe aparecer en la salida del ps.
node02# ps -ef | grep script_infinito
root 11206854 6816064 0 09:22:51 - 0:00 /bin/ksh /tmp/jorge/script_infinito.ksh
node02:/# clRGinfo -m
---------------------------------------------------------------------------------------------------------------------
Group Name Group State Application state Node
---------------------------------------------------------------------------------------------------------------------
RG_prueba ONLINE node02
App_control_Jorge ONLINE MONITORED
node02# kill 11206854
node02# clRGinfo -m
---------------------------------------------------------------------------------------------------------------------
Group Name Group State Application state Node
---------------------------------------------------------------------------------------------------------------------
RG_prueba ONLINE node02
App_control_Jorge ONLINE MONITOR FAILED
En /var/hacmp/log/hacmp.out podremos ver como el monitor ha intentado rearrancar la aplicación pero no ha sido capaz porque he puesto un error en el cleanup script.
[..]
server_restart: Calling user specified cleanup method /tmp/jorge/stop_script.ksh
+RG_preuba:server_restart[+199] /tmp/jorge/stop_script.ksh
/tmp/jorge/stop_script.ksh[5]: kill: bad argument count
+RG_prueba:server_restart[+201] STATUS=1
+RG_prueba:server_restart[+202] [ 1 -ne 0 ]
+RG_prueba:server_restart[+204] cl_log 6162 Failure in user-defined script /tmp/jorge/stop_script.ksh.\n /tmp/jorge/stop_script.k
sh
[...]
WARNING: Cluster CL_prueba has been running recovery program 'TE_SERVER_RESTART' for 840 seconds. Please check cluster status.
Esta línea seguirá repitiéndose aunque se corrija el cleanup script porque el cluster ha quedado inestable:
NODO ACTIVO:
node02:/# lssrc -ls clstrmgrES
Current state: ST_RP_FAILED
NODO PASIVO:
node01:/# lssrc -ls clstrmgrES
Current state: ST_BARRIER
- Solución
Corregir el cleanup script y recuperar el cluster de un fallo de script en ambos nodos. Esto deja de nuevo el cluster en ST_STABLE.
# smitty hacmp --> Problem Determination Tools --> Recover From PowerHA SystemMirror Script Failure
NOTA: si todos los scripts de cleanup and restart son correctos, el application monitor recuperará la aplicación.
Prueba 2: ERROR: The application monitor script file: does not exist or is not an executable
on node: node02.
He puesto "prueba 2", por seguir un orden, pero realmente es un error que he encontrado al trastear un rato con el cluster. Ese error me ha vuelto un poco loco porque todo estaba correcto, pero al pasar la verificación y sincronización del cluster, aparecía una y otra vez.
- Soluciones:
1) Comprobar que el Application Monitor tiene distinto nombre que otros recursos.
2) Comprobar que los scripts que maneja tienen permisos adecuados, que existen en la ruta especificada, etc.
3) Si no hay nada que esté mal realmente:
3.1) Eliminar el Application Monitor y sincronizar
3.2) Volver a declarar el Application Monitor y sincronizar.
Un saludo.
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario