Sistema para la gestión en redes no comerciales de los SLA en la etapa de ejecución

SLA Management at the execution stage in non-commercial networks

Guillermo Gafas Cabrera ^I, Caridad Anías Calderón ^II

RESUMEN

Actualmente las empresas que proveen servicios de telecomunicaciones deberían establecer acuerdos de nivel de servicio con sus clientes para acordar y fijar la calidad de los servicios a ofrecer. Establecer estos acuerdos permite obtener múltiples beneficios tanto a los clientes como a los proveedores de los servicios. Existen varias iniciativas para la estandarización de los mencionados acuerdos pero estas presentan una complejidad elevada, por ello, aplicarlas en redes de entidades que ofrecen servicios de telecomunicaciones de manera no comercial resultaría complejo, además, las herramientas que permiten gestionar estos acuerdos son generalmente software propietario. En este artículo se presenta una propuesta desarrollada para ser aplicada en redes de telecomunicaciones no comerciales que permite la gestión de los acuerdos de nivel de servicio en la etapa de ejecución. Para comprobar el funcionamiento de la propuesta realizada se desarrolló un software que también se presenta.

Palabras claves: acuerdos de nivel de servicio, redes de telecomunicaciones no comerciales

ABSTRACT

At present the companies that provide telecommunications services need to establish service level agreements with customers to agree and set the quality of services to offer. To establish service level agreements allow for multiple benefits to customers and service providers. There are a lot of existing initiatives for standardization of those agreements in various scenarios, but these have a high complexity and apply them to networks of entities that provide telecommunications services in non-commercial way would be complex and the tools to manage such agreements are generally proprietary software. In this article it is established a proposal to be applied to non-commercial networks that allows to manage service level agreements at the execution stage. To check out the operation of the proposal a software was developed, that is also showed up in this article.

Key words: service level agreements, non-commercial telecommunications networks

1.- INTRODUCCIÓN

En los últimos años la variedad de servicios ofrecidos por las empresas de telecomunicaciones se ha incrementado drásticamente, haciéndose necesario una correcta gestión de los mismos para lograr, entre otros, mejorar la disponibilidad y calidad de los servicios, aumentar la satisfacción de los usuarios y disminuir los costos. El establecimiento de acuerdos de nivel de servicio (SLA, Service Level Agreement) entre el proveedor de servicios y el cliente permite, entre otros aspectos, acordar y gestionar la calidad de los servicios ofrecidos y las penalidades que se aplicarán por incumplimiento de los términos del acuerdo [1].

Existen multitud de iniciativas para la estandarización de los SLA en diversos escenarios. Estas iniciativas presentan generalmente un nivel de complejidad elevado, por lo que aplicarlas en redes de entidades que ofrecen servicios de telecomunicaciones de manera no comercial (para los efectos de este trabajo redes no comerciales) resulta complejo.

Por otra parte, se debe contar con herramientas software que permitan gestionar los SLA que se establecen con los clientes. La mayoría del software que es empleado para la gestión de SLA es propietario, por lo que resulta difícil encontrar aplicaciones que se puedan utilizar con este propósito en redes no comerciales.

Lo antes planteado llevó a los autores a diseñar un sistema que permitiera la gestión de los SLA de manera eficiente en redes no comerciales. Para su diseño se tuvo en cuenta el ciclo de vida de un SLA según la  UIT-T, haciendo énfasis en la etapa de ejecución, ya que resulta ser la más crítica para la gestión de los SLA producto a los mecanismos de supervisión y control que involucra [2]. El sistema que se diseñó posee varios bloques y para comprobar su funcionamiento se desarrolló un software que permite la gestión de los SLA en la etapa de ejecución, en el tipo de redes analizado.

2.- INICIATIVAS EXISTENTES PARA LA GESTIÓN DE LOS SLA

Dada la importancia y la gran cantidad de datos involucrados en los SLA se requiere contar con sistemas automatizados para su gestión. Para la estructuración del sistema que se propone resultó necesario profundizar en los procesos involucrados en la gestión de los SLA en la etapa de ejecución, de las iniciativas propuestas por organismos rectores para su normalización y estandarización. En la actualidad existe una multitud de iniciativas para la estandarización de los SLA en diversos escenarios. En la tabla 1 se recopilan 45 organismos e iniciativas que proponen mecanismos para dicha estandarización [3].

