Reparar fallo de OSD en Ceph: reequilibrado de datos, problemas de backfilling y proceso de reemplazo de OSD

Reparar un fallo de OSD de Ceph es una tarea rutinaria en entornos de almacenamiento de objetos distribuidos, pero conlleva riesgos: una configuración incorrecta puede degradar el I/O de producción y eliminar OSDs de forma prematura puede provocar PGs unsized/lost. Este artículo explica paso a paso cómo detectar de forma segura un fallo de OSD, cómo solucionar problemas de Backfill/Rebalance, ajustar responsablemente los parámetros de Recovery y cómo realizar un reemplazo de OSD tanto manualmente con ceph‑volume como de forma orquestada con cephadm. Público objetivo: administradores, system engineers y storage operators.

Por qué el enfoque en Rebalance y Backfill es importante

OSD significa Object Storage Daemon; representa un dispositivo y el daemon asociado que gestiona objetos en Placement Groups (PGs). Si un OSD falla, Ceph intenta restaurar las réplicas faltantes mediante Backfill y Rebalancing. Backfill (copiado de datos desde réplicas existentes) y Rebalance (redistribución de la colocación de objetos) generan mucho tráfico de red y I/O en disco. Sin una gestión dirigida, esto puede aumentar las latencias o ralentizar considerablemente la recuperación, y por tanto prolongar el tiempo en que el clúster no está en su estado óptimo.

Primeras acciones: evaluación rápida

Empiece con una comprobación „First‑Look“ para determinar el alcance y la urgencia. Esto ayuda a decidir si necesita ajuste de parámetros, flags temporales o un reemplazo inmediato del OSD.

# Gesamtstatus, betroffene PGs, Recovery-Zeit
ceph -s
# Topologie und welcher Host betroffen ist
ceph osd tree
# Kapazitätsverteilung und freie Kapazität
ceph osd df

Importante: anote el número de PGs degraded/recovering, el Recover‑Throughput y si los mensajes de MON marcan OSDs existentes como out/down. Estos valores determinan la urgencia.

Reparar un fallo de OSD de Ceph: prioridades y árbol de decisión

Al decidir cómo actuar, distinga tres prioridades: 1) mantener el acceso a los datos para las aplicaciones, 2) restaurar la salud del clúster, 3) limpiar/reemplazar de forma sostenible el OSD defectuoso. Un esquema mental rápido:

• Si hay errores SMART o fallos breves repetidos → reemplazar el OSD.
• Si la causa es la red/alcanzabilidad del host → diagnóstico del host, posible uso de noout para mantenimiento programado.
• Si Backfill es extremadamente lento → análisis de causas (red, I/O, parámetros) y ajuste temporal con plan de reversión.

Comprobaciones y métricas esenciales

El monitoring es decisivo. Métricas esenciales:

• PG‑Status: active+clean, recovering, degraded — muestra el estado inmediato.
• Recover Bytes / Recover Throughput: cuántos bytes/seg se transfieren.
• Latencias de OSD (read/write): un aumento sostenido indica hotspots o saturación.
• Métricas de red: ancho de banda, pérdida de paquetes, MTU‑Mismatch.
• Nivel de host: iostat, CPU, memoria, SMART para errores de disco.

# Live Überwachung
ceph -w
# PG-Übersicht
ceph pg dump pgs_brief
# Beispiel iostat
iostat -x 1 5

Registros y mensajes de error típicos

Los logs de OSD y MON muestran las causas. Mensajes frecuentes:

• „heartbeat from osd.X timed out“ → red/alcanzabilidad del host; compruebe MTU, logs del switch, IPMI.
• Errores SMART o I/O → disco físico defectuoso.
• „slow request“ → rendimiento del OSD/dispositivo, con frecuencia causa de un Backfill lento.

# OSD-Logs prüfen
journalctl -u ceph-osd@.service -n 200
# Alternativ Ceph-Logs
grep -i "heartbeat" /var/log/ceph/ceph-osd.*.log

Causas típicas de un backfill muy lento

Un backfill lento suele no ser solo un problema de parámetros. Causas frecuentes:

• Cuellos de botella en la red o pérdida de paquetes (p. ej. desajuste de MTU, QoS, eventos de Spanning Tree).
• OSD individuales lentos (degradación de hardware, límite de IOPS en el controlador RAID).
• Hotspots del clúster: algunos OSD reciben claramente más datos que otros (desequilibrio de CRUSH, CRUSH‑rules mal configuradas).
• Falta de capacidad libre en los OSD de destino: el reequilibrado necesita espacio libre.

Solución de problemas paso a paso para backfills atascados

1. Comprobar la red: pruebas iperf3 entre los hosts afectados.

# Auf Host B (Server, Empfänger)
iperf3 -s
# Auf Host A (Client, Sender)
iperf3 -c  -t 30

2. Comprobar y comparar la MTU en todas las interfaces OSD.

ip link show eth0
ethtool -k eth0

3. Comprobar la salud y el rendimiento del dispositivo (SMART, iostat).

smartctl -a /dev/sdX
iostat -x 1 10

4. Detectar hotspots: analizar OSD‑DF y métricas de latencia de OSD.

ceph osd df tree
# Falls Prometheus vorhanden, prüfen: ceph_osd_op_latency_seconds

Ajuste temporal: modificar con responsabilidad

Los cambios en los parámetros de recovery pueden acelerar la recuperación, pero también afectar el I/O de producción. Guarde antes los valores actuales y aumente de forma incremental mientras monitoriza.

# Werte sichern
ceph config get global osd_max_backfills > /tmp/osd_max_backfills.before || true
ceph config get global osd_recovery_max_active > /tmp/osd_recovery_max_active.before || true
# Beispielhafte, konservative Erhöhung
ceph config set global osd_max_backfills 4
ceph config set global osd_recovery_max_active 8

Por qué funciona: osd_max_backfills controla cuántos hilos de backfill por OSD se ejecutan simultáneamente; osd_recovery_max_active limita las operaciones de recovery paralelas. Aumentarlos permite más movimiento de datos en paralelo, pero requiere muchas más reservas de red y disco. Si falla cuando algunos OSD siguen lentos o el ancho de banda de red está limitado, un recovery aumentado solo empeorará las latencias.

Usar los flags con criterio: noout, norebalance, nobackfill

Los flags pueden ayudar, pero son riesgosos. noout impide que los MONs saquen automáticamente OSDs del CRUSH, por ejemplo durante un mantenimiento temporal. Use:

# Vor geplanter Wartung
ceph osd set noout
# Nach Abschluss
ceph osd unset noout

Aviso: noout puede ocultar fallos reales. norebalance o nobackfill son similares: adecuados para ventanas de mantenimiento cortas, peligrosos si un OSD se ha perdido realmente.

Reemplazo de OSD: flujo de trabajo y comandos (manualmente con ceph-volume)

Si un disco está defectuoso o hay errores SMART, un reemplazo limpio suele ser la mejor opción. Aquí un procedimiento conservador y documentable para un reemplazo manual con ceph-volume (OSDs basados en LVM):

1. Sacar el OSD del servicio de forma limpia (out) y esperar hasta que los PGs estén de nuevo en proceso.

# Markieren und prüfen
ceph osd out osd.
ceph -s    # beobachten, bis PGs recovering/clean werden

2. Detener el servicio OSD en el host.

systemctl stop ceph-osd@.service
# Prüfen, dass der Prozess gestoppt ist
systemctl status ceph-osd@.service

3. Ejecute zap/elimine el dispositivo antiguo (en caso de sustitución física).

# Zap löscht LVM/Partition-Header. ACHTUNG: unwiderruflich für das Device
ceph-volume lvm zap /dev/sdX --destroy

Explicación: ceph-volume lvm zap elimina metadatos de Ceph del dispositivo y lo prepara para su reutilización. Puede fallar si el dispositivo está ocupado; compruebe los LVs con lvs.

