PLATAFORMA WEB PARA UNIFICAR LA ADMINISTRACIÓN DE EQUIPOS Y SERVICIOS DE REDES DE COMPUTADORES

Transcripción

1 UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA VALPARAÍSO - CHILE PLATAFORMA WEB PARA UNIFICAR LA ADMINISTRACIÓN DE EQUIPOS Y SERVICIOS DE REDES DE COMPUTADORES DAVID SAMUEL RODRÍGUEZ ALBORNOZ MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO CIVIL TELEMÁTICO. Profesor Guía: Profesor Correferente: Agustín González Valenzuela. Nicolás A. Jara Carvallo. 25 de Junio de 2012

2 A mis Padres por su incondicional apoyo, y su forma de impartir una disciplina de oro. A mis abuelos, el gran Tata Enrique, y mis abuelitas Bili y Alola que no pudieron estar f sicamente, pero siempre las tengo a mi lado, al igual que al legendario abuelito Samuel. A mis padrinos, T a Ten y T o Lucho, grandes exponentes de la familia. A mis hermanos, que ayudaron a forjar mi esp ritu para no convertirme en una mala oveja. A todos mis familiares que siempre creyeron en mi capacidad. A mis profesores, compañeros, amigos, vecinos, novia. Gracias a todos, hoy despego como un hombre nuevo.

3 PLATAFORMA WEB PARA UNIFICAR LA ADMINISTRACIÓN DE EQUIPOS Y SERVICIOS DE REDES DE COMPUTADORES Memoria para optar al título de Ingeniero Civil Telemático DAVID SAMUEL RODRÍGUEZ ALBORNOZ Profesor Guía: Agustín González Valenzuela Profesor Correferente: Nicolás A. Jara Carvallo 25 de Junio de 2012 Resumen La motivación de este proyecto es resolver el problema que existe en materia de configuración de equipos y servicios de red, la falta de uniformidad. Al no existir un estándar de configuración, distintos fabricantes desarrollan soluciones de hardware que se configuran de una forma especial y que llevan a precisar de manuales especiales o capacitaciones para configurar equipos. Este proyecto busca unificar la forma en que los administradores de red interactúan con los equipos y servicios de redes a través de una plataforma web única que permita realizar operaciones de administración y control independiente del fabricante de los equipos. Además se busca que la plataforma sea fácilmente escalable, a diferencia de las aplicaciones actuales. Otro objetivo es lograr una arquitectura que permita admitir nuevos módulos y tecnologías independiente del lenguaje de programación en la cual fueron desarrolladas. Para lograr tal nivel de escalabilidad, la arquitectura se basa en un middleware orientado a mensajes, que permite comunicación asíncrona entre procesos que se encuentran II

4 implementados en lenguajes distintos por medio de colas de mensajes. Gracias a esto, se logra desligar al servidor web de las aplicaciones de bajo nivel, permitiendo que las capacidades de la plataforma se basen en llamados a servicios. La comunicación entre servidor web y servicios se realiza mediante el estándar de mensajería SOAP. Los servicios encargados del control de los equipos de red utilizan un protocolo de comunicación remota para ingresar los parámetros de configuración enviados por el usuario terminal ( o administrador ) desde la interfaz web. Finalmente, se logró como resultado una solución que, por medio de la interacción entre un usuario administrador y la pantalla de un computador personal o smarthphone, logra configurar y administrar equipos de red de distintos fabricantes y modelos de forma rápida y unificada por medio de una misma interfaz web. Palabras Clave: Uniformidad, Plataforma web, middleware orientado a mensajes, administrar equipos de red. III

5 WEB PLATFORM TO UNIFY THE ADMINISTRATION OF COMPUTER NETWORKING DEVICES AND SERVICES Undergraduate thesis for the degree of Ingeniero Civil Telemático DAVID SAMUEL RODRÍGUEZ ALBORNOZ Guide Professor: Agustín González Valenzuela Coreferential Professor: Nicolás A. Jara Carvallo 25 de Junio de 2012 Abstract The motivation of this proyect is to solve the existing problem in terms of network devices and services configuration, the lack of uniformity. Because there isn't a standard configuration, different hardware manufacturers develop solutions that are configured by special ways and require special manuals and capacitation to set up the devices. This project seeks to unify the way that network administrators interact with network devices and services through a single web platform that allows management operations and control, independent of the manufacturer of the devices. It is also sought that the platform be easily scalable, unlike current applications. Another objective is to achieve an arquitecture that allows support for new modules and technologies independent of the programming language in which they were developed. To achieve this level of scalability, the architecture is based on a message-oriented middleware, which enables asynchronous communication between processes that are implemented in different languages through message queues. Thanks to this, it is possible to decouple the web server from the low level applications, allowing the platform capabilities be based on service calls. The communication between web server and services is done through the standard SOAP messaging. The services responsible for monitoring network devices use a remote communication protocol to enter the configuration parameters IV

