Con el paso de los años la virtualización se ha convertido en algo habitual en nuestro entorno de trabajo.
¿Que comercial no tiene instalado un VirtualBox para mostrar un producto a sus clientes?
¿Que desarrollador no lo usa para comprobar si algo funciona con el IExplorer o en un entorno de preproducción?
¿Quien no ha oído hablar del cloud computing?

¿A quien va dirigido esto?

Si ya usas virtualización de forma habitual espero enriquecer tu punto de vista con mi propuesta final.
Si no usas virtualización es cuestión de poco tiempo que la acabes usando así que también te interesa.
Si acabas de entrar en este mundillo. ¡Bienvenido al club!

En esta entrada hablaré de su aplicación en una sala de máquinas.

Al final propondré la que a mi me parece la solución óptima en virtualización.

¿Porque usarla?

Lone Star: Escucha. No estamos haciendo esto por dinero.
Vomito mira a Lone Star con cara de sorpresa.
Lone Star: ¡Lo estamos haciendo por un montón de dinero!
De la película "Spaceballs", cuando Lone Star y Vomito van a rescatar a la princesa Vespa.

La virtualización en una sala de máquinas

En Andago tenemos varias máquinas virtuales compartiendo el mismo hardware y estamos muy contentos con el sistema. Se ahorra tiempo de gestión y dinero en hardware.
En la tabla de abajo se muestra de forma gráfica como son las soluciones sin virtualización, con virtualización usando xen o kvm y en que se podría convertir si las cuentas no me fallan usando openvz.

Un servidor con 8GB de RAM y 1 GB asignado a cada servidor virtual se convierte en ...

Sin virtualización	Usando Xen	Usando OpenVZ

Hay vida mas alla de VirtualBox

Así de cabeza, se me ocurren media docena de sistemas de virtualizacion: kvm, xen, openvz, qemu, vbox y bochs.
Intentar comparar todos estos sistemas es como intentar comparar a Maestro Yoda con un yogurt así que voy a cometer una serie de imprecisiones para poder hacerlo.

Unas pocas definiciones

Tipos de virtualización

Virtualización por software

Consiste en emular una computadora por software. Las peticiones del SO cliente las recibe el software virtualizador y las responde el mismo.
Es un sistema de virtualización muy lento.

Virtualización por hardware

En los procesadores puede existir una parte dedicada a la virtualización. Si el software de virtualización lo usa, la velocidad de las virtuales es casi la misma que si no estuvieran siendo virtualizadas.

Paravirtualización

Utilizando el núcleo del anfitrión se arranca el software de la virtual. Todas las virtuales y el servidor comparten el mismo núcleo.
No necesita unos requerimientos especiales hardware y el rendimiento obtenido es prácticamente el mismo que si se lanzaran los procesos directamente en el servidor anfitrión.

Migración de una maquina virtual

Consiste en mover una virtual de un servidor a otro de forma automática.
Pongamos por caso que tenemos un par de servidores físicos y en uno de ellos hay una virtual que está haciendo un uso intensivo del hardware porque ... está ejecutando el algoritmo de los números primos.
Lo lógico es migrarla al que tenga menos carga.
También puede ser útil por fallo hardware, actualizaciones del anfitrión y otros motivos muy interesantes que no voy a analizar en esta entrada.

Migración con parada

El proceso para la máquina virtual y la arranca en el servidor de destino.

Migración en vivo

La máquina se congela guardando su estado y se pasa al servidor destino donde se descongela. Es casi imprescindible usar almacenamiento compartido para no tener que migrar los datos del disco.
Por ejemplo en xen se hace una copia de la memoria al servidor destino, se congela en el origen, se hace una última sincronización de la memoria y se arranca en el destino. El tiempo de parada es de unos 10 segundos. El virtual solo nota que "le han abducido" durante un rato.
Si el almacenamiento no es compartido la migración en vivo tarda tanto que las conexiones dan un timeout así que no me parece muy útil.
Aunque esta característica a priori es una pasada, en el año que llevo usando el clustercillo de Xen (diré como se monta en otra entrada), el único motivo por el que he necesitado migrar en vivo ha sido por tareas de mantenimiento del propio cluster de Xen. Vamos, que si no hubiera podido hacerlo tampoco lo hubiera necesitado. Además, el aumento de la complejidad debido a la implementación del cluster redujo la disponibilidad del mismo (los servidores se caían cada dos por tres).

