Trabajo de Grado Ingeniero de Sistemas

DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA CLOUD COMPUTING
BASADA EN HERRAMIENTAS OPEN SOURCE PARA OFRECER SERVICIOS

DE PLATAFORMA (PAAS) A LOS ESTUDIANTES DE INGENIERÍA DE
SISTEMAS UCEVA.
ANDRES FELIPE GONZALEZ VARGAS

DIEGO FERNANDO BRIÑEZ CRUZ
UNIDAD CENTRAL DEL VALLE DEL CAUCA

FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
TULUA, AGOSTO 27 DEL 2019
DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA CLOUD COMPUTING
BASADA EN HERRAMIENTAS OPEN SOURCE PARA OFRECER SERVICIOS
DE PLATAFORMA (PAAS) A LOS ESTUDIANTES DE INGENIERÍA DE
SISTEMAS UCEVA.
TRABAJO DE GRADO PRESENTADO COMO REQUISITO PARA OPTAR AL

TÍTULO DE INGENIERO DE SISTEMAS
DIRECTOR:
VIVIAN OREJUELA RUIZ
INGENIERA DE SISTEMAS
UNIDAD CENTRAL DEL VALLE DEL CAUCA

FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
TULUA, AGOSTO 27 DEL 2019
TABLA DE CONTENIDO
CAPÍTULO I. ASPECTOS GENERALES DEL PROYECTO ............................. 14

1.1 DEFINICIÓN DEL PROBLEMA ........................................................... 14
1.1.1. PLANTEAMIENTO DEL PROBLEMA ............................................ 14
1.1.2. PREGUNTA DE INVESTIGACIÓN ................................................ 16
1.2 JUSTIFICACION .................................................................................. 17
1.3 OBJETIVOS ......................................................................................... 20
1.3.1 General .......................................................................................... 20
1.3.2 Específicos .................................................................................... 20
1.4 ALCANCE ............................................................................................ 21
CAPÍTULO II - MARCO REFERENCIAL .......................................................... 22
2.1 MARCO TEÓRICO............................................................................... 22
2.1.1 SISTEMAS OPERATIVOS ............................................................. 22
2.1.2 MÁQUINA VIRTUAL ...................................................................... 23
2.1.3 SISTEMAS DISTRIBUIDOS ........................................................... 23
2.1.4 CLÚSTER COMPUTING................................................................ 23
2.1.5 GRID COMPUTING ....................................................................... 24
2.1.6 CLOUD COMPUTING.................................................................... 25
2.2 ESTADO DEL ARTE ............................................................................ 26
2.2.1 INTRODUCCIÓN Y DEFINICIÓN .................................................. 26
2.2.2 CARACTERÍSTICAS DE LA CLOUD COMPUTING ...................... 26
2.2.2.1 Autoservicio a la carta................................................................ 27
2.2.2.2 Amplio acceso a la red............................................................... 27
2.2.2.3 Reservas de recursos en común ............................................... 27
2.2.2.4 Rapidez y elasticidad ................................................................. 27
2.2.2.5 Servicio supervisado .................................................................. 27
2.2.3 ARQUITECTURA DE LA CLOUD COMPUTING............................ 27
2.2.3.1 Nodo controlador ....................................................................... 28
2.2.3.2 Nodo de cómputo ...................................................................... 28
2.2.3.3 Nodo de almacenamiento .......................................................... 29
2.2.3.4 Nodo de red ............................................................................... 29
2.2.4 TIPOS DE CLOUD COMPUTING .................................................. 29
2.2.5 SERVICIOS DE CLOUD COMPUTING.......................................... 30
2.2.5.1 Software como servicio (SaaS) .................................................. 30
2.2.5.2 Plataforma como servicio (PaaS) ............................................... 30
2.2.5.3 Infraestructura como servicio (IaaS) .......................................... 30
2.2.6 PIONEROS DE LA CLOUD COMPUTING ..................................... 31
2.2.7 REVISIÓN DE PROVEEDORES.................................................... 31
2.2.7.1 Amazon Web Service (AWS) ..................................................... 31
2.2.7.2 Microsoft Azure .......................................................................... 31
2.2.7.3 Google Cloud ............................................................................. 31
2.2.8 CUADRO COMPARATIVO JUSTIFICANDO LA ELECCIÓN DE
OPENSTACK PARA CONFIGURAR LA CLOUD QUE OFRECE
PLATAFORMA DE SERVICIO. ................................................................... 32
2.2.8.1 OpenNebula .............................................................................. 34
2.2.8.2 Eucalyptus ................................................................................. 34
2.2.8.3 CloudStack ................................................................................ 34
2.2.8.4 OpenStack ................................................................................. 34
CAPÍTULO III – METODOLOGÍA DE LA INVESTIGACIÓN ............................. 35
3.1 DEFINICIÓN DE LA INVESTIGACIÓN ................................................ 35
3.1.1 TEMA ............................................................................................. 35
3.1.2 TIPO DE INVESTIGACIÓN ............................................................ 35
3.1.3 Alcance de la investigación ............................................................ 36
3.1.4 Técnica de recolección de datos .................................................... 36
3.2 PREPARACIÓN DE LA INVESTIGACIÓN........................................... 37
3.2.1 Justificar la investigación ............................................................... 37
3.2.2 Recolectar datos ............................................................................ 37
CAPITULO IV. DISEÑO E IMPLEMENTACION DE LA INFRAESTRUCTURA DE
COMPUTO DE LA PLATAFORMA CLOUD COMPUTING............................... 38
4.1 SERVICIOS A IMPLEMENTAR ........................................................... 38
4.1.1 SERVICIO DE IDENTIDAD (KEYSTONE) ..................................... 38
4.1.1.1 Arquitectura de Keystone........................................................... 39
4.1.1.2 Service catalog y endpoints ....................................................... 40
4.1.2 SERVICIO DE IMÁGENES (GLANCE) .......................................... 41
4.1.2.1 Diferentes formatos de ficheros de imágenes ............................ 41
4.1.2.2 Arquitectura de Glance .............................................................. 43
4.1.3 SERVICIO DE COMPUTO (NOVA) ............................................... 44
4.1.3.1 Arquitectura ............................................................................... 44
4.1.3.2 El orquestador de nova .............................................................. 45
4.1.3.3 Tipos de hipervisores en OpenStack ......................................... 45
4.1.4 SERVICIO DE RED (NEUTRON) ................................................... 46
4.1.4.1 Arquitectura de Neutron ............................................................. 47
4.1.4.2 4.1.4.2 Conceptos de red en Neutron ........................................ 48
4.1.5 SERVICIO DE ALMACENAMIENTO (CINDER) ............................. 49
4.1.5.1 Arquitectura de Cinder ............................................................... 50
4.1.5.2 Tecnologías de Cinder ............................................................... 51
4.1.5.3 Conceptos de Cinder ................................................................. 51
4.1.6 SERVICIO DE ALMACENAMIENTO DE OBJETOS (SWIFT) ........ 51
4.1.6.1 Arquitectura de Swift .................................................................. 53
4.1.6.2 Conceptos de Swift .................................................................... 54
4.1.7 SERVICIO DE ORQUESTACIÓN (HEAT) ..................................... 55
4.1.7.1 Arquitectura Heat ....................................................................... 56
4.1.7.2 Anatomía de plantillas Heat ....................................................... 56
CAPITULO V. INFRAESTRUCTURA DE COMPUTO IMPLEMENTADA Y
PLATAFORMA DE SERVICIOS PAAS ............................................................ 58
5.1 INFRAESTRUCTURA DE COMPUTO OPENSTACK .......................... 58
5.2 ESPECIFICACIÓN DE SERVIDOR ANFITRIÓN.................................. 60
5.3 INSTALACIÓN DE ENTORNO OPENSTACK TODO EN UNO ........... 61
5.3.1 Instalación sistema operativo anfitrión ........................................... 61
5.3.2 Instalación paquetes OpenStack .................................................... 77
5.3.3 Despliegue OpenStack .................................................................. 84
5.3.4 Creación de imagen para OpenStack ............................................ 86
CAPITULO VI. PROTOTIPO FUNCIONAL QUE UTILIZA LA PLATAFORMA
CLOUD COMPUTING IMPLEMENTADA ......................................................... 88
6.1 IMPORTACIÓN DE IMAGEN PARA OPENSTACK ............................. 88
6.2 CREACIÓN DE VOLUMENES OPENSTACK ...................................... 91
6.3 CREACIÓN DE INSTANCIAS OPENSTACK ....................................... 92
6.4 LABORATORIO PRACTICO OPENSTACK ........................................ 95
CAPITULO VII. CONCLUSIONES Y RECOMENDACIONES ......................... 100
7.1 CONCLUSIONES............................................................................... 100
7.2 RECOMENDACIONES ...................................................................... 101
8. COLABORADORES................................................................................. 102
9. REFERENCIAS BIBLIOGRÁFICAS ......................................................... 103
LISTADO ILUSTRACIONES
Ilustración 1 – Estado actual Trabajos de Grado en estudiantes de Ingeniería de

Sistema y Electrónica UCEVA. ............................................................................. 16
Ilustración 2 – Esquema justificación proyecto. ................................................... 17
Ilustración 3 – Coste de servidor físico................................................................ 18
Ilustración 4 – Servicio de servidor en la nube. ................................................... 19
Ilustración 5 - Vista abstracta de los componentes de un sistema informático. ... 22
Ilustración 6 – Cuadro comparativo de las principales Cloud Computing
OpenSource ......................................................................................................... 33
Ilustración 7 – Proceso cualitativo. ...................................................................... 36
Ilustración 8 - Arquitectura de Keystone.............................................................. 39
Ilustración 9 – Arquitectura de Glance ................................................................ 43
Ilustración 10 – Arquitectura de Nova ................................................................. 44
Ilustración 11 – Arquitectura de Neutron ............................................................. 47
Ilustración 12 – Arquitectura de Cinder ............................................................... 50
Ilustración 13 – Arquitectura de Swift .................................................................. 53
Ilustración 14 – Arquitectura de Heat. ................................................................. 56
Ilustración 15 - Arquitectura básica para ambiente OpenStack. .......................... 58
Ilustración 16 - Arquitectura para ambiente de Producción OpenStack. .............. 59
Ilustración 17 - Descripción técnica (Servidor - UCEVA). .................................... 60
Ilustración 18 – Creación de MV en VMWare...................................................... 61
Ilustración 19 – Creación de MV en VMWare –Tipo de configuración. ................ 62
Ilustración 20 – Creación de MV en VMWare – Compatibilidad con Hardware. .. 62
Ilustración 21 – Creación de MV en VMWare – Configuración de Boot. .............. 63
Ilustración 22 – Creación de MV en VMWare – Selección SO Anfitrión. ............. 63
Ilustración 23 – Creación de MV en VMWare – Nombre de MV y ruta de destino.
............................................................................................................................. 64
Ilustración 24 – Creación de MV en VMWare – Selección número de Procesadores.
............................................................................................................................. 64
Ilustración 25 – Creación de MV en VMWare - Selección capacidad RAM. ........ 65
Ilustración 26 – Creación de MV en VMWare – Selección tipo red...................... 65
Ilustración 27 – Creación de MV en VMWare – Selección Controlador I/O. ........ 66
Ilustración 28 – Creación de MV en VMWare – Selección tipo disco duro virtual 66
Ilustración 29 – Creación de MV en VMWare – Selección disco duro virtual. ...... 67
Ilustración 30 – Creación de MV en VMWare – Selección capacidad disco duro
virtual. ................................................................................................................... 67
Ilustración 31 – Creación de MV en VMWare – Asignar nombre disco duro virtual.
............................................................................................................................. 68
Ilustración 32 – Creación de MV en VMWare – Configuración realizada............. 68
Ilustración 33 – Creación de MV en VMWare – MV preparada para instalación de
SO anfitrión........................................................................................................... 69
Ilustración 34 – Creación de MV en VMWare – Origen SO anfitrión ................... 69
Ilustración 35 – Instalación – Iniciar MV. ............................................................. 70
Ilustración 36 – Instalación – Selección idioma SO. ............................................ 70
Ilustración 37 – Instalación – Selección configuración teclado ............................ 71
Ilustración 38 – Instalación – Selección tipo de SO. ............................................ 71
Ilustración 39 – Instalación – Configuración de red. ............................................ 72
Ilustración 40 – Instalación – Configuración Ubuntu archive Mirror ..................... 72
Ilustración 41 – Instalación – Selección tipo particionamiento ............................. 73
Ilustración 42 – Instalación – Selección partición creada. ................................... 73
Ilustración 43 – Instalación – Visualización sistema de archivos. ........................ 74
Ilustración 44 – Instalación – confirmación cambios sistema de archivos. .......... 74
Ilustración 45 – Instalación – Configuración perfil SO. ........................................ 75
Ilustración 46 – Instalación – Paquetes adicionales. ........................................... 75
Ilustración 47 – Instalación – Reiniciar para aplicar cambios. ............................. 76
Ilustración 48 – Instalación – Ubuntu listo para inicial ......................................... 76
Ilustración 49 – Actualización de paquetes. ........................................................ 77
Ilustración 50 – Validación de usuario administrador .......................................... 77
Ilustración 51 – Actualizando paquetes. .............................................................. 77
Ilustración 52 – Paquetes actualizados. .............................................................. 78
Ilustración 53 – Proceso de descarga de paquetes. ............................................ 78
Ilustración 54 – Instalación de paquetes. ............................................................ 79
Ilustración 55 – Creación de usuario Stack. ........................................................ 79
Ilustración 56 – Echo Stack................................................................................. 79
Ilustración 57 – Inicio de sesión usuario Stack. ................................................... 80
Ilustración 58 – Clonación de repositorio devStack. ............................................ 80
Ilustración 59 – Fin de clonación. ........................................................................ 80
Ilustración 60 – Cambio de propietario. ............................................................... 81
Ilustración 61 – Consultar IP. .............................................................................. 81
Ilustración 62 – Configuración local.conf. ............................................................ 82
Ilustración 63 – Ejecución de stack.sh. ............................................................... 82
Ilustración 64 – Instalación de servicios. ............................................................. 83
Ilustración 65 – Fin de instalación de servicios. .................................................. 83
Ilustración 66 – Dashboard. ................................................................................ 84
Ilustración 67 – Ingreso a Horizon....................................................................... 84
Ilustración 68 – Administración de OpenStack. ................................................... 85
Ilustración 69 – Instalación de aplicativos. .......................................................... 86
Ilustración 70 – Creación de usuario para estudiantes. ....................................... 86
Ilustración 71 – Entorno de desarrollo. ................................................................ 87
Ilustración 72 – Creación de imagen en OpenStack............................................ 88
Ilustración 73 – Detalles de la imagen................................................................. 89
Ilustración 74 – Configuración de sabor. ............................................................. 89
Ilustración 75 – Proceso de creación de imagen. ................................................ 90
Ilustración 76 – Estado de la imagen. ................................................................. 90
Ilustración 77 – Volumen..................................................................................... 91
Ilustración 78 – Estado de volumen. ................................................................... 91
Ilustración 79 – Detalles de creación de imagen. ................................................ 92
Ilustración 80 – Asignación de volumen. ............................................................. 92
Ilustración 81 – Asignación de sabor................................................................... 93
Ilustración 82 – Configuración de red. ................................................................. 93
Ilustración 83 – Ejecución de instancia. .............................................................. 94
Ilustración 84 – Consola grafica de Instancia. ..................................................... 94
Ilustración 85 – Laboratorio practico. .................................................................. 95
Ilustración 86 – Acceso de usuario estudiante1. ................................................. 95
Ilustración 87 – Creación de directorios. ............................................................. 96
Ilustración 88 – Creación de fichero ejercicio1. ................................................... 96
Ilustración 89 – Elaboración de ejercicio1 – Laboratorio. .................................... 96
Ilustración 90 – Creación y validación de ejecutable ejercicio.cpp. ..................... 97
Ilustración 93 – Creación y validación de ejecutable ejercicio2.cpp. ................... 98
Ilustración 96 – Creación y validación de ejecutable ejercicio3.cpp. ................... 99
LISTADO TABLAS
Tabla 1 - Listado de proyectos de investigación y trabajos de grado que requieren

procesamiento masivo de datos. .......................................................................... 15
GLOSARIO
TIC: Tecnologías de la información y la comunicación, se referirse a cualquier forma

de hacer cómputo.
Middleware: Software que se sitúa entre un sistema operativo y las aplicaciones

