Mi querido amigo Aitor Enzunza me mandó hace unas semanas este impagable correo con una propuesta de backup para ESXi. Gracias crack! eres una pasada de tio, lástima que yo sea tan puñeteramente hetero 🙂
Egunon,
Bujcando, bujcando he dado con este excelente hilo en el que se discute como hacer backups de máquinas en ESXi a través de scripts. Es bastante largo y complicado de leer, pero como yo ahora mismo tengo tiempo con mi pata chula pues me he hecho un intensivo. Me gustaría compartirlo contigo porque me parece interesante y además te va a ahorrar unas cuantas horas de lectura.
http://communities.vmware.com/thread/164134?tstart=0&start=0
El nombre es un poco engañoso porque, aunque inicialmente era para backup de esxi a güinflous, al final degenera en un montón de escenarios posibles.
Te adjunto en un fichero comprimido todos los scripts que ha colgado la gente en ese hilo pero ordenados, explicados y referenciados a los posts en los que aparecen. Hay alguno que no incluyo porque se menciona explicitamente en el foro que han ido quedando obsoletos.
Todos se basan en lo siguiente, para poder hacer backup de las vm estando encendidas (no obstante, con algunos scripts es posible apagar la vm antes de hacer el backup):
1.- Se copia el vmx
2.- Se hace un snapshot de la vm, con lo que se «libera» el disco para poder copiarlo, haciendo que la vm siga corriendo pero guarde los cambios en el snapshot)
3.- De una u otra manera se copian los vmdk
4.- Se deshace el snapshot
(El tema de copiar el vmx antes del snapshot es porque al hacer la instantanea, se cambia la referencia del disco en el vmx, con lo que si copiaramos el vmx despues del snapshot, estaría haciendo referencia a un disco que no vamos a copiar, el del snapshot precisamente. Esto, aunque no es una catastrofe, nos obligaria a editar el vmx antes de restaurar una de esas copias)
En principio son para copiar las vms de un datastore a otro de los que haya configurados en los hosts esxi, pero algunos scripts «se traen» los ficheros a local con scp
Los hay para llamarlos desde güinflous; los hay para llamarlos desde linux; y los hay para llamarlos desde el propio host esxi, lo que a priori parece una mamonada, pero no lo es tanto porque asi podemos hacer uso de los vmkfstools, que por lo visto dan mucho mejor rendimiento al copiar los vmdks. Además el uso de scp (es decir, una copia a través de ssh) desde el propio esxi tiene dos problemas: uno es la evidente sobrecarga tanto de la red como de la cpu en la transferencia de datos por hacerla cifrada y/o comprimida; la otra es el tener que copiar las claves permitidas en el host esxi (vamos, configurar el cliente ssh para
que pueda hacerse la copia automaticamente sin introducir credenciales en la consola), Lo mas complejo de esto ultimo es que al reiniciar el esxi se borran estos ficheros, con lo que hay que reimportarlos
Esto último tiene solucion, que consistiria en guardar en un datastore los ficheros de las claves permitidas y escribit un script en el esxi que le diga que importe esas claves en el arranque (en los rc iniciales). También hay quien sugiere comprimirlos y meterlos en el oem.tgz del esxi, en vez de en red, y aplicar el mismo procedimiento de cargarlos en el inicio. Personalmente creo que es mucho lio para poca o ninguna ganancia, habiendo soluciones mejores, para la transferencia, I
mean.
Como conclusiones que he sacado yo personalmente, decir que:
1) Al escribir de esxi a nfs el rendimiento en la transferencia de datos debe ser bastante malo (de ahí que algunos de los scripts escribam en un datastore local al esxi primero y lo transfieran en trocitos de 2GB después al datastore nfs). Aparentemente esto se soluciona con el flag de async activado en el export de la unidad nfs.
2) Si lanzamos cualquiera de los scripts escritos para ejecutarse en el propio esxi desde una máquina central a través de un cliente ssh (en güinflows podeis usar plink, por ejemplo), podemos gestionar las labores de backup todas desde el mismo sitio (un servidor de backup), lo que reduce el esfuerzo (tiempo y organizacion) que hay que dedicar para asegurarse de que tenemos todos los backups bien configurados. Evidentemente podemos programar el lanzamiento de los backups (con cron o con las tareas programadas, por ejemplo) para hacerlos diariamente, semanalmente o cuando mas nos plazca.
3) El hecho de lanzarlo desde un sitio central hacia todos los esxi reparte el trabajo de backup en los host (es algo asi como un sistema de backup centralizado/distribuido, cen-dis) con las ventajas e inconvenientes que eso supone.
4) Otra ventaja de este planteamiento cen-dis, es que si hubiera un problema de comunicaciones en determinado momeno entre el jefe y los hosts, no se vería afectada la tarea de bakup, porque se está ejecutando de forma distribuida, es decir, ya lo he lanzado y ahora me olvido hasta que me notifique que ha terminado.
5) Comentar que para el caso de lanzar los scripts a través de ssh desde una maquina central, en alguno de los datastores del esxi (el de backup mismo) tenemos que tener accesibles los scripts que queramos ejecutar para que los host los puedan «coger» (realmente lo ven como un fichero más dentro de su estructura de carpetas y no saben donde está).
6) Da la sensación por lo leído y lo estudiado de las tripas de los scripts que el mas completo de ellos es el ghettoVCB (vamos el vcb cutre 😀 ), que sería del tipo «lo lanzo en el propio host esxi». Permite parametrizar bastantes cosillas tal cual lo tiene escrito el autor.
7) Para el caso de los scripts que implementan algún método de compresión tras la copia (gzip, por ejemplo, en el caso de los scripts para linux), decir que sólo tiene sentido en el caso de que la máquina que ejecuta el script (y por consiguiente la rutina de compresión) almacene localmente los ficheros de backup. Y digo localmente, no digo una maquina virtual que no sabemos donde vive exactamente en nuestras cabinas u openfilers o lo que sea; en el caso de máquinas virtuales, tenemos que saber a ciencia cierta que el almacenamiento es local y no san o nfs o whatever. El porqué de esto, es que si los backups están almacenados en algún sitio en la red, me tengo que traer los ficheros por la red, los tengo que comprimir y luego los tengo que escribir comprimidos otra vez en red (esto, además del primer viaje que han hecho los ficheros desde los hosts hasta la san). Evidentemente, asi a botepronto, esto triplicaría la ventana de backup (y no siempre podemos permitírnoslo, no?).
8) Como todo tiene pegas, no se puede tener snapshot previos para utilizar estos metodos. Algunos scripts fallarian, otros se saltan esas vm… Anyway, hay quien recomienda no tener un snapshot mas de unas horas, dicen que es una mala práctica… I don’t know, tu que opinas?
Y aquí la URL donde están los scripts:
http://www.4shared.com/file/109566863/6da06dcb/backup_esxitar.html
Un besi
tor
Josep Ros
