Proxmox Ceph HEALTH_WARN: cómo empezar a solucionar de forma segura

octubre 17, 2025 • febrero 3, 2026 • Lectura: 29 min • Views: 7

¿Te fue útil?

Mirás Proxmox, ves una banda amarilla y tu cerebro hace lo mismo que está haciendo el clúster: rellenar de ansiedad. El mensaje es “Ceph HEALTH_WARN”. Puede ser mera limpieza rutinaria. Puede ser la primera tos antes de una neumonía.

La trampa es reaccionar rápido en la dirección equivocada. Esta guía trata sobre movimientos seguros: las comprobaciones que no empeoran las cosas, los comandos que dicen la verdad y las decisiones que podrás justificar en un postmortem.

Qué significa realmente HEALTH_WARN (y qué no)

El estado de salud de Ceph tiene tres niveles: HEALTH_OK, HEALTH_WARN, HEALTH_ERR. HEALTH_WARN es el clúster diciéndote: “Algo no es ideal, pero sigo funcionando”.

Eso no significa “ignóralo”. Tampoco significa “entres en pánico y empieces a reiniciar demonios”. HEALTH_WARN es un contenedor. El contenido significativo está en la lista de advertencias debajo: nearfull, OSD down, PGs degraded, slow ops, clock skew, problemas de quorum de mon, errores de scrub y una docena de otras formas en que el almacenamiento pide ayuda con educación.

Dos principios guía:

Ceph es una máquina de estado distribuida. La mayoría de las “soluciones” consisten en dejar que converja (o ayudarla a converger de forma segura).
Tus primeros movimientos más seguros son de solo lectura. Observá, medí y luego cambiá.

Interpretación operativa útil:

HEALTH_WARN con I/O estable y sin riesgo de disponibilidad de datos: programá mantenimiento, reducí riesgo, no hagas cambios drásticos.
HEALTH_WARN con impacto en clientes (latencia, timeouts, VMs atascadas): tratálo como un incidente e identificá el cuello de botella rápido.
HEALTH_WARN con PGs “misplaced”, “degraded” o “undersized”: estás a una falla más de tener un mal día. Priorizá la recuperación de redundancia.

Verdad seca: Ceph es como un trabajo en grupo—si no comprobás qué hace cada uno, vas a estar depurando “problemas de comunicación” a las 2 a.m.

Guion rápido de diagnóstico (primero/segundo/tercero)

Primero: confirmá qué está realmente mal (un comando, una pantalla)

Tu primera tarea es traducir “amarillo” en uno o dos modos de falla específicos.

cr0x@server:~$ ceph -s
  cluster:
    id:     7c2f0b7c-9c55-4e2e-8b3f-8c3c7c1d8a2a
    health: HEALTH_WARN
            1 osds down
            2 nearfull osd(s)
            36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops.

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

  data:
    pools:   2 pools, 256 pgs
    objects: 2.1M objects, 8.2 TiB
    usage:   24 TiB used, 36 TiB / 60 TiB avail
    pgs:     240 active+clean
             12  active+undersized+degraded

Significado: Esto no es un único problema; es un clúster bajo presión. Un OSD está caído, un par están nearfull (lo que estrangula), y hay slow ops (dolor visible para clientes). Los PGs están undersized/degraded (riesgo).

Decisión: Tratálo como incidente. Enfocate primero en el riesgo de disponibilidad (OSD down → PGs degradados), luego en el rendimiento (slow ops), mientras comenzás de inmediato con un plan para mitigar nearfull.

Segundo: determiná si el problema es “plano de control” o “plano de datos”

Problemas del plano de control: quorum de mon inestable, mgr muerto, desviación de tiempo. Problemas del plano de datos: OSDs caídos, errores de disco, pérdida de red, slow ops, tormentas de backfill.

Si el quorum de mon es inestable, no empieces a “reparar” PGs. Arreglá el quorum primero.
Si OSDs están caídos, no persigas ajustes de rendimiento. Restaurá OSDs y redundancia.
Si todos los demonios están arriba pero persisten slow ops, investigá latencia de red/disco y ajustes de recuperación.

Tercero: identificá el tipo de cuello de botella en 10 minutos

La mayoría de incidentes reales de HEALTH_WARN se reducen a uno de estos:

Presión de capacidad (nearfull/full, backfill bloqueado, escrituras limitadas).
Falla de un solo nodo (OSD down, host reiniciado, disco muerto, resets de HBA).
Dolor de red (pérdida de paquetes, MTU incorrecto, switch congestionado, enrutamiento asimétrico).
Tormenta de recuperación (backfill/rebalance compitiendo con I/O cliente).
Almacenamiento lento (un dispositivo OSD arrastrando a todos).
Problemas de tiempo/reloj (advertencias de mon_clock_skew, rarezas de autenticación, flaps extraños).

Reglas de seguridad: qué evitar cuando el clúster está amarillo

Ceph premia la calma. Castiga la improvisación.

1) No reinicies demonios “para borrar la advertencia”