que se ejecutan en él. Básicamente, funciona como una capa de traducción oculta
para permitir la comunicación y la administración de datos en aplicaciones
distribuidas.
Virtualización: Es la creación a través de software de una versión virtual de algún

recurso tecnológico, como puede ser una plataforma de hardware, un sistema
operativo, un dispositivo de almacenamiento u otros recursos de red.
Computación ubicua: Concepto en ingeniería de software y las ciencias de la

computación. Es entendida como la integración de la informática en el entorno de la
persona, de forma que los ordenadores no se perciban como objetos diferenciados,
apareciendo en cualquier lugar y en cualquier momento.
Multi threading: Ejecución de grupo de thread que corren en paralelo utilizando el

mismo espacio en memoria y variables globales permitiendo la multitarea,
mejorando el rendimiento de las aplicaciones.
Script: Conjunto de órdenes guardadas en un archivo de texto, generalmente muy

ligero y, que es ejecutado por lotes o línea a línea, en tiempo real por un intérprete.
Docker: proyecto de código abierto que automatiza el despliegue de aplicaciones

dentro de contenedores de software, proporcionando una capa adicional de
abstracción y automatización de virtualización de aplicaciones en múltiples sistemas
operativos.
GIT: Software de control de versiones, pensando en la eficiencia y la confiabilidad

del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran
número de archivos de código fuente.
G ++ command: Comando de invocación del compilador GNU c ++, que se utiliza

para pre-procesar, compilar, ensamblar y vincular el código fuente para generar un
archivo ejecutable.
LSI Logic: Controlador orientado a la arquitectura de 32 y 64 bits, más utilizado en

la virtualización de MV, debido a su compatibilidad con el sistema operativo anfitrión.
BustLogic: Primer controlador que utilizo VMware para la virtualización de
máquinas virtuales, actualmente solo está disponible para computadores con
arquitectura de 32 bits.
Logic SAS: Controlador de facto utilizado actualmente por VMware el cual

aprovecha mejor el hardware anfitrión.
IDE: Disco duro, el cual utiliza una conexión ATA paralei, tiene una capacidad que
viene desde 30MB a 750GB.
SATA: El tipo de disco duro SATA sustituye a su antecesor IDE, ya que gracias a
su tecnología brinda mayores velocidades y su capacidad de almacenamiento viene
desde los 80GB hasta los 2TB.
SCSI: Disco duro especialmente utilizado para grandes cantidades de información,

generalmente usado en servidores ya que tienen la capacidad de almacenar y leer
grandes de volúmenes de datos a altas velocidades comparado con sus
antecesores IDE y SATA.
NVME: Disco duro SSD, el cual tiene grandes velocidades de transmisión de datos
tanto escritura y lectura.
Nota de aceptación:
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
Firma del presidente del jurado
_____________________________
Firma del jurado
_____________________________
Firma del Jurado
Tuluá – Valle del Cauca, 27 de agosto de 2019

DEDICATORIA
Este trabajo de grado es dedicado a cada integrante de mi valiosa familia: mi

compañera de vida e hijo (Martín), mis padres, hermanas, abuelos que pusieron su
fe en mí; A mis amigos, compañeros de estudio y profesores que me han brindado
su incondicional apoyo durante toda esta etapa de formación profesional.
Andrés Felipe Gonzalez Vargas
La culminación de este trabajo de grado es dedicada a mis padres que me

acompañaron durante todo el proceso académico y me dieron las bases para salir
a delante pensando en mi futuro.
Diego Fernando Briñez Cruz

1. CAPÍTULO I. ASPECTOS GENERALES DEL PROYECTO
1.1 DEFINICIÓN DEL PROBLEMA
1.1.1. PLANTEAMIENTO DEL PROBLEMA
En los tiempos actuales es muy importante el manejo y la distribución que se realiza

a la Información, ya que se ha convertido en una fuente muy importante de
desarrollo de los países. Debido al gran despliegue de dispositivos con capacidad
de conexión, la información que se genera en las operaciones computacionales del
día a día, crece de manera exponencial, es por esta razón que el procesamiento se
torna complejo y por ello se debe contar con una tecnología que obtenga el mayor
provecho de la información suministrada, de allí la importancia de la utilización de
la tecnología Cloud Computing para el procesamiento de grandes volúmenes de
datos generados. La Cloud Computing se convierte en una herramienta potente y
escalable de computación masiva y de alto rendimiento, capaz de almacenar,
analizar (en línea o fuera de línea) y procesar en tiempo real los datos suministrados
por la infraestructura de monitoreo. La tecnología de computación en la nube
permite almacenamiento y software como servicio (SaaS) con posibilidades de
personalización y virtualización a bajo costo, además provee una plataforma abierta,
flexible y reconfigurable (PaaS) para monitoreo y control de aplicaciones 1.
La computación en la nube o en ingles Cloud Computing es una computación

basada en Internet que provee servicios sobre demanda que incluye acceso a
servidores, discos de almacenamiento, diferentes plataformas y aplicaciones para
cualquier nivel de negocio, compañía u organización. En la computación en la nube
los servicios son pagados según el uso, así como también la calidad del servicio
(QoS) es acordada entre el proveedor de servicio de la nube y el cliente.
Los altos volúmenes de datos procesados pueden servir a investigadores, a la

industria y las universidades, para mejorar los diferentes servicios y procesos que
se relacionan con las actividades humanas. Para poder almacenar esta información
sin tener que invertir grandes sumas de dinero en la infraestructura de
comunicaciones se requiere de la computación en la nube, lo cual la convierte en
una excelente alternativa que además de almacenar, también permite procesar los
datos2.
En la formación de futuros profesionales de la ingeniería de sistemas es importante

que sean capaces de implementar y evaluar soluciones innovadoras a problemas
complejos en ambientes globales competitivos, ya sea dentro del ámbito
empresarial / institucional o autónomos.
1
Cloud computing for big data from biomedical sensors monitoring, storage and analyze. Maria,
Server. 2018 - 2019
2
Analysis of cloud computing delivery architecture models. Bojanova & Samba. 2018 - 2019.
14
A través de la investigación realizada por los autores de este documento y con base
a los trabajos de grado de la facultad de Ingeniería de Sistemas existentes en la
Biblioteca Néstor Grajales López, de la Unidad central del valle del cauca, se
identificó algunos que contienen soluciones las cuales requieren una gran
infraestructura de cómputo para su implementación, por tal motivo fueron
archivados y no se encuentran desplegados en las instalaciones de la UCEVA.
Teniendo en cuenta lo anterior, se realizará un estudio mediante el cual se logre

brindar a los estudiantes de ingeniería de Sistemas una solución innovadora la cual
permita desplegar nuevos proyectos que requieran infraestructura robusta, en el
caso de los proyectos de investigación que siempre se encuentren disponibles para
su constante crecimiento y respecto a los trabajos de grados concluirlos con
facilidad y que no queden relegados en la Biblioteca Néstor Grajales López.
A continuación, se listan proyectos que requieren infraestructura de despliegue los

cuales generan muchos datos que pueden ser información valiosa si se analizan
con herramientas adecuadas que logren hacer predicciones o perfiles de consumo,
las cuales tendrían un mayor aprovechamiento y utilización en el tiempo siendo la
computación en la nube la respuesta al procesamiento y análisis de datos que se
requiere.
Tabla 1 - Listado de proyectos de investigación y trabajos de grado que requieren

procesamiento masivo de datos.
Proyecto Estado Tipo Programa

Implementación de la tecnología Terminado Trabajo de Ingeniería
zigbee en el cultivo del maíz. Grado Electrónica
Diseño e implementación de un Terminado Trabajo de Ingeniería

sistema prototipo para el Grado Electrónica
registro y control de equipos de
laboratorio, basado en Rifd y
Zigbee
Diseñar un sistema IoT para En curso Investigación Ingeniería
controlar el cultivo de maíz en la de
granja agroecológica de la Sistemas
UCEVA.
Diseño e implementación de un En curso Trabajo de grado Ingeniería
sistema prototipo de Electrónica
localización para distancias
cortas utilizando redes de
sensores inalámbricas
15
Valoración colaborativa de Terminado Investigación Ingeniería
procesos de contratación de
pública en el marco del libre Sistemas
acceso a la información
Fuente: Biblioteca Néstor Grajales López.
Ilustración 1 – Estado actual Trabajos de Grado en estudiantes de Ingeniería de

Sistema y Electrónica UCEVA.
Fuente: Los Autores.
Estadísticamente se observa en la Ilustración que el 88,89% de los trabajos de

Grados realizados por los estudiantes de Ingeniería de Sistemas y Electrónica
UCEVA que necesitan procesamiento de datos se encuentran archivados, debido a
factores económicos que no permiten la adquisición de infraestructura para
implementar un servidor propio.
1.1.2. PREGUNTA DE INVESTIGACIÓN
¿Cómo se puede resolver la necesidad de procesar y almacenar los datos

generados en la ejecución de proyectos de grado y/o semilleros de investigación en
los estudiantes de Ingeniería de Sistemas de la UCEVA?
16
1.2 JUSTIFICACION
Con el creciente uso de las TIC se están generando altos volúmenes de datos que
pueden servir a investigadores, a la industria y las universidades para mejorar los
diferentes servicios y procesos que se relacionan con las actividades humanas
como lo son el monitoreo de cultivos o las redes de sensores 3. Para poder
almacenar esta información sin tener que invertir grandes sumas de dinero en la
infraestructura de comunicaciones, los servicios que ofrece la computación en la
nube se convierte en una excelente alternativa que además de almacenar, también
permite procesar los datos. Es por esto que la integración de la computación en la
nube con las tecnologías de monitoreo como las redes de sensores inalámbricas
son un desafío que está siendo estudiado en diferentes países (India, Brasil,
E.E.U.U, China, Colombia) y más ahora que son dos de los elementos claves para
el conocido Internet de las Cosas, en donde se quiere conectar y controlar diferentes
dispositivos a lo largo del planeta.
Ilustración 2 – Esquema justificación proyecto.
En la UCEVA, existe variedad de proyectos de software (Ver Tabla 1. Listado de

proyectos de investigación y trabajos de grado que requieren procesamiento masivo
de datos) que se centran en campos como la ingeniería de sistemas o Electrónica
los cuales se ejecutan localmente. Estos proyectos actualmente no se encuentran
en funcionamiento, debido a que necesitan una infraestructura física (Ver
ilustración 3. Coste de servidor físico); esta infraestructura generalmente tiene un
alto coste en Hardware, Software, arrendamientos (Ver ilustración 4. Servicio de
servidor en la nube) y servicios públicos, lo que hace que sea poco asequible para
3
Orlando, O y Juan, R. Diseño de un sistema basado en IOT para controlar el cultivo de maíz en la
granja agroecológica de la UCEVA. 2019.
17
los estudiantes de Ingeniería de Sistemas UCEVA. La tecnología Cloud Computing
es una excelente alternativa que está cambiando la perspectiva de los servicios en
Internet, con la promesa de servicios de Infraestructura, Plataforma y software más
baratos y flexibles.
Ilustración 3 – Coste de servidor físico.
Fuente: DELL. Servidor en torre PowerEdge T140. (DELL, 2019)
18
Ilustración 4 – Servicio de servidor en la nube.
Fuente: Godaddy. Hosting de servidor dedicado. (Godaddy, 2019)
Por ello la necesidad de Implementar una Cloud Computing privada pueda ofrecer
servicios de Plataforma (PaaS) para los estudiantes de Ingeniería de Sistemas
UCEVA que proporcione medios para desarrollar aplicaciones que permitan analizar
los datos recolectados en sus diferentes trabajos o investigaciones y desplegarlas
para administrarlas, obtener información de forma remota que permita la toma de
decisiones o publicación de datos.
19
1.3 OBJETIVOS
1.3.1 General
Diseñar e implementar una plataforma Cloud Computing basada en herramientas

Open Source para ofrecer servicios de Plataforma (PaaS) a los estudiantes de
Ingeniería de Sistemas UCEVA.
1.3.2 Específicos
 Diseñar e implementar la infraestructura de computo a nivel Hardware de la

plataforma Cloud Computing.
 Instalar en la infraestructura de computo implementada, los paquetes de
Software de plataforma Cloud Computing para ofrecer servicios PaaS
realizando las configuraciones y pruebas que sean requeridas.
 Crear un prototipo funcional aprovechando las herramientas ofrecidas por el
PaaS, que permita el análisis de datos en la Cloud Computing.
20
1.4 ALCANCE
 Diseñar e implementar un prototipo de la plataforma Cloud Computing

privada para ofrecer servicios de Plataforma (PaaS) a los estudiantes del
programa de Ingeniería de Sistemas UCEVA que permita acceso en tiempo
real a las aplicaciones migradas a dicho servicio adquirido.
 Desplegar en la plataforma Cloud Computing privada imágenes pre-

configuradas para crear instancias con herramienta de desarrollo para los
estudiantes de Ingeniería de Sistemas.
21
2. CAPÍTULO II - MARCO REFERENCIAL
2.1 MARCO TEÓRICO
El marco teórico que se desarrolla a continuación, permite conocer los conceptos

básicos necesarios para el entendimiento del desarrollo de este proyecto.
2.1.1 SISTEMAS OPERATIVOS
Un sistema operativo es un programa que administra el hardware de una

computadora. También proporciona una base para los programas de aplicación y
actúa como un intermediario entre el usuario y el hardware de la computadora. Un
aspecto sorprendente de los sistemas operativos es la forma en que varían al
realizar estas tareas. Los sistemas operativos de mainframe están diseñados
principalmente para optimizar la utilización del hardware. Los sistemas operativos
de computadora personal (PC) admiten juegos complejos, aplicaciones de negocios
y todo lo demás4. Los sistemas operativos para computadoras portátiles
proporcionan un entorno en el que un usuario puede interactuar fácilmente con la
computadora para ejecutar programas. Por lo tanto, algunos sistemas operativos
están diseñados para ser convenientes, otros para ser eficientes, y otros para ser
una combinación de los dos.
Ilustración 5 - Vista abstracta de los componentes de un sistema informático.
Un sistema informático se puede dividir aproximadamente en cuatro componentes:

el hardware, el sistema operativo, los programas de aplicación y los usuarios
4
Silberschatz, G. Operating System Concepts. 2018 – 2019.
22
(Ilustración 5). El hardware, la unidad de procesamiento central (CPU), la memoria
y los dispositivos de entrada / salida (E / S), proporciona los recursos informáticos
básicos para el sistema. Los programas de aplicación, como los procesadores de
texto, las hojas de cálculo, los compiladores y los navegadores web, definen las
formas en que estos recursos se utilizan para resolver los problemas informáticos
de los usuarios. El sistema operativo controla el hardware y coordina su uso entre
los diversos programas de aplicación para los distintos usuarios. También podemos
ver un sistema de computadora que consiste en hardware, software y datos. El
sistema operativo proporciona los medios para el uso adecuado de estos recursos
en el funcionamiento del sistema informático. Un sistema operativo es similar a un
gobierno. Al igual que un gobierno, no realiza ninguna función útil por sí mismo.
Simplemente proporciona un entorno dentro del cual otros programas pueden hacer
un trabajo útil.
2.1.2 MÁQUINA VIRTUAL
Una máquina virtual (acrónimo VM) es un programa de software o sistema operativo

que no solo muestra el comportamiento de una computadora separada, sino que
también es capaz de realizar tareas como ejecutar aplicaciones y programas como
tal. Una máquina virtual, generalmente conocida como un invitado, se crea dentro
de otro entorno informático denominado "host". Pueden existir múltiples máquinas
virtuales dentro de un único host a la vez. Existen diferentes proveedores de
software para VM tales como VirtualBox de
5
Oracle y Workstation Pro de VMWare .
2.1.3 SISTEMAS DISTRIBUIDOS
Un Sistema Distribuido es aquel en el que los componentes hardware o software,

localizados en computadoras unidas mediante red, comunican y coordinan sus
acciones sólo mediante paso de mensajes.
Las computadoras que están conectadas mediante una red pueden estar separados
espacialmente por cualquier distancia. Pueden estar en condiciones distintas, en el
mismo edificio o en la misma habitación6.
2.1.4 CLÚSTER COMPUTING
Clúster Computing se define como una colección de computadoras distribuidas o

