Ceph OSD en Proxmox caído: disco vs red vs servicio — Identificación rápida

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

Cuando un OSD se cae, tu trabajo no es ser ingenioso. Tu trabajo es ser rápido, correcto y aburrido. Empieza por las preguntas que reducen la incertidumbre al máximo.

Primero: ¿Se puede alcanzar el nodo y la hora es correcta?

• Verificar accesibilidad del host: ¿Puedes SSH al nodo? Si no, no estás depurando Ceph; estás depurando el nodo, el hipervisor o la red.
• Verificar hora: Si los relojes se desincronizan, Ceph actúa como si hubieras sustituido la física por teatro improvisado. Arregla el NTP antes de perseguir fantasmas.

Segundo: ¿Falla el proceso OSD o está en ejecución pero aislado?

• Estado del servicio: Si systemd indica que el OSD está en crash-loop, probablemente hay problemas de disco/BlueStore/corrupción/auth. Si muestra “active (running)” pero el cluster lo muestra como down, sospecha de red, firewall o binding a IP incorrecta.
• Vista de Ceph: Compara ceph osd tree con el estado de systemd. Las discrepancias son oro diagnóstico.

Tercero: ¿El disco está lo bastante sano para sostener IO de journal/BlueStore?

• Logs del kernel: Una mirada a dmesg y journalctl suele indicar si la unidad lanza errores o timeouts.
• SMART y timeouts de IO: Si ves resets, timeouts o reubicaciones SMART, deja de reiniciar demonios y empieza a planear el reemplazo.

Condiciones de parada (evita empeorar)

• Si múltiples OSDs están caídos en varios hosts: trátalo como problema de red o configuración a nivel de clúster hasta que se demuestre lo contrario.
• Si un host pierde muchos OSDs a la vez: sospecha de HBA/backplane/PSU o de la red de ese host.
• Si un OSD hace flapping: asume bloqueos de IO intermitentes o pérdida de paquetes, no “Ceph es raro”. Ceph es determinista; tu hardware no lo es.

Modelo mental práctico: qué significa realmente “OSD down”

Ceph tiene dos “verdades” distintas acerca de un OSD:

• Lo que piensa el host: systemd inicia ceph-osd@ID, el proceso está en ejecución, puede leer su almacén, se enlaza a una IP y se conecta a los mons.
• Lo que piensa el cluster: los monitores rastrean los heartbeats del OSD. Si los monitores no los reciben dentro de los tolerancias, el OSD se marca como down. Separadamente, un OSD puede estar out (excluido de la colocación de datos) incluso si está up.

Así que “OSD down” no significa por definición “disco muerto”. Es “el clúster no puede oír a este OSD de forma fiable”. Eso puede ser:

• Disco/IO: el proceso OSD se bloquea o falla porque las lecturas/escrituras a BlueStore o al dispositivo de bloque hacen timeout.
• Red: el OSD está sano localmente pero no puede alcanzar a los mons o pares (ruteo, VLAN, MTU, bonding, switch, firewall).
• Servicio/configuración: el OSD no arranca, no puede autenticarse (cephx), se enlaza a la dirección equivocada o hay una incompatibilidad de versión/config.

Lo que quieres es un conjunto mínimo de comprobaciones que divida estas categorías pronto. Todo lo demás es detalle.

Idea parafraseada (Gene Kim, autor sobre fiabilidad/operaciones): “La mejora ocurre cuando acortas y estabilizas los bucles de retroalimentación.” Eso es lo que es este playbook: bucles cortos.

Datos interesantes y contexto (Ceph + realidad Proxmox)

1. La lógica de “heartbeat” de los OSDs en Ceph es centrada en los monitores. Tu OSD puede estar ocupado, vivo y aun así declarado down si los heartbeats no llegan a tiempo.
2. “Down” y “out” son palancas diferentes. down es detección de salud; out es colocación de datos. Confundirlos provoca tormentas de reequilibrio autoinfligidas.
3. BlueStore reemplazó a FileStore porque el doble-commit y la sobrecarga de sistema de archivos de FileStore no aguantaban las unidades modernas y las expectativas de latencia.
4. El algoritmo CRUSH de Ceph proviene de investigación enfocada en dominios de fallo controlados. Es por eso que puedes sobrevivir a la pérdida de hosts o racks, siempre que tu topología sea honesta.
5. Proxmox integró la gestión de Ceph para hacer el almacenamiento hiperconvergente más accesible, pero también facilita equivocarse con clics cuando no entiendes el comportamiento del demonio subyacente.
6. Los errores de red se hacen pasar por fallos de disco. La pérdida de paquetes puede parecer “operaciones lentas” y timeouts. Un puerto de switch defectuoso ha arruinado más fines de semana que los bugs de firmware.
7. El flapping de OSD rara vez es aleatoriedad del software. A menudo es ahorro de energía, estrangulamiento térmico, problemas de HBA o enlaces marginales—cosas que “funcionan la mayor parte del tiempo” hasta que la carga sube.
8. La recuperación de Ceph puede amplificar problemas. Cuando un OSD cae, el backfill/recovery incrementa IO y tráfico de red, lo que puede llevar a componentes marginales al límite.

