Anotaciones desde el cubículo...

No es para nadie un secreto que las tecnologías de información cambian cada aspecto de nuestra vida diaria, muchas veces sin nosotros darnos cuenta y a veces hasta sin nuestro permiso. Las redes sociales son muestra clara de ello, porque han moldeado nuestro comportamiento poco a poco desde su aparición y luego hasta su popularización.

Las redes sociales han dado para las relaciones personales, la música, relaciones basadas en localización, juegos, videos y casi cualquier forma de entretenimiento digital. Era prácticamente inevitable que estos modos de crear y compartir no llegaran a la educación y el aprendizaje, sólo era cuestión de tiempo. Los antecedentes indican que incluso hasta hace poco, la educación a distancia era sólo una forma no presencial de impartir la enseñanza utilizando los mismos métodos que en la educación presencial. Así, aún se tenía a un docente entregando el material, las sugerencias y recomendaciones y el alumno aún tenía que recurrir a su docente para orientaciones e indicaciones. Era, en pocas palabras, modificar el espacio y tiempo en el modelo presencial de educación.

Poco a poco surgieron herramientas que cambiaron gradualmente los métodos y las maneras de abordar la educación a distancia, como el uso de medios electrónicos para compartir el material, para consultas y debates, el uso de salas de chat y herramientas más modernas como Moodle.

No es sin embargo hasta la aparición  y consolidación de Wikipedia[1] entre los años 2001 y 2004 que se definen varios hitos y aspectos que constituyen lo que se puede considerar actualmente el modelo de educación más abierto, inclusivo y extenso que se haya conocido:

• Modelo colaborativo: no sólo docentes y especialistas en las áreas de estudio son los responsables de crear, aportar, aprobar o revisar los contenidos, ahora cualquier persona con conocimientos puede realizar sus aportes a cualquier área de conocimiento.
• Educación sin fronteras: al ser entidades que nace, viven y se alimentan en Internet, no existen las fronteras geográficas para la colaboración, por lo que un artículo que ha colocado hoy alguien en España, mañana puede ser pulido por alguien en la India.
• Blindado contra información maliciosa: en términos de computación lo diría libre de virus, y sucede de la misma manera que con el software libre, porque como las plataformas están abiertas a todas las personas para colaboración, si sólo a una se le ocurre editar en la Wikipedia, por ejemplo que el Holocausto nunca ocurrió, hay 50 personas que se dan cuenta que obviamente no es cierto y proceden a corregir la información. No son plataformas infalibles, pero sí muy seguras y no por la plataforma en sí, sino por los usuarios.
• Cero costos: el uso de las TIC para masificar los contenidos educativos supone, sino un gran ahorro de costos, el ahorro de la totalidad de costos asociados a los métodos tradicionales de educación. El uso de plataformas para compartir contenidos en Internet como Youtube, Google Docs, Dropbox, SlideShare, Prezi y cualquier otra plataforma privada, supone que estos contenidos son capaces de llegar, teóricamente a cualquier usuario que tenga una computadora y conexión a Internet.
• La clase se imparte una sola vez, pero se escucha muchas veces: la atemporalidad que proporcionan las herramientas en Internet solucionan el gran problema del tiempo y su administración tanto de parte de los que ofrecen el conocimiento como de aquellos quienes lo van a recibir. Ese tiempo de ocio en la oficina puede servir para tomar dos lecciones de álgebra lineal a través de Youtube o para grabar un nuevo video tutorial con la explicación para resolver un sistema de ecuaciones a través de matrices. No hay restricciones de tiempo, y mucho menos de lugar.
• La realidad como elemento pedagógico: los modelos abiertos y colaborativos de educación proveen un contexto mucho más realista que la educación tradicional, al enfocarse en elementos sociales del entorno que pueden estimular el aprendizaje, la interacción con personas de distintas culturas y distintas maneras de pensar, el descubrimiento de saberes y conocimiento de manera colectiva pueden llegar a ser ingredientes que agreguen dinamismo a las relaciones de enseñanza-aprendizaje.

Los mencionados son sólo algunos de los aspectos más importantes que caracterizan las herramientas basadas en conocimiento que están a disposición de la gran mayoría de internautas hoy en día. Pero no sólo la Wikipedia ha sido una revelación desde sus inicios para la educación tradicional. En 1999 nace en la Universidad de Tübingen en Alemania algo denominado OpenCourseWare[2], un movimiento cuyo propósito es publicar en la web los materiales y estrategias docentes de contenidos de nivel universitario que son agrupados dentro de áreas determinadas del conocimiento. No fue hasta el año 2002 que esta iniciativa despega gracias al interés del MIT en colgar en la web todo su material pedagógico de pregrado y postgrado con el fin de otorgar acceso libre a toda la base de conocimientos que conformas las disciplinas académicas del MIT. La mayoría del contenido es ofrecido bajo licencia Creative Commons y su propósito no es más que fortalecer lo que se denomina la sociedad del conocimiento.

En el OpenCourseWare del MIT[3] podemos encontrar, por ejemplo, notas de las clases, exámenes con sus respuestas, asignaciones para estudiantes y contenido multimedia. Con esta posibilidad, un alumno del MIT o de cualquier otra universidad que cursa una carrera de Ingeniería o Matemáticas, por ejemplo, podría reforzar los tópicos que no le quedaron muy claro en la clase de la mañana. Se hace, de alguna manera, menos necesaria una consulta presencial con el docente de la materia, porque están disponibles videos de muchos otros profesores dando una clase del mismo contenido y que probablemente sea más sencillo de entender y lo mejor de todo es que se puede recibir la clase 1, 2, 3 y hasta 10 veces. Es una ayuda que los estudiantes de hace algunos años atrás no tenían y quizá ni siquiera imaginaban.

Pero los avances no se detienen con esta iniciativa, más recientemente, en el año 2006, se creó la Khan Academy[4], una organización sin fines de lucro cuya misión es proveer de educación de calidad a cualquiera y en cualquier parte. Con una colección de más de 2700 videos, alojados en Youtube, se ofrecen cursos en disciplinas como matemáticas, álgebra, química, física, economía, historia, medicina, biología, astronomía y ciencias de la computación. En el sitio se dispone de todos los materiales agrupados por áreas del conocimiento, un mapa de progreso, ejercicios de matemáticas, tutoría y consultas. También ofrece, como componente social, una suerte de recompensas de acuerdo al progreso del estudiante, como pines o badges por completar una determinada cantidad de tiempo viendo los videos, completando una serie de clases o resolviendo los ejercicios. Aunque actualmente el enfoque de la academia es en las áreas de matemáticas, en un futuro se espera que puedan ofrecer clases y tutorías en todas las áreas del conocimiento, como se puede apreciar al entrar cada día al sitio. Sin duda es una de las ayudas que cualquiera de mis compañeros y yo no hubiésemos imaginado que pudiesen existir algún día y que de haberlas tenido en nustro momento no hubiésemos sufrido tanto con las matemáticas.

Hay más, y es que la Universidad de Stanford anunció hace algunos meses que estaría abriendo cursos en línea de sus clases más populares de ciencias de la computación, que son: Introducción a bases de datos, Introducción al aprendizaje de máquinas e Introducción a la Inteligencia Artificial. La clase de Introducción a la Inteligencia Artificial atrajo unas 160.000 personas, de las cuales 35.000 permanecieron en el curso. Las 3 clases empezaron en Octubre y están programadas para terminar este mes de Diciembre y desde ya se ofrecen 16 nuevas clases[5] que empezarán entre Enero y Febrero del año entrante. Teoría de Juegos, Software como Servicio, Criptografía, Diseño y Análisis de Algoritmos e Interacción Humano-computadora son algunos de los cursos que se ofrecerán, y aunque están muy enfocados en el área de las ciencias de la computación de ofrecerá un curso de Anatomía.

Como ven, no hay razones, tanto para profesionales como estudiantes, para no sobresalir y alcanzar la excelencia en sus respectivas áreas académicas. Las herramientas y las iniciativas disponibles hoy en día facilitan y amplían los horizontes de cualquier disciplina y ponen a disposición, de manera gratuita, conocimiento y destrezas para reforzar lo que ya aprendimos de manera tradicional y como herramienta de soporte a aquellos quienes están en las universidades en este momento.

=== Referencias

[1] http://es.wikipedia.org/wiki/Wikipedia

[2] http://www.ocwconsortium.org/en/aboutus

[3] http://ocw.mit.edu/index.htm

[4] http://www.khanacademy.org

[5] http://www.class-central.com/

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.

[1] http://opennebula.org/

[2] http://www.nimbusproject.org/

[3] http://open.eucalyptus.com/

[4] http://www.openstack.org/

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

Básicamente el título lo resume todo. Resume una de las interrogantes, madres del conocimiento y la propagación de este: ¿Por qué?. Acá intentaré dedicar parte de mi tiempo ocioso en la oficina a escribir artículos, observaciones, recomendaciones y conocimiento de mi propio cultivo, todo alrededor de la informática, la computación, el área de ingeniería y el área de sistemas.

Compartir el conocimiento es una constante desde que aprendemos nuestras primeras palabras, mientras vivimos esa época que generalmente se olvida llamada escuela, la loca juventud en el bachillerato y el rápido y casi imperceptible paso a la adultez en la universidad. Durante esta y casi todas las etapas de nuestra vida compartimos el conocimiento, actividad que curiosamente disminuye en gran parte de los profesionales y de manera sustancial al empezar la vida profesional y conforme se avanza en esta. Son pocos los que se dedican de manera parcial o completa a la noble tarea de compartir los conocimiento, ya sea formando nuevos profesionales, contribuyendo en proyectos colaborativos o simplemente otorgando las orientaciones indicadas en el momento indicado a aquellas personas que buscan consejo en sus sabias palabras.

En la medida de las posibilidades actualizaré este pequeño espacio con notas de interés para cursantes de carreras universitarias y profesionales en ejercicio en las áreas previamente mencionadas, esperando que los conocimientos que poco a poco fui adquiriendo también les sean útiles a ustedes en sus estudios o en su trabajo.

Gracias de antemano por leer...nos vemos en la primera nota.