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
6.2.1.1. Interface Layer ...................................................................................... 82
6.2.1.2. Core Layer ............................................................................................ 83
6.2.1.3. External Layer ....................................................................................... 86
6.2.1.4. Diagrama de clases de UnaCloud Server ............................................. 87
6.2.2. UnaCloud Client ....................................................................................... 87
6.2.2.1. External Layer ....................................................................................... 87
6.2.2.2. Core Layer ............................................................................................ 89
6.2.2.3. 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 - DISTRIBUTED.NET ....................................................................... 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 Distributed.net ....................................... 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 Network.com (Sun Grid) (20), Amazon Web
Services (21), Salesforce.com (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 Salesforce.com (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

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

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

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).
Forrester
Inc.

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

Usabilidad

Modelo de
autoservicio

Acceso a travs de
red

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.

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

Administracin
delegada
Acuerdos de nivel de
servicio y calidad de
servicio

Seguridad

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

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
TIPO DE SERVICIO

EJEMPLO
Amazon Elastic Compute Cloud (Amazon EC2) (21),
Sun Network.com (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), GoDaddy.com (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.

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

como

Colaboracin
aplicaciones
oficina

y
de

Servicios de pago
Software basado en
Web integrable a otras
aplicaciones

EJEMPLO
Box.net (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),
Saleforce.com
AppExchange (116), Yahoo! Maps API (117), Zembly
(118).
23

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

Type I Hypervisor

CPU

MEMORY STORAGE

Main Operating System

NETWORK

CPU

HARDWARE

MEMORY STORAGE

NETWORK

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

P
EC2
Windows Instances
EC2
Management
Instance

INTERNET

SS
H

EC2
Management
Instance

Remote Management
Station

EC2
Linux Instances

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.

Context Broker

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.

Context
Client

Storage
Service

Workspace
Resource
Manager

Workspace
Service

Workspace
Pilot

IaaS
Gateway

Cloud
Client

Workspace
Control

Others
Providers

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

Other Tools

Core

SQL Pool

Request Manager (XML-RPC)

BD

VM
Manager

BD

Host
Manager

VN
Manager

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

Private
Network

Node
Controller

Cluster A

Node
Controller

Private
Network

Node
Controller

Cluster
Controller

Node
Controller

Cluster
Controller

Node
Controller

Node
Controller

Public
Network

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

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

Thin Client

Parent Image
VMware View
Composer

Desktop
Laptop

VMware ThinApp

USER
EXPERIENCE

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

Future Applications

App

App

App

App

App

VMware vCenter Suite

VMware vSphere

Application
Services

Availability

Security

vMotion
Storage vMotion
HA
Fault Tolerance
Data Recovery

vShield Zones
VMsafe

vCompute
Infrastructure
Services

ESX
ESXi
DRS

vStorage
VMFS
ThinProvisioning

Internal Cloud

Scalability
DRS
Hot Add

vNetwork
DistributedSwitch

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

Amazon EC2

Nimbus

OpenNebula

Eucalyptus

VMware View y
vSphere

Implementaciones
IaaS

Usabilidad

Alta

Alta

Media

Alta

Alta

Modelo de autoservicio

Alto

Alto

Alto

Alto

Alto

Acceso a travs de red

Alto

Alto

Alto

Alto

Alto

Personalizacin
de
servicios bajo demanda

Alta

Baja

Alta

Baja

Alta

Modelo multiusuario

Alta

Alta

Alta

Alta

Alta

Virtualizacin

Alta

Alta

Alta

Alta

Alta

Escalabilidad

Alta

Media

Alta

Media

Alta

Interoperabilidad y bajo
acoplamiento

Media

Alta

Alta

Alta

Media

Extensibilidad

Media

Alta

Alta

Alta

Media

Alta

Media

Media

Media

Alta

Medio

Bajo

Bajo

Bajo

Alto

Seguridad

Alta

Media

Media

Media

Alta

Modelo de trazabilidad

Alto

Bajo

Bajo

Bajo

Alto

Caractersticas
Cloud
Computing

Administracin
delegada
Acuerdos de nivel de
servicio y calidad de
servicio

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

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: Distributed.net (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 2

Computer laboratory 1

CVC C
Cluster/Grid User
Cluster/Grid User

CVC A

Slave

Slave

Slave
Master

Slave

Slave

Slave

CVC B

Slave

Slave

Certificate
Authority (CA)

Middleware
Grid

Slave

Slave

Slave

Master

Master

Slave

Slave

Slave

Slave

Slave

Computer laboratory 3
Cluster/Grid User

Cluster/Grid User

Slave

Master

Slave

CVC A

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

Control de impacto a
los usuarios de los
recursos compartidos

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.

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

BAYANIHAN

OurGrid

InteGrade

UnaGrid

de

BOINC

de

Distributed.net

de

SETI@Home

Facilidad
instalacin
Herramientas
monitoreo
Herramientas
administracin

GIMPS

Portabilidad

Condor

Caractersticas
Cloud
Computing
Control de impacto
a los usuarios de los
recursos
compartidos
Aprovechamiento de
recursos dedicados
Ejecucin
permanente
Uso
de
agentes/clientes
ligeros

Worm

Implementaciones
Oportunistas

No

No

No

No

No

No

No

No

No

No

No

No

No

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

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

Amazon EC2

Vmware View y
vSphere

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

Eucalyptus

Control de impacto a los

usuarios de los recursos
compartidos

OpenNebula

Requerimientos
pertinentes a una
infraestructura
base oportunista

Nimbus

Implementaciones
IaaS

No

No

No

No

No

No

No

No

No

No

No

No

No

No

59

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.

GIMPS

Distributed.net

Condor

SETI@Home

BAYANIHAN

BOINC

OurGrid

InteGrade

UnaGrid

Tabla 11. Comparacin y evaluacin del estado de la computacin

oportunista frente a cloud computing

Media

Media

Baja

Media

Baja

Media

Media

Media

Baja

Modelo de autoservicio

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Alto

Nulo

Nulo

Acceso a travs de red

Alto

Alto

Medio

Alto

Alto

Alto

Alto

Medio

Nulo

Nula

Nula

Nula

Nula

Nula

Nula

Nula

Nula

Media

Alto

Alto

Bajo

Alto

Bajo

Alto

Alto

Alto

Alto

Virtualizacin

Nula

Nula

Nula

Nula

Nula

Nula

Baja

Nula

Media

Escalabilidad

Alta

Alta

Media

Alta

Media

Alta

Alta

Alta

Baja

Medio

Medio

Alto

Medio

Bajo

Alto

Medio

Medio

Bajo

Baja

Media

Alta

Baja

Baja

Media

Media

Media

Media

Alta

Alta

Media

Alta

Media

Alta

Media

Media

Baja

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Nulo

Media

Media

Media

Media

Baja

Media

Media

Media

Baja

Alto

Alto

Alto

Alto

Nulo

Alto

Medio

Medio

Nulo

Implementaciones
Oportunistas

Caractersticas
Cloud
Computing
Usabilidad

Personalizacin
de
servicios bajo demanda
Modelo multiusuario

Interoperabilidad y bajo
acoplamiento
Extensibilidad
Administracin
delegada
Acuerdos de nivel de
servicio y calidad de
servicio
Seguridad
Modelo de trazabilidad

62

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, Distributed.NET, 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)

IaaS
Model
Type II Hypervisor

Virtualization Technology

Operating
System

Main Operating
System

CommodityHardware
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

Administrator
IaaS-Grid User

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

Physical Monitoring

Physical Administration

IaaS Traceability

IaaS Monitoring

IaaS Administration

IaaS Deployment

IaaS Customization

cmp UnaCloud Architecture

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

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.

Physical
Monitoring

Physical
Administration

IaaS Traceability

IaaS Monitoring

IaaS Administration

IaaS Deployment

IaaS Customization

cmp UnaCloud Serv er Architecture

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

6.2.1.1.

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

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

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

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).
6.2.1.2.

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

SERVICIO

Configuracin
hardware

Configuracin
software

del

componente

Customized Environment

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.

resume la

Tabla 15. Implementacin del componente Persistence Manager.

SERVICIO

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

6.2.1.3.

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.

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

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

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

Physical Monitoring

IaaS Monitoring

IaaS Administration

Physical Administration

IaaS Deployment

IaaS Customization

cmp UnaCloud Client Architecture

UNACLOUD CLIENT

External Layer

Security Manager

<<uses>>

Communication Manager

Core Layer

Context
Manager

Local Executor
Manager

Hyperv isor
Manager

Operating System Services

Monitoring
Manager

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

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

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

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.

90

Tabla 24. Implementacin del componente Monitoring Manager.

SERVICIO
Monitoreo
de
mquinas fsicas

6.2.2.3.

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

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

IaaS Customization

Authentication
Process
Full
Customization

Yes

No

Customize
Operating System
Type

Customize
Operating System
Version

Customize RAM
Memory Size

Customize CPU
Cores

Customize
Deployable Image

Customize Hard
Disk Size

End User Type

Cloud

Grid

Customize
Execution
Instances Number

Customize
Instances Number
and Localization

Customize
Execution Time

No adaptation
path

Deploy IaaS

UnaCloud Server
UnaCloud Client

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

No

Virtual Machine
CPU Cores Context
Adaptation

Virtual Machine
RAM Memory Size
Context Adaptation

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
IaaS Administration

UnaCloud Client

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 Administration

IaaS Deployment
Operation Type
Monitor

Turn Off

Restart

Execution
Time

Monitor IaaS

Request Monitor
Variables to
UnaCloud Client

Collect and Send

Virtual Machine
State Variables to
UnaCloud Serv er

Display the
Monitoring Report

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 Virtual
Machine

Send Virtual
Machine Restart
Order to UnaCloud
Client

Change Virtual
Machine Execution
Time

Send Virtual
Machine Execution
Time Order to
UnaCloud Client

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

Turn Off

Restart

Logout

Monitor Physical
Machine

Request Monitor
Variables to
UnaCloud Client

Turn Off Physical

Machine

Send Physical
Machine Turn Off
order to UnaCloud
Client

Restart Physical
Machine

Send Physical
Machine Restart
order to UnaCloud
Client

Logout Physical
Machine

Send Physical
Machine Logout
order to UnaCloud
Client

Collect and Send

Virtual Machine
State Variables to
UnaCloud Serv er

Display the
Monitoring Report

Operating System
Serv ices
Inv ocation

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.

Public Key
Private Key

Public Key
UnaCloud
Server

UnaCloud
Client

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.

3. UnaCloud Client descifra el mensaje

utilizando la llave pblica de UnaCloud Server
y un orden especifico para el tratamiento de
los parmetros recibidos.

3
True
False

3a

3a. Si el mensaje descifrado contiene

parmetros interpretables por UnaCloud
Client, en su orden correcto, este procede a
su ejecucin.

3b

3b. Si el mensaje descifrado no contiene

parmetros interpretables o el orden de los
mismos es incorrecto, UnaCloud Client
descarta el mensaje.

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.

Public Key

Public Key
UnaCloud
Server

Private Key

UnaCloud
Client

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.

True
False

3a

3b

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.

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

Operating System
Serv ices
Inv ocation

Customize
Localization and
Instances Number

Customize CVC
Execution Time

Hyperv isor Type II

Serv ices
Inv ocation

Deploy CVC

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

GUMA

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

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.

Figura 25. Administracin de usuarios UnaCloud.

104

servicios
usuarios
para la
figura se
facilita la
registros

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

Remote Access Mechanism

Administrators

IaaS users

UnaCloud
Server

Grid
Masters

GigE

Grid users

Alan Turing

Waira I

Waira II

IaaS
virtual
machines

CVC
Slaves

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

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

Tiempo de ejecucin de la tarea (segundos)

Prueba 1 Prueba 2
Prueba 3
Prueba 4
53,94

81,01

108,05

134,99

54,16

81,42

108,39

135,58

54,21

81,46

108,58

135,60

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)

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

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

