Proyectos Multidisciplinares de las TIC-II. Mster en Telecomunicacin 2012-2013.

Autor: Julio Jornet Monteverde.

ndice de contenido.
1. 2. 3. INTRODUCCIN. ............................................................................................................................ 3 1.1. SISTEMAS DE MONITOREO CON O SIN AGENTES .......................................................................................... 3 EL PROYECTO OPENNMS................................................................................................................. 5 FUNCIONALIDADES ........................................................................................................................ 6 3.1. GESTIN DE EVENTOS Y ALARMAS ........................................................................................................... 6 3.1.1. Recoleccin de Eventos ............................................................................................................ 6 3.1.2. Correlacin de Alarmas ........................................................................................................... 7 3.1.3. Notificaciones de Usuario y Escalados Programados .............................................................. 9 3.1.4. Integracin de Trouble Tickets ................................................................................................. 9 3.2. RENDIMIENTO Y GESTIN DE SLAS ........................................................................................................ 10 3.2.1. Rendimiento y Gestin de recoleccin de datos .................................................................... 10 3.2.2. Visualizacin de Datos ........................................................................................................... 10 3.2.3. Gestin de SLAs ..................................................................................................................... 11 3.3. INTEGRACIN Y GESTIN DE CONFIGURACIN ......................................................................................... 11 3.3.1. Configuracin unificada ........................................................................................................ 11 3.3.2. Descubrimiento de la Red ...................................................................................................... 12 3.3.3. Configuracin de Interfaces ................................................................................................... 13 3.3.4. Integracin............................................................................................................................. 14 3.4. POLLER REMOTO ................................................................................................................................ 15 ARQUITECTURA ........................................................................................................................... 15 4.1. MEJORAS VERSIN 2.0. ....................................................................................................................... 16 IMPLEMENTACIN EN SPED.......................................................................................................... 17 OTROS SISTEMAS DE GESTIN DE RED .......................................................................................... 19 6.1. NAGIOS ............................................................................................................................................. 19 6.1.1. Caractersticas y funcionalidades .......................................................................................... 20 6.1.2. Funcionalidades bsicas ........................................................................................................ 20 6.1.3. Estructura .............................................................................................................................. 21 BIBLIOGRAFA Y REFERENCIAS ...................................................................................................... 22

4. 5. 6.

7.

1. Introduccin.
OpenNMS es una de las alternativas libres ms destacadas para realizar tareas de administracin y gestin de redes, bajo sistemas Linux. Esta poderosa herramienta, incorpora un paquete de funciones, que permiten controlar por completo todo el trfico de datos que se transmite a travs de la red. OpenNMS es una aplicacin fcil de utilizar. Podemos manipular cada una de las caractersticas de la red, as como, analizar y detallar cada uno de los archivos que se transfieren, y realizar una serie de tareas de gestin y de conexiones de red. Este software realiza un anlisis de cada una de las conexiones entrantes y salientes de nuestra red, con el principal objetivo de verificar si existen conexiones no autorizadas. Tambin, genera reportes completos de gestin, para documentar cada una de las situaciones que se presenten en la red. Cuenta con una licencia de funcionamiento GPL. OpenNMS es una plataforma de gestin de red de nivel empresarial desarrollada en el marco del modelo de cdigo abierto. A diferencia de los productos de gestin de red que estn muy centrados en los elementos de red tales como los interfaces switches y routers, OpenNMS se centra en los recursos de red que ofrecen servicios: pginas web, acceso a bases de datos, DNS, DHCP, etc (aunque la informacin sobre elementos de la red tambin est disponible ).

Como la mayora de los servicios de red se proporcionan a travs del protocolo TCP / IP, OpenNMS est muy centrado en el nivel IP. El elemento bsico de monitorizacin se llama "interfaz", y una interfaz se identifica por una direccin IP. Los servicios se asignan a las interfaces, y si una serie de interfaces que se descubren pertenecen al mismo dispositivo (ya sea a travs de SNMP o SMB), stas pueden agruparse juntas en un "nodo".

1.1. Sistemas de monitoreo con o sin agentes

El agente de un sistema de monitoreo es un componente de software. Generalmente es una pequea aplicacin que reside en el cliente y recoge datos. Los datos se envan al servidor central de la aplicacin en base a 2 opciones. La primera opcin es que el envo de datos sea administrado por el agente local, o este sea administrado por la estacin de 3

monitoreo central.

Los sistemas que tienen la poltica de envo de informacin al servidor administrada por el agente ubicado en el cliente, tienen como desventaja que pueden generar cargas de trabajo en los equipos clientes. Por lo tanto es deseable que las polticas de envo de informacin sean administradas por el servidor y no por el agente.

En la tabla 1 se expone un cuadro de ventajas y desventajas de sistemas con agentes y sistemas sin agentes.

Sistemas con agentes

Ventajas Desventajas Desventajas Informacin ms especfica y ms detallada. Mayor flexibilidad para realizar monitoreos personalizable. Posibilidad de crear soluciones de monitoreos que controlen estados de servicios o mtricas no estndares sobre aplicaciones o hardware. El control de las aplicaciones y servicios se realiza directamente en el nodo monitoreado. Mayor seguridad en la red ya que se manejan protocolos propietarios de encriptacin. Menor riesgo de deteccin de inactividades. Puede provocar mayor carga de actividad en el cliente Se debe instalar el agente en todos los equipos que se van a monitorear. Sistemas sin agentes No hay que instalar el agente en el cliente No se genera carga de trabajo en el cliente Es una opcin para casos en los que no es posible instalar aplicaciones en los clientes Tiene mtricas menos especificas por consiguiente se pueden realizar anlisis menos detallados. Pueden ser afectadas por hechos que sucedan en la red. El desarrollo de complementos puede ser mas complicado, o directamente imposibles de realizar. No son seguros.

Ventajas

Tabla 1: Ventajas y desventajas de los agentes en sistemas de monitoreo.

Las soluciones basadas en agentes instalados en el cliente brindarn acceso a ms informacin y con mtricas ms detalladas, este hecho puede ser importante para disminuir el tiempo de deteccin de fallos, mientras que soluciones sin agentes le permiten al fabricante evitar la etapa de desarrollo del agente pero con el riesgo de 4

obtener menos datos y en un entorno menos seguro. En base a lo expuesto, y teniendo en cuenta las ventajas y desventajas ya nombradas anteriormente de ambas soluciones se agrega como requerimiento no funcional la caracterstica de tener en su estructura el uso de un agente en el cliente.

2. El Proyecto OpenNMS
Como ya se ha comentado, OpenNMS es un sistema de gestin de red orientado a agente, y es la primera plataforma desarrollada bajo cdigo abierto, GPL.

Est escrito en Java y por lo tanto es portable a todas las plataformas del mercado, Windows, Linux, Sun, Unix, etc. Su escalabilidad en los sistemas ha sido probada, prueba de ello son los resultados obtenidos: 300.000 puntos de datos cada 5 minutos y deteccin automtica de nodos centrales con ms de 5000 interfaces.

Existe una amplia comunidad de usuarios comerciales que utilizan OpenNMS en sus sistemas, tales como: Swisscom, MySpace, Foxtel, Fox TV, BBC Monitoring, Wind Telecomunications. La comunidad OpenNMS es muy activa y existen cerca de 1000 usuarios activos subscritos en las listas de discusin. En la actualidad tienen unos 35 desarrolladores con acceso a los repositorios. La comunidad est gestionada por la Orden del Polo Verde (OGP). Todos los miembros de dicha orden tienen un voto en la direccin del proyecto y 5

no existen restricciones de acceso.

La licencia es del tipo GPL y la propiedad intelectual as como la marca es propiedad del Grupo OpenNMS. El objetivo del grupo es promover el proyecto.

3. Funcionalidades
OpenNMS est dividido en una serie de funcionalidades que cumplen con unas determinadas caractersticas.

3.1. Gestin de Eventos y Alarmas 3.1.1. Recoleccin de Eventos

OpenNMS puede registrar todo tipo de eventos ocurridos: Trigers, evaluacin de eventos, automatizacin de acciones en funcin del procesado de la tabla de alarmas. Los Nodos Pasivos se utilizan para representar servicios o recursos gestionados por otro agente. Existen dos procesos llamados Event Translator y Pasive Status que permiten a los eventos mapearse a estos nodos. El proceso Actiond se utiliza para generar acciones Java basados en la recepcin de eventos. Tambin se pueden enviar los eventos que se deseen via XML-RPC a otro sistema de gestin remoto.

