Comenzamos este el inicio del 2023 con un articulo basado en cómo funciona el backup, más concretamente el backup en VMware.
El objetivo de este articulo es dar respuesta a las siguientes preguntas:
- ¿Qué hace internamente VMware?
- ¿Cómo hace VMware un backup de una aplicación que está dentro de una VM (Virtual Machine)?
- ¿Cuáles son los métodos de transferencia de datos?
- ¿Qué es el CBT?
Como bien sabemos, el proceso de backup es el siguiente:
El software de backup (Veeam, Commvault, etc) habla con VMware a través de su API. Este le pide a VMware que haga un snapshot de la VM, se realiza el backup de este snapshot al repositorio que sea (cabina de almacenamiento, cloud, HPE Storeonce) y el software revierte el snapshot para dejar la VM funcionando.
¿Qué hace internamente VMware?
Hay dos piedras angulares:
- SDK (Software Development Kit)
- VADP (Virtual advance data protection)
El software de backup conecta con VMware a través de SDK (Rest API) y dialoga con VMware (Vcenter, ESXi). Va a ser el encargado de pedir los request. El SDK obtiene los IDs de la VM que queremos proteger (ID VM, ESXi donde está la VM, el datastore donde está alojada la VM).
A continuación, comienza el dialogo interno en VMware. Se realiza la solicitud de poner la VM en modo consistente. Esta consistencia no la realiza el Vcenter, la realiza el ESXi. La consistencia comienza con un snapshot de VMware (señalar que no es lo mismo un snapshot de VMware que un snapshot a nivel de Hardware (cabina de almacenamiento)).
El software de backup puede requerir dos tipos de consistencia:
- Crash consistant
- Aplication consistant
Crash consistant: Snapshot a nivel de la VM. Es consistente a nivel de esa VM independientemente de lo que haya ocurrido dentro del Guess (Sistema Operativo). La aplicación que hay dentro de este Guess VMware ni la mira.
APP consistant: el software de backup hace un request de app-consistantacy y después hace un snapshot de la VM.
¿Cómo hace VMware un backup de una aplicación que está dentro de una VM?
En primer lugar, VMware llama a las VM-Tool de la VM. Es obligatorio que estén instaladas.
Hay dos tipos de consistencia dentro del Aplication consistant:
- Microsoft: VSS (sistema de snapshot dentro del SO)
- Linux: Scrips Pre y Post (comandos RMAN)
Una vez ya tenemos la consistencia dentro de la VM, el sistema “baja” y realiza el snapshot de VMware de la propia VM. Hemos conseguido consistencia a nivel de la aplicación y consistencia a nivel de la VM.
Pero ¿qué es lo que pasa internamente cuando VMware hace un snapshot de una VM?
VMware coge los discos vmdk y hace un commit de todo lo que está en memoria y lo escribe en disco. Normalmente la VM esta encendida. VMware pone los vmdk en read only y todas las IO nuevas que llegarían al vmdk las desvia a unos ficheros que son .snap.
Todos los cambios que ocurran durante la fase de backup se acumulan aquí. Cuando el backup termina, es el propio VSphere el que vuelca los cambios que están en el .snap al vmdk.
Cuando hacemos un snapshot a nivel de VM el software de backup requiere consistencia de esta VM y solo nos llevamos el timestamp consistente, el vmdk (baseline snap). Todo lo que ocurre en la memoria de la VM mientras dura el backup no está siendo protegido porque está guardando estos cambios en el .snap. En el caso de querer hacer un recovery, lo que recuperamos es el baseline snap.
Hasta este este punto es cómo funciona VMware, ahora hay que llevarse el backup al repositorio. Aquí empieza el dialogo con la API de backup.
A continuación, se devuelve control al software de backup a través del SDK. Es en este momento cuando el software de backup empieza realmente a hacer la transferencia de datos.
¿Cómo hace esta transferencia? A través de la API VADP. El VADP vuelve a hablar con el Vcenter y con el ESXi.
Para VMware el API es todo (SDK y VADP) pero cuando el software de backup se refiere a la API se refiere al VADP.
En el caso del Backup & Recovery de HPE el orquestrator habla con el SDK y el Gateway con el VADP. En Commvault al agente de backup que habla con el mundo virtual se le llama VSA (Virtual Server Agent). Puede estar junto con un media agent, junto con un ComServ o independiente. En Veeam es lo que llaman los Proxys.
¿Cuáles son los métodos de transferencia de datos?
Es el software de backup el que dice como se van a transferir los datos al repositorio. El Vcenter y el ESXi se coordinan para la metodología de transporte. Le dicen al VADP como pedir los ficheros, las cabeceras, etc. Es decir, como posicionarse dentro del VMFS para protegerlo.
Tenemos tres metodologías de transporte de datos:
- SAN
- NBD
- Hot Add
El método SAN (típico en cabinas de almacenamiento) requiere que los datastores (VMFS) no solo estén conectados a los ESXi, sino también tienen que estar conectados a las VM donde están los Proxys (Media Server, media agent, gateways). Estos proxys son VM Windows y necesitan una HBA (Host Bus Adapter) para estar conectados a la SAN (red de almacenamiento). Es el método de transporte más eficiente, el que más rendimiento obtiene. Es importante recordar que en VMware no podemos virtualizar una HBA, tiene que ser física. Este método también es válido para iSCSI.
El método NBD (Network base Daemon) es un método de transferencia a través de la red (Network). Es el más seguro, pero es el más lento.
El ESXi, a través del VMkernel (gestión, primero en dar de alta) manda los datos a través de ethernet a los media agent o media servers. Este método consume recursos de CPU, RAM del ESXi ya que es el que trabaja. Es más seguro ya no presenta ningún volumen a nadie. Es el que se usa en HPE Simplivity, Vsan cuando usamos Veeam, Commbault, etc. Debido al bajo rendimiento se recomienda interfaces de 10/25GbE.
El método Hot Add. La parte software (VSA Agent, proxy agent) que habla con la API de VMware (SDK y VADP) consiste en una VM que esta alojada en un ESXi. Esta VM es necesario que este instalada en cada host ESXi que tenga el usuario.
Lo que hace Hot Add es congelar las VM al igual que los otros métodos, pero a la hora de procesar el dato en lugar de pasarlo por la SAN o en modo NBD sigue el siguiente proceso:
- Coge cada VM, abre le VM folder (donde están los .vmdk), coge este fichero y en caliente se conecta a la VM que esta alojada en el ESXi (mount). Este ya es consistente y está en read only.
- A través del VADP hacemos el backup al repositorio que consideremos.
- Cuando acaba de realizar el backup de todo el disco lo desconecta (umount) y se va al siguiente. De ahí el nombre Hot Add. Aquí es donde se producen los fallos. Como el disco no se desmonta, el .vmdk no se elimina (snapshots encolados).
La siguiente pregunta que se hace el software de backup es ¿Qué me llevo?
Si es un full backup se lleva todo, pero si es un incremental o diferencial se lleva solo lo que ha cambiado. Como antes, el software de backup habla con el Vcenter y el ESXi a través del VADP.
Si tenemos un Backup incremental o diferencial entra en juego el CBT (Change block tracking). Esta es la tecnología que usa el B&R de HPE.
¿Qué es el CBT?
Es un mapa de cambios. No hay que recorrer todo el .vmdk para identificar los bloques que han cambiado, es el propio ESXi el que detecta que ha cambiado. Es como una especie de escaneo del disco.
Una vez que la transferencia de los datos se ha llevado a cabo, el software de backup se lo comunica al Vcenter y al ESXi a través del SDK. El software de backup da la tarea por finalizada.
Ahora es VMware quien se encarga de eliminar todos los snapshots tanto en el Guess como en la propia VM. Es aquí donde se producen más errores y crasheos. Los snapshots se pueden quedar acumulados en VMware ya que hay bastantes cambios y no consolidan bien.
La solución a este problema es que la ventana de backup sean segundos/minutos para que no haya tanto cambio. Muy difícil sin la tecnología de los arrays (cabinas) de almacenamiento.
En un entorno en el que tenemos muchas transacciones (por ejemplo, un Oracle) es necesario que el software de backup no solo hable con VMware, sino que también hable con la cabina de almacenamiento, el hardware array.
El software de backup habla con VMware para hacer un snapshot consistente, VMware da el ok, el software habla con el array y el tiempo que tarda una cabina en hacer un snapshots de un volumen son segundos. La cabina da el ok al software de backup y tenemos un hardware snapshot consistente.
El tiempo que tarda todo este proceso es muy pequeño (1 min como mucho) por lo que los cambios que ha habido en los snapshots de VWware ( Guess o en la VM) son muy pocos y no tenemos el problema de acumulación de snapshots.
Entonces, ¿cómo transportamos los datos al repositorio de backup?
Quiero recordar que el snapshot está en la cabina de almacenamiento. Es el software de backup el que monta ese snapshot en un ESXi (servidor de backup) y a partir de ahí utilizamos los métodos de transferencia que hemos visto (SAN, NBD o Hot Add).
Las ventajas que tiene esto: todas las VM que tenemos en el disco que hemos montado a través del snapshot de Hardware están apagadas con lo cual no hay que hacer consistencia de ningún tipo (ya son consistentes en sí mismas).
Cuando la transferencia de esos datos llega a su fin solo tenemos que decirle al ESXi que haga un umount del snapshot. El tiempo de esta transferencia de los datos puede ser elevado (2 horas), pero ya no te afecta al VMware.
La pega de esto es que hacemos un snapshot de todo un volumen. Si queremos hacer un snapshot de una determinada VM que esté en un volumen en principio no podríamos. Pero los softwares de backup tienen una tecnología que se llama el autodiscover que habla con el VMware y descubre todas las VM del entorno. Con esta tecnología también podemos hacer un autodiscover pero por datastore y nos descubre las VM de este. Con esto podemos hacer políticas de backup que tomen ciertas VM de un cierto Datastore.
Espero que os haya parecido interesante y nos vemos en futuros artículos.