En muchas ocasiones durante la administración de un servidor de aplicaciones Weblogic podemos presentar problemas de alto uso de cpus, stucks threads, errores de aplicaciones, sobrecarga de logs, entre otros, que hagan que nuestro managed server se cuelgue o simplemente se apague.
Algunas veces la solución al error no viene a ser algo sencillo, ya que muchas veces se debe depurar la aplicación instalada para lograr un correcto funcionamiento, hacer algunas configuraciones de infraestructura como subir heap size de java, límites de uso del cpus, clusterizar, entre otros.
Es por ello que mientras se llegan a esas soluciones, existe una pequeña configuración que se puede realizar en el node manager del weblogic, esto con el fin de que ante cualquier fallo que bote nuestra aplicación, se reinicie automáticamente y así, los tiempos de time down sean mucho menores.
¿Qué es CrashRecoveryEnable?
CrashRecoveryEnable es una configuración crucial en el NodeManager de WebLogic que determina si los servidores gestionados (managed servers) deben reiniciarse automáticamente después de un fallo. En otras palabras, esta configuración permite la recuperación automática de servidores que pueden haber experimentado un cierre inesperado.
Beneficios:
- Minimización los tiempos de inactividad: La principal ventaja de esta configuración es minimizar los tiempos de inactividad. En lugar de depender de intervenciones manuales para reiniciar servidores afectados, el NodeManager toma la iniciativa y restaura automáticamente la funcionalidad del servidor.
- Aumento de la fiabilidad: La recuperación automática mejora la fiabilidad del entorno. Si un servidor experimenta un fallo, CrashRecoveryEnable asegura que se restablezca rápidamente, manteniendo la integridad del sistema.
- Optimización del mantenimiento: Al automatizar la recuperación después de un fallo, los equipos de administración pueden centrarse en tareas más estratégicas en lugar de dedicar tiempo a la recuperar manual los managed server.
Configuración:
Para habilitar CrashRecoveryEnable, debemos acceder al archivo nodemanager.properties, que se encuentra en el directorio nodemanager de nuestra instalación de WebLogic.
$DOMAIN_HOME/nodemanager
Debemos añadir el siguiente comando o establecerlo en true:
CrashRecoveryEnable=true
Esta simple configuración es la clave para hacer que los managed server se reinicien automáticamente.
Nota: Si estamos en un ambiente clusterizado, esta configuración se deberá aplicar a todos los nodemanager.properties que tengamos configurados.
Posterior a esto, debemos reiniciar nuestro NodeManager y reiniciar también los managed server que estén siendo administrador por ese NodeManager, además hay que tener presente que si lo hacemos por medio de la consola de linux, debemos iniciar los managed server por medio del node manager para que este los pueda monitorear.
En casos de requerir una guía sobre cómo iniciar los managed server usando el node manager desde la consola de linux, puedes seguir la siguiente documentación:
Consideraciones importantes:
- Configuración consciente: Aunque CrashRecoveryEnable es una herramienta útil, su uso debe ser consciente. Es crucial entender los posibles impactos y configurar adecuadamente otros aspectos de su entorno para garantizar una recuperación suave.
- Registro y monitoreo: Hay que asegurarse de tener mecanismos efectivos de registro y monitoreo para evaluar la efectividad de la recuperación automática y tomar medidas correctivas de ser necesario.
La administración de servidores junto con la capacidad de recuperación ante desastres son dos conceptos que van de la mano, configuraciones simples como estas pueden evitar pérdidas millonarias dependiendo la aplicación y así mismo desencadenar despidos por largos tiempos de time down; aún así, este comando no es mágico, si nuestro problema se debe a razones externas como la caída de la base de datos, problemas de acceso de red, puertos, entre otros, el nodemanager continuará intentando iniciar el managed server sin lograrlo, en ese tipo de situaciones, se tendrá que matar el proceso del node manager y revisar los logs para atender el problema real.