Desarrollo de un sistema de monitorización y administración remota de equipos de telecomunicaciones

Transcripción

1 1 Desarrollo de un sistema de monitorización y administración remota de equipos de telecomunicaciones Federico Bonsignore, Federico Merino, Gonzalo Ramos, Rafael Staricco, José Joskowicz Resumen Existe hoy en el mundo una gran preocupación por contar con redes corporativas de telecomunicaciones con la mayor disponibilidad posible, ya que están cada día más fuertemente ligadas a los resultados comerciales que se obtienen. La importancia que cobra esta necesidad conduce a la búsqueda de alternativas para manejar adecuadamente la información de los equipos en tiempo real y las notificaciones de fallas a personal de guardia para ofrecer mejores tiempos de respuesta. Los autores presentan en este artículo una solución a esta problemática planteada, abordando el diseño, desarrollo y construcción de un sistema para la monitorización y administración remota de equipos de telecomunicaciones, basado en TINI (Tiny InterNet Interface), una plataforma de hardware con Java embebido. Se discuten los resultados obtenidos y las conclusiones alcanzadas, así como posibles trabajos futuros. Palabras Clave 1-Wire, Agente, Alarmas, Eventos, Matching. I. INTRODUCCIÓN A nivel empresarial resulta hoy en día sumamente importante contar con sistemas de comunicaciones funcionando permanentemente, permitiendo así el correcto desenvolvimiento de los negocios. Se invierten grandes sumas de dinero en infraestructura, se montan enormes redes que intercomunican diferentes sitios, se establecen importantes contact centers que centralizan la comunicación con los clientes, etc. Naturalmente, se destina también una buena parte de los recursos a los sistemas y contratos de mantenimiento, los que generalmente incluyen servicios de guardia permanentes y Artículo recibido el 10 de Julio de El proyecto Umpire fue financiado parcialmente por ISBEL S.A. F. Bonsignore se desempeña en el Dpto. de Ingeniería en ISBEL S.A., Montevideo, Uruguay ( fbonsignore@isbel.com.uy). F. Merino es Jefe de Ventas para Uruguay en ISBEL S.A., Montevideo, Uruguay ( fmerino@isbel.com.uy). G. Ramos trabajó en el área de soporte técnico de Anteldata, y en Softnet Uruguay. Hoy se desempeña en Huawei Technologies, Montevideo, Uruguay ( gramos@huawei.com). R. Staricco trabajó en el área de soporte técnico de Anteldata. Hoy es Asesor Comercial en ISBEL S.A., Montevideo, Uruguay ( rstaricco@isbel.com.uy). J. Joskowicz, Profesor Adjunto (Gr. 3) de la Facultad de Ingeniería UDELAR y Gerente de Desarrollo de Software en ISBEL S.A., Montevideo, Uruguay ( jjoskowicz@isbel.com.uy). exigentes tiempos de respuesta ante fallas. Existe, adicionalmente, una marcada tendencia hacia contratos de soporte con pagos acordes a la calidad de servicio (ANS, Acuerdos de Nivel de Servicio) En estos casos, el tiempo de respuesta ante fallas es lo que marca la gran diferencia entre un contrato rentable, con buena calidad de servicio para el cliente final, o un contrato no rentable, con pobre calidad de servicio para el cliente final. Es de esta forma que surge la necesidad de tener un monitorizador en sitio, que revele lo que está ocurriendo en el interior del o de los equipos principales. Contratar personal calificado y dedicado en sito para esta labor resuelve casi siempre el problema del tiempo de respuesta, pero resulta excesivamente caro para la prestadora del servicio. Lo que se precisa es contar con algo que controle en todo momento lo que sucede en los equipos del cliente, que perciba inmediatamente si se produjo una falla, que la clasifique correctamente según su severidad, que tome alguna acción básica si es necesario, y que notifique inmediatamente lo sucedido al equipo humano de guardia que se encuentra, generalmente, lejos de allí. Conceptualmente, la idea está inmersa en el modelo de red de gestión de redes de telecomunicaciones TMN (Telecommunications Management Network), especificado en la serie de recomendaciones M.3XXX de UIT-T (Unión Internacional de las Telecomunicaciones, sector Normalización de las Telecomunicaciones) [1]. La entidad que se busca generar estará formando parte de la capa más baja de dicho modelo, la de Gestión de Elemento (Element Management), como una interfaz de contacto entre la DCN (Data Communication Network, red de comunicación de datos) y la red de telecomunicaciones. Si bien muchos equipos ya traen incorporados diferentes mecanismos que soportan la notificación de alarmas, éstos varían según el fabricante y hay otros (algunos críticos, por ejemplo ciertas aplicaciones de IVR, Interactive Voice Response) que no tienen un manejo unificado de la información de eventos internos por lo que se torna dificultoso consolidar un sistema único y homogéneo, de forma que los distintos eventos registrados puedan reportarse de una manera adecuada y centralizada. En 2001, José Joskowicz orientador del proyecto que derivó en el producto que se describe aquí- junto a otros

