El cliente había hecho la tarea. Tres nodos Proxmox funcionando hacía más de un año, respaldo operativo, un administrador dedicado. Llegó con una decisión estudiada: implementar Ceph para eliminar el punto único de falla de su NAS y tener los datos completamente en sus propios servidores en Chile, con la Ley 21.719 en el horizonte.
El diagnóstico era correcto. La recomendación fue no implementarlo todavía.
Lo que cumplía y lo que no
El requisito que todos conocen estaba cumplido: tres nodos. Los dos que casi nadie evalúa, no.
El primero era la red. Los tres nodos se comunicaban por interfaces de 1 Gbps compartidas con el tráfico de las VMs, la gestión del clúster y el acceso al NAS. Ceph replica cada escritura entre nodos a través de la red. Sobre esa infraestructura, el rendimiento del almacenamiento distribuido habría sido notoriamente inferior al del NAS que pretendía reemplazar. El cliente habría pagado complejidad para obtener un retroceso — y la conclusión interna habría sido que Ceph no funciona, cuando lo que no funcionaba era la red debajo.
El segundo era la experiencia operacional. El administrador era competente en la operación diaria de Proxmox, pero nunca había gestionado almacenamiento distribuido. Los estados de recuperación de Ceph cuando un disco o un nodo falla tienen comportamientos específicos que el equipo necesita entender antes de tenerlos en producción. Ese conocimiento no se adquiere leyendo documentación durante una emergencia.
La recomendación con dos partes
La primera fue inmediata: mantener el NAS como almacenamiento principal y cerrar el riesgo real con la replicación integrada de Proxmox sobre ZFS para los cinco sistemas con datos más críticos. Con eso, si el NAS fallaba, lo más importante podía levantarse desde las réplicas locales mientras se recuperaba el resto. El riesgo del punto único de falla quedó reducido sin agregar la complejidad de Ceph.
La segunda fue un plan con condiciones verificables — no con fechas — hacia Ceph: renovar la red del clúster a 10 Gbps dedicados, construir un laboratorio con servidores de descarte donde el administrador pudiera provocar y resolver fallas simuladas de disco y de nodo, y recién entonces la migración planificada.
El costo de renovar la red resultó equivalente al quince por ciento del presupuesto que el cliente tenía reservado para Ceph. Presentado de esa forma, la inversión en red dejó de ser un gasto adicional y pasó a ser parte natural del proyecto, reordenado en el tiempo.
Lo que ocurrió
La replicación de las VMs críticas quedó operando en pocos días. La renovación de red se ejecutó meses después dentro del presupuesto normal de infraestructura. El administrador practicó con el laboratorio durante seis semanas, documentando cada procedimiento de falla y recuperación. La migración a Ceph ocurrió cerca de un año después de la conversación inicial: sobre la red correcta, con un operador que ya había visto los estados difíciles del sistema, sin sobresaltos.
El mismo destino, en otro orden. Esa es toda la diferencia.
Un no todavía con condiciones concretas no es un freno: es la ruta más corta hacia el sí que funciona.
¿Cuándo fue la última vez que un proveedor les recomendó no implementar algo que ya tenían decidido?
