Live Migration Versus Quick Migration
En la medida en que se va conociendo mas acerca de Windows Server Virtualization es natural que aparezcan dudas acerca de sus caracteristicas.
Una de las mas famosas es Live/Quick Migration.
Por lo tanto voy a dedicar un ratito a clarificar todo cuanto pueda acerca de este punto.
Primera aclaracion, Quick y Live Migration no es lo mismo. No son sinonimos ni terminos intercambiables. Una cosa es Quick Migration y otra muy distinta es Live Migration.
RTM de WSV va a tener listo Quick Migration mientras que Live Migration estara listo en una actualizacion unos meses despues del RTM de WSV.
Si bien ambas sirven para "mover" una VM de un host a otro, ambos lo hacen de forma y en tiempos diferentes.
Live Migration logra instanciar una VM en otro Host en menos de un segundo mientras que Quick Migration necesita un tiempo que varia dependiendo de la cantidad de RAM de la VM y de la velocidad de la conexion al storage.
Hecha la aclaracion, vamos a desgranar cada una de ellas.
Quick Migration
Trabaja basicamente en tres pasos
- La maquina es puesta en "Saved" state.
- La VM es tomada por el otro host
- La VM es restaurada.
La velocidad de Quick Migration no depende del tamaño de la VM (tamaño del VHD) en si ya que esta nunca es copiada o movida.
La siguiente tabla muestra en promedio el tiempo que toma Quick Migration en "mover" una VM
VM Memory 1 GbE iSCSI 2 Gb FC 4 Gb FC
512 MB ~8 seconds ~ 4 seconds ~2 seconds
1 GB ~16 seconds ~8 second ~ 4 seconds
2 GB ~32 seconds ~16 seconds ~8 seconds
4 GB ~64 seconds ~32 seconds ~16 seconds
8 GB ~2 minutes ~64 seconds ~32 seconds
Los requerimientos para Quick Migration son los siguientes:
1. Windows Server 2008 Enterprise or Datacenter x64 Editions in the parent partition. EL Host debe correr Windows Server 2008 Enterprise or Datacenter x64 Edition por que Quick Migration requiere Windows Server Cluster que esta solamente disponible en Windows Server 2008 Enterprise y Datacenter.
2. Shared Storage. Para que Quick Migration mueva una VM de un server a otro se requiere un shared storage como ser SAN (iSCSI o Fiber Channel) o NAS. Atencion que Windows Server 2008 no soporta mas clusters con SCSI paralelo.
Live Migration Basico.
Los requerimientos para Live Migration son similares a los de Quick Migration
A grandes rasgos Live Migration podria describirse asi:
1. Migration Preflight. ¿Puede ocurrir la migracion de manera segura y confiable?
a. Si la migracion puede ocurrir, se hace.
b. Si se detecta algun riesgo o imposibilidad, esta no se permite.
2. VM Transfer.
a. Copia la configuracion de la VM y crea el worker process en el otro host.
b. Mueve las paginas de memoria desde el Host actual al nuevo, Primero mueve todas las paginas inactivas que pueda para reducir el conjunto de paginas tanto como sea posible.
3. Transferencia Final y encendido de la VM. Idealmente en este punto, hay un conjunto de paginas muy chico sosteniendo con vida a la VM ya que casi todas las otras paginas fueron movidas al otro host. Las pocas que quedan estan en estado activo, entonces en este paso final la maquina es pausada y esa mimiVM es movida de un host a otro, luego la VM es encendida. Se mueve la conectividad del storage de un server a otro y listo.
Live Migration en detalle
1. Migration Preflight. El primer paso en Live Migration se hace en el host fuente (donde la VM esta actualmente corriendo) y en el host destino (donde la VM finalmente sera movida)para segurarse que la migracion puede ocurrir.
Los pasos detallados son:
A. Un handshake inicial entre el fuente y el destino
B. Se establece una conexion de red entre ambos hosts
C. Chequeo de varios recursos disponibles:
I. Son los procesadores similares en arquitectura interna? (VM en Intel no pueden moverse a AMD y viceversa)
II. Hay suficiente memoria RAM disponible en el destino?
III. Hay suficiente CPU disponible en el destino?
IV. Hay acceso a los recursos globales requeridos (vhd, network, etc)?
V. Acceso a recursos fisicos para dispositivos que deben seguir asociados a la VM despues de la migracion. O sea que las unidades de CD, DVD y las LUN o Discos Offline necesarios para ser reasociados se encuentren disponibles.
· Cualquier cuestion con lo anterior, el proceso de Migration Preflight falla y la migracion no ocurre. La VM se queda donde esta y sigue ejecutandose como si nada ya que ninguna migracion ha ocurrido.
· Si el Migration Preflight es exitoso la migracion puede ocurrir y se pasa al paso 2.
2. VM Transfer. Ahora que se ha determinado que Live Migration puede ocurrir de manera segura, el proceso de migracion comienza. El objetivo de este paso es mover tanto estado de la VM (paginas inactivas) como sea posible, para reducir la VM activa tanto como se pueda, quedando sin mover un pequeño working set de la VM.
La configuracion de la VM y la informacion de los dispositivos es copiada en el destino, asi como tambien la creacion del worker process. Luego, la memoria de la VM es transferida al destino mientras la VM aun se encuentra corriendo, Los writes a memoria son interceptados y usados para hacer un seguimiento de las acciones que se hacen mientras la VM es migrada. Estas pagina van a ser retransmitidas luego.
3. Transferencia final y encendido de la VM. Ahora que casi todo el proceso ha sido realizado y la mayoria de la VM ya ha sido movida, se completa el proceso de migracion, Lo que queda de la VM es pausada, la vM es entonces transferida al otro host el acceso al storage es movido de un host a otro, y la VM es restaurada en el host destino.
Mientras todo eso ocurre, ¿Que pasa con las aplicaciones que intentan acceder a la VM que esta siendo migrada?
Es importante entender primero porque los administradores IT buscan mover una VM, la gran mayoria necesitan esta caracteristica para realizar mantenimiento preventivo y programado a los hosts. Y ademas estos trabajos se intentan realizar en horas no pico, aun teniendo la caracteristica de Live Migration disponible. Lo que significa que en la mayoria de los casos una diferencia de >1seg a 30seg no es demasiado relevante cuando la migracion se realiza programaticamente.
De todas maneras y enfocados en el punto en cuestion:
Live Migration. Como Live Migration se considera a un proceso de menos de un segundo de duracion, genrealmente este no tiene impacto en el servicio dela VM, TCP/IP puede tolerar minimos cortes, retransmitir y seguir sin que el usuario lo note.
Quick Migration. Aca la respuesta es mas ambigua, "depende". La realidad es que depende de como la aplicacion cliente reintenta y soporta los cortes de conexion, alguna aplicaciones usan cache qeu permiten tolerar algunos segundos de cortes mientras que otras no. Si laaplicacion esta bien diseñada y previó escenarios de tolerancia a fallos, entonces no deberia habler problemas tolerando un corte de hasta 15 segundos de duracion.
Lo ideal es entonces probar las aplicaciones que eventualmente correrian en servidores virtuales con Quick Migration y ver que pasa. Entonces en un server fisico con la aplicacion instalada, ejecutarla, realizar una accion dentro de la misma, en el medio del proceso, desconectar el cable de red, contar hasta 10, reponerlo, y ver que pasa. Lo que pase en esa prueba pasara con Quick Migration