No hay duda de que Amazon es el líder cuando se trata de una variedad de servicios en la nube ofrecidos a través de su servicio web EC2 (Elastic Compute Cloud). Con un proceso de aprovisionamiento relativamente simple y la capacidad de escalar fácilmente las instancias y las necesidades de almacenamiento hacia arriba o hacia abajo, EC2 tiene como objetivo ofrecer toda la promesa de la nube a precios rentables. Sin embargo, para algunos, la nube no se trata solo de flexibilidad y facilidad de implementación; se trata de rendimiento. Los beneficios comerciales de poder activar o desactivar entornos potentes para aplicaciones críticas como análisis a menudo pueden superar con creces el gasto de hacerlo a través de OPEX en lugar de la inversión a largo plazo de CAPEX. Con ese fin, en mayo, Amazon GA presentó la familia de instancias bare metal i3 que brinda acceso directo a los recursos de CPU y memoria del servidor subyacente.
No hay duda de que Amazon es el líder cuando se trata de una variedad de servicios en la nube ofrecidos a través de su servicio web EC2 (Elastic Compute Cloud). Con un proceso de aprovisionamiento relativamente simple y la capacidad de escalar fácilmente las instancias y las necesidades de almacenamiento hacia arriba o hacia abajo, EC2 tiene como objetivo ofrecer toda la promesa de la nube a precios rentables. Sin embargo, para algunos, la nube no se trata solo de flexibilidad y facilidad de implementación; se trata de rendimiento. Los beneficios comerciales de poder activar o desactivar entornos potentes para aplicaciones críticas como análisis a menudo pueden superar con creces el gasto de hacerlo a través de OPEX en lugar de la inversión a largo plazo de CAPEX. Con ese fin, en mayo, Amazon GA presentó la familia de instancias bare metal i3 que brinda acceso directo a los recursos de CPU y memoria del servidor subyacente.
Las instancias i3.metal se basan en el sistema Nitro, que es una colección de componentes de protección de servidor y descarga de hardware creados por AWS que "proporcionan de forma segura recursos de red y almacenamiento de alto rendimiento a las instancias EC2". Las instancias i3.metal también aprovechan todos los demás servicios que ofrece AWS Cloud, como Elastic Block Store (EBS), que aprovechamos como parte de esta revisión. Las instancias también cuentan con hasta 15.2 TB de almacenamiento de instancia respaldado por SSD NVMe, así como procesadores Intel Xeon de 2.3 GHz que ofrecen 36 núcleos hiperprocesos (72 procesadores lógicos) y 512 GiB de memoria. En el lado de la estructura, las instancias i3.metal ofrecen hasta 25 Gbps de ancho de banda de red agregado, impulsando un alto rendimiento de red y una menor latencia a través de Enhanced Networking basado en Elastic Network Adapter (ENA).
Dentro de EC2, hay varios tipos de instancias. Las instancias i3 se encuentran dentro de la categoría "Almacenamiento optimizado", y las instancias i3.metal toman el relevo como las de mayor rendimiento de ese grupo. La siguiente tabla destaca la familia y la configuración de los tipos de instancia.
| Modelo | CPU virtual | Memoria (GiB) | Rendimiento de la red | Almacenamiento (TB) |
| i3.grande | 2 | 15.25 | Hasta 10 Gigabits | 1 SSD de 0.475 NVMe |
| i3.xgrande | 4 | 30.5 | Hasta 10 Gigabits | 1 SSD de 0.95 NVMe |
| i3.2xgrande | 8 | 61 | Hasta 10 Gigabits | 1 SSD de 1.9 NVMe |
| i3.4xgrande | 16 | 122 | Hasta 10 Gigabits | 2 SSD de 1.9 NVMe |
| i3.8xgrande | 32 | 244 | Gigabit 10 | 4 SSD de 1.9 NVMe |
| i3.16xgrande | 64 | 488 | Gigabit 25 | 8 SSD de 1.9 NVMe |
| i3.metal | 72 | 512 | Gigabit 25 | 8 SSD de 1.9 NVMe |
Las instancias i3.metal están disponibles en las regiones de AWS EE. UU. Este (Norte de Virginia), EE. UU. Este (Ohio), EE. UU. Oeste (Oregón), Europa (Fráncfort) y Europa (Irlanda), y se pueden adquirir como instancias bajo demanda. Instancias reservadas (3 años, 1 año y convertibles) o como instancias de spot. A los efectos de esta revisión, probamos en la región de Virginia del Norte. Probamos tanto con almacenamiento NVMe como con volúmenes en bloque de EBS.
Desempeno
Análisis de carga de trabajo de VDBench
Para evaluar el rendimiento de la instancia EC2 i3.metal, aprovechamos VDBench instalado localmente para probar el almacenamiento EBS (30 x 1 TB) y NVMe (8 x 1.7 TB). Con ambos tipos de almacenamiento, asignamos el 12 % de cada dispositivo y los agrupamos en conjunto para observar el rendimiento máximo del sistema con una cantidad moderada de localidad de datos.
Estas cargas de trabajo ofrecen una gama de diferentes perfiles de prueba que van desde pruebas de "cuatro esquinas", pruebas comunes de tamaño de transferencia de bases de datos, así como capturas de seguimiento de diferentes entornos VDI. Todas estas pruebas aprovechan el generador de cargas de trabajo vdBench común, con un motor de secuencias de comandos para automatizar y capturar resultados en un gran clúster de pruebas informáticas. Esto nos permite repetir las mismas cargas de trabajo en una amplia gama de dispositivos de almacenamiento, incluidos arreglos flash y dispositivos de almacenamiento individuales.
perfiles:
- Lectura aleatoria 4K: 100 % de lectura, 128 subprocesos, 0-120 % de iorate
- Escritura aleatoria 4K: 100 % de escritura, 64 subprocesos, 0-120 % de iorate
- Lectura secuencial de 64 K: 100 % de lectura, 16 subprocesos, 0-120 % de iorate
- Escritura secuencial de 64 K: 100 % de escritura, 8 subprocesos, 0-120 % de iorate
- Base de datos sintética: SQL y Oracle
- Seguimientos de clones vinculados a VDI
Analizamos tanto EBS como NVMe en esta revisión. Debido a que existe una gran diferencia de rendimiento, hemos separado los resultados en dos gráficos (la latencia estaría tan separada que los gráficos serían muy difíciles de leer).
Nuestra primera prueba analiza la lectura aleatoria de 4K. Aquí, la instancia de EBS tuvo un rendimiento de latencia inferior al milisegundo hasta el final. Con aproximadamente 64 59.46 IOPS, aumentó la latencia a 64,047 ms con un rendimiento de XNUMX XNUMX IOPS.
Al observar la lectura aleatoria máxima de NVMe 4K, vemos que la instancia funciona mucho mejor. La instancia alcanzó un máximo de 2,802,904 348 XNUMX IOPS con una latencia de XNUMX μs.
La escritura aleatoria 4K con EBS vio casi lo mismo que las lecturas 4K con EBS. La instancia rompió 1 ms un poco antes, alrededor de 60 64,003 IOPS, y alcanzó un máximo de 29.97 XNUMX IOPS con una latencia de XNUMX ms.
Para la versión NVMe de la instancia, hubo un ligero aumento en la latencia, pero todavía estaba por debajo de 1 ms. La instancia alcanzó un máximo de 920,975 545 IOPS con una latencia de XNUMX μs.
Cambiando a pruebas secuenciales, para el rendimiento máximo de lectura de EBS 64K, la instancia tuvo una latencia de submilisegundos hasta alrededor de 70K IOPS o alrededor de 450 MB/s y alcanzó un máximo de 17,360 1.08 IOPS o 27.65 GB/s con una latencia de XNUMX ms.
La lectura secuencial de 64K con NVMe nos dio un rendimiento máximo de 244,037 15.25 IOPS o 514 GB/s con una latencia de XNUMX μs.
Con 64K de escritura con EBS, la instancia comenzó por encima de 1 ms y alcanzó un máximo de 17,359 1.08 IOPS o 13.8 GB/s con una latencia de XNUMX ms.
La escritura secuencial de 64 K es la primera vez que vemos que la instancia de NVMe supera 1 ms. La instancia alcanzó un máximo de 58,572 3.66 IOPS o 1.08 GB/s con una latencia de XNUMX ms.
Al cambiar a nuestras cargas de trabajo de SQL, la instancia de EBS tuvo un rendimiento de latencia de submilisegundos hasta alrededor de 55 64,036 IOPS y alcanzó un máximo de 14.93 XNUMX IOPS con una latencia de XNUMX ms.
Para la versión NVMe de la instancia, vimos un rendimiento máximo de 834,231 302 IOPS con una latencia de XNUMX μs para la prueba de SQL.
Para SQL 90-10 con EBS, la instancia nuevamente superó la latencia de 1 ms alrededor de 55 64,036 IOPS y alcanzó un máximo de 14.99 XNUMX IOPS con una latencia de XNUMX ms.
La versión NVMe de la instancia en SQL 90-10 tuvo un rendimiento máximo de 605,150 415 IOPS y una latencia de XNUMX μs.
El SQL 80-20 con EBS volvió a dar casi los mismos números con una latencia de submilisegundos que finalizó en alrededor de 55 64,036 IOPS y un pico de 14.93 XNUMX IOPS con una latencia de XNUMX ms.
El SQL 80-20 con NVMe tuvo un número de instancias de 511,840 493 IOPS y una latencia de XNUMX μs.
Las pruebas de Oracle para EBS mostraron el mismo rendimiento máximo impar de casi los mismos números. Para Oracle, la instancia alcanzó 64,036 13.6 IOPS con una latencia de 55 ms. La instancia tuvo un rendimiento de latencia de submilisegundos hasta alrededor de XNUMX XNUMX IOPS.
Con NVMe, la instancia alcanzó 457,372 613 IOPS con una latencia de XNUMX μs en la prueba de Oracle.
Oracle 90-10 tuvo el pico de instancias de EBS en 64,035 10.3 IOPS con una latencia de 1 ms. La instancia rompió 55 ms a alrededor de XNUMX XNUMX IOPS.
La versión NVMe de la instancia en Oracle 90-10 pudo alcanzar 520,448 333 IOPS con una latencia de XNUMX μs.
Oracle 80-20 hizo que EBS rompiera 1 ms alrededor de 55 64,036 IOPS y alcanzara un máximo de 10.3 XNUMX IOPS con una latencia de XNUMX ms.
La instancia con NVMe tuvo un rendimiento máximo de 435,265 400 IOPS con una latencia de XNUMX μs.
A continuación, analizamos nuestras pruebas VDI Linked Clone (LC). Comenzando con Boot, la versión de EBS de la instancia tenía una latencia de menos de un milisegundo hasta aproximadamente 35 42,893 IOPS y alcanzó un máximo de 11.2 XNUMX IOPS con una latencia de XNUMX ms.
La versión NVMe de la instancia pudo alcanzar un máximo de 349,799 363 IOPS y una latencia de XNUMX μs en nuestra prueba de arranque VDI LC.
Para el inicio de sesión inicial de VDI LC, la instancia de EBS superó la línea de 1 ms durante algún tiempo antes de caer alrededor de 31 34,486 IOPS. La instancia alcanzó un máximo de 6.95 XNUMX IOPS y una latencia de XNUMX ms.
Con el inicio de sesión inicial de VDI LC, la instancia de NVMe alcanzó un máximo de 93,405 677 IOPS con una latencia de XNUMX μs.
Con VDI LC Monday Login, una vez más, la instancia de EBS flirteó con 1 ms durante algún tiempo antes de dar el salto alrededor de 25 34,643 IOPS y alcanzar un máximo de 13.85 XNUMX IOPS con una latencia de XNUMX ms.
Y, por último, nuestro VDI LC Monday Login con NVMe tuvo un pico de instancia de 119,615 1.1 IOPS con una latencia de XNUMX ms.
Conclusión
Los servicios en la nube de Amazon generalmente se consideran los más versátiles. Si bien la computación y el almacenamiento ciertamente son variados, Amazon también tiene opciones de rendimiento. Amazon ofrece una gran cantidad de opciones de rendimiento en su servicio web EC2, incluida su instancia bare metal i3. Estas instancias aprovechan el sistema AWS Nitro de hardware y software especialmente diseñado. Las instancias i3.metal brindan un mejor rendimiento a través del acceso directo a las CPU y la memoria, al mismo tiempo que ofrecen a los usuarios la capacidad de aprovechar otras funciones, como el almacenamiento adjunto de AWS EBS y el almacenamiento NVMe local.
En cuanto al rendimiento, probamos tanto el almacenamiento en bloque (EBS) como NVMe. Esto tiene la intención de dar a los lectores una idea de qué esperar en términos de opciones, y menos de que uno sea mejor que el otro (por lo general, el almacenamiento NVMe funciona mejor y tiene una latencia mucho más baja, razón por la cual hay dos conjuntos de gráficos). Al observar el EBS, vimos un patrón en el que la instancia superaba 1 ms y, poco después, aumentaba la latencia y finalizaba. A lo largo de nuestras pruebas, EBS alcanzó un máximo de alrededor de 64 4 IOPS, que es el máximo permitido para EBS. Esto incluyó las pruebas 64K y las tres pruebas SQL y Oracle. La instancia se ralentizó un poco para nuestras pruebas de VDI. Amazon indica que es posible ajustar la configuración para lograr más de los XNUMX XNUMX IOPS prescritos, pero los procesos para lograrlo no son los que experimentaría la mayoría de los clientes, por lo que no seguimos este camino.
Para nuestras pruebas de NVMe, vimos resultados que estaban más en línea con nuestros puntos de referencia normales. Los puntos destacados incluyeron un rendimiento de lectura aleatoria de 4K de 2.8 millones de IOPS, escritura de 4K de 920 64 IOPS, lectura de 15.25 K de 500 GB/s y rendimiento de SQL de más de 834 435 IOPS en las tres pruebas (con la prueba de SQL de alrededor de 520 350 IOPS). Las pruebas de Oracle también tuvieron una buena actuación con NVMe, con resultados entre 3 XNUMX IOPS y XNUMX XNUMX IOPS. Nuestro VDI Linked Clone mostró un sólido rendimiento de arranque con aproximadamente XNUMX XNUMX IOPS. La única decepción aquí es que los clientes no pueden optar por más NVMe local en las instancias iXNUMX.metal.
En general, la instancia i3.metal nos dio exactamente lo que Amazon prometió. Eso es tranquilizador para los clientes que quieren saber que van a recibir el nivel de servicio prometido. Por supuesto, esto tiene un costo, ya que con cualquier implementación en la nube, la preocupación será la facilidad de uso y los resultados en la nube frente a otros proveedores de la nube frente a las instalaciones. Dicho esto, los clientes que tienen cargas de trabajo que pueden arreglárselas con un nivel de IOPS más bajo pueden ahorrar bastante dinero. Sin embargo, todo se reduce a cuáles son los requisitos finales para la instancia en particular. Con ese fin, las instancias i3.metal son excelentes para las aplicaciones principales que no van a superar o no pueden superar los límites de rendimiento que ofrece i3.metal y no necesitan las IOPS que ofrecería una matriz todo flash en las instalaciones. instancia. Además, si ya forma parte de la familia de Amazon, el cambio a bare metal le resultará familiar y probablemente haya una ventaja económica al consumir varios programas de AWS a granel.
Suscríbase al boletín de StorageReview