paralelas que están interconectadas entre sí utilizando redes de alta velocidad,
como Gigabit Ethernet, SCI, Myrinet e Infiniband. Trabajan juntos en la ejecución de
tareas de uso intensivo de datos e informática que no serían factibles de ejecutar
en una sola computadora. Los clústeres se utilizan principalmente para alta
5
Philippe, G. Virtualización des sistemas de información con VMware. 2018 – 2019.
6
Coulouris, Kindberg. Sistemas Distribuidos: Conceptos y Diseño. 2018 – 2019.
23
disponibilidad, equilibrio de carga y para fines informáticos. Se utilizan para fines de
alta disponibilidad ya que mantienen nodos redundantes que se utilizan para
proporcionar servicio cuando los componentes del sistema fallan. El rendimiento del
sistema se mejora aquí porque incluso si un nodo falla, hay otro nodo en espera que
llevará a cabo la tarea y eliminará los puntos únicos de falla sin ningún impedimento.
Cuando se conectan varias computadoras juntas en un clúster, comparten la carga
de trabajo computacional como una sola computadora virtual. Desde el punto de
vista de los usuarios, son máquinas múltiples, pero funcionan como una sola
máquina virtual. La solicitud del usuario se recibe y se distribuye entre todas las
computadoras independientes para formar un clúster. Esto da como resultado un
trabajo computacional equilibrado entre diferentes máquinas, mejorando el
rendimiento de los sistemas de clúster. A menudo, los clusters se utilizan
principalmente con fines computacionales, que el manejo de actividades basadas
en IO7.
Durante muchos años, el superordenador fue el líder en el campo de la informática.

Pero debido a algunos de los problemas enfrentados en el área de la ciencia, la
ingeniería y los negocios, que no podrían abordarse de forma efectiva mediante el
uso de superordenadores. Fueron reemplazados por clusters con el objetivo de
superar estos problemas y también ofrecieron una forma muy barata de obtener
acceso a un potencial informático potencialmente enorme.
2.1.5 GRID COMPUTING
Grid computing se define como un tipo de sistema paralelo y distribuido que permite
el intercambio, la selección y la agregación de recursos autónomos distribuidos
geográficamente de forma dinámica en tiempo de ejecución en función de su
disponibilidad, capacidad, rendimiento, costo y requisitos de calidad de servicio para
los usuarios8.
Grid computing combina computadoras de múltiples dominios administrativos para

alcanzar un objetivo común (resolver una sola tarea), y luego puede desaparecer
con la misma rapidez. Es análogo a la red eléctrica. Una de las estrategias
principales de Grid computing es usar middleware para dividir y distribuir piezas de
un programa entre varias computadoras. La Grid computing implica el cómputo de
una manera distribuida, que también puede implicar la agregación de sistemas
basados en computación en clúster a gran escala. El tamaño de una Grid computing
puede variar desde una pequeña red de estaciones de trabajo informáticas dentro
de una corporación hasta grandes colaboraciones en muchas empresas y redes 9.
7
R, Buyya. Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering
computing as the 5th utility. Future Generation Computer Systems. 2018 - 2019.
8
Ian, F. Yong, Z. Ioan, R. Shiyong, L. Cloud Computing and Grid Computing 360-Degree Compared.
2018 – 219.
9
R, Buyya. Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering
computing as the 5th utility. Future Generation Computer Systems. 2018 - 2019.
24
2.1.6 CLOUD COMPUTING
Cloud computing o computación en la nube hace referencia tanto a las aplicaciones

entregadas como servicios a través de Internet como al hardware y software del
sistema en los centros de datos que brindan esos servicios.
Cloud computing es un tipo de sistema paralelo y distribuido que consiste en una

colección de computadoras virtualizadas e interconectadas que se aprovisionan
dinámicamente y se presentan como uno o más recursos informáticos unificados
basados en el acuerdo de nivel de servicio. Cloud computing es un modelo que
permite acceso de red ubicuo, conveniente y bajo demanda a un grupo compartido
de recursos informáticos configurables (por ejemplo, redes, servidores,
almacenamiento, aplicaciones y servicios) que pueden aprovisionarse y lanzarse
rápidamente con un mínimo esfuerzo administrativo o la interacción del proveedor
de servicios. La computación en la nube proporciona básicamente tres tipos de
servicio:
Software como servicio (SaaS), plataforma como servicio (PaaS) e infraestructura

como servicio (IaaS).
 SaaS es un tipo de servicios en el que muchos usuarios pueden hacer uso

del software alojado por el proveedor del servicio y pagar solo por el tiempo
que lo utilizan. Será mejor que comprar el hardware y el software, ya que
evita la carga de actualizar el software a la última versión, la licencia y, por
supuesto, es más económico10. Algunos ejemplos de proveedores de
servicios son Salesforce, el sistema de gestión de relaciones con el cliente
(CRM) y Google Apps.
 PaaS proporciona un entorno integrado de alto nivel para diseñar, construir,

probar, implementar y actualizar aplicaciones personalizadas en línea11.
Algunos ejemplos de proveedores de servicios son Google App Engine,
Microsoft Azure, RightScale y SalesForce.
 IaaS se refiere a los servicios proporcionados a los usuarios para utilizar la

potencia de procesamiento, el almacenamiento, la red y otros recursos
informáticos, para ejecutar cualquier software, incluidos los sistemas
operativos y las aplicaciones. Algunos de los proveedores de IaaS son AWS,
Eucalyptus, OpenStack, GoGrid y Flexiscale12.
10
Michael, K. Architecting the Cloud: Design Decisions for Cloud Computing Service Model: SaaS,
PaaS, IaaS. 2018 – 2019.
11
Matthew, S. Sarhan, M. Omonowo, D. Cloud Computing: Opportunities and Challenges. 2018 –
2019.
12
Armbrust, Jhosef. Above the clouds: A Berkeley view of cloud computing. 2018 - 2019
25
2.2 ESTADO DEL ARTE
2.2.1 INTRODUCCIÓN Y DEFINICIÓN
La evolución de los computadores se ha venido en incremento mejorando

constantemente su arquitectura desde los años 70, estos avances han permitido
mejorar significativamente los primeros modelos de microprocesadores, apropiando
técnicas como el multithreading, predicción dinámica de saltos y la planificación
dinámica de instrucciones. Esto ha permitido grandes avances en diferentes áreas
como la agricultura, la astronomía, la medicina entre otras, pero cada estudio
conlleva exorbitante cantidad de datos, y el procesarlo se vuelve una tarea muy
costosa donde el rendimiento y almacenamiento pueden llegar a ser un
inconveniente. Dada la evolución de los sistemas distribuidos hacia el paradigma
Grid, se vieron interesadas compañías como GOOGLE, AMAZON e IBM, ya que
era una tecnología fácilmente escalable lo cual era muy bien recibido dando paso a
nuevos horizontes, es decir, tener la capacidad de ofrecer servicios de cómputo y
almacenamiento a usuarios u otras compañías permitiendo acceder a estos
recursos de manera remota para la realización de tareas complejas13.
La NIST (National Institute of Standards and Technology) define la Cloud Computing

como un modelo tecnológico que permite el acceso remoto, y la administración de
recursos compartidos a través de la red como servidores, aplicativos, redes y
equipos de almacenamiento de los cuales pueden ser rápidamente suministrados y
liberados minimizando el costo de gestión y la interacción que se debe mantener
con el proveedor del servicio14.
Según IBM, Cloud Computing es un modelo de aprovisionamiento rápido de

recursos IT que potencia la prestación de servicios, facilitando la operativa del
usuario final y del prestador del servicio. Además, todo ello se realiza de manera
fiable y segura, con una escalabilidad elástica que es capaz de atender fuertes
cambios en la demanda no previsibles a priori, sin que esto suponga apenas un
incremento en los costes de gestión15.
2.2.2 CARACTERÍSTICAS DE LA CLOUD COMPUTING
La principal característica por la que se destaca la Cloud Computing es el consumo

de servicios como infraestructura, plataforma y/o aplicaciones a los cuales se
pueden obtener mediante internet sin que el usuario tenga conocimiento de cómo
suceden estos procesos, además de ella, se pueden encontrar las siguientes
características16:
13
Pardo, M.B. Cloud Computing tecnología y negocio. 2018 – 2019.
14
Miralles. Cloud computing y protección de datos. 2018 – 2019.
15
Rodríguez, Murazzo. Arquitectura de Cloud Computing Hibrida basada en tecnología Open
Sourse. 2018 – 2019.
16
Valdéz, J. Cómputo en la nube. 2018 – 2019.
26
2.2.2.1 Autoservicio a la carta
El usuario puede ampliar recursos consumibles de manera automática como lo son
el almacenamiento y procesamiento, sin la necesidad de pedirlo a su proveedor de
servicio17.
2.2.2.2 Amplio acceso a la red

Disponibilidad de acceder desde cualquier parte del mundo a través de cualquier
dispositivo como teléfonos celulares, computadores portátiles entre otros conectado
a la red18.
2.2.2.3 Reservas de recursos en común

Aquellos recursos que son proporcionados por el proveedor son de uso compartido,
y son usados según la demanda de los usuarios, esto hace una referencia al modelo
de multiposesion, donde se interactúa con recursos físicos y virtuales que son
reasignados a cada uno de los consumidores. Algunos ejemplos de recursos son:
almacenamiento, procesamiento, memoria, ancho de banda de red y máquinas
virtuales19.
2.2.2.4 Rapidez y elasticidad

La Cloud computing tiene la capacidad de suministrar recursos que han sido
pedidos por el consumidor de manera inmediata y elástica hacen parecer como
recursos ilimitados y es posible adquirir cualquier cantidad de recursos en cualquier
momento. Según el caso se realiza de manera automática, para mayor eficiencia en
el redimensionado correspondiente a la petición, por parte del consumidor20.
2.2.2.5 Servicio supervisado

Los recursos que posee la Cloud Computing son monitoreados, con el fin de mostrar
transparencia en la administración de recursos tanto para el consumidor como para
el proveedor. La monitorización permite optimizar la utilización de los mismos como
el almacenamiento, procesamiento, ancho de banda etc21.
2.2.3 ARQUITECTURA DE LA CLOUD COMPUTING
La arquitectura de la Cloud Computing contiene ciertos elementos los cuales

siempre se encuentran en los diferentes tipos de Cloud Computing como el nivel de
17
Luis, A. COMPUTACIÓN EN LA NUBE Notas para una estrategia española en Cloud Computing.
2018 – 2019.
18
MARIA A. ANÁLISIS DE UNA INFRAESTRUCTURA CLOUD OPEN SOURCE. 2018 – 2019.
19
Julio, T. LEX CLOUD COMPUTING. 2018 – 2019.
20
Julio, T. LEX CLOUD COMPUTING. 2018 – 2019.
21
David, C. Cloud Computing: retos y oportunidades. 2018 – 2019.
27
virtualización, el almacenamiento escalable, mecanismos de administración de
múltiples clientes y APIS Web22.
La capacidad de virtualizar servidores y el almacenamiento es el eje fundamental

de su arquitectura, ya que optimiza la agilidad de la Cloud Computing. Gracias a la
virtualización, el proveedor puede realizar cambios de aprovisionamiento a la Cloud
Computing de manera sencilla en caso de que se necesite, o la eliminación de
infraestructura que no se esté utilizando.
El almacenamiento escalable, es una característica distintiva de la Cloud Computing

utilizando diversas tecnologías para el aprovechamiento de varios grupos de
componentes de almacenamiento dependiendo de la demanda de los consumidores
enfocados en la infraestructura y recursos de almacenamiento.
Los mecanismos que permitan admitir varios usuarios al mismo tiempo, es un

servicio de la Cloud Computing que debe permitir la utilización de recursos
compartidos tanto físicos o virtuales y ser capaz de realizar un seguimiento del uso
del servicio por consumidor. Este servicio es una característica que poseen las
Cloud Computing privadas, publicas e hibridas.
Las APIS Web es otro elemento clave en la arquitectura de la Cloud Computing, ya

que es un conjunto de estándares sobre los cuales trabaja la Cloud Computing como
HTTP, RESTful, XML, SOAP entre otros, estos estándares permiten que los
servicios que ofrecen los proveedores estén disponibles a través de un navegador
web.
Los nodos básicos que debe tener una Cloud Computing para prestar sus servicios
pueden variar en cantidad dependiendo de cómo se desea configurar,
principalmente se deben tener los siguientes:
2.2.3.1 Nodo controlador

Se encarga de hacer la interacción con el usuario y hace el rol de puente para la
comunicación con los demás nodos, la gran mayoría de servicios de nube se
instalan en este nodo23.
2.2.3.2 Nodo de cómputo

Se encarga de la administración de instancias de máquinas virtuales24.
22
Arquitectura de la Cloud Computing. https://www.akamai.com/es/es/resources/cloud-computing-
architecture.jsp. 2018 – 2019.
23
Antonio, C. Despliegue de arquitectura Cloud basada en OpenStack y su integración con Chef
sobre CentOS. 2018 – 2019.
24
OpenStack. Overview. https://docs.openstack.org/install-guide/overview.html#compute. 2018 –
2019.
28
2.2.3.3 Nodo de almacenamiento
Se encarga de gestionar y almacenar las instancias e imágenes25.
2.2.3.4 Nodo de red

Se encarga de ejecutar los servicios de red, tal como proporcionar una dirección IP
a una instancia de Nova de arranque26.
2.2.4 TIPOS DE CLOUD COMPUTING
De acuerdo con la definición de NIST, existen cuatro tipos de Cloud Computing para
su implementación que se encargan de la infraestructura: Pública, Privada,
Comunitaria e Híbrida.
El Modelo Público, es uno de los principales modelos de Cloud Computing que se

puede ver en el mercado, ya que su principal característica es permitir al consumidor
acceder a servicios desde cualquier lugar a través de cualquier dispositivo
conectado a la red. Además, se encuentra el modelo privado es similar al modelo
público, pero la infraestructura y/o recursos son propios del consumidor, lo cual da
total control sobre la Cloud Computing y permite adaptar la calidad de servicio y
seguridad según lo necesite, también se existe el modelo híbrido, el cual es la
combinación entre los modelos públicos y privados, su principal ventaja consiste en
el aumento de la capacidad de una Cloud Computing privada con recursos de una
Cloud Computing pública obteniendo un mejor servicio, administrando la carga de
trabajo. Por último, se encuentra el modelo comunitario, el cual está orientado a la
comunidad, con la facilidad de compartir su infraestructura entre diferentes
organizaciones apuntando a un interés en común27.
El modelo SPI en que se basa la Cloud Computing hace referencia a los 3 tipos de
servicios que puede ofrecer una Cloud Computing, es decir, Software, plataforma e
infraestructura, estos servicios son consumidos dependiendo de la demanda que
tengan los usuarios.
25
OpenStack. Overview. https://docs.openstack.org/install-guide/overview.html#compute. 2018 –
2019.
26
Antonio, C. Despliegue de arquitectura Cloud basada en OpenStack y su integración con Chef
sobre CentOS. 2018 – 2019.
27
Aguilar, L. NUBE Notas para una estrategia. 2018 – 2019.
29
2.2.5 SERVICIOS DE CLOUD COMPUTING
2.2.5.1 Software como servicio (SaaS)

El servicio SaaS (Software as a Service) se encarga de proporcionar aplicaciones
que se encuentren en la Cloud Computing con el fin de ser consumidas por el
usuario a través de un cliente ligero desde cualquier tipo de dispositivo, donde el
consumidor no tiene acceso a la infraestructura o preocuparse por el
almacenamiento que pueda necesitar mediante un aplicativo. Un ejemplo Gmail28.
2.2.5.2 Plataforma como servicio (PaaS)

El servicio PaaS (Platform as a Service) se encarga de ofrecer un ambiente de
desarrollo para el consumidor, utilizando el lenguaje de programación y los APIs
(Application Programming Interface) definidos por el proveedor. El consumidor
cuando desarrolla sus propias aplicaciones son orientadas directamente a la Cloud
Computing, con la capacidad de controlar las configuraciones de entorno del hosting
de las aplicaciones y sin la necesidad de preocuparse que tanta infraestructura
ocupe el despliegue de las aplicaciones como redes, sistemas operativos,
almacenamiento, procesamiento etc. Un ejemplo Google App29.
2.2.5.3 Infraestructura como servicio (IaaS)

El servicio IaaS (Infrastructure as a Service) se encarga de ofrecer al consumidor la
administración y la obtención de recursos compartidos como procesamiento,
almacenamiento, redes entre otros recursos computacionales, para que el
consumidor pueda incluir aplicaciones, sistemas operativos, máquinas virtuales u/o
software de su elección al realizar el despliegue. Un ejemplo Amazon Web
Service30.
28
Michael, K. Architecting the Cloud: Design Decisions for Cloud Computing Service Model: SaaS,
PaaS, IaaS. 2018 – 2019.
29
Carlos, M. Procesamiento de grandes volúmenes de datos en entornos Cloud Computing utilizando
Hadoop MAPREDUCE. 2018 – 2019.
30
María, M. Despliegue de una Infraestructura Cloud Privada de Código Abierto. 2018 – 2019.
30
2.2.6 PIONEROS DE LA CLOUD COMPUTING
Aproximadamente en el año 1961, John McCarthy fue la primera persona que

sugirió públicamente que la tecnología de tiempo compartido (Time Sharing) de las
computadoras podría utilizarse para prestar un servicio, fue tiempo después en 1999
que Salesforce.com introdujera el concepto de consumir aplicaciones empresariales
a través de la red utilizando una página web. En el 2002 Amazon fue el siguiente en
lanzar sus servicios con Amazon Web Service el cual se ve hoy en la actualidad
como uno de los proveedores de servicios punteros a nivel mundial, además en el
2006 presentó a Elastic Compute Cloud como un servicio web comercial el cual
permitió que microempresas y empresas medianas pudieran consumir el servicio de
correr sus propias aplicaciones. En el 2005 OpenNebula lanzó el primer software de
código abierto el cual era orientado a nubes privadas e híbridas. Windows Azure
salió en el año 2009 por Microsoft, después en el 2010 se implementaron las capas
de servicios como cliente, aplicación, infraestructura, plataforma y servidor. Apple
en 2011, sacó al mercado un sistema de almacenamiento en la nube, dirigido a los
consumidores para el almacenamiento de documentos, música, videos, fotografías
y aplicaciones31.
2.2.7 REVISIÓN DE PROVEEDORES
2.2.7.1 Amazon Web Service (AWS)

Plataforma segura de servicios en la nube que ofrece potencia de cómputo,
almacenamiento de bases de datos, entrega de contenido y otras funcionalidades
para ayudar a las empresas a ajustar su escala y crecer32.
2.2.7.2 Microsoft Azure

Microsoft Azure es un conjunto en constante expansión de servicios en la nube para
ayudar a su organización a satisfacer sus necesidades comerciales. Le otorga la
libertad de crear, administrar e implementar aplicaciones en una red mundial
enorme con sus herramientas y marcos favoritos33.
2.2.7.3 Google Cloud

Google Cloud es una plataforma creada por Google la cual agrupó a todas las
aplicaciones de desarrollo web las cuales estaban ofreciendo por esta empresa.
Con la finalidad de recuperar el terreno perdido frente a otros proveedores como
Amazon, por su entrada tardía en un sector clave dentro del negocio del Cloud
Computing como es el IaaS, el gigante de los buscadores ha organizado sus
servicios core de Cloud Computing en una misma plataforma, dotando al sistema
de más cohesión y ofreciendo una mayor homogeneidad en el uso de los servicios
31
Valencia, Cruz. Historia Del Cloud Computing. 2018 – 2019.
32
Felipe, V - Diego, B. Diseño de selección de una plataforma Cloud Computing. 2018 – 2019.
33
Will, B. Cloud Architecture Patterns: Using Microsoft Azure. 2018 – 2019.
31
como: Google App Engine, Google Cloud Storage, Google Compute Engine, Google
Cloud SQL etc34.
2.2.8 CUADRO COMPARATIVO JUSTIFICANDO LA ELECCIÓN DE

OPENSTACK PARA CONFIGURAR LA CLOUD QUE OFRECE
PLATAFORMA DE SERVICIO.
Para este estudio se realizó un cuadro comparativo entre cada una de las
plataformas OPEN SOURCE que se encuentran en el mercado y de las cuales se
puede instalar de forma local o pública haciendo algún convenio con algún
proveedor de computación ya mencionado en este documento. Para realizar el
cuadro comparativo se tuvo en cuenta los requerimientos de infraestructura mínimos
para poder realizar la instalación de la nube. En la Ilustración 6, se pueden
observar las siguientes plataformas: OpenNebula, OpenStack, Eucalyptus y
CloudStack. Estas plataformas fueron comparadas con criterio tales como
compatibilidad con nodos virtualizados, lenguajes de programación que conforman
el funcionamiento de la nube, requisitos de hardware, código libre (OpenSourse) e
Interface vía API, Web y SSH. El estudio reflejó que la plataforma más antigua es
OpenNebula ya que sus inicios parten desde 2005 a diferencias de sus
competidores como lo son Eucalyptus en el 2008, OpenStack y CloudStack en el
201035.
34
Yavuz, Y. Bahadir, A. Murat, D. Google Cloud Messaging (GCM): An Evaluation. 2018 – 2019.
35
32
Ilustración 6 – Cuadro comparativo de las principales Cloud Computing OpenSource.
33
2.2.8.1 OpenNebula
OpenNebula es una plataforma que tiene una larga trayectoria, se determinó que
no se utilizaría ya que dejó de producir actualizaciones a partir del 2010 lo cual la
descalifica ya que no sería viable ya que podría no dar soporte en caso de que se
esté poniendo una nube en producción, algo a destacar es que OpenNebula es una
plataforma que puede ser pública, privada e híbrida lo cual lo hacía un gran
candidato36.
2.2.8.2 Eucalyptus
Eucalyptus es una plataforma que puede ser privada e híbrida, pero para poder
instalar dicha plataforma se requieren infraestructura física de la cual no se cuenta
por el momento y esto hace complicado a la hora de realizar la instalación37.
2.2.8.3 CloudStack
CloudStack es una plataforma que requiere la menor infraestructura entre los
candidatos lo cual lo hace una buena opción, el único inconveniente es que solo
ofrece interface de acceso a usuarios vía web lo cual lo hace más lento en tiempo
de ejecución en comparación con SSH y API38.
2.2.8.4 OpenStack
OpenStack es una plataforma completa, su última actualización fue implementada
el 10 de abril del 2019 en su versión Rocky, aproximadamente el 16 de octubre del
2019 lanzará su versión Train lo cual lo hace más reciente para el soporte de la
misma, para el montaje se puede realizar con máquinas virtuales, lo que hace más
fácil a la hora de requerir equipos de gran potencia y realizar fácilmente la
redundancia de nodos39.
OpenStack actualmente se encuentra liderando el mercado de la nube privada y

pública, siendo respaldada por más de 500 empresas, donde las más importantes
en la industria de la Cloud Computing se encuentran MS, Oracle, VMWare,
Ericsson, HP, IBM, Juniper, Cisco, procaces, F5 y SAP. Las razones por la cual se
encuentran apoyando esta plataforma es la capacidad de construcción de funciones
de red y su estándar como nube publica/privada, permitiendo la creación de
múltiples nodos los cuales pueden ser implementados en máquinas virtuales,
demostrando su capacidad de sostenibilidad y escalabilidad en producción, por
estas razones se eligió para el proyecto la plataforma OpenStack.
36
Scielo. Arquitectura de Referencia para el diseño y despliegue de Nubes Privadas.
http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1815-59282015000100001. 2018 – 2019.
37
38
39
OpenStack. Open source software for creating private and public clouds.
https://www.openstack.org. 2018 – 2019.
34
3. CAPÍTULO III – METODOLOGÍA DE LA INVESTIGACIÓN
3.1 DEFINICIÓN DE LA INVESTIGACIÓN
3.1.1 TEMA
En este trabajo se realiza el estado del arte de la tecnología Cloud Computing Open
Source y se configura la infraestructura Cloud Computing para ofrecer servicio de
plataforma a los estudiantes de ingeniería de Sistemas de la UCEVA.
3.1.2 TIPO DE INVESTIGACIÓN
La investigación, se encuentra centrada en el sondeo de las diferentes plataformas

Cloud Computing Open Source más usadas en el mercado y para ello la
investigación se realizará de tipo descriptiva, realizando una comparación entre
cada plataforma y escogiendo la que se adapte a las necesidades de los estudiantes
de ingeniería de Sistemas, UCEVA.
Para desarrollar el trabajo de grado y tomando la investigación descriptiva de base,

se puede concluir que tiene un enfoque cualitativo que “utiliza la recolección y
análisis de los datos para afinar las preguntas de investigación o revelar nuevas
interrogantes en el proceso de interpretación”40.
“El enfoque cualitativo también se guía por áreas o temas significativos de

investigación. Sin embargo, en lugar de que la claridad sobre las preguntas de
investigación e hipótesis preceda a la recolección y el análisis de los datos (como
en la mayoría de los estudios cuantitativos), los estudios cualitativos pueden
desarrollar preguntas e hipótesis antes, durante o después de la recolección y el
análisis de los datos. Con frecuencia, estas actividades sirven, primero, para
descubrir cuáles son las preguntas de investigación más importantes; y después,
para perfeccionarlas y responderlas. La acción indagatoria se mueve de manera
dinámica en ambos sentidos: entre los hechos y su interpretación, y resulta un
proceso más bien “circular” en el que la secuencia no siempre es la misma, pues
varía con cada estudio”41
A continuación, se intenta representarlo en la Ilustración 5, pero cabe señalar que

es simplemente eso, un intento, porque su complejidad y flexibilidad son mayores.
40
Dalgleish, et. Metodología de la investigación. 2018 – 2019.
41
Dalgleish, et. Metodología de la investigación. 2018 – 2019.
35
Ilustración 7 – Proceso cualitativo.
Fuente: Dalgleish et al. 2017.
3.1.3 Alcance de la investigación
El alcance de la investigación va regulado por la consulta bibliográfica de las

diferentes plataformas Cloud Computing Open Source más usadas en el mercado
actual, clasificación e informe final de los resultados.
3.1.4 Técnica de recolección de datos
La recolección de datos para el desarrollo de la investigación se apoya en la

búsqueda de información en ensayos, artículos científicos y contenidos de la red
informática Mundial (World wide web) de sitios bien referenciados.
36
3.2 PREPARACIÓN DE LA INVESTIGACIÓN
3.2.1 Justificar la investigación
El desarrollo de la investigación se realizará mediante la recolección de información

vía internet como lo son fuentes primarias, base de datos, libros y revistas
indexadas, debido a que actualmente la UCEVA no cuenta con material investigativo
acerca del tema de investigación, no existe recopilaciones en su base de datos y
biblioteca debido a que esta tecnología es reciente, además no cuenta con
profesionales especializados sobre este campo de la computación para dar
soluciones a los contratiempos que se tendrán en el trascurso de la investigación.
3.2.2 Recolectar datos
Para la recolección de datos sobre las diferentes Plataformas Cloud Computing

Open Source se realizará un filtro por las siguientes características:
 Tipo de Virtualización: Que herramienta dispone para recrear a través de

software recursos de hardware y SO.
 Lenguajes de programación: Define los lenguajes programación que
soporta para su despliegue.
 Sistema Operativo: Indica bajo qué Sistema operativo se va alojar la
plataforma Cloud Computing.
 Procesamiento (CPU): Indica el requisito mínimo de CPU que necesita cada
nodo para su funcionamiento.
 Memoria RAM: Indica el requisito mínimo de RAM que necesita cada nodo
para su funcionamiento.
 Almacenamiento: Indica el requisito mínimo de Disco duro que necesita
cada nodo para su funcionamiento.
 Maquinas físicas/virtuales: Especifica si la infraestructura de la Cloud
Computing se debe implementar en máquinas físicas o virtualizadas.
 Implementación: Si tiene soporte para usarse como Cloud Computing
Pública, Privada o Hibrida.
37
4. CAPITULO IV. DISEÑO E IMPLEMENTACION DE LA INFRAESTRUCTURA
DE COMPUTO DE LA PLATAFORMA CLOUD COMPUTING
4.1 SERVICIOS A IMPLEMENTAR
4.1.1 SERVICIO DE IDENTIDAD (KEYSTONE)
Todos los usuarios y servicios confían en Keystone, sin este servicio ningún usuario
podrá autentificarse, crear instancias, redes u otros recursos en OpenStack, así
también los servicios propios de OpenStack también confían en la autentificación
de Keystone para poder crear las solicitudes de los usuarios42.
El concepto de autenticación y autorización son dos palabras o conceptos que son

muy a menudo se han malinterpretado, una definición correcta de estos términos.
Autentificación es el acto de confirmar la identidad de un usuario específico, en otras
palabras, demostrar que un usuario es quien dice ser, por otro lado, la autorización
es la función de determinar los derechos de acceso para ese usuario específico.
Keystone contiene una variedad de funciones, pero ante todo proporciona
autentificación y todos los usuarios de OpenStack deben autentificarse en Keystone
a través Horizon, la interfaz de línea de comandos o directamente hablando con la
API. Los derechos de acceso de un usuario incluyen la creación o no de un router
virtual en Neutron, crear imágenes de Glance que sean de acceso público. Esta
autorización es manejada por un archivo llamado policy Json y reside en cada
directorio de configuración de cada servicio de OpenStack instalado en un entorno
de producción.
42
Jackson, K. OpenStack cloud computing cookbook. 2018 – 2019.
38
4.1.1.1 Arquitectura de Keystone
Ilustración 8 - Arquitectura de Keystone.
Fuente: Grafico elaborado a partir de https://javieroto.wordpress.com/2018/08/11/4-

openstack-keystone-usuarios-grupos-roles-proyectos-dominios
Keystone es un sistema de autenticación común en toda la nube y por eso recibe

más solicitudes que cualquier otro servicio de OpenStack, desde la versión liberti
OpenStack, el equipo de desarrollo de Keystone pasó a utilizar Apache como
interfaz de API para Keystone. Apache está vinculado al puerto 5000 y es la puerta
de entrada principal a Keystone, todos los servicios confían en Keystone para la
autentificación de usuarios43.
El sistema de administración de bases de datos relacionales en entornos

OpenStack es generalmente MaríaDB y contiene una base de datos de Keystone la
cual almacena todos los datos para todos los diversos recursos de Keystone.
Los demonios son contenedores lógicos de alto nivel utilizados para agrupar a los
usuarios, grupos y los proyectos.
Un proyecto representa un área donde se crean los recursos, los clientes de un

proyecto pueden crear múltiples proyectos según la configuración establecida por
el administrador del proyecto.
Los usuarios son creados para personas individuales en una organización, los
usuarios suelen residir en una base de datos de Keystone, pero posiblemente
podrían vivir en un servidor de Active Directory o LDAP, cada demonio puede
contener cualquier número de usuarios, del mismo modo un usuario puede
pertenecer a más de un proyecto.
43
José, J. Trabajo de Fin de Grado Sistemas de Identidad Federados en Openstack. 2018 – 2019.
39
El rol es simplemente una etiqueta que es aplicado directamente a un usuario a un
grupo, Keystone no tiene nada que ver con la autorización, la autorización es
ejecutada a través de sus ficheros de Json y estos ficheros determinarán que lo que
puede o no puede hacer un usuario.
Los grupos son un concepto en Keystone más nuevo que proporciona una forma
fácil de aplicar un rol existente a múltiples usuarios, son opcionales y se crearon
para optimizar el proceso de aplicar roles al usuario a la vez.
Service catalog o mayormente conocido como endPoints, es un mapa de

almacenamiento en Keystone, el cual contiene una lista de servicios y sus URL
finales, se puede tomar como una guía telefónica de OpenStack, donde esta guía
telefónica proporciona una lista de URL finales para todos los servicios instalados
en el entorno de OpenStack.
4.1.1.2 Service catalog y endpoints
La mayoría de los usuarios y administradores principales de OpenStack Interactúan

indirectamente con las API de servicios de OpenStack a través del panel de control
Horizon o el CLI y puedes ver el catálogo de servicios como una lista de URL
almacenadas en Keystone, está lista muestran las URL de las APIS también
conocidos como endpoint para todos los servicios actualmente instalados en
entornos OpenStack. El administrador de OpenStack es el responsable de publicar
un servicio de OpenStack recientemente instalado para los usuarios del entorno,
una vez que se instala un servicio se debe agregar al catálogo servicios para que
los nuevos usuarios sepan qué servicios están disponibles. Agregar nuevos
servicios y endpoints al catálogo se puede hacer fácilmente a través del cliente de
python OpenStack, el comando (OpenStack catalog list) muestra todos los
endpoints del entorno de OpenStack. Existen 3 URL por cada servicio en el servicio
de catálogos. La URL pública es usada por los usuarios que acceden externamente
a la API, seguido por la URL interna, está es la URL que típicamente es usada por
servicios para la comunicación interna y por último se encuentra el admin, esta URL
se usa para exponer funciones especiales que son exclusivas del administrador
para un servicio, aunque normalmente es la misma URL que la URL Interna, con el
comando (OpenStack catalog list) es posible ver todo el catálogo entero del entorno
de OpenStack.
40
4.1.2 SERVICIO DE IMÁGENES (GLANCE)
Glance es el servicio de imagen de OpenStack, este servicio provee el libre

