Xen Server

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INGENIERÍA

INFORMÁTICA
GRADO EN INGENIERÍA INFORMÁTICA

TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN
TRABAJO FIN DE GRADO
Despliegue de una infraestructura Cloud basada en

XenServer para Bilib
Mario González Cifuentes
Julio, 2014
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INGENIERÍA
INFORMÁTICA
Departamento de Sistemas Informáticos
TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN
TRABAJO FIN DE GRADO
Despliegue de una infraestructura Cloud basada en

XenServer para Bilib
Autor: Mario González Cifuentes

Director: María Blanca Caminero Herraez
María del Carmen Carrión Espinosa Julio, 2014
Resumen
Este trabajo se realiza en colaboración con Bilib (Centro de Apoyo Tecnológico a

Emprendedores), cuya misión es la "difusión y aplicación de las Tecnologías de la
Información y las Comunicaciones, unido al fomento del emprendimiento empresarial en
Castilla-La Mancha".
En concreto, desde Bilib se pretende ofrecer a sus clientes una plataforma Cloud
donde puedan desarrollar nuevos servicios, o bien, desplegar instancias de servicios
preconfigurados. A tal fin, se dispone de una infraestructura de computación en el Centro
de Procesamiento de Datos del Parque Científico y Tecnológico de Albacete. Más
precisamente, estos equipos están alojados en las instalaciones de la empresa AreaProject,
encargada a su vez de su mantenimiento. El servicio contratado con AreaProject incluye la
gestión básica de los servidores virtualizados con XenServer.
El objetivo principal de este trabajo consiste en evaluar el rendimiento de dicha

infraestructura. Para ello, ha sido necesario adquirir conocimientos sobre el
funcionamiento de la computación cloud y de los entornos cloud privados. En concreto,
conocer las características de la tecnología de virtualización XenServer y conocer las tareas
a realizar para administrar la infraestructura. Además, y de cara a cubrir el principal
objetivo del presente trabajo se han evaluado las prestaciones de la infraestructura ante
distintas configuraciones y condiciones de carga. Estas evaluaciones se han realizado
haciendo uso del benchmark CloudSuite, concretamente la aplicación Cloud Suite Data
Serving. Las pruebas realizadas incluyen entre otras un análisis vertical de las máquinas
virtuales desplegadas con el fin de saber ante una petición de un usuario cuál es la elección
idónea que cumpla con sus requerimientos.
Agradecimientos
Me gustaría dar las gracias a mis

directoras del trabajo, María Blanca
Caminero Herraez y María del Carmen
Carrión Espinosa, por su compresión y
ayuda durante estos meses en todos y cada
uno de los problemas que han ido
surgiendo. También querría agredecer su
ayuda a Bilib y AreaProject, que me han
permitido realizar este trabajo en sus
instalaciones.
I
ÍNDICE
CAPÍTULO 1. INTRODUCCIÓN ......................................................................... 9

1.1 INTRODUCCIÓN ....................................................................................... 9
1.2 MOTIVACIÓN .......................................................................................... 10
1.3 OBJETIVOS .............................................................................................. 11
1.4 ESTRUCTURA DE LA MEMORIA .......................................................... 12
CAPÍTULO 2. ESTADO DEL ARTE .................................................................. 13

2.1 INTRODUCCIÓN ..................................................................................... 13
2.2 COMPUTACIÓN CLOUD ........................................................................ 14
2.3 MODELOS DE SERVICIO ....................................................................... 16
2.4 MODELOS DE DESPLIEGUE.................................................................. 20
2.5 VENTAJAS E INCONVENIENTES......................................................... 22
2.6 TECNOLOGÍAS DE VIRTUALIZACIÓN ................................................ 23
2.7 ALTERNATIVAS DE VIRTUALIZACIÓN.............................................. 26
2.8 XENSERVER ............................................................................................ 27
2.8.1 INTRODUCCIÓN .............................................................................. 27
2.8.2 FUNCIONAMIENTO......................................................................... 28
2.8.3 OTRAS CARACTERÍSTICAS ........................................................... 32
CAPÍTULO 3. INFRAESTRUCTURA CLOUD DESPLEGADA EN BILIB ...... 35

3.1 INTRODUCCIÓN ..................................................................................... 35
3.2 UNIDAD DE PROCESAMIENTO ............................................................ 37
3.3 UNIDAD DE ALMACENAMIENTO........................................................ 38
3.4 REDES ...................................................................................................... 40
3.4.1 TOPOLOGÍA DE LA RED ................................................................. 40
3.5 DESPLIEGUE SOFTWARE...................................................................... 42
CAPÍTULO 4. EVALUACIÓN DEL SISTEMA .................................................. 45

4.1 DESCRIPCIÓN DEL CASO DE ESTUDIO .............................................. 45
4.2 APLICACIÓN DESPLEGADA EN EL SISTEMA .................................... 47
4.2.1 CASSANDRA .................................................................................... 47
4.2.2 YCSB ................................................................................................. 51
4.3 MÉTRICAS DE RENDIMIENTO ............................................................. 58
4.4 PRUEBAS REALIZADAS ........................................................................ 59
4.4.1 ESCENARIO 1: CLIENTE EXTERIOR ............................................. 60
III
4.4.2 ESCENARIO 2: CLIENTE INTERIOR ...............................................66
4.4.3 CONCLUSIONES SOBRE LA ESCALABILIDAD VERTICAL ........78
4.4.4 CONCLUSIONES FINALES SOBRE EL DISEÑO DEL SISTEMA ..84
CAPÍTULO 5. CONCLUSIONES Y PROPUESTAS ...........................................85

5.1 CONCLUSIONES ......................................................................................85
5.2 OBJETIVOS LOGRADOS .........................................................................86
5.3 COMPETENCIAS ADQUIRIDAS .............................................................87
5.4 TRABAJO FUTURO Y POSIBLES AMPLIACIONES..............................87
BIBLIOGRAFÍA.....................................................................................................89
LIBROS Y ARTICULOS ....................................................................................89
ENLACES INTERNET .......................................................................................90
CONTENIDO DEL CD...........................................................................................93
ANEXO A. MATERIAL USADO ........................................................................95
ANEXO B. PROCESO DE INSTALACIÓN DE CLOUDSUITE DATA SERVING

105
ÍNDICE DE FIGURAS
Ilustración 1 - Servicios que ofrece Bilib a través del servicio Cloud ...................... 10
Ilustración 2 - Organización de los elementos dependiendo de la arquitectura usada.
............................................................................................................................... 17
Ilustración 3 - Usuarios cloud ordenados por capas de arquitectura. Fuente: Revista
Dintel ..................................................................................................................... 17
Ilustración 4 - Estructura básica de un sistema virtualizado..................................... 24
Ilustración 5 - Estructura básica de Xen .................................................................. 28
Ilustración 6 - Arquitectura XenServer. Fuente: Citrix XenServer .......................... 29
Ilustración 7 - Ubicación del 'pool' dentro del sistema XenServer. Fuente: Citrix
XenServer .............................................................................................................. 30
Ilustración 8 - Networking en XenServer ................................................................ 34
Ilustración 9 - Esquema básico del despliegue ........................................................ 36
Ilustración 10 - Organización del enclosure Albacete. Fuente: Bilib ....................... 37
Ilustración 11 - VLANs pertenecientes al despliegue. Fuente: Bilib ........................ 41
Ilustración 12 - Gestión de las VPNs. Fuente: Bilib ................................................ 41
Ilustración 13 - Esquema software utilizado en el despliegue basado en la
arquitectura de XenServer ...................................................................................... 42
Ilustración 14 – Captura de pantalla del pool creado desde XenCenter .................... 43
Ilustración 15 - Arquitectura de Cassandra. Fuente: Apache Cassandra .................. 50
Ilustración 16 - Arquitectura YCSB. Fuente: www.dcomp.sor.ufscar.br ................. 51
Ilustración 17 - Distribuciones de carga usadas en los workloads. Fuente: YCSB
GitHub ................................................................................................................... 56
Ilustración 18 - Diagrama de bloques de las pruebas de evaluación......................... 59
Ilustración 19 – Escenario1: Productividad (F. carga) ............................................. 61
Ilustración 20 – Escenario1: Tiempo (F.carga) ....................................................... 61
Ilustración 21 – Escenario1: Latencia (F. carga) ..................................................... 61
Ilustración 23 – Escenario1: Tiempo (F. carga)....................................................... 63
Ilustración 26 – Escenario1: Tiempo (F. ejecución) ................................................ 64
Ilustración 25 – Escenario1: Productividad (F. ejecución) ...................................... 64
Ilustración 27 – Escenario1: Latencia (F. ejecución) ............................................... 64
Ilustración 28 – Escenario1: Productividad (F. ejecución) ...................................... 65
Ilustración 29 – Escenario1: Tiempo (F. ejecución) ................................................ 65
Ilustración 30 – Escenario1: Latencia (F. ejecución) ............................................... 66
Ilustración 32 – Escenario2: Tiempo (F. carga)....................................................... 67
V
Ilustración 34 – Escenario2: Productividad (F. carga) ..............................................69
Ilustración 35 – Escenario2: Tiempo (F. carga) .......................................................69
Ilustración 36 – Escenario2: Latencia (F. carga) ......................................................69
Ilustración 37 – Escenario2: Productividad (F. ejecución) .......................................70
Ilustración 38 – Escenario2: Tiempo (F. ejecución) .................................................70
Ilustración 39 – Escenario2: Latencia (F. ejecución)................................................71
Ilustración 46 - Comparativa de productividad entre los workloads .........................79
Ilustración 47 - Comparativa de tiempo entre los workloads ....................................79
Ilustración 48 - Comparativa de latencia entre los workloads ..................................80
Ilustración 49 - Comparativa de productividad entre los workloads .........................80
Ilustración 50 - Comparativa de tiempo entre los workloads ....................................81
Ilustración 51 - Comparativa de latencia entre los workloads ..................................81
Ilustración 52 - Comparativa de productividad entre los workloads de los dos tipos de
máquinas virtuales ..................................................................................................82
Ilustración 53 - Comparativa de tiempo entre los workloads de los dos tipos de
Ilustración 54 - Comparativa de latencia entre los workloads de los dos tipos de
Ilustración 55 - Esquema básico del despliegue. Fuente Bilib ................................ 100
ÍNDICE DE TABLAS
Tabla 1 - Resumen de la historia de la computación ............................................... 14

Tabla 2 - Características de la virtualización y paravirtualización ........................... 25
Tabla 3 - Servidores usados durante el despliegue .................................................. 38
Tabla 4 - Características de las cargas de trabajo .................................................... 56
VII
CAPÍTULO 1
CAPÍTULO 1. INTRODUCCIÓN
En este primer capítulo se realiza una breve introducción a la computación Cloud y

se dedica especial atención a la presentación del contexto en el que se desarrolla este
Trabajo Fin de Grado. Además, se comenta la principal motivación y objetivos que se
espera alcanzar durante el desarrollo del trabajo.
1.1 INTRODUCCIÓN
En el presente Trabajo Fin de Grado se plantea el despliegue y evaluación de una

infraestructura cloud, también conocida como computación en el cloud. Este despliegue
consiste en ofrecer infraestructura hardware como servicio, de forma que los usuarios
pueden acceder a servicios y hacer uso de infraestructuras muy complejas sin necesidad
de tener un amplio conocimiento de la gestión de recursos, como servidores, redes,
comunicaciones, seguridad, etc.
Hoy en día la mayoría de empresas TIC utilizan servicios en la cloud. El problema

es que los servidores que proveen estos servicios necesitan grandes unidades de
procesamiento, las cuales no se aprovechan lo suficiente.
Esto motivó la instalación de máquinas virtuales en los servidores para exprimir el

rendimiento de los mismos, y así poder reducir el número de servidores necesarios. Esta
opción supone un importante ahorro en los costes tanto económicos como energéticos.
Otra importante ventaja es la facilidad de escalabilidad de los servidores, ya que

puede hacer uso de proveedores para contratar máquinas virtuales y alojar los servicios.
De esta manera se cubren las necesidades de muchas empresas que requieren soportar
grandes demandas de servicios en periodos muy breves de tiempo, sin tener que invertir
grandes cantidades de dinero en hardware.
9
CAPÍTULO 1
Este Trabajo Fin de Grado se realiza en colaboración con Bilib (Centro de Apoyo
Tecnológico a Emprendedores), cuya misión es la "difusión y aplicación de las
Tecnologías de la Información y las Comunicaciones, unido al fomento del
emprendimiento empresarial en Castilla-La Mancha". [Bilib]
En concreto, Bilib pretende ofrecer a las empresas TIC de Castilla La-Mancha una
plataforma Cloud donde puedan desarrollar nuevos servicios, o bien, desplegar instancias
de servicios preconfigurados. Su objetivo es que las empresas puedan utilizar la cloud
para aprovechar y utilizar sus servicios, que pueden ser muy útiles para el desarrollo de la
empresa, algunos de ellos se muestran en la Ilustración 1.
Ilustración 1 - Servicios que ofrece Bilib a través del servicio Cloud
A tal fin, se dispone de una infraestructura de computación en el Centro de

Procesamiento de Datos del Parque Científico y Tecnológico de Albacete. Más
precisamente, estos equipos están alojados en las instalaciones de la empresa AreaProject
[AreaP], encargada a su vez de su mantenimiento. El servicio contratado con AreaProject
incluye la gestión básica de los servidores virtualizados con XenServer [XenSrvr].
1.2 MOTIVACIÓN
La principal motivación para la realización de este trabajo es la necesidad del

despliegue de servicios virtualizados, para así poder ofrecer servicios en la cloud, así
como realizar una evaluación de las prestaciones ofrecidas por un caso de uso concreto de
dichos servicios.
Hace unos años la mayoría de estos servicios, que ahora están en la cloud, se
realizaban desde grandes computadoras difícilmente escalables y que apenas se ajustaban
a las necesidades de servicio de cada momento.
CAPÍTULO 1
Estos servidores sufren un gran desaprovechamiento de rendimiento en el uso de

sus recursos ya que nunca se usan al máximo rendimiento durante todo el tiempo.
Para evitar este desaprovechamiento de los servidores surge la virtualización, con la

que se puede hacer un mejor uso y aprovechamiento del hardware del que disponemos,
además de implementar una solución fácilmente escalable y con un tiempo de despliegue
de nuevos servidores realmente corto frente al uso convencional.
Además, el término 'servidor web' como la típica computadora física, situada en un

determinado lugar, comienza a desaparecer y se comienza a utilizar el término 'servicio
web', en el que pueden estar repartidos sus distintos componentes entre diferentes lugares
del mundo sin problemas de integración. En los que es posible incrementar o disminuir su
capacidad simplemente contratando un ancho de banda en un servidor y desplegando allí
una imagen.
1.3 OBJETIVOS
El principal objetivo que se persigue con este trabajo es la evaluación de una

infraestructura cloud privada disponible al uso para la empresa Bilib. Para ello, mediante
una batería de pruebas se analizará el rendimiento del sistema y se obtendrán una serie de
conclusiones que nos ayudarán a la hora de elegir la configuración de la máquina virtual
necesaria para cumplir los requisitos del usuario, así como a la hora de configurar la
arquitectura.
Todo esto estará precedido de un estudio de la tecnología y del material utilizado,

además de la descripción del proceso de despliegue del sistema.
Este es el objetivo general que se puede desglosar en los siguientes objetivos

parciales:
- Familiarización con la tecnología Cloud

- Familiarización con el hipervisor Xen
o Estudio del software de XenServer
- Estudio del entorno de trabajo
o Componentes hardware
o Componentes software
- Despliegue del benchmark y puesta en marcha de CloudSuite Data Serving
sobre la infraestructura disponible
11
CAPÍTULO 1
- Análisis y evaluación de rendimiento de distintas configuraciones

desplegadas sobre la infraestructura en uso
1.4 ESTRUCTURA DE LA MEMORIA
El documento se divide en cinco capítulos. El primero de ellos consiste en una

breve introducción del trabajo, donde también se comentan los distintos objetivos que se
persiguen con la ejecución.
El segundo capítulo trata sobre el estado del arte del trabajo, en el que se describe la
tecnología que se usará.
En el tercer capítulo se ofrece una descripción completa del equipo utilizado, tanto
software como hardware.
El capítulo cuatro consiste en la recopilación de las distintas pruebas realizadas en

el sistema y las conclusiones obtenidas al término de dichas pruebas.
En el quinto y último capítulo podemos encontrar las conclusiones y conocimientos

adquiridos a lo largo del desarrollo del trabajo, y además los posibles trabajos futuros a
realizar.
CAPÍTULO 2
CAPÍTULO 2. ESTADO DEL ARTE
En este capítulo se presenta el estado de la cuestión sobre la computación cloud,

sobre sus características, ventajas e inconvenientes. Además, se analizarán los distintos
modelos de servicio que ofrece y se comentarán los posibles modelos de despliegue
disponibles. Por último se comentan las principales características de la tecnología de
virtualización y las ventajas que ofrece la paravirtualización. Asimismo se incluye un
análisis de los distintos tipos de hipervisores de virtualización y cuál será la opción
elegida.
También contiene un análisis de XenServer, el hipervisor sobre el que se basa el

despliegue realizado. Primero se incluye una introducción del software, a continuación se
expone el funcionamiento y arquitectura del mismo. Y por último se habla de los
elementos tantos virtuales como físicos que entran en juego durante el funcionamiento de
XenServer.
2.1 INTRODUCCIÓN
En los inicios de la computación se utilizaban los mainframes, que eran

ordenadores centrales a los que se conectaban los usuarios que podían interaccionar con
el ordenador mediante un monitor y un teclado.
Más tarde (80’s) aparecieron los PC u ordenadores personales, así las

organizaciones podían dispones de tantos ordenadores como necesitaran para soportar
diversas aplicaciones, lo cual comporto que acabaran teniendo una serie de máquinas
distribuidas por varios departamentos que gestionaban distintas aplicaciones.
Años después de la aparición de Internet aparecieron webs como Yahoo, Google o

Amazon, que daban servicio a un amplio abanicos de usuarios que se conectaban desde
13
CAPÍTULO 2
cualquier lugar del mundo. En este periodo es cuando nace la Web 2.0, donde los
usuarios ya no son solo consumidores de información sino que también producen
información que puede ser consumida por el resto de usuarios de la red.
Todo ello hace aparecer la necesidad de potentes servidores que tiene que dar
servicio a una gran cantidad de usuarios que se conectan desde cualquier tipo de
dispositivo. Servidores que ya no se encuentran alojados en las empresas que han creado
los programas o servicios informáticos. Han desplazado toda la computación y
almacenamiento de sus servidores hacia algún sitio externo desde el que puedan acceder
fácilmente a través de Internet a grandes centros de proceso de datos (CPD).
La red se ha convertido en nuestro ordenador. Es lo que se conoce como
computación cloud.
La Tabla 1 muestra una comparativa de los distintos modelos de computación a lo

largo de la historia:
Modelo de Características Costes

computación y
almacenamiento
Mainframe Centralizado Sistemas que Inversión inicial tanto

procuraban aprovechar para el hardware como
al máximo los recursos para el software
a causa del alto coste de
estos
Personal Computer Distribuido PC y servidores Inversión inicial para la
(PC) distribuidos conectados compra de hardware y
en red (primero local y costes de licencias para
después Internet). el SO y las aplicaciones
software que se usaban.
Cloud Centralizado Inmensos CPD con Se paga solo por lo que
recursos TIC de bajo se gasta a medida que
coste que se optimizan se va usando a lo largo
aprovechando la del tiempo.
economía de escala.
Tabla 1 - Resumen de la historia de la computación
2.2 COMPUTACIÓN CLOUD
El modelo de computación Cloud es un modelo que habilita el acceso a un conjunto

