Cómo podemos terminar usando Openstack

Una cuestión que se discute ida y vuelta en cada charla sobre virtualización es si Openstack va a llegar a usarse "masivamente" igual que Linux.

La discusión en realidad, se parece mucho a la que había hace 10 años atrás cuando Linux "aparecía" en ambientes de server, como webserver y estaba presente la discusión de si Linux iba o no a usarse masivamente como sistema operativo de servidor para otra cosa que no fuera LAMP (webservers basados en Apache).

Claro, igual que en ese momento, hablar de Openstack y limitarse a considerar un uso masivo eventual es una simplificación.


Cuando entendemos lo fácil que es instalar una infraestructura Openstack, luego es muy directa la conclusión: Openstack va a utilizarse masivamente de un momento a otro.

Si Openstack no tiene éxito como software libre de cloud, lo tendrán otras opciones: 

http://incubator.apache.org/cloudstack/
http://www.eucalyptus.com/


La nube privada opensource
La cuestión que surge luego de instalar y configurar tu primera nube es simple: podemos instalar una, dos, tres, cuatro infraestructuras de nube privada, rápidamente, sin muchas vueltas.

No hay costo de licencias que pagar, las imágenes de los servidores virtuales que se puede deployar quedan disponibles de inmediato, su configuración se simplifica en grado sumo, etc.

El salto que hay desde instalar un - ahora ya - simple hipervisor como KVM, Vmware ESX, Xen, etc. a tener una real infra de cloud privada es simple: se manejan imagénes completas, desde CLI (línea de comando) o desde una GUI, se las puede montar desde imágenes .iso, desde snapshots de las máquinas virtuales en ejecución, etc. etc. 

El conjunto total de software que usa Openstack es libre: 

 - Linux como sistema operativo base, 

 - Mysql como backend (si "conmueve" de algun modo tener una sola DB corriendo como backend de una infraestructura - virtual - completa, fácilmente puedes montar Mysql en esquemas de alta disponibilidad..de hecho, es una recomendación), 

- Los componentes de Openstack en sí pueden distribuirse entre varios servidores (la última vez que miré, ya había un par de maneras de montar - al menos manualmente - cada componente en un esquema al menos de redundancia, sino de alta disponibilidad).

 - Los componentes de Openstack pueden ensamblarse de diferentes modos, incluído claro, la posibilidad de correrlos todos desde un solo server.

 - La infra básica de Openstack para altos requerimientos computacionales (o sea, poder correr muchas máquinas virtuales, poder disponer de la posibilidad de correr a futuro - ilimitadamente - cuantas máquinas virtuales se quiera/requiera/necesite, etc.), consiste en:

* Controlador: donde corren el software que maneja la nube privada
 * Storage
 * Nodos de Computación: (en la práctica, cada uno es un hipervisor estándar, gestionado desde Openstack)
* etc. (hay un par de cosas más).

 Y la idea básica de escalabilidad sería que se puede agregar los nodos de computación que se requieran.

 Es decir, a medidad que vayamos necesitando correr más máquinas virtuales y si nuestros servers físicos actuales ya no soportarán esa carga de trabajo, simplemente se añaden nuevos servers de computación.


La comparación directa de qué tan bueno es el software opensource Openstack es contra Vmware vSphere, y prácticamente toda argumentación contra la implementación de una nube privada opensource recae sobre dicha comparación. 

La respuesta a favor de Openstack deriva del sentido común: quienes implementen una nube privada, pueden poder necesitar hacerlo no una sola vez, sino varias veces. 

 Si estás usando software comercial, cada nube privada tendrá un costo asociado inevitable. 

Los costos puntuales más elevados disponibles en software comercial de infraestructura privada y nubes privadas, están asociados justamente a esta necesidad de las organizaciones: cuando más locaciones remotas tenga la infraestructura para ser asociadas de algun modo con la infraestructura de nube privada, más altos son los costos (porque los componentes y licencias a pagar requeridos son un "extra" a la infraestructura de nube privada local).

Ejemplo 
Un ejemplo simple es un comercio de venta al público, que tenga dos sucursales, en cada una tiene un rack con 4 a 6 servidores corriendo todo tipo de software de servicios (webservers externos, internos, DBs de backend para aplicaciones internas, soft de servicio para el comercio, etc.).

El nivel gerencial de IT resuelve que tienen demasiados servers físicos corriendo, los recursos son desaprovechados y es anti-económico, surge la idea de montar una infraestructura virtual. 

 En el análisis surge la cuestión de la administración de la infraestructura virtual, y su consumo en recursos dada la necesidad de implementar muchos hipervisores a mediano plazo (más de 4 hipervisores por sucursal, un total inicial de 8 hipervisores en total), con estimación a que se implementen al menos 5 hipervisores más en un plazo no mayor a 5 años (en la idea de que los ciclos de vida del hardware ya en producción en esa fecha, estarán finalizando y los - ya en ese momento - viejos hipervisores /servers físicos deberán ser reemplazados por esos 5 nuevos servers).

 Alguien sugiere gerenciar la infraestructura virtual como una nube privada, directamente desde una capa de software corriendo "a caballo" sobre todos los hipervisores, permitiendo una administración simplificada - y con mucho menos costo de administración en horas/hombre - de máquinas virtuales ("instancias" en la jerga de nube), y de los recursos de virtualización.

 La idea de un software comercial llamado "ZZZ" surge de inmediato, pero luego se dan cuenta que los planes a futuro implican abrir nuevas sucursales en los próximos 5 años, al menos 4 nuevas sucursales. Entonces el plan de implementación de una nube privada deberá contemplar una implementación de al menos 6 locaciones de nube privada diferentes. 

 Por cada locación se deberá pagar licencias para poder utilizar las capacidades del software comercial de nube privada llamado "ZZZ". Se hacen los cálculos y luego se suma el hardware que se va a requerir para sostener todo ese software (incluídos aquí los requerimientos del software de usuario final que efectivamente es necesario para los clientes internos).

 Es aquí donde los números no cierran hoy en día, los costos de licencias para montar no una, sino 4, 5, 6 nubes privadas, casi simultáneamente, o con muy pocos años de diferencia, son tremendos.


Conclusión: la idea original o cómo se van a usar las nubes privadas en realidad
La idea "original" era que montar una nube privada iba a ser suficientemente caro en términos de necesidades de hardware, que nadie iba a necesitar más de una sola nube privada en su organización.

Más o menos es el mismo razonamiento que se hacía 10 años atrás cuando un server físico era "caro" y nadie pensaba que una organización chica a mediana fuera a necesitar más de un solo software de servidor web. 5 años luego de esos razonamientos, muchas organizaciones ya estaban implementando decenas de Apaches para todo tipo de tareas (por ejemplo, ¿cuantos servicios Apache tienes hoy corriendo en tu infraestructura?).

La idea "original" de los proveedores de software comercial de virtualización era proveer hipervisores, y que las grandes organizaciones luego incorporaran una capa de soft de gestión "a caballo" para manejar esos hipervisores. Pero solo "una" capa, una sola instancia de ese soft de gestión.

Sin embargo, las infraestructuras organizacionales IT típicamente están suficientemente descentralizadas, y los servidores, excepto pocos casos ideales están geográficamente dispersos, al menos entre varios edificios de una ciudad. En estos casos implementar más nubes privadas va a ser una opción interesante.

Si tienes todos tus servidores en la misma locación física, lo que necesitarás es poder hacer crecer indefinidamente la infraestructura, sin preocuparte de migraciones masivas de plataforma virtual porque la organización de repente no tiene presupuesto para dar el siguiente salto.

Cuando se produzca ese evento, es probable que muchos administradores tomen un par de servers y empiecen a montar el proto-nucleo de su futura nube privada, y medida que pasan los meses y años (unos pocos), esos núcleos se van a poblar de nuevos nodos y máquinas virtuales funcionando en producción, y al cabo de un tiempo, el salir a pagar licencias por algo que tiene costo cero y está funcionando perfectamente hace 2-3 años, va a ser una pregunta de respuesta obvia.