Revisión de NetApp AFF A800

El AFF A800 es el arreglo de almacenamiento all-flash ONTAP de primera línea de NetApp, que en el lanzamiento ofreció NVMe/FC de extremo a extremo primero en la industria sobre FC de 32 Gb, así como conectividad de 100 GbE. Hasta la fecha, nos hemos abierto camino a través de la línea AFF all-flash, comenzando con el potente A200 (después de haber sido reemplazado por el A220), así como el A300. Las dos unidades que revisamos anteriormente ganaron premios Editor's Choice. Hoy analizaremos el potente A800 basado en NVMe que ofrece los mismos beneficios de ONTAP de los modelos revisados anteriormente, así como un rendimiento exponencialmente más rápido y una latencia más baja. Si bien esta revisión inicial se centra en el rendimiento del sistema a través de Fibre Channel, los artículos posteriores se sumergirán en el soporte NVMe over Fabrics (NVMeoF) de extremo a extremo del A800.

A diferencia del A200 y el A300 que se crearon para diferentes segmentos del mercado de gama media, el A800 está diseñado para las cargas de trabajo que exigen el mayor rendimiento (como AI y Deep Leaning), al tiempo que incluye el sólido conjunto de servicios de datos empresariales que ONTAP ofrece. conocido por. Como un punto de claridad, NetApp tiene una serie de almacenamiento realmente rápido en la familia EF all-flash, como el rango medio EF570 revisamos anteriormente. Volviendo al A800, NetApp afirma que el sistema puede alcanzar los 1.3 millones de IOPS con una latencia inferior a 500 μs y un rendimiento de hasta 34 GB/s con un par HA. A escala, esto significa que un clúster NAS puede ofrecer hasta 11.4 millones de IOPS con una latencia de 1 ms y un rendimiento de 300 GB/s. Un clúster SAN puede ofrecer hasta 7.8 millones de IOPS con una latencia de 500 µs y un rendimiento de 204 GB/s.

Al igual que el resto de los sistemas de la serie AFF A, el NVMe A800 puede escalar a 24 (12 pares HA) nodos de controlador dual 4U en un clúster en configuración NAS. Debido a que este es un sistema basado en NVMe, hay algunos matices cuando se trata de escalar unidades. El A300 de rango medio, por ejemplo, admite 4608 unidades, mientras que el A800 alcanza un máximo de 2880. Si bien no es probable que sea un problema funcional cuando se implementa, destacamos esto solo para indicar que los sistemas basados en NVMe tienen diferentes desafíos de ingeniería al considerar los estantes de expansión JBOD que Sistemas basados en SAS, por lo que no podemos simplemente suponer que a medida que avanza en la línea de productos, todo se vuelve más grande. En una configuración SAN, NVMe A800 se escala a 12 nodos (6 pares HA) con soporte para 1,440 unidades. Dicho esto, si los usuarios aprovechan los SSD NVMe de 15.3 TB, pueden escalar hasta 2.5 PB en un espacio de 4U. Con eficiencias de datos habilitadas (asumiendo 5:1), el A800 admite más de 315 PB en un clúster NAS de 24 nodos y 160 TB en un clúster SAN.

Si bien NetApp ha habilitado la compatibilidad con NVMe de extremo a extremo en otros sistemas AFF, el A800 ofrece lo que se denomina compatibilidad con NVMe de extremo a extremo. Como se señaló, no vamos a profundizar en lo que esto significa en esta revisión. Baste decir que el A800 es el primer arreglo NVMe all-flash que logra esto. Efectivamente, lo que esto significa es que las organizaciones pueden aprovechar la ola emergente de capacidades de NVMeoF en la actualidad, sin dejar de atender sus cargas de trabajo más tradicionales a través de FC. Anteriormente, las organizaciones que querían aprovechar NVMeoF generalmente estaban relegadas a implementaciones de tipo "proyecto científico" que, si bien eran rápidas, tenían limitaciones en lo que respecta a la escala y los servicios de datos. La implementación de NetApp aquí aborda esas deficiencias, al mismo tiempo que brinda soporte para las opciones de conectividad estándar tanto en FC como en Ethernet.

Por supuesto, no podemos hablar del A800 sin destacar la conectividad en la nube y la Estructura de datos de NetApp. Inherente a ONTAP hay un conjunto profundo de conectividad con los principales proveedores de la nube, lo que permite a los clientes colocar sus datos donde tenga más sentido, ya sea localmente en el A800 o en otro lugar. NetApp admite conexiones en la nube y en múltiples nubes con Amazon Web Services, Microsoft Azure, Google Cloud Platform y otros. La amplia compatibilidad con la nube permite a los clientes de NetApp tener la flexibilidad que necesitan al administrar su huella de datos y la agilidad para mover los datos según sea necesario para aprovechar la economía de la nube, las nuevas características o los tipos de formas, etc.

Nuestra construcción particular consta de un A800 con 24 SSD NVMe de 1.92 TB con dos puertos FC de 32 Gb de cuatro puertos conectados por controlador (8 puertos en total) con ONTAP 9.5RC1 instalado.

Especificaciones de NetApp A800

Escalamiento máximo	2-24 nodos (12 pares HA)
SSD máximo	2880
Capacidad efectiva máxima	316.3PB
Controlador dual activo-activo por sistema
Factor de forma del controlador	4U
Ranuras de expansión PCIe	8
Puertos de destino FC (rango automático de 32 Gb)	32
Puertos de destino FC (rango automático de 16 Gb)	32
Puertos de 100 GbE (rango automático de 40 GbE)	20
puertos de 10 GbE	32
Compatible con redes de almacenamiento	NVMe/FC FC iSCSI NFS pnfs CIFS/PYMES
versión del sistema operativo	ONTAP 9.4 RC1 o posterior
Estantes y medios	Paquetes de unidades NVMe
Sistema operativo host/cliente compatible	Windows 2000 Windows Server 2003 Windows Server 2008 Windows Server 2012 Windows Server 2016 Linux oracle solaris AIX HP-UX Mac OS VMware ESX

Diseño y construcción

El NetApp AFF A800 es un arreglo de 4U que tiene un aspecto muy similar al resto de la serie AFF. Debajo del elegante bisel que contiene la ventilación y la marca NetApp, hay dos filas de bahías para unidades azules de 2.5” para las SSD.

En cuanto a las unidades NVMe, NetApp es compatible con una amplia gama de opciones de capacidad, incluidas SSD de 1.9 TB, 3.8 TB, 7.6 TB y 15.3 TB. En el momento de escribir este artículo, NetApp envía todas estas unidades como autocifrado (SED) con cifrado AES-256. Además, para los sistemas inicializados con ONTAP 9.4, se habilita la puesta a cero rápida de la unidad.

Volteando hacia la parte posterior del dispositivo, hay dos controladores: uno apilado encima del otro como una imagen especular. Nuestra configuración incluye cuatro estilos diferentes de interfaces para la conectividad. Estas cuatro tarjetas se encuentran en las ranuras PCIe del extremo derecho y central. Incluyen una tarjeta FC de 32 Gb de cuatro puertos (arriba a la izquierda), una tarjeta de red de 25 GbE de dos puertos (abajo a la izquierda), una tarjeta de red de 100 GbE de dos puertos (arriba a la derecha) y una tarjeta de red de 10 GbE de cuatro puertos (abajo a la derecha).

Al quitar uno de los controladores, podemos ver las conexiones con el resto de la unidad, así como los ventiladores que se alinean en la parte frontal del controlador.

Volteando hacia el controlador posterior, el lado izquierdo tiene PSU dobles redundantes para cada controlador, así como los puertos de interconexión HA y los puertos de interconexión del clúster. La parte inferior derecha de cada controlador también tiene puertos de interconexión de clúster y 1HA. La mayor parte del resto se ocupa con ranuras PCIe (cinco) que se pueden llenar con puertos de red de canal de fibra de 100 GbE, 10 GbE o 32 Gb o alguna combinación de los anteriores, como en nuestra configuración. En la parte inferior central están los puertos de administración y dos puertos USB 3.0.

El controlador es increíblemente fácil de abrir, lo que lo hace muy útil.

Podemos ver las dos CPU, 20 ranuras DIMM (pobladas con 20 DIMM de 32 GB de RAM) y las dos ranuras NVDIMM. Los AIC de la red PCIe también son fácilmente accesibles desde aquí.

Equipo Directivo

La GUI de ONTAP ha recorrido un largo camino a lo largo de los años, desde una GUI habilitada para Java en la versión 8.2 y anteriores hasta la moderna y bien diseñada ONTAP 9.5 basada en web. NetApp ha realizado mejoras significativas en la GUI, haciéndola cada vez más utilizable para algo más que las funciones de administración diarias.

Tablero o Dashboard:

Después de iniciar sesión, será recibido por el tablero que le dará un resumen rápido de lo que está sucediendo con el sistema. El tablero es bastante sencillo en cuanto a lo que puede ver. Cada uno de los widgets permite echar un vistazo rápido a las alertas, el rendimiento, la capacidad, la eficiencia y la protección. Para una visualización más detallada y tendencias a largo plazo, se recomienda utilizar OnCommand Unified Manager de NetApp (gratuito) para las métricas de ONTAP.

Nivel de nube:

Con la adición de la opción Fabric Pool de NetApp Cloud, la GUI simplifica la conexión a nubes públicas, incluido NDAS, así como a StorageGRID local.

SVM:

Desde esta pestaña, puede crear, editar, eliminar e iniciar/detener todas las SVM de protocolo de datos en el clúster de ONTAP, así como editar varias configuraciones.

Grupos agregados y de almacenamiento:

Las pestañas Agregado y Conjunto de almacenamiento permiten la creación y administración sencillas de Agregados y Conjuntos de almacenamiento.

Volúmenes y LUN:

La página de administración de volumen y LUN le brinda una amplia variedad de creación y administración de FlexVols, FlexGroups y LUN, e incluso igroups y mapeo para cada una de las SVM.

calidad del servicio:

QoS ha recorrido un largo camino en ONTAP a lo largo de los años, ya que ahora puede configurar un techo y un piso para cada carga de trabajo, así como configurarlos para que se adapten a sus cargas de trabajo cambiantes. QoS se puede aplicar a varios objetos dentro de ONTAP, como volúmenes, archivos y LUN, así como a algunos otros objetos.

Configuración de red:

Toda la configuración y administración básicas de la red se encuentra en la GUI: IP Spaces, Broadcast Domains, Ports, LIF, FC y ahora NVMe.

mirando:

Hasta las últimas versiones de ONTAP, necesitaba crear relaciones de interconexión únicamente a través de la CLI; sin embargo, ahora puede crear pares de clúster e incluso pares de SVM en la GUI también. Una vez que haya configurado la interconexión, podrá incluso crear una relación SnapMirror directamente en el asistente de creación de volúmenes.

Actualizaciones de clústeres:

Las actualizaciones de ONTAP son cada vez más fáciles de realizar. Una característica pequeña pero muy útil agregada en 9.4 hace que sea aún más fácil realizar actualizaciones de ONTAP. Seguro que a todos nos encanta la línea de comandos, pero esto hace que sea muy fácil trabajar con los clientes para actualizar sus archivos. No más servidores http/ftp con los que meterse; simplemente cargue el archivo .tgz directamente y ejecute la actualización automática del clúster.

Performance

Para el rendimiento, compararemos el A800 con el A300. Esto se utiliza para mostrar qué tan bien escala el rendimiento de los modelos AFF de NetApp a medida que asciende en la familia. En todas nuestras pruebas, tenemos habilitados los servicios de reducción de datos, lo que significa que la deduplicación y la compresión en línea están habilitadas. Como hemos señalado en revisiones anteriores, NetApp ONTAP ofrece excelentes capacidades de recuperación ante desastres con una sobrecarga o un impacto en el rendimiento mínimos.

La configuración de nuestro AFF A800 de NetApp incluía 8 puertos FC de 32 Gb con 24 SSD NVMe de 1.92 TB instalados. De los 24 SSD de 1.92 TB implementados en nuestro A800, los dividimos en dos agregados RAID-DP, con 11 SSD en uso y uno como repuesto dinámico. El arreglo se conectó mediante 32 Gb a través de dos conmutadores Brocade G620, que luego tenían 16 enlaces de 16 Gb a nuestros servidores Dell PowerEdge R740xd.