2 2 colaboradores desarrollaron un software llamado Gossiper (por mas detalles ver [2]), que buscaba resolver algunas de estas complicaciones. El software propone un sistema de recolección y tratamiento de eventos centralizado a través de una topología en estrella, donde una entidad principal se encarga de procesar los envíos de cierto número de agentes remotos en tiempo real, avisando por intermedio de correos electrónicos o SMS (Short Message Service) al personal de guardia que está de turno, y/o generando reclamos en un sistema de tickets de soporte. El software fue lanzado comercialmente al poco tiempo y funciona hasta el día de hoy en distintos clientes de la empresa que adquirió los derechos para su comercialización. No obstante, comenzaron a aparecer algunas desventajas en Gossiper. Una de ellas es el alto costo asociado para el cliente que surge de tener que instalar el agente remoto sobre un PC. Es frecuente observar que, en el intento por disminuir este costo indirecto, se incurre en otro inconveniente de índole operativa: el uso compartido del equipo con otras aplicaciones produce en ocasiones inestabilidades generadas por conflictos internos que derivan muchas veces en la generación de falsas alarmas, o en la omisión de alarmas reales. Es decir, afectan el mismísimo cometido del software. Estas y otras circunstancias prácticas motivaron a los autores a buscar una nueva alternativa, que no sólo intenta superar las anteriores dificultades observadas sino que además incorporara nuevas funcionalidades. Nace así Umpire 1, un equipo stand-alone diseñado y construido a la medida de estos requerimientos. En el presente artículo se explicará en qué consiste esta solución propuesta, qué funciones cumple y cómo ha respondido a las pruebas de campo a las que ha sido sometido. II. LA SOLUCIÓN BUSCADA Como se explicó en la sección anterior, se buscaba diseñar un nuevo equipo capaz de poder manejar continuamente grandes volúmenes de información y de discriminarla en favor de detectar eventos peculiares o pre-configurados dignos de ser reportados. Estos eventos a su vez son de distintos tipos: los hay aquellos que se manifiestan cuando se dan una serie de coincidencias predefinidas, aquellos otros que se disparan cuando éstas no se dan en un cierto tiempo, los que se quieren ejecutar sólo al inicio del sistema, aquellos que se precisa generar periódicamente y los que contienen información de supervivencia del nodo remoto para el sitio central. También era de interés de los autores mantener la compatibilidad hacia atrás con Gossiper, por lo que se debía conservar el mismo formato que utilizaba este software. Funcionalidades adicionales que se deseaban incorporar eran, entre otras, el manejo de salidas locales en el sitio remoto, la posibilidad de administración de los equipos monitorizados, la integración de los equipos a sistemas de monitorización basados en SNMP cuando éstos no contaran con soporte nativo de dicho protocolo, y la monitorización del estado de algunas variables de entorno. En beneficio de lo anterior se debió buscar un soporte de hardware apropiado, que contara con las interfaces adecuadas. A. Generalidades III. EL PRODUCTO FINAL Para la implementación de este producto se decidió utilizar la plataforma TINI [3], [4], que es un microcontrolador desarrollado por Dallas Semiconductor especialmente diseñado para proveer un medio simple, flexible y económico para desarrollar sistemas de control que deban integrarse y comunicarse en ambientes de redes corporativas o residenciales. Habilita a los desarrolladores de software a usar tres lenguajes, Java, C o Assembler, siendo la primera opción la más popularmente utilizada. A través de las APIs (Application Programming Interface) del JDK 1.1 [5] el programador puede crear una amplia variedad de aplicaciones utilizando las ventajas que ofrece dicho lenguaje. TINI ofrece además la posibilidad de usar un hardware propietario adicional comúnmente conocido como socket, que le brinda al desarrollador varias interfaces de I/O, especialmente útiles en el caso en cuestión. Dentro de estas opciones, el socket provee una interfaz Ethernet accesible a través de un conector RJ-45, un conector RJ-11 por el cual se conectan dispositivos que soportan un protocolo propietario llamado 1-Wire [6] y dos interfaces RS-232 accesibles en sendos conectores DB-9. La plataforma TINI permite a dispositivos con salidas de comunicación estándar ser monitorizados, controlados y manejados remotamente. Varios otros sistemas han sido desarrollados basados en plataformas con Java embebido, con muy buenos resultados [7]-[10]. En la fig. 1.a se muestra la vista frontal del equipo ya completamente ensamblado, donde se puede observar un botón de reset y cuatro leds; los tres verdes son los indicadores de encendido de los tres relays que posee el equipo internamente para controlar hasta tres circuitos externos independientes, y el rojo es el que indica si Umpire esta encendido. Por su parte, la fig. 1.b es una vista trasera del equipo. Se distinguen dos conectores RJ-45, uno para la interfaz Ethernet, y otro para la interfaz 1-Wire, y dos conectores DB-9, para entradas seriales. Se aprecian también las tres entradas para conectar circuitos externos a los relays anteriormente mencionados. Se observa a su vez la entrada de alimentación que esta conectada a la fuente de tensión continua y el interruptor para encender o apagar Umpire. 1 Umpire significa en español juez de silla, evocando la función de árbitro que se buscaba en el equipo a diseñar dentro de una red de telecomunicaciones.