262,43

526,63

1060,75

106,02

263,03

527,06

1063,07

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 Distributed.net 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

Control de impacto a los

usuarios de los recursos
compartidos

Estrategia oportunista basada en la ejecucin

de mquinas virtuales como procesos en
background de prioridad baja.

Aprovechamiento de
recursos dedicados

Ejecucin permanente
Uso de agentes/clientes
ligeros

Portabilidad

Facilidad de instalacin
Herramientas de
monitoreo
Herramientas de
administracin

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.

120

VALIDACIN

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)

Prueba
Operacin
Mquinas Virtuales
Encendido
Apagado
Reinicio
Monitoreo
Mquinas Fsicas
Apagado
Reinicio
Cierre de sesin
Monitoreo

Sin mecanismos de
seguridad

Con mecanismos de
seguridad

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

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

0,16
0,14
0,15
1

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 157.253.202.101 a 157.253.202.135 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

Acceso a travs de red

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.

123

VALIDACIN

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 157.253.202.46 a 157.253.202.80. 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

Acceso a travs de red

Personalizacin de
servicios bajo demanda

Modelo multiusuario

Virtualizacin

Escalabilidad

Interoperabilidad y bajo
acoplamiento

Extensibilidad

Administracin delegada

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.

126

VALIDACIN

