Monitorización a nivel de Plataforma de servicios desplegados en la Nube

ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM´ ATICA Monitorizaci´on a nivel de Plataforma de servicios desplegados en la Nube Monitoring Platform of Cloud Services Realizado por Samuel G´omez Cabrera Tutorizado por Francisco Javier Dur´an Mu˜noz Departamento Lenguajes y Ciencias de la Computaci´on UNIVERSIDAD DE M´ ALAGA M´ ALAGA, Julio 2015 Fecha defensa: El Secretario del Tribunal Resumen El desarrollo y crecimiento de tecnolog´ıas basadas en Cloud Computing o Computaci´on en la Nube nos proporciona un nuevo modelo de entender el desarrollo y computaci´on de aplicaciones y servicios. Este modelo est´a basado en internet y permite poner al alcance de usuarios y desarrolladores de software un conjunto de recursos que pueden utilizar remotamente sin el esfuerzo derivado de la implantaci´on y mantenimiento de equipos f´ısicos. As´ı, los distintos proveedores de servicios de computaci´on en la Nube proporcionan alta disponibilidad, flexibilidad, y diferentes capas de abstracci´on con diferentes caracter´ısticas y recursos bajo demanda. A pesar de las numerosas ventajas de la Nube, el despliegue de aplicaciones y servicios trae de la mano nuevos desaf´ıos. Cuestiones como la interoperabilidad entre distintas Nubes, o la reconfiguraci´on y gesti´on din´amica de servicios son algunos de los problemas que es necesario abordar de forma eficiente. En este trabajo, se desarrolla una infraestructura para dar soporte a la gesti´on y monitorizaci´on de servicios distribuidos en diferentes nubes. En concreto, se utilizan mecanismos para la especificaci´on de componentes y sensores para su despliegue a trav´es de diferentes proveedores de Nube. La monitorizaci´on de la plataforma subyacente a cada aplicaci´on es realizada a trav´es de estos sensores, encargados de recopilar informaci´on sensible de an´alisis. Los datos recopilados de cada componente permiten a los usuarios tomar decisiones de reconfiguraci´on de sus aplicaciones, y ejecutarlas a trav´es de tecnolog´ıas que permiten cambiar el estado del servicio. Palabras claves: Computaci´on en la Nube, Monitorizaci´on, Abstract Cloud Computing is a rapidly growing area that provide a new way to understand software and applications development. This Internet-based model provides a set of resources that can manage remotely without the investment needed to deploy and maintain their own infrastructure, to both users and software developers. Thus, Cloud computing providers offer high availability, flexibility, and different abstraction layers with different features and on-demand resources. Despite cloud benefits, deployment of applications and services brings new challenges to address. Issues such as interoperability between clouds, reconfiguring tasks and dynamic services management are part of the problems that we need to deal with. This project developed an infrastructure to managing and monitoring distributed systems among different Clouds. In particular, a set of technologies have been developed in order to specify components and sensors to be deployed through different Cloud providers. Monitoring the underlying platform of each application is carried out by sensors, which are responsible of collecting value data. The information obtained supports users to make robust decisions to reconfigure their applications. Keywords: Cloud Computing, monitoring ´ Indice 1. Introducci´on 10 1.1. Motivaci´on.................................... 10 1.2. Objetivos .................................... 11 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Estado del arte 13 2.1. Computaci´on en la Nube . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.1. Antecedentes .............................. 13 2.1.2. Definici´on y caracter´ısticas . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.3. Capas de abstracci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.4. TiposdeNubes............................. 17 2.2. Desaf´ıos e ideas claves de la Nube . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.1. Interoperabilidad entre Nubes: IaaS y PaaS . . . . . . . . . . . . . 19 2.2.2. SLA&QoS ............................... 23 2.3. Monitorizaci´on ................................. 25 2.3.1. Monitorizaci´on en la Nube . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.2. Herramientas .............................. 27 3. Desarrollo de la Infraestructura 30 3.1. Estudiodelsistema............................... 30 3.1.1. Alcance ................................. 30 3.1.2. Situaci´onactual............................. 31 3.1.3. Estudio y valoraci´on de alternativas . . . . . . . . . . . . . . . . . . 31 3.2. An´alisisdelsistema............................... 32 3.2.1. Objetivos ................................ 32 3.2.2. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.3. Casosdeuso .............................. 34 3.2.4. Identificaci´on de subsistemas . . . . . . . . . . . . . . . . . . . . . . 39 3.3. Dise˜no y especificaci´on del sistema . . . . . . . . . . . . . . . . . . . . . . 41 3.3.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.2. Dise˜no de la realizaci´on de los casos de uso . . . . . . . . . . . . . . 43 3.3.3. Modelodedatos ............................ 58 3.4. Implementaci´on de la infraestructura . . . . . . . . . . . . . . . . . . . . . 60 3.4.1. Medios.................................. 60 3.4.2. Tecnolog´ıas ............................... 61 3.4.3. Descripci´on de la soluci´on . . . . . . . . . . . . . . . . . . . . . . . 64 4. Resultados y Pruebas de an´alisis 68 5. Conclusiones 82 5.1. Trabajosfuturos ................................ 83 Referencias Bibliogr´aficas 84 Anexo I. Descripci´on t´ecnica del equipo servidor 88 Anexo II. Instrucciones de instalaci´on 89 ´ Indice de figuras 1. Capas de abstracci´on de la Nube y software tradicional . . . . . . . . . . . 15 2. Pir´amide de capas de abstracci´on de la Nube . . . . . . . . . . . . . . . . . 17 3. Tipos de Nube y ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. CU 01. Casos de uso de acceso al sistema y modificar perfil, y gesti´on de usuarios ..................................... 36 5. CU 02. Casos de uso de creaci´on, consulta y borrado de sensor . . . . . . . 37 6. CU 03. Casos de uso de despliegue de aplicaciones y sensores . . . . . . . . 37 7. CU 05. Casos de uso de monitorizaci´on y reconfiguraci´on de aplicaciones . 38 8. Diagrama de subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 10. Diagrama de secuencia inicio de sesi´on . . . . . . . . . . . . . . . . . . . . 44 11. Diagrama de secuencia modificar usuario . . . . . . . . . . . . . . . . . . . 45 12. Diagrama de secuencia modificar contrase˜na . . . . . . . . . . . . . . . . . 46 13. Diagrama de secuencia crear usuario . . . . . . . . . . . . . . . . . . . . . 47 14. Diagrama de secuencia borrar usuario . . . . . . . . . . . . . . . . . . . . . 48 15. Diagrama de secuencia crear sensor . . . . . . . . . . . . . . . . . . . . . . 49 16. Diagrama de secuencia consultar sensor . . . . . . . . . . . . . . . . . . . . 50 17. Diagrama de secuencia eliminar sensor . . . . . . . . . . . . . . . . . . . . 51 18. Diagrama de secuencia desplegar aplicaci´on . . . . . . . . . . . . . . . . . . 52 19. Diagrama de secuencia desplegar sensor . . . . . . . . . . . . . . . . . . . . 53 20. Diagrama de secuencia consultar servicios . . . . . . . . . . . . . . . . . . 54 21. Diagrama de secuencia monitorizar aplicaci´on . . . . . . . . . . . . . . . . 55 22. Diagrama de secuencia reconfigurar aplicaci´on . . . . . . . . . . . . . . . . 56 23. Diagrama de secuencia consultar hist´orico . . . . . . . . . . . . . . . . . . 57 24. Diagrama de entidad-relaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 59 25. Filosof´ıa s´ıncrona Multi-thread frente la as´ıncrona de Nodejs . . . . . . . . 61 26. Representaci´on jer´arquica de aplicaciones y entidades en Brooklyn . . . . . 63 27. Especificaci´on de aplicaci´on web de Chat en formato YAML y la estructura generadaenBrooklyn.............................. 68 28. Especificaci´on de localizaciones en formato YAML y despliegue de sensores 69 29. Especificaci´on de servicios y selecci´on de sensores para despliegue . . . . . 71 30. Informaci´on acerca del estado de los servicios desplegados . . . . . . . . . . 72 31. Monitorizaci´on de CPU en instancia de amazon y en instancia local . . . . 73 32. Monitorizaci´on de CPU en instancia de amazon y en instancia local, anotacionesrelevantes ............................... 74 33. Monitorizaci´on de CPU en instancia de amazon y en instancia local, suavizadodevalores ................................ 75 8 34. Monitorizaci´on de peticiones por segundo al servidor web, peticiones a la base de datos y tiempo de CPU de la instancia de amazon . . . . . . . . . 76 35. Interfaz de la aplicaci´on web desplegada en la m´aquina local y base de datos en una instancia de Amazon . . . . . . . . . . . . . . . . . . . . . . . 77 36. Interfaz de la consola de amazon ec2 donde se muestra la instancia desplegada que contiene la base de datos MySQL . . . . . . . . . . . . . . . . . . 77 37. Interfaz de reconfiguraci´on de My Web Cluster. Acci´on de parado del componente...................................... 78 38. Consulta de datos en hist´orico sobre los valores recogidos de CPU . . . . . 79 39. Consulta de datos en hist´orico sobre los valores recogidos de consultas a la basededatos .................................. 80 40. Consulta de datos en hist´orico sobre los valores recogidos de peticiones al servidorweb................................... 81 ´ Indice de tablas 1. Proyectosmulti-cloud.............................. 21 2. Librer´ıas y herramientas multi-cloud . . . . . . . . . . . . . . . . . . . . . 22 3. Importancia de la monitorizaci´on en la Nube . . . . . . . . . . . . . . . . . 26 4. Servicios de monitorizaci´on de Nube ofrecidos por los proveedores . . . . . 28 5. Servicios y herramientas de monitorizaci´on . . . . . . . . . . . . . . . . . . 29 6. Descripci´on de componentes y objetivos . . . . . . . . . . . . . . . . . . . . 32 7. Descripci´on de los requisitos del sistema . . . . . . . . . . . . . . . . . . . 33 8. conjunto de recursos de la REST API del sistema . . . . . . . . . . . . . . 67 9 en el que cada proveedor nos permite elegir no s´olo el sistema operativo que queremos que ejecute nuestra m´aquina, sino tambi´en seleccionar sus componentes, tales como tipo y numero de procesadores, tama˜no de memoria RAM o disco duro. Esto lo hace especialmente conveniente para ser el sustituto natural de los equipos f´ısicos, con la ventaja de poder adaptarlos a nuestras necesidades espec´ıficas en cada momento. Entre los proveedores de servicios que ofrecen IaaS se encuentran Amazon Web Services (AWS), Windows Azure, Rackspace, Google Compute Engine, HP o IBM. Plataforma como servicio (PaaS) Ocupando la capa intermedia se encuentra PaaS, destinada principalmente para el despliegue de aplicaciones o servicios espec´ıficos. En su mayor´ıa, el cat´alogo de servicios del proveedor, se compone de un conjunto de herramientas espec´ıficas destinadas a alojar aplicaciones o servicios desarrollados en un lenguaje de programaci´on o tecnolog´ıa determinada. Entre estos servicios, tambi´en se incluyen los destinados a cubrir las fases del ciclo de vida de desarrollo de software. La conciencia por parte del usuario de estar ejecutando una m´aquina f´ısica, a la vez que su control sobre la misma se ven reducidas dr´asticamente. A diferencia del modelo anterior, el conjunto de servicios constituye un grupo heterog´eneo y dependiente de la implementaci´on dada por cada proveedor. Este hecho, unido a la falta de est´andares, dificulta la interoperabilidad y migraci´on entre distintos proveedores [10], a la vez que propicia lo que se conoce como “vendor lock-in”III. Entre los de proveedores de servicios PaaS m´as representativos, destacan Amazon Web Services (AWS), Windows Azure, Google App Engine, Red Hat OpenShift o Heroku. Software como servicio (SaaS) En la cima de la pir´amide, SaaS representa el conjunto de aplicaciones accesibles a trav´es de internet como servicio. En este caso, el usuario ´unicamente act´ua como consumidor de un servicio ofertado y que cumple una determinada funci´on. La diferencia con el modelo tradicional, es que los usuarios o clientes se subscriben a una determinada aplicaci´on o servicio que se distribuye a trav´es de la red, en lugar de desarrollarla o comprarla e instalarla en sus sistemas f´ısicos. Este tipo de aplicaciones, pueden a su vez dar soporte o complementar a otros servicios. Desarrolladores de software o entidades, pueden decidir hacer uso de un determinado IIISituaci´on en la cual el cliente que usa un producto o servicio no tiene la capacidad de migrar a otros de la competencia. 16 servicio accesible a trav´es de la red para enriquecer sus propios sistemas. El vendor lock-in resulta, igual que en el modelo anterior, uno de los principales obst´aculos para la adopci´on de servicios basados en SaaS. Dejando de lado esta dependencia, otra de las cuestiones a tener en cuenta es la falta de control total sobre los procesos ejecutados por el usuario al no disponer del control del cual dispon´ıamos en casos anteriores, sobre la aplicaci´on o sobre la infraestructura subyacente. Algunos ejemplos de servicios SaaS m´as conocidos son Google Apps, Microsoft Online Services o Salesforce. Figura 2: Pir´amide de capas de abstracci´on de la Nube 2.1.4. Tipos de Nubes Si tenemos en cuenta como son desplegados o implementados los servicios que dan soporte a una Nube, podemos clasificarlas seg´un los siguientes tipos: Nube privada: tipo de Nube en la cual el consumidor tiene acceso exclusivo virtual o f´ısico a sus servicios de c´omputo. Nube p´ublica: es aquel modelo de Nube en el cual la infraestructura y sus recursos l´ogicos pertenecientes al entorno se encuentran disponibles para el p´ublico en general o para un amplio grupo de usuarios. Nube h´ıbrida: en este caso se combinan dos o m´as tipos de Nubes (P´ublica, Privada o Comunitaria) que se mantienen como entidades separadas pero con un nexo de uni´on a trav´es de tecnolog´ıas estandarizadas o propietarias, que permiten la portabilidad de datos y aplicaciones. 17 Nube comunitaria: aqu´ı, la infraestructura es compartida por diversas organizaciones y su principal objetivo es soportar a una comunidad espec´ıfica con un conjunto de preocupaciones u objetivos en com´un. Figura 3: Tipos de Nube y ejemplos En la Figura 3 podemos observar algunos ejemplos de soluciones o implementaciones de cada tipo de Nube. Sin duda las Nubes p´ublicas son las que tienen un mayor recorrido y por ello multitud de proveedores ofrecen soluciones de este tipo, no obstante estos mismos proveedores est´an comenzando a poner al alcance de los usuarios alternativas a sus servicios, en ocasiones como software libre como es el caso de OpenStack [11], a nivel privado, h´ıbrido o incluso comunitario. Este ´ultimo caso es el de NYSE Technologies [12]. 2.2. Desaf´ıos e ideas claves de la Nube En esta secci´on se exponen los retos e ideas clave a las que se debe hacer frente en el estado actual de los servicios de computaci´on en la Nube. Estos desaf´ıos, son objeto de los principales trabajos de investigaci´on en la actualidad sobre la materia, y todos ellos guardan una estrecha relaci´on con el objetivo del presente trabajo. 18 2.2.1. Interoperabilidad entre Nubes: IaaS y PaaS Generalmente, las capas de abstracci´on IaaS yPaaS son las m´as demandadas por parte de los desarrolladores y empresas desarrolladoras de software. Su consumo crece a˜no tras a˜no gracias a su flexibilidad, simplicidad, y sobretodo por requerir una menor inversi´on en comparaci´on con la necesaria para la instalaci´on de infraestructuras propias. Las soluciones de PaaS, resultan especialmente convenientes para el desarrollo y despliegue de aplicaciones usando una determinada tecnolog´ıa, por ejemplo un lenguaje de programaci´on y framework de desarrollo concreto. La implementaci´on de estos servicios son llevadas a cabo por parte del proveedor, no existiendo un est´andar para la creaci´on de los mismos. Este hecho dificulta enormemente la interoperabilidad y aumenta el vendor lock-in, adem´as dependemos del control que se nos otorgue desde la interfaz de gesti´on para configurar nuestros componentes. La ausencia de dise˜nos apoyados en est´andares, hace que resulte complicado establecer soluciones a corto plazo para facilitar tareas como la de interoperabilidad, gesti´on din´amica o reconfiguraci´on de servicios, que sean capaces de operar con la gran cantidad de proveedores existentes. Iniciativas como Cloud4SOA [13], han tratado de abordar este problema ofreciendo un servicio que da soporte a una serie de proveedores PaaS, estableciendo mecanismos para la gesti´on y migraci´on de aplicaciones entre los mismos. No obstante, tareas como la migraci´on entre estos proveedores no han sido posible en todos los casos. Esta heterogeneidad, pone de manifiesto que resulta necesaria la convergencia de los proveedores de servicio para el desarrollo de servicios basados en est´andares comunes para conseguir una mayor y mejor competitividad, que retorne asimismo en un mayor beneficio para los usuarios. En la capa de IaaS y con un mayor control sobre la infraestructura virtual, como vimos en las Figuras 1 y 2, resulta abordable el desarrollo de mecanismos para proporcionar una soluci´on a la problem´atica expuesta. Con estas ideas en mente, las investigaciones sobre Inter-Clouds [14], tienen como prop´osito garantizar calidad de servicio, as´ı como rendimiento y disponibilidad de cada servicio, a trav´es de la interconexi´on de Nubes de diferentes proveedores. Aqu´ı aparte de la interoperabilidad necesaria, cobran tambi´en especial importancia las SLAIV, la QoS, y el uso de interfaces est´andar. La entrada en juego del Inter-Cloud y su necesidad [15] tienen como argumento sus beneficios tales como: diversificaci´on geogr´afica de recursos, mayor capacidad de recupeIVSLA - Service Level Agreement, en castellano acuerdo de nivel de servicio 19 raci´on ante desastres, se evita el vendor lock-in y los proveedores son capaces de ofrecer mejores SLA a los usuarios. Tipos de Inter-Cloud Dentro de los llamados Inter-Clouds, podemos clasificarlos en las dos siguientes categor´ıas [15]: Clouds o Nubes federadas: se da cuando un conjunto de proveedores de servicios de Nube, de forma voluntaria, realizan interconexiones entre sus infraestructuras con el objetivo de permitir el mutuo intercambio de recursos. Este enfoque resulta especialmente interesante para organizaciones o entidades gubernamentales. Multi-Cloud: hace referencia al uso de m´ultiples e independientes Nubes por parte de un cliente o servivio. A diferencia de la anterior categor´ıa, en este caso un entorno multi-cloud no implica la interconexi´on entre y compartici´on de recursos por parte de proveedores. La responsabilidad del manejo, planificaci´on y gesti´on de los recursos recae sobre el cliente o los servicios que act´uen como intermediarios (denominados brokers en la literatura en ingl´es) del mismo. Dentro de los Inter-Clouds, el enfoque multi-cloud ser´a el que ocupe mayor atenci´on a lo largo del trabajo. En este modelo, se asume que no existe a priori ning´un acuerdo entre proveedores de servicios. Multi-Cloud: iniciativas, herramientas y tecnolog´ıas A continuaci´on se har´a un resumen de los proyectos y tecnolog´ıas en relaci´on a multicloud que han sido objeto de an´alisis y estudio. La Tablas 1 y 2 no pretende ser un informe exhaustivo de cada una de las herramientas existentes, no obstante, puede servir para ofrecer una visi´on global de las m´as relevantes, de sus principales caracter´ısticas y de su estado actual. 20 Tipo/Organizaci´on Estado Licencia Caracter´ısitcas Contrail [16] EU project terminado Apache 2.0 Nube federada, SLA, IaaS & PaaS, portabilidad OPTIMIS [17] EU project terminado BSD license Nube federada, Nube comunitaria, IDE, SLA mOSAIC [18] EU project terminado Apache 2.0 Nube federada y multicloud, API, portabilidad, sem´antica STRATOS* [19] York University. Apoyada por fondos de NSERC, Amazon and CA Inc. terminado Apache 2.0 PaaS, aplicaciones determinadas, desarrollo y ejecuci´on OpenTOSCA [20] Institute of Architecture of Application Systems, Stuttgart en desarrollo Apache 2.0 est´andar TOSCA, ecosistema, contenedores de aplicaciones MODAClouds [21] EU project en desarrollo Apache 2.0 IDE, adaptaci´on, QoS, prototipado temprano, Model-driven , sem´antica SeaClouds [22] EU project en desarrollo Apache 2.0 orquestaci´on, SLA, monitorizaci´on, basado en est´andares, reconfiguraci´on Cloud4SOA EU project terminado GPL recomendaci´on, sem´antica, PaaS, discovery Apache Brooklyn [23] CloudSoft en desarrollo Apache 2.0 CAMP, despliegue, gesti´on de aplicaciones distribuidas Tabla 1: Proyectos multi-cloud *Donado a Apache en 2013 21 Tipo Ult. versi´on Lenguaje licencia Caracter´ısitcas Apache jclouds [24] librer´ıa 1.9.0 java, clojure Apache 2.0 portabilidad, control absoluto, desarrollo muy activo, gran comunidad, popular, importante rango de proveedores, plantillas Apache LibCloud [25] librer´ıa 0.17.0 python Apache 2.0 abstracci´on, importante rango de proveedores, simplicidad, gran comunidad Apache DeltaCloud [26] librer´ıa 1.1.3 ruby Apache 2.0 RESTful API, proveedores m´as importantes SimpleCloud* [27] librer´ıa 2.0.1 PHP BDS License abstracci´on, simplicidad, almacenamiento y bases de datos, poca implementaci´on a nivel IaaS Apache Nuvem [28] librer´ıa 1.0-incubating java Apache 2.0 poco activo, solo soporta Google App Engine y Amazon EC2 Tabla 2: Librer´ıas y herramientas multi-cloud *Incluida en Zend Framework como Zend Cloud [29] Como se puede observar en la tabla 2, las librer´ıas multi-cloud m´as populares y con 22 mayor n´umero de proveedores en su cat´alogo son Apache jclouds y Apache LibCloud, por ello constituyen un est´andar de facto para desarrolladores de java ypython respectivamente. La herramienta Brooklyn, desarrollada por Cloudsoft y actualmente incluida dentro del proyecto Apache IncubatorV, hace uso de jclouds y es sin duda una de las m´as avanzadas y prometedoras del sector. El proyecto SeaClouds, en el cual participa la Universidad de M´alaga, usa actualmente Brooklyn para el despliegue de aplicaciones. 2.2.2. SLA & QoS Tal y como vimos en la secci´on 2.2.1, los conceptos de SLA y QoS resultan clave. Para aprovechar la ventajas ofrecidas por la computaci´on en la Nube es imprescindible poder establecer acuerdos fiables con los proveedores para garantizar el cumplimiento de los requisitos necesarios, y la calidad del servicio. SLA: Acuerdo a nivel de servicio El t´ermino SLA [30] se define como un contrato entre proveedor y cliente acerca de un servicio, donde se especifica la funci´on que debe realizar ´este, sus l´ımites en cuanto a rendimiento, las obligaciones de ambos actores, y c´omo deben manejarse las posibles desviaciones respecto de las condiciones acordadas inicialmente. El SLA contiene en esencia, el conjunto de requisitos no funcionales del servicio que el potencial usuario solicita al proveedor. Este es un ´area objeto de multitud de trabajos de investigaci´on en la actualidad, y su estandarizaci´on, evoluci´on y automatizaci´on suponen un reto. Cada proveedor de servicios de Nube establece e informa a los usuarios de los SLA de sus productos, estos constituyen una garant´ıa y son sin duda un factor muy importante a tener en cuenta. La importancia se debe a lo cr´ıtico que puede llegar a ser para las organizaciones una violaci´on de alguno de los requisitos que deben cumplir sus sistemas. Los contenidos [31] que deber´ıa incluir un SLA son: el conjunto de servicios ofertados por el proveedor una definici´on especifica de cada uno de los servicios las responsabilidades del proveedor y clientes el conjunto de m´etricas usadas para determinar si el proveedor est´a suministrando los servicios tal y como se prometi´o Vhttp://incubator.apache.org 23 un mecanismo de auditor´ıa los mecanismos disponibles para la resoluci´on de conflictos en el caso de que estos t´erminos no se llegaran a cumplir las condiciones en las cuales el SLA puede cambiar a lo largo del tiempo A pesar de que algunos proveedores ofrecen condiciones negociables en funci´on de los requisitos espec´ıficos del cliente, en Nubes p´ublicas habitualmente esto no ocurre as´ı, y los clientes pueden no ver satisfechas sus necesidades por completo con los SLA est´andar. Esto se une a que, normalmente, las especificaciones de los SLA se encuentran basadas en plantillas expresadas en lenguaje natural, de car´acter ambiguo, por lo que resulta dif´ıcil la convergencia entre estas especificaciones y los requisitos, QoS y necesidades de los sistemas de informaci´on reales. Con esta visi´on en mente, cobra m´as importancia si cabe el desarrollo de tecnolog´ıas inter-cloud que permitan a los proveedores mejorar las condiciones de los SLA (p. ej. a trav´es de Nubes federadas) y a clientes controlar el cumplimiento de los requisitos de sus sistemas, mediante t´ecnicas avanzadas y adaptables de monitorizaci´on, y evitar el vendor lock-in con tecnlog´ıas multi-cloud. QoS: Calidad de servicio En computaci´on en la Nube, QoS [32] hace referencia a los niveles de rendimiento, fiabilidad y disponibilidad ofrecida por un determinado servicio o infraestructura de un proveedor. Parte de estos par´ametros pueden encontrarse especificados en los SLA en forma de niveles m´ınimos que deben cumplirse. El criterio de calidad de servicio no es ´unico, y resulta altamente dependiente de la aplicaci´on o servicio desplegado en la Nube y de su entorno. As´ı, por ejemplo, si un determinado proveedor ofrece unos par´ametros de latencia determinados en funci´on de la localizaci´on de su centro de datos, esta no ser´a la misma para el acceso de usuarios desde cualquier localizaci´on. De la misma forma, un servicio puede requerir diferentes par´ametros de calidad de servicio dependiendo de los cambios en las reglas del negocio, la ´epoca del a˜no, o incluso la hora de d´ıa. Resulta evidente que un control de la QoS en tiempo real mediante t´ecnicas de monitorizaci´on marcar´a la diferencia y permitir´a reaccionar ante los requisitos cambiantes de los servicios, mediante la reconfiguraci´on de los mismos, de la infraestructura, mediante escalabilidad (con recursos del mismo proveedor, de otro o de manera h´ıbrida), o bien 24 los asociados a las condiciones del proveedor. Dentro de esta ´ultimo caso, se encuentran aquellas situaciones asociadas a los cambios en las condiciones del servicio por parte del proveedor, ya sea directamente QoS, tarificaci´on, aparici´on de nuevos competidores o pol´ıticas de seguridad. Evitar el vendor lock-in y tener poder de decisi´on para redistribuir, reconfigurar o escalar nuestros servicios, nos conduce a la obtenci´on de una mejor QoS para nuestros servicios. 2.3. Monitorizaci´on La palabra monitorizar se define como: “observar mediante aparatos especiales el curso de uno o varios par´ametros fisiol´ogicos o de otra naturaleza para detectar posibles anomal´ıas’’. En ingenier´ıa del software [33], usamos el t´ermino monitorizaci´on para referirnos al registro de la ocurrencias de un evento espec´ıfico durante la ejecuci´on de un programa, con el objetivo de obtener informaci´on que no es posible mediante el estudio de su implementaci´on. Esta informaci´on incluye el comportamiento del componente en ejecuci´on as´ı como informaci´on acerca del sistema operativo sobre el que se ejecuta. Cuando tratamos con sistemas distribuidos, el concepto de monitorizaci´on o supervisi´on no s´olo se asocia al control del estado de cada elemento integrante del sistema, sino tambi´en al rendimiento de ´este y su cumplimiento de determinados patrones individuales que formar´an parte de los requisitos conjuntos del sistema completo. Esta monitorizaci´on en tiempo real, debe cumplir el objetivo primordial de mantener el rendimiento del sistema dentro de un rango de valores, de manera que, que no var´ıe el orden ni el comportamiento de los eventos del sistema. El nivel de monitorizaci´on no siempre es el mismo en todo los sistemas, y de igual forma, tampoco lo es dependiendo del destinatario final de estos resultados. Los expertos m´as t´ecnicos probablemente desear´an conocer la informaci´on acerca del funcionamiento a bajo nivel. En cambio, para los profesionales m´as cercanos al sistema directivo ser´an de utilidad aquellos par´ametros sobre los procesos de alto nivel de su sistema. Por ello, se debe recopilar la informaci´on adecuada en cada caso, representarla con claridad y de manera que aporte valor y soporte la toma de decisiones, ya sea esta, a largo o medio plazo o incluso en tiempo de ejecuci´on. 25 3.2. An´alisis del sistema Despu´es del estudio de los elementos necesarios para dar una soluci´on al problema, ahora se debe especificar correctamente cada uno de los elementos que van a servir de base para el dise˜no del sistema. Mediante el An´alisis del sistema, se especificar´a de manera m´as detallada la infraestructura que vamos a desarrollar, sus objetivos y los requisitos que debe satisfacer. 3.2.1. Objetivos En la secci´on de 3.1.1 se encuentran descritos en alto nivel los objetivos que debe cumplir la infraestructura a desarrollar. Estos objetivos, sin embargo, deben dividirse y especificarse de manera m´as formal y adecuada a la posterior fase de dise˜no. En la Tabla 6 se clasifica y resume el conjunto de objetivos que se desea cumplir. Nombre Objetivo Despliegue de aplicaciones distribuidas en la Nube El sistema debe proporcionar un mecanismo para la descripci´on y despliegue de los servicios y sus componentes en la Nube. Despliegue de sensores en la Nube El sistema debe proporcionar un mecanismo para la descripci´on y despliegue de mecanismos sensores para recopilar datos de monitorizaci´on. Recopilaci´on de datos El sistema debe establecer mecanismos para la obtenci´on de los datos de sensores y de las aplicaciones desplegadas en la Nube. Presentaci´on de datos e informaci´on Los datos recopilados y la informaci´on sobre los servicios, deben presentarse de manera adecuada mediante interfaces gr´aficas intuitivas y que permitan realizar an´alisis Almacenamiento de datos Los datos recopilados deben poder almacenarse pertinentemente y de forma robusta y consistente en una base de datos Consulta de datos Los datos recopilados, deben encontrarse accesibles a posteri, para su consulta y an´alisis Toma de decisiones y reconfiguraci´on Los componentes desplegados en la Nube, deben poder reconfigurarse y cambiar su comportamiento en base a las decisiones adoptadas por el usuario. Control y acceso de usuarios Los usuarios deben poder acceder a sus configuraciones y servicios de forma independiente y poder configurar su perfil. Tabla 6: Descripci´on de componentes y objetivos 32 3.2.2. Requisitos del sistema Tras la definici´on de los objetivos a cumplir, los requisitos marcar´an aquellas condiciones o funcionalidades que har´an que se cumplan estos objetivos. A continuaci´on en la Tabla 7 se muestra el cat´alogo de requisitos definido. Crear usuario Crear un nuevo usuario y su almacenamiento en base de datos Eliminar usuario Eliminar un usuario de la base de datos Inicio de sesi´on Inicio de sesi´on del usuario en el sistema Especificar aplicaci´on Definir una aplicaci´on para su posterior despliegue, implicando esto la definici´on de sus caracter´ısticas Crear sensor Creaci´on y almacenamiento de un sensor para su posterior despliegue, implicando esto la definici´on de su localizaci´on y caracter´ısticas Eliminar sensor Eliminar un determinado sensor de base de datos Desplegar aplicaci´on Desplegar una determinada aplicaci´on ya definida a trav´es de su especificaci´on Desplegar sensor Desplegar un determinado sensor ya definido a trav´es de su especificaci´on Consulta servicios Consultar el estado de los servicios desplegados Modificar perfil Modificar par´ametros del perfil del usuario Monitorizar aplicaci´on Obtener datos de los sensores que monitorizan la aplicaci´on Reconfigurar aplicaci´on Reconfigurar o cambiar el estado de una aplicaci´on desplegada Consultar hist´orico Consultar datos del hist´orico de monitorizaci´on de aplicaciones almacenado en base de datos Consultar sensor Consultar la especificaci´on de los sensores definidos en base de datos Cierre de sesi´on Terminar la sesi´on del usuario en el sistema Tabla 7: Descripci´on de los requisitos del sistema 33 3.2.3. Casos de uso En la especificaci´on de requisitos de la Tabla 7, se han identificado los requisitos que debe cumplir nuestro sistema. A continuaci´on se ilustran los casos de uso, estos deben especificar y ayudar a´un m´as a la comprensi´on de los requisitos y la relaci´on entre el sistema y su entorno. Estos casos de uso, deben entenderse como casos de alto nivel. Esto quiere decir que a pesar de que tratan de especificar los requisitos con m´as detalle, no constituyen una especificaci´on completa de la funcionalidad deseada. A medida que se avance hacia las fases de dise˜no, esta funcionalidad ser´a descrita y especificada con mayor detalle de cara a la implementaci´on. En un caso de uso, se entiende por actor a todo aquel usuario o entidad que accede al sistema para satisfacer sus necesidades a trav´es del servicio que se le ofrece. Los actores se dividen seg´un su rol, pudiendo pertenecer un actor a varios roles distintos. Los actores que van a interactuar con nuestro sistema ser´an de los dos siguientes tipos: Usuario: el usuario, puede realizar todas las acciones sobre los sensores, el despliegue, la monitorizaci´on y configuraci´on de servicios. De igual forma podr´a cambiar su usuario y contrase˜na si lo desea. Sin embargo, no podr´a realizar consultas a la base de datos sobre objetos que no le pertenezcan o no hayan sido creados por ´el. Los objetos pertenecientes al sistema si ser´an accesibles, pero no podr´a realizar operaciones de borrado sobre ellos ni tampoco sobre su usuario ni el resto de usuarios del sistema. Administrador: el administrador posee aparte de las funcionalidades atribuidas al usuario normal, la capacidad para la crear y borrar usuarios. Casos de uso: CU 01.(v´ease Figura 4): describe las funciones encaminadas a la autenticaci´on del usuario en el sistema, as´ı como la modificaci´on del perfil del mismo. El inicio de sesi´on en el sistema por parte del usuario ser´a un paso necesario para la realizaci´on del resto de funciones, por lo que el resto de casos de uso deber´an incluir el de inicio de sesi´on. Este comportamiento no se ha ilustrado mediante inclusiones para mayor simplicidad y no cargar de complejidad los diagramas. El usuario acceder´a al 34 sistema mediante sus credenciales haciendo uso del nombre de usuario y contrase˜na, este nombre de usuario y contrase˜na es creado por el Administrador, que es el usuario con rol suficiente para la creaci´on y borrado de usuarios. El Administrador, podr´a seleccionar cualquier usuario de la lista de usuarios y borrarlo y asimismo dispondr´a de un formulario para la creaci´on de ellos. CU 02.(v´ease Figura 5): especifica las distintas operaciones sobre sensores, es decir, la creaci´on, consulta y el borrado de los mismos. La creaci´on de sensores es realizable por cualquier tipo de usuario a trav´es de un formulario en el cual se escriben las caracter´ısticas del mismo. Estos sensores son objetos pertenecientes a su creador, salvo los sensores que ser´an objetos de sistema y ser´an accesibles por cualquier usuario. La consulta de sensores para cada usuario devolver´a una lista con los sensores creados por ´el mismo, pudiendo realizar las operaciones de consulta y borrado para cada uno de ellos. CU 03.(v´ease Figura 6): en este caso de uso se determinan las funciones de despliegue de aplicaciones y sensores. La extensi´on nos indica que la operaci´on de desplegado de sensores se puede realizar conjuntamente al desplegar la propia aplicaci´on. Las operaciones de selecci´on de sensor y especificaci´on de la aplicaci´on aparecen con el estereotipo de inclusi´on para reflejar que son necesarios para el cumplimiento del objetivo en cada caso. El despliegue de aplicaciones se realiza a trav´es de un formulario encaminado a tal fin, mediante la especificaci´on de una aplicaci´on podemos a continuaci´on seleccionar un sensor, de los accesibles a trav´es de la operaci´on consulta, para su despliegue. Estas operaciones se pueden realizar por tanto de forma conjunta como se indica en el diagrama, o puede indicarse el despliegue de sensores de forma independiente. CU 04.: la consulta de servicios por parte del usuario no implica ning´un caso de inclusi´on ni extensi´on. A trav´es de esta operaci´on consulta, el usuario obtendr´a una lista con las aplicaciones que se encuentran desplegadas incluy´endose el estado actual de la misma. CU 05.(v´ease Figura 7): las operaciones que realizamos sobre las aplicaciones ya desplegadas vienen indicadas en este caso de uso, y son las correspondientes a las funciones de monitorizaci´on y reconfiguraci´on. La monitorizaci´on es junto al despliegue de aplicaciones y servicios uno de los casos de uso m´as relevantes. Para la monitorizaci´on, el usuario selecciona del men´u de aplicaciones disponibles aquellos elementos que desea monitorizar y a continuaci´on se reciben los datos pertinentes. La reconfiguraci´on es tambi´en realizada mediante la selecci´on en este men´u de aquellas acciones que se encuentran disponibles para ejecutarse para cada aplicaci´on. CU 06.: en el caso de uso de consulta de hist´orico solo disponemos de la operaci´on de consulta por parte del usuario sin ning´un caso de inclusi´on o extensi´on. Mediante un formulario, el usuario puede especificar filtros sobre los campos de b´usqueda para la 35 obtenci´on de las entradas disponibles que cumplan dichos patrones. Estos patrones, proporcionan mecanismos para determinar caracter´ısticas como su rango, fecha o nombre. El conjunto de valores obtenidos ser´an ´unicos para cada usuario ya que ser´an datos obtenidos por un usuario concreto. De esta forma, tras la b´usqueda el usuario obtendr´a aquellos objetos pertenecientes ´unicamente a su usuario y no los datos recopilados por cualquier otro. Figura 4: CU 01. Casos de uso de acceso al sistema y modificar perfil, y gesti´on de usuarios 36 Figura 5: CU 02. Casos de uso de creaci´on, consulta y borrado de sensor Figura 6: CU 03. Casos de uso de despliegue de aplicaciones y sensores 37 Figura 7: CU 05. Casos de uso de monitorizaci´on y reconfiguraci´on de aplicaciones 38 3.2.4. Identificaci´on de subsistemas A partir de la descripci´on de los casos de uso en la secci´on anterior, podemos empezar a identificar algunos subsistemas que comparten procesos de la misma categor´ıa. La separaci´on de estos subconjuntos ayuda a comprender las diferentes funciones y sus relaciones con el sistema completo. Estos subsistemas se pueden resumir en los siguientes: Subsistema de control de acceso Subsistema de control de perfil Subsistema de control de usuario Subsistema de despliegue Subsistema de consulta de servicios o aplicaciones Subsistema de sensores Subsistema de hist´orico Subsistema de monitorizaci´on y reconfiguraci´on Subsistema de utilidades y servicios En la Figura 8 se representa un diagrama de los subsistemas involucrados en los diferentes procesos, as´ı como las relaciones de los mismos. La infraestructura a desarrollar est´a basada en el patr´on modelo vista controlador (MVC). Este patr´on de arquitectura establece una separaci´on entre los datos y la l´ogica de negocio de una aplicaci´on, y su interfaz de usuario y el control de eventos y comunicaciones. Este modelo y la abstracci´on de cada una de las capas, permite la reutilizaci´on de componentes y a la vez facilita la tarea de desarrollo y mantenimiento de aplicaciones y servicios. 39 Utilidades y servicios Acceso a datos Database Vista Datos lógica Control de servicios Monitorización y reconfiguración Histórico Sensores Despliegue Control de usuario Control de perfil Control de acceso GUI Figura 8: Diagrama de subsistemas 40 3.3. Dise˜no y especificaci´on del sistema El objetivo del proceso de dise˜no es la definici´on de la arquitectura del sistema y de su entorno, junto con una descripci´on detallada de cada uno de los componentes. A partir de estas especificaciones, ser´a posible llevar a cabo la tarea de implementaci´on final de la infraestructura. 3.3.1. Arquitectura del sistema Mediante la definici´on de la arquitectura general del sistema, especificamos las particiones f´ısicas del mismo, la descomposici´on de sus subsistemas de dise˜no y la ubicaci´on de cada uno de ellos. En esta fase de modelado, se deben incluir detalles de la infraestructura tecnol´ogica que dar´a soporte al sistema. Para ello, se ampliar´an los detalles acerca de la implementaci´on concreta de cada uno de los nodos involucrados en el sistema. Para el modelo de sistema que identificamos anteriormente en la secci´on 3.2.4, debemos asignar aquellos recursos hardware, software y de comunicaciones que soporten la carga t´ecnica y las especificaciones del sistema para su implementaci´on. La infraestructura dise˜nada va a estar compuesta principalmente por los siguientes elementos: Servidor web API de acceso al servidor web Base de datos Servidor Brooklyn La tecnolog´ıa de desarrollo de cada uno de estos componentes debe elegirse de acuerdo a las necesidades del entorno que se detallaron en la fase de estudio. Hoy en d´ıa, el patr´on MVC es implementado por muchos frameworks webs de diferentes lenguajes de programaci´on. Estos frameworks se han popularizado enormemente en los ´ultimos tiempos en el desarrollo de aplicaciones web. Para la valoraci´on del framework y lenguaje m´as adecuado se han tenido en cuenta aquellos m´as extendidos y popularizados, primando como caracter´ısticas m´as relevantes la eficiencia, rendimiento y la capacidad para comunicarse con los componentes externos. De igual forma, el tipo de base de datos escogida para dar soporte a los datos recopilados por la infraestructura se ha seleccionado de entre las disponibles por su capacidad para ofrecer un rendimiento y capacidad acorde a los requisitos del sistema. La Figura 9 pretende ilustrar los nodos y componentes involucrados en el sistema as´ı como las distintas tecnolog´ıas necesarias para su funcionamiento. La plataforma de monitorizaci´on constituye el n´ucleo del sistema y su implementaci´on debe realizarse proveyendo mecanismos para comunicarse con el resto de componentes que forman la infraestructura. 41 Borrar usuario matarSesionUsuario sesión iniciada :login «controller» optional borrarSensoresdeUsuario Sensor borrar Usuario borraUsuario :Usuarios «controller» borrarUsuario(nombre) :Usuarios «GUI» Administrador Figura 14: Diagrama de secuencia borrar usuario 48 Crear sensor Sensor Sensor nuevoSensor Sensor crearSensor(parametros) :Sensor «controller» nuevoSensor(parametros) :Sensor «GUI» Usuario Figura 15: Diagrama de secuencia crear sensor 49 Consultar sensor Sensor Sensor getSensorById Sensor sensor(id) :Sensor «controller» consultarSensor(id) :Sensor «GUI» Usuario Figura 16: Diagrama de secuencia consultar sensor 50 Eliminar sensor mensaje(error) permisoDenegado sensor de otro usuario sensor de usuario alt borrarSensor Sensor borrarSensor(id) :Sensor «controller» borrarSensor(id) :Sensor «GUI» Usuario Figura 17: Diagrama de secuencia eliminar sensor 51 Desplegar aplicación instancia/despliegue Nube proveedor error mensaje(ok) despliegueCorrecto POST desplegar mensaje(error) especificación inválida especificación válida alt Brooklyn API Brooklyn «sistema externo» desplegarAplicacion :Despliegue «controller» desplegarAplicacion(especificacion) :Despliegue «GUI» Usuario Figura 18: Diagrama de secuencia desplegar aplicaci´on 52 Desplegar sensor desplegarSensor(SensorSpec) Sensor Sensor getSensorById Sensor sensor(id) :Sensor «controller» instancia/despliegue Nube proveedor error mensaje(ok) despliegueCorrecto POST desplegar mensaje(error) especificación inválida especificación válida alt Brooklyn API Brooklyn «sistema externo» desplegarAplicacion :Despliegue «controller» seleccionaSensor(id) :Despliegue «GUI» Usuario Figura 19: Diagrama de secuencia desplegar sensor 53 Consultar servicios mensaje(Estado) mostrarEstado Estado respuestaEstado estado check Nube proveedor GET getServicios Brooklyn API Brooklyn «sistema externo» consultar :Servicios «controller» consultarServicios() :Servicios «GUI» Usuario Figura 20: Diagrama de secuencia consultar servicios 54 loop [Cancelación por parte del usuario] Monitorizar aplicación mensaje(Dato) mostrarDato Dato respuestaDato dato check Nube proveedor GET getSensor(name) Brooklyn API Brooklyn «sistema externo» monitorizar(id,metrica) :Monitorizacion «controller» monitorizarAplicacion(id,metrica) :Monitorizacion «GUI» Usuario Figura 21: Diagrama de secuencia monitorizar aplicaci´on 55 Reconfigurar aplicación setEffector() Nube proveedor POST postEffector(name) Brooklyn API Brooklyn «sistema externo» configurar(id,accion) :Reconfiguracion «controller» reconfigurarAplicacion(id,metrica) :Reconfiguracion «GUI» Usuario Figura 22: Diagrama de secuencia reconfigurar aplicaci´on 56 Consultar histórico mensaje(Datos) mostrarDatos Datos getHistorico Historico historico(parametros) :Historico «controller» consultarHistorico(parametros) :Historico «GUI» Usuario Figura 23: Diagrama de secuencia consultar hist´orico 57 JQuery JQuery [57] podr´ıa definirse como un framework o una API de funciones, su potencia, su sencillez y su car´acter de software libre han hecho crecer su popularidad enormemente en los ´ultimos a˜nos. Es uno de los complementos m´as esenciales para el desarrollo web, ya que nos facilita mucho el desarrollo de aplicaciones enriquecidas del lado del cliente, en lenguaje Javascript, lo que lo hace compatible con todos los navegadores. Bootstrap Bootstrap [58] es un framewrok front-end compuesto por un conjunto de herramientas para el dise˜no de aplicaciones web. Fue implementada por desarrolladores del equipo de Twitter, y liberada por este posteriormente en 2011 como una soluci´on de c´odigo abierto. Entre sus caracter´ısticas principales, destacan su dise˜no modular, la flexibilidad de sus componentes, sus plantillas y su compatibilidad con los diferentes navegadores. Aunque destacan muchas de sus funcionalidades, el apartado visual es una de sus grandes ventajas, proporcionando mecanismos para adaptarse a cualquier tipo de pantalla, y por consiguiente a cualquier tipo de dispositivo (m´ovil, PC, tablet, etc.). 3.4.3. Descripci´on de la soluci´on La soluci´on adoptada para la monitorizaci´on de la plataforma permite la creaci´on y el despliegue de sensores para la obtenci´on de m´etricas. Este conjunto de m´etricas van desde aquellos par´ametros de la plataforma f´ısica (M´aquina virtual), como de la plataforma software en la que se encuentre ejecut´andose el servicio, como en este caso lo es una distribuci´on linux, o una plataforma o entorno tecnol´ogico concreto como puede ser una base de datos o un servidor web. Es importante se˜nalar que esta infraestructura permite el despliegue de sensores a trav´es de servicios IaaS, pero no por ello la monitorizaci´on se realiza ´unicamente a nivel f´ısico del sistema. De esta forma, el sistema desarrollado es capaz de monitorizar a trav´es de sensores a nivel de una plataforma concreta, ya sea hardware o software, a bajo o alto nivel. Para la soluci´on final, los escenarios que se han tenido en cuenta para el despliegue y distribuci´on de aplicaciones son aquellos que nos permite la herramienta Brooklyn, junto con su librer´ıa para el despliegue. La infraestructura es capaz por tanto, de desplegar aplicaciones (y sensores) en cualquier servicio IaaS de los proveedores que implementa jclouds. Mediante Brooklyn, se han realizado una serie especificaciones de sensores en formato YAML. Estos sensores se dividen en dos tipos, sensores ssh y sensores http. El primero realiza su funci´on de recopilaci´on de datos a trav´es de comandos ssh y para su creaci´on el usuario ´unicamente deber´a introducir el tipo del mismo y el comando que desee ejecutar por consola. El segundo utiliza peticiones http a un servidor y para su especificaci´on en 64 lugar del comando a ejecutar, se requiere la direcci´on y el path del servidor y recurso de un objeto JSON. Estas especificaciones, y el conjunto de funcionalidades es proporcionada tal y como vemos en la Figura 9 mediante la plataforma de monitorizaci´on que constituye el elemento fundamental de la arquitectura del sistema. Esta plataforma ha sido desarrollada como aplicaci´on web haciendo uso de Nodejs para la creaci´on de la API REST que da soporte a las rutas que podemos ver en la Tabla 8. El usuario se comunica con esta API a trav´es de las diferentes vistas haciendo uso de un navegador web. La interfaz de la aplicaci´on es accesible desde cualquier navegador. Con el uso de Bootstrap para proporciona una interfaz limpia, intuitiva y con elementos din´amicos que resultan de ayuda a la comprensi´on de las diferentes transiciones de cada operaci´on. Adem´as, la interfaz se encuentra dise˜nada para adaptarse a cualquier tipo de pantalla (monitor, m´ovil o tablet). La l´ogica de la aplicaci´on del lado del cliente se encuentra desarrollada mediante JQuery, que es encargada de manejar los distintos flujos de informaci´on e intercambiarlos con el cliente mediante el uso de la tecnolog´ıa Ajax IX. La librer´ıa Dygraphs, permite que podamos presentar los datos obtenidos de la monitorizaci´on de una forma adecuada e interactiva. Se ha desarrollado adem´as un mecanismo para la anotaci´on y marcado de elementos relevantes en gr´aficas, as´ı como permitir indicar el conjunto de medias m´oviles con el objeto de suavizar y obtener una tendencia de la serie. Las gr´aficas, son obtenidas y alimentadas en tiempo real por el conjunto de datos obtenidos por los sensores encargados de recopilar datos a partir de m´etricas. En la creaci´on de sensores para la monitorizaci´on se han tomado como referencia de m´etricas aquellas proporcionadas por la herramienta collectl para los siguientes subsistemas: CPU, Disco, Sistema de ficheros, Memoria y Red. Tambi´en se han desarrollado, entre otros, sensores para la monitorizaci´on de los par´ametros de rendimiento de una base de datos MongoDB. Estos sensores se han especificado como de tipo ssh, tal y como se comento anteriormente, y por ello ser´an interpretables por la API de Brooklyn para su despliegue. Adem´as de estos sensores proporcionados por el sistema, cada usuario puede especificar y almacenar su propia colecci´on de sensores, que ser´an solo visibles desde su sesi´on. La base de datos MongoDB que forma parte de la arquitectura del sistema, es la encargada del almacenamiento de todos los objetos de los cuales har´a uso la aplicaci´on. Entre ellos se incluyen aquellos especificados en la Figura 24. Para la puesta en marcha del sistema en producci´on, la base de datos contar´a con el conjunto de especificaciones de los sensores nombrados con anterioridad, que ser´an accesibles y seleccionables por cualquier usuario para su despliegue. Como se puede observar en la Figura 9, la funcionalidad aportada va a permitir a un usuario avanzado (a la derecha de la imagen) realizar la especificaci´on tanto de aplicaciones como de componentes para su posterior despliegue en diferentes proveedores de IXAjax - https://es.wikipedia.org/wiki/AJAX 65 Nubes (que ser´an descritos en la especificaci´on) a trav´es de la API de Brooklyn. Posteriormente, un usuario no t´ecnico o directivo podr´ıa ser capaz de interpretar y analizar estos resultados (parte superior de la imagen) y tomar decisiones sobre la configuraci´on de sus servicios en base a determinados requisitos. Estas decisiones, pueden ser notificadas al usuario avanzado con el objetivo de que realiza las reconfiguraciones necesarias, y tras esto, el usuario directivo puede observar mediante la presentaci´on de los resultados de forma visual y gr´afica el cambio en el estado de sus servicios seg´un los diferentes sensores que desee observar. De igual forma, es posible que se desee notificar por parte del directivo al personal t´ecnico la necesidad de observar otro tipo de m´etrica. Esto conllevar´a de nuevo la necesidad de especificaci´on por parte del t´ecnico de nuevas especificaciones de sensores que podr´an proporcionar nuevas m´etricas para su visualizaci´on. Este ciclo se repite y proporciona la capacidad no s´olo de observar y decidir en tiempo real, si no que cualquier usuario va a disponer de los datos monitorizados almacenados en el hist´orico para su consulta. El conjunto de mensajes y operaciones intercambiadas entre los usuarios y los servicios se realiza a trav´es de la API de Brooklyn y de forma transparente al usuario. El uso de interfaces gr´aficas adecuadas y una presentaci´on de la informaci´on intuitiva permite a cada tipo de usuario comprender y seguir el flujo de los procesos y datos en el sistema. Un ejemplo de especificaci´on de una aplicaci´on lo podemos ver en la Figura 27. El despliegue, monitorizaci´on y reconfiguraci´on de servicios es tambi´en realizada a trav´es de la interfaz gr´afica como vemos en las Figuras 29, 31 y 37 de forma que esta informaci´on ser´a enviada a trav´es de la API de Brooklyn para que se ejecute la acci´on o proceso pertinente. A continuaci´on en la Tabla 8 se detallan las diferentes rutas REST de acceso a los recursos del sistema. En la descripci´on de cada ruta se especifica el tipo de recurso que es devuelto o se env´ıa al servidor Nodejs por parte del cliente. En el caso de las vistas, es el usuario el que accede a ellas a trav´es del men´u. En el resto de los casos, estas rutas son manejadas por la l´ogica que se ejecuta en el cliente navegador y act´uan de forma transparente al usuario conforme ´este navega por los diferentes men´us interactivos o realiza operaciones mediante formularios. 66 M´etodo URI Descripci´on GET / Acceso al sistema* POST /login Inicio de sesi´on de usuario GET /user/profile Vista Perfil del usuario POST /user/profile/modusr Modificaci´on de nombre de usuario POST /user/profile/modpass Modificaci´on de contrase˜na de usuario POST /user/new Creaci´on de un nuevo usuario (administrador**) POST /user/del/<id usuario>Eliminar usuario (administrador**) GET /user/settings Vista Configuraci´on del usuario POST /user/settings/brooklyn Modificaci´on de configuraci´on de la m´aquina Brooklyn GET /user/brooklyn Vista de despliegue POST /user/brooklyn/deploy Despliegue de una especificaci´on GET /user/sensors Vista de sensores POST /user/sensors/search B´usqueda de sensores POST /user/sensors/del/<id sensor>Eliminar un sensor POST /user/sensors/new Creaci´on de un sensor GET /user/monitoring Vista de monitorizaci´on GET /user/brooklyn/apps Lista de jer´arquica de aplicaciones desplegadas GET /user/brooklyn/entity/<id app>/<id entity>Devuelve la entidad concreta GET /user/brooklyn/sensorvalues/<id app>/<id entity>Devuelve los valores de los sensores correspondientes a esa entidad GET /user/brooklyn/sensor/<id app>/<id entity>/<sensor>Devuelve el valor de un sensor GET /user/brooklyn/effectors/<id app>/<id entity>/ Devuelve la lista de effectors de la entidad POST /user/brooklyn/sensor/<id app>/<id entity>/<effector>Ejecuta un effector GET /user/historical Vista de hist´orico POST /user/historical/search B´usqueda en el hist´orico POST /user/brooklyn Vista de monitorizaci´on GET /logout Cierre de sesi´on de usuario Tabla 8: conjunto de recursos de la REST API del sistema *Acceso a la vista principal si el usuario se encuentra autenticado, en caso contrario se redirige a /login. **En estos casos el sistema devuelve un error de Permiso Denegado (403) si el usuario no se encuentra autorizado para realizar esta acci´on. 67 4. Resultados y Pruebas de an´alisis Con la puesta en marcha de la infraestructura en el servidor de producci´on, y los distintos elementos que la componen, se han realizado una serie de pruebas y casos de uso reales de despliegue y gesti´on de aplicaciones distribuidas para su monitorizaci´on. Para las distintas operaciones de despliegue y pruebas se ha tomado como ejemplo una aplicaci´on web que implementa un simple Chat sobre un servidor JBoss, junto con una base de datos MySQL. Su especificaci´on en formato YAML puede verse en la Figura 27. Como puede observarse en esta figura, el servidor se encuentra sobre un cluster que hace uso de un balanceador de carga nginx. My Web Cluster My Web JBoss7Server NginxController My DB name: My Web Cluster location: localhost services: - serviceType: brooklyn.entity.webapp.ControlledDynamicWebAppCluster name: My Web id: web brooklyn.config: wars.root: "http://search.maven.org/remotecontent?filepath=io/brooklyn/example /brooklyn-example-hello-world-sql-webapp/0.7.0-M1/brooklyn-example-hello-world -sql-webapp-0.7.0-M1.war" java.sysprops: brooklyn.example.db.url: "$brooklyn:formatString(\"jdbc:%s%s?user=%s\\\\& password=%s\", component(\"db\").attributeWhenReady(\"datastore.url\"), \"visitors\", \"brooklyn\", \"br00k11n\")\n" - serviceType: brooklyn.entity.database.mysql.MySqlNode id: db name: My DB brooklyn.config: creationScriptUrl: "https://bit.ly/brooklyn-visitors-creation-script" Figura 27: Especificaci´on de aplicaci´on web de Chat en formato YAML y la estructura generada en Brooklyn La informaci´on sobre la localizaci´on de los elementos puede describirse tanto para cada uno de ellos como para la aplicaci´on completa. 68 Para la selecci´on y configuraci´on de sensores, el sistema implementa un sistema interactivo que permite a˜nadir aquellos sensores que deseemos para cada una de las localizaciones. De esta forma si se desea a˜nadir una serie de sensores a una localizaci´on concreta que ya se encuentra ejecutando alguna aplicaci´on que deseamos monitorizar, simplemente podemos a˜nadir una especificaci´on con su localizaci´on o localizaciones, que ser´an detectadas y mediante el men´u podremos seleccionar los elementos que queramos desplegar. En la figura 28 podemos encontrar una descripci´on del procedimiento para la especificaci´on de sensores en varias localizaciones. Sensores desplegados en una instancia de amazon ec2 en la región de Irlanda Sensores desplegados en la máquina con ip 192.168.0.18 Sensores desplegados en la máquina local Sensores para jclouds Sensores para byon Sensores para localhost Entidad de Monitorización locations: - localhost - location: byon: user: root privateKeyFile: ~/.ssh/id_rsa hosts: - 192.168.33.24 - jclouds:aws-ec2: region: eu-west-1 identity: AKA_YOUR_ACCESS_KEY_ID credential: <access-key-hex-digits> Figura 28: Especificaci´on de localizaciones en formato YAML y despliegue de sensores Para el caso de la aplicaci´on web de chat, se ha realizado distribuyendo los componentes de la siguiente forma: Componente web: desplegado en m´aquina local Componente de base de datos: desplegado en una instancia de tipo t1.micro en el servicio Amazon EC2 en la regi´on de Irlanda (eu-west) Las Figuras 29 a 34 muestran el procedimiento de despliegue del caso de uso, y los datos obtenidos por la monitorizaci´on de los par´ametros de CPU y de peticiones a la base de datos y al servidor web. La aplicaci´on, ha sido sometida a valores de estr´es con el fin de mostrar su comportamiento en diferentes condiciones. Estas condiciones de estr´es se 69 han realizado mediante la inserci´on continuada de mensajes en la aplicaci´on de chat, cuya interfaz podemos observar en la Figura 35. La Figura 36 muestra las instancias que se encuentran ejecut´andose en la consola de Amazon EC2, para ello se ha creado previamente un usuario en los servicios de Amazon, cuyas credenciales han sido especificadas para el despliegue. Por ´ultimo se ilustran las consultas realizadas a posteriori sobre los datos de monitorizaci´on recogidos, estos valores se pueden filtrar seg´un diferentes condiciones de fecha y hora, tipo de m´etrica, as´ı como rango del propio valor. En las Figuras 38 a 40 se pueden comprobar los resultados obtenidos mediante consultas. Los resultados obtenidos, tanto en tiempo real como a posteriori, nos muestran informaci´on acerca de como se est´a comportando nuestro servicio. La facilidad para especificar nuevos sensores para una localizaci´on y para definir esta recogida de datos para casi cualquier m´etrica existente constituye una garant´ıa para poder tomar decisiones robustas. Este sistema,da soporte tanto a la fase de desarrollo como a la de producci´on de servicios o aplicaciones distribuidas. De esta forma, una entidad u organizaci´on puede usar el entorno para realizar testing sobre el comportamiento de sus sistemas antes de realizar el despliegue. Posteriormente tambi´en puede monitorizar de forma robusta su aplicaci´on y poder decidir que datos desea recopilar y en que momento, mediante el despliegue de estos sensores de forma din´amica. Todos los datos recopilados pueden ser susceptibles de an´alisis en tiempo real mediante la representaci´on gr´afica, y a lo largo de un periodo de tiempo mediante la consulta al hist´orico. Estas dos modalidades de an´alisis, permiten la toma de decisiones a nivel de negocio y a nivel operativo tanto a en tiempo real, como a medio y largo plazo. La presentaci´on de los datos resulta adecuada tanto para usuarios t´ecnicos como para aquellos no especializados. La capacidad para la definici´on de sensores de alto nivel, ayuda a acercar este tipo de sistemas a lo largo del nivel directivo. Este acercamiento facilita la comprensi´on y la rotura de la brecha existente entre el personal m´as t´ecnico y el personal de direcci´on encargado de la toma de decisiones. Por lo tanto, con la adopci´on de esta infraestructura, las entidades pueden ver cubiertas sus necesidades operativas y de negocio a trav´es de todo el ciclo de vida tanto de desarrollo, como producci´on y mantenimiento de sus aplicaciones en la Nube. 70 Figura 29: Especificaci´on de servicios y selecci´on de sensores para despliegue 71 Figura 30: Informaci´on acerca del estado de los servicios desplegados 72 Figura 31: Monitorizaci´on de CPU en instancia de amazon y en instancia local 73 Figura 39: Consulta de datos en hist´orico sobre los valores recogidos de consultas a la base de datos 80 Figura 40: Consulta de datos en hist´orico sobre los valores recogidos de peticiones al servidor web 81 5. Conclusiones El car´acter novedoso de la computaci´on en la Nube hace que cualquier trabajo que se desarrolle en su ´ambito tenga una carga importante de estudio e investigaci´on. A lo largo de esta memoria se ha tratado de dar una visi´on lo m´as amplia posible del abanico de posibilidades, tecnolog´ıas y estudios sobre la computaci´on en la Nube centrada principalmente en monitorizaci´on de aplicaciones distribuidas y gesti´on e interoperabilidad en entornos multi-cloud. Dados los avances, oportunidades de negocio y oportunidades de investigaci´on que ofrecen estos elementos no resulta f´acil saber cu´al ser´a la l´ınea futura. Lo que s´ı parece claro es que el uso de la Nube ir´a incorpor´andose paulatinamente con m´as fuerza en el mundo empresarial. El avance de las redes de comunicaciones y el grado de acogida a est´andares por parte de los proveedores, van a determinar en qu´e medida las empresas y organizaciones pueden delegar sus servicios y confiar en la Nube. Mediante el desarrollo de esta infraestructura, se ha proporcionado un mecanismo de monitorizaci´on y gesti´on de servicios distribuidos en un entorno multi-cloud. La soluci´on adoptada para su implementaci´on permite la adaptaci´on a diferentes entornos que pueden cubrir un gran n´umero de necesidades, que van desde el n´umero de proveedores o tecnolog´ıas soportadas por la API de despliegue, la capacidad para definici´on nuevos sensores, reconfiguraci´on de servicios, o la capacidad de an´alisis a trav´es de las herramientas gr´aficas proporcionadas. As´ı, una empresa que desee desplegar sus servicios en la nube, puede lograr obtener una soluci´on integrada a trav´es de ´este sistema ahorrando en el uso de recursos de computaci´on pudiendo controlar y monitorizar el estado de sus sistemas. El fruto de este trabajo pretende aportar una ventaja a˜nadida al despliegue de aplicaciones y servicios en la Nube, y servir como base para el desarrollo de nuevas iniciativas que traten de acercar este nuevo paradigma de la Computaci´on en la Nube como un servicio cercano y del cual se pueden obtener numerosos beneficios, que van m´as all´a de los recursos econ´omicos. El uso del sistema puede ser de gran ayuda para asistir al ciclo de vida del desarrollo y mantenimiento de software, usando la Nube como infraestructura para el despliegue de sus servicios a trav´es de nuestra infraestructura pudiendo beneficiarse de la retroalimentaci´on obtenida en base a an´alisis de los datos monitorizados, y disponer as´ı de fundamentos robustos para verificar el cumplimiento de requisitos y apoyar la toma de decisiones. La monitorizaci´on juega, y va a seguir jugando, un papel clave en este entorno. La p´erdida de control sobre la infraestructura por parte del cliente debe equilibrarse correctamente con estas medidas de supervisi´on que permitan comprobar la QoS y ser una garant´ıa de cumplimiento de los SLA. Este hecho cobra a´un mayor relevancia cuanto m´as avanzamos en la pir´amide de abstracci´on y menos sabemos sobre la infraestructura donde operan nuestros servicios. Los proveedores deben no s´olo garantizar el cumplimento de los SLA, sino ofrecer interfaces para el acceso a servicios de monitorizaci´on con el objetivo de poder obtener valores reales y fiables. Todo ello con independencia de la capa servicio de la Nube en la que nos encontremos. 82 Lograr la confianza de las empresas y usuarios no vinculados al sector de las TIC’s, es otro motivo para el fomento de este tipo de medidas. Fortalecer esta confianza va a pasar no solo por asegurar con garant´ıas las condiciones de los servicios, sino tambi´en por poner a disposici´on de los usuarios herramientas de alto nivel accesibles a cualquier tipo de p´ublico. De esta forma, ser´an capaces de verificar, gestionar y comprobar el correcto funcionamiento de sus sistemas. 5.1. Trabajos futuros El enfoque adoptado para el desarrollo de la infraestructura, hace que se encuentre en un grado de madurez en el cu´al es posible su explotaci´on en la actualidad. Tanto como elemento para el despliegue y gesti´on, como herramienta para monitorizaci´on de aplicaciones y servicios en la Nube, puede proporcionar una soluci´on integrada. Adem´as, el hecho de contar con tecnolog´ıas en pleno auge como Brooklyn, jclouds, Nodejs, o MongoDB, hace que con un mantenimiento evolutivo las mejoras que se implementaran en estas tecnolog´ıas se vieran reflejadas en un aumento de las capacidades y rendimiento de nuestro sistema. Lograr una mayor abstracci´on en el dise˜no, podr´ıa ser una posible ´area en la que mejorar el sistema y as´ı acercarlo a un p´ublico menos especializado. De igual forma, su integraci´on con otras herramientas existentes en el desarrollo de aplicaciones, tales como IDEs supondr´ıa un gran avance y una forma de potenciar su uso. Otra posible forma de mejorar su potencial, ser´ıa mediante la creaci´on de componentes para predecir los cambios en los servicios desplegados a trav´es de los datos recopilados. En este sentido, un ´area a´un por explotar y con mucho futuro como la inteligencia empresarial o business intelligence, es un marco de trabajo que resulta muy interesante y en el que podr´ıan converger sistemas monitorizaci´on y an´alisis formando una estructura completa que aporte “inteligencia” al negocio. Finalmente, tambi´en se debe mencionar que la creaci´on e inserci´on de nuevos sensores en nuestro sistema, se puede traducir en un aumento de las prestaciones del sistema, disponiendo as´ı de un mayor n´umero de m´etricas disponibles que pueden dar cobertura a los requisitos de los potenciales usuarios. 83 Referencias [1] Real Academia Espa˜nola. (2014). Diccionario de la lengua espa˜nola (23.a ed.). Consultado en http://www.rae.es/ [2] HarperCollins. (2011). Collins English Dictionary. Consultado en http://www. collinsdictionary.com/ [3] Cambridge University Press. (2015). Cambridge dictionaries online. Consultado en http://dictionary.cambridge.org [4] J.McCarthy, “Reminiscences on the History of Time Sharing”, Standford University, 1983. [5] R. Buyya, et al., Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility, Future Generation Computer Systems, 2009. [6] Wikipedia, Virtual Storage Personal Computing. Wikimedia Foundation, Inc. 21 January 2008. [7] Qusay F. Hassan, “Desmystifying Cloud Computing”, Faculty of Computers and Information, Mansoura University, Egypt , 2011. [8] P. Mell and T. Grance, The NIST Definition of Cloud Computing, Special Publication 800-145, National Institute of Standards and Technology, Gaithersburg, Maryland, 2011. [9] Srinivas Rao V,Nageswara Rao N K ,E Kusum Kumari, Cloud Computing : An Overview, JATIT, Nov 2009, www.jatit.org [10] Toby Velte, Anthony Velte, Robert Elsenpeter, Cloud Computing, A Practical Approach, McGraw-Hill, Inc., New York, NY, 2009 [11] Open source software for creating private and public clouds. https://www.openstack. org/ [12] NYSE Technologies Launches Global CloudBased ‘Capital Markets Community Platform” http://www.vmware.com/files/pdf/customers/ VMware-NYSE-Technologies-12Q2-EN-Case-Study.pdf [13] Dimitris Zeginis, Francesco D’Andria, Stefano Bocconi, Jesus Gorronogoitia Cruz, Oriol Collell Martin, Panagiotis Gouvas, Giannis Ledakis, Konstantinos, A. Tarabanis. A user-centric multi-PaaS application management solution for hybrid multiCloud scenarios. Scalable Computing: Practice and Experience, 2013. [14] N. Grozev, R. Buyya, “Inter-Cloud architectures and application brokering: Taxonomy and survey”, Software Practice and Experience, vol. 44, pp. 369–390, 2014. 84 [15] B. Kezia Rani, B. Padmaja Rani, Dr., A. Vinaya Babu, Dr., “Cloud Computing and Inter-Clouds – Types, Topologies and Research Issues”, Procedia Computer Science, vol. 50, pp. 24–29, 2015. [16] Contrail Project - A European Cloud Federation, IaaS, PaaS project. http:// contrail-project.eu/ [17] Optimis Project - Optimized Infrastructure Services. http://www.optimis-project. eu/ [18] mOSAIC Project - Open-Source API and Platform for Multiple Clouds. http://www. mosaic-project.eu/ [19] Apache Stratos - Open source polyglot Platform as a Service (PaaS) framework. http://stratos.apache.org/ [20] OpenTOSCA - Open Source TOSCA Ecosystem. http://www.iaas.uni-stuttgart.de/ OpenTOSCA/ [21] MODAClouds - MOdel-Driven Approach for design and execution of applications on multiple Clouds. http://www.modaclouds.eu/ [22] SeaClouds - Seamless adaptive multi-cloud management of service applications. http: //www.seaclouds-project.eu/ [23] Apache Brooklyn open source project. http://brooklyn.incubator.apache.org/ [24] Apache jclouds - The Java Multi-Cloud Toolkit. http://jclouds.apache.org/ [25] Apache Libcloud - Python library for interacting with many of the popular cloud service providers using a unified API. https://libcloud.apache.org/ [26] Apache DeltaCloud https://deltacloud.apache.org/ [27] SimpleCloud API https://en.wikipedia.org/wiki/Simple Cloud API [28] Apache Nuvem http://wiki.apache.org/incubator/Nuvem [29] Zend Cloud http://framework.zend.com/manual/1.12/en/zend.cloud.html [30] K. Oberle, G. Gallizo, R. Kuebert, E. Oliveros, Enhancing the SLA Framework of a Virtualized Service Platform by dynamic renegotiation, eChallenges2010, Warsaw, Poland, October 2010. [31] Cloud Computing Use Cases Group, Cloud computing use cases white paper, July 2010 http://www.cloud-council.org/Cloud Computing Use Cases Whitepaper-4 0. pdf [32] D Ardagna, G Casale, M Ciavotta, JF P´erez, W Wang, Quality-of-service in cloud computing: modeling techniques and their applications, Journal of Internet Services and Applications, 5(1), 1-17, 2014. 85 [33] Jeffrey J.P.Tsai, Steve J.H.Yan, Monitoring and Debugging of Distributed and RealTime Systems, IEEE Computer Society Press, 1995. [34] M. Zu˜niga-Prieto, P. Cedillo, J. Gonz´alez-Huerta, E. Insfr´an, and S. Abrah˜ao, “Monitoring Services Quality in the Cloud”, ERCIM News 2014, Vol. 99, Special Theme on Software Quality, 2014. [35] Giuseppe Cicotti , Luigi Coppolino , Rosario Cristaldi , Salvatore D´ Antonio , Luigi Romano, QoS monitoring in a cloud services environment: the SRT-15 approach, Euro-Par Workshops (1), volume 7155 of Lecture Notes in Computer Science, page 15-24. Springer, 2011. [36] VC Emeakaroha, I Brandic, M Maurer, S Dustdar, Low Level Metrics to High Level SLAs-LoM2HiS framework: Bridging the gap between monitored metrics and SLA parameters in Cloud environments, The 2010 High Performance Computing and Simulation Conference (HPCS), 2010. [37] Amazon CloudWatch http://aws.amazon.com/es/cloudwatch/ [38] AzureWatch https://www.paraleap.com/AzureWatch [39] CloudKick https://en.wikipedia.org/wiki/Cloudkick [40] Google Cloud Monitoring https://cloud.google.com/monitoring/ [41] HP Cloud Monitoring http://www.hpcloud.com/products-services/monitoring [42] Zenoss Cloud http://www.zenoss.com/solution/cloud-monitoring [43] vRealize Hyperic http://www.vmware.com/es/products/vrealize-hyperic [44] Ganglia Monitoring System http://ganglia.sourceforge.net/ [45] Nagios https://www.nagios.com/products [46] collectl http://collectl.sourceforge.net/ [47] collectd https://collectd.org/ [48] OpenNMS http://www.opennms.org/ [49] Zabbix http://www.zabbix.com/ [50] WebStorm https://www.jetbrains.com/webstorm/ [51] Git http://git-scm.com/ [52] Bitbucket https://bitbucket.org/ [53] Nodejs https://Nodejs.org/ 86 [54] Express http://expressjs.com/ [55] MongoDB https://www.mongodb.org// [56] Dygraphs http://dygraphs.com/ [57] JQuery https://jquery.com/ [58] Bootstrap http://getbootstrap.com/ [59] YAML: YAML Ain’t Markup Language http://yaml.org/ [60] Cloud Application Management for Platforms Version 1.1 Committee Specification 01, OASIS, 2014,http://docs.oasis-open.org/camp/camp-spec/v1.1/camp-spec-v1.1. html 87 Anexo I. Descripci´on t´ecnica del equipo servidor Informaci´on del equipo: Procesador : 4x Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz Memoria : 3928MB Disco : Familia: Seagate Barracuda 7200.14 (AF) Modelo: ST2000DM001-1CH164 Capacidad: 2,00 TB Veri´on SATA: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Informaci´on del sistema operativo: ID Distribuidor: Debian Descripci´on: Debian GNU/Linux 8.1 (jessie) Release: 8.1 Codename: jessie Detalles del Kernel: Linux servidor 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux 88 Anexo II. Instrucciones de instalaci´on Para la puesta en producci´on de la infraestructura ser´a necesario en primer lugar la instalaci´on de los siguientes elementos: Apache Brooklyn Nodejs MongoDB Se detallar´an los pasos necesarios para la instalaci´on en distribuciones linux basadas en Debian. Instalaci´on de Apache Brooklyn Para la instalaci´on y configuraci´on, y puesta en marcha de Apache Brooklyn, se puede consultar la p´agina web del proyecto [23], en la que se detalla de forma adecuada los pasos necesarios. Nodejs Para la instalaci´on de Nodejs, abre una consola y ejecuta los siguientes comandos: sudo apt−get i n s t a l l python−software−properties sudo apt−get update sudo apt−get i n s t a l l nodejs npm MongoDB Para la instalaci´on de MongoDB, abre una consola y ejecuta los siguientes comandos: curl −O https :// f a s t d l . mongodb . org / linux /mongodb−linux−x86 64 −3.0.4. tgz tar −zxvf mongodb−linux−x86 64 −3.0.4. tgz cd /opt mkdir −p mongodb cp −R−n mongodb−linux−x86 64 −3.0.4/ mongodb echo ” export PATH=/opt/mongodb/ bin :$PATH” >> /home/<usuario >/. bashrc source /home/<usuario >/. bashrc #crear d i r e c t o r i o de datos mkdir −p /data/db #i n i c i a r mongo mongod 89