6 sended by the terminal user (or administrator) from the web interface. Finally, a solution was achieved which, by means of the administrator user interaction and personal computer or smartphone, manages to configure and administrate network devices from different manufacturers and models quickly and unified through a single web interface. Keywords: Uniformity, web platform, message-oriented middleware, manage network devices. V

7 Glosario WIND: Web Interface for Network Devices. XML: Extensible Markup Language. STOMP: Simple Text Oriented Message Protocol. HTTP: Hyper Text Trasfer Protocol. HTML: HyperText Markup Language. TCP: Transmission Control Protocol. PHP: PHP Hypertext Preprocessor. SOAP: Simple Object Access Protocol. JMS: Java Message Service. ActiveMQ: Active Message Queue. Servidor Apache: Servicio contenedor de documentos HTML para su entrega mediante requerimientos realizados con el protocolo HTTP. API: Application Programming Interface. UML: Unified Modeling Language.

8 Índice general Resumen Abstract Glosario II IV VI 1. Introducción Equipos que operan en una red de computadores Problema Propuesta WIND - Web Interface for Network Devices Esquema básico de la solución Estado del Arte Herramientas de administración/control Java Device Manager Cisco Security Device Manager (SDM) Herramientas de administración Tecnologías Involucradas Servidor de aplicaciones HTTP Apache Framework Jquery/JQueryUI/Jquery Mobile Middlewares y servidores de aplicaciones ActiveMQ - Un Middleware Orientado a Mensajes Bibliotecas y Frameworks necesarios Virtualización Dynamips/Dynagen Tunctl - UML Utilities VII

9 Índice general (Índice general) 4. Diseño de la Solución Arquitectura Protocolos Protocolo Telnet Protocolo SOAP Protocolos Openwire y STOMP Implementación Comunicación entre Procesos Funcionamiento de los procesos Wind y Agente en la arquitectura Generación de requerimientos por parte del servidor web Verificación de resultados y objetivos Middleware Soporte de equipos y caso de uso Conclusiones y Trabajo Futuro Conclusiones Trabajo Futuro Referencias 47 A. Arranque de la Plataforma WIND 49 A.1. Servidor Apache A.2. Middleware Apache ActiveMQ B. Instalación de bibliotecas y equipos de prueba 51 B.1. Agregando extención STOMP a PHP B.2. Virtualización de equipos CISCO C. Configuraciones Especiales 53 C.1. Archivo de configuración ActiveMQ C.2. Configuración de Routers Virtualizados VIII

10 Índice de figuras 1.1. Modelo ISO/OSI. Capas de red en que operan los dispositivos Diseño del logotipo de la aplicación Diagrama básico de la solución Screenshot del programa Java Device Manager Screenshot del programa Cisco Security Device Manager Taxonomía de un Middleware Logotipo del Middleware ActiveMQ Consola web ActiveMQ Ejemplo genérico. Cuatro subredes conectadas mediante un bridge Escenario de pruebas usando las tecnologías descritas Arquitectura detallada de la solución propuesta Estructura de un mensaje SOAP Ejemplo de un requerimiento SOAP Ejemplo de una respuesta SOAP ante la request enviada Ejemplo ilustrativo de un proceso Wind creando cola de mensajes en el broker Ejemplo de mensaje SOAP recibido en la cola Estructura XML IX

11 Índice de figuras (Índice de figuras) 5.4. Mensaje SOAP para solicitud de colas de tipo Routers Escritorio servidor Wind Ubuntu Protocolos conectores STOMP y Openwire Consola web ActiveMQ Portal interfaz web Wind para la selección de tipos de equipos Lista de equipos disponibles Página de control de Router Cisco, modelo c7200, id= Pop-up de control de interfaces del Router seleccionado Configuración de la interfaz FastEthernet 1/ Ventana de Interface Status A.1. Screenshot consola Ubuntu X

12 Capítulo 1 Introducción Las redes de computadores hoy en día significan un pilar fundamental en las comunicaciones globales, y transportan ujos de información por todo el planeta. Para formar una red de computadores es necesario utilizar herramientas de hardware y software que facilitan esta labor. Las herramientas de hardware utilizadas en una red, como cualquier aparato electrónico, cuentan con una vida útil y un comportamiento que no está ajeno a las probabilidades de fallas. Es por eso que la labor de los administradores de red y los ingenieros es tan importante, ayudan a salvaguardar la salud de los equipos, la información traficada a través de ellos y además a desarrollar soluciones de tipo software que ayuden en esta tarea Equipos que operan en una red de computadores Dentro de la materia de Redes de Computadores, existe un modelo descriptivo, organizado en capas, que ayuda a comprender que procesos se llevan a cabo en la comunicación entre las distintas entidades que operan en una red. Este modelo se muestra en la figura 1.1 y recibe el nombre de modelo ISO/OSI: 1

