Clústeres Proxmox y SAN: la sorpresa de almacenamiento al dejar VMware

Dejar VMware es como arrancar una tirita. Duele, desde luego, pero todo el mundo te dice que vale la pena. El agotamiento con las licencias, las subidas repentinas de costes y unos contratos que de pronto parecen hostiles son motivos de sobra conocidos. Proxmox se presenta con una imagen tranquila, abierta y reconfortante, prometiendo clústeres, HA, migración en vivo y un futuro en el que no tengas que negociar con un comercial en cada renovación.

Así que haces lo que parece más obvio. Tomas la arquitectura en la que has confiado durante diez años, un clúster pequeño respaldado por una SAN, y le conectas Proxmox. El mismo almacenamiento, un nuevo hipervisor. Fácil, ¿verdad?

Ahí es donde las cosas empiezan a complicarse. Proxmox respaldado por una SAN no se comporta igual que VMware respaldado por una SAN, incluso cuando en el plano técnico todo "funciona", y nadie te avisa de antemano. El desfase es ante todo de expectativas, y pilla desprevenidos a muchos equipos.

El problema de la memoria muscular de VMware

La mayoría de los entornos VMware acostumbraron a los administradores a pensar de una forma muy concreta. El almacenamiento en bloque compartido es el centro del universo, los snapshots salen baratos y el aprovisionamiento fino resulta invisible. Sobreasignas almacenamiento con tranquilidad y te preocupas por las consecuencias más adelante, lo que normalmente significa nunca.

VMFS absorbe la complejidad sin rechistar, la SAN hace su magia y el hipervisor no estorba. Al dar el salto a Proxmox, muchos asumen que ese mismo reparto de tareas sigue vigente: la SAN gestiona la inteligencia del almacenamiento y el hipervisor se limita a consumirlo.

Sin embargo, Proxmox no te oculta las decisiones de almacenamiento. Te obliga a responsabilizarte de ellas.

LVM compartido: la primera sorpresa

La mayoría de los clústeres de Proxmox basados en SAN empiezan con LVM compartido sobre iSCSI o Fibre Channel. Está soportado, documentado y es estable, y sobre el papel cumple los requisitos para sustituir a VMware. De hecho funciona: la migración en vivo, la alta disponibilidad y el multipath están operativos.

Entonces surgen las dudas. ¿Por qué los discos quedan con aprovisionamiento fijo (thick)? ¿Por qué los snapshots no aparecen o resultan peligrosos? ¿Por qué al eliminar una VM no se recupera el espacio? Aquí es donde la memoria muscular de VMware se quiebra.

El LVM compartido en Proxmox es deliberadamente conservador. Los volúmenes exigen espacio garantizado. Los snapshots son estructuras completas de copia en escritura que pueden dispararse al instante. El snapshot de un disco virtual de 1TB puede suponer una presión de 1TB de espacio aunque nada cambie.

El aprovisionamiento fino a nivel de SAN no resuelve esto de forma mágica, porque el hipervisor no lo ve. Proxmox planifica el almacenamiento como si fuera real, reservado y finito, ya que desde su perspectiva lo es. Quienes administran esperan flexibilidad y Proxmox les ofrece previsibilidad.

"Pero la SAN hace aprovisionamiento fino"

Este argumento se repite a menudo y técnicamente es cierto. Muchas SANs modernas gestionan el aprovisionamiento fino, la deduplicación y la compresión con solvencia. Reclaman bloques con eficiencia y mienten, con amabilidad, sobre la capacidad real.

La dificultad está en la visibilidad. Con LVM compartido, Proxmox no sabe que la SAN desafía a la física en tu beneficio. Solo ve una LUN grande y fija. Al crear un snapshot de un disco, Proxmox se prepara para el peor escenario de crecimiento. Al borrar una VM, la SAN puede no liberar nada a menos que la opción discard esté perfectamente configurada.

Ese desacuerdo genera una falsa sensación de seguridad. Todo parece correcto hasta que deja de estarlo, y cuando falla, falla deprisa.

NFS: la opción que todos rechazan (y acaban usando)

En algún momento de casi cualquier migración, alguien lo dice en voz alta: "¿Y si usamos simplemente NFS?". A esto suele seguirle un silencio incómodo, cierto espanto y algún comentario irónico sobre el rendimiento.

