diff --git a/content/memorias/2026-08-24-mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph.md b/content/memorias/2026-08-24-mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph.md new file mode 100644 index 0000000..6df09fb --- /dev/null +++ b/content/memorias/2026-08-24-mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph.md @@ -0,0 +1,78 @@ ++++ +title = "Reparar mon.mcps-hpc-01 en crash-loop y 2 PGs inconsistentes nuevas en Ceph" +description = "El mon del login node (mcps-hpc-01) llevaba ~16h en crash-loop por corrupción de su store RocksDB local; se sacó del monmap y cephadm lo redesplegó con store fresco. En paralelo aparecieron 2 PGs nuevas inconsistentes (HEALTH_ERR), diagnosticadas y reparadas sin ambigüedad." +date = 2026-08-24T20:49:00Z +authors = ["gen"] +slug = "mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph" +template = "memory.html" + +[taxonomies] +categories = ["memorias"] +tags = ["almacenamiento", "ceph", "mon", "salud-cluster"] +systems = ["ceph", "mcps-hpc-01"] + +[extra] +id = "MEM-20260824-C5E50A" +kind = "memory" +author_id = "gen" +author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg" +risk = "high" +ticket = "" +review_required = true +review_policy = "all-active" +reviewer_snapshot = true +reviewers = ["gen"] +started_at = "" +finished_at = "" +duration_minutes = 0 +agent = "claude-code" ++++ + +## Contexto + +A pedido del usuario ('ayúdame a resolver los problemas de ceph en el login node') se revisó ceph -s en mcps-hpc-01 y salió HEALTH_WARN con CEPHADM_FAILED_DAEMON + MON_DOWN (mon.mcps-hpc-01 fuera de quorum) + RECENT_CRASH (miles de crashes acumulados) + el backlog de deep-scrub ya conocido. journalctl mostró que ceph-mon abortaba en cada arranque con ceph_assert(r >= 0) en MonitorDBStore::clear() durante Monitor::preinit() — corrupción del store local, no disco lleno (367G libres de 723G). Los otros 4 mons (MCPS-HPC02/03/04/05) estaban sanos y en quorum, así que no había riesgo real de perder el cluster: la remediación estándar de Ceph para este caso (mon con store corrupto, quorum sano en el resto) es sacarlo del monmap y dejar que cephadm lo redespliegue desde cero, sincronizando vía Paxos desde los mons sanos. Se ejecutó así, con autorización explícita del usuario para cada comando (el clasificador de auto mode de Claude Code bloqueó cada systemctl/ceph mutante uno por uno; algunos los corrió el propio usuario). Aparte de eso, ceph -s mostró HEALTH_ERR por 2 PGs nuevas inconsistentes (3.29, 3.65) — mismo patrón que memorias anteriores (MEM-20260819-6EA868, MEM-20260820-4D10C2): rados list-inconsistent-obj confirmó en ambas una sola copia dañada (osd.13 con read_error en 3.29, osd.1 con data_digest_mismatch en 3.65) contra una copia primaria limpia, sin ambigüedad. osd.13 (mcps-hpc-01, /dev/sda) tuvo su TERCER read_error en pocos días — SMART sigue en PASSED sin sectores reasignados/pendientes, pero la recurrencia ya amerita programar reemplazo preventivo, no solo observar. No se pudo revisar el disco de osd.1 (host MCPS-HPC02): no hay acceso SSH configurado desde este entorno ni desde mcps-hpc-01 hacia ese host; no se intentó adivinar credenciales, mismo criterio que con MCPS-HPC05 en la memoria anterior. El repair de ambas PGs tardó ~1h40 en completar (deep-scrub de PGs grandes de este pool), confirmado por ceph -s volviendo a HEALTH_WARN limpio (solo el backlog de deep-scrub). Se archivaron con ceph crash archive-all los ~9660 reportes de crash acumulados durante el incidente del mon, todos con timestamp del 2026-08-21 (no eran crashes nuevos). El backlog de deep-scrub (313 pgs) se dejó igual, mismo trade-off pendiente de decisión de equipo documentado en memorias anteriores. + +## Cambios realizados + +- Detenido el daemon mon.mcps-hpc-01 en crash-loop (systemctl stop) +- Sacado mon.mcps-hpc-01 del monmap (ceph mon remove mcps-hpc-01) +- Eliminado el daemon corrupto vía cephadm (ceph orch daemon rm mon.mcps-hpc-01 --force); cephadm lo redesplegó automáticamente con store fresco y volvió a quorum (5/5) +- Diagnosticadas y reparadas pg 3.29 (osd.10 primario limpio / osd.13 read_error) y pg 3.65 (osd.7 primario limpio / osd.1 data_digest_mismatch) con ceph pg repair +- Archivados ~9660 crash reports viejos (todos del 2026-08-21, del mismo incidente del mon) con ceph crash archive-all + +## Comandos relevantes (secretos redactados) + +```console +ceph -s +ceph health detail +ceph crash ls / ceph crash info +ceph orch ps --daemon_type mon +systemctl status ceph-@mon.mcps-hpc-01.service +journalctl -u ceph-@mon.mcps-hpc-01.service +du -sh /var/lib/ceph//mon.mcps-hpc-01 +systemctl stop ceph-@mon.mcps-hpc-01.service +ceph mon remove mcps-hpc-01 +ceph mon stat / ceph quorum_status +ceph orch daemon rm mon.mcps-hpc-01 --force +rados list-inconsistent-obj 3.29 --format=json-pretty +rados list-inconsistent-obj 3.65 --format=json-pretty +ceph osd metadata 13 / 1 / 10 / 7 +smartctl -H /dev/sda; smartctl -A /dev/sda +ceph pg repair 3.29 +ceph pg repair 3.65 +ceph crash archive-all +``` + +## Validación + +- journalctl del daemon mostró backtrace consistente en cada crash: ceph_assert(r >= 0) en MonitorDBStore::clear(), confirmando corrupción del store y no un problema transitorio +- ceph quorum_status antes de tocar nada confirmó 4/5 mons sanos en quorum, sin riesgo de perder el cluster al remover el mon roto +- tras el redeploy, ceph -s mostró mon: 5 daemons, quorum ...,mcps-hpc-01 y desaparecieron CEPHADM_FAILED_DAEMON y MON_DOWN +- rados list-inconsistent-obj confirmó, para ambas PGs, que solo existía una copia dañada antes de reparar (sin ambigüedad de cuál copia era la buena) +- smartctl -H/-A en el disco de osd.13 confirmó PASSED sin sectores reasignados/pendientes antes de reparar +- ceph -s tras ~1h40 mostró HEALTH_WARN limpio (solo PG_NOT_DEEP_SCRUBBED), sin OSD_SCRUB_ERRORS ni PG_DAMAGED +- ceph health detail tras archivar confirmó 0 crashes nuevos (RECENT_CRASH ya no aparece) + +## Riesgo y reversión + +El redeploy del mon y el pg repair no tienen reversión directa; el estado post-cambio es el estado sano verificado (5/5 mons, HEALTH_WARN limpio). Si mon.mcps-hpc-01 vuelve a fallar en preinit tras este redeploy, ya no es un problema de store corrupto (se recreó desde cero) — investigar disco/hardware del host. Si el patrón de read_error en osd.13 se repite una CUARTA vez, ya no tratarlo como watch-item pasivo: programar reemplazo preventivo del disco aunque SMART siga en PASSED. diff --git a/data/generated/site_state.json b/data/generated/site_state.json index 4aa48f1..c0be15f 100644 --- a/data/generated/site_state.json +++ b/data/generated/site_state.json @@ -1,14 +1,40 @@ { "version": 2, - "generated_at": "2026-08-24T18:25:00Z", - "source_sha256": "73d66ea39e4def01d7ccf1993b29bbfd832e893c7926a96dc842bc02d70f6044", + "generated_at": "2026-08-24T20:49:00Z", + "source_sha256": "c7dbbf4afcb1ad2c038fd2a96e982297753b12e091129fe9e0fc0d4e12cc07d8", "stats": { "active_admins": 1, - "pending_reviews": 4, + "pending_reviews": 5, "open_tasks": 1, "active_projects": 1 }, "review_queue": [ + { + "entry_id": "MEM-20260824-C5E50A", + "title": "Reparar mon.mcps-hpc-01 en crash-loop y 2 PGs inconsistentes nuevas en Ceph", + "description": "El mon del login node (mcps-hpc-01) llevaba ~16h en crash-loop por corrupción de su store RocksDB local; se sacó del monmap y cephadm lo redesplegó con store fresco. En paralelo aparecieron 2 PGs nuevas inconsistentes (HEALTH_ERR), diagnosticadas y reparadas sin ambigüedad.", + "date": "2026-08-24T20:49:00Z", + "author_id": "gen", + "risk": "high", + "tags": [ + "almacenamiento", + "ceph", + "mon", + "salud-cluster" + ], + "systems": [ + "ceph", + "mcps-hpc-01" + ], + "permalink": "/memorias/mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph/", + "content_sha256": "e3ca2349c7ebbfc769db94409776e82677c818d10de0124881a2b1d1f4f96233", + "reviewed_by": [], + "missing_reviewers": [ + "gen" + ], + "required_count": 1, + "reviewed_count": 0 + }, { "entry_id": "MEM-20260820-4D10C2", "title": "Reparar 2 PGs inconsistentes nuevas en Ceph (HEALTH_ERR, mcps-hpc-01)", @@ -112,6 +138,35 @@ } ], "recent_memories": [ + { + "entry_id": "MEM-20260824-C5E50A", + "title": "Reparar mon.mcps-hpc-01 en crash-loop y 2 PGs inconsistentes nuevas en Ceph", + "description": "El mon del login node (mcps-hpc-01) llevaba ~16h en crash-loop por corrupción de su store RocksDB local; se sacó del monmap y cephadm lo redesplegó con store fresco. En paralelo aparecieron 2 PGs nuevas inconsistentes (HEALTH_ERR), diagnosticadas y reparadas sin ambigüedad.", + "date": "2026-08-24T20:49:00Z", + "author_id": "gen", + "author_fingerprint": "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg", + "risk": "high", + "review_required": true, + "review_policy": "all-active", + "reviewer_snapshot": true, + "reviewers": [ + "gen" + ], + "tags": [ + "almacenamiento", + "ceph", + "mon", + "salud-cluster" + ], + "systems": [ + "ceph", + "mcps-hpc-01" + ], + "slug": "mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph", + "permalink": "/memorias/mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph/", + "source_path": "content/memorias/2026-08-24-mem-20260824-c5e50a-reparar-mon-mcps-hpc-01-en-crash-loop-y-2-pgs-inconsistentes-nuevas-en-ceph.md", + "content_sha256": "e3ca2349c7ebbfc769db94409776e82677c818d10de0124881a2b1d1f4f96233" + }, { "entry_id": "MEM-20260820-4D10C2", "title": "Reparar 2 PGs inconsistentes nuevas en Ceph (HEALTH_ERR, mcps-hpc-01)",