Reiniciar mons/mgrs/osds cambia el estado, dispara peering, puede reiniciar recuperación y puede hacerte perder lo único que tenías: un clúster estable que se estaba curando lentamente. Reiniciá solo cuando sepas qué estás arreglando (proceso bloqueado, ciclo de reinicio confirmado, reset de kernel, etc.).

2) No marques OSDs como out a menos que lo decidas con intención

ceph osd out desencadena movimiento de datos. En un clúster ocupado eso puede convertir “un OSD caído” en “todo el clúster lento durante horas”. Si el OSD está caído por un problema transitorio del host, recupéralo antes de declararlo out.

3) No “arregles nearfull” cambiando los ratios de full a mitad del incidente

Sí, podés elevar mon_osd_nearfull_ratio y similares. Eso no es capacidad. Es negación con pasos extra. Si debés ajustar ratios para desbloquear escrituras de emergencia, tratálo como una excepción temporal con plan de rollback.

4) No ejecutes comandos agresivos de reparación a ciegas

ceph pg repair y herramientas a nivel OSD pueden ser correctas, pero no son una respuesta primaria. Demostrá que tenés errores de scrub o PGs inconsistentes y confirmá que el quorum y la red son estables antes.

5) No optimices la recuperación mientras todavía estás diagnosticando

Modificar osd_max_backfills o osd_recovery_max_active puede ayudar—pero también podés dejar sin I/O a clientes o sobrecargar un nodo débil. Diagnosticá primero, ajustá después.

Broma #1: Si estás a punto de “simplemente reiniciar el nodo Ceph”, recordá: el clúster tiene sentimientos, y los expresa en tráfico de backfill.

Datos interesantes y contexto (Ceph y Proxmox)

Ceph nació en UC Santa Cruz como proyecto de investigación a mediados de los 2000, con la meta de almacenamiento autogestionado a escala. Ese ADN aún se nota: quiere sanarse solo, a veces ruidosamente.
CRUSH no es un sistema de archivos; es el algoritmo de colocación que decide dónde van los datos sin una tabla de búsqueda centralizada, por eso Ceph escala sin un cuello de botella único de metadatos para la colocación de objetos.
Los PGs (placement groups) son cubos virtuales usados para gestionar replicación y recuperación. No son “particiones” ni “volúmenes”, pero controlan el radio de impacto de la recuperación.
HEALTH_WARN suele ser una señal de capacidad, no siempre de fallo. Muchos clústeres funcionan “bien” hasta que llegan a nearfull, y entonces el rendimiento se desploma porque Ceph se protege a sí mismo.
El modelo de scrub de Ceph es medicina preventiva: los scrubs ligeros y profundos cambian I/O en segundo plano por detección temprana de corrupción. Desactivar scrub es como quitar detectores de humo porque no te gusta el pitido.
BlueStore reemplazó a FileStore como backend por defecto hace años, principalmente para reducir la complejidad del journal y mejorar el rendimiento, especialmente en SSD/NVMe.
Red pública y red de clúster son conceptos separados en el diseño de Ceph: mezclar tráfico cliente y replicación/backfill en la misma red saturada es una clásica historia de “en pruebas iba bien”.
Proxmox integra Ceph estrechamente (herramientas pveceph, paneles de salud en la UI), pero no cambia el comportamiento fundamental de Ceph: seguís solucionando con herramientas de Ceph, no con buenas vibras del GUI.
Las advertencias de desajuste de reloj existen por una razón: los monitores de Ceph dependen de timeouts y lógica de quorum; la deriva de tiempo puede parecer fallos y causar flapping.

Una cita para pegar en un post-it, porque así deberías abordar la depuración de sistemas distribuidos: “La esperanza no es una estrategia.” — General Gordon R. Sullivan.

Tareas prácticas: comandos, significado, decisión

Estas están ordenadas más o menos de lo más seguro/generales a lo más dirigido. Úsalas como una lista de verificación: ejecutá, interpretá, decidí. Si solo hacés una cosa de este artículo, hacé la parte de “significado + decisión” cada vez. Eso te evita caminar al azar hacia downtime.

Tarea 1: Capturar los detalles de salud del clúster

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 osds down; 2 nearfull osd(s); 36 slow ops
[WRN] OSD_DOWN: 1 osds down
    osd.7 down since 2025-12-26T09:01:33.123+0000, last_up 2025-12-26T08:42:10.991+0000
[WRN] OSD_NEARFULL: 2 nearfull osd(s)
    osd.3 is near full at 84%
    osd.9 is near full at 85%
[WRN] SLOW_OPS: 36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops

Significado: Esta es la lista procesable. Te dice qué cree Ceph que está mal, con IDs y marcas temporales.

Decisión: Abrí una nota de incidente. Copiá y pegá esta salida. La necesitarás para saber si las cosas mejoran tras los cambios.

Tarea 2: Verificar quorum de mon y estabilidad básica del plano de control