13 1.1 Equipos que operan en una red de computadores (Introducción) Figura 1.1: Modelo ISO/OSI. Capas de red en que operan los dispositivos. (Computer Networking, 6e James F. Kurose - Keith W. Ross) Dentro de la familia de dispositivos que pueden existir en una red de computadores, destacan: Routers: Los routers son elementos que permiten transportar paquetes de información a través de una red. Los routers están sujetos a algoritmos propiamente tales que le permiten dialogar con routers vecinos y determinar la ruta más adecuada para transportar la información. En el ámbito de redes, se dice que un router opera en la capa 3 del modelo OSI. Firewalls: Los cortafuegos ayudan en el ámbito de la seguridad para frenar o establecer un obstáculo ante tráfico indeseado o malicioso que intenta penetrar en la red. 2

14 1.1 Equipos que operan en una red de computadores (Introducción) Hub: Los HUB son dispositivos que se asemejan a un splitter de corriente, es decir, replican el tráfico entrante en todas sus salidas (broadcast). Switches: Los switches permiten extender la red mediante la conmutación de paquetes. Similar a un HUB pero inteligente, ya que reconoce direcciones MAC y por lo tanto puede tomar la decisión de puertos de salida (no broadcast). Opera en capa de enlace del modelo OSI (aunque también existen los switches de capa 3). Servers: Los servidores poseen variadas funciones, entre muchas otras, la función de alojar la información de la red. En el universo de la administración de redes, hay ciertos elementos que hay que tener en cuenta a la hora de operar con estos dispositivos, por ejemplo, todos los dispositivos de red pertenecen a un fabricante que implementa sus funcionalidades de acuerdo a los estándares propietarios de la empresa donde se fabricaron. Además todos funcionan de manera diferente y por ende, se administran de una forma especial. Por ello muchas veces se requiere de capacitaciones especiales para los trabajadores que operan con ellas, lo cual converge a una necesidad de homogeneidad de las interfaces de control de los dispositivos. Todos los dispositivos de red requieren en algún momento de la atención presencial y no remota del administrador de red, y esto es algo inevitable. Los dispositivos están vinculados con entidades tanto de software como de hardware, y además otros elementos físicos como por ejemplo, los cables de par trenzado. Existen herramientas web que usualmente son utilizadas para administrar los equipos de red. 3

15 1.2 Problema (Introducción) 1.2. Problema Para operar con equipos de red, ya sean routers, firewalls o servidores entre otros, es necesario tener conocimientos previos y especializados, ya que al no existir un estándar de configuración, cada fabricante diseña arquitecturas y comandos de manera distinta para operar los equipos. Generalmente estos comandos de configuración para cada equipo son ingresados a través de una linea de comandos o bien cada equipo cuenta con una interfaz gráfica propia de configuración, o una solución de software que permita conectarse a esa máquina para poder configurarla de manera sencilla, soluciones que suelen funcionar solo para ese modelo o fabricante en particular. Las empresas desarrolladoras de equipos de red como por ejemplo Cisco, suelen adaptar sus productos y tecnologías a los nuevos requerimientos tanto de los usuarios como de las empresas que proveen servicios (VTR, Claro, Entel, etc.). Los sistemas de configuración de los equipos Cisco cambian de acuerdo a estos requerimientos, por lo que un determinado modelo Cisco no necesariamente dispone del mismo esquema sintáctico para configurarse como modelos anteriores o posteriores a él. Resumiendo, los problemas detectados y como se enfrenta el problema de configuración son: 1. No Existe un estándar de configuración para los equipos de diferentes fabricantes, lo cual requiere conocimientos especializados para configurar equipos de un fabricante determinado. 2. La falta de uniformidad en los comandos para gestionar equipos de un mismo fabri- 4

16 1.3 Propuesta (Introducción) cante pero con distintas versiones de sistema operativo. 3. Usualmente la terminal de configuración de lo equipos es a través de un CLI ( Command line interface ), lo cual para usuarios más inexpertos pueda resultar engorroso de operar. 4. Las soluciones orientadas a la configuración de equipos de red basadas en interfaces gráficas actuales no funcionan para todos los fabricantes de equipos Propuesta Se propone diseñar una plataforma web, en la cual se puedan agregar equipos de red de distintos modelos y fabricantes, y configurarlos a través de una interfaz visual, que sea visible tanto desde un computador de escritorio, como desde un dispositivo móvil, como un smartphone o tablet. La idea de esto es unificar la forma en la que el usuario configura los equipos, y abre las puertas para que un usuario con menor conocimiento de equipos de un fabricante determinado pueda configurarlos de la misma manera que los demás. Además de esto, facilitar el trabajo para los administradores más experimentados agregando la comodidad de poder configurar estos dispositivos sin tener que estar conectándose a la consola de control de cada equipo, y utilizando aparatos que no requieran del uso de cables, un ejemplo de ello, configurar un set o rack de equipos a través de la pantalla de un ipad o iphone WIND - Web Interface for Network Devices WIND ( Web Interface for Network Devices ) es el nombre de la aplicación propuesta que pretende unificar los estilos de configuración y monitoreo de equipos de red. 5