Luego de un análisis de varias iniciativas, entre las que destacan las propuestas por el TMForum, UIT-T e ITIL se llegó a la conclusión de que presentan un nivel de complejidad elevado, por lo que aplicarlas a los servicios brindados en redes no comerciales resulta complejo. Entre las iniciativas antes mencionadas se encuentra el Mapa de Operaciones de las Telecomunicaciones mejorado (eTOM, enhanced Telecomunication Operations Map), desarrollado por el TMForum, que brinda todo un marco de procesos en el que se especifican, entre otros, los procesos involucrados en la gestión de los SLA en la etapa de ejecución [4]. Aunque este marco resulta muy complejo para ser aplicado en redes no comerciales e involucra la facturación por los servicios brindados, algo de menor interés en este tipo de redes, por su profundidad fue el seleccionado como base para desarrollar la propuesta del sistema para la gestión en redes no comerciales de los SLA en su etapa de ejecución.

Para el desarrollo del sistema, así como la conformación del software, fue necesario el análisis de algunas de las herramientas existentes para la gestión de los SLA. Entre las herramientas analizadas se destacan ServiceDesk Plus, IT SLA Monitoring and Reporting, Gestar ITIL y FrontRange ITSM. Cada herramienta posee diversos módulos y funcionalidades e involucran la gestión de SLA de uno o más servicios.

Estas herramientas están basadas en algunas de las iniciativas mencionadas con anterioridad e implican elementos de facturación de los servicios. Por otra parte las herramientas analizadas están sujetas al uso de licencias para su operación, por lo que se hace difícil encontrar aplicaciones que se puedan utilizar para la gestión de los SLA en la etapa de ejecución en redes no comerciales.

3.- SISTEMA PARA LA GESTIÓN DE LOS SLA EN LA ETAPA DE EJECUCIÓN

En el diseño del sistema de gestión de los SLA en su etapa de ejecución se consideró una base de datos (UISLA, Unidad de Información de SLA) centralizada y accesible para todos los bloques del sistema. En UISLA deben estar almacenados los detalles de cada uno de los SLA contratados y los recursos que se encuentran asociados a cada uno de los servicios que se brindan a los clientes. Además el sistema está compuesto por cuatro bloques funcionales:

        • Bloque "Recolección de datos"

        • Bloque "Gestión del desempeño de los recursos y servicios"

        • Bloque "Gestión de incidencias"

En la figura 1 se observa el diagrama general del sistema diseñado para la gestión de los SLA. Vale aclarar que por ser un  sistema diseñado para redes no comerciales, no se tomó en cuenta la dependencia de la facturación con el cumplimiento de los SLA.  Los bloques que componen el sistema interactúan con la base de datos obteniendo e insertando diversos tipos de información.

La interfaz con el cliente del servicio (SC, Service Customer) representa la vía de comunicación que existe entre el SP y el SC y permite que este último pueda informar al SP los problemas que detecte en el servicio. Esta interfaz también es empleada por el SP para hacer llegar los reportes de calidad de servicio (QoS, Quality of Service) al SC.

Los bloques del sistema propuesto pueden interactuar entre sí y con la base de datos UISLA y están compuestos por diversos sub-bloques que les proporcionan sus funcionalidades. A continuación se analizan los bloques que conforman el sistema que se propone para la gestión de los SLA en la etapa de ejecución.

3.1.- BLOQUE RECOLECCIÓN DE DATOS

Este bloque lleva a cabo la primera fase del sistema. El mismo permite recolectar, procesar y almacenar información proveniente del monitoreo constante de las instancias de los recursos y servicios involucrados en los SLA. La información recopilada puede ser:

        • Datos de desempeño de los recursos y servicios.

        • Información de uso de los recursos y servicios.

        • Otros eventos, como alarmas de fallos.

Este bloque puede emplear diversas políticas o mecanismos de monitorización entre los que se encuentran el sondeo o polling, informe de eventos o notificaciones, proxys y sondas.

        • Detalles de los recursos/servicios a monitorear (enrutadores, conmutadores, PCs y aplicaciones, entre otros).

        • Parámetros a monitorear para cada recurso/servicio.

        • Frecuencia de monitorización para cada elemento.

        • Mecanismos de monitorización a emplear.

Existen eventos que desencadenan la acción de monitorización sobre los recursos y servicios, estos pueden ser:

        • Eventos automáticos del propio bloque de recolección de datos, regidos por la frecuencia de monitorización establecida para cada recurso/servicio en particular.

        • Solicitud de otro bloque (evento desencadenado cuando el bloque "Gestión de incidencias" necesita contar con información actualizada).

Las responsabilidades de este bloque también abarcan:

        • Procesamiento de los datos a través de mecanismos de filtrado (según criterios pre-establecidos) y formateado de la información (agregación y transformación).

