PROYECTO FINAL DE INGENIERÍA REGISTRO DE EVENTOS, ANÁLISIS Y EMISIÓN DE AVISOS DE ALARMAS EN CPD'S DE MISIÓN CRÍTICA

Transcripción

1 PROYECTO FINAL DE INGENIERÍA REGISTRO DE EVENTOS, ANÁLISIS Y EMISIÓN DE AVISOS DE ALARMAS EN CPD'S DE MISIÓN CRÍTICA Calligaro, Daniel Victor LU Ingeniería Informática LU Ingeniería Informática Tutor: Godio, Claudio, UADE Diciembre 19, 2011 UNIVERSIDAD ARGENTINA DE LA EMPRESA FACULTAD DE INGENIERÍA Y CIENCIAS EXACTAS

2 Resumen Registro de eventos, análisis y Ingeniería Informática Calligaro, Daniel Victor Los Centros de Procesamiento de Datos (CPD) son establecimientos que poseen una infraestructura orientada a la prestación de servicios de cómputo a clientes, la cual debe ser debidamente monitoreada para asegurar la calidad del servicio prestado. Debido a que dicha infraestructura varía considerablemente entre distintos CPD, la solución que se ha de implementar deberá, o bien ser un desarrollo a medida, o presentar grandes cualidades de adaptabilidad. Por otra parte, los CPD de Misión Critica (clasificados como Tier 4) presentan además requerimientos adicionales de funcionamiento tales como disponibilidad, confiabilidad, real-time y monitoreo, los cuales deberán ser satisfechos por la solución de monitoreo implementada. La infraestructura de un CPD se encuentra compuesta de una gran variedad de elementos que pueden ser monitoreados. El problema que esta variedad de elementos presenta es la heterogeneidad de los medios de conexión que se deberán utilizar. Debido a esto la solución implementada requerirá disponer de mecanismos de comunicación para cada medio de conexión utilizado en el entorno. Este trabajo propone como solución de monitoreo un sistema que satisfaga las características previamente mencionadas. Para afrontar la necesidad de flexibilidad y adaptabilidad, el sistema se diseñó de forma que sea extensible de forma ilimitada, lo cual se logra haciendo uso de un esquema de plugins en los puntos de conexión del sistema. Por otra parte, el sistema presenta un diseño modular, multi-capa y de plataforma abierta, el cual permite minimizar el impacto de errores, facilitar el mantenimiento y la integración y/o migración de datos con otros sistemas. El diseño del sistema se presenta en términos generales como módulos que actúan sobre un flujo de información. En uno de los extremos del flujo el sistema se integra con agentes (sensores o sistemas) por medio de plugins, transformando la información recibida a un formato estándar entendible por la aplicación. En el extremo opuesto se encuentran las salidas, las cuales también consisten de plugins que permiten integrar distintos mecanismos de notificación al sistema. En la parte central del sistema se encuentra el motor de reglas, el cual realiza la transformación de los datos recibidos para comunicarlos por medio de las salidas al entorno. Este último módulo le brinda al administrador la flexibilidad de poder definir una lógica de control propia, tomando los datos relevantes a informar, y utilizando el medio de comunicación que considere pertinente para informar una situación dada. 1 de 105

3 Summary Registro de eventos, análisis y Ingeniería Informática Calligaro, Daniel Victor Data Centers (DC) provide computing services to its client, running a service-oriented infrastructure which must be carefully monitored to assure the quality of its services. Due to infrastructure diversity between each installation, the monitoring solution to be implemented must be either a custom development or a highly adaptable system. Furthermore, a Mission Critical DC (Tier 4 certification) presents additional requirements such as availability, reliability, real-time and monitoring, all of which must be fulfilled by the selected monitoring solution. The DC's infrastructure contains a great variety of elements to be monitored. Each element implements its own communication method, and may or may not share the same mechanism with other elements. This variety of technologies requires great flexibility on communications mechanism, requirement that must be fulfilled by the selected monitoring solution. This paper proposes a system design that fulfills all the previously mentioned requirements. Adaptability and communications flexibility is achieved by the use of a plugin-based architecture for all integration points of the system. This characteristic is defined as a design premise under the name of Unlimited extensibility. Furthermore, the system is designed to be modular, multi-layered and with an open platform, effectively reducing error impact, providing ease for maintenance and migration or integration with other systems. The high-level design of the system defines a flux of information onto which a series of modules are placed to transform it. On the flux start, the systems are linked with various agents (sensors or systems) with the use of plugins, formatting all the received information into an application-readable format. On the opposite side of the flux is located the Outputs module, which allows the system to communicate with external notification mechanisms. Finally, on the center of the flux is located the rule engine module, which transforms the information received from the first module, and transfers it to the Outputs module. This module provides the system administrator with the flexibility to define its own control logic, using the appropriate communication mechanism to inform the current situation. 2 de 105

4 1 Índice Registro de eventos, análisis y Ingeniería Informática Calligaro, Daniel Victor 1 Índice Estructura del documento Centros de Procesamiento de Datos Concepto General Clasificaciones según performance en las operaciones Concepto de Misión Crítica Características de Misión Crítica Monitoreo en Centros de Procesamiento de Datos Objetivo del Monitoreo en Centros de Procesamiento de Datos Estado del arte Elementos Típicamente Monitoreados Sensores Concepto General Sensores ambientales típicamente utilizados en CPDs Mensajería en Sistemas Concepto General Comunicaciones basadas en polling Comunicaciones basadas en notificación de eventos Requerimientos del sistema propuesto Premisas de diseño Características de Arquitectura Alcance del diseño propuesto Componentes Generales del Sistema Concepto general Primera Etapa: Acceso a Fuentes de datos Segunda Etapa: Mapeo de entidades Tercera Etapa: Manejo de Eventos y Reglas Etapa Final: Salidas del Sistema Etapa Final: Interfaces de Visualización Diseño del Sistema propuesto Plataforma de ejecución seleccionada Descripción de la plataforma Motivos de selección Propiedades de Misión Crítica de la plataforma Frameworks y componentes Rhino Google Web Toolkit (GWT) Infinispan MapReduce Model de 105

5 6.2.4 Hibernate Selección del Motor de Base de Datos Criterios de Definición de los Módulos del sistema Módulos Principales del Sistema Plugins de Entrada Módulo de Lecture Mapping Agent State Manager Componentes de Extensión Funcional Salidas Motor de Reglas Motor de Vistas Macro-módulo o Módulo Director Módulos Secundarios y/o de Soporte Autenticación y Control de Acceso Interfaces de Configuración del Sistema Servicios de Registro del Sistema Mantenimiento de repositorios de datos Características del modelo de datos General Lecturas de Agentes Respuestas de Componentes de Extensión Funcional Definición de componentes del sistema Registros de Sistema Herramientas complementarias Context Replay Kit de Desarrollo Plugins, Reglas y Componentes - SDK Elementos de desarrollo Herramientas de prueba Comparativa con soluciones existentes Elementos monitoreables: Extensibilidad e Integración: Ejecución distribuida: Modularidad: Evolución a futuro Conclusiones Bibliografía ANEXO 1: Diagramas del sistema propuesto y prototipo ANEXO 2: Objetivo y Alcance del Prototipo ANEXO 3: Modelo de datos del prototipo de 105

6 2 Estructura del documento Este documento posee los siguientes capítulos: 1. Centros de Procesamiento de Datos 2. Monitoreo en Centros de Procesamiento de Datos 3. Requerimientos del sistema propuesto 4. Diseño del Sistema propuesto 5. Herramientas complementarias 6. Comparativa con soluciones existentes 7. Evolución a futuro 8. Conclusiones Centros de Procesamiento de Datos: Este primer capítulo ofrece una introducción al concepto de Centro de Procesamiento de Datos, definiendo sus características y las distintas clasificaciones según el nivel de servicio que prestan. Enfocándose en los Centros de Procesamiento de Datos de Misión Crítica se analiza qué características son propias de este tipos de instalaciones, y como éstas impactan en las cualidades que debe satisfacer un sistema de monitoreo para dicha instalación. Monitoreo en Centros de Procesamiento de Datos: Conociendo la definición de Centro de Procesamiento de Datos se analiza brevemente cuál es el objetivo del monitoreo de las instalaciones, y se detallan los distintos tipos de elementos y mecanismos de comunicación que se pueden presentar en un escenario promedio. Este análisis permite definir los distintos medios de comunicación con los cuales deberá tratar el sistema propuesto. Requerimientos del sistema propuesto: Habiendo definido las características generales que deberá satisfacer el sistema propuesto, se definen de forma detallada los distintos requerimientos generales que deberá respetar el diseño del sistema propuesto. Más aún, se define la estructura de alto nivel del diseño propuesto, junto con su interacción con los elementos del entorno y distintas etapas de transformación de datos. Diseño del Sistema propuesto: Tomando como base los requerimientos definidos en el capítulo anterior, se define la plataforma de desarrollo a utilizar, las distintas tecnologías y frameworks que se adoptarán para el desarrollo y el detalle de la arquitectura modular del sistema. A su vez se detalla cómo cada módulo satisface los requerimientos generales mencionados anteriormente, según corresponda, junto con sus respectivas 5 de 105

7 responsabilidades, y los medios de integración entre éstos. Por otra parte, se define también el modelo de datos que se utilizará para dar soporte y persistencia a la aplicación. Herramientas complementarias: Este capítulo define una serie de herramientas que, si bien no forman parte directa del sistema, complementan su funcionalidad. Cada herramienta posee una descripción de su funcionalidad y su objetivo, y como dicha funcionalidad permite extender la funcionalidad ofrecida por el sistema mismo. Comparativa con soluciones existentes: Habiendo definido las cualidades principales del sistema, y cómo éste afronta los problemas detallados en los sistemas de monitoreo actuales, se realiza un breve análisis de cómo se comporta el sistema propuesto con uno de los productos más utilizados en el campo de monitoreo y administración de infraestructura de Centros de Procesamiento de Datos. Evolución a futuro: Este capítulo enumera una serie de aspectos a mejorar, definiendo el inicio de lo que puede ser un roadmap de desarrollo del diseño propuesto. Dichos aspectos de mejora se enfocan en afrontar nuevas tendencias en la operación de los CPDs. Conclusiones: El capítulo final recapitula las características principales del sistema, y las contrasta con la problemática del desarrollo e instalación de un sistema de monitoreo en un Centro de Procesamiento de Datos de Misión Crítica. Cada característica se detalla en ventajas y desventajas, junto con los medios implementados para mitigar sus desventajas, y como ésta resuelve uno o varios aspectos puntuales de la problemática planteada. 6 de 105

8 3 Centros de Procesamiento de Datos 3.1 Concepto General Se denomina Centro de Procesamiento de Datos (CPD) al establecimiento y su respectiva infraestructura destinada al alojamiento y mantenimiento de equipamiento y sistemas informáticos. Dicho equipamiento es utilizado para ofrecer servicios de procesamiento de datos a clientes que lo contratan en base a parámetros tales como disponibilidad, confiabilidad y seguridad ofrecida por la empresa operadora del CPD (Proveedor), generalmente pactados en el contrato como Service Level Agreement (SLA). Dependiendo del contrato establecido con el cliente, el equipamiento puede ser propiedad del Proveedor, o puede ser entregado por el cliente, ofreciéndole la operadora los servicios de conectividad y disponibilidad de servicios subyacentes necesarios para su funcionamiento. Un CPD se conforma por una serie de sistemas tanto físicos como lógicos (cada uno con propósitos particulares) que brindan una estructura de soporte para el funcionamiento del equipamiento instalado. Estos sistemas son los que brindan los distintos servicios básicos que posibilitan el funcionamiento del CPD, ya sea directa o indirectamente. Dependiendo de cómo su mal funcionamiento afecta a la prestación de los servicios del CPD a sus clientes, se clasifican en: Servicios primarios: Se denominan servicios primarios a aquellos que forman parte del servicio prestado por el CPD a sus clientes, como puede ser el servicio de red que permite el acceso al exterior a un equipo instalado en el CPD. Esto implica que su mal funcionamiento afecta directamente al servicio prestado. Debido al impacto percibido por el cliente, si el funcionamiento de un servicio primario no es correctamente monitoreado y mantenido, se puede incurrir en un incumplimiento del SLA que puede conllevar una penalización (generalmente monetaria y en forma de compensación al cliente por los daños ocasionados) al operador del CPD. Servicios secundarios: Se denominan servicios secundarios a aquellos que complementan a los servicios primarios, por ejemplo el servicio de ventilación, en el cual una caída de duración breve resulta transparente para cliente. Esto implica que su mal funcionamiento no necesariamente impacta de forma directa en el cliente del CPD. Más allá del impacto menor que generan estos servicios, los mismos deben recibir un monitoreo y mantenimiento igual de riguroso que un servicio primario. La gran diferencia respecto a los servicios primarios es que algunos secundarios pueden recibir mantenimiento más agresivo, pudiendo detener el servicio de manera inesperada por cortos períodos de tiempo. Sin embargo siempre se 7 de 105

9 deberá realizar un breve análisis de dichas operaciones, contemplando el costo de mantenimiento adicional requerido para restaurar el servicio y la normalidad de operaciones en el CPD una vez que se hayan realizado las tareas de mantenimiento necesarias. 3.2 Clasificaciones según performance en las operaciones Existen muchas medidas por las cuales se pueden comparar las operaciones de distintos CPDs, pero no todas reflejan fielmente la calidad del servicio de éstos, o no se pueden alcanzar resultados concluyentes debido a la cantidad de variables que se deben analizar. Es por ello que el Uptime Insitute 1 definió una clasificación básica de 4 niveles para calificar la infraestructura y las operaciones de los CPDs 2 : Tier 1: CPDs que cuentan con capacidad instalada suficiente para soportar la operación de todos los equipos instalados (considerando que no existen espacios sin asignar). Tanto las tareas de mantenimiento mayores, que requieren dejar fuera de línea a todos o una porción significativa de los equipos del CPD, como también cualquier problema o siniestro en cualquier servicio primario o secundario, impactan sobre los servicios provistos a los clientes del CPD. Tier 2: CPDs que califican como Tier 1, pero cuentan con infraestructura redundante de servicios secundarios. Esto permite evitar la baja de los servicios prestados cuando se debe efectuar mantenimiento sobre un equipo de servicio secundario. Los servicios primarios siguen afectando directamente al servicio prestado. El equipamiento redundante no presenta la misma capacidad de servicio que todo el equipamiento principal instalado (la redundancia no es 1:1 sino que un equipo redundante se utiliza para sustituir a 1 de N equipos frente a una falla). Tier 3: CPDs que califican como Tier 2, pero cuentan con plena redundancia de servicios primarios y secundarios. Esto permite que cualquier tarea de mantenimiento pueda realizarse sin necesidad de detener los servicios prestados a los clientes. A su vez, todos los componentes redundantes tienen la capacidad de continuar la operación del CPD si se dejan fuera de línea a todos los componentes principales (redundancia 1:1). 1 Instituto dedicado a la emisión de estándares y publicación de documentos en el campo de operación de CPDs, abarcando tanto temas generales como certificaciones de calidad hasta metodologías de operación específicas. 2 Clasificación definida por el Uptime Institute en la publicación Data Center Site Infrastructure Tier Standard: Topology 8 de 105

10 Tier 4: CPDs que califican como Tier 3, pero tienen la capacidad de actuar de manera automática frente a un problema o siniestro, asegurando que la menor cantidad de servicios se vean afectado. Este tipo de infraestructura requiere contar con sistemas de monitoreo en tiempo real de los servicios tanto primarios como secundarios, asociado junto con equipos de conmutación de rutas de distribución de servicios, que permiten poner en marcha los sistemas redundantes para cubrir la baja de los principales. A su vez se requiere que todos los equipos redundantes se mantengan aislados físicamente de los principales, para minimizar el impacto de un siniestro o problema que afecte a una zona física en particular. Este tipo de CPDs son los que se consideran como de Misión Crítica y son para los cuales se propone el diseño del Sistema de Monitoreo y Gestión de Eventos propuesto en este trabajo. 3.3 Concepto de Misión Crítica Misión Critica es una característica que se le atribuye generalmente a los sistemas que representan el núcleo de operaciones de una empresa. Dicha empresa depende fuertemente del sistema para poder realizar sus operaciones diarias, y su indisponibilidad puede significar pérdidas masivas tanto monetarias como de imagen frente al cliente. También pueden impactar directa o indirectamente a otras empresas u organizaciones; la caída del sistema de la bolsa de New York puede afectar a cientos de compañías e individuos por sumas de dinero astronómicas. Así como la empresa depende del sistema para su funcionamiento, el sistema a su vez requiere de una serie de servicios para poder funcionar, como un equipo en el cual ejecutarse, un motor de base de datos sobre el cual mantener su información, entre otros. Analizando estas dependencias entre elementos se puede ver una relación en cadena entre grupos de servicios, siendo encabezados por la empresa (que en realidad se compone de varias unidades funcionales que utilizan distintos componentes del sistema), seguido por el sistema (que se compone por componentes que utilizan distintos servicios subyacentes para operar). 9 de 105

11 Funcionando este conjunto de sistemas como un todo a modo de cadena de subsistemas, sufre de la misma debilidad que afecta a toda cadena de elementos: el conjunto es tan robusto como el más débil de sus componentes. Esto implica que teóricamente el Sistema de Misión Crítica tendrá un nivel de disponibilidad igual al menor nivel de disponibilidad de los sistemas que le dan soporte a su ejecución. Es por ello que para asegurar su funcionamiento se deberá elevar el nivel de servicio de todos los sistemas subyacentes. Sin embargo las instalaciones que cumplen con estos requisitos tienen un costo mucho mayor, y requieren un grado de mantenimiento y monitoreo significativo, además de herramientas, contratos con proveedores especializados y personal entrenado. Debido a la alta inversión en infraestructura y mantenimiento que se debe realizar para poner en marcha uno de estos sistemas, es poco común que una empresa mantenga sus sistemas in-house, por lo que recurren a servicios de terceros que se responsabilicen por proveer y administrar todos los servicios subyacentes requeridos para poder mantener en funcionamiento al sistema de Misión Crítica. Dichos proveedores operan CPDs que cumplen con todos los requerimientos de disponibilidad y confiabilidad que requiere el cliente, y se los denominan CPDs de Misión Crítica por el tipo de sistemas que suelen hospedar. 3.4 Características de Misión Crítica Disponibilidad: El requerimiento de disponibilidad impone la necesidad de poder asegurar que los servicios hospedados en el CPD se encontrarán disponibles un X% del tiempo de servicio por año (o plazo acordado en el SLA). Esto requiere que los servicios internos se encuentren estructurados de manera tal que ante un siniestro o evento no controlado las instalaciones puedan operar lo más cercano posible a condiciones normales. Confiabilidad: Vinculado con el requerimiento de disponibilidad, el requerimiento de confiabilidad apunta al aseguramiento de la continuidad de las operaciones del CPD frente a desastres. Esto implica que, para mantenerse operativo, el CPD debe contar con mecanismos de auto-recuperación, mecanismos redundantes u otras tecnologías para poder mantener el servicio aún cuando parte de las instalaciones queden fuera de línea. Tiempo real: El requerimiento de tiempo real refiere a la necesidad de una alta velocidad de respuesta. Este requerimiento en particular no es común a todos los CPDs de Misión Crítica, pero es un factor requerido por muchas aplicaciones. Los CPDs que cumplen con este tipo de requerimientos son generalmente destinados a hospedar sistemas transaccionales (como el sistema de la bolsa fr valores), o sistemas que se encargan del análisis de fuentes de datos que se actualizan en tiempo real. Desde el punto de vista técnico, este requerimiento 10 de 105

12 implica el control de la velocidad de respuesta y transferencias de datos en el CPD, requiriendo la instalación de equipo adicional para el monitoreo y administración de los enlaces de conexión, que actúen en el acto frente a un problema de comunicación. Esto último generalmente es verificado por el cliente cuando se requiere desplegar sistemas distribuidos en el CPD, lo que implica que se hará un uso intensivo de los enlaces de conexión entre los equipos. Monitoreo: Para poder mantener las características previamente mencionadas resulta imperativo tener conocimiento total del estado de funcionamiento del CPD. Los servicios de monitoreo, útiles para quienes operan el CPD y realizan su mantenimiento, permiten detectar tempranamente posibles fallos a futuro o tendencias desfavorables de funcionamiento, controlar que cualquier operación de mantenimiento previamente hecha opere correctamente, entre otras. Gracias a estas capacidades es posible realizar mantenimiento preventivo, evitando los problemas que pueden surgir por cualquier tipo de falla, que pueden implicar elevadas penalizaciones por infracción del SLA acordado con el cliente. 11 de 105

13 4 Monitoreo en Centros de Procesamiento de Datos 4.1 Objetivo del Monitoreo en Centros de Procesamiento de Datos El monitoreo dentro de un CPD tiene como objetivo centralizar la información correspondiente al funcionamiento de los distintos elementos que lo componen para poder facilitar la detección de fallas. Un sistema de monitoreo complementado con procedimientos de seguimiento del estado del CPD y análisis de tendencias de funcionamiento le permite al Proveedor maximizar su tiempo de servicio del CPD. Frente a una falla, el sistema deberá y se limitará a reportar la situación dada a los sistemas y/o personal necesario para tomar acción. Este tipo de alertas permiten minimizar los períodos de tiempo que una situación problemática permanece desatendida, permitiendo según la naturaleza del problema minimizar daños al equipamiento, maximizar el tiempo en servicio o prevenir el desencadenamiento de un problema a gran escala. Si el sistema mismo actúa frente a una falla, se lo considera no sólo como sistema monitor, sino también como sistema de contingencias. 4.2 Estado del arte En la actualidad existen muchas soluciones de monitoreo de CPDs que toman distintos enfoques sobre qué elementos se controlan dentro de las instalaciones. Esto se debe principalmente a la multiplicidad de elementos que son susceptibles a ser sensados en la infraestructura que utiliza el CPD para llevar a cabo sus operaciones y su arquitectura de sistemas utilizada para brindar sus servicios. Dado que estos dos grandes grupos de variables a controlar son significativamente distintas, muchas soluciones suelen enfocarse en uno de los dos campos en particular, optimizando su forma de funcionamiento e interacción con el usuario para maximizar sus prestaciones para dicho campo. Por otra parte, muchas de estas soluciones involucran parte de la funcionalidad de administración de Infraestructura, orientada a procesos automáticos para la atención de situaciones previamente definidas por un administrador. Dichos procesos suelen ser inflexibles en cuanto al grado de libertad de las acciones a tomar, y generalmente se orientan a tratar con tipos de acciones predeterminadas, como puede ser la administración de la red interna del CPD. Dado que ya presentan un componente de administración, la mayoría de las soluciones de menor calibre, orientadas a la administración de entornos relativamente pequeños, no ofrecen buenas cualidades de integración con otros sistemas que permiten un control más fino y detallado de las instalaciones. 12 de 105

14 Por último, dado que los sistemas no ofrecen la totalidad de la funcionalidad para establecer un sistema de monitoreo, administración y control en todos sus aspectos, las soluciones de gran magnitud ofrecen medios de integración con otros sistemas, como puede ser un sistema de data mining o predicciones que permitan establecer forecast del funcionamiento del CPD. Sin embargo, con excepción de unos pocos, la integración con algún producto particular es favorecida por sobre la capacidad de libre integración, imponiendo barreras en la implementación de middleware para interconexión de otros sistemas con el sistema de monitoreo actual. 4.3 Elementos Típicamente Monitoreados Una primera clasificación de los elementos que componen el CPD los divide en 2 grupos de acuerdo a su función: elementos primarios y secundarios. Los elementos primarios son aquellos que brindan los servicios primarios, es decir, los elementos que soportan al servicio principal que se brinda a los consumidores del CPD. Ejemplos de elementos primarios son: servidores, servicios (aplicaciones, web, servicio de nombres de dominio (dns), bases de datos, hosting, etc), dispositivos de red como enrutadores (routers) o conmutadores (switches). Los elementos secundarios son aquellos que brindan la infraestructura y medios físicos para soportar la ejecución de los servicios primarios. Estos comprenden: cableado eléctrico, sistemas de energía ininterrumpida, generadores, acondicionadores de aire, dispositivos de detección de intrusión física, control de acceso, entre otros. A su vez, los elementos pueden ser clasificados de acuerdo a su naturaleza: elementos físicos y elementos lógicos. Por ejemplo, un servicio de base de datos no se monitoreará de la misma manera que la temperatura de una zona y habitación particular, ya que son de distinta naturaleza. Sin embargo, ambos elementos aportarán un punto de monitoreo de interés para ser tenido en cuenta al momento de analizar el estado del CPD. Las magnitudes físicas, en general, suelen corresponderse con los servicios secundarios tales como: temperatura, humedad, niveles de tensión de suministro eléctrico, nivel de combustible en los generadores, las cuales suelen ser obtenidas mediante el uso de sensores. Estos sensores poseen internamente mecanismos que permiten transformar las magnitudes medidas en señales digitales, permitiendo que esa información pueda ser accedida por un sistema externo. Por otra parte, los sistemas lógicos pueden comprender elementos tanto de los servicios primarios como de los servicios secundarios. El acceso a la información de los sistemas lógicos se realiza mediante la utilización de protocolos de comunicación, los cuales pueden 13 de 105

15 ser propietarios o estándar. Algunos ejemplos de sistemas lógicos son los servicios de conectividad que puedan brindar la infraestructura de networking, como así también información general del funcionamiento de un equipo: espacio en disco, utilización de procesador, ancho de banda utilizado en las interfaces de red y otros. Si bien no es posible monitorear la totalidad de elementos que forman un CPD, se tiende a monitorear todos aquellos elementos que en caso de falla puedan llegar a impactar negativamente en la prestación de sus servicios. A su vez, como medida preventiva también se suelen monitorear aquellos parámetros que pueden ser indicadores de una posible falla, los cuales con el debido análisis permiten detectar de forma temprana problemas potenciales. 4.4 Sensores Concepto General Un sensor es un dispositivo que mide una magnitud física y la convierte en algún tipo de señal de características adecuadas para ser interpretada por un observador o sistema. Para integrarse al sistema de monitoreo, un sensor debe poder comunicar su estado de manera digital o, en caso contrario, contar con un transductor que permita comunicar en forma digital el estado del sensor asociado. El sistema monitor actuará en base al estado de todos los sensores integrados a éste, según la lógica de análisis que utilice (las formas más sencillas corresponden a comparaciones de valores límite o conteo de ocurrencias, entre otros). Según el tipo de alerta emitido, se pueden movilizar sistemas de contingencia o personal de mantenimiento. Los sensores con salida de tipo digital pueden ser clasificados en dos categorías: Las salidas de estado suelen representar situaciones discretas en un elemento medido, ya sea porque el evento registrado es discreto (como puede ser el estado de apertura de una puerta), o porque si bien se trata de una magnitud variable, se establecen rangos de clasificación de estados (se establecen límites de valores para cada estado que se comunica). Este tipo de señales generalmente se aplican para la detección de cambios a cierto estado, o conteo de ocurrencias. En ciertos casos también existe la posibilidad de realizar un seguimiento de los estados por los cuales pasa el elemento medido, para verificar que siga un patrón esperado. 14 de 105

16 En cambio, las de salida de magnitud representan conversiones directas de una o más variables medidas en un elemento. Este tipo de señales suelen utilizarse para diversos tipos de análisis, desde una transformación a estados discretos, cálculos de promedios y desvíos, hasta pronósticos estadísticos de su evolución. Estos últimos tipos de análisis suelen requerir un historial de la evolución del elemento medido para poder realizar los cálculos necesarios Sensores ambientales típicamente utilizados en CPDs Temperatura: Suele monitorearse ya que el exceso de calor puede ocasionar daños o perdida de rendimiento en el equipamiento debido al mal funcionamiento del sistema de refrigeración o exceso de carga en los sistemas refrigerados. Los daños físicos de los equipos pueden significar además pérdidas en el servicio. Humedad: Un ambiente húmedo puede generar la condensación de agua sobre los componentes electrónicos o mecánicos de los sistemas, generalmente debido a un mal funcionamiento del sistema de refrigeración. El agua condensada puede causar cortocircuitos en el equipamiento, teniendo como consecuencia el mal funcionamiento de sus circuitos e incluso daños a sus componentes. En los dispositivos mecánicos, la humedad puede generar corrosión, afectar lubricantes o incluso generar esfuerzos innecesarios por aumento de la fricción. Humo: Este tipo de sensores son aplicados generalmente como detectores contra incendios, debido a que la combustión de los elementos en una habitación suelen generar humo. Sin embargo es posible que dispositivos emanen humo aún cuando no se ha generado llama, como el caso de un cortocircuito en donde los cables pueden llegar a calentarse a elevadas temperaturas y comenzar a desprender humo del calentamiento del aislante o de los artefactos. Ambas situaciones deben ser monitoreadas, pero deben poder distinguirse a la perfección dada la diferencia de magnitud del siniestro que representan. Movimiento: Suelen utilizarse para detectar la intrusión de personas no autorizadas en zonas restringidas como habitualmente lo son las salas de servidores o de equipamiento central. El principio de funcionamiento puede ser diverso, los principales métodos son: acústico, infrarrojo y electromagnético. Presencia de agua: Estos sensores se utilizan para detectar inundaciones, acumulaciones o filtraciones de agua en superficies, para lo cual sobre la superficie en la cual se quiere detectar la presencia de agua. Al momento que el agua entra en contacto con el sensor, 15 de 105

17 éste se dispara y activa la señal que indicará que se detecta la presencia de agua. Esta clase de sensores es útil en zonas de inundaciones o incluso por precaución en caso de rotura de alguna tubería de agua. Rotura de Vidrios: Utilizan un principio de funcionamiento acústico, ayudado por un sistema de reconocimiento de patrones de sonido que permite identificar la rotura de vidrios. Ayudan como medida de seguridad para la detección de intrusión forzada a recintos restringidos. Apertura de Puertas: Estos sensores pueden ser utilizados en conjunto con sistemas de alarma o monitoreo, y ser de utilidad para levantar notificaciones en caso de que se abran puertas en horarios no autorizados. 4.5 Mensajería en Sistemas Concepto General El mecanismo de mensajería de sistemas refiere al medio de comunicación utilizado por los elementos que son susceptibles de ser medidos que no se encuentran asociados de manera directa a un dispositivo sensor, sino que constan de fuentes de datos mantenidas por sistemas activos en algún equipo del CPD. La principal diferencia entre este tipo de variables y las cubiertas por sensores es que este tipo de variables refieren generalmente al propio estado del sistema que las genera, y no al estado del CPD en general (existen puntos intermedios, por ejemplo aquellas aplicaciones que monitorean el estado de la red principal del CPD). Estas fuentes de datos presentan una gran ventaja, que radica en el hecho de que se anula la necesidad de interactuar de manera directa con dispositivos de hardware. Si bien existen sensores que exponen su información de manera sintética y fácilmente accesible programáticamente, existen tantos otros que requieren un medio de conexión físico directo contra el dispositivo para poder obtener sus lecturas. A su vez, en muchos casos permite la asociación de triggers (mecanismo de notificación de eventos) que permiten simplificar la comunicación con el Sistema de Monitoreo y Gestión de Eventos ya que se delega a la fuente de datos la responsabilidad de notificar su actualización. Sin embargo, estas fuentes de datos no siempre exponen un método sencillo para acceder a sus contenidos. Así como existen sistemas que tienen por objetivo publicar sus datos a cualquier sistema que desee utilizarlos, existen otros tantos sistemas (generalmente forman parte de suites con formatos propietarios o interfaces de acceso ofuscadas y/o no 16 de 105

18 documentadas) que presentan métodos complejos difíciles de aplicar o comprender, con el objetivo de promover el uso de las herramientas desarrolladas por su mismo creador Comunicaciones basadas en polling El método de polling representa el esquema de actualización de datos más sencillo de implementar. Se basa en el hecho de que una aplicación almacena los datos generados en algún medio, dispositivo, sistema de archivos o de bases de datos de fácil acceso. Esta información luego puede ser accedida por el Sistema de Monitoreo, ya sea de forma anónima o por medio de uso credenciales para autenticación, y por lo general se mantiene actualizada de forma periódica. Polling de historiales o archivos de datos: La forma más básica de polling se enfoca en acceder de manera directa a estos datos, a intervalos regulares de tiempo. Esto implica que el módulo encargado de acceder a estos datos debe acceder al archivo, dispositivo o base de datos en donde se almacenan dichos datos y verificar si éstos se actualizaron respecto a la última consulta, en cuyo caso deberá extraer los datos nuevos (en caso de que se acceda a un historial completo) y comunicarlos al sistema. Como se puede apreciar por su forma de funcionamiento, el sistema que genera los datos, y el módulo que los monitorea no interactúan de forma directa sino a través del medio utilizado para almacenar dichos datos. Esta arquitectura tiene la ventaja de poder monitorear aplicaciones que no fueron diseñadas para ser monitoreadas, pero conlleva la desventaja de que en muchos casos no se cuenta con la estructura lógica con la que los datos fueron almacenados, siendo necesario realizar procesos de ingeniería inversa para poder deducir dicha estructura. Más aún, puede darse el caso de que la información a la que se acceda se encuentre medianamente redactada en archivos de log, cuyos propósitos son principalmente brindar una descripción legible en algún lenguaje a un administrador de sistema sobre eventos ocurridos en el sistema. En estos casos la extracción de datos es más delicada, ya que dependiendo de cómo se redacte, puede ser más complicado establecer un algoritmo que pueda interpretar correctamente todas las entradas de dicho log. Por último, esta técnica puede ser causa de muchos problemas si no se aplica con cierto criterio. El principal problema que posee es la necesidad de establecer intervalos de tiempo sobre los cuales se accede a la fuente de datos. Este intervalo es inversamente proporcional a la velocidad de respuesta promedio ante la actualización de datos por parte del sistema 17 de 105

19 monitoreado. Es imperativo que dicho intervalo sea definido cuidadosamente, ya que un intervalo muy alto podría implicar retrasos significativos en la actualización de datos, y uno muy bajo imponer una sobrecarga innecesaria sobre el equipo en que se ejecuta, en especial cuando se deben interpretar grandes volúmenes de datos en texto plano. Polling de interfaces remotas: Evolución de la metodología anterior, enfocada principalmente en resolver los problemas de seguridad y acceso que ésta presenta. Internamente funciona como polling de archivos de datos, pero contiene la lógica necesaria para exponer una interfaz, la cuál puede ser utilizada por otros sistemas. Componentes que implementan estos métodos de conexión suelen funcionar como intermediarios entre la fuente de datos y el sistema monitor, logrando eliminar su necesidad de tener acceso directo al recurso monitoreado. Este tipo de interfaces pueden encontrarse desarrolladas como parte del sistema monitoreado o como un módulo independiente, cuyo desarrollo puede presentar los mismos problemas de sobrecarga del sistema con intervalos de consulta muy cortos (en especial si se trata de módulos desarrollados por empresas ajenas a la que desarrolló el sistema monitoreado). Es por ello que se deben tener las mismas consideraciones que en la metodología anterior al momento de establecer el período de los intervalos entre consultas. Sin embargo, como se mencionó anteriormente, esta metodología tiene varias ventajas. Al exponer un medio de acceso programático se simplifica considerablemente el desarrollo necesario para realizar el acceso a datos. Adicionalmente la interfaz remota puede contener la implementación de manejos de errores propios para el acceso de información, reportando el error apropiado para el dominio de la aplicación que la accede, o incluso un manejo interno que permita mantener el acceso remoto, generando transparencias para el sistema remoto frente a dichos errores. Por último, en caso de que el componente sea un elemento externo al sistema de monitoreo puede cumplir la función de Gateway de información entre dos zonas que se encuentran parcialmente aisladas (zonas a las que el sistema de monitoreo propiamente dicho no puede acceder de manera directa). Polling de feeds o informes de estado: Extensión de la metodología anterior, enfocada en la simplificación del método de acceso, y en la minimización de los problemas de sobrecarga por consultas a intervalos muy cortos. La principal diferencia de funcionamiento respecto a las metodologías anteriores es que ésta establece su propio intervalo interno de actualización de datos, desligándose el acceso a datos de las peticiones externas. 18 de 105

20 La simplificación del método de acceso se logra gracias al uso del protocolo HTTP. La implementación final puede variar, siendo desde una interfaz con la que se puede interactuar como puede ser un webservice, hasta un simple punto de información que expone todos los datos pertinentes al servicio, sin importar qué partes de éstos son relevantes para el sistema remoto que los consume. Para soportar altos niveles de concurrencia y de demanda de información se establece un intervalo propio en el que sus datos expuestos son actualizados. Esto permite controlar la carga de procesamiento de datos, y los datos ya procesados pueden ser almacenados en un medio de alta velocidad de acceso como puede ser en memoria, para garantizar tiempos de respuesta mínimos. Si bien esta metodología presenta mejoras significativas, la incorporación del protocolo HTTP acarrea una serie de inconvenientes de uso propios de éste. Hoy en día las redes de comunicación de cualquier entorno corporativo poseen un nivel de complejidad tal que todas las comunicaciones atraviesan ciertos componentes que permiten reducir la carga de la red, y simplificar su administración (cachés y proxys). Una configuración errónea en estos componentes puede perjudicar a esta metodología de comunicación, llegando incluso a imposibilitar la comunicación con el elemento que se desea monitorear Comunicaciones basadas en notificación de eventos Concepto general El método de notificación de eventos presenta un mecanismo más avanzado que el método de polling. A diferencia del método anterior, el sistema monitor delega la actividad de detectar actualizaciones en la fuente de datos al módulo que la controla. Esto le permite minimizar la cantidad de comunicaciones realizadas con el módulo de control para determinar si hubo o no cambios. Por otra parte, al igual que la metodología de polling, existen múltiples implementaciones de mecanismos de notificación de eventos, pero en este caso pueden diferenciarse por múltiples factores en vez de únicamente por su principio de funcionamiento Mecanismos de notificación Una de las propiedades que define a un mecanismo de notificación de eventos es cómo se implementa la notificación propiamente dicha. Se denomina notificación a una llamada al sistema monitor que hace las veces de señal indicadora de actualización de datos. Principalmente existen dos tipos de implementaciones: 19 de 105

21 Suscripción de contactos: Se considera como contacto a una pequeña unidad de programa que respeta una interfaz definida por el módulo de control. Al ser notificado de actualizaciones dicho contacto se encarga de realizar la llamada al sistema de monitoreo al que representa, pudiendo pasar los datos actualizados o simplemente la notificación de actualización, según como se encuentre especificado el módulo de control. Este mecanismo tiene la ventaja de encontrarse basado en un patrón de diseño ampliamente probado (remote observer), y define un contrato específico de comunicaciones por medio de interfaces que se deben respetar (definición explícita del protocolo de comunicación). Sin embargo esta implementación tiene la desventaja de funcionar de manera desconectada, implicando que no siempre se mantiene un canal de comunicaciones abierto hacia el módulo de control, por lo que una pérdida de conectividad entre ambos sistemas pasa desapercibida hasta que el sistema de monitoreo, si es que se lo implementa, emite una advertencia por tener información desactualizada, o se detecte por medio de algún mecanismo de heartbeat la pérdida de conectividad entre los sistemas. Long polling: Cumpliendo con el principio de funcionamiento de los sistemas de polling, long polling permite simular un mecanismo de notificación de eventos de manera eficiente. La diferencia fundamental de este mecanismo con respecto a un mecanismo de polling normal es que al realizar una solicitud de datos al servidor, éste mantiene la conexión abierta (sin emitir su respuesta) en caso de que no haya información para transmitir. De esta manera el cliente queda a la espera de la respuesta del servidor mientras que éste espera a que haya un evento a comunicar. Su característica de retención de conexión le permite funcionar bajo la restricción de comunicación de un esquema cliente-servidor (sistema de monitoreo - módulo de control) en el cual el servidor no puede comunicar datos al cliente si previamente el cliente no inició el canal de comunicaciones. Esto se debe básicamente a que el servidor no conoce o no puede conocer exactamente cómo conectarse con el cliente (esta técnica es fuertemente explotada en el ámbito del desarrollo web, permitiendo interacciones entre cliente y servidor mucho más dinámicas). Este mecanismo permite, dada su implementación en los módulos de conectividad de bajo nivel generalmente provistos por el sistema operativo, detectar cuando se pierde conectividad con el servidor, pudiendo así manejar dicha situación en el acto. Otros mecanismos: Los dos mecanismos presentados anteriormente representan las formas fundamentales de implementación de un sistema de notificación de eventos. Sin embargo esto no implica que a la hora una implementación se limite a estas dos opciones. Con la 20 de 105

22 proliferación de los sistemas distribuidos, tanto física como lógicamente, fueron surgiendo y desarrollándose soluciones que proponían un medio común para resolver este tipo de comunicaciones. Hoy en día las mayores distribuciones de sistemas operativos poseen un mecanismo interno de comunicación entre procesos que permiten limitar la implementación a un simple enlace del sistema a dicho mecanismo (en Linux se encuentra el protocolo DCOP o DBUS y bajo Windows el protocolo DCOM) Mecanismos de detección de eventos Otra propiedad que define a una implementación de un mecanismo de notificación de eventos es el evento propiamente dicho que captura el módulo para notificar a sus suscriptores. Esta propiedad puede comprender tanto el núcleo de la implementación del módulo, así también como una simple delegación de notificaciones a uno o varios sistemas subyacentes. A su vez se debe realizar una distinción en el alcance del evento, indicando los distintos grados de granularidad que existen en las notificaciones enviadas por el módulo: Delegación de eventos: Requiere un nivel mínimo de implementación del mecanismo de eventos. El módulo simplemente requiere suscribirse a las notificaciones de eventos de los elementos que monitorea. Este tipo de construcciones generalmente se utilizan para mejorar, adaptar o extender la funcionalidad y accesibilidad del sistema de notificación de eventos subyacente. Las mejoras en la funcionalidad pueden ser desde una simple interpretación de los datos del sistema que son publicados bajo un formato más robusto que facilite su interpretación y uso, hasta un monitoreo y seguimiento de la evolución de distintos componentes del sistema ofreciendo información agregada con un análisis de la situación general del sistema que éste no ofrece de forma directa. Estas implementaciones se especializan en sistemas distribuidos y generalmente consisten en implementaciones específicas aplicables a una única configuración de sistemas. Las adaptaciones de interfaces y extensiones de accesibilidad de forma aislada suelen encontrarse en implementaciones de menor tamaño, que tienen el propósito de facilitar la integración de las fuentes de datos a un sistema de monitoreo, brindando una interfaz estándar a todas las fuentes, y un punto de acceso a todos los sistemas que en caso contrario no serían directamente accesibles. 21 de 105

23 Notificación periódica: Comprende el mecanismo más básico de un sistema de notificación de eventos. Su principio de funcionamiento se basa en la solicitud de datos a la fuentes de datos a intervalos regulares, seguida de una inmediata notificación al sistema de monitoreo. Estas implementaciones pueden ser efectivas para fuentes de datos actualizadas en tiempo real. Actualización de fuente de datos: Comprende el mecanismo de un sistema que abarca por completo la definición de sistema de notificación de eventos. Su principio de funcionamiento hacia la fuente de datos se basa en la metodología de polling, e internamente realiza un seguimiento de la evolución de los datos para poder detectar cambios en éstos. Esto implica que debe contar con alguna clase de algoritmo que le permita procesar de la forma más rápida posible las diferencias entre los datos expuestos en la última solicitud y los de actual. Este tipo de implementaciones son sistemas de notificación de eventos completos, ya que basándose en el mecanismo de polling para la obtención de datos permiten generar eventos a los cuales otros sistemas pueden suscribirse. Si bien este mecanismo es completo, existen tipos de implementaciones más avanzadas. La implementación básica de este mecanismo tiene la desventaja de que si la fuente de datos provee exceso de información, de la cual sólo una porción es útil para un sistema suscripto, pueden generarse notificaciones que en la práctica no surten efecto alguno, incurriendo en esfuerzo de procesamiento desperdiciado. Actualización de conjunto de datos: Extendiendo el funcionamiento del mecanismo anterior, los sistemas de notificación basados en actualizaciones de conjuntos de datos permiten refinar qué se puede considerar como un evento para el sistema suscripto. Esto se basa en el hecho de que el módulo de control presenta la capacidad de poder definir algún medio de detección que se enfoque en una parte de la información brindada por la fuente de datos, y pueda determinar si dicha porción de información se actualizó. La implementación de este tipo de mecanismos varía fuertemente según la forma en que la fuente de datos presenta su información. Cuanto más estructurada se encuentre, más sencilla será la implementación, ya que implicará un menor esfuerzo el identificar los distintos bloques o conjuntos de datos por los que se encuentra compuesto; es más sencillo detectar si el contenido de un nodo de un archivo XML se modificó que detectar si lo hizo parte de un log en texto plano. 22 de 105

24 5 Requerimientos del sistema propuesto 5.1 Premisas de diseño Partiendo de las propiedades que caracterizan a todos los sistemas que se encuentran en un CPD de Misión Crítica y con el objetivo de maximizar el valor y la relevancia en el tiempo del sistema propuesto, es necesario establecer un conjunto de premisas de diseño. Dichas premisas establecen qué características deberán cumplirse en todos los componentes del sistema, sirviendo de guía al momento de analizar distintas posibilidades de implementación o diseños de arquitectura. Si bien no todas las premisas son significativamente aplicables en todos los componentes del sistema, es mandatorio que nunca se realice un diseño que atente de forma directa contra éstas. Extensibilidad ilimitada: Esta propiedad se enfoca en la incorporación de nuevos componentes que permitan ampliar la funcionalidad del sistema, o incluso incorporar una nueva tecnología que no exista o no sea relevante en el campo hoy en día. Para ello el diseño deberá enfocarse en la distribución de lógica de funcionamiento, de manera tal que se provean medios de simple acceso que permitan el desarrollo de nuevos componentes, y que estos sean fácilmente integrables a los módulos del sistema, requiriendo el menor grado de alteraciones posible (modificación del comportamiento propio del sistema). Si se logra una perfecta modularidad, la incorporación de un nuevo componente no requeriría la modificación de ningún otro componente, por lo que éstos podrían ser actualizables según se liberen correcciones futuras del sistema. Plataforma abierta: Esta propiedad, relativa al punto anterior, apunta al desarrollo con APIs documentadas de fácil acceso. La definición de la API permite que un tercero pueda hacer uso de un componente particular del sistema (extender la funcionalidad del sistema requiere un mecanismo interno para hacer pública esa nueva funcionalidad), por lo que en el futuro, si la funcionalidad de un módulo es superada por otra aplicación, dicha aplicación tendrá la posibilidad de integrarse al sistema para adquirir la funcionalidad de los módulos restantes. Gracias a esta facilidad de integración, el sistema podrá ser relevante por un período más prolongado, ya que si bien en el futuro parte de su funcionalidad será obsoleta, la otra parte será aún utilizable sin requerir cambios al sistema propiamente dicho. Diseño multi-capa: Esta propiedad apunta al desacoplamiento entre módulos lógicos del programa, que permite un grado de flexibilidad tal que, siempre y cuando se respeten las interfaces previamente definidas, los elementos de una capa puedan ser reemplazados por otros más nuevos o más extensos sin la necesidad de realizar cambios en el resto de las 23 de 105

25 capas. De esta manera cualquier individuo que desee extender la funcionalidad del núcleo del sistema podrá trabajar sobre la capa relevante a sus objetivos, sin la necesidad de encarar la modificación a través de todos los módulos del sistema, reduciendo considerablemente el tiempo necesario para realizar dicho desarrollo. Diseño modular: Esta propiedad apunta a compartimentar la lógica del sistema en pequeños módulos fáciles de mantener, que definan sus propias interfaces de uso para integrarse al sistema. Junto con el diseño multi-capa y el diseño de plataforma abierta se puede lograr un diseño altamente flexible y resiliente a la obsolescencia, ofreciendo excelentes cualidades de extensibilidad y posibilidades de actualización. Más aún, estas tres propiedades de diseño complementan a la propiedad de extensibilidad ilimitada, obteniendo un esquema de desarrollo e integración bien definido que permite simplificar ampliamente las tareas de desarrollo de nuevos componentes. Estructura de datos flexible: Esta propiedad apunta a permitir el almacenamiento de información adicional de todos los elementos con los que interactúa el usuario en el sistema. De esta manera, futuros desarrollos pueden hacer uso de esa información adicional (la cual tendrá una estructura definida por el usuario) para ofrecer funcionalidad extendida, sin la necesidad de alterar el esquema de datos y toda la lógica de acceso a datos. Resiliencia a fallas: Para asegurar la disponibilidad del sistema es necesario que el mismo tenga un buen manejo de errores. Esto implica que el diseño deberá contemplar todas las situaciones posibles de error y definir cómo actuar frente éstas. Dicha acción deberá minimizar el impacto del error en el funcionamiento general del sistema y afectar a la menor cantidad de componentes posibles. Siempre se deberán reportar los errores frente a situaciones inesperadas y exponer el máximo nivel de detalle posible para brindarle al administrador del sistema una clara visión de la situación ocurrida. 5.2 Características de Arquitectura Plataforma de desarrollo y ejecución: En la actualidad existe una serie de familias de sistemas operativos que no son directamente compatibles entre sí, lo que implica que cualquier aplicación que fuese desarrollada originalmente para correr sobre una plataforma determinada probablemente no pueda ser ejecutada en otra, o al menos requiera cierta modificación y re-empaquetado de la misma. Esta disparidad de plataformas se hace presente en los CPDs, en donde no necesariamente se cuenta con la disponibilidad de cualquiera de éstas. Es por ello que resulta imprescindible contar con un lenguaje que sea compatible con todas las plataformas, que a su vez sea lo suficientemente robusto para 24 de 105

26 permitir diseños estables, escalables y con buenos índices de rendimiento, y que al mismo tiempo permitan una orientación modular para mejorar las cualidades de extensibilidad y mantenimiento del sistema desarrollado. Cualidades de escalabilidad: Dado que un CPD no se caracteriza por tener un tamaño en particular, es necesario tener en cuenta que la cantidad de elementos con la que operará el sistema en un ambiente de producción podrá variar considerablemente. Esto requiere que el diseño se encuentre preparado para poder operar con grandes volúmenes de elementos activos (ya que a mayor cantidad de elementos se requerirá un mayor poder de procesamiento), cada uno configurado con requerimientos de procesamiento particulares. Facilidad de acceso a la configuración: Es de gran importancia que un sistema que complementa las actividades de mantenimiento de un CPD presente facilidades de configuración para usuarios remotos. Esto se debe a que no siempre el administrador de un CPD se encuentra on-site, por lo que el acceso remoto representa una herramienta muy útil para sus tareas. Considerando la naturaleza de las tareas que un administrador realiza, es indispensable contar con una herramienta de configuración lo más sencilla posible, y que sea fácilmente integrable con conjuntos de tareas predefinidas para ejecutar tareas rutinarias a modo batch. Facilidad de uso: La facilidad de uso de un sistema en el contexto de interfaz gráfica apunta a cuan sencilla es la misma para lograr realizar una tarea determinada. La simplicidad de una interfaz contempla características tales como la disponibilidad de información necesaria o el recorrido a través de distintas pantallas que es requerido para completar una tarea, sin descuidar la relevancia de los datos mostrados al usuario. Esto implica que se mostrarán exclusivamente los datos que sean relevantes al usuario, de manera ordenada. Por otro lado se encuentra la cualidad intuitiva de la interfaz, que describe que tan críptica es dicha interfaz para su uso. Una interfaz intuitiva implica una estructuración lógica de los datos mostrados por pantalla, en donde todos los componentes poseen alguna referencia sobre su comportamiento u objetivo, requiriendo una cantidad mínima de documentación para poder describir el funcionamiento de toda la interfaz. Ambos conceptos se encuentran relacionados con el concepto de curva de aprendizaje, el cual describe cómo se adapta el usuario con el tiempo a utilizar el sistema de manera automática. Mientras más sencilla e intuitiva sea la interfaz más empinada será la curva, lo que implica una mejor adaptación en un menor período de tiempo. 25 de 105

27 5.3 Alcance del diseño propuesto Servicios básicos: El diseño final presupondrá la disponibilidad de servicios básicos brindados por la plataforma de ejecución elegida, abstrayéndose del contexto operativo de una instalación particular. Es por ello que no se detallarán diseños de servicios a nivel de componentes de hardware, como así tampoco administración de recursos ni uso de interfaces de bajo nivel, que se encuentran ya abstraídas por librerías de libre disponibilidad. Todas las referencias a este tipo de implementaciones siempre hacen alusión a componentes de expansión del sistema, que no se encuentran especificados en detalle en este documento, y no hacen al diseño del sistema sino como ejemplo de una supuesta implementación que puede ser modificada o reemplazada en el futuro. Características de Misión Crítica: Si bien el diseño contemplará cómo recuperarse y actuar frente a errores del propio sistema, no contemplará cómo actuar frente a fallas en los servicios básicos. En un CPD, estos servicios básicos puedan ser dispuestos de manera que brinden un servicio continuo incluso frente a alguna falla en ese nivel, ya que el manejo de fallas de los mismos se relega al operador del CPD. Esto implica que en el contexto operativo en el que se desplegó el sistema se deberán configurar servicios que cumplan con las características de Misión Crítica. Se dejará a libre elección del administrador del sistema si se utilizará el propio sistema para monitorear los recursos que brindan los servicios de soporte al mismo, pero se deberá considerar la posibilidad de que el sistema quede fuera de línea en caso de que se presente un evento catastrófico sobre dichos recursos. Seguridad: El diseño final contemplará características de seguridad básicas de uso. Esto implica que no se abordarán consideraciones de seguridad de datos persistidos tanto para la configuración básica como la configuración funcional. A su vez no se contemplará el diseño ni la implementación específica de protocolos de comunicaciones que brinden seguridad, tanto en comunicaciones con componentes externos al sistema como entre componentes propios del mismo. El criterio de exclusión de características de seguridad se basa en que los servicios subyacentes al sistema ya contemplan un esquema de seguridad propio, por lo que su análisis no aportaría contenido significativo al diseño. Estas características excluidas deberán ser contempladas en el despliegue del sistema en su contexto operativo, y ser debidamente configuradas en todos los servicios subyacentes acorde al nivel de seguridad general esperado. 26 de 105

28 5.4 Componentes Generales del Sistema Concepto general En términos generales el sistema se considera como una serie de componentes enlazados en cadena, que permiten un flujo de entrada y de salida de información. Los distintos componentes que se detallan a continuación se pueden considerar como etapas de transformación de la información publicada por la etapa anterior. Cada etapa tiene un objetivo de transformación particular, y complementa al funcionamiento del resto de las etapas que, individualmente, no cubren la funcionalidad esperada del sistema. El flujo inicial (entrada al sistema) de información es conformado por datos de sensores y componentes externos sin procesar, mientras que el flujo final (salidas del sistema) comprende información interpretable por los usuarios del sistema Primera Etapa: Acceso a Fuentes de datos La etapa de acceso a fuentes de datos representa la frontera entre el Sistema de Monitoreo y Gestión de eventos y los Agentes (sensores y fuentes de datos). Es en esta etapa en la que se toman los datos de las fuentes utilizando distintos mecanismos de acceso, y se pasan al módulo de mapeo de datos para hacer accesibles los datos actualizados al resto del sistema. El concepto de Agente refiere a cualquier fuente de datos externa que tiene la capacidad de integrarse al Sistema. Dichos agentes pueden ser heterogéneos, teniendo cada uno un funcionamiento interno y un mecanismo de integración distinto. El mecanismo de integración se ve fuertemente influenciado por la naturaleza de los datos que maneja, particularmente si se tratan de variables medidas en tiempo real o que sólo son significativas frente a cambios. Los agentes pueden ser tanto Módulos Monitores desarrollados específicamente para el sistema, como componentes definidos por terceros ya sea por un módulo intermediario, sensor o fuente de datos que respeta ciertos estándares que permiten la comunicación 27 de 105

29 directa. Para maximizar la capacidad de integración del Sistema de Monitoreo y Gestión de eventos será necesario definir mecanismos de integración para todas las situaciones que se puedan presentar. Según su mecanismo de integración, los agentes se pueden dividir en dos grandes grupos: Agentes activos: Se identifican con el medio de comunicación de notificación de eventos. Estos agentes son componentes que realizan un seguimiento de los sensores a los que se asocian, y frente a un cambio generan un evento hacia el Sistema de Monitoreo y Gestión de Eventos para que éste lo procese según como se haya programado. Este tipo de agentes se aplica generalmente en situaciones en las que la variación de la lectura del sensor es tan significativa como la lectura misma. Un caso típico es el monitoreo de puertas, en donde los sensores detectan si se encuentra abierta o cerrada, y la apertura de la puerta es tan significativa como el hecho de que la puerta se encuentra abierta en este momento. Presenta la ventaja de minimizar la cantidad de datos transmitidos y simplificar cómo se maneja dentro del Sistema de Monitoreo y Gestión de Eventos los eventos de estos agentes. Sin embargo presenta la desventaja de distribuir la configuración del sistema en componentes externos al mismo, requiriendo la misma ser replicada cuando se realizan ciertos cambios, lo que conlleva tareas de mantenimiento más complejas. Agentes pasivos: Se identifican con el medio de comunicación de polling. Estos agentes pueden ser tanto Módulos Monitores como piezas de software de terceros o incluso el sensor mismo que publica datos para que cualquier elemento en la red pueda leerlos. La propiedad común a todos los distintos tipos de elementos que pueden clasificarse bajo esta categoría es el hecho de que respetan un protocolo de comunicación definido, que le permite al Sistema de Monitoreo y Gestión de Eventos abstraerse de la implementación del agente y concentrarse en la mera interpretación de los datos. Este mecanismo presenta la ventaja de centralizar la configuración de todos los agentes, simplificando las tareas de administración del sistema. Sin embargo presenta la desventaja de requerir mantener información de conexión para cada agente, característica que anteriormente se resolvía automáticamente ya que la conexión siempre la establecía el agente contra el sistema. Se 28 de 105

30 debe presentar una solución sencilla particularmente para los entornos de red de asignación dinámica, donde no se puede tener una referencia fija a cada agente. Una vez obtenidos los datos actualizados de los agentes, éstos son transferidos a la etapa siguiente. Resulta imperativo que todos los datos transferidos se encuentren asociados de forma unívoca al agente que lo generó, ya que los datos por sí solos no pueden representar a un agente, y en caso de que contengan dicha información, no se puede conocer el método por el cual interpretarlos ya que no se conoce su formato. Para el caso de los Agentes pasivos, al encontrarse toda la configuración centralizada en el sistema dicha asociación resulta sencilla. Sin embargo, para el caso de los Agentes activos, como la información obtenida resulta ser anónima para el sistema, será necesario desarrollar un método de asociación alternativo Segunda Etapa: Mapeo de entidades La etapa de mapeo de entidades se encarga de tomar los datos de los agentes provenientes de la etapa de acceso a datos y hacerlos disponibles a las etapas posteriores para su uso. Así como los datos de actualización se encuentran asociados directamente con un agente, es necesario establecer un vínculo entre dichos elementos y su referencia en el sistema (representación del agente en el sistema). Es para ello que se define el concepto de Entidad, la cual representa en el dominio de la aplicación a un agente externo. Es por medio de estas entidades que las etapas posteriores podrán acceder a los datos de un agente. El proceso de mapeo de entidades comienza con la búsqueda de la entidad correspondiente a los datos de actualización recibidos de la etapa anterior. Esto implica que no sólo los datos recibidos deben encontrarse asociados al agente al que pertenecen, sino también que el 29 de 105

31 agente propiamente dicho debe tener algún tipo de relación con la Entidad que lo representa en el sistema. Es en esta etapa en donde los datos que utiliza el sistema pasan de ser datos provenientes del exterior, a ser información propia de una Entidad del sistema. Una vez obtenida la entidad correspondiente será necesario realizar una transformación de los datos recibidos. Dado que los datos obtenidos del agente externo pueden tener cualquier estructura lógica, será necesario que cada Entidad conozca la forma de transformar dichos datos en información estructurada de forma tal que sea de utilidad para las siguientes etapas del sistema. Sin embargo, debido a que los datos de entrada poseen una estructura y cantidad de datos arbitraria, la entidad requerirá a su vez esa misma flexibilidad si se desea conservar toda la información recibida (el volumen de datos recibido puede variar entre agentes). Por último, una vez actualizado el estado de las entidades afectadas es necesario notificar las actualizaciones realizadas en la etapa siguiente, para que el sistema pueda procesar el nuevo estado de dichas entidades. Para evitar ejecuciones innecesarias, cada entidad deberá tener la posibilidad de especificar si su actualización de estado requiere que el sistema lo procese, o si debe ser encubierto Tercera Etapa: Manejo de Eventos y Reglas Esta etapa compone la parte central del sistema, la cual se encarga de procesar todas las actualizaciones de las distintas entidades y ejecutar todas las acciones consecuentes a éstas, según como se haya programado el sistema. Para permitirle al usuario definir el comportamiento del sistema para los distintos eventos de actualización que pueden surgir, se define el concepto de Regla. Una regla es un medio de programación, por el cual el usuario puede definir cómo deberá operar el sistema frente a un evento de actualización. Estas reglas podrán contener cualquier algoritmo matemático o lógico que se considere necesario para analizar el estado del sistema, y tendrán la posibilidad de emitir sus resultados al exterior. Es preciso tener en cuenta al momento de programar una regla, cuál es la naturaleza del evento al cual ésta se asocia. Una regla asociada al evento de una entidad que representa un agente activo ya tiene implícito el hecho de que los datos cambiaron, mientras que una asociada a un agente pasivo simplemente representa el hecho de que se solicitaron datos actualizados. Es en este último caso en el cual se debe contemplar dentro del sistema la posibilidad de que una entidad mantenga un historial de los datos recibidos, con el propósito de brindar un medio de detectar variaciones con respecto a estados anteriores. A su vez 30 de 105

32 cada regla puede requerir mantener un registro histórico de valores calculados internamente para analizarse en iteraciones posteriores, por lo que la regla misma también deberá contar con un medio de almacenamiento de datos. El primer paso de la gestión de eventos consiste en determinar qué reglas se ven alcanzadas por el evento de actualización actualmente procesado. Para ello, al momento de definir una regla el usuario no sólo deberá especificar la lógica que comprenderá la regla, sino también a la actualización de qué entidades deberá ésta asociarse. Esto permitirá que una Entidad pueda asociarse a múltiples reglas (para cuando se analizan distintos aspectos de la Entidad), como también una Regla puede asociarse a múltiples entidades (para definir una única regla que procese el estado de entidades de la misma naturaleza y estructura de datos). Al momento de activarse una regla ésta deberá ejecutar su lógica de procesamiento, la cual podrá obtener los estados de otras entidades disponibles en el sistema. Al permitirle al usuario definir la lógica de ejecución de una regla se logra obtener un alto grado de flexibilidad, logrando un alto grado de reusabilidad de los elementos disponibles. A su vez, en casos en donde existan entidades que cumplan características similares, permite condensar en una única regla distintos resultados. Durante la ejecución de la lógica de una regla, ésta puede requerir acceso al estado de otras entidades del sistema. Para asegurar que una regla se ejecutará en la temporalidad en la que se generó el evento de actualización, todo el acceso al estado de otras entidades deberá limitar la información obtenida a los estados previos al momento de generación del evento. Toda la información obtenida no podrá ser alterada de forma alguna, ya que no comprende parte de los objetivos de esta etapa el modificar el estado de las entidades. Más aún, las reglas deberán poseer la capacidad de generar información, almacenarla, utilizar dicha información en el futuro y compartirla con otras reglas. Esto es necesario ya que muchas operaciones pueden requerir mantener información de cálculo intermedia, a la cual se le deberá realizar un seguimiento. Si dicha posibilidad de mantener información no existiese, cada regla debería recalcular esos datos para cada estado, cada vez que se realiza una actualización. 31 de 105

33 5.4.5 Etapa Final: Salidas del Sistema La etapa de salidas del sistema ofrece un medio por el cual una regla, luego de su ejecución, puede emitir algún tipo de notificación que permita informar a un usuario o sistema externo de una situación particular. Para simplificar la integración de nuevos métodos de notificación al sistema, la implementación de esta etapa deberá definir una arquitectura tal que brinde la flexibilidad y expansibilidad necesaria para extender el sistema conforme surjan nuevas necesidades de comunicación. Se define como Salida a un componente del sistema que permite emitir una notificación a un componente externo, ya sea un sistema o un elemento de hardware, utilizando el protocolo adecuado para transmitir la información necesaria. Distintas salidas representarán a distintos componentes externos a los cuales se podrá solicitar que comuniquen la información transmitida. Debido a la innovación tecnológica que presenta el rubro de tecnología informática, las capacidades de comunicación disponibles para cualquier dispositivo o aplicación se encuentran en constante crecimiento. Dichas innovaciones pueden abarcar desde simples mejoras a medios existentes hasta el desarrollo de plataformas y estándares completamente nuevos. Por este motivo, la implementación de esta etapa debe presentar una flexibilidad tal que permita incluir tanto nuevas tecnologías, como así también aquellas que no se consideraron previamente. Dado que una regla debe tener la capacidad de solicitar la emisión de una notificación a una Salida en particular, será necesario definir algún medio de identificación para cada una de éstas. A su vez se deberá definir la forma de comunicación que tendrá cada salida, y generalizarse para facilitar la integración con todas las reglas disponibles en el sistema Etapa Final: Interfaces de Visualización Las interfaces de visualización o Vistas son medios gráficos de representación del estado de las entidades del sistema de forma sintética. Estas Vistas complementan a las Salidas, 32 de 105

34 ofreciendo un medio de comunicar información a los usuarios, pero carecen de la funcionalidad de emitir cualquier tipo de notificación. Como generalmente un CPD comprende centenas de agentes monitoreados, el volumen de información generado resulta imposible de analizar y comprender de manera rápida por un humano. Utilizando el poder de procesamiento disponible al sistema, las Vistas deberán resolver los principales problemas con los que se encuentra una persona al momento de analizar toda la información disponible: Volumen de datos históricos: refiere a la necesidad de analizar los estados anteriores de una lectura de un componente, los cuales pueden requerir distintas interpretaciones según la naturaleza de los datos (puede ser un simple valor promedio hasta un análisis de tendencias para pronósticos). Además, dependiendo de cómo se configure el sistema, el volumen de datos históricos puede crecer más o menos rápidamente según la frecuencia con la que se soliciten datos actualizados a los agentes. Agrupación de datos por relevancia: refiere a la necesidad de filtrar datos de agentes que no intervienen en el objetivo de un análisis, ya que por ejemplo, puede no existir conexión entre un sensor de temperatura y el registro de errores de una base de datos. Interpretación de datos: para realizar un análisis de los datos ofrecidos por el sistema es necesario poder entender qué es lo que dichos datos expresan. La estructura de datos expuesta no necesariamente tiene que estar expresada para facilitar su legibilidad, ya que es común que cuanto más legible para un humano es la información, menos eficiente es su procesamiento. 33 de 105

35 6 Diseño del Sistema propuesto 6.1 Plataforma de ejecución seleccionada Descripción de la plataforma Debido a la variedad de tecnologías y plataformas disponibles se estableció que el lenguaje a utilizar deberá poseer la capacidad de permitir la ejecución del sistema sobre cualquier plataforma y/o tecnología con la menor configuración o adaptación posible. Tomando esta característica se optó por el lenguaje Java, no sólo por ser multiplataforma (sin la necesidad de tener distintas compilaciones para cada plataforma), sino que además presenta una distribución particular que se encuentra orientada al desarrollo de aplicaciones empresariales (Java EE - aplicación ejecutándose sobre JBoss) Motivos de selección Java EE presenta un framework base de trabajo que simplifica considerablemente ciertos aspectos de diseño que en otros lenguajes deberían diseñarse o integrarse con múltiples frameworks, pudiendo introducir inestabilidades o incongruencias de diseño al sistema. Más aún, dentro de Java EE existen una serie de entornos de ejecución que le dan soporte a este tipo de aplicaciones, denominados Application Servers (AS). De todos los AS disponibles en el lenguaje se seleccionó particularmente al servidor JBoss, principalmente por las características de escalabilidad, disponibilidad y ejecución distribuida simplificada que ofrece a las aplicaciones Propiedades de Misión Crítica de la plataforma Es necesario establecer una plataforma que provea un contexto de ejecución resiliente a fallas y de alta disponibilidad. Esto permitirá simplificar el diseño del sistema para enfocarlo exclusivamente sobre la tolerancia a fallas en componentes internos al mismo. El enfoque en este tipo de soluciones se debe a que la integración de estas características al sistema no aporta valor, existiendo tantas otras implementaciones que permiten cumplir con las mismas propiedades. Dentro del campo de arquitecturas de ejecución distribuida se pueden diferenciar 3 soluciones particulares para las necesidades del sistema propuesto: Clustered JBoss: Se encuentra orientado a la redundancia a nivel de contexto de ejecución de la aplicación, pudiendo existir ésta en un espacio que se encuentra sustentado por múltiples instancias del Application Server. Esta primera alternativa requiere el uso de múltiples equipos sobre los cuales se ejecutará cada instancia del JBoss, cada uno con un entorno de ejecución propio, sincronizado con las otras instancias para asegurar la 34 de 105

36 consistencia de datos. Este esquema tiene como ventajas una fuerte resiliencia a fallos tanto de Hardware como de Software en un equipo en particular, ya que se encuentran los otros nodos disponibles, como así también fallos en los dispositivos de conectividad, con la posibilidad de incluso mantener el nodo afectado en funcionamiento si se dispone de múltiples rutas de conexión entre sí. Por otra parte tiene como desventaja el hecho de que al ser múltiples instancias del Application Server se multiplica su esfuerzo de mantenimiento, y en caso de que los equipos se encuentren conectados por una red de uso común a otros equipos, ésta puede verse saturada por el volumen de datos transmitido entre los nodos. Clustered OS: A diferencia del caso anterior, esta solución se enfoca en delegar al sistema operativo el manejo de las operaciones distribuidas sobre múltiples nodos, presentándose frente a las aplicaciones que alberga como un entorno de ejecución único (En la familia de sistemas operativos UNIX existen multiplicidad de proyectos y distribuciones orientadas a clusters, mientras que para la familia de sistemas operativos basados en Windows existen las versiones HPC o de High Performance Computing). Si bien la multiplicidad de equipos que componen el cluster requiere también un mayor esfuerzo de mantenimiento, es más probable que este tipo de configuraciones ya existan en un CPD aplicadas a otras soluciones. Esta solución cuenta con la ventaja de poder prescindir, en primera instancia, de la configuración de un cluster de instancias de JBoss. Sin embargo esto a su vez es una desventaja en sí misma, ya que tanto el JBoss como el sistema operativo presentan puntos únicos de operación, sobre los cuales una falla dejaría fuera de línea al sistema (a nivel de sistema operativo refiere a una falla que afecte al mismo, y no una falla en un equipo en particular). Si el nivel de confiabilidad brindados por estos sistemas no es suficiente, o por política operativa no se permiten este tipos de configuraciones, será necesario establecer múltiples instancias del OS y/o del JBoss. Clustered Virtual Machines: Hoy en día los entornos virtualizados permiten a los CPDs maximizar la utilización de sus recursos, manteniendo entornos discretos para cada aplicación o cliente. Este esquema se basa en el uso de Máquinas Virtuales sobre OS distribuidos, con la posibilidad de migración entre distintas instancias de OS. La máquina virtual contiene internamente una instancia de un sistema operativo con la ejecución del JBoss, por lo que al encontrarse expuesta exclusivamente al servicio que alberga se minimizan los factores de inestabilidad en el sistema. Al estar basado en la misma solución que el punto anterior presenta sus mismas desventajas, cualquier error que afecte al sistema operativo host que no permita la migración de la máquina virtual a otra instancia del OS, como así también un error en el sistema operativo de la máquina virtual, pueden dejar fuera de línea al sistema, por lo que se deberá implementar un cluster de instancias de 35 de 105

37 JBoss para asegurar su continuidad. Sin embargo, las máquinas virtuales poseen una característica única que representa su mayor ventaja, la posibilidad de replicar por medio de imágenes. Esto implica que una misma máquina virtual puede ejecutarse en N instancias distintas, configurando tanto al OS como al JBoss para que se configuren dinámicamente según la existencia de otras máquinas ya en ejecución, eliminando la necesidad de mantener múltiples instancias de JBoss por separado. Sin embargo presenta la desventaja de que este tipo de esquemas es práctico únicamente si ya se hace uso de arquitecturas basadas en sistemas operativos y máquinas virtuales distribuidas. Basado en las características de cada esquema de configuración, se toma la configuración de Clustered JBoss para el diseño del sistema, ya que representa el caso base para todos los otros casos expuestos, los cuales pueden ser implementados por el administrador del CPD sin necesidad de alterar el sistema ni ninguno de sus componentes. 6.2 Frameworks y componentes Rhino Rhino es una implementación de un intérprete de Javascript para Java que provee capacidades de scripting a las aplicaciones en dicha tecnología. Es un proyecto de código abierto de la fundación Mozilla liberado bajo licencia GNU/GPL. Con el uso de este motor el sistema le permitirá al usuario implementar la lógica de sus reglas más complejas, sin restricciones en cuanto a los componentes básicos de procesamiento que el sistema ofrece para el resto de las reglas, que serán ejecutadas cada vez que haya que procesar un evento. El cuerpo principal de la regla será el script generado por el usuario, y se persistirá al igual que otras reglas que utilicen sólo operaciones básicas del sistema. Estas reglas serán cargadas en tiempo de ejecución y serán interpretadas y ejecutadas por el motor Rhino. Al momento de ejecución de la reglas, el sistema proveerá un contexto de ejecución el cual contendrá los puntos de acceso a los distintos recursos de entrada y salida manejados por el sistema, como así también a manejadores particulares del sistema en lo referente a historial de eventos, datos de configuración de entidades y espacio para el almacenamiento de datos generados por el mismo script de manera disponible a través de distintas ejecuciones de la misma regla. Todos los elementos previamente mencionados se harán disponibles al script por medio de definiciones de contexto de ejecución. El contexto de ejecución de un script puede ser manipulado previo a su ejecución, permitiendo inyectar referencias a objetos basados en 36 de 105

