Cuando una VM va torpe y hay storage compartido de por medio, la tentación es preciosa. Todo el mundo mira a Ceph, pone cara grave y empieza a hablar de latencia como si ya supiera qué pasa. Yo intento no entrar tan rápido en esa película.
Antes de abrir la interfaz, antes de ponerme a revisar gráficas y antes de culpar al cluster entero, lanzo ceph -s.
No porque el comando me vaya a explicar toda la historia. No lo hace. Pero sí porque me da en pocos segundos una lectura muy útil del tono real del cluster. Si está limpio, si viene tocado, si hay PGs degradadas, si hay OSDs en un estado raro o si el problema ya lleva rato dejando huellas bastante visibles.
Y hay otra razón por la que me gusta. Me obliga a dejar de hablar del storage como concepto abstracto. Con ceph -s la conversación baja a cosas concretas. Estado de salud, OSDs arriba o dentro, objetos degradados, pools llenándose demasiado, scrubs atrasados, flags olvidadas. Ahí ya no hay mucho sitio para el teatro.
por qué sigo empezando por ceph -s#
Porque es el filtro más rentable que conozco para separar dos situaciones muy distintas.
La primera es la buena. Ceph está razonablemente tranquilo y el problema probablemente está en otro sitio. Igual en la VM, en la red, en el host o en una carga puntual.
La segunda es la incómoda. Ceph sigue levantado, sí, pero ya te está diciendo que no está para fiestas. Y si ignoras eso, luego el cluster te cobra la confianza con intereses.
La documentación de Ceph lo plantea bastante claro. Antes de empezar a leer o escribir datos, conviene revisar el estado del cluster con ceph status o ceph -s. Proxmox, por su parte, insiste en algo que a veces se olvida cuando montamos infra en casa. Ceph no es solo espacio compartido. Es un sistema distribuido con su propio apetito de red, CPU, memoria y disco. Si una pieza se tuerce, la foto del cluster cambia rápido.
Yo no necesito más ceremonia que esa. Si el cluster es parte crítica del homelab, mirar ceph -s antes de tocar nada me parece una costumbre bastante sensata.
una salida real que me gusta porque no es bonita#
He preparado esta captura con una salida real de mi cluster, saneada en nombres internos y detalles que no aportan nada fuera de casa.
Me gusta porque no enseña el caso perfecto. Enseña uno mucho más útil.
- el cluster responde
- los monitores están en quorum
- los OSDs salen
upein - aun así el estado general es
HEALTH_WARN
Eso es exactamente lo que quiero ver en un artículo así. El caso que más ayuda no es el de HEALTH_OK con todo limpio. Es el caso ambiguo, el que te podría engañar si solo miras dos líneas y cierras terminal demasiado pronto.
En esta salida hay varios avisos que ya me hacen bajar el ritmo.
- un OSD marcado como
backfillfull - flags
noouten un host - objetos degradados
- una PG
active+undersized+degraded - scrubs atrasados
- dos pools en estado
backfillfull
No es una catástrofe. Tampoco es un cluster que yo trataría como si estuviera plácido.
la línea que manda de verdad, health#
Lo primero que leo siempre es la cabecera de salud. No por original, sino porque manda.
En la captura sale esto.
health: HEALTH_WARN
Debajo aparece el resumen del motivo. Ahí es donde empieza lo interesante. No me basta con ver la etiqueta amarilla. Quiero el porqué.
En este caso el resumen ya me da bastante contexto.
- hay un OSD en un estado problemático
- hay un OSD
backfillfull - siguen activas flags
NOUP,NODOWN,NOINoNOOUT - existe degradación de redundancia
- hay scrubs pendientes desde hace demasiado tiempo
- dos pools están
backfillfull
A mí esto me cambia el tono al instante. Ya no estoy en modo “vamos a tocar cosas y luego miramos”. Estoy en modo “vale, el cluster sigue operativo, pero no está para meterle otra tensión gratis”.
Ese matiz importa mucho. En Ceph, WARN no siempre significa drama inmediato. Pero sí suele significar que hay contexto que no debes ignorar si aprecias tus propias horas de sueño.
por qué me fijo tanto en que up e in no me tranquilizan por sí solos#
Hay una línea muy engañosa en muchas salidas de Ceph. La de los OSDs.
En esta captura sale así.
osd: 4 osds: 4 up, 4 in
Si me quedara solo con eso, podría contarme la historia de que el cluster está básicamente bien. Los cuatro OSDs están arriba. Los cuatro siguen dentro. Todo correcto. Cerramos terminal.
Pues no.
Esa línea es importante, claro. Me dice que no tengo un OSD caído de forma obvia. Pero no invalida el resto de avisos. De hecho, esa combinación es bastante instructiva. Puedes tener todos los OSDs up e in y, aun así, seguir con degradación, con pools demasiado llenos para backfill y con flags que alteran cómo se comporta el cluster.
Eso es justo lo que me gusta de ceph -s. Te obliga a leer la foto entera. Si alguien quiere resumir Ceph a una única línea feliz, el propio comando se encarga de fastidiarle el plan.
cómo leo el bloque de servicios#
Después del estado general voy al bloque services. Es donde compruebo si la estructura básica sigue en pie.
En la captura sale esto.
mon: 3 daemons, quorum node-a,node-b,node-cmgr: node-a(active, since 5d)osd: 4 osds: 4 up, 4 in
Lo primero que me importa aquí es el quorum de monitores. Si los MON no están bien, la conversación cambia mucho y muy rápido. En mi rutina, ver tres monitores en quorum me da una base razonable para seguir leyendo con calma.
Luego miro el manager activo. No suelo obsesionarme con qué nodo concreto carga el mgr, pero sí me interesa que la línea salga clara, sin rarezas y sin reinicios sospechosos.
Y por último, los OSDs. Como decía antes, no me relajo solo por verlos up e in, pero desde luego prefiero empezar desde ahí que desde un 3 up, 4 in o cosas así, que ya te obligan a pensar en otra liga de problemas.
el bloque data es donde empiezo a medir el susto#
Para mí, la parte más útil de ceph -s suele estar en data.
Aquí veo cuántos pools y PGs tengo, cuántos objetos se están moviendo y, sobre todo, si el estado de esas PGs merece respeto inmediato.
La salida de esta captura enseña esto.
2 pools, 33 pgs121.86k objects, 458 GiB1.3 TiB used, 6.5 TiB / 7.7 TiB avail32 active+clean1 active+undersized+degraded
La línea buena es 32 active+clean. La mala es la que viene justo debajo.
1 active+undersized+degraded
Aquí yo ya no discuto con el cluster. Si me dice que hay una PG degradada y además undersized, me la tomo en serio. Aunque solo sea una. Aunque el porcentaje total degradado parezca modesto. Aunque el resto del cluster siga dando servicio.
Porque el problema no es solo el porcentaje. El problema es el tipo de síntoma.
undersized me dice que esa PG no tiene todas las réplicas que debería. degraded me dice que la redundancia no está donde toca. Eso no significa automáticamente que todo vaya a romperse, pero sí significa que el margen de seguridad ya no es el que yo quiero cuando voy a tocar almacenamiento, reiniciar nodos o presumir de homelab robusto.
la parte de io me ayuda a no sacar conclusiones simples#
También miro la línea de I/O.
En esta salida aparece algo así como 304 MiB/s rd y una escritura bastante más modesta. Eso me interesa por dos motivos.
Primero, porque me recuerda que el cluster no está quieto. No estoy leyendo una foto de laboratorio con el sistema en reposo absoluto. Hay clientes trabajando.
Segundo, porque el rendimiento aparente puede engañar. Un cluster puede seguir sirviendo lectura bastante bien mientras arrastra avisos de salud. Si me limito a pensar “como sigue dando caña, entonces no pasa nada”, acabo ignorando señales que luego vuelven peor disfrazadas.
Ceph tiene bastante aguante y eso es una bendición. También puede empujar a la complacencia, que ya no me parece tan bendición.
lo que me contó ceph health detail y por qué no lo ignoré#
Después de ceph -s, si la salud no está en OK, el siguiente paso lógico para mí es ceph health detail.
Aquí es donde el cluster deja de resumir y se pone concreto. En esta misma captura aparecen varios avisos que merecen nombre y apellidos.
OSD_BACKFILLFULL#
Este aviso me importa mucho.
Que un OSD esté backfillfull significa que Ceph considera que ya no tiene margen cómodo para operaciones de backfill. No es lo mismo que estar absolutamente lleno, pero sí es una señal bastante clara de que el equilibrio del cluster se ha complicado.
En cristiano. Si ya estás en este punto, no es el momento ideal para hacer movimientos despreocupados que fuercen más redistribución.
OSD_FLAGS#
En la salida aparece una advertencia porque un host conserva flags como noout.
Esto me parece uno de los clásicos del homelab. Pones una flag temporal para mantenimiento, te juras que luego la quitas y un día más tarde el cluster sigue viviendo con ella mientras tú ya estás pensando en otra cosa.
No siempre rompe nada por sí sola. Pero cambia el comportamiento del cluster y, sobre todo, cambia cómo debes interpretar otros síntomas. Si hay flags activas, la foto ya no es la de una operación normal. Y a mí eso me gusta recordármelo cuanto antes.
PG_DEGRADED#
Aquí no hay mucha poesía.
Si ceph health detail me dice que hay objetos degradados y una PG atascada en active+undersized+degraded, yo lo apunto mentalmente como un problema real, no como ruido administrativo.
Además, en este caso la PG llevaba varios días así. Ese detalle pesa bastante. No es un susto de dos minutos por un reinicio reciente. Es una herida que sigue abierta.
PG_NOT_DEEP_SCRUBBED y PG_NOT_SCRUBBED#
Estos avisos no siempre son lo más urgente del mundo, pero tampoco me gusta verlos acumulados cuando ya hay otros problemas de fondo.
El scrub retrasado no me asusta tanto como una PG degradada, pero sí me dice que el cluster no está pasando por su rutina normal con la disciplina que me gustaría. Si además coincide con backfillfull, flags raras y redundancia tocada, la lectura global empeora.
POOL_BACKFILLFULL#
Cuando el aviso escala a pools, ya no pienso en el problema como una rareza aislada de un disco. Pienso en un margen de maniobra más estrecho para el conjunto.
Y eso, en un cluster que soporta almacenamiento de VMs, me parece suficiente motivo para no improvisar.
cuándo sigo trabajando y cuándo freno#
Esta es la parte práctica. Que haya HEALTH_WARN no significa siempre que debas congelar la vida entera del homelab. A veces es una advertencia asumible, conocida y bajo control.
Pero yo sí freno si veo alguno de estos patrones.
- PGs degradadas o undersized que no son flor de un reinicio reciente
- flags olvidadas después de una ventana de mantenimiento
- OSDs o pools en
backfillfull - scrubs retrasados junto a más avisos serios
- cualquier estado en el que tocar nodos vaya a reducir todavía más el margen
Si, en cambio, el cluster está HEALTH_OK o el warning es muy acotado, reciente y entendido, sigo con bastante más tranquilidad.
La palabra clave para mí es entendimiento. No necesito pureza absoluta. Necesito saber por qué el cluster me está avisando y qué riesgo real estoy comprando si sigo adelante.
la rutina corta que suelo hacer con Ceph en Proxmox#
Mi secuencia típica no tiene demasiado misterio.
ceph -sceph health detail- GUI de Ceph en Proxmox para cruzar la foto
- revisión de OSDs o de capacidad si el warning apunta ahí
- ya luego decisiones de mantenimiento
Me interesa empezar así porque el orden impide una trampa muy común. Irse a mirar gráficas, paneles y métricas finas antes de aceptar el diagnóstico básico que el propio cluster ya te está regalando.
Si ceph -s ya viene torcido, no necesito una odisea de observabilidad para admitirlo.
lo que ceph -s no me resuelve#
Tampoco conviene pedirle milagros.
ceph -s no me dice por sí solo qué VM concreta va mal ni dónde está exactamente el cuello de botella. No sustituye mirar latencias, logs más largos, distribución por OSD o comportamiento real de los clientes. Tampoco me cuenta toda la historia de capacidad, de recuperación o de red.
Pero no le pido eso.
Le pido una lectura inicial con muchísima relación valor por segundo. Una que me diga si el cluster está sano, tocado o directamente en ese punto en el que seguir tocando cosas sin contexto es una forma muy creativa de generarte trabajo.
Y para eso sigue siendo de las mejores primeras miradas que hay.
mi conclusión#
ceph -s me gusta porque obliga a dejar de fantasear. Si el cluster está bien, lo verás rápido. Si viene arrastrando avisos serios, también. Y en ambos casos te ahorra una cantidad bastante indecente de diagnósticos teatrales.
La captura de este artículo me parece buen ejemplo de por qué no me basta con ver monitores en quorum y OSDs up e in. Todo eso puede ser cierto y, aun así, seguir teniendo una PG degradada, pools en backfillfull, flags de mantenimiento olvidadas y scrubs atrasados. Ceph sigue funcionando, sí. Pero no está pidiendo más experimentos.
Si usas Proxmox con Ceph, yo metería ceph -s al principio de cualquier revisión seria del storage compartido. No al final, cuando ya has tocado media casa. Al principio.
Porque cuando el cluster habla claro, la peor idea suele ser hablar tú por encima.
referencias#
- Documentación de Proxmox VE sobre Ceph
- Documentación oficial de Ceph sobre monitorización del cluster
- Post relacionado: Ceph en homelab: cuándo merece la pena y cuándo solo te roba horas
- Post relacionado: pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada