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.