Imágenes de expansión dinámica vs tamaño fijo

Las primeras se crean con un tamaño de unos pocos KB y se van ampliando automáticamente a medida que se va necesitando. Esto hace que la virtual vaya más lenta por lo que es recomendable usar un tamaño fijo para las imágenes.
Además, la gestión de las imágenes de tamaño fijo es mucho más sencilla.

Hablemos de coches ;-)

Para saber que es lo que queremos primero necesitamos saber para que lo vamos a usar.

Microcar (openvz)

Puede ir por el carril bus, no paga zona hora, 3 litros a los 100, 6000 euros, poca capacidad de carga, perfecto para ciudad.

Turismo (virtualbox, qemu, kvm)

6 litros a los 100, 12000 euros.

Camión (xen, kvm)

Mayor capacidad de carga, 30000 euros, 12 litros a los 100.

Un repaso a los sistemas de virtualización más importantes

En el principio era qemu

qemu es el primer software de virtualización que recuerdo. Su rendimiento es tirando a malo ya que hace virtualización por software, pero viene muy bien por partes de su software que se han usado en otros proyectos como xen o kvm.
Otra cosa muy usada de qemu son sus formatos de disco tanto para Xen como para KVM.
También se usa para emular diferentes arquitecturas tal como se hace en el proyecto openmoko, en el que se usa el qemu-arm para lanzar su emulador y poder programar sin el móvil a mano.

qemu + vt = KVM = Kernel-based Virtual Machines

KVM son todas las cosas buenas de qemu pero usando además la virtualización por hardware. Por ello se obtiene un rendimiento muy bueno y se puede usar "profesionalmente" tanto en grandes sistemas como en PCs de escritorio.
Parece que KVM es la elección de los desarrolladores de linux para solucionar el problema de la virtualización. Tienes que comprender que igual que existe un controlador para tu tarjeta de sonido también tiene que haber un "controlador" para esa zona del procesador que permite la virtualización por hardware.
Parece que RedHat también tira por KVM.

VirtualBox

Es muy bueno para virtualización en escritorio y quizás por ello sea el más conocido.
Ahora mismo no existe una versión libre para servidores así que no nos sirve para una sala de máquinas.

Xen

En este momento xen es todo lo que le puedes pedir a un sistema de virtualización si dispones de mucho dinero para invertir en él.
Con Xen podrás hacer lo que quieras y las máquinas virtuales tendrán un rendimiento muy bueno.
En este momento para mi es el mejor virtualizador por hardware que existe y el peor paravirtualizador que existe, lo cual tampoco está mal porque solo conozco dos.

Voy a explicar su funcionamiento porque es bastante distinto a lo habitual.
En xen a las maquinas virtuales se les llama dominios.
Cuando se arranca el servidor, en apariencia vemos como carga grub y núcleo para luego arrancar el init con todos los demás procesos y sacar el login. En realidad, lo que ocurre tras la carga del núcleo se hace dentro de una máquina virtual llamada Dom0 (dominio 0) desde la que se permite tener acceso directo al servidor de Xen. A todos los dominios creados a partir de ese momento desde el Dom0 se les llama DomU (Dom1, Dom2, Dom3, ...).
A cada uno de los dominios hay que reservarles memoria y disco. Esos recursos solo los puede utilizar el dominio al que han sido asignados. Incluso hay que asignar bastante memoria al Dom0 para que sea capaz de manejar ficheros grandes que se usarán en la manipulación de los discos virtuales.

En cuanto a la paravirtualización de xen, se facilita un poco la gestión de los dominios pero tampoco demasiado y hasta donde yo se consume los mismos recursos.

La gran pega de Xen es que el servidor en el que funciona solo va a poder ser un servidor de Xen así que siempre tendrás un buen virtualizador por hardware y un horrible paravirtualizador.

OpenVZ

Lo que voy a explicar ahora es "mentira" pero es muy didáctico así que créetelo de momento.

Es totalmente distinto al resto. En realidad, virtualizar, virtualizar, lo que se dice virtualizar no virtualiza nada.
Para que nos entendamos es como si copias un sistema completo a un directorio, le haces un chroot y ejecutas "init". A ese init, y por tanto a todos sus hijos, se le asigna una cuota de disco, memoria, procesador, una IP, ... de tal forma que si te conectas por ssh a ese entorno chroot (o enjaulado) tu jurarías por tus muelas que estás es un servidor físico ... con ciertas salvedades.
Por ejemplo, si intentas abrir un dispositivo tun para usar openvpn no podrás a menos que se te permita de forma explícita desde el sistema anfitrión.
Pero por otro lado el rendimiento obtenido es el mismo que si no se estuviera dentro de una máquina virtual.

En OpenVZ a las "máquinas virtuales" se les llama "contenedores".

Al usar por fuerza el núcleo del anfitrión nos encontramos con la gran limitación de este sistema: solo se pueden crear contenedores de sistemas Linux. Si necesitas instalar un OpenSolaris con este sistema no vas a poder.

La gran ventaja de este sistema respecto al resto es su aprovechamiento de recursos y su facilidad y rapidez de gestión. Eso se traduce en "un montón de dinero".
¿No me crees? Mira los precios que ofrece HostEurope con su OpenVZ.

Pongamos que tienes un PC con 4 GB de RAM. Puedes instalar 4 servidores con 2GB de RAM cada uno.
No me he equivocado con los números ni hago magia, es OpenVZ.
En la próxima entrada explicaré como hacerlo.

En cuanto a la gestión de los recursos, es muy eficiente. Por poner un ejemplo, si te piden que aumentes el espacio en disco de una virtual solo tendrás que ejecutar un comando y la virtual verá que tiene más disco de forma instantánea. No hay tiempo de parada.

Otro tema importante es el backup. Usando openvz solo será necesario hacer backup del servidor anfitrión y se hará de todos sus contenedores, ya que estos están situados en /var/lib/vz/private/101/.

Asignación de recursos con un sistema de virtualización por hardware

Para simplificar supongamos que solo podemos asignar uso de disco y memoria.

La memoria

El disco suele ser un problema en todos los sistemas por ser extremadamente leeeento. Imagina 10 máquinas virtuales que se quedan sin memoria física y empiezan a usar la memoria virtual machacando el disco. Un servidor virtual no puede quedarse sin memoria para usar la swap bajo ningún concepto o el rendimiento del sistema empezará a caer en picado.
Así que hay que asignar toda la RAM que previsiblemente vaya a utilizar el servidor virtual. Hacer esto tiene como consecuencia que gran parte de la memoria se quede reservada pero sin uso. En mi caso hemos llegando a un estado en el que el 69% de la memoria asignada a virtuales no se está usando. En mi caso estamos hablando de 80 GB a unos 35 euros el GB de memoria de servidor inutilizables ... y creo que todos sabemos multiplicar en la sala.

El disco

Con el disco ocurre mas o menos lo mismo solo que el disco es un poco más barato. Si una máquina necesita 5GB se le acaban dando 10GB o 15GB por si los necesitara.

Conclusiones

Cambios en la memoria solo implican un reinicio de la virtual pero en el disco implica parar el servidor, aumentar el espacio físico, redimensionar el sistema de ficheros y arrancarlo. Es decir, un tiempo de parada importante.

Con todo esto quiero decir que la virtualización por hardware no hace un buen aprovechamiento de recursos.
Tampoco debe hacerlo porque no es su objetivo. Su objetivo es que el sistema operativo cliente "vea" un hardware completo y eso lo hace bien, pero ¿es ese nuestro objetivo o solo necesitamos separar servicios dentro del mismo servidor?

El sistema de virtualización perfecto

Para mi es el que incluye el mejor paravirtualizador y el elegido de los virtualizadores por hardware: KVM+OpenVZ (podemos llamar a la solución KVZ para abreviar).

En los casos en los que tengamos que virtualizar algo que no sea linux o estemos hablando de una máquina de preproducción para un cliente externo no nos quedará otra que usar KVM.

En caso de virtualizar un Linux se usará OpenVZ y se le dará la memoria y disco que necesite como cuota blanda para darle una cuota dura del doble de lo pedido. En un servidor con 8GB de memoria cabrían 7 servidores con 2GB de memoria asignada. El primero en cuota blanda y el segundo en cuota dura.

Y si has llegado hasta aquí te mereces un chiste malo:
- ¿Como se llama usted?
- Me llamo bienvenido.
- Anda, como mi felpudo.

El álbum de hoy

Un album con muy buena música de piano aunque por la primera canción no lo parezca: