RAID frente a JBOD: la mejor opción de almacenamiento para los backups de hipervisores

A la hora de configurar el almacenamiento en servidores locales o en dispositivos NAS, RAID y JBOD son las dos opciones más habituales. Ambas consisten en combinar varias unidades en un único volumen, pero difieren significativamente en cuanto a la forma en que se distribuyen, protegen y consultan los datos. Elegir una configuración inadecuada puede provocar una disminución del rendimiento o la pérdida de datos. En esta entrada se analizan las diferencias entre JBOD y RAID y se identifican los tipos de almacenamiento óptimos para backups y almacenes de datos de máquinas virtuales.

NAKIVO para backup de VMware vSphere

NAKIVO para backup de VMware vSphere

Protección completa de los datos para máquinas virtuales de VMware vSphere y opciones de recuperación instantánea. Destinos de copia de seguridad seguros, tanto locales como externos y en la nube. Funciones antirransomware.

RAID frente a JBOD: diferencias fundamentales

RAID (matriz redundante de discos independientes) combina varias unidades físicas en una única unidad lógica para mejorar el rendimiento, la redundancia o ambos. Los distintos niveles de RAID ofrecen diferentes equilibrios entre velocidad y protección de datos que se adaptan a distintos escenarios.

RAID 0 (distribución de datos) combina discos para mejorar el rendimiento. Los datos se dividen en bloques que se distribuyen entre las unidades de disco y a los que se accede en paralelo, lo que aumenta la velocidad de lectura y escritura. No hay redundancia: si falla una unidad, se pierden todos los datos. Se requieren al menos dos discos para el RAID 0.

RAID 0 uses striping

RAID 1 (duplicación) es un nivel RAID fiable con un 100 % de redundancia. Los datos se duplican en dos unidades; esta configuración ofrece una alta protección de datos, pero la capacidad de almacenamiento se reduce a la mitad (por ejemplo, si se utilizan dos unidades de 10 TB en RAID 1, la capacidad útil es de 10 TB). Se necesitan al menos dos discos para RAID 1.

RAID 1 uses mirroring

RAID 10 (1+0) combina un alto rendimiento con una redundancia del 100 %. Los pares de unidades duplicadas (1) se distribuyen en bandas (0), lo que hace que este nivel sea muy adecuado para servidores. RAID 10 requiere al menos 4 unidades. La matriz se construye en este orden:

Los discos duplicados en RAID 1 → se distribuyen en RAID 0.

RAID 10 uses mirroring and striping

RAID 5 (distribución + paridad) equilibra rendimiento, capacidad y redundancia. Los datos se distribuyen entre varios discos junto con información de paridad que puede utilizarse para la recuperación de datos y la reconstrucción de la matriz. La configuración está diseñada para tolerar el fallo de un disco mediante paridad distribuida: un disco equivalente a la paridad para RAID 5 y dos para RAID 6. Se requieren al menos 3 discos para RAID 5.

RAID 5 uses single parity

RAID 6 es similar a RAID 5, pero utiliza paridad dual, lo que permite que la matriz, en teoría, sobreviva al fallo de dos unidades. Los requisitos para RAID 6 son al menos 4 unidades.

RAID 6 uses dual parity

JBOD (Just a Bunch of Disks) no es un nivel RAID. Describe una configuración en la que varias unidades funcionan de forma independiente o se combinan sin lógica RAID ni redundancia.

Existen dos formas de JBOD:

  1. Discos independientes (JBOD verdadero): cada unidad aparece por separado. Por ejemplo, un JBOD con tres unidades tiene el siguiente aspecto:
    1. Unidad 1 (2 TB)
    2. Unidad 2 (4 TB)
    3. Unidad 3 (1 TB)
  2. Extensión/concatenación : Varias unidades se fusionan en un único volumen lógico de gran tamaño (también denominado «extensión de discos», «modo lineal» o «concatenación»). En este caso, un conjunto de unidades de 2 TB + 4 TB + 1 TB aparece como un único volumen de 7 TB. Los archivos de un volumen JBOD extendido llenan el primer disco y, a continuación, se extienden al siguiente. Dado que la extensión se realiza de forma secuencial, los nuevos archivos intentan ocupar el bloque de direcciones lógicas disponible más bajo.
  3. JBOD spanning

Este comportamiento secuencial funciona perfectamente en teoría, donde los archivos llenan un disco antes de que el sistema pase al siguiente. En la práctica, los archivos se crean, modifican y eliminan continuamente, especialmente en servidores y sistemas con gran carga de trabajo. Como resultado, los datos rara vez pueden permanecer perfectamente confinados a un único disco en una configuración JBOD extendida.

Cuando se elimina un archivo, los bloques correspondientes se marcan como libres en el sistema de archivos. Estas eliminaciones crean huecos entre los archivos restantes. Las nuevas escrituras pueden entonces fragmentarse, con sus bloques dispersos por varios discos del volumen JBOD extendido. Si falla un disco del volumen, se pierde cualquier archivo cuyos bloques se encuentren en ese disco, incluso si otras partes residen en unidades en buen estado.

Cuando se escribe un nuevo archivo de gran tamaño, la primera parte podría llenar un hueco en el disco 1, mientras que las partes restantes pueden dividirse entre el espacio libre secuencial del disco 2 y el disco 3. Los datos quedan fragmentados tanto lógicamente (dentro de NTFS) como, potencialmente, físicamente (entre varios discos). Los archivos nuevos más pequeños pueden simplemente ocupar un hueco dejado por un archivo eliminado en uno de los discos existentes.

Nota: NOTA : Tanto los volúmenes JBOD, LVM como los volúmenes NTFS extendidos (spanned) crean un único volumen de gran tamaño que abarca varios discos, pero difieren en la capa de abstracción, la flexibilidad, el dominio de fallo y las capacidades de gestión. LVM, utilizado en sistemas basados en Linux, ofrece un enfoque más avanzado, dinámico y flexible. JBOD opera en la capa del sistema de archivos (por ejemplo, NTFS), mientras que LVM introduce una capa de gestión de volúmenes entre los discos físicos y el sistema de archivos. Esto permite a LVM admitir el redimensionamiento dinámico de volúmenes, las escrituras no secuenciales y el RAID 1 por software (duplicación de discos).

La desfragmentación, compatible con NTFS, puede reducir la fragmentación y mejorar las posibilidades de recuperar archivos de discos en buen estado en un volumen JBOD si un disco falla después de que se complete el proceso de desfragmentación. Sin embargo, la desfragmentación supone una gran carga para todas las unidades y requiere un tiempo considerable en volúmenes de gran tamaño. Si un disco falla durante la desfragmentación, se pueden perder archivos o puede fallar todo el volumen.

Nota: NOTA : La desfragmentación se aplica a las unidades de disco duro, pero no a las unidades de estado sólido.

Las principales diferencias entre JBOD y RAID son:

  • RAID está diseñado para ofrecer redundancia, rendimiento o ambos. Su configuración es más compleja y los requisitos de hardware son más exigentes. Si falla un disco, RAID necesita tiempo para reconstruir la matriz.
  • JBOD proporciona la máxima capacidad útil y permite combinar unidades de diferentes tamaños en un único volumen. La configuración es sencilla, pero no ofrece redundancia ni tolerancia a fallos.

Al comparar RAID con JBOD, el paralelismo más cercano se da entre RAID 0 y el JBOD de extensión, ya que ninguno de los dos ofrece redundancia. A lo largo de esta entrada, «JBOD» se refiere a la forma de extensión/concatenación, salvo que se indique lo contrario.

Comparación del rendimiento en backup y recuperación

JBOD no mejora el rendimiento, independientemente de cómo se utilice. Solo RAID puede aumentar la velocidad.

En una configuración JBOD de extensión , los datos llenan un disco antes de escribirse en el siguiente:

  • Un archivo almacenado íntegramente en el disco 1 se lee y se escribe a la velocidad nativa del disco 1.
  • Un archivo que se extiende a través de varios discos está limitado por el disco más lento. El aumento del tiempo de búsqueda entre discos y una mayor latencia pueden hacer que JBOD sea más lento que un único disco independiente.

JBOD proporciona la máxima capacidad sin ninguna ganancia de rendimiento, paralelismo ni striping.

El rendimiento del RAID depende del nivel (tipo) de RAID configurado.

El RAID 0 (distribución de datos) ofrece el rendimiento más rápido, ya que los datos se reparten entre varios discos y se accede a ellos en paralelo. Por ejemplo, con dos unidades en RAID 0, las lecturas y escrituras secuenciales pueden alcanzar hasta el doble de la velocidad de un solo disco. Si se utilizan dos discos duros de 200 MB/s, el modo JBOD ofrece hasta 200 MB/s, mientras que el RAID 0 puede alcanzar hasta 400 MB/s.

El RAID 1 (duplicación) mantiene datos idénticos en dos unidades. Las operaciones de lectura suelen ser más rápidas: un controlador puede leer desde cualquiera de los discos y alcanzar hasta el doble de la velocidad de un solo disco en buenas implementaciones. La velocidad de escritura es equivalente a la de un solo disco, ya que cada escritura debe realizarse en ambas unidades.

