En el año 2003 se libera la primera versión de la tecnología vMotion junto al vCenter 1.0 y la versión 2.0 del ESX.
En este artículo, la definición, su conceptualización a alto nivel y algunas aclaraciones personales como valor agregado para entender mejor esta revolucionaria tecnología.
¿Qué es vMotion?
VMware vSphere vMotion es la tecnología que permite migrar en vivo una máquina virtual (vm) y sin tiempo de inactividad de las cargas de trabajo de un servidor a otro servidor.
¿Se pudiese decir que el vMotion migra de un servidor físico a otro servidor físico?
Aunque es lo más común, es muy interesante que no está limitado a servidores físicos, ya que podríamos hacer vMotion entre un host ESXi virtual anidado dentro de un host ESXi físico o entre dos hosts ESXi virtuales. Esa es la posibilidad por la cual VMware lo define de esta forma. (enlace de la definición oficial al final del artículo)
Tiempo de inactividad:
El tiempo de inactividad es el tiempo en que las aplicaciones de negocios, su servicio u otra clasificación se hacen indisponibles o inactivas para sus clientes o usuarios, lo que suele causar molestias e inconformidades, pérdida de dinero, pérdida de credibilidad o incumplimientos de OLA, SLA u otros acuerdos.
Clasificación de los tiempos de inactividad:
Programados: Estos tiempos de inactividad son planificados, informados, consensuados y aprobados por ambas partes.
No programados: Estos pueden suceder por fallas en el sistema operativo donde recide la aplicación, también puede ser de la infraestructura, red, almacenamiento, por fallas en el hardware donde reside la vm, mala configuración o por fallas del mismo aplicativo.
Cuando se ejecuta vMotion entre dos hosts, se asegura la disponibilidad del aplicativo o servicio que corre en las vm´s, aunque la ejecución de movimiento entre hosts no excluye que puedan suceder indisponibilidades fuera del proceso o el control del vMotion.
Ejemplo: Si un administrador dispara un vMotion de vm-01 donde corre la contabilidad, de un host A a un host B y al llegar la vm-01 al host B, se va la luz en el rack donde está el host B, apagando todas las vm´s que la contienen, incluyendo la vm-01, la aplicación de contabilidad que corre en la vm-01 está indisponible para los usuarios hasta que se resuelva el incidente, dicha indisponibilidad no se debió al vMotion.
Importante: Al igual que todo sistema, la ejecuación del vMotion depende de que otros sistemas y sub-sistemas dependientes funcionen y estén configurados de manera adecuada.
Hago la aclaratoria ya que he sabido de demostraciones y presentaciones de determinada tecnología que han fallado en plena demostración, normalmente el presentador se pone nervioso, pero cuando se sabe que un sistema depende de muchas variables u otros sistema para operar correctamente, usará este argumento para razonar que el problema no necesariamente es la tecnología que está presentando, que cabe la posibilidad de que sea otro sistema del cuál depende.
Lo anterior también me permite abordar el tema de la complejidad, ya que no es lo mismo hacer un vMotion entre dos host que están en un mismo rack que hacer vMotion entre dos hosts que están en racks diferentes, centros de datos diferentes, ciudades o países diferente o del on-premise a la nube, etc.
Mientras más complejo es el traslado o movimiento entre hosts, los sistemas o configuraciones dependientes para que el vMotion se ejecuten correctamente deben estar funcionando de manera óptima y estable.
Esto podría sonarte como lógico y de sentido común, pero cuando una empresa o persona adquiere una tecnología con expectativas, quizás por la publicidad o por el pre-venta y dicha expectativas no se cumplen del todo, lo primero que hacen es echarle la culpa a la tecnología y no a la implementación, al diseño, a la configuración u otro factor.
Ejemplo: Compran o migran a VMware para darle más estabilidad, agilidad y escalabilidad al centro de datos, pero cuando el departamento de monitoreo informa que hay más fallas en la disponibilidad de las aplicaciones ahora que antes, pudiesen decir que perdieron el dinero con VMware, cuando la realidad y la causa pudiese ser un montón de variables externas a VMware.
Características de la migración con vMotion:
La vm que migra de un host a otro conserva su su identidad completa, incluye su dirección ip, su dirección mac, lo que estaba ejecutando tanto en memoria como en la cpu, las conexiones que tenían hacia la vm, bien sea al sistema operativo vía ssh o rdp por ejemplo, también las conexiones que tienen los usuarios a las aplicaciones, todo.
Alcance y velocidad:
Como hemos dicho antes, el movimiento en caliente o en vivo entre dos hosts de una vm puede hacerse a muchos niveles, desde dos hosts en un mismo rack hasta dos hosts en países geográficamente muy distantes entre sí.
Con respecto a la velocidad de movimiento, y aquí volvemos a las variables dependientes, dependerá del ancho de banda de la red, ya que no será lo mismo que los hosts estén conectados a 10 Gbps, que a 100 gbps o más. Dependerá de la estabilidad de medio de conexión, la configuración, el tamaño de la vm a mover en cuanto a memoria y cpu virtual entre otras.
En este punto, lo importante es saber que la tecnología de vMotion puede hacer movimientos con un gran alcance y a una velocidad lo suficientemente rápido como para que los usuarios de la aplicación no perciban el movimiento, y eso es muy poderoso.
Automatización de migraciones.
Estos procesos de migración en vivo o en caliente con vMotion pueden ejecutarse manualmente o programarlos para una determinada hora y fecha por el administrador, de esta forma las migraciones amplían su rango de acción y poder.
Aplicaciones prácticas.
Al incorporar la tecnología de vMotion a la solución de virtualización VMware en 2003, se abrieron muchas oportunidades de crear otras tecnologías de más alto nivel cuya base principal es el vMotion.
Algunos ejemplos:
1. Ahora se podía hacer mantenimiento del hardware físico sin afectar los servicios o aplicaciones que se ejecutaban en las vm´s de ese host al moverlas a otro host.
2. Si la suma de los consumos computacionales de las vm´s en un host en particular ponía en riesgo el host, por ejemplo, por llegar a estar consumiendo el 99% de la memoria RAM, se podía desahogar el host moviendo algunas vm´s a otro host con vMotion.
3. Si se está haciendo una migración o actualización de hardware que soportan los hipervisores, digamos de HP a CISCO (es solo un ejemplo), es posible usar vMotion para hacer la migración al nuevo hardware sin tiempo de inactividad para los usuarios.
4.Si luego de la jornada laboral de los usuarios, el consumo de las aplicaciones que corren en las vm´s baja de forma que pueden distribuirse a menor cantidad de hosts, el departamento de TI pudiera mover con vMotion las vm´s a pocos hosts y apagar unos cuantos para ahorrar electricidad, y al amanecer, volverlos a encender y distribuirlos como antes para recibir de nuevo la carga de los usuarios.
5. El último ejemplo para que puedan palpar el poder de esta tecnología, imagine que una empresa multinacional ha decidido migrar algunas de sus procesos administrativos, contabilidad, recursos humanos entre otros a otro país, crearán un centro de datos y con vMotion, podrían migrar las vm´s que soportan las aplicaciones que serán redistribuidas al nuevo centro de datos.
Fuente primaria de la información:
