Almacenamiento basado en S3, con un 22% menos de costes que el almacenamiento de objetos, funciones/acceso estándar al sistema de archivos y el mayor rendimiento posible
El reto: Migración de cargas de trabajo basadas en archivos a la nube
Está inmerso en su viaje de migración a la nube. Tiene una aplicación, quizá una de miles, que aún se ejecuta en el almacenamiento tradicional basado en archivos. Ahora se enfrenta a una gran decisión: ¿cómo migrarla a la nube sin comprometer el rendimiento, la colaboración o sus objetivos presupuestarios?
Históricamente, ha habido tres opciones:
Opción 1: Refactorización al almacenamiento de objetos
A primera vista, parece la ruta "nativa de la nube". El almacenamiento de objetos compatible con S3 es barato, fácil de aprovisionar y requiere poca infraestructura.
Pero la realidad es mucho más compleja.
La trampa: Complejidad, coste y bloqueo
Refactorizar aplicaciones heredadas para el almacenamiento de objetos es:
Lleva mucho tiempo: Reescribir el código para que admita la semántica de objetos en posiblemente decenas de miles de aplicaciones no es un trabajo de fin de semana, sino una tarea de décadas.
Caro: Puede que ahorre en infraestructura, pero gastará mucho en desarrollo de software, pruebas y mantenimiento a largo plazo.
Alta latencia, baja IOPS: El almacenamiento de objetos no está diseñado para cargas de trabajo de baja latencia que requieran entre cientos de miles y millones de pequeñas lecturas y escrituras. Tendrá problemas con las cargas de trabajo que esperan ejecutarse en sistemas de archivos de alto rendimiento.
Complejidad operativa: Para las aplicaciones que no controlas (por ejemplo, software de terceros o de proveedores obsoletos), la refactorización puede ser imposible. Esto le obliga a utilizar una pasarela de archivos (próximo tema) o a crear flujos de trabajo personalizados que hidraten los datos desde el almacenamiento de objetos a un sistema de archivos local, para volver a escribirlos de nuevo, lo que añade costes, latencia y riesgos de sincronización.
Bloqueo del proveedor de la nube: Al refactorizar para API de almacenamiento de objetos específicas, se vincula estrechamente a un proveedor de nube concreto.
Sí, hay aspectos positivos..
Bajos costes de infraestructura
Almacenamiento duradero y resistente
Fácil de desplegar
...pero no superan los retos para la mayoría de las cargas de trabajo basadas en archivos.
Opción 2: Lift-and-Shift a través de File Gateway
Otro enfoque común es utilizar una pasarela de archivos para conectar su aplicación basada en archivos al almacenamiento de objetos sin cambios en el código.
El problema: Bajo rendimiento y altos costes de API
Escala: Las pasarelas suelen implementarse como máquinas virtuales individuales o hosts que ejecutan una capa de abstracción de protocolos, ejecutando servicios NFS o SMB que se sitúan delante de las API de almacenamiento de objetos. Incluso con una caché local, estás limitado por el ancho de banda máximo y el cálculo máximo que puede proporcionar un único host. Esto los hace poco prácticos para cargas de trabajo a gran escala como HPC, formación de IA o renderizado 3D.
Limitaciones de un solo escritor: Incluso si tuviera que ejecutar varias pasarelas para superar las limitaciones de escalado, la mayoría de las pasarelas de archivos no pueden compartir de forma segura el acceso entre varias ubicaciones. Esto descarta la colaboración en tiempo real y, lo que es peor, introduce un riesgo de corrupción de datos en la cubeta de objetos, ya que varias pasarelas leen y escriben desde sus propias vistas en caché de los datos.
Sobrecarga de llamadas a la API: Dado que las pasarelas traducen las operaciones de archivos en llamadas a la API de S3, los costes se disparan, especialmente en el caso de aplicaciones con muchos metadatos o poca actividad de archivos.
Compatibilidad con aplicaciones: Muchas aplicaciones se crearon y diseñaron para ejecutarse en sistemas de archivos locales, y se ampliaron a las organizaciones ejecutándolas en un NAS de nivel empresarial. A menudo no toleran implementaciones SMB o NFS incompletas o incoherentes que no se adhieren al contrato proporcionado por el servidor NFS oficial de Linux o Windows File Server, algo habitual en las pasarelas que aprovechan las pilas de protocolos de código abierto o utilizan controladores FUSE.
¿Positivos?
Despliegue rápido
No requiere cambios en la aplicación
Aun así, este enfoque deja mucho que desear, especialmente a gran escala o entre equipos globales.
Opción 3: Utilizar un sistema de archivos en la nube
Los sistemas de archivos alojados en la nube, como Amazon FSx, EFS, Azure Files o Azure NetApp Files, prometen llevar la semántica de los archivos a la nube.
El problema: Costes elevados, escala limitada e implantaciones aisladas
Caro: Al ser puertos de servidores de almacenamiento on-prem en la nube, requieren almacenamiento en bloque aprovisionado 24/7 (como EBS), lo que se traduce en costes extremadamente elevados en relación con el almacenamiento de objetos, especialmente a escala.
Escala limitada: Parte del "almacenamiento de archivos en la nube" es en realidad hardware de terceros que funciona en centros de datos en la nube, lo que genera problemas de capacidad, ya que la cadena de suministro, la semántica de despliegue y el aprovisionamiento son independientes de las configuraciones estandarizadas de hardware y bastidores utilizadas por el almacenamiento de objetos y otros servicios nativos. Otros servicios sufren porque simplemente no pueden crecer más allá de la limitación de almacenamiento en una sola máquina virtual, que alcanza un máximo de unos cientos de TB, o porque las pilas de software simplemente no son capaces de soportar más almacenamiento. El resultado es tener que dividir los datos en varias instancias, lo que conlleva una gestión más compleja.
Características limitadas: Muchos de los primeros servicios de archivos nativos de la nube son implementaciones de cosecha propia y, por lo tanto, son de protocolo único y carecen de las funciones de nivel empresarial a las que está acostumbrado de los sistemas locales (es decir, instantáneas, cuotas, registro de auditoría, replicación, control de acceso).
Inelástica: Por otro lado, en el caso de las versiones alojadas en la nube de pilas de software existentes en las instalaciones, muchas adolecen de ser adaptaciones de software diseñadas para funcionar en un centro de datos principalmente estático en un hardware de servidor principalmente estático. El software no se diseñó para añadir y eliminar nodos bajo demanda. No se diseñó para poder hacer frente a una reserva infinita de capacidad de almacenamiento de objetos que se asigna de forma dispersa. Como tal, muchas de estas ofertas requieren decisiones unidireccionales por adelantado en el momento del aprovisionamiento, y no proporcionan ninguna capacidad de aumentar el rendimiento cuando es necesario, o reducirlo cuando no lo es, o desaprovisionar almacenamiento (para que pueda dejar de pagar por él) cuando cambian los requisitos.
¿Positivos?
Despliegue rápido
No es necesario refactorizar
Infraestructura gestionada
Sin embargo, si su caso de uso implica computación de alto rendimiento, colaboración global o conjuntos de datos de varios petabytes, estas soluciones suelen quedarse cortas.
La mejor solución de archivos en la nube
¿Y si no tuviera que elegir entre rendimiento, coste y simplicidad?
Cloud Native Qumulo ofrece una plataforma de almacenamiento de archivos verdaderamente moderna, creada específicamente para la nube y diseñada para ejecutar cargas de trabajo basadas en archivos a precios de S3, con mejor rendimiento y menos compromisos.
¿Por qué Qumulo nativo en la nube?
✅ No requiere refactorización
Lleve sus cargas de trabajo basadas en archivos existentes a la nube tal cual. La experiencia del usuario final sigue siendo la misma.
integración nativa con S3
Benefíciate de la durabilidad y redundancia de S3 bajo el capó, sin necesidad de refactorizar tu aplicación para hablar de objetos.
verdaderamente multiprotocolo
Accede a los mismos datos mediante NFS, SMB o S3, sin silos.
✅ Colaboración global con CDF (Cloud Data Fabric)
Colabore entre regiones o nubes al instante. Sin necesidad de replicación. Simplemente funciona.
✅ Escala elástica
Empiece con poco y escale hasta 10EB+. El rendimiento aumenta con la capacidad: hasta 1,6 TB/s de rendimiento y 20 millones de IOPS.
✅ Coste total de propiedad un 80
En comparación con los sistemas de archivos en la nube tradicionales, Qumulo reduce drásticamente el coste total mediante:
Almacenamiento inteligente en caché (reduce los costes de la API de S3)
Compresión (reducción de los datos almacenados en S3)
Mayor eficacia de almacenamiento
✅ Mayor rendimiento que la API de S3 por sí sola
Incluso cuando se utiliza la API de S3, Qumulo supera el almacenamiento de objetos estándar.
Éxito en el mundo real: Aeroespacial a escala de petabytes
Por este motivo, una empresa aeroespacial internacional decidió migrar sus cargas de trabajo de varios petabytes a Qumulo y obtuvo importantes beneficios:
✅ 22% menos de costes de almacenamiento en comparación con una app totalmente refactorizada que utiliza S3 estándar
✅ Menos llamadas a la API, gracias al almacenamiento inteligente en caché y a Cloud Data Fabric (CDF)
menor huella de datos gracias a la compresión integrada
✅ No es necesario modificar la arquitectura ni la refactorización de las aplicaciones heredadas
Su próximo paso: Pruebe Qumulo hoy mismo
Tanto si traslada una sola aplicación como miles de ellas, Qumulo le ofrece una base preparada para el futuro para ejecutar sus cargas de trabajo basadas en archivos en la nube, a un coste menor, con un mayor rendimiento y sin compromisos.
📩 ¿Listo para empezar?
Envíenos un correo electrónico a aws@qumulo.com o visítenos en AWS Marketplace para poner en marcha su implantación hoy mismo.