Saludos amigos, hoy os traigo una entrada muy interesante. Se que muchos de vosotros estáis ejecutando VMs que se encuentran en un entorno QNAP o similares. Para proteger todas estas VMs con Veeam de la mejor manera posible, Veeam tiene el transport mode llamado Direct SAN Access.
¿Qué es y cómo funciona el modo de transporte de Veeam Direct SAN Access?
El modo de Direct SAN es el que Veeam siempre recomienda para obtener el mejor resultado cuando protegemos nuestras VMs, es el que más trabajo tiene de configurar, pero como menciono, también el que nos da mejor resultado.Por supuesto, una de las ventajas mas grandes frente por ejemplo al modo Network, es que no saturamos para nada la red de gestión de VMware, cosa que si hacemos si estamos usando el modo Network.
Si viéramos un diagrama rápido podríamos ver que funciona de la siguiente manera:
El proceso de recuperación de datos en modo de Direct SAN Access incluye los siguientes pasos:
- El Veeam proxy envía una petición al host ESX(i) para localizar la VM necesaria en el almacén de datos (1).
- El host localiza la VM y recupera metadatos sobre la disposición de los discos virtuales en la SAN (es decir, direcciones físicas de los bloques de datos) y envía estos metadatos al Veeam proxy (2, 3, 4).
- El Veeam proxy utiliza los metadatos para copiar bloques de datos directamente desde la SAN y los envía al destino (5, 6).
El Veeam proxy que utiliza el modo de acceso directo SAN debe conectarse directamente a la estructura SAN. El procesamiento de la VM fallará si no se configura una conexión SAN directa o si no está disponible cuando se inicia el trabajo.
QNAP y vSphere Storage APIs Array Integration (VAAI)
Antes de continuar con los pasos de configuración, un poco más de teoría. Desde la versión de vSphere 4, tenemos a nuestros alcance esta tecnología.
En un entorno virtualizado, las operaciones de almacenamiento han sido tradicionalmente caras desde el punto de vista de los recursos. Funciones como la clonación y los snapshots de las VM pueden ser realizadas más eficientemente por el almacenamiento que por el host. VMware vSphere Storage APIs Array Integration (VAAI), también conocido como aceleración de hardware o APIs de descarga de hardware, son un conjunto de APIs que permiten la comunicación entre los hosts VMware vSphere ESXi y los dispositivos de almacenamiento. Las APIs permiten al host ESXi descargar ciertas operaciones de almacenamiento en el array, lo que reduce la sobrecarga de recursos en los hosts ESXi y puede mejorar significativamente el rendimiento para operaciones de almacenamiento intensivo como la clonación de almacenamiento, el zeroing, etc. El objetivo de VAAI es ayudar a los proveedores de almacenamiento a proporcionar asistencia de hardware para acelerar las operaciones de E/S de VMware que se realizan de forma más eficiente en el hardware de almacenamiento.
QNAP incluye soporte directo de VAAI para iSCSI, ya que VMware incluye un driver universal. Con lo que si estás pensando en usar un modo de almacenamiento para QNAP, yo recomiendo iSCSI. Si estás pensando en usar NFS, QNAP tiene un plugin que tendremos que instalar en todos los Hosts de ESXi, no he conseguido que funcione en vSphere 6.7.
Configuración iSCSI en QNAP y vSphere 6.7
No voy a extenderme mucho en estos pasos, ya que os enseñé cómo configurar todo esto en el siguiente post:
Una vez tenemos nuestros volúmenes iSCSI, podemos seguir configurando nuestros elementos
Configuración de Veeam Proxy para Direct SAN Access (iSCSI)
Ya tenemos todo listo en nuestra infraestructura, pero nos queda un punto muy importante, queremos que nuestro Proxy sea capaz de realizar el backup desde la SAN, como vemos en el siguiente diagrama:
Si nuestro Proxy fuera virtual, lo primero será añadirle una tarjeta de red, VMXNET3, en la red SAN:
En esta tarjeta de red, pondremos nuestro Proxy una IP y, como buena práctica, activaremos Jumbo Frames ya que todo mi entorno de SAN funciona en Jumbo Frames:
Para comprobar que nuestro entorno soporta Jumbo Frames, lanzaremos un ping especial con 8492 bytes a nuestro QNAP:
ping 192.168.100.50 -f -l 8492
Pinging 192.168.100.50 with 8492 bytes of data:
Reply from 192.168.100.50: bytes=8492 time<1ms TTL=64
Reply from 192.168.100.50: bytes=8492 time<1ms TTL=64
Reply from 192.168.100.50: bytes=8492 time<1ms TTL=64
Reply from 192.168.100.50: bytes=8492 time=1ms TTL=64
Ping statistics for 192.168.100.50:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Lo siguiente será mapear los iniciadores iSCSI de QNAP a nuestro server, como uso Windows Server 2016 no hay muchos problemas en que los VMFS van a ser escritos o corrompidos, pero si usaramos Windows Server 2008, tener cuidado y aseguraros que los iSCSI y discos que montamos están en solo lectura para Windows. En Windows Server 2016 abrimos el iSCSI Initiator, ponemos la IP de nuestra SAN iSCSI y le damos a quick connect, nos mostrará las las LUN, conectamos las que tengamos que proteger VMs dentro:
Cuando mapeamos la LUN, podremos ver que está en formato solo lectura:
Como buena práctica, yo recomiendo forzar el modo Direct SAN Access si queremos usarlo y tenemos todo bien configurado, desde nuestro consola de Veeam, editaremos nuestro Proxy:
Editaremos el Transport mode, que suele estar en automático: 
Como podéis ver, he marcado Direct storage access y deshabilitado que salte a modo Network si algo falla, de esta manera puedo forzar que o se hace por SAN o falla: 
El trabajo comenzará, y podremos ver que se está ejecutando en modo SAN, lo cual quiere decir que todo está bien configurado, el trabajo me ha dado una velocidad de 79MB/s:
He lanzado el mismo trabajo en modo Network, NDB como podéis ver aquí, y me ha dado un tiempo de 57MB/s, lo que quiere decir que el modo Direct SAN Access me ha dado casi un 30% mejor rendimiento.
Nada más amigos, espero que os haya gustado este post y os haya resultado útil, siempre que podáis, elegir Direct SAN Access para vuestras copias de Veeam, ganaréis en rendimiento en general y velocidad, e incluso seguridad al realizarse todo mediante esa red SAN.
Leave a Reply