Calculadora de Capacidad RAID & ZFS

Calculadora de Capacidad RAID & ZFS

Calcula la capacidad de almacenamiento útil en TB decimales y TiB binarios para configuraciones RAID 0, 1, 5, 6, 10, 50, 60 y ZFS RAIDZ1/Z2/Z3, con sobrecarga de paridad, riesgo de fallo por URE en reconstrucción, tiempo estimado y visualizador de bahías.

Cargar ejemplo
Configuración del array
Tolerancia a fallos:2 Drives per vdev
4 Disco
0 Reserva
Discos de datos: 2 | Discos de paridad: 2 | Discos Hot Spare: 04 Tolerancia máxima a fallos
Capacidad útil (TiB)28.19 TiB
Eficiencia de almacenamiento48.4%
Capacidad segura al 80 % (TiB)22.56 TiB
Riesgo de fallo URE en reconstrucción0.0%
Tiempo de reconstrucción22.2 Horas
Coste por TiB útil$38.31

Visualizador de bahías

ZFS RAIDZ2 (Dual Parity vdev) • 4 Bahía En línea

Datos (2)Paridad (2)
STORAGE CHASSIS ENCLOSURE // ZFS
#01
Disco #1 • 16 TBdata

En línea • 7,200 RPM Enterprise HDD (~200 MB/s) • URE: 10⁻¹⁵ (1 sector per ~125 TB) - NAS Pro / CMR

Coste por disco:$270.00
Coste total: $1,080.00Coste por TiB útil: $38.31Coste por TB útil: $34.84
Referencia técnica y guía de arquitectura

Calculadora de Capacidad RAID & ZFS — Guía de referencia

Calcula la capacidad de almacenamiento útil en TB decimales y TiB binarios para matrices RAID 0, 1, 5, 6, 10, 50, 60 y ZFS RAIDZ1/Z2/Z3, considerando sobrecarga de paridad, riesgo de fallo por URE en reconstrucción, tiempos de reconstrucción y visualizador de bahías.

Calculadora de Capacidad RAID & ZFS — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Calculadora de Capacidad RAID & ZFS — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

Relación de conversión decimal (TB) vs. binaria (TiB) (IEC 80000-13)Constante de conversión de base (Float64)

Gobierna la divergencia matemática de base entre el etiquetado decimal de los fabricantes de almacenamiento (1 TB = 10^12 bytes) y el direccionamiento binario en sistemas POSIX (1 TiB = 2^40 = 1 099 511 627 776 bytes), conforme a los estándares de precisión IEC 80000-13 e IEEE 754-2019. Ejecutado localmente mediante JavaScript del lado del cliente con complejidad O(1), este factor determina una reducción aparente e inmutable del 9,0949 % de capacidad previa a las estructuras del sistema de archivos o al particionado GPT EFI.

Por defecto: 0.90949470177
Tasa de error de bits (BER) por error de lectura irrecuperable (URE)Constante exponencial de Poisson

Probabilidad estadística de encontrar un sector físico ilegible durante la reconstrucción secuencial de la matriz, modelada como P(fallo) = 1 - exp(-Bits_Totales_Leídos * BER). Los discos duros SATA de consumo operan a un BER de 10^-14 (1 error de sector por cada 12,5 TB leídos), las unidades empresariales Nearline SAS operan a 10^-15, y las unidades de misión crítica SAS/NVMe U.2/U.3 alcanzan un BER de 10^-16, definiendo el umbral matemático en el que las topologías de doble paridad (RAID 6 / RAIDZ2) se vuelven obligatorias.

Por defecto: 1e-14 (SATA de consumo)
Factor de penalización de escritura en almacenamiento (Multiplicador RMW de lectura-modificación-escritura)Coeficiente de multiplicación de E/S

Cuantifica las transacciones físicas de E/S en platos magnéticos o NAND requeridas para completar una única escritura aleatoria de banda (stripe) bajo la semántica de E/S de POSIX. RAID 0 incurre en 1 operación de E/S; RAID 1/10 incurre en 2 (escrituras espejo en paralelo); RAID 5 incurre en 4 (2 lecturas + 2 escrituras para datos y paridad); y RAID 6 incurre en 6 (3 lecturas + 3 escrituras sobre los síndromes P+Q calculados en el campo de Galois GF(2^8)), estableciendo los requisitos del búfer de coalescencia de escritura en memoria.

Por defecto: 4 (RAID 5) / 6 (RAID 6)
Reserva de espacio de holgura (Slop Space) en OpenZFS Pool y geometría de sector de vdev (ashift)Flag de memoria de kernel / Geometría de vdev

Búfer a nivel de kernel que reserva 1/32 (3,125 %, mínimo 128 MiB) de la capacidad bruta del zpool mediante vdev_slop_shift=5, garantizando que las transacciones administrativas (zfs destroy, zfs rollback) se ejecuten sin desencadenar fallos de falta de espacio POSIX ENOSPC. Impone ashift=12 (límite de asignación de 4096 bytes) para prevenir más de un 300 % de amplificación de escritura en sectores físicos Advanced Format de 512e y 4Kn.

Por defecto: Reserva del 3,125 % (ashift=12)
Aislamiento criptográfico y sandbox de ejecución en navegador sin telemetríaContrato de aislamiento del lado del cliente

Garantiza que todos los cálculos de la matriz, vectores de supervivencia de reconstrucción de Poisson y geometrías de paridad se ejecuten exclusivamente dentro del entorno aislado (sandbox) WebAssembly/V8 del cliente, con cero telemetría de red o transmisión al servidor. Las configuraciones de topología de almacenamiento, números de serie y geometrías de disco, y capacidades de datastores permanecen aisladas en memoria volátil local, cumpliendo estrictamente con la arquitectura zero-trust y la confidencialidad criptográfica.

Por defecto: Sandbox de cliente aislado (0 bytes de E/S de red)

Consejos profesionales y mejores prácticas

El abismo de rendimiento del 80 % en sistemas de archivos Copy-on-Write (CoW)

Nunca supere el 80 % de asignación en pools de almacenamiento con tecnología Copy-on-Write (ZFS / Btrfs). Cuando la capacidad del pool supera el umbral del 80 %, el asignador de espacio de ZFS conmuta de un algoritmo first-fit de mapa de espacio O(1) a una búsqueda intensiva best-fit a través de metaslabs. Esto desencadena una fragmentación catastrófica del sistema de archivos, destruye la localidad espacial de escritura secuencial y desploma los IOPS de escritura aleatoria hasta en un 70 %.

La trampa de IOPS aleatorios en vdevs anchos bajo topologías RAIDZ

Un único vdev RAIDZ de ZFS ofrece el rendimiento de IOPS de escritura aleatoria de SOLO UN disco constituyente, independientemente de si agrupa 4 o 24 unidades. Dimensionar un chasis de 24 bahías como un único vdev RAIDZ2 de 24 discos paraliza el rendimiento de datastores de máquinas virtuales y registros de transacciones de bases de datos. Para escalar los IOPS de forma lineal, cree un stripe combinando múltiples vdevs más estrechos (por ejemplo, cuatro vdevs RAIDZ2 de 6 discos) o implemente vdevs en espejo (equivalente a RAID 10).

Desalineación del tamaño de sector y amplificación de escritura con ashift=12

Formatee siempre discos duros y SSD modernos con formato avanzado 4Kn y 512e utilizando ashift=12 (alineación de sectores de 4096 bytes) al crear pools de ZFS (`zpool create -o ashift=12`). Aceptar el valor heredado por defecto ashift=9 (sectores de 512 bytes) provoca que los sectores nativos de 4 KB se dividan entre múltiples escrituras físicas, desatando una penalización inevitable de más del 300 % por amplificación de escritura que degrada el rendimiento de E/S y acelera el desgaste de la memoria NAND.

Disparidad de supervivencia: doble paridad frente a reserva activa (Hot Spare)

Migrar un pool de almacenamiento de RAID 5 + disco de reserva dedicado (Hot Spare) a una matriz activa RAID 6 con el mismo número de discos proporciona una tolerancia a fallos exponencialmente superior. Una unidad Hot Spare permanece completamente inactiva en estado estacionario y ofrece redundancia cero durante la ventana de reconstrucción de alto estrés. Por el contrario, RAID 6 mantiene paridad dual Reed-Solomon activa en todo momento, sobreviviendo a un segundo fallo de disco o a un error URE durante toda la reconstrucción.

Problemas comunes y soluciones

⚠️La capacidad útil del sistema de archivos en el sistema operativo es entre un 4 % y un 9 % menor que el espacio bruto calculado del volumen

La asignación de reserva de root y la sobrecarga de metadatos de las particiones consumen bloques brutos. En Linux, ext4 reserva automáticamente el 5 % de los bloques del volumen para el superusuario root con el fin de evitar bloqueos totales del sistema; recupere este espacio en puntos de montaje de almacenamiento que no sean de root ejecutando 'tune2fs -m 1 /dev/sdX' para reducir la reserva al 1 %. Asimismo, tenga en cuenta las tablas de particiones GPT EFI, las extensiones de metadatos de LVM (4-8 MiB) y el espacio de holgura (slop space) del 3,125 % en ZFS ('spa_slop_shift=5'), el cual reserva margen para operaciones de instantáneas (snapshots) y eliminación de archivos en entornos Copy-on-Write.

⚠️Un error de lectura irrecuperable (URE) aborta la reconstrucción de la matriz y deja el pool de almacenamiento fuera de línea (offline)

Durante la reconstrucción de un RAID 5 de paridad simple, un fallo de lectura secundario ocurre inmediatamente al toparse con sectores ilegibles en discos supervivientes de 8 TB o más. Detenga de inmediato las operaciones de escritura y genere clones de bloques brutos a nivel de bit de todos los discos supervivientes en un medio alternativo mediante 'ddrescue -b 4096 /dev/sdX /media/recovery.img' antes de ejecutar fsck o reiniciar metadatos. Para erradicar esta vulnerabilidad en futuras implementaciones, establezca como obligatoria la doble paridad (RAID 6 o RAIDZ2) en cualquier matriz con discos de 4 TB o superiores para tolerar fallos secundarios de lectura de sectores.

⚠️Hiperactividad extrema del disco (thrashing) y degradación crítica de velocidad durante el resilvering de un pool ZFS

La contención durante el resilvering se debe a cuellos de botella en la caché interna de unidades SMR (Shingled Magnetic Recording) gestionadas por el disco o a la inanición de metadatos en una memoria ARC (Adaptive Replacement Cache) subdimensionada. Verifique con 'smartctl -i /dev/sdX' que las unidades sean CMR (Conventional Magnetic Recording); reemplace de inmediato cualquier disco SMR gestionado por host o por disco (Host-Managed o Drive-Managed). Para estabilizar cargas de trabajo en producción, regule la prioridad de E/S del resilvering con 'zfs set zfs:zfs_resilver_min_time_ms=2000' y amplíe la memoria ARC del host para evitar expulsiones continuas de metadatos de la caché.

Preguntas frecuentes (FAQ)

¿Cómo se calcula la capacidad útil de un RAID según los diferentes niveles de la matriz?▼

La capacidad útil de un RAID depende de la topología de la matriz y de la sobrecarga de discos de paridad: RAID 0 proporciona N * Capacidad_Disco (0 % de pérdida por paridad); RAID 1 proporciona 1 * Capacidad_Disco (50 % de pérdida por espejo en 2 discos); RAID 5 proporciona (N - 1) * Capacidad_Disco; RAID 6 proporciona (N - 2) * Capacidad_Disco; y RAID 10 proporciona (N / 2) * Capacidad_Disco. En pools ZFS RAIDZ, reste un 3,125 % adicional (1/32) correspondiente a la asignación de espacio de holgura (slop space) y convierta terabytes decimales a tebibytes binarios mediante el factor 0,9095 (1 TiB = 10^12 / 2^40 TB).

¿Por qué la capacidad formateada de un RAID es menor que el tamaño comercial del disco duro?▼

Los fabricantes de discos duros comercializan la capacidad en notación decimal, donde 1 terabyte (TB) = 10^12 bytes, mientras que los sistemas operativos direccionan el almacenamiento en tebibytes binarios (TiB), donde 1 TiB = 2^40 = 1 099 511 627 776 bytes. Esta discrepancia matemática genera de inmediato una reducción aparente de capacidad del 9,0949 % (por ejemplo, una unidad de 18 TB ofrece solo ~16,37 TiB de espacio bruto). Los metadatos de las tablas de partición (GPT EFI), las tablas de asignación del sistema de archivos (tablas de inodos, extensiones de journaling) y la reserva de espacio de holgura de ZFS reducen aún más la capacidad final disponible.

¿Por qué RAID 5 es peligroso con discos duros de alta capacidad de 16 TB o 18 TB?▼

RAID 5 tolera el fallo de un solo disco y exige leer íntegramente cada uno de los discos supervivientes para recalcular la paridad durante la reconstrucción. Las unidades SATA de consumo estándar especifican una tasa de error de lectura irrecuperable (URE) de 10^-14 (1 bit erróneo por cada 12,5 TB leídos). Reconstruir una matriz de 4 discos de 16 TB requiere leer 48 TB de datos continuos, lo que genera una probabilidad estadística de fallo en la reconstrucción superior al 98 % según el modelo de Poisson P = 1 - exp(-Bits * BER), provocando la destrucción total de la matriz ante un único sector ilegible.

¿Cuál es la diferencia entre RAID 10 y RAID 6 para el almacenamiento de bases de datos?▼

RAID 10 distribuye datos en bandas (striping) sobre pares en espejo con un factor de penalización de escritura de 2, mientras que RAID 6 calcula paridad dual P+Q mediante Reed-Solomon con un factor de penalización de 6. Para bases de datos transaccionales de alta concurrencia (MySQL, PostgreSQL, Oracle) con alta carga de E/S de escritura aleatoria, RAID 10 ofrece un 300 % más de IOPS de escritura aleatoria y reconstruye unidades degradadas sin sobrecarga de recálculo de paridad. RAID 6 está optimizado para transferencias secuenciales intensivas de lectura, repositorios de copias de seguridad y almacenamiento masivo de archivo de coste optimizado.

¿En qué se diferencia ZFS RAIDZ2 de un RAID 6 tradicional por hardware?▼

ZFS RAIDZ2 sustituye los tamaños de banda fijos y las controladoras hardware con caché respaldada por batería (BBU) por anchos de banda dinámicos y sumas de comprobación criptográficas Fletcher4/SHA-256 de 128 bits, erradicando por completo el catastrófico agujero de escritura ('write hole') de RAID 5 y 6. Durante la reconstrucción (resilvering), ZFS solo lee y recalcula los metadatos reales y bloques de datos activos en lugar de escanear sectores vacíos sin asignar, y detecta y repara automáticamente la corrupción silenciosa de datos (bit rot) durante los ciclos programados de depuración (scrub).

¿Qué es la regla del 80 % en pools ZFS y cómo funciona el espacio de holgura (slop space)?▼

La regla del 80 % de ZFS establece que los pools de almacenamiento no deben superar el 80 % de uso de capacidad para evitar pasar de un asignador first-fit con mapa de espacio O(1) a una búsqueda best-fit de alta latencia que desata una fragmentación severa y degradación de IOPS. Simultáneamente, OpenZFS aplica por defecto una reserva de espacio de holgura del 3,125 % (1/32 de la capacidad bruta total del pool, con un mínimo de 128 MiB) regida por 'spa_slop_shift=5', asegurando que operaciones administrativas críticas como eliminación de instantáneas, destrucción de sistemas de archivos y escritura de metadatos se completen con éxito incluso si el pool alcanza el 100 % de la cuota de usuario.

¿Cuánto tiempo tarda la reconstrucción de un RAID con discos duros de 16 TB o 20 TB?▼

La duración de la reconstrucción está determinada por la capacidad bruta de la unidad, el ancho de banda secuencial sostenido de escritura, el rendimiento del backplane de la controladora y la carga concurrente de E/S de las aplicaciones. Sin carga de trabajo en segundo plano, un disco empresarial de 18 TB y 7200 RPM con una tasa sostenida de 200 MB/s tarda entre 25 y 30 horas en reconstruirse. Bajo una carga transaccional de producción del 50 % o si se utilizan unidades con tecnología SMR (Shingled Magnetic Recording), la reconstrucción se prolonga de 5 a 9 días, ampliando drásticamente la ventana de vulnerabilidad ante fallos secundarios de hardware.

Herramientas y utilidades relacionadas

Todas las herramientas →