17 1.3 Propuesta (Introducción) Figura 1.2: Diseño del logotipo de la aplicación ( Creado usando el programa Inkscape en Ubuntu ) La versión preliminar que se pretende generar dispone de algunas pocas opciones genéricas de configuración para 2 modelos de equipos de red, con una arquitectura basada en un middleware orientado a mensajes, aplicación web basado en html-javascript-php para la vista y la generación de requerimientos por parte del usuario cliente, aplicaciones java de bajo nivel para manejar las peticiones del usuario, la conexión con los equipos de red que se quieren administrar y la interpretación de los requerimientos generados por el usuario para traducirlos a comandos y acciones sobre estos equipos Esquema básico de la solución La arquitectura básica de la solución es mostrada en la figura 1.3: Figura 1.3: Diagrama básico de la solución. 6

18 1.3 Propuesta (Introducción) Para la realización de este proyecto se estudiaron las siguientes tecnologías de las cuales se darán detalles más adelante: ActiveMQ: Message Broker que permite la comunicación de procesos mediante mensajes de texto. JqueryMobile: Framework para aplicaciones web javascript para equipos móviles y de escritorio. Dynagen/Dynamips: Simulador de escenarios y equipos de red Cisco. Bibliotecas de Java para soporte de comunicaciones con ActiveMQ. Bibliotecas de Java Commons para el soporte de variados protocolos de red (Telnet). Protocolos SOAP, Telnet, OpenWire, STOMP. Otro de los puntos que ataca esta propuesta, es crear un producto que sea lo suficientemente modular para que pueda ser reutilizado usando la misma lógica para administrar otro tipo de dispositivos o para usarse en otro tipo de negocios, como por ejemplo: Redes de sensores Aprovisionamiento de usuarios Domótica GUI's Web de diversos programas ( Ej: GUI Matlab Web ) etc. 7

19 Capítulo 2 Estado del Arte Actualmente en Chile y el mundo existen herramientas de administración de equipos de red pagados y open-source. Todos son instalables y algunos están integrados en los mismos equipos Herramientas de administración/control A continuación se mostraran algunas herramientas que ofrecen soluciones de administración/control y bajo que condiciones opera según cada fabricante Java Device Manager Controlador y gestionador de dispositivos de red. Este software open-source facilita la configuración de equipos NORTEL para que el usuario no tenga que lidiar con el terminal del mismo. Hasta donde se sabe esta aplicación no tiene soporte web, y requiere de su instalación en Microsoft Windows. 8

20 2.1 Herramientas de administración/control (Estado del Arte) Figura 2.1: Screenshot del programa Java Device Manager Cisco Security Device Manager (SDM) SDM es la herramienta desarrollada por Cisco, que cumple exactamente con los puntos que ataca este proyecto, pero solamente para sus equipos. Es un applet accesible a través del navegador. Actualmente viene instalado por defecto en los equipos nuevos de Cisco. Ofrece una alta capacidad de configuración para los equipos, como por ejemplo, las configuraciones de interfaces de red. Figura 2.2: Screenshot del programa Cisco Security Device Manager. 9

21 2.2 Herramientas de administración (Estado del Arte) 2.2. Herramientas de administración Otras herramientas destacadas que se alejan del objetivo principal del proyecto pero que también cumplen rol de administración a través de la web son: Nagios: Sistema de monitorización muy potente que permite identificar problemas tanto de hardware como de software. Permite detectar problemas para así mitigar los efectos que pueda tener dentro de una empresa u organización. Suele utilizarse para administrar la salud de los equipos de red. PRTG - Paessler Router Traffic Grapher : Software que permite la monitorización de redes de manera segura y permite controlar tráficos de entrada y salida de diferentes dispositivos de red que soporte protocolo SNMP. Dentro de las posibilidades destaca la integración de datos históricos para realizar análisis de ancho de banda durante días, semanas o años entre otros. Actualmente PRTG es pagado y también cuenta con una aplicación para dispositivos móviles. Cacti: Cacti es una aplicación web escrita en PHP. Permite el despliegue de gráficos en tiempo real, y está orientado al monitoreo del estado de equipos (temperatura, voltaje, velocidad, tráfico, etc.). Pandora FMS: Otro software de código abierto para monitorizar sistemas, aplicaciones y servicios. También tiene soporte de base de datos para realizar análisis históricos. En las últimas versiones se incluyeron soportes y consolas web para Smartphones. Con respecto a todo lo mencionado y a las tecnologías existentes, lo que este proyecto intenta agregar es el concepto de control a través de una interfaz cómoda y minimalista, que unifique los estilos de configuración de los equipos de red independiente de la marca/- modelo y de la sintaxis de configuración que esto conlleva, ofreciendo opciones básicas 10

22 2.2 Herramientas de administración (Estado del Arte) que sean comunes para todos los equipos, y en la medida que el usuario requiera nuevas funcionalidades éstas puedan ser agregadas sin necesidad de crear una nueva aplicación, manteniendo la plataforma. Además, se busca que la arquitectura de la plataforma Wind permita agregar nuevos equipos a la lista de configuraciones junto con los que ya se encuentran en el sistema, sin la necesidad de detener la plataforma. 11

23 Capítulo 3 Tecnologías Involucradas 3.1. Servidor de aplicaciones HTTP Apache El servidor apache es una tecnología de código abierto para las plataformas Unix, Microsoft Windows y Macintosh entre otras que implementa protocolo HTTP. Apache es utilizado principalmente para el envío de páginas web a través de Internet en caso de recibir peticiones de documentos HTML que aloja en su servidor. Apache suele estar integrado a otras tecnologías. Una de estas integraciones es conocida como LAMP: Linux: Plataforma/Sistema operativo. Apache: Servidor Web. Mysql: Gestor de base de datos. Php: Lenguajes de programación. 12

24 3.2 Framework Jquery/JQueryUI/Jquery Mobile (Tecnologías Involucradas) 3.2. Framework Jquery/JQueryUI/Jquery Mobile Jquery es un framework javascript 1 que ofrece una API completa que simplifica enormemente el desarrollo de aplicaciones web. Ofrece dentro de otras opciones, el manejo de estilos dinámicos, generación de contenido dinámico a través de ajax y mucho más. Además de esto, Jquery-UI utiliza las potencialidades de la API de Jquery para crear interfaces visuales únicas y uidas, que sacan el mayor provecho del navegador web utilizado. Jquery Mobile es un framework de desarrollo orientado a aplicaciones web-móviles, creado a partir de los anteriores Jquery/JqueryUI. Ofrece un sistema unificado basado en HTML5 para la mayoría de las plataformas móviles existentes ( IOS, Android, BlackBerry, WindowsPhone, etc. ), es exible y ofrece elementos visuales prefabricados fácilmente modificables y una variada cantidad de funciones para manejar eventos propios de los dispositivos móviles Middlewares y servidores de aplicaciones Dentro del mundo de los servicios en materia de redes, son conocidos los servidores de aplicaciones. Los servidores de aplicaciones son una componente de una red de computadores que tiene la tarea de ejecutar ciertas aplicaciones cuando el usuario lo requiera. Un ejemplo son los comúnmente conocidos servidores web. Un servidor de aplicaciones integra en la mayoría de los casos un Middleware, un software que permite la interacción entre aplicaciones de software o hardware independientes. Los Middleware se sitúan entre la capa de aplicación y la capa de red del modelo 1 Javascript: Lenguaje de programación ejecutado del lado del cliente, a diferencia de PHP que que lo hace en el servidor 13

25 3.3 Middlewares y servidores de aplicaciones (Tecnologías Involucradas) OSI y ofrecen una abstracción de software y comunicación, lo que resulta ideal para generar soluciones distribuidas. Originalmente fue concebido para la interacción de software entre arquitecturas nuevas con otras plataformas más antiguas o entre sistemas operativos heterogéneos. Figura 3.1: Taxonomía de un Middleware. Algunos Middleware destacados dentro de la categoría de integración de la figura 3.1 son: Orientados a Procesos: Utilizan comunicación síncrona entre procesos. Opera remotamente mediante un cliente-stub y un servidor-skeleton. Básicamente, el stub encapsula el mensaje que se desea enviar al servidor, el cual contiene los parámetros con el método al cual se quiere acceder y que previamente está creado en el servidorskeleton. El skeleton desencapsula, lee los parámetros del método al cual se está invocando, realiza la petición para correr el método, acepta el resultado retornado por la función invocada y escribe el valor retornado de regreso al stub. Orientados a objetos: Este tipo de middleware es una extensión del anterior, ya que soporta comunicación asíncrona y transacciones distribuidas. Java RMI es un ejemplo, ya que permite la invocación remota de objetos contenidos en otra máquina virtual de java. Otros casos de Middleware orientados a objetos son JavaBeans, DCOM, y CORBA. 14

