Proxmox necesita una estrategia de almacenamiento coherente más que un rival de TrueNAS

La idea que parece obvia hasta que la tocas

Toda plataforma popular llega tarde o temprano al mismo momento incómodo: los usuarios dejan de preguntar qué puede hacer y empiezan a preguntar por qué tiene que existir el resto de su stack. Proxmox ya gestiona los hosts. Ya entiende de VMs, contenedores, pools ZFS, clústeres, copias de seguridad, permisos y la integración de almacenamiento suficiente para que un homelab parezca una pequeña nube privada. Así que la propuesta casi se escribe sola: ¿por qué no crear también un producto de almacenamiento de Proxmox? Llámalo ProxStorage, y que sea sencillo, basado en Debian y solo ZFS, sin el desorden de la tienda de apps, sin la maraña de plugins y sin la crisis de identidad. Exportaría NFS e iSCSI, dejaría que Proxmox gestionara los snapshots de forma limpia y daría a los usuarios un único ecosistema en lugar de otro appliance más con otro panel y otro conjunto de supuestos.

La idea tocó un nervio porque responde a algo real. Mucha gente aprecia TrueNAS por lo que mejor hace, pero está cansada de ver cómo las plataformas de almacenamiento derivan hacia el terreno de la "caja que lo hace todo". Apps, plugins, cambios constantes de interfaz, segmentación de producto, inquietud comercial y proyectos paralelos llamativos hacen que algunos usuarios vuelvan a querer un appliance de almacenamiento aburrido. No quieren un parque de juegos de Kubernetes, un lanzador de servidores multimedia ni una marca de estilo de vida para discos. Quieren un destino de almacenamiento serio, respaldado por ZFS, para virtualización, algo que diga: aquí tienes tus pools, datasets, snapshots, exportaciones NFS, destinos iSCSI, tareas de replicación y permisos. Que duermas bien.

El atractivo es evidente. Un appliance de almacenamiento hecho por la misma gente que desarrolla Proxmox VE podría resultar nativo de una forma que TrueNAS, OpenMediaVault, XigmaNAS o una máquina Debian montada a mano nunca terminan de conseguir. Imagina los snapshots del almacenamiento visibles en la interfaz de Proxmox igual que las copias de seguridad, y una coordinación de snapshots consciente de las VMs sin apaños. Imagina una interfaz limpia pensada para servir a clústeres PVE en vez de a todos los pasatiempos posibles de un NAS, con menos capas de traducción entre "necesito almacenamiento fiable para VMs" y "esto es lo que hace ese trabajo".

Ese es el sueño, y los sueños de almacenamiento tienen la fea costumbre de convertirse en pesadillas de soporte.

TrueNAS es más que una carpeta compartida con una interfaz bonita

Buena parte de la confusión inicial vino de gente que trató la propuesta como si tratara solo de compartir archivos. Alguien preguntó para qué iba a necesitar nadie TrueNAS si podía montar una pequeña VM de NAS dentro de Proxmox. Otro señaló que Proxmox ya tiene pools ZFS e incluso una sección de la interfaz para ellos. Es cierto, pero se pierde la sustancia de la idea. La propuesta se parecía más a "dale a Proxmox un backend de almacenamiento dedicado que compita con el papel de SAN que suele cubrir TrueNAS" que a "déjame compartir una carpeta".

Esa distinción importa. TrueNAS viene de un mundo en el que el almacenamiento bare metal era el objetivo, y el rendimiento, la replicación, los pools escalables, el almacenamiento en bloque y una gestión limpia eran el producto en sí. Un comentarista contó que tenía una máquina TrueNAS bare metal con unos 300TB de almacenamiento, parte de ellos dedicados a almacenamiento en bloque iSCSI que antes alimentaba VMware y ahora alimenta Proxmox. Una micro VM de NAS que sirve las fotos de la familia es otra cosa. Esa máquina es infraestructura, un subsistema de almacenamiento.

