Tras analizar el rendimiento del clúster VMware VSAN con una carga de trabajo OLTP tradicional de Sysbench , quisimos comprobar la capacidad de respuesta de la plataforma ante una carga de trabajo mayor para casos de uso más exigentes. La implementación inicial consistió en cuatro máquinas virtuales Sysbench, una por nodo, pero esta carga de trabajo no elevó la E/S de disco a un nivel suficientemente alto como para considerar que los recursos se utilizaban plenamente. Esto es similar a cuando un cliente ejecuta una prueba de concepto (POC), la prueba con un subconjunto de su carga de trabajo actual, pero no mide la capacidad de respuesta de la plataforma a medida que las cargas de trabajo aumentan con el tiempo o a medida que se migran más datos de la aplicación. Para comprender mejor la respuesta de este clúster VSAN ante cargas de trabajo MySQL cada vez mayores, ampliamos la prueba de rendimiento con cuatro máquinas virtuales Sysbench (una por nodo) a un total de 8 y 12 máquinas virtuales.
Dell PowerEdge R730xd VMware VSAN Especificaciones
- Servidores Dell PowerEdge R730xd (x4)
- CPU: Ocho Intel Xeon E5-2697 v3 2.6GHz (14C/28T)
- Memoria: 64 x 16GB DDR4 RDIMM
- SSD: 16 unidades de estado sólido de 800 GB Uso mixto SAS MLC 12 Gbps
- Disco duro: 80 x 1.2TB 10K RPM SAS 6Gbps
- Redes: 4 x Intel X520 DP 10 Gb DA/SFP+, + I350 DP 1 Gb Ethernet
- Capacidad de almacenamiento: 86.46TB
Rendimiento de Sysbench
Cada máquina virtual 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 (400 GB). 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.
Con una carga de 8 máquinas virtuales, vimos que las máquinas virtuales de Sysbench consumían entre 5,200 y 6,300 MHz cada una, y los recursos totales del host indicaban que se utilizaban alrededor de 18,000 22 MHz. Esto dejó una gran cantidad de recursos de CPU con solo un 8 % utilizado por host, aunque con una carga de trabajo de 16 máquinas virtuales Sysbench estábamos usando casi todo el caché SSD disponible. Para el impacto del almacenamiento, cargamos 14 máquinas virtuales Sysbench para ampliar el espacio total, consumiendo alrededor de 86.46 TB de la capacidad total de almacenamiento de VSAN de 8 TB. Sin embargo, en el momento de la carga de trabajo de 7 VM, solo 14 TB de esos 3.5 TB estaban activos. Esto se compara con 4 TB en la carga de trabajo de XNUMX VM.
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: 12 horas
- 6 horas preacondicionamiento 32 hilos
- 1 hora 32 hilos
- 1 hora 16 hilos
- 1 hora 8 hilos
- 1 hora 4 hilos
- 1 hora 2 hilos
A medida que escalamos la carga de trabajo de OLTP de Sysbench, medimos un aumento del rendimiento de 2,830 TPS en total con 4 VM a 4,259 TPS con 8 VM. Esto da como resultado un aumento del 50 % en el rendimiento con la duplicación de la huella de la carga de trabajo.
Con el mayor rendimiento transaccional agregado, medimos el aumento de la latencia promedio de 45 ms a 60 ms por máquina virtual. Se trata de un aumento del 33 % con respecto a la carga de trabajo más pequeña.
La latencia promedio del percentil 99 también aumentó de 94 ms a 131 ms a medida que aumentaron las demandas de E/S.
Mientras el punto de referencia estaba en funcionamiento, capturamos estadísticas de CPU, disco y red de vCenter. Durante la prueba de 8 VM, vimos una distribución de VM-CPU de 5,275 MHz hasta 6,393 MHz en todas las VM.
Con 2 VM activas por nodo, vimos una actividad de disco mixta que midió un total de 609 MB/s después de que comenzó la carga de trabajo. Los picos más grandes se midieron mientras la base de datos preconstruida se copiaba a sí misma dentro de cada máquina virtual al comienzo de la prueba.
El tráfico de red de un host durante la prueba Sysbench de 8 VM midió una mezcla de 391 MB/s después de que la prueba se estabilizó.
Dado que el propósito de esta prueba es mostrar cómo VSAN responde a una carga de trabajo cada vez mayor, empujamos la plataforma a 12 VM en total después de la ejecución de 8 VM. Este fue el punto de quiebre en el que parte de la carga de trabajo salió de la caché SSD. No trazamos este rendimiento porque la mayoría de las cargas de trabajo no se completaron ni obtuvieron las puntuaciones adecuadas. Para las máquinas virtuales que terminaron, habríamos visto un rendimiento de transacción agregado tan bajo como 1000-1500TPS en todo el clúster. La caída del rendimiento que medimos puede, por supuesto, mitigarse con dispositivos flash más grandes, como SSD de 1.6 TB en lugar de 800 GB, o pasar a un modelo VSAN all-flash en el que la distribución en su nivel de lectura no tiene un tamaño tan grande. Caída de E/S. El subraya la necesidad de dimensionar correctamente el componente flash del entorno VSAN, los administradores o sus socios revendedores deben tener un buen conocimiento del conjunto de datos de trabajo. Esta es una de las fortalezas clave de la plataforma VSAN; lo que permite a los clientes personalizar las configuraciones para que se adapten mejor a las necesidades de las cargas de trabajo actuales y futuras o intercambiar/agregar SSD de manera económica según sea necesario.
Saber dónde están los puntos de ruptura de su plataforma es muy importante. Las cargas de trabajo implementadas inicialmente generalmente crecerán a medida que pase el tiempo, tanto en número de máquinas virtuales como en capacidad de almacenamiento. Cada plataforma de almacenamiento tiene un cuello de botella (incluso los arreglos all-flash), lo que nos lleva a cómo se acumula este clúster VSAN de cuatro nodos. Actualmente, solo hemos tenido una plataforma de almacenamiento que ejecutó con éxito 12 y 16 máquinas virtuales Sysbench, que era un arreglo all-flash con un MSRP de $575,000. Sin embargo, las pruebas futuras de este clúster de VSAN incluirán configuraciones all-flash para intentar alcanzar objetivos de rendimiento similares.
Revisión de VMware Virtual SAN: descripción general y configuración
Revisión de VMware Virtual SAN: rendimiento de VMmark
Revisión de VMware Virtual SAN: rendimiento de Sysbench OLTP
Revisión de VMware Virtual SAN: rendimiento de SQL Server
Revisión de VMware Virtual SAN: Rendimiento de Sysbench OLTP escalado
Revisión de VMware Virtual SAN: rendimiento sintético de HCIbench
Amazon