El diseño óptimo para alcanzar RTPOs de 15 minutos con Veeam Backup & Replication

julio 20, 2016 — por Albert Gris0

main

Assoc. Cat. VirtualitzacióCloudVeeamVirtualizacionVMware

El diseño óptimo para alcanzar RTPOs de 15 minutos con Veeam Backup & Replication

julio 20, 2016 — por Albert Gris0

En mi post de la semana pasada presenté una estrategia para nuestros circuitos de backups que servía para alcanzar niveles de protección de datos que se podían ajustar a nuestras necesidades.

Estas políticas de almacenamiento de copias que obtendremos mediante por ejemplo esta metodología, nos sirven para cubrir parte de los objetivos de nuestros backups. Aún así, igual de crucial será el diseño en el que basemos nuestra infraestructura.  En este post intentaré resumir qué posibilidades tenemos en este sentido para alcanzar los objetivos más comunes en este tipo de proyectos.

La idea en este caso es basar la arquitectura en niveles de storage, cada uno aportando sus beneficios de manera que en global tengamos una infraestructua capaz de dar respuesta a cada reto que se nos presente en este aspecto.


Para empezar, nos centraremos en los objetivos a los que intenta dar respuesta este diseño:

  • RTPOs más bajos: són las métricas más importantes al afrontar prácticamente cualquier proyecto de este estilo, pero veamos cuales son los problemas más comunes para reducir estos tiempos: Para el RPO (el tiempo que pasa entre copias), normalmente el problema está, no en la ventana de backup en sí, sino en el impacto que genera el proceso en la máquina. Es por eso que el RPO más común en backups son 24 horas, aprovechando las horas nocturnas de cómo ventana de Backup. Reducir el RTO consiste en hacer más rápida la restauración del servicio una vez declarado el desastre. Es por eso que aquí el reto a superar es básicamente tener una tasa de transferencia desde el repositorio al almacenamiento principal lo más rápido posible.
  • Rollbacks/DRP: En general, hay dos grandes tipos de copias que responden a los distintos tipos de “desastres”. Normalmente, habrá copias de rollback con las que querremos recuperar en la mayoría de los casos ficheros  y no máquinas enteras, de manera poco disruptiva y generalmente debido a problemas de software. Con este planteamiento buscamos poca profundidad de retención (3 días por ejemplo), poco RPO y restauración muy rápida. En DRP sin embargo, queremos asegurarnos de estar protegidos ante desastres físicos en nuestro datacenter, por lo que interesa almacenar los backups en localizaciones remotas y cumpliendo con con retenciones mucho más grandes.
  • Cada vez tenemos que guardar más ficheros: O nuestro histórico de backups va a crecer o querremos aumentar retenciones de nuestros rollbacks. Con el diseño que proponemos, los distintos niveles suponen también distintos precios por GB de manera que nos facilitará encontrar la distribución que mejor se ajuste a nuestros requisitos.
  • Rebajar las posibilidades de pérdida de datos

Siendo estos los objetivos a cumplir, veamos qué niveles proponemos y como los configuramos con Veeam Backup & Replication:

  • Nivel 1

Este nivel consiste en storage rápido y con acceso rápido a los datos en origen.  Mi ejemplo favorito es un buen servidor físico con HBAs del protocolo de SAN que utilicemos para conectar directamente a la cabina, un RAID10 de discos NLSAS (o de mayor rendimiento si se pudiera) y dimensionado normalmente para almacenar retenciones de 1 a 2 semanas. Este nivel nos da la opción de:

    • Rebajar RPOs: Con discos de acceso rápido y visibilidad directa y rápida de los datos en orígen por SAN, la duración del backup será corta y por lo tanto, el snapshot que generará Veeam en la máquina no tendrá poco tiempo para crecer. Si además le añadimos la posibilidad de usar snapshots de cabina, el impacto en orígen será mínimo y nos permitirá hacer copias con mayor recurrencia. Dependiendo de qué tipo de discos dispongamos y sobretodo del tamaño de incremental que movamos, usar Forward Incremental y no Reverse Incremental aún hará más rápido el proceso, pues este último supone unas 3 veces más carga de I/O a los discos de repositorio.
    • Rebajar RTOs: Usar un servidor Windows como repositorio, nos permite aprovechar la restauración más rápida de Veeam, Instant VM Recovery, que presenta los discos de las VMs directamente desde el repositorio a los ESXis mediante NFS. Restaurar en el storage de origen también será muy rápido, pues podremos usar la SAN de nuevo para mover los datos.

De esta manera, con este nivel cumplimos con la posibilidad de poder hacer rollbacks de manera eficiente y sobretodo, rebajar muchísimo los RTPOs.

  • Nivel 2

Uno de los principales problemas del primer nivel es que al ser storage rápido, será bastante caro. Como el objetivo de este no es una gran retención, no hace falta que consumamos muchísimo espacio “caro”. Para poder cumplir con estas retenciones, surge el siguiente nivel. Este podría ser un NAS (con deduplicación que permita optimizar el espacio quizás), con un buen nivel de precio por GB usando RAID5 por ejemplo, y con el que ya cumplamos una retención de quizás un mes.  Su ubicación no debería ser cercana al datacenter como el nivel 1, pues no se espera tan buena tasa de transferencia. La mejor propuesta sería ubicarlo en el mismo edificio pero fuera del CPD. Podemos usar los backups generados en nivel 1 para moverlos a nivel 2 mediante Backup Copy Jobs. De esta manera, no tocamos otra vez origen y nos ahorramos impacto en producción.

  • Nivel 3

El último nivel. Será el que nos permita guardar mayor retención y sobretodo, con poca posibilidad de pérdida. Para cumplirlo, su naturaleza debería ser totalmente offsite. Con Veeam, podríamos usar copias a cinta que luego podremos llevarnos offsite o directamente usar Cloud Connect y lanzar backups a otro datacenter directamente. Aquí podremos almacenar gran nivel de copias por lo que cumpliremos el objetivo de guardar mayor retención y sobretodo, minimizar las posibilidades de pérdida de datos distribuyendo las copias entre medios distintos y ubicaciones distintas tal y como vimos en el otro post.

Dejar comentario

Tu dirección de correo no será publicada Los campos requeridos están marcados con *

10 + diecinueve =