Para nuestros puntos de referencia sintéticos que utilizan VDbench y Sysbench, aprovisionamos 32 volúmenes de 600 GB repartidos uniformemente entre controladores y grupos de discos. Para SQL Server, utilizamos cuatro volúmenes adicionales de 1.1 TB, dos por controlador para albergar las máquinas virtuales utilizadas para la evaluación comparativa. Después de tener en cuenta la reducción de datos, la huella total utilizada durante nuestras pruebas ascendió a poco menos del 50 % de utilización para cada agregado.

Rendimiento de SQL Server

El protocolo de prueba OLTP de Microsoft SQL Server de StorageReview emplea el borrador actual del Benchmark C (TPC-C) del Transaction Processing Performance Council, un benchmark de procesamiento de transacciones en línea que simula las actividades que se encuentran en entornos de aplicaciones complejos. El punto de referencia TPC-C se acerca más que los puntos de referencia de rendimiento sintéticos para medir las fortalezas de rendimiento y los cuellos de botella de la infraestructura de almacenamiento en entornos de bases de datos.

Cada máquina virtual con SQL Server está configurada con dos discos virtuales: un volumen de 100 GB para el arranque y un volumen de 500 GB para la base de datos y los archivos de registro. Desde la perspectiva de los recursos del sistema, configuramos cada VM con 16 vCPU, 64 GB de DRAM y aprovechamos el controlador LSI Logic SAS SCSI. Si bien nuestras cargas de trabajo de Sysbench probadas anteriormente saturaron la plataforma tanto en E/S de almacenamiento como en capacidad, la prueba de SQL busca el rendimiento de la latencia.

Esta prueba utiliza SQL Server 2014 ejecutándose en máquinas virtuales invitadas de Windows Server 2012 R2 y está destacada por Dell's Benchmark Factory for Databases. Si bien nuestro uso tradicional de este punto de referencia ha sido probar grandes bases de datos de escala 3,000 en almacenamiento local o compartido, en esta iteración nos enfocamos en distribuir cuatro bases de datos de escala 1,500 de manera uniforme en nuestros servidores.

Configuración de prueba de SQL Server (por VM)

Windows Server 2012 R2
Huella de almacenamiento: 600 GB asignados, 500 GB utilizados
SQL Server 2014
- Tamaño de la base de datos: escala 1,500
- Carga de clientes virtuales: 15,000
- Búfer RAM: 48GB
Duración de la prueba: 3 horas
- 2.5 horas de preacondicionamiento
- Período de muestra de 30 minutos

Para nuestro rendimiento transaccional de SQL Server, el A800 obtuvo una puntuación total de 12,635.5 3,158.6 TPS con máquinas virtuales individuales que se ejecutaron de 3,159.3 TPS a 300 TPS (un pequeño aumento sobre los 12,628.7 200 TPS del A12,583.8 y los XNUMX XNUMX TPS del AXNUMX).

En cuanto a la latencia promedio de SQL Server, vemos una mayor mejora en el A800, ya que se redujo a 5 ms agregados y 5 ms en todas las máquinas virtuales (mucho mejor que los 300 ms del A8 y los 200 ms del A25).

Rendimiento Sysbench MySQL

Nuestro primer punto de referencia de la aplicación de almacenamiento local consiste en una base de datos OLTP MySQL de Percona medida a través de SysBench. Esta prueba mide el promedio de TPS (transacciones por segundo), la latencia promedio y también la latencia promedio del percentil 99.

Cada máquina virtual de Sysbench está configurada con tres discos virtuales: uno para arranque (~92 GB), uno con la base de datos preconstruida (~447 GB) y el tercero para la base de datos bajo prueba (270 GB). Desde la perspectiva de los recursos del sistema, configuramos cada VM con 16 vCPU, 60 GB de DRAM y aprovechamos el controlador LSI Logic SAS SCSI.

Configuración de prueba de Sysbench (por VM)

CentOS 6.3 de 64 bits
Percona XtraDB 5.5.30-rel30.1
- Tablas de base de datos: 100
- Tamaño de la base de datos: 10,000,000
- Subprocesos de la base de datos: 32
- Búfer RAM: 24GB
Duración de la prueba: 3 horas
- 2 horas preacondicionamiento 32 hilos
- 1 hora 32 hilos

Para Sysbench, probamos varios conjuntos de máquinas virtuales, incluidos 8, 16 y 32, y ejecutamos Sysbench con la reducción de datos "activada". El A800 pudo alcanzar 15,750.8 TPS para 8VM, 22,170.9 TPS para 16VM y 44,149.8 TPS para 32VM. Estos son mucho más altos que los anteriores, casi duplicando lo que hizo el A300 con 32VM, 22,313 TPS.

Con la latencia promedio de Sysbench, el A800 alcanzó 16.3 ms para 8 VM, 23.1 ms para 16 VM y 23.2 ms para 32 VM. Esto es mucho mejor que los modelos AFF más pequeños.

En nuestro peor escenario de latencia (percentil 99), el A800 alcanzó 31.3 ms para 8 VM, 48.5 ms para 16 VM, 48.1 ms para 32 VM.

Análisis de carga de trabajo de VDBench

Cuando se trata de comparar matrices de almacenamiento, las pruebas de aplicaciones son las mejores y las pruebas sintéticas ocupan el segundo lugar. Si bien no es una representación perfecta de las cargas de trabajo reales, las pruebas sintéticas ayudan a los dispositivos de almacenamiento de referencia con un factor de repetibilidad que facilita la comparación de manzanas con manzanas entre las soluciones de la competencia. 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
Trazas de clones vinculados y clones completos de VDI

Comenzando con un rendimiento máximo de lectura aleatoria de 4K, el A800 comenzó con 118,511 217.5 IOPS con una latencia de 800 μs. El A1 se mantuvo por debajo de 1.07 ms hasta que alcanzó alrededor de 1,219.829 millones de IOPS y alcanzó un máximo de 3.3 IOPS con una latencia de 300 ms. Esta fue una marcada diferencia en comparación con el rendimiento máximo del A635,342 de 6.4 XNUMX IOPS con una latencia de XNUMX ms.

En cuanto al rendimiento de escritura 4K, el A800 comenzó con 45,676 213.1 IOPS con una latencia de 800 μs. El A410 tuvo un rendimiento de latencia de submilisegundos hasta alrededor de 439 4.4 IOPS y alcanzó un máximo de alrededor de 300 208,820 IOPS con una latencia de 9.72 ms antes de caer un poco. Por el contrario, el AXNUMX tuvo un rendimiento máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Cambiando a cargas de trabajo secuenciales, observamos el rendimiento máximo de lectura de 64K, y aquí el A800 comenzó con 29,589 1.85 IOPS o 166.1 GB/s con una latencia de 300 μs. El A300 tenía una latencia de menos de un milisegundo hasta aproximadamente 18.5 302,668 IOPS o 18.9 GB/s, y alcanzó un máximo de 1.7 300 IOPS o 84,766 GB/s con una latencia de 5.71 ms. El A3.64 alcanzó un máximo de aproximadamente XNUMX XNUMX XNUMX IOPS o XNUMX GB/s con una latencia de XNUMX ms antes de caer un poco.

Para un rendimiento de escritura secuencial de 64K, el A800 comenzó con 8,103 IOPS o 506.4 MB/s con una latencia de 304.8 μs. La matriz se mantuvo por debajo de 1 ms hasta el final de su ejecución o alrededor de 80 5 IOPS o 80,536 GB/s, y alcanzó un máximo de 5.03 3.1 IOPS o 300 GB/s con una latencia de 48,883 ms. Para un rendimiento máximo, vimos que el A3.1 alcanzó 4.8 XNUMX IOPS o XNUMX GB/s con una latencia de XNUMX ms.

Nuestro próximo lote de puntos de referencia son nuestras pruebas de SQL. En SQL, el A800 comenzó con 138,007 255.2 IOPS con una latencia de 650 μs y tuvo una latencia de menos de un milisegundo hasta aproximadamente 697,603 1.5 IOPS, y alcanzó un máximo de 300 488,488 IOPS con una latencia de 2.1 ms. Esto se compara con el pico del AXNUMX de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

