Mr.PlanB Logo
    Volver al blog
    Proxmox
    Ceph
    Almacenamiento
    Alta disponibilidad
    StarWind
    Synology

    Cómo acabé usando Ceph, StarWind y Synology a la vez

    25 de enero de 2026
    8 min de lectura

    Hay un momento concreto en la trayectoria de todo homelab en el que dejas de construir cosas y empiezas a negociar con ellas. En ese punto ya has superado la fase de reparar y la de optimizar. Es el instante en que tu arquitectura de almacenamiento te mira de frente y te dice: "Tenemos que hablar".

    Esta es la historia de cómo terminé ejecutando Ceph, StarWind VSAN y Synology a la vez. Nada de esto se concibió como una arquitectura de almacenamiento en varios niveles. Sucedió intento de simplificación a intento de simplificación, y cada intento añadía una capa más. El resultado fue un auténtico turducken de almacenamiento, delicioso en la teoría y bastante inquietante en la práctica.

    Mi objetivo inicial no era probar todas las tecnologías de almacenamiento a la vez. Solo quería una cosa: almacenamiento masivo en alta disponibilidad que no volara por los aires cada vez que un nodo estornuda. Ese era todo mi sueño, y sí, me busqué este lío yo solo.

    El plan original (que era perfecto, por supuesto)

    Tengo un clúster pequeño de Proxmox con 5 nodos, nada del otro mundo, que lleva años funcionando como un reloj. En un momento dado tomé la decisión lógica y configuré Ceph porque:

    • Es nativo
    • Es de nivel "empresarial"
    • Todo el mundo dice "tú usa Ceph" con la seguridad de quien ya ha sufrido lo indecible

    Y Ceph funcionó: para discos de máquinas virtuales, para contenedores y para todo aquello que necesita seguir levantado si cae un servidor físico. Cero quejas en esa parte.

    Luego estaba el almacenamiento masivo: bibliotecas de Plex, vídeos de Frigate, archivos multimedia a los que les dan igual los IOPS pero que exigen permanecer en línea. Es el tipo de datos que quieres montar una vez y no volver a pensar en ellos jamás.

    Aquí entró en escena el Synology RackStation. Hacía justo lo que debía hacer, con SMB, NFS y una única IP. Era sólido como una roca, aburrido y maravilloso, y cumplía su trabajo con total solvencia sin hacer ruido mientras yo me engañaba diciendo que era algo "temporal".

    Y entonces pensé: "¿Y si meto ese almacenamiento dentro del propio clúster?". Ahí fue donde todo descarriló por completo.

    StarWind: "esto será sencillo" (narrador: no lo fue)

    Ceph ya estaba ahí, pero yo buscaba algo un poco más... parecido a una SAN para el almacenamiento masivo, con replicación síncrona, algo que se comportara como un dispositivo de bloques que pudiera entender con claridad. Así que añadí StarWind VSAN.

    Para ser justos, StarWind cumplió lo que prometía: volúmenes iSCSI, HA, replicación en espejo y esa reconfortante ilusión de software empresarial que toma las decisiones difíciles por ti. Ahora tenía:

    • Ceph para discos de máquinas virtuales y contenedores
    • StarWind para almacenamiento masivo en HA
    • Synology para... ¿copias de seguridad? ¿apoyo moral?

    Para entonces, mi esquema de almacenamiento ya no cabía en una sola pantalla. La replicación funcionaba a la perfección. La gran pregunta pendiente era cómo usarla en la práctica sin que todo pareciera pegado con cinta aislante.

    El problema de la IP (o "por qué esto no puede actuar como un NAS")

    Hay algo que Synology clava de forma impecable. Lo montas, tiene una IP y, si algo se rompe, conmuta al nodo secundario sin que a tus puntos de montaje les importe lo más mínimo. Ese es el estándar de oro y ese es el listón.

    Lo que yo pretendía era obtener el comportamiento de Synology HA pero respaldado por mi flamante almacenamiento en VSAN. Lo que obtuve fue una larga mirada al abismo de los sistemas de archivos clusterizados, los gestores de volúmenes y las soluciones "técnicamente posibles".

    El almacenamiento en bloque es sencillo; la semántica de un sistema de archivos compartido no lo es. iSCSI te entrega un dispositivo de bloques, pero solo una entidad puede escribir en él a la vez salvo que busques el caos más absoluto. Así que las dudas empezaron a acumularse:

    • ¿Paso el volumen iSCSI directamente a los contenedores?
    • ¿Lo encapsulo dentro de LVM?
    • ¿Renuncio por completo a los volúmenes lógicos de Proxmox?
    • ¿Necesito GFS2? ¿OCFS2? ¿Alguna otra sigla que huela a sufrimiento?

    Cada respuesta venía acompañada de una etiqueta de advertencia.

    "Usa un sistema de archivos clusterizado" (genial, genial)

    Sobre el papel, la solución parece de lo más directa:

    1. Presentar el LUN iSCSI a varios nodos
    2. Colocar un sistema de archivos clusterizado encima
    3. Montarlo en todos los servidores
    4. Hacer bind-mount hacia los contenedores
    5. Conseguir el éxito

    En la realidad cotidiana, cada paso es un compromiso constante entre fragilidad, rendimiento y complejidad. Elige dos, o a veces solo una.

    Los sistemas de archivos clusterizados son fascinantes cuando están diseñados desde la base de la infraestructura. Resultan mucho menos fascinantes cuando los encajas a la fuerza solo para que Plex sobreviva al reinicio de un nodo. En cuanto al rendimiento, no necesito cifras desorbitadas ni compito por récords, pero me gustaría alcanzar 200 MB/s sin sentir que estoy tentando a la suerte.

    En un momento dado me di cuenta de que estaba intentando construir un NAS con piezas que explícitamente no son un NAS. Una vez más, me metí en esto yo solo.

    CephFS entra en escena

    Todo viaje por el almacenamiento termina volviendo a Ceph. Es como la gravedad del sector. CephFS suena impecable:

    • Sistema de archivos compartido
    • Nativo dentro del clúster
    • Activo en varios nodos simultáneamente
    • Sin extraños rituales de aislamiento de nodos

    Pero CephFS viene con su propia dosis de realidad:

    • A los pools sobre discos mecánicos no les gustan nada las cargas de metadatos
    • Cualquier cosa montada sobre 2 nodos es... espiritualmente peligrosa
    • Las matemáticas de la replicación se vuelven incómodas muy rápido

    Sí, Ceph tiene sumas de verificación y, en efecto, detecta la corrupción de datos. No, eso no hace que los pools con pocas réplicas te dejen dormir tranquilo por las noches. Ceph es plenamente feliz cuando le das múltiples nodos, múltiples OSD, redes muy rápidas y paciencia. Es bastante menos feliz cuando le pides que se comporte como un pequeño y dócil NAS.

    Mientras tanto, el Synology sigue ahí plantado

    Esta parte es la que de verdad te descoloca la cabeza. El Synology no protesta, no plantea dilemas filosóficos y no necesita una pizarra para explicarse. Sirve NFS, conserva su IP, replica cuando se le pide y, por lo demás, simplemente existe.

    Al final, una voz muy sensata en mi interior me preguntó: "¿Por qué estás haciendo todo esto?". ¿Para qué mover el almacenamiento masivo al clúster cuando el clúster ya tiene alta disponibilidad donde de verdad importa? ¿Por qué forzar a Ceph o a VSAN a convertirse en un NAS cuando un NAS real ya hace tareas de NAS excepcionalmente bien?

    La respuesta, por desgracia, era una mezcla de curiosidad, orgullo y la convicción de que debía existir una forma limpia de unificarlo todo. No la había, la verdad.

    En qué acabó todo esto (una tregua de almacenamiento)

    No terminé con una única solución perfecta. Terminé con un compromiso, más bien un alto el fuego:

    • Ceph se queda donde brilla: discos de VM, contenedores y servicios que exigen recuperación rápida
    • StarWind demostró que la HA a nivel de bloques funciona, pero añade capas que no necesito para archivos multimedia
    • Synology sigue gestionando el almacenamiento masivo, porque es insultantemente bueno haciéndolo

    La gran lección fue que la alta disponibilidad no significa que todo deba estar clusterizado. Ciertas cosas solo necesitan ser fiables, otras solo requieren volver a estar en línea rápido y algunas funcionan mucho mejor siendo aburridas. Tratar de que todo el almacenamiento se comporte de forma idéntica es la receta perfecta para acabar con 3 plataformas de almacenamiento distintas y un artículo de blog como este.

    La conclusión (antes de comprar más hardware)

    Si estás persiguiendo almacenamiento masivo en HA dentro de un clúster de virtualización, hazte antes una sola pregunta: ¿quiero que esto sea elegante o quiero que funcione? La elegancia suele pagarse con complejidad, y la complejidad siempre te pasa la factura más adelante.

    No probé todas las alternativas de almacenamiento a la vez por accidente. Me limité a repetir "esto simplificará las cosas" y a creérmelo en cada ocasión. Nunca fue así, aunque aprendí muchísimo, sobre todo que la mejor decisión de arquitectura consiste a veces en dejar que cada herramienta haga aquello en lo que es impecablemente aburrida, resistiendo la tentación de unificarlo todo solo porque tienes la posibilidad técnica de hacerlo.

    Y ahora, si me disculpas, tengo que dejar de mirar diagramas de arquitectura antes de que me dé por añadir almacenamiento de objetos "solo para ver cómo responde".

    Recursos relacionados