de recursos computacionales configurables mediante bajo demanda y con ubicuidad. Este
conjunto de recursos puede ser rápidamente suministrado y lanzado con un esfuerzo de
mantenimiento mínimo o interacción por parte del proveedor. [NIST]
14
CAPÍTULO 2
A continuación se detallan las características básicas de la computación Cloud,

seguidas de los diferentes modelos ‘cloud’ y las distintas arquitecturas aplicadas.
Las principales características de la computación Cloud son:
- Servicio propio bajo demanda: Un consumidor puede suministrar de manera

unilateral capacidades computacionales al sistema, como tiempo de servidor o
capacidad almacenamiento, según sea necesario de forma automática sin requerir
interacción humana con el proveedor del servicio.
- Acceso desde la red: Las capacidades del sistema están disponibles a través de la
red accediendo mediante plataforma que pueden ser usadas por distintos tipos de
dispositivos (smartphones, tablets, ordenadores,…)
- Puesta en conjunto de recursos: Los recursos informáticos son reunidos para

suministrar servicio a múltiples consumidores usando un modelo multi-inquilino,
con un servidor físico o virtual sede de una aplicación que está diseñada para
permitir el uso de múltiples usuarios diferentes. Cada usuario se siente como si
tuviera un uso exclusivo de la aplicación. Los recursos son dinámicamente
asignados y reasignados de acuerdo con la demanda del consumidor.
- Flexibilidad: Gracias a la computación cloud tenemos un nuevo abanico de

servicios a la vez que se ofrece la posibilidad de convertir gastos fijos en
variables, lo que permite conocer mejor los costes reales y minimizar los riesgos.
La flexibilidad se muestra en dos características básicas, que son:
o Agilidad con que permite autoproveerse de servicios ofrecidos a través de

la cloud. Permite que se puedan reducir los plazos de implantación. El
tener un CPD (centro de procesamiento de datos) propio supondría que la
implementación de servicios sería de días o semanas, en cambio
trabajando desde el cloud se reduce a horas. Es decir, las infraestructuras o
servicios TIC dejarán de ser un problema para las organizaciones y podrán
centrarse en sus objetivos de negocio.
o Escalabilidad: Sin el cloud las empresas que querían aumentar su oferta

tenían que invertir primero una gran cantidad de capital en infraestructura
y otros recursos informáticos (software). Por ejemplo, una empresa que
tenga picos en sus actividades debe de invertir mucho capital en recursos
que mantendrá inactivos durante la mayor parte del tiempo o reducir su
actividad en determinadas épocas. Usando el cloud, la empresa podrá
adaptar los servicios y recursos contratados a sus necesidades.
15
CAPÍTULO 2
- Monitorización: Los sistemas de computación cloud controlan y optimizan sus

recursos de manera automática gracias a los sistemas de medida, que chequean el
rendimiento del sistema en el nivel de abstracción apropiado para un determinado
tipo de servicio (almacenamiento, procesamiento de datos, ancho de banda,
usuarios activos,…). Los recursos usados pueden ser monitorizados y controlados,
además permiten enviar información propia. Todo esto proporciona información
de gran utilidad tanto para el proveedor como para el consumidor de esos
servicios.
Este modelo 'cloud' está compuesto por 5 características principales, tres modelos
de servicio y cuatro modelos de despliegue. [NIST]
Las soluciones de la computación cloud disponibles en el mercado se clasifican en

varias dimensiones, que se pueden categorizar de dos maneras.
Una de ellas sería por el modelo de servicio, que incluye los modelos
Infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) y Software como
servicio (SaaS). La otra categoriza por el tipo de modelos de despliegues disponibles, es
decir, las formas de integración y explotación de la infraestructura; en este conjunto se
encuentran el cloud privado, el público, el híbrido y el comunitario.
2.3 MODELOS DE SERVICIO
El servicio ofrecido en un entorno de computación cloud puede categorizarse en

función del nivel de control ofrecido sobre la infraestructura subyacente. Así, se dispone
de tres modelos de servicio fundamentales: IaaS, PaaS, SaaS (ver la Ilustración 2).
16
CAPÍTULO 2
Ilustración 2 - Organización de los elementos dependiendo de la arquitectura usada.
Cada modelo engloba un grupo de usuarios totalmente distintos (ver la Ilustración

3).
Ilustración 3 - Usuarios cloud ordenados por capas de arquitectura. Fuente: Revista Dintel
Actualmente se habla de diferentes tipos de modelos, de los que los más habituales
son los siguientes:
17
CAPÍTULO 2
Software como Servicio (SaaS):

El modelo de servicio más completo es aquél que ofrece el software y el hardware
como un servicio conjunto, es decir, SaaS provee la infraestructura, el software, la
solución y toda la pila de aprovisionamiento como un servicio global.
Software as a Service (SaaS) se puede describir como software que está desplegado
en un servicio de hosting y puede ser accedido globalmente a través de Internet mediante
navegador, móvil, tablet, etc. Y donde todos los aspectos que no sean la propia
interacción con la aplicación son transparentes al usuario. En el modelo SaaS, los
usuarios pagan por el uso del servicio mediante cuotas de suscripción, válidas por un
determinado período de tiempo, como en el caso de un alquiler. Las características
fundamentales de este modelo se pueden resumir en:
- El software está disponible globalmente a través de Internet y bajo demanda.

- El modelo de subscripción suele ser mediante licencias o basado en uso y es facturado
por mensualidades de forma recurrente.
- Todo lo relativo a operaciones es responsabilidad del proveedor
- Las actualizaciones, mejoras, evoluciones o parches en el aplicativo, debe ser siempre
transparente al usuario y por supuesto no debe hacer ningún tipo de configuración.
- SaaS soporta múltiples usuarios generalmente con un modelo multi-tenant (multi-
inquilino).
Este modelo de servicios normalmente pretende llegar a pequeñas y medianas

empresas (PYMES) y a veces a usuarios individuales. El acceso suele ser a través de un
portal o de un CMS web, que puede ser en abierto o bien está sujeto a una subscripción
previa de otro servicio en la compañía que ofrece SaaS (ADSL, línea móvil, .etc.). Dicho
portal puede ser muy variado, pero generalmente contiene los servicios y aplicaciones
adquiridos previamente con un acceso mediante 'mashups'. Y por otro lado un catálogo
de aplicaciones que se ofrecen. De ahí en adelante el portal puede ser tan avanzado como
se quiera pero siempre será el punto de acceso y uso a los servicios.
Plataforma como Servicio (PaaS):

Este modelo de servicio se sitúa por encima de IaaS y por debajo del SaaS en
cuanto a nivel de abstracción de los recursos de tecnología de la información. Este
modelo propone un entorno software en el cuál un desarrollador puede crear y modificar
soluciones dentro de un contexto de herramientas de desarrollo que la plataforma
proporciona.
18
CAPÍTULO 2
En PaaS los clientes pueden interactuar con el software para introducir o recuperar
datos, realizar acciones, etc.; pero no tienen responsabilidad de mantener el hardware,
software o el desarrollo de las aplicaciones, sólo se tiene responsabilidad de la interacción
con la plataforma, es decir, el proveedor es el responsable de todos los aspectos
operacionales. Además, la plataforma ofrece herramientas de desarrollo y despliegue de
aplicaciones.
Las plataformas como servicio vienen a suponer que el desarrollador de

aplicaciones web se olvida de almacenaje de ficheros, de gestión de la base de datos, de
balanceo entre máquinas, de ancho de banda, de escalabilidad, de picos de demanda, de
estabilidad, de configurar una máquina servidor...; en definitiva, únicamente se presta
atención al desarrollo de la aplicación web, olvidándose de la infraestructura.
Poder abstraerse del entorno supone dos ventajas importantes. La primera sería el
ahorro de costes y la segunda la posibilidad de centrar toda la atención en la aplicación.
El ahorro de coste no proviene únicamente de la posibilidad de contratar un servicio de
almacenamiento más barato, sino porque el conocimiento necesario para crear
arquitecturas escalables es muy costoso. Aunque también cuenta con algunos
inconvenientes: depender de un único proveedor y sufrir sus caídas.
Infraestructura como Servicio (IaaS):

Podría definirse como un modelo de servicios de computación. Estos servicios
podrían utilizarse para resolver necesidades computacionales sin problemas de
escalabilidad. El presente trabajo centra su atención en este modelo de servicio.
El modelo IaaS hace referencia al hecho de ofrecer servicios de computación y

almacenamiento, de tal manera que sea posible disponer de recursos como ciclos de CPU
(Central Processing Unit), memoria, disco o equipamientos de red. El consumidor alquila
los recursos de hardware en vez de comprarlos e instalarlos en su propio centro de
procesamiento de datos, lo que le permite ir variando el consumo de los recursos en
funciones de sus necesidades, esto se conoce como elasticidad de la infraestructura.
Este modelo está siendo adoptado por una multitud de 'startups' que han
comenzado a emprender en tiempos de crisis y que no se pueden permitir tener su propio
centro de datos o una infraestructura propia. En este modelo los desarrolladores
encuentran una forma dinámica y flexible de trabajar, ya que se puede interactuar con la
IaaS mediante servidores virtuales, almacenamiento virtual.
Normalmente se generan instancias de estas máquinas virtuales desde un portal

web. En ese momento los desarrolladores tienen vía libre para personalizar y encontrar
19
CAPÍTULO 2
una solución apropiada. El acceso y la interacción de la aplicación con la IaaS suele

realizarse a través de SOA (Service-Oriented Architecture).
IaaS está enfocado a cualquier empresa que desea delegar la implantación de sus
sistemas software y aplicaciones en la infraestructura hardware de un proveedor externo
(hosting) o que requiera de servicios de almacenamiento externo, copias de seguridad de
sus datos, cálculos complejos que requieran software de elevadas prestaciones, etc., el
proveedor les permitirá gestionar dichos sistemas en un entorno virtualizado.
Los proveedores de servicios son los propietarios de las máquinas físicas, y las
ofrecerán como un servicio a los usuarios, además de proporcionarles un entorno que les
permita gestionarlas (sitio web).
2.4 MODELOS DE DESPLIEGUE
Podemos definir cuatro tipos de clouds dependiendo de quién pueda acceder a los
servicios que ofrece y de quién se encargue de gestionar la infraestructura.
Actualmente existe una importante tendencia en grandes empresas a la

implementación dentro de su estructura y utilizando la red privada de la propia
organización, de los llamadas “clouds privados”. Este concepto, a priori más cercano al
de despliegue tradicional de aplicaciones que la de computación cloud “estándar”, hace
referencia a redes o CPDs propietarios que utilizan tecnologías características de la
computación cloud, tales como la virtualización. Así, parten de los principios de la
computación cloud tradicional y ofrecen los mismos servicios pero dentro, en la propia
estructura de la compañía. Este modelo será el usado en el trabajo.
Se suelen diseñar específicamente para un usuario, proporcionando un control

óptimo de la información gestionada, de su seguridad y de la calidad de servicio ofrecida.
Habitualmente el usuario es también propietario de la infraestructura de cloud privado, y
tiene control total de las aplicaciones desplegadas en ella.
Los principales inconvenientes de este modelo son los analizados para el paradigma
tradicional, por ejemplo los relativos a la ampliación de los sistemas informáticos. Esto
obliga a adquirir nuevos sistemas antes de hacer uso de ellos, contrariamente a lo ofrecido
por los clouds públicos, donde ampliar los recursos se reduce a controlarlos con el
proveedor de servicios.
Como ventaja de este tipo de clouds, a diferencia de las clouds públicos, destaca la
localización de los datos dentro de la propia empresa, lo que conlleva a una mayor
seguridad de estos.
20
CAPÍTULO 2
Por otro lado, en un despliegue de un cloud comunitario, la infraestructura del

cloud está proporcionada únicamente para el uso específico de una comunidad de
consumidores de una organización que comparte información. La propiedad, gestión y
uso corresponde a más de una organización.
En el caso del cloud público los servicios que se ofrecen se encuentran en los
servidores externos al usuario, pudiendo tener acceso a las aplicaciones de forma gratuita
o de pago y utilizar el servicio adecuado, cuando a la empresa que ofrece el servicio no le
importa compartir recursos virtualizados en el cloud y donde el despliegue de la
aplicación será de manera provisional.
La principal ventaja de los clouds públicos es la capacidad de procesamiento y

almacenamiento sin tener que instalar máquinas de manera local, por lo que la inversión
inicial no es muy alta y los gastos de mantenimiento no existen en este sentido,
únicamente pagaremos una cuota (mensual o trimestral) dependiendo del uso que
hagamos. La carga operacional y la seguridad de los datos recaen íntegramente sobre el
proveedor del servicio. Debido a ello, el riesgo por la adopción de una nueva tecnología
es bastante bajo. El retorno de la inversión se consigue rápidamente en este tipo de
clouds.
Como inconvenientes se cuenta con el acceso de toda la información por terceras

empresas, y la dependencia de los servicios en línea (online).
También puede resultar difícil integrar estos servicios con otros sistemas
propietarios. Es muy importante a la hora de apostar por un servicio en el cloud público,
asegurarse de que se puede conseguir todos los datos que se tengan en ella, gratuitamente
y en el menor tiempo posible.
El modelo híbrido combina los modelos anteriormente descritos, sobre clouds

públicas y privadas, de manera que se aprovecha la ventaja de localización física de la
información gestionada por los clouds privados con la facilidad de ampliación de
recursos de los clouds públicos. Las principales cuestiones a vigilar en este modelo son la
privacidad y la protección de datos, igual que en el cloud público.
El cloud híbrido consiste en coordinar las aplicaciones propias de la empresa con

las consumidas a través del cloud público, entendiéndose también como la incorporación
de servicios de computación cloud a las aplicaciones privadas de la organización. Esto
permite a una empresa mantener el control sobre las aplicaciones críticas para su negocio
y aprovechar al mismo tiempo las posibilidades ofrecidas por los servicios ofertados por
el cloud en aquellas áreas donde resulte más adecuado.
En la actualidad este tipo de clouds está teniendo una gran aceptación dentro del
mundo empresarial, por lo que están desarrollando software de gestión de cloud que
21
CAPÍTULO 2
permita controlar la cloud privada e incorporar al mismo tiempo recursos y servicios de

proveedores públicos de computación cloud.
A continuación se presentan las principales ventajas e inconvenientes de la

Computación Cloud.
2.5 VENTAJAS E INCONVENIENTES
El modelo de computación cloud permite ofrecer de manera conveniente y a

demanda, recursos y servicios altamente disponibles tanto desde la red privada como la
red pública., con un testeo continuo de las aplicaciones por parte del desarrollador
durante el ciclo de vida software. Partiendo de ese hecho se obtienen multitud de
beneficios.
El tener un entorno cloud nos permite realizar pruebas de testeo de una manera
poco costosa sin tener que desplegar una infraestructura real. Además de proporcionar
servidores o mainframes, un entorno virtual de test puede ser ejecutado en software “low-
cost”. Estos entornos virtuales pueden ser fácilmente reconfigurados para distintas
necesidades o proyectos de testeo.
También hay que tener en cuenta la disponibilidad del servicio, el servicio siempre
ha de estar disponible para el cliente. El cloud computing permite diseñar una
infraestructura redundante que permita ofrecer un servicio siempre constante y sin
interrupciones de acuerdo a las condiciones del cliente.
La disponibilidad no es el único beneficio de tener una infraestructura arrendada. El

ahorro de costes es una de las ventajas más interesantes del cloud computing. Al evitar la
compra y mantenimiento de la infraestructura por parte del cliente. El usuario de estos
servicios únicamente tendrá que pagar los recursos que utiliza.
Al poder reducir los gastos, las empresas pequeñas tienen oportunidad de competir
con el resto pudiendo ofrecer los mismos servicios. La ventaja competitiva no reside en
quien tiene los recursos sino quien los utiliza de manera correcta.
También cabe destacar que la computación cloud consigue un importante ahorro

energético al exprimir el rendimiento de los centros de procesamiento de datos (CPD).
Por último, la deslocalización del sistema permite acceder a los servicios desde
cualquier lugar. Internet no tiene limitaciones geográficas, por lo tanto es indiferente
localizar nuestro CPD en España o en la otra punta del mundo.
22
CAPÍTULO 2
Pero no todo son ventajas ya que podrían surgir otras cuestiones como la garantía
de disponibilidad de esos datos alojados a tantísimos kilómetros. La información se ha
vuelto un bien esencial en la sociedad actual, y por ello tenemos que evitar a toda costa
las situaciones en los que no tengamos control sobre nuestra información. Por eso se debe
buscar un equilibrio entre la rebaja de la factura energética pero sin descuidar donde
alojamos nuestra información.
Es importante saber la localización del proveedor cloud y estar seguro de que la

normativa de la región donde está ubicado garantiza un nivel apropiado de protección de
datos de carácter personal de acuerdo con lo establecido en la LOPD (Ley Orgánica de
Protección de Datos). Además la localización no afecta sólo a la sede del proveedor, sino
que también se tiene en cuenta la localización del CPD. También hay que tener en cuenta
la privacidad, es difícil confiar la información sensible a terceros por ello cuantas más
garantías se consigan mejor.
Además, es importante tener en cuenta la escasez de estándares. Para solventar

estos problemas muchas empresas están optando por una combinación entre el cloud
privado y el público, llamado cloud. A pesar de no tener una escalabilidad casi infinita,
conlleva un compromiso razonable en cuanto a la protección y la confiabilidad en el
almacenamiento de los datos.
Otro inconveniente es la dificultad de descubrir fallos, no se puede saber si algo va

mal en la infraestructura real. En la infraestructura física, cuando el rendimiento no es
bueno existen una serie de métricas que permiten saber si hay un problema de hardware o
dónde está el cuello de botella. En la infraestructura virtualizada únicamente es posible
llegar hasta la información que ofrece la máquina virtual, que no siempre es suficiente
para identificar el problema (porque éste puede estar fuera del contexto de la máquina
virtual).
Por último, la influencia de máquinas virtuales vecinas puede afectar al rendimiento

del sistema, este inconveniente es conocido popularmente como el ‘vecino ruidoso’. Si un
vecino de una determinada máquina virtual está haciendo un uso muy intenso del host en
esa máquina su rendimiento se verá afectado, pero no se observarán síntomas de
saturación. Es algo que no se puede llegar a identificar por parte del cliente, ya que el
servicio ofrecido por esa máquina virtual irá lento, pero las métricas no reflejarán
ninguna saturación; y que el proveedor puede no considerar.
2.6 TECNOLOGÍAS DE VIRTUALIZACIÓN
Para comprender como funciona la computación cloud se ha de entender qué clase

de tecnología usa, y que características y beneficios aporta al sistema.
23
CAPÍTULO 2
Una de las tecnologías claves para el éxito de la computación cloud es la tecnología

de virtualización.
Es fácil confundir el concepto ‘cloud’ con virtualización, ya que tienen servicios

similares pero no intercambiables. La diferencia es lo suficientemente importante como
para afectar en la toma de decisiones de un proyecto.
La virtualización consiste en la creación, a través de software, de una versión

virtual de algún recurso tecnológico. Se trata de la tecnología que sustenta el modelo de
computación cloud.
En la Ilustración 4, se muestra la capa en la que trabaja la virtualización, dicha capa