4. Instale el nuevo disco y cree el OSD.

# Beispiel: neues OSD auf /dev/sdY anlegen
ceph-volume lvm create --data /dev/sdY

Tras create el OSD se registrará automáticamente en los MONs y se aplicarán las reglas CRUSH. Observe el progreso del reequilibrado.

Reemplazo de OSD: con cephadm (orquestado)

En clústeres gestionados por cephadm, muchos operadores prefieren la variante orquestada porque cephadm se encarga de la gestión del ciclo de vida (imagen de contenedor, despliegue de unidades, registro). Pasos típicos:

1. Preparar: poner el nuevo dispositivo a disposición del host.
2. Agregar el OSD al host con cephadm o reemplazarlo de forma selectiva.

# Alle verfügbaren Devices erkennen (nur lesen)
ceph orch device ls
# Alle verfügbaren Devices als OSDs nutzen (vorsichtig; meist in Staging testen)
ceph orch apply osd --all-available-devices
# Alternativ: gezielt ein Device zu einem Host hinzufügen (prüfen in Ihrer Ceph-Version)
# ceph orch daemon add osd :  <-- je nach Version und Politik

Nota: ceph orch apply osd --all-available-devices es potente y solo debe emplearse en producción si comprende la política del orquestador. Pruebe en staging.

Validación cuidadosa tras el reemplazo

Tras cada reemplazo valide:

• La salud del clúster es HEALTH_OK o, al menos, no hay PGs en degraded/recovering.
• ceph osd df tree muestra datos distribuidos de forma uniforme y sin hotspots extremos.
• Accesos de lectura aleatorios a pools/objetos críticos y comparación de checksums si están disponibles.

# Wichtige Prüfungen
ceph -s
ceph health detail
ceph osd df tree
# Beispiel: stichprobenartiger Objekt-Check
rados -p  ls | head
rados -p  get 

Plan de reversión y documentación

Cualquier cambio en los parámetros de recuperación o la eliminación de OSDs debe ser reversible. Prepare scripts que restauren los valores de configuración originales y registre marcas de tiempo de todas las acciones.

# Rücksetzskript-Beispiel
prev1=$(cat /tmp/osd_max_backfills.before || echo "2")
prev2=$(cat /tmp/osd_recovery_max_active.before || echo "2")
ceph config set global osd_max_backfills "$prev1"
ceph config set global osd_recovery_max_active "$prev2"
ceph osd unset noout || true

Errores comunes y cómo evitarlos

Errores prácticos que ocurren con más frecuencia:

• Cambios en parámetros de recuperación sin observabilidad: compruebe siempre los dashboards y las alertas.
• Eliminar OSD ( ceph osd rm ) mientras los PGs aún están en recovering: causa PGs lost/unsized.
• Aplicar a ciegas ceph orch apply osd --all-available-devices en hosts heterogéneos: creación no deseada de OSDs.
• Capacidad libre insuficiente antes del reemplazo: asegúrese de que los OSDs destino tengan espacio suficiente.

Lista de comprobación pragmática para el reemplazo de OSD

1. Recopilar: ceph -s, ceph osd tree, ceph osd df, logs relevantes.
2. Respaldar: exporte los valores de configuración actuales (/tmp) y guarde capturas de pantalla del monitoring.
3. Decidir: Replace o reparación (Host vs. unidad). Si hay duda, preferir Reweight en lugar de rm.
4. Ejecutar: marcar noout para mantenimiento planificado; OSD out; stop; zap; create con ceph-volume o cephadm.
5. Observar: rendimiento de recuperación, latencias y utilización de la red; mantener puntos de restauración preparados.
6. Validar: HEALTH_OK, ceph osd df tree, lecturas por muestreo.
7. Documentar: tiempos, métricas, decisiones, acción de rollback.

Conclusión

Reparar una falla de OSD de Ceph significa: trabajar de forma estructurada, aprovechar la monitorización, modificar parámetros de forma conservadora y documentada y probar los Replace‑Workflows. Separe los problemas de Host de los de unidad, prefiera el reweighting frente a la eliminación inmediata, y utilice herramientas orquestadas como cephadm solo tras pruebas en staging. Con comprobaciones claras, estrategias de retroceso y scripts automatizados de rollback reduce el riesgo de inconsistencias de datos y acorta los tiempos de recuperación.

Indicaciones operativas adicionales

Asegúrese de que sus Runbooks se practiquen regularmente. Ejecuciones de prueba en Staging aumentan la fiabilidad en intervenciones en vivo. Además, defina qué roles del equipo se informan y actúan en qué orden (Operator, NetAdmin, Storage‑Engineer) — eso acelera las escalaciones y reduce errores durante intervenciones críticas.

Reparar una falla de OSD de Ceph: aspectos de arquitectura y operación

En el tema de reparar fallas de OSD de Ceph, la corrección inmediata es solo una parte: las decisiones de arquitectura y la operación continua determinan en gran medida la rapidez y seguridad de la recuperación. Determinantes son la estrategia de placement (CRUSH), el tipo de pool (replicación vs. Erasure Coding), la topología de red y la reserva de capacidad.

CRUSH‑Map y topología: asegure que las reglas CRUSH reflejen límites físicos (Server, Chassis, Rack, AZ). Sin un placement rack‑aware, al fallar un rack aumenta el riesgo de que muchas réplicas de PG se vean afectadas simultáneamente, concentrando las cargas de backfill.

Diseño de pools: los pools replicados se comportan durante el backfill de forma distinta a los pools erasure‑coded. Los EC‑pools suelen requerir temporalmente más I/O y ancho de banda de red para la reconstrucción y son menos tolerantes a varios fallos simultáneos de OSD. Planifique para los EC‑pools reservas de headroom mayores y tiempos de recuperación más largos en sus SLOs.

Headroom de capacidad: no opere Ceph de forma sostenida con una utilización muy alta. Se recomienda una capacidad libre (según la carga) de al menos 10–20 % para que el rebalancing y las réplicas temporales encuentren espacio. Si los OSD objetivo tienen poco espacio libre, el backfill se estanca y el tiempo de fallo aumenta.

Arquitectura de red: separe el tráfico público y el tráfico del clúster físicamente o mediante QoS. La saturación del interconnect del clúster es una de las causas más frecuentes de backfills lentos. Defina métricas de monitoring para pérdida de paquetes, errores de MTU y throughput por OSD y dispare alarmas antes de que comience el rebalancing.

Indicaciones de integración para la operación: vincule los metadatos de OSD con su CMDB (Host, Slot, número de serie) y sus herramientas de orquestación. Workflows automatizados para el reemplazo de hardware (BMC‑Reboot, Ticketing, Asset‑Update) reducen errores en intervenciones manuales. Las acciones del orquestador (cephadm) deberían registrarse en Change‑Pipelines y probarse en Staging.

Monitorización y automatización: defina umbrales de alerta claros (p. ej. número de PG degradadas, throughput de recuperación por debajo de lo esperado, aumento de latencia de OSD). Automatice las comprobaciones preflight antes de un reemplazo y un script de rollback que restaure todos los valores de configuración guardados anteriormente. Practique el procedimiento regularmente en un entorno de réplica — esto reduce los errores humanos en un escenario en producción.

Revisión rápida antes de intervenir: comprobar la topología CRUSH, tener en cuenta el tipo de pool, verificar la capacidad libre, comprobar la salud de la red, confirmar el mapeo OSD→Hardware en la CMDB. Estos aspectos de arquitectura y operación acortan los tiempos de recuperación y reducen notablemente el riesgo de inconsistencias de datos.

Para este tema también son importantes Ceph Backfill y Ceph Rebalancing. La entrada sitúa estos aspectos de forma comprensible y muestra en qué puntos hay que fijarse en el día a día.