Anotaciones desde el cubículo...

Hace algunos meses, en la institución donde laboro se me ha pedido evaluar una serie de plataformas y aplicaciones de software para la gestión de ambientes para desarrollar ambientes de computación en la nube. La computación en la nube es un concepto que redefine de alguna manera la manera y la visión con la que se prestan los servicios de computación y cómputo con las tecnologías que día a día crecen en capacidades de almacenamiento, de transmisión y de procesamiento.

La NIST (Instituto Nacional de Tecnología y Estándares por sus siglas en inglés) define la computación en nube como:

La computación en nube es un modelo que permite convenientemente, el acceso bajo demanda a un conjunto de recursos configurables de computación (Por ejemplo: redes, servidores, almacenamiento, aplicaciones y servicios), que pueden ser rápidamente aprovisionados y liberados con el mínimo esfuerzo de gestión o interacción con el proveedor de servicios.

Para no entrar en detalles profundos de este extenso tema, es completamente válido imaginarse una nube de las que dibujábamos en cuando chicos e imaginarnos dentro de dicha nube una serie de servicios que son ofrecidos a los usuarios a través de internet o de la intranet de una organización. Hoy en día, las actividades que realizamos comúnmente en internet son ofrecidas bajo este paradigma, es decir, cuando revisamos el correo, cuando twitteamos, cuando subimos una foto a Facebook o cuando vemos un video en Youtube, estamos siendo atendidos por una serie de servicios que se encuentran en una y en varias nubes de computación.

Los servicios de computación en nube pueden ser ofrecidos en tres (3) capas, a saber:

• Software como servicio (SaaS)
• Plataforma como servicio (PaaS)
• Infraestructura como servicio (IaaS)

El software como servicio se encuentra en la capa superior y provee a los usuarios una solución completa a sus requerimientos de software para la gestión de una tarea específica en la empresa u organización, como el correo electrónico ofrecido por Google Apps. La plataforma como servicio es una capa intermedia que provee los recursos necesarios para el desarrollo o puesta en marcha de una aplicación sin la complejidad que implica el manejo y administración del hardware y software subyacente requerido para la instalación y configuración de los servicios. La infraestructura como servicio, que es lo que detallaremos con más profundidad, es la capa más baja y es un medio crudo para entregar recursos de cómputo en bruto como los servicios de red, el almacenamiento, conexiones, rutas y tecnologías de virtualización. Es en esta capa de infraestructura como servicio que reside gran parte de la importancia de la computación en nube, ya que permite atender los requerimientos para manejar cargas de trabajo en momentos determinados, ya sea aumentando o disminuyendo la capacidad. El ejemplo más claro de servicios que operan en esta capa son los que provistos por Amazon con su EC2 (Amazon Elastic Compute Cloud) y S3 (Amazon Simple Storage Service). Es la capa que provee la disponibilidad, elasticidad y escalabilidad a las capas superiores para adaptarse a los cambios de carga y demanda de cierto conjunto de recursos de computación.

Open Nebula es un conjunto de herramientas de código abierto para la gestión y manejo de plataformas de computación en nube, que permite el despliegue rápido de recursos distribuidos y con configuración personalizada de cómputo según las necesidades y la demanda. Open Nebula es ideal para organizaciones que desean distribuir de una manera más eficiente su poder de cómputo mediante la distribución de recursos en función de la carga e intensidad del trabajo. Es un proyecto que cuenta con el apoyo de organizaciones como C12G Labs, que actualmente lleva el proyecto a nivel empresarial, por los laboratorios de investigación y desarrollo de Telefónica y la empresa CloudScaling, mientras que su uso se extiende hasta organizaciones como KPMG, Fermilabs y la filial alemana de Telefónica. Igualmente ha conseguido el apoyo técnico y monetarios de importantes organizaciones europeas, lo que de alguna manera deja en claro la robustez que posee y que puede alcanzar en un futuro.

Para la instalación de Open Nebula es necesario un o varios equipos servidores con capacidades de virtualización, sistema operativo libre (Debian, Ubuntu, CentOS) y el ambiente XEN, KVM o VMWare debidamente configurado. Para el caso expuesto acá se utilizarán 5 equipos servidores, con la distribución Debian y XEN como motor de virtualización. Uno de los equipos funcionará como frontend del cluster y los otros 4 servirán como nodos de escalabilidad. La premisa básica de esta configuración es que el equipo frontend sea el encargado de distribuir la carga y las instancias virtuales a través de los 4 nodos restantes para logar el balanceo de la carga y aprovechar los recursos de los mismos, que es el propósito final de este tipo de herramientas. Básicamente queremos lograr una arquitectura similar a la mostrada en la imagen, pero con 4 nodos.

=== Pasos previos:

Se describen a continuación una serie de pasos que deberán ser completados para lograr la funcionalidad completa de la herramienta, no serán descritos en esta pequeña guía:

• Instalación básica de Debian en los 5 equipos
• Instalación y configuración de Xen en los 5 equipos (xen-linux-system-2.6.32-5-xen-amd64, xen-tools)
• Instalación de servidor SSH en cada uno de los equipos (ssh)
• Instalación de servidor NFS en el equipo frontend (nfs-kernel-server)
  
• Instalación de cliente NFS en los equipos nodos

En el equipo frontend se requiere que estén instalados los siguientes paquetes:

• ruby, sqlite3, libsqlite3-dev, libxmlrpc-c-dev, libssl-dev, openssl, scons, build-essential, g++, flex, bison, libxml2-dev, libxml-parser-ruby, libnokogiri-ruby1.8, libmysqlclient-dev, mysql-server-5.1, libjson-ruby, libsinatra-ruby1.8, thin1.8 y rubygems.

En los equipos nodo se requieren los siguientes paquetes:

• ruby, nfs-kernel-server y nfs-client

Los nombres de los paquetes pertenecen a la distribución Debian en su versión 6.0, que será nuestro ambiente de trabajo. Se utilizará la versión de 64 bits.

====== Preparando el cluster

Acá prepararemos el cluster para la instalación de Open Nebula, generaremos una estructura de directorios en el frontend que luego se replicará en los nodos, generaremos llaves SSH para el acceso sin password entre los nodos y el frontend, configuraremos el puente de red y crearemos el usuario que se encargará de administrar la plataforma.

=== NFS

En el frontend crearemos los siguientes directorios:

• /srv/cloud/one
• /srv/cloud/images

Luego editaremos el archivo /etc/exports y colocaremos lo siguiente:

• /srv/cloud    192.168.1.1/255.255.255.0(rw)

cambiando por supuesto la red bajo la cual se está trabajando. Luego en cada nodo debemos crear el directorio /srv/cloud y montar en él el directorio que exportamos desde el frontend a través de NFS, lo cual se puede lograr editando el archivo /etc/fstab en cada uno de los nodos y agregando una línea así:

• 192.168.1.1:/srv/cloud        /srv/cloud    nfs    rw,timeo=14,auto,hard,intr    0    0

=== Usuarios

Luego debemos crear un usuario que será el encargado de administrar la plataforma Open Nebula, para ello creamos un usuario y lo añadiremos a un grupo que tendrá los permisos para manipular la configuración y la administración de Open Nebula.

Primero creamos un grupo cloud por ejemplo, aunque pueden nombrarlo como deseen, luego creamos un usuario que llamaremos oneadmin que pertenecerá al grupo cloud. Este paso debemos hacerlo en los equipos nodos también y se puede proceder de la siguiente manera:

• groupadd cloud
• useradd -d /srv/cloud/one -g cloud -m oneadmin -s /bin/bash

Deben asegurarse que los usuarios y grupos creados en los equipos nodos tengan el mismo id.

=== Red

El puente de red es necesario para que las instancias virtuales creadas en Open Nebula puedan comunicarse a través de la red con otros equipos reales o virtuales. El puente permite a varias instancias virtuales comunicarse por red a través de una única interface real de red, para ello editamos el archivo /etc/network/interfaces para que quede así:

auto lo
iface lo inet loopback

# The primary network interface

auto xen-br0 eth1
iface xen-br0 inet dhcp
bridge-ports eth1

De esta manera definimos un puente con la interfaz xen-br0 pero que realmente se comunicará al exterior por la interfaz eth1. Luego de editar el archivo es necesario reiniciar la red ejecutando:

• /etc/init.d/networking restart

Para verificar que haya funcionado debemos ver con un simple ifconfig o netstat -ie que la interfaz xen-br0 es la que tiene la dirección ip de la máquina.

=== SSH

Para logar seguridad y eficiencia en la comunicación entre el equipo frontend y los equipos nodo generaremos llaves SSH para el usuario oneadmin y las agregaremos al anillo de confianza para que desde el frontend se pueda acceder a los nodos sin preguntar por contraseñas, para ello generamos una llave y la copiamos a los nodos de la siguiente manera en el frontend con el usuario oneadmin:

• ssh-keygen (presionar Enter cuando pregunte por contraseña)
• cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Para evitar cualquier sorpresa se recomienda desde el equipo frontend realizar una prueba de acceso hacia cada uno de los nodos para verificar que todo esté correcto.

Ya con estos pasos tenemos una estructura de cluster necesaria para instalar Open Nebula, como la que se muestra a continuación:

====== Instalación de Open Nebula

Al momento de instalar Open Nebula disponemos de dos modalidades para dicha tarea, podemos optar por una instalación auto-contenida (preferida) o de sistema. La instalación auto-contenida instala los archivos de Open Nebula en una única carpetea, mientras que la de sistema instala los archivos en los directorios del sistema. la instalación recomendada es la auto-contenida ya que facilita el manejo de los archivos de configuración y de bitácoras y a su vez el proceso de desinstalación es más sencillo.

Para instalar Open Nebula debemos descargar el código fuente desde acá: http://downloads.dsa-research.org/opennebula/. Como podrán ver, en la lista desplegable existen binarios para muchas distribuciones, pero en nuestro caso lo compilaremos desde sus fuentes, por lo que descargaremos el que está listado como OpenNebula 2.2.1 tarball. Luego en el directorio que lo hayamos descargado:

• tar xvzf opennebula-2.2.1.tar.gz
• cd opennebula-2.2.1/
• scons mysql=yes (para soporte a mysql, por defecto es para sqliteDB)
• chmod a+x install.sh
• ./install.sh -u oneadmin -g cloud -d /srv/cloud/one (indicamos el usuario oneadmin, el grupo cloud y el directorio /srv/cloud/one)

Luego de realizar todos estos pasos tendremos una instancia de Open Nebula instalada en el directorio /srv/cloud/one y bajo este directorio debería encontrarse una jerarquía de directorios como la siguiente:

====== Configuración de Open Nebula

Luego de culminar el corto proceso de instalación es hora de configurar Open Nebula. Como se realizó la instalación auto-contenida, los archivos de configuración están en el directorio /srv/cloud/one/etc, de este directorio nos interesa el archivo oned.conf, que es en donde residen los parámetros bajo los cuales funciona Open Nebula. Como en nuestro caso estamos trabajando con XEN como tecnología de virtualización y NFS como tecnología de transferencia, debemos configurar algunos parámetros del archivo para que trabaje como debe ser:

Como estamos utilizando MySQL como gestor de base de datos para guardar datos de Open Nebula debemos especificar la información:

DB = [ backend = "mysql",
       server  = "localhost",
       port    = 3306,
       user    = "usuario",
       passwd  = "contraseña",
       db_name = "nombre_bd" ]

En la documentación de Open Nebula indican que si el directorio VAR de Open Nebula se monta en la misma dirección tanto en el frontend como en los nodos no es necesario descomentar la variable VM_DIR, pero yo siempre la descomento y le doy el valor por defecto por seguridad, así que debería quedar así:

VM_DIR = /srv/cloud/one/var

Para la comunicación de Open Nebula con XEN, descomentamos las siguientes líneas:

IM_MAD = [
    name       = "im_xen",
    executable = "one_im_ssh",
    arguments  = "xen" ]

VM_MAD = [
    name       = "vmm_xen",
    executable = "one_vmm_ssh",
    arguments  = "xen",
    default    = "vmm_ssh/vmm_ssh_xen.conf",
    type       = "xen" ]

Para la transferencia a través de NFS, descomentamos las siguientes líneas:

TM_MAD = [
    name       = "tm_nfs",
    executable = "one_tm",
    arguments  = "tm_nfs/tm_nfs.conf" ]

NOTA: Como buena prática recomiendo comentar todos los controladores que se vayan a utilizar, a fin de tener un archivo más ordenado y más fácil de editar al momento de cualquier error en la configuración. De cualquier manera es un archivo de configuración bastante intuitivo y muy bien documentado.

NOTA 2: El usuario oneadmin debe poseer permisos para ejecutar comandos para trabajar con XEN, esto se puede lograr a través de sudo.

=== Usuarios y variables de entorno

Antes de arrancar por primera vez Open Nebula es necesario definir algunas variables de entorno y un archivo con información del usuario. Como hemos instalado Open Nebula de manera auto-contenida, es necesaria la definición de una variable llamada ONE_LOCATION, que contendrá la ruta en donde se encuentra la instalación de Open Nebula, en nuestro caso /srv/cloud/one. Igualmente será necesario un archivo llamado one_auth, que será un archivo de texto plano con el nombre de usuario y la contraseña del usuario que administrará Open Nebula. Dicho archivo estará en /home/nombre_usuario/.one/one_auth. Como definimos un usuario oneadmin cuyo directorio home definimos en /srv/cloud/one entonces el archivo quedará en /srv/cloud/one/.one/one_auth. Igualmente se debe definir una variable de entorno ONE_AUTH con dicha ruta, definir una variable ONE_XMLRPC y actualizar la variable PATH. Para ello:

• mkdir -p /srv/cloud/one/.one
• echo "oneadmin:password" >> /srv/cloud/one/.one/one_auth
• export ONE_LOCATION=/srv/cloud/one
• export ONE_AUTH=/srv/cloud/one/.one/one_auth
• export ONE_XMLRPC=http://localhost:2263/RPC2
• export PATH=/srv/cloud/one/bin:$PATH

Si todo ha ido bien, al ejecutar one start ya se debería estar ejecutando Open Nebula. A partir de acá recomiendo leer la documentación que proveen en su sitio oficial para empezar a probar las bondades de la plataforma. Vale destacar que está en constante desarrollo y en algún momento podamos ver que falta alguna característica que nos parezca esencial para la administración y el manejo, pero ahí reside la belleza de los proyectos de código abierto, que siempre están en desarrollo. Por ejemplo, en la última versión estable, que es la 2.2, disponemos de una pequeña interfaz web llamada Sunstone desde la que podemos manejar las operaciones esenciales en Open Nebula, como agregar nodos a nuestro cluster, crear las redes, definir las imágenes y definir las instancias virtuales.

ACTUALIZACIÓN: tanto en la documentación oficial como en la de los usuarios que han configurado la herramienta, se estila omitir o fijar por defecto la configuración de la variable VM_DIR en el archivo oned.conf, por lo que si se sigue el resto de los pasos como lo dicta la documentación oficial las imágenes de las máquinas virtuales no se copiarán propiamente en los nodos como tal sino que se realizará una copia local en el equipo que tiene la instalación de Open Nebula. En mi opinión lo más apropiado es definir un directorio fuera del punto de montaje del directorio compartido, en nuestro caso /srv/cloud, para que así efectivamente se realice la copia de la imagen de la máquina virtual a una carpeta en el equipo nodo.

====== Referencias

http://opennebula.org/documentation:documentation