Saludos amigos, desde hace mucho tiempo me encuentro cada vez en más lugares la necesidad de los Departamentos de IT de ofrecer la copia de seguridad (Backup) como servicio internamente al resto de departamentos.
Esto quiere decir que los responsables de IT y de Backup crean toda la infraestructura y posibilidades de backup, y son los diferentes responsables de cada aplicación o grupo de aplicaciones los responsables.
Crear un plan de políticas SLA acorde con nuestro negocio
Lo primero que tendremos que hacer es sentarnos y crear estos planes de SLA, acorde con las necesidades y obligaciones de nuestra empresa. Por ejemplo, imaginemos que tenemos tres diferentes niveles de protección para nuestro entorno.
BACKUP-SLA-30-24
Esta política, seguramente sea de las más típicas en cualquier empresa, se trata de realizar un Backup cada 24 horas, con una retención durante 30 días. En el repositorio tendríamos algo tal que así:
Nota: El tema de las synthetic full es algo que yo recomiendo, pero es opcional, podrían ser Active Full.
BACKUP-SLA-30-06
Esta política realiza un Backup cada 6 horas, con una retención durante 30 días. En el repositorio tendríamos algo tal que así:
Nota: El tema de las synthetic full es algo que yo recomiendo, pero es opcional, podrían ser Active Full, al ser cada 6 horas, yo recomendaría una synthetic para compactar todo cada noche, de ahí la synthetic cada 4 puntos.
BACKUP-SLA-30-01
Esta política, que consideraríamos nuestro nivel más crítico, se trata de realizar un Backup cada hora, con una retención durante 30 días. En el repositorio tendríamos algo tal que así:
Nota: El tema de las synthetic full es algo que yo recomiendo, pero es opcional, podrían ser Active Full, al ser cada hora, yo recomendaría una synthetic para compactar todo cada noche, de ahí la synthetic cada 24 puntos.
Topología de un entorno de Backup basado en políticas SLA
La mayor ventaja que esta manera de proteger el entorno tiene, es que delegamos completamente la responsabilidad de las máquinas a proteger, con la retención que se necesiten a los responsables de dichos sistemas, el diseño para un entorno mediano grande podría ser así:
En el que encontramos que con un solo servidor (VM) de Veeam Backup & Replication, y diferentes Proxies dedicados a cada Tag es suficiente. En el caso más exigente que es el backup de cada hora, tendremos que contar con un server físico conectado a la SAN de producción, conectado a un Repositorio de tipo appliance de altas prestaciones o a discos rápidos, o un RAID 10 o 60.
Opcionalmente podremos tener VMs para para Enterprise Manager y otra para Veeam ONE
Arquitectura escalable y diseño de la Infraestructura de Veeam Backup & Replication
Para diseñar un servicio como éste, no podemos usar un proxy virtual con un backup repository y pensar qué ya tenemos todo listo (por poder se puede, pero no lo recomiendo).
Para diseñar de manera correcta el entorno vamos a tener varios elementos en cuenta:
- El número total de tareas concurrentes que queremos asignar en un principio
- El número total de extents que formarán parte de nuestro Scale-Out Backup Repository
- La frecuencia con la que se ejecutan las tareas, contra más frecuente menos ventana de trabajo tenemos con lo que más proxies tendremos que meter para procesar más tareas concurrentes, y los repositorios tendrán que tener más ancho de banda (mejores discos y mejores conexiones)
Vamos a pensar que tenemos varios servidores genéricos con almacenamiento como Backup Repositories.
BACKUP-SLA-30-24
Esto quiere decir, que por ejemplo para dar servicio a digamos, 100VMs con 2 VMDK (2 discos) cada una con un tamaño medio de 300GB por cada VM en total cada 24 horas, podríamos diseñar algo como lo siguiente:
Que en números serían:
- 2x Virtual Proxy
- 4vCPU
- 8GB RAM
- VMXNET3 y PVSCSI
- 80GB para OS (Windows Server 2016/2019)
- Nuestro Backup Repository tendría que tener los siguientes recursos (más o menos):
- 4 Cores o más
- 10GB RAM
- Copia Full MB/s: 200,25
- Copia Incremental MB/s: 20,02
Nada muy grande o complejo, ya que son unas copias sencillas.
BACKUP-SLA-30-06
Esto quiere decir, que por ejemplo para dar servicio a digamos, 50VMs con 2 VMDK (2 discos) cada una con un tamaño medio de 300GB por cada VM en total cada 24 horas, podríamos diseñar algo como lo siguiente:
Que en números serían:
- 3x Virtual Proxy
- 4vCPU
- 8GB RAM
- VMXNET3 y PVSCSI
- 80GB para OS (Windows Server 2016/2019)
- Nuestro Backup Repository tendría que tener los siguientes recursos (más o menos):
- 6 Cores o más
- 14GB RAM
- Copia Full MB/s: 400,50
- Copia Incremental MB/s: 40,05
Aquí ya aumenta el número de Proxies, además de incremental el ancho de banda que el Backup Repositorio tiene que darnos.
BACKUP-SLA-30-01
Nuestras aplicaciones más críticas, lo más seguro es que queramos usar el SAN Transport Mode (require eun proxy físico) Y Backup from Storage Snapshots siempre que sea posible.
Por ejemplo para dar servicio a digamos, 20VMs con 2 VMDK (2 discos) cada una con un tamaño medio de 300GB por cada VM en total cada 24 horas, podríamos diseñar algo como lo siguiente:
Que en números serían:
- Nuestro Proxy, que es físico esta vez requiere lo siguiente:
- 32 Cores o más
- 64GB RAM o más preferiblemente
- VMXNET3 y PVSCSI
- 80GB para OS (Windows Server 2016/2019)
- Nuestro Backup Repository tendría que tener los siguientes recursos (más o menos):
- 20 Cores o más
- 128GB de RAM o más
- Copia Full MB/s: 961,19
- Copia Incremental MB/s: 96,12
Al ser lo que más recursos consume, en este caso estaríamos hablando de discos sólidos si fuera posible, o con un RAID 10, 60, o similar para acelerar la escritura, además el proxy físico tiene que ser potente para ejecutar cuantas más tareas concurrentes posibles, mejor.
Cómo crear nuestras política de SLA en VMware vSphere
Desde vSphere, nos iremos hasta el menú, Tags & Custom Attributes:
En Categories, crearemos una nueva:
Llamaremos a esta categoría BACKUP, además de introducir una descripción para la misma, y seleccionar donde se puede aplicar esta categoría, en mi caso solo en algunos componentes:
Ya de vuelta a la sección de Tags, vamos a crear las que correspondan:
BACKUP-SLA-30-24 (30 días de retención, cada 24 horas)
Por ejemplo, vamos a crear nuestra primera Tag que será usada como política de SLA para crear backups cada 24 horas, con 30 puntos de restauración:
BACKUP-SLA-30-06 (30 días de retención, cada 6 horas)
Vamos a crear ahora la segunda Tag que será usada como política de SLA para crear backups cada 6 horas, con 30 puntos de restauración:
BACKUP-SLA-30-01 (30 días de retención, cada 1 hora)
Por último, la última Tag que será usada como política de SLA para crear backups cada 1 hora, con 30 puntos de restauración:
Es todo por ahora en esta primera parte de esta serie de blogs sobre políticas SLA para crear Backups, os dejo la serie completa:
- Veeam: Cómo diseñar e implementar un sistema de Backup basado en políticas SLA – Parte I – Diseño, Arquitectura y creación de Tags en vSphere
- Veeam: Cómo diseñar e implementar un sistema de Backup basado en políticas SLA – Parte II – Creación de las políticas en Veeam Backup & Replication
- Veeam: Cómo diseñar e implementar un sistema de Backup basado en políticas SLA – Parte III – Asignando vSphere Tags a los grupos de aplicaciones
- Veeam: Cómo diseñar e implementar un sistema de Backup basado en políticas SLA – Parte IV – Vistazo rápido y creación de reportes de las políticas de Backup
- Veeam: Cómo diseñar e implementar un sistema de Backup basado en políticas SLA – Parte V – Vigilando el entorno de Veeam Backup & Replication con Veeam ONE
WOW, super valiosa esa información Jorge, realmente de calidad, lo aprecio mucho y lo estaré incluyendo en mi arsenal de conocimiento para las implementaciones que tenga a futuro, la verdad está genial.