Los eventos se controlan con el proceso Eventd el cual recibe y graba toda la informacin. Este proceso escucha el puerto 5817 por el cual los dems procesos envan peticiones e incluso se pueden enviar desde sistemas externos a OpenNMS.

Listado de Eventos

3.1.2. Correlacin de Alarmas

Se utiliza un mecanismo de Alarma para manejar traps de recoleccin de alarmas o traps de anulacin de alarmas en un entorno de gestin de alarmas cclico. Cuando se recibe 7

por primera vez un trap o disparo se recoge una alarma. Si se reciben sucesivos traps, stos se contarn en la misma alarma. Si se reconoce la alarma, se provocar un trap de limpieza de la alarma y sta desaparecer quedando el sistema preparado para recibir un nuevo evento. Este mecanismo de utilizacin es el ms simple en un listado de alarmas. El usuario tambin puede configurar reglas ms sofisticadas de tratamiento de eventos de alarmas incluso automatizndolo en funcin de un sofisticado anlisis ya que posee un motor de reglas.

Listado de Alarmas

Detalle de Alarma

3.1.3. Notificaciones de Usuario y Escalados Programados

OpenNMS soporta mltiples usuarios y proporciona un mecanismo de Escalado de Notificaciones entre los usuarios. Si se detecta un evento severo, como una alarma Mayor, este mecanismo generar una Notificacin que se escalar en el tiempo a travs de una lista de usuarios si la alarma no se reconoce en un periodo de tiempo definido por el usuario. El sistema tambin puede generar un sonido, un email o un mensaje instantneo para llamar la atencin sobre la notificacin. Tambin existen mecanismos de notificacin tales: XMPP: Jabber, un protocolo de mensajera instantnea. Programas externos Traps SNMPs HTTP GET/POST hacia una web site.

Se pueden definir grupos de usuarios y roles a los cuales se les puede asociar cuentas email genricas.

Listado de Notificaciones

3.1.4. Integracin de Trouble Tickets

Si el mecanismo de escalado bsico no es suficiente, OpenNMS tambin dispone de una interface Trouble Ticket para integrarlo en el sistema con un nmero de incidencia.

3.2. Rendimiento y Gestin de SLAs 3.2.1. Rendimiento y Gestin de recoleccin de datos

Como en otras herramientas de gestin de redes tales como Nagios o Cricket, OpenNMS almacena datos en ficheros RRD. Se puede utilizar la herramienta RRD para hacer la recoleccin de datos pero la librera preferida es JRobin la cual es una implementacin Java de RRD. OpenNMS ya lleva implementada una MIBS (base de datos SMNP) que soporta la gran mayora de fabricantes de equipamiento, pero los usuarios pueden definir sus propias configuraciones. La comunidad de usuarios suelen compartir estos trabajos y sus experiencias con los nuevos equipos. Sin embargo, a diferencia de estas herramientas, toda la programacin de la recoleccin de datos se controla totalmente por un proceso Java dentro de OpenNMS el cual hace que la solucin sea muy escalable. Los datos pueden recogerse desde varias fuentes distintas: sondeo SNMP, traps de gestin, mensajes ASCII tipo syslog, TL1, JMX. Tambin existe una integracin con Nagios que permite la utilizacin de plugins de Nagios. OpenNMS tambin se ha integrado con SNORT.

3.2.2. Visualizacin de Datos

OpenNMS presenta los datos de rendimiento en forma de grficos. Estos grficos tambin se pueden exportar en forma de informes de rendimiento. Tambin se pueden definir umbrales que generan alarmas cuando hay cambios en los datos. OpenNMS puede realizar transacciones sintticas para comprobar la disponibilidad de servicios en los nodos. Esto se puede realizar de una manera centralizada o con un conjunto de rollers distribuidos remotamente.

10

3.2.3. Gestin de SLAs

Se pueden definir umbrales en los SLAs que generarn una alarma en cuanto se rebasen y pueden escalarse en funcin de las reglas definidas. A cada punto de recoleccin de datos de rendimiento se le puede asignar dos umbrales, uo superior y otro inferior, para evitar los rebotes de alarmas.

3.3. Integracin y Gestin de Configuracin 3.3.1. Configuracin unificada