almacenamiento y registro de todas las imágenes Cloud que se encuentran en el
entorno de OpenStack instalado, las imágenes son almacenadas en una variedad
de Backend llamados almacenes de datos (sistema de archivo local NFC o un
contenedor en Swift). A continuación, se describen áreas de aplicación del servicio
de Glance como lo son las imágenes Cloud, los formatos de ficheros de imágenes
y la arquitectura de Glance.
Para la creación de una instancia directamente en una máquina virtual, se debe

proporcionar el nombre, el tamaño de la memoria RAM, la cantidad de CPUS
virtuales, el tamaño del disco local y una imagen. Las máquinas virtuales no pueden
ejecutarse sin proporcionarles una imagen de un sistema operativo o algún medio
para leer desde el disco local. En el pasado era costumbre descargar un sistema
operativo como un fichero con extensión ISO, este fichero es un archivo único de
disco óptico. El proceso de instalación de un sistema operativo, en este caso una
máquina virtual, implicaba responder y elegir las preguntas básicas que
proporcionaba el asistente de instalación como lo son, la configuración de zona
horaria, administración de usuarios, administración de red entro otros, por ende,
estos procesos conllevan mucho tiempo, donde uno de los propósitos de la nube,
es priorizar la agilidad estos procesos y perder el tiempo en una instalación no es la
idea. En el momento en que se inicia una instancia en el entorno de OpenStack,
siempre se debe proporcionar una imagen de disco almacenada en Glance, la cual
es accedida a través de una petición por medio del servicio de nova, después de
eso, la imagen se coloca en el nodo de cómputo. Estas imágenes han sido
configuradas previamente por una persona, ya sea manualmente o por medio de un
script que haya pasado por el procedimiento de instalación inicial y haya instalado
programas específicos y archivos de configuración que permitan garantizar que sea
compatible con la nube44.
Nota: Las imágenes que se encuentran almacenadas en la nube que contiene

Glance son generalmente instantáneas de los contenidos en disco.
.
4.1.2.1 Diferentes formatos de ficheros de imágenes
Las imágenes de disco almacenan todo el contenido del sistema operativo y vienen
en una variedad de formatos de archivos como lo son45:
44
OpenStack. Image service. https://docs.openstack.org/glance/queens/install/get-started.html.
2018 – 2019.
45
Davod, C. Diseño e Instalación de una infraestructura de nube privada basada en Openstack. 2018
– 2019.
41
4.1.2.1.1 QCOW2 (QEMU Copy-On-Write)
El formato de imagen QCOW2 es uno de los formatos de disco apoyado por QEMU,
el cual se utiliza con el hypervisor QEMU y KVM, su nombre proviene por la
capacidad de optimizar el almacenamiento en disco, retrasando la asignación de
almacenamiento hasta que realmente sea necesario46.
4.1.2.1.2 VMDK (Virtual Machine Disk)

El formato de imagen VMDK diseñado por VMWARE para sus productos de
virtualización utilizando el hipervisor de VMWARE ESXIES, pero actualmente es un
formato abierto, compatible con otros hipervisores que no son propios de VMWARE
como por ejemplo Virtual Box.
4.1.2.1.3 VHD (Virtual Hard Drive)

VHD es un formato de disco que representa una unidad de disco duro virtual, creado
por conettix diseñado originalmente para el hypervisor virtual PC, en el año 2003
conettix fue adquirida por Microsoft, actualmente VHD se usa con productos y
servicios relacionados con Microsoft como por ejemplo Hyper-V y Azure.
4.1.2.1.4 VDI (Virtual Disk Image)

VDI es un formato de imagen que consiste en replicar un sector de disco físico
incluyendo el contenido completo y su estructura de datos, es un formato muy
utilizado por ORACLE Virtual Box.
4.1.2.1.5 ISO
El formato de imagen ISO el cual está regido bajo la norma ISO9660, es un archivo
de disco óptico y todo el contenido de los datos está escrito en este fichero incluido
el sistema de archivos y el sistema operativo.
4.1.2.1.6 RAW
El formato RAW permite realizar una copia exacta de una imagen sin necesidad de
comprimir, el servicio de nova permite descomprimir cualquier imagen de nube
comprimida y se añadirá a la máquina virtual en el momento de arrancar esta
instancia.
46
Trujillo, D. Diseño e Instalación de una infraestructura de nube privada basada en Openstack. 2018
– 2019.
42
4.1.2.2 Arquitectura de Glance
Ilustración 9 – Arquitectura de Glance.
Fuente: Grafico elaborado a partir de

https://javieroto.wordpress.com/2018/08/12/5-openstack-glance-imagenes-y-los-
diferentes-tipos-como-kvm-y-amazon-aws
Glance está compuesta por dos demonios principales, uno de ellos es Glance API
que corre por el puerto 9292 y es la entrada principal a Glance, es decir debemos
interactuar con el Glance API para almacenar y recuperar imágenes de disco. El
segundo demonio es Glance registry, por consiguiente, es el responsable de
almacenar los metadatos asociados a una imagen en la base de datos relacional
como por ejemplo el nombre de la imagen, la ubicación de la imagen, el tamaño de
la imagen, el propietario de la imagen, el estado de la imagen y el formato del disco.
Por último, Glance puede almacenar imágenes en una variedad de Backend de
almacenamiento de datos incluyendo Swift, Amazon S3 así como sistema local de
archivos en el que recibe el propio dominio de las APIS o incluso en un servidor web
de acceso público47.
47
OpenStack. Image service. https://docs.openstack.org/glance/queens/install/get-started.html.
2018 – 2019.
43
4.1.3 SERVICIO DE COMPUTO (NOVA)
4.1.3.1 Arquitectura
Ilustración 10 – Arquitectura de Nova.
Fuente: Grafico elaborado a partir de http://vmartinezdelacruz.com/en-pocas-

palabras-como-funciona-openstack
Nova es el servicio de cómputo en OpenStack y es el Core de la construcción del

Cloud en OpenStack. Nova ha sido diseñado para gestionar y automatizar pool de
recursos de cómputo que permite trabajar con gran variedad de tecnologías de
virtualización existentes en el mercado. La arquitectura de nova, está compuesta
por 6 demonios principales, el primero de ellos es nova API, corre bajo el puerto
8774 y la entrada principal nova y cualquier servicio que quiera interactuar con Nova
debe interactuar primero con nova API para poder crear, listar, editar borrar y
gestionar cualquiera de las instancias que encuentren en el entorno de OpenStack
instalado. El segundo demonio es Nova Scheduler, este demonio evalúa y filtra
todos los HOST de cómputo disponibles en el centro de datos para determinar el
mejor nodo de cómputo para poder arrancar una instancia, el comportamiento de
nova Scheduler, puede ser modificado según se requiera en función de las
características específicas como por ejemplo la arquitectura de la CPU de los
servidores o la ubicación específica del centro de datos48.
48
OpenStack. Image service. https://docs.openstack.org/nova/queens/install/overview.html. 2018 –
2019.
44
Nova conductor es el tercer demonio, este agente es mayormente conocido como
el Worker DataBase y este demonio se conecta directamente a la base de datos
relacional del entorno de openStack, principalmente debido a un tema de seguridad
y escalabilidad ya que él nodo de cómputo hypervisor es el componente menos
confiable de un entorno virtualizado multitenant por la que toda la comunicación de
datos debe de pasar por nova conductor. El siguiente Demonio es Nova novncroxy,
este demonio proporciona acceso a la consola de las instancias a través de un
cliente VNC o navegador web, el penúltimo demonio es nova consoleauth, este
demonio recibe solicitudes de Nova novncroxy para utilizar el token de un usuario y
mapear el HOST privado y el puerto de servidor VNC de una instancia, y por último
se encuentra él nova compute, es el demonio más importante porque su función
principal es gestionar las máquinas virtuales en los hipervisores.
Nota: Para poder Iniciar una instancia con Nova, el administrador normalmente
debe proporcionar una imagen de Glance deseada y un sabor de Nova.
4.1.3.2 El orquestador de nova

El servicio nova es el corazón de la nube de OpenStack como se mencionó
anteriormente la arquitectura de nova está compuesta por una colección de
demonios que trabajan para organizar la disponibilidad de recursos informáticos
aprovechando las características de virtualización que se han estado ejecutando en
Linux durante años, en openStack en lugar de reinventar la rueda nova trabaja con
una variedad de tecnologías de hipervisor existentes incluyendo KVM, QEMU y
Hyper-V, VMWARE ESXIES, Xen server y también la capacidad de aprovechar las
tecnologías de contenedores Linux existentes como DEKKER y LXDE. Cuando un
administrador inicia una instancia, nova aprovecha los recursos de CPU, memoria
y disco disponibles en los nodos de cómputo. La escalabilidad en OpenStack es
muy importante, por lo que su aplicación en producción permite a un cliente tener
entre 5 y 5000 nodos de cómputo para almacenar sus instancias 49.
4.1.3.3 Tipos de hipervisores en OpenStack

El servicio de Nova es compatible con una gran variedad de hipervisores, en los que
se pueden encontrar QEMU (Quick Emulador) el cual fue lanzado en 2003, QEMU
es un hipervisor de código abierto que proporciona una emulación completa del
sistema, es capaz de emular uno o varios procesadores sin asistencia de la CPU,
por lo cual tiene una tendencia a ser un poco lento. El siguiente hipervisor es XEN,
creado igualmente en el año 2003 por la universidad de Cambridge, Xen es un
hipervisor de código abierto e implementa una técnica llamada para-virtualización
(P.V), por lo cual no requiere de procesadores con extensiones de virtualización
pero en cambio depende de controladores que hay que instalar dentro de las
máquinas virtuales o de las instancias, Xen ha sido utilizado por muchas nubes
públicas como por ejemplo Rug Space e incluso Amazon web Services, también se
49
Steinberg, K. NOVA: A Microhypervisor-Based Secure Virtualization Architecture. 2018 – 2019.
45
encuentra el hipervisor QEMU-KVM (Quick Emulator Kernel Based Virtual) lanzado
en 2006, QEMU-KVM es una bifurcación que sigue utilizando QEMU para visualizar
los periféricos del sistema HOST, pero también aprovechando procesadores con
extensiones de virtualización de hardware. QEMU-KVM es mucho más rápido
debido a su capacidad para virtualizar instancias a velocidades casi nativas, esto a
menudo se denomina como virtualización asistida por hardware o HVM50.
Nova no es un hipervisor por el contrario es un demonio de abierto que a menudo

se utilizan para administrar cualquiera de los hipervisores que se han mencionado
anteriormente. En un entorno OpenStack, el Nova compute utilizará este demonio
LIBVIRT para administrar las instancias o las máquinas virtuales, LIBVIRT es el que
interactúa con cualquier hipervisor del entorno OpenStack, además de los tres
hipervisores mencionados de código abierto, nova compute también es compatible
con el hipervisor Hyper-V de Microsoft, VMware Vcenter así como XEN Server un
producto de virtualización compatible con XEN51.
4.1.4 SERVICIO DE RED (NEUTRON)
Neutron es el servicio de red en OpenStack y es el que administra las redes

virtuales, subredes, direcciones IP, routers, reglas de Firewall y mucho más en un
entorno de OpenStack. Neutron y en particular SDN de las siglas en inglés Software
Defined Networking áreas. Neutron permite a los usuarios en OpenStack crear los
recursos virtuales necesarios para garantizar que sus instancias obtengan
direcciones IP internas (IP fijas) y direcciones IP externas (IP flotantes)52. Las IP
flotantes permiten a las aplicaciones que residen en instancias de OpenStack, la
facilidad de acceso externo de las mismas a través de Neutron. Los usuarios de
OpenStack pueden ver sus propias redes, subredes, reglas de firewalls y
balanceador de carga a través de: el tablero de Horizon, la interfaz de línea de
comandos o directamente a través del API53.
50
Anshu, A. Ravi, G. Multiple hypervisor based Open Stack cloud and VM migration. 2018 – 2019.
51
Murazzo, A. Análisis de una infraestructura Cloud open Source. 2018 – 2019.
52
María A. análisis de una infraestructura Cloud open source. 2018 – 2019.
53
Rodríguez, Murazzo. Arquitectura de Cloud Computing Hibrida basada en tecnología Open
Sourse. 2018 – 2019.
46
4.1.4.1 Arquitectura de Neutron
Ilustración 11 – Arquitectura de Neutron.

https://javieroto.wordpress.com/2018/08/19/6-openstack-neutron-parte-1redes-
tenant-subredes-security-group-topologia-y-reglas-de-seguridad
Neutron está compuesto de cinco demonios importantes como se muestra en el

diagrama.
4.1.4.1.1 Neutron server

Neutron Server es un API y la puerta de enlace principal a Neutron, cualquier
servicio o usuario debe interactuar con ese servicio para crear, enumerar, eliminar
y administrar redes y otros recursos de red54.
4.1.4.1.2 Neutron DHCP Agent.

Neutron DHCP Agent es un demonio que proporciona servicios de DHCP a sus
redes de Neutron, solo en caso de que se haya habilitado el servicio DHCP. El
demonio Neutron DHCP Agent realmente se encuentra utilizando un programa
llamado DNS Mask, el cual es un software de servidor DHCP ligero que está
corriendo dentro de un espacio de nombres de red o name Space. Los espacios de
nombres de red o name Space, son una característica del kernel de Linux y dividen
el uso de red, permitiendo la segregación de los recursos de red, a pesar de rangos
de direcciones IP similares55.
54
OpenStack. Networking service. https://docs.openstack.org/neutron/queens/install/overview.html.
2018 – 2019.
55
James, D. Learning OpenStack Networking. 2018 – 2019.
47
4.1.4.1.3 Neutron L3 Agent
Neutron L3 Agent es un demonio dedicado a crear routers en Neutron, dentro de
este agente, los routers de Neutron son también espacios de nombres de red o
name Space con tablas de enrutamiento únicas y reglas de IPtables.
4.1.4.1.4 Neutron metadata Agent

El demonio Neutron metadata Agent, es un demonio que proporciona servicios de
metadatos a todas las instancias. El servicio de metadatos fue popularizado por
Amazon Web Services y es una dirección IP no enrutable, concretamente la
169.254.168.254 a la que un usuario Squid puede conectarse para obtener
información personal con respecto a esa instancia.
4.1.4.1.5 Neutron Linus Bridge Agent

Este demonio se ejecuta en cada nodo de cálculo o Nova, es el responsable de la
creación y gestión de todas las funciones relacionadas con la red en los nodos de
cómputo, incluida la creación de interfaces de red virtuales para las instancias de
orden creadas, así como la creación y conexión de los LinuX Bridge y las reglas de
IPtables.
4.1.4.2 4.1.4.2 Conceptos de red en Neutron
En el entorno de OpenStack hay dos tipos de redes en Neutron, las que son
llamadas redes de networks providers y networks the tenants, las redes the
tenants son las redes privadas que son creadas en el momento de dar inicio a un
nuevo proyecto en OpenStack. Las redes the tenants o las redes de proyectos son
redes creadas por los propios usuarios que desean iniciar instancias en su propio
dominio de rede de capa 2. Las redes the tenants o las redes de proyectos siempre
son propiedad de ese proyecto al que el usuario tiene acceso durante la creación
de esa red56.
Las redes providers por el contrario son creadas por el administrador del cloud o
alguien con un rol de nivel de administrador. Estas redes se utilizan para
proporcionar acceso a la red de recursos fuera del entorno de OpenStack, un
ejemplo de recurso podría ser el internet o incluso un servidor de base de datos
bermetal que exista en una VLAN o XLAN específica en un centro de datos.
Las subredes en OpenStack son un bloque de direcciones IPv4 o versión IPv6

asociado a una red específica en OpenStack, esta subred permite la asignación de
direcciones IP a instancias de máquinas virtuales u otros recursos de red. Una red
debe estar asociada a una red para iniciar una instancia en ella y en el proceso de
creación de una subred se debe proporcionar un rango de red. Las subredes
56
Denton, J. Learning OpenStack Networking (Neutron). 2018 – 2019.
48
conectadas a las redes the tenants o a las redes de proyecto siempre suelen tener
el DHCP habilitado.
Un puerto en OpenStack es una analogía de la tarjeta de interfaz de red virtual que

representa puntos de entrada y salida para el tráfico de datos, siempre hay una
dirección MAC y una ID de usuario (UID) asociado a cada puerto. Los puertos se
crean automáticamente cuando se inicia una instancia en una red, además,
OpenStack ofrece la posibilidad de reservar un puerto en caso de que se necesite
una dirección IP específica en una instancia.
Los Security groups o los grupos de seguridad son los encargados de controlar el
tráfico hacia y desde un puerto, de forma predeterminada todo el tráfico de salida
que está permitido en todas las instancias. Sin embargo, todo el tráfico de entrada
está limitado, excepto para aquellas instancias que estén dentro del mismo grupo
de seguridad predeterminado.
Los routers son dispositivos de red generados por el demonio de Neutron L3 Agent
y permiten conectar diferentes redes entre sí. Los routers de Neutron se usan
comúnmente para conectar el tráfico de diferentes redes the tenants o redes de
proyecto, este tipo de tráfico se denomina tráfico Este y Oeste. Estos routers
también se usan para conectar las redes de proyecto o las redes the tenants a una
red Provider para acceder a otra red externa, este tipo de tráfico se domina norte
sur.
4.1.5 SERVICIO DE ALMACENAMIENTO (CINDER)
Cinder que es el servicio de almacenamiento de bloques en OpenStack, el cual

permite crear a los usuarios volúmenes persistentes que son montados en las
instancias. Cinder fue basado en un servicio que pertenece a Amazon
(almacenamiento de bloques elásticos). El servicio de Amazon Web Services EC2
es conocido actualmente como Nova en OpenStack, Nova ha sufrido grandes
cambios comparados a su lanzamiento en el año 2006, una de las principales
diferencias es cómo A.W.S o Amazon es gestionar el almacenamiento de las
máquinas virtuales. En el año 2006 Amazon sólo ofrecía almacenamiento efímero
para sus máquinas virtuales, se consideraba la posibilidad de que un usuario
arranque una instancia con un sabor, ofreciendo un disco primario de 20GB y un
disco secundario de 50GB, toda la información escrita en esos discos locales
residen en el nodo de cómputo que se aloja en esa instancia y cuando el usuario
apague esa estancia todos los datos de esa instancia se eliminarían, y los usuarios
de OpenStack necesitaban tener almacenamiento persistente en sus estancias, por
tal motivo nació Cinder, con el fin para dotar a las instancias de un almacenamiento
por bloque persistente, de tal modo que si se llegara a detener, reiniciar una
instancia, la información no se pierda. Es muy importante mencionar que OpenStack
introdujo el concepto de volúmenes de bloque persistentes dentro del proyecto de
Nova en la versión Bexar del año 2011 y ya para el año 2012 el lanzamiento de
49
OpenStack Folsom introdujo el almacenamiento de bloques como su propio
proyecto llamado Cinder57.
4.1.5.1 Arquitectura de Cinder
Ilustración 12 – Arquitectura de Cinder.

http://docshare01.docshare.tips/files/28301/283015604.pdf
Cinder está compuesta por cuatro demonios principales, el primer demonio es

Cinder API que está corriendo por el puerto 8776, este demonio es el API y la puerta
de enlace principal a Cinder, así cualquier usuario debe interactuar con Cinder API
para poder crear, enumerar, eliminar y administrar volúmenes de bloques,
snapshots o instantáneas y copias de seguridad. Cinder scheduler evalúa y filtra
todos los nodos de almacenamiento disponibles en el entorno de OpenStack para
determinar el mejor nodo de almacenamiento, Cinder scheduler se puede modificar
en función a las características específicas como por ejemplo la capacidad de los
discos o la latencia de estos. El siguiente demonio es Cinder Volume, este demonio
reside en los nodos de almacenamiento de Cinder y es el responsable de la creación
y eliminación de los volúmenes de bloque y por último se encuentra Cinder Backup,
el cual ayuda a realizar copias de volúmenes de bloque en OpenStack Swift u otros
57
OpenStack. Cinder Block Storage service. https://docs.openstack.org/cinder/queens/install/get-
started-block-storage.html. 2018 – 2019.
50
objetos de almacenamiento de terceros que se puedan contener en el entorno de
OpenStack58.
4.1.5.2 Tecnologías de Cinder

Por defecto Cinder funciona con dos tecnologías muy específicas como son LVM
(Lógical Volume Manager) y ISCSI. LVM es un conjunto de herramientas que se
desarrolló a finales de la década del 90 para permitir a los usuarios agregar y
reemplazar discos duros sin tiempo de inactividad o interrupción del servicio, esto
se hace mediante la creación de volúmenes lógicos únicos de discos duros
completos, lo que permite el cambio del tamaño dinámico, por el contrario ISCSI es
un estándar de almacenamiento basado en IP para proporcionar acceso de nivel de
bloque a dispositivos de almacenamiento a través de una red. Cinder utiliza LVM e
ISCSI para presentar los dispositivos de bloque sin formato a las instancias de Nova
y siempre a través de una red59.
4.1.5.3 Conceptos de Cinder

Volumen: Un volumen es un dispositivo de bloque sin formato que se puede
conectar a una estancia de manera virtual en Nova, luego este volumen puede ser
utilizado como un disco duro tradicional por sistema operativo de la instancia60.
Instantánea: También llamado Snapshot en Cinder, es una copia en un punto en el

tiempo en concreto del contenido de un volumen de sólo lectura, se puede crear
una instantánea snapshot a partir de un volumen que esté actualmente en uso
dentro de una estancia. La instantánea o snapshot se puede usar también para
crear un nuevo volumen.
Backup: En Cinder un backup de un volumen es un archivo comprimido de los

contenidos de ese volumen, y además está almacenado en un contenedor de
almacenamiento de objetos como por ejemplo en Swift, u otro proveedor externo
como por ejemplo Google Cloud Platform o incluso S3 de Amazon.
4.1.6 SERVICIO DE ALMACENAMIENTO DE OBJETOS (SWIFT)
Swift es el servicio de almacenamiento basado en objetos y proporciona a los

usuarios almacenamiento redundante en la nube accesible a través de una API. El
servicio de Swift se ha basado en el popular servicio de almacenamiento de objetos
en Amazon llamado S3, algunas de las aplicaciones más populares del mundo usan
S3, como por ejemplo Dropbox que es una interfaz que usa S3 para almacenar tus
archivos, así como Tumblr para alojar imágenes. En agosto del 2009 Rakspace se
inspiró en Amazon S3 y comenzó a trabajar en su propio servicio de
58
Javier, B. Service Function Chaining en NFV: Evaluación practica con OpenStack. 2018 – 2019.
59
Markelov, A. ertified OpenStack Administrator Study Guide. In Certified OpenStack Administrator
Study Guide. 2018 – 2019.
60
Santero, J. Proceso de virtualización de un centro de procesamiento de datos (CPD). 2018 – 2019.
51
almacenamiento de objetos llamado Cloud Files. Este servicio de almacenamiento
de objetos llamado Cloud Files, es un servicio que está disponible en la actualidad,
pero el proyecto se convirtió en lo que hoy se conoce como OpenStack Swift. El
sistema de almacenamiento redundante escalable de código abierto y con una
interfaz API de acceso al igual que S3, Swift se presenta a los usuarios como un
servicio de almacenamiento de objetos que hace que el almacenamiento parezca
ilimitado. También presenta alojamiento de sitios web estáticos control de versiones
de objetos listas de control de acceso o ACL y caducidad de objetos. OpenStack
Swift escribe los objetos en varias unidades de disco distribuidas por los servidores
en el centro de datos. El software de Swift escrito en Python como otros muchos
servicios de OpenStack es responsable de garantizar la replicación de datos y la
integridad en todo el cluster, en caso de que falle un servidor o disco duro, Swift
replica sus contenidos desde otros nodos activos a nuevas ubicaciones en el cluster.
Los cluster de almacenamiento se escalan horizontalmente simplemente agregando
nuevos servidores, debido a que OpenStack usa un software para asegurar la
replicación y distribución de datos a través de diferentes dispositivos, se pueden
usar discos duros económicos y servidores de muy bajo costo61.
61
Maresca, M. Diseño e implementación de herramientas web para la gestión de recursos
Openstack. 2018 – 2019.
52
4.1.6.1 Arquitectura de Swift
Ilustración 13 – Arquitectura de Swift.

http://docshare01.docshare.tips/files/28301/283015604.pdf
Swift está compuesto por 14 demonios primarios el primero es Swift Proxy Server,
es el API y la puerta de enlace principal para Swift, es también el responsable de
vincular el resto de la arquitectura Swift, cualquier usuario debe interactuar con Swift
Proxy Server para crear contenedores, cargar objetos, establecer ACL y habilitar
características especiales como el control de versiones de objetos o la habilitación
de sitios web estáticos. El demonio Swift Object Server, es el responsable de
recuperar y eliminar objetos almacenados en unidades locales del cluster de Swift,
los objetos se almacenan como archivos binarios en el sistema de archivos con los
metadatos almacenados en los atributos extendidos del archivo, mayormente
conocido como XATTRS. El siguiente demonio es Swift Object Auditor, este
demonio rastrea todo el sistema de objetos local comprobando la integridad de los
objetos si encuentra a un archivo corrupto, el archivo se pone en cuarentena y la
replicación reemplazará este archivo defectuoso con otra réplica. El siguiente
demonio en esa lista es Swift Object Expire, este demonio ofrece eliminación
programada de los objetos. El demonio Swift Object reconstructor permite al usuario
reconstruir los objetos que han sido borrados. El Swift Object Replicator, mantiene
el sistema en un estado coherente frente a las condiciones de error temporal como
por ejemplo interrupciones de la red o fallas de la unidad de disco, los procesos de
replicación comparan los datos locales con cada copia remota para garantizar que
53
todos contengan la última versión, la replicación de objetos utiliza una lista hash
para comprobar rápidamente subsecciones de cada partición. El siguiente demonio
es Swift container Server, este demonio maneja la lista de objetos dentro de un
contenedor particular, los listados se almacenan como archivos de base de datos
SQLite y se repican en él, este demonio es muy similar al Swift Object Server 62.
El demonio Swift Container Auditor rastrea el sistema del contenedor local

verificando la integridad de la base de datos de SQLite, si se encuentra alguna
corrupción, el archivo se pone en cuarentena y la replicación se reemplazará en el
archivo defectuoso por otra réplica. El demonio Swift Container Updater, actualizará
la información del contenedor en la base de datos de la cuenta, ademas recorrerá
toda la ruta del contenedor en el sistema en busca de contenedores de archivos
SQLite y enviará actualizaciones al servidor de la cuenta según sea necesario. El
demonio Swift Container Sync, es el responsable de permitir que el contenido de un
contenedor se pueda migrar o copiar a otro contenedor a través de una
sincronización en la Background. El siguiente demonio en Swift Account Server
maneja la lista de contenedores dentro de una cuenta particular, los listados se
almacenan como archivos de base de datos SQLite y se replican en el cluster. El
siguiente demonio es Swift Account Auditor su función es igual a Swift Container
Auditor, pero su diferencia es que mira los archivos de la base de datos de SQLite.
El Swift Account Replicator es similar al Swift Container Replicator, la característica
que los diferencia es que compara los archivos de la cuenta de la base de datos de
SQLite, por último se encuentra el demonio Swift Account Reaper, éste demonio se
encarga de eliminar las cuentas que un administrador de OpenStack ha marcado
para su posterior eliminación.
4.1.6.2 Conceptos de Swift

 Account: Swift utiliza el término Account o cuenta para referirse a un
proyecto de OpenStack.
 Container: Un conteiner o contenedor utilizado para archivos estáticos
también conocidos como objetos. Un usuario debe crear un contenedor para
cargar un objeto en una cuenta de Swift. Todos los contenedores son
propiedad de la cuenta o proyecto a la que accedió el usuario cuando los
creó, por defecto todos los objetos cargados en un contenedor son privados.
 Objects: Los objetos son archivos que el usuario o administrador carga en
un contenedor, por lo general estos son archivos estáticos como por ejemplo
imágenes, películas, documentos o registros.
 Objects Expiration o caducidad del objeto: Un usuario puede configurar
un objeto para que expire en un momento específico, una vez que un objeto
ha expirado, ya no será accesible y se eliminará del cluster de Swift, los
códigos de registro temporal o las claves que son válidas por un corto tiempo.
62
Vilafranca, B. Creació d' un clúster de computació amb OpenStack. 2018 – 2019.
54
 ACL o la lista de control de acceso: ACL por defecto es un contenedor de
Swift privado el cual no es accesible para ningún otro usuario u otros
proyectos, de forma predeterminada un usuario con la función de admin o el
rol Swift Operator puede establecer ACLS a nivel de contenedor para dar
acceso de lectura y escritura a ese contenedor63.
 Static Web Hosting o alojamiento de sitios web estáticos: OpenStack en
lugar de utilizar un servidor web tradicional como Apache o NGINX para alojar
un sitio web, utiliza Swift para poder alojar archivos de sitios web estáticos
como HTML, CSS o JavaScript.
 Object Versioning o el control de versiones: Permite a un usuario agregar
múltiples versiones de un archivo específico, el usuario simplemente crea un
contenedor alternativo para almacenar las versiones y a medida que el
usuario carga un archivo con el mismo nombre en el contenedor Swift, la
versión anterior se publica en el contenedor alternativo, el usuario puede
recuperar y restaurar fácilmente una versión anterior, si se envía una solicitud
de borrado del objeto, la última versión se elimina y la versión anterior se
restaura en su lugar64.
4.1.7 SERVICIO DE ORQUESTACIÓN (HEAT)
Heat es el servicio de orquestación en OpenStack y su objetivo es ayudar a los

usuarios de OpenStack a modelar, configurar y automatizar la creación y
administración de los recursos de OpenStack. A partir del 2007 hasta el 2010
muchos usuarios comenzaron a crear scripts en bash para automatizar la creación
de entornos completos para sus aplicaciones, la creación de estos scripts en bash,
funciono de maravilla por un tiempo, pero los usuarios comenzaron a tener
problemas si volvían a ejecutar el script accidentalmente, o si querían eliminar los
recursos o agregar solo un cambio adicional. Luego algunos usuarios tenían que
construir la lógica en sus scripts en bash para hacerlos más potentes y agregar más
scripts adicionales para ayudar a eliminar los entornos, pero en febrero del 2011 se
lanzó Cloud Formation. Con Cloud Formation, un usuario podía escribir su
arquitectura A.W.S deseada en un archivo de plantilla JSON. Los usuarios podían
iniciar esta plantilla y desplegar su pila, después de que el usuario finaliza. Con el
entorno de la pila se podía agregar recursos adicionales o destruir estos recursos al
eliminar esta plantilla y se introdujo en abril del 2013 con la versión Grizzly de
OpenStack, al igual que Cloud Formation, Heat comienzan con un plan o plantilla
de orquestación de Heat, que describe todos los recursos de OpenStack que se
aprovisionan65.
63
Vilafranca, B. Creación de un clúster de computacional amb OpenStack. 2018 – 2019.
64
Maria, G. Diseño e implementacion de herramientas web para la gestion de recursos de
OpenStack. 2018 – 2019.
65
Hamid. A. Pooyan, J. An Auto-Scaling Cloud Controller Using Fuzzy Q-Learning - Implementation
in OpenStack. 2018 – 2019.
55
Heat se encarga de aprovisionar y configurar sin necesidad de preocuparse por las
dependencias o el orden de ejecución. Cada usuario tiene los permisos de crear y
eliminar la pila con gran facilidad, si se desea realizar un cambio de la pila sólo se
necesita actualizarla y por consiguiente se proporciona una plantilla modificada con
nuevos parámetros66.
4.1.7.1 Arquitectura Heat
Ilustración 14 – Arquitectura de Heat.

https://malditamelena.wordpress.com/2017/05/10/openstack-y-los-modulos-
malditos
El demonio Heat API, se encuentra corriendo por el puerto 8004, el Heat API, es la
API y la puerta de enlace principal a Heat. Cualquier usuario debe interactuar con
Heat API para crear, enumerar, eliminar y administrar stacks o pilas. El siguiente
demonio es Heat API CFN, que se encuentra corriendo por el puerto 8000, este
demonio proporciona una API de consulta al estilo de A.W.S y que permite a los
servicios y usuarios utilizar funcionalidades similares a Cloud Formation como
condiciones de espera y opciones de auto escalado automático. Por último Heat
Engine, este demonio es el responsable de iniciar las pilas y administrar todos los
recursos especificados en la plantilla67.
4.1.7.2 Anatomía de plantillas Heat

