Descubra cómo convertir AWS EBS sc1 en un poderoso medio de almacenamiento para sus cargas de trabajo de producción.
A principios de 2020, recibimos comentarios de nuestros clientes de que querían almacenar más datos de archivos en la nube en Qumulo, pero el costo de la infraestructura de AWS EBS st1 se disparó a medida que superaban los 50 TB aproximadamente. Desglosamos el costo de nuestra solución, lo analizamos desde muchos ángulos diferentes y vimos que, a medida que aumentaba la capacidad, el costo estaba dominado por EBS. Más tarde ese año, después de más pruebas y algunos cambios en la forma en que nuestro producto maneja los discos de alta latencia, pudimos ofrecer configuraciones que redujeron el precio en hasta el 70%. Como hicimos eso?
En primer lugar, algunos antecedentes.
Qumulo en AWS usa volúmenes EBS gp2 para SSD y volúmenes st1 para HDD
La Plataforma de datos de archivos Qumulo es un sistema de archivos distribuido de alta disponibilidad que se ejecuta en varios nodos configurados de forma idéntica en un clúster. Cada nodo del clúster es un participante igual, y otras máquinas o usuarios que necesiten acceder a los datos en un sistema Qumulo pueden hacerlo desde cualquier nodo, y todos verán exactamente el mismo estado.
Esto le permite escalar para servir a miles de clientes conectados, y algunas configuraciones pueden alcanzar más de 1 millón de IOPS y decenas de GB / s. Sus datos están protegidos contra la pérdida de un volumen de EBS (EBS anuncia una tasa de falla anual de 0.1% -0.2%) y aún es accesible incluso si un nodo se reinicia o se apaga temporalmente (es decir, para mantenimiento).
Los dos modos principales de operación de Qumulo son todos SSD, lo que significa que sus datos se escriben y leen desde SSD y nunca se mueven a ningún otro lugar. Piense en esto como una plataforma de un solo nivel diseñada para proporcionar una latencia baja constante para cosas como la edición, reproducción y renderizado de videos. También tenemos un modo de dos niveles que consiste en una capa delgada de SSD que actúan como un caché persistente, y el "almacenamiento" está respaldado por un gran banco de HDD de menor costo. Esta fue la configuración en la que nos enfocamos en hacer más rentable para los clientes.
Nuestro producto AWS utiliza volúmenes EBS gp2 para SSD y volúmenes st1 para HDD. A medida que aumenta la capacidad de su clúster Qumulo de 50 TB a 100 TB, 200 TB a 400 TB, el costo de st1 comienza a dominar el costo de toda la solución. Y se vuelve caro muy rápido. (RELACIONADO: Cómo presupuestar y controlar los costos para una estrategia de datos de alto rendimiento)
Ahora, si sabe algo sobre AWS EBS, es posible que sepa que AWS tiene otra clase de disco duro menos costosa llamada sc1. Se anuncia como: "Estos (sc1) son ideales para cargas de trabajo a las que se accede con poca frecuencia con conjuntos de datos grandes y fríos con grandes tamaños de E / S, donde el atributo de rendimiento dominante es el rendimiento (MiB / s)".
Qumulo experimentó con sc1 desde el principio, pero vio datos preocupantes. La latencia fue mucho mayor y el costo no pareció reflejar la diferencia de rendimiento.
Pruebas de rendimiento IO Latency sc1 vs st1 a principios de 2020
| Leer | Escribe. | |
| Secuencial | + 72% | + 159% |
| Aleatorio | + 162% | + 213% |
Además, ya sabíamos que nuestro rendimiento se vio afectado por la sobrecarga de latencia de IO de EBS conectado a la red. Algunas pruebas anecdóticas con nuestro software tampoco parecían prometedoras. Presentamos sc1 como demasiado arriesgado para sugerirlo a los clientes. en ese momento.
Los clientes quieren almacenamiento empresarial rentable en AWS EBS sc1
A fines del año pasado, Qumulo volvió a mirar después de haber pasado varios ciclos de desarrollo largos y costosos ajustando el rendimiento de su sistema. Y, como teníamos clientes que nos pedían específicamente sc1, dijimos; bueno, intentémoslo una vez más. Hicimos algunas pruebas, encontramos algunos cuellos de botella en nuestro código que deberíamos ajustar y luego comenzamos a realizar evaluaciones comparativas para tener una idea de dónde aterrizamos.
Nos sorprendió gratamente.
El rendimiento máximo de transmisión múltiple en un clúster con sc1 como respaldo coincidió y ocasionalmente superó el rendimiento de un clúster equivalente que ejecuta st1. Si bien nos damos cuenta de que esto no siempre sucederá para todas las cargas de trabajo, muestra hasta dónde ha llegado nuestra tecnología para ayudar a enmascarar el efecto del uso de niveles de almacenamiento rentables en un sistema de archivos empresarial.
Niveles rentables en un sistema de archivos empresarial
Una muestra de sc1 versus st1 en 2021
| Médico | Costo mensual de infraestructura de AWS (us-west-2) | MB / s de escritura de transmisión múltiple máxima | Lectura máxima de transmisión múltiple (en caché o desde SSD) MB / s | Lectura máxima de transmisión múltiple desde HDD MB / s |
| M5.12xgrande 4x55TiB st1 | $17,989.28 | 1635 MiB / s | 3192 MiB / s | 3202 MiB / s |
| M5.12xgrande 4x55TiB sc1 | $ 11,230.88 (-37%) | 1683 MiB / s | 3135 MiB / s | 3194 MiB / s |
Los valores de la tabla anterior se proporcionan solo con fines informativos y son representativos de una única prueba de flujo múltiple Qumulo realizada con un clúster de 4 nodos e instancias m5.12xlarge. El precio variará según los acuerdos empresariales y la región de implementación deseada. El rendimiento puede variar según la latencia de la red, el tipo de instancia y el número de nodos.
¿Cómo es esto posible hoy?
Desde sus inicios, Qumulo se ha centrado en optimizar el producto y mejorar el rendimiento. Con nuestra solución definida por software, la única palanca que hay que tirar es hacer que nuestro software sea más inteligente, mejor y más rápido. Esto puede parecer una desventaja (¿por qué no hacer trampa con hardware propietario?), Pero la ventaja es que obtenemos este valor y esfuerzo en todas partes, no solo en las instalaciones.
La optimización en Qumulo significa que:
- Escribe siempre en flash, punto final. Nunca involucramos discos duros lentos en el camino rápido para escribir datos.
- Almacenar siempre en caché todos los datos que también escribe en la memoria, en caso de que solicite los mismos datos de nuevo, ni siquiera tenemos que leer un disco o pedir a otros nodos los mismos datos.
- Mover datos al disco duro en segundo plano, fuera de la vista, fuera de la mente, según sea necesario, automáticamente. Piense en esto como una organización en niveles automatizada para un almacenamiento más económico. Siempre movemos los datos más fríos, y lo hacemos bajo el sistema de archivos, a nivel de bloque. Por lo tanto, si está ejecutando el comando de archivo de Linux una y otra vez y solo lee los primeros 4 KB de un archivo, trataremos ese primer bloque como activo y el resto del archivo como no activo. Esto maximiza el uso de la caché SSD.
- Pruebe SSD cuando solicite datos que no estén en caché. Si no está en SSD, lo leemos desde el HDD, pero también comenzamos a buscar previamente el siguiente bloque en un archivo para que ya esté en nuestra memoria caché si aún no lo ha solicitado. ¿Por qué? Para adelantarte antes de que lo pidas. Esto hace que la lectura desde el disco duro parezca rápida, porque está enmascarada por el prefetcher. También hacemos esto si está leyendo archivos secuencialmente en un directorio.
- Mueva los bloques que ha leído del HDD varias veces, de vuelta al SSD. ¿Por qué? No hay razón para mantenerlo en el medio más lento si va a seguir solicitando esos datos. Lo promocionamos automáticamente para usted, no se requieren ajustes ni políticas.
- Optimice nuestro sistema de asignación de bloques para que no haya tiempo de esperar a que una dirección escriba datos.
- Poseer casi toda la pila de código para todo en el producto, hasta las estructuras de datos y algoritmos. Podemos ajustar un tipo incorrecto o un mapa hash que golpea líneas de caché defectuosas como a nadie. Incluso escribimos las implementaciones de NFS y SMB desde cero, y podemos ajustar todo de arriba hacia abajo en nuestra pila.
- Ejecutar completamente en el espacio de usuario, tenga nuestro propio programador de tareas para evitar el cambio de contexto del kernel y haga todo a través de E / S asíncrona.
Convirtiendo AWS EBS sc1 en un poderoso medio de almacenamiento para sus cargas de trabajo de producción
Se necesita tiempo para construir un sistema de almacenamiento escalable como la plataforma de datos de archivos de Qumulo. Pero el valor de hacer esto se nota. Convertimos de manera efectiva sc1, un tipo de volumen de EBS que Amazon no recomienda para "cargas de trabajo activas", en un poderoso medio de almacenamiento para sus cargas de trabajo de producción. A $ 0.015 por GiB-mes, y S3 a $ 0.021 por GiB-mes en el más barato, EBS sc1 es en realidad un 28% menos que el estándar S3, ¡y eso es solo almacenamiento! S3 cobra por llamadas a API además del almacenamiento.
Más información
- Reduzca los costos y gane flexibilidad en AWS con Qumulo Cloud Q
- Qumulo en AWS: servicios de video en la nube para M&E Creative Studios
