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:
- El proxy de copia de seguridad envía una solicitud al host ESXi para localizar la VM necesaria en el almacén de datos.
- El host ESXi localiza la VM.
- Veeam Backup & Replication activa VMware vSphere para crear una instantánea de la VM.
- 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).
- El host ESXi envía los metadatos al proxy de copia de seguridad.
- 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.
- 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:
## 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.
Presentar nuestra LUN de EMC Unity a nuestros Proxies Linux
Por lo general, en EMC Unity 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 nuestra Unity, en Storage – Block, haremos click en la LUN y en el icono de Editar:
Haremos click en Host Access, y añadiremos uno nuevo:
Haremos click en Add Host:
Introduciremos un nombre descriptivo y una IP de nuestro Proxy: 
En la siguiente ventana es muy probable que nos detecte el iSCSI Initiator, si no, siempre apodemos ponerlo a mano, recordar aquel nombre con el 1993 que hemos visto antes: 
Ya cuando hemos terminado, lo seleccionamos y hacemos click en OK: 
Por último seleccionamos el nuevo Host que hemos creado y hacemos click en Close: 
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 EMC Unity 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 EMC Unity. Cambiar la IP por la vuestra:
iscsiadm -m discovery -t st -p 192.168.100.17
Esto me ha devuelto una LUN:
192.168.100.17:3260,1 iqn.1992-04.com.emc:cx.virt204595qmet.a3
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.17 -T iqn.1992-04.com.emc:cx.virt204595qmet.a3 --login
Como podéis ver, he usado la IP de mi EMC Unity, 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.17 --login
El resultado de la operación es algo similar a esto:
Logging in to [iface: default, target: iqn.1992-04.com.emc:cx.virt204595qmet.a3, portal: 192.168.100.17,3260] (multiple) Login to [iface: default, target: iqn.1992-04.com.emc:cx.virt204595qmet.a3, portal: 192.168.100.17,3260] successful.
Podemos comprobar los nuevos discos con un típico fdisk -l , me aparece un nuevo disco en sdb:
Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 sectors Disk model: VRAID Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 8192 bytes / 4194304 bytes Disklabel type: gpt Disk identifier: 889DC0B4-8EC9-4916-9B26-C15013B3B952 Device Start End Sectors Size Type /dev/sdb1 2048 209715166 209713119 100G VMware VMFS
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.
Leave a Reply