se sitúa justo por encima del hardware del sistema, y por encima de la capa de
virtualización se crean las máquinas virtuales que a su vez contendrán las aplicaciones
que utilizará el usuario final.
Ilustración 4 - Estructura básica de un sistema virtualizado
El software de virtualización permite ejecutar múltiples sistemas operativos y varias

aplicaciones en el mismo servidor, y al mismo tiempo permite a las empresas reducir
costes TIC mientras que aumenta la eficiencia, la utilización y la flexibilidad de su
hardware existente. [VenVi]
La tecnología que está detrás de la virtualización se conoce como hipervisor. Este

sistema separa el ordenador de la infraestructura física. La virtualización crea servidores,
24
CAPÍTULO 2
estaciones de trabajo (workstations), almacenamiento y otros sistemas independientes de

la capa de hardware físico.
Una máquina virtual (MV) (Virtual Machine (VM), en inglés) es un ordenador que,
similar a un ordenador físico, ejecuta un sistema operativo y posee unas aplicaciones
instaladas. La única diferencia es que el hardware es virtual, no físico. El sistema
operativo que se ejecuta en la máquina virtual no es consciente de que se encuentra en un
entorno virtual y no físico. Las máquinas virtuales son creadas y alojadas en una
infraestructura virtual, y pueden utilizar todos los dispositivos virtuales – redes o
almacenamiento – que el hipervisor les proporciona.
Es importante entender que computación cloud no es lo mismo que virtualización,

la principal diferencia recae en la capacidad de la virtualización de manipular al
hardware, mientras que computación cloud consiste en el servicio resultante de tal
manipulación.
No todos los sistemas cloud utilizan virtualización, algunos sistemas pueden utilizar
una variante llamada paravirtualización. La paravirtualización es una tecnología similar a
la virtualización, pero mejora la eficiencia de las máquinas virtuales, obteniendo un
rendimiento similar al de un sistema nativo. Una de las plataformas que usa esta
tecnología es Xen. [VenVi]
En la Tabla 2 se enumeran las ventajas de la utilización de la virtualización y las

funcionalidades extra que aporta la paravirtualización.
Virtualización Paravirtualización
- Alta disponibilidad y recuperación ante - Mejora el rendimiento general de dispositivos
desastres de E/S, CPU y memoria
- Seguridad e independencia - Sistemas operativos invitados y el anfitrión
interactúan de manera directa con los
- Mejora de la eficiencia energética recursos físicos del computador
- Optimización del uso y control de los - Modelo basado en hipervisor
recursos - Poca carga que le da al procesador al no tener
que tener una capa completa de
- Portabilidad
virtualización
- Migración - Introduce en los sistemas operativos invitados
- Disminución del número de ordenadores permitiéndoles la comunicación directa
con el hipervisor
Tabla 2 - Características de la virtualización y paravirtualización
Los modelos de virtualización dependen del recurso que se abstrae y el ente que
virtualiza, por ello dependiendo de la situación se debe elegir una tecnología u otra.
25
CAPÍTULO 2
La virtualización tiene un alto rendimiento, siempre y cuando las tareas de las

aplicaciones utilizadas en la máquina virtual no requieran de un alto nivel de
procesamiento y que el host donde se hospeda la máquina no esté utilizando un gran
número de recursos. También comparte recursos con el host.
La paravirtualización no presenta problemas de rendimiento ante un alto nivel de

procesamiento, además goza de todas las ventajas de la virtualización y mejora las
deficiencias de ésta.
Además, ambas permiten un ahorro económico, debido a que la mayoría de

recursos se centralizan permitiendo una administración más óptima y con menor personal
técnico.
2.7 ALTERNATIVAS DE VIRTUALIZACIÓN
Existen dos tipos de hipervisores (o hypervisors), cada uno de ellos presenta sus
pros y sus contras. Estos tipos son: bare-metal y hosted.
Los hipervisores bare-metal no funcionan bajo un sistema operativo instalado sino

que acceden directamente al hardware. Por lo tanto permitirán obtener mejor rendimiento,
escalabilidad y estabilidad. Sin embargo, presentan el inconveniente de la limitación en el
hardware soportado por esta tecnología.
La tecnología bare-metal se adapta mejor a centros de datos empresariales, ya que

dispone de características avanzadas como pueden ser: administración de recursos, alta
disponibilidad (que veremos más adelante), seguridad y permite una administración
centralizada de la infraestructura de la organización.
Entre los hipervisores de este tipo destacan: VMware ESX y ESXi, Microsoft
Hyper-V, Citrix XenServer y Oracle VM. [HYP]
Los hipervisores hosted requieren la instalación previa de un sistema operativo

sobre el que ejecutarse, como cualquier otro tipo de instalación de una aplicación
software. A diferencia de bare-metal esta tecnología permite una mayor compatibilidad
con el hardware, ya que es el propio sistema operativo quien se encarga de la gestión de
los drivers. Se usa en estaciones de trabajo, principalmente para funciones de testeo,
desarrollo o para aquellos que necesiten más de un sistema operativo.
Los hipervisores más conocidos son: VMware Workstation/Fusion/Player/Server,

Microsoft Virtual PC, Oracle VM VirtualBox, Red Hat Enterprise Virtualization y
Parallels Desktop. [HYP]
26
CAPÍTULO 2
En este trabajo se usará Citrix XenServer ya que viene impuesto por la empresa.
2.8 XENSERVER
Como se ha indicado anteriormente, para la realización de este trabajo se utilizará el

software de paravirtualización XenServer basado en el hipervisor Xen.
2.8.1 INTRODUCCIÓN
Xen es un proyecto creado por la corporación de XenSource en la universidad de

Cambridge. La primera versión de Xen fue lanzada en 2003, totalmente de código
abierto. En octubre de 2007, Citrix Systems compró XenSource y renombró los productos
de XenSource por XenServer. En 2009, Citrix anunció que sus aplicaciones comerciales
estarían disponibles en código abierto y de manera gratuita bajo el nombre de Xen Cloud
Platform (XCP). A pesar de que Citrix compró XenSource, Xen es desarrollado y
mantenido por la comunidad como software libre, con licencia GPLv2. [CitGui]
XenServer utiliza el hipervisor de Xen Project como componente central de su

arquitectura para ofrecer abstracción y elasticidad de la infraestructura subyacente.
XenServer 6.0 es la última versión disponible de la plataforma de virtualización de

servidores. El paquete XenServer contiene todo lo necesario para gestionar un despliegue
de equipos virtuales que se ejecutan en Xen, el hipervisor de paravirtualización de código
libre con un rendimiento casi nativo.
XenServer se ejecuta directamente en el hardware del servidor sin necesitar un

sistema operativo ejecutándose por debajo, lo que mejora la eficiencia y escalabilidad del
sistema. XenServer funciona abstrayendo los componentes de la máquina física (como
discos duros, recursos y puertos) y asignándolos en las máquinas virtuales que se ejecutan
en él.
En los sistemas Xen, el hipervisor se sitúa en la capa más baja y con más
privilegios. Esta capa soporta uno o más sistemas operativos huéspedes que se ejecutan
en CPUs físicas. El primer sistema operativo alojado llamado Dominio de Control
(dom0) se ejecuta de manera automática cuando el hipervisor arranca y recibe los
privilegios especiales y acceso directo a todo el hardware físico. El Dominio de Control
es una máquina virtual con privilegios que ejecuta una herramienta de administración de
XenServer, llamada “toolstack” (una rutina de control para Xen). Además de
proporcionar funciones de administración para XenServer, el Dominio de Control
27
CAPÍTULO 2
también ejecuta el “driver stack” que proporciona máquinas virtuales creadas por los
usuarios con acceso a los dispositivos físicos.
XenServer está disponible en 4 versiones: gratuita, avanzada, empresas y platinium.

La principal diferencia entre las distintas versiones es el método de automatización de la
gestión de las máquinas y de la infraestructura. Para el desarrollo de este de trabajo se
usará XenServer versión gratuita.
2.8.2 FUNCIONAMIENTO
A continuación se explica de un modo breve el funcionamiento y configuración de

la aplicación XenServer y sus características básicas.
El hipervisor de XenServer es de tipo bare-metal y se sitúa en la capa de

virtualización, justo por encima de la capa hardware del sistema (ver Ilustración 5).
Ilustración 5 - Estructura básica de Xen
XenServer está diseñado para la administración de máquinas virtuales (MV) en

Windows y Linux.
Como se puede observar en la Ilustración 6, Xen tiene acceso a los dispositivos de

almacenamiento, red y a los controladores del hardware; de esta manera proporciona el
hardware virtualizado necesario para la creación de las máquinas virtuales reclamadas por
el usuario.
28
CAPÍTULO 2
Ilustración 6 - Arquitectura XenServer. Fuente: Citrix XenServer
Para facilitar el manejo de las máquinas virtuales XenServer permite crear “pools”
de hosts. Un “pool” es una entidad capaz de gestionar todas las máquinas virtuales en
conjunto, independientemente de donde se estén ejecutando, es decir, que en caso de
caída de un host físico, las máquinas virtuales se pueden volver a arrancar en otro host,
siempre que tengamos almacenamiento compartido.
Un “pool” se define como dos o más máquinas Citrix XenServer que componen
una misma entidad, de modo que pueden compartir recursos como máquinas virtuales,
almacenamiento, etc. de forma centralizada.
29
CAPÍTULO 2
Ilustración 7 - Ubicación del 'pool' dentro del sistema XenServer. Fuente: Citrix XenServer
En la Ilustración 7 se puede observar la situación de un “pool” en el sistema con

respecto a los hosts y recursos del mismo.
Cuando se usa un pool con almacenamiento compartido las máquinas virtuales se

pueden mover en caliente (XenMotions) entre los hosts que componen el pool, compartir
plantillas, repositorios de almacenamiento… Aporta también una agregación de recursos,
ya que si un host ya no puede asumir más carga de máquinas virtuales, la siguiente
máquina virtual, será levantada en otro host.
En cada “pool”, siempre tiene que haber un nodo designado como “master”,
mientras que los otros miembros se denominan “slaves”. El rol master se caracteriza por
“exponer” la administración del clúster de forma centralizada y reenvía los comandos a
los otros nodos si es necesario.
XenServer ofrece una serie de funcionalidades complementarias que se utilizarán

durante el despliegue. El hipervisor XenServer obliga a una homogeneidad hardware en
los hosts del “pool. Para la configuración de las máquinas virtuales se utilizarán las
siguientes características:
- Generación de plantillas
o Limpias y autoconfiguradas
o Homogeneidad de sistemas
- Despliegue rápido por clonación

o Sencillo desde XenCenter
30
CAPÍTULO 2
- Preparación para pruebas “catastróficas”

o Realización de snapshot, guarda una imagen del estado de una máquina
virtual. Copia tanto datos como configuraciones en un archivo asociado a
dicha máquina.
o “Snapshots” es una característica muy útil de XenServer, proporciona un
punto en el tiempo del estado del disco.
o Por ejemplo, si se quiere realizar un test para actualizar una aplicación
instalada en la máquina virtual. Usando “snapshot”, permite revertir el estado
de la maquina a un estado anterior a la actualización, si la actualización
provoca algún fallo en el funcionamiento de la máquina virtual.
o También, “snapshot” proporciona una manera rápida de crear plantillas que
pueden ser exportadas para funciones de backup o usadas para crear máquinas
virtuales rápidamente.
o Cuando creamos un “snapshot”, el resultado es una máquina virtual similar a
la plantilla. Los “snapshots” contienen toda la configuración de la máquina
virtual permitiendo exportar la “snapshot” y restaurarla en caso de necesitarlo.
o Es aconsejable utilizarlo para evitar perder tiempo con un “vuelta a atrás”.
- Gestión de memoria extendida: Memory Ballooning
- High Availability (alta disponibilidad): es un protocolo de diseño del sistema y su

implementación asociada que asegura un cierto grado absoluto de continuidad
operacional durante un período de medición dado. Disponibilidad se refiere a la
habilidad de la comunidad de usuarios para acceder al sistema, someter nuevos
trabajos, actualizar o alterar trabajos existentes o recoger los resultados de trabajos
previos. Si un usuario no puede acceder al sistema se dice que está no disponible.
 Después de haber creado las máquinas virtuales en el entorno de XenServer,

hay que garantizar que el servicio ofrecido por esas máquinas virtuales no se
vea afectado por la caída de un host físico.
 La “alta disponibilidad” es una característica de XenServer diseñada para
asegurar que las máquinas virtuales estarán siempre disponibles y ofrecer un
nivel óptimo de servicio.
 Cuando se habilita la opción de “alta disponibilidad” en el “pool”, XenServer
monitoriza continuamente la salud de los hosts. Si un host falla, las máquinas
virtuales que corren en el host caído pasan automáticamente a otro host
disponible. Además, si el host caído es el “pool master”, la “alta
disponibilidad” elige otro host automáticamente para ser el nuevo “pool
master”.
 Las máquinas virtuales que se ejecutan bajo “alta disponibilidad” son llamadas
“protegidas”.
31
CAPÍTULO 2
- DRS (consumo dinámico).
- Cliente sencillo y completo: XenCenter. XenCenter es una herramienta (Windows) de

gestión del sistema cloud. Proporciona una interfaz gráfica que permite la instalación
completa, configuración y gestión de las máquinas virtuales.
2.8.3 OTRAS CARACTERÍSTICAS
Además de lo comentando anteriormente respecto a la configuración y gestión de

las máquinas virtuales, XenServer cuenta con otras funcionalidades, relacionadas con el
almacenamiento y la red de interconexión, importantes que conviene configurar para
obtener el mayor rendimiento de XenServer.
GESTIÓN DE USUARIOS
En primer lugar es importante citar la gestión de usuarios, servicio de gran
importancia para poder acceder a la gestión de XenServer; se encarga de definir usuarios,
grupos, roles y permisos permite controlar quien tiene acceso a los hosts y “pools” de
XenServer y que acciones pueden ejecutar.
En XenServer Free cuando se crean nuevos usuarios, estos reciben acceso total al
“pool”. Por eso todos los usuarios tendrán rol de administrador en el “pool”.
ALMACENAMIENTO
Otra característica relevante y a la que se le presentará mayor importancia en la fase
de pruebas es el almacenamiento. En un entorno XenServer, los dispositivos de
almacenamiento físico están disponibles en un repositorio sobre el que se crea una base
de datos que permite a los hosts de XenServer poder conectar con el almacenamiento.
En XenServer el almacenamiento se organiza a través de repositorios de

almacenamiento (storage repository, SR), que contienen imágenes de disco virtual,
dispositivos de bloque físico y dispositivos de bloque virtual. Un repositorio de
almacenamiento (SR) es una abstracción del dispositivo de disco físico, que pueden ser
un dispositivo local o un dispositivo en SAN. En el repositorio de almacenamiento de
XenServer, las imágenes de disco virtual se crean como una abstracción del
almacenamiento de objetos que pueden ser presentados a una máquina virtual.
En XenServer hay tres modos de construir el almacenamiento
La más usada e importante es SAN (Storage Area Network) que consiste en una red
de almacenamiento dedicada que proporciona acceso, los sistemas SAN son usados
principalmente para crear dispositivos de almacenamiento, como arrays de discos,
32
CAPÍTULO 2
accesible a los servidores de manera que los dispositivos aparecen como conectados
locamente al sistema operativo; normalmente requiere el uso de Fibre Channel.
Otras opciones serían DAS (Direct Attached Storage): Es un subsistema de

almacenamiento que está unido a un servidor o estación de trabajo usando un cable; y
NAS (Network Attached Storage): Se trata de un almacenamiento de datos a nivel de
archivo conectado a una red que proporciona acceso a datos a los distintos clientes.
Los modelos de almacenamiento comentados anteriormente se basan en diferentes

tipos de tecnología como son; discos locales, NFS (Network File System), iSCSI (Internet
Small Computer System Interface) y FC (Fibre Channel).
NETWORKING
XenServer proporciona una serie de características de red que permiten crear redes
para las máquinas virtuales de la misma manera que si fueran redes para dispositivos
físicos (ver Ilustración 8).
Por eso es posible conectar máquinas virtuales a la 'red de producción' como si

fueran maquinas físicas o poder crear redes privadas con un host o un “pool” para
funciones de testeo, desarrollo o seguridad. También es posible conectar máquinas
virtuales a una VLAN usando una configuración VLAN estándar.
Las máquinas virtuales se conectan a las redes usando NICs virtuales, conocidas
como interfaces virtuales que enviar y recibir tráfico de la red.
La red lógica será llamada 'red de producción' y agrupará todas las máquinas
virtuales de un mismo host; ese host controla la 'red de producción' mediante su propia
NIC física.
La NIC física proporcionará conexión local y a Internet al host, permitiendo a todas

las máquinas virtuales conectarse.
Existen varios tipos modelos de red disponibles, siendo la más usada single-server
privado, este tipo de red no está unido a una interfaz de red física y puede ser usado para
proporcionar conectividad entre las máquinas virtuales que son ejecutadas en un host
determinado – el tráfico de red se mantiene aislado y no puede llegar a otros hosts.
Normalmente a este tipo de red se le refiere como interna. Será la opción elegida en el
despliegue.
33
CAPÍTULO 2
Ilustración 8 - Networking en XenServer
34
CAPÍTULO 3
CAPÍTULO 3. INFRAESTRUCTURA
CLOUD DESPLEGADA EN BILIB
En este capítulo se realiza un informe detallado de la tecnología, tanto software

como hardware, usada durante el despliegue del trabajo. Además de comentar la
topología de las redes.
3.1 INTRODUCCIÓN
Tal y como se ha adelantado previamente, para la realización de este trabajo se ha

utilizado el equipamiento perteneciente a Bilib, cedido por red.es, el cual se encuentra
alojado y mantenido por la empresa AreaProject.
Todo el equipo utilizado se encuentra alojado en un centro de procesamiento de

datos (CPD). Un centro de procesamiento de datos es aquella ubicación donde se
concentran los recursos necesarios para el procesamiento de la información de una
organización, en este caso Bilib.
El desarrollo del trabajo se centrará en el despliegue de un software de la capa IaaS

en el servidor físico disponible. Una vez terminado y creada una cloud de tipo privada; se
pondrá en marcha una aplicación de prueba en la capa SaaS para testear la plataforma.
Para medir el rendimiento del equipo paravirtualizado se utiliza un benchmark. Los

benchmarks son una técnica empleada para estimar el rendimiento de un sistema o
componente. Consta de un conjunto de procedimientos que son utilizados para poder
realizar pruebas de comparación.
35
CAPÍTULO 3
En la Ilustración 9 se muestra un diagrama simplificado del despliegue sobre el que

se ha realizado el trabajo.
Ilustración 9 - Esquema básico del despliegue

El despliegue consiste en un esquema de computación clásico. En primer lugar
consta de una unidad de procesamiento compuesta por varios servidores (agrupados en un
blade) que se encargan de procesar los datos. También incluye una unidad de
almacenamiento, encargada de almacenar datos, conectada mediante cableado Fibre
Channel a la unidad de procesamiento. Por último, todo el sistema está dotado de
conectividad a la red local de AreaProject y a la red exterior.
El sistema usado en el trabajo utiliza un método de almacenamiento basado en una

SAN en la que se almacenan todos los datos del sistema cloud. La SAN está formada por
arrays de discos que forman un único repositorio de almacenamiento (SR), otorgando
gran rapidez a las operaciones del servidor. Además, utiliza un sistema NAS para guardar
las copias de seguridad del sistema.
36
CAPÍTULO 3
Durante del desarrollo del trabajo se usará una red de Fibre Channel unida por
switches Fibre Channel, formando una red de conexión punto a punto. Las razones que
nos llevan a usar este modelo es que venía impuesto por la empresa, aunque es un
material bastante más caro y menos flexible que iSCSI.
Para este trabajo se utiliza una red single-server privada, descrita anteriormente,
gestionada por un par de switches, debido a la simplicidad del sistema y la complejidad
de las otras alternativas propuestas.
3.2 UNIDAD DE PROCESAMIENTO
La unidad de procesamiento se encuentra en uno de los armarios del centro de

