Pese a que se que mi e-amigo “J.L” me dirá que hacía esto en VMWare desde el principio de los tiempos 😉 os voy a contar una cosa que me gusta mucho del System Center Virtual Machine Manager.
En una infraestructura moderna, lo normal será que los servidores de maquinas virtuales orientados a la consolidación, estén conectados a redes de almacenamiento SAN, ya sea por I-SCSI o por Fibra con sus correspondientes HBAs.
Si este es el caso y los servidores son Windows 2003 R2 y nuestro hardware dispone de un driver VDS como por ejemplo pasa con las de HP (MSA 1000, 1500 y EVAS 3K,4K,5K,6K y algunas XP) http://h18006.www1.hp.com/products/storageworks/vdsvsshard/index.html, entonces podremos usar VMM para traspasar las maquinas virtuales de unas maquinas a otras en cuestión de pocos segundos.
Dado que con el VDS, el sistema operativo es capaz de controlar la asignación de LUNs a las maquinas conectadas a la SAN, VMM cambiara la asignación del LUN del disco duro lógico en el que este la maquina virtual para que el servidor origen deje de ver el disco y el servidor destino lo pueda ver y voila!!!! Ya tendremos nuestra maquina virtual cambiada de servidor y en segundos.
VMM tiene un soporte fantástico para automatización tanto a través de los scripts típicos como del potentísimo PowerShell, lo cual hace muy fácil hacer un script que tome como parámetro la maquina virtual y el servidor destino y se encargue automáticamente de pausar la maquina, moverla y re arrancarla.
En el sitio de connect para la beta 2 de VMM tenéis un documento específico sobre los requisitos y funcionamiento de esta estupenda feature aqui teneis el link https://connect.microsoft.com/vmm/Downloads/DownloadDetails.aspx?DownloadID=6238 .
Interesante la forma de comprender como se mueven máquinas virtuales practicamente «en caliente». Un día un alumno mio había ido a una charla de VMWare donde les presentaban el ESX 3.0 si no recuerdo mal. Me comentaba que les habían enseñado una demo donde se utilizaba un cluster ESX activo-pasivo donde un nodo se «caía» (Así me lo dijo), y la máquina guest la virtualizaba el otro ESX del cluster. Al parecer no se perdía ni un «ping».
Pues bien ¿Hasta qué punto es esto real? Si la máquina se cae de verdad, no le da tiempo al sistema a pausar el guest y ordenar a la SAN ,que al nodo que aún sigue vivo, le asigne otro LUN (Si lo he entendido bien)? ¿O si le da tiempo? Me corroe saber como funciona…
De estos piques de buen rollito (espero) que tenéis se aprende mucho… se aprende mucho tanto de J.L Medina como de ti DMatey. Unos máquinas los dos.
Le asigna el mismo LUN, pero lo has entendido bien.
En realidad el tiempo que tarda en transferirse la maquina depende de la cantidad de memoria ram que tenga la maquina virtual, si quieres mover una maquina con 8gb de Ram y los 8 estan siendo usados, hay que esperar a que se escriban al disco duro en la SAN, ese proceso puede tardar dependiendo de la capacidad de IO de la SAN y lo ocupado que esten los Fabric, a si que en un entorno real y de producción, lo de que no se pierda ni un ping, pues no me lo creo.
Pero rapido es rapido, con VS tambien se pueden montar clusters pero hay que analizar bien si son necesarios o no, algun dia pondre un post sobre el tema.
Me voy que me gruñen.
Vamos a ver… en la actual versión, en 3.0.1, si utilizas HA y cae un nodo, la VM se levanta en el otro, es decir, se hace un power on, así que de no perder ni un ping, nada… los pierdes todos hasta que la máquina arranca de nuevo. Otra cosa es el movimiento en caliente, donde efectivamente no pierdes ni un ping, ya que el host origen no «desconecta» la VM hasta que el destino no la ha asumido. Básicamente utiliza el enlace vMotion para transferir los datos de la memoria del host destino.
La sutil diferencia entre lo que explica Daniel y VMware es que en VMware TODAS las máquinas que están conectadas a un almacenamiento SAN ven y acceden a la LUN en simultáneo. En un entorno Virtual Server no es así: NTFS no es un FS concurrente y necesita «bloquear» la LUN. Traducido al entorno de virtualización, en Virtual Server has de asignar una LUN por VM si quieres clusterizarlas. Otro tema a tener en cuenta es el funcionamiento de MSCS. Cuando haces un movimiento de recursos entre nodos, MSCS primero desconecta el recurso y después lo levanta en el otro nodo, lo que significa que en caso de movimiento, la máquina virtual no está dando servicio. Esto, y dicho sea en descargo de Virtual Server, no es un problema de la plataforma de virtualización, sino la operativa del Cluster de Microsoft. De hecho, para hacer un cluster Activo/Activo (donde TODOS los nodos operan a la vez) en Oracle 9i, Oracle utiliza Raw partitions para almacenar los datos (particiones que no vé Windows Server)
Daniel:´Créeme, no se pierde ni una sola conexión en un terminal server, ni en SQL, ni siquiera ves un salto en Windows media reproduciendo una película en una máquina virtual cuando la mueves de un host a otro. Estás cordialmente invitado a verlo cuando quieras.
Y puestos a filtrar sin saltarme los NDA, versiones siguientes de ESX soportarán el Activo/Activo, es decir, que una máquina virtual se esté ejecutando a la vez en dos host, recibiendo las mismas conexiones y carga de trabajo, pero sólo una interacciona con el entorno, así que en caso de caída de un host, la VM sobrevivirá sin perder ni un ping, al igual que en un mirror de disco el OS no se entera de que ha fallado el principal y que ahora es el secundario el que responde a sus peticiones. Incluso no pasará mucho tiempo hasta que veáis cosas realmente impresionantes en ESX… Y hasta quí puedo leer…
Respecto a SCVMM. Lo monté en mi lab… Muy buena pinta. Ya les tiré la punta a mis infiltrados en VMware… lástima que los host deban correr Windows Server R2. Aunque la documentación dice que es posible gestionar Windows 2003, por mucho que lo intenté, no conseguí que lo viera. Si, tengo Virtual Server también en mi lab. Pero si, buena pinta tiene, si señor. Y puestos a puntear a Mr. Matey, Virtual Center admite sin problemas cualquier versión de ESX a la primera… 😉 (¿Creías que ibas a escaparte de esta, Dani?)
YA en serio. No veo un futuro con un sólo hypervisor. Habrá varios, de múltiples capacidades, pero que podrán hablar entre si. VMI es una gran oportunidad para todos los fabricantes. Sólo depende de que todos quieran usarlo.
Un cordial saludo.
J. L. Medina.
PD: ¿Buen rollito? Sin compasión. Al enemigo ni agua… sólo cerveza.
Buenas explicaciones 🙂
Cierto es que yo hablaba de clusters VS.
VMotion es la leche.