38 Java para su uso desde dentro del script. Para cada elemento de contexto definido será necesario establecer que interfaz deberá éste respetar para su uso, para ofrecer una forma única de acceso común a todas las reglas. Dado que Javascript es un lenguaje inherentemente interpretado, éste sufre del mismo problema que tienen todos los lenguajes interpretados, el bajo rendimiento. Debido a que todas las instrucciones no solo poseen un requerimiento de procesamiento propio de la operación a ejecutar, sino también el requerimiento de procesamiento de su interpretación, éstas suelen tener un rendimiento neto mucho menor que su equivalente ejecución nativa bajo un lenguaje compilado. Para afrontar este problema Rhino permite la posibilidad de precompilar en tiempo de ejecución los scripts a utilizar, realizando una traducción de Javascript al lenguaje base Java. Si bien el rendimiento no se compara directamente con su equivalente compilado, la ejecución de código precompilado demostró uno o dos órdenes de magnitud de mejora en los tiempos de procesamiento. Es por ello que todos los módulos que utilicen este motor de Javascript deberán, en la medida de lo posible, precompilar sus scripts para maximizar su rendimiento. Desde el punto de vista de seguridad, Rhino presenta una característica que debe ser considerada. Para facilitar su integración con el entorno Java en el que se ejecuta, el contexto de ejecución del script ofrece facilidades de acceso a todos los ClassPaths por defecto. Esto implica que un script puede importar y utilizar, por ejemplo, la clase java.io.file y por medio de ésta obtener acceso al sistema de archivos del equipo en que se ejecuta. Para evitar la implementación de algoritmos que puedan representar una amenaza para la integridad del sistema, utilizando el framework de seguridad de Rhino se restringirá el acceso a todos los ClassPaths de Java. Esto limitará al script a utilizar los objetos expuestos por el contexto para interactuar con otros módulos del sistema Google Web Toolkit (GWT) GWT comprende un framework orientado a la generación y manipulación programática de páginas Web. A diferencia de otros frameworks, GWT es prácticamente 100% orientado a objetos, en el sentido en que uno puede componer y actualizar una página enteramente desde Java, sin la necesidad de generar HTML para estructurar la página (excepto por el marco base que puede ser generado de forma sencilla por una herramienta de composición de páginas web). Más aún, GWT permite abstraerse de otras tecnologías web que se aplican generalmente para aumentar la interactividad de la página, como es el manejo de eventos por Javascript o el uso de AJAX (Asynchronous Javascript And Xml) para comunicación asincrónica, requiriendo únicamente conocer por medio de qué elementos 37 de 105

39 Java se puede generar funcionalidad equivalente (internamente GWT hace uso de dichas tecnologías). Por otra parte, además de la abstracción de tecnologías Web, GWT presenta la ventaja de estar en constante crecimiento. Esto implica que ante la aparición de nuevas tecnologías, como la emisión del borrador de la especificación de HTML 5 en estos últimos años, ciertos componentes pueden actualizarse para hacer uso de esta nueva tecnología, mejorando la calidad de presentación sin la necesidad de conocer estrictamente como funciona dicha tecnología. La incorporación de nuevas tecnologías conlleva además un problema adicional que GWT resuelve de forma automática, que es la compatibilidad del cliente utilizado para ver la página con dichas tecnologías. Muchos componentes de GWT tienen la capacidad de hacer un fallback a tecnologías anteriores en caso de que cierta tecnología no sea soportada por el cliente utilizado, resolviendo problemas de compatibilidad con todos los clientes presentes en el mercado. Estas características que ofrece GWT permiten eliminar la necesidad de mantener elementos del sistema basados en tecnologías web tales como HTML y Javascript para web. Internamente GWT funciona como un conversor de Java bytecode a estructuras de Javascript optimizadas para la manipulación de páginas, por lo que no se requieren componentes especiales en los clientes para poder visualizar páginas generadas con esta tecnología. La conversión a Javascript, al no realizarse por medio de un intérprete sino al momento de compilar el proyecto, reduce el overhead de ejecución de las páginas a sólo el procesamiento necesario para vincular elementos del servidor con llamadas desde la página misma. Cabe destacar que GWT posee una serie desventajas frente a tecnologías clásicas de confección de páginas web. La desventaja principal es la estructura HTML generada, ya que todos los elementos de la página se generan en tiempo de ejecución. Al no poseer control directo sobre el código generado, se dificulta la posibilidad de estilizar y estructurar la página a gusto. Si bien existen métodos para estructurar la página de forma sencilla, éstos ya involucran manipulación del HTML base utilizado por cada página. Por otra parte, al realizar un mapeo entre elementos del lado del servidor y del cliente, siempre existirá un overhead de procesamiento incluso en las operaciones más sencillas, afectando la escalabilidad del sitio. Sin embargo, no se consideran como críticas a ninguna de ambas desventajas. Los beneficios de la abstracción de HTML superan ampliamente las dificultades para estilizar y estructurar la página, principalmente porque la estética de la página no es tan importante como en un sitio orientado al acceso público por internet. Por último, el sitio web en sí no 38 de 105

40 tiene los mismos requerimientos de escalabilidad que los módulos de procesamiento del servidor, ya que no tendrá el nivel de carga que tienen los módulos principales del sistema Infinispan MapReduce Model MapReduce es una metodología de procesamiento de datos orientado a operaciones distribuidas sobre clusters. Tiene por objetivo simplificar la estructuración de una operación sobre un conjunto de datos, proveyendo un método para separar dichos datos en grupos destinados a distintos nodos para su procesamiento parcial. En la medida en que cada nodo finaliza su operación, de ser necesario se realiza un post-procesado de los resultados obtenidos por cada nodo para generar el resultado final de la operación. De esta manera se puede paralelizar el procesamiento de datos, minimizando los tiempos de ejecución y maximizando la utilización de los recursos disponibles. La inclusión de este framework tiene por objetivo brindar capacidad de procesamiento de alto rendimiento al sistema en caso de que se posean grandes conjuntos de datos para generar un reporte o un gráfico a visualizar en una vista. Utilizando esta metodología de procesamiento se pueden minimizar los tiempos de procesamiento necesarios para generar la información necesaria para la vista o reporte solicitado. Al momento de estructurar el procesamiento de una regla se puede analizar la necesidad de utilizar procesamiento distribuido, dependiendo de la necesidad de velocidad y poder de procesamiento necesario para realizar las operaciones estipuladas. A diferencia de un método de procesamiento lineal, como los que se pueden implementar utilizando el motor de Javascript, estos métodos de procesamiento requieren cumplir con una estructura particular. Es debido a esto que su inclusión en el sistema no es trivial como el caso de algoritmos que se ejecutan sobre el motor de Javascript, sino que requiere la definición de varios módulos, su desarrollo realizado en Java y su instalación en el servidor como una librería para su uso nativo desde los módulos del sistema. Es por ello que este método se recomienda exclusivamente para operaciones con grandes requerimientos de poder de procesamiento. Para su uso dentro del sistema, éste proveerá al contexto de ejecución del algoritmo con puntos de acceso a los distintos módulos. A través de estos puntos de acceso se podrán recuperar datos de los historiales de las entidades para realizar los cálculos necesarios, o incluso hacer uso de Componentes de Extensión Funcional. Si bien no impone una limitación en el desarrollo del algoritmo, es aconsejable realizar todo el acceso a datos previo a la distribución de ejecución, para evitar inconsistencias en el procesamiento frente a 39 de 105

41 cambios en el ambiente que puedan afectar a los cálculos realizados en tiempos diferentes. Estos algoritmos tienen acceso completo al historial de todas las entidades del sistema, por lo que un algoritmo no necesariamente se debe limitar al procesamiento de un único sensor. Por último, para maximizar la reutilización de estos algoritmos, éstos podrán ser ejecutados desde una regla que se encuentre ejecutándose en el motor de Javascript, por lo que éste puede ser parametrizado al momento de su invocación, y sus resultados pueden ser utilizados para realizar cálculos adicionales. La gran ventaja de este método es que, frente a volúmenes crecientes de datos, si el proceso particiona de manera eficiente el conjunto de datos a procesar, se puede incrementar el rendimiento del proceso simplemente agregando nuevos nodos al cluster. Para ello se debe diseñar cuidadosamente la estructura del algoritmo, permitiendo maximizar su eficiencia y escalabilidad. Debido a que este tipo de algoritmos no se enfoca para el uso general sino para situaciones con requerimientos particulares de procesamiento, junto con la imposibilidad de determinar a priori el tipo de algoritmo implementado, el sistema no proveerá herramientas avanzadas para el mantenimiento de éstos Hibernate Para abstraer la implementación del esquema de datos utilizado por el sistema se hará uso del framework de persistencia Hibernate, el cual permite realizar la persistencia y lectura de objetos en Java sin necesidad de interactuar directamente con la base de datos. El uso de este framework al abstraer la implementación del esquema de datos permite que dicho esquema de datos pueda sufrir modificaciones, necesitando luego simplemente modificar las propiedades de mapeo de Hibernate, sin la necesidad de modificar la lógica de negocio. 6.3 Selección del Motor de Base de Datos La elección de Hibernate como framework de persistencia nos permite flexibilizar la elección del motor de base de datos. Así como el lenguaje Java permite ejecutar el sistema en múltiples plataformas sin la necesidad de realizar grandes adaptaciones, Hibernate permite abstraerse del motor de base de datos. Gracias a esto es posible utilizar distintos motores de bases de datos simplemente modificando la configuración del framework de persistencia. 6.4 Criterios de Definición de los Módulos del sistema Partiendo de las premisas de diseño detalladas anteriormente, es necesario confeccionar un diseño de sistema que las respete, manteniendo una agrupación funcional coherente que 40 de 105

42 facilite el desarrollo, mantenimiento y comprensión del sistema. Es por ello que se decidió segmentar el sistema en módulos funcionales que deberán tener leves dependencias funcionales, tratando en lo posible de evitar cualquier referencia directa entre sí por medio del uso de Contratos Funcionales para predefinir cómo deberán comunicarse. Este esquema se aplicará particularmente sobre el segmento de funcionalidad principal del sistema, el cual define la forma de funcionamiento del mismo. Cada Contrato Funcional deberá encontrarse debidamente documentado para ofrecer completo conocimiento a terceros de cómo puede hacerse uso de los módulos que lo implementan. Enfocando el diseño no desde la funcionalidad de negocio, sino desde la funcionalidad en cuanto a los elementos que manipula en el sistema, será necesario definir una serie de capas de abstracción que independicen la lógica puramente de negocio de la lógica de mantenimiento, configuración e interacción con el usuario. Es por ello que se implementará el patrón Mode View Presenter (MVP) para separar la lógica de negocio en lo que conformaría la capa de Model (que a su vez se subdivide en los módulos mencionados anteriormente), encapsulando la lógica de control y mantenimiento del sistema e interacción en la capa de Presenter, y finalmente la lógica de visualización en la capa de View. Por último, es necesario establecer cómo se extenderá la funcionalidad del sistema para incorporar nuevos componentes o tecnologías. Para ello se utilizará el patrón Plugin, con la excepción de que no sólo se podrá diferenciar según el runtime y plataforma de ejecución (distintos sistemas operativos pueden requerir distintos métodos de comunicación con las capas más bajas), sino también según los agentes que se desea integrar al sistema (tipos de sensores o fuentes de datos de la cual tomar las lecturas). Compartimentando la lógica de interacción con el contexto en distintos plugins, éstos deberán presentarse frente al sistema por medio de un Contrato Funcional común a todos los componentes del mismo tipo. Teniendo esta segmentación flexible de funcionalidad, aquellos módulos que la implementen deberán manejar la configuración utilizada por cada plugin, y deberán mantener la información necesaria para determinar qué componente es el indicado para cada operación. 6.5 Módulos Principales del Sistema Plugins de Entrada Propiedades Generales Al existir una gran variedad de elementos que se pueden monitorear en un CPD, existe la necesidad de establecer un método flexible de adquisición de datos, que posibilite extender en el futuro los tipos de agentes que pueden integrarse en el sistema. Para ello se define el 41 de 105

43 esquema de Plugins de Entrada, que permite modularizar los métodos de obtención de datos de las variables a medir. Un plugin representa un módulo que satisface cierto comportamiento que le permite integrarse al sistema, mientras que al mismo tiempo se encuentra definido de forma suficientemente abstracta como para poder incluir funcionalidad para la conexión con el elemento remoto que posee la información que se desea obtener. Para poder lograr esto se define una interfaz y requerimientos de implementación que se deben satisfacer al momento de desarrollar el plugin. Dicha interfaz expone el comportamiento necesario para realizar una petición de actualización a un agente dado, y para solicitar información relativa al tipo de configuración que requiere el plugin para conectarse (parámetros de configuración). Para ejecutar una solicitud de datos para un agente, dicho agente es descripto por medio de los parámetros de configuración que son requeridos para conectarse lógicamente a este. Es por medio de esta parametrización que el plugin puede ser reutilizado para distintos agentes sin la necesidad de modificarlo y publicarlo como un plugin distinto. Siguiendo este esquema, frente a la aparición de nuevos elementos que posean un método de comunicación no utilizado previamente en conjunto con el sistema, basta con desarrollar e integrar un plugin de entrada para extender la capacidad de integración del sistema. Si bien esto implica la necesidad de realizar un desarrollo a un nivel de abstracción parcialmente igual que el del sistema, estos desarrollos no deberían ser frecuentes, y deben tener por objetivo la creación de un módulo lo suficientemente flexible para que pueda ser reutilizado con otros elementos que presenten características de comunicación similares Alcance funcional En los requerimientos impuestos por el sistema, un plugin simplemente debe cumplir con la necesidad de informar qué parámetros son requeridos para definir una conexión con un agente particular, y ofrecer la capacidad de solicitar en cualquier momento una actualización de los datos de actualización del agente en un formato predeterminado. Teniendo estas limitaciones (junto con unas restricciones menores de implementación definidas en el detalle de implementación del sistema), el plugin no debe necesariamente establecer una conexión con el elemento que se desea medir. Esto implica que un plugin tiene la posibilidad de conectarse a un elemento intermedio, el cual provee extractos de la información original, la cual contiene los elementos de importancia a ser utilizados por el sistema. De esta manera se pueden integrar otros sistemas de información al sistema de monitoreo. 42 de 105

44 Por otra parte esto también resuelve las limitaciones o elevados niveles de complejidad que puede presentar Java para la obtención de datos de bajo nivel. Ya que se pueden tomar datos de otros programas, existe la posibilidad de desarrollar una aplicación en un lenguaje distinto, que realice todas las interacciones con los componentes de bajo nivel, convierta los datos a un formato estándar, y los exponga para su acceso por un medio común de comunicación, compatible con el plugin. De esta manera, siempre que se utilicen métodos de comunicación estándar, se podrán incorporar otras tecnologías a la aplicación de manera sencilla Métodos Activo y Pasivo de adquisición de datos Método Activo: en el método activo de adquisición de datos, el plugin generalmente estará escuchando (queda a la espera de que un agente inicie una conexión) y el agente será quien esté programado para informar de manera autónoma ante la ocurrencia de un evento. Por ejemplo, este será el caso cuando tengamos un sensor de puerta abierta monitoreado por un agente activo, en donde el agente se encargará de monitorear periódicamente el estado del sensor. En caso de detectar un cambio, el agente le comunicará el cambio al plugin y entonces la información del evento llegará al sistema. Denominamos a este método como Activo ya que será el conjunto Agente-Plugin el que de manera autónoma y sin recibir instrucciones del sistema indicarán una lectura. Método Pasivo: este método será utilizado para categorizar a aquellas actualizaciones que se realizan mediante una consulta periódica al plugin. El sistema contará con un temporizador con el que le indicará al plugin que deberá obtener una lectura del sensor e informarla. Se lo denomina como pasivo ya que el conjunto Agente-Plugin estará a la espera de que el sistema inicie una consulta para entonces responder con la lectura Agentes e Instancias de Plugins Todos los agentes del sistema se definen por una asociación con una Instancia de Plugin. Será a través de la Instancia de Plugin que el sistema obtendrá los estados actualizados del agente, ya que la misma contiene la configuración necesaria para conectarse a éste y obtener la información necesaria. Esta definición se realiza principalmente por el hecho de que el Agente propiamente dicho es un elemento que interactúa con múltiples módulos dentro del sistema, mientras que la Instancia de Plugin se utiliza exclusivamente en este módulo. Por otra parte permite reducir la cantidad de propiedades duplicadas que se definen para un agente, ya que el plugin puede requerir hacer uso de una propiedad del agente que a su vez se utiliza en otro módulo. 43 de 105

45 Elementos que intervienen Ciclo de vida en el sistema Los plugins por sí solos no son elementos activos del sistema, sino que su ejecución depende de la invocación por parte de otro módulo, la de Lecture Mapping. Dicho módulo realizará la invocación al plugin en cuanto necesite obtener el estado actualizado de un agente que requiera dicho plugin. El funcionamiento interno del plugin no se encuentra estandarizado, por lo que depende de cómo se realice la implementación. Sin embargo, todos los plugins deberán comportarse en forma general de manera sincrónica, implicando que el proceso sobre el cual se realiza la llamada al agente deberá bloquearse hasta obtener el nuevo estado del mismo. Para simplificar el modo de funcionamiento, tanto los plugins activos como pasivos reportan las actualizaciones de estado de los agentes por medio de un capturador de eventos intermedio, el cual redirige el evento de actualización al módulo o complemento que corresponda. La diferencia de funcionamiento entre los agentes pasivos y activos en este nivel, es que los pasivos fueron previamente activados para solicitar la actualización, por lo que el evento de actualización capturado se puede manejar de forma distinta a los de los agentes activos Contratos funcionales que implementa Obtención de estados: Dependiendo de si se trata de un plugin para agentes pasivos u activos la implementación varía. Sin embargo es común para los dos que, al momento de iniciarse (activos) o al momento de realizar una petición de actualización (pasivos) es necesario que el plugin acepte un objeto intermediario que hará de capturador de eventos, a través del cual se le comunicará al sistema sobre la actualización del estado de un agente dado. Publicación de parámetros de configuración: A través de este comportamiento el sistema puede conocer qué parámetros son los que se utilizan para parametrizar el plugin. Haciendo 44 de 105

46 uso de esta información se solicitará al usuario que especifique los parámetros de una instancia en particular, para asociarla lógicamente con el agente correspondiente. El detalle de los parámetros puede contener información adicional, como una descripción del mismo, su formato o lista de posibles valores para simplificar su configuración Características de Misión Crítica Debido a que los plugins pueden ser desarrollos realizados por terceros, se especificaron de manera tal que se minimicen los requerimientos de implementación de los mismos. Es por ello que en relación a las características de Misión Critica sólo se puede mencionar que el concepto de plugin fue ideado con la intención de trasladar dichas características al módulo que los administra. Cabe destacar que los requerimientos impuestos a los plugins son necesarios para que el módulo que los administra pueda satisfacer sus objetivos funcionales. Se puede decir, además, que el esquema de plugins permite indirectamente satisfacer los requerimientos de Tiempo Real, ya que frente a la necesidad existe la posibilidad de minimizar los tiempos de reacción del sistema haciendo uso de plugins para agentes activos. Por otra parte, la modularidad de los plugins permite minimizar la propagación de un error crítico en uno de ellos, afectando únicamente al plugin en el que se originó. Este tipo de aislamiento permite ofrecer un mayor nivel de disponibilidad del sistema, minimizando las causas de cese de funcionamiento Emisión de registros de sistema Errores de comunicación: Cada instancia tiene la posibilidad de comunicar todos los errores que surgen en la comunicación con el agente asociado. Dicho error puede ser utilizado internamente en el sistema como datos para el resto del sistema, permitiendo establecer reglas que informen de inmediato a un administrador o al personal responsable en caso de que no se pueda establecer comunicación con algún componente crítico. Para poder lograr este cometido es necesario que cada error registrado pueda ser asociado directamente a un agente, permitiendo distinguirlos fácilmente al momento de establecer la lógica en las etapas posteriores. 45 de 105

47 6.5.2 Módulo de Lecture Mapping Propiedades Generales Este módulo representa el punto de conexión entre el sistema y los agentes externos. A través de este módulo se realiza toda la obtención de información actualizada de cada agente registrado en el sistema, utilizando los métodos de conexión requeridos según el tipo de agente y sus parámetros de configuración. Debido a la diversidad de elementos que se pueden monitorear, pudiendo cada uno implementar una tecnología o metodología de comunicación distinta, es necesario establecer un modo flexible de conexión a éstos. Para ello se utilizan los Plugins de Entrada definidos previamente. Debido al gran volumen de elementos a monitorear en un CPD, resulta impracticable definir un plugin específico para cada uno de éstos, por lo que cada plugin define una serie de elementos parametrizables que le permiten al sistema reutilizar el mismo para distintos agentes que presenten características de comunicación similares. Dicha parametrización deberá ser definida por el usuario, para cada agente en particular, ya que el sistema no tiene la capacidad de reconocer automáticamente dichas propiedades. Para estandarizar la metodología de parametrización de cada plugin, todos serán configurados por medio de estructuras de datos en formato XML, cuya estructura si podrá ser definida arbitrariamente por el plugin. Esto permite por un lado unificar la forma de representación de la configuración de los plugins, manteniendo un amplio grado de libertad respecto a los elementos de configuración que el plugin puede requerir. Teniendo las instancias de los plugins ya configuradas para conectarse con los agentes remotos, es necesario establecer, en caso de ser agentes pasivos, ciclos de actualización para mantener actualizado el estado de los agentes reflejado en el sistema. Este ciclo debe ser prefijado teniendo en cuenta los requerimientos de actualidad de la variable medida, la carga de procesamiento que significa tanto en el equipo remoto como en el local la obtención de dicha información, la criticidad de actuar un ciclo más tarde del momento en que se generó el evento medido y la velocidad con que la variable medida se actualiza Dependencia de estados entre agentes Un punto que se debe considerar en este módulo es la dependencia de datos requerida por las reglas del sistema frente a un evento en un agente determinado. Esto se desprende de cómo se encuentran implementadas las reglas del sistema, requiriendo que varios agentes cuenten con información actualizada para su correcto análisis. Esto genera la necesidad de sincronizar en cierto modo la actualización de los estados de varios agentes para asegurar 46 de 105

48 la correcta ejecución de las reglas implementadas. Para ello el sistema ofrece la capacidad de configurar Update Jobs, que forman unidades de ejecución que realizan la actualización simultánea de múltiples elementos. Un Update Job puede servir de reemplazo al ciclo común de actualización, teniendo varios agentes que dependen de su ejecución para actualizar su estado. Por otro lado existen agentes que no sólo se actualizan por medio del ciclo de actualización estándar, sino también se encuentran asociados a múltiples Update Jobs. Esto puede deberse principalmente a que el estado de un agente es dependencia de múltiples elementos que pertenecen a distintos grupos de operación. Dado que un agente puede ser actualizado tanto por medio de un ciclo común de actualización, así como también por medio de múltiples Update Jobs, estos últimos tendrán la posibilidad de indicar qué agentes generan evento de actualización. Esto permite minimizar la cantidad de eventos que deberán ser luego procesados por el motor de reglas, pudiendo reducir los eventos de estos agentes a exclusivamente los generados por su ciclo común de actualización. Por otra parte, para minimizar la cantidad de información que fluye en general al sistema, se debe analizar la posibilidad de unificar Update Jobs, eliminando múltiples actualizaciones de un mismo agente en un período muy corto de tiempo. Sin embargo, se debe contemplar la posibilidad de que un agente tenga un retraso considerable en su respuesta. Esto puede resultar contraproducente para el funcionamiento normal del sistema, y es motivo suficiente para descartar la posibilidad de unificar Update Jobs a costa de un mayor poder de procesamiento demandado. Para lidiar con el problema de tiempos de respuesta excesivamente largos de algunos agentes, producto de un problema de comunicación o desperfectos técnicos varios, el Update Job permite también la asignación de dos límites de tiempo de espera, junto con una propiedad adicional para todos los agentes asociados. La propiedad adicional de los agentes asociados indica si la actualización del agente es crítica, siendo ésta una de las razones principales por las cuales el Update Job fue creado. Por otra parte se encuentra el primer límite de tiempo de espera, que define el tiempo máximo a esperar, tras el cual, de haberse actualizado todos los agentes críticos, el Update Job se persiste y genera todos los eventos de actualización pertinentes. Esto permite al sistema evitar que el proceso quede en espera de forma indefinida hasta que se actualice un agente, el cual frente a un problema de comunicación se puede presuponer que mantuvo su estado desde el ciclo de actualización anterior. Por último se encuentra el segundo límite de tiempo de espera, tras el cual el Update Job se descarta debido a no haber recibido a tiempo los datos necesarios de los agentes críticos del mismo. 47 de 105

