Ceph 19.2.6: revisa el número de PG antes de actualizar

Ceph Squid 19.2.6 es una actualización de seguridad que merece la pena instalar, pero yo no trataría un clúster grande como un portátil que se parchea primero y se investiga después. Antes de actualizar, revisa la salud del clúster, el número de placement groups de cada pool, el pool interno .mgr, la compatibilidad de los clientes y los nuevos requisitos de rotación de claves CephX que introduce esta versión de seguridad.

He contrastado el anuncio de la versión Ceph 19.2.6, la documentación de Ceph Manager y el aviso de la comunidad que pide revisar el número de PG de .mgr antes de actualizar clústeres grandes. El debate en el tracker upstream es el motivo de mi cautela, y el anuncio de la versión de Ceph es el motivo por el que no aplazaría la actualización de seguridad indefinidamente.

¿Por qué Ceph 19.2.6 es una actualización urgente?

Ceph 19.2.6 es un hotfix urgente de Squid que corrige cuatro CVE relacionadas con la autenticación, RGW y el comportamiento de los monitores. El proyecto Ceph publicó Squid 19.2.6 junto con Tentacle 20.2.4 el 19 de agosto de 2026 y recomendó encarecidamente a los operadores que actualizaran.

Las cuatro incidencias son CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 y CVE-2026-54330. La primera es la que más importa aquí, porque la solución introduce un nuevo tipo de clave CephX llamado aes256k y un nuevo procedimiento de actualización y rotación de claves.

Eso cambia la naturaleza del mantenimiento. Además de sustituir paquetes o imágenes de contenedor, según tu método de despliegue y tus clientes, puede que también tengas que verificar que los daemons y los clientes entienden el nuevo tipo de clave antes de rotar las credenciales.

Ceph indica que cephadm automatiza la rotación de las claves de OSD y MDS durante la actualización, mientras que algunas claves de cliente siguen necesitando la atención del operador. El soporte de aes256k en el cliente del kernel empieza upstream en el kernel Linux 7.0, con backports disponibles en algunas distribuciones. Así que "mi clúster Ceph está en 19.2.6" y "todos los clientes están listos para la nueva clave" son comprobaciones distintas.

Si este clúster Ceph está debajo de Proxmox, trata la capa de almacenamiento como un plan de cambio propio. La sección de Proxmox es útil para la parte del hipervisor, pero las notas de versión de Ceph deben seguir siendo la referencia para el orden de las acciones de seguridad en Ceph.

¿Qué es el pool .mgr y por qué deberías revisarlo?

El pool .mgr es un pool reservado de Ceph que crea el servicio Ceph Manager para que los módulos del manager puedan guardar estado persistente. La documentación de Ceph lo describe de forma explícita como el pool de los módulos del manager, y el punto inicial lo marca como un nombre de pool interno reservado.

Los administradores pueden pasar por alto este pool porque no contiene imágenes RBD normales ni datos de usuario de CephFS, pero eso no lo hace prescindible. El personal de Proxmox también ha advertido a los usuarios de que no borren ni modifiquen a la ligera los pools internos de Ceph que empiezan por punto.

El aviso actual de la comunidad sobre Ceph 19.2.6 pide a quienes operan clústeres grandes que revisen el número de placement groups de .mgr antes de actualizar. La incidencia enlazada en el tracker de Ceph sigue siendo el sitio adecuado para seguir el estado exacto del bug y cualquier solución definitiva upstream, así que no me voy a inventar un número de PG "seguro" universal que el propio Ceph no ha publicado.

Lo que sí haría es anotar la configuración del pool antes de tocar el clúster:

ceph health detail
ceph osd lspools
ceph osd pool ls detail
ceph osd pool autoscale-status
ceph -s

Luego localiza la entrada de .mgr en la salida del detalle de los pools y anota su pg_num, el modo de autoescalado, el tamaño y los metadatos de aplicación. Si tu clúster es grande o la configuración del pool .mgr parece rara, compárala directamente con la incidencia upstream y con las indicaciones de la lista de correo antes de seguir. Es mejor que suponer que un número de PG más alto o más bajo tiene que ser el correcto.

¿Por qué importa el número de placement groups en una actualización de Ceph?

Los placement groups son la capa lógica que usa Ceph para asignar objetos a conjuntos de OSD, así que el número de PG afecta directamente a cuánto estado del clúster tienen que seguir y mover los daemons. Pocos PG pueden perjudicar la distribución, y demasiados aumentan la memoria y la sobrecarga del peering.

El Ceph moderno incluye el autoescalador de PG para reducir el ajuste manual necesario, pero el autoescalado no garantiza que todos los pools históricos de todos los clústeres grandes tengan una configuración ideal. Los pools internos también pueden sobrevivir a varias generaciones de actualizaciones y cambios de configuración.

Antes de una actualización de seguridad, me importa menos llegar a un número de PG matemáticamente perfecto y más detectar las excepciones. ¿Hay un pool interno diminuto con un número sorprendente de PG? ¿Está desactivado el autoescalado en un pool que nadie recuerda haber creado? ¿Hay PG que no están en active+clean antes incluso de empezar el mantenimiento?

Si el clúster empieza el cambio en un estado degradado o en recuperación, pierdes la capacidad de saber si el problema lo causó la actualización. Por eso mi primer control es aburrido: ceph -s debería mostrar un estado que ya entiendo.

Para una explicación más amplia de cómo interactúan las decisiones de diseño de almacenamiento con la virtualización, la sección de almacenamiento es más útil que intentar arreglar la arquitectura de los pools en plena ventana de parche de emergencia.

¿Qué debería comprobar antes de instalar Ceph 19.2.6?

Unas comprobaciones previas para Ceph 19.2.6 deberían demostrar que conoces el estado de partida y que puedes dar marcha atrás si un nodo o un cliente se comporta de otra forma después de actualizar. Yo capturaría tanto el estado del clúster como el de sus dependencias, y mi lista incluiría:

• Confirmar que están activos todos los monitores, managers, OSD y daemons MDS que deberían estar en marcha.
• Confirmar que los estados de los PG se entienden y, a ser posible, están en active+clean antes de empezar.
• Anotar ceph versions para saber exactamente qué daemons están en qué versión.
• Anotar los detalles de todos los pools, con especial atención a .mgr y a cualquier otro pool interno.
• Revisar ceph osd pool autoscale-status en busca de recomendaciones de PG inesperadas o de autoescalado desactivado.
• Comprobar la capacidad libre y el margen para la recuperación. La urgencia de seguridad no es motivo para actualizar un clúster que ya está casi lleno.
• Revisar el procedimiento oficial de rotación de claves CephX de Ceph 19.2.6 antes de cambiar el primer daemon.
• Inventariar los clientes CephFS y RBD del kernel, no solo los daemons del clúster.
• Si usas RGW multisite, seguir la nota de la versión sobre rgw_sigv4_insecure antes de empezar la actualización.
• Hacer copia de seguridad de la configuración crítica y de los datos de los monitores con el método adecuado para tu despliegue.

También guardaría las salidas en el ticket de mantenimiento. Cuando algo cambia después del nodo tres, "creo que antes estaba así" no sirve de nada. Una captura de texto de las comprobaciones previas es una prueba barata.

¿Qué tiene de especial la rotación de claves CephX en 19.2.6?

Ceph 19.2.6 introduce aes256k como nuevo tipo de clave CephX, así que hay que tener en cuenta la compatibilidad de autenticación entre daemons y clientes. Ceph dice que es la primera vez que introduce un nuevo tipo de clave de credenciales CephX, y por eso la versión trae un procedimiento específico para actualizar las claves.

En los despliegues con cephadm, la rotación de las claves de los daemons está más automatizada, pero el anuncio de la versión sigue avisando a los operadores de que la actualización tardará más mientras se rotan las claves de OSD y MDS. Las claves de cliente son un asunto aparte.

Aquí es donde los entornos mixtos pueden darte sorpresas. Un clúster Ceph moderno puede dar servicio a clientes de kernel más antiguos, contenedores, hipervisores, sistemas de copia de seguridad y appliances. El clúster puede terminar de actualizar sus daemons mientras un cliente todavía no admite la vía de credenciales que pretendes usar.

Por eso, en el runbook separaría "actualizar el software de los daemons" de "rotar todas las credenciales de inmediato". Sigue el procedimiento oficial, valida clientes representativos y continúa con la rotación cuando tengas pruebas de que el parque de clientes está preparado.

¿Cambia Proxmox la decisión de actualizar a Ceph 19.2.6?

Proxmox hace más visible el impacto del mantenimiento, porque Ceph puede estar sosteniendo discos de VMs en producción mientras lo parcheas, pero no elimina la necesidad de seguir las indicaciones de seguridad del propio Ceph. La preocupación adicional principal es mantener suficiente redundancia de almacenamiento y de cómputo mientras los hosts pasan por el mantenimiento.

Si también estás preparando una actualización de Proxmox VE 8 a 9, evita amontonar todos los cambios importantes en una sola ventana. El fin de soporte de Proxmox VE 8 también aprieta, pero un plan por etapas sigue siendo más seguro. Yo completaría y validaría la ruta necesaria de Ceph y después pasaría al cambio de versión mayor de Proxmox.

Explico ese orden en la guía de actualización por el fin de soporte de Proxmox VE 8, porque los plazos están relacionados pero los dominios de fallo son distintos.

¿Debería retrasar Ceph 19.2.6 por el aviso sobre .mgr?

Yo no retrasaría Ceph 19.2.6 indefinidamente. Cuatro correcciones de seguridad y una recomendación explícita de upstream para actualizar pesan más que la comodidad de quedarse en un nivel de parche de Squid más antiguo.

Sí retrasaría el primer nodo de producción el tiempo suficiente para revisar .mgr, leer la incidencia actual del tracker, validar la salud del clúster y entender la nueva ruta de rotación de claves. Eso puede ser cuestión de horas o de un ciclo de mantenimiento. No debería convertirse en una excusa para dejar un clúster expuesto sin parchear durante meses.

Si hoy gestionara un clúster Ceph grande, mi orden sería sencillo: capturar el estado actual, investigar cualquier configuración de PG rara en .mgr, probar la actualización en el entorno de menor riesgo disponible, parchear el clúster de producción en oleadas controladas y rotar credenciales solo con la compatibilidad de los clientes verificada. La urgencia de seguridad debería hacer el proceso más rápido sin volverlo descuidado.