Almacenamiento para virtualización en Proxmox: ZFS vs Ceph vs iSCSI vs NFS

Reglas de decisión que realmente puedes usar

Si recuerdas una cosa, que sea esta: no estás eligiendo “almacenamiento”, estás eligiendo modos de fallo. El rendimiento es una característica; la previsibilidad es un producto.

Elige ZFS (local) cuando

• Puedes tolerar que el almacenamiento de un solo nodo no sea compartido automáticamente.
• Quieres integridad de datos fuerte y comportamientos de recuperación transparentes.
• Tu carga de trabajo es mayormente “las VM viven en el nodo en el que se ejecutan”, con migración/HA manejadas por replicación o copias de seguridad.
• Valoras la simplicidad operativa: una caja, un pool, un conjunto de herramientas.

Orientación opinada: Para 1–3 nodos, ZFS es la respuesta por defecto a menos que tengas un requisito firme de almacenamiento de bloque compartido y migración en caliente sin planificación.

Elige Ceph cuando

• Necesitas almacenamiento compartido entre muchos hipervisores y esperas que los nodos fallezcan sin drama.
• Puedes permitirte 3+ nodos (en serio) y suficientes discos para que la replicación tenga sentido.
• Tienes la red para soportarlo: baja latencia, sin sobre-subscriptión, idealmente dedicada al tráfico de almacenamiento.
• Estás dispuesto a ejecutar un sistema distribuido a propósito, no por accidente.

Orientación opinada: Ceph es genial cuando tienes un clúster. Es un hobby cuando tienes dos nodos y un sueño.

Elige iSCSI cuando

• Ya posees un arreglo de almacenamiento o SAN que hace snapshots, replicación y tiene contratos de soporte.
• Quieres semántica de bloque y gestión centralizada del almacenamiento.
• Puedes configurar multipath correctamente y entiendes el radio de explosión de un solo arreglo.

Orientación opinada: iSCSI está bien si el arreglo es el producto. Si tu “arreglo” es una VM Linux con un par de discos, estás reinventando la decepción.

Elige NFS cuando

• Quieres la vía más rápida hacia almacenamiento compartido con comportamiento comprensible.
• Almacenas imágenes de VM o backups y puedes vivir con “el servidor es el servidor”.
• Quieres inspección humana fácil y flujos de recuperación más simples.

Orientación opinada: NFS es la furgoneta de uso familiar del almacenamiento para virtualización: no es sexy, casi siempre adecuado, y todo el mundo tiene una opinión sobre los portavasos.

Una cita, idea parafraseada: la idea de fiabilidad de Jim Gray (parafraseada): si no puedes explicar tu modelo de fallo, no tienes un sistema—solo una demo.

Un modelo mental: lo que las VM hacen al almacenamiento

Las máquinas virtuales hacen tres cosas que el almacenamiento odia:

• Escrituras aleatorias desde múltiples invitados a la vez. Incluso las escrituras “secuenciales” del invitado se fragmentan en el host.
• Agitación de metadatos: snapshots, clonación, aprovisionamiento delgado y copy-on-write convierten “escribir datos” en “escribir datos más tareas administrativas”.
• Sensibilidad a la latencia: una VM no es un servidor de base de datos; es una pila de planificadores. Añade 5 ms en la capa de almacenamiento y podrías añadir 50 ms de “¿por qué SSH va lento?” arriba.

Luego sumas realidades específicas de Proxmox:

• Los discos de VM pueden ser raw (lo mejor), qcow2 (con funciones pero con sobrecarga), o RBD (bloque Ceph).
• Backups y snapshots se realizan en el host, no en el invitado, lo cual es genial hasta que tu backend de almacenamiento interpreta eso como “amplificación de escritura sorpresa”.
• La migración en caliente quiere almacenamiento compartido o copia rápida. “Copia rápida” sigue siendo copia. Copiar sigue siendo IO.

Entonces la pregunta se vuelve: ¿dónde quieres que viva la complejidad—en cada nodo (ZFS), en un NAS/SAN compartido (NFS/iSCSI), o dentro del tejido del clúster (Ceph)?

Broma 1/2: El almacenamiento es el único lugar donde “funcionó en pruebas” es código para “nadie probó la VM vecino ruidosa”.

ZFS en Proxmox: local-primero, fiabilidad-primero

ZFS es un sistema de archivos y gestor de volúmenes que se comporta como si le ofendiera personalmente la corrupción silenciosa. Checksums por todas partes. Semántica copy-on-write. Snapshots que realmente sirven. Send/receive para replicación que es aburrido en el mejor sentido.

En qué ZFS es excelente en virtualización

• Recuperación predecible: un vdev en espejo pierde un disco, lo reemplazas, resilver. Sin magia.
• Snapshots con herramientas reales: los snapshots de ZFS son baratos; lo que te cuestan es fragmentación a largo plazo y crecimiento de metadatos si guardas demasiados.
• Rendimiento local: con espejos NVMe y suficiente RAM, ZFS es brutalmente rápido para cargas de VM.
• Integridad de datos: checksums end-to-end detectan discos malos, cables malos, controladores malos y días malos.

Lo que ZFS no es

ZFS no es almacenamiento compartido por defecto. Puedes replicar, puedes hacer backups, puedes construir una capa compartida encima, pero ZFS por sí solo no te dará almacenamiento de bloque compartido transparente entre nodos.

Reglas de diseño que te mantienen fuera de problemas

• Los espejos vencen a RAIDZ para latencia de VM. RAIDZ puede ser adecuado para cargas secuenciales, con mucha capacidad y lectura intensiva. Las escrituras aleatorias de VM no son esa carga.
• No te obsesiones con SLOG a menos que entiendas las escrituras sync. Para muchas cargas de VM, o no necesitas un SLOG o necesitas uno muy bueno. Un “SLOG SSD” barato es una trampa de fiabilidad si miente sobre la protección contra pérdida de energía.
• Usa discos/volúmenes raw cuando sea posible. qcow2 tiene funciones; también añade sobrecarga. ZVOLs o archivos raw suelen comportarse mejor con IO caliente.
• Mantén los snapshots bajo control. Cientos de snapshots en datasets de VM ocupados convertirán lentamente tu “pool rápido” en un “pool rápido (recreación histórica)”.

Los ajustes que importan (y por qué)

Tres perillas aparecen en los postmortems más de lo que deberían:

• ashift (alineación del tamaño de sector). Equivocarlo al crear el pool y horneas amplificación de escritura.
• recordsize / volblocksize. Desajuste con la carga y desperdicias IO o amplificas escrituras.
• sync. “sync=disabled” es cómo conviertes una batería UPS en una lotería de pérdida de datos.

Ceph en Proxmox: almacenamiento distribuido con dientes reales

Ceph es lo que ocurre cuando quieres que el almacenamiento se comporte como un primitivo de nube: autocurativo, replicado, escalable y nativo de red. Puede ser glorioso. También puede ser una lección en física en cámara lenta.

En qué Ceph es excelente

• Almacenamiento de bloque compartido (RBD) entre hosts, con migración en caliente que no implica copiar discos por todos lados.
• Tolerancia a fallos cuando está bien diseñado: un OSD muere, un host muere, discos mueren y el clúster sigue sirviendo.
• Palanca operativa a escala: añades nodos, añades OSDs, reequilibras y sigues adelante.

Lo que Ceph exige

• Calidad de red: latencia y pérdida de paquetes se verán como “lentitud aleatoria de VM” y “tareas bloqueadas”.
• Presupuesto de IOPS: la replicación significa que pagas las escrituras varias veces. Las escrituras pequeñas se multiplican y se registran. No es opcional.
• Espacio libre: operar cerca del lleno no es “eficiente”, es un acantilado de rendimiento. El reequilibrio necesita espacio.
• Madurez operativa: debes poder interpretar el estado del clúster, estados de backfill y comportamiento de placement groups sin hacer clics de pánico.

Ceph para Proxmox: guía práctica

Para discos de VM, usa RBD a menos que tengas una necesidad específica de un sistema de archivos POSIX; CephFS es genial, pero suele ser mejor para archivos compartidos, no para discos de VM calientes. Si tu carga es sensible a la latencia y con muchas escrituras, presupuestar OSDs rápidos (NVMe o SSDs muy buenos) y una red de almacenamiento real.

El ajuste de Ceph no es tanto sobre sysctls mágicos sino sobre arquitectura sensata: suficientes OSDs, replicación apropiada, suficiente CPU por host y no ejecutar Ceph en los mismos nodos débiles que querías usar como cómputo.

Broma 2/2: Ceph es “simple” de la misma forma que un contenedor de envío es “solo una caja”. Las partes interesantes son todo lo que está alrededor.

iSCSI: almacenamiento en bloque con aristas afiladas

iSCSI es almacenamiento en bloque sobre IP. No es moderno, no es tendencia y no va a desaparecer. En entornos corporativos suele ser la vía de menor resistencia porque ya existe un SAN y un equipo que habla LUN con fluidez.

Cuando iSCSI es la respuesta correcta

• Necesitas almacenamiento de bloque compartido y confías más en tu array que en un almacenamiento distribuido DIY.
• Quieres snapshots/replicación centralizados manejados por el array (y el proveedor asume las llamadas a medianoche).
• Puedes implementar multipath y redes redundantes correctamente.

Modos de fallo que debes aceptar

• Radio de explosión centralizado: una caída del array es dolor para todo el clúster.
• Sensibilidad a la ruta de red: microburst y MTU mal configurada pueden parecer “corrupción de disco de VM” cuando en realidad son timeouts y resets.
• Interacciones entre profundidad de cola y latencia: una VM parlanchina puede empujar el LUN hacia latencias de cola si el array no está bien aprovisionado.

En Proxmox, a menudo emparejarás iSCSI con LVM o ZFS sobre iSCSI (sí, puedes, pero hazlo con intención). Si ya tienes ZFS local, apilar ZFS encima de iSCSI suele significar duplicar la complejidad sin ganancias claras.

NFS: almacenamiento compartido sencillo (hasta que no lo es)

NFS es almacenamiento de archivos sobre la red. Es fácil de configurar, fácil de razonar y fácil de superar. Para muchos clústeres Proxmox es el compromiso correcto: almacenamiento compartido para ISO/plantillas/backups e incluso discos de VM si las necesidades de rendimiento son moderadas y el servidor es decente.

NFS brilla cuando

• Quieres almacenamiento compartido sin ejecutar un sistema de almacenamiento distribuido.
• Valoras la recuperación directa: monta el export en otro sitio y tus archivos están ahí.
• Tu carga no es extremadamente sensible a la latencia ni muy intensiva en escrituras.

NFS duele cuando

• Tu NAS está subdimensionado y se convierte en el cuello de botella único.
• Las opciones de montaje son incorrectas para imágenes de VM (el comportamiento de caché y bloqueo importa).
• Tratas NFS como almacenamiento en bloque y esperas que se comporte como un SAN.

Proxmox soporta bien NFS. Solo no pretendas que sea magia. El servidor NFS ahora es una dependencia crítica: monitorízalo, actualízalo y dale almacenamiento que no se caiga durante scrub/reconstrucción RAID.

Hechos interesantes y un poco de historia (lo útil)

1. ZFS nació en Sun Microsystems a mediados de los 2000 con checksums end-to-end como característica central, no como un añadido.
2. Copy-on-write precede a la virtualización moderna; es una idea antigua que se volvió mainstream porque snapshots y clones son oro operativo.
3. Ceph comenzó como un proyecto universitario y se convirtió en una plataforma de almacenamiento open-source adoptada fuertemente en la era OpenStack.
4. RBD existe porque los sistemas de archivos no bastaban para la semántica de bloque en la nube: imágenes, clones y snapshots a escala querían una interfaz de bloque nativa.
5. NFS data de los años 80 y aún sobrevive porque “un sistema de archivos compartido” sigue siendo una necesidad fundamental, y es lo suficientemente simple para depurar con paquetes.
6. iSCSI se estandarizó a principios de los 2000 para llevar acceso tipo SAN a redes Ethernet comunes.
7. La amplificación de escritura no es un problema teórico: los sistemas COW más cargas de VM pueden multiplicar las escrituras de backend dramáticamente, especialmente con snapshots y bloques pequeños.
8. El algoritmo de placement “CRUSH” de Ceph está diseñado para evitar tablas de búsqueda centralizadas para la colocación de datos, lo que importa cuando escalas.
9. Proxmox popularizó el clúster “baterías incluidas” para tiendas pequeñas y medianas: obtienes KVM, gestión, backups e integración de almacenamiento sin montar una docena de componentes por tu cuenta.

12+ tareas prácticas: comandos, salidas, decisiones

Estos son los chequeos que ejecuto cuando alguien dice “el almacenamiento está lento” o “las migraciones se pusieron raras”. Cada tarea incluye: comando, qué significa la salida y qué decisión tomar.

Tarea 1: Identificar el backend de almacenamiento por VM

cr0x@server:~$ qm config 101
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: app01
scsi0: local-zfs:vm-101-disk-0,size=120G
ide2: local:iso/debian-12.iso,media=cdrom
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0

Significado: local-zfs te dice que es un volumen respaldado por ZFS en este nodo, no compartido. Si esperabas almacenamiento compartido para migración en caliente, acabas de encontrar la discrepancia.

Decisión: Para HA/migración en caliente sin tiempo de inactividad, mueve el disco de la VM a Ceph/NFS/iSCSI o implementa replicación ZFS + conmutación planeada.

Tarea 2: Confirmar qué storages reconoce Proxmox

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active      102305280        25165824        77175168   24.60%
local-zfs        zfspool  active     9999220736      2130706432      7868514304   21.31%
ceph-rbd         rbd      active    29997662208      8996782080     209,?         29.99%

Significado: Confirma qué backends están online y si Proxmox puede alcanzarlos. Si Ceph muestra capacidad rara o está inactivo, deja de culpar a “la VM”.

Decisión: Si un store compartido está inestable, trátalo como un incidente en la capa de almacenamiento, no en cómputo.

Tarea 3: Chequeo de salud de ZFS (no adivines)

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

Significado: Pool sano. Si el rendimiento es malo, no es porque ZFS esté actualmente degradado.

Decisión: Si esto reporta vdevs degradados o errores de checksum, deja el trabajo de rendimiento y empieza por la seguridad de datos.

Tarea 4: Verificar diseño del pool ZFS (espejos vs RAIDZ)

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

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1   ONLINE       0     0     0
            nvme1n1   ONLINE       0     0     0

Significado: vdev en espejo. Bueno para latencia de VM. Si ves RAIDZ1/2 con un número pequeño de discos y VMs con muchas escrituras, espera mayor latencia cola.

Decisión: Si la latencia de VM es el problema y estás en RAIDZ, considera migrar VMs calientes a espejos o vdevs SSD/NVMe.

Tarea 5: Revisar propiedades ZFS que afectan el comportamiento de VM

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

Significado: Valores sensatos: lz4 ayuda más de lo que perjudica; atime=off evita escrituras de metadatos; sync=standard es seguro.

Decisión: Si ves sync=disabled en datasets de VM, decide si aceptas perder escrituras recientes tras un fallo. La mayoría de entornos de producción no deberían.

Tarea 6: Encontrar presión en ARC (RAM como componente de rendimiento)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   812    74      9     9   12    65   88     0    0   48G   56G
12:01:02   790    80     10     8   10    72   90     0    0   48G   56G
12:01:03   805    77     10     7    9    70   91     0    0   48G   56G

Significado: Tamaño ARC vs objetivo (arcsz vs c) y tasa de misses. Una tasa alta de misses en cargas estables puede significar que tu working set no cabe en RAM.

Decisión: Si los misses son consistentemente altos y los discos están ocupados, añade RAM o mueve cargas calientes a medios más rápidos; no afines antes de dimensionar correctamente.

Tarea 7: Comprobar latencia IO en vivo en el host

cr0x@server:~$ iostat -x 1 3
Linux 6.8.12-pve (pve1)  12/28/25  _x86_64_  (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   310.0  4096.0 18560.0   2.10   0.25  11.0
nvme1n1         118.0   305.0  4000.0 18200.0   2.35   0.24  10.7

Significado: await es la métrica práctica de “qué tan mal se siente”. Si await está entre 20–200 ms, los invitados se quejarán. Si %util está al máximo, estás saturado.

Decisión: Await alto con baja util sugiere colas en otro lugar (controlador, bloqueos de filesystem, red). Await alto con alta util sugiere que necesitas más spindles/IOPS.

Tarea 8: Mapear qué proceso/VM está haciendo IO

cr0x@server:~$ pvesh get /nodes/pve1/qemu --output-format json-pretty
[
  {
    "cpu": 0.17,
    "diskread": 1610612736,
    "diskwrite": 987654321,
    "mem": 0.62,
    "name": "db01",
    "pid": 24510,
    "status": "running",
    "uptime": 182003,
    "vmid": 110
  },
  {
    "cpu": 0.04,
    "diskread": 10485760,
    "diskwrite": 7340032,
    "mem": 0.28,
    "name": "app01",
    "pid": 25111,
    "status": "running",
    "uptime": 55321,
    "vmid": 101
  }
]

Significado: Vista rápida por VM. La VM “db01” está generando IO real. Correlaciona con métricas de latencia.

Decisión: Si una VM domina el IO y causa daño colateral, aísla: pool dedicado, QoS, clase OSD separada o muévela fuera de NFS compartido.

Tarea 9: Comprobación de saneamiento del montaje NFS (las opciones importan)

cr0x@server:~$ findmnt -t nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET           SOURCE                  FSTYPE OPTIONS
/mnt/pve/nfs-vm  nas01:/export/proxmox   nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys

Significado: Quieres montajes hard para imágenes de VM (para evitar corrupción silenciosa por escrituras cortas), y rsize/wsize razonables. NFSv4.2 suele ser buena si el NAS lo soporta.

Decisión: Si ves montajes soft, arréglalo. “Soft” es para lecturas no críticas, no para discos de VM.

Tarea 10: Comprobación de latencia del servidor NFS desde el cliente

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
1248933    120        0

Client nfs v4:
ops count  retrans
READ 402911  18
WRITE 311220 47
COMMIT 1021   0

Significado: Retransmisiones indican problemas de red/servidor. Unas pocas ocurren; una tasa en aumento se correlaciona con bloqueos y congelamientos de VM.

Decisión: Si retrans spikean durante incidentes, deja de tunear Proxmox y empieza a mirar carga del NAS, errores NIC, buffers del switch, mismatch de MTU.

Tarea 11: Estado de sesión iSCSI y multipath

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.10.50:3260,1 iqn.2020-01.com.vendor:san01.lun1 (non-flash)
tcp: [2] 10.10.11.50:3260,1 iqn.2020-01.com.vendor:san01.lun1 (non-flash)

cr0x@server:~$ multipath -ll
mpatha (3600a098038314c6a6b5d4a6f4b6a6f30) dm-3 VENDOR,Array
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:10 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:10 sdc 8:32 active ready running

Significado: Dos sesiones iSCSI: probablemente dos fabrics/VLANs. Multipath muestra camino activo y camino habilitado. Si tienes un solo camino, no tienes redundancia.

Decisión: Si los caminos flaquean o uno está abajo, arregla la red antes de culpar al array o a Proxmox.

Tarea 12: Salud del clúster Ceph a simple vista

cr0x@server:~$ ceph -s
  cluster:
    id:     3c3b1e2d-aaaa-bbbb-cccc-111122223333
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 12 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 4h)
    mgr: pve1(active), standbys: pve2
    osd: 12 osds: 12 up (since 3h), 12 in (since 3h)

  data:
    pools:   2 pools, 128 pgs
    objects: 1.02M objects, 3.9 TiB
    usage:   11 TiB used, 22 TiB / 33 TiB avail
    pgs:     127 active+clean, 1 active+clean+scrubbing

Significado: “slow ops” es una señal de alarma para latencia. Se está realizando scrub. A veces scrub coincide con jitter visible por el usuario.

Decisión: Si slow ops persisten, revisa latencia de OSD y red. Si el scrub causa problemas, ajusta ventanas y prioridades en lugar de deshabilitar scrubs para siempre.

Tarea 13: Latencia OSD de Ceph y contadores de rendimiento

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    3                   4
1    4                   5
2    45                  52
3    3                   4

Significado: OSD 2 está enfermo comparado con sus pares. A menudo es un disco malo, un dispositivo saturado o un vecino ruidoso en ese nodo.

Decisión: Drena/marca fuera el OSD malo si es necesario, o investiga el host/disco específico. No “tunées Ceph” globalmente para compensar un dispositivo fallando.

Tarea 14: Revisa la presión de backups de Proxmox (el almacenamiento puede estar bien, los backups lo matan)

cr0x@server:~$ grep -E "vzdump|INFO:|ERROR:" /var/log/syslog | tail -n 8
Dec 28 01:10:02 pve1 vzdump[31120]: INFO: starting new backup job: vzdump 110 --storage nfs-backup --mode snapshot
Dec 28 01:10:05 pve1 vzdump[31120]: INFO: VM 110 - starting backup
Dec 28 01:10:09 pve1 vzdump[31120]: INFO: VM 110 - using inotify to track modifications
Dec 28 01:12:41 pve1 vzdump[31120]: INFO: VM 110 - backup finished

Significado: Los backups se están ejecutando durante la ventana de dolor. El modo snapshot es bueno, pero aún genera IO de lectura y trabajo de metadatos.

Decisión: Si la latencia de almacenamiento coincide con ventanas de backup, cambia horarios, limita concurrencia o mueve destinos de backup fuera del mismo cuello de botella.

Guion de diagnóstico rápido: qué revisar primero/segundo/tercero

Este es el orden que encuentra respuestas rápido. La meta no es la perfección; es detener la discusión y aislar la capa.

Primero: determina si es local al host, compartido o por red

• Revisa la ubicación del disco de la VM: qm config <vmid>.
• Revisa la lista de storages: pvesm status.
• Si es Ceph/NFS/iSCSI, asume que la red está involucrada hasta demostrar lo contrario.

Segundo: mide la latencia donde importa

• Latencia de disco del host: iostat -x 1.
• “slow ops” de Ceph y ceph osd perf.
• Retransmisiones NFS: nfsstat -c.
• Salud de ruta iSCSI: multipath -ll.

Tercero: busca estados degradados/de recuperación

• ZFS: zpool status para resilver/scrub/errores de checksum.
• Ceph: estados de recovery/backfill/scrub en ceph -s.
• NAS/array: ¿está reconstruyendo, scrubeando o haciendo snapshots?

Cuarto: encuentra la VM bully y la correlación temporal

• Contadores IO por VM: pvesh get /nodes/<node>/qemu.
• Revisa ventanas de backup y jobs de snapshot.
• Busca un inquilino que sature colas compartidas.

Quinto: valida lo aburrido

• Errores y drops NIC: ip -s link, contadores del switch.
• Consistencia de MTU (especialmente si intentaste jumbo frames).
• Steal/ready de CPU y IO wait: el dolor de almacenamiento puede simular contención de CPU.

Errores comunes: síntomas → causa raíz → arreglo

1) Las VM se congelan 30–120 segundos en NFS

Síntomas: Logs del invitado muestran timeouts de disco; el host muestra mensajes “server not responding”; luego todo se recupera.

Causa raíz: Fallos momentáneos del servidor NFS (carga, latencia de almacenamiento o pérdida de red). Los montajes hard hacen que los clientes esperen (lo cual es más seguro que corromper datos).

Arreglo: Arregla el cuello de botella del NAS o la red. Valida opciones de findmnt. Considera mover discos de VM sensibles a ZFS local o Ceph RBD.

2) El pool ZFS parece sano pero las VM van lentas durante snapshots

Síntomas: Picos de latencia durante ventanas de backup; patrones de IO se vuelven aleatorios; aumentan misses de ARC.

Causa raíz: Cargas con muchos snapshots incrementan metadatos y fragmentación; los backups pueden inducir tormentas de lectura.

Arreglo: Reduce recuento/retención de snapshots, escalona backups, separa datasets calientes y prefiere raw/ZVOL para discos críticos de rendimiento.

3) Ceph se siente rápido por semanas y luego se vuelve “pegajoso”

Síntomas: HEALTH_WARN slow ops; jitter de IO en VM; tareas bloqueadas ocasionales.

Causa raíz: Operar cerca de la capacidad o un OSD fallando lentamente. Backfill/recovery compite con IO de clientes.

Arreglo: Mantén headroom, reemplaza discos fallando temprano y planifica scrubs con sentido. No ignores un OSD rezagado en ceph osd perf.

4) iSCSI “funciona” pero aparecen errores aleatorios de sistema de archivos en invitados

Síntomas: Invitados muestran errores ext4/xfs; multipath muestra flapping; dmesg tiene resets SCSI.

Causa raíz: Ruta de red inestable, MTU erróneo, cables/óptica malos o multipath/tiempos mal configurados.

Arreglo: Estabiliza enlaces, aplica paths redundantes, alinea MTU end-to-end y valida salud de multipath. No lo ocultes con reintentos.

5) ZFS “sync=disabled” hizo las cosas rápidas… hasta que parpadeó la energía

Síntomas: Tras un crash, algunas VM arrancan con sistemas de archivos corruptos; bases de datos necesitan reparación.

Causa raíz: Deshabilitar sync confirmó escrituras antes de que fueran seguras en medios estables.

Arreglo: Vuelve a sync=standard, añade un SLOG apropiado con protección contra pérdida de energía si necesitas latencia en sync, y usa UPS correctamente (sin sustituirlo).

6) Ceph en 1 GbE “más o menos funciona” pero las migraciones son brutales

Síntomas: Latencia alta en picos; IO de cliente se bloquea; recovery tarda una eternidad.

Causa raíz: La red es el backplane de Ceph. 1 GbE es un impuesto que pagas por cada escritura.

Arreglo: Mejora a por lo menos 10 GbE (a menudo 25 GbE en despliegues serios), separa tráfico de almacenamiento y deja de tratar la red como opcional.

Listas de verificación / plan paso a paso

Si construyes un setup Proxmox de 1–3 nodos

1. Por defecto usa espejos ZFS locales para discos de VM.
2. Usa un almacenamiento separado (a menudo NFS) para ISOs/plantillas/backups.
3. Decide desde el inicio cómo manejarás la falla de un nodo:
   • Replicación ZFS entre nodos para VMs importantes, o
   • Restaurar desde backups con RTO/RPO definidos.
4. Dimensiona RAM teniendo en cuenta ARC; no prives a ZFS.
5. Mantén la retención de snapshots sensata; diseña horarios de backup alrededor del IO.

Si construyes un clúster de 4+ nodos y quieres almacenamiento compartido

1. Elige Ceph RBD si puedes proporcionar:
   • 3+ nodos mínimo (para quorum y replicación),
   • Dispositivos de almacenamiento rápidos,
   • Una red de almacenamiento seria.
2. Separa dominios de fallo: host, disco, rack (si tienes).
3. Planifica headroom de capacidad: no operes cerca del lleno.
4. Operationaliza chequeos de salud: slow ops, OSD perf, ventanas de scrub.
5. Prueba fallos: saca un OSD, reinicia un host, valida recuperación y efecto en latencia.

Si tu empresa ya posee un SAN/NAS

1. Usa iSCSI para almacenamiento de bloque de VM si el array está probado y soportado.
2. Usa NFS para archivos compartidos, plantillas y backups donde la semántica de archivos ayude.
3. Implementa multipath y switching redundante como si fuera serio.
4. Consigue acceso a telemetría del array o diagnosticarás a ciegas.

Una simple matriz “qué debo elegir”

• ZFS: mejor para rendimiento local y integridad de datos; almacenamiento compartido vía replicación/backups.
• Ceph: mejor para almacenamiento compartido y resiliencia a escala de clúster; exige red y madurez operativa.
• iSCSI: mejor cuando ya tienes un SAN real; radio de explosión alto pero predecible con un buen array.
• NFS: mejor para simplicidad y archivos compartidos; aceptable para discos de VM con un buen NAS y cargas moderadas.

Tres micro-historias corporativas desde las trincheras del almacenamiento

Incidente causado por una suposición equivocada: “NFS es solo disco local más lento”

Tenían un clúster Proxmox ordenado: tres nodos de cómputo y un appliance NAS que a todos les gustaba por su UI amigable y luces parpadeantes. Los discos de VM vivían en NFS porque facilitaba la migración y el equipo de almacenamiento decía “es redundante”.

La suposición era que NFS se comporta como un disco local más lento. Esto significa: si el NAS está ocupado, las VM se vuelven más lentas. El comportamiento real es más duro: si el NAS se pausa el tiempo suficiente, los clientes se bloquean fuertemente. Eso no es un bug; es cómo los montajes “hard” preservan la corrección.

Una tarde, un scrub programado del NAS coincidió con un job de backup de Proxmox. El NAS no se cayó. Simplemente tardó más en responder. Los kernels invitados comenzaron a loggear timeouts de IO. Las bases de datos hicieron lo que hacen las bases de datos cuando se asustan: dejaron de confiar en su propio mundo.

El postmortem fue incómodo porque la gráfica que todos miraban era throughput. El throughput parecía bien. La latencia fue el asesino, y nadie estaba graficando retransmisiones NFS o profundidad de cola del NAS.

La solución fue aburrida: mover VMs sensibles a latencia a espejos ZFS locales, mantener NFS para backups/plantillas, y añadir monitorización que muestre latencia cola y retransmisiones. La migración dejó de ser tan mágica. Los incidentes se volvieron mucho menos frecuentes.

Optimización que salió mal: “Deshabilitemos sync; es más rápido”

En otra empresa tenían ZFS en espejos SSD y unas cuantas VMs con carga transaccional. Veían picos periódicos de latencia de escritura y alguien propuso la clásica solución: poner sync=disabled en el dataset. El rendimiento mejoró al instante. Aplausos. Un ticket se cerró.

Dos meses después, tuvieron un breve evento de energía. No un corte dramático—más bien el tipo que hace parpadear las luces y te recuerda que el edificio es más viejo que tu pipeline CI. Los hosts se reiniciaron. La mayoría de las VMs volvieron. Algunas no. Una base de datos sí, pero la capa de aplicación empezó a lanzar inconsistencias de datos sutiles.

Ahora la “optimización de rendimiento” era un problema de respuesta a incidentes con legal mirando de cerca. El equipo descubrió la dura verdad: cuando deshabilitas sync, intercambias durabilidad por velocidad. A veces ese intercambio es aceptable en laboratorio. En producción necesitas ser explícito, documentarlo y obtener aprobación de los que serán culpados después.

La solución final no fue exótica. Revirtieron a comportamiento seguro de sync y añadieron un dispositivo SLOG con protección contra pérdida de energía para las cargas que necesitaban escrituras sync de baja latencia. También mejoraron las pruebas del UPS y dejaron de confiar en “tiene baterías” como especificación de diseño.

Práctica aburrida pero correcta que salvó el día: “Headroom y ensayo de fallos”

Una empresa con Proxmox + Ceph tenía una regla que todos criticaban: mantener espacio libre por encima de un umbral y nunca dejar que el clúster se acerque al lleno. Era impopular porque parecía presupuesto desaprovechado. Finanzas ama un disco lleno; los ingenieros aman un pager tranquilo.

También ejecutaban un ensayo trimestral de fallos. No caos teatral—simplemente extraer un OSD, reiniciar un nodo y ver qué pasaba. Registraban el tiempo de recuperación y el efecto en latencia de VM. No fue divertido. Fue trabajo.

Entonces un host murió un lunes por la mañana. Una muerte real: placa madre, no reinicio. Ceph reequilibró, los clientes siguieron funcionando y el clúster permaneció utilizable. La latencia subió, pero no se volvió no lineal porque había espacio para backfill y la red no estaba al límite.

La recuperación se sintió anticlimática. Ese es el mayor cumplido que le puedes dar al almacenamiento.

Lo que los salvó no fue una bandera secreta de Ceph. Fue headroom, monitorización y ya haber visto el sistema fallar de manera controlada.

Preguntas frecuentes

1) ¿Debo usar ZFS o Ceph para un clúster Proxmox de dos nodos?

Usa ZFS local y replica o haz backups. Ceph en dos nodos es posible de formas raras, pero rara vez vale el riesgo operativo y las compensaciones de rendimiento.

2) ¿RAIDZ es malo para Proxmox?

No “malo”, pero a menudo la herramienta equivocada para latencia de VM. Los espejos suelen ofrecer mejor IOPS y menor latencia cola para cargas aleatorias de escritura típicas de VMs mixtas.

3) ZFS en SSD: ¿necesito un SLOG?

Solo si tienes un volumen significativo de escrituras sync y te importa su latencia. Si añades un SLOG, hazlo enterprise-grade con protección contra pérdida de energía, o habrás construido una trampa de fiabilidad.

4) Para Ceph en Proxmox, ¿debo usar RBD o CephFS para discos de VM?

RBD para discos de VM en la mayoría de los casos. CephFS es excelente para sistemas de archivos compartidos, pero las cargas de discos de VM suelen mapear mejor a semánticas de bloque.

5) ¿Puedo ejecutar Ceph y VMs en los mismos nodos Proxmox?

Sí, y muchos lo hacen. Pero dimensiona CPU/RAM en consecuencia y recuerda: cuando la carga de VM sube, los daemons de Ceph compiten por recursos. Si quieres almacenamiento predecible, considera nodos dedicados a almacenamiento a mayor escala.

6) ¿NFS es aceptable para discos de VM?

Sí, si el NAS es potente y tu carga no es ultra sensible a latencia. Es común en clústeres pequeños. Monitoriza latencia y retransmisiones, y no uses montajes “soft”.

7) iSCSI vs NFS para Proxmox: ¿cuál es más rápido?

Depende más del servidor/array y la red que del protocolo. iSCSI puede ofrecer comportamiento de bloque predecible; NFS puede ser más simple operativamente. Elige en base a modos de fallo y manejabilidad, no por una captura de benchmark.

8) ¿Los discos de VM deben ser qcow2 o raw?

Raw suele ser más rápido y simple. qcow2 aporta funciones (como snapshots internos) pero añade sobrecarga. En Proxmox, prefiere raw/ZVOL para discos calientes a menos que necesites las funciones de qcow2.

9) ¿Cuál es la forma más rápida de saber si Ceph es el problema o la VM es el problema?

Revisa ceph -s por slow ops y ceph osd perf por outliers, luego correlaciona con iostat del host y síntomas de latencia de disco en la VM. Si Ceph muestra slow ops, no es “solo la VM”.

10) ¿Puedo mezclar HDD y SSD en Ceph?

Puedes, pero hazlo deliberadamente (clases de dispositivo separadas, pools separados). Mezclarlos a ciegas suele significar que los discos rápidos pasan su vida esperando a los lentos.

Conclusión: siguientes pasos prácticos

Elige un backend de almacenamiento según cómo quieres que se vean las caídas, no según cómo quieres que se vean los dashboards.

• Si eres pequeño (1–3 nodos), construye espejos ZFS locales para discos de VM, mantén NFS para backups y artefactos compartidos, e implementa replicación/backups con una restauración probada.
• Si eres un clúster real (4+ nodos) y puedes financiar la red y los discos, usa Ceph RBD y trátalo como el sistema distribuido que es: moniotirízalo, deja headroom y ensaya fallos.
• Si ya posees un arreglo apropiado, iSCSI es una respuesta corporativa sensata—solo haz multipath correctamente y acepta la dependencia centralizada.
• Si quieres almacenamiento compartido sin una plataforma distribuida, NFS sigue siendo lo más simple que funciona, y la simplicidad es una característica de rendimiento a las 3 a.m.

Tu próxima acción debe ser específica: ejecuta las tareas de diagnóstico arriba en un día normal, captura la latencia base y escribe qué significa “sano”. El incidente llegará después. Siempre llega. Al menos haz que llegue a adultos preparados.