Acuerdos de nivel de
servicio y calidad de
servicio
Seguridad

Modelo de trazabilidad

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

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.
http://dx.doi.org/10.1016/j.future.2008.12.001.
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.
http://www.computer.org/portal/web/csdl/doi/10.1109/MCSE.2009.121.
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.
http://www.aspeninstitute.org/sites/default/files/content/docs/pubs/Identity_in_the_Age_of_Clou
d_Computing.pdf.
7. da Palma Rosa, Pedro. Cloud Computing Basics. [En lnea] Dell, Inc.
http://content.dell.com/in/en/business/d/sb360/cloud-computing-basics.aspx.
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.
http://www.gartner.com/it/page.jsp?id=739613.
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.
http://www.google.com/trends?q=cloud+computing&ctab=0.
12. Morgan Stanley. Technology Trends. [En lnea] 12 de junio de 2008.
http://www.morganstanley.com/institutional/techresearch/pdfs/TechTrends062008.pdf.
13. Pew Research Center. The Pew Internet & American Life Project. [En lnea] 2008.
http://www.pewinternet.org/~/media/Files/Reports/2008/PIP_Cloud.Memo.pdf.pdf.
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. http://www.financialpost.com/money/story.html?id=562877.
16. IDC exchange. IT Cloud Services Forecast 2008, 2012: A Key Driver of New Growth.
[En lnea] 8 de octubre de 2008. http://blogs.idc.com/ie/?p=224.
17. Google. Google App Engine. [En lnea] http://code.google.com/.
18. IBM, Corp. LotusLive. [En lnea] https://www.lotuslive.com/es/.
19.
Microsoft
Corporation.
Windows
Azure
platform.
[En
lnea]
http://www.microsoft.com/windowsazure/.
20. SUN Microsystems, Inc. Sun Cloud Computing. [En lnea] http://www.network.com.
21. Amazon Web Services, LLC. Amazon Elastic Compute Cloud (Amazon EC2). [En lnea]
http://aws.amazon.com/ec2/.
22. Salesforce.com Foundation. About Us. [En lnea] Salesforce.com, Inc.
http://www.salesforcefoundation.org/aboutus/bod.html.

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] http://workspace.globus.org/.
25. Grupo de Arquitectura Distribuida. OpenNebula.org. [En lnea] Universidad
Complutense de Madrid. http://www.opennebula.org/.
26. European Union FP7 projects &. Reservoir. [En lnea] http://www.reservoir-fp7.eu/.
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] http://www.vmware.com/.
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.
http://www.lk.cs.ucla.edu/LK/Bib/REPORT/press.html.
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.
Salesforce.com,
Inc.
Milestones.
[En
lnea]
http://www.salesforce.com/company/milestones/.
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. http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc.
43.
Open
Cloud
Manifesto.
[En
lnea]
Spring,
2009.
http://www.opencloudmanifesto.org/Open%20Cloud%20Manifesto.pdf.
44. Wang, Lizhe y Von Laszewski, Gregor. Cloud Computing: a Perspective Study. [En
lnea]
Diciembre
de
2008.
https://ritdml.rit.edu/dspace/bitstream/1850/7821/1/LWangConfProc11-16-2008.pdf.
45. Kim, Won. Jounal of Object Technology. [En lnea] enero - febrero de 2009.
http://www.jot.fm/issues/issue_2009_01/column4.pdf.
http://www.jot.fm/issues/issue_2009_01/column4.pdf.
46. Vecchiol, Christian, Chu, Xingchen y Buyya, Rajkumar. Aneka: A Software Platform for
.NET-based
Cloud
Computing.
[En
lnea]
julio
de
2009.
http://arxiv.org/ftp/arxiv/papers/0907/0907.4622.pdf.

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.
http://portal.acm.org/citation.cfm?id=1327512.1327513#.
49. Hwang, Kai. Massively Distributed Systems: From grids and p2p to clouds. [En lnea]
2008. http://www.springerlink.com/content/b20700v83492544u.
50. Ohlman, B., Eriksson, A. y Rembarz, R. What Networking of Information Can Do for
Cloud
Computing.
[En
lnea]
1
de
julio
de
2009.
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=5159218&isnumber=5159183.
51. Mcfedries, Paul. The Cloud is the Computer. [En lnea] agosto de 2008.
http://www.spectrum.ieee.org/aug08/6490.
52. Vaquero, Luis, y otros. A Break In The Clouds: Towards A Cloud Definition. [En lnea]
2008. http://portal.acm.org/citation.cfm?id=1496091.1496100#.
53. Geelan, Jeremy. Twenty one experts define cloud computing. [En lnea] agosto de 2008.
http://virtualization.sys-con.com/node/612375.
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.
https://edms.cern.ch/document/925013. Technical report.
55. Milojicic, Dejan. Cloud computing: Interview with Russ Daniels and Franco Travostino. [En
lnea] septiembre de 2008. http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2008.97.
56. Zhang, Liang-Jie y Zhou, Qun. CCOA: Cloud Computing Open Architecture. [En lnea]
julio
de
2009.
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=5175875&isnumber=517578.
57. Chaganti, Prabhakar. Cloud computing with Amazon Web Services. [En lnea] 29 de julio
de 2008. http://www.ibm.com/developerworks/architecture/library/ar-cloudaws1/.
58. Armbrust, michael, y otros. Above the Clouds: A Berkeley View of Cloud Computing. [En
lnea] 10 de febrero de 2009. http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-200928.pdf.
59. Sun Microsystems, Inc. Take Your Business to a Higher Level. [En lnea] 1, marzo de
2009. http://www.sun.com/offers/docs/cloud_computing_primer.pdf.
60. VMware, Inc. Cloud Computing Delivering Cloud Solutions from Development to
Production. [En lnea] 200. http://www.vmware.com/solutions/cloud-computing/faqs.html.
61. Oracle. Architectural Strategies for Cloud Computing. [En lnea] agosto de 2009.
http://www.oracle.com/technology/architect/entarch/pdf/architectural_strategies_for_cloud_com
puting.pdf.
62. Cisco Systems, Inc. Private Cloud Computing for Enterprises: Meet the Demands of High
Utilization
and
Rapid
Change.
[En
lnea]
junio
de
2009.
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns836/ns976/white_paper
_c11-543729.pdf.
63. Yankee Group. Pinning Down Cloud. [En lnea] 24 de agosto de 2009.
http://www.yankeegroup.com/ResearchDocument.do?id=51855.
64. Forrester Research, Inc. Is Cloud Computing Ready For The Enterprise? [En lnea] 7 de
marzo de 2009. http://www.forrester.com/Research/Document/Excerpt/0,7211,44229,00.html.
65. Gartner, Inc. Gartner Says Cloud Computing Will Be as Influential as E-business. [En
lnea] 26 de junio de 2008. http://www.gartner.com/it/page.jsp?id=707508.
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. http://www.interactic.com.co/dmdocuments/clud_computing.pdf.
68. ElasticHosts Ltd,. ElasticHost. [En lnea] http://www.elastichosts.com/.
69. Enomaly, Inc. Enomaly Elastic Computing. [En lnea] http://www.enomaly.com/.
70. Technologies, Akamai. Akamai. [En lnea] http://spanish.akamai.com/enes/.

134

71. Amazon Web Services, LLC. Amazon CloudFront Beta. [En lnea]
http://aws.amazon.com/cloudfront/.
72. . Amazon Simple Storage Service (Amazon S3). [En lnea] http://www.amazon.com/s3/.
73.
Amazon
Web
Services,
LLC.
Amazon
SimpleDB.
[En
lnea]
http://aws.amazon.com/simpledb/.
74. . Amazon Elastic Block Store (EBS). [En lnea] http://aws.amazon.com/ebs/.
75. Microsoft Corporation. Microsoft SkyDrive. [En lnea] http://skydrive.live.com.
76. YouTube, LLC. YouTube. Broadcast Yourself. [En lnea] http://www.youtube.com.
77. Nirvanix, Inc. Nirvanix Storage Delivery Network. [En lnea] http://www.nirvanix.com/.
78. Microsoft Corporation. Microsoft Live Mesh. [En lnea] 30 de octubre de 2009.
http://www.mesh.com/.
79. Flickr, LLC. Flickr. [En lnea] http://www.flickr.com.
80. Elastra Corporation. Elastra Manage ComplexITy. [En lnea] http://www.elastra.com/.
81. Engine Yard, Inc. Rails in the Cloud. [En lnea] http://www.engineyard.com/.
82. XCalibre Communications, Ltd. FlexiScale. [En lnea] http://www.flexiscale.com/.
83. Layered Technologies, Inc. GridLayer. [En lnea] http://www.layeredtech.com/.
84. Joyent, Inc. Enterprise Class Cloud Computing. [En lnea] http://www.joyent.com/.
85. Rackspace, US Inc. The Rackspacecloud. [En lnea] http://www.rackspacecloud.com/.
86. Savvis, Inc. Virtual Intelligent Hosting. [En lnea] http://www.savvis.net/enUS/Pages/Home.aspx.
87. Digital Realty Trust, Inc. Digital Realty Trust. [En lnea] http://www.digitalrealtytrust.com/.
88. GoDaddy.com, Inc. [En lnea] https://www.godaddy.com/.
89. Layered Technologies, Inc. Layered Technology. [En lnea] http://www.layeredtech.com/.
90. Terremark Worldwide. Terremark. [En lnea] http://www.terremark.com/default.aspx.
91. 1&1 Internet, Inc. 1&1 Internet. [En lnea] http://order.1and1.com/.
92.
Cohesive
Flexible
Technologies,
Corp.
CohesiveFT.
[En
lnea]
http://www.cohesiveft.com/.
93. Amazon Web Services, LLC. Amazon Simple Queue Service (Amazon SQS). [En lnea]
http://aws.amazon.com/sqs/.
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]
http://www.microsoft.com/windowsazure/sqlazure/.
96. NetSuite, Inc. NetSuite Business Operating System (NS-BOS). [En lnea]
http://www.netsuite.com/portal/landing/ns-bos.shtml.
97. Box.net. Box.net. [En lnea] http://www.box.net/.
98. Microsoft. Microsoft Office Live. [En lnea] http://office.microsoft.com.
99. Facebook, Inc. Facebook. [En lnea] http://www.facebook.com.
100. LinkedIn Corporation. LinkedIn. [En lnea] http://www.linkedin.com.
101. Twiter, Inc. Twiter. [En lnea] http://twitter.com/.
102. MySpace.com. MySpace.com. [En lnea] http://www.myspace.com/.
103. Zillow.com. Zillow. [En lnea] http://www.zillow.com/.
104. Google. Google Maps. [En lnea] http://maps.google.com.
105. Cisco Systems, Inc. Cisco WebEx. [En lnea] http://www.webex.com/.
106. Google. Google Docs. [En lnea] http://docs.google.com.
107. . Google Talk. [En lnea] http://talk.google.com.
108.
Microsoft.
Microsoft
Exchange
Online.
[En
lnea]
http://www.microsoft.com/online/exchange-online.mspx.
109. RightNow Technologies, Inc. RightNow. [En lnea] http://www.rightnow.com/.
110. Google. Gmail. [En lnea] http://www.gmail.com.
111. Microsoft Hotmail. Hotmail. [En lnea] http://www.hotmail.com.
112. Yahoo! Inc. Yahoo! [En lnea] http://www.yahoo.com.