3 3 Fig. 1.- a. Vista frontal del equipo desarrollado. b. Vista trasera. Se desarrolló enteramente en Java un software cuyas principales funcionalidades se describen a continuación: 1. Comunicación vía con servidor central de Gossiper (envío y recepción). 2. Intercambio de archivos de datos con equipos de red (colocación hacia y recuperación desde servidores o equipos con capacidad de almacenamiento de archivos). 3. Soporte para SNMP (Simple Network Management Protocol) de forma de permitir la integración de los equipos con un sistema central de monitorización de redes basado en este protocolo. 4. Capacidad de control sobre una red de sensores y actuadores. 5. Soporte para funcionar como servidor web de forma de ser capaz de manejar una interfaz accesible de forma remota a través de conexiones HTTP (Hypertext Transfer Protocol) realizables desde cualquier web browser estándar. 6. Emulación de terminal serial para administración remota de los equipos monitorizados. En la fig. 2 se observa un diagrama típico del sistema desarrollado dentro de una red empresarial donde se desea monitorear el funcionamiento de un equipo genérico a través de una conexión serie y de algunas variables locales de entorno. Fig. 2.- Esquema de un posible escenario de aplicación para Umpire B. Descripción general de funcionamiento Como se describió hasta aquí Umpire es un sistema embebido que concentra una serie de funcionalidades útiles para la monitorización y administración de equipos de telecomunicaciones. Desde el punto de vista de monitorización el sistema es capaz de manejar y controlar equipos, ya sea a través de una conexión serial o una conexión de red. Por otra parte, también puede sensar variables de entorno a través del protocolo 1- Wire. En este primer desarrollo se refiere, se cubrió únicamente lo referente a las medidas de temperatura y estado de interruptores. Es a través de esos diferentes mecanismos que el sistema obtiene la información que deberá procesar para efectuar su función de monitorización y control. Una vez que los datos son obtenidos por el sistema, éste procede a analizarlos de forma de poder detectar la ocurrencia de alguna circunstancia anómala que amerite ser reportada como una alarma o evento. La detección de estas alarmas se hace en base a una serie de reglas predefinidas que se explicarán a continuación. Luego del análisis de las diferentes entradas, el sistema se encarga por un lado de respaldar la información capturada de las diferentes entradas y por otro, de ejecutar los diferentes procedimientos para la propagación de las eventuales alarmas existentes. Como la plataforma de hardware no ofrece abundantes recursos en lo que refiere a almacenamiento de datos, el sistema se encarga internamente de mantener los diferentes respaldos controlando su tamaño y enviándolos vía FTP (File

4 4 Transfer Protocol) a un servidor de archivos una vez que estos superan un determinado volumen pre-configurado. De esta manera se tienen disponibles en el sistema los últimos datos recibidos y se mantiene en este servidor externo toda la actividad recibida por las diferentes entradas. Cuando hay alarmas o eventos detectadas, el sistema prevé varios mecanismos para su reporte. Las vías de propagación de alarmas soportados por Umpire son, el envío de s al servidor central del sistema Gossiper, con el cual se aseguró la correcta compatibilidad, el envío de traps SNMP v1 a una consola de administración central (NMS) y la activación de salidas locales a través del control de dispositivos controlados por apertura y cierre de relays (los cuales pueden ser manejados por el sistema desde el bus 1-Wire). La elección del mecanismo para las diferentes alarmas dependerá de cada caso según el sistema esté configurado. Otra funcionalidad es la que se relaciona con la administración de equipos seriales a través de una conexión de red. El sistema es capaz de aceptar conexiones externas por su interfaz de red de forma de proveer un acceso al puerto serie del equipo conectado a esta interfaz. Esto permite por ejemplo configurar equipos por su consola serial a través de un acceso de red y sin la necesidad de establecer la conexión a los mismos vía módems accedidos por una línea telefónica. Para esto el sistema cuenta con la capacidad de emular el terminal serial de forma de ejecutar por intermedio de su puerto serial las instrucciones y comandos enviados a través de la conexión de red establecida. Este y otros procesos se detallarán más adelante. Finalmente, se destacan los distintos medios de administración, mantenimiento y monitorización propios de Umpire. A través de la interfaz web se puede acceder a la configuración actual y a diferentes variables y archivos claves para analizar el estado actual de funcionamiento. Por otro lado, es posible realizar actualizaciones de la configuración simplemente en base al envío de s a Umpire. Por último, un completo sistema de información de actividad y mantenimiento de fallas es constantemente registrado en los diferentes archivos log internos del sistema. En la fig. 3 puede verse a la izquierda el circuito impreso diseñado, incluyendo la fuente de alimentación, la serie de relays y la conexión de salida para el bus 1-Wire. Sobre la derecha se observa otro circuito impreso, correspondiente al socket y el microcontrolador TINI. Fig 3.- Vista del hardware interno C. Algunos aspectos técnicos Como se explicó anteriormente, el software interno de Umpire está enteramente desarrollado en Java. Se compone de tres bloques principales llamados Umpire Core (UC), Umpire Serial Monitor (USM) y Umpire Web Interface (UWI). UC es quien se encarga de coordinar y ejecutar todas las tareas necesarias que aseguren el correcto procesamiento y notificación de los datos que arriban al sistema, típicamente a través del trabajo de USM en la puerta serie, pero también gracias a los aportes según el caso- de un cliente FTP y del controlador del bus 1-Wire, implementados en packages interno que también integran UC. Este bloque tiene un motor de matching incorporado que analiza secuencialmente los datos en busca de patrones de texto predefinidos que sean considerados de relevancia para el equipo monitorizado, y temporizadores que disparan eventos periódicos. Cuenta a su vez con packages que manejan los protocolos SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol versión 3) y SNMP entre otras cosas, como se puede observar en el esquema de packages de la fig. 4. USM no sólo cuenta con el lector de datos de la puerta serie, sino que además tiene bajo su control el proceso que espera conexiones a un puerto TCP (Transmission Control Protocol), y escribe en la interfaz serial todo lo que llega allí y viceversa, permitiendo administrar vía TCP/IP el equipo monitorizado.

5 5 Fig. 4.- Diagrama UML de packages de UC Por último, el tercer bloque implementa una interfaz de acceso vía HTTP a través de un applet Java, que corre en el PC local del administrador, liberando de esa forma mucha carga de procesamiento que en soluciones del tipo server-side asumiría mayoritariamente Umpire, claramente no conveniente en este caso. De esta forma, se diseñó un protocolo básico de comunicación entre los dos extremos, cuya interacción se esquematiza simplificadamente en la fig. 5. Éste permite el pasaje de los datos desde y hacia Umpire, que incluyen información de los estados actuales de los sensores 1-Wire, gráficas históricas, contenido de los archivos de configuración, y logs. Ver [2] por más detalles. Fig 5.- Diagrama UML de despligue o instalación de la interfaz web. La configuración del equipo se realiza mediante una serie de archivos de texto plano que contienen los diferentes parámetros necesarios para la interconexión de los equipos y para la interpretación de la información que se recibe. Está previsto que estos archivos de configuración se generen a través de la interfaz gráfica de administración de Gossiper. Se elaboraron manuales de instalación [11] y configuración [12] que permiten operar sencillamente el equipo. Otro de los objetivos iniciales era documentar detalladamente el proceso de ensamblaje [13], para lo que se confeccionaron planos físicos y de los circuitos con instrucciones de armado, de manera de posibilitar la fabricación en serie de este producto. IV. PRIMEROS RESULTADOS OBTENIDOS Se realizaron ya pruebas en ambientes reales de aplicación, y se obtuvieron resultados satisfactorios, tanto de captura y procesamiento de eventos como de interoperabilidad con el servidor central de Gossiper. En cuanto a su capacidad de procesamiento de datos seriales, que era uno de los parámetros más importantes e interesantes por su naturaleza asíncrona y por la importancia de no perderlos en ningún momento, se estimó para la primera versión terminada que puede recibir una tasa sostenida de entrada superior a los 200 kbps. En lo que refiere al software, se analizaron las funcionalidades del equipo minuciosamente a través de un Test Plan, incluyendo tests funcionales de caja negra y de caja blanca, así como tests de stress.