Así que la versión justa de la idea de ProxStorage es que Proxmox podría completar su ecosistema con un producto de almacenamiento convergente junto al Ceph hiperconvergente, algo mucho más interesante que clonar TrueNAS porque a alguien no le gustan los plugins. Ceph ya forma parte de la historia de Proxmox, pero Ceph no es un appliance de almacenamiento casual de una sola máquina. Necesita varios nodos y planificación. Necesita red, discos, monitores, OSDs, dominios de fallo y cierta madurez emocional. Un producto NAS o SAN puede ser útil precisamente porque no hacen falta tres o más máquinas físicas para que tenga sentido.

Ese punto salió de forma directa: un NAS no debería necesitar 3+ dispositivos para funcionar. Otra persona replicó que un NAS seguro y escalable tiene su sitio en una pequeña empresa, aunque un homelab diminuto pueda arreglárselas con menos. Los dos lados tienen razón. Un appliance de almacenamiento único y un clúster de almacenamiento distribuido resuelven problemas distintos, y fingir lo contrario es lo que hace que la gente acabe enfadada con Ceph por no ser un Synology, o con un NAS por no ser una malla de almacenamiento escalable horizontalmente.

El apoyo más firme a la propuesta vino de quienes entendían ese terreno intermedio. Un destino de almacenamiento dedicado, basado en ZFS, gestionado por Proxmox y quizá consciente de Ceph, hecho específicamente para PVE, podría ser útil. TrueNAS no es malo y las herramientas actuales funcionan; el argumento se apoya en el hueco que hay en el ecosistema Proxmox entre "ZFS local en cada host" y "clúster Ceph completo". En ese hueco vive mucho almacenamiento real de pequeñas empresas y laboratorios.

Los de "usa lo que ya existe" tienen razón en algo

La otra cara del debate es brutalmente práctica: ¿por qué debería Proxmox crear todo un producto de almacenamiento si las piezas ya existen? Puedes montar ZFS directamente en un nodo PVE. Puedes exportar datasets a través de un contenedor LXC con Samba, meter XigmaNAS u otro sistema NAS en una VM, o configurar a mano NFS e iSCSI en Debian. Puedes ejecutar TrueNAS en bare metal, usar OpenMediaVault o comprar una SAN comercial. El ecosistema es un lío, pero no está vacío.

Un comentarista propuso XigmaNAS y lo describió como un fork de FreeNAS con muchos años a cuestas que ofrece buena parte de lo que la gente pide. Otro sugirió usar el LXC "Zamba" y exportar un dataset ZFS. Alguien más apuntó que puedes crear un dataset ZFS en Proxmox y pasar el almacenamiento a una VM de forma que el pool siga en PVE. Ninguna de estas sugerencias es fantasía. Así es exactamente como mucha gente resuelve hoy el problema: mantener ZFS donde Proxmox pueda verlo y usar un servicio ligero o una VM para exponerlo.

El problema es que "ya puedes hacerlo" no te da un producto coherente alrededor. Una pila de exportación ZFS hecha a mano puede funcionar de maravilla para quien la montó y ser un montón confuso de supuestos para el siguiente administrador. TrueNAS existe porque gestionar almacenamiento implica mucho más que comandos: ciclo de vida, permisos, alertas, replicación, snapshots, compartición, monitoreo, actualizaciones y recuperación. Un appliance de almacenamiento nativo de Proxmox tendría que hacer todo eso sin convertirse en la cosa inflada a la que supuestamente venía a sustituir.

Esa es la parte difícil. Todo el mundo quiere algo "sencillo", y nadie se pone de acuerdo en dónde termina lo sencillo. Añade solo NFS e iSCSI, y alguien pregunta al instante por SMB. Añade SMB, y alguien pregunta por almacenamiento de objetos. Añade almacenamiento de objetos, y ya vas derivando hacia la misma proliferación de funciones que se quería evitar. Añade apps, y la propuesta muere del todo; déjalas fuera, y una parte del mercado NAS se encoge de hombros y se queda donde está. Enfocar un producto parece fácil hasta que cada función que falta es el motivo de descarte de alguien.

También hubo una queja procedimental razonable: las peticiones de funciones van a Bugzilla, no solo a una charla informal. No es una respuesta romántica, pero es la adulta. Si el objetivo es atraer a los desarrolladores, una petición de verdad necesita alcance, casos de uso, lo que queda fuera, puntos de integración y un motivo por el que ayudaría al negocio que hay detrás de Proxmox. "Por favor, creen un sistema operativo de almacenamiento" es pedir una línea de producto entera.

La inquietud con TrueNAS es en realidad una cuestión de confianza

Las críticas a TrueNAS tenían un tono emocional. Iban más allá de "prefiero otra interfaz" y llegaban a "esto parece inflado, la interfaz no para de cambiar, ¿y si se vuelve más comercial?". Ese miedo es habitual en las comunidades cercanas al código abierto. La gente construye su casa, su laboratorio y su negocio sobre una herramienta y luego ve cómo evoluciona la empresa que hay detrás. De repente hay productos nuevos, marca nueva, prioridades nuevas, y los usuarios empiezan a preguntarse si siguen siendo el público.

Parte de esa inquietud puede ser injusta. TrueNAS sigue cumpliendo un papel importante y tiene una larga trayectoria. No tiene nada de malo que un producto de almacenamiento tenga una interfaz pulida, ofertas comerciales o ambiciones más amplias. Las empresas necesitan dinero, los desarrolladores necesitan sueldos y los fabricantes de hardware necesitan clientes. Que un proyecto siga vivo suele significar que alguien paga el oxígeno.

Aun así, la incomodidad es real. Los usuarios que quieren un appliance de almacenamiento para Proxmox no quieren necesariamente una plataforma NAS para todo con personalidad propia. Quieren algo más callado, con menos opiniones fuera de su carril, algo que no dé la impresión de poder convertirse en otro ecosistema que tengan que descifrar. En ese sentido, la idea de ProxStorage tiene menos que ver con odiar TrueNAS y más con querer un almacenamiento que forme parte del mismo cerebro operativo que Proxmox.

Por eso importa la idea de los snapshots. "La VM puede ver snapshots nativos de ProxStorage" puede sonar vago, pero el deseo que hay debajo es muy concreto: los usuarios quieren una virtualización consciente del almacenamiento sin fronteras torpes, donde el hipervisor, el destino de almacenamiento y el sistema de copias de seguridad se entiendan entre sí. Proxmox Backup Server ya demuestra lo valioso que puede ser pensar en ecosistema, porque encaja con la forma en que PVE entiende las copias de seguridad en lugar de limitarse a guardar archivos. Un appliance de almacenamiento de Proxmox podría, en teoría, hacer lo mismo con el almacenamiento compartido.

Con todo, la confianza funciona en ambos sentidos. Los usuarios pueden confiar en Proxmox, pero Proxmox tendría que ganarse la confianza en una categoría nueva. A los appliances de almacenamiento se les juzga con dureza porque la pérdida de datos no se perdona. Una aspereza en la interfaz de VMs es molesta; una aspereza en la replicación del almacenamiento o en el comportamiento de iSCSI puede acabar con un negocio. Un producto de "almacenamiento sin preocupaciones" suena precioso, y también suena a nota de secuestro enviada desde la futura cola de soporte.

El producto que falta es real, y la trampa también

La versión más convincente de ProxStorage sería acotada: basada en Debian y centrada en ZFS, sin tienda de apps y sin teatro de Docker. Tendría un NFS e iSCSI sólidos, y soporte claro de SMB solo si el producto está dispuesto a asumirlo como es debido. Súmale autenticación nativa de Proxmox, flujos de snapshots y replicación alineados con PVE, buen monitoreo, alertas excelentes, documentación de primera y una ruta de actualización limpia. Quizá ofrezca integración opcional con Ceph para diseños más grandes, sin imponer un enfoque centrado en Ceph. En resumen, un appliance de almacenamiento para quienes quieren un compañero SAN/NAS para Proxmox en lugar de un NAS de estilo de vida.

Eso podría ser potente. Daría a pequeñas empresas y laboratorios una alternativa más limpia a "instala TrueNAS en bare metal y conéctalo" o a "haz un montón de trabajo de almacenamiento a medida en Debian y reza para que todo el mundo lo documente". Los MSP y los equipos internos de TI tendrían una historia de soporte más coherente, y los usuarios que quieren almacenamiento compartido sin la complejidad de Ceph ni la dispersión de un appliance NAS generalista tendrían adónde ir. Ampliaría el ecosistema de una forma que resulta natural.

