Open Nebula como plataforma para computación en la nube II…
En la entrada anterior instalamos y configuramos Open Nebula para que funcionara sobre un sistema de virtualización Xen bajo el sistema operativo Debian. Ahora en esta entrada vamos a ver cómo configurar todos los elementos necesarios para empezar a instanciar máquinas virtuales y a distribuir los recursos bajo nuestra disposición.
Una vez instalada toda la plataforma de Open Nebula, básicamente hay que seguir estos pasos para empezar a trabajar:
- Definir los clústers y los nodos
- Definir las redes que pueden ser utilizadas por las máquinas virtuales
- Definir las imágenes a utilizar por las máquinas virtuales
- Definir las instancias de las máquinas virtuales
- Contextualización de las máquinas virtuales
=== Definición de clústers y nodos
Desde la versión 2.0 de Open Nebula es soportada la creación lógica de clústers. Por defecto, todos los nodos que añadimos en Open Nebula se añaden al cluster default. Esta característica le permite a los administradores agrupar los nodos a su conveniencia para una mejor organización ya administración de su plataforma. La administración de los clústers se puede realizar a través del comando onecluster.
Para la administración de los nodos se utiliza el comando onehost y a través de este podemos agregar y eliminar los nodos de nuestra plataforma en Open Nebula. En nuestro ejemplo utilizaremos 4 nodos, y si nos fijamos en la entrada anterior, se ha configurado Open Nebula para que utilice Xen como tecnología de virtualización y NFS como tecnología de transferencia, entonces para agregar nodos hacemos lo siguiente:
- onehost create nodo01 im_xen vmm_xen tm_nfs
- onehost create nodo02 im_xen vmm_xen tm_nfs
- onehost create nodo03 im_xen vmm_xen tm_nfs
- onehost create nodo04 im_xen vmm_xen tm_nfs
Lo que hacemos es agregar uno a uno los nodos que conforman nuestra red, en nuestro caso los llamamos nodo01..04 y para que funcione así deben estar agregados en el archivo /etc/hosts de la máquina frontend. Luego de agregar los nodos deberíamos poder visualizarlos con el comando onehost list y mostrar algo parecido a esto:
Si se quiere usar KVM en lugar de Xen para la virtualización solo se debe cambiar im_ xen por im_kvm y vmm_xen por vmm_kvm. Igualmente, si se quiere utilizar SSH para la transferencia se sustituye tm_nfs por tm_ssh. En la imagen vemos los 4 nodos en Open Nebula.
=== Definición de redes
En Open Nebula es necesario definir las redes virtuales con las direcciones que serán utilizadas por las máquinas virtuales. Se pueden definir tantas redes sean necesarias. Se pueden definir dos tipos de redes: ranged y fixed. La red tipo ranged sirve para definir redes por medio de una dirección de red base y un tamaño de red. La red de tipo fixed consiste en una lista de direcciones IP fijadas o no a través de las direcciones mac de las interfaces de las máquinas virtuales. Para ambos tipos es necesario definir las siguientes variables: NAME, TYPE, PUBLIC, BRIDGE. Una red tipo fixed ejemplo sería la siguiente y que utilizaremos durante todo la entrada. Para definir una red virtual sólo debemos crear un archivo de texto con un contenido similar como al que se muestra a continuación, cambiando por supuesto los parámetros a conveniencia. Podemos llamar el archivo publica.net, por ejemplo, y una vez creado el archivo se utiliza el comando onevnet para crear la red.
- onenvnet create publica.net -v
NAME = “Publica”
TYPE = FIXED
PUBLIC = YES
BRIDGE = xen-br0
LEASES = [IP=172.26.18.100]
LEASES = [IP=172.26.18.101]
LEASES = [IP=172.26.18.102]
.
.
.
LEASES = [IP=172.26.18.148]
LEASES = [IP=172.26.18.149]
LEASES = [IP=172.26.18.150]
GATEWAY = 172.26.1.1
DNS = 172.26.16.4
Esta definición indica que tendremos una red virtual llamada Publica, de tipo fixed, que se comunicará con nuestra interfaz de red a través del puente xen-br0 y que tiene un rango de IPs desde la 172.26.18.100 hasta la 172.26.18.150. Adicionalmente se ha definido el gateway y la dirección del servidor DNS. Al ejecutar el comando onevnet list nos debería mostrar la siguiente información:
Ya con este paso tenemos la red virtual configurara, con direcciones IP disponibles para que sean utilizadas por las instancias virtuales.
=== Definición de imágenes
En Open Nebula antes de tener instancias virtuales ejecutándose en el sistema es necesario tener imágenes en el repositorio y definidas en el sistema. Las imágenes no son más que copias enteras de un sistema de archivos de un sistema operativo GNU/Linux o simplemente un disco virtual que se puede adjuntar a otra máquina virtual para utilizar como almacén de datos. Open Nebula maneja las imágenes de manera similar a como se definen las redes virtuales, se crea un archivo de texto con todas las variables y definiciones y luego se registra la imagen. Al registrarse la imagen, Open Nebula sube a su repositorio de imágenes el archivo y lo coloca a disposición del creador o a todos los usuarios según su definición. El directorio del repositorio de imágenes de Open Nebula se encuentra en la máquina frontend y según la guía anterior lo definimos en /srv/cloud/images.
Un archivo de definición de imagen es similar a este:
NAME = “Imagen 1 Debian 6.0”
PATH = /ruta_al_archivo_imagen/disk.img
PUBLIC = NO
PERSISTENT = YES
DESCRIPTION = “Imagen con Debian Squeeze”
En esta imagen que hemos definido hemos colocado un nombre, especificamos la ruta hasta el archivo de la imagen, especificamos que no es pública, que es persistente y añadimos una pequeña descripción. Las variables PUBLIC y PERSISTENT están definidas por defecto en NO. Si especificamos que no es pública entonces la imagen no podrá ser utilizada por todos los usuarios sino sólo por el usuario que la registró. En el caso de la persistencia, si especificamos que la imagen es persistente, entonces podrá ser utilizada por una sola instancia virtual, ya que todos los datos que se generen en la sesión se guardarán en la imagen y ésta volverá modifcada al repositorio, si por el contrario, se especifica que no es persistente, la imagen podrá ser utilizada por varias instancias virtuales y al finalizar la sesión estas copias se borrarán y la imagen en el repositorio no se modificará.
El repositorio de imágenes, como fue definido en los pasos de la entrada anterior, está ubicado en la máquina frontend en el directorio /srv/cloud/images. Para registrar una imagen basta con crear un archivo de texto con las variables y valores mencionados anteriormente, guardarlos en un archivo llamado debian.img, por ejemplo y ejecutar:
- oneimage register debian.img
Esto tardará algunos minutos ya que se estará subiendo el archivo imagen hasta la máquina frontend.
Al registrar la imagen podemos verla con el comando oneimage list y debería mostrar una información paracida a la siguiente:
Con esto ya tendremos una imagen que puede ser utilizada por una instancia virtual. Se pueden agregar cualquier cantidad de imágenes al repositorio siempre y cuando exista espacio. Como recomendación sugiero utilizar las imágenes que se crean con el comando xen-create-image, que viene en el paquete xen-tools.
=== Definición de instancias (máquinas) virtuales
Luego de definidas las imágenes virtuales, éstas ya pueden ser utilizadas por instancias virtuales. Al igual que en los dos pasos anteriores, la definición de una máquina virtual se plasma sobre un archivo de texto plano que podemos nombrar como mejor nos parezca. Para motivos del ejemplo lo llamaremos debian.one y tendrá definida las variables y los valores de nuestra instancia virtual. Entonces, la definición de una máquina virtual quedaría de la siguiente forma:
NAME = debian01
OS = [ KERNEL = /boot/vmlinuz-2.6.32-5-xen-amd64,
INITRD = /boot/initrd.img-2.6.32-5-xen-amd64,
ROOT = xvda2,
BOOT = xvda
]
DISK = [ IMAGE_ID = 16,
TARGET = xvda2,
READONLY = no
]
DISK = [
type = swap,
size = 1024,
readonly = “no”,
target = xvda1
]
MEMORY = 512
CPU = 1
VCPU = 1
NIC = [ NETWORK = “Publica”, IP=172.26.18.140]
CONTEXT = [
hostname = “$NAME”,
files = “/srv/cloud/one/plantillas/contexto/init.sh”,
target = “xvdb”,
ip_public = “$NIC[IP, NETWORK="Publica"]”
]
En primer lugar hemos definido una variable NAME cuyo valor es debian01 y no es más que el nombre de esta instancia virtual, luego tenemos una variable macro que contiene más variables dentro de sí, llamada OS y que refiere a lo necesario para que el sistema operativo arranque. Dentro de OS se define una variable KERNEL, que apuntamos hacia el kernel del sistema anfitrión, e igualmente el disco ram inicial en la variable INITRD, también especificamos, en la variable ROOT, el dispositivo que contiene el sistema de directorios del sistema operativo a instanciar y por último el dispositivo en donde se encuentra la marca de arranque en la variable BOOT.
Luego de definir la variable macro OS, tenemos otra llamada DISK, que es en donde definimos los discos que tendrá el sistema operativo, pueden ser tantos como necesitemos y de diversis tipos. En nuestro ejemplo definimos el primer disco con una variable anidada IMAGE_ID con la cual hacemos referencia al identificador de la imagen que registramos en el paso anterior, luego en TARGET definimos el punto de montaje de dicha imagen y por último una variable READONLY que especificamos en no ya que necesitamos escribir y borrar datos de la imagen. Otra manera de definir la imagen a utilizar es mediante la variable IMAGE con el nombre de la imagen como valor de la variable.
El segundo disco de nuestra instancia virtual es de tipo swap, que hará las veces de área de intercambio. Para ello definimos una nueva variable macro DISK y de manera anidada definimos las variables type, size, readonly y target, con los valores que pueden ver en el ejemplo. Le decimos entonces que será un disco swap de 1 gb de tamaño y su punto de montaje será xvda1.
Luego en la variable MEMORY especificamos la cantidad de memoria real que la instancia tendrá, en nuestro caso 512 megabytes, que tomará del sistema anfitrión. En las variables CPU y VCPU especificamos la cantidad de núcleos del procesador que la instancia virtual tomará del sistema anfitrión.
La variable macro NIC es la que contiene los parámetros para las interfaces de red de nuestra instancia virtual. En nuestro ejemplo especificamos que estará en la red Publica mediante la variable NETWORK y que la dirección ip que tomará del pool será la 172.26.18.140, esto definido en la variable IP.
El siguiente bloque en la definición de la instancia virtual, que se agrupa bajo la variable macro CONTEXT, es el que proporcionará los valores para la configuración de la instancia virtual una vez haya arrancado. En nuestro ejemplo definimos el nombre del host o de la instancia virtual que estamos virtualizando, valga la redundancia, indicamos la ruta a un archivo que se ejecutará al momento del arranque de los servicios en la instancia virtual, especificamos el destino en donde se montará el dispositivo que contiene los archivos de contexto y finalmente especificamos de nuevo la dirección ip que tomará la instancia para que internamente realice la configuración de las interfaces de red. El proceso de contextualización de las instancias virtuales nos permite proporcionarle las características únicas que requieren las instancias para ser diferenciadas de las otras. Open Nebula crea un disco virtual con los archivos que se requieren para darle contexto a la instancia virtual, que se montará como un disco en la instancia virtual mientras está levantando y ejecutará las acciones que especificamos en los scripts incluídos.
En nuestro ejemplo hemos enviado sólo un archivo, llamado init.sh que contiene lo siguiente:
#!/bin/bash
if [ -f /mnt/context.sh ]
then
. /mnt/context.sh
fi
echo $HOSTNAME > /etc/hostname
hostname $HOSTNAME
echo 127.0.0.1 $HOSTNAME » /etc/hosts
if [ -n “$IP_PUBLIC” ]; then
ifconfig eth0 $IP_PUBLIC
route add default gw 172.26.18.1
fi
if [ -n “$NETMASK” ]; then
ifconfig eth0 netmask $NETMASK
fi
Este pequeño script básicamente verifica en primer lugar que en el directorio /mnt exista un archivo llamado context.sh y si existe lo ejecuta. Luego inserta el valor de la variable HOSTNAME dentro del archivo /etc/hostname, ejecuta el comando hostname con el valor de la variable anterior, agrega localhost dentro del archivo /etc/hosts. En los dos últimos bloques de código, se verifican que las variables no estén vacías y se ejecutan las instrucciones dentro de los condicionales. En el primer caso se le asigna la dirección ip a nuestra instancia, en nuestro ejemplo 172.26.18.140 y se agrega el gateway por defecto. En el segundo condicional sólo especificamos la máscara de red.
El archivo context.sh, que no especificamos en ninguna parte, es generado automáticamente por Open Nebula una vez añadimos el bloque CONTEXT en el archivo de definición de la instancia virtual. Entonces esta instancia virtual montará un dispositivo /dev/xvdb de tipo iso, como una imagen de CD, en el directorio /mnt y que contendrá sólo dos archivos: context.sh y init.sh.
En el ejemplo, el archivo context.sh contiene lo siguiente:
# Context variables generated by OpenNebula
FILES=”/srv/cloud/one/plantillas/contexto/init.sh”
HOSTNAME=”cassandra01”
IP_PUBLIC=”172.26.18.140”
TARGET=”xvdb”
en donde básicamente define unas variables con los valores que hemos definido. El verdadero proceso de contextualización se realiza a través del archivo /etc/rc.local, con unas líneas que debemos añadir para que todo el proceso funcione:
#!/bin/sh -e
mount -t iso9660 /dev/xvdb /mnt
if [ -f /mnt/context.sh ]; then
. /mnt/init.sh
fi
umount /mnt
exit 0
Cuando arranca nuestra instancia virtual, y al llegar a la ejecución del archivo /etc/rc.local, se montará entonces el disco en el dispositivo /dev/xvdb en el directorio /mnt, se verificará luego que exista el archivo context.sh en /mnt y de ser verdadero, se ejecutará el archivo init.sh. El último paso del proceso es desmontar el dispositivo. Al final deberíamos tener una instancia virtual cuyo hostname es debian01 y su dirección ip es 172.26.18.140.
Como pueden ver, el proceso de contextualización le permite a los usuarios de Open Nebula añadir tantas características sean necesarias a sus instancias virtuales para que se ajusten a las necesidades y los requerimientos, ya sea para ambientes de prueba o de desarrollo. Se pueden enviar llaves públicas, archivos de configuración, y paquetes para configurar instancias virtuales a la medida.
Para visualizar un listado con las instancias virtuales en ejecución basta con ejecutar:
- onevm list
y para visualizar la información específica de una instancia virtual basta con hacer:
- onevm show id_de_instancia (por ejemplo: onevm show 18)
En el primer caso se debería mostrar la siguiente información:
=== Conclusiones
Open Nebula[1] puede funcionar como una herramienta apropiada para el manejo de clouds de computación privados si se dispone del tiempo y de un recurso humano dedicado, ya que como han podido ver, la plataforma no es del todo automática en ciertos aspectos, por lo que puede ser necesaria la atención dedicada de un especialista. Lo complejo es realmente al principio y luego del proceso de instalación, encontrar el mejor escenario de acoplamiento entre el equipo frontend y los equipos nodos. Hay que enfrentar errores diversos que presenta la plataforma y si se requiere documentación hay que tener paciencia para buscar en las listas de correo del proyecto. Existe buena documentación, pero requiere ser ampliada y ser más explicativa. La ayuda que ofrecen en el canal de IRC es buena.
Entre tanto, recomiendo echarle un ojo a Nimbus[2], Eucalyptus[3] y OpenStack[4], que son proyectos similares y en distintas etapas de madurez, cada uno con ciertas ventajas frente a sus competidores. Cuando las haya probado intentaré escribir guías similares a ésta para orientación general.
[2] http://www.nimbusproject.org/
[3] http://open.eucalyptus.com/
Anotaciones desde el cubículo…: http://imhector.posterous.com/open-nebula-como-plataforma-para-computacion-47767 - En la entrada anterior instalamos y configuramos Open Nebula para que funcionara sobre un sistema de virtualización Xen bajo el sistema operativo Debian . Ahora en esta entrada vamos a ver cómo configurar todos los elementos necesarios para empezar a instanciar máquinas virtuales y a distribuir los …