49 En caso de que un Update Job sea finalizado o cancelado antes de que un agente responda a la petición de actualización, el sistema, al recibir su respuesta, actualizará su estado y generará el evento correspondiente sólo en caso de que el agente hubiese sido marcado como no crítico y con generación de evento en el Update Job terminado prematuramente. Esta limitación se introduce para evitar la generación de eventos de agentes con estados inconsistentes (sería el mismo caso de que no existiesen Update Jobs) o de los eventos que originalmente no se deseaban generar. Al igual que la configuración del plugin de entrada, los Update Jobs no pueden ser determinados de manera programática, por lo que deben ser definidos a mano por el administrador del sistema. Deberá ser éste quien evalúe las ventajas de tener información sincronizada contra la posibilidad de ejecutar múltiples actualizaciones de algún agente. A su vez será éste quien determine dentro de un Update Job cuáles agentes es crítico actualizar, cuáles no, y cuáles no requieren siquiera generar un evento al recibir su actualización, teniendo en cuenta qué posibilidades existen de que el Update Job se persista de forma prematura con una parte de los agentes actualizada, o que su ejecución sea descartada por completo debido a falta de datos Elementos que intervienen 48 de 105

50 Ciclo de vida en el sistema El módulo de lecture-mapping comprende uno de los elementos principales del sistema, por lo que éste se encontrará activo mientras el sistema se encuentre en línea. Siendo éste el responsable de la obtención de datos actualizados de todos los agentes registrados en el sistema, la actividad de este módulo depende directamente de cómo se haya configurado el sistema para solicitar actualizaciones. Si existen elementos que se actualicen con una frecuencia alta, el módulo presentará un nivel de actividad constante, realizando la invocación de Plugins de Entrada y administración de sus ciclos de ejecución, y programando futuras solicitudes de datos según los intervalos configurados. Dado el potencial volumen de elementos con los que debe trabajar, este módulo contará con soporte para ejecución concurrente, permitiendo aliviar cualquier problema que pueda surgir en un plugin particular. Por otra parte, si bien representa un nivel de actividad despreciable frente al nivel generado por un sistema con una amplia configuración de agentes, el módulo debe actuar frente a ciertas interacciones en el usuario, específicamente con las que tratan con la administración de agentes. Dentro de estas actividades será necesario también manejar invocaciones a plugins de entrada, pero con el propósito de solicitar la información necesaria para poder configurar una instancia de éstos. Este tipo de actividades serán comunes únicamente al momento de inicializar el sistema desplegado, o al realizar tareas de mantenimiento que requieran modificar los métodos de comunicación que tiene el sistema con los agentes registrados en éste Contratos funcionales que implementa Administración de Agentes: Así como un plugin representa un método de comunicación con un elemento externo al sistema, la instancia representa a un elemento particular, registrándose en el sistema como agente. Para establecer dichos agentes el administrador del sistema deberá realizar una inicialización del mismo, especificando qué agentes existen en el entorno, especificando también qué plugin de comunicación requiere para comunicarse, y los parámetros que dicho plugin requiere para establecer el enlace de comunicación. Administración de Update Jobs: Al igual que los Agentes, es necesario que el administrador del sistema establezca cómo se deberán solicitar las actualizaciones de los agentes. Esta interfaz se utiliza en conjunto con la interfaz gráfica del sistema para brindarle al 49 de 105

51 administrador las herramientas necesarias para configurar todos los Update Jobs necesarios según se haya planificado en la programación del despliegue del sistema. Control de Flujo de actualizaciones: Siendo este módulo el catalizador de todas las operaciones de los otros módulos que no provengan de la interacción de un usuario con el sistema, se establece esta interfaz con el propósito de controlar su funcionamiento. Es por medio de ésta que, tanto el sistema como el usuario, pueden detener o reiniciar el ciclo operativo del sistema Características de Misión Crítica Siendo el punto de partida para todas las operaciones automáticas del sistema, un error en este punto se propagaría a las etapas posteriores, pudiendo dejar el sistema completamente inoperante. Es por ello que es vital que en este módulo se realice un minucioso control de las operaciones que lleva a cabo, y que éstas se ejecuten de manera ordenada sin dar lugar a posibles conflictos. Para asegurar la ejecución de todos los Update Jobs será necesario establecer ejecuciones paralelas, permitiendo aislar el ciclo de actualización de un agente de otro. Esto implica no sólo que el módulo deberá poder iniciar ejecución paralela de distintos Update Jobs, sino que debe estar preparado para atender de manera concurrente los informes de actualizaciones obtenidas que luego serán transferidas al módulo de Agent State Manager. De esta manera no sólo se logra que los problemas de un agente en particular afecten sólo al Update Job desde el que se lo invoca, sino que también es posible mantener una ejecución concurrente permanente de todos los plugins asociados a agentes activos. Un punto a tener en cuenta respecto al contexto de ejecución del sistema es la conectividad del nodo del cluster en que se ejecuta un plugin. De ser posible, es recomendable que la mayor parte de los plugins, sino todos, puedan ejecutarse en cualquiera de los nodos. El poder ejecutarse en cualquier nodo implica que frente a un problema que afecte a un nodo en particular que imposibilite la comunicación con agentes externos, el sistema puede simplemente relocalizar todas las operaciones de dicho nodo a uno que se encuentre disponible. Esta característica, en conjunto con la descripta anteriormente, mejoran efectivamente el nivel de Disponibilidad del sistema frente a los agentes que éste maneja. Por último, como se mencionó en la definición de los Plugins de Entrada, éstos no necesariamente poseen implementaciones de recupero frente a errores, ni registros de errores que permitan a un administrador realizar un análisis de los problemas sucedidos. Es 50 de 105

52 por ello que la capa de Lecture Mapping debe complementar el funcionamiento de dichos plugins para asegurar una ejecución segura, consistente y que garantice la integridad de los datos informados. Particularmente esto se logra por medio de los Update Jobs, los cuales permiten definir qué elementos pueden o no reportar un error frente a una solicitud de actualización, y determinar si la situación que se les presenta se encuentra en un estado consistente que puede continuar ejecutándose o si debe descartar toda la información e informar el problema como un error severo. Por otra parte, es este módulo el que también se encarga de informar todos los errores, ya sean de un Update Job o de un plugin en particular, para que éstos se registren debidamente en el sistema Emisión de registros de sistema Agent Lectures: El principal registro que genera este módulo son las lecturas con el estado actualizado de los agentes registrados en el sistema. Sin embargo estos registros no son administrados por este módulo, sino que se transfieren al módulo de Agent State Manager para su persistencia y posterior solicitud y transferencia a módulos subsiguientes. Errores de plugins: Como un plugin comprende un elemento aislado del sistema, todos los errores que son comunicados por éstos deben ser administrados por este módulo para su posterior tratamiento y persistencia. Todos los errores de plugins tienen la posibilidad de ser tratados como eventos del sistema, para que éste reaccione según como haya sido parametrizado por el administrador. Errores en Update Jobs: Si bien todos los errores puntuales de comunicación de un plugin se manejan de forma independiente, puede que la actualización de un agente no se lleve a cabo por un fallo en la actualización en un componente asociado al mismo Update Job. Es por ello que los Update Jobs consisten en otra fuente posible de errores que se puede utilizar en el sistema para tomar acciones correctivas o advertir lo antes posible a un operario de la potencial situación problemática en la que se encuentra el sistema Agent State Manager Propiedades Generales El módulo de Agent State Manager es el módulo que provee al resto del sistema de información sobre el estado actual e histórico de los agentes, y ofrece al módulo de Lecture Mapping facilidades de persistencia de nuevas lecturas. Este módulo se encarga de la persistencia de las instancias de AgentState y las lecturas obtenidas del módulo de Lecture Mapping, y a su vez provee mecanismos de caché para minimizar la carga a la base de 51 de 105

53 datos para consultas de estados recientes. Junto a estos elementos, este módulo debe manejar también la temporalidad de la información de los sensores, ya que todas las lecturas obtenidas pertenecen a un punto determinado en el tiempo. Ya que este módulo administra todas las operaciones de persistencia del AgentState y los AgentLecture, no es necesario que las características de persistencia de estas entidades se expongan fuera de este módulo. Aprovechando esta característica, y para minimizar el volumen de información entre capas, se implementará el patrón Data Transfer Object (DTO) para la transferencia de datos del agente a otros módulos, eliminando cualquier overhead generado por la administración de la entidad por fuera del contexto en que fue inicializada (asociación y desasociación de entidades al contexto y serialización de información de persistencia). Dichos objetos serán los que alimentarán a todos los módulos que utilicen información de estado de Agentes, y no presentan lógica adicional excepto aquella necesaria para exponer sus propios datos Elementos que intervienen 52 de 105

54 Ciclo de vida en el sistema Este módulo forma parte del funcionamiento central del sistema, por lo que su existencia se encuentra administrada por el macro-módulo que representa a todo el sistema. Durante su período de actividad el módulo deberá atender dos tareas principales, escritura de nuevas lecturas emanadas por el módulo de Lecture Mapping, y las solicitudes de datos de los módulos del Motor de Reglas y Motor de Vistas. A su vez deberá atender tareas secundarias de programación del sistema, particularmente aquellas que se vinculan a la configuración de nuevos agentes. Dichas tareas secundarias provienen de las capas superiores de interfaz de usuario, y no de otros módulos dentro de la misma capa como son las tareas principales. La mayoría de las tareas secundarias sólo presentarán una ejecución frecuente al momento de realizar la inicialización del sistema, o cuando se realizan cambios en la infraestructura de sensores del CPD. Para mejorar el rendimiento el módulo implementa un mecanismo de caché para minimizar las lecturas hacia la base de datos. Dicho caché contendrá todas las instancias activas del ciclo, con su respectivo historial de estados, a menos que se indique lo contrario por configuración del módulo. Al momento de iniciar el ciclo de vida del módulo, el caché se inicializa vacío. En caso de que la marca LoadAllStatesOnStartup se encuentre activa, luego de inicializarse el caché se poblará con los estados de todos los agentes existentes que hayan sido persistidos en ejecuciones anteriores. Conforme avanza la ejecución del sistema, los historiales de los estados de los agentes crecen constantemente. Para evitar la sobreasignación de recursos al módulo, cada agente tiene una configuración en la cual se puede indicar el tamaño del historial que se mantiene cacheado, a partir del cual las lecturas más viejas se descartan de memoria. Por último, al finalizar el ciclo de vida del módulo, éste se encarga de descartar todos los elementos que se encontraban en el caché y finalizar su ejecución Contratos funcionales que implementa Escritura de AgentLectures: Debiendo administrar el estado de todos los agentes, es lógico establecer que este módulo sea responsable de la escritura de las nuevas lecturas obtenidas del ambiente, pero por su definición, dichas lecturas no son obtenidas por éste sino por medio del módulo de Lecture Mapping. Es por ello que este módulo deberá exponer el comportamiento necesario para poder recibir lecturas en estructuras de datos predefinidas 53 de 105

55 por el sistema, e implementar la lógica necesaria para relacionar la lectura con su correspondiente AgentState, y manejar la persistencia de ésta. Lectura de AgentStates e históricos de AgentLectures: Debiendo administrar el estado de todos los agentes, todos los otros módulos deberán recurrir a éste para solicitar el estado de un agente particular. Debido a que esta operación es vital para el funcionamiento del sistema y presenta una frecuencia de uso muy alta, internamente el módulo implementa un caché, como se mencionó anteriormente. A su vez esta interfaz debe presentar la posibilidad de recuperar estados para un cierto punto en el tiempo, y con un tamaño de historial definido por quien lo invoca. Es por ello que internamente se deberá implementar lógica que permita discernir entre que elementos se encuentran en caché y cuáles no, realizar las solicitudes pertinentes a la base de datos, y confeccionar el objeto de intercambio para enviarle el estado solicitado para el punto en el tiempo indicado. ABM de AgentStates: Para completar las cualidades administrativas del módulo, es necesario que éste permita crear y modificar AgentStates según indique el usuario. Siendo un proceso que abarca a todo el ciclo de funcionamiento principal, la creación de nuevos AgentStates provendrá de otros módulos de la misma capa, en vez de la interacción directa con el usuario. Esta funcionalidad contempla la simple generación de un nuevo AgentState sin inicializar. Una vez completado el paso anterior el usuario deberá configurar las propiedades de persistencia del AgentState y su historial, proveyendo su inicialización y preparación para entrar en funcionamiento Características de Misión Crítica Siendo este módulo directa o indirectamente la fuente de información de la mayoría de los módulos principales, es necesario que no sólo se minimicen las posibilidades de error, sino también manejar e informar de la forma más ordenada posible aquellas situaciones de error que no puedan ser evitadas o resueltas en tiempo de ejecución. Dependiendo principalmente de la conexión con la base de datos, es necesario que este módulo pueda afrontar problemas que surjan de este componente de forma que sea transparente para otros módulos, desde el punto de vista de obtención de estados. Para ello se definen estrategias alternativas tanto para la escritura como la lectura de datos. Escritura de nuevos estados: Frente a la solicitud de escritura de un nuevo estado, en caso de no estar disponible la conexión a la base de datos, el módulo puede ser configurado para que simplemente mantenga la lectura en memoria y la aliste para su persistencia al momento que se restablezca la conexión. De esta manera la información pendiente por 54 de 105

56 persistir se mantiene disponible al sistema, haciendo transparente la caída de conexión. Sin embargo, debido a la naturaleza finita de los recursos disponibles, esta situación no se puede mantener por un período indeterminado de tiempo. Por otro lado, el sistema puede configurarse para que no acepte nuevas peticiones de persistencia de estados, provocando que el sistema quede fuera de línea hasta que se resuelva el problema subyacente. Re-sincronización de estados de agentes: Partiendo de la configuración de transparencia de errores de conexión a la base de datos, se debe contemplar una nueva vulnerabilidad relacionada con la consistencia del historial de estados en caso de que el sistema se detenga por algún factor desconocido. En éste caso, al volver a su ciclo operativo, el sistema no sólo no dispondrá de los últimos estados de los agentes, sino que no será directamente detectable, iniciándose en un estado distinto al último registrado durante su último ciclo operativo. Para evitar esto, el módulo dispondrá de la posibilidad de seleccionar un método de persistencia alternativo, que pueda ser utilizado para luego restaurar el último estado del sistema en caso de que ocurra una situación similar a la planteada. Este repositorio de datos no requiere cumplir con las mismas características de rendimiento que el principal, ya que se utilizará exclusivamente como medio de recuperación, y no como complemento al principal. Lectura de estados: A diferencia de la escritura de nuevos estados, la lectura de estados ya posee un mecanismo que permite continuar la ejecución del sistema sin necesidad de disponer de una conexión activa a la Base de datos, el caché de estados históricos. Siempre y cuando no se soliciten estados anteriores al estado más viejo actualmente en caché, se puede prescindir de la disponibilidad de la base de datos (mientras que la escritura de nuevos estados funcione dentro de los límites establecidos para estas situaciones). Sin embargo, se pueden presentar dos situaciones en las cuales no se dispone de la información necesaria, y que pueden ser tratadas de forma distinta conforme a como haya configurado el módulo el usuario. En caso de solicitar el estado de los agentes para un punto en el tiempo en el cual no se disponga de información alguna en caché, no existe otra alternativa que registrar un error e informar al solicitante de la situación actual. En cambio, si se posee información parcial en caché, se puede optar por actuar de la misma manera que si no tuviese información, o trabajar con la información disponible informando al solicitante de la situación actual, el cual evaluará si la información obtenida es suficiente para proseguir con su ejecución. Desde el punto de vista de la escalabilidad, este módulo presenta el mayor nivel de criticidad. Teniendo que administrar el histórico de todos los agentes, ya de por sí el volumen de datos que maneja crece constantemente en el tiempo. Más aún, dicho volumen 55 de 105

57 será aproximadamente proporcional a la cantidad de agentes que el sistema administre. Para evitar el crecimiento descontrolado de información, el sistema cuenta con un medio de caché para limitar la cantidad de información que se mantendrá disponible en memoria para su uso por otros módulos. Esto permite disminuir la carga sobre el motor de base de datos, acción que puede significar retrasos en el ciclo de ejecución (comparado con el acceso a memoria). Sin embargo es crítico que el tamaño del caché sea correctamente configurado acorde a la demanda de datos históricos de cada agente. El volúmen de datos históricos de un agente depende tanto de la frecuencia de actualizaciones, como así también del volúmen de datos promedio obtenido en cada lectura, y la fracción relevante del histórico para las operaciones del sistema varía según la naturaleza de las lecturas, y la medida de histórico requerida (número de lecturas o tiempo de histórico). Un caché demasiado chico puede suponer un rendimiento menor a la operación sin caché, ya que no sólo realiza muchas operaciones con la base de datos, sino que también debe determinar si un estado se encuentra en caché o no. Por otra parte, un caché demasiado grande implica un uso excesivo de recursos sin ventaja perceptible. A su vez, el tamaño del caché afecta el tiempo de independencia del sistema frente a una pérdida de conexión con la base de datos, debido a lo expuesto en los puntos anteriores. Por último, debido a que se presentan multiplicidad de situaciones que pueden significar problemas de funcionamiento u oportunidades de mejora operativa, es necesario que el módulo emita alertas, errores y notificaciones que den a conocer cómo evoluciona el funcionamiento interno del módulo. Dichos mensajes serán emitidos a través del módulo de Registros de Sistema, el cual se deberá configurar acorde a lo deseado por el administrador del sistema, para que cada mensaje se emita por el medio que considere más apropiado Emisión de registros de sistema Errores y advertencias: Como se mencionó anteriormente, el sistema tiene la posibilidad de generar mensajes de error y/o advertencias acorde a determinadas situaciones que se pueden presentar en el funcionamiento de módulos. A su vez será necesario registrar cualquier error proveniente de los elementos que utilice este módulo, que no afecten de manera directa al sistema pero brinden una fuente de información crítica relativa al funcionamiento del mismo. Cada tipo de error o advertencia definida en el módulo tendrá un código de identificación único para que puedan ser debidamente tratados por el módulo de Registros del Sistema. 56 de 105

58 Notificaciones: Además de las notificaciones críticas del estado el módulo también emite notificaciones informativas que permiten detallar ciertos aspectos del funcionamiento del módulo que pueden ser registrados en distintos medios conforme con los intereses del Administrador del sistema. Dichos registros pueden variar desde notificaciones de resolución de errores hasta simples puntos de registro con datos de rendimiento o estado general del módulo. Los distintos tipos de registros informativos generados, al igual que los errores y advertencias, serán identificados con un código único para que puedan ser debidamente interpretados por el servicio de Registros del Sistema Componentes de Extensión Funcional Propiedades Generales Para simplificar el procesamiento u obtención de datos externos en el Motor de Reglas o el Motor de Vistas, se define el módulo de Componentes de Extensión Funcional. La posibilidad de incorporar módulos lógicos que contengan algoritmos de procesamiento o de conectividad embebidos, y de libre disponibilidad, permitirá simplificar sustancialmente la tarea de programación del sistema. Por medio de este módulo, otros componentes del sistema podrán solicitar servicios de procesamiento extendido, brindado por las librerías integradas a éste. Los Componentes de Extensión Funcional se componen por librerías que implementan tanto algoritmos de cálculo como comunicaciones con componentes externos al sistema. Dicha funcionalidad se encuentra encapsulada en la librería para una fácil distribución e instalación. Esta metodología de modularización permite incorporar funcionalidad preexistente de forma sencilla en el desarrollo de un sistema. Los Componentes de Extensión Funcional permiten esta misma flexibilidad, pero al nivel de aplicación, para utilizarse desde los módulos en los que el usuario tiene la posibilidad de programar el sistema. De esta manera se pueden incorporar potentes métodos de cálculo o interconexión con componentes externos que permiten maximizar la funcionalidad disponible al usuario. La definición de un componente de extensión funcional no lo limita al tipo de aplicación que este puede tener. Pueden existir componentes que se utilicen exclusivamente por reglas, como puede ser el análisis de datos para detectar desvíos respecto a ciertas referencias, así como también aquellos que se usan exclusivamente por el ViewEngine, como puede ser procesar el historial de estados de un agente para confeccionar los datos para mostrar un histograma. El único factor limitante de la implementación del componente es la interfaz que éste deberá respetar para poder integrarse correctamente al sistema. 57 de 105

59 Excepto por la interfaz común que debe implementar, internamente los Componentes de Extensión Funcional no tienen restricciones de implementación. Toda la lógica implementada por el componente no podrá acceder al sistema, por lo que es necesario que al momento de su ejecución, se provea al componente con todos los datos necesarios. Otro punto importante a tener en cuenta es que el componente será utilizado como elementos stateless (sin estado interno persistente aparente), por lo que la implementación, si bien puede conservar estado interno, debe tener particular consideración de este aspecto (particularmente en aspectos tales como concurrencia del código). Para poder ser debidamente administrado, cada componente debe proveer una serie de datos básicos que permitan identificarlo y comprender su funcionamiento u objetivo. Dicha información, al igual que la funcionalidad del componente, debe ser expuesta por medio de una interfaz común a todos los componentes. A través de esta interfaz el sistema podrá relevar todos los componentes disponibles, e indexarlos para permitir su uso desde otros módulos. Más aún, el administrador del sistema tendrá la posibilidad de definir qué componentes se encontrarán disponibles para su uso, por medio del panel de configuración del módulo Elementos que intervienen Ciclo de vida en el sistema Este módulo comprende uno de los módulos principales del sistema, por lo que se encontrará activo durante todo el período de ejecución del sistema. Durante su funcionamiento éste podrá ser invocado desde otros módulos para la solicitud de ejecución de un componente de extensión funcional. Al momento de atender una solicitud de ejecución primero será necesario determinar si el componente solicitado se encuentra disponible en el sistema, y luego que éste se encuentre habilitado para su uso. Los Componentes de Extensión Funcional propiamente dichos tendrán múltiples ciclos cortos de ejecución. Cada ciclo de ejecución se corresponde con una solicitud de ejecución 58 de 105

60 de un módulo externo, con la posibilidad de que múltiples ciclos de ejecución deban realizarse de forma concurrente. Si bien no se restringe la posibilidad de mantener estado interno, cada ciclo de ejecución se considera como terminado una vez que el proceso solicitado termine. Esto implica que una vez que el componente realizó el proceso correspondiente para los datos dados, éste pasa a estado pasivo Contratos funcionales que implementa Solicitud de componente: El módulo de administración puede ser accedido por otros módulos para solicitar componentes de ejecución. Este contrato provee al solicitante con una referencia remota al componente para solicitar que se ejecute con los datos que se especifiquen, y luego utilizar su respuesta. Ejecución de componente: Cada componente ofrece una forma única y uniforme a través de todos los Componentes de Extensión Funcional para su ejecución. Lo que difiere entre un componente y otro es el volumen de datos que se le deben proveer, y la estructura de los datos que éste devuelve al finalizar su ejecución Publicación de parámetros de identificación: Cada componente debe proveer de información de identificación para su administración desde el módulo de administración. Al mismo tiempo dicha información es utilizada por otros módulos para realizar la solicitud de un componente particular Características de Misión Crítica Al igual que los plugins de entrada, los Componentes de Extensión Funcional pueden ser desarrollos de terceros, por lo que la calidad de su funcionamiento no se puede garantizar para todos los componentes que pueden existir (el nivel de calidad del componente deberá ser analizado por el administrador). Siempre se debe enfocar el desarrollo de un componente para satisfacer todas las características posibles, ya que a diferencia de los plugins de entrada, éstos no pueden ser complementados por el módulo administrador ya que la funcionalidad que implementa es desconocida para éste. Teniendo en cuenta esta característica, los Componentes de Extensión Funcional comprenden un punto en el cual un administrador del sistema puede comprometer la robustez del sistema por confiar en un componente que no se encuentre debidamente probado. Esto no implica que afecte a la totalidad del sistema, sino que todo proceso que dependa de un componente de baja calidad correrá el riesgo de fallar por inconsistencias en el funcionamiento del componente. Esto se logra gracias a que el módulo administrador 59 de 105