6 6 V. CONCLUSIONES Umpire se presenta como un producto novedoso teniendo en cuenta que no se encuentran sencillamente en el mercado equipos con similares prestaciones, tamaño y costo. Luego de las primeras experiencias en ambientes reales se observa que el producto cumple satisfactoriamente con las funciones para las que fue diseñado. La documentación existente permite producir el equipo en forma serial, lo cual era un objetivo del equipo que desarrolló Umpire. Otros proyectos previos en plataformas similares [14] habían sido elaborados para casos particulares, y la posibilidad del ensamblaje industrial del equipo en cuestión marcó una diferencia sustancial con aquellos. La temática que enfrenta Umpire permite pensar en una gran cantidad de posibles agregados y mejoras para hacer en futuras versiones. Se ha pensado en particular en desarrollar soporte para otros protocolos (ESMTP, PPP, versiones superiores de SNMP), ampliar la gama de sensores 1-Wire para permitir una lectura más completa del estado del entorno de los equipos, y adaptar el software de Umpire a otras plataformas más potentes de hardware [15] para producir en el mediano plazo una versión apta para escenarios de aplicación más exigentes y/o de mayor porte. [13] F. Bonsignore, F. Merino, G. Ramos, R. Staricco, J. Joskowicz. Umpire v1.0. Manual de Ensamblaje, Facultad de Ingeniería, UDELAR, Marzo 2006 [14] D.Parente, A.Rancaño, F.Viñar, R. Sotelo, STAS-nfxr: Sistema Remoto de gestión de un equipo trasmisor de FM. Documentación Proyecto de Fin de carrera, Facultad de Ingeniería UDELAR. Junio, 2004 [15] Systronix, Documentación de JStick, Octubre Disponible: REFERENCIAS [1] CCITT Recommendation M.3010, Principles for a Telecommunication Management Network, Geneva, 1996 [2] F. Bonsignore, F. Merino, G. Ramos, R. Staricco, J. Joskowicz. Umpire v1.0. Documentación del Proyecto de Fin de Carrera, Facultad de Ingeniería, UDELAR, Marzo [3] D. Loomis, The TINI Specification and Developers Guide ADDISON- WESLEY [4] Dallas Semiconductor MAXIM, Getting Started with TINI, Diciembre, Disponible: [5] Sun Microsystems, Inc. Java Development Kit 1.1, 1998, Disponible: [6] Dallas Semiconductor MAXIM. 1-Wire Specification, Diciembre, Disponible: [7] Low-cost home monitoring using a Java-based embedded computer, Lamberti, F. Demartini, C., 4th International IEEE EMBS Special Topic Conference on Information Technology Applications in Biomedicine, 2003 [8] The role of embedded agents in creating ambient intelligent environments, H Hagras and M Colley, IEE Seminar on Intelligent Building Environments, (2005/11059), p. v1-127 [9] Towards a RT-Java based embedded remote monitoring tool for smalland medium power plant units, Reveilleau, L. Becquet, E. Gressier-Soudan, E. Douin, J.-M. Bacon, L. Horn, F., IEEE International Conference on, Emerging Technologies and Factory Automation, Proceedings th [10] Simulation and Modeling of a Remote Home Automation System using an Embedded Programmable Logic Device (EPLD) and a Tiny Internet Interface (TINI), Matthew Crowley, Graham McDougall and Scott Stanley, Electrical and Computer Engineering in the Faculty of Engineering of the University of Manitoba [11] F. Bonsignore, F. Merino, G. Ramos, R. Staricco, J. Joskowicz. Umpire v1.0. Manual de Instalación, Facultad de Ingeniería, UDELAR, Marzo [12] F. Bonsignore, F. Merino, G. Ramos, R. Staricco, J. Joskowicz. Umpire v1.0. Manual de Operación, Facultad de Ingeniería, UDELAR, Marzo 2006.