Embed Size (px)
Citation preview
UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA
VALPARAÍSO – CHILE
“ESTUDIO E IMPLEMENTACIÓN DE LA TÉCNICA
DE VIRTUALIZACIÓN EN LA DIRECCIÓN
CENTRAL DE SERVICIOS COMPUTACIONALES,
UTFSM”
ALEJANDRO ESTEBAN LARA MOLINA
MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE
INGENIERO CIVIL TELEMÁTICO
PROFESOR GUÍA:
PROFESOR CORREFERENTE
DRA. ALEJANDRA BEGHELLI Z.
MSC. MARCELO MARABOLI R.
MAYO 2011
2
Al Padre, su Hijo y su Espíritu,
por estar siempre junto a mí.
A mis padres y hermana,
por las oraciones, el apoyo y los sacrificios que hoy tienen respuesta.
A mis abuelas, ti@s, prim@s e hij@s,
por el apoyo, las preocupaciones y las fuerzas.
A los profesores que guiaron este trabajo,
por las oportunidades, sus consejos y el apoyo bridado en este último tramo.
A Telemática y a todos quienes la conforman,
por su acogida y por permitir mi pleno desarrollo.
3
RESUMEN
Durante la década recién pasada, la virtualización se ha transformado en una de las técnicas más
utilizadas en grandes instituciones que necesitan ofrecer servicios informáticos de distinta índole.
Sin duda esta tendencia se mantendrá durante los años venideros.
La virtualización permite la ejecución de distintas máquinas virtuales (cada una a cargo de un
servicio distinto) en una misma máquina física. Esto conlleva ventajas significativas en términos
de ahorros de hardware, disminución en el consumo de electricidad y eficiencia en la
administración tanto de las máquinas virtuales como de los recursos de hardware reales
existentes. La principal desventaja consiste en el aumento del tiempo de respuesta de los
servicios virtualizados. Sin embargo, el beneficio de implementar virtualización parece
compensar con creces la desventaja asociada, dada la adopción masiva de la virtualización por
parte de diversas instituciones.
En la actualidad el mercado ofrece varias herramientas que permiten implementar virtualización.
Entre ellas se distinguen herramientas propietarias y de código fuente abierto. En ambos casos, la
mayoría de las herramientas permite explotar las principales ventajas de esta técnica. La
selección de la mejor alternativa estará determinada por los requerimientos y restricciones que
plantee el usuario para los servicios virtualizados.
En esta memoria se presenta una descripción de la técnica de virtualización así como un estudio
comparativo de las principales herramientas de virtualización disponibles en el mercado
(propietarias y de código abierto). Posteriormente, se presenta un caso de estudio que analiza la
factibilidad técnica de implementar la técnica de virtualización para 3 servicios de la Dirección
Central de Servicios Computacionales (DCSC) de la Universidad Técnica Federico Santa María.
Este análisis considera los requerimientos y restricciones de la DCSC y los beneficios que se
esperan obtener tras una implementación formal. Además de esto se reporta una implementación
primaria de virtualización, la cual consta de una serie de pruebas a los servicios de Web, DNS y
LDA. Finalmente, la memoria finaliza con las conclusiones obtenidas a partir del trabajo
realizado y con la propuesta de algunos trabajos futuros en esta misma línea.
4
ABSTRACT
In the last decade, virtualization has become one of the main techniques used in organizations
offering different types of informatics services. This trend is envisaged to continue in the coming
years.
Virtualization allows the execution of different virtual machines (each in charge of a determined
service) in a single physical host. As a result, significant advantages in terms of hardware
savings, electricity consumption and management efficiency are achieved. The main drawback
lies in the increase of the response time of virtualized services. However, the benefits of
implementing virtualization seems to compensate the downside of the increased delay, given the
widely adoption of such techniques in many organization.
Currently, the marked offers many virtualization software kits. They can be classified between
proprietary and open source kits. In both cases, most of them allow benefiting from the main
advantages of virtualization. The selection of the proper virtualization software kit will be
determined by the requirements and constraints imposed by the user on the characteristics of the
virtualized services.
In this work a brief description of the virtualization technique is given as well as a comparative
study of the main proprietary and open source software kits. Then, a case of study with the aim
of evaluate the technical feasibility of implementing virtualization for 3 services offered by the
Computational Services Unit (DCSC, Dirección Central de Servicios Computacionales) at
Universidad Técnica Federico Santa María. The study takes into account the requirements and
constraints imposed by the DCSC to its virtualized services as well as the benefits expected after
implementing virtualization. A preliminary implementation is reported, where the services of
web, DNS and LDAP are virtualized. Finally, this work ends with the drawing of the main
conclusions and the proposal of further work.
5
Índice
Capítulo 1
1. INTRODUCCIÓN .................................................................................................................... 11
2. REFERENCIAS ........................................................................................................................ 15
Capítulo 2
VIRTUALIZACIÓN..................................................................................................................... 16
1. ASPECTOS DE LA TÉCNICA DE VIRTUALIZACIÓN. ................................................. 16
1.1. DEFINICIÓN. ................................................................................................................ 16
1.2. HISTORIA. .................................................................................................................... 17
2. TIPOS DE VIRTUALIZACIÓN. ......................................................................................... 18
2.1. VIRTUALIZACIÓN A NIVEL DE SISTEMA OPERATIVO. .................................... 18
2.2. VIRTUALIZACIÓN A NIVEL DE HARDWARE....................................................... 19
2.2.1. FULL-VIRTUALIZACIÓN. .................................................................................. 20
2.2.2. PARAVIRTUALIZACIÓN. ................................................................................... 21
3. VENTAJAS DE LA VIRTUALIZACIÓN. .......................................................................... 21
3.1. CONSOLIDACIÓN DE SEVIDORES. ......................................................................... 22
3.2. AHORROS ..................................................................................................................... 22
3.3. ADMINISTRACIÓN ..................................................................................................... 23
3.4. INTEGRACIÓN DE HARDWARE. ............................................................................. 24
3.5. TECNOLOGÍA VERDE. ............................................................................................... 25
4. DESVENTAJAS DE LA VIRTUALIZACIÓN. .................................................................. 25
4.1. DEGRADACIÓN DE SERVICIOS............................................................................... 26
5. RESUMEN. .......................................................................................................................... 26
6. BIBLIOGRAFÍA. ................................................................................................................. 27
6
Capítulo 3
ANÁLISIS DENTRO DE LA DIRECCIÓN CENTRAL DE SERVICIOS
COMPUTACIONALES (DCSC) ................................................................................................. 31
1. CONTEXTO ACTUAL DE LA DCSC. ............................................................................... 31
2. OBJETIVOS TRAS LA IMPLEMENTACIÓN DE VIRTUALIZACIÓN. ........................ 32
2.1. EJECUCCIÓN DE DIVERSOS SISTEMAS OPERATIVOS DENTRO DE UNA
MISMA MÁQUINA. ................................................................................................................ 32
2.2. ADMINISTRACIÓN DE SERVIDORES. .................................................................... 33
2.3. INTEGRACIÓN DE HARDWARE. ............................................................................. 35
3. REQUERIMIENTOS Y RESTRICCIONES. ....................................................................... 36
3.1. EJECUCIÓN DE DIVERSOS SISTEMAS OPERATIVOS DENTRO DE UNA
MISMA MÁQUINA. ................................................................................................................ 36
3.2. ADMINISTRACIÓN DE SERVIDORES. .................................................................... 36
3.3. INTEGRACIÓN DE HARDWARE. ............................................................................. 37
3.4. RESTRICCIONES. ........................................................................................................ 37
4. RESUMEN. .......................................................................................................................... 38
5. BIBLIOGRAFÍA. ................................................................................................................. 39
Capítulo 4
ANÁLISIS DE HERRAMIENTAS DE VIRTUALIZACIÓN .................................................... 41
1. HERRAMIENTAS. .............................................................................................................. 41
1.1. HERRAMIENTAS PROPIETARIAS. .......................................................................... 41
1.1.1. VMWARE VSPHERE............................................................................................ 42
1.1.2. CITRIX XENSERVER. .......................................................................................... 48
1.2. HERRAMIENTAS DE CÓDIGO ABIERTO. .............................................................. 52
1.2.1. XEN. ....................................................................................................................... 52
1.2.2. KVM. ...................................................................................................................... 54
1.2.3. PROXMOX VIRTUAL ENVIRONMENT. ........................................................... 56
2. ANÁLISIS Y SOLUCIÓN. .................................................................................................. 58
3. RESUMEN. .......................................................................................................................... 59
7
4. BIBLIOGRAFÍA. ................................................................................................................. 60
Capítulo 5
IMPLEMENTACIÓN Y ANÁLISIS DE LA SOLUCIÓN.......................................................... 65
1. BENEFICIOS. ...................................................................................................................... 65
1.1. CANTIDAD DE SERVIDORES VIRTUALES. ........................................................... 66
1.2. AHORRO ENERGÉTICO ............................................................................................. 67
2. DESVENTAJAS POR TIPO DE SERVICIO VIRTUALIZADO ....................................... 69
2.1. SERVICIO WEB............................................................................................................ 70
2.2. DNS. ............................................................................................................................... 76
2.3. LDAP ............................................................................................................................. 79
3. RESUMEN. .......................................................................................................................... 84
4. BIBLIOGRAFÍA. ................................................................................................................. 85
Capítulo 6
CONCLUSIONES Y TRABAJO FUTURO ................................................................................ 87
1. CONCLUSIONES ................................................................................................................ 87
2. TRABAJO FUTURO............................................................................................................ 88
Anexos
A1: Gráficos detallados de las pruebas realizadas. ....................................................................... 90
1. WEB. ..................................................................................................................................... 90
2. DNS....................................................................................................................................... 96
3. LDAP. ................................................................................................................................... 99
A2: Códigos de programas para mediciones .............................................................................. 104
1. WEB .................................................................................................................................... 104
3. LDAP .................................................................................................................................. 104
3.1. ldap_test.sh ................................................................................................................... 104
3.2. ldap_test_2.sh ............................................................................................................... 105
8
Índice de figuras
Figura 2.1: Esquema de virtualización a nivel de sistema operativo ............................................ 19
Figura 2.2: Esquema de full-virtualización ................................................................................... 20
Figura 2.3: Esquema de paravirtualización ................................................................................... 21
Figura 4.1: Arquitectura de funcionamiento de VMware vSphere ............................................... 42
Figura 4.2: Arquitectura de funcionamiento de Citrix XenServer. ............................................... 49
Figura 4.3: Arquitectura de Xen ................................................................................................... 53
Figura 4.4: Arquitectura de KVM. ................................................................................................ 55
Figura 4.5: Arquitectura de Proxmox Virtual Environment. ........................................................ 57
Figura 5.1: Configuración de red y dispositivos utilizados para las pruebas. ............................... 69
Figura 5.2: Ilustración de los tiempos involucrados en una transacción HTTP de Apache
Benchmark. ................................................................................................................................... 72
Figura 5.3: Gráficas de los escenarios obtenidas con Apache Benchmark. .................................. 73
Figura 5.4: Gráficas de los escenarios obtenidas con NameBench. ............................................. 77
Figura 5.5: Gráficas de los escenarios impares obtenidas con el script. ....................................... 81
Figura 5.6: Gráficas de los escenarios pares obtenidas con el script ............................................ 82
Figura A.1: Datos evaluación web, escenario 1 ............................................................................ 90
Figura A.2: Datos evaluación web, escenario 2 ............................................................................ 91
Figura A.3: Datos evaluación web, escenario 3. ........................................................................... 91
Figura A.4: Datos evaluación web, escenario 4. ........................................................................... 92
Figura A.5: Datos evaluación web, escenario 5 ............................................................................ 92
Figura A.6: Datos evaluación web, escenario 6 ............................................................................ 93
Figura A.7: Datos evaluación web, escenario 7 ............................................................................ 93
Figura A.8: Datos evaluación web, escenario 8 ............................................................................ 94
Figura A.9: Datos evaluación web, escenario 9 ............................................................................ 94
Figura A.10: Datos evaluación web, escenario 10 ........................................................................ 95
Figura A.11: Datos evaluación DNS, escenario 1 ........................................................................ 96
Figura A.12: Datos evaluación DNS, escenario 2 ........................................................................ 96
Figura A.13: Datos evaluación DNS, escenario 3 ........................................................................ 97
Figura A.14: Datos evaluación DNS, escenario 4 ........................................................................ 97
9
Figura A.15: Datos evaluación DNS, escenario 5 ........................................................................ 98
Figura A.16: Datos evaluación LDAP, escenario 1 ...................................................................... 99
Figura A.17: Datos evaluación LDAP, escenario 2 ...................................................................... 99
Figura A.18: Datos evaluación LDAP, escenario 3 .................................................................... 100
Figura A.19: Datos evaluación LDAP, escenario 4 .................................................................... 100
Figura A.20: Datos evaluación LDAP, escenario 5 .................................................................... 101
Figura A.21: Datos evaluación LDAP, escenario 6 .................................................................... 101
Figura A.22: Datos evaluación LDAP, escenario 7 .................................................................... 102
Figura A.23: Datos evaluación LDAP, escenario 8 .................................................................... 102
Figura A.24: Datos evaluación LDAP, escenario 9 .................................................................... 103
Figura A.25: Datos evaluación LDAP, escenario 10 .................................................................. 103
10
Índice de tablas
Tabla 3.1: Tabla de requerimientos y restricciones para las herramientas a analizar. .................. 37
Tabla 4.1: Detalle de cada una de las distintas versiones de VMware vSphere. .......................... 44
Tabla 4.2: Detalle de las versiones de VMware vSphere para pequeñas y medianas empresas... 46
Tabla 4.3: Análisis de funcionalidades de VMware vSphere según requerimientos y
restricciones de la DCSC .............................................................................................................. 47
Tabla 4.4: Detalle de las distintas versiones de Citrix XenServer ................................................ 50
Tabla 4.5: Análisis de funcionalidades de Citrix XenServer según requerimientos y restricciones
de la DCSC ................................................................................................................................... 51
Tabla 4.6: Análisis de funcionalidades de Xen según los requerimientos y restricciones de la
DCSC. ........................................................................................................................................... 54
Tabla 4.6: Análisis de funcionalidades de KVM según los requerimientos y restricciones de la
DCSC. ........................................................................................................................................... 56
Tabla 4.8: Análisis de Proxmox Virtual Environment según las especificaciones de la DCSC .. 58
Tabla 5.1: Especificaciones de hardware y sistema operativo de los equipos utilizados para las
pruebas .......................................................................................................................................... 70
Tabla 5.2: Resumen de las pruebas con Apache Benchmark. ...................................................... 71
Tabla 5.3: Tiempos promedio y total de cada escenario. .............................................................. 74
Tabla 5.4: Resumen de pruebas con Namebench ......................................................................... 76
Tabla 5.5: Tiempos promedio y total para cada escenario ............................................................ 79
Tabla 5.6: Escenarios de prueba para LDAP. ............................................................................... 80
Tabla 5.7: Tiempos promedio y total para cada escenario ............................................................ 83
11
Capítulo 1
1. INTRODUCCIÓN
Dentro de las empresas e instituciones como las universidades, es común que se ofrezcan
servicios de red tales como sitios web, directorio de personas, nombres de dominio, entre otros.
Adicionalmente, se encuentran muchas aplicaciones de carácter interno que también están
basadas en la red, como sitios de control de versiones para documentos, sistemas de gestión, etc.
Todos estos servicios y aplicaciones requieren de un servidor para ejecutarse. Según la cantidad
de servicios y aplicaciones, la cantidad y variedad de servidores dentro de las empresas o
instituciones suele ser considerable, generándose así problemas importantes en términos de su
administración y mantención.
Entre los problemas más comúnmente observados destacan los siguientes:
La necesidad de ejecutar diversos sistemas operativos (Windows, Solaris, Unix, Linux,
etc.) requiere de servidores dedicados por cada sistema operativo. Esto implica costos en
la adquisición de servidores, ya que cada plataforma debe tener su o sus propios
servidores dedicados. Adicionalmente, para plataformas que no son de código abierto, se
requiere la adquisición de licencias, lo que impacta el manejo del presupuesto.
La subutilización de los recursos de hardware, en el caso de servidores dedicados. Como
ejemplo, un servidor que ejecuta el servicio de Domain Name System o DNS [1]
mediante la aplicación BIND DNS [2], no tendrá una utilización de CPU mayor al 15%
[3].
Ante la inexistencia de una herramienta de software que administre centralizadamente los
recursos, la administración y mantención de estos servidores puede volverse
problemática. Por ejemplo, el retiro de servidores para mantención o actualización de
software o hardware, requiere la activación de un servidor de respaldo al que se deben
migrar los servicios ofrecidos por el servidor original, de manera transparente al usuario.
Existen casos reportados de empresas [4], [5] y [6], que se vieron enfrentadas a al menos una de
las situaciones planteadas anteriormente. Las soluciones implementadas apuntaron a tener una
12
infraestructura que permitiera integrar una gran variedad de sistemas operativos dentro de ella y
que fuera fácil de administrar y mantener en el tiempo, lo cual se pudo lograr mediante la técnica
de virtualización.
La virtualización es una técnica mediante la cual, los recursos de un computador (CPU, RAM,
almacenamiento y tarjetas de red) se asignan, de manera dinámica, a distintos procesos. Estos
procesos tienen la cualidad de representar una máquina virtual, con las mismas funcionalidades
de un computador. Cada máquina virtual tiene su propio sistema operativo y tiene acceso a todos
los recursos de la máquina física, además de ser independiente del resto de las máquinas
virtuales.
El proceso maestro encargado de asignar los recursos entre las máquinas virtuales se conoce
como el Administrador de Máquinas Virtuales (Virtual Machine Monitor o VMM), que crea una
capa de abstracción entre el hardware de la máquina física (conocida también como host) y el
sistema operativo de cada máquina virtual. Este administrador es el encargado de asignar los
recursos entre las máquinas virtuales (también conocidas como guests), permitiendo ejecutar
distintos sistemas operativos, dentro de una sola máquina física.
Entre los beneficios reportados de la técnica de virtualización [7], destacan el ahorro de
máquinas físicas, estimado en una razón de hasta 20:1 [8], la reducción en consumo eléctrico, el
que se estima cercano a los 7000 [kW/h] anuales por servidor virtualizado, y la mejora en los
porcentajes de utilización de servidores (de un rango de 5-15% a 60-80%).
La principal desventaja de la técnica de virtualización consiste en la poca tolerancia a fallas, ya
que si falla la plataforma física, fallan también todas máquinas virtuales que se ejecutan sobre
ella. Otra desventaja que presenta la virtualización es la degradación de servicio, ya que si un
servidor tiene muchas máquinas virtuales, estas deben compartir los recursos físicos del servidor
host, lo cual introduce retardos en las respuestas de las máquinas virtuales.
Dados los beneficios y desventajas de la técnica de virtualización, antes de implementarla en
cualquier institución es necesario un análisis previo de requerimientos ya que no todos los
servicios se benefician de su puesta en marcha. Por ejemplo, una aplicación masiva como un
sitio web que tiene un alto número de visitas, no se ejecutaría dentro de una máquina virtual,
dadas las limitaciones en tiempos de respuesta.
13
El objetivo de este trabajo de título es el análisis y la implementación de virtualización dentro de
la Dirección Central de Servicios Computacionales de la Universidad Técnica Federico Santa
María. Para conseguir este objetivo, el trabajo consistirá en las siguientes etapas:
Análisis de la necesidad de implementar virtualización dentro de la institución. Esta etapa
incluirá un análisis de los servicios requeridos por la institución y sus requerimientos de
hardware.
Análisis y estudio de las diversas herramientas de virtualización disponibles en la
actualidad, tomando en cuenta lo que cada una de ellas ofrece en comparación a los
requerimientos anteriormente señalados,
Implementación primaria de la herramienta seleccionada, a fin de estudiar su
comportamiento
Evaluación de desempeño de la implementación, en cuanto a beneficios y a pérdidas o
costos que podrían repostarse tras una implementación definitiva.
El resto de esta memoria se ordena de la siguiente forma:
El capítulo 2 abordará el tema de virtualización, con su definición y evolución histórica. Además
se presentarán de los tipos de virtualización existentes, finalizando con sus ventajas y
desventajas.
Por su parte, en el capítulo 3 se analizará la situación dentro de la Dirección Central de Servicios
Computacionales, desde donde se obtendrán los requerimientos base para la búsqueda de una
solución.
En el capítulo 4 se presentará el estudio de las herramientas de virtualización existentes en la
actualidad, analizándolas según los requerimientos del capítulo 3 para así encontrar una solución
final.
Por otra parte, en el capítulo 5 se presentará el análisis posterior a la implementación primaria de
la herramienta elegida anteriormente. Se realizará una proyección de los beneficios que se
obtendrán y de los costos que se deberán asumir.
14
Finalmente, en el capítulo 6 se presentarán las conclusiones obtenidas y los futuros trabajos que
se podrán realizar tras esta memoria.
15
2. REFERENCIAS
[1] Domain Name System – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Domain_Name_System> [consulta: 31 de marzo de 2011]
[2] BIND – Wikipedia, the free encyclopedia [en línea] <http://en.wikipedia.org/wiki/BIND>
[consulta: 31 de marzo de 2011]
[3] ALBITZ, Paul y LIU, Cricket. DNS and BIND. 5ta Ed. 1005 Gravenstein Highway North,
Sebastopol, CA 95472, Estados Unidos, O’Reilly & Associates, 2006.
[4] VMware customer story, KAZ Computing - VMware. [en línea]
<http://www.vmware.com/files/pdf/customers/apac_au_07Q4_cs_vmw_kaz_computing_english.
pdf> [consulta: 10 de octubre de 2010]
[5] Microsoft case of study, Accenture - Microsoft. [en línea]
<http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=1000004028>
[consulta: 10 de octubre de 2010]
[6] VMware customer story, nworks – VMware. [en línea].
<http://www.vmware.com/files/pdf/customers/07Q3_ss_vmw_Nworks_English.pdf> [consulta:
10 de octubre de 2010]
[7] LÓPEZ-VALLEJO M., HUEDO E., GARBAJOSA J. Informe de Vigilancia Tecnológica
madri+d “Green IT: tecnologías para la eficiencia energética de los sistemas TI”. [en línea]
Fundación madri+d para el Conocimiento. Madrid (España). 2008.
<http://www.madrimasd.org/informacionidi/biblioteca/publicacion/doc/VT/VT19_green_IT_tec
nologias_eficiencia_energetica_sistemas_TI.pdf> [consulta: 11 de octubre de 2010]
[8] Reduce Energy Cost and Go Green With VMware Green IT Solutions - VMware. [en línea]
<http://www.vmware.com/files/pdf/VMware-GREEN-IT-OVERVIEW-SB-EN.pdf> [consulta:
11 de octubre de 2010]
16
Capítulo 2
VIRTUALIZACIÓN
En este capítulo se describirá en mayor detalle la técnica de virtualización y cuál ha sido su
evolución en el tiempo. También se presentarán los distintos tipos de virtualización existentes
actualmente y por último, se abordarán las ventajas y desventajas que presenta esta técnica.
1. ASPECTOS DE LA TÉCNICA DE VIRTUALIZACIÓN.
Como primera parte, se realizará una definición de lo que trata la de virtualización, describiendo
otros términos que ayudarán a comprenderla. Además de esto, se realizará una reseña histórica
respecto de ella, desde sus inicios hasta nuestros días, la cual ayudará a comprender su evolución
histórica.
1.1. DEFINICIÓN.
Tal como se presentó en la introducción, la virtualización es una técnica que permite ejecutar
diversos procesos que simulan una máquina real, conocidos como máquinas virtuales (guests),
dentro de una máquina física (host). Cada una de estas máquinas virtuales tendrá asignada
instancias de cada uno de los recursos de hardware (CPU, memoria RAM, almacenamiento y
dispositivos de red) que posea la máquina física y operará de manera independiente del resto de
las máquinas virtuales instaladas en el mismo host.
El Administrador de Máquinas Virtuales (Virtual Machine Monitor o VMM), es el proceso
encargado de administrar los recursos de hardware de la máquina física, asignándolos de manera
dinámica y transparente a cada una de las máquinas virtuales. Además de esto, el VMM es el
encargado de proveer la independencia a cada una de las máquinas virtuales.
La asignación de recursos por parte del VMM, se lleva a cabo mediante algoritmos de
planificación o de scheduling. Dentro de los distintos tipos de algoritmos utilizados, se encuentra
el Planificador Basado en Créditos [1] (Credit-Based Scheduler).Este algoritmo considera dos
valores, el primero es weight, que indica la porción de CPU física que le corresponde a cada
CPU de máquina virtual o CPU virtual y el cap, que indica el tiempo de utilización de la CPU
física por parte de la CPU virtual. Estos valores son los encargados de asignar prioridad de uso
17
de CPU a cada máquina virtual. Además, cada CPU virtual tiene una variable llamada crédito, la
cual puede tomar dos valores over, si la CPU física ya fue utilizada y under, si aún no. El
algoritmo funciona de la siguiente forma:
Se inicializan todas las variables de crédito de las CPUs virtuales, en estado under.
Se atiende a la CPU virtual con mayor weight, por el periodo de tiempo indicado por cap.
Una vez finalizado el uso de CPU física, se cambia la variable de crédito de la CPU
virtual a estado over y se atiende a la CPU con mayor weight y que se encuentre con
variable crédito en estado under.
Este algoritmo es utilizado en Xen, un VMM código abierto y en el que se ahondará en detalle en
la sección 1.2.1 del capítulo 4.
Además de este algoritmo, algunos VMM utilizan algoritmos de planificación incorporados en el
núcleo (kernel) del sistema operativo, como es el caso del Planificador Completamente Justo [2]
(CFS: Completely Fair Scheduler). Este algoritmo busca minimizar los tiempos de espera, sobre
todo para los procesos que, por prioridad, se atienden al final. Este algoritmo se utiliza en las
últimas versiones de núcleo de Linux, lo cual es aprovechado por el VMM de código abierto
KVM, del cual se profundizará con mayor detalle en la sección 1.2.2 del capítulo 4
1.2. HISTORIA.
El concepto de virtualización no es reciente, ya a comienzo de la década de 1960 el proyecto
Atlas [3] desarrollado entre la Universidad de Manchester y Ferranti Ltd., constaba en un
computador que, entre otras características, ejecutaba un programa supervisor de rutinas de extra
código (Supervisor Extracode Routines o S.E.R.), que se ejecutaba en una especie de máquina
virtual y otra de estas máquinas virtuales era utilizada para ejecutar programas de usuario [4].
Otra empresa precursora de la virtualización fue IBM, que a mediados de la década de 1960
trabajó en el proyecto M44/44X [5] que constaba de una máquina base (M44) modelo 7044, y el
resto eran máquinas virtuales de la máquina 7044 (44X). El objetivo tras esto era el aprovechar
al máximo el hardware disponible en los grandes y costosos computadores de la época
(mainframes) de manera de ejecutar múltiples tareas (multitasking) en este computador.
18
Para finales de la década de 1960 y comienzos de la década de 1970, IBM desarrolló otros
proyectos tales como el sistema operativo CP-40 [6], desarrollado para el sistema S360/40 y que
permitía ejecutar multiples instancias de sistemas operativos clientes, además es considerado
como el primer sistema operativo en implementar virtualización completa. Luego, se desarrolló
el CP-67 [7], basado en CP-40, para el sistema S360/67, entre otros [8].
Para finales de la década de 1970 y la década de 1980, la virtualización perdió terreno con la
aparición de los computadores de escritorio y los servidores con arquitectura x86. Pero el interés
por tener plataformas fáciles de administrar y los intentos por abaratar costos en la
infraestructura de tecnologías de la información en las empresas, reimpulsaron la investigación y
el desarrollo de esta técnica, lo cual se refleja en el hecho de que para la segunda mitad de la
década de 1990, empresas como VMware [9] comenzaran a explotar este nicho, ofreciendo
soluciones para servidores y computadores de escritorio.
Para la primera década del siglo XXI, la virtualización ha tenido un gran auge, de la mano de
soluciones propietarias ofrecidas por empresas como Microsoft [10], VMware, Citrix [11], entre
otras. Además de estas, existe una importante cantidad de soluciones de tipo código abierto, tales
como Xen [12], KVM [13], OpenVZ [14], entre otras. Además de esto, las empresas
desarrolladoras de procesadores como Intel y AMD han contribuido a este auge desarrollando
tecnología compatible con virtualización, como Intel VT [15] y AMD-V [16], las cuales han
facilitado la implementación de esta técnica tanto en computadores de escritorio como en
servidores.
2. TIPOS DE VIRTUALIZACIÓN.
En esta sección se describirán los tipos de virtualización existentes: la virtualización a nivel de
sistema operativo y la virtualización a asistida por hardware. Se detallan las características
principales y los principales exponentes de cada uno de estos tipos.
2.1. VIRTUALIZACIÓN A NIVEL DE SISTEMA OPERATIVO.
Esta tipo de virtualización permite al núcleo del sistema operativo tener múltiples copias o
instancias de un mismo sistema operativo, tal como se puede apreciar en la figura 1. Cada una de
19
estas copias es independiente de la otra, es decir, un proceso que se encuentra ejecutándose en
una copia A no afectará directamente a otro proceso que se encuentra en la copia B.
Para conseguir esta independencia, el núcleo del sistema operativo es quien maneja la asignación
de los recursos a fin de que no existan problemas entre las copias.
Figura 2.1: Esquema de virtualización a nivel de sistema operativo
Dentro de las ventajas de este tipo de virtualización se cuenta el no introducir mayor sobrecarga
en el sistema, ya que al ser copias del mismo sistema operativo, no se necesita hardware
emulado, a diferencia de la técnica de virtualización asistida por hardware, que si lo necesitan.
La desventaja de este tipo de virtualización consiste en que sólo permite copias del mismo
sistema operativo, dado que el núcleo es el mismo para todas estas copias. Por lo tanto, en el
caso de que necesitaran máquinas virtuales con sistemas operativos de distinto núcleo (por
ejemplo, una máquina con Microsoft Windows y otra con FreeBSD), este tipo de virtualización
no servirá.
Ejemplos de herramientas que usan este tipo de virtualización son: FreeBSD jails [17], Solaris
Zones [18] y OpenVZ [14].
2.2. VIRTUALIZACIÓN A NIVEL DE HARDWARE.
La virtualización de hardware permite ejecutar diversos sistemas operativos dentro de una misma
máquina física, lo cual marca una diferencia con lo visto anteriormente.
Dentro de esta modalidad existen dos subtipos de virtualización, los cuales son: full-
virtualización y para-virtualización.
Copia A Copia B Copia N …
Sistema Operativo
Hardware
20
2.2.1. FULL-VIRTUALIZACIÓN.
En este subtipo, el administrador de máquinas virtuales o VMM, es el encargado de permitir el
acceso de cada máquina virtual a los recursos de hardware físico existentes en la máquina física,
entregando un acceso transparente a los recursos de hardware a cada una de las máquinas
virtuales existentes. Como se explicó en un comienzo, el acceso al hardware se realiza mediante
algoritmos de planificación o de scheduling, los cuales asignan los recursos de hardware entre las
máquinas virtuales. La figura 2 presenta un esquema de cómo funciona este subtipo de
virtualización. Dentro de los componentes se destaca el administrador de máquinas virtuales
(VMM), compuesto generalmente por un sistema operativo base y alguna herramienta de
virtualización (como Xen o KVM) y las herramientas de administración, que brindan utilidades
extra, las cuales dependerán de la herramienta de virtualización (ver Cap. 4).
Figura 2.2: Esquema de full-virtualización
Esta técnica tiene como principal desventaja que el acceso a hardware mediante algoritmos de
scheduling introduce cierta sobrecarga en el sistema, ya que por cada máquina virtual que
requiere acceso a los recursos de hardware, el administrador de máquinas virtuales debe ejecutar
dicho algoritimo. Sin embargo, en la actualidad esto se ha visto mejorado de cierta forma,
especialmente con la aparición de las tecnologías de virtualización desarrolladas por los distintos
fabricantes de hardware, como lo es en el caso de Intel y AMD, quienes han desarrollado
procesadores con tecnología Intel VT-x [15] y AMD-V [16] respectivamente, tecnologías que
permiten un mejor desempeño en la asignación de CPU a las máquinas virtuales.
Ejemplos de herramientas de virtualización que utilizan esta subclase de técnica son: VMware
ESXi [20], Citrix Xenserver [21] y KVM [13].
Guest 1 Guest 2
Admin.
Tools
…
VMM
Hardware
21
2.2.2. PARAVIRTUALIZACIÓN.
Esta subclase se caracteriza por proveer una API (Application Programming Interface o Interfaz
de Programación de Aplicaciones) [22] especial, la cual busca optimizar el acceso a los recursos
de hardware, agilizándolo. Para utilizar esta API, tanto el sistema operativo que reside en la
máquina física o host, como el sistema operativo a virtualizar o guest, deben modificarse. La
figura 3 presenta un esquema de este tipo de virtualización, destacándose la API que debe tener
cada sistema operativo guest. Los roles del VMM y de las herramientas de administración
(Admin. Tools) son iguales a los expuestos en full-virtualización
Figura 2.3: Esquema de paravirtualización
La principal ventaja que tiene esta subclase es que provee de tiempos de respuesta mejores que
en el caso de las máquinas virtuales que se encuentran full-virtualizadas especialmente en
aquellas máquinas físicas que no cuentan con tecnologías que apoyan la virtualización. La
principal desventaja es que sólo admiten la ejecución de sistemas operativos de código abierto,
ya que solo estos pueden ser modificados a fin de tener la API de paravirtualización. Ejemplos
de herramientas de virtualización que pertenecen a esta subclase son: Xen [12] y Denali [23].
3. VENTAJAS DE LA VIRTUALIZACIÓN.
A continuación se abordarán las principales ventajas que ofrece la virtualización, profundizando
en cada una de ellas.
Modif.
Guest 1 Admin.
Tools
…
VMM
Hardware
Modif.
Guest 2
API API
22
3.1. CONSOLIDACIÓN DE SEVIDORES.
El concepto de consolidación de servidores [24] hace referencia a la utilización eficiente de los
recursos que ofrecen los servidores, apuntando a la disminución de la cantidad de servidores con
los que se ofrece un determinado conjunto de servicios.
Este concepto nace a raíz de estudios realizados por especialistas, tales como Tony Iams, quien
en [24] declara que “típicamente, los servidores trabajan entre un 15 a un 20% de su
capacidad”. Un ejemplo de esta situación se encuentra en [26], donde se reporta que la
utilización de CPU que puede llegar a tener un servicio como BIND DNS [25], es apenas del
10% [26]. Siendo esta una situación común, es fundamental utilizar herramientas que permitan
aprovechar los recursos de hardware disponibles.
Al permitir la ejecución de múltiples máquinas virtuales dentro de una máquina física, la técnica
de virtualización aporta a la reducción de servidores físicos necesarios para satisfacer los
requerimientos de servicios de información de las instituciones. Además de lo anterior, la
virtualización permite una mejor utilización de los recursos de hardware en los servidores, ya
que según estudios de empresas como VMware, la utilización de servidores puede aumentar del
rango entre 5 al 15% al rango de entre 60 al 80% [27], lo cual dependerá de la cantidad de
máquinas virtuales que se ejecuten dentro del servidor y de los servicios que estas máquinas
virtuales entreguen.
3.2. AHORROS
Otra de las ventajas que presenta la virtualización, son los ahorros económicos, de infraestructura
y de consumo de electricidad que se pueden generar tras su implementación.
Uno de los ahorros generados es el de hardware, ya que como se pudo entender del punto de
consolidación de servidores, uno de los fines es la reducción del hardware existente, lo que
conduce a una disminución en la adquisición de hardware por parte de las empresas e
instituciones. Según análisis tras los casos de estudios de empresas como VMware [27] y Citrix
[28], el ahorro en este ítem puede llegar a ser de un 50%, lo cual depende del tamaño del
proyecto.
23
Otro ahorro a considerar es el de infraestructura, el cual se desprende del ahorro en hardware
dado que al disminuir la cantidad de servidores en el datacenter de una empresa, se logra
disminuir el espacio necesario para tener estos servidores. Como resultado, disminuye el costo de
elementos relacionados con la infraestructura, como por ejemplo racks para mantener dichos
servidores y cableado necesario tanto para proporcionar electricidad a los servidores, como el
cableado de red.
Por otra parte, el ahorro de servidores implica también un ahorro en consumo de electricidad.
Según estimaciones obtenidas tras casos de estudios, empresas como VMware [27] aseguran que
el ahorro que se puede alcanzar en cuanto a consumo eléctrico puede llegar a ser de un 80%, lo
cual depende del tamaño del proyecto.
3.3. ADMINISTRACIÓN
La administración de plataformas también se ve beneficiada con la virtualización, ya que tal
como se mencionó en la introducción, una de las claves de esta técnica es que facilita la
administración de servidores.
Todas las herramientas de virtualización existentes, ya sean comerciales o de código abierto,
poseen programas especiales que facilitan la administración de las máquinas virtuales mediante
la administración de los recursos de hardware que se asignan a cada una de las máquinas
virtuales, la creación máquinas virtuales y el monitoreo de cada una de las máquinas virtuales
dentro de los servidores.
La administración de recursos de hardware determina cómo se asignan de los recursos de la
máquina física a cada una de las máquinas virtuales existentes dentro de un servidor. Esto es
importante al momento de la creación de cada máquina virtual, ya que se permite establecer los
requerimientos de hardware como cantidad de memoria RAM y cantidad de núcleos de CPU.
Además de esto, los parámetros pueden ser modificados, a fin de agregar más recursos a una
máquina virtual en particular.
La facilitación de la creación de las máquinas virtuales radica en la rapidez con que puede
llevarse a cabo esta tarea, ya que no tan solo se permite crear una máquina de la manera
convencional, es decir, instalando el sistema operativo y luego configurarlo, a fin de que preste
24
sus servicios, sino que también se permite manejar máquinas con configuración por omisión, las
que pueden ser utilizadas como modelo estándar para la creación de máquinas de manera más
rápida. La creación de máquinas en base a esta especie de máquina estándar se puede realizar
mediante técnicas de clonación de máquinas, las cuales en la actualidad son ofrecidas por gran
parte de las herramientas de virtualización existentes.
Finalmente, el monitoreo de máquinas virtuales comprende tareas como la actualización de
software y hardware de máquinas virtuales y el remplazo de máquinas virtuales. En el último
caso, sobre todo las máquinas que presten servicios críticos que no pueden dejar de ejecutarse.
En esta situación, el reemplazo puede realizarse de manera simple, dado que si se requiere retirar
alguna máquina virtual de funcionamiento, ya sea para actualización o revisión, basta con crear
otra máquina virtual con la misma configuración y dejarla en funcionamiento, reemplazando a la
que se actualizará o retirará. Esto evita problemas de continuidad de servicio, lo cual será crítico
en la medida de la importancia del servicio que la máquina virtual ofrezca.
Algunas de las herramientas de virtualización cuentan con interfaz gráfica, como Citrix
XenCenter [29] en XenServer, VMware vSphere [30] en VMware ESXi y Virtual Machine
Manager [32] en el caso de herramientas como Xen y KVM, o mediante línea de comando, como
virsh [31] en Xen y KVM.
3.4. INTEGRACIÓN DE HARDWARE.
Hasta este punto el enfoque parece considerar solamente un servidor y sus máquinas virtuales,
pero ¿qué sucede en el caso de que exista más de un servidor físico con máquinas virtuales? La
respuesta a esta pregunta es que la virtualización también permite integrar distintos servidores
físicos a fin de realizar tareas que permitan un mejor uso del hardware existente. Muchas
herramientas, tanto comerciales como código abierto, permiten integrar servidores, a fin de que
estos conformen una plataforma unificada, donde los recursos de cada servidor se encuentren
disponibles para las máquinas virtuales existentes dentro del sistema.
La principal funcionalidad que se destaca en el caso de la integración de servidores es la de la
migración de máquinas virtuales mientras se encuentran ejecutando. Esto es, cambiar una
máquina virtual de un servidor a otro mientras cumple sus funciones. Esta funcionalidad es muy
útil al momento de que sea necesario cambiar máquinas virtuales que ofrezcan servicios críticos,
25
de un servidor a otro, lo cual puede ser necesario en caso de requerir una mantención del servidor
físico que involucre desconectarlo, asegurando que los servicios seguirán en funcionamiento.
Gran parte de las herramientas de virtualización actuales, tanto las comerciales como XenServer
[33] y VMware ESXi [34], como las de código abierto como Xen [35] y KVM [36], ofrecen esta
funcionalidad.
3.5. TECNOLOGÍA VERDE.
Además de beneficios desde el punto de vista de tecnologías de la información, las implicancias
de la virtualización llegan a otras áreas, como por ejemplo el medio ambiente. Se reconoce a la
virtualización como una Tecnología Verde [37] (Green Computing o Green IT) dadas sus
características, que aportan a la eficiencia en la utilización de los recursos, lo cual minimiza el
impacto que pueden producir en el medio ambiente, a la reducción en el consumo de
electricidad, como se pudo apreciar anteriormente, lo cual también conduce a una reducción en la
emisión de dióxido de carbono al medio ambiente.
Según estimaciones de firmas como IDC [38], citadas en muchos estudios de impacto de la
virtualización en el medio ambiente [39], dice que cada servidor emite aproximadamente 4
toneladas de dióxido de carbono anuales al ambiente, lo cual es considerable al momento de
analizar si dentro de la empresa o institución existen servidores que se encuentran funcionando a
niveles menores del 20%, tal como se vio anteriormente, ya que se tienen potenciales
contaminantes, los cuales podrían ser reducidos tomando las medidas adecuadas. Es por esto que
tecnologías como la virtualización se hacen necesarias de implementar, ya sea en las empresas o
instituciones.
4. DESVENTAJAS DE LA VIRTUALIZACIÓN.
Como toda tecnología, la virtualización posee ciertas desventajas, las cuales apuntan a la
degradación de los servicios que una máquina virtual ofrece, comparado con los mismos
servicios que ofrecería una máquina física, la necesidad de redundancia y la necesidad de
hardware que permita llevar a cabo las tareas de virtualización.
26
4.1. DEGRADACIÓN DE SERVICIOS.
Esto se produce especialmente cuando se usa virtualización en servidores que no poseen
hardware con soporte para virtualización, tal como se mencionó en el punto de full-
virtualización. En este caso, se produce una gran sobrecarga en el administrador de máquinas
virtuales, dado que este proceso es el encargado de emular el hardware de cada máquina virtual.
Este problema se acentúa a medida que existan más máquinas virtuales dentro del servidor.
Se han hecho muchos estudios respecto a este tema [40] [41] y todos dan cuenta de que existe
una cierta demora en la realización de algunas tareas, como por ejemplo, escritura en disco.
Si bien existen soluciones que buscan mitigar este problema, como por ejemplo, hardware que
cuente con tecnología que facilite la virtualización, o la paravirtualización (recomendada en
casos de hardware sin soporte para virtualización), siempre existirá cierto nivel de degradación
en las máquinas virtuales.
5. RESUMEN.
En este capítulo se ha descrito el concepto de virtualización, a fin de que se puedan comprender
los aspectos más relevantes de la técnica de virtualización y su evolución histórica.
Además de esto, se han discutido tanto las ventajas como desventajas de esta técnica, las cuales
deben ser consideradas al momento de iniciar un proyecto de virtualización, lo cual será el tema
principal del próximo capítulo.
27
6. BIBLIOGRAFÍA.
[1] Credit-Based CPU Scheduler. [en línea]
<http://wiki.xensource.com/xenwiki/CreditScheduler> [consulta: 27 de diciembre de 2010].
[2] Completely Fair Scheduler – Wikipedia, the free encyclopedia. [en línea]
<http://en.wikipedia.org/wiki/Completely_Fair_Scheduler> [consulta: 27 de diciembre de 2010].
[3] Computer History – Ferranti Atlas Computer. [en línea]
<http://www.computinghistory.org.uk/det/1080/Ferranti-Atlas-Computer> [consulta: 29 de
diciembre de 2010].
[4] An Introduction to Virtualization – kernelthread.com [en línea]
<http://www.kernelthread.com/publications/virtualization/> [consulta: 29 de diciembre de 2010]
[5] IBM_M44/44X - Wikipedia, the free encyclopedia. [en línea]
<http://en.wikipedia.org/wiki/IBM_M44/44X> [consulta: 29 de diciembre de 2010].
[6] CP – 40 - Wikipedia, the free encyclopedia. [en línea] <http://en.wikipedia.org/wiki/ CP-40>
[consulta: 29 de diciembre de 2010].
[7] CP – 67 - Wikipedia, the free encyclopedia. [en línea] <http://en.wikipedia.org/wiki/ CP-67>
[consulta: 29 de diciembre de 2010].
[8] History of CP/CMS - Wikipedia, the free encyclopedia. [en línea]
<http://en.wikipedia.org/wiki/History_of_CP/CMS> [consulta: 29 de diciembre de 2010].
[9] VMware Site [en línea] <http://www.vmware.com/> [consulta: 29 de diciembre de 2010].
[10] Microsoft Virtualization Site [en línea] <http://www.microsoft.com/virtualization>
[consulta: 29 de diciembre de 2010].
[11] Citrix Systems Site [en línea] <http://www.citrix.com/> [consulta: 29 de diciembre de
2010].
[12] Xen Site [en línea] <http://www.xen.org/> [consulta: 29 de diciembre de 2010].
28
[13] Kernel-Based Virtual Machine Site [en línea] <http://www.linux-kvm.org/> [consulta: 29 de
diciembre de 2010].
[14] Open VZ Site [en línea] <http://openvz.org> [consulta: 29 de diciembre de 2010].
[15] Virtualization Technologies from Intel [en línea]
<http://www.intel.com/technology/virtualization/> [consulta: 30 de diciembre de 2010].
[16] Virtualization AMD Site [en línea] <http://sites.amd.com/us/business/it-
solutions/virtualization/Pages/virtualization.aspx> [consulta: 30 de diciembre de 2010].
[17] Jails – The FreeBSD Handbook [en línea]
<http://www.freebsd.org/doc/handbook/jails.html> [consulta: 30 de diciembre de 2010].
[18] System Administration Guide: Oracle Solaris 9 Containers [en línea]
<http://dlc.sun.com/pdf/820-4490/820-4490.pdf> [consulta: 30 de diciembre de 2010].
[19] Binary Translation – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Binary_translation> [consulta: 30 de diciembre de 2010].
[20] VMware vSphere Hypervisor (Based on VMware ESXi) – VMware [en línea]
<http://www.vmware.com/products/vsphere-hypervisor/> [consulta: 30 de enero de 2010].
[21] Citrix Xenserver – Citrix Systems [en línea]
<http://www.citrix.com/English/ps2/products/product.asp?contentID=683148&ntref=prod_top>
[consulta: 30 de diciembre de 2010].
[22] Application programming interface - Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Application_programming_interface> [consulta 30 de diciembre
de 2010]
[23] Denali Project [en línea] <http://denali.cs.washington.edu/> [consulta: 30 de diciembre de
2010].
[24] What is Server Consolidation? – SearchDataCenter.com [en línea]
<http://searchdatacenter.techtarget.com/definition/server-consolidation> [consulta: 3 de enero de
2011].
29
[25] INTERNET SYSTEM CONSORTIUM. BIND DNS. [en línea]
<http://www.isc.org/software/bind> [consulta: 3 de enero de 2011].
[26] ALBITZ, Paul y LIU, Cricket. DNS and BIND. 5ta Ed. 1005 Gravenstein Highway North,
Sebastopol, CA 95472, Estados Unidos, O’Reilly & Associates, 2006.
[27] How to WMware Right-size IT Infrastructure to Reduce Power Consumption – VMware [en
línea] <http://www.vmware.com/files/pdf/WhitePaper_ReducePowerConsumption.pdf>
[consulta: 4 de enero de 2011].
[28] Xenserver, How it helps – Citrix Systems [en línea]
<http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300355> [consulta: 4 de
enero de 2011].
[29] XenCenter, Xenserver – Citrix Community [en línea]
<http://community.citrix.com/display/xs/XenCenter> [consulta: 4 de enero de 2011]
[30] VMware vSphere – VMware [en línea] <http://www.vmware.com/products/vsphere/>
[consulta: 4 de enero de 2011].
[31] virsh manual page – Unix.com [en línea] <http://www.unix.com/man-page/All/1m/virsh/>
[consulta: 4 de enero de 2011].
[32] Virtual Machine Manager [en línea] <http://virt-manager.et.redhat.com/index.html>
[consulta: 4 de enero de 2011].
[33] VMware vMotion for Live Migration of Virtual Machines – VMware [en línea]
<http://www.vmware.com/products/vmotion/> [consulta: 5 de enero de 2011].
[34] Everything you always wanted to know about XenMotion – Citrix Community [en línea]
<http://community.citrix.com/pages/viewpage.action?pageId=18481296> [consulta: 5 de enero
de 2011].
[35] Live Migration of Virtual Machine – System Research Group, Computer Laboratory,
University of Cambridge [en línea] <http://www.cl.cam.ac.uk/research/srg/netos/papers/2005-
migration-nsdi-pre.pdf> [consulta: 5 de enero de 2011].
30
[36] Migration – KVM [en línea] <http://www.linux-kvm.org/page/Migration> [consulta: 5 de
enero de 2011].
[37] Green Computing – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Green_computing> [consulta: 5 de enero de 2011].
[38] IDC Home [en línea] <http://www.idc.com/> [consulta: 5 de enero de 2011].
[39] VMware Green IT Energy Efficiency - VMware [en ínea]
<http://www.vmware.com/virtualization/green-it/> [consulta: 5 de enero de 2011].
[40] Performance Evaluation of Virtualization Technologies for Server Consolidation –
Parallels.com [en línea]
<http://www.parallels.com/r/pdfs/partners/hp/performance_evaluation_of_vt_for_sc_hp_labs.pdf
> [consulta: 6 de enero de 2011]
[41] Quantifying the Performance Isolation Properties of Virtualization Systems – Clarkson
University [en línea]
<http://people.clarkson.edu/~jmatthew/publications/isolation_ExpCS_FINALSUBMISSION.pdf
> [consulta: 6 de enero de 2011].
31
Capítulo 3
ANÁLISIS DENTRO DE LA DIRECCIÓN CENTRAL DE SERVICIOS
COMPUTACIONALES (DCSC)
En este capítulo se analiza la situación actual de la Dirección Central de Servicios
Computacionales (DCSC), perteneciente a la Universidad Técnica Federico Santa María, desde
el punto de vista de los servicios que ésta ofrece. Posteriormente se definen los objetivos que la
DCSC se busca alcanzar tras la implementación de virtualización, contrastando esto con las
ventajas mencionadas en el capítulo anterior. A partir de este análisis y definición de objetivos,
se obtendrán una serie de requisitos base, los cuales se utilizarán al momento de seleccionar una
futura solución.
1. CONTEXTO ACTUAL DE LA DCSC.
La DCSC es la unidad encargada de administrar y ofrecer los recursos y los servicios
computacionales dentro de la universidad. Dentro de la variedad de recursos y servicios
ofrecidos, este trabajo se enfocará en los servidores con los que cuenta esta unidad y los servicios
que estos ofrecen, entre los que se destacan los servidores web, los servidores LDAP (Light
Directory Access Protocol) [1] y los servidores DNS (Domain Name System) [2]. Estos
servidores son la base de los servicios internos que presta la universidad, tales como el Sistema
de Información y Gestión Académica (SIGA) [3], Aula Virtual [4], y sitios web como el
perteneciente a la universidad [5].
Uno de los problemas reportados dentro de esta unidad se encuentra el de la baja utilización por
parte de algunos servidores, especialmente los que ejecutan servicios LDAP, DNS y web. En la
actualidad, algunos de estos servicios se ejecutan en computadores Dell OptiPlex GX280 [6], los
cuales no son aprovechados en su totalidad respecto de su poder de cómputo. Además, estos
computadores ocupan recursos, tales como las UPS (Uninterruptible Power Supply) [7], las
cuales podrían ofrecer una mayor autonomía a los servidores, frente a cortes de electricidad, si se
pudiera eliminar estos computadores.
Dadas las ventajas que ofrece la virtualización (analizadas en el capítulo anterior), la DCSC ha
decidido realizar un estudio de factibilidad de implementación de dicha técnica. Para esto, en el
32
marco de este trabajo de título se investigará y evaluará, mediante pruebas experimentales, la
factibilidad y beneficios de implementar virtualización. Para las investigaciones se evaluarán
varias herramientas disponibles en la actualidad, tanto de código abierto como licenciadas, a fin
de elegir una solución que satisfaga los requerimientos planteados por esta unidad.
2. OBJETIVOS TRAS LA IMPLEMENTACIÓN DE VIRTUALIZACIÓN.
Los objetivos que la DCSC busca alcanzar con la virtualización son los siguientes:
Ejecutar diversos sistemas operativos (Windows, Unix y Linux) dentro de una misma
máquina. A fin de ofrecer servicios que consuman pocos recursos de hardware (no mayor
a 20%), independiente del sistema operativo en el cual se ejecute.
Facilitar la administración de los servidores. A fin de que tareas como retiro de servidores
para actualización, creación y modificación de nuevos servidores sean tareas más
simples, tal como se expuso en la sección 3.3 del capítulo 2.
Conseguir integración de hardware. Conseguir una herramienta que permita administrar
múltiples servidores físicos ejecutando máquinas virtuales, a fin de ofrecer una mejor
calidad de servicio.
A continuación se profundizaran estos objetivos, relacionándolos con las ventajas presentadas en
la sección 3 del capítulo 2.
2.1. EJECUCCIÓN DE DIVERSOS SISTEMAS OPERATIVOS DENTRO DE UNA
MISMA MÁQUINA.
Como primer requerimiento se tiene que la solución propuesta debe permitir la ejecución de
varias máquinas virtuales dentro de una misma máquina física. En este caso, cada máquina
virtual será considerada como un servidor virtual. Cada servidor virtual podrá contar con su
sistema operativo, el cual podrá ser Microsoft Windows [8] (XP, Server 2003 y Server 2008),
sistemas operativos basados en BSD Unix como FreeBSD [9] y/o distribuciones Linux tales
como CentOS [10] y Ubuntu [11], a fin de ejecutar servicios independiente del sistema operativo
que se requiera. Es por esta razón que se requiere una plataforma que permita ejecutar servidores
virtuales con alguno estos sistemas operativos.
33
Dentro de los tipos de virtualización analizados en el capítulo anterior, se hizo mención tanto a la
virtualización tanto a nivel de sistema operativo como la virtualización a nivel de hardware. La
primera es una buena solución cuando se tiene una plataforma conformada con máquinas que
utilicen sistemas operativos con un mismo núcleo, como lo sería el caso de que se utilizaran
máquinas con distribuciones Linux. La segunda, permite crear máquinas independientes, cada
una con su propio hardware. Este enfoque hace posible la ejecución de máquinas con sistemas
operativos independientes del sistema operativo base del sistema, por ende, la solución debe
considerar este tipo de virtualización (virtualización a nivel de hardware).
Como se describe en la sección 2.2 del capítulo 2, la virtualización a nivel de hardware se
clasifica en dos subtipos: la paravirtualización y la full-virtualización.
La paravirtualización requiere de sistemas operativos con modificaciones que los hagan
compatibles con la técnica de virtualización, lo cual no es un problema en el caso de sistemas
operativos Linux y los de tipo BSD Unix, como FreeBSD, en los cuales ya se han incluido estas
modificaciones o bien, es posible intervenirlos al ser de código abierto. Sin embargo, en el caso
de sistemas operativos con código fuente cerrado, como Microsoft Windows, esto no se puede
realizar. Por lo tanto, con este tipo de sistema operativo la paravirtualización no es factible aún.
Por otra parte, la full-virtualización cuenta con el hecho de que no necesita modificar el sistema
operativo del servidor virtual. Esto presenta una ventaja al momento de desarrollar una
plataforma con sistemas operativos distintos. Adicionalmente, el hecho de contar con hardware
que ofrece soporte para virtualización (En este caso se cuenta con un procesador Intel modelo
E5310 [12], con tecnología Intel VT-x [13]), lo cual hace considerar herramientas que contengan
full-virtualización como una solución.
2.2. ADMINISTRACIÓN DE SERVIDORES.
Otro de los requerimientos planteados, es el de conseguir una plataforma simple de administrar.
Esto implica considerar una serie de tareas o rutinas comunes a la administración de servidores,
tales como la creación rápida de servidores, el monitoreo centralizado de los servidores, la
modificación de recursos asignados a los servidores, el inicio automático de las máquinas
virtuales junto con el inicio de la máquina física y la migración de máquinas físicas a máquinas
virtuales (proceso conocido como P2V).
34
Actualmente, la DCSC debe poner a punto los equipos dentro del datacenter o en la oficina de
quien se encuentra a cargo, para luego instalarlos en el datacenter. Una situación similar sucede
cuando se deben actualizar el sistema operativo o el servicio ejecutado en un servidor, donde
además de realizar esta operación, se debe considerar configurar la redundancia del servicio en
caso de que se trate de uno crítico. En resumen, se tornan tareas engorrosas, las cuales requieren
de solución.
Tal como se presentó en el punto 3.3 del capítulo 2, una de las ventajas de la virtualización es la
simplificación de la administración de las máquinas virtuales, dado que la mayoría de las
herramientas disponibles poseen programas, ya sean con interfaz gráfica o mediante línea de
comando, que hacen más sencilla las tareas de creación, monitoreo, modificación, inicio y
migración de las distintas máquinas virtuales alojadas en una máquina física. De esta manera, es
importante que una futura solución considere la inclusión de herramientas de virtualización que
cuente con este tipo de programas, teniendo en cuenta cuántas de las tareas descritas
anteriormente son posibles de realizar y cuán sencilla es la realización de estas tareas.
En la tarea de creación de una máquina virtual un parámetro importante a considerar es el tiempo
que toma, desde la asignación de recursos de hardware por primera vez a una máquina virtual y
la instalación de su sistema operativo hasta que se ejecuta por primera vez. Además de esto, en la
tarea de crear una máquina virtual debe existir la opción de crear máquinas virtuales en base a
una ya existente. Esto se realiza mediante la clonación de máquinas virtuales, lo que facilita
significativamente la creación de una máquina virtual de similares características a alguna de las
ya existentes.
La tarea de monitoreo necesita que el programa de administración entregue información acerca
del estado de los recursos más importantes (e.g. utilización de disco, RAM, CPU y dispositivos
de red) de cada una de las máquinas virtuales y de la máquina física, a fin de comprender lo que
sucede en cada momento dentro de la plataforma y detectar posibles fallas de manera rápida.
La funcionalidad de modificación de recursos de una máquina debe permitir cambiar la
asignación de los recursos de hardware (disco duro, CPU, RAM y dispositivos de red) a cada
máquina y, en lo posible, sin detener la máquina virtual a modificar.
35
Es fundamental que la herramienta de administración permita el inicio automático de máquinas
virtuales al iniciar el servidor o máquina física, ya que esto disminuye los tiempos en los que las
máquinas virtuales pueden recuperar su funcionalidad.
Finalmente, la tarea de migración de máquinas físicas a virtuales (P2V), es muy útil en la
creación de máquinas virtuales con servicios complejos de configurar, pero que ya están
operativos en una máquina física. En ese caso, la migración automática de dicho servicio a una
máquina virtual simplifica significativamente la tarea del administrador.
En resumen, la solución propuesta debe contar con una herramienta de administración que
incluya las funcionalidades que permitan realizar las tareas recién descritas, con la posible
excepción de la migración de máquina física a virtual, para la cual se buscarán alternativas si es
que la herramienta de administración seleccionada no la considerara.
2.3. INTEGRACIÓN DE HARDWARE.
Un tercer requerimiento consiste en la integración de los servidores físicos en una única
plataforma de hardware. De esta manera, no sólo se obtienen ahorros en costos de máquinas
físicas sino que también se aspira a ofrecer servicios con redundancia, lo cual es necesario en
caso de servidores que ejecuten servicios críticos que requieren alta disponibilidad.
Una ventaja adicional de la redundancia que se obtiene con la integración de servidores es que al
contar con una granja (i.e. al menos dos servidores físicos) la tarea de migrar máquinas virtuales
entre máquinas físicas, así como las tareas de actualización, reparación, o modificación de
servicios y servidores físicos pueden realizarse sin necesidad de detener la operación de los
servicios.
Más que una problemática, lo que busca la DSCS es aprovechar el hecho de que se cuenta con
servidores que poseen hardware compatible con estos fines, de manera de utilizar sus
capacidades de una mejor forma que la actual.
36
3. REQUERIMIENTOS Y RESTRICCIONES.
Descritas las necesidades funcionales por parte de la DCSC, en esta sección se creará una tabla
resumen con los requerimientos base y las restricciones presupuestarias y de tecnologías que
deben considerarse en la generación de la solución final.
3.1. EJECUCIÓN DE DIVERSOS SISTEMAS OPERATIVOS DENTRO DE UNA MISMA
MÁQUINA.
Los sistemas operativos que se requieren que sean soportados tanto por las máquinas físicas
como las virtuales son:
Sistemas operativos host 1 a utilizar. Determinar si la herramienta tiene su propio sistema
operativo o si es necesario instalar uno previamente.
Sistemas operativos guest 2 soportados. Se requiere que exista soporte para sistemas
operativos Microsoft Windows (XP, Server 2003 y Server 2008), Unix BSD (FreeBSD) y
Linux (principalmente para CentOS y Ubuntu).
3.2. ADMINISTRACIÓN DE SERVIDORES.
Las funcionalidades requeridas en términos de la administración de servidores son las siguientes:
Software de monitoreo y gestión. Se requiere que la herramienta cuente con un software
con interfaz gráfica, por sobre una con software vía línea de comando, dadas las
facilidades de uso que presenta el primero.
Asignación de recursos al guest.
Clonación de máquinas virtuales.
Iniciar máquinas virtuales automáticamente al iniciar el host.
Migración de máquina física a máquina virtual (P2V).
1Corresponde al sistema operativo base que necesita el administrador de máquinas virtuales (VMM) para su
funcionamiento (Ver cap. 2 punto 1.1) 2 Sistemas operativos para las máquinas virtuales (Ver cap.2 punto 1.1)
37
3.3. INTEGRACIÓN DE HARDWARE.
Migración de máquinas virtuales entre servidores físicos, sin necesidad de detenerla.
3.4. RESTRICCIONES.
Además de los requerimientos recién listados, la DCSC tiene restricciones respecto del
equipamiento de hardware disponible para implementar la virtualización así como el presupuesto
a disposición. Estas restricciones son:
Máxima RAM soportada para el host. Que la herramienta permita trabajar con la mayor
cantidad de RAM posible (de preferencia sobre 32 GB)
Máxima cantidad de núcleos que se pueden asignar a los guest. Que la herramienta
permita asignar la mayor cantidad de núcleos a las máquinas virtuales.
Precio (en el caso de herramientas pagadas). Si bien no existe un presupuesto formal en
este caso, el fin es encontrar una herramienta que ofrezca la mayor cantidad de
funcionalidades al menor costo posible
La tabla resumen de los requerimientos y restricciones es la siguiente:
Requerimientos y restricciones solución final Solución analizada
Req
uerim
ient
os
Sistema operativo hostSistema operativo guestSoftware de monitoreo y gestiónAsignación de recursos al guestClonación de máquinas virtualesIniciar máquinas virtuales automáticamente al iniciar el hostMigración de máquina física a máquina virtual (P2V)Migración de máquinas virtuales entre servidores físicos, sin necesidad de detenerla
Res
tricc
ion
es
Máxima RAM soportada por el hostMáximo número de núcleos que se pueden asignar a los guestPrecio.
Tabla 3.1: Tabla de requerimientos y restricciones para las herramientas a analizar.
Por cada herramienta a analizar en el capítulo 4, se completará una tabla similar.
38
4. RESUMEN.
En este capítulo se presentaron los problemas presentes en la actualidad con la actual
configuración de servidores de la DCSC, los objetivos que se desean alcanzar mediante la
implementación de la técnica de virtualización y las restricciones impuestas en la solución. A
partir de esta información se ha obtenido una lista de requerimientos base con los que debe
cumplir la solución final.
En el siguiente capítulo se estudian diferentes alternativas de solución.
39
5. BIBLIOGRAFÍA.
[1] LDAP – Wikipedia, the free encyclopedia. [en línea] <http://en.wikipedia.org/wiki/LDAP>
[consulta: 02 de abril de 2011].
[2] INTERNET SYSTEM CONSORTIUM. BIND DNS. [en línea]
<http://www.isc.org/software/bind> [consulta: 02 de abril de 2011].
[3] Portal de Sistema de Gestión Académica [en línea] <https://www.siga.usm.cl/pag/> [consulta
02 de abril de 2011]
[4] Alua – USM [en línea] <http://www.aula.usm.cl/> [consulta: 02 de abril de 2011]
[5] Universidad Técnica Federico Santa María [en línea] <http://www.usm.cl/> [consulta: 02 de
abril de 2011]
[6] Dell OptiPlex GX280 [en línea]
<http://www.dell.com/html/us/products/optiplex/GX280_3d_model.html> [consulta: 02 de abril
de 2011]
[7] Uninterruptible Power Supply [en línea]
<http://en.wikipedia.org/wiki/Uninterruptible_power_supply> [consulta: 02 de abril de 2011].
[8] Microsoft Corporation Web Site [en línea] <http://www.microsoft.com/en/us/default.aspx>
[consulta: 18 de febrero de 2011].
[9] The FreeBSD Project [en línea] <http://www.freebsd.org/> [consulta: 02 de abril de 2011]
[10] www.centos.org – The Community ENTerprise Operating System [en línea]
<http://www.centos.org/> [consulta: 02 de abil de 2011].
[11] Ubuntu Homepage [en línea] <http://www.ubuntu.com/> [consulta: 02 de abril de 2011].
[12] Intel Xeon Processor E5310 [en línea]
<http://ark.intel.com/Product.aspx?id=28030&processor=E5310&spec-
codes=SL9XR,SLACB,SLAEM > [consulta: 02 de abril de 2011]
40
[13] Virtualization Technologies from Intel [en linea]
<http://www.intel.com/technology/virtualization/> [consulta: 02 de abril de 2011].
41
Capítulo 4
ANÁLISIS DE HERRAMIENTAS DE VIRTUALIZACIÓN
En este capítulo se reporta el estudio de las herramientas de virtualización más utilizadas en la
actualidad. Cada una de ellas se analizará desde la perspectiva de los requerimientos y
restricciones descritas en el capítulo 3. El estudio incluye tanto herramientas propietarias como
herramientas de código abierto. Para el análisis de estas primeras, se dispondrá de la utilización
de las versiones gratuitas que las empresas desarrolladoras de estas han dispuesto para este fin
además de considerar las licencias, en cuanto a funcionalidades ofrecidas y costos de licencias.
Por su parte, las segundas se analizarán mediante la su implementación. Además, por cada
herramienta se confeccionará una tabla, como la presentada al final del capítulo 3, donde se
listan los requerimientos y restricciones de la DCSC y si la herramienta cumple o no con cada
uno de ellos.
1. HERRAMIENTAS.
En la actualidad existe una variada gama de herramientas de virtualización disponibles en el
mercado. Dentro de esta variedad, existen herramientas propietarias, las cuales gozan de gran
popularidad entre las empresas. Este tipo de herramientas ofrece una gran cantidad de
funcionalidades, dependiendo del tipo de licencia que se adquiera con la empresa desarrolladora
de la herramienta. Por otra parte, existen herramientas de código abierto, las cuales están
disponibles para su uso gratuito por parte de quién desee utilizarlas. En términos de
funcionalidades ofrecidas, la gran mayoría se encuentra a la par con las ofrecidas por las
herramientas propietarias y su uso se da mayoritariamente en instituciones académicas y de
investigación, además de pequeñas empresas.
1.1. HERRAMIENTAS PROPIETARIAS.
En este estudio se consideraron las dos herramientas más populares existentes en la actualidad,
las cuales son VMware vShpere [1] y Citrix Xenserver [2]. Además de ser las más populares,
estas herramientas ofrecen versiones gratuitas que ofrecen una serie de funcionalidades básicas,
con el fin de promocionar sus ventajas como herramienta de virtualización. Dependiendo del
42
costo que se pague por la licencia, estas herramientas ofrecen funcionalidades adicionales a las
de la versión gratuita.
1.1.1. VMWARE VSPHERE.
VMware vSphere ha sido desarrollada por VMware [3], la empresa de virtualización más
importante y con mayor presencia en el mercado [4]. Esta herramienta consta de un sistema
operativo liviano, basado en POSIX [5], el cual contiene el administrador de máquinas virtuales,
que se instala en el servidor físico. Además de esto, la herramienta cuenta con un software de
monitoreo remoto llamado vSphere Client, el cual se instala en un computador distinto al
servidor físico, quien juega el rol de cliente. Este modelo tiene la ventaja de que todo el
procesamiento de la información entregada por el servidor físico la realiza este cliente, dejando
al servidor las tareas ligadas a la virtualización y al cliente la de interpretar información, como
un monitor. Además del monitoreo, todas las ordenes de administración se pueden ejecutar desde
este cliente (creación y actualización de máquinas virtuales, etc.)
Además de este cliente, VMware vSphere ofrece una interfaz web de monitoreo del servidor, el
cuál se ejecuta dentro del servidor físico y se acede via navegador web. Cabe destacar que en
este caso se considerará el cliente remoto, dada las razones expuestas anteriormente.
La figura 1 muestra la arquitectura básica de VMware vSphere, que corresponde a la versión
gratuita de esta herramienta.
Figura 4.1: Arquitectura de funcionamiento de VMware vSphere3
3Hecho en base a referencia: http://www.101datasolutions.co.uk/wp-content/uploads/2008/07/vmware-esxi.gif
Hardware servidor
MV1 MV2
VMware vShpere (ESXi)
Hardware cliente
Sistema operativo
vSphere Client
43
En la figura se distinguen los siguientes componentes:
Servidor (izquierda): Es donde reside la herramienta de virtualización. VMware vSphere
es la capa que realiza las tareas de administrador de máquinas virtuales (ver capítulo,
figura). Esta capa consta del sistema operativo propio, basado en POSIX y el conjunto de
herramientas desarrolladas por VMware (las cuales se detallarán a continuación). Sobre
esto, se encuentran las máquinas virtuales.
Cliente (derecha): Es donde reside la herramienta de monitoreo y administración. La
arquitectura corresponde a cualquier programa que se instala en un computador de
escritorio, la cual se ejecuta sobre el sistema operativo que posea dicho computador.
La comunicación entre el servidor y la herramienta de monitoreo y administración se realiza
sobre red.
La tabla 1 resume las funcionalidades de las distintas licencias de VMware vSphere. La tabla se
construyó en base a la información que la empresa desarrolladora tiene disponible en [6] y [7].
44
Versión Gratuita
Versión Estándar
Versión Avanzada
Versión Empresarial
Versión Empr. Plus
Hardware
Memoria máxima
para el servidor físico 256 [GB] 256 [GB] 256 [GB] 256 [GB]
No hay
limite
Núcleos por
procesador 6 6 12 6 12
Licencia
No hay límite
por servidor
físico
1 CPU 1 CPU 1 CPU 1 CPU
Funcionalidad
Thin Provisioning X X X X X
Update Manager X X X X
Data Recovery X X X X
High Availability X X X X
vMotion X X X X
vStorage APIs for
Data Production X X X X
Virtual Serial Port
Concentrator X X X
Hot Add X X X
vSheld Zones X X X
Fault Tolerance X X X
vStorage APIs for
Array Integration X X
vStorage APIs for
Multipathing X X
Storage vMotion X X
Distributed Resources
Scheduler (DRS),
Distributed Power
Management (DPM)
X X
Storage I/O Control X
Network I/O Control X
Distributed Switch X
Host Profiles X
Costo de la Licencia
(USD) 0
Desde 1268
a 1818,65
Desde 2717
a 3675,55
Desde 3479
a 4708,45
Desde 4229
a 5723,70
Tabla 4.1: Detalle de cada una de las distintas versiones de VMware vSphere.
A modo de aclaración, se considera el valor memoria RAM máxima por servidor a modo de
dimensionar una cantidad máxima de máquinas virtuales a ejecutar dentro del servidor. Por su
parte, el licenciamiento de las versiones de vSphere se considera por CPU física, indistinto de la
45
cantidad de núcleos que posea, a diferencia de la versión gratuita, donde la licencia se entrega
por servidor. Finalmente, los valores de licencias están en el rango desde la de menor precio (con
1 año de soporte básico) y la de mayor precio (con 3 años de soporte en producción)
El significado de las filas que describen funcionalidad es el siguiente:
Thin Provisioning [8] se encarga de optimizar el uso de espacio mediante asignación
dinámica de tamaño a los discos virtuales de las máquinas virtuales
Update Manager [9] se encarga de las actualizaciones de software, tanto de los hosts
como de los guests
Data Recovery [10] y vStorage APIs for Data Protection [11], son funcionalidades para
respaldos de información
High Availability [12] y Fault Tolerance [13] permiten el monitoreo y detección de fallas
en servidores físicos para ofrecer alta disponibilidad
vMotion [14] y Storage vMotion [15] permiten migración de máquinas y discos virtuales
mientras están en funcionamiento
Virtual Serial Port Concentrator para monitoreo de los servidores vía puerto serial
Hot Add que da la posibilidad de agregar hardware a las máquinas virtuales mientras
están en funcionamiento
vShield Zones [16] permite la separación de máquinas virtuales en zonas de seguridad, lo
cual es muy útil para separar ambientes, en caso de tener máquinas que están en etapas de
prueba (o de testing) y otras que ya prestan funcionalidades (o en etapa de producción).
vStorage APIs for Array Integration [17] y vStorage APIs for Multipathing que mejoran
el rendimiento de los arreglos de discos
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM) [18],
Storage I/O Control [19] y Network I/O Control [20] optimizan y balancean la asignación
de recursos de hardware
46
Distributed Switch [21] y Host Profiles [22] ayudan en la administración de los
servidores
Además de las licencias presentadas anteriormente, existe otro tipo de licenciamiento [6], el cual
está orientado a empresas pequeñas. La tabla 2 resume estas opciones.
Versión Essentials Versión Essentials PlusHardwareMemoria máxima para el servidor físico 256 [GB] 256 [GB]
Núcleos por procesador 6 6
Licencia 3 servidores con hasta 2 procesadores cada uno
3 servidores con hasta 2 procesadores cada uno
FuncionalidadThin Provisioning X XUpdate Manager X XData Recovery XHigh Availability XvMotion XvStorage APIs for Data Production X X
Costo (USD) 611 Desde 4229 a 5723,70
Tabla 4.2: Detalle de las versiones de VMware vSphere para pequeñas y medianas empresas.
La tabla 3 muestra el resultado del análisis, en base a los requerimientos y restricciones
planteados en el capítulo 3, de 4 versiones de esta herramienta: la versión gratuita, la versión
Essential Plus, la versión estándar y la versión empresarial. Se seleccionó estas versiones dadas
las funcionalidades, las que representan opciones a considerar por parte de la unidad.
47
Criterio/Versión Gratuita Essential Plus Estándar EmpresarialSistema Operativo Host soportados Propio Propio Propio Propio
Sist. Operativos Guest soportados
FreeBSD X X X XLinux X X X XWindows (XP/Vista/7) X X X X
Windows Server (2003, 2008) X X X X
Migración de M.V. sin detener operación No Si Si Si
Migración de máquina física a máquina virtual (P2V)
Si Si Si Si
SW de monitoreo y gestión
vSphere Client vSphere Client vSphere Client vSphere Client
Clonación de M.V. Si (detenida) Si Si SiAsignación de recursos de hardware a M.V. Si (detenida) Si (detenida) Si (detenida) Si
Máxima RAM del Host 256 [GB] 256 [GB] 256 [GB] Ilimitado
Máxima RAM del Guest
Depende del S.O. (32 o 64 bits)
Depende delS.O. (32 o 64 bits)
Depende del S.O. (32 o 64 bits)
Depende del S.O. (32 o 64 bits)
Núcleos Soportados para el Host
No hay límite por servidor físico
2 procesadores con 6 núcleos
1 procesadores con 6 núcleos
64 Procesadores de hasta 6 núcleos
Núcleos asignables al Guest 6 6 6 6
Iniciar M.V. al iniciar host Si Si Si Si
Precio (USD) 0 Desde 4229 a 5723,70
Desde 1268 a 1818,65
Desde 4229 a 5723,70
Tabla 4.3: Análisis de funcionalidades de VMware vSphere según requerimientos y restricciones de la DCSC
Para aclarar la tabla 3, en primer lugar que el sistema operativo host sea propio está relacionado
con que no es necesario instalar un sistema operativo base, ya que la herramienta viene sobre uno
(ver inicio del tema), a diferencia de otras herramientas que se verán más adelante. Por otra
parte, la casilla de máxima RAM asignable al guest dependerá del sistema operativo que se
utilice, si es uno de 32 bits como máximo se podrán asignar 4 GB de RAM y en el caso de
48
sistemas operativos de 64 bits, la asignación será mayor, pero dependerá del sistema operativo
que instalado.
De la tabla 3 es posible apreciar que todas las opciones, exceptuando a la gratuita, satisfacen lo
requerimientos y restricciones planteados, por lo que representan opciones para la unidad, siendo
la versión estándar y la Essential Plus las que más se acomodan, dadas las funcionalidades
ofrecidas, que son iguales. La limitante es respecto del costo de licencias, ya que al ser una etapa
de prueba inicial, no se tiene mucha noción de la cantidad de servidores a involucrar en el
proyecto final, lo cual sería interesante, sobre todo si se considera que la versión Essential Plus y
la estándar tienen diferencias de precio, considerando los servidores y las CPU a utilizar.
1.1.2. CITRIX XENSERVER.
Esta herramienta está basada en la herramienta de código abierto Xen [23] (la cual se verá en la
sección 1.2.1, de herramientas de código abierto). Sus orígenes se remontan al año 2007, cuando
la empresa Citrix Systems [24] adquiere XenSource, Inc., y comienza el desarrollo de una línea
de herramientas propietarias, las cuales se han masificado a tal punto que en la actualidad Citrix
XenServer se encuentra posicionada como la tercera herramienta de virtualización en el mercado
[4].
Al igual que vSphere, Citrix XenServer consta de un sistema operativo liviano, basado en una
versión de Linux y de un software de monitoreo y gestión, llamado Citrix XenCenter [25]. Este
último al igual que vSphere Client, se instala en un computador remoto, el cual hace las veces de
cliente. Esta herramienta de monitoreo y gestión cumple además la función de realizar la
migración de máquina física a virtual.
En cuanto a arquitectura, esta herramienta posee una estructura igual a la de vSphere, la que se
muestra en la figura 2.
49
Figura 4.2: Arquitectura de funcionamiento de Citrix XenServer4.
Existen 4 versiones de Citrix XenServer: la versión gratuita, la versión avanzada, la versión
empresarial y la versión platino, las cuales varían según costo de adquisición y funcionalidades
ofrecidas, tal como se puede apreciar en la tabla 3 [26].
4 Hecho en base a referencia: http://www.cyberco.net/1/index.php?option=com_content&view=article&id=91:citrix-
xen-server&catid=47:virtualisation&Itemid=75
Hardware servidor
MV1 MV2
Citrix XenServer
Hardware cliente
Sistema operativo
XenCenter XenCenter
50
Funcionalidad Ver. Gratuita
Ver. Avanzada
Ver. Empresarial
Ver. Platino
XenServer Hypervisor X X X X
IntelliCache X X X X
Resilient distributed management
architecture. X X X X
VM disk snapshot and revert X X X X
XenCenter management X X X X
Conversion tools X X X X
XenMotion live migration X X X X
Distributed virtual switching X X X
Heterogeneous pools X X X
High availability X X X
Memory optimization X X X
Performance alerting & reporting X X X
Dynamic workload balance X X
Host power management X X
Live memory snapshot and revert X X
Provisioning services (virtual) X X
Role-based administration X X
StorageLink X X
Web self-service with delegated
administration X X
Automated VM protection and recovery X
Lab manager with self-service portal X
Provisioning services (physical) X
Site recovery X
Costo por servidor (USD) 0.- 1000.- 2500.- 5000.-
Tabla 4.4: Detalle de las distintas versiones de Citrix XenServer
Las funcionalidades presentadas en la tabla 4 se pueden agrupar según su orientación. Es así
como existen las orientadas a la administración de las máquinas virtuales (como Resilient
distributed management architecture, VM disk snapshot and revert, XenCenter management,
Distributed virtual switching, Performance alerting & reporting, Live memory snapshot and
revert, Role-based administration y Web self-service with delegated administration), otras
orientadas a la administración de recursos de hardware (como IntelliCache, Heterogeneous
pools, Memory optimization y Host power management), a entregar alta disponibilidad (como
High availability, Dynamic workload balance y Automated VM protection and recovery),
además de una herramienta para conversión de máquinas físicas a virtuales (Conversion tools) y
una herramienta para migrar máquinas virtuales en ejecución (XenMotion live migration).
51
De manera análoga a la tabla 3, la tabla 5 muestra qué versiones cumplen con cuáles de los
requerimientos y restricciones planteados en el Capítulo 3.
Criterio/Versión Gratuita Avanzada Empresarial PlatinoSistema operativo host Propio Propio Propio PropioSist. operativos guest soportados
FreeBSD X X X XLinux X X X XWindows (XP/Vista/7) X X X X
Windows Server (2003, 2008) X X X X
Mover M.V. mientrasestá en funcionamiento Si Si Si Si
Migración de máquina física a máquina virtual (P2V)
Si Si Si Si
SW de monitoreo y gestón XenCenter XenCenter XenCenter XenCenter
Clonación de M.V. Si (detenida) Si (detenida) Si SiAsignación de recursos de hardware a M.V. Si (detenida) Si (detenida) Si Si
Máxima RAM host 512 [GB] 512 [GB] 512 [GB] 512 [GB]
Máxima RAM guestDepende del S.O. (32 o 64 bits)
Depende del S.O. (32 o 64 bits)
Depende del S.O. (32 o 64 bits)
Depende del S.O. (32 o 64 bits)
Núcleos soportados host
64procesadores lógicos5
64 procesadores lógicos
64 procesadores lógicos
64 procesadores lógicos
Núcleos asignables al guest 8 8 8 8
Iniciar M.V. al iniciar host Si Si Si Si
Precio (USD) 0.- 1000.- 2500.- 5000.-
Tabla 4.5: Análisis de funcionalidades de Citrix XenServer según requerimientos y restricciones de la DCSC
Se aprecia que todas las versiones de XenServer cumplen con los requerimientos y restricciones
propuestas por la DCSC. De estas versiones, la versión gratuita es la que más conviene en este
caso, dado que las funcionalidades ofrecidas son suficientes.
5 Distinto a núcleo, ya que este último puede tener más de un procesador lógico. En la version 5.5 de Citrix XenServer, se especifican, como máximo 32 un procesador con núcleos
52
1.2. HERRAMIENTAS DE CÓDIGO ABIERTO.
De la misma forma que se presentó en el caso de las herramientas propietarias, en esta sección se
analizarán herramientas de código abierto. Estas herramientas se encuentran disponibles de
manera gratuita, ya sea para utilizarlas en ambientes donde se requiera de herramientas con
buenas funcionalidades y sin la necesidad de invertir en licencias o bien para investigar y
desarrollar nuevas funcionalidades mediante la intervención directa del código.
Se analizarán 3 herramientas: Xen [23], que es una de las pioneras en el ámbito de herramientas
de virtualización de código abierto, KVM [28], que es una de las herramientas de virtualización
que está tomando más fuerza y Proxmox Virtual Environment [29], una herramienta reciente que
está basada en KVM y OpenVZ [30]. El último caso es un muy buen ejemplo del desarrollo de
nuevas funcionalidades en el ámbito de código abierto.
1.2.1. XEN.
Xen es una herramienta de virtualización de código abierto desarrollada por un grupo de
investigación en sistemas de la Universidad de Cambridge [31], quienes luego fundaron
XenSocurce, Inc. Esta herramienta fue lanzada en 2003 y pese a que en 2007 fue adquirida por
Citrix Systems, el proyecto original aún se mantiene gracias al apoyo de Citrix y de una
comunidad de desarrolladores, que se encarga de la actualización [32]. Xen se distribuye
mediante licencia GNU General Public License (GPLv2) [33].
A diferencia de las herramientas propietarias analizadas anteriormente, las cuales sólo trabajan
con arquitecturas de procesadores x86 de 64 bits, esta herramienta funciona además con
arquitecturas de procesadores x86 de 32 bits, Itanium [34] y ARM [35] entre otras.
El sistema operativo base que utiliza Xen puede ser cualquiera de las distribuciones de Linux
descritas en [36]. A diferencia de otras herramientas basadas en Linux (como KVM, que se
describe en la sección 1.2.2), la instalación de Xen requiere de un kernel de Linux modificado, el
cual posee la API de paravirtualización. La herramienta también permite full-virtualización.
53
Figura 4.3: Arquitectura de Xen6
En la figura 3 se presenta la arquitectura de esta herramienta. A diferencia de lo visto con las
herramientas propietarias, en el lado del cliente existen diversas opciones de herramientas de
administración, una conexión vía protocolo SSH [37] al host, utilizando herramientas de
administración de línea de comando, como virsh [38] o combinando SSH con despliegue de
gráficos (SSH+X11 [39]) o incluso instalando aplicaciones gráficas como Virtual Machine
Manager [40] (conocido también como virt-manager), la cual puede ser instalada tanto en el
servidor y ejecutarse desde el cliente con SSH+X11 o en el mismo cliente.
Dentro de las funcionalidades ofrecidas por Xen se encuentran: ejecución en modo full-
virtualización o paravirtualización, migración de máquinas virtuales sin detener su operación y
migración de máquina física a virtual (P2V). En este último caso, si bien existen opciones
formales para realizar esta tarea, como la herramienta virt-p2v [41], estas ya se encuentran
descontinuadas, por lo que se sugiere opciones externas o no oficiales, tales como tomar
imágenes del servidor a virtualizar y montar dicha imagen en una máquina virtual [42].
En [43] se encuentra una lista más exhaustiva de las funcionalidades ofrecidas por Xen.
La tabla 6 se presenta un cuadro resumen de las funcionalidades de Xen, respecto de los
requerimientos y restricciones de la DCSC, presentados en el capítulo 3.
6 Hecho en base a referencia: http://thecamels.org/wp-content/uploads/XEN-schema.png
Hardware servidor
MV1 MV2 SO Host
Xen
Hardware cliente
Sistema operativo
Herramienta de administración
54
Criterio XenSistema operativo host Sistemas operativos Linux Sist. operativos guest soportados
FreeBSD XLinux XWindows (XP/Vista/7) XWindows Server (2003, 2008) X
Migración de M.V. mientras está en funcionamiento SiMigración de máquina física a máquina virtual (P2V) SiSW de monitoreo y gestión Línea de comando o aplicación gráficaClonación de M.V. Si (maquina detenida)Asignación de recursos de hardware a M.V. Si (detenida)Máxima RAM host 1 [TB]Máxima RAM guest Depende del S.O. (32 o 64 bits)Núcleos soportados host 16Núcleos asignables al guest 16Iniciar M.V. al iniciar host SiPrecio (USD) 0
Tabla 4.6: Análisis de funcionalidades de Xen según los requerimientos y restricciones de la DCSC.
1.2.2. KVM.
KVM o Kernel-based Virtual Machine, es una herramienta de virtualización desarrollada por
Qumranet [44] y adquirida en 2008 por Red Hat, Inc. [45]. En la actualidad se le considera como
uno de los competidores directos de Xen en el ámbito de las soluciones de código abierto.
Su primera versión se remonta a febrero de 2007, como parte oficial de la versión 2.6.20 del
núcleo de Linux [46] y hasta la fecha se encuentra en constante desarrollo por una comunidad de
programadores, distribuyéndose bajo licencias GPLv2, LGPLv2, LGPL y GPL [33]. Además, el
hecho de que sea parte oficial del núcleo de Linux, hace que esta sea la herramienta de
virtualización oficial de Linux, a diferencia de Xen que, como se vio anteriormente, utiliza una
versión modificada del núcleo de Linux.
KVM está especialmente desarrollada para procesadores con arquitectura x86 que tengan soporte
para instrucciones Intel VT-x [47] y AMD-V [48], pero también se han hecho desarrollos para
otras arquitecturas como PowerPC [49], Itanium [34] y ARM [35].
Respecto a los tipos de virtualización, al igual que Xen, KVM permite tanto paravirtualización
como full-virtualización.
55
Figura 4.4: Arquitectura de KVM7.
En la figura 4 se presenta un diagrama con la arquitectura de funcionamiento de KVM, la cual es
similar a la de Xen, sobre todo en el lado del cliente. Es por esta razón que se pueden utilizar las
mismas soluciones descritas para Xen.
Respecto a los sistemas operativos host y dada la calidad de herramienta oficial del núcleo de
Linux, KVM se puede instalar en cualquier distribución de Linux.
Las funcionalidades que KVM ofrece son similares a Xen, dentro de las que se destacan:
migración de máquinas virtuales mientras están en funcionamiento [50], clonación de máquinas
virtuales, y otras, que se encuentran más detalladas en [51]. En lo que respecta a migración de
máquina física a virtual (P2V), al igual que para Xen, se sugiere considerar opciones no oficiales
[42].
La tabla 7 se presenta un resumen de las funcionalidades de KVM en términos de los
requerimientos y restricciones establecidos por la Dirección Central de Servicios
Computacionales, descritos en el capítulo 3 de esta memoria.
7 Hecho en base a referencia: http://southbrain.com/south/virtualization/virtualization-kvm-60.png
Hardware servidor
MV1 MV2 SO Host
KVM
Hardware cliente
Sistema operativo
Herramienta de administración
56
Criterio Kernel-based Virtual MachineSistema operativo host Sistemas operativos Linux Sist. operativos guest soportados
FreeBSD XLinux XWindows (XP/Vista/7) XWindows Server (2003, 2008) X
Migrar M.V. mientras está en funcionamiento SiMigración de máquina física a máquina virtual (P2V) SiSW de monitoreo y gestión Línea de comando o aplicación gráficaClonación de M.V. Si (maquina detenida)Asignación de recursos de hardware a M.V Si (detenida)Máxima RAM host Depende del S.O.3
Máxima RAM guest Depende del S.O. (32 o 64 bits)Núcleos soportados host Depende del S.O.8
Núcleos asignables al guest 16Iniciar M.V. al iniciar host SiPrecio (USD) 0
Tabla 4.6: Análisis de funcionalidades de KVM según los requerimientos y restricciones de la DCSC.
1.2.3. PROXMOX VIRTUAL ENVIRONMENT.
Proxmox Virtual Environment es una herramienta de virtualización de código abierto
desarrollada y mantenida por Proxmox Server Solutions GmbH. [52]. La principal idea tras esta
herramienta es la de ofrecer una herramienta de clase empresarial en base a herramientas de
código abierto, tales como KVM y OpenVZ. Esta herramienta se distribuye bajo licencia GPLv2
[33].
La primera versión de Proxmox Virtual Environment fue lanzada en abril de 2008, y en la
actualidad se encuentra en la versión 1.7. Los desarrolladores tienen previsto lanzar al mercado
la versión 2.x durante la segunda mitad del año 2011 [53].
Al igual que KVM, Proxmox Virtual Environment está enfocada principalmente a servidores con
procesadores de arquitectura de 64 bits que tengan instrucciones Intel VT-x o AMD-V.
En cuanto al sistema operativo base que utiliza, Proxmox Virtual Environment está desarrollado
en Debian Lenny de 64 bits [54]. Además esta herramienta permite virtualización tanto a nivel
8 Al ser parte del núcleo del sistema operativo, este parámetro dependerá de las limitaciones de hardware de la distribución que se utilice.
57
de sistema operativo con OpenVZ, la cual es útil con sistemas operativos Linux y full-
virtualización con KVM tanto para sistemas operativos Linux como para otros (Unix-BSD,
Microsoft Windows).
Figura 4.5: Arquitectura de Proxmox Virtual Environment.
La arquitectura de funcionamiento de Proxmox Virtual Environment se presenta en la figura 5.
Siendo similar a las arquitecturas presentadas anteriormente en este capítulo, en lo que respecta a
aplicación de monitoreo y gestión se diferencia de las anteriores en que en el lado del servidor
físico donde reside la herramienta de gestión y monitoreo se instala un servidor web. Este
servidor web recibe la información entregada por el administrador de máquinas virtuales (KVM
+ OpenVZ) ordenándola de manera que sea interpretable para la administración y monitoreo del
servidor físico y de los servidores virtuales. El acceso a esta información es mediante navegador
web.
En cuanto a funcionalidades, esta herramienta entrega migración de máquinas virtuales mientras
están en ejecución, clonación y respaldo de máquinas virtuales. Una lista más completa de
funcionalidades se encuentra en [55]. Respecto a migración de máquina física a virtual o P2V, se
recomienda utilizar la misma estrategia descrita tanto para Xen como para KVM.
La tabla 8 presenta un resumen de las funcionalidades de Proxmox Virtual Environment en
términos de los requerimientos y restricciones los parámetros establecidos para el caso de la
Dirección Central de Servicios Computacionales (capítulo 3).
Hardware servidor
MV1 MV2 SO Host + Web server
KVM + OpenVZ
Hardware cliente
Sistema opeativo
Navegador web
58
Criterio Proxmox Virtual EnvironmentSistema operativo host PropioSist. operativos guest soportados
FreeBSD XLinux XWindows (XP/Vista/7) XWindows Server (2003, 2008) X
Migrar M.V. mientras está en funcionamiento SiMigración de máquina física a máquina virtual (P2V) SiSW de monitoreo y gestión Interfaz webClonación de M.V. Si (maquina detenida)Asignación de recursos de hardware a M.V. Si (detenida)Máxima RAM host 256 [GB]Máxima RAM guest Depende del S.O. (32 o 64 bits)Núcleos soportados host 16Núcleos asignables al guest 16Iniciar M.V. al iniciar host SiPrecio (USD) 0
Tabla 4.8: Análisis de Proxmox Virtual Environment según las especificaciones de la DCSC
2. ANÁLISIS Y SOLUCIÓN.
De la inspección de las Tablas 3, 5, 6, 7 y 8 es posible apreciar que las cinco herramientas
cumplen con la mayoría de los requerimientos y restricciones establecidos por la Dirección
Central de Servicios Computacionales.
En lo que respecta a las herramientas propietarias, la versión gratuita de VMware vSphere (tabla
3) no cumple con uno de los requerimientos: migración de máquinas virtuales mientras se
encuentran en ejecución. En cambio, esta funcionalidad sí es ofrecida por la versión gratuita de
Citrix XenServer (tabla 5), lo cual hace considerarla como una opción. Por su parte, analizando
tanto las funcionalidades como los servicios adicionales de las distintas licencias (tablas 1 y 2 en
vSphere y 4 en XenServer) de VMware vSphere y Citrix Xenserver, ambas consideran soporte
técnico mínimo de un año (ver [6] y [7] para VMware y [56] para Citrix XenServer) y en cuanto
a funcionalidades, Citrix XenServer ofrece más funcionalidades con licencias menos costosas,
además de entregar licencias por servidor, a diferencia de VMware, quién entrega licencias solo
por CPU.
59
En el caso de las herramientas de código abierto, comparando las tablas 6, 7 y 8 se puede
concluir que todas ofrecen las mismas funcionalidades, lo cual deja abierta la opción de elegir
cualquiera. Sin embargo, en términos de permanencia en el mercado, respaldo oficial del sistema
operativo y plataforma de la herramienta de administración, existen diferencias.
Xen es la herramienta que lleva más tiempo en el mercado. Sin embargo, no es una herramienta
oficial de virtualización en Linux, a diferencia de KVM. Desde este punto de vista, KVM es una
opción más segura.
Proxmox Virtual Environment no es muy popular y su interfaz web de administración, es más
lenta que la de sus competidores, sobre todo en el despliegue de gráficos en sistemas operativos
Microsoft Windows. Esta desventaja resulta en su descarte como opción de virtualización. Por lo
tanto, entre las opciones gratuitas, se prefiere KVM.
Al comparar KVM con la edición gratuita de Citrix XenServer, ésta última requiere renovar
anualmente la licencia gratuita [57], lo cual es un trámite engorroso y algo lento (es necesario
solicitar dicha licencia, la cual demora un tiempo en ser generada). Esto no es necesario con
KVM.
Debido a sus ventajas y su cumplimiento de los requerimientos y restricciones establecidos por la
DCSC, en esta memoria se opta por utilizar KVM como herramienta de virtualización para ser
implementada en un plan piloto en la DCSC.
3. RESUMEN.
En este capítulo se estudiaron distintas herramientas de virtualización, analizándolas desde el
punto de vista de las funcionalidades que estas ofrecen y cómo estas se adecúan a los
requerimientos expresados por la Dirección Central de Servicios Computacionales de la
Universidad. En base a este estudio, se ha optado por seleccionar la herramienta de código
abierto KVM.
En el siguiente capítulo se realizará un análisis y proyección de los beneficios esperados tras una
implementación formal de virtualización y también de los costos que se deberán asumir.
60
4. BIBLIOGRAFÍA.
[1] Free VMware vSphere Hypervisor: Bare Metal Hypervisor (based on VMware ESXi) [en
línea] <http://www.vmware.com/products/vsphere-hypervisor/> [consulta: 21 de febrero de
2011].
[2] Citrix System >> Citrix Xenserver. [en línea]
<http://www.citrix.com/English/ps2/products/product.asp?contentID=683148&ntref=prod_top>
[consulta: 21 de febrero de 2011].
[3] VMware [en línea] <www.vmware.com> [consulta: 21 de febrero de 2011]
[4] ComputerProfile-blog.com >> Opportunities in a turbulent period [en línea]
<http://computerprofile-blog.com/?p=627> [consulta: 21 de febrero de 2011]
[5] POSIX – Wikipedia, the free encyclopedia [en línea] <http://en.wikipedia.org/wiki/POSIX>
[consulta: 21 de febrero de 2011].
[6] VMware Store - Small and Mid-Size Business Options [en línea]
<http://www.vmware.com/vmwarestore/vsphere_smbpurchaseoptions.html> [consulta: 21 de
febrero de 2011]
[7] VMware Store – Vmware vSphere 4 Bundle Solutions [en línea]
<http://www.vmware.com/vmwarestore/vsphere_purchaseoptions.html> [consulta: 21 de febrero
de 2011].
[8] VMware Storage I/O Control [en línea] <http://www.vmware.com/products/vstorage-thin-
provisioning/> [consulta: 21 de febrero de 2011].
[9] VMware vCenter Update Manager [en línea] <http://www.vmware.com/products/update-
manager/> [consulta: 21 de febrero de 2011].
[10] VMware Data Recovery [en línea] <http://www.vmware.com/products/data-recovery/>
[consulta: 21 de febrero de 2011]
[11] VMware vStorage API [en línea] <http://www.vmware.com/products/vstorage-apis-for-
data-protection/> [consulta: 21 de febrero de 2011].
61
[12] VMware High Availability (HA) [en línea] <http://www.vmware.com/products/high-
availability/> [consulta: 21 de febrero de 2011].
[13] VMware Fault Tolerance (FT) [en línea] <http://www.vmware.com/products/fault-
tolerance/> [consulta: 21 de febrero de 2011].
[14] VMware vMotion [en línea] <http://www.vmware.com/products/vmotion/> [consulta: 21 de
febrero de 2011]
[15] VMware Storage VMotion [en línea] <http://www.vmware.com/products/storage-
vmotion/overview.html> [consulta: 21 de febrero de 2011].
[16] VMware vShield Zones [en línea] <http://www.vmware.com/products/vshield-zones/>
[consulta: 21 de febrero de 2011].
[17] VMware vStorage APIs for Array Integration [en línea]
<http://www.vmware.com/products/vstorage-apis-for-array-integration/overview.html>
[consulta: 21 de febrero de 2011].
[18] Distributed Resources Scheduler (DRS), Distributed Power Management (DPM) [en línea]
< http://www.vmware.com/products/drs/> [consulta: 21 de febrero de 2011].
[19] VMware vSphere - Storage I/O Control [en línea]
<http://www.vmware.com/products/storage-io-control/overview.html> [consulta: 21 de febrero
de 2011].
[20] VMware Network I/O Contol [en línea] <http://www.vmware.com/products/network-io-
control/overview.html> [consulta: 21 de febrero de 2011].
[21] VMware vNetwork Distributed Switch [en línea]
<http://www.vmware.com/products/vnetwork-distributed-switch/> [consulta: 21 de febrero de
2011].
[22] VMware vCenter Server Features [en línea] <http://www.vmware.com/products/vcenter-
server/features.html#c1236> [consulta: 21 de febrero de 2011].
[23] Xen Homepage [en línea] <www.xen.org> [consulta: 21 de febrero de 2011]
62
[24] Citrix Systems [en línea] <www.citrix.com> [consulta: 21 de febrero de 2011]
[25] XenCenter [en línea] <http://community.citrix.com/display/xs/XenCenter> [consulta: 21 de
febrero de 2011]
[26] XenServer Editions [en línea]
<http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2300456> [consulta: 21
de febrero de 2011].
[27] XenServer Specifications [en línea]
<http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=1681139> [consulta: 21
de febrero de 2011]
[28] KVM [en línea] <http://www.linux-kvm.org/> [consulta: 21 de febrero de 2011]
[29] Proxmox VE [en línea] <http://pve.proxmox.com/wiki/Main_Page> [consulta: 21 de febrero
de 2011]
[30] OpenVZ [en línea] <http://wiki.openvz.org/Main_Page> [consulta: 21 de febrero de 2011]
[31] Computer Laboratory – Xen VMM [en línea]
<http://www.cl.cam.ac.uk/research/srg/netos/xen/> [consulta: 23 de febrero de 2011]
[32] Community – Xen [en línea] <http://www.xen.org/community/> [consulta: 23 de febrero de
2011].
[33] GNU General Public License – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/GNU_General_Public_License> [consulta: 23 de febrero de 2011]
[34] Itanium – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Itanium> [consulta: 23 de febrero de 2011]
[35] ARM architecture – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/ARM_architecture> [consulta: 23 de febrero de 2011]
[36] OS Compatibility – Xen Wiki [en línea]
<http://wiki.xensource.com/xenwiki/OSCompatibility> [consulta: 23 de febrero de 2011]
63
[37] Secure Shell - Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Secure_Shell> [consulta: 23 de febrero de 2011]
[38] Man page virsh [en línea] <http://linux.die.net/man/1/virsh> [consulta: 24 de febrero de
2011]
[39] X Window System - Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/X11> [consulta: 24 de febrero de 2011]
[40] Virtual Machine Manager [en línea] <http://virt-manager.et.redhat.com/> [consulta: 24 de
febrero de 2011].
[41] virt-p2v – P2V migration tool [en línea] <http://people.redhat.com/~rjones/virt-p2v/virt-
p2v.1.html> [consulta: 24 de febrero de 2011].
[42] P2V Conversion when using KVM. << Axelilly’s Ponderings [en línea]
<http://axelilly.wordpress.com/2010/05/11/p2v-conversion-when-using-kvm/> [consulta: 24 de
febrero de 2011].
[43] Xen 4.0 – Xen Wiki [en línea] <http://wiki.xensource.com/xenwiki/Xen4.0> [consulta: 24
de febrero de 2011].
[44] Qumranet – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/Qumranet> [consulta: 25 de febrero de 2011]
[45] Red Hat [en línea] <http://www.redhat.com/> [consulta: 25 de febrero de 2011].
[46] Linux: 2.6.20 Kernel Released | KernelTrap [en línea] <http://kerneltrap.org/node/7670>
[consulta: 25 de febrero de 2011].
[47] Virtualization Technology from Intel [en línea]
<http://www.intel.com/technology/virtualization/> [consulta: 25 de febrero de 2011]
[48] Virtualization | AMD [en línea] <http://sites.amd.com/us/business/it-
solutions/virtualization/Pages/virtualization.aspx> [consulta: 25 de febrero de 2011]
64
[49] PowerPC – Wikipedia, the free enciclopedia [en línea]
<http://en.wikipedia.org/wiki/PowerPC> [consulta: 25 de febrero de 2011].
[50] Migration – KVM [en línea] <http://www.linux-kvm.org/page/Migration> [consulta: 25 de
febrero de 2011].
[51] KVM Features – KVM [en línea] <http://www.linux-kvm.org/page/KVM_Features>
[consulta: 25 de febrero de 2011].
[52] Proxmox – Start page [en línea] <http://www.proxmox.com/> [consulta: 25 de febrero de
2011].
[53] Roadmap – Proxmox VE [en línea] <http://pve.proxmox.com/wiki/Roadmap> [consulta: 25
de febrero de 2011].
[54] Bare-metal ISO Instaler – Proxmox VE [en línea] <http://pve.proxmox.com/wiki/Bare-
metal_ISO_Installer> [consulta: 25 de febrero de 2011].
[55] Backup - Restore - Live Migration – Proxmox VE [en línea]
<http://pve.proxmox.com/wiki/Backup_-_Restore_-_Live_Migration> [consulta: 25 de febrero
de 2011].
[56] Citrix Licensing Resource Center [en línea]
<http://www.citrix.com/lang/English/lp/lp_2305120.asp> [consulta: 26 de febrero de 2011].
[57] Free Xenserver License Renew – Server Fault [en línea]
<http://serverfault.com/questions/207398/free-xenserver-license-renew> [consulta 26 de febrero
de 2011].
65
Capítulo 5
IMPLEMENTACIÓN Y ANÁLISIS DE LA SOLUCIÓN
Luego de seleccionar e implementar la herramienta escogida en el capítulo anterior, es necesario
responder una par de preguntas claves: ¿qué beneficios se obtienen al implementar virtualización
en los servicios identificados? y ¿cuál es el costo que se debe asumir?
Estas interrogantes serán las bases de este capítulo. Para responderlas, en este capítulo se
analizarán los beneficios y los costos asociados, de manera cuantitativa y se reportarán las
pruebas a la implementación.
Los beneficios potenciales obtenidos mediante virtualización se proyectarán en base a datos de
los equipos y de información adicional, como el valor de kilowatt hora ($/kWh). En tanto que los
costos se proyectarán en base a pruebas realizadas a los servicios que se virtualizarán en una
primera etapa (web estáticas, DNS y LDAP), tal como se mencionó en la sección 1 del capítulo 3
de este trabajo.
1. BENEFICIOS.
Uno de los beneficios que produce el uso de virtualización, mencionado en la sección 3.2 del
capítulo 2, es el ahorro en hardware, ya que en un servidor físico se pueden ejecutar un número
determinado de servidores virtuales. Este hecho derivará en otros ahorros, tales como consumo
de energía eléctrica por servidor y consumo en sistemas de climatización en la sala de servidores,
tal como se expuso en los capítulos 1 y 2.
Dado que la implementación de la virtualización de los servicios de Web, DNS y LDAP se
encuentra aún en desarrollo en la DCSC, el análisis de los beneficios esperados se presenta de
manera estimada. Esta estimación, junto con la de costos, permitirá establecer la conveniencia de
implementar virtualización en el caso estudiado.
66
1.1. CANTIDAD DE SERVIDORES VIRTUALES.
Un aspecto clave cuando se virtualiza un sistema es determinar la cantidad de servidores
virtuales que pueden ejecutarse dentro de un servidor físico. Esto depende no sólo de la
plataforma física que ofrece el host, sino también de los servicios que se desea virtualizar y su
nivel de utilización.
En términos de hardware, se puede obtener una primera aproximación considerando la relación
existente entre las velocidades de procesamiento de la CPU del servidor físico (CPUf) y la
capacidad de procesamiento de la CPU que utilizará el servidor virtual (CPUv). Este último dato
depende de los servicios a virtualizar.
Tal como se mencionó al principio de este capítulo, se desea virtualizar servicios de páginas web
de contenido estático, LDAP y DNS. Según estimaciones propias y otras obtenidas de la
literatura [1], la utilización promedio de CPU de estos servicios no supera el 20% de la
capacidad de procesadores Intel Pentium 4 de 2 [GHz]. Por lo tanto, la utilización del servidor
virtual , CPUv , es de 400 [MHz] como máximo.
El servidor físico en el que se realizará la virtualización posee un procesador Intel Xeon modelo
E5310 [2] de 4 núcleos que funcionan a una velocidad de 1,6 [GHz] cada uno, lo cual entrega
una velocidad de procesamiento total de CPUf.=6,4 [GHz]. Con los valores de CPUf de 6400
[MHz] y de CPUv de 400 [MHz], el servidor físico permitiría hasta 16 servidores virtuales.
Además de la capacidad de procesamiento de la CPU, el proceso de virtualización debe
considerar también la memoria RAM disponible en el servidor físico (RAMf) así como la RAM
necesaria para los servidores virtuales (RAMv). En este caso, el servidor físico cuenta con 32
[GB] de RAM y de acuerdo a las consideraciones de la Dirección Central de Servicios
Computacionales respecto del consumo de RAM por parte de los servicios a virtualizar, esta no
debería ser mayor a 2 [GB] por servidor. Por lo tanto, considerando las restricciones de uso de
RAM, se podrían ejecutar hasta 16 máquinas virtuales por servidor.
En lo que respecta a almacenamiento en disco duro, en este trabajo no se considera una gran
limitante: el servidor 500[GB] en disco duro, lo que es más que suficiente para atender la
67
demanda de los servidores virtuales (ya que en promedio no utilizarán discos duros virtuales
mayores a 10 [GB], según lo estimado por la DCSC para estos servicios).
Dado que los servicios que se ejecutarán en los servidores virtuales utilizan el recurso de red, es
también necesario considerar las restricciones que impone el número de tarjetas de red del
servidor físico en los servicios a virtualizar. El servidor físico de la DCSC posee 2 interfaces de
red, cada una operando una velocidad de 1000[Mbps]. Dados los servicios a virtualizar (Web,
DNS y LDAP), se considera que en el peor de los casos, cada servidor virtual genera un tráfico
de 300 [kbps] por conexión (según datos de la DCSC9), por lo tanto, se podría atender
aproximadamente 6660 conexiones simultaneas (3330 por interfaz de red). Esto implicaría que
los 16 servidores virtuales atenderían hasta 415 conexiones simultáneas cada uno.
En las estimaciones anteriores no se ha incluido el uso de CPU, RAM y tarjetas de red que
necesita el sistema operativo base y el administrador de máquinas virtuales (VMM). Para los
servicios del caso de estudio de esta memoria, se ha determinado, en base a las observaciones
propias, que el sistema operativo y el VMM tienen un requerimiento promedio de 450 [MHz] de
CPU (aproximadamente el 25% de uno de los núcleos de CPU del servidor físico). En cuanto a
RAM desde 2 [GB] en RAM es suficiente para cubrir las necesidades del VMM, según
estimaciones realizadas tras esta implementación primaria.
En resumen, estos requerimientos se satisfacen si en vez de instalar 16 servidores virtuales, se
implementan 12. Lo que deja capacidad de hardware suficiente para atender los requerimientos
del sistema operativo base y del VMM. Cabe mencionar que este método, donde se han
considerado asignaciones estáticas de recursos de hardware, si bien no representa la realidad, es
una buena aproximación inicial de lo que puede suceder en la práctica.
1.2. AHORRO ENERGÉTICO
La disminución de servidores físicos que resulta de la implementación de la técnica de
virtualización conlleva ahorros en el consumo de energía del sistema. Para estimar este ahorro,
en este trabajo de título se consideraron dos tipos de servidores físicos, representativos de de
situación actual de la Dirección Central de Servicios Computacionales. El primero corresponde a
9 Tanto esta como otras estimaciones realizadas durante este capítulo están basadas en información de monitoreo
obtenida de http://redes2.dcsc.utfsm.cl/mrtg/
68
un computador que genera un consumo máximo de 300 [W] de potencia. Este tipo de servidor se
usa actualmente para alojar el servicio que requieren pocos recursos de hardware, como LDAP,
DNS y webs estáticas. El segundo tipo, corresponde a un servidor que genera un consumo
máximo de 750 [W] de potencia y en el que actualmente se aloja el servicio con mayores
requerimientos de hardware, como el servidor de sitios web de alumnos.
Para estimar el ahorro en consumo de energía eléctrica debido a la disminución de servidores, se
considera lo siguiente:
El periodo de tiempo en el que se evaluará el consumo en energía eléctrica de 30 días.
Se supone que la Universidad se encuentra en una zona tarifaria de alta tensión, que
corresponde a la tarifa aplicada a empresas e instituciones. El costo del kilowatt hora para
esta zona tarifaria es de $69,281 (pesos chilenos). Los valores se encuentran disponibles
en [3].
El ahorro de energía eléctrica proviene de la disminución en el consumo eléctrico del
sistema de servidores y del sistema de climatización.
El consumo de energía eléctrica de los servidores de 300[W] y 750 [W] es de 216[kWh] y
540[kWh], respectivamente (obtenidos de la multiplicación del consumo en watts, multiplicado
por el número de horas de un mes). Estos consumos se traducen en un ahorro monetario de
aproximadamente $15.000 y $37.000 mensuales10 (30 y 77 [USD]) para el servidor de 300 [W] y
750 [W], respectivamente.
Además del ahorro de consumo energético directo de los servidores virtualizados, existe un
ahorro debido a la disminución de carga del sistema de climatización, el cual está encargado de
mantener la temperatura a un nivel apropiado para el correcto funcionamiento de los equipos.
El consumo energético de los sistemas de climatización se suele medir en [BTU/h] (British
Thermal Unit [4] por hora). La relación entre [BTU/h] y [kWh] es de 3,412. Por lo tanto, los
servidores de 300[W] y 750 [W] tienen un consumo de 1023,6[BTU/h] y 2559,1[BTU/h],
respectivamente. 10 Considerando un mes de 30 días.
69
En cuanto al ahorro monetario, al solo cambiar las unidades (de [kWh] a [BTU/h]), se debe notar
que es el mismo que el expuesto anteriormente, por lo que los ahorros mensuales en esta materia
son del orden de los $15.000 (30 [USD]) para el computador de 300 [W] y de $37.000 (77
[USD]) para el servidor de 750 [W].
2. DESVENTAJAS POR TIPO DE SERVICIO VIRTUALIZADO
Como se discutió en el Capítulo 2, la técnica de virtualización conlleva también ciertas
desventajas relacionadas con la degradación de servicio resultante de la emulación del hardware
real para cada máquina virtual.
Para estimar el nivel de degradación del servicio que prestaría un servidor virtual, comparado
con el mismo servicio alojado en un servidor físico, en este trabajo de título se diseñaron una
serie de pruebas de rendimiento. Estas pruebas se realizaron para los tres servicios a virtualizar:
servicios web de contenido estático, DNS y LDAP.
El escenario en cual se desarrollaron estas pruebas se ilustra en la figura 1.
Cliente Sevidor físico
Red oficina
Firewall
Red servidores
Figura 5.1: Configuración de red y dispositivos utilizados para las pruebas.
De la figura es posible apreciar que la configuración de prueba constó de:
Cliente: Computador personal Compaq Presario modelo F505LA, desde donde el cliente
solicita la prestación del servicio de red. Las especificaciones de hardware y sistema
operativo de este computador se encuentran en la columna derecha de la Tabla 1.
Red oficina: Corresponde a una red interna de computadores de escritorio en la cual se
encuentra el cliente.
70
Firewall: Es el componente que separa la red oficina de la red servidores, por razones de
seguridad.
Red servidores: Es la red donde se encuentran los servidores que administra la DCSC.
Esta red es distinta a la red oficina.
Servidor físico: Dell PowerEdge 2950 [6], con las especificaciones de hardware y sistema
operativo que se listan en la segunda columna de la Tabla 1. La herramienta de
virtualización instalada fue KVM, la cual se instaló sobre el sistema operativo Ubuntu
Server 10.10 [7]. Cada uno de los 3 servidores virtuales instalado en el servidor físico
utilizó el sistema operativo FreeBSD 8.1.
Note que la configuración de prueba no involucró el paso de datos por la red externa. Todas las
transferencias se efectuaron entre servidores/computadores dentro de la Universidad.
Hardware Servidor (virtualizado) Servidor (físico) Cliente
Procesador1 núcleo de procesador Intel Xeon E5310 1.6 [GHz] por servidor virtual.
Intel Xeon E5310 1.6 [GHz], 4 núcleos
AMD Sempron Mobile 1.6 [GHz]
RAM 1[GB] Por servidor virtual (3 [GB] en total) 16 [GB] 2 [GB]
SistemaOperativo
Ubuntu Server 10.10 (Base). FreeBSD 8.1 (Servidor virtual) FreeBSD 8.1 ArchLinux 2009.08
[9]Tarjetas de Red
1 interfaz de 100 Mbps para los 3 servidores
1 interfaz de 100 Mbps
1 interfaz de 100 Mbps
Disco Duro 10 [GB] por servidor 500 [GB] 80[GB]
Tabla 5.1: Especificaciones de hardware y sistema operativo de los equipos utilizados para las pruebas
2.1. SERVICIO WEB.
En este estudio, el servicio web se ofrecerá usando la aplicación servidora Apache [10], la que
debido a su uso extendido a nivel mundial [11] cuenta con bastante documentación y soporte, lo
que facilita su configuración y puesta en marcha.
Apache es un software de código abierto, distribuido bajo licencia Apache License [12]. Se
encuentra disponible para plataformas BSD, Linux, MacOS y Windows. Dentro de sus ventajas
destaca las de ser un servidor modular compuesto por un módulo central y otros módulos, que
agregan funcionalidades adicionales, tales como soporte para otros lenguajes de programación
71
(Perl, PHP, Python) y control de acceso. Más detalles de las funcionalidades adicionales se
encuentran en [13].
La herramienta utilizada para evaluar el funcionamiento de Apache en un servidor virtualizado
será Apache Benchmark [14]. Este software permite determinar el número de solicitudes de
páginas web a ejecutar durante el tiempo de prueba. Permite también generar solicitudes
simultáneas con el objeto de emular varias visitas a un sitio web. Utilizando esta funcionalidad,
se simularon 10 escenarios de carga del servidor web virtualizado. Cada escenario fue definido
por el valor de solicitudes de páginas totales como de solicitudes simultáneas. Estos escenarios
se resumen en la tabla 2, donde la notación EX corresponde al escenario X. Cada escenario tiene
asociado un número de conexiones totales y otro de conexiones simultáneas. Por ejemplo, en el
escenario 1 (E1) se generan 500 conexiones en total y dentro de cada una de ellas conexiones
totales, existen 50 conexiones simultáneas.
Los valores de conexiones simultáneas como totales, se han seleccionado para lograr un máximo
de estrés, tanto en los servidores físicos como en los virtuales.
Conexiones totales
500 1000 1500 2000 2500
Conexiones
simultáneas
50 E1 E3 E5 E7 E9
100 E2 E4 E6 E8 E10
Tabla 5.2: Resumen de las pruebas con Apache Benchmark.
Cabe destacar que en promedio estas pruebas duran entre 3 y 5 segundos, dependiendo la
cantidad de conexiones totales
Para medir el rendimiento del servicio web virtualizado, se midieron sus tiempos de respuesta.
En el establecimiento y operación de una conexión HTTP, Apache Becnhmark distingue 4
tiempos: el tiempo de conexión o ctime, el tiempo de espera o wait, el tiempo de transacción o
dtime y el tiempo total o ttime.
72
Figura 5.2: Ilustración de los tiempos involucrados en una transacción HTTP de Apache Benchmark.
La figura 2 ilustra los instantes de inicio y término de cada uno de estos tiempos. El tiempo de
conexión o ctime es el tiempo que transcurre desde que el cliente envía la solicitud de conexión
al servidor hasta que la conexión se establece. El tiempo de espera o wait, corresponde al instante
desde que se establece la conexión hasta que el servidor inicia la transferencia de datos al cliente.
El tiempo de transacción o dtime, es el que transcurre desde que se inicia la transferencia de
datos, hasta que se cierra la conexión con el servidor. Finalmente el tiempo total o ttime es la
suma del tiempo de conexión y el tiempo de transacción.
A continuación se presenta un gráfico que resume los tiempos totales (ttime) obtenidos durante
esta evaluación, tanto para el caso en que el servicio residen directamente en un servidor físico
(terminados en fis en la gráfica), como para el caso en que el servicio ha sido virtualizado
(terminados en vir en la gráfica). Los gráficios con los todos los tiempos (ctime, ditme, ttime y
wait), correspondientes a los resultados obtenidos para cada escenario se presentan en la sección
1 de A.1 en Anexos.
ctime
ttime
wait dtime
ttime
tiempo [ms]
Cliente Servidor
ctime
wait
dtime
Búsqueda por parte del cliente
Transferencia del sitio web
73
Figura 5.3: Gráficas de los escenarios obtenidas con Apache Benchmark.
74
Es posible apreciar que, como era de esperar, los tiempos totales correspondientes a los casos
donde el servicio se ejecuta en servidores virtuales (EX_vir), son mayores a los tiempos totales
de los casos donde el servicio se ejecuta en servidores físicos (EX_fis).
La tabla 3 presenta el valor promedio de ttime y el valor del tiempo total para cada escenario.
Cabe destacar que los escenarios han sido ordenados según el número de conexiones simultáneas
por conexión, con esto, los escenarios impares corresponden a 50 conexiones simultáneas y los
pares a 100 conexiones simultáneas.
Escenario
Tiempo
Promedio de
ttime Físico
(ms)
Tiempo
Promedio de
ttime Virtual
(ms)
Razón de
diferencia de
ttime
promedio
Tiempo
Total
Físico
(ms)
Tiempo
Total
Virtual
(ms)
Razón de
diferencia
E1 15,923 23,458 1,473 23 41 1,782
E3 14,92 23,851 1,598 25 46 1,84
E5 15,091 24,497 1,623 27 50 1,851
E7 13,235 23,873 1,803 30 55 1,833
E9 12,519 23,322 1,862 32 57 1,781
E2 28,064 47,72 1,7 40 66 1,65
E4 31,165 46,12 1,479 43 70 1,627
E6 30,925 49,137 1,588 45 73 1,622
E8 30,239 47,831 1,581 48 76 1,583
E10 28,204 45,807 1,624 50 79 1,58
Tabla 5.3: Tiempos promedio y total de cada escenario.
Es posible apreciar en la tabla que las razones de tiempo promedio y de tiempo total en los
distintos escenarios difieren en su comportamiento. En el caso de los escenarios impares (50
conexiones simultáneas), si bien en los tiempos promedios de atención existe una tendencia a
aumentar la razón de diferencia, en el caso total se da un efecto de alcanzar un valor máximo
(E5) y luego disminuir. Esto se debe a, a medida que existen más solicitudes totales, la mayor
cantidad de estas se atienden dentro del tiempo promedio, lo cual se puede apreciar al observar
que la curva se mantiene más plana en el centro de la gráfica, a medida que se aumentan las
solicitudes totales. Esto provoca que las solicitudes que se atienden al final sean menos, lo cual
se puede apreciar al ver que la curva se ve más pronunciada al final, a medida que hay mayor
cantidad de solicitudes totales.
75
El caso de los escenarios pares es diferente, ya que en los tiempos promedio se alcanza un valor
mínimo (E4), para luego ir aumentando, a diferencia de los tiempos totales, donde la tendencia es
claramente a disminuir. Sin embargo, se puede ver gráficamente, que se observa el mismo
comportamiento descrito para los escenarios impares, ya que al aumentar las solicitudes totales,
se atiende una mayor cantidad cerca del centro y al final el número de solicitudes es menor.
Lo destacable es que, a diferencia de lo que se podría pensar, al tener mayor número de
solicitudes simultáneas, la razón de los tiempos promedio y total va disminuyendo, lo cual se
puede deber a que el servidor virtual aprovecha de mejor manera los recursos limitados que
posee, comparado con un servidor físico que solo utiliza parte de ellos. Aun así, los tiempos,
tanto totales como promedio son mayores en el caso de los escenarios pares que en los impares.
Para concluir con el análisis de web, se puede decir que existe una diferencia notoria, la cual
pude llegar a ser el doble de tiempo en el caso de una solicitud promedio, lo cual invita a pensar
muy bien el tipo de sitios web a alojar en un servidor virtual.
En este caso específico, los sitios que se pretenden alojar en los servidores virtuales, son sitios
que no tienen una gran cantidad de tráfico diario (entre 500 y 1000 solicitudes diarias, según
estimaciones propias). Este hecho nos deja cercanos a los parámetros de los escenarios 1 y 3, los
cual podrían suceder en el peor de los casos (tener todas esas conexiones en un instante de
tiempo). Con esto se asegura que en el peor de los casos se tendrá una razón de diferencia
promedio de 1,84 veces, es decir, el tiempo de respuesta del servidor virtual será un 84% mayor
que el servidor físico.
Finalmente es necesario considerar que estas pruebas han sido realizadas internamente, es decir,
con una red con pocos saltos (hop) y sin transferencia de datos hacia/desde la red externa. La
influencia de la red externa debiera apreciarse en conexiones desde el hogar, y considerando que
pueden existir entre 6 y 15 saltos11
, los cuales pueden agregar entre 15 y 30 [ms] de retardo en la
respuesta. Esta adición hará que los tiempos promedio, en el caso de los escenarios 1 y 3, tiendan
a valores de tiempo total obtenidos en el escenario 9. Pese a esto la razón en el peor caso se hace
11
Esta información puede obtenerse mediante la ejecución del comando traceroute en sistemas operativos
Linux/Unix y con el comando tracert en Windows.
76
cercana entre 1,86, lo cual aumenta en un 2% la diferencia obtenida en el caso de acceder de
manera local.
2.2. DNS.
El rendimiento de un servicio de DNS virtualizado será estudiado en lo que respecta al servicio
de consulta y resolución de nombres externos. Otras tareas, como la creación y administración de
zonas y nombres de dominio para servidores internos, no fueron consideradas debido a que la
DSCS así lo consideró
La aplicación servidora utilizada será BIND DNS [15], la que por su uso extendido (sobre todo
en sistemas operativos Unix) cuenta con una amplia documentación y soporte.
La herramienta de evaluación de rendimiento utilizada fue la aplicación de código abierto
Namebench [16], distribuida bajo licencia Apache License 2.0 [12] y desarrollada para evaluar
la respuesta de servidores DNS. Namebench funciona generando consultas DNS con URLs [17]
disponibles en el computador cliente en el cual se ejecuta este programa. Estas URLs se toman
como información, del historial de navegación de los navegadores web del computador cliente.
Namebench permite generar un máximo de 2400 consultas DNS por evaluación.
Namebench se ejecutó sobre el sistema operativo Windows XP, pero con el mismo laptop de la
figura 1. Cada prueba dura entre 3 y 5 segundos, dependiendo de la cantidad de solicitudes
totales.
Los escenarios para esta prueba son los que se presentan en la tabla 4.
Número de consultas DNS totales 250 500 1000 1500 2000
Escenario E1 E2 E3 E4 E5
Tabla 5.4: Resumen de pruebas con Namebench
Los valores de carga seleccionados se han estimado considerando las estadísticas de uso del
servicio de DNS por parte de la DCSC.
A continuación se presenta el gráfico resumen de las evaluaciones realizadas. Para gráficos más
detallados ver la sección 2 de A1 en Anexos.
77
Figura 5.4: Gráficas de los escenarios obtenidas con NameBench.
78
En el gráfico se aprecian los resultados obtenidos en el caso del servidor físico (escenarios
terminados en fis) y de los obtenidos en el caso del servidor virtual (terminados en vir).
De los gráficos se puede inferir que existe una demora en los tiempos de respuesta de las
consultas en el caso del servidor virtual, comparado con el servidor físico, aunque al parecer esta
diferencia se hace menos notoria a medida que se aumentan las respuestas.
Otro hecho interesante es que, a medida que se aumentan el número de consultas totales,
aumenta la cantidad de respuestas que son atendidas antes de los 200 [ms]. Una causa de este
comportamiento puede ser que, considerando que existe una cantidad determinada de URL´s en
el historial de navegación del navegador de internet del cliente, a mayor cantidad de consultas
totales, existe una mayor probabilidad de que consultas a una URL se repita. Dado que el
servidor DNS tiene caché (es decir, se guardan un registro de consultas, a fin de obtener una
respuesta más rápida), los tiempos de respuesta a las consultas repetidas son menores. Otra causa
puede ser que dos o más de las consultas pueden ir a un mismo dominio. Un ejemplo de ello
sería el de una consulta a la URL www.ejemplo.com y otra a eventos.ejemplo.com. Dado que
ambas URL pertenecen al domino ejemplo.com y que el servidor DNS posee caché, la obtención
de una respuesta, tanto para www.ejemplo.com como para eventos.ejemplo.com será más rápida,
ya que el servidor DNS ya tiene información de la pertenecía de ambas URLs al mismo dominio
(ejemplo.com).
La Tabla 5 muestra los resultados de los tiempos totales (hasta que se atiende la última solicitud)
y de los tiempos promedios de respuesta, tanto para el caso del servidor físico como del servidor
virtual.
79
Escenario
Tiempo
Promedio
Físico (ms)
Tiempo
Promedio
Virtual (ms)
Razón de
Diferencia
Tiempo
Total
Físico (ms)
Tiempo Total
Virtual
(ms)
Razón de
diferencia
(ms)
E1 349,091 379,893 1,088 1795,451 1839,769 1,024
E2 304,729 315,391 1,034 1838,216 2023,525 1,101
E3 258,973 264,68 1,022 2244,692 2503,087 1,115
E4 213,823 219,528 1,026 2429,784 2695,024 1,109
E5 185,568 190,132 1,024 2705,03 3110,825 1,15
Tabla 5.5: Tiempos promedio y total para cada escenario
Si bien se cumplen las diferencias entre los valores de tiempo obtenidos entre el servidor virtual
y el servidor físico, se observa que la diferencia promedio tiende a disminuir y que la diferencia
total tiende a aumentar y la explicación está en lo mencionado anteriormente, es decir que
dependiendo de la URL, específicamente si es una ya previamente visitada, la diferencia entre
los tiempos de respuesta será menor que en el caso de una que no sea muy visitada.
Según datos de la DCSC, en la práctica DNS tiene cerca de 1000 consultas por minuto en
promedio, lo cual es cercano a lo que sucede en los escenario 2, donde la razón es de 1,034 en
promedio y de 1,1 para la última consulta. Es por esto que, la diferencia entre el tiempo de una
consulta a un servidor virtual, comparada con la respuesta de un servidor físico puede llegar a ser
de un 3,4% mayor en promedio y de un 10% para la última consulta.
Cabe mencionar que los valores en un escenario más real no diferirían en gran manera, ya que se
debe considerar que este servicio se utiliza dentro de la universidad. Se hace esta salvedad, dada
la proyección de diferencia entre los tiempos de respuesta entre un servidor virtual y un servidor
físico hecha para el caso de web, ya que en este caso no debería variar demasiado, haciendo que
en el peor de los casos sea cercano a un 10% mayor, en el caso del servidor virtual.
2.3. LDAP
El último de los servicios analizados fue LDAP. Este servicio se ejecutó con el software
OpenLDAP [18], desarrollado por The OpenLDAPProject. OpenLDAP es una de las
aplicaciones servidoras más utilizadas al momento de implementar este servicio y se encuentra
disponible para múltiples sistemas operativos, tales como Unix-BSD, Mac OS, Linux y
Windows. OpenLDAP se distribuye bajo su propia licencia, OpenLDAP Public License [19].
80
Debido a que las herramientas disponibles para evaluación de rendimiento de LDAP no
contaban con una documentación precisa [20], en este trabajo de título se desarrolló una
herramienta ad-hoc para realizar esta tarea. Dicha herramienta se desarrolló en lenguaje Bash
[21], dada la facilidad con la que se pueden manejar las órdenes hechas por línea de comando,
como por ejemplo, las consultas al servidor LDAP.
Respecto a los escenarios de prueba, se utilizaron los mismos de la evaluación de Apache. Es
decir, se realizó un número de consultas totales y un número de consultas ejecutadas de manera
simultánea. La diferencia es que estas consultas simultáneas son parte de las consultas totales, es
decir, que si se ejecutan 1000 consultas totales, con 10 consultas simultáneas, estas 1000
consultas estarán agrupadas en grupos de 10, por lo que equivaldrá a 100 grupos de 10 consultas
simultáneas.
Otra similitud con el caso de Apache es el sistema operativo que se utilizó para las pruebas en el
cliente, el cual será la distribución de Linux ArchLinux.
En la tabla 6 se presentan los escenarios de prueba para este caso.
Conexiones totales
500 1000 1500 2000 2500
Conexiones
simultáneas
10 E1 E3 E5 E7 E9
25 E2 E4 E6 E8 E10
Tabla 5.6: Escenarios de prueba para LDAP.
Los gráficos obtenidos tras la pruebas se muestran a continuación. La nomenclatura utilizada en
los gráficos es similar a las anteriores, donde fis representa los escenarios evaluados con el
servicio en el servidor físico y vir en el servidor virtual. Gráficos más detallados se presentan en
la sección 3 de A1 en Anexos.
81
Figura 5.5: Gráficas de los escenarios impares obtenidas con el script.
82
Figura 5.6: Gráficas de los escenarios pares obtenidas con el script
83
A simple vista, se observa que se cumple que el servicio ejecutado en servidor virtual demora
más tiempo que en el caso del servidor físico, aunque en el último escenario esta tendencia no es
tan marcada como en los otros escenarios, esto puede ser debido al nivel de tráfico en la red al
momento de realizar las pruebas en el caso del servidor físico, comparado con el nivel existente
en el caso del servidor virtual.
Respecto a los datos de los tiempos, tanto promedio como tiempo total, los valores obtenidos se
muestran en la tabla 7, a fin de hacer un análisis más cuantitativo. Al igual que para el caso de
Apache, se han dividido el análisis de los escenarios considerando el número de conexiones
simultáneas que se ejecutan.
Escenario
Tiempo
Promedio
Físico (s)
Tiempo
Promedio
Virtual (s)
Razón de
diferencia
Tiempo
Total
Físico (s)
Tiempo
Total
Virtual (s)
Razón de
diferencia
E1 1,547 1,765 1,141 3,03 3,433 1,133
E3 3,295 3,48 1,056 6,51 6,88 1,056
E5 4,589 5,204 1,134 9,091 10,32 1,135
E7 6,158 6,93 1,125 11,256 13,765 1,223
E9 7,188 8,513 1,184 13,377 16,96 1,268
E2 1,217 1,55 1,273 2,322 3,031 1,305
E4 2,477 2,777 1,121 4,768 5,414 1,135
E6 3,545 4,125 1,163 6,98 8,106 1,161
E8 4,693 5,459 1,163 9,278 10,792 1,163
E10 6,893 7,035 1,021 13,767 14,258 1,036
Tabla 5.7: Tiempos promedio y total para cada escenario
Analizando los valores de los tiempos obtenidos, se aprecia que se cumple una tendencia, la cual
muestra que los valores de los tiempos si bien disminuyen entre los primeros escenarios (E1 con
E3, en el caso de 10 y E2 con E4 en el caso de 25) los valores aumentan, salvo lo que ocurre con
el escenario 10, donde la diferencia de los tiempos promedio y total se hace es menor, haciendo
que esta tendencia no se cumpla para el caso de 25 consultas simultáneas.
Según las estimaciones de uso por parte de la DCSC, el servicio LDAP tiene una utilización de
2000 usuarios por cada 12 horas, lo cual encaja con los escenarios 7 y 8, los cuales tienen en
promedio una razón de diferencia de entre 1,125 y de 1,163 veces y de entre un 1,223 y 1,163 en
el peor de los casos, haciendo que el tiempo de respuesta en el caso virtual sea cercano a un de
entre un 12% (promedio) a un 22% (peor caso) mayor.
84
Considerando una consulta externa, se considera el mismo retardo considerado en el análisis de
Web, (entre 15 y 30 [ms]), lo cual no influye mucho en el tiempo de respuesta promedio
obtenido en los escenarios 7 y 8, por lo que la diferencia promedio no debería variar en gran
manera, pudiendo llegar a ser hasta un 22% mayor en el caso del servidor virtual
3. RESUMEN.
En este capítulo se cuantificaron los beneficios y desventajas de implementar virtualización en
servicios web, DNS y LDAP. Los beneficios se midieron en términos de reducción de servidores
físicos y ahorros en consumo energético. Las desventajas se analizaron en términos de la
degradación de los tiempos de respuesta de los servicios virtualizados respecto de cuando operan
directamente en un servidor físico.
Los resultados obtenidos mostraron que si bien existen diferencias, estas son mayores en el caso
de web, donde se reportan diferencias de entre un 60% y un 80% de aumento en los tiempos de
repuesta. En el caso de los servicios de DNS y LDAP son menores, llegando a ser del orden de
un 10% en el caso de DNS y de un 20% en el caso de LDAP.
85
4. BIBLIOGRAFÍA.
[1] [26] ALBITZ, Paul y LIU, Cricket. DNS and BIND. 5ta Ed. 1005 Gravenstein Highway
North, Sebastopol, CA 95472, Estados Unidos, O’Reilly & Associates, 2006.
[2] Intel Xeon Processor E5310 [en línea]
<http://ark.intel.com/Product.aspx?id=28030&processor=E5310&spec-
codes=SL9XR,SLACB,SLAEM> [consulta: 15 de marzo de 2011].
[3] Tarifas de suministro eléctrico - Chilquinta [en línea]
<http://www.chilquinta.cl/residenciales/files/2009/11/valores_tarifas_suministro_electrico.pdf>
[consulta: 21 de febrero de 2011]
[4] British termal unit – Wikipedia, the free encyclopedia [en línea]
<http://en.wikipedia.org/wiki/British_thermal_unit> [consulta: 16 de marzo de 2011].
[5] Frigoría – Wikipedia, la enciclopedia libre [en línea]
<http://es.wikipedia.org/wiki/Frigor%C3%ADa> [consulta: 16 de marzo de 2011].
[6] Dell PowerEdge 2950 Server Product Details [en línea]
<http://www.dell.com/us/dfb/p/poweredge-2950/pd?refid=pedge_2950&s=dfb&cs=28>
[consulta: 20 de marzoo de 2011]
[7] Ubuntu Server [en línea] <http://www.ubuntu.com/business/server/overview> [consulta: 20
de marzo de 2011].
[8] FreeBSD 8.1 [en línea] <http://www.freebsd.org/releases/8.1R/announce.html> [consulta: 20
de marzo de 2011].
[9] Arch Linux [en línea] <http://www.archlinux.org/> [consulta: 20 de febrero de 2011].
[10] The Apache HTTP Server Project [en línea] <http://httpd.apache.org/> [consulta: 20 de
marzo de 2011]
[11] March 2011 Web Server Survey | Netcraft [en línea]
<http://news.netcraft.com/archives/2011/03/09/march-2011-web-server-survey.html> [consulta:
20 de marzo de 2011].
86
[12] Licenses - Apache [en línea] <http://www.apache.org/licenses/> [consulta: 20 de marzo de
2011].
[13] Module Index – Apache HTTP Server[en línea] <http://www.apache.org/licenses/>
[consulta: 20 de marzo de 2011].
[14] ab – Apache HTTP Server [en línea] <http://httpd.apache.org/docs/2.0/programs/ab.html>
[consulta: 20 de marzo de 2011]
[15] BIND | Internet Systems Consortium [en línea] <http://www.isc.org/software/bind>
[consulta: 23 de marzo de 2011].
[16] Namebench – Open-source DNS Benchmark Utility – Google Project Hosting [en línea]
<http://code.google.com/p/namebench/> [consulta: 23 de marzo de 2011].
[17] Uniform Resource Locator – Wikipedia, the free enciclopedia [en línea]
<http://en.wikipedia.org/wiki/URL> [consulta: 23 de marzo de 2011].
[18] OpenLDAP, Main Page [en línea] <http://www.openldap.org/> [consulta: 25 de marzo de
2011].
[19] OpenLDAP Public License [en línea]
<http://www.openldap.org/software/release/license.html> [consulta: 25 de marzo de 2011].
[20] Cool Solutions: LDAP Benchmark Tester [en línea]
<http://www.novell.com/coolsolutions/tools/14046.html> [consulta: 25 de marzo de 2011].
[21] Bash (Unix shell) - Wikipedia, the free enciclopedia [en línea]
<http://en.wikipedia.org/wiki/Bash_%28Unix_shell%29> [consulta: 25 de marzo de 2011].
87
Capítulo 6
CONCLUSIONES Y TRABAJO FUTURO
1. CONCLUSIONES
En este trabajo de título se logró una implementación primaria de virtualización dentro de la
Dirección Central de Servicios Computacionales (DCSC). Esta implementación resultó en un
servidor de pruebas, actualmente operativo y que se encuentra ejecutando la herramienta de
código abierto KVM. En dicho servidor se realizaron las pruebas con los servicios de Web, DNS
y LDAP. Este conjunto de servicios virtualizados permitió satisfacer todas las necesidades
planteadas por la entidad. Actualmente, en el servidor se han realizado implementaciones
definitivas de algunos servicios, los cuales se ejecutan dentro de máquinas virtuales con sistemas
operativos Linux (CentOS), Windows (Server 2003) y FreeBSD. Ejemplo de esto, es el caso de
cPanel12
, una herramienta de administración de sitios web, además de servidores de archivo para
otras unidades dentro de la universidad y servidores de prueba para desarrollo de aplicaciones.
En total, se contabilizan hasta este instante, 6 máquinas virtuales en ejecución en el mismo
servidor físico utilizado en las pruebas.
En el proceso de análisis de distintas herramientas de virtualización disponibles en el mercado
fue posible notar las ventajas comparativas que ofrecen las herramientas de código abierto. En
términos de funcionalidades ofrecidas, en muchos aspectos compiten favorablemente con las
herramientas propietarias. Esto es una ventaja significativa para quienes se inician en el área de
la virtualización o bien para pequeñas y medianas empresas que desean implementar una
infraestructura básica utilizando virtualización de servicios.
El análisis posterior a la implementación permitió evaluar el impacto que la virtualización puede
tener en el desempeño de los servicios ofrecidos. En este sentido, se analizaron tanto los
beneficios (ahorro de servidores físicos y consecuente ahorro de consumo energético) como las
desventajas (retardos experimentados por el cliente de un servicio). De los beneficios, se pudo
cuantificar el ahorro mensual que se puede llegar a obtener, tanto en consumo de energía
eléctrica como en consumo en sistema de climatización al momento de retirar una unidad del
12
http://www.cpanel.net/
88
datacenter, ya sea de servidor o de computador. Dependerá de las unidades que realmente se
logren retirar, la cuantificación total de dichos ahorros.
Además de esto, también se abordó la principal desventaja de la virtualización, la que guarda
relación con los retardos que puede introducir en los tiempos de respuesta de un servidor virtual,
comparado con un servidor físico. En este contexto, se pudo determinar que los retardos varían
según el tipo de servicio a virtualizar, ya que en el caso de web, la respuesta de un servidor
virtual llegó a tener una diferencia de hasta un 86% comparado con la respuesta de un servidor
físico ejecutando este mismo servicio. En cambio, para los casos de DNS y LDAP, esta
diferencia fue menor, llegando a ser de un 10% en el caso de la primera y de un 22% para la
segunda.
Los resultados obtenidos en términos de beneficios y desventajas permitieron apreciar que para
muchos servicios, las desventajas en términos de retardo no son significativas, mientras que los
ahorros económicos pueden ser importantes. Esta tendencia parece ser la dominante en las
empresas hoy en día, lo cual se refleja en el hecho que virtualización de servicios se está
masificando en el mercado de las tecnologías de información y comunicaciones.
2. TRABAJO FUTURO.
Dentro de las extensiones que pueden abordarse a partir de este trabajo, se pueden destacar las
siguientes:
Desarrollar un plan de virtualización dentro de la entidad13, de manera de realizar un
estudio exploratorio que identifique qué otros servicios convendría virtualizar. Esto
conllevaría el desarrollo de un plan en el que se consideren aspectos de investigación,
pruebas, implementación en marcha blanca y una implementación definitiva de otros
servicios.
Analizar las respuestas de los servicios ya implementados o por implementar, de manera
de obtener nuevos datos y realizar nuevas proyecciones respecto de cómo responden los
13 Como en este caso de estudio: http://www.excellencegateway.org.uk/page.aspx?o=239359
89
servicios, considerando una plataforma con un mayor número de máquinas físicas y
virtuales en ejecución.
90
Anexos
A1: Gráficos detallados de las pruebas realizadas.
A continuación se incluyen los gráficos obtenidos de la evaluación de cada uno de los servicios.
En el caso de Web, se incluyen los tiempos descritos en la sección 1.3.1 del capítulo 5
1. WEB.
Figura A.1: Datos evaluación web, escenario 1
91
Figura A.2: Datos evaluación web, escenario 2
Figura A.3: Datos evaluación web, escenario 3.
92
Figura A.4: Datos evaluación web, escenario 4.
Figura A.5: Datos evaluación web, escenario 5
93
Figura A.6: Datos evaluación web, escenario 6
Figura A.7: Datos evaluación web, escenario 7
94
Figura A.8: Datos evaluación web, escenario 8
Figura A.9: Datos evaluación web, escenario 9
95
Figura A.10: Datos evaluación web, escenario 10
96
2. DNS
Figura A.11: Datos evaluación DNS, escenario 1
Figura A.12: Datos evaluación DNS, escenario 2
97
Figura A.13: Datos evaluación DNS, escenario 3
Figura A.14: Datos evaluación DNS, escenario 4
98
Figura A.15: Datos evaluación DNS, escenario 5
99
3. LDAP.
Figura A.16: Datos evaluación LDAP, escenario 1
Figura A.17: Datos evaluación LDAP, escenario 2
100
Figura A.18: Datos evaluación LDAP, escenario 3
Figura A.19: Datos evaluación LDAP, escenario 4
101
Figura A.20: Datos evaluación LDAP, escenario 5
Figura A.21: Datos evaluación LDAP, escenario 6
102
Figura A.22: Datos evaluación LDAP, escenario 7
Figura A.23: Datos evaluación LDAP, escenario 8
103
Figura A.24: Datos evaluación LDAP, escenario 9
Figura A.25: Datos evaluación LDAP, escenario 10
104
A2: Códigos de programas para mediciones
Se incluyen los códigos desarrollados para las pruebas, los cuales están escritos en lenguaje
Bash.
1. WEB
#!/bin/bash for i in {1..5} do for j in {1..2} do l=$(($i*500)) m=$(($j*50)) #Se muestra el comando a ejecutar echo "ab -n $l -c $m -g n$l""_c$m http://200.1.30.230 > n$l""_c$m"".txt #Ejecución del comando ab (apache benchmark) ab -n $l -c $m -g n$l""_c$m http://200.1.30.230/ > n$l""_c$m"".txt #Pausa entre mediciones sleep 30 done done
2. DNS
Recordar que para en este caso se utilizó el software Namebench (ver sección 1.3.2 del capítulo
5).
3. LDAP
3.1. ldap_test.sh
#!/bin/bash #$1=consultas totals / $2=consultas totales agrupadas (ie 500 en grupos de 10 = 50) / $3=cantidad de consultas totales (10 ó 25) i=$2 for j in {1..i} do #se llama al script que hace las consultas de grupo time ./ldap_test_2.sh $1 $3>> data_$1/ldap_time_$j.txt done
105
3.2. ldap_test_2.sh
#!/bin/bash #$1=consultas totals / $2= cantidad de consultas totales (10 ó 25) k=$(($2-1)) for l in {1..k} do # se arma el comando con las consultas en paralelo command=$command’ldapsearch -H ldap://200.1.30.230 -x -D \"cn=alara,dc=example,dc=com\" -b \"dc=example,dc=com\" -w 123456 \"cn=Alejandro Lara\" cn >> data_$1/file$k & ’ done # se agrega el la última linea al comando (sin & al final) command=$command’ldapsearch -H ldap://200.1.30.230 -x -D \"cn=alara,dc=example,dc=com\" -b \"dc=example,dc=com\" -w 123456 \"cn=Alejandro Lara\" cn >> data_$1/file$2’
$command
