Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento

Texto completo

(1)ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN. PROYECTO FIN DE GRADO TÍTULO: Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento AUTOR: Zakariae Ziggaf Kanjaa TITULACIÓN: Grado en Ingeniería Telemática. DIRECTOR: Carlos Ramos Gallardo TUTOR: Ana Belén García Hernando DEPARTAMENTO: Departamento de Ingeniería Telemática y Electrónica. VºBº. Miembros del Tribunal Calificador:. PRESIDENTE: Margarita Millán Valenzuela. TUTOR: Ana Belén García Hernando. SECRETARIO: Antonio da Silva Fariña. Fecha de lectura:. Calificación:. El Secretario,.

(2)

(3) Agradecimientos Primero quisiera agradecer a mi familia todo su apoyo. En especial a mi hermana Rachida y sobre todo a mis padres porque gracias a su esfuerzo pudieron darme la oportunidad de cursar mis estudios universitarios. Quiero también dar las gracias a mi tutora Ana Belén García y mi tutor profesional Carlos Ramos por todo su apoyo y esfuerzo. Y por último agradecer a mi actual empresa, Satec S.A por haber puesto a mi disposición todos los medios necesarios para la realización del proyecto..

(4)

(5) Resumen Hoy en día resulta casi imprescindible el uso de herramientas de control de los recursos informáticos por parte de empresas del sector IT (Information Technology), ya sea a nivel de recursos internos, o bien, recursos informáticos externos gestionados por otras entidades. Disponer de un sistema de monitorización modular que permita supervisar las infraestructuras informáticas supone un gran ahorro de personal y de tiempo ya que la forma de detectar y solucionar las incidencias es más rápida, aumentando así la seguridad de las redes monitorizadas y por la tanto mejorando la calidad del servicio ofrecido al cliente final. El objetivo de este proyecto fin de grado es implementar un sistema de monitorización basado en software OpenSource. El sistema propuesto consiste en el despliegue de una solución de monitorización que permita la distribución de sus servicios y componentes entre servidores (Modo Clúster) y que sea un sistema escalable ante el crecimiento de los equipos monitorizados o el incremento de usuarios que acceden a ese sistema de monitorización. Para entrar en el contexto inicialmente se presenta un estudio comparativo de las herramientas de monitorización de redes y servicios más utilizadas del sector IT, tales como Nagios, ZenOSS, OsmiUS y Zabbix. A partir de este estudio se ha decidido utilizar ZenOSS como base para desarrollar un sistema de monitorización de alta disponibilidad. Cabe destacar que un requisito no funcional del presente proyecto será desarrollar la totalidad del proyecto usando únicamente software de código libre. Este requisito abarca desde los entornos de desarrollo, sistemas operativos y bases de datos, hasta los lenguajes de programación y tecnologías utilizadas. Por último, se presentan pruebas y resultados concluyentes que muestran el correcto funcionamiento del sistema desarrollado.. i.

(6)

(7) Abstract Nowadays it is almost essential to use tools to control computer resources by companies in the IT sector (Information Technology), either at the level of internal resources or external IT resources managed by other entities. Having a modular monitoring system that allows monitoring computer infrastructures is a great saving of personnel and time since the way to detect and solve incidents is faster, thus increasing the security of monitored networks and therefore improving the quality of the service offered to the final customer. The objective of this final degree project is to implement a monitoring system based on OpenSource software. The proposed system consists of the deployment of a monitoring solution that allows the distribution of its services and components between servers (Cluster Mode) and that is a scalable system in view of the growth of the monitored equipment or the increase of users accessing that system of monitoring. To enter the context, a comparative study of the most used network and service monitoring tools of the IT sector, such as Nagios, ZenOSS, OsmiUS and Zabbix, is presented. From this study, it has been decided to use ZenOSS as the basis to develop a high availability monitoring system. It should be noted that a non-functional requirement of the present project will be to develop the entire project using only open source software. This requirement ranges from development environments, operating systems and databases, to the programming languages and technologies used. Finally, conclusive tests and results are presented that show the correct functioning of the developed system.. iii.

(8)

(9) Índice de Contenido Resumen ........................................................................................................................... i Abstract .......................................................................................................................... iii Índice de Contenido ........................................................................................................ v Índice de ilustraciones .................................................................................................. vii Índice de tablas .............................................................................................................. ix 1 1.1 1.2 1.3. Introducción y objetivos ..................................................................................... 1 Motivación ............................................................................................................ 1 Objetivos ............................................................................................................... 1 Estructura del resto de la memoria ....................................................................... 2. 2.1. Marco tecnológico del proyecto ......................................................................... 3 Herramientas de monitorización OpenSource ...................................................... 3. 2. 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5. 2.2 2.3. Sistemas en Clúster ............................................................................................... 6 Otros protocolos y tecnologías utilizadas en el proyecto ..................................... 7 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5. 3 3.1 3.2. 4.1. Descripción de la arquitectura lógica de la herramienta de monitorización utilizada .................... 15 Arquitectura en clúster para alta disponibilidad (HA) .................................................................... 19 Arquitectura Software.................................................................................................................... 24. Diseño de la monitorización ............................................................................... 26 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5. 4.3. Requisitos de los equipos monitorizados: ..................................................................................... 12 Requisitos de comunicaciones:..................................................................................................... 12. Descripción de la solución propuesta .............................................................. 15 Arquitectura ........................................................................................................ 15 4.1.1 4.1.2 4.1.3. 4.2. SSH ................................................................................................................................................. 7 SNMP .............................................................................................................................................. 7 WinRM ............................................................................................................................................ 8 RRDTool ......................................................................................................................................... 8 Lucene ............................................................................................................................................ 9. Especificaciones y restricciones de diseño ...................................................... 11 Restricciones provenientes de la herramienta de monitorización....................... 11 Requisitos de equipos y comunicaciones para realizar la monitorización ......... 11 3.2.1 3.2.2. 4. Osmius ............................................................................................................................................ 3 Nagios Core .................................................................................................................................... 4 ZenOSS Core.................................................................................................................................. 5 Zabbix ............................................................................................................................................. 5 Herramienta seleccionada .............................................................................................................. 6. El modelado de los elementos monitorizados............................................................................... 26 Herencia en la definición de los tipos de dispositivos ................................................................... 28 Definición de plugins de descubrimiento....................................................................................... 28 Definición de plantillas de monitorización ..................................................................................... 28 Definición de Event Class para el tratamiento de alarmas ........................................................... 29. Monitorización Activa ........................................................................................ 30 4.3.1 4.3.2. Monitorización de CPU ................................................................................................................. 33 Monitorización de Memoria ........................................................................................................... 37. v.

(10) 4.3.3 4.3.4. 4.4. Monitorización reactiva ...................................................................................... 51 4.4.1 4.4.2. 5 5.1. 6.1 6.2. Diseño de la monitorización de logs ..............................................................................................51 Integración del LogWatcher con ZenOSS .....................................................................................53. Pruebas y Resultados ........................................................................................ 55 Resultados: .......................................................................................................... 58 5.1.1 5.1.2 5.1.3. 6. Monitorización de FileSystem........................................................................................................43 Monitorización de Procesos ..........................................................................................................46. Resultados de monitorización activa mediante el protocolo SNMP ..............................................58 Resultados de monitorización activa mediante el protocolo SSH .................................................67 Resultado de la prueba del funcionamiento de la lógica del clúster desarrollada .........................74. Conclusiones y trabajos futuros ....................................................................... 77 Conclusiones ....................................................................................................... 77 Trabajos futuros .................................................................................................. 77. Referencias..................................................................................................................... 79 Anexo A.. Presupuesto .............................................................................................. 81. Anexo B.. Manual de usuario .................................................................................. 83. vi.

