1.6 TB/s en AWS NO ES EL TITULAR para Cloud Native Qumulo

Cloud Native Qumulo escaló a 1,6 TB/s en AWS, y eso ni siquiera es lo mejor. Esto es lo que significa para ti.

Durante años, los clientes empresariales han expresado la misma preocupación por la nube:

"Simplemente no es lo suficientemente rápido"
"Aunque lo fuera, no podemos tener de forma fiable suficiente computación en una zona de disponibilidad"

Un cliente lo expresó claramente:

"Necesitamos superar los 1,5 TB/s de rendimiento sostenido en la nube, sin sacrificar la fiabilidad ni la flexibilidad"

La "B" mayúscula de TB importa. Se trata de bytes, no de bits. Un byte equivale a ocho bits, por lo que 1,5 TB/s se traduce en unos 12 terabits por segundo de movimiento sostenido de datos. Y sostenido es igual de importante. No se trata de una ráfaga efímera ni de un pico asistido por la caché, sino de un rendimiento continuo que se mantiene a lo largo del tiempo. 

Para poner esta cifra en contexto, el streaming de una sola película 4K suele requerir unos 25 megabits por segundo. A 12 Tb/s, el mismo sistema podría soportar teóricamente casi medio millón secuencias 4K simultáneas.

Y para aquellos que se lo estén preguntando, Qumulo CNQ estuvo a la altura del desafío, alcanzando 1,6 TB/s y 20,7 millones de IOPS, pero hablaremos de ello más adelante. 

De hecho, las cifras de rendimiento por sí solas nunca fueron la verdadera preocupación. Pocas empresas necesitan hoy 1,5 TB/s, pero la experiencia nos dice que planificar sólo para la demanda actual rara vez acaba bien. Construir sistemas de alto rendimiento a partir de recursos en la nube suele ser una cuestión de presupuesto, tolerancia al riesgo y fragilidad del sistema. De hecho, construir sólo para la velocidad es una gran manera de llegar a tutearse con el director financiero en muchas organizaciones, y no en el buen sentido. Combinar la velocidad con una arquitectura de infraestructura frágil puede resolver temporalmente un reto, pero crea muchos retos tecnológicos y económicos adicionales como efectos en cadena.

Resolver el problema de fondo de la flexibilidad arquitectónica requiere una nueva forma de pensar. 

La mayoría de las plataformas de almacenamiento en nube obligan a los clientes a tomar decisiones tempranas sobre la infraestructura a largo plazo. El rendimiento, la disponibilidad y el coste están estrechamente ligados, lo que obliga a sobreaprovisionar para los picos de demanda, duplicar datos para aumentar la resistencia o anclar cargas de trabajo a ubicaciones específicas. Una vez tomadas estas decisiones, es difícil y caro deshacerlas.

Como resultado, el almacenamiento se convierte en la limitación en torno a la cual planifican los equipos informáticos, en lugar de ser una base flexible que se adapta a las cargas de trabajo cambiantes.

La mejor pregunta que deberían hacerse los clientes no es: "¿A qué velocidad puede ir esto?"

Se trata de lo siguiente: ¿Puede la nube ofrecer un rendimiento extremo cuando lo necesito, sin encerrarme en arquitecturas frágiles, almacenamiento duplicado o infraestructuras permanentemente sobreaprovisionadas?

Qumulo se tomó en serio ese reto. No persiguiendo un titular, sino probando un modelo operativo diferente. Y por eso 1,6 TB/s NO ES EL TITULAR. Usted podría preguntarse: "Qumulo, si escalar a 1,6 TB/s en AWS, no es el titular, ¿qué es?"

¿Y si el verdadero titular no fuera en absoluto la velocidad, sino la eliminación de las limitaciones zonales sin pagar un impuesto económico?

La respuesta empieza por una arquitectura nativa de la nube, no una readaptada.