61 ejecutará cada componente de forma aislada, para evitar que los errores que puedan surgir de éste repercutan en otros componentes o módulos Emisión de registros de sistema Errores: Cada componente tiene la posibilidad de emitir errores en su funcionamiento, indicando la información necesaria para poder identificar de manera unívoca al componente de origen. Sin embargo estos errores no podrán ser utilizados dentro del Motor de Reglas del sistema, sino que serán parte sólo del registro de errores del mismo Salidas Propiedades Generales Al igual que los plugins de entrada para el relevo de datos, para emitir comunicaciones con elementos exteriores al sistema existen gran variedad de métodos de comunicación que se pueden utilizar. Es por ello que se define un esquema de Plugins de Salida que flexibilizan la capacidad de comunicación del sistema al exterior, permitiendo extenderla conforme aparezcan nuevas tecnologías de comunicación. Un plugin representa a un módulo que permite establecer un canal de comunicación con un elemento externo al sistema, el cual puede ser único para un elemento particular, como así también genérico para comunicarse con elementos que implementan un protocolo estandarizado. Para simplificar el método de integración se define una interfaz y requerimientos de implementación que se deben satisfacer al momento de desarrollar el plugin. Dicha interfaz expone el comportamiento necesario para realizar una comunicación con un elemento externo, y para solicitar información relativa al tipo de configuración que requiere el plugin para conectarse (parámetros de configuración). Al igual que los agentes para el módulo de Lecture Mapping, es necesario establecer la configuración necesaria para cada salida que se requiera utilizar en el sistema, especificando qué plugin utiliza y la configuración necesaria que éste requiere para poder establecer el vínculo de comunicación. Más aún, la definición de salida no comprende una restricción en cuanto a qué tipo de componente externo o protocolo deberá utilizar ésta. Dado que deben comunicarse con elementos externos al sistema, una salida no requiere mantener registro de lo que se le comunicó, como puede ser la activación de una alarma, que no necesariamente mantiene un historial de cuando fue activada. Al mismo tiempo una salida no necesariamente debe comprender algo más que un registro histórico de los valores comunicados. Este último caso puede comprender un archivo de registro, o incluso una interfaz contra otro sistema que se 60 de 105

62 alimenta de la información generada por el Sistema de Monitoreo. Teniendo esta definición general de lo que puede comprender un plugin de salida, el sistema ofrece una gran capacidad potencial de integración con otros sistemas, siempre que se logre desarrollar el plugin de salida que actúe como intermediario entre éstos, y se establezcan el conjunto de reglas necesarios para generar la información que se desea comunicar. Por último, así como existe el módulo de Lecture-Mapping para los plugins de entrada, es necesario que los plugins de salida sean configurables por medio de un módulo administrador (este módulo comprende la definición tanto del módulo administrador como de los plugins que administra). A través de este módulo de administración de Salidas se podrán configurar las distintas instancias de los plugins que se pueden utilizar para comunicar información al exterior del sistema. Es a través de este módulo también por el cual el motor de reglas tendrá la posibilidad de solicitar una instancia para realizar dicha comunicación. Las tareas de administración del módulo deberán ser realizadas por un administrador del sistema, y se considera como una tarea de despliegue inicial, ya que una vez configuradas todas las salidas su administración no debería ser necesaria excepto que se deseen introducir cambios en las salidas disponibles Elementos que intervienen Ciclo de vida en el sistema Los plugins de salida no son elementos activos del sistema, sino que entran en acción únicamente cuando se solicite su ejecución desde otro módulo. Dicha invocación quedará 61 de 105

63 relegada al módulo de administración de salidas, a través del cual se realizarán todas las peticiones de ejecución. Internamente el funcionamiento del plugin no tiene limitaciones en cuanto a cómo debe funcionar. Ya que una vez invocado el plugin no requiere generar una respuesta requerida por el invocador, no es necesario que su funcionamiento sea sincrónico. Esto implica que una vez realizada la invocación el módulo administrador realizará el seguimiento de la ejecución del plugin, mientras que el módulo invocador puede continuar realizando otras tareas. Por otra parte, el módulo administrador integra un módulo principal del sistema, por lo que éste siempre se encontrará activo durante la ejecución del mismo. Sus actividades pueden depender desde la invocación desde otros módulos para la invocación de plugins, como así también por medio de interacción del administrador del sistema para la inicialización de nuevas salidas o modificación de los parámetros de ejecución de salidas preexistentes. Existe una situación particular en la que la ejecución del módulo se desprende del ciclo de ejecución del invocador, que es el caso de ejecuciones asincrónicas de los plugins (como se describió previamente). En estos casos el módulo administrador permanecerá en su actividad mientras el plugin no notifique que terminó sus operaciones Contratos funcionales que implementa Administración de plugins: El módulo administrador debe exponer la funcionalidad necesaria para habilitar, deshabilitar, crear, modificar y eliminar instancias de plugins de salida que se encuentren habilitadas en el sistema. Esta interfaz es requerida para permitirle al administrador del sistema realizar la inicialización requerida para la puesta en marcha del sistema. Solicitud de ejecución de plugins: Ya que el módulo administrador es el intermediario entre el resto del sistema y las instancias de plugins configuradas por el administrador, es necesario que este exponga la funcionalidad necesaria para invocar módulos identificados por medio de un código de identificación único. Junto a este código de identificación será necesario especificar también los parámetros con los que se realizará la ejecución para el caso en que una misma instancia permita comunicar información generada dentro del sistema a los componentes externos a éste. Invocación de plugin, Para que un plugin pueda ser invocado por el módulo administrador es necesario que esté presente una interfaz de invocación normalizada para todos los plugins. Es a través de ésta que el sistema solicita la ejecución de un plugin con los datos de una instancia determinada, y con los parámetros asociados a la solicitud de ejecución. 62 de 105

64 Publicación de parámetros de configuración: Como un plugin puede configurarse en múltiples instancias si se trata de una implementación genérica de un método de comunicación, es necesario que éste informe qué parámetros se deben establecer para configurar una instancia. Esta interfaz provee una forma normalizada de solicitar dicha información, la cual puede ser luego utilizada por una interfaz gráfica para la configuración por parte del administrador del sistema Características de Misión Crítica Dadas las características de los plugins, éstos no pueden garantizar que su implementación contemple características de misión crítica. Sin embargo es el módulo de administrador el cual puede cubrir parcialmente esta carencia funcional. Dentro de los parámetros de configuración expuestos por el plugin se pueden especificar ciertas características de funcionamiento, como frente a qué situaciones el sistema puede solicitar una repetición de una operación frente a una falla, o solicitar múltiples parámetros de configuración para casos de servicios que se encuentren disponibles por más de un medio de comunicación. Bajo este esquema, el sistema puede continuar funcionando normalmente incluso en ambientes con problemas de comunicación o problemas de funcionamiento varios. Por otro lado, inherente a la definición de los plugins y complementado con el funcionamiento del módulo administrador, un problema severo que pueda surgir en un plugin queda confinado a éste, sin afectar a otros plugins u otros módulos que no dependan del plugin problemático. De esta manera, frente a un plugin con problemas de funcionamiento el sistema puede operar normalmente con todos los elementos que no requieran de dicho plugin para su operación. Frente a cualquier error, el sistema será debidamente notificado y podrá actuar según las reglas establecidas por el administrador. Estas reglas pueden incluso servir como acción alternativa, ya que el error reportado no sólo posee adjunto el identificador del plugin de salida problemático, sino también los parámetros de ejecución de la invocación original Emisión de registros de sistema Errores: Frente a un error en un plugin, éste deberá ser debidamente registrado, y podrá utilizarse como evento para el motor de reglas. El error deberá contener el código de identificación de la instancia de plugin utilizada, sus parámetros de configuración de instancia y parámetros de invocación. De esta manera, por medio del motor de reglas, el administrador de sistema puede establecer un manejo avanzado de errores con capacidad de tomar acciones alternativas frente a un fallo de comunicación. 63 de 105

65 6.5.6 Motor de Reglas Propiedades Generales El motor de reglas le brinda al sistema la característica de ser personalizable a la hora de tomar decisiones de acción en función de los estados de sus agentes. Este motor le brindará al administrador la capacidad de establecer qué acciones deberá realizar el sistema en función de los datos obtenidos. Para poder brindar esta funcionalidad, el motor de reglas permite interactuar con los datos de entrada, los Componentes de Extensión Funcional y las salidas para emitir las notificaciones necesarias. Dada la variedad de agentes que podrán ser monitoreados, es importante brindarle al administrador la posibilidad de configurar las reglas de monitoreo de manera flexible. Por lo general, los sistemas tradicionales que brindan interfaces gráficas para configurar estas acciones son limitados en cuanto a lo que permiten realizar como acciones en función de las entradas. Para no caer en estas limitaciones el sistema permitirá al administrador definir las reglas mediante la utilización de un lenguaje de programación. De manera similar a como se escribiría una rutina en un programa, el sistema permitirá escribir una regla. Esto permite definir una lógica tan compleja como sea necesaria al momento de evaluar los estados de los agentes. Para que la inclusión de las reglas se pueda hacer mediante un leguaje de programación, y que simultáneamente el código de las reglas pueda existir en formato texto dentro del sistema, se utilizará el lenguaje Javascript, y será ejecutado por el motor Rhino de Javascript para Java. De esta manera se podrá incluir el código de las reglas sin necesidad de compilar ni referenciar librerías externas, cuyo desarrollo implica un esfuerzo considerablemente mayor. Además, desde la interfaz de administración del sistema se podrá modificar la lógica de las reglas existentes y cargar la lógica de las nuevas reglas. Como todo entorno en el cuál se va a ejecutar código, el sistema va a exponer ciertos objetos para ser utilizados desde la lógica de las reglas. Estos objetos permitirán interactuar con los Componentes de Extensión Funcional y las salidas del sistema, pudiendo principalmente consultar los valores monitoreados actuales, históricos y acceder a la información de monitoreo de otros agentes del sistema. Además, también permitirá interactuar con las salidas para generar las alertas y notificaciones si correspondieran. Las reglas no sólo tendrán disponible los estados de los agentes y las salidas del sistema, sino que también podrán interactuar con los Componentes de Extensión Funcional agregados al sistema, que permitirán simplificar la lógica de procesamiento de ciertos agentes, haciendo uso de los algoritmos ofrecidos por los componentes. 64 de 105

66 La ejecución de reglas tiene lugar dentro de lo que se conoce como contexto de ejecución. Este contexto es el que expondrá al código de la regla una serie de objetos. Estos objetos serán las referencias correspondientes a los otros módulos del sistema, para posibilitar el consumo de los servicios provistos por éstos, tales como las referencias al Módulo de Salidas para enviar alertas, o al Módulo Agent State Manager para consultar los valores históricos de un agente. Al mismo tiempo, desde el código de las reglas se podrán definir variables de contexto. Éstas permitirán almacenar valores en el contexto de ejecución, las cuales podrán ser utilizadas en subsiguientes ejecuciones. Sin embargo éste no permite utilizar variables definidas en los contextos de otras reglas. Como puede resultar necesario compartir valores entre distintas reglas, el sistema proveerá, mediante un objeto disponible en todos los contextos de ejecución, la referencia a un diccionario para almacenar valores de manera externa al contexto de la regla. Esto permitirá que reglas distintas tengan acceso a variables en común. Debido a que es posible asociar un agente con más de una regla, es posible que un evento de actualización de un agente requiera ser atendido por múltiples reglas. Dentro del flujo de datos del sistema, esto se manifestará como la creación de varios eventos de actualización, todos surgidos del mismo agente, pero para ser procesados, cada uno, por una regla distinta. Si bien el sistema de reglas no soporta establecer un orden en la ejecución de las reglas, dicha característica puede ser deseable o necesaria para implementar ciertos comportamientos. A su vez existen situaciones en las cuales es necesario que, partiendo de distintos agentes, según la naturaleza de los datos de cada uno de ellos, se genere un evento común a todos. Con este objetivo se define el concepto de Evento Virtual, el cual representa un evento generado por la lógica de reglas del sistema, y no por el conjunto de entidades que éste maneja. Este evento virtual permite no sólo desasociar el evento de un Agente específico, sino que también asegura que dicho evento se ejecute luego de ejecutarse todas las reglas asociadas al evento originante. Este evento virtual sólo se diferencia de un evento normal en su origen, por lo que debe contar también con un Agente asociado que simule el origen del evento. Para ello se define el concepto de Agente Virtual, que, al igual que el Evento Virtual, representa a un Agente que no se encuentra directamente relacionado con un agente externo real. Dicho Agente Virtual permite establecer un vínculo entre el invocador y las reglas asociadas al Evento Virtual a través del cual se pueden comunicar los datos necesarios para la lógica de las reglas asociadas. Por otra parte, dado que puede existir la necesidad de definir múltiples reglas muy similares para atender eventos de Agentes de la misma naturaleza, el sistema ofrecerá la posibilidad de utilizar reglas a modo de template. Esto implica que una regla puede definirse copiando 65 de 105

67 los datos de una regla existente, permitiendo rápidamente generar múltiples reglas similares de forma rápida y sencilla. Para eliminar la necesidad de modificar el script generado, la regla permitirá al usuario definir parámetros que pueden ser luego utilizados dentro del script Elementos que intervienen Ciclo de vida en el sistema Este es otro de los módulos centrales del sistema y su función da soporte a una de las características principales del sistema que es evaluar las entradas. Por lo tanto, su ejecución está directamente controlada por el módulo director, asegurando su correcta ejecución, ya que es fundamental que este módulo esté en ejecución para el correcto funcionamiento del sistema. En general, su estado de ejecución se corresponderá con la ejecución general de todo el sistema, ya que si este módulo no se encuentra funcional, el sistema monitoreo no brindará su servicio. Durante el inicio del sistema, el módulo director se encargará de iniciar la ejecución de este módulo. Durante su inicio, el Motor de Reglas instanciará todos los contextos de ejecución correspondientes a las reglas, referenciará los objetos del sistema en el contexto y cargará el código de las reglas en los mismos, y mantendrá todo a la espera de la llegada de Eventos de Actualización para procesar. A medida que vayan surgiendo Eventos de Actualización disponibles para procesar, el motor de reglas irá ejecutando las correspondientes reglas, referenciando a éstas su correspondiente Evento de Actualización. Durante la ejecución de la regla, el programa que la constituye podrá tener acceso a los datos históricos de los agentes involucrados a través del Agent State Manager. Esto hará posible que una regla pueda tomar decisiones sobre el estado histórico de un agente, tal 66 de 105

68 como puede ser una regla que necesite determinar una tendencia. En algunos casos puede resultar conveniente leer los últimos N datos y en función de la variación de los mismos tomar alguna acción. Este comportamiento es soportado gracias al acceso de los datos históricos de los Agentes. Para generar las salidas, se dispondrá de referencias al Módulo de Salidas. De esta manera la regla generará las alertas correspondientes en caso de ser necesario. Esta funcionalidad genera una dependencia entre las reglas y los plugins de salida. Al momento de diseñar una regla, se debe tener en cuenta qué plugins de salida se va a utilizar y qué recaudos y condiciones hay que tener para utilizarlos. Es recomendable en este punto preferir plugins de salidas que expongan comportamientos asincrónicos, lo que conferirá al motor de reglas una mayor capacidad de atender eventos. Si por el contrario, se realizaran operaciones sincrónicas de entrada y salida desde el código de las reglas, existiría la posibilidad de bloquear la ejecución de las reglas con tiempos muertos de procesador, desperdiciando capacidad de procesamiento. Por último, las reglas tendrán pleno acceso a los Componentes de Extensión Funcional, ya que son una de las principales herramientas al momento de escribir código reutilizable para su consumo por parte de las reglas. Al igual que con las salidas, el hecho de que una regla haga uso de un Componente de Extensión Funcional generará una dependencia entre la regla y el componente. Es posible que distintas reglas utilicen distintas versiones de componentes, situación que al no ser manejada correctamente podrá producir errores si los componentes cambian la lógica y estructura de datos requeridos Contratos funcionales que implementa Administración de Reglas: Mediante esta interfaz se permitirá realizar el mantenimiento de las reglas, permitiendo cargar nuevas reglas y modificar o borrar las existentes. Esta tarea, si bien no presenta mayor complejidad, es de alta importancia ya que la presencia de las reglas es necesaria para el procesado de los eventos de actualización. Estado de ejecución de reglas: Dado que existe la posibilidad de que las reglas se ejecuten frecuentemente, resulta de utilidad exponer la funcionalidad necesaria para obtener los datos correspondientes al estado de ejecución, tanto de las reglas, como del motor. Es por esto que el Motor de Reglas expondrá la funcionalidad necesaria para mantener un estado de ejecución de las reglas. Este punto será el que deberá contemplar la posibilidad de manejar el estado de los contextos de ejecución. 67 de 105

69 Características de Misión Crítica Tal como en el caso de los Plugins o Componentes de Extensión Funcional, las reglas naturalmente van a ser desarrolladas por terceros, justamente como consecuencia de permitir una alta capacidad de personalización y flexibilidad del sistema (distribuyéndose como scripts). Este hecho requiere que deba ser contemplada por el sistema la posibilidad de falla de las reglas. No obstante es necesario remarcar la importancia que debe prestarse al buen diseño de las reglas, en especial en temas como fugas de memoria, robustez ante datos incompletos o de formato inesperado, y eficiencia en cuanto a los requerimientos de tiempo de procesador. Una situación importante a tener en cuenta referido a este módulo es la posibilidad de que existan varias instancias del Motor de Reglas dentro del cluster. El mayor problema en cuanto a la existencia de múltiples instancias de Motores de Reglas es la capacidad para asociar el contexto apropiado a la ejecución de una regla ante la presencia de un Evento de actualización. La importancia radica en que los contextos de ejecución guardan el estado de ejecución de una regla. Para ello, si bien existirán múltiples instancias del módulo ejecutándose en paralelo, los contextos de ejecución se mantendrán centralizados en una única instancia, la cual será publicada para su acceso desde las instancias restantes. Esto permitirá evitar problemas de sincronización entre cachés distribuidas, sin imponer una gran restricción en el paralelismo de la ejecución de reglas Emisión de registros de sistema Si bien naturalmente las reglas procesan los datos de los eventos con el objetivo de emitir notificaciones, sus salidas son generalmente canalizadas a través de los Plugins de Salida y no como una emisión de registro de sistema. Sin embargo, en caso de que se produzcan errores, éstos estarán debidamente informados en los registros de sistema. Errores de ejecución de reglas: Es posible, y el sistema lo contempla, que la ejecución de una regla resulte errónea. En caso de producirse un error al momento de ejecutar una regla, se generarán un registro de error para evidenciar la situación anormal. De acuerdo con esto, el sistema estará diseñado para soportar errores en las reglas sin afectar la ejecución del resto de los componentes del sistema, o de la ejecución misma de otras reglas. Errores en invocaciones a otros módulos: Además de los errores propios de las reglas, es posible que surjan errores durante las invocaciones a Componentes de Extensión Funcional o a Plugins de Salida. En estos casos, si bien el error se produce en el código que 68 de 105

70 corresponde a otros módulos, es posible que el error sea reportado por el Motor de Reglas. Esta situación es esperable en aquellos casos en los que se realicen llamadas sincrónicas a los elementos ajenos al Motor de Reglas, debido a que el hilo de ejecución pertenece al motor de reglas. Como en el caso anterior, es importante un buen diseño de las reglas, para que contemplen estas situaciones y el impacto de una excepción sea menor. Respuestas de Componentes de Extensión Funcional: Las respuestas de los Componentes de Extensión Funcional pueden registrarse (en la medida de lo posible) asociándose con la marca temporal del evento atendido. Este registro no cumple ningún objetivo dentro del funcionamiento del sistema, sino que es utilizado por otras herramientas (descriptas posteriormente en la sección de Herramientas Complementarias) Motor de Vistas Propiedades Generales El Motor de Vistas comprende el módulo dedicado a la visualización de los datos manejados en el sistema de manera agregada y procesada para los usuarios del sistema. A través de éste módulo el administrador del sistema puede diseñar pantallas que muestren Componentes de Visualización tales como gráficos, listas o alertas en pantalla, alimentándose de los estados de los agentes, utilizando algoritmos definidos por el usuario para procesar esa información previo a su publicación. Este módulo complementa al módulo de salidas, ofreciéndole a los usuarios del sistema la posibilidad de establecer vistas actualizadas del estado interno del sistema de manera sintética. Para poder definir como el sistema mostrará la información por pantalla, es necesario primero configurar Vistas que definen distintas perspectivas del estado del sistema. Estas Vistas a su vez contienen Componentes de Visualización que representan los elementos que se muestran en pantalla. Las distintas perspectivas que se pueden configurar son enteramente definidas por el administrador del sistema, realizando las agrupaciones de elementos que considere más convenientes. Más aún, no es necesario que cada perspectiva contenga elementos distintos, ya que pueden existir perspectivas que correspondan a distintos tipos de agrupamientos (Ej.: Sensores de Temperatura y Sensores de Sala 2). Las distintas Vistas definidas en el sistema pueden ser ordenadas en una estructura jerárquica de clasificaciones definida por el administrador del sistema. Dicha estructura jerárquica se mostrará en el portal del sistema para poder acceder a dichas Vistas, simplificando efectivamente la forma de acceso a éstas. Internamente cada Vista se 69 de 105

71 compone de varios Componentes de Visualización, asociados a un esquema de orden que define de que forma se mostrarán en pantalla, y de ser necesario agrupamientos para definir pestañas dentro de la misma Vista. Para poder realizar la visualización en pantalla, los Componentes de Visualización deben tener la capacidad de renderizarse. Esto implica que estos elementos deben poder ser embebidos dentro de la representación de una página, la cual luego será convertida a formato HTML para su visualización en el navegador del cliente. Para poder lograr esto junto con la tecnología de visualización seleccionada (GWT), los Componentes de Visualización deben proveer elementos que tienen la capacidad de comportarse como elementos de dicho framework, manteniendo al mismo tiempo la capacidad de ser utilizados en el entorno de ejecución normal para su configuración y población de información a mostrar. Dado que existen multiplicidad de métodos de representación gráfica que pueden existir para los estados de los distintos agentes registrados en el sistema, incluyendo la posibilidad de nuevos formatos de representación que se popularicen o conviertan en técnicamente factibles en el futuro, es necesario que el sistema cuente con la capacidad de extender los formatos de representación que tiene disponibles. Para ello, siguiendo con el esquema adoptado en otros módulos, este módulo contará con un esquema de Plugins de Visualización, los cuales implementan los componentes basados en el framework GWT para realizar el renderizado en el navegador del usuario. Al igual que en los otros módulos, será necesario que éste permita la administración de los plugins, siendo una instancia de estos representado por un Componente de Visualización. Estos elementos se componen por una referencia al plugin junto con su configuración, acompañado por características de identificación y formatos de comunicación requeridos. A su vez, para poder realizar correctamente la representación del gráfico acorde a las necesidades de los usuarios del sistema, el sistema incorpora la posibilidad de definir un script de conversión de datos para alimentar al plugin, Dicho script, basándose en el mismo principio de funcionamiento que las reglas del Motor de Reglas, tiene acceso al histórico de estados de todos los agentes, como así también a los Componentes de Extensión Funcional para realizar operaciones matemáticas avanzadas. Dado que los distintos formatos de representación pueden requerir distintas configuraciones de datos, la estructura de datos requerida por el plugin no se encuentra estandarizada, sino a la forma en que esta se debe definir. Esto permite establecer un formato de comunicación normalizado entre el sistema y el plugin, habilitando al mismo tiempo a definir una estructura de datos arbitraria necesaria para alimentarse. Para dicha estructura de datos se pueden 70 de 105

72 utilizar los mismos esquemas basados en XML utilizado en otros módulos. Dicha estructura deberá ser debidamente definida por el plugin para facilitar su uso al momento de implementar el script de conversión de datos de un Componente de Visualización dado Elementos que intervienen Ciclo de vida en el sistema Siendo un módulo principal del sistema, el Motor de Vistas se mantiene activo durante todo el ciclo operativo del sistema. Sin embargo, a diferencia de otros módulos, todas las operaciones que se realizan en este módulo se derivan de la interacción del usuario con el sistema. La razón por la cual este módulo se mantiene constantemente activo es para maximizar su rendimiento. Ya que existe la posibilidad de que las vistas estén bajo constante uso (múltiples usuarios navegando por las distintas vistas), al mantenerse activas en memoria se reduce la necesidad de estar constantemente cargando desde la base de datos todos los elementos de cada vista. 71 de 105

73 Como se mencionó previamente, la mayor parte de las operaciones que se realizan con este módulo consiste en navegación de Vistas para la consulta del estado interno del sistema. Generalmente las Vistas se encuentran compuestas por múltiples Componentes de Visualización, los cuales se alimentan de los datos provistos por otros módulos. Es probable que estas Vistas requieran ejecutar muchas operaciones matemáticas con volúmenes medios de datos, particularmente cuando existan muchos elementos de representación por gráficos, en donde la información se encuentra preprocesada para calcular los distintos componentes de dicho gráfico. Más aún, el resto de las operaciones corresponden a tareas administrativas de configuración. Como es de esperar, el sistema por defecto no cuenta con ninguna Vista o Componente de Visualización predeterminado, por lo que éstos deben ser configurados al momento de realizar el despliegue inicial del sistema. A su vez será necesario realizar la configuración de todos los Plugins de Visualización que se utilizarán en conjunto a los componentes. Todos los elementos configurados en estas tareas se encontrarán directamente disponibles para su navegación a través del portal del sistema. Por otra parte, los Plugins de Visualización poseen un ciclo de vida corto y reiterado durante el ciclo de operación del sistema. Esto se debe a que carece de sentido mantener un plugin en memoria ya que no requiere mantener ningún estado, y su operación no debería diferir entre un caso y otro (esto es una norma que deben cumplir todos los Plugins de Visualización desarrollados para mantener la performance del sistema) Contratos funcionales que implementa Administración de Plugins: Es necesario que el sistema tenga conocimiento de todos los Plugins de Visualización que se encuentran disponibles. De no ser así resultaría imposible conocer desde el sistema qué estructura de datos espera un plugin para poder realizar la representación gráfica de un estado de un agente. Administración de Componentes de Visualización: Teniendo a su disposición los Plugins de Visualización, es necesario definir los distintos componentes que podrán asociarse a una Vista para su visualización. Dentro de estas tareas se incluye la definición de la lógica utilizada para la conversión de datos del sistema a la estructura requerida por el plugin. Administración de Vistas: El paso final para realizar la configuración del sistema es la definición de las distintas Vistas del sistema. Cada vista no sólo deberá ser clasificada para 72 de 105

