Ceph con Proxmox es una combinación habitual en infraestructuras virtualizadas. En este artículo describo de forma práctica cómo debe planificar MON/OSD/MGR, dimensionar correctamente las Placement‑Groups (PGs) y diagnosticar y resolver sistemáticamente problemas de rendimiento. La palabra clave principal Ceph con Proxmox se coloca intencionadamente al principio: la integración influye en la operación, el monitoreo, la migración y el cumplimiento de los SLA.
Por qué la planificación de la arquitectura es importante en Ceph
Antes de integrar Ceph en Proxmox, debe entender la responsabilidad de los componentes. En resumen: los MONs (monitores) gestionan el quórum del clúster y la configuración; los OSDs (Object Storage Daemon) almacenan los datos y realizan replicación y scrubbing; los MGRs (manager) proporcionan el panel, la API y las métricas. Esta separación de funciones determina las decisiones de hardware, red y operación — y por tanto el rendimiento y la tolerancia a fallos.
Reglas básicas para el diseño de MON/OSD/MGR
La distribución de MONs, OSDs y MGRs afecta a la estabilidad y mantenibilidad. Reglas básicas:
- MONs: Siempre un número impar (al menos 3) para resiliencia del quórum; los MONs son livianos, pero requieren acceso de red estable.
- OSDs: Distribuya los OSDs entre hosts y failure‑domains (host, rack); los OSDs son críticos para I/O y constituyen el cuello de botella del sistema.
- MGRs: Al menos dos instancias MGR para redundancia del panel y de los exporters; la caída de un MGR afecta principalmente a la observabilidad, no a la consistencia.
Recomendación para clústeres típicos
Para instalaciones de Proxmox pequeñas a medianas (6–20 nodos) una configuración posible es: 3 MONs en hosts separados, 2 MGRs distribuidos, y distribuir los OSDs de modo que haya al menos tres OSDs por failure‑domain. Evite la co‑ubicación de MON/MGR con todos los OSDs de un rack para reducir el radio de impacto.
Ceph con Proxmox: medidas realistas de ajuste de rendimiento
El ajuste del rendimiento comienza con la medición. Los cuellos de botella de Ceph solo pueden entenderse con métricas, perfiles de I/O y pruebas controladas. Áreas típicas son la red, el dispositivo OSD, CPU/memoria en los OSDs y la configuración de PG (Placement‑Groups, grupos lógicos de distribución).
Configuraciones clave de Ceph y su efecto
- osd_memory_target (Ceph): Controla la huella de RAM de las estructuras de caché de los OSD — demasiado bajo → caída del rendimiento, demasiado alto → presión de memoria. Valores dependientes de la RAM de OSD y del número de PG.
- osd_recovery_max_active / osd_recovery_op_priority: Limitan las tareas de recuperación paralelas, reducen la carga de backfill a corto plazo, pero prolongan el tiempo de recuperación.
- osd_max_backfills: Limitación de backfills paralelos por OSD; útil en caso de saturación de red.
Recomendaciones (conservadoras)
Comience con valores predeterminados conservadores y ajuste de forma incremental. Valores de ejemplo que debería probar:
# Beispiel: vorsichtigere Recovery‑Limits setzen
ceph config set osd osd_recovery_max_active 2
ceph config set osd osd_max_backfills 1
# Memory‑Target nach OSD‑RAM anpassen (Beispiel 8GB RAM)
ceph config set osd osd_memory_target 5368709120 # 5GBPor qué: Estas configuraciones reducen la presión de I/O simultáneo sobre la red y la CPU, evitan picos de latencia a corto plazo y son reversibles. Pruebe y documente cada cambio.
Placement‑Groups (PGs): concepto, cálculo y pg_autoscaler
Los Placement‑Groups agrupan objetos y son la unidad atómica que CRUSH distribuye a los OSDs. El número de PGs influye en la distribución de datos, el tamaño del reequilibrado y la huella de memoria de los OSD.
Enfoque de cálculo y ejemplo práctico
Como regla general se consideran 50–200 PGs por OSD; una fórmula simplificada:
target_pgs = (osd_count * pgs_per_osd) / replication_sizeEjemplo: 12 OSDs, repl_size=3, pgs_per_osd=100 → target_pgs = (12*100)/3 = 400 → elija 256 o 512 (a menudo se recomienda una potencia de 2). Las versiones modernas de Ceph ofrecen pg_autoscaler, que ajusta el número de PGs de forma gradual — compruebe la compatibilidad con su versión de Proxmox.
pg_autoscaler: Ventajas y desventajas
pg_autoscaler automatiza los ajustes y reduce errores humanos. Inconvenientes: en versiones antiguas puede provocar rebalancing no deseado, por lo que actívelo solo si ha verificado la versión y el comportamiento.
CRUSH‑Map, dominios de fallo y clases de dispositivo
La CRUSH‑Map determina la colocación física. Defina claramente los dominios de fallo (p. ej. host, rack) y las clases de dispositivo (ssd/hdd) para que las políticas (p. ej. colocación separada para un tier SSD) se apliquen. Una CRUSH‑Map incorrecta conduce a una distribución desigual y a un incremento del tráfico de datos en caso de fallo.
Scrubbing, Backfilling y Recovery: diferencias y reglas de operación
El scrubbing (comprobación periódica de la integridad de los datos) es una actividad planificada; el Deep‑Scrub examina el contenido con mayor profundidad. El backfilling describe la copia de datos tras añadir o eliminar OSDs. El recovery es la restauración sincronizada tras fallos. Estos procesos consumen I/O y red de forma diferente — planifique ventanas de mantenimiento y establezca límites para tareas paralelas.
Resolución de rendimiento: runbook de incidentes sistemático
En caso de incidente de rendimiento siga un procedimiento estructurado: primero medir, luego intervenir, nunca cambiar la configuración global a ciegas.
Medidas inmediatas (primeros 10 minutos)
- Comprobar visión general del clúster:
ceph -s
ceph osd df tree
ceph pg stat
ceph osd perf
- Comprobar datos de red y estadísticas de los switches (MTU, errores, descartes).
- Comprobar I/O de OSD: iostat, iotop, blktrace.
- Observar clientes (I/O de VM de Proxmox con iostat dentro de las VMs).
Intervenciones y comandos habituales
Si el backfill es la causa, limite el recovery/backfill:
# Temporär OSD Noout (Achtung: nur bei geplanter Wartung)
ceph osd set noout
# Drosseln
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_max_backfills 1
# Überwachen
ceph -w
Si la CPU/memoria de los OSD es el cuello de botella, compruebe el número de PG y osd_memory_target. Reduzca los PGs solo de forma gradual y supervise la estabilidad de los OSD.
Runbook concreto para picos críticos de latencia
- Identificar: ceph osd perf, ceph pg dump | grep stuck/degraded.
- Aislar: reducir temporalmente clientes (QoS en Proxmox), set noout en caso de mantenimiento.
- Limitar: establecer los valores de recovery/backfill como arriba.
- Buscar la causa: contadores del switch, ethtool -S, iostat, dmesg para errores de dispositivo.
- Restablecer gradualmente: si la carga disminuye, revertir los valores y vigilar el monitorizado.
Pruebas y validación: fio como herramienta
Valide los perfiles de almacenamiento con fio (simulación de patrones de I/O). Un ejemplo para un mix aleatorio de lectura/escritura 4k:
fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70
--bs=4k --numjobs=8 --size=1G --runtime=300 --group_reporting
Realice dichas pruebas de forma aislada en una VM de prueba o directamente en los dispositivos OSD; interprete IOPS y latencia en relación con las cargas de trabajo esperadas de las VM de Proxmox.
Reemplazo de OSD: procedimiento seguro y estrategia de reversión
Al sustituir un OSD documente el estado de antemano, marque el OSD como out, supervise la recuperación hasta alcanzar la estabilidad y cree copias de seguridad de la CRUSH‑Map y del MON‑State. Comandos de ejemplo:
# OSD aus dem Cluster nehmen
ceph osd out
# Überwachen
ceph -w
# Nach Austausch neu anlegen (Beispiel ceph-volume)
sudo ceph-volume lvm create --data /dev/sdb
Estrategia de reversión: si el reemplazo falla, puede volver a montar temporalmente el dispositivo antiguo y volver a adjuntar el OSD, o ajustar la Weight‑Scale para evitar un reequilibrado descontrolado.
Métricas, alertas y observabilidad
Los módulos MGR proporcionan métricas Prometheus. Las alertas prioritarias deberían ser: ceph_health != OK, altas tasas de recovery/backfill, aumento de la OSD‑latency, muchos PGs en STATE ‚active+undersized‘ o ‚degraded‘. Los dashboards ayudan a ver comportamientos de tendencia y no solo eventos aislados.
Reglas prácticas de operación y errores comunes
- Configure MTU/Jumbo‑Frames solo tras las pruebas de extremo a extremo; MTU inconsistentes generan fragmentación y descartes.
- Evite el modo RAID en los controladores de almacenamiento para los OSD; HBA/Pass‑through reduce latencias inesperadas.
- Realice cambios en el número de PGs o en la CRUSH‑Map de forma escalonada y acompañados por sprints de monitorización.
- Programe ventanas de scrub y deep‑scrub en periodos de baja I/O.
Lista de verificación antes de la puesta en producción
- Comprobada la compatibilidad de versiones entre Proxmox y Ceph.
- Red Public/Cluster configurada, MTU comprobada.
- Establecido el número y la distribución de MON/MGR (mín. 3 MONs, 2 MGRs).
- Dimensionamiento de OSD: clases de dispositivos, dispositivos WAL/DB planificados.
- Planificación de PG: PGs objetivo calculados y validados en entorno de pruebas.
- Backups: flujo de trabajo de copias de seguridad para MON/MGR/CRUSH‑Map establecido.
- Monitorización: módulos MGR, Prometheus Exporter y sistema de alertas configurados.
- Planes de rollback documentados y probados (OSD Replace, MON‑RESTore).
Conclusión: disciplina operacional en lugar de ajustes mágicos
Ceph con Proxmox ofrece alta escalabilidad y buenas posibilidades de integración en entornos virtualizados — siempre que la arquitectura, la red y la planificación de PG estén alineadas. Comience de forma conservadora, mida los efectos y optimice de manera gradual. En caso de problemas de rendimiento ayuda una comprobación estructurada por capas (Hardware → Kernel → Red → Ceph → Cliente) y la limitación dirigida de Recovery/Backfill. La documentación, la monitorización y las estrategias de reversión probadas reducen los riesgos operativos y hacen el sistema predecible.
Use la lista de verificación como documento operativo y añada enlaces internos a how‑tos más detallados (p. ej., Proxmox‑Upgrades, diseño ZFS), para crear un manual operativo completo.
Aspectos operativos y de integración que a menudo se pasan por alto
En implementaciones de Ceph en Proxmox no solo decide la configuración pura del clúster el éxito, sino también cómo integra el almacenamiento en los procesos operativos, las copias de seguridad y la gestión de cambios. A continuación, aspectos prácticos que en proyectos suelen dar lugar a sorpresas posteriores, junto con recomendaciones concretas.
Estrategia de copias de seguridad y snapshots para VMs
Los RBD‑Snapshots son rápidos, pero no reemplazan una copia de seguridad sistemática. Utilice snapshots para puntos de consistencia a corto plazo (p. ej. antes de parches), pero exporte copias de seguridad regulares offsite (p. ej. exportación de los datos de la VM o uso de un backend de objetos como RGW/S3). Tenga en cuenta que los snapshots por sí mismos generan carga de I/O y que muchos snapshots pueden provocar degradaciones de rendimiento. Por tanto, planifique un intervalo de eliminación y la automatización para la limpieza de snapshots.
Coordinación con funciones de Proxmox
Asegúrese de que los Storage Pools de Proxmox (RBD) estén correctamente etiquetados y de usar controles de admisión para la colocación de VMs, para evitar hosts Hot‑OSD. Establezca reglas que impidan que demasiadas VMs con alta carga de I/O se acumulen en hosts con muchos OSD — eso reduce los riesgos de puntos calientes.
Capa de seguridad y cumplimiento
Active la encriptación de transporte entre los servicios de Ceph (mTLS) y considere la encriptación de los dispositivos (dmcrypt) para datos sensibles. Preste atención al manejo de claves: las claves no deben residir solo localmente, sino referenciarse desde su PKI/gestor externo de secretos (p. ej. HashiCorp Vault). Documente el proceso de desencriptado y recuperación para que el personal de operaciones sepa actuar en emergencias.
Playbook de actualización y rollback
Un playbook formal de actualizaciones reduce riesgos. Principios básicos: actualizaciones por fases, Health‑Checks después de cada etapa, timeouts conservadores y un procedimiento definido de reversión. Pruebe la actualización en un entorno de replicación y mantenga respaldos de los datos de estado MON y MGR disponibles.
# Ejemplo: Health‑Check antes de la actualización (versión corta)
ceph status --format=json | jq '.health'
ceph osd tree --format=json | jq '.nodes | length'
Automatización y orquestación
Utilice herramientas de orquestación (cephadm, Ansible) para despliegues repetibles y configuraciones documentadas. Guarde los cambios de configuración de Ceph en un repositorio Git y vincúlelos a su sistema de control de cambios. Las pruebas automatizadas (smoke‑checks tras cambios de configuración) evitan efectos secundarios no deseados en los pools productivos.
Multi‑site, replicación y escenarios DR
Si existen requisitos georedundantes, planifique la replicación de buckets RGW o Ceph‑RADOS‑Mirroring. Estos despliegues cambian drásticamente los requisitos de latencia y ancho de banda; pruebe la resiliencia de la replicación ante fallos de red simulados y cuantifique las SLA de ancho de banda necesarias para las ventanas de recuperación.
Observability: umbrales y alertas sensatas
Una alerta solo es tan buena como su acción. Defina responsables y runbooks automáticos para alertas como aumento de la latencia OSD, incremento de la tasa de backfill o degradación de PG. Ejemplos de umbrales pragmáticos:
- latency p95 > X ms durante Y minutos → generar ticket y aplicar parámetros de recuperación limitadores
- varios OSDs offline simultáneamente → escalación inmediata
- PGs en degraded/stuck > 0 durante Z minutos → evaluar entrada en modo de mantenimiento
Recomendación organizativa
Elabore un pequeño playbook operativo (2–3 páginas) con listas de verificación para: health‑checks diarios, procedimientos para intercambio de OSD, secuencia de actualizaciones y pasos de rollback. Combine este playbook con automatizaciones técnicas y pruebas de caos periódicas (fallos controlados) — así asegura que sus equipos adquieran familiaridad con los procesos de recuperación y que la tecnología quede integrada de forma estable en la operación productiva.
Para este tema también son importantes Mon Osd Mgr y el rendimiento de Ceph. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en la operativa diaria.