La computación en Nube [1–3] es un nuevo paradigma en el cual convergen tecnologías tanto novedosas, como ya existentes, para ofrecer como un servicio, todas las capacidades de un sistema computacional a diferentes usuarios [2]. A este servicio se puede acceder desde cualquier dispositivo que cuente con acceso a Internet, sin importar su ubicación física.
Este nuevo modelo de computación trae muchos beneficios, planteando a su vez también algunos desafíos, tales como su monitorización. Los entornos Nube, dinámicos y altamente distribuidos, ofrecen múltiples ventajas en su aplicación, pero son intrínsecamente difíciles de monitorizar [4]. La principal dificultad se presenta para desarrolladores y administradores [5], por el nivel de abstracción de la infraestructura: la abstracción/unificación de los recursos se realiza a través de la virtualización [6] y algunos otros niveles de encapsulamiento.
En la actualidad no existen muchas soluciones de código abierto para la monitorización en los entornos Nube. La mayoría de las herramientas y APIs disponibles, utilizadas para la monitorización de recursos, han sido desarrolladas para infraestructuras Grid [7] y Clusters [8]. Aunque estas herramientas, con ciertas modificaciones y configuradas apropiadamente, pueden usarse como punto de partida para la monitorización de la infraestructura en un entorno Nube [9], no todas son capaces de capturar el dinamismo que se observa en
este nuevo tipo de arquitectura distribuida [10]. Por esta razón, es un problema interesante de investigación, el evaluar en forma detallada cuáles herramientas se adaptan mejor a este nuevo modelo computacional. En este sentido, en este artículo se presenta la fase inicial del trabajo de investigación propuesto, que consiste en evaluar diferentes herramientas de monitorización, que por sus características se puedan adoptar en entornos Nube, particularmente Nubes privadas e híbridas. El artículo pretende servir de referencia a los proveedores y administradores de la infraestructura al momento de seleccionar herramientas de monitorización para entornos Nube, que ofrezcan información sobre los recursos y servicios desplegados.
Este artículo se estructura de la siguiente manera: en la Sección II se presentan los conceptos relacionados con la computación en Nube. En la Sección III se exponen definiciones relacionadas con la monitorización en Nube. En la Sección IV se presenta la metodología utilizada para la evaluación de las herramientas y en la Sección V, se describe el proceso de evaluación. En la Sección VI se presentan los trabajos relacionados a la investigación y por último, en la Sección VII se presentan las conclusiones y trabajos futuros.
II. COMPUTACIÓN EN NUBE
A. Definición de Computación en Nube
Una de las definiciones más concisa y ampliamente aceptada, sobre la computación en Nube, proviene del Instituto Nacional de Estándares y Tecnología de los Estados Unidos de América (NIST) [1], [11], cuyos miembros consideran que se trata de un modelo que habilita de forma global y conveniente el acceso, bajo demanda, a una serie de recursos computacionales, configurables y comunes (tales como redes, servidores, dispositivos de almacenamiento, aplicaciones y servicios) que se pueden conformar y proveer rápidamente a los usuarios con un mínimo esfuerzo administrativo o una mínima interacción con el proveedor del servicio. El modelo de la computación en Nube desarrollado por el NIST está compuesto por tres modelos de servicio y cuatro modelos de despliegue.
B. Modelos de Servicio
Software como Servicio (SaaS): en este modelo una aplicación se ofrece como un servicio que proporciona
un proveedor. El proveedor es el encargado del mantenimiento, soporte y administración de la aplicación de la cual dispondrá el usuario durante el tiempo en el que se haya contratado el servicio.
Plataforma como Servicio (PaaS): su principal función es ofrecer una solución completa para la construcción y puesta en marcha de aplicaciones y servicios Web que estarán completamente disponibles a través de Internet.
Infraestructura como Servicio (IaaS): proporciona como un servicio al usuario una infraestructura integral de computación, usando principalmente la virtualización [6], es decir, a través de la asignación de máquinas virtuales bajo demanda. El usuario paga a un proveedor externo para obtener mayor capacidad de almacenamiento y de cómputo. El proveedor es el encargado de realizar el mantenimiento y la administración de la infraestructura.
C. Modelos de Despliegue
Modelo de Nubes Privadas: en este modelo la infraestructura de Nube es operada en forma exclusiva por una organización.
Modelo de Nubes Comunitarias: este modelo tiene una variante que contempla la operación, administración, pertenencia y/o ubicación de la infraestructura de Nube computacional en varias organizaciones que conforman una comunidad de intereses afines.
Modelo de Nubes Públicas: los servicios previstos por la infraestructura de Nube computacional están disponibles al público en general, incluyendo usuarios y organizaciones académicas, científicas o comerciales. El proveedor de los servicios de la Nube generalmente es propietario de los mismos y suele facturar o adquirir ganancias indirectas por su uso externo.
Modelo de Nubes Híbridas: la infraestructura de computación en Nube está compuesta por varios modelos de despliegue: privado, comunitario o público.
III. MONITORIZACIÓN EN COMPUTACIÓN EN NUBE
– DEFINICIÓN DEL PROBLEMA
La monitorización juega un papel significativo cuando se trata de asegurar la calidad de servicio en la computación en Nube [12], ya que provee indicadores que permiten verificar el cumplimiento de los acuerdos (Service Level Agreements, SLAs) [13]. El uso de los monitores facilita también el desarrollo de mecanismos para aumentar la utilización de recursos de manera adaptativa, la detección de problemas en los servicios, la optimización del despliegue de aplicaciones y el descubrimiento de patrones de uso de los numerosos usuarios finales, entre otros.
La monitorización sirve a los usuarios, al igual que a los proveedores de la infraestructura, porque les permite verificar
el funcionamiento de sus propias aplicaciones y/o servicios a través de la revisión del estado de las máquinas virtuales.
Algunos de los retos a superar en el desarrollo de un sistema para la monitorización en los entornos Nube se presentan a continuación:
La abstracción/unificación de los recursos virtualizados: para los desarrolladores y administradores de la Nube, los recursos abstraídos/unificados por la virtualización y algunos otros niveles de encapsulamiento dificultan el seguimiento de los problemas hasta su fuente. Por otro lado, la limitada información suministrada por el proveedor sobre el rendimiento de la infraestructura y de los recursos, puede no tener el nivel de detalle necesario para entender cuál es el estatus actual de los recursos. El problema se agudiza porque los usuarios no tienen la libertad de desplegar su propia infraestructura de monitorización debido a que la Nube les proporciona un API predefinido y les oculta los recursos a bajo nivel, especialmente en los niveles Plataforma como Servicio (PaaS) y Software como Servicio (SaaS).
El consumo de energía: este criterio es de gran importancia actualmente por la introducción de nuevas regulaciones legales en cuanto al impacto ambiental [14]. Se busca mejorar el aprovechamiento de los recursos de hardware, para reducir costos, espacio y energía; sin que exista un perjuicio para el rendimiento de la Nube.
Herramientas de monitorización para entornos específicos: la mayoría de las herramientas de monitorización que se han desarrollado para los entornos Nube han sido creadas específicamente para los principales proveedores de Nubes públicas (Amazon, Google, Microsoft, entre otros). Por lo tanto, en las Nubes privadas, comunitarias o híbridas, los administradores deben, o bien hacer uso de herramientas provenientes de otro tipo de entornos distribuidos (redes, Grids, etc.), o bien desarrollar herramientas propias que se adapten a los nuevos requerimientos. Lamentablemente, muchos de los sistemas de monitorización existentes para sistemas distribuidos, tales como MonaLisa [15] y GridICE [16], se han ocupado de la monitorización de grandes sistemas, pero no han abordado el problema de la infraestructura dinámica y rápidamente cambiante que se observa en las Nubes [10].
Dado que la monitorización juega un rol importante en los entornos Nube, uno de los objetivos de este trabajo es encontrar la herramientas más adecuadas que puedan ser insertadas posteriormente en los componentes de monitorización de los proyectos OPTIMIS [17] y BonFIRE [18]. El principal objetivo de OPTIMIS es el desarrollo de herramientas para soportar el ciclo de vida completo de servicios IT en entornos Nube (desarrollo, despliegue y gestión en tiempo de ejecución), con la finalidad de optimizar al máximo los recursos utilizados. OPTIMIS considera diferentes tipos de escenarios basados tanto en Nubes públicas como
privadas (“cloud bursting”, “multi-cloud” y “cloud federation”). Por otro lado, en el marco de BonFIRE se está desarrollando una plataforma de Nube multi-sitio que soportará trabajos de investigación multidisciplinarios a gran escala. En la próxima Sección se presenta la metodología para evaluar las herramientas.
IV. METODOLOGÍA
La evaluación de las herramientas se llevó a cabo principalmente en dos etapas. La primera etapa consistió en una evaluación inicial de varias herramientas utilizadas en sistemas distribuidos. Las herramientas a seleccionar deberán cumplir ciertos requerimientos básicos que se mencionan en la Sección V y que se establecieron en los proyectos OPTIMIS y BonFIRE. La evaluación se realizó principalmente con base en la revisión de la documentación de las herramientas. La segunda etapa consistió en evaluar con un mayor nivel de detalle las herramientas seleccionadas en la etapa anterior, tomando en consideración, esta vez, los requerimientos de monitorización en entornos Nube establecidos en [9] y [10]. En esta fase no sólo se utilizó la documentación existente, sino que se instalaron las herramientas en un ambiente Nube para probar las principales características exigidas.
Aunque no se presentan resultados en el artículo, es importante mencionar que las herramientas que superen las dos fases de evaluación serán expuestas posteriormente a pruebas más detalladas y rigurosas, donde se incrementen considerablemente los niveles de carga propios de ambientes de Nube.
V. EVALUACIÓN DE LAS HERRAMIENTAS
A. Primera Fase
1) Requerimientos Básicos Exigidos En esta primera etapa se estableció un conjunto de
requerimientos básicos, atendiendo a las exigencias de los proyectos involucrados y a características deseables en cualquier herramienta de monitorización para entornos distribuidos, especialmente para Nubes. Estos requerimientos básicos se enumeran a continuación: (1) ser de código abierto, para poder ser desplegadas en cualquier entorno Nube, es decir, deben ser independientes del proveedor de la infraestructura; (2) permitir la monitorización de ambientes dinámicos y virtuales; (3) tener la capacidad de medir el desempeño de aplicaciones y/o recursos; (4) no limitar el número de dispositivos a monitorizar y continuar correctamente el proceso de monitorización a medida que se van agregando recursos a la Nube; (5) requerir de pocos componentes de hardware para su funcionamiento. Los recursos de hardware deben ser aprovechados en su mayoría para las máquinas virtuales y para la oferta de servicios, no deben ser monopolizados por las herramientas de monitorización.
2) Herramientas que Participan en la Selección Algunas herramientas de monitorización tales como
Monitis [19], Nimsoft [4], Cloudkick [20] y Silverline [21] han sido creadas específicamente para los principales proveedores de Nubes públicas, pudiéndose utilizar sólo para la monitorización de los servicios provistos por dichos
proveedores. Se trata de soluciones comerciales y dependientes de la infraestructura Nube que no cumplen con el primer y segundo requerimiento planteados. Por tales motivos estas herramientas son descartadas del resto del análisis.
Dentro de las opciones para monitorizar entornos distribuidos y redes se encuentran herramientas como Nagios [22], Lattice [23], HypericHQ [24], Zenoss [25], GroundWork [26], Zabbix [27], OpenNMS [28], Ganglia [29], MonaLisa [15] y GridICE [16]; particularmente Lattice, HypericHQ y GroundWork prometen abordar también la monitorización para entornos Nube. Las herramientas MonaLisa [15] y GridICE [16], se orientan hacia la monitorización de grandes sistemas distribuidos, pero no atienden los problemas de infraestructura dinámica presentes en las Nubes, con lo cual no cumplen con el requisito 2; por este motivo estas herramientas tampoco serán tomadas en consideración en el resto del análisis.
A continuación, se describirán brevemente las herramientas restantes. Posteriormente se realizará la selección de herramientas que más se adapten a los criterios mencionados. Las herramientas favorecidas serán de nuevo valoradas en la próxima fase con un mayor nivel de detalle.
En la Tabla I, donde se incrementa el número de herramientas comparadas en [9], se presentan las principales características de las herramientas estudiadas; las características tomadas en cuenta en la primera fase se identifican con (*) y las características que se toman en cuenta en la segunda fase de evaluación se identifican con (**). El resto de las características es información general que puede ser de utilidad para casos particulares.
Una de las herramientas ampliamente utilizada para la monitorización de grandes infraestructuras de TI, es Nagios, un sistema de monitorización, concebido para la supervisión de sistemas distribuidos y redes, que permite a las organizaciones identificar y resolver problemas de infraestructura antes de que afecten a los procesos de negocio críticos. Nagios se basa en el concepto de plugins, utilizando el resultado de la ejecución de cada plugin para determinar el estado de un recurso o servicio (de manera local o remota) y tomar las acciones necesarias.
Por su parte, Lattice es un Framework de monitorización para la supervisión de ambientes físicos y virtuales, redes virtuales y también para la monitorización de servicios en ambientes altamente dinámicos y a gran escala. Lattice proporciona funcionalidades a sus usuarios para agregar servicios de monitorización potentes y flexibles en los sistemas que se desarrollen.
El sistema de monitorización HypericHQ permite a las organizaciones contar con un monitor de la infraestructura de TI, así como también de los servicios de Nube. HypericHQ puede descubrir automáticamente, monitorizar y administrar servicios de software sin tener en cuenta el tipo de servicio o su ubicación, permitiendo a las organizaciones obtener fácilmente una vista unificada del desempeño y del estado de sus aplicaciones.
Zenoss permite medir el desempeño de diferentes tipos de dispositivos y administrarlos remotamente, ofreciendo una solución integrada para monitorizar toda la infraestructura (redes, servidores y aplicaciones) a través de una interfaz Web.
Con Zenoss se puede revisar periódicamente la disponibilidad de los servicios, el inventario de hardware y software, la configuración del sistema y su rendimiento, así como otros eventos de interés.
Por su parte, GroundWork es una aplicación para monitorizar redes, aplicaciones y Nubes en tiempo real. Fue diseñada para organizaciones cuya infraestructura posea aplicaciones, sistemas operativos y entornos de hardware heterogéneos. Presenta la información de monitorización a través de herramientas gráficas de visualización.
Zabbix es un programa que monitoriza el valor de numerosos parámetros de red, así como el estado y la integridad de los servidores. Zabbix usa un mecanismo de notificación flexible que permite a los usuarios configurar alertas, prácticamente para cualquier evento, a través de correos electrónicos. Esto permite una rápida reacción para solventar problemas en los servidores. Zabbix ofrece interesantes reportes y facilidades para visualizar la información de monitorización almacenada.
OpenNMS es una plataforma para la monitorización y administración de redes. Una instancia de OpenNMS puede observar un gran número de nodos de un servidor, realizando pocas configuraciones. OpenNMS es escalable y extensible, a través de la creación de plugins.
Por último, Ganglia es un sistema de monitoreo escalable y distribuido orientado a sistemas de alto desempeño como Clusters y Grids. Está basado en un diseño jerárquico de federación de Clusters. Ganglia permite a los usuarios medir en tiempo real la utilización de los recursos de todas las máquinas pertenecientes al sistema en observación.
3) Selección De la Tabla I, la primera herramienta en ser descartada es
Ganglia, debido a que no presenta soporte para monitorización en ambientes virtuales, una característica indispensable para los entornos Nube. Además monitoriza sólo recursos físicos, por lo cual no cumple con los requerimientos 2 y 3.
OpenNMS también se descarta porque se enfoca principalmente en la monitorización de red y no presenta funcionalidades para la monitorización de servidores y/o aplicaciones, por lo cual no cumple con el requerimiento número 3.
Otra de las herramientas que podría ser considerada es GroundWork, pero no cumple con el requerimiento 4 ya que sólo soporta en su versión libre la monitorización de 50 dispositivos. Si en el entorno a evaluar el número de dispositivos es superior al mencionado, GroundWork, no podrá ser desplegada en su versión libre, teniéndose que optar por la versión Empresarial (versión comercial), que soporta mayor número de dispositivos; al usar la versión comercial no se cumple con el requerimiento número 1.
Zabbix, presenta características similares a HypericHQ y Nagios. Una de las desventajas que se puede apreciar en los diferentes foros sobre la implementación de la herramienta es que su desempeño es pobre. Este tipo de problema se puede solucionar ([30], [31]) instalando cada uno de los componentes
que constituyen el núcleo de la herramienta en diferentes equipos con ciertas características, a saber:
Intel Dual Core 6400 4GB como mínimo.
2 GB de RAM para el servidor Zabbix, 4 GB para la GUI Zabbix y 16 GB para la base de datos con almacenamiento rápido (RAID10 MySQL InnoDB o PostgreSQL).
Esto representa un considerable costo computacional, no requerido por las otras herramientas, por lo cual se cumple en menor medida con el requerimiento 5. Finalmente, se descarta Zabbix dado que posee funciones similares a HypericHQ y Nagios (Ver Tabla I), teniendo éstas menos requerimientos computacionales. En resumen, las herramientas Nagios, Lattice, HypericHQ y Zenoss son las que lucen más adecuadas para la monitorización en entornos Nube, ya que cumplen con los requerimientos establecidos en esta primera etapa de evaluación.
B. Segunda Fase
La evaluación en esta segunda fase parte de requisitos más concretos, que toda herramienta de monitorización para entornos Nube debe cumplir según [10], así como de exigencias particulares para los niveles de Plataforma (PaaS) e Infraestructura (IaaS) [9].
1) Requerimientos Exigidos Como lo definen en [10], las principales características que
deben tomarse en cuenta para la monitorización en entornos Nube son:
Escalabilidad: asegurar que el monitor pueda soportar un gran número de sensores (probes).
Elasticidad: para monitorizar correctamente los recursos virtuales creados y destruidos por redes que se expanden y contraen.
Migración: de tal manera que cualquier recurso virtual que se mueve de un Host físico a otro, sea monitorizado correctamente.
Adaptabilidad: para que el sistema de monitorización pueda adaptarse a cargas variables de cómputo y de red sin ser invasivo.
Autonomía: para que el sistema de monitorización pueda seguir ejecutándose, una vez iniciado, sin intervención ni reconfiguración.
Federación (descentralización): para que cualquier recurso virtual que reside en otro dominio sea monitorizado correctamente.
De acuerdo con [9] existe una serie de requisitos concretos para cada uno de los niveles de servicio, SaaS, PaaS e IaaS, en este caso en particular se analizarán sólo los niveles IaaS y PaaS debido a que el enfoque de este trabajo de investigación es desde el punto de vista de los proveedores de infraestructura. Estos requerimientos, según el nivel de abstracción considerado, son:
TABLA I. COMPARACIÓN DE HERRAMIENTAS DE CÓDIGO ABIERTO
Autodescubrimiento No No Si Si Si Si Si En cluster
Evaluación / Alerta /
Notificación
Alertas Si No Si Si Si Si Si No
Alertas de recuperación /
acciones correctivas
Si No No Si Si Si Si No
Visualización(**)
Diagramas y gráficos Si No Si Si Si Si Si Si
Tablero personalizable Si No Si Si Si Si Si No
Servicio de Soporte
Documentación Si Poca Si Si Poca Si Poca Si
Foro Si No Si Si Si Si No Si
IaaS: Monitorización de la infraestructura física y virtual. En este nivel los dos aspectos de importancia son: utilizar los recursos físicos de la manera más eficiente posible y asegurar que la QoS acordada con el cliente con respecto al ambiente virtual se cumpla. Los requerimientos pertinentes a tales aspectos que fueron evaluados en este trabajo son:
Soportar varios tipos de recursos: el mecanismo de monitorización de la infraestructura debe ser capaz de obtener métricas de desempeño de diferentes tipos de recursos, tales como la información referente al almacenamiento, la utilización de red, la velocidad de CPU y la temperatura ambiental. Adicionalmente, no se debe perder de vista el estado de la infraestructura virtual: hipervisor, número de máquinas virtuales ejecutándose, redes virtuales desplegadas, asociación (mapping) entre la infraestructura física y virtual.
Minimizar el impacto en los recursos: cuando se realiza un modelo de negocio como IaaS, todo proveedor de Nube desea maximizar la capacidad de su
infraestructura y eventualmente usar la menor cantidad de recursos posible para el mecanismo de monitorización interno. En este contexto, la monitorización debe ser ligera y eficiente sin agregar una sobrecarga notable. Lo relacionado a cantidad de hardware necesitado para el funcionamiento de la herramienta se evaluó en la etapa I; en esta etapa se medirá el overhead.
Solución escalable y configurable: el mecanismo de monitorización de la infraestructura Nube debe ser dinámico y configurable. Debe ser fácilmente extensible para agregar más recursos y horizontalmente escalable [32], cuando se requiera agregar nuevos nodos. Finalmente, la información de monitorización debe ser proporcionada automáticamente por los recursos al iniciarse el monitor.
PaaS: Recolección de datos y administración en el nivel de plataforma. En cuanto al nivel de plataforma del modelo de servicio de la computación en Nube, el monitor tiene por
objetivo, recoger y resumir toda la información que viene del nivel de infraestructura, así como de las aplicaciones y proporcionar dicha información a algún consumidor (usuario final o administrador) a través de diferentes interfaces (API de programación, GUIs Web, reportes, etc.). Por otro lado, es importante que el tipo de dato recolectado sea óptimamente utilizable a efectos de la evaluación del acuerdo de servicio (SLA) realizado. Los requerimientos más importantes conducentes a estas características son:
La información proveniente del nivel de infraestructura de la Nube debe ser re-enviada al consumidor de la plataforma.
El usuario debe ser capaz de procesar esta información, compararla con datos históricos y combinarla con datos de monitoreo provenientes de su propia aplicación. Por tanto, es deseable que el sistema ofrezca ciertas facilidades para el usuario de este nivel, tales como interfaces de flujo (stream interfaces) que permitan la monitorización en tiempo real, estadísticas extraídas de datos históricos, interfaces gráficas (GUIs) para la visualización y gráficos que permitan la comparación de datos en tiempo de ejecución e históricos, etc.
2) Plataforma de Experimentación A fin de verificar la presencia de algunos de los
requerimientos exigidos en las distintas herramientas, se instalaron en un ambiente Nube de prueba (Fig. 1) descrito a continuación:
Se utilizaron tres computadores con las siguientes características: (1) Wagadugu un Intel(R) Pentium(R) Dual CPU T2330, procesador 1.60GHz, 992,5 MB de RAM, disco duro de 120GB, tarjeta de red Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+. En este servidor se tiene instalado Ubuntu 11.10 (oneiric) núcleo Linux 2.0.0-17-generic. (2) Máquina Física 1 una Intel(R) Core (TM) i3 M 330, procesador de 2.13GHz, 4 GB de RAM, disco duro de 500GB, tarjeta de red Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E. En esta máquina se tiene como sistema operativo Debian wheezy/sid núcleo 3.2.0-2-686-pae. (3) Máquina Física 2 una Intel(R) Pentium(R) D CPU 3.00GHz, 2 GB de RAM, disco duro de 160GB, tarjeta de red Broadcom Corporation BCM4401-B0 100Base-TX. En la Máquina Física 2 se tiene Debian wheezy/sid núcleo 2.6.32-5-xen-686 como sistema operativo. En la Máquina Física 1 se iniciaron además cuatro máquinas virtuales (test01, …, test04
1. Cada máquina virtual (testi), es una Intel(R) Core (TM) i3 M 330, procesador de 2.13GHz, 64 MB de RAM, disco duro de 2GB; las máquinas virtuales ejecutan Debian 6.0.4 núcleo 2.6.32-5-xen-686. Las cuatro herramientas evaluadas presentan una arquitectura cliente/servidor. Por tal motivo, en las diferentes máquinas virtuales se instaló el cliente de cada herramienta (en test01 se instaló HypericHQ, en test02 Zenoss, en test03 Nagios y en test04 Lattice) y en Wagadugu los respectivos servidores. Cada herramienta se activó de manera independiente. Para ejecutar las instancias de las máquinas virtuales se utilizó el hipervisor Xen [33], en las Máquinas Físicas 1 y 2. La versión de Xen instalada es 4.1.2-2.
Figura 1. Escenario base para prueba de las herramientas.
Con respecto a las herramientas de monitorización se instalaron las siguientes versiones: el núcleo de Nagios 3.2.3 y para el cliente el complemento Nagios Remote Plugin Executor (NRPE) versión 2.12 y la versión 1.4.15 de los plugins 1.4.15. La versión de Lattice es 0.6.7. La versión de HypericHQ es 4.5.1 y Zenoss versión 3.2.1.
3) Evaluación Según los Requerimientos Exigidos Escalabilidad: como resultado del análisis realizado en la
primera etapa de la metodología planteada en relación con la escalabilidad, las herramientas han sido desplegadas para la monitorización de grandes infraestructuras de TI, lo que garantiza que soportan un gran número de sensores para la recolección y administración de la información de monitorización ([23–25], [34]).
Elasticidad: en cuanto a la elasticidad, se activaron los clientes de cada una de las herramientas al crear la respectiva máquina virtual. Se observó que la información recibida y mostrada en el servidor correspondía únicamente a los clientes activos. Una vez destruidas las máquinas virtuales los respectivos clientes quedaban inaccesibles.
Migración y federación: otra de las pruebas que se realizó fue migrar las máquinas virtuales de Host físico y seguir ejecutando los respectivos sensores. Estas pruebas no se pudieron realizar en máquinas ubicadas en diferentes organizaciones, por tal motivo se realizó sólo el cambio de dominio virtual, haciendo uso de las funcionalidades que tiene Xen para la migración de las máquinas virtuales y configurando parámetros como: configuración de red, imagen de sistema operativo ejecutado, dominio, etc. Las cuatro máquinas virtuales, con los respectivos clientes instalados, fueron migradas de la Máquina Física 1 a la Máquina Física 2 1). A dicha prueba las cuatro herramientas seguían monitoreando correctamente, por lo tanto cumplieron con la característica de migración y federación.
Adaptabilidad: al ejecutar las herramientas en cada una de las máquinas virtuales creadas se supervisó su comportamiento con el comando top de UNIX y no se observó ningún aumento significativo en el consumo de recursos en el servidor donde se estaba ejecutando cada herramienta. Esto nos hace suponer que aumentar el número de máquinas virtuales con la herramienta respectiva no representaría una sobrecarga considerable en el
desempeño de la Nube, por tal motivo las herramientas cumplieron esta característica.
Autonomía: una vez instaladas y configurados los respectivos servicios, las herramientas se ejecutaron sin necesidad de intervención ni reconfiguración; sólo se le prestó atención a la agregación/eliminación de los clientes que se necesitaron activar. Por lo tanto las cuatro herramientas cumplen con la característica de autonomía.
Luego de haber verificado que las herramientas satisfacen los principales requerimientos de monitorización para ambientes Nube según [10], se evaluó si las herramientas satisfacen los requerimientos específicos exigidos para los niveles IaaS y PaaS.
a) Nivel IaaS
SOPORTE DE VARIOS TIPOS DE RECURSOS
Las herramientas que ofrecieron mayor libertad para la recuperación de métricas de desempeño de los respectivos Hosts fueron Lattice y Nagios, ya que se pueden crear diferentes tipos de sensores/plugins de acuerdo con lo que se necesite monitorizar. Nagios cuenta con una comunidad activa de programadores, la cual ha desarrollado una gran cantidad de plugins que pueden ser incorporados fácilmente al núcleo de monitorización.
HypericHQ permite definir una gran cantidad de parámetros de monitorización para todo el ambiente. Los parámetros se agrupan en tres grandes categorías: tipo de plataforma, tipo de servicios por plataforma y tipo de servidores.
Según la documentación HypericHQ, Nagios y Lattice prometen soporte para monitorizar recursos virtuales; máquinas virtuales en ejecución e información del hipervisor, no obstante, en la práctica HypericHQ no reconoció, en el proceso de autodescubrimiento, el hipervisor Xen instalado en la Máquina Física 1.
Zenoss recoge información a través del protocolo SNMP (Simple Network Management Protocol) y de comandos de que dispone la propia herramienta. Zenoss mostró correctamente toda la información relacionada con la red, pero no mostró información del software/aplicaciones que estaban instalados y/o ejecutándose en los agentes.
De lo anterior se concluye que las mejores opciones en cuanto al soporte de recursos son Nagios y Lattice. HypericHQ presentó problemas con la identificación de la infraestructura virtual y Zenoss sólo mostró correctamente información relacionada con la red.
CONFIGURACIÓN
Para cada una de las herramientas se pueden agregar fácilmente nuevos agentes para monitorizar, configurándolos adecuadamente (los cuales deben cumplir con los pre-requisitos establecidos para la instalación de las herramientas) y los respectivos
servidores que recogen las mediciones enviadas por los diferentes agentes.
En cuanto a la monitorización de Hosts remotos se observó lo siguiente: Zenoss no necesitó la instalación de agentes o plugins en los Hosts cuando hace uso del protocolo SNMP. Nagios necesitó de la instalación de los plugins y el complemento NRPE. Con HypericHQ y Lattice fue necesario instalar los respectivos agentes en los Host.
Nagios, HypericHQ y Zenoss cuentan con una interfaz donde se pueden configurar fácilmente ciertos parámetros de monitorización. Nagios permite además configurar opciones de monitorización (definición de grupos, Host, servicios, etc.) a través de la modificación de archivos de texto plano (CFG). La configuración de parámetros de monitorización para Lattice se realiza modificando el código fuente. Las herramientas con autodescubrimiento, como es el caso de HypericHQ y Zenoss, limitan la configuración de los parámetros de monitorización a las opciones que presentan las plantillas.
La mejor opción con respecto a la configuración en nuestra opinión es Nagios, debido a que permite la modificación de los parámetros de monitorización a través de una interfaz Web y por medio de la modificación de archivos de texto plano; no está limitado a plantillas que permiten sólo la modificación de determinados parámetros.
IMPACTO EN LA UTILIZACIÓN DE RECURSOS
Se midió el consumo de memoria y CPU que presenta cada una de las herramientas en el servidor en estado de reposo, es decir, cuando la Nube no está recibiendo solicitudes de servicios. Las mediciones se hicieron con el comando top 2 se puede observar que Lattice y Nagios exhiben el consumo más bajo de estos recursos.
Para tener idea acerca del consumo de red de las herramientas, se midió la cantidad de bytes enviados desde los agentes al servidor al trasmitir la información de monitorización de las respectivas máquinas virtuales en las que se estaban ejecutando. Se utilizó la herramienta Wireshark [35]. En la Fig. 3 se puede observar que las herramientas que presentaron un menor consumo de red, enviando una menor cantidad de bytes, fueron HypericHQ y Lattice.
En cuanto al impacto en la utilización de recursos, se concluye que Lattice es el que exhibe la utilización más baja en los recursos evaluados. Nagios presentó un bajo consumo en memoria y CPU, pero fue el que envío mayor número de bytes por la red.
A la luz de los resultados obtenidos, se considera que para el nivel IaaS las herramientas más adecuadas son Nagios y Lattice debido a que ofrecen más opciones para recuperar métricas de desempeño de los diferentes recursos físicos y virtuales (Hosts); son escalables y exhiben una baja utilización en la mayoría de los recursos.
b) Nivel PaaS
RECOLECCIÓN DE LA INFORMACIÓN DE LA INFRAESTRUCTURA
Nagios, HypericHQ, Lattice y Zenoss permiten la recolección de la información de monitorización a través de diferentes agentes/sensores, tanto remotos como locales.
El análisis de la información recolectada es más fácil con Nagios, HypericHQ y Zenoss debido a que dichas herramientas presentan una interfaz gráfica para visualizar la información recogida por sus agentes. Lattice no ofrece esta funcionalidad y no posee mecanismos para analizar la información recolectada; los datos recolectados, sin procesar, pueden ser visualizados por la consola (shell). Esto coloca a Lattice en desventaja frente a las otras herramientas con respecto a esta característica.
INTERFACES GRÁFICAS (GUIS) PARA LA VISUALIZACIÓN DE LA
INFORMACIÓN RECOLECTADA
Las interfaces gráficas de HypericHQ y Nagios son muy intuitivas y fáciles de comprender. Nagios, además, posee varias opciones para personalizar la interfaz Web que han sido desarrolladas por la comunidad de usuarios y están disponibles en [22].
Lattice no cuenta con una interfaz gráfica.
La interfaz gráfica de Zenoss no es tan intuitiva y toma tiempo identificar las opciones que se necesitan configurar.
Las herramientas que presentan las mejores interfaces gráficas son HypericHQ y Nagios: son fáciles de utilizar y al resumir la información de monitorización en diferentes secciones, se facilita la comprensión de la información mostrada.
GENERACIÓN DE REPORTES
HypericHQ muestra un reporte muy básico sobre la disponibilidad de recursos que esta monitoreando. Sólo muestra información detallada por cada recurso, según los parámetros configurados en la plantilla del recurso/servicio. Presenta un reporte de los agentes que tiene desplegados. También se muestra información general del servidor (núcleo de HypericHQ) y se pueden consultar los reportes de diagnóstico. Finalmente, es posible configurar consultas a la base de datos y ver información general sobre los agentes.
Zenoss cuenta con una serie de reportes predefinidos (plantillas) donde muestra información de todos los dispositivos que se están monitoreando. Los reportes disponibles son de dispositivos, eventos, usuarios y desempeño (dispositivos y servicios).
La interfaz gráfica de Nagios tiene una sección de reportes donde se pueden configurar reportes de disponibilidad, tendencias, alertas, notificaciones y eventos. Al igual que HypericHQ, Nagios presenta
información sobre el comportamiento del servidor donde se está ejecutando. La interfaz muestra información de desempeño de Nagios y la programación de la cola de los servicios (locales y remotos) que se chequearán (Check Scheduling Queue).
La opción más completa para la generación de reportes es Nagios, debido a que HypericHQ es muy básico y Zenoss está limitado a los reportes predefinidos, los cuales no ofrecen mucha flexibilidad al momento de necesitar nuevos reportes.
VISUALIZACIÓN DE HISTÓRICOS
Con HypericHQ, Nagios y Zenoss se puede obtener la información de un día específico.
Nagios permite configurar reportes por Host, servicios o grupos, lo cual facilita el análisis de la información.
HypericHQ muestra información sólo por recursos de manera individual, no se puede obtener un reporte del comportamiento general de todos los recursos monitoreados.
Lattice no muestra información histórica.
En cuanto a la visualización de datos históricos se puede concluir que las opciones más completas son Nagios y Zenoss.
Finalmente, después de revisar todos los requerimientos para el nivel PaaS, se considera que los monitores más adecuados son HypericHQ y Nagios debido a que permiten la recolección y visualización de la información de monitorización; poseen una intuitiva interfaz Web, fácil de usar y desde donde se puede administrar la herramienta y observar toda la información recogida. Ofrecen además una gran variedad de reportes sobre datos históricos y en tiempo de ejecución.
VI. TRABAJOS RELACIONADOS
El diseño de un mecanismo de monitorización para la computación en Nube es un problema complejo. Por otro lado, debido a la inmadurez del modelo de computación en Nube, aún no existe una solución estándar y definitiva referente a la monitorización en estos entornos. Entre las iniciativas que abordan este tema se pueden mencionar: en [36] proponen e implementan un mecanismo para la monitorización y descubrimiento de servicios en la Nube, haciendo una extensión al Middleware Eucalyptus que utiliza Ganglia y NWS para recuperar información de desempeño de los recursos. En el artículo no presentan los criterios que utilizaron para seleccionar dichas herramientas. Por otro lado, en [10], definen las características que deben tomarse en cuenta para la monitorización de servicios en la Nube. Para los autores el establecer dichas características en un sistema de monitorización requiere de una arquitectura flexible y un diseño cuidadoso; utilizan Lattice como herramienta para la administración de servicios de la Nube. En [9], [12] y [37] se encuentran propuestas de arquitecturas para la monitorización y administración de servicios en la Nube que pueden servir de referencia al momento de diseñar los componentes de monitorización para OPTIMIS y BonFIRE.
Consumo CPU y Memoria
0
5
10
15
20
25
30
Lattice Nagios HypericHQ Zenoos
Herramientas
%
% uso CPU
% uso memoria
Figura 2. Consumo de recursos en el servidor (CPU y memoria).
Consumo de red
0
500
1000
1500
2000
2500
3000
3500
4000
4500
Lattice Nagios HypericHQ Zenoos
Herramientas
byte
s
Total bytes
enviados
Figura 3. Consumo de recursos en el servidor (red).
En este trabajo se utilizó el mismo enfoque presentado en [37], donde integran en la arquitectura herramientas de monitorización existentes en lugar de desarrollar otras nuevas.
VII. CONCLUSIONES
El objetivo de este trabajo fue evaluar herramientas de monitorización para entornos de Nubes, especialmente privados e híbridos. Las herramientas seleccionadas como resultado de las dos primeras fases de la metodología serán evaluadas más exhaustivamente en la plataforma experimental bajo condiciones de carga propias de los entornos Nube. Las herramientas más adecuadas serán posteriormente incluidas en los componentes de monitorización que se desarrollarán en el marco de los proyectos OPTIMIS y BonFIRE.
Del análisis realizado se desprenden las siguientes conclusiones:
Después de evaluar las cuatro herramientas seleccionadas en la fase uno, tomando en cuenta características particulares de los entornos Nube, en forma global y de forma específica para los niveles IaaS y PaaS, se concluye que la herramienta de código abierto más completa es Nagios, la cual cumple con la mayoría de los requerimientos exigidos, con excepción del consumo de red. Al respecto, se proyecta la realización de pruebas más detalladas, que incluyan un mayor número de métricas y que permitan obtener una conclusión más sólida al respecto. De mantenerse los resultados obtenidos hasta el momento, se recomienda dimensionar la red donde se despliega la herramienta de tal modo que no afecte el funcionamiento de las aplicaciones que se ejecutan sobre ella. Por tal motivo, se debe tener cuidado al realizar el despliegue de dicha herramienta en un entorno Nube determinado.
Es posible recomendar también herramientas adecuadas por cada nivel de servicio, por ejemplo Lattice parece muy útil para el nivel de infraestructura por su bajo overhead y el soporte a varios tipos de recursos. Las ventajas que ofrece HypericHQ en la
recolección y visualización de la información, lo colocan como una alternativa importante para el nivel PaaS.
Las herramientas con autodescubrimiento, como es el caso de HypericHQ y Zenoss, están limitadas en cuanto a su administración. Aunque poseen una variedad de plantillas y abarcan una gran cantidad de plataformas y servicios no se pueden extender fácilmente más allá de lo que las plantillas permiten.
La solución recomendada como resultado de este trabajo sería una combinación de herramientas para aprovechar al máximo las funcionalidades que se cubren en cada nivel. Se propone el uso de Lattice y Nagios combinadas en una solución híbrida que aprovecharía, principalmente, la arquitectura de plugins de Nagios, para añadir escalabilidad y versatilidad al sistema de monitorización y las ventajas de Lattice con respecto al bajo impacto en los recursos monitorizados. Como trabajo futuro, se propone integrar ambas herramientas en una arquitectura de monitorización de entornos Nube.
AGRADECIMIENTO
Esta investigación fue realizada en el HLRS (High Performance Computing Center Stuttgart) de la Universidad de Stuttgart y parcialmente financiada por los proyectos (del Séptimo Programa Marco, FP7, de la Comisión Europea) OPTIMIS (Optimized Infrastructure Services) con número de contrato 257115 y BonFIRE (Building Service Testbeds for Future Internet Research and Experimentation) con número de contrato 257386.
REFERENCIAS
[1] P. Mell y T. Grance, «A NIST definition of cloud computing», NIST
special publication, vol. 800, p. 145, 2011.
[2] Wikipedia contributors, «Computación en la nube», Wikipedia, la enciclopedia libre. Wikimedia Foundation, Inc., 10-jun-2012.
[3] R. Buyya, C. S. Yeo, y S. Venugopal, «Market-oriented cloud computing:
Vision, hype, and reality for delivering it services as computing utilities», in
High Performance Computing and Communications, 2008. HPCC’08. 10th
![Page 1: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/1.jpg)
![Page 2: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/2.jpg)
![Page 3: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/3.jpg)
![Page 4: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/4.jpg)
![Page 5: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/5.jpg)
![Page 6: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/6.jpg)
![Page 7: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/7.jpg)
![Page 8: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/8.jpg)
![Page 9: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/9.jpg)
![Page 10: [IEEE 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Medellin, Colombia (2012.10.1-2012.10.5)] 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) - Evaluation](https://reader035.documents.pub/reader035/viewer/2022080407/575095d11a28abbf6bc51aa2/html5/thumbnails/10.jpg)
