En mi rol aquí en Veeam, hablo con muchas personas de diferentes industrias alrededor del mundo. La virtualización es una gran comunidad en el sentido en que podemos hacer esto, y rápidamente convergemos a discutir sobre asuntos similares. Afortunadamente, Veeam ayuda a resolver los problemas de estas personas en lo que a respaldar VMs se refiere.
A menudo surgen preguntas como “¿qué almacenamiento me recomiendas para los respaldos?” o “¿cuál es el mejor almacenamiento para los respaldos?”. Estas son preguntas difíciles de responder ya que hay muchos factores y prioridades únicas que nos inclinan a tomar una decisión sobre el almacenamiento. Frecuentemente, encuentro esas preguntas entre mis propias inquietudes, al efecto de: “¿Qué es más importante: espacio de almacenamiento, rendimiento o costo?”. Es una pregunta complicada de responder para su inversión en almacenamiento de respaldo para VMs. Por caso, todas las variables son, en efecto, igualmente importantes. Otras inquietudes surgen alrededor del protocolo y preferencias de marcas o conocimiento específico de productos, pero esta primera pregunta es la que conlleva mayor peso.
Cuando lanzamos la v7 de Veeam Backup & Replication, una de las iniciativas que Anton Gostev (VP de la Gerencia de Producto) y yo discutimos fue la necesidad de cambiar la forma en que la gente piensa sobre cómo el almacenamiento de respaldo se aprovisiona. Esto se alinea maravillosamente con las nuevas capacidades ahora disponibles en la versión 7 de respaldo de copia (Backup Copy Job) y aceleración de WAN integrada (Built-in WAN Acceleration) y el mensaje más amplio acerca de dar a la gente lo que necesita: respaldos rápidos, recuperaciones rápidas y la tranquilidad de que los respaldos se están escribiendo eficientemente fuera del sitio (off-site).
Podemos beneficiarnos enormemente si cambiamos la forma en la que implementamos el almacenamiento de respaldos para VMs.
Vamos al centro del asunto, ¿Cuál es la solución de almacenamiento óptima para respaldos? La arquitectura óptima de respaldos para VMs que propone Gostev es una forma muy flexible de alcanzar esas metas. La mejor parte es que sus prioridades, presupuestos, expectativas de recuperación y más, pueden todas alcanzarse con esta aproximación. Creo que un diagrama es apropiado, así que observemos la figura debajo:
Hay muchos procesos involucrados aquí, pero básicamente con esta aproximación (y hay muchas) los respaldos de Veeam pueden escribirse al almacenamiento de respaldo próximo al recurso de almacenamiento primario. Esto se puede dar de muchas formas: podría ser un sistema de almacenamiento tipo “primary-class” separado, un drive array separado en la SAN primaria o incluso un sistema de almacenamiento de alta velocidad corriendo SSDs. De esta manera se pueden adaptar muy bien la mayoría de las situaciones de restauración dado que posee unas cuántas características clave:
1. Alto rendimiento de almacenamiento: Al proveer almacenamiento rápido para su primera “línea” de respaldos se incrementa la velocidad de los respaldos y, aún más importante, de la recuperación. Con esta forma de hacer respaldos, todo comienza con un más alto rendimiento de almacenamiento; además, esto ayudará a alcanzar las expectativas de sus inversores con opciones de recuperación más rápidas.
2. Baja retención: Porque has aprovisionado un recurso de almacenamiento de alto rendimiento en el paso 1; esto significa que no podemos mantener el grueso de nuestros respaldos aquí. Especialmente cualquier punto de retención (como respaldo completo semanal, mensual o anual al estilo de retención GFS).
3. Es una fuente para el trabajo de copia de respaldo: las VMs se pueden escribir a un recurso de almacenamiento diferente (el de la derecha) tanto para protección fuera de sitio tanto como para retención adicional (como retención tipo GFS); y ese recurso de almacenamiento diferente puede ser un dispositivo de almacenamiento de rendimiento más lento.
Ahora tenemos literalmente cientos o quizás miles de maneras de rebanar esto e implementarlo. Más aún, si comenzamos a hablar acerca de una estrategia de uno-a-mucho, entonces en realidad tenemos muchísimos escenarios para discutir. Echémosle un vistazo a lo que todas esas capacidades hacen para mejorar el proceso de respaldo. En lo que se refiere a relativamente baja retención, hay menos puntos de restauración atravesándose, lo que mejora la performance del respaldo incremental. El alto rendimiento del almacenamiento también puede ayudar al rendimiento del respaldo incremental. Pero el mayor ahorro de tiempo viene con el trabajo de copia de respaldo. Esto escribirá los puntos de restauración de la VM fuera del sitio una vez que el respaldo de la VM se complete. Estos 3 puntos ayudan críticamente a abordar el deseo de respaldos más rápidos, restauraciones más rápidas y tener respaldos fuera de sitio.
Esta es una forma de abordar esta necesidad, pero, por supuesto, las necesidades de cada uno son diferentes. He hablado con algunas personas quienes ahora prefieren aprovisionar un LUN en el SAN primario para ese primer paso del proceso de respaldo. Siempre he sido un fan de la separación, pero al escuchar su diseño, tiene sentido. Una manera de diseñar alrededor de estas directrices es aprovisionar un LUN para ese primer repositorio de respaldo y luego dejar que el trabajo de copia de respaldo escriba puntos de restauración de la VM a múltiples recursos de almacenamiento (uno en sitio y otro fuera de sitio). Esto es importante dado que el primer sistema de almacenamiento puede tener poca retención y no poder proteger el sitio contra fallas. ¡Es un gran diseño!
Ahora, si uno de los repositorios va a mantener múltiples puntos de restauración, como los de la retención GFS que se incluye con la v7, la única forma práctica de implementar esto es con deduplicación. Para ponerlo de una manera sencilla: si mantenemos múltiples respaldos completos de control semanal, mensual, cuatrimestral, y anual, habrá un gran número de VBKs en el disco.
El sistema de almacenamiento deduplicado es otro tema que plantea un punto de discusión algo complicado. Las appliances de deduplicación tipo ExaGrid, Data Domain, Store Once de HP y otras son opciones válidas. Pero el software de deduplicación de Windows Server 2012 es también una solución; y todas las necesidades de cada quién son diferentes. Algo que he notado a través de los años aquí en Veeam es que hay muchas maneras de encarar el tema de la deduplicación, y cada appliance lo aborda de manera diferente. Un ejemplo son las appliances de duplicación de las series EX del ExaGrid, que matienen un “landing zone” del último perfil de la información en un estado completamente “hidratado”; esto permite restaurar operaciones para proceder a la velocidad de la network en lugar de estar “re-hidratando” bloques en un perfil enorme de información. Esto es importante para las VMs dado que hay una buena posibilidad de que surja una vasta cantidad de lecturas aleatorias (especialmente en tareas tales como recuperación instantánea de VM – Instant VM recovery). Para mayor información, asegúrense de bajar el reporte de laboratorio de ESG “Virtual Machine Backup Without Compromise”, donde los detalles de esta estrategia de deduplicación son medidos junto a los respaldos de Veeam.
Aprovisionar almacenamiento para respaldos es parecido a examiner la eficiencia del combustible para un vehículo: es la clásica situación donde el millaje puede variar. Todo se reduce a la pregunta acerca de qué es lo más importante: velocidad, ahorro de espacio y costo. Otras cuestiones surgen dado que las necesidades de cada quien no son las mismas.
¿Qué tips y trucos usaste en tu estrategia para aprovisionar almacenamiento de respaldos con Veeam y en particular ahora con la función de trabajo de copia integrado (Built-in Copy Job)? ¡Comparte tu comentario aquí debajo!
