Ceph en Proxmox: cuándo merece la pena, cuándo es una trampa y cómo dimensionarlo correctamente

Cuándo Ceph en Proxmox merece la pena

Ceph en Proxmox merece la pena cuando necesitas almacenamiento de bloque compartido para virtualización que pueda crecer,
sobrevivir fallos y ser operado sin vendor lock-in. La frase clave es “necesitas”, no “sería genial”.

Encaja cuando estas afirmaciones son verdad

• Necesitas HA + migración en vivo a escala sin un gran SAN/NAS central.
• Puedes dedicar hardware real (NVMe, CPU, RAM, red) al comportamiento de almacenamiento, no solo a la capacidad.
• Esperas fallos (un disco al mes, un host por trimestre) y quieres que el clúster los soporte.
• Puedes ejecutar al menos tres nodos (y preferiblemente más) con hardware y redes consistentes.
• Tu carga es mayoritariamente discos de VM (RBD) con patrones de E/S razonables, no un desfile caótico de escrituras sincrónicas pequeñas.
• Tienes disciplina de operaciones: monitorización, ventanas de mantenimiento, control de firmware y una persona que se haga responsable de la salud del almacenamiento.

Lo que Ceph te da y que es difícil de simular

El valor real no es “almacenamiento distribuido”. Es tolerancia a fallos predecible y elasticidad operacional.
Cuando agregas nodos, añades capacidad y rendimiento. Cuando un host muere, los datos siguen ahí. Cuando un disco falla, lo reemplazas
y Ceph sana. Si lo montas sensatamente, esto es aburrido en el mejor sentido.

Si quieres una regla de decisión en una frase: Ceph merece la pena cuando quieres que el almacenamiento falle como un servicio, no como un dispositivo.

Cuándo es una trampa (y qué hacer en su lugar)

La trampa es pensar que Ceph son “tres servidores y algunos discos”. Eso es como creer que un datacenter es “una habitación y algo de electricidad”.
Ceph es un sistema distribuido. Es sensible a la latencia, hambriento de red durante la recuperación y extremadamente honesto respecto a la física.

Señales de alarma que normalmente significan “no implementes Ceph aquí”

• Dos nodos o “añadiremos el tercero más tarde”. Ceph necesita quórum y dominios de fallo; “más tarde” no es un diseño.
• 1GbE o “tráfico de almacenamiento y VM comparten el mismo switch barato”. La recuperación te destrozará.
• Hardware mixto donde la mitad de los nodos son viejos y la mitad nuevos. Los OSD más lentos marcan el ritmo durante la recuperación.
• Presupuesto centrado en capacidad: muchos HDD, SSDs diminutos, RAM mínima, CPU mínima.
• Bases de datos con muchas escrituras y fsyncs intensos, o aplicaciones que hacen escrituras sincrónicas por transacción sin agrupar.
• Sin tiempo de operador. Si nadie se hace cargo del almacenamiento, el clúster terminará adueñándose de vosotros.

Qué hacer en su lugar (alternativas realistas)

• Nodo único o pequeño clúster de laboratorio: ZFS en cada nodo, replicar con ZFS send, aceptar que la migración en vivo no es gratuita.
• Dos nodos en producción: usa un SAN/NAS compartido o un tercer host testigo ligero para quórum (pero no finjas Ceph).
• Bases de datos sensibles a latencia: NVMe local con replicación a nivel de aplicación; o un appliance de almacenamiento dedicado.
• Presupuesto ajustado: menos nodos, más potentes, mejor que muchos nodos débiles. Ceph no recompensa “más chatarra”.

Broma #1: Ceph sobre 1GbE es una gran manera de aprender paciencia, mindfulness y cómo explicar “consistencia eventual” a humanos enfadados.

Cómo se comporta Ceph realmente bajo cargas de VM

Proxmox normalmente usa Ceph RBD para los discos de VM. Eso significa que tus lecturas y escrituras de VM se convierten en operaciones de objetos
contra placement groups (PGs), distribuidas entre OSDs y replicadas (o codificadas por borrado) entre dominios de fallo.
Es elegante. También implacable: cada escritura se convierte en múltiples escrituras.

Pools replicados: el predeterminado por una razón

Un pool replicado con size=3 escribe datos en tres OSDs. Tu “escritura de 1GB” son tres escrituras más trabajo de metadatos.
La ventaja es baja amplificación de lectura y lógica de reconstrucción simple. Para discos de VM, los pools replicados siguen siendo el predeterminado sensato.

Erasure coding: genial en teoría, complicado en la práctica

Erasure coding ahorra capacidad utilizable, pero aumenta el coste de CPU, el tráfico de red y la amplificación de escrituras pequeñas.
Puede funcionar para cargas secuenciales grandes. Para discos de arranque de VM y patrones de escritura aleatoria, a menudo se convierte en una máquina de latencia.
Usa pools EC con precaución, normalmente para datos fríos, backups o patrones de almacenamiento de objetos—no como tu datastore principal de VM.