procesamiento de datos. Consiste en seis servidores blade agrupados en el enclosure
‘Albacete’.
Un servidor blade es un tipo de computadora para los centros de procesamiento de

datos; específicamente diseñado para aprovechar el espacio, reducir consumo y
simplificar su explotación. Cada servidor está formado únicamente por un
microprocesador, memoria y buses. Es decir, por separado no son funcionales; pero una
vez se conectan al chasis del armario se pueden utilizar para el procesamiento de datos.
En la Ilustración 10 se muestra la disposición de los servidores blade usados

durante el despliegue, en el enclosure ‘Albacete’
Ilustración 10 - Organización del enclosure Albacete. Fuente: Bilib
37
CAPÍTULO 3
En el enclosure ‘Albacete’ hay disponibles seis servidores de los cuales únicamente

se utilizarán cuatro de ellos para formar el sistema XenServer 6.0, en concreto los que se
muestran en la Tabla 3:
Servicio de virtualización
SRVXEN01 Física (Blade)
Citrix XenServer
Citrix XenServer
Citrix XenServer
SRVPROD01 Física (Blade)
Citrix XenServer
Tabla 3 - Servidores usados durante el despliegue
El modelo de los servidores blade es HP BL465 G6 con XenServer 6.0 instalado

como sistema operativo. Cada servidor cuenta con dos LUN (número de unidad lógica) y
una tarjeta de red propia usado por el almacenamiento SAN del sistema.
3.3 UNIDAD DE ALMACENAMIENTO
El sistema de almacenamiento se encuentra en un armario contiguo al de la unidad

de procesamiento. En él se aloja la unidad de almacenamiento de datos y la unidad
encargada de almacenar las copias de seguridad.
Se compone principalmente de una red de área de almacenamiento (Storage Area

Network, SAN). Se trata de una arquitectura completa que agrupa los siguientes
elementos:
- Una red de alta velocidad de canal de fibra (Fibre Channel)

- Un equipo de interconexión dedicado (conmutadores, puentes, etc)
- Elementos de almacenamiento de red (discos duros)
El rendimiento de la SAN está estrechamente relacionado con el tipo de red que se

utiliza. En este caso se utiliza una red de Fibre Channel, que proporciona un ancho de
banda de unos 100 megabytes/segundo (1000 megabits/segundo) creando una red similar
a una Gigabit Ethernet.
Fibre Channel es un estándar, está optimizado para almacenamiento y otras

aplicaciones de alta velocidad.
38
CAPÍTULO 3
Para este trabajo se utiliza una topología punto a punto, siendo la interfaz genérica
y la interconexión con la capa física de cada nodo. No ofrece ninguna ventaja adicional
pero su implementación es la más sencilla.
La SAN permitirá compartir datos entre varios equipos de la red sin afectar al
rendimiento ya que el tráfico de SAN está totalmente separado del tráfico de usuario. Son
los servidores de aplicaciones que funcionan como una interfaz entre la red de datos
(Fibre Channel) y la red de usuario (Ethernet).
El modelo de SAN usado será un HP StorageWorks 4400. Es un sistema de

almacenamiento RAID (Redundant Array of Independent Disks), que ofrece alto
rendimiento y escalabilidad bajo demanda.
Este sistema de almacenamiento está diseñado para centro de procesamiento de

datos (CPD), donde mejorar el uso de almacenamiento y la escalabilidad son cuestiones
vitales. Reúne aplicaciones específicas para la realización de rápidas transacciones
entrada/salida. Además, proporciona capacidad de expansión, replicación instantánea y
una administración del almacenamiento bastante simple.
La estructura de este tipo de almacenamiento es la siguiente:
1. Recinto de discos: Esto es el cajón de discos o "Disk drive enclosure". Tiene 14

bahías con capacidad para 14 discos duros.
2. Switches: Aquí será donde se conectarán los cables de fibra de los cajones de
discos, las controladoras o los servidores (la red SAN - Storage Area Network) a los
adaptadores de bus del host (HBA). Todo ello por duplicado, tanto el cableado como los
switches.
3. Controladores: Se encargan de monitorizar y controlar el sistema.
Además de la SAN, la unidad de almacenamiento posee una Network Attached

Storage (NAS). La NAS es una tecnología de almacenamiento dedicada a compartir la
capacidad de almacenamiento de un servidor.
Esta NAS será utilizada como almacenamiento de las copias de seguridad

realizadas al sistema. En concreto la máquina usada para dicha labor será un HP
StorageWorksX1800 G2.
39
CAPÍTULO 3
3.4 REDES
El CPD cuenta con dos equipos de seguridad (firewalls). Cada equipo de seguridad
está formado por dos componentes hardware; un componente para seguridad perimetral y
un componente para protección IDS (Intrusion Detection Prevention System).
Por tanto, el CPD dispondrá tanto de seguridad perimetral como de protección IDS
con componentes configurados en modo Failover Active/Standbye.
El firewall IDS no tienen reglas de filtrado, solamente actúa como filtro IDS.
Donde la política de tráfico se definirá permitiendo el tráfico de salida y denegando

todo tráfico entrante desde Internet.
3.4.1 TOPOLOGÍA DE LA RED
Cada servidor del clúster posee su propia tarjeta de red, con una dirección IP
individual para cada servidor.
La conexión de cada servidor con las distintas VLANs se ha establecido de la

siguiente manera (ver Ilustración 11).
Se ha utilizado una configuración de uplink activo/activo con 802.1Q (tagging)

para todas las VLANs, con un único enlace desde cada Virtual Connect (módulo
encargado del armario de las conexiones virtualizadas de los blades). Esto es muy
recomendable en entornos de virtualización (XenServer) en el que los servidores crean su
propio switch virtual.
40
CAPÍTULO 3
Ilustración 11 - VLANs pertenecientes al despliegue. Fuente: Bilib
Ilustración 12 - Gestión de las VPNs. Fuente: Bilib
En la Ilustración 12 se muestra como los routers y switches del despliegue

gestionan las VLANs de la estructura del sistema.
A la VLAN 1 se le asignará la Red Gestión y el resto de VLANs se destinarán a la

Red Pública, excepto la red 8 que tendrá conexión directa con la red de Bilib.
41
CAPÍTULO 3
Todas las redes son de tipo single-server, como ya se ha comentado anteriormente,

y son administradas por dos switches mediante el uso de vSwitch (switch virtual creado
por XenServer para la gestión de las redes virtuales).
3.5 DESPLIEGUE SOFTWARE
El material software necesario para el despliegue software se compone

principalmente de una aplicación encargada de la configuración del almacenamiento del
EVA SAN llamado HP Command View EVA, una aplicación web que permite gestionar
y monitorizar el array virtual del sistema de almacenamiento.
También es necesario instalar XenServer 6.0 versión gratuita en los distintos hosts
usados durante el despliegue. La instalación se realiza en el espacio reservado en la SAN
que tiene cada uno de los hosts. Donde se configuran datos relativos a la localización y
fecha, datos de conexión a Internet (dirección IP, gateway,...), usuario y contraseña para
poder acceder al host desde XenCenter y administrarlo.
Por último se necesita XenCenter para poder acceder a la gestión de hosts

XenServer desde cualquier equipo con Windows.
Ilustración 13 - Esquema software utilizado en el despliegue basado en la arquitectura de XenServer
42
CAPÍTULO 3
A través de XenCenter se ha creado una estructura interna que reúne los servidores
y el almacenamiento SAN (ver Ilustración 13). En concreto, se compone de un “pool”
llamado 'Bilib POOL' que incluye los cuatro hosts XenServer (SRVXEN01, SRVXEN02,
SRVXEN03 y SRVXEN04) para facilitar la gestión de los mismos. Además, se le ha
asignado como almacenamiento la SAN configurada anteriormente con el nombre
'SAN_BILIB', cómo se puede apreciar en la Ilustración 14 toda la infraestructura ha sido
creada mediante XenCenter.
Ilustración 14 – Captura de pantalla del pool creado desde XenCenter
XenCenter permite manejar todas las opciones de configuración de los hosts,

además de poder monitorizar su actividad. A partir de la estructura descrita
anteriormente, XenCenter podrá crear máquinas virtuales con un sistema operativo
determinado. En concreto, en nuestras pruebas habrá dos tipos de máquinas virtuales
(básica y avanzada) donde la principal diferencia recaerá en los recursos hardware
asociado a cada una ellas.
Las máquinas virtuales serán creadas en un host XenServer, que a su vez forma
parte del “pool”. El sistema operativo utilizado por cada máquina virtual será Ubuntu
Server 13.10. Además, en la máquina virtual cliente se instalará el Benchmark CloudSuite
Data Serving formado por YCSB y Cassandra.
43
CAPÍTULO 3
44
CAPÍTULO 4
CAPÍTULO 4. EVALUACIÓN DEL

SISTEMA
En el cuarto capítulo se trata la evaluación del sistema. Para comenzar, se describen

las distintas aplicaciones utilizadas para dicha evaluación. A continuación se habla acerca
de los parámetros modificables durante la evaluación, y por último se exponen los datos
calculados y se muestran las conclusiones obtenidos a partir de ellos.
4.1 DESCRIPCIÓN DEL CASO DE ESTUDIO
Sobre la estructura anteriormente desplegada se realizará una evaluación del sistema

mediante una batería de pruebas basadas en unos determinados casos de estudio.
Para ello se utilizará CloudSuite Data Serving [Parsa]. CloudSuite es un conjunto de

pruebas para sistemas Cloud. Se compone de ocho tipos de pruebas que han sido
seleccionadas en base a su popularidad en los centros de datos de hoy en día.
CloudSuite cubre un amplio rango de categorías de aplicaciones comúnmente usadas

en los centros de datos en la actualidad. Para nuestro análisis nos centraremos en la
categoría ‘Data Serving’ que mide el rendimiento del sistema focalizando la carga de
trabajo en el almacenamiento.
La categoría ‘Data Serving’ de CloudSuite se compone de dos aplicaciones, un

gestor de base de datos NoSQL llamado Cassandra (utilizado para gestionar los datos que
se usarán en las pruebas de testeo del sistema) y un benchmark especializado en sistemas
cloud llamado YCSB (utilizado para medir el rendimiento del sistema). [Parsa]
45
CAPÍTULO 4
El funcionamiento de este benchmark, que se detallará más adleate, es como sigue:
Primero se cargan, en la base de datos, los datos a ejecutar en las pruebas mediante
Cassandra [Cass]. Cassandra es un gestor de base de datos con una estructura de
almacenamiento basado en columnas, escrito en Java y de libre distribución. Está
optimizado para la escritura y basado en DynamoDB, un servicio de bases de datos
NoSQL rápido y totalmente gestionado que permite almacenar y recuperar de manera fácil
y sencilla cualquier cantidad de datos, así como atender cualquier nivel de tráfico de
solicitudes para obtener una mayor disponibilidad y durabilidad. [ADyn]
Para la parte de ejecución de datos, se utiliza el benchmark YCSB [YCSB]. YCSB es

un servicio diseñado para realizar pruebas de rendimiento sobre bases de datos. Permite
crear cargas de trabajo para poder analizar el comportamiento de los gestores ante
diferentes entornos de cargas de trabajo y poder realizar comparativas de bases de datos.
El objetivo que se pretende medir con este benchmark es el rendimiento de las

máquinas virtuales del servidor dependiendo de su configuración hardware y la carga de
trabajo introducida. Este proceso se llevará a cabo mediante operaciones de lectura,
inserción, escaneo y actualización.
Se prueban distintas configuraciones de despliegue de los servicios cloud, las

denominadas pruebas internas y pruebas externas. En el Escenario 1 las pruebas se realizan
desde dos máquinas virtuales creadas en el interior del clúster y en el Escenario 2 las
pruebas se realizan desde una máquina interna y una externa al clúster. Estas pruebas se
dividen en dos fases: carga y ejecución.
En las pruebas se testeará el rendimiento del sistema de dos modos: aumentando el

número de operaciones por segundo que debe realizar o variando el número de hilos que se
ejecutan de manera simultánea. Estos dos modos definen dos niveles básicos de
evaluación.
- Productividad: El nivel de rendimiento se centra en la latencia de las peticiones

cuando la base de datos está soportando una carga. La latencia es crítica en los
sistemas que ofrecen servicios, ya que por lo general hay un usuario esperando al
otro lado. Sin embargo, hay una desventaja inherente entre la latencia y el
rendimiento: al aumentar la cantidad de carga, la latencia de las peticiones se
incrementa; de esta manera se produce retrasos en el disco, CPU, etc. Normalmente
los diseñadores de la aplicación deben establecer una latencia aceptable y un
número de servidores suficiente para lograr el rendimiento deseado. Un sistema con
mejor rendimiento alcanzará la latencia deseada con un menor número de
servidores.
46
CAPÍTULO 4
El nivel de productividad del benchmark pretende caracterizar este equilibrio para

cada sistema de base de datos mediante la medición de la latencia, al aumentar la
carga, hasta el punto en el que el sistema de base de datos se satura y el rendimiento
deja de aumentar.
Para desarrollar este nivel de referencia, se necesita un generador de carga de

trabajo, el cual servirá para dos propósitos: definir el conjunto de datos a cargar en
la base de datos y ejecutar operaciones con el conjunto de datos mientras se mide el
rendimiento.
YCSB se ocupa de ambos propósitos. Un conjunto de parámetros definen la

naturaleza del conjunto de datos y de las operaciones (transacciones) utilizadas con
los datos.
YCSB permite definir el rendimiento ofrecido con un parámetro mediante la línea

de comandos, y obtener informes de latencia.
- Escalabilidad vertical: Un aspecto clave de los sistemas cloud es su capacidad de

escalabilidad, de modo que se pueda manejar más carga. El nivel de escalabilidad
vertical examina el impacto en el rendimiento de la ampliación de las capacidades
hardware de las máquinas virtuales.
4.2 APLICACIÓN DESPLEGADA EN EL SISTEMA
Una vez completado el despliegue, tanto hardware como software, de los

componentes básicos de la infraestructura cloud se pondrá en funcionamiento el servicio
ofrecido, basado en el benchmark CloudSuite Data Serving.
Para ello se instalará y ejecutará en las máquinas virtuales del sistema. Como se ha
comentado en el apartado anterior CloudSuite Data Serving se compone de dos
aplicaciones principales, Cassandra e YCSB; las cuales se describen a continuación.
4.2.1 CASSANDRA
Cassandra es un gestor de base de datos no-relacionales [Cass]. Hoy en día es un

proyecto de Apache. Fue desarrollado por Facebook en 2008 y liberado como un proyecto
Open Source en Google Code. En 2009 se convirtió en un proyecto “Apache Incubator”, y
finalmente en 2010 se convirtió en un proyecto TOP-LEVEL. Está implementado en Java.
47
CAPÍTULO 4
Las bases de datos NoSQL son sistemas de almacenamiento de información que no

cumplen con el esquema entidad-relación. Mientras que las tradicionales bases de datos
relacionales basan su funcionamiento en tablas, joins y transacciones ACID (atomicidad,
coherencia, aislamiento y durabilidad), las bases de datos NoSQL no imponen una
estructura de datos en forma de tablas y relaciones (no imponen un esquema pre-fijado de
tablas). Esto hace que a estas bases de datos también se les denomine “schema-less” o
“schema-free”.
Las bases de datos NoSQL permiten almacenar información en otros formatos como
clave-valor (similar a tablas Hash), mapeo de columnas, documentos o grafos. Además de
la carencia de un esquema “predeterminado”, la principal característica de las bases de
datos NoSQL es que están pensadas para manipular enormes cantidades de información de
manera muy rápida. Para ello suelen almacenar toda la información que pueden en
memoria (utilizando el disco como una mera herramienta de persistencia), y están
preparadas para escalar horizontalmente sin perder rendimiento. Suelen funcionar bastante
bien en hardware de bajo coste.
Cassandra está orientado a proporcionar alto rendimiento y escalabilidad lineal. Es

capaz de manejar varios terabytes de datos si lo necesita y puede manejar millones de
ficheros, incluso en un clúster pequeño. Es una base de datos descentralizada. Esto
significa que no existe la estructura maestro-esclavo que existe en otra bases de datos como
HBase [HBas]. En Cassandra todos los nodos son idénticos y tienen la misma
funcionalidad.
Las características más importantes de Cassandra son:
- Escalabilidad: El rendimiento de las operaciones de lectura y escritura se

incrementa con el aumento de la capacidad hardware de las máquinas virtuales.
- Consistencia configurable: Las operaciones de lectura y escritura ofrecen un nivel

configurable de consistencia.
- Lenguaje ‘query’: Cassandra introduce CQL (Lenguaje Query de Cassandra), una

alternativa similar a SQL para la interfaz.
- Tolerancia a fallos: Los datos son replicados en múltiples nodos miembros del
clúster. Por tanto, en caso de que un nodo caiga, los datos que almacena éste no se
pierden ya que otros nodos del clúster almacenan una copia de estos datos.
Además, el nodo que cae es reemplazado de forma muy rápida, y por tanto, no se
nota su ausencia al no haber prácticamente tiempos de inactividad.
- Descentralización: Toda su estructura está basada en un clúster de nodos que son

totalmente idénticos entre ellos, es decir, no hay una jerarquía de nodos. Al no
48
CAPÍTULO 4
tener un punto central donde se guarda la información, no existe un punto único de

fallos y, por tanto, tampoco se producen cuellos de botella.
- Flexibilidad: Por cada nodo que se añade al clúster, el rendimiento de lectura y

escritura o de los volúmenes de información que fluyen a través del clúster se ve
incrementado de forma lineal.
- Alta disponibilidad: Gracias a las características anteriores, la información está

siempre disponible. Por eso es un sistema adecuado para aplicaciones que no
pueden permitirse perder datos.
Arquitectura de Cassandra
La arquitectura de Cassandra tiene una alta complejidad ya que es un sistema de
almacenamiento que necesita trabajar en un entorno de producción de alta disponibilidad,
donde su característica más importante es la persistencia de datos.
Los módulos que componen Cassandra contienen una serie de bloques que le
permiten ser un sistema de almacenamiento distribuido: particionado, replicación, adhesión
de miembros, manejo de caídas y escalado del sistema. Todos ellos trabajan en sincronía
para manejar correctamente las peticiones de lectura y escritura.
Cassandra no soporta un modelo de datos relacional completo. En su lugar,

proporciona clientes con un modelo de datos simple que soporta un control dinámico sobre
la disposición de los datos y el formato. Dentro del modelo de datos que define Cassandra
se pueden encontrar cinco tipos de estructuras de datos.
- Column: Es una 3-tupla que guarda un nombre, un valor y un tiempo de

modificación o acceso. Es la estructura básica de Cassandra.
- SuperColumn: Es una 2-tupla, contiene un nombre y un valor pero no un tiempo.

Trabaja como un contenedor de una o más columns.
- ColumnFamily: Similar a las tablas de las base de datos relacionales, puede

contener un número infinito de filas. Está formada por un nombre y un mapa con
una clave/valor que contiene Columns.
- SuperColumnFamily: Es una gran estructura de datos similar a ColumnFamily