Para llevar a cabo su propósito, en el bloque Recolección de Datos está conformado por los siguientes sub-bloques: "Control de Monitorización", "Encuesta", "Gestor", "Filtrado" y "Normalización" (ver figura 2).

El sub-bloque que controla la monitorización obtiene de la base de datos los recursos/servicios y los parámetros a monitorear, así como los mecanismos de monitoreo que se deben emplear para dichos recursos/servicios, el período de monitorización y otros detalles necesarios para el proceso de supervisión. Este sub-bloque, además, es capaz de recibir una indicación del bloque "Gestión de incidencias" para activar el monitoreo de un recurso/servicio específico. Una vez obtenidos los detalles de los recursos/servicios a monitorear, este sub-bloque ejecuta el mecanismo de monitoreo que se va a emplear.

En el diseño del sistema que se propone se consideraron como mecanismos posibles de monitorización la encuesta al recurso/servicio o la existencia de un agente del lado del mismo que recopila la información necesaria y la notifica.  En caso de que el mecanismo empleado sea el de encuesta, se conforma la solicitud que se emite al recurso/servicio con el objetivo de recibir respuesta por parte del mismo (esto se realiza en el sub-bloque "Encuesta") y se interactúa con el recurso/servicio mediante el envío de la misma. En caso de que el recurso emplee un agente se le cede el proceso de interacción con el mismo al sub-bloque "Gestor".

Una vez obtenidos los datos de desempeño, por cualquiera de los mecanismos antes mencionados, estos se pasan a los sub-bloques "Filtrado" y "Normalización". En el primero se filtra la información recibida según criterios previamente establecidos, lo que permite desechar la que no sea necesaria.  En el segundo sub-bloque se lleva a cabo la normalización de la información lo que incluye el formateado de la misma (agregación y transformación) para su correcta inserción en la base de datos.

3.2.- BLOQUE GESTIÓN DEL DESEMPEÑO DE LOS RECURSOS Y SERVICIOS

Este bloque vigila el nivel de servicio que los recursos y servicios ofrecen, verificando su correcta operación en todo momento. Abarca la supervisión, análisis, control y notificación de su desempeño. Trabaja con información básica almacenada previamente en la base de datos del sistema por el bloque de "Recolección de datos", procesándola de diversas formas para, por ejemplo, obtener estadísticas y conformar los indicadores clave de desempeño (KPI, Key Performance Indicators), que no deben superar los valores umbrales establecidos (que se obtienen de UISLA) para que el servicio funcione de manera correcta.

En sentido general las responsabilidades de este bloque incluyen:

        • Obtener la información, almacenada en la base de datos, para el procesado de los parámetros de desempeño con vistas a la conformación de los KPI.

        • Adquirir, en la base de datos, los valores umbrales establecidos para los KPI, los que se requieren para verificar el correcto funcionamiento del recurso/servicio.

        • Detectar violaciones en los umbrales establecidos, lo que representa una degradación en la calidad del servicio ofrecido, debido a un posible fallo en los recursos que soportan a los servicios o a un cuello de botella creado por un uso elevado de los mismos. La detección temprana de la degradación del desempeño de recursos y servicios también posibilita actuar de manera proactiva, evitando fallos de gran magnitud.

        • Informar al bloque de "Gestión de incidencias" los elementos afectados debido a violaciones de umbrales de los KPI, lo que desencadena la actividad de restauración necesaria.

Para realizar sus funciones, el bloque Gestión del desempeño de los recursos y servicios se ha considerado formado por tres sub-bloques: "Obtención de información de desempeño", "Procesado de las estadísticas" y "Analizador".  La figura 3 recoge los detalles de las funcionalidades de este bloque.

El sub-bloque "Obtención de información de desempeño" es el encargado de interactuar con la base de datos UISLA para obtener la información de desempeño, los valores umbrales de los KPI y los valores de alerta.  Además, recibe solicitudes del bloque "Gestión de incidencias" que le indica evaluar los parámetros de un determinado recurso/servicio e interactúa con el sub-bloque "Procesado de las estadísticas" para entregarle los datos de desempeño que le permiten conformar los KPI. También se comunica con sub-bloque "Analizador" para indicarle los distintos rangos posibles de los parámetros de desempeño.  

El sub-bloque "Procesado de las estadísticas" realiza diversas funciones en dependencia del parámetro de nivel de servicio que esté evaluando. El procesado de los parámetros puede variar notablemente de uno a otro según la naturaleza del mismo.

El sub-bloque "Analizador" se encarga de comparar las estadísticas procesadas (los KPI conformados) con los rangos establecidos en los SLA. Esto le permite detectar si los parámetros procesados se encuentran en un rango normal, en el rango de alerta o si se ha producido una alarma (por ejemplo, cuando el servicio no se encuentra activo). Acorde con los resultados obtenidos del análisis, emite al bloque de "Gestión de incidencias" un informe de estado de los KPI, si estos se encuentran en el rango normal, o una alerta o alarma, si existe algún problema indicando, en este caso los detalles del incidente.

3.3.- BLOQUE GESTIÓN DE INCIDENCIAS

El bloque "Gestión de incidencias" cubre todo tipo de incidencias, ya sean fallos, consultas realizadas por el personal técnico o por los usuarios (generalmente mediante una llamada al centro de asistencia), o problemas detectados de forma automática por las herramientas de monitoreo. El objetivo principal de este bloque es restaurar lo antes posible el servicio a su funcionamiento normal, garantizando niveles de calidad y disponibilidad elevados.

        • Límites de tiempo: Se deben definir límites de tiempo para cada uno de los niveles de gestión.

        • Modelos de incidencias: Permite determinar rápidamente el procedimiento adecuado para atender las incidencias, lo que facilita que las que son estándar se gestionen de forma correcta y en el tiempo establecido.

        • Incidencias graves: Requieren un procedimiento distinto al estándar, con plazos más cortos, debido a su urgencia. Se debe definir lo que es una incidencia grave, así como precisar las prioridades para la atención a estas incidencias.

        • Escalado funcional: Consiste en involucrar o transferir un fallo o problema a un equipo técnico con mayor experiencia para que ayude en su solución.

        • Escalado jerárquico: Involucrar o transferir un fallo o problema no resuelto a niveles de gestión más elevados para su solución.

La capacidad para resolver las incidencias en un tiempo determinado es fundamental al ofrecer servicios. Para ello, entre otros elementos, la gestión de incidencias debe tener acceso a los SLA almacenados en la base de datos ya que es esencial que se disponga de información puntual sobre los recursos asociados a los servicios brindados.

Una herramienta que posibilite la gestión de incidencias debe gestionar las averías técnicas de los servicios ofrecidos y almacenar toda la información relevante, en referencia a la incidencia, siguiendo un flujo de trabajo que defina los estados por los que pasa la misma, los grupos técnicos que deben tratarla, y las notificaciones o acciones automáticas a realizar. De acuerdo con lo antes planteado, el empleo de una herramienta de gestión de incidencias tiene tres objetivos básicos:

        • Minimizar los periodos "fuera de servicio".

        • Registrar la información relevante de todas las incidencias.

En la figura 4 se muestra el diagrama detallado del bloque "Gestión de incidencias", el cual se encuentra compuesto por diversos sub-bloques que realizan variadas funciones. Para poder explicar el funcionamiento de este bloque se analizarán dos situaciones: a la interfaz de entrada le llega un incidente que representa una alerta o alarma y, a la interfaz de entrada llega un reporte de problemas emitido por el cliente del servicio. Si a la interfaz de entrada llega un reporte de estado lo que ocurre se explica en las dos situaciones planteadas.

Situación 1: Alerta o Alarma en la interfaz de entrada

        • La alerta o alarma que se recibe es emitida por el bloque de "Gestión del desempeño de los recursos y servicios", la cual indica los detalles de la incidencia ocurrida por ejemplo: Fecha, id_recurso(s), id_servicio(s), KPI afectados y valores de los KPI.

        • Se correlaciona la incidencia que se recibe con las incidencias pendientes de solución existentes en UISLA, con el objetivo de determinar si existen incidencias por la misma causa aún no solucionadas.

        • Si existe alguna incidencia pendiente registrada por la misma causa aún no solucionada, se actualiza el estado de la misma en la base de datos. Si este no es el caso, se agrega (registra) la nueva incidencia a la lista de incidencias pendientes y se emite una alerta o alarma al operador.

        • Se correlaciona la incidencia actual con incidencias ya solucionadas, ocurridas con anterioridad por la misma causa. Esto le brinda al operador un historial de posibles soluciones, lo que le ayuda a resolver más rápidamente el problema reportado en la incidencia.

        • Se ejecutan las acciones correspondientes para la solución, lo que requiere interactuar con una base de datos que contenga la configuración de todos los recursos y servicios. Esta interacción consiste en la solicitud de datos de configuración y, luego de ejecutar las acciones necesarias para la solución, la actualización del estado de la configuración de los recursos y servicios que hayan sido modificados.

        • A continuación, es necesario verificar que los cambios efectuados hayan tenido la repercusión esperada. Para esto se le indica a los bloques de "Recolección de datos" y "Gestión del desempeño de los recursos y servicios" que lleven a cabo un análisis del estado actual de los recursos y servicios especificados y se espera por el reporte de estado emitido por el último bloque.

        • Cuando llega el reporte de estado se lleva a cabo un análisis de incidencias para determinar si corresponde a la solicitud de un reporte de problemas emitido por el SC o a la verificación de que la incidencia ha sido solucionada.

        • Si el problema aún no ha sido solucionado se actualiza el estado de la incidencia en la base de datos. Una característica importante de este bloque es que tiene en cuenta que si el tiempo para el tratamiento de una incidencia en un nivel ha vencido, esta debe ser escalada al nivel inmediato superior. En caso de que dicho tiempo aún no haya vencido se vuelve a empezar el ciclo trabajando en otra posible solución.