1import os
2import sys
3from datetime import datetime
4import libnfs
5
6os.environ['LD_LIBRARY_PATH'] = "/var/task/lib:/var/task/libnfs:" + os.environ.get('LD_LIBRARY_PATH', '')
7sys.path.append('/var/task')
8
9def handler(event, context):
10    try:
11        nfs = libnfs.NFS("nfs://YOUR_CNQ_ADDRESS/YOUR_NFS_EXPORT")
12    except Exception as e:
13        return {"statusCode": 500, "body": "Error connecting to NFS export: " + str(e)}
14    
15    try:
16        timestamp = datetime.now().isoformat()
17        message = f"Hello from AWS Lambda via CNQ! - {timestamp}\n"
18        
19        f = nfs.open("/testing-from-lambda.txt", "w+")
20        f.write(message)
21        f.close()
22    except Exception as e:
23        return {"statusCode": 500, "body": "Error writing to file: " + str(e)}
24    
25    try:
26        f = nfs.open("/testing-from-lambda.txt", "r")
27        content = f.read()
28        return {"statusCode": 200, "body": content}
29    except Exception as e:
30        return {"statusCode": 500, "body": "Error reading file: " + str(e)}
31
32Built for the Cloud from the Beginning

La arquitectura de Qumulo fue diseñada para la nube, no adaptada a ella. Esa distinción es importante.

La mayoría de los sistemas de almacenamiento de archivos en la nube no fracasaron debido a una mala ejecución. Fracasaron porque heredaron supuestos de una era definida por el hardware y nunca se rediseñaron completamente para operaciones basadas en la nube.

Los sistemas de archivos tradicionales se basaban en una simple verdad física: el hardware de almacenamiento definía tanto la capacidad como el rendimiento. Más discos significaba más espacio, y más espacio significaba más rendimiento. La capacidad y el rendimiento estaban físicamente unidos. No se podía escalar de forma significativa uno sin el otro. Este modelo tenía mucho sentido cuando las empresas compraban discos giratorios, instalaban servidores en bastidores y cableaban sus propias redes.

Cuando los proveedores de servicios en la nube introdujeron los servicios de gestión de archivos, muchos de esos mismos supuestos se mantuvieron.

Algunos servicios escalan la capacidad automáticamente, pero el rendimiento sigue ligado a la cantidad de datos almacenados. Otros requieren que los clientes proporcionen capacidad y rendimiento como atributos fijos. La elasticidad existe, pero está limitada por el mismo acoplamiento que existía en las instalaciones.

Como el rendimiento y la capacidad siguen estando vinculados, los clientes se quedan con dos opciones poco atractivas:

• Provisión para el pico: pagar el máximo rendimiento y capacidad en todo momento, incluso cuando la utilización es baja

• Provisión para la media: ahorrar dinero hasta que las cargas de trabajo chocan contra un muro y el rendimiento se convierte en el cuello de botella

La mayoría de los equipos eligen la primera opción porque el coste de las cargas de trabajo ralentizadas o el incumplimiento de los plazos supera con creces el coste del sobreaprovisionamiento puede necesidad es lo contrario de la economía de la nube.

El problema se agrava cuando entra en escena la diversidad de protocolos. Los entornos Linux esperan NFS. Los entornos Windows requieren SMB. Las aplicaciones modernas dependen cada vez más del acceso a objetos a través de API compatibles con S3.

El resultado es la fragmentación. Diferentes servicios, diferentes modelos de escalado, diferentes comportamientos operativos. Los equipos que ejecutan cargas de trabajo mixtas suelen gestionar varios sistemas de almacenamiento, cada uno optimizado para un caso de uso limitado.

Con el tiempo, el almacenamiento se convierte en la limitación en torno a la cual planifican los equipos informáticos.

"¿De cuánto almacenamiento disponemos?" Preguntan: "¿Qué podemos ejecutar?"

Esto es al revés. La infraestructura debe adaptarse a las cargas de trabajo, no al revés.

Cloud Native Qumulo rompe ese acoplamiento.

