Tiering en ZFS: NVMe, SSD y disco

Un vistazo en 33 segundos

No necesitas que todo sea NVMe: ZFS deja combinar discos rápidos y lentos en un pool y colocar cada dato donde toca.
El ARC (caché en RAM) es lo que más acelera ZFS, y es gratis: dale RAM. El L2ARC lo extiende a un SSD, pero solo ayuda en casos concretos.
El SLOG acelera escrituras síncronas (bases de datos, NFS), no todas; si tu carga no las usa, no aporta nada.
El special vdev guarda metadatos y bloques pequeños en SSD/NVMe: acelera muchísimo el trabajo con muchos ficheros, pero si muere, se pierde el pool (hay que ponerlo con redundancia).
La trampa: añadir dispositivos «para ir más rápido» sin saber qué acelera cada uno. Casi siempre, más RAM para el ARC gana.

Hay una creencia cara y muy extendida: para que el almacenamiento vaya rápido, todo tiene que ser NVMe. Es cara porque el NVMe de capacidad cuesta un dineral, y es falsa porque ignora cómo funciona ZFS. ZFS está diseñado precisamente para lo contrario: combinar unos pocos dispositivos rápidos con mucha capacidad lenta y barata, y poner cada tipo de dato donde le saca el máximo partido. Bien montado, un pool con un poco de NVMe y mucho disco girando rinde, en la práctica, casi como uno todo-NVMe por una fracción del precio.

El problema es que ZFS ofrece varias piezas de aceleración —ARC, L2ARC, SLOG, special vdev— con nombres crípticos, y mucha gente las añade a lo loco, «para ir más rápido», sin entender qué acelera cada una. El resultado es dinero tirado en dispositivos que no ayudan a su carga, o —peor— un special vdev sin redundancia que se lleva el pool entero por delante cuando falla.

Este artículo explica qué hace de verdad cada pieza, cuál acelera qué, y cómo decidir cuáles te convienen según tu carga real sobre Proxmox. Sin magia y sin gastar de más.

Primero, la que más importa y es gratis: el ARC

Antes de comprar nada, entiende esto: lo que más acelera ZFS ya lo tienes, y es la RAM. El ARC (Adaptive Replacement Cache) es la caché de lectura de ZFS en memoria. Guarda los datos y metadatos más usados en RAM, y como la RAM es órdenes de magnitud más rápida que cualquier disco, un buen ratio de aciertos del ARC hace que ZFS vuele sin tocar los discos.

La consecuencia práctica choca con la intuición de mucha gente: antes de gastar en SSD de caché, dale RAM al servidor. Cada gigabyte de RAM que ZFS puede usar para el ARC acelera más que casi cualquier dispositivo que añadas después. Es la mejora con mejor relación coste-beneficio, y muchos la ignoran por ir directos a comprar «un SSD de caché» que ayuda menos.

Solo cuando el ARC ya no da más de sí —porque el conjunto de datos activo no cabe en la RAM que puedes poner— tiene sentido mirar las piezas de abajo. Y cada una resuelve un problema distinto.

Las piezas de aceleración, una por una

L2ARC: extender la caché de lectura a un SSD

El L2ARC es una segunda capa de caché de lectura, en un SSD, para lo que no cupo en el ARC de RAM. Suena bien, pero tiene truco: mantener el índice del L2ARC consume RAM, esa misma RAM que el ARC podría estar usando. Un L2ARC mal dimensionado puede incluso empeorar las cosas, robándole memoria al ARC.

Cuándo ayuda de verdad: cuando tienes un conjunto de datos de lectura grande, que no cabe en RAM (y no puedes poner más), pero sí cabría en un SSD. Casos de mucha lectura repetida sobre un dataset mayor que la RAM. Cuándo no: si tu problema son las escrituras, o si tu conjunto activo ya cabe en el ARC. En muchos servidores, el L2ARC es una solución a un problema que no tienen.

SLOG: acelerar escrituras síncronas (solo esas)

Aquí hay más malentendidos que en ninguna otra pieza. El SLOG no es una caché de escritura general. No acelera todas las escrituras. Solo acelera las escrituras síncronas: aquellas en las que la aplicación exige confirmación de que el dato está a salvo antes de seguir. Bases de datos, NFS, iSCSI y algunas cargas concretas las usan; muchas otras no.

El SLOG (un dispositivo rápido y con protección ante cortes, idealmente con condensadores) permite a ZFS confirmar esas escrituras síncronas al instante y consolidarlas al pool después. Si tu carga hace escrituras síncronas, un SLOG las transforma; si no las hace, un SLOG no cambia absolutamente nada. Antes de comprar uno, averigua si tu carga usa escrituras síncronas. Si no lo sabes, probablemente no las use tanto como para justificarlo.

Special vdev: metadatos y bloques pequeños en rápido (con cuidado)

Esta es la pieza más potente y la más peligrosa. Un special vdev es un dispositivo rápido (SSD/NVMe) donde ZFS guarda los metadatos del pool y, opcionalmente, los bloques pequeños. ¿Por qué acelera tanto? Porque gran parte de la lentitud de un pool de discos girando no está en leer los datos grandes, sino en el ir y venir constante buscando metadatos: qué ficheros hay, dónde están, sus atributos. Poner eso en NVMe hace que operaciones con muchos ficheros —listar, buscar, recorrer— pasen de lentas a instantáneas, aunque los datos sigan en disco lento.

Pero viene con una advertencia en mayúsculas: si el special vdev muere, se pierde el pool entero. Los metadatos son el índice de todo; sin ellos, los datos son ilegibles. Por eso un special vdev SIEMPRE debe llevar redundancia —espejo de dos o tres dispositivos—, igual que el pool principal. Un special vdev en un único SSD es una bomba de relojería: el día que ese SSD falla, no pierdes una caché, pierdes todo. Este es el error más grave que se comete con ZFS tiering.

Cada pieza se enchufa en un sitio distinto y resuelve un problema distinto. El special vdev es el único cuyo fallo se lleva el pool entero.

Qué acelera qué: la tabla de decisión

Pieza	Acelera	Cuándo ayuda	Riesgo si falla
ARC (RAM)	Lecturas (todo)	Siempre. Empieza aquí	Ninguno (es RAM)
L2ARC (SSD)	Lecturas que no caben en RAM	Datasets de lectura grandes, sin más RAM posible	Ninguno (solo caché)
SLOG (SSD/NVMe)	Escrituras síncronas	Bases de datos, NFS, iSCSI	Bajo (con dispositivo espejado)
special vdev (SSD/NVMe)	Metadatos y ficheros pequeños	Muchos ficheros, operaciones de metadatos	Alto: se pierde el pool. Redundancia obligatoria

La lectura de la tabla: el orden correcto de inversión es RAM → special vdev (con redundancia) → SLOG/L2ARC según carga. No al revés, y no todo a la vez «por si acaso».

Un diseño típico que rinde y no arruina

Para un pool de Proxmox con VMs y datos, un montaje equilibrado y sensato:

Mucha RAM para el ARC. La inversión número uno.
Discos de capacidad (disco girando o SSD SATA grandes) como vdev principal, con la redundancia que toque (espejo, RAID-Z).
Un special vdev en espejo de NVMe para metadatos y bloques pequeños, si trabajas con muchos ficheros o quieres que las operaciones de listado/búsqueda vuelen. Siempre redundante.
Un SLOG solo si tu carga hace escrituras síncronas de verdad (bases de datos, NFS servido desde el pool).
L2ARC solo si el conjunto de lecturas desborda la RAM y no puedes ampliarla.

Con esto, un pool mayoritariamente de disco barato se comporta como algo mucho más caro, porque lo caliente y los metadatos viven en NVMe y lo frío —la mayoría, por volumen— en capacidad barata. Que es exactamente la promesa del tiering: pagar rápido solo por lo que necesita ser rápido.

Preguntas frecuentes

¿Necesito que todo el almacenamiento sea NVMe para que ZFS vaya rápido? No. ZFS está diseñado para combinar poca capacidad rápida con mucha capacidad lenta y barata. Con suficiente RAM para el ARC y, si acaso, un special vdev de NVMe para metadatos, un pool mayoritariamente de disco girando rinde en la práctica casi como uno todo-NVMe, por una fracción del coste.

¿Qué es mejor, añadir un SSD de caché o más RAM? Casi siempre más RAM. El ARC en RAM es lo que más acelera ZFS y es la mejor relación coste-beneficio. Un SSD de caché (L2ARC) solo ayuda en casos concretos —conjunto de lectura mayor que la RAM que puedes poner— y encima consume algo de RAM para su índice. Empieza siempre por la RAM.

¿El SLOG acelera todas las escrituras? No, solo las escrituras síncronas (las que exigen confirmación antes de seguir): bases de datos, NFS, iSCSI. Si tu carga no hace escrituras síncronas, un SLOG no cambia nada. Antes de comprar uno, confirma que tu carga las usa; si no, es dinero tirado.

¿Por qué el special vdev necesita redundancia obligatoria? Porque guarda los metadatos del pool: el índice de dónde está todo. Si el special vdev falla y no hay redundancia, los datos quedan ilegibles y se pierde el pool entero, no solo una caché. Por eso siempre debe ir en espejo de dos o tres dispositivos, igual que el resto del pool.

¿Puedo añadir estas piezas a un pool ZFS que ya existe? El L2ARC y el SLOG se pueden añadir y quitar en caliente sin problema. El special vdev se puede añadir a un pool existente, pero afecta solo a los datos escritos a partir de ese momento (los metadatos antiguos no se mueven solos), y quitarlo es delicado según la topología. Planifícalo con cuidado y con backups.

Fuentes

OpenZFS, documentación sobre ARC, L2ARC y caché.
OpenZFS, documentación de special vdev (allocation classes).
Proxmox, ZFS on Linux en Proxmox VE.
OpenZFS, documentación sobre ZIL y escrituras síncronas (SLOG).

¿Quieres almacenamiento rápido en tu cloud privado sin pagar todo a precio de NVMe? Diseñamos contigo el pool ZFS con el tiering correcto sobre Proxmox —la RAM, el special vdev y el SLOG que tu carga necesita, ni uno más—. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.