Panel de salud de ZFS: las métricas que debes supervisar (o estás ciego)

Qué significa “saludable” en ZFS (y qué no)

“Salud” en ZFS no es solo “pool está ONLINE.” Eso es como declarar a un paciente sano porque está técnicamente en pie.
La salud real es: los datos son correctos, la redundancia sigue existiendo, el tiempo de recuperación está acotado y el rendimiento es predecible bajo carga.

Un panel útil responde cinco preguntas continuamente:

1. ¿Mis datos siguen protegidos? (Redundancia intacta; no se acumula corrupción silenciosa; sin tendencias preocupantes en checksums.)
2. ¿Estoy a punto de perder protección? (Scrub detectando más errores; reallocations SMART en aumento; riesgo de resilver creciendo.)
3. ¿El pool es lo suficientemente rápido para la carga? (Distribución de latencias; colas; comportamiento de sync writes; balance de vdev.)
4. ¿El pool se está volviendo más lento con el tiempo? (Fragmentación, pool lleno, presión de metadatos, thrash del ARC, saturación de special vdev.)
5. ¿Puedo recuperar rápidamente? (Tiempo de resilver; disponibilidad de spares; retraso de replicación; cumplimiento del calendario de scrubs.)

Lo que no significa: “CPU baja,” “la red parece bien,” o “nadie me ha avisado todavía.” ZFS puede ocultar mucho dolor detrás de buffers y escrituras asíncronas hasta que aparece una carga con muchas syncs y pide la verdad.

Hechos y contexto histórico (por qué existen estas métricas)

• ZFS nació en Sun a mediados de los 2000 con el objetivo explícito de integridad de datos de extremo a extremo—checksums en todo, no solo en los metadatos.
• “Scrub” no es un nombre gracioso: existe porque la corrupción silenciosa es real, y los discos mienten convincentemente hasta que lees cada bloque.
• ARC (Adaptive Replacement Cache) es central para el rendimiento de ZFS; no es un añadido. ZFS está diseñado asumiendo una caché grande e inteligente.
• L2ARC llegó más tarde como una caché de lectura “de segundo nivel” en dispositivos rápidos, pero no es magia: necesita RAM para metadatos y puede consumir CPU.
• ZIL y SLOG suelen entenderse mal: el ZIL siempre existe; un SLOG es solo un dispositivo separado para almacenar el ZIL más seguro/rápido.
• Copy-on-write (CoW) cambia la simplicidad de reescribir en sitio por consistencia. El precio es la fragmentación y la necesidad de vigilar el espacio libre.
• “RAIDZ no es RAID” en comportamiento operativo: el rebuild (resilver) lee solo bloques asignados, lo que puede ser más rápido, pero aún castiga a discos lentos.
• OpenZFS amplió el ecosistema a illumos, FreeBSD, Linux y otros; por eso algunos comandos y kstats difieren según la plataforma.
• Special vdevs (metadatos/pequeños bloques) son potentes pero operativamente peligrosos: perder el special vdev puede hacerte perder el pool.

Esto no son trivialidades. Explican por qué el panel debe tener sesgo hacia la integridad y la latencia, no solo el rendimiento bruto.

Las métricas que debes rastrear (y cómo interpretarlas)

1) Estado del pool y contadores de errores (integridad primero)

Tu fila superior debe ser brutalmente simple: estado del pool y contadores de errores por vdev y dispositivo:
errores de lectura, errores de escritura, errores de checksum. Los errores de checksum son los que deberían hacerte sentarte derecho.
Lecturas y escrituras pueden fallar de forma transitoria; los errores de checksum significan que los datos no coincidieron con lo que ZFS escribió.

Rastrear:

• Estado del pool: ONLINE/DEGRADED/FAULTED
• Contadores de error por dispositivo leaf
• Eventos “errors: Permanent errors have been detected…”
• Número de dispositivos degradados/faltantes

Regla de decisión: cualquier tendencia de errores de checksum distinta de cero es un incidente hasta que se demuestre lo contrario. No es un ticket. Es un incidente.

2) Métricas de scrub: último scrub, duración, errores encontrados

Los scrubs son tu suero de verdad periódico. Si no haces scrubs, estás apostando al negocio a que los discos se comportarán cuando importe.
Un panel debe mostrar:

• Tiempo desde que se completó el último scrub
• Duración del scrub (y cómo cambia)
• Errores encontrados durante el scrub
• Tasa de scrub (MB/s), especialmente en pools grandes

Patrón a vigilar: scrubs que tardan más cada mes a menudo correlacionan con un pool más lleno, más fragmentado o un disco degradándose en silencio.

3) Métricas de resilver: inicio, progreso, estimación de finalización

