MAGOSCLOUD: PLATAFORMA DECLARATIVA,
OPORTUNISTA, ALTAMENTE ESCALABLE PARA
INFORMACIÓN Y SERVICIOS WEB 2.0
CHRISTIAN FERNANDO ARIZA PORRAS
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C.
MAGOSCLOUD: PLATAFORMA DECLARATIVA,
OPORTUNISTA, ALTAMENTE ESCALABLE PARA
INFORMACIÓN Y SERVICIOS WEB 2.0
CHRISTIAN FERNANDO ARIZA PORRAS
Tesis de Grado presentada como requisito para optar al título de Magíster en Ingeniería de Sistemas y Computación
Director: Claudia Lucía Jiménez Guarín Profesor Asociado
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C.
CONTENIDO
1 Introducción ... 8
1.1 Grid vs Cloud ... 10
1.2 El proyecto Magos y su evolución hacia MagosCloud... 11
1.3 Definición del problema ... 11
1.4 Objetivos ... 12
1.4.1 Objetivo General ... 12
1.4.2 Objetivos específicos ... 12
2 Estado Del Arte ... 13
2.1 CloudComputing ... 13
2.1.1 Infraestructura como servicio ... 13
2.1.2 Plataforma como Servicio ... 15
2.1.3 Cloud Middleware ... 15
2.2 MapReduce... 15
3 Estrategia de solución ... 18
3.1 Casos de uso ... 20
3.2 Lenguaje declarativo de MagosCloud ... 21
3.3 Decisiones de diseño ... 22 3.4 Arquitectura Propuesta ... 24 4 Diseño ... 25 4.1 Modelo de componentes ... 25 4.1.1 Vista General ... 25 4.1.2 MCNode ... 25 4.1.3 MCVMInstance ... 26 4.1.4 MCServer ... 27 4.1.5 MCLoadBalancer ... 28 4.2 Diagrama de Despliegue ... 29 4.3 Diagramas de Secuencia ... 30 4.3.1 Instanciación de Plataforma ... 30 4.3.2 Desplegar Aplicación ... 31
5 Implementación y pruebas ... 32
5.1 Flujo de control y componentes de MagosCloud ... 33
5.2 Estrategias y configuraciones de las plataformas soportadas ... 39
5.2.1 Apache HA ... 39 5.2.2 Tomcat HA ... 39 5.2.3 MySql HA ... 39 5.2.4 Hadoop-HBase ... 39 5.2.5 Servidor de Archivos ... 39 5.2.6 Base de datos XML ... 39
5.3 Diseños y Resultados de Pruebas ... 40
5.4 Análisis de resultados ... 45
6 Conclusiones y trabajo futuro ... 48
7 Referencias ... 50
Anexo A: Casos de Uso ... 56
Anexo B: Manual de Instalación de MagosCloud ... 60
MagosCloud Server ... 60 Requerimientos: ... 60 Procedimiento de Instalación. ... 60 MagosCloud LoadBalancer ... 61 Requerimientos ... 61 Procedimiento de instalación ... 61 MagosCloud MCNode ... 61 Requerimientos ... 61 Procedimiento de instalación ... 61
Anexo C Primeros pasos con Hadoop ... 62
Mordiendo Hadoop: Instalación y primeras pruebas ... 62
Mordiendo Hadoop: Instalación en Cluster ... 65
Modiendo Hadoop: Desarrollo de aplicaciones MapReduce ... 70
Configuración del entorno de desarrollo ... 71
INDICE DE FIGURAS
Ilustración 1 Principios de MagosCloud ... 9
Ilustración 2 Clasificación de servicios Cloud y visibilidad de valor para el usuario final [75] ... 9
Ilustración 3 Estrategia de implementación ... 19
Ilustración 4 Diagrama general casos de uso ... 20
Ilustración 5 Esquema del lenguaje definido ... 21
Ilustración 6 Ejemplo de solicitud de plataforma ... 22
Ilustración 7 Diagrama general arquitectura MC ... 24
Ilustración 8 Magos Cloud Componentes ... 25
Ilustración 9 Componente MCNode ... 26
Ilustración 10 Componente MCVMInstance ... 26
Ilustración 11 Componente MCServer ... 27
Ilustración 12 Componente MCLoadBalancer ... 28
Ilustración 13 Diagrama de despliegue ... 29
Ilustración 14 Instanciar Plataforma (Diagrama de secuencia) ... 30
Ilustración 15 Desplegar Aplicación ... 31
Ilustración 16 Estructura del proyecto para el módulo StatusReporter ... 32
Ilustración 17 Diagrama de Actividades Solicitud a MagosCloud ... 33
Ilustración 18 Estructura del proyecto para el módulo MCServer ... 34
Ilustración 19 Estructura del proyecto para el módulo MCBalanceador ... 35
Ilustración 20 Estructura del proyecto para el módulo MCNode ... 35
Ilustración 21 Estructura del proyecto para el módulo MCMVInstance ... 36
Ilustración 22 Estructura del proyecto para el módulo MCPuppetEN ... 36
Ilustración 23 Estructura del proyecto Util ... 37
Ilustración 24 Modelo de datos para MCServer ... 37
Ilustración 25 Modelo de datos MCLoadBalancer ... 38
Ilustración 27 Número de muestras por segundo, mayor es mejor. ... 43 Ilustración 28 Porcentaje de error reportado por Jmeter. ... 43
INDICE DE CUADROS
Tabla 1 Atributos de calidad requeridos frente a diferentes alternativas ... 17
Tabla 2 Decisiones de diseño ... 23
Tabla 3 Pruebas Funcionales ... 41
Tabla 4 Prueba de carga – Apache -Mysql ... 44
8
1
Introducción
El término Web 2.0 es asociado con servicios que han tomado protagonismo durante la primera década del siglo XXI, donde el contenido generado por el usuario es la norma y que son mejores cuantos más usuarios lo usan [67]. En la segunda década del siglo XXI los servicios Web 2.0 buscan, además de la generación de contenido por parte del usuario, la personalización y la agregación de contenido, aplicaciones tipo mashup1, que manejan un alto volumen de datos y que buscan adaptarse al usuario, sus necesidades y su contexto. Estos servicios tienen en común la necesidad de la capacidad de escalar, pueden pasar de unos pocos usuarios a millones en muy poco tiempo gracias al efecto red, y el manejo de grandes cantidades de datos.
La infraestructura necesaria para dar soporte a la escalabilidad que requiere este tipo de servicios implica una inversión, en capacidad de cómputo y espacio de almacenamiento, así como de expertos para configurar plataformas para entornos de alta disponibilidad y alto desempeño. Los recursos de cómputo son limitados y la configuración de las plataformas requiere tiempo y conocimiento.
El problema de la escalabilidad para las aplicaciones de e-ciencia y la Web 2.0 ha sido enfrentado de diferentes formas, con el objetivo compartido de reducir costos y aumentar la flexibilidad. El paradigma Cloud Computing [37], está fuertemente ligado a los paradigmas Grid Computing [35] y Utility Computing [69], toma de ellos estrategias y objetivos, abstrae la complejidad de la infraestructura, es impulsado por economías de escala, dinámicamente escalable y dirigido hacia Internet. Las soluciones de tipo Cloud Computing tienen como objetivo la personalización y uso de infraestructura, software y aplicaciones, como servicios enfocados en la facilidad de uso [74].
El desarrollador enfrenta retos, más allá de la funcionalidad de su servicio, que involucran una curva de aprendizaje al tener que preocuparse por los recursos de hardware, la escalabilidad de las fuentes de datos y del servidor de aplicaciones, la configuración de plataformas para procesamiento de grandes cantidades de datos de manera distribuida, el uso eficiente de los recursos. Fuentes de datos heterogéneas y diferentes tipos de servidores de aplicaciones son comunes en este tipo de servicios. Este trabajo presenta MagosCloud, una solución que ayuda al desarrollador a enfrentar estos retos, ofreciéndole una plataforma declarativa,
1En este documento se utiliza terminología técnica en inglés. Algunas palabras como Grid, Cloud,
middleware, map, reduce, hypervisor, mashup, entre otras se mantienen intencionalmente en éste idioma, dado que son consideradas como de uso común dentro del dominio.
9
oportunista y extensible, que le oculta la complejidad del manejo de infraestructura y escalabilidad.
Ilustración 1 Principios de MagosCloud
Las soluciones que implementan el paradigma Cloud Computing se clasifican frecuentemente de acuerdo con su usuario objetivo y el valor que aportan al usuario final (Ilustración 2). Se identifican tres tipos de soluciones: Infraestructura como Servicio (IaaS), Plataforma como Servicio (PaaS) y Software como Servicio (SaaS) [75].
10
Proveedores como Amazon [8], Google [25], WSO2 [81], entre otros han desarrollado servicios que implementan el paradigma Cloud Computing, haciendo cada vez más común su uso en entornos personales y empresariales.
En el caso de los servicios de Amazon (EC2, S3, EBS), se han centrado en proveer Infraestructura como Servicio (IaaS), que puede ser usada de manera declarativa usando AWS CloudFormation. Amazon, además, provee Elastic Load Balancing para balancear la carga entre las instancias de Amazon EC2 en una o varias zonas de disponibilidad.
Google App Engine [25], la apuesta de Google de plataforma como servicio, ofrece al desarrollador una plataforma donde desplegar aplicaciones en un entorno java, Python o Go, en la infraestructura de Google. Ofrece dos tipos de repositorios de aplicaciones, High Replication Datastore (HRD) y Master/Slave, que se diferencian por las garantías de consistencia y confiablidad.
Estas soluciones resuelven problemas similares, sin embargo no cumplen con los atributos de calidad buscados por MagosCloud. Los objetivos de MagosCloud están fuertemente ligados con los paradigmas Cloud Computing y Grid Computing, a continuación se discute su definición y relación.
1.1
Grid vs Cloud
La definición de Grid computing puede ser expresada por tres puntos principales, “permitiendo compartir recursos y resolución coordinada de problemas en organizaciones virtuales dinámicas y multi-institucionales” [35]:
• Recursos coordinados sin estar sujetos a un control centralizado, diferentes dominios administrativos.
• Uso de protocolos e interfaces estándar, abiertos y de propósito general. No son sistemas específicos a una aplicación.
• Entrega niveles de calidad de servicio no triviales.
Aunque Grid Computing y Cloud Computing comparten muchos de sus objetivos, las implementaciones y características fundamentales son diferentes. Estas diferencias se hacen explícitas en la definición de Cloud Computing dada por [37], que traslapa varios modelos como Utility Computing, Services Computing y Grid Computing: “Un paradigma de computación distribuida a gran escala impulsado por economías de escala, en el cual un grupo de poder de computo, almacenamiento, plataformas y servicios administrados, de algo nivel, virtualizados, dinámicamente escalables, son entregados por demanda a clientes externos sobre Internet.”
11
Cloud Computing no sólo comparte objetivos con Grid Computing, su infraestructura se basa en ella. La evolución se ha dado entre el modelo de compartir poder de cómputo y espacio de almacenamiento a un modelo basado en economía, donde lo que se comparte son recursos y servicios más abstractos. Estas diferencias ponen sobre la mesa varios nuevos retos y oportunidades para el desarrollo y uso de servicios, plataforma o infraestructura bajo el paradigma Cloud [16].
1.2
El proyecto Magos y su evolución hacia MagosCloud
El proyecto Magos (Middleware Architecture for Grid Oriented Services) “ofrece al desarrollador de aplicaciones orientadas a servicios (SOA) la posibilidad de describir de forma declarativa los requerimientos no funcionales que espera de un grid, indicando los recursos necesarios, características de privacidad, replicación de servicios y de fuentes de datos” [47].
El objetivo de Magos es reducir la curva de aprendizaje para el desarrollador SOA y facilitar la instalación y cooperación de aplicaciones autónomas en el grid. Magos abstrae la complejidad de creación de un servicio de datos, instalación de un servicio, manejo de replicación, manejo de autorización y seguridad, manejo de servicios complejos y dependencias, consulta de servicios instalados, manejo de la distribución de carga y manejo de workflow de aplicaciones [21] [44] [58] [59] [46]. Aunque Magos logra ocultar al desarrollador SOA una parte importante de la complejidad del uso del grid, el desarrollador aún debe estar consciente de las características del grid, generar un grid service en lugar de web service, generar obligatoriamente un workflow para ejecutar la aplicación, no existen facilidades para generar aplicaciones computacionalmente exigentes (con la estrategia MapReduce por ejemplo) ni soporta archivos como fuente de datos.
Retomando la discusión de la sección 1.1, la evolución de Grid a Cloud está justificada por el impulso de la economía de escala, la virtualización, la abstracción de la complejidad de los sistemas distribuidos y la posibilidad de personalización dada al usuario. Teniendo en cuenta el propósito inicial del proyecto Magos el cambio del paradigma Grid a Cloud se puede ver como una evolución, consecuente con la aproximación propuesta por Foster [37].
1.3
Definición del problema
El desarrollador de un servicio Web 2.0, además de tener en cuenta los aspectos funcionales de su aplicación, debe preocuparse de la escalabilidad y disponibilidad de la infraestructura y la configuración de las plataformas para alcanzar estos atributos, el uso eficiente de los recursos y el aspecto económico que esto implica.
12
Este trabajo ofrece una solución que permite al desarrollador, de forma declarativa, definir las plataformas requeridas y aprovechar los recursos de cómputo existentes, sin tener que lidiar con temas de configuración de plataforma y de uso de infraestructura.
MagosCloud permite al desarrollador usar las configuraciones definidas por expertos en cada plataforma y delegar el manejo de la infraestructura para alcanzar los atributos de escalabilidad y disponibilidad, dedicándose a los aspectos funcionales de su aplicación. En el presente trabajo se concibe MagosCloud y se diseña e implementa MagosCloud Core, que reúne los componentes básicos de la infraestructura diseñada.
1.4
Objetivos
1.4.1
Objetivo General
Ofrecer una plataforma, basada en el paradigma Cloud Computing, altamente escalable que provea a los desarrolladores un ambiente declarativo, configurable en términos de carga, en el cual desplegar servicios web de gran concurrencia y aplicaciones exigentes en términos de cómputo y almacenamiento.
1.4.2
Objetivos específicos
• Diseñar e implementar una plataforma que brinde de forma dinámica servicios de procesamiento y almacenamiento en contextos de alta escalabilidad.
• Diseñar una arquitectura que permita satisfacer los atributos de calidad definidos.
• Abstraer la complejidad de los sistemas altamente distribuidos para su uso por parte de los desarrolladores SOA y expertos de e-ciencia.
• Proveer una plataforma con interacción de forma declarativa, con el mínimo de curva de aprendizaje por parte del usuario sobre la plataforma y su forma de uso.
• Validar la estrategia de virtualización en soluciones de alta escalabilidad en entornos oportunistas.
• Proponer e implementar una estrategia de uso declarativa de la plataforma.
• Validar el procesamiento en contexto de fuentes heterogéneas de aplicaciones MapReduce y Web 2.0.
13
2
Estado Del Arte
Los problemas de escalabilidad, aprovechamiento de recursos y manejo de grandes cantidades de datos, han sido estudiados ampliamente en los últimos años. El paradigma Cloud Computing ha ganado especial protagonismo y es relevante para MagosCloud dados sus objetivos, retomando las secciones 1.1 y 1.2.
MagosCloud nace como la evolución del proyecto Magos. Teniendo en cuenta sus limitaciones, descritas en BioMagos [68], el framework MapReduce y sus implementaciones son relevantes en el desarrollo de MagosCloud.
A continuación se describen trabajos actuales comparables con MagosCloud en cada uno de estos aspectos.
2.1
CloudComputing
Las soluciones que implementan el paradigma Cloud Computing generalmente son clasificadas de acuerdo con la visibilidad frente al usuario final: Infraestructura como Servicio, Plataformas como Servicio y Software como Servicio. Esta división es muchas veces artificial y difusa, sin embargo nos permite comparar servicios similares teniendo un referente. Para el objetivo de este proyecto son relevantes los enfoques de Infraestructura como Servicio y Plataforma como Servicio, así como las diferentes aproximaciones que tienen a ocultar la complejidad del uso de la infraestructura Cloud.
2.1.1
Infraestructura como servicio
Elastic Site [60] provee una Infraestructura como Servicio (IaaS) basada en Nimbus [2] que da al usuario provisión automática y dinámica de recursos. Es interesante para el desarrollo de MagosCloud, dado que justifica la necesidad de aprovisionamiento dinámico de recursos, sin embargo el nivel de abstracción y los servicios ofrecidos son diferentes, dado que sólo tiene en cuenta los trabajos enviados en lotes bajo un scheduler específico.
UnaCloud [74] provee un entorno escalable, usando una estrategia oportunista, centrándose en la aproximación de Infraestructura como Servicio, dentro de su trabajo futuro se lista la necesidad de experimentar e implementar la aproximación PaaS. UnaCloud es interesante para MagosCloud como alternativa para proveer la infraestructura, MagosCloud se enfoca en la aproximación PaaS, donde la provisión de recursos se realiza teniendo en cuenta consideraciones específicas a cada plataforma. UnaCloud utiliza vmrun que, además de las funcionalidades usadas,
permite crear clones de máquinas virtuales, ejecutar aplicaciones y copiar archivos en la MV, operaciones necesarias en MagosCloud.
14
Amazon Web Services (AWS) [8] ofrece un conjunto de servicios que forman una solución tipo Infraestructura como Servicio. Amazon Elastic Compute Cloud (EC2) [4] permite desplegar instancias de máquinas, Amazon Machine Image (AMI), iniciarlas, detenerlas y monitorearlas, además de permitir aumentar o disminuir la cantidad de recursos asignados a ellas. Elastic Load Balancing [10] distribuye el tráfico entrante entre varias instancias de Amazon EC2.
Amazon S3 [6] y EBS [3] ofrecen servicios de almacenamiento. S3 permite acceder a los datos usando una interfaz sencilla desde cualquier lugar en la web. EBS ofrece volúmenes de almacenamiento para ser usados en las instancias de Amazon EC2. Amazon SimpleDB [7] y Amazon Relational Database Service (RDS) [5] ofrecen servicios de manejo de bases de datos. SimpleDB ofrece un almacén de datos no relacionales de tipo llave-valor. RDS ofrece un manejador de base de datos relacional, compatible con MySQL u Oracle.
AWS CloudFormation [9], lanzado públicamente en febrero de 2011 [11], ofrece a los desarrolladores la posibilidad de crear plantillas de colecciones de recursos para aprovisionarlas de manera predictiva y ordenada. Estas plantillas están definidas en JSON y describen de manera comprehensiva los servicios, parámetros, entradas y salidas esperadas para una finalidad específica.
Amazon es el referente en el mercado y sirve como punto de comparación para los nuevos desarrollos, como MagosCloud. El conjunto de servicios de Amazon Web Services, particularmente CloudFormation, EC2 y Elastic Load Balancig, comparten objetivos con MagosCloud, sin embargo no cumplen con las condiciones de extensibilidad, código abierto y posibilidad de despliegue como Cloud privada. Ubuntu Enterprise Cloud (UEC) [20] [15] es una solución de tipo IaaS que permite desplegar una infraestructura Cloud privada, compatible con Amazon EC2, lo que le permite utilizar las herramientas diseñadas para este servicio. UEC se evaluó como alternativa para el manejo de infraestructura en MagosCloud, sin embargo no se encontró conveniente en un ambiente oportunista.
Nimbula [64] ofrece una solución de Cloud privada, un sistema de administración de Cloud, compuesto por Nimbula Cloud Operative System y Nimbula Cloud Director. Ofrece altos niveles de automatización, flexibilidad, escalabilidad y seguridad. Nimbula soluciona los problemas a nivel de infraestructura que enfrenta MagosCloud, sin embargo para ello requiere una infraestructura dedicada, por lo que no se ajusta a los requerimientos de MagosCloud.
15
2.1.2
Plataforma como Servicio
Google AppEngine [25] ofrece una plataforma para desplegar aplicaciones desarrolladas en Java o Python en un entorno distribuido, soporta como fuente de datos a BigTable [25], no soporta bases de datos relacionales e impone algunas limitaciones al desarrollador. A diferencia de AppEngine, MagosCloud soporta diferentes tipos de fuentes de datos, permitiendo al desarrollador elegir, entre las opciones ofrecidas o usando una fuente externa, la que mejor se ajuste a la aplicación.
WSO2 Stratos [81] [39] ofrece una plataforma Open Source, cuya primera versión estable fue lanzada el 15 de noviembre de 2010, tanto para cloud pública como para cloud privada, con soporte para aplicaciones orientadas a servicios. Stratos está basado en proyectos abiertos como Tomcat, Axis, Drools. La principal diferencia frente a MagosCloud es que éste último soporta aplicaciones computacionalmente exigentes bajo el modelo MapReduce y la posibilidad de despliegue en un entorno oportunista. La integración con WSO2 Stratos se estudió como alternativa de implementación de MagosCloud.
Una propuesta inspirada en ITIL se describe en [40] en forma de una arquitectura teórica, que incluye el módulo de Plataforma como Servicio, por lo cual es relevante para MagosCloud.
2.1.3
Cloud Middleware
La estrategia de tener un middleware para integración de servicios de diferentes proveedores es utilizada para sobrellevar las diferencias y el uso de APIs propietarias.
El modelo de middleware propuesto en [73] Altocumulus está basado en el modelo de mejores prácticas y trata de homogeneizar las diferentes plataformas e infraestructuras Cloud. Propone patrones de escalabilidad e interacción, para disminuir la dependencia hacia el proveedor Cloud. Estos patrones son interesantes para el desarrollo de MagosCloud, que los tiene en cuenta en su arquitectura. Scicumulus [65] propone un middleware para workflows científicos, se separa de los requerimientos de MagosCloud al enfocarse únicamente en procesos de e-ciencia y no considerar el paradigma MapReduce.
2.2
MapReduce
MapReduce [29] [30] [50] [28] es un modelo de programación y su implementación asociada, utilizados para procesar y generar grandes cantidades de datos de forma paralela. Es fácil de usar para programadores sin experiencia en entornos
16
distribuidos ya que oculta los detalles de la paralelización, tolerancia a fallos y balanceo de carga.
Una de las aplicaciones más populares de MapReduce está en los entornos de e-ciencia [61] [48] [32] [68] [33], sin embargo las aplicaciones son variadas [27] e incluyen construcción de modelos de traducción estadísticos [31], minería de datos [22] [38], procesamiento de texto [33], comparación de datos [78], manejadores de bases de datos distribuidas [83]y aprendizaje de máquina [24].
GridBatch [56] provee un modelo de programación basado en MapReduce, y el framework asociado. Se utiliza específicamente para operaciones analíticas en una infraestructura Cloud. De manera similar [18] propone Freeride-G, que se enfoca en mejorar la tolerancia a fallas a través de un API que es una variación de MapReduce. Estos frameworks se separan de MapReduce incluyendo nuevos operadores, lo que hace que las aplicaciones que lo usan estén ligadas a sus librerías.
MOON [53] ofrece una implementación del modelo MapReduce en entornos oportunistas. Este proyecto es interesante para MagosCloud por tener en cuenta la alta volatilidad de los nodos presentada en entornos no intrusivos.
El trabajo presentado en “Job scheduling for multi-user mapreduce cluster” [85] propone una técnica de asignación de tareas en el framework MapReduce, para el escenario en el que el cluster es usado por múltiples usuarios. MagosCloud enfrenta este problema a través del uso de la virtualización, de tal forma que el usuario es el único usuario del cluster virtual.
Hadoop [79] [76][14], es un framework para computación distribuida que soporta aplicaciones con uso intensivo de datos. Implementa, entre otras cosas, el paradigma MapReduce y HDFS, un sistema de archivos distribuido y el principal sistema de almacenamiento en Hadoop. Hadoop ha sido ampliamente recibido por la comunidad de desarrolladores [28]. En las pruebas realizadas sobre éste framework [12] [13] [14] se evidencian sus funcionalidades, que incluyen el manejo de entrada y salida de nodos, un sistema de archivos distribuidos, manejo de replicación de datos y asignación de tareas. Las aplicaciones MapReduce en Hadoop pueden estar escritas en Java, C++, pig, entre otros lenguajes además de poder usar cualquier ejecutable, a través de la utilidad de streaming, como mapper o reducer. Los trabajos previos sobre la combinación entre MapReduce y máquinas virtuales [61] [42] [77] [87] sugieren varios aspectos a tener en cuenta, tanto en rendimiento como en volatilidad, en éste tipo de entornos. MagosCloud aprovecha las lecciones aprendidas en estos trabajos para mitigar los problemas que surgen en este tipo de entornos.
17
BioMagos [68] implementa una aplicación bioinformática basada en MapReduce, sobre Magos, documentado los problemas encontrados para el desarrollo y despliegue de éste tipo de aplicaciones. Las conclusiones de BioMagos sirven como punto de partida al proyecto MagosCloud, al evidenciar las limitaciones existentes en Magos para la creación de aplicaciones computacionalmente exigentes y el manejo de archivos.
En “Defining Future Platform Requirements for e-Science Clouds” [72] resume los requerimientos de las aplicaciones de e-Ciencia en el entorno Cloud. MagosCloud adopta las consideraciones en términos de requerimientos de aplicación y modelo de uso.
Tabla 1 Atributos de calidad requeridos frente a diferentes alternativas
Dados los requerimientos no funcionales las soluciones evaluadas no constituyen una solución al problema enfrentado por MagosCloud. A continuación se describe la estrategia de solución definida en MagosCloud.
_ Am a zo n W e b S e rv ic e s G o o g le A p p s W S O 2 S tr a to s U n a C lo u d U b u n tu E n te rp ri se C lo u d N im b u la M a g o sC lo u d Oportunista Declarativo Portabilidad de Aplicaciones Sí
Portabilidad de Datos No aplica
Código Abierto No
Extensible Cloud Privada
18
3
Estrategia de solución
MagosCloud es una solución que implementa el paradigma Cloud Computing de tipo Plataforma como Servicio (PaaS), extensible, declarativo, oportunista para servicios Web 2.0, teniendo al desarrollador como usuario objetivo:
Oportunista: usa la infraestructura existente en la organización, aprovechando los recursos que son subutilizados.
Extensible: permite dar soporte a nuevos tipos de plataformas y fuentes de datos, así como utilizar los proveedores de virtualización existentes en la organización. Declarativo: oculta la complejidad del manejo de los recursos de infraestructura y de la configuración de las plataformas al desarrollador. El desarrollador crea una solicitud de Instancia de plataforma, o de despliegue sobre una instancia existente, que puede ser reutilizada.
Para alcanzar estos objetivos MagosCloud despliega un conjunto de máquinas virtuales, configuradas automáticamente de acuerdo con las necesidades del desarrollador y ocultando su complejidad a través de un conjunto de definiciones:
• Plataforma: Para MagosCloud una Plataforma es una pila de solución (El término común en inglés es solution stack), que incluye el sistema operativo, el software y la configuración necesaria, en una o más máquinas, para desplegar una aplicación funcional, o una base de datos en caso de fuentes de datos.
• Instancia de plataforma: Una instancia de plataforma es el conjunto de máquinas virtuales configuradas para una plataforma específica, visible al usuario desarrollador como una unidad.
El desarrollador interactúa en MagosCloud con los conceptos anteriores, solicitándole una instancia de plataforma en la cual desplegará sus datos y/o aplicaciones. Por ejemplo, una plataforma tipo MC_APACHE ofrece una máquina virtual configurada como balanceador de carga y un conjunto (variable) de máquinas virtuales configurados como instancias de Apache. Una instancia de esta configuración es el conjunto de máquinas virtuales que pertenecen a un desarrollador.
Las siguientes definiciones hacen parte de MagosCloud y su funcionamiento pero se ocultan al usuario desarrollador:
• Nodo de instancia: Una máquina virtual que pertenece a una instancia de plataforma dada.
19
• Nodo MagosCloud: Cada máquina física que permite a MagosCloud subir o bajar máquinas virtuales.
• Configuración: Definición del conjunto de paquetes, archivos y parámetros necesarios para un nodo de plataforma dada.
• Gestor de Configuraciones: Componente que se encarga de aplicar una configuración dada (instalar paquetes, crear archivos de configuración, copiar archivos, crear archivos y controlar servicios) a la máquina virtual.
• Balanceador de carga: Componente que se encarga de monitorear las máquinas virtuales y físicas. Es el encargado de decidir en cuál nodo de MagosCloud se desplegará cada máquina virtual y cuándo desplegar una nueva máquina virtual para una instancia de plataforma dada, de acuerdo con el estado de las máquinas existentes.
• Estado: En la implementación actual de MagosCloud se tiene en cuenta como estado la cantidad de espacio en disco duro disponible, la cantidad de memoria disponible, el porcentaje de uso del procesador y su frecuencia en MHz.
Ilustración 3 Estrategia de implementación
Para los diferentes componentes de MagosCloud se evaluaron diferentes alternativas. WSO2 Stratos [81] se evaluó para ser integrado para proveer las
20
diferentes plataformas y fuentes de datos. Sin embargo en la versión evaluada requería ser instalado sobre Ubuntu Enterprise Cloud, que no es conveniente para el entorno oportunista de MagosCloud dado que requiere ser instalado sobre la máquina física.
Se decide usar la estrategia oportunista de UnaCloud más no su implementación, por no ajustarse a los requerimientos de extensibilidad ya que dependía, en la versión evaluada, de un hypervisor específico y de una plantilla de máquina virtual por cada nuevo conjunto de aplicaciones ofrecido. MagosCloud está diseñado para disminuir la dependencia hacia un hypervisor determinado.
MagosCloud, a diferencia de UnaCloud, tiene sólo una imagen de máquina virtual base. Esta imagen al instanciarse instala los paquetes, crea los archivos y sube los servicios especificados por la configuración dada.
Como gestor de configuración se decide usar Puppet [71], que permite una definición declarativa de las configuraciones. Puppet, a diferencia de otros gestores de configuración como Chef [66], maneja de manera semántica conceptos como usuario, servicio y paquete.
3.1
Casos de uso
El desarrollador puede usar MagosCloud para definir una nueva plataforma desplegar una aplicación existente y consultar los reportes sobre el uso de la infraestructura.
Ilustración 4 Diagrama general casos de uso
uc Casos de Uso Desarrollador Instanciar Servidor Desplegar Aplicación ver Reportes Administrador MagosCloud Crear Dominios Registrar Usuarios Crear Tipos de Plataforma Usuario Usa aplicación
21
Dado el alcance de este trabajo, el diseño tiene en cuenta los casos de uso del desarrollador, el usuario y el administrador, sin embargo en la implementación se priorizan los casos de uso del desarrollador. En el anexo A se detalla cada caso de uso del desarrollador.
3.2
Lenguaje declarativo de MagosCloud
El desarrollador interactúa con MagosCloud usando el lenguaje declarativo definido, basado en XML, y que puede ser diferente al lenguaje final de usuario.
Ilustración 5 Esquema del lenguaje definido
Bajo este esquema el usuario puede, por ejemplo, definir una solicitud de plataforma, limitando el crecimiento a 20 nodos usando la definición que se muestra en la Ilustración 6.
El tipo de datos tipoPlataforma es definido por la unión de tipoPlataformaEnum y tipoPlataformaExt. Esto permite definir nuevas plataformas sin dejar de validar los definidos, inicialmente, en MagosCloud
22
3.3
Decisiones de diseño
Teniendo en cuenta los atributos de calidad y las funcionalidades deseadas en MagosCloud se toman las siguientes decisiones de diseño:
Decisión Razonamiento Observaciones
Eliminar la
dependencia hacia un hypervisor específico. Uso del patrón factory.
La estrategia oportunista usa un hypervisor tipo 2, sin depender de un hypervisor específico. El eliminar la dependencia facilita la implementación de MagosCloud en un entorno en el que existe una solución de virtualización.
Se usa una abstracción del hypervisor y un patrón factory. De esta forma, para dar soporte a un nuevo hypervisor se debe crear la clase específica que implemente la interfaz dada, y modificar HypervisorFactory para instanciarla. Usar la estrategia oportunista y de plataforma como servicio de UnaCloud mas no su implementación. La estrategia oportunista de UnaCloud permite el aprovechamiento de los recursos existentes. La implementación de
UnaCloud está ligada a VMWare Workstation.
UnaCloud, al estar basado en un hypervisor VMWare, puede ser ejecutado en máquinas virtuales ESX.
Se descarta también UEC dado que no funciona en máquinas virtuales (al menos en las pruebas realizadas) al no detectar/usar las instrucciones de virtualización. Uso de Puppet [71] para el manejo de configuraciones. El lenguaje declarativo de Puppet facilita extender MagosCloud para dar soporte a otros tipos/configuraciones de plataforma.
Puppet es de código abierto y su lenguaje permite ser extendido.
<?xml version="1.0" encoding="UTF-8" ?> <solicitud xmlns="http://www.christian-ariza.net/schemas/"> <plataforma maxNodos="20"> <tipo>APACHE</tipo> <parametros></parametros> </plataforma> </solicitud>
23 Distribuir las
máquinas
virtuales entre los nodos
disponibles2.
Cuando se ejecutan varias máquinas virtuales en la misma máquina física (con una NIC) comparten entre ellas la carga de red.
Se distribuye, en lo posible, las máquinas virtuales en las máquinas físicas, así se disminuye la carga de red compartida entre ellas.
Una estrategia tipo round-robin no es suficiente para esta asignación, se debe tener en cuenta además la carga (procesamiento, memoria, disco) de cada máquina física Distribuir las máquinas pertenecientes a una instancia de plataforma, contribuye a su disponibilidad. Al usar estrategias de replicación en las plataformas se aumenta el número de peticiones de red. Adaptación del componente de obtención de estado usado en UnaCloud. Basado en SIGAR [41].
Permite conocer el estado de la máquina en términos de memoria, procesamiento y disco duro.
Además de la información utilizada como estado en MagosCloud, SIGAR permite conocer, entre otros datos, las interfaces de red, carga promedio y memoria por proceso.
Compromiso entre carga de red y tiempo de reporte de estado.
El tiempo de reporte de estado es directamente proporcional al tiempo que puede estar una instancia de máquina virtual fuera de servicio. Existe un compromiso entre el tiempo de reporte y la carga de red (cada máquina física y virtual hace un reporte cada cierto tiempo) que involucra un intercambio de mensajes hacia el balanceador de carga dado y la carga de red en un momento dado.
Se privilegia la carga de red y se penaliza el tiempo de respuesta a eventos del balanceador de carga. El tiempo de reporte es configurable.
Uso de linked clones de una máquina base.
MagosCloud puede instanciar más de una máquina virtual por cada nodo. Usando linked clones se disminuye notablemente el espacio de almacenamiento utilizado.
El tamaño de la máquina base se convierte en un costo fijo, que se distribuye en los diferentes nodos de instancia que se basan en ella.
Tabla 2 Decisiones de diseño
24
3.4
Arquitectura Propuesta
La arquitectura propuesta, basada en la estrategia descrita anteriormente, es una arquitectura distribuida que incluye balanceo de carga, administración de configuraciones, manejo del hypervisor y reporte de estado.
Ilustración 7 Diagrama general arquitectura MC
El desarrollador interactúa con el servidor de MagosCloud, solicitando una nueva instancia de plataforma o un despliegue sobre una plataforma existente. MagosCloud oculta al desarrollador la infraestructura y la configuración de la plataforma. El usuario de la aplicación interactúa con ella directamente, a partir de la dirección IP entregada al desarrollador por MagosCloud.
A continuación se describe el diseño y responsabilidades de los componentes de MagosCloud, su despliegue y los diagramas de secuencia para la instanciación de una plataforma y el despliegue de aplicaciones sobre ella.
25
4
Diseño
Teniendo como base las decisiones de diseño y la arquitectura general propuesta, se diseñan los componentes de MagosCloud.
4.1
Modelo de componentes
En esta sección se presenta el modelo general y el detalle de las responsabilidades de cada uno de los componentes de MagosCloud.
4.1.1
Vista General
En la Ilustración 8 se presentan los componentes generales de MagosCloud y las relaciones entre ellos.
Ilustración 8 Magos Cloud Componentes
4.1.2
MCNode
El componente MCNode es el responsable de reportar el estado de la máquina física,
recibir solicitudes, e interactuar con el hypervisor, para iniciar, parar o ejecutar comandos en máquinas virtuales.
cmp Components LB UI Conf MCServer LB UI Conf MCVMInstance desp MCLoadBalancer desp MCEndUserWI desp Reg MCNode desp Reg «specification» StatusReporter Node Register Configure Deploy Deploy request Status Report
26
Ilustración 9 Componente MCNode
El componente VMManager se encarga de abstraer las operaciones del hypervisor, y
es el encargado de clonar, iniciar, detener y ejecutar comandos en las máquinas virtuales.
MCNode utiliza a StatusReporter para obtener, y reportar al balanceador de carga
asignado, el estado de la máquina física.
4.1.3
MCVMInstance
El componente MCVMInstance es el encargado de configurar el estado inicial de la
máquina virtual al ser ejecutado por primera vez. Configura la dirección IP y nombre de la máquina virtual, la IP del balanceador de carga al cual le reportará el estado y el servidor de configuraciones del cual obtiene la definición de la configuración.
Ilustración 10 Componente MCVMInstance cmp MCNodo desp MCNode desp «specification» StatusReporter VMManager Virtual Machine Deploy Register Physical machine register Register Virtual Machine Deploy Register cmp MCVMInstance MCVMInstance Local configuration Local configuration manager Local configuration «specification» StatusReporter «delegate»
27
Este componente se encarga también de consultar el servidor y aplicar la configuración según corresponda e informar el estado de la máquina virtual al balanceador de carga dado.
4.1.4
MCServer
El componente MCServer es el responsable de registrar las máquinas nodo, traducir
las solicitudes del usuario desarrollador, administrar la configuración de las máquinas virtuales y asignar nodos y solicitudes a los balanceadores de carga.
Ilustración 11 Componente MCServer
El componente MCNode Manager es el responsable de registrar los nodos y
asignarlos a un balanceador de carga.
El componente Configuration Manager es el responsable de definir y comunicar a
las máquinas virtuales su configuración. Este componente se apoya en Puppet para comunicar la configuración, y definir el catálogo de configuraciones posibles. Para asignar la configuración se define un componente PuppetEN que actúa como puente entre Puppet y MagosCloud.
Deployment Manager es el encargado de decidir cuantas máquinas virtuales se
desplegarán, asignarles los nombres y direcciones IP y asignarlas a un balanceador de carga. cmp MCServer Conf fisicos LB UI MCServer Conf fisicos LB UI Configuration Manager Configuration User Authentication Request Translator Request MCNode Manager Registration Deployment Manager Deploy description Report Generator «delegate» «use» «delegate» «delegate» «use» «use» «delegate»
28
4.1.5
MCLoadBalancer
Se encarga de recibir las peticiones de despliegue de máquinas virtuales, seleccionar los nodos en los que se desplegarán, recibir los reportes de estado de los nodos y máquinas virtuales, detectar las máquinas virtuales que no responden para desplegar nuevas instancias.
Ilustración 12 Componente MCLoadBalancer
El componente monitor revisa los reportes de estado y, si existen nodos sin reporte
de estado en un periodo de tiempo, trata de comunicarse con ellos. Si no logra comunicarse inicia una nueva instancia con la misma dirección IP y nombre que el nodo que no responde.
cmp MCLoadBalcer MCLoadBalancer Status Listener Deploy DeployRequest Monitor Listener
Listener Deploy Request Listener Node Manager Deploy VM Persistence «use» «use» «delegate» «delegate» «delegate» «use» «use»
29
4.2
Diagrama de Despliegue
El despliegue de MagosCloud requiere una máquina que actúa como servidor, uno o más balanceadores de carga y uno o más nodos. En cada máquina nodo debe existir una plantilla de máquina virtual que debe incluir el componente MCVMInstance.
Ilustración 13 Diagrama de despliegue
Tanto el nodo como la plantilla de máquina virtual incluyen el componente
StatusReporter. deployment Despliegue «device» Servidor MC «executionEnviron... WebServer «executionEnviro... Java Application :MCEndUserWI :MCServer «device» Nodo MC «executionEnvironment» Aplicación Java :MCNode «executionEnvironment» Database «device» VMWare Image :MCVMInstance «specificatio... : StatusReporter «specificatio... : StatusReporter «device» LoadBalancer MC : MCLoadBalancer VMrun TCP/IP TCP/IP TCP/IP JDBC TCP/IP TCP/IP Socket
30
4.3
Diagramas de Secuencia
Se muestra los diagramas de secuencia que corresponden a los casos de uso instanciación de plataforma y desplegar aplicación.
4.3.1
Instanciación de Plataforma
Para la instanciación de una nueva plataforma en MagosCloud el usuario describe la plataforma usando el lenguaje declarativo definido. Usando esta solicitud el componente MCServer asigna un conjunto de direcciones y genera los nombres de
las máquinas virtuales necesarias para la plataforma, las asigna a un balanceador de carga que se encarga de asignarlas a los nodos.
Ilustración 14 Instanciar Plataforma (Diagrama de secuencia)
El componente MCNode crea e inicia una nueva máquina virtual, como un linked
clone de la máquina base, y ejecuta en ella el componente MCVMInstance
asignándole el nombre, la dirección IP, la dirección IP del balanceador de carga al cual le reportará el estado y la dirección IP del servidor de configuraciones. MCVMInstance se encarga de configurar inicialmente la máquina virtual, solicitando al servidor y aplicando la configuración.
sd Instanciación de Plataforma
Desarrollador
Components::MCEndUserWI Components::MCServer Components::MCLoadBalancer Components::MCNodo Components::MCVMInstance
DescribirPlataforma() DesplegarPlataforma() DesplegarVM(nombresLB, prefijoNombres, max, min) *DesplegarVM(Nombre, IP) Desplegar() Confirmación() Confirmar() InformarDespliegue(id_despliegue) SolicitarConfiguración(nombre) AplicarConfiguración(especificación) *ConsultarEstado() EstadoPeticion() Verificar()
31
4.3.2
Desplegar Aplicación
Para desplegar una aplicación en MagosCloud el usuario desarrollador define los archivos que la constituyen y la plataforma en la cual se desplegará, en el lenguaje declarativo. Con esta definición MCServer actualiza la configuración de los nodos de
la plataforma y les solicita recargarla. MCVMInstance se encarga de recargar la
configuración obteniendo los archivos y procesándolos según sea definido para la plataforma.
Ilustración 15 Desplegar Aplicación sd Desplegar App
Desarrollador
Components::MCVMInstance Components::MCEndUserWI Components::MCServer Components::MCLoadBalancer
Deploy(servicio, archivos) Deploy(Servicios,Archivos) ForceReload(id_conf) ReloadConfig() SolicitarConfiguración() Configurar(Especificacion) Configurado() Confirmacion() Confirmacion()
5
Este capítulo describe la implementación de
su totalidad y que se constituye en el componente básico de la arquitectura de MagosCloud.
Como entorno de desarrollo se usó Eclipse
operativos Windows XP y Windows 7. En producción se usa Debian 6.0, distribución estable con
estricta política de lanzamientos y soporte
MCLoadBalancer y como sistema operativo de la máquina virtual base para las
instancias de plataforma MagosCloud.
El componente StatusReporter
para obtener información sobre el estado de las máquinas, físicas y virtuales definido por la cantidad de espacio en disco duro disponible, la cantidad de memoria disponible, el porcentaje de uso del procesador y su frecuencia en MHz Este componente es a su vez utilizado por
las máquinas virtuales, y por
Ilustración
Como parte de la administración de configuraciones, se utiliza Puppet, versión 2.6, teniendo a puppet master
máquina virtual base. La última versión disponible de P
se prefiere el uso de la versión 2.6 por estar presente en los repositorios oficiales de Debian 6.0, adicionalmente, los cambios introducidos al lenguaje pueden afectar el
32
Implementación y pruebas
Este capítulo describe la implementación de MagosCloud Core, que fue lograda en su totalidad y que se constituye en el componente básico de la arquitectura de
Como entorno de desarrollo se usó Eclipse Helios Service Release 2 en los sistemas operativos Windows XP y Windows 7. En producción se usa Debian 6.0,
con repositorios de paquetes estrictamente seleccionados ítica de lanzamientos y soporte, para el despliegue de
y como sistema operativo de la máquina virtual base para las instancias de plataforma; Windows 7 se utiliza para el despliegue de los nodos de
StatusReporter utiliza la versión 1.6.4 de la librería hyperic
para obtener información sobre el estado de las máquinas, físicas y virtuales cantidad de espacio en disco duro disponible, la cantidad de memoria disponible, el porcentaje de uso del procesador y su frecuencia en MHz
nte es a su vez utilizado por MCMVInstance, para reportar el estado de
las máquinas virtuales, y por MCNode para reportar el estado de las máquinas físicas.
Ilustración 16 Estructura del proyecto para el módulo StatusReporter
Como parte de la administración de configuraciones, se utiliza Puppet, versión 2.6,
puppet master en el servidor de MagosCloud y a puppet agent
a última versión disponible de Puppet es la 2.7, sin embargo fiere el uso de la versión 2.6 por estar presente en los repositorios oficiales de Debian 6.0, adicionalmente, los cambios introducidos al lenguaje pueden afectar el , que fue lograda en su totalidad y que se constituye en el componente básico de la arquitectura de
en los sistemas operativos Windows XP y Windows 7. En producción se usa Debian 6.0, una estrictamente seleccionados y una para el despliegue de MCServer,
y como sistema operativo de la máquina virtual base para las para el despliegue de los nodos de
hyperic-sigar
para obtener información sobre el estado de las máquinas, físicas y virtuales, cantidad de espacio en disco duro disponible, la cantidad de memoria disponible, el porcentaje de uso del procesador y su frecuencia en MHz. , para reportar el estado de para reportar el estado de las máquinas físicas.
Como parte de la administración de configuraciones, se utiliza Puppet, versión 2.6,
puppet agent en la
uppet es la 2.7, sin embargo fiere el uso de la versión 2.6 por estar presente en los repositorios oficiales de Debian 6.0, adicionalmente, los cambios introducidos al lenguaje pueden afectar el
33
funcionamiento de las configuraciones definidas actualmente, en especial en cuanto al alcance de las variables.
5.1
Flujo de control y componentes de MagosCloud
Inicialmente MagosCloud cuenta con un MCServer y al menos un MCLoadbalancer,
el servidor debe conocer los balanceadores disponibles. Al iniciar un nodo MCNode,
éste debe conocer la ubicación del servidor con quien se registra.
34
El componente MCServer registra los nodos y los asigna a uno de los balanceadores
existentes. Al recibir la solicitud de una nueva plataforma, MagosCloud, consulta los tipos de configuración asociados a ella y el número deseable de nodos, genera los nombres de acuerdo con la configuración y les asigna una dirección IP a cada uno. A continuación MCServer elige, de acuerdo con la carga actual, un balanceador de
carga y le asigna la instancia de plataforma, enviándole el listado de direcciones y nombres.
Ilustración 18 Estructura del proyecto para el módulo MCServer
El componente MCBalanceador (MCLoadBalancer) se encarga de recibir los reportes
de sus nodos asignados, y de las máquinas virtuales (nodos de instancia) instanciadas en ellas. Si hay una máquina virtual que no reporta estado en un periodo de tiempo definido, el balanceador iniciará una nueva, con el mismo nombre e IP, en uno de sus nodos asignados. Si la carga en las máquinas virtuales, para una determinada instancia de plataforma, es superior al límite definido, el balanceador solicitará al servidor una nueva dirección y nombre para un nodo de instancia.
Ilustración 19
El componente MCNode
del balanceador de carga e interactúa con el
eliminar y ejecutar comandos en las máquinas virtuales. En el caso de VMWare Workstation se utilizó la versión 1.10 de VIX, y su herramienta
implementar éstas funciones. máquina virtual, creando un
MCMVInstance en ella.
Ilustración
El componente MCMVInstance
recibe como parámetros el nombre de la máquina virtual instanciada, la dirección IP asignada, la dirección IP del
dirección IP del servidor de configuraciones que usará el agente
MCMVInstance se encarga de configurar la máquina virtual con estos datos e iniciar
35
19 Estructura del proyecto para el módulo MCBalanceador
reporta el estado de la máquina física, recibe las peticiones del balanceador de carga e interactúa con el hypervisor para clonar, iniciar, detener, eliminar y ejecutar comandos en las máquinas virtuales. En el caso de VMWare Workstation se utilizó la versión 1.10 de VIX, y su herramienta
implementar éstas funciones. MCNode utiliza esta funcionalidad para
máquina virtual, creando un linked clone de la máquina virtual base,
Ilustración 20 Estructura del proyecto para el módulo MCNode
MCMVInstance, que se incluye dentro de la máquina virtual base
recibe como parámetros el nombre de la máquina virtual instanciada, la dirección IP la dirección IP del balanceador de carga al cual le reportará el estado y
el servidor de configuraciones que usará el agente
encarga de configurar la máquina virtual con estos datos e iniciar
MCBalanceador
reporta el estado de la máquina física, recibe las peticiones ara clonar, iniciar, detener, eliminar y ejecutar comandos en las máquinas virtuales. En el caso de VMWare Workstation se utilizó la versión 1.10 de VIX, y su herramienta vmrun, para
utiliza esta funcionalidad para crear la de la máquina virtual base, y ejecutar
áquina virtual base, recibe como parámetros el nombre de la máquina virtual instanciada, la dirección IP balanceador de carga al cual le reportará el estado y la el servidor de configuraciones que usará el agente de Puppet. encarga de configurar la máquina virtual con estos datos e iniciar
el agente de Puppet, plataforma.
Ilustración 21
Cuando MCMVInstance
Puppet, este se comunica con el servidor de de Magos (MCServer). A su vez
nodos, que es dada por el componente
configuración para un nodo de instancia dado, por nombre resultado que incluye el listado de clases definidas en Puppet
necesarios que constituyen la configuración de la instancia de plataforma formato YAML.
Ilustración
El proyecto Util incluye funciones que son usadas en los componentes de
MagosCloud, como el manejo de
incluyendo la definición de los tipos de mensajes a intercambiar, clases comunes, la ejecución de comandos del sistema operativo y el manejo de los mensajes de salida.
36
que obtiene y aplica la configuración de la instancia de
21 Estructura del proyecto para el módulo MCMVInstance
MCMVInstance, en una instancia de plataforma, ejecuta el agente de
uppet, este se comunica con el servidor de Puppet (puppet master) en el servidor
. A su vez puppet master usa una definición externa d
nodos, que es dada por el componente PuppetEN. PuppetEN consulta a
configuración para un nodo de instancia dado, por nombre del nodo, y devuelve el resultado que incluye el listado de clases definidas en Puppet y los parámetros
que constituyen la configuración de la instancia de plataforma
Ilustración 22 Estructura del proyecto para el módulo MCPuppetEN
incluye funciones que son usadas en los componentes de sCloud, como el manejo de sockets para la comunicación entre ellos, definición de los tipos de mensajes a intercambiar, clases comunes, la ejecución de comandos del sistema operativo y el manejo de los mensajes de salida.
que obtiene y aplica la configuración de la instancia de
, en una instancia de plataforma, ejecuta el agente de ) en el servidor usa una definición externa de los consulta a MCServer la
, y devuelve el y los parámetros que constituyen la configuración de la instancia de plataforma, en
incluye funciones que son usadas en los componentes de para la comunicación entre ellos, definición de los tipos de mensajes a intercambiar, clases comunes, la ejecución de comandos del sistema operativo y el manejo de los mensajes de salida.
Tanto MCServer como MCBalanceador
usado EJB3 para manejar persistencia del lado de la aplicación y manejador de bases de datos.
Ilustración
MCServer persiste los diferentes tipos de plataforma
MagosCloud Core, sus tipos de configuración, número mínimo de nodos para cada tipo, las clases de Puppet que utiliza c
37
Ilustración 23 Estructura del proyecto Util
MCBalanceador requieren un módulo de persistencia, se ha
usado EJB3 para manejar persistencia del lado de la aplicación y MySql manejador de bases de datos.
Ilustración 24 Modelo de datos para MCServer
persiste los diferentes tipos de plataforma a los que da sop , sus tipos de configuración, número mínimo de nodos para cada tipo, las clases de Puppet que utiliza cada configuración y sus parámetros.
de persistencia, se ha MySql 5.5 como
a los que da soporte , sus tipos de configuración, número mínimo de nodos para cada
38
Para adicionar un nuevo tipo de plataforma basta con crear las definiciones de la configuración en Puppet y registrarlas en la base de datos con los parámetros que sean necesarios.
Si como valor de parámetro se utiliza <<lista:tipodeconfiguracion>> (por
ejemplo <<lista:nodoapache>>) el valor del parámetro será generado por
MagosCloud como un arreglo con la dirección IP de los nodos de instancia de la plataforma que tienen el tipo de configuración dado. De igual forma para obtener como valor de parámetro el id de configuración (id de la instancia de plataforma)
se utiliza el valor <<prefijo:idconf>>.
MCServer también persiste los nodos que se han registrado y el balanceador que
tienen asignado.
Ilustración 25 Modelo de datos MCLoadBalancer
MCLoadBalancer persiste los nodos que se han asignado al balanceador, así como
las máquinas virtuales, los reportes de estado recibidos y una bitácora con la información de las operaciones realizadas sobre las máquinas virtuales en el tiempo.
39
5.2
Estrategias y configuraciones de las plataformas soportadas
5.2.1
Apache HA
Uso del balanceador de carga de apache, mod_proxy_balancer, con mínimo dos
nodos apache y un balanceador de carga. En el Anexo D: Ejemplo de uso documentado de Puppet se encuentra el ejemplo documentado de la definición de la configuración del balanceador de carga en Puppet.
Se utiliza Apache2 en la última versión disponible en el repositorio de la distribución de la imagen base, Debian 6 para la máquina base actual.
5.2.2
Tomcat HA
Uso de apache con mod_proxy, con mínimo dos nodos Tomcat y un nodo apache
actuando como balanceador de carga.
Se utiliza Apache2 y Tomcat6 en las últimas versiones disponibles en el repositorio de la distribución de la máquina base.
5.2.3
MySql HA
Uso de MySql proxy y replicación multi-master para obtener alta disponibilidad. En
la versión actual sólo tiene un nodo proxy y dos nodos master con replicación
circular.
5.2.4
Hadoop-HBase
Uso de módulos basados en los provistos en Puppet forge. Se modifican para funcionar en Debian 6 y configurando los parámetros convenientemente.
Se utiliza la versión 0.90.3 de HBASE.
5.2.5
Servidor de Archivos
Uso de una interfaz ftp para el manejo de archivos, usando Hadoop-ftp3 en el nameserver.
5.2.6
Base de datos XML
Se utiliza BaseX4
, que provee paquetes para la distribución Debian usada en las máquinas base. Actualmente no se provee una estrategia para alta disponibilidad en este manejador de base de datos.
3
http://www.hadoop.iponweb.net/Home/hdfs-over-ftp
4
40
5.3
Diseños y Resultados de Pruebas
Se diseñan 3 tipos de pruebas para validar los requerimientos de MagosCloud. La primera es una prueba funcional (Tabla 3) que, partiendo de definiciones en el lenguaje de MagosCloud, valida que se desplieguen los diferentes tipos de plataformas ofrecidas y se desplieguen aplicaciones sobre ellas.
La segunda es una prueba de carga (Tabla 4), sobre una aplicación desarrollada en PHP y MySql, tanto sobre un ambiente de control, desplegado en dos máquinas virtuales con recursos dedicados que se encuentran en un servidor ESX, como en una plataforma desplegada en MagosCloud.
La tercera prueba es una prueba de estrés (Tabla 5) utilizando una aplicación tipo MapReduce que genera grandes cantidades de archivos sobre el sistema de archivos distribuido.
Pruebas Funcionales
Objetivo: Comprobar la funcionalidad del sistema en un ambiente de producción.
Tipo de prueba: Funcional
Responsable : Christian Ariza
Fecha: 02/07/2011
Datos de prueba a usar: Definiciones de plataforma para los tipos de servidor soportados.
Definiciones de despliegue.
Resultados esperados: Se despliegan las aplicaciones dadas. Resultados:
Resultados obtenidos de las pruebas efectuadas:
En promedio 8 minutos en atender una solicitud, que despliega de 3 a 5 máquinas virtuales iniciales. La solicitud de base de datos XML con BaseX despliega una máquina virtual en 2 minutos.
41 Análisis de los resultados:
Concepto de los resultados de la prueba:
Los resultados están dentro del rango previsto. La diferencia entre en el tiempo de despliegue se debe a no paralelizar la asignación de máquinas virtuales. En este momento lo hace de forma secuencial, para asegurar una distribución uniforme de las máquinas virtuales en la infraestructura, como mecanismo de resistencia a fallas.
Al desconectar una máquina física el balanceador de carga de MagosCloud se encarga de crear nuevas instancias de las máquinas virtuales en la infraestructura.
Observaciones y
sugerencias:
Se sugiere evaluar paralelizar de asignación de máquinas por parte del balanceador de carga.
Tabla 3 Pruebas Funcionales
Prueba de carga – Apache-MySql
Objetivo: Comprobar la capacidad de escalabilidad en términos de procesamiento/memoria.
Tipo de prueba: Prueba de carga Responsable Christian Ariza
42
Datos de prueba a usar: Aplicación PHP, de inscripción a eventos, que genera con cada petición una inserción y una consulta para MySql.
Pruebas con Jmeter distribuido, utilizando 3 nodos esclavos cada uno de los cuales genera 100 y 333 peticiones por segundo en momentos dados, Se ejecuta 10 veces cada prueba. Cada petición incluye los datos del formulario de inscripción y simula la inscripción de un participante. Jmeter master Jmeter slave Jmeter slave Jmeter slave Target
Ilustración 26 Configuración prueba de carga
Jmeter cuenta como error cualquier respuesta diferente a HTTP 200 OK. Este porcentaje de error incluye errores de conectividad con el servidor web, errores en la aplicación (causados por la concurrencia o la conexión con la base de datos) y peticiones canceladas por el servidor por no ser atendidas en un tiempo específico (timeout).
Resultados esperados: Cuando los niveles de carga en cada plataforma (Apache/MySql) llegan a los niveles máximos definidos se crean nuevas instancias, hasta alcanzar el número máximo de instancias dado por el desarrollador.
Resultados obtenidos de las pruebas efectuadas:
43
Resultados obtenidos de las Datos de control: Aplicación desplegada en máquinas virtuales con recursos dedicados:
Rendimiento: Muestras Muestras/ segundo Respuest diferente HTTP 200 Petición 1 3000 26.3 3.17% Petición 2 9030 31.6 50.31%
Porcentaje de error total: 38.55%
Datos de la plataforma desplegada en MagosCloud: Muestras Muestras/ segundo Respuesta diferente HTTP 200 Petición 1 3000 71.3 0.0% Petición 2 9090 76.9 23.29%
Porcentaje de error total: 17.91%
Ilustración 27 Número de muestras por segundo, mayor es mejor.
Ilustración 28 Porcentaje de error reportado por Jmeter.
Petición 1 Petición 2 26,3 31,6 71,3 76,9 Base MagosCloud Petición 1 Petición 2 3,17% 50,31% 0 23,90% Base MagosCloud
: Aplicación desplegada en máquinas
Respuestas diferentes de HTTP 200 3.17% 50.31%
Datos de la plataforma desplegada en MagosCloud: Respuestas diferentes de HTTP 200 0.0% 23.29%
úmero de muestras por segundo, mayor es mejor.
Porcentaje de error reportado por Jmeter.
44 Análisis de los resultados:
Concepto de los resultados de la prueba:
Los mecanismos de balanceo de carga en la definición de la plataforma (5.2) permiten un mejor desempeño que en el caso base.
El reporte de estado por parte de las máquinas virtuales, usando datos puntuales, no permite anticiparse a niveles de carga futuros. Este tipo de reportes puntuales puede llevar a tomar decisiones con base en picos, o valles, instantáneos.
Observaciones y
sugerencias:
Se sugiere revisar la estrategia usada por el balanceador de carga de MagosCloud para tener en cuenta datos históricos. Por ejemplo se puede usar monitoreo con una mayor frecuencia en las máquinas virtuales, que reporte al balanceador en cuando sea necesario y manteniendo el reporte periódico actual como heartbeat.
Se utilizaron 3 máquinas como esclavos de Jmeter dado el límite de peticiones que puede ejecutar paralelamente cada máquina.
Tabla 4 Prueba de carga – Apache-MySql
Prueba de carga: Archivos
Objetivo: Comprobar la escalabilidad en término de almacenamiento de archivos.
Tipo de prueba: Prueba de estrés. Responsable: Christian Ariza
Fecha: 07/07/2011
Datos de prueba a usar: Crawler tipo MapReduce que descarga grandes cantidades de datos, a partir de una lista de URLs definida.
Resultados esperados: Cuando el nivel de almacenamiento llegue a niveles críticos se crean nuevas instancias (nodos de Hadoop) hasta que se alcance el número máximo definido por el usuario.
45
es de 2 minutos desde el reporte que supera los índices de saturación de carga definidos.
Resultados:
Resultados obtenidos de las pruebas efectuadas:
Se levanta una nueva máquina virtual, sin embargo la aplicación falla por falta de recursos antes de que esta sea operativa.
Con una tasa menor de creación de datos la estrategia de escalabilidad en datos es válida.
Análisis de los resultados:
Concepto de los resultados de la prueba:
El tomar la decisión de levantar una nueva máquina basado en el último estado, puede no ser suficiente en una aplicación de uso intensivo de datos. El tiempo que toma en levantar una nueva máquina virtual puede ser superior al que le toma a la aplicación quedarse sin recursos y detenerse.
Observaciones y
sugerencias:
Buscar un mecanismo que logre anticiparse a la falta de recursos, una primera aproximación puede ser usar los reportes históricos. Para aplicaciones intensivas en datos se pueden cambiar los límites en el balanceador de carga para iniciar la carga de la nueva máquina con anticipación.
Tabla 5 Prueba carga: Archivos
5.4
Análisis de resultados
MagosCloud permite utilizar los recursos no aprovechados en la infraestructura existente, ocultando la infraestructura del usuario desarrollador. Permite configurar plataformas con mecanismos de resistencia a fallas, sin intervención del usuario y usando un lenguaje declarativo.
El enfoque de MagosCloud aporta valor al desarrollador, comparado con las soluciones de tipo infraestructura como servicio, haciendo invisible la infraestructura necesaria para alcanzar los objetivos de resistencia a fallas y escalabilidad. Adicionalmente, frente a las soluciones de tipo plataforma como servicio, MagosCloud aporta extensibilidad, permitiendo soportar nuevas plataformas sin modificar su arquitectura. El nivel de abstracción alcanzado, la