pero que en lugar de tener Columns dispone de un mapa de SuperColumns.
49
CAPÍTULO 4
- Espacio de claves: Es la mayor estructura de datos usada en Cassandra, es capaz de

almacenar ColumnFamilies y SuperColumnFamilies. Guarda bastante similitud
con el Esquema de las BBDD relacionales.
En la Ilustración 15 se muestra la estructura básica usada por Cassandra.
Ilustración 15 - Arquitectura de Cassandra. Fuente: Apache Cassandra

Pss
PUESTA A PUNTO DE LA BASE DE DATOS
Para poder ejecutar el benchmark YCSB, primero debemos configurar la base de

datos con Cassandra en el nodo donde se van a ejecutar las pruebas.
Durante la fase de carga se introducen los datos que han sido seleccionados en la
base de datos para ejecutar las pruebas. Se debe crear un “espacio de claves” con factor de
replicación 1, dentro del “espacio de claves” se crea una columna de familia para
almacenar los datos.
Una vez haya sido configurada la estructura de la base de datos en el nodo donde se
va a ejecutar el Benchmark (nodo servidor), se debe modificar la configuración de
Cassandra en cada uno de los nodos que participarán en las pruebas (nodo servidor y nodo
50
CAPÍTULO 4
cliente/s), de esta manera se permitirá que los nodos puedan conectarse entre sí y ofrecer al
nodo cliente la posibilidad de acceder a la base de datos del nodo servidor para cargar los
datos sobre los que se trabajará durante las pruebas.
Además, se instala en todas las máquinas virtuales Apache y Java JDK para el
correcto funcionamiento del Benchmark.
4.2.2 YCSB
YCSB (Yahoo Cloud Systems Benchmark) [YCSB] es una herramienta que se utiliza
para medir el rendimiento de varios sistemas en el cloud. Está diseñada en código abierto
permitiendo que otras personas contribuyan a su desarrollo y mejora.
Se centra en los sistemas que proporcionan operaciones de lectura y escritura en los

datos en línea (servicios online). El entorno consiste en una carga de trabajo que genera el
cliente y un paquete de cargas de trabajo estándar (workload) que cubren partes
interesantes del espacio de actuación (workload de lectura pesada, workload de escritura
pesada, workload mixto, etc.)
YCSB es un programa Java que genera datos para ser cargados en la base de datos y
generar las operaciones con las cuales crearemos la carga.
Ilustración 16 - Arquitectura YCSB. Fuente: www.dcomp.sor.ufscar.br
En la Ilustración 16 se muestra la arquitectura de YCSB. El ejecutor de ‘workload’

acciona múltiples hilos. Cada hilo ejecuta una serie de operaciones secuenciales mediante
51
CAPÍTULO 4
llamadas a la base de datos, tanto para la fase de carga de datos como para la fase de
ejecución de una carga de trabajo (transacción). Los hilos limitan la velocidad con la que
se generan las solicitudes, para poder controlar directamente la carga que se ejecuta. Los
hilos también miden la latencia y el rendimiento logrado de las operaciones, e informan de
estas medidas al módulo estadístico.
YCSB utiliza una serie de propiedades para definir las operaciones, que se dividen en
dos grupos:
- Propiedades del ‘workload’: Propiedades que definen la carga de trabajo o

workload. Por ejemplo, el porcentaje de lectura/escritura, la distribución usada o
tamaño y número de campos del registro.
- Propiedades del tiempo de ejecución: Propiedades específicas para una prueba

determinada. Por ejemplo, el gestor de base de datos empleado (en nuestro caso
Cassandra), propiedades usadas para iniciarla (hostnames), número de hilos,…
Un aspecto importante de YCSB es su extensibilidad: es fácil definir nuevos tipos de

carga de trabajo e implementar una capa de interfaz de datos.
YCSB no tiene utilidad si se usa aislado, su utilidad aparece cuando se combina con
un gestor de base de datos que permita interactuar con un sistema de datos. Para este
trabajo hemos utilizado Cassandra como aplicación para la gestión de la base de datos.
Cómo trabajar con YCSB

Para poder ejecutar YCSB hay que tener en cuenta una serie de consideraciones
previas, los pasos que hay que seguir para ejecutar (en un único nodo) la carga de trabajo
adecuada, y que pasaremos a describir en detalle, son:
1) Establecer el sistema de base de datos a probar: Se puede realizar en un sólo

equipo actuando como local o en varios remotos, dependiendo de la configuración a
probar.
Antes de ejecutar el cliente YCSB, se deben crear las tablas de la base de datos. Estas
tablas se crean manualmente desde el propio Cassandra a través de línea de comando.
La información en las bases de datos relacionales se almacenan en forma de filas,

pero en Cassandra la información se almacena en columnas con pares clave-valor y clave-
mapa para múltiples valores, que se agrupan en column families (familia de columnas).
Las bases de datos que utilizan filas contienen todos los campos de un registro
almacenados de forma contigua, siendo muy eficiente si se accede a registros de manera
52
CAPÍTULO 4
aleatoria. Cuando la base de datos se estructura en columnas es idóneo para los acceso
frecuentes al mismo conjunto de datos.
Las column families se crean por defecto cuando la base de datos es creada, pero las
columnas se pueden agregar a las column families en cualquier momento. Por otra parte,
las columns se agregan solo a las claves especificadas, por lo tanto diferentes claves
pueden tener distintos números de columnas en cualquier columns family.
Las tablas se crean antes de iniciar el servidor.Se crean distintas tablas dependiendo
de la carga de trabajo elegida. En este caso se creará una única tabla llamada 'usertable' con
un esquema flexible de columnas, que será la encargada de trabajar con los 'workloads'.
2) Seleccionar una capa apropiada como interfaz de base de datos: Consiste en una
capa de interfaz de base de datos en código Java que ejecuta las operaciones de lectura,
inserción, actualización, borrado y escaneo de datos.
Estas llamadas son generadas por YCSB mediante línea de comandos, donde se
especifica el nombre de la clase a utilizar. Por último, el cliente carga de forma dinámica la
interfaz de la clase.
En este caso se utiliza Cassandra porque CloudSuite Data Serving así lo específica,
además de ser uno de los gestores de base de datos más rápidos y fiables de usar. [NSDs]
3) Elegir el 'workload' adecuado: El 'workload' (carga de trabajo) define los datos que
se pueden cargar en la base de datos durante la fase de carga y las operaciones que se
ejecutarán con esos datos en la fase de ejecución.
Los parámetros configurables son:

- threads: Número de hilos que se van a ejecutar de manera simultánea en una prueba.
Por defecto, YCSB usa un único hilo, pero es posible añadir más hilos. Esto es habitual
para incrementar la carga generada.
Este parámetro permitirá simular la existencia de varios usuarios lanzando peticiones al
sistema gestor de la base de datos de manera simultánea.
- target: Determina la productividad, marca el número de operaciones por segundo que

realiza el nodo servidor. Por defecto el nodo servidor realizará todas las operaciones
por segundo que pueda. Por ejemplo, si cada operación tarda 100 milisegundos de
media, el servidor podrá realizar 10 operaciones por segundo por hilo. Para generar
latencia que afecte a la productividad es conveniente probar distintas cantidades de
operaciones por segundo, y medir la latencia resultante.
Mediante este parámetro existirá la posibilidad de simular ejecuciones con gran carga
de procesamiento o cargas más ligeras según se necesite.
53
CAPÍTULO 4
- s: Es un parámetro utilizado para comprobar el estado del sistema durante ejecuciones

largas.
4) Cargar los datos: Las cargas de trabajo tienen dos etapas: la de carga (que
especifica los datos a insertar) y la de las transacciones (que especifica las operaciones que
se ejecutarán en el conjunto de datos).
Los parámetros que se utilizan durante la carga de datos son:
- load: Indica el tipo de workload se va a ejecutar (carga de datos)

- db: Indica el gestor de base de datos que se va a usar.
- P: Indica que se van a utilizar archivos para cargar parámetros. Para la fase de
carga se utiliza el archivo ‘settings_load” que contendrá los parámetros a usar
en la carga de datos.
5) Ejecutar el workload:
Para la ejecución de datos se deben configurar los siguientes parámetros:
- t: Indica la fase del workload se va a ejecutar (transacción)
- db: Indica el gestor de base de datos que se va a usar, en este caso será
Cassandra
- P: Indica que se van a utilizar archivos para cargar parámetros. Para la fase de
ejecución se utiliza el archivo ‘settings” que contendrá los parámetros a usar en
la ejecución de datos.
LOS WORKLOADS
Los workloads son las cargas de trabajo predifinidias para YCSB, están hechos para
bases de datos pequeñas, por ejemplo 6000 registros. Para una base de datos en
funcionamiento hay que utilizar parámetros más grandes, por ejemplo 100 millones de
registros. Para ello se necesita cambiar el valor del parámetro ‘recordcount’.
Cuando la carga se completa el cliente crea un informe estadístico sobre el

rendimiento del workload. Estas estadísticas son idénticas en la fase de ejecución.
YCSB incluye un conjunto de ‘workloads’, cargas de trabajo, que definen un

benchmark básico para sistemas cloud. Estos ‘workloads’ son muy útiles en la obtención
de parámetros de referencia que nos permitan comprender el rendimiento de diferentes
sistemas.
54
CAPÍTULO 4
Cada ‘workload’ representa una mezcla determinada de operaciones de lectura y

escritura, tamaño de los datos, distribuciones de solicitud y puede ser utilizado para evaluar
aspectos determinados del rendimiento de los sistemas.
En principio, dividimos los ‘workloads’ en dos grupos: los que contienen

operaciones de rendimiento y los que contienen operaciones de lectura/escritura.
Cada operación que se realiza en la base de datos es elegida aleatoriamente,

pudiendo ser:
- Insert: Insertar un nuevo registro.

- Update: Escribir en un registro reemplazando el valor anterior.
- Read: Leer un registro, ya sea un campo elegido al azar o todos los campos.
- Scan: Explorar registros en orden, empezando por un aleatoriamente. El número
de registros explorados también es aleatorio.
El benchmark debe tomar muchas decisiones al azar al generar la carga: operación/es

a realizar, qué registros leer o escribir, cuántos registros explorar,… Estas decisiones se
rigen por distribuciones aleatorias. YCSB tiene varios modelos de distribución:
- Uniform: Elige un elemento aleatorio uniformemente. Por ejemplo, cuando se elige

un registro, todos los registros de la base de datos tienen la misma probabilidad de
ser elegidos.
- Zipfian: Elige un elemento de acuerdo con la distribución Zipfian. Por ejemplo,

cuando se elige un registro, algunos registros serán extremadamente populares (la
cabeza de la distribución) mientras que otros muchos no serán populares (la cola).
- Latest: Parecida a la distribución Zipfian, excepto en que los registros más

populares están situados al comienzo de la distribución.
- Multinomial: Las probabilidades de cada elemento pueden ser especificadas. Por

ejemplo, es posible asignar una probabilidad de 0.95 a la operación ‘read’, un 0.05
a la ‘update’ y un 0 a ‘scan’ e ‘insert’. El resultado será un ‘workload’ de lectura
(pesado).
55
CAPÍTULO 4
Ilustración 17 - Distribuciones de carga usadas en los workloads. Fuente: YCSB GitHub
Workload Operaciones Selección de registro

A –Update (pesado) Read 50% Zipfian
Update 50%
B – Read (mayoría) Read 95% Zipfian
Update 5%
C – Read (sólo) Read 100% Zipfian
D – Read (reciente) Read 95% Latest
Insert 5%
E–Rangos pequeños Scan 95% Zipfian / Uniform
Insert 5%
F – Read-modify- Read 90% Multinomial
write Update 5%
Insert 5%
Tabla 4 - Características de las cargas de trabajo
En la Tabla 4 se muestra la configuracion de cada tipo de carga, que se comentan a

continuación:
56
CAPÍTULO 4
Workload A: Update (pesado). Este ‘workload’ tiene un 50% de escritura y un 50%

de lectura. Una aplicación de ejemplo sería un registro de eventos.
Workload B: Read (mayoría). Este ‘workload’ es una mezcla de 95% operaciones de

lectura y tan sólo un 5% de operaciones de escritura. Una aplicación de ejemplo sería una
aplicación que etiquete fotos, añadir una etiqueta sería una operación de escritura pero la
mayoría se centraría en operaciones de lectura.
Workload C: Read (sólo). Este ‘workload’ contiene un 100% de operaciones de

lectura. Una aplicación de ejemplo sería una caché de perfil de usuario, donde los perfiles
se construirían en cualquier lugar.
Workload D: Read (reciente). En este ‘workload’ nuevos registros son insertados,

donde los más recientes son los más populares. Una aplicación de ejemplo sería una
actualización del estado del usuario, la gente quiere leer el último registro.
Workload E: Rangos cortos. En este ‘workload’, pequeños rangos de registros se

consultan, en vez de mediante registros individuales. Una aplicación de ejemplo serían los
hilos de conversaciones, donde cada escaneo es para los mensajes de un hilo determinado.
Workload F: Read-modify-write. En este ‘workload’, el cliente leerá un registro, lo

modificará y escribirá los nuevos cambios. Una aplicación de ejemplo sería, una base de
datos de usuario, donde cada registro del usuario es leído y modificado por el usuario o
registra actividad del usuario.
Los seis ‘workloads’ son similares. Los ‘workloads’ D y E insertan registros durante
el testeo. Por ello para mantener un tamaño consistente en la base de datos, se sigue esta
secuencia.
1. Cargamos la base de datos usando el ‘workload’ A y el parámetro –load.

2. Ejecutamos el ‘workload’ A con el parámetro –t.
3. Ejecutamos el ‘workload’ B con el parámetro –t.
4. Ejecutamos el ‘workload’ C con el parámetro –t.
5. Ejecutamos el ‘workload’ D con el parámetro –t.
6. Ejecutamos el ‘workload’ E con el parámetro –t.
7. Borramos los datos de la base de datos.
8. Recargamos la base de datos, usando el ‘workload’ E y el parámetro –load.
9. Y por último, ejecutamos el ‘workload’ E con el parámetro –t. Este
‘workload’ inserta nuevos registros e incrementa el tamaño de la base de
datos.
57
CAPÍTULO 4
Aunque las clases ‘workload’ y sus parámetros asociados están definidos en cada
‘workload’, hay parámetros adicionales que pueden ser modificados. Estas opciones son:
- Hosts: Direcciones IP de los nodos servidores en los que se van a ejecutar las
pruebas.
- Threadcount: Número de hilos que se van a ejecutar en paralelo en una prueba. Por
defecto, YCSB usa un único hilo, pero es posible añadir más hilos. Esto es habitual
- Recordcount: Número de registros usados por la base de datos.
- Operationcount: Parámetro exclusivo de la fase de ejecución, sirve para determinar

el número de operaciones totales que ejecutará el benchmark.
- Target: Este parámetro representa la tasa de servicio del sistema, esto equivale al
número de operaciones realizadas por segundo, que determinarán la productividad
del sistema. Por defecto, YCSB intentará completar tantas operaciones como
pueda. Por ejemplo, si cada operación tarda 100 milisegundos de media, el cliente
realizará alrededor de 10 operaciones por segundo por hilo. Para generar una
latencia en el rendimiento, es posible utilizar distintos ‘targets’ y medir la latencia
de cada uno.
Los ‘workloads’ tienen dos fases: carga (en la cual definimos los datos a insertar) y
ejecución (en la cual definimos las operaciones que utilizarán los datos anteriormente
definidos).
4.3 MÉTRICAS DE RENDIMIENTO
Las métricas han de ser lo más representativas posibles del rendimiento del sistema y
permitan obtener resultados cuantitativos, de las cuales se puedan obtener conclusiones.
Estas métricas se obtienen al ejecutar la fase de carga y ejecución en cada una las
máquinas virtuales del clúster.
En estas pruebas se utilizarán tres métricas básicas:
- Productividad: Representa el número de operaciones por segundo (tasa de servicio)

que realiza el sistema. Es el valor más representativo para saber cuál es el
rendimiento del sistema.
58
CAPÍTULO 4
- Tiempo (Runtime): Representa el tiempo total que tarda en completarse una fase
(carga o ejecución). Es inversamente proporcional a la productividad.
- Latencia: Es la suma de los retrasos que se producen por la demora en la
propagación y transmisión de paquetes durante la ejecución de las operaciones de
las cargas de trabajo. Cuanto más costosa es la operación a realizar mayor es la
latencia producida.
4.4 PRUEBAS REALIZADAS
Principalmente se realizan dos tipos de pruebas, las pruebas en máquinas básicas y

las pruebas en máquinas avanzadas.
Para la realización de este trabajo se han utilizado cuatro máquinas virtuales creadas
mediante XenServer. Estas máquinas se ubican en el clúster donde se ha realizado el
despliegue de XenServer anteriormente comentado.
En la Ilustración 18 se muestra la localización de las máquinas virtuales en el

sistema, y la interacción que tienen entre ellas a través del software instalado en el
despliegue.
Ilustración 18 - Diagrama de bloques de las pruebas de evaluación
59
CAPÍTULO 4
Para las pruebas realizadas entre máquinas virtuales básicas, se han usado dos
máquinas con una configuración idéntica, que consiste en una unidad de procesamiento de
2 vCPU, 2 GB de memoria RAM y 50 GB de almacenamiento en disco.
Una máquina virtual básica actuará como cliente, su labor principal será administrar
la base de datos Cassandra y el encargado de lanzar los parámetros de las pruebas. La otra
máquina virtual básica es donde se efectuarán las pruebas de carga, almacenando los datos
en la base de datos gestionada por Cassandra.
Y para las pruebas realizadas entre dos máquinas virtuales avanzadas, se han usado
dos máquinas con una configuración idéntica, que consiste en una unidad de
procesamiento de 4 vCPU, 4 GB de memoria RAM y 100 GB de almacenamiento en disco.
La funcionalidad de ambas máquinas es igual que en el caso de las máquinas básicas.
Cada tipo de pruebas se dividen a su vez en dos fases, carga y ejecución (de datos);
estas pruebas pueden realizarse variando la tasa de servicio (número de operaciones por
segundo) o cambiando el número de hilos que se ejecutan en paralelo en la máquina.
Con la realización de las pruebas se obtendrán tres métricas de rendimiento,

mediante las cuales se establecerá cual es la máquina virtual más apropiada dependiendo
de la necesidad del usuario.
Además, y antes de pasar a mostrar los resultados debemos aclarar que se han
desplegado dos escenarios distintos. Uno en el que el cliente no está ubidado en la
infraestructura cloud con lo que presentará una latencia de acceso al servicio variable, este
caso lo denominaremos Escenario 1. En un segundo caso de estudio, denominado
Escenario 2, todos los componentes se encuentran desplegados en la infraestructura cloud
gestionada por XenServer.
4.4.1 ESCENARIO 1: CLIENTE EXTERIOR
Estas pruebas se realizan desde una máquina exterior para analizar el rendimiento del
sistema desde un nodo situado fuera del clúster.
Para todas estas pruebas se utilizará únicamente la carga de trabajo A y se modificará

el parámetro 'target' o el parámetro 'threadcount' según se busque analizar la productividad
por la tasa de servicio (número de operaciones por segundo) o por el número de hilos en
ejecución.
60
CAPÍTULO 4
A continuación se realizan una serie de pruebas para evaluar el rendimiento del

sistema durante el proceso de carga de datos a la base de datos.
Primero se analiza el rendimiento del sistema variando el número de operaciones por