26 3.3 Middlewares y servidores de aplicaciones (Tecnologías Involucradas) Orientados a mensajes: Usualmente llamados MOM ( Middleware Oriented Message). En este caso la comunicación entre aplicaciones se efectúa mediante publicación/- subscripción de mensajes. Un cliente puede publicar mensajes en una cola contenida en el servidor MOM (MessageBroker). Los clientes que estén subscritos a dicha cola recibirán el mensaje enviado por el publicador. El servidor MOM se asegura de que el mensaje sea entregado a sus subscriptores, por lo que se podría ver al servidor como un cartero ActiveMQ - Un Middleware Orientado a Mensajes ActiveMQ es un broker de mensajes open source bajo la licencia de Apache. ActiveMQ fue concebido para ser multiplataforma, tanto por la parte de sistemas operativos, como de los lenguajes que puede manejar, esto implica que puede realizarse una comunicación entre procesos que fueron creados a partir de lenguajes de programación distintos u otros paradigmas. ( ej. comunicación php/java, c++/java, delphy/java, etc ). ActiveMQ permite la comunicación indirecta y asíncrona entre procesos y asegura la entrega de los mensajes, incluso, si uno de los procesos receptores no está disponible en el momento en que un mensaje les fue enviado. Figura 3.2: Logotipo del Middleware ActiveMQ. Apache ActiveMQ implementa todas las funcionalidades de JMS ( Java Message Service ), una API creada por Sun Microsystems para la utilización de colas de mensajes entre 15

27 3.3 Middlewares y servidores de aplicaciones (Tecnologías Involucradas) aplicaciones, y cumple el rol de JMS Provider, encargado de manejar las sesiones y colas creadas en este sistema. JMS implementa 2 modelos de comunicación: 1. Punto a Punto: Comunicación básica entre 2 clientes, el cliente que envía el mensaje y el que está dispuesto a recibirlo. El cliente productor envía los mensajes a una cola FIFO 2 que hace referencia al cliente consumidor. 2. Modelo Publicador/Subscriptor: Modelo enfocado a varios clientes, donde algunos clientes son publicadores de información, también llamados tópicos, y por otro lado los clientes que son consumidores de estos tópicos. A diferencia del modelo anterior, varios clientes puede consumir un tópico en particular. Similar al concepto de modelo Uno a Muchos en materia de bases de datos. ActiveMQ provee las bibliotecas necesarias para conectarse a cualquier aplicación Java y C++ a través del protocolo de conexión nativo de ActiveMQ, OpenWire. Otros clientes pueden implementar de una manera más sencilla la conexión con el middleware mediante el protocolo de conexión STOMP 3 con la limitación de que este protocolo no permite la utilización de todas las potencialidades que Openwire ofrece, solo implementa el modelo básico de creación de colas y consumidores, no es posible crear colas de mensaje temporales u otras operaciones más complejas en el broker. ActiveMQ posee una interfaz web para administrar las colas creadas en el broker, lo cual facilita el desarrollo de aplicaciones basados en clientes ActiveMQ y la depuración de los mensajes que se envían a través del broker. Entrega información detallada de cuales son las colas que actualmente tienen consumidores, cuantos mensajes han encolado y cuantos han despachado, si existen mensajes pendientes, etc. 2 First in, first out: Lógica de colas de eventos donde el primer evento en llegar, es el primero en atenderse. 3 Simple (or Streaming) Text Oriented Message Protocol 16

28 3.4 Bibliotecas y Frameworks necesarios (Tecnologías Involucradas) Figura 3.3: Consola web ActiveMQ Bibliotecas y Frameworks necesarios Para la realización de este proyecto, fueron necesarias las siguientes bibliotecas y frameworks: Bibliotecas de conexión ActiveMQ openwire-java. Bibliotecas de conexión ActiveMQ stomp-php. Bibliotecas de utilidades Apache-Commons ( necesario para la utilización de funciones Telnet en java ). Bibliotecas necesarias para la utilización de Framework Jquery Mobile. Framework de programación en java NetBeans. Otras opciones y configuraciones adicionales del broker ActiveMQ se encuentran explicadas en el Anexo C. 17