Desde el principio, CNQ separó por diseño el rendimiento de la capacidad. El cálculo se escala independientemente del almacenamiento de objetos duraderos, y el rendimiento se añade o elimina ajustando los recursos informáticos en lugar de preasignando capacidad. Los clientes sólo pagan por el almacenamiento que consumen, mientras que el rendimiento se convierte en un atributo elástico en lugar de un compromiso fijo.

Esto permite a CNQ soportar servicios de archivos empresariales de uso general de forma económica, al tiempo que se adapta a cargas de trabajo especializadas y de alta intensidad sin forzar a los clientes a un sobreaprovisionamiento permanente o a silos de almacenamiento fragmentados.

Con esto queda claro el titular: CNQ diseñado para la nube, no adaptado a ella. Aun así, siento que me falta algo.

El reto: Ir más rápido que en las instalaciones, sin red de seguridad

La exigencia del cliente no era teórica.

En las instalaciones, la carga de trabajo se ejecutaba en un único centro de datos, con la informática situada cerca del almacenamiento para minimizar la latencia. Si fallaba la infraestructura, ya fuera la alimentación, la refrigeración o la red, la carga de trabajo se detenía. La recuperación ante desastres existía, pero, como la mayoría de los sistemas de recuperación ante desastres, era asíncrona, poco probada e incapaz de mantener el rendimiento completo de la carga de trabajo.

El sistema funcionaba, pero era frágil.

Tradicionalmente, el paso a la nube nunca ha tenido que ver con la velocidad. Se trataba de eliminar puntos únicos de fallo sin introducir nuevas limitaciones. Pero si pudiera ser rápido, ¿cómo afectaría eso a los negocios de nuestros clientes?

En la nube, las expectativas estaban claras:

• Superar el rendimiento en las instalaciones

• Evitar la dependencia de una única Zona de Disponibilidad

• Mantener el pleno rendimiento durante las averías

• Hágalo sin duplicar los costes de almacenamiento

Este último requisito es donde muchos sistemas de archivos en la nube se quedan cortos.

La mayoría de las ofertas de zonas de disponibilidad múltiple utilizan la replicación. Se mantienen copias completas de los datos en cada zona para proporcionar disponibilidad. Aunque es eficaz para la durabilidad, este enfoque tiene consecuencias reales. Los costes de almacenamiento aumentan linealmente con el número de zonas. El rendimiento de escritura se reduce debido a la coordinación entre zonas. Multi-AZ se convierte en algo que los clientes reservan para escenarios de fallo en lugar de para el funcionamiento normal.

Al mismo tiempo, la disponibilidad informática en la nube no está distribuida uniformemente.

Las cargas de trabajo intensivas en GPU y CPU a menudo se enfrentan a limitaciones de capacidad que varían según la zona y el tiempo. Un diseño que ancla los datos a una única zona obliga al cálculo a seguirla, incluso cuando existe capacidad en otras partes de la región. Los clientes acaban buscando instancias, reservando computación antes de que los datos estén listos (lo que resulta costoso) o retrasando el trabajo por completo (lo que alarga el plazo de obtención de resultados).

El cliente planteó a Qumulo el reto de la velocidad, la fiabilidad y la resistencia. La solución debía ofrecer un mayor rendimiento al tiempo que eliminaba la dependencia a nivel de zona, suprimía la duplicación del almacenamiento y permitía que las cargas de trabajo se ejecutaran dondequiera que hubiera capacidad informática disponible en un momento dado.

Qumulo resuelve ese problema a nivel arquitectónico, en lugar de superponer la disponibilidad a los supuestos heredados.

La arquitectura: Zona de disponibilidad múltiple por diseño, no por duplicación

El núcleo de esta implementación era un clúster CNQ multi-AZ, distribuido uniformemente en tres zonas de disponibilidad dentro de una única región de AWS.

Una zona de disponibilidad, o AZ, es un conjunto físicamente separado de uno o más centros de datos dentro de una región de AWS. Cada AZ está diseñada para funcionar de forma independiente, con su propia alimentación, refrigeración y redes, aunque está conectada a otras AZ de la región a través de enlaces de gran ancho de banda y baja latencia. Esta separación permite que las aplicaciones sigan estando disponibles aunque se produzca una interrupción en todo el centro de datos.

Amazon S3 proporciona durabilidad a nivel regional, donde los datos se protegen automáticamente en varias instalaciones. Esta es la razón por la que AWS ofrece 11 nueves (99,999999999% de durabilidad), ampliamente considerado como el punto de referencia del sector para la protección de datos.

Por su diseño, la arquitectura de CNQ abarca varias zonas de disponibilidad de AWS sin requerir réplicas completas de los datos de los clientes en cada zona. Como resultado:

• El coste de almacenamiento es idéntico tanto si CNQ se ejecuta en una AZ como en varias

• El rendimiento de escritura no se ve penalizado por la replicación entre zonas

• El funcionamiento Multi-AZ es el estado normal, no un modo de fallo

Nota: Normalmente, los servicios multi-AZ cuestan el doble que sus implementaciones de una sola-AZ. Mantener el mismo coste supone un importante beneficio económico. 

Si una zona de disponibilidad deja de estar disponible, el clúster sigue funcionando en las zonas restantes sin pérdida de datos y sin necesidad de conmutar por error a una copia secundaria.

Este diseño es más sencillo, rápido y materialmente más barato que los enfoques multi-AZ basados en réplicas.

Sería fácil hacer de esto el titular: La arquitectura CNQ ofrece resistencia multizona sin duplicación de datos. No está mal. Pero podemos hacerlo aún mejor. 

La ventaja de la zona de disponibilidad múltiple CNQ para cargas de trabajo intensivas en GPU

Multi-AZ suele considerarse una función de disponibilidad, lo cual está bien, pero hoy en día la disponibilidad se considera una apuesta segura. Lo que realmente importa es lo que CNQ aporta a la computación, es decir, hacer que la adquisición de GPU y CPU sea mucho menos dolorosa. 

La mayoría de los sistemas de archivos en la nube, incluso los comercializados como multi-AZ, anclan el almacenamiento a una única zona primaria. El cálculo debe seguir a los datos. Si las GPU o CPU no están disponibles en esa zona, la carga de trabajo se detiene, incluso cuando existe capacidad no utilizada en otra parte de la región.

Esto obliga a los equipos a buscar GPU y CPU. Primero, buscan instancias de cálculo escasas. A continuación, reservan y pagan por esos recursos antes de poder utilizarlos. Luego viene el problema de los datos. Los grandes conjuntos de datos deben copiarse o reubicarse en el lugar donde se encuentra el sistema informático. Sólo después de completar todos estos pasos puede reanudarse el trabajo. CNQ elimina esta limitación.

Con CNQ, la informática de varias zonas de disponibilidad puede acceder simultáneamente al mismo conjunto de datos. Los clientes pueden agregar capacidad entre zonas en un único grupo lógico sin necesidad de copiar o reorganizar los datos.

Si hay GPU disponibles en una zona el lunes y en otra el martes, los clientes no tienen que trasladar los datos ni reconstruir la infraestructura. Simplemente dirigen el despliegue CNQ existente a donde haya computación disponible.

Desde la perspectiva del cliente, esto permite:

• Acceso más rápido a GPU y CPU escasas

• Sin fases de reubicación o copia de datos

• Sin penalizaciones por replicación

• Sin aumento de los costes de almacenamiento

El trabajo puede comenzar inmediatamente porque los datos ya existen en cada zona de disponibilidad dentro de S3, que sirve como capa de almacenamiento persistente. A diferencia de Amazon Elastic Block Store (EBS) o el almacenamiento conectado a instancia, esta arquitectura no requiere copiar o rehidratar los datos en cada zona antes de que pueda comenzar la computación. En su lugar, el sistema de archivos accede a los datos localmente en cada AZ a través de NeuralCache. Este enfoque elimina los esfuerzos de preparación de datos de semanas de duración y mantiene los costosos recursos informáticos plenamente utilizados desde el principio.

Una vez más, puede que estés pensando: seguramente este tiene que ser el titular: CNQ y el arte de hacer soportable la caza de GPU. Vamos por buen camino. Veamos si podemos superarlo.

Aumente el rendimiento todo lo que quiera y luego redúzcalo

El cliente pidió superar los 1,5 TB/s de rendimiento sostenido en la nube, sin sacrificar la fiabilidad ni la flexibilidad. Qumulo creó un despliegue de prueba que finalmente superó las expectativas, logrando 1,6 TB/s de rendimiento agregado sostenido y 20,7 millones de IOPS. Efectivamente, estas cifras son impresionantes (futuros lectores, consulten la fecha de publicación para conocer el contexto), pero ¿se trata de requisitos máximos o medios? Y si usted es un cliente que está leyendo esto y está interesado en 1,6 TB/s y 20,7 millones de IOPS, no se preocupe, ¡lo tenemos! Véase más abajo.

Muchos clientes dan prioridad a la flexibilidad y necesitan poder ampliar o reducir los recursos en función de la demanda. Como ya se ha dicho, los clientes a menudo eligen entre aprovisionarse para los picos de demanda con un coste elevado o dimensionarse para un uso medio y arriesgarse a sufrir un déficit de rendimiento. Esta disyuntiva pone de relieve el valor fundamental de la nube: la variabilidad. Esta configuración puede costar unos 5.000 dólares por hora, lo que la hace valiosa cuando se necesita, pero poco práctica económicamente para funcionar de forma continua. La capacidad de consumir este nivel de rendimiento sólo cuando es necesario hace que un enfoque basado en la nube sea económicamente viable en comparación con la infraestructura local.

CNQ permite a los clientes alcanzar el máximo rendimiento sin tener que pagar siempre por la máxima capacidad. Esa es la diferencia.

Con muchos sistemas de archivos en la nube, el rendimiento está ligado a la capacidad aprovisionada permanentemente. Si se dimensiona para picos, se pagan precios de pico todo el tiempo, incluso cuando la carga de trabajo disminuye.

CNQ desvincula esas decisiones.

Los clientes pueden escalar el rendimiento de forma agresiva para cumplir un plazo, una ventana de formación o un aumento de la producción, y luego reducirlo una vez pasado el pico. No se encierra en una configuración de línea roja solo para cubrir picos ocasionales.

Esta elasticidad se aplica no sólo a la escala, sino también a la elección de instancias. En esta implantación, los tipos de instancia se ajustaron a mitad de diseño debido a limitaciones de capacidad regional. El clúster simplemente creció hasta 250 nodos, soportando aproximadamente 333.000 conexiones, utilizando un menor ancho de banda por nodo sin necesidad de ningún rediseño.

Posteriormente, los clientes pueden cambiar a familias de instancias más recientes a un coste inferior mediante la sustitución continua, sin tiempo de inactividad ni migración de datos.

Juntos hemos descubierto por fin el titular: CNQ ofrece Rendimiento máximo sin compromiso máximo. ¿Verdad? Pero, ¿por qué necesitaría alguien esta cantidad de rendimiento máximo? 

Los momentos que exigen un rendimiento máximo extremo

No todas las cargas de trabajo necesitan un rendimiento extremo, y de eso se trata exactamente.

Esta arquitectura no consiste en funcionar siempre a 1,6 TB/s. Se trata de tener la opción de funcionar a esa velocidad cuando el momento lo requiere. Se trata de tener la opción de funcionar a esa velocidad cuando el tiempo importa, sin verse penalizado económica u operativamente el resto del tiempo.

Lo que hoy parece excesivo tiene la costumbre de convertirse en el valor de referencia de mañana. Entonces, ¿por qué alguien necesitaría este rendimiento? 