segundo (tasa de servicio), parámetro 'target', que se ejecutarán en la máquina virtual. Para
cada una de las máquinas se fija un determinado número de hilos ('threadcount'), en este
caso será de un hilo para todas.
Después de realizar las pruebas de carga variando la tasa de servicio, se obtienen las
gráficas que se muestran en las Ilustraciones 19, 20 y 21; que representan una comparativa
entre el rendimiento ofrecido por una máquina virtual básica y una avanzada en los
aspectos de productividad, tiempo total y latencia.
20 1400000
operaciones/segundo
1200000
milisegundos
Básica
15 1000000
800000
10 Básica Avanzada
600000
5 400000
Avanzada 200000
0 0
5 10 15 20 25 30 35 40 5 10 15 20 25 30 35 40
Tasa de servicios Tasa de servicios
Ilustración 19 – Escenario1: Ilustración 20 – Escenario1: Tiempo

Productividad (F. carga) (F.carga)
58000
57000
56000
microsegundos
55000
54000
Básica
53000
Avanzada
52000
5 10 15 20 25 30 35 40
Tasa de servicios
Ilustración 21 – Escenario1: Latencia

(F. carga)
Se observa como la productividad en la máquina básica crece hasta llegar al pico de

unas 17 operaciones por segundo aproximadamente. Una vez la productividad alcanza las
61
CAPÍTULO 4
17 operaciones por segundo se mantiene constante. Al igual que en la máquina básica, la

máquina avanzada llega al tope de productividad con muy pocas operaciones, aunque se
puede apreciar un ligero aumento de productividad con respecto a la máquina básica. En
este caso la máquina avanzada permite un par de operaciones más, llegando a alcanzar las
19 operaciones por segundo.
El tiempo de carga está íntimamente relacionado con la productividad. Cuantas más

operaciones por segundo consigue realizar la máquina, menor es el tiempo de ejecución del
proceso de carga de datos. En la Ilustración 20 se observa como disminuye el tiempo de
ejecución mientras aumenta la productividad, una vez se estanca la productividad el tiempo
de ejecución se estabiliza. Lógicamente la máquina virtual avanzada consigue un ligero
descenso del tiempo comparado con la máquina básica, esto se debe a que su productividad
es mayor.
La latencia es bastante alta en todas las iteraciones de la prueba, esto se debe a que
las pruebas se realizan desde fuera del clúster y al estar en otra red distinta la latencia
aumenta considerablemente. Se puede observar que, la máquina avanzada disminuye su
latencia con respecto a la máquina básica gracias a su mayor productividad.
La siguiente tanda de pruebas analiza el rendimiento del sistema variando el número

de hilos que se ejecutan de manera simultánea en la máquina virtual durante la fase de
carga de datos, para ello se modifica el parámetro 'threadcount'.
Para cada una de las máquinas se fija el valor de la tasa de servicio ('target') en un
número asequible para cada tipo de máquina, para la máquina virtual básica serán 18
operaciones por segundo y para la máquina avanzada 20 operaciones por segundo.
Después de las pruebas de carga variando el número de hilos se obtienen las gráficas
que se muestran en las Ilustraciones 22, 23 y 24, que representan una comparativa entre el
rendimiento ofrecido entre la máquina virtual básica y la avanzada en los aspectos de
productividad, tiempo total y latencia.
62
CAPÍTULO 4
20 2500000
18 Básica
Operaciones/segundo
Milisegundos
16 2000000
14 Avanzada
12 1500000
10
8 1000000
6 Básica
4 500000
2 Avanzada
0 0
1 2 4 8 16 32 48 56 64 1 2 4 8 16 32 48 56 64
Número de hilos Número de hilos

Productividad (F. carga) (F. carga)
8000000
microsegundos
7000000 Básica
6000000
5000000 Avanzada
4000000
3000000
2000000
1000000
0
1 2 4 8 16 32 48 56 64
Número de hilos

(F. carga)
Se puede observar que para la máquina virtual básica la productividad se mantiene en

18 operaciones por segundo aproximadamente al aumentar el número de hilos; cuando el
sistema no soporta el aumento del número de hilos, en este caso son 64, la productividad
desciende bruscamente. En la máquina virtual avanzada se observa el mismo fenómeno
que durante la fase de carga de la máquina básica, al llegar a 64 threads el sistema sufre
una importante pérdida de rendimiento, solo que en la máquina avanzada la productividad
mínima sigue siendo mayor que en la básica llegando a las 20 operaciones por segundo.
El tiempo de ejecución es inverso a la productividad, con un número de hilos

asequible se mantiene constante pero al llegar a un determinado número hilos el tiempo de
ejecución se incrementa debido al descenso de la productividad. La única diferencia
observable en la gráfica es que el tiempo de la máquina virtual básica aumenta en mayor
grado que el de la avanzada, consiguiendo la máquina avanzada permanecer en un tiempo
estable hasta los 48 threads, mientras que la básica a los 32 threads comienza a aumentar
sus tiempos.
63
CAPÍTULO 4
La latencia es similar en todas las pruebas mientras el sistema responda

correctamente a las peticiones de carga de datos, al llegar a 64 hilos el sistema no lo
soporta correctamente, provocando un retraso en la respuesta del sistema que se ve
reflejado en un gran aumento de la latencia.
Ahora se realizan una serie de pruebas para evaluar el rendimiento del sistema
durante el proceso de ejecución de datos en la base de datos.

Después de realizar las pruebas de ejecución, variando la tasa de servicio, se obtienen

las gráficas que se muestran en las Ilustraciones 25, 26 y 27, que representan una
comparativa entre el rendimiento ofrecido entre la máquina virtual básica y la avanzada en
los aspectos de productividad, tiempo total y latencia.
50 1400000
milisegundos
1200000
operaciones/segundo
40 Básica
1000000
30 800000
20 600000 Avanzada
400000
10 200000
Básica Avanzada
0 0
5 10 15 20 25 30 35 40 45 50 5 10 15 20 25 30 35 40 45 50 55
Tasa de servicio Tasa de servicio

Productividad (F. ejecución) (F. ejecución)
28000
microsegundos
27500
27000
26500
26000
25500
Básica Avanzada
25000
5 10 15 20 25 30 35 40 45 50 55
Tasa de servicio

(F. ejecución)
64
CAPÍTULO 4
Se puede observar como la máquina virtual básica es incapaz de ejecutar más de 36

operaciones por segundo, siendo ese su máximo de productividad. En cambio la máquina
virtual avanzada permite una productividad de hasta 40 operaciones por segundo.
El tiempo, al estar relacionado con la productividad, disminuye conforme aumentan

las operaciones por segundo, alcanzando el mínimo tiempo en el momento en el que se
obtiene la máxima productividad. Cómo es lógico al tener mayor productividad, la
máquina virtual avanzada consigue un menor tiempo de ejecución.
Conforme aumentan las operaciones por segundo durante la ejecución disminuye

ligeramente la latencia en ambos tipos de máquinas. Aunque se consigue una menor
latencia en la máquina avanzada debido sin duda a una mayor productividad.

ejecución de datos, para ello se modifica el parámetro 'threadcount'.
número asequible, para la máquina virtual básica serán 35 operaciones por segundo y para
la máquina avanzada 40 operaciones por segundo.
que se muestran en las Ilustraciones 28, 29 y 30; que representan una comparativa entre el
45 1600000
40 1400000
operaciones/segundo
Básica
milisegundos
35 1200000
30 1000000
25 Avanzada
Básica 800000
20
15 600000
10 400000
5 Avanzada 200000
0 0
1 2 4 8 16 32 48 56 64 1 2 4 8 16 32 48 56 64

65
CAPÍTULO 4
1400000
microsegundos
1200000
1000000 Básica
800000
600000 Avanzada
400000
200000
0
1 2 4 8 16 32 48 56 64
Número de hilos

(F. ejecución)
Observamos que al igual que en la fase de carga de datos, durante la fase de

ejecución, en la máquina virtual básica, se mantiene una productividad asequible hasta
utilizar 48 threads durante la ejecución, lo que provoca una reducción drástica de las
operaciones por segundo ejecutadas. En cambio la máquina virtual avanzada consigue una
productividad decente hasta los 56 threads. Ambas máquinas colapsan con 64 threads.
Con el tiempo de ejecución pasa algo similar a la productividad. La máquina virtual

básica responde de manera correcta con tiempos bajos hasta utilizar 48 threads durante la
ejecución, lo que provoca un enorme aumento en el tiempo de ejecución. Por otro lado la
máquina virtual avanzada todavía consigue buenos tiempos para 56 threads.
Por último, respecto a la latencia, al igual que el tiempo, la máquina virtual básica
sufre un gran aumento cuando se utilizan 48 threads. La máquina avanzada soporta una
latencia asequible hasta los 56 threads.
CONCLUSIONES DE LAS PRUEBAS EXTERNAS

Como se puede observar la máquina virtual avanzada ofrece una mejor respuesta a
las peticiones realizadas desde el exterior del clúster. Aunque debido a las interferencias de
la red y el aumento de la latencia que se producen al realizar las pruebas desde el exterior
del clúster y que desvirtúan los datos reales del rendimiento de las máquinas virtuales, se
ha decidido hacer un análisis más detallado del rendimiento del sistema mediante pruebas
realizadas en el interior del clúster, con el fin de obtener unos datos lo más precisos
posible.
4.4.2 ESCENARIO 2: CLIENTE INTERIOR
En este escenario las pruebas se realizan desde dos máquinas internas para analizar el
rendimiento del sistema mediante dos máquinas pertenecientes al clúster.
66
CAPÍTULO 4
A continuación se realizan una serie de pruebas para evaluar el rendimiento del

sistema durante el proceso de carga de datos en la base de datos.
Para las pruebas de carga se utilizará únicamente la carga de trabajo A y se

modificará el parámetro 'target' o el parámetro 'threadcount' según se busque analizar la
productividad (número de operaciones por segundo) o por el número de hilos en ejecución.

Después de realizar las pruebas de carga variando la tasa de servicio se obtienen las
entre el rendimiento ofrecido entre la máquina virtual básica y la avanzada en los aspectos
de productividad, tiempo total y latencia.
700 140000
0peraciones/segundo
milisegundos
600 120000
Básica
500 100000
400 80000
Avanzada
300 60000
Básica
200 40000
100 20000
Avanzada
0 0
50
100
150
300
500
800
1000
1500
2000
50
300
500
100
150
800
1000
1500
2000

3500
3000
microsegundos
2500
2000
1500
1000
500 Básica Avanzada
0
50 100 150 300 500 800 1000 1500 2000
Tasa de servicio
Ilustración 33 – Escenario2: Latencia (F. carga)

67
CAPÍTULO 4
Como se puede observar en la Ilustración 31 se prueban distintos valores de

productividad. Finalmente se aprecia que no se consiguen más de 500 operaciones por
segundo en la máquina virtual básica. En cambio la máquina virtual avanzada permite
realizar hasta 600 operaciones por segundo, llegado a ese punto el sistema es incapaz de
aumentar su productividad.
Para el tiempo de carga de la máquina virtual básica se ve claramente como

disminuye hasta llegar a las 500 operaciones por segundo, una vez conseguida esa
productividad se estanca en tiempos muy parecidos. Para la máquina virtual avanzada el
tiempo tiene un comportamiento similar sólo que al conseguir más productividad se
obtiene a un tiempo mínimo menor.
Podemos observar como la latencia decrece ligeramente con el aumento de la

productividad; aunque es cuasi despreciable, esto se debe a que al aumentar el número de
operaciones conseguimos que la máquina pueda obtener de una manera más rápida las
peticiones a atender. Aunque lo que sí se observa claramente es la menor latencia obtenida
por la máquina avanzada respecto a la máquina básica.

carga de datos, para ello se modifica el parámetro 'threadcount'.
número asequible para cada tipo de máquina. Para la máquina virtual básica serán 500
Después de realizar las pruebas de carga variando el número de hilos se obtienen las
68
CAPÍTULO 4
700 35000
operaciones/segundo
milisegundos
600 30000
Básica Avanzada
500 25000
20000
400
15000
300
Básica Avanzada 10000
200 5000
100 0
0
1 4 16 64 196 384 768

2000000
microsegundos
1500000 Básica
1000000
Avanzada
500000
0
1
2
4
8
16
32
64
128
384
196
256
512
768
1024
Número de hilos

(F. carga)
A diferencia de las pruebas desde el exterior del clúster, realizar las pruebas en el
interior del clúster permite elevar el número de hilos a un número bastante alto. La
máquina virtual básica permite mantener una productividad máxima hasta los 64 hilos, a
partir de esa cifra el rendimiento comienza a disminuir de manera bastante notoria. Por otra
parte la máquina virtual avanzada consigue mantener una productividad de casi 600
operaciones por segundo hasta los 64 threads. Después al ir aumentando el número de hilos
desciende la productividad. De todas maneras observamos como con el mismo número de
hilos conseguimos más productividad con la máquina avanzada que con la máquina básica.
Al igual que en la productividad, con 64 threads obtenemos un tiempo de carga

bastante bajo pero a partir de ahí comienza a aumentar. Aun así la máquina virtual
avanzada consigue unos tiempos más bajos que la básica debido a su mayor productividad
con el mismo número de hilos.
A partir de 64 threads la máquina virtual básica empieza a tener problemas en

responder a las peticiones y la latencia se dispara. En cambio la máquina avanzada
69
CAPÍTULO 4
consigue moderar el aumento de la latencia a mayor número de hilos, consiguiendo una

latencia máxima bastante baja con respecto a la máquina virtual básica.
Ahora se realizan una serie de pruebas para evaluar el rendimiento del sistema
durante el proceso de ejecución de datos en la base de datos.
Para todas estas pruebas se utilizarán las distintas cargas de trabajo que tenemos a
nuestra disposición (A/B/C/E/F/G) y se modificará el parámetro 'target' (número de
operaciones por segundo). Excepto en las pruebas con hilos, debido a que en estas pruebas
no afecta el tipo de operaciones sino el número de hilos que se ejecuten simultáneamente y
por lo tanto únicamente se usará la carga de trabajo A.
Como cada workload trabaja un aspecto determinado del sistema durante su

ejecución, se utilizan todas las cargas de trabajo que tenemos disponibles para evaluar el
rendimiento del sistema.
Primero se analiza el rendimiento de la máquina virtual básica variando el número

de operaciones por segundo (tasa de servicio), parámetro 'target', que se ejecutarán en la
máquina virtual. Para cada una de las máquinas se fija un determinado número de hilos
('threadcount'), en este caso será de un hilo para todas.
Después de las pruebas de ejecución variando la tasa de servicio se obtienen las

600 140000
operaciones/segundo
milisegundos
500 120000
100000
400
80000
300 60000
200 40000
100 20000
0 0
A B C D E F A B C D E F

70
CAPÍTULO 4
25000
microsegundos
20000
15000
10000
5000
0
50 100 150 300 500 800 1000 1500
Tasa de servicio
A B C D E F

(F. ejecución)
Una vez obtenidas las gráficas de rendimiento de las distintas cargas de trabajo se
analizan el comportamiento de cada una de ellas por separado.
Carga de trabajo A
El workload A es una mezcla al 50% de operaciones de lectura y escritura.
Se puede observar como la productividad aumenta hasta las 450 operaciones por
segundo aproximadamente. A partir de esta cifra se estanca, llegando a su máximo de 460
operaciones por segundo.
El tiempo desciende hasta que la productividad se estabiliza y se mantiene en un

tiempo bajo gracias a la alta productividad.
La latencia desciende a medida que aumenta la productividad debido a que el sistema

recibe más peticiones y no tiene que esperar entre unas y otras.
Además, se demuestra que independientemente de la productividad y el tiempo de

ejecución, la latencia de escritura es mayor que la de lectura, aun utilizando la misma
proporción de operaciones.
Carga de trabajo B
Este workload tiene un 95% de operaciones de lectura y un 5% de operaciones de

escritura.
La productividad se estabiliza alrededor de las 480 operaciones por segundo al igual

que en el workload A, solo que el máximo del workload B es de 485 operaciones por
segundo, ligeramente superior al workload A.
71
CAPÍTULO 4
El tiempo, inversamente proporcional a la productividad, obtiene sus valores más

bajos cuando la productividad es mayor.
Al contrario que en el workload A, la latencia total sumada por las operaciones de

lectura es mayor que la de escritura. Esto se debe a que el número de operaciones de
lectura es mucho mayor que el de escritura lo que le permite bajar su latencia.
Carga de trabajo C
Este workload contiene un 100% de operaciones de lectura.
La productividad al igual que en los otros workloads sufre un gran crecimiento hasta
estabilizarse en las 500 operaciones por segundo, siendo su máximo de productividad 538
Como en los otros workloads al aumentar la productividad se reduce el tiempo de

ejecución hasta llegar a un máximo de productividad que provoca un tiempo mínimo de
ejecución.
Únicamente tenemos una latencia, en este caso de lectura, debido a que este
workload únicamente realiza operaciones de lectura. Al igual que con los otros workloads
al aumentar la productividad se consigue una pequeña reducción en la latencia de las
operaciones.
Carga de trabajo D
Este workload se encarga de insertar nuevos registros.
La productividad sigue la misma tendencia que en workloads anteriores, va

aumentando hasta estabilizarse en algo menos de 500 operaciones por segundo. Siendo el
máximo de productividad de 495 operaciones por segundo.
El tiempo sigue una tendencia inversa a la productividad, se observa como desciende

el tiempo de ejecución conforme aumenta el número de operaciones por segundo.
Este workload sufre dos latencias, la latencia que produce la operación insertar los
datos es mayor que la de lectura de datos.
Carga de trabajo E
En este workload se trabaja la consulta de registros.
72
CAPÍTULO 4
A diferencia del resto de workloads el aumento de productividad de este workload es

bastante reducido, consigue llegar como máximo a las 60 operaciones por segundo, una
productividad bastante reducida con respecto al resto de workloads. Esto se debe
principalmente a las operaciones de escaneo de registros que requieren un gran esfuerzo de
computación por parte del sistema.
Debido al escaso incremento de la productividad el tiempo de ejecución se mantiene

bastante alto.
El workload tiene dos latencias, una latencia al insertar datos y otra latencia al
escanear registros. La latencia que provoca escanear registros es muy elevada.
Carga de trabajo F
El workload F lee los registros, los modifica y finalmente escribe los cambios.
En este workload la productividad responde bien hasta las 300 operaciones por
segundo aproximadamente, una vez se superan las 300 operaciones el sistema se estanca en
unas 320 operaciones por segundo siendo incapaz de conseguir más productividad. Al ser
un workload con tanta carga y variedad de operaciones, es normal que sea uno de los
workload que menos productividad obtiene.
Al no rendir a un nivel alto de productividad el tiempo de ejecución no es todo lo

bajo que se espera comparado con el resto de workloads.
El workload F tiene tres tipos de operaciones, la modificación del registro provoca

una latencia insignificante con respecto a las operaciones de lectura y escritura de datos,
siendo las operaciones de escritura las que más latencia provocan.
Ahora se analiza el rendimiento de la máquina virtual avanzada variando el número

de operaciones por segundo (tasa de servicio), parámetro 'target', que ejecutarán la
máquina virtual. Para cada una de las máquinas se fija un determinado número de hilos
('threadcount'), en este caso será de un hilo para todas.
Después de las pruebas de ejecución variando la tasa de servicio se obtienen las

73
CAPÍTULO 4
700 140000
operaciones/segundo
milisegundos
600 120000
500 100000
400 80000
300 60000
200 40000
100
20000
0
0
Tasa de servicio
Tasa de servicio
A B C D E F A B C D E F

16000
microsegundos
14000
12000
10000
8000
6000
4000
2000
0
50 100 150 300 500 800 1000 1500
Tasa de servicio
A B C D E F