El tiempo de resilver es riesgo operativo. Mientras resilverea, tienes redundancia reducida y mayor exposición a una segunda falla.
Rastrear:

• Resilver en progreso
• Tasa de escaneo y ETA
• Número de resilvers en los últimos N días (resilveres frecuentes sugieren hardware marginal)

Decisión: si el tiempo de resilver es “días,” no estás ejecutando un sistema de almacenamiento; estás operando una tómbola. Ajusta diseño: más vdevs, mirrors,
menos grandes RAIDZ, o discos más rápidos, según restricciones.

4) Presión de capacidad: % usado, % libre y, crucialmente, fragmentación del espacio libre

ZFS tiene un precipicio de rendimiento. No es un mito. Pasado cierto llenado, las asignaciones se complican, la fragmentación crece y la latencia se dispara bajo carga.
Rastrear:

• Porcentaje de asignación del pool
• Cuotas/reservas de dataset (pueden ocultar una escasez real)
• Fragmentación del espacio libre (a nivel pool)

Umbral de opinión: trata 80% de uso del pool como “amarillo”, 90% como “rojo”.
Algunos pools sobreviven más allá, pero lo pagas en latencia.

5) Latencia: no solo promedio, sino distribución y latencia de sync writes

Las gráficas de throughput tranquilizan a la gente. Las de latencia mantienen los sistemas vivos. Quieres:

• Latencia de lectura p50/p95/p99 por pool y por vdev
• Latencia de escritura p50/p95/p99
• Latencia de sync write (especialmente si sirves bases de datos, NFS o discos de VM)
• Profundidad de cola (device y pipeline de ZFS)

Si p99 es feo, los usuarios llamarán “lentitud aleatoria.” Tú lo llamarás “un martes.”

6) IOPS y ancho de banda por vdev (el desbalance te dice dónde está el fuego)

Los pools ZFS son agregados. El cuello de botella suele ser un vdev, un disco o una clase de dispositivo (por ejemplo, special vdev, SLOG).
Rastrear:

• IOPS y ancho de banda por vdev de primer nivel
• Latencia por vdev
• Porcentaje de busy de disco

Decisión: si un vdev está consistentemente más caliente, corrige el layout o la colocación de cargas. No “tunes” alrededor de un problema estructural.

7) Métricas ARC: tamaño, ratio de aciertos, evicciones y “¿está ARC compitiendo con el OS?”

ARC puede ocultar pecados. O exponerlos. Necesitas:

• Tamaño ARC vs target
• Ratio de aciertos (global y por datos vs metadatos si está disponible)
• Tasa de evicción
• Señales de presión de memoria (actividad de swap, riesgo de OOM)

Cuidado: un alto hit ratio de ARC puede ser insignificante si tu carga es streaming. La señal real es: ¿estás cumpliendo los SLOs de latencia?

8) Métricas L2ARC (si se usa): ratio de aciertos, tasa de alimentación y amplificación de escritura

L2ARC ayuda en cargas de lectura intensiva y cacheables. También puede simplemente consumir la durabilidad de los SSD sin lograr nada.
Rastrear:

• Tamaño L2ARC y ratio de aciertos
• Tasa de “feed” (cuánto estás escribiendo en él)
• Indicadores de desgaste del SSD (desde SMART)

Decisión: si el ratio de aciertos es bajo y la tasa de feed es alta, probablemente sea un placebo caro.

9) Métricas ZIL/SLOG: tasa de sync writes, latencia SLOG y salud del dispositivo

Si exportas NFS con sync, ejecutas bases de datos o alojas discos de VM, el comportamiento del ZIL definirá tu peor día.
Rastrear:

• IOPS de sync write
• Latencia y errores del dispositivo SLOG
• Utilización y contención del SLOG

Un SLOG que está “bien” hasta que toca throttling térmico es una receta clásica de caída.

10) Perillas a nivel dataset que cambian la realidad: recordsize, volblocksize, compression, atime, sync

Los datasets ZFS son límites de política. Tu panel debe permitir correlacionar rendimiento con las perillas que configuras:

• recordsize (filesystems) y volblocksize (zvols)
• algoritmo de compression y ratio
• atime (a menudo escrituras inútiles)
• sync (standard/always/disabled)

El ratio de compresión no es solo “espacio ahorrado.” También es “menos IO requerido” si hay CPU disponible. Vigila ambos.

11) SMART y salud de dispositivos: sectores realocados, errores de media, temperatura y eventos de pérdida de energía

ZFS puede corregir algunos errores. No puede corregir un disco que muere lentamente mientras lo ignoras.
Rastrear:

• Reallocated sector count / media errors
• UDMA CRC errors (los cables/backplanes importan)
• Temperatura y flags de thermal throttling
• NVMe percent used / nivel de desgaste

Decisión: reemplaza discos basándote en la tendencia, no en heroicidades. Esperar a “FAILED” es cómo terminas resilverando en un fin de semana festivo.

12) Señales de replicación y backup: lag, última ejecución y “¿probamos realmente la restauración?”

Un panel de salud sin estado de replicación/backup es teatro. Rastrear:

• Hora de la última snapshot y cumplimiento de retención
• Lag de replicación (tiempo y bytes)
• Último send/receive exitoso
• Recencia de prueba de restauración (sí, pertenece al panel)

Una idea parafraseada de W. Edwards Deming encaja bien en operaciones: Sin datos, eres solo otra persona con una opinión. (idea parafraseada, atribuida a W. Edwards Deming)

Broma #1: ZFS es como un buen contable—todo está checksummed, y recordará absolutamente lo que trataste de “ignorar.”

Tareas prácticas: comandos, significado de la salida y decisiones (12+)

Estas son tareas que puedes ejecutar hoy. El punto no es el comando. El punto es lo que haces después de leer la salida.
Los ejemplos asumen OpenZFS en Linux; ajusta rutas para tu plataforma si hace falta.

Task 1: Confirmar estado del pool y contadores de error

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:33 with 0 errors on Sun Dec 22 02:18:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0

errors: No known data errors

Qué significa: “ONLINE” es necesario pero no suficiente. Los contadores importan. Cualquier CKSUM distinto de cero es una señal roja; READ/WRITE también, pero CKSUM es más alarmante.

Decisión: Si los errores son distintos de cero, inicia un incidente: identifica el dispositivo, revisa el cableado/backplane, ejecuta SMART y planifica el reemplazo. Si aparecen CKSUM repetidos, no esperes.

Task 2: Vigilar scrubs/resilver lentos o atascados

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 02:10:03 2025
        4.12T scanned at 610M/s, 2.01T issued at 298M/s, 18.3T total
        0B repaired, 10.97% done, 0 days 15:22:10 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

errors: No known data errors

Qué significa: “scanned” vs “issued” puede divergir; issued refleja IO real. ETAs largos pueden indicar discos lentos, contención o throttling.

Decisión: Si el ETA del scrub se inflama o la tasa issued colapsa bajo carga normal, investiga latencia por disco y errores. Considera programar scrubs en horarios sin pico y verifica los throttles de scrub.

Task 3: Comprobar capacidad del pool y riesgo de fragmentación

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank             72.4T  9.63T   128K  /tank
tank/vm          41.1T  9.63T  40.9T  /tank/vm
tank/backups     28.7T  9.63T  28.7T  /tank/backups
tank/home        2.58T  9.63T  2.58T  /tank/home

Qué significa: “AVAIL” se comparte entre datasets a menos que existan reservas. Un pool con ~88% usado ya está en territorio de “precipicio de latencia” para muchas cargas.

Decisión: Si tiendes hacia 85–90% usado, deja de añadir datos. Gana tiempo expirando snapshots, moviendo datos fríos, añadiendo vdevs o expandiendo capacidad. No “tunes” para salir.

Task 4: Mostrar políticas de dataset que cambian el comportamiento de escritura

cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,compression,atime,sync tank/vm
NAME     PROPERTY     VALUE
tank/vm  recordsize   128K
tank/vm  compression  lz4
tank/vm  atime        off
tank/vm  sync         standard

Qué significa: Estas propiedades influyen directamente en el tamaño de IO y la semántica de durabilidad. “sync=always” puede destrozar la latencia en un SLOG débil; “sync=disabled” puede fingir rendimiento arriesgando pérdida de datos.

Decisión: Valida que las propiedades coincidan con la carga. Si cambiaste sync a “disabled” para “arreglar” rendimiento, no arreglaste rendimiento—cambiaste las reglas de la física.

Task 5: Medir carga IO en tiempo real y latencia por vdev

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        72.4T  9.63T  3.12K  1.88K  612M  241M
  raidz2-0                  72.4T  9.63T  3.12K  1.88K  612M  241M
    sda                         -      -    520    310   98M   41M
    sdb                         -      -    510    305   96M   40M
    sdc                         -      -    540    312  101M   41M
    sdd                         -      -    105    328   22M   39M
    sde                         -      -    525    309   99M   40M
    sdf                         -      -    520    316   98M   40M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Un disco (sdd) hace muchas menos lecturas pero escrituras similares: eso puede indicar errores de lectura, lecturas lentas o un problema de path que provoca reintentos en otro lado.

Decisión: Investiga ese dispositivo: SMART, cableado, controlador y logs del kernel. Si el vdev está desequilibrado, los tiempos de resilver y scrub sufren, y también tu latencia p99.

Task 6: Comprobar comportamiento del ARC (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|hits|misses|demand_data_hits|demand_data_misses) '
size                            4    17179869184
c_min                           4     4294967296
c_max                           4    34359738368
hits                            4    9140284432
misses                          4     821739122
demand_data_hits                4    6021139981
demand_data_misses              4     611229880

Qué significa: Tamaño ARC, target máximo y contadores hits/misses te dan eficiencia de caché. Un bajo hit ratio bajo carga de lecturas aleatorias sugiere añadir RAM o cambiar layout.

Decisión: Si misses son altos y la latencia es alta, considera añadir RAM antes de sumar “cachés” SSD. Si tu carga es streaming, no reacciones exageradamente a misses; céntrate en throughput y comportamiento de escrituras.

Task 7: Confirmar que no hay presión de memoria oculta tras ARC

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           256Gi       118Gi        12Gi       2.0Gi       126Gi       136Gi
Swap:            0B          0B          0B

Qué significa: La memoria “available” importa. Si available colapsa y comienza churn de swap, ARC se reducirá y tu almacenamiento repentinamente “se pondrá lento” en todas partes.

Decisión: Si el host está intercambiando, trátalo como incidente de rendimiento. Arregla la presión de memoria, reduce cargas co-ubicadas o limita ARC intencionalmente.

Task 8: Comprobar latencia por disco y colas (nivel OS)

cr0x@server:~$ iostat -x 2 2
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.42    0.00    5.18    8.70    0.00   75.70

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  %util
sda             85.0    51.0    98.0    41.0    1680.0     7.2    42.0     48.0     32.0   96.0
sdb             82.0    49.0    96.0    40.0    1676.0     6.8    39.0     44.0     31.0   94.0
sdc             88.0    52.0   101.0    41.0    1672.0     6.9    40.0     46.0     31.0   95.0
sdd             18.0    55.0    22.0    39.0    1490.0    18.5   210.0    420.0     26.0   99.0

Qué significa: sdd tiene await de lectura masivo y cola profunda. Ese es tu fragmento caliente de miseria. ZFS esperará por él porque la paridad/mirror lo necesita.

Decisión: Reemplaza el disco, arregla el path o mueve el vdev a hardware más sano. Afinar ZFS no hará que un disco moribundo deje de morir.

Task 9: Extraer SMART/NVMe y decidir reemplazo proactivo

cr0x@server:~$ sudo smartctl -a /dev/sdd | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|Temperature_Celsius'
  5 Reallocated_Sector_Ct   0x0033   097   097   010    Pre-fail  Always       -       48
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       6
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       6
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   041   053   000    Old_age   Always       -       59

Qué significa: Sectores pendientes y offline_uncorrectable junto con temperatura alta: este disco no está “bien.” Está negociando con la entropía.

Decisión: Reemplázalo. Si está caliente, arregla el flujo de aire también. Si varios discos muestran tendencias similares, sospecha de la refrigeración del chasis, el backplane o calidad de lote.

Task 10: Revisar eventos ZFS en busca de advertencias silenciosas

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 24 2025 14:18:03.512410000  ereport.fs.zfs.io
        vdev_path: /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_9JH2ABCD
        vdev_guid: 1234567890123456789
        zio_err: 5
        zio_offset: 8723412992
        zio_size: 131072
        zio_flags: 180880
        parent_guid: 9876543210987654321

Qué significa: ZFS te está avisando sobre errores de IO con contexto. Estos eventos suelen aparecer antes que un estado “DEGRADED” completo.

Decisión: Correlaciona eventos con SMART y logs del kernel. Escala si la tasa de eventos aumenta. Unos pocos errores de IO pueden convertir rápidamente la situación en un resilver.

Task 11: Validar ashift (la trampa de rendimiento que no notas hasta que duele)

cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|vdev_tree' -n | head
34:        vdev_tree:
57:            ashift: 12

Qué significa: ashift=12 implica sectores de 4K. Si creaste un pool con ashift=9 en discos 4K por error, obtienes amplificación read-modify-write y latencia triste.

Decisión: Si ashift es incorrecto, planifica migración. No se puede corregir en sitio. Por eso la creación del pool debe tratarse como diseño de esquema.

Task 12: Confirmar uso de special vdev (si existe) y si está saturado

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          raidz2-0                   ONLINE       0     0     0
            sda                      ONLINE       0     0     0
            sdb                      ONLINE       0     0     0
            sdc                      ONLINE       0     0     0
            sdd                      ONLINE       0     0     0
            sde                      ONLINE       0     0     0
            sdf                      ONLINE       0     0     0
          special
            nvme0n1                  ONLINE       0     0     0

Qué significa: Existe un special vdev. Eso significa que metadatos (y posiblemente bloques pequeños) residen ahí. Si se sobrecarga o falla, puedes tener un gran problema.

Decisión: Asegura que el special vdev tenga redundancia (mirror) y monitorea su latencia y desgaste. Si es un dispositivo único, corrige ese diseño antes de que te corrija a ti.

Task 13: Comprobar carga de snapshots y aumento de retención

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation | head -n 8
NAME                               USED  REFER  CREATION
tank/vm@auto-2025-12-25-0000        0B    40.9T  Thu Dec 25 00:00 2025
tank/vm@auto-2025-12-24-0000        0B    40.9T  Wed Dec 24 00:00 2025
tank/vm@auto-2025-12-23-0000       12.4G  40.9T  Tue Dec 23 00:00 2025
tank/vm@auto-2025-12-22-0000       10.1G  40.9T  Mon Dec 22 00:00 2025
tank/vm@auto-2025-12-21-0000       11.7G  40.9T  Sun Dec 21 00:00 2025
tank/vm@auto-2025-12-20-0000        9.8G  40.9T  Sat Dec 20 00:00 2025
tank/vm@auto-2025-12-19-0000       10.9G  40.9T  Fri Dec 19 00:00 2025

Qué significa: “USED” de snapshot no es cero una vez que los bloques divergen. La proliferación de snapshots consume espacio en silencio y puede degradar rendimiento.

Decisión: Si los snapshots se están comiendo el pool, arregla la retención. Si el cumplimiento exige retención larga, presupuestar capacidad y evita almacenar datasets con alta volatilidad en el mismo pool.

Task 14: Detectar lag de replicación por tiempos recientes de snapshot (simple pero efectivo)

cr0x@server:~$ zfs get -H -o value creation tank/vm@auto-2025-12-25-0000
Thu Dec 25 00:00 2025

Qué significa: Si la última snapshot es antigua, la replicación tampoco puede estar al día (a menos que replique sin snapshots, lo cual tiene su propio riesgo).

Decisión: Si el calendario de snapshots está desviándose, trata el lag de replicación como un incidente de RPO. Arregla la tubería, no solo la ejecución fallida.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

El objetivo no es volverte un mago. El objetivo es evitar pasar dos horas discutiendo si es “la red” mientras el pool está al 92%.
Aquí está el orden que gana en producción.

Step 1: Confirma que no estás ya en un evento de riesgo de datos

• Comprueba: zpool status -v (errores, DEGRADED, scrub/resilver en progreso)
• Comprueba: zpool events -v | tail (nuevos errores de IO)
• Comprueba: SMART para dispositivos sospechosos (pending/uncorrectable sectors)

Si hay errores de checksum, deja de perseguir rendimiento. Estás en modo integridad ahora.

Step 2: Identifica si el problema es latencia, throughput o semántica de sync

• Comprueba: zpool iostat -v 1 (¿quién está caliente? ¿qué vdev?)
• Comprueba: iostat -x 1 (await, %util, profundidad de cola por disco)
• Pregunta: ¿La carga es sync-heavy (NFS sync, bases de datos, escrituras de VM)?

Síntoma clásico: el ancho de banda parece “bien,” pero la latencia p99 es terrible y los usuarios se quejan. Eso es colas, contención o un dispositivo lento.

Step 3: Comprobar presión de capacidad y fragmentación

• Comprueba: zfs list y tendencias de uso del pool
• Comprueba: recuento de snapshots y crecimiento

Si el pool está muy lleno, puedes perder días “afinando” mientras el asignador sigue fallando. Compra espacio primero.

Step 4: Comprobar efectividad de caché y presión de memoria

• Comprueba: estadísticas ARC (hits/misses, tamaño vs c_max)
• Comprueba: free -h y actividad de swap

El thrash del ARC convierte lecturas aleatorias pequeñas en seeks de disco. Tu panel debe permitir ver ese cambio en semanas, no solo después de que suene el pager.

Step 5: Revisar “perillas de política” y cambios recientes

• Comprueba: propiedades de datasets (sync, recordsize, compression)
• Comprueba: despliegues recientes: actualizaciones de kernel, firmware de controladora, nuevas cargas, nuevas opciones de montaje NFS

La mayoría de incidentes no son misteriosos. Simplemente no están correlacionados. Corrélalos.

Tres mini-historias corporativas (lo que realmente pasa)

Mini-historia #1: El incidente causado por una suposición errónea (“ONLINE significa sano”)

Una compañía SaaS mediana ejecutaba bases de datos de clientes sobre almacenamiento de VM respaldado por ZFS. El panel del pool tenía un gran mosaico verde:
“tank: ONLINE.” Todos se sentían tranquilos. Cuando llegaron las quejas de rendimiento, el equipo de almacenamiento señalaba ese mosaico y decía,
“Es almacenamiento, está bien. Deben ser los hypervisors.”

La primera pista real fue un aumento paulatino en tiempos de consulta que no correlacionaba con CPU o red. Luego la ventana de backup empezó
a solaparse con horas de negocio. Nada dramático—solo la sensación de que todo estaba más pesado que antes.
Finalmente el equipo ejecutó zpool status -v y encontró un conteo de checksum distinto de cero en un disco que había estado “estable” semanas.
Los scrubs pasaban, pero tardaban más, y nadie había estado monitoreando la duración.

La suposición errónea fue creer que ZFS “lo manejaría” y que les avisarían cuando importara. Pero ZFS es conservador: reintentará,
corregirá y seguirá sirviendo. Esa amabilidad es exactamente por qué debes monitorearlo. Esos contadores de checksum contaban la historia:
un path de disco estaba corrupto intermitentemente, corregido por redundancia—hasta que ya no.

La solución fue aburrida: reemplazar el disco, inspeccionar la bahía del backplane y añadir alertas sobre deltas de checksum (no solo conteo absoluto),
además de un panel de “duración de scrub.” El resultado fue igualmente aburrido: la próxima vez que un path falló, lo reemplazaron antes de síntomas hacia clientes.
Eso es lo que parece el éxito en almacenamiento: no pasa nada.

Mini-historia #2: La optimización que salió mal (“sync=disabled es rendimiento gratis”)

Un equipo de plataforma interno tenía un sistema CI respaldado por NFS. Era “lento” durante horas pico. Alguien leyó un blog y puso
sync=disabled en el dataset, porque la carga eran “artefactos de build temporales.” El panel instantáneamente mejoró.
La latencia bajó. Todos celebraron. Alguien sugirió aplicar el mismo cambio en más datasets.

Una semana después, un evento de energía afectó al rack. No fue un desastre total; solo una transferencia de UPS y un par de hosts que no les gustó.
El sistema CI volvió… y luego los jobs empezaron a fallar con artefactos corruptos y archivos faltantes. La “temporalidad” de los artefactos
resultó ser mentira: el sistema también cacheaba blobs de dependencias y salidas de build que se reutilizaban después.

ZFS hizo exactamente lo que le dijeron: con sync disabled, reconoció escrituras antes de que estuvieran seguras en almacenamiento estable.
El equipo había cambiado durabilidad por velocidad sin una decisión formal de riesgo. El evento de energía no fue el problema; la política lo fue.

La solución fue doble: volver a sync=standard, y construir una solución real:
un SLOG NVMe en mirror con protección contra pérdida de energía, más instrumentación para latencia de sync writes.
Tras eso, el panel mostró la verdad: el cuello de botella era sync writes, no magia aleatoria.

Mini-historia #3: La práctica aburrida que salvó el día (“scrub + alertas SMART por tendencia”)

Una firma de servicios financieros manejaba un gran pool de archivo. Nada espectacular. Lecturas mayormente secuenciales, escrituras periódicas y retención estricta.
El equipo tenía un hábito que a todos les parecía un poco molesto: scrubs mensuales, con alertas no solo por errores sino también por “aumento de duración del scrub en 30%.”
También seguían tendencias SMART de sectores pendientes y temperatura.

Un mes, la duración del scrub saltó. Sin errores, solo más lento. El panel mostró que la p95 de latencia de lectura de un vdev subía continuamente,
mientras el resto se mantenía estable. SMART no marcaba fallo catastrófico, pero sí mostraba aumento en Current_Pending_Sector en un disco.
No era suficiente para que el proveedor lo cambiara por sí solo, pero sí para activar la política interna del equipo.

Reemplazaron el disco durante horario laboral sin drama. Una semana después, el disco viejo falló por completo en el banco de pruebas.
El equipo no ganó un premio. Tampoco recibió una llamada a las 03:00 con un pool degradado y un CEO que de pronto entiende la aritmética de paridad.

La práctica no fue ingeniosa. Fue consistente. El almacenamiento recompensa la consistencia como un animal entrenado: aliméntalo con scrubs y alertas de tendencia, y se comporta.

Errores comunes: síntoma → causa raíz → solución

1) “El pool está ONLINE pero los usuarios reportan pausas aleatorias”

Síntoma: Congelaciones cortas, picos de latencia p99, especialmente bajo carga mixta.

Causa raíz: Un disco lento, fallos de controladora o un desequilibrio de vdev que causa colas. A menudo visible en iostat -x como await/%util alto en un único dispositivo.

Solución: Identifica el disco caliente/lento, revisa SMART y logs, reubica/reemplaza hardware. Añade paneles de latencia por disco, no solo throughput del pool.

2) “Todo se volvió más lento después de añadir más datos”

Síntoma: Declinación gradual del rendimiento, scrubs más largos, errores de asignación cerca del final.

Causa raíz: Pool demasiado lleno y/o muy fragmentado; snapshots consumiendo espacio; segmentos libres pequeños.

Solución: Devuelve el pool a una utilización razonable. Elimina/expira snapshots responsablemente, añade capacidad, rebalancea datos. Pon “pool used %” en la portada con alertas duras.

3) “Las sync writes son dolorosamente lentas”

Síntoma: Bases de datos/NFS/VMs muestran alta latencia de commit; throughput parece bien para cargas asíncronas.

Causa raíz: Sin SLOG, SLOG débil o SLOG sin protección contra pérdida de energía; también posible: sync=always en un dataset que no lo necesita.

Solución: Usa un SLOG espejado, con PLP, para cargas serias de sync. Monitorea latencia y errores del SLOG. No pongas sync=disabled para “arreglar” esto.

4) “Vemos errores de checksum pero SMART parece bien”

Síntoma: CKSUM distinto de cero en zpool status, a menudo aumentando lentamente.

Causa raíz: Cableado/backplane/controladora, no necesariamente el medio. Pueden aparecer UDMA CRC errors, pero no siempre.

Solución: Cambia cables/puertos, actualiza firmware, mueve el disco a otra bahía/controladora y vuelve a scrubbear. Trata deltas de checksum como señales críticas.

5) “L2ARC no ayudó; desgaste SSD alto”

Síntoma: Poco o ningún mejora en latencia de lectura; volumen de escritura en SSD muy alto.

Causa raíz: Working set no cabe o no es cacheable; L2ARC se alimenta agresivamente; overhead de metadatos consume RAM.

Solución: Verifica ratio de aciertos y tasa de feed. Si no ayuda, quítalo. Gasta presupuesto en RAM o en layout de vdev antes de comprar SSDs placebo.

6) “Resilver tarda una eternidad y nos sentimos expuestos”

Síntoma: Reconstrucciones medidas en días; rendimiento degradado durante resilver.

Causa raíz: Vdevs enormes en discos lentos, pool sobrecargado o pocos vdevs (poca paralelización).

Solución: Rediseña: más vdevs, vdevs mirror para cargas aleatorias, o RAIDZ más pequeños. Ten spares disponibles y prueba procedimientos de reemplazo.

Broma #2: Si tu única alerta de almacenamiento es “pool FAULTED,” tu monitorización es básicamente un detector de humo que solo pita después de que la casa ya se mudó.

Listas de verificación / plan paso a paso

Checklist del panel: los paneles que importan

• Panel de integridad: estado del pool, cuenta DEGRADED/FAULTED, errores checksum/read/write (absoluto y delta), eventos ZFS recientes.
• Panel de scrub & resilver: última hora de scrub, tendencia de duración, errores encontrados; flag de resilver activo, tasa, ETA.
• Panel de capacidad: pool used %, free %, uso por dataset, espacio usado por snapshots, outliers de quota/reservation.
• Panel de latencia: read/write p50/p95/p99 por pool y por vdev; await de dispositivo; %util; profundidad de cola.
• Panel de carga: IOPS y ancho de banda por vdev; tasa de sync writes si es medible; datasets top talkers si tienes contabilidad por dataset.
• Panel de caché: tamaño ARC, ratio de aciertos, tasa de evicción; ratio L2ARC y tasa de feed (si se usa).
• Panel de salud de dispositivos: tendencias SMART: pending/uncorrectable/reallocated, CRC errors, temperatura, desgaste NVMe.
• Panel de protección de datos: frescura de snapshots, lag de replicación, último backup/replicación exitosa, fecha de última prueba de restauración.

Checklist de operaciones: rutinas semanales y mensuales

1. Semanal: revisar deltas de checksum y logs de eventos ZFS; investigar cualquier cambio.
2. Semanal: revisar tendencia de latencia p99 por vdev; identificar hotspots emergentes.
3. Semanal: revisar margen de capacidad; confirmar que no se está acercando al 90%.
4. Mensual: ejecutar un scrub (o garantizar que se ejecutó); registrar duración y comparar con la línea base.
5. Mensual: revisar informe de tendencias SMART y temperaturas; arreglar flujo de aire antes de reemplazar la mitad de la flota.
6. Trimestral: probar una restauración (a nivel archivo y dataset), documentar tiempo de restauración y actualizar runbooks.
7. Después de cualquier cambio de hardware: verificar identificadores de dispositivo, ashift, y que las alertas sigan mapeando a los discos correctos.

Paso a paso: cuando agregas un nuevo pool (haz esto siempre)

1. Decide layout de vdev según carga: mirrors para IO aleatorio, RAIDZ para capacidad y patrones más secuenciales.
2. Confirma expectativas de ashift antes de crear. Trátalo como irreversible.
3. Define políticas de dataset desde el principio: compression activada (lz4), atime off para la mayoría, recordsize/volblocksize sensatos, sync standard.
4. Programa scrub y alertas antes de que caiga data de producción.
5. Implementa monitorización SMART con alertas basadas en tendencia, no solo “FAILED.”
6. Establece una línea base de rendimiento (latencia bajo carga representativa) y consérvala para comparaciones.

Preguntas frecuentes

1) ¿Cuál es la métrica única más importante de ZFS?

Deltas de errores de checksum (y los eventos relacionados). Los problemas de rendimiento duelen; los problemas de integridad arruinan carreras.
Rastrea conteos absolutos y cambios a lo largo del tiempo por dispositivo.

2) ¿Con qué frecuencia debo hacer scrub?

Para la mayoría de pools de producción: mensual es un valor sensato. Pools muy grandes o muy ocupados pueden necesitar ajuste, pero “nunca” no es una estrategia.
Si los scrubs son muy disruptivos, ajusta la programación e investiga por qué el pool no tolera lecturas secuenciales.

3) ¿Por qué ZFS se vuelve lento cuando el pool está casi lleno?

Las asignaciones CoW necesitan espacio libre relativamente contiguo. Conforme el espacio libre disminuye y se fragmenta, ZFS trabaja más para asignar bloques y el IO se vuelve más aleatorio.
Las latencias se disparan antes de llegar al 100%. Por eso alertas temprano.

4) ¿Es el ratio de aciertos ARC un KPI fiable?

Es un diagnóstico, no un KPI. Un bajo hit ratio puede ser normal para lecturas de streaming. Úsalo para explicar comportamiento de latencia, no para “optimizar un número.”

5) ¿Cuándo debo usar L2ARC?

Cuando tu working set es mayor que la RAM pero aún cacheable, y tienes CPU y RAM de sobra para el overhead de metadatos.
Si puedes comprar más RAM, hazlo antes en muchos casos.

6) ¿Necesito un SLOG?

Solo si tienes escrituras sync significativas y te importa la latencia (bases de datos, NFS con sync, almacenamiento de VM).
Si añades uno, usa dispositivos con protección contra pérdida de energía y réplicalos en mirror para fiabilidad.

7) ¿Los errores de checksum son siempre un disco moribundo?

No. A menudo son cableado, HBA defectuoso, firmware o una bahía backplane inestable. Pero la reparación sigue siendo urgente: identifica el path y elimina la corrupción.

8) ¿Debería alertar solo cuando el “pool cambia a ONLINE”?

Eso es lo mínimo, y llega demasiado tarde para estar cómodo. Avisa por deltas de checksum, anomalías en duración de scrub, tendencias SMART y picos de latencia de vdev.
“ONLINE” es el titular; la historia está en las notas al pie.

9) ¿Cómo detecto si un vdev es el cuello de botella?

Usa zpool iostat -v y a nivel OS iostat -x para comparar await/%util por dispositivo. Un único dispositivo topado con await alto y util elevado es el culpable clásico.
Si solo un vdev de primer nivel está caliente, puede que estés infra-provisionado en número de vdevs (no en tamaño de discos).

10) ¿Cuál es un umbral razonable de alerta para temperatura de disco?

Depende de la clase de disco, pero temperaturas sostenidas en los altos 50s °C son una mala señal para longevidad.
Tómatelo por tendencia: si la temperatura sube en semanas, probablemente cambiaste flujo de aire o densidad.

Conclusión: próximos pasos que puedes hacer esta semana

Un panel de salud de ZFS no es un único gráfico. Es un conjunto de opiniones codificadas como alertas: integridad primero, luego latencia, luego capacidad, luego optimización.
Si solo rastreas throughput y “ONLINE,” te enterarás de los problemas cuando los usuarios te lo enseñen—a gritos.

1. Añade paneles en la portada para: deltas de checksum, duración de scrub, pool used % y latencia p99 por vdev.
2. Convierte SMART en alertas por tendencia: pending/uncorrectable, reallocated, temperatura y desgaste NVMe.
3. Escribe una página de runbook: qué hacer cuando aumentan errores de checksum y qué hacer cuando pica la latencia p99.
4. Elige un calendario de scrubs y hazlo obligatorio; alerta cuando no ocurra.
5. Detén “arreglos de rendimiento” que en realidad son concesiones de durabilidad a menos que hayas tomado una decisión formal de riesgo.

Haz eso, y ya no estarás ciego. Seguirás teniendo problemas—esto es almacenamiento—pero serán problemas que puedes prever, cuantificar y arreglar en tus términos.