La mayoría de las organizaciones no elige la dependencia de un appliance. Llegan a ella con una compra tras otra y se dan cuenta cuando llega el presupuesto de la tercera ampliación. Si tiene delante un presupuesto de renovación y se pregunta si ese incremento de capacidad es de verdad la única opción, aquí está la aritmética que hay detrás de esa sensación y lo que cambia cuando la capa de almacenamiento deja de ser el hardware.
Conviene separar dos cosas que se suelen mezclar. Un appliance como formato es una buena idea: dimensionado de antemano, con el software adaptado a la plataforma y rápido de poner en marcha. vStor se ofrece como appliance virtual precisamente por eso, y DPX es multifunción a propósito, en el sentido de appliance de backup específico (en inglés).
El problema es más concreto: un appliance de hardware de capacidad fija, en el que el fabricante decide cómo y cuándo se crece. Esa restricción aparece más tarde, y aparece en forma de aritmética.
La economía de comprar capacidad en escalones que fija el fabricante
Con la caja llegan cuatro restricciones:
- La capacidad viene en los incrementos que vende el fabricante, no en los que usted necesita.
- Las mejoras de rendimiento suelen significar otro presupuesto de hardware.
- El ciclo de renovación sigue la hoja de ruta del fabricante y no su plan de infraestructura.
- El crecimiento imprevisto obliga a ampliar solo para mantener la retención donde ya estaba.
Esto choca con un segundo hecho. La mayoría de los presupuestos de backup se mantienen o se reducen mientras crecen los datos que cubren. La respuesta del appliance de hardware a ese ajuste es comprar el siguiente incremento, lo que obliga a una compra grande aunque la carencia real sea pequeña o se limite a una sola carga de trabajo.
Lo incómodo es que esto llega a la vez que todo lo demás. A los equipos se les pide mejorar la capacidad de recuperación ante ransomware, ampliar la cobertura a más hipervisores, dar soporte a sedes periféricas y mantener los costes. Una plataforma de almacenamiento que solo crece mediante compras propietarias convierte cada una de esas peticiones en una solicitud de inversión.
Qué cambia cuando la capa de almacenamiento está definida por software
Catalogic vStor separa el software de almacenamiento de backup de la decisión sobre el hardware. Se despliega como appliance virtual o en un servidor físico, de modo que el repositorio se diseña en torno a sus datos y no en torno al catálogo de un producto.
| Hardware de capacidad fija | Definido por software | |
|---|---|---|
| La capacidad crece en | Incrementos del fabricante | Lo que usted pueda aprovisionar |
| Cambio de rendimiento | Nuevo presupuesto de hardware | Pasar a un almacenamiento más rápido |
| Sede remota | Rara vez se justifica | Despliegue a medida |
| La renovación depende de | La hoja de ruta del fabricante | Su propia planificación |
En la práctica significa almacenamiento más rápido bajo las cargas de trabajo con expectativas de restauración cortas, capacidad más barata para la retención larga y algo pequeño en una sede remota que nunca podría justificar su propio hardware. Los mismos controles de protección se aplican en todos los casos.
DPX sigue teniendo un destino de backup gestionado. Lo que cambia es quién decide cómo se financia y se amplía ese destino.
La eficiencia de la capacidad no es un redondeo
El almacenamiento de backup tiene que absorber los datos con la rapidez suficiente para que los trabajos terminen dentro de su ventana, y conservarlos con la eficiencia suficiente para que haya puntos de restauración disponibles. Cuando un repositorio está sobrecargado, los síntomas son conocidos:
- ventanas de backup incumplidas
- limpiezas de retención que se alargan
- presión para conservar menos puntos de restauración
Este último es una decisión de recuperación que toma una limitación del almacenamiento.
vStor utiliza la compresión y la deduplicación de ZFS para reducir esa presión. La compresión reduce el tamaño de los datos al escribirlos. La deduplicación guarda una sola vez los bloques repetidos, cuando la carga de trabajo lo justifica.
Los ratios dependen por completo de los datos. Las imágenes de VM, los registros, las bases de datos y los conjuntos de backup repetidos suelen beneficiarse. Los datos ya comprimidos o cifrados no, y ningún producto lo va a cambiar.
Lo importante no es el ratio, sino que la eficiencia del almacenamiento determina directamente durante cuánto tiempo puede mantener disponibles puntos de restauración limpios tras un incidente, lo que es una capacidad de recuperación y no una partida de coste.
Las cargas de trabajo mixtas empeoran un repositorio fijo
Un único entorno DPX rara vez protege un solo tipo de dato. Contiene imágenes de VM, servidores de archivos, volúmenes de aplicaciones, bases de datos, sistemas con muchos registros y datos de sedes remotas, y cada uno se comporta de forma distinta:
- algunos se comprimen bien o tienen bloques repetidos que merece la pena deduplicar
- otros cambian tan deprisa que la copia de ayer ya está obsoleta
- otros deben conservarse durante años y casi nunca se leerán
Un diseño de capacidad fija oculta esas diferencias hasta que el repositorio se llena. Entonces todas las opciones son malas: acortar la retención, descartar puntos de restauración, mover datos a mano o iniciar una solicitud de compra. Las dos primeras debilitan la postura de recuperación para resolver un problema de almacenamiento.
Diseñar el repositorio teniendo en cuenta el comportamiento de las cargas de trabajo evita la mayor parte de esto y hace que el plan resultante sea explicable. Un administrador puede decir por qué una carga de trabajo está donde está, por qué su retención es la que es y qué protege sus puntos de recuperación.
Sedes remotas y plataformas cambiantes
Las sedes remotas y periféricas tienen datos reales y poco personal. Rara vez justifican un appliance de hardware propio, pero siguen necesitando capacidad de restauración local y puntos de recuperación protegidos. El backup solo centralizado genera presión sobre el ancho de banda y restauraciones lentas, sobre todo con un enlace WAN estrecho.
La flexibilidad de despliegue permite que un vStor a medida en la sede remota se encargue de la recuperación local y que después replique determinados puntos de recuperación a un destino central para ganar resiliencia. Es una respuesta mejor que elegir entre un hardware que nadie puede justificar y una restauración que tarda un día.
El mismo argumento se aplica a la estrategia de virtualización, que ahora es especialmente inestable. Las organizaciones se mantienen en VMware, amplían Hyper-V, adoptan Nutanix AHV o Proxmox, o ejecutan varios a la vez.
Un repositorio atado a una plataforma de hardware, o a una hipótesis sobre un hipervisor, se convierte en una restricción de migración justo cuando más vale la flexibilidad. El almacenamiento definido por software permite decidir la plataforma por sus méritos, y DPX cubre las cargas de trabajo en cualquier caso en VMware, Nutanix y Proxmox.
Cómo calcular el caso de negocio
Si lo que quiere es acotar el propio término, qué es el almacenamiento inmutable (en inglés) explica WORM, los bloqueos de borrado y lo que protegen y lo que no. Si el caso de negocio ya está resuelto y la duda es el diseño, cómo planificar el almacenamiento inmutable (en inglés) explica qué conservar en local, qué replicar y cómo demostrar que la restauración funciona.
Para la visión de producto, consulte el almacenamiento de backup inmutable o solicite una demo.
Pawel Staniec
CTO
Pawel is CTO at Catalogic Software, where he owns DPX product architecture and technology direction and works with our developers, alliance partners and customers across EMEA to keep what we build aligned with how our data protection products are actually deployed. He writes about the engineering behind our releases, including NDMP backup management, Proxmox VE protection, and where hypervisor-native backup tooling stops being enough.