Pandora FMS Enterprise en Alta Disponibilidad
This post is also available in : Inglés
Alta Disponibilidad en monitorización con Pandora FMS
Pandora FMS es una herramienta de monitoreo proactivo, avanzada, flexible y fácil de configurar a medida del negocio. Se integra a todas las necesidades en servidores, equipos de red, terminales y lo que sea necesario.
Este artículo se aplica a la edición Enterprise de Pandora FMS y lo que se expone no se puede utilizar en Pandora FMS Community.
En este artículo nos enfocaremos en la ejecución de Pandora FMS contemplando alta disponibilidad para tener la solución operativa ante la falla de un servidor, teniendo presente que la herramienta de monitoreo es la encargada de enviarnos alertas ante la falla de cualquier componente de nuestro datacenter.
Requerimientos
Algo fundamental para tener cualquier solución en alta disponibilidad es contar con al menos dos componentes de cada componente de la solución para lograr, ante la falla de alguno de los componentes, que siempre tengamos Pandora FMS tomando métricas, enviando alertas, mostrando dashboards de salud o cualquier configuración que sea importante en nuestra implementación. Para poder comprender un poco esta arquitectura podemos ver el esquema funcional básico para este tipo de configuración.
En este escenario se utilizarán máquinas virtuales que se ejecutan en dos servidores de virtualización. Se puede utilizar VMware Esx, HyperV, KVM o la plataforma de virtualización que soporte virtualizar CentOS 7.
| VM | USO | Detalle |
| PandoraServer01 | Pandora Server, Pandora Consola | Server HA |
| PandoraServer02 | Pandora Server, Pandora Consola | Server HA |
| PandoraDB01 | Percona DB | DB HA |
| PandoraDB02 | Percona DB | DB HA |
| PandoraDB03 | Percona DB Datos Históricos | Histórico |
| KempLB01 | Balanceador | HLB |
| KempLB02 | Balanceador | HLB |
Para poder entender cómo funciona la solución en alta disponibilidad vamos a describir los tres componentes que figuran en la tabla (Detalle) para entender cómo funciona Pandora FMS en un escenario de misión crítica. Un ejemplo podría ser un ISP (Proveedor de Internet). Con esto claro, veremos cómo funciona la solución.
HLB: Balanceador de carga; este componente cumple con una función muy importante, que es generar una IP Virtual (VIP). Veremos este punto más adelante al validar la salud de cada componente de Pandora FMS Enterprise, comprobando que el servidor esté activo y enviando carga -en caso de que uno de los servidores no esté disponible- al otro. El detalle de los puertos que se configuran en el balanceador es el siguiente:
- 80 TCP – http (Consola WEB).
- 443 TCP – https (Consola WEB con Certificado SSL).
- 41121 TCP – Tentacle (Recibe las métricas de los agentes).
- 162 UDP – SNMP Traps (Recibe Alertas de equipos SNMP).
Server HA: Son dos consolas de Pandora FMS que ejecutan todos los componentes para tomar las métricas de los agentes y todos los componentes que forman parte la solución, y la aplicación web para operar la solución.
DB HA: Pandora FMS trabaja con una base de datos Percona, la cual soporta la ejecución en alta disponibilidad con el esquema de maestro-esclavo, que replica los datos y permite, a partir de una IP Virtual (VIP), mantener la solución operativa ante la falla de uno de los servidores de base de datos Pandora FMS.
Histórico: Se guardan los datos históricos; en caso de ser indispensable se puede montar la DB histórica con dos servidores Percona en Alta disponibilidad con DB HA.
Ejemplo completo de un escenario de Alta Disponibilidad en Pandora FMS Enterprise
Después de describir en forma general cómo pensar un escenario de Alta Disponibilidad vamos a ver un ejemplo completo. Antes de empezar veamos el esquema funcional.
| VM | IP | USO |
| PandoraServer01 | 192.168.200.1 | Server HA |
| PandoraServer02 | 192.168.200.2 | Server HA |
| PandoraDB01 | 192.168.200.21 | DB HA |
| PandoraDB02 | 192.168.200.22 | DB HA |
| PandoraDB03 | 192.168.200.23 | Histórico |
| KempLB01 | 192.168.200.11 | HLB |
| KempLB02 | 192.168.200.12 | HLB |
| Flotante LB | 192.168.200.10 | VIP Serve |
| Flotante DB | 192.168.200.20 | VIP DB HA |
Pandora FMS y la salud de la base de datos en HA
Algo fundamental en una configuración de Alta Disponibilidad es la salud de cada uno de los componentes. Pandora FMS Enterprise tiene integrado un monitoreo de la réplica de la base de datos Percona que permite -además de conocer el estado de Salud de la base de datos- realizar operaciones de corrección sin la necesidad de tener un perfil con conocimientos avanzados, como se puede ver en la siguiente imagen.
Pandora FMS Server y sus componentes
En la siguiente imagen podemos ver los servidores de Pandora FMS Enterprise ejecutándose en ambos servidores.
Parte de la configuración de Pandora FMS Enterprise se guarda en la base de datos Percona; estos cambios se ven reflejados en ambos servidores en forma inmediata.
Actualizaciones y cambios
Es muy importante tener presente que, al ser una solución modular, todos los componentes deben tener las mismas versiones. Al momento de realizar la actualización se hace en todos los componentes en forma simultánea, de la siguiente forma:
- PandoraServer01
- PandoraServer02
- PandoraDB01
- PandoraDB02
De esta forma estamos actualizados en este escenario, donde se puede brindar un SLA elevado utilizando las virtudes de Pandora FMS.
Pandora FMS tiene una configuración en el archivo
/etc/pandora/pandora_server.conf
Al realizar algún cambio es importante hacerlo en ambas consolas y reiniciar el servicio pandora_server para que todo funcione en forma correcta.
Archivos compartidos por ambas consolas
Para que todos los cambios se reflejen en ambas consolas se puede sumar un storage y montar las siguientes carpetas vía NFS, donde ambas consolas puedan escribir en forma simultánea.
| Directorio | Uso |
| /var/spool/pandora/data_in/conf | Configuración Agente |
| /var/spool/pandora/data_in/collections | Configuración Colecciones |
| /var/spool/pandora/data_in/md5 | Hash Configuración Agentes |
| /var/www/html/pandora_console/attachment/ | HA, Consolas |
| /var/www/html/pandora_console/images | Imágenes |
Con esta configuración tendremos nuestro Pandora FMS Enterprise funcionando en Alta Disponibilidad. Más detalles de esta configuración en la documentación oficial.
Funcionamiento de Pandora FMS en Alta Disponibilidad
Luego de ver cómo se realiza la implementación de Pandora FMS Enterprise en Alta Disponibilidad, entremos un poco más en detalle de cuáles son los beneficios, qué nos permite y fundamentalmente cómo funciona. Antes de ver en detalle el funcionamiento de Pandora FMS en Alta Disponibilidad vamos a ver más de cerca dos términos muy importantes para poder entender mejor este tipo de arquitectura.
¿Que es una arquitectura en alta disponibilidad?
Una solución de alta disponibilidad, conocida por sus siglas en ingles, HA (High Availability), se aplica cuando queremos disponer de un plan de contingencia sobre cualquier componente que se enfrente a alguna situación anómala, para poder seguir dando el servicio del mismo.
¿Qué significa que una Arquitectura ofrezca escalabilidad?
Se entiende por escalabilidad a la capacidad de adaptación y respuesta de un sistema con respecto al rendimiento de este a medida que aumentan de forma significativa el número de usuarios de este. Aunque parezca un concepto claro, la escalabilidad de un sistema es un aspecto complejo e importante del diseño.
La gran diferencia entre una arquitectura de Alta Disponibilidad y una de gran escalabilidad es la cantidad de equipos que la componen. Para tener Alta Disponibilidad es suficiente contando con dos componentes de cada una de sus partes; en una solución de gran escalabilidad serán necesarios N componentes en función a la carga. Pero a modo práctico la forma de pensarla es la misma.
En Pandora FMS Enterprise, según la arquitectura, vamos a tener todos los servidores de Pandora FMS ejecutándose en un solo equipo, según podemos ver en el siguiente esquema:
En la Arquitectura de Pandora FMS las acciones que realizan las consolas, como por ejemplo Plugin Server y Network Server, son acciones que se ejecutan desde los servidores de Pandora FMS Enterprise hacia los dispositivos monitoreados. Como la configuración está guardada en la base de datos, ante la falla de un servidor se ejecutarán las acciones desde el que esté funcionando de forma correcta.
El acceso a la consola, los traps SNMP o el reporte de los agentes al puerto 41121 TCP (Tentacle), son balanceados por el balanceador que permite decidir entre varias estrategias de balanceo, como por ejemplo darle prioridad a un servidor, distribuir la carga manteniendo sesiones, etc.
Veamos un ejemplo gráfico de la falla de uno de los servidores de Pandora FMS Enterprise:
Como se explicó anteriormente, los componentes que están balanceados serán redirigidos por el balanceador de carga y los servidores de Pandora FMS Enterprise en forma nativa.
Vista de salud de servidores de Pandora FMS: en este caso uno de los servidores no está funcionando pero nuestra solución sigue estando operativa incluso con este servidor con problemas.
Desde la consola web veremos los mensajes informando que uno de los servidores dejó de funcionar:
Es importante saber que Pandora FMS seguirá funcionando en forma correcta, incluso si son necesarios varios días para resolver el problema del servidor o incluso aunque sea necesario reinstalarlo.
Base de datos de Pandora FMS Enterprise en HA. ¿Cómo funciona?
Por último, y teniendo presente que la base de datos de Pandora FMS Enterprise es el corazón del producto, vamos a entender cómo funciona la arquitectura para que siempre esté disponible para los servidores de Pandora FMS.
Desde la consola Web, en Servers -> Manage Database HA
Podemos ver el estado de salud de nuestra base de datos en Alta Disponibilidad
Podemos ver la IP virtual (VIP) 172.16.75.21, la IP donde se conecta Pandora FMS Enterprise para trabajar con la base de datos; el servidor que tiene el rol Master es el que guarda los datos y se replican en el servidor con el rol Slave. Es fundamental prestar atención a que esta réplica funcione en forma correcta para evitar pérdida de datos.
En el esquema podemos ver que tenemos una falla en el segundo servidor de la base de datos; en ese caso se perderá la réplica y se ajustará en forma automática en el momento en que vuelva a estar disponible.
Si la falla se produce en el servidor que tiene el rol Master, el servidor con el rol Slave pasa a ser Master; Pandora FMS Enterprise pierde la conexión por un lapso de tiempo pequeño y vuelve a estar disponible.
Para finalizar el artículo es importante conocer que Pandora FMS brinda herramientas de gestión de los servidores de base de datos que permiten volver a sincronizar el servidor Master con el Slave, poner un servidor en Standby y poder configurar alarmas ante alguna falla en este componente crítico de Pandora FMS Enterprise ejecutándose en una arquitectura de Alta Disponibilidad.
Antes de despedirnos recuerda que puedes conocer todo lo que Pandora FMS puede ofrecerte entrando aquí.
Además, si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela aquí.
Socio Fundador y CEO de SITS SOLUCIONES.
Emprendedor inquieto, Tecnólogo de formación e innovador por vocación, cuenta con más de 25 años de experiencia en el universo IT. Transitando la transformación digital y creando soluciones innovadoras, actualmente enfocado en Monitoreo Pro-Activo, Cloud y Alta disponibilidad. Realiza contribuciones a las comunidades de Pandora FMS para Argentina, Chile y Uruguay.
Founder partner and CEO of SITS SOLUCIONES.
Restless entrepreneur, training technologist and innovator by vocation, has more than 25 years of experience in the IT universe. Moving the digital transformation and creating innovative solutions, currently focused on Pro-Active Monitoring, Cloud and High Availability. He makes contributions to Pandora FMS communities for Argentina, Chile and Uruguay.
