XIV Congreso Internacional de la Academia de Ciencias Administrativas A.C. (ACACIA) Capítulo 11. Ingeniería y Gestión de Sistemas

Transcripción

1 XIV Congreso Internacional de la Academia de Ciencias Administrativas A.C. (ACACIA) Capítulo 11. Ingeniería y Gestión de Sistemas Uso de herramientas de código abierto para administrar dispositivos de red: caso de una empresa de componentes de seguridad automotriz Martínez Cifuentes, Fernando Candidato a Maestro en Tecnologías de la Información y la Comunicación por la Universidad Autónoma de Baja California Valencia Moreno, José Manuel Facultad de Ciencias Administrativas y Sociales de la Universidad Autónoma de Baja California Profesor Investigador de tiempo completo, jova@uabc.mx Osorio Cayetano, Oscar Ricardo Facultad de Ciencias Administrativas y Sociales de la Universidad Autónoma de Baja California Profesor de tiempo completo, oosorio@uabc.mx Universidad Autónoma de Baja California Facultad de Ciencias Administrativas y Sociales Blvd. de los Lagos y blvd. Zertuche S/N Fracc. Valle Dorado Ensenada, B. C Tel ext. 165 Del 27 al 30 de abril en la Escuela de Graduados en Administración y Dirección de Empresas (EGADE) del Tecnológico de Monterrey en Monterrey, N. L.

2 RESUMEN Las medianas y pequeñas empresas que cuentan con una red de computadoras propia, se enfrenta a la necesidad de su administración y mantenimiento. Sin embargo esto puede resultar costoso y una actividad difícil de lograr. Es decir, existe la necesidad de contar con un sistema que mantenga informado en tiempo real de los eventos que ocurren en cada uno de los dispositivos de red de datos, como son: congestión en red, presentación de colisiones, pérdida de enlaces, sobrecarga de CPU, saturación de memoria y errores en interfaces. El presente trabajo direcciona esta necesidad y propone un sistema de administración centralizada de dispositivos de red, a través del uso de herramientas de código abierto, trayendo consigo la ventaja principal, el costo. La propuesta se implementó en una empresa mediana orientada a la fabricación de componentes de seguridad automotriz. Palabras clave: Código abierto, monitoreo de red, pymes. 2

3 1. ANTECEDENTES La Empresa de Componentes de Seguridad Automotriz (ECSA), dedicada a la manufactura de bolsas de aire para automóviles, está abierta a las nuevas tecnologías que beneficien su proceso haciéndolo más eficiente. Fue fundada en el año 1991 en la ciudad de Ensenada, Baja California y forma parte de un corporativo a nivel mundial. Durante sus 18 años de operación ha usado las TIC para el óptimo funcionamiento de sus operaciones y ello ha contribuido a posicionarse como una de las grandes empresas en el ramo automotriz a nivel nacional. La demanda y dependencia de las TIC por parte de las organizaciones han dado pie a que surjan nuevas herramientas y mejores dispositivos que controlen el manejo de la red de datos, así mismo que puedan ser adaptados e implementados fácilmente en las organizaciones con el propósito de mantener una comunicación integra y confiable de tal forma que no se vea interrumpido el flujo de la información en los procesos de la misma. Sin embargo, la falta de implementación de nuevas herramientas de administración de dispositivos, ya sea por el alto costo de algunos de ellos o su desconocimiento por parte de los administradores de red, se ven en la necesidad de utilizar múltiples programas que les sirven como apoyo para realizar sus actividades diarias de administración y control de la red. 2. PLANTEAMIENTO DEL PROBLEMA Dentro de la administración de las TIC es importante contar con herramientas que agilicen el tiempo de respuesta ante problemas o situaciones adversas, de tal forma que se pueda proporcionar una solución rápida y oportuna. 3

4 Con el paso del tiempo todo dispositivo electrónico se va deteriorando y consumiendo su periodo de vida, es por esto que se requiere contar con la información de eventos que se presenten en cada uno de los dispositivos de telecomunicación y redes de datos utilizados, tales como: routers, switchs y firewalls, con la finalidad de prevenir cualquier situación que afecte directamente la funcionalidad de la organización, ya que son relevantes para el buen desempeño de la red en la empresa. De igual forma, no se cuenta con la información que pueda ayudar de manera inmediata a identificar y solucionar fallas en los dispositivos. Fallas generadas por problemas de hardware tales como sobrecarga de CPU, saturación de memoria, errores en interfaces, entre otros. Si bien se conocen y manejan por separado cada uno de los dispositivos, no existe forma de realizar un monitoreo global de estos, haciendo más difícil su administración. La falta de herramientas de administración para la red en la empresa es el factor principal para que cualquier falla, no se identifique de forma inmediata y por consiguiente retrase su reparación. 3. OBJETIVO Realizar una investigación que permita proponer herramientas de código libre que ayuden en la administración centralizada de los dispositivos de red utilizados en ECSA, como son los routers, switchs y firewalls. 4. JUSTIFICACIÓN Entre los beneficios que se obtendrán al lograr una administración centralizada de eventos de los dispositivos de telecomunicación y redes de datos existentes, están la reducción significativa de tiempo en la identificación y solución de los problemas y la optimización de recursos de la empresa, ayudando a prevenir posibles fallas de 4

5 comunicación en la red de la organización, evitando que se vean afectados los intereses de las misma, a través de pérdidas de productividad y financieras. El uso de este sistema beneficiará principalmente a la empresa como tal. En el aspecto administrativo, la comunicación con los clientes es fundamental para el crecimiento de la misma organización, mejorará el nivel de productividad y eficiencia. También facilitará la administración para el encargado de la red, así como al personal de sistemas relacionados. Es importante mencionar que con el análisis de alternativas para la implementación de este sistema, se ayudará proponer una mejora en la administración de la red y se ahorrará costo en la prevención de fallas, al disminuir el tiempo de repuesta en la resolución de problemas de los dispositivos existentes. Para mayor claridad del impacto económico en una celda de trabajo de la empresa, que produce 2,500 piezas en 9 horas al día, donde cada producto tiene un valor de $1.15 de dólar, esto equivale a $2,875 dólares al día, lo dividimos entre 9 para determinar el costo de producción por hora, esto nos da un resultado de $ dólares que finalmente es lo que se pudiera estar dejando de ganar al momento de perder la comunicación con el sistema de captura o la falla de algún dispositivo de red de datos. La cifra anterior tiene que ser multiplicada por la cantidad de celdas que elaboran el mismo producto y que también sean afectadas por la falta de sistema de captura de producción en la misma nave o a nivel general. El precio del producto y la cantidad a producir son variables según al plan de producción programado del día. 5. MARCO REFERENCIAL Los adelantos de las tecnologías de administración de redes tanto en hardware como en software, han proporcionado a los administradores de redes un completo equipo de herramientas que facilitan la gestión, permitiéndoles actuar de manera rápida o de prevenir situación que afecten el desempeño de las mismas. 5

6 Cuando no se cuentan con herramientas de administración, se estará prácticamente en situación donde la solución a las fallas se tomarían largos periodos de tiempo, pérdida de dinero en el proceso o adquisición de equipo de reemplazo, así mismo podría afectar en un momento dado los intereses de la empresa en su conjunto e incluso el despido de el encargado de la red. Alfredo Campos señala que: Cuando sobreviene un problema en alguno de estos elementos, depende sobre todo del tamaño de la misma, el qué tan pronto puede detectarse, diagnosticarse y por supuesto resolverse. Para las redes pequeñas, la tarea es sencilla ya que incluso una revisión ocular de los elementos puede revelar al menos en qué dispositivo o sistema se presenta la falla, más no nos dirá con exactitud en dónde se localizan los problemas. En cuanto a las redes más grandes, el problema se complica sobre todo si el elemento que falla se encuentra lejos de las instalaciones de mantenimiento o que está en un sitio de difícil acceso. Para este caso, es indispensable saber a detalle cuál es el motivo de la falla para que la gente de campo pueda solucionar el problema. (Campos, 2007) 5.1. Marco histórico Este caso de estudio se realizará en la red de datos de ECSA la cual está compuesta por un total de 146 equipos de cómputo, 82 se encuentran en oficina, 49 en celdas de producción y 15 son para diversas actividades. Los elementos que componen la red son; 1 router, 1 firewall, 1 filtro de internet, 1 core switch y 6 switch ubicados en las diferentes oficina de la empresa. También se cuentas con 7 dispositivos de puntos de acceso para la distribución de la señal de red inalámbrica. El resto de dispositivos que se encuentran conectados a la red están compuestos por relojes digitales con timbres adheridos, checadores de huella digital, impresoras y cámaras de vigilancias. Todos estos dispositivos son administrables vía LAN. 6

7 Los programas principales utilizado son: correo electrónico y el sistema principal de captura de producción, en este sistema está integrado los módulos de control de materia prima y finanzas, sistema que se encuentra en una localidad de Atlanta Georgia, en Estados Unidos. El resto de las aplicaciones utilizadas se administran en forma local Esquema de administración Es importante primero definir un esquema de administración de los dispositivos que se requiere controlar (MacFaden, Partain, Saperia & Tackabury, 2003), esto es, aplicar a cada uno de ellos un nombre único identificador según sea su función, homogenizar las cuentas de acceso e incluso utilizar un mismo modelo de configuración en cada dispositivo. Para la identificación de los dispositivos de red datos en ECSA se consideraran los siguientes puntos: EN <Ensenada> Localidad. CC <Cisco Catalys> - Marca y modelo de dispositivo. SW <Switch>, RO<Router>, y FW<Firewall> - Funcionalidad de dispositivo Asignación de número identificador. Para poder recolectar la información de los dispositivos en red, es necesaria la configuración del protocolo de comunicación SNMP en cada unos de los equipos. Se activará una configuración básica, la cual consta de privilegios de lectura, escritura y configuración de IP o nombre del servidor en el cual estarán los sistemas de monitoreo que solicitaran la obtención de datos a cada dispositivo configurado en ellos, así como los encargados de envíos de alertas. También es necesario identificar qué equipo está conectado a qué puerto de cada uno de los switchs integrado en la red. Todo esto facilitará las tareas de administración al momento de que se presenten las fallas, así como en el momento en que se implemente el sistema de monitoreo. 7

8 5.3. Monitoreo requerido Enfocados en los dispositivos de red de datos, se requiere monitorear el desempeño como puede ser el uso del procesador, memoria, uso de cada una de las interfaces de comunicaciones (información transmitida, información recibida, estado de interface y errores o fallas), temperatura, voltaje interno y estado de abanicos. No todos los dispositivos son configurables a los elementos anteriormente mencionados, por tal motivo serán evaluados antes de su configuración en los sistemas de monitoreo. En este caso de estudio se configurará un solo dispositivo switch para realizar las evaluaciones correspondientes a los sistemas de monitoreo planteados en este documento Técnicas de monitoreo Una red de datos puede ser monitoreada según los parámetros definidos en cada unos de los dispositivos interconectados en la red local. Estas configuraciones pueden ser aplicadas de tal forma que alerte de inmediato de eventos de cada dispositivo, por ejemplo, el tiempo de inactividad o la limitación de recursos de la red con un evento concreto que se haya producido recientemente o eventos críticos en la red, ancho de banda utilizado y algún otro parámetro que sea de gran relevancia para el administrador de la red. El monitoreo se puede definir como la constante vigilancia de los dispositivo de red relevantes o críticos integrados a una infraestructura de red con el fin de tener el control y los elementos necesarios para actuar de manera anticipada a cualquier falla o evento. Se puede monitorear una red en forma activa donde los eventos son vistos por el administrador en tiempo real de tal manera que facilita la pronta atención del suceso. También la una red puede ser monitoreada en forma pasiva, donde las herramientas encargas de realizar esta actividad tienen como función principal la recolección y 8

9 almacenamiento de datos de los servicios o dispositivos que genera el evento. Esa información recolectada sirve como referencia, tendencia o historial para prevención de fallas que se pueda presentar a futuro o simplemente para implementar mejoras en la infraestructura de red Acerca del Protocolo SNMP El protocolo SNMP es definido en la RFC 1157 por la Fuerza de Trabajo en Ingeniería de Internet (IETF o Internet Engineering Task Force), clasificado en el nivel de aplicación del modelo TCP/IP. Está diseñado para facilitar el intercambio de información entre dispositivos de red y es ampliamente utilizado en la administración de redes para supervisar el desempeño y el estado de una red, equipo de cómputo y otros dispositivos. El protocolo SNMP es asíncrono de petición - respuesta basada en el modelo de interrupción y sondeo directo, esto es, que una entidad no necesita esperar una respuesta después de enviar un mensaje, por lo que puede enviar otros mensajes o realizar otras actividades. SNMP se basa en un conglomerado de agentes. Cada agente es un elemento de la red que ofrece unas determinadas variables al exterior, para ser leídas o modificadas. Asimismo, un agente puede enviar alertas a otros agentes para avisar de eventos que tengan lugar Sistemas de monitoreo de red de datos En la actualidad existen muchas herramientas de software para la gestión de redes que ayudan a los administradores a mantener la red funcionando eficazmente. Algunos sistemas tienen como función principal monitorear los eventos de ciertos dispositivos que soporten el protocolo SNMP. Las aplicaciones de monitoreo de dispositivos de red pueden ser de tipo comercial o de libre distribución. Las primeras por su alto costo de adquisición o renta, es difícil que las empresas realicen el gasto para su utilización. Entre las herramientas de monitoreo que podemos hacer mención están OpUtils, ManageEngine, Net Flow, HP 9

10 Open View, Cisco Works, ninbus de nimsoft, entre otros. El soporte con los que cuenta cada de una de estas aplicaciones hacen muy sencilla su implementación y manejo, lamentablemente los costos son muy elevados y para muchas empresas no es redituables. Como ejemplo una de las herramientas de monitoreo de dispositivos red de tipo comercial es OpUtils, un conjunto de más de 30 herramientas que ayudan a los administradores de red a monitorear, diagnosticar, detectar y resolver problemas de sus recursos de TIC (ManageEngine, 2010). En cuanto los costos se puede mencionar que van desde $ dlls la versión estandar para un usuario de red, hasta los $ 2, dlls por la versión profesional sin límite de usuarios. Este proyecto se enfocará al estudio y evaluación de dos herramientas de análisis y monitoreo que son de mayor utilización en la actualidad: Cacti y Nagios. Se van a identificar y analizar sus funcionalidades, determinar cuál es menos complejo en su configuración, menos robusto en su ejecución y más óptimo para ser implementado, y sobre todo, que cubra las necesidades requeridas en este caso de estudio Cacti Es una herramienta completa de graficado en red, diseñada para aprovechar el poder de almacenamiento y la funcionalidad de graficar que poseen las Round Robin Database tool (RRDtool) (Oetiker, 2009). En otros términos, es una aplicación que permite monitorear sistemas y servicios de una forma gráfica. Cacti está hecho totalmente en PHP y proporciona plantillas avanzadas de gráficos, múltiples métodos para la recopilación de datos y características de gestión para el usuario. Tiene una interfaz de usuario fácil de usar, que resulta conveniente para su instalación en redes pequeñas así como también para redes complejas con cientos de dispositivos. La funcionalidad de cacti está basada en la herramienta RRDTOOL la cual es del sector Open Source. Trabaja con una base de datos que utiliza la planificación Round-Robin. Esta técnica utiliza con una cantidad fija de datos que son definidos al 10

11 principio de su creación y un apuntador al elemento más reciente. Una base de datos usando round robin se estructura como si fuera un círculo con unos cuantos puntos dibujados alrededor del borde; estos puntos son los lugares donde se pueden guardar los datos. Cuando se lee o escribe el dato actualmente, el apuntador se mueve al próximo elemento. Como se esta trabajando en un círculo, no hay ni principio ni fin; siempre puedes seguir sobrescribiendo los datos almacenados. Al cabo de un tiempo ya se habrán usado todas las posiciones disponibles y el proceso empieza a reutilizar las antiguas. De esta forma, la base de datos no crece en tamaño y, por lo tanto, no requiere ningún mantenimiento. RRDtool trabaja con estas bases de datos en Round-robin, guardando y recuperando datos de ellas. Cacti funciona en conjunto con Apache, PHP4, MySQL, RRDTools y Net-SNMP. Estas aplicaciones son parte fundamental para el uso de cacti, es por eso que deberán ser instaladas y configuradas previamente. Un servidor Apache para la utilización de interface web para la gestión ente el usuario y la aplicación, el PHP servirá para la utilización de bibliotecas relacionadas con el programa cacti, así como el despliegue de contenido generado en la aplicación. El RRDtools va a ser utilizada para almacenar y procesar datos de dispositivos y servicios recolectados vía SNMP. Dentro de las principales características de Cacti (Cacti, 2009) están: La recopilación de datos mediante scripts o comandos. Por ejemplo, si se quisiera graficar los tiempos de ping de un host, se podría crear una fuente de datos, utilizando un script que haga ping a un host y devuelva el valor en milisegundos. Crea prácticamente cualquier gráfica, utilizando todos los estándares de tipos de gráficas de RRDtool y funciones de consolidación. Muestra la información en varios tipos de vistas: lista estándar, preliminar y en árbol. Manejo de usuarios con permisos. Utilización de plantillas para reutilizar las definiciones de gráficos, fuentes de datos y dispositivos. 11

12 Nagios Es un sistema de monitoreo de código abierto que puede supervisar en forma centralizada los recursos de redes tales como conmutadores, enrutadores, servidores, servicios y aplicaciones (Nagios, 2009). Tiene soporte para SNMP que permite revisar equipos y servicios que le son especificados, alertando cuando el comportamiento de estos no es el deseado. Está escrito en C y fue diseñado para ejecutarse en GNU/Linux y en varias distribuciones de Unix también. Está licenciando bajo la GNU General Public License versión 2 de la Free Software Foundation, se puede descargar y utilizar de forma gratuita. Nagios se compone de un demonio (servicio) dedicado para su ejecución, es el encargado de recoger, analizar y presentar los datos de los servicios o dispositivos. Nagios no se basa en el protocolo SNMP para su funcionalidad, si no en un conjunto de pequeños módulos llamados plugins especializados en diferentes servicios. Estos módulos tienen sus funciones específicas en la red de datos como la verificación de servicios de red como el DHCP, DNS, revisión de protocolos (HTTP, ICMP, etc.), performance de equipos, etc. Existen dos tipos de plugins, los locales que son aquéllos que se distribuyen en y para monitorear el propio servidor de Nagios y los remotos que son aquéllos que pueden estar disponibles en las estaciones remotas. Un plugin de conexión remota (NRPE) se utiliza para crear una conexión entre una estación de trabajo o servidor y el servidor dedicado Nagios. El servidor de Nagios se compone de unos ficheros de configuración en los que se especifican qué estaciones y servicio se van a estar monitoreadas y con qué periodicidad. Para su instalación y configuración, nagios requiere como primer punto una plataforma Linux y un compilador C previamente instalados, a su vez requiere un servidor web (apache), librerías gráficas GD, JPEG y PNG, el protocolo SNMP y por ultimo un manejador de base de datos como lo es el MySQL. 12

13 Características principales de Nagios: Monitorear servicios de red: correo (SMTP, POP3, IMAP), servidores WWW (HTTP), FTP, proxies, chequeo de puertos (TCP, UDP), tráfico de red (carga de las interfaces), bases de datos, etc. Monitorear recursos de los hosts (carga de procesador, uso de disco, memoria, verificación de logs, etc.) Monitoreo de parámetros físicos de dispositivos (temperatura, humedad, carga eléctrica). Diseño simple de plugins; elaboración personalizada según las necesidades especificas. Disponibilidad de una interfaz web para consulta del estado de los recursos y servidores. Sistema de notificaciones muy flexible; notificaciones a contactos cuando un servicio o host tenga problemas y puedan resolverlo ( , pager o definido por el usuario). 6. METODOLOGÍA Este caso práctico está basado en la investigación de aspectos teóricos que abarcarán los conceptos relacionados de los elementos necesarios para la clara explicación de los sistemas de monitoreo y su importancia en la actualidad. La segunda parte se enfocará a el aspecto práctico, es decir, consistirá en la configuración, manejo y análisis de la herramienta de monitoreo de red seleccionada. Se utilizará la entrevista, la información se obtendrá de la entrevista con el gerente de sistemas de ECSA, con el fin de conocer más a fondo sus necesidades como responsable de las tecnologías de la información. La mayoría de la información será obtenida en Internet, ya que es ahí donde se pueden encontrar más fácilmente temas relacionados con aplicaciones de monitoreo, procedimientos y técnicas que ayuden este proyecto. 13

14 La selección de software a utilizar, será en relación a los conocimientos previos que se tengan del manejo de los mismos por parte del desarrollador del proyecto. Se utilizarán las aplicaciones de monitoreo que más se apeguen a los requerimiento definidos en este documento. También se obtendrá información de manuales de referencia tanto de dispositivos de telecomunicación, aplicaciones de monitoreo y de la plataforma Linux a utilizar en el desarrollo de este proyecto. 7. DESARROLLO 7.1. Gestor de Red Simple Network Management Protocol (SNMP) Se puede ver como el medio estándar de monitorear hardware, ya que en la actualidad la mayoría de los equipos de cómputo o dispositivos de red proveen el servicio de SNMP con el fin de permitir que sus parámetros ya definidos puedan ser monitoreados. Además de los parámetros estándar que el protocolo provee para todos los sistemas, cada fabricante puede incorporar una serie de extensiones a este sistema y proporcionar los datos necesarios para que el sistema gestor SNMP pueda monitorear estos sistemas. Es muy común ver dispositivos que pueden proveer las llamadas traps, que son avisos que el hardware manda al sistema de monitoreo para notificar algún cambio en el hardware o error en el sistema, pasando así de un sistema principalmente pasivo como es el SNMP a un sistema activo que permite recibir avisos cuando es necesario. Los elementos básicos para el protocolo SNMP en una red son 1) los Administradores; que se encuentra ubicados en los equipos de gestión de red, y 2) los Gestores (Agentes de red); 3) elementos pasivos a ser gestionados, esto se encuentran en los host, router, switch, entro otros (Presuhn, Case, McCloghrie, Rose & Waldbusser, 2002A). Los Agentes de red son quienes les envían la información a los administradores, esto puede ser por iniciativa propia o apoyada por los parámetros contenidos en su Management Information Base (MIB). 14

15 Un Trap es un mensaje espontáneo enviado por el Agente al Administrador, al detectar una condición predeterminada, como es la conexión/desconexión de una estación o una alarma (Presuhn, Case, McCloghrie, Rose & Waldbusser, 2002B). MIB es una base de datos completa y bien definida, con una estructura en árbol, adecuada para manejar diversos grupos de objetos (información sobre variables/valores que se pueden adoptar), con identificadores exclusivos para cada objeto. A través del MIB se tiene acceso a la información para la gestión, contenida en la memoria interna del dispositivo en cuestión Recursos disponibles Se cuenta con un equipo de cómputo con las características necesarias para la instalación y ejecución de aplicaciones que se requieran para este proyecto, así mismo se tiene la autorización para el uso de un dispositivo de red (switch) que no está siendo utilizado para poder realizar las pruebas correspondientes sin afectar los dispositivos en funcionamiento. Las aplicaciones que se analizarán son de código libre y solo es necesario descargarlas desde sus sitios de Internet, por lo tanto para el desarrollo de este proyecto no será necesario hacer gastos económicos. El recurso humano, un desarrollador del proyecto será quien participante, no será necesaria la intervención de alguna otra persona Qué se desea monitorear en la red de datos? Los primeros elementos que se requieren monitorear son las conexiones remotas con otros sitios del corporativo donde se encuentran los sistemas principales de la empresa. Los enlaces tienen que estar activos las 24 horas y los 7 días a la semana. Se requiere detectar la caída del enlace en tiempo real para actuar de inmediato, así como llevar un control histórico de los eventos generados para posteriormente justificar algún proyecto de mejora o simplemente para la prevención de fallas de las mismas. Otro elemento considerado a ser monitoreado es la interconexión activa de todos los dispositivos switch integrados en la red. También es necesario saber el estado y 15

16 actividad que se generan en los puntos de acceso inalámbricos activos en la empresa, ya que gran parte de los equipos en el área de producción acceden a los servicios de red por ese medio.como algo adicional, ser requiere verificar el estado de los switch integrados en la red. Los factores considerados en el monitoreo son: Estado operacional de las interfaces en general o alguna en especifico. Carga de CPU, memoria en uso, utilización de ancho de banda (trafico TX RX en bytes). Pérdidas de paquetes. Información en tiempo real para identificar y diagnosticar fallas. Información histórica para realizar comparativos con la de tiempo real. Diagnosticar problemas o corregir fallas y estadísticas de funcionamiento Métricas de monitoreo Algunos dispositivos cuentan con sensores de temperatura, voltaje, estado de abanicos, etc., en los manuales de cada dispositivo deberán estar especificados los parámetros de máximos y mínimos de cada elemento a ser monitoreado. En el caso del monitoreo de tráfico en un puerto, el uso de ancho de banda y la latencia son dos parámetros importantes para medir el rendimiento de la red o para detectar posible saturación de tráfico o colisiones. En este caso la configuración puede variar según las necesidades demandadas Configuración y análisis del sistema Cacti La instalación de los sistemas Cacti y Nagios se realizará sobre una plataforma Linux distribución OpenSuse11, por motivos de configuración de ambas aplicaciones y por que ya se tiene experiencia en el manejo de este sistema operativo. El equipo de cómputo a utilizar en este proyecto tiene las siguientes características; doble procesador AMD 64 Opteron de 1.6 GHz, 512MB en Ram y 80GB en Disco Duro. 16

17 La instalación y configuración de cacati se inicia con la instalación de los servicios de Apache, MySQL, RRDTool, Net-snmp y PHP en el servidor OpenSuse. Después hay que instalar los módulos faltantes y necesarios para que PHP, MySQL y Apache se comuniquen entre sí, es decir: #apt-get install php5-cli #apt-get install php5-mysql #apt-get install libapache2-mod-php5 Se requiere crear un usuario y un grupo para los usuarios de cacti: #adduser cactiuser #addgroup cacti Posteriormente es necesario crear la base de datos y dar permisos a la DB para que el usuario cactiuser pueda accesarla. Se procedeme inmediatamente con la descarga del código fuente de cacti desde su página oficial Ya que es descargado se tendrá que descomprimir de preferencia en el directorio root (www) de apache2, después lo renombramos a CACTI, entramos al directorio de cacti y creamos el modelo de datos importando el script cacti.sql a la base de datos en mysql. Después se modifica el archivo de configuración de cacti; #vi include/config.php (aquí se validarán los campos con el nombre de la DB creada, así como con el usuario y clave asignados). Se requiere la configuración de una tarea calendarizada o cron para realizar la actualización cada cierto tiempo. Acto seguido se reinicia el servicio del apache y el mysql. Con esto se da por finalizada la instalación. El siguiente paso es configurar por primera vez a cacti mediante la interfaz web, para esto se abre una sesión de navegador web y colocamos la dirección IP del servidor y el nombre del folder de CACTI: 17

18 La configuración por primera vez es simplemente para verificar que todos los valores requeridos y las rutas estén correctamente definidos. Cacti cuenta con una serie de plantillas de dispositivos definidas por defecto, se pueden agregar más plantillas desde la página oficial de cacti, así como plantillas y scripts de terceros para estadísticas específicas. Una vez ya agregadas al sistema cacti, las platillas pueden ser personalizadas modificando sus atributos. En este proyecto solo se permitirá agregar un switch y un punto de acceso (Access Point) para realizar las pruebas correspondientes. Se descargaron unas platillas para el modelo de switch y del dispositivo inalámbrico a configurar en cacti. Para recolectar la información de los dispositivos de red, es necesario habilitar el protocolo SNMP en los dispositivos. Por ejemplo, en nuestro caso se requiere conocer el uso del CPU, memoria, estado de abanico e interfaces de un Cisco Catalyst 2950, por lo tanto, en el dispositivo activamos lo siguiente: sw(config)# snmp-server community public RO sw(config)# snmp-server enable traps snmp sw(config)# snmp-server enable traps config sw(config)# snmp-server contact Administrator Una vez activado este servicio en el switch, agregamos los dispositivos en cacti utilizando las plantillas previamente cargadas. Después se procede a crear las gráficas agregando o modificando los atributos como el color, líneas horizontales, función de consolidación, operación matemática (CDEF), etc. Para visualizar las 18

19 gráficas, es necesario agregarlas a un árbol nuevo o existente de gráficas. A continuación se muestra la configuración realizada en la empresa: CPU, memoria, estado del abanico y trafico generado en los puertos 22 y 24 del switch. Gráficas a detalle del tráfico generado en el puerto Do0 Tráfico generado en los puertos del Access Point configurado en el sistema Cacti. 19

20 Se puede visualizar a detalle por segmentos de tiempo cada elemento monitoreado. Monitoreo del tráfico generado en el puerto 24, por hora, día, semana, mes y año. Ventajas: Es una herramienta es muy flexible gracias a su concepto de plantillas. Existen cientos de plantillas en Internet para la gran mayoría de los dispositivos y servicios que se utilizan en una red. La mayor parte de las funcionalidades pueden ser configurables mediante la interface web. 20

21 Permite la administración de usuario y personalizar los perfiles de cada uno de ellos según su roll. Se cuenta con la opción de importar y exportar los templetes. Si se requiere personalizarlos, se pueden hacer desde un procesador de XML y después importarlos nuevamente al sistema Cacti. Cuenta con bastantes plugins que prácticamente fortalecen y hacen a Cacti una herramienta potente para los administradores de redes. Envío de alertas por correo del estado de los dispositivos monitoreados, mediante el plugin Thold, que su función es tomar los valores de las gráficas para verificar la disponibilidad del Host y así poder emitir la alerta. Puede ser configurado y utilizado en las plataformas Linux y Windows. Desventajas y limitantes: Su instalación es muy extensa por la cantidad de componentes que requiere para su ejecución. La configuración pudiera a llegar a ser un poco compleja por la cantidad de componentes que interactúan con Cacti. Su presentación de inicio es de forma austera, mostrando como funcionalidad primaria la de graficado de datos recolectados. Para cualquier otra función que no se encuentre integrada al sistema Cacti, será necesario localizar e integrar el plugin al sistema Configuración y análisis del sistema Nagios La explicación de la instalación es a grandes rasgos y en la configuración no se describirá a detalle, ya que este sistema es un poco complejo para este proceso, por lo tanto se tardaría demasiado en abordar cada uno de los puntos del proceso de configuración. Es importante mencionar que esta aplicación solo es ejecutada en Linux, por lo tanto, la configuración se realizó en un servidor con la distribución OpenSuse11. Se requiere tener instalado un servidor Apache2 para visualizar la interface web de nagios, bibliotecas y herramientas de compilación necesarias para generar los 21

22 binarios de nagios como lo son gcc, gd y php5-gd y por ultimo un gestor de base de datos como lo es el MySQL, para guardara el historial del eventos. Una vez cumplidos con los requisitos anteriores procedemos a la instalación, para ello se requiere descargar nagios del sitio oficial la versión fue la más reciente a la fecha del desarrollo de este documento. También descargar los plugins que son los que servirán para el monitoreo de algún dispositivo en especial. La instalación se puede hacer de dos maneras, la primera es utilizando la herramienta de instalación YaST mediante los repositorios existentes y la segunda opción es realizarlo de manera manual compilándolo. La diferencia entre ambas es las rutas en que son ubicadas las aplicaciones al momento de instalarse. Al momento de configurar las aplicaciones es cuando se complica la localización de los componentes requeridos. Aunque requiere mayor trabajo y tiempo, se recomienda la segunda opción. # tar xvfz nagios tar.gz >>entrar al directorio nagios #./configure # make all && make install && make install-init && make install-config Si saliera un error quizás sea por falta de alguna de las herramientas o bibliotecas necesarias para la ejecución de nagios. Con esto queda instalado este sistema, después se procede a realizar la instalación de los plugins efectuando el mismo procedimiento anterior. Una vez terminado con este último proceso, se requiere configurar lo siguiente: Crear un nuevo usuario nagios y asignarle una contraseña OpenSuse. Crear un grupo nagios. Agregar el usuario nagios a este grupo. Ejecute el script de configuración de Nagios, pasando el nombre del grupo que se creó anteriormente: #./configure --with-command-group=nagios 22

23 Por último se le define a servidor apache el acceso a la página de nagios, también se reinician los servicios respectivos de apache y nagios, para que carguen los nuevos valores de configuración: #htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin #service apache2 restart #service nagios restart Al igual que la configuración de Cacti, en esta aplicación se definirá un switch y un punto de acceso para ser monitoreados, es necesario configurar cada uno de los archivos cfg que estarán involucrados en los eventos. Para entender mejor el funcionamiento de nagios primeramente es necesario familiarizarse con sus archivos de configuración que prácticamente son la columna vertebral de nagios. Estos archivos son: nagios.cfg Configuración general de nagios. resources.cfg Archivo donde se definen los recursos (plugins, password, etc.). cgi.cfg Configuración del Interfaz web (mapas, imágenes, etc.) hosts.cfg Archivo donde se dan de alta los host a monitorear. hostgroups.cfg Definición de los grupos a los que pertenece cada host contacts.cfg Definición de usuarios (nombre, dirección, etc.). contactgroups.cfg Archivo donde se agregan a los usuarios de contacts.cfg en su respectivo grupo. services.cfg Definición de los servicios que podrán ser utilizados para monitorear los dispositivos. localhost.cfg Controla los procesos y servicios del equipo en el que Nagios está ejecutándose. printer.cfg Definición de impresoras a monitorear. switch.cfg Monitorizado de dispositivos de red, como routers y switches. windows.cfg Monitorizado de equipos y servicios de Windows. Según se vaya requiriendo se pueden ir agregando según las necesidades. Para este caso fue necesario crear un grupo llamado AP (access point) para definir el dispositivo inalámbrico que será agregado a nagios y ser monitoreado. Para la configuración del switch fue necesario definirlo en los siguientes archivos: En el nagios.cfg se habilito el uso del objeto switch mostrando su ruta: cfg_file=/usr/local/nagios/etc/objects/switch.cfg 23

24 En el archivo de configuración switch.cfg se definió el nombre del dispositivo y los servicio que van a ser monitorear, esta sería su estructura: # HOST DEFINITIONS define host{ use generic-switch ; Inherit default values from a template host_name ENCCSW01 Sistemas alias Cisco Switch ; A longer name associated with the switch address xx.xx.xx.xx ; IP address of the switch hostgroups switches ; Host groups this switch is associated with } # HOST GROUP DEFINITIONS define hostgroup{ hostgroup_name switches ; The name of the hostgroup alias Network Switches ; Long name of the group } # SERVICE DEFINITIONS # Create a service to PING to switch define service{ use generic-service ; Inherit values from a template host_name ENCCSW01 Sistemas ; The name of the host the service is associated with service_description PING ; The service description check_command check_ping!200.0,20%!600.0,60% ; The command used to monitor the service normal_check_interval 5 ; Check the service every 5 minutes under normal conditions retry_check_interval 1 } El mismo proceso se realizó con el punto de acceso, en este caso solo fue necesario crear un objeto llamado ap.cfg donde se definieron los servicios que se requieren monitorear, de igual forma, se dio de alta en el archivo templates.cfg y nagios cfg. Cada vez que se realiza alguna configuración a los archivos cfg es necesario reiniciar el servicio de nagios para que cargue los nuevos valores. Pantalla principal de nagios, la cual muestra un resumen del estado actual del sistema y sus componentes agregados a él. 24

25 Despliegue de todos los hosts Menú Servicios. Estado de los servicios de todos hosts agregados en el sistema. En esta ventana se detectan algunos servicios en estado crítico. Menú Problemas: Despliega los host a los que se les detectó algún problema. 25

26 Alertas generadas en los dispositivos. Clasificado por segmento fecha y hora. Alerta de uso de ancho de banda del puerto 24. Ventajas: Cubre las necesidades básicas de monitoreo en forma sencilla, es adaptable y modificable para necesidades específicas. Flexible por ser de código abierto. Instalación muy sencilla y existen cientos de plugins disponibles en Internet. Capacidad de soportar la carga de miles equipos o servicios. 26

27 Se basa en un conjunto de pequeños módulos llamados plugins especializados para revisar el estado de diferentes servicios. Por lo tanto, tiene la capacidad de monitorear servicios de red de manera distribuida, esto es, monitoreo de protocolos como: Ping, DHCP, SMTP, entre otros. Envío de alertas de correo y/o sms, audio, etc., de tipo individual o en grupo de los eventos ocurridos ya sean no favorables o cuando estos son restablecidos. Permite programar las alertas, definir grupos de contactos, llevar una base comentarios o conocimientos alimentadas por el administrador y determinar los parámetros de chequeo. Cuenta con una herramienta de validación de los ficheros de configuración. Desventajas y limitantes: Su configuración es muy complicada, porque se tiene que definir cada dispositivo o servicio en los diferentes plantillas de configuración de Nagios. Entre más grande sea la red a monitorear, mayor será el tiempo dedicado para su configuración. Es mínima la gestión en la interface web. Se corre el riesgo de cometer algún error al momento de editar la configuración de un servicio o dispositivo. 8. CONCLUSIONES Determinar qué aplicación de monitoreo es la más efectiva, es algo complicado ya que ambas reúnen las cualidades necesarias requeridas para este proyecto de evaluación. Además por tratarse de aplicaciones de código abierto, estas son mejoradas día a día por las constantes contribuciones de las comunidades de desarrolladores. Ambas aplicaciones nos guían a cubrir las tareas de monitoreo de tal manera que solo necesitan que se les alimente de las instrucciones según las necesidades en la red. Cacti se enfoca más a la evaluación de la información y a la presentación de los datos de manera gráficas. Por el otro lado, la aplicación de nagios se enfoca más a 27

28 lo informativo, visual y lo más atractivo, es sistema de notificación inmediata del estado de los dispositivos en red. Lo interesante en ambas aplicaciones es que por las herramientas que se les han ido agregado con el paso del tiempo las han fortalecido y las han hecho más completas y competitivas. Estos agregados se pueden subrayar como en el caso de cacti, mediante su plugins de notificaciones vía correo y por la otra parte, nagios con el Add-on que le permite el graficar la información obtenida. Cacti resulta más cómodo de configurar y más flexible a la hora de presentar la información, por otra parte, a nagios se le considera como un sistema funcional e interesante para el monitoreo de la red. Con la combinación de ambas aplicaciones se podría contar con mayores alternativas para la obtención y presentación de la información. Con la comprobación de ambos sistemas se puede decir que se cumple con el objetivo principal planteado en este proyecto, y a su vez, se entrega una solución de sistema que dará excelentes resultado en cuanto al monitoreo y gestión de dispositivos de red. Actualmente tomar una decisión sobre aplicaciones de Open Source a implementar en una organización no es nada sencillo, porque se presta a la desconfianza de su utilización donde probablemente viole la seguridad y privacidad de los datos en la empresa. Cacti y Nagios proporcionan esa confianza de ser unas aplicaciones seguras, porque son programas que ya tienen unos años en funcionamiento y siendo probadas con éxito, además se han fortalecido con el paso del tiempo. Por tales razones, la propuesta es usar una de estas dos herramientas para la administración de los dispositivos de red en una empresa como ECSA, o en la medida de las posibilidades, utilizar las dos para complementar las fortalezas de cada una. 28

29 9. RECOMENDACIONES Al analizar e implementar las herramientas presentadas, se tuvo como experiencia el cuidado de ciertos detalles que pueden ser cruciales en el desempeño de las mismas. A manera de recomendaciones se presentan las situaciones más importantes y que sin duda ahorrarán tiempo y evitarán frustraciones: 1. Es vital identificar claramente la ubicación los elementos que serán utilizados por el sistema (apache, mysql, php, etc.) para su correcto funcionamiento. En el caso de la distribución OpenSUSE 11, se recomienda no utilizar el asistente de instalación de software (YAST), ya que la instalación de cada programa la realiza de forma distinta y en rutas diferentes a la instalación realizada en forma manual utilizando la herramienta TAR. 2. Es muy importante establecer los horarios de alertas de estas dos aplicaciones, ya que pueden llegar a saturar las cuentas de correos de tantos avisos. 3. Los plugins o componentes de cada aplicación de monitoreo, deberán corresponder a cada versión de Cacti o Nagios instalados, en el caso contrario se correrá el riesgo de dañar la instalación de los sistemas de monitoreo. 10. BIBLIOGRAFÍA Cacti ( ). Cacti HowTos. Consultado el 8 de marzo del 2010 en Campos, A. (2007, Abril-Junio). Qué son los sistemas de gestión de red?. Consultado el 8 de agosto del 2007 en alfredo44.html MacFaden, M., Partain, D., Saperia J. & Tackabury W. (2003, April). Configuring Networks and Devices with Simple Network Management Protocol (SNMP). Consultado el 3 de marzo del 2010 en 29

30 ManageEngine, OpUtils: Network Monitoring Toolset. Consultado el 8 de marzo del 2010 en Nagios Core Development Team ( ). Nagios Core 3.x Documentation. Consultado el 8 de marzo del 2010 en Oetiker, T. (12-Sep-2009). About RRDtool. Consultado el 8 de marzo del 2010 en Presuhn, R., Case, J., McCloghrie, K. Rose, M. & Waldbusser, S. (Diciembre 2002). Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP). Consultado el 8 de marzo del 2010 en Presuhn, R., Case, J., McCloghrie, K. Rose, M. & Waldbusser, S. (Diciembre 2002). Transport Mappings for the Simple Network Management Protocol (SNMP). Consultado el 8 de marzo del 2010 en 30