Broma #1: El almacenamiento distribuido es solo almacenamiento de un solo host, más red, más consenso, más la posibilidad de equivocarte en tres sitios a la vez.

Tareas de triage: comandos, salidas, decisiones (12+)

Estas son tareas prácticas que puedes ejecutar en nodos Proxmox (o desde un nodo con acceso admin a Ceph). Cada tarea incluye el comando, qué implica la salida típica y qué decides después. Ejecútalas en este orden salvo que ya conozcas la categoría.

Task 1: Confirma que el clúster ve un OSD caído y cuál

cr0x@pve1:~$ ceph -s
  cluster:
    id:     7c2a0d3e-0f8a-4e5a-9a5b-5e9b0c7d3c12
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12 pgs undersized
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 6h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 12 osds: 11 up (since 4m), 12 in (since 6h)
  data:
    pools:   4 pools, 128 pgs
    objects: 2.1M objects, 8.3 TiB
    usage:   25 TiB used, 40 TiB / 65 TiB avail
    pgs:     12 undersized+degraded

Significado: Esto es real: el clúster advierte al menos un OSD caído y los PGs están afectados.

Decisión: Identifica inmediatamente qué OSD(s) y qué host(s). No reinicies servicios al azar todavía.

Task 2: Mapea el ID del OSD al host y la ubicación del dispositivo

cr0x@pve1:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         65.00000 root default
-3         21.66667     host pve1
 0   hdd    3.61111         osd.0      up   1.00000  1.00000
 1   hdd    3.61111         osd.1      up   1.00000  1.00000
 2   hdd    3.61111         osd.2    down   1.00000  1.00000
-5         21.66667     host pve2
 3   hdd    3.61111         osd.3      up   1.00000  1.00000
...

Significado: osd.2 está caído en pve1.

Decisión: Dirígete al host específico y comprueba el demonio OSD y el disco.

Task 3: Comprueba si el servicio OSD está en ejecución (división servicio vs red)

cr0x@pve1:~$ systemctl status ceph-osd@2 --no-pager
● ceph-osd@2.service - Ceph object storage daemon osd.2
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 08:51:22 UTC; 2min 10s ago
    Process: 18342 ExecStart=/usr/bin/ceph-osd -f --cluster ceph --id 2 (code=exited, status=1/FAILURE)
   Main PID: 18342 (code=exited, status=1/FAILURE)

Dec 26 08:51:22 pve1 ceph-osd[18342]: bluestore(/var/lib/ceph/osd/ceph-2) _read_bdev_label failed: (5) Input/output error
Dec 26 08:51:22 pve1 systemd[1]: ceph-osd@2.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 08:51:22 pve1 systemd[1]: ceph-osd@2.service: Failed with result 'exit-code'.

Significado: No está en ejecución; el log grita error de IO al leer la etiqueta de BlueStore. Eso suele ser problema de la ruta de disco, no de la red.

Decisión: Evita reiniciar; inspecciona disco/HBA y logs del kernel. Prepárate para reemplazo.

Task 4: Si está en ejecución, verifica que Ceph aún lo declare down (sospecha de red)

cr0x@pve1:~$ systemctl is-active ceph-osd@2
active

Significado: Localmente activo. Si ceph osd tree aún lo muestra como down, suele ser red, auth o binding.

Decisión: Comprueba conectividad hacia los monitores y las direcciones a las que el OSD está enlazado.

Task 5: Extrae logs específicos del OSD rápidamente

cr0x@pve1:~$ journalctl -u ceph-osd@2 -n 80 --no-pager
Dec 26 08:49:10 pve1 ceph-osd[18011]: starting osd.2 at /var/lib/ceph/osd/ceph-2
Dec 26 08:49:11 pve1 ceph-osd[18011]: bluestore: using bdev /dev/ceph-2/block
Dec 26 08:49:15 pve1 ceph-osd[18011]: heartbeat_map is_healthy_to_peer osd.7 down
Dec 26 08:49:22 pve1 ceph-osd[18011]: slow ops, oldest one is now 31.122s
Dec 26 08:49:29 pve1 ceph-osd[18011]: monclient(hunting): authenticate timed out
Dec 26 08:49:31 pve1 ceph-osd[18011]: unable to talk to monitor
Dec 26 08:49:35 pve1 ceph-osd[18011]: dropped 3 slow requests due to timeout

Significado: Operaciones lentas y luego timeouts de autenticación con monitores. Esto puede ser por stalls de disco o problemas de red para alcanzar a los mons. El “unable to talk to monitor” te inclina hacia red, pero no des por hecho aún.

