Proxmox + Ceph: cuándo conviene una infraestructura hiperconvergente y cuándo no
Proxmox VE integra directamente una de las plataformas de almacenamiento distribuido más conocidas del ecosistema open source:
Ceph.
La combinación resulta especialmente atractiva porque permite construir una infraestructura hiperconvergente donde los mismos servidores proporcionan:
- Cómputo
- Memoria
- Virtualización
- Almacenamiento
- Alta disponibilidad
Esto puede reducir la necesidad de utilizar una SAN externa y permite construir plataformas que escalan agregando nodos y discos.
Pero existe un error que debemos evitar:
Ceph no debe instalarse automáticamente solamente porque Proxmox lo incluye.
Una arquitectura Proxmox + Ceph requiere dimensionar correctamente discos, red, latencia, capacidad, memoria, recuperación ante fallas y crecimiento.
En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cuándo Ceph puede ser una excelente opción, cuándo probablemente no lo sea y qué debemos revisar antes de comprar el hardware.
Conoce las soluciones de Virtualización Empresarial de Sistro
¿Qué es Ceph?
Ceph es una plataforma de almacenamiento distribuido diseñada para utilizar múltiples servidores y discos como una infraestructura conjunta.
En lugar de depender de una única cabina central de almacenamiento, los datos pueden distribuirse entre diferentes discos y nodos.
Ceph puede proporcionar distintos tipos de almacenamiento, entre ellos:
- Block storage mediante RBD
- File storage mediante CephFS
- Object storage en determinadas arquitecturas
Dentro de Proxmox VE, uno de los usos más habituales es utilizar Ceph RBD como almacenamiento para discos de máquinas virtuales.
¿Qué significa infraestructura hiperconvergente?
Tradicionalmente una arquitectura de virtualización puede tener:
Hosts de virtualización
↓
Red de almacenamiento
↓
SAN o cabina externa
En una arquitectura hiperconvergente podemos tener:
Nodo 1: Compute + Storage
Nodo 2: Compute + Storage
Nodo 3: Compute + Storage
Los mismos nodos ejecutan las máquinas virtuales y aportan discos al almacenamiento distribuido.
Eso es precisamente lo que hace atractiva la combinación Proxmox + Ceph.
Consulta las soluciones Proxmox VE de Sistro
¿Qué problema resuelve Ceph?
En un cluster de virtualización necesitamos responder una pregunta:
¿Dónde viven los discos de las máquinas virtuales?
Si cada máquina depende exclusivamente del almacenamiento local de un único host, una falla de ese servidor puede complicar la recuperación de la carga.
Ceph distribuye la información entre varios nodos.
Esto permite que distintos hosts del cluster accedan al almacenamiento distribuido y que la plataforma mantenga redundancia según la política configurada.
Ceph elimina la SAN
Puede eliminar la necesidad de una SAN dedicada en determinados proyectos.
Pero eso no significa que:
Ceph siempre sea mejor que una SAN.
Ambas arquitecturas tienen ventajas y costos diferentes.
La decisión depende de:
- Infraestructura existente
- Capacidad
- IOPS
- Latencia
- Red
- Experiencia del equipo
- Presupuesto
- Crecimiento
- Alta disponibilidad
Arquitectura típica Proxmox + Ceph
Una arquitectura básica puede visualizarse así:
NODO PVE01
CPU + RAM + OSD Ceph
NODO PVE02
CPU + RAM + OSD Ceph
NODO PVE03
CPU + RAM + OSD Ceph
Todos conectados mediante una red de almacenamiento de alta velocidad.
Las máquinas virtuales utilizan volúmenes Ceph RBD accesibles desde los nodos del cluster.
¿Tres nodos son suficientes?
Tres nodos pueden utilizarse como punto de partida para determinados clusters pequeños.
También encajan naturalmente con el modelo de quorum que analizamos anteriormente para Proxmox.
Pero debemos hacer una distinción importante:
que tres nodos permitan construir la arquitectura no significa que tres nodos sean ideales para cualquier workload.
Conforme aumenta:
- Capacidad
- IOPS
- Máquinas virtuales
- Tráfico
- Criticidad
puede ser mejor utilizar más nodos.
Los clusters pequeños tienen menos margen ante una falla
Supongamos que tenemos tres nodos.
Si uno falla, perdemos aproximadamente una tercera parte de:
- Cómputo
- Memoria
- Discos
- Ancho de banda del cluster
Los nodos restantes deben absorber tanto las máquinas virtuales como la recuperación del almacenamiento.
Por eso el escenario de falla puede ser mucho más exigente que la operación normal.
No dimensionemos Ceph para el día normal
El diseño debe analizar también:
¿Qué ocurre cuando un nodo desaparece?
En ese momento podemos tener simultáneamente:
- VMs reiniciándose en otros hosts
- Ceph recuperando datos
- Replicación
- Backfill
- Usuarios productivos
- Backup
- Tráfico de red
Ese es uno de los momentos donde una mala arquitectura de networking puede hacerse evidente.
La red es uno de los componentes más importantes de Ceph
En una arquitectura hiperconvergente, los discos ya no están simplemente dentro de un servidor.
Los datos necesitan moverse entre nodos.
La red pasa a formar parte directa del sistema de almacenamiento.
Por eso debemos considerar:
- Ancho de banda
- Latencia
- Switches
- Redundancia
- MTU
- Bonding
- Interfaces
- Diseño físico
¿1 GbE sirve para Ceph?
Para una plataforma empresarial moderna, normalmente no diseñaría Ceph alrededor de una red de 1 GbE.
Puede convertirse rápidamente en un cuello de botella.
Debemos recordar que Ceph utiliza la red no solamente para atender máquinas virtuales.
También la utiliza para:
- Replicación
- Recovery
- Backfill
- Rebalance
- Comunicación entre componentes
10 GbE como punto de partida
Proxmox recomienda utilizar al menos una red de 10 GbE o superior para tráfico Ceph.
Además recomienda que esta red esté separada del tráfico sensible de Corosync.
Esto tiene mucho sentido.
Durante una recuperación, Ceph puede generar grandes cantidades de tráfico.
Si ese tráfico comparte la misma interfaz saturada con Corosync podemos afectar precisamente la comunicación que mantiene saludable al cluster.
NVMe puede necesitar todavía más red
Actualmente un solo dispositivo NVMe moderno puede generar suficiente throughput para acercarse o superar lo que una red de 10 GbE puede transportar.
Por eso en arquitecturas de alto desempeño debemos comenzar a evaluar:
- 25 GbE
- 40 GbE
- 100 GbE
dependiendo de los discos y del número de OSD por nodo.
No compres NVMe rápido y después uses una red lenta
Este es un error de arquitectura clásico.
Podemos invertir mucho dinero en:
- Servidores modernos
- CPU
- RAM
- NVMe empresariales
y después conectarlos con una red incapaz de transportar el rendimiento del almacenamiento.
En ese escenario el cuello de botella deja de ser el disco.
Pasa a ser el switch o la NIC.
Ceph Public Network y Cluster Network
Ceph puede trabajar con diferentes redes para funciones específicas.
Public Network
Transporta tráfico entre clientes Ceph y los servicios de almacenamiento.
Por ejemplo, una máquina virtual accediendo a su volumen RBD.
Cluster Network
Puede utilizarse para tráfico interno entre OSD, replicación y recuperación.
Separar estas redes puede mejorar rendimiento y reducir interferencias.
Corosync debe protegerse de la saturación
Corosync necesita baja latencia y comunicación estable.
Ceph puede generar grandes cantidades de tráfico.
Por eso una arquitectura empresarial debe evitar que una recuperación masiva de almacenamiento provoque problemas en la comunicación del cluster Proxmox.
Una posible separación puede ser:
Red 1 → Corosync
Red 2 → Ceph Public / VMs
Red 3 → Ceph Cluster
La arquitectura exacta dependerá del tamaño y desempeño requerido.
¿Necesitamos switches redundantes?
Si buscamos alta disponibilidad, sí debemos evaluar redundancia también en networking.
No tiene demasiado sentido construir:
3 servidores + discos redundantes + Ceph
y conectar todo a:
1 solo switch.
Ese switch se convierte inmediatamente en un punto único de falla.
En ambientes empresariales podemos diseñar:
Switch A + Switch B
con enlaces redundantes desde los nodos.
¿Qué discos utilizar?
Esta decisión depende completamente del workload.
Podemos encontrar arquitecturas basadas en:
- SSD SATA empresariales
- SSD SAS
- NVMe
- HDD para determinadas cargas de capacidad
- Combinaciones por clases de almacenamiento
No todos los discos ofrecen el mismo comportamiento.
No recomendamos discos de escritorio para Ceph empresarial
En producción debemos analizar discos diseñados para cargas sostenidas y entornos de servidor.
Entre los factores que debemos considerar están:
- Endurance
- DWPD
- Latencia
- IOPS
- Throughput
- Power Loss Protection
- Garantía
- Patrón de escritura
Ceph y las controladoras RAID
Ceph normalmente quiere trabajar directamente con los dispositivos que utilizará como OSD.
No debemos asumir que una controladora RAID tradicional configurada con grandes volúmenes RAID es automáticamente la arquitectura correcta.
Durante el diseño debemos revisar:
- HBA
- Modo passthrough
- Controladora
- Acceso individual a discos
- Compatibilidad del servidor
Distribuye los discos de manera equilibrada
Ceph funciona mejor cuando la capacidad y los discos se distribuyen razonablemente entre los nodos.
Por ejemplo, una arquitectura equilibrada:
PVE01 → 4 OSD
PVE02 → 4 OSD
PVE03 → 4 OSD
suele ser más sencilla de planear que una plataforma donde un nodo aporta casi toda la capacidad.
Más capacidad por disco también implica más recuperación por falla
Un disco muy grande permite aumentar densidad.
Pero si ese OSD falla, Ceph tendrá que reconstruir una mayor cantidad de información.
Por eso debemos equilibrar:
densidad + tiempo de recuperación + rendimiento + riesgo.
La capacidad RAW no es capacidad útil
Este punto es fundamental cuando cotizamos.
Supongamos:
3 nodos × 20 TB RAW = 60 TB RAW.
No significa que tendremos 60 TB disponibles para máquinas virtuales.
Ceph necesita redundancia.
Si utilizamos una política de tres réplicas como ejemplo, una parte importante de la capacidad física estará dedicada precisamente a mantener copias redundantes.
También debemos reservar espacio para operación, recuperación y crecimiento.
Por eso una cotización debe diferenciar claramente:
Capacidad RAW
de
Capacidad útil.
No llenes Ceph al 100%
Un almacenamiento distribuido necesita espacio disponible para operar.
Además de las VMs debemos considerar:
- Replicación
- Recovery
- Backfill
- Snapshots
- Crecimiento
- Rebalance
Una plataforma demasiado llena pierde margen operativo precisamente cuando ocurre una falla.
Ceph también consume RAM
En un diseño hiperconvergente la RAM no solamente la utilizan las máquinas virtuales.
También existen servicios de Proxmox y daemons de Ceph.
Durante operaciones como recovery y rebalance el consumo puede aumentar.
Por eso al dimensionar memoria debemos considerar:
VMs + Proxmox + Ceph + reserva + escenario de falla.
El error de asignar toda la RAM a las VMs
Supongamos un nodo con 256 GB.
No deberíamos planear 255 GB de máquinas virtuales solamente porque técnicamente caben.
Necesitamos reserva para:
- Sistema operativo
- Ceph
- Cache
- Operaciones de recuperación
- HA
- Crecimiento
Ceph también consume CPU
Los procesos de almacenamiento necesitan CPU para:
- Procesamiento de I/O
- Checksums
- Replicación
- Recovery
- Networking
En una arquitectura HCI el mismo procesador atiende tanto máquinas virtuales como almacenamiento.
Eso es precisamente lo que significa hiperconvergencia.
¿Qué pasa si un nodo falla?
Esta es una prueba crítica.
Cuando un nodo desaparece:
1. El cluster pierde recursos de cómputo
2. Las VMs protegidas pueden necesitar reiniciarse en otros hosts
3. Ceph pierde los OSD de ese nodo
4. El almacenamiento puede iniciar procesos de recuperación
5. La red recibe tráfico adicional
6. CPU y RAM de los nodos restantes reciben mayor carga
Por eso el diseño debe validarse bajo falla y no solamente cuando todo funciona.
HA de Proxmox y redundancia de Ceph son cosas diferentes
Proxmox HA protege la disponibilidad de máquinas virtuales y contenedores.
Ceph proporciona redundancia y disponibilidad en la capa de almacenamiento.
Ambas tecnologías pueden trabajar juntas.
Pero no son lo mismo.
Ceph tampoco es un backup
Este punto debe quedar muy claro.
Que Ceph mantenga varias copias de datos no significa que tengamos respaldo.
Si un usuario elimina información dentro de una VM, la eliminación puede replicarse perfectamente.
Lo mismo puede ocurrir con:
- Ransomware
- Corrupción lógica
- Error de aplicación
- Borrado accidental
- Error administrativo
Seguimos necesitando una plataforma de backup.
Proxmox Backup Server
Dentro del ecosistema podemos utilizar Proxmox Backup Server para proteger VMs y contenedores.
Una arquitectura podría verse así:
Cluster Proxmox + Ceph
↓
Proxmox Backup Server
↓
Repositorio secundario / copia externa
Esto separa:
Alta disponibilidad
de
Protección de datos.
¿Cuándo sí conviene Proxmox + Ceph?
Cuando queremos HCI
Si buscamos integrar cómputo y storage en los mismos nodos, Ceph es una alternativa natural.
Cuando no queremos depender de una SAN externa
Puede reducir la necesidad de una cabina centralizada.
Cuando queremos crecer agregando nodos
Una arquitectura distribuida permite escalar de forma gradual, siempre que el diseño lo contemple desde el principio.
Cuando necesitamos almacenamiento compartido distribuido
Las VMs pueden utilizar almacenamiento accesible desde diferentes nodos.
Cuando queremos eliminar el storage como punto único de falla
Los datos se distribuyen entre varios nodos y dispositivos de acuerdo con las políticas definidas.
¿Cuándo NO recomiendo Ceph automáticamente?
Cuando el cliente ya tiene una excelente SAN
Si existe una SAN empresarial con capacidad, soporte y vida útil disponible, descartarla solamente para instalar Ceph puede no tener sentido financiero.
Cuando solamente tenemos dos servidores
Hay otros diseños que pueden resultar más adecuados dependiendo de disponibilidad y presupuesto.
Cuando la red es solamente 1 GbE
Probablemente debamos invertir primero en networking.
Cuando el presupuesto no permite discos apropiados
Un almacenamiento distribuido barato y mal dimensionado puede convertirse en una mala experiencia.
Cuando el equipo no tiene experiencia operando Ceph
Ceph agrega capacidad, pero también una nueva capa que hay que administrar y comprender.
Cuando el workload exige latencia extremadamente predecible
Debemos analizar cuidadosamente si la arquitectura distribuida seleccionada puede satisfacer el requerimiento.
Cuando el ambiente es demasiado pequeño
Para unas pocas VMs sin requisitos fuertes de HA, una arquitectura más sencilla puede resultar mejor.
Proxmox + Ceph vs SAN
| Característica | Proxmox + Ceph | SAN tradicional |
|---|---|---|
| Modelo | Distribuido / HCI | Storage centralizado |
| Escalamiento | Agregar discos/nodos | Según capacidad de cabina |
| Networking | Crítico para storage distribuido | Red SAN / storage específica |
| Administración | Integrada con Proxmox | Plataforma independiente |
| Experiencia requerida | Proxmox + Ceph | Storage del fabricante |
No existe un ganador universal.
La arquitectura correcta depende de la infraestructura y los objetivos del cliente.
Proxmox + Ceph vs ZFS local
ZFS también es una excelente tecnología.
Pero resuelve un escenario diferente.
ZFS local proporciona almacenamiento robusto dentro de un nodo.
Ceph proporciona almacenamiento distribuido entre varios nodos.
Podemos simplificarlo así:
ZFS → excelente storage local
Ceph → storage distribuido
La selección depende de la arquitectura.
¿Necesito Ceph para Live Migration?
No necesariamente.
Proxmox puede trabajar con otras tecnologías de almacenamiento compartido y existen escenarios de migración donde se puede trasladar también almacenamiento.
Ceph es una alternativa, no un requisito obligatorio de Proxmox.
¿Necesito Ceph para High Availability?
No necesariamente.
HA necesita que las cargas puedan recuperarse correctamente desde otros nodos, pero pueden existir diferentes arquitecturas de storage compatibles con ese objetivo.
Podemos utilizar, según el proyecto:
- SAN
- NFS
- Ceph
- Otras tecnologías compatibles
Escenario 1: empresa con SAN existente
Tenemos:
- 3 hosts VMware
- SAN empresarial
- 40 VMs
- 10 GbE o Fibre Channel
- Veeam
La empresa quiere migrar a Proxmox.
No asumiría automáticamente que tenemos que tirar la SAN y construir Ceph.
Primero evaluaría si podemos conservar parte de la infraestructura existente.
Consulta el servicio de Migración a Proxmox VE de Sistro
Escenario 2: infraestructura nueva desde cero
Una empresa necesita:
- 3 o más nodos
- Alta disponibilidad
- Storage distribuido
- Crecimiento
- No dispone de SAN
Aquí Proxmox + Ceph puede ser una alternativa especialmente interesante.
Podemos diseñar desde el inicio:
- Discos
- NIC
- Switches
- Capacity Planning
- Redundancia
- Backup
Escenario 3: pequeña empresa con cinco VMs
La empresa tiene pocas máquinas y presupuesto limitado.
En este caso probablemente no empezaría por Ceph.
Una arquitectura sencilla con buen storage local, backup y procedimientos de recuperación puede resultar más apropiada.
Escenario 4: plataforma de alto rendimiento con NVMe
Tenemos:
- Múltiples nodos
- NVMe empresariales
- Muchos IOPS
- Máquinas críticas
- Gran movimiento de datos
Aquí debemos prestar especial atención a la red.
Un almacenamiento extremadamente rápido conectado a switching insuficiente desperdicia gran parte de la inversión.
Escenario 5: cluster con 1 GbE existente
Si el cliente quiere implementar Ceph pero solamente dispone de switching Gigabit, probablemente primero recomendaríamos revisar la capa de red.
La pregunta no sería:
“¿Cómo instalamos Ceph con lo que tenemos?”
Sino:
“¿Qué infraestructura necesita Ceph para cumplir el objetivo del proyecto?”
Errores frecuentes al implementar Proxmox + Ceph
1. Instalarlo porque está integrado en la interfaz
Integración sencilla no significa arquitectura sencilla.
2. Utilizar red de 1 GbE para producción exigente
El networking puede convertirse en el cuello de botella.
3. Mezclar Ceph y Corosync en una red saturada
Podemos afectar la estabilidad del cluster.
4. Comprar discos no adecuados
Storage empresarial requiere dispositivos apropiados para la carga.
5. Calcular capacidad útil igual a capacidad RAW
La redundancia consume espacio.
6. Llenar el cluster casi al 100%
Dejamos poco margen para recuperación y crecimiento.
7. No reservar RAM para Ceph
Las VMs no son las únicas consumidoras de memoria.
8. No reservar CPU
Recovery y storage también requieren procesamiento.
9. Usar un solo switch
Convertimos el networking en un Single Point of Failure.
10. Confundir Ceph con backup
La redundancia no sustituye una copia de seguridad.
11. No probar la falla de un nodo
La arquitectura debe validarse bajo condiciones adversas.
12. Ignorar el crecimiento
Discos, nodos, red y capacidad deben diseñarse para evolucionar.
Checklist antes de cotizar Proxmox + Ceph
Antes de comprar hardware deberíamos conocer:
- Número de máquinas virtuales
- CPU utilizada
- RAM utilizada
- Capacidad actual
- Capacidad futura
- IOPS
- Latencia requerida
- Tipo de workload
- Base de datos
- Aplicaciones críticas
- RPO
- RTO
- Número de nodos
- Tipo de discos
- Cantidad de OSD
- Velocidad de red
- Switches
- Redundancia
- Backup
- Crecimiento a tres o cinco años
Preguntas que Sistro debería hacer antes de recomendar Ceph
- ¿Cuántas VMs tienes?
- ¿Cuánto almacenamiento utilizas realmente?
- ¿Qué crecimiento esperas?
- ¿Cuántos IOPS necesitas?
- ¿Qué latencia requieren tus aplicaciones?
- ¿Ya tienes SAN o NAS?
- ¿Qué velocidad tienen tus switches?
- ¿Qué interfaces tienen tus servidores?
- ¿Utilizarás SSD o NVMe?
- ¿Qué ocurre si falla un nodo?
- ¿Qué RPO y RTO necesitas?
- ¿Cómo realizarás backups?
- ¿Quién administrará Ceph?
Después podemos decidir si HCI realmente aporta valor.
Proxmox + Ceph dentro de Biblioteca Virtual Sistro 2.0
Este artículo complementa directamente nuestro contenido sobre clusters Proxmox.
Proxmox cluster de 3 nodos: hardware, quorum y HA
Migrar VMware a Proxmox: checklist antes de la primera VM
Servicios Proxmox en Sistro
Virtualización Empresarial
https://sistro.net/virtualizacion
Proxmox VE
https://sistro.net/proxmox
Instalación y Configuración Proxmox VE Empresarial
https://sistro.net/proxmox/instalacion-proxmox-ve
Migración a Proxmox VE
https://sistro.net/proxmox/migracion-proxmox-ve
Soporte Administrado Proxmox VE
https://sistro.net/proxmox/soporte-administrado-proxmox-ve
Recomendación final
Proxmox + Ceph puede ser una excelente arquitectura para empresas que buscan construir una plataforma hiperconvergente, distribuida y preparada para crecer.
Pero Ceph no debe verse como una casilla que simplemente activamos dentro de Proxmox.
La arquitectura depende directamente de:
Discos + Red + Latencia + CPU + RAM + Capacidad + Redundancia + Recovery + Backup.
En algunos clientes Ceph será exactamente la solución correcta.
En otros será mejor conservar una SAN existente.
En ambientes pequeños una arquitectura más sencilla puede proporcionar mejores resultados y menor complejidad.
Por eso nuestra recomendación es:
no elijas primero la tecnología de almacenamiento.
Define primero el workload y los objetivos de disponibilidad.
¿Estás evaluando Proxmox + Ceph?
En Sistro Networks podemos realizar un assessment de tu infraestructura y dimensionar nodos, discos, networking, capacidad, IOPS, backup y alta disponibilidad antes de comprar el hardware.
Diseñamos la solución para determinar si Ceph realmente aporta valor o si una arquitectura SAN, NAS, ZFS u otra alternativa resulta más adecuada.
Consulta nuestro servicio de Instalación y Configuración Proxmox VE Empresarial
Preguntas frecuentes
¿Qué es Ceph en Proxmox?
Es una plataforma de almacenamiento distribuido integrada con Proxmox VE que permite utilizar discos de varios nodos como una infraestructura de storage conjunta.
¿Necesito Ceph para utilizar Proxmox?
No. Proxmox puede utilizar ZFS, LVM, NFS, iSCSI, SAN, NAS y otras tecnologías de almacenamiento.
¿Necesito Ceph para HA?
No necesariamente. Existen otras arquitecturas de almacenamiento compartido o distribuido que pueden utilizarse dependiendo del diseño.
¿Cuántos nodos necesito para Ceph?
Tres nodos pueden utilizarse como punto de partida para determinados clusters pequeños, pero la cantidad correcta depende de capacidad, rendimiento, disponibilidad y crecimiento.
¿10 GbE es suficiente para Ceph?
Puede ser un punto de partida para muchos proyectos, pero plataformas con múltiples SSD o NVMe pueden requerir 25 GbE o más dependiendo del rendimiento esperado.
¿Puedo usar 1 GbE?
Técnicamente pueden existir escenarios limitados, pero para una nueva implementación empresarial de Ceph normalmente recomendamos diseñar networking de mayor capacidad.
¿Ceph sustituye el backup?
No. Ceph proporciona redundancia de almacenamiento, pero no protege frente a eliminación lógica, ransomware, corrupción o errores humanos.
¿Ceph es mejor que una SAN?
No existe una respuesta universal. Ceph puede ser excelente para HCI y crecimiento distribuido, mientras que una SAN existente puede seguir siendo la mejor solución para determinados ambientes.
¿Puedo migrar VMware a Proxmox y conservar mi SAN?
En muchos casos puede evaluarse. No es obligatorio sustituir el almacenamiento existente únicamente por migrar el hipervisor.
Deja un Comentario