Spiga

Comparación: OpenStack vs VMware vCloud


Este post trata de realizar una comparación, desde diferentes puntos de vista, de dos de las soluciones IaaS más implantadas del momento, como son OpenStack y VMware vCloud. Sin embargo, establecer una comparación directa entre ambas soluciones no es una tarea sencilla, ya que, aunque hay algunas partes de la funcionalidad de los proyectos OpenStack y los productos de VMware que compiten en cierto sentido, el enfoque general y la filosofía de ambos ecosistemas es totalmente diferente [1].

Las soluciones Vmware como ESXi hypervisor,  vSphere y vCenter están enfocadas a la virtualización y no a clouds privados, por lo que no incorporan muchas de las funcionalidades ofrecidas por OpenStack (en especial las referidas a la orquestación, automatización, elasticidad, análisis de errores y almacenamiento de objetos [2, 3, 4]). Por consiguiente, se ha escogido vCloud para este artículo, al estimarse que es el producto VMware que podría ser más equivalente a OpenStack para realizar la comparación.


Funcionalidades técnicas
 
La siguiente tabla recoge una comparación simple y de alto nivel [5] de las funcionalidades ofrecidas por OpenStack y Vmware vCloud:



Funcionalidad
OpenStack
Vmware vCloud
Capa de virtualización
Virtualización tipo 2 – Libvirt sobre Linux. Soporta varios hypervisores: XEN, KVM, HyperV, ESX…
Virtualización tipo 1 – bare metal; sólo soporta vSphere.
Gestión
Open API, Command line, consola Web, herramientas de orquestación. Componentes distribuidos: almacenamiento, redes, computación…
Consola web, API. Requiere contar con vCenter para gestionar de forma centralizada los pools de recursos, nodos y almacenamiento.
Almacenamiento
Almacenamiento de bloques u objetos, escalado vertical u horizontal,  compatible con dispositivos NAS.
Sistema de ficheros tradicional, como NFS, o la solución propietaria VMFS con vCenter.
Redes
Direct connected, non-routable, DHCP. Gestionadas desde la línea de comandos, API o consola web…
Direct connected, non-routable, DHCP. Requiere vCloud Networking and Security.
Monitorización del uso de recursos
Todos los componentes envían mensajes por cada evento.  Éstos se gestionan por un AMQP.
Requiere VMware Chargeback Manager
Instancias
Se pueden lanzar instancias desde imágenes o instantáneas.
vApps o VMs existentes deben ser importadas y entonces se ofrecen como servicio.
Compatibilidad
con clouds
públicos
Compatibilidad con AWS CloudFormation y la API de EC2.
vCloud Connector conecta un vCloud privado con VMware vCloud público.
Soporte / Dependencia del
fabricante
Cientos de empresas de todo el mundo ofrecen soporte técnico y soluciones a medida
vCloud es un producto que pertenece y es comercializado por VMware.
Licencia
Libre
Propietaria

Tabla 1 – Funcionalidades técnicas ofrecidas por OpenStack y VMware vCloud


Coste de adquisición de las licencias

La política de precios de los productos VMware no es sencilla, por lo que es recomendable contactar con un partner que comercialice los productos en España para realizar un estudio a medida. Sin embargo, la tabla 2 permite hacerse una idea del coste adquisición de las licencias para nuestra infraestructura



Producto
Precio de licencia
1 año de soporte y suscripción
VMware vCloud Suite Standard
EUR 4,495.00
Basic
EUR 943.37
Production
EUR 1,123.23
VMware vCloud Suite Advanced
EUR 6,745.00
Basic
EUR 1,415.50
Production
EUR 1,685.29
VMware vCloud Suite Enterprise
EUR 10,350.00
Basic
EUR 2,170.91
Production
EUR 2,584.59

Tabla 2 – Precios de licencia y 1 año de soporte de vCloud Suite

Las licencias de vCloud Suite se conceden por procesador, como vSphere Enterprise Plus, que actúa como base para todas las ediciones de vCloud Suite. Todas las máquinas virtuales de las CPU de vCloud Suite 5 tienen derecho a todos los componentes incluidos en esa edición de vCloud Suite [6].

OpenStack, por su parte, se distribuye con una licencia libre que permite su uso sin restricciones de forma gratuita.

Tipo de licencia


Elegir una solución privativa para un componente tan importante en una organización como es el software para la infraestructura de cloud, es hacer depender toda la infraestructura de la organización del pago constante de licencias de uso y enormes limitaciones en cuanto a la extensión, modificación o adaptación del mismo a las características propias [7].

Optar por software libre no es solo una cuestión económica a corto plazo, es un planteamiento de independencia tecnológica y fomento de la libre competencia
y del desarrollo innovador local. El software privativo está dominado por poderosas empresas estadounidenses (como VMware) y la alternativa que debería plantearse firmemente en Europa, tal y como se recoge en los informes sobre cloud computing de la Comisión Europea [8,9], es optar incondicionalmente por el software libre, que permite que las empresas compitan entre sí de forma justa y equitativa.


Tendencia y previsiones


El desarrollo de software para IaaS ha sido uno de los temas candentes de los últimos años en las tecnologías de la información, y en concreto el software OpenStack se ha convertido en foco de atención de todo el sector, como puede comprobarse en la figura siguiente obtenida de Google Trends, que compara las búsquedas en función de palabras claves.



Imagen 1 - Comparación en las búsquedas de los últimos años en Google de los términos vCloud y OpenStack

Esta diferencia en el número de búsquedas en Google no se produce por casualidad, sino que se debe, por un lado, al impresionante ritmo de desarrollo que se sigue en OpenStack (con una nueva versión cada 6 meses) y, por otra parte, a su acogida en el mundo empresarial, donde todo tipo de compañías y organismos están utilizando esta plataforma para instalar sus clouds públicos y privados.

Por estos motivos, optar por una opción de software libre para el software del cloud no sólo incluye enormes ventajas desde el punto de vista de la independencia tecnológica o de gastos por las licencias de uso, sino que además desde un punto de vista puramente técnico y de usabilidad, los proyecto de software libre para IaaS son una opción competitiva con cualquier producto privativo hoy en día y parece ser que serán en muchos aspectos mejores en un futuro muy cercano dado el enorme ritmo de desarrollo que tienen en el momento actual [10].


Con todos estos datos, ¿adivináis qué solución es la que se decidió utilizar para montar el cloud privado del IES Gonzalo Nazareno? :-)

Midiendo el impacto del Carrier-Grade NAT sobre las aplicaciones en red

Este post es un resumen del rfc7021 'Assessing the Impact of Carrier-Grade NAT on Network Applications', que trata de evaluar el posible impacto del uso de NAT444 por parte los ISPs para seguir ofreciendo servicio IPv4 a sus clientes durante la transición a IPv6. Esta tecnología añade un Carrier-Grade NAT (CGN) en la red del proveedor de servicios de internet, lo que implica realizar NAT dos veces, una en la conexión del cliente a la red del ISP y otra en la red del ISP. Un grupo de organizaciones ha probado el impacto de NAT444 sobre el funcionamiento de muchos servicios y aplicaciones populares de Internet utilizando diferentes escenarios, topologías de red y equipamiento de distintos fabricantes, identificando las áreas donde esta segunda capa de NAT provoca problemas de comunicación.





Servicios que dejaron de funcionar

Varias aplicaciones peer-to-peer fallaron y no superaron los tests, en concreto juegos peer-to-peer con Xbox y llamadas SIP peer-to-peer con el cliente PJSIP. Muchos dispositivos CGN usan NAT "full cone" de forma que una vez se mapea un puerto para un servicio externo se acepten conexiones de entrada en ese puerto. Sin embargo, algunas aplicaciones no enviarion tráfico saliente primero y, por tanto, no se abrió el puerto a través del CGN. Otras aplicaciones trataron de abrir un puerto fijo; en estos casos el servicio funciona para un único usuario, pero falla cuando varios usuarios tratan de usar el mismo puerto. Tampoco funcionaron correctamente aplicaciones como BitTorrent y uTorrent cuando realizaron peer-to-peer seeding.Sesiones FTP con servidores detrás de dos NAT también fallaron. Y el tráfico multicast tampoco se envió a través del CGN.

Servicios que sufrieron un impacto en el rendimiento

Transferencias de ficheros de gran tamaño (entre 750 MB y 1.4 GB) y sesiones múltiples de streaming de vídeo iniciadas en un único cliente en la misma red detrás del CGN sufrieron una reducción del rendimiento comparándolo con los resultados obtenidos en la misma red sin usar NAT.

Otros retos de CGN

  • Pérdida de información de geoposicionamiento.
  • Identificación de la responsabilidad al producirse un abuso.
  • Anti-spoofing. Pueden producirse situaciones en las que se disparen mecanismos antispoofing o antiDDOS, produciendo pérdida de conectividad para algunos usuarios, al superarse los límites de conexiones permitidas desde una dirección IP.


Consideraciones relativas a la seguridad

En general, como un dispositivo CGN comparte una dirección IPv4 con múltiples usuarios, estos dispositivos suponen un objetivo atractivo para realizar ataques DOS. Además, si una dirección IP es añadida a una lista negra (por ej. de SPAM) se podría producir un problema de conectividad al resto de usuarios legítimos de ese CGN.

Mitigación del impacto del CGN

Afortunadamente existen varios métodos que podrían reducir el impacto del CGN en los servicios de internet:
  • Peer-to-peer y gaming--> Uso de un proxy.
  • Geoposicionamiento --> Desplegar el CGN cerca del borde de la red; usar asignación de IP y puerto regional.
  • Registro de peticiones para problemas legales --> Registro determinístico; compresión de datos; registro puertos bulk.
 Aunque, sin duda, la situación ideal sería que los ISPs acelerasen la transición a IPv6 y comenzaran a ofrecer este servicio a sus usuarios.