Compraste un montón de discos. La hoja de cálculo dice “un vdev RAIDZ2 gigante” es lo más eficiente. Luego producción pregunta “¿por qué la latencia subió a 80ms durante un scrub?” y tu teléfono on-call suena con “felicidades, ahora es tu problema”.
La planificación del ancho de vdev es el momento en que el almacenamiento deja de ser comprar y se convierte en gestión del riesgo. Los vdevs más anchos pueden parecer capacidad y rendimiento gratis. No lo son. Cambian los dominios de fallo, los tiempos de reconstrucción, el comportamiento de I/O de bloques pequeños y la forma en que ZFS distribuye el trabajo.
El modelo mental: los vdevs son las unidades de rendimiento
Los pools ZFS se construyen a partir de vdevs (dispositivos virtuales). El pool stripea datos a través de vdevs, no a través de discos individuales. Dentro de cada vdev, ZFS depende del esquema de redundancia del vdev (mirror, RAIDZ1/2/3, dRAID, etc.) para convertir varios discos físicos en un único dispositivo lógico.
Esa última frase es la trampa. La gente ve 24 discos y piensa “24 spindles de IOPS”. Con ZFS, obtienes aproximadamente “tantos IOPS como vdevs,” ajustado por el layout. Un pool con un vdev RAIDZ2 es una cola de I/O (por vdev de nivel superior) para lecturas/escrituras aleatorias. Un pool con seis vdevs mirror son seis colas de I/O. Mismos discos físicos. Comportamiento distinto bajo carga.
La planificación del ancho de vdev es elegir un dominio de fallo y una forma de rendimiento. Vdevs más anchos consolidan capacidad y pueden mejorar el rendimiento secuencial grande. También concentran el riesgo y pueden hacer que I/O aleatorio pequeño se sienta como caminar por melaza.
Dos reglas que siguen siendo ciertas cuando todo lo demás cambia
- Regla 1: Si tu workload es intensivo en I/O aleatorio (VMs, bases de datos), generalmente quieres más vdevs, no vdevs más anchos.
- Regla 2: Si tu workload es mayormente secuencial grande (backups, medios, archivos), RAIDZ ancho puede estar bien—hasta que las ventanas de reconstrucción se conviertan en tu nuevo hobby.
Una cita para tener en la pared, porque resume el juego: La esperanza no es una estrategia.
(idea parafraseada, a menudo asociada con cultura de operaciones y fiabilidad)
Broma #1: Un “vdev gigante” es como una carretera de un solo carril—genial hasta el primer coche averiado, y entonces todos aprenden nuevas palabras.
Datos rápidos y contexto histórico
A los ingenieros de almacenamiento les encanta discutir sobre el ancho de vdev porque la “respuesta correcta” depende del workload, la tolerancia al riesgo y de cuánto odias los fines de semana. Aun así, algo de historia ayuda a explicar por qué las compensaciones se ven así.
- ZFS nació en Sun Microsystems a mediados de los 2000 con un modelo de “gestor de volúmenes integrado + sistema de archivos”. Por eso existen los vdevs: el sistema de archivos controla las decisiones de RAID.
- RAIDZ no es el RAID5/6 clásico de hardware. ZFS usa ancho de stripe variable para RAIDZ, lo que reduce los problemas clásicos del “raid5 write hole” cuando se combina con copy-on-write y checksums.
- “IOPS por vdev” se volvió una regla empírica porque ZFS despacha I/O a nivel de vdev. No es toda la historia, pero predice el dolor sorprendentemente bien.
- Los scrubs fueron diseñados como operaciones de integridad, no como característica de rendimiento. Leen todo para verificar checksums. En vdevs anchos con discos grandes, “todo” es… mucho.
- El crecimiento de capacidad de los discos superó a los IOPS durante décadas. Un HDD moderno es enorme pero no rápido. Los vdevs anchos amplifican el desajuste “grande pero lento” durante el resilver.
- La realidad de sectores 4K (ashift) cambió la planificación. Sectores desalineados (ashift incorrecto) pueden multiplicar silenciosamente la amplificación de escritura y la latencia, especialmente en RAIDZ.
- El SSD cambió el juego pero no eliminó la física. Puedes hacer vdevs anchos en SSD y “funcionará”, pero las matemáticas de reconstrucción y paridad siguen costando CPU y latencia.
- dRAID existe en gran parte porque el tiempo de resilver dolía. Distribuye la capacidad de repuesto y el trabajo de reconstrucción, reduciendo la ventana típica de “un disco a la vez durante días” de RAIDZ ancho en HDD grandes.
Qué cuesta realmente “más discos por vdev”
1) Compras capacidad con un dominio de fallo mayor
Un vdev de nivel superior es la unidad atómica de redundancia. Si un vdev RAIDZ2 puede perder dos discos, entonces cualquier tercer fallo de disco en ese mismo vdev es catastrófico para el pool. Cuando haces el vdev más ancho, pones más discos en el mismo cubo de “se permiten dos fallos”.
Con varios vdevs más pequeños, los fallos tienden a repartirse entre vdevs. Con un vdev ancho, el destino del pool depende de ese grupo y su presupuesto de paridad. Ese es el coste del “radio de daño”.
2) Las reconstrucciones duran más, y las reconstrucciones largas son un impuesto de fiabilidad
ZFS resilveriza a nivel de bloques (solo datos asignados) en muchos casos, lo cual es genial. Pero el pool aún necesita escanear metadatos, y todavía debes leer de los discos sobrevivientes y escribir bloques reconstruidos. A medida que los discos crecen, “solo asignados” aún puede ser muchos terabytes.
Los vdevs anchos aumentan el número de discos que participan en la I/O de reconstrucción por cada bloque. Eso significa más lecturas totales durante el resilver, más probabilidad de encontrar errores de sectores latentes, más contención con workloads de producción y más tiempo en la ventana de peligro donde un segundo/tercer fallo termina la historia.
3) I/O aleatorio pequeño: la paridad no es gratis
Los mirrors son amables con I/O aleatorio: las lecturas se pueden balancear entre ambos lados y las escrituras pequeñas son relativamente baratas. RAIDZ debe calcular paridad y a menudo hacer read-modify-write para stripes parciales. ZFS es inteligente, pero no es magia.
Al aumentar el ancho del vdev, el tamaño de “full stripe” aumenta. Para workloads de bloques pequeños (comunes en VMs y bases de datos), a menudo escribes stripes parciales. Eso empuja a RAIDZ a lecturas extra y actualizaciones de paridad. Vdevs más anchos pueden significar más trabajo por escritura y mayor variación de latencia.
4) La latencia se vuelve más variable bajo trabajos en segundo plano
Scrubs, resilvers y lectores secuenciales pesados tocan cada disco. En un vdev ancho, esas operaciones activan más discos a la vez y lo hacen por más tiempo. El pool aún puede servir I/O normal, pero las colas se profundizan. Los percentiles de latencia suben. Y son los percentiles los que te despiertan por la noche, no la media.
5) No obtienes realmente “más rendimiento” como crees
Para throughput secuencial, RAIDZ ancho puede ayudar porque más discos contribuyen a cada stripe. Para IOPS aleatorias, especialmente escrituras, un vdev RAIDZ se comporta como un solo dispositivo con sobrecarga de paridad. Si quieres más IOPS aleatorias, quieres más vdevs de nivel superior.
Así que el argumento de “más discos por vdev” suele ser: mejor eficiencia de capacidad, a veces mejor throughput secuencial, y menos vdevs que gestionar. La factura llega como: peor rendimiento aleatorio por TB, mayor dominio de fallo, reconstrucciones más largas, mayor impacto de trabajos en segundo plano.
6) La planificación de la expansión se vuelve incómoda
ZFS históricamente expandía pools añadiendo vdevs, no “añadiendo discos a un vdev RAIDZ”. La expansión de RAIDZ se ha vuelto posible en OpenZFS moderno, pero no es una carta gratuita: es una operación pesada, toma tiempo, y sigues quedándote con un vdev más ancho y todos los costes anteriores.
Planificar el ancho del vdev es también planear cómo crecerás. Si tu modelo de crecimiento es “comprar la misma estantería otra vez”, vdevs más pequeños que coincidan con la geometría de la estantería tienden a envejecer mejor.
Ajusta el ancho del vdev al workload: secuencial, aleatorio, mixto
Secuencial grande (repositorios de backup, medios, archivo)
Las escrituras y lecturas secuenciales son donde RAIDZ puede lucir excelente. Streams de bloques grandes permiten a ZFS ensamblar I/O grande y los discos se mantienen ocupados de forma predecible. Vdevs más anchos pueden aumentar el throughput agregado porque más discos participan en cada stripe.
Pero: los repositorios de backup también hacen scrubs, purgas y a veces muchas restauraciones paralelas. Si construyes un vdev RAIDZ2 monstruoso, el trabajo en segundo plano y las tormentas de restauración competirán en la misma cola de un solo vdev. Si puedes tolerarlo (y tu RTO también), bien. Si tu restauración es el momento en que el CEO descubre el almacenamiento, no apuestes.
I/O aleatorio pesado (datastores de VM, bases de datos)
Aquí, RAIDZ ancho suele ser la herramienta equivocada. No porque sea “lento”, sino porque es impredecible bajo presión. La latencia de escritura aleatoria es la asesina. Los mirrors (o más vdevs RAIDZ más estrechos) distribuyen I/O entre más colas independientes y reducen la sobrecarga de paridad.
Si debes usar RAIDZ para almacenamiento de VMs en HDD, mantén vdevs más estrechos, usa suficientes vdevs para obtener paralelismo y sé honesto sobre las expectativas de rendimiento. Si es SSD/NVMe, RAIDZ puede ser aceptable, pero los mirrors aún ganan en latencia cola en muchos workloads reales.
Workloads mixtos (fileshares + VMs + backups en el mismo pool)
Aquí es donde “un pool para gobernarlos a todos” se complica. Workloads mixtos generan tamaños de I/O mixtos. RAIDZ odia escrituras pequeñas aleatorias mientras otro proceso hace lecturas secuenciales. Tu monitor mostrará “utilización” y “throughput” y aun así recibirás quejas porque la latencia es lo que sienten los humanos.
En la vida corporativa, los workloads mixtos ocurren por presupuesto. Si no puedes separar pools, al menos divide vdevs: más vdevs le da a ZFS opciones. También considera special vdevs para metadata/bloques pequeños si sabes lo que haces—bien hecho, puede transformar workloads con muchos directorios y archivos pequeños.
Ancho RAIDZ, paridad y la física que no puedes negociar
Niveles de paridad: RAIDZ1 vs RAIDZ2 vs RAIDZ3
La paridad es tu póliza de seguro. RAIDZ1 (paridad simple) cada vez es peor idea con HDD grandes en entornos serios porque las ventanas de reconstrucción son largas y los errores de lectura latentes no son un cuento. RAIDZ2 es la línea práctica para pools HDD que importan. RAIDZ3 existe para cuando quieres dormir durante un resilver largo en discos enormes, pero cuesta más en overhead de paridad y rendimiento.
La paridad no escala con el ancho. Un RAIDZ2 de 6 discos y uno de 16 discos toleran ambos dos fallos. Un vdev más ancho significa “el mismo número de fallos permitidos sobre más discos”. Esa es la compensación central de fiabilidad.
Recordsize, volblocksize y por qué “escrituras pequeñas” se vuelven problema de todos
ZFS escribe en records (recordsize por defecto a menudo 128K para filesystems), pero los zvols para dispositivos de bloque tienen volblocksize (a menudo 8K/16K). Bases de datos e imágenes de VM tienden a generar escrituras de 4K–16K. Si tu full-stripe de RAIDZ es grande y tus escrituras reales son pequeñas, estás en territorio de stripe parcial. Las escrituras parciales son donde la sobrecarga de paridad y read-modify-write aparecen como latencia.
La solución no es “tocar perillas hasta que mejore”. La solución es: elegir un layout de vdev que coincida con la forma de I/O del workload, y ajustar recordsize/volblocksize intencionalmente.
La compresión cambia las matemáticas del ancho (en su mayoría para bien)
La compresión (como lz4) reduce bytes escritos. Eso puede reducir tiempo de disco y a veces el trabajo de paridad. También puede hacer que las escrituras sean más pequeñas y dispersas, lo que aumenta el churn de metadata. Normalmente la compresión es ganancia, pero mídelo—especialmente en sistemas ya limitados por CPU.
Special vdevs y SLOG: herramientas poderosas y afiladas
Los special vdevs (metadata y bloques pequeños) pueden rescatar el rendimiento para workloads de archivos pequeños en RAIDZ HDD. Pero se vuelven dispositivos críticos: perder el special vdev puede hacer que pierdas el pool. Eso significa special vdevs en mirror con buenos dispositivos y monitorización.
SLOG (separate log) ayuda solo para escrituras síncronas. No arreglará la latencia general. Ponlo solo si entiendes tu workload sync, no porque lo viste en un hilo de foro.
Broma #2: Comprar un SLOG para arreglar latencia de escritura aleatoria es como comprar un felpudo más bonito para arreglar un techo con goteras.
Matemáticas de resilver/reconstrucción: tiempo, ventana de riesgo y radio de daño
Por qué los vdevs anchos hacen que el riesgo de resilver se sienta personal
Durante un resilver, los discos sobrevivientes se leen intensamente y de forma continua. Eso es estrés. También es cuando descubres qué unidades estaban acumulando errores silenciosos. Un vdev más ancho significa más discos en el mismo grupo de redundancia, y más discos deben leerse para reconstruir datos. El resilver toca más hardware y dura más, lo que aumenta la probabilidad de que algo más falle antes de terminar.
Datos asignados vs disco completo: ZFS ayuda, pero no apuestes tu trabajo a ello
El resilver de ZFS suele ser más rápido que la reconstrucción clásica de RAID porque puede saltarse bloques no asignados. Genial. Pero los pools reales no están vacíos, y los metadatos aún necesitan escaneo. Además, “rápido” es relativo cuando tus discos tienen decenas de terabytes y el pool está ocupado.
Los vdevs anchos aumentan el daño colateral durante la reconstrucción
Aun si un resilver termina con éxito, un vdev ancho tiende a degradar más el rendimiento durante el proceso porque más discos están ocupados con trabajo de reconstrucción. Si el pool sirve workloads sensibles a latencia, la ventana de resilver se convierte en un incidente de rendimiento.
Implicación operativa: tu plan de reconstrucción es parte de la arquitectura
No planifiques el ancho de vdev en el vacío. Planifícalo con:
- Qué tan rápido puedes reemplazar un disco (personas, repuestos, SLA del proveedor).
- Cuánta degradación de rendimiento toleras durante un resilver.
- Cuánto puede funcionar tu pool en “redundancia reducida” de forma segura.
- Qué sucede si un segundo disco falla durante el resilver.
Tres micro-historias corporativas (anonimizadas, reales suficiente)
1) Incidente causado por una suposición errónea: “24 discos = muchos IOPS”
La empresa estaba en pleno crecimiento, migrando desde un SAN legado a un appliance basado en ZFS. Tenían un requisito en papel: “soportar la granja de VMs existente sin degradación de rendimiento”. Un miembro del equipo hizo la aritmética familiar: 24 HDD, 7200 RPM, luego “plenty” de IOPS. Construyeron un único vdev RAIDZ2 porque maximiza el espacio usable y se veía ordenado.
Pasó las pruebas iniciales. El benchmark sintético usó lecturas y escrituras secuenciales grandes. Los gráficos parecían heroicos. La migración siguió y durante una semana estuvo tranquila.
Luego llegó la tormenta de arranque del lunes por la mañana. Las VMs iniciaron, el antivirus actualizó, Windows hizo cosas de Windows, y la latencia subió. No gradualmente—en picos. Los tickets decían “todo está lento”. Los logs del hypervisor decían “storage latency 100–200ms”. La caja de almacenamiento no estaba “caída”, simplemente se estaba ahogando.
Descubrieron el error: el pool tenía un vdev de nivel superior. Una cola. I/O aleatorio de docenas de VMs se acumuló en esa cola, y la sobrecarga de paridad de RAIDZ empeoró las escrituras. La solución no fue una flag de tuning. La solución fue arquitectónica: reconstruir el pool como múltiples vdevs (mirrors en su caso), aceptar menos capacidad usable y obtener latencia predecible. La dura lección: Los IOPS vienen del recuento de vdevs y del tipo de medio, no del simple número de discos.
2) Optimización que salió mal: “Hagamos vdevs más anchos para reducir overhead de paridad”
Otra organización tenía un gran repositorio de backups en HDD RAIDZ2. Funcionaba, no rápido, pero aceptable. Decidieron “optimizar” aumentando el ancho del vdev durante una expansión: menos vdevs, cada uno más ancho, layout más simple, algo mejor eficiencia de capacidad. Además, menos vdevs significaban menos cosas que monitorizar, lo que siempre suena bien en una reunión.
Para ingest secuencial grande, mejoró. Los jobs de ingest terminaron antes y todos se felicitaron. Luego llegó el scrub trimestral. Los scrubs duraron más de lo esperado, pero eso se toleró.
El fallo real apareció semanas después durante un día con muchas restauraciones paralelas. Tenían múltiples restores paralelos mientras ya corría un resilver (porque, por supuesto, un disco falló durante el periodo ocupado). El vdev más ancho implicó que el resilver involucrara más discos, lo que significó más contención. El rendimiento de las restores colapsó y el RTO prometido a clientes internos se convirtió en un incidente de rendimiento.
La optimización “funcionó” para el mejor escenario y falló para el peor. Esa es una trampa clásica: haces benchmark del día soleado y luego vives la tormenta.
3) Práctica aburrida pero correcta que salvó el día: vdevs relativamente estrechos, hot spares y disciplina de scrubs
Un tercer equipo gestionaba un entorno mixto: directorios home, artefactos de build y algo de almacenamiento de VM. Fueron conservadores. Construyeron múltiples vdevs RAIDZ2 de anchura moderada, mantuvieron al menos un spare probado on-site y programaron scrubs regularmente con monitorización de duración y conteo de errores.
No fue glamuroso. La eficiencia de capacidad no estaba “maximizadas”. También tenían una regla: ningún pool por encima de cierto umbral de utilización (apuntaban a mantener espacio libre real, no espacio libre de fantasía). Finanzas se quejaba; los ingenieros asentían y siguieron adelante.
Un viernes por la tarde falló un disco. El spare se insertó inmediatamente y empezó el resilver. Durante la noche, un segundo disco en el mismo chasis dio errores. Como los vdevs eran más estrechos y el historial de scrubs ya había identificado un par de discos marginales a principios de año, tenían reemplazos listos. El segundo fallo afectó a otro vdev, así que la redundancia se mantuvo. El pool permaneció online, el rendimiento bajó pero siguió usable, y el lunes no hubo revisión de incidentes.
La práctica aburrida no “previno” la falla. Redujo el radio de daño y acortó el tiempo en la ventana de peligro. Eso es lo que hace una buena arquitectura de almacenamiento.
Guía rápida de diagnóstico: encuentra el cuello de botella antes de “tunear”
Cuando el rendimiento es malo, los equipos suelen empezar a girar perillas de ZFS como si fuera una radio. No lo hagas. Primero, identifica el recurso limitante y si la limitación es estructural (ancho/layout de vdev) o situacional (scrub, resilver, un disco fallando).
Primero: confirma la topología del pool y su estado actual
- ¿Es un RAIDZ ancho o muchos vdevs?
- ¿Está corriendo un scrub/resilver?
- ¿Hay errores de lectura/escritura/checksum?
Segundo: determina si el dolor es latencia, throughput o CPU
- Alta latencia con bajo throughput a menudo significa cola, I/O aleatorio pequeño o un disco enfermo.
- Alto throughput con latencia aceptable significa que probablemente estás bien.
- Alta CPU durante escrituras puede significar compresión, checksum, trabajo de paridad RAIDZ o mismatch de recordsize.
Tercero: aísla si un vdev/disco es el matón
- Si un disco muestra alta latencia o errores, puede arrastrar a todo el vdev RAIDZ.
- Si un vdev está saturado y otros están inactivos, estás limitado por el número de vdevs, no por el recuento de discos.
Cuarto: comprueba el espacio libre del pool y los indicadores de fragmentación
- Pools muy llenos se comportan mal, especialmente RAIDZ con bloques pequeños.
- El espacio libre es presupuesto de rendimiento, no solo capacidad.
Quinto: decide si la solución es operativa o arquitectónica
- Soluciones operativas: reemplazar disco fallando, reprogramar scrub, limitar resilver, añadir SLOG solo si el workload sync lo requiere.
- Soluciones arquitectónicas: añadir vdevs, reconstruir como mirrors, dividir workloads entre pools, considerar special vdevs o dRAID cuando proceda.
Tareas prácticas: 12+ comandos, salidas y decisiones
Estos son los comandos que ejecutas cuando alguien dice “el almacenamiento está lento” y necesitas responder con evidencia. Cada tarea incluye qué significa la salida y la decisión que tomas.
Task 1: Identificar layout de vdev y estado actual
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 07:12:44 with 0 errors on Tue Dec 24 03:12:01 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
/dev/disk/by-id/ata-d1 ONLINE 0 0 0
/dev/disk/by-id/ata-d2 ONLINE 0 0 0
/dev/disk/by-id/ata-d3 ONLINE 0 0 0
/dev/disk/by-id/ata-d4 ONLINE 0 0 0
/dev/disk/by-id/ata-d5 ONLINE 0 0 0
/dev/disk/by-id/ata-d6 ONLINE 0 0 0
/dev/disk/by-id/ata-d7 ONLINE 0 0 0
/dev/disk/by-id/ata-d8 ONLINE 0 0 0
errors: No known data errors
Significado: Un vdev RAIDZ2 con 8 discos. El scrub completó, sin errores.
Decisión: Si este pool aloja workloads de I/O aleatorio y la queja es latencia, probablemente estás limitado por el número de vdevs. Considera añadir más vdevs de nivel superior (o reconstruir el layout) en lugar de perseguir tuning.
Task 2: Mostrar utilización y latencia a nivel de vdev
cr0x@server:~$ zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 22.1T 12.7T 310 420 42.1M 55.8M
raidz2-0 22.1T 12.7T 310 420 42.1M 55.8M
ata-d1 - - 38 52 5.3M 7.1M
ata-d2 - - 40 50 5.4M 6.9M
ata-d3 - - 39 52 5.4M 7.1M
ata-d4 - - 38 53 5.2M 7.2M
ata-d5 - - 39 53 5.4M 7.2M
ata-d6 - - 38 53 5.2M 7.2M
ata-d7 - - 39 53 5.4M 7.2M
ata-d8 - - 39 54 5.4M 7.3M
-------------------------- ----- ----- ----- ----- ----- -----
Significado: Todo el I/O pasa por un vdev. La distribución en discos luce pareja (bien), pero aún puede ser un cuello de botella de cola única para I/O aleatorio.
Decisión: Si necesitas más IOPS aleatorias, añade otro vdev (misma redundancia) para aumentar el paralelismo a nivel superior. Hacer más ancho el vdev no ayuda aquí; más vdevs sí.
Task 3: Detectar un disco fallando por latencia, no solo por errores
cr0x@server:~$ iostat -x 1 3
Linux 6.8.0 (server) 12/26/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
6.12 0.00 3.44 9.33 0.00 81.11
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 6.0 12.0 512 2048 256.0 0.7 38.2 12.4 51.1 2.4 4.3
sdb 45.0 60.0 5200 7600 245.3 9.9 96.7 90.2 101.5 3.1 32.5
sdc 46.0 59.0 5150 7550 244.9 2.1 19.4 17.2 21.2 2.9 30.8
Significado: sdb tiene mucho mayor await y profundidad de cola que sus pares. Podría estar reintentando o reasignando internamente.
Decisión: Saca SMART y considera reemplazo proactivo. Un disco lento puede estrangular un RAIDZ porque cada stripe espera al más lento.
Task 4: Comprobar contadores SMART y historial de self-test
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'Reallocated|Pending|Uncorrect|Power_On_Hours|SMART overall|Self-test'
SMART overall-health self-assessment test result: PASSED
Power_On_Hours 37124
Reallocated_Sector_Ct 12
Current_Pending_Sector 3
Offline_Uncorrectable 1
SMART Self-test log structure revision number 1
# 1 Extended offline Completed: read failure 90% 37110 12345678
Significado: “PASSED” es una señal débil. Sectores pending/uncorrectable más test extendido fallido es una señal fuerte.
Decisión: Reemplaza el disco antes de que sea un segundo fallo durante el resilver. Considera correr un scrub después del reemplazo para validar.
Task 5: Verificar ashift (alineación de sectores) del pool
cr0x@server:~$ zdb -C tank | egrep -m1 'ashift|vdev_tree'
ashift: 12
Significado: ashift=12 significa que se asumen sectores de 4K. Bueno para HDD/SSD modernos.
Decisión: Si ves ashift=9 en discos 4K, espera amplificación de escritura y bajo rendimiento. La solución requiere reconstruir el pool correctamente; no puedes “tunear” ashift después.
Task 6: Identificar datasets y si usas zvols (VMs) vs filesystems
cr0x@server:~$ zfs list -o name,type,used,available,recordsize,volblocksize -r tank
NAME TYPE USED AVAIL RECSIZE VOLBLOCK
tank filesystem 22.1T 12.7T 128K -
tank/vmstore filesystem 8.2T 12.7T 128K -
tank/vmstore/zvol1 volume 600G 12.7T - 8K
tank/backups filesystem 10.3T 12.7T 1M -
Significado: Las VMs usan un zvol con volblocksize 8K; backups usan recordsize 1M (bueno para secuencial).
Decisión: Si la latencia de VMs es mala en un RAIDZ ancho, considera mover almacenamiento de VMs a mirrors o SSD, o aumentar el número de vdevs. Para backups, RAIDZ ancho puede estar bien.
Task 7: Comprobar sync settings y si SLOG importaría
cr0x@server:~$ zfs get -o name,property,value,source sync tank/vmstore/zvol1
NAME PROPERTY VALUE SOURCE
tank/vmstore/zvol1 sync standard local
Significado: Las escrituras sync son obedecidas. Si tu workload es muy sync-heavy (bases de datos, NFS con sync), la latencia puede estar dominada por el comportamiento del ZIL.
Decisión: Considera SLOG solo si confirmas carga significativa de escrituras sync y puedes ofrecer dispositivos con protección contra pérdida de energía. Si no, no lo pongas.
Task 8: Medir presión de escritura sync vía estadísticas ZIL (Linux OpenZFS)
cr0x@server:~$ cat /proc/spl/kstat/zfs/zil | egrep 'zil_commit|zil_itx_count|zil_itx_indirect_count'
zil_commit 18442
zil_itx_count 9921
zil_itx_indirect_count 144
Significado: Hay commits ZIL no triviales. Si esto sube rápidamente durante la ventana de queja, las escrituras sync están involucradas.
Decisión: Si la latencia de escrituras sync es el cuello de botella, evalúa SLOG (en mirror) o batching en la aplicación. Si no, no culpes al ZIL.
Task 9: Confirmar si un scrub/resilver está corriendo y cuánto progresa
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 08:11:02 2025
9.21T scanned at 1.12G/s, 2.03T issued at 252M/s, 22.1T total
0B repaired, 9.19% done, 1 day 01:33:40 to go
config:
...
Significado: El scrub está corriendo y tardará más de un día. Ese es mucho tiempo para compartir discos con producción.
Decisión: Si esto impacta workloads sensibles a latencia, programa scrubs en ventanas más tranquilas y considera vdevs más estrechos/más vdevs en futuras construcciones para reducir el impacto por vdev.
Task 10: Comprobar espacio libre del pool y flags de asignación especial
cr0x@server:~$ zpool list -o name,size,alloc,free,cap,health
NAME SIZE ALLOC FREE CAP HEALTH
tank 34.8T 22.1T 12.7T 63% ONLINE
Significado: 63% usado es cómodo. Si regularmente estás por encima de ~80–85% en RAIDZ con workloads mixtos, espera mayor fragmentación y latencia.
Decisión: Si la capacidad es alta, planifica expansión antes de llegar al precipicio. Expandir es más fácil que recuperar, y es más barato que explicar al negocio por qué las escrituras se volvieron lentas “sin razón”.
Task 11: Identificar distribución de tamaños de bloque con una muestra fio rápida
cr0x@server:~$ fio --name=randwrite --filename=/tank/vmstore/testfile --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --size=8G --runtime=30 --time_based --direct=1
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=32
...
write: IOPS=820, BW=3.2MiB/s (3.4MB/s)(96MiB/30001msec)
lat (usec): min=450, max=280000, avg=38500.12, stdev=42000.55
Significado: Escrituras aleatorias 4K con IOPS bajas y latencia máxima/media muy alta. En RAIDZ HDD esto es dolor esperado.
Decisión: Si esto se parece al workload de producción, deja de intentar tunearlo. Usa mirrors/SSD, aumenta el número de vdevs o separa almacenamiento de VMs del almacenamiento masivo.
Task 12: Comprobar presión de ARC (memoria) y si las lecturas son cache hits o hits en disco
cr0x@server:~$ arcstat 1 3
time read miss miss% dmis dm% pmis pm% arcsz c
08:32:11 12K 4K 33% 2K 16% 2K 16% 96G 110G
08:32:12 11K 5K 45% 3K 27% 2K 18% 96G 110G
08:32:13 13K 4K 30% 2K 15% 2K 15% 96G 110G
Significado: La tasa de aciertos del ARC es aceptable. Si miss% es alto y estás limitado por latencia de lectura, los discos están haciendo trabajo real.
Decisión: Si las lecturas fallan en ARC y tus discos ya están ocupados, no hagas vdevs más anchos esperando milagros. Considera añadir RAM (si razonable), separar workloads o usar special vdev/L2ARC solo después de medir.
Task 13: Comprobar errores de checksum indicando corrupción silenciosa o problemas de cableado
cr0x@server:~$ zpool status -v tank | egrep -A2 'READ|WRITE|CKSUM'
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
Significado: Sin errores. Si ves CKSUM errors, no asumas “disco malo”—a menudo es cableado, HBA, expander o alimentación.
Decisión: Si CKSUM crece, investiga la ruta de hardware (cambia cable, puerto, HBA). No reconstruyas el layout para arreglar un cable suelto.
Task 14: Inspeccionar propiedades de dataset que influyen en la forma de I/O
cr0x@server:~$ zfs get -o name,property,value,source compression,atime,recordsize,logbias,primarycache tank/vmstore tank/backups
NAME PROPERTY VALUE SOURCE
tank/vmstore compression lz4 local
tank/vmstore atime off local
tank/vmstore recordsize 128K default
tank/vmstore logbias latency default
tank/vmstore primarycache all default
tank/backups compression lz4 local
tank/backups atime off local
tank/backups recordsize 1M local
tank/backups logbias throughput local
tank/backups primarycache all default
Significado: Backups afinados para throughput; VM store defaults pueden estar bien pero las elecciones de zvol importan más que recordsize.
Decisión: Si un dataset está afinado al revés para su workload (p. ej., recordsize demasiado pequeño para backups, sync forzado sin razón), corrige propiedades. Pero no esperes que las propiedades superen un mal layout de vdev.
Errores comunes: síntomas → causa raíz → solución
Error 1: “Picos de latencia durante scrubs; los usuarios se quejan”
Síntomas: Aumentos de latencia previsibles cuando empieza un scrub; workloads interactivos se vuelven lentos; zpool status muestra scrub en progreso.
Causa raíz: Vdev ancho + HDD significa que el scrub es largo y compite por el mismo ancho de banda y colas de disco que el I/O de producción.
Solución: Programa scrubs fuera de horas pico; considera múltiples vdevs (más paralelismo de nivel superior) en futuras builds; separa workloads sensibles a latencia de pools de datos masivos.
Error 2: “Tenemos 20+ discos así que el rendimiento de VMs debería ser excelente”
Síntomas: Bajas IOPS, alta latencia tail, throughput parece aceptable pero las apps time out; especialmente malo durante boot storms.
Causa raíz: Uno (o muy pocos) vdevs RAIDZ. I/O aleatorio limitado por el número de vdevs y overhead de paridad.
Solución: Usa mirrors para VMs/bases de datos en HDD, o aumenta el número de vdevs de nivel superior. Si debes usar RAIDZ, mantén vdevs más estrechos y añade más de ellos.
Error 3: “Resilver tarda una eternidad; estamos nerviosos varios días”
Síntomas: Tiempo estimado de resilver es de varios días; rendimiento degradado; la ansiedad por un segundo fallo se vuelve un estilo de vida.
Causa raíz: Vdev ancho + discos grandes + alta utilización + workload en curso. La ventana de reconstrucción es larga y estresante.
Solución: Mantén menor utilización; elige vdevs más estrechos o dRAID cuando proceda; ten repuestos on-site; planifica throttling de reconstrucción y ventanas de mantenimiento.
Error 4: “Añadimos un SLOG y no cambió nada”
Síntomas: Misma latencia; sin mejora notable; a veces peor estabilidad por un SSD barato.
Causa raíz: El workload no está dominado por escrituras sync, o el SLOG no es seguro frente a pérdida de energía, o el verdadero problema es la amplificación de escritura aleatoria en RAIDZ ancho.
Solución: Mide la tasa de escribas sync primero; si es necesario, usa dispositivos empresariales y en mirror. Si no, quita la complejidad.
Error 5: “Un disco está ‘medio lento’ pero esperaremos”
Síntomas: Aún no hay errores ZFS, pero iostat muestra un disco con mayor latencia; timeouts ocasionales en logs.
Causa raíz: Unidad degradándose, ruta de cableado inestable o puerto de expander con problemas. RAIDZ espera al miembro más lento.
Solución: Reemplaza proactivamente o mueve el componente sospechoso. Valida con SMART y logs de errores. No esperes a que “falle” durante un resilver.
Error 6: “El pool está al 90% y las escrituras se pusieron lentas; debe ser un bug”
Síntomas: Latencia creciente con el tiempo; poco espacio libre; fragmentación y overhead de metadata suben.
Causa raíz: Copy-on-write necesita espacio libre para asignar eficientemente. RAIDZ sufre más cuando los segmentos libres disminuyen y las escrituras se dispersan.
Solución: Añade capacidad antes de que el pool esté lleno; aplica cuotas/reservas; archiva o borra; considera separar datos calientes y fríos en distintos pools.
Listas de verificación / plan paso a paso
Plan paso a paso para el ancho de vdev (lo que haría antes de comprar discos)
- Clasifica el workload: mayormente secuencial, mayormente aleatorio o mixto. Si no puedes clasificarlo, es mixto.
- Decide tu tolerancia a fallos: RAIDZ2 como baseline para HDD; RAIDZ3 para discos muy grandes o tiempos de reemplazo largos; mirrors para capas de baja latencia.
- Elige la forma de rendimiento objetivo: cuántos IOPS aleatorios de lectura/escritura realmente necesitas y qué percentil de latencia es aceptable.
- Escoge primero el número de vdevs: el número de vdevs de nivel superior es tu presupuesto de paralelismo. Luego elige el ancho por vdev.
- Escoge el ancho del vdev con prudencia:
- Para HDD con VM/bases de datos: mirrors, múltiples vdevs.
- Para HDD backups/archivo: RAIDZ2 con ancho moderado; evita “un vdev gigante” a menos que realmente aceptes el riesgo de resilver.
- Planifica incrementos de crecimiento: añade vdevs con el tiempo; mantiene layouts consistentes. Evita un vdev “raro” que se comporte distinto.
- Mantén margen de utilización: fija un tope interno (a menudo ~80% para workloads mixtos) y trátalo como política, no sugerencia.
- Planifica las reconstrucciones: repuestos on-site, procedimiento documentado de reemplazo y monitorización para señales tempranas de fallo.
- Separa capas si es necesario: coloca workloads sensibles a latencia en mirrors/SSD, datos masivos en RAIDZ.
- Prueba con un benchmark representativo: random 4K/8K, mixto read/write, más un scrub corriendo, porque esa es la realidad.
Checklist operacional (qué verificar mensualmente)
- Calendario de scrub y última duración de scrub; investiga si la duración está aumentando.
- Contadores SMART y self-tests fallidos; reemplaza temprano.
- Tendencia de capacidad del pool y fecha proyectada de “80%”.
- zpool status limpio, sin CKSUM errors.
- Percentiles de latencia (no solo promedios) durante picos y durante operaciones de fondo.
FAQ
Q1: ¿Es “RAIDZ vdev más ancho = más rápido” alguna vez cierto?
Para throughput secuencial grande, sí: más discos por stripe pueden aumentar ancho de banda de lectura/escritura. Para I/O aleatorio, especialmente escrituras pequeñas, más ancho suele ser peor o al menos no mejor.
Q2: ¿Por qué la gente dice “los IOPS vienen de los vdevs”?
Porque ZFS stripea a través de vdevs de nivel superior. Cada vdev es una unidad de rendimiento con su propia cola. Más vdevs significan más paralelismo para I/O aleatorio.
Q3: ¿Cuál es un ancho “seguro” para RAIDZ2?
“Seguro” depende del tamaño del disco, tiempo de reemplazo y workload. En la práctica, anchuras moderadas son más fáciles de vivir que anchuras muy grandes porque las ventanas de resilver y el radio de daño crecen con el ancho.
Q4: Si tengo 24 discos, ¿debería hacer un RAIDZ2 de 24 discos?
Casi nunca para pools de propósito general o con muchas VMs. Obtendrás un dominio de fallo enorme y comportamiento de I/O aleatorio de un solo vdev. Mejor reparte en varios vdevs.
Q5: Los mirrors desperdician 50% de capacidad. ¿Por qué elegirlos?
Porque compran baja latencia, altos IOPS aleatorios, comportamiento de fallo más simple y resilvers más rápidos. La capacidad es más barata que las caídas de servicio.
Q6: ¿Añadir L2ARC arregla los problemas de I/O aleatorio en vdevs anchos?
A veces ayuda en workloads de lectura intensiva con patrones repetidos. No arreglará la latencia de escritura aleatoria ni el overhead de paridad. Además, L2ARC tiene consideraciones de memoria y warmup propias.
Q7: ¿Debería usar RAIDZ1 si tengo discos más pequeños?
Para cualquier cosa importante en HDD, RAIDZ1 es una apuesta innecesaria. RAIDZ2 es el default sensato. RAIDZ1 puede ser aceptable para datos no críticos, fácilmente reproducibles y con ventanas de reconstrucción cortas.
Q8: ¿Puedo expandir un vdev RAIDZ añadiendo discos luego?
OpenZFS moderno soporta expansión de RAIDZ, pero es una operación pesada y aún terminas con un vdev más ancho y sus costes. Muchas organizaciones prefieren añadir un nuevo vdev para crecer.
Q9: ¿dRAID resuelve el problema de reconstrucción de vdevs anchos?
dRAID reduce el tiempo de resilver al distribuir el trabajo de reconstrucción y la capacidad de repuesto. Puede ser una buena opción para pools HDD grandes, pero no sustituye universalmente a los mirrors en workloads de baja latencia.
Q10: ¿Cuál es el mayor error de planificación?
Diseñar priorizando la eficiencia de capacidad primero y tratar el comportamiento de rendimiento/reconstrucción como “problemas de tuning”. El layout es arquitectura. El tuning es condimento.
Siguientes pasos que puedes hacer esta semana
- Inventario tus pools: lista layouts de vdev, workloads servidos, duración de scrubs y latencia típica.
- Ejecuta la guía rápida de diagnóstico durante una ventana de queja y durante un scrub; compara resultados.
- Decide qué optimizas: baja latencia, alto throughput o TB utilizables máximos. Elige un objetivo primario por pool.
- Si estás limitado por número de vdevs: planea expansión añadiendo vdevs (o migrando a mirrors para la capa caliente), no ampliando el vdev existente.
- Si las ventanas de resilver te asustan: reduce el ancho de vdev en la próxima construcción, mantén más espacio libre y ten repuestos probados a mano.
- Escribe un runbook de reconstrucción: pasos de reemplazo de disco, comportamiento esperado de resilver y métricas que disparan escalamiento.
Si vas a retener una pauta de todo esto, que sea esta: No construyas tu primer pool ZFS como un vdev RAIDZ ancho a menos que el workload sea realmente secuencial y el riesgo sea verdaderamente aceptable. Cuando falla, no falla con educación.