Nubes Privadas para dummies

Este artículo comenzó igual que la mayoría de los problemas interesantes, con una simple pregunta

¿Por qué iniciarse en infraestructuras de cloud privada?.

Desde el punto de vista del especialista en infraestructura, solo puede llamar a una respuesta "Qué? Todavía no comenzaste a implementar una private cloud?"

Sí, es así de necesario.

En el fondo es bueno

La cuestión de fondo es que las private clouds son una solución a diversos problemas de infraestructura que han estado dando vueltas en los datacenters desde poco tiempo después de que se hizo el avance - o retroceso, es cuestión de opiniones - tecnológico de grandes mainframes propietarios a "pequeños" servers (primero el hard propietario de Digital, Sun, etc. y luego a Intel, AMD, ahora inclusive yendo a ARM).

Si todavía tienes pocos servers en tu datacenter, este es el momento de empezar a ganar insight en infraestructura de private clouds. De ese modo tendrás listo el skillset y el expertise para el momento en que llegues a los problemas que se desprenden de usar servers individuales, luego sumarles storage externo (SANs y similares), luego empezar a virtualizar servers físicos en hipervisores y luego empezar a utilizar manejadores de hipevisores.

Una cloud privada es justo el tipo de software que puedes utilizar junto con los manejadores de hipervisores o para reemplazarlos por completo (depende de la solución y del producto) y resolver los problemas que todavía no mencioné (de hecho).

¿Qué ganamos con más trabajo?

Parecería obvia la respuesta, pero vamos a los sucios detalles.

La ganancia de utilizar private clouds son muchas, en principio puedo referenciar las listas de problemas de las páginas de datasheets de los varios vendors de soluciones de virtualización, que es donde vas a encontrar el 100% de los problemas que resuelve una infraestructura virtualizada.

Luego de eso, para qué querrías complicarte la vida con el montaje de una private cloud? La respuesta es simple: no es complicarte, si ya llegaste al último paso y estás usando manejadores de hipervisores en tu día de oficina típico como sysadmin, ya estás a las puertas de:

- Necesitar manos extra ($$$ en más sysadmins), y/o

- Necesitar más tiempo de trabajo propio ($$$ y !#$% a granel, compitiendo simultáneamente por tu valiosa atención)

- En lo técnico, tus máquinas virtuales van a empezar a necesitar un trabajo semi-artesanal de babysitting muy similar a las viejas épocas donde se parcheaba y compilaba manualmente código fuente de Apache para varias decenas de servers. No, no hablemos de kernels, algunos sysadmins ganan un rápido estado de agitación de solo recordar los días de administración manual de kernels Linux :-D

Lo que no anda nos encontró (y no queríamos)

En definitiva, las nuevas capacidades de la infraestructura virtual (y todo lo que hay "abajo"), han creado un monstruo: la facilidad para crear nuevos servidores tan rápido como pueda clickear "aceptar" el sysadmin.

Eso no es bueno, definitivamente, es bueno para el negocio, es bueno para la infraestructura, es bueno para los developers, etc. pero no es bueno para el sysadmin.

Hay decenas de componentes anidados en una infraestructura virtual, que incluso si fue muy bien diseñada (las chances van al contrario), pueden fallar. Ahora ¿por qué digo que "tu" infraestructura virtual está mal diseñada? No lo dije (lee de vuelta), sino que la mayoría de las "infras" van a terminar virtualizadas "por las malas", esto es también conocido como "implementación paulatina", con muchos SPOF (Single Point of Failure), acechando detrás de cada esquina del datacenter.

No se añade a esa sopa de SPOFs un capa más de administración de máquinas virtuales promiscuamente generadas a golpe de llamadas telefónicas de management, un rápido capacity planning (y un feliz "sí jefe, se puede"), y un par de clicks casi no muy meditados.

Esa infraestructura virtual va a requerir - más - tiempo de administración, que no va a estar disponible si estás ocupado creando y borrando máquinas virtuales.

La solución es una private cloud.

Metiendo las manos en el barro

La idea central de la private cloud es ocuparse de crear una interfaz entre los usuarios de la infraestructura virtual, "clientes" a partir de ahora y los recursos de la infraestructura (virtual), "servicios" desde ahora.

Cualquier private cloud software que se precie de llamarse así brinda una interfaz lo suficientemente gráfica para que un "cliente" pueda conectarse a ella, elegir de un menu (ahí hay trabajo de configuración para el sysadmin!), y luego crearse para sí mismo una reluciente y nueva máquina virtual, con toda clase de características técnicas muy interesantes, pero con características no técnicas aún más interesantes:

El servicio del software de private cloud incorpora al autoservicio de creación de máquinas virtuales no solo la extracción quirúrgica de la necesidad de comunicaciones telefónicas y de correos y la correspondiente lluvia de chequeos y autorizaciones, sino también incorpora a la administración automática (configurables por el sysadmin), diversas políticas muy útiles, por ejemplo:

- Cuanto tiempo de vigencia tiene la máquina virtual antes de ser automáticamente borrada

- Será borrada de inmediato? o solo apagada y dejada en reserva, por cuanto tiempo?

- El personal de helpdesk puede crear nuevos servers o clientes virtuales de prueba para software de oficina, con tremendas restricciones a nivel de comunicaciones de red con el resto de la infraestructura interna.

- El personal de sysadmin (esos somos nosotros), podrá crear la cantidad de máquinas virtuales que necesite (quiera), sin importar que se seleccione la cantidad total de RAM disponible en el hipervisor (es broma :-).

- El personal de desarrollo tendrá determinados privilegios extendidos, para crear y guardar determinada cantidad de servidores virtuales (de modo de poder ir probando diversos baseline de configuración para una aplicación).

- etc. etc.

La idea de mostrar un par de políticas no es abarcar todas las capacidades del software de private clouds, sino que se vea qué tipo de trabajo administrativo se está automatizando - esta palabra es adorada por RR.HH. y jefes hoy en día - y mejorando sustancialmente ("si es automático, no puede haber error humano", ya sé, ya sé...está muy sobrevalorada la idea).

Veamos un par de detalles técnicos; hoy disponemos de OpenNebula y OpenStack, software opensource (licencia Apache ambos), que a diferencia de la mayoría del software de clouding privativo permite administrar varios/muchos tipos de hipervisores, incorporando nuevos tipos con regular frecuencia. Traducción al español: desde tu soft de cloud privada puedes usar al mismo tiempo máquinas virtuales (hipervisores) KVM, Vmware, Hyper-V, Xen, Virtualbox y probablemente nuevos tipos (y versiones no retrocompatibles con viejos hipervisores del mismo tipo!!! alguien dijo escalabilidad horizontal?), de hipervisores que vayan apareciendo.

Las posibilidades en lo técnico se amplían al poder utilizar clouds híbridas: múltiples tipos de máquinas virtuales, locales y remotas, que incluye las de proveedores públicos de clouding como Amazon y probables futuros proveedores de clouding basados en estándares (impuestos por los productos opensource como OpenNebula y OpenStack).

Conclusiones

Esto es básicamente una explicación a vuelo de pájaro, así que no hay tanto material para sacar conclusiones.

Lo básico es que si no usas private clouds, lo harás porque:

- te pedirán que lo hagas,

- eventualmente lo vas a necesitar,

- de hecho puede que no lo llegues a necesitar (o que nadie se haya dado cuenta que hace falta :-), y en realidad verás que te soluciona suficientes problemas para que querer usarlas.

- y claro, es innegable, son tremendos powertoys para el sysadmin con un poco de sangre caliente en las venas.

- pensandolo mejor, sí las vas necesitar, es mejor que empieces ahora.