(F. ejecución)
Una vez obtenidas las gráficas de rendimiento de las distintas cargas de trabajo se
analizan por separado.
Carga de trabajo A
El workload A es una mezcla al 50% de operaciones de lectura y escritura.
El sistema responde correctamente al incremento de productividad hasta estancarse

en unas 600 operaciones por segundo, consiguiendo una productividad máxima de 599
El tiempo de ejecución desciende conforme aumenta la productividad, cuando se

estabiliza la productividad se consigue un tiempo mínimo de unos 10000 milisegundos.
74
CAPÍTULO 4
El workload tiene dos latencias, la latencia de escritura es menor que la de lectura.

Ambas latencias descienden conforme aumenta la productividad.
Carga de trabajo B
Este workload tiene un 95% de operaciones de lectura y un 5% de operaciones de

escritura.
Conseguimos un gran aumento de productividad hasta algo más de 500 operaciones

por segundo, a partir de ahí se estabiliza.
El tiempo de ejecución baja conforme aumenta la productividad.
La latencia de escritura es menor que la latencia producida por las operaciones de

lectura. Ambas latencias sufren una pequeña disminución al aumentar la productividad.
Carga de trabajo C
Este workload contiene un 100% de operaciones de lectura.
El sistema aumenta la productividad hasta casi 600 operaciones por segundo, una vez
llegado a ese punto se estabiliza.
El tiempo de ejecución desciende al aumentar la productividad como en los

anteriores workloads.
La latencia sufre una pequeña reducción al aumentar la productividad, aunque es una

reducción despreciable.
Carga de trabajo D
En este workload se encarga de insertar nuevos registros.
En este workload conseguimos un aumento de productividad hasta alcanzar unas 425

operaciones por segundo, una vez llegado a ese punto la productividad se estabiliza.
Conseguimos una importante reducción del tiempo de ejecución con el aumento de la

productividad, estancándose cuando la productividad no puede aumentar más.
La latencia producida por las operaciones de lectura es bastante más baja que la
producida por operaciones de inserción de datos.
75
CAPÍTULO 4
Carga de trabajo E
En este workload se trabaja la consulta de registros.
Con la ejecución de este workload tan sólo conseguimos una productividad de 100
operaciones por segundo, esto sin duda es debido a la alta carga de trabajo que provocan
las operaciones de escaneo.
La baja productividad tiene efecto inmediato en el tiempo de ejecución, provocando

que sea bastante alto en comparación con los otros workloads en su momento de
productividad máxima.
Podemos observar como son las operaciones escaneo las que provocan una mayor
latencia.
Carga de trabajo F
El workload F lee los registros, los modifica y finalmente escribe los cambios.
En este workload conseguimos ampliar la productividad hasta unas 425 operaciones

por segundos, después se estabiliza
El tiempo de ejecución es inversamente proporcional a la productividad por lo que va

descendiendo hasta que la productividad se estanca, entonces el tiempo se estabiliza.
El workload produce tres latencias; la productividad de la modificación de datos es

despreciable, las operaciones de lectura y escritura si producen una latencia medible siendo
mayor la latencia por lectura que por escritura.

ejecución de datos, para ello se modifica el parámetro 'threadcount'.
número asequible para cada tipo de máquina. Para la máquina virtual básica serán 500
que se muestran en las Ilustraciones 43, 44 y 45; que representan una comparativa entre el
76
CAPÍTULO 4
700 20000
milisegundos
operaciones/segundo
600
500 15000
400
10000
300
200 Básica
5000
Básica Avanzada
100 Avanzada
0 0
2
1
4
8
16
32
64
128
256
512
768
1024
1
2
4
8
16
32
64
768
128
256
512
1024

3000000
microsegundos
2500000
Básica
2000000
1500000 Avanzada
1000000
500000
0
4
1
2
8
16
32
64
256
128
512
768
1024
Número de hilos

(F. ejecución)
En la ejecución podemos observar un comportamiento similar a la carga. Se

mantiene en 500 operaciones por segundo hasta pasar de los 64 hilos, lo que provoca un
importante descenso de la productividad. En el caso de la máquina virtual avanzada la
productividad de ejecución se mantiene hasta casi 128 hilos, a partir de ahí comienza a
decrecer. Como es lógico la avanzada consigue mayor productividad que la básica hasta el
punto en el que ambas colapsan con 1024 threads.
Como durante las pruebas de carga, en la máquina virtual básica al disminuir la

productividad aumenta el tiempo de ejecución, y el sistema empieza a tener dificultades
para atender las peticiones a partir del uso de 64 hilos. En la máquina virtual avanzada se
observa que a partir de 128 hilos en ejecución hay un aumento en el tiempo de ejecución,
esto se debe al descenso de productividad en ese punto. Al igual que en productividad, la
máquina avanzada consigue resultados que la básica hasta el momento en que ambas
colapsan con 1024 threads.
77
CAPÍTULO 4
En la máquina básica al incrementar el número hilos aumenta la latencia, a partir de

512 hilos la latencia se dispara haciendo impracticable la prueba. En cambio al igual que
en la fase de carga, la máquina virtual avanzada consigue una latencia bastante aceptable
para todas las pruebas, siendo mínima hasta los 512 threads.
CONCLUSIONES DE LAS PRUEBAS INTERNAS

Como se puede observar estas pruebas nos han ofrecido unos datos más exactos,
eliminando las perturbaciones que puede provocar el paso de estos por redes externas.
Respecto al rendimiento de la máquina se observan unos resultados más positivos lo

que hacen intuir un mayor rendimiento desde estas máquinas si se trabaja desde el interior
del clúster. Además, el parámetro de la latencia se consigue reducir hasta en un 90%.
4.4.3 CONCLUSIONES SOBRE LA ESCALABILIDAD VERTICAL
Tanto en las pruebas exteriores como interiores de clúster queda claro que la
máquina virtual avanzada con una configuración más completa, ofrece mejor rendimiento
tanto en productividad como en tiempo de ejecución y latencia de las operaciones.
Se comparan los distintos resultados obtenidos durante las pruebas, seleccionando

únicamente los resultados de la productividad máxima de cada ‘workload’.
En las gráficas, el eje X representa las distintas cargas de trabajo usadas a lo largo de
las pruebas y el eje Y marca los resultados obtenidos por cada carga de trabajo.
MÁQUINA VIRTUAL BÁSICA
Productividad
En esta grafica representamos la máxima productividad (más operaciones por
segundo) obtenidas al ejecutar cada workload.
78
CAPÍTULO 4
600
operaciones/segundo
500 Tasa de
servicio
400
300
200
100
0
A B C D E F
Cargas de trabajo
Ilustración 46 - Comparativa de productividad entre los workloads
Conseguimos la máxima productividad en el workload C ya que se le limita a

operaciones de lectura. En cambio el workload E al escanear registros tiene una
productividad muy baja.
Tiempo de ejecución
En la gráfica podemos observar el tiempo mínimo de ejecución de cada carga de
trabajo, siendo el valor de la productividad el máximo obtenido durante las pruebas.
120000
100000 Runtime
milisegundos
80000
60000
40000
20000
0
A B C D E F
Cargas de trabajo
Ilustración 47 - Comparativa de tiempo entre los workloads
Podemos observar que el ‘workload’ E es el que más tiempo tarda en ejecutarse

debido a su baja productividad. El resto de ‘workloads’ mantienen un tiempo de ejecución
mínimo alrededor de unos 10000 milisegundos.
Latencia
En esta gráfica comparamos la latencia obtenida por las operaciones en el momento
de máxima productividad del workload.
79
CAPÍTULO 4
25000
Latencia
20000
microsegundos
15000
10000
5000
0
A B C D E F
Cargas de trabajo
Ilustración 48 - Comparativa de latencia entre los workloads
Observamos que la mayor latencia se encuentra en el workload E debido a que las

operaciones de escaneo de registro provocan gran latencia, en cambio el workload C tiene
la menor latencia ya que únicamente utiliza operaciones de lectura.
MÁQUINA VIRTUAL AVANZADA
Productividad
En este grafica representamos la máxima productividad (más operaciones por
segundo) de cada workload.
700
600
operaciones/segundo
Productividad
500
400
300
200
100
0
A B C D E F
Cargas de trabajo
Ilustración 49 - Comparativa de productividad entre los workloads
Conseguimos la máxima productividad en el workload C ya que se le limita a

operaciones de lectura, en cambio el workload E al escanear registros tiene una
productividad muy baja.
80
CAPÍTULO 4
En la primera grafica podemos observar el tiempo mínimo de ejecución de cada
carga de trabajo, siendo el valor de la productividad el máximo obtenido durante las
pruebas.
70000
60000 Runtime
milisegundos
50000
40000
30000
20000
10000
0
A B C D E F
Cargas de trabajo
Ilustración 50 - Comparativa de tiempo entre los workloads
Podemos observar que el ‘workload’ E es el que más tiempo tarda en ejecutarse

debido a su baja productividad. El resto de ‘workloads’ mantienen un tiempo de ejecución
mínimo alrededor de unos 10000 milisegundos.
Latencia
En esta gráfica comparamos la latencia obtenido por las operaciones en el momento
de máxima productividad del workload.
14000
12000 Latencia
microsegndos
10000
8000
6000
4000
2000
0
A B C D E F
Cargas de trabajo
Ilustración 51 - Comparativa de latencia entre los workloads
Observamos que la mayor latencia se encuentra en el workload E debido a que las

operaciones de escaneo de registro provocan gran latencia, en cambio el workload C tiene
la menor latencia ya que únicamente utiliza operaciones de lectura.
81
CAPÍTULO 4
CONCLUSIONES
Una vez hemos estudiado el rendimiento de los distintos workloads en cada una de
las máquinas virtuales, realizamos una comparación directa entre los dos tipos de máquinas
(avanzada y básica).
Productividad
700
600 Avanzada
operaciones/segundo
500 Básica
400
300
200
100
0
A B C D E F
Cargas de trabajo
Ilustración 52 - Comparativa de productividad entre los workloads de los dos tipos de máquinas
virtuales
La máquina virtual avanzada obtiene una mayor productividad en todas las cargas de
trabajo, siendo más notorio en el workload E donde casi dobla la productividad de la
máquina básica. Sin embargo en la workload C, que requiere menos potencia, la diferencia
es muy reducida.
82
CAPÍTULO 4
120000
Avanzada
100000
Básica
milisegundos
80000
60000
40000
20000
0
A B C D E F
Cargas de trabajo
Ilustración 53 - Comparativa de tiempo entre los workloads de los dos tipos de máquinas virtuales
Las diferencias de tiempo de son ligeramente favorables a la máquina avanzada.

Excepto para el workload E, que requiere un gran trabajo por parte del sistema, donde la
máquina avanzada reduce casi a la mitad el tiempo de ejecución.
Latencia
25000
Avanzada
20000
Básica
microsegundos
15000
10000
5000
0
A B C D E F
Cargas de trabajo
Ilustración 54 - Comparativa de latencia entre los workloads de los dos tipos de máquinas virtuales
Con la latencia ocurre algo similar al tiempo de ejecución, las diferencias entre
máquinas son relativamente pequeñas, excepto para el workload E donde se nota una gran
diferencia entre la máquina avanzada y la máquina básica.
Por lo tanto queda claro que la máquina virtual avanzada ofrecerá un mayor
rendimiento que la máquina virtual básica, especialmente en las cargas de trabajo que
implican un gran esfuerzo por parte del sistema para realizarlas.
83
CAPÍTULO 4
Ahora bien, salvo en el caso del workload E, habría que valorar si el coste más
elevado de una máquina avanzada justifica la ganancia obtenida en prestaciones.
4.4.4 CONCLUSIONES FINALES SOBRE EL DISEÑO DEL SISTEMA
Al existir un gran número de decisiones respecto a la arquitectura de un sistema

cloud, es posible desarrollar un gran número de configuraciones. Al tener tantas
posibilidades es imposible que uno obtenga el mejor resultado en todos los testeos con los
distintos ‘workloads’, cada uno puede funcionar mejor con distintas aplicaciones. Es decir,
dependiendo de la arquitectura utilizada cada sistema tendrá unas mejoras y unos
inconvenientes.
- Rendimiento en la lectura VS Rendimiento en la escritura: En los sistemas que

ofrecen servicios, el hecho de no saber si el próximo registro será de escritura o de lectura
es un inconveniente. Se ha demostrado que los workloads con operaciones de lectura
obtienen mejores rendimientos que los workloads con mayoría de operaciones de escritura.
Como se puede observar en las Ilustraciones 46, 49 y 52, a medida que aumenta el
número de operaciones de lectura del workload sus resultados de productividad aumentan
considerablemente además de reducirse el tiempo total. Además, queda demostrado que
sucede tanto en la máquina virtual básica como en la avanzada.
En concreto el workload A, que posee un 50% de operaciones de escritura y un 50%

de operaciones lectura, proporciona menor productividad que el workload B, que realiza un
5% de operaciones de escritura y un 95% de operaciones de lectura. Por último el
workload C, que contiene un 100% de operaciones de lectura, mejora la productividad
respecto a los workload A y B.
84
CAPÍTULO 5
CAPÍTULO 5. CONCLUSIONES Y
PROPUESTAS
En el último capítulo de este documento se habla de las conclusiones extraídas del

trabajo y los objetivos logrados. Además, se comentan las competencias adquiridas y los
posibles trabajos futuros a desarrollar a partir de este trabajo.
5.1 CONCLUSIONES
El alcance del trabajo consiste en realizar un análisis detallado de un despliegue de

servicios cloud mediante XenServer, y evaluar su rendimiento con una batería de pruebas.
Con la realización del trabajo se ha demostrado que se puede contar con nuevas
alternativas tecnológicas y modelos con los que poder ofrecer servicios a nuestros clientes.
Trabajar en este trabajo ha servido para conocer tecnologías desconocidas por

completo por parte del autor de este documento, como puede ser la virtualización o la
computación cloud, los cuales tendrán un futuro más que relevante en el mundo de la
informática.
Una parte importante de este trabajo ha sido la documentación y familiarización con

todas estas tecnologías para tener un conocimiento previo y poder realizar un despliegue
más rápido y menos costoso.
En concreto este trabajo ha aportado importantes conocimientos en el campo de la

virtualización y paravirtualización, además de las diferentes herramientas de dichas
tecnologías. El trabajo también ha permitido adquirir conocimientos de los entornos cloud
y de la herramienta de computación cloud XenServer.
85
CAPÍTULO 5
Por último también ha permitido conocer el uso y funcionamiento de los benchmark

para sistemas cloud en concreto de YCSB; y ha aportado conocimientos del
funcionamiento de base de datos NoSQL y de los gestores de bases de datos NoSQL en
concreto de Cassandra.
También se demuestra que virtualizar requiere un estudio de la utilización de los

recursos de las aplicaciones para analizar si conviene o no instalar máquinas virtuales. Esto
es importante porque a veces es fácil sobrecargar el hardware y como consecuencia no se
obtiene el rendimiento deseado en las aplicaciones deseadas.
Se han desplegado distintas configuraciones haciendo uso de la tecnología de

virtualización XenServer y se ha estudiado la influencia de realizar un escalado vertical
sobre las máquinas virtuales para dar soporte a los requisitos de los usuarios.
Toda esta evaluación se ha realizado prestando especial atención a las aplicaciones

demandantes en operaciones sobre bases de datos tal como es el caso del benchmark
Cloudsuite Data Serving (una de las aplicaciones modelo más demandada hoy en dia
sobre los sistemas cloud), compuesta por YCSB y Cassandra.
5.2 OBJETIVOS LOGRADOS
Durante el desarrollo de este Trabajo Fin de Grado se ha logrado el objetivo

principal, consistente en la evaluación del sistema cloud desplegado.
Además, se han logrado los siguientes objetivos parciales:
- Adquisición de conocimientos sobre las tecnologías Cloud y su posición en el

mercado de las tecnologías.
- Aprendizaje de las fases e implementación de un despliegue Cloud, y de las

tecnologías usadas en el mismo.
- Aprendizaje del uso de un software de virtualización (XenServer), y del benchmark

para sistemas Cloud YCSB.
- Adquisición de conocimientos de bases de datos NoSQL y utilización del gestor

Cassandra.
- Capacidad de análisis de las pruebas obtenidas.
86
CAPÍTULO 5
5.3 COMPETENCIAS ADQUIRIDAS
Durante el desarrollo de este trabajo me han resultado de gran utilidad las

competencias adquiridas durante la carrera y en concreto las del módulo de Tecnologías de
la Información. De las que destacan:
[TI2] Capacidad para seleccionar, diseñar, desplegar, integrar, evaluar, construir,

gestionar, explotar y mantener las tecnologías de hardware, software y redes, dentro de los
parámetros de coste y calidad adecuados.
[TI5] Capacidad para seleccionar, desplegar, integrar y gestionar sistemas de

información que satisfagan las necesidades de la organización, con los criterios de coste y
calidad identificados.
5.4 TRABAJO FUTURO Y POSIBLES AMPLIACIONES
Para finalizar con este último capítulo, comentaremos algunas de las propuestas que
se podrían añadir, al trabajo actual, en trabajos futuros:
El trabajo se ha centrado en hacer pruebas a una y dos máquinas virtuales, pudiendo

ser interesante realizar pruebas a un gran número máquinas virtuales de manera simultánea
y analizar el rendimiento. De esta manera trabajaríamos sobre la escalabilidad horizontal.
Otra opción sería cambiar el gestor de base de datos utilizado, Cassandra, por otro
como HBase o MongoDB; y estudiar las diferencias de rendimiento entre los distintos
gestores de base de datos. También se podría realizar un estudio sobre una base de SQL
para comparar las diferencias entre los resultados obtenidos y evaluar cuál de los dos tipos
de base de datos compensa más utilizar.
Una última posibilidad sería crear máquinas virtuales más potentes, con un hardware
que ofrezca más rendimiento, y aumentar la carga de trabajo sobre ellas para intentar hacer
caer al sistema completo. Sería una manera interesante de trabajar la escalabilidad vertical.
87
BIBLIOGRAFÍA
LIBROS Y ARTICULOS
[XenArt] P. Barham y otros, “Xen and the Art of Virtualization”, Proceedings of

the nineteenth ACM symposium on Operating systems principles, 2003.
[BCSS] Brian F. Cooper y otros, “Benchmarking Cloud Serving Systems with

YCSB”, Procedings of the 1 st ACM Symposium on Cloud Computing,
2010
[SecXen] George Dunlap, “Securing your cloud with Xen’s advanced security
features”, Xen Project 2011
[CitGui] Daniele Tosatto y otros, “Citrix XenServer 6.0 Administration Essential

Guide”, Packt Publishing Ltd, 2012
[NSDs] Sergey Bushik y otros, “A vendor-independent comparison of NoSQL

databases: Cassandra, HBase, MongoDB, Riak”, Informe técnico,
Network World, 2013
[NIST] Peter Mell y otros, “NIST Special Publication 800-145: The NIST
Definition of Cloud Computing”, 2012
[ECCS] Michael Armbrust y otros, “Above the Clouds: A Berkeley View of

Cloud Computing”, Informe técnico UCB/EECS-2009-28, U. Berkeley ,
2009
89
ENLACES INTERNET
[Parsa] Parallel Systems Architecture Lab.

http://parsa.epfl.ch/
Último acceso: 30-06-2014
[SuCit] Citrix, Support.

http://support.citrix.com/
[JoseMa] Blog de virtualización y Computación Cloud.

http://www.josemariagonzalez.es/
[Bujarra] Blog Bujarra 3.0.

