AKAsistemas

Si bien la plataforma de virtualización de Red Hat no es la mas popular del mercado si que es competitiva y con una cantidad de funcionalidades interesantes que son de envidiar, las cuales se pueden consultar en el siguiente enlace, una de las caracteristicas que mas adolecen a la plataforma es la carencia de una herramienta integrada de respaldos de las maquinas virtuales (VmWare tampoco la tiene, se puede instalar herramientas de terceros por modicos costos ;)) mas eso no quiere decir que no se den facilidades para la integración con terceros (solo necesitas picar un poco de codigo para utilizar su API), tambien vale la pena mencionar que hay herramientas externas que si soportan los respados de VM en RHV de forma nativa por mencionar una nada mas sería Acronis, sin embargo hay otras herramientas mas veteranas como veritas la cual particularmente no cuenta con dicha integración a RHV.

En esta ocasión trataremos de hacer una integración con Veritas Netbackup sencillamente haciendo uso de sus herramientas; este trabajo se estructurará en dos secciones.

Respaldos de maquinas virtuales a través de virtual apliance.

Integración del virtual apliance a Veritas Netbackup.

Respaldos y restauración de maquinas virtuales a través de virtual apliance

En esta primera etapa se hará uso en su mayoría del sdk de python para ovirt y haremos uso de las recomendaciones de respaldo propiamente del proyecto ovirt en donde nos indican que lo mas practico para hacer los respaldos de las VMs.

A modo de resumen se presenta la siguiente arquitectura de la solución.

Flujo de respaldo

Fuente: Andrey Amado

Flujo de restauración
Fuente: Andrey Amado

Si bien estos son los componentes principales, ahora vamos a ver el gráfico en donde se verá el proceso de respaldo.

Fuente: Andrey Amado

Seguidamente el proceso de restauración.

Fuente: Andrey Amado

Antes de continar es claro decir que este trabajo se basa en gran medida por el trabajo hecho por vacosta94 me he tomado la libertad de hacer cambios en su codigo, mismo que estoy publicando junto con este trabajo.

REQUISITOS

Una maquina virtual GNU/Linux de preferencia Centos7 esta debe en el mismo datacenter en donde se encuentran las VMs a respaldar.
Librerias de python para la api de ovirt
Un directorio con suficiente espacio para almacenar el respaldo de la maquina virtual.
CA del manager del entorno de virtualización
Suficiente espacio en el dominio de almacenamiento para almacenar los snapshots.

INSTALACIÓN

Primero que todo necesitaremos una maquina Centos7/RHEL 7 con python instalado ya que este script corre bajo dicho interprete.

Seguido instalaremos el sdk de ovirt, este nos permitirá consumir la API del manager y adicionalemente algunas herramientas adicionales para la correcta ejecución.

yum install -y epel-release
yum install -y qemu-img python-ovirt-engine-sdk4 python-requests git ovirt-guest-agent
Hay que establecer un directorio de trabajo en donde se ubicarán los archivos descargados del proyecto, para este ejercicio y siendo fieles al trabajo original trabajaremos en sobre el directorio /opt/obkp

mkdir -p /opt/obkp && cd /opt/obkp

git clone git@gitlab.com:andrey66/ovirt-vm-backup-rhv-vm-backup.git

curl --insecure "https://rhevmanager.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA" -o ca.crt

Este ultimo archivo es la CA del manager, archivo indispensable para poderse conectar, usted puede descargarlo en donde desee, sin embargo es importante recordar la ruta en donde se guarda puesto que debemos especificarla en el archivo de configuración default.conf el cual esta dentro del repositorio de software.

CONFIGURACIÓN

La configuración esta controlada por el archivo default.conf el cual se le enviará como parametro al script de respaldo y restauración, el archivo tiene la siguiente estructura.

#################default.conf###############

[bkp]
url             = https://rhevmanager.example.net/ovirt-engine/api
user            = admin@internal
password        = pass123
ca_file         = /opt/obkp/ca.crt
bkpvm           = NVOVMPROXY
bckdir          = /mnt/

[restore]
url             = https://rhevmanager.example.net/ovirt-engine/api
user            = admin@internal
password        = test123
ca_file         = /opt/obkp/ca.crt
storage         = nvo-MSA2050-Dev
bkpvm           = NVOVMPROXY
bckdir          = /mnt/

