Consolidar y desagregar/distribuir servicios en infraestructuras virtuales

Ayer en la Hackathon Express 2013, estaba conversando con un par de  IT guys y les comento que estuve trabajando con un cliente familiar para ellos, y que pasamos de unas pocas máquinas físicas a varias decenas de máquinas virtuales en producción, esto causó cierta sorpresa, principalmente porque la cantidad de servicios en producción permaneció más o menos igual, pero la cantidad de servidores virtuales parecía un poco elevada..en otras palabras, tal vez haría falta "consolidar".

Consolidar

Había hace un tiempo la tendencia a "consolidar": incluir la mayor cantidad de servicios posible de correr por servidor físico y por sistema operativo. Esta noción brinda ciertos beneficios por sobre tener muchos servidores y servicios en cada uno.

Sin embargo no es una visión correcta para ser aplicada en un entorno de infraestructura virtualizada. El fundamento detrás de "consolidar" se basa principalmente en limitaciones propias del hardware físico, que no existen más en las infraestructuras virtuales.

La idea principal de "consolidar" se daba cuando un servidor físico se iba haciendo "viejo", y se acerca al fin de garantía o ya lo superaba e iba en camino a ser descontinuado por el fabricante, aquí se buscaba "consolidar", concentrando la mayor cantidad de servicios posibles en servidores físicos que aún tenían garantía o que se encuentraban aún plenamente soportados - en partes y respuestos - por el fabricante.

Otra noción importante devenía del mejor aprovechamiento de recursos además del hardware con garantía: los mismos recursos del hardware (ram, procesador, disco, etc.), los recursos externos (alimentación, disponibilidad de conectividad, etc.). Al consolidar, los servicios se ubicaban de modo tal de poder acceder a un conjunto de ciertos recursos que tal vez no estuvieran disponibles en otro hardware (un server viejo fuera de garantía idealmente), o inclusive, accediendo a facilidades de recursos solo disponibles en el lugar físico donde se iba a reubicar - consolidar - los servicios (por ejemplo: algún link de fibra óptica más cercano al backbone y/o core de la organización, brindando al servicio potencial mayor conectividad hacia la red interna).

Es decir, si pensamos la idea de "consolidar" basándonos en infraestructuras puramente basadas en servidores físicos, y en gral. en recursos físicos, consolidar tiene mucho sentido.

Distribuir, desagregar

Las infraestructuras virtuales crean una "capa intermedia" de administración y gestión de recursos (hipervisores y sus dispositivos virtuales, manejadores de hipervisores), que son luego entregados a servidores virtuales.

Esos servidores virtuales consumen los recursos entregados por la capa de virtualización, incluyendo procesador, ram, discos, conectividad, etc.

La capa de virtualización se encarga de proveer servicios avanzados de gestión de recursos, por ejemplo, permitiendo tener servidores virtuales, cuya suma total de memoria ram virtual asignada es mayor que la memoria ram física disponible en la capa física (en el servidor en el que corre el hipervisor en gral.). Similares características se encuentra en cuanto a procesadores, espacio en disco, conectividad, etc.

Entonces, si de repente tenemos un solo servidor virtual con 3 servicios que consumen X cantidad de ram, y los separamos en 3 servidores virtuales, en algún punto no estamos desaprovechando la memoria ram física en realidad. Una parte mínima de memoria adicional será ocupada para mantener tres sistemas operativos diferentes funcionando al mismo tiempo (3 kernels y poco más), y la memoria individual que ocupa cada servicio será muy similar en cada server separado, respecto de lo que ocupaba cada uno cuando estaban "consolidados" en un solo server virtual.

Las ventajas que obtenemos al desagregar servicios, al distribuirlos en varias máquinas virtuales en vez de consolidarlos es que nos hacemos de piezas más pequeñas para manejar, servidores que ocupan menos memoria ram (algo que es barato, pero no siempre está disponible en demasía), y si necesitamos mover una máquina virtual de un hipervisor a otro, casi seguramente lo podremos hacer.

Hay otras ventajas evidentes de la desagregación: si un kernel falla, los otros dos servicios siguen funcionando, si un servicio tiene una brecha de seguridad, los otros dos permanecen - en lo inmediato - sin ser alcanzados, etc. etc.

Cualquier "cosa" que le suceda a un servicio (en un servidor virtual), a nivel de software y hasta el nivel del mismo sistema operativo que lo está corriendo, continúa sin afectar los otros dos servicios, que si son independientes del servicio afectado, van a continuar operando normalmente mientras la capa de virtualización funcione normalmente.

Consolidar y desagregar servicios en servidores, pero en un contexto pertinente

Como ven "consolidar" es una noción, no "prehistórica" ni poco útil en la actualidad, sino perfectamente útil y pertinente en un contexto específico: infraestructuras de servidores físicos.

Los beneficios de la desagregación de servicios en varios servidores virtuales - en entornos virtualizados - inclusive suponen, como estrategia de gestión de recursos de infraestructura, un número mucho más elevado de ventajas respecto de lo que se obtiene "consolidando" al trabajar con servidores físicos. 

Además de simples ventajas prácticas (el mencionado incremento de resiliencia de servicios gracias a que cada uno corre en sistemas operativos diferentes, por ej.), hay diferentes posibilidades exclusivamente disponibles en entornos virtualizados se hacen disponibles a los administradores al desagregar servicios .La migración live de máquinas virtuales sería casi lo más útil:

http://en.wikipedia.org/wiki/Live_migration

http://www.vmware.com/products/datacenter-virtualization/vsphere/vmotion.html
http://blogs.citrix.com/2012/08/24/storage_xenmotion/
http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html

Subutilizando recursos con infraestructura virtual, un ejemplo

Al contrario, cuando se tiene servidores "consolidados" en entornos virtuales, nos encontramos con grandes consumidores de recursos, que tienden a replicar la misma situación de sub-utilización o poco óptima utilización de recursos que había previo a la virtualización, pero agregando en el medio una capa de hipervisores.

Por ejemplo, sin virtualización, en un servidor físico dado, se corría un Linux con 3 servicios críticos, ahora, con un hipervisor corriendo sobre el servidor físico, se tiene de vuelta un Linux con los mismos 3 servicios críticos, y al ocupar estos tantos recursos, no dejan "lugar" para incluir más servidores virtuales en el mismo hipervidor.

Puede ocurrir que uno de esos servicios críticos se use a la mañana, otro a la tarde y un tercer servicio es de backup y está funcionando toda la noche, entonces en ningun momento del día se tiene realmente libres los recursos físicos disponibles, si hubiera mínimas cantidades libres de alguno, la criticidad del uso del servicio activo al momento o que otros recursos estén siendo ocupados al máximo al momento (mucho procesamiento/ram a la mañana en una base de datos, mucho storage por la tarde en el volcado a disco de datos, y mucha conectividad a la noche cuando se hacen los backups).

Desagregando los 3 servicios en 3 servidores virtuales, podríamos encontrar que a la tarde, en un hipervisor diferente de donde corren los 3 servidores virtuales, hay suficiente "tranquilidad" como para que el servicio que es intensivo en storage corra, así que lo podríamos mover allí, de ese modo la tarde queda libre para poder correr diagnósticos sobre el servidor virtual que se encarga del backup a la noche, y cuando llegue el momento de hacer backups, tenemos de ante-mano cierto stock de pre-diagnósticos del sistema, y si hay alguna falla inclusive podríamos tener un pre-aviso antes de que ocurra la falla.

Si hubiéramos tenido los el servicio intensivo en storage a la tarde y el de backup intensivo a la noche, consolidados en un mismo server, esa situación de prevención de errores tal vez no hubiera sido posible de alcanzar por falta de recursos (no se podía "molestar" al server a la tarde mientras estaba ocupado en otra cosa).