Pensemos en una empresa energética que decide si va a arrendar un pozo de mil millones de dólares. La cuestión no es si el análisis cuesta unos millones más en gastos en la nube. La cuestión es quién llega antes a la respuesta. Llegar pronto puede determinar quién se asegura el activo y quién se va con las manos vacías.

En la atención sanitaria, un análisis genómico más rápido puede suponer la diferencia entre una incertidumbre prolongada y una decisión terapéutica que salve vidas.

En los medios de comunicación y el entretenimiento, la velocidad puede determinar si un proyecto cumple su plazo de lanzamiento o si los retrasos se convierten en una cascada de costes imprevistos que borran los márgenes de beneficio. Un renderizado, un análisis y una iteración más rápidos significan menos equipos creativos inactivos esperando en la infraestructura.

En todos estos ejemplos, la limitación no es la cantidad de datos que pueden almacenarse. Es el tiempo necesario para obtener información y tomar decisiones. Cuando la infraestructura proporciona respuestas más rápidamente, las organizaciones no sólo ejecutan las cargas de trabajo con mayor rapidez, sino que también obtienen resultados más rápidamente. Están comprimiendo ciclos de decisión completos y liberando más valor de su recurso más caro e insustituible, el tiempo humano de los expertos. 

Imagine lo que su empresa podría conseguir cuando el rendimiento aumente y disminuya, deje de pagar por el margen de inactividad y empiece a pagar por los resultados. 

Seguramente el titular debe ser: Deje de esperar en las infraestructuras. CNQ ofrece resultados más rápidamente. Pero, ¿realmente lo capta todo? 

El efecto acumulativo

Al ofrecer 1,6 TB/s de rendimiento de lectura secuencial agregada sostenida, Qumulo superó el objetivo de rendimiento original del cliente en más de un 50 % en comparación con los sistemas locales. Para lograr este nivel de rendimiento, fue necesaria una arquitectura nativa de la nube construida íntegramente sobre la infraestructura estándar de AWS y que abarcaba tres zonas de disponibilidad.

Y lo que es más importante, este trabajo demuestra que un rendimiento extremo no requiere compromisos inasequibles.

Además del rendimiento de 1,6 TB/s, el sistema alcanzó 20,7 millones de IOPS con una latencia inferior al milisegundo. 

Pero el valor real va más allá de las cifras. La arquitectura permite a los clientes aplicar la informática en todas las zonas de disponibilidad en lugar de limitarse a una única zona, lo que facilita considerablemente la adquisición de GPU y CPU a gran escala. También valida la capacidad de recuperación de CNQ en AWS, ofreciendo una disponibilidad de datos excepcional y once nueves de durabilidad, sin inflar los costes de almacenamiento a través de la duplicación. Los clientes conservan la flexibilidad de elegir familias de instancias que se ajusten a sus necesidades de rendimiento y presupuestos, pagando solo por lo que realmente utilizan.

En conjunto, estas capacidades crean un efecto acumulativo, lo que llamamos el Efecto acumulativo.

Quizá no sea un solo titular el que deba llamar su atención. Tal vez sean todos.

• Qumulo en la nube alcanza 1,6 TB/s en AWS 

• CNQ diseñado para la nube, no adaptado a ella

• La arquitectura CNQ ofrece resistencia multizona sin duplicación de datos

• CNQ y el arte de hacer soportable la caza de GPUs

• CNQ ofrece el máximo rendimiento sin el máximo compromiso

• Deje de esperar en las infraestructuras. CNQ ofrece resultados más rápidamente

Esa combinación es la historia.

Para llevar

Esta implantación demostró que un sistema de archivos nativo de la nube puede ofrecer un rendimiento extremo sin concesiones:

• Multi-AZ por diseño, no por duplicación

• Rendimiento que se amplía y se reduce

• Libertad para funcionar donde haya ordenadores disponibles, no donde estén los datos

• Resultados más rápidos 

La nube no sólo tiene que ser rápida. Con la arquitectura adecuada, puede ser más flexible, más resistente y más económica que los sistemas locales.