(11) Índice de ilustraciones Ilustración 1: Arquitectura de Osmius [3] ..................................................................................................3 Ilustración 2: Ejemplo de diseño básico de un clúster Activo-Pasivo ........................................................7 Ilustración 3: Modelo de Comunicaciones de monitorización..................................................................13 Ilustración 4: Diseño lógico por capas ....................................................................................................16 Ilustración 5: Diseño lógico de la base de datos .....................................................................................17 Ilustración 6: Diseño global arquitectura HA ...........................................................................................19 Ilustración 7: Grafo de dependencias funcionales entre los procesos ....................................................23 Ilustración 8: Modelado Global de la Monitorización ...............................................................................26 Ilustración 9: Concepto de dispositivo.....................................................................................................27 Ilustración 10: Modelado DeviceClass de la monitorización ...................................................................27 Ilustración 11: Lógica de agrupación de dispositivos ..............................................................................28 Ilustración 12: Estructura de una plantilla de monitorización (Monitoring Template) ..............................29 Ilustración 13: Representación gráfica del uso de CPU con umbral asociado ........................................35 Ilustración 14: Representación gráfica del uso de CPU ..........................................................................35 Ilustración 15: Representación gráfica del uso de Memoria....................................................................40 Ilustración 16: Gráficas para monitorización de uso de FileSystem ........................................................44 Ilustración 17: Modelado de Procesos ....................................................................................................47 Ilustración 18: Diseño para la monitorización de Logs mediante logWatcher .........................................52 Ilustración 19: Estructura de Event Classes para tratamientos de Logs .................................................53 Ilustración 20: Lógica de asignación de Event Class ..............................................................................54 Ilustración 21: Definición del dataSource Cpu Raw USer .......................................................................58 Ilustración 22: Definición del dataSource Cpu Raw Wait ........................................................................58 Ilustración 23: Definición del dataSource Cpu Raw System ...................................................................59 Ilustración 24: Definición de la gráfica CPU_Utilizacion ..........................................................................59 Ilustración 25: Grafica para monitorización de uso de CPU mediante SNMP .........................................59 Ilustración 26: Definición del dataSource memAvailReal ........................................................................60 Ilustración 27: Definición de la gráfica Memory Utilization ......................................................................60 Ilustración 28: Grafica para monitorización de uso de Memoria mediante SNMP ..................................61 Ilustración 29: Definicion de los dataSources UsedBlocks y TotalBlocks ...............................................61 Ilustración 30: Definición de la gráfica Usage .........................................................................................62 Ilustración 31: Pasar de Blocks a Bytes ..................................................................................................62 Ilustración 32: Grafica para monitorización de uso de FileSystem mediante SNMP ...............................63 Ilustración 33: Definición del dataSource MemoryAvailable....................................................................64 Ilustración 34: Definición de la gráfica Used ...........................................................................................64 Ilustración 35: Propiedades del GraphPoint ............................................................................................65 Ilustración 36: Grafica para monitorización de uso de Memoria .............................................................65 Ilustración 37: Definir el dataPoint CpuBusyTimePerCent ......................................................................66 Ilustración 38: Definición de la gráfica ....................................................................................................66 Ilustración 39: Grafica para monitorización de uso de CPU ....................................................................67 Ilustración 40: Definición del dataSource cpu_top con su correspondientes dataPoints.........................67 Ilustración 41: El contenido del dataSource cpu_top ..............................................................................68 Ilustración 42: Definición de la gráfica CPU Usage.................................................................................68 vii.

(12) Ilustración 43: Grafica para monitorización de uso de CPU mediante SSH ........................................... 69 Ilustración 44: Definición del dataSource mem_used............................................................................. 69 Ilustración 45: El contenido del dataSource Mem_used......................................................................... 69 Ilustración 46: Definición de la gráfica Memory Utilization ..................................................................... 70 Ilustración 47: Grafica para monitorización de uso de Memoria mediante SSH ..................................... 70 Ilustración 48: Defunción del dataSource disk ....................................................................................... 71 Ilustración 49: Definición de la gráfica Disk Utilization ........................................................................... 71 Ilustración 50: Grafica para monitorización de uso de FileSystem mediante SSH ................................. 72 Ilustración 51: Definicion del dataSource Cpu_idle ................................................................................ 72 Ilustración 52: Contenido del dataSource cpu_idle ................................................................................ 73 Ilustración 53: Definición de la gráfica CPU Utilization ........................................................................... 73 Ilustración 54: Grafica CPU Utilization ................................................................................................... 74 Ilustración 55: Los nodos del Clúster ..................................................................................................... 74 Ilustración 56: El estado del clúster ........................................................................................................ 75 Ilustración 57: Caida del servicio ZenCore ............................................................................................. 75 Ilustración 58: Arranque del servicio ZenCore ....................................................................................... 76 Ilustración 59: La instalacion del paquete ricci ....................................................................................... 83 Ilustración 60: Instalacion del Luci ......................................................................................................... 84 Ilustración 61: Arranque del servicio ricci ............................................................................................... 84 Ilustración 62: Luci ................................................................................................................................. 84 Ilustración 63: Crear un Cluster con el Luci............................................................................................ 85 Ilustración 64: Cluster de dos nodos ...................................................................................................... 85 Ilustración 65: Cluster.conf ..................................................................................................................... 86. viii.

(13) Índice de tablas Tabla 1: las comunicaciones necesarias para la monitorización activa y reactiva ..................................13 Tabla 2: Puntos de montaje compartidos por los nodos del clúster ........................................................21 Tabla 3: Direccionamiento IP del clúster .................................................................................................21 Tabla 4: los grupos de servicios del ZenOSS Core ................................................................................22 Tabla 5: Dependencias de arranque de los procesos .............................................................................23 Tabla 6: Dependencias funcionales entre los procesos ..........................................................................23 Tabla 7: dependencias Failover entre los procesos ................................................................................24 Tabla 8: Software requerido para el backend .........................................................................................24 Tabla 9: ZenPacks instalados .................................................................................................................25 Tabla 10: Software requerido para la gestión del Clúster .......................................................................25 Tabla 11: Las DeviceClass estándar según el tipo de acceso ................................................................31 Tabla 12: Ejemplos de asignación de plantillas de monitorización según el tipo de dispositivo..............32 Tabla 13: Monitorización estándar de la CPU mediante SNMP ..............................................................33 Tabla 14: Monitorización estándar de la CPU mediante SNMP para Windows ......................................34 Tabla 15: Ejemplos de definición de alertas de superación del umbral de CPU .....................................34 Tabla 16: Ejemplo de definición de gráficas y umbrales .........................................................................34 Tabla 17: Comandos SSH para la monitorización de CPU .....................................................................36 Tabla 18: Umbrales de CPU establecidos por defecto para la generación de alarmas ..........................36 Tabla 19: Definición de gráficas y umbrales para la monitorización de CPU ..........................................36 Tabla 20: Monitorización estándar de la CPU mediante WinRM para equipos Windows .......................37 Tabla 21: Umbrales del uso de la CPU establecidos para la generación de alarmas .............................37 Tabla 22: OIDs utilizados para la monitorización de la memoria de los equipos Linux, Solaris y HP-UX ................................................................................................................................................................38 Tabla 23: Monitorización estándar de la CPU mediante SNMP para equipos Windows .........................38 Tabla 24: Umbrales del uso de la Memoria configurados para la generación de alertas ........................39 Tabla 25: Definición de algunos gráficos de la monitorización de la memoria ........................................39 Tabla 26: Comandos SSH para la monitorización de Memoria...............................................................40 Tabla 27: Umbrales del uso de la Memoria para la monitorización por SSH ..........................................41 Tabla 28: Definición de algunos gráficos de la monitorización de la memoria mediante SSH ................41 Tabla 29: Definición de los data sources para la monitorización de la memoria mediante WinRM ........42 Tabla 30: Umbrales de memoria para generación de alertas de equipos Windows ...............................42 Tabla 31: Definicion de graficos para monitorización de memoria de equipos Windows ........................42 Tabla 32: Plugins para el descubrimiento de la componente de FileSystem mediante SNMP ...............43 Tabla 33: Los Oids utilizadas para la monitorización de los fileSystem ..................................................43 Tabla 34: Umbrales para generación de alertas de FileSystem..............................................................44 Tabla 35: Plugins utilizados para el descubrimiento de la componente de FileSystem mediante SSH ..45 Tabla 36: Los data source necesarios para la monitorización de FileSystem mediante SSH .................45 Tabla 37: Los data source necesarios para la monitorización de FileSystem de equipos Windows .......46 Tabla 38: Umbrales para generación de alertas de FileSystem para dispositivos Windows...................46 Tabla 39: Los plugins para el descubrimiento de los procesos ...............................................................48 Tabla 40: OIDs necesarios para la monitorización de los procesos mediante SNMP .............................48 Tabla 41: Umbrales configurados para la generación de alertas de procesos........................................48 ix.

(14) Tabla 42: Los comandos necesarios para monitorizar los procesos vía SSH ........................................ 49 Tabla 43: Los umbrales para generación de alamas de procesos monitorizados por SSH ................... 50 Tabla 44: Los comandos WMI necesarios para monitorizar los procesos vía WinRM ........................... 50 Tabla 45: Los data sources definidos para monitorizar procesos en equipos Windows......................... 51 Tabla 46: Los umbrales para generación de alamas de procesos monitorizados por WinRM ............... 51 Tabla 47: El mapeo de severidad entre LogWatcher y ZenOSS ............................................................ 54 Tabla 48: Pruebas realizadas................................................................................................................. 55 Tabla 49: Presupuesto del desarrollo del proyecto ................................................................................ 81 Tabla 50: Presupuesto equipamiento ..................................................................................................... 81 Tabla 51: Presupuesto total del proyecto ............................................................................................... 81. x.

(15) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 1 Introducción y objetivos 1.1 Motivación Hay muchas razones por las que podemos querer monitorizar nuestras infraestructuras IT, pero la más común es la necesidad de saber cuándo algo está fallando. Para cubrir dicha necesidad surgen los sistemas de monitorización, una herramienta de monitorización no solo nos ayudaría a encontrar fallos sino nos serviría además para poder predecir posibles situaciones y actuar en consecuencia para evitarlas. En general un sistema de monitorización es un sistema que busca constantemente fallos o problemas tanto hardware como software dentro de una red, permitiendo así a los administradores tener siempre el control de qué está pasando en la red que administran y detectar los problemas que surgen en cada momento antes de que los usuarios de la misma los perciban. Los avisos a los administradores deben ser fiables ya que si se reportaran falsas alarmas el sistema perdería credibilidad. Además es necesario que el modo de envío de las notificaciones de un sistema de monitorización tenga múltiples opciones de envío para asegurar que el mensaje de fallo en un sistema llegue a la persona adecuada [1].. 1.2 Objetivos La idea de este proyecto surge en la empresa en la que he realizado mi beca, en el área de consultoría de Telecomunicaciones, y más concretamente en el departamento de OSS (Operations Support Systems), donde las tareas principales son diseñar, integrar e implantar las herramientas de gestión y monitorización de red, principalmente en proyectos de operadoras de comunicaciones. Los principales objetivos del proyecto son:  . . . Documentar de manera comparativa las características de las herramientas OpenSource más importantes de monitorización de sistemas y red existentes en la actualidad. Implementar una solución que permita a las empresas controlar sus recursos informáticos dando la posibilidad de notificar vía SMS y e-mail las incidencias e incluso solucionarlas de manera automática. Desarrollar un sistema que permita controlar desde un entorno Web y de manera visual el estado de los equipos y servicios configurados, realizar tareas relacionadas con los mismos, como la generación de informes y deshabilitar monitorizaciones y alertas. Diseñar una solución de monitorización capaz de ofrecer un servicio de alta disponibilidad que permita la monitorización tanto activa como reactiva de una manera no intrusiva, es decir, sin la necesidad de la instalación de agentes en los sistemas a monitorizar.. 1.

(16) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 1.3 Estructura del resto de la memoria La estructura de la memoria será la siguiente: Primero, se presenta el marco tecnológico del proyecto en el que se hace una comparación de las herramientas de monitorización de redes y servicios más utilizadas además de exponer las tecnologías implicadas en el desarrollo del proyecto. A continuación, se muestran los objetivos generales y específicos que se pretenden alcanzar con el sistema propuesto. Le sigue el capítulo en el que se analiza con detalle el desarrollo y el funcionamiento completo del proyecto. También se incluyen los resultados de las pruebas que se realizaron un entorno de preproducción. Para finalizar con las conclusiones y futuras líneas de trabajo e investigación.. 2.

(17) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 2 Marco tecnológico del proyecto 2.1 Herramientas de monitorización OpenSource El principal objetivo de una herramienta de monitorización es la prevención de incidencias y controlar los recursos informáticos disponibles. Se encargan de notificarnos de los fallos que surgen en la red, o incluso, solucionarlos de forma automática cuando se produzca un fallo conocido mediante la ejecución de alguna acción programada. En esta sección hacemos un estudio comparativo de las herramientas de monitorización más comunes en el área de monitorización de redes y servicios. Solo se estudian herramientas openSource con licencias que permiten la distribución gratuita del producto, ya que se busca una solución de monitorización de coste bajo. 2.1.1. Osmius. Osmius es una herramienta de monitorización openSource desarrollada por la empresa PeopleWare. Permite monitorizar en tiempo real el estado de cualquier elemento conectado a nuestra red (Servidores, Routers, etc…), está basada en el Framework C++, dispone de funcionalidades tales como el autodescubrimiento de los equipos conectados a la red, la capacidad de desarrollar plugins en diferentes lenguajes, predicción de fallos y Business Intelligence [2].. Ilustración 1: Arquitectura de Osmius [3]. Como se puede observar en la Ilustración 1, Osmius utiliza una arquitectura basada en agentes para tener la capacidad de adaptarse a cualquier entorno a monitorizar. Está compuesto por un servidor central (CS), los agentes maestros (MA) y los agentes (AG). Estos agentes son los encargados de supervisar el estado de nuestra red y del tratamiento de los eventos mediante la ejecución de las acciones necesarias dependiendo de la instancia a monitorizar, también son los que envían los eventos a la consola de eventos para que podamos consultar y gestionar de forma centralizada. Algunas de sus características son [4]: 3.

(18) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento.  .  . Un sistema Multiplataforma (Windows, Linux, Solaris, HP-UX) es decir no está atado a ningún sistema operativo ni hardware. Una herramienta de monitorización que implemente un sistema de notificación flexible (en forma de email, SMS, tweets), también permite integrar las notificaciones con software de terceros (Remedy, JIRA...). Capacidad de gestionar de 60.000 de eventos por minuto Un sistema con una base de datos MySQL donde se almacena toda la información generada durante su funcionamiento.. Agentes Maestros (MA): es un módulo sofware que se instala en un host remoto y que actúa como un satélite del servidor central de Osmius, con el objetivo de poder gestionar y monitorizar instancias desde un host remoto. Agentes (AG): son módulos software ejecutados siempre en la misma máquina que el Agente maestro, se encargan de enviar todos los eventos obtenidos por cada uno de ellos al agente maestro que por su parte los reenvía al Servidor Central. Por cada instancia a monitorizar tiene un agente que lo supervisa.. 2.1.2. Nagios Core. Nagios es la herramienta de monitorización de red y servicios más utilizada, creada por Ethan Galstad, escrita en lenguaje C y publicada bajo la GNU General Public License. Se encarga de supervisar constantemente equipos, servicios y cualquier elemento de nuestra red que especifiquemos avisándonos cuando aparecen los problemas y cuando se solucionan. Es un software que ofrece una gran capacidad para consultar prácticamente cualquier parámetro de interés de un sistema, y enviar notificaciones vía E-mail o SMS cuando alguno de estos parámetros excede de los umbrales configurados por el personal responsable. Las características más destacadas de Nagios son [5]:   .  . 4. Monitorización de recursos hardware: uso del CPU, espacio libre en filesystems, uso de memoria, etc… Capacidad de chequear el estado de los servicios de red: SNMP, POP3, HTTP, SSH, DNS, etc. Capacidad de desarrollar plugins o complementos que permiten a los usuarios programar chequeos personalizados. Esos plugins no están limitados a ningún lenguaje de programación específico (normalmente Perl o Shell). Capacidad de crear una topología o jerarquía de red que nos permita separar los servicios caídos de los inalcanzables. Capacidad de monitorizar de forma pasiva el estado de los equipos y servicios mediante el NSCA (Nagios Service Check Acceptor)..

(19) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 2.1.3. ZenOSS Core. Otra herramienta de monitorización de red y servicios OpenSource es ZenOSS Core. El desarrollo de ZenOSS comenzó en 2005 por Erik Dahl y Bill Karpovich, los cuales formaron la compañía ZenOSS, Inc. Es un producto licenciado bajo la GNU General Public License Version 2.0 y publicada por la Free Software Fundation. ZenOSS, Inc ofrece dos versiones comerciales, basados en la versión OpenSource (ZenOSS Core), llamados ZenOSS Service Dynamics Enterprise y ZenOSS Profesional que disponen de funcionalidades adicionales (por ejemplo: umbrales de predicción de datos) y proporcionan soporte y mantenimiento. ZenOSS Core es una plataforma de código abierto para la gestión y monitorización de infraestructuras IT (Infrastructure Technology) basada en servidor de aplicaciones Zope que puede gestionar inventario/configuración, disponibilidad, rendimiento de dispositivos. Además, permite la monitorización de los servicios en la red, recursos hardware (CPU, memoria, fileSystems…), también descubre automáticamente nuevos elementos a monitorizar en la red, cambios en la configuración y dispone de un sistema de notificación de eventos basado en un conjunto de reglas [6]. ZenOSS, Inc posee una comunidad llamada Zenoss Core Comunnity la cual dispone de un repositorio de plugins desarrollados en lenguaje Python llamados ZenPacks, con los cuales los miembros de la comunidad pueden extender las funcionalidades de ZenOSS Core.. 2.1.4. Zabbix. Zabbix es un sistema de código abierto para la monitorización de red creado por Alexei Vladishev, licenciado bajo la GNU General Public License Version 2 y publicado por Free Software Fundation. Zabbix ha sido diseñado para vigilar y seguir el estado de varios servicios de red, servidores y otros equipos de la red. Permite un control centralizado, capacidad de gestionar hasta 1000 dispositivos, utiliza MySQL, PostgreSQL, SQLite u Oracle para almacenar datos [7]. Algunas de sus características son [8]:    . Cuenta con un front-end, en código PHP, que proporciona diferentes formas de visualizar los datos recogidos (Gráficos, alertas, listas de problemas...). Incluye un back-end que cuenta con una base de datos que almacena y facilita los datos a la interfaz web (front-end). Detecta de forma automática nuevos de dispositivos y servicios a monitorizar. Es un software multiplataforma, disponible para Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X. 5.

(20) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 2.1.5. Herramienta seleccionada. Las herramientas de monitorización que hemos evaluado anteriormente, cumplen ampliamente las necesidades que puedan surgir en cualquier red informática a monitorizar, por lo tanto para seleccionar una de ellas, se decidió tomar la decisión desde otro punto de vista, como valorar aquella que se adapte de la forma más óptima posible, a los recursos disponibles en nuestra empresa, en la que finalmente será desarrollada y objeto de este PFG. Una vez se ha realizado la comparativa con las principales herramientas de monitorización de red y servicios, debemos optar por una de ellas. La elección final en nuestro caso es ZenOSS Core. La ventaja que ofrece ZenOSS Core frente a las demás herramientas de monitorización, se demuestra en la potencia de sus módulos, la escalabilidad y personalización que nos permite, el soporte ofrecido por parte de los propios usuarios y por el grado de usabilidad que demuestra frente a otras aplicaciones similares. Es muy configurable, y está implementada para realizar una eficiente administración centralizada, de todos los módulos que la componen. ZenOSS Core ofrece además la posibilidad de identificar a cada uno de los equipos, recursos y dispositivos tecnológicos que forman nuestra red, así como datos de ubicación, hora de conexión, etc… Otra característica destacada de ZenOSS Core es la integración con Google Maps, que permite a los usuarios representar gráficamente la localización de los equipos en las diferentes zonas geográficas definidas por el administrador [9]. Otro punto importante que se ha tenido en cuenta es el lenguaje de programación Python ya que la empresa Satec S.A posee de programadores con muchos conocimientos en ese lenguaje, que nos permite desarrollar nuevos plugins y chequeos.. 2.2 Sistemas en Clúster El término clúster se aplica a un grupo de computadoras independientes interconectadas entre sí, de tal modo que funcionan como si fuesen una única computadora. Tipos del clúster [10]: . . . . 6. Alto rendimiento: clúster utilizado en aplicaciones que ejecutan tareas que requieren una gran capacidad computacional. El objetivo es evitar la compra de computadoras de alto coste. Alta disponibilidad: clúster que se caracteriza por mantener en todo momento la prestación del servicio, independientemente de si ocurre algún tipo de fallo en el sistema. Activo-Pasivo: cluster en el que solamente hay un nodo que da servicio, mientras el resto están inactivos. En el caso de que el nodo activo falle, otro nodo del cluster se hará cargo del servicio. En la Ilustración 2 se muestra un esquema de este tipo de clúster. Balanceo de carga: clúster que permite repartir de forma equitativa la carga del sistema entre sus servidores evitando así la sobrecarga de dicho sistema..