Pero también competiría por la atención de los desarrolladores con todo lo que Proxmox ya tiene que mantener: PVE, PBS, Mail Gateway, SDN, clústeres, HA, integración con Ceph, integración con ZFS, mejoras de copias de seguridad, trabajo de interfaz, problemas del kernel, soporte de hardware, documentación y soporte empresarial. Que Debian y ZFS ya existan no convierte un producto de almacenamiento en "poco trabajo". Los paquetes son la parte barata; la integración, las pruebas, las salvaguardas y el soporte son donde está el gasto.

Y la comunidad se dividiría al instante. Unos dirían: "Por fin, una SAN limpia para Proxmox". Otros dirían: "¿Para qué duplicar TrueNAS?". Algunos querrían Ceph integrado, otros exigirían SMB y otros querrían almacenamiento de objetos. Unos querrían un appliance de un solo nodo y otros almacenamiento en HA. Algunos insistirían en que un NAS debe ser sencillo, mientras otros insistirían en que lo sencillo es irresponsable. El producto nacería con mil expectativas encima.

Nada de eso lo descarta, pero la propuesta necesita disciplina. "Sustituir a TrueNAS" es demasiado amplio, demasiado emocional y probablemente innecesario. La mejor idea es "crear un appliance de almacenamiento de Proxmox centrado en ser el mejor backend de almacenamiento compartido para PVE", que es un objetivo más limpio. No necesita ganar todo el mundo NAS. Necesita resolver el hueco de almacenamiento de Proxmox mejor que el parcheado actual.

Las mejores ideas suelen empezar como quejas

Lo interesante de este debate es que la propuesta original era desordenada y el instinto que la movía era sólido. La gente quiere un almacenamiento que resulte nativo en su plataforma de virtualización, menos inflado y con una opción entre el ZFS local y un Ceph completo. Quiere snapshots, replicación, NFS, iSCSI e integración con PVE sin hacer malabares con un universo aparte. Y sí, hay quien está cansado de ver cómo las plataformas de almacenamiento se convierten en plataformas de apps con discos pegados.

Los críticos también tenían razón en algo. Proxmox ya tiene ZFS, y ya existen muchas herramientas NAS. TrueNAS es algo más que un producto inflado, y XigmaNAS, OMV, un Debian montado a mano y las exportaciones sencillas desde contenedores ya cubren muchos casos de uso. Un producto nuevo traería carga de soporte, crecimiento descontrolado del alcance y mil maneras de decepcionar a la gente. "Almacenamiento sin preocupaciones" es el tipo de frase que suena genial hasta que el primer usuario pierde un pool por aceptar una advertencia que no entendía.

En realidad hay tres bandos. El primero quiere un appliance de almacenamiento nativo de Proxmox porque el ecosistema parece incompleto sin él. El segundo dice que las herramientas existentes bastan y que Proxmox no debería gastar energía reinventando la gestión del almacenamiento. El tercero ve la forma más amplia: puede que haya sitio para un producto de almacenamiento convergente, pero solo si se mantiene centrado en servir a clústeres Proxmox en vez de perseguir todas las funciones NAS habidas y por haber.

Ese tercer bando es probablemente el que más se acerca a la verdad. Proxmox no necesita matar a TrueNAS, clonarlo ni convertirse en otro NAS inflado con catálogo de apps y crisis de identidad. Pero un compañero de almacenamiento limpio y enfocado, construido sobre ZFS, exportaciones compartidas de bloque y archivo, snapshots y flujos de trabajo conscientes de PVE, está lejos de ser una idea tonta. Es el tipo de pieza que falta y que los usuarios empiezan a pedir cuando una plataforma se vuelve lo bastante importante como para organizar alrededor de ella todo su laboratorio o su negocio.

Lo que queda abierto es si Proxmox quiere esa responsabilidad. Construir almacenamiento es fácil del mismo modo que construir un puente es fácil: la forma es obvia, los materiales existen y todo el mundo sabe dónde está la otra orilla. Lo difícil es que la gente confíe en él cuando lo cruza en coche.