Introducción a la infraestructura virtual: concepto y soporte físico

Introducción

En general y en informática, un recurso virtual es un recurso irreal, es decir, un recurso que no tiene equivalente físico directo. Así, memoria virtual es la memoria que, en realidad, está almacenada en parte en un disco o realidad virtual es un entorno inmersivo generado por ordenador que imita a la realidad (al menos en que se puede situar uno dentro de ella). Una infraestructura virtual será un recurso -procesador, memoria, disco, conjunto de aplicaciones o incluso una sola aplicación- que no corresponde exactamente a su equivalente real (no tiene un procesador físico, o un disco físico exclusivo) sino que se ha creado a través de una serie de mecanismos computacionales para funcionar como tal.

A partir de esto, un recurso en la nube es aquel al que se puede acceder bajo demanda, que es escalable y que, desde el punto de vista del usuario, se facturable según uso, no por el hecho de tener acceso.

El origen de la palabra viene de la tradicional representación de recursos en la red como una nube.

Desde el punto de vista del desarrollo, la creación y gestión de infraestructuras virtuales entra dentro del concepto de DevOps, un concepto que abarca tanto sistemas como desarrollo y que está a caballo de ambos. En primer lugar, DevOps implica la automatizació de las tareas de creación de un puesto de trabajo para desarrollo, pero también la sistematización de pruebas, de despliegue y de las tareas de configuración relacionadas con la misma, todo ello en un entorno de desarrollo ágil. En concreto, DevOps comprende los 7 aspectos siguientes, vistos en la página de una herramienta, Rex, usada para ello:

1. Automatización de tareas relacionadas con el desarrollo. En resumen, que no haya que recordar comandos para hacer todo tipo de cosas (instalación de librerías o configuración de una máquina) sino que haya scripts que lo homogeneicen y automaticen.

2. Virtualización: uso de recursos virtuales para almacenamiento, publicación y, en general, todos los pasos del desarrollo y despliegue de software.

3. Provisionamiento de los servidores: los servidores virtuales a los que se despliegue deben estar preparados con todas las herramientas necesarias para publicar la aplicación.

4. Gestión de configuraciones: la gestión de las configuraciones de los servidores y las órdenes para provisionamiento deben estar controladas por un sistema de gestión de versiones que permita pruebas y también controlar en cada momento el entorno en el que efectivamente se está ejecutando el software.

5. Despliegue en la nube: publicación de aplicaciones en servidores virtuales.

6. Ciclo de vida del software definición de las diferentes fases en la vida de una aplicación, desde el diseño hasta el soporte.

7. Despliegue continuo: el ciclo de vida de una aplicación debe ir ligado a ciclos de desarrollo ágiles en los que cada nueva característica se introduzca tan pronto esté lista y probada; el despliegue continuo implica integración continua de las nuevas características y arreglos, tanto en el software como el hardware.

Tecnologías de virtualización: un poco de historia

Tecnológicamente la computación nube se basa en el proceso progresivo de virtualización de recursos computacionales que ha tenido lugar prácticamente desde que se empezaron a usar los sistemas de tiempo compartido o time-share en los años 50. Estos sistemas convertían una sola máquina real en diversas máquinas virtuales, una por usuario. A estos sistemas se accedía mediante terminales tontos, con usuarios percibiendo un uso exclusivo de los recursos, es decir, teniendo acceso a un ordenador virtual

En realidad en estos sistemas la protección de memoria o de CPU era relativa; la virtualización de recursos en el sentido que la conocemos ahora tiene su origen en los mainframes de los 60. La línea temporal de tecnologías de virtualización sitúa en los años 60 el desarrollo de los primeros sistemas de memoria virtual por parte de IBM, con el primer monitor de máquinas virtuales hecho en los años 80 sobre el procesador 80286.

El concepto de red privada virtual o VPN (virtual private network) es posterior y comenzó a usarse en los años noventa, simultáneamente a lo que se puede considerar las primeras aplicaciones virtuales, los servicios de correo web tales como Yahoo o Hotmail, que son en realidad una virtualización de las aplicaciones de lectura del correo electrónico.

Todos los conceptos, por lo tanto, tienen origen en el pasado pero la computación nube tal como la conocemos resurge a principios de siglo por la potencia alcanzada por los procesadores y sobre todo por la existencia de soporte físico en los mismos para llevar a cabo virtualización de diferentes recursos tales como CPU, memoria, almacenamiento y red. Productos privativos como VMWare existen desde principios de siglo y otros libres, como Xen, desde el año 2003.