Situación 2: Reporte de problemas por el SC en la interfaz de entrada

        • A la interfaz de entrada le llega el reporte de un posible problema detectado por el SC.

        • El proceso continúa con la correlación con las incidencias pendientes. Si no existen incidencias pendientes por la misma causa se procede a su registro y se emite una alarma al operador.

        • Se procede a analizar el estado de los recursos y servicios implicados en el reporte del problema. Para esto se activan los bloques de "Recolección de datos" y "Gestión de desempeño de los recursos y servicios" indicando los recursos y servicios a monitorear, siendo necesario obtener de la base de datos correspondiente los detalles de los recursos y servicios implicados.

        • Se espera por el reporte de estado para determinar si existe o no un problema. Si el problema no existe se procede a dar cierre a la incidencia y a reportarle al SC que realmente no existen problemas en el servicio que está recibiendo.

        • Si realmente existe un problema se procede al ciclo de solución de la incidencia mencionado en la primera situación.

3.4.- BLOQUE GESTIÓN DEL SLA

El bloque "Gestión del SLA" es el encargado de llevar el registro y control de las violaciones incurridas en los SLA y de emitir los informes de QoS a los clientes. Las responsabilidades de este bloque incluyen:

        • Adquisición y procesado (de manera parcial y global) de los parámetros de desempeño almacenados en la base de datos para conformar los KPI que se incluyen en el SLA.

        • Obtención en la base de datos de los valores "objetivo" acordados para los parámetros de nivel de servicio.

        • Comparación de los valores "objetivo" con los valores de los parámetros procesados.

        • Clasificación de las violaciones incurridas a los SLA.

        • Conformación de los informes de QoS emitidos al cliente.

En la figura 5 se pueden observar los detalles de la estructura del bloque "Gestión del SLA" el cual está compuesto, a su vez, por los sub-bloques:

        • "Procesado de las estadísticas".

        •  "Análisis de las violaciones".

        • "Conformación del informe de QoS".

El procesado de las estadísticas varía en dependencia del parámetro de nivel de servicio que se desea comprobar. Determinados parámetros, como la latencia promedio y el jitter promedio, involucran el promediado de las estadísticas obtenidas a lo largo del período establecido. Por otra parte existen parámetros, como la disponibilidad y el tiempo medio entre fallos, que dependen de expresiones para su cálculo, por lo que primeramente es necesario procesar las variables de las que dependen estos parámetros para luego calcular los mismos.

El sub-bloque "Procesado de las estadísticas" interactúa con la base de datos UISLA para obtener los parámetros de nivel de servicio que debe evaluar para cada instancia del servicio, así como las estadísticas acumuladas. También interactúa con los sub-bloques "Conformación del informe de QoS", al que le envía los parámetros evaluados, y "Análisis de las violaciones", al que le hace llegar el análisis global de los parámetros de nivel de servicio.

El sub-bloque "Análisis de las violaciones" recibe, como se mencionó anteriormente, los parámetros de nivel de servicio ya evaluados, además de los valores "objetivo" para cada uno de estos parámetros y los rangos para las distintas magnitudes de violación establecidas en el SLA. Con esta información, se encarga de comparar los valores de los parámetros de nivel de servicio con los valores acordados y determinar si ha ocurrido o no una violación. En caso de ocurrir una violación, la clasifica teniendo en cuenta los rangos establecidos para las distintas magnitudes de violación en el SLA. La información resultante se envía al sub-bloque "Conformación del informe de QoS" para emitir el informe mensual de QoS al cliente.

