ZFS y la Nueva Matemática del Datacenter: Por Qué Cambiar RAID en Hardware + ESXi por Barebone + Proxmox Va Más Allá del Ahorro

Todo proyecto de infraestructura crítica se topa con la misma pregunta en algún momento: ¿vale la pena mantener la arquitectura tradicional de virtualización — controladora RAID dedicada, hipervisor propietario, licenciamiento por núcleo — o migrar a un modelo basado en hardware simplificado y almacenamiento definido por software?

Con la reestructuración de licenciamiento de VMware bajo Broadcom, esa pregunta dejó de ser teórica. Pero reducir esa decisión solo a la hoja de cálculo de costos es subestimar lo que realmente cambia cuando cambias RAID en hardware por ZFS. La diferencia más profunda no es el precio de la controladora — es lo que sucede el día en que algo se quema, y es cuánto esa arquitectura te vuelve más competitivo cuando revendes infraestructura al cliente final.

En este artículo, vamos más allá de lo obvio: hardware, licenciamiento, rendimiento y seguridad — y entramos en cuatro puntos que raramente aparecen en esta comparación y que, en la práctica, pesan tanto o más que el ahorro directo: portabilidad del pool en caso de desastre, fin del lock-in con el fabricante de la controladora, capacidad real de hacer crecer un pool ya en producción, y el impacto directo en el margen de quien revende virtualización como servicio.

El punto de partida: dos arquitecturas, dos filosofías

Arquitectura tradicional (RAID en hardware + ESXi):
Una controladora RAID dedicada (generalmente un chip Broadcom/LSI con procesador propio y caché con batería o supercondensador) monta el array a nivel de hardware. El hipervisor ve un único volumen lógico y no tiene visibilidad sobre los discos individuales. Los metadatos del array se graban en formato propietario, legible solo por controladoras compatibles del mismo fabricante — y, con frecuencia, de la misma familia de firmware.

Arquitectura ZFS (HBA + Proxmox):
Los discos se presentan "crudos" al sistema operativo a través de un HBA en modo IT (sin RAID embebido), y ZFS asume toda la responsabilidad de redundancia, caché, compresión y verificación de integridad a nivel de software, usando la CPU y la RAM del propio servidor. Los metadatos del pool quedan grabados en los propios discos, en formato abierto, legible por cualquier sistema operativo con soporte para ZFS.

Es exactamente esa última frase — metadatos grabados en los discos, en formato abierto — la que cambia todo lo que viene a continuación.

1. Escalabilidad y recuperación ante desastres: el pool es portátil, el servidor no lo es

Este es, en mi experiencia práctica, el punto más subestimado de la comparación — y el más decisivo cuando las cosas salen realmente mal.

En un array RAID en hardware, el volumen lógico solo existe mientras la controladora que lo creó (o una compatible) esté funcionando. Si la placa madre muere, si la controladora se quema, o si todo el servidor queda inutilizable por cualquier motivo físico (incendio, sobretensión, inundación, robo), los datos quedan rehenes de dos condiciones: encontrar una controladora compatible y recrear exactamente la misma configuración del array.

Con ZFS, el pool es una unidad lógica autocontenida. Si un servidor sale de operación, el procedimiento de recuperación es literalmente:

1. Tomar los discos (o los discos remanentes, si el array tenía redundancia);

2. Instalar en cualquier otro hardware con Proxmox, TrueNAS o cualquier Linux/BSD con soporte para ZFS;

3. Ejecutar zpool import;

4. El pool vuelve a estar en línea, con todos los datasets, snapshots y permisos intactos.

No importa el fabricante, el modelo de la placa madre o la generación del procesador del nuevo servidor. Esto transforma la recuperación ante desastres de "esperar logística de hardware específico" a "cuestión de minutos, con el hardware que ya tienes disponible" — incluso un servidor más simple o hasta una estación de trabajo, temporalmente, hasta que la operación se normalice.

