Veeam: Novedades en Veeam Backup & Replication v11 – Linux Proxies – DirectSAN con NetApp

Saludos amigos, allá por Marzo de 2020 os contaba que Veeam había dado un paso muy importante anunciando Linux Proxies, un componente que sin duda tiene todo el sentido del mundo seleccionar Linux para ello, ya que solo mueve información de un lugar a otro.

Ahora con Veeam Backup and Replication v11, Veeam da un salto adelante e incluye muchas mejoras para los Proxy basados en Linux, por ejemplo, ahora podemos usar otros métodos de backup, como son DirectSAN, DirectNFS, y Fibre Channel. Y ahorrar en licencias Windows, y aumentar en seguridad.

En esta fantástica entrada, vamos a ver el paso a paso para usar un Ubuntu 20.04 LTS en modo DirectSAN, a unas cabinas de discos que tengo. De esta forma el backup va a volar, además de liberar carga de trabajo al hypervisor.

Diagrama del funcionamiento de Proxy Linux usando Direct-SAN

Para recuperar los bloques de datos de la VM desde un LUN SAN durante la copia de seguridad, el proxy de copia de seguridad utiliza metadatos sobre la disposición de los discos de la VM en la SAN.

La copia de seguridad de datos en el modo de transporte de acceso directo a la SAN incluye los siguientes pasos:

1. El proxy de copia de seguridad envía una solicitud al host ESXi para localizar la VM necesaria en el almacén de datos.
2. El host ESXi localiza la VM.
3. Veeam Backup & Replication activa VMware vSphere para crear una instantánea de la VM.
4. El host ESXi recupera los metadatos sobre la disposición de los discos de la VM en el almacenamiento (direcciones físicas de los bloques de datos).
5. El host ESXi envía los metadatos al proxy de copia de seguridad.
6. El proxy de copia de seguridad utiliza los metadatos para copiar los bloques de datos de la VM directamente desde el almacenamiento de origen a través de la SAN.
7. El proxy de copia de seguridad procesa los bloques de datos copiados y los envía al destino.

Fantástico, ahora que sabemos cómo funciona y cómo envía la información desde un lugar a otro, vamos a ver los pasos para poner nuestros Proxies Linux a tope.

Supongo que estáis usando redes dedicadas. Por ejemplo, todo mi tráfico iSCSI va por el rango 192.168.100.0, con un cable dedicado. Como mis proxies son virtuales, he añadido una segunda tarjeta de red que ve ésta red.

Configurar nuestro Cliente de iSCSI (iSCSI Initiator)

Los pasos son muy sencillos, y aunque pueden variar un poco si tenéis RedHat u otros, seguro son parecidos los pasos, lo primero será instalar el paquete open-iscsi (que seguramente tengáis)

sudo apt-get update
sudo apt-get install open-iscsi

Una vez tenemos instalado el paquete, vamos a añadirlo al arranque:

sudo systemctl enable iscsid

Que nos mostrará algo similar a esto:

Synchronizing state of iscsid.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable iscsid

Vamos ahora a crear, o comprobar, nuestro InitiatorName, editaremos el siguiente fichero:

sudo vi /etc/iscsi/initiatorname.iscsi

En mi caso ya tiene uno creado, retro con su 1993 y su todo. El nombre es lo de menos, con tal de que sea único, yo lo he dejado por defecto, pero si vamos a desplegar varios proxies, es mejor editar el nombre un poco:

## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator.  The InitiatorName must be unique
## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames.
InitiatorName=iqn.1993-08.org.debian:01:af5bf2af245

Para que la sesión a las futuras LUN se conecte de manera automática, lo más seguro que queráis ésto, editaremos el fichero llamado /etc/iscsi/iscsid.conf y nos aseguraremos que en la sección de Startup settings nos queda así:

#*****************
# Startup settings
#*****************

# To request that the iscsi initd scripts startup a session set to "automatic".
 node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
# node.startup = manual

# For "automatic" startup nodes, setting this to "Yes" will try logins on each
# available iface until one succeeds, and then stop.  The default "No" will try
# logins on all available ifaces simultaneously.
node.leading_login = No

Como veis he descomentado el node.startup, y he comentado el node.startup = manual, sencillo.

Vamos a reiniciar el servicio por si acaso:

service open-iscsi restart

Presentar nuestra LUN de NetApp a nuestros Proxies Linux

Por lo general, en NetApp y cualquier fabricante decente, tendremos que añadir los iSCSI Initiators en la web, a medida de seguridad para que no se conecte todo el mundo a unas LUN que son críticas, como son las que presentamos a VMware.

Dentro de nuestro ONTAP, en Storage – LUN, haremos click en el Mapped to Initiators:

Haremos click en Edit:

Y añadiremos el iSCSI Initiator que tanta gracia nos ha hecho antes, el que era 1993, etc. Os quedaría algo así, hacer click en Save:

Ya tenemos esta parte lista, vamos a nuestro Linux de nuevo. Si tuvieramos más Proxies, es el momento de añadirlos todos, claro.

Añadir nuestras LUN de NetApp al Proxy

De vuelta a nuestro Ubuntu 20.04, llega el momento de conectar esas fantásticas LUN a nuestro OS, recordar no formatearlas, ni iniciarlas, ni nada, solo los comandos que os muestro aquí, ni más ni menos 🙂

Con el siguiente comando podremos ver todas las LUN que está presentando el sistema NetApp. Cambiar la IP por la vuestra:

iscsiadm -m discovery -t st -p 192.168.100.236

Esto me ha devuelto una LUN:

192.168.100.236:3260,1026 iqn.1992-08.com.netapp:sn.812793a88c8611eb8a040050569080ec:vs.2

Fantástico, si tuviera más LUN, aquí me aparecerían todas. Ahora que conocemos la LUN, o LUNS que queremos, vamos a conectarnos a ellas, el comando muy sencillo, mezcla un poco de lo anterior, mirar que fácil:

sudo iscsiadm -m node -p 192.168.100.236 -T iqn.1992-08.com.netapp:sn.812793a88c8611eb8a040050569080ec:vs.2 --login

Como podéis ver, he usado la IP de mi NetApp, así como a la LUN a la que me quiero conectar. Si tuvieráis un montón de LUN y queréis conectaros a todas, usar esto:

sudo iscsiadm -m node -p 192.168.100.236 --login

El resultado de la operación es algo similar a esto:

Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.812793a88c8611eb8a040050569080ec:vs.2, portal: 192.168.100.236,3260] (multiple)
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.812793a88c8611eb8a040050569080ec:vs.2, portal: 192.168.100.236,3260] successful.

Podemos comprobar los nuevos discos con un típico fdisk -l , me aparece un nuevo disco en sdb:

Disk /dev/sdb: 13 GiB, 13958643712 bytes, 27262976 sectors
Disk model: LUN C-Mode      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 65536 bytes
Disklabel type: gpt
Disk identifier: 46D2AF85-985C-4998-B4C2-99970CAEE8D8

También con un comando más bonito, sudo lsblk -e7, os mostraría esto:

Hagáis lo que hagáis, no toquéis estos sdb, sdc, y similares, ya que son vuestros VMFS.

Configuración final en Veeam Backup and Replication

Ya nos queda poco, para forzar que el tráfico va por DirectSAN, a mi me gusta cambiar el transport mode y lanzar el trabajo, en el proxy, o proxies que tenemos configurados haremos lo siguiente:

Si queremos, de manera opcional, podemos también decir que solo procese VMs que se encuentren en los Datastore que queramos, esto sería perfecto si tenemos unos proxies dedicados para éstas cargas de trabajo que sabemos que solo procesan VMs de determinados datastores: Lanzamos el trabajo, y vemos que usa [san], y por lo general la velocidad tendría que ser muy buena:

Eso es todo amigos, echar un vistazo a la entrada de cómo crear el repositorio linux, que tiene un vídeo también en Castellano y mucha más información para comenzar. Espero que os guste.