Soporte Ceph Soporte y consultoría de clústeres Ceph en producción. Para OpenStack, Kubernetes o Proxmox VE.
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.
Qué 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 por CPU | 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.
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, no un formulario.
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.
