El año pasado revisamos la serie QSAN XCubeSAN XS1200 y descubrimos que tenía un buen rendimiento, buenas capacidades y un buen precio para los mercados SMB y ROBO que eran su objetivo. Para esta revisión, veremos el mismo dispositivo con el controlador XS5226 de gama alta. Como el diseño, la construcción y la administración son idénticos (estamos usando el mismo chasis), los lectores pueden consultar el revisión previa.
El año pasado revisamos la serie QSAN XCubeSAN XS1200 y descubrimos que tenía un buen rendimiento, buenas capacidades y un buen precio para los mercados SMB y ROBO que eran su objetivo. Para esta revisión, veremos el mismo dispositivo con el controlador XS5226 de gama alta. Como el diseño, la construcción y la administración son idénticos (estamos usando el mismo chasis), los lectores pueden consultar el revisión previa.
Dentro de la familia XS5200 (al igual que la familia XS1200), QSAN ofrece varios factores de forma y un controlador simple o doble, nuevamente con S para simple o D para doble. El XS5226D es un controlador dual que es activo-activo y está orientado a un mayor rendimiento para entornos de misión crítica, siendo los casos de uso ideales HPC, integración de virtualización y M&E. La empresa afirma tener un rendimiento de hasta 12 GB/s de lectura secuencial y 8 GB/s de escritura secuencial con más de 1.5 millones de IOPS.
Como se indicó, estamos usando el mismo chasis, lo que significa que hay varias áreas de superposición entre las dos revisiones y, por lo tanto, se omitirán aquí. Sin embargo, analizaremos las diferencias de especificación clave, ya que afectan directamente el rendimiento.
Especificaciones de QSAN XCubeSAN XS5226D
| Controlador de incursiones | Doble activo |
| CPU | Intel Xeon D-1500 de cuatro núcleos |
| Salud Cerebral | hasta 128 GB de DDR4 ECC |
| Tipo de unidad | |
| Disco duro SED de 2.5″ SAS, NL-SAS | |
| SAS, SSD SATA de 2.5" (se necesita una placa MUX de 6 Gb para unidades SATA de 2.5" en un sistema de controlador dual) | |
| Capacidades de expansión | 2U 26 bahías, SFF |
| Unidades máximas admitidas | 286 |
Performance
Análisis de la carga de trabajo de la aplicación
Los puntos de referencia de la carga de trabajo de la aplicación para QSAN XCubeSAN XS5226D consisten en el rendimiento de OLTP de MySQL a través de SysBench y el rendimiento de OLTP de Microsoft SQL Server con una carga de trabajo TPC-C simulada. En cada escenario, teníamos el arreglo configurado con 26 SSD Toshiba PX04SV SAS 3.0, configurados en dos grupos de discos RAID12 de 10 unidades, uno conectado a cada controlador. Esto dejó 2 SSD como repuestos. A continuación, se crearon dos volúmenes de 5 TB, uno por grupo de discos. En nuestro entorno de prueba, esto creó una carga equilibrada para nuestras cargas de trabajo de SQL y Sysbench.
Rendimiento de SQL Server
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 Benchmark Factory for Databases de Quest. 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 el QSAN XS5200 (dos máquinas virtuales por controlador).
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
Equipo LoadGen de fábrica de referencia OLTP de SQL Server
- Dell EMC PowerEdge R740xd Clúster de 4 nodos de SQL virtualizado
- 8 CPU Intel Xeon Gold 6130 para 269 GHz en clúster (dos por nodo, 2.1 GHz, 16 núcleos, caché de 22 MB)
- 1 TB de RAM (256 GB por nodo, 16 GB x 16 DDR4, 128 GB por CPU)
- 4 x Emulex 16GB FC HBA de dos puertos
- 4 NIC Mellanox ConnectX-4 rNDC de 25 GbE de dos puertos
- VMware ESXi vSphere 6.5/Enterprise Plus 8-CPU
Para nuestras pruebas, compararemos el nuevo controlador con el probado anteriormente. Esto es menos un "cuál es mejor" y más una "mirada al rendimiento que uno obtiene dependiendo de sus necesidades".
Con SQL Server, la diferencia en los controladores realmente no supuso una gran diferencia general en el rendimiento. El XS1226 con 4 VM alcanzó los 12,634.3 5226 TPS y el XS4 con 12,634.7 VM alcanzó los XNUMX XNUMX TPS.
Con la latencia promedio de SQL vimos más de lo mismo. El XS1226 tenía una latencia de 5.8 ms y el XS5226 tenía una latencia de 5.0 ms.
Rendimiento de Sysbench
Cada banco de sistema La máquina virtual 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 máquina virtual con 16 vCPU, 60 GB de DRAM y aprovechamos el controlador LSI Logic SAS SCSI. Los sistemas de generación de carga son servidores Dell R740xd.
Clúster de 740 nodos MySQL virtualizado Dell PowerEdge R4xd
- 8 CPU Intel Xeon Gold 6130 para 269 GHz en clúster (dos por nodo, 2.1 GHz, 16 núcleos, 22 MB de caché)
- 1 TB de RAM (256 GB por nodo, 16 GB x 16 DDR4, 128 GB por CPU)
- 4 x Emulex 16GB FC HBA de dos puertos
- 4 NIC Mellanox ConnectX-4 rNDC de 25 GbE de dos puertos
- VMware ESXi vSphere 6.5/Enterprise Plus 8-CPU
Configuración de prueba de Sysbench (por VM)
- CentOS 6.3 de 64 bits
- Huella de almacenamiento: 1 TB, 800 GB utilizados
- 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
En nuestro benchmark Sysbench, probamos varios conjuntos de 4VM, 8VM, 16VM y 32VM. En el desempeño transaccional, el XS5226D mostró un desempeño sólido con 6,889 TPS para 4 VM, 13,023 8 TPS para 21,645 VM, 16 26,810 TPS para 32 VM y XNUMX XNUMX TPS para XNUMX VM.
Con una latencia promedio, el XS4 de 1226 VM funcionó ligeramente mejor que el XS5226D, de 18.1 ms a 18.6 ms, pero el XS5226D superó al controlador anterior en las otras configuraciones de VM con 19.7 ms para 8 VM, 23.9 ms para 16 VM y 41 ms para 32 VM.
En nuestro punto de referencia de latencia del peor de los casos, vemos lo mismo que con la latencia promedio: mejor en 4VM para la serie XS1200 y mejor en el resto con la serie XS5200. Para el XS5226D, vimos una latencia de 32.7 ms para 4 VM, 34.8 ms para 8 VM, 47 ms para 16 VM y 76.9 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. En el lado del arreglo, usamos nuestro grupo de servidores Dell PowerEdge R740xd:
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
En el rendimiento de lectura máximo de 4K, el XS5226D tuvo un rendimiento de latencia de submilisegundos de hasta 400 442,075 IOPS, con un rendimiento máximo de 8.03 1200 IOPS con una latencia de 284 ms. Esto superó con creces al XS13.82 que alcanzó un máximo de XNUMX XNUMX IOPS y una latencia de XNUMX ms.
Con un rendimiento de escritura máximo de 4K, el nuevo controlador tuvo un rendimiento de latencia de submilisegundos de hasta alrededor de 270 294,255 IOPS con un pico de 6.27 246 IOPS con una latencia de 7.9 ms. A modo de comparación, el controlador anterior tenía un rendimiento máximo de aproximadamente XNUMX K con una latencia de XNUMX ms.
Cambiando al rendimiento secuencial, en la lectura de 64K, el XS5226D recorrió justo por debajo de 1 ms hasta aproximadamente 38 K IOPS o 2.3 GB/s y alcanzó un máximo de 95,762 5.99 IOPS o 5.34 GB/s con una latencia de 1200 ms. El XSXNUMX ni siquiera tenía un rendimiento de submilisegundos.
Para una escritura máxima secuencial de 64 5226, el XS1D tuvo un rendimiento inferior a 63 ms hasta aproximadamente 3.9 80 IOPS o 4.95 GB/s. Alcanzó un máximo de aproximadamente 2.68 XNUMX IOPS o XNUMX GB/s con una latencia de XNUMX ms.
En nuestra carga de trabajo de SQL, el nuevo controlador eclipsó fácilmente a su contraparte. El XS5226D tuvo un rendimiento de latencia de submilisegundos hasta alrededor de 380 425,327 IOPS y alcanzó un máximo de 2.27 5226 IOPS con una latencia de 200 ms. Entonces, el controlador XS1D tenía alrededor de XNUMX XNUMX IOPS más con una latencia de XNUMX ms más baja.
En SQL 90-10, el XS5226D se mantuvo por debajo de 1 ms hasta aproximadamente 350 407,661 IOPS y alcanzó un máximo de 2.36 1 IOPS con una latencia de XNUMX ms. Una vez más, eclipsó al otro controlador que tenía todo su rendimiento en XNUMX ms.
El SQL 80-20 mostró el XS5226D con un rendimiento de latencia de submilisegundos hasta aproximadamente 340 387,085 IOPS y un rendimiento máximo de 2.4 1200 IOPS con una latencia de 247 ms. Una vez más, fue un gran salto de rendimiento en el XS3.26 que tuvo un rendimiento máximo de alrededor de XNUMX XNUMX IOPS a una latencia de XNUMX ms.
Con Oracle Workload, el XS5226D logró casi 310 1 IOPS antes de romper 381,444 ms y alcanzar un máximo de 3.1 1200 IOPS con 246,186 ms. El XS4.2 alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.
Con Oracle 90-10, el XS5226D se mantuvo por debajo de 1 ms hasta aproximadamente 360 407,763 IOPS y alcanzó un máximo de 1.56 1200 IOPS con una latencia de 248,759 ms. A modo de comparación, el XS2.2 alcanzó un máximo de 1 XNUMX IOPS con una latencia de XNUMX ms y nunca cayó por debajo de XNUMX ms durante su ejecución.
Para la ejecución de Oracle 80-20, el XS5226D logró apenas 350 1 IOPS antes de romper 386,844 ms y alcanzar un máximo de 1.66 1200 IOPS con una latencia de 1 ms. El XS242,000 estuvo por encima de 4.16 ms en todo momento con un pico de XNUMX 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 XS5226D superó la línea de 1 ms por un momento antes de caer a aproximadamente 225 367,665 IOPS y alcanzar un máximo de 2.78 1200 IOPS con una latencia de 218 ms. Un salto impresionante en el rendimiento en comparación con los 4.26 XNUMX IOPS y la latencia de XNUMX ms del XSXNUMX.
Para el inicio de sesión inicial de VCI FC, el XS5226D tuvo un rendimiento de latencia de submilisegundos hasta aproximadamente 200 260 IOPS y alcanzó un máximo de aproximadamente 3 1200 IOPS con una latencia de 185,787 ms. El XS3.91 alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms en la misma prueba.
El VDI Full Clone Monday Login vio que el XS5226D alcanzó aproximadamente 163 1 IOPS por debajo de 269,724 ms y alcanzó un máximo de 1.86 182,376 IOPS con una latencia de 2.55 ms. El controlador anterior pudo alcanzar un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.
Al cambiar a VDI Linked Clone, la prueba de arranque mostró que el XS5226D llegó hasta aproximadamente 110K con un rendimiento de latencia de submilisegundos y alcanzó un máximo de 216,579 2.36 IOPS con una latencia de 1200 ms. El XS149,488 alcanzó un máximo de 3.39 XNUMX IOPS con una latencia de XNUMX ms.
El inicio de sesión inicial de VDI Linked Clone también vio que el XS5226D llegó hasta aproximadamente 110K con un rendimiento de latencia de submilisegundos y luego alcanzó un máximo de 182,425 IOPS con una latencia de 1.39ms. Compare esto con el XS1200 que tuvo un rendimiento máximo de 147,423 1.71 IOPS a una latencia de XNUMX ms.
Finalmente, el VDI Linked Clone Monday Login hizo que el XS5226D una vez más llegara a aproximadamente 110 220 con un rendimiento de latencia de submilisegundos y luego alcanzó un máximo de aproximadamente 2.3 1200 IOPS con una latencia de 148,738 ms. El XS3.2 alcanzó un máximo de XNUMX XNUMX IOPS con una latencia de XNUMX ms.
Conclusión
El QSAN XCubeSAN XS5226D es un SAN activo-activo dual que promete más rendimiento que el XS1226D que estaba destinado a las PYMES. Para esta revisión, aprovechamos el mismo chasis con un controlador actualizado. Dicho esto, el diseño, la construcción y la administración fueron los mismos y se pueden encontrar en nuestro revisión original. El XS5226D está dirigido a más cargas de trabajo de misión crítica y tiene casos de uso de destino más altos que el XS1226D, como HPC, M&E y virtualización. Usar el mismo chasis significa que todos los beneficios de conectividad y alta disponibilidad son los mismos.
En cuanto al rendimiento, en nuestro análisis de la carga de trabajo de la aplicación, la diferencia en los controladores realmente no se tradujo en una gran diferencia en el rendimiento de nuestros puntos de referencia de SQL Server, aunque en otras áreas vimos ganancias masivas. El TPS para el XS1226 fue de 12,634.3 5226 y para el XS0.4 la puntuación fue solo 12,634.7 TPS más alta con 5.8 5.0. Vimos una acción similar con una latencia promedio con el controlador más pequeño golpeando 1226ms y el más grande golpeando 4ms. Con Sysbench, vimos un rendimiento mucho mejor del XS5226 en configuraciones de 32 VM, pero el XS26,810.4 tuvo un mejor rendimiento con más VM con un rendimiento de 41 VM de 76.9 XNUMX TPS, una latencia promedio de XNUMX ms y el peor de los casos de XNUMX ms.
Con nuestras cargas de trabajo de VDBench hubo una gran diferencia en casi todas nuestras pruebas con el XS5226D claramente proporcionando mucho más rendimiento. En nuestro 4K, vimos que los controladores XS5226D alcanzaron puntuaciones de más de 442 294 IOPS de lectura y 8.03 6.27 IOPS de escritura con una latencia tan baja como 64 ms y 6 ms, respectivamente. El rendimiento de 5K mostró que el controlador alcanzó casi 425 GB/s de lectura y casi 407 GB/s de escritura. Con nuestra carga de trabajo de SQL, el controlador tuvo un rendimiento máximo de más de 90 10 IOPS, 387 80 IOPS para 20-381 y 407 90 IOPS para 10-386. La carga de trabajo de Oracle también mostró algunos números realmente buenos con un rendimiento máximo de más de 80 20 IOPS, 1.56 3.1 IOPS para 5226-367 y 216 260 IOPS para 182-5226 con latencias entre 269 ms y 220 ms. Para nuestro VDI Full Clone y Linked Clone, analizamos el inicio, el inicio de sesión inicial y el inicio de sesión del lunes. Para el rendimiento de arranque, el XSXNUMXD alcanzó más de XNUMX XNUMX IOPS en FC y más de XNUMX XNUMX IOPS en LC. El inicio de sesión inicial mostró aproximadamente XNUMX XNUMX IOPS de máximo rendimiento FC y más de XNUMX XNUMX IOPS para LC. Y Monday Login tenía el controlador XSXNUMXD con más de XNUMX XNUMX IOPS FC y XNUMX XNUMX IOPS LC.
En general, al XS5200 le fue bastante bien y aprovechó al máximo los SSD Toshiba PX04 SAS3 que instalamos. El rendimiento en total es muy impresionante, ya que 6 GB/s de lectura y 5 GB/s de escritura (64 K secuenciales) desde una SAN SMB es muy bueno. Por supuesto, hay algo de compromiso; el conjunto de funciones, la interfaz y las integraciones de software con paquetes populares como VMware dejan un poco que desear a medida que busca más lujo en las necesidades empresariales. Sea como fuere, el XS5200 ofrece un fantástico perfil de rendimiento/costo que hará el trabajo perfectamente para gran parte del público objetivo.
Lo más importante es...
El QSAN XCubeSAN con el controlador XS5226D brinda un rendimiento mucho mayor a las cargas de trabajo necesarias, aún con un precio relativamente bueno.
Suscríbase al boletín de StorageReview
