Este artículo presenta algunas modificaciones al código fuente de Walrus, el componente del servicio de almacenamiento incluido en la estructura de fuente abierta Eucalyptus para computación en nube que implementa un entorno IaaS (Infraestructura como Servicio). Aprenda cómo modificar el código fuente Walrus y cómo recompilarlo y ejecutarlo para mejorar los mecanismos de uso compartido y de bloqueo de archivos en el entorno Eucalyptus.
El mejor motivo que se nos ocurre para hacer esto, ya sea para consumidores de servicios en nube o para desarrolladores y diseñadores de aplicaciones y servicios en nube, especialmente si éstos emplearán el uso compartido o el bloqueo de archivos, es que puede mejorar la función de su aplicación o servicio, lo cual puede mejorar el rendimiento de dichos recursos y, a la vez, reducir la asignación general de tiempo, ancho de banda y potencia de computación para su recurso. Esto posiblemente traerá aparejada una reducción en los costos.
Le mostramos, paso a paso, cómo instalar Eucalyptus en un cluster: en este caso, un servidor blade IBM®; esta técnica también puede utilizarse en una computadora personal o una laptop.
Para aprovechar al máximo este artículo, usted debería poseer una comprensión cabal de los conceptos involucrados en la computación en nube, la tecnología Java™ y los comandos de codificación UNIX®, así como cierta comprensión básica acerca de cómo trabajar con clusters. Para usar el código del ejemplo, necesita una comprensión básica de la estructura Eclipse. En la sección Recursos encontrará enlaces a antecedentes de estas tecnologías.
La instalación de Eucalyptus en un cluster
Para este artículo, nosotros utilizamos Eclipse 3.4.2 y Cent OS 5.4 como sistemas operativos.
Los servidores blade IBM son compatibles con una amplia gama de tecnologías de procesadores y de sistemas operativos, permitiendo así a los clientes ejecutar todas sus diferentes cargas de trabajo dentro de una misma arquitectura. Los servidores blade reducen la complejidad, mejoran la administración de sistemas y aumentan la eficiencia energética, al tiempo que disminuyen los costos totales de propiedad. Nosotros utilizamos el Servidor IBM LS20 BladeCenter® (Recursos).
En este artículo, nos referimos generalmente a la instalación de un único cluster; todos los componentes, salvo los controladores de nodos, están ubicados en la máquina a la que nos referimos como "front end". (En otras palabras, el controlador de nube, el controlador de clusters y elcontrolador de almacenamiento se ejecutan en la máquina front end. A las máquinas que sólo ejecutan controladores de nodos las llamamos "nodos."
Es bastante simple instalar Eucalyptus 1.6.1 en CentOS. Como admin:
- Descomprima ("untar") el archivo eucalyptus-1.6.1-centos-i386.tar.gz.
- Ingrese como cualquier usuario distinto a
roote instálelo como se muestra en el developerWorks wiki.
Luego de seguir esos pasos, Eucalyptus debería instalarse. Otras direcciones alternativas de instalación están disponibles en el sitio web de Eucalyptus. A continuación, baje las herramientas de administración Eucalyptus para administrar imágenes virtuales. El wiki explica el uso de paquetes de imágenes.
La Figura 1 muestra los cuatro componentes de alto nivel, cada uno con su propia interfaz de servicio web, que comprende una instalación de Eucalyptus:
Figura 1. Los cuatro componentes de alto nivel de Eucalyptus
Esos componentes son el controlador de nodos, el controlador de clusters, el controlador de almacenamiento (Walrus) y el controlador de nube.
- Los controladores de nodos controlan la ejecución, inspección y terminación de instancias VM (Virtual Machine = Máquina Virtual) en el host donde se ejecutan.
- Los controladores de clusters organizan y reúnen información sobre la ejecución VM en controladores de nodos específicos, y también administra la red de instancias virtuales.
- El controlador de almacenamiento (Walrus) es un servicio de almacenamiento
put/getque implementa la interfaz S3 de Amazon, proporcionando un mecanismo para almacenar y brindar acceso a imágenes de máquinas virtuales y datos de usuarios. - El controlador de nube es el punto de entrada a la nube para usuarios y administradores. Consulta a los administradores de nodos acerca de la información sobre recursos, toma decisiones de organización de alto nivel, y las implementa mediante solicitudes al controlador de clusters.
Acerca de Walrus, el componente de almacenamiento
Walrus es un servicio de almacenamiento incluido en Eucalyptus, que es compatible por interfaz con el S3 de Amazon. Walrus permite almacenar datos persistentes, organizados como buckets y objetos.
Walrus no proporciona el bloqueo de escrituras de objetos; sin embargo, como en el caso de S3, usted puede estar seguro de que sistemáticamente se guarda una copia del objeto si existen escrituras simultáneas al mismo objeto. Si se encuentra una escritura a un objeto cuando hay una escritura previa al mismo objeto en curso, la escritura previa es invalidada.
La versión actual de Walrus no ofrece datos consistentes ni el bloqueo de objetos. Para ejecutar una imagen en la nube, usted debe producir una imagen empaquetada y subirla a la nube. Walrus actúa como un administrador de almacenamiento: recibe la imagen y la almacena como buckets y objetos. Cuando usted desea acceder a la imagen desde la nube, a Walrus se le confía la tarea de verificar y decodificar las imágenes que han sido subidas por los usuarios.
Cuando se desea almacenar una imagen, se crea un bucket aparte para cada usuario con un
único nombre de bucket. Utilizando S3cmd, cree un bucket y un nombre de bucket:
$ s3cmd mb s3://my-new-bucket-name |
Una vez creado un bucket, usted puede subir el archivo (al que se lo llama objeto) al bucket:
$ s3cmd put filename s3://my-new-bucket-name/filename |
Para conocer más acerca de la operación interna de Walrus, puede consultar el S3cmd de Amazon S3 (Recursos).
Introduciendo el bloque de archivos en Walrus
Para superar las dificultades de Walrus, hemos introducido un mecanismo de bloqueo de archivos: para conservar la consistencia de los datos, hemos proporcionado la capacidad de acceder al archivo en el modo lectura/escritura.
Cuando el usuario1 quiere acceder a cualquier archivo en modo escritura, el objeto correspondiente será bloqueado para que no puedan acceder a él otros usuarios hasta que sea liberado por el usuario1. Pero otros usuarios pueden acceder al archivo en modo lectura.
Nosotros diseñamos una cola de espera separada en la cual colocar la solicitud de escritura de cada usuario, siguiendo el orden en el que solicitaron el objeto y permitiendo que el sistema pueda procesar la solicitud como corresponde.
Administración de imágenes en Walrus
Antes de ejecutar las instancias VM en Eucalyptus, deberían añadirse las imágenes VM bajadas o creadas empaquetándolas con sus credenciales de Eucalyptus, y luego subir las imágenes y registrarlas.
Para habilitar una imagen VM como una entidad ejecutable, el administrador de Eucalyptus debe añadir una imagen del sistema raíz de archivos y un par kernel/ramdisk a Walrus (almacenamiento en bucket) y registrar los datos subidos con Eucalyptus. Cada una de las imágenes es añadida a Walrus y es registrada con Eucalyptus en forma separada, utilizando los siguientes comandos compatibles con EC2:
- Para añadir la imagen del sistema raíz de archivos a Walrus:
- Empaquete la imagen:
$ euca-bundle-image -i <vm image file>
- Suba el paquete:
$ euca-upload-bundle -b <image bucket> -m /tmp/<vm image file>.manifest.xml
- Registre la imagen:
$ euca-register <image bucket>/<vm image file>.manifest.xml
- Empaquete la imagen:
- Para añadir el kernel a Walrus y registrarlo con Eucalyptus:
- Empaquete el kernel:
$ euca-bundle-image -i <kernel file> --kernel true
- Suba el paquete:
$ euca-upload-bundle -b <kernel bucket> -m /tmp/<kernel file>.manifest.xml
- Registre el kernel:
$ euca-register <kernel-bucket>/<kernel file>.manifest.xml
- Empaquete el kernel:
Detrás del mecanismo modificado
Actualmente, Eucalyptus no tiene soporte para un mecanismo de uso compartido de archivos, pero le mostraremos cómo implementar el uso compartido de archivos en Eucalyptus. Nos enfocamos en mantener la consistencia de los datos.
Para cada usuario se crea una instancia de Máquina Virtual independiente. En su actual encarnación, Eucalyptus tampoco soporta el uso compartido de archivos entre diferentes instancias VM. Si dos o más usuarios acceden al archivo en modo escritura simultáneamente y modifican el archivo, el último contenido guardado se actualiza en el archivo.
Primero, veamos cómo se crea un volumen y cómo se acopla a una instancia.
Antes de crear un nuevo volumen, busque información sobre las actuales zonas de disponibilidad:
$ euca-describe-availability-zones |
Cree un nuevo volumen:
$ euca-create-volume --size <size of volume> -x <name of availability zone> |
donde --size indica el tamaño del volumen que se desea crear
y -x indica el nombre de la zona de disponibilidad donde usted quiere que resida el volumen.
Acople un volumen a una instancia con el siguiente comando:
$ euca-attach-volume |
Por ejemplo, para acoplar el volumen vol-12345678 a la instancia i-98765432 en /dev/sdb:
$ euca-attach-volume -i i-98765432 -d /dev/sdb vol-12345678 |
Cuando la instancia VM comienza a ejecutarse, usted puede ver dos direcciones IP asignadas a ésta. Ingrese a la dirección IP utilizando la llave SSH:
$ ssh -i mykey.private root@<ip-address> |
Veamos esto en forma de escenario
Supongamos que el usuario A y el usuario B ingresan a dos sistemas diferentes, a los que llamaremos Sistema 1 y Sistema 2, con el mismo nombre de usuario y la misma contraseña, e intentan acceder a un archivo desde ambos sistemas.
Tanto A como B intentan acceder a la misma instancia VM a través de Elastic Fox en forma simultánea (al mismo
tiempo) en modo escritura. Al utilizar la dirección IP de la instancia, ambos intentan
acceder a la instancia usando el comando ssh. Cuando A modifica el archivo, lo hace B, entonces la modificación de B es la que se actualiza. El estado de las escrituras del archivo no es consistente.
La arquitectura modificada de Walrus contribuye a hacer que las modificaciones del archivo de datos sean consistentes.
Veamos la arquitectura de la nube y su red virtual.
Figura 2. La arquitectura de la nube y su red virtual
Los componentes son:
- El CLC o controlador de nube, que es la interfaz con los clientes y lleva a cabo la organización de alto nivel; forma la plataforma de administración.
- Los ccX son los controladores de clusters, que distribuyen las solicitudes entrantes a controladores de nodos específicos y reúnen/reportan información sobre un conjunto de controladores de nodos.
- Los ncX son los controladores de nodos, las máquinas que albergan las instancias VM.
- Walrus es el almacenamiento secundario persistente que usan los controladores de nodos para almacenar sus imágenes VM y a veces para almacenar datos.
La Figura 3 muestra cómo un usuario comparte archivos con otros usuarios.
Figura 3. Diagrama de flujo de cómo un usuario comparte archivos
En el diagrama de flujo (siga los números):
- El cliente ingresa con ID y contraseña de ingreso.
- CLC controla el ID del usuario en la base de datos y crea una nueva sesión para un usuario válido.
- CLC devuelve el mensaje de estado al cliente.
- El usuario comparte el archivo que posee.
- CLC ahora controla si el usuario realmente posee el archivo o no, y en caso de una autenticación exitosa, añade la identidad del nuevo usuario a la lista de acceso del archivo compartido.
- CLC reenvía este mensaje al CC correspondiente.
- CC encuentra el NC que alberga la instancia de máquina virtual para el usuario y reenvía este mensaje.
- NC transfiere este archivo a un medio compartido persistente (Walrus) para permitir el uso compartido entre usuarios.
- El archivo es transferido al Walrus a través del CC y el CLC.
- El archivo es transferido al Walrus.
- CLC entrega el mensaje de éxito al cliente.
La Figura 4 muestra cómo un cliente solicita acceso a un archivo.
Figura 4. Diagrama de flujo de cómo un cliente solicita acceso a un archivo
En este diagrama de flujo (siga los números):
- El usuario ingresa usando login y contraseña.
- CLC controla esto con la base de datos de usuarios y crea una nueva sesión para un usuario válido.
- CLC devuelve el mensaje de estado de login al cliente.
- El cliente solicita un archivo.
- CLC envía la solicitud al directorio de usuarios para verificar el acceso del usuario al archivo. El directorio de usuarios almacena los detalles del archivo y el usuario accede a los datos.
- CLC reenvía la solicitud al CC correspondiente.
- CC encuentra el NC que alberga la instancia de máquina virtual creada para el usuario.
En los pasos 8, 9 y 10, el NC transmite los datos al usuario mediante un canal seguro a través del CC y el CLC.
Probablemente ya sea tiempo de mostrar cómo es el interior de un controlador de nodos. En todos los controladores de nodos se ejecuta un hipervisor. El hipervisor es un software de virtualización de plataformas. Nosotros usamos el hipervisor tipo 1, que interactúa directamente con el hardware hospedador, ejecuta un sistema operativo huésped por sobre los hipervisores, y asigna recursos de sistema a los diferentes LPARs para compartir recursos físicos tales como CPUs, dispositivos de almacenamiento con acceso directo, y memoria. (Los hipervisores de tipo 1 fueron introducidos por IBM a principios de los '70 con los procesadores IBM System 370.) La Figura 5 muestra cómo opera el flujo de uso con el NC y su hipervisor.
Figura 5. Dentro del controlador de nodos
En este diagrama de flujo (siga los números):
- Solicitud entrante del CC al NC.
- El módulo del controlador de nodos que se ejecuta en ese nodo la reenvía a los hipervisores.
- El hipervisor realiza la tarea con la ayuda del sistema operativo huésped.
- El OS huésped instruye al hipervisor sobre lo que debe hacer.
- El hipervisor ahora interactúa con el hardware y completa la tarea.
Hemos visto cómo el uso compartido de archivos introducido en Eucalyptus puede ayudar; ahora veamos cómo asegurar la consistencia de los datos a través del concepto de acceder a los archivos en modo lectura/escritura.
La Figura 6 muestra de qué manera una lista de espera por tiempo para acceder a un archivo en modo escritura puede mejorar la consistencia de los datos:
Figura 6. Mejora de la consistencia utilizando una lista de espera por tiempo en modo escritura
La Figura 6 compara la solicitud del usuario B para el archivo F1 en modo escritura en el tiempo t versus la solicitud del usuario C para el mismo archivo en modo escritura en el tiempo t+1. Para implementar la consistencia del archivo, hemos diseñado una lista de espera que se emplea para ubicar la solicitud según el criterio de "el primero en llegar es el primero en ser atendido".
Puesto que B solicitó al archivo antes que C, B es ubicado al comienzo de la lista y C es ubicado luego de B.
En general, si el usuario efectúa una solicitud para acceder al archivo en modo escritura, cada solicitud se ordena según el momento en que es efectuada. El usuario de la primera solicitud se ubica al comienzo de la lista. El usuario de la solicitud siguiente se ubica a continuación, y así sucesivamente.
La Figura 7 muestra el determinador añadido de la función usuario-solicitud (escritura o lectura) para determinar los niveles de uso compartido / bloqueo a fin de mejorar la consistencia de los datos.
Figura 7. Mejora de la consistencia utilizando un determinador de lectura/escritura
En la Figura 7, hemos añadido un campo (además del marco de tiempo en que un usuario accede al archivo) para representar en qué modo se provee el acceso al archivo — si el usuario está accediendo en modo escritura o lectura.
En la lista de acceso para escritura, el usuario B está ubicado al comienzo, ya que solicitó primero el acceso al archivo en modo en escritura respecto del usuario C. Al usuario B se le proporciona acceso para escritura. El usuario C logrará acceso para escritura una vez que el usuario B libere el bloqueo del archivo. Pero el usuario C puede acceder al archivo en modo lectura mientras el usuario B todavía lo tiene bloqueado para modo escritura.
En general, si dos o más usuarios acceden al archivo en modo escritura simultáneamente, al primer usuario se le otorga acceso al archivo en modo escritura, y las solicitudes de acceso en modo escritura de los restantes usuarios son ubicadas en la lista de espera. Pero a todos los otros usuarios se les da acceso en modo lectura. Cuando el primer usuario con acceso para escritura libera el archivo, se le otorga acceso en modo escritura al usuario que le sigue en la lista.
Modificación, recompilación y ejecución del código modificado
Sabemos que usted se ha abierto paso a través de todos estos conceptos sólo para llegar a esta parte—los verdaderos pasos de modificación. Y éstos son bastante sencillos.
- Cree un espacio de trabajo y copie la carpeta clc de la fuente Eucalyptus.
Figura 8. Elija su carpeta de espacio de trabajo
- Importe la fuente haciendo clic en File > Import.
Figura 9. Elija su fuente de importación
-
Seleccione General > Existing Projects dentro de su espacio de trabajo.
Figura 10. Seleccione Existing Projects
- Seleccione la ruta del directorio raíz como root/java/workspace/clc.
Figura 11. Seleccione la ruta del directorio raíz
- Haga clic en Finish.
Figura 12. Cuando se hayan añadido exitosamente el directorio raíz y los proyectos, haga clic en Finish
-
A la izquierda hay una pestaña llamada "package" que detalla el contenido del proyecto. Ahora haga clic con el botón derecho en build.xml.
Figura 13. Listo para construir ...
- Ejecute la construcción Ant
Figura 14. ... y es un éxito!
Usted debería ver que la construcción fue un éxito. Y eso fue fácil.
La aplicación propiamente dicha tiene varios archivos, pero nosotros hemos tratado solamente los puntos destacados, dejando que usted construya sobre esta base para crear sus propias aplicaciones.
Para implementar el mecanismo del uso compartido y el bloqueo de archivos, hemos creado una clase llamada WalrusVirtualBlockManager. El código implementa el mecanismo de bloqueo de archivos en Eucalyptus. El Listado 1 es el código fuente.
Listado 1. WalrusVirtualBlockManager
package edu.ucsb.eucalyptus.cloud.ws;
import org.apache.log4j.Logger;
import edu.ucsb.eucalyptus.cloud.entities.ObjectInfo;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.*;
import edu.ucsb.eucalyptus.cloud.entities.ObjectInfo;
public class WalrusVirtualBlockManager
{
private static Logger LOG = Logger.getLogger(WalrusVirtualBlockManager.class);
public static Map<ObjectInfo,ReentrantLock>
storagelockMap = new HashMap<ObjectInfo,ReentrantLock>();
private static WalrusVirtualBlockManager virtualBlockMgr;
private WalrusVirtualBlockManager()
{
}
public static WalrusVirtualBlockManager getInstance()
{
VirtualBlockMgr = new WalrusVirtualBlockManager();
return virtualBlockMgr;
}
public ReentrantLock lock(ObjectInfo info)
{
ReentrantLock lck = new ReentrantLock();
storagelockMap.put(info,lck);
return lck;
}
public void unlock(ObjectInfo info)
{
ReentrantLock lck = storagelockMap.get(info);
lck.unlock();
clear(info);
}
public void clear(ObjectInfo info)
{
storagelockMap.remove(info);
}
public void clearAll()
{
for(Map.Entry<ObjectInfo,ReentrantLock> entry : storagelockMap.entrySet())
{
unlock(entry.getKey());
}
storagelockMap.clear();
}
}
|
¿Qué pasa si yo no uso Walrus?
Esta técnica modificada de almacenamiento de bloques puede adaptarse también para otras plataformas de nube. Por ejemplo, en Cassandra, los datos están replicados. Vale decir, la versión más reciente del recurso de datos descansa en algún nodo del cluster, pero las versiones anteriores siguen por allí afuera, en otros nodos. El objetivo consiste en que, finalmente, todos los nodos accederán a la versión más reciente. El bloqueo del archivo no está disponible, pero aquí puede introducirse la técnica modificada de almacenamiento de bloques de la forma en que lo hicimos en este artículo para mantener la consistencia de los datos. Usted ha visto a Cassandra en acción en Digg, Facebook, Twitter y otros sitios.
Ahora usted sabe cómo instalar Eucalyptus en un cluster y cómo modificar el código fuente de Walrus para implementar o mejorar el mecanismo de uso compartido y de bloqueo de archivos en la nube.
Aprender
-
La comunidad Eucalyptus presenta un entorno
sandbox en el cual los miembros de la comunidad pueden ensayar y experimentar con Eucalyptus. Allí encontrará toda la documentación.
-
Vea algunas interesantes presentaciones de Eucalyptus.
-
"Infrastructure-as-a-Service (IaaS) and Eucalyptus" (developerWorks, diciembre 2009) muestra dos cosas — de qué manera las nubes IaaS prestan servicios básicos que pueden usarse para implementar y ejecutar sus aplicaciones, y de qué manera puede utilizarse Eucalyptus como infraestructura para crear nubes públicas o privadas. (Otro artículo, "Cloud services for your virtual infrastructure," trata sobre Eucalyptus y la Plataforma como Servicio.)
-
Otros artículos de developerWorks sobre Eucalyptus incluyen:
- "Anatomy of an open source cloud."
- "Cloud computing with Linux."
- "Deploy your database applications and projects on the cloud."
-
Conozca más acerca de las herramientas y comandos de Amazon S3.
-
Otros artículos de developerWorks sobre Amazon S3 incluyen:
- "Cultured Perl: Storage management on Amazon S3."
- "Migrate your Linux application to the Amazon cloud."
- "Anatomy of an open source cloud."
-
Para conocer acerca de los comandos UNIX básicos, vea Commonly used UNIX commands
y UNIX commands.
-
Descubra los servidores BladeCenter de IBM. Conozca más sobre el BladeCenter LS20 utilizado en este artículo.
-
La zona de computación en nube
de developerWorks ofrece recursos actualizados sobre computación en nube, incluyendo
- Una introducción al mundo de la computación en nube.
- Artículos y manuales técnicos, podcasts y webcasts actualizados para aliviar sus esfuerzos de desarrollo, y también una ventana a talleres profesionales y sesiones grabadas para hacer de usted un eficiente desarrollador de nubes.
- Conexiones a descargas e información de productos IBM diseñadas para emplear en entornos de nube.
- Una participación activa en los temas sobre los que conversa la comunidad.
-
El sitio de fuente abierta de developerWorks ofrece recursos actualizados sobre software de fuente abierta, su desarrollo e implementación.
-
El sitio de tecnología Java de developerWorks ofrece recursos actualizados sobre estándares y tecnología Java.
-
La zona de tecnología de fuente abierta de
developerWorks alberga conocimientos técnicos de muchos productos de fuente abierta como Eucalyptus.
-
El blog IBM Developer Cloud brinda
los detalles más recientes sobre la nube del desarrollador, según los expertos en computación en nube.
-
El how-to wiki está permanentemente actualizado con escenarios de uso común para la nube del desarrollador.
-
Manténgase actualizado con los eventos técnicos y webcasts de developerWorks .
-
El canal IBMdevcloud en YouTube
ofrece todo tipo de demostraciones prácticas, como por ejemplo el uso de una variedad de productos IBM en la nube de prueba, la creación de instancias y el acceso a las mismas.
-
El portal ibm.com/cloud brinda un
resumen de alto nivel sobre los ofrecimientos de nube de IBM.
Obtener los productos y tecnologías
-
Descargue la última construcción de Eucalyptus.
-
El IBM Smart Business Development and Test en la Nube de IBM es su sitio para comenzar a desarrollar sus aplicaciones para la nube.
-
Con el software de prueba de IBM, disponible para descargar directamente de developerWorks, construya su próximo proyecto de desarrollo en la nube.
Comentar
-
Siga el chatter sobre Eucalyptus en Twitter; también puede seguir developerWorks .
-
El grupo Developer Cloud en My developerWorks es la comunidad para el Smart Business Development and Test en la Nube de IBM.
-
Involúcrese en la comunidad de developerWorks (blogs de desarrolladores, grupos, foros, podcasts, perfiles, boletines, wikis y temas de comunidad) a través de My developerWorks, una red profesional y un conjunto unificado de herramientas de comunidad para conectarse, compartir y colaborar.
Ramanathan Sundarrajan (MydW profile) es miembro activo del grupo de trabajo Cloud Computing de IBM y realizó extensas investigaciones sobre innovaciones de nubes. Ramanathan realizó el seguimiento de estudiantes practicantes del último año de la Facultad de Ingeniería Guindy de la Universidad de Anna; el presente artículo es uno de los resultados de ese proyecto.
Kishorekumar Neelamegan aporta más de 13 años de experiencia en el desarrollo de software, fuertemente centrado en la integración del software a la plataforma Rational. Kishore es un evangelista apasionado de la nube, y frecuente participante de developerWorks: sus actividades pueden seguirse a través de su MydW profile y MydW group, dW India IBMers.