http://www.bujarra.com/
[AJOD] AJPD Soft.

http://www.ajpdsoft.com/
[WikiXen] Wiki Xen Project

http://wiki.xenproject.org/
[DocsCit] Docs Citrix

http://docs.vmd.citrix.com/
[DataDoc] Datastax Documentation.

http://www.datastax.com/
[YCSB] GitHub YCSB

https://github.com/
[VMWare] Introduccion Cloud, por VMWare

http://www.vmware.com/es/cloud-computing/
90
[Bilib] Bilib
http://www.bilib.es
[AreaP] Blog de virtualización y Computación Cloud

http://www.areaproject.es/
[XenSrvr] XenServer Org.

http://www.xenserver.org
[Dell] Ventajas Cloud Computing

http://www.dell.com/learn/es/es/esbsdt1/cloud-computing-value-benefits
[ADyn] Amazon DynamoDB

http://aws.amazon.com/es/dynamodb/
[HBas] Base de datos HBase, SAD

http://goo.gl/s0nKuS
[VenVi] Virtualización, Wikipedia

http://goo.gl/dfXzMa
[HYP] Hipervisor, Wikipedia

http://es.wikipedia.org/wiki/Hipervisor
[Cass] Cassandra Wiki, Apache

http://es.wikipedia.org/wiki/Hipervisor
[WiEO] Escalabilidad, Wikipedia

http://es.wikipedia.org/wiki/Escalabilidad
91
92
CONTENIDO DEL CD
En el contenido del CD que acompaña a la memoria podemos encontrar los

siguientes recursos:
 Memoria del trabajo en los formatos PDF, DOCX y DOC dentro del directorio
Memoria.
 Libros y artículos a los que se ha hecho referencia durante la memoria y que se han
utilizado como bibliografía. Los cuales podemos encontrar en el directorio
Bibliografía.
93
94
ANEXO A. MATERIAL USADO
La unidad de computación se compone de servidores HP BL465 G6, donde se han

instalado como sistema operativo Citrix XenServer, destinado para la instalación del
sistema de virtualización.
Datos Generales
Características Servidor Físico
SO Citrix Xen Server
Arquitectura 64 bits
RAM 48Gb
Ubicación CPD Edificio Emprendedores
Almacenamiento
Una LUN de 6GB para sistema designada desde la EVA
Una LUN de 850GB para datos designada desde la EVA
Datos Generales
Host XenServer 6.0 perteneciente al Clúster ALBACETE
Virtual Switch Interfaces Direccionamiento
Todas las VLANS
Network Nic2 y Nic3
permitidas
Almacenamiento
Datastore Capacidad Tipo
HBA 700GB SR
Servicio de
virtualización Citrix SRVXEN01 192.168.8.10 Física (Blade)
XenServer
Servicio de
XenServer
95
Servicio de
XenServer
Servicio de
virtualización Citrix SRVPROD01 192.168.8.13 Física (Blade)
XenServer
La unidad de almacenamiento posee dos elementos principales un sistema SAN y un

sistema NAS.
El sistema SAN es gestionado por HP EVA 4400, conexionado a la unidad de

procesamiento mediante Fibre Channel usando Fibre Channel - Switch
Para el sistema NAS se utiliza HP StoargeWorks X1800 G2, su labor principal es

realizar las labores de backup.
Datos Generales
Marca y modelo HP Storage Works X1800 G2
RAID 50
Almacenamiento
FTP 961.30GB
ISOS 1.68TiB
Sin asignar 8.30TiB
Servidor HP StorageWorks X1800 G2 donde se ha instalado como sistema

operativo Linux Ubuntu 10.10. Esta máquina es la encargada de realizar las funciones de
repositorio y FTP.
Datos Generales
Características Servidor Físico
SO Linux Ubuntu 10.10
Arquitectura 64 bits
Número de serie CZC93830GZ
Almacenamiento
Dos discos duros SAS de 140GB en RAID 1 para Sistema Operativo Linux
Ubuntu 10.10
Diez discos duros SAS de 2TB en RAID 6
Como ya se ha comentado anteriormente, las copias de seguridad de las

configuraciones de los dispositivos y bases de datos de los servicios del centro
demostrador se alojan en el servidor NAS.
96
Para el sistema de redes se utilizan dos equipos encargados de la gestión de IPs y
puertos situados en el armario 1.
Datos Generales Módulo Netbotz

System Name NetBotz1
Número de serie QA1049180255
Armario 1
Ubicación
(Emprendedores)
Datos Generales Módulo Eagle

System Name Eagle1
Número de serie 12761
Armario 1
Ubicación
(Emprendedores)
Sensores
Humedad Activado
Temperatura Activado
Humos Activado
Apertura Activado
Inundación Activado
Device Type Monitoring Single Phase
Energía
Fuente Voltaje Límite
A 228V 1.129,4 Wh
B 229V 1.179,4 Wh
Datos Generales Módulo Control Infraestructura (ISX Central)

Versión de software 6.0.2.21
Número de serie 16986804586516
302914
Las redes son gestionadas por dos switches (cores):
Datos Generales
Modelo CISCO WS_C4948E
Catalyst 4500 L3 Switch Software
Versión del software
v12.2
48 Gigabit Ethernet y 4 10Gigabit
Número de puertos
Ethernet
CPD Centro TIC CORE1
Ubicación
Emprendedores
97
Número de serie CAT1425S0Q5
Datos Generales
Modelo CISCO WS_C4948E
Catalyst 4500 L3 Switch Software
v12.2
48 Gigabit Ethernet y 4 10Gigabit
Número de puertos
Ethernet
Ubicación CPD Centro TIC CORE2
Número de serie CAT1425S0SQ
Y un router:
Datos Generales
Modelo Cisco 2900
c2900-universalk9-mz.SPA.150-
1.M3.bin
Número y tipo de puertos 2eth,4bri,1 atm,vbri
CPD Centro TIC CORE1
Ubicación
Emprendedores
Número de serie FCZ1440C0HU
Respecto a la seguridad del CPD, se cuenta con dos equipos de seguridad (firewalls).
Cada equipo de seguridad está formado por dos componentes hardware; un componente
para seguridad perimetral y un componente para protección IDS.
Por tanto, el CPD dispondrá tanto de seguridad perimetral como de protección IDS
con componentes configurados en modo Failover Active/Standbye. El firewall IDS no
tienen reglas de filtrado, solamente actúa como filtro IDS.
Componente para la protección IDS Firewall 1
Datos Generales
Modelo Serie 5500
Versión del software asa831-k8
Funcionalidad Protección IDS
Número y tipo de puertos 7
Ubicación CPD Centro TIC
Número de serie JMX1446L1J0
Componente para la protección IDS Firewall 2
Datos Generales
Modelo Serie 5500
98
Funcionalidad Protección IDS
Número de serie JMX1446L2RH
Componente para la protección perimetral Firewall 1
Datos Generales
Modelo Serie 5500
Funcionalidad Perímetro
Número de serie JMX1446L0AK
Componente para la protección perimetral Firewall 2
Datos Generales
Modelo Serie 5500
Funcionalidad Perímetro
Por último, el material software usado durante el despliegue ha sido:
- CD instalación XenServer 6.0

- CD Supplemental pack Linux
- XenCenter para Windows
- XenTools
- Citrix License Server
99
Ilustración 55 - Esquema básico del despliegue. Fuente Bilib
100
101
ANEXO B. PROCESO DE INSTALACIÓN
DE CLOUDSUITE DATA SERVING
B.1 INTRODUCCIÓN
En este anexo se define el proceso de instalación completo de CloudSuite Data

Serving, incluyendo las aplicaciones requeridas para dicha instalación.
B.2 PROCEDIMIENTO
Este proceso se realizará tanto en el nodo cliente como en el nodo servidor, ya que es
la única manera de que se comuniquen entre sí las bases de datos y se ejecute el
benchmark.
Aplicaciones previas:
JAVA
Lo primero que se debe hacer es instalar JAVA, en concreto la versión 1.6_23 para
Linux.
Para ello se descarga desde el directorio http://cran.cc.uoc.gr, mediante el comando:
103
wget http://cran.cc.uoc.gr/Java/Linux-x86_64/1.6u23/jdk-6u23-linux-amd64.rpm
Se actualizan los repositorios de Ubuntu:
wget http://www.java.net/download/jdk6/6u23/promoted/b01/binaries/jdk-6u23-ea-
bin-b01-linux-amd64-30_aug_2010.bin
mv jdk-6u23-ea-bin-b01-linux-amd64-30_aug_2010.bin /usr/local
sh jdk-6u23-ea-bin-b01-linux-amd64-30_aug_2010.bin
Se reinicia la máquina:
shutdown -r now
Se confirma que se ha instalado la versión de Java correctamente:
java –versión
Además, es posible confirmar que se incluye el compilador Java incluido en el JDK

(kit de desarrollo Java):
javac –versión
104
Configurar ruta 'JAVA_HOME':
Editar el archivo environment:
sudo nano /etc/environment
Añadir las siguientes líneas al archivo environment:
JAVA_HOME = "/usr/local/jdk1.6.0_23/bin/"
JRE_HOME = "/usr/local/jdk1.6.0_23/jre"
PATH ="...(otras rutas):$JAVA_HOME:$JRE_HOME
Realizar el mismo proceso con el archive profile:
sudo nano /etc/profile
Y añadir:
JAVA_HOME = "/usr/local/jdk1.6.0_23/bin/"
PATH ="...(otras rutas):$JAVA_HOME:$JRE_HOME
105
export JAVA_HOME
export PATH
Por último se actualizan los archivos editados:
source /etc/environment
source /etc/profile
Apache
Instalar Apache en el equipo:
sudo apt-get install apache2
Ant
Instalar Ant en el equipo:
sudo apt-get install ant
106
YCSB
Descargar la versión deseada de YCSB, en este caso la versión es 0.1.3:
wget http://parsa.epfl.ch/cloudsuite/software/dataserving.tar.gz
Descomprimir el archivo:
tar xfvz dataserving.tar.gz
Acceder a la carpeta descomprimida y realizar un ant.
cd YCSB
Ant
Volver al directorio anterior:
cd ..
Ahora descargar el fichero comprimido que contiene Cassandra, en concreto la

versión 0.7.3:
wget http://archive.apache.org/dist/cassandra/0.7.3/apache-cassandra-0.7.3-
bin.tar.gz
107
Descomprimir Cassandra y copiar todos sus archivos .jar al directorio
~/YCSB/db/cassandra-0.7/lib/:
tar xfvz apache-cassandra-0.7.3-bin.tar.gz
cd apache-cassandra-0.7.3-bin.tar.gz/lib/
cp *.jar ~/YCSB/db/cassandra-0.7/lib/
Volver al directorio donde se encuentra YCSB y compilar:
cd ~/YCSB/
ant
ant dbcompile-cassandra-0.7
shutdown -r now
Ya se ha completado la instalación de YCSB compatibilizándolo con Cassandra

como base de datos.
108
Cassandra
Ir al directorio donde se ha descomprimido Cassandra anteriormente:
cd ~/ apache-cassandra-0.7.3-bin.tar.gz/
Buscar el archivo Cassandra-env.sh en /conf y editarlo:
sudo nano cassandra-env.sh
Cambiar el parámetro JVM_OPTS –Xss128k descrito en su código y modificarlo

por:
JVM_OPTS -Xss256k
Crear un par de carpetas para guardar los logs del programa y concederles
privilegios:
sudo mkdir -p /var/log/cassandra
sudo chown -R `whoami`/var/log/cassandra
sudo mkdir -p /var/lib/Cassandra
sudo chown -R `whoami` /var/lib/cassandra
109
Se inicializa Cassandra
bin/cassandra –f
Salir y comprobar que funciona para la máquina local:
bin/cassandra-cli --host localhost
Ahora generar una base de datos con Cassandra, primero generar un keyspace
llamado usertable:
create keyspace usertable with replication_factor=1;
A continuación nombrar el keyspace:
use usertable;
Crear una columna de familia:
create column family data with column_type = 'Standard' and comparator =

'UTF8Type';
Y salir de Cassandra, con ello ya se habrá generado la base de datos:
exit;
110
De esta manera ya se habría instalado todo el software necesario para las pruebas, el
siguiente paso sería configurar el servicio Cassandra, desde su archivo de configuración
Cassandra.yalm, estableciendo los parámetros correspondientes.
Y por último habría que crear dos archivos llamados settings.dat y settings_load.dat
donde se incluyen los parámetros necesarios para la ejecución del benchmark y que será
suministrado a la aplicación mediante su invocación en el comando de llamada al
benchmark.
En el directorio de YCSB
cd ~/YCSB/
Es posible cargar la base de datos en el Benchmark, eligiendo un ‘workload’

determinado y pasándole algunos parámetros mediante el archivo settings_load.dat:
java -cp build/ycsb.jar:db/cassandra-0.7/lib/* com.yahoo.ycsb.Client -load -s -db

com.yahoo.ycsb.db.CassandraClient7 -P workloads/workloada -P settings_load.dat
Y ejecutar el Benchmark, con un ‘workload’ determinado y pasándole algunos

parámetros mediante el archivo settings.dat:
java -cp build/ycsb.jar:db/cassandra-0.7/lib/* com.yahoo.ycsb.Client -t -s -db

com.yahoo.ycsb.db.CassandraClient7 -P workloads/workloada -P settings.dat
Por último para configurar YCSB se utilizan estos comandos:
- Hosts: Direcciones IP de los nodos servidores en los que se van a ejecutar las
pruebas.
- Threadcount: Número de hilos que se van a ejecutar en paralelo en una prueba. Por
defecto, YCSB usa un único hilo, pero es posible añadir más hilos. Esto es habitual
- Recordcount: Número de registros usados por la base de datos.

111
- Operationcount: Parámetro exclusivo de la fase de ejecución, sirve para determinar
el número de operaciones totales que ejecutará el benchmark.
- Target: Este parámetro representa la tasa de servicio del sistema, esto equivale al
número de operaciones realizadas por segundo, que determinarán la productividad
del sistema. Por defecto, YCSB intentará completar tantas operaciones como
pueda. Por ejemplo, si cada operación tarda 100 milisegundos de media, el cliente
realizará alrededor de 10 operaciones por segundo por hilo. Para generar una
latencia en el rendimiento, es posible utilizar distintos ‘targets’ y medir la latencia
de cada uno.
Los parámetros adicionales para configurar YCSB son:
o fieldcount: Número de campos en un registro (por defecto 10)

o fieldlength: Tamaño de cada campo (por defecto 100)
o readallfields: Leer todos los campos (por defecto true)
o readproportion: Que proporción de operaciones deben ser de lectura (por
defecto 0.95)
o updateproportion: Que proporción de operaciones deben ser update (por
defecto 0.05)
o insertproportion: proporción de operaciones deben ser inserciones (por
defecto 0)
o scanproportion: Que proporción de operaciones deben de ser escaneos (por
defecto 0)
o readmodifywriteproportion: Que proporción de operaciones deben ser
lectura de un registro, modificación de dicho registro y escritura del valor
anterior (por defecto 0)
o requestdistribution: Que distribución debe ser usada para seleccionar los
registros a operar (por defecto uniforme)
o maxscanlength: Número máximo de registros a escanear (por defecto 1000)
o scanlengthdistribution: Que distribución debe ser usada para elegir el
número de registros a escanear, entre 1 y maxscanlength (por defecto
uniforme)
o insertorder: Como deben ser insertados los registros, en orden por clave o
por orden hashed (por defecto hashed)
o operationcount: Número de operaciones a ejecutar
112
o maxexecutiontime: Tiempo máximo de ejecución en segundos. El
benchmark se ejecuta hasta que el contador de operaciones llegue a su tope
o se llegue al tiempo máximo, el primero que se cumpla.
o table: Nombre de la tabla (por defecto usertable)
113

Xen Server

Cargado por

Copyright:

Formatos disponibles

Xen Server

Cargado por

Información del documento

Descripción original:

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

Xen Server

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INGENIERÍA

GRADO EN INGENIERÍA INFORMÁTICA

TRABAJO FIN DE GRADO

Despliegue de una infraestructura Cloud basada en

Mario González Cifuentes

Departamento de Sistemas Informáticos

TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN

TRABAJO FIN DE GRADO

Despliegue de una infraestructura Cloud basada en

Autor: Mario González Cifuentes

Este trabajo se realiza en colaboración con Bilib (Centro de Apoyo Tecnológico a

El objetivo principal de este trabajo consiste en evaluar el rendimiento de dicha

Me gustaría dar las gracias a mis

CAPÍTULO 1. INTRODUCCIÓN ......................................................................... 9

CAPÍTULO 2. ESTADO DEL ARTE .................................................................. 13

CAPÍTULO 3. INFRAESTRUCTURA CLOUD DESPLEGADA EN BILIB ...... 35

CAPÍTULO 4. EVALUACIÓN DEL SISTEMA .................................................. 45

CAPÍTULO 5. CONCLUSIONES Y PROPUESTAS ...........................................85

CONTENIDO DEL CD...........................................................................................93

ANEXO A. MATERIAL USADO ........................................................................95

ANEXO B. PROCESO DE INSTALACIÓN DE CLOUDSUITE DATA SERVING

Tabla 1 - Resumen de la historia de la computación ............................................... 14

En este primer capítulo se realiza una breve introducción a la computación Cloud y

En el presente Trabajo Fin de Grado se plantea el despliegue y evaluación de una

Hoy en día la mayoría de empresas TIC utilizan servicios en la cloud. El problema

Esto motivó la instalación de máquinas virtuales en los servidores para exprimir el

Otra importante ventaja es la facilidad de escalabilidad de los servidores, ya que

Ilustración 1 - Servicios que ofrece Bilib a través del servicio Cloud

A tal fin, se dispone de una infraestructura de computación en el Centro de

La principal motivación para la realización de este trabajo es la necesidad del

Estos servidores sufren un gran desaprovechamiento de rendimiento en el uso de

Para evitar este desaprovechamiento de los servidores surge la virtualización, con la

Además, el término 'servidor web' como la típica computadora física, situada en un

El principal objetivo que se persigue con este trabajo es la evaluación de una

Todo esto estará precedido de un estudio de la tecnología y del material utilizado,

Este es el objetivo general que se puede desglosar en los siguientes objetivos

- Familiarización con la tecnología Cloud

- Análisis y evaluación de rendimiento de distintas configuraciones

1.4 ESTRUCTURA DE LA MEMORIA

El documento se divide en cinco capítulos. El primero de ellos consiste en una

El capítulo cuatro consiste en la recopilación de las distintas pruebas realizadas en

En el quinto y último capítulo podemos encontrar las conclusiones y conocimientos

CAPÍTULO 2. ESTADO DEL ARTE

En este capítulo se presenta el estado de la cuestión sobre la computación cloud,

También contiene un análisis de XenServer, el hipervisor sobre el que se basa el

En los inicios de la computación se utilizaban los mainframes, que eran

Más tarde (80’s) aparecieron los PC u ordenadores personales, así las

Años después de la aparición de Internet aparecieron webs como Yahoo, Google o

La Tabla 1 muestra una comparativa de los distintos modelos de computación a lo

Modelo de Características Costes

Mainframe Centralizado Sistemas que Inversión inicial tanto

Tabla 1 - Resumen de la historia de la computación

2.2 COMPUTACIÓN CLOUD

El modelo de computación Cloud es un modelo que habilita el acceso a un conjunto

A continuación se detallan las características básicas de la computación Cloud,

Las principales características de la computación Cloud son:

- Servicio propio bajo demanda: Un consumidor puede suministrar de manera