cr0x@server:~$ ceph quorum_status --format json-pretty
{
  "election_epoch": 42,
  "quorum": [0,1,2],
  "quorum_names": ["pve1","pve2","pve3"],
  "quorum_leader_name": "pve1",
  "monmap": {
    "mons": [
      {"rank":0,"name":"pve1","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.11:3300"},{"type":"v1","addr":"10.10.0.11:6789"}]}},
      {"rank":1,"name":"pve2","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.12:3300"},{"type":"v1","addr":"10.10.0.12:6789"}]}},
      {"rank":2,"name":"pve3","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.13:3300"},{"type":"v1","addr":"10.10.0.13:6789"}]}}
    ]
  }
}

Significado: El quorum está sano cuando es estable y contiene la mayoría de mons. Si falta un mon en el quorum o oscila, todo lo demás se vuelve ambiguo.

Decisión: Si el quorum es inestable: detené y arreglá red/tiempo/salud del host de mon primero. No toques el estado de OSD ni la reparación hasta que el quorum sea aburrido otra vez.

Tarea 3: Confirmar que el manager está activo y no bloqueado

cr0x@server:~$ ceph mgr stat
{
  "active_name": "pve1",
  "num_standbys": 1
}

Significado: El MGR provee dashboards y algo de lógica de orquestación (dependiendo de módulos). Si está caído, perdés visibilidad y algo de automatización.

Decisión: Si no hay un mgr activo: restauralo, pero no supongas que problemas de mgr causan I/O. Generalmente es observabilidad, no ruta de datos.

Tarea 4: Identificar qué PGs están poco saludables y por qué

cr0x@server:~$ ceph pg stat
256 pgs: 240 active+clean, 12 active+undersized+degraded, 4 active+peering
data: 8.2 TiB objects, 24 TiB used, 36 TiB / 60 TiB avail
io: 120 MiB/s rd, 45 MiB/s wr, 410 op/s rd, 190 op/s wr

Significado: undersized+degraded significa que no se cumplen los requisitos de replicación. peering significa que los PGs están negociando quién posee qué; puede ser normal brevemente, o signo de un problema más profundo si persiste.

Decisión: Si degraded/undersized persiste más de unos minutos, encontrá los OSDs faltantes y restauralos. Si el peering persiste, sospechá partición de red o flaps de OSD.

Tarea 5: Encontrar rápidamente el OSD caído y su host

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         5.45600  root default
-3         1.81900      host pve1
 0    hdd  0.45500          osd.0      up   1.00000  1.00000
 3    hdd  0.45500          osd.3      up   1.00000  1.00000
 7    hdd  0.45500          osd.7    down   1.00000  1.00000
-5         1.81900      host pve2
 1    hdd  0.45500          osd.1      up   1.00000  1.00000
 4    hdd  0.45500          osd.4      up   1.00000  1.00000
 9    hdd  0.45500          osd.9      up   1.00000  1.00000
-7         1.81800      host pve3
 2    hdd  0.45500          osd.2      up   1.00000  1.00000
 5    hdd  0.45500          osd.5      up   1.00000  1.00000
12    hdd  0.45500          osd.12     up   1.00000  1.00000

Significado: Esto te da el radio físico de impacto: qué nodo contiene el OSD caído.

Decisión: Si es un problema a nivel host (varios OSDs caídos en un mismo host), tratalo como un incidente del nodo (alimentación, kernel, NIC, HBA). Si es un único OSD, probablemente sea problema del disco o del camino HBA.

Tarea 6: Verificar si el OSD caído está realmente “down” o solo “out”/detenido

cr0x@server:~$ ceph osd dump | grep -E '^osd\.7|^epoch'
epoch 12872
osd.7 up 0 in 1 weight 0.455 last_clean_begin 2025-12-26T08:40:15.000000+0000 last_clean_end 2025-12-26T08:40:15.000000+0000

Significado: El OSD está marcado up 0 (down) pero aún in 1. Ceph espera que sea parte del clúster, pero no está respondiendo.

Decisión: Preferí restaurar el demonio/camino de disco para que vuelva a estar up. Evitá marcarlo out a menos que esperes una interrupción prolongada o reemplazo de hardware.

Tarea 7: En el host afectado, revisá el servicio OSD y los logs recientes

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: failed (Result: exit-code) since Fri 2025-12-26 09:02:01 UTC; 3min ago
    Process: 19444 ExecStart=/usr/bin/ceph-osd -f --cluster ceph --id 7 --setuser ceph --setgroup ceph (code=exited, status=1/FAILURE)
   Main PID: 19444 (code=exited, status=1/FAILURE)

cr0x@server:~$ journalctl -u ceph-osd@7 -n 80 --no-pager
Dec 26 09:01:58 pve1 ceph-osd[19444]: bluestore(/var/lib/ceph/osd/ceph-7) _mount failed: (5) Input/output error
Dec 26 09:01:58 pve1 ceph-osd[19444]: failed to mount object store
Dec 26 09:02:01 pve1 systemd[1]: ceph-osd@7.service: Main process exited, code=exited, status=1/FAILURE

Significado: Esto no es un problema de “lógica” de Ceph; es un error de E/S montando BlueStore. Pensá en disco, controlador, cableado o kernel.

