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 Enríquez, German Ezequiel LU Ingeniería Informática Tutor: Godio, Claudio, UADE Agosto 8, 2011 UNIVERSIDAD ARGENTINA DE LA EMPRESA FACULTAD DE INGENIERÍA Y CIENCIAS EXACTAS

2 Resumen 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 101

3 Summary 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 101

4 1 Índice 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 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 Hibernate de 101

5 6.3 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 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 101

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. 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 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. 5 de 101

7 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. 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 101

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 101

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 101

10 Registro de eventos, análisis y Ingeniería Informática Calligaro, Daniel Victor Tier 4: CPDs que califican como Tier 3, pero tienen la capacidad ad 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 ados 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).

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 101

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 101

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 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 12 de 101

14 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 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.3 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: 13 de 101

15 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. 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. 14 de 101

16 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, é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.4 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 15 de 101

17 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 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 16 de 101

18 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 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). 17 de 101

19 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. 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. 18 de 101

20 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: 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 19 de 101

21 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 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. 20 de 101

22 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. 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 21 de 101

23 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 101

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 101