#######################################

El archivo se divide en dos secciones, la primera para el respaldo y tiene las siguientes lineas:

a)
[bkp]

Es la definición de la cabecera de la sección de repaldo, se invocará cuando el script de backup sea ejecutado.

url = https://rhevmanager.example.net/ovirt-engine/api

La url del manager, es importante recordar que la conexión es solo permitida por https

c)
user = admin@internal
El usuario y dominio con el que se quiere conectar.

d)

password = pass123
La contraseña para autenticar el usuario.

e)
ca_file = /opt/obkp/ca.crt
La CA del manager, si la correcta CA no se podrá conectar al manager.

bkpvm = NVOVMPROXY

El nombre de la maquina virtual que esta actuando como Apliance, este nombre debe ser el que aparece en el manager de preferencia debe coindicir con el hostname interno de la VM.

g)
bckdir = /mnt/

El directorio en donde se almacenará el disco y la metadata de la maquina virtual, es muy importante contar con el suficiente espacio para alojar todos los discos de la VM.

[restore]

Cabecera para la sección de restauración

url             = https://rhevmanager.example.net/ovirt-engine/api
 

Url del manager para el proceso de restauración.

user            = admin@internal

Usuario para el proceso de restauración.

password = test123

Contraseña para el usuario

ca_file         = /opt/obkp/ca.crt 

CA para conectarse de forma segura al manager

storage         = nvo-MSA2050-Dev
 

Dominio de almacenamiento en donde se restaurarán los discos o maquinas virtuales. 

bkpvm = NVOVMPROXY

Maquina virtual appliance desde donde se ejecutarán las restauraciones.

bckdir          = /mnt/

Directorio en donde se buscará el directorio, discos y metadata que será posteriormente restaurada en forma de VM.

EJECUCIÓN

RESPALDO

Una vez que se tiene claro lo que se necesita, vamos a ejecutar el script por primera vez.

Fuente: Andrey Amado

Con esta primera ejecución deberemos tener en el directorio /mnt un directorio con el nombre la VM respaldada y sus respectivos archivos.

Fuente: Andrey Amado

Como lo podemos ver en la imagen efectivamente el respaldo fue ejecutado exitosamente y con su archivo de disco .qcow2 y la metada respectiva.

Solo a modo de guia el contenido de la metada en este caso es el siguiente:

Fuente: Andrey Amado

Toda esta información es estrictamente necesaria para que el script pueda crear la maquina virtual, de lo contrario se trendrá que hacer los pasos manualmente para restaurar el disco y posteriormente la VM.

RESTAURACIÓN

Ahora se procederá con el proceso de restauración, es muy importante recordar el directorio que se especificó en el archivo default.conf en la sección restore en este caso es "/mnt"

Fuente: Andrey Amado

Se aclara que el parametro del nombre de la maquina virtual es el directorio que el script buscara sobre el SO; adicionalmente en caso de que el nombre de la VM ya exista dentro del manager se le agregará al nombre las letras "RES", esto se puede ver en la imagen, ahora vamos a ver como quedaron en el manager.

Fuente: Andrey Amado

Se aclara que las tarjetas de red no se les restaura la vlan, esto con fines de seguridad obligando al sysadmin a configurar manualmente la red.

Fuente: Andrey Amado

Ahora se procederá a ejecutar la VM y verificar que inicie correctamente.

Fuente: Andrey Amado

En algunos casos con Windows es necesario reiniciar el SO para que tome el puntero del mouse.

INTEGRACIÓN CON NETBACKUP

Si bien es conocido por todos no existe una integración directa entre Netbackup y RHV, pero en este caso se intentará usar el script de la primera sección junto con los scripts propiamente de netbackup, puntualmente bpstart_notify y restore_notify desde el lado del master de netbackup.

El diagrama general es el siguiente:

Fuente: Andrey Amado

Inicialmente el grafico puede ser un poco confuzo pero a medida que vayamos explicando el proceso este quedará un poco mas claro.

MODIFICACIONES AL CLIENTE DE NETBACKUP (BPSTART_NOTIFY)

Primero vamos a aclarar que a partir de este punto se asume que el cliente de netbackup esta instalo en la maquina virtual (virtual appliance).