En SQL 90-10, el A800 comenzó con 70,867 277.3 IOPS con una latencia de 1 μs y se mantuvo por debajo de 640 ms hasta aproximadamente 730,567 1.4 IOPS, y alcanzó un máximo de 300 416,370 IOPS con una latencia de 2.46 ms. El AXNUMX, por otro lado, tuvo un rendimiento máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Para SQL 80-20, el A800 comenzó con 56,391 256.6 IOPS a una latencia de 480 μs con una latencia de submilisegundos hasta aproximadamente 800 623,557 IOPS. El A1.6 alcanzó un máximo de 300 360,642 IOPS con una latencia de 2.82 ms. Esto fue aproximadamente el doble de los XNUMX XNUMX IOPS del AXNUMX con una latencia de XNUMX ms.

Pasando a nuestras cargas de trabajo de Oracle, vimos que el A800 comenzaba con 64,020 254.7 IOPS con una latencia de 1 μs, permaneciendo por debajo de 470 ms hasta aproximadamente 800 656,438 IOPS. El A1.9 alcanzó un máximo de 800 300 IOPS con una latencia de 340,391 ms. Una vez más, el A3.6 tuvo casi el doble de rendimiento que el AXNUMX con una puntuación de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Con Oracle 90-10, el A800 comenzó con 75,710 242.5 IOPS y una latencia de 759,117 μs. El arreglo manejó el rendimiento de latencia de submilisegundos en todo momento, alcanzando un máximo de 839.2 300 IOPS a una latencia de 417,869 μs, un gran avance desde el pico del A1.53 de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Con Oracle 80-20, el A800 mantuvo un rendimiento de latencia de submilisegundos a partir de 65,505 254.5 IOPS a 666,556 μs de latencia y alcanzó un máximo de 943.1 300 IOPS a 362,499 μs. El A1.62 alcanzó un máximo de XNUMX IOPS y una latencia de XNUMX ms.

A continuación, cambiamos a nuestra prueba de clonación de VDI, completa y vinculada. Para VDI Full Clone Boot, el A800 tuvo una latencia de menos de un milisegundo hasta alrededor de 535 579,786 IOPS y alcanzó un máximo de 1.8 300 IOPS con una latencia de 300,128 ms. El A3.46 alcanzó un máximo de XNUMX IOPS con una latencia de XNUMX ms.

Con el inicio de sesión inicial de clon completo de VDI, el A800 se mantuvo por debajo de 1 ms hasta aproximadamente 200 254,888 IOPS y alcanzó un máximo de 3.5 300 IOPS con una latencia de 123,984 ms. Esto contrasta con el A7.26 que alcanza un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

El VDI FC Monday Login mostró el A800 con un rendimiento de latencia de submilisegundos hasta aproximadamente 180 228,346 IOPS y un pico de 2.2 300 IOPS con una latencia de 131,628 ms. Este fue un gran salto con respecto a los 3.89 XNUMX IOPS del AXNUMX con una latencia de XNUMX ms.

Al cambiar a VDI Linked Clone (LC), en la prueba de arranque, el A800 tuvo una latencia de menos de 1 ms casi todo el tiempo, rompiendo la barrera de 1 ms con aproximadamente 440 460,366 IOPS y alcanzando un máximo de 1.1 300 IOPS con una latencia de 215,621 ms. El A2.28 alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

En el inicio de sesión inicial de VDI LC, el A800 nuevamente tuvo una larga latencia de submilisegundos hasta alrededor de 158 166,224 IOPS, alcanzando un máximo de 1.5 300 IOPS con una latencia de 95,296 ms. Esto se compara con el pico del A2.68 de XNUMX XNUMX IOPS con una latencia de XNUMX ms.

Finalmente, observamos el inicio de sesión de lunes de VDI LC, donde el A800 comenzó con 15,287 299.3 IOPS con una latencia de 1 μs. La matriz se mantuvo por debajo de 130 ms hasta aproximadamente 164,684 3.1 IOPS y alcanzó un máximo de 300 94,722 IOPS con una latencia de 5.4 ms. El AXNUMX alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms

Conclusión

El NetApp AFF A800 es un arreglo de almacenamiento all-flash de 4U que tiene que ver con el máximo rendimiento. El A800 viene con todo el flash NVMe y está diseñado para las cargas de trabajo más exigentes. Además de admitir todos los NVMe (y SSD NVMe de hasta 15.3 TB de capacidad cada uno), el AFF A800 también tiene conectividad opcional de 100 GbE para cuando el rendimiento es una necesidad absoluta. Según NetApp, el AFF A800 debería poder alcanzar 1.4 millones de IOPS con una latencia inferior a 500 μs. Al igual que con otros arreglos de NetApp de la serie A, el A800 funciona con ONTAP.

Para el rendimiento, ejecutamos nuestras cargas de trabajo de análisis de aplicaciones, que consisten en SQL Server y Sysbench, así como nuestras cargas de trabajo de VDBench. Para nuestro análisis de la carga de trabajo de la aplicación, el A800 obtuvo puntajes de SQL Server transaccional de 12,835.5 5 TPS en total y una latencia promedio de 300 ms. Este fue un gran paso adelante en el rendimiento de los 12,628.7 TPS del A8 y la latencia media de 800 ms. Con Sysbench, el A15,750.8 nos proporcionó 8 22,170.9 TPS para 16 VM, 44,149.8 32 TPS para 16.3 VM y 8 23.1 TPS para 16 VM, con latencias promedio de 23.2 ms para 32 VM, 31.3 ms para 8 VM y 48.5 ms para 16 VM, y latencias en el peor de los casos de 48.1 ms para 32 VM, 800 ms para XNUMX VM y XNUMX ms para XNUMX VM. En algunos casos, el AXNUMX pudo duplicar el TPS mientras reducía la latencia aproximadamente a la mitad.

Para nuestras cargas de trabajo de VDBench, NetApp AFF A800 siguió brillando. Los puntos destacados incluyen 1.2 millones de IOPS en lectura de 4K, 439 4 IOPS en escritura de 18.9K, 64 GB/s en lectura secuencial de 5.03 K y 64 GB/s en escritura de 5 K. Todos estos números se alcanzaron con una latencia de menos de 698 ms. En nuestras pruebas de SQL, el arreglo alcanzó 731 90 IOPS, 10 624 IOPS en SQL 80-20 y 800 656 IOPS en SQL 90-10. En Oracle, el A80 alcanzó los 20 759 IOPS y tanto en Oracle 667-800 como en Oracle 580-460, el arreglo tuvo una latencia inferior al milisegundo en todo momento con puntuaciones máximas de 4.4 XNUMX IOPS y XNUMX XNUMX IOPS, respectivamente. En nuestras pruebas de VDI Clone, el AXNUMX pudo alcanzar puntuaciones de arranque de XNUMX XNUMX IOPS para Full Clone y XNUMX XNUMX IOPS para Linked Clone. La latencia máxima más alta en cualquiera de nuestras pruebas fue de solo XNUMX ms.

Al igual que los sistemas ONTAP de mercado medio que analizamos anteriormente, NetApp una vez más sale del parque con el A800 enfocado en la empresa. El perfil de rendimiento es muy fuerte, ocupando su posición en la parte superior de la familia ONTAP. Como se señaló, esta prueba es el trabajo de canal de fibra de variedad de jardín; todavía tenemos que pelar lo que está disponible en la configuración de NVMeoF, que debería ser muy divertido. Al examinar el hardware para su revisión, a veces surge la preocupación de que los proveedores de almacenamiento más antiguos no son tan rápidos y flexibles como las nuevas empresas y el "código heredado" no puede seguir el ritmo. No vemos signos de estos problemas en ninguna parte de la cartera de NetApp y, además, el A800 adopta NVMe y NVMeoF de formas prácticas para la empresa sin sacrificar las características de disponibilidad y protección de datos inherentes a ONTAP durante años. NetApp tiene un gran manejo de NVMe en el A800, estamos entusiasmados de ver cómo este aprendizaje encuentra su camino a través de sus otros arreglos.