135

113. Amazon Web Services, LLC. Amazon Flexible Payments ServiceTM (Amazon FPS). [En
lnea] http://aws.amazon.com/fps/.
114. . Amazon DevPay. [En lnea] http://aws.amazon.com/devpay/.
115. Google. Google Calendar. [En lnea] http://calendar.google.com.
116. Salesforce.com, Inc. AppExchange On-Demand Marketplace. [En lnea]
http://sites.force.com/appexchange/home.
117. Yahoo! Inc. Yahoo! Maps Web Services. [En lnea] http://developer.yahoo.com/maps/.
118. Sun Microsystems, Inc. Zembly Beta. [En lnea] http://zembly.com/.
119. VMware, Inc. Transform your Business with Virtualization. [En lnea]
http://www.vmware.com/virtualization/what-is-virtualization.html.
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]
http://www.xen.org/files/Marketing/HypervisorTypeComparison.pdf.
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]
http://aws.amazon.com/ec2/.
125. Amazon Web Services, LLC. Amazon Web Services Overview of Security Processes.
[En
lnea]
noviembre
de
2009.
http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf.
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]
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1767.
128. . Amazon EC2 Instances Type. [En lnea] http://aws.amazon.com/ec2/instance-types/.
129. . Developer Tools. Elasticfox Firefox Extension for Amazon EC2. [En lnea]
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609.
130. Solutions, Suchi Software. Amazon S3 Firefox Organizer(S3Fox). [En lnea] 11 de
septiembre de 2009. https://addons.mozilla.org/en-US/firefox/addon/3247.
131. Amazon Web Services, LLC. Amazon EC2 Service Level Agreement. [En lnea] 23 de
octubre de 2008. http://aws.amazon.com/ec2-sla/.
132. . Amazon S3 Service Level Agreement. [En lnea] 1 de octubre de 2007.
http://aws.amazon.com/s3-sla/.
133. Alliance, The Globus. Nimbus. [En lnea] http://workspace.globus.org/.
134. Chicago, University of. The Globus Alliance. [En lnea] http://www.globus.org/alliance/.
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] http://www.cca08.org/papers/Paper39-Kate-Keahey.pdf.
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. http://www.ieee.org/stamp/stamp.jsp?arnumber=1540502&isnumber=32898.
139.
TORQUE
Resource
Manager.
[En
lnea]
http://www.clusterresources.com/products/torque-resource-manager.php.
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] http://www.sun.com/software/sge/.
142. Grupo de Arquitectura Distribuida. Client API 1.2. [En lnea] Universidad Complutense
de Madrid. http://www.opennebula.org/doku.php?id=documentation:rel1.2:api.

136

143. Sun Microsystems, Inc. VirtualBox. [En lnea] http://www.virtualbox.org/.

144. VMware, Inc. [En lnea] http://www.vmware.com/products/view/.
145.
.
VMware
View
Reference
Architecture.
[En
lnea]
http://www.vmware.com/resources/wp/view_reference_architecture_thanks.html.
146.
.
VMware
View
4.
Built
for
Desktops.
[En
lnea]
2009.
http://www.vmware.com/files/pdf/VMware-View-4-DS-EN.pdf.
147. . VMware vSphere 4. [En lnea] http://www.vmware.com/products/vsphere/.
148. . VMware vSphere 4. The Best Platform for Building Cloud Infrastructures. [En lnea]
http://www.vmware.com/files/pdf/vsphere_enterprise_datasheet.pdf.
149. Sun Microsystems, Inc. Cisco Nexus 1000V Series Switches. [En lnea]
http://www.cisco.com/en/US/products/ps9902/index.html.
150. Distributed Management Task Force, Inc. Open Virtualization Format Specification. [En
lnea]
22
de
febrero
de
2009.
http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf. 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]
http://boinc.berkeley.edu/trac/wiki/VolunteerComputing.
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]
http://www.mersenne.org.
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. Distributed.net. Distributed.net. [En lnea] http://www.distributed.net/.
162. Anderson, David. BOINC: A System for Public-Resource Computing and Storage. [En
lnea] 2004. http://portal.acm.org/citation.cfm?id=1033223.
163. Sarmenta, L., y otros. Bayanihan Computing .NET: Grid Computing with XML Web
Services.
[En
lnea]
mayo
de
2002.
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1540502&isnumber=32898.
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] http://glite.web.cern.ch/glite/.

137

167. Gartner. Magic Quadrant for x86 Server Virtualization Infrastructure. [En lnea] 2010.
http://www.vmware.com/files/pdf/cloud/Gartner-VMware-Magic-Quadrant.pdf.
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. http://technet.microsoft.com/es-es/sysinternals/bb897553.aspx.
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. http://sistemas.uniandes.edu.co/~grid/dokuwiki/doku.php?id=cloudcomputing.
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]
http://www.cs.wisc.edu/condor/background.html.
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]
http://mersennewiki.org/index.php/Main_Page.
188. . How GIMPS Works. [En lnea] http://www.mersenne.org/various/works.php.
189. Mlucas. The Mlucas Project. [En lnea] http://hogranch.com/mayer/README.html.
190.
University
of
California,
Berkeley.
SETI@HOME.
[En
lnea]
http://setiathome.berkeley.edu/.

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.
Distributed.net.
Distributed.net
FAQ-O-Matic.
[En
lnea]
http://faq.distributed.net/cache/51.html.
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.
http://portal.acm.org/citation.cfm?id=1033223.
194. Baldassari, James, Finkel, David y Toth, David. SLINC: A Framework for Volunteer
Computing.
[En
lnea]
13-15
de
noviembre
de
2006.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.3363&rep=rep1&type=pdf.
195. (EELA-2), E-science grid facility for Europe and Latin America. Welcome to the
EELA-2 Project. [En lnea] www.eu-eela.eu/.
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] http://www.hyperic.com/products/sigar.

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

Alto
Computer

Boot Server

Segment
Worm 1

DNS Server

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

Execution Machine

Controlling
Daemons
Schedd

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.

Prime.net 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 Prime.net 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

Garbage
Collector

Data
Recorder

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 - DISTRIBUTED.NET
Distributed.net (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, Distributed.net 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
Distributed.net 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 Distributed.net (Adaptado de (192)).

La arquitectura de Distributed.net 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, Distributed.net 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++)

CLIENT

MySQL DB

Work Generator
(C++, BOINC
API)

BOINC Client
Demon
(BOINC API)

Web Site
(PHP)

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()
R
o
t
ge tePo
le
de

pu
tR
Pool Service

es

ul
t()

Volunteer Worker 2

Volunteer Worker 3

Computation
Client

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, Distributed.net 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

GRM
AR

Dedicated Node

Resource Provider Node

LUPA

LRM

User Node

LUPA

LRM

LRM
NCC

ASCT

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
3.6.3.2.3.1.2.2 y ICEFaces Run-Time Libraries versin 1.8.2.2. 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

Core Layer

Java EE Container

External Layer

EJB Container
Session Bean
Managed Bean

GlassFish
Entity Bean

Web Browser

JSF
Components

Xstream

JPA Persistence
Engine
Oracle Toplink

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

Core Layer
Operating System

Java SE
SIGAR

Runtime

UnaCloud
Server

Xstream

Commons IO

vmrun

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