lo pimero será copiar el script de bpstart_notify desde el master al cliente, la documentación (Administrator Guide II de veritas) el script lo podemos encontrar en la ruta "/usr/openv/netbackup/bin/goodies/bpstart_notify" y deberemos colocarlo en la ruta del cliente "/usr/openv/netbackup/bin/"

Fuente: Andrey Amado

Debemos de asegurarnos que el script tenga permisos de ejecutarse, se los asignaremos con el comando chmod +x bpstart_notify.

Ahora se debe editar el archivo para incrustar nuestra linea del script.

Fuente: Andrey Amado

Los cuadros en rojo indican los datos importantes, la primera variable es nada mas para tener en cuenta donde se volcará el log del script; nuestra insersión es puntualmente la segúnda en donde indicamos la ruta absoluta del script con sus parametro, atención al tercer parametro $3 este será el nombre de la VM a respaldar y será entregada a través del nombre del schedule de la politica (lo veremos cuando se cree la politica en netbackup) y la redirección de la salida del log de bpstart "BPSTART_CALLED", guardamos los cambios y salimos.

Los detalles del funcionamiento del script bpstart_notify se explican muy detalldamente en la documentación de netbackup, por lo que explicarlos en este documento esta demás.

MODIFICACIONES AL SERVIDOR DE NETBACKUP (RESTORE_NOTIFY)

Así como se modifico el cliente, es hora de hacer una pequeñas modificaciones al servidor las cuales consisten en agregar las llaves SSH al root del cliente y una pequeña modificación al script restore_notify en el servidor.

El proceso de intercambio de llaves SSH asegura que el servidor de netbackup pueda logearse en el cliente (VirtualAppliance) sin contraseña.

Los pasos se resumen en lo siguiente:

- Generar unas llaves publicas en el servidor de netbackup con el comando "ssh-keygen -t rsa".

- Copiar los certificados con "ssh-copy-id root@ip_virtual_app"

- Asegurar que en el cliente exista el certificado y se pueda iniciar sesión sin contraseña desde el master al virtual app.

Fuente: Andrey Amado


Fuente: Andrey Amado

Como se puede observar ya podemos ejecutar comandos en el virtualappliance desde el master de netbackup.

Ahora vamos a modificar el script de restore_notify, este se encuentra en la ruta /usr/openv/netbackup/bin del master de netbackup, también debe tener permisos de ejecución.

Fuente: Andrey Amado

Pimero modificaremos la shell de ejecución para hacer que algunos parametros a través de ssh no nos den tantos problemas y según insertaremos las variables del host del virtual appliance y la variable de como descubriremos como se llama la maquina virtual que se quiere restaurar.

NOTA IMPORTANTE: El directorio de restauración DEBE estar vacio para evitar conflictos con el proceso de restauración.

Fuente: Andrey Amado

El segundo cambio y el mas considerable es el siguiente:

Fuente: Andrey Amado

                        IMAGE=`echo $2`
                        CLIENT=`echo $IMAGE | sed 's/_.*//'`
                        if [ $CLIENT == "NVOVMPROXY" ]; then
                                echo $(date) "Start recovery process" >> $OUTF
                                echo ${dateStr} $IMAGE "<- removable media device" >> $OUTF
                                echo $VM >> $OUTF
                                echo $SRVVMBKP >> $OUTF
                                /bin/ssh root@$SRVVMBKP "/bin/echo '' > /tmp/logres.log"
                                /bin/ssh root@$SRVVMBKP "/bin/echo $(/bin/date) Restore process is starting.. wait some minutes >> /tmp/logres.log"
                                /bin/ssh root@$SRVVMBKP "/bin/python /opt/obkp/restorevm.py /opt/obkp/default.conf $VM >> /tmp/logres.log"
                                /bin/echo $(/bin/date) Restore process was finished >> $OUTF
                        fi

CUIDADO: El script de restuaración se ejecuta una vez se terminan la copia de los archivos al cliente, es decir que el directorio que se especificque en este caso /mnt debe ser el mismo definido en el archivo default.conf, debe asegurarse en limpiar el directorio de restauración antes de proceder con un proceso de restauración desde la consola de netbackup de lo contrario puede generar conflictos en el proceso de restauración.

NOTA: Es normal que una vez se ejecute el proceso de restauración no vea el progreso en el log interno de netbackup puesto que espera a finalizar el proceso remoto de python y así liberar la salida del sistema.