Decisión: Dejá de adivinar y revisá hardware y logs del kernel a continuación. Si el disco está fallando, planificá un flujo de trabajo de reemplazo de OSD en lugar de reinicios repetidos.

Tarea 8: Revisar mensajes del kernel por resets/timeouts del disco en ese nodo

cr0x@server:~$ dmesg -T | tail -n 40
[Fri Dec 26 09:01:41 2025] sd 6:0:2:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Fri Dec 26 09:01:41 2025] blk_update_request: I/O error, dev sdc, sector 918274048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 09:01:43 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Fri Dec 26 09:01:43 2025] ata7.00: failed command: READ DMA
[Fri Dec 26 09:01:44 2025] ata7: hard resetting link

Significado: El kernel está detectando errores reales de E/S/resets. Ceph no puede vencer a la física.

Decisión: Reemplazá el disco o arreglá el camino (HBA, cable, backplane). Si no podés hacerlo de inmediato, marcá el OSD como out y comenzá la recuperación controlada (después de evaluar la capacidad del clúster y el margen de rendimiento).

Tarea 9: Identificar ofensores de “slow ops” y si es un OSD o muchos

cr0x@server:~$ ceph health detail | sed -n '/SLOW_OPS/,$p'
[WRN] SLOW_OPS: 36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops

cr0x@server:~$ ceph daemon osd.12 dump_historic_ops | head -n 25
{
  "ops": [
    {
      "description": "osd_op(client.48219:9123 3.2f3a 3:1f9d9b4f:::rbd_data.1a2b...:head [write 0~4194304] ...)",
      "duration": 92.334,
      "initiated_at": "2025-12-26T09:00:11.112233Z",
      "type_data": { "op_type": "write" }
    }
  ]
}

Significado: Ceph te indica qué demonio está bloqueando operaciones. Si es un OSD consistentemente, sospechá ese disco o su host (latencia, saturación de cola, NIC).

Decisión: Si un OSD es el punto caliente, inspeccioná sus métricas a nivel de disco y nodo. Si los slow ops se extienden por muchos OSDs, sospechá congestión de red o tormenta de recuperación.

Tarea 10: Verificar presión de recovery/backfill (el asesino silencioso del rendimiento)

cr0x@server:~$ ceph -s | sed -n '/recovery/,$p'
  progress:
    Global Recovery Event (1m)
      [==========..........] (remaining: 2m)
      recovering, 1.2 GiB/s, 18 objects/s

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    5                   8
1    6                   9
2    5                   8
3    7                   11
4    6                   9
5    5                   8
9    8                   14
12   60                  95

Significado: Está ocurriendo recuperación y un OSD (12) tiene latencias muy superiores. Ese OSD puede convertirse en ancla que arrastra tanto la recuperación como el I/O de clientes.

Decisión: Si la recuperación compite con I/O de producción, limitá la recuperación con cuidado. Si un OSD está enfermo, arreglalo o aislalo antes de aumentar la velocidad de recuperación.

Tarea 11: Confirmar que nearfull es real y encontrar los OSDs culpables

cr0x@server:~$ ceph df detail | head -n 40
RAW STORAGE:
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
hdd    60 TiB   36 TiB   24 TiB     24 TiB      40.0
POOLS:
POOL     ID  PGS  STORED  OBJECTS  USED     %USED  MAX AVAIL
rbd      1   224  7.8 TiB 2.0M     23 TiB   62.5   11 TiB
cephfs   2   32   0.4 TiB 0.1M     1.1 TiB  18.0   11 TiB

cr0x@server:~$ ceph osd df | sort -k8 -n | tail -n 6
ID CLASS WEIGHT  REWEIGHT SIZE   RAW USE DATA   OMAP META AVAIL %USE VAR  PGS STATUS
3  hdd   0.45500 1.00000  5.5T   4.6T    4.5T   0B  4.0G 0.9T 84.1 1.20 24  up
9  hdd   0.45500 1.00000  5.5T   4.7T    4.6T   0B  4.1G 0.8T 85.2 1.21 26  up

Significado: Nearfull es por OSD, no promedio del clúster. Dos OSDs están calientes, probablemente por desequilibrio CRUSH, desajuste de tamaños de dispositivo o un pasado movimiento out/in que dejó la colocación desigual.

Decisión: Si unos pocos OSDs están nearfull, no agregues capacidad “en cualquier lado”. Arreglá el desequilibrio (reweight/balancer), reemplazá discos pequeños o redistribuí con cuidado. Planificá también cabeza de espacio inmediata: eliminar/mover datos si estás cerca del full.

Tarea 12: Verificar si el balancer está habilitado y si ayuda o perjudica

cr0x@server:~$ ceph balancer status
{
  "active": true,
  "mode": "upmap",
  "optimize_result": "no_optimization_needed",
  "last_optimize_duration": "0.000000s"
}

Significado: El modo upmap puede suavizar la distribución sin un movimiento masivo de datos, pero aun así cambia mapeos. Si está deshabilitado, podés tener desequilibrio a largo plazo. Si está habilitado pero atascado, puede haber restricciones (nearfull, reglas CRUSH mal configuradas).

Decisión: Si nearfull está localizado y el balancer no progresa, investigá CRUSH, clases de dispositivo y pesos de OSD. Evitá forzar un rebalance agresivo durante carga pico.

Tarea 13: Verificar sincronización de tiempo y buscar advertencias de desajuste de reloj

cr0x@server:~$ ceph health detail | grep -i skew
[WRN] MON_CLOCK_SKEW: clock skew detected on mon.pve2, mon.pve3

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 09:06:17 UTC
           Universal time: Fri 2025-12-26 09:06:17 UTC
                 RTC time: Fri 2025-12-26 09:06:16
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: Las advertencias de clock skew pueden ser causadas por deriva real, VMs pausadas o nodos sobrecargados que retrasan NTP. En la práctica, suele ser “el nodo está demasiado ocupado para mantener bien el tiempo”.

Decisión: Si NTP no está sincronizado, arreglá el tiempo primero. Si NTP está bien pero persiste el desajuste, investigá saturación de CPU o pausas de VM en hosts de mon.

Tarea 14: Revisar errores de red y paquetes descartados en las interfaces Ceph

cr0x@server:~$ ip -s link show dev eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9123491234  12349123   0     412     0     10123
    TX:  bytes packets errors dropped carrier collsns
    8234123412  11234123   0      95      0     0     0

Significado: Los descartes en la red de almacenamiento se correlacionan fuertemente con slow ops, retrasos de peering y flaps de OSD. Desajustes de MTU pueden parecer pérdida aleatoria.

Decisión: Si los descartes/errores son no nulos y están aumentando, tratá la red como sospechosa. Confirmá MTU extremo a extremo y revisá puertos de switch. No ajustes la recuperación de Ceph para “arreglar” un problema de pérdida de paquetes.

Tarea 15: Verificar banderas de clúster que puedan bloquear la recuperación

cr0x@server:~$ ceph osd dump | grep flags
flags noout,noscrub,nodeep-scrub

Significado: Banderas como noout pueden ser intencionales durante mantenimiento, pero también pueden mantener el clúster degradado más tiempo del esperado. noscrub puede ocultar señales de corrupción.

Decisión: Si las banderas se pusieron para mantenimiento y se olvidaron, quitálas deliberadamente cuando sea seguro. Si estás en un incidente, no elimines banderas sin entender por qué se pusieron.

Tarea 16: Inspeccionar un PG específico que esté atascado o degradado

cr0x@server:~$ ceph pg dump_stuck inactive | head
PG_STAT STATE             UP            UP_PRIMARY  ACTING        ACTING_PRIMARY
1.2a     inactive         [7,3,12]      7           [7,3,12]      7

cr0x@server:~$ ceph pg 1.2a query | head -n 35
{
  "state": "active+undersized+degraded",
  "up": [7,3,12],
  "acting": [7,3,12],
  "info": {
    "stats": {
      "state": "active+undersized+degraded"
    }
  },
  "recovery_state": [
    {
      "name": "Started/Primary/Active",
      "enter_time": "2025-12-26T09:01:40.000000Z"
    }
  ]
}

Significado: El conjunto acting del PG incluye al OSD 7, que está caído. Esa es la razón por la cual el PG no puede cumplir size/min_size.

Decisión: Arreglá el OSD 7 o reemplazalo. No pierdas tiempo en reparar PGs cuando la réplica faltante es la causa real.

Tarea 17: Si debés limitar la recuperación, hacelo con intención (y revertí luego)

cr0x@server:~$ ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1'
injected data to osd.0
injected data to osd.1
injected data to osd.2
injected data to osd.3
injected data to osd.4
injected data to osd.5
injected data to osd.9
injected data to osd.12

Significado: Reduciste la concurrencia de recuperación en todos los OSDs. Esto puede estabilizar la latencia de clientes a costa de una curación más lenta.

Decisión: Usalo solo cuando el impacto al cliente sea severo y necesites que el clúster responda. Creá un recordatorio para revertir cuando termine el incidente, o serás “misteriosamente lento para recuperar” para siempre.

Tarea 18: Verificar que la replicación/min_size del pool no esté auto-saboteándose

cr0x@server:~$ ceph osd pool ls detail | sed -n '1,80p'
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 224 pgp_num 224 autoscale_mode on
pool 2 'cephfs' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on

Significado: Size 3 / min_size 2 es típico. Si min_size es 3, un único OSD caído puede bloquear escrituras. Si size es 2 en un clúster pequeño, tu tolerancia a fallas es más baja de lo que creés.

Decisión: Si las escrituras están bloqueadas porque min_size es demasiado estricto para tu apetito de riesgo, ajustalo durante un cambio planificado, no en medio del caos—a menos que el impacto al negocio lo exija y quede documentado.

Tres micro-historias corporativas desde el terreno

1) Incidente causado por una suposición errónea: “Amarillo significa seguro”

Una empresa SaaS mediana corría Proxmox con Ceph para almacenamiento de VMs. Habían visto HEALTH_WARN muchas veces—normalmente una advertencia de scrub, un OSD nearfull que se iba tras limpieza rutinaria o un flap transitorio de OSD durante actualizaciones de kernel. La costumbre del on-call era mirar ceph -s, encogerse de hombros y seguir, a menos que la UI se pusiera roja.

Un viernes, HEALTH_WARN reportó un OSD caído y un puñado de PGs degradados. La suposición fue “la replicación lo cubrirá”. Eso no es erróneo en principio; es erróneo en el momento. El clúster ya estaba al límite: alta carga de escritura, recuperación limitada demasiado conservadoramente por un incidente anterior y un nodo con discos ligeramente peores que los demás.

Durante el fin de semana, un segundo disco en el mismo host empezó a lanzar picos de latencia. El OSD no llegó a caerse del todo, solo se volvió lo suficientemente lento como para disparar slow ops. Los clientes empezaron a hacer timeouts. El almacenamiento estaba técnicamente disponible, pero el rendimiento se convirtió en la interrupción. El negocio lo percibió como “la plataforma está caída” porque las VMs que no pueden escribir son VMs que no viven.

El postmortem tuvo una frase que importó: trataron la pérdida de redundancia como algo cosmético. Los PGs degradados no son una marca de belleza; son un reloj de cuenta regresiva que avanza más rápido cuando ya estás estresado.

Lo que lo arregló no fueron heroísmos. Restauraron el OSD caído, reemplazaron el disco defectuoso y—lo más importante—agregaron una regla: PGs degraded/undersized disparan un incidente sin importar el color. El color de la UI no es tu modelo de riesgo.

2) Optimización que salió mal: “Aceleremos la recuperación”

Otra organización tenía reinicios frecuentes de nodos por actualizaciones de firmware. Se fastidiaron con los largos tiempos de recuperación y decidieron “tunear Ceph”. Alguien aumentó osd_max_backfills y osd_recovery_max_active en todo el clúster para hacer backfill más rápido.

Funcionó—en un clúster de staging vacío. En producción, el mismo cambio convirtió cada reinicio en un brownout. La recuperación compitió con escrituras/lecturas de clientes, saturando discos y la red de almacenamiento. Los picos de latencia dispararon más slow ops. Los slow ops generaron timeouts. Los timeouts provocaron reintentos de la aplicación. Los reintentos amplificaron la carga. Todo se transformó en un DDoS autoinfligido, pero con más YAML.

Lo realmente doloroso: los ingenieros interpretaron los síntomas como “Ceph es inestable después de reinicios”, así que reiniciaron nodos otra vez para “resetearlo”, reiniciando la recuperación cada vez. Así es como convertís un ajuste en un generador de incidentes.

La solución fue ligar el tuning de recuperación al horario y la latencia observada. Crearon dos perfiles: conservador en horario laboral, agresivo por la noche. También aprendieron a mirar ceph osd perf y descartes de red antes de cambiar nada. La velocidad de recuperación no es comida gratis; es un intercambio con tus usuarios.

3) Práctica aburrida pero correcta que salvó el día: “Noout durante mantenimiento, y luego quitarlo”

Una empresa regulada (mucho proceso, mucho papeleo, muchas opiniones) programó una ventana de mantenimiento para reemplazar un disco fallando en un nodo Ceph. Hicieron la danza aburrida: pusieron noout antes de bajar el host, registraron la hora de inicio y asignaron a una persona responsable de quitar la bandera al final.

Durante la ventana, otro nodo experimentó un breve problema de red y perdió un OSD. En muchos entornos, aquí es donde el clúster comienza a reordenar datos y el mantenimiento se vuelve un festival nocturno de backfill. Pero con noout puesto, Ceph no decidió inmediatamente que el OSD temporalmente ausente se había ido para siempre, así que no inició el pesado movimiento de datos mientras ya estaban operando con capacidad reducida.

Restauraron la red, trajeron el nodo de mantenimiento y luego quitaron deliberadamente noout. El clúster sanó con mínimo drama. El negocio no lo notó.

Esto no fue ingeniería ingeniosa. Fue higiene operativa: saber qué banderas existen, cuándo usarlas y—crucialmente—cómo salir del mantenimiento de forma limpia. La mejor herramienta del equipo ese día fue una lista de verificación.

Broma #2: Mantenimiento de Ceph sin checklist es como hot-swappear un disco con los ojos cerrados—técnicamente posible, emocionalmente caro.

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

1) Síntoma: “HEALTH_WARN nearfull” y el rendimiento se pone extraño

Causa raíz: Uno o unos pocos OSDs están nearfull, provocando que Ceph limite/retroceda, y la recuperación puede estar bloqueada o ralentizada por restricciones de ratio full.

Solución: Identificá los OSDs con mayor %use (ceph osd df). Reducí crecimiento de datos inmediatamente (eliminá/mové snapshots/VMs), agregá capacidad y corregí el desequilibrio (balancer/pesos CRUSH). Evitá hacks de ratio salvo para una ventana de escritura de emergencia temporal.

2) Síntoma: “1 osds down” pero lo marcás out inmediatamente y el clúster se vuelve lento

Causa raíz: Marcar out disparó un rebalance grande en discos/red ya ocupados.

Solución: Si el OSD puede volver rápido, reintegralo en lugar de marcarlo out. Si debés marcarlo out, limitá la recuperación y programá el movimiento cuando la carga cliente sea baja.

3) Síntoma: PGs atascados en “peering” por mucho tiempo

Causa raíz: Flapping de OSD, pérdida de paquetes de red o una partición que causa intercambio inconsistente de estado.

Solución: Revisá historial up/down de OSD, descartes de red, consistencia de MTU y logs de switch. Estabilizá la red primero. Reiniciar OSDs al azar a menudo extiende el peering.

4) Síntoma: Slow ops pegadas a un OSD

Causa raíz: El disco de ese OSD es lento, su host está sobrecargado o está viendo resets a nivel de kernel.

Solución: Usá ceph osd perf para confirmar, luego inspeccioná dmesg y logs de servicio en el host. Reemplazá el dispositivo o arreglá el camino. No “tunées Ceph” para compensar un disco que está muriendo.

5) Síntoma: Slow ops en muchos OSDs, especialmente durante recuperación

Causa raíz: Recuperación/backfill está saturando red o discos. O la red de almacenamiento es con pérdida/congestionada.

Solución: Revisá progreso de recuperación, perf de OSD y descartes de NIC. Limitá recuperación temporalmente si el impacto al cliente es inaceptable. Arreglá la red si ves pérdida.

6) Síntoma: “MON_CLOCK_SKEW” aparece intermitentemente

Causa raíz: Sincronización de tiempo mala o inestable, o hosts sobrecargados que retrasan la gestión del tiempo.

Solución: Asegurá que NTP/chrony esté activo y sincronizado. Investigá CPU steal, carga y pausas de VM en hosts de mon. Las advertencias de tiempo no son cosméticas; se correlacionan con rarezas de quorum.

7) Síntoma: Errores de scrub o advertencias de “inconsistent PG”

Causa raíz: Inconsistencia de datos detectada durante scrub, a menudo por errores de disco pasados, bit rot o eventos de recuperación interrumpidos.

Solución: Confirmá qué PGs son inconsistentes, asegurá la estabilidad del clúster y luego ejecutá reparaciones dirigidas con precaución. También investigá el hardware subyacente por errores silenciosos. Si es generalizado, tratá la calidad de la flota de hardware como el verdadero incidente.

8) Síntoma: Todo parece “up” pero las escrituras están bloqueadas

Causa raíz: min_size del pool demasiado estricto para las fallas actuales, o el clúster está alcanzando umbrales de full, o algunos PGs están atascados undersized.

Solución: Verificá configuraciones de pool, ratios de full, restaurá OSDs faltantes. Ajustá min_size solo como decisión consciente de riesgo, documentada y preferiblemente planificada.

Listas de verificación / plan paso a paso

Checklist A: Primeros 5 minutos (sin riesgo, solo lectura)

Ejecutá ceph -s y ceph health detail. Pegá las salidas en tu registro de incidente.
Confirmá quorum: ceph quorum_status. Si es inestable, detenete y arreglá eso primero.
Mirá el estado de PG: ceph pg stat. Identificá contadores degraded/undersized/peering.
Encontrá OSDs claramente caídos: ceph osd tree.
Comprobá si nearfull es por OSD: ceph osd df.

Checklist B: Siguientes 15 minutos (localizar cuello de botella)

Si algún OSD está caído, mapealo a un host y revisá systemctl status + journalctl para ese OSD.
Ejecutá ceph osd perf. Encontrá outliers.
Si hay slow ops, identificá qué demonios: ceph health detail y usá ceph daemon osd.X dump_historic_ops selectivamente.
Revisá descartes de red en interfaces Ceph: ip -s link. Si los descartes aumentan, tratá la red como sospechosa.
Buscá banderas olvidadas: ceph osd dump | grep flags.

Checklist C: Escalera de intervención segura (cambiar lo menos posible)

Restaurá lo que falta: volvé a poner OSDs en marcha si el hardware lo permite; arreglá problemas del host.
Reducí el dolor del cliente: si la recuperación está aplastando la latencia, limitala temporalmente (y documentá el cambio exacto).
Restaurá redundancia: si el hardware está muerto, marcá OSD out y comenzá el reemplazo—solo después de confirmar que tenés margen de capacidad y seguridad del dominio de fallas.
Atendé la capacidad: priorizá mitigación de nearfull antes de que llegue a full; agregá espacio, rebalanceá con cuidado, eliminá datos si es necesario.
Repará solo con evidencia: las inconsistencias de scrub reciben reparación dirigida después de restaurar la estabilidad.

Checklist D: Endurecimiento post-incidente (lo que desearías haber hecho antes)

Creá alertas que disparen con PGs degraded/undersized, no solo con HEALTH_ERR.
Basalizá latencia commit/apply de OSD y monitoreá outliers.
Rastreá la dispersión de utilización por OSD (VAR) e investigá desequilibrios temprano.
Documentá perfiles de tuning de recuperación y cuándo usar cada uno.
Estandarizá MTU de la red de almacenamiento y validala extremo a extremo durante ventanas de cambio.
Hacé que “quitar banderas de mantenimiento” sea un paso obligatorio con un responsable nombrado.

FAQ

1) ¿HEALTH_WARN siempre es urgente?

No. Es un nivel de severidad, no un diagnóstico. Algunas advertencias son informativas (como crashes recientes de demonios que ya se recuperaron). Otras son indicadores previos a una falla (nearfull, PGs degradados). Tratá como urgentes a PGs degraded/undersized y slow ops porque se traducen en riesgo y dolor para usuarios.

2) ¿Debo reiniciar servicios de Ceph cuando veo HEALTH_WARN?

No como primer movimiento. Reiniciar cambia el estado del clúster y puede reiniciar recuperación y peering. Reiniciá cuando tengas evidencia: un demonio en ciclo de reinicio, un proceso bloqueado o una corrección confirmada que requiera reinicio.

3) ¿Cuál es la diferencia entre “OSD down” y “OSD out”?

Down significa que no responde. Out significa que Ceph ya no coloca datos allí y moverá datos fuera. Down puede ser transitorio; out es una decisión política que desencadena movimiento de datos.

4) ¿Por qué importa que un par de OSDs estén nearfull si el clúster tiene mucho espacio libre?

Porque las escrituras en Ceph se ven limitadas por los dispositivos más llenos. Si dos OSDs están nearfull, la colocación se vuelve restringida, el backfill se complica y el clúster puede throttlear o rechazar escrituras aunque el promedio parezca estar bien.

5) ¿Cuál es la forma más rápida de encontrar el cuello de botella: red, disco o recuperación?

Ejecutá ceph health detail (qué se queja Ceph), ceph osd perf (quién está lento) y ip -s link (la red está descartando). Esos tres usualmente te dicen dónde mirar luego.

6) ¿Puedo cambiar de forma segura parámetros de recuperación durante un incidente?

Sí, si lo tratás como una mitigación temporal y sabés por qué lo hacés. Bajá la concurrencia de recuperación para proteger latencia cliente; aumentala para reducir tiempo-en-riesgo cuando la carga cliente sea baja y el hardware esté sano. Registrá siempre el cambio y revertí luego.

7) ¿Qué implican realmente “active+clean”, “degraded”, “undersized” y “peering”?

active+clean: replicado completamente, sirviendo I/O normalmente. degraded: faltan una o más réplicas. undersized: por debajo del umbral min_size de riesgo; puede bloquear escrituras según configuración y estado. peering: miembros del PG negociando estado; peering prolongado sugiere inestabilidad.

8) ¿Cuándo marco un OSD out versus intentar traerlo de vuelta?

Traelo de vuelta si el problema es transitorio (reboot del host, servicio detenido, hiccup de red corto). Marcá out si el dispositivo/camino está fallando o esperás que el OSD esté indisponible lo suficiente como para que esperar aumente el riesgo. Si lo marcás out, planificá la carga de recuperación.

9) ¿La GUI de Proxmox alcanza para solucionar Ceph?

La GUI sirve para una vista rápida. Para decisiones que afectan movimiento de datos y recuperación, usá las salidas del CLI de Ceph. El CLI te muestra exactamente los tipos de advertencia, timestamps e IDs de demonios que necesitás.

10) Si veo errores de scrub, ¿debería reparar de inmediato?

Primero estabilizá el clúster (quorum, red, estabilidad de OSDs). Luego identificá qué PGs son inconsistentes y repará esos específicamente. Reparar durante inestabilidad puede desperdiciar tiempo y a veces empeorar el ruido.

Conclusión: próximos pasos que podés ejecutar mañana

Cuando Proxmox muestra Ceph HEALTH_WARN, no lo trates como un único problema ni como un color. Tratalo como una lista. Tu camino más seguro es: capturar ceph health detail, confirmar quorum, identificar PGs degradados y OSDs caídos, y luego probar si el cuello de botella es un disco, una red o una tormenta de recuperación.

Pasos prácticos siguientes:

Escribí una hoja de ruta de on-call de una página que comience con el Guion rápido de diagnóstico e incluya los comandos que realmente usás.
Agregá alertas sobre PGs degraded/undersized, OSDs nearfull y slow ops, no solo HEALTH_ERR.
Decidí (con calma diurna) cuál será tu política de tuning de recuperación en horario laboral vs fuera de horario.
Auditá tu red de almacenamiento: consistencia de MTU, descartes y errores de puerto de switch. Ceph amplificará fielmente lo que hace tu red.
Planificá margen de capacidad. Las advertencias nearfull de Ceph son avisos tempranos; tratálos como tal.

Ceph es confiable cuando lo dejás ser predecible. Tu trabajo es mantener el sistema lo suficientemente estable para converger—y evitar “arreglos” que generen más movimiento que información.