BlueStore, WAL/DB y el “impuesto de las escrituras pequeñas”

Ceph moderno usa BlueStore (no FileStore). BlueStore tiene su propia metadata (RocksDB) y usa un WAL.
En OSDs HDD, quieres esos componentes DB/WAL en SSD/NVMe, o pagarás latencia por cada operación con muchos metadatos.
En OSDs todo-flash, mantener DB/WAL en el mismo dispositivo está bien; separarlos puede ayudar pero no es obligatorio.

La latencia vence al throughput para virtualización

Los discos de VM están dominados por IO aleatorio pequeño, actualizaciones de metadatos y comportamiento de fsync según el SO invitado.
Si solo miras “GB/s” construirás un clúster que rinde bien en benchmarks y se siente terrible.
Lo que importa: latencia p95 durante operaciones normales y durante recuperación.

Una cita, porque las operaciones guardan recibos

idea parafraseada — Gene Kranz: “los sistemas duros y competentes vienen de la disciplina y la preparación, no del optimismo.”

Hechos y contexto histórico (porque Ceph no apareció por accidente)

• Ceph comenzó como proyecto de investigación en UCSC a mediados de los 2000, con enfoque en eliminar los cuellos de botella de metadatos centralizados.
• Su algoritmo CRUSH fue diseñado para evitar tablas de búsqueda y escalar decisiones de colocación sin un coordinador central.
• La capa RADOS de Ceph es el producto real; bloque (RBD), archivo (CephFS) y objeto (RGW) son “clientes” encima de ella.
• BlueStore reemplazó a FileStore para evitar el doble journaling a través de un filesystem POSIX y mejorar la consistencia del rendimiento.
• CephFS requirió comportamiento estable del servidor de metadatos; pasaron años antes de que se considerara listo para producción en entornos conservadores.
• Proxmox integró Ceph profundamente para hacer el almacenamiento hiperconvergente accesible sin una pila de proveedor de almacenamiento separada.
• Los placement groups existen para agrupar la colocación de objetos; pocos PGs crean cuellos de botella, demasiados aumentan la sobrecarga.
• Los estados de salud de Ceph (HEALTH_OK/WARN/ERR) son deliberadamente contundentes para que los operadores no ignoren problemas “menores” hasta que sean outages.

Dimensionamiento que no te miente

Dimensionar Ceph trata de alinear la tolerancia a fallos, los objetivos de latencia y el tiempo de recuperación.
La capacidad es la parte más fácil—y la más engañosa. La forma correcta es trabajar hacia atrás desde la carga.

Empieza con la única pregunta que importa: ¿qué pasa cuando un nodo muere?

Cuando un nodo muere, Ceph hará backfill/rebalance. Eso significa muchas lecturas desde OSDs sobrevivientes y escrituras a otros.
Tu clúster debe sobrevivir a esto manteniendo la IO de las VM tolerable. Si dimensionas solo para el “camino feliz”, la recuperación se convierte en el outage.

Número de nodos: tres es el mínimo; cinco es donde empieza a sentirse serio

• 3 nodos: usable, pero los dominios de fallo son ajustados. La presión de recuperación es intensa; el mantenimiento es estresante.
• 4 nodos: mejor, pero aún incómodo para algunos diseños CRUSH y programación de mantenimiento.
• 5+ nodos: recuperación más suave, más fácil sacar nodos, mejor distribución de PGs y IO.

Red: trátala como un backplane de almacenamiento, no como “solo Ethernet”

Para Ceph en Proxmox, la red es el chasis. En IO normal empujas tráfico de replicación. En recuperación,
empujas una tormenta. Si tu red está insuficiente, todo se convierte en “latencia aleatoria” y comienza el juego de culpables.

• Mínimo viable: 10GbE, idealmente dedicado o separado por VLAN para tráfico público/cluster.
• Confortable: 25GbE para cargas mixtas, o 10GbE para clústeres all-flash pequeños con afinado cuidadoso.
• Switches: sin bloqueo, con pocos problemas de buffer, MTU consistente y sin políticas QoS “misteriosas”.

Medios OSD: todo-flash es más simple; HDD requiere ayuda de SSD/NVMe

Si ejecutas almacenamiento de VM en OSDs HDD, estás eligiendo un mundo donde la latencia de escritura aleatoria es tu compañía constante.
Puedes hacerlo usable con SSD/NVMe para DB/WAL, suficientes spindles y expectativas realistas. Pero no finjas que se sentirá como SAN flash.

Perfiles de hardware por regla práctica (prácticos, no teóricos)

• Pequeño clúster VM todo-flash (3–5 nodos): 8–16 NVMe por nodo o menos NVMes empresariales grandes; 128–256GB RAM; 16–32 núcleos; 25GbE si puedes.
• Híbrido (HDD capacidad + SSD metadata): 8–16 HDD por nodo más 1–2 NVMe para DB/WAL; 128GB+ RAM; 25GbE fuertemente recomendado.
• “Encontramos discos en un armario”: no lo hagas.

CPU y RAM: Ceph usará felizmente lo que le niegues

Los OSDs consumen CPU para checksums, compresión (si está activada), cálculo EC (si se usa) y canalizaciones de IO generales.
MONs y MGRs necesitan memoria para mantener mapas de clúster y servir clientes sin bloquearse.

• RAM: planifica para memoria de OSD + overhead del host + Proxmox. Privar al host causa jitter que parece “red” o “bug de Ceph”.
• CPU: no sobredimensiones hasta el punto en que los hilos de OSD se preempen bajo carga de VM. Los picos de latencia son el síntoma.

Matemáticas de capacidad que reflejan la realidad

Para pools replicados, la capacidad usable es aproximadamente: raw / replica_size, menos overhead.
Replica size 3 significa que obtienes alrededor de un tercio usable. Luego reserva margen: Ceph necesita espacio para mover datos durante fallo y recuperación.

• Objetivo: mantener pools por debajo de ~70–75% llenos en estado estable si valoras tus fines de semana.
• Por qué: la recuperación y el backfill necesitan espacio libre en los OSDs; clústeres casi llenos amplifican el dolor del rebalanceo y el riesgo.

Dimensionamiento de IOPS y latencia: la parte incómoda

Dimensionas Ceph entendiendo patrones de IO:

• Escrituras aleatorias pequeñas: castigan clústeres HDD y redes subdimensionadas.
• Escrituras sincrónicas (fsync): revelan journal/WAL y latencia del dispositivo; invitados ejecutando bases de datos pueden dominar el comportamiento del clúster.
• Lecturas: suelen ser más fáciles, pero lecturas en cache frío más recuperación aún pueden doler.

Si no puedes medir la carga, asume que es peor de lo que crees. Las cargas de producción siempre lo son.

Decisiones sobre pools, CRUSH y colocación de datos

Dimensionamiento de pools replicados: elige el fallo que quieres sobrevivir

La mayoría de despliegues Proxmox usan size=3, min_size=2. Eso generalmente sobrevive a la falla de un nodo sin ponerse solo-lectura.
Bajar a size=2 es tentador por la capacidad. También es una degradación de fiabilidad que a menudo se convierte en un outage sorpresa durante un segundo fallo.

Dominios de fallo: host, chasis, rack

Las reglas CRUSH deciden dónde van las réplicas. Si tu dominio de fallo es “host” pero tus tres nodos comparten la misma regleta,
tu dominio de fallo es en realidad “regleta”. Diseña la topología física como si lo tomaras en serio.

Conteo de PGs: no los ajustes a mano como si fuera 2016

El autoscaling de PG existe por una razón. Aun así, necesitas entender la presión de PGs:
pocos PGs pueden crear hotspots; demasiados pueden sobrecargar memoria y CPU de OSD.
Usa el autoscaler y luego verifica la distribución y el rendimiento.

Separa pools por clase de rendimiento, no por intuición

• Pool rápido: OSDs NVMe todo-flash para VMs sensibles a latencia.
• Pool de capacidad: HDD+SSD DB/WAL para almacenamiento en masa, cargas menos sensibles.
• No mezcles: poner una clase de OSD lenta en el mismo pool arrastra la IO cliente durante recuperación y peering de PG.

Tareas prácticas: comandos, salidas, qué significa y qué decides

Estos son los chequeos que hago cuando alguien dice “Ceph está lento” o “Ceph se comporta raro”.
Cada uno incluye: comando, salida de ejemplo, qué significa la salida y la decisión que tomas.

Tarea 1 — Confirmar salud del clúster y el titular real

cr0x@server:~$ ceph -s
  cluster:
    id:     2c8c8b9a-1c61-4a9f-9a19-4c0d7cfe2a91
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 23 sec, osd.7 has slow ops

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

  data:
    pools:   2 pools, 256 pgs
    objects: 1.12M objects, 4.3 TiB
    usage:   13 TiB used, 21 TiB / 34 TiB avail
    pgs:     254 active+clean
             2  active+remapped+backfilling

Significado: No es “todo está roto”. Es un OSD con operaciones lentas y un backfill en curso.

Decisión: Trata las quejas de rendimiento como esperables durante backfill; investiga por qué osd.7 está lento (disco, CPU, red).

Tarea 2 — Verificar si estás en modo recuperación/backfill

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 slow ops; 2 pgs backfilling
SLOW_OPS 1 slow ops, oldest one blocked for 23 sec, osd.7 has slow ops
PG_BACKFILLING 2 pgs backfilling

Significado: Hay actividad de recuperación; la latencia cliente puede dispararse.

Decisión: Decide si limitar temporalmente la recuperación o dejar que termine; verifica si el backfill es esperado (reinicio OSD reciente, reemplazo de disco).

Tarea 3 — Identificar qué OSD es el villano (o la víctima)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
  0                  6                 7
  1                  5                 6
  7                120               145
  8                  7                 8

Significado: osd.7 es mucho más lento que sus pares; no es “Ceph está lento”, es “un componente está lento”.

Decisión: Investigar salud del disco del host de osd.7, saturación o errores de red; considerar marcarlo fuera si está dañando el clúster.

Tarea 4 — Verificar el árbol OSD y asegurar que la topología coincide con la realidad

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         34.00000 root default
-3         11.33333     host pve1
 0    ssd   1.33333         osd.0      up   1.00000  1.00000
 1    ssd   1.33333         osd.1      up   1.00000  1.00000
 2    ssd   1.33333         osd.2      up   1.00000  1.00000
-5         11.33333     host pve2
 7    ssd   1.33333         osd.7      up   1.00000  1.00000
 8    ssd   1.33333         osd.8      up   1.00000  1.00000
 9    ssd   1.33333         osd.9      up   1.00000  1.00000

Significado: La clase y pesos de OSD parecen consistentes. Si ves pesos muy distintos, tendrás datos y IO desiguales.

Decisión: Si un host tiene menos OSDs/peso, espera hotspots; planifica expansión o reweighting.

Tarea 5 — Comprobar el estado del autoscaler de PG

cr0x@server:~$ ceph osd pool autoscale-status
POOL     SIZE  TARGET SIZE  RATE  RAW CAPACITY  RATIO  TARGET RATIO  PG_NUM  NEW PG_NUM  AUTOSCALE
rbd         3            -   3.0       34 TiB   0.65             -     128         192  on
cephfs      3            -   3.0       34 TiB   0.10             -     128          64  on

Significado: El autoscaler sugiere que rbd necesita más PGs (más paralelismo), mientras que cephfs podría necesitar menos.

Decisión: Acepta los cambios del autoscaler en periodos tranquilos; evita gran churn de PGs durante incidentes.

Tarea 6 — Revisar ajustes de pool que afectan la latencia de VM

cr0x@server:~$ ceph osd pool get rbd size
size: 3
cr0x@server:~$ ceph osd pool get rbd min_size
min_size: 2
cr0x@server:~$ rbd pool stats rbd
Total Images: 124
Total Snapshots: 37
Provisioned Size: 19.7 TiB
Total Used Size: 6.2 TiB

Significado: La replicación está configurada para HA típica. Provisioned vs used ayuda a detectar riesgo de sobreaprovisionamiento.

Decisión: Si lo provisionado se acerca a la capacidad usable, aplica cuotas o expande antes de que el backfill sea imposible.

Tarea 7 — Validar la salud de la red en las interfaces de Ceph

cr0x@server:~$ ip -s link show eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9123489123  8123492       0        3       0      0
    TX:  bytes  packets  errors  dropped  carrier  collsns
    8451239912  7923341       0        0        0      0

Significado: Errores cero; unas pocas drops pueden ser aceptables, pero drops crecientes bajo carga pueden indicar congestión o problemas de buffer.

Decisión: Si errores/drops suben, deja de culpar a Ceph y comienza a depurar puertos de switch, desajuste de MTU o saturación.

Tarea 8 — Confirmar consistencia de MTU (asesino silencioso)

cr0x@server:~$ ip link show eno2 | grep mtu
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000

Significado: La MTU de la interfaz es jumbo. Eso está bien solo si todo el camino lo soporta.

Decisión: Si algunos nodos tienen 1500 y otros 9000, elige uno y estandariza; MTU inconsistente produce latencia extraña y fragmentación.

Tarea 9 — Comprobar saturación de IO del host (¿está el disco al máximo?)

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   980.0  2400.0  8820.0   2.1   0.3   34.0
sdb              10.0   320.0   160.0  5120.0  48.0   2.5   98.0

Significado: sdb está cerca del 100% de utilización con await alto. Si ese es un dispositivo OSD, causará operaciones lentas.

Decisión: Si OSDs HDD están saturados, reduce tasa de recuperación, mueve workloads calientes a pool flash o añade spindles/nodos.

Tarea 10 — Inspeccionar un demonio OSD específico por stalls o errores de dispositivo

cr0x@server:~$ systemctl status ceph-osd@7 --no-pager
● ceph-osd@7.service - Ceph object storage daemon osd.7
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled)
     Active: active (running) since Sun 2025-12-28 08:12:11 UTC; 2h 3min ago
   Main PID: 23871 (ceph-osd)
      Tasks: 92
     Memory: 5.1G
        CPU: 1h 12min
     CGroup: /system.slice/system-ceph\x2dosd.slice/ceph-osd@7.service
             └─23871 /usr/bin/ceph-osd -f --cluster ceph --id 7 --setuser ceph --setgroup ceph

Significado: El OSD está corriendo; el uso de memoria es visible. Esto no prueba que esté sano, pero descarta “está caído”.

Decisión: Si el tiempo CPU es bajo pero la latencia alta, sospecha del disco o esperas de IO; revisa logs y estadísticas del dispositivo.

Tarea 11 — Buscar problemas de disco a nivel kernel

cr0x@server:~$ dmesg -T | tail -n 8
[Sun Dec 28 09:55:14 2025] blk_update_request: I/O error, dev sdb, sector 219902314
[Sun Dec 28 09:55:14 2025] Buffer I/O error on dev sdb, logical block 27487789, async page read
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] Sense Key : Medium Error [current]
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] Add. Sense: Unrecovered read error

Significado: El disco está fallando. Ceph intentará hacer frente, pero tu latencia será horrible y la recuperación puede thrash.

Decisión: Marca el OSD fuera, reemplaza el disco y planifica la ventana de recuperación; no “esperes a ver”.

Tarea 12 — Marcar con seguridad un OSD fuera cuando está dañando el clúster

cr0x@server:~$ ceph osd out 7
marked out osd.7.

Significado: Ceph empezará a mover datos fuera de osd.7 para restaurar el estado de replicación deseado.

Decisión: Monitorea el impacto del backfill. Si el clúster no puede manejar la recuperación sin derretirse, tu dimensionamiento es marginal.

Tarea 13 — Observar los throttles de recuperación/backfill y afinar con cuidado

cr0x@server:~$ ceph config get osd osd_max_backfills
1
cr0x@server:~$ ceph config get osd osd_recovery_max_active
3

Significado: Ajustes de recuperación conservadores reducen el impacto en clientes pero alargan el tiempo de reconstrucción.

Decisión: Durante horario laboral, mantén conservador. En ventanas de mantenimiento, aumenta ligeramente y vigila latencia.

Tarea 14 — Comprobar “nearfull” antes de que sea “full”

cr0x@server:~$ ceph df
--- RAW STORAGE ---
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
ssd    34 TiB   21 TiB   13 TiB     13 TiB     38.25
TOTAL  34 TiB   21 TiB   13 TiB     13 TiB     38.25

--- POOLS ---
POOL  ID  PGS  STORED  OBJECTS  USED     %USED  MAX AVAIL
rbd    1  128  4.1TiB  950k     12.3TiB  57.0     6.2TiB
cephfs 2  128  0.2TiB  170k     0.6TiB    2.8     6.2TiB

Significado: El uso raw parece bien, pero el %USED del pool es lo que importa para la capacidad efectiva de ese pool.

Decisión: Si rbd se acerca a 70–75%, programa expansión; no corras cerca del lleno y esperes recuperación indolora.

Tarea 15 — Verificar que Proxmox ve y usa el datastore Ceph correctamente

cr0x@server:~$ pvesm status
Name     Type     Status    Total     Used     Avail    %
local    dir      active   1.8T     220G     1.6T   12.0%
ceph-rbd rbd      active   6.2T     3.5T     2.7T   56.0%

Significado: El plugin de almacenamiento de Proxmox reporta capacidad y uso; desajustes pueden indicar problemas de auth/config.

Decisión: Si Proxmox muestra “unknown” o “inactive”, arregla la configuración cliente de Ceph antes de perseguir fantasmas de rendimiento.

Guion de diagnóstico rápido (encuentra el cuello de botella sin reuniones de una semana)

Este es el orden que ahorra tiempo. No siempre. Pero lo suficiente como para que deba ser memoria muscular.

Primero: ¿el clúster está sano o recuperándose?

• Ejecuta ceph -s y ceph health detail.
• Si ves backfill/recuperación/peering, acepta que el rendimiento está degradado y decide si limitar o esperar.
• Si ves slow ops, identifica los OSD(s) con ceph osd perf.

Segundo: ¿un host o disco está arrastrando a todos?

• En el host sospechoso: iostat -x para %util/await.
• Revisa logs kernel: dmesg -T para errores IO/tormentas de reset.
• Revisa SMART si está disponible (a menudo con herramientas del proveedor).
• Si un dispositivo falla, marca el OSD fuera y reemplázalo; no negocies con la física.

Tercero: ¿la red está mintiendo?

• Revisa contadores: ip -s link (errores/drops).
• Confirma MTU: ip link show.
• Busca congestión: picos durante backfill son normales; drops constantes no lo son.

Cuarto: ¿es un problema de configuración de pool/cliente?

• Confirma ajustes de replicación del pool y autoscaler de PG.
• Revisa si usaste pools EC para discos de VM (herida autoinfligida común).
• Valida la configuración de almacenamiento de Proxmox y que los clientes usen la red correcta.

Quinto: ¿simplemente está subdimensionado?

Si todos los componentes están “sanos” pero la latencia sigue mala bajo carga normal, tu clúster puede simplemente no tener suficientes
IOPS, CPU o red. Este es el momento de ser honesto: el tuning no convertirá HDD en NVMe.

Broma #2: Afinar un clúster Ceph subdimensionado es como reorganizar las sillas del barco—excepto que las sillas están en llamas y el barco es tu SLA.

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

1) “Todo se pone lento cuando un nodo cae”

Síntomas: picos de latencia, timeouts de VM, Proxmox se siente lento durante reemplazo de disco o reboot de host.

Causa raíz: recuperación/backfill satura la red u OSDs; clúster dimensionado solo para el camino feliz.

Solución: aumenta cuenta de nodos y ancho de banda de red; limita la recuperación en horas laborales; reserva headroom (mantente bajo ~75%).

2) “Lentitud aleatoria, sin errores obvios”

Síntomas: stalls ocasionales de 5–30s, HEALTH_WARN con slow ops, luego se limpia.

Causa raíz: un dispositivo OSD falla intermitentemente, problemas de firmware, o contención de IO a nivel host.

Solución: usa ceph osd perf para identificar ofensores; revisa dmesg; reemplaza discos inestables; deja de mezclar SSDs de consumo.

3) “Ceph está lleno, pero df dice que hay espacio”

Síntomas: el pool llega a nearfull/full, escrituras bloqueadas, a pesar de que la capacidad “raw” aún está disponible.

Causa raíz: la capacidad efectiva a nivel de pool está restringida por replicación y distribución; llenado desigual entre OSDs; sobreventa por thin provisioning.

Solución: expande antes de que los pools excedan umbrales seguros; rebalancea pesos; aplica cuotas y disciplina de aprovisionamiento.

4) “Grandes benchmarks de throughput, terrible experiencia VM”

Síntomas: pruebas secuenciales bien; cargas reales lentas; latencia p95 fea.

Causa raíz: los benchmarks no reflejan IO aleatorio pequeño + patrones fsync; HDD/híbrido sin DB/WAL en SSD adecuados; CPU hambrienta.

Solución: mide latencia; mueve discos de VM a pool todo-flash; asegura planificación de CPU para OSDs; no sobreasignes nodos de almacenamiento.

5) “Usamos erasure coding para discos de VM para ahorrar espacio”

Síntomas: mayor latencia de escritura, especialmente bajo carga; recuperación brutal; picos de CPU.

Causa raíz: amplificación de escrituras pequeñas en EC y coste computacional; no alineado con patrones IO de discos de VM.

Solución: usa pools replicados para discos de VM; reserva EC para objetos grandes y cargas menos sensibles a latencia.

6) “Ceph sigue flapeando quórum / MONs se quejan”

Síntomas: MONs fuera de quórum, pausas del clúster, errores extraños durante tráfico pico.

Causa raíz: nodos MON sobrecargados o subdimensionados, inestabilidad de red, o MONs corriendo en nodos hambrientos por carga de VM.

Solución: asegura tres MONs en nodos estables; reserva CPU/RAM; aisla la red; deja de poner MONs en el hypervisor más ocupado.

7) “El backfill nunca termina”

Síntomas: semanas de PGs remapeando/backfilling, estados degradados constantes tras pequeños cambios.

Causa raíz: muy poca capacidad libre, poco ancho de banda o cambios demasiado agresivos (añadir/quitar múltiples OSDs a la vez).

Solución: planifica cambios; añade capacidad en lotes pequeños; limita la recuperación; evita operar cerca del lleno; aumenta la red.

Tres mini-historias del mundo corporativo (anonimizadas, plausibles y dolorosamente familiares)

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

Una empresa mediana migró de un host de virtualización único con SSDs locales a un clúster Proxmox de tres nodos con Ceph.
La suposición fue simple: “Tenemos tres nodos, así que tenemos HA ahora. Será al menos tan rápido.”
Nadie dijo en voz alta “la replicación añade escrituras”. Nadie hizo pruebas de fallos con cargas reales.

El primer reboot de mantenimiento fue un martes por la mañana. Un nodo bajó para actualizaciones de firmware. Ceph hizo lo que Ceph hace:
empezó a backfill para mantener la replicación. La latencia de las VM subió, luego subió otra vez, y el helpdesk comenzó a reenviar tickets
con líneas de asunto escritas en mayúsculas.

Culparon a Proxmox, luego a Ceph, luego a la red. La verdad fue aburrida: 10GbE se compartía con tráfico de clientes,
y los OSDs eran SSD SATA que parecían bien en un contexto de nodo único pero se desmoronaron bajo escrituras aleatorias replicadas más recuperación.
La suposición equivocada no fue “Ceph es rápido”. Fue “Ceph se comporta como almacenamiento local, solo que compartido.”

La solución no fue una configuración mágica. Separaron el tráfico de almacenamiento, limitaron la recuperación en horario de oficina
y añadieron dos nodos más para reducir la presión de recuperación. La solución a largo plazo fue más incómoda:
dejaron de vender a stakeholders internos la idea de “HA es gratis”.

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

Otra organización tenía un clúster Ceph todo-flash que estaba “bien” pero sin emoción. Querían más eficiencia de capacidad.
Alguien propuso erasure coding para el datastore principal de VM. La hoja de cálculo era preciosa.
El plan de migración era limpio. El ticket de cambio tenía tono confiado. Peligro, en forma corporativa.

Al principio funcionó. La capacidad usable subió. Luego empezaron las quejas de rendimiento—sutiles al principio, luego persistentes.
Lo peor no fue la latencia promedio; fue la latencia cola. Las apps se quedaban bloqueadas brevemente, luego se recuperaban. Los usuarios lo describían como “pegajoso”.

Bajo el capó, las escrituras aleatorias pequeñas eran golpeadas por la amplificación EC y el coste adicional de cálculo.
Durante eventos de recuperación, la red y la CPU se disparaban de maneras que el equipo no había modelado. Cada incidente menor se transformaba en
un periodo prolongado de rendimiento degradado.

Revirtieron el datastore principal a pools replicados, mantuvieron EC para cargas menos interactivas,
y dejaron de “optimizar” sin un presupuesto de rendimiento alineado con la carga. La eficiencia de capacidad es genial—hasta que te cuesta credibilidad.

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

Un equipo de servicios financieros corría un clúster Proxmox+Ceph de cinco nodos. Nada exótico: pools replicados, 25GbE, NVMe consistentes,
ajustes de recuperación conservadores. Su arma secreta no era el equipo. Era el proceso.

Mantenían un hábito semanal pequeño: revisar la salud de Ceph, comprobar outliers de latencia de OSD y mirar tendencias de utilización de pools.
También imponían una regla: actualizaciones de firmware de almacenamiento y cambios de kernel ocurrían en ventanas controladas, un nodo a la vez,
y un checkpoint “para si la recuperación está enfadada”.

Una semana, notaron un único OSD escalando en latencia commit/apply. Sin errores aún. Solo “diferente”.
Lo marcaron fuera en una ventana tranquila, reemplazaron la unidad, dejaron que el clúster sane y siguieron. Dos días después,
una unidad del mismo modelo en otro entorno empezó a lanzar errores de lectura y causó un incidente visible para el cliente.

Su outage fue un non-event porque trataron “ligeramente raro” como tarea, no como curiosidad. La práctica fue aburrida.
El resultado fue de élite.

Listas de verificación / plan paso a paso

Lista de decisión: ¿deberías ejecutar Ceph en Proxmox?

• ¿Tienes al menos 3 nodos ahora (no “pronto”)? ¿Preferiblemente 5+?
• ¿Tienes 10GbE mínimo, idealmente 25GbE, con switching sensato?
• ¿Puedes mantener la utilización en estado estable por debajo de ~70–75%?
• ¿Tienes hardware consistente entre nodos?
• ¿Tienes una persona responsable de la salud del almacenamiento (alertas, mantenimiento, actualizaciones)?
• ¿Aceptas que la recuperación de fallos es un evento de rendimiento que debes presupuestar?

Lista de construcción: una base sensata para un clúster nuevo

1. Elige número de nodos y dominios de fallo. Decide si el fallo “host” es suficiente o necesitas separación a nivel de rack.
2. Escoge velocidad y topología de red. Separa el tráfico Ceph lógicamente (VLAN) y, si es posible, físicamente.
3. Elige clase de medios por pool. No mezcles HDD y NVMe en el mismo pool de rendimiento.
4. Configura pools replicados para discos de VM (size=3, min_size=2 es común). Sé explícito sobre por qué.
5. Activa el autoscaler de PG y revisa cambios sugeridos periódicamente.
6. Define alertas para: HEALTH_WARN/ERR, slow ops, nearfull/full, cambios de quórum MON, flaps de OSD, errores de disco.
7. Documenta el comportamiento de recuperación: qué es “degradado normal” y cuándo limitar.

Lista de operaciones: hábitos semanales que previenen drama

• Revisar ceph -s y ceph health detail.
• Comprobar ceph osd perf por outliers e investigar uno por semana.
• Revisar tendencias de capacidad con ceph df y uso de almacenamiento en Proxmox.
• Confirmar que no hay picos de errores/drops en NICs de almacenamiento.
• Hacer una actividad de mantenimiento controlada a la vez (un reboot de host, un reemplazo de OSD), luego observar.

Lista de expansión: añadir nodos/OSDs sin caos

1. Confirma que tienes margen para backfill (espacio y ancho de banda).
2. Añade en lotes pequeños para que la recuperación no aplaste la IO cliente.
3. Observa estados PG y perf de OSD mientras se rebalancea.
4. Tras la recuperación, valida utilización de pools y distribución de PG.
5. Sólo entonces procede al siguiente lote.

Preguntas frecuentes

1) ¿Cuál es el número mínimo de nodos para Ceph en Proxmox?

Tres nodos es el mínimo para un clúster real con quórum y almacenamiento replicado. Cinco nodos es donde el mantenimiento y la recuperación dejan de sentirse como un truco.

2) ¿Puedo ejecutar Ceph sobre 1GbE si mi carga es pequeña?

Puedes, pero probablemente no deberías. Incluso los clústeres pequeños tienen eventos de recuperación, y 1GbE convierte la recuperación en “todo está lento”.
Si debes hacerlo, mantén expectativas bajas y evita promesas de HA.

3) ¿Necesito redes separadas para tráfico público y de cluster?

No estrictamente, pero la separación (al menos por VLAN) reduce el radio de explosión y facilita la resolución de problemas. Si tienes puertos, dedica enlaces.

4) ¿Debería usar CephFS para discos de VM?

Para discos de VM en Proxmox, RBD suele ser la opción correcta. CephFS es excelente para cargas de archivos compartidos, no como reemplazo de la semántica de bloque.

5) Replicación size 2 vs 3: ¿es aceptable size 2?

Size 2 es aceptable solo cuando aceptas explícitamente la reducción de tolerancia a fallos y entiendes los escenarios de fallo.
En la mayoría de entornos empresariales, size 3 es el valor predeterminado más seguro porque tolera la realidad más desordenada.

6) ¿Debería usar erasure coding para ahorrar espacio?

Usa EC cuando la carga encaje: objetos grandes, menos sensibilidad a latencia y puedes pagar el overhead adicional de CPU/red.
Para datastores VM primarios, los pools replicados suelen ser el trade-off correcto.

7) ¿Qué tan lleno es “demasiado lleno” para Ceph?

Trata ~70–75% como el rango para “empieza a planear expansión” para pools replicados de VM.
Pasado eso, la recuperación se vuelve más lenta y arriesgada, y eventualmente golpearás límites de backfill.

8) ¿Por qué el rendimiento empeora durante reconstrucciones aunque el clúster esté sano?

Porque las reconstrucciones consumen los mismos recursos que necesitan tus clientes: IO de disco, CPU y red.
Un clúster sano puede seguir estando ocupado. Dimensionas y afinás para una degradación aceptable durante la recuperación, no para la perfección.

9) ¿Puedo mezclar modelos de SSD o generaciones de nodos diferentes?

Puedes, pero es una fuente común de latencia en cola y comportamiento desigual. En Ceph, la heterogeneidad aparece durante la recuperación y cargas de hotspot.
Si debes mezclar, aíslalo por clase de dispositivo y pool, y espera complejidad operativa.

10) ¿Cuál es la primera métrica a vigilar cuando “Ceph se siente lento”?

ceph osd perf para outliers de latencia commit/apply, además de si el clúster está backfilling. Un OSD lento puede envenenar toda la experiencia.

Próximos pasos que puedes ejecutar

1. Ejecuta el guion de diagnóstico rápido la próxima vez que alguien se queje. Captura ceph -s, ceph osd perf y iostat del host.
2. Decide tu presupuesto de fallos: ¿qué tan mal puede ponerse todo durante la recuperación y seguir siendo “aceptable”?
3. Arregla las piedras grandes primero: ancho de banda de red, medios consistentes y margen. El tuning viene después.
4. Separa pools por clase de rendimiento y deja de mezclar dispositivos lentos y rápidos en el mismo datastore de VM.
5. Institucionaliza comprobaciones aburridas: revisión semanal de salud, búsqueda de outliers, seguimiento de tendencias de capacidad y mantenimiento de un cambio a la vez.

Si Ceph en Proxmox se ajusta a tus necesidades y lo dimensionas honestamente, es una forma sólida de ejecutar virtualización resiliente sin comprar una religión del almacenamiento.
Si intentas engañar a la física, te responderá con gráficos de latencia que parecen arte moderno.