(21) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Ilustración 2: Ejemplo de diseño básico de un clúster Activo-Pasivo. 2.3 Otros protocolos y tecnologías utilizadas en el proyecto 2.3.1. SSH. Secure SHell es un protocolo que permite a los usuarios conectarse a un host remoto mediante la implementación de conexiones seguras entre dos máquinas utilizando una arquitectura cliente/servidor. Usando SSH, el cliente inicia una conexión TCP sobre el puerto 22 con la el servidor mediante una sesión cifrada, impidiendo así que alguien pueda obtener la contraseña o cualquier otra información que se intercambia por la red [11]. Algunas de sus características: .   . . 2.3.2. El cliente puede verificar que se está conectando al mismo servidor durante posteriores sesiones, una vez se haya realizado una primera conexión a un servidor. El protocolo SSH utiliza el Secure Socket Layer (SSL), que contiene librerías criptográficas para cifrar las comunicaciones. El cliente cifra la información de autenticación (nombre de usuario y contraseña) antes de enviarla al servidor. Los datos intercambiados entre el cliente y el servidor durante la conexión se transfieren por medio de algoritmos de encriptación de 128bits, lo cual los hacen muy difícil de descifrar y leer por terceros. El protocolo SSH se usa como medio para hacer seguros aquellos protocolos inseguros mediante el uso de una técnica denominada reenvío por puerto.. SNMP. Para el proceso de monitorización de los equipos, se utiliza el protocolo SNMP (Simple Network Management Protocol) en nuestra solución usamos SNMPv2 para obtener la información necesaria [12]. SNMP es un protocolo de la capa de aplicación para la gestión de dispositivos de red que funciona sobre redes TCP/IP. Los dispositivos que normalmente son compatibles con SNMP son Routers, switches, servidores, etc. 7.

(22) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Los componentes básicos de SNMP son [13]: Gestor SNMP: Un gestor o sistema de gestión es una entidad independiente que es responsable de comunicarse con el agente SNMP instalado en los dispositivos de red. Agente SNMP: Es un programa instalado dentro del elemento de red que permite recopilar la base de datos de información de administración desde el dispositivo localmente y lo pone a disposición del Gestor SNMP cuando se lo solicita. Estos agentes pueden ser estándar (por ejemplo, Net-SNMP) o específicos de un proveedor (por ejemplo, HP Insight Agent) MIB (Management Information Base): Contiene la estructura de los datos SNMP que se pueden gestionar en un determinado sistema. Cada dato tiene una representación numérica u OID (identificador de objeto) en la MIB del dispositivo. Las versiones de SNMP más utilizadas son: SNMPv1 y SNMPv2, ambas versiones tienen las mismas características, pero SNMP V2 incluye nuevas operaciones y nuevos tipos de datos; otra versión es SNMP V3 que ofrece nuevas funcionalidades respecto a las otras versiones anteriores como control de acceso y autenticación, sin embargo no ha sido mayoritariamente aceptado en la industria. Los comandos snmp usados más frecuentemente son: snmpget: Se usa para obtener un valor concreto de la Mib. snmpwalk: Se usa para obtener un grupo de valores de la Mib. snmptable: Tiene la misma función que el comando snmpwalk, se diferencian en la forma de representar los valores obtenidos. 2.3.3. WinRM. WinRM (Windows Remote Management) es un protocolo estándar basado en SOAP (Simple Object Access Protocol) sobre HTTP y HTTPS y por lo tanto es considerado un protocolo compatible con los firewalls. Es utilizado para la administración de equipos Windows y la ejecución de procesos en remoto través del puerto 80 (http) o el puerto 443 (https) en una red TCP/IP. WinRM ofrece una CLI (interfaz de línea de comandos) que permite realizar tareas de gestión y administración comunes. Además, provee una API (Librerías) para scripting de modo que se pueden programar scripts personalizados basados en Windows Scripting Host para obtener los datos [14].. 2.3.4. RRDTool. RRDTool (Round Robin Database Tool) es una herramienta de código abierto creada por Tobias Oetiker desarrollada en PHP, construida sobre una base de datos que maneja planificación según Round-Robin. Es un software de alto rendimiento utilizado para el almacenamiento de datos tales como tráfico de red, Cpu, memoria, etc.) y mostrarlos en forma 8.

(23) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. de gráficas en distintos intervalos de tiempo. Los datos se almacenan de manera compacta en una base de datos que no crece con el tiempo [15]. 2.3.5. Lucene. Lucene es una API Opensource implementada en java, distribuida bajo la licencia de Apache Software License, que permite agregar capacidades de indexación y búsqueda de información textual dentro de aplicaciones Java, C++, Python, .NET, etc... Lucene crea bases de datos textuales, lo que permite a los usuarios realizar búsquedas de texto completo dentro de documentos de cualquier formato. Esto hace que Lucene sea una gran utilidad para cualquier aplicación que requiere esta característica, sobre todo en aplicaciones multiplataforma [16].. 9.

(24)

(25) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 3 Especificaciones y restricciones de diseño 3.1 Restricciones provenientes de la herramienta de monitorización Las restricciones del modelo de monitorización ZenOSS, como en la mayoría de sistemas de monitorización de estas características, dependen en gran medida de las capacidades hardware del sistema (CPU, Memoria). Número máximo de nodos:. El número máximo de nodos que se podrán dar de alta en ZenOSS va a depender no sólo del HW, sino también del número de operaciones I/O que se realicen, es decir, del número de pollings (ICMP, SNMP, WMI) y lo pesadas que sean esas consultas. Una consulta SNMP penaliza más el rendimiento que una ICMP. (Polling hace referencia a un sondeo que realiza un servidor para comprobar el estado de cada equipo en una red). Se estima que el número máximo de nodos que se pueden tener dados de alta en un sistema ZenOSS con un único colector está entre 1000-1500 nodos, con una media de 100 pollings por nodo en ciclos de 300 segundos [17]. Número máximo de alertas activas:. El número máximo de alertas activas que pueda gestionar ZenOSS depende del tamaño de la base de datos zenoss_zep en la que se almacenan los eventos. Cuanto mayor sea el tamaño de base de datos, mayor es el número de eventos que ZenOSS pueda almacenar. Por defecto, ZenOSS borra los eventos en estado archivado cada 90 días. El tamaño mínimo que se recomienda que tenga la base de datos para que el rendimiento no se vea penalizado es de 50GB [18]. Número máximo de eventos por segundo:. El número máximo de eventos viene determinado por la capacidad que tienen las colas a través de las cuales se gestionan. RabbitMQ (el sistema de distribución de eventos que se utiliza en ZenOSS para que los diferentes procesos se comuniquen entre sí) no tiene definido un número máximo de mensajes que pueda gestionar por cada cola. Este número varía dependiendo de la memoria RAM disponible.. 3.2 Requisitos de equipos y comunicaciones para realizar la monitorización A continuación, se van a definir los requisitos que deben cumplir los equipos que conforman las plataformas de Servicio, OSS y gestores de elementos de red del cliente, así como los requisitos de las comunicaciones.. 11.