El sub-bloque "Conformación del informe de QoS" se encarga de la elaboración del informe que se envía al cliente para que este conozca la calidad del servicio que recibe. Este bloque obtiene de la base de datos la frecuencia de envío del informe, el o los mecanismos para su presentación al cliente y la información que debe estar reflejada en el mismo. Además, recibe del sub-bloque "Procesado de las estadísticas" el análisis de los parámetros procesados de manera parcial o global, en dependencia de si el informe es el emitido periódicamente o el que se emite una vez al mes. En caso de que el informe sea emitido mensualmente, se recibe desde el sub-bloque "Análisis de las violaciones" las violaciones incurridas durante el período. Finalmente, el informe se conforma y se envía al cliente mediante la(s) vía(s) acordada(s) en los mecanismos de presentación y con la frecuencia establecida en el SLA.

4.- SOFTWARE DESARROLLADO PARA GESTIONAR EN REDES NO COMERCIALES LOS SLA EN LA ETAPA DE EJECUCIÓN

El software desarrollado tiene como objetivo validar el diseño del sistema de gestión de los SLA en la etapa de ejecución. Para su elaboración se utilizó como lenguaje de programación C# y se empleó Microsoft Visual Studio 2012, por sus posibilidades de personalizar y conformar la interfaz gráfica.

Con el propósito de que el código empleado fuera totalmente compatible con un sistema operativo GNU/Linux, se programaron las funcionalidades del software utilizando MonoDevelop ejecutándose sobre Ubuntu 12.04. El sistema gestor de base de datos empleado fue SQLite, escogido por su simplicidad y eficiencia.

La interfaz gráfica se realizó utilizando los formularios de Windows, ya que los brindados por MonoDevelop para crear interfaces gráficas pertenecen a GTK (Kit de herramientas de programas para manipulación de imágenes de GNU, GNU Image Manipulation Program Tool Kit) y el trabajo con los mismos resulta difícil.

Para el correcto funcionamiento del software desarrollado se deben tener en cuenta los requerimientos siguientes: 

        • Ejecutarlo en un sistema operativo basado en GNU/Linux y no en sistemas operativos basados en Windows o Mac.

        • Contar con una instalación de Mono que permita ejecutar programas basados en .NET versión 4.0 (en los repositorios de Ubuntu 12.04 se encuentra la instalación necesaria de Mono).  Además, se debe poseer permisos administrativos y ejecutar, en la línea de comandos, la sentencia: sudo apt-get install mono, la que permite instalar el lenguaje común de infraestructura que es utilizado para correr aplicaciones compiladas en .NET.

        • Instalar el paquete apache_utils que contiene la aplicación apache_bench. Este paquete se encuentra disponible en la mayoría de los repositorios. Para la instalación del mismo se debe ejecutar en la línea de comandos la sentencia: sudo apt-get install apache_utils.

        • Poseer, en la localización donde se va a ejecutar la aplicación, permisos administrativos que permitan la ejecución, creación y modificación de archivos, ya que el software desarrollado durante su ejecución hace uso de archivos temporales.

        • Tener instalado SQLite para lo cual se emplea la sentencia: sudo apt-get install sqlite.

4.1.- MÓDULO "MONITOR"

El módulo "Monitor", como ya se mencionó previamente, es el encargado de ejecutar el bloque "Recolección de datos". Este módulo no posee interfaz gráfica ni brinda la posibilidad de interacción con el usuario, su trabajo consiste en la recopilación, filtrado, formateo y almacenamiento de las estadísticas de desempeño.

Aunque los sistemas empleados para gestionar niveles de servicio deben permitir el monitoreo de diversos elementos, en la realización de este software, cuyo objetivo era solamente validar el funcionamiento de la propuesta realizada, se consideró que existe un solo recurso/servicio a monitorear. Esto evita invertir esfuerzos en la conformación de este módulo para dedicarlos al módulo "Ejecución del SLA", lo que es admisible dado que este no varía sustancialmente con el recurso/servicio que se desea monitorear. Se consideró que se brinda un único servicio Web a múltiples usuarios.

La aplicación ab se utiliza para emitir un número determinado de solicitudes a un servidor Web, con el objetivo de obtener diversos parámetros que permitan conocer el desempeño del servicio. Por su parte la aplicación wget se utiliza para conocer el estado del servicio Web permitiendo saber si el servicio se encuentra o no activo, sin necesidad de descargar contenido del sitio.

Una vez obtenidas las estadísticas de desempeño mediante las aplicaciones ab y wget se procede a la ejecución del programa monitor.exe. Este programa es una aplicación de consola que se abastece de los archivos temporales creados por las aplicaciones ab y wget para realizar el filtrado de la información que contienen. Este filtrado elimina toda la información que no es necesaria o que es redundante, por ejemplo, a partir del tamaño de los documentos que fueron descargados, del número de solicitudes completadas y del tiempo que tomó la descarga se pueden obtener indicadores como son: el tiempo y la velocidad de transferencia promedio por solicitud y el tráfico total cursado. Luego del filtrado de la información, el programa monitor.exe formatea y almacena la información en la base de datos.

