Soporte Ceph Diseñamos, migramos y sostenemos el almacenamiento de tus clústeres Proxmox VE, OpenStack y Kubernetes.
Nos meten en Ceph normalmente para tres cosas: montar el clúster bien de la primera vez, arreglar el que otros dejaron a medias, o reemplazar una cabina SAN que ya cuesta más que la infraestructura entera. Cubrimos RBD, CephFS y RGW (S3) sobre OpenStack, Kubernetes o Proxmox VE.
Qué es Ceph
y cuándo tiene sentido
Ceph corre sobre Linux y hardware x86 estándar, y en el mismo clúster te da bloque (RBD) para máquinas virtuales, ficheros (CephFS) para lo que se monta desde varios sitios, y objetos S3 (RGW) para el backup y la parte de aplicaciones. Los datos se replican entre servidores, y si se cae un disco, un host o incluso una sala, la producción sigue.
Es lo que sostiene la nube privada cuando decides no depender de un hiperescalar, y lo que tiene sentido cuando tu cabina SAN se llena y la siguiente cuesta más que un coche. Escala añadiendo servidores, no comprando una máquina nueva del mismo fabricante.
SAP HANA certificado no, bases de datos con latencia sub-milisegundo tampoco. Ahí Ceph no es la respuesta y te ahorramos el proyecto. Para casi todo lo demás del datacenter —virtualización, nube privada, backup, S3 interno, contenedores— sí encaja.
Cómo aprender Ceph desde cero →
Proyecto oficial · ceph.io ↗ · Documentación técnica ↗
Qué cubrimos en Ceph
Todo el ciclo de vida del clúster, con el mismo equipo: diseño, migración desde cabinas viejas, tuning cuando va lento, y el turno de las 3 AM cuando algo se cae.
Ceph RBD
El disco de tus máquinas virtuales, servido por Ceph en vez de por una cabina. Con snapshots y clones que van en segundos porque son copy-on-write, no copias completas. Habla nativamente con Cinder, libvirt/KVM y Proxmox VE.
CephFS
Un sistema de ficheros POSIX que se monta desde cien máquinas a la vez sin que un servidor de metadatos sea el cuello de botella. Cuando alguien pide "NFS pero de verdad", esto es lo que sacamos. Cómo montarlo en alta disponibilidad con Ganesha →
Ceph RGW
Un endpoint S3 que apunta a tu clúster, no a AWS. Bucket policies, IAM, versionado y lifecycle. Veeam e IBM Storage Defender lo tratan como un bucket cualquiera.
S3 · Swift · Veeam · IBM Defender Ceph vs MinIO: guía 2026 →Rook / Ceph CSI
Los pods necesitan volúmenes que sobrevivan a un reschedule. Con Rook Ceph vive dentro del propio clúster K8s; con Ceph CSI se conecta a uno externo. Los dos casos con snapshots y RWX real.
RWO · RWX · Snapshots CSICeph en Proxmox VE
Tres nodos con cómputo y almacenamiento en la misma máquina, sin comprar vSAN y sin licencia por CPU. Proxmox integra Ceph nativamente; nosotros lo dimensionamos y lo dejamos afinado para que aguante producción, no solo demos.
Alternativa vSANCeph con NVMe para IA, HPC y analítica
Un GPU-hour cuesta más que un mes de un OSD; el almacenamiento no puede ser el cuello de botella. Pools 100% NVMe, red de 100 GbE o RDMA y CRUSH pensado para que las réplicas no compitan por el mismo switch.
Ceph en Proxmox VE
Proxmox trae Ceph integrado, así que el almacenamiento se decide al montar el clúster y no después. Cuatro cosas cambian el resultado, y tres de ellas cuestan dinero si se descubren tarde.
¿ZFS o Ceph?
Depende de si las VMs pueden pararse. La replicación de ZFS es asíncrona y va por parejas de nodos: más barata y más simple de operar, y en una caída pierdes lo escrito desde la última réplica — tan reciente como la frecuencia que le hayas puesto. Ceph es síncrono y compartido: el dato está en el clúster antes de que se confirme la escritura, así que cualquier nodo arranca cualquier VM sin mover nada. Con dos nodos y sin exigencia de alta disponibilidad, ZFS sobra. Con tres o más y servicios que no pueden caerse, Ceph.
ZFS asíncrono · Ceph síncronoLa red, que es por donde se cae
Con el pool replicado por defecto, cada escritura del cliente genera dos copias más que viajan por la red, y el rebalanceo tras perder un disco compite por el mismo cable que las VMs. Sobre 1 GbE eso no se sostiene: 10 GbE es el suelo, con la red de clúster separada de la de gestión, y con OSD en NVMe se queda corto enseguida. Se dimensiona al principio, porque cambiar la red con el clúster ya montado es otro proyecto.
10 GbE mínimo · red de clúster aparteSalir de vSAN
Si vienes de vSphere con vSAN, el equivalente funcional es Proxmox con Ceph: cómputo y almacenamiento en las mismas máquinas. Sobre el licenciamiento conviene ser exacto, porque se cuenta mal a menudo: Proxmox funciona sin suscripción, y la que hay se vende por socket y da acceso al repositorio enterprise sin desbloquear funciones; vSAN se licencia por core y con mínimo por CPU. Cuál sale a cuenta depende de vuestros nodos y de vuestros cores, así que se echa con el inventario delante. Y luego está la operación, que es donde se va el tiempo: otras herramientas, otro modelo de fallo y otro sitio donde mirar los logs.
Alternativa a vSANDónde vive la copia de seguridad
Las réplicas cubren un disco roto. Un borrado o un ransomware se replican igual que el resto, así que la copia tiene que vivir fuera del clúster: Proxmox Backup Server en hardware distinto, con deduplicación, y con la verificación programada para que un restore que no funciona no se descubra el día que hace falta.
Proxmox Backup ServerQué hacemos exactamente
Ingenieros propios que se sientan con tu equipo y conocen tu clúster.
Empezamos midiendo lo que hará el clúster de verdad, no lo que dice el brief. Con eso salen el número de OSD, el ratio SSD:HDD, la topología de red y las reglas del CRUSH map. Desplegamos con cephadm y no lo damos por bueno hasta que el bench en fio y rados replica los números que prometimos.
La cabina no se apaga hasta que Ceph lleva semanas sirviendo lo mismo. Pasamos cargas por olas —primero las que se pueden reiniciar, luego las de las 3 AM— y al final comparamos checksums antes de tirar del cable a la SAN vieja.
Ceph rinde lo que le dejas rendir. Si va lento, casi siempre es la red, el tamaño del PG, o un pool mal balanceado; casi nunca "es que Ceph es lento". Medimos, tocamos una cosa cada vez, y te dejamos los benchmarks para que puedas repetirlos tú.
Prometheus, Grafana y Ceph Dashboard atados a lo que ya tengas. No te enviamos una alerta por cada scrub; sí te avisamos cuando un OSD va camino de morir o cuando la capacidad va a chocar en tres meses.
Este es el que nos llama a las 3 AM. PG inconsistentes, mons sin quorum, OSD que
no arrancan, un upgrade que se atascó a mitad. Turno 24/7 con SLA firmado. Regla
de oro: si el clúster está degradado, no lo toques hasta hablar con nosotros.
El error más común y cómo se corrige →
Tiempos de respuesta
Clúster read-only, pérdida de quorum de mons o PGs inaccesibles.
OSDs caídos, degradación de rendimiento o recuperación en curso.
Revisión de arquitectura, tuning y recomendaciones proactivas.
SLA y penalizaciones recogidos por contrato.
Cuándo Ceph gana,
cuándo no
Ninguna tecnología cabe en todo. Estos son los casos donde Ceph resuelve, y los que mandaríamos a otro sitio aunque nos costara el proyecto.
| Qué necesitas resolver | Ceph | Qué pediríamos en su lugar |
|---|---|---|
| Sustituir cabina SAN que ya cuesta más que renovar el hierro entero | Encaja | — |
| Almacenamiento persistente para OpenStack o Kubernetes | Es el patrón de referencia | — |
| Bucket S3 interno sin pasar por AWS | RGW resuelve | — |
| Clúster hiperconvergido con Proxmox o KVM, sin licencia obligatoria para funcionar | Combo maduro | — |
| Backup y archivado a largo plazo con Veeam o Storage Defender | RGW compatible S3 | — |
| Base de datos con latencia sub-milisegundo estricta | No lo forcemos | NVMe local + réplica a nivel de aplicación |
| SAP HANA certificado por SAP | No está certificado | IBM FlashSystem u otra cabina certificada |
| Home directories de un edificio (3-5 TB, un solo sitio) | Sobredimensionado | NFS clásico o cabina pequeña |
Ceph casi nunca
viaja solo
Llega con OpenStack encima o con Kubernetes. Muchas veces las dos cosas. Los que sabemos de la capa de abajo somos los mismos que damos soporte a las de arriba.
Almacenamiento distribuido: bloque para VMs, POSIX para ficheros, S3 para lo demás. Lo que sostiene todo lo de arriba.
Estás aquíNube privada real, aislada del hiperescalar. Nova, Neutron, Cinder y Glance apoyados en Ceph. Formación oficial mientras montamos la landing de soporte.
Formación OpenStack →OpenShift, Rancher (k3s), Canonical, Talos. Los volúmenes persistentes salen de Ceph vía Rook o Ceph CSI.
Formación OpenShift →Preguntas frecuentes sobre Ceph
Ceph es una plataforma de almacenamiento distribuido open source que corre sobre Linux y hardware estándar. Un mismo clúster ofrece tres interfaces: bloque (RBD) para VMs y bases de datos, ficheros (CephFS) para cargas compartidas y objetos compatibles con S3 (RGW). Los datos se replican entre nodos y el clúster tolera fallos de discos, servidores o incluso salas enteras si el diseño lo prevé.
Cuando quieres crecer sin comprar una cabina nueva cada vez que se llena la actual, cuando el coste de licencia por TB de tu fabricante sube más de lo que crece tu negocio, o cuando además del almacenamiento en bloque necesitas S3 y ficheros compartidos sin licenciar tres productos distintos. Si tu carga principal es SAP HANA certificada o una base de datos con latencia sub-milisegundo estricta, Ceph no es tu opción y te lo diremos.
Sí, y es una de sus combinaciones más maduras. Proxmox VE integra Ceph de forma nativa, lo que permite montar clústeres hiperconvergidos de tres nodos en adelante: cómputo y almacenamiento en las mismas máquinas, sin licencia extra y sin depender de vSAN. En SIXE diseñamos y afinamos ese tandem para entornos de producción, no solo para laboratorio.
Depende de si las VMs pueden pararse. La replicación de ZFS es asíncrona y va por parejas de nodos: es más barata y más simple de operar, pero en una caída pierdes lo escrito desde la última réplica; la migración en vivo manda solo el incremento desde esa réplica, no el disco entero. Ceph es síncrono y compartido: cualquier nodo puede arrancar cualquier VM al instante. Con dos nodos y sin exigencia de alta disponibilidad, ZFS sobra. Con tres nodos o más y servicios que no pueden caerse, Ceph.
Ceph es el almacenamiento de referencia para ambos. En OpenStack lo consumen Cinder (bloque), Glance (imágenes) y Manila (ficheros) de forma nativa. En Kubernetes se despliega con el operador Rook o con Ceph CSI, y aporta volúmenes persistentes ReadWriteOnce y ReadWriteMany, snapshots y clones. Funciona con OpenShift, Rancher (k3s), Canonical Kubernetes y Talos.
Un clúster útil en producción arranca en tres nodos, que es el mínimo para mantener quorum de monitores y una regla de replicación x3. Por debajo funciona pero como laboratorio, no como sistema tolerante a fallos. A partir de ahí escala en horizontal: seis nodos empiezan a permitir dominios de fallo por rack, y de diez en adelante ya hablamos de topologías empresariales serias.
Sí, con el diseño correcto. Para inferencia y entrenamiento distribuido montamos pools NVMe con red de alta velocidad (25/100 GbE o superior) y ajustamos la configuración para IOPS y ancho de banda reales. Para HPC el patrón es CephFS con MDS activos en paralelo. Requiere dimensionar bien la parte física: no se compra un clúster genérico y se espera que aguante GPUs a plena carga.
Sí, es uno de los motivos por los que suelen llamarnos. Diagnóstico de PGs inconsistentes, pérdida de quorum de monitores, OSDs que no arrancan, recuperación que no avanza o upgrades atascados. Trabajamos con turno 24/7 y SLA por contrato para P1.
Escríbenos y te lo miramos
Dinos qué pasa: clúster nuevo, uno que ya no arranca, o cabina SAN que se te está yendo de las manos. Te contesta un ingeniero.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