74 su fácil acceso, sino que deberá asociar los distintos componentes que mostrará, los agrupamientos de éstos, su orden y esquema de ordenamiento. Publicación de datos de configuración: Como se mencionó previamente un Plugin de Visualización puede definir una estructura arbitraria de datos que puede requerir para realizar la representación gráfica de un conjunto de ellos. Para ello es necesario que el sistema tenga una forma normalizada de acceder a estos datos. Generación de Elementos de Representación: Un plugin actúa como Factory de elementos que pueden embeberse en la representación de objetos de una página para ser luego transformado al formato de visualización correspondiente. Esta interfaz le permite al sistema pedirle a cualquier plugin que genere dicho elemento al momento de componer una página, alimentándolo previamente con la estructura de datos requerida Características de Misión Crítica Siendo un módulo que complementa al módulo de Salidas, el Motor de Vistas se enfoca en las características de Monitoreo que posee el sistema. Es a través de este módulo que un usuario puede consultar el estado interno del sistema, permitiéndole acceder a la información en tiempo real y de forma sintética, que en caso contrario debería ser compilada por otra aplicación alimentándose de los datos que el sistema segrega a través del módulo de Salidas. Más aún, no sólo permite observar el estado del CPD en general, sino el estado del sistema mismo. Como se mencionó en puntos anteriores muchos elementos tienen la posibilidad de reportar errores de manera interna, y utilizar dichos errores como una fuente de datos. Dicha fuente de datos podría luego ser utilizada para aplicar distintas reglas y tomar alguna acción según se haya definido Emisión de registros de sistema Errores: Cualquiera de los elementos que intervienen en este módulo tiene la capacidad de generar errores. Los plugins pueden generar errores por problemas de dependencias, los Componentes de Visualización pueden no satisfacer la estructura de datos requerida por el plugin, o las vistas pueden presentar algún error al momento de componer su estructura visual. Todos estos errores se registran en el sistema pero no sirven de fuente de datos para el motor de reglas. La razón de esto es que este módulo, si bien es un módulo principal, no compone parte del flujo crítico de datos que comprende el sistema, por lo que definir reglas para tratar estos errores no se considera prioritario. 73 de 105

75 6.5.8 Macro-módulo o Módulo Director Propiedades Generales Estando el sistema compuesto por módulos heterogéneos, cada uno dedicado a su propia administración, resulta necesario definir un componente que administre todos los módulos componentes. Para ello se define el Módulo Director, o Macro-módulo, el cual administrará el funcionamiento de todos los módulos anteriormente mencionados, como así también todos los módulos secundarios definidos más adelante. Dado que todos los módulos tienen un bajo nivel de acoplamiento, éstos no pueden acceder de forma directa entre ellos, sino que deben solicitar su acceso a través del Módulo Director. Éste personificará el módulo solicitado, actuando como intermediario entre el módulo real y el solicitante. En términos generales la especificación de este módulo cumple con varios patrones de diseño orientados a diseños modulares y extensibles. Por empezar, éste cumple con el patrón de Service Locator, ya que permite a los distintos módulos hacer uso de otros módulos sin que tengan conocimiento directo entre sí de su existencia. Esto se logra principalmente por medio del uso de interfaces o Contratos Funcionales, los cuales permiten abstraerse de una implementación específica, junto con la tecnología de búsqueda de instancias de módulos por naming, provistas por el servicio de naming (JNDI) de J2EE. Por otra parte, este módulo cumple con el patrón Interceptor, ya que actúa como intermediario en las comunicaciones entre todos los módulos. Esto implica que cualquier lógica intermedia que se desee incorporar al sistema (ya sea desde un registro de llamadas hasta una transformación intermedia de datos), sólo requerirá una modificación al Módulo Director, sin necesidad de modificar los módulos intervinientes originales. Acorde con la característica modular del sistema, así como se definen un conjunto estándar de módulos implementados, también se debe admitir la posibilidad de que uno de estos módulos sea modificado o reemplazado por un módulo de terceros, respetando éste las interfaces correspondientes. Para brindar este nivel de flexibilidad el Módulo Director, haciendo uso de los servicios de naming provistos por JNDI, permitirá al administrador parametrizar las rutas de los módulos que componen el sistema. Al delegar la búsqueda e instanciación del módulo al entorno de ejecución de J2EE, el sistema puede interactuar con el nuevo módulo valiéndose únicamente de las interfases definidas. Para que éste se encuentre disponible en el sistema sólo será necesario instalarlo en el contexto del Application Server, el cual lo indexará y hará disponible a otros componentes disponibles en el mismo entorno. 74 de 105

76 Elementos que intervienen Ciclo de vida en el sistema El Módulo Director se puede considerar como un representante directo del Sistema. El ciclo de vida de este módulo afecta a todos los módulos del sistema, y de éste dependen para su inicialización e interconexión. Al momento de iniciar el sistema, el Módulo Director deberá solicitar instancias de todos los módulos configurados, y actuar como referente a todos ellos, manteniendo dichas instancias activas durante su ejecución. Dado que este módulo actúa como intermediario entre todos los módulos, éste presentará el nivel de actividad más elevado del sistema, ya que su actividad se compone por la suma de actividades de todos los módulos que lo componen. Debido al elevado nivel de actividad que presenta, resulta imperativo que este módulo se encuentre desarrollado enfocado en la performance Contratos funcionales que implementa Ya que este módulo es el intermediario de todos los módulos del sistema, requerirá implementar los contratos funcionales de todos los módulos que representa. Sin embargo, además presenta funcionalidad adicional que no puede ser adjudicada a ningún módulo particular. Configuración de módulos: Por medio de esta interfaz se puede definir que módulos se utilizarán para la ejecución del sistema. La configuración deberá ser cargada conforme a la información obtenida de los módulos instalados. Inicio y parada de sistema: Debido a que pueden realizarse paradas por mantenimiento, el sistema requerirá un medio por el cual controlar su funcionamiento. Esta interfaz permitirá al administrador detener el servicio hasta que las condiciones de operación vuelvan a la normalidad. 75 de 105

77 Características de Misión Crítica Dado que cada módulo posee su propio enfoque sobre las características de Misión Crítica, el Módulo Director se encargará únicamente de controlar el funcionamiento de todas las partes de forma integrada. Los principales aspectos que sobresalen en su implementación son Disponibilidad y Confiabilidad. El requerimiento de Disponibilidad se satisface por medio de ejecución distribuida de componentes. Cuando un módulo se referencia por nombre, siendo el nombre parte del contexto del cluster del Servidor de Aplicaciones, frente a un problema en el nodo en el que reside bastará con restaurar la instancia en otro nodo volviendo a solicitarla al entorno. Por otra parte, el requerimiento de Confiabilidad se satisface de forma similar, con la excepción de que en este caso el Módulo Director deberá analizar si el estado de un módulo particular frente a un error se puede considerar como consistente. En caso negativo, la instancia se descarta y se solicita una nueva instancia Emisión de registros de sistema Registro de funcionamiento: Para facilitar el análisis del estado de funcionamiento del Módulo Director, éste generará un log en el cual volcará la información de su funcionamiento. Dentro de este log se podrá registrar tanto información general de funcionamiento, advertencias frente a situaciones adversas superadas, o errores críticos que conllevan una inmediata parada de sistema. A diferencia de otros módulos, éste utiliza sus propios medios de registro, ya que su funcionamiento no puede encontrarse asociado a un componente que tiene el potencial de fallar y deshabilitar su capacidad de generación de logs de funcionamiento. 6.6 Módulos Secundarios y/o de Soporte Autenticación y Control de Acceso Este módulo tiene por objetivo restringir el acceso a los distintos módulos del sistema a los usuarios no autorizados; el acceso a recursos del sistema, recursos remotos o privilegios de ejecución del sistema en su entorno operativo, junto con la seguridad de los repositorios de datos, son puntos de seguridad que deberán ser tratados por el Administrador por fuera del sistema, al realizar su instalación. Para poder hacer efectiva estas medidas de seguridad será necesario establecer que todo usuario requiera pasar por una etapa de autenticación previo al acceso a cualquier elemento del portal web del sistema. Los métodos de autenticación pueden ser variados, abarcando desde un simple método de usuario/clave para el sistema, integración con autenticación de dominio, o cualquier servicio 76 de 105

78 de autenticación que se base en generación de tokens para la autenticación de un usuario. Cada esquema tiene sus ventajas y desventajas y satisface distintas necesidades de seguridad según los requerimientos impuestos por las políticas de seguridad del entorno de trabajo: Usuario/Clave: Es el esquema más sencillo de seguridad, ya que funciona por defecto, sin la necesidad de realizar integración con ningún elemento externo. Todo el esquema de seguridad es manejado por el sistema, incluyendo la definición de usuarios, permisos de acceso y datos de cada uno y claves de acceso. La desventaja de este esquema es que ciertas políticas de seguridad requieren un esquema más robusto que uno basado en claves. Además hoy en día existe la tendencia en las grandes corporaciones a integrar todos los servicios de acceso para facilidad administrativa. Autenticación de dominio: Corresponde a un esquema similar al anterior, con la salvedad de que los usuarios se autentican contra un servicio de autenticación externo, el cual administra todos los usuarios del dominio. Este esquema, como se mencionó anteriormente, presenta ventajas administrativas tales como baja de usuarios para todos los sistemas integrados, o actualización de datos de los mismos que se propagan de manera automática. Sin embargo cuenta con la misma debilidad frente a políticas de seguridad. Un sistema de autenticación ampliamente utilizado en entornos corporativos es LDAP, existiendo distintas implementaciones según el sistema operativo. Autenticación por tokens: La autenticación por tokens permite integrar otros métodos de autenticación al sistema, utilizando servicios de integración que permitan validar un token generado por un punto de acceso brindado por el sistema de autenticación externo. Al momento de utilizar el sistema, éste puede previamente solicitar una redirección al punto de acceso del sistema de autenticación, el cual puede solicitar cualquier conjunto de datos que sea necesario para la autenticación (estos esquemas pueden incluir métodos de seguridad avanzada como OTP o Biométricas), generando internamente un token, el cual le es comunicado al sistema. El sistema, al recibir este token se comunica con el sistema de autenticación para obtener los datos de usuario del token recibido para luego permitirle el acceso al sistema al usuario en caso de que el token sea válido. 77 de 105

79 Para simplificar la asignación de permisos de acceso, el sistema permitirá la creación de Grupos, los cuales tendrán permisos de acceso al sistema que se proyectarán a todos los usuarios incluidos en dicho grupo. A su vez un usuario puede tener permisos particulares de acceso, los cuales predominan sobre los permisos heredados de los grupos a los cuales se encuentra asignado. Todas las interfaces de configuración de los distintos módulos del sistema tendrán configuraciones de acceso distintas, como así también todas las interfaces de operaciones administrativas de los módulos secundarios, e interfaces de configuración de despliegue del sistema que no pertenecen a un módulo particular. Más aún se provee la posibilidad de brindar control de acceso a las distintas vistas, permitiendo limitar a un grupo determinado de usuarios el acceso a una vista en particular, o a todas las vistas que pertenecen directa o indirectamente a una Clasificación dada. Por último, para asegurar la seguridad al operar con el sistema, se implementa un sistema de tokens que se utilizan para validar las distintas operaciones. Este sistema de tokens se enfoca en generar para cada operación de cada usuario un token dado, el cual es enviado al navegador del cliente. Al realizar una operación se envía nuevamente ese token, el cual se utiliza para verificar si éste fue emitido y si se encuentra dentro del lapso de validez del mismo, y si el usuario que desea realizar la operación es el que solicitó originalmente el token. De esta manera se realiza una pseudo-autenticación por cada operación que se realiza contra el sistema, imponiendo una restricción a cualquier ataque de personificación que se pueda hacer. Más allá de esta metodología implementada, es necesario que los protocolos de comunicación utilizados sean seguros, tales como HTTPS para la comunicación de datos con el navegador. 78 de 105

80 6.6.2 Interfaces de Configuración del Sistema Con la excepción del módulo de Motor de Vistas, el resto de los módulos principales o secundarios consisten en diseños de backend, implicando que se concentran en definir cómo será la lógica del módulo, definiendo características puntuales de la interfaz gráfica de configuración que se integra con el módulo. Este método de diseño sigue el principio de implementación por capas, en el cual los elementos de visualización no se encuentran definidos con los elementos de lógica de negocio o de persistencia, facilitando el mantenimiento de cada capa sin necesidad de alterar las otras. Requiriendo todos los contratos funcionales de administración del sistema, como así también la mayoría de los módulos secundarios, un medio por el cual el administrador del sistema pueda aplicar la configuración necesaria, cada uno de estos elementos contará con una interfaz gráfica. Cada interfaz gráfica incluirá todos los parámetros requeridos para realizar la configuración necesaria, como se puede observar en las distintas pantallas incluidas en el Anexo de Manual del Usuario, en donde se detalla además los distintos campos que comprenden la interfaz, y su modo de uso. Un elemento particular de administración que no puede ser representado por una interfaz gráfica de estructura estática es la instancia de cualquiera de los plugins que se definieron anteriormente. Teniendo éstos una estructura de datos arbitraria requerida por el plugin, los datos solicitados y sus tipos pueden ser variados. Para ello se establece que dentro de los parámetros de configuración publicados por los plugins, la sección donde se describan los parámetros de configuración posea una estructura determinada, la cual puede ser utilizada para armar en tiempo de ejecución una interfaz gráfica que corresponda a los atributos y tipos de datos especificados por el plugin. Utilizando este tipo de generación dinámica de interfaces gráficas se puede simplificar la forma de configurar una instancia de plugin, presentándole al administrador del sistema una interfaz gráfica estéticamente idéntica a otras interfaces del sistema, con todos los elementos publicados por el plugin. Más aún, si así se detalló en la configuración publicada por el plugin, todos los campos pueden tener asociados textos de ayuda para facilitar aún más su uso. Este tipo de interfaces dinámicas se puede conseguir fácilmente gracias a la estructura de objetos de composición de página ofrecida por GWT, la cual se puede integrar con un intérprete de la configuración del plugin para generar la estructura de objetos necesaria para componerla. 79 de 105

81 6.6.3 Servicios de Registro del Sistema Todos los módulos principales del sistema generan registros del sistema, y dichos registros son administrados por el módulo de Registro del Sistema. Como se mencionó anteriormente, distintos módulos generan distintos tipos de registros, o registros del mismo tipo con distintos contenidos de datos. Ciertos registros generados pueden ser notificaciones del estado interno de un módulo, mientras que otros pueden corresponder a un error relativo a un componente particular del módulo de origen. Todos estos datos deberán ser debidamente guardados por este módulo. Como los distintos tipos de registros generados en los módulos, como así también los registros de los distintos módulos, tienen distinto nivel de importancia para el administrador del sistema, es necesario que éste pueda definir como se administran dichos registros. Una de las principales características a determinar en el sistema es qué elementos van a ser efectivamente registrados, ya que no toda la información puede serle relevante al administrador. Esto implica que si bien un registro es generado en un módulo, dicho registro puede descartarse si en el módulo de Registro del Sistema se especificó que los registros del tipo o del módulo de origen no son de importancia. Más aún, ciertos registros definidos anteriormente tienen la capacidad de generar eventos de actualización que pueden ser tratados por el Motor de Reglas. Esto implica que el módulo deberá contar con la capacidad de generar los eventos correspondientes para poder tratar la situación actual. Esto implica, además, que el administrador debe tener la capacidad de configurar por medio de este módulo qué orígenes de registros permiten o no generar eventos, para evitar carga indeseada en el sistema. Por otra parte, así como el módulo deberá mantener los registros generados, será necesario además que permita acceder a los registros ya existentes en el sistema. Para simplificar la búsqueda de información, se deberá poder especificar ciertos criterios de búsqueda para reducir el tamaño del historial a mostrar, con parámetros tales como módulo de origen, tipo de registro y términos a encontrar dentro del contenido del registro. El propósito de este acceso es meramente informativo, para ser utilizado en la interfaz gráfica como un historial de actividades del sistema. Por último, este módulo deberá ofrecer la posibilidad de determinar cómo se persistirán los registros que debe mantener. Inicialmente se contará con dos posibilidades, que consisten en registro por Base de Datos y registro por Archivo de Log. Esto permite al administrador 80 de 105

82 del sistema elegir el método que le sea de mayor utilidad, ya que cada uno cuenta con ventajas y desventajas: Registro por Base de Datos: Ofrece la ventaja de simplificar los métodos de búsqueda, ya que los motores de Base de Datos cuentan con algoritmos de búsqueda optimizados. Sin embargo posee la desventaja de que acceder por medios externos a esa información requiere contar con una serie de herramientas de conexión que permitan conectarse a la Base de Datos donde los registros fueron persistidos. Registro por Archivo de Log: Cuenta con la ventaja de encontrarse disponible como un archivo en el sistema de archivos, y al ser en texto plano puede ser accedido con cualquier herramienta de edición de texto. Por otra parte, cuenta con la desventaja de no ser óptimo para realizar búsquedas de información dentro de éstos, ya que ciertos datos que se diferenciaban por columnas en la base de datos, aquí se deberán determinar buscando separadores de texto Mantenimiento de repositorios de datos Todos los elementos del sistema requieren cierta parametrización que debe ser persistida para asegurar que su funcionamiento continúe siendo el mismo frente a una parada de sistema y subsiguiente reinicio. Más aun, ciertos módulos generan registros o poseen elementos con historial de estados que se expanden con el funcionamiento del sistema, sin ningún tipo de límite en su crecimiento. Esto puede conllevar severos problemas de mantenimiento dado el volumen de datos generado. Dada la necesidad de controlar el crecimiento del volumen de datos, se define un módulo que proveerá al sistema con medios de control sobre dicho crecimiento bajo distintos criterios de selección. Dado que es imposible definir un criterio de control único para todos los entornos de producción que pueden existir en los distintos CPDs, dicho criterio deberá poder ser configurado por el administrador del sistema acorde a sus necesidades. Como se mencionó anteriormente, los agentes poseen asociada una configuración relativa al tamaño mínimo de historial que se debe mantener para éste. En conjunto con esta configuración, el administrador tendrá la posibilidad de configurar para cada módulo y tipo de registro emitido el tamaño máximo de historial que pueden mantener, ya sea por cantidad de registros o por vejez de la información en caso de que se deba cumplir con ciertas políticas de seguridad y mantenimiento de información para auditorías (para el caso de historiales de agentes, prevalece la opción que mayor volumen de datos preserva). El proceso de purga del 81 de 105

83 repositorio de datos se ejecutará a intervalos regulares o en determinadas fechas configurables por el administrador. Controlar el volumen de datos manejado por el sistema no implica necesariamente la eliminación de los datos que exceden a los límites impuestos. La eliminación del excedente de datos consiste en la configuración más básica, pero como se mencionó anteriormente puede ser necesario que por políticas de funcionamiento todos los datos deban ser preservados. Para permitir un mejor control sobre el rendimiento y escalabilidad del sistema, manteniendo el volumen de información impuesto por políticas, este módulo proveerá al administrador con la posibilidad de migrar toda la información excedente a una base de datos secundaria, la cual no será utilizada por el sistema excepto para hacer el traspaso de información. Utilizando esta opción se podrá limitar considerablemente el volumen de datos con el que trabaja el sistema (particularmente esta opción es ventajosa cuando la cantidad de elementos manejada por el sistema es elevada, y se realizan actualizaciones en lapsos cortos de tiempo), mientras al mismo tiempo se mantiene el historial de datos acorde a las normas. 6.7 Características del modelo de datos General Como se puede apreciar en la arquitectura del sistema, éste debe manejar datos tanto de lectura como de configuración y directivas de operación. Dependiendo de cómo se haya desplegado el sistema en su ambiente operativo, y también de la complejidad de dicho ambiente, el volumen de datos que se manejará varía. Sin embargo siempre existirá una marcada diferencia de volumen de datos según la naturaleza de los mismos, ya que cada conjunto tiene distintos propósitos y métodos de mantenimiento. Es por ello que cada conjunto debe ser descripto de manera individual, detallando las particularidades del mismo respecto de otros conjuntos. El principal problema ajeno a la definición del modelo que soportará a la aplicación es la persistencia de estructuras de datos arbitrarias. Dichas estructuras no pueden mapearse directamente contra una estructura de datos definida, ya que su propia estructura puede ser definida por el usuario o por terceros que desarrollen componentes para el sistema. Es por ello que se optó por tratar dichas estructuras como unidades indivisibles, persistiéndolas como estructuras representadas en formato XML, que puede ser interpretada por la aplicación para reconstruir la estructura de datos original. 82 de 105

84 6.7.2 Lecturas de Agentes Las lecturas registradas en el sistema representan el conjunto de datos más grande del sistema. Debido a que las lecturas deben almacenarse a modo de historial, el conjunto total de datos crece rápidamente, y no puede ser limitado de manera arbitraria por el sistema debido a que existe la posibilidad de que se requiera un historial de gran tamaño por políticas de operación, requerimientos de auditoría, o como fuente de datos para la ejecución de pruebas o revisión detallada del estado del CPD en el tiempo. Más aún, las lecturas al conformarse por estructuras de datos arbitrarias definidas por los componentes de entrada deberán almacenarse en un formato que permita flexibilidad en su estructura. Para evitar el crecimiento ilimitado de este conjunto de datos el sistema provee un componente de configuración para mantener los repositorios de datos, a través del cual podrá especificar con qué criterio se deberán seleccionar los registros a eliminar Respuestas de Componentes de Extensión Funcional Las respuestas de Componentes de Extensión Funcional presentan grandes similitudes con las lecturas de los agentes, con la excepción de que estas respuestas no forman parte del funcionamiento principal del sistema, sino un mero registro de los valores obtenidos durante su ejecución para futuros análisis. Más allá de la relevancia de estos registros respecto al funcionamiento principal del sistema, estos registros presentan las mismas características relativas a la estructura de datos que los componen. Más aún, sufriendo el mismo problema de crecimiento ilimitado que las lecturas de los agentes, estos registros deberán ser purgados según el mismo criterio de selección utilizado para la purga de historiales de lecturas de agentes. Esto se debe principalmente a que ambos elementos componen un historial de cómo se desempeñó internamente el sistema, brindando la posibilidad de recrear su evolución haciendo uso de sus datos históricos Definición de componentes del sistema Todos los componentes que intervienen en el ciclo principal de funcionamiento del sistema son parametrizables, por lo que dicha parametrización debe ser mantenida en un repositorio de datos. Estos elementos presentan una naturaleza relacional, ya que representan el estado de configuración de las entidades que componen al modelo de la aplicación. Sin embargo, al igual que las lecturas, existen parámetros representados como estructuras arbitrarias de datos definidas por el usuario. Dado que la parametrización del sistema sólo sufre grandes cambios al inicio de su ciclo de funcionamiento (etapa de inicialización y pruebas) ésta no requiere control adicional para limitar su crecimiento. 83 de 105

85 6.7.5 Registros de Sistema Similar a las lecturas de agentes, los componentes de sistema deben mantener un historial de registros. La principal diferencia con las lecturas es que en este caso el administrador define qué se deberá registrar, por lo que en primera instancia ya existe cierto control respecto al volumen de datos que se mantendrá. Sin embargo, sin importar la configuración de registro (excepto en el caso en que se desactive) el volumen de datos tiende a crecer constantemente, por lo que también se encuentra disponible la posibilidad de configurar el componente de mantenimiento de repositorios de datos para que limite el tamaño del historial mantenido. 84 de 105

