© Josep Ros. Con la tecnología de Blogger.

Consulta Técnica: vmware converter y backup en caliente

Mi colega Barrujas me realiza una consulta un tanto extensa y con cierta complejidad que voy respondiendo por partes:

Hola, ante todo felicitarte por tu blog el cual leo so cuando puedo que no cuando quiero, pero en fin creo que como todos los que pertenecemos a este mundo, siempre deseamos que el día tenga mas horas.

Me gustaría hacerte varias preguntas. Soy Administrador de un dominio con bastantes clientes (unos 800) y desde hace cuatro años también me introduje en el mundo de la vitalización desde el Workstation 3 y sucesivos. “No han dejado de sorprenderme estos chicos de vmware ”.

Tienes el cielo ganado. Imagino que al principio no te lo pusieron nada fácil...

Pues bien convencí a mi gente en aquellos años de que el mundo giraría hacia la vitalización tal y como ahora sucede, el caso es que comenzamos con 4 licencias de gsx 3.0 y 4 servidores supermicro opteron a 2000mhz doble core. Todo nos ha ido de maravilla durante este tiempo pudiendo pasar las aplicaciones a ts virtualizadas con Windows 2000 y posteriormente con windows2003.

Este entorno de partida con GSX o Server me parece correcto. Sólo comentar que se complementaría genial con una cabina iSCSI o similar y que conviene insistir en que es importante que la controladora de disco tenga caché de escritura a tutiplén (ideal 512Mb) con batería. (perdón por decir siempre lo mismo...).

Sin embargo, el problema siempre ha sido el mismo, cuando convierto una maquina gsx a vmware 1.x parece ir todo bien pero a levantarla en el nuevo server parece haber migrado solo una parte dejando de lado los últimos ficheros escritos, es como si solo remontara desde el ultimo snapshot creado, a pesar de que en ocasiones lo hubiéramos borrado con anterioridad.

Hemos investigado al respecto y parece ser que el método que utilizábamos de copiar la carpeta de un server existente y cambiarle el nombre creando un nuevo id y posteriormente hacerle un sysprep no era un método muy fiable llegando incluso en ocasiones a confundir los snapshot anteriores. Por este motivo comenzamos a hacer backup de los propios ficheros con ntbackup y otros similares incluso ghost y acronis, pero cuando lo reviertes a la nueva máquina virtual creada todo va más lento incluso aumenta el rendimiento del procesador del host. Además en ocasiones las maquinas migradas estaban en un sistema buslogic y al convertirlas vmware advertía de que serian pasada como scsi lsi.

Bueno, hemos utilizado el converter hasta el 3.01 y tampoco lo resuelve, los ficheros vmem y lock es como si los omitiera.

No se si esto te ha ocurrido alguna vez o si hay alguien que conozca este problema y alguna solución.

No sé si por suerte o por desgracia pero me han pasado estos problemas que comentas y unos cuantos más en temas de conversión a VM. Te cuento qué solución he empleado para no tener estos problemas.

En primer lugar, para que no se produzca ninguna operación destructiva, apago la VM en producción y hago una copia, con la que trabajaré. Entiendo que esto en ocasiones es tiempo y problemas por falta de espacio, pero convendría hacerse con un disco USB o Ethernet de 500Gb o 1TB para poder trabajar con holgura y que no nos dé pereza hacer copias.

Una vez que tenemos la VM copiada, la inventariamos en el mismo o en otro Host y eliminamos todas las snapshots, ya sabes, la opción Remove que sólo está disponible con la VM apagada ¿cierto? Esto nos deja un escenario de trabajo más 'limpio' con sólo un archivo VMDK por cada disco de la VM.

A partir de ahí y siempre con la VM apagada tendremos que clonarla como ahora te comentaré. Permíteme comentarte que a mí siempre me ha funcionado más rápidamente la conversión con VM apagadas y ahorro problemas adicionales de muy diferente índole tales como problemas con el Token del Directorio Activo, archivos que se han modificado tras la conversión, etc, etc.

Ahora es el momento de hacer la 'foto' del sistema. Para ello se puede utilizar el VMware Converter. Esto no debería ser ningún obstáculo, ya que partimos de una VM de GSX. Sin embargo si esto no te funciona puedes utilizar una herramienta de imagen como Acronis True Image o Symantec Backup Exec System Recovery 7.0 (Ghost ya sólo es para clientes 2000, XP y Vista). Tanto si haces una imagen con True Image (en frío o caliente) que te dará como resultado uno o más archivos TIB (uno por cada VMDK), como si utilizas el BESR que te dará un archivo V2i por cada VMDK, el resultado será que tienes una imagen de tu VM.

Ahora puedes emplear dos métodos:

1. Utilizar el Converter para hacer un proceso i2V, es decir, origen de la conversión un archivo de imagen, y destino una VM de VMware Server. Esto te debería respetar tanto el SID del equipo (importantísimo en Directorio Activo), como las firmas de disco. Te permite también realizar un cambio en el tamaño de los discos lo que se agradece. Muy importante que al finalizar este proceso exitosamente le pongas las VMware Tools actualizadas (te recomiendo desinstalar primero las del GSX).

2. La opción que siempre te funcionará. Haz una imagen de la VM origen (con o sin snapshots, no importa) con el Backup Exec System Recovery 7. El producto debe estar licenciado, no sirve la demo. Una vez que tienes el archivo o los archivos V2i creas una VM con VMware Server. Esta VM, por supuesto, tendrá su/s propio/s disco/s y elementos que consideres adecuados. Puede tener más RAM y más procesadores o menos que la original. Arrancas la VM con el Symantec Recovery Disk del BESR 7 y procedes a restaurar la imagen (ojo, debes tener acceso a ella desde la VM), en un momento determinado te pedirá si quieres utilizar Restore Anywhere (maravilla de las maravillas...). Le dices que yes. Esto hará que al levantar la VM te limpie la capa HAL, pero te respete tanto SID como firmas de disco. Verás que al iniciar por primera vez la VM tarda lo suyo (paciencia) y que tendrás que reiniciarla para que te coja bien toda la capa hardware. Una vez finalizado este proceso le instalas las VMware Tools y a funcionar. Este método me gusta mucho, porque es también no destructivo.

También aprovecho para preguntar si sabes de algún software para wmware server capaz de copiar las maquinas virtuales en caliente y pasarlas tal cual a una unidad de red conectada del host. La idea hasta ahora es mantener los cuatro servidores con una partición de arranque C: y otra D: donde están todas las maquinas virtuales aunque ese host o server, solo tenga activas un número determinado de ellas. De esta manera en caso de que el host caiga, siempre podría levantarlas (guardando el id) en otro servidor o repartirlas por los restantes.

Lo hemos intentado montando dfs pero las replicas solo son funcionales si apagas las maquinas que tienes en ejecución y esperas a que se realice la replicación, generalmente de noche claro, incluso diseñamos script que realizaran esta labor parando copiando y levantando a una determinada hora, valido pero engorroso.

Por supuesto ya sé que todo esto con vmotion es más sencillo pero como ya debes tener claro nos encanta probar cosas y complicarnos la vida.

La pregunta es, ¿conoces algún sistema de replicación de virtuales en caliente que facilite todo esto?. Recientemente he probado el vconverter que clona y convierte las maquinas en caliente pero solo la parte del disco duro virtual, con lo que posteriormente hay que crear nueva máquina y añadirle el disco y claro eso conlleva a cambio de id y a que el AD no te deje pasar y tengas que volver a meterlo en el dominio.

Verás, creo que debemos diferenciar claramente un software de replicación de uno de backup. Si hablamos de Double-Take, este software (muy caro) nos permite tener replicada una carpeta con VM en otro servidor en tiempo real. Esto está muy bien pero no nos permite, por ejemplo, recuperar una VM al escenario como estaba ayer. Imaginemos que la VM ha sido sometida a un proceso de instalación nocivo (como lo que está haciendo la Magdalena Álvarez con los pobres desgraciados que utilizamos los trenes por estas lares) que ha producido una pantalla azúl. El Double-Take habrá replicado exactamente el error, con lo que mi gozo en un pozo, estoy doblemente jodido o doblemente penetrado (como indica literalmente el nombre del producto). Esto no es ninguna crítica respecto a productos como Double-Take (al que sólo le encuentro un precio muy elevado) sino una cuestión meramente descriptiva.

Por otra parte tenemos los productos de backup clásicos como el 'veritas' (Symantec Backup Exec for Windows Servers) o CA BrightStor ARCServe, Legato, etc. Con estos productos puedes seguir haciendo backup desde la red, de las VM como si fuesen equipos físicos. Esta práctica está muy extendida y no supone ningún añadido a lo que se suele tener en un escenario de trabajo clásico. Además pues hay compatibilidad con cinta, etc.

Yo me decanto por otra solución: El backup por software de imagen. A nuevas tecnologías (virtualización) nuevas soluciones de copia de seguridad. Eso es lo que yo leo entre líneas de toda esta revolución que nos está suponiendo la virtualización.

Trato de explicarme un poco más. Imaginemos un escenario de diferentes servidores físicos con su unidad del sistema C: de, pongamos 20GB y su unidad de 'datos' que contiene las VM, pongamos V: de 72, 100, 300, 500GB, etc. Por otra parte tenemos dispositivos Ethernet con gran espacio de almacenamiento. Por ejemplo los discos de LaCie de 1, 2 o 4TB. Creo que el de 1TB sale por 600 o 700€ PVP (perdona pero soy un desastre para los precios). En ese escenario en el que hay suficiente espacio de disco en la red al que puedo acceder como \\naslacie\copiaVM ya tengo todo listo para programa las copias.

Ahora sólo hace falta instalar el Symantec Backup Exec System Recovery 7.0 en los servidores físicos y programar una copia mensual (por ejemplo) de la C: Con esto ya tenemos solucionado el problema de volver a instalar el sistema operativo físico, su antivirus, su propio sistema BESR, con su programación y demás. Y ahora vamos al turrón: programar las copias de las VM. Podemos hacer una copia diaria por la noche de lunes a sábado (dependiendo del escenario) que se vuelque en la red. Te recomiendo que dividas las imágenes en archivos de 1 GB porque te irá más rápido y el entendimiento entre BESR y el dispositivo de red será mejor que si lanzas un 'churro' de muchos GB en un sólo archivo.

Este software permite que hagas scripts pre y post. VMware dice que sólo se va a poder recuperar con 100% de éxito una VM que haya sido pausada o detenida antes de la copia. Efectivamente no voy yo a llevar la contraria a los muchachos de VMware y eso sería lo ideal. Sin embargo hay escenarios en los que no se puede parar nunca. Hace poco mi colega Gura me comentaba esta problemática en un escenario de un cliente suyo. Bien, si no se puede parar nunca, bien que tendremos que hacer copia ¿no?. De muertos al río, hacemos imagen del escenario en el momento en que exista menos carga de trabajo. Si se trata de un servicio de urgencias de un hospital, a las 4 de la mañana habrá una gran actividad de ronquidos de los médicos, enfermeras y recepcionistas, por lo que podremos programarla sin que eso suponga ninguna debacle para el entorno.

Mi experiencia (ya larga) haciendo imágenes en caliente sin pre ni post de VM con estos dos programas Backup Exec System Recovery 7.0 y VMware Server 1.x (también va bien con 2.x) es excelente. Jamás tuve nigún problema para levantar una VM ni pérdida de datos crítica (lógicamente si se trata de un SQL o un Exchange puede haberse perdido algún registro o mensaje, pero no la integridad de los almacenes o BD). El pobre Windows se quejará y dirá ¿qué me ha pasado? le dices que nada, que siga a lo suyo y fiesta. Por supuesto, pruébalo y convéncete por ti mismo, porque entiendo que esto te puede sonar a música celestial o a canto de sirenas. Ya me explicarás qué tal tu experiencia si lo pruebas, seguro que será excelente.

Mi recomendación para que esto vaya de perlas es que tengas, a ser posible, un entorno de LAN un poco aislado para backup. Esto es tan sencillo como añadir una tarjeta de red adicional (a GB) a tus servidores físicos y poner un pequeño switch con puertos suficientes a GB para recepcionar una tarjeta de red por servidor y los dispositivos de copia de red. Si por ejemplo tenemos 10 servidores físicos y 2 dispositivos de copia en red necesitaremos un switch de 12 puertos. También mi recomendación es que pongas IP de un rango distinto, si tienes 192.168.1.x, pues le pones a este escenario de backup una IP 10 o similar. Así no castigas la red mientras haces el backup.

Sólo un par de cosas más. Este escenario de copia D2D (disco a disco) yo lo complementaría con una copia definitiva a un segundo escenario ya sea de disco (D2D) o de cinta (D2T) lo que te permitirá extraer el dispositivo con la copia cifrada y protegida a una dependencia externa.

En escenarios ESX hay otras herramientas como VCB que permiten hacer otras virguerías. Todo lo que aquí he comentado se refiere a este escenario que los pobres utilizamos tanto, el VMware Server, que, a mi entender, es una magnífica opción para virtualizar en producción sin que nos cueste un ojo de la cara.

Siento haberme extendido demasiado pero no estoy acostumbrado a escribir mucho en internet, y menos a creerme cosas que escriben otros, en muchas ocasiones auténticas bestialidades. Gracias a Dios no es tu caso.

Un saludo y mi agradecimiento personal por tu contribución al mundo virtual y en hora buena de nuevo por tu blog.

Barrujas.

Gracias por todos los comentarios que realizas sobre mi tarea en el blog. Espero poderos continuar ayudando mucho tiempo :-)

Saludos cordiales y espero que me cuentes qué tal te ha ido.

Josep

3 comentarios:

Jesús Díez dijo...

Magnífico post Josep, muchas gracias, me has sacado de varias dudas. Desde ahora seguiré asiduamente tu Blog.

pepeasecas dijo...

¡EXCELENTE, PRÁCTICO, DIRECTO, EXQUISITO!

Me tatúo en las neuronas:
"Controladora de disco tenga caché de escritura a tutiplén (ideal 512Mb)con batería."

Pepe (Sevilla)

enrique@delacalle.net dijo...

Gracias Josep, realmente clarificatorio

Solo una advertencia en los procesos de clonado que me ha ocurrido hoy mismo (por eso me animo a escribir )

Si Copias una imagen para levantar otra instancia , si has hecho un Linux Debian ( a mi me ha pasado con la dist. etch ) , el interface de red no se levanta porque espera que sea la misma MAC.

La solucion consiste en borrar un fichero que esta en el /etc/udev/xxxxx-net.d

esto que parece facil , desmonta todo lo referente a clonados en caliente ..etc.. etc...

Un Saludo

Enrique de la Calle

Consulta Técnica

[Consulta Técnica][bleft]

Virtualización

[Virtualización][twocolumns]

Naturaleza

[Naturaleza][grids]