El primer servicio en tener esa denominación fue el elastic compute cloud, de Amazon, un servicio de creación de máquinas virtuales bajo demanda surgido en 2006. A partir de ese momento, se lanzaron diferentes servicios similares.

La virtualización de la infraestructura permite:

• Creación y configuración de la misma bajo demanda. En vez de desplazar a un técnico, o hacerlo remotamente, se puede automatizar la creación de un recurso (a base de recetas o plantillas) y llevarse a cabo cuantas veces se necesite.

• Simplificación del control y despliegue de recursos: permite usar diferentes sistemas operativos y en cada caso el más adecuado para la tarea que se requiera.

• Permite que el vendor aproveche mejor el hardware, usando la capacidad para servir a diferentes clientes a lo largo del día o de la semana y creando tanta infraestructura virtual como la física pueda soportar. Esto también reduce la cantidad de energía consumida.

• Portabilidad: una máquina virtual se puede mover físicamente de un ordenador a otro cuando sea necesario.

• Ahorro de costes iniciales en un centro de datos frente a una instalación tradicional, aunque eventualmente algunos negocios puedan optar, si tienen un uso intensivo y regular, en volver a una instalación tradicional.

Todas estas ventajas hacen que, en el año 2013, más de la mitad de los negocios americanos usan infraestructura virtual.

Tipos de virtualización

El término virtualización abarca diferentes técnicas y tecnologías que tienen todas el mismo objetivo: crear recursos que, desde el punto de vista de un programa, sean exclusivos. Cada una de las tecnologías necesita una aplicación determinada para usarse y, en muchos casos, soporte a nivel de hardware. En todo caso, el sistema operativo o aplicación que ejecuta las operaciones necesarias para virtualizar se denomina anfitrión y el que se ejecuta dentro de la máquina virtual invitado.

• La virtualización plena virtualiza todos los aspectos de un ordenador para poder ejecutar sistemas operativos y otros programas sin modificar. Las aplicaciones necesarias para llevarlas a cabo se llaman hipervisores o programas de control, y para que se consigan de forma completa necesitan soporte hardware tal como reescritura binaria y ensombrecimiento de estructuras de datos. La mayoría de los procesadores modernos de Intel y AMD tienen este tipo de soporte.

• La virtualización parcial sólo virtualiza algún recurso: la memoria, por ejemplo.

• La paravirtualización requiere modificación de los sistemas operativos

• La virtualización a nivel de sistema operativo sólo permite que anfitrión y cliente usen el mismo sistema operativo pero con invitados aislados del anfitrión y entre sí. En este caso, en vez de hablarse de máquinas virtuales se habla de jaulas, zonas o contenedores; generalmente se trata de aplicaciones de un sistema operativo determinado y el soporte suele estar a nivel del núcleo de los mismos.

• La virtualización de aplicaciones empaqueta aplicaciones de forma que se ejecuten en un entorno que las aísla del resto del sistema operativo; una parte es el uso de virtualización de escritorio que permite aplicar una serie de aplicaciones generalmente desde un navegador. En general, los programas necesarios se denominan emuladores; WINE (Windows Emulator) permite, por ejemplo, ejecutar aplicaciones de Windows sin modificación en Linux y CygWin crea un entorno similar para Windows, aunque en este caso las aplicaciones se tienen que recompilar. Programas como CDE en Linux permiten empaquetar aplicaciones para que se ejecuten de forma independiente en cualquier sistema operativo Linux.

• La virtualización de entornos de desarrollo es una práctica habitual en lenguajes de scripting tales como Perl, Python o Ruby. Se trata de reproducir entornos de producción de la forma más fiel posible, incluyendo las versiones de intérpretes y librerías usadas en el entorno de producción. Esta práctica permite también probar una aplicación en diferentes versiones con una sola orden. virtualenv, perlbrew rbenv o RVM son diferentes aplicaciones que permiten realizarlo para diferentes lenguajes.

En realidad, la contenedorización de aplicaciones puede usar las técnicas que se explican en el resto de la asignatura; de hecho, se pueden crear paquetes que permiten ejecutar una aplicación con todas las dependencias necesarias. Por ejemplo, docker es una aplicación que permite crear fácilmente aplicaciones contenidas desde línea de órdenes para su uso en cualquier tipo de contenedor, desde simples contenedores Linux hasta máquinas virtuales.

Desarrollo colaborativo y despliegue de aplicaciones: git

git es un programa distribuido de gestión de control de versiones. Se diseñó originalmente para la gestión de fuentes del núcleo de Linux, pero hoy en día se usa también de forma extensiva para despliegue de aplicaciones.

Un sistema de control de versiones permite saber a quién corresponde cada cambio en un fuente y revertir tales cambios si hay algún problema en los mismos. También permite trabajar simultáneamente con diferentes versiones y, eventualmente, fusionarlas conservando los cambios en las mismas. El hecho de que se puedan revertir los cambios y también integrarse en un flujo de desarrollo (que incluya integración continua, por ejemplo) es la clave de su popularidad en el despliegue de aplicaciones en la nube.

El ciclo básico de uso de git consiste, tras la clonación, en hacer pull - modificar - commit - push. Este último sincroniza la versión local con la versión remota. Se pueden hacer varios commits antes de hacer push; todos los cambios se subirán al hacerlo. En realidad el programa es mucho más complejo y admite múltiples cambios, pero a este nivel es suficiente con conocer esto.

Restricción y medición del uso de recursos: cgroups

Un primer paso hacia la creación de entornos y más adelante máquinas virtuales es la implantación de un mecanismo de contención a nivel del núcleo que permita segregar grupos de procesos y asignarles diferentes recursos, o limitar el uso de los mismos, según el grupo. En Linux esto se consigue usando los denominados grupos de control o CGROUPS, un mecanismo que se implantó por primera vez a principios de los años 90.

Los cgroups usan un mecanismo común a todos los Linux denominado sistemas de ficheros virtuales, igual que el sistema /proc presente en todos. En este caso, los que tienen soporte a nivel de kernel permiten crear un sistema de ficheros en /cgroups o en /sys/fs/cgroups a partir del cual se controla el uso de los mismos.

Si ese sistema de ficheros virtual está ya activado, se puede listar su contenido usando ls o el navegador de ficheros. Si no lo está, se monta con

mount -t cgroup cgroup /sys/fs/cgroup/

o

	mount -t cgroup cgroup /cgroup/

dependiendo de donde esté configurado.

En Ubuntu 14.04, por ejemplo, se monta por defecto y está en /sys/fs/cgroup. Si no, se puede instalar cgroup-lite para instalarlos cuando se arranque el sistema.

Dependiendo de cómo esté configurado, puede contener algo como esto

blkio.io_merged                   cpuset.memory_pressure
blkio.io_queued                   cpuset.memory_pressure_enabled
blkio.io_service_bytes            cpuset.memory_spread_page
blkio.io_serviced                 cpuset.memory_spread_slab
...

con diferentes ficheros, unos de lectura y escritura y otros de lectura, que permiten controlar y monitorizar la actividad de los diferentes grupos de control. O bien un simple systemd o

blkio  cpuacct  devices  hugetlb  perf_event
cpu    cpuset   freezer  memory   systemd

en caso de que cgroup-lite se haya instalado y esté funcionando.

Aviso: lo siguiente puede que no funcione, dependiendo de la configuración. Si se ha configurado con cgroup-lite no va a funcionar y sólo se podrán crear grupos dentro de directorios determinados.

Dependiendo de la configuración que se haya creado, crear un grupo de control es tan simple como crear un subdirectorio

mkdir /cgroup/buenos

aunque se tiene que hacer con permisos de superusuario, para lo cual, en Ubuntu, habrá que hacer

sudo su - root

La creación de ese grupo automáticamente hace que se creen una serie de subdirectorios específicos para cada grupo de control, tales como estos:

 ...
cpuset.cpu_exclusive              memory.usage_in_bytes
cpuset.cpus                       memory.use_hierarchy
cpuset.mem_exclusive              notify_on_release
cpuset.mem_hardwall               tasks

Este último es, precisamente, el fichero que contiene los PIDs de las tareas que vamos a regular. Por ejemplo, si queremos limitar todas las tareas iniciadas desde un intérprete de comandos, averiguamos el PID de ese intérprete con

ps aux | grep bash

por ejemplo y escribimos, también usando privilegios de root

echo 0 > /cgroup/malos/cpuset.cpus 
echo 0 > /cgroup/malos/cpuset.mems 

Estas dos órdenes son imprescindibles para asignar las CPUs por omisión de las tareas, y sin ellas no se podrá escribir en el siguiente fichero. En caso de tener varias CPUs, podemos usar el número de CPU en el que queremos que se ejecute cada grupo de control.

Una vez hecho eso, se asignan las tareas a cada grupo de control

echo xxx > /cgroup/buenos/tasks

Se puede crear otro grupo de control llamado malos, por ejemplo, procediendo de la misma forma, y no olvidando asignar las CPUs y las memorias antes que las tareas, o no te dejará escribir en las mismas.

Una vez hecho eso, cada grupo de control será gestionado de forma independiente y con las restricciones y límites que le impongamos. Podemos, por ejemplo, limitar el ancho de banda de la CPU:

echo 512 > /cgroup/buenos/cpu.shares

Aunque en este caso lo que hemos hecho ha sido aumentarlo del valor 1024 que se le asigna por defecto.

Lo más importante es la contabilidad que se hace por separado para cada uno de los grupos; los ficheros con el prefijo cpuacctnos darán información sobre uso; por ejemplo:

cat /cgroup/malos/cpuacct.usage

devolverá un valor similar a

72012663139

que nos dará una idea del uso de cada grupo en particular y nos permitirá comparar entre un grupo y otro.

En el caso en que cgroups viniera ya configurado en el sistema operativo, se puede trabajar de forma similar, pero limitando recursos específicos, por ejemplo, CPU, de esta forma

root@penny:/sys/fs/cgroup/cpu# mkdir alto
root@penny:/sys/fs/cgroup/cpu# mkdir bajo
root@penny:/sys/fs/cgroup/cpu# ls alto/
cgroup.clone_children  cpu.cfs_period_us  cpu.stat
cgroup.event_control   cpu.cfs_quota_us   notify_on_release
cgroup.procs           cpu.shares         tasks

Dentro de este directorio se pueden asignar diferentes procesadores mediante cgroup.procs o tareas específicas a uno u otro grupo. Instalar cgroup-bin te proporciona diferentes utilidades, como lscgroup o cgcreate que te crea grupos con el mismo nombre en todos los controladores que desees:

root@penny:/sys/fs/cgroup# cgcreate -g cpu,cpuacct:/good
root@penny:/sys/fs/cgroup# find . -name good
./cpuacct/good
./cpu/good

Esto se puede usar, entre otras cosas, para medir uso de recursos por parte de diferentes usuarios o grupos de aplicaciones. Por supuesto, también para aislar recursos y, por tanto, crear infraestructuras virtuales, pero esto se verá más adelante.

El paquete cgroup-bin (libcgroup en ArchLinux, puede variar en otras distros) permite un control por línea de órdenes algo más sencillo sin necesidad de trabajar directamente con sistemas de ficheros virtuales. Con una serie de órdenes o un fichero de configuración en /etc/cgconfig.conf se pueden controlar los diferentes grupos de control y limitar y contabilizar el uso de recursos por parte de los diferentes procesos que se hayan asignado en los grupos.

Los grupos se crean con la orden cgcreate:

sudo cgcreate -a un_usuario -g memory,cpu,cpuacct:teestoyviendo

Esta orden crea un grupo teestoyviendo que se encarga de controlar memoria, CPU y de contabilizar el uso de recursos de la CPU y da permiso a un_usuario para que trabaje con él. El resto de las órdenes que afecten a este grupo las podrá realizar este usuario. Por ejemplo, se pueden crear subgrupos con

cgcreate -g memory,cpu,cpuacct:teestoyviendo/wp
cgcreate -g memory,cpu,cpuacct:teestoyviendo/navegadores

Y cada uno de estos subgrupos se podrá controlar por separado, teniendo su subdirectorio correspondiente dentro de /sys/fs/cgroup/(memory|cpu|cpuacct) .

Esta librería tiene otra orden, cgexec, para ejecutar órdenes dentro de un grupo determinado, de forma que no haya que añadir el PID de un proceso a un fichero dentro del sistema de ficheros virtuales anterior.

cgexec   -g memory,cpu,cpuacct:teestoyviendo/wp lowriter

Con cgclassify, para finalizar, podemos cambiar un proceso de grupo. La sintaxis es la misma que en el caso de cgexec (es decir, usa la opción -g) pero habrá que pasarle un número de proceso.

Si se quiere trabajar con usuarios en vez de procesos, se puede usar cgrules, un fichero de configuración que permite especificar a qué grupo pertenece cada usuario e incluso qué comandos de qué usuario deben pertenecer a cada grupo. Con ello se le puede asignar, por ejemplo, más prioridad en la CPU o entrada/salida a unos usuarios que a otros.

Virtualización a nivel de hardware

Los sistemas operativos modernos ofrecen puentes para poder usar las capacidades de virtualización que contienen los procesadores de sobremesa y portátiles modernos. Hay dos tecnologías principales dentro del mundo x86: VT-x de Intel y AMD-V. En algunos casos, esta tecnología está desactivada en la BIOS, por lo que habrá que comprobar si está activada o no en nuestro caso particular. Para hacerlo se usa este comando en Linux:

egrep '^flags.*(vmx|svm)' /proc/cpuinfo

/proc/cpuinfo es el fichero del sistema de ficheros virtual /proc que da acceso mediante “ficheros” a las estructuras de datos del núcleo de Linux; cpuinfo lista las características de la CPU y vmx es el flag que se usa para indicar que el procesador usa esta tecnología; smd es el flag para AMD-V. egrep busca líneas de un fichero que contengan la expresión regular indicada, y si aparecen los flags listará la línea completa. Si no lista nada, entonces es que el procesador no tiene esa funcionalidad o está desactivada.

Lo que implementan estas tecnologías son una serie de instrucciones para proteger zonas de memoria, crear máquinas virtuales anidadas y facilitar la virtualización de los buses de entrada/salida.

Normalmente esta aceleración hardware de la virtualización no se expone directamente al usuario, sino que se añade una capa de abstracción en el sistema operativo que, habitualmente, no distingue entre la aceleración de hardware usada. Esta capa se incluye en el núcleo del sistema operativo y se expone de alguna forma (a través de un dispositivo virtual, por ejemplo) para que los hipervisores o aplicaciones para gestionar máquinas virtuales puedan usarlo.

Esta infraestructura en Linux se llama KVM, Kernel-based Virtual Machine (aunque también se ha usado en otros sistemas operativos). Este dispositivo se encarga de gestionar la aplicación de memoria del invitado al anfitrión, crear los dispositivos virtuales de entrada salida y presentar la salida de vídeo del invitado en el anfitrión. En realidad, KVM tampoco se usa directamente en general (aunque es una parte del núcleo con sus características como cualquier otra) sino que lo habitual es que se use a través de hipervisores tales como QEMU. KVM sólo está activado si puede usar la aceleración por hardware del procesador.

Niveles de infraestructura virtual

Ya se ha visto en este tema dos niveles de virtualización diferentes, pero desde el punto de vista comercial se habla de tres niveles: Infrastructure, Platform y Software as a service

El nivel superior consiste en una aplicación que, en vez de trabajar de forma autónoma en el ordenador, tiene una parte contenida en el servidor. Aunque el desarrollo de las mismas tiene técnicas propias y el objetivo de la asignatura es crear una aplicación que se pueda vender como un SaaS, el principal foco de la asignatura será los dos primeros niveles: Infraestructura como Servicio y Plataforma como Servicio. La mayoría de los temas están dedicados a la creación, diseño y mantenimiento de IaaS, por lo que dedicaremos especial atención en este tema al nivel PaaS.

A diferencia del IaaS, que proporciona algo similar al bare metal o capacidades de máquina (CPU, almacenamiento, entrada salida y red) que uno puede configurar y usar según necesidad, un PaaS contiene infraestructura y una pila de soluciones o solution stack completa que permita desplegar en el mismo nuestras propias aplicaciones.

En realidad, pocos vendedores ofrecen simples IaaS. Lo más normal es que permitan usarlos a ese nivel, pero a la vez tengan un sistema fácil para añadir funcionalidad y combinarla en una pila completa de soluciones que incluya el sistema de almacenamiento de datos y el marco web de aplicaciones, junto con sistemas de monitorización y de análisis de las peticiones. Es difícil hoy en día (año 2014) encontrar un IaaS simple, de hecho.

A dónde ir desde aquí

En el siguiente tema veremos como usar sistemas de plataforma como servicio. Previamente habrá que realizar la práctica correspondiente a esta materia.