(26) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Los requisitos para poder realizar la monitorización de los sistemas del cliente mediante ZenOSS Core son de dos tipos. Por un lado, es necesaria una serie de requisitos de comunicaciones, además de unos requisitos de configuración y acceso en los equipos a monitorizar. Estos requisitos dependen del modelo de monitorización que se utilice: SSH, SNMP, WINRM o monitorización de logs. A continuación, se detallan los requisitos para cada uno de los modos de monitorización. 3.2.1. Requisitos de los equipos monitorizados:. Los requisitos de acceso y configuración para la monitorización por SSH son: . Usuario de sistema operativo con la conectividad SSH activada. Las credenciales de acceso SSH de este usuario se utilizan para realizar la monitorización de los servidores desde ZenOSS.. . El usuario debe permitir la conexión por SSH desde el exterior y debe tener una password válida y en uso.. . El usuario debe tener su propio directorio de HOME y debe poder ejecutar su propia instancia de cron.. Los requisitos de acceso y configuración para la monitorización por SNMP son: . Poseer de un usuario de sistema operativo con la conectividad SNMP activada. La comunidad de acceso SNMP de este usuario se utiliza para realizar la monitorización de los servidores desde ZenOSS.. . Permitir la conexión por SNMP desde el exterior.. . Tener instalado el agente NET-SNMP en los sistemas a monitorizar.. . Configurar el agente Net-SNMP. para que pueda responder a las MIBS: HOSTRESOURCES-MIB [19] y UCD-SNMP-MIB [20].. . Configurar una comunidad de acceso SNMPv2c sólo lectura con permisos a las vistas de las MIB’s: MIB-II, HOST-RESOURCES-MIB, UCD-SNMP-MIB, IFMIB. . Habilitar también las consultas desde la IP virtual asociada a los colectores de ZenOSS. Las credenciales de acceso (comunidad SNMP) se utilizan para realizar la monitorización desde ZenOSS.. Los requisitos de acceso y configuración para la monitorización de los logs son:. 3.2.2. . Permisos de instalación y ejecución de un paquete software logwatcher en los servidores.. . Permisos de lectura para la ruta donde se almacenen los logs. Requisitos de comunicaciones:. El modelo de comunicaciones internas de ZenOSS se define en la ilustración 3. 12.

(27) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Ilustración 3: Modelo de Comunicaciones de monitorización. En la tabla 1 se detallan las comunicaciones definidas para la monitorización tanto activa como reactiva de los dispositivos monitorizados. Tabla 1: las comunicaciones necesarias para la monitorización activa y reactiva Servicio. Proceso. Puerto. Protocolo. Dirección. apache. apache. 443 (HTTPSSL). TCP. IN. TCP. IN. TCP. OUT. dispositivos monitorizados. OUT. dispositivos monitorizados. OUT. dispositivos monitorizados. OUT. dispositivos monitorizados. TCP. OUT. dispositivos monitorizados. TCP. OUT. dispositivos monitorizados. UDP. IN. dispositivos monitorizados. 80 (HTTP) Monitorización Activa SSH. zencommand. Descubrimiento y modelado SSH. zenmodeler. Monitorización Activa SNMP. Zenprocess. Descubrimiento y modelado SNMP Monitorización activa WINRM. Descubrimiento y modelado WINRM. Monitorización Reactiva. Zenperfsnmp. 22 (SSH). 22 (SSH). 161 (SNMP). zenmodeler. 161 (SNMP). zenpython. 5985 (HTTP) 5986 (HTTPS). zenpython. zensyslog. UDP UDP ICMP. 5985 (HTTP) 5986 (HTTPS). Zentrap. TCP ICMP. 514 (Syslog), 162 (SNMP). Origen | Destino. Red Usuarios. 13.

(28)

(29) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 4 Descripción de la solución propuesta La solución de monitorización propuesta se basa en la utilización de la herramienta opensource ZenOSS como motor de la monitorización. ZenOSS permite la monitorización tanto activa como reactiva o pasiva de una manera no intrusiva, es decir, sin necesidad de instalación de agentes en los sistemas a monitorizar. Una vez que se descubre la infraestructura, comienza a monitorizar el rendimiento de cada dispositivo. Posteriormente, ofrece la gestión de eventos, automatización de alarmas e informes. Para la monitorización activa no intrusiva de las plataformas de Servicio, OSS (Operations Systems Support) y gestores de elementos de red se utiliza como protocolo estándar el protocolo SNMP, salvo en aquellos casos en los que no sea posible o cuando un agente SNMP no devuelve una información crítica sobre alguna pieza específica, se utiliza SSH como método de monitorización en equipos UNIX y WINRM en equipos Windows. En los sistemas Windows se utiliza WINRM, que es un protocolo basado en SOAP capaz de ejecutar, estableciendo una conexión HTTP o HTTPS, comandos PowerShell y WMI para obtener información de los sistemas. En aquellos sistemas Windows que lo soporten se utiliza WINRM como protocolo de consulta alternativo a SNMP. En cuanto a la monitorización reactiva se realiza mediante el envío de mensajes de Syslog y Traps SNMP a ZenOSS.. 4.1 Arquitectura En este apartado se describe de manera detallada la arquitectura lógica, arquitectura software y la de alta disponibilidad de la solución de monitorización de equipos y servicios que conforman cada una de las redes de los diferentes clientes. 4.1.1. Descripción de la arquitectura lógica de la herramienta de monitorización utilizada. ZenOSS Core posee una arquitectura distribuida y modular en diferentes capas funcionales que se muestran en la ilustración 4. Dichas capas son: capa de presentación, capa de agregación, consolidación y negocio, y capa de recolección.. 15.

(30) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Ilustración 4: Diseño lógico por capas. Capa de presentación: La capa de presentación consiste en una interfaz web que permite al usuario tanto realizar la operación como la administración centralizada de la herramienta. Esta capa está formada por Zope, un servidor web opensource basado en python y orientado a objetos. Aunque Zope se puede utilizar directamente como frontal web el presente diseño propone utilizar un servidor web apache que funcionara en modo proxy del servidor web Zope para permitir a los usuarios tanto el acceso HTTP (en el puerto por defecto 80) como HTTPS (en el puerto por defecto 443) sin que el proceso Zope necesite ejecutarse con privilegios de root. Zope: Aplicación web orientada a objetos. Está escrita en el lenguaje de programación Python. Es utilizado para la edición de contenidos, personalizaciones básicas y aporta ventajas respecto a lugares web compuestos por archivos de texto plano.. 16.

(31) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Capa de consolidación y negocio: Esta capa se muestra gráficamente en la ilustración 5.. Ilustración 5: Diseño lógico de la base de datos. Las bases de datos utilizadas por esta capa son: o ZODB (Zope Object DataBase): Es la base de datos del servidor de aplicaciones Zope que contiene, además de la configuración del servidor web, la CMDB (configuration Management Database) completa del sistema monitorización utilizada no sólo por el servidor web. o ZODB_session: Base de datos donde se persisten las preferencias de las sesiones de usuario del servidor web Zope. o Zenoss_zep: Base de datos de eventos del sistema. En esta capa se agrupan también los procesos principales de ZenOSS que intervienen en el tratamiento de los eventos recolectados por la capa de recolección (zenHub, zenEventd, zenEventServer y zenActiond) . ZenHub, es el nexo de unión de los diferentes colectores que conforman la herramienta con los procesos de backend. Se encarga como tarea principal de recoger todos los eventos que los colectores producen y de proporcionarles la información de configuración (acceso a la ZODB).. . ZenEventd, se encarga de realizar la clasificación, enriquecimiento y tratamiento de los eventos (trasformaciones), los datos de esos eventos son almacenados en una base de datos MySQL.. . ZenEventServer (ZEP), es un demonio en java, que se encarga del procesado final de los eventos para su almacenaje en la base de datos (zenoss_zep_event). Además realiza las correlaciones básicas de los eventos (correlación problema-solución y de duplicación), la generación de índices de búsqueda y proporciona al interfaz de usuario los servicios de acceso a la base de datos de eventos.. . ZenActiond, es el encargado de generar las notificaciones al exterior, estas notificaciones pueden ser emails, SMS, generación de traps, etc.. 17.

(32) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. ZenOSS se compone de una serie de servicios de backend que se encargan de la comunicación, almacenamiento, etc…, estos servicios son: rrdcache, MySQL, RabbitMQ y MemCache para agilizar el acceso a los datos. A continuación se detallan más en profundidad: . RRDCache, proceso que permite mejorar el rendimiento en el acceso a los ficheros de datos RRD.. . MySQL, incluye las bases de datos ZODB y ZODB_session que utiliza Zope y la base de datos zenoss_zep en la que se almacenan los eventos.. . RabbitMQ, es el sistema de distribución de eventos que se utiliza en ZenOSS para que los diferentes procesos se comuniquen entre sí.. . Memcache, es un servicio de backend que permite agilizar el acceso a la ZODB desde los distintos procesos de ZenOSS.. . ZenJobs, es el encargado de planificar la ejecución de las tareas internas de mantenimiento.. . RRD Files, La información de rendimiento recolectada por la capa de recolección se almacena en ficheros RRD (Round Robin database),. Capa de recolección: En esta capa se incluyen todos los procesos que intervienen en la monitorización, tanto activa como pasiva, así como los procesos de descubrimiento y modelado. ZenOSS tiene distintos procesos según el tipo de tarea que vayan a realizar: La monitorización reactiva se lleva a cabo a través de dos procesos: zensyslog y zentrap. Son los encargados de escuchar en los puertos 514 (syslog) y 162 (traps-snmp) y recolectar todos los mensajes que se reciban. El proceso zenModeler se encarga de realizar el descubrimiento de los dispositivos monitorizados e inventariar sus componentes (procesos, filesystems, interfaces, etc.). Este descubrimiento se puede realizar utilizando diferentes protocolos de acceso a los dispositivos, entre ellos SSH o SNMP. La monitorización activa se compone de varios procesos, cada uno de ellos con una tarea de consulta en los equipos específica según el tipo de consulta que se vaya a realizar.. 18. . zenStatus: Se encarga de la monitorización remota de puertos TCP/UDP en los elementos monitorizados.. . zenPing: Es el encargado de chequear de forma activa si un equipo o interfaz está disponible.. . zenProcess: Es el demonio que se utiliza para la monitorización de los procesos vía SNMP (uso del agente Net-SNMP).. . zenPerfSnmp: Es el demonio que recolecta vía SNMP los datos para las métricas de rendimiento, como CPU, Memoria, FileSystems, etc. para generar los gráficos de rendimiento..

(33) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. 4.1.2. . zenCommand: Permite ejecutar cualquier tipo de script o línea de comando por SSH en los equipos, así como recoger los datos de rendimiento que se utilicen para generar las gráficas.. . zenPython: Este demonio replica el funcionamiento del zenCommand sin la necesidad de tener que establecer una sesión Shell para obtener los datos, ejecutando código python. Según el tipo de consulta que se realice se utilizarán unos puertos u otros. Arquitectura en clúster para alta disponibilidad (HA). Una característica importante que debe ofrecer esta solución de monitorización es que se encuentre en alta disponibilidad, para ello se ha diseñado una arquitectura de ZenOSS en clúster de dos nodos en modo activo-pasivo con posibilidad de balanceo de carga, tal como se muestra en la ilustración 6.. Ilustración 6: Diseño global arquitectura HA. El clúster de la solución propuesta se compone de dos nodos trabajando en modo activo-pasivo, en el que se van a balancear los diferentes procesos de la solución teniendo en cuenta que la carga de cada uno de los nodos esté equilibrada. El clúster cuenta con almacenamiento compartido para poder realizar la conmutación de los procesos de back-end (bases de datos) entre los dos nodos. 19.

(34) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Los diferentes procesos de ZenOSS que se quieran balancear/conmutar dentro del clúster se definen en la fase de la configuración de los servicios del clúster. Cada servicio clúster está formado por un grupo de procesos y los recursos compartidos necesarios: almacenamiento externo e IP virtual del servicio. Cada uno de estos servicios tiene sus propios scripts de parada, arranque, chequeo de estado y procedimientos de failover y failback. Al existir servicios que no necesitan conexión con el exterior, y para no consumir direcciones IP de la red de gestión del cliente de manera innecesaria, se ha decidido utilizar dos tipos de redes: una red privada del clúster y una pública (que es la red de gestión del cliente). Por una parte la red privada se utiliza para la comunicación entre los dos nodos del clúster y es utilizada tanto para realizar el heartbeat (proceso necesario en la infraestructura clúster para el intercambio de información del estado de los procesos entre los nodos) como para las comunicaciones internas de los servicios balanceados entre ambos nodos. El conexionado físico entre ambos nodos del clúster es redundante (dos conexiones por cable cruzado) que se comporta como un único enlace lógico (configuración de interfaces bond) [22]. Por otra parte la red pública se utiliza para las comunicaciones de los servicios que requieren conexión con el exterior. Los procesos que requieren comunicación con el exterior son el frontal que da acceso a los usuarios a la herramienta, el servicio de notificaciones y los servicios de recolección de la monitorización activa y reactiva. 4.1.2.1. Almacenamiento compartido por los dos nodos del clúster:. En cuanto al almacenamiento, al usar un clúster se tienen que tener en cuenta los servicios que necesitan disponer de almacenamiento externo y que éste se pueda compartir entre ambos nodos. En nuestro caso esos servicios son las bases de datos MySQL, los ficheros de datos RRD (Round Robin Database) de rendimiento y los ficheros de indexación generados por el proceso zeneventserver (ZEP: ZenOSS Event Processor). ZEP usa un motor de indexación (Lucene) para facilitar el acceso desde la interfaz de usuario a los datos de los eventos y a la configuración, almacenados en zenoss_zep y zodb respectivamente. Estos índices se van a almacenar en el sistema de ficheros, y por lo tanto se tendrán que compartir entre los nodos del clúster. El acceso al almacenamiento compartido se va a realizar a través de conexiones de fibra a la cabina de almacenamiento externo utilizando para ello las tarjetas HBA (Host Bus Adapter) disponibles en los nodos. Se han utilizado tres puntos de montaje (LUN: Logical unit number): uno para almacenar los ficheros RRD’s que conforman los datos de rendimiento, otro punto de montaje para las bases de datos MySQL que ZenOSS utiliza y otro más para los índices de ZEP (Zenoss Event Processor). Para ello se han montado en uno de los nodos del clúster tres LUN’s independientes en la cabina de almacenamiento externo (se podría montar desde cualquiera de los nodos del clúster). Tanto la LUN asociada al MySQL como la asociada para los índices Lucene del ZEP no necesitan ser compartidas por más de un servicio del clúster. Cada una de ellas está asociada como recurso a un servicio del clúster diferente. 20.