4.2.- MÓDULO "EJECUCIÓN DEL SLA"

Como ya se mencionó, este módulo es el encargado de implementar las funcionalidades de los restantes bloques del sistema propuesto para la gestión de los SLA en la etapa de ejecución. Posee una interfaz gráfica, que fue realizada utilizando los formularios de Windows, cuatro formularios principales y varios formularios secundarios, estos son:

1.    Formulario "Gestión de ejecución de SLA"

2.    Formulario "Gestión de desempeño"

      o    Formulario "Detalles de indisponibilidad"

3.    Formulario "Gestión de incidentes"

      o    Formulario "Modificar incidente"

4.    Formulario "Gestión del SLA"

      o    "Detalles SLA"

El primer formulario que se presenta al ejecutar el programa desarrollado es el de "Gestión de ejecución de SLA", el cual representa la vía de acceso a los restantes formularios que componen el software. El mismo brinda información general sobre el estado del servicio, indicando si el servicio se encuentra activo y el número de incidencias pendientes (incidencias que no han sido solucionadas y que por lo tanto permanecen activas). Además indica, en incidencias no revisadas, las incidencias que han ocurrido y que se han solucionado sin reportarle al sistema los detalles de su solución.

El formulario "Gestión de desempeño" recoge las funcionalidades más importantes del bloque "Gestión del desempeño de los recursos y servicios". Este formulario, además, posee un formulario secundario, el de "Detalles de indisponibilidad". Ambos formularios se pueden apreciar en la figura 6.

Adicionalmente, el formulario "Gestión de desempeño" brinda el resultado del procesado de los parámetros de desempeño, los que deben ser actualizados periódicamente para que sea posible velar por el estado de los mismos. También este formulario permite cargar una tabla con más información (sin procesar) relacionada con los datos de desempeño, lo que posibilita analizar en qué momento ocurrió una degradación el servicio o en qué momento el servicio se encontraba trabajando con más holgura.

Además, a través del formulario "Gestión de desempeño" se puede conocer el tiempo total en el que el servicio ha estado indisponible, por cualquier razón, así como el número de veces en que esto ha ocurrido. Para obtener información más detallada sobre las indisponibilidades se puede desplegar el formulario "Detalles de indisponibilidad" que desglosa, por fecha, las interrupciones al servicio indicando el tiempo que el mismo estuvo inactivo.

El formulario "Gestión de incidentes" implementa las principales funcionalidades del bloque "Gestión de incidencias". Cuenta con dos formularios secundarios: "Modificar incidente" y "Base del conocimiento". Este formulario permite conocer los incidentes que están ocurriendo en ese momento (incidentes pendientes) y los que no se han cerrado de manera correcta (incidentes no revisados), pues aún no se han descrito en el sistema las acciones de solución llevadas a cabo.

El formulario secundario "Base del conocimiento" permite visualizar todos los incidentes ocurridos que han sido resueltos, lo que es útil para encontrar posibles soluciones a nuevos incidentes. Por su parte el formulario secundario "Modificar Incidente" permite cerrar un incidente, una vez que ha sido solucionado de manera correcta. El cierre del incidente requiere una descripción detallada de la solución dada al problema que dio origen al mismo lo que, automáticamente, pasa a formar parte de la "Base del Conocimiento" para futuras consultas. Cerrar un incidente disminuye el indicador de incidentes no revisados.

4.3.- ESCENARIO DE PRUEBA DEL SOFTWARE DESAROLLADO

En el escenario de prueba fueron empleadas tres PC (dos laptops y una computadora de escritorio). Para ejecutar el software de gestión de los SLA y el servicio Web se utilizaron en dos PC, el sistema de virtualización por software VMware Workstation 10.0.0 sobre el cual se encontraba corriendo Ubuntu 12.04. Esto se puede apreciar en la figura 8.

Una laptop se encargó de ejecutar el software de gestión de los SLA y en la computadora de escritorio se ejecutó el servicio Web. Ambas computadoras se comunicaron mediante una laptop que funcionó como puente entre una red inalámbrica y una red cableada. La red inalámbrica se empleó con el objetivo de proporcionar una mayor latencia a los paquetes que se transmiten entre el software de gestión de los SLA y el servicio Web, que hicieran más reales las condiciones de prueba. La plataforma de virtualización brindó la flexibilidad necesaria para simular una degradación en el desempeño del servicio brindado, ya que permite limitar el ancho de banda de las interfaces de red así como la pérdida de paquetes.

Para realizar la prueba se simuló un fallo en el servicio Web. Esto permitió comprobar el funcionamiento de los distintos formularios que conforman el programa. Se parte de que el servicio Web se encuentra activo y no se están ejecutando ninguno de los módulos que conforman el software desarrollado. Para ejecutar los dos módulos que conforman dicho software hay que situarse en la consola y sobre la localización del software, escribir las sentencias: ./script y mono GeSLA.exe. Una vez ejecutadas ambas sentencias, el software, ya ejecutándose, muestra en el formulario "Gestión de ejecución de SLA" que no existen incidentes pendientes ni incidentes no revisados.

A continuación se simula un fallo en el servicio desactivando el servidor Web. El fallo del servicio es automáticamente detectado por el software una vez completado el ciclo de monitorización, indicando en el formulario "Gestión de ejecución de SLA" que existe un incidente pendiente y un incidente no revisado, como se observa en la figura 9.

En el formulario "Gestión de desempeño" aparece que ha ocurrido una interrupción y comienza a incrementar el tiempo total en el que el servicio ha estado indisponible. En la figura 9 se muestra dicho formulario donde se aprecian los valores de los indicadores de desempeño procesados y los detalles de indisponibilidad brindados por el formulario con este nombre.

]]> Para obtener los detalles del problema se recurre al formulario "Gestión de incidentes" (ver figura 10) en el que se pueden comprobar los incidentes pendientes así como la base de datos con todos los incidentes previos, donde se pueden buscar posibles soluciones.

Una vez restaurado el funcionamiento del servicio, el indicador de incidentes pendientes disminuye su valor, pero el indicador de incidentes no revisados se mantiene, indicando que no se han descrito las acciones llevadas a cabo para dar solución al problema. Para hacerlo, en el formulario "Gestión de Incidentes", se selecciona el incidente no revisado para actualizar su estado en el formulario "Modificar incidente". Una vez hecho esto se puede observar en el formulario "Base del conocimiento" de la figura 10 que el incidente con su solución se encuentra registrado.

En la figura 11 se encuentra el formulario "Gestión del SLA" con los detalles de los dos SLA que se encuentran registrados. Como se puede observar, en uno de los SLA el tiempo total de indisponibilidad de servicio permitido fue superado y se incurrió en una violación menor de disponibilidad, sin embargo en el otro acuerdo (que es más flexible) no se incurrió en ninguna violación de este tipo. El tiempo medio por solicitud en un SLA alcanzó el valor necesario para considerarse una violación media mientras que en el otro una violación menor.

Como prueba adicional se simuló una degradación del desempeño de la red, limitando el ancho de banda de la interfaz de red del servidor a 10 Mbps e insertando una pérdida de paquetes de un 2%. Esto posibilitó verificar que el software reacciona de manera proactiva indicando que existe una degradación del desempeño de la red, lo que permite llevar a cabo oportunamente las acciones para dar solución al problema que se presenta.

5.- CONCLUSIONES

La propuesta de sistema para la gestión de los SLA en la etapa de ejecución es de gran utilidad para redes no comerciales, en las que no es importante considerar la dependencia de la facturación con el cumplimiento de los  SLA.  El mismo posee cuatro bloques funcionales, que interactúan entre ellos y con una base de datos centralizada.  Cada bloque está compuesto por diversos sub-bloques que les proporcionan sus funcionalidades.

En las pruebas del software se simularon diversas situaciones que se presentan en la práctica. Se comprobó su funcionamiento con el servicio trabajando sin problemas y con incidentes como el fallo en el servicio Web y la degradación del desempeño del mismo mediante una sobrecarga de la red. Una vez finalizada las pruebas se pudo corroborar que el software funciona de manera correcta ante diversas situaciones.

REFERENCIAS

1. Ding J. Advances in Network Management. 6000 Broken Sound Parkway NW: Auerbach Publications; 2010. 375p.

2. Requisitos de gestión de calidad de servicio/acuerdo de nivel de servicio a través de la interfaz X de la RGT para servicios del protocolo Internet. M.3341, (2003).

3. Kennedy J. Towards Standardized SLAs.  Euro-Par 2013: Parallel Processing Workshops; Aachen, Alemania: Springer; 2013.

4. Enhanced Telecom Operations Map (eTOM) – The business process framework. M.3050.1, (2007).

5. TMForum. SLA Management Handbook. Enterprise Perspective Berkshire, United Kingdom: The Open Group; 2004. 137p.

Recibido: 18 de febrero de 2016
Aprobado: 15 de junio de 2016

  ]]>  

Guillermo Gafas Cabrera. CubaTel s.a., La Habana, Cuba. E-mail: guillermo@cubatel.cu.