RAID 10 (espejos en bandas) combina RAID 1 y RAID 0, lo que ofrece un excelente rendimiento en operaciones de entrada/salida por segundo (IOPS).

  • Lecturas: hasta N veces la velocidad del disco.
  • Escrituras: Normalmente, ofrece aproximadamente la mitad del rendimiento de un RAID 0 (aunque sigue siendo significativamente más rápido que un solo disco).

El RAID 10 ofrece la mejor combinación de rendimiento y redundancia entre los niveles RAID y supera al JBOD en todos los parámetros de rendimiento.

RAID 5 (distribución de datos + paridad simple) requiere tres o más discos. El rendimiento de lectura y escritura difiere:

  • Lecturas: rápidas, aunque no tanto como en RAID 0 (paralelización equivalente a N–1 discos).
  • Escrituras: más lentas debido al cálculo de la paridad y a la «penalización de escritura».

Las velocidades de escritura en RAID 5 suelen rondar la mitad de las de RAID 0 con el mismo número de discos.

El RAID 5 supera al JBOD en cargas de trabajo con gran volumen de lectura, pero en cargas de trabajo con gran volumen de escritura puede ser más lento que el RAID 0 y, en algunos casos, ligeramente más lento que el JBOD.

El RAID 6 (paridad dual) se comporta de forma similar al RAID 5, pero conlleva una penalización de escritura aún mayor:

  • Lectura: comparable al RAID 5.
  • Escritura: suele ser el más lento entre los niveles RAID habituales.

El rendimiento de lectura sigue superando al de JBOD, aunque el de escritura puede quedar por debajo.

En resumen :

  • RAID 0 ofrece el mayor rendimiento bruto.
  • RAID 10 ofrece el mejor equilibrio entre rendimiento y fiabilidad.
  • JBOD es adecuado para grandes volúmenes de almacenamiento en los que la velocidad y la redundancia no son prioritarias.

Tenga en cuenta estas características a la hora de elegir RAID o JBOD como almacenamiento de origen o destino para las operaciones de backup y recuperación.

Nota: NOTA : Evite utilizar el «RAID falso», una función integrada en las placas base con puertos SATA y que se configura a través de los ajustes de la UEFI/BIOS. Esta forma híbrida de RAID por software depende de la CPU del host. El «RAID falso» no funciona en Linux y requiere controladores especiales en Windows. Carece de la fiabilidad del verdadero RAID por hardware, y no se puede acceder a los datos SMART mientras el «RAID falso» está activado. Si surgen problemas, puede producirse una pérdida de datos. Cuando el RAID por hardware no sea una opción, considere alternativas de RAID por software auténticas, como LVM de Linux, mdadm o ZFS.

Rendimiento y fiabilidad del RAID

El rendimiento es importante, pero la fiabilidad cobra igual de importancia cuando el objetivo es la protección de datos y la recuperación. Cada nivel de RAID ofrece un perfil diferente, mereciendo especial atención el RAID 5 y el RAID 6.

RAID 0 es rápido para la lectura, la escritura y el almacenamiento de backups utilizados en operaciones de recuperación. Sin embargo, si falla una unidad, se pierden todas las copias de seguridad de la matriz. El mismo riesgo se aplica a los datos primarios almacenados en RAID 0 cuando no existe una copia de seguridad independiente.

Un segundo escenario de recuperación consiste en reconstruir la matriz en los propios discos, sin restaurar los datos desde un soporte externo. Todos los niveles RAID, excepto el RAID 0, ofrecen capacidades de autorreparación automática que reconstruyen la matriz a partir de datos redundantes o de paridad presentes en los discos restantes que se encuentran en buen estado. Después de sustituir la unidad averiada, el proceso de reconstrucción se inicia automáticamente.

RAID 1 con dos unidades puede soportar el fallo de una unidad y es muy fiable. La reconstrucción es rápida, ya que no requiere cálculo de paridad.

RAID 10 tolera el fallo de cualquier unidad individual e incluso puede soportar el fallo de dos unidades, siempre que los discos averiados pertenezcan a pares de espejos diferentes. La fiabilidad y la tolerancia a fallos son elevadas, y las reconstrucciones son rápidas porque no se requiere cálculo de paridad (a diferencia del RAID 5).

RAID 10 can survive if two disks in different mirrors fail

RAID 5 puede, en teoría, sobrevivir al fallo de una unidad, y RAID 6 puede sobrevivir al fallo de dos unidades, pero la fiabilidad real de estos niveles es menor de lo que parece. El riesgo de fallo total de la matriz aumenta significativamente durante el proceso de reconstrucción. El RAID 5, en particular, merece un análisis minucioso, a pesar de su redundancia declarada.

