Almacenamiento basado en S3, con costes un 22 % inferiores a los del almacenamiento de objetos, funciones y acceso estándar del sistema de archivos y el máximo rendimiento posible.
El reto: Migrar cargas de trabajo basadas en archivos a la nube
Estás inmerso en tu proceso de migración a la nube. Tienes una aplicación —quizás una entre miles— que aún se ejecuta en almacenamiento tradicional basado en archivos. Ahora te enfrentas a una decisión importante: ¿cómo migrarla a la nube sin comprometer el rendimiento, la colaboración ni tus objetivos presupuestarios?
Históricamente, han existido tres opciones:
Opción 1: Refactorizar a almacenamiento de objetos
A primera vista, esta parece la opción "nativa de la nube". El almacenamiento de objetos compatible con S3 es económico, sencillo de aprovisionar y requiere poca infraestructura.
Pero la realidad es mucho más compleja.
El problema: complejidad, coste y dependencia.
La refactorización de aplicaciones heredadas para el almacenamiento de objetos consiste en:
- Pérdida de 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; es un esfuerzo que dura décadas.
- Costoso: Es posible que ahorres en infraestructura, pero que gastes significativamente en desarrollo de software, pruebas y mantenimiento a largo plazo.
- Alta latencia, bajo IOPS: El almacenamiento de objetos no está diseñado para cargas de trabajo de baja latencia y alto volumen de transacciones que requieren cientos de miles o millones de pequeñas lecturas y escrituras. Tendrá dificultades con cargas de trabajo que esperan ejecutarse en sistemas de archivos de alto rendimiento.
- Operativamente complejo: Para las aplicaciones que no controlas (por ejemplo, software de terceros o de proveedores obsoletos), la refactorización puede resultar imposible. Esto te obliga a usar una puerta de enlace de archivos (tema que abordaremos a continuación) o a crear flujos de trabajo personalizados que transfieran datos del almacenamiento de objetos a un sistema de archivos local, solo para luego volver a escribirlos, lo que aumenta los costos, la latencia y los riesgos de sincronización.
- Dependencia del proveedor de la nube: A medida que refactorizas para API de almacenamiento de objetos específicas, te vuelves estrechamente dependiente de un proveedor de nube en particular.
Sí, hay aspectos positivos…
- bajos costos de infraestructura
- Almacenamiento duradero y resistente
- Fácil de implementar
…pero estos inconvenientes no compensan los desafíos que presentan la mayoría de las cargas de trabajo basadas en archivos.
Opción 2: Migración directa mediante File Gateway
Otro enfoque común es utilizar una puerta de enlace de archivos para conectar su aplicación basada en archivos al almacenamiento de objetos sin cambios en el código.
El inconveniente: Rendimiento deficiente y altos costes de API
- Escala: Las pasarelas suelen implementarse como máquinas virtuales o hosts individuales que ejecutan una capa de abstracción de protocolo, con servicios NFS o SMB que actúan como intermediarios para las API de almacenamiento de objetos. Incluso con una caché local, el ancho de banda y la capacidad de cómputo máximos que un solo host puede proporcionar limitan su uso. Esto las hace poco prácticas para cargas de trabajo a gran escala, como computación de alto rendimiento (HPC), entrenamiento de IA o renderizado 3D.
- Limitaciones de un solo escritor: Aunque se implementaran varias puertas de enlace para superar las limitaciones de escalabilidad, la mayoría de las puertas de enlace de archivos no pueden compartir el acceso de forma segura entre distintas ubicaciones. Esto imposibilita la colaboración en tiempo real y, lo que es peor, introduce un riesgo de corrupción de datos en el repositorio de objetos, ya que varias puertas de enlace leen y escriben desde sus propias vistas en caché de los datos.
- Sobrecarga de la llamada a la API: Debido a que las pasarelas traducen las operaciones de archivos en llamadas a la API de S3, sus costos se disparan, especialmente para aplicaciones con gran cantidad de metadatos o poca actividad de archivos.
- Compatibilidad de aplicaciones: Muchas aplicaciones se crearon y diseñaron para ejecutarse en sistemas de archivos locales y se escalaron a nivel empresarial ejecutándolas en un NAS de nivel empresarial. A menudo, no toleran implementaciones incompletas o inconsistentes de SMB o NFS que no se ajusten al contrato proporcionado por el servidor NFS oficial de Linux o el servidor de archivos de Windows, lo cual es común en gateways que utilizan pilas de protocolos de código abierto o controladores FUSE.
¿Aspectos positivos?
- Rápido de implementar
- No requiere cambios en la aplicación.
Aun así, este enfoque deja mucho que desear, especialmente a gran escala o en 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 archivos a la nube.
El problema: Costos elevados, escala limitada y despliegues aislados.
- Costoso: Debido a que son traslados de servidores de almacenamiento locales a la nube, requieren almacenamiento en bloque aprovisionado las 24 horas del día, los 7 días de la semana (como EBS), lo que resulta en costos extremadamente altos en comparación con el almacenamiento de objetos, especialmente a gran escala.
- Escala limitada: Algunos servicios de "almacenamiento de archivos en la nube" son, en realidad, hardware de terceros que se ejecuta en centros de datos en la nube, lo que genera problemas de capacidad, ya que la cadena de suministro, la semántica de implementación y el aprovisionamiento son independientes de las configuraciones estandarizadas de hardware y racks que utilizan el almacenamiento de objetos y otros servicios nativos. Otros servicios se ven afectados porque simplemente no pueden superar la limitación de almacenamiento de una sola máquina virtual, que alcanza un máximo de unos pocos cientos de TB, o porque las pilas de software no son compatibles con más almacenamiento. En consecuencia, es necesario fragmentar los datos en múltiples instancias, lo que conlleva una gestión más compleja.
- Funciones limitadas: Muchos de los servicios de archivos nativos de la nube de primera mano son implementaciones propias y, por lo tanto, utilizan un solo protocolo y carecen de las características de nivel empresarial a las que está acostumbrado en los sistemas locales (es decir, instantáneas, cuotas, registro de auditoría, replicación, control de acceso).
- No elástico: Por otro lado, las versiones en la nube de pilas de software locales existentes suelen ser adaptaciones de software diseñado para ejecutarse en un centro de datos prácticamente estático con hardware de servidor también prácticamente estático. El software no se diseñó para añadir y eliminar nodos bajo demanda. Tampoco se concibió para gestionar una capacidad de almacenamiento de objetos prácticamente infinita y con una asignación limitada. Por ello, muchas de estas soluciones requieren decisiones definitivas al inicio del aprovisionamiento y no ofrecen la posibilidad de escalar el rendimiento cuando sea necesario, ni de reducirlo cuando no lo sea, ni de liberar el almacenamiento (para dejar de pagar por él) cuando cambien los requisitos.
¿Aspectos positivos?
- Rápido de implementar
- No es necesario refactorizar
- Infraestructura administrada
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 a menudo resultan insuficientes.
La mejor solución de archivos en la nube
¿Y si no tuvieras que elegir entre rendimiento, coste y sencillez?
Cloud Native Qumulo ofrece una plataforma de almacenamiento de archivos verdaderamente moderna, creada de forma nativa para la nube, diseñada para ejecutar cargas de trabajo basadas en archivos con la economía de S3, con mejor rendimiento y menos concesiones.
¿Por qué Cloud Native Qumulo?
✅ No se requiere refactorización
Traslade sus cargas de trabajo existentes basadas en archivos a la nube, tal cual están. La experiencia del usuario final también se mantiene igual.
✅ Integración nativa con S3
Benefíciese de la durabilidad y redundancia internas de S3, sin necesidad de refactorizar su aplicación para que utilice la programación orientada a objetos.
✅ Verdaderamente multiprotocolo
Acceda a los mismos datos utilizando NFS, SMB o S3, sin silos de datos.
✅ Colaboración global con CDF (Cloud Data Fabric)
Colabora al instante entre regiones o nubes. No requiere replicación. Simplemente funciona.
✅ Escala elástica
Empieza con poco y escala hasta más de 10 EB. El rendimiento crece con la capacidad: hasta 1.6 TB/s de rendimiento y 20 millones de IOPS.
✅ Costo total de propiedad un 80 % menor
En comparación con los sistemas de archivos en la nube tradicionales, Qumulo reduce drásticamente el coste total mediante:
- Almacenamiento en caché inteligente (reducción de costes de la API S3)
- Compresión (reducción de datos almacenados en S3)
- Mejor eficiencia de almacenamiento
✅ Rendimiento superior al de la API de S3 por sí sola
Incluso utilizando la API de S3, Qumulo supera al almacenamiento de objetos estándar.
Éxito en el mundo real: la industria aeroespacial a escala de petabytes.
Por este motivo, una empresa aeroespacial global optó por migrar sus cargas de trabajo de varios petabytes a Qumulo y obtuvo importantes beneficios:
✅ Costes de almacenamiento un 22 % inferiores en comparación con una aplicación totalmente refactorizada que utiliza S3 estándar.
✅ Menos llamadas a la API, gracias al almacenamiento en caché inteligente y a Cloud Data Fabric (CDF)
✅ Menor consumo de datos gracias a la compresión integrada
✅ No se requiere reestructuración/refactorización de aplicaciones heredadas
Tu siguiente paso: ¡Prueba Qumulo hoy mismo!
Tanto si trasladas una sola aplicación como miles, Qumulo te ofrece una base preparada para el futuro para ejecutar tus cargas de trabajo basadas en archivos en la nube, a un menor coste, con un mayor rendimiento y sin concesiones.
¿Listo para comenzar?
Envíenos un correo electrónico a aws@qumulo.com o visítenos en el AWS Marketplace Para lanzar su implementación hoy mismo.