Toda la configuracin de OpenNMS est almacenada en archivos XML y se encuentra dentro de un directorio. Muchas de estas configuraciones tambin se exponen en la interface de usuario. Las configuraciones incluyen los tiempos de barrido, mapeado de traps del tipo eventos/alarmas, gestin de MIBs, etc.

11

3.3.2. Descubrimiento de la Red

Dado un rango de direcciones, OpenNMS puede descubrir por si mismo los elementos y servicios dentro de una red. Automticamente asocia puertos con nodos. La nomenclatura por defecto de un nodo en la base de datos se rellenar con el nombre del dispositivo detectado por un escaneo SNMP del dispositivo. El proceso responsable de la tarea de detectar los servicios es Capsd y es capaz de detectar los siguientes servicios: Citrix DHCP DNS Domino IIOP FTP General Purpose (script based) HTTP HTTPS ICMP IMAP JBOSS (JMX) JDBC JDBC Stored Procedure JSR160 K5 LDAP Microsoft Exchange MX4J Notes HTTP NSClient (Nagios Agent) NRPE (Nagios Remote Plugin Executor) NTP POP3 Radius SMB SMTP SNMP SSH TCP Windows Services (SNMP-based)

Es posible importar la configuracin de los servicios con un fichero tipo XML. Esta configuracin deshabilitar los procesos de descubrimiento por medio de barridos ping. El proceso Capsd es el responsable de descubrir todos los servicios a monitorizar sobre un dispositivo. Recopila y almacena datos de diversas fuentes, incluyendo SNMP, JMX, HTTP y NSClient. Si el dispositivo tiene implementado SMNP, entonces es capaz de manejar todos los

12

servicios interrogando y registrando los tiempos de respuesta utilizando transacciones sintticas.

3.3.3. Configuracin de Interfaces

Tambin se pueden utilizar archivos XML conteniendo la configuracin de las interfaces y as modificar el nombre y el inventario de la Red. Como ejemplo podemos comentar que esta interfaz la utiliza Swisscom para sincronizar OpenNMS con su red WIFI Europea de Hotspots. OpenNMS implementa un mecanismo de provisionamiento automtico que est integrado con el sistema RANCID (RANCID Really Awesome New Cisco confIg Differ http://www.shrubbery.net/rancid/), (http://reductivelabs.com/trac/puppet). y tambin con PUPPET.

Ejemplo de Porvisionamiento Manual

Ejemplo de Provisionamiento externo con XML

13

3.3.4. Integracin
OpenNMS posee numerosos puntos de integracin para la paginacin, sonidos de alarmas, email, tratamiento de tickets/incidencias, etc.

El sistema est preparado para utilizar mapas para mostrar la topologa de la red tal y como se refleja a continuacin.

14

3.4. Poller Remoto

OpenNMS implementa una funcionalidad para poder realizar interrogaciones desde puestos remotos. El cliente remoto se conecta al servidor OpenNMS y se descarga el plugin Remote Poller utilizando el Java Web Start. Una vez ejecutndose, el plugin interroga los servicios de los nodos centrales utilizando transacciones sintticas. Una vez se tienen los resultados, se envan al servidor OpenNMS.

4. Arquitectura
A continuacin se muestra un diagrama de bloques de la arquitectura OpenNMS:

15

El sistema tiene una serie de APIs que son las siguientes: API Servicio Detector: Deteccin de Servicios, Interface Java. API Servicio Monitor: Plugin Poller para monitorizar los servicios detectados, Interface Java. API Servicio Recoleccin: Plugin Collectd para crear los recolectores de datos de rendimiento. Interface Java. API Servicio Thesholder: Plugin para crear umbrales de servicios detectados. Interface Java. API Notificaciones estratgicas: Plugin para crear nuevos mtodos de notificacin. Interface Java. API Reconocimiento: Plugin para leer las respuestas a las notificaciones. Interface Java. API Provisin Adaptador: Plugin para la integracin de CMS, EMS, sistemas de inventariado, etc. Interface Java.

A continuacin se muestra un ejemplo de cmo se comunican los procesos internos:

4.1. Mejoras versin 2.0.

En la parte de provisionamiento se ha implementado una nueva arquitectura con un modo de descubrimiento de servicios y recursos en paralelo. La interfaz de usuario se ha actualizado a un entorno Web (AJAX) 16

Se ha mejorado el flujo de trabajo de las Alarmas y del Escalado. Se ha implementado una API REST para poder acceder utilizando tecnologas web (Pearl, python, etc).

Se han implementado seguridad en las Listas de Control de Acceso a Usuarios (ACLs) permitiendo una granularidad fina del control de usuarios.

Tambin se han reducido el nmero de reinicios requeridos en el sistema por cambios en la configuracin.

Se ha implementado un mdulo de soluciones de tolerancia a fallos.

5. Implementacin en SPED
Tal y como se ha planteado el Sistema de Prevencin, Extincin de incendios forestales y Deteccin de plantaciones irregulares (SPED), y una vez analizado en profundidad el funcionamiento del sistema OpenNMS, podemos implementarlo para controlar y gestionar nuestros servidores de datos, servidores de grabacin de imgenes y hasta en nuestros dispositivos concentradores o routers Meshlium Xtreme ya que tienen un SO basado en Linux y por lo tanto podemos cargar el agente OpenNMS. El hecho de que podamos implementar OpenNMS en los routers Meshlium tambin implica que podamos supervisar las interfaces de ste y por ello nuestra red de transmisin compuesta de enlaces punto-punto o punto-multipunto. En cuanto a los Motes, no podemos utilizar el sistema OpenNMS ya que estos dispositivos estn configurados para utilizar la tecnologa ZigBee como medio de comunicacin hasta el router y todava no est soportado Zigbee en OpenNMS. Adems, existe una restriccin que hace que los Motes no puedan implementar un agente y es que el software de control est especialmente diseado para tener un bajo consumo. Esto conlleva a que el Mote est la mayor parte del tiempo en modo suspensin y solamente se despierte para enviar los valores de los sensores y para notificar al coordinador de su existencia. Tambin tenemos la limitacin de la memoria ya que estos dispositivos tienen muy poca memoria. Existe un modelo de Mote que implementa un interface WIFI para la comunicacin y que nos permitira gestionar en parte dicha comunicacin con OpenNMS, pero el consumo se disparara y ya no sera viable ya que los requerimientos de energa conllevaran una mayor batera y placa solar mayor. 17

Existe un SO que se ha diseado para los dispositivos ZigBee y es el TinyOS que se trata de un sistema operativo de cdigo abierto y el cual nos brindara la posibilidad de implementar un pequeo agente con su propia MIB dentro del mdulo de comunicacin ZigBee, pero hay que tener en cuenta que la filosofa de gestin de OpenNMS es que quien realiza el Polling es el gestor OpenNMS hacia los dispositivos e interfaces y por diseo esto no es operativo ya que la gran mayora de veces nuestro Mote estara en suspensin. La idea a trabajar sera implementar la comunicacin en sentido contrario, es decir, quien inicia el polling debe ser nuestro dispositivo ZigBee para anunciar su existencia al router coordinador y ste como s que tiene implementado el agente OpenNMS ser el que controlar los tiempos de respuesta y dems datos. Una futura lnea de investigacin sera evaluar y probar todas las ideas expuestas ya que los Motes son dispositivos muy verstiles y adems existe software de cdigo abierto que abre un sinfn de posibilidades.

18

6. Otros Sistemas de Gestin de Red

Como ya se ha mencionado en apartados anteriores, otro de los sistemas de monitorizacin es Nagios. Es el ms popular en lo que a sistemas de monitorizacin de cdigo abierto se refiere y se ha establecido como un estndar de facto.

6.1. Nagios
Nagios es una popular herramienta de monitorizacin de servicios de red y dispositivos. Administradores de sistemas de todo el mundo dependen de Nagios y de su galera de plugins para mantener sus sistemas en funcionamiento y detectar los problemas antes de que ocurran. Pero Nagios tiene un par de problemas:

Nagios carece de un soporte adecuado para entornos de gran magnitud, as como de tcnicas corporativas contemporneas como pueda ser el clustering.

El cdigo base en C de Nagios, con diez aos de antigedad, presenta limitaciones a la hora de adaptarlo a la rpida evolucin de las redes de hoy en da.

Existe una evolucin de Nagios que soluciona los dos problemas mencionados y se trata de Shinken. El objetivo de Shinken es el de proporcionar un nuevo modelo multi-proceso distribuido que se adapte bien a entornos distribuidos y heterogneos. El proyecto Shinken se encuentra en una fase temprana y falta implementar ms funcionalidades. El objetivo es asegurar una compatibilidad absoluta entre sus archivos y los de Nagios.

19

6.1.1. Caractersticas y funcionalidades

Nagios marca el estndar en la industria de monitoreo a grandes niveles por unas cuantas razones. Este permite controlar la red informtica y solucionar problemas antes que los usuarios los detecten. Nagios es un sistema estable, escalable, con soporte y extensible.

Este sistema permite monitorear una importante cantidad de dispositivos y sistemas como por ejemplo: Sistemas Operativos Windows, Sistemas Operativos Linux/Unix, Routers, Switches, Firewalls, Impresoras, Servicios y Aplicaciones. NAgios cuenta con una muy importante cantidad de addons desarrollados por la comunidad (ms de 200) que permiten extender las funcionalidades del sistema. Es un software de cdigo abierto, con acceso completo al cdigo fuente, liberado bajo licencia GPL.

Nagios es un sistema que cuenta con ms de 10 aos en desarrollo, es un sistema que permite escalar hasta monitorear ms de 100,000 nodos, cuenta con gran reconocimiento, ganador de mltiples premios. Actualmente cuenta con ms de 250.000 usuarios alrededor del mundo. Tiene una lista de correos activa y una amplia comunidad a travs del website.

6.1.2. Funcionalidades bsicas

Se destacan las siguientes caractersticas de funcionamiento:

20

Enviar de forma inmediata notificaciones de problemas va email, pager o telfonos celulares. Capacidad de notificar a mltiples usuarios. Uso de su interfase web que permite ver informacin detallada de los estados de los distintos componentes, reconocer problemas de forma rpida. Permite reiniciar automticamente aplicaciones que hayan fallado, servicios y equipos. Permite agendar actualizaciones de hosts, servicios y componentes de la red. Permite planificar las capacidades de los componentes a travs del monitoreo. Permite generar reportes de disponibiidad SLA (Service Level Agreements), y reportes histricos de alertas y notificaciones. Adems permite ver las tendencias de los informes a travs de la integracin con Cactus y RRD.

Mltiples usuarios pueden acceder a la interfase web, adems cada usuario puede tener una vista nica y restringida.

6.1.3. Estructura
Nagios tiene las siguientes caractersticas principales en cuanto a su estructura:

El sistema cuenta con un ncleo que forma la lgica de control de negocio de la aplicacin, este contiene el software necesario para realizar la monitorizacin de los servicios y de las mquinas de la red.

El sistema hace uso de diversos componentes que ya vienen en el paquete de instalacin con la aplicacin, y puede hacer uso de otros componentes realizados por terceras personas.

El autor sostiene que aunque permite la captura de paquetes SNMP para notificar sucesos, pero no es un sistema de monitorizacin y gestin basado en SNMP, sino que realiza su labor basndose en una gran cantidad de pequeos mdulos software que realizan chequeos de partes de la red.

Muestra los resultados de la monitorizacin y del uso de los diversos componentes en una interfaz web a travs de un conjunto de CGIs y de un conjunto de pginas HTML que vienen incorporadas, y que permiten al administrador una completa visin de lo qu ocurre, en dnde ocurre y en algunos casos el por qu ocurre.

21

Por ltimo, si se compila para ello, Nagios guardar los histricos en una base de datos para que al detener y reanudar el servicio de monitorizacin, todos los datos sigan sin cambios.

Nagios permite monitorizar sistemas Windows mediante la instalacin de un agente en la mquina a monitorizar, aunque la parte servidor de Nagios debe residir en un servidor Unix/Linux.

7. Bibliografa y Referencias
Proyecto SIGNA, Aplicaciones de Monitoreo. Estudio de alternativas de cdigo abierto. Introduction to OpenNMS. Craig Gallen, 2009. Desarrollo de un entorno para configuracin y monitorizacin de redes Zigbee. Proyecto Fin de Carrera, Sergio Lillo Moreno. Informe Tcnico: Protocolo ZigBee (802.15.4). Javier Martn y Daniel Ruiz. Junio 2007. http://www.libelium.com/development/waspmote http://www.opennms.org/ http://www.nagios.org/

22