Con esto concluimos la modificación de los scripts, ahora a crear la politica de prueba en Netbackup.

CREACIÓN DE POLITICAS DE RESPALDO

Lo primero será abrir la consola de administración de netbackup e iniciar el asistente para crear nuevas politicas.

Fuente: Andrey Amado

Seguidamente se creará una politica de filesystem, puesto que la intención es copiar los archivos generados por el script.

Fuente: Andrey Amado

A continuación se le da un nombre a la politica y se especifica el tipo, este será del tipo estandar puesto que el virtualappliance es una maquina tipo *NIX.

Fuente: Andrey Amado

A continuación se agrega el nombre del cliente del apliance.

NOTA: Este instructivo no cubre como instalar el cliente de netbackup, por lo tanto se asume que el cliente ya es alcanzable desde la consola de administración de Netbackup.

Fuente: Andrey Amado

Si la configuración de cliente es correcta el msmo netbackup debería haber detectado las configuraciones del cliente.

Fuente: Andrey Amado

En este paso se sellecionará el directorio a respaldar por el agente de netbackup, es muy importante mencionar que es obligatorio elegir el mismo directorio definido en el archivo default.conf de lo contrario el agente no respaldará nada de lo que el script genere.

Fuente: Andrey Amado

Ahora se elegirá el tipo de respaldo, en este caso será full (por defecto nos va a crear una tarea con el nombre de Full, mas adelante modificaremos este detalle).

Fuente: Andrey Amado

Le definiremos la frecuencia y la retención (mas adelante revisaremos de nuevo estos parametros)

Fuente: Andrey Amado

En la siguiente pantalla se defnirá las horas para ejecutar el respaldo, igual estos datos se revisarán mas adelante.

Fuente: Andrey Amado

Y con esto se termina la configuración de la politica.

Fuente: Andrey Amado

Ahora vamos a verificar la politica creada

Fuente: Andrey Amado

Con la politica creada ahora es necesario modificar el schedule, punto importante a mencionar es que el nombre del schedule DEBE ser el nombre de la maquina virtual a respaldar, de lo contrario el parametro que le llegará a bpstart_notify y por ende al script de respaldos no será una VM valida y fallará el proceso.

Fuente: Andrey Amado

Para el caso del ejemplo se especificará que la politica se ejecute los primeros días de la semana, puntualmente los domingos.

Fuente: Andrey Amado

El schedule final quedo de la siguiente forma.

Fuente: Andrey Amado

EJECUCIÓN MANUAL DE LA POLITICA

Ahora vamos a probar la politica creada y verificar su funcionamiento.

Fuente: Andrey Amado

Revisamos el progreso de la tarea y podemos verificar el avance de la misma.

Fuente: Andrey Amado

La revisión de la salida del script nos confirma que el resultado del respaldo a sido éxitoso.
NOTA: el script se demora en arrojar la salida puesto que es capturada hasta que termine su ejecución.

Fuente: Andrey Amado

Al momento de revisar el respaldo se puede observar que fue creado éxitosamente y se encuentra almacenado bajo la politica del netbackup.

Fuente: Andrey Amado

RESTAURACIÓN DE MAQUINA VIRTUAL

En caso que el nombre de la maquina virtual exista se le agregará las letras RES, para este caso se puede ver como existe la maquina original.

Fuente: Andrey Amado

En la anterior imagen se puede observar que el proceso termino éxitosamente, pero aun no tenemos certeza de si l amaquina se restauro correctamente o no y cual fue el proceso, para ello nos vamos enfocar en dos archivos,

el primero será el archivo RESTORE_CALLED en el servidor de netbackup
el segundo es el archivo /tmp/logres.log en el virtual appliance en donde se guarda la ejecución de la restauración de la maquina, este log no mostrará el progreso hasta que termine la ejecución del mismo, en una revisión posterior se intentará corregir este defecto.

Muestra de la salida del restore_called en el servidor de netbackup
Fuente: Andrey Amado

Fuente: Andrey Amado

Por ultimo se enciende la maquina y se verifica que haya iniciado correctamente.

Fuente: Andrey Amado

Espero este trabajo pueda ayudar a cubrir algunas de las necesidades de respaldos.

En caso de comentarios me pueden contactar a través de gitlab o bien a través del blog.

Hasta el proximo post.