Para operaciones que atienden clientes hospitalarios e industriales, donde el SLA de disponibilidad es innegociable, esa capacidad de reimportar el pool en cualquier lugar no es un "bono" — es reducción directa del tiempo de indisponibilidad en un escenario de catástrofe, lo que se traduce en menos multa contractual y menos riesgo reputacional.

2. Fin del lock-in de la controladora: el costo oculto del RMA

Este punto conversa directamente con el anterior, pero merece un destaque propio porque es un costo que raramente entra en la hoja de cálculo inicial — solo aparece cuando la controladora falla.

Cuando una controladora RAID en hardware se quema, la reposición no es trivial:

• Normalmente se necesita el mismo modelo, o uno compatible en la misma familia de firmware, para que el array sea reconocido correctamente;

• Fabricantes como Broadcom/LSI no tienen un stock local amplio en Brasil — el lead time de importación o de un revendedor autorizado puede llevar días, a veces semanas;

• Mientras tanto, el servidor queda parado, o necesitas buscar una solución de contorno (restaurar desde backup en otro hardware, si lo hay, con todo el tiempo que eso consume);

• Si la controladora específica quedó descontinuada, el problema empeora — puedes quedar rehén del mercado de reposición usada.

Con HBA + ZFS, ese riesgo prácticamente desaparece. Un HBA en modo IT es una pieza mucho más commodity — cualquier HBA compatible (incluso de otro fabricante) reconoce los discos y zpool import hace el resto. Incluso puedes mantener un HBA de repuesto en stock propio a un costo mucho menor que mantener una controladora RAID de repuesto, y eso ya es suficiente para eliminar el cuello de botella logístico del fabricante.

En la práctica: cambias una dependencia de un proveedor específico, con lead time incierto, por una pieza estandarizada de bajo costo que cualquier distribuidor de TI tiene disponible — o que ya tienes en el estante.

3. Crecimiento del pool: expansión que el RAID tradicional no entrega de verdad

Este punto suele pasar desapercibido hasta el día en que el cliente pide más espacio — y es una de las diferencias más prácticas en el día a día de la operación.

En controladoras RAID de hardware, algunas líneas más robustas incluso ofrecen OCE (Online Capacity Expansion), pero en la práctica es una funcionalidad limitada: normalmente exige agregar discos en lote (no un disco aislado), el proceso puede llevar horas o días en arrays grandes, el array funciona con resiliencia reducida durante toda la expansión, el nivel de RAID queda fijo, y no toda controladora — o firmware — soporta la operación de manera confiable. Por eso, en la práctica, la mayoría de las operaciones trata "expandir array" como sinónimo de "destruir y recrear desde cero con los discos nuevos", restaurando todo desde el backup.

Con ZFS, existen hoy dos caminos de crecimiento, y ninguno de ellos exige destruir el pool:

• Agregar un nuevo vdev al pool (zpool add): siempre fue posible — sumas un nuevo grupo de discos (otro RAIDZ, otro mirror) al pool existente, expandiendo la capacidad total instantáneamente, sin tocar los datos ya grabados. Es el método más usado y más seguro en producción.

• Expandir un vdev RAIDZ existente disco a disco (zpool attach): desde OpenZFS 2.3 — ya presente en las versiones actuales de Proxmox — es posible anexar un único disco nuevo a un vdev RAIDZ ya existente y expandir su capacidad sin necesidad de un conjunto completo de discos nuevos. Vale la alerta técnica: los datos ya grabados antes de la expansión continúan usando la proporción antigua de paridad hasta que son reescritos, por lo que la ganancia de espacio pleno aparece de forma gradual — pero la operación en sí ocurre con el pool en línea y sin destruir nada.

También es posible crecer cambiando disco por disco por unidades más grandes (zpool replace + autoexpand=on), dejando que el pool asuma la capacidad adicional automáticamente en cuanto todos los discos de un vdev sean reemplazados — una estrategia de upgrade incremental que el RAID en hardware simplemente no ofrece con la misma flexibilidad.

En la práctica operativa, esto significa que el crecimiento de un entorno ZFS acompaña el crecimiento del cliente sin forzar una parada extensa ni una reconstrucción completa del storage — algo que, en el modelo tradicional, normalmente se convierte en un proyecto de migración aparte.

4. Hardware: cuánto cuesta el cambio en sí

En clusters con múltiples nodos — como entornos multirregión con nodos distribuidos entre diferentes datacenters — ese ahorro se multiplica linealmente, y además reduce el número de piezas propietarias que necesitan mantenerse en stock de repuesto.

5. Licenciamiento: donde está el mayor impacto financiero recurrente

La migración de clientes a Proxmox en 2025 y 2026 ha sido impulsada casi enteramente por la reestructuración de licenciamiento de VMware promovida por Broadcom: fin de las licencias perpetuas, paquetes de suscripción obligatorios y conteo mínimo de núcleos por CPU, que multiplicaron los costos de muchas operaciones de mediano porte en un rango de 3 a 10 veces.

Del otro lado, el modelo de Proxmox es radicalmente más simple. El software en sí es gratuito y sin limitación de núcleos, VMs o nodos de cluster. La suscripción es opcional y se cobra por socket físico de CPU ocupado, no por núcleo:

El detalle más relevante para quienes están migrando servidores con procesadores modernos de alta densidad: una CPU con 32, 64 o incluso 128 núcleos sigue siendo licenciada como un único socket. Es el opuesto exacto del modelo por núcleo que encareció el licenciamiento tradicional — y en la práctica favorece justamente a los servidores más robustos, que son los que más interesan para la consolidación de cargas de trabajo hospitalarias e industriales.

Estimación práctica: dependiendo del tier de soporte contratado en Proxmox y de la configuración de núcleos que el cliente tenía licenciada anteriormente, el ahorro en licenciamiento anual suele estar entre 60% y 85% frente a un contrato vSphere equivalente pos-reestructuración.

6. El ángulo que más importa para quien revende infraestructura: margen

Si miras esto puramente como cliente final, la cuenta ya cierra. Pero si construyes infraestructura para revender — IaaS, VPS, colocation con servicio gestionado — el efecto se multiplica, porque cada real ahorrado en CAPEX y en licenciamiento se convierte en margen disponible para competir en precio sin sacrificar rentabilidad.

El mercado de nube en Brasil está cada vez más competitivo, con proveedores internacionales presionando precios agresivamente. En ese escenario, el costo base de tu infraestructura es lo que determina hasta dónde puedes bajar el precio final sin operar en números rojos. Un stack basado en barebone + Proxmox + ZFS, comparado con un stack tradicional con RAID en hardware + hipervisor licenciado por núcleo, típicamente resulta en:

• CAPEX por nodo menor (ahorro de hardware detallado arriba), lo que reduce el payback de cada servidor nuevo puesto en producción;

• OPEX de licenciamiento drásticamente menor, lo que es especialmente relevante cuando estás fijando el precio de un contrato recurrente a largo plazo para el cliente final;

• Menor exposición a riesgo operacional (recuperación más rápida, sin lock-in de proveedor), lo que reduce el costo de SLA y de contingencia que normalmente necesita ser embebido en el precio;

• Backup nativo gratuito vía Proxmox Backup Server, reduciendo una línea más de costo recurrente que normalmente sería trasladada al cliente o absorbida en el margen.

En la práctica, esto significa que la misma calidad de servicio — o incluso superior, dado el aumento de integridad de datos de ZFS — puede ofrecerse con un precio más competitivo, sin comprimir el margen de la operación. Es la diferencia entre competir por precio "quemando margen" y competir por precio porque la base de costo realmente es menor.

7. Rendimiento: no es una victoria unilateral

Sería deshonesto presentar ZFS como estrictamente más rápido — la realidad depende de un dimensionamiento correcto.

Ventajas de ZFS:

• ARC (Adaptive Replacement Cache): usa la RAM del host como caché de lectura de manera mucho más agresiva e inteligente que la caché limitada de una controladora RAID.

• Compresión inline (lz4): casi siempre compensa el costo de CPU, reduciendo el volumen real de I/O en disco.

• Copy-on-write: elimina el "write hole" clásico del RAID 5/6, donde una caída de energía en medio de una escritura puede corromper todo el stripe.

Puntos de atención:

• ZFS consume CPU (checksum, compresión) y exige RAM dedicada — regla práctica de aproximadamente 1 GB de RAM por TB de almacenamiento, más aún si se habilita la deduplicación (recomendamos evitar dedup en producción en la mayoría de los casos).

• Un HBA sin caché de escritura propia puede penalizar cargas con muchas escrituras síncronas — típico de bases de datos Oracle — a menos que se agregue un dispositivo SLOG dedicado en NVMe u Optane.

• En arrays muy llenos, el resilver (reconstrucción) de ZFS puede ser más lento que un rebuild de RAID en hardware, aunque las versiones recientes de OpenZFS han avanzado bastante en ese punto.

Recomendación de arquitectura: nunca colocar una controladora RAID en modo hardware detrás de ZFS — eso enmascara el acceso directo a los discos que ZFS necesita para funcionar correctamente. El camino correcto es siempre HBA en modo IT, con SLOG dedicado cuando la carga de trabajo exija baja latencia de escritura síncrona.

8. Seguridad e integridad de datos

Si en rendimiento el resultado es "depende del dimensionamiento", en integridad de datos la ventaja de ZFS es inequívoca:

• Checksum de punta a punta en cada bloque: el RAID en hardware tradicional no detecta corrupción silenciosa de datos (bit rot). ZFS la detecta y, habiendo redundancia, se autocorrige durante un scrub programado.

• Eliminación del write hole: el diseño copy-on-write de RAIDZ evita la ventana de corrupción presente en el RAID 5/6 tradicional en caso de caída de energía durante una escritura.

• Snapshots nativos: instantáneos, prácticamente sin costo de espacio en el momento de la creación (gracias al COW) — un diferencial enorme para estrategias de backup y recuperación ante desastres.

• Sin dependencia de hardware propietario: como ya se detalló, la recuperación no depende de una controladora compatible — reforzando el mismo punto de portabilidad desde otro ángulo, ahora el de integridad bajo falla.

Para operaciones que manejan bases Oracle, sistemas PACS de imagen médica o cualquier carga de trabajo donde la corrupción silenciosa es inaceptable, este argumento de integridad tiende a pesar tanto como — o más que — el ahorro financiero, especialmente en auditorías de cumplimiento.

Conclusión: una decisión de arquitectura, no solo de costo

La migración de RAID en hardware + ESXi a barebone + Proxmox con ZFS no es solo una forma de recortar costos — aunque el ahorro combinado en hardware y licenciamiento normalmente ya justifica el proyecto por sí solo. Es un cambio estructural en cuatro frentes que se refuerzan mutuamente:

1. Resiliencia operacional real, porque el pool de datos no está atado a un hardware específico y puede ser recuperado en cualquier lugar, en minutos;

2. Independencia de proveedor, porque una pieza de repuesto commodity sustituye la dependencia de un lead time incierto de controladora propietaria;

3. Crecimiento sin trauma, porque el pool acompaña la expansión del cliente sin exigir destrucción y reconstrucción completa del storage;

4. Competitividad de mercado, porque una base de costo menor se traduce directamente en margen disponible para quien revende infraestructura, en un mercado de nube cada vez más presionado por precio.

Como siempre reforzamos en los proyectos de migración que conducimos: la gobernanza de la infraestructura debe venir antes de la elección de tecnología. ZFS no es la respuesta correcta para todo escenario, pero para quien ya paga el precio del licenciamiento tradicional, quiere previsibilidad presupuestaria, resiliencia real ante desastres y margen para competir — la cuenta cierra en todos los frentes.

Nyverra conduce migraciones de VMware/ESXi a Proxmox con arquitectura ZFS, incluyendo dimensionamiento de hardware, planificación de storage y migración asistida de cargas de trabajo críticas. Habla con nuestro equipo para un análisis de viabilidad de tu entorno.