Pandora FMS es una aplicación distribuida compleja que tiene diferentes elementos clave, susceptibles de representar un cuello de botella si no se dimensiona y configura correctamente. El propósito de este capítulo es ayudar a realizar un estudio propio de capacidad, para analizar la escalabilidad de Pandora FMS en función de una serie específica de parámetros. Este estudio ayudará a conocer los requisitos que debería tener la instalación para poder soportar determinada capacidad.
Las pruebas de carga sirven también para observar la capacidad máxima por servidor. En el modelo de arquitectura actual (v3.0 o posterior), con “N” servidores independientes y una Command Center (Metaconsola) , esta escalabilidad tiende a ser de orden lineal, mientras que la escalabilidad basada en modelos centralizados es exponencial.
El hecho de que Pandora FMS compacte datos en tiempo real, es muy relevante de cara a calcular el tamaño que van a ocupar. Se realizó un estudio inicial que comparaba la forma de almacenar los datos de un sistema clásico con la forma “asíncrona” de almacenar los datos de Pandora FMS. Esto se puede ver en el esquema que hay incluido en este capítulo.
En un sistema convencional
Para un chequeo, con una media de 20 iteraciones al día, se tiene un total de 5 MB al año en espacio ocupado. Para 50 chequeos por agente, son 250 MB por año.
En un sistema no convencional, asíncrono o con compactación, como Pandora FMS
Para un chequeo, con una media de 0,1 variaciones al día, se tiene un total de 12,3 KB al año en espacio ocupado. Para 50 chequeos por agente, son 615 KB por año.
Se describe a continuación un glosario de términos específicos para este estudio, para mejor comprensión del lector.
CRITICAL
(crítico) o WARNING
(advertencia).El estudio se ha hecho pensando en una implantación dividida en tres fases principales:
Para determinar con exactitud los requisitos de Pandora FMS en implantaciones de este volumen de datos hay que conocer muy bien que tipo de monitorización se va a realizar, con la mayor exactitud posible. Para el siguiente estudio se ha tenido en cuenta de forma específica las características del entorno de un cliente ficticio llamado “QUASAR TECNOLOGIES” que se pueden resumir en los siguientes puntos:
Después de hacer un estudio exhaustivo de todas las tecnologías y determinar el alcance de la implementación (identificando los sistemas y sus perfiles de monitorización), se ha llegado a las siguientes conclusiones:
Una vez conocidos los requisitos básicos para la implantación en cada fase (tasa de módulos / segundo), número de alertas totales, módulos por dia y megabytes por mes, se va a realizar una prueba de esfuerzo (stress) real sobre un servidor relativamente similar a los sistemas de producción (no se ha podido hacer la prueba en una máquina similar a las de producción).
Estas pruebas de stress, dirán qué capacidad de proceso tiene Pandora FMS en un servidor y cuál es su nivel de degradación con el tiempo. Esto sirve para los siguientes objetivos:
Las pruebas realizadas, han sido sobre un servidor DELL PowerEdge T100® con procesador Intel Core Duo® a 2,4Ghz y con 2 GB de RAM. Este servidor, funcionando sobre un Ubuntu Server 8.04 y ha proporcionado la base de estudio para las pruebas en entornos de Alta Capacidad. Las pruebas se han realizado sobre configuraciones de agente relativamente similares a las del proyecto de QUASAR TECNOLOGIES. La intención de las pruebas no es replicar exactamente el mismo volumen de información que va a tener QUASAR TECNOLOGIES, ya que no se dispone del mismo hardware, sino replicar un entorno de alta capacidad, similar al de QUASAR TECNOLOGIES para evaluar el impacto en el rendimiento a lo largo del tiempo y determinar otros problemas (principalmente de usabilidad) derivados de manejar grandes volúmenes de datos.
Los resultados obtenidos son muy positivos ya que el sistema, aunque muy sobrecargado, era capaz de procesar un volumen de información muy considerable (180 000 módulos, 6000 agentes y 120 000 alertas). Las conclusiones derivadas de este estudio son las siguientes:
Si bien el punto anterior representaba un estudio “rápido” basado únicamente en módulos de tipo “dataserver”, en este capítulo se presenta una forma más completa de hacer un análisis de la capacidad de Pandora FMS.
Como punto de partida, en todos los casos se utilizará siempre la filosofía de “el peor de los casos” siempre que se pueda escoger. Se asume que, si no se puede escoger, será la filosofía “el caso habitual”. Nunca se estimará nada en el “mejor de los casos” ya que no es válida.
A continuación, se verá cómo calcular la capacidad del sistema, por tipo de monitorización o en base al origen de la información.
En base a unos objetivos, calculados según el punto anterior, se supondrá que el objetivo estimado es ver cómo se comporta con una carga de 100 000 módulos, repartido entre un total de 3000 agentes, esto es, una media de 33 módulos por agente.
Se creará una tarea de pandora_xmlstress
ejecutada mediante cron o script) manual, que contenga 33 módulos, repartidos con una configuración similar a esta:
generic_proc
.generic_data
.
Se configurarán los umbrales de los 17 módulos de tipo generic_proc
de esta manera:
module_begin module_name Process Status X module_type generic_proc module_description Status of my super-important daemon / service / process module_exec type=RANDOM;variation=1;min=0;max=100 module_end
En los 15 módulos de tipo generic_data
se deben establecer umbrales. El procedimiento a seguir será el siguiente:
Se configurarán los umbrales de los 15 módulos de tipo generic_data
de forma que genere datos de tipo:
module_exec type=SCATTER;prob=20;avg=10;min=0;''m''ax=100
Se configurarán los umbrales para esos 15 módulos, de forma que tengan este patrón:
0-50 normal 50-74 warning 75- critical
Se añadirán al fichero de configuración del pandora_xml_stress
unos tokens nuevos para poder definir los umbrales desde la generación del XML. Atención: esto debido a que Pandora FMS solo “adopta” la definición de umbrales en la creación del módulo, pero no en la actualización con datos nuevos.
module_min_critical 75 module_min_warning 50
Ejecute el pandora_xml_stress
.
Se debe dejar corriendo al menos 48 horas sin ningún tipo de interrupción y debe monitorizar (con un agente de Pandora FMS) los siguientes parámetros:
find /var/spool/pandora/data_in | wc -l
pandora_server
:ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $3}'
ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $4}'
ps aux | grep "sbin/mysqld" | grep -v grep | awk '{print $3}'
/usr/share/pandora_server/util/pandora_database_check.pl /etc/pandora/pandora_server.conf
unknown
):echo "select SUM(unknown_count) FROM tagente;" | mysql -u pandora -p<password> -D pandora | tail -1
(donde <password>
es la contraseña del usuario pandora
)
Las primeras ejecuciones tienen que servirnos para afinar el servidor y la configuración de MySQL.
Se utilizará el script/usr/share/pandora_server/util/pandora_count.sh
para contar (cuando haya ficheros XML pendientes de procesar) la tasa de procesamiento de paquetes. El objetivo es lograr que se puedan “procesar” todos los paquetes generados (3000) en un intervalo inferior al 80% del tiempo límite (5 minutos). Esto implica que se tienen que procesar 3000 paquetes en 4 minutos, luego:
3000 / (4x60) = 12,5
Se tiene que lograr una tasa de procesamiento de 12,5 paquetes como mínimo para estar razonablemente seguros de que Pandora FMS puede procesar esa información.
Elementos a ajustar:
max_queue_files
).Importancia de todo esto: una instalación de Pandora FMS con un servidor GNU/Linux instalado “por defecto” en una máquina potente, puede no pasar de 5 a 6 paquetes por segundo, en una máquina potente bien “optimizada” y “acondicionada” puede llegar perfectamente de 30 a 40 paquetes por segundo. Esto también depende mucho de la cantidad de módulos que haya en cada agente.
Se configura el sistema para que el script de mantenimiento de BBDD en /usr/share/pandora_server/util/pandora_db.pl
se ejecute cada hora en vez de cada día:
mv /etc/cron.daily/pandora_db /etc/cron.hourly
Se deja funcionando el sistema, con el generador de paquetes un mínimo de 48 horas. Una vez pasado ese tiempo se evalúan los siguientes puntos:
pandora_server
”: debería tener frecuentes picos, pero con una tendencia constante, no creciente.
Si todo ha ido bien, ahora se debe evaluar el impacto del rendimiento de la ejecución de alertas. Aplique una alerta a cinco módulos específicos de cada agente (de tipo generic_data
), para la condicion CRITICAL
. Algo que sea relativamente ligero, como crear un evento o escribir a syslog (para evitar el impacto que pudiera tener algo con alta latencia como enviar un mensaje de correo electrónico).
Opcionalmente puede crear una alerta de correlación de eventos para generar una alerta para cualquier condición crítica de cualquier agente con uno de esos cinco módulos.
Deje el sistema 12 horas operando bajo esos criterios y evalúe el impacto, siguiendo el criterio anterior.
Suponiendo que la política de almacenamiento de datos fuera:
Debería dejar el sistema funcionando “solo” durante al menos 10 días para evaluar el rendimiento a largo plazo. Puede que viera un “pico” sustancial al cabo de 7 días debido al movimiento de datos a la BBDD de histórico. Esa degradación es importante tenerla en cuenta. Si no se puede disponer de tanto tiempo, se puede reproducir (con menos “realismo”) cambiando el intervalo de purgado a 2 días en eventos y 2 días para mover datos a histórico, para evaluar ese impacto.
Se trata específicamente del servidor de red ICMP. En caso de realizar las pruebas para el servidor de red versión Open, vea el punto correspondiente al servidor de red (genérico).
Suponga que ya tiene el servidor funcionando y configurado. Algunos parámetros clave para su funcionamiento:
block_size X
Define el número de pings que hará el sistema por cada ejecución. Si la mayoría de pings van a tardar lo mismo, puede subir el número a un número considerablemente alto, por ejemplo: de 50 a 70.
Si, por el contrario, el parque de módulos de ping es heterogéneo y están en redes muy diferentes, con tiempos de latencia muy diferentes, no interesa poner un número alto, pues la prueba tardará lo que tarde el más lento, así que puede utilizar un número relativamente bajo, como de 15 a 20.
icmp_threads X
Evidentemente, cuantos más hilos tenga, más chequeos podrá ejecutar. Si suma todos los hilos que ejecuta Pandora FMS no deberían llegar al rango de 30-40. No debería usar más de 10 hilos aquí, aunque depende mucho del tipo de hardware y la versión de GNU/Linux que esté usando.
Ahora, debe “crear” un número ficticio de módulos de tipo ping para probar. Se asume que va a probar un total de 3000 módulos de tipo ping. Para ello, lo mejor es tomar un sistema en la red que sea capaz de soportar todos los pings (un servidor GNU/Linux cualquiera puede con esa tarea).
Utilizando el importador CSV de Pandora FMS (disponible en la versión Enteprise), cree un fichero con el siguiente formato:
(Nombre agente, IP,os_id,Interval,Group_id)
Puede usarse este shellscript para generar ese fichero (cambiando la dirección IP de destino y el ID de grupo)
A=3000 while [ $A -gt 0 ] do echo "AGENT_$A,192.168.50.1,1,300,10" A=`expr $A - 1` done
Lo principal es tener a Pandora FMS monitorizada, midiendo las métricas que del punto anterior: consumo de CPU (pandora y mysql), número de módulos en estado desconocido y otros monitores interesantes.
Importe el CSV para crear 3000 agentes, lo cual tardará unos minutos. Luego vaya al primer agente (AGENT_3000
) y cree en él un módulo de tipo PING.
A continuación, vaya a la herramienta de operaciones masivas y copie ese módulo a los otros 2999 agentes restantes.
Pandora debería empezar a procesar esos módulos. Mida con las mismas métricas que el caso anterior y vea como evoluciona. El objetivo es dejar un sistema operable para el número de módulos de tipo ICMP requerido sin que ninguno de ellos llegue a estado desconocido.
Aquí se trata específicamente del servidor de red SNMP. En caso de realizar las pruebas para el servidor de red Open, vea el punto correspondiente al servidor de red (genérico).
Suponga que ya tiene el servidor funcionando y configurado. Algunos parámetros clave para su funcionamiento:
block_size X
Define el número de peticiones SNMP que hará el sistema por cada ejecución. Hay que tener en cuenta que el servidor los agrupa por dirección IP de destino, de forma que ese bloque es orientativo. Conviene que no sea muy grande (30 a 40 como máximo). Cuando un elemento del bloque falla, un contador interno hace que lo reintente el servidor PFMS.
snmp_threads X
Evidentemente, cuantos más hilos tenga, más chequeos podrá ejecutar. Si suma todos los hilos que ejecuta Pandora FMS no deberían llegar al rango de 30 a 40. No debería usar más de 10 hilos aquí, aunque depende mucho del tipo de hardware y la versión de GNU/Linux que esté usando.
La forma más rápida de probar es mediante un dispositivo SNMP, aplicando a todos los interfaces, todos los módulos de monitorización “básicos” de serie. Esto se hace mediante la aplicación del SNMP Explorer (Agente → Modo de administración → SNMP Explorer). Identifique las interfaces, y aplique todas las métricas a cada interfaz. En un switch de 24 puertos, esto genera unos 650 módulos.
Si genera otro agente con otro nombre, pero la misma dirección IP tendrá otros 650 módulos. Otra opción puede ser copiar todos los módulos a una serie de agentes que tengan todos la misma dirección IP de forma que los módulos copiados funcionen “atacando” al mismo switch.
Otra opción es utilizar un emulador de SNMP, como el Jalasoft SNMP Device Simulator.
El objetivo de este punto es ser capaz de monitorizar de forma constante, un pool de módulos SNMP durante al menos 48 horas, monitorizando la infraestructura, para asegurarse de que el ratio de monitorización de módulos por segundo es constante, y no existen períodos de tiempo donde el servidor produzca módulos en estado desconocido. Esta situación se podría dar por:
Aquí aplica el mismo concepto que arriba, pero de forma más simplificada. Habrá que controlar:
Dimensionar con esos datos un conjunto de prueba, y verificar que la capacidad del servidor es constante a lo largo del tiempo.
Aquí el supuesto es más sencillo: se parte de que el sistema no va a recibir traps de forma constante, sino que más bien se trata de evaluar la respuesta ante una avalancha de traps, de los cuales algunos generarán alertas.
Para ello simplemente hay que hacer un script que genere traps de forma controlada a gran velocidad:
#!/bin/bash TARGET=192.168.1.1 while [ 1 ] do snmptrap -v 1 -c public $TARGET .1.3.6.1.4.1.2789.2005 192.168.5.2 6 666 1233433 .1.3.6.1.4.1.2789.2005.1 s "$RANDOM" done
Nota: detenerlo con la tecla CTRL+C a los pocos segundos, pues generará cientos de traps rápidamente.
Una vez montado el entorno hay que validar los siguientes supuestos:
sleep 1
al script anterior dentro del bucle while, para generar 1 trap por segundo. Se deja el sistema operando 48 horas y se evalúa el impacto en el servidor.De forma similar a los SNMP, se evaluarán los eventos del sistema PFMS en dos supuestos:
/usr/share/pandora_server/util/pandora_manage.pl \ /etc/pandora/pandora_server.conf --create_event "Prueba de evento" system Pruebas
Ese comando, usado en un bucle como el usado para generar traps, se puede usar para generar decenas de eventos por segundo. Se puede paralelizar en un script con varias instancias para provocar un número más alto de inserciones. Esto serviría para simular el comportamiento del sistema ante una tormenta de eventos. De esta forma se podría probar el sistema, antes, durante y después de una tormenta de eventos.
Para ello se usará otro servidor independiente de Pandora FMS, utilizando la funcionalidad de monitorización WEB. En una sesión de usuario donde realizará las siguientes tareas en un orden específico y medirá lo que tardan en ser procesadas:
Se realiza esta prueba con al menos tres usuarios diferentes. Se puede paralelizar esa tarea para ejecutarla cada minuto, de forma que si hay 5 tareas (cada uno con su usuario), estaría simulando la navegación de cinco usuarios simultáneos. Una vez establecido el entorno, tendrá en cuenta: