Jan 10, 2010

Backups en VMware ESXi

VMware ESXi 4.0 sólo nos permite hacer un backup de la configuración del servidor (usuarios, servidores NTP, parámetros del sistema, etc.) y no de las máquinas virtuales. Esta tarea se puede realizar a través del VMware vSphere CLI:

VMware vSphere CLI> vicfg-cfgbackup --server 192.168.1.11 --username root --password xxxxxx -s ESXi20091211.backup

Únicamente tendremos que indicar la dirección IP del ESXi, la password para el usuario root y un nombre para el fichero de backup.

Para restaurar el backup de configuración, ejecutaremos la siguiente orden:

VMware vSphere CLI> vicfg-cfgbackup --server 192.168.1.11 --username root --password xxxxxx -l ESXi20091211.backup

Para hacer un backup de una máquina virtual, tenemos la opción de exportarla a través de la herramienta VMware vSphere Client. Para ello tendremos que apagarla en primer lugar y a continuación pulsar sobre File, Export, Export OVF Template. Esta opción nos permitirá guardar en nuestro disco duro local una imagen en formato OVF de la máquina virtual.

El formato OVF (Open Virtualization Format) es un estándar abierto para empaquetar y distribuir máquinas virtuales. Su principal ventaja es que el tamaño de las exportaciones suele ser bastante más pequeño que el original, ya que no empaqueta las secciones del disco duro virtual que están sin utilizar. Por contra, este proceso tiene la principal desventaja de que hay que hacerlo con la máquina virtual apagada y de forma manual.

Si tenemos acceso a la service console del ESXi, vamos a tener la posibilidad de poder realizar backups de las máquinas virtuales de manera automática y en caliente, es decir, sin apagar el sistema operativo de la máquina virtual.

La idea es la siguiente: en primer lugar habría que hacer una copia del fichero VMK de la máquina virtual. A continuación habría que hacer un snapshot, de esta forma y a partir de este momento, cualquier cambio no se escribiría en el disco virtual, sino en el snapshot. Después ya podríamos copiar el disco virtual VMDK, y por último, eliminaríamos el snapshot.

Para hacer todo esto existe un script llamado ghettoVCB.sh, el cual sigue una metodología similar a la herramienta de pago de VMware para tal fin: VCB (VMware Consolidated Backup). Este script lo depositaremos en el datastore local del ESXi y le asignaremos permisos de ejecución.

~ # chmod +x /vmfs/volumes/datastore1/ghettoVCB.sh

La razón por la que se guarda en el datastore local es debido a que cualquier fichero o directorio que creemos fuera de este espacio, será automáticamente eliminado al volver a arrancar el ESXi.

El backup que creemos a partir de la máquina virtual lo podremos almacenar en el propio datastore local o montar una unidad de almacenamiento por NFS o iSCSI. Para el presente caso de estudio vamos a emplear un datastore remoto accedido por NFS y ubicado en la máquina con dirección IP 192.168.1.100.

Para dicho datastore se tiene la opción de dejarlo montado de forma permanente a través del cliente vSphere, o bien configurar las variables del script para que monte y desmonte la unidad remota cuando la vaya a emplear. Utilizaremos la segunda opción.

A continuación vamos a editar el script y modificar el valor de alguna de sus variables.

~ # cat /vmfs/volumes/datastore1/ghettoVCB.sh
...
# Formato del backup de la VM
DISK_BACKUP_FORMAT=zeroedthick

# Número de backups que serán rotados
VM_BACKUP_ROTATION_COUNT=1

# Habilitar el backup a través de NFS
ENABLE_NON_PERSISTENT_NFS=1

# Desmontar la unidad remota cuando el backup se haya completado
UNMOUNT_NFS=1

# Dirección IP del servidor NFS
NFS_SERVER=192.168.1.100

# Directorio que exportará el servidor NFS
NFS_MOUNT=/export

# Nombre con el que se mostrará el datastore importado
NFS_LOCAL_NAME=nfs_storage_backup

# Nombre del directorio donde se almacenarán los backups
NFS_VM_BACKUP_DIR=backups
...

Si en lugar de almacenar el backup en la máquina remota a través de NFS hubiéramos empleado el propio datastore local del ESXi, tendríamos que haber definido a través de la variable VM_BACKUP_VOLUME el path donde depositar el backup.