29 3.5 Virtualización (Tecnologías Involucradas) 3.5. Virtualización Para la creación del proyecto fue necesario utilizar ciertas herramientas que permitieran virtualizar equipos de hardware e interfaces de red reales, de tal forma de que no se dependiera de un espacio físico de trabajo y fuera más sencilla la realización de pruebas sin causar accidentes en éstos. Durante la búsqueda de una herramienta de virtualización se encontró la existencia de 2 que, funcionando en conjunto, ofrecen la posibilidad de montar los sistemas operativos de routers Cisco, estas herramientas son Dynamips y Dynagen Dynamips/Dynagen Dynamips : Es un simulador de router Cisco creado por Christophe Fillot. Permite cargar imágenes de IOS 4 Cisco y simular su ejecución en el ordenador. Según las palabras de su propio creador, este simulador de equipos Cisco se creó con el objetivo de: Ser usado como una plataforma de formación y estudio, para lograr familiarizarse con los dispositivos de Cisco. Realizar pruebas de las características especiales de los IOS de Cisco. Comprobar configuraciones de forma rápida para implementar sin riesgos en routers reales. Evidentemente, este simulador no pretende remplazar a los enrutadores reales, pero sirve de práctica para quienes quieran rendir los exámenes de certificación CCNA/C- CNP/CCIE. 4 Cisco IOS o Internetwork Operating System, es el software que utiliza la gran mayoría de los routers y switches de Cisco. 18

30 3.5 Virtualización (Tecnologías Involucradas) Dynagen: Por otra parte, Dynagen es un front-end basado en texto que utiliza hypervisor, modo de comunicación con Dynamips. La gran utilidad de Dynagen es que permite agregar fácilmente nuevas IOS con sus configuraciones iniciales respectivas, y ofrece una sintaxis simple para interconectar routers, bridges, ethernet switches, etc. También es posible ejecutar telnet hacia los routers montados con la interfaz de dynagen Tunctl - UML Utilities Tunctl es una herramienta del paquete UML Utilities del sistema operativo Linux Ubuntu ( en otras distribuciones también está disponible ) que permite hacer bridges o puentes de red lógicos. Un bridge es un sistema de capa 2 del modelo OSI, que permite la interconexión de segmentos de red, permitiendo la transferencia de datos de una red hacia otra sin necesidad de un router. Figura 3.4: Ejemplo genérico. Cuatro subredes conectadas mediante un bridge. Opera mediante una tabla de direcciones MAC que son detectadas en cada segmento de la red dividida, y cuando uno de los nodos desea enviar un dato hacia otro nodo, el bridge copia la trama a las otras subredes, las cuales eliminan o filtran dicha trama en caso de no tener esa subred como destino. 19

31 3.5 Virtualización (Tecnologías Involucradas) Gracias a Tunctl es posible crear interfaces TUN/TAP. Éstas permiten virtualizar interfaces de red que se comportan como una tarjeta de red, permitiéndoseles asignar dirección ip y máscara de subred. Y ahora, De que nos sirve Tunctl, las interfaces virtuales y los simuladores de IOS Cisco?. Como se explicó en el punto anterior, Dynagen permite el crear una configuración de red a partir de las IOS cargadas sobre Dynamips, y también, permite realizar conexiones lógicas entre interfaces de red de los routers montados virtualmente ( para el caso de Cisco, interfaces FastEthernet/Ethernet ) y las interfaces virtuales ( TUN/TAP ) que hallamos creado en la máquina donde se esté ejecutando Dynamips/Dynagen. Gracias a todas estas herramientas y tecnologías, se dispone de todo lo necesario para realizar pruebas de conexión con equipos virtuales y el desarrollo de la aplicación propuesta. El siguiente diagrama muestra un posible escenario de pruebas, ver figura 3.5: Figura 3.5: Escenario de pruebas usando las tecnologías descritas. 20

32 3.5 Virtualización (Tecnologías Involucradas) Como muestra la figura 3.5, a través de Dynamips, se virtualizan 2 router Cisco, modelos c7200 y c3620 respectivamente, y mediante tunctl dos interfaces de red virtuales, tap0 y tap1, conectados a la interfaz f0/0 de los router por medio de una conexión lógica usando Dynagen. Junto a esto, los servicios web y el middleware ActiveMQ para la comunicación entre interfaz web y las aplicaciones a desarrollar en el proyecto. 21

33 Capítulo 4 Diseño de la Solución 4.1. Arquitectura La arquitectura Wind consta de 3 partes clave, la parte de creación de requerimientos por parte del usuario a través de la interfaz web (Capa Vista / Generación de requerimientos), la parte de procesos y equipos, y el intermediario de los mensajes entre la interfaz web y los equipos a administrar, del cual está encargado ActiveMQ (Core). La arquitectura propuesta se muestra en la figura 4.1: Figura 4.1: Arquitectura detallada de la solución propuesta. 22

34 4.1 Arquitectura (Diseño de la Solución) Los módulos involucrados en la arquitectura son: Dispositivos terminales: Son los equipos que el usuario administrador utilizara para el control de los equipos de red. Pueden ser dispositivos móviles y equipos de escritorio, como un computador personal, pc, notebooks, smarthphones, etc. Servidor Apache: Encargado de alojar la interfaz web y todo lo relacionado con capa vista. Incluye módulos para la creación de mensajes y conexión con ActiveMQ. ActiveMQ Message Broker: A grandes rasgos, ActiveMQ es un intermediario entre la interfaz visual web y los equipos de red. El análogo de ActiveMQ es un cartero, acumula cartas con mensajes y los envía a los destinatarios que corresponda. Agente: Proceso encargado de informar qué equipos y servicios de red se encuentran disponibles actualmente en el sistema. Procesos Wind: Desde una perspectiva de alto nivel, un proceso Wind es el representante de un equipo de red. Por lo cual se entiende que por cada equipo nuevo que se quiera integrar al sistema, existirá un nuevo proceso Wind. Además tienen la tarea de interpretar todos los mensajes que tengan como destino el equipo del cual son representantes y comunicarle el mensaje que fue recibido en un lenguaje que ellos entiendan. Equipos: Son los componentes de red que se desean administrar y controlar. Esta arquitectura tiene la característica de que permite agregar nuevos equipos sin necesidad de detener el funcionamiento de los que ya se encuentran integrados en la plataforma web de configuración, ya que funcionan de manera independiente y dependen solamente del intermediario de mensajes ActiveMQ. 23

35 4.2 Protocolos (Diseño de la Solución) Los detalles sobre la comunicación entre ActiveMQ y los distintos procesos involucrados se encuentran explicados a más bajo nivel en el capítulo Protocolos Para poder llevar a cabo la comunicación entre distintos dispositivos y procesos que se ejecutan en la arquitectura de la solución, es necesario tener claro el concepto de protocolo. Protocolo de comunicación es un conjunto de reglas y secuencias de mensajería que se lleva a cabo para entablar una relación entre entidades que, en este caso conforman una red. Como es de esperar, para poder llevar a cabo esta propuesta, es necesario establecer qué reglas y métodos de comunicación, asociadas a un protocolo, son necesarios para hacer que el sistema ofrezca una modularidad tal que permita integrar dispositivos de cualquier tipo Protocolo Telnet Telnet es un protocolo que permite a los usuarios acceder a dispositivos de forma remota usando conexión TCP. Se encuentra estandarizado a través de la norma RFC Telnet se basa en el concepto de Terminal Virtual de Red (NVT, Network Virtual Terminal), que es un dispositivo imaginario que ofrece una representación intermedia de un terminal, que tiene el objetivo de eliminar la necesidad ( tanto de parte del usuario cliente que desea entablar la comunicación, como del servidor que se desea controlar y que proporciona el servicio de conexión ) de guardar información de las características del terminal y las convenciones asociadas a su manejo. 24

36 4.2 Protocolos (Diseño de la Solución) Para poder utilizar Telnet en la consola de comandos, se utiliza Telnet seguido de la dirección ip de la máquina con la cual se desea trabajar. Se recomienda utilizar Telnet solo en ambientes locales, ya que la información enviada por la red no es encriptada y viajan como texto plano. En la arquitectura de la solución, se utiliza el protocolo Telnet para comunicar los procesos Wind y los equipos de red que se desean administrar localmente Protocolo SOAP El protocolo SOAP ( Protocolo simple de acceso a objetos ) es un protocolo estándar auspiciado por la w3c. SOAP está basado en XML, y fue concebido para el intercambio de objetos estructurados en arquitecturas distribuidas a través de cualquier protocolo de transporte ( como por ejemplo HTML, SMTP, JMS, etc ). SOAP es un protocolo derivado de XML-RPC, protocolo de llamados a procedimientos remotos. SOAP fue diseñado para entregar información minuciosa acerca de qué se está enviando, en cambio XML-RPC, fue diseñado para ser sencillo pero lo hace menos dúctil. Por dar un ejemplo, SOAP admite entre otras cosas, el tipo de codificación de caracteres ( UTF-8, UTF-16, etc ). El mensaje SOAP se estructura en base a 3 elementos básicos, SOAP Envelop, SOAP Header, SOAP Body, ver figura 4.2: 25

37 4.2 Protocolos (Diseño de la Solución) Figura 4.2: Estructura de un mensaje SOAP. SOAP Envelope : Es la envoltura del mensaje ( sobre ). Todos los mensajes parten desde este elemento raíz. SOAP Header: La cabecera del mensaje, usado para enviar información adicional sobre el contenido del mensaje (tipos de datos definidos por la aplicación entre otros). Su uso no es obligatorio. SOAP Body: Es el cuerpo del mensaje que contiene lo que se desea enviar. Un ejemplo de mensajería SOAP se muestra en la figura 4.3 (en este ejemplo el header fue omitido): Figura 4.3: Ejemplo de un requerimiento SOAP. 26