Veeam 13.1 puede respaldar las VMs de OpenShift Virtualization desde la misma consola que tu equipo ya usa, sin instalar un agente dentro del guest. Te muestro la arquitectura en un solo diagrama: cinco componentes (dos de ellos nuevos) y los cinco pasos que sigue un job de backup entre ellos.
Los componentes
VBR Server: el que da las órdenes
- Qué es: tu servidor de Veeam Backup & Replication de siempre, físico o virtual.
- Qué hace: guarda la configuración, programa los jobs, asigna recursos y coordina cada backup y cada restore. Además funciona como backup proxy de uso general, así que puede mover datos hacia y desde los repositorios por su cuenta.
- Dónde está en el diagrama: arriba a la izquierda, alimentando al plug-in.
- Modelo mental: la torre de control. Decide qué y cuándo; no lee los discos de las VMs.
Veeam Plug-in for KubeVirt: el traductor
- Qué es: la capa de integración entre VBR y todo lo que es OpenShift Virtualization.
- Qué hace: permite que el servidor de backup se conecte a un clúster de OpenShift Virtualization y ejecute tareas de protección de datos y recuperación ante desastres sobre sus recursos.
- Dónde está: todavía del lado de Veeam, pero es el componente que baja hasta el clúster (la flecha verde que entra al Veeam KubeVirt Proxy).
- Modelo mental: un despachante bilingüe. VBR habla de «jobs y repositorios»; el clúster habla de «pods y PVCs». Acá es donde se hace la traducción.
Veeam KubeVirt Proxy: el residente dentro del clúster
- Qué es: un contenedor efímero que vive en un pod dentro del clúster protegido.
- Qué hace: procesa las cargas de backup cuando los datos se mueven hacia y desde los repositorios.
- Reglas de juego: exactamente un proxy por clúster protegido. Si tenés tres clústeres, desplegás tres proxies, y un solo VBR se puede conectar a todos.
- Dónde está: a la izquierda de la caja de OpenShift, conectado a KubeVirt (azul) y al plug-in (verde).
- Modelo mental: el capataz de obra. Es la única presencia permanente de Veeam en tu clúster, y es el que contrata a los trabajadores que vienen a continuación.
VKP Data Mover: el trabajador temporal que hace el trabajo pesado
- Qué es: un servicio en un pod que el proxy despliega temporalmente para un job.
- Qué hace: en un backup, lee los datos de los discos de la VM protegida y los envía al repositorio; en un restore, lee del repositorio y escribe en el destino.
- Dónde está: en el centro-derecha del diagrama, uno por cada VM que se procesa (Data Mover 1 → VM1, Data Mover 2 → VM2), cada uno conectado a los PVCs de su VM.
- Modelo mental: contratistas que llegan para el turno y se van. Es el pod que tu equipo de plataforma va a ver aparecer y desaparecer durante la ventana de backup, y la razón por la que no hace falta un agente dentro del guest.
Backup Repository: donde todo termina
- Qué es: el almacenamiento donde VBR guarda los backups de tus VMs de OpenShift Virtualization.
- Qué hace: ser el destino. Nada exótico: es el mismo concepto de repositorio que ya usás.
- Dónde está: arriba a la derecha, recibiendo las flechas verdes que salen directo de los data movers.
- Modelo mental: el depósito. El mismo depósito que usás para los backups de vSphere y Hyper-V, y ese es justamente el punto.
Leer el diagrama como una línea de tiempo
Si seguís las flechas en orden, el dibujo deja de ser una topología y se convierte en una secuencia:
- VBR le pasa el job al plug-in.
- El plug-in se comunica con el proxy dentro del clúster.
- El proxy levanta un data mover por cada VM y apunta cada uno a los discos de esa VM a través de KubeVirt.
- Cada data mover envía los datos directo al repositorio.
- Cuando termina el job, los data movers desaparecen; el proxy se queda para la próxima.
Dos de esos pasos corren completamente dentro de OpenShift, cerca del storage. Esa es la decisión de diseño que vale la pena recordar: el servidor de backup orquesta, el clúster hace el camino de los datos.
Un saludo a todo el equipo de Veeam que lanzó este increíble plug-in 👏
Publicado originalmente en inglés en Veeam Community.
