Memoria PFC - Juan Valero
Memoria PFC - Juan Valero
Memoria PFC - Juan Valero
1
Antes de empezar me gustaría dar las gracias al director del proyecto, Anto-
nio Barba Martí. También quisiera agradecer a Felip Riera Palou y a Carlos
Müller Cejás por los conocimientos que me han transmitido. Y por último me
gustaría dedicar este proyecto a Alba, a mis amigos, y a mi incombustible fa-
milia por el apoyo prestado durante este largo camino. A todos, gracias por
ayudarme a llegar al nal del túnel.
2
Índice General
1 Introducción 7
1.1 Descripción del proyecto . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Descripción de la memoria . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . 9
3 Algoritmos de planicación 46
3.1 Algoritmos elementales . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Algoritmos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Algoritmos híbridos . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Conclusiones 110
5.1 Conclusiones del proyecto . . . . . . . . . . . . . . . . . . . . . . 110
5.2 Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3
Lista de Tablas
1 Tráco garantizado para cada tipo de tráco . . . . . . . . . . . 36
2 Relación entre variables y coecientes . . . . . . . . . . . . . . . 41
3 Sistema de coecientes para cada perl . . . . . . . . . . . . . . . 41
4 Reparto de requisitos para cada tipo de tráco . . . . . . . . . . 61
5 Recursos necesarios en función del ratio de peticones aceptadas . 86
6 Asignación de distribución de trácos para el caso de estudio del
tipo I (Business) . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Lista de Figuras
1 Visión general de una arquitectura tipo nube basada en SLA. . . 22
2 Mapa conceptual de ofertas de acuerdo. . . . . . . . . . . . . . . 26
3 Ejemplos de posibles ofertas de acuerdo. . . . . . . . . . . . . . . 27
4 Ejemplo de un acuerdo de servicio. . . . . . . . . . . . . . . . . . 28
5 Esquema del comportamiento general del sistema. . . . . . . . . 34
6 Relación entre los tiempos de petición y los posibles modos del
servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7 Proceso de solapamiento. . . . . . . . . . . . . . . . . . . . . . . 50
8 Diagrama de ujo del algoritmo híbrido MiMMO. . . . . . . . . . 58
9 Diagrama de ujo del algoritmo híbrido MiFMLB. . . . . . . . . 63
10 Diagrama de ujo del algoritmo híbrido CoFiLB. . . . . . . . . . 66
11 Porcentaje de peticiones aceptadas en función de la disponibilidad
del servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
12 Coste total del sistema en función de la disponibilidad del servicio. 71
13 Número total de recursos liberados en función de la disponibilidad
del servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
14 Información de ajustes en función de la disponibilidad del servicio. 74
15 Información de balanceos de carga en función de la disponibilidad
del servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
16 Número de pérdidas por servicio saturado en función de la disponi-
bilidad del servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . 76
17 Porcentajes de pérdidas debidas a las tres posibles causas en fun-
ción de la disponibilidad del servicio. . . . . . . . . . . . . . . . . 77
18 Coste medio por recurso utilizado en función de la disponibilidad
del servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
19 Porcentaje de peticiones aceptadas en función del tamaño del
bloque de peticiones. . . . . . . . . . . . . . . . . . . . . . . . . . 79
20 Coste total del sistema en función del tamaño del bloque de peti-
ciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
21 Número total de recursos liberados en función del tamaño del
bloque de peticiones. . . . . . . . . . . . . . . . . . . . . . . . . . 81
22 Información de ajustes en función del tamaño del bloque de peti-
ciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4
23 Porcentajes de pérdidas debidas a las tres posibles causas en fun-
ción del tamaño del bloque de peticiones. . . . . . . . . . . . . . 83
24 Porcentajes de pérdidas por tipo de tráco en función del tamaño
del bloque de peticiones. . . . . . . . . . . . . . . . . . . . . . . . 84
25 Porcentaje de peticiones aceptadas en función del número de re-
cursos por servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . 85
26 Coste total del sistema en función del número de recursos por
servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
27 Número total de recursos liberados en función del número de
recursos por servicio. . . . . . . . . . . . . . . . . . . . . . . . . . 88
28 Información de ajustes en función del número de recursos por
servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
29 Porccentaje de balanceos de carga realizados en función del número
de recursos por servicio. . . . . . . . . . . . . . . . . . . . . . . . 89
30 Porcentajes de pérdidas en función del número de recursos disponibles. 90
31 Porcentaje de peticiones aceptadas en función de la proporción
del tráco tipo I en el sistema. . . . . . . . . . . . . . . . . . . . 92
32 Coste total en función de la proporción del tráco tipo I en el
sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
33 Recursos liberados en función de la proporción del tráco tipo I
en el sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
34 Porcentajes de los mecanismos de ahorro energético en función
de la proporción del tráco tipo I en el sistema. . . . . . . . . . . 94
35 Porcentajes de pérdidas por tráco en función de la proporción
del tráco tipo I en el sistema. . . . . . . . . . . . . . . . . . . . 95
36 Porcentaje de peticiones aceptadas en función de la proporción
del tráco tipo II en el sistema. . . . . . . . . . . . . . . . . . . . 96
37 Coste total en función de la proporción del tráco tipo II en el
sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
38 Recursos liberados en función de la proporción del tráco tipo II
en el sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
39 Porcentajes de los mecanismos de ahorro energético en función
de la proporción del tráco tipo II en el sistema. . . . . . . . . . 98
40 Porcentajes de pérdidas por tráco en función de la proporción
del tráco tipo II en el sistema. . . . . . . . . . . . . . . . . . . . 99
41 Porcentaje de peticiones aceptadas en función de la proporción
del tráco tipo III en el sistema. . . . . . . . . . . . . . . . . . . 100
42 Coste total en función de la proporción del tráco tipo III en el
sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
43 Recursos liberados en función de la proporción del tráco tipo III
en el sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
44 Porcentajes de los mecanismos de ahorro energético en función
de la proporción del tráco tipo III en el sistema. . . . . . . . . . 103
45 Porcentajes de pérdidas por tráco en función de la proporción
del tráco tipo III en el sistema. . . . . . . . . . . . . . . . . . . 104
5
46 Porcentaje de peticiones aceptadas en función de la proporción
del tráco tipo IV en el sistema. . . . . . . . . . . . . . . . . . . 105
47 Coste total en función de la proporción del tráco tipo IV en el
sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
48 Recursos liberados en función de la proporción del tráco tipo IV
en el sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
49 Porcentajes de los mecanismos de ahorro energético en función
de la proporción del tráco tipo IV en el sistema. . . . . . . . . . 107
50 Porcentajes de pérdidas por tráco en función de la proporción
del tráco tipo IV en el sistema. . . . . . . . . . . . . . . . . . . 107
6
1 Introducción
1.1 Descripción del proyecto
Es conocido por todo el mundo que las redes de telecomunicaciones están en
continua evolución. Es por ello que cada día más, se desarrollan nuevas tec-
nologías y aplicaciones que pretenden facilitar y agilizar las actividades tanto
de las empresas como de los usuarios particulares. Esta constante evolución
implica la aparición de nuevas posibilidades dentro del mundo de las comu-
nicaciones. Una de ellas es la posibilidad de descentralizar ciertas funciones
mediante la migración de aplicaciones.
En este contexto surge lo que se conoce como Cloud Computing. Este tipo
de sistemas está formado por una nube de servidores que proporcionan deter-
minados servicios a los usuarios que acceden a ella. Toda red de computadores
conlleva una gran cantidad de complejidades que deben abordarse con seriedad
y otorgarles la relevancia correspondiente. Una de estas adversidades es el con-
sumo del sistema, y cómo optimizarlo con el n de reducir costes y aumentar
la celeridad en las comunicaciones. Este proyecto propone tres algoritmos que
proporcionen un determinado ahorro en los costes minimizando el tiempo de
uso efectivo de los nodos de la nube. Para ello se ha trabajado con un mecan-
ismo de negociación de parámetros de calidad de servicio llamado Service Level
Agreement (SLA en adelante). Gracias a este protocolo se han podido establecer
ciertos niveles de calidad de servicio (perles de usuario, tráco garantizado,...).
Los algoritmos propuestos deberán implementarse en unos elementos de la nube
llamados Schedulers.
Para poder realizar este proyecto se han tenido en cuenta una serie de vari-
ables que inuyen directamente en el consumo total del sistema, como pueden
ser el número de CPU's (o nodos de la nube) que se acuerda en la negociación
SLA, o los tiempos de tarea o valores temporales límite (deadline times ). Tam-
bién se han tenido en consideración otros factores ajenos a la negociación SLA,
como por ejemplo el tiempo total virtual del sistema.
Con el n de determinar la eciencia de todos los algoritmos propuesto e
implementados en este proyecto, se han realizado una serie de simulaciones
en el proyecto. Gracias a dichas simulaciones se ha podido estudiar el com-
portamiento y las prestaciones de los mecanismos de gestión y asignación de
recursos propuestos en el presente documento.
1.2 Objetivos
El principal objetivo de este proyecto es el de desarrollar una serie de algoritmos
que proporcionen un ahorro del coste en un sistema de Cloud Computing basado
en SLA. Sin embargo, este objetivo principal puede desglosarse en una serie de
objetivos más especícos. A continuación se indican estos objetivos:
7
• Poner a prueba estas técnicas mediante el desarrollo de algoritmos e-
cientes.
Cabe destacar que es necesario alcanzar una serie de hitos o metas que suponen
el medio para lograr satisfacer los objetivos. Dichos hitos son los siguientes:
8
de tablas y grácas comparativas que permiten examinar las cualidades de cada
algoritmo. Los resultados que se muestran en este capítulo certican el ahorro en
el coste que ofrecen las diferentes soluciones propuestas para una gran cantidad
de situaciones diferentes.
En el quinto y último capítulo se resumen brevemente las conclusiones más
relevantes que a las que se han llegado con la realización de este proyecto.
Además este capítulo incluye una serie de posibles trabajos futuros relacionados
con la temática de este proyecto.
Matlab
Para realizar las simulaciones de las prestaciones de los algoritmos, se ha
utilizado la herramienta Matrix Laboratory ( ) en su versión 7.10.0.499
Matlab
(R2010a), ya que proporciona muchas de las funciones necesarias para poder
simular correctamente el entorno que este proyecto precisa. es un pro-
grama de cálculo numérico especializado en vectores y matrices, con lo que en-
Matlab
caja perfectamente con las necesidades de simulación de este proyecto. Además,
cuenta con un lenguaje de programación propio, lo cual resulta muy
atractivo a la hora de implementar el funcionamiento de los diferentes algoritmos
de asignación de recursos.
AT X, que es
Para la realización del presente documento se ha empleado L E
un sistema de composición de textos, orientado especialmente a la creación de
libros, documentos cientícos y técnicos que contengan fórmulas matemáticas.
Típicamente se usa para la composición de artículos académicos, tesis y libros
técnicos dado que la calidad tipográca de los documentos realizados con L AT X
E
es comparable a la de una editorial cientíca de primera línea. Es por ese motivo
por lo que se ha creído conveniente utilizarlo para ese n.
9
2 Descripción del entorno de trabajo
En este capítulo se describe el entorno en el que se ha trabajado para la re-
alización del proyecto. Para poder comprender mejor el entorno del proyecto,
es necesario establecer primero unas bases teóricas a cerca de las principales
tecnologías relacionadas con el mismo. En el presente documento se abordan
los aspectos más relevantes de los sistemas de computación de tipo nube y
del protocolo de negociación SLA. Se completará este apartado teórico con un
breve repaso al estado del arte en lo referente a la forma de abordar el ahorro
energético en entornos de Cloud Computing. Una vez se disponen de los con-
ceptos básicos teóricos, se puede elaborar un sistema de trabajo con el que se
puedan realizar simulaciones y evaluar los resultados obtenidos. En la parte
nal de este capítulo se representará un esquema del escenario implementado
en el proyecto, comentando todos y cada uno de los elementos que intervienen
en él.
10
acceder a un catálogo de servicios estandarizados y responder con ellos a las
necesidades de su negocio, de forma exible y adaptativa, en caso de deman-
das no previsibles o de picos de trabajo, pagando únicamente por el consumo
efectuado, o incluso gratuitamente en caso de proveedores que se nancian por
publicidad o de organizaciones sin ánimo de lucro. La Computación en la Nube
consigue aportar estas ventajas, apoyándose sobre una infraestructura tecnológ-
ica dinámica que se caracteriza, entre otros factores, por un alto grado de au-
tomatización, una rápida movilización de los recursos, una elevada capacidad de
adaptación para atender a una demanda variable, así como virtualización avan-
zada y un precio exible en función del consumo realizado evitando además el
uso fraudulento del software y la piratería. A nivel de software se considera que
Cloud Computing sigue una arquitectura orientada a servicios de cliente (en
inglés Service Oriented Architecture, SOA). Una arquitectura orientada a servi-
cios proporciona una metodología y un marco de trabajo en el que se denen
una serie de capas software que permiten desarrollar sistemas de información
modulables y altamente escalables.
En la actualidad, el término Cloud Computing está muy extendido y es
utilizado de diversas formas y para diversos propósitos. A veces, incluso se
ve inuenciado por el marketing para dar valor a un producto. Es por eso
que existen muchas maneras de denir este concepto. Por ejemplo, según un
informe de la consultora McKinsey&Company, las nubes son servicios basados
en hardware que ofrecen capacidades de computación, redes y almacenamiento
de modo que:
Para el IEEE Internet Computing, sin embargo, Cloud Computing es un paradigma
en el que la información es almacenada en servidores de Internet de forma perma-
nente y cacheada temporalmente sobre los clientes (ordenadores de sobremesa,
centros de entretenimiento, portátiles, etc.). Si se les pregunta a distintas
personas, aún cuando estén relacionadas con el mundo de la informática o las
telecomunicaciones, seguramente se obtendrían tantas respuestas como número
de interrogados. Incluso pueden encontrarse respuestas en contra de este mod-
elo. Para evitar esta confusión, a partir de las deniciones anteriores y después
de un exhaustivo estudio sobre este paradigma, puede concluirse que:
Cloud Computing es un paradigma informático que consiste en que los re-
cursos de computación son proporcionados como servicio ( as a service ), per-
mitiendo a los usuarios acceder a servicios tecnológicos desde Internet ( en la
nube , y por lo tanto desde cualquier dispositivo y cualquier lugar del mundo)
bajo demanda.
11
2.1.2 Conceptos importartes relacionados con el Cloud Computing
En este apartado, se incluyen una serie de términos relacionados con el Cloud
Computing que son de obligado conocimiento y que facilitarán el seguimiento
del texto de aquí en adelante.
12
elementos compartidos no aislados permitiría a los usuarios interactuar con ma-
terial perteneciente a otros de forma trivial, generando riesgos relativos a la
seguridad.
Lleva asociadas unas cuotas iniciales de pago más bajas que el resto
de implementaciones. Adicionalmente los costes del cloud público
son variables, cumpliendo el principio de pago por uso.
1 Según el estudio Cloud Computing, Retos y Oportunidades realizado por el equipo de Es-
tudios del Observatorio Nacional de las Telecomunicaciones y de la Sociedad de la Información
(ONTSI).
13
Todas estas características suponen una serie de inconvenientes asociados
a ellas. Las principales desventajas de las nubes públicas son pues:
2 Según el mismo estudio Cloud Computing, Retos y Oportunidades realizado por el equipo
de Estudios del Observatorio Nacional de las Telecomunicaciones y de la Sociedad de la In-
formación (ONTSI).
14
Elevado coste material.
Con una solución de cloud híbrido, al igual que en los casos detallados
anteriormente, se consigue una rápida puesta en servicio.
15
con las ventajas evidentes que ello conlleva en términos de elasticidad.
Sin embargo, la cantidad de recursos es menor que los existentes en una
solución de cloud público, limitando la elasticidad respecto a dicho cloud
público. Por otra parte, el número de usuarios de este tipo de nube es
menor que los de la nube pública, lo que la dota de mayores prestaciones
en cuestiones de seguridad y privacidad .
3
Tal y como ocurría con el resto de nubes, las nubes comunitarias tienen
una serie de ventajas, como son:
16
De esta forma se reducen los costes tanto de software como hardware, así
como los gastos de mantenimiento y operación. Las consideraciones de
seguridad son controladas por el proveedor del servicio. El suscriptor del
servicio únicamente tiene acceso a la edición de las preferencias y a unos
privilegios administrativos limitados.
Los clientes que optan por este tipo de familia cloud en vez de adquirir o
dotarse directamente de recursos como pueden ser los servidores, el espa-
cio del centro de datos o los equipos de red optan por la externalización
17
en busca de un ahorro en la inversión en sistemas TI. Con esta external-
ización, las facturas asociadas a este tipo de servicios se calculan en base
a la cantidad de recursos consumidos por el cliente, basándose así en el
modelo de pago por uso [2].
• Velocidad. El acceso de alta velocidad hará del uso del Cloud Computing
para sus usuarios una grata experiencia.
18
• Estabilidad. El uptime es un aspecto importante para los sitios Web y
aplicaciones de las empresas que contratan los servicios Cloud. Con el sis-
tema de distribución de recursos este uptime aumenta signicativamente,
pues si una máquina presenta algún fallo las otras continuarán sirviendo
las aplicaciones y archivos. Al utilizar mecanismos de optimización de
gestión de recursos (como la virtualización y los balanceos de carga) es
posible aprovechar al máximo los recursos disponibles y afrontar mejor
situaciones adversas, como picos de demanda.
19
• Cuidado con la escalabilidad automática. Una computación tipo
nube es susceptible a ataques tipo DDoS (Distributed Denial of Service ).
Este ataque consiste en que alguien con malas intenciones ataca una apli-
cación o una web cualquiera con la intención de colapsarla, lanzando peti-
ciones desde múltiples terminales de manera concurrente y masiva. Al
nal, el servicio cae ya que no es capaz de satisfacer todas las peticiones
solicitadas.
Desde el punto de vista del hardware, el Cloud Computing incorpora tres as-
pectos nuevos con respecto a los sistemas de computación tradicionales [3]:
• Software comercial.
20
Ese equilibrio se consigue con un proceso de negociación. Al nal del proceso
de negociación, proveedor y el consumidor se comprometen a un acuerdo. Es
importante destacar que no siempre ambas partes están de acuerdo, por lo que
el proceso de negociación puede suponer varios mensajes entre ellos, hasta que,
tanto consumidor como proveedor de servicios lleguen a un acuerdo en el que
las necesidades y exigencias de ambos queden satisfechas, deniendo claramente
las obligaciones de cada una de las partes. Otro aspecto que suele abarcar este
tipo de acuerdos son las compensaciones en caso de incumplimiento de contrato.
El uso comercial de los servicios web, y en general en entornos orientados a
servicios, suele estar regulado por los que se conoce como acuerdos de nivel de
servicio (Service Level Agreement, SLA). Según H. Ludwig et al. un contrato
SLA recoge las obligaciones de cada una de las partes, los métodos para medir su
grado de cumplimiento, su modelo de facturación y las medidas sancionadoras
en caso de violación de los términos del contrato [4]. Resumiendo, un SLA es
un contrato legalmente vinculante entre un proveedor y un usuario, que dene
los términos del acuerdo entre ambas partes a nivel de servicio, especicando
obligaciones, responsabilidades, garantías y compensaciones. Si bien este con-
trato se puede denir de cualquier manera mientras los clientes sean capaces de
entenderlo y aceptarlo, comúnmente se ofrece simplemente como un documento
de texto que es accesible por las partes.
En la actualidad los proveedores Cloud ofrecen una visión muy básica de
los SLAs para sus clientes. Como obligación se establece una compensación,
habitualmente en forma de descuento en la facturación, a los usuarios en caso de
violación del contrato. Otros aspectos candidatos a formar parte de un acuerdo
de servicio, son los requisitos de CPU o memoria, restricciones geográcas, etc.
Utilizando un SLA, es la propia nube la encargada de llevar a cabo operaciones
encaminadas al cumplimiento de los contratos. De forma complementaria, la
nube también puede realizar comprobaciones del estado de los SLA, determinar
si se han violado sus términos, realizar acciones correctoras, noticar al usuario
del incidente y ejecutar los procedimientos de compensación adecuados.
Resulta evidente que disponer de un acuerdo entre las partes implicadas
en un entorno orientado a servicios, es ampliamente benecioso tanto para el
consumidor como para el proveedor de servicio. Para los consumidores, el SLA
tiene las siguientes ventajas:
21
ůƵƐƚĞƌϭ
ůƵƐƚĞƌϮ
ƌŽŬĞƌϮ
W^ WĂŶŝĨŝĐĂĚŽƌ
ůŽĐĂůϭ
ZĞĐƵƌƐŽƐ
ĐŽŵƉƵƚĂĐŝŽŶĂůĞƐ
W^ WĂŶŝĨŝĐĂĚŽƌ
ůŽĐĂůϮ
^
ƌŽŬĞƌ W^
W^ WĂŶŝĨŝĐĂĚŽƌ
ůŽĐĂůϯ
. ZĞĐƵƌƐŽĚĞ
. ĂůŵĂĐĞŶĂŵŝĞŶƚŽ
ƌŽŬĞƌϯ WĂŶŝĨŝĐĂĚŽƌ
ůƵƐƚĞƌϯ W^
ůŽĐĂůŶ
DĞƚĂͲ^>
^ƵďͲ^>
• Ofrecer a sus clientes informes que muestren que se cumplen los tiempos
de actividad, o incluso que se excede el SLA.
22
elementos que participan en la negociación son los siguientes:
23
Cada uno de estos elementos del sistema expuestos anteriormente puede
adoptar un determinado rol dentro de la negociación del SLA. Los diferentes
roles que pueden tomar las partes de la negociación son los siguientes:
Una vez expuestos los diferentes elementos que forman parte de la arquitectura
del sistema, resulta evidente la importancia de la planicación y gestión de
recursos, sobretodo en entornos de alto rendimiento como la nube. La existencia
de algoritmos ecientes de planicación podría ser de crucial importancia a la
hora de estimar la capacidad del sistema, y aumentar las probabilidades de
aceptación de una determinada petición. Muchos de estos algoritmos están
basados en colas de prioridad o recompensas y ahorros económicos. No obstante,
este proyecto se ha centrado en desarrollar algoritmos de planicación y gestión
de recursos basándose en el ahorro del coste.
24
objetos de nivel de servicio y se centra fundamentalmente en la descripción y
monitorización de acuerdos de calidad.
WS-Agreement [12] es una recomendación propuesta por el grupo de trabajo
del Object Grid Forum, que proporciona una estructura para describir ofertas
de acuerdo y un protocolo para obtener acuerdos de nivel de servicio. WS-
Agreement ha tenido mucha aceptación, y es por eso que para este proyecto, se
ha decidido tener en cuenta las especicaciones que propone este protocolo de
servicios web. Su diseño ha estado fuertemente inuenciado por WSLA.
WSLA (Web Service Level Agreement) fue propuesto por Ludwig et al. [11],
y permite a clientes y proveedores describir objetivos de nivel de servicio y se
centra fundamentalmente en la descripción y monitorización de acuerdos de
calidad.
La gura 2 muestra el mapa conceptual para describir ofertas de acuerdo
en WS-Agreement, tomado como referencia para un modelo de acuerdos básico.
En esta recomendación, una oferta de acuerdo tiene dos partes claramente difer-
enciadas: el contexto y los términos. A su vez, los términos pueden distinguirse
entre los que describen los servicios objeto del acuerdo (términos de servicio)
y los que describen las obligaciones respecto a dichos servicios (términos de la
garantía). La gura 3 muestra un ejemplo de dos ofertas de acuerdo.
La gura 4 muestra el acuerdo que nalmente podría establecerse tras seguir
el proceso de negociación correspondiente. En WS-Agreement, los acuerdos
siguen un esquema similar a las ofertas de acuerdo .
5 En este caso, tanto el
acuerdo como las ofertas de acuerdo son bilaterales, es decir, recogen obliga-
ciones de ambas partes. Hay que decir que también es habitual en numerosas
propuestas que las ofertas de acuerdo por parte de los clientes sólo requieran
obligaciones a los proveedores, mientras que las ofertas de acuerdo por parte de
los proveedores sólo garanticen obligaciones a los clientes. Éstas se denominan
unilaterales.
Hay que añadir que, en contextos diferentes a WS-Agreement, a las ofertas
de acuerdo propuestas por los clientes también se les conoce como demandas,
mientras que a las ofertas de acuerdo propuestas por los proveedores también
se les conoce simplemente como ofertas.
Una vez establecidas todas las cláusulas del contrato, entra en juego el plan-
icador de recursos, empleando los algoritmos ecientes de optimización que se
presentan en este proyecto.
5 Nótese que estos ejemplos no se muestran con la notación XML de WS-Agreement, sino
que se utiliza una sintaxis concreta más fácil de entender para ilustrar cómo utilizar esta
recomendación de una forma clara y concisa.
25
ĐƵĞƌĚŽͬKĨĞƌƚĂĚĞ
ĂĐƵĞƌĚŽ
ĐŽŶƐƚŝƚƵŝĚŽƉŽƌ͙ ƉƵĞĚĞƐĞƌ
dĠƌŵŝŶŽĚĞ
'ĂƌĂŶƚşĂ
ͲůŝĞŶƚĞ
ͲWƌŽǀĞĞĚŽƌ ŚĂĐĞƌĞĨĞƌĞŶĐŝĂĂ͙ dĠƌŵŝŶŽĚĞ
Ͳ&ĞĐŚĂĚĞĞdžƉŝƌĂĐŝſŶ ^ĞƌǀŝĐŝŽ
ͲKƚƌĂŝŶĨŽƌŵĂĐŝſŶĚĞŝŶƚĞƌĠƐ ĐŽŶƐƚŝƚƵŝĚŽƉŽƌ͙
ŚĂĐĞƌĞĨĞƌĞŶĐŝĂĂ͙ WĂƌƚĞ
KďůŝŐĂĚĂ ƉƵĞĚĞƐĞƌ
ůĐĂŶĐĞ
sĂůŽƌĞƐĚĞ
EĞŐŽĐŝŽ ĞƐĐƌŝƉĐŝſŶ
ĚĞ^ĞƌǀŝĐŝŽ
ĐŽŶƐƚŝƚƵŝĚŽƉŽƌ͙
sŝŐĞŶĐŝĂ
Ͳ/ŵƉŽƌƚĂŶĐŝĂƌĞůĂƚŝǀĂ ZĞĨĞƌĞŶĐŝĂ
ͲWĞŶĂůŝnjĂĐŝŽŶĞƐ KďũĞƚŝǀŽĚĞEŝǀĞů ĚĞ^ĞƌǀŝĐŝŽ
Ͳ'ƌĂƚŝĨŝĐĂĐŝŽŶĞƐ ĚĞ^ĞƌǀŝĐŝŽ
ͲƌŝƚĞƌŝŽƐĚĞƉƌĞĨĞƌĞŶĐŝĂ
ĐŽŶƐƚŝƚƵŝĚŽƉŽƌ͙
WƌŽƉŝĞĚĂĚĞƐ
ĚĞ^ĞƌǀŝĐŝŽ
ͲsĂůŝĚĞnjƚĞŵƉŽƌĂů ŚĂĐĞƌĞĨĞƌĞŶĐŝĂĂ͙
ͲKƚƌŽƐĨĂĐƚŽƌĞƐĞdžƚĞƌŶŽƐ ĐŽŶƐƚŝƚƵŝĚŽƉŽƌ͙
ͲƚƌŝďƵƚŽƐĚĞĐĂůŝĚĂĚ
ͲŽŶĚŝĐŝŽŶĞƐƐŽďƌĞ
ƉƌŽƉŝĞĚĂĚĞƐĚĞƐĞƌǀŝĐŝŽ ĚĞĨŝŶŝĚĂƐƐĞŐƷŶ͙
26
Figura 3: Ejemplos de posibles ofertas de acuerdo.
27
Figura 4: Ejemplo de un acuerdo de servicio.
28
Contexto El contexto contiene información general de la oferta de acuerdo,
por ejemplo, la identicación de las partes y la fecha de expiración. En el
Universitat Politècnica
ejemplo de la gura 3, las partes del acuerdo son la
de Catalunya como cliente y la empresa CasaLibro dedicada a la venta de
libros, como proveedor. El acuerdo expira el 31/12/2013.
Términos de servicio Describen los servicios que son objeto de las ofertas de
acuerdo. Por regla general, un proveedor puede hacer referencia a los interfaces
WSDL de los servicios web que oferta. En el ejemplo anterior, el proveedor
incluye las referencias a sendos servicios, comprarLibro() y consultarLibro(),
etiquetados con S1 y S2, respectivamente. Por otro lado, un cliente puede
describir los servicios en los que está interesado mediante, por ejemplo, palabras
claves que indican una cierta funcionalidad que se requiere. En el ejemplo,
se utilizan palabras claves como librería, compra de libros y consulta de
libros.
También se distinguen las propiedades del servicio, donde pueden describirse,
por ejemplo, los atributos de calidad que serán utilizados para denir los obje-
tivos de nivel de servicio. En nuestro ejemplo, se declaran los siguientes atributos
de calidad: MTTF, MTTR, RT, CCODE y ETIME.
De entre todos los aspectos relacionados con los términos de servicio, cabe
destacar sobre los atributos de calidad, que S. Ran [13] sostiene la ausencia de
consenso en la terminología usualmente empleada, a pesar de los estándares.
Esta es una constante que se repite en muchos de los aspectos relativos a los
acuerdos SLA. Existen diferentes maneras de describir y organizar los atribu-
tos de calidad. Es posible elaborar un modelo de calidad para agrupar atrib-
utos relacionados, deniendo una determinada jerarquía. Estos modelos de
calidad también se conocen como catálogos. En la norma ISO8402 Quality
Management and Quality Assurance, Vocabulary, incorporado posteriormente
al ISO-9000, la calidad de servicio (QoS, Quality of Service ) se describe como la
totalidad de características de un producto o servicio que son relevantes para
su capacidad de satisfacer las necesidades ya establecidas o implícitas . Por lo
tanto, y tal y como se arma en [14], puede decirse que un atributo de cali-
dad es cualquier característica medible de un servicio que puede inuir sobre la
percepción que pueda tenerse del mismo.
29
• Objetivo de Nivel de Servicio (SLO, Service Level Objective ): Describe
las obligaciones respecto a los términos de servicio, que suelen expresarse
como condiciones sobre las propiedades de servicio que tengan asociadas .
6
Puede distinguirse entre objetivos garantizados por la parte que establece
7
la oferta de acuerdo y objetivos requeridos a la parte contraria . Ejemplos
de SLO son el tiempo de tarea (tD ), el número de CPUs (NCP U ) requeridas
para satisfacer dicha tarea (valor suministrado por el consumidor) o lo que
en las especicaciones de WS-Agreement se les llama boundary times (tS ,
tF ). En este proyecto, a estos términos se les ha llamado variables, y más
adelante se profundizará sobre las mismas.
30
• En la oferta del proveedor, los términos de la garantía establecen que:
Todos ellos tienen validez hasta la fecha de expiración del acuerdo, que en
este caso coincide con la fecha de expiración de la demanda, es decir, 31
de diciembre de 2013.
31
que basan sus investigaciones en reducir el coste computacional reduciendo el
tiempo de los runtimes y de las tareas por hora (véase [18]).
Son muchos los artículos y análisis que abordan el ahorro en el coste desde
un punto de vista económico. Por ejemplo, V. Yarmolenko y R. Sakellariou en
[9] y [16] denen nuevas variables de recompensas y compensaciones económi-
cas empleando el protocolo SLA. Un análisis similar hacen L. Wu et al. en
[28], donde se diseña un algoritmo basado en una presupuestación económica
estimada. Por su parte, A. Andrzejak et al. en [21] también hacen uso de la
tecnología SLA para relacionar diferentes tipos de tráco con los sistemas de
taricación y de ese modo reducir el coste económico del sistema.
La otra gran línea de trabajo para reducir el coste del sistema se centra
en reducir el coste energético del hardware con técnicas de refrigeración (cool-
ing ), como por ejemplo la propuesta de Google en su whitepaper [26]. Otra
herramienta muy empleada para el ahorro en el coste es el cálculo de índices de
efectividad como el PUE (Power Usage Eectiveness ). En esa línea, X. Wang et
al. en [27] centran sus investigaciones en desarrollar un algoritmo de eciencia
energética basándose en esta variable y el uso de un framework de Google muy
extendido llamado MapReduce.
Teniendo en cuenta la naturaleza de los sistemas de Cloud Computing, ex-
isten varias técnicas que ayudan a reducir el coste del sistema, además de las
ya mencionadas. Como ya se ha comentado en el apartado anterior, la virtual-
ización es un concepto clave a la hora de estudiar y analizar cualquier aspecto
relacionado con el Cloud Computing. En ese sentido, y dentro de todo lo que es
la reducción de costes, resulta casi obligado hablar de la migración de máquinas.
En este tipo de entornos la migración es un aspecto fundamental, ya que per-
mite liberar de carga a ciertos recursos y aumentar la exibilidad del sistema.
Por eso, los algoritmos diseñados para reducir los costes energéticos suelen tener
en cuenta el estado los servidores o recursos. Si un servidor se encuentra satu-
rado o con un nivel de carga elevado, se le considera en cuarentena o aislado, y
debe realizarse una migración hacia otra máquina virtual. A esa migración se le
conoce como balanceo de carga, y es una de las técnicas que se han empleado en
este proyecto. Si por el contrario se desea reducir el coste energético evitando
la expansión de recursos y utilizar sólo un cierto recurso o MV, se suele emplear
una técnica llamada consolidación, y también es una de los mecanismos de re-
ducción energética empleados en este proyecto. M. Mishra et al. trabajan en
esta dirección en [29]. El terccer mecanismo que se ha utilizado en este proyecto
para tratar de reducir el coste energético en sistemas de Cloud Computing es el
que se ha llamado Time Shifting (o Time Overlapping ), inspirado en el trabajo
de V.Aggarwal et al. en [30]. La técnica de Time Shifting o desplazamiento
temporal se emplea fundamentalmente en servicios a tiempo real.
Existe un consorcio internacional llamado The Green Grid cuyo objetivo es
el de aumentar la eciencia energética en los Data Centers. Trabaja y propone
estándares en relación a todo lo que es el ahorro energético en las tecnologías
de la información. Abarca tanto temas de potencia y energía como de polución
y contaminación. Para mayor información consultar la web en [31].
32
2.4 Descripción del entorno de trabajo
Con todos los conceptos teóricos comentados anteriormente, es momento de ex-
poner y describir el sistema que se ha implementado en este proyecto. Para
una mejor comprensión del entorno de trabajo, esta exposición se divide en
dos partes: descripción del sistema y descripción de las variables del sistema.
En la primera parte se ofrece una visión amplia del entorno de trabajo imple-
mentado, explicando detalladamente cada módulo del esquema. Por otro lado,
en la segunda parte se describen las diferentes variables y parámetros que han
intervenido, de uno u otro modo, en la realización del proyecto.
Best Eort (o tráco tipo II). Es el tipo de tráco con menor nivel de
calidad de servicio, ya que no se puede garantizar una mínima QoS.
33
Figura 5: Esquema del comportamiento general del sistema.
34
repeticiones con un solo bloque. Esta n depende de cada prueba, y varía
entre 20 y 100 repeticiones (en el caso de este proyecto). Con esto se
consigue promediar los valores obtenidos en cada prueba, de manera que
se disminuye el error debido a la aleatoriedad inherente en muchas de las
variables utilizadas en las simulaciones.
tdemora 1
P rior = + (1)
1000 c4 + 0.5·tLAX + 0.02·tD ·NCP U
Una vez calculado este valor de prioridad para cada petición, se ordenan
de menor a mayor para su posterior tratamiento. Se ha decidido realizar
esta ordenación previa al tratamiento de las peticiones puesto que es una
buena manera de dotar de ciertos privilegios de preferencia a los tipos de
tráco con un mayor nivel de calidad de servicio.
• Tráco garantizado. Una vez todas las peticiones del bloque han sido
ordenadas, se pasa a trabajar petición a petición. Para cada una de ellas
se comprueba si se ha excedido la cantidad de tráco garantizado para
cada tipo de tráco. Esta cantidad de tráco depende exclusivamente
del tipo de tráco, de manera que a mayor calidad de servicio, mayor
tráco garantizado. En el entorno de trabajo de este proyecto, que un
tráco esté garantizado signica que no se ve afectado por el sistema de
35
Tabla 1: Tráco garantizado para cada tipo de tráco
Tipo I 20%
Tipo II 80%
Tipo III 40%
Tipo IV 60%
Filtro 2 : este ltro descarta las peticiones que soliciten más del 80%
de los recursos totales del sistema. Solo se aplica para las peticiones
correspondientes a los servicios relacionados con los tipos de tráco
I, II y IV.
36
Filtro 4 : este último ltro se le aplica a todas las peticiones entrantes,
y descarta las que necesiten un tiempo de tarea superior al 80% del
tiempo de tarea máximo soportado por el sistema. Este valor máximo
del tiempo de tarea permitido se ha tomado del obtenido en [19].
• Tratar petición. Este paso corresponde a las tareas del algoritmo (el que
sea). Por lo tanto, una vez llegados a este punto, la petición es tratada. En
el contexto de este proyecto en término tratar consiste en la asignación
de los recursos del sistema en función de una serie de parámetros. Cabe
resaltar que una petición puede ser tratada y descartada por no cumplir
unos requisitos mínimos. En tal caso, los recursos que se le asignarían
quedarían libres, y la petición pasaría a formar parte de la estadística de
estudio para el análisis de las prestaciones de los propios algoritmos imple-
mentados (costes, inuencia del tipo de tráco, porcentajes de peticiones
aceptadas/perdidas,...).
Una vez analizadas todas las peticiones del bloque, se pasaría a analizar el
siguiente bloque de peticiones.
Por razones de simplicidad, para la realización de este proyecto se han tenido
en cuenta las siguientes consideraciones:
37
• Siguiendo una aproximación similar a la expuesta en [18], se asume que
todos los servidores son iguales a nivel de hardware y computación. Todos
y cada uno de los servidores tienen las mismas características internas
y externas: capacidad de memoria, frecuencia del procesador, sistema
operativo,... Si hubiera distinción entre los servidores, podrían optimizarse
los algoritmos propuestos.
• Tiempo nal (tF ): este valor, al igual que el tiempo de inicio, también
se considera un tiempo límite. Corresponde al tiempo a partir del cual
se considera que la petición ha sido completamente tratada y libera el
recurso. Como ya se ha comentado, tanto el tiempo de inicio como el
tiempo nal son tiempos límite, por lo que se emplean para asegurarse
que no se solapan los tiempos de tarea de una petición y otra dentro de
un mismo servidor.
38
resaltar, que para cumplir la premisa que se exige en [19], se ha compro-
bado que efectivamente se verica que para cada petición entrante:
tD
= 0.1
tF − tS
• Laxitud (tLAX ): es una variable que indica cuan laxa es una petición.
Dicho de otro modo, es el tiempo que transcurre desde que acaba el tiempo
de tarea hasta el tiempo nal. Este valor es especialmente útil para mecan-
ismos de solapamiento temporal, puesto que indica el grado de exibilidad
o laxitud que permite la petición.
39
que el nivel de prioridad sólo dependería del tipo de servicio solicitado. Teniendo
en cuenta esto y el hecho de que puede existir un cierto desvío a la hora de
generar el valor de las variables en la simulación (errores de código, demasiados
grados de libertad a la hora de denir las variables, errores por suposiciones poco
exibles,... y todos aquellos errores derivados de la naturaleza de este proyecto),
todas las armaciones y conclusiones comentadas sólo pueden vericarse dentro
del entorno creado en este proyecto. Fuera del mismo, no se puede asegurar que
las armaciones se ajusten a los supuestos teóricos.
Es importante remarcar que para la realización de este proyecto, no se han
tenido en cuenta las demoras propias del sistema, ya sean de origen interno
(como por ejemplo los retardos I/O) como externo (latencias de la red, por ejem-
plo). También cabe resaltar que no se han tenido en cuenta factores económicos
como el precio, recompensas o presupuestos, ya que en este proyecto no se busca
el ahorro económico, ni índices como el PUE, puesto que las variables que in-
tervienen en dicho índice no se aplican en la planicación y gestión de recursos
como tal.
Existen, no obstante, una serie de parámetros que también son muy rele-
vantes a la hora de entender los resultados obtenidos en este proyecto. Estos
parámetros son los que permiten realizar las diferentes pruebas llevadas a cabo
en el proyecto variando su valor y ajustándolo a entornos lo más reales posible,
pudiendo analizar así la repercusión tanto de los propios parámetros como de
las variables anteriormente descritas. Gracias a la posibilidad de cambiar el
valor de estos parámetros, puede observarse el comportamiento de los algorit-
mos en diferentes situaciones y ante diferentes eventos que puedan surgir. Los
parámetros que permiten modelar los diferentes sistemas son los siguientes:
40
Tabla 2: Relación entre variables y coecientes
Variable Coeciente
c1 c2 c3 c4 c5 c6
Perl tráco tipo I 1 4 1 3 0.6 4
Perl tráco tipo II 1 1 4 1 0.8 1
Perl tráco tipo III 2.5 2 3 2 0.9 2
Perl tráco tipo IV 1 3 2 4 0.4 3
41
sos asignados para cada uno de los cuatro servicio diferentes del sistema.
Para mayor simplicidad se ha supuesto que todos los servicios disponen
del mismo número de recursos para asignar. Evidentemente, cuanto más
alto sea este parámetro, mayor será la capacidad del sistema para dar
servicio a todas las peticiones entrantes. Es importante comentar que es
posible que en una petición se soliciten un número superior de recursos
que el máximo del sistema. Ello no supone ningún problema en el entorno
implementado en este proyecto. Al igual que ocurría con el parámetro
de la disponibilidad, si un sistema posee un mayor número de recursos
disponibles, podrá dar servicio a un mayor número de peticiones, pero a
costa de coste superior (a priori, ya que en el capítulo 4 se demostrará que
el algoritmo híbrido 3 dispone de mecanismos para reducir este gasto que
supone el aumento del número de recursos).
42
Este valor indica la cantidad de bloques en los que se divide los servicios
para realizar la consolidación. Evidentemente este valor se aplica sobre
el número total de recursos disponibles para cada servicio, es decir, si
se disponen de 40 recursos para un determinado servicio, y se asigna un
número de bloques para la consolidación de 4, esto supone que se dividen
todos los recursos del servicio entre 4, por lo que cada bloque consta
de 10 recursos. En cambio, si el número de bloques es 10, cada bloque
dispondrá de 4 recursos. En el capítulo 3 se detallará este mecanismo
de consolidación, y se relacionará con el resto de aspectos del algoritmo
híbrido 3.
Para poder tener toda la información necesaria para comprender los algoritmos
que se proponen en el presente documento, es necesario relacionar las variables y
parámetros descritos con el coste. De este modo, puede abordarse mucho mejor
la problemática y los objetivos de este proyecto. Para ello, se han denido para
cada servidor, dos estados de funcionamiento: estado ON y estado OFF.
Con el n de relacionar los estados y modos del servidor con las variables co-
mentadas, a continuación se muestran la gura 6a y la gura 6b que permiten
entender mejor los conceptos anteriormente descritos. El tiempo sobrante que
aparece en la gura 6b corresponde con en cuestión.
Con toda esta información, es importante resaltar que tal y como se ha
implementado tanto el sistema como los algoritmos de planicación y asignación
de recursos con la herramienta de Matlab, resulta sencillo incorporar nuevas
restricciones, ltros, módulos, métodos, tipos de tráco, parámetros o variables.
9 Para todo el tema de costes se ha tomado como referencia la familia de servidores que
emplea Amazon en el servicio Cloud que ofrece ([22], [23]).
43
(a) Esquema temporal de una petición.
Figura 6: Relación entre los tiempos de petición y los posibles modos del servi-
dor.
44
El código se ha implementado de este modo pensando en los posibles trabajos
futuros en torno a la problemática en la que se centra este proyecto.
45
3 Algoritmos de planicación
Resulta evidente que para poder diseñar algún algoritmo que pueda reducir
el coste del sistema, es necesario pasar primero por una serie de pasos. A lo
largo de cada una de esos pasos o fases se han ido implementando una serie de
métodos cada vez más complejos, para llegar al diseño nal de los algoritmos
que propone este documento. En este capítulo se detalla la evolución de los
algoritmos que se han empleado en el proyecto.
Antes de detallar cada uno de los métodos implementados en este proyecto,
es obligado recordar que todos y cada uno de los métodos tienen dos fases:
estimación y asignación. En la primera fase se realiza una estimación de la
planicación de los recursos del sistema. Los procedimientos que se describen
en este capítulo corresponden únicamente a esta fase de estimación. Una vez
se ha realizado la estimación, se produce un proceso de asignación, en el que
se asigna el recurso resultante en la estimación o no, dependiendo de si cumple
o no alguno de los dos requisitos básicos implementados en este proyecto. El
primero de estos requisitos está relacionado con la disponibilidad del servicio
en cuestión. Concretamente, si la asignación de un recurso en concreto a una
petición en particular provoca que el servicio exceda de la disponibilidad del
mismo, la petición será descartada. La segunda restricción que debe cumplir la
asignación de un recurso a una petición entrante es que no debe superarse la
demora máxima solicitada por el usuario. Por lo tanto, si el hecho de que un
determinado servidor dé servicio a una determinada petición supone incumplir
alguno de estos dos requisitos, la petición queda automáticamente descartada.
Método elemental I
Este primer método es el más sencillo de todos. Básicamente se trata de una
asignación directa de manera secuencial de los recursos del sistema. Una vez
que las peticiones han sido ordenadas según su valor de prioridad, se le asigna a
cada petición tantos servidores como CPUs hayan sido solicitados por el usuario.
En este método no se tienen en cuenta ningún criterio temporal ni restricción
alguna. Es decir, no se tiene en cuenta la disponibilidad del servicio en cuestión,
ni la carga de un servicio o un servidor en concreto. Además la asignación se
46
realiza independientemente de los valores temporales de la petición (tiempo de
inicio, tiempo nal y tiempo de tarea). Otra característica importante de este
método es que la tarea sólo la realiza un servidor, y por su parte, el resto de
servidores asignados quedan reservados. Por lo tanto, el primer servidor que se
le haya asignado a la petición estará tD segundos en modo full y el resto del
tiempo en modo idle, mientras que el resto de servidores asignados, al estar
reservados para ofrecer servicio a dicha petición, estarán en modo idle los tTOT
segundos.
A la hora de calcular el coste que supone cada petición empleando este
método, es necesario calcular el tiempo total en el que los servidores que están
involucrados están en cada modo. A partir de la explicación anterior, puede
calcularse los tiempos en modo full y modo idle totales para cada petición, por
lo que siguiendo la naturaleza del propio método, se obtiene que:
TF U LL = tD
Método elemental II
El método elemental II es una evolución del método elemental I. El funcionamiento
es similar al primero, pero en este método se produce una distribución del tiempo
de tarea entre varios CPUs. Es decir, este algoritmo asigna tantos CPUs como
ha solicitado el usuario, también secuencialmente, sin atender a restricciones ni
criterios de optimización ni requisitos del usuario. Por lo tanto, la única difer-
encia entre este método y el anterior es que en este caso, el tiempo de tarea se
reparte entre todos los CPUs asignados a la petición en cuestión. Como con-
secuencia de ello, el servidor estará en modo full sólo una enésima parte del
tiempo de tarea total (tD/NCP U , dónde NCP U es el número de nodos asignados
a la petición), y estará en modo idle el resto del tiempo. Es importante re-
saltar que el resto del tiempo que se había destinado al tiempo de tarea ahora
forma parte del tiempo de laxitud. Por consiguiente, el nuevo tiempo de laxitud
h i
NCP U −1
es
NCP U ·tD + tLAX . Este hecho será de especial relevancia en el método
básico I y los dos métodos híbridos propuestos en este proyecto. Debido a ello,
y para mayor comodidad, el procedimiento de distribución del tiempo de tarea
entre los CPUs asignados se ha empleado en todos los métodos sucesivos.
En este caso, los tiempos en modo idle y full para cada petición tratada
47
son diferentes a los del primer método elemental y quedan denidos por las
siguientes ecuaciones (también se sigue la idea general del método):
tD
TF U LL = ·NCP U = tD
NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U
·NCP U
h i ó
tD
TIDLE = tT OT − NCP U ·NCP U = tT OT ·NCP U − tD
tD
TF U LL = ·NCP U = tD
NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U
·NCP U
h i ó
tD
TIDLE = tT OT − NCP U ·NCP U = tT OT ·NCP U − tD
48
Tal y como ocurría en el resto de métodos elementales, en este método
también aparece la limitación comentada anteriormente, o sea, si encuentra un
nodo en el que no se pueda insertar la petición, no pasa al siguiente nodo, sino
que descarta la petición directamente. De nuevo, debido a las características
propias del método, no se consigue liberar ningún recurso con este algoritmo. De
hecho, la losofía de este método va radicalmente en contra de la minimización
de recursos empleados, ya que intenta repartir lo máximo posible la carga entre
todos los servidores.
No obstante, según las pruebas realizadas para los tres métodos elementales,
y como cabía esperar, este último método es el que ofrece mejores prestaciones
sólo en cuanto a ratio de peticiones aceptadas (ya que el coste aumenta debido
precisamente a este ratio mejorado de peticiones aceptadas). Es por eso por lo
que el criterio de optimización temporal que se utiliza en este algoritmo se ha
empleado en los dos métodos híbridos propuestos.
49
Figura 7: Proceso de solapamiento.
valor que indica el máximo tiempo que una petición entrante podrá aprovechar.
Ese tiempo aprovechable se le ha llamado ajuste, y dependerá de la laxitud de
la última petición que haya tratado dicho servidor. No obstante, una petición
entrante sólo podrá aprovechar parte de ese tiempo de ajuste. Esa parte coincide
con la diferencia entre el tiempo límite de inicio indicado por el usuario y el inicio
del tiempo de tarea de esta petición entrante. La gura 7 muestra grácamente
este procedimiento de ajuste mediante solapamiento.
En la gura 7 puede verse también que el solapamiento se produce no desde
el nal del tiempo de tarea de la petición anterior, sino a partir del inicio del
tiempo de tarea de la nueva petición, con lo que, en el peor de los casos no hay
apenas espacio temporal entre el tiempo de tarea de una petición y el de otro.
No obstante, gracias a las pruebas realizadas en este proyecto, se ha comprobado
que la mayoría de los casos la laxitud es mayor que la diferencia entre el tiempo
de inicio y el principio del tiempo de tarea de la nueva petición. Por motivos
de simplicidad en este proyecto se asume que siempre que se asigne un servidor
en el que se pueda realizar este solapamiento temporal, se hará, sin tener en
cuenta las implicaciones y complicaciones que ello supone. Si se tuvieran en
consideración tales complicaciones, se dejaría de ahorrar entre un 25% y un
30%, tal y como se reeja en el capítulo 4 de la presente memoria.
Cabe resaltar que en este método cobra especial importancia la distribución
del tiempo de tarea entre todos los CPUs solicitados, ya que la consecuencia
directa de este procedimiento es un aumento considerable la laxitud de la peti-
ción, lo que supone aumentar el posible tiempo de ajuste disponible en cada
servidor. Con esto se consigue además, aumentar la cantidad de peticiones a las
que un servidor puede dar servicio. En vista de los resultados obtenidos en las
simulaciones realizadas, se ha decidido aplicar este método de ajuste a los dos
algoritmos híbridos propuestos en este proyecto.
En este caso los tiempos en modo idle y full para una determinada petición
son diferentes con respecto a los obtenidos en los métodos elementales. Esto es
debido a que al ajustarse temporalmente las peticiones entrantes, se aprovecha
50
mejor el tiempo. Además, en este método hay que considerar dos posibles casos,
en función de si se realiza ajuste o no a la petición en cuestión. En el caso de que
no se produjera ajuste, los tiempos quedarían denidos de una forma similar a
la de los métodos elementales, es decir:
tD
TF U LL,N oAjuste = ·NN oAjuste
NCP U
h i
CP U −1
TIDLE,N oAjuste = tS + tLAX + tD · NNCP U
·NN oAjuste
h i ó
tD NN oAjuste
TIDLE,N oAjuste = tT OT − NCP U ·NN oAjuste = tT OT ·NN oAjuste − tD · NCP U
(2)
tD
TF U LL,Ajuste = ·NAjuste
NCP U
h i
CP U −1
TIDLE,Ajuste = tLAX + tD · NNCP U
·NAjuste
ó (3)
51
tD tD
TF U LL = ·NN oAjuste + ·NAjuste = tD
NCP U NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U i
·NN oAjuste + (4)
h
NCP U −1
+ tLAX + tD · NCP U ·NAjuste =
h i
CP U −1
= tLAX + tD · NNCP U
·NCP U + tS ·NAjuste =
= tT OT ·NCP U − (tS ·NAjuste + 2tD )
Es interesante remarcar que, al igual que ocurría en el caso de los métodos
elementales, el tiempo en modo full coincide con el tiempo de tarea de la petición.
Hecho que era de esperar.
Otro aspecto a tener en cuenta es el número de ajustes que pueden producirse
en un único servidor mediante el método básico de Time Shifting. Para analizar
este aspecto es necesario primero suponer que a una petición determinada se
le asigna un único CPU para realizar toda la tarea, independientemente de los
CPUs que se hayan solicitado. Éste podría ser un valor para medir si un sólo
servidor puede dotar de servicio a una petición en concreto (por ejemplo, por
si más adelante se desease incorporar métodos de consolidación para liberar
recursos). Siempre que se cumpla que:
NCP U − 1
tS < tLAX + tD ·
NCP U
es decir, que pueda ajustarse, puede armarse a partir de las ecuanciones
anteriores que:
T V D−tS
k< tD +tLAX
ó
k < TtTVOTD−tS
−tS
TM AX = tS + k· (tD + tLAX )
donde k es el número de divisiones del tiempo de tarea que se puede hacer
empleando un único servidor. Considerando que el servidor nunca antes había
sido asignado como recurso, puede decirse que (k − 1) es el número máximo de
ajustes que permite un determinado servidor. Por otro lado, el tiempo total,
TM AX , es el tiempo total máximo que el servidor está activo con la petición en
cuestión.
En cuanto a las prestaciones ofrecidas en el estudio realizado en este proyecto,
por parte de este método, es interesante resaltar que presenta un tiempo de
relleno elevado debido a que ordena los recursos priorizando sólo el ajuste, lo que
hace que el reparto de servidores no sea el más equitativo posible, aumentando
así el tiempo de relleno.
En este algoritmo, al priorizar el ajuste se reparte la carga entre todos los
servidores, con lo que tampoco se consigue liberar recursos. Por consiguiente,
52
en este método el principal ahorro en el coste del sistema se consigue con el
solapamiento temporal.
tD
TF U LL = ·NCP U = tD
NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U
·NCP U
h i ó
tD
TIDLE = tT OT − NCP U ·NCP U = tT OT ·NCP U − tD
53
no tenerla en cuenta. Por ello, en el algoritmo híbrido III se ha implementado
un mecanismo de consolidación que permite aprovechar el gran punto a favor
de la consolidación, pero sin las limitaciones del método básico II.
54
los daños producidos debidos a este inconveniente, ya que se cargan antes los
servicios con un menor nivel de calidad de servicio.
Como cabía esperar, el tiempo en modo full y en modo idle que implica una
petición en concreto si se emplea este método básico coinciden con los tiem-
pos de los métodos elementales II y III, y con el método básico II comentados
anteriormente, es decir:
tD
TF U LL = ·NCP U = tD
NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U
·NCP U
h i ó
tD
TIDLE = tT OT − NCP U ·NCP U = tT OT ·NCP U − tD
55
1. Dividir el tiempo de tarea entre el número de recursos solicitados por el
usuario en la petición.
2. Calcular el recurso con una menor carga de trabajo acumulada del servicio
en cuestión. Para ello se realiza un búsqueda uno a uno del servidor con
menor carga de trabajo, dentro de la planicación realizada hasta ese
momento.
3. Una vez encontrado el recurso con una menor carga de trabajo, se guarda
la información de cantidad de carga (tiempo total de servicio de ese servi-
dor). A ese servidor se le considera como la opción 1. Llegados a este
punto es necesario resaltar la importancia de estos valores del servidor.
Este método híbrido se caracteriza por la posibilidad de escoger entre dos
opciones de asignación de recursos, en función de una serie de factores.
Este servidor con una menor carga de trabajo acumulada será una de las
dos opciones a analizar a la hora de asignar el recurso a la petición.
5. En este punto del algoritmo ya se tienen las dos posibles opciones de selec-
ción para asignar el recurso. Cabe resaltar que se produce un balanceo del
tiempo de trabajo entre tantos servidores como CPU's solicite el usuario,
por lo que se realizarán tantas asignaciones de recursos como CPU's so-
licitados. El criterio de selección de asignación de recurso es el siguiente:
56
Con este algoritmo se mejora el nivel de saturación que ofrecían los otros méto-
dos, ya que prioriza la selección del recurso reduciendo una posible congestión de
cada servicio. Además, el hecho de ser un algoritmo multiopción, ofrece un plus
de calidad, puesto que se asigna siempre el mejor servidor de los posibles, dentro
la ristra de servidores destinados al tipo de tráco de la petición en cuestión.
Con el n de ayudar a comprender mejor el funcionamiento de este algoritmo,
en la gura 8 se muestra un diagrama de ujo con los procesos que se llevan a
cabo y las transiciones entre los mismos.
Los tiempos en modo full e idle de una determina petición coinciden con los
expuestos en el método básico I, ya que se realiza un proceso de ajuste que limita
los tiempos de los servidores, con todo lo que ello conlleva. También cumple la
expresión del número máximo de ajuste que un único servidor puede asumir,
para una sola petición entrante. Por lo tanto, para este algoritmo híbrido:
tD tD
TF U LL = ·NN oAjuste + ·NAjuste = tD
NCP U NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U i
·NN oAjuste +
h
CP U −1
+ tLAX + tD · NN ·NAjuste =
h iCP U
NCP U −1
= tLAX + tD · NCP U ·NCP U + tS ·NAjuste =
= tT OT ·NCP U − (tS ·NAjuste + 2tD )
Método híbrido II: Minimum Fit Makespan with Load Balance (MiFMLB)
Dependiendo del entorno, del sistema, del contexto o del tipo de tráco, entre
otros, es posible que se desee priorizar otros aspectos (como minimizar las de-
moras), a costa de una saturación más rápida del sistema. Es por eso que se ha
diseñado otro algoritmo de planicación y gestión de recursos. Con este nuevo
algoritmo se pretende minimizar el número de peticiones perdidas por exceder
el tiempo de demora y por sobrepasar la disponibilidad del sistema, a costa de
cargar de trabajo ciertos servicios en favor de otros. Esto se realiza mediante
57
ZĞĂůŝnjĂƌĞƐƚŝŵĂĐŝſŶʹůŐŽƌŝƚŵŽ,şďƌŝĚŽϭ
^ŝŐƵŝĞŶƚĞWh
ƐŽůŝĐŝƚĂĚŽ
͎dŽĚĂƐůĂƐ
^/
Wh ĄůĐƵůŽĚĞ
ƐŽůŝĐŝƚĂĚĂƐ͍ ŽƐƚĞƐ
ĐƚƵĂůŝnjĂƌ
EK ƐĞƌǀŝĚŽƌĞƐ
ĄůĐƵůŽĚĞůƐĞƌǀŝĚŽƌŵĞŶŽƐ
ĐŽŶŐĞƐƚŝŽŶĂĚŽĚĞůƐĞƌǀŝĐŝŽ
ĐŽƌƌĞƐƉŽŶĚŝĞŶƚĞ;KƉĐŝſŶϭͿ
͎džŝƐƚĞŶ
EK ƐŝŐŶĂƌƐĞƌǀŝĚŽƌ
ƐĞƌǀŝĚŽƌĞƐ
KƉĐŝſŶϭ
ĂũƵƐƚĂďůĞƐ͍
^/
ĄůĐƵůŽĚĞůƐĞƌǀŝĚŽƌƋƵĞ
ƉĞƌŵŝƚĂĂƉƌŽǀĞĐŚĂƌŵĞũŽƌĞů
ĂũƵƐƚĞ;KƉĐŝſŶϮͿ
EK
͎KƉĐŝſŶϭ
EK ƐŝŐŶĂƌƐĞƌǀŝĚŽƌ ƐŝŐŶĂƌƐĞƌǀŝĚŽƌ
ŵĞũŽƌƋƵĞ
KƉĐŝſŶϮ KƉĐŝſŶϭ
KƉĐŝſŶϮ͍
^/
͎ƐƚŝŵĂĐŝſ ĐƚƵĂůŝnjĂƌ
^/ WĞƚŝĐŝſŶ ^ĞƌǀŝĚŽƌĞƐ
ŶĐƵŵƉůĞ
ĚĞƐĐĂƌƚĂĚĂ LJŽƐƚĞƐ
ƌĞƋƵŝƐŝƚŽƐ͍
EK
58
un mecanismo de balanceo de carga combinado con un proceso de ajuste sim-
ilar al que se realiza en el algoritmo híbrido anterior. En el próximo capítulo,
donde se exponen los diferentes resultados obtenidos para cada algoritmo, a esta
combinación de mecanismos se le ha llamado tratamiento especial, puesto que
gracias a esta combinación, el método híbrido II presenta unas prestaciones muy
interesantes bajo determinadas circunstancias.
Para poder comprender mejor el funcionamiento de este algoritmo, a con-
tinuación se detallan los pasos que lleva a cabo el planicador empleando este
método.
2. Si este servidor puede ajustarse, se marca con un ag para indicarlo y que
más adelante se le pueda aplicar el tratamiento correspondiente.
59
menor nivel de QoS. De este modo, en el momento en el que se em-
pieza a tratar una petición se comprueba si el servicio solicitado está
disponible o si por el contrario está saturado. Si está saturado, se
estudian el resto de servicios en busca de uno que pueda ocuparse de
la parte de la tarea de la petición. El orden de análisis es el siguiente:
en primer lugar se analizan los servidores correspondientes al tráco
tipo II (Best Eort), después al tipo III (Alta Carga), luego al tipo I
(Business) y por último al tipo IV (Tiempo Real).
60
Tabla 4: Reparto de requisitos para cada tipo de tráco
Servicio full X X X X
Demora excedida X - - X
Longitud excesiva medio nulo bajo alto
2
Lmáxima = µtT OT (1 + 0.1) ·µNCP U (1 + 0.1) = µtT OT ·µNCP U · (1.1)
Con todo esto, se ha diseñado una tabla para denir un sistema de reparto
de requisitos en función del nivel de calidad de servicio propio de cada tipo
de tráco. La tabla 4 muestra con una 'X' los factores que se tienen en
cuenta a la hora de decidir si se realiza un balanceo de carga o no. En
la la de la tabla 4 correspondiente a la longitud excesiva, en lugar de
marcar los tipos de tráco que se ven afectados por este factor, se indica
el grado de rigurosidad con el que se analiza este requisito.
61
disponibilidad y demora máxima. Si los cumple, se asigna denitivamente
ese servidor a la petición, y si no los cumpliera, se pasaría al siguiente
servidor de la lista elaborada en el paso 1 y se avanzaría a los siguientes
pasos anteriormente descritos hasta encontrar un servidor correcto.
tD tD
TF U LL = ·NN oAjuste + ·NAjuste = tD
NCP U NCP U
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U
·NN oAjuste +
h i
CP U −1
+ tLAX + tD · NN ·NAjuste =
h iCP U
NCP U −1
= tLAX + tD · NCP U ·NCP U + tS ·NAjuste =
= tT OT ·NCP U − (tS ·NAjuste + 2tD )
62
Figura 9: Diagrama de ujo del algoritmo híbrido MiFMLB.
63
Este algoritmo cuenta con la principal ventaja del balanceo de carga, que es
la mejora en términos de saturación total, al repartir la carga entre los distintos
servidores del sistema. Evidentemente también acarrea el mayor inconveniente
asociado a este mecanismo de balanceo de carga, es decir, el sobrecargar el resto
de servicios. Tal y como se ha planteado en este proyecto, este algoritmo, y
en concreto el mecanismo de balanceo de carga implementado en él, favorece
la liberación de carga de trabajo de los servicios con un nivel de calidad de
servicio mayor, en detrimento de la aceleración de la saturación de los servicios
con menor nivel de QoS. Por lo tanto, en vista de lo comentado en este apartado,
a priori podría armarse que este algoritmo se ve afectado por el tipo de tráco
dominante en el sistema. Para corroborar esta armación se han realizado una
serie de pruebas y simulaciones que se detallan en el siguiente capítulo.
Al igual que ocurría con el método híbrido I, al no disponer de un mecanismo
de consolidación, no se consigue liberar recursos del sistema, por lo que la reduc-
ción en el coste se consigue, fundamentalmente con el ajuste, ya que, como ya se
ha comentado, con el balanceo de carga se consigue mejorar otras prestaciones
(QoS, tasa de peticiones aceptadas, optimización de servicios, aprovechamiento
del sistema,...).
64
manera que se intenta asignar, siempre que sea posible, los recursos correspon-
dientes al primer bloque. La asignación dentro del bloque no es ni secuencial ni
aleatoria, sino que se lleva a cabo una búsqueda inteligente de recursos posibles,
teniendo en cuenta que la principal premisa es la de minimizar el coste total
del sistema. Esta búsqueda inteligente es similar a la que se realizaba en el
algoritmo híbrido, puesto que siempre que se ajustará la petición entrante den-
tro del bloque, y, concretamente, se le asignará el recurso ajustable con mayor
carga de trabajo total acumulada (con el propósito de minimizar el número de
recursos totales). Por lo tanto, con este modo de funcionamiento, tanto si el
número de bloques es 1, como si es igual al número de recursos, se realizaría
una consolidación entre todos los recursos del sistema, tal y como ocurría en el
método elemental II.
Además, como bien se ha comentado anteriormente, en este algoritmo tam-
bién se ha incorporado un mecanismo de balanceo de carga que se produce en el
caso en el que la petición en cuestión no pueda ser tratada por ningún servidor
del servicio solicitado. Si eso ocurre, el proceso de selección de recurso vuelve a
no ser ni secuencial ni aleatorio, sino que se emplea la misma búsqueda ordenada
que se llevaba a cabo en el método híbrido II. Es decir, se comprueban todos
los servidores de cada servicio uno a uno hasta que se encuentra el adecuado,
siempre teniendo en cuenta el orden de búsqueda denido en el algoritmo ante-
rior. No obstante, en este algoritmo, no se le asigna a la petición el servidor con
menor carga de trabajo acumulado como sucedía en el método híbrido II, sino
que ahora se pretende asignar el recurso con mayor carga del nuevo servicio,
con la intención de liberar la mayor cantidad de recursos posibles. Tal y como
ocurría con el algoritmo híbrido II, este mecanismo proporciona ciertas venta-
jas, sobretodo a la hora de analizar las prestaciones relacionadas con la calidad
del servicio.
Siguiendo con la dinámica anterior, se ha elaborado un diagrama de ujo
que muestra el funcionamiento de este tercer algoritmo híbrido. En la gura
10 puede verse dicho diagrama, y cómo el proceso de balanceo de carga queda
perfectamente identicado.
A la hora de analizar el comportamiento temporal a nivel matemático, cabe
resaltar que los tiempos coinciden con los de los otros dos algoritmos híbridos,
es decir:
tD tD
TF U LL = ·NN oAjuste + ·NAjuste = tD
NCP U NCP U
65
Figura 10: Diagrama de ujo del algoritmo híbrido CoFiLB.
66
h i
CP U −1
TIDLE = tS + tLAX + tD · NN CP U i
·NN oAjuste +
h
NCP U −1
+ tLAX + tD · NCP U ·NAjuste =
h i
CP U −1
= tLAX + tD · NNCP U
·NCP U + tS ·NAjuste =
= tT OT ·NCP U − (tS ·NAjuste + 2tD )
67
4 Estudio y análisis de los resultados
Una vez denidos perfectamente todas las variables, parámetros y métodos con
los que se han trabajado en este proyecto, es el momento de analizar los re-
sultados obtenidos en el proyecto. La dinámica que se ha llevado a cabo en
las simulaciones es muy simple. Básicamente para cada prueba se han jado
todos los parámetros excepto uno, así se puede estudiar la repercusión de ese
parámetro sobre los algoritmos. La intención de esta forma de trabajo es de-
scubrir para qué valores los algoritmos suponen un menor coste en el sistema,
además de comprobar el resto de prestaciones (fundamentalmente porcentaje
de peticiones aceptadas y cantidad de recursos liberados del sistema). Una vez
jados los parámetros se presentarán una serie de grácas que mostrarán el
comportamiento de los algoritmos híbridos. En este proyecto sólo se muestran
los resultados de los algoritmos híbridos porque son los que se proponen en el
presente documento y los que presentan los resultados más interesantes.
La presentación de los resultados será la siguiente:
68
• El parámetro que varía en esta simulación es la disponibilidad del sistema
(o tal y como se ha denido en el capítulo 2, T V D). Para mayor simplici-
dad se ha supuesto que todos los servicios tienen la misma disponibilidad,
es decir, que están disponibles el mismo tiempo total. Por ejemplo, si se
analizan los resultados para una disponibilidad de 1500 segundos, todos
los servicios que ofrece el sistema implementado en este proyecto están
disponibles 1500 segundos.
69
Figura 11: Porcentaje de peticiones aceptadas en función de la disponibilidad
del servicio.
10 En este proyecto, para ajustarse a unas necesidades reales, se asume que un porcentaje de
peticiones aceptadas por debajo del 90% es inaceptable en un sistema con una arquitectura
orientada a servicio come es el de Cloud Compunig.
70
Figura 12: Coste total del sistema en función de la disponibilidad del servicio.
71
orden, es decir, primero se estabiliza el H3, luego el H2 y por último el H1. Se
estabilizan en este orden debido al uso de mecanismos de reducción de coste.
Por ejemplo, el algoritmo H1 sólo hace uso del mecanismo de ajuste, lo cual
hace que se estabilice en último lugar, y de una forma más lenta que el resto.
Por el contrario, el H3, al emplear ajustes, balanceos de carga y consolidación,
tiene un proceso de estabilización mucho más rápido y brusco. Este proceso
viene marcado por la estabilización que se produce en el porcentaje de peti-
ciones aceptadas, de manera que el punto de la gráca donde un algoritmo se
estabiliza en lo referente al porcentaje de peticiones aceptadas, también lo hace
en el coste.
En la gura 12 puede verse también que a partir de los 1150 segundos de
disponibilidad el H3 tiene el mismo coste mientras que el resto de algoritmos
aumentan su coste a medida que aumenta la disponibilidad. Este proceso de
estabilización supone que para disponibilidades medias el coste del algoritmo H3
se equilibre con respecto al ofrecido por H1, e incluso, para disponibilidades altas
el coste del H3 es menor que el de cualquier otro algoritmo de los propuestos en
este proyecto.
Estrictamente hablando (es decir, teniendo en cuenta únicamente el coste
total del sistema) el algoritmo H2 es el que ofrece un coste más elevado con
respecto a los otros dos. De hecho la comparación se agrava si los resultados
del coste total se analizan junto a los del porcentaje de peticiones aceptadas.
Por ejemplo, el coste del H2 es siempre superior al del H1 y H3, y además, sólo
para disponibilidades medias el H2 supera al H1 en porcentaje de peticiones
aceptadas (y apenas llega al 0.92% de mejora en ese aspecto, concretamente con
una disponibilidad de 1500 segundos). Cabe destacar que pese a lo que pueda
parecer en esta subsección, el algoritmo H2 presenta prestaciones interesantes,
sobretodo en lo que respecta a calidad de servicio, y más adelante se verá.
Por lo tanto, una vez evaluada la gráca correspondiente al coste total del
sistema, resulta evidente que se ha conseguido el objetivo marcado al inicio del
proyecto, es decir, un ahorro energético gracias al uso de los mecanismos de
reducción de coste incorporados en los algoritmos.
La gura 13 muestra el número de recursos liberados mediante el uso del
algoritmo H3
11 . Como se podía suponer, cuanto más exigente sea el entorno
(disponibilidades bajas) menos recursos se podrán liberar en el sistema.
Si se analizan las guras 12 y 13 puede comprobarse que existe una clara
relación entre el proceso de estabilización en el coste total del sistema y la
cantidad de recursos liberado. El proceso de estabilización del coste empieza
aproximadamente a partir de una disponibilidad de 950 segundos. Es entonces
cuando el algoritmo H3 empieza a liberar recursos del sistema. Por lo tanto,
puede armarse que a medida que el H3 empieza a liberar recursos del sistema,
empieza a estabilizarse el coste total.
Tal y como puede verse en la gráca de la gura 13, a mayor disponibilidad
mayor cantidad de recursos liberados. Esto era de esperar puesto que un sistema
72
Figura 13: Número total de recursos liberados en función de la disponibilidad
del servicio.
con una disponibilidad elevada permite (para el algoritmo H3) emplear un menor
número de recursos para dotar de servicio a todas las peticiones entrantes. En
estos sistemas, y con este algoritmo, un único servidor puede dar servicio a
una gran cantidad de peticiones gracias a la elevada disponibilidad del propio
servidor. Para comprobar todo lo comentado, se puede analizar un ejemplo
puntual. En sistemas en los que la disponibilidad sea de 2000 segundos, se
consigue liberar casi un 57% de los recursos totales del sistema. Este hecho
supone un ahorro considerable con respecto al resto de algoritmos.
La gura 14 está compuesta por dos subguras. La subgura 14a muestra
el tiempo total que se ahorra con el mecanismo de ajuste para cada algoritmo
de los expuestos en el presente documento, y la subgura 14b representa el
porcentaje de ese tiempo ahorrado con respecto al tiempo total del sistema en
activo (tiempo en modo idle y tiempo en modo full) en el supuesto que no se
hubiera empleado el mecanismo de ajuste. En otras palabras, esta segunda sub-
gura muestra el porcentaje de tiempo que se ha conseguido ahorrar mediante
el uso del mecanismo de ajuste
12 . Estas dos subguras sirven para comprobar
la importancia del mecanismo de ajuste, ya que el tiempo que se ahorra con
este mecanismo tiene como consecuencia directa el ahorro en el coste total del
sistema. Tal y como se han denido las variables, los parámetros y el modo de
funcionamiento del sistema en este proyecto, se ha comprobado tras multitud
de pruebas y simulaciones, que el tiempo que se ahorra en un proceso de ajuste
(hay que recordar que equivale al tiempo de entrada, tS ) en media corresponde
al 39% del tiempo total de la petición, tT otal .
Resulta evidente que el algoritmo híbrido H3 es el que ahorra más tiempo
con este mecanismo, sea cual sea la disponibilidad. A priori uno podría pensar
12 Es obligado comentar que esta segunda subgura es una estimación general, ya que resulta
casi imposible reproducir el comportamiento de los algoritmos sin el mecanismo de ajuste.
73
(a) Tiempo ajustado total. (b) Porcentaje de tiempo ajustado con respecto
al total en activo.
74
(a) Número total de balanceos de carga produci-(b) Porcentaje de balanceos de carga realizados.
dos.
75
Figura 16: Número de pérdidas por servicio saturado en función de la disponi-
bilidad del servicio.
76
(a) Porcentaje de pérdidas en(b) Porcentaje de pérdidas en(c) Porcentaje de pérdidas en
H1. H2. H3.
Figura 17: Porcentajes de pérdidas debidas a las tres posibles causas en función
de la disponibilidad del servicio.
prácticamente nulo (en comparación a los valores con los que se trabajan en la
gura 16).
Una vez vista esta gura resulta evidente cuál es la principal razón de pérdida
en el sistema implementado en este proyecto para disponibilidades bajas. Para
disponibilidades medias existen dos razones principales: saturación y longitud
excesiva. Para disponibilidades altas, como era de esperar, no hay pérdidas por
saturación del servicio, así que la mayoría de pérdidas se producen a causa de
una longitud excesiva
14 . Esta apreciación queda reejada en la gura 17.
En la gura 17 puede verse que el comportamiento es idéntico en los tres
algoritmos, la única diferencia es el la disponibilidad a la que se producen los
cambios en la gráca. Tal y como quedaba claro en la gura 11, el H3 se
estabiliza antes que el resto y se producen menos pérdidas. Por eso la saturación
deja de ser el principal motivo de pérdida antes que el resto.
La gura 18 indica el coste medio por recurso utilizado. Esto es, en media,
el coste que aporta un único recurso al coste total del sistema. Debe aclararse
que para este cálculo no se han considerado los recursos liberados (para el caso
del algoritmo híbrido III).
Lo más interesante de esta gura 18 es que, si bien es cierto que el coste
medio por recurso en los algoritmos H1 y H2 siguen la forma espera (es decir,
la del coste total del sistema), el coste medio en el H3 describe un aumento
casi lineal (disponibilidades bajas y medias). Para entorno menos exigentes, al
aumentar el número de recursos liberados, el H3 emplea menos recursos con lo
que la progresión se curva y no sigue la misma forma exacta, pero se aproxima
al aumento lineal de las disponibilidades bajas y medias. Basándose únicamente
en los resultados que reeja la gura, el coste medio por recurso en H3 en función
de la disponibilidad del sistema puede aproximarse con la expresión siguiente:
Disponibilidad 1 1
Costerecurso = + = (Disponibilidad + 12.5) ·10−4
30000 2400 3
14 Como ya se ha comentado en el capítulo 2, el sistema de ltrado es el que descarta
estas peticiones, excepto en el H2 que también puede tener pérdidas por este motivo en el
tratamiento especial que se lleva a cabo en dicho algoritmo.
77
Figura 18: Coste medio por recurso utilizado en función de la disponibilidad del
servicio.
78
Figura 19: Porcentaje de peticiones aceptadas en función del tamaño del bloque
de peticiones.
79
Figura 20: Coste total del sistema en función del tamaño del bloque de peti-
ciones.
80
Figura 21: Número total de recursos liberados en función del tamaño del bloque
de peticiones.
81
(a) Porcentaje de tiempo ajus- (b) Porcentaje de ajustes.
tado.
Figura 22: Información de ajustes en función del tamaño del bloque de peti-
ciones.
otro punto de vista podría decirse que en ese caso, se conseguiría un cierto nivel
de calidad de servicio en detrimento del coste.
Para poder entender mejor la gura correspondiente al coste total del sis-
tema en función del tamaño del bloque de peticiones es necesario analizar otros
aspectos que justican dicha gura. A continuación se muestran estos aspectos.
La gura 22 hace referencia al mecanismo de ajuste. La gura 22a indica el
porcentaje de tiempo que se ahorra al utilizar el mecanismo de ajuste (respecto
al que se le estima si no hubiera tal mecanismo) con respecto al número de peti-
ciones por bloque. Es un buen indicador del ahorro que supone este mecanismo.
Por otra parte, la gura 22b muestra el porcentaje de peticiones que han sido
aceptadas utilizando el mecanismo de ajuste. Puede verse que, el orden de uso
del mecanismo de ajuste coincide con el obtenido en el caso de la disponibilidad,
es decir, en orden descendente: H3, H1 y H2.
Es interesante remarcar que en el H2, existe una relación entre el porcentaje
de tiempo ajustado y el coste. Tal y como puede observarse en la gura 20, a
partir de las 1400 peticiones por bloque el H2 empieza a estabilizarse reduciendo
el crecimiento de su coste. Esto se debe al mayor aprovechamiento del uso del
mecanismo de ajuste en este algoritmo híbrido.
La gura 23 corresponde a los porcentajes de pérdidas para cada una de
las razones posibles en función del número de peticiones por bloque. La gura
indica el porcentaje de peticiones perdidas a causa de: servicio saturado, tiempo
de demora excedido y longitud de tarea excesiva. Esta gura puede ayudar a
comprender mejor el comportamiento de los algoritmos. En la gura 23 puede
observarse que el porcentaje de peticiones perdidas a causa de un servicio sat-
urado es la principal razón por la que se producen pérdidas en cualquiera de
los tres algoritmos híbridos, sobretodo para tamaños de bloque elevados. Este
hecho era de esperar ya que si se trabaja con bloques con muchas peticiones,
las últimas peticiones que se traten muy probablemente se encuentren con los
servicios saturados, y por lo tanto, dichas peticiones quedarán descartadas.
En la subgura 23a puede apreciarse uno de los efectos del uso del sistema
de balanceo de carga que está implementado en el algoritmo H2, y que rigen su
82
(a) Porcentaje de pérdidas por(b) Porcentaje de pérdidas por(c) Porcentaje de pérdidas por
Saturación. Demora. Longitud.
Figura 23: Porcentajes de pérdidas debidas a las tres posibles causas en función
del tamaño del bloque de peticiones.
83
(a) Pérdidas en el algoritmo H1. (b) Pérdidas en el algoritmo H2. (c) Pérdidas en el algoritmo H3.
Figura 24: Porcentajes de pérdidas por tipo de tráco en función del tamaño
del bloque de peticiones.
tamaños de bloque altos, muestra una tasa de pérdidas de casi el 22% para las
peticiones de tipo III, y al rededor del 19% para peticiones que soliciten servicios
a tiempo real, lo cual es inadmisible. En cambio si el algoritmo dispone de un
mecanismo de balanceo de carga, se puede hacer frente a una mayor cantidad
de peticiones, tal y como se aprecia en la gura. Además se observa claramente
las consecuencias del sistema de ordenación de servicios implementado en el bal-
anceo de carga. De esta forma se consigue además, reducir considerablemente
el número de peticiones perdidas para los trácos con un mayor nivel de calidad
de servicio. Por último, la subgura correspondiente al algoritmo H3 muestra
la clara mejoría que se consigue al complementar el balanceo de carga con un
mecanismo de consolidación, minimizando las pérdidas para todos los tipos de
tráco del sistema.
84
Figura 25: Porcentaje de peticiones aceptadas en función del número de recursos
por servicio.
85
Tabla 5: Recursos necesarios en función del ratio de peticones aceptadas
Cota de QoS
16 Recursos H1 Recursos H2 Recursos H3
98% 53 36 30
97% 42 32 25
96% 35 29 22
95% 32 26 21
92% 27 22 18
90% 25 21 17
86
Figura 26: Coste total del sistema en función del número de recursos por servicio.
87
Figura 27: Número total de recursos liberados en función del número de recursos
por servicio.
(a) Porcentaje de tiempo ajus-(b) Reducción de coste con(c) Porcentaje de peticiones que
tado estimado. ajuste. provocan ajustes.
Figura 28: Información de ajustes en función del número de recursos por servicio.
17 Tal y como se ha denido en este capítulo y en los anteriores, todos los servicios tienen
igual número de recursos, por lo que si se añade un recursos la ecuación, en realidad se están
añadiendo uno por servicio, es decir, un total de 4.
88
Figura 29: Porccentaje de balanceos de carga realizados en función del número
de recursos por servicio.
89
(a) Porcentaje de pérdidas por(b) Porcentaje de pérdidas por
Saturación. Demora.
claramente que cuanto menor sea el número de recursos, mayor será en número
de balanceos. Esto era de esperar, ya que, tal y como está denido el entorno
de trabajo en este proyecto, al disponer de más recursos, no es necesario hacer
balanceos de carga. Sin embargo, si el sistema dispone de pocos recursos para
dotar de servicio a las peticiones entrantes, deberá realizar balanceos de carga.
La gura 30 muestra los porcentajes de peticiones perdidas a causa de sat-
uración del servicio y a causa de sobrepasar el tiempo de demora requerido
(subgura 30a y subgura 30b respectivamente), en función de la cantidad de
recursos por servicio. Puede observarse, que como era de esperar, cuantos más
recursos haya disponibles, menor será la cantidad de pérdidas. Es interesante
que, para los datos iniciales expuestos al inicio de la presente sección, el algo-
ritmo H3 sólo precisa de 19 recursos para conseguir que no se produzca ninguna
pérdida por demora. Una vez más, se demuestra la efectividad de la consoli-
dación en entornos adversos (en este caso, entornos que disponen de pocos re-
cursos), sobretodo a la hora de evitar pérdidas por tiempo de demora excedido.
Para el caso de las pérdidas debidas a saturación del servicio el comportamiento
es similar.
90
misma disponibilidad, es decir, que están disponibles el mismo tiempo
total. Concretamente los servidores están disponibles un total de 2000
segundos (33 minutos y 20 segundos).
• Se ha jado el tamaño del set de peticiones, de manera que para esta
simulación se ha utilizado un tamaño de bloque de 1000 peticiones por
bloque.
• Para esta prueba se ha jado el número máximo de recursos disponibles
64 CPUs por servicio).
(
d
P rob {T ráf icoi } = 1 − 3· (6)
10
A partir de la ecuación (6) se ha elaborado una sencilla tabla que indica la
probabilidad de que una petición entrante solicite un determinado servicio.
Concretamente la tabla 6 corresponde a la asignación de probabilidades de
entrada de los diferentes tipos de tráco implementados en este proyecto,
en función del valor de un coeciente de distribución, d, para el caso de
estudio del tráco tipo I. Se podría deducir las tablas correspondientes al
resto de trácos extrapolando de la tabla 6.
18 Se ha seguido esta expresión por exigencias del código de la simulación. No obstante los
resultados obtenidos no sufren ningún tipo de variación por tal expresión.
91
Tabla 6: Asignación de distribución de trácos para el caso de estudio del tipo
I (Business)
0.5 85% 5% 5% 5%
1 70% 10% 10% 10%
1.5 55% 15% 15% 15%
2 40% 20% 20% 20%
2.5 25% 25% 25% 25%
3 10% 30% 30% 30%
92
Figura 32: Coste total en función de la proporción del tráco tipo I en el sistema.
• Al saturarse uno de los servicios más rápidamente que el resto (en este
caso el tipo I), los algoritmos que incorporan un sistema de balanceo de
carga pueden evitar que se descarten peticiones, lo que supondría pérdidas
en el sistema. El H1, como no posee ningún tipo de balanceo de carga, se
ve afectado por este inconveniente, tal y como puede verse claramente en
la gura 31.
93
Figura 33: Recursos liberados en función de la proporción del tráco tipo I en
el sistema.
94
(a) Porcentaje de pérdidas para(b) Porcentaje de pérdidas para(c) Porcentaje de pérdidas para
el H1. el H2. el H3.
fecho todas las peticiones que solicitan ese mismo tipo de servicio, con lo que
el algoritmo se ve obligado a realizar un balanceo de carga para satisfacer las
necesidades de las peticiones entrantes. A partir de una cierta distribución de
entrada, los algoritmos mantienen una determinada tasa de balanceos.
Otro aspecto relacionado con el comportamiento de los algoritmos puede
verse en la subgura 34b, donde se aprecia claramente el aumento de ajustes
que se produce a medida que se tiende a entornos con trácos equiprobables.
Este aumento del número de ajustes para cada algoritmo explica la reducción
de la pendiente de coste total de la gura 32.
La gura 35 muestra información sobre las pérdidas para cada tipo de tráco
en función de la presencia del tráco de tipo I. Esta información puede llegar a
ser de utilidad ya que indica un posible nivel de calidad de servicio. Como era de
esperar, cuanto más tráco de un tipo haya en el sistema, más pérdidas de ese
tipo habrá. Dicho esto, la principal diferencia entre el algoritmo H1 y los otros
dos es el porcentaje de peticiones perdidas del tipo de tráco más abundante,
que en este caso es el tipo I. Puede observarse que gracias al balanceo de carga
los algoritmos H2 y H3 son capaces de evitar la pérdida de peticiones de tipo
I cuando hay mucho tráco de ese tipo. Este hecho se repite para el resto de
trácos, aunque en algunos casos la diferencia es menor que en otros, como se
verá más adelante.
Otro aspecto a resaltar es el aumento que se produce en las pérdidas de tipo
III para el algoritmo H1 en entornos en los que apenas existe tráco de tipo I,
es decir, entornos en los que la distribución de trácos es 10/30/30/30. Una
vez más es debido a que el H1 no cuenta con un sistema de balanceo de carga,
lo que provoca que no pueda satisfacer la demanda de peticiones de tipo III
cuando aumenta el porcentaje de peticiones que solicitan este tipo de servicio.
Sin embargo, puede comprobarse que los algoritmos H2 y H3, si que pueden
solventar este inconveniente ya que cuentan con un mecanismo de balanceo de
carga.
95
Figura 36: Porcentaje de peticiones aceptadas en función de la proporción del
tráco tipo II en el sistema.
96
Figura 37: Coste total en función de la proporción del tráco tipo II en el
sistema.
del tráco de tipo III, que es el que genera una mayor carga al sistema. A
medida que aumenta la presencia del tráco de Alta Carga en el sistema, los
mecanismos implementados en el algoritmo H3 se ponen en funcionamiento y
empiezan a reducir el coste. El H1, al no contar con tales mecanismos, no puede
reducir tanto coste como lo hace el H3. De hecho, la pendiente de la curva de
H1 es muy superior a la de H3, e incluso a la de H2, como consecuencia de los
mecanismos de ahorro energético con los que cuentan los algoritmos.
Evidentemente, cuantas más peticiones se acepten, más coste supondrá al
sistema, por eso, el algoritmo H1 supone un coste tan reducido con respecto a
los otros dos algoritmos.
La gura 38 muestra la cantidad de recursos que el algoritmo H3 logra lib-
erar, en función del porcentaje de peticiones tipo Best Eort (tipo II) del sis-
tema. Como puede verse, cuanto más tráco de un sólo tipo haya en el sistema,
más recursos se logran liberar. Este hecho se repite en el caso del tráco tipo I
(como ya se ha comentado anteriormente) y el tráco de tipo IV (como se verá
más adelante). Esta información podría analizarse más profundamente si se
pudiera estudiar cada servicio por separado, ya que se podría diferenciar entre
recursos liberados de cada uno de los cuatro servicios denidos en el sistema.
En tal caso, se vería que la mayoría de los recursos que el algoritmo H3 consigue
liberar corresponden a los servicios I, III y IV.
La gura 39 muestra información sobre los porcentajes de peticiones que
implican mecanismos de ahorro al ser aceptadas, en función de la presencia
del tráco de tipo II. Concretamente la subgura 39a muestra el porcentaje de
balanceos de carga que se producen, mientras que la subgura 39b muestra el
porcentaje de peticiones aceptadas que han provocado un proceso de ajuste en
el sistema.
Lo primero que llama la atención de esta gura es que tanto la gráca de
97
Figura 38: Recursos liberados en función de la proporción del tráco tipo II en
el sistema.
98
(a) Porcentaje de pérdidas para(b) Porcentaje de pérdidas para(c) Porcentaje de pérdidas para
el H1. el H2. el H3.
19 Se dene la laxitud aumentada como la suma de la laxitud normal (intervalo desde que
acaba el tiempo de tarea hasta el tiempo nal de la petición) y el tiempo que resulta al dividir
el tiempo de tarea entre el número de CPUs solicitadas.
99
Figura 41: Porcentaje de peticiones aceptadas en función de la proporción del
tráco tipo III en el sistema.
Análisis para el tráco del tipo III (Alta Carga ). La gura 41 muestra el
porcentaje de peticiones aceptadas en función de la presencia del tráco de tipo
100
Figura 42: Coste total en función de la proporción del tráco tipo III en el
sistema.
III. De nuevo, la forma de las curvas de porcentajes son similares a las anteriores,
salvo en el algoritmo H1. Como puede verse en la gura, los algoritmos H2 y H3
muestran porcentajes constantes y altos
20 , independientemente de la densidad
de peticiones de Alta Carga (tipo III). No obstante, H1 se ve muy afectado
por la presencia masiva de este tipo de tráco, incluso más que en los casos
anteriormente analizados. Esto se debe a dos motivos: la naturaleza del tráco
(es el que genera una mayor carga al sistema, por lo que satura antes el servicio)
y la ausencia de un mecanismo de balanceo de carga que permita luchar contra
este inconveniente.
En la gura 42 puede verse el efecto del tráco de tipo III sobre el coste
total del sistema. Lo más llamativo de esta gura es que las curvas dieren
radicalmente con respecto a los otros dos casos analizados anteriormente. De
hecho, en este caso el coste se reduce a medida que disminuye el porcentaje de
peticiones de tipo III en el sistema, en los algoritmos H2 y H3. El algoritmo
híbrido H1 se comporta totalmente diferente a nivel de coste, ya que primero
aumenta el coste a medida que aumenta el porcentaje del resto de trácos, pero
cuando llega a los 2.5 (trácos equiprobables) empieza a reducir el coste.
El comportamiento de los algoritmos H2 y H3 se explica una vez más con
la gura correspondiente a las peticiones aceptadas. Presentan un coste muy
superior al de H1 en entornos en los que existe más peticiones de tipo III que
de cualquier otro tipo de tráco, debido a que se aceptan más peticiones, lo
que implica, como ya se ha comentado en repetidas ocasiones, un mayor coste
20 Hay que recordar que aproximadamente el 1.5% de peticiones perdidas son a causa de
una longitud de tarea excesiva, y por lo tanto, son descartadas por el sistema de ltrado. En
el algoritmo H2, sobretodo en entornos en los que predomina el tráco de tipo III, también
se produce cierto número de pérdidas por longitud excesiva a causa de la implementación del
mecanismo de balanceo de carga.
101
Figura 43: Recursos liberados en función de la proporción del tráco tipo III en
el sistema.
energético. Dicho de otro modo, el algoritmo H1, como acepta menos peticiones,
consume menos.
Otro aspecto importante del comportamiento de los algoritmos H2 y H3
es que, al disminuir el porcentaje de peticiones correspondientes al servicio III
(que es el más problemático), se consigue disminuir el coste total del sistema
sin empeorar el ratio de peticiones aceptadas/perdidas. De hecho, el coste que
supone el algoritmo H3 es siempre inferior al de H2 por las mismas razones que
en los casos ya analizados en esta sección, es decir, por realizar un mayor número
de ajustes (como se verá más adelante) y por la combinación de consolidación
con balanceo de carga (minimización de servidores en uso).
Por último, cabe resaltar que para entornos en los que el porcentaje de tráco
de tipo III está por debajo del resto de trácos, el algoritmo H1 disminuye el
coste, precisamente por haber una menor cantidad de peticiones de Alta Carga
(tipo III) en el sistema.
La gura 43 muestra la cantidad de recursos que el algoritmo H3 logra lib-
erar, en función del porcentaje de peticiones tipo III del sistema. En este caso
el número de recursos liberados aumenta a medida que disminuye el porcentaje
de peticiones de este tipo. Esto se debe a que por la caracterización del tipo
de tráco, el tipo III genera una carga muy elevada al sistema, lo que obliga a
emplear un mayor número de servidores. No obstante, como puede apreciarse
en la gura, aunque haya un 85% de peticiones de Alta Carga en el sistema, el
algoritmo H3 es capaz de liberar aproximadamente 46 recursos en total (18% de
los recursos). Cabe recordar que a mayor cantidad de recursos liberados mayor
reducción de coste energético se consigue.
La gura 44 muestra información sobre los porcentajes de peticiones que
implican mecanismos de ahorro al ser aceptadas, en función de la presencia del
tráco de tipo III. Concretamente la subgura 44a muestra el porcentaje de
102
(a) Porcentaje de balanceos de (b) Porcentaje de ajustes.
carga.
103
(a) Porcentaje de pérdidas para(b) Porcentaje de pérdidas para(c) Porcentaje de pérdidas para
el H1. el H2. el H3.
104
Figura 46: Porcentaje de peticiones aceptadas en función de la proporción del
tráco tipo IV en el sistema.
105
Figura 47: Coste total en función de la proporción del tráco tipo IV en el
sistema.
106
(a) Porcentaje de balanceos de (b) Porcentaje de ajustes.
carga.
(a) Porcentaje de pérdidas para(b) Porcentaje de pérdidas para(c) Porcentaje de pérdidas para
el H1. el H2. el H3.
107
Conclusiones generales sobre los análisis para cada tipo de tráco En
este apartado se reúnen una serie de conclusiones generales, a modo de resumen,
obtenidas tras analizar el comportamiento de los tres algoritmos híbridos en
función de la presencia de cada tipo de tráco. Es importante remarcar que estas
conclusiones se han tomado a partir de los resultados expuestos en la presente
memoria, por lo que tienen validez sólo para los datos de entrada comentados
al inicio de esta subsección.
108
de balanceo de carga ayuda a reducir la tasa de errores en entornos en los
que exista un tipo de tráco dominante, sea cual sea dicho tráco.
109
5 Conclusiones
Llegados a este punto, es el momento de concluir la memoria repasando las con-
clusiones realizadas y comprobando que ciertamente se han satisfecho todos los
objetivos que planteados en el capítulo 1. Además en este capítulo se propon-
drán una serie de posibles trabajos futuros relacionados, de una u otra forma,
con la temática del proyecto.
110
• Uno de los puntos fuertes a la hora de reducir el coste del sistema es min-
imizar la cantidad de máquinas utilizadas. En ese sentido, y tras analizar
profundamente los resultados obtenidos, parece claro que un mecanismo
de consolidación en un entorno como el descrito en este proyecto, resulta
muy benecioso en términos de ahorro en el coste energético, ya que se
consigue reducir el número de servidores necesarios para dotar de servicio
a todo un conjunto de peticiones.
111
5.2 Trabajos futuros
Tras todo el trabajo realizado en este proyecto, resulta interesante proponer
una serie de trabajos futuros relacionados con la temática de este proyecto o
que surgen como consecuencia del mismo.
Matlab
dría realizarse un trabajo en el que se implementase un sistema a tiempo
real mediante objetos tipo Java y relacionarlos con el lenguaje .
Con esto se conseguiría un entorno más exible y en el que puedan in-
corporarse nodos a la nube en cualquier momento del proceso. Además
podrían denirse una gran cantidad de variables SLA con las que negociar
y enfocar así el trabajo hacia metas muy diferentes.
112
Bibliografía
[1] García García, A. (2010). Cloud Computing PaaS Platform Cloud Com-
PaaS. Hernández García, V. dir. ; Alfonso Laguna, CD. dir. 113 p.
[5] Henan Zhao and Rizos Sakellariou. Advance Reservation Policies for
Workows. In Proceedings of the 12th International Workshop on Job
Scheduling Strategies for Parallel Processing (JSSPP), June 2006, Saint-
Malo, France. Lecture Notes in Computer Science, volume 4376, pages
47-67.
[8] Henan Zhao and Rizos Sakellariou. Advance Reservation Policies for
Workows. In Proceedings of the 12th International Workshop on Job
Scheduling Strategies for Parallel Processing (JSSPP), June 2006, Saint-
Malo, France. Lecture Notes in Computer Science, volume 4376, pages
47-67.
[9] Sakellariou, R., Yarmolenko, V.: Job Scheduling on the Grid: Towards
SLA-Based Scheduling. In: Grandinetti, L. (ed.) High Performance Com-
putning and Grids in Actions, pp. 207-222. IOS Press, Amsterdam (2008).
113
[13] S.Ran. A Model for Web Services Discovery with QoS. ACM SIGecom
Excanges, 4(1):1-10, Spring 2003.
[15] K. Trivedi. Probability and Statistics with Reliability, Queuing, and Com-
puter Science Applications. John Wiley & Sons, 2001.
[19] Rizos Sakellariou, Viktor Yarmolenko, Parallel Job Scheduling for HPC:
the Case for Novel Forms of Scheduling , in Book High Performance Com-
puting and Grids in Action, L. Grandinetti Ed., IOS Press, (2008).
[20] http://www1.euro.dell.com/es/es/corp/Servidores/poweredge-
c5000/pd.aspx?red=poweredge-c5000&s=corp
[21] Artur Andrzejak, Derrick Kondo, Sangho Yi: Decision Model for Cloud
Computing under SLA Constraints. MASCOTS 2010: 18th Annual
IEEE/ACM International Symposium on Modeling, Analysis and Simula-
tion of Computer and Telecommunication Systems, Miami, Florida, USA,
August 17-19, 2010. Pages 257-266 MASCOTS 2010.
[22] http://www.intel.la/content/www/xl/es/processors/xeon/xeon-processor-
e3-family/micro-server-resources.html
[23] http://www.powerof60.com/introducingthetechnology.html?utm_source=
AWSHP&utm_medium=banner&utm_campaign=BA_AWSHP_IntelAWS&utm
_content=GenericAWS&00N500000026nJd=BA_AWSHP_IntelAWS_Generic&
[24] García García, A. (2010). Cloud Computing PaaS Platform Cloud Com-
PaaS. Hernández García, V. dir. ; Alfonso Laguna, CD. dir. 113 p.
114
[25] M Calzarossa M Italiani and G Serazzi A Workload Model Representative
of Static and Dynamic Characteristics Acta Informatica, 23:255-266, 1986.
[27] Xiaoli Wang, Yuping Wang and Hai Zhu Energy-Ecient Multi-Job
Scheduling Model for Cloud Computing and Its Genetic Algorithm Hin-
dawi Publishing Corporation, Mathematical Problems in Engineering, Vol-
ume 2012, Article ID 589243, 16 pages, doi:10.1155/2012/589243
[28] Wu L., Garg S. K., and Buyya R., SLA-based Admission Control for a
Software-as-a-Service Provider in Cloud Computing Environments, Journal
of Computer and System Sciences, May 2011.
[31] http://www.thegreengrid.org/
115
116