OpenStack y VmWare – Parte II

vmware-openstackCuando nos planteamos el uso de una plataforma como OpenStack, está claro que uno de los objetivos a cubrir es el uso integral de la plataforma con todas sus funcionalidades. Para ello OpenStack requiere que los hipervisores utilizados sean basados en herramientas opensource, por lo que cuando implantamos la herramienta sobre un entorno VmWare estamos infrautilizando todo el potencial que nos ofrece.

Para poder realizar el despliegue de instancias sobre un entorno vSphere se requiere una máquina linux con el agente de nova instalado que apunte al vCenter del entorno. El controlador de VmWare requiere que se le pase cierta información: el datacenter al que va a estar conectado, el bridge que utilizará para levantar las instancias, el datastore sobre el que se realizarán los despliegues, etc…

1
2
3
4
5
6
7
8
9
[DEFAULT]
compute_driver=vmwareapi.VMwareVCDriver
[vmware]
host_ip=<vCenter host IP>
host_username=<usuario vCenter>
host_password=<password vCenter>
cluster_name=<Nombre del Cluster en vCenter>
datastore_regex=<Opcional datastore regex>

Esto implica que si utilizamos el resto de componentes de OpenStack, perdemos capacidades en lo referente a SDNs, así como el uso de grupos de seguridad, que solventaremos utilizando NSX, tecnología propietaria de VmWare, o la inclusión automatizada de claves SSH para las instancias desplegadas, entre otras.

Además, al contrario de lo que ocurre con los entornos KVM, se requiere almacenamiento compartido, sin soporte para almacenamiento efímero, DRS habilitado (quien no lo tiene) y la copia de imágenes desde GLANCE puede llegar a suponer problemas debido a los tamaños, sin excluir la duplicidad de los ficheros, que detallaremos en otro momento.

CEILOMETER, el módulo de telemetría de OpenStack, no recibe información sobre consumos de las instancias desplegadas sobre ese entorno, por lo que toda la parte de orquestación y auto escalado (HEAT) dependerá de las herramientas de VmWare.

Nova .- VmWare Driver
Nova .- VmWare Driver

Otro de los inconvenientes es la nula capacidad para integrase con CEPH, el almacenamiento por bloque y de objetos de forma distribuida es una de las grandes ventajas de las plataformas abiertas. No sólo por lo que implica a nivel de costes dentro de lo que sería un proyecto de virtualización o IaaS, ya también por las capacidades ofrecidas en cuanto a des-localización y escalabilidad. Volvemos a insistir vSan es una excelente herramienta, ¿pero puede competir con un entorno basado en Ceph o GlusterFS?, en lo que a posibilidades ajenas y uso fuera del entorno virtual se refiere.

En lo que respecta a volúmenes, CINDER, estamos en una situación similar; podemos configurar la integración de los volúmenes con los datastores de VmWare y utilizar entornos iSCSI de forma limitada, pero nada más lejos de todas las capacidades que nos ofrece otro tipo de soluciones.

Es cierto que VmWare tiene herramientas que cubren muchos de estos aspectos, por no decir todos, pero para que necesitamos OpenStack si lo único que vamos a realizar es despliegue de instancias contra tecnología VmWare, lo cual nos obligará a incurrir en redundar gastos derivados de un consumo de espacio mayor y de unas necesidades de conocimiento de ambas plataformas, que hacen que un proyecto así sea del todo inviable.

El resumen de todo esto podría ser: Teniendo disponible vRa por que utilizar OpenStack, o mejor dicho… Teniendo OpenStack por qué desplegar sobre VmWare. Sin embargo, esa es una pregunta a la que cada uno deberá dar respuesta. Continuaremos desgranando la integración de los diferentes componentes en siguientes post…

Deja un comentario