Decisión: Revisa logs del kernel por timeouts de IO vs problemas de enlace/MTU. Uno suele confesar.

Task 6: Revisa el ring buffer del kernel por resets/timeouts de disco (división disco)

cr0x@pve1:~$ dmesg -T | egrep -i 'blk_update_request|I/O error|reset|timed out|nvme|sd '
[Fri Dec 26 08:48:58 2025] sd 6:0:12:0: [sdl] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[Fri Dec 26 08:48:58 2025] blk_update_request: I/O error, dev sdl, sector 182400 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 08:48:59 2025] sd 6:0:12:0: [sdl] rejecting I/O to offline device
[Fri Dec 26 08:49:02 2025] ata12: hard resetting link
[Fri Dec 26 08:49:07 2025] ata12: link is slow to respond, please be patient

Significado: Eso es una unidad o ruta de enlace que se comporta mal (disco, cable, backplane, HBA). Ceph solo es el mensajero.

Decisión: Trátalo como incidente de hardware: evita flapping marcando out si es necesario y programa reemplazo/mantenimiento.

Task 7: Comprueba enlace de red, errores y drops (división red)

cr0x@pve1:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    981G  744M      0   18422       0  11922
    TX:  bytes packets errors dropped carrier collsns
    904G  701M      0       0       0      0      0

Significado: Paquetes RX descartados en el nivel de bond. En una red de almacenamiento, las pérdidas son picos de latencia con gabardina.

Decisión: Revisa esclavos, puertos de switch, consistencia de MTU y congestión. Si los drops suben durante la recuperación, has encontrado el cuello de botella.

Task 8: Valida consistencia de MTU (arma clásica de pie en Proxmox/Ceph)

cr0x@pve1:~$ ip link show dev vmbr1 | sed -n '1p'
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

cr0x@pve2:~$ ip link show dev vmbr1 | sed -n '1p'
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Significado: Desajuste de MTU. Tramas jumbo en un extremo y no en el otro son la forma de comprar timeouts “aleatorios”.

Decisión: Corrige MTU end-to-end (hosts, bonds, bridges, puertos de switch). Luego reevalúa la salud del OSD.

Task 9: Confirma conectividad a los monitores desde el nodo afectado (red vs auth)

cr0x@pve1:~$ ceph quorum_status --format json-pretty | sed -n '1,40p'
{
  "election_epoch": 88,
  "quorum": [
    0,
    1,
    2
  ],
  "quorum_names": [
    "pve1",
    "pve2",
    "pve3"
  ],
  "quorum_leader_name": "pve1"
}

Significado: Desde este nodo, la CLI puede hablar con los mons. Eso no garantiza que el OSD pueda, pero reduce la probabilidad de aislamiento total de red.

Decisión: Si el OSD no puede autenticarse pero la CLI sí, sospecha de keyring/permiso cephx o binding del OSD a la interfaz equivocada.

Task 10: Inspecciona qué IPs Ceph cree que debe usar (errores de binding)

cr0x@pve1:~$ ceph config get osd public_network
10.10.10.0/24

cr0x@pve1:~$ ceph config get osd cluster_network
10.10.20.0/24

Significado: Ceph está configurado para enlazarse a redes específicas. Si las interfaces del host no coinciden (o las rutas están mal), el OSD puede enlazarse a algo inútil.

Decisión: Verifica la dirección IP del host y que ambas redes existan y enruten correctamente en este nodo.

Task 11: Verifica qué dirección está anunciando el OSD

cr0x@pve1:~$ ceph osd find 2
{
  "osd": 2,
  "ip": "10.10.10.11:6806/12345",
  "crush_location": {
    "host": "pve1",
    "root": "default"
  }
}

Significado: El OSD anuncia 10.10.10.11. Si esa IP es errónea, se movió o ahora está en otra interfaz/VLAN, los pares no podrán alcanzarlo.

Decisión: Si esto no coincide con la red prevista, corrige el direccionamiento y reinicia el OSD limpiamente. No lo “outes” aún a menos que el riesgo de datos lo requiera.

Task 12: Revisa ceph health detail por pistas inmediatas

cr0x@pve1:~$ ceph health detail
HEALTH_WARN 1 osds down; Degraded data redundancy: 12 pgs undersized
[WRN] OSD_DOWN: 1 osds down
    osd.2 is down
[WRN] PG_DEGRADED: Degraded data redundancy: 12 pgs undersized
    pg 1.2c is undersized+degraded, acting [7,2]
    pg 1.2f is undersized+degraded, acting [2,9]

Significado: El clúster está gritando “me falta osd.2.” No dice por qué, pero te indica impacto y urgencia.

Decisión: Si el IO de clientes está afectado y necesitas estabilidad, considera marcar el OSD out (con precaución) para iniciar la recuperación—después de confirmar que realmente está muerto o inalcanzable por un tiempo.

Task 13: Verifica el mapeo del dispositivo de bloque para ese OSD (exactitud de la ruta)

cr0x@pve1:~$ ceph-volume lvm list --osd-id 2
====== osd.2 =======
[block]       /dev/ceph-2/block
  type        block
  lv_path     /dev/ceph-2/osd-block-3c6f8a1d-9c6e-4ad2-9e4c-5d2c6c4a9f12
  vg_name     ceph-2
  lv_name     osd-block-3c6f8a1d-9c6e-4ad2-9e4c-5d2c6c4a9f12
  devices     /dev/sdl

Significado: El OSD depende de /dev/sdl. Ahora puedes comprobar SMART, el controlador, el cableado y si /dev/sdl sigue presente.

Decisión: Si el dispositivo falta o es inestable, deténte. Tiempo para manejo de hardware.

Task 14: Presencia del dispositivo y sanidad de latencia

cr0x@pve1:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,STATE,ROTA,TYPE,MOUNTPOINT | egrep 'sdl|ceph-2|NAME'
NAME          SIZE MODEL            SERIAL        STATE ROTA TYPE MOUNTPOINT
sdl         3.6T  ST4000NM000A     ZC1ABC12      running    1 disk
ceph--2-osd--block--3c6f8a1d 3.6T                          1 lvm

Significado: El dispositivo existe. Existir no es sinónimo de saludable, pero es mejor que “desaparecido”.

Decisión: Si el servicio falla con errores de IO pese a la presencia, ejecuta SMART y revisa resets de enlace.

Task 15: Comprobación SMART (no sobreinterpretes, pero respétalo)

cr0x@pve1:~$ smartctl -a /dev/sdl | egrep -i 'Reallocated|Pending|Offline_Uncorrectable|SMART overall|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       39876
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       3200
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       88
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       88

Significado: La unidad te está diciendo efectivamente que se va. Créelo.

Decisión: Reemplaza el disco. No pierdas tiempo ajustando Ceph para hardware que falla.

Task 16: Si sospechas pérdida de red, prueba la pérdida y MTU correctamente (no solo ping)

cr0x@pve1:~$ ping -c 5 -M do -s 8972 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
From 10.10.10.11 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.10.10.11 icmp_seq=2 Frag needed and DF set (mtu = 1500)
--- 10.10.10.12 ping statistics ---
5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4081ms

Significado: El MTU del camino es 1500 en algún punto. Jumbo no es end-to-end.

Decisión: Corrige la configuración de MTU antes de culpar a Ceph. Luego reinicia el OSD afectado si se enlazó correctamente.

Task 17: Si el servicio falla, inspecciona BlueStore y permisos de FS rápidamente

cr0x@pve1:~$ ls -ld /var/lib/ceph/osd/ceph-2
drwxr-x--- 5 ceph ceph 4096 Dec 26 08:40 /var/lib/ceph/osd/ceph-2

Significado: La propiedad parece normal. Si es incorrecta (root:root o demasiado restrictiva), el OSD podría fallar tempranamente.

Decisión: Corrige permisos solo si puedes explicar cómo cambiaron (scripts de paquete, ediciones manuales, restauración). De lo contrario arriesgas enmascarar un problema más profundo.

Task 18: Revisa reports de crash de Ceph para este demonio (a menudo subutilizados, muy reveladores)

cr0x@pve1:~$ ceph crash ls | head
ID                                      ENTITY    NEW
2025-12-26_08:51:22.18342               osd.2     *
2025-12-20_14:11:03.22991               osd.7

cr0x@pve1:~$ ceph crash info 2025-12-26_08:51:22.18342 | sed -n '1,60p'
{
  "crash_id": "2025-12-26_08:51:22.18342",
  "entity_name": "osd.2",
  "utsname_hostname": "pve1",
  "assert_condition": "bdev_label_valid",
  "backtrace": [
    "ceph-osd(...",
    "libc.so.6(..."
  ]
}

Significado: El crash está registrado y apunta a un problema de label/lectura del dispositivo BlueStore. Esto apoya la hipótesis de “ruta de disco / IO”.

Decisión: No lo trates como “reinicio lo arregla”. Planea swap de hardware o reparación de BlueStore solo si sabes lo que haces y tienes redundancia.

Disco vs red vs servicio: señales reveladoras

El diagnóstico más rápido es reconocimiento de patrones respaldado por uno o dos comandos confirmatorios. Aquí están los patrones que importan en producción.

Indicadores de problema de disco/IO

• El OSD no arranca con errores de lectura de BlueStore, “Input/output error” o “failed to read bdev label”.
• Los logs del kernel muestran resets/timeouts en el dispositivo subyacente (reset de enlace SATA, timeout NVMe, SCSI “rejecting I/O”).
• SMART muestra sectores pendientes/reasignados o salud general FAIL.
• El OSD hace flapping bajo carga (recovery/backfill lo desencadena). Las unidades marginales se colapsan cuando dejas de ser cortés y empiezas a ser realista.

Decisión práctica: Si los logs del kernel muestran timeouts de IO, asume hardware hasta demostrar lo contrario. Reinicios son cuidados paliativos, no tratamiento.

Indicadores de problema de red

• El proceso OSD está en ejecución pero Ceph lo marca como down; los logs muestran “unable to talk to monitor” o timeouts de heartbeat.
• Múltiples OSDs caen en distintos hosts alrededor del mismo momento.
• Caídas/errores de paquetes en interfaces de almacenamiento; contadores de switch suben; bonding hace flapping.
• Desajuste de MTU (jumbo frames medio habilitados) causando fragmentación intermitente o drops silenciosos con DF activado.
• Enrutamiento asimétrico (la red pública funciona, la cluster no) provocando conectividad parcial extraña.

Decisión práctica: Arregla la pérdida de paquetes antes de “tunear Ceph”. Ceph no puede reconfigurar la física.

Indicadores de problema de servicio/configuración

• systemd muestra fallos con exit-code sin errores de kernel IO (piensa: auth, config, permisos, keyring faltante).
• Errores cephx en el log del OSD: “permission denied”, “bad key”, “authenticate timed out” (también puede ser red, así que valida).
• El OSD se enlaza a la dirección equivocada tras renombrar interfaz, cambiar bridge o refactorizar la red.
• Skew de versiones o deriva de configuración tras upgrades parciales (común en ventanas de cambio corporativas donde alguien “solo tuvo tiempo” para dos nodos).

Decisión práctica: Si es servicio/config, normalmente puedes arreglarlo sin reemplazar hardware—pero solo después de confirmar que la ruta de disco es estable y la red está limpia.

Análisis profundo: rutas rápidas dentro de cada modo de fallo

1) Fallos en la ruta de disco: el síntoma “OSD está caído” es el último dominó

Los OSDs de Ceph son muy buenos tolerando lentitud transitoria—hasta que dejan de serlo. Cuando los stalls de IO superan las tolerancias de heartbeat, los monitores declaran el OSD down. A veces el proceso OSD sigue vivo, bloqueado en IO, pareciendo “ejecutándose”. Por eso no te quedes solo en el estado de systemd.

Los fallos en la ruta de disco vienen en sabores:

• Fallo del medio: sectores reasignados/pendientes, incontables no corregibles, reintentos de lectura, problemas térmicos.
• Fallo de transporte: cable SATA/SAS malo, backplane marginal, bugs de firmware de HBA, problemas con expansores.
• Problemas de energía: un rail PSU compartido o alimentación del backplane que provoca resets bajo carga.
• Colapso de colas: un disco que “funciona” pero presenta picos catastróficos de latencia (el asesino del almacenamiento distribuido).

Qué hacer cuando sospechas fuertemente de la ruta de disco:

• Recolecta evidencia (dmesg, SMART, logs OSD) una vez.
• Evita el flapping. El flapping incrementa el churn de recuperación, que incrementa carga, lo que empeora el flapping. Es un bucle de retroalimentación con nombre de trabajo.
• Decide: mantener in temporalmente si va a volver rápido y necesitas evitar reequilibrio, o marcar out si está realmente muerto o inseguro.

Guía con opinión: Si ves repeated timeouts/resets de IO en ese dispositivo por más de unos minutos, marca el OSD out y planifica el reemplazo. Si lo mantienes in “para ver si se estabiliza”, estás apostando con la salud del clúster con ventaja de la casa del 100%.

2) Fallos de red: Ceph es un detector de latencia que además almacena datos

Ceph es implacable con la latencia porque debe serlo. Si los heartbeats y mensajes se retrasan, debe asumir fallo para preservar consistencia. Eso hace a Ceph un gran sistema de alerta temprana para problemas de red—siempre que no mates al mensajero reiniciando demonios hasta que los contadores se reinicien.

Fallos de red que suelen presentarse como OSD down:

• Desajuste de MTU entre vmbr/bond, puertos de switch o interfaces VLAN.
• Mala configuración de bonding (LACP en host y estático en switch, o viceversa), provocando agujeros intermitentes por hashing.
• Inconsistencias de etiquetado VLAN tras cambios en el switch.
• Reglas de firewall que bloquean puertos de messenger Ceph (rango típico 6800–7300) o puertos de monitor.
• Congestión y microburst durante recovery/backfill.

Modo rápido para separar “red” de “stall de disco” cuando los logs muestran timeouts: revisa los logs del kernel. Los stalls de disco suelen mostrar mensajes de dispositivo. Los problemas de red suelen mostrar drops de paquetes, flaps de enlace, mensajes de bonding o nada en absoluto mientras Ceph se queja. En ese caso de “nada”, mira los contadores de interfaz y los logs del switch.

3) Fallos de servicio/config: los sutiles

Los problemas de servicio son donde los humanos causan más daño porque confían. El disco existe, la red hace ping, así que el OSD “debería” arrancar. Pero Ceph no es un binario único; es un conjunto de identidades, keyrings, configs y mapeos de dispositivos. Rompe uno y obtienes un OSD que educadamente se niega.

Disparadores comunes de servicio/config:

• Keyring faltante o permisos equivocados bajo /var/lib/ceph/osd/ceph-ID/keyring.
• Permisos del directorio OSD cambiados durante reparación manual o restauración.
• Symlink de dispositivo obsoleto si udev renombró y el OSD apunta a una ruta muerta.
• Upgrades parciales provocando incompatibilidades de messenger/protocolo o suposiciones de config.

Las correcciones de servicio deberían ser reversibles. Si te pillas “probando cosas”, para y toma un snapshot de hechos: logs, config, mapeo de dispositivos. Luego cambia una cosa, valida y continúa.

Broma #2: Un OSD que “solo necesita un reinicio” es como una impresora que “solo necesita un reinicio”—rara vez es toda la historia, solo la parte que puedes hacer sin herramientas.

Tres microhistorias del mundo corporativo (qué falló, qué funcionó)

Microhistoria #1: El incidente causado por una suposición equivocada

Tenían un pequeño clúster Proxmox con Ceph para discos de VM. Un OSD cayó tras un reinicio de mantenimiento rutinario. El on-call miró ceph -s, vio “1 osd down” y asumió que el disco había muerto. Razonable… si te gusta equivocarte eficientemente.

El equipo marcó el OSD out inmediatamente para “iniciar la recuperación”. Eso desencadenó backfill en todo el clúster. La utilización de red subió. La latencia subió con ella. Luego otros dos OSDs empezaron a hacer flapping en otros nodos. Ahora el panel era un árbol de Navidad y el IO cliente estaba intermitentemente bloqueado.

La causa raíz no eran discos. El reinicio había reordenado nombres de interfaz en ese host tras una actualización de kernel, y la configuración de red pública de Ceph seguía apuntando al bridge antiguo. El OSD arrancó, se enlazó a la dirección equivocada y se volvió inalcanzable para los pares. El “fallo de disco” fue la historia que los humanos se contaron porque encajaba con el síntoma.

Cuando corrigieron el binding de la interfaz y reiniciaron el OSD, volvió instantáneamente. Pero el daño ya estaba hecho: el clúster ya estaba reequilibrando fuertemente. Convertieron un problema de identidad de un OSD en un incidente de rendimiento multi-OSD.

Lo que cambió su comportamiento fue una regla: nunca marques un OSD out hasta que hayas validado errores en la ruta de disco o confirmado aislamiento sostenido de red. Les ralentizó cinco minutos y les ahorró horas después.

Microhistoria #2: La optimización que salió mal

Otro equipo quería “más rendimiento” y “menos overhead”. Habilitaron jumbo frames en la red de almacenamiento. Buena intuición. Actualizaron bridges y bonds en Proxmox a MTU 9000, actualizaron un par de puertos ToR y probaron con un ping básico, y declararon victoria.

Semanas después, durante un evento de recuperación pesado (reemplazo planificado de OSD), los OSDs empezaron a caer y entrar. Las advertencias de slow ops se acumularon. El on-call vio timeouts de autenticación con monitores y sospechó de cephx. Rotaron claves. Reiniciaron demonios. Incluso reiniciaron un monitor. Todo empeoró.

El culpable fue aburrido: un camino intermedio en el switch todavía tenía MTU 1500 en un trunk VLAN. La mayoría del tráfico “funcionaba” porque caía a paquetes más pequeños, pero patrones específicos del messenger Ceph bajo carga empezaron a golpear restricciones de fragmentación. La prueba de ping original no usó DF con payload grande. La optimización creó un modo de fallo latente que solo se disparaba bajo estrés—justo cuando menos quieres sorpresas.

Tras arreglar MTU end-to-end y estandarizar la validación (DF pings, contadores de interfaz, comprobaciones de puertos de switch), el flapping se detuvo. El rendimiento mejoró también, pero la verdadera ganancia fue la previsibilidad.

La lección: las optimizaciones que dependen de corrección a través de múltiples capas deben tratarse como migraciones de configuración, no como ajustes. Valida como un escéptico, no como un optimista.

Microhistoria #3: La práctica aburrida pero correcta que salvó el día

Una organización ejecutaba Ceph en Proxmox con un procedimiento de cambios estricto que todos se burlaban hasta que importó. Cada disco OSD tenía un mapeo registrado: bahía chasis → número de serie → ruta de dispositivo en Linux → ID del OSD. También guardaban un pequeño stock de discos idénticos y tenían un runbook de reemplazo probado.

Cuando un OSD cayó a las 14:00 un martes (el tipo de incidente más amable), el on-call no adivinó. Ejecutó ceph osd tree, mapeó el ID del OSD al número de serie mediante su inventario, luego confirmó con ceph-volume lvm list y smartctl. SMART mostró sectores pendientes y los logs del kernel mostraron resets. Sin drama.

Marcó el OSD out tras confirmar la falla real, ajustó flags de recuperación para evitar saturar el IO cliente y reemplazó el disco en la bahía correcta a la primera. El OSD de repuesto arrancó, backfilled y el clúster volvió a salud limpia sin una sola reunión “¿dónde está ese disco?”.

Sin heroísmos. Sin comandos místicos de Ceph. Solo inventario preciso y un runbook usado antes de que fuera necesario.

La lección: las prácticas aburridas escalan mejor que las personas ingeniosas. Además, duermen más.

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

1) “El OSD está caído, así que el disco está muerto”

Síntoma: ceph -s informa 1 OSD down; los admins inmediatamente planifican reemplazo de disco.

Causa raíz: El OSD está en ejecución pero inalcanzable por desajuste de MTU, problema VLAN o dirección bind equivocada.

Solución: Compara systemctl is-active ceph-osd@ID con ceph osd tree. Si está activo localmente pero down en el clúster, valida MTU con DF ping, revisa drops de interfaz y confirma la IP anunciada por el OSD via ceph osd find.

2) “Reiniciar el OSD lo arreglará” (amplificador de flapping)

Síntoma: OSD alterna up/down cada pocos minutos; reiniciar parece ayudar brevemente.

Causa raíz: Stalls de IO o resets de enlace bajo carga; reiniciar solo resetea timers y oculta el problema hasta que vuelva la carga.

Solución: Revisa dmesg por resets/timeouts; revisa SMART. Si hay señales de hardware, deja de reiniciar y programa reemplazo. Si hay señales de red (drops/errores), arregla la red primero.

3) Marcar OSD out demasiado pronto

Síntoma: Un OSD cae; el operador lo marca out de inmediato; el rendimiento del clúster se desploma.

Causa raíz: El reequilibrio/backfill empieza mientras el problema subyacente era transitorio o solucionable (p. ej., binding de servicio). El tráfico de recuperación sobrecarga el clúster, causando más timeouts.

Solución: Espera lo suficiente para confirmar persistencia (minutos, no segundos), valida la categoría y limita la recuperación si el IO cliente importa. Marca out solo cuando estés seguro de que no volverá pronto.

4) Jumbo frames medio habilitados

Síntoma: Eventos aleatorios de OSD down durante recovery; pings funcionan; sesiones TCP se reinician bajo carga.

Causa raíz: Desajuste de MTU en bridges, bonds, VLANs o trunks de switch.

Solución: Estandariza MTU end-to-end. Valida con ping -M do -s 8972 entre todos los nodos Ceph en las redes relevantes. Revisa también la configuración del switch.

5) Ignorar un disco “casi bien” que tiene picos de latencia

Síntoma: No hay SMART FAIL, pero frecuentes slow ops y ocasional OSD down.

Causa raíz: Disco/HBA/backplane causando cola larga intermitente sin fallos absolutos. Ceph castiga la latencia tail.

Solución: Usa logs del kernel y timing de logs OSD. Correlaciona eventos down con stalls de IO. Considera reemplazar el componente sospechoso incluso sin un resumen SMART dramático.

6) Cambios de firewall o ACL que bloquean puertos Ceph

Síntoma: OSD arranca pero no puede conectar a mons; logs muestran timeouts; el problema aparece tras “hardening” de seguridad.

Causa raíz: Puertos de monitor/messenger bloqueados o reglas asimétricas entre nodos.

Solución: Verifica alcance en los puertos requeridos desde el nodo OSD hacia monitores y pares. Revierte o corrige reglas. La consistencia importa más que la astucia.

Listas de verificación / plan paso a paso

Checklist A: Triage de cinco minutos “¿qué es?”

1. Ejecuta ceph -s y ceph osd tree. Identifica IDs de OSD y hosts.
2. En el host: systemctl status ceph-osd@ID y journalctl -u ceph-osd@ID -n 80.
3. En el host: dmesg -T | egrep -i 'I/O error|timed out|reset|rejecting I/O'.
4. En el host: ip -s link en las interfaces hacia Ceph; busca drops/errores.
5. Valida MTU con DF ping entre IPs de almacenamiento si jumbo está habilitado.

Checklist B: Si parece disco/IO

1. Confirma mapeo: ceph-volume lvm list --osd-id ID.
2. Revisa SMART: smartctl -a /dev/DEVICE.
3. Revisa errores y resets del kernel: dmesg -T.
4. Si se confirma fallo: planifica reemplazo. Si hace mucho flapping, marca out para estabilizar la colocación.
5. Limita la recuperación si el IO cliente importa (coordina con tu equipo, no improvises en horas punta).

Checklist C: Si parece red

1. Revisa contadores de interfaz (drops/errores) y estado de enlace.
2. Valida MTU end-to-end con DF pings.
3. Revisa estado de bonding y consistencia LACP; verifica que los esclavos no hagan flapping.
4. Confirma IP anunciada por el OSD: ceph osd find ID.
5. Arregla la red primero, luego reinicia el OSD una vez, no diez veces.

Checklist D: Si parece servicio/config

1. Revisa systemd y logs por errores cephx/config.
2. Valida propiedad y presencia del keyring en el directorio del OSD.
3. Confirma que los valores de red de Ceph coinciden con interfaces y rutas reales.
4. Revisa upgrades recientes y skew de versiones entre nodos.
5. Aplica un cambio a la vez, documenta lo tocado y revierte si el síntoma cambia pero no mejora.

Preguntas frecuentes

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

Down es detección de salud (los monitores no reciben heartbeats). Out cambia la colocación CRUSH para que el clúster deje de intentar almacenar allí e inicie la recuperación en otro sitio.

2) El servicio OSD está “active (running)” pero Ceph dice que está down. ¿Cómo?

El proceso puede estar vivo pero inalcanzable: dirección bind equivocada, aislamiento de red, reglas de firewall, desajuste de MTU o pérdida severa de paquetes. Valida la IP anunciada (ceph osd find) y drops de interfaz.

3) ¿Debo reiniciar el servicio OSD cuando cae?

Sólo después de revisar journalctl y dmesg. Si los logs del kernel muestran timeouts/resets de IO, reiniciar solo hace la caída más ruidosa. Arregla hardware primero.

4) ¿Cuándo debo marcar un OSD out?

Cuando tengas evidencia de que no volverá pronto (fallo hardware, aislamiento persistente de red) y mantenerlo in esté causando inestabilidad. Marcar out desencadena carga de recuperación, así que hazlo deliberadamente.

5) ¿Puede un solo disco malo tumbar múltiples OSDs?

Sí, si varios OSDs comparten un HBA, expander, backplane, o si un host tiene problemas sistémicos de IO. También sí si “un solo disco” es en realidad un dominio de fallo compartido que no modelaste.

6) ¿Por qué los OSDs caen más durante recovery/backfill?

La recuperación incrementa la profundidad de IO y el tráfico de red. Discos marginales, HBAs, cables o puertos de switch que “funcionan bien” en reposo pueden colapsar bajo carga real.

7) ¿SMART es suficiente para declarar un disco sano o muerto?

SMART es útil, no omnisciente. Un SMART FAIL es concluyente. Un SMART PASS no garantiza, especialmente para picos de latencia y problemas de camino de controlador.

8) ¿Cómo distinguo desajuste de MTU de pérdida general de paquetes?

El desajuste de MTU aparece cuando usas pings DF con payload grande y obtienes “Frag needed and DF set.” La pérdida general muestra drops/errores en contadores y pérdida de ping inconsistente incluso con paquetes pequeños.

9) Tenemos redes public y cluster separadas. ¿Cuál importa para OSD down?

Ambas pueden importar. Los OSDs hablan con los mons por la red public, y a menudo usan la cluster para replicación/backfill. Una falla en cualquiera puede desencadenar comportamiento down según la configuración y patrones de tráfico.

10) ¿Cuál es la forma más segura de recopilar evidencia antes de cambiar algo?

Toma: ceph -s, ceph health detail, ceph osd tree, systemctl status ceph-osd@ID, journalctl -u ceph-osd@ID y dmesg -T. Ese conjunto suele identificar la categoría.

Siguientes pasos que deberías hacer realmente

Si quieres menos sorpresas de “OSD down”, haz el trabajo poco glamuroso:

1. Estandariza tu triage rápido: convierte el playbook anterior en memoria muscular por defecto. La consistencia vence a la brillantez.
2. Endurece tus supuestos de red: valida MTU end-to-end, monitoriza drops y trata las VLAN de almacenamiento como sistemas críticos de producción (porque lo son).
3. Inventaría tus discos en serio: mapea ID OSD a serial y bahía. El momento para aprender qué disco es cuál no es durante una caída.
4. Reduce incentivos al flapping: deja de reiniciar a ciegas. Recolecta evidencia, decide disco vs red vs servicio y actúa una vez.
5. Practica el reemplazo de OSD cuando no haya fuego. El runbook usado con calma es el runbook que usarás correctamente bajo presión.

El objetivo no es convertirte en un mago de Ceph. El objetivo es dejar de perder tiempo por mala clasificación. Disco, red o servicio: elige el correcto rápido y lo demás se convierte en ingeniería razonable en lugar de danza interpretativa.