86 7 Herramientas complementarias 7.1 Context Replay Por medio de las interfaces de visualización definidas por el usuario, uno puede obtener distintos puntos de vistas del estado del CPD agrupado según el criterio con el cual se ha desarrollado dicha vista. Sin embargo las interfaces de visualización sirven al propósito de representar el estado del sistema en tiempo real, sin la posibilidad de ver estados anteriores mantenidos en los registros históricos de lecturas. En caso de que ocurriese algún evento adverso puede resultar de utilidad tener acceso a la información almacenada en el Registro del Sistema para poder diagnosticar el problema, pero el formato con el que se mantienen esos registros no tiene como prioridad principal su legibilidad (a excepción de algunos registros de logs). Para cubrir esta necesidad se define la herramienta de Context Replay que permite observar el estado de cualquier interfaz de visualización en el tiempo. Dado que esta herramienta depende fuertemente del registro de lecturas del sistema, es de suma importancia que en el módulo de mantenimiento de repositorios de datos se haya establecido mantener un historial de lecturas lo suficientemente extenso como para poder realizar un análisis de cualquier situación que se pueda presentar. Más aún, las vistas pueden depender de Componentes de Extensión Funcional que no hayan sido configurados para que mantengan un historial de las respuestas obtenidas conforme se hayan solicitado durante la ejecución. Es por ello que se pueden presentar inconsistencias en la información visualizada si existen componentes sin historial cuya respuesta sea sensible al momento en que se lo invocó. El núcleo de esta herramienta se encuentra sobre el módulo de Motor de Vistas, el cual se encarga de la administración de las interfaces de visualización. El módulo de Motor de Vistas se alimenta de los módulos Agent State Manager, que le provee los estados actuales e históricos de todos los agentes, y Componentes de Extensión Funcional que ofrecen funcionalidad adicional para realizar cálculos u obtener información complementaria que no se encuentre administrada por el sistema. Para poder incorporar la capacidad de observar el estado de las interfaces de visualización en cualquier momento dado en el tiempo, es necesario que el Context Replay intervenga con sus propios módulos: Agent State Manager: Encargado de proveer el estado histórico y actual de los agentes, este módulo deberá incorporar la capacidad de obtener dicho estado actual e histórico para un punto determinado en el tiempo. Si bien esta funcionalidad ya se encuentra incorporada en el módulo, en este contexto la temporalidad de los datos será determinada por el usuario, y 85 de 105

87 se tomará como punto de referencia para excluir cualquier estado posterior de cualquier Agente. Debido a que los registros históricos se encuentran limitados por el módulo de mantenimiento de repositorios de datos, el módulo incluye la capacidad de detectar si el punto en el tiempo solicitado excede al historial mantenido. Se notificará al usuario con una alerta en caso de que los historiales de estados de algún Agente se encuentren truncados, o se registrará un error severo en caso de que no se pueda recuperar datos de alguno de los Agentes involucrados en la interfaz. Componentes de Extensión Funcional: Al igual que el módulo de Agent State Manager este módulo mantiene un historial de datos obtenidos por la vista y las reglas, pero presenta dos diferencias importantes. Primero, el módulo de Componentes de Extensión Funcional no maneja el concepto de temporalidad de los datos, ya que dicha propiedad se incorpora exclusivamente para mantener registro de la respuesta obtenida. Por otra parte, el registro histórico de respuestas de componentes no se define como una propiedad común a todos los componentes, sino que es configurado por el usuario bajo el criterio de selección que éste considere adecuado (para un correcto funcionamiento es necesario que mantenga el historial de todos los componentes que sean sensibles al estado del contexto o el tiempo). Teniendo en cuenta estas diferencias, el módulo de Componentes de Extensión Funcional incorporará, junto con la administración de los Componentes de Extensión Funcional, la administración de los registros históricos de dichos componentes. Para incorporar esta funcionalidad, la herramienta de Context Replay define un módulo que se interpone entre la vista y los módulos previamente mencionados, mediando todas las comunicaciones entre ellos. Al intervenir entre todas las comunicaciones el módulo puede solicitar información de manera más específica según el punto en el tiempo que el usuario desee visualizar. A su vez permite extender el funcionamiento del módulo de Componentes de Extensión Funcional para poder trabajar con los registros históricos de los componentes 86 de 105

88 cuando éstos se encuentren presentes. Por último, estando el módulo administrado por medio de una interfaz gráfica con la cual el usuario selecciona qué punto en el tiempo desea analizar, la herramienta ofrece la funcionalidad suficiente para analizar el estado de cualquier interfaz de visualización para cualquier momento dado. 7.2 Kit de Desarrollo Plugins, Reglas y Componentes - SDK Elementos de desarrollo Dada la naturaleza extensible y modular del sistema, complementada por la premisa de plataforma abierta, es necesario proveer a quien lo desee con un paquete que contenga el conjunto de componentes necesarios para realizar el desarrollo de Componentes de Extensión Funcional, plugins de entrada o salida, o reemplazos totales de un módulo. Dicho paquete permite garantizar una fácil integración de los módulos y componentes al sistema, sin la necesidad de alterar el mismo. Todos estos elementos deben ser provistos en contenedores cerrados, que permitan su uso pero no su modificación, no como medio de protección, sino para evitar que cualquier error por parte del desarrollador que altere estos elementos genere inconsistencias para su integración, ocasionando comportamientos inesperados. Los principales elementos que componen a este paquete son: Interfaces o Contratos Funcionales: Son las interfaces que deben respetar los distintos Componentes de Extensión Funcional o plugins de entrada o salida, según a que módulo pertenezcan. Son estos Contratos Funcionales los que permiten simplificar el proceso de integración, unificando el modo de interactuar de todos los componentes de cada módulo. A su vez, como el sistema provee un diseño modular, existe la posibilidad de reemplazar módulos enteros por unos de desarrollo propio. Para ello se proveen también las interfaces de todos los módulos del sistema, con los cuales el mismo deberá interactuar o implementar según el módulo a reemplazar. Objetos de intercambio: Las interfaces sólo permiten definir qué comportamiento deberá satisfacer el módulo o componente, pero no permiten definir los elementos que se intercambian entre los distintos componentes del sistema, que en su interior transportan la información necesaria para su funcionamiento. Tanto para el desarrollo de Componentes de Extensión Funcional, como de módulos de sistema es mandatorio que respeten los objetos definidos y sus interfaces. En el desarrollo de Componentes de Extensión Funcional es imposible introducir nuevas propiedades al objeto de intercambio, ya que el sistema no se encuentra diseñado para que tenga en cuenta dichas propiedades. A su vez no es recomendable cambiar la forma en que el objeto mantiene internamente la información (respetando el comportamiento expuesto) ya que éstos se encuentran optimizados para una 87 de 105

89 eficiente serialización y comunicación. Sin embargo, en caso de que se modifique un módulo y elementos relacionados, es posible extender las propiedades de los objetos, pero deberán detectarse por métodos alternativos ya que su Contrato Funcional (que no puede ser modificado) expone que deberá utilizar el objeto de intercambio original para el intercambio de información Herramientas de prueba Disponiendo de estos elementos de desarrollo, un desarrollador se encuentra en condiciones de implementar tanto un componente de extensión funcional así como también un módulo del sistema. Sin embargo, como cualquier desarrollo, éste debe ser debidamente probado previo a su publicación en el entorno de producción. Teniendo en cuenta que el propio sistema se encuentra diseñado para mantenerse en funcionamiento incluso durante la instalación o remoción de Componentes de Extensión Funcional, resulta incongruente que cualquier elemento desarrollado, tanto un componente de extensión funcional, un módulo, o incluso una regla sean expuestos al entorno de producción para realizar pruebas de su funcionamiento, con alta probabilidad de que se presenten comportamientos inesperados. Es por ello que el SDK debe contar a su vez con una serie de herramientas que complementen el desarrollo de estos elementos brindando un entorno seguro sobre el cual realizar pruebas, e incluso poder analizar el comportamiento de estos elementos para realizar los ajustes necesarios que sean relativos a características de rendimiento o eficiencia: Entorno de prueba de reglas: Siendo las reglas el punto central de programación del usuario sobre el sistema es necesario que éstas sean sometidas a una serie de pruebas para asegurar su correcto funcionamiento. El entorno de pruebas deberá presentar todos los componentes y salidas necesarios para el funcionamiento de la regla, mientras que las entradas podrán ser emuladas por medio de creación de nuevas lecturas tanto por el usuario como también de forma automática por el sistema. Para prevenir falsas alarmas todas las salidas deberán ser ficticias, constando únicamente de un registro de los parámetros obtenidos cada vez que se realizó una invocación a éstas, mientras que los Componentes de Extensión Funcional pueden ser tanto reales como ficticios dependiendo de qué acciones toma su lógica interna. En caso de que los Componentes de Extensión Funcional sean ficticios, será necesario que el usuario configure qué valores devolverá (posiblemente utilizando lógica simplificada que describa el comportamiento del componente real en una situación determinada). 88 de 105

90 Entorno de prueba de Componentes de Extensión Funcional, plugins de entrada y de salida: Estos elementos representan los principales elementos de comunicación entre el sistema y su entorno y, a diferencia de las reglas, requieren un diseño y proceso de desarrollo más sofisticado y completo. A su vez, al integrarse en el sistema a un nivel más bajo, es crítico que las pruebas a las cuales se somete este módulo sean más meticulosas, con el objetivo de transferir el elemento al entorno de producción con el mínimo factor de inestabilidad posible. Si bien el sistema se encuentra preparado para manejar errores e inconsistencias de estos elementos, éstos igualmente implican problemas de ejecución en el mismo, pudiendo darse situaciones en las cuales todos los elementos que dependan del componente problemático pierdan sincronía con el estado registrado en el sistema. Dichos problemas pueden generar inconsistencias de datos e incluso provisión de información errónea a quienes dependen del sistema para conocer el estado de funcionamiento del CPD. Entorno de prueba de módulos de sistema: Los módulos de sistema, al igual que los Componentes de Extensión Funcional, entradas y salidas, se integran al sistema a un nivel más bajo, por lo que requieren pruebas meticulosas de funcionamiento para asegurar su corrección. Sin embargo estos elementos se diferencian en el hecho de que cualquier problema en su funcionamiento afecta a todo el sistema por completo, pudiendo ocasionar una falla de sistema no esperada. A su vez, los módulos deben integrarse con muchos más elementos del sistema para poder ejecutar sus funciones, y siendo parte central del mismo deben considerarse como críticas ciertas pautas de diseño tales como escalabilidad o resiliencia a errores internos del módulo. Para ello, aparte de las pruebas previamente mencionadas, se deberán realizar pruebas de integración con los otros módulos, pruebas de rendimiento y de capacidad de escalabilidad (pruebas de carga). Capacidad de configurar Mocks y Unit Tests para realizar pruebas automatizadas: Integrándose con los entornos de prueba previamente mencionados esta herramienta permite predefinir conjuntos de pruebas que pueden ser aplicadas a distintos componentes. Esta característica es ideal para realizar pruebas de compatibilidad entre dos elementos, en donde un elemento reemplaza al otro, por lo que debe cumplir perfectamente con el comportamiento del elemento original. A su vez permite integrar dentro de las herramientas de prueba al Context Replay, permitiendo tomar datos reales ordenados temporalmente para simular la ejecución del elemento en el ambiente de producción. Por último, esta herramienta permite definir dentro de las pruebas, condiciones de éxito que se deben alcanzar al final de la prueba para considerarla como aprobada. 89 de 105

91 8 Comparativa con soluciones existentes El sistema de monitoreo de código abierto Nagios presenta una solución con cualidades muy similares al sistema propuesto, contemplando además características de administración de los elementos controlados. Esta solución se considera como una de las más completas y versátiles que existe en el mercado de monitoreo y control de infraestructura y sistemas, motivo por el cual se la eligió como representante de dicho área para realizar un breve análisis comparativo respecto a las prestaciones que tiene con respecto al sistema propuesto en este trabajo: 8.1 Elementos monitoreables: Nagios, en su concepción, inició como un sistema de monitoreo de infraestructura, excluyendo en gran parte la posibilidad de monitorear el estado de un sistema sin la necesidad de incurrir en una adaptación considerable del sistema. Hoy en día, si bien el sistema evolucionó en el tiempo agregando gradualmente esta capacidad, su forma de funcionamiento continúa siendo parcialmente orientada al monitoreo de infraestructura (principalmente se observa en las formas de integración de dichos sistemas al sistema de monitoreo). Respecto al enfoque inicial, el sistema propuesto posee una definición más libre sobre qué elementos monitoreables puede éste integrar. Esta libertad de definición permite no sólo integrar tanto mecanismos de monitoreo de infraestructura como sistemas varios de forma homogénea, sino que además permite integrar cualquier elemento para el cual se pueda desarrollar un plugin para su integración. 8.2 Extensibilidad e Integración: Nagios presenta una estructura extensible que, al igual que el sistema propuesto, se encuentra basada en un esquema de plugins de integración. Sin embargo este esquema es fundamentalmente distinto en el mecanismo subyacente de integración utilizado. Los plugins de Nagios existen como programas externos a Nagios, los cuales son parametrizados en su ejecución por el sistema. Esto implica que si bien el plugin no se encuentra necesariamente ligado únicamente a Nagios, el mecanismo de integración que poseen es más limitado. El mecanismo de integración presentado por el sistema propuesto presenta un balance de cualidades opuesto al definido por Nagios. Todos los plugins presentan una interfaz definida, la cual es utilizada directamente por el núcleo del sistema, sin pasos de integración 90 de 105

92 intermedios. Esta definición estricta provoca que el plugin no pueda ser reutilizado libremente por otros sistemas, pero existen métodos que permiten solucionar dicho problema de forma sencilla. 8.3 Ejecución distribuida: Nagios, al comprenderse por un sistema stand-alone, no puede aprovechar de forma directa las ventajas provistas por un entorno de ejecución distribuido como el utilizado en el diseño del sistema propuesto. Esto implica que para realizar una instalación distribuida del sistema para brindar redundancia ante fallas que generen el malfuncionamiento de un nodo sea más complejo, incurriendo en más variables de configuración que requieren ser definidas para que el sistema se ejecute apropiadamente. Sin embargo este esquema presenta la ventaja de redurcir los requerimientos de software disponible en los nodos que intervienen, ya que no requiere la presencia del entorno de ejecución utilizado en el diseño del sistema propuesto. 8.4 Modularidad: Si bien tanto Nagios como el diseño propuesto presentan un diseño interno modular, el sistema propuesto presenta la ventaja de que no solo define módulos de procesos que componen distintos aspectos de procesamiento de información del sistema, sino que además admite la posibilidad de reemplazar dichos módulos de forma sencilla a través de la configuración misma del sistema. Acorde con el criterio de Plataforma abierta, al ser conocido el método de integración utilizado y las interfaces de los distintos módulos permite simplificar el proceso de adaptación de los módulos a las necesidades particulares de una organización. 91 de 105

93 9 Evolución a futuro A lo largo de este documento se definieron cuáles eran las prestaciones actuales de los sistemas existentes en el campo de monitoreo junto con cuáles eran sus falencias, acompañadas luego con una serie de definiciones de requerimientos de alto nivel que definen brevemente un sistema que cubre dichas falencias. Por último se realizó un análisis detallado de cómo debería componerse dicho sistema, cubriendo todos los requerimientos previamente definidos. Si bien el diseño demostrado en este documento cubre todos los problemas previamente resaltados, esto no debería limitar la posibilidad de evolución del sistema únicamente dentro de este marco. Dada la naturaleza de los CPDs de hoy en día y sus tendencias evolutivas, los puntos de mejora que se destacan son: Integración entre distintos CPD: Como se mencionó previamente, el diseño de este documento se limita a la implementación de un sistema de monitoreo para un único CPD, sin soporte directo para la integración de distintas instalaciones en distintas localizaciones. Hoy en día no es inusual operar sistemas que se encuentran en ejecución en distintos CPDs de forma simultánea, integrados y operando como un único proceso capaz de enfrentar siniestros en una de sus instalaciones con una pérdida de información mínima. Este tipo de operaciones se encuentran en constante crecimiento, albergando sistemas críticos de grandes empresas internacionales, entre otras. Dado que el sistema se ejecuta de forma distribuida, resulta conveniente tener la capacidad de monitorear los distintos sitios de forma integrada, permitiendo detectar problemas que exceden a un único CPD, como pueden ser problemas de comunicación entre estos. Sin embargo, la administración centralizada implica un costo de operación elevado dada la complejidad de la definición del modelo de operación del sistema, además de ser arriesgado, dado que al encontrarse centralizado, cualquier problema que surja sobre la única instancia del sistema afecta a todos los CPDs en operación. Debido a esto se define que uno de los puntos de evolución a futuro que debe contemplar el sistema es la posibilidad de integrar elementos entre distintas instancias del sistema de monitoreo, de forma sencilla y efectiva, permitiendo minimizar el nivel de acoplamiento entre los distintos sistemas al mínimo, maximizando al mismo tiempo el grado de control y visibilidad que poseen los administradores de los CPDs sobre recursos externos a estos. 92 de 105

94 Mejoras de interfaz para la definición de reglas: Si bien el sistema presenta una interfaz sencilla para poder realizar la configuración de reglas sin presentar limitaciones en cuanto a su potencial flexibilidad, su uso implica cierto conocimiento técnico para definir la lógica de una regla. Estos conocimientos técnicos (conocimientos de lógica y código Javascript) si bien son básicos, imponen una restricción para quien puede o no realizar la configuración del sistema. Para poder minimizar esta restricción se propone como posibilidad de mejora una interfaz de configuración de reglas alternativa, capaz de brindar un entorno gráfico sencillo y flexible, ya sea en forma de diagramas de flujo y transformación de información, que remueva la necesidad de conocer cómo armar un algoritmo en Javascript para realizar una tarea, así como también la posibilidad de utilizar distintos lenguajes para completar la tarea. El conocimiento requerido de lógica se mantiene, ya que ya sea en forma de código o en forma de un diagrama visual de flujo de información el usuario debe componer una estructura lógica, un algoritmo que permita transformar datos de entrada en alertas o notificaciones de algún tipo. 93 de 105

95 10 Conclusiones Registro de eventos, análisis y Ingeniería Informática Calligaro, Daniel Victor Los distintos CPDs operativos en la actualidad varían considerablemente tanto en la infraestructura de servicios que éstos poseen para operar, como así también en la infraestructura de sistemas utilizados para controlar y operar los equipos que brindan dichos servicios. Esta variedad de escenarios o entornos de producción imposibilita el desarrollo de un único sistema cerrado que satisfaga cualquier escenario posible, sin la necesidad de realizar grandes modificaciones para adaptarlo a dicho entorno. Gracias a las características de extensibilidad y diseño abierto definidas en el sistema propuesto, éste puede adaptarse fácilmente a distintos entornos productivos, requiriendo solo del desarrollo de plugins para su adaptación, minimizando la necesidad de realizar modificaciones al núcleo del sistema y, por ende, el riesgo de introducir nuevas fallas críticas al sistema. Por otra parte, así como existen entornos productivos distintos, el operador de un CPD puede requerir establecer métodos propios de control y análisis del estado del equipamiento, que pueden no haber sido contemplados en el diseño original del sistema. Haciendo uso de un motor de scripting para la definición de reglas, el sistema propuesto le permite al administrador del sistema volcar cualquier lógica que haya determinado para realizar el control de ciertos agentes, sin la necesidad de modificar el sistema en sí. Sin embargo, esta funcionalidad presenta la desventaja de imponer la necesidad de conocer el lenguaje seleccionado (Javascript) para configurar el sistema. Esto se mitiga permitiendo parametrizar los scripts utilizados, permitiendo copiarlos entre reglas sin la necesidad de modificar el código de la misma. De esta manera, una persona más idónea para la codificación de la lógica puede cargar un conjunto de procesos parametrizados definidos por el administrador, pudiendo luego el administrador generar distintas reglas simplemente cambiando sus parámetros. Por último, un factor muy importante al momento de seleccionar qué solución de monitoreo utilizar en un CPD es el costo de despliegue, migración e integración del sistema seleccionado al entorno productivo. Las cualidades de integración ya se encuentran ampliamente satisfechas por el esquema de plugins del sistema propuesto, pero el despliegue y migración del sistema presenta otros tipos de requerimientos que esta cualidad no cubre. Debido al volumen masivo de elementos que manejan los CPDs, y el costo general de sus operaciones y costo potencial de una pérdida de servicio, resulta imperativo contar con una solución que permita realizar una migración progresiva del sistema, en caso de contar con un sistema anterior, permitiendo realizar pruebas suficientes previas a la puesta en marcha definitiva para asegurar su correcto funcionamiento. El concepto de 94 de 105

96 plataforma abierta permite facilitar este tipo de tareas, permitiéndole a un desarrollador interactuar con el sistema a bajo nivel, posibilitando el desarrollo de middleware que permita la migración de datos o la interacción entre módulos, tareas que en una situación normal requeriría realizar modificaciones sobre el núcleo del sistema. Más aún, esta característica facilita las tareas de expansión funcional del sistema, ya sea por una actualización o por un desarrollo adicional que se integra al esquema propuesto, o incluso su integración con futuros sistemas que presenten mejores características en ciertos aspectos, manteniendo al sistema original para todas las operaciones de backend. 95 de 105

97 11 Bibliografía Registro de eventos, análisis y Ingeniería Informática Calligaro, Daniel Victor Alur, Deepak. Core J2EE patterns best practices and design strategies. 2nd ed. New Jersey, Estados Unidos: Prentice Hall, ISBN Fowler, Martin. Patterns of enterprise application architecture. 1st ed. Boston, Estados Unidos: Addison-Wesley, ISBN Schmidt, Klaus. High Availability and Disaster Recovery: Concepts, Design, Implementation. 1st ed. Frankfurt, Alemania: Springer-Verlag, ISBN Lea, Doug. The java.util.concurrent Synchronizer Framework [en linea]. 1st ed. Nueva York, Estados Unidos: State University of New York, < [Consulta: Marzo 2011]. Sun Microsystems, Inc. JSR Enterprise JavaBeansTM 3.1 [en linea]. 1st ed. California, Estados Unidos: Sun Microsystems, Inc., < > [Consulta: Febrero 2011]. ADC Telecommunications, Inc. TIA-942 Data Center Standards Overview [en linea]. Edición Original. Minnesota, Estados Unidos: ADC Telecommunications, Inc., < [Consulta: Noviembre 2011]. Nilsen, Kelvin; Larkham, Adrian. Applying Java Technologies to Mission-Critical and Safety- Critical Development [base de datos en linea]. 1st ed. Southhampton, Inglaterra: Springer- Verlag, < [Consulta: Septiembre 2010]. Knight, John C.; Strunk, Elisabeth A. Achieving Critical System Survivability Through Software Architectures [base de datos en linea]. 1st ed. Virginia, Estados Unidos: Springer- Verlag, < [Consulta: Septiembre 2010]. Uptime Institute, LCC. Data Center Infrastructure Tier Standard: Operational Sustainability [en linea]. 1st ed. Nueva York, Estados Unidos: Uptime Institute Professional Services, < [Consulta: Agosto 2010]. 96 de 105

98 Uptime Institute, LCC. Data Center Infrastructure Tier Standard: Topology [en linea]. 1st ed. New Mexico, Estados Unidos: Uptime Institute Professional Services, < [Consulta: Agosto 2010]. Bernard, Emmanuel. Hibernate Annotations Reference Guide [en linea]. S.I.: Red Hat, Inc., < [Consulta: Abril 2011]. Stansberry, Brian; Zamarreno, Galder; Ferraro, Paul. JBoss AS 5.1 Clustering Guide [en linea]. S.I.: JBoss Community, < [Consulta: Febrero 2011]. JBoss AS6 Documentation [en linea]. S.I.: Red Hat, Inc. < [Consulta: Junio 2011]. Google Web Toolkit: Developer's Guide [en linea]. S.I.: Google. < [Consulta: Febrero 2011]. Google Web Toolkit: Debugging in Hosted Mode [en linea]. S.I.: Google. < [Consulta: Mayo 2011]. Rhino Documentation [en linea]. S.I.: Mozilla.org, < [Consulta: Junio 2011]. JBoss Infinispan: User Guide [en linea]. Muir, Pete. S.I.: JBoss Community. < [Consulta: Febrero 2011]. Introducing distributed execution and MapReduce framework [en linea]. Blagojevic, Vladimir. S.I.: JBoss Comunity, < [Consulta: Febrero 2011]. 97 de 105

99 ANEXO 1: Diagramas del sistema propuesto y prototipo 98 de 105

100 Registro de eventos, análisis y emisión de avisos Ingeniería Informática Calligaro, Daniel Victor de alarmas Composición de módulos Principales Este diagrama se encuentra simplificado para mejorar su legibilidad, dejando de lado ciertas definiciones de métodos que no hacen al funcionamiento principal del módulo, como así también ciertas clases que tiene como único objetivo ser de transporte de datos entre distintos módulos (DTOs). 99 de 105

101 Registro de eventos, análisis y emisión de avisos Ingeniería Informática Calligaro, Daniel Victor de alarmas Composición de módulos de Soporte Este diagrama se encuentra simplificado para mejorar su legibilidad, dejando de lado ciertas definiciones de métodos que no hacen al funcionamiento principal del módulo, como así también ciertas clases que tiene como único objetivo ser de transporte de datos entre distintos módulos (DTOs). 100 de 105