Servicios personalizados
Español (pdf)
Articulo en XML
Referencias del artículo
Enviar articulo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
La gestión es considerada por algunos investigadores como un área prescindible de las redes, por desconocer que la calidad y el buen funcionamiento de los servicios ofrecidos a través de una red de telecomunicaciones dependen de la misma. Esto responde a que el objetivo de la gestión es mejorar la disponibilidad y rendimiento de las redes e incrementar su efectividad, lográndose una mayor productividad en la organización y un aumento de la satisfacción de los usuarios [1].
En la actualidad, una amplia variedad de sectores soporta sus procesos sustantivos en las tecnologías de la información (IT, Information Technologies), tales como los bancarios, la salud, el comercio y otros, imponiendo como requerimiento a las redes y servicios: alta eficiencia, disponibilidad y seguridad. Estas características solo pueden ser alcanzadas a través de una gestión organizada y robusta.
La gestión, al igual que las redes, ha evolucionado con el tiempo. La primera etapa se conoce como gestión autónoma, presente en las primeras redes en las que existían pocos nodos y cada nodo tenía su propio sistema de gestión local [2]. Con el crecimiento de las redes esta estrategia resultó insostenible. Surge entonces la gestión homogénea en redes donde se emplean equipos y protocolos de un mismo fabricante [3]. Posterior a esta, y debido a la incorporación en las redes de una amplia variedad de tecnologías, que hacen que en una misma red se puedan encontrar diversos recursos de diferentes fabricantes que pueden interoperar entre sí; la gestión entra en una fase conocida como gestión heterogénea [2, 4].
De esta manera se puede afirmar que la gestión de redes en ambientes multiproveedores y multitecnologías se ve afectada por las limitaciones de la gestión heterogénea, necesitándose una gestión normalizada o integrada [5]. Esta es obstaculizada por la presencia de múltiples formas de integración incompatibles entre sí.
Una posible solución de integración podría ser el empleo de APIs (Interfaces de Programación de Aplicación, Application Programming Interfaces, por sus siglas en inglés), con el fin de lograr que la información de gestión que ofrecen los diferentes sistemas gestores pueda ser integrada en una aplicación única. Las APIs son mucho más que una herramienta tecnológica: son sobretodo un vehículo de comunicación entre aplicaciones. Existe una amplia variedad de APIs en el mercado con disímiles funciones [6].
Las grandes empresas del mundo dan servicio en sus plataformas a terceras compañías a través de APIs. En el campo de los datos y los servicios, las APIs se han convertido en una herramienta esencial para la integración de la infraestructura, el intercambio de información y la aplicación de funcionalidades a los productos finales [7].
Dada la amplia gama de APIs que existen y las singularidades de los diversos entornos de red, realizar un proyecto de integración de gestión mediante el empleo de estas se convierte en una tarea compleja en la mayoría de los casos. De esta manera, se evidencia la necesidad de desarrollar una guía o procedimiento que facilite el diseño y despliegue de un proyecto de este tipo.
Las APIS
Una API especifica cómo deberían interactuar los diferentes componentes software. Además de facilitar el acceso a componentes hardware y a bases de datos, una API puede utilizarse para facilitar el trabajo de desarrollo. En la práctica, las APIs a menudo incluyen dentro de sus librerías especificaciones para manejar subrutinas, tipos de datos, clases y variables. En algunos casos, especialmente en servicios web, una API es únicamente una especificación para que los usuarios remotos puedan consumir los servicios [8].
Sería complicado entender el verdadero valor de las APIs para una empresa solo como un vehículo de comunicación entre aplicaciones. Esto es, las APIs entendidas como herramientas para llevar datos de una aplicación a otra, necesaria para que la segunda pueda funcionar [6].
Existe en el mercado una amplia gama de APIs, pero es necesario seleccionar adecuadamente la que se debe usar acorde con el entorno donde va a ser implementada. Aunque generalmente se ofrece una amplia documentación sobre las APIs, la forma de utilizarlas puede ser diferente por cada fabricante de sistemas gestores y, por tanto, estos no son compatibles entre sí necesitándose una aplicación que funcione como proxy.
Empleo de las apis por el tm forum
La organización internacional más importante para la gestión, TMForum, actualmente centra sus esfuerzos en un programa llamado Open API, con el objetivo de crear un conjunto de APIs comunes que permita reducir los costos de la integración de la gestión. El programa Open API ha crecido significativamente desde su inicio hace tres años y en estos momentos está firmado por 42 empresas y las API abiertas se implementan en todo el mundo [9]. Actualmente cuentan con más de 50 APIs REST para múltiples funciones, las cuales son genéricas y no solo se aplican a la industria de las telecomunicaciones [10, 11].
El propósito de TMForum con el proyecto Open APIs es:
Habilitar la agilidad empresarial.
Habilitar la asociación para nuevos servicios.
Proporcionar simplificación del estado de IT mediante la racionalización de sistemas.
Reducir el tiempo de comercialización.
Con este proyecto, TMForum está ayudando a que el negocio principal de la empresa cumpla con los requisitos de los clientes, especialmente para reducir la complejidad de sus sistemas OSS. Las API abiertas del proyecto Open API del TMForum actualmente son utilizadas por más de 700 empresas y 5400 personas.
Las empresas que son parte de este manifiesto afirman que: lo que antes era Telco ahora es IT. Las API abiertas son un requisito previo para habilitar la red de hoy y de mañana, para entregarla de manera automática y rápida, sin arriesgar la calidad y asegurar ingresos adicionales [12].
Algunas de las empresas, que utilizan las APIs abiertas del proyecto Open API están de acuerdo con el Manifiesto y han dado sus criterios sobre cómo están desarrollando sus nuevos productos digitales. Además, exponen capacidades con API diseñadas según el conjunto de Open API y los beneficios que estas aportan a su negocio. Por ejemplo: Orange [13], Amdocs [14], EXFO [12] y TEOCO [15].
Procedimiento para integrar la gestión de redes empleando apis
El procedimiento que se propone para integrar la gestión de redes empleando APIs, como se muestra en la figura 1, plantea cuatro fases:
Necesidad de integración de la gestión.
Análisis de las posibilidades de integración de la gestión empleado APIs.
Prueba.
Despliegue.
Estas fases se describen en los próximos epígrafes y deben ser desarrolladas con la mayor precisión posible, pues cada una de ellas depende significativamente de la anterior.
Fase 1 Necesidad de integración de la gestión
La primera fase del procedimiento está dividida en dos bloques fundamentales, según se muestra la figura 2: análisis de los requerimientos del negocio y los requerimientos técnicos y caracterización del escenario de integración. En ellos, una vez bien analizado el proceso para determinar la necesidad de integración de la gestión, se da paso a la siguiente fase.
Análisis de los requerimientos del negocio y los requerimientos técnicos
La gestión de redes es abarcadora y el diseño de un sistema de gestión, que incluya todas las posibilidades que esta tecnología ofrece, es un objetivo poco realista. Por tanto, definir los requerimientos de la organización en que se va a integrar la gestión es fundamental para precisar qué funciones se deben implementar, a fin de que el sistema satisfaga sus necesidades de integración de la gestión.
Siguiendo lo resumido en la figura 2, se tiene que en la caracterización del negocio de una organización se debe determinar en qué área trabaja la misma, cuáles son sus metas, quiénes son sus usuarios y qué servicios ofrece. Esta información debe contribuir a lograr una visión general de la necesidad de integrar la gestión en la organización.
Seguidamente se deben caracterizar las políticas y los recursos humanos de la organización, además de las restricciones del proyecto de integración de la gestión.
Las políticas de la organización pueden tener un impacto considerable sobre las decisiones que se tomarán en el proyecto de integración de la gestión. Puede haber predilección o rechazo a usar aplicaciones y dispositivos de un fabricante o tecnología específica, pueden existir políticas sobre los sistemas operativos empleados, las licencias de software, los estándares que se utilizarán y otros.
Analizar las características del personal que quedará al frente del sistema integrado de gestión, permitirá establecer la complejidad que el mismo puede alcanzar. Además, es imprescindible el conocimiento de dicho personal sobre la teoría detrás de la gestión de redes, pues esto les permitirá tomar mejores decisiones, detectar las causas de posibles fallos y aumentará sus posibilidades de mejorar el sistema con el paso del tiempo. El conocimiento de lenguajes de programación permite al personal de redes diseñar o modificar dichas aplicaciones para que respondan a sus necesidades. Finalmente debe tenerse en cuenta preferencias personales de gestión de los administradores, pues sentirse cómodo y conforme con las aplicaciones de gestión o sistemas gestores contribuye a un mejor desempeño del personal.
Para alcanzar los objetivos de un proyecto de integración de la gestión es imprescindible analizar el tiempo en el que este se debe desarrollar, crear un plan que delimite las tareas que se deben realizar y los períodos de tiempo asignados a cada una, el presupuesto con que se cuenta, si existe algún tipo de infraestructura de gestión sus características y otros elementos que, aunque no estén directamente relacionados con la gestión, puedan incidir en el éxito del proyecto. De esta manera se establecerán claramente los beneficios que espera la organización con el desarrollo del proyecto de integración de la gestión y se reducirán las probabilidades de fracaso al evitar que se concentren esfuerzos en funciones que, aunque pueden parecer atractivas, no son las requeridas por la organización. En resumen, un análisis previo de las características de la organización es la clave para lograr que los requerimientos de negocios expongan, desde la perspectiva de la organización, “qué” se persigue, “por qué” y qué beneficios le aportará a la organización si se logra satisfacer el requerimiento.
Por su parte, los requerimientos de la organización se plantean divididos en dos grupos fundamentales: de negocios y técnicos.
Requerimientos de negocio
Los requerimientos de negocio definen las necesidades de alto nivel de la organización y no contienen detalles sobre “cómo” darles solución. Deben expresar de forma clara “qué” resultados espera obtener la organización, y qué beneficios se alcanzarán si se logra dar cumplimiento a dichos requerimientos, lo que responde a “por qué” la organización los plantea; deben ser trazados además, desde la perspectiva de la organización y no desde la perspectiva de un empleado o grupo específico [16]. Para lograr la obtención de un conjunto de requerimientos de negocio bien definidos se debe indagar, en primer lugar, sobre las razones por las que la organización emprende un proyecto de integración de la gestión y cómo ayudará este en el desempeño de sus funciones.
Requerimientos técnicos
Los requerimientos técnicos son aquellas exigencias técnicas que deben cumplir las soluciones que se den a los requerimientos de negocio de un proyecto de integración de la gestión para satisfacer las expectativas de la organización. Algunos ejemplos de requerimientos técnicos a exigirle al sistema integrado de gestión pueden ser:
Escalabilidad: se debe tener en cuenta los planes de expansión de la organización y, por tanto, de la expansión de su red y la gestión en un futuro cercano.
Adaptabilidad: el sistema integrado de gestión debe tener la capacidad de incluir nuevas tecnologías sin necesidad de realizar cambios significativos.
Disponibilidad: relacionado con el tiempo que se encuentra el sistema integrado de gestión disponible para los operadores de la red.
Seguridad: se refiere al nivel de seguridad que debe poseer el sistema integrado de gestión.
Usabilidad: facilidad de uso del sistema integrado de gestión. Esto puede incluir la capacidad de personalizar la interfaz y modificar las funciones para adaptarlas a las necesidades del administrador.
Asequibilidad: la asequibilidad está estrechamente relacionada con el presupuesto de la organización para el proyecto de integración de la gestión.
Confiabilidad: un sistema integrado de gestión confiable debe mostrar las alertas en el momento en que están ocurriendo los problemas en la red y debe además mantenerlas mientras son válidas.
Caracterización del escenario de integración
Análisis de la red existente
La caracterización de la red existente permitirá recopilar información útil para el proyecto de integración de la gestión: estándares de gestión presente, métricas que se pueden obtener, si el sistema de gestión puede ser centralizado o distribuido y otros aspectos de suma importancia para el proyecto. La figura 3 resume el proceso de caracterización del escenario de integración de la gestión, cuyos bloques se explican a continuación.
Análisis de las características de la red
El análisis de la red existente permite conocer la cantidad de elementos de red y servidores que posee la misma, qué tecnología emplean, de qué fabricante son, qué protocolos utilizan, cómo funciona la red, qué estructura tiene, cuántos son y dónde se ubican los usuarios, en qué lugar se encuentran los puntos más sensibles, dónde se concentra la mayor cantidad de tráfico y otros aspectos que servirán para determinar qué equipos e interfaces son de mayor importancia para el negocio de la organización.
Análisis de los servicios críticos de la organización
Determinar los servicios críticos para la organización ayuda a precisar las funciones que debe cumplir el sistema integrado de gestión. De ser necesario, para determinar los servicios críticos se podría elaborar una tabla en la que se recojan los servicios de red de la organización, las pérdidas económicas por cada hora que un servicio de la red no esté disponible, así como otras posibles consecuencias.
Requerimientos de red de los servicios críticos
Una vez que se han determinado los servicios críticos para la organización se debe analizar cuáles son los requerimientos que debe cumplir la red para que estos funcionen correctamente. Las funciones que debe tener el sistema integrado de gestión deben contribuir a garantizar dichos requerimientos. Por ejemplo, una organización que ofrezca servicios de VoIP (Voz sobre el Protocolo Internet, Voice over Internet Protocol, por sus siglas en inglés) requiere que su red posea una latencia menor que 300 ms y jitter menor que 100 ms. Por tanto, sería necesario monitorear ambos parámetros para asegurar que el servicio se ofrece con la calidad requerida.
Análisis del sistema de gestión existente
Análisis de las posibilidades de gestión de los equipos de la red
Para emprender el proyecto de integración de la gestión se deben analizar en los elementos de red las formas de gestión que soportan. O sea, los protocolos y modelos de información de gestión que poseen, ya sean propietarios o no. Para facilitar esta tarea se recomienda emplear tablas con los siguientes parámetros:
Versión del sistema operativo: en muchas ocasiones, el firmware del equipo define qué funcionalidades de gestión soporta. Puede darse el caso que en una versión no soporte algunas funcionalidades y una versión más actualizada sí.
Formas de gestión: En este punto se puede analizar si el equipo posee las siguientes características:
SNMP v1, v2, v3.
SYSLOG.
HTTP.
HTTPS (Protocolo Seguro de Transferencia de Hipertexto, Hypertext Transfer Protocol Secure, por sus siglas en inglés).
Telnet.
SSH (Intérprete de Órdenes Segura, Secure Shell, por sus siglas en inglés).
FTP (Protocolo de Transferencia de Archivos, File Transfer Protocol, por sus siglas en inglés).
SFTP (Protocolo Seguro de Transferencia de Archivos, Secure File Transfer Protocol, por sus siglas en inglés).
TFTP (Protocolo de Transferencia de Archivos Trivial, Trivial File Transfer Protocol, por sus siglas en inglés).
Protocolos propietarios de gestión.
Otras opciones de gestión.
Análisis de los sistemas gestores
Para realizar la caracterización del sistema de gestión existente en la organización, se deben analizar los sistemas gestores que posee y para qué se utilizan. En este punto no es necesario analizar a fondo todas las funcionalidades que ofrecen los sistemas gestores, sino cuáles se están empleando. Debe analizarse también el nivel de integración existente entre los sistemas gestores que se emplean, además, de analizar los procedimientos y procesos que emplea la organización.
Es importante que este paso no se omita, pues es posible que la solución que resulte de la aplicación del procedimiento que se propone en este capítulo, emplee parte del sistema implementado, lo cual puede ser una ventaja para muchas organizaciones que tienen vasta experiencia con algunos sistemas gestores. Además, este paso define si la gestión de la red es heterogénea o no y por consiguiente la necesidad o no de un realizar un proyecto de integración de la gestión.
Fase 2 análisis de las posibilidades de integración de la gestión empleado apis
Una vez identificada la necesidad de integración de la gestión en una organización, es preciso analizar la posibilidad de realizar la integración de la gestión empleando APIs.
Esta fase, al igual que la anterior, está dividida en dos bloques (ver figura 1): análisis de las APIs que poseen los sistemas gestores y definición de la aplicación integradora de gestión; que definirán de manera clara y precisa, a partir de un profundo análisis, las posibilidades que tiene la organización, de poder integrar la gestión empleando APIs.
Análisis de las APIs que poseen los sistemas gestores existentes
En este punto se deben estudiar a profundidad las características de los sistemas gestores, esencialmente, la existencia de APIs hacia al norte que posean o cualquier otra vía de cómo exportar la información de gestión. Una vez realizado esto, se debe analizar si la información de gestión que brindan los sistemas gestores a integrar es útil para realizar la integración mediante el empleo de las APIs. La figura 4 resume el proceso.
Para facilitar la tarea de estudio profundo de las características de los sistemas gestores, se recomienda tener en cuenta los siguientes parámetros:
Tipo de licencia.
Arquitectura.
Tipo de aplicación y sistema operativo con los que trabaja.
Mecanismos de comunicación y/o transferencia de datos.
Tecnología de la base de datos (BD, Database por sus siglas en inglés) que posee.
Si posee APIs hacia el norte y sus características.
Formas de exportar la información de gestión con vista a lograr una futura integración.
El análisis de la información de gestión que manejan las APIs de los sistemas gestores, permite determinar si la misma es útil para realizar la integración de la gestión. Para determinar esto se deben tener en cuenta los requerimientos técnicos definidos por la organización al iniciar el proyecto.
Además, para determinar si existen condiciones para el desarrollo de una API, en caso de que el sistema no tenga una nativa, se deben analizar los recursos humanos existentes. Este proceso estará condicionado fundamentalmente por los conocimientos del personal dedicado a la gestión de las redes y por los recursos que le asigne la organización a la gestión con el fin de contratar desarrolladores.
Definición de la aplicación integradora
Una vez, determinados los sistemas gestores a integrar con sus respetivas APIs, el siguiente paso es definir la aplicación integradora. Para ello se necesita determinar la(s) vía(s) que posibilite(n) el almacenamiento en la base de datos (BD) de la información de gestión que poseen las APIs consideradas, diseñar una BD que almacene dicha información de gestión, definir las características y funcionalidades principales de la aplicación y finalmente, programar la aplicación integradora basada en la web. La figura 5 resume el proceso.
Es imprescindible la identificación de vía(s) que permita(n) almacenar en BD la información de gestión que poseen las APIs seleccionadas, dado que este proceso no ocurre de manera automática. Se recomienda el uso de scripts o plugins para así facilitar dicha problemática. En caso de no existir vías de este tipo, se puede considerar la creación de las mismas, de forma tal que estas se programen a partir del formato de la información que brindan las APIs. Para la creación de estas vías se deben determinar si existen posibilidades en cuanto a recursos humanos existentes. Este proceso estará condicionado fundamentalmente, al igual que en el desarrollo de APIs, por los conocimientos del personal dedicado a la gestión de las redes y por los recursos que le asigne la organización a la gestión con el fin de contratar desarrolladores.
Diseño de la BD integradora de gestión
En el diseño de la BD integradora de gestión se debe tener en cuenta la estructura de la información de gestión que brindan las APIs de los sistemas gestores a integrar, la cual se debe normalizar en un diseño único. Además, se debe tener en cuenta la definición de una estructura óptima para la relación de las tablas, de forma tal que se logre:
Almacenar la información de gestión.
Tener en cuenta los elementos fundamentales de la aplicación integradora de gestión (alarmas, incidencias, etc.).
Normalizar la información que se recibe a través de las APIs.
Para el diseño de la BD integradora de gestión sería recomendable seguir lo establecido al respecto y una vez normalizados los datos se debe seleccionar la tecnología para la implementación del diseño, o sea, seleccionar el gestor de base de datos que mejor se ajuste a la estructura de la información que se recibe a través de las APIs y al tipo de información, que sea fácil de usar, que le aporte seguridad a la información, que los módulos disponibles en el mismo cumplan con los requisitos del negocio, que tenga capacidad de integración, que sea escalable y que el costo sea el más adecuado para la organización.
Definición de las características y funcionalidades principales de la aplicación integradora de gestión
En este paso del procedimiento para establecer las características y funciones que debe poseer la aplicación integradora de gestión, se deben tener en cuenta los requerimientos técnicos definidos en la primera fase del mismo.
Primeramente, es necesario definir un grupo de características claves para la aplicación integradora de gestión. Estas características tendrán un impacto directo sobre el tráfico de información de gestión y en la forma de llevar a cabo gestión en general. Algunas de estas características son: gestión proactiva o reactiva, gestión en banda o fuera de banda, gestión centralizada o distribuida.
Por otra parte, se deben especificar las funciones que debe implementar la aplicación integradora de gestión considerando las cinco áreas funcionales. Es necesario asegurarse de que las funciones seleccionadas respondan a los requerimientos del negocio, de lo contrario se perderán tiempo y recursos en funciones que no ayudarán a cumplir las metas propuestas.
Es muy importante establecer qué funciones de gestión necesitan integrarse y qué alcance debe tener dicha integración, creando una lista en orden de prioridad con las características que se desean lograr. En el transcurso del proceso de integración, las necesidades de integración de la gestión pueden cambiar, causando la adición, modificación o eliminación de aspectos en la lista, por lo que es muy probable que nunca se satisfagan las necesidades de menor prioridad. Sin embargo, se logrará un sistema de gestión con un nivel de integración aceptable capaz de cubrir los requerimientos planteados. Por ejemplo, algunos de los aspectos de la lista pueden ser:
Mapa topológico y la gestión de alarmas a nivel de red, todo desde una misma interfaz.
Acceso a las herramientas básicas de diagnósticos (ping, traceroute, etc.) desde el mapa topológico.
De esta manera se puede definir qué es lo más importante a integrar para satisfacer los requerimientos de la organización, a la vez que se controlan los costos y la complejidad del proceso de integración.
Selección de marco de desarrollo de la aplicación integradora de gestión
En este paso se deben revisar diferentes marcos de desarrollo para seleccionar el que se va a emplear en el esquema de la aplicación integradora de gestión. Además, se debe tener en cuenta la compatibilidad del marco con el gestor de la base de datos integradora diseñada. En la tabla 1 se muestran ejemplos de marcos de desarrollo y su compatibilidad con gestores de BD.
Tabla 1 Ejemplos de compatibilidad entre marco de desarrollo y gestores de base de datos [Desarrollo propio]
| No. | Marco de desarrollo | Gestor de base de datos |
|---|---|---|
| 1 | Symfony | My SQL |
| 2 | Django | Postgre SQL My SQL Oracle SQLite |
| 3 | APEX | Oracle |
| 4 | Signum | MS SQL Server |
| 5 | Drupal | SQLite |
Programar la aplicación integradora de gestión
Una vez seleccionado el marco de desarrollo y teniendo en cuenta las características y funcionalidades definidas para la aplicación integradora de gestión, se debe pasar a la programación de la misma. Para ello se precisa:
Instalar el diseño de la BD integradora en el gestor de base de datos o en el propio marco de desarrollo, si este tiene posibilidades para ello.
Habilitar en los sistemas gestores a integrar las APIs a utilizar. Además, habilitar en la aplicación integradora la conexión con dichas APIs. Las APIs que se puedan utilizar en la integración de la gestión definen las funcionalidades de gestión de la aplicación integradora.
Definir las vistas para el diseño gráfico, que sean amigables y entendibles para el usuario final.
Desarrollar la forma en que se mostrará la información estadística de gestión.
Definir el empleo de herramientas para realizar búsquedas avanzadas dentro del sistema, teniendo en cuenta las facilidades que pudiera brindar el marco de desarrollo.
Definir los niveles de acceso a la aplicación integradora de gestión y los roles para asignar permisos a las vistas del diseño gráfico, así como a las funcionalidades.
Fase 3 Prueba
Una vez seleccionadas las APIs a considerar para el proyecto de integración de la gestión y programada la aplicación integradora, es necesario entrar en la fase de prueba. La figura 6 muestra de manera explícita el proceso.
Esta fase contiene un solo bloque (ver figura 1): realizar pruebas a nivel de laboratorio y/o piloto. Esto determinará, a partir de la obtención de los resultados exitosos o no de la(s) prueba(s), si el sistema integrado de gestión está en condiciones para pasar a la siguiente fase de despliegue.
Las pruebas a nivel de laboratorio y/o piloto se deben realizar en redes simuladas y/o en redes reales aisladas de la red de la organización, respectivamente. La prueba piloto, a diferencia la de laboratorio, consiste en emplear la aplicación integradora para gestionar una parte de la red de la organización. Su objetivo es realizar pruebas en un ambiente más cercano a la realidad.
Fase 4 Despliegue
Una vez obtenidos resultados exitosos en realizadas las pruebas realizadas a nivel de laboratorio y/o piloto, se da paso a la fase de despliegue. La figura 6 resume el proceso.
Esta fase, está dividida en dos bloques (ver figura 1): despliegue del sistema y corrección de errores y optimización. A partir de los resultados exitosos o no del despliegue del sistema integrado de gestión se deberá dictaminar si el proyecto cumplió o no con los requerimientos técnicos y de negocio de la organización.
Despliegue del sistema y corrección de errores
En este punto del procedimiento para integrar la gestión empleando APIs, se debe pasar a gestionar toda la red de la organización con la solución integrada de gestión y verificar que la misma es capaz de satisfacer los requerimientos técnicos y de negocio de la organización.
En caso de presentase alguna dificultad en el despliegue del sistema, se debe revisar exhaustivamente la correcta instalación y configuración de los elementos que componen la aplicación integradora de gestión.
Optimización
Finalmente, después de lograr el despliegue completo del sistema integrado de gestión, se debe continuar con el proceso de optimización del mismo, para con ello, mantener y perfeccionar el nivel de integración obtenido.
Validación del procedimiento
El procedimiento para realizar integración de la gestión de redes empleando APIs presentado a través de su aplicación en una entidad, la cual se encarga de mantener y gestionar una red que ofrece conectividad a nivel nacional.
Se desarrollaron para dicha entidad, cada una de las fases del procedimiento que se propone. De manera tal que, se determinó de la fase 1 la necesidad de realizar un proyecto de integración de la gestión. Seguidamente, se concluyó de la fase 2 el análisis de las APIs que poseen los sistemas gestores y la definición de la aplicación integradora.
Una vez programada la aplicación integradora y listos los elementos que componen el sistema integrado de gestión, se da paso a la fase 3: prueba.
En este caso, no se realizaron pruebas a nivel de laboratorio debido a que la entidad no contaba con los recursos necesarios para simular. No obstante, realizar la prueba piloto, permite obtener resultados más cercanos a la realidad.
Prueba piloto en un entorno controlado de la entidad
Para llevar a cabo la prueba piloto en la entidad se utilizó un entorno de red controlado, formado por elementos reales y virtuales, con el objetivo de verificar si las funcionalidades del sistema integrado de gestión diseñado eran capaces de dar respuesta a los requerimientos de negocio y técnicos planteados por la entidad.
El escenario de prueba cuenta con dos máquinas virtuales en las cuales se instalaron los sistemas gestores: iManager U2000 en el SO Windows Server 2003 y Check_MK OMD versión Raw 1.2.8p27 en el SO Debian 7. Además, posee un servidor físico en el cual se instaló la aplicación integradora sobre el SO Oracle Linux Server 6.5, el cual trae implícito en su paquete de instalación el gestor de base de datos Oracle en su versión 11g release 1. En este se instaló y configuró el marco de desarrollo APEX versión 18.1.0, creando un espacio de trabajo para la prueba nombrado SISTEC_LITE.
Además, se utilizaron en el escenario varios equipos de la serie de Huawei y un servidor de correo HP (Hewlett-Packard, por sus siglas en inglés) que deben ser gestionados por los sistemas gestores instalados. Para obtener la información de gestión de los equipos Huawei bajo licencia, gestionados por el iManager U2000, se utilizó el protocolo SNMP a partir de MIBs privadas y se empleó el protocolo ICMP (Protocolo de Control de Mensajes de Internet, Internet Control Message Protocol, por sus siglas en inglés), para los equipos Huawei que son gestionados como si fueran de un tercero. Por otra parte, el Check_MK para obtener la información de gestión de los equipos gestionados, utilizó el protocolo SNMP a partir de las MIBs públicas con las que cuenta y empleó el agente check_mk para recolectar la información de gestión del servidor de correo. La figura 7 muestra los elementos que componen el escenario de prueba.
Una vez listos todos los elementos que componen el sistema integrado de gestión, la prueba consistió en ejecutar las vías de obtención de la información de gestión de las APIs identificadas para cada sistema gestor. De esta manera, los mecanismos de recolección de eventos de las vías llenarían los datos pertinentes a cada evento en las tablas de la BD de la aplicación integradora de gestión, como muestran los resultados siguientes:
Ejemplos de equipo (ver figura 10) y un servidor (ver figura 11) gestionados por el Check_MK con sus correspondientes servicios en la aplicación integradora de gestión.
Registro de alarmas en la aplicación integradora de gestión (ver figura 12 a partir de los estados: DOWN (de los equipos), CRITICAL y WARNING (de los servicios).
Registro de incidencias a partir de 15 minutos de creada la alarma (ver figura 13).
En la figura 8 se muestra una vista de la aplicación donde puede verse el registro de equipos. Se tiene información sobre el nombre del equipo, su tipología, dirección IP y MAC, fecha del último cambio de estado, información sobre dicho estado, el alias del equipo y su estado con respecto al sistema de gestión.
En la figura 9 puede verse un acercamiento más detallado a los datos de un equipo particular de los listados en la figura 8, en este caso gestionado por el iManager U2000.
Por otro lado, en las figuras 10 y 11 se muestran los detalles de equipos agenciados por otro gestor, el Check_MK.
La figura 12 muestra un fragmento del registro completo de alarmas del sistema donde puede conocerse el equipo y servicios donde se dio la alarma, la severidad de esta, información sobre el hecho su periodo de ocurrencia y el estado de la alarma para su gestión.
Otra vista del gestor permite conocer el registro de incidencias (ver figura 13) donde se muestra el nombre del equipo, dirección IP, nombre del servicio, severidad de la alarma e información sobre esta. Además, puede conocerse el periodo de ocurrencia y el estado de la incidencia.
Como se pudo evidenciar en las figuras, se lograron resultados exitosos en la realización de la prueba piloto. De esta manera, se pudo comprobar que las funcionalidades del sistema integrado de gestión son capaces de dar respuesta a los requerimientos planteados por la entidad, dando así, paso a la siguiente fase del procedimiento.
Una vez realizada la prueba piloto, con exitosos resultados, el sistema integrado de gestión está listo para pasar a la fase 4 y ser desplegado en el entorno real de la red de la entidad.
Despliegue del sistema en la entidad y corrección de errores
Para la realización del despliegue del sistema se tuvo en cuenta el escenario que se describe en la prueba piloto, el cual es similar al entorno real de la entidad.
El entorno de red de la entidad está compuesto por aproximadamente 700 dispositivos gestionables. Estos se interconectan empleando tecnologías de transmisión por cobre y fibra óptica, formando anillos para ofrecer redundancia. Además, lo componen servidores que hospedan sistemas ministeriales, correo electrónico y servicios de videoconferencia, entre otras aplicaciones desplegadas.
Una vez realizado el despliegue del sistema integrado de gestión e iniciada la recolección de información de gestión procedente de las APIs, se pudo comprobar que el flujo de información aumentó dado a la diversidad y cantidad de elementos a supervisar con respecto a la prueba piloto realizada. Sin embargo, el diseño de la BD y del sistema integrado de gestión propuesto, resultaron satisfactorios al asimilar y procesar el crecimiento de dicho flujo.
Además, se logró un adecuado seguimiento de incidencias en el sistema integrado de gestión, evidenciándose una disminución en los tiempos de atención a las mismas. Pues a partir de que toda la información de gestión se muestra en una sola interfaz se facilita la identificación de estas y su impacto en la red.
Otra funcionalidad que demostró su correcto funcionamiento dentro del sistema, fue la generación de reportes estadísticos. Ejemplo de ello se evidencia en los registros de: eventos y alarmas del sistema (ver figura 14), desempeño de eventos en los últimos 30 días (ver figura 15) y equipos con más alarmas (ver figura 16), entre otros.
La figura 14 muestra un reporte estadístico de eventos y alarmas del sistema como son el número total de alarmas, alarmas interfaces, alarmas ping, alarmas CPU e incidencias. Puede notarse en dicho reporte cómo se distribuyen las alarmas según su tipo en tiempo real.
La figura 15 muestra el comportamiento de estos indicadores estadísticos en los últimos 30 días de ejecución del sistema. Esta serie temporal de datos graficados de forma simultánea permite conocer los momentos de mayor/menor cantidad de alarmas e incidencias durante un mes, lo que posibilita el monitoreo en tiempo real de los eventos.
Por otro lado, la figura 16 muestra los equipos que mayor cantidad de alarmas reportan, ordenados de forma descendente. Esto permite identificar rápidamente y en tiempo real dónde se están dando la mayor cantidad de incidencias en el sistema.
Optimización del sistema desplegado en la entidad
Una vez concluido el despliegue del sistema integrado de gestión con exitosos resultados en el procedimiento recogido en este trabajo se plantea que se debe continuar hacia el proceso de optimización del mismo, con el objetivo de mantener y perfeccionar el nivel de integración obtenido.
Para ello se hizo necesario realizar un análisis de la información de gestión recolectada de los sistemas gestores, determinándose:
Conclusiones
La validación del procedimiento propuesto para la integración de la gestión empleando API demostró su agilidad y efectividad a la hora de realizar el proceso de recolección, procesamiento y atención a incidencias, utilizando los pasos del mismo. Además, el proceso de integración de la gestión en redes es complejo y se ve afectado por factores externos e internos de diversos tipos. No obstante, el procedimiento genérico propuesto permite el diseño y despliegue de sistemas integrados de gestión que puedan ajustarse a los requerimientos y características particulares de las organizaciones. Aunque el procedimiento es genérico, está limitado a las características de las organizaciones y las condiciones de infraestructura que estas presenten.
La implementación de este proceso tiene implicaciones teóricas y prácticas significativas. En términos teóricos, permitiría la integración de los distintos aspectos relativos a los servicios y aplicaciones ofertados por los sistemas de red y la gestión de las tecnologías que los sustentan. En términos prácticos, la gestión integrada resolvería los problemas de la gestión heterogénea, permitiendo la interconexión de productos heterogéneos y garantizando un nivel de servicio adecuado. Además, la gestión integrada minimizaría el tráfico de gestión de red y simplificaría los nodos gestionados.
La investigación resulta novedosa en tanto, hasta donde las autoras conocen, no se reportan en la literatura científica cubana publicaciones que propongan un procedimiento similar.
Se recomienda aplicar este procedimiento en un escenario tecnológico más complejo y evaluar el efecto antes y después de su implementación utilizando varios criterios de calidad (a determinar). Esto reflejaría la escalabilidad y flexibilidad del procedimiento.
