TPTito Pinardo Gutiérrez
← Volver al rack
English
1U · STORAGEZFS · RAIDZ1 · espejos · RAID1 En producción

Posición 25 de 25 en el rack · En producción

Unidad 1U · Almacenamiento

ZFS y RAID · los discos

Escrituras ×13 sin comprar nada

Los datos grandes viven en un pool ZFS RAIDZ1 de cinco discos de 10 TB en una bandeja externa; los mundos de los juegos, en un espejo de cuatro discos SAS; el sistema, en un RAID1 por software. ZFS verifica cada bloque al leerlo y una caché enorme en RAM sirve casi todas las lecturas.

Por qué ZFS
Sumas de comprobación en cada bloque, compresión, instantáneas y ampliar un RAIDZ en caliente. Y la RAM sobrante del servidor se convierte en caché.
Qué pool para qué
RAIDZ para mucho espacio con un disco de margen; espejos para escrituras pequeñas y rápidas; RAID1 por software para el sistema.
Lo que no es
Ni RAIDZ ni espejos son una copia de seguridad: aguantan que muera un disco, no un borrado. Eso está en la unidad de copias.
  • 95 → 1.237escrituras por segundo con fsync en el pool grande
  • 5 × 10 TBen RAIDZ1, ampliado de 4 a 5 en caliente
  • 0 Breparados en el scrub tras la ampliación
  • > 98 %de las lecturas de juegos desde la caché en RAM

El almacenamiento por dentro

Varios pools para usos distintos y una bandeja externa de discos. Elige un recorrido.

Recorridos Pulsa uno y sigue el paquete.

Conexiones Discos del servidor y de la bandeja ZFS gestionado por el hipervisor Pools Ajustes Discos Salud HBA SAS Bandeja 24 Contenedores Zabbix Proxmox 9.2 Pool RAIDZ1 Pool espejos RAID1 sistema Discos sueltos Caché ARC recordsize 1M atime off Planificador Caché escritura Al arrancar Ampliación UUID XFS Scrub SMART Ocupación fio
Hermesde visita en la unidad

Pulsa una pieza o elige un recorrido. Si vienes de una habilidad, ya están encendidas las piezas donde la uso.

      Alguien ve una película
      1. Contenedores — Plex pide un fichero.
      2. Pool grande (RAIDZ1) — Al pool grande, que comprueba la suma de cada bloque al leerlo.
      3. Caché en RAM — Lo que se lee a menudo se queda en la caché de RAM.
      4. Contenedores — Y llega al contenedor, verificado.
      Amplío el pool en caliente
      1. Bandeja de 24 discos — Meto un quinto disco en la bandeja.
      2. Controladora SAS — La controladora lo ve.
      3. Actualización del hipervisor — Primero, actualizar el hipervisor: ampliar un RAIDZ necesita una versión más nueva de ZFS.
      4. Ampliar el RAIDZ — La ampliación se lanza sobre el grupo de discos, no sobre un disco.
      5. Pool grande (RAIDZ1) — El pool sigue en uso mientras se reparten los datos.
      6. Scrub — Al terminar, un scrub lo verifica todo: 0 errores.
      Trece veces más escrituras
      1. Medir con fio — Mido con fio: 95 escrituras con fsync por segundo.
      2. Caché de escritura de los discos — Activo la caché de escritura de los discos.
      3. Reactivar al arrancar — Y un servicio que la vuelve a activar en cada arranque.
      4. Planificador «none» — Con el planificador en «none».
      5. Medir con fio — Vuelvo a medir: 1.237.
      Vigilar los discos
      1. SMART — Cada disco informa de su SMART.
      2. Monitorización — La monitorización lo recoge sin despertar los discos dormidos.
      3. Scrub — Los scrubs periódicos comprueban cada bloque.
      4. Ocupación — Y la ocupación de cada pool.
      5. Monitorización — Si algo empeora, aviso.
      Un disco que vuelve a entrar
      1. Discos sueltos — Saco un disco de su bahía y lo vuelvo a meter.
      2. Identificador de un disco — No monta: el sistema cree que el mismo disco ya está montado.
      3. Discos sueltos — Se limpia el registro del sistema de ficheros y se monta.
      4. Contenedores — Y sus datos vuelven a estar disponibles.

      1. Controladora SAS

        Una controladora en modo HBA: ZFS ve los discos tal cual, sin RAID por hardware en medio.

      2. Bandeja de 24 discos

        Una bandeja de discos de segunda mano, conectada por SAS, donde vive el pool grande.

      3. Contenedores

        Montan los datasets que necesitan.

        • LXC

      4. Monitorización

        Estado de los pools, del RAID y SMART de cada disco, sin despertar los que duermen.

        • Zabbix

      5. Actualización del hipervisor

        Ampliar un RAIDZ necesita ZFS 2.3 o más: hubo que actualizar Proxmox primero.

        • Proxmox VE

      6. Pool grande (RAIDZ1)

        Cinco discos de 10 TB: espacio para la biblioteca multimedia, con un disco de margen.

        • ZFS

      7. Pool de juegos (espejos)

        Cuatro discos SAS en dos espejos: escrituras pequeñas y frecuentes, como guardar un mundo.

        • ZFS

      8. RAID1 del sistema

        Dos discos en espejo por software para el sistema y los discos de los contenedores.

        • Linux (Debian, Alpine, Arch)

      9. Discos sueltos

        Algunos discos independientes con XFS, pendientes de entrar en el pool.

        • Linux (Debian, Alpine, Arch)

      10. Caché en RAM

        ZFS usa la RAM libre como caché de lectura. En el pool de juegos sirve más del 98 %.

        • ZFS

      11. Tamaño de bloque

        Bloques de 1 MB para vídeo, que se lee de principio a fin. Bloques normales donde hay ficheros pequeños.

        • ZFS

      12. Sin tiempo de acceso

        No escribir cada vez que se lee un fichero.

        • ZFS

      13. Planificador «none»

        ZFS ya ordena y agrupa la E/S: el planificador del kernel solo estorba.

        • Linux (Debian, Alpine, Arch)

      14. Caché de escritura de los discos

        Venía apagada en varios discos. Con ZFS es segura: vacía esa caché en cada transacción.

        • Linux (Debian, Alpine, Arch)

      15. Reactivar al arrancar

        En los discos detrás de la bandeja el ajuste no siempre sobrevive a un apagado: un servicio lo vuelve a poner en cada arranque.

        • Linux (Debian, Alpine, Arch)

      16. Ampliar el RAIDZ

        Añadir un quinto disco a un RAIDZ de cuatro, en caliente, sin mover los datos a otro sitio.

        • ZFS

      17. Identificador de un disco

        Un disco sacado y vuelto a meter puede chocar consigo mismo.

        • Linux (Debian, Alpine, Arch)

      18. Scrub

        Lee todo el pool y comprueba cada bloque contra su suma. Tras la ampliación: 0 errores.

        • ZFS

      19. SMART

        La salud que cada disco dice de sí mismo: sectores reasignados, temperatura, errores.

        • Linux (Debian, Alpine, Arch)

      20. Ocupación

        Por encima del 80-85 %, ZFS escribe más lento. Hay que vigilarlo antes de llegar.

        • ZFS

      21. Medir con fio

        En un dataset temporal sin compresión, antes y después de cada ajuste, y borrado al terminar.

        • Linux (Debian, Alpine, Arch)

      Lo que uso de mi árbol

      Pulsa una habilidad: se encienden en el mapa las piezas donde la uso y te cuento para qué.

      Proxmox VE
      ZFS gestionado desde el hipervisor; actualizado para poder ampliar un RAIDZ.
      LXC
      Los contenedores montan los datasets que necesitan.
      ZFS
      RAIDZ1 ampliado en caliente, espejos para los juegos, caché ARC, compresión, recordsize y scrubs.
      Linux (Debian, Alpine, Arch)
      RAID por software para el sistema, caché de escritura de los discos, planificador de E/S y discos XFS sueltos.
      Zabbix
      Vigila pools, RAID y SMART sin despertar los discos dormidos.

      Bitácora de incidencias

      Averías reales. Lee el síntoma, elige la causa que creas y mira cómo se arregló.

      1. #1

        Una ampliación que no hacía nada

        Julio de 2026 · pool

        El script de ampliar el pool con un disco nuevo terminaba, pero el pool seguía igual de grande. Sin ningún error claro.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        La orden apuntaba a un disco del pool, como en un espejo, en vez de al grupo RAIDZ entero. Y la versión de ZFS instalada todavía no permitía ampliar un RAIDZ.
        Solución
        Actualizar el hipervisor a una versión con ZFS 2.3 o más y lanzar la ampliación sobre el grupo de discos. Terminó en un día y el scrub posterior reparó 0 bytes.
        Lección
        Un script que «termina» no es un script que funciona: hay que comprobar el resultado. Y leer qué versión permite qué antes de lanzar algo así.

      2. #2

        «wrong fs type, bad superblock»

        14-07-2026 · disco

        Saqué un disco de su bahía y lo volví a meter. No montaba, y el error hablaba de un sistema de ficheros dañado.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Al sacarlo en caliente, el kernel cerró el sistema de ficheros pero no lo olvidó del todo. Al volver con otro nombre de dispositivo, su identificador chocaba con el que aún figuraba como montado.
        Solución
        Limpiar la referencia antigua y montarlo de nuevo, sin tocar sus datos.
        Lección
        El mensaje de error no siempre dice la causa: «superblock dañado» era «ya te conozco». El registro del kernel lo decía claro.

      3. #3

        Discos lentos de fábrica

        06-10-2026 · rendimiento

        El pool grande hacía solo 95 escrituras con fsync por segundo, con cinco discos.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Los discos tenían la caché de escritura desactivada, y en los que van detrás de la bandeja ni siquiera aceptaban la orden normal para activarla.
        Solución
        Activarla con la orden que sí aceptan, guardarla en el disco y añadir un servicio que la vuelve a activar en cada arranque. De 95 a 1.237 escrituras por segundo.
        Lección
        La configuración de fábrica no es la mejor para cada uso. Medir, cambiar una cosa y volver a medir.

      Contado entero en un artículo:

      Cómo se construyó

      1. Julio y agosto de 2026

        Ampliación del pool

        • Actualización de Proxmox para tener una versión de ZFS que amplíe RAIDZ.
        • Quinto disco añadido en caliente y scrub posterior sin errores.

      2. Septiembre y octubre de 2026

        Ajustes medidos

        • Sin tiempo de acceso y bloques grandes para vídeo.
        • Caché de escritura y planificador en todos los pools, medidos con fio antes y después.

      Decisiones (y por qué)

      • RAID por hardware o ZFS

        ZFS con la controladora en modo HBA

        ZFS necesita ver los discos de verdad para comprobar cada bloque y reparar lo que encuentra. Un RAID por hardware se lo escondería.

      • Un pool para todo o varios

        Uno por patrón de uso

        Mucho espacio y lectura secuencial no piden lo mismo que muchas escrituras pequeñas. Separarlos deja ajustar cada uno.

      Lo que aprendí

      • Comprobar el resultado de una operación de discos, no que el script termine.
      • Medir cada ajuste antes y después.
      • Un RAID no es una copia.

      Lo siguiente

      • Unir los discos sueltos al pool.
      • Un SSD para el sistema y las bases de datos.

      ¿Hablamos?

      Puedo contar cualquiera de estas decisiones en detalle en una entrevista.

      Descargar CV Contactar ← Volver al rack

      Reconstrucción a partir de mi documentación: sin rutas, nombres de discos ni contenido.