(35) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Sin embargo, la LUN asociada a los ficheros RRD se ha montado directamente en cada nodo del clúster mediante la configuración fstab (file systems table). De esta manera se monta en el arranque de cada nodo y se excluye de la lógica del clúster. Cada punto de montaje tiene asignado su propio Filesystem. En la tabla 2 se especifica cada Filesystem con el tamaño inicial establecido, considerando la posibilidad de ampliar este tamaño si fuese necesario. Tabla 2: Puntos de montaje compartidos por los nodos del clúster FileSystem. Tamaño Estimado. Punto de montaje. /data/perf. 100 GB. Métricas RRD (NFS). /data/mysql. 200GB. Bases de Datos ZenOSS. /data/zepindex. 50GB. Índices ZEP. 4.1.2.2. Direccionamiento del clúster. En el clúster se han definido dos redes: una red pública del clúster que se corresponde con la red de gestión del cliente y una red privada para las comunicaciones internas del clúster. Los servicios que necesiten comunicarse con el exterior del clúster tienen direccionamiento virtual de la red pública del clúster y aquellos servicios que no necesiten comunicarse con el exterior del clúster (servicios de back-end) tienen direccionamiento virtual de la red privada del clúster tal como podemos ver en la tabla 3. Tabla 3: Direccionamiento IP del clúster Servidor Nodo 1. Nodo 2. Servicio. Tipo de Red. Dirección IP. ILO (Integrated Lights-Out). Pública. a.b.c.68. Gestión. Pública. a.b.c.67. Clúster (Interfaz de heartbeat). Privada. x.x.x.10. ILO. Pública. a.b.c.70. Gestión. Pública. a.b.c.69. Clúster (Interfaz de heartbeat). Privada. x.x.x.11.  Las direcciones IP de la ILO se utilizan para poder aprovechar el mecanismo de Fence Device, disponible en el software de clúster de RedHat, que permite aislar un nodo del almacenamiento compartido y evitar así las inconsistencias en los datos de almacenamiento compartido. De esta forma, si alguno de los nodos entra en estado de malfuncionamiento, el nodo que tome el control será capaz de asegurarse que el nodo problemático está apagado lanzando una señal a través de la ILO. De este modo se asegura que el almacenamiento compartido está asignado sólo al nodo activo.. 21.

(36) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento.  Las direcciones IP correspondientes a la gestión de los servidores son utilizadas para poder realizar la gestión remota por SSH de los nodos del clúster.  Las direcciones IP de los nodos en la red privada del clúster se utilizan para los procesos de heartbeat (proceso necesario en la infraestructura clúster para el intercambio de información del estado de los procesos entre los nodos) del clúster. En la tabla 4 se muestran los procesos de ZenOSS que se quieran balancear/conmutar dentro del clúster, con sus correspondientes puntos de montaje. Según el tipo del servicio se le asigna una dirección IP de la red pública del clúster (red de gestión del cliente) o una de la red privada al servicio: Tabla 4: los grupos de servicios del ZenOSS Core. 4.1.2.3. Servicio. Procesos del servicio/puntos de montaje. Red. zenfront. Httpd. Publica. zenactive. zenping, zenperfsnmp, zencommand, zenpython, zenprocess, zenstatus. Publica. zenreactive. syslog-ng, zensyslog_TCS, zensyslog_IUM, zensyslog_Logwatcher, zentrap. Publica. zennotif. Zenactiond. Publica. zencore. rabbitmq-server, memcached, mysql, zepindex, mysqld, zeneventserver, zenhub, zeneventd, zenjobs, zopectl, zredis y zenrrdcached. Privada. Dependencias entre los procesos del sistema. Se han identificado tres tipos de dependencias entre los procesos que componen el sistema ZenOSS; dependencias de arranque, dependencias funcionales y dependencias de failover. Estas dependencias serán cruciales a la hora de determinar la política de failover a seguir, así como el proceso de arranque y parada de los servicios. Dependencias de arranque: Las dependencias de arranque hacen referencia al orden que se debe seguir en el arranque de los procesos para que el sistema arranque correctamente. Estas dependencias no significan que los procesos no vayan a arrancar, sino que arrancarán, pero entrarán en estado de malfuncionamiento. El proceso zeneventserver es el que debe arrancar primero, seguido del zenhub. Una vez arrancado el zenhub, el resto de procesos se pueden arrancar en paralelo. La tabla 5 detalla las dependencias de arranque entre los procesos de ZenOSS que conforman el core del sistema:. 22.

(37) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento Tabla 5: Dependencias de arranque de los procesos Proceso. Depende de. zeneventserver (ZEP). memcached. mysql rabbitmq zenhub, zope, zeneventd. zeneventserver. zenactiond, zenping, zencommand, zenprocess, zenmodeler, zenperfsnmp, zenrdis. zenhub. rrdcache. nfs. Dependencias Funcionales: Estas dependencias implican que si alguno de los procesos de los que depende otro proceso falla, el proceso dependiente entrará en estado de malfuncionamiento. Las dependencias funcionales entre los distintos procesos que componen ZenOSS se especifican en la tabla 6 y la ilustración 7. Tabla 6: Dependencias funcionales entre los procesos Proceso. Depende de. ZenFront. zope. ZenCore. mysql, nfs, rabbitmq,. ZenNotif. rabbitmq, mysql, zenhub. ZenActive. zenhub, nfs. ZenReactive. N/A. Ilustración 7: Grafo de dependencias funcionales entre los procesos. 23.

(38) Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento. Dependencias Failover: Las dependencias de failover definen las dependencias existentes entre los servicios que componen ZenOSS a la hora de ser balanceados. Dos servicios dependientes se tendrán que balancear juntos, permaneciendo en todo momento en el mismo nodo del clúster. Las dependencias se describen en la tabla 7. Tabla 7: dependencias Failover entre los procesos Servicio. Depende de. ZenCore. Nfs, mysql. ZenActive. Nfs, rrdcache. 4.1.3. Arquitectura Software. 4.1.3.1. Software de Backend. Los paquetes software que conforman los servicios de backend (capa de acceso a datos) de la solución se instalan de acuerdo a las versiones mínimas compatibles con la ZenOSS Core 4.2.5 (ver tabla 8). Ambos nodos del clúster tienen instalados todos los paquetes para poder arrancar estos servicios de backend en cualquiera de los nodos. Tabla 8: Software requerido para el backend. 4.1.3.2. Paquete SW. Versión Mínima requerida por ZenOSS 4.2.5. mysql. 5.5.35 (ultima estable compatible). memcache. 1.4.5. rrdcache. 1.4.7. rabbitmq. 3.3.5 (última versión estable compatible). nfs. N/A. Software ZenOSS. El software OpenSource de ZenOSS está instalado por completo en ambos nodos. La versión de ZenOSS instalada es ZenOSS 4.2.5 build 2108, así como la última versión de parches (ZUP: ZenOSS Update Package) disponible. Además, se han instalado los siguientes ZenPacks de la Comunidad (ver tabla 9):. 24.