Los distintos formatos que soporta el backup (variable DISK_BACKUP_FORMAT) son los siguientes:

  • zeroedthick: éste es el tipo de disco utilizado por defecto al crear una VM en un ESXi y todo el espacio de almacenamiento es reservado previamente. Además, sus bloques son borrados (puestos a cero) la primera vez que se escribe sobre ellos.

  • eagerzeroedthick: durante el momento de su creación, todo el espacio es reservado y puesto a cero. Este tipo de discos son los más seguros, ya que los bloques han sido previamente borrados de cualquier dato previo, ofreciendo además un rendimiento ligeramente superior durante la primera operación de escritura.

  • thin: este tipo de disco tiene la peculiaridad de que crece bajo demanda, es decir, se puede definir un disco thin con un tamaño máximo de 100 GB, y nada más instalar el sistema operativo ocupar sólo 4 GB. Esos 4 GB serán el tamaño real del disco y podrá crecer hasta los 100 GB. El rendimiento ofrecido por este tipo de formato es muy pobre y no se recomienda para entornos de producción.

  • 2gbsparse: divide un disco en varios discos de un tamaño máximo de 2 GB. Este tipo de formato no se puede utilizar directamente en un ESX/ESXi, por lo que hay que transformarlo previamente a un formato thin o thick.

Decir también que el formato seleccionado (zeroedthick) crea una imagen idéntica (bit a bit) a la de la máquina virtual. Después ya por último, crearemos un fichero con la lista de las máquinas virtuales sobre las que queramos aplicar el backup (por ejemplo y para el presente caso de estudio, dos máquinas virtuales denominadas centos01.local y centos02.local).

~ # cat /vmfs/volumes/datastore1/vms_to_backup
centos01.local
centos02.local

Para ejecutar el script lanzaremos la siguiente orden:

/vmfs/volumes/4a65032c-09446b90-9d40-00237d337b62 # ./ghettoVCB.sh -f vms_to_backup -l log_backup

Para automatizar este proceso de backups podemos añadir una tarea al cron del sistema operativo. En el siguiente ejemplo se va a configurar un backup automático que se ejecute todos los Sábados por la noche a las 02:30h.

En primer lugar vamos a definir esta tarea en el cron del usuario root:

~ # cat /var/spool/cron/crontabs/root
...
30 02 * * 6 /vmfs/volumes/datastore1/ghettoVCB.sh -f /vmfs/volumes/datastore1/vms_to_backup -l /vmfs/volumes/datastore1/log_backup

Para que los cambios tomen efecto, vamos a reiniciar el proceso crond. Para ello primero lo mataremos y luego lo volveremos a arrancar a través de busybox (binario que contiene pequeñas versiones de los comandos más básicos de Linux).

~ # kill $(cat /var/run/crond.pid)

~ # busybox crond

El problema de este método es que si en un momento dado hay que reiniciar el ESXi, el sistema operativo restaurará el cron de root por su original. Por lo tanto lo que habrá que hacer será editar el fichero /etc/rc.local y definir este proceso dentro de dicho archivo.

~ # cat /etc/rc.local
...
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "30 02 * * 6 /vmfs/volumes/datastore1/ghettoVCB.sh -f /vmfs/volumes/datastore1/vms_to_backup -l /vmfs/volumes/datastore1/log_backup" >> /var/spool/cron/crontabs/root
/bin/busybox crond

Y por último, para asegurarnos que los cambios en el fichero /etc/rc.local serán guardados para futuros reinicios, ejecutaremos el siguiente comando:

~ # /sbin/auto-backup.sh

Para restaurar un backup de una VM, primero copiaremos el directorio que contiene el backup al datastore local de la máquina, bien a través de una conexión iSCSI o NFS hacia la máquina que contiene los backups, o por ejemplo subiendo dicho directorio al datastore desde el ordenador con el que nos conectemos al ESXi a través del cliente vSphere.

A continuación, ejecutaremos un Browse sobre el datastore, accederemos al directorio que contiene todos los ficheros de la VM y pincharemos con el botón derecho del ratón sobre el archivo con extensión VMK. Para restaurar la máquina ejecutaremos la orden Add to Inventory.

11 comments:

  1. Hola que tal?

    Antes que nada, felicitarte por tu blog y por este gran articulo, esta muy bien currado y explica varios temas interesantes sobre ESXi.

    Tengo una pregunta a ver si me puedes ayudar, sabes si es posible montar un disco duro USB en un ESXi y configurarlo como un datastore, es decir ponerlo como disco duro del sistema para crear maquinas virtuales en el.

    Saludos...

    ReplyDelete
  2. Hola,

    no se puede. Puedes crear un nuevo datastore conectando un nuevo disco (fibra, iSCSI, SCSI o montando un volumen VMFS ya existente) o montando una carpeta compartida por NFS.

    A través del service console, he conseguido montar un disco USB (formateado como FAT). Pero al intentar crear un datastore dentro de esta unidad, el proceso falla debido a que no se puede formatear este dispositivo como VMFS.

    La semana que viene pondré un artículo sobre esto…

    Un saludo,

    ReplyDelete
  3. Hola Javier,

    Lo que pensaba, muchísimas gracias por la información. Tengo varios años trabajando con virtualización pero el vSphere y el ESX es nuevo para mi y mientras mas lo toco, mas me gusta.

    Por recomendación, un articulo bueno e interesante seria acerca de las limitaciones que tiene la version Hypervisor del vSphere, creo que hay mucha gente interesada en esta version por ser gratuita pero pocos somos los que conocemos todas sus limitaciones.

    Saludos...

    Felicitaciones por el blog.
    http://photoreview2010.blogspot.com

    ReplyDelete
  4. Hola,

    escribí ya un artículo exponiendo a grandes rasgos, las principales características de vSphere.

    http://redes-privadas-virtuales.blogspot.com/2009/12/vmware-esxi-y-vsphere.html

    En él hay una tabla donde puedes ver las limitaciones del ESXi (versión gratuita) con respecto al ESX (versión de pago).

    Un saludo,

    ReplyDelete
  5. Buenas tardes.

    Me gustaría hacerte unas consultas sobre este tema.
    ¿Como puedo ponerme en contacto contigo?

    Muchas gracias de antemano.

    ReplyDelete
  6. Excelente me ha ayudado mucho , pero tengo una duda fijate que cuando esta respaldando mis maquinas a un servidor NFS con centos 6 se queda en 98% clone y no pasa al respaldo de la otra maquina virtual, y tengo un buen espacio en mi servidor NFS.

    alguna idea? ,

    ReplyDelete
  7. Posiblemente no haya acabado la operación de escritura. Cosas que puedes hacer:

    1) Dentro del servidor CentOS, puedes comprobar si el tamaño de la máquina virtual que estás respaldando sigue creciendo o no. # watch 'ls -l virtual_machine'
    Si va variando el tamaño del fichero, pues espera a que finalice la escritura.

    2) Echa un vistazo a los logs de NFS en el servidor (/var/log/messages). Si fuera necesario, puedes incrementar la verbosidad (http://redes-privadas-virtuales.blogspot.com/2010/04/incrementar-los-logs-de-nfs.html).

    3) También se me ocurre que le eches un vistazo a las estadísticas del servidor NFS (# nfsstat -rc). Si el número de retransmisiones es alto, igual has tenido problemas de red.

    4) Y ya en última instancia podrías capturar tráfico con tcpdump y analizarlo con wireshark.

    ReplyDelete
  8. Hola Javier, me pareció interesante el modo en que explicas los tipos de formatos para los discos virtuales en un entorno vsphere.
    Sin embargo, cuando mencionas los discos de tipo thin, como pobres en rendimiento y no recomendables en entornos de producción, me entra la duda con la info que recojo en otro foro. En ella se hace mencion sobre el formato tipo thin: "Este es el tipo de disco que tiene el tiempo de creación más corto y el rendimiento es el mismo que el tipo eager-zeroed".
    El tiempo de creación no es mi duda, mi duda es con el rendimiento.

    Gracias.

    ReplyDelete
    Replies
    1. El problema de los thin es que el disco va creciendo a medida que lo vas utilizando (bajo demanda), así hasta el tamaño máximo que definas para ese disco. Luego no puede tener el mismo rendimiento un disco duro virtual ya creado desde el principio con su máximo tamaño, que otro que va creciendo "sobre la marcha".

      De todos modos, puedes crearte rápidamente un par de máquinas virtuales Linux, una con cada tipo de disco, y hacer pruebas de rendimiento para obtener el performance de lectura/escritura con diferentes tamaños de ficheros y de bloques. En mi blog tengo varios artículos sobre cómo hacer esto.

      Un saludo,

      Delete
  9. Hola! muy bueno tu blog!!! estoy entrando en este mundo y me ha servido!! pero tengo una duda, cree un NFS en Ubuntu server (Maquina Virtual) y al configurar todo el ghettoVCB.sh no se si estoy bien configurando los parametros, ya que no me traspasa los Backups al servidor NFS UBUNTU! te envio los datos de el ghettoVCB.sh para que me digas si estoy configurando bien !!

    (Cree una carpeta en Ubuntu que se llama copias) es ahi en donde quiero que se pasen los Backups

    _____________________________________________________________________
    # Author: William Lam
    # Created Date: 11/17/2008
    # http://www.virtuallyghetto.com/
    # http://communities.vmware.com/docs/DOC-8760
    ##################################################################

    # directory that all VM backups should go (e.g. /vmfs/volumes/SAN_LUN1/mybackupdir)
    VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS

    # Format output of VMDK backup
    # zeroedthick
    # 2gbsparse
    # thin
    # eagerzeroedthick
    DISK_BACKUP_FORMAT=zeroedthick

    # Number of backups for a given VM before deleting
    VM_BACKUP_ROTATION_COUNT=1

    # Shutdown guestOS prior to running backups and power them back on afterwards
    # This feature assumes VMware Tools are installed, else they will not power down and loop forever
    # 1=on, 0 =off
    POWER_VM_DOWN_BEFORE_BACKUP=1

    # enable shutdown code 1=on, 0 = off
    ENABLE_HARD_POWER_OFF=1

    # if the above flag "ENABLE_HARD_POWER_OFF "is set to 1, then will look at this flag which is the # of iterations
    # the script will wait before executing a hard power off, this will be a multiple of 60seconds
    # (e.g) = 3, which means this will wait up to 180seconds (3min) before it just powers off the VM
    ITER_TO_WAIT_SHUTDOWN=3

    # Number of iterations the script will wait before giving up on powering down the VM and ignoring it for backup
    # this will be a multiple of 60 (e.g) = 5, which means this will wait up to 300secs (5min) before it gives up
    POWER_DOWN_TIMEOUT=5

    # enable compression with gzip+tar 1=on, 0=off
    ENABLE_COMPRESSION=0

    ############################
    ####### NEW PARAMS #########
    ############################

    # Include VMs memory when taking snapshot
    VM_SNAPSHOT_MEMORY=0

    # Quiesce VM when taking snapshot (requires VMware Tools to be installed)
    VM_SNAPSHOT_QUIESCE=0

    ##########################################################
    # NON-PERSISTENT NFS-BACKUP ONLY
    #
    # ENABLE NON PERSISTENT NFS BACKUP 1=on, 0=off

    ENABLE_NON_PERSISTENT_NFS=1

    # umount NFS datastore after backup is complete 1=yes, 0=no
    UNMOUNT_NFS=1

    # IP Address of NFS Server
    NFS_SERVER=192.168.1.102

    # Path of exported folder residing on NFS Server (e.g. /some/mount/point )
    NFS_MOUNT=/export

    # Non-persistent NFS datastore display name of choice
    NFS_LOCAL_NAME=r5/Backup/lamw-ghettoVCB-518cef7/

    # Name of backup directory for VMs residing on the NFS volume
    NFS_VM_BACKUP_DIR=Home/expled/copias

    ############################
    ######### EMAIL ############
    ############################

    ReplyDelete
    Replies
    1. Hola,

      En el ejemplo que utilizo, en el servidor NFS exporto el directorio "/export", el cual contiene a su vez el directorio "backups".

      Luego en base a tu configuración, deberías exportar por NFS desde Ubuntu, el directorio "/export", el cual a su vez contendrá los directorios "Home/expled/copias" con permisos de escritura.

      Delete