0% encontró este documento útil (0 votos)
4 vistas162 páginas

Unacloud: IaaS para Cloud Computing Oportunista

La tesis presenta UNACLOUD, una infraestructura como servicio (IaaS) diseñada para el cloud computing oportunista, abordando su contexto, objetivos y características. Se exploran implementaciones de modelos IaaS existentes y se evalúan aspectos de diseño para el desarrollo de UNACLOUD, incluyendo su arquitectura y procesos de administración. Finalmente, se discuten los resultados de pruebas realizadas para validar la efectividad de UNACLOUD en comparación con otros modelos de computación.

Cargado por

Jorge Martinez
Derechos de autor
© Attribution Non-Commercial (BY-NC)
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
4 vistas162 páginas

Unacloud: IaaS para Cloud Computing Oportunista

La tesis presenta UNACLOUD, una infraestructura como servicio (IaaS) diseñada para el cloud computing oportunista, abordando su contexto, objetivos y características. Se exploran implementaciones de modelos IaaS existentes y se evalúan aspectos de diseño para el desarrollo de UNACLOUD, incluyendo su arquitectura y procesos de administración. Finalmente, se discuten los resultados de pruebas realizadas para validar la efectividad de UNACLOUD en comparación con otros modelos de computación.

Cargado por

Jorge Martinez
Derechos de autor
© Attribution Non-Commercial (BY-NC)
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

UNACLOUD: INFRAESTRUCTURA COMO SERVICIO PARA CLOUD COMPUTING OPORTUNISTA

EDGAR EDUARDO ROSALES ROSERO

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE INGENIERA DE SISTEMAS Y COMPUTACIN BOGOT D.C. JULIO 2010

UNACLOUD: INFRAESTRUCTURA COMO SERVICIO PARA CLOUD COMPUTING OPORTUNISTA

EDGAR EDUARDO ROSALES ROSERO

Tesis de grado presentada como requisito para optar al ttulo de Magister en Ingeniera Sistemas y Computacin

Director: Ph. D. Harold Enrique Castro Barrera Profesor Asociado

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE INGENIERA DE SISTEMAS Y COMPUTACIN BOGOT D.C. JULIO 2010

TABLA DE CONTENIDO 1. INTRODUCCIN .............................................................................................. 9 1.1. CONTEXTO................................................................................................. 13 1.2. OBJETIVO PRINCIPAL ............................................................................... 15 1.3. OBJETIVOS ESPECFICOS ....................................................................... 15 2. CLOUD COMPUTING .................................................................................... 16 2.1. ASPECTOS CONCEPTUALES ................................................................... 16 2.1.1. Contexto histrico..................................................................................... 16 2.1.2. Definiciones en construccin .................................................................... 17 2.1.3. Caractersticas principales ....................................................................... 19 2.1.4. Definicin propuesta................................................................................. 21 2.1.5. Modelos de servicio.................................................................................. 21 2.1.6. Virtualizacin ............................................................................................ 24 2.1.7. Modelos de despliegue ............................................................................ 25 2.1.8. Ventajas de cloud computing ................................................................... 26 2.1.9. Desventajas de cloud computing ............................................................. 28 2.2. IMPLEMENTACIONES DEL MODELO IAAS .............................................. 29 2.2.1. Amazon Elastic Compute Cloud ............................................................... 29 2.2.2. Nimbus ..................................................................................................... 32 2.2.3. OpenNebula ............................................................................................. 34 2.2.4. Eucalyptus................................................................................................ 36 2.2.5. VMware View y VMware Sphere .............................................................. 38 2.3. EVALUACIN DE LAS IMPLEMENTACIONES DEL MODELO IAAS ........ 41 3. COMPUTACIN OPORTUNISTA .................................................................. 46 3.1. ASPECTOS CONCEPTUALES ................................................................... 46 3.1.1. Definicin ................................................................................................. 46 3.1.2. Contexto de aplicacin ............................................................................. 47 3.2. IMPLEMENTACIONES DE LA COMPUTACIN OPORTUNISTA .............. 48 3.2.1. Taxonoma de las implementaciones de la computacin oportunista ...... 48 3.2.2. UnaGrid .................................................................................................... 50 3.3. IDENTIFICACIN DE ASPECTOS DE DISEO E IMPLEMENTACIN TILES PARA EL DESARROLLO DE UNACLOUD ............................................. 52 4. EVALUACIN DEL ESTADO DEL ARTE CON RESPECTO A LOS OBJETIVOS .......................................................................................................... 57 4.1. EVALUACIN DEL ESTADO DEL ARTE DE CLOUD COMPUTING ......... 58 4.2. EVALUACIN DEL ESTADO DEL ARTE DE LA COMPUTACIN OPORTUNISTA .................................................................................................... 62 5. ESTRATEGIA DE SOLUCIN ....................................................................... 69 5.1. ESTRATEGIAS DE DISEO E IMPLEMENTACIN .................................. 69 5.1.1. Estrategia de virtualizacin ...................................................................... 70 5.1.2. Estrategia oportunista .............................................................................. 71 5.2. ALCANCE DE LA SOLUCIN..................................................................... 72

5.2.1. Alcance funcional ..................................................................................... 72 5.2.2. Alcance no funcional ................................................................................ 74 6. UNACLOUD.................................................................................................... 77 6.1. VISIN GENERAL DE LA ARQUITECTURA .............................................. 77 6.2. ARQUITECTURA ........................................................................................ 79 6.2.1. UnaCloud Server ...................................................................................... 80 [Link]. Interface Layer ...................................................................................... 82 [Link]. Core Layer ............................................................................................ 83 [Link]. External Layer ....................................................................................... 86 [Link]. Diagrama de clases de UnaCloud Server ............................................. 87 6.2.2. UnaCloud Client ....................................................................................... 87 [Link]. External Layer ....................................................................................... 87 [Link]. Core Layer ............................................................................................ 89 [Link]. Diagrama de clases de UnaCloud Client .............................................. 91 6.3. MODELO DE PROCESOS DE UNACLOUD ............................................... 91 6.3.1. Personalizacin del modelo IaaS ............................................................. 91 6.3.2. Despliegue del modelo IaaS .................................................................... 92 6.3.3. Administracin del modelo IaaS ............................................................... 93 6.3.4. Administracin de la infraestructura base ................................................ 94 6.4. MECANISMOS DE COMUNICACIONES .................................................... 96 6.4.1. Mecanismos de seguridad en las comunicaciones .................................. 97 7. IMPLEMENTACIN, PRUEBAS Y RESULTADOS ...................................... 100 7.1. FASES DE IMPLEMENTACIN................................................................ 100 7.2. HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD . 102 7.2.1. Herramientas utilizadas para el desarrollo de UnaCloud Server ............ 102 7.2.2. Herramientas utilizadas para el desarrollo de UnaCloud Client ............. 103 7.3. IMPLEMENTACIN DE UNACLOUD ....................................................... 103 7.3.1. Procedimiento de autenticacin para el acceso a los servicios de UnaCloud ............................................................................................................ 103 7.3.2. Procedimiento de administracin de usuarios UnaCloud ....................... 104 7.3.3. Proceso de personalizacin del modelo IaaS ........................................ 105 7.3.4. Proceso de despliegue del modelo IaaS ................................................ 109 7.3.5. Proceso de administracin del modelo IaaS .......................................... 110 7.3.6. Procedimiento de consulta de la trazabilidad del modelo IaaS .............. 111 7.3.7. Procedimiento de administracin de los laboratorios ............................. 112 7.3.8. Procedimiento de administracin de las mquinas fsicas ..................... 112 7.3.9. Proceso de administracin de la infraestructura base ............................ 113 7.3.10. Procedimientos adicionales ................................................................ 114 7.4. PRUEBAS Y RESULTADOS DE UNACLOUD .......................................... 115 7.4.1. Caractersticas de la infraestructura de despliegue................................ 115 7.4.2. Pruebas para la validacin de las estrategias de virtualizacin y oportunista........................................................................................................... 117

7.4.3. Pruebas de tiempos de respuesta de UnaCloud .................................... 121 7.4.4. Pruebas en el contexto grid computing .................................................. 122 7.4.5. Pruebas en el contexto cloud computing................................................ 124 8. CONCLUSIONES Y TRABAJO FUTURO .................................................... 128 9. BIBLIOGRAFA ............................................................................................. 132 ANEXOS ............................................................................................................. 140 ANEXO A - IMPLEMENTACIONES DE LA COMPUTACIN OPORTUNISTA .. 140 ANEXO A1 - WORM ........................................................................................... 140 ANEXO A2 - CONDOR ....................................................................................... 141 ANEXO A3 - GIMPS ............................................................................................ 143 ANEXO A4 - SETI@HOME ................................................................................. 144 ANEXO A5 - [Link] ....................................................................... 146 ANEXO A6 - BOINC ............................................................................................ 147 ANEXO A7 - BAYANIHAN COMPUTING .NET................................................... 149 ANEXO A8 - OURGRID ...................................................................................... 150 ANEXO A9 - INTEGRADE .................................................................................. 152 ANEXO B - DIAGRAMAS DE CLASES .............................................................. 155 ANEXO B1 - DIAGRAMA DE CLASES DE UNACLOUD SERVER ................... 155 ANEXO B2 - DIAGRAMA DE CLASES DE UNACLOUD CLIENT ..................... 157 ANEXO C - HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD ........................................................................................................ 160 ANEXO C1 HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD SERVER ........................................................................................ 160 ANEXO C2 - HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD CLIENT .......................................................................................... 161

NDICE DE FIGURAS Figura 1. Modelos de servicio cloud computing ..................................................... 21 Figura 2. Diagrama de despliegue de un hypervisor ............................................. 24 Figura 3. Modelos de despliegue cloud computing ............................................... 26 Figura 4. Diagrama de despliegue de Amazon EC2 ............................................. 30 Figura 5. Arquitectura de Nimbus .......................................................................... 33 Figura 6. Arquitectura de OpenNebula .................................................................. 35 Figura 7. Diagrama de despliegue de Eucalyptus ................................................. 37 Figura 8. Diagrama de despliegue de VMware View ............................................. 39 Figura 9. Arquitectura de VMware vSphere........................................................... 40 Figura 10. Arquitectura de UnaGrid ....................................................................... 51 Figura 11. Estrategia de virtualizacin de UnaCloud ............................................. 71 Figura 12. Estrategia oportunista de UnaCloud..................................................... 72 Figura 13. Visin general de la arquitectura de UnaCloud .................................... 77 Figura 14. Diagrama de componentes de la arquitectura de UnaCloud ................ 80 Figura 15. Diagrama de componentes de la arquitectura de UnaCloud Server .... 81 Figura 16. Diagrama de componentes de la arquitectura de UnaCloud Client ...... 88 Figura 17. Proceso de personalizacin del modelo IaaS en UnaCloud ................. 92 Figura 18. Proceso de despliegue del modelo IaaS en UnaCloud ........................ 93 Figura 19. Proceso de administracin del modelo IaaS en UnaCloud .................. 94 Figura 20. Proceso de administracin de la infraestructura base en UnaCloud .... 95 Figura 21. Protocolo de seguridad entre UnaCloud Server y UnaCloud Client ..... 97 Figura 22. Protocolo de seguridad entre UnaCloud Client y UnaCloud Server ..... 98 Figura 23. Proceso de despliegue de un CVC en GUMA. ................................... 101 Figura 24. Autenticacin de usuarios UnaCloud. ................................................ 104 Figura 25. Administracin de usuarios UnaCloud. .............................................. 104 Figura 26. Personalizacin del tipo de sistema operativo. .................................. 105 Figura 27. Personalizacin de la versin del sistema operativo. ......................... 106 Figura 28. Personalizacin del conjunto de aplicaciones. ................................... 106 Figura 29. Consulta del listado de aplicaciones. ................................................. 106 Figura 30. Personalizacin del tamao del disco duro. ....................................... 107 Figura 31. Personalizacin del nmero de ncleos de procesamiento. .............. 107 Figura 32. Personalizacin del tamao de la memoria RAM. .............................. 108 Figura 33. Personalizacin del nmero de instancias y el tiempo de ejecucin. . 108 Figura 34. Personalizacin del modelo IaaS con localizacin de ejecuciones. ... 109 Figura 35. Consola de administracin del despliegue del modelo IaaS. ............. 110 Figura 36. Monitoreo del modelo IaaS. ............................................................... 110 Figura 37. Administracin del tiempo de ejecucin del modelo IaaS. ................. 111 Figura 38. Reporte de la trazabilidad de uso del modelo IaaS. ........................... 111 Figura 39. Administracin de los laboratorios que soportan a UnaCloud. ........... 112

Figura 40. Administracin de las mquinas fsicas que soportan a UnaCloud. ... 113 Figura 41. Administracin de la infraestructura fsica que soporta a UnaCloud. . 113 Figura 42. Monitorizacin de la infraestructura fsica que soporta a UnaCloud. . 114 Figura 43. Administracin de las mquinas virtuales. ......................................... 115 Figura 44. Infraestructura de despliegue de UnaCloud. ...................................... 117 Figura 45. Uso simultneo del procesador por parte del usuario y la mquina virtual. .................................................................................................................. 119 Figura 46. Diagrama de despliegue de varios segmentos worm ......................... 140 Figura 47. Arquitectura de Condor ...................................................................... 142 Figura 48. Diagrama de despliegue de GIMPS ................................................... 144 Figura 49. Diagrama de despliegue de SETI@home .......................................... 145 Figura 50. Diagrama de despliegue de [Link] ....................................... 147 Figura 51. Arquitectura de BOINC....................................................................... 148 Figura 52. Diagrama de despliegue de Bayanihan Computing .NET .................. 149 Figura 53. Diagrama de despliegue de OurGrid .................................................. 151 Figura 54. Arquitectura de InteGrade .................................................................. 153 Figura 55. Diagrama de clases de UnaCloud Server .......................................... 156 Figura 56. Diagrama de clases de UnaCloud Client ............................................ 158 Figura 57. Estructura de implementacin de UnaCloud Server........................... 160 Figura 58. Estructura de implementacin de UnaCloud Client. ........................... 162

NDICE DE TABLAS Tabla 1. Definiciones de cloud computing en construccin. .................................. 18 Tabla 2. Caractersticas de cloud computing......................................................... 19 Tabla 3. Clasificacin de proveedores IaaS .......................................................... 22 Tabla 4. Clasificacin de proveedores PaaS ......................................................... 23 Tabla 5. Clasificacin de proveedores SaaS ......................................................... 23 Tabla 6. Comparacin y evaluacin de las implementaciones del modelo IaaS frente a las caractersticas de cloud computing..................................................... 42 Tabla 7. Identificacin de aspectos tiles para el desarrollo de UnaCloud ........... 53 Tabla 8. Evaluacin de aspectos tiles para el desarrollo de UnaCloud ............... 54 Tabla 9. Requerimientos asociados a la infraestructura base ............................... 58 Tabla 10. Comparacin y evaluacin de las implementaciones del modelo IaaS frente a los requerimientos asociados a la infraestructura oportunista .................. 59 Tabla 11. Comparacin y evaluacin del estado de la computacin oportunista frente a cloud computing ....................................................................................... 62 Tabla 12. Implementacin del componente Web interface. ................................... 82 Tabla 13. Implementacin del componente Customized Environment Manager. .. 83 Tabla 14. Implementacin del componente Virtual Machine Manager. ................. 84 Tabla 15. Implementacin del componente Persistence Manager. ....................... 85 Tabla 16. Implementacin del componente Physical Infrastructure Manager. ...... 85 Tabla 17. Implementacin del componente Server Communication Manager. ..... 86 Tabla 18. Implementacin del componente Server Security Manager. ................. 87 Tabla 19. Implementacin del componente Client Communication Manager. ....... 89 Tabla 20. Implementacin del componente Client Security Manager. ................... 89 Tabla 21. Implementacin del componente Context Manager. ............................. 89 Tabla 22. Implementacin del componente Hypervisor Manager. ......................... 90 Tabla 23. Implementacin del componente Local Executor Manager. .................. 90 Tabla 24. Implementacin del componente Monitoring Manager. ......................... 91 Tabla 25. Comparacin entre los prototipos implementados .............................. 102 Tabla 26. Caractersticas de la infraestructura de despliegue ............................. 116 Tabla 27. Impacto de las tareas intensivas en procesamiento ............................ 118 Tabla 28. Impacto de las tareas intensivas en entrada y salida (I/O) .................. 118 Tabla 29. Validacin de UnaCloud contra las caractersticas de la computacin oportunista........................................................................................................... 120 Tabla 30. Prueba de tiempos de respuesta de UnaCloud ................................... 121 Tabla 31. Caractersticas del CVC de bioinformtica .......................................... 123 Tabla 32. Principales contribuciones al proyecto Campus Grid Uniandes .......... 123 Tabla 33. Caractersticas de las mquinas virtuales de prueba .......................... 125 Tabla 34. Validacin de UnaCloud contra las caractersticas generales de cloud computing ............................................................................................................ 126

1. INTRODUCCIN Entre los ms recientes paradigmas de la computacin, grid computing1 (1) y cloud computing (2) parecen ser los de mayor prospectiva (3). Grid computing es considerado un paradigma en produccin que ha adquirido una enorme relevancia al satisfacer las necesidades de grandes capacidades computacionales para el desarrollo de la e-Ciencia. La investigacin acadmica y cientfica alrededor de grid computing ha contribuido notablemente a su madurez, conllevando al desarrollo de estndares, arquitecturas, tecnologas, herramientas y aplicaciones que en la mayora de los casos son abiertas y de propsito general (4). En contraposicin, cloud computing es considerado un paradigma en desarrollo (5), cuya madurez puede considerarse en etapa de infancia (6). Al tratarse del ms reciente paradigma de la computacin (2), aun no existen acuerdos generales para su definicin (7) y hay discrepancia en cuanto a sus posibles arquitecturas, modelos y estndares. Sin embargo, cloud computing es considerado el paradigma sucesor de grid computing (8), especialmente porque supone una evolucin disruptiva del mismo al tener como objetivo la personalizacin y entrega de infraestructuras computacionales, software y aplicaciones como servicios de alta usabilidad. Estos servicios ocultan al usuario la mayora de las complejidades asociadas a la administracin de la infraestructura base, pueden ser desplegados bajo demanda, son facturados en un modelo de pago por uso y generalmente son accedidos remotamente a travs de Internet (9). Aunque se considera que las mayores expectativas acerca del paradigma cloud computing estarn en fase de produccin dentro de 1 a 5 aos (10). Cloud computing est captando una gran atencin alrededor del mundo (11), (12), no nicamente la de expertos en tecnologas de informacin y comunicaciones (TICs), sino tambin acadmicos, cientficos, investigadores, empresarios y personas del comn, que se ven atrados por la entrega de infraestructuras y servicios computacionales bajo demanda (13). Este novedoso paradigma est adquiriendo una fortaleza inesperada en el mercado mundial de las tecnologas de informacin (TI), pronosticndose una participacin del orden de billones de dlares para los prximos aos, segn estudios publicados por firmas de consultora e investigacin internacionales, como es el caso de Gartner (14), Merrill Lynch (15), IDC (16), entre otras.

El autor usa terminologa tcnica en idioma ingls al considerarla de comn uso en el medio acadmico e ingenieril, esta incluye palabras como: cluster computing, grid computing, cloud computing, Infrastructure as a Service IaaS, Platform as a Service PaaS, Software as a Service SaaS, middleware, Web, framework, broadcast, open source, entre otras. Adicionalmente, el nombramiento de los componentes de la arquitectura de UnaCloud y todas las figuras del documento fueron elaboradas en idioma ingls para facilitar su divulgacin.

El desarrollo actual de cloud computing tiene dos actores fundamentales. El primero lo constituyen ms de 600 empresas del sector TI, incluyendo a gigantes informticos como es el caso de: Google, IBM, Microsoft, Oracle, Amazon, entre otros. Ellos han desarrollado implementaciones propietarias a gran escala enfocadas en la tercerizacin de centros de cmputo, el soporte a aplicaciones de negocio, redes sociales, portales de videojuegos y redes de distribucin de contenido, estas incluyen a: Google App Engine (17), IBM BlueHouse (18), Microsoft Windows Azure (19), Sun [Link] (Sun Grid) (20), Amazon Web Services (21), [Link] (22), entre muchas otras. El segundo actor lo representa la comunidad acadmica y cientfica, responsable del desarrollo de implementaciones abiertas y de propsito experimental, incluyendo proyectos como Eucalyptus (23), Nimbus (24), OpenNebula (25), Reservoir (26), entre otros. Su objetivo se ha enfocado en la necesidad de investigar las potencialidades de cloud computing para suplir la falencias y complejidades innecesarias que el paradigma grid computing ha supuesto tradicionalmente en su esfuerzo por soportar el desarrollo de la e-Ciencia, particularmente en reas como la medicina, la biologa, la fsica, la optimizacin de modelos ingenieriles y la educacin. Si bien existen muchas diferencias entre las implementaciones propietarias y abiertas, la diferencia ms relevante la constituye el presupuesto otorgado para la investigacin y la experimentacin cloud computing por parte del sector comercial. Presupuesto visible en colosales inversiones en centros de cmputo y tecnologas de vanguardia con capacidad para soportar modelos de servicio y despliegue cloud computing a escala mundial. Sin embargo, las actuales implementaciones abiertas no distan totalmente de este enfoque. Su instalacin requiere de grandes inversiones en recursos computacionales dedicados, incluyendo servidores de administracin, nodos dedicados a la ejecucin y provisin de recursos para mquinas virtuales, sistemas de almacenamiento especializados e infraestructuras de redes de alta velocidad, motivo por el cual son una opcin prcticamente inviable en organizaciones y pases con recursos econmicos escasos. En forma adicional, el proceso de implementacin de un ambiente cloud computing es complejo y extenso. Cloud computing tiene tres modelos de servicio que incluyen la provisin de infraestructuras computacionales (procesamiento, memoria, almacenamiento y redes) como servicio (Infrastructure as a Service IaaS), plataformas de desarrollo como servicio (Platform as a Service PaaS) y software como servicio (Software as a Service SaaS). Estos tres modelos son naturalmente dependientes de una infraestructura computacional base, por lo cual no es sorprendente que la mayora de las iniciativas comerciales, acadmicas y cientficas se hayan fundado en implementaciones parciales del modelo de servicio IaaS (modelo IaaS para abreviar), algunas de las cuales planean integrar modelos PaaS y SaaS en versiones futuras de mayor madurez. 10

Teniendo en cuenta la relevancia emergente del paradigma cloud computing, la necesidad de su investigacin y experimentacin en independencia de proveedores comerciales, las dificultades econmicas asociadas a los recursos dedicados para el soporte de su infraestructura base (incluso mediante el uso de implementaciones abiertas) y la jerarqua en la implementacin de sus modelos de servicio y despliegue. En este trabajo de investigacin se presenta a UnaCloud, una implementacin a medida del modelo IaaS, que tiene como objetivo la entrega de servicios computacionales fundamentales, haciendo uso oportunista de los recursos de cmputo actualmente disponibles en la Universidad de los Andes, para proveer una plataforma de investigacin y experimentacin cloud computing escalable y a bajo costo. UnaCloud aprovecha las capacidades computacionales dispersas en computadores y servidores (prevalentemente econmicos), que soportan las labores informticas de estudiantes, docentes y personal administrativo de la Universidad de los Andes. Estos computadores y servidores conforman una infraestructura de crecimiento horizontal que tiende a estar subutilizada por periodos de tiempo significativos, lo cual redunda en la abundancia de recursos computacionales ociosos. Dado el nmero de computadores y servidores disponibles en la universidad, esta solucin es econmicamente atractiva para la construccin de infraestructuras computacionales a gran escala, como aquellas requeridas para la implementacin de tecnologas y modelos de servicio cloud computing. UnaCloud es una solucin oportunista que supera las problemticas asociadas al aprovechamiento de recursos computacionales preexistentes, caracterizados por su distribucin, alta heterogeneidad, independencia de dominio administrativo y disponibilidad parcial. Estas problemticas han sido objeto de estudio del paradigma de la computacin oportunista (27), por lo cual UnaCloud representa una convergencia entre los paradigmas cloud computing y la computacin oportunista. El primero de ellos analizado como una finalidad, particularmente en lo relacionado al modelo IaaS y el segundo analizado como un medio, particularmente en lo relacionado a estrategias oportunistas de abastecimiento de infraestructuras computacionales de crecimiento horizontal, se define esto como infraestructuras basadas en la agregacin escalable de laboratorios de cmputo y recursos computacionales individuales, no dedicados, distribuidos, heterogneos y prevalentemente subutilizados. UnaCloud utiliza una estrategia de virtualizacin que adems de optimizar y agilizar el aprovisionamiento, la reutilizacin y asignacin de recursos computacionales bajo demanda, facilita la ejecucin de aplicaciones e-Ciencia en sus ambientes nativos, mayoritariamente Linux, con todas las configuraciones de middlewares, frameworks, libreras, etc. sobre recursos computacionales del campus de la Universidad de los Andes, cuyo sistema operativo predominante es 11

Windows. Adicionalmente UnaCloud utiliza una estrategia de control de impacto que le permite aprovechar recursos compartidos simultneamente con otros usuarios sin afectar la calidad de servicio percibida por los mismos. UnaCloud provisiona una plataforma de experimentacin multipropsito del modelo IaaS, totalmente extensible a otros modelos de servicio cloud computing como PaaS y SaaS. Esta plataforma es capaz de desplegar ambientes personalizados de ejecucin bajo demanda, cuya versatilidad implcita, facilita su adaptacin dinmica a las necesidades emergentes no solo en el desarrollo de la e-Ciencia, sino tambin en el soporte o mejoramiento de actividades de naturaleza acadmica o incluso comercial. Por otra parte, UnaCloud representa un mejoramiento a las iniciativas actuales grid computing de la Universidad de los Andes. Esto incluye al proyecto Campus Grid Uniandes2 (28) y su sub proyecto UnaGrid (29), los cuales a travs del estudio, integracin y aprovechamiento de las caractersticas, oportunidades y ventajas de modelo IaaS, han sido extendidos a travs del legado de UnaCloud para superar los logros en investigacin y desarrollo en e-Ciencia hasta ahora alcanzados. Este documento se desarrolla de la siguiente forma: en el segundo captulo se revisan aspectos conceptuales e introductorios al paradigma cloud computing, esto incluye una revisin y evaluacin al estado del arte del modelo IaaS. En el tercer captulo se revisan aspectos conceptuales de la computacin oportunista, esto incluye una revisin al estado del arte de las implementaciones que han aportado el conjunto ms representativo de estrategias y aspectos de diseo e implementacin oportunistas. En el cuarto captulo se evalan las implementaciones del modelo IaaS y de la computacin oportunista en trminos de los objetivos del presente trabajo de investigacin. En el quinto captulo se elabora una descripcin general de la estrategia de solucin implementada a travs de UnaCloud, esto incluye la definicin de sus principales estrategias y el alcance del proyecto. En el sexto captulo se presenta a UnaCloud en trminos de su arquitectura y servicios, esto incluye la descripcin de las arquitecturas de alto y bajo nivel, los modelos de procesos y los mecanismos de comunicaciones incorporados en UnaCloud. En el sptimo captulo se describe y analiza la implementacin, pruebas y resultados obtenidos con UnaCloud, incluyendo la validacin de todos los objetivos y requerimientos planteados en el alcance funcional y no funcional del proyecto. Finalmente, en el octavo captulo se presentan las conclusiones y se plantea un trabajo futuro orientado a dar continuidad al presente trabajo de investigacin.

Proyecto fundado parcialmente por ECOS-NORD action C06M02.

12

1.1. CONTEXTO El trabajo de investigacin descrito en este documento se enmarca en el contexto del proyecto Campus Grid Uniandes, una iniciativa de la Universidad de los Andes, cuyo propsito primordial es la construccin y despliegue de una infraestructura a gran escala, capaz de satisfacer las demandas de capacidades computacionales que exige el desarrollo de la e-Ciencia. Este proyecto se ha dividido en dos grandes reas de trabajo: las infraestructuras basadas en recursos computacionales dedicados, formalmente conocidas como grid de servicios y las infraestructuras basadas en el aprovechamiento de recursos computacionales parcialmente disponibles, formalmente conocidas como grid oportunistas. En el rea de trabajo de los grid oportunistas, mltiples esfuerzos de investigacin han conllevado al diseo e implementacin de UnaGrid, una infraestructura grid virtual oportunista capaz de aprovechar los ciclos computacionales ociosos de los computadores disponibles en los laboratorios de informtica del Departamento de Ingeniera de Sistemas y Computacin. Esta infraestructura garantiza a los usuarios de los recursos compartidos, tener prioridad para el acceso a los recursos fsicos, mientras en forma paralela se aprovechan los recursos ociosos o sub utilizados por los mismos, para suplir a bajo costo los requerimientos computacionales exigidos para el desarrollo de proyectos grid computing acadmicos e investigativos. UnaGrid se basa en dos estrategias base. La primera estrategia es el uso de la tecnologa de virtualizacin VMware (30) para facilitar el encapsulamiento de ambientes de ejecucin personalizados. Esto se logra al fabricar mquinas virtuales con todas las instalaciones y configuraciones de sistemas operativos, middlewares, frameworks, herramientas y libreras, necesarias para la ejecucin apropiada de aplicaciones grid computing. La segunda estrategia se basa en la ejecucin de mquinas virtuales (que componen un ambiente de ejecucin personalizado), como procesos en background de prioridad baja. Esto permite el despliegue de infraestructuras grid virtuales oportunistas en forma paralela a la ejecucin de los procesos de un usuario de un recurso compartido, sin afectar la calidad de servicio percibida por el mismo durante el ejercicio de sus labores cotidianas. UnaGrid ha permitido la creacin y despliegue de infraestructuras computacionales que han suplido los requerimientos de aplicaciones y proyectos grid computing en diferentes reas del conocimiento, incluyendo la bioinformtica, qumica computacional e ingeniera industrial. UnaGrid ha mejorado notablemente el tiempo que toma la generacin de resultados, producto de la ejecucin eficiente de aplicaciones multipropsito que requieren grandes capacidades de 13

procesamiento. Adicionalmente, UnaGrid ha promovido el trabajo multidisciplinario entre diferentes grupos de investigacin, los cuales pueden desplegar sus propias infraestructuras grid, compartiendo y reutilizando una misma infraestructura fsica. A pesar de los resultados obtenidos a travs de UnaGrid, su implementacin dista de un estado maduro y actualmente existen problemticas asociadas a su personalizacin de servicios bajo demanda, usabilidad, escalabilidad, seguridad, trazabilidad de uso de recursos, monitorizacin y administracin delegada. Estas problemticas son trasversales a su naturaleza grid computing, fundamentalmente en los procesos asociados al abastecimiento y provisin de infraestructuras computacionales oportunistas a gran escala. En este contexto, el trabajo descrito en este documento retoma los avances3 y aborda las problemticas actualmente existentes en UnaGrid. Estas problemticas incluyen la necesidad de una infraestructura computacional de crecimiento horizontal, capaz de satisfacer grandes demandas computacionales a bajo costo. Por este motivo, uno de los objetivos de este trabajo consiste en contribuir al proyecto Campus Grid Uniandes y su sub proyecto UnaGrid, extendiendo sus funcionalidades a travs del estudio e integracin de las caractersticas, oportunidades y ventajas del paradigma cloud computing, particularmente del modelo IaaS implementado a travs de UnaCloud. Sin embargo, el alcance de este trabajo de investigacin no se limita al contexto de extensin de UnaGrid y aborda un contexto adicional, completamente acorde con la necesidad de investigacin y experimentacin con el paradigma cloud computing. En este contexto, el presente trabajo de investigacin tiene como objetivo el despliegue, la administracin y entrega de una plataforma de experimentacin del modelo IaaS, extensible a modelos de servicio cloud computing PaaS y SaaS. Esta plataforma de naturaleza verstil puede ser utilizada no solamente para el desarrollo de la e-Ciencia, sino tambin para mejorar o soportar el desarrollo de actividades acadmicas e incluso comerciales, que tengan grandes demandas de recursos computacionales.

El autor es parte de un equipo de trabajo que ha aportado activamente al desarrollo de UnaGrid. Este equipo de trabajo ha publicado varios artculos de investigacin entre los cuales se encuentran (165), (174) y (175).

14

1.2. OBJETIVO PRINCIPAL Desarrollar un modelo IaaS de cloud computing, que entregue recursos y servicios computacionales fundamentales, soportndose en una infraestructura computacional oportunista de crecimiento horizontal. 1.3. OBJETIVOS ESPECFICOS Validar y extender el estado de la computacin oportunista, en relacin al modelo IaaS de cloud computing. Definir la arquitectura de un modelo IaaS soportado en infraestructuras computacionales oportunistas de crecimiento horizontal. Desarrollar un prototipo capaz de desplegar, administrar y entregar una plataforma de experimentacin del modelo IaaS, mediante el aprovechamiento oportunista de la infraestructura computacional disponible en los laboratorios de informtica del Departamento de Ingeniera de Sistemas y Computacin de la Universidad de los Andes. Contribuir a los objetivos del proyecto Campus Grid Uniandes.

15

2. CLOUD COMPUTING Este captulo tiene como objetivo revisar, integrar y complementar aspectos conceptuales e introductorios al paradigma cloud computing. Adicionalmente se tiene como objetivo revisar el estado del arte de las principales implementaciones del modelo IaaS de cloud computing, para identificar aspectos crticos para el diseo e implementacin de UnaCloud. Este captulo se organiza de la siguiente forma: en la primera seccin se abordan aspectos conceptuales del paradigma cloud computing, en la segunda seccin se revisan implementaciones acadmicas y comerciales del modelo IaaS, finalmente en la tercera seccin se realiza una evaluacin a las implementaciones estudiadas. 2.1. ASPECTOS CONCEPTUALES En esta seccin se abordan aspectos conceptuales de cloud computing, esto incluye un breve contexto histrico, el estudio de definiciones en construccin, la identificacin y seleccin de caractersticas relevantes, la propuesta de una definicin propia, la definicin de la virtualizacin como una tecnologa de apoyo y la identificacin de modelos de servicio, modelos de despliegue, ventajas y desventajas de cloud computing. 2.1.1. Contexto histrico En el ao de 1961, John McCarthy inventor del lenguaje de programacin LISP vision: un da la computacin estar organizada como un servicio pblico (31), posteriormente el 3 de julio del ao de 1969, Leonard Kleinrock uno de los cientficos a cargo del proyecto ARPANET (Advanced Research Projects Agency Network), el cual sent las bases de Internet, dijo: actualmente las redes de computadoras estn en su infancia, pero en la medida en que crezcan y se vuelvan sofisticadas, probablemente veremos el nacimiento de servicios de computacin los cuales, al igual que los servicios de electricidad y telfono, llegarn a cada casa y oficina alrededor de todo el pas (32). Estas visiones se anticipaban a la aparicin de nuevos paradigmas de computacin fortalecidos por el desarrollo de tecnologas de vanguardia capaces de proveer medidas de desempeo, eficiencia, escalabilidad, distribucin, autonoma y ubicuidad, nunca antes vistas. Estos novedosos paradigmas de la computacin incluyen: cluster computing (33), grid computing, global computing (34), Internet computing (35), peer-to-peer computing (P2P) (36), ubiquitous computing (37), utility computing (38) y ms recientemente cloud computing, derivada del trmino cloud, usado como metfora de infraestructuras tecnolgicas complejas y cuyo origen se remite a la dcada de los 90, en referencia a las ya enormes redes ATM (Asynchronous Transfer Mode) (39). 16

En el ao de 1999, Marc Benioff, Parker Harris y otros socios, fundaron la compaa [Link] (22), aplicando tecnologas desarrolladas por compaas como Google y Yahoo! a diversas aplicaciones de negocio. Ellos fortalecieron la entrega de servicios bajo demanda, particularmente SaaS, vindose respaldados por miles de clientes y negocios exitosos (40). A inicios del ao 2000, Yahoo! y Google anunciaron la prestacin de servicios cloud a cuatro de las ms grandes universidades de Estados Unidos: la Universidad de Carnegie Mellon, la Universidad de Washington, la Universidad de Stanford y el Massachusetts Institute of Technology (MIT). Poco tiempo despus IBM Corp. anunci el ofrecimiento de servicios cloud, seguido por gigantes informticos como Microsoft, Oracle, Intel, SUN, SAS y Adobe, cuyos enfoques abarcaron la provisin de modelos IaaS, PaaS y SaaS. Sin embargo, se considera que el inicio de cloud computing, puede ser atribuido a la aparicin de los servicios Web de Amazon (Amazon Web Services) (21), que iniciaron su produccin en el ao 2006 ofreciendo el modelo IaaS con capacidades bsicas de procesamiento y almacenamiento a travs de Internet (39). Amazon Web Services populariz el modelo IaaS, convirtindolo en una de las nociones principales de cloud computing (41). Su novedosa estrategia permiti la ejecucin personalizada y bajo demanda de mquinas virtuales Linux en infraestructuras computacionales con una complejidad totalmente oculta a los usuarios finales. Esta estrategia minimiz e incluso elimin los costos capitales para los consumidores de servicios cloud, otorgndoles la posibilidad de aumentar o disminuir las capacidades de su infraestructura computacional para satisfacer los picos o las fluctuaciones en la demanda de servicios TI, pagando nicamente por la capacidad consumida bajo un modelo de facturacin basado en tarifas horarias. 2.1.2. Definiciones en construccin Cloud computing es an un paradigma en evolucin, sus definiciones, arquitecturas, modelos, casos de uso, tecnologas base, problemas, riesgos y beneficios, sern continuamente redefinidos en debates promocionados por el sector pblico y privado (42). Al tratarse del ms reciente paradigma de la computacin (2), aun no existen acuerdos generales para su definicin (39), (43), (44) y su madurez an puede considerarse en etapa de infancia (6), (45), (46). En general, cloud computing hace referencia a un novedoso aprovisionamiento de infraestructuras, plataformas de desarrollo y software que son entregados como un servicio (47). Este aprovisionamiento est basado principalmente en paradigmas y tecnologas como utility computing, grid computing y la virtualizacin. Paradigmas y tecnologas que no pueden considerarse nuevas (48), (49), pero que han madurado para permitir a cloud computing, diferenciarse del escenario de 17

centralizacin de recursos, propuesto hace ms de 50 aos con la aparicin de servidores robustos compartidos por tiempo. Cloud computing ha brindando nuevas posibilidades para construir y desplegar infraestructuras computacionales y servicios complejos (49), que pueden ser accedidos bajo demanda, ser utilizados desde cualquier lugar, a cualquier hora, ocultando las complejidades de la infraestructura base a los usuarios finales (50). En esta revisin se estudiaron ms de veinte definiciones de cloud computing en construccin (3), (7), (39), (42), (44), (50), (51), (52), (53), (54), (55), (56), (57), (58), (59), (60), (61), (62), (63), (64), (65), (66), las cuales plantean acercamientos orientados desde el punto de vista histrico, tecnolgico, cientfico y comercial. La Tabla 1, resume algunas de ellas por considerarlas de mayor relevancia dada la trayectoria y prestigio de la fuente, as como el nivel de aceptacin y referencias a las mismas por parte de la industria y la comunidad acadmica y cientfica. Tabla 1. Definiciones de cloud computing en construccin.

DEFINICIONES DE CLOUD COMPUTING Un modelo conveniente para permitir el acceso por red y bajo demanda, a un conjunto de recursos computacionales compartidos y configurables (por ejemplo, servidores, almacenamiento, redes, aplicaciones y servicios) que pueden ser abastecidos rpidamente y desplegados con un mnimo esfuerzo de gestin o interaccin con el proveedor de servicios (42).

Instituto Nacional de Estndares y Tecnologa (National Institute of Standards and Technology NIST) de Estados Unidos Forrester Inc.

Un conjunto de infraestructuras computacionales Research, abstradas, altamente escalables y administrables, capaces de albergar aplicaciones del consumidor final y facturar por su consumo (64). Un estilo de computacin donde se provee como un servicio, capacidades TI, masivamente escalables, a Gartner, Inc. mltiples clientes externos, usando tecnologas de Internet (65). Un tipo de sistema paralelo y distribuido compuesto por un conjunto de computadores virtualizados e interconectados que son abastecidos dinmicamente y Rajkumar Buyya y presentados como uno o ms recursos computacionales unificados, soportados por acuerdos otros de nivel de servicios, establecidos mediante la negociacin entre el consumidor y el proveedor de servicios (3). 18

2.1.3. Caractersticas principales A partir de todas las definiciones estudiadas, se hizo un anlisis comparativo para extraer las caractersticas de cloud computing comnmente referenciadas. Como se puede apreciar en la Tabla 2, se determinaron 3 categoras generales con 13 caractersticas consideradas de mayor relevancia por la cantidad de referencias efectuadas, as como por representar puntos de encuentro conceptuales entre las diferentes fuentes o autores. Caractersticas como la usabilidad, el modelo de autoservicio, la personalizacin de servicios bajo demanda, el uso de tecnologas de virtualizacin, la administracin delegada, la escalabilidad, el acceso a travs de red y los modelos de trazabilidad son las caractersticas ms referenciadas. Por otra parte, caractersticas como la centralizacin de la infraestructura base y la auto regulacin en el gasto de energa elctrica fueron exceptuadas al ser referenciadas en contextos no genricos. Tabla 2. Caractersticas de cloud computing

CON RESPECTO A LOS USUARIOS FINALES El proveedor de servicios debe ofrecer mecanismos de acceso con interfaces de usuario de alta usabilidad, cuya operacin casi intuitiva, requiera conocimientos bsicos de TI. El usuario final debe poder consumir servicios computacionales con una mnima o nula interaccin humana con el proveedor de servicios, incentivando un modelo de consumo basado en el autoservicio. El proveedor de servicios debe garantizar un nivel de ubicuidad para el acceso a las infraestructuras computacionales, software o aplicaciones desplegadas, ofreciendo servicios que pueden ser invocados por el usuario final desde redes internas, externas y principalmente Internet.

Usabilidad

Modelo de autoservicio

Acceso a travs de red

CON RESPECTO AL DESPLIEGUE DE LOS SERVICIOS COMPUTACIONALES Personalizacin de servicios bajo demanda Dependiendo del modelo de servicio (IaaS, PaaS y SaaS), el usuario debe poder seleccionar bajo demanda el tipo de infraestructura, software o aplicacin que desea consumir como un servicio, as como aplicar configuraciones personalizadas para el 19

Modelo multiusuario

Virtualizacin

Escalabilidad

Interoperabilidad y bajo acoplamiento

Extensibilidad

despliegue del mismo. Esto debe facilitar la creacin de ambientes personalizados de desarrollo, pruebas y produccin que son desplegados, asignados y accedidos bajo la demanda del usuario final. El proveedor de servicios debe poseer infraestructuras computacionales, software o aplicaciones aprovechables mediante un modelo de uso multiusuario que optimice el uso de la infraestructura base. El proveedor de servicios debe poseer infraestructuras computacionales virtuales con la finalidad de asignar recursos y proveer servicios en forma eficiente, dinmica y elstica (conforme a la demanda). El proveedor de servicios debe poseer infraestructuras computacionales, software y aplicaciones capaces de operar eficientemente bajo modelos de consumo, crecimiento y abastecimiento escalables. El proveedor debe desarrollar servicios de alta interoperabilidad y bajo acoplamiento capaces de operar en ambientes distribuidos y de alta heterogeneidad, facilitando su integracin con componentes, aplicaciones o infraestructuras pertenecientes al usuario final o incluso a otros proveedores. El proveedor debe desarrollar servicios de alta extensibilidad que faciliten la agregacin, especializacin o modificacin de funciones generales con la finalidad de adaptarse a requerimientos especficos.

CON RESPECTO A LA ADMINISTRACIN DE LA INFRAESTRUCTURA BASE El proveedor de servicios debe ocultar al usuario final, la mayora de complejidades asociadas a la infraestructura computacional base, incluyendo tareas pertinentes a su administracin, mantenimiento y actualizacin. El proveedor de servicios est en capacidad de cumplir acuerdos de nivel de servicio pactados con el usuario final, con el fin de proveer calidad sobre los servicios ofrecidos. El proveedor de servicios debe poseer mltiples mecanismos de seguridad para proteger la infraestructura computacional y los datos de los usuarios finales. Esto incluye mecanismos de autorizacin, autenticacin, confidencialidad, integridad 20

Administracin delegada Acuerdos de nivel de servicio y calidad de servicio

Seguridad

Modelo de trazabilidad

y no repudio, as como mecanismos de proteccin y aislamiento de la infraestructura fsica, entre otros. El proveedor de servicios debe poseer mecanismos para registrar y monitorizar el uso de su infraestructura computacional, software o aplicaciones, permitiendo llevar trazabilidad de uso a nivel de usuario y la aplicacin opcional de modelos de facturacin de pago por uso.

2.1.4. Definicin propuesta Como parte del anlisis comparativo efectuado y teniendo como finalidad hacer un aporte al estado del arte de cloud computing, se propone la siguiente definicin: Cloud computing es un paradigma de la computacin caracterizado por permitir el acceso por red y bajo demanda a infraestructuras computacionales multiusuario, escalables, virtualizadas y configurables que son entregadas a usuarios finales en forma de servicios de alta usabilidad. Estos servicios pueden estar soportados por acuerdos de nivel de servicio y/o modelos de trazabilidad o pago por uso. 2.1.5. Modelos de servicio La mayora de las propuestas estudiadas, contemplan una arquitectura a partir de la definicin de tres modelos de servicio (ver la Figura 1). Es importante destacar que para cada uno de ellos, se propone una clasificacin de proveedores de servicios que integra y complementa los trabajos publicados en (3), (10) y (66). Los resultados de este proceso fueron publicados por el autor en (67).
SaaS PaaS IaaS
HARDWARE LAYER

Figura 1. Modelos de servicio cloud computing.

Modelo IaaS: contempla la entrega de servicios de infraestructura, tambin denominados servicios computacionales fundamentales, entre los cuales se encuentran: almacenamiento, procesamiento y memoria. Dicha infraestructura es desplegada bajo demanda, permitiendo a los usuarios el despliegue de aplicaciones sobre un sistema operativo principal. En este modelo de servicio, el usuario final no administra ni controla la infraestructura base cloud computing, pero puede controlar dispositivos de almacenamiento, sistemas operativos, aplicaciones desplegadas y opcionalmente controlar componentes de red, tales 21

como un firewall o un enrutador. La Tabla 3, resume algunos ejemplos de proveedores o tecnologas IaaS. Tabla 3. Clasificacin de proveedores IaaS EJEMPLO Amazon Elastic Compute Cloud (Amazon EC2) (21), Sun [Link] (Sun Grid) (20), ElasticHosts (68), Procesamiento Eucalyptus (23), Nimbus (24), OpenNebula (25), Enomaly (69). Distribucin de Akamai (70), Amazon CloudFront Beta (71). contenido a travs de servidores virtuales Amazon Simple Storage Service (Amazon S3) (72), Amazon SimpleDB (73), Amazon Elastic Block Store Almacenamiento (74), Microsoft SkyDrive (75), Youtube (76), Nirvanix Storage Delivery Network (77), Microsoft Live Mesh Beta (78), Flickr (79). Administracin de Elastra (80), Engine Yard (81), FlexiScalable (82), Grid Layer (83), Joyent (84), Mosso (85), Savvis Virtual sistemas Intelligent Hosting (86). Administracin de Digital Realty Trust (87), [Link] (88), Layered Technology (89). alojamiento Rackspace (85), Savvis Virtual Intelligent Hosting (86), Alojamiento Terremark Worldwide (90), FlexiScalable (82), 1&1 autnomo Internet (91). VLAN (Virtual Local CohesiveFT (92). Area Network) Modelo PaaS: consiste en la provisin de plataformas de ejecucin como un servicio. Estas permiten la ejecucin de aplicaciones creadas o adquiridas por el usuario final con la restriccin de que su despliegue debe ajustarse a la infraestructura cloud computing disponible en el proveedor (lenguajes de programacin, middlewares, frameworks, herramientas soportadas, etc.). Al igual que en el modelo IaaS se oculta al usuario final todos los detalles de la infraestructura base cloud computing, pero este ocultamiento tambin incluye sistemas operativos, servidores, redes de telecomunicaciones, dispositivos de almacenamiento, entre otros. Sin embargo, se busca que el usuario tenga un alto grado de control sobre su plataforma de desarrollo y aplicaciones desplegadas, mediante un mecanismo estndar para su acceso y uso. La Tabla 4, resume algunos ejemplos de proveedores o tecnologas PaaS. TIPO DE SERVICIO

22

Tabla 4. Clasificacin de proveedores PaaS TIPO DE SERVICIO Plataformas desarrollo Base de datos Cola de mensajes Servidores aplicaciones EJEMPLO de Amazon Simple Queue Service (Amazon SQS) (93), Amazon Simple Storage Service (Amazon S3) (72), Google App Engine (17), GRIDS Lab Aneka (46). Amazon SimpleDB (73), Big Table (94), Microsoft SQL Azure Database (95). Amazon Simple Queue Service (Amazon SQS) (93). de NetSuite Business Operating System (NS-BOS) (96).

Modelo SaaS: consiste en la entrega exclusiva de software perteneciente al proveedor de servicios, a travs de la ejecucin de una instancia servidora dentro de la infraestructura cloud computing, que es invocada como un servicio por mltiples usuarios o aplicaciones cliente bajo un mecanismo de acceso por red. Este modelo de servicio se caracteriza por ocultar totalmente aspectos de administracin y control de la infraestructura base cloud computing, as como por permitir limitadas configuraciones al software por parte del usuario final. SaaS se diferencia del modelo de servicio PaaS por otorgar un menor grado de administracin, control y propiedad al usuario final con respecto al software que va a ser desplegado, incluyendo las configuraciones posibles sobre el mismo. Esto se debe a que su objetivo es la entrega de software como un servicio listo para ser consumido bajo demanda. La Tabla 5, resume algunos ejemplos de proveedores o tecnologas SaaS. Tabla 5. Clasificacin de proveedores SaaS TIPO DE SERVICIO Aplicaciones sitios Web Colaboracin aplicaciones oficina Servicios de pago Software basado en Web integrable a otras aplicaciones como EJEMPLO [Link] (97), Microsoft Office Live (98), Facebook (99), LinkedIn (100), Twitter (101), MySpace (102), Zillow (103), Google Maps (104). Cisco WebEx Weboffice (105), Google Docs (106), Google Talk (107), IBM BlueHouse (18), Microsoft Exchange Online (108), RightNow (109), Gmail (110), Microsoft Hotmail (111), Yahoo! Mail (112). Amazon Flexible Payments Service (Amazon FPS) (113), Amazon DevPay (114). Flickr Application Programming Interface (API) (79), Google Calendar API (115), [Link] AppExchange (116), Yahoo! Maps API (117), Zembly (118). 23

y de

2.1.6. Virtualizacin La virtualizacin es una tecnologa de apoyo utilizada en todos los modelos de servicio en cloud computing para asignar recursos y proveer servicios en forma eficiente, dinmica y elstica. La virtualizacin es una tecnologa basada en software, capaz de ejecutar mltiples sistemas operativos y aplicaciones sobre una arquitectura de hardware compartida (119). Estas ejecuciones se llevan a cabo mediante instancias de archivos, formalmente denominados mquinas virtuales. Una mquina virtual es el encapsulamiento de un sistema operativo y un conjunto de aplicaciones en un archivo que es ejecutado por un hypervisor. Un hypervisor es un software encargado de instanciar las mquinas virtuales sobre una infraestructura de hardware que puede ser compartida con un sistema operativo principal u otras mquinas virtuales (120). Existen dos tipos de hypervisors (121). Los hypervisors tipo I son aquellos que se instalan y ejecutan directamente sobre el hardware de la infraestructura computacional base. Estos hypervisors abstraen la capa de hardware facilitando la asignacin de cuotas de recursos computacionales para la ejecucin de mltiples mquinas virtuales. Los hypervisors tipo II son aquellos que se instalan y ejecutan sobre un sistema operativo principal que a su vez est instalado directamente sobre el hardware de la infraestructura computacional base. Estos hypervisors utilizan los servicios del sistema operativo para acceder al hardware disponible y son capaces de ejecutar mltiples mquinas virtuales compartiendo los recursos fsicos con el sistema operativo principal. La Figura 2 muestra el diagrama de despliegue de los hypervisors tipo I y II.

Guest Operating System 1... Guest Operating System 1 Guest Operating System 2 ...

Type II Hypervisor Main Operating System

Type I Hypervisor

CPU

MEMORY STORAGE

NETWORK

CPU

MEMORY STORAGE

NETWORK

HARDWARE

HARDWARE

Figura 2. Diagrama de despliegue de un hypervisor.

Las principales ventajas de los hypervisors tipo I son las facilidades operativas y administrativas sobre las mquinas virtuales bajo su cargo, incluyendo la posibilidad de clonacin de mquinas virtuales y el cambio de configuraciones de hardware (procesador, memoria, almacenamiento y red) en tiempo de ejecucin (los cuales pueden o no reflejarse inmediatamente dependiendo del sistema 24

operativo instalado en la mquina virtual). Sin embargo, su principal desventaja es la necesidad de una infraestructura fsica robusta y dedicada a la provisin de mquinas virtuales. Por su parte, los hypervisors tipo II tienen la ventaja de operar sobre recursos computacionales no dedicados y de medianas prestaciones, ofreciendo las facilidades para ser instalados y ejecutados sobre un sistema operativo principal (Windows, Linux, Mac, Solaris, etc.). Sin embargo, su principal desventaja es la necesidad de usar los servicios de un sistema operativo principal para acceder a la capa de hardware, consideracin a la cual debe ajustarse la ejecucin de mltiples mquinas virtuales, para evitar posibles problemas de desempeo. 2.1.7. Modelos de despliegue La mayora de las propuestas estudiadas contemplan la definicin de tres modelos de despliegue, como se ver en su definicin, las palabras: pblico, comunitario, privado e hbrido no necesariamente hacen referencia a un contexto de localizacin. La Figura 3 ilustra algunos modelos de despliegue cloud computing. Modelo de cloud privado: la infraestructura base cloud computing es operada en forma exclusiva por una organizacin. Sin embargo, esta misma puede ser administrada por la misma organizacin o por un tercero especializado. La infraestructura puede pertenecer y ubicarse en la organizacin usuaria o estar a cargo de un tercero especializado que acta como proveedor. En cualquier caso, la organizacin usuaria debe tener control sobre la infraestructura, software y aplicaciones que conforman su cloud privado. Este modelo tiene una variante que contempla la operacin, administracin, pertenencia y/o ubicacin de la infraestructura base cloud computing en varias organizaciones que conforman una comunidad de intereses mutuos. Este modelo es comnmente denominado cloud comunitario. Modelo de cloud pblico: los servicios provistos por la infraestructura cloud computing estn disponibles al pblico en general, incluyendo usuarios y organizaciones acadmicas, cientficas o comerciales. El proveedor de los servicios cloud generalmente es propietario de los mismos y suele facturar o adquirir ganancias indirectas por su uso externo. Modelo de cloud hbrido: la infraestructura cloud computing est compuesta por varios modelos de despliegue (privado, comunitario o pblico).

25

.
Figura 3. Modelos de despliegue cloud computing.

2.1.8. Ventajas de cloud computing A continuacin se resumen las ventajas de cloud computing desde el punto de vista del usuario final, algunas de estas ventajas estn basadas y complementan el trabajo publicado en (57). Disminucin de complejidades y costos capitales y operacionales asociados a la adquisicin, instalacin, configuracin, actualizacin y mantenimiento de infraestructuras computacionales propias. Disminucin en los costos capitales y operacionales asociados a la instalacin, prueba, configuracin, mantenimiento, actualizacin y licenciamiento para el despliegue de software sobre una infraestructura computacional propia. Esto puede incluir los beneficios econmicos asociados al aprovisionamiento rpido de nuevas versiones de software que pueden otorgar una rpida adaptacin a cambios tecnolgicos, lo cual generalmente se traduce en ventajas competitivas. Disminucin de los presupuestos y esfuerzos dirigidos al rea de TI, permitiendo la re distribucin de los mismos en reas de mayor inters para el negocio. Esto adicionalmente promueve la competencia basada en lneas de negocio, en lugar de una competencia basada en fortalezas tecnolgicas. Disminucin de los riesgos asociados a proyectos TI en dependencia de la adquisicin o actualizacin de software o infraestructuras computacionales propias. Disminucin en los tiempos estimados para la obtencin de beneficios directamente asociados al uso de software o de infraestructuras computacionales. Esto puede incluir una disminucin el tiempo de desarrollo de proyectos TI, la disminucin de los tiempos esperados para la obtencin de 26

beneficios econmicos medibles mediante el retorno de la inversin (ROI) y una disminucin en los tiempos necesarios para el aprovisionamiento de tecnologas necesarias para el soporte de nuevos procesos o lneas de negocio. Elasticidad para el crecimiento o disminucin en el uso de recursos computacionales fundamentales. Esto incluye la posibilidad de aumentar las capacidades de la infraestructura computacional para satisfacer requerimientos crticos, as como reducir su demanda para disminuir costos innecesarios en periodos de bajo consumo. La ubicuidad, alta disponibilidad y usabilidad de los servicios cloud, permitiendo su acceso por red y bajo demanda. Trazabilidad del uso efectivo de la infraestructura computacional o software desplegado y la posibilidad de facturacin bajo un modelo de pago por uso. La ubicuidad, persistencia y accesibilidad de la informacin al estar ubicada en infraestructuras computacionales de alta disponibilidad, generalmente administradas por terceros. Esto incluye las facilidades para compartir y manipular informacin en un esquema multiusuario o multi organizacional.

A continuacin se resumen las ventajas de cloud computing desde el punto de vista del proveedor de servicios, algunas de estas ventajas estn basadas y complementan los trabajos publicados en (57), (122) y (123). Disminucin de los costos asociados al software o a la infraestructura computacional provista a travs de la maximizacin de ingresos obtenidos mediante esquemas de entrega de servicios multiusuario y la generacin de beneficios econmicos obtenidos mediante mecanismos indirectos como la publicidad o venta de informacin. Una solucin rentable y ecolgica a los costos asociados al consumo de electricidad, reserva de espacio fsico y mantenimiento de ambientes de temperatura controlada para infraestructuras computacionales sobredimensionadas o subutilizadas. Expansin y diversificacin de las lneas de negocio TI, incluyendo los beneficios asociados a la rpida provisin de infraestructuras tecnolgicas y software para proyectos internos o de participacin conjunta con proveedores, socios o terceros.

27

Aumento de los ingresos econmicos, captacin, retencin y mejoramiento de clientes por medio de esquemas de facturacin basados en modelos de pago por uso. Mejoramiento de franquicias preexistentes mediante la provisin de servicios cloud complementarios a los servicios TI tradicionalmente ofrecidos. Desarrollo y mejoramiento de servicios cloud con base en el aprovechamiento de inversiones en investigacin preexistente, orientada al fortalecimiento de lneas de negocio internas. 2.1.9. Desventajas de cloud computing

Desde el punto de vista del usuario final, algunas posibles desventajas de cloud computing incluyen: La entrega de informacin y datos a terceros con las implicaciones de seguridad concernientes. Esto puede implicar la interceptacin de los datos en su viaje por la red, la posibilidad de acceso y manipulacin de la informacin por parte de personal ajeno, no autorizado, entre otras. Implicaciones de privacidad dada la posibilidad de uso de la informacin y datos entregados por los usuarios finales, con propsitos de marketing, campaas de publicidad segmentadas o venta de los mismos a empresas especializadas. Una alta dependencia con el proveedor de servicios, dada la inexistencia de estndares para el ofrecimiento y consumo de servicios cloud. Esto se puede ver agravado dada la baja oferta o incluso exclusividad en la oferta de servicios, conllevando a la generacin de monopolios informticos. Implicaciones sobre la informacin, datos y calidad en la prestacin de servicios cloud, dada la venta de la empresa proveedora, su cierre o transformaciones en sus lneas de negocio. La falta de acuerdos de nivel de servicio, que aseguren calidad de servicio a los usuarios finales y adicionalmente se encuentren amparados por figuras legales vigentes en los pases donde se ubican los usuarios finales de los servicios cloud.

28

La imposibilidad de delegar totalmente la administracin de servicios TI o almacenar informacin sensible en infraestructuras cloud computing, dada la existencia de restricciones legales para su tratamiento, localizacin y auditora. La reduccin de la brecha existente entre organizaciones cuya principal estrategia implica la diferenciacin por servicios TI basados en recursos e inversiones privadas. 2.2. IMPLEMENTACIONES DEL MODELO IAAS

En esta seccin se revisan algunas implementaciones acadmicas y comerciales del modelo IaaS de cloud computing. Estas implementaciones fueron seleccionadas teniendo en cuenta su nivel de uso por parte de mltiples iniciativas, programas y proyectos cloud computing, la trayectoria y prestigio del desarrollador, el nivel de aceptacin y referencias por parte de la industria y la comunidad acadmica y cientfica, as como por su aporte al estado del arte del paradigma cloud computing. La revisin incluye una definicin general de la implementacin, los objetivos propuestos, la identificacin de sus caractersticas distintivas, as como aspectos fundamentales de su implementacin, arquitectura y despliegue. 2.2.1. Amazon Elastic Compute Cloud Amazon Elastic Compute Cloud (Amazon EC2) (124) es un servicio Web que provee capacidades de cmputo elsticas, disponibles a travs de una infraestructura cloud computing diseada con la finalidad de proveer computacin escalable a entornos Web, bajo demanda, siguiendo un modelo comercial de pago por uso. Amazon EC2 hace parte de los Amazon Web Services, que iniciaron su produccin en el ao 2006, ofreciendo comercialmente capacidades bsicas de procesamiento y almacenamiento a usuarios y empresas en todo el mundo. Amazon EC2 provee el modelo IaaS mediante una enorme infraestructura computacional fsica que abarca miles de servidores dedicados de altas prestaciones. Dicha infraestructura est distribuida en varias localidades de Estados Unidos y Europa, con el propsito de aumentar la disponibilidad de los servicios (regiones de disponibilidad) y proveer mecanismos de seguridad y tolerancia a fallas ms robustos (125). Amazon EC2 est basado en la tecnologa de virtualizacin Xen (126), esto permite que toda su infraestructura fsica sea compartida a travs de la ejecucin bajo demanda de mltiples mquinas virtuales, cada una de las cuales tiene asignadas fracciones de recursos computacionales de la infraestructura fsica, posee un sistema operativo independiente y se entrega al usuario final como una unidad computacional con 29

una cuenta de administrador asociada. Amazon EC2 provee mquinas virtuales basadas en los sistemas operativos Linux, OpenSolaris y Windows, incluyendo un amplio rango de kernels basados en arquitecturas de 32 y 64 bits, como es el caso de Ubuntu, Fedora Core, Red Hat Enterprise, Debian, Gentoo, openSUSE, OpenSolaris y Windows Server 2003. Amazon EC2 provee imgenes de varias mquinas virtuales pre configuradas conocidas como Amazon Machine Images (AMIs), las cuales pueden ser seleccionadas para su despliegue dentro de la infraestructura y ser accedidas directamente por los usuarios finales a travs de Internet. Los usuarios finales de Amazon EC2 pueden instalar sus propias aplicaciones, as como desinstalar paquetes o servicios incluidos por defecto en una AMI. Estas imgenes modificadas pueden ser expuestas en una visibilidad privada o pblica a travs de configuraciones de seguridad y de acceso por red (125). A nivel de configuracin, las AMIs provistas por Amazon EC2 varan en el nmero de ncleos de procesamiento, la cantidad de memoria RAM, la arquitectura de 32 64 bits, el espacio disponible en disco, el desempeo de entrada y salida (I/O) y el precio, el cual es facturado por hora de uso (una fraccin de tiempo es equivalente a una hora).

RD
Remote Management Station INTERNET

P
EC2 Windows Instances EC2 Management Instance

SS H
EC2 Linux Instances

Remote Management Station

EC2 Management Instance

Figura 4. Diagrama de despliegue de Amazon EC2 (Adaptado de (127)).

Amazon EC2 basa su modelo de contabilidad de instancias, basndose en la nocin de una unidad de cmputo EC2, la cual equivale a la capacidad de una CPU de 1.0 - 1.2 GHz con un procesador Opteron o Xeon modelo 2007 (128). En consecuencia, Amazon EC2 puede ocultar totalmente la infraestructura fsica base, haciendo que cada requerimiento efectuado por un usuario pueda ser respondido por una misma o diferentes mquinas fsicas que pueden o no, estar compartidas con otros usuarios a travs de la ejecucin de AMIs. Una vez el usuario ha desplegado una AMI recibe una direccin DNS (Domain Name System) que puede ser accedida mediante SSH (Secure SHell) para el caso de OpenSolaris y Linux o escritorio remoto para el caso Windows, usando una cuenta

30

con privilegios de administrador del sistema operativo. La Figura 4 ilustra un diagrama de despliegue de Amazon EC2. Amazon EC2 es soportado por los servicios de almacenamiento provistos por Amazon Simple Storage Service (Amazon S3) (72), el cual permite a usuarios finales el almacenamiento de grandes volmenes de datos en un sistema de almacenamiento distribuido, de alto desempeo y disponibilidad. Los datos pueden ser accedidos para efectuar operaciones de lectura y escritura mediante protocolos como SOAP (Simple Object Access Protocol), REST y BitTorrent as como desde navegadores Web convencionales haciendo uso de URLs (Uniform Resource Locator). El modelo de almacenamiento de Amazon S3 se compone de una jerarqua bsica de dos niveles basados en buckets y objetos. Los usuarios finales pueden crear buckets (una cuenta puede tener ms de 100 buckets) y asignarles un nmero ilimitado de objetos cuyo espacio en disco puede exceder los 5GB. El modelo de facturacin equivale a una cuota fija por Gigabyte almacenado en periodos mensuales, aunque existen costos adicionales en relacin a la transferencia de datos desde y hacia Amazon S3, exceptuando las transferencias realizadas entre Amazon S3 y Amazon EC2. Todas las AMIs de un usuario final son almacenadas en Amazon S3. Los servicios de almacenamiento secundario asociados a una AMI estn vigentes nicamente durante el despliegue de la misma, incluso despus de un reinicio y son borrados una vez se finaliza su despliegue. Para proveer almacenamiento secundario persistente sobre las instancias de las mquinas virtuales, Amazon provee el servicio Amazon Elastic Block Store (EBS) (74), el cual provee bloques de almacenamiento que pueden ser formateados por el usuario final en el sistema de archivos de su eleccin. Amazon provee un amplio rango de utilidades de lnea de comandos para agrupar y controlar imgenes e instancias en ejecucin del servicio Amazon EC2. Tambin existe una amplia variedad de herramientas desarrolladas por terceros y ofrecidas a los usuarios finales en forma comercial y gratuita. Un ejemplo de este tipo de herramientas son Elastic Fox (129) y S3Fox (130) dos add-ons del navegador Web Firefox que permiten controlar remotamente los servicios Amazon EC2 y Amazon S3 respectivamente, mediante una interface grfica amigable. Estas operaciones de control incluyen la creacin de nuevas instancias y la finalizacin y monitorizacin de aquellas existentes para el caso de Amazon EC2, as como la transferencia de datos desde y hasta el servicio Amazon S3, la creacin de buckets, objetos y operaciones de borrado y asignacin de permisos. Aunque Amazon EC2 y Amazon S3 proveen acuerdos de nivel de servicio, estos aun representan esfuerzos en desarrollo por estandarizar la disponibilidad de los servicios. Los acuerdos de nivel de servicio actuales contemplan una 31

disponibilidad por regin del 99,95% para Amazon EC2 y 99,9% para Amazon S3 por ao de servicio, implicando que ante un fallo tan solo exista una devolucin de un crdito de servicio equivalente al 10% o 25% de la cuenta vigente para un periodo de crdito elegible. Los detalles de estos acuerdos de nivel de servicio se encuentran disponibles en (131) y (132). A pesar de que Amazon es el lder indiscutible en la provisin del modelo IaaS a nivel mundial, su naturaleza comercial ha mantenido bajo estricta reserva los detalles clave de su arquitectura y funcionamiento, incluyendo tecnologas de apoyo e infraestructura base. Adicionalmente los costos asociados al uso de sus servicios, han conllevado a que su modelo IaaS sea mayoritariamente empleado como una plataforma de produccin para fines prevalentemente comerciales, distando de una plataforma de experimentacin cloud computing factible de la extensin y personalizacin que el desarrollo de la e-Ciencia generalmente exige. 2.2.2. Nimbus Nimbus (133), es un conjunto de herramientas open source que proveen un modelo IaaS. El proyecto inici en el ao 2007 en la Universidad de Chicago y est en produccin desde marzo del ao 2008. Actualmente es un proyecto incubadora del Globus Alliance (134), soportado por la National Science Foundation - NSF y el Department of Energy - DOE de los Estados Unidos. El objetivo principal de Nimbus es la provisin de infraestructuras computacionales para el soporte de proyectos de la comunidad cientfica, con el fin de mejorar el entendimiento de las potencialidades y desafos del paradigma cloud computing. Nimbus provee el modelo IaaS mediante la asignacin y aprovechamiento de una infraestructura computacional basada en clusters de servidores robustos, los cuales son utilizados como proveedores dedicados de recursos computacionales que un usuario final puede consumir remotamente y bajo demanda. Actualmente Nimbus se encuentra desplegado en las universidades de Chicago y Florida, soportndose en ms de 30 nodos, incluyendo servidores de almacenamiento interconectados mediante canales de fibra ptica. Nimbus est basado en las tecnologas de virtualizacin Xen y KVM (Kernel-based Virtual Machine) (135), las cuales permiten la ejecucin de mltiples mquinas virtuales, facilitando la asignacin y comparticin de los recursos computacionales disponibles en los clusters de servidores fsicos. Estas mquinas virtuales estn basadas en distribuciones Linux y arquitecturas de 32 y 64 bits incluyendo a Debian, Red Hat, Fedora y Scientific Linux. Sistemas operativos a los cuales un usuario final accede con privilegios de administrador mediante mecanismos de acceso estndar como SSH y VNC (Virtual Network Computing).

32

Nimbus provee un servicio de administracin de mquinas virtuales que puede ser invocado remotamente por clientes comerciales o abiertos a travs de protocolos basados en Amazon EC2 WSDLs, Amazon EC2 Query API y Grid Community WSRF. Estos mismos se ejecutan en el contenedor Java Globus Toolkit basado en Apache Axis y proveen interfaces de usuario para acceder y operar mltiples mquinas virtuales, incluyendo operaciones bsicas tales como: ejecucin, apagado, reinicio y monitoreo. Adicionalmente, Nimbus provee un mecanismo de lnea de comandos que expone servicios WSRF (Web Service Resource Framework) para la ejecucin de scripts complejos. Entre sus principales funcionalidades, Nimbus permite el despliegue con un click de clusters virtuales a gran escala en forma rpida, automtica y repetitiva. Esto incluye la provisin de mecanismos para facilitar la personalizacin de instancias de mquinas virtuales a travs de un script ejecutado al iniciar las mquinas virtuales, esto es, configuracin de polticas de acceso y configuraciones de almacenamiento sobre una mquina virtual, adaptndola al contexto deseado por el usuario final. Estos clusters virtuales tambin pueden ser configurados para pertenecer a una red privada virtual, de tal forma que se facilite la ejecucin de aplicaciones con requerimientos de interconexin entre instancias.
Storage Service Workspace Service IaaS Gateway

Context Broker

Workspace Resource Manager Workspace Pilot Others Providers

Workspace Control

Context Client

Cloud Client

Workspace Client

Figura 5. Arquitectura de Nimbus (Adaptado de (136)).

Como se puede apreciar en la Figura 5, la arquitectura de Nimbus contempla un servicio de almacenamiento constituido por un repositorio dedicado de mquinas virtuales que trabaja en cooperacin con Globus GridFTP (137). Esto facilita su interoperabilidad con mltiples sistemas de archivos en red, as como la administracin segura de los servidores o sistemas de almacenamiento incluidos en la arquitectura de despliegue. Adicionalmente Nimbus facilita la integracin de mquinas virtuales con recursos computacionales que posean sistemas de administracin de trabajos instalados y pre configurados, como puede ser el caso de Condor (138), Torque (139), PBS (140), Sun Grid Engine (SGE) (141), entre 33

otros. Esto facilita el envo de unidades de trabajo a las mquinas virtuales desplegadas dentro del sistema o a componentes fsicos con recursos disponibles, retomando el modelo de procesamiento utilizado por el paradigma grid computing para el desarrollo de la e-Ciencia. Nimbus permite a un usuario final el aprovechamiento de centros de datos mediante la configuracin y despliegue de mquinas virtuales que en conjunto conforman clusters virtuales de procesamiento. Sus principales funcionalidades se orientan a la provisin eficiente y escalable de infraestructuras computacionales bajo demanda que puedan ser desplegadas fcilmente por investigadores y estudiantes para el desarrollo de sus experimentos y actividades de naturaleza acadmica y cientfica. Sin embargo y a pesar de sus prestaciones, la implementacin actual de Nimbus nicamente soporta el despliegue de mquinas virtuales y clusters Linux, lo cual supone una de sus mayores limitaciones para satisfacer requerimientos de ambientes personalizados de ejecucin, al igual que las limitaciones implcitas en los componentes de hardware de altas prestaciones requeridos para su despliegue y correcto funcionamiento. 2.2.3. OpenNebula OpenNebula (25) es una herramienta de licencia open source que administra infraestructuras TI compuestas por instancias de mquinas virtuales ejecutadas en infraestructuras computacionales a gran escala. El proyecto inici en el ao 2002 y es desarrollado por el Grupo de Arquitectura Distribuida de la Universidad Complutense de Madrid (UCM). El principal objetivo de OpenNebula es extender los beneficios provistos por las tecnologas de virtualizacin a centros de datos o clusters computacionales, transformando infraestructuras fsicas en infraestructuras virtuales de alta flexibilidad y desempeo a travs del modelo IaaS de cloud computing. OpenNebula provee el modelo IaaS haciendo uso de la agregacin de centros de datos de altas prestaciones, cuyos recursos computacionales dedicados son aprovechados mediante las tecnologas de virtualizacin Xen y KVM para facilitar y agilizar su aprovisionamiento. Al igual que los proyectos revisados con anterioridad, OpenNebula soporta varias distribuciones Linux y Windows en arquitecturas de 32 y 64 bits, facilitando su acceso remoto al usuario mediante mecanismos estndares y haciendo uso de privilegios de administrador. Como se puede apreciar en la Figura 6, la arquitectura de OpenNebula se divide en tres capas. OpenNebula Tools, es un conjunto de herramientas desarrolladas para la interface provista por la capa inferior. OpenNebula Core constituye un conjunto de herramientas para la administracin de mquinas virtuales, redes 34

virtuales y componentes fsicos. OpenNebula Drivers, es un intermediario entre diferentes tecnologas de virtualizacin, almacenamiento y monitoreo. La arquitectura de OpenNebula se caracteriza por su bajo acoplamiento y el uso de interfaces XML-RPC (Extensible Markup Language - Remote Procedure Call), la cuales facilitan la invocacin de acciones sobre mquinas virtuales, incluyendo la asignacin de sus instancias a recursos fsicos con capacidades adecuadas para ejecucin. Su mecanismo de acceso para usuarios finales se basa en un cliente de lnea de comandos (CLI) que permite manipular la infraestructura virtual e incluye operaciones bsicas sobre las mquinas virtuales y los recursos fsicos que las alojan. En forma adicional al CLI, es posible utilizar otras herramientas XML-RPC capaces de interactuar con el API OpenNebula (142), sin que ninguna alternativa sea representativa de una interface de usuario de alta usabilidad.
Tools Scheduller Command Line Interface Core Other Tools

SQL Pool

Request Manager (XML-RPC)


VM Manager Host Manager VN Manager

BD

BD

Drivers Transfer Driver Virtual Machine Driver Information Driver

Figura 6. Arquitectura de OpenNebula (Adaptado de (25)).

OpenNebula posee componentes especializados para el almacenamiento de mquinas virtuales. Estos mismos son responsables de todas las transferencias de archivos, incluyendo la transferencia de mquinas virtuales desde repositorios centralizados y la transferencia de archivos asociados a puntos de salvamento para migraciones de mquinas virtuales no activas. Otra de las principales prestaciones de Open Nebula la constituye la provisin de componentes para facilitar la administracin del direccionamiento IP (Internet Protocol) y MAC (Media Access Control), facilitando la creacin de redes virtuales, as como su asignacin a los adaptadores de las mquinas virtuales en ejecucin. La implementacin actual de OpenNebula soporta el modelo IaaS en modelos de despliegue de cloud privados, pblicos e hbridos. Esto se ha logrado mediante la agregacin de un cliente cloud para usuarios finales que expone servicios bsicos para la creacin de infraestructuras virtuales bajo demanda. Los planes de extensibilidad de OpenNebula incluyen su integracin con otros proveedores IaaS, 35

como es el caso de Amazon EC2 y ElasticHosts, as como lograr la compatibilidad con otros hypervisors basados en tecnologas VMware y Virtual Box (143). A pesar de que OpenNebula es una de las implementaciones ms completas del modelo IaaS, su despliegue es muy complejo y requiere de una arquitectura cluster compuesta por mltiples nodos Linux de altas prestaciones que deben actuar como proveedores dedicados de recursos computacionales para la ejecucin de mquinas virtuales. Esta arquitectura tambin supone la existencia de al menos un servidor Linux dedicado que acta como controlador principal del cluster de recursos. Adicionalmente OpenNebula, requiere de un repositorio centralizado, siendo necesario un servidor o sistema de almacenamiento robusto ante el aumento de la cantidad de imgenes de mquinas virtuales a desplegar y un sistema de redes de alta velocidad para la transferencia eficiente de mquinas virtuales entre varios centros de datos. 2.2.4. Eucalyptus Eucalyptus (23) es un framework de licencia open source (FreeBSD-style license) que implementa el modelo de servicio IaaS. El proyecto inici en el ao 2007 y es desarrollado por el Departamento de Ciencias Computacionales de la Universidad de California, Santa Barbara. El objetivo principal de Eucalyptus es proveer el modelo IaaS en independencia de tecnologas propietarias o software cuya complejidad entorpezca el ejercicio de la experimentacin y la investigacin cientfica con tecnologas cloud computing. El proyecto abarca el modelo IaaS al considerarlo la base fundamental sobre la cual se podrn extender modelos PaaS y SaaS en infraestructuras cloud computing maduras. Eucalyptus posee mltiples componentes que interactan mediante interfaces bien definidas, incentivando a mltiples colaboradores a desarrollar o mejorar la implementacin actual. En ese sentido, uno de los principales propsitos del proyecto Eucalyptus es compartir informacin acerca de sus caractersticas, en contraposicin a la poca documentacin disponible de las soluciones propietarias existentes. Los requerimientos de diseo de Eucalyptus incluyen: una solucin de fcil instalacin, alta modularidad basada en estndares y mecanismos de comunicacin fiables, acceso para usuarios finales facilitado por una interface API basada en aquella provista por Amazon (EC2 y S3) y un manejo de redes virtuales para separar el trfico de varios usuarios. Adicionalmente se busca un diseo orientado a soportar la investigacin acadmica en la temtica de cloud computing. Eucalyptus permite iniciar, apagar y reiniciar la ejecucin de mquinas virtuales soportadas por el hypervisor Xen, aunque se planea una futura compatibilidad con tecnologas KVM y VMware.

36

Cloud Controller and Walrus

Public Network

Cluster Controller

Cluster Controller

Private Network

Private Network

Node Controller

Node Controller

Node Controller

Cluster A

Node Controller

Cluster B

Figura 7. Diagrama de despliegue de Eucalyptus (Adaptado de (23)).

Como se puede apreciar en la Figura 7, Eucalyptus tiene un diseo modular y jerrquico. Cada componente de alto nivel es implementado a travs de un Web service stand alone con el fin de hacer uso de lenguajes de descubrimiento de recursos y de las funcionalidades de seguridad incorporadas en este tipo de servicios. Eucalyptus requiere de un componente que acta como repositorio dedicado de mquinas virtuales, este mismo controla la ejecucin, inspeccin y finalizacin de todas las instancias de mquinas virtuales, as como las caractersticas del computador fsico donde residen (nmero de ncleos, tamao de la memoria, espacio disponible en disco, etc.). En Eucalyptus las solicitudes de de mquinas virtuales contienen requerimientos especficos para su ejecucin como es el caso de nmero de ncleos, memoria y espacio en disco. Estas mismas se anteceden de la ejecucin de mecanismos de autenticacin que garantizan que el administrador de una mquina virtual sea el nico usuario capaz de operarla. Una de las principales caractersticas de Eucalyptus es su versatilidad en la administracin de la red que conforma la infraestructura desplegada. Las funcionalidades a nivel de red facilitan el encendido y apagado de las interfaces de red de las mquinas virtuales usando tres modos de configuracin. El primero de ellos consiste en la asignacin de un adaptador de red virtual que opere en modo puente (bridge), permitiendo la asignacin de una direccin IP mediante un requerimiento estndar a un servidor DHCP (Dynamic Host Configuration Protocol). El segundo modo permite al usuario administrador la asignacin de una 37

Node Controller

Node Controller

pareja de direcciones MAC e IP, que se reservan durante la ejecucin de la mquina virtual y se liberan automticamente despus de su finalizacin. El tercer modo implica el control de los adaptadores de red por parte de Eucalyptus, otorgando aislamiento de trfico, la configuracin de firewalls lgicos entre mquinas virtuales y la asignacin de direcciones MAC e IP. En este ltimo modo, todas las instancias de las mquinas virtuales de un usuario se asocian a una VLAN configurada tpicamente con direcciones IP privadas. Las operaciones necesarias para configurar el tercer modo se soportan en los servicios iptables Packet Filtering, iptables Network Address Translation (NAT), Destination NAT (DNAT) y Source NAT (SNAT) del sistema operativo Linux. Eucalyptus posee un servicio de almacenamiento dedicado que implementa la interface de Amazon S3 para otorgar capacidades de almacenamiento de datos a usuarios finales e instancias de mquinas virtuales. Este servicio de almacenamiento implementa mecanismos de autenticacin y soporta operaciones mediante una interface REST (Representational State Transfer) va HTTP (Hypertext Transfer Protocol). Este servicio tambin acta como un repositorio centralizado de mquinas virtuales que responde solicitudes de descarga de mquinas virtuales mediante un API compatible con Amazon EC2. A pesar de todas las funcionalidades implementadas en Eucalyptus, este framework nicamente puede ser usado en infraestructuras cluster Linux compuestas por mltiples recursos computacionales robustos y dedicados. Esto incluye un repositorio de imgenes centralizado, nodos dedicados a la provisin de mquinas virtuales, acceso a configuraciones especiales de dispositivos de red y un servidor de administracin global. En forma similar a Nimbus, la implementacin actual de Eucalyptus carece de soporte para distribuciones Windows, Solaris y Mac, lo cual limita su versatilidad en la produccin de ambientes de ejecucin personalizados. 2.2.5. VMware View y VMware Sphere VMware View (144) es una solucin comercial de la empresa VMware, Inc. que extiende la virtualizacin de escritorios mediante la entrega de escritorios virtuales personalizados como un servicio administrable, haciendo uso de una plataforma centralizada cloud computing (145). VMware View consolida escritorios virtuales personalizados en servidores pertenecientes al centro de datos empresarial, facilitando la administracin de sistemas operativos, aplicaciones y datos, que en conjunto proveen una solucin de escritorios virtuales personalizados que pueden ser entregados y accedidos por los usuarios finales desde equipos de escritorio, equipos porttiles y clientes ligeros a travs de mecanismos convencionales de red. Aunque al momento de elaboracin de este estado del arte, VMware no 38

posee implementaciones del modelo IaaS, se analizan sus productos de virtualizacin de escritorios y centros de datos, al considerarse alternativas para la provisin de ambientes personalizados de ejecucin.
Vir Cen tua tra l D lize es d k to ps
PLATFORM

VM wa re

vS ph ere

MANAGEMENT

Linked Clones

OS
VMware View Manager VMware View Composer Desktop Laptop USER EXPERIENCE VMware ThinApp

Thin Client

Parent Image

Figura 8. Diagrama de despliegue de VMware View (Adaptado de (146)).

Como se aprecia en la Figura 8, VMware View asla la dependencia existente entre el hardware y el software de los recursos computacionales comnmente asignados a usuarios finales en forma individual, facilitando la provisin dinmica de escritorios virtuales personalizados, desde plataformas de virtualizacin capaces de agilizar los procesos de despliegue y entrega, minimizando los esfuerzos de mantenimiento y actualizacin y otorgando tolerancia y recuperacin ante fallas, haciendo uso de la tecnologa VMware vSphere (147). VMware View permite la creacin y provisin de escritorios virtuales o grupos de ellos, desde una imagen primaria que es clonada para satisfacer las necesidades de cmputo de usuarios finales en forma rpida y escalable. Entre las principales prestaciones de los componentes de VMware View se encuentran un protocolo de visualizacin de alto desempeo, construido especficamente para entregar escritorios virtuales a usuarios finales haciendo uso de redes LAN o WAN, este protocolo permite la ejecucin de contenido multimedia enriquecido, la aplicacin de mltiples configuraciones de monitor y el acceso a perifricos disponibles localmente. Una consola centralizada para la administracin, provisin y despliegue de escritorios virtuales capaz de operar ms de 1000 imgenes facilitando la actualizacin y aplicacin de parches sobre los 39

sistemas operativos virtuales. Una solucin orientada a la clonacin de escritorios virtuales que comparten una unidad de disco virtual soportada en una imagen maestra. Esta tecnologa (VMware Linked Clone) permite enlazar escritorios virtuales a una imagen maestra que puede ser actualizada o parchada replicando cambios a todos los escritorios virtuales sin afectar los archivos o aplicaciones individuales de cada usuario final. Un software de virtualizacin de aplicaciones que desacopla las aplicaciones de los sistemas operativos aislndolas y encapsulndolas en archivos EXE o MSI. Esta tecnologa permite la ejecucin sin conflictos de mltiples versiones de una misma aplicacin en un sistema operativo nico o su ejecucin en varios sistemas operativos sin la necesidad de modificarla.
Existing Applications App App App App Future Applications App App App App

VMware vCenter Suite VMware vSphere Availability Application Services


vMotion Storage vMotion HA Fault Tolerance Data Recovery

Security
vShield Zones VMsafe

Scalability
DRS Hot Add

vCompute Infrastructure Services


ESX ESXi DRS

vStorage
VMFS ThinProvisioning

vNetwork
DistributedSwitch

Internal Cloud

External Cloud

Figura 9. Arquitectura de VMware vSphere (Adaptado de (148)).

Adicionalmente VMware vSphere incorpora un sistema orientado a la transformacin de centros de datos en plataformas de virtualizacin capaces de proveer servicios de infraestructura y aplicaciones en modelos de despliegue cloud privados, pblicos e hbridos. Aunque VMware View incluye una versin de VMware vSphere limitada a escritorios virtuales (VMware View vSphere for Desktops), en este trabajo se revisa la arquitectura de VMware vSphere en su versin completa, dada la relevancia tecnolgica de su presentacin como el primer sistema operativo cloud computing. Como se puede apreciar en la Figura 9, 40

VMware vSphere se divide en tres componentes base: Infrastructure Services, Application Services y vApps. Entre las principales funcionalidades de VMware vSphere se encuentran servicios orientados a la virtualizacin de servidores, permitiendo su integracin en conjuntos de recursos agregados que pueden ser accedidos directamente por aplicaciones usuarias. Un componente de automatizacin del uso de eficiente de energa elctrica, capaz de optimizar constantemente el consumo elctrico de cada servidor perteneciente a la infraestructura. Un componente de administracin de las redes asociadas a las mquinas virtuales bajo el dominio de VMware vSphere, incluyendo compatibilidad con switches virtuales distribuidos como el caso de Cisco Nexus 1000v (149). Componentes de administracin de niveles variantes de disponibilidad a aplicaciones en dependencia de su importancia para el negocio. Software para la migracin de mquinas virtuales activas entre mltiples servidores ESX y ESXi facilitando procesos de mantenimiento programado sin afectar las aplicaciones o servicios prestados a usuarios finales. Una entidad lgica compuesta de una o varias mquinas virtuales que usa el formato abierto de virtualizacin (Open Virtualization Format) (150), para especificar y encapsular todos los componentes de una aplicacin multicapa, as como polticas operacionales y acuerdos de nivel de servicio asociados a la misma. Aunque VMware View y VMware vSphere son las soluciones propietarias lideres en la provisin de tecnologas de virtualizacin y cloud computing para entornos empresariales, su instalacin requiere de uno o varios centros de datos robustos, compuestos por servidores de procesamiento dedicados, sistemas de almacenamiento de altas prestaciones e infraestructuras de redes de alta velocidad, adems de personal administrativo certificado en la operacin y mantenimiento de la suite de productos comerciales VMware. 2.3. EVALUACIN DE LAS IMPLEMENTACIONES DEL MODELO IAAS A lo largo de este captulo se revisaron implementaciones acadmicas y comerciales del modelo IaaS. Esta revisin tiene como objetivo la identificacin de aspectos crticos que deben ser tenidos en cuenta para el diseo e implementacin de UnaCloud. Para lograr este objetivo se plantea una evaluacin cuya metodologa adopta como criterio el cumplimiento de las caractersticas generales de cloud computing (previamente identificadas y explicadas en el numeral 2.1.3). Este cumplimiento debe facilitar la identificacin y descarte de aspectos a tener cuenta para el diseo e implementacin de UnaCloud en trminos del modelo IaaS.

41

La Tabla 6, muestra una comparacin y evaluacin de las implementaciones del modelo IaaS frente a las caractersticas de cloud computing. Las convenciones utilizadas hacen referencia al grado de cumplimiento de la caracterstica evaluada, siendo Alto el mayor grado de cumplimiento, Medio el grado intermedio, Bajo el menor grado y Nulo el incumplimiento total. Tabla 6. Comparacin y evaluacin de las implementaciones del modelo IaaS frente a las caractersticas de cloud computing

Caractersticas Cloud Computing Usabilidad Modelo de autoservicio Acceso a travs de red Personalizacin de servicios bajo demanda Modelo multiusuario Virtualizacin Escalabilidad Interoperabilidad y bajo acoplamiento Extensibilidad Administracin delegada Acuerdos de nivel de servicio y calidad de servicio Seguridad Modelo de trazabilidad

Alta Alto Alto Alta Alta Alta Alta Media Media Alta Medio Alta Alto

Alta Alto Alto Baja Alta Alta Media Alta Alta Media Bajo Media Bajo

Media Alto Alto Alta Alta Alta Alta Alta Alta Media Bajo Media Bajo

Alta Alto Alto Baja Alta Alta Media Alta Alta Media Bajo Media Bajo

Media Media Alta Alto Alta Alto

Con base en la evaluacin realizada, a continuacin se presentan algunas conclusiones previas: Usabilidad: a excepcin de OpenNebula, todas las implementaciones poseen interfaces de usuario de alta usabilidad que permiten su operacin intuitiva y exigen conocimientos bsicos de TI. OpenNebula por su parte, es considerada una alternativa de medio cumplimiento al proveer la mayora de sus 42

VMware View y vSphere


Alta Alto Alto Alta Alta Alta Alta

Amazon EC2

OpenNebula

Eucalyptus

Nimbus

Implementaciones IaaS

funcionalidades para usuarios finales a travs de una interface de lnea de comandos. Modelo de autoservicio: todas las implementaciones poseen mecanismos para minimizar la interaccin o negociacin del usuario final con el proveedor de servicios. En todos los casos es necesario un primer proceso de autenticacin y autorizacin para hacer uso formal de los servicios, este es considerado un proceso critico para el caso de las implementaciones comerciales. Acceso a travs de red: todas las implementaciones ofrecen una amplia gama de configuraciones para facilitar a los usuarios finales acceder a las infraestructuras y servicios computacionales por medio de redes locales, redes de rea amplia y principalmente Internet. Este acceso se proporciona a travs de mecanismos estndares como SSH, VNC o escritorio remoto. Personalizacin de servicios bajo demanda: las implementaciones comerciales ofrecen un conjunto significativo de posibilidades para personalizar ambientes de ejecucin a travs de la ejecucin de mquinas virtuales con mltiples sistemas operativos, arquitecturas y aplicaciones. Por su parte, las implementaciones acadmicas ofrecen opciones que en la mayora de los casos se limitan a distribuciones Linux. Modelo multiusuario: todas las implementaciones optimizan el uso de los recursos computacionales disponibles, permitiendo la convivencia simultnea de mltiples usuarios que comparten una misma infraestructura computacional base. En todos los casos, este modelo de consumo de recursos computacionales se basa en tecnologas de virtualizacin que utilizan hypervisors tipo I. Virtualizacin: todas las implementaciones utilizan tecnologas de virtualizacin para aprovisionar y desplegar recursos computacionales, sin embargo, la mayora de implementaciones ofrece una compatibilidad sesgada (con tecnologas de virtualizacin abiertas o propietarias). Escalabilidad: las implementaciones comerciales estn en mayor capacidad de soportar modelos de consumo, crecimiento y abastecimiento escalables, hecho que obedece principalmente a las grandes inversiones en infraestructuras computacionales dedicadas. Interoperabilidad y bajo acoplamiento: todas las soluciones se basan en arquitecturas de bajo acoplamiento capaces de operar en ambientes distribuidos y de alta heterogeneidad. Sin embargo, las implementaciones comerciales nicamente contemplan mecanismos parciales para facilitar su integracin con 43

componentes, aplicaciones o infraestructuras pertenecientes al usuario final o a otros proveedores. Extensibilidad: en este aspecto las implementaciones acadmicas demuestran una notoria ventaja frente a las comerciales, debido a su licenciamiento abierto y su naturaleza experimental e investigativa. Administracin delegada: todas las implementaciones ocultan al usuario final las complejidades de la infraestructura base, siendo un tercero el responsable de las labores de administracin, mantenimiento y actualizacin de la misma. Sin embargo, las implementaciones comerciales se destacan al ocultar totalmente la infraestructura base cloud computing tanto a usuarios finales sin conocimientos TI, como a usuarios expertos en TI. Acuerdos de nivel de servicio y calidad de servicio: la gama de productos VMware se destaca por sus mecanismos de tolerancia a fallas, recuperacin automtica ante fallas, balanceo de carga automtico y priorizacin de servicios con respecto a su importancia para el negocio. Amazon EC2 posee acuerdos de nivel de servicio permisivos en lo legal, aunque en la prctica es considerado un proveedor de alta disponibilidad que ofrece una alta calidad de servicio. Las implementaciones acadmicas por su parte no implementan acuerdos de nivel de servicio y facilitan parcialmente la aplicacin de configuraciones orientadas a proveer cierto grado de calidad de servicio para los usuarios finales. Seguridad: todas las implementaciones poseen mecanismos de seguridad con el fin de proteger los datos de los usuarios finales, destacndose las soluciones comerciales que generalmente operan con datos de negocio, cuya privacidad es considerada relevante. Modelo de trazabilidad: las implementaciones comerciales demuestran una notoria ventaja al necesitar datos precisos y sustentados para aplicar modelos de pago por uso y/o permitir la elaboracin de reportes detallados de uso de recursos en el tiempo, incluyendo la deteccin de posibles cadas del servicio y el incumplimiento de acuerdos de nivel de servicio. En resumen, los resultados de la evaluacin demuestran que todas las implementaciones del modelo IaaS estudiadas cumplen total o parcialmente con las caractersticas generales de cloud computing. En la mayora de los casos la parcialidad en el cumplimiento de una caracterstica se debe principalmente a un estado de maduracin de las tecnologas de apoyo, a procesos en desarrollo o a los objetivos e intereses detrs de cada proyecto. A nivel de implementacin, las caractersticas ms relevantes se resumen en: usabilidad, modelo de autoservicio, 44

modelo multiusuario, virtualizacin, seguridad, interoperabilidad y bajo acoplamiento, extensibilidad y acceso a travs de red. Por otra parte y especialmente en el mbito de las implementaciones acadmicas, caractersticas como la personalizacin de servicios bajo demanda, administracin delegada, escalabilidad, modelo de trazabilidad, acuerdos de nivel de servicio y calidad de servicio son de cumplimiento parcial. Esta evaluacin otorga un alto nivel de concordancia con la priorizacin de aspectos a tener en cuenta para el diseo e implementacin de UnaCloud, pero existen dos grandes excepciones. La primera de ellas se asocia a la personalizacin de servicios bajo demanda, debido a que uno de los principales objetivos de UnaCloud es ofrecer una plataforma de experimentacin multipropsito, cuya versatilidad implcita le permita ser aprovechada en mltiples contextos. Esto implica una alta prioridad para esta caracterstica dentro del diseo e implementacin de UnaCloud. La segunda excepcin se asocia a los acuerdos de nivel de servicio y calidad de servicio. Si bien la mayora de las implementaciones comerciales del modelo IaaS revisadas cumplen con esta caracterstica, estas dependen del uso de infraestructuras computacionales dedicadas, robustas y de altas prestaciones. Este aspecto puede ser considerado el mayor limitante de UnaCloud debido a la naturaleza voltil, heterognea y distribuida de la infraestructura oportunista que se utilizar como infraestructura base, problemtica ampliamente estudiada por la computacin oportunista.

45

3. COMPUTACIN OPORTUNISTA El modelo IaaS constituye la base sobre la cual se estructuran los objetivos de este trabajo de investigacin. As mismo, la propuesta e implementacin de este modelo a partir de UnaCloud debe soportarse mayoritariamente en una infraestructura oportunista de crecimiento horizontal, cuya composicin incluye computadores de escritorio y servidores que son usados por los estudiantes y profesores de la Universidad de los Andes para el ejercicio de sus labores acadmicas e investigativas. Por estas razones, este captulo tiene como objetivo revisar el estado del arte de la computacin oportunista con la finalidad de identificar aspectos conceptuales, de diseo e implementacin tiles para el desarrollo de UnaCloud. Este captulo se organiza de la siguiente forma, en la primera seccin se revisan aspectos conceptuales del paradigma de la computacin oportunista, en la segunda seccin se revisan varias implementaciones relevantes para el desarrollo y evolucin de la computacin oportunista. Finalmente en la tercera seccin se identifican problemticas de investigacin y aspectos considerados de relevancia en el contexto de la provisin de infraestructuras computacionales mediante estrategias oportunistas. 3.1. ASPECTOS CONCEPTUALES En esta seccin se revisan aspectos conceptuales de la computacin oportunista, esto incluye una definicin general y su contexto de aplicacin. 3.1.1. Definicin La computacin oportunista (27), tambin denominada computacin voluntaria (volunteer computing) (151) o computacin de recursos pblicos (public-resource computing) (152), puede definirse como una rama de la computacin distribuida en la cual se maximiza la utilizacin eficiente de recursos computacionales que estn parcialmente disponibles. Esto implica el aprovechamiento de recursos computacionales sin necesidad de hacer uso exclusivo de los mismos, asegurando que los usuarios de los recursos compartidos no perciban un deterioro significativo en la calidad del servicio. Este tipo de estrategias estn orientadas a proveer una infraestructura computacional a gran escala, principalmente para el soporte al desarrollo de proyectos de e-Ciencia, sin incurrir en inversiones financieras adicionales para la compra de hardware, reserva de espacio fsico, mantenimiento de ambientes de temperatura controlada y costos asociados a procesos de adquisicin, instalacin, configuracin, prueba, administracin y mantenimiento de las tradicionales infraestructuras de crecimiento vertical (153). 46

3.1.2. Contexto de aplicacin En el contexto mundial, el inters en la computacin oportunista se ha concentrado en la bsqueda de una solucin eficiente a la demanda de capacidades computacionales a gran escala, cuya provisin sera inviable econmicamente mediante un enfoque de computacin centralizado. Esto ha conllevado al despliegue de infraestructuras computacionales escalables a Internet, compuestas prevalentemente por computadores econmicos, heterogneos, distribuidos y parcialmente disponibles, cuyo poder de procesamiento acumulado ha llegado al orden de los PetaFLOPS (Floating point Operations Per Second), permitiendo el desarrollo de proyectos de computacin cientfica distribuida (154). En el contexto latinoamericano, el paradigma de la computacin oportunista ha tenido un auge relevante al representar una solucin econmica y tecnolgicamente eficiente ante las demandas de grandes capacidades computacionales para el desarrollo de proyectos investigativos. Este inters se ha enfocado en el aprovechamiento de infraestructuras computacionales preexistentes, de comn uso por parte de estudiantes, docentes y empleados administrativos, caracterizadas por permanecer subutilizadas y cuyos costos asociados, generalmente se encuentran contemplados en el presupuesto actual de las organizaciones propietarias. A pesar de todas las ventajas asociadas al paradigma de la computacin oportunista, es notoria la existencia de grandes complejidades asociadas al diseo, construccin, despliegue, administracin y uso de infraestructuras computacionales no dedicadas. Estas complejidades estn asociadas en gran parte al modelo de uso, distribucin y heterogeneidad de recursos computacionales preexistentes, los dominios administrativos comprometidos, la inestabilidad ante variaciones en la disponibilidad de los recursos, el diseo de mecanismos para la deteccin y aprovechamiento de recursos computacionales ociosos sin afectar la calidad de servicio percibida por el usuario del recurso compartido, entre otros aspectos. Dadas estas complejidades, no es sorprendente la existencia de mltiples limitaciones impuestas a los proyectos que pueden verse beneficiados mediante el uso de la computacin oportunista, especialmente aquellas asociadas a la calidad de servicio que en todos los casos se limita a una estrategia del mejor esfuerzo, dada la naturaleza voltil de la infraestructura base. Tampoco es sorprendente el hecho de que muchas de las iniciativas para el aprovechamiento de la computacin oportunista hayan tenido una paulatina evolucin para ofrecer soporte a paradigmas tales como cluster computing y grid computing, no solo por 47

su relevancia emergente, dada su contribucin significativa al desarrollo de la eCiencia (3), sino tambin por haber estudiado extensamente los estndares, mecanismos, herramientas, tecnologas y metodologas para operar bajo ambientes heterogneos, distribuidos, de dominio administrativo independiente, con recursos de uso compartido entre varias organizaciones, usando arquitecturas seguras, basadas en servicios desacoplados y de alta interoperabilidad (4), (155), (156). Sin embargo, a pesar de la concordancia de los esfuerzos efectuados en la computacin oportunista para el soporte de la cluster y grid computing; en el momento de elaboracin de este estado del arte, no fue posible encontrar ningn tipo de iniciativa referente al aprovechamiento del paradigma de la computacin oportunista en relacin cloud computing, lo cual constituye una motivacin investigativa fundamental para el desarrollo de UnaCloud. 3.2. IMPLEMENTACIONES DE LA COMPUTACIN OPORTUNISTA En esta seccin se revisan algunas implementaciones (Desktop Grids and Volunteer Computing Systems - DGVCS's) de la computacin oportunista. Estas implementaciones fueron seleccionadas teniendo en cuenta su relevancia histrica, el nivel de aceptacin y referencias por parte de la industria y la comunidad acadmica y cientfica, as como por su aporte al estado del arte del paradigma de la computacin oportunista. 3.2.1. Taxonoma oportunista de las implementaciones de la computacin

El Anexo A incluye una definicin general de las principales implementaciones de la computacin oportunista, incluyendo sus objetivos, la identificacin de sus caractersticas distintivas y aspectos fundamentales de su despliegue, arquitectura e implementacin. Para facilitar el estudio de estas implementaciones, a continuacin se propone una taxonoma que resume sus principales aportes al estado del arte del paradigma de la computacin oportunista. Los resultados de este proceso han sido utilizados como insumo para la produccin del captulo de un libro (157), que al momento de la elaboracin de este trabajo de investigacin, ha sido aprobado para su publicacin. Proyectos limitados a entornos LAN: esta categora se remite al origen de la computacin oportunista y se caracteriza por el aprovechamiento de recursos computacionales preexistentes, homogneos, de baja distribucin y conectados por infraestructuras de redes LAN. Estas condiciones facilitaron la experimentacin con estrategias para el aprovechamiento de recursos computacionales dedicados y no dedicados, particularmente para el aprovechamiento de ciclos computacionales ociosos. Dentro de esta categora se 48

destacan dos proyectos precursores: Worm (158) y Condor (138), analizados en los Anexos A1 y A2, respectivamente. Proyectos de nico propsito, escalables a Internet: esta categora se caracteriza por la aparicin de proyectos de la computacin oportunista de nico propsito, escalables a Internet, con capacidad de aprovechar recursos computacionales preexistentes, de alta distribucin y heterogeneidad (a nivel de sistema y hardware), pertenecientes a dominios administrativos independientes. Estas condiciones facilitaron la agregacin de capacidades de procesamiento del orden de los PetaFLOPS, pero impusieron restricciones sobre el tamao de los mensajes y archivos a transferirse dentro del sistema. En esta categora aparece el concepto de un agente ligero, portable y de fcil instalacin que al ejecutarse permanentemente como un proceso en background de prioridad baja, efecta el aprovechamiento oportunista de recursos computacionales ociosos en forma paralela y no intrusiva a los procesos del donador del recurso, esto es, control de impacto a los usuarios de los recursos compartidos. Dentro de esta categora se destacan dos proyectos: GIMPS (159) y SETI@home (160), analizados en los Anexos A3 y A4, respectivamente. Proyectos de propsito general, escalables a Internet: esta categora se caracteriza por la aparicin de proyectos de la computacin oportunista escalables a Internet y de propsito general. Al igual que la categora previa, estos proyectos cuentan con la capacidad de aprovechar recursos computacionales preexistentes, de alta distribucin y heterogeneidad, pertenecientes a dominios administrativos independientes, pero estos mismos no estn limitados a un propsito nico. Dentro de esta categora se destacan dos proyectos: [Link] (161) y BOINC (162), analizados en los Anexos A5 y A6, respectivamente. Proyectos especializados en cluster y grid computing: esta categora se caracteriza por la aparicin de proyectos de la computacin oportunista especializados en cluster y grid computing, de escalabilidad variable. Al igual que la categora previa, estos proyectos cuentan con la capacidad de aprovechar recursos computacionales preexistentes, de alta distribucin y heterogeneidad. Sin embargo, suponen el despliegue de middlewares y planificadores para el procesamiento de unidades de trabajo que demandan enormes capacidades de procesamiento, requiriendo incluso la agregacin de mltiples dominios administrativos. Dentro de esta categora se destacan cuatro proyectos: Bayanihan Computing .NET (163), OurGrid (164), InteGrade (153) y UnaGrid (165). Los tres primeros proyectos son analizados en los Anexos A7, A8 y A9, mientras UnaGrid es analizado en la siguiente sub seccin, debido a su relevancia en el contexto de este trabajo de investigacin.

49

3.2.2. UnaGrid UnaGrid (165) es una infraestructura grid virtual oportunista, cuyo objetivo principal es el aprovechamiento eficiente de recursos computacionales ociosos o subutilizados mediante una estrategia oportunista que facilita la ejecucin de aplicaciones grid computing con grandes demandas de procesamiento. El proyecto inici en el segundo semestre del ao 2008 como una iniciativa del grupo de Tecnologas de Informacin y Comunicaciones (COMIT) de la Universidad de los Andes de Colombia. UnaGrid implementa el concepto de cluster virtual personalizado (Customized Virtual Cluster - CVC), el cual hace referencia a una infraestructura virtual conformada por mltiples mquinas virtuales ejecutadas en computadores de escritorio convencionales, mediante la tecnologa de virtualizacin VMware. Estas mquinas virtuales conforman un grid de procesamiento que tiene las instalaciones y pre configuraciones de almacenamiento, red, herramientas y middlewares que requieren las aplicaciones grid para su adecuado despliegue. Esto permite que UnaGrid despliegue los sistemas operativos soportados por la tecnologa de virtualizacin VMware en arquitecturas de 32 y 64 bits. Estos sistemas operativos pueden ser accedidos directamente por el usuario final a travs de mecanismos estndar como escritorio remoto o SSH, usando una cuenta con privilegios de administrador. La estrategia oportunista inicial de UnaGrid se bas en la ejecucin de CVCs en horarios nocturnos, cuando los laboratorios de informtica del Departamento de Ingeniera de Sistemas y Computacin de la Universidad de los Andes, estn cerrados al pblico y por lo tanto, pueden considerarse totalmente disponibles. Debido a que la ejecucin de los CVCs ocurra en horarios bien conocidos, el mecanismo de ejecucin de los CVCs se bas en tareas programadas del sistema operativo Windows XP, las cuales se programaban y actualizaban en cada computador de escritorio de los laboratorios. Estas tareas estaban encargadas de ejecutar un archivo de procesamiento en lotes (.bat), cuyos comandos MS-DOS invocaban directamente al ejecutor de mquinas virtuales VMware Workstation para iniciar individualmente una de las mquinas virtuales, que en agregacin conformaban un CVC. Aunque esta estrategia facilit el aprovechamiento oportunista de recursos computacionales no dedicados, primordialmente para el desarrollo de proyectos de e-Ciencia, las limitaciones impuestas por el horario conllevaron al desarrollo de un mecanismo alterno. Este mecanismo sustituy los archivos de procesamiento en lotes por archivos visual basic scripts (.vbs), capaces de modificar la visibilidad y prioridad de los procesos asociados a la ejecucin de una mquina virtual. De esta forma se logra 50

ejecutar mquinas virtuales como procesos en background de baja prioridad, garantizando que el usuario disponga de la totalidad de los recursos del computador en el cual est trabajando (si as lo demanda), mientras la mquina virtual nicamente consume los recursos que el usuario no est utilizando o la totalidad de los mismos en el caso de un computador totalmente ocioso. Este mecanismo permite la ejecucin continua de los CVCs, ya que las mquinas virtuales aprovechan los recursos fsicos no utilizados por los usuarios mientras stos realizan sus actividades diarias sin percibir una degradacin en la calidad de servicio.
GRID COMMUNITY Computer laboratory 1 Cluster/Grid User CVC A Cluster/Grid User Certificate Authority (CA) Slave Slave Slave Computer laboratory 2 CVC C

Slave

Slave

Slave Master Middleware Grid Master

Slave

Slave

Slave

Slave

Slave CVC B

Slave Cluster/Grid User

Computer laboratory 3 Cluster/Grid User CVC A

Slave Slave Slave Slave Master Master Slave

Slave

Slave

Slave

Slave

Slave

Figura 10. Arquitectura de UnaGrid.

Como se puede observar en la Figura 10, la arquitectura de UnaGrid se basa en un modelo maestro esclavo. Cada CVC puede ser desplegado sobre decenas de equipos de escritorio convencionales en los cuales se almacena una imagen de la mquina virtual que cumple el rol esclavo, requirindose nicamente de un componente dedicado cumpliendo el rol de maestro del CVC. En lo relacionado a adicionar e integrar recursos de procesamiento dedicados a la infraestructura oportunista, basta simplemente con instalar un cluster dedicado cuya infraestructura de comunicaciones sea capaz de interconectarse con la infraestructura virtual existente. Dado que algunas aplicaciones requieren capacidades de procesamiento no convencionales, que pueden superar las capacidades ofrecidas por un solo CVC, se hace necesaria su agregacin, proceso viable a travs de tres alternativas. La primera consiste en la configuracin de un CVC para ser parte de otro preexistente incluyendo la asignacin de un maestro global, la segunda se enfoca en aprovechar las 51

capacidades de agregacin de recursos de cmputo ofrecidas por algunos planificadores como es el caso de Condor y SGE, finalmente la tercera se enfoca en instalar los componentes de un middleware grid computing como es el caso de Globus Toolkit o gLite (166). UnaGrid ha permitido la creacin y despliegue de infraestructuras computacionales virtuales que han suplido los requerimientos de aplicaciones y proyectos de e-Ciencia en diferentes reas del conocimiento incluyendo la bioinformtica y la qumica computacional. UnaGrid ha mejorado notablemente el tiempo que toma la generacin de resultados, producto de la ejecucin eficiente de aplicaciones grid computing que requieren grandes capacidades de procesamiento. Adicionalmente, UnaGrid ha promovido el trabajo multidisciplinario entre diferentes grupos de investigacin, los cuales pueden desplegar sus propias infraestructuras grid computing, compartiendo y reutilizando una misma infraestructura fsica. 3.3. IDENTIFICACIN DE ASPECTOS DE DISEO E IMPLEMENTACIN TILES PARA EL DESARROLLO DE UNACLOUD A lo largo de este captulo y en el Anexo A, se revis el estado del arte de la computacin oportunista. Esta revisin tiene como objetivo identificar aspectos de diseo e implementacin, tiles para el desarrollo de UnaCloud, particularmente aquellos asociados a los mecanismos para el aprovechamiento de recursos computacionales ociosos, estrategias para el abastecimiento oportunista de infraestructuras computacionales de crecimiento horizontal, mecanismos de control de impacto sobre usuarios finales, entre otros. La identificacin de estos aspectos debe estar orientada a la construccin de una infraestructura base cloud computing a gran escala, con prestaciones similares a aquellas obtenidas mediante recursos dedicados y robustos, pero haciendo uso de una estrategia de crecimiento horizontal basada mayoritariamente en computadores de escritorio. A continuacin se muestran los resultados obtenidos. La Tabla 7 muestra una breve descripcin de aspectos de diseo e implementacin tiles en el contexto de la computacin oportunista. Posteriormente en la Tabla 8, se evala el cumplimiento de estos aspectos en las implementaciones oportunistas revisadas.

52

Tabla 7. Identificacin de aspectos tiles para el desarrollo de UnaCloud

CON RESPECTO A LOS USUARIOS FINALES La implementacin posee mecanismos que le permiten el aprovechamiento de recursos computacionales sin necesidad de hacer uso exclusivo de los mismos, asegurando que los usuarios de los recursos compartidos no perciban un deterioro significativo en la calidad del servicio.

Control de impacto a los usuarios de los recursos compartidos

CON RESPECTO A LA ESTRATEGIA USADA PARA EL APROVECHAMIENTO DE RECURSOS La implementacin es capaz de operar en infraestructuras computacionales dedicadas. La implementacin opera simultneamente a los Ejecucin permanente procesos de usuario. La implementacin utiliza un mecanismo de agente o Uso de cliente ligero, instalado en cada componente de la agentes/clientes infraestructura computacional, con el fin de efectuar o ligeros coordinar su aprovechamiento en forma oportunista. Aprovechamiento de recursos dedicados CON RESPECTO A LOS PROCESOS DE INSTALACIN, ADMINISTRACIN Y MANTENIMIENTO Portabilidad Facilidad de instalacin Herramientas de monitoreo Herramientas de administracin La implementacin tiene un alto grado de independencia respecto a la plataforma de ejecucin. La implementacin posee herramientas que facilitan su instalacin. La implementacin posee herramientas que facilitan el monitoreo de los recursos computacionales disponibles. La implementacin posee herramientas que automatizan o facilitan las principales labores asociadas a su administracin.

53

Tabla 8. Evaluacin de aspectos tiles para el desarrollo de UnaCloud


Implementaciones Oportunistas Condor GIMPS Worm

[Link]

SETI@Home

BAYANIHAN

InteGrade S S S S S No S S

Caractersticas Cloud Computing Control de impacto a los usuarios de los recursos compartidos Aprovechamiento de recursos dedicados Ejecucin permanente Uso de agentes/clientes ligeros Portabilidad Facilidad instalacin Herramientas monitoreo Herramientas administracin de de de

S No S S S No S

S No No S No S S

S S S S S S S

S S S S S S S

S S S S S S S

S S S S S S S

S No No No No No No

S S S S No S S

S S No No No No No

Con base en las evaluaciones realizadas, a continuacin se presentan algunas conclusiones previas. Control de impacto a los usuarios de los recursos compartidos: todas las implementaciones poseen mecanismos para controlar el impacto a los usuarios de los recursos compartidos. Estos mecanismos se resumen en cinco estrategias oportunistas: la ejecucin de procesos en horarios bien definidos donde los recursos computacionales pueden considerarse ociosos, la ejecucin de procesos en background de prioridad baja, la ejecucin de procesos ante la deteccin de inactividad (por ejemplo de mouse y teclado o protectores de pantalla), la ejecucin como servicios y la asignacin de cuotas de recursos computacionales ajustables por el usuario. Aprovechamiento de recursos dedicados: todos los proyectos estudiados son capaces de operar eficientemente en infraestructuras dedicadas y en modelos hbridos, es decir, en convivencia con infraestructuras dedicadas y oportunistas. 54

UnaGrid

OurGrid

BOINC

Ejecucin permanente: nicamente las soluciones que implementan las estrategias oportunistas de ejecucin de procesos en background de prioridad baja y aprovechamiento de cuotas de recursos computacionales ajustables por el usuario, son capaces de ejecutarse en forma permanente y paralela a los procesos del usuario sin afectar significativamente la calidad de servicio que percibe. Uso de un cliente/agente ligero: la mayora de proyectos usan agentes o clientes ligeros utilizados para aprovechar recursos computacionales ociosos o para actuar como intermediarios entre los componentes articuladores de la arquitectura distribuida. Portabilidad: la mayora de los proyectos basan su portabilidad en el desarrollo de instaladores de agentes o clientes ligeros para mltiples sistemas operativos y/o configuraciones de hardware. Facilidad de instalacin: los proyectos que hacen uso de tecnologas complementarias como middlewares grid computing, virtualizacin, frameworks, planificadores, entre otros. Requieren generalmente de procesos de instalacin que exigen conocimientos de TI no triviales. Por otra parte, las soluciones basadas en agentes ligeros y escalables a Internet, basan gran parte de su xito en ofrecer mecanismos portables que faciliten su instalacin a usuarios con conocimientos mnimos de TI. Herramientas de monitoreo: la mayora de los proyectos incluyen herramientas de monitoreo que facilitan la identificacin de recursos computacionales disponibles, el estado de procesos o trabajos en curso, as como el nivel de contribucin de los participantes. Herramientas de administracin: la mayora de proyectos incluyen herramientas capaces de facilitar o automatizar la administracin de la infraestructura computacional. Sin embargo, todas estn basadas en interfaces de usuario de baja usabilidad. En resumen, los resultados evidencian que todos los aspectos identificados son relevantes para el abastecimiento de infraestructuras computacionales oportunistas y estn mayoritariamente implementados en las soluciones revisadas. El control de impacto a los usuarios de los recursos compartidos, es sin duda el aspecto ms relevante en la computacin oportunista, sin embargo, la tcnica de ejecucin de procesos en background y prioridad baja, parece ser la ms eficiente y no intrusiva en el aprovechamiento permanente de recursos computacionales no dedicados. Es importante destacar que este es uno de los requerimientos de 55

diseo ms importantes de UnaCloud, debido a la relevancia de aprovechar recursos computacionales parcialmente disponibles, cuyo propsito primario es soportar las labores acadmicas e investigativas de estudiantes y el personal docente y administrativo de la Universidad de los Andes. La idea del uso de un cliente/agente ligero parece facilitar la consecucin de otros aspectos tales como el aprovechamiento de recursos dedicados, la ejecucin permanente y no intrusiva, as como la facilidad y escalabilidad de la instalacin. Sin embargo, como parte de los aspectos de diseo contemplados en este trabajo de investigacin, se concibe que al complementarse con un desarrollo en lenguajes de programacin multiplataforma como es el caso de Java, evitara el desarrollo de varias versiones para mltiples sistemas operativos o configuraciones de hardware, lo cual redunda en una alta portabilidad para la solucin oportunista. Los resultados de las dos evaluaciones evidencian desafos y oportunidades. Un desafo, lo representa la necesidad de adoptar los aspectos relevantes de diseo e implementacin del paradigma de la computacin oportunista para el desarrollo de una infraestructura base cloud computing, capaz para proveer un modelo IaaS. Por otra parte, las mayores oportunidades estn representadas en la posibilidad de validar y extender el paradigma de la computacin oportunista en relacin a cloud computing. Este importante objetivo podra constituir un referente en investigacin para la evolucin de proyectos oportunistas que consideren su extensin en trminos del aprovechamiento de las ventajas, caractersticas y tecnologas cloud computing.

56

4. EVALUACIN DEL ESTADO DEL ARTE CON RESPECTO A LOS OBJETIVOS En los dos captulos previos se ha revisado en forma general el estado del arte de cloud computing y la computacin oportunista. Estos dos paradigmas emergentes de la computacin distribuida constituyen los pilares fundamentales sobre los cuales se fundamentan los objetivos de UnaCloud. El primer paradigma es analizado como una finalidad, particularmente en cuanto a un modelo IaaS, capaz de proveer servicios de infraestructura bajo demanda. El segundo paradigma es analizado como un medio para construir una infraestructura base cloud computing a bajo costo, utilizando estrategias de abastecimiento de infraestructuras computacionales de crecimiento horizontal. Este captulo tiene como objetivo principal la evaluacin de los proyectos revisados en el estado del arte de cloud computing y de la computacin oportunista con respecto a los objetivos de este trabajo de investigacin. Estos mismos pueden ser ampliados de la siguiente forma: Aprovechamiento de la infraestructura computacional disponible: en ausencia de una infraestructura computacional dedicada, robusta, de altas prestaciones y disponible para la experimentacin cloud computing, se tiene como objetivo el aprovechamiento de las capacidades computacionales dispersas en computadores y servidores, prevalentemente econmicos, que soportan las labores informticas de estudiantes, docentes y personal administrativo de la Universidad de los Andes. Aunque la capacidad de agregacin de estos recursos computacionales representa una solucin econmicamente atractiva para la construccin de infraestructuras computacionales a gran escala, como aquellas requeridas para la implementacin de tecnologas y modelos de servicio cloud computing (particularmente el modelo IaaS); tambin implica un conjunto de problemticas asociadas al aprovechamiento de recursos computacionales preexistentes, caracterizados por su distribucin, alta heterogeneidad, independencia de dominio administrativo y disponibilidad variante. Experimentacin cloud computing: se tiene como objetivo proveer una plataforma abierta de experimentacin cloud computing, capaz de desplegar, administrar y entregar el modelo IaaS. Aunque esta plataforma de experimentacin debe representar un mejoramiento a las alternativas de infraestructura usadas actualmente a travs de la incorporacin de las caractersticas, ventajas y tecnologas cloud computing; tambin supone una extensin que resulta disruptiva frente a los paradigmas cluster y grid computing actualmente utilizados.

57

4.1. EVALUACIN DEL ESTADO DEL ARTE DE CLOUD COMPUTING Para validar el estado del arte de las implementaciones cloud computing frente a la posibilidad del aprovechamiento de la infraestructura computacional disponible en la Universidad de los Andes, se propone una evaluacin cuya metodologa adopta los criterios explicados en la Tabla 9. Estos criterios se asocian a la construccin de una infraestructura oportunista (de bajo costo), pero tambin se evalan aspectos como la disponibilidad de la implementacin y su licenciamiento, al considerarse aspectos relevantes para la construccin de una plataforma de naturaleza abierta, experimental e investigativa. Esta evaluacin pretende evidenciar problemticas de investigacin que destaquen la validez y relevancia de UnaCloud frente al estado del arte de cloud computing. Tabla 9. Requerimientos asociados a la infraestructura base

CON RESPECTO A LOS USUARIOS FINALES La implementacin posee mecanismos que le permiten Control de impacto a el aprovechamiento de recursos computacionales sin necesidad de hacer uso exclusivo de los mismos, los usuarios de los asegurando que los usuarios de los recursos recursos compartidos compartidos no perciban un deterioro significativo en la calidad del servicio. CON RESPECTO A LOS REQUERIMIENTOS DE INSTALACIN Requiere de distribuciones especificas Requiere de un servidor de administracin dedicado Requiere de nodos dedicados a la provisin de recursos computacionales Requiere sistemas de almacenamiento especializados Requiere de configuraciones La implementacin requiere que sus componentes sean instalados en recursos computacionales con distribuciones de sistemas operativos especficos. La implementacin requiere de uno o varios servidores dedicados que acten como administradores del sistema. La implementacin requiere de mltiples nodos en arquitecturas cluster que acten como proveedores dedicados de recursos computacionales para la ejecucin de mquinas virtuales. La implementacin requiere de sistemas de almacenamiento, principalmente para soportar las operaciones de su repositorio de mquinas virtuales. La implementacin requiere de configuraciones especiales en la infraestructura de red, incluyendo 58

especiales en la dispositivos como routers, switches y firewalls. infraestructura de red Medios de instalacin Los instaladores de la implementacin no estn disponibles para la experimentacin acadmica con el restringidos modelo IaaS La implementacin no puede usarse en mltiples Licenciamiento propsitos experimentales debido a restricciones comercial asociadas a su licenciamiento. La Tabla 10, muestra una evaluacin de las implementaciones del modelo IaaS frente a los requerimientos asociados a una infraestructura base oportunista. Tabla 10. Comparacin y evaluacin de las implementaciones del modelo IaaS frente a los requerimientos asociados a la infraestructura oportunista
Implementaciones IaaS OpenNebula Eucalyptus Nimbus

Requerimientos pertinentes a una infraestructura base oportunista Control de impacto a los usuarios de los recursos compartidos Requiere de distribuciones especificas Requiere de nodos dedicados a la provisin de recursos computacionales Requiere de un servidor de administracin dedicado Requiere de soluciones de almacenamiento especializadas Requiere de configuraciones especiales en la infraestructura de red Medios de instalacin restringidos Licenciamiento comercial

No

No

No

No

No

No

No No

No No

No No

S S

59

Vmware View y vSphere No S S S S S No S

Amazon EC2

Con base en la evaluacin realizada, a continuacin se presentan algunas conclusiones previas: Control de impacto a los usuarios de los recursos compartidos: todas las implementaciones requieren de una infraestructura computacional dedicada, robusta y de altas prestaciones, motivo por el cual ninguna posee mecanismos oportunistas para controlar el impacto en el aprovechamiento de recursos compartidos. Requiere de distribuciones especificas: todas las implementaciones requieren distribuciones Linux o hypervisors tipo I basados en distribuciones Linux, para la instalacin de sus componentes base, es decir aquellos encargados de abastecer y provisionar el modelo IaaS. Esto constituye una enorme limitante en el planteamiento de una infraestructura base compuesta prevalentemente por distribuciones Windows, como es el caso de la mayora de equipos de escritorio pertenecientes al campus de la Universidad de los Andes. Requiere de nodos dedicados a la provisin de recursos computacionales: todas las implementaciones requieren de mltiples nodos que actan como proveedores dedicados de recursos computacionales para las mquinas virtuales que se ejecutan en el sistema. Las caractersticas de estos nodos deben ser las de equipos de altas prestaciones, capaces de soportar adecuadamente hypervisors tipo I. Requiere de un servidor de administracin dedicado: todas las implementaciones requieren de uno o varios servidores dedicados que acten como administradores del sistema. Estos servidores suelen operar bajo el sistema operativo Linux y generalmente son de propsito especfico, es decir, no deben ser usados para soportar funciones distintas a la administracin del sistema, por cuestiones de eficiencia y escalabilidad. Requiere soluciones de almacenamiento especializadas: los requerimientos de almacenamiento incluyen: sistemas de almacenamiento dedicado (Network Attached Storage - NAS), redes de rea de almacenamiento (Storage Area Network - SAN) o servidores de almacenamiento con sistemas de archivos accesibles desde los nodos que actan como ejecutores de mquinas virtuales. En general, la escalabilidad y desempeo de los sistemas es dependiente de la robustez de su solucin de almacenamiento. Requiere de configuraciones especiales en la infraestructura de red: la provisin de ambientes de ejecucin con configuraciones de red personalizadas, incluyendo direccionamiento pblico, privado, VLANs y VPNs, son dependientes 60

de las configuraciones especiales ofrecidas por los dispositivos de red que interconectan la infraestructura base. Por otra parte, configuraciones del tipo NAT, DNAT y SNAT pueden ser logradas a travs de software, pero su implementacin como en el caso de Eucalyptus, se limita a distribuciones Linux. Medios de instalacin restringidos: la implementacin de Amazon EC2, no est disponible para su instalacin y la documentacin sobre la misma es escasa e insuficiente. Licenciamiento comercial: Amazon EC2, VMware View y VMware vSphere son soluciones comerciales, cuyo uso experimental se limita a convenios, modos o periodos de prueba. En resumen, ninguna implementacin del modelo IaaS satisface los requerimientos necesarios para la consecucin de los objetivos de este trabajo de investigacin. Los resultados de la evaluacin evidencian el hecho de que no existe una implementacin del modelo IaaS de cloud computing capaz de operar sobre una infraestructura computacional base, econmica y no dedicada o que haga uso de una estrategia oportunista. Este hecho deriva en varias problemticas de investigacin parcialmente o aun no exploradas. La primera de ellas est sujeta al requerimiento de distribuciones Linux o hypervisors tipo I basados en este sistema operativo, para la instalacin de los componentes base del modelo IaaS. Esta problemtica adquiere gran relevancia al tener en cuenta el hecho de que los recursos computacionales que soportan las labores informticas de estudiantes, docentes y personal administrativo de la Universidad de los Andes tienen predominantemente instalada una distribucin Windows. La segunda de ellas es la ausencia de investigacin sobre un mecanismo de control de impacto en la calidad de servicio percibida por los usuarios de los recursos computacionales aprovechados en forma oportunista para crear una infraestructura cloud computing de soporte. La tercera es la ausencia de investigacin sobre mecanismos para provisionar recursos computacionales para la ejecucin de mquinas virtuales, haciendo uso oportunista de recursos computacionales no adecuados para la instalacin de hypervisors tipo I. La cuarta es la necesidad de estudiar mecanismos para proveer un modelo IaaS con servicios de administracin, almacenamiento y red soportados en los recursos actualmente disponibles en la infraestructura TI de la Universidad de los Andes. Finalmente, una quinta problemtica la supone la necesidad de crear una implementacin IaaS a la medida del grupo de restricciones anteriores, esto es, un aporte al estado del arte de cloud computing.

61

4.2. EVALUACIN DEL ESTADO DEL ARTE DE LA COMPUTACIN OPORTUNISTA Para validar el estado del arte de la computacin oportunista frente a la posibilidad de entregar una plataforma de experimentacin del modelo IaaS de cloud computing, se plantea una evaluacin cuya metodologa adopta como criterio el cumplimiento de las caractersticas generales de cloud computing (previamente identificadas y explicadas en el numeral 2.1.3). Este cumplimiento pretende evaluar el estado general de la computacin oportunista en relacin a cloud computing. Sin embargo, se hace un nfasis en UnaGrid para evidenciar los aportes ms significativos logrables a travs del desarrollo de UnaCloud, esto es, el aprovechamiento de las caractersticas, ventajas y tecnologas del modelo IaaS de cloud computing. A continuacin se muestra los resultados de la evaluacin. Tabla 11. Comparacin y evaluacin del estado de la computacin oportunista frente a cloud computing
[Link]

BAYANIHAN

SETI@Home

InteGrade

Caractersticas Cloud Computing Usabilidad Modelo de autoservicio Acceso a travs de red Personalizacin de servicios bajo demanda Modelo multiusuario Virtualizacin Escalabilidad Interoperabilidad y bajo acoplamiento Extensibilidad Administracin delegada Acuerdos de nivel de servicio y calidad de servicio Seguridad Modelo de trazabilidad

Media Nulo Alto Nula Alto Nula Alta Medio Baja Alta Nulo Media Alto

Media Nulo Alto Nula Alto Nula Alta Medio Media Alta Nulo Media Alto

Baja Nulo Medio Nula Bajo Nula Media Alto Alta Media Nulo Media Alto

Media Nulo Alto Nula Alto Nula Alta Medio Baja Alta Nulo Media Alto

Baja Nulo Alto Nula Bajo Nula Media Bajo Baja Media Nulo Baja Nulo

Media Nulo Alto Nula Alto Nula Alta Alto Media Alta Nulo Media Alto

Media Alto Alto Nula Alto Baja Alta Medio Media Media Nulo Media Medio

Media Nulo Medio Nula Alto Nula Alta Medio Media Media Nulo Media Medio

Baja Nulo Nulo Media Alto Media Baja Bajo Media Baja Nulo Baja Nulo

62

UnaGrid

OurGrid

Condor

GIMPS

BOINC

Implementaciones Oportunistas

La Tabla 11, muestra una comparacin y evaluacin de las implementaciones del paradigma de la computacin oportunista frente a las caractersticas de cloud computing. Las convenciones utilizadas hacen referencia al grado de cumplimiento de la caracterstica evaluada, siendo Alto el mayor grado de cumplimiento, Medio el grado intermedio, Bajo el menor grado y Nulo el incumplimiento total. Con base en la evaluacin realizada, a continuacin se presentan algunas conclusiones previas, es importante destacar que al ser un predecesor de las implementaciones de computacin oportunista, el proyecto Worm no cumple con la mayora de caractersticas y por ese motivo se omite del proceso de evaluacin. Usabilidad: aunque todos los proyectos incorporan interfaces de usuario, su implementacin dista del enfoque cloud computing, al requerir conocimientos de TI no triviales para la operacin de aplicaciones stand alone, interfaces de lnea de comandos e interfaces Web no intuitivas y de funcionalidades limitadas. La implementacin de UnaGrid carece de cualquier tipo de interfaz de usuario propia. Esto evidencia una problemtica de investigacin no explorada, debido a que la operacin del sistema se efecta a travs del desarrollo y ejecucin de scripts que requieren conocimientos de TI no triviales. Modelo de autoservicio: a excepcin de OurGrid, todos los proyectos requieren de procesos de negociacin y aprobacin por parte del proveedor de servicios para obtener beneficios de las infraestructuras TI. En OurGrid la negociacin entre el proveedor de la infraestructura computacional y el usuario final es minimizada mediante el concepto de red de favores. En UnaGrid el proceso de despliegue de un CVC requiere de una alta interaccin, aprobacin y negociacin del usuario final con los administradores de la infraestructura computacional donde ser desplegado. Esto dista totalmente de cualquier modelo de consumo basado en el autoservicio y representa una problemtica de investigacin no explorada. Acceso a travs de red: los proyectos diseados para operar en Internet cumplen por naturaleza con la provisin de mecanismos propios para un acceso a travs de red que facilite su administracin. UnaGrid no provee servicios o datos para garantizar el acceso a travs de red a las infraestructuras computacionales bajo su cargo. El acceso a estos recursos se efecta a travs de servicios provistos por las distribuciones de sistemas operativos, frameworks, middlewares o planificadores disponibles en los CVCs para soportar la ejecucin de aplicaciones grid o en las mquinas fsicas que los albergan. Personalizacin de servicios bajo demanda: ningn proyecto de computacin oportunista posee mecanismos para facilitar al usuario final la aplicacin de configuraciones personalizadas o la asignacin y despliegue de infraestructuras, 63

software o aplicaciones bajo demanda. En UnaGrid el uso de tecnologas de virtualizacin permite a los usuarios finales la configuracin de ambientes de pruebas, desarrollo y produccin personalizados, facilitando la correcta ejecucin de sus aplicaciones grid computing. Sin embargo, el despliegue de los CVCs est condicionado por el uso de tareas programadas del sistema operativo Windows, mecanismo programado en horarios bien definidos y por lo tanto, no ejecutable bajo demanda. En este aspecto es necesaria la investigacin de mecanismos de ejecucin de ambientes personalizados bajo la demanda del usuario final. Esto constituira un aporte significativo al estado del arte de la computacin oportunista. Modelo multiusuario: todas las implementaciones poseen mecanismos para efectuar una optimizacin de recursos. La estrategia oportunista de UnaGrid aprovecha recursos computacionales ociosos en forma paralela a las tareas convencionales de un usuario, sin deteriorar la calidad del servicio percibida por el mismo. Esta estrategia supone un modelo de aprovechamiento de recursos multiusuario. Sin embargo, existen dificultades asociadas al nivel de comparticin de la infraestructura computacional fsica por parte de varios usuarios finales de los CVCs. Esto obedece a que en ausencia de un mecanismo de ejecucin distinto a las tareas programadas de Windows, la asignacin de recursos es predominantemente esttica, siendo necesarios cambios individuales en cada equipo fsico para re direccionar la ejecucin de otro CVC o cambiar un horario de ejecucin preestablecido. Virtualizacin: a excepcin de UnaGrid y OurGrid, las implementaciones no utilizan tecnologas de virtualizacin para el aprovisionamiento de infraestructuras computacionales. UnaGrid utiliza tecnologas de virtualizacin con dos finalidades primordiales. La primera de ellas hace referencia a la facilidad para la creacin y administracin de ambientes de ejecucin personalizados, que tienen todas las instalaciones y configuraciones necesarias para la correcta ejecucin de aplicaciones grid computing, incluyendo configuraciones de sistemas operativos, frameworks, middlewares, libreras, etc. La segunda finalidad, tambin incorporada en OurGrid, se resume en el aislamiento del ambiente de ejecucin grid respecto al ambiente de ejecucin del usuario del recurso compartido, otorgando un mayor grado de seguridad a la estrategia oportunista para el aprovechamiento de recursos. Sin embargo, al no existir un mecanismo de despliegue bajo demanda, se evidencia la ausencia de investigacin respecto al aprovechamiento de las tecnologas de virtualizacin para desplegar infraestructuras computacionales en forma rpida, eficiente y dinmica. Escalabilidad: los proyectos diseados para operar en Internet cumplen por naturaleza con un alto nivel de escalabilidad, sin embargo, su modelo de crecimiento y abastecimiento es dependiente de factores externos como la 64

voluntad de mltiples usuarios para donar sus recursos computacionales en forma exclusiva o parcial. Por otra parte, proyectos como Condor, Bayanihan y UnaGrid aun poseen arquitecturas acopladas que limitan su operacin en entornos Internet. La escalabilidad de las propuestas estudiadas es dependiente del sistema de comunicaciones seleccionado, aspectos como la interoperabilidad, seguridad, as como la cantidad y tamao de los mensajes que intercambian los componentes, son cruciales para el diseo e implementacin de arquitecturas escalables. La escalabilidad de UnaGrid est limitada por dos hechos fundamentales: la falta de mecanismos de ejecucin remotos, comunicacin entre componentes y paso de mensajes y la operacin bajo un dominio administrativo nico. Estos dos hechos evidencian problemticas de investigacin no exploradas en relacin a mecanismos de comunicacin robustos y eficientes, as como la provisin de mecanismos de seguridad para hacer factible la operacin de UnaGrid en dominios administrativos independientes. Interoperabilidad y bajo acoplamiento: a excepcin de Condor, Bayanihan, y UnaGrid, todas las soluciones se basan en arquitecturas de bajo acoplamiento, la mayora de ellas escalables a Internet. Por otra parte, el grado de interoperabilidad es dependiente de las tecnologas base utilizadas como es el caso de hypervisors, middlewares, lenguajes de programacin, etc. El diseo e implementacin de UnaGrid no contempla actualmente un desarrollo en donde se pueda evaluar extensamente esta caracterstica. La arquitectura de UnaGrid es acoplada y dependiente de un punto de administracin bajo un dominio administrativo nico, adicionalmente no est basada en mdulos, componentes o servicios distintos a las funciones bsicas del sistema operativo Windows o de los sistemas operativos alojados en las mquinas virtuales. Extensibilidad: la extensibilidad de los servicios disponibles en las implementaciones estudiadas, est condicionada por su tipo de licenciamiento, la documentacin disponible y aspectos de diseo, despliegue y arquitectura. Soluciones como GIMPS y SETI@Home se califican en cumplimiento bajo por estar diseadas para propsitos nicos, mientras las restantes facilitan la creacin y publicacin de proyectos multipropsito o la especializacin de funciones disponibles para satisfacer nuevos requerimientos del usuario. El diseo e implementacin de UnaGrid no contempla un desarrollo en donde se pueda evaluar extensamente esta caracterstica, sin embargo, su arquitectura simple es factible de extensin. Administracin delegada: algunos proyectos de donacin voluntaria a escala Internet como GIMPS, [Link], SETI@Home y BOINC, cuentan con un notorio cumplimiento de esta caracterstica, debido a que los dueos de los recursos computacionales compartidos son completamente responsables de los 65

mismos, incluyendo los costos operacionales y capitales. En UnaGrid, los mecanismos de instalacin, configuracin y despliegue de los CVCs requieren conocimientos de la infraestructura base e involucran la participacin del usuario final en tareas pertinentes a su administracin, mantenimiento y actualizacin, enfoque distante de la delegacin de labores de administracin, propuesto en el paradigma cloud computing. Esto se debe en gran parte a la ausencia de herramientas que faciliten la administracin de la infraestructura base. Acuerdos de nivel de servicio y calidad de servicio: no es sorprendente que todas las alternativas incumplan esta caracterstica y operen bajo la estrategia del mejor esfuerzo, dada la volatibilidad de la infraestructura oportunista de soporte. Aunque para UnaGrid esto tambin constituye una problemtica de investigacin no explorada, la naturaleza oportunista de la infraestructura de soporte representa un limitante en su alcance. Seguridad: todas las implementaciones poseen mecanismos de seguridad bsicos, aunque se destacan aquellas implementaciones cuya operacin mayoritaria ocurre en Internet, lo cual supone un mayor inters por minimizar los riesgos de ataques o de entrega de resultados malintencionados. Por otra parte, es evidente que todos los mecanismos de seguridad implementados no involucran aspectos asociados a la asignacin y despliegue de recursos bajo demanda, aspecto fundamental en el enfoque cloud computing. UnaGrid implementa mecanismos de seguridad bsicos, resumidos en los servicios entregados por el sistema operativo Windows para la administracin de privilegios a cuentas de usuarios locales y aquellos asociados al directorio activo. Como se mencion anteriormente, UnaGrid tambin aprovecha el aislamiento de los ambientes de ejecucin virtuales para evitar intrusiones en el ambiente de ejecucin del usuario del recurso fsico. A pesar de estos mecanismos bsicos, es evidente la ausencia de investigacin asociada a la seguridad en los mecanismos de comunicaciones necesarios para aumentar la escalabilidad del sistema en trminos de su bajo acoplamiento, operacin a travs de mltiples dominios administrativos y soporte al paso de mensajes. Modelo de trazabilidad de uso: las implementaciones a escala Internet demuestran una notoria superioridad en el cumplimiento de esta caracterstica, dada la necesidad de utilizar la informacin de participacin de usuarios con finalidades de marketing viral, premiaciones o el reconocimiento de ambientes de ejecucin fiables. UnaGrid no posee un modelo para llevar trazabilidad de uso de sus infraestructuras computacionales fsicas o virtuales.

66

Los resultados de la evaluacin demuestran que las implementaciones oportunistas revisadas incumplen con las caractersticas necesarias para situarse dentro del contexto cloud computing. Este no es un hecho sorprendente debido a los requerimientos originales para los cuales fueron diseadas. Sin embargo, esta evaluacin adquiere relevancia al evidenciar problemticas de investigacin parcialmente o aun no exploradas que son abordadas mediante el presente trabajo de investigacin. Una de las principales problemticas de investigacin la constituye el abastecimiento de infraestructuras computacionales a gran escala, haciendo uso de recursos computacionales prevalentemente econmicos, distribuidos, heterogneos y de disponibilidad parcial. Esta problemtica ha sido ampliamente investigada para el desarrollo de las implementaciones revisadas, constituyndose en un valioso referente para el diseo e implementacin de UnaCloud. Sin embargo, al tratarse de investigacin limitada al contexto de los paradigmas de la computacin oportunista, cluster y grid computing, se hace necesaria una adaptacin apropiada al contexto cloud computing, particularmente para la provisin del modelo IaaS. Esto requerir un notorio esfuerzo orientado a la propuesta e implementacin de una arquitectura cloud computing basada en una infraestructura oportunista. Con base en los resultados de la comparacin y evaluacin, los dos proyectos ms destacados son: OurGrid y UnaGrid. Aunque OurGrid es sin duda la implementacin ms madura y robusta en el contexto grid computing, la estrategia de virtualizacin de UnaGrid, sumada a su estrategia oportunista la hace factible de extensin al contexto cloud computing. El nivel de personalizacin logrado a travs del uso de tecnologas de virtualizacin, diferencia contundentemente a UnaGrid de cualquier otro proyecto de la computacin oportunista. La importancia de esta estrategia puede validarse al tener en cuenta dos aspectos. El primero se asocia a la maximizacin de la usabilidad de la infraestructura de soporte. Por medio de las tecnologas de virtualizacin, UnaGrid puede soportar cualquier ambiente de ejecucin deseado por el usuario final, de tal forma que se pueden emular los ambientes nativos de sus aplicaciones. Este hecho es factible de extensin a modelos IaaS capaces de entregar plataformas de experimentacin de alta versatilidad. El segundo aspecto se asocia a la reutilizacin de la infraestructura fsica. Al desacoplar la dependencia entre el software y el hardware, las tecnologas de virtualizacin han permitido a UnaGrid utilizar una misma infraestructura fsica para desplegar mltiples CVCs. Este hecho es factible de extensin a modelos IaaS capaces de asignar plataformas de experimentacin cloud computing bajo demanda, optimizando el aprovechamiento de una infraestructura base de naturaleza oportunista. Por lo tanto, la principal contribucin de UnaCloud en el contexto del proyecto Campus Grid Uniandes y su sub proyecto UnaGrid, debe orientarse a la 67

personalizacin de servicios en un modelo de despliegue y asignacin de recursos bajo demanda, caracterstica no disponible en ninguna implementacin de la computacin oportunista. Adems de esta contribucin los resultados de la evaluacin demuestran que en el contexto de UnaGrid se deben mejorar aspectos relacionados a su usabilidad, escalabilidad, seguridad, extensin en el aprovechamiento de tecnologas de virtualizacin, extensibilidad, interoperabilidad y bajo acoplamiento, mecanismos de acceso a travs de red, trazabilidad de uso de recursos y administracin delegada. Finalmente los resultados de las dos evaluaciones evidencian desafos y oportunidades. El mayor desafo para la consecucin de los objetivos de este trabajo de investigacin, lo representa la consecucin de la mayora de caractersticas de cloud computing en una implementacin del modelo IaaS cuya infraestructura computacional de soporte, a diferencia de todas las implementaciones cloud computing estudiadas, debe estar compuesta por recursos computacionales preexistentes, que en su mayora son econmicos, de alta distribucin, alta heterogeneidad, con independencia de dominio administrativo y de disponibilidad variante. Debido a que estas problemticas son objeto de estudio del paradigma de la computacin oportunista, la mayor oportunidad est representada en evaluar una convergencia entre los paradigmas cloud computing y la computacin oportunista para disear una estrategia de solucin hibrida, a la medida de las restricciones y los objetivos planteados.

68

5. ESTRATEGIA DE SOLUCIN En los dos captulos previos se han identificado cinco principales problemticas de investigacin parcialmente o aun no exploradas que validan la relevancia de este trabajo de investigacin. Tambin se han identificado aspectos de diseo e implementacin tiles para el desarrollo de UnaCloud. Los resultados ms relevantes en el contexto cloud computing se resumen en: usabilidad, modelo de autoservicio, personalizacin de servicios bajo demanda, administracin delegada, modelo multiusuario, virtualizacin, escalabilidad, seguridad, interoperabilidad y bajo acoplamiento, extensibilidad, acceso a travs de red y modelo de trazabilidad. Mientras en el contexto de la computacin oportunista se resumen en: control de impacto a los usuarios de los recursos compartidos, aprovechamiento de recursos dedicados, ejecucin permanente, uso de agentes/clientes ligeros, portabilidad, facilidad de instalacin, herramientas de monitoreo y herramientas de administracin. Adicionalmente se ha evidenciado que la principal contribucin de UnaCloud en el contexto del proyecto Campus Grid Uniandes y su sub proyecto UnaGrid, debe orientarse a la personalizacin de servicios en un modelo de despliegue y asignacin de recursos bajo demanda, caracterstica no disponible en ninguna implementacin de la computacin oportunista. Sin embargo, tambin existen retos tendientes a mejorar UnaGrid en trminos de su usabilidad, escalabilidad, seguridad, extensin en el aprovechamiento de tecnologas de virtualizacin, extensibilidad, interoperabilidad y bajo acoplamiento, mecanismos de acceso a travs de red, trazabilidad de uso de recursos y administracin delegada. Teniendo en cuenta estos requerimientos, este captulo tiene como objetivo la descripcin general de la estrategia de solucin implementada a travs de UnaCloud. Este captulo se organiza de la siguiente forma, en la primera seccin se describen las principales estrategias de diseo e implementacin de UnaCloud, incluyendo su estrategia de virtualizacin y su estrategia oportunista, finalmente en la segunda seccin se describe su alcance funcional y no funcional. 5.1. ESTRATEGIAS DE DISEO E IMPLEMENTACIN Teniendo como base el trabajo desarrollado en UnaGrid, el presente trabajo de investigacin se basa en dos estrategias de diseo e implementacin fundamentales: una estrategia de virtualizacin y una estrategia oportunista. A continuacin se describen estas estrategias.

69

5.1.1. Estrategia de virtualizacin UnaCloud adopta tecnologas de virtualizacin (ver Figura 11) para el encapsulamiento de ambientes personalizados de ejecucin en mquinas virtuales, accediendo a las siguientes ventajas: Optimizacin de recursos fsicos: el uso de tecnologas de virtualizacin permite la ejecucin de mltiples ambientes de ejecucin sobre una misma infraestructura fsica, es decir, la reutilizacin de una infraestructura fsica para mltiples propsitos simultneos. Esta optimizacin es administrada por el hypervisor tipo II instalado en el recurso fsico, el cual vela por el cumplimiento de las cuotas de recursos fsicos asignadas a las mquinas virtuales, disminuyendo la competicin por recursos. Esta ventaja tambin supone una solucin eficiente a la sub utilizacin de recursos computacionales preexistentes y a la necesidad de efectuar inversiones en nuevos recursos computacionales dedicados para el ejercicio de la investigacin y el desarrollo de la e-Ciencia, as como para el soporte de actividades computacionales multipropsito. Aislamiento del ambiente de ejecucin: el uso de tecnologas de virtualizacin permite el aislamiento del ambiente de ejecucin usado para proveer el modelo IaaS, respecto al ambiente de ejecucin del usuario del recurso compartido. Esto redunda en dos ventajas clave. La primea se asocia al grado de intrusin administrativa sobre los recursos fsicos. Esto implica que cualquier tipo de operacin a nivel del sistema operativo virtualizado o de sus aplicaciones, como puede ser el caso de fallas, reinicios y cadas del servicio, no afectan al ambiente de ejecucin del usuario del recurso compartido. La segunda se asocia al aislamiento de las vulnerabilidades de seguridad, las cuales se limitan al ambiente de ejecucin del modelo IaaS, sin afectar el ambiente de ejecucin desplegado directamente sobre el recurso fsico. Este tipo de aislamiento puede fortalecerse mediante la asignacin de recursos fsicos limitados, adems de la aplicacin de configuraciones seguras a nivel del sistema operativo virtualizado. Administracin y provisin de ambientes personalizados: el uso de tecnologas de virtualizacin facilita la creacin y despliegue bajo demanda de ambientes personalizados con todas las todas las instalaciones y configuraciones de sistemas operativos, middlewares, frameworks, herramientas y aplicaciones deseadas por el usuario final. As mismo se facilita la aplicacin de configuraciones hardware, apropiadas para la ejecucin de un software especfico. Esto implica un beneficio de gran importancia, representado en la posibilidad de ofrecer a los usuarios finales, ambientes de ejecucin que emulan los ambientes nativos de sus aplicaciones, garantizando una alta usabilidad para el modelo IaaS.

70

Portabilidad de ambientes personalizados: el uso de tecnologas de virtualizacin elimina la dependencia entre el hardware y el software del ambiente personalizado de ejecucin, permitiendo su reubicacin en recursos fsicos con heterogeneidad a nivel de hardware o sistema. El hecho de que una mquina virtual sea encapsulada como un archivo, facilita su transferencia y replicacin entre dispositivos de almacenamiento convencionales. Adicionalmente la estrategia de virtualizacin supone una solucin a los problemas de heterogeneidad de sistema, particularmente para facilitar la ejecucin de aplicaciones de e-Ciencia en sus ambientes nativos, prevalentemente Linux, sobre recursos computacionales del campus de la Universidad de los Andes, cuyo sistema operativo predominante es Windows.

UnaCloud IaaS Model Type II Hypervisor Main Operating System

CPU

Memory

Storage

Network

HARDWARE
Figura 11. Estrategia de virtualizacin de UnaCloud.

5.1.2. Estrategia oportunista UnaCloud adopta una estrategia oportunista basada en la ejecucin de procesos en background de prioridad baja (ver Figura 12), accediendo a las siguientes ventajas: Optimizacin de recursos fsicos: el uso de prioridades bajas para los procesos involucrados en el despliegue del modelo IaaS, permite su ejecucin paralela y permanente a los procesos ejecutados por el usuario del recurso compartido. Esto supone una solucin eficiente y econmica al problema de sub utilizacin de recursos computacionales no dedicados. Control de impacto a los usuarios de los recursos compartidos: el uso de prioridades permite que el sistema operativo del recurso fsico otorgue prioridad absoluta al usuario del mismo en el acceso y uso de los recursos fsicos disponibles. De esta forma, una mquina virtual componente del modelo IaaS, nicamente utiliza los recursos fsicos que el usuario del recurso compartido no est utilizando o la totalidad de los mismos en el caso de un equipo totalmente 71

ocioso. Esto redunda en un impacto controlado e imperceptible en la calidad de servicio percibida por el usuario del recurso compartido. Aislamiento del ambiente de ejecucin: el uso de procesos en background impiden la visualizacin y/o manipulacin de las mquinas virtuales que componen el modelo IaaS, por parte de los usuarios de los recursos fsicos. Esto facilita una ejecucin silenciosa en la cual un usuario de un recurso fsico desconoce totalmente el estado de comparticin del mismo.
Virtual Machine (background and low priority process) Virtualization Technology Main Operating System

IaaS Model Type II Hypervisor Operating System

Commodity Hardware Hardware


CPU Memory Storage Network

Figura 12. Estrategia oportunista de UnaCloud.

5.2. ALCANCE DE LA SOLUCIN En esta seccin se presenta el alcance establecido para UnaCloud en trminos funcionales y no funcionales. 5.2.1. Alcance funcional Teniendo en cuenta los objetivos del presente trabajo de investigacin, se hace necesario implementar un modelo IaaS capaz de proveer el siguiente conjunto de funcionalidades: Personalizacin del modelo IaaS: esta funcionalidad debe permitir a todos los usuarios la creacin de un ambiente personalizado para su despliegue bajo demanda a travs del modelo IaaS. Estas configuraciones se dividen en cinco reas: software, hardware, cantidad, localizacin (opcional) y tiempo de ejecucin. En la primera rea se debe permitir la configuracin del tipo de sistema operativo, su versin y el conjunto de aplicaciones instaladas sobre el mismo. En la segunda rea se debe permitir la configuracin del tamao del disco duro, el nmero de ncleos de procesamiento y el tamao de la memoria RAM. En la tercera rea se debe permitir la eleccin del nmero de instancias a desplegar. En la cuarta rea se puede elegir la localizacin del despliegue del modelo IaaS, en componentes especficos de la infraestructura fsica de soporte. Esta rea nicamente aplica 72

para usuarios que lo demanden (generalmente usuarios de aplicaciones grid que desean optimizar el aprovechamiento de la infraestructura oportunista). Finalmente en la quinta rea se debe permitir la configuracin del tiempo de ejecucin. Para los usuarios que deseen omitir la personalizacin completa de su modelo IaaS, la funcionalidad deber permitirles seleccionar nicamente el nombre de la imagen que desean ejecutar, es decir, el nombre otorgado al conjunto de aplicaciones pre instalado en la mquina virtual o el nombre del CVC para el caso de usuarios Grid, el nmero de instancias y el tiempo de ejecucin de las mismas. Despliegue del modelo IaaS: esta funcionalidad debe permitir a todos los usuarios el despliegue bajo demanda de los servicios computacionales fundamentales que componen el modelo IaaS (almacenamiento, procesamiento y sistema operativo). Esto debe incluir la provisin de los datos necesarios para el acceso a las infraestructuras computacionales mediante mecanismos estndares como escritorio remoto, VNC y SSH. Administracin del modelo IaaS: esta funcionalidad debe estar disponible para todos los usuarios. Para los usuarios finales se debe proveer mecanismos para la operacin de sus mquinas virtuales, incluyendo operaciones bsicas tales como: ejecucin, apagado, reinicio, monitoreo y cambio de tiempo de ejecucin. Para los usuarios administradores se deben proveer todas las funcionalidades del usuario final, pero incluyendo todas las mquinas virtuales en ejecucin dentro del modelo IaaS soportado por UnaCloud. Trazabilidad de uso del modelo IaaS: esta funcionalidad debe proveer un servicio para consultar el uso del modelo IaaS a travs de una trazabilidad efectuada a nivel de usuario. Esta consulta debe llevarse a cabo mediante la entrega de un reporte bsico que incluya la informacin asociada a las mquinas virtuales ejecutadas, la infraestructura fsica utilizada para su despliegue, los detalles de personalizacin elegidos por el usuario final y el periodo de vigencia de la ejecucin. Administracin de la infraestructura base: esta funcionalidad debe estar disponible exclusivamente para usuarios administradores. Entre sus servicios se debe incluir una interface para apagar, reiniciar, bloquear, desbloquear y cerrar la sesin activa en los recursos computacionales que componen la infraestructura base del modelo IaaS. Adicionalmente se debe ofrecer una interface para monitorizar los recursos computacionales que la componen.

73

5.2.2. Alcance no funcional Usabilidad: UnaCloud debe ofrecer mecanismos de acceso con interfaces de usuario de alta usabilidad, cuya operacin requiera conocimientos bsicos de TI y faciliten al usuario final el consumo de servicios computacionales fundamentales en un modelo basado en el autoservicio. Acceso a travs de red: UnaCloud debe ofrecer un servicio de acceso directo, que puede ser invocado por el usuario final desde redes internas e Internet. Este mismo debe estar basado en un portal Web de acceso universitario. Modelo de uso de recursos: UnaCloud debe usar recursos computacionales no dedicados, en un modo de ejecucin permanente. Para ello debe utilizar una estrategia oportunista que no afecte significativamente la calidad del servicio percibida por los usuarios de los recursos compartidos. Adicionalmente UnaCloud debe estar en capacidad de operar eficientemente en recursos dedicados o en modelo hbridos, es decir, en la coexistencia de recursos oportunistas y dedicados. Virtualizacin: UnaCloud debe proveer infraestructuras computacionales basndose en tecnologas de virtualizacin para la asignacin y aprovechamiento oportunista de recursos computacionales no dedicados. Aunque estas tecnologas permitirn el despliegue de infraestructuras computacionales bajo demanda, no se proporcionar elasticidad en tiempo real sobre las mismas, debido a las limitaciones impuestas por los hypervisors tipo II, instalables en las arquitecturas x86 de los equipos de escritorio convencionales. Adicionalmente el abastecimiento de mquinas virtuales estar limitado por la disponibilidad de imgenes previamente configuradas y localizadas en el sistema. El hypervisor seleccionado para el despliegue inicial de UnaCloud ser VMware debido a su amplio liderazgo sobre los hypervisor competidores en arquitecturas x86 (167). Escalabilidad: UnaCloud debe implementar modelos de consumo, crecimiento y abastecimiento escalables en infraestructuras computacionales oportunistas de crecimiento horizontal. Sin embargo, su escalabilidad estar limitada a las condiciones de la infraestructura de red de soporte, la volatibilidad de la infraestructura oportunista y las capacidades de almacenamiento, memoria y procesamiento disponibles. Interoperabilidad, extensibilidad y bajo acoplamiento: UnaCloud debe estar basado en tecnologas multipropsito, abiertas y de bajo acoplamiento que le provean alta interoperabilidad. Estas mismas deben ser seleccionadas teniendo en cuenta dos prioridades: otorgar un alto desempeo sobre infraestructuras

74

computacionales oportunistas y representar alternativas maduras y ampliamente difundidas con la finalidad de facilitar su divulgacin y extensin. Administracin delegada: UnaCloud debe proveer herramientas que faciliten la administracin de la infraestructura oportunista que utiliza para su despliegue. Adicionalmente UnaCloud debe ocultar al usuario final las complejidades asociadas a la infraestructura computacional base. Sin embargo, esto no implicar su operacin ante procesos de mantenimiento o actualizacin, automticos o programados en la infraestructura fsica de soporte. Heterogeneidad: UnaCloud debe operar en recursos computacionales con alta heterogeneidad de sistema y de hardware. Para desacoplar la dependencia entre el software y el hardware involucrado, se utilizarn los servicios y herramientas de un hypervisor tipo II de VMware para arquitecturas x86. Acuerdos de nivel de servicio y calidad de servicio: UnaCloud facilitar el despliegue y administracin de una plataforma cloud computing experimental que operar bajo la estrategia del mejor esfuerzo, dada la naturaleza oportunista de la infraestructura de soporte. Esto incluye la inexistencia de garantas sobre tiempos de respuesta y la imposibilidad de ofrecer tolerancia y recuperacin ante fallas o cualquier tipo de acuerdo de nivel de servicio o calidad de servicio. Seguridad: UnaCloud debe proveer mecanismos de seguridad bsicos que soporten el paso de mensajes entre sus componentes, as como el acceso a sus servicios. Sin embargo, se supondr la inexistencia de usuarios malintencionados que hagan mal uso de las interfaces de entrada, modifiquen el comportamiento de las mquinas virtuales y fsicas que compongan la infraestructura de despliegue o que hagan uso malicioso de las mismas, incluyendo la instalacin de software ilegal, ataques de denegacin de servicio, escaneo de puertos, pruebas de penetracin, modificacin o inyeccin de cdigo, etc. Facilidad de instalacin: UnaCloud debe estar basado en un agente ligero desarrollado en el lenguaje de programacin Java. Este agente debe ser de fcil instalacin y de alta portabilidad. Esto incluye la posibilidad de su instalacin distribuciones Windows, Linux y Mac. Servicios computacionales: UnaCloud entregar servicios computacionales fundamentales incluyendo procesamiento, almacenamiento, sistemas operativos y aplicaciones a travs una estrategia de abastecimiento basada en mquinas virtuales. Estos servicios no incluirn servicios de almacenamiento complementarios a los disponibles temporalmente dentro de las mquinas

75

virtuales o configuraciones networking que involucren la administracin u operacin del cualquier tipo de sistema operativo o componente de red. Modelos de servicio: UnaCloud estar en capacidad de desplegar, administrar y entregar un modelo IaaS, mediante el aprovechamiento oportunista de la infraestructura computacional disponible en los laboratorios de informtica del Departamento de Ingeniera de Sistemas y Computacin de la Universidad de los Andes. Esto no incluir otros modelos de servicio cloud computing como es el caso de SaaS o PaaS. Modelos de despliegue: UnaCloud ser implementado usando el modelo de despliegue de cloud privado, donde la infraestructura computacional es operada y administrada por la Universidad de los Andes.

76

6. UNACLOUD En este captulo se presenta a UnaCloud, una implementacin a medida del modelo IaaS de cloud computing, capaz de entregar servicios computacionales fundamentales haciendo uso oportunista de los recursos de cmputo actualmente disponibles en el Campus de la Universidad de los Andes. Este captulo se organiza de la siguiente forma, en la primera seccin se describe una visin general de la arquitectura de UnaCloud, en la segunda seccin se describe esta arquitectura en mayor detalle, en la tercera seccin se describe el modelo de procesos y finalmente en la cuarta seccin se describen los mecanismos de comunicaciones de UnaCloud. 6.1. VISIN GENERAL DE LA ARQUITECTURA La solucin propuesta en este trabajo de investigacin consiste en la integracin de un sistema de informacin con una infraestructura computacional de naturaleza oportunista, esto es, el desarrollo de un portal Web capaz de articularse con una infraestructura de informacin y comunicaciones para proveer servicios computacionales fundamentales a travs de un modelo IaaS de cloud computing. La visin general de la arquitectura se ilustra en la Figura 13.

IaaS Model Type II Hypervisor UnaCloud Clients Operating System Hardware UnaCloud Server

IaaS User Grid User IaaS-Grid User Administrator

Figura 13. Visin general de la arquitectura de UnaCloud.

Como se puede apreciar en la visin ilustrada en la Figura 13, existen cuatro tipos de usuarios UnaCloud. Los usuarios IaaS son aquellos que demandan la 77

ejecucin del modelo IaaS sin elegir la localizacin de su despliegue. Estos usuarios acceden a una interface Web para la personalizacin y/o despliegue de mquinas virtuales con configuraciones de propsito genrico (por ejemplo, mquinas virtuales usadas para el soporte de actividades acadmicas). Los usuarios Grid son aquellos que demandan la ejecucin del modelo IaaS, eligiendo la localizacin de su despliegue en componentes especficos de la infraestructura fsica de soporte. Ellos acceden a una interface Web que les facilita personalizar y/o desplegar CVCs para la ejecucin de aplicaciones de e-Ciencia (por ejemplo, aplicaciones cluster o grid computing). Los usuarios IaaS-Grid son aquellos con permisos para acceder en forma excluyente a cualquiera de las dos interfaces anteriores. Adicionalmente existen usuarios administradores que adems de acceder a todas las interfaces disponibles para los usuarios finales (con todos los privilegios), acceden a las herramientas de administracin de la infraestructura base. La arquitectura de UnaCloud se divide en dos grandes componentes: UnaCloud Server y UnaCloud Client. Estos dos componentes se han implementado haciendo uso de tecnologas de informacin y comunicaciones abiertas que facilitan su interoperabilidad y extensibilidad, adaptndose a las condiciones de una infraestructura oportunista. UnaCloud Server est conformado por tres capas. La primera de ellas es un portal Web que acta como una interface de alta usabilidad a travs del cual todos los usuarios finales acceden a UnaCloud. Este mismo permite a los usuarios finales personalizar, desplegar, administrar y obtener los datos para acceder bajo demanda a su plataforma de experimentacin del modelo IaaS. Esto constituye un modelo de autoservicio en el cual un usuario final consume servicios computacionales con una mnima o nula interaccin humana con el proveedor de servicios. Este consumo es registrado para proveer trazabilidad a nivel de usuario. El portal Web est disponible en Internet por lo cual puede ser accedido por red mediante cualquier navegador Web. La segunda capa es una interface para facilitar la integracin del portal Web con la infraestructura computacional oportunista, esto incluye los procesos de personalizacin y administracin del modelo IaaS, la administracin de la infraestructura fsica de soporte y bases de datos usadas para mantener consistentes los registros asociados al estado de la infraestructura fsica y virtual. Finalmente, la tercera capa acta como un canal seguro de comunicaciones mediante el cual se envan ordenes para desplegar y administrar tanto la infraestructura del modelo IaaS como la infraestructura fsica de soporte. UnaCloud Client es un agente ligero, de fcil instalacin y alta portabilidad que se instala directamente sobre la infraestructura fsica de soporte, dispuesta para el 78

despliegue oportunista del modelo IaaS. Este cliente se encarga de la ejecucin en background y en prioridad baja de las mquinas virtuales que componen el modelo IaaS, de tal forma que un usuario de un recurso compartido no perciba una degradacin significativa en la calidad de servicio (control de impacto a los usuarios de los recursos compartidos) y sea posible el aprovechamiento permanente y optimizado de la infraestructura fsica bajo un modelo multiusuario. Para el despliegue de las mquinas virtuales, UnaCloud Client invoca al sistema operativo y al hypervisor tipo II cuando recibe una orden desde UnaCloud Server, esto es, despliegue bajo demanda y asignacin dinmica de la infraestructura virtual que compone el modelo IaaS. Todas las operaciones de UnaCloud Client estn limitadas a las rdenes recibidas desde UnaCloud Server mediante un paso de mensajes que incluye mecanismos de confidencialidad y no repudio. UnaCloud Client est dividido en dos capas. La primera de ellas es un canal seguro de comunicaciones mediante el cual recibe rdenes desde UnaCloud Server. Estas rdenes son procesadas por las funcionalidades soportadas en la segunda capa. Estas incluyen los procesos de adaptacin de las mquinas virtuales al contexto personalizado (elegido por el usuario final), la invocacin al sistema operativo local para la ejecucin de procesos de soporte, la invocacin al hypervisor tipo II para la administracin de mquinas virtuales y finalmente la monitorizacin del recurso fsico que aloja a UnaCloud Client. Finalmente UnaCloud Client puede instalarse en cualquier computador de escritorio o servidor que utilice los sistemas operativos Windows, Linux o Mac, en un modelo escalable de crecimiento horizontal, esto es, infraestructuras basadas en la agregacin de laboratorios de cmputo y recursos computacionales dispersos, heterogneos, de disponibilidad parcial y pertenecientes a diferentes dominios administrativos. 6.2. ARQUITECTURA Como se puede apreciar en el diagrama de componentes de la Figura 14, la arquitectura de UnaCloud se divide en dos componentes primarios: UnaCloud Server y UnaCloud Client. Estos componentes se dividen en capas basadas en servicios desacoplados, que interactan y se componen entre s para satisfacer los requerimientos del presente trabajo de investigacin (referirse al numeral 5.2). En las siguientes secciones se explica detalladamente la arquitectura de UnaCloud. Para cada componente primario se explica el diseo de alto nivel (diagramas de componentes) y el diseo de bajo nivel (diagramas de clases). Al final de la seccin tambin se detallan los modelos de procesos (diagramas de actividades) que describen las principales interacciones que ocurren entre los componentes de UnaCloud para satisfacer sus requerimientos funcionales en trminos de servicios. 79

cmp UnaCloud Architecture


Physical Administration

IaaS Customization

IaaS Administration

IaaS Deployment

UNACLOUD SERVER

Interface Layer

Core Layer Services

Core Layer

External Layer Services

External Layer

UnaCloud Client Services

UNACLOUD CLIENT

External Layer

Core Layer Services

Core Layer

Figura 14. Diagrama de componentes de la arquitectura de UnaCloud.

6.2.1. UnaCloud Server En trminos generales UnaCloud Server es el componente encargado de proveer la interface de entrada a los servicios de UnaCloud. Este componente primario posee una arquitectura de tres capas: Interface Layer, Core Layer y External Layer. En la Figura 15 se presenta un diagrama de componentes que representa a 80

IaaS Traceability

IaaS Monitoring

Physical Monitoring

UnaCloud Server con todos los servicios que incorpora. Este diagrama se corresponde con el componente UnaCloud Server ilustrado genricamente en la Figura 14. A continuacin se detallan las funciones del UnaCloud Server en trminos de las capas que lo componen.
cmp UnaCloud Serv er Architecture
IaaS Customization IaaS Administration IaaS Deployment IaaS Traceability

IaaS Monitoring

Physical Administration

UNACLOUD SERVER

Interface Layer

Web Interface

Core Layer

Customized Env ironment Manager

Virtual Machine Manager

Persistence Manager

Physical Infrastruture Manager

External Layer

Communication Manager

<<uses>>

Security Manager

UnaCloud Client Services

Figura 15. Diagrama de componentes de la arquitectura de UnaCloud Server.

81

Physical Monitoring

[Link].

Interface Layer

Esta capa se encarga de proveer la interface Web de entrada a los usuarios para el uso de los servicios proporcionados por UnaCloud. A continuacin se hace una descripcin del conjunto de servicios soportados por esta capa. Web interface: esta interface Web provee un servicio de acceso a la gama de servicios proporcionados por UnaCloud, tanto para usuarios finales como para usuarios administradores. Esta interface est compuesta por un portal Web que facilita el acceso y operacin intuitiva de los servicios proporcionados por UnaCloud. La Tabla 12 resume la implementacin del componente. Tabla 12. Implementacin del componente Web interface. SERVICIO IMPLEMENTACIN Autenticacin para el uso de los servicios proporcionados por UnaCloud. Esta autenticacin se basa en un nombre de usuario y clave, validados por la base de datos de UnaCloud (para usuarios ajenos a la Universidad de los Andes) y/o el servicio LDAP de la Universidad de los Andes. Autorizacin para el uso de los servicios proporcionados por UnaCloud. Creacin, edicin y eliminacin de registros asociados a los usuarios de UnaCloud. Esto incluye usuarios finales: IaaS, Grid e IaaS-Grid y usuarios administradores. Interface grfica de alta usabilidad para la captura de parmetros requeridos en la personalizacin del modelo IaaS (interface del componente Customized Environment Manager). Interface grfica de alta usabilidad para la captura de parmetros requeridos para el despliegue del modelo IaaS (interface del componente Customized Environment Manager). Interface grfica de alta usabilidad para la captura de parmetros requeridos para la operacin y administracin del modelo IaaS (interface del componente Virtual Machine Manager).

Autenticacin

Autorizacin Administracin de la informacin de usuarios Interface grfica de personalizacin del modelo de servicio IaaS Interface grfica de despliegue del modelo de servicio IaaS Interface grfica de administracin del modelo de servicio IaaS

Interface grfica de Interface grfica de alta usabilidad para monitorizar el estado del modelo IaaS (interface del componente monitoreo del modelo Virtual Machine Manager). de servicio IaaS

82

Interface grfica para Interface grfica de alta usabilidad para el reporte de la trazabilidad del trazabilidad del modelo IaaS (interface del componente modelo de servicio Persistence Manager). IaaS Interface grfica de alta usabilidad para la captura de Interface grfica de parmetros requeridos para la operacin y administracin de la administracin de mquinas fsicas que componen la infraestructura base del modelo IaaS (interface del infraestructura fsica componente Physical Infrastructure Manager). Interface grfica de alta usabilidad para monitorizar el Interface grfica de estado de ejecucin y las variables de entorno de las monitoreo de la mquinas fsicas que componen la infraestructura base del modelo IaaS (interface del componente Physical infraestructura fsica Infrastructure Manager). [Link]. Core Layer

Esta capa se encarga de proveer los servicios para la configuracin y posterior acceso al modelo IaaS, la provisin de un servicio de operacin y administracin de las mquinas virtuales que componen el modelo IaaS y la provisin de un servicio de operacin y administracin de la infraestructura base. A continuacin se hace una descripcin del conjunto de servicios soportados por esta capa. Customized Environment Manager: este componente se encarga de verificar la disponibilidad de los recursos necesarios para el despliegue del modelo IaaS. Para ello utiliza la informacin disponible en las base de datos de recursos fsicos y de instancias de mquinas virtuales. La Tabla 13 resume la implementacin del componente. Tabla 13. Manager. Implementacin del componente Customized Environment

SERVICIO

Configuracin hardware

Configuracin software

IMPLEMENTACIN Verificacin de la disponibilidad y asignacin de imgenes de mquinas virtuales con los parmetros de de hardware requeridos para el despliegue del modelo IaaS. Esto incluye el tamao del disco duro, nmero de ncleos de procesamiento y el tamao de la memoria RAM. Verificacin de la disponibilidad y asignacin de de imgenes de mquinas virtuales con los parmetros de software requeridos para el despliegue del modelo IaaS. Esto incluye el sistema operativo y el conjunto de aplicaciones instaladas sobre el mismo. 83

Nmero de instancias

Localizacin

Tiempo de ejecucin

Verificacin de la disponibilidad numrica de los recursos fsicos requeridos para el despliegue del modelo IaaS. Verificacin de la disponibilidad y asignacin de los recursos fsicos localizados para el despliegue del modelo IaaS. Verificacin de la disponibilidad, asignacin y cambio del tiempo de ejecucin asignado a las instancias de las mquinas virtuales que componen el modelo IaaS.

Virtual Machine Manager: este componente de encarga de la operacin y administracin de las mquinas virtuales. Esto incluye operaciones bsicas tales como: ejecucin, apagado, reinicio y monitoreo. La Tabla 14 resume la implementacin del componente. Tabla 14. Implementacin del componente Virtual Machine Manager. SERVICIO Ejecucin de mquinas virtuales Finalizacin de mquinas virtuales Reinicio de mquinas virtuales IMPLEMENTACIN Ejecucin de imgenes de mquinas virtuales usadas para la creacin del modelo IaaS. Apagado de instancias de mquinas virtuales usadas en el despliegue del modelo IaaS. Reinicio de instancias de mquinas virtuales usadas en el despliegue del modelo IaaS. Monitoreo de instancias de mquinas virtuales usadas Monitoreo de para la creacin del modelo IaaS. Esto nicamente incluye su estado (en ejecucin, finalizada) y mquinas virtuales configuraciones personalizadas (hardware, software, localizacin y tiempo de ejecucin). Creacin, edicin y eliminacin de registros asociados a una mquina virtual (nombre, laboratorio, direccionamiento IP, direccionamiento MAC, nmero de ncleos del procesador, tamao del disco duro, tamao Administracin de la de la memoria RAM, hypervisor, directorio, imagen y esquema de seguridad), sistema operativo (nombre, informacin de versin y tipo), hypervisor (nombre y versin), mquinas virtuales aplicaciones (nombre y versin), esquema de seguridad para el acceso remoto a las mquinas virtuales (nombre y clave del usuario administrador, mecanismo de acceso remoto y puerto) e imagen (nombre, tipo y aplicaciones). Persistence Manager: este componente de encarga de la presentacin y administracin de la informacin histrica de ejecuciones de las mquinas 84

virtuales (auditora) que componen el modelo IaaS. La Tabla 15 implementacin del componente. Tabla 15. Implementacin del componente Persistence Manager. SERVICIO

resume la

Trazabilidad modelo IaaS

IMPLEMENTACIN Auditora del uso del modelo IaaS incluyendo datos sobre la infraestructura fsica de soporte (nombre de la mquina fsica que alberg una ejecucin y nombre del laboratorio al que pertenece), datos del modelo IaaS (imagen desplegada, tipo de imagen, sistema operativo, versin del sistema operativo, tiempo de del ejecucin, tamao de disco, tamao de memoria, nmero de ncleos de procesador asignados, direccionamiento IP, direccionamiento MAC y finalmente datos del esquema de seguridad elegido para el acceso remoto a la infraestructura. Esta auditora se consulta a travs de reportes que facilitan llevar una trazabilidad de uso discriminada a nivel de usuario y ejecucin de una mquina virtual.

Physical Infrastructure Manager: este componente se encarga de la operacin y administracin de los recursos fsicos necesarios para la construccin de la infraestructura base del modelo IaaS. Esto incluye operaciones bsicas tales como: apagado, reinicio, bloqueo, desbloqueo y cierre de sesin. Adicionalmente ofrece una interface para monitorizar los recursos computacionales que componen la infraestructura base. La Tabla 16 resume la implementacin del componente. Tabla 16. Implementacin del componente Physical Infrastructure Manager. SERVICIO Apagado de mquinas fsicas Reinicio de mquinas fsicas Bloqueo Desbloqueo mquinas fsicas y de IMPLEMENTACIN Apagado de las mquinas fsicas usadas como parte de la infraestructura base del modelo IaaS (cuyo dominio administrativo lo permita). Reinicio de las mquinas fsicas usadas como parte de la infraestructura base del modelo IaaS (cuyo dominio administrativo lo permita). Bloqueo y desbloqueo lgico de mquinas fsicas para evitar o permitir su uso como parte de la infraestructura base del modelo IaaS.

Cierre de sesin de las mquinas fsicas usadas como Cierre de sesin de parte de la infraestructura base del modelo IaaS (cuyo dominio administrativo lo permita). mquinas fsicas

85

Monitoreo mquinas fsicas

de

Administracin de la informacin de la infraestructura fsica

Administracin del estado de la infraestructura fsica

Recepcin de la informacin de monitoreo de las mquinas fsicas usadas como parte de la infraestructura base del modelo IaaS. Esto incluye variables del estado actual del procesador, memoria, disco duro, red y sistema operativo. Creacin, edicin y eliminacin de registros asociados a una mquina fsica (nombre, laboratorio, direccionamiento IP, direccionamiento MAC, nmero de ncleos del procesador, tamao del disco duro, tamao de la memoria RAM, arquitectura, directorio de instalacin del hypervisor, sistema operativo y coordenadas de ubicacin para el caso de mquinas pertenecientes a laboratorios fsicos) o a un laboratorio de cmputo (nombre, nmero de filas, nmero de columnas y tipo). Recepcin de la informacin pertinente al estado de la infraestructura fsica. Esto incluye un seguimiento a los eventos de encendido, apagado, inicio y cierre de sesin (si el dominio administrativo lo permite). Este servicio es implementado en forma desacoplada de la interface Web de UnaCloud Server, principalmente para reducir la carga de comunicaciones y el procesamiento de hilos por parte del contenedor Web.

[Link].

External Layer

Esta capa se encarga de proveer los servicios de administracin de las comunicaciones del lado del servidor y los mecanismos para garantizar seguridad en las mismas. A continuacin se hace una descripcin del conjunto de servicios soportados por esta capa. Server Communication Manager: este componente se encarga de la administracin de las comunicaciones del lado del servidor. Esto incluye operaciones de conexin, desconexin y paso de mensajes. La Tabla 17 resume la implementacin del componente. Tabla 17. Implementacin del componente Server Communication Manager. SERVICIO IMPLEMENTACIN Conexin con los Conexin con los clientes. clientes Desconexin con los Desconexin con los clientes. clientes Paso de mensajes desde y hacia los clientes. Paso de mensajes 86

Server Security Manager: este componente se encarga de la administracin de la seguridad en las comunicaciones del lado del servidor. La Tabla 18 resume la implementacin del componente. Tabla 18. Implementacin del componente Server Security Manager. SERVICIO Conexin con clientes Cifrado comunicaciones Descifrado comunicaciones [Link]. IMPLEMENTACIN los Conexin con no repudio con los clientes. de Cifrado de las comunicaciones con los clientes. de Descifrado de las comunicaciones con los clientes.

Diagrama de clases de UnaCloud Server

En el Anexo B1 se presenta y explica el diagrama de clases de las principales entidades de UnaCloud Server. 6.2.2. UnaCloud Client UnaCloud Client es el componente encargado de ejecutar las rdenes de UnaCloud Server, pertinentes a administrar la infraestructura oportunista de soporte y las operaciones requeridas para el despliegue y administracin del modelo IaaS. Este componente primario posee una arquitectura de dos capas: External Layer y Core Layer. En la Figura 16 se presenta un diagrama de componentes que representa a UnaCloud Client con todos los servicios que incorpora. Este diagrama se corresponde con el componente UnaCloud Client ilustrado genricamente en la Figura 14. A continuacin se detallan las funciones del UnaCloud Client en trminos de las capas que lo componen. [Link]. External Layer

Esta capa se encarga de proveer los servicios de administracin de las comunicaciones del lado del cliente y los mecanismos para garantizar seguridad en las mismas. A continuacin se hace una descripcin del conjunto de servicios soportados por esta capa.

87

cmp UnaCloud Client Architecture


Physical Administration

IaaS Customization

IaaS Deployment

IaaS Administration

UNACLOUD CLIENT

External Layer

Security Manager

<<uses>>

Communication Manager

Core Layer

Context Manager

Local Executor Manager

Hyperv isor Manager

IaaS Monitoring

Monitoring Manager

Operating System Services

Hypervisor Services

Figura 16. Diagrama de componentes de la arquitectura de UnaCloud Client.

Client Communication Manager: este componente se encarga de la administracin de las comunicaciones del lado del cliente. Esto incluye operaciones de conexin, desconexin y paso de mensajes. La Tabla 19 resume la implementacin del componente. 88

Physical Monitoring

Tabla 19. Implementacin del componente Client Communication Manager. SERVICIO Conexin Desconexin Paso de mensajes IMPLEMENTACIN Conexin con el servidor. Desconexin con el servidor. Paso de mensajes desde y hacia el servidor.

Client Security Manager: este componente se encarga de la administracin de la seguridad en las comunicaciones del lado del cliente. La Tabla 20 resume la implementacin del componente. Tabla 20. Implementacin del componente Client Security Manager. SERVICIO Conexin con clientes Cifrado comunicaciones Descifrado comunicaciones [Link]. IMPLEMENTACIN los Conexin con no repudio con el servidor. de Cifrado de las comunicaciones con el servidor. de Descifrado de las comunicaciones con el servidor.

Core Layer

Esta capa se encarga de proveer los servicios para la personalizacin, administracin y monitorizacin de las mquinas virtuales que componen el modelo IaaS y la administracin y monitorizacin de la infraestructura fsica base. A continuacin se hace una descripcin del conjunto de servicios soportados por esta capa. Context Manager: este componente se encarga de adaptar la ejecucin de una mquina virtual al contexto del ambiente personalizado que es requerido por un usuario final a travs de UnaCloud Server. La Tabla 21 resume la implementacin del componente. Tabla 21. Implementacin del componente Context Manager. SERVICIO Configuracin del nmero de ncleos de procesamiento Configuracin de la memoria RAM IMPLEMENTACIN Configuracin del nmero de ncleos de una mquina virtual a instanciarse. Configuracin del tamao de la memoria RAM de una mquina virtual a instanciarse. 89

Configuracin del Configuracin y cumplimiento del tiempo de ejecucin tiempo de ejecucin de una mquina virtual. Hypervisor Manager: este componente se encarga de ejecutar los requerimientos del servidor en independencia del hypervisor tipo II instalado de la mquina fsica en uso. La Tabla 22 resume la implementacin del componente. Tabla 22. Implementacin del componente Hypervisor Manager. IMPLEMENTACIN Ejecucin de comandos mediante llamados a los servicios del hypervisor local. Estas ejecuciones estn restringidas a las operaciones necesarias para soportar Operaciones sobre el las funciones requeridas por el componente Hypervisor hypervisor Manager de UnaCloud Server. Esto incluye operaciones encendido, apagado, reinicio y monitoreo del estado de mquinas virtuales Local Executor Manager: este componente se encarga de ejecutar los requerimientos del servidor en independencia del sistema operativo de la mquina fsica en uso. La Tabla 23 resume la implementacin del componente. Tabla 23. Implementacin del componente Local Executor Manager. Ejecucin de comandos mediante llamados a los servicios del sistema operativo local. Estas ejecuciones estn restringidas a las operaciones necesarias para Operaciones sobre el soportar las funciones de los componentes: Physical sistema operativo Infrastructure Manager, Virtual Machine Manager y Customized Environment Manager de UnaCloud Server. Monitoring Manager: este componente se encarga de recolectar las variables de estado del procesador, memoria, disco duro, red y sistema operativo de la mquina fsica donde reside un UnaCloud Client. Esta informacin es recolectada y devuelta al UnaCloud Server bajo demanda, de tal modo que siempre refleja el estado actual de la mquina fsica. La Tabla 24 resume la implementacin del componente. SERVICIO

90

Tabla 24. Implementacin del componente Monitoring Manager. SERVICIO Monitoreo de mquinas fsicas IMPLEMENTACIN Recoleccin y envo de la informacin de monitoreo de las las mquinas fsica en donde reside el cliente. Esto incluye variables de estado actual del procesador, memoria, disco duro, red y sistema operativo. Diagrama de clases de UnaCloud Client

[Link].

En el Anexo B2 se presenta y explica el diagrama de clases de las principales entidades de UnaCloud Client. 6.3. MODELO DE PROCESOS DE UNACLOUD Los servicios de UnaCloud descritos en las secciones previas, son consumidos por los usuarios finales a travs de la ejecucin de procesos basados en los requerimientos funcionales y no funcionales de UnaCloud (referirse al numeral 5.2). A continuacin de hace la descripcin de un conjunto significativo de estos procesos. 6.3.1. Personalizacin del modelo IaaS La Figura 17 corresponde al diagrama de actividades del proceso de personalizacin del modelo IaaS. El inicio se antecede de un procedimiento de autenticacin y autorizacin que permite a los usuarios la entrada a los servicios de UnaCloud. Posteriormente se muestra un men que facilita al usuario seleccionar la forma del despliegue. Si el usuario desea una personalizacin completa, se mostraran una serie de mens interdependientes que permiten la seleccin del tipo de sistema operativo, la versin del sistema operativo, el conjunto de aplicaciones pre instaladas, los tamaos de disco duro y memoria RAM, el nmero de ncleos de CPU, el nmero de instancias a ejecutar y el tiempo de ejecucin. Por otra parte, si el usuario desea omitir la personalizacin completa, tiene la opcin de desplegar el modelo IaaS seleccionando nicamente el nombre de la imagen, es decir, el nombre otorgado al conjunto de aplicaciones pre instalado en la mquina virtual o el nombre del CVC para el caso de un usuario Grid, el nmero de instancias a ejecutar y el tiempo de ejecucin. Para el caso de los usuarios Grid se tiene una interface para seleccionar la localizacin de la ejecucin del CVC, es decir, la posibilidad de localizar las ejecuciones de mquinas virtuales en componentes especficos de la infraestructura fsica de soporte. Esto adquiere una gran utilidad al hacer uso de 91

una infraestructura oportunista de disponibilidad variante, en donde puede ser necesario tener preferencias para la localizacin de un CVC, con la finalidad de agilizar la obtencin de resultados, documentar exhaustivamente la experimentacin u optimizar el aprovechamiento de los recursos fsicos disponibles.
act IaaS Customization

Authentication Process Full Customization

IaaS Customization

Yes Customize Operating System Type Customize Operating System Version

No Customize Deployable Image Customize Hard Disk Size

End User Type Customize RAM Memory Size Customize CPU Cores

Grid Customize Instances Number and Localization

Cloud Customize Execution Instances Number

Customize Execution Time

No adaptation path UnaCloud Server UnaCloud Client

Deploy IaaS

Figura 17. Proceso de personalizacin del modelo IaaS en UnaCloud.

6.3.2. Despliegue del modelo IaaS La Figura 18 corresponde al diagrama de actividades del proceso de despliegue del modelo IaaS. El inicio se antecede por el proceso de personalizacin del modelo IaaS analizado anteriormente. Luego el componente UnaCloud Client recibe la solicitud de despliegue desde UnaCloud Server y se encarga de su procesamiento. Si la solicitud corresponde a una personalizacin completa, se ejecuta una adaptacin al contexto deseado, a travs de la modificacin de los 92

parmetros asociados al nmero de ncleos de procesamiento y el tamao de la memoria RAM. Si la solicitud no corresponde a una personalizacin completa, se omiten las actividades de adaptacin ya que la mquina virtual se ejecutar con su configuracin actual. Posteriormente UnaCloud Client reserva el tiempo de ejecucin para la mquina virtual y ejecuta la misma a travs de invocaciones al sistema operativo y al hypervisor tipo II, instalados en la infraestructura fsica de despliegue. Finalmente UnaCloud Server proporciona al usuario final todos los datos necesarios para acceder remotamente a su modelo IaaS.
act IaaS Deployment

IaaS Deployment
IaaS Customization Full Customization

Yes Virtual Machine CPU Cores Context Adaptation Virtual Machine RAM Memory Size Context Adaptation

No Virtual Machine Execution Time Scheduling Operating System Serv ices Inv ocation

Virtual Machine Executed Hyperv isor Type II Serv ices Inv ocation

Yes Send Confirmation to UnaCloud Serv er No Show Remote Connection Data Show Error Message

No adaptation path UnaCloud Server UnaCloud Client


IaaS Administration

Figura 18. Proceso de despliegue del modelo IaaS en UnaCloud.

6.3.3. Administracin del modelo IaaS La Figura 19 corresponde al diagrama de actividades del proceso administracin del modelo IaaS. El inicio se antecede por el proceso despliegue del modelo IaaS analizado anteriormente. Luego la interface Web UnaCloud Server despliega un men con un conjunto de operaciones 93 de de de de

administracin disponibles para las mquinas virtuales desplegadas por el usuario final, incluyendo su apagado, reinicio y monitoreo. El monitoreo de mquinas virtuales implica un intercambio de mensajes entre UnaCloud Server y UnaCloud Client para requerir las variables de estado de una mquina virtual. UnaCloud Client recolecta y devuelve estas variables a UnaCloud Server para su presentacin al usuario final en compaa de otras variables histricas pertinentes al contexto de ejecucin. Tanto para la operacin de apagado como para la operacin de reinicio, UnaCloud Server enva una orden a UnaCloud Client quien la ejecuta a travs de la invocacin a los servicios del sistema operativo y del hypervisor local. UnaCloud Server permite al usuario final extender o disminuir el tiempo de ejecucin de una mquina virtual. Este proceso requiere un intercambio de mensajes entre UnaCloud Server y UnaCloud Client y un llamado a los componentes de persistencia para registrar un cambio en los datos histricos de ejecucin de mquinas virtuales.
act IaaS Administration

IaaS Deployment Operation Type Monitor Monitor IaaS

IaaS Administration

Request Monitor Variables to UnaCloud Client

Collect and Send Virtual Machine State Variables to UnaCloud Serv er

Display the Monitoring Report

Turn Off

Turn Off Virtual Machine

Send Virtual Machine Turn Off Order to UnaCloud Client

Operating System Serv ices Inv ocation

Hyperv isor Serv ices Inv ocation

Restart

Restart Virtual Machine

Send Virtual Machine Restart Order to UnaCloud Client Send Virtual Machine Execution Time Order to UnaCloud Client

Execution Time

Change Virtual Machine Execution Time

Change the Current Virtual Machine Scheduling UnaCloud Server UnaCloud Client

Figura 19. Proceso de administracin del modelo IaaS en UnaCloud.

6.3.4. Administracin de la infraestructura base La Figura 20 corresponde al diagrama de actividades del proceso de administracin de la infraestructura base. Este proceso nicamente puede ser llevado a cabo por usuarios administradores y no es dependiente de los procesos analizados anteriormente. La interface Web de UnaCloud Server despliega un listado de todos los laboratorios fsicos y virtuales registrados en UnaCloud. Al 94

seleccionar un laboratorio fsico se despliega un mapa con la localizacin exacta de todos sus recursos computacionales. Para el caso de los laboratorios virtuales se despliega un mapa con una localizacin geomtrica que ordena todos sus recursos computacionales. Los laboratorios virtuales generalmente contienen recursos computacionales que no pertenecen a laboratorios fsicos y que por lo tanto, no poseen variables de localizacin que puedan ser usadas como referencia.
act Physical Administration

Physical Administration
Operation Type Monitor Collect and Send Virtual Machine State Variables to UnaCloud Serv er

Monitor Physical Machine

Request Monitor Variables to UnaCloud Client

Display the Monitoring Report

Turn Off

Turn Off Physical Machine

Send Physical Machine Turn Off order to UnaCloud Client Send Physical Machine Restart order to UnaCloud Client Send Physical Machine Logout order to UnaCloud Client

Restart

Restart Physical Machine

Operating System Serv ices Inv ocation

Logout

Logout Physical Machine

UnaCloud Server UnaCloud Client

Figura 20. Proceso de administracin de la infraestructura base en UnaCloud.

Asociado a la seleccin de recursos computacionales, se despliega un men con un conjunto de operaciones de administracin disponibles para la infraestructura fsica que soporta al modelo IaaS, incluyendo su apagado, reinicio, bloqueo y desbloqueo, cierre de sesin y monitoreo. El monitoreo de recursos computacionales implica un intercambio de mensajes para requerir las variables de estado de un recurso. UnaCloud Client recolecta y devuelve estas variables a UnaCloud Server para su presentacin al usuario final de tal forma que estas mismas siempre reflejan el estado actual de un recurso fsico. Para las operaciones de apagado, bloqueo y desbloqueo, reinicio y cierre de sesin, UnaCloud Server enva una orden a UnaCloud Client quien la ejecuta a travs de la invocacin a los servicios del sistema operativo local. Estas rdenes nicamente pueden ser llevadas a cabo en dominios administrativos que autoricen a 95

UnaCloud para su ejecucin, con el fin de otorgarle una mayor granularidad al esquema de seguridad del sistema. 6.4. MECANISMOS DE COMUNICACIONES Como se ha detallado en las secciones anteriores, UnaCloud est basado en la integracin de un sistema de informacin con una infraestructura computacional de crecimiento horizontal. Dicha integracin se apoya en mecanismos de comunicaciones cuyo diseo e implementacin deben adaptarse a los requerimientos no funcionales planteados en el numeral 5.2.2. En trminos de comunicaciones, entre los requerimientos se destacan: facilidad de instalacin, seguridad e interoperabilidad, extensibilidad y bajo acoplamiento. Teniendo en cuenta estos requerimientos, UnaCloud utiliza la implementacin estandarizada de sockets TCP (Transmission Control Protocol) del lenguaje de programacin Java, con el fin de articular eficiente y confiablemente las comunicaciones entre sus componentes. Dicha eleccin obedece a tres razones fundamentales: Minimizacin de la complejidad de instalacin y configuracin para un despliegue escalable: la implementacin de sockets incorporada en el lenguaje de programacin Java no requiere de la instalacin adicional de ningn tipo de software de comunicaciones. Esto otorga facilidad, rapidez y escalabilidad al proceso de instalacin y despliegue de UnaCloud. En contraposicin, opciones como los servicios Web requieren de la instalacin de servidores o contenedores Web que deben ser configurados y probados para su correcto uso. Por otra parte, opciones como RMI utilizan puertos que generalmente estn bloqueados por defecto en los firewalls. Si bien existe la opcin de empaquetar los mensajes RMI en mensajes HTTP, como se demuestra en (168), los costos en el desempeo de esta solucin la hacen una opcin ineficiente. Desempeo: como se demuestra en (169) y en (170) los sockets son mecanismos de comunicaciones ms eficientes para entornos LAN que los servicios Web y RMI, debido a que estos ltimos hacen uso de una mayor cantidad de encabezados y datos de control. Interoperabilidad, extensibilidad y bajo acoplamiento: como se afirma en (171), los sockets son el mecanismo ms difundido y universal de comunicacin. Tecnologas como los servicios Web y RMI otorgan un menor grado acoplamiento, pero estos beneficios nicamente son apreciables en sistemas complejos, con dominios administrativos heterogneos para la distribucin de sus arquitecturas. Intrusin y reserva de recursos: como se afirma en (170), los sockets minimizan la reserva de recursos computacionales en contraposicin a tecnologas como los 96

servicios Web y RMI. Esto se debe a que los sockets operan sobre la capa de transporte (cuarta capa) del modelo OSI, mientras los servicios Web operan sobre capa de aplicaciones (sptima capa), haciendo uso de servidores Web que reservan ms recursos de procesamiento, memoria y red para su correcta operacin. Aunque RMI hace un uso ms eficiente de los recursos de procesamiento y memoria, el uso de encabezados y datos de control conlleva a mayor saturacin de los recursos de red. 6.4.1. Mecanismos de seguridad en las comunicaciones En forma adicional a la implementacin de los mecanismos de comunicaciones, se hace necesaria la inclusin de mecanismos de seguridad que protejan y mantengan la confiabilidad en el paso de mensajes, esto es, un mecanismo de comunicaciones eficiente, rpido y seguro. Los mecanismos de seguridad se dividen en los dos tipos de comunicaciones posibles dentro del sistema: Comunicaciones entre UnaCloud Server y UnaCloud Client: UnaCloud Server posee una llave asimtrica pblica y una llave asimtrica privada basada en el algoritmo RSA. Estas llaves tienen un tamao de 2048 bits, tamao considerado confiable hasta el 2030 segn el estudio publicado en (172). Cada UnaCloud Client posee la llave pblica de UnaCloud Server.
1. UnaCloud Server enva un mensaje a UnaCloud Client. Este mensaje ha sido cifrado con la llave privada de UnaCloud Server. 2. UnaCloud Client recibe el mensaje desde UnaCloud Server.
1 2

Public Key Private Key UnaCloud Server UnaCloud Client

Public Key

3 True False 3a

3. UnaCloud Client descifra el mensaje utilizando la llave pblica de UnaCloud Server y un orden especifico para el tratamiento de los parmetros recibidos. 3a. Si el mensaje descifrado contiene parmetros interpretables por UnaCloud Client, en su orden correcto, este procede a su ejecucin. 3b. Si el mensaje descifrado no contiene parmetros interpretables o el orden de los mismos es incorrecto, UnaCloud Client descarta el mensaje.

3b

Figura 21. Protocolo de seguridad entre UnaCloud Server y UnaCloud Client.

Como se puede apreciar en la Figura 10, cada mensaje enviado por UnaCloud Server es cifrado con su llave privada. Al recibir el mensaje, UnaCloud Client 97

descifra el mensaje haciendo uso de la llave pblica de UnaCloud Server. Si el mensaje es consistente con una de las posibles rdenes que UnaCloud Client puede procesar y estas mismas estas expresadas en un orden vlido, el proceso ha conllevado a un paso de mensajes confiable y la ejecucin de una operacin basada en el no repudio (nicamente el poseedor de la llave privada de UnaCloud Server pudo haber enviado a ejecutar la orden). Comunicaciones entre UnaCloud Client y UnaCloud Server: todos los mensajes enviados desde UnaCloud Client a UnaCloud Server son cifrados utilizando la llave pblica de UnaCloud Server, garantizando que este ltimo sea el nico capaz de interpretarlos, esto es, confidencialidad. Adicionalmente y para garantizar el cumplimiento del modelo de cloud privado de UnaCloud, se implement un mecanismo de identificacin nica de cada UnaCloud Client con el fin de efectuar un proceso de autenticacin.
1. UnaCloud Client enva un mensaje a UnaCloud Server. Este mensaje ha sido cifrado con la llave pblica de UnaCloud Server. 2. UnaCloud Server recibe el mensaje desde UnaCloud Client. 3. UnaCloud Server descifra el mensaje utilizando su llave privada y un orden especifico para el tratamiento de los parmetros recibidos. 3a. Si el mensaje descifrado contiene parmetros interpretables por UnaCloud Server, en su orden correcto y contiene los parmetros de identificacin nicos del UnaCloud Client (direccin IP, direccin MAC, nombre de equipo y nmero serial de la tarjeta madre) este procede a responder la peticin. 3b. Si el mensaje descifrado no contiene parmetros interpretables, el orden de los mismos es incorrecto o no contiene los parmetros de identificacin nicos del UnaCloud Client, UnaCloud Server descarta el mensaje.

Public Key Private Key UnaCloud Server UnaCloud Client

Public Key

3 True False 3a

3b

Figura 22. Protocolo de seguridad entre UnaCloud Client y UnaCloud Server.

Como se puede apreciar en la Figura 22, en el primer paso de mensajes entre UnaCloud Client y UnaCloud Server, el primero obtiene el nmero serial de la tarjeta madre de la mquina fsica donde ha sido desplegado. Este nmero serial en compaa de otros datos de configuracin de software y hardware de la mquina fsica son enviados a UnaCloud Server para ser cotejados con registros 98

Web previos. Si los datos coinciden, UnaCloud Server almacena el nmero serial enviado por UnaCloud Client, utilizndolo como su identificador nico. Para todos los procesos de comunicacin subsecuentes, UnaCloud Client enviar un mensaje cifrado con la llave pblica de UnaCloud Server y el nmero serial de su tarjeta madre (calculado en el instante). Esto garantizar confidencialidad en el paso de mensajes y no repudio, ya que ningn recurso fsico que intente suplantar a un UnaCloud Client (a travs de la clonacin del agente y de las configuraciones particulares de software y hardware) podr falsificar el nmero serial de la tarjeta madre, ms aun el orden de combinacin de envo de parmetros que UnaCloud Server utilizar en el descifrado del mensaje para corroborar su validez. Utilizando estos protocolos de seguridad se eliminan las vulnerabilidades asociadas a la apertura de los sockets TCP tanto en UnaCloud Client como en UnaCloud Server, sin impactar contundentemente el desempeo general del sistema (tiempo para el paso de mensajes y tiempo para la administracin de las mquinas virtuales). Al igual que en la mayora de implementaciones oportunistas estudiadas en Anexo A, los mecanismos de seguridad seleccionados, no utilizan mecanismos de autenticacin basados en certificados digitales en los dos puntos de comunicaciones. Esto se debe a que la provisin de una llave privada para un UnaCloud Client no puede efectuarse a travs de la red (una llave privada no debe exponerse a intercepcin), motivo por el cual cada instalador de UnaCloud Client al incorporar una llave privada, sera distinto y nico, disminuyendo las ventajas de facilidad de instalacin y portabilidad que otorga un modelo de instalacin basado en agentes ligeros, escalable a Internet. Es importante destacar que estos mecanismos de seguridad retoman y adaptan las ideas estudiadas en implementaciones oportunistas escalables a Internet.

99

7. IMPLEMENTACIN, PRUEBAS Y RESULTADOS Este captulo tiene como objetivo describir y analizar la implementacin, pruebas y resultados obtenidos con UnaCloud. Este captulo se organiza de la siguiente forma: en la primera seccin se describen las fases de implementacin del prototipo, en la segunda seccin se presentan las herramientas utilizadas para el desarrollo de UnaCloud, en la tercera seccin se describe la implementacin final de UnaCloud en trminos de sus servicios, finalmente en la cuarta seccin se presentan las pruebas y resultados de la validacin a las estrategias, tiempos de respuesta y funcionalidades de UnaCloud. 7.1. FASES DE IMPLEMENTACIN El prototipo desarrollado en este trabajo de investigacin fue implementado en dos fases. La primera fase constituy un esfuerzo por solucionar dos de las nueve problemticas identificadas en el contexto de UnaGrid (referirse al numeral 4.2). Estas incluyen: usabilidad y personalizacin de servicios bajo demanda. Para lograr la incorporacin de estas caractersticas en UnaGrid, se desarroll un portal Web denominado: GUMA Grid Uniandes Management Application, el cual proporcion una primera interface Web para que los usuarios finales de UnaGrid pudieran realizar despliegues de CVCs sobre la infraestructura fsica de los laboratorios del Departamento de Ingeniera de Sistemas y Computacin de la Universidad de los Andes. A travs de esta interface Web se proporcionaron servicios para la administracin de usuarios, laboratorios fsicos y CVCs. Como se ilustra en la Figura 23, el proceso de despliegue de un CVC permiti que la ejecucin de mquinas virtuales ocurriera bajo demanda, durante tiempos de vida parametrizables y fuese localizada en componentes especficos de la infraestructura fsica de soporte. La implementacin del mecanismo de despliegue localizado se hizo a travs de la presentacin Web del mapa de la infraestructura fsica de soporte, en el cual un usuario poda seleccionar una o varias mquinas y efectuar las operaciones de ejecucin y finalizacin de mquinas virtuales durante un tiempo de vida parametrizable. La implementacin del mecanismo de ejecucin bajo demanda se soport en el ejecutor de procesos remotos PsExec versin 1.94 (173), una variacin de telnet, capaz de ejecutar remotamente comandos MS-DOS en distribuciones Windows. Si bien PsExec facilit el envo de comandos a la infraestructura fsica para el despliegue de mquinas virtuales, este mismo no puede ser modificado, no incluye ningn mecanismo de seguridad para el paso de mensajes (tanto para comandos como para datos de autenticacin) y est limitado a distribuciones Windows bajo un dominio administrativo nico, lo cual redunda en

100

las problemticas de extensibilidad, seguridad y escalabilidad ya existentes en UnaGrid (referirse al numeral 4.2).
act CVC Deployment

CVCs Deployment

Select CVC

Customize Localization and Instances Number

Customize CVC Execution Time

Deploy CVC

Operating System Serv ices Inv ocation

Hyperv isor Type II Serv ices Inv ocation

GUMA PsExec

Figura 23. Proceso de despliegue de un CVC en GUMA.

Por ese motivo, aunque GUMA otorg una mayor usabilidad a UnaGrid, no incorpor mecanismos para la personalizacin bajo demanda de las mquinas virtuales a ejecutarse, esto es, personalizacin de parmetros tales como: sistema operativo, aplicaciones, tamaos del disco duro y memoria RAM, nmero de ncleos de procesamiento, etc. Por este motivo GUMA fue catalogada como una solucin grid computing, cuyas funcionalidades apoyaron la consecucin de los resultados de investigacin publicados en (165), (174) y (175). La segunda fase del prototipo desarrollado en este trabajo de investigacin abarc todas las problemticas previamente identificadas en UnaGrid y los requerimientos funcionales y no funcionales planteados para este trabajo de investigacin (referirse al numeral 5.2). Aunque UnaCloud retoma algunas ideas de diseo e implementacin de GUMA4, su diseo e implementacin fueron cambiados e implementados en otras tecnologas con el propsito de satisfacer requerimientos funcionales y no funcionales asociados a la experimentacin cloud computing. Estos cambios conllevaron a que la propuesta de este trabajo de investigacin fuera implementada en su totalidad a travs de UnaCloud. La Tabla 25 muestra una comparacin entre GUMA y UnaCloud. Esta comparacin adopta como

Ideas construidas e implementadas en su momento con la colaboracin del equipo de trabajo de UnaGrid.

101

criterios de evaluacin las caractersticas principales de cloud computing que fueron identificadas en el numeral 2.1.3. Tabla 25. Comparacin entre los prototipos implementados CARACTERSTICA
Usabilidad Modelo de autoservicio Acceso a travs de red Personalizacin de servicios bajo demanda Modelo multiusuario Virtualizacin Escalabilidad Interoperabilidad y bajo acoplamiento Extensibilidad Administracin delegada Acuerdos de nivel de servicio y calidad de servicio Seguridad Modelo de trazabilidad

GUMA

UnaCloud

X X X X X X

7.2. HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD Como se describi en el captulo anterior, la arquitectura de UnaCloud se divide en dos grandes componentes: UnaCloud Server y UnaCloud Client (referirse a la Figura 14). A continuacin se describen las herramientas empleadas para la implementacin de cada uno de estos componentes. Es importante destacar que todas las herramientas fueron seleccionadas teniendo en cuenta dos propsitos fundamentales. El primero de ellos fue utilizar tecnologas abiertas, multipropsito y ampliamente difundidas. Esta seleccin maximiza la interoperabilidad y facilita la extensibilidad de UnaCloud, proporcionando un ambiente de desarrollo sin limitaciones para la experimentacin cloud computing. El segundo propsito fue la obtencin del mayor desempeo posible ante las condiciones de una infraestructura oportunista de crecimiento horizontal. Esta seleccin otorga un grado de intrusin mnimo y garantiza un aprovechamiento eficiente de los recursos fsicos y virtuales dispuestos para el despliegue del modelo IaaS. 7.2.1. Herramientas utilizadas para el desarrollo de UnaCloud Server En el Anexo C1 se describen las herramientas utilizadas para el desarrollo de UnaCloud Server. Esta descripcin se ampla con la estructuracin de las mismas en trminos de las capas de la arquitectura UnaCloud Server: Interface Layer, Core Layer y External Layer.

102

7.2.2. Herramientas utilizadas para el desarrollo de UnaCloud Client En el Anexo C2 se describen y estructuran las herramientas utilizadas para el desarrollo de UnaCloud Client en trminos de su arquitectura en dos capas: External Layer y Core Layer. 7.3. IMPLEMENTACIN DE UNACLOUD Esta seccin describe la implementacin final de UnaCloud en trminos de sus servicios, los cuales que fueron ampliamente descritos en la arquitectura de sus componentes (referirse al numeral 6.2). La implementacin final de UnaCloud Server tiene ms de 12000 lneas de cdigo incluyendo ms de 180 clases Java. El portal Web que soporta a UnaCloud Server incluye adems componentes: JSF, HTML, JavaScript y CSS (Cascading Style Sheets) para soportar todas las tecnologas de la presentacin Web. Por otra parte, UnaCloud Client fue implementado como un agente liviano. El mismo consta de aproximadamente 25 clases con ms de 2500 lneas de cdigo compiladas y empaquetadas en un archivo de extensin .jar que en conjunto con sus libreras y scripts no superan los 12MB, facilitando su transferencia, portabilidad y proceso de instalacin (176). Adicionalmente, todo el cdigo fuente fue escrito y documentado en idioma ingls, principalmente para facilitar su entendimiento y extensibilidad. A continuacin se hace la descripcin de la implementacin final de UnaCloud. 7.3.1. Procedimiento de autenticacin para el acceso a los servicios de UnaCloud El catlogo de servicios disponibles en UnaCloud, nicamente puede ser accedido y consumido por usuarios finales o administradores previamente autorizados. Para ello, UnaCloud proporciona un servicio para facilitar la autenticacin a los usuarios. La Figura 24 ilustra la interface dispuesta para la autenticacin de los usuarios UnaCloud. Es importante destacar que todas las interfaces Web de UnaCloud utilizan el protocolo cifrado HTTPS (Hypertext Transfer Protocol Secure) para proteger la transferencia de todos los datos en la red. Una vez se ha ejecutado el proceso de autenticacin en forma exitosa, UnaCloud despliega un men principal adaptado al tipo de usuario. Para los usuarios IaaS se despliega un men que les facilita el despliegue del modelo IaaS en dos modos: personalizando totalmente su ejecucin o seleccionado una imagen disponible (para evitar la repeticin del proceso de personalizacin). Para los usuarios Grid se despliega un men que les facilita el despliegue localizado del modelo IaaS en dos modos: personalizando totalmente su ejecucin o seleccionado un CVC disponible. Para los usuarios IaaS-Grid se despliegan los dos mens anteriores, 103

facilitndoles acceder a los mismos en forma excluyente. Finalmente para los usuarios administradores se despliegan todos los mens disponibles para los usuarios finales y un men especial que les facilita el acceso a todos los servicios y herramientas de administracin del modelo IaaS y de la infraestructura fsica de soporte.

Figura 24. Autenticacin de usuarios UnaCloud.

7.3.2. Procedimiento de administracin de usuarios UnaCloud El registro que autoriza a un usuario para el acceso y consumo de los proporcionados por UnaCloud, es un procedimiento efectuado por los administradores a quienes UnaCloud proporciona un servicio administracin de usuarios. Como se ilustra Figura 25 (a partir de esta omite el encabezado de UnaCloud visible en la Figura 24), este servicio creacin, edicin, bsqueda (por nombre o tipo) y eliminacin de asociados a los usuarios finales y administradores de UnaCloud. servicios usuarios para la figura se facilita la registros

Figura 25. Administracin de usuarios UnaCloud.

104

7.3.3. Proceso de personalizacin del modelo IaaS Este proceso incluye todos los servicios de personalizacin descritos en la Tabla 13 y el modelo de procesos descrito en numeral 6.3.1. Debido a la existencia de mltiples tipos de usuarios UnaCloud, a continuacin se discrimina la descripcin de la implementacin final con base en los mismos: Usuarios IaaS: todos los usuarios IaaS (incluyendo administradores y usuarios IaaS-Grid que asuman el rol IaaS) pueden hacer uso del servicio de personalizacin del modelo IaaS. Como se ilustra en la secuencia compuesta por las Figuras 26, 27, 28, 29, 30, 31, 32 y 33, UnaCloud proporciona interfaces Web para la personalizacin del modelo IaaS a travs de la seleccin de ocho configuraciones especificas: tipo de sistema operativo, versin del sistema operativo, conjunto de aplicaciones pre instaladas, tamao del disco duro, nmero de ncleos de procesamiento, tamao de la memoria RAM, nmero de instancias a ejecutar y tiempo de ejecucin total.

Figura 26. Personalizacin del tipo de sistema operativo.

El proceso de personalizacin del modelo IaaS inicia con la seleccin del tipo de sistema operativo. Actualmente UnaCloud es compatible con todos los sistemas operativos soportados por los hypervisors que administra (VMware Workstation versiones 6.5 y 7), de tal forma que UnaCloud est en capacidad de desplegar ms de 200 sistemas operativos en arquitecturas de 32 y 64 bits. Posteriormente el proceso de personalizacin del modelo IaaS permite la seleccin de la versin especfica del sistema operativo. Al igual que todas las configuraciones posteriores, esta personalizacin es dependiente de la seleccin previa que haya efectuado el usuario. Con el fin de ofrecer una gua de configuracin a lo largo del proceso, UnaCloud muestra todas las configuraciones efectuadas previamente, en el pie de pgina de la interface Web.

105

Figura 27. Personalizacin de la versin del sistema operativo.

Una vez se ha elegido la versin del sistema operativo, UnaCloud permite la seleccin del conjunto de aplicaciones a utilizar. Este conjunto es identificado mediante un nombre diciente de las aplicaciones que contiene. Como se ilustra en Figura 29, UnaCloud proporciona una interface para consultar el listado de aplicaciones que componen un conjunto.

Figura 28. Personalizacin del conjunto de aplicaciones.

Figura 29. Consulta del listado de aplicaciones.

106

Como se ilustra en la Figura 30, la siguiente personalizacin es la seleccin del tamao (en Gigabytes) del disco duro de la mquina virtual a ejecutar. Este tamao est limitado a 1 y 2 Terabytes para los hypervisors VMware Workstation 6.5 y 7, respectivamente.

Figura 30. Personalizacin del tamao del disco duro.

Como se aprecia en la Figura 31, la siguiente personalizacin es el nmero de ncleos de procesamiento de la mquina virtual. Este nmero est limitado a 2 y 10 ncleos para los hypervisors VMware Workstation 6.5 y 7, respectivamente.

Figura 31. Personalizacin del nmero de ncleos de procesamiento.

En la Figura 32 se ilustra la personalizacin del tamao de la memoria RAM de la mquina virtual. Este tamao est limitado a 8 y 32 Gigabytes para los hypervisors VMware Workstation 6.5 y 7, respectivamente. Finalmente en la Figura 33 se ilustra la ltima etapa de personalizacin del modelo IaaS. Esta consiste en la seleccin del nmero de instancias de mquinas virtuales a ejecutar y el tiempo total de ejecucin. Para el caso de usuarios IaaS que desean evitar el proceso de personalizacin completo, se provee una interface que les permite seleccionar 107

nicamente el nombre de una imagen, el nmero de instancias a ejecutar y el tiempo de ejecucin. Esta interface se asemeja a la ilustrada en la Figura 33.

Figura 32. Personalizacin del tamao de la memoria RAM.

Figura 33. Personalizacin del nmero de instancias y el tiempo de ejecucin.

Usuarios Grid: todos los usuarios Grid (incluyendo administradores y usuarios IaaS-Grid que asuman el rol Grid) pueden hacer uso del servicio de personalizacin del modelo IaaS con localizacin de ejecuciones sobre la infraestructura fsica de soporte. Como se ilustra en la Figura 34, UnaCloud proporciona una interface Web para la personalizacin del modelo IaaS a travs de la seleccin de siete configuraciones: tipo de sistema operativo, versin del sistema operativo, nombre del CVC, tamao del disco duro, nmero de ncleos de procesamiento, tamao de la memoria RAM y tiempo de ejecucin total. En forma adicional, UnaCloud despliega un mapa de la infraestructura fsica de soporte, en el cual un usuario Grid puede seleccionar una o varias mquinas para el despliegue localizado de su modelo IaaS. Para el caso de usuarios Grid que 108

desean evitar el proceso de personalizacin completo, se provee una interface que les permite seleccionar nicamente el nombre del CVC, el nmero de instancias a ejecutar, el tiempo de ejecucin y la localizacin del despliegue. Esta interface se asemeja a la ilustrada en la Figura 34.

Figura 34. Personalizacin del modelo IaaS con localizacin de ejecuciones.

7.3.4. Proceso de despliegue del modelo IaaS Una vez se ha finalizado el proceso de personalizacin del modelo IaaS, UnaCloud ejecuta automticamente las operaciones incluidas en la Tabla 21 y el modelo de procesos descrito en el numeral 6.3.2, para efectuar el despliegue del modelo IaaS. Como se puede apreciar en la Figura 35, UnaCloud provee un servicio de administracin del modelo IaaS, el cual incluye la presentacin Web de una consola de administracin de las mquinas virtuales desplegadas. Como parte del proceso de despliegue del modelo IaaS, esta consola proporciona los datos asociados al esquema de seguridad para el acceso remoto a las mquinas virtuales. Estos datos incluyen el nombre de la mquina virtual, el nombre y puerto del mecanismo de acceso remoto, la direccin IP de la mquina virtual, el nombre de usuario y la clave del administrador del sistema operativo hospedado en la mquina virtual. Todos los datos que se incluyen en las columnas pueden ser ordenados alfabtica o numricamente en forma ascendente o descendente, consultados y agrupados por palabras clave o ser ocultados. Estos datos son 109

suficientes para que un usuario de UnaCloud pueda acceder remotamente al modelo IaaS que ha personalizado y desplegado.

Figura 35. Consola de administracin del despliegue del modelo IaaS.

7.3.5. Proceso de administracin del modelo IaaS Este proceso incluye el conjunto de operaciones descritas en numeral 6.3.3. Como se ilustra en la Figura 35, el servicio de administracin de las mquinas virtuales provee un men para efectuar las operaciones de apagado, reinicio, monitoreo y cambio del tiempo de ejecucin. Las operaciones de apagado y reinicio ocurren en forma inmediata a su solicitud y no requieren de interfaces adicionales. Como se ilustra en la Figura 36, la operacin de monitoreo de mquinas virtuales despliega un nuevo men que incluye datos bsicos de su configuracin y estado.

Figura 36. Monitoreo del modelo IaaS.

Por otra parte, La operacin de cambio del tiempo de ejecucin despliega el men ilustrado en la Figura 37, el cual incluye informacin del tiempo de ejecucin de la 110

mquina virtual, el tiempo configurado para su apagado automtico, el tiempo de vida restante y un men que permite la extensin o abreviacin del tiempo originalmente configurado para la mquina virtual.

Figura 37. Administracin del tiempo de ejecucin del modelo IaaS.

7.3.6. Procedimiento de consulta de la trazabilidad del modelo IaaS La consulta de la trazabilidad del modelo IaaS, es un procedimiento efectuado por los usuarios administradores. Como se ilustra Figura 38, UnaCloud provee un servicio bsico de reportes de uso del modelo IaaS discriminados por usuario. Los datos incluidos en este reporte son aquellos descritos en la Tabla 15.

Figura 38. Reporte de la trazabilidad de uso del modelo IaaS.

111

7.3.7. Procedimiento de administracin de los laboratorios La administracin de los laboratorios que conforman la infraestructura fsica que utiliza UnaCloud para el soporte oportunista del modelo IaaS, es un procedimiento efectuado por los usuarios administradores. En UnaCloud los laboratorios son tratados como unidades de agregacin lgicas y fsicas. Los laboratorios fsicos agrupan mquinas fsicas que pertenecen a laboratorios del mundo real y que por lo tanto, poseen variables que permiten su localizacin exacta. Los laboratorios virtuales agrupan mquinas fsicas que no pertenecen a laboratorios reales y que por lo tanto, no poseen variables de localizacin que puedan ser usadas como referencia. Como se ilustra Figura 39, UnaCloud provee un servicio que facilita la creacin, edicin, bsqueda (por nombre o tipo) y eliminacin de los registros asociados a los laboratorios que conforman la infraestructura de soporte.

Figura 39. Administracin de los laboratorios que soportan a UnaCloud.

. 7.3.8. Procedimiento de administracin de las mquinas fsicas La administracin de las mquinas fsicas que conforman los laboratorios usados para el soporte de UnaCloud, es un procedimiento efectuado por los usuarios administradores. Como se ilustra Figura 40, UnaCloud provee un servicio que facilita la creacin, edicin, bsqueda (por nombre o tipo) y eliminacin de los registros asociados a las mquinas fsicas que conforman la infraestructura de soporte.

112

Figura 40. Administracin de las mquinas fsicas que soportan a UnaCloud.

7.3.9. Proceso de administracin de la infraestructura base Este proceso incluye el conjunto de operaciones descritas en numeral 6.3.4. Como se ilustra en la Figura 41, UnaCloud proporciona un servicio para la administracin de la infraestructura fsica, a travs de un men para efectuar las operaciones de apagado, reinicio, cierre de sesin, bloqueo y desbloqueo. Estas operaciones se efectan sobre las mquinas desplegadas en el mapa de la infraestructura fsica de soporte y estn restringidas a las polticas que el dominio administrativo otorgue a UnaCloud con el fin de aumentar la granularidad del esquema de seguridad del sistema.

Figura 41. Administracin de la infraestructura fsica que soporta a UnaCloud.

113

Adicionalmente UnaCloud proporciona un servicio para el monitoreo de la infraestructura fsica. Como se ilustra en la Figura 42, la interface Web de UnaCloud incluye variables del estado actual del procesador, memoria, disco duro, red y sistema operativo.

Figura 42. Monitorizacin de la infraestructura fsica que soporta a UnaCloud.

7.3.10.

Procedimientos adicionales

La administracin de la informacin de los hypervisors, esquemas de seguridad para acceso remoto a las mquinas virtuales, sistemas operativos, aplicaciones y mquinas virtuales se hacen a travs de servicios que UnaCloud provee para facilitar la creacin, edicin, bsqueda y eliminacin de los registros asociados. Un ejemplo de las interfaces Web provistas por estos servicios se puede apreciar en la Figura 43. 114

Figura 43. Administracin de las mquinas virtuales.

7.4. PRUEBAS Y RESULTADOS DE UNACLOUD Las estrategias de virtualizacin y oportunista (referirse a los numerales 5.1.1 y 5.1.2) fueron probadas exhaustivamente para medir el impacto que la ejecucin de una mquina virtual como un proceso en background de prioridad baja, tiene sobre el desempeo percibido por el usuario del recurso computacional compartido. Tambin se probaron los tiempos de respuesta con el fin de promediar el tiempo requerido para llevar a cabo la ejecucin de los principales servicios de UnaCloud. Finalmente y para validar el cumplimiento de los objetivos del presente trabajo de investigacin (referirse a los numerales 1.2 y 1.3) y de los requerimientos funcionales y no funcionales estipulados en la estrategia de solucin (referirse al numeral 5.2) se efectuaron pruebas en casos de uso cloud y grid computing. 7.4.1. Caractersticas de la infraestructura de despliegue Las pruebas descritas en esta seccin fueron elaboradas a travs del despliegue de UnaCloud Client en las mquinas fsicas pertenecientes a los tres laboratorios de informtica del Departamento de Ingeniera de Sistemas y Computacin de la Universidad de los Andes: Waira 1, Waira 2 y Alan Turing, con un total de 105 computadores de escritorio. Adicionalmente, el componente UnaCloud Server fue desplegado en una mquina virtual ejecutada en el servidor del grupo de investigacin en Comunicaciones y Tecnologas de Informacin (Comit), el cual se 115

encuentra ubicado en el centro de datos del Departamento de Ingeniera de Sistemas y Computacin. Las caractersticas de la infraestructura de despliegue se muestran en la Tabla 26. Cabe destacar que parte de esta infraestructura ser reemplazada prximamente por computadores de escritorio con procesadores de cuatro ncleos de procesamiento, memoria de 8GB y discos duros de 350GB. Conforme la infraestructura fsica crezca en capacidades computacionales, las mismas podrn ser utilizadas por parte de UnaCloud para otorgar una mayor eficiencia al modelo IaaS, disminuyendo el desperdicio de recursos computacionales ociosos. Tabla 26. Caractersticas de la infraestructura de despliegue CARACTERSTICAS DE LAS MQUINAS FSICAS UTILIZADAS PARA EL DESPLIEGUE DE UNACLOUD CLIENT Hewlett-Packard Fabricante dc7700 Convertible Minitower PC Modelo Intel Q965 Express chipset Tarjeta Madre
Intel Core 2 Duo E6300 Processor (1.86-GHz, 2 MB L2 cache, 1066-MHz FSB) 250-GB SATA 3.0-Gb/s Hard Drive (8MB Cache, Disco duro 7200 rpm) 4-GB DDR2 Synch Dram PC2-5300 (667-MHz) Memoria RAM Non ECC (4 x 1GB) Intel 82566DM Gigabit Network Connection Tarjeta de red (integrated on system board) SATA DVD+/-RW (DL/DF) LightScribe Drive Unidades pticas Microsoft Windows XP Professional Service Pack Sistema Operativo 3 - 32 bits CARACTERSTICAS DE LA MQUINA VIRTUAL UTILIZADA PARA EL DESPLIEGUE DE UNACLOUD SERVER Intel Xeon E5520 @ 2.27Ghz (only one core) Procesador 30GB - VMware Virtual disk SCSI Device Disco duro 3GB Memoria RAM VMXNET3 Ethernet Adapter Gigabit Network Tarjeta de red Connection Windows 7 Professional - 32 bits Sistema Operativo

Procesador

Para la interconexin entre el centro de datos y los laboratorios se utiliz la infraestructura de comunicaciones ilustrada en la Figura 44. Como se puede apreciar en la misma, la infraestructura se basa en tres switches de conmutacin y un switch multicapa, interconectados a travs de enlaces Gigabit Ethernet. En forma adicional a los componentes de UnaCloud, se utilizaron componentes de experimentacin grid computing, incluyendo un CVC con su nodo maestro y sus nodos esclavos. 116

Data Center

Administrators

Remote Access Mechanism

IaaS users

UnaCloud Server GigE

Grid Masters

Grid users

Alan Turing

Waira I

Waira II CVC Slaves

IaaS virtual machines

Computer laboratories with UnaCloud Client

Figura 44. Infraestructura de despliegue de UnaCloud.

7.4.2. Pruebas para la validacin de las estrategias de virtualizacin y oportunista Para validar las estrategias de virtualizacin y oportunista se realizaron tres tipos de pruebas5. La primera prueba evalu el impacto a los usuarios de los recursos compartidos (usuarios de los recursos fsicos que albergan simultneamente la ejecucin de mquinas virtuales como procesos en background de prioridad baja) cuando estos ejecutan aplicaciones intensivas en procesamiento. Para ello se utiliz una aplicacin intensiva en CPU, en el ambiente de ejecucin del usuario del recurso compartido en tres escenarios distintos: sin la ejecucin de una mquina virtual, con la ejecucin de una mquina virtual con un ncleo asignado (haciendo uso intensivo de procesamiento) y con la ejecucin de una mquina virtual con dos ncleos de procesamiento asignados. Los resultados de la primera prueba se muestran en la Tabla 27. Estos resultados evidencian que la ejecucin de la mquina virtual de procesamiento (como proceso en background de prioridad baja) afecta en menos del 1% el rendimiento percibido por los usuarios de los recursos compartidos cuando stos ejecutan tareas intensivas en procesamiento.
5

Las pruebas descritas en el numeral 7.4.2 fueron realizadas con la colaboracin del ingeniero Mario Jos Villamizar Cano, integrante del equipo de trabajo de UnaGrid y han sido referenciadas en los artculos de investigacin (165) y (174).

117

Tabla 27. Impacto de las tareas intensivas en procesamiento


Tiempo de ejecucin de la tarea (segundos) Prueba 1 Prueba 2 Prueba 3 Prueba 4 53,94 54,16 54,21 81,01 81,42 81,46 108,05 108,39 108,58 134,99 135,58 135,60

Prueba Escenario Sin mquina virtual Una mquina virtual con un ncleo asignado Una mquina virtual con dos ncleos asignados

La segunda prueba evalu el impacto a los usuarios de los recursos compartidos cuando estos ejecutan aplicaciones intensivas en entrada y salida. Para ello se efectuaron operaciones de compresin de archivos de diferentes tamaos en el ambiente de ejecucin del usuario. Esta prueba se ejecut utilizando los mismos escenarios de la primera prueba, obteniendo los resultados mostrados en la Tabla 28. Los resultados evidencian un impacto menor al 3% en el rendimiento percibido por los usuarios de los recursos compartidos cuando stos ejecutan aplicaciones intensivas en almacenamiento. Tabla 28. Impacto de las tareas intensivas en entrada y salida (I/O)
Tiempo de ejecucin de la tarea (segundos) Prueba 1 Prueba 2 Prueba 3 Prueba 4 200MB 500MB 1GB 2GB 104,10 259,85 521,16 1041,42 105,66 106,02 262,43 263,03 526,63 527,06 1060,75 1063,07

Prueba Escenario Sin mquina virtual Una mquina virtual con un ncleo asignado Una mquina virtual con dos ncleos asignados

Los resultados de las dos pruebas anteriores se justifican en los mecanismos utilizados por los sistemas operativos para administrar la prioridad de los procesos a su cargo. Esta administracin otorga por defecto la mayor cantidad de recursos computacionales a los procesos que se ejecutan con mayor prioridad, disminuyendo dinmicamente los recursos computacionales asignados a los procesos con prioridad baja. Este hecho es corroborado en la tercera prueba. La tercera prueba monitoriz el uso simultneo del procesador por parte del usuario del recurso compartido y de la mquina virtual ejecutada como un proceso en background de prioridad baja. Para este escenario, la mquina virtual tiene asignados dos ncleos de procesamiento y se ejecutan tareas intensivas en procesamiento en ambos ambientes, es decir, en el ambiente del usuario del 118

recurso compartido y de la mquina virtual. Los resultados de esta prueba se ilustran en la Figura 45.

120,0 100,0 80,0 60,0 40,0 20,0 0,0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Virtual Machine Process User Process

Figura 45. Uso simultneo del procesador por parte del usuario y la mquina virtual.

Entre 1 y 2 el usuario hace uso exclusivo de la CPU de la mquina fsica, entre 3 y 4 se ejecuta una mquina virtual que usa un porcentaje aproximado al 50% de la CPU. Entre 5 y 6 la mquina virtual consume aproximadamente el 100% de la CPU. Entre 7 y 8 el usuario demanda un 50% de la CPU y la mquina virtual disminuye automticamente (por accin del sistema operativo) su consumo a un 50%. Entre 9 y 10 el usuario incrementa el consumo de CPU a aproximadamente un 100% de la CPU y la mquina virtual disminuye automticamente su consumo al mnimo posible para su continuidad. Entre 11 y 12 el usuario disminuye el consumo de la CPU a aproximadamente un 50% y la mquina virtual retoma automticamente el 50% restante. Entre 13 y 14 no hay ningn usuario haciendo uso de la mquina fsica y la mquina virtual retoma el 100% de la CPU. Los resultados evidencian que la mquina virtual nicamente consume los ciclos de procesamiento no utilizados por el usuario del recurso compartido, o la totalidad de los mismos en el caso de un recurso totalmente disponible (no utilizado momentneamente por un usuario o de naturaleza dedicada) garantizando un impacto despreciable en el rendimiento percibido por los usuarios finales. Con base en los resultados obtenidos en las pruebas, se concluye que las estrategias de virtualizacin y oportunista incorporadas en UnaCloud, representan una solucin no intrusiva para la construccin de infraestructuras virtuales, incentivando el aprovechamiento de recursos computacionales ociosos y brindando una solucin eficiente a la problemtica de subutilizacin de recursos preexistentes y no dedicados. Es importante destacar que el uso de procesos en prioridad baja se basa en las estrategias utilizadas por los proyectos GIMPS, 119

SETI@home y [Link] analizados en los Anexos A3, A4 y A5, respectivamente. Finalmente y teniendo como base los resultados de las pruebas anteriores, se hizo una validacin a UnaCloud en trminos del conjunto de aspectos de diseo e implementacin que fueron identificados en el numeral 3.3 como parte del anlisis a las implementaciones del paradigma de la computacin oportunista. La Tabla 29 muestra los resultados de la validacin. Tabla 29. Validacin de UnaCloud contra las caractersticas de la computacin oportunista
CARACTERSTICA OPORTUNISTA IMPLEMENTACIN EN UNACLOUD Estrategia oportunista basada en la ejecucin de mquinas virtuales como procesos en background de prioridad baja. Compatibilidad con infraestructuras computacionales dedicadas. Facilidad para la agregacin de recursos computacionales dedicados a travs de la instalacin de un agente liviano. Ejecucin paralela y no intrusiva a los procesos del usuario del recurso compartido mediante el uso de las estrategias de virtualizacin y oportunista. Desarrollo de un agente liviano capaz de invocar al sistema operativo local y al hypervisor tipo II para el despliegue de un modelo IaaS. Desarrollo de un agente liviano desarrollado en el lenguaje de programacin Java para maximizar el grado de independencia con respecto a la plataforma de ejecucin. Compatibilidad con los sistemas operativos Windows, Linux y Mac. Desarrollo de un agente cuyo proceso de instalacin se reduce a la copia de un archivo empaquetado .jar y la configuracin de su ejecucin al inicio del sistema operativo. Desarrollo de un agente capaz de monitorizar el estado actual del procesador, memoria, disco duro, red y sistema operativo. Provisin de mecanismos para facilitar la administracin de la infraestructura fsica, incluyendo operaciones de apagado, reinicio, cierre de sesin, bloqueo, desbloqueo y monitoreo. VALIDACIN

Control de impacto a los usuarios de los recursos compartidos Aprovechamiento de recursos dedicados

Ejecucin permanente Uso de agentes/clientes ligeros

Portabilidad

Facilidad de instalacin Herramientas de monitoreo Herramientas de administracin

120

7.4.3. Pruebas de tiempos de respuesta de UnaCloud Con el fin de promediar el tiempo requerido para la ejecucin de los principales servicios provistos por UnaCloud, se realizaron 16 tipos de pruebas. Los servicios incluidos en las pruebas corresponden a las operaciones posibles sobre las mquinas virtuales que componen el modelo IaaS (ejecucin, apagado, reinicio y monitoreo) y sobre la infraestructura fsica de soporte (apagado, reinicio, cierre de sesin y monitoreo). Todos las operaciones seleccionadas requieren de un paso de mensajes entre UnaCloud Server y UnaCloud Client, tal y como se describi en el numeral 6.4. Adicionalmente y con la finalidad de promediar el costo en el desempeo debido a la implementacin de los mecanismos de seguridad descritos en el numeral 6.4.1, se usaron dos escenarios generales de pruebas: uno sin mecanismos de seguridad en las comunicaciones y otro incorporando los mismos. Los dos escenarios incluyeron los laboratorios Waira 1, Waira 2 y Alan Turing. La Tabla 30 muestra los resultados obtenidos. Tabla 30. Prueba de tiempos de respuesta de UnaCloud
Tiempo aproximado de ejecucin de la operacin para una mquina (segundos) Operacin
Mquinas Virtuales Encendido Apagado Reinicio Monitoreo Mquinas Fsicas Apagado Reinicio Cierre de sesin Monitoreo

Prueba

Sin mecanismos de seguridad


0,16 0,15 0,14 0,17 0,16 0,14 0,15 1

Con mecanismos de seguridad


0,21 0,2 0,19 0,23 0,21 0,2 0,21 2

Las diferencias entre el paso de mensajes sin mecanismos de seguridad y aquel que los incorpora, tiene un costo promedio del 43%. Este costo no es significativo al tener en cuenta que la operacin que requiere un mayor tiempo para su ejecucin es el monitoreo de mquinas fsicas con un tiempo promedio de respuesta de 2 segundos. Todos los resultados se obtuvieron a travs de un intervalo de medicin estndar, este mismo inicia al ejecutar la operacin haciendo uso de la interface Web de UnaCloud Server y finaliza cuando UnaCloud Client invoca al sistema operativo y/o hypervisor para delegarle su ejecucin. Por lo tanto este intervalo incluye el tiempo que UnaCloud Server toma para ordenar los parmetros configurados por el usuario, empaquetar los mismos en un mensaje, el paso de mensajes entre UnaCloud Server y UnaCloud Client y el tiempo que 121

UnaCloud Client toma para recibir, desempaquetar, validar e invocar al sistema operativo y/o hypervisor local. Por lo tanto, es importante aclarar que los tiempos medidos en las pruebas no incluyen el tiempo que el sistema operativo y/o hypervisor toman para finalizar la operacin. Esto se debe a que el tiempo requerido para llevar a cabo las operaciones, es dependiente de las configuraciones particulares de cada sistema operativo y los recursos de hardware disponibles, tanto en el caso de la infraestructura fsica como en la virtual. Con base en los resultados obtenidos en las pruebas se concluye que en promedio, todas las operaciones de UnaCloud se efectan en tiempos de respuesta eficientes, facilitando por ejemplo que la ejecucin segura de un CVC de 105 mquinas virtuales ocurra aproximadamente en 23 segundos. Sin embargo y como se especifica en el numeral 5.2.2, esto no implica que exista algn tipo de garanta sobre los tiempos de respuesta, dada la naturaleza oportunista de la infraestructura de soporte. 7.4.4. Pruebas en el contexto grid computing En el marco de los objetivos de este trabajo de investigacin se plantea una contribucin al proyecto Campus Grid Uniandes y su sub proyecto UnaGrid. Esta contribucin se resume en la extensin y mejoramiento de las funcionalidades actuales a travs de aportes basados en el estudio e integracin de las caractersticas, oportunidades y ventajas del paradigma cloud computing, particularmente del modelo IaaS implementado a travs de UnaCloud. Para validar estos aportes se efectuaron pruebas mediante un caso de uso para usuarios Grid. Este caso de uso utiliz el CVC de bioinformtica desplegado para el soporte computacional a mltiples proyectos de investigacin del Departamento de Ciencias Bilgicas de la Universidad de los Andes, el cual ha venido trabajando con el Departamento de Ingeniera de Sistemas y Computacin para el desarrollo de proyectos que buscan analizar la genmica del caf, la yuca y la papa para el mejoramiento de las producciones afectadas por organismos biolgicos (177), (178), (179). Las caractersticas de las mquinas virtuales del CVC de bioinformtica se resumen en la Tabla 31. El despliegue del CVC fue efectuado sobre la totalidad del laboratorio Waira II, para un total de 35 mquinas fsicas y virtuales. El hypervisor tipo II utilizado para el despliegue fue VMware Workstation en su versin 6.5. Todo el CVC tiene una configuracin de direcciones IP pblicas incluidas en el rango [Link] a [Link] y adicionalmente, tiene configurado el mecanismo de acceso remoto SSH, restringido para su uso por parte del usuario administrador del CVC.

122

Tabla 31. Caractersticas del CVC de bioinformtica


CARACTERSTICAS DE UNA MQUINA VIRTUAL DEL CVC DE BIOINFORMTICA Procesador 2 CPU cores Disco duro 10GB - VMware Virtual disk SCSI Device Memoria RAM 1GB VMXNET3 Ethernet Adapter Gigabit Network Tarjeta de red Connection Sistema Operativo Linux Debian 4 release 8 32 bits Java SE JDK 1.6, SGE 6, GCC 4.4.1, HMMER 3, Aplicaciones BLAST (Basic Local Alignment Search Tool) 2.2 y VMware Tools 6.

La prueba efectuada a travs de UnaCloud tuvo como resultado el despliegue de las 35 mquinas virtuales en aproximadamente 7 segundos. El tiempo promedio que cada mquina virtual tom en paralelo para la carga de su sistema operativo y habilitacin de sus servicios de red (para ser accedida mediante SSH) fue de aproximadamente 3 minutos, tiempo en el cual un CVC est listo para recibir la orden de ejecucin de trabajos desde el maestro SGE ubicado en el centro de datos (referirse a la Figura 44). En forma adicional se valid el cumplimiento de las contribuciones efectuadas por UnaCloud al proyecto Campus Grid Uniandes teniendo en cuenta las falencias de UnaGrid determinadas y evaluadas en numeral 4.2. La Tabla 32 resume los resultados de esta validacin. Los resultados evidencian que UnaCloud es una solucin oportunista que supera las problemticas asociadas al aprovechamiento de recursos computacionales preexistentes, caracterizados por su distribucin, alta heterogeneidad, independencia de dominio administrativo y disponibilidad variante. Adicionalmente se puede concluir que UnaCloud representa un mejoramiento al proyecto Campus Grid Uniandes en trminos de las falencias detectadas en UnaGrid, a travs de la incorporacin de caractersticas, conceptos y ventajas del paradigma cloud computing. Tabla 32. Principales contribuciones al proyecto Campus Grid Uniandes FALENCIA DE UNAGRID Usabilidad CONTRIBUCIN DE UNACLOUD
Interface de usuario de alta usabilidad basada en un portal Web de acceso universitario. Portal Web accesible desde Intranet e Internet, no dependiente de sistemas operativos, frameworks, middlewares o planificadores disponibles en los CVCs.

VALIDACIN

Acceso a travs de red

123

Personalizacin de servicios bajo demanda

Escalabilidad

Interoperabilidad y bajo acoplamiento Extensibilidad

Administracin delegada Extensin en el aprovechamiento de tecnologas de virtualizacin Seguridad Modelo de trazabilidad

Servicio de personalizacin del modelo IaaS bajo demanda, caracterstica no disponible aun en ninguna implementacin de la computacin oportunista. Modelo de abastecimiento y crecimiento horizontal escalable en independencia de los dominios administrativos involucrados. Esto implica que el aprovechamiento de los recursos computacionales ociosos puede extenderse a un cloud privado conformado por todos los recursos computacionales de la Universidad de los Andes. Reduccin del acoplamiento de la arquitectura para operar en modelos de despliegue cloud computing. Uso de tecnologas abiertas de alta interoperabilidad. Desarrollo basado en tecnologas estandarizadas, de amplia divulgacin y patrones de diseo de ltima generacin. Ocultamiento de la infraestructura base a los usuarios finales y provisin de servicios para facilitar las labores de los usuarios administradores. Extensin de la compatibilidad con el hypervisor VMware Workstation 7. Despliegue de CVCs bajo demanda en independencia de las tareas programadas del sistema operativo Windows. Incorporacin de mecanismos de autenticacin y autorizacin, confidencialidad y no repudio para el despliegue de los CVC. Mecanismos para llevar trazabilidad de los CVCs a nivel de usuario.

7.4.5. Pruebas en el contexto cloud computing Uno de los objetivos del presente trabajo de investigacin plantea el desarrollo de un prototipo capaz de desplegar, administrar y entregar una plataforma de experimentacin del modelo IaaS. Para validar esta capacidad se efectuaron pruebas mediante casos de uso acordes a los usuarios IaaS. Estos casos utilizaron mquinas virtuales de propsito acadmico, particularmente aquellas que soportan actividades de desarrollo de software y minera y bodegas de datos. Las caractersticas de las mquinas virtuales fabricadas para la prueba se resumen en la Tabla 33. El despliegue de las mismas fue efectuado sobre la totalidad del laboratorio Waira, para un total de 70 mquinas fsicas y virtuales. El hypervisor utilizado para el despliegue fue VMware Workstation en su versin 6.5. Todas las mquinas virtuales fueron configuradas con direcciones IP pblicas incluidas en el rango [Link] a [Link]. Adicionalmente se 124

configur escritorio remoto en todas las mquinas virtuales de tal forma que su uso estuviese restringido al usuario administrador. Tabla 33. Caractersticas de las mquinas virtuales de prueba
CARACTERSTICAS DE LA MQUINA VIRTUAL DE DESARROLLO DE SOFTWARE Procesador 1 CPU core Disco duro 20GB - VMware Virtual disk SCSI Device Memoria RAM 1,5 GB VMXNET3 Ethernet Adapter Gigabit Network Tarjeta de red Connection Microsoft Windows XP Professional Service Pack Sistema Operativo 3 - 32 bits Java SE JDK 1.6, Eclipse Galileo, Netbeans IDE Aplicaciones 6, Enterprise Architect 7.5, 7-zip 4.65, Adobe Reader 9, Mozilla Firefox 3.5 y VMware Tools 6. CARACTERSTICAS DE LA MQUINA VIRTUAL DE MINERA Y BODEGAS DE DATOS Procesador 2 CPU cores Disco duro 20GB - VMware Virtual disk SCSI Device Memoria RAM 2 GB VMXNET3 Ethernet Adapter Gigabit Network Tarjeta de red Connection Microsoft Windows XP Professional Service Pack Sistema Operativo 3 - 32 bits IBM DB2 9.5, Intelligent Miner 8.1, Internet Aplicaciones Information Services 6.5 y VMware Tools 6.

La prueba tuvo como resultado el despliegue de las 70 mquinas virtuales en aproximadamente 13 segundos. El tiempo promedio que cada mquina virtual tom en paralelo para la carga de su sistema operativo y habilitacin de sus servicios de red (para ser accedida mediante escritorio remoto) fue de aproximadamente 3 y 4 minutos para la mquina virtual de desarrollo de software y minera y bodegas de datos, respectivamente. En forma adicional se valid el cumplimiento de las funcionalidades provistas por UnaCloud en trminos de sus caractersticas cloud computing. La Tabla 34 resume los resultados de esta validacin.

125

Tabla 34. Validacin de UnaCloud contra las caractersticas generales de cloud computing CARACTERSTICA CLOUD COMPUTING Usabilidad Modelo de autoservicio IMPLEMENTACIN EN UNACLOUD
Interfaces Web de alta usabilidad y operacin casi intuitiva. Interfaces Web que exponen servicios consumibles sin la necesidad de procesos de negociacin. Interfaces Web accesibles desde Intranet e Internet. Provisin al usuario de datos para el acceso al modelo IaaS mediante mecanismos de acceso remoto estndares y seguros. Servicios de personalizacin del modelo IaaS incluyendo configuraciones de sistema operativo, conjunto de aplicaciones, hardware, nmero de instancias y tiempo de ejecucin. Agente ligero capaz de ejecutar mquinas virtuales como procesos paralelos, no intrusivos a los procesos ejecutados en el ambiente del usuario del recurso compartido. Despliegue bajo demanda de infraestructuras virtuales, asignadas en forma eficiente y dinmica. Modelo de crecimiento y abastecimiento horizontal, escalable en el modelo de despliegue de cloud privado. Mecanismos de comunicaciones escalables, eficientes y seguros, capaces de articular ejecuciones remotas y seguras en independencia de los dominios administrativos involucrados. Mecanismos capaces de operar en ambientes distribuidos, voltiles y de alta heterogeneidad. Uso de tecnologas abiertas, de alta interoperabilidad y bajo acoplamiento, sin limitaciones para la experimentacin cloud computing. Desarrollo basado en el lenguaje de programacin Java (SE y EE). Desarrollo y documentacin del cdigo en idioma ingls. Ocultamiento de la infraestructura base a usuarios finales y provisin de servicios para facilitar la administracin, incluyendo servicios de monitorizacin de la infraestructura fsica.

VALIDACIN

Acceso a travs de red

Personalizacin de servicios bajo demanda

Modelo multiusuario

Virtualizacin

Escalabilidad

Interoperabilidad y bajo acoplamiento

Extensibilidad

Administracin delegada

126

Acuerdos de nivel de servicio y calidad de servicio Seguridad

Ningn mecanismo implementado, dada la naturaleza voltil de la infraestructura oportunista de soporte. Mecanismos de autenticacin y autorizacin para el acceso y consumo de los servicios cloud. Mecanismos de confidencialidad y no repudio para el paso de mensajes requerido en las comunicaciones entre componentes. Mecanismos para monitorizar el uso del modelo IaaS, permitiendo llevar trazabilidad de uso a nivel de usuario (auditora).

Modelo de trazabilidad

Los resultados de estas pruebas evidencian que UnaCloud provisiona una plataforma de experimentacin multipropsito del modelo IaaS. Esta plataforma es capaz de desplegar ambientes personalizados de ejecucin bajo demanda, cuya versatilidad implcita, facilita su adaptacin dinmica a las necesidades emergentes no solo en el desarrollo de la e-Ciencia, sino tambin en el soporte o mejoramiento de mltiples actividades que utilicen un soporte computacional para su desarrollo. Como se aprecia en la validacin efectuada en la Tabla 34, UnaCloud no proporciona ningn tipo de acuerdo de nivel de servicio o calidad de servicio. Como se explic en los captulos 5 y 6, UnaCloud opera sobre una infraestructura oportunista que por definicin no puede ofrecer ningn tipo de calidad de servicio. Esto se debe a que una infraestructura oportunista vara en su disponibilidad y puede considerarse voltil al estar expuesta a eventos provocados por los usuarios de los recursos fsicos, incluyendo su apagado, reinicio, desconexin elctrica o de red, fallas a nivel del sistema operativo principal, fallas de aplicaciones que comprometan la estabilidad del sistema operativo principal o el hypervisor, etc. Aunque son factibles esfuerzos de investigacin para tratar esta problemtica, estos mismos no se encuentran en el alcance inicial de este trabajo de investigacin. En forma adicional se evidencia que UnaCloud plantea e implementa una novedosa arquitectura de un modelo IaaS soportado en infraestructuras computacionales oportunistas. En contraposicin a la evaluacin efectuada a las implementaciones del modelo IaaS (referirse al numeral 4.1), UnaCloud incorpora mecanismos de control de impacto a los usuarios de los recursos compartidos, su instalacin no est limitada a distribuciones especificas, no requiere de nodos de provisin de recursos dedicados, no requiere de sistemas de almacenamiento especializados, configuraciones especiales en la infraestructura de red y su instalacin est disponible para la experimentacin con el modelo IaaS, debido a que la implementacin fue totalmente desarrollada con tecnologas de licencia abierta, extensibles y de alta interoperabilidad.

127

8. CONCLUSIONES Y TRABAJO FUTURO El desarrollo del trabajo de investigacin presentado en este documento permiti elaborar las siguientes conclusiones: UnaCloud representa una convergencia entre los paradigmas cloud computing y la computacin oportunista. El primero de ellos analizado como una finalidad, particularmente en lo relacionado al modelo IaaS. El segundo analizado como un medio, particularmente en lo relacionado a estrategias oportunistas para el abastecimiento de infraestructuras computacionales. Para lograr esta convergencia, el presente trabajo de investigacin valid y extendi el paradigma de la computacin oportunista al identificar, evaluar y utilizar sus principales estrategias, caractersticas y aspectos de diseo e implementacin para implementar un modelo IaaS de cloud computing, mayoritariamente soportado en infraestructuras oportunistas de crecimiento horizontal. Los resultados obtenidos no solo demuestran la viabilidad de la convergencia sino que representan un referente para el desarrollo de experimentacin cloud computing abierta, extensible, interoperable, eficiente, escalable y a bajo costo. UnaCloud es una implementacin a medida del modelo IaaS, cuyo diseo supera las problemticas asociadas al aprovechamiento de recursos computacionales preexistentes, prevalentemente econmicos, caracterizados por su distribucin, alta heterogeneidad, independencia de dominio administrativo y disponibilidad variante. Para superar estas problemticas se defini e implement una arquitectura de alto y bajo nivel, basada en componentes y servicios desacoplados, capaces de administrar una infraestructura computacional oportunista desde un sistema de informacin basado en tecnologas Web. Esta arquitectura, en contraposicin a todas las implementaciones del modelo IaaS revisadas, es capaz de operar en la coexistencia de infraestructuras oportunistas y dedicadas, brindando la mayora de funcionalidades y caractersticas deseables de un modelo IaaS de cloud computing. UnaCloud despliega, administra y entrega una plataforma de experimentacin multipropsito del modelo IaaS, totalmente extensible a otros modelos de servicio cloud computing como PaaS y SaaS. Esta plataforma es capaz de desplegar ambientes personalizados de ejecucin bajo demanda, cuya versatilidad implcita, facilita su adaptacin dinmica a las necesidades emergentes no solo en el desarrollo de la e-Ciencia, sino tambin en el soporte o mejoramiento de actividades de naturaleza acadmica o incluso comercial. Los resultados obtenidos demuestran que el modelo IaaS supone una solucin eficiente a las problemticas de subutilizacin de recursos preexistentes y no 128

dedicados, otorga ubicuidad y usabilidad para el acceso y operacin de servicios computacionales fundamentales, facilita la ejecucin de aplicaciones emulando sus ambientes nativos y disminuye el tiempo requerido para la obtencin de resultados en dependencia de la provisin de infraestructuras computacionales. En el contexto del proyecto Campus Grid Uniandes, UnaCloud representa una extensin y mejoramiento a las principales falencias del sub proyecto UnaGrid. Estas incluyen aspectos relacionados con su usabilidad, personalizacin de servicios bajo demanda, escalabilidad, seguridad, extensin en el aprovechamiento de tecnologas de virtualizacin, extensibilidad, interoperabilidad y bajo acoplamiento, mecanismos de acceso a travs de red, trazabilidad de uso de recursos y administracin delegada. Los resultados obtenidos suponen un adelanto significativo para superar los logros de investigacin y desarrollo en e-Ciencia hasta ahora alcanzados mediante los paradigmas cluster y grid computing en la Universidad de los Andes.

Para guiar la continuidad del presente trabajo de investigacin se propone el siguiente trabajo futuro: El proceso de implementacin de un ambiente cloud computing es complejo y extenso. Este trabajo de investigacin inici una estrategia incremental para la implementacin de todos los modelos de servicio cloud computing (IaaS, PaaS y SaaS), enfocndose en el modelo IaaS. Por lo tanto, se hace necesaria una extensin a este trabajo para implementar los modelos de servicio cloud computing restantes. En forma adicional, este trabajo de investigacin inici con un modelo de despliegue de cloud privado. Es necesaria una investigacin exhaustiva para implementar los modelos de despliegue de cloud pblico, comunitario e hbrido. El modelo IaaS implementado a travs de UnaCloud no incluye mecanismos de interoperabilidad con otras implementaciones del modelo IaaS comerciales o acadmicas. Por lo tanto, se requiere de una investigacin exhaustiva de los APIs e interfaces expuestas por soluciones como Amazon EC2 y Amazon S3, Eucalyptus, Open Nebula, etc. No nicamente para otorgar un mayor grado de versatilidad a la experimentacin cloud computing, sino tambin para reutilizar herramientas, servicios, mdulos y componentes que puedan extender las funcionales y el alcance oportunista de UnaCloud. En este trabajo de investigacin se implement la personalizacin de las configuraciones asociadas al tipo y versin del sistema operativo, conjunto de aplicaciones, tamaos de la memoria RAM y disco duro, nmero de ncleos de 129

procesamiento, nmero de instancias, localizacin del despliegue y tiempo de ejecucin del mismo. Se requiere investigacin orientada a la personalizacin bajo demanda de la configuracin de la infraestructura de red que interconecta un determinado despliegue del modelo IaaS. UnaCloud implementa un modelo de servicio que no involucra almacenamiento adicional al suministrado por las mquinas virtuales que conforman el modelo IaaS. Por lo tanto, es deseable investigacin exhaustiva orientada a implementar servicios de almacenamiento persistente, desacoplados de la ejecucin del modelo IaaS. Estos mismos puede basarse en los conceptos de investigacin desarrollados en Amazon S3 y Amazon EBS. UnaCloud es compatible con el hypervisor VMware Workstation en sus versiones 6.5 y 7. Es precisa una investigacin exhaustiva para extender su compatibilidad con los hypervisors: Virtual Box, Hyper V, KVM, entre otros. Adicionalmente se requiere investigacin para garantizar su interoperabilidad con hypervisors tipo I, como es el caso de Xen y VMware ESX, primordialmente para operar mquinas virtuales que por su disponibilidad se ejecutan en infraestructuras dedicadas y a cargo de estos hypervisors. UnaCloud est limitado por las funcionalidades provistas por los hypervisors tipo II instalables en las arquitecturas x86 de la infraestructura de soporte. Por lo tanto, es deseable investigacin exhaustiva para evaluar la posibilidad de emular funcionalidades deseadas de los hypervisor tipo I. Quiz la funcin ms relevante en el contexto cloud computing sea la elasticidad para aumentar o disminuir recursos computacionales en tiempo real y conforme a la demanda. UnaCloud implementa un servicio de auditora que registra automticamente y permite la consulta de la trazabilidad de uso del modelo IaaS a nivel de usuario. Sin embargo, es necesaria investigacin orientada a la implementacin de reportes avanzados y estadsticos con base en dichos registros. Estos reportes deberan contemplar el soporte a un modelo de facturacin de pago por uso, discriminando el uso de recursos procesamiento, memoria, almacenamiento, red, energa elctrica, etc. UnaCloud implementa mecanismos bsicos de seguridad basados en procesos de autenticacin, autorizacin, confidencialidad y no repudio. Por lo tanto, se hace indispensable una investigacin exhaustiva para analizar, disear e implementar un modelo de seguridad robusto que contemple aspectos como el uso malintencionado de las infraestructuras fsicas y virtuales, incluyendo la instalacin de software ilegal, ataques de denegacin de servicio, escaneo de

130

puertos, pruebas de penetracin, depuracin, modificacin o inyeccin de cdigo, etc. UnaCloud no provee ningn tipo de acuerdo de nivel de servicio o calidad de servicio. Por lo tanto, se necesita investigacin exhaustiva, orientada a la implementacin de modelos predictivos que optimicen el aprovechamiento de la infraestructura oportunista para otorgar niveles probabilsticos de disponibilidad y calidad de servicio. Adicionalmente se hace ineludible investigacin exhaustiva para la implementacin de mecanismos de tolerancia y recuperacin ante fallas. Las pruebas efectuadas en este trabajo de investigacin son factibles de extensin a travs del montaje o aprovechamiento de escenarios que involucren situaciones que puedan afectar el desempeo del modelo IaaS. Esto puede incluir el uso exhaustivo de recursos computacionales por parte de los usuarios de los recursos compartidos, la ejecucin simultnea de mltiples mquinas virtuales intensivas en procesamiento, almacenamiento y red, cadas en el servicio, fallas a nivel del sistema operativo, hypervisor, etc. UnaCloud provee una interface de usuario de alta usabilidad, basada en un portal Web de acceso universitario. Para la automatizacin de procesos asociados a la personalizacin, despliegue y administracin del modelo IaaS y de la infraestructura fsica de soporte, es indispensable investigacin orientada a la implementacin de una interface de lnea de comandos, capaz de ejecutar scripts parametrizables, complejos y seguros. En este trabajo de investigacin se implementaron servicios para facilitar la administracin de la infraestructura fsica de soporte incluyendo las operaciones de apagado, reinicio, cierre de sesin, bloqueo, desbloqueo y monitorizacin. Sin embargo, es precisa investigacin orientada a la implementacin de mecanismos para facilitar las labores de administracin pertinentes al proceso inicial de despliegue de las mquinas virtuales. Para ello deben desarrollarse mecanismos eficientes de copiado y adaptacin de mquinas virtuales desde repositorios con capacidad para almacenar mltiples plantillas estandarizadas. Conforme a los objetivos del presente trabajo de investigacin, el estado de UnaCloud corresponde al de un prototipo. Por lo tanto, se hacen necesarios procesos de anlisis, diseo, desarrollo, pruebas y mantenimiento orientados a su correccin, mejoramiento y puesta en produccin final.

131

9. BIBLIOGRAFA
1. Foster, Ian y Kesselman, Carl. The Grid: Blueprint for a New Computing Infrastructure. s.l. : Morgan-Kaufman, 1999, 2. 2. Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Buyya, Rajkumar, y otros. 2009, Future Gener. Comput. Syst. [Link] 3. Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities. Buyya, Rajkumar, Chee Shin, Yeo y Venugopal, Srikumar. Melbourne, Australia : s.n., 2009. 2009 9th IEEE/ACM International Symposium on Cluster Computing and the Grid, CCGRID 2009. 4. Foster, I. y Kesselman, C. The Grid: blueprint for a new computing infrastructure. s.l. : Morgan Kaufmann, 1998. 5. Guest Editor's Introduction: Cloud Computing for the Sciences. Sullivan, Francis. [ed.] IEEE Computer Society. 4, 2009, Computing in Science and Engineering, Vol. 11, pgs. 10-11. [Link] 6. Lasica, Joseph Daniel. Identity in the Age of Cloud Computing: The next-generation Internets impact on business, governance and social interaction. [En lnea] septiembre de 2009. [Link] d_Computing.pdf. 7. da Palma Rosa, Pedro. Cloud Computing Basics. [En lnea] Dell, Inc. [Link] 8. Cloud Computing Issues, Research and Implementations. Vouk, Mladen A. Cavtat, Croatia : s.n., 2008. Proceedings of the ITI 2008 30th Int. Conf. on Information Technology Interfaces. 9. Gartner, Inc. Gartners Hype Cycle 2008 Technical Report. [En lnea] julio de 2008. [Link] 10. Cloudbus Toolkit for Market-Oriented Cloud Computing. Buyya, Rajkumar, Pandey, Suraj y Vecchiola, Christian. Springer, Germany : s.n., 2009. Proceeding of the 1st International Conference on Cloud Computing. 11. Google Trends Labs. Cloud Computing. [En lnea] 2009. [Link] 12. Morgan Stanley. Technology Trends. [En lnea] 12 de junio de 2008. [Link] 13. Pew Research Center. The Pew Internet & American Life Project. [En lnea] 2008. [Link] 14. Gartner, Inc. Gartner Highlights Key Predictions for IT Organisations and Users in 2008 and Beyond. enero 31 de 2008. Comunicado de Prensa de Gartner. 15. Hamilton, D. 'Cloud computing' seen as next wave for technology investors. [En lnea] 4 de junio de 2008. [Link] 16. IDC exchange. IT Cloud Services Forecast 2008, 2012: A Key Driver of New Growth. [En lnea] 8 de octubre de 2008. [Link] 17. Google. Google App Engine. [En lnea] [Link] 18. IBM, Corp. LotusLive. [En lnea] [Link] 19. Microsoft Corporation. Windows Azure platform. [En lnea] [Link] 20. SUN Microsystems, Inc. Sun Cloud Computing. [En lnea] [Link] 21. Amazon Web Services, LLC. Amazon Elastic Compute Cloud (Amazon EC2). [En lnea] [Link] 22. [Link] Foundation. About Us. [En lnea] [Link], Inc. [Link]

132

23. The Eucalyptus Open-source Cloud-computing System. Nurmi, Daniel, y otros. Santa Barbara, California 93106 : s.n., 22 de abril de 2009. 24. Alliance, The Globus. Nimbus. [En lnea] [Link] 25. Grupo de Arquitectura Distribuida. [Link]. [En lnea] Universidad Complutense de Madrid. [Link] 26. European Union FP7 projects &. Reservoir. [En lnea] [Link] 27. Berman, Fran, Fox, Geoffrey y Hey, Anthony. Grid Computing: Making the Global Infrastructure a Reality. s.l. : Wiley, Mayo de 2003. pg. 304. 978-0-470-85319-1. 28. Campus-grid UniAndes. Harold, Castro y Danilo, Prez. Bogot D.C. : s.n., 2007. Conferencia Latinoamericana de Computacin de Alto Rendimiento Ponencia. 29. UnaGrid - On Demand Opportunistic Desktop Grid. Castro, H., Rosales, E., Villamizar, M. and Miller, A. Melbourne : s.n., 2010. 4th Workshop on Desktop Grid and Volunteer Computing Systems (PCGRID 2010). 30. VMware, Inc. [En lnea] [Link] 31. Cloud Computing. Dikaiakos, Marios D., y otros. 5, s.l. : IEEE Computer Society, septiembre - octubre de 2009, IEEE Internet Computing, Vol. 13, pgs. 10-13. 32. Kleinrock, Leonard. UCLA to be the First Station in Nationwide Computer Network. [En lnea] Universidad de California, 3 de julio de 1969. [Link] 33. Pfister, G. F. Cluster Computing. [ed.] E. D. Reilly, and D. Hemmendinger, A. Ralston. s.l. : Eds. 4th ed. John Wiley and Sons Ltd.,Chichester. Encyclopedia of Computer Science. 34. Xtremweb: A generic global computing system. Fedak, G., y otros. 2001. In Proceedings of the 1st IEEE International Symposium on Cluster Computing and the Grid. pgs. 582587. 35. Toward internet distributed computing. Milenkovic, M., y otros. s.l. : IEEE Computer, 2003. Vol. 36, pgs. 36-46. 36. A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications. Schollmeie, Rdiger. s.l. : IEEE , 2002. Proceedings of the First International Conference on Peer-to-Peer Computing. 37. Some computer science problems in ubiquitous computing. Weiser, M. [ed.] Commun ACM. 1993. 10.1145/159544.159617. 38. Parkhill, D F. The Challenge of the Computer Utility. s.l. : Addison-Wesley Publishing Company, 1996. B000O121OS. 39. Cloud computing is changing how we communicate. Maggiani, Rich. Waikiki, HI, USA : s.n., 2009. IEEE International Professional Communication Conference. pgs. 1-4. 978-14244-4357-4. 40. [Link], Inc. Milestones. [En lnea] [Link] 41. Virtual Infrastructure Management in Private and Hybrid Clouds. Sotomayor, B., y otros. 5, septiembre - octubre de 2009, Internet Computing, IEEE, Vol. 13, pgs. 14-22. 42. Mell, Peter y Grance, Tim. NIST Definition of Cloud Computing. [En lnea] 15, 7 de Octubre de 2009. [Link] 43. Open Cloud Manifesto. [En lnea] Spring, 2009. [Link] 44. Wang, Lizhe y Von Laszewski, Gregor. Cloud Computing: a Perspective Study. [En lnea] Diciembre de 2008. [Link] 45. Kim, Won. Jounal of Object Technology. [En lnea] enero - febrero de 2009. [Link] [Link] 46. Vecchiol, Christian, Chu, Xingchen y Buyya, Rajkumar. Aneka: A Software Platform for .NET-based Cloud Computing. [En lnea] julio de 2009. [Link]

133

47. Cost-Benefit Analysis of Cloud Computing versus Desktop Grids. Kondo, Derrick, y otros. s.l. : IEEE Computer Society, 2009. Proceedings of the 2009 IEEE International Symposium on Parallel&Distributed Processing . pgs. 1-12. 978-1-4244-3751-1. 48. Weiss, Aaron. Computing in the clouds. [En lnea] diciembre de 2007. [Link] 49. Hwang, Kai. Massively Distributed Systems: From grids and p2p to clouds. [En lnea] 2008. [Link] 50. Ohlman, B., Eriksson, A. y Rembarz, R. What Networking of Information Can Do for Cloud Computing. [En lnea] 1 de julio de 2009. [Link] 51. Mcfedries, Paul. The Cloud is the Computer. [En lnea] agosto de 2008. [Link] 52. Vaquero, Luis, y otros. A Break In The Clouds: Towards A Cloud Definition. [En lnea] 2008. [Link] 53. Geelan, Jeremy. Twenty one experts define cloud computing. [En lnea] agosto de 2008. [Link] 54. EGEE II, Members of EGEE (Enabling Grids for E-sciencE Project). An EGEE comparative study: Grids and clouds - evolution or revolution? [En lnea] junio de 2008. [Link] Technical report. 55. Milojicic, Dejan. Cloud computing: Interview with Russ Daniels and Franco Travostino. [En lnea] septiembre de 2008. [Link] 56. Zhang, Liang-Jie y Zhou, Qun. CCOA: Cloud Computing Open Architecture. [En lnea] julio de 2009. [Link] 57. Chaganti, Prabhakar. Cloud computing with Amazon Web Services. [En lnea] 29 de julio de 2008. [Link] 58. Armbrust, michael, y otros. Above the Clouds: A Berkeley View of Cloud Computing. [En lnea] 10 de febrero de 2009. [Link] 59. Sun Microsystems, Inc. Take Your Business to a Higher Level. [En lnea] 1, marzo de 2009. [Link] 60. VMware, Inc. Cloud Computing Delivering Cloud Solutions from Development to Production. [En lnea] 200. [Link] 61. Oracle. Architectural Strategies for Cloud Computing. [En lnea] agosto de 2009. [Link] [Link]. 62. Cisco Systems, Inc. Private Cloud Computing for Enterprises: Meet the Demands of High Utilization and Rapid Change. [En lnea] junio de 2009. [Link] _c11-[Link]. 63. Yankee Group. Pinning Down Cloud. [En lnea] 24 de agosto de 2009. [Link] 64. Forrester Research, Inc. Is Cloud Computing Ready For The Enterprise? [En lnea] 7 de marzo de 2009. [Link] 65. Gartner, Inc. Gartner Says Cloud Computing Will Be as Influential as E-business. [En lnea] 26 de junio de 2008. [Link] 66. Future View: The New Tech Ecosystems Of Cloud, Cloud Services, And Cloud Computing. Gillett, Frank E. s.l. : Forrester, Inc., 28 de agosto de 2008, Emerging Cloud Markets series. 67. Rosales, Eduardo, y otros. Cloud Computing - Una perspectiva para Colombia. [En lnea] abril de 2010. [Link] 68. ElasticHosts Ltd,. ElasticHost. [En lnea] [Link] 69. Enomaly, Inc. Enomaly Elastic Computing. [En lnea] [Link] 70. Technologies, Akamai. Akamai. [En lnea] [Link]

134

71. Amazon Web Services, LLC. Amazon CloudFront Beta. [En lnea] [Link] 72. . Amazon Simple Storage Service (Amazon S3). [En lnea] [Link] 73. Amazon Web Services, LLC. Amazon SimpleDB. [En lnea] [Link] 74. . Amazon Elastic Block Store (EBS). [En lnea] [Link] 75. Microsoft Corporation. Microsoft SkyDrive. [En lnea] [Link] 76. YouTube, LLC. YouTube. Broadcast Yourself. [En lnea] [Link] 77. Nirvanix, Inc. Nirvanix Storage Delivery Network. [En lnea] [Link] 78. Microsoft Corporation. Microsoft Live Mesh. [En lnea] 30 de octubre de 2009. [Link] 79. Flickr, LLC. Flickr. [En lnea] [Link] 80. Elastra Corporation. Elastra Manage ComplexITy. [En lnea] [Link] 81. Engine Yard, Inc. Rails in the Cloud. [En lnea] [Link] 82. XCalibre Communications, Ltd. FlexiScale. [En lnea] [Link] 83. Layered Technologies, Inc. GridLayer. [En lnea] [Link] 84. Joyent, Inc. Enterprise Class Cloud Computing. [En lnea] [Link] 85. Rackspace, US Inc. The Rackspacecloud. [En lnea] [Link] 86. Savvis, Inc. Virtual Intelligent Hosting. [En lnea] [Link] 87. Digital Realty Trust, Inc. Digital Realty Trust. [En lnea] [Link] 88. [Link], Inc. [En lnea] [Link] 89. Layered Technologies, Inc. Layered Technology. [En lnea] [Link] 90. Terremark Worldwide. Terremark. [En lnea] [Link] 91. 1&1 Internet, Inc. 1&1 Internet. [En lnea] [Link] 92. Cohesive Flexible Technologies, Corp. CohesiveFT. [En lnea] [Link] 93. Amazon Web Services, LLC. Amazon Simple Queue Service (Amazon SQS). [En lnea] [Link] 94. Bigtable: A Distributed Storage System for Structured Data. Chang, Fay, y otros. Seattle, WA : s.n., noviembre de 2006. Seventh Symposium on Operating System Design and Implementation. 95. Microsoft. Microsoft SQL Azure Database. [En lnea] [Link] 96. NetSuite, Inc. NetSuite Business Operating System (NS-BOS). [En lnea] [Link] 97. [Link]. [Link]. [En lnea] [Link] 98. Microsoft. Microsoft Office Live. [En lnea] [Link] 99. Facebook, Inc. Facebook. [En lnea] [Link] 100. LinkedIn Corporation. LinkedIn. [En lnea] [Link] 101. Twiter, Inc. Twiter. [En lnea] [Link] 102. [Link]. [Link]. [En lnea] [Link] 103. [Link]. Zillow. [En lnea] [Link] 104. Google. Google Maps. [En lnea] [Link] 105. Cisco Systems, Inc. Cisco WebEx. [En lnea] [Link] 106. Google. Google Docs. [En lnea] [Link] 107. . Google Talk. [En lnea] [Link] 108. Microsoft. Microsoft Exchange Online. [En lnea] [Link] 109. RightNow Technologies, Inc. RightNow. [En lnea] [Link] 110. Google. Gmail. [En lnea] [Link] 111. Microsoft Hotmail. Hotmail. [En lnea] [Link] 112. Yahoo! Inc. Yahoo! [En lnea] [Link]

135

113. Amazon Web Services, LLC. Amazon Flexible Payments ServiceTM (Amazon FPS). [En lnea] [Link] 114. . Amazon DevPay. [En lnea] [Link] 115. Google. Google Calendar. [En lnea] [Link] 116. [Link], Inc. AppExchange On-Demand Marketplace. [En lnea] [Link] 117. Yahoo! Inc. Yahoo! Maps Web Services. [En lnea] [Link] 118. Sun Microsystems, Inc. Zembly Beta. [En lnea] [Link] 119. VMware, Inc. Transform your Business with Virtualization. [En lnea] [Link] 120. New Approach to Virtualization Is a Lightweight. Vaughan-Nichols, S.J. 11, noviembre de 2006, Computer, Vol. 39, pgs. 12-14. 121. Xen. How are Hypervisors Classified? [En lnea] [Link] 122. Hamilton, J. Internet-Scale Service Efficiency. s.l. : In Large-Scale Distributed Systems and Middleware (LADIS) Workshop, septiembre de 2008. 123. Vogels, W. A Head in the Clouds - The Power of Infrastructure as a Service. s.l. : In First workshop on Cloud Computing and in Applications (CCA 08), octubre de 2008. 124. Amazon Web Services, LLC. Amazon Elastic Compute Cloud (Amazon EC2). [En lnea] [Link] 125. Amazon Web Services, LLC. Amazon Web Services Overview of Security Processes. [En lnea] noviembre de 2009. [Link] 126. Xen and the art of virtualization. Barham, P., y otros. New York, NY, USA : ACM, 2003. In SOSP 03: Proceedings of the nineteenth ACM symposium on Operating systems principles. pgs. 164177. 127. Amazon Web Services, LLC. Articles & Tutorials. [En lnea] [Link] 128. . Amazon EC2 Instances Type. [En lnea] [Link] 129. . Developer Tools. Elasticfox Firefox Extension for Amazon EC2. [En lnea] [Link] 130. Solutions, Suchi Software. Amazon S3 Firefox Organizer(S3Fox). [En lnea] 11 de septiembre de 2009. [Link] 131. Amazon Web Services, LLC. Amazon EC2 Service Level Agreement. [En lnea] 23 de octubre de 2008. [Link] 132. . Amazon S3 Service Level Agreement. [En lnea] 1 de octubre de 2007. [Link] 133. Alliance, The Globus. Nimbus. [En lnea] [Link] 134. Chicago, University of. The Globus Alliance. [En lnea] [Link] 135. QEMU, a Fast and Portable Dynamic Translator. Bellard, F. s.l. : FREENIX Track, 2005. Proceedings of the USENIX Annual Technical Conference. pgs. 4146. 136. Keahey, K., y otros. Science Clouds: Early Experiences in Cloud Computing for Scientific Applications. [En lnea] [Link] 137. GridFTP: Protocol Extensions to FTP for the Grid. Allcock, W. 2003. Global Grid Forum. 138. Litzkow, M., Livny, M. y Mutka, M. A hunter of idle workstations. [En lnea] 1988. pp. 104111. [Link] 139. TORQUE Resource Manager. [En lnea] [Link] 140. Portable batch system: External reference specification. Henderson, R. y Tweten, D. 1996. Technical report, NASA, Ames Research Center. 141. Sun Microsystems, Inc. Sun Grid Engine. [En lnea] [Link] 142. Grupo de Arquitectura Distribuida. Client API 1.2. [En lnea] Universidad Complutense de Madrid. [Link]

136

143. Sun Microsystems, Inc. VirtualBox. [En lnea] [Link] 144. VMware, Inc. [En lnea] [Link] 145. . VMware View Reference Architecture. [En lnea] [Link] 146. . VMware View 4. Built for Desktops. [En lnea] 2009. [Link] 147. . VMware vSphere 4. [En lnea] [Link] 148. . VMware vSphere 4. The Best Platform for Building Cloud Infrastructures. [En lnea] [Link] 149. Sun Microsystems, Inc. Cisco Nexus 1000V Series Switches. [En lnea] [Link] 150. Distributed Management Task Force, Inc. Open Virtualization Format Specification. [En lnea] 22 de febrero de 2009. [Link] DSP0243. 151. Sarmenta, Louis F. G. Volunteer Computing . Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology. Massachusetts : s.n., 2001. Ph.D. dissertation. 152. BOINC. Volunteer Computing. [En lnea] [Link] 153. InteGrade: object-oriented Grid middleware leveraging the idle computing power of desktop machines. Goldchleger, Andrei, y otros. 5, So Paulo : John Wiley & Sons, Ltd., 26 de marzo de 2004, Concurrency and Computation: Practice and Experience, Vol. 16, pgs. 449 - 459. 154. The computational and storage potential of volunteer computing. Anderson, David P. y Fedak, Gilles. s.l. : IEEE Computer Society, 2006. In CCGRID 06. pgs. 7380. 155. The physiology of the grid: An open grid services architecture for distributed systems integration. Foster, I., Kesselman, C., Nick, J., Tuecke, S. 2002. 156. The anatomy of the grid: Enabling scalable virtual organizations. Foster, I., Kesselman, C., Tuecke, S. 3, 2001, High Performance Computuing Applications, Vol. 15, pgs. 200222. 157. Harold, Castro, Eduardo, Rosales y Mario, Villamizar. Desktop Grids and Volunteer Computing Systems. [aut. libro] Nikolaos Preve. Computational and Data Grids: Principles, Designs, and Applications. Atenas : IGI Global, 2010. 158. The "Worm" Programs Early Experience with a Distributed Computation. Shoch, John F.; Hupp, Jon A. 3, s.l. : Xerox Corporation Palo Alto Research Center, marzo de 1982, Communications of the ACM, Vol. 25. 159. Mersenne Research, Inc. GIMPS - Great Internet Mersenne Prime Search. [En lnea] [Link] 160. SETI@home An Experiment in Public-Resource Computing. Anderson, David, y otros. s.l. : ACM New York, noviembre de 2002, Communications of the ACM, Vol. 45, pgs. 56-61. 0001-0782. 161. [Link]. [Link]. [En lnea] [Link] 162. Anderson, David. BOINC: A System for Public-Resource Computing and Storage. [En lnea] 2004. [Link] 163. Sarmenta, L., y otros. Bayanihan Computing .NET: Grid Computing with XML Web Services. [En lnea] mayo de 2002. [Link] 10.1109/CCGRID.2002.1017182. 164. The OurGrid Approach for Opportunistic Grid Computing. Francisco, Brasileiro y Rodrigo, Miranda. Bogot D.C. : s.n., 2009. Proceedings of the First EELA-2 Conference. 165. UnaGrid - On Demand Opportunistic Desktop Grid. Harold, Castro, y otros. Melbourne, Australia : s.n., 2010. 4th Workshop on Desktop Grid and Volunteer Computing Systems (PCGRID 2010). 166. EGEE. gLite. [En lnea] [Link]

137

167. Gartner. Magic Quadrant for x86 Server Virtualization Infrastructure. [En lnea] 2010. [Link] 168. Comparison of performance of Web services, WS-Security, RMI, and RMISSL. Matjaz, Juric, y otros. 79, septiembre de 2006, The Journal of Systems and Software, pgs. 689700. 169. Stream Sockets versus Web Services for High-Performance and Secure Structural Analysis in Internet Environments. Javier, Garca y Eduardo, Bravo. 1, enero de 2009, Journal of Computing in Civil Engineering, Vol. 23, pgs. 47 56. 170. Comparison of Web Services, Java-RMI, and CORBA service implementations. A.B., Neil y Gray. Melbourne, Australia : s.n., 2004. Fifth Australasian Workshop on Software and System Architectures. 171. Communication facilities for Distributed Systems. V., Barladeanu. 13, Computer Science Journal of Moldova, Vol. 5. 172. Recommendation for Key Management Part 1: General. Barker, E., y otros. [ed.] NIST. mayo de 2006, NIST Special Publication. 173. Russinovich, Mark. Windows Sysinternals. PsExec v1.94. [En lnea] Microsoft, 4 de enero de 2008. [Link] 174. UnaGrid: Una solucin oportunista para la HPC en Colombia. Harold, Castro, y otros. Cartagena, Colombia : s.n., 2010. Quinto Congreso Colombiano de Computacin (5CCC). 175. Integrating a virtual Opportunistic Infrastructure to an EELA Site. Artur, Miller, y otros. Choron, Venezuela : s.n., 2009. 2nd EELA-2 Conference. 176. Rosero, Edgar Eduardo Rosales. Opportunistic Cloud Infrastructure as a Service. [En lnea] 2010. [Link] 177. Mesoscale Modeling of the Bacillus thuringiensis Sporulation Network Based on Stochastic Kinetics and Its Application for in Silico Scale-down. Gonzlez, A., y otros. Trento : s.n., 2009. HIBI '09. International Workshop on High Performance Computational Systems Biology. 178. Characterization of Phytophthora infestans Populations in Colombia: First Report of the A2 Mating Type. Vargas A.M., Ocampo L.M.Q., Cespedes M.C., Carreno N., Gonzalez A., Rojas A., Zuluaga A.P., Myers K., Fry W.E. and Jimenez P. s.l. : American Phytopathological Society, 2009. Phytopathology. pgs. 82-88. 179. Computational Biology in Colombia. Restrepo, S., y otros. 10, 2009, PLOS Computational Biology, Vol. 5. 180. Shostak, S. Sharing the Universe: Perspectives on Extraterrestrial Life. California : Berkeley Hills Books, 1998. 181. Livny, M. High-throughput resource management. The Grid: Blueprint for a New Computing Infrastructure. s.l. : Morgan Kaufmann, 1999, pgs. 311337. 182. Condor Project. How did the Condor project start? [En lnea] [Link] 183. Condor services for the Global Grid: interoperability between Condor and OGSA. Chapman, C. and Wilson, P. and Tannenbaum, T., y otros. s.l. : UK Engineering and Physical Science Research Council, 2004, pgs. 870-877. 184. Thain, Douglas, Tannenbaum, Todd y Livny, Miron. Grid Computing: Making the Global Infrastructure a Reality. s.l. : John Wiley, 2003, 11. 185. Frey, James, y otros. Condor-G: A computation management agent for multi-institutional grids. 2002, pgs. 237-246. 186. Foster, I. y Kesselman, C. The Globus project: A status report. s.l. : In IPPS/SPDP 98 Heterogeneous Computing Workshop, 1998. pgs. 4-18. 187. Mersenne Research, Inc. Mersenne Wiki. [En lnea] [Link] 188. . How GIMPS Works. [En lnea] [Link] 189. Mlucas. The Mlucas Project. [En lnea] [Link] 190. University of California, Berkeley. SETI@HOME. [En lnea] [Link]

138

191. Signal processing in SETI. Cullers, D. K., Linscott, I. R. y Oliver, B. M. 11, s.l. : ACM New York, 1985, Communications of the ACM, Vol. 28, pgs. 1151-1163. 0001-0782 . 192. [Link]. [Link] FAQ-O-Matic. [En lnea] [Link] 193. Anderson, David, Korpela, Eric y Walton, Rom. High-Performance Task Distribution for Volunteer Computing. [En lnea] diciembre de 2005. In Proceedings of the First IEEE International Conference on e-Science and Grid Technologies. [Link] 194. Baldassari, James, Finkel, David y Toth, David. SLINC: A Framework for Volunteer Computing. [En lnea] 13-15 de noviembre de 2006. [Link] 195. (EELA-2), E-science grid facility for Europe and Latin America. Welcome to the EELA-2 Project. [En lnea] [Link]/. 196. On the Co-existence of Service and Opportunistic Grids. Brasileiro, Francisco, y otros. Bogot D.C. : s.n., 2009. Proceedings of the First EELA-2 Conference. pgs. 51-61. 197. A system for fault-tolerant execution of data and compute intensive programs over a network of workstations. Smith, J. y Shrivastava, S.K. s.l. : IEEE Press, 1996. In Lecture Notes in Computer Science. Vol. 1123. 198. Grid computing for Bag-of-Tasks applications. Cirne, Walfredo, y otros. septiembre, 2003. In Proceedings of the I3E2003. 199. A computational economy for grid computing and its implementation in the Nimrod-G resource broker. Abramson, David, Buyya, Rajkumar y Giddy, Jonathan. 2002. Future Generation Computer Systems (FGCS) Journal. pgs. 1061-1074. 200. Analyzing market-based resource allocation strategies for the computational grid. Wolski, R., y otros. 2001. International Journal of Highperformance Computing Applications. 201. Automatic Grid Assembly by Promoting Collaboration in Peer-to-Peer Grids. Nazareno, Andrade, y otros. [ed.] Enterprise Systems and Storage Laboratory HP Laboratories Bristol. julio 25, 2007. Journal of Parallel and Distributed Computing. Vol. 68. 202. Automatic grid assembly by promoting collaboration in peer-to-peer grids. Andrade, N., y otros. 2007. Journal of Parallel and Distributed Computing . Vol. 67, pgs. 957- 966 . 203. OurGrid. OurGridStatus. [En lnea] 204. Object Management Group. CORBA v3.0 SpeciSpecication. julio de 2002. OMG document 02-06-33. 205. Lua an extensible extension language. Ierusalimschy, R., de Figueiredo, L. H. y Filho., W. C. 6, 1996, Software Practice and Experience, Vol. 26, pgs. 635652. 206. InteGrade: a tool for executing parallel applications on a Grid for opportunistic computing. Braga Pinheiro Junior, Jos, y otros. Fortaleza, Brasil : s.n., 2005. Proceedings of the 23th Brazilian Symposium on Computer Networks (SBRC Tools Track). 207. A bridging model for parallel computation. Valiant, L. G. 8, 1990, Communications of the ACM, Vol. 33, pgs. 103111. 208. BSPlib: The BSP programming library. . Hill, J. M. D., y otros. 14, Parallel Computing, Vol. 24, pgs. 19471980. 209. The Implementation of the BSP Parallel Computing Model on the InteGrade Grid Middleware. Goldchleger, Andrei, y otros. Grenoble, France : ACM New York, NY, USA, 2005. Proceedings of the 3rd international workshop on Middleware for grid computing. pgs. 1-6. 1-59593-269-0. 210. Hyperic, Inc. Hyperic SIGAR API. [En lnea] [Link]

139

ANEXOS ANEXO A - IMPLEMENTACIONES DE LA COMPUTACIN OPORTUNISTA ANEXO A1 - WORM La idea original de usar ciclos de procesamiento computacionales ociosos mediante un esquema de computacin distribuida, fue propuesta en 1978 para el desarrollo de un proyecto con programas worm, dirigido por Xerox Palo Alto Research Center (PARC) (180). El desarrollo de los programas worm estuvo orientado a los requerimientos de trascender las fronteras de la mquina que los ejecuta, movindose entre varias mquinas conectadas por una red, incluyendo mecanismos para la deteccin y replicacin en mquinas ociosas. El desarrollo de los programas worm es considerado un precursor de la computacin oportunista debido a que sent las bases para el aprovechamiento de recursos computacionales no dedicados, mediante la programacin de ejecuciones oportunistas durante horarios nocturnos, cuando la mayora de recursos computacionales podan considerarse ociosos (158). Las pruebas fueron efectuadas por personal TI en una infraestructura con caractersticas homogneas, la cual inclua 100 computadoras Alto, cada una conectada mediante una red local Ethernet a servidores de archivos, servidores de arranque y servidores de resolucin de nombres. La infraestructura computacional usada en el experimento se muestra en la Figura 46. Al tratarse de un centro de cmputo bajo un dominio administrativo nico, exista una programacin de uso bien conocida, as como usuarios responsables de su operacin.

File Server

Boot Server

DNS Server

Alto Computer

Segment Worm 1

Segment Worm 2

Segment Worm 3

Figura 46. Diagrama de despliegue de varios segmentos worm (Adaptado de (158)).

140

El diseo de los programas worm descart la posibilidad de alojarse o escribir en el disco duro de las mquinas objetivo debido a la existencia de servidores de almacenamiento dedicados. Un programa worm tena varios segmentos, cada uno ejecutndose en una mquina distinta. Bajo un modelo muy simple, cada worm est numerado como una parte del programa worm completo. Los programas worm estn escritos en el lenguaje de programacin bsico combinado o BCPL por las siglas en ingls de Basic Combined Programming Language. El proceso de deteccin de mquinas ociosas se implement a travs de un protocolo simple que incluy el envo de un formato de paquete especial que se distribua en la red por medio de un broadcast, para ejecutarse en las mquinas objetivo y cuyo valor de retorno determinaba el estado actual de las mquinas (ociosa o en actual uso). Una vez se detectaba una mquina ociosa, se enviaba la peticin para que la mquina hiciera un arranque desde la red, cargando el segmento worm asignado. Todos los segmentos worm estaban en capacidad de comunicarse entre s, de tal forma que les fuese posible detectar la falla de un segmento, ubicando una mquina ociosa alterna para ejecutar un segmento de respaldo. Estas tcnicas de segmentacin fueron probadas exitosamente para soportar varias aplicaciones incluyendo programas para probar el desempeo de hardware, aplicaciones para el tratamiento distribuido de imgenes, aplicaciones para probar el desempeo de enlaces Ethernet, hasta sistemas de animacin en tiempo real consumiendo mltiples mquinas. ANEXO A2 - CONDOR Condor (138), (181) es un sistema de administracin de carga especializado para tareas de computacin intensiva. El proyecto inici en el ao de 1988 como una continuacin al proyecto Remote-Unix (RU) de la Universidad de WisconsinMadison (182) y es considerado uno de los proyectos ms importantes en contribucin a la computacin de alto desempeo (High Throughput Computing HTC). El proyecto tiene como objetivo principal el desarrollo, implementacin, despliegue y evaluacin de mecanismos y polticas que soporten HTC en grandes conjuntos de computadores distribuidos, incluyendo el aprovechamiento eficiente de recursos computacionales ociosos. Al igual que otros sistemas de lotes en cola (batch queueing system), Condor provee a usuarios finales un mecanismo para la gestin de la cola de trabajos, polticas de planeacin, esquemas de prioridad, monitoreo y administracin de recursos. De esta forma los usuarios finales pueden enviar trabajos seriales o individuales a Condor, el cual se responsabiliza de colocarlos en la cola de 141

trabajos, elije el recurso adecuado para su ejecucin basndose en una poltica de planeacin, ejecuta los trabajos, monitoriza su progreso y finalmente informa al usuario sobre la culminacin del los mismos.
Central Manager Negotiator Collector

Submit Machine Controlling Daemons Schedd

Execution Machine Controlling Daemons start/starter

Shadow
per Syste m for me call s da sR PC s

Users jobs Users Code Syscall_Lib

Checkpoint file save to disk

Figura 47. Arquitectura de Condor (Adaptado de (183)).

Como se ilustra en la Figura 47, la arquitectura de Condor se basa en el modelo maestro esclavo, que responsabiliza al componente maestro de la revisin peridica del grupo de esclavos para planificar el envo de trabajos y procesar las constantes actualizaciones recibidas desde los esclavos con el fin de monitorizar el progreso de los trabajos y el estado general del cluster. Condor se compone de cinco demonios fundamentales. Condor_master tiene como funcin bsica, simplificar la administracin, manteniendo en ejecucin todos los demonios de Condor en cada mquina del sistema. Condor_startd se encarga de representar y anunciar una mquina perteneciente al sistema. Esto incluye la publicacin de las capacidades de la mquina as como sus polticas de uso. Cuando Condor_startd est listo para ejecutar un trabajo, invoca a Condor_starter el componente encargado de iniciar un trabajo, supervisar su ejecucin, detectar su culminacin y transferir los resultados a la mquina que lo envi. Condor_schedd acta como un gestor de la cola de trabajos, facilitando su manipulacin a travs de operaciones bsicas tales como la adiccin, consulta y borrado de trabajos. Este demonio se complementa con Condor_shadow el cual procesa peticiones para la transferencia de archivos, registros de progreso e informes estadsticos cuando un trabajo se ha completado. Condor_collector es una base de datos dinmica de informacin sobre el estado de los demonios de Condor, los recursos en donde se ejecutan y las solicitudes de recursos hechas al sistema. Finalmente Condor Negotiator es responsable de toda la intermediacin en el sistema, incluyendo la tarea de 142

verificar el cumplimiento de los requisitos de un trabajo en las mquinas disponibles. Estos dos ltimos componentes se ejecutan exclusivamente en el maestro del sistema Condor. Condor est diseado para operar bajo un dominio administrativo nico (184), pero existe una versin variante, Condor-G (185) cuyo diseo le permite ser interoperable con el middleware grid Globus Toolkit (186) para extender las capacidades de Condor a infraestructuras grid computing. Como una caracterstica diferenciadora de otros sistemas de lotes en cola, la arquitectura de Condor est diseada para operar eficientemente no solo en recursos computacionales dedicados, sino tambin sobre recursos computacionales parcialmente disponibles, conformados por computadores de escritorio, altamente distribuidos, econmicos y heterogneos. Las configuraciones de Condor incluyen un modo de aprovechamiento de recursos computacionales ociosos que se ejecuta exclusivamente ante la deteccin de inactividad en el teclado y mouse del computador que lo aloja. Adicionalmente Condor puede ser configurado para producir puntos de chequeo (checkpoints) peridicos, que le permiten migrar la ejecucin de trabajos a nodos disponibles, minimizando la prdida de tiempo de procesamiento en caso de fallas. ANEXO A3 - GIMPS GIMPS (Great Internet Mersenne Prime Search) (159) es un proyecto de computacin distribuida dedicado a la bsqueda de nmeros primos de Mersenne desarrollado por Mersenne Research, Inc. y actualmente licenciado bajo la figura GNU GPL (GNU General Public License). El proyecto fue fundando en enero de 1996 y se considera el primer proyecto de computacin voluntaria en el mundo. Su principal objetivo es la bsqueda de nmeros primos de Mersenne, un tipo especial de nmeros primos que son especialmente tiles para el desarrollo de algoritmos de cifrado rpido y la ejecucin de pruebas de desempeo, como aquellas usadas en la fabricacin de hardware (especialmente en circuitos de procesadores) (187). El proceso de bsqueda de los nmeros primos de Mersenne requiere de enormes capacidades de procesamiento, por lo cual resulta ineficiente cualquier solucin de cmputo centralizado. Adicionalmente la bsqueda puede efectuarse sobre conjuntos de nmeros que constituyen bloques de trabajo sin interdependencia para el clculo y entrega de resultados. La propuesta de GIMPS se basa en el aprovechamiento de recursos computacionales mediante la descarga e instalacin de un cliente liviano que permite a un usuario donador, aportar recursos computacionales ociosos para el clculo de nmeros primos de Mersennne, sobre plataformas Windows, Linux y Mac. El cliente est desarrollado en el lenguaje de programacin C y se ejecuta 143

como un proceso en background en la prioridad ms baja disponible en el sistema operativo que lo alberga. Haciendo uso de esta configuracin de procesos, se asegura un mnimo impacto en el desempeo percibido por el dueo del recurso compartido durante su ejecucin paralela.

[Link] Server
HTTP

Internet

GIMPS Clients

Mlucas Clients

Figura 48. Diagrama de despliegue de GIMPS (Adaptado de (188)).

La arquitectura del sistema se basa en un modelo cliente servidor escalable a Internet. Como se ilustra en la Figura 48, el cliente GIMPS se comunica con el servidor centralizado [Link] exclusivamente para obtener trabajos y reportar los resultados obtenidos. La comunicacin sucede a travs del protocolo HTTP (HyperText Transfer Protocol), haciendo uso de mensajes ligeros. El cliente es capaz de guardar el estado de sus trabajos cada media hora, por lo cual se considera este periodo como la mxima unidad de tiempo computacional perdido ante una falla. Dado el enfoque distribuido de la solucin y la posibilidad de desconexin permanente de un cliente, el proceso de distribucin de trabajos ocurre en forma redundante entre al menos dos clientes activos. Aunque el cliente del proyecto original nicamente soporta procesadores basados en arquitecturas x86, mltiples voluntarios alrededor del mundo desarrollaron Mlucas (189), la versin multiplataforma (no x86) de GIMPS. ANEXO A4 - SETI@HOME El proyecto SETI@home (160) represent el siguiente hito al permitir la participacin escalable de millones de recursos computacionales con el propsito de resolver un problema nico: la bsqueda de inteligencia extraterrestre, SETI (Search for Extraterrestial Intelligence). El proyecto inici a mediados de 1999 en

144

la Universidad de California, Berkeley y fue acreditado como el proyecto en recibir el mayor tiempo de procesamiento computacional en la historia (190). El objetivo de SETI@home se enfoca en el procesamiento de seales de radio de onda corta provenientes desde el espacio. Dichas seales no son producidas en forma natural, por lo cual una seal cuyo anlisis computacional descarte totalmente el hecho de que su proveniencia corresponda a un ruido producido por alguna fuente humana (como las estaciones de televisin, radio, satlites, radares, etc.), se considerara una evidencia cientfica de la existencia de tecnologa extraterrestre, esto es, vida extraterrestre inteligente (191). El proceso de anlisis de las seales de radio necesita de enormes capacidades computacionales para cubrir amplios espectros con mayor sensibilidad. Adicionalmente el anlisis de las seales puede ser paralelizado y no requiere de comunicacin entre clientes, por lo cual SETI@home usa eficientemente el modelo de computacin de recursos pblicos a travs de Internet.

Arecibo Laboratory

Data Recorder

Garbage Collector

Work-Unit Storage Splitter

Data Result Server

Database Server

Internet

SETI@home Clients

Figura 49. Diagrama de despliegue de SETI@home (Adaptado de (160)).

Al igual que GIMPS, SETI@home est basado en un agente ligero desarrollado en el lenguaje de programacin C++ y actualmente ofrece soporte a casi todos los sistemas operativos existentes, logro viable ante la colaboracin de desarrolladores voluntarios en todo el mundo. SETI@home puede ejecutarse como un protector de pantalla que adicionalmente incluye informacin estadstica asociada al procesamiento en ejecucin. Como se puede apreciar en la Figura 49, la arquitectura original de SETI@home es un modelo cliente servidor escalable a Internet con una dependencia a un servidor centralizado robusto, que debe coordinar a los clientes en la entrega de trabajos y en la recepcin de resultados mediante mensajes livianos comunicados a travs del protocolo HTTP. 145

El servidor primario se encarga de distribuir trabajos en forma redundante (a un nivel doble o triple), no solo para contemplar la desconexin permanente de los clientes, sino tambin para corroborar la validez de los resultados obtenidos, este proceso permite descartar resultados producidos en mquinas con procesadores daados o resultados fabricados por usuarios malintencionados. Adicionalmente los resultados obtenidos en cada cliente son guardados autnomamente en el disco duro en forma peridica, con el fin de proveer tolerancia a fallas y una alta eficiencia aun si el cliente es frecuentemente desactivado. SETI@home tambin desarroll una estrategia de premiacin a los participantes destacados por su contribucin. Dicha estrategia de marketing viral consiste en la categorizacin de participantes por la cantidad de procesamiento computacional aportado, que permite la conformacin de equipos de mltiples usuarios para posibilitar la competencia grupal. Esta categorizacin conforma un ranking a nivel mundial que puede ser consultado en la pgina oficial del proyecto y es respaldado por un conjunto de incentivos que incluyen correos de agradecimientos personalizados y reconocimientos pblicos. Adicionalmente se cre una comunidad virtual con perfiles de usuario configurables, que permite compartir noticias tcnicas y cientficas, foros de opinin e informacin general del proyecto. ANEXO A5 - [Link] [Link] (161) es una organizacin sin nimo de lucro a cargo de un proyecto del mismo nombre, fundado en 1997 bajo la licencia GNU FPL (Freeware Public Licence) el cual es considerado el primer proyecto de computacin distribuida de propsito general en el mundo. El proyecto se ha orientado a probar tcnicas de rompimiento de algoritmos de cifrado y a la bsqueda de conjuntos de Golomb ptimos (Optimal Golomb Ruler - OGR) que resultan especialmente tiles en las teoras de codificacin y combinatoria, as como en la colocacin de sensores para cristalografa de rayos X y el estudio de la radioastronoma. Ambas tareas se caracterizan por el uso intensivo de grandes capacidades de procesamiento y su distribucin natural en unidades de trabajo no dependientes para la generacin de resultados. Al igual que GIMPS y SETI@home, [Link] est basado en la ejecucin oportunista de un cliente liviano que fue desarrollado en el lenguaje de programacin C++ (actualmente ofrece soporte a Windows, Linux, Mac, Solaris y AIX), pero este mismo tambin puede ejecutarse como un protector de pantalla o un servicio ms del sistema operativo Windows. Como se ilustra en la Figura 50, la arquitectura del sistema parte de un modelo cliente servidor de tres jerarquas (arquitectura pirmide) que le permite ser escalable a Internet. El cliente [Link] se comunica directamente con un servidor proxy el cual se encarga 146

de asignar las unidades de trabajo obtenidas desde el servidor centralizado Bobine. Una vez un cliente ha procesado la unidad de trabajo, entrega los resultados obtenidos a su servidor proxy quien hace llegar los mismos al servidor centralizado principal.

Figura 50. Diagrama de despliegue de [Link] (Adaptado de (192)).

La arquitectura de [Link] contempla un mecanismo bsico de tolerancia a fallas al permitir que los clientes usen DNS round-robin para ubicar servidores proxy, en el caso de que el servidor asignado originalmente ya no se encuentre disponible. Adicionalmente se contempla un esquema opcional de cuatro jerarquas que usa servidores proxy personalizados (pproxies) entre los servidores proxy y los clientes, con el objetivo de permitir la distribucin de trabajos y recepcin de resultados a travs de firewalls. Los procesos de comunicacin estn soportados en el protocolo HTTP y se basan en el uso de mensajes ligeros. ANEXO A6 - BOINC BOINC (Berkeley Open Infrastructure for Network Computing) (162), surgi en el ao 2002 como una respuesta efectiva a las falencias detectadas en SETI@home, particularmente en lo relacionado a mejorar el esquema de seguridad para evitar la participacin de usuarios malintencionados y el uso exclusivo de una infraestructura creada con el fin de solucionar un problema nico. De esta forma, el principal objetivo de BOINC es el aprovechamiento de recursos computacionales para el desarrollo de proyectos cientficos multipropsito, ocultando las complejidades asociadas a la creacin, operacin y mantenimiento de proyectos de computacin de recursos pblicos al proveer un conjunto de herramientas para la construccin de una infraestructura segura, con servidores de domino administrativo autnomo y alta escalabilidad en Internet. 147

Al igual que GIMPS, [Link] y SETI@home, BOINC utiliza un agente ligero que debe ser instalado y ejecutado por los usuarios donadores de recursos computacionales. Sin embargo, este agente se diferencia de todos los acercamientos mencionados, porque realmente no est encargado de consumir en forma oportunista los recursos computacionales ociosos, sino que acta como una simple interface entre el servidor de BOINC y una o varias aplicaciones cientficas usuarias de BOINC que se ejecutan en el cliente. De esta forma, el agente consume una cantidad mnima de recursos computacionales y provee a la aplicacin cientfica usuaria, a travs de un API desarrollado en el lenguaje de programacin C++, las condiciones para el aprovechamiento de los recursos computacionales ociosos y las funcionalidades incorporadas en BOINC para el ocultamiento de las complejidades asociadas a la computacin de recursos pblicos. Este ocultamiento incluye la administracin de las comunicaciones que ocurren entre los clientes y el servidor, de tal forma que sea innecesario el desarrollo de cdigo y la implementacin de protocolos de comunicaciones para la creacin y ejecucin de aplicaciones cientficas usuarias.
SERVER Scheduler (C++) MySQL DB CLIENT

Work Generator (C++, BOINC API)

Web Site (PHP)

BOINC Client Demon (BOINC API)

Data Servers (HTTP)

Figura 51. Arquitectura de BOINC (Adaptado de (162)).

BOINC administra la capa de interaccin con el sistema manejador de base de datos (MySQL), de tal forma que un proyecto usuario no requiera el desarrollo de componentes de conexin o consulta sobre la base de datos. BOINC tambin administra la distribucin de trabajos y la recoleccin de resultados en forma eficiente y escalable, lo cual implica una carga de hasta 10 millones de peticiones diarias por parte de sus clientes (193). Como se ilustra en la Figura 51, la arquitectura de BOINC se basa en un modelo cliente servidor escalable a Internet, donde se responsabiliza al cliente BOINC de solicitar unidades de trabajo para las aplicaciones cientficas y de la entrega de los resultados producidos al servidor principal. Las unidades de trabajo poseen metadatos acerca de sus 148

requerimientos de procesamiento, memoria, espacio en disco, software y fecha lmite de espera para la generacin de resultados. La arquitectura de BOINC es escalable y modular, ya que suprime la restriccin de un servidor centralizado, permitiendo que cada uno de los componentes pueda ser ejecutado por una o varias instancias servidoras distribuidas bajo el control de cada proyecto. Esto supone que el nico cuello de botella en la infraestructura sea el sistema manejador de base de datos MySQL (194). El proyecto incluye todas las estrategias de marketing viral originalmente implementadas en SETI@home, pero las extiende en un esquema de participacin de mltiples proyectos. Adicionalmente, implementa un mecanismo de seguridad ms robusto para proteger los archivos que contienen los crditos otorgados a los usuarios por su aporte voluntario expresado en recursos computacionales. ANEXO A7 - BAYANIHAN COMPUTING .NET Bayanihan Computing .NET (163), es un framework genrico para grid computing basado en Microsoft .NET cuyo desarrollo inici en septiembre del ao 2001. Bayanihan implementa computacin voluntaria mediante la provisin de un servicio Web conjunto (pool service Web) asociado a computadores que actan como consumidores y proveedores de recursos computacionales mediante la arquitectura genrica que se ilustra en la Figura 52.

k() Tas Volunteer Worker 1 get


Computation Client ) ol(

Po () k a te cre dTas lt() ad esu l() tR Poo ge te le de

pu tR
Pool Service

es

ul t()

Volunteer Worker 2

Computation Client

Volunteer Worker 3

Figura 52. Diagrama de despliegue de Bayanihan Computing .NET (Adaptado de (163)).

El servicio Web principal permite que los usuarios finales, conectados a travs de clientes de cmputo (computation clients), creen conjuntos de tareas que son enviadas a recursos computacionales voluntarios (volunteers workers) para su ejecucin y posterior retorno de resultados. El framework permite la ejecucin de aplicaciones en la forma de ensamblador, como es el caso de archivos DLL (Dynamic Link Library). Estos archivos son descargados por los recursos computacionales voluntarios, implementando los mecanismos de seguridad bsicos que son provistos por la plataforma .NET de Microsoft. A diferencia de 149

GIMPS, [Link] y SETI@home, Bayanihan permite la ejecucin de aplicaciones de mltiple propsito incluyendo el soporte a grid computing. Los objetivos de una arquitectura basada en servicios Web incluyen la provisin de mtodos sencillos que pueden ser invocados por los clientes para ejecutar funciones especficas a nivel de aplicacin con sus propios datos, as como la provisin de computacin paralela para la ejecucin eficiente de tareas intensivas en el uso de recursos computacionales. Su diseo permite a un cliente invocar un mtodo sencillo para la ejecucin de tareas que son distribuidas por el framework a varios recursos computacionales voluntarios en forma transparente al cliente. Los servicios Web tienen un diseo ligero con la finalidad de que puedan ser accedidos desde dispositivos mviles como PDAs (Personal Digital Assistant) o incluso celulares. Adicionalmente estos servicios Web pueden orquestarse, permitiendo la conformacin de ambientes de cluster o grid computing de escalabilidad limitada. ANEXO A8 - OURGRID OurGrid (164) es un sistema de comparticin de recursos de licencia open source, basado en una red P2P de sitios que facilita compartir recursos equitativamente para formar infraestructuras de grid computing. El proyecto inici en el ao 2004 siendo desarrollado por el Departamento de Sistemas y Computacin de la Universidad Federal de Campina Grande de Brasil y actualmente es implementado en el contexto del proyecto E-science grid facility for Europe and Latin America (EELA-2) (195), aunque se consider operativo hasta el ao 2010 (196). OurGrid tiene dos objetivos fundamentales, el primero de ellos consiste en promover la agregacin escalable de recursos computacionales a una infraestructura grid oportunista, requiriendo una mnima interaccin o esfuerzo de negociacin por parte del dueo del recurso. El segundo objetivo plantea el diseo de una plataforma abierta y extensible de fcil instalacin, capaz de ejecutar aplicaciones del tipo bolsa de tareas (bag-of-tasks BoT Applications) (197), (198), mientras se promueve una cultura de comparticin de recursos para garantizar el acceso a la infraestructura grid. En OurGrid no existe ningn tipo de garanta de calidad de servicio sobre las aplicaciones desplegadas. Esto disminuye las complejidades asociadas a modelos de economa grid tradicionales (199), (200), evita las negociaciones entre proveedores de recursos y promueve una cultura de comparticin de recursos equitativa, siguiendo una estrategia del mejor esfuerzo.

150

OurGrid Brokers OurGrid Community

OurGrid Peer

OurGrid Workers

Figura 53. Diagrama de despliegue de OurGrid (Adaptado de (164)).

Los principales componentes de la arquitectura de OurGrid se ilustran en la Figura 53. El OurGrid Worker es un agente que se ejecuta en los recursos computacionales grid y es el responsable de implementar un ambiente seguro para la ejecucin oportunista de aplicaciones grid. Este agente define su comportamiento basndose en polticas establecidas por el dueo de los recursos, para determinar las condiciones en la cuales un recurso puede considerarse ocioso. El OurGrid Peer es el componente de cada sitio que administra el conjunto de recursos disponibles en la infraestructura grid. Este se une a la comunidad OurGrid mediante un servicio de descubrimiento que notifica a otros OurGrid Peers de su existencia. El OurGrid Peer puede ser accedido por usuarios internos y externos de la comunidad OurGrid, permitindole actuar como proveedor o consumidor de recursos. Todos los OurGrid Peers usan un protocolo para compartir recursos, este mismo provee mensajes para el descubrimiento de recursos adecuados para la ejecucin de trabajos (usando peticiones broadcast), la peticin de uso de recursos, la aceptacin o negacin y envo de trabajos y finalmente el retorno de resultados. Es importante destacar que los mecanismos incluidos en este protocolo no suponen un despliegue bajo demanda de los recursos, pero si permiten su bsqueda y asignacin dinmica. El OurGrid Broker es el responsable de proveer interfaces de usuario para la ejecucin de aplicaciones as como de ejecutar y administrar la programacin de aplicaciones en los recursos disponibles en la infraestructura grid. Una vez el OurGrid Broker recibe una peticin para la ejecucin de aplicaciones, procede a contactar al OurGrid Peer (generalmente del mismo sitio), solicitndole el nmero de mquinas necesarias para llevar a cabo la ejecucin, incluyendo parmetros tales como el sistema operativo, el mnimo de memoria requerida, etc. Cuando el OurGrid Peer recibe una solicitud del OurGrid Broker, este prioriza la bsqueda de recursos dentro de aquellos actualmente pertenecientes a su sitio y de ser necesario, est en capacidad de contactar otros OurGrid Peers para solicitarles

151

recursos adicionales. Tan pronto las mquinas son entregadas al OurGrid Broker, este mismo se encarga de programar las tareas y administrar su ejecucin. Todo el esquema de comparticin de recursos de OurGrid se basa en el concepto de una red de favores (network of favors) (201), una solucin parcial al problema de participantes no recprocos en la comparticin de recursos (free-riding peers) (202), la cual se basa en el supuesto de que un participante activo donar sus ciclos computacionales ociosos en reciprocidad a una donacin previa, marginalizando a usuarios no cooperativos mediante un mecanismo natural de simetra de intereses. Para ello cada OurGrid Peer guarda localmente un conjunto de datos histricos de los participantes que han hecho donaciones previas, con el fin de permitir priorizar los favores solicitados por los participantes de mayores crditos. La actualizacin de los crditos asociados a los usuarios donantes sucede en forma automtica, tan pronto como termina la ejecucin de un trabajo. Adicionalmente y teniendo como propsito fundamental el solucionar eficientemente los posibles problemas de seguridad asociados a la figura de intrusin de un agente, OurGrid utiliza un enfoque basado en mquinas virtuales, que le permite aislar a un posible usuario malicioso, mediante la restriccin de un entorno de ejecucin (sistema operativo, aplicaciones) con limitados recursos hardware y software de la mquina fsica (aquellos asignados por un hypervisor tipo II). OurGrid tambin incorpora mecanismos de seguridad robustos basados en llaves privadas y pblicas para certificar la autenticidad de los mensajes enviados mediante los protocolos OurGrid (196). Estos mecanismos buscan evitar ataques de denegacin de servicio provocados por participantes maliciosos. El estado actualizado de OurGrid puede ser monitorizado en la pgina oficial del proyecto (203). ANEXO A9 - INTEGRADE InteGrade (153) es una infraestructura middleware grid orientada a objetos de licencia GNU LGPL (Lesser General Public License), basada en el aprovechamiento oportunista de recursos computacionales ociosos. El proyecto inici en el segundo semestre del ao 2002 como una iniciativa del Instituto de Matemticas y Estadstica de la Universidad de Sao Pablo (IME-USP), el Departamento de Informtica de la Pontificia Universidad Catlica de Ro de Janeiro (PUC-Rio), la Universidad Federal de Gois (UFG), el Departamento de Informtica de la Universidad de Federal de Maranho (UFMA) y la Facultad de Computacin de la Universidad Federal de Mato Grosso do Sul (UFMS) de Brasil. InteGrade est basado en el middleware estandarizado para sistemas de objetos distribuidos CORBA (Common Object Request Broker Architecture) (204). Esto le 152

permite implementar servicios incorporados tales como nombramiento, intercambio, transacciones y persistencia. Todos los servicios de InteGrade son exportados mediante una implementacin CORBA ligera denominada O 2, escrita en LUA (205) que es accesible mediante una API desarrollada para los lenguajes de programacin C y C++. Otra de sus principales caractersticas es la integracin de un componente de anlisis de patrones de uso de recursos computacionales, capaz de recolectar datos estadsticos y determinar probabilsticamente la disponibilidad de una mquina, as como la conveniencia de asignarle un trabajo especfico. Esta implementacin evoluciona en el tiempo a travs de la recoleccin permanente de datos que pueden determinar nuevos patrones predominantes. Las unidades de composicin de la arquitectura de InteGrade son los clusters, cuyas agregaciones jerrquicas permiten construir una infraestructura grid compuesta por recursos dedicados y recursos parcialmente disponibles. Los componentes de la arquitectura InteGrade se ilustran en la Figura 54.
Cluster Manager

GUPA AR

GRM

Dedicated Node

Resource Provider Node

User Node

LUPA LRM NCC

LRM

LUPA ASCT

LRM

Figura 54. Arquitectura de InteGrade (Adaptado de (206)).

InteGrade soporta aplicaciones secuenciales, paramtricas (Parameter Sweep Applications) y paralelas BSP (Bulk Synchronous Parallel) (207) con requerimientos de comunicacin y sincronizacin entre nodos. Para lograr este objetivo, InteGrade incorpora un componente que analiza las caractersticas de los sistemas cliente as como las conexiones de red que los comunican, haciendo posible establecer parmetros especficos para la ejecucin de un trabajo, como por ejemplo el nmero de mquinas, la capacidad de CPU y memoria RAM requerida, la velocidad de conexin entre nodos, etc. Adicionalmente InteGrade utiliza su componente de anlisis de patrones de uso con el fin de determinar el conjunto de mquinas adecuadas para la ejecucin de una aplicacin paralela e implementa el modelo BSP con la finalidad de dividir los procesos de comunicacin y sincronizacin de nodos, al tiempo que impone sincronizaciones 153

frecuentes entre nodos. Dicho modelo est implementado en la librera Oxford BSPlib API (208), pero una aplicacin desarrollada en esta librera necesita un cambio de encabezado, re compilacin y cambio de enlaces para su adecuado funcionamiento con InteGrade (209). Dadas las condiciones variantes de disponibilidad de una infraestructura oportunista, el soporte a aplicaciones paralelas BSP, supone la aplicacin de una estrategia del mejor esfuerzo.

154

ANEXO B - DIAGRAMAS DE CLASES ANEXO B1 - DIAGRAMA DE CLASES DE UNACLOUD SERVER En este anexo se presenta y explica el diagrama de clases de las principales entidades de UnaCloud Server (la implementacin final consta de ms de 180 clases). Como se puede apreciar en la Figura 55 las clases SystemUser y SystemUserType son responsables de la administracin de usuarios (finales y administradores), as como de los procesos pertinentes a la autenticacin y autorizacin para la entrada a los servicios de UnaCloud Server. Las clases Template y TemplateType son responsables de la administracin de plantillas para el despliegue del modelo IaaS. Una plantilla es el identificador a bajo nivel de una imagen con un conjunto de aplicaciones que determinan su perfil funcional. Por ejemplo una plantilla de desarrollo de software tendr asociados lenguajes de programacin, entornos de desarrollo integrados (IDE), contenedores Web, herramientas de anlisis, diseo y prueba de software, etc. La clase TemplateType determina el tipo de plantilla, existiendo dos posibles variaciones: plantillas cloud o plantillas grid. Las primeras son aquellas accesibles a los usuarios IaaS (plantillas de propsito genrico) mientras las segundas estn restringidas para usuarios Grid o IaaS-Grid, los cuales configuran plantillas de propsito especfico para el correcto despliegue de sus aplicaciones de e-Ciencia. La clase Template tiene una relacin con la clase Application debido a que como explic anteriormente una plantilla contiene muchas aplicaciones. Adicionalmente la clase Template tiene una relacin con la clase OperatingSystem debido a que una plantilla tiene asociado un nico sistema operativo, el cual soporta el conjunto de aplicaciones que la componen. Las clases OperatingSystem y OperatingSystemType son responsables de la administracin de los sistemas operativos disponibles en la infraestructura base y en las mquinas virtuales que componen el modelo IaaS. La clase OperatingSystemType determina el tipo de sistema operativo existiendo cuatros opciones posibles: Windows, Linux, Mac y Solaris. La clase PhysicalMachine administra la informacin de cada una de las mquinas fsicas que componen la infraestructura base del modelo IaaS. Esta clase tiene una relacin con la clase OperatingSystem debido a que cada mquina fsica posee un sistema operativo principal sobre el cual es desplegado el modelo IaaS a travs de UnaCloud Client y un hypervisor tipo II.

155

Figura 55. Diagrama de clases de UnaCloud Server.

156

Las clases Laboratory y LaboratoryType son responsables de la administracin de los laboratorios fsicos y virtuales que agrupan las mquinas fsicas que componen la infraestructura base. Como se puede apreciar en la Figura 55, una mquina fsica pertenece a un laboratorio y este mismo tiene un tipo que lo define como laboratorio fsico o laboratorio virtual, este ltimo es una unidad de ordenamiento de mquinas fsicas que no pertenecen a ningn laboratorio fsico y que por lo tanto no tienen un localizacin natural que facilite su agrupamiento. Las clases VirtualMachine, VirtualMachineExecution y VirtualMachineSecurity son responsables de la administracin de las mquinas virtuales que componen el modelo IaaS. Como se puede apreciar en el diagrama de clases, una mquina virtual est asociada a una plantilla que acta como un descriptor del conjunto de aplicaciones y del sistema operativo que posee. Una mquina virtual tambin se asocia con una mquina fsica, debido a que ella constituye su proveedor de recursos computacionales para garantizar su ejecucin. La clase VirtualMachine se relaciona con la clase Hypervisor asignando un nico hypervisor tipo II a cada mquina virtual. Este mismo debe ser seleccionado durante su creacin y es invocado por UnaCloud Client para ejecutar las operaciones de ejecucin, apagado, reinicio y monitoreo. La clase VirtualMachine tambin se relaciona con la clase VirtualMachineSecurity. Esta ltima administra el esquema de seguridad para el acceso remoto a las mquinas virtuales que componen el modelo IaaS. Finalmente la clase VirtualMachine se relaciona con la clase VirtualMachineExecution la cual se responsabiliza de auditar las ejecuciones de mquinas virtuales. Este conjunto de registros histricos son almacenados con el propsito de auditar el uso de la infraestructura mediante reportes bsicos que facilitan consultar la trazabilidad de mquinas virtuales a nivel de usuario. ANEXO B2 - DIAGRAMA DE CLASES DE UNACLOUD CLIENT En este anexo se presenta y explica el diagrama de clases de las principales entidades de UnaCloud Client (la implementacin final consta de ms de 25 clases). Como se puede apreciar en la Figura 56, la clase ClientCommunication es el punto de entrada a los servicios provistos por UnaCloud Client. Esta clase se encarga de recibir una orden proveniente desde UnaCloud Server y trasladarla a la clase responsable de su cumplimiento. Todas las rdenes son ejecutadas a travs de la clase LocalProcessExecutor quien se responsabiliza de invocar a los servicios del sistema operativo local. A travs de esta invocacin es posible efectuar todas las operaciones de ejecucin, administracin y monitoreo soportadas por UnaCloud Client, incluyendo llamados 157

al hypervisor tipo II para las operaciones pertinentes a las mquinas virtuales que componen el modelo IaaS.

Figura 56. Diagrama de clases de UnaCloud Client.

La clase Hypervisor es responsable de ejecutar todas las operaciones asociadas a la administracin de mquinas virtuales (ejecucin, apagado, reinicio y monitoreo) mediante llamados al hypervisor local. Estos llamados se implementan a travs de clases especializadas en cada hypervisor tipo II soportado por UnaCloud Client, debido a las diferencias existentes en los comandos necesarios para la operacin de mquinas virtuales, as como en las funcionalidades disponibles. La clase Context se responsabiliza de la adaptacin de una mquina virtual al contexto de ejecucin personalizado que fue elegido por 158

el usuario final en UnaCloud Server. Esta adaptacin se debe implementar mediante clases especializadas en cada hypervisor soportado por UnaCloud Client, debido a las diferencias existentes en los archivos de configuracin de las mquinas virtuales. La clase Schedule se responsabiliza de la programacin de tiempos de ejecucin de una mquina virtual, la extensin o disminucin de los mismos y el apagado de una mquina virtual una vez ha finalizado su tiempo de reserva. Finalmente, la clase PhysicalMachine es responsable de la administracin de la informacin pertinente al recurso fsico que aloja a UnaCloud Client. Esta informacin se especializa en los contextos de las clases: CPU, Memory, Network, HardDisk y OperatingSystem. Las cuatro primeras clases implementan mtodos capaces de monitorizar un recurso computacional en tiempo real a travs del API: Hyperic's System Information Gatherer (SIGAR), mientras la clase OperatingSystem incorpora mtodos para monitorizar e invocar el sistema operativo a travs del API provisto por el lenguaje de programacin Java SE y segmentos de cdigo o scripts adaptados a cada sistema operativo soportado por UnaCloud Client (Windows, Linux y Mac).

159

ANEXO C - HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD ANEXO C1 - HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD SERVER Como se puede apreciar en la Figura 57, las tres principales capas de la arquitectura de UnaCloud Server estn implementadas en el contenedor del lenguaje de programacin Java Platform, Enterprise Edition (Java EE) versin 5. Sin embargo, existen herramientas particulares que soportan las funciones de cada capa. A continuacin se hace una breve descripcin de las mismas: Interface Layer: esta capa proporciona el servicio Web Interface (referirse a la Figura 14), el cual est implementado sobre el contenedor Web: GlassFish Server versin 2.1 final build. Este contenedor Web soporta todas las tecnologas de presentacin de UnaCloud Server, incluyendo a: Java Server Faces versin 1.2 (JSF), JSF Extensions Ajax versin 1.0, ICEFaces Project Integration versin [Link].[Link] y ICEFaces Run-Time Libraries versin [Link]. Estas tecnologas Web son accesibles desde todos los sistemas operativos que tengan instalado Java Runtime Environment (JRE) igual o superior a la versin 1.5 y soporten cualquiera de los navegadores Web: Microsoft Internet Explorer 6.x, Mozilla Firefox 2.x, Apple Safari 5.x, Google Chrome 3.x o versiones superiores.
UnaCloud Server
Interface Layer Java EE Container Core Layer
EJB Container Session Bean Managed Bean GlassFish Entity Bean JSF Components JPA Persistence Engine Oracle Toplink Xstream

External Layer

Web Browser

MySQL Server

Figura 57. Estructura de implementacin de UnaCloud Server.

Core Layer: esta capa proporciona los servicios: Customized Environment Manager, Virtual Machine Manager, Physical Infrastructure Manager y Persistence Manager (referirse a la Figura 14). Todos estos servicios estn soportados en el contenedor Enterprise Java Bean (EJB) versin 3.0. Este contenedor soporta los 160

Session, Managed y Entity Beans responsables de la administracin de las funciones de presentacin, negocios y persistencia, respectivamente (en trminos del patrn de diseo Web: Modelo Vista Controlador 2 MVC2). Adicionalmente, el servicio Persistence Manager se implementa sobre el Object-Relation Mapping (ORM) Oracle Toplink versin 10g, que acta como motor de persistencia del Java Persistence API (JPA). Esta persistencia se soporta en los servicios del sistema manejador de base de datos MySQL Community Server versin 5.1.47, el cual fue administrado haciendo uso de Toad for MySQL versin 4.6. External Layer: esta capa proporciona los servicios: Communication Manager y Security Manager (referirse a la Figura 15). El primero se soporta en los sockets TCP incluidos en la distribucin Java SE mientras el segundo se soporta en Xstream versin 1.3.1, librera que facilita la persistencia cifrada de archivos XML que contienen las llaves asimtricas y datos de configuracin de UnaCloud Server. Todos estos datos son necesarios para la implementacin de los mecanismos de seguridad en las comunicaciones que fueron descritos en el numeral 6.4.1. Adicionalmente, UnaCloud Server puede ser instalado en distribuciones Windows, Linux y Mac requiriendo nicamente de la instalacin de JRE, MySQL y Glassfish. El manual de instalacin de UnaCloud Server puede ser encontrado en (176). ANEXO C2 - HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DE UNACLOUD CLIENT Como se puede apreciar en la Figura 58, las dos principales capas de la arquitectura de UnaCloud Client estn implementadas en el lenguaje de programacin Java SE, compilado en el Java Developer Kit versin 1.6.0_20. Sin embargo, existen herramientas particulares que soportan las funciones de cada capa. A continuacin se hace una breve descripcin de las mismas: External Layer: esta capa proporciona los servicios: Security Manager y Communication Manager (referirse a la Figura 15). El primero se soporta en la librera Xstream para el cifrado de archivos XML que contienen datos de configuracin e identificadores locales, as como datos de red de UnaCloud Server. El segundo servicio se soporta totalmente en los sockets TCP incluidos en la distribucin Java SE. Core Layer: esta capa proporciona los servicios: Context Manager, Local Executor Manager, Hypervisor Manager y Monitoring Manager (referirse a la Figura 15). El primer servicio se soporta en el conjunto de operaciones de entrada y salida para la manipulacin de archivos, proporcionado por la librera Apache Commons-IO versin 1.4, la cual facilita la lectura y modificacin de los archivos 161

de configuracin de las mquinas virtuales (archivos planos .vmx). El segundo servicio, Local Executor Manager, ejecuta segmentos de cdigo adaptados a las primitivas de cada sistema operativo soportado por UnaCloud Client (Windows, Linux y Mac). Estos segmentos utilizan la clase Runtime de Java para invocar los servicios expuestos por el sistema operativo (tpicamente interfaces para la ejecucin de comandos). El tercer servicio, Hypervisor Manager, utiliza la clase Runtime de Java para invocar a la herramienta VMware vmrun (incluida en VMware platform with VIX libraries), la cual permite invocar al hypervisor tipo II, VMware Workstation en sus versiones 6.5 o 7, para efectuar las operaciones de administracin y monitoreo de mquinas virtuales que conforman el modelo IaaS. Finalmente el cuarto servicio, Monitoring Manager, se soporta en el API: Hyperic's System Information Gatherer (SIGAR) (210) versin 1.6.3, para ejecutar todas las operaciones de monitorizacin de la infraestructura fsica.

UnaCloud Client
External Layer Java SE
SIGAR

Core Layer Operating System

Runtime

vmrun

UnaCloud Server

Xstream

Commons IO

Hypervisor Type II
VMware Workstation

Figura 58. Estructura de implementacin de UnaCloud Client.

Adicionalmente UnaCloud Client puede ser instalado en distribuciones Windows, Linux y Mac requiriendo nicamente de la instalacin de JRE. El manual de instalacin de UnaCloud Client puede ser encontrado en (176). Cabe destacar que los desarrollos de UnaCloud Server y UnaCloud Client, fueron elaborados en el IDE Netbeans versin 6.7 el cual fue instalado con todos los paquetes Java (Netbeans Platform SDK, Java SE, Java Web y EE).

162

También podría gustarte