Proxmox Ceph «monitor caído/fuera de quórum»: restaurar monitores y quórum sin pánico

Cómo falla realmente el quórum de monitores Ceph (modelo mental)

Los monitores de Ceph (MONs) no son «solo otro demonio». Son la fuente de verdad del clúster: el monmap (quiénes son los monitores), el osdmap (qué OSDs existen y dónde), el estado de autenticación (CephX) y un montón de estado de consenso que debe coincidir en una mayoría.

Los monitores forman quórum usando un algoritmo de consenso (Ceph ha usado mecanismos tipo Paxos históricamente y ha evolucionado con las versiones). En términos sencillos: los monitores deben poder hablar entre sí de forma fiable y ponerse de acuerdo sobre los mapas comprometidos más recientes. Si no pueden, prefieren dejar de ser autoritativos a mentir.

Qué suele significar «caído» vs «fuera de quórum»

• monitor caído: ese proceso de monitor no es alcanzable o no está en ejecución (o está bloqueado tan fuerte que podría considerarse apagado).
• fuera de quórum: el proceso está en ejecución, pero no forma parte de la mayoría que actualmente acuerda el estado. Puede estar particionado, con desfase horario, tener un monmap antiguo o tener el store dañado.
• sin quórum: el clúster está efectivamente ciego. Los OSDs pueden seguir sirviendo IO existentes por un tiempo, pero los cambios de estado y los informes de salud se vuelven limitados y riesgosos. Trátalo como «deja de improvisar».

La regla de oro

Nunca «arregles el quórum» borrando cosas hasta que sepas qué monitor tiene la verdad más reciente. Si borras el monitor equivocado, puedes convertir una caída recuperable en un proyecto de reconstrucción.

Aquí está la mentalidad operativa que quiero que adoptes: los monitores son el plano de control; los OSDs son el plano de datos. Puedes sobrevivir con redundancia en el plano de datos magullado. No puedes sobrevivir a un plano de control que esté equivocado y confiado.

Una cita para colgar en la pared: La esperanza no es una estrategia. — General Gordon R. Sullivan. En operaciones, eso no es motivación; es un recordatorio para verificar antes de cambiar.

Broma #1: Un monitor de Ceph fuera de quórum es como un gerente fuera de la reunión: sigue enviando correos, pero nadie los toma en serio.

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

Esta es la secuencia para «detener la hemorragia». No empieces reconstruyendo monitores. Empieza demostrando el modo de fallo.

Primero: ¿hay quórum en absoluto?

Si al menos un monitor está en quórum, tienes un ancla. Si ninguno lo está, tu trabajo es identificar el store de monitor sobreviviente más autoritativo y restaurarlo, no crear una nueva realidad.

Segundo: ¿es un problema de red o de hora que se disfraza de Ceph?

Las particiones de red y la deriva del tiempo son las dos primeras causas de «todo parece roto». Revísalas antes de tocar los datos del mon.

Tercero: ¿está sano el store del monitor (espacio en disco, sistema de ficheros, corrupción)?

Los monitores son sensibles a eventos de disco lleno y problemas de sistema de archivos. Un monitor puede estar «en ejecución» pero efectivamente muerto porque no puede comprometer cambios.

Cuarto: ¿el monmap/FSID es incorrecto o está desactualizado en un nodo?

Una trampa común en Proxmox/Ceph: un nodo tiene configuración sobrante de un clúster anterior o fue reinstalado, y ahora habla con confianza con una identidad equivocada.

Quinto: Considera reconstruir/crear solo ahora

Reconstruir un monitor está bien cuando tienes quórum y reemplazas un miembro. Es peligroso cuando no tienes quórum y estás adivinando.

Datos interesantes y contexto (por qué los monitores son delicados)

1. El nombre Ceph viene de un monstruo marino mitológico (Cephalopod). Es un nombre simpático para un sistema que te morderá si operas de forma descuidada.
2. Los monitores de Ceph usaron durante años un mecanismo de consenso basado en Paxos; el objetivo del diseño es consistencia fuerte para los mapas, no «siempre arriba a cualquier precio».
3. La regla de “número impar de MONs” no es superstición. El consenso por mayoría significa que 3 MONs toleran 1 fallo; 4 MONs también toleran 1 fallo; 5 toleran 2.
4. La deriva del tiempo es una falla de primera clase en sistemas distribuidos. Los monitores pueden negarse a participar si el desfase de reloj rompe las suposiciones de lease/timeout.
5. El estado CephX se almacena y sirve desde los monitores; un monitor con keyrings rotos puede parecer «errores aleatorios de permisos» por todo el clúster.
6. Los monitores almacenan mapas críticos en disco local; no son «stateless». Trata al store del monitor como una pequeña base de datos replicada por consenso.
7. La integración de Proxmox facilita el despliegue, pero también facilita olvidar que las herramientas del ciclo de vida de Ceph existen (y son importantes).
8. Históricamente, “corrupción del store del mon” a menudo ha sido consecuencia de disco lleno, pérdida de energía o bugs del sistema de archivos—rara vez «Ceph decidió olvidar».

Tareas prácticas: comandos, salida esperada y decisiones (12+)

Estas son tareas reales que ejecuto durante un incidente. Cada una tiene: comando, qué significa la salida y qué decisión tomar después. Ejecútalas en un nodo monitor salvo que se indique lo contrario.

Task 1: Check current quorum view (from any node with ceph.conf + key)

cr0x@server:~$ ceph -s
  cluster:
    id:     0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
    health: HEALTH_WARN
            1/3 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2 (age 5m), out of quorum: mon3
    mgr: mon1(active), standbys: mon2
    osd: 12 osds: 12 up, 12 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 40 TiB / 53 TiB avail
    pgs:     256 active+clean

Significado: Tienes quórum (mon1, mon2). mon3 es el paciente, no el cirujano.

Decisión: Repara/reincorpora mon3 usando el quórum sano. Evita operaciones de “forzar”.

Task 2: If ceph -s hangs, test direct MON connectivity

cr0x@server:~$ timeout 5 ceph -s; echo $?
124

Significado: El código de salida 124 = timeout. A menudo es “sin quórum” o el cliente no puede alcanzar monitores.

Decisión: Pasa a comprobaciones de red/hora y a logs locales del mon. No empieces a cambiar mapas de Ceph desde un host que ni siquiera puede hablar con los MONs.

Task 3: Identify the monitor endpoints from config

cr0x@server:~$ grep -E '^(fsid|mon_host|public_network|cluster_network)' /etc/pve/ceph.conf
fsid = 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
mon_host = 10.10.10.11 10.10.10.12 10.10.10.13
public_network = 10.10.10.0/24
cluster_network = 10.10.20.0/24

Significado: Tienes las IP previstas. Si la IP de un monitor cambió, “existirá” pero nunca será encontrada.

Decisión: Confirma que esas IPs son correctas en cada nodo. Si no, arregla la red/DNS y solo entonces toca Ceph.

Task 4: Check MON systemd state (is it actually running?)

cr0x@server:~$ systemctl status ceph-mon@mon3 --no-pager
● ceph-mon@mon3.service - Ceph monitor daemon
     Loaded: loaded (/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:11:32 UTC; 2min 12s ago
    Process: 18231 ExecStart=/usr/bin/ceph-mon -f --cluster ceph --id mon3 --setuser ceph --setgroup ceph (code=exited, status=1/FAILURE)

Significado: No es un misterio de quórum; es una falla de servicio en mon3.

Decisión: Lee los logs, comprueba espacio en disco, revisa el mon store y luego reinicia.

Task 5: Read recent MON logs for the real reason

cr0x@server:~$ journalctl -u ceph-mon@mon3 -n 80 --no-pager
Dec 26 09:11:31 mon3 ceph-mon[18231]: mon.ceph-mon@mon3: error opening mon data directory at '/var/lib/ceph/mon/ceph-mon3': No space left on device
Dec 26 09:11:31 mon3 systemd[1]: ceph-mon@mon3.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:32 mon3 systemd[1]: ceph-mon@mon3.service: Failed with result 'exit-code'.

Significado: Disco lleno. Clásico. Predecible. Solucionable.

Decisión: Libera espacio de forma segura, luego ejecuta una comprobación de integridad del sistema de archivos si procede, y después reinicia el MON.

Task 6: Verify filesystem capacity and inode pressure

cr0x@server:~$ df -h /var/lib/ceph/mon/ceph-mon3
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   50G     0 100% /

cr0x@server:~$ df -i /var/lib/ceph/mon/ceph-mon3
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       3276800 220000 3056800    7% /

Significado: El problema es capacidad, no inodos.

Decisión: Elimina la basura correcta (logs, kernels antiguos, volcados de fallos). No borres archivos del store del monitor por ira.

Task 7: Check time sync (quorum hates time travelers)

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

Significado: Este nodo está sincronizado.

Decisión: Ejecuta esto en cada MON. Si alguno muestra “synchronized: no” o gran deriva, arregla NTP/chrony antes de reintentar el quórum.

Task 8: Verify MON ports are reachable between monitors

cr0x@server:~$ nc -vz 10.10.10.11 3300
Connection to 10.10.10.11 3300 port [tcp/*] succeeded!

cr0x@server:~$ nc -vz 10.10.10.12 6789
Connection to 10.10.10.12 6789 port [tcp/*] succeeded!

Significado: Ceph moderno usa 3300 (msgr2); compatibilidad antigua usa 6789 (msgr1). Si esto falla, el quórum no volverá hasta arreglar red/firewalls.

Decisión: Si está bloqueado: arregla reglas de firewall, VLANs, MTU, enrutamiento. Si está abierto: procede a las comprobaciones del mon store.

Task 9: Confirm the MON identity directory exists and permissions are sane

cr0x@server:~$ ls -ld /var/lib/ceph/mon/ceph-mon3
drwxr-x--- 8 ceph ceph 4096 Dec 26 09:02 /var/lib/ceph/mon/ceph-mon3

Significado: El directorio existe y pertenece a ceph.

Decisión: Si la propiedad es incorrecta (común tras restauraciones manuales), arréglala antes de reiniciar: el monitor no se auto-reparará por errores de permisos.

Task 10: See who the cluster thinks the monitors are (mon dump)

cr0x@server:~$ ceph mon dump
epoch 21
fsid 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
last_changed 2025-12-26T08:58:07.123456+0000
created 2025-11-02T12:12:01.000000+0000
min_mon_release 18 (reef)
election_strategy: 1
0: [v2:10.10.10.11:3300/0,v1:10.10.10.11:6789/0] mon.mon1
1: [v2:10.10.10.12:3300/0,v1:10.10.10.12:6789/0] mon.mon2
2: [v2:10.10.10.13:3300/0,v1:10.10.10.13:6789/0] mon.mon3

Significado: mon3 sigue en el monmap. Bien. Quieres que se reincorpore, no que se vuelva a añadir desde cero salvo que sea necesario.

Decisión: Si una IP/hostname es incorrecta aquí, tendrás que arreglar el direccionamiento (o, en último recurso, eliminar/reagregar el monitor correctamente).

Task 11: Check monitor store health hints (fsck is for filesystems; this is for MONs)

cr0x@server:~$ ceph-mon -i mon3 --cluster ceph --mon-data /var/lib/ceph/mon/ceph-mon3 --check
ceph-mon: mon data is consistent

Significado: El store del monitor parece consistente para iniciar.

Decisión: Reinicia el servicio. Si la comprobación reporta corrupción, detente y elige una ruta de reconstrucción en lugar de reiniciar repetidamente.

Task 12: Restart the MON and watch it join quorum

cr0x@server:~$ systemctl restart ceph-mon@mon3
cr0x@server:~$ ceph -s
  cluster:
    id:     0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 10s)
    mgr: mon1(active), standbys: mon2
    osd: 12 osds: 12 up, 12 in

Significado: De vuelta en quórum. Has terminado con la parte urgente.

Decisión: Ahora haz el seguimiento: ¿por qué se llenó el disco? Añade alertas y housekeeping para que no vuelva a ocurrir un viernes por la noche.

Task 13: If no quorum, inspect local mon’s view without contacting the cluster

cr0x@server:~$ ceph-mon -i mon1 --cluster ceph --show_monmap | head
dumped monmap epoch 21
fsid 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
last_changed 2025-12-26T08:58:07.123456+0000
created 2025-11-02T12:12:01.000000+0000

Significado: Puedes leer el monmap desde el store local. Eso ayuda a demostrar qué store está intacto.

Decisión: Compara entre nodos; la época más reciente y un FSID consistente son tus pistas para «qué store de monitor confiar».

Task 14: Confirm FSID matches across Proxmox ceph.conf and mon store

cr0x@server:~$ ceph fsid
0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f

Significado: Si esto devuelve un FSID diferente al de /etc/pve/ceph.conf, estás mezclando clústeres o configs.

Decisión: Detente y reconcilia la deriva de configuración antes de «arreglar» otra cosa.

Task 15: Validate that the monitor is listening on expected addresses

cr0x@server:~$ ss -lntp | egrep ':(3300|6789)\s'
LISTEN 0      4096         10.10.10.13:3300       0.0.0.0:*    users:(("ceph-mon",pid=19012,fd=20))
LISTEN 0      4096         10.10.10.13:6789       0.0.0.0:*    users:(("ceph-mon",pid=19012,fd=21))

Significado: Está enlazado correctamente. Si escucha solo en 127.0.0.1 o en la interfaz equivocada, has encontrado al culpable.

Decisión: Arregla la red del host y/o public_network de Ceph; reinicia.

Task 16: Check for firewall policy blocking intra-cluster traffic

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | head
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N PVEFW-Drop
-N PVEFW-Input

Significado: Tienes una postura por defecto DROP. Está bien, pero solo si los puertos Ceph están permitidos entre MONs.

Decisión: Si esto cambió recientemente, inspecciona los conjuntos de reglas y asegúrate de que TCP 3300 y (si es necesario) 6789 estén permitidos en la red pública de Ceph.

Task 17: Proxmox Ceph tooling sanity check (don’t fight your platform)

cr0x@server:~$ pveceph status
Cluster FSID: 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
MONs: 3, quorum: mon1, mon2, mon3
OSDs: 12 up/12 in
MGR: mon1 (active)

Significado: Confirma que la vista de Proxmox coincide con la de Ceph.

Decisión: Si discrepan, sospecha deriva de configuración entre /etc/pve, /etc/ceph local y lo que realmente usa tu CLI.

Rutas de recuperación: de “un mon caído” a “sin quórum”

Escenario A: Un monitor caído, el quórum aún existe (mejor caso)

Este es el fallo «normal». Tienes suficientes monitores para mantener la mayoría. Tu objetivo es devolver el monitor faltante al servicio o reemplazarlo limpiamente.

• Arregla la causa local (disco lleno, servicio caído, nodo arrancado con un kernel distinto, NIC inestable).
• Valida sincronía de tiempo y puertos de red.
• Arranca el monitor y obsérvalo reincorporarse.

Sé estricto: si un store de monitor está corrupto, no sigas reiniciándolo esperando que «eventualmente funcione». Ahí es donde obtienes quórum con flapping e inestabilidad crónica.

Escenario B: Dos monitores caídos en un clúster de 3 mon (sin quórum)

Ahora estás en modo «restaurar mayoría». Con 3 MONs necesitas 2. La recuperación más segura suele ser:

1. Elige el nodo monitor que parezca más intacto (almacenamiento más estable, menos tocado, probablemente con el mon store intacto).
2. Haz que ese monitor arranque limpiamente y valida su store.
3. Levanta un monitor adicional para alcanzar quórum.
4. Una vez exista quórum, reconstruye cualquier monitor restante desde el quórum sano.

Si solo rebotas servicios al azar, puedes acabar con cada monitor creyendo en un mundo distinto. Los sistemas de consenso no premian la danza interpretativa.

Escenario C: Todos los monitores “up” pero ninguno en quórum (flapping o split brain)

Esto suele ser partición de red o desfase horario. A veces es un desajuste de MTU en la red pública de Ceph: sondas pequeñas pasan, mensajes grandes fallan y todo parece «mayormente alcanzable».

Prioriza:

• Comprobación de sincronía de relojes entre todos los MONs.
• Conectividad bidireccional en 3300/6789 entre todos los MONs.
• Corrección de interfaz/IP (sin IPs duplicadas, sin ARP obsoletos, sin sorpresas de VRRP).
• Revisión de cambios en firewall (Proxmox o upstream).

Escenario D: Corrupción del store del monitor (el desagradable)

Si tienes quórum, reconstruir un solo monitor es rutinario: páralo, aparta su store, recréalo desde el quórum y arráncalo. Si no tienes quórum, la recuperación por corrupción trata de encontrar el store sobreviviente menos malo y reconstituir el quórum desde él.

En la práctica, harás una de las siguientes:

• Reconstruir un monitor desde un quórum existente (seguro).
• Recrear un monitor nuevo y unirlo al quórum (seguro si existe quórum).
• Recuperar el quórum arrancando el mejor store sobreviviente y añadiendo otros (arriesgado pero a veces necesario).

Broma #2: Un store de monitor corrupto es como una hoja de cálculo corrupta—alguien sugerirá «simplemente reescríbelo», y esa persona no debería tener acceso a producción.

Listas de verificación / plan paso a paso (hacer esto, no intuiciones)

Checklist 1: Cuando aún tienes quórum (reparar un MON individual)

1. Confirma que existe quórum con ceph -s. Si cuelga, cambia a diagnósticos locales.
2. En el nodo MON fallido: systemctl status ceph-mon@<id> y journalctl -u ....
3. Arregla la causa raíz: disco lleno, permisos, NIC caído, hora desincronizada, regla de firewall.
4. Ejecuta chequeo del store: ceph-mon -i <id> --check (donde esté soportado) para evitar flapping.
5. Reinicia el MON y confirma que está escuchando (ss -lntp).
6. Confirma la reincorporación en ceph -s y ceph quorum_status.
7. Realiza trabajo de seguimiento: monitoriza tendencias de uso de disco, añade alertas, prevén recurrencias.

Checklist 2: Cuando no tienes quórum (restaurar mayoría de forma segura)

1. Deja de cambiar cosas a nivel de clúster. Tu objetivo es encontrar uno o dos stores de mon buenos.
2. Elige un nodo candidato “mejor monitor” (almacenamiento más estable, menos tocado, probablemente con el mon store intacto).
3. En cada nodo MON: comprueba espacio en disco (df -h), sincronía de hora (timedatectl) y errores recientes (journalctl).
4. Confirma consistencia de FSID entre /etc/pve/ceph.conf y la vista local del store (ceph-mon --show_monmap).
5. Arregla particiones de red primero (puertos 3300/6789). Si los monitores no pueden hablar, ninguna reconstrucción ayudará.
6. Arranca un monitor limpiamente. Observa los logs. Buscas comportamiento de “formando quórum”, no solo “activo (en ejecución)”.
7. Levanta un segundo monitor para alcanzar la mayoría. Dos MONs de tres forman quórum.
8. Una vez exista quórum: reconstruye cualquier monitor restante correctamente desde el quórum en lugar de intentar resucitar estados corruptos.

Checklist 3: Reconstruir un monitor cuando existe quórum (reemplazo controlado)

No te doy intencionalmente un comando de “borrar y rehacer” en uno solo. Las reconstrucciones son seguras cuando las haces deliberadamente y verificas en cada paso.

1. Verifica quórum y salud: ceph -s, ceph mon dump.
2. Detén el MON objetivo: systemctl stop ceph-mon@monX.
3. Mueve aparte el store antiguo: renombra el directorio del mon en lugar de borrarlo. Eso te da una palanca de reversión.
4. Recrea el store del monitor desde los mapas actuales del clúster usando la herramienta adecuada para tu versión de Ceph/Proxmox.
5. Inicia el MON y verifica la unión mediante ceph -s y ceph quorum_status.

Si tu organización espera runbooks, escribe esto con tus IDs reales de monitor y rutas. Nada envejece peor que “monX” durante una verdadera caída.

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

1) Síntoma: «monitor caído» tras un reinicio rutinario

Causa raíz: Directorio de datos del monitor ausente/movido, permisos cambiados, o el nodo arrancó con un mapeo de hostname/ID diferente al esperado.

Solución: Valida que /var/lib/ceph/mon/ceph-<id> exista y pertenezca a ceph:ceph. Confirma que el ID del monitor coincide con el nombre de la unidad de servicio. Reinicia y verifica puertos en escucha.

2) Síntoma: «fuera de quórum» pero el servicio está activo

Causa raíz: Partición de red, firewall bloqueando 3300/6789, desajuste de MTU o enrutamiento asimétrico entre MONs.

Solución: Prueba conectividad MON-a-MON usando nc -vz en 3300 y 6789. Revisa switch/VLAN/MTU y reglas de firewall. No reconstruyas monitores por un problema de red.

3) Síntoma: comandos ceph cuelgan o hacen timeout solo desde algunos nodos

Causa raíz: Nodos cliente apuntando a direcciones de monitor obsoletas en la configuración, o DNS que devuelve IPs diferentes. A veces es un lío de doble pila (IPv6 medio configurado).

Solución: Confirma que mon_host es correcto en la configuración que el nodo realmente usa. Estandariza en IPs explícitas si tu DNS no es disciplinado.

4) Síntoma: monitores entran y salen del quórum cada pocos minutos

Causa raíz: Deriva del tiempo, host sobrecargado, pérdida intermitente de paquetes o latencia de disco que provoca commits lentos.

Solución: Revisa timedatectl entre MONs. Inspecciona dmesg por errores de almacenamiento. Busca CPU steal o IO wait. Arregla la plataforma, no el síntoma.

5) Síntoma: después de “arreglar” un monitor, Ceph muestra FSID incorrecto o errores raros de autenticación

Causa raíz: Clústeres mezclados: /etc/ceph/ceph.conf obsoleto, keyring equivocado, o un nodo reinstalado que generó nueva configuración de clúster en otra ruta.

Solución: Verifica que el FSID de /etc/pve/ceph.conf y ceph fsid coincidan. Asegúrate de que tu CLI use la configuración y keyring previstos. Elimina configs obsoletos que enmascaren las gestionadas por Proxmox.

6) Síntoma: el monitor no arranca, el log dice “No space left on device”

Causa raíz: Sistema de ficheros root lleno (a menudo logs, volcados de fallos o backups almacenados localmente).

Solución: Libera espacio de forma segura. Luego reinicia. Si el store del monitor se vio afectado, ejecuta una comprobación de consistencia si está disponible y vigila errores repetidos.

7) Síntoma: el MON arranca pero sale inmediatamente con errores relacionados al store

Causa raíz: Corrupción de base de datos del monitor, a veces tras pérdida de energía o errores de disco.

Solución: Si existe quórum, reconstruye ese monitor desde el quórum y conserva el store antiguo como evidencia. Si no hay quórum, identifica el store más intacto entre los monitores y restaura el quórum desde él.

Tres microhistorias corporativas desde las trincheras de monitores

Microhistoria 1: El incidente causado por una suposición errónea

Tenían un clúster Proxmox ordenado de tres nodos: tres monitores, muchos OSDs y la creencia de que «los monitores son ligeros, así que podemos ponerlos donde sea». Un monitor vivía en un nodo que también ejecutaba un runner de CI ruidoso y una pila de métricas que escribía como si le pagaran por inode.

Una actualización de kernel requirió una ventana de reinicio. El reinicio fue bien. Luego, diez minutos después, la salud de Ceph se torció: un monitor caído, otro con «operaciones lentas» y el tercero fuera de quórum. El on-call asumió que era un bug de Ceph porque «nada cambió excepto un reinicio». Esa suposición les hizo perder la primera hora.

La realidad: el reinicio arrancó el runner de CI, que inmediatamente empezó a saturar disco en ese nodo. La latencia de commit del monitor se disparó, las elecciones empezaron a expirar y el quórum se convirtió en una puerta giratoria. Nada estaba «mal» con Ceph. La plataforma estaba violando la necesidad del monitor de IO predecible y aburrido.

La solución no fue exótica. Movieron el runner de CI fuera del host del monitor, fijaron el IO del monitor a almacenamiento más rápido y pusieron alertas en uso del sistema root y latencia de disco. La lección del postmortem fue vergonzantemente simple: los monitores son «ligeros» solo si no castigues sus discos.

Microhistoria 2: La optimización que salió mal

Otra organización quiso endurecer la seguridad. Habilitaron una postura de firewall estricta en Proxmox y se felicitaron por «cerrar el clúster». Funcionó en el sentido de que nada obvio se rompió inmediatamente. Los monitores se mantuvieron en quórum durante semanas.

Entonces un mantenimiento de red provocó que un monitor se reiniciara. Cuando volvió, no pudo reincorporarse al quórum. El servicio estaba en ejecución, los logs parecían vagamente de red y la salud de Ceph gritaba sobre un monitor fuera. El equipo siguió el playbook estándar: reiniciar, reinit, incluso movieron el directorio de datos del monitor. Aún fuera.

La optimización fallida fue sutil: las reglas del firewall permitían conexiones establecidas pero faltaban permisos explícitos para los puertos de monitor en la red de Ceph. En estado estacionario funcionaba porque las sesiones ya estaban abiertas. Tras un reinicio, el monitor tuvo que establecer nuevas conexiones. No pudo. El quórum no falló instantáneamente; falló cuando la “optimización” se topó con un cambio de estado real.

La solución eventual fue sencilla: reglas de firewall explícitas y auditadas que permitan tráfico MON-a-MON en las interfaces correctas, más una cláusula en la revisión de cambios: «Si tocas firewalling, valida puertos Ceph entre monitores». Mantuvieron la postura de seguridad, pero dejaron de depender de la persistencia afortunada de conexiones.

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

Este equipo hizo algo profundamente poco glamuroso: guardaron un pequeño archivo de “datos del clúster” en su repo interno. Listaba el FSID de Ceph, IDs de monitores, IPs de monitores, las redes públicas/cluster y la ubicación de los directorios de datos de monitores. También listaba cómo se ve lo “normal” para ceph -s y qué host suele ser el manager activo.

Cuando un host de monitor sufrió una falla de almacenamiento y quedó en bucle de reinicios, el on-call no tuvo que adivinar qué monitores existían ni qué IPs debían tener. Verificaron el quórum, confirmaron la identidad del monitor muerto y supieron de inmediato que todavía tenían mayoría. Sin drama. Lo trataron como reemplazar un miembro de RAID fallado: aislar, reemplazar, reintroducir.

La ganancia de segundo orden: durante el reemplazo evitaron el error humano más común—reusar accidentalmente un ceph.conf antiguo de otro entorno. Su archivo de “datos del clúster” incluía el FSID. Lo comprobaron antes de empezar. Coincidía. Prosiguieron.

No fue heroico. Fue aburrido. Y les salvó de aquella clase de caída donde todos aprenden la CLI de Ceph leyendo logs como hojas de té.

Preguntas frecuentes

1) ¿Cuál es el número mínimo de monitores que debería ejecutar?

Tres. Siempre tres para clústeres reales. Uno es laboratorio. Dos es un mal compromiso: no puedes tolerar una falla sin perder quórum.

2) ¿Por qué Ceph insiste en un número impar de monitores?

Por la mayoría de consenso. Con 3 puedes perder 1. Con 5 puedes perder 2. Con 4 aún solo puedes perder 1, así que pagaste complejidad extra sin mayor tolerancia a fallos.

3) ¿Puedo ejecutar monitores en los mismos nodos que OSDs?

Sí, es habitual. Pero mantén el almacenamiento del monitor predecible: evita llenar discos root, evita vecinos ruidosos y no pongas stores de MON en SSDs consumidores inestables y luego te sorprendas.

4) «ceph -s» cuelga. ¿Significa automáticamente que no hay quórum?

No automáticamente, pero es una fuerte señal. También puede significar que tu nodo no alcanza a ningún monitor por firewall/DNS/enrutamiento. Prueba TCP 3300/6789 a cada IP de monitor desde el nodo donde cuelga.

5) ¿Es seguro borrar un directorio de datos de monitor para “resetearlo”?

Sólo cuando tienes quórum y estás reconstruyendo deliberadamente ese monitor específico. Incluso entonces, muévelo aparte primero. Borrar el store equivocado durante un evento sin quórum es como fabricar una caída más larga.

6) ¿Cómo sé si es deriva del tiempo versus problemas de red?

La deriva del tiempo produce un tipo especial de caos: elecciones intermitentes, «fuera de quórum» con conectividad aparentemente buena y logs quejándose de timeouts de forma aleatoria. Revisa timedatectl entre MONs y arregla NTP/chrony primero. Los problemas de red aparecen claramente con fallos en las comprobaciones de puertos y problemas de alcance consistentes.

7) ¿Proxmox cambia cómo funciona la recuperación de monitores de Ceph?

Los fundamentos son los mismos. Proxmox te da herramientas convenientes y guarda la configuración de Ceph en /etc/pve, lo cual es genial hasta que accidentalmente usas un /etc/ceph local obsoleto. Tu recuperación sigue dependiendo de quórum, red, hora y un monmap correcto.

8) ¿En qué debo alertar para evitar incidentes de quórum de monitores?

Uso de disco en hosts de monitor (especialmente root), estado de sincronía de hora, pérdida/latencia de paquetes entre monitores y salud del servicio ceph-mon@*. También alerta sobre “mon down” y eventos de “quorum changed”; son humo temprano.

9) Si perdí dos monitores en un clúster de 3, ¿puedo “forzar” quórum con uno?

En ocasiones puedes coaccionar un clúster en modos de emergencia según la versión y las herramientas, pero es peligroso y depende del contexto. Operativamente: restaura un segundo monitor en su lugar. El consenso por mayoría existe para evitar que te comprometas con la verdad equivocada.

10) ¿Por qué el disco lleno rompe tanto a los monitores?

Porque los monitores deben persistir actualizaciones de estado para ser autoritativos. Si no pueden escribir, no pueden participar con seguridad. Eso no es fragilidad de Ceph; es Ceph negándose a mentir.

Conclusión y próximos pasos

«monitor caído/fuera de quórum» se siente como un desastre específico de Ceph, pero la mayoría de las recuperaciones son trabajo de plataforma: arregla la presión de disco, la hora y la accesibilidad de la red, y luego deja que los monitores hagan su trabajo. Si existe quórum, reparas o reconstruyes un monitor desde la mayoría conocida y buena. Si no existe quórum, deja de improvisar y céntrate en restaurar una mayoría usando los stores de monitor más intactos.

Próximos pasos que pagan la renta:

• Pon los hosts de monitor en almacenamiento aburrido y fiable y evita que los sistemas root se llenen.
• Estandariza y audita reglas de firewall para los puertos de MON en la red de Ceph.
• Haz la sincronización horaria algo no negociable: alerta cuando cualquier monitor no esté sincronizado.
• Escribe tus datos del clúster (FSID, IDs de monitores, IPs, redes). No es glamuroso. Es efectivo.