Blog de Amazon Web Services (AWS)
Escalando el rendimiento de SQL Server más allá de 1 millón de transacciones por minuto con Amazon FSx
En general, nuestra estrategia puede ser utilizada por clientes que buscan formas rentables de ejecutar las implementaciones de bases de datos SQL Server de mayor rendimiento en la nube.
1. Introducción
En 2021, nuestro equipo lanzó una entrada de blog que estableció un nuevo punto de referencia para el rendimiento de SQL Server en AWS. Los autores utilizaron instancias de Amazon Elastic Compute Cloud (Amazon EC2) R5B.24xLarge optimizadas para memoria capaces de hasta 60 Mbps de ancho de banda de Amazon Elastic Block Store (EBS) y 260,000 operaciones de entrada/salida por segundo (IOPS). Para aprovechar al máximo las capacidades de E/S de esta instancia, se almacenó una base de datos de prueba HammerDB TPCC de 3.5 TB en dos volúmenes io2 Block Express (IO2-Be), dispuestos en configuración RAID-0. Las pruebas de rendimiento con HammerDB con esta configuración lograron casi 830,000 TPM.
En la misma entrada de blog, los autores mostraron que alojar la base de datos en el volumen de la tienda de instancias de Amazon EC2 mejora el rendimiento en aproximadamente un 20%. Sin embargo, los volúmenes de almacén de instancias son efímeros, ya que proporcionan solo almacenamiento temporal a nivel de bloque que se pierde si detiene la instancia. Esto hace que los volúmenes de almacén de instancias sean adecuados para el almacenamiento tempdb, mientras que tanto los volúmenes de EBS como los file systems de Amazon FSx proporcionan soluciones de almacenamiento duraderas y escalables para alojar sus bases de datos.
Las familias de instancias más nuevas, como x2iedn y r6idn , ofrecen mejoras significativas en el rendimiento sobre el r5b.24xlarge que se utilizó en la publicación del blog. Estas mejoras conducen a un aumento de aproximadamente 30% del rendimiento, lo que resulta en cerca de 1 millón de TPM. Sin embargo, estas ganancias de rendimiento tienen un costo. El aumento del número de CPU virtuales (vCPU) requiere licencias adicionales de SQL Server, y la necesidad de usar RAID-0 en 3 volúmenes IO2-be para saturar el rendimiento de la instancia también aumenta los costos de almacenamiento de EBS.
En esta entrada de blog, mostraremos cómo el uso innovador de Amazon FSx le permite lograr un mayor rendimiento de SQL Server de lo que es posible solo con EBS o volúmenes de almacenamiento de instancias.
2. Configuración de prueba
Para nuestras pruebas de rendimiento de SQL Server en Windows, utilizamos sistemas de archivos Amazon FSx compatibles con Windows, a saber, Amazon FSx para NetApp ONTAP (FSx para ONTAP) y Amazon FSx para Windows File Server. Configuramos cada sistema de archivos Amazon FSx con almacenamiento SSD de 26 TB, 80.000 IOPS y rendimiento de 2 Gbps. FSx para ONTAP ofrece un rendimiento de hasta 4 Gbps y 160.000 IOPS, y FSx para Windows ofrece un rendimiento de hasta 12 Gbps y 350.000 IOPS, pero estas ofertas solo están disponibles en ciertas regiones de AWS al momento de escribir este artículo, por lo que excluimos estas configuraciones de nuestras pruebas. (Planeamos realizar el seguimiento de estas pruebas de rendimiento utilizando los niveles de capacidad de rendimiento más altos).
Para nuestras pruebas de rendimiento, utilizamos la licencia de Amazon incluida Microsoft Windows Server 2019 con SQL Server 2019 Enterprise edition en la región AWS Virginia (us-east-1). Utilizamos instancias EC2 r5dn.24xlarge, que ofrecen 768 GB de RAM, 96 vCPU, 100 Gbps de ancho de banda de red y cuatro volúmenes de almacenamiento de instancias SSD NVMe de 900 GB. Seleccionamos esta instancia porque es comparable en términos de vCPU y RAM con el r5b.24xlarge utilizado en la entrada original del blog, pero ofrece un mayor rendimiento de red, lo cual es importante, ya que utilizamos almacenamiento conectado a la red para la base de datos.
Para el tempdb, creamos un volumen RAID-0 sobre cuatro volúmenes de almacén de instancias, que están disponibles en instancias EC2 r5dn.24xlarge. También utilizamos volúmenes IO2-be EBS aprovisionados con 64,000 IOPS para archivos de registro de bases de datos de SQL Server. Almacenamos los archivos de datos de la base de datos en los sistemas de archivos de Amazon FSx.
Utilizamos HammerDB, una herramienta de benchmarking ampliamente utilizada, para simular una carga de trabajo de base de datos. La carga de trabajo OLTP de HammerDB fue la base de nuestras pruebas de rendimiento porque cargas de trabajo similares son comunes en las migraciones de SQL Server a AWS. Generamos una base de datos de pruebas que incluye 30,000 Data Warees, que es de aproximadamente 3 TB de tamaño.
Los usuarios virtuales HammerDB son usuarios simulados que ponen una carga en la base de datos para pruebas de rendimiento. Para medir el máximo rendimiento de un sistema, es recomendable comenzar con unos pocos usuarios virtuales y aumentar incrementalmente este número hasta que la base de datos TPM llegue a una meseta. Cuando aumentemos el número de usuarios virtuales, la métrica de rendimiento crecerá hasta que alcance un punto de saturación, en el que el crecimiento se detenga, o incluso disminuya.
Para cada configuración, elegimos el siguiente número de usuarios virtuales: 256, 362, 512, 724 y 1024. Para lograr resultados confiables y consistentes, realizamos tres pruebas separadas para cada punto de carga de usuario virtual. Luego calculamos el promedio de estas pruebas.
3. Pruebas de rendimiento con FSx para ONTAP de NetApp
FSx para ONTAP ofrece dos protocolos: iSCSI y SMB. Utilizamos ambos protocolos en nuestras pruebas de rendimiento.
3.1. Uso de FSx para ONTAP con protocolo iSCSI
Adjuntamos interfaces iSCSI, proporcionadas por cuatro FSx independientes para instancias ONTAP, como unidades a la instancia EC2. Estas unidades se dividieron luego en una configuración RAID-0 usando la función Espacios de almacenamiento de Windows. Para mejorar el rendimiento de las unidades iSCSI, habilitamos MPIO y asignamos cuatro paths a cada unidad. Mostramos la configuración para este escenario en la Figura 1.
Figure 1. Configuración de prueba de rendimiento FSx para Windows File Server.
Los resultados de las pruebas de desempeño HammerDB para esta configuración se presentan en la Tabla 1 y la Figura 2. Como lo indican los resultados, esta configuración nos permitió duplicar el rendimiento detallado en la entrada original del blog. El punto de meseta se alcanzó con 724 usuarios virtuales en esta configuración, lo que significa que cualquier aumento adicional en la carga condujo a una disminución del rendimiento.
Cuadro 1. FSx para resultados de rendimiento iSCSI ONTAP.
Figura 2. FSx para resultados de rendimiento iSCSI ONTAP.
3.2. Uso de FSx para ONTAP con protocolo SMB
FSx para ONTAP también es compatible con el protocolo SMB, un protocolo de comunicación cliente-servidor utilizado para compartir el acceso a los archivos a través de la red. A diferencia del protocolo iSCSI, SMB no presenta unidades virtuales, sino que ofrece recursos compartidos de archivos. Por lo tanto, no pudimos usar el striping RAID-0 para mejorar el rendimiento como lo hicimos en el escenario anterior.
En lugar de distribuir volúmenes, utilizamos una característica de SQL Server que distribuye archivos de base de datos en un grupo de archivos a través de múltiples volúmenes o recursos compartidos de archivos. Distribuimos el grupo de archivos principal a través de cuatro archivos compartidos presentados por cuatro sistemas de archivos FSx ONTAP.
En un escenario RAID-0, cada registro de una tabla se divide en varias unidades subyacentes. Sin embargo, cuando distribuimos el grupo de archivos primario a través de varios recursos compartidos, cada registro de tabla asignado a este grupo de archivos se almacena completamente en un solo recurso compartido SMB. Todos los registros de una tabla se distribuirán uniformemente entre múltiples acciones. Esta configuración se asemeja a RAID-0. Ilustramos esta configuración en la Figura 3.
Figura 3. FSx para configuración de prueba de rendimiento ONTAP para protocolo SMB.
Presentamos los resultados de las pruebas de desempeño de HammerDB para esta configuración en la Tabla 2 y Figura 4. Como muestran los resultados, esta configuración superó a la que discutimos anteriormente en la Sección 3.1 anterior. A medida que aumenta la carga, el rendimiento también mejora, aunque a un ritmo desacelerado, alcanzando una meseta en 1,024 usuarios virtuales.
Cuadro 2. FSx para resultados de rendimiento ONTAP SMB
Figura 4. FSx para resultados de rendimiento ONTAP SMB
4. Pruebas de rendimiento con FSx para Windows File Server
FSx para Windows File Server solo soporta el protocolo SMB, por lo que para nuestras pruebas utilizamos una configuración similar a la que presentamos en la Figura 3, con la excepción de que usamos FSx para Windows File Server en lugar de FSx para ONTAP, como se muestra en la Figura 5.
Figura 5. Configuración de prueba de rendimiento FSx para Windows File Server.
Al ejecutar SQL Server usando esta configuración para almacenamiento, logramos los resultados de rendimiento presentados en la Tabla 3 y Figura 6.
Cuadro 3. Resultados de rendimiento de FSx para Windows File Server.
Figura 6. Resultados de rendimiento de FSx para Windows File Server.
5. Comparación precio/rendimiento
La Tabla 4 resume los resultados de nuestras pruebas de rendimiento a través de las tres configuraciones previamente discutidas, más la configuración original usando volúmenes de IO2-be EBS (de la publicación original del blog). También proporcionamos estimaciones de costos para cada configuración. Al calcular el costo de Amazon FSx, no consideramos el costo de backup ni el ahorro de duplicación, ya que estos no se aplican a las cargas de trabajo de bases de datos.
El rendimiento para configuraciones que utilizan FSx para ONTAP utilizó los valores de rendimiento de estado estacionario, que, para cargas de trabajo dinámicas como SQL Server, típicamente 10-15% más bajos que los resultados proporcionados en las Tablas 1 y 2. El costo de cómputos se basa en la instancia EC2 r5dn.24xlarge con licencia incluida Windows Server y SQL Server Enterprise Edition en la región de AWS us-east-1 (Norte de Virginia), válida al momento de escribir este artículo.
Cuadro 4. Datos de comparación de precios y desempeño.
Agregar cuatro sistemas de archivos Amazon FSx aumentó el costo total del sistema. Sin embargo, debido al mayor rendimiento, redujo el costo general por transacción.
FSx para ONTAP, cuando se utiliza con la interfaz SMB, ofrece la mejor relación precio-rendimiento. FSx para Windows File Server proporcionó el mayor rendimiento general pero tiene el mayor costo total. Sin embargo, cuando se tiene en cuenta el desempeño superior de SQL Server logrado con esta configuración, el costo por 1,000 TPM es comparable al de FSx para ONTAP usando la interfaz SMB.
6. Ampliar el alcance de las pruebas de rendimiento
Nuestro análisis estaría incompleto si no consideráramos nuevos tipos de instancias de AWS, específicamente, la familia de instancias EC2 optimizadas para memoria x2iedn, que se utilizan para una amplia gama de aplicaciones a gran escala que consumen mucha memoria. Esta familia ofrece una relación 32:1 de memoria a vCPU en todos los tamaños, escalando hasta 4 TB de RAM, lo que los hace atractivos para usar para cargas de trabajo de SQL Server. Para la comparación con la instancia r5dn.24xlarge, utilizada en todas nuestras pruebas anteriores, optamos por la instancia x2iedn.24xlarge y x2iedn.32xlarge, con 2 TB y 4 TB de RAM, respectivamente.
El uso de una base de datos de 3.5 TB en instancias EC2 con RAM cercana o superior al tamaño de la base de datos podría no proporcionar una carga adecuada para probar el subsistema IO. Por lo tanto, generamos una base de datos HammerDB con 75,000 almacenes, lo que, a 8.5 TB, nos permite estresar el subsistema IO. También pretendimos aumentar aún más la carga de SQL Server aumentando el número de usuarios virtuales a 2,048.
Para el subsistema de almacenamiento, seleccionamos la configuración de mejor rendimiento con cuatro FSx para servidores de archivos de Windows en una configuración que coincide con la de la Figura 8. Los resultados de nuestras pruebas se presentan en la Tabla 5 y Figura 7.
Cuadro 5. Resultados de pruebas de desempeño, base de datos de 8.5 TB.
Figura 7. Resultados de pruebas de desempeño, base de datos de 8.5 TB.
SQL Server en la instancia r5dn.24xlarge alcanzó un pico de aproximadamente 1.5 millones de TPM para la base de datos de 8.5 TB. La mayor cantidad de RAM en la familia x2iedn fue el factor determinante para permitir que SQL Server en estas instancias superara la marca de 2 millones de TPM. Con la base de datos de 8.5 TB, la memoria extra en la familia x2iedn, en comparación con 768 GB disponibles en r5dn.24xlarge, de hecho marcó una diferencia significativa.
El análisis precio-rendimiento para este conjunto de pruebas se proporciona en la Tabla 6. La instancia EC2 x2iedn.24xlarge surgió como un claro ganador en términos de costo por 1,000 TPM, aunque ofreció un rendimiento marginalmente menor en comparación con la instancia EC2 x2iedn.32xlarge más grande. Para beneficiarse realmente de los 4 TB de RAM disponibles en la instancia EC2 x2iedn.32xlarge, es posible que necesitemos considerar una base de datos aún más grande.
Cuadro 6. Comparación precio/rendimiento para pruebas de bases de datos grandes.
Otra observación interesante, ilustrada en la Figura 8, es que a medida que hicimos la transición a instancias con mayor RAM, disminuyeron las IOPS y el rendimiento consumido del FSx subyacente para Windows File Server. Esto se debe a que SQL Server completó más operaciones en la caché, reduciendo la demanda en el sistema de archivos.
Figura 8. Las IOPS y el rendimiento cambian con un aumento en la RAM.
7. Conclusión
Nuestro uso innovador de múltiples sistemas de archivos de Amazon FSx nos permitió lograr un rendimiento de almacenamiento significativamente superior al que podría ofrecer un solo sistema de archivos. Esto condujo a un aumento significativo en el rendimiento de SQL Server. Aunque el uso de varios sistemas Amazon FSx aumenta el costo de la implementación, el aumento resultante en el rendimiento de SQL Server reduce el costo general por transacción a niveles comparables o incluso menores que otras configuraciones.
Si bien FSx para ONTAP con la interfaz iSCSI mostró un rendimiento algo menor en nuestras pruebas de SQL Server, el uso de RAID-0 ofrece una ruta de implementación más simple ya que no tenemos que distribuir el grupo de archivos primarios en cuatro volúmenes.
Realizamos nuestras pruebas usando cuatro sistemas de archivos Amazon FSx, pero “cuatro” no es un “número mágico” para este caso. Puede lograr un aumento significativo en el rendimiento de SQL Server utilizando solo dos o tres sistemas de archivos de Amazon FSx, dependiendo de las instancias EC2 utilizadas para alojar SQL Server y sus requisitos específicos de rendimiento y costos.
Este método proporciona otra opción para que nuestros clientes administren cargas de trabajo de SQL Server de alto rendimiento. Específicamente, nuestra estrategia puede ser utilizada por clientes que buscan formas rentables de ejecutar las implementaciones de bases de datos SQL Server de mayor rendimiento en la nube.
Este artículo fue traducido del Blog de AWS en Inglés.
Acerca de los autores
Alex Zarenin es Arquitecto Principal de Soluciones con Amazon Web Services. Trabaja con empresas de servicios financieros diseñando e implementando una amplia gama de soluciones técnicas. Con experiencia de dominio en tecnologías Microsoft, Alex cuenta con más de 30 años de experiencia técnica tanto en el sector comercial como en el público. Alex tiene un doctorado en Ciencias de la Computación de la Universidad de Nueva York.
Sudhir Amin es arquitecto sénior de soluciones en Amazon Web Services. En su puesto con sede en Nueva York, brinda orientación arquitectónica y asistencia técnica a clientes empresariales en diferentes verticales de la industria, acelerando su adopción en la nube. Es un gran fanático del snooker, los deportes de combate como el boxeo y UFC, y le encanta viajar a países con ricas reservas de vida silvestre donde llega a ver de cerca a los animales más majestuosos del mundo.
Vikas Babu Gali es un arquitecto especialista en soluciones, que se centra en las cargas de trabajo de Microsoft en Amazon Web Services. Vikas proporciona orientación arquitectónica y asistencia técnica a clientes en diferentes verticales de la industria acelerando su adopción en la nube.
Traductor
Luiz Rampanelli es arquitecto de soluciones en el equipo de AWS Latam. Cuenta con más de 10 años de experiencia con cargas de trabajo de Microsoft en entornos híbridos y de nube. Trabaja diseñando soluciones siguiendo las mejores prácticas para que los clientes puedan aprovechar al máximo los beneficios de la nube de AWS.
Revisor
JuanMa Silva quien es arquitecto de soluciones con especialidad en Microsoft para México y MCO. Cuenta con 15 años de experiencia en la industria de IT, en posiciones de Sysadmin, consultor para ayudar a migrar clientes a la nube y modernización de aplicaciones, soporte aplicaciones de misión critica basados en tecnologia Microsoft.