E pur si muove......

La migración de máquinas virtuales entre host siempre ha sido un tema controvertido. Entre los defensores a ultranza de Live Migration (movimiento sin parada/suspensión) hasta los que aseguran que Quick Migration (movimiento previa suspensión y con periodo corto de pérdida de servicio) es más que suficiente, hay opiniones para todos los gustos.

La mía, como siempre, es "depende". Quiero decir que, aparte del aspecto tecnológico que no puedo negar que resulta impresionante, existen otros tipos de consideraciones. Teniéndolas en cuenta todas, mi opinión es, sin duda, Live Migration gratis. Como por desgracia eso por el momento no es posible, me veo obligado a detallar más mi postura.

Yo me acuso de usar vMotion (Live Migration según VMware) en producción. Y he mantenido entornos de producción con una o dos migraciones diarias hasta el otro extremo de 19 (sí, digo bien, diecinueve y hay testigos) por minuto en entornos DRS (Distributed Resource Scheduler). Y duela a quien le duela, funciona. En las pocas ocasiones en que la he visto fallar en algún que otro cliente, siempre ha sido un problema asociado a la configuración de red, a la del almacenamiento o a la del ESX. Nadie está libre de que su tecnología falle por razones del entorno.

Sin embargo hay razones que desacosenjan y hasta impiden la implementación de vMotion. Entre las técnicas, las compatibilidades entre procesadores, que no siempre son subsanables mediante masking de registros (véase el caso de SSE4) o EVC (Enhanced vMotion Compatibility -no sé si existe algo similar en el mercado para el resto de los hipervisores), y por otro lado, la sempiterna economía: vMotion implica un coste, tanto del producto como del soporte posterior.

En un entorno de producción, la existencia o no de Live Migration puede ser la diferencia entre tener que hacer una solicitud de cambio (change request), pasar un comité de probación y planificar una parada en el caso de no disponer de ella, a no tener que pasar por ese necesario calvario, ya que, en realidad, el servicio no se interrumpe. Y conozco muchas políticas de cambio donde un vMotion no implica una solicitud/aprobación ya que el servicio no se interrumpe. Evidentemente, en un entorno de desarrollo o preproducción, la necesidad de Live Migration se ve claramente disminuida, en especial si acarrea coste. Incluso algunos servicios de producción pueden "evitar" el uso de Live Migration simplemente duplicando servidores y asegurándonos que no se ejecutan todos en la misma máquina... hablo de Domain controllers, granjas web, etc.

Sin embargo, para servicios de producción como Bases de datos, servidores de correo, que no son fácil o económicamente redundables, Live Migration se convierte, en datacenters altamente virtualizados, en un requerimiento fundamental para evitar paradas de mantenimiento de los hosts o el almacenamiento, o de factores infraestructurales como el suministro eléctrico, obras o modificaciones del datacenter, etc. Los downtimes más o menos programados... o los temidos Zeros (apagado eléctrico del datacenter), pasan de ser situaciones que requieren de una cuidadosa programación a una serie de operaciones absolutamente normales.... o dicho de otra manera, de una frenética carrera de apagado del site principal y encendido del de respaldo en unas cuantas horas, a unas cuantas operaciones programadas con semanas de antelación (podemos ir moviendo las máquinas con dias o semanas sin necesidad de esperar al día del apagado) sin impacto apreciable en la operación.

A muchos de los que estáis leyendo este post, su contenido no debe suponer una sorpresa: Ya estáis más que hartos de hacer vMotion (aka VMware Live Migration) sin un sólo problema. A los que no, os animo a "vivir" la experiencia de vMotion. A los que siguen diciendo que vMotion sólo funciona en los vídeos, deciros lo mismo que se atribuye a Galileo Galilei...

... Y sin embargo, se mueven!!!