Copias consistentes en KVM

Publicada en por admin
SOLO FUNCIONA CORRECTAMENTE EN CENTOS7

La idea es usar el script de python kvmBackup (https://github.com/bioinformatics-ptp/kvmBackup) con algunas modificaciones realizadas por mi para mejorar su comportamiento. Este script permite la automatización de las tareas de backup usando la API de libvirt para la automatización de las copias en una máquina. Permite definir tiempo de rotación de las copias, … 

Instalación del software necesario

El software en si no necesita instalación, ya que es un script python, pero tiene una serie de dependencias que hay que resolver para una correcta ejecución de este. 

Hay que instalar los siguientes paquetes libyaml, PyYAML, pigz, unzip 

yum install libyaml PyYAML pigz unzip

Luego nos descargamos la versión modificada del script desde el enlace de este post y lo colocamos en el home del root 

Para que las snapshot en caliente de kvm de forma consistente funcionen, hay que instalar una versión modificada de qemu-kvm, ya que en el binario de centos no esta incluido el soporte de snapshot. Hay que instalar la versión de redhat que esta disponible de forma gratuita. Para ello hay que realizar lo siguiente (OJO, se puede realizar en una máquina madre con hijas en ejecución que no pasa nada, las máquinas no se paran) 

cd /etc/yum.repos.d/ 
vim qemu-kvm-rhev.repo

y pegamos el siguiente texto 

[qemu-kvm-rhev] 
name=oVirt rebuilds of qemu-kvm-rhev 
baseurl=http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7Server/ 
mirrorlist=http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-3.5-el7Server 
enabled=1 
skip_if_unavailable=1 
gpgcheck=0

A continuación 

yum remove qemu-kvm yum install qemu-kvm-rhev

Luego procedemos a instalar los drivers virtio-win necesarios para poder realizar los snapshot consistentes, para ello hay que realizar lo siguiente: 

wget https://fedorapeople.org/groups/virt/virtio-win/virtio-win.repo -O /etc/yum.repos.d/virtio-win.repo 
yum install virtio-win

y ponemos la última versión estable de los drivers virtio-win en la carpeta /isos que luego nos hará falta para la instalación del qemu guest agent 

cd /isos/ 
wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

Preparación de las máquinas virtuales para ejecutar el script

Este script hace las copias consistentes para versiones superiores a windows7 y 2008, y linux, para versiones de windows2003 y windows XP el Qemu Guest Agent no soporta la creación de snapshot consistentes ya que no es capaz de comunicarse con el sistema operativo para que deje de escribir en disco en el momento de generar el snapshot, por tanto en estos casos puede darse el caso de tener insconsistencias de datos al restaurar la copia de seguridad. 

Para poder crear los snapshot de forma segura, es necesario realizar una serie de acciones en la máquina virtual e instalar un software. Se explican los pasos según el tipo de SO de la máquina virtual. 

Máquina linux

En el caso de una máquina linux, es posible realizar la configuración sin apagar la máquina. Primero veremos el caso de hacerlo apagando la máquina y luego sin apagarla. 

Apagando la máquina

  1. Apagamos la máquina hija
  2. Desde la madre, editamos la máquina y añadimos un nuevo hardware. Podemos hacerlo gráficamente o por línea de comandos. 
    1. Gráficamente 
      1. Le damos a añadir HW y añadimos un Channel. 
      2. Seleccionamos el tipo org.qemu.guest_agent.0, Unix Socket y Auto socket
    2. Línea de comandos
      1. Editamos el fichero XML de la máquina y añadimos las siguientes líneas 
  3. Encendemos la máquina hija, entramos en la máquina hija e instalamos el sw necesario, en el caso de ser un centos,

Con la máquina encendida

  1. Desde la máquina madre, creamos un fichero XML que se llame agent.xml y que tenga el siguiente contenido
  2. Desde la máquina madre, agregamos el hw en caliente con el siguiente comando
  3. Entramos en la máquina hija e instalamos el sw necesario, en el caso de ser un centos,

Máquina Windows

En el caso de máquinas windows, siempre hay que apagar la máquina para poder hacer la configuración. 

  1. Apagamos la máquina
    1. Editamos la máquina y añadimos un nuevo hardware. Podemos hacerlo gráficamente o por línea de comandos.
      1. Gráficamente 
        1. Le damos a añadir HW y añadimos un Channel. 
        2. Seleccionamos el tipo org.qemu.guest_agent.0, Unix Socket y Auto socket
      2. Línea de comandos
        1. Editamos el fichero XML de la máquina y añadimos las siguientes líneas
    2. Mapeamos en el CD de la máquina la iso virtio-win.iso, que debe de estar en la carpeta /isos (esto en teoría se podría hacer tirando desde la instalación que hemos echo del virtio-win en la madre, mapeandole el path correspondiente (/usr/share(virtio-win)
    3. Encendemos la máquina. La máquina debe de detectar un HW nuevo, en caso contrario, nos vamos al administrador de HW y debe de aparece un dispositivo PCI que no reconoce. Le damos a Actualizar controlador, y le decimos que busque el driver en el CD-ROM. Nos debe de encontrar el driver correspondiente pero nos preguntará cual queremos instalar. Seleccionamos la versión correspondiente para el SO y arquitectura. Una vez instalado es posible que nos pida reiniciar el equipo, pero no siempre lo pide. Si no reconoce el driver correspondiente, lo que hay que coger y decirle de donde lo tiene que leer, que es CD-ROM\vioserial\so\arquitectura. El dispositivo nuevo que nos debe de quedar estará dentro de Dispositivos del sistema VirtIO-Serial Driver 
    4. Una vez instalado el driver, nos vamos al CD ROM, vamos a la carpeta guest-agent y ejecutamos el binario correspondiente a la arquitectura de nuestra máquina. Esto nos instalará el software necesario que se materializa como dos servicios QEMU. 
    5. Entrar en el administrador de servicios y verificar que ambos servicios tienen inicio automático y están iniciados. 

Configuración y ejecución del script El script funciona de forma muy sencilla. Tiene un fichero de configuración donde decimos de que máquinas queremos hacer copias de seguridad que día y la retención que tendrán estas copias, y luego simplemente lo ejecutamos. 

Veamos primero el fichero de configuración. Se ubica en el mismo directorio del script, config.yml. Básicamente el contenido del fichero es el siguiente: 

bernabet :
    domains:
        centos7:
            #day_of_week: [Sun, Mon, Tue, Wed, Thu, Fri, Sat]
            day_of_week: [Fri]
            rotate: 4
        Winturasa:
            #day_of_week: [Sun, Mon, Tue, Wed, Thu, Fri, Sat]
            day_of_week: [Mon]
            rotate: 4
            w2k3: 1
        navisionpreR2:
            #day_of_week: [Sun, Mon, Tue, Wed, Thu, Fri, Sat]
            day_of_week: [Sat]
            rotate: 4
            w2k3: 0
    backupdir: /maquinasvirtuales/backup
  •   El primer parámetro es el hostname de la máquina. En teoría el script esta preparado para desde una máquina poder lanzar las copias de otras madres, pero esto aún no esta operativo. En el caso del ejemplo, la máquina es bernabet
  • El segundo parámetro indica que a continuación aparecen las máquinas de las cuales vamos a hacer copias de seguridad. 
  • El tercer parámetro es el nombre de la máquina hija, como aparece listada en el virsh list
  • El cuarto parámetro es el/los días de la semana que se realizará la copia de seguridad. 
  • El quinto parámetro son los días de rotación, es decir, cuanto tiempo va a mantener la copias de seguridad de la máquina sin sobreescribirla. 
  • El sexto parámetro, es una de las modificaciones de la EPTDA, e indica si la máquina es un windows2003/XP o superior. En caso de que este a 1 indica que es w2003/XP y por tanto a la hora de hacer el snapshot tiene que ejecutarse sin un parámetro que puede perder la consistencia de la máquina. En el caso de no poner nada o poner 0, se entiende que la máquina hija soporta el snapshot consistente y se lanza de esa forma. 
  • El septimo parámetro es el path donde se realizará la copia de seguridad. 

Para lanzar el script basta ejecutar

./kvmBackup.py --config ./config.yml

Lo suyo es programarlo en el crontab, por ejemplo de la siguiente forma 

0  2  *  *  * root /root/kvmBackup/kvmBackup.py --config /root/kvmBackup/config.yml >> /var/log/kvmBackup 2>&1

Recuperación del una máquina

Para poder restaurar una máquina, lo primero que tenemos que hacer es eliminar o destruir la antigua máquina, ya que el id de la máquina es el mismo. En caso de hacerlo en otra madre, no es necesario destruirla. 

A continuación lo que hacemos es seleccionar la copia que queremos restaurar y desempaquetar el contenido

[root@cloud1 ~]#tar zxvf ficherobackup.tar.gz 
2015-12-13/DockerNode2.xml 2015-12-13/DockerNode2-inactive.xml 
2015-12-13/DockerNode2-migratable.xml 
2015-12-13/829cd357-8ae7-4d0d-9a3b-308fbcbc8e7b-0.img

Los tres ficheros .xml son generados al hacer el backup con parametros distintos del comando virsh dumpxml. El primero es sin parámetros, el inactive.xml se obtiene usando el parámetro –inactive, que es cuando el dominio no esta activo, y este es el que usaremos para recuperar ya que la máquina simula un apagado en el snapshot; el migratable.xml es obtenido con el parámetro –migratable, y suele usarse para migración de máquinas (no tiene definidas ni redes ni bridges). 

Movemos las imagenes de los discos al path correspondiente donde deben de estar. 

mv 2015-12-13/829cd357-8ae7-4d0d-9a3b-308fbcbc8e7b-0.img /var/lib/libvirt/images/829cd357-8ae7-4d0d-9a3b-308fbcbc8e7b-0.img

Y ahora creamos la máquina en base al xml del que hicimos el backup. 

root@cloud1 ~]# virsh define 2015-12-13/DockerNode2-inactive.xml
Dominio DockerNode2 definito da 2015-12-13/DockerNode2-inactive.xml

[root@cloud1 ~]

# virsh list –all  Id    Nome                           Stato —————————————————-
 10    DockerNode1                    en ejecucion
 –     DockerNode2                    apagada OJO
Si la máquina es movida de un servidor a otro, el parámetro de guest agent channel no es válido y fallará a la hora de crear la máquina. Para ello, es necesario modificar las entradas del guest agent channel en el xml de la máquina; es decir, abría que editar el xml de definición de la máquina y donde aparece 

<channel type='unix'>
  <source mode='bind' path='/var/lib/libvirt/qemu/channel/targe/DockerNode2.org.qemu.guest_agent.0'/>
  <target type='virtio' name='org.qemu.guest_agent.0'/>
  <address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>

debería de aparecer 

<channel type="unix">
   <source mode="bind"/>
   <target type="virtio" name="org.qemu.guest_agent.0"/>
</channel>

que es lo que aparece la primera vez que añadimos el channel a la máquina creada desde cero. 

Esta información esta sacada de la siguientes urls

Script python usado para realizar las copias de seguridad. Versión original sin modificar. Solo funciona en Centos7 

Guia de como instalar y usar el Qemu Guest Agent  necesario para el script anterior 

Página donde se descargan o instalar los driver windows-virtio para poder instalar el agent en las máquinas windows. 

  • https://fedoraproject.org/wiki/Windows_Virtio_Drivers

Guia de como hay que instalar el paquete qemu-kvm-rhev para que tenga incorporada la funcinalidad de crear snapshot en caliente 

  • https://www.redhat.com/archives/libvirt-users/2014-November/msg00106.html

Con windowsxp y windows2003 server no se pueden hacer los snapshot de 
forma que se pueda asegurar la consistencia por el quiesce 

  • https://bugzilla.redhat.com/show_bug.cgi?id=1086084

Guia de parametros y uso de libvirt 

  • https://libvirt.org/html/libvirt-libvirt-domain-snapshot.html

Método alternativo para usar pero que actualmente no usamos 

  • http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

Otro método para hacer las copias con pause y resume 

kvmBackup-master.tarDescarga