Proxmox Storage: Ceph vs ZFS — El árbol de decisión que nadie te muestra

febrero 6, 2026 • febrero 6, 2026 • Lectura: 30 min • Views: 0

¿Te fue útil?

No sientes las decisiones de almacenamiento el primer día. Las sientes la primera vez que un nodo muere a las 2:13 a.m., el CEO está en un avión con Wi‑Fi intermitente y tu historia de “HA” se convierte en “estamos investigando”. Ahí es cuando descubres si compraste resiliencia o simplemente adquiriste un nuevo pasatiempo.

En Proxmox, la pregunta Ceph vs ZFS parece una comparación de características. En producción, es una decisión sobre modos de fallo. Este artículo es el árbol de decisión que desearía que más equipos hubieran tenido antes de construir con confianza algo equivocado.

El árbol de decisión (úsalo, no las corazonadas)

Aquí está la versión directa. Si no estás de acuerdo, bien: ejecuta las pruebas en este artículo y deja que tus gráficas resuelvan la discusión.

Paso 1: ¿Necesitas almacenamiento compartido para migración en vivo y HA entre nodos?

Si sí, y lo quieres integrado: elige Ceph (RBD). Ese es el objetivo: almacenamiento de bloques distribuido que sobrevive la pérdida de nodos y sigue sirviendo.
Si no (o puedes aceptar “migración con downtime” o enfoques basados en réplicas): ZFS en cada nodo suele ser la mejor relación fiabilidad-esfuerzo que puedes comprar.

Paso 2: ¿Cuántos nodos tienes, realmente?

1 nodo: ZFS. Ceph no es un producto para un solo nodo a menos que estés haciendo laboratorio o disfrutes la complejidad autoinfligida.
2 nodos: ZFS, más un tercer voto (qdevice) para el quórum del clúster. Ceph en 2 nodos es una trampa; inventarás nuevas formas de tristeza.
3 nodos: Ceph se vuelve viable. ZFS sigue siendo más simple. Tu necesidad de almacenamiento compartido y tolerancia a fallos decide.
4–8 nodos: Ceph brilla si necesitas almacenamiento compartido y puedes pagar la red y los discos para hacerlo correctamente.
9+ nodos: Ceph suele ser la opción por defecto para almacenamiento compartido, pero solo si lo tratas como un sistema de almacenamiento, no como una casilla para marcar.

Paso 3: ¿Cuál es tu presupuesto de fallos?

“Un host puede morir y nadie debería notarlo”: Ceph con replicación (size 3) y dominios de fallo razonables.
“Un host puede morir y podemos conmutar en minutos, quizá restaurar algunas VMs”: ZFS con replicación (zfs send/receive), backups y un RTO realista.
“Solo necesitamos buenos discos locales, restauraremos desde backup”: ZFS, mirrors y un plan de respaldo que realmente restaure.

Paso 4: ¿Qué red tienes para el tráfico de almacenamiento?

10GbE con conmutación compartida y sin aislamiento: ZFS suele ganar a menos que tu clúster Ceph sea pequeño y poco cargado. Ceph puede funcionar en 10GbE, pero el rendimiento y la recuperación te pelearán.
25GbE+ red de almacenamiento dedicada (o al menos VLAN/QoS bien separadas): Ceph se vuelve mucho más predecible, especialmente durante backfill/rebalance.

Paso 5: ¿Qué tipo de IO hacen realmente tus VMs?

Escrituras aleatorias sensibles a latencia (bases de datos, colas): los mirrors ZFS suelen sentirse más rápidos. Ceph puede hacerlo, pero debes diseñarlo: OSDs NVMe, buena red y recuperación afinada.
Principalmente lecturas, escrituras moderadas, muchas VMs: Ceph encaja bien si quieres almacenamiento compartido y aceptas la amplificación de escritura de replicación/EC.
Cargas secuenciales grandes: ambos lo manejan; elige según el modelo operativo y el comportamiento ante fallos.

Paso 6: ¿Quién lo operará a las 2 a.m.?

Equipo pequeño, baja tolerancia a on-call específico de almacenamiento: ZFS. Menos piezas móviles, menos comportamientos emergentes a nivel de clúster.
Equipo que puede invertir en madurez operativa: Ceph puede volverse aburrido—en el buen sentido—una vez que eres disciplinado.

Regla de opinión: si eliges Ceph para evitar comprar un SAN compartido, aún debes pagar lo equivalente en red, discos y esfuerzo operativo. Ceph no es “almacenamiento compartido barato.” Es “almacenamiento compartido que posees”.

Lo que realmente estás comprando: semántica y modos de fallo

ZFS en Proxmox: verdad local, integridad fuerte

ZFS es un sistema de archivos y gestor de volúmenes con checksum extremo a extremo, copy-on-write, snapshots, replicación y un modelo de caché que puede hacer que tus VMs se sientan ágiles. En Proxmox, ZFS suele usarse como almacenamiento local por nodo: pools para discos de VM (zvols) y datasets para backups o plantillas.

Qué obtienes: rendimiento predecible, excelente integridad de datos y simplicidad operativa. Si un nodo muere, el almacenamiento muere con él—a menos que hayas replicado en otro sitio.

Qué no obtienes: almacenamiento de bloques compartido listo para usar. Puedes construir semánticas compartidas mediante replicación y orquestación, pero eso no es lo mismo que “cualquier nodo puede ejecutar cualquier VM ahora mismo con su disco adjunto”.

Ceph en Proxmox: almacenamiento de bloques distribuido, compartido por diseño

Ceph te da un clúster de almacenamiento: los OSD almacenan datos, los MON mantienen el estado del clúster y los clientes (tus nodos Proxmox) hablan con el clúster por la red. Con RBD obtienes dispositivos de bloque compartidos que Proxmox puede usar para discos de VM. Si un nodo o disco muere, el clúster se cura re-replicando datos.

Qué obtienes: almacenamiento compartido, replicación auto-reparadora, conocimiento de dominios de fallo y la capacidad de perder un nodo sin perder acceso a discos de VM.

Qué no obtienes: simplicidad. Estás operando un sistema distribuido. Los sistemas distribuidos son fantásticos, hasta que te das cuenta de que la red ahora es parte de tu controlador RAID.

Verdad seca: ZFS tiende a fallar “localmente y a todo pulmón”. Ceph tiende a fallar “globalmente y de forma sutil” si está mal configurado, porque la salud del clúster y los comportamientos de recuperación pueden degradarlo todo a la vez.

Idea parafraseada (atribuida): Werner Vogels (CTO de Amazon) ha impulsado durante mucho tiempo la idea de que “todo falla, así que diseñas para falla”. Las decisiones de almacenamiento son donde o haces eso en serio o no lo haces.

Hechos interesantes y contexto histórico (para que dejes de repetir errores de 2012)

Ceph empezó como proyecto de investigación (el doctorado de Sage Weil), y su diseño temprano apostó fuertemente por hardware de commodity y fiabilidad impulsada por software.
CRUSH (el algoritmo de colocación de Ceph) está diseñado para evitar cuellos de botella de metadatos centralizados calculando la colocación de objetos, no buscándola.
RBD (RADOS Block Device) se convirtió en el “disco de VM” porque la semántica de bloque mapea limpiamente a hypervisors y formatos de imagen.
ZFS nació en Sun con un modelo de “pool de almacenamiento” que trataba los discos como un recurso gestionado, no como un conjunto fijo de particiones con una plegaria.
ZFS popularizó el checksum extremo a extremo en la conciencia administrativa mainstream: la corrupción silenciosa deja de ser un mito cuando ZFS te muestra las pruebas.
Los clústeres Ceph tempranos tenían reputación de complejidad operativa porque el tuning de recuperación, los counts de PG y la variación de hardware podían hacer el comportamiento impredecible. Mucho ha mejorado, pero la física no cambió.
El erasure coding se volvió importante en Ceph porque la replicación (3x) es cara; EC reduce overhead pero aumenta la complejidad y el coste de escritura.
Proxmox adoptó tanto Ceph como ZFS temprano porque las empresas pequeñas y medianas necesitaban opciones reales de almacenamiento sin comprar todo un ecosistema SAN.

Broma #1: RAID significa “Redundant Array of Inexpensive Disks”, y luego compras los switches 25GbE y se convierte en “Remarkably All-Incostly Decision”.

Hardware y topología: la parte que todo el mundo subfinancia

Hardware para Ceph: los mínimos no son lo mismo que “funciona bien”

Ceph quiere discos consistentes, latencia consistente y suficiente capacidad de red para sobrevivir eventos de recuperación. Funcionará en todo tipo de hardware. También te castigará por decisiones creativas.

Opciones de diseño de discos

HDD OSDs: buenos para capacidad, malos para latencia de escritura aleatoria. Aceptables para cargas de VM tipo archivo, no adecuados para bases de datos ocupadas a menos que aceptes mayor latencia.
SSD/SATA OSDs: punto medio utilizable, pero ojo con la resistencia y el rendimiento sostenido de escritura.
NVMe OSDs: la experiencia de “Ceph se siente como almacenamiento local” suele ser NVMe más buena red.

El coste de Ceph a menudo lo domina la amplificación de escritura: la replicación (size 3) escribe múltiples copias; EC reparte datos y paridad entre OSDs; las escrituras pequeñas aleatorias resultan caras. No presupuestes Ceph por TB bruto. Presúpustalo por TB utilizable al nivel de latencia que necesitas durante la recuperación.

Red

Ceph es un sistema de almacenamiento en red. Eso significa que tu bus de almacenamiento es Ethernet. Si lo infraestimas, obtendrás el equivalente de almacenamiento de intentar beber un batido con un removedor de café.

10GbE: puede funcionar para clústeres pequeños, pero la recuperación se comerá tu almuerzo. Necesitas separación del tráfico cliente o una forma extremadamente cuidadosa de traffic shaping.
25GbE: la línea base sensata para “nos importa el rendimiento y el tiempo de recuperación”.
Redes duales: siguen siendo útiles (pública/cliente vs clúster/backfill), pero muchas implementaciones tienen éxito con una sola red bien diseñada si eres disciplinado.

Hardware para ZFS: lo aburrido es una característica

ZFS te recompensa por hacer lo básico: memoria ECC (preferible), vdevs en espejo para almacenamiento de VM y mantener los pools cómodamente por debajo del lleno. ZFS puede usar RAIDZ para capacidad, pero las cargas de VM no son “un gran archivo secuencial”. Son un montón de escrituras aleatorias con gabardina.

Mirror vs RAIDZ en cargas VM en Proxmox

Mirrors: menor latencia, mayor IOPS, comportamiento de rebuild más simple. Excelente por defecto para pools de VM.
RAIDZ2/3: mejor eficiencia de capacidad, pero penalización en escrituras aleatorias y tiempos de resilver que pueden ser dolorosos. Mejor para almacenamiento en bloque, backups y cargas menos sensibles a latencia.

SLOG y L2ARC: deja de comprar piezas mágicas primero

La mayoría de equipos no necesitan un dispositivo SLOG separado. Si tu carga es mayormente escrituras asíncronas (común en muchas cargas de VM), SLOG no ayudará mucho. Si ejecutas bases de datos con muchas escrituras sync y te importa la latencia, entonces sí, un SLOG de alta gama con protección ante pérdida de energía puede importar.

L2ARC puede ayudar en lecturas, pero también consume RAM para metadatos y puede crear una falsa sensación de seguridad. Empieza con suficiente RAM y un layout de pool sensato. Añade L2ARC cuando puedas demostrar un problema de misses en caché.

Realidad del rendimiento: latencia, IOPS, reconstrucciones y el impuesto del “vecino ruidoso”

Ceph: estado estable vs estado de fallo

En estado estable, Ceph puede ofrecer excelente throughput y buena latencia—especialmente con NVMe y redes rápidas. En estado de fallo (OSD caído, nodo en reboot, fallo de red), Ceph comienza a hacer lo que está diseñado para hacer: re-replicar, backfill, rebalance. Ese trabajo de recuperación compite con el IO cliente.

Tu trabajo es asegurarte de que la recuperación no se convierta en un apagón de clúster. Eso significa:

Tener margen correcto de red y rendimiento de disco.
Configuraciones de recuperación/backfill razonables (no “ilimitadas, YOLO”).
Dominios de fallo que coincidan con la realidad (host, chasis, rack).

ZFS: el ARC te hace parecer listo (hasta que no)

El rendimiento de ZFS suele percibirse como “rápido” porque el ARC (caché en memoria) oculta la latencia de lectura. Eso es un valor real. Pero también puede ocultar que tu pool está infra-provisionado para escrituras, o que estás a punto de alcanzar la fragmentación y ser destrozado por escrituras sync.

Otra realidad divertida de ZFS: una vez que superas ~80% de utilización del pool, el rendimiento a menudo se degrada. La gente discute el número exacto; tus gráficas no. Mantén pools de VM con margen. No estás guardando fotos familiares. Estás almacenando plazos de otras personas.

“Vecino ruidoso” en la práctica

Con pools locales ZFS, una VM ruidosa tiende a afectar ese nodo. Con Ceph, una VM ruidosa puede amplificarse en dolor a nivel de clúster si genera mucho IO de escritura que provoca tráfico de replicación y demoras en la recuperación. Por eso QoS y límites sensatos de disco para VMs importan más en el territorio Ceph.

Sobrecarga operativa: quién está de guardia para qué

Operación ZFS: menos piezas móviles, pero debes hacer replicación/backups

La carga operativa de ZFS es principalmente:

Monitorear la salud de los pools (scrubs, SMART, contadores de error).
Gestionar snapshots y retención (no hagas snapshots para siempre; eso no es un plan, es procrastinación).
Replicación si quieres resiliencia más allá de un host.
Gestión de capacidad: añade vdevs, no te encierres en una esquina de expansión RAIDZ.

Operación Ceph: un clúster de almacenamiento es un ser vivo

Ceph requiere comodidad con:

Salud del clúster: placement groups, backfill, objetos degradados.
Troubleshooting de red como habilidad de almacenamiento, no como hobby de otro equipo.
Gestión de cambios: añadir OSDs cambia la colocación de datos y dispara re-balanceo.
Entender comportamientos de recuperación: tradeoffs entre velocidad e impacto.

Broma #2: Ceph es como tener un pulpo mascota—brillante, potente, y si lo ignoras un fin de semana redecorará la casa.

Tres mini-historias corporativas (todas lo bastante reales como para doler)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana migró de ZFS local a Ceph porque querían migración en vivo sin fricción. El ingeniero de almacenamiento (buenas intenciones, tiempo limitado) asumió que la red 10GbE existente sería “suficiente” porque los benchmarks en estado estable parecían aceptables. Construyeron un clúster Ceph de 4 nodos, replicación size 3, mezclaron OSDs SSD SATA y algunos discos más antiguos “temporalmente”, y salieron a producción.

Dos meses después, un OSD empezó a flapping—subía/bajaba cada pocos minutos—por un disco marginal y un HBA que no toleraba bien su cableado. Ceph hizo lo que Ceph hace: empezó el backfill, luego se pausó, luego reanudó, luego volvió a empezar. La latencia de IO cliente subió. Los discos de VM empezaron a agotar tiempos de espera. Los hypervisors parecían “sanos”, pero el almacenamiento estaba esencialmente thrashing.

La suposición equivocada fue sutil: asumieron que el tráfico de recuperación era una tarea de fondo. No lo es. En Ceph, la recuperación es una carga de trabajo de primera categoría. En 10GbE, la recuperación más IO cliente puede saturar los mismos enlaces, causando picos de latencia que parecen “problemas aleatorios de aplicación”.

La solución no fue glamorosa. Aislaron el tráfico de almacenamiento, mejoraron los interconectores y establecieron límites conservadores de recuperación durante horario laboral. También estandarizaron las clases de medios de OSD y dejaron de mezclar discos “temporales” con perfiles de latencia distintos.

La lección: si no puedes permitirte el margen de red para eventos de recuperación, no puedes permitirte Ceph. Solo estás pidiendo fiabilidad prestada del futuro a interés terrible.

Mini-historia 2: La optimización que salió mal

Otra organización ejecutaba Proxmox con mirrors ZFS. Estaban limitados por capacidad y decidieron “optimizar” cambiando nuevos pools a RAIDZ2. Las cuentas eran atractivas. Los dashboards se veían mejor. Finanzas estaba encantada.

Luego la carga de VM cambió. Un equipo añadió una canalización analítica intensiva en escrituras, muchas escrituras aleatorias pequeñas y un par de bases de datos configuradas para fsync agresivo. La latencia pasó de “aceptable” a “mi aplicación está poseída”. ZFS empezó a gastar mucho tiempo haciendo la matemática de paridad y lidiando con patrones de escritura aleatoria que RAIDZ no disfruta. Los scrubs y resilvers se alargaron. El rendimiento bajo carga se volvió intermitente.

Intentaron parchearlo con SSDs más rápidos como L2ARC, lo que ayudó principalmente lecturas y no hizo nada por el dolor de latencia en escrituras. Luego compraron un SLOG sin verificar si su carga estaba realmente limitada por sync writes. No lo estaba, al menos no de la forma que pensaban. El SLOG mejoró algunas métricas pero no arregló el problema visible para los usuarios.

Eventualmente migraron el almacenamiento de las VMs más cargadas de nuevo a vdevs en espejo y mantuvieron RAIDZ2 para datasets masivos y backups. La ganancia de capacidad fue real, pero era el tier equivocado para esa carga.

La lección: optimizar sin un modelo de carga es ruleta de rendimiento. A veces ganas. Operaciones recuerda cuando no lo haces.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa relacionada con salud ejecutaba Proxmox con Ceph para discos de VM compartidos. Nada lujoso: OSDs NVMe consistentes, VLAN de almacenamiento dedicada y una ventana de cambios estricta. La parte poco sexy era su rutina semanal: revisar la salud de Ceph, verificar scrubs, chequear contadores SMART y probar la restauración de al menos una VM desde backups.

Un jueves, un switch top-of-rack empezó a perder paquetes bajo carga. No cayó totalmente. Suficiente para causar picos intermitentes de latencia. Las aplicaciones comenzaron a quejarse. Los hypervisors parecían bien. Las gráficas de almacenamiento mostraron aumento de retransmisiones y caída de throughput cliente.

Porque tenían líneas base aburridas, vieron rápido qué había cambiado: aumentaron los errores de red y Ceph empezó a mostrar ops lentas. Ralentizaron la recuperación, desviaron algo de tráfico y coordinaron con redes para cambiar hardware. El clúster se mantuvo disponible.

El verdadero salvavidas llegó después. Durante el evento de red, un OSD fue marcado como out y empezó a backfillear. Lo notaron inmediatamente con los chequeos rutinarios de salud, confirmaron que los datos se estaban reequilibrando de forma segura y evitaron que una segunda falla se convirtiera en una situación de riesgo de datos pausando tareas de mantenimiento no esenciales.

La lección: prácticas aburridas—líneas base, chequeos rutinarios de salud y pruebas de restauración—convierten un “apagón misterioso” en un “incidente controlado”. No es glamoroso. Es cómo mantienes los fines de semana.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decidir

A continuación hay tareas prácticas que puedes ejecutar en nodos Proxmox. Cada una incluye: un comando, una salida de ejemplo realista, qué significa y la decisión que impulsa. Ejecútalas. No las debatas en Slack.

Tarea 1: Confirma qué tipos de almacenamiento cree Proxmox que tienes

cr0x@server:~$ pvesm status
Name             Type     Status  Total     Used     Available  %
local            dir      active  196.00G   21.30G    164.70G  10%
local-zfs        zfspool  active  1.75T     612.00G   1.14T    35%
ceph-rbd         rbd      active  10.00T    6.20T     3.80T    62%

Significado de la salida: Tienes tanto ZFS local como Ceph RBD configurados, y Ceph está al 62% de uso.

Decisión: Si Ceph es tu store principal de discos de VM, 62% no es “lleno”, pero está lo suficientemente avanzado como para que la recuperación/rebalance cueste más. Planifica capacidad antes del 75–80%.

Tarea 2: Verifica la salud del pool ZFS y detecta problemas silenciosos temprano

cr0x@server:~$ zpool status -x
all pools are healthy

Significado de la salida: No hay errores conocidos, no hay vdevs degradados.

Decisión: Si esto no es “all pools are healthy”, deja de discutir Ceph vs ZFS y arregla tu pool actual primero. La higiene del almacenamiento precede a los debates de arquitectura.

Tarea 3: Inspecciona el layout de ZFS (mirror vs RAIDZ te dice expectativas de rendimiento)

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

        NAME                         STATE     READ WRITE CKSUM
        rpool                        ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1        ONLINE       0     0     0
            ata-SAMSUNG_SSD_2        ONLINE       0     0     0
          mirror-1                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_3        ONLINE       0     0     0
            ata-SAMSUNG_SSD_4        ONLINE       0     0     0

Significado de la salida: Dos vdevs en espejo (mirrors en stripe). Excelente para IOPS de VM y comportamiento de rebuild.

Decisión: Si estás en RAIDZ para discos de VM y eres sensible a la latencia, este es el momento para considerar migrar cargas calientes a mirrors.

Tarea 4: Comprueba compresión y volblocksize de ZFS (asesinos silenciosos de rendimiento)

cr0x@server:~$ zfs get -o name,property,value -s local compression,volblocksize local-zfs/vmdata
NAME               PROPERTY      VALUE
local-zfs/vmdata   compression   lz4
local-zfs/vmdata   volblocksize  8K

Significado de la salida: Compresión LZ4 activada (usualmente buena), volblocksize 8K (común para discos de VM).

Decisión: Si la compresión está desactivada, actívala salvo que tengas una razón específica. Si volblocksize es grande para cargas de escritura aleatoria, espera amplificación de escritura.

Tarea 5: Comprueba la presión del ARC (el rendimiento ZFS suele igualar la realidad de RAM)

cr0x@server:~$ arcstat 1 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:11   892    73      8    39   53    34   47     0    0   48G   56G

Significado de la salida: ARC es 48G, target 56G, tasa de misses 8%. No es terrible.

Decisión: Si miss% es consistentemente alto y tus discos están ocupados, considera más RAM antes de comprar SSDs de caché. La RAM es la mejora de rendimiento más barata en ZFS.

Tarea 6: Confirma si las escrituras sync son un cuello de botella (aquí se decide SLOG)

cr0x@server:~$ zfs get -o name,property,value sync local-zfs/vmdata
NAME               PROPERTY  VALUE
local-zfs/vmdata   sync      standard

Significado de la salida: Comportamiento sync por defecto. Las apps que solicitan sync lo obtendrán; otras no.

Decisión: No pongas sync=disabled para “arreglar rendimiento” en discos de VM. Si lo haces, renombra tu clúster a “maybe-later” y actualiza tu currículum.

Tarea 7: Comprueba la salud del clúster Ceph a simple vista

cr0x@server:~$ ceph -s
  cluster:
    id:     8e0c2d8f-7e2b-4c2a-9d1b-2c9e5d2e3a1a
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 38 sec
            1 osds down
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 12 osds: 11 up, 12 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   13 TiB used, 24 TiB / 37 TiB avail
    pgs:     240 active+clean
             16  active+degraded

Significado de la salida: Un OSD está down pero aún “in”, y tienes ops lentas y PGs degradados.

Decisión: Trata HEALTH_WARN con slow ops como un incidente de producción si persiste. Encuentra el OSD caído y la razón antes de reiniciar cualquier otra cosa.

Tarea 8: Identifica rápidamente el OSD caído o inestable

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         37.260   root default
-3         12.420       host pve1
 0    ssd   3.105            osd.0     up   1.00000  1.00000
 1    ssd   3.105            osd.1   down   1.00000  1.00000
 2    ssd   3.105            osd.2     up   1.00000  1.00000
 3    ssd   3.105            osd.3     up   1.00000  1.00000
-5         12.420       host pve2
 4    ssd   3.105            osd.4     up   1.00000  1.00000
 5    ssd   3.105            osd.5     up   1.00000  1.00000
 6    ssd   3.105            osd.6     up   1.00000  1.00000
 7    ssd   3.105            osd.7     up   1.00000  1.00000
-7         12.420       host pve3
 8    ssd   3.105            osd.8     up   1.00000  1.00000
 9    ssd   3.105            osd.9     up   1.00000  1.00000
10    ssd   3.105            osd.10    up   1.00000  1.00000
11    ssd   3.105            osd.11    up   1.00000  1.00000

Significado de la salida: osd.1 está down en el host pve1.

Decisión: Decide si esto es un problema transitorio del daemon (reiniciar) o un problema de dispositivo (SMART, logs del kernel). Si es hardware, marca y reemplaza correctamente.

Tarea 9: Comprueba si Ceph está haciendo backfill/recover (predictor de impacto)

cr0x@server:~$ ceph -w
2026-02-04T12:03:10.123+0000 mon.pve1 [WRN] Health check update: 1 osds down (OSD_DOWN)
2026-02-04T12:03:12.456+0000 osd.3 [INF] 1.2% backfill_recovery 120/10000 objects recovered
2026-02-04T12:03:13.222+0000 mgr.pve1 [WRN] Slow OSD heartbeats on back (osd.6)

Significado de la salida: Recovery/backfill está activo, además de advertencias de heartbeats lentos (red u OSD sobrecargado).

Decisión: Si la latencia cliente sufre, considera temporariamente limitar la recuperación para mantener los servicios vivos y luego acelerarla fuera de horas.

Tarea 10: Confirma la configuración de replicación de pools Ceph (no puedes adivinar la durabilidad)

cr0x@server:~$ ceph osd pool ls detail
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 128 pgp_num 128 autoscale_mode on
pool 2 'cephfs_data' erasure profile ec-4-2 crush_rule 3 pg_num 64 pgp_num 64 autoscale_mode on

Significado de la salida: Tu pool de discos de VM (rbd) está replicado size 3, min_size 2.

Decisión: Si estás en size 2 por “espacio”, entiende que estás sacrificando tolerancia a fallos. Size 2 frecuentemente convierte una segunda falla en downtime o riesgo de datos.

Tarea 11: Comprueba latencia y utilización de OSDs Ceph (quién es el lento del grupo)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    5                   7
1    0                   0
2    6                   8
3    52                  75
4    6                   9
5    5                   7
6    7                   10

Significado de la salida: osd.3 es dramáticamente más lento que sus pares.

Decisión: Investiga hardware del host de osd.3, salud del disco y red. Un OSD lento puede causar latencia a nivel de clúster por ops lentas.

Tarea 12: Valida la red de almacenamiento (pérdida de paquetes = “Ceph está lento”)

cr0x@server:~$ ip -s link show eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9823456789  8123456  0       0        0       12345
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  7123456  0       0        0       0

Significado de la salida: No hay errores RX/TX ni drops en esta interfaz.

Decisión: Si ves errores/paquetes descartados, arregla la red antes de ajustar Ceph. El tráfico de almacenamiento odia el “casi funciona”.

Tarea 13: Verifica señales de salud de discos (ZFS y Ceph mueren por discos aburridos)

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i "critical_warning|media_errors|num_err_log_entries|percentage_used"
critical_warning                    : 0x00
percentage_used                     : 7%
media_errors                        : 0
num_err_log_entries                 : 0

Significado de la salida: NVMe parece saludable; desgaste bajo, sin errores de medio.

Decisión: Si media_errors sube o critical_warning se activa, deja de confiar en el dispositivo. Planifica su reemplazo antes de que decida por ti.

Tarea 14: Mide latencia de IO en el nodo (prueba si es disco o red)

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    4.25    8.90    0.00   74.74

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  r_await  w_await  aqu-sz  %util
nvme0n1         120.0   850.0  4800.0 55200.0    0.0     2.0     1.2     18.4    6.5   92.0

Significado de la salida: El dispositivo está muy utilizado, y w_await es ~18ms—alto para NVMe, lo que sugiere saturación o encolamiento.

Decisión: Si %util está al máximo y await sube, estás limitado por disco en ese nodo/host OSD. En Ceph, eso puede ser un OSD lento; en ZFS, quizá un vdev está sobrecargado.

Tarea 15: Comprueba configuraciones de IO de disco de VM en Proxmox (a veces el cuello de botella es auto-infligido)

cr0x@server:~$ qm config 101 | egrep -i "scsi|virtio|iothread|cache|discard"
scsihw: virtio-scsi-single
scsi0: ceph-rbd:vm-101-disk-0,discard=on,iothread=1,ssd=1

Significado de la salida: virtio-scsi-single con iothread activado y discard on, usando Ceph RBD.

Decisión: Buena línea base para muchas cargas. Si ves cache=unsafe en algún sitio, trátalo como un item en el registro de riesgos con fecha límite corta.

Tarea 16: Observa IO cliente en Ceph desde la perspectiva del clúster

cr0x@server:~$ ceph osd pool stats
pool rbd id 1
  client_io_rate: 48 MiB/s rd, 22 MiB/s wr, 310 op/s rd, 420 op/s wr
pool cephfs_data id 2
  client_io_rate: 12 MiB/s rd, 4 MiB/s wr, 90 op/s rd, 60 op/s wr

Significado de la salida: El pool RBD está haciendo la mayor parte del IO.

Decisión: Cuando los usuarios dicen “el almacenamiento está lento”, valida si el IO realmente aumentó, o si la latencia subió sin throughput (a menudo red o un OSD).

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

Este es el orden de triaje que uso cuando alguien dice “las VMs están lentas” y la sala empieza a culpar al almacenamiento como ritual.

Primero: ¿es local al nodo o a todo el clúster?

Comprueba la carga del nodo Proxmox: si un nodo está caliente, puede ser IO local o scheduling de CPU.
Comprueba si solo las VMs en Ceph están afectadas: si sí, céntrate en salud de Ceph y red; si no, puede ser CPU del host, presión de memoria o un problema de red compartida.

Segundo: ¿Ceph está inestable o recuperando?

Ejecuta: ceph -s y busca HEALTH_WARN/ERR, slow ops, PGs degradados, OSD down, recovery/backfill.
Decisión: Si hay recuperación en curso, asume que contribuye a la latencia. Decide si limitar temporalmente la recuperación.

Tercero: ¿es pérdida/latencia de red?

Comprueba errores/paquetes descartados en interfaces: ip -s link en todos los nodos y puertos VLAN de almacenamiento.
Mira advertencias de heartbeat en Ceph: a menudo apuntan a micro-pérdidas de red o enlaces saturados.
Decisión: Si ves drops/retransmisiones, trata la red como sospechoso principal.

Cuarto: ¿es un disco/OSD lento?

Ceph: ceph osd perf para identificar outliers; luego chequea SMART y dmesg en el host.
ZFS: zpool status para errores; iostat -x para saturación; comprueba si un vdev lleva más carga.
Decisión: Reemplaza hardware fallando temprano. Un disco degradado pero aún funcionando es cómo empiezan los outages.

Quinto: ¿es configuración de VM o comportamiento del invitado?

Comprueba bus de disco y iothreads: dispositivos mal configurados pueden limitar rendimiento.
Comprueba comportamiento fsync del invitado: las bases de datos pueden convertir el almacenamiento en un microscopio de latencia.
Decisión: Si una VM es la culpable, aplica límites de IO o muévela a un tier diseñado para ella.

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

1) Síntoma: “Ceph está lento durante el día, bien por la noche”

Causa raíz: Recovery/backfill compite con IO cliente; la carga en horario laboral no deja margen.

Solución: Limita la recuperación durante picos; aumenta capacidad de red; usa medios más rápidos; reduce la varianza en rendimiento de OSDs.

2) Síntoma: Congelamientos/tiempos de espera aleatorios en VMs sobre Ceph

Causa raíz: Pérdida de paquetes o micro-bursts en la red de almacenamiento; un OSD flapping; acumulación de ops lentas.

Solución: Valida contadores de error y salud de switches; aísla tráfico de almacenamiento; corrige MTU; reemplaza discos/OSDs inestables.

3) Síntoma: Pool ZFS “saludable” pero el rendimiento se degrada con el tiempo

Causa raíz: Pool demasiado lleno; fragmentación; snapshots retenidos para siempre; escrituras aleatorias pequeñas en RAIDZ.

Solución: Mantén margen; poda snapshots; migra almacenamiento caliente de VMs a vdevs en espejo; añade vdevs antes de la crisis.

4) Síntoma: “Añadir discos empeoró Ceph”

Causa raíz: Rebalanceo/backfill comenzó y saturó red/disco; OSDs no uniformes; dominios CRUSH mal alineados.

Solución: Añade capacidad en ventanas controladas; limita backfill; mantiene consistencia de clases OSD; valida topología CRUSH.

5) Síntoma: Sustos de corrupción ZFS tras un evento de energía

Causa raíz: Sin UPS; SSDs de consumo sin protección ante pérdida de energía; configuraciones de cache de escritura arriesgadas.

Solución: UPS y SSDs adecuados para cargas críticas; evita caching inseguro; prueba procedimientos de recuperación.

6) Síntoma: Ceph parece sano pero persisten picos de latencia

Causa raíz: Un OSD lento (alta apply latency) o contención de CPU en hosts OSD; VM ruidosa saturando IO.

Solución: Usa ceph osd perf e iostat a nivel host; mueve VMs pesadas; aplica límites IO; asegura margen de CPU en hosts OSD.

7) Síntoma: Migración en vivo lenta o falla bajo carga

Causa raíz: Tráfico de migración comparte red limitada con Ceph; o el almacenamiento es ZFS local y en realidad estás copiando discos.

Solución: Separa la red de migración; si necesitas semánticas compartidas, usa Ceph o acepta migración planificada con downtime y replicación.

8) Síntoma: “Pusimos sync=disabled y todo se aceleró”

Causa raíz: Cambiaste durabilidad por velocidad; ahora eres vulnerable a pérdida de datos por corte de energía o panic del kernel.

Solución: Revierte. Si las escrituras sync son demasiado lentas, arregla la ruta de almacenamiento (mirrors, SLOG con PLP, medios más rápidos, tuning), no las leyes de la física.

Listas de verificación / plan paso a paso

Checklist A: Si te inclinas por ZFS (almacenamiento local, ops más simples)

Elige mirrors para pools de VM salvo que tengas una carga probada que encaje en RAIDZ.
Activa compresión (lz4) y verifica que esté en datasets/zvols de VM.
Planifica margen: objetivo <70% usado para pools de VM; trata 80% como un precipicio de rendimiento, no como sugerencia.
Programa scrubs y monitorea errores de checksum.
Implementa replicación (zfs send/receive) a otro nodo o destino de backup si necesitas restauraciones rápidas.
Prueba restauraciones mensualmente como mínimo; más a menudo si cambias políticas de retención.
Decide tu historia de fallo: pérdida de nodo = restaurar desde backup, o conmutar mediante discos de VM replicados.

Checklist B: Si te inclinas por Ceph (almacenamiento compartido, semánticas HA)

Empieza con 3+ nodos con hardware OSD consistente; evita mezclar clases de latencia en el mismo pool.
Presupuesta red correctamente: 25GbE como baseline para cargas serias; aísla tráfico de almacenamiento.
Elige tamaño de replicación intencionalmente (a menudo size 3). Escribe qué fallo tolera.
Define dominios de fallo (host/rack) para que CRUSH coincida con la realidad física.
Establece límites de recuperación/backfill para estabilidad diurna; ten un perfil “fuera de horas” si es necesario.
Monitorea slow ops y outliers de perf de OSD; trátalos como advertencias tempranas.
Practica el reemplazo de OSD en un día no crítico. No quieres que tu primera vez sea durante un estado degradado.

Checklist C: Plan de migración si te equivocaste el año pasado

Inventario de cargas: qué VMs necesitan baja latencia, cuáles necesitan capacidad, cuáles necesitan semánticas compartidas.
Crea tiers: almacenamiento caliente (mirrors/NVMe), almacenamiento general, almacenamiento masivo/backups.
Mueve una carga primero y mide antes/después (latencia, throughput, cola de latencia).
Automatiza rollback para que tu migración no sea una puerta sin retorno.
Documenta runbooks operativos para el nuevo tier (cómo reemplazar disco, cómo diagnosticar IO lento, quién llama a quién).

Preguntas frecuentes

1) ¿Puedo ejecutar Ceph en 3 nodos con mezcla de SSD y HDD?

Puedes, pero probablemente no deberías para discos de VM. Mezclar latencias en el mismo pool tiende a crear dolor por latencia en cola. Si debes mezclar, separa por clase de dispositivo y usa pools diferentes.

2) ¿Ceph siempre es más lento que ZFS local?

No. Pero Ceph añade saltos de red y overhead de replicación. Con hardware y red excelentes, Ceph puede ser rápido y consistente. En “10GbE sobrante”, ZFS local a menudo se sentirá mejor para escrituras sensibles a latencia.

3) ¿RAIDZ es “malo” para almacenamiento de VM en ZFS?

No moralmente. Prácticamente, RAIDZ puede ser una mala opción para cargas de escritura aleatoria de VMs porque la sobrecarga de paridad y el comportamiento de IOPS pueden perjudicar. Mirrors suelen ser el valor por defecto más seguro para discos de VM.

4) ¿Debería usar erasure coding de Ceph para discos de VM?

Usualmente no para discos de VM primarios a menos que tengas una razón sólida y entiendas los tradeoffs de rendimiento. EC brilla en eficiencia de capacidad, a menudo mejor para workloads tipo objeto/archivo que para IO de bloque aleatorio sensible a latencia.

5) ¿Cuál es la red mínima “seria” para Ceph?

Para producción con carga significativa: 25GbE y switching sensato. 10GbE puede funcionar, pero acabarás afinando alrededor de eventos de recuperación y viviendo con más variaciones.

6) ¿Necesito RAM ECC para ZFS?

Altamente recomendado, especialmente para cargas críticas. ZFS protege los datos en disco con checksums, pero errores en RAM aún pueden causar malos resultados. ECC reduce una clase de fallos silenciosos y feos.

7) ¿Cómo difieren operativamente los snapshots entre Ceph y ZFS?

Los snapshots de ZFS son extremadamente maduros y fáciles de razonar. Los snapshots RBD de Ceph existen y son útiles, pero tu músculo operativo será más fuerte con flujos de trabajo estilo ZFS. Para backups en Proxmox, normalmente usarás Proxmox Backup Server en cualquier caso.

8) ¿Puedo combinarlos: ZFS local y Ceph para compartido?

Sí, y muchas tiendas lo hacen. Pon cargas sensibles a latencia o con afinidad a nodo en ZFS local, y usa Ceph para VMs que se benefician del almacenamiento compartido y HA. El truco es tener reglas de colocación claras y monitorear ambas rutas.

9) ¿Cuál es la razón más común por la que Ceph decepciona?

Red infra-provisionada y hardware OSD inconsistente. La gente espera que el almacenamiento distribuido se comporte como un SSD local. Ceph puede hacerlo, pero solo si lo pagas en diseño.

10) ¿Cuál es la razón más común por la que ZFS decepciona?

Presión de capacidad y proliferación de snapshots. Los pools se llenan demasiado, el rendimiento cae y entonces alguien “lo arregla” borrando lo incorrecto. Planifica margen y retención desde el día uno.

Próximos pasos que puedes hacer esta semana

Ejecuta las tareas de comando anteriores en tu clúster actual y anota qué es verdad (layout, salud, outliers de latencia, drops de red). Eso será tu línea base.
Decide qué necesitas realmente: semánticas de almacenamiento compartido (Ceph) o almacenamiento local fuerte con replicación/backups (ZFS). No finjas necesitar ambos si no es cierto.
Si estás en Ceph: valida aislamiento y margen de red; confirma pool size/min_size; identifica OSDs lentos y arréglalos antes de que se vuelvan incidentes.
Si estás en ZFS: confirma mirrors para pools de VM, compresión activada y suficiente margen; audita retención de snapshots; haz una prueba de restauración que incluya arrancar una VM.
Escribe la historia de fallo en una página: “Si un nodo muere, hacemos X; si un disco muere, hacemos Y; si la red falla, hacemos Z.” Si no puedes escribirlo, todavía no lo posees.

La decisión Ceph vs ZFS no es “cuál es mejor”. Es “qué conjunto de tradeoffs quieres depurar a las 2 a.m.” Elige el que puedas operar, no el que gane en un foro.