Llegamos a ustedes gracias a:



Reportajes y análisis

Nubes privadas: No son para los débiles

[17/01/2011] Si está pensando en operar una nube privada, necesitará de software de administración para ayudarlo a crear un pool virtualizado de recursos de computación, proporcionar acceso a los usuarios finales, y manejar la seguridad, la asignación de recursos, el tracking y la facturación.

Probamos cinco productos de administración de nube (Cloud Manager de Novell, Eucalyptus Enterprise, OpenNebula, Citrix Lab Manager, y CloudStack de Cloud.com) para ver si la actual generación de herramientas es capaz de enfrentar la tarea.
Encontramos que Cloud Manager de Novell era el único producto que tenía todas las características que buscábamos. Por tanto, Cloud Manager es el claro ganador de nuestro Clear Choice Test. Quedamos frustrados por algunos de los otros productos, y un par de ellos no se encontraban listos aún para el trabajo duro.
Como en toda discusión sobre cloud computing, el primer paso es obtener definiciones. En esta prueba, estamos construyendo y entregando infraestructura como servicio (IaaS) dentro del firewall corporativo.
Y aunque ciertamente es posible correr correo electrónico y aplicaciones de línea de negocios en una nube privada, nuestra prueba se enfocó en escenarios en donde los desarrolladores o usuarios finales están en capacidad de seleccionar un conjunto finito de recursos (hardware, licencias, aplicaciones) para trabajos de corta duración pero no continuos.
Diseñamos nuestra prueba para ver cuán accesible era la aplicación de administración de nube privada tanto para administradores como para usuarios; especialmente si los usuarios no eran parte del personal de sistemas técnicos o desarrolladores.
También nos concentramos en la capacidad del programa de administración de reunir varios tipos de recursos, proporcionar soporte a máquinas virtuales heterogéneas, así como hacer esto de forma segura; y poder reportar lo que se hace y calcular el costo de todo.
A continuación los reviews individuales de los productos:
Novell Cloud Manager 1.0
Cloud Manager (CM) de Novell controla los activos internos de forma muy similar a como lo hacen los proveedores de servicios de nube pública, pero perfeccionando sus detalles y con un alto grado de automatización.
Cloud Manager permite a los constructores de nubes privadas identificar activos de hardware, unir pools de recursos en servidores virtualizados, empaquetar soluciones, y luego facturar y hacer el seguimiento del uso a través de Active Directory y modelos de seguridad LDAP.
Al igual que con el resto de los productos evaluados, se requiere de un considerable trabajo de preparación para asignar los recursos de hardware y software, agruparlos en componentes identificables, y luego permitir que sean accesados y rastreados a través del ciclo de vida de la fase de producción.
Cuando finalmente queda lista la construcción, Novell Cloud Manager ofreció la forma más madura de administrar, aprovisionar y contabilizar los recursos de nube, con el beneficio añadido de que podían inmediatamente ser manipulados por los usuarios finales.
Existen dos componentes de control principales: el Cloud Manager Application Server, y el Cloud Manager Orchestration Server, que instalamos en un ambiente VMware 4.1 usando una máquina virtual SUSE 11 para cada servicio.
El aprovisionamiento inicial también requirió construir máquinas virtuales que sirvan como librería a la cual se accedería mediante el CM Orchestration Server (CMOS) para hacer el trabajo. El CMOS contiene componentes (provenientes de la adquisición de PlateSpin por parte de Novell) que construyen instancias customizadas de maquinas virtuales.
E instalamos un agente CMOS en el vCenter de VMware para conectar los bits de Novell con VMware. Novell Cloud Manager también funciona con los hipervisores Xen e Hyper-V, pero no los evaluamos.
Una vez configurado -lo cual no fue difícil-, Cloud Manager nos permitió exponer recursos de nube y ponerles límites. Los usuarios se autentican a través de los servicios de directorio de Active Directory o LDAP, y se usan plantillas pre configuradas para calcular el costo de los componentes de la nube, implementarlos y estimar su ciclo de vida.
Los componentes son máquinas virtuales configuradas con aplicaciones pre instaladas y opcionales, con características específicas como vCPU, almacenamiento, memoria, direcciones IP. La configuración puede quedar fija, o permitirse cambios, tales como el tamaño o localización del almacenamiento o los incrementos de memoria.
Las plantillas deben encontrarse disponibles para los usuarios en una parte del NFS montado por vCenter como almacenamiento. Probamos las máquinas virtuales tanto de Windows Server como de SUSE Linux Enterprise Server y no tuvimos dificultades en su lanzamiento y sus payloads.
Los componentes de facturación y contabilidad de Novell Cloud Manager añaden un sabor de Managed Services Provider (MSP) y los diferencian de los otros paquetes que revisamos. Cada carga de trabajo puede mostrar cuánto va a costar al mes en base a las tarifas establecidas por el administrador -éstas pueden incluir costos tales como almacenamiento (por gigabyte), vCPU, memoria (por megabyte) y costos de red y almacenamiento.
Por ejemplo, podemos establecer tres dólares por vCPU al mes. (Todo se calcula en costos mensuales, no por hora). También se pueden generar varios reportes de negocios en formatos CSV, PDF o Excel. Los recursos empleados luego pueden ser seguidos, facturados, de la misma forma como cuando los usuarios compran y usan recursos de nube públicos de un MSP o proveedor de nube privada.
CM nos ofreció una imagen completa de la administración de nube privada. La documentación era adecuada y necesaria, ya que en esencia se está construyendo una nube desde sus cimientos, y luego se la ofrece para servicios de producción pagados.
Citrix Lab Manager 3.9 con portal de autoservicio
El portal de autoservicio de Citrix no es un producto independiente, es parte de la Citrix XenServer Platinum Edition unido con el Citrix Lab Manager, un administrador de recursos y sistema de control específicamente creado para las máquinas virtuales de XenServer.
XenServer tiene la capacidad de convertir los componentes de Lab Manager en un sistema de aprovisionamiento de nube mediante roles definidos dentro del portal de autoservicio.
A diferencia del Cloud Manager de Novell, el portal de autoservicio (SSP, por sus siglas en inglés) es específico para XenServer, pero funciona con máquinas virtuales de Linux y Windows que pueden ser cargadas fácilmente con especificaciones de aplicaciones y ambiente (CPU, memoria, etc.) para su uso en este sistema similar a una librería.
El SSP hace el seguimiento de mucha información en los reportes pero no proporciona los componentes necesarios para facturar, algo que se tiene que manejar fuera del paquete.
Se necesita XenServer 5.6 Platinum Edition, el cual es licenciado por servidor sin importar cuantos cores contenga el servidor. Nosotros instalamos XenServer y configuramos un servidor de licenciamiento para asignar la licencia Platinum. Luego importamos una plantilla de maquinas virtuales de Lab Manager (que debe localizarse en el almacenamiento compartido), y luego instalamos la base de datos Postgres y Lab Manager en ella. Luego de unos pasos más en la configuración pudimos tenerlo todo listo, aunque experimentamos unos cuantos dolores de cabeza con el appliance virtual de Linux Licensing.
Las máquinas virtuales de nube que se iban a utilizar con el portal fueron luego creadas a partir de las imágenes del sistema operativo ISO almacenadas en nuestro servidor. Una vez que fueron creadas, necesitamos instalar los agentes invitados de Lab Manager, y tanto las máquinas virtuales de Windows como de SLES funcionaron bien.
Dentro del portal, asignamos plantillas a partir de ejemplos que podían usarse para definir qué roles van a tener los administradores y los usuarios, y qué máquinas virtuales y recursos pueden utilizar.
Lab Manager y el portal se pueden conectar a Active Directory o LDAP (nosotros usamos Active Directory) para la autenticación del usuario, y los usuarios tienen roles que se encuentran bastante detallados dentro de Lab Manager. Los usuarios pueden tener cuotas o límites en la memoria o espacio de disco.
Al evaluar el portal, lanzamos varias máquinas virtuales Windows y Linux en forma exitosa y simplemente con roles de usuarios. Las máquinas virtuales contienen aplicaciones pre configuradas, o simplemente son instancias de sistema operativo en bruto. El portal merece reconocimiento por su facilidad de uso que puede ser aprovechada por cualquier civil ilustrado.
Dentro de Lab Manager encontramos reportes de facturación que son bastante detallados y pueden incluir mucha información sobre el nombre del trabajo, tiempo de inicio, tiempo de fin, RAM usado, almacenamiento usado, etc. Estos reportes pueden utilizarse para crear información de facturación, pero no hay ningún costo asociado con estos campos y, como señalamos, el costeo/facturación se encuentra fuera del alcance del portal.
CloudStack 2.1.3 de Cloud.com
Algo más espartano y menos flexible es CloudStack de Cloud.com. CloudStack utiliza una aplicación de servidor de administración que puede encontrarse en una máquina virtual o una caja física que corra Red Hat Enterprise Linux, o Centos 5.4+ edición de 64 bits. Aunque es utilitario, CloudStack sirve como una librería o repositorio de imágenes de máquinas virtuales que pueden utilizarse en una nube o en una configuración similar a una nube.
Se requiere de bastante preparación antes del deployment. Una vez que uno crea una máquina virtual, no se puede cambiar la asignación de CPU, memoria, número de CPU o tamaño de disco; la configuración de las máquinas virtuales es fija. Esto significa que una gran cantidad de posibles máquinas virtuales debe ser bien planeada para satisfacer los potenciales requerimientos de configuración, y construirse antes del deployment.
Evaluamos CloudStack con Citrix XenServer. Aunque el sitio web señala que se soporta KVM y VMware, no pudimos encontrar documentación para esto y luego nos dijeron que el soporte se proporcionará en el release 2.2, que actualmente se encuentra en beta. El almacenamiento para CloudStack funciona con NFS e iSCSI, 100GB mínimo. Y se requiere al menos de un share de NFS para almacenamiento secundario. Luego, se requiere de un iSCSI u otro NFS para el almacenamiento primario.
Tuvimos algunos problemas con CloudStack. Como mencionamos, una vez que uno crea una maquina virtual es muy difícil alterarla. Si uno quiere algo diferente, tiene que borrarla y crearla nuevamente, lo cual es fastidioso. Es posible ir a la base de datos MySQL que hace registro de las configuraciones de Cloud.com, pero esta firma no ofrece un esquema para la base de datos, y las actualizaciones son manuales y complicadas. El soporte para base de datos se lanzará pronto, de acuerdo al vocero de Cloud.com.
Intentamos crear una nueva instancia de máquina virtual dos veces, pero fallamos en ambas ocasiones porque no había suficientes direcciones IP disponibles. La interfase de usuario nos dijo que teníamos tres máquinas virtuales disponibles para una cierta cuenta, pero en realidad solo una se encontraba ahí.
Los defaults en la interfase de usuario generalmente se salen del rango de lo normal. Como ejemplo, hay un default de 24 horas antes que una máquina virtual que ha sido destruida se borre. A pesar de que se encuentra destruida, la dirección IP asociada con ella no es devuelta, y uno no puede añadir otra máquina virtual hasta que la máquina destruida sea suprimida si uno no tiene suficientes direcciones IP. Esto puede ser un problema si uno tiene muchos usuarios que usan muchos recursos de máquina virtual de nube. Recomendamos considerar esto antes de la implementación.
Otra limitación es que no pudimos crear ninguna máquina virtual en el nodo de XenServer antes de añadir la máquina al repositorio de Cloud.com, ya que no hay un proceso de descubrimiento de máquinas virtuales existentes/actuales. Si una máquina virtual se añade a XenServer antes, CloudStack no se va a inicializar adecuadamente y no se puede seguir configurando CloudStack.
También encontramos que no podíamos tener el servidor de licencias de XenServer en el nodo; el servidor de licencias debe encontrarse en otra máquina o máquina virtual, no en el nodo. Este y otros comportamientos quisquillosos no se encuentran anotados en la documentación, lo cual podría ser incorrecto o desorientador.
Luego de la tediosa configuración, CloudStack soportó las máquinas virtuales Windows y Linux sin incidentes. CloudStack toma en cuenta la seguridad LDAP, pero usamos la nuestra para modificar la interfase de usuario web por defecto. Existen usuarios incorporados (no miembros de un servicio de directorio) que pueden ser autenticados si se desea.
El uso de CloudStack es registrado por usuario, aunque esto no se muestra en ninguna parte en la interfase de usuario web; solo se encuentra disponible a través de la API listUsageRecords API, pero es posible modificar la interfase de usuario web, como fue el caso con la seguridad LDAP. Los programadores SOAP probablemente puedan hacer plantillas de facturación para los datos.
Eucalyptus Enterprise Edition 2.0.1
Hemos revisado Eucalyptus antes como parte de Ubuntu Enterprise Cloud (UEC) y ahora vamos a ver lo que tiene la versión Enterprise. De hecho openEucalyptus es la base de ambas versiones, y se sabe que es sólido, pero debido a errores en la documentación, casi nos rendimos dos veces.
Los componentes de administración de la Enterprise Edition (EE) son similares a aquellos usados en la UEC: Cloud Controller, Walrus (para almacenamiento tipo Amazon S3), un Storage Controller (para almacenamiento tipo bloque más que tipo archivo) y un Cluster Controller.
Los componentes son instalados en una máquina RHEL 5.4+, CentOS, 5.4+ u OpenSUSE 11.2+ sobre el bare metal, más que sobre una máquina virtual (aunque esto no se encontraba documentado sino hasta la mitad de nuestro review).
Instalar la EE es pesado debido a la pobreza de la documentación. Aunque Eucalyptus generalmente instala la EE para sus clientes, nosotros preferimos hacerlo por nosotros mismos. En el proceso, descubrimos que el soporte para las ediciones de Windows Server era problemático y no se encontraba bien documentado.
En defensa de Eucalyptus, señalan que su personal no tiene dificultad con ello, y aunque les creemos, la disponibilidad de componentes de nube es crítica y se hace dependiente de la disponibilidad del personal de soporte de Eucalyptus.
Durante la instalación, tuvimos que hacer una lista de trucos, referentes ocasionalmente a la documentación de openEucalyptus para arreglar cosas. Luego de que se nos informara a medio camino de que necesitábamos un servidor físico para los componentes de administración, tuvimos más trabajo que hacer.
Luego creamos imágenes e instancias usando los mismos pasos que usamos para crear instancias de UEC. Esto incluye empaquetar las instancias, subirlas y registrar las instancias. Las instancias de VMware actuales deben pasar por una conversión, y las instancias de Windows deben pasar por un proceso de conversión de varias fases; una de las fases puede hacer que las instancias de Windows Server tengan una configuración de hardware de boot-time incorrecta, lo cual puede dejar con una pantalla azul a nuestras instancias hasta que soporte nos dijo cual era el motivo.
No hay enlaces a LDAP o Active Directory para la autenticación de los usuarios, así que los logons de los usuarios y los administrativos se encuentran contenidos en la seguridad de la EE, la cual apenas y es admisible.
Una vez que la instalación se ha completado, no hubo problema en el uso de las instancias convertidas y registradas. La interfase de usuario web de la EE es un poco primitiva, aunque hace el seguimiento de las instancias utilizadas de forma adecuada.
La única forma de usar las máquinas virtuales es usando las herramientas euca en la línea de comando, u otras herramientas de Amazon. Las herramientas como euca-run-instances, euca-reboot-instances y euca-terminate-instances son comandos que los usuarios necesitan para usar y dejar de usar las instancias; esto no es atractivo para las personas comunes, pero los desarrolladores y administradores no tendrán problema con ello.
Lo único que los usuarios o administradores pueden ver en la interfase de usuario son las imágenes que se encuentran disponibles para ellos y las credenciales que van a usar con herramientas de línea de comando (ssh keys, secret keys, query ID, X.509 certificates, etc). Para tener información sobre como correr instancias de máquinas virtuales se necesita una herramienta llamada euca-describe-instances. Hay toneladas de otras herramientas de línea de comando disponibles. Sin embargo, no hay interfases simpáticas para que los usuarios se conecten para ver las instancias administradas, apagarlas o hacer reboot.
Hay una sección de la interfase de usuario de la EE que puede ser usada para construir reportes sobre cosas como los eventos del sistema, y recursos que han sido usados. Los reportes pueden exportarse a varios formatos como PDF, CSV, Excel o HTML.
Con los reportes de uso de recursos uno puede ver el uso del almacenamiento o de las instancias, incluyendo cuántos volúmenes fueron usados, cuántas horas fueron usados, y cuántas instancias fueron creadas. Esto puede usarse para la facturación, aunque no hay una facturación incorporada.
Al final, las deficiencias de la documentación nos volvieron locos; y gastamos demasiado tiempo quitando los bugs a este paquete. Recomendamos usar el soporte de Eucalyptus si le parecen interesantes las características de la EE.
OpenNebula 2.0
El proyecto OpenNebula proporciona un toolkit de administración de nube que es específico de instancias de máquinas virtuales Linux, y es un componente de un grupo mayor, la Open Cloud Community. OpenNebula es código abierto por completo, y no open core como Eucalyptus Enterprise.
OpenNebula está especialmente diseñado para las necesidades de los desarrolladores y un uso de máquinas virtuales de nube no continuo (enfocado en el control del trabajo). Puede funcionar con civiles capacitados pero requiere de un administrador con habilidades moderadamente fuertes en Unix/Solaris/Linux para la configuración y el uso por parte de usuarios de nube privada. OpenNebula tiene opciones también para nubes públicas e híbridas, pero nos concentramos en las nubes privadas para este review.
OpenNebula corre sobre Ubuntu 10.0.4 o CentOS 5.4+ (también funciona con la mayoría de las otras distribuciones Linux, pero la instalación express solo se encuentra disponible para las distribuciones mencionadas). Su instalación se basa estrictamente en script (en lugar de GUI) y requiere de numerosos (pero fáciles de hacer) archivos de configuración.
Las imágenes de máquinas virtuales de OpenNebula deben ser creadas como imágenes KVM o Xen antes de ser instaladas mediante script. También existe un controlador de VMware, pero requiere que la API libvirt se encuentre instalada desde la fuente y toma mucho más esfuerzo hacer que corra.
Hay una máquina virtual de muestra que se puede descargar para evaluar el ambiente. Pudimos usarla y hacerla correr fácilmente. Una vez que una imagen se crea, tuvimos que copiarla manualmente donde queremos que estén almacenadas las imágenes. Luego creamos un archivo de configuración para la imagen de la máquina virtual y creamos una descripción de red.
Luego de que se añadió la configuración de la red con el comando onevnet, lanzamos una instancia de esa imagen con el comando onevm mediante un usuario logeado. Pudimos hacer que un servidor Linux funcione perfectamente sin problemas. También intentamos utilizar una máquina virtual de Windows Server 2008 que estaba funcionando en KVM, pero desafortunadamente no pudimos lanzarla con OpenNebula. Hay bastante soporte para Windows, pero no una guía real.
Entre los complementos soportados se incluye la autenticación LDAP (que requiere net-ldap ruby gem), contabilidad (que requiere sequel ruby gem), controladores de VMware y el instalador express de OpenNebula (que usamos para la instalación).
Usamos Ubuntu 10.04 en una máquina virtual sobre ESX 4.1 como front end y otra máquina con Ubuntu 10.04 como nodo. El instalador express configura un share NFS en el front end para que los nodos compartan imágenes.
Todo se hace con herramientas de línea de comandos; no había una interfase web para interactuar con OpenNebula. A continuación algunos de los comandos principales:
* oneimage (añade/lista/borra un imagen/iso a un repositorio y establece atributos para esas imágenes)
* onevm (crea/borra/inicia/detiene máquinas virtuales y otras funciones relacionadas con ellas)
* oneacct (usado para obtener datos de facturación/contabilidad sobre hosts/máquinas virtuales/usuarios)
* onecluster (lista/crea/borra clusters) onehost (añade/borra/sincroniza hosts) oneuser (crea/borra/lista usuarios)
* onevnet (usado para crear/modificar/borrar redes virtuales
OpenNebula soporta varios tipos de tipos de esquemas de autenticación, incluyendo nombres de usuario y contraseña con SQLlite o mySQL, y mediante administración de SSH key.
También hay un nuevo complemente LDAP, aunque no pudimos hacerlo funcionar correctamente con Active Directory. (Uno de los problemas con la documentación de OpenNebula es la falta de consejos para solucionar problemas).
Hay un complemento para OpenNebula que instala el comando oneacct, que le permite a uno buscar información sobre cuánto tiempo corren las instancias, quiénes las corren, en qué host se encuentran y otros detalles. Esta información puede usarse para facturación (aunque no hay nada pre creado para este propósito, esto se deja en manos del administrador).
La modularidad de OpenNebula lo hace un candidato para su futura conglomeración con otras aplicaciones tipo FOSS para una configuración de nube privada completamente en código abierto, aunque hay muchas piezas que aún faltan. Aunque la documentación de OpenNebula no es maravillosa, se puede trabajar con ella, y nos gustó cómo funcionó la primera vez, tal como se esperaba.
OpenNebula contiene herramientas útiles, y sus fortalezas son más como un conjunto de herramientas que funcionan juntas para hacer que los recursos de nube se encuentren disponibles para los desarrolladores y el personal de sistemas más que para los usuarios civiles.
Conclusión
En general, construir una nube privada con las herramientas que hemos revisado implicó mucho trabajo de configuración por adelantado, luego unir la configuración con la familia del hipervisor soportado, y luego encontrar formas de agregar/objetivar pools de recursos para que sean fácilmente disponibles mediante los ciclos de vida de las instancias.
El Cloud Manager de Novell tuvo un buen desempeño y sabe como cobrar por él. El portal de auto servicio de Citrix se construye sobre Lab Manager, pero los componentes del portal son parte de un costo de licencia por servidor, y se encuentran cautivos de XenServer. Cloud.com pronto ofrecerá una mayor compatibilidad con estos dos productos, pero es un trabajo en desarrollo. Nos gustó OpenNebula para el uso del personal avanzado de sistemas o los desarrolladores. Luego queda Enterprise Eucalyptus, que Eucalyptus puede controlar, pero el EE nos sacó de quicio.
Tom Henderson y Brendan Allen, Network World (US)