Las plantillas de Heat o HoT de las siglas en inglés Heat Orchestration Template,
son plantillas que Heat API son consumidas para crear recursos virtuales en el
entorno de OpenStack. Las plantillas son extremadamente prácticas porque
permiten consultarlas en un sistema de control de versiones como Github para
rastrear fácilmente los cambios. Si se producen problemas después de implementar
66
Arabnejad, J. Estrada. I. Service-Oriented and Cloud Computing. 2018 – 2019.
67
Aida, P. Deployment of a cloud computing environment for the CMS experiment. 2018 – 2019.
56
una plantilla de Heat, simplemente se procede a restaurar a una versión anterior de
la plantilla. Las plantillas más nuevas creadas por los usuarios pueden hacer
referencia a funciones que no se encuentran en versiones anteriores, por lo tanto,
las plantillas son incompatibles con entornos más antiguos68.
68
OpenStack. Heat Orchestration Template (HOT).
https://docs.openstack.org/heat/rocky/template_guide/hot_guide.html. 2018 – 2019.
57
5. CAPITULO V. INFRAESTRUCTURA DE CÓMPUTO IMPLEMENTADA Y
PLATAFORMA DE SERVICIOS PAAS
5.1 INFRAESTRUCTURA DE COMPUTO OPENSTACK
La Arquitectura ideal (Ilustración 16) para la implementación de nube OpenStack

consta al menos tres nodos para distribuir la carga de procesamiento, pero en vista
de que no se cuenta con los recursos financieros suficientes para obtener los
requisitos de hardware necesario se usará una infraestructura básica para
desplegar la nube OpenStack (Ilustración 15).
Ilustración 15 - Arquitectura básica para ambiente OpenStack.
58
Ilustración 16 - Arquitectura para ambiente de Producción OpenStack.
59
5.2 ESPECIFICACIÓN DE SERVIDOR ANFITRIÓN
En el DATACENTER UCEVA se reservó un espacio para el Cloud computing

UCEVA, al cual se le proporcionó los siguientes recursos virtualizados para la
instalación del entorno OpenStack.
Ilustración 17 - Descripción técnica (Servidor - UCEVA).
Fuente: Oficina de Informática UCEVA.
60
5.3 INSTALACIÓN DE ENTORNO OPENSTACK TODO EN UNO
Para instalar un entorno OpenStack se puede realizar mediante Scripts,

contenedores (Docker), repositorios (GIT) o de forma manual el cual suele ser muy
engorroso por la infinidad de paquetes individuales a instalar.
Para la presente instalación de entorno OpenStack se realizará mediante un script

pre-configurado que clona de un repositorio GIT específico OpenStack los paquetes
y servicios necesarios para su funcionamiento.
5.3.1 Instalación sistema operativo anfitrión
El sistema operativo anfitrión se va instalar virtualizado en VMWare, aprovechando

las bondades de la plataforma OpenStack que permite la virtualización.
Ilustración 18 – Creación de MV en VMWare
Se crea una nueva máquina virtual (Clic Create a New Virtual Machine)
61
Ilustración 19 – Creación de MV en VMWare –Tipo de configuración.
Existen dos formas de creación de

máquinas virtuales, la Typical para
principiantes (guiada) y la Custom
para usuarios avanzados, en este
caso (Clic Custom > Clic Next >)
Ilustración 20 – Creación de MV en VMWare – Compatibilidad con Hardware.
Se selecciona la versión para la

compactibilidad de hardware, se
deja por defecto Workstation 15.x
para VMWare recientes (Clic Next >)

62
Ilustración 21 – Creación de MV en VMWare – Configuración de Boot.
Se prepara el boot para instalar el

sistema operativo, se puede
seleccionar de origen unidad óptica,
imagen ISO o Instalar después (Clic
I will install the operating system later
> Clic Next >)
Ilustración 22 – Creación de MV en VMWare – Selección SO Anfitrión.
Se selecciona en Tipo de Sistema

operativo que se instalará en la
máquina virtual (Select Linux >
Select Version Ubuntu 64-bit > Clic
Next >)

63
Ilustración 23 – Creación de MV en VMWare – Nombre de MV y ruta de destino.
Se elige el nombre de la máquina

Virtual y el destino de la instalación
(Clic Next >)
Ilustración 24 – Creación de MV en VMWare – Selección número de

Procesadores.
Se selecciona el número de
procesadores e hilos que se le van
asignar a la Máquina Virtual (Clic
Next >)
Nota: Se seleccionan la cantidad de

núcleos físicos y núcleos
virtualizados, según la capacidad de
hardware en el cual se va a instalar
OpenStack.
64
Ilustración 25 – Creación de MV en VMWare - Selección capacidad RAM.
Se selecciona la Memoria RAM que

se le va asignar a la Máquina Virtual
(Clic Next >)
Ilustración 26 – Creación de MV en VMWare – Selección tipo red.
Seleccionar el tipo de Red, la más

usadas son el Modo Bridge que tiene
su propia IP en la red local y es como
si hubiera otro equipo físico en la red
y el Modo NAT que sale a internet
emulando un DHCP y utilizando la
misma IP del equipo host. (Select
(NAT) > Clic Next >)
65
Ilustración 27 – Creación de MV en VMWare – Selección Controlador I/O.
Se selecciona el Tipo de controlador

recomendado para mayor eficiencia
en rendimiento de la Máquina Virtual
(Clic Next >)
Nota: Se eligió LSI Logic debido a

que es un controlador estable que
permite un mejor rendimiento con los
sistemas operativos Linux y
Windows. Visualizar glosario para
conocer los tipos de controladores
Ilustración 28 – Creación de MV en VMWare – Selección tipo disco duro virtual
Selecciona el Tipo de Disco duro

virtual que se va usar en la Máquina
Virtual (Select SCSI > Clic Next >)
Nota: Se determinó utilizar SCSI

debido a que soporta hasta 2TB de
disco, y permite la escalabilidad en
relación al almacenamiento de la
máquina virtual. Visualizar glosario
para conocer los tipos de disco a
implementar en una máquina virtual.
66
Ilustración 29 – Creación de MV en VMWare – Selección disco duro virtual.
Se selecciona el origen de disco a

usar en la Máquina Virtual, se puede
crear un nuevo disco vitual, escoger
una existente o usar uno físico.
(Select Create a new virtual disk >
Clic Next >)
Ilustración 30 – Creación de MV en VMWare – Selección capacidad disco duro

virtual.
Se especifica la capacidad del disco

virtual a crear, si se distribuye en uno
o más archivos de almacenamiento
y hay un check para reservar el
espacio (Sino se reserva el espacio
el disco ira creciendo proporcional a
la información almacenada) (Select
Store virtual disck as a single file >
Clic Next >)
67
Ilustración 31 – Creación de MV en VMWare – Asignar nombre disco duro virtual.
Se selecciona el nombre del disco

virtual a crear (Clic Next >)
Ilustración 32 – Creación de MV en VMWare – Configuración realizada.
Se visualiza la configuración previa

de la Máquina Virtual y se procede a
finalizar para realizar los cambios
(Clic Finish >)

68
Al lado izquierdo se visualizan las Maquina Virtuales existentes, Seleccionar
UbuntuOpentackUceva, luego Clic Edit virtual machine settings.
Ilustración 33 – Creación de MV en VMWare – MV preparada para instalación de

SO anfitrión.
Ilustración 34 – Creación de MV en VMWare – Origen SO anfitrión
Se abrirá una ventana y en

pestaña de Hardware
seleccionar CD/DVD (SATA), al
lado derecho Seleccionar Use
ISO image file y finalmente
especificar la ruta del ISO del
Sistema Operativo a instalar.
(Clic Ok >)

69
Ilustración 35 – Instalación – Iniciar MV.
Dar Clic Power on this virtual machine > para iniciar la Máquina Virtual.
Ilustración 36 –
Instalación –
Selección idioma SO.
Al iniciar la
instalación
seleccionar el idioma
del SO (Enter >)
70
Nota: La ISO que se utilizó contiene la distribución Ubuntu 18.04.2-live-server-
amd64, debido a que es una distribución libre, además, está orientada a la
comunidad, por lo que se encuentra en constante crecimiento lo cual permite mejor
soporte y constante corrección de bugs.
Ilustración 37 – Instalación – Selección configuración teclado
Seleccionar la
configuración del teclado
(Clic Hecho >)
Ilustración 38 – Instalación – Selección tipo de SO.
Se selecciona si se va
instalar el Ubuntu
convencional o el Cloud
(Diferencia de paquetes)
(Enter Instalar Ubuntu >)

71
Ilustración 39 – Instalación – Configuración de red.
Se configura la
interfaz
(Recomendado por
defecto) (Enter
Hecho >)
Ilustración 40 – Instalación – Configuración Ubuntu archive Mirror
Se configura el
Ubuntu archive Mirror
que corresponde a los
espejos
(Recomendado dejar
por defecto) (Enter
Hecho >)
72
Ilustración 41 – Instalación – Selección tipo particionamiento
Se pueden crear las

diferentes particiones
de disco de forma
manual o automática
(Enter User An Entire
Disk)
Ilustración 42 – Instalación – Selección partición creada.
Seleccionar la
partición donde se van
instalar el SO (Enter
/dev/sda 100.00G)

73
Ilustración 43 – Instalación – Visualización sistema de archivos.
Se visualiza la
Configuración del
sistema de archivos
y se confirman los
cambios (Enter
Hecho >)
Ilustración 44 – Instalación – confirmación cambios sistema de archivos.
Se muestra un
mensaje para
confirmar los
cambios ya que
después de esto no
se podrá recuperar
la información
existente (Enter
Continuar >)
74
Ilustración 45 – Instalación – Configuración perfil SO.
Se realiza la
configuración del
perfil, donde va el
nombre de la
máquina, servidor,
usuario y
contraseña. (Enter
Hecho >)
Ilustración 46 – Instalación – Paquetes adicionales.
Se puede instalar
adicionalmente
distintos paquetes,
omitir en este caso
(Enter Hecho >)

75
Ilustración 47 – Instalación – Reiniciar para aplicar cambios.
Se completa la
instalación y se reinicia
el sistema (Enter
Reiniciar ahora >)
¡Listo! Ubuntu 18.04.2

LTS instalado.
Ilustración 48 – Instalación – Ubuntu listo para inicial
76
5.3.2 Instalación paquetes OpenStack
Ilustración 49 – Actualización de paquetes.
Se actualiza el listado de paquetes y posteriormente se instalan.
Ilustración 50 – Validación de usuario administrador
Ingresar contraseña del usuario administrador.
Ilustración 51 – Actualizando paquetes.
Actualizando listado de paquetes disponibles.
77
Ilustración 52 – Paquetes actualizados.
Listado de paquetes para actualizar y confirmación para hacerlo.
Ilustración 53 – Proceso de descarga de paquetes.
Descargando Paquetes…
78
Ilustración 54 – Instalación de paquetes.
Instalando y configurando paquetes…
Ilustración 55 – Creación de usuario Stack.

Se crea el usuario stack y se confirma la información suministrada.
Ilustración 56 – Echo Stack.
79
Se entra en modo root, y se envía un echo a la dirección visualizada, seguido se
sale del modo root.
Ilustración 57 – Inicio de sesión usuario Stack.

Se inicia sesión con el usuario creado anteriormente.
Se clona el repositorio GIT de OpenStack con fuentes para la configuración e

instalación del entorno.
Ilustración 58 – Clonación de repositorio devStack.

Clonando….
Ilustración 59 – Fin de clonación.
80
Ilustración 60 – Cambio de propietario.
Se visualiza el directorio clonado y cambia de propietario a todos los archivos y

subdirectorios y finalmente se edita el fichero local.conf.
Ilustración 61 – Consultar IP.
Se debe seleccionar una interfaz para agregarlo al fichero de configuración.
81
Ilustración 62 – Configuración local.conf.
Se agrega las contraseñas requeridas y se digita el HOST_IP consultado

anteriormente.
Ilustración 63 – Ejecución de stack.sh.
Se lista nuevamente para ver si existe el fichero stack.sh y se ejecuta.
82
Ilustración 64 – Instalación de servicios.
Instalando OpenStack y sus servicios…
Ilustración 65 – Fin de instalación de servicios.
Instalación completa y datos de acceso al entorno OpenStack.
83
5.3.3 Despliegue OpenStack
Al momento de terminar la instalación el entorno OpenStack se dan los datos de

acceso al Dashboard para administrar la nube, mediante una URL para desplegar
Horizon en el navegador web http://192.168.17.134/dashboard.
Ilustración 66 – Dashboard.
Ilustración 67 – Ingreso a Horizon.

84
Se accede con el usuario creado al momento de la instalación, en este caso Usuario
admin y Contraseña uceva2019.
Ilustración 68 – Administración de OpenStack.
En la primera vista se observa el resumen de los recursos que tiene consumido el

entorno OpenStack y los límites de sus servicios (No va ligado al hardware físico
que se posee).
85
5.3.4 Creación de imagen para OpenStack
Para realizar el prototipo funcional y ofrecer servicio de Plataforma (PaaS) se creará

una VM en VMWare con el Sistema Operativo Anfitrión Ubuntu (Configuración e
instalación Ubuntu-18.04.2 ver. Ilustración 14 – Ilustración 45). Se instalarán
aplicativos de desarrollo de software (g++) y usuarios de acceso para que los
estudiantes de Ingeniería de Sistemas UCEVA, en la asignatura Fundamentos de
programación puedan resolver problemas de C++.
Ilustración 69 – Instalación de aplicativos.

 Instalación entorno de desarrollo y prueba C++.
 Instalación paquetes g++.
Ilustración 70 – Creación de usuario para estudiantes.
86
Ilustración 71 – Entorno de desarrollo.
Finalizando la configuración del entorno de desarrollo se ubica la ruta de la VM y se

copia el archivo de disco virtual, el cual se va a importar para crear la imagen en el
ambiente OpenStack.
87
6. CAPITULO VI. PROTOTIPO FUNCIONAL QUE UTILIZA LA PLATAFORMA
CLOUD COMPUTING IMPLEMENTADA
Para ofrecer servicio de plataforma como servicio (PaaS) se crean instancias que
representan el sistema de cómputo virtualizado al cual se puede acceder desde la
API OpenStack o mediante SSH. Para la creación de instancias es necesario que
exista al menos una imagen que corresponde a un ISO de instalación del Sistema
Operativo o archivos de disco virtual con el Sistema Operativo (Linux o Windows)
pre-instalado.
6.1 IMPORTACIÓN DE IMAGEN PARA OPENSTACK
Ilustración 72 – Creación de imagen en OpenStack.
Para crear imágenes OpenStack se debe dirigir al menú lateral opción Administrador
> Compute > Imágenes y dar Clic > Crear imagen.
88
Ilustración 73 – Detalles de la imagen.
Se debe agregar Detalles de la imagen a crear tales como nombre de la imagen,

archivo de origen, formato de la imagen a importar.
Ilustración 74 – Configuración de sabor.

89
Se selecciona los requerimientos de imagen que consta de tamaño mínimo
permitido de espacio en disco duro y RAM.
Ilustración 75 – Proceso de creación de imagen.

Creando imagen…
Ilustración 76 – Estado de la imagen.

Imagen creada exitosamente…
90
6.2 CREACIÓN DE VOLUMENES OPENSTACK
La creación de volúmenes muy importante y que las instancias se alojan en ellas.

Para crear volúmenes OpenStack se debe dirigir al menú lateral opción
Administrador > Imágenes y dar Clic > Crear volumen.
Ilustración 77 – Volumen.
Se agrega detalle del volumen a crear tales como nombre del volumen, descripción,
origen del volumen (Puede ser vació o se puede escoger una imagen existente),
tipo, tamaño, zona de disponibilidad y grupo.
Ilustración 78 – Estado de volumen.

91
6.3 CREACIÓN DE INSTANCIAS OPENSTACK
Las instancias son VM para usuarios OpenStack y son duplicados de las imágenes
existentes.
Para crear instancias OpenStack se debe dirigir al menú lateral opción

Administrador > Instancias y dar Clic > Lanzar instancia.
Ilustración 79 – Detalles de creación de imagen.
Se agrega detalles de la instancia a crear tales como Nombre de la instancia,

descripción, Zona de disponibilidad y Numero de instancias a crear.
Ilustración 80 – Asignación de volumen.

92
Se asigna el volumen o se crea uno si no hay disponibilidad.
Ilustración 81 – Asignación de sabor.
Se escoge el sabor que define los requisitos de Hardware que tendrá la instancia.
Ilustración 82 – Configuración de red.
Se asigna las redes disponibles para canales de comunicación para la instancia.

93
Ilustración 83 – Ejecución de instancia.
Instancia creada y ejecución desde consola OpenStack.
Ilustración 84 – Consola grafica de Instancia.
Instancia iniciada con ejemplo de prueba.

94
6.4 LABORATORIO PRACTICO OPENSTACK
Se crea laboratorio práctico para la asignatura FUNDAMENTOS DE

PROGRAMACIÓN que corresponde al primer semestre del programa Ingeniería de
Sistemas UCEVA.
Ilustración 85 – Laboratorio practico.
Ilustración 86 – Acceso de usuario estudiante1.
Se ingresa con el usuario designado.
95
Ilustración 87 – Creación de directorios.
Se crea directorio para agregar los ejercicios a resolver.
Ilustración 88 – Creación de fichero ejercicio1.
Se crea el fichero para el primer ejercicio dentro del directorio laboratorio.
Ilustración 89 – Elaboración de ejercicio1 – Laboratorio.
96
Se realiza el primer ejercicio, para guardar los cambios se presiona CTRL+O y para
salir del editor CTRL+X.
Ilustración 90 – Creación y validación de ejecutable ejercicio.cpp.
Se crea el ejecutable del ejercicio1.cpp, seguido se lanza el ejecutable y se da

solución para verificar su funcionamiento.
Se crea el fichero para el segundo ejercicio dentro del directorio laboratorio.

97
Se realiza el segundo ejercicio, para guardar los cambios se presiona CTRL+O y
para salir del editor CTRL+X.
Ilustración 93 – Creación y validación de ejecutable ejercicio2.cpp.

Se crea el fichero para el tercer ejercicio dentro del directorio laboratorio.
98
Se realiza el tercer ejercicio, para guardar los cambios se presiona CTRL+O y para
salir del editor CTRL+X.
Ilustración 96 – Creación y validación de ejecutable ejercicio3.cpp.

99
7. CAPITULO VII. CONCLUSIONES Y RECOMENDACIONES
7.1 CONCLUSIONES
Como resultado de este trabajo final de grado se ha obtenido un entorno Cloud

totalmente funcional en la plataforma para Cloud OpenStack, la cual es de licencia
GNU, instalado mediante un script pre-configurado que clona de un repositorio GIT
para OpenStack donde se encuentran los paquetes y servicios necesarios para su
funcionamiento. Además, se creó una estancia para estudiantes del curso
fundamentos de programación, donde cada uno puede abrir una sesión y utilizarla
para programar, compilar y ejecutar código fuente creado como parte del
laboratorio.
La plataforma Cloud OpenStack se ha estudiado en cuanto a su funcionamiento,

encontrando que es funcional desde la administración de imágenes que son la base
para crear instancias, estas instancias son la plataforma como servicio que es el
entorno final de desarrollo para un usuario.
En cuanto a la arquitectura de OpenStack se concluye que dicha arquitectura es

escalable en dos ámbitos, el primero es que a mayor poder de computo mayor
cantidad de servicios se pueden ofrecer; y el otro ámbito es la flexibilidad de
cambiar, aumentar o disminuir, el poder de computo o memoria cuando el usuario
lo requiere en su instancia.
La Cloud Computing ofrece un potencial para los ambientes productivos, de

crecimiento computacional a los usuarios, con baja inversión económica sin tener
que enfrentar la obsolescencia de equipos y adquisición de licencias.
Con la Cloud Computing se logra obtener alta disponibilidad en los sistemas debido
a la duplicidad total que se puede realizar de un servicio o nodo, logrando sistemas
confiables, además se logra la adecuada administración de los recursos físicos del
Cloud, administrando los tiempos de usos de memoria o procesamiento acorde a
las solicitudes de servicio, lo cual reduce la huella de carbono producidos por
equipos de cómputo.
Se logra evidenciar que realizando una buena configuración de los segmentos de

red que permita la correcta comunicación de los nodos, se puede impactar
positivamente la instalación el entorno OpenStack.
100
7.2 RECOMENDACIONES
A medida que se vaya aumentando el número de clientes por instancia, es necesario

incrementar el hardware en procesamiento, memoria volátil y almacenamiento para
ofrecer un servicio de Plataforma como servicio (PaaS) óptimo.
101
8. COLABORADORES
VIVIAN OREJUELA RUIZ

Ingeniera de Sistemas
Docente Programa de Ingeniería de Sistemas, UCEVA
WILMAR SALGADO ARIZA

Ingeniero de Sistemas
Docente Programa de Ingeniería de Sistemas, UCEVA
102
9. REFERENCIAS BIBLIOGRÁFICAS
Wireless Communications and Mobile Computing (25 December 2013). A survey of

mobile cloud computing: architecture, applications, and approaches:
http://onlinelibrary.wiley.com/doi/10.1002/wcm.1203/full.
Communications of the ACM CACM Volume 53 Issue 4, (April 2010). A View of

Cloud Computing: https://cacm.acm.org/magazines/2010/4/81493-a-view-of-cloud-
computing/fulltext.
Armbrust, M., Fox, A., Griffith, R., Joseph, A., & RH. (2009). Above the clouds: A
Berkeley view of cloud computing. University of California, Berkeley, Tech.
Rep. UCB , 07–013. https://doi.org/10.1145/1721654.1721672.
Buyya, M. C. and R. (2002). Weaving computational grids: How Analogous Arethey

With Electricalgrids? Management, 61–71.
Buyya, R., Buyya, R., Yeo, C. S., Yeo, C. S., Venugopal, S., Venugopal, S., …
Brandic, I. (2009). Cloud computing and emerging IT platforms: Vision, hype,
and reality for delivering computing as the 5th utility. Future Generation
Computer Systems, 25(June 2009), 17.
https://doi.org/10.1016/j.future.2008.12.001.
Coulouris, G., Dollimore, J., & Kindberg, T. (2007). Sistemas Distribuidos:

Conceptos y Diseño. 726. https://doi.org/M. 45.496-2003.
Dalgleish, T., Williams, J. M. G. ., Golden, A.-M. J., Perkins, N., Barrett, L. F.,
Barnard, P. J., … Watkins, E. (2007). Metodologia de la investigacion - sexta
edición. In Journal of Experimental Psychology: General (Vol. 136).
103
Valdés, J. T. (2013). Cómputo en la nube. Biblioteca Jurídica Virtual, 14. Retrieved
from https://archivos.juridicas.unam.mx/www/bjv/libros/7/3249/3.pdf.
Miralles, R. (2010). Cloud computing y protección de datos. IDP. Revista de Internet,

Derecho y Política, (11), 14–23. Retrieved from
http://www.redalyc.org/articuloBasic.oa?id=7881702400.
Rodríguez, N., Murazzo, M., Chavez, S., & Guevara, M. (2017). Arquitectura de
Cloud Computing Hibrida basada en tecnología Open Sourse. 10.
Campoverde, A., Hernández R, D., & Mazón, B. (2015). Cloud computing con
herramientas open-source para Internet de las cosas. Maskana, (7), 172–182.
https://doi.org/10.18046/syt.v13i34.2090.
Cruz Valencia, K. (2012). Historia Del Cloud Computing. Revista de Información,

Tecnología y Sociedad, 2. Retrieved from
http://www.revistasbolivianas.org.bo/scielo.php?pid=S1997-
40442012000200021&script=sci_arttext&tlng=es.
AGUILAR, L. J. (2013). NUBE Notas para una estrategia. Computacion En La Nube,

2, 89–112. Retrieved from file:///C:/Users/Usuario/Downloads/Documat-
ComputacionEnLaNube-4098278_1.pdf.
Felipe, A., Vargas, G., Fernando, D., Cruz, B., & Central, U. (n.d.). Diseño de
selección de una plataforma Cloud Computing.
Sánchez, M., Barrena, M., Bustos, P., Campillo, C., & García, P. (2016). Arquitectura
Software Basada en Tecnologías Smart para Agricultura de Precisión.
Jornadas de Ingenieria Del Software y Bases de Datos, (September).
104
Armbrust, M., Fox, A., Griffith, R., Joseph, A., & RH. (2009). Above the clouds: A
Berkeley view of cloud computing. University of California, Berkeley, Tech.
Rep. UCB, 07–013. https://doi.org/10.1145/1721654.1721672.
Buyya, R., Buyya, R., Yeo, C. S., Yeo, C. S., Venugopal, S., Venugopal, S., …
Brandic, I. (2009). Cloud computing and emerging IT platforms: Vision, hype,
and reality for delivering computing as the 5th utility. Future Generation
Computer Systems, 25(June 2009), 17.
https://doi.org/10.1016/j.future.2008.12.001.
Bojanova, I., & Samba, A. (2011). Analysis of cloud computing delivery architecture
models. Proceedings - 25th IEEE International Conference on Advanced
Information Networking and Applications Workshops, WAINA 2011, 453–458.
https://doi.org/10.1109/WAINA.2011.74.
Maria, A. R., & Sever, P. (n.d.). Cloud computing for big data from biomedical
sensors monitoring, storage and analyze. 2–5.
Yabar, S., & Com, S. (n.d.). o r e n e. 31.
Jackson, K. (2012). OpenStack cloud computing cookbook. Packt Publishing.
Jose Joaquin, E. G. (2017). Trabajo de Fin de Grado Sistemas de Identidad

Federados en Openstack.
Openstack.org. (n.d.). OpenStack Docs: Heat Orchestration Template (HOT) Guide.

Retrieved December 16, 2018, from
https://docs.openstack.org/heat/rocky/template_guide/hot_guide.html.
Aida, P. H. (2018). CLOUD PARA EL COMPUTACION (Deployment of a cloud

computing environment for the.
Openstack.org. (2018). OpenStack Docs: Cinder Block Storage service overview.

Retrieved October 4, 2018, from
https://docs.openstack.org/cinder/queens/install/get-started-block-storage.html
105
Maresca, M. G. (2015). Diseño e implementación de herramientas web para la
gestión de recursos Openstack.
Vilafranca, B. (2018). Creación de un clúster de computacional amb OpenStack.
Arabnejad, H., Jamshidi, P., Estrada, G., Ioini, N. El, & B, C. P. (2014). Service-
Oriented and Cloud Computing. 8745, 152–167. https://doi.org/10.1007/978-3-
662-44879-3.
Markelov, A. (2016). Certified OpenStack Administrator Study Guide. In Certified

OpenStack Administrator Study Guide. https://doi.org/10.1007/978-1-4842-2125-9
Ingenier, G., Jesus, C., & Cano, B. (2017). Service Function Chaining en NFV:
Evaluaci ´ on pr ´ actica con OpenStack Javier Bautista Ramos Tutor: Director:
Santero, J. C. (2016). PROCESO DE VIRTUALIZACIÓN DE UN CENTRO DE

PROCESAMIENTO DE DATOS (CPD).
Denton, J. (2014). Learning OpenStack Networking (Neutron). Packt Publishing.
Openstack.org. (2018). OpenStack Docs: Overview. Retrieved January 30, 2019,

from https://docs.openstack.org/nova/queens/install/overview.html#example-
architecture
Openstack.org. (2018). OpenStack Docs: Architecture Nova. Retrieved May 30,

2019, from https://docs.openstack.org/nova/queens/install/overview.html
Steinberg, U., & Kauer, B. (2010). NOVA: A Microhypervisor-Based Secure

Virtualization Architecture. EuroSys 2010, 209–222.
Murazzo, M. A. (2015). Análisis de una infraestructura cloud open source.
Awasthi, A. (2016). VM migration. 130–134.

https://doi.org/10.1109/CONFLUENCE.2016.7508101
Openstack.org. (2018). OpenStack Docs: Basic architecture. Retrieved May 30,

2019, from
https://docs.openstack.org/glance/queens/contributor/architecture.html
Openstack.org. (2018). OpenStack Docs: Image service. Retrieved May 30, 2019,
from https://docs.openstack.org/glance/queens/install/get-started.html
Trujillo, D. C. (2017). Diseño e Instalación de una infraestructura de nube privada

basada en Openstack’’.
106

Trabajo de Grado Ingeniero de Sistemas

Cargado por

Copyright:

Formatos disponibles

Trabajo de Grado Ingeniero de Sistemas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo de Grado Ingeniero de Sistemas

Cargado por

Copyright:

Formatos disponibles

DISEÑO E IMPLEMENTACIÓN DE UNA PLATAFORMA CLOUD COMPUTING

BASADA EN HERRAMIENTAS OPEN SOURCE PARA OFRECER SERVICIOS

ANDRES FELIPE GONZALEZ VARGAS

UNIDAD CENTRAL DEL VALLE DEL CAUCA

TRABAJO DE GRADO PRESENTADO COMO REQUISITO PARA OPTAR AL

UNIDAD CENTRAL DEL VALLE DEL CAUCA

CAPÍTULO I. ASPECTOS GENERALES DEL PROYECTO ............................. 14

Ilustración 1 – Estado actual Trabajos de Grado en estudiantes de Ingeniería de

Tabla 1 - Listado de proyectos de investigación y trabajos de grado que requieren

TIC: Tecnologías de la información y la comunicación, se referirse a cualquier forma

Middleware: Software que se sitúa entre un sistema operativo y las aplicaciones

Virtualización: Es la creación a través de software de una versión virtual de algún

Computación ubicua: Concepto en ingeniería de software y las ciencias de la

Multi threading: Ejecución de grupo de thread que corren en paralelo utilizando el

Script: Conjunto de órdenes guardadas en un archivo de texto, generalmente muy

Docker: proyecto de código abierto que automatiza el despliegue de aplicaciones

GIT: Software de control de versiones, pensando en la eficiencia y la confiabilidad

G ++ command: Comando de invocación del compilador GNU c ++, que se utiliza

LSI Logic: Controlador orientado a la arquitectura de 32 y 64 bits, más utilizado en

Logic SAS: Controlador de facto utilizado actualmente por VMware el cual

SCSI: Disco duro especialmente utilizado para grandes cantidades de información,

Tuluá – Valle del Cauca, 27 de agosto de 2019

Este trabajo de grado es dedicado a cada integrante de mi valiosa familia: mi

Andrés Felipe Gonzalez Vargas

La culminación de este trabajo de grado es dedicada a mis padres que me

Diego Fernando Briñez Cruz

1.1 DEFINICIÓN DEL PROBLEMA

1.1.1. PLANTEAMIENTO DEL PROBLEMA

En los tiempos actuales es muy importante el manejo y la distribución que se realiza

La computación en la nube o en ingles Cloud Computing es una computación

Los altos volúmenes de datos procesados pueden servir a investigadores, a la

En la formación de futuros profesionales de la ingeniería de sistemas es importante

Teniendo en cuenta lo anterior, se realizará un estudio mediante el cual se logre

A continuación, se listan proyectos que requieren infraestructura de despliegue los

Tabla 1 - Listado de proyectos de investigación y trabajos de grado que requieren

Proyecto Estado Tipo Programa

Diseño e implementación de un Terminado Trabajo de Ingeniería

Fuente: Biblioteca Néstor Grajales López.

Ilustración 1 – Estado actual Trabajos de Grado en estudiantes de Ingeniería de

Fuente: Los Autores.

Estadísticamente se observa en la Ilustración que el 88,89% de los trabajos de

1.1.2. PREGUNTA DE INVESTIGACIÓN

¿Cómo se puede resolver la necesidad de procesar y almacenar los datos

Ilustración 2 – Esquema justificación proyecto.

Fuente: Los Autores.

En la UCEVA, existe variedad de proyectos de software (Ver Tabla 1. Listado de

Ilustración 3 – Coste de servidor físico.

Fuente: DELL. Servidor en torre PowerEdge T140. (DELL, 2019)

Fuente: Godaddy. Hosting de servidor dedicado. (Godaddy, 2019)

Diseñar e implementar una plataforma Cloud Computing basada en herramientas

 Diseñar e implementar la infraestructura de computo a nivel Hardware de la

 Diseñar e implementar un prototipo de la plataforma Cloud Computing

 Desplegar en la plataforma Cloud Computing privada imágenes pre-

2.1 MARCO TEÓRICO

El marco teórico que se desarrolla a continuación, permite conocer los conceptos

2.1.1 SISTEMAS OPERATIVOS

Un sistema operativo es un programa que administra el hardware de una

Ilustración 5 - Vista abstracta de los componentes de un sistema informático.

Fuente: Los Autores.