A pesar de todo, NFS suele ser la forma menos desconcertante de operar almacenamiento compartido en Proxmox. El almacenamiento basado en archivos desbloquea los discos qcow2, lo que aporta un aprovisionamiento fino que Proxmox entiende de verdad. Los snapshots residen dentro del archivo de disco en vez de consumir volúmenes lógicos enteros, y el uso de espacio pasa a ser visible, predecible y recuperable.

No es tan rápido ni tan elegante como el almacenamiento en bloque nativo, ni gestiona el multipath como Fibre Channel. Pero se comporta de forma noble, y al migrar fuera de VMware, el comportamiento estable importa más que los benchmarks.

El choque con la realidad de los snapshots

Los snapshots son el punto donde las expectativas chocan de frente con la realidad.

En VMware, los snapshots son arriesgados pero engañosamente sencillos. Todo el mundo sabe que no equivalen a copias de seguridad y aun así se utilizan continuamente, porque son rápidos, flexibles y casi siempre salen bien.

En Proxmox con LVM compartido, los snapshots parecen una trampa. Existen, pero no transmiten tranquilidad, no escalan bien y pueden descuadrar tus cálculos de almacenamiento de formas que VMware nunca dejaba ver.

Eso obliga a un cambio de hábitos. Los equipos vuelven a tratar las VMs como ganado, con imágenes inmutables, copias de seguridad externas, snapshots de vida muy corta si acaso se usan, y recuperación mediante restauración en vez de rebobinado. Es otra forma de trabajar que no resulta peor, pero los cambios generan incomodidad en plena migración.

"¿Por qué no usar simplemente Ceph?"

En cuanto aprietan los problemas con la SAN, Ceph entra en escena. Es nativo, está integrado y fue diseñado para los clústeres de Proxmox desde su concepción. Escala, se autorrepara y convierte el almacenamiento compartido en un componente central en lugar de una dependencia ajena.

Ceph no sale gratis, ya sea por inversión en hardware, redes o complejidad operativa. Para clústeres pequeños de 2 a 3 nodos, con frecuencia resulta excesivo. Exige memoria RAM, discos veloces y redes impecables, y premia la disciplina frente a los atajos.

Algunos equipos lo adoran y otros lo descartan de inmediato. Ceph responde a una filosofía por completo diferente, de modo que no conviene esperar que resuelva por sí solo el desencanto con la SAN.

Las suposiciones dan más problemas que el almacenamiento

Hay un detalle que nadie expresa en voz alta durante las reuniones de planificación: la mayor parte de las dificultades procede de las suposiciones heredadas de VMware, mucho más que de la propia SAN.

VMware acostumbró a los administradores a no preocuparse por la mecánica del almacenamiento, y Proxmox vuelve a poner esa mecánica sobre la mesa. No te protege de cálculos erróneos ni disimula el riesgo tras opciones predeterminadas amables.

Puede parecer un retroceso hasta que compruebas lo que ganas: transparencia, control y menos precipicios ocultos. Aunque solo ayuda si estás preparado para asumirlo.

Lo que tienen en común las migraciones con éxito

Los equipos que culminan con satisfacción una migración a Proxmox con SAN suelen compartir varios rasgos. Aceptan que no todo tiene una correspondencia exacta con VMware y diseñan el almacenamiento en torno a las fortalezas de Proxmox en vez de guiarse por la nostalgia de VMware. Emplean los snapshots como herramientas puntuales y no como redes de protección, y planifican la capacidad sabiendo que vuelve a importar de verdad.

Algunos eligen NFS. Otros continúan con LVM compartido ajustando sus expectativas. Otros apuestan de lleno por Ceph. Unos pocos combinan almacenamiento local con replicación y abandonan la búsqueda de la perfección centralizada.

Ninguna de esas opciones es equivocada. El error consiste en asumir que Proxmox actuará como VMware con solo mirar hacia otro lado.

Salir vale la pena, aunque no sea indoloro

Proxmox no está roto, las SANs no han quedado obsoletas y marcharse de VMware no significa rebajar el nivel de exigencia. Significa reaprender dónde están los límites.

Los equipos que encuentran dificultades suelen tener capacidad técnica de sobra. Lo que les hace tropezar es esperar que la capa de almacenamiento permanezca invisible. Proxmox no busca ser invisible; busca ser honesto. Una vez que dejas de luchar contra eso, todo el conjunto cobra mucho más sentido.