Monitoreo a prueba de fallos: cómo garantizarlo con clústeres de servidores
Monitoreo a prueba de fallos: cómo garantizarlo con clústeres de servidores
Las redes informáticas llevan mucho tiempo siendo componentes críticos de los procesos de negocio. El fallo de un sistema de este tipo significa, en la práctica, la detención de las actividades de toda la organización. El monitoreo y el diagnóstico del rendimiento de la red son una de las tareas principales para garantizar la salud de la empresa. Se trata de un proceso continuo de supervisión de una red digital para detectar a tiempo fallas y errores y responder de forma rápida y adecuada. En este contexto surge la pregunta sobre la alta disponibilidad del propio servicio de monitoreo y su funcionamiento ininterrumpido.
El programa 10-Strike Network Monitor Pro implementa varios mecanismos que garantizan la tolerancia a fallos del sistema de monitoreo. El uso de estos mecanismos le permite mantener la infraestructura de red bajo control fiable. Repasemos los métodos de monitoreo a prueba de fallos disponibles en el software, hasta un clúster de conmutación por error de servidores de monitoreo.
Monitoring Service Guard
El watchdog del servidor de monitoreo está implementado como un servicio llamado 10-Strike Network Monitor Watchdog. Se instala en cada host donde se despliega el paquete de instalación del programa principal o del servidor de monitoreo. El servicio supervisa los parámetros del servicio de servidor de monitoreo 10-Strike Network Monitor Pro Service y del SGBD Firebird Server. Si estos servicios se detienen o fallan, el guard los reinicia automáticamente. Si cinco intentos de iniciar estos servicios no tienen éxito, el guard envía una notificación por correo electrónico a la dirección indicada. Tenga en cuenta que, aunque detenga regularmente el servicio del servidor de monitoreo para mantener la base de datos, el guard activo lo volverá a iniciar en unos segundos. Por ello, en esas situaciones debe detener primero el servicio watchdog y después el servidor de monitoreo.
El watchdog supervisa no solo el estado del servicio (iniciado / no iniciado), sino también la actividad del propio proceso de monitoreo y sus parámetros. Si el proceso de monitoreo deja de mostrar señales de actividad (escritura de una etiqueta en la base de datos), el guard también reinicia el servicio. Hace lo mismo si deja de ejecutarse un número determinado de comprobaciones, lo que puede indicar acumulación de errores internos durante el monitoreo.
El uso de un watchdog evita que el monitoreo se detenga por errores de software en el servidor de monitoreo.
Servidor de respaldo de base de datos
En el sistema de monitoreo distribuido, la base de datos central se encuentra en un servidor físico y los servidores de monitoreo suelen instalarse en otros. Los servicios de monitoreo se conectan a la base de datos por TCP e intercambian información con ella, reciben configuración y registran las estadísticas recopiladas y los resultados de las pruebas. Puede ocurrir que el servidor de base de datos falle o se pierda la conexión con él. Esto amenaza con la pérdida de la información operativa que el servidor de monitoreo escribe en la base de datos.
Para resolver este problema, se propone usar un servidor de respaldo con una base de datos instalada, al cual se replica todo el sistema de archivos (o parte de los archivos). La configuración del servicio de monitoreo incluye un parámetro con la dirección del servidor de base de datos de respaldo. El servidor de monitoreo y la consola GUI pueden conmutar a él automáticamente si el servidor de base de datos principal deja de estar disponible. La dirección del servidor de respaldo se configura en los ajustes de conexión a la base de datos del programa. Debe configurar usted mismo la replicación de la base de datos (como opción, espejado del sistema de archivos) para mantener el estado actual de la copia de respaldo.
Protección contra pérdida de información cuando se pierde la conexión con la base de datos central
Existe una solución alternativa al problema de pérdida de conexión entre el servidor de monitoreo remoto y la base de datos central. Si no se indica ni configura un servidor de base de datos de respaldo, el servicio de monitoreo conmutará a la base de datos local, que se configura e instala automáticamente desde el paquete de distribución (c:\ProgramData\10-Strike\Network Monitor Pro\LocalDB\NETMONITOR.FDB). El servidor de monitoreo escribirá las estadísticas de monitoreo de hosts en la base de datos local hasta que se restablezca la comunicación normal con la base de datos principal. Cuando se restablezca la conexión, todos los datos acumulados durante ese tiempo de inactividad en la base de datos local se transferirán automáticamente a la base de datos principal. Todo el proceso es completamente automático y no requiere ninguna acción del usuario. Tampoco se necesitan configuraciones adicionales del software para que funcione.
En esas situaciones, el log del servicio se registra en el log del programa (c:\ProgramData\10-Strike\Network Monitor Pro\Logs\NetMonitorPro.log). Si la conexión con la base de datos se interrumpe durante mucho tiempo, puede comprobar si los datos se transfirieron correctamente a la base de datos central.
Reserva del servidor de monitoreo: trabajo con servidor de respaldo secundario
La reserva puede realizarse no solo para el servidor de base de datos central, sino también para el propio servidor de monitoreo. Consideremos la situación en la que falla un host con el servicio de monitoreo instalado. En ese caso, el proceso de monitoreo se detiene por completo. Para evitar incidentes de este tipo, se propone instalar un servidor de monitoreo de respaldo en un segundo host físico y asignarle el mismo ID. Así obtenemos dos servicios de monitoreo activos conectados a la misma base de datos y con el mismo ID en el archivo de configuración c:\ProgramData\10-Strike\Network Monitor Pro\NetMonitorPro.ini. El servicio que se inicia primero se establece automáticamente como activo y comienza a ejecutar todas las comprobaciones. El servicio que se inicia segundo pasa a ser el de respaldo. También lee la misma lista de comprobaciones de la base de datos, pero no las ejecuta. El servicio de respaldo supervisa constantemente la actividad del primer servicio según ciertos indicadores en la base de datos. Si el primer servicio deja de estar activo por algún motivo, el servicio de monitoreo de respaldo comienza automáticamente a ejecutar comprobaciones sin tiempo de inactividad.
Cuando el primer servidor vuelve a funcionar con normalidad, el primer servicio asume el rol de respaldo y comienza a supervisar la actividad del segundo servicio. Y así sucesivamente...
Esta solución puede usarse al crear un clúster de conmutación por error de servidores.