El RAID 5 se desarrolló en 1987, cuando la capacidad de los discos era baja (unos 20 MB) y la probabilidad de que la reconstrucción se completara con éxito después del fallo de un solo disco era alta, dadas las velocidades de reconstrucción de la época. Las unidades modernas se comercializan ahora con capacidades de 30 TB y más. Aunque las capacidades han crecido en órdenes de magnitud, las velocidades de las unidades mecánicas no han seguido el ritmo, especialmente en el caso de los discos duros (HDD).

Cuando falla una unidad en un RAID 5, la matriz entra en un estado degradado. En principio, se sigue pudiendo acceder a los datos después de reconstruir la matriz. La cantidad de datos que hay que reconstruir es igual a la capacidad de un disco, utilizando los datos de paridad distribuidos entre los discos restantes en buen estado. Durante la reconstrucción, el rendimiento de los discos de toda la matriz se ve significativamente reducido, ya que el controlador debe ejecutar cálculos de paridad y comprobaciones de coherencia adicionales.

Una vez sustituido el disco averiado, el controlador RAID inicia la reconstrucción. Lee los datos restantes de los discos que siguen funcionando y, basándose en la información de paridad, escribe el contenido reconstruido en la nueva unidad. Los tiempos de reconstrucción suelen ser largos y dependen del número de discos, la CPU del controlador, la cantidad de datos de la matriz y otros factores similares. Si el servidor sigue gestionando cargas de trabajo con un uso intensivo de E/S durante la reconstrucción, tanto el rendimiento de la matriz como la velocidad de reconstrucción disminuyen, lo que alarga aún más el proceso.

Dado que la capacidad de las unidades se amplía más rápidamente que su velocidad (especialmente en el caso de los discos duros), los tiempos de reconstrucción de RAID 5 no dejan de crecer. Por ejemplo, la reconstrucción de una matriz RAID 5 de cinco discos de 4 TB en un servidor muy ocupado puede llevar más de un día, y las matrices formadas por discos de 20 TB pueden prolongarse hasta varios días. Multiplica esas cifras aún más si se trata de unidades de 30 TB.

Durante una reconstrucción de RAID 5, la matriz funciona, en la práctica, sin redundancia, al igual que el RAID 0. Incluso una pequeña interrupción —un error de lectura en un disco, una interferencia de señal o un problema con el cable— puede provocar que la reconstrucción falle. Si un segundo disco falla durante este periodo, se pierden todos los datos de la matriz.

El parámetro «tasa de error de bits» (BER) es utilizado por los proveedores para estimar la fiabilidad de las unidades. El BER de los discos de clase de sobremesa es de 10^14, mientras que los de clase Enterprise alcanzan los 10^15. El valor de 10^14 significa que la probabilidad de que se produzca un error de lectura irrecuperable no es superior a 1 entre 100 000 000 000 000 de bits (14 ceros). 10^14 bits sea igual a 11 TB de datos. Esto significa que, después de leer unos 11 TB de un disco duro de clase de escritorio, la probabilidad de que se produzca al menos un error de lectura a nivel de bit es cercana al 100 %. En la práctica, las unidades suelen fallar antes de lo que sugeriría su tiempo medio hasta el fallo (MTTF) teórico.

Con los discos duros de clase Enterprise, la situación mejora en un orden de magnitud: la probabilidad acumulada de error de lectura alcanza casi el 100 % después de leer unos 110 TB de datos. Teniendo en cuenta que los discos duros disponibles en el mercado en 2026 superarán los 30 TB por unidad, una tasa de error de lectura (BER) de 10^15 ya no resulta especialmente satisfactoria para matrices de gran tamaño. La probabilidad de fallo es menor para los discos de menor capacidad y mayor para los de mayor capacidad.

Hay que tener en cuenta que gran parte de los datos almacenados en las matrices de discos son datos inactivos —a los que se accede en raras ocasiones y que a menudo permanecen sin utilizarse durante 1 o 2 años—. Dado que los sistemas no analizan continuamente cada sector del disco para comprobar su estado y coherencia, algunos archivos pueden encontrarse en bloques que ya no se pueden leer. Esta corrupción latente permanece invisible hasta que la reconstrucción del RAID 5 la pone de manifiesto, momento en el que se convierte en un problema grave.

No se recomienda utilizar RAID 5, especialmente en sistemas de producción o para datos críticos para el negocio. Si aún así es necesario utilizar RAID 5, no lo combines con controladores de bajo coste ni con discos de consumo. Opta por controladores RAID de nivel Enterprise y unidades con índices de fiabilidad más elevados. El RAID 6 ofrece un rendimiento ligeramente superior al del RAID 5, pero el riesgo de pérdida de datos sigue siendo significativo.

Siempre se debe hacer backup de los datos almacenados en RAID 5 en un dispositivo de almacenamiento externo para protegerse frente a un fallo de la matriz. El mismo principio se aplica al almacenamiento RAID 0 y JBOD.

Fiabilidad y rendimiento del JBOD

En una configuración JBOD de extensión, si falla un disco, cualquier archivo cuyos bloques se encuentren en la unidad dañada se vuelve ilegible e irrecuperable. Solo los archivos almacenados íntegramente en unidades en buen estado pueden recuperarse potencialmente.

En configuraciones específicas, el fallo de un solo disco puede provocar que falle todo el volumen JBOD, incluso si la mayor parte de los datos se encuentra en discos en buen estado, de forma similar a lo que ocurre con RAID 0. El motivo es el sistema de archivos: si estructuras críticas, como la Tabla Maestra de Archivos (MFT), residen en la unidad averiada, el sistema operativo ya no puede asignar direcciones lógicas a bloques físicos, lo que hace que los datos de los discos en buen estado resulten inaccesibles. Si se desconoce el patrón de escritura de su configuración JBOD, considere el almacenamiento como si tuviera tolerancia a fallos nula.

Rendimiento RAID para VMware e Hyper-V

El almacenamiento RAID ofrece un mayor rendimiento, pero no todos los niveles RAID son adecuados para los almacenes de datos de máquinas virtuales o el almacenamiento de máquinas virtuales.

RAID 0 es rápido, pero no seguro. El fallo de un solo disco provoca un tiempo de inactividad hasta que las máquinas virtuales afectadas se restauran a partir de un backup o se realiza la conmutación por error a réplicas preexistentes de las mismas. El RAID 0 en un almacén de datos de máquinas virtuales requiere una estrategia sólida de copias de seguridad y replicación. Se desaconseja encarecidamente el uso de RAID 0 sin medidas adicionales de protección de datos en entornos de producción. Puede ser aceptable para cargas de trabajo temporales, como laboratorios y entornos de prueba.

RAID 1 funciona bien para el almacenamiento de máquinas virtuales en VMware, Hyper-V y otras plataformas de virtualización. El rendimiento es adecuado, y la redundancia del 100 % de los datos evita el tiempo de inactividad después del fallo de un solo disco mientras se reconstruye la matriz. RAID 1 es una opción razonable para entornos virtuales más pequeños con un número limitado de máquinas virtuales.

RAID 10 ofrece el máximo rendimiento y fiabilidad. Su elevado número de IOPS, su baja latencia, la rapidez en las operaciones de lectura y escritura, su sólida tolerancia a fallos y la rapidez en la reconstrucción lo convierten en el nivel RAID recomendado para VMware, Hyper-V y otras plataformas de virtualización en entornos de producción.

RAID 5 ofrece un rendimiento moderado en lectura, pero el rendimiento en escritura es más lento. A pesar de cierta ventaja en lectura en condiciones normales de funcionamiento, el RAID 5 no debe utilizarse para almacenar máquinas virtuales ni datos críticos para la misión. Como se ha comentado anteriormente, el riesgo de reconstrucción es elevado y la pérdida de rendimiento durante la reconstrucción es considerable.

RAID 6 ofrece un rendimiento de lectura similar al de RAID 5, pero con una velocidad de escritura más lenta. La fiabilidad mejora ligeramente con respecto a RAID 5, pero sigue presentando todas sus debilidades. No se recomienda el RAID 6 para almacenar máquinas virtuales o datos críticos.

Rendimiento de JBOD para VMware e Hyper-V

A diferencia del almacenamiento de copias de seguridad, el almacenamiento de máquinas virtuales tiene requisitos de rendimiento mucho más estrictos. Las cargas de trabajo de las máquinas virtuales son muy sensibles a las IOPS, la latencia y el rendimiento. En este contexto, el RAID y el JBOD se comportan de manera muy diferente, e incluso la elección del nivel de RAID afecta significativamente al rendimiento de las máquinas virtuales en esa matriz.

Las cargas de trabajo de las máquinas virtuales generan muchas operaciones pequeñas de lectura y escritura y exigen un elevado número de IOPS, especialmente en el caso de los discos virtuales que alojan sistemas operativos, bases de datos y servidores de archivos. Los archivos de intercambio, la paginación, las instantáneas y los discos delta generan una fuerte amplificación de escritura. Durante el funcionamiento normal de las máquinas virtuales son habituales los picos periódicos de E/S.

Dado que JBOD es una de las configuraciones de almacenamiento más lentas, no se recomienda su uso para VMware, Hyper-V u otros archivos de máquinas virtuales, especialmente en entornos de producción.

Consideraciones de almacenamiento: VMware frente a Hyper-V

Ambos VMware e Hyper-V dependen en gran medida del rendimiento y la consistencia del almacenamiento, pero difieren en cómo acceden al almacenamiento, optimizan las cargas de trabajo y protegen los datos.

VMware vSphere es más sensible al rendimiento del almacenamiento debido a la forma en que VMFS, vMotion, instantáneas y DRS interactúan con los Almacenes de datos. Los tipos de almacenamiento compatibles con VMware vSphere son:

  • Red de área de almacenamiento (SAN): iSCSI, Fibre Channel, FCoE
  • Almacenamiento conectado a la red (NAS): NFS v3/v4.1
  • Almacenamiento conectado directamente (DAS): RAID local, NVMe, SSD
  • vSAN (almacenamiento hiperconvergente)
  • Almacenamientos en la nube (vVols, recursos compartidos NFS)

NFS proporciona almacenamiento compartido a nivel de archivo, mientras que iSCSI y DAS operan a nivel de bloque.

Los almacenes de datos VMFS son el tipo de almacenamiento de máquinas virtuales más utilizado en entornos VMware vSphere debido a su fiabilidad, comodidad y facilidad de configuración. VMFS es un sistema de archivos en clúster que permite que varios hosts ESXi accedan simultáneamente a los mismos almacenes de datos, bloques y archivos, un requisito imprescindible para las configuraciones en clúster. Las características principales de los almacenes de datos VMFS de VMware incluyen:

  • Excelentes para cargas de trabajo con un elevado número de IOPS
  • Admiten el acceso de varios hosts al mismo almacén de datos
  • Requisitos de rendimiento elevados del almacenamiento subyacente
  • Ofrecen aprovisionamiento «thin» y «thick»
  • Ofrecen un rendimiento óptimo con RAID 10 para el inicio de máquinas virtuales y las actividades de escritura

Los almacenes de datos VMFS pueden crearse en discos locales (incluidas matrices RAID locales a través de DAS) o en LUN iSCSI expuestas por dispositivos SAN y NAS a través de la red. En ambos casos, el RAID suele configurarse en el dispositivo SAN o NAS subyacente para garantizar el rendimiento y la fiabilidad. El RAID también puede utilizarse para configurar recursos compartidos de archivos NFS en un servidor de archivos.

Se aplican los principios de selección del nivel de RAID descritos anteriormente. Los SSD ofrecen el máximo rendimiento, mientras que los HDD son adecuados para cargas de trabajo menos exigentes. El RAID 10 es la opción óptima para el almacenamiento de máquinas virtuales de VMware, siendo el RAID 1 una alternativa aceptable. VMware ESXi solo admite RAID por hardware para el almacenamiento conectado localmente.

Microsoft Hyper-V utiliza NTFS o ReFS en volúmenes compartidos de clúster (CSV); su comportamiento de almacenamiento difiere significativamente del de VMware vSphere. Los tipos de almacenamiento compatibles con Hyper-V son:

  • DAS: matrices RAID (las más comunes)
  • SAN: iSCSI/Fibre Channel
  • SMB 3.0/3.02 (servidor de archivos de escalabilidad horizontal — SOFS)
  • Espacios de almacenamiento/Espacios de almacenamiento directos (S2D)
  • Almacenamiento en la nube basado en Azure

SMB es un protocolo de uso compartido de archivos nativo de los entornos de Microsoft.

Hyper-V almacena VHDX archivos de disco virtual en volúmenes NTFS/ReFS conectados directamente, volúmenes compartidos de clúster (CSV) y recursos compartidos de archivos SMB 3.0. Los CSV permiten que varios hosts accedan simultáneamente al mismo LUN, lo cual es necesario para la configuración de clústeres. Hyper-V en Windows Server admite RAID por hardware, RAID simulado y RAID por software. Las recomendaciones de RAID para Hyper-V coinciden con las de VMware: RAID 10 es la mejor opción para los hosts que ejecutan cargas de trabajo de máquinas virtuales, y RAID 1 es una alternativa razonable. El RAID por hardware sigue siendo la implementación preferida.

Costes de almacenamiento y ampliación

RAID suele aumentar los costes de almacenamiento porque la redundancia reduce la capacidad útil: se paga por más hardware del que realmente se obtiene en términos de espacio efectivo. Por ejemplo:

  • RAID 0: sin reducción de capacidad
  • RAID 1: 50 % de capacidad útil (dos unidades se duplican entre sí)
  • RAID 10: 50 % de capacidad útil (bandas duplicadas)
  • RAID 5: Pérdida de capacidad equivalente a un disco (N discos → N−1 utilizables)
  • RAID 6: Pérdida de capacidad equivalente a dos discos (N discos → N−2 utilizables)

Para obtener el máximo rendimiento y fiabilidad, se requiere un controlador RAID de alta calidad (con batería y caché), lo que conlleva un precio elevado.

JBOD es la opción más económica, ya que no se necesitan unidades adicionales para la redundancia ni se requiere ningún hardware de controlador especial. Se puede añadir cualquier número de discos para crear un volumen grande, a diferencia de RAID 1, que está limitado a dos unidades. JBOD también funciona con unidades mixtas —de diferentes proveedores, capacidades y velocidades—, pero esta flexibilidad se consigue a costa del rendimiento y la fiabilidad.

La ampliación es donde las dos configuraciones difieren notablemente. La mayoría de las configuraciones RAID no se pueden ampliar fácilmente o solo admiten una ampliación limitada. Normalmente es necesario sustituir todos los discos miembros por unidades más grandes de igual capacidad, o configurar una matriz RAID independiente, lo que requiere puertos libres en el controlador RAID o incluso un controlador adicional. Los controladores RAID avanzados pueden ampliar el RAID 10 añadiendo pares de discos. El RAID 5 y el RAID 6 pueden ampliarse mediante la adición de discos, pero el proceso es arriesgado y requiere mucho tiempo.

El JBOD ofrece la mayor flexibilidad y la vía de expansión más sencilla. Se puede añadir una unidad en cualquier momento, independientemente del fabricante, la capacidad, el modelo u otros parámetros. Los nuevos discos están disponibles de inmediato, sin que sea necesario realizar una reconstrucción ni un cálculo de paridad.

Optimización del rendimiento de los backups con NAKIVO

JBOD puede servir como almacenamiento de bajo coste y ampliable para los backups. La velocidad de las copias de backup suele estar limitada por la conexión de red, con una sobrecarga adicional derivada de la compresión y el cifrado, lo que significa que los límites de velocidad bruta del JBOD rara vez suponen un cuello de botella. Aun así, recuerda el Regla de backup «3-2-1» y mantén copias de backup adicionales que puedan sacarte del apuro si falla el almacenamiento principal de backup.

Incluso con niveles RAID fiables, como RAID 1 y RAID 10, sigue siendo necesario hacer backup de los datos de estas matrices. RAID 1 tolera el fallo de una unidad, y RAID 10 puede soportar dos, siempre que los discos averiados pertenezcan a pares de espejos diferentes. Pero la redundancia no es una protección contra todos los modos de fallo. La eliminación accidental, los ataques de ransomware, la corrupción del software y los desastres físicos pueden destruir los datos o el propio servidor. El RAID en espejo es una forma de redundancia, no un sustituto de una solución adecuada de estrategia de backup.

NAKIVO Backup & Replication incluye una amplia gama de funciones diseñadas para que la protección de datos sea rápida, segura, fiable y cómoda.

  • Copia de seguridad de máquinas virtuales sin agente para VMware vSphere, Microsoft Hyper-V, Proxmox VE y Nutanix AHV. Se utilizan las API nativas del hipervisor para realizar copias de seguridad de los datos a nivel de host.
  • Transferencia de datos sin LAN : NAKIVO Backup & Replication selecciona automáticamente el modo óptimo de transferencia de datos, como VMware Hot Add o Direct SAN Access, para reducir la carga de la red y acelerar las copias de seguridad.
  • Aceleración de la red : Los datos se comprimen antes de enviarse a través de la red al almacenamiento de copia de seguridad de destino, lo que mejora la velocidad de transferencia y reduce el espacio de almacenamiento necesario.
  • Programación y automatización de copias de seguridad : Las opciones flexibles programación y retención permiten que los jobs de backup se ejecuten automáticamente, lo que ahorra tiempo.
  • Integración con appliances de desduplicación : El uso de appliances de desduplicación compatibles y sus protocolos nativos de transferencia de datos maximiza la velocidad de copia de seguridad y minimiza el uso de almacenamiento de copias de seguridad. Entre las appliances compatibles se incluyen EMC Data Domain (DD Boost), HPE StoreOnce (Catalyst) y NEC HYDRAstor (Universal Express).
  • Copia de seguridad incremental : Solo se transfieren los datos que han cambiado desde la última copia de seguridad completa o backup incremental , lo que ahorra tiempo y mejora el rendimiento en comparación con las copias de seguridad exclusivamente completas.
  • Seguimiento de cambios nativo para VMware e Hyper-V : Seguimiento de cambios en los bloques de VMware (CBT) y el seguimiento resiliente de cambios de Hyper-V (RCT) aceleran las copias de seguridad incrementales.
  • Exclusión de datos de intercambio : Los archivos y particiones de intercambio almacenan datos temporales del sistema operativo y añaden un volumen innecesario a las copias de seguridad. NAKIVO Backup & Replication los excluye, lo que mejora la velocidad de las copias de seguridad y ahorra espacio de almacenamiento.
  • Truncamiento de registros : Los sistemas de bases de datos crean archivos de registro para garantizar la coherencia de las transacciones y facilitar la recuperación. Estos registros pueden alcanzar un gran tamaño. La función de truncamiento de registros mantiene las copias de seguridad más compactas.

Conclusión

A pesar de su bajo coste y ampliabilidad, el almacenamiento JBOD no es adecuado para datos críticos ni para cargas de trabajo que exijan un alto rendimiento. El fallo de un solo disco puede provocar la pérdida de datos. El JBOD puede funcionar como almacenamiento de copia de backup, pero solo cuando exista al menos una copia de backup adicional en un almacenamiento independiente. Se deben evitar las configuraciones RAID 5 y RAID 6 para datos importantes. RAID 10 y RAID 1 siguen siendo las opciones más fiables, y RAID 10 ofrece el mayor rendimiento, lo que lo hace ideal para el almacenamiento de máquinas virtuales con redundancia total. Incluso con el mejor nivel de RAID, sigue siendo esencial hacer backup de los datos de la matriz, ya que muchos casos de pérdida de datos se producen sin que se produzca ningún fallo en la matriz.

Prueba NAKIVO Backup & Replication

Prueba NAKIVO Backup & Replication

Solicita una versión de prueba gratuita para descubrir todas las funciones de protección de datos de la solución. 15 días gratis. Sin limitaciones de funciones ni de capacidad. No es necesario facilitar un número de tarjeta de crédito.

PREGUNTAS FRECUENTES

¿Cuál es la diferencia entre JBOD y RAID?

RAID combina varias unidades de disco en una sola unidad lógica mediante el uso de striping, mirroring o paridad para mejorar el rendimiento, la redundancia o ambos. JBOD (Just a Bunch of Disks) agrupa las unidades de disco en un único volumen sin utilizar ninguno de estos mecanismos. RAID requiere unidades de disco compatibles y un controlador; JBOD admite unidades de disco mixtas sin necesidad de hardware especial. RAID protege contra fallos de disco (excepto RAID 0); JBOD no ofrece tolerancia a fallos.

¿Es suficiente un JBOD para almacenar backups?

El JBOD puede servir como almacenamiento de copias de seguridad de bajo coste, ya que la velocidad de las copias de seguridad suele estar limitada por la red, y no por el rendimiento de los discos. Sin embargo, el fallo de un solo disco puede destruir archivos repartidos en varias unidades. Si utilizas JBOD para las copias de seguridad, sigue la regla 3-2-1 y mantén al menos una copia de backup adicional en un almacenamiento independiente.

¿Qué nivel RAID es el más adecuado para las máquinas virtuales de VMware e Hyper-V?

RAID 10 es el nivel recomendado para el almacenamiento de máquinas virtuales tanto en VMware como en Hyper-V. Combina el striping y el mirroring para ofrecer un elevado número de IOPS, baja latencia, reconstrucciones rápidas y redundancia total. RAID 1 es aceptable para entornos más pequeños. Se deben evitar RAID 5 y RAID 6 para cargas de trabajo de máquinas virtuales debido a la lentitud en las escrituras, el elevado riesgo de reconstrucción y la pérdida de rendimiento durante la recuperación.

¿Por qué no se recomienda el RAID 5 para los datos de producción?

El RAID 5 se diseñó en 1987 para unidades de pequeña capacidad. Dado que las unidades modernas superan los 30 TB, los tiempos de reconstrucción se alargan hasta varios días. Durante la reconstrucción, la matriz funciona sin redundancia. Un solo error de lectura, un problema con el cable o un segundo fallo de disco durante este periodo provoca la pérdida total de los datos. Los controladores y las unidades de nivel empresarial reducen el riesgo, pero el RAID 10 sigue siendo una opción más segura.

¿Se puede utilizar JBOD para almacenes de datos de VMware o Hyper-V?

No se recomienda utilizar JBOD para el almacenamiento de máquinas virtuales. Las cargas de trabajo de las máquinas virtuales requieren un elevado número de IOPS, baja latencia y un rendimiento constante. JBOD no ofrece ninguna mejora de rendimiento con respecto a un único disco, ni paralelismo ni tolerancia a fallos. Un fallo de disco en un volumen JBOD puede provocar la interrupción del funcionamiento de las máquinas virtuales en ejecución, sin que exista otra vía de recuperación que no sea la restauración a partir de una copia de seguridad.

Artículos recomendados