sql >> Base de Datos >  >> RDS >> Database

Consideraciones sobre el rendimiento de la instancia administrada de Azure SQL

La Instancia administrada de Azure SQL Database estuvo disponible de forma general a fines de 2018. Desde entonces, muchas organizaciones han comenzado a migrar a la Instancia administrada para obtener los beneficios de un entorno administrado. Las organizaciones están aprovechando las copias de seguridad administradas, muchas funciones de seguridad integradas, un SLA de tiempo de actividad del 99,99 % y un entorno siempre actualizado en el que ya no son responsables de parchear SQL Server o el sistema operativo.

Un tamaño no siempre caben todos.

Instancia administrada proporciona dos niveles de rendimiento. El propósito general está diseñado para aplicaciones con rendimiento típico y requisitos de latencia de E/S y proporciona alta disponibilidad integrada. El crítico para el negocio El nivel está diseñado para aplicaciones que requieren baja latencia de E/S y mayores requisitos de alta disponibilidad. Business Critical también proporciona dos secundarios no legibles y un secundario legible. El secundario legible es una excelente manera de distribuir la carga de trabajo fuera del principal, lo que puede reducir el nivel de servicio requerido para el principal, lo que reduce el gasto general de la instancia.

Cuando se lanzó Instancia administrada por primera vez, podía elegir entre procesadores Gen4 y Gen5. Gen4 todavía se describe en la documentación, pero esta opción casi no está disponible ahora. Para este artículo, solo cubriré las configuraciones que utilizan los procesadores Gen5.

Cada nivel de servicio admite entre 4 y 80 CPU lógicas, también conocidas como núcleos virtuales o vCores. La memoria se asigna a aproximadamente 5,1 GB por núcleo virtual. Uso general proporciona hasta 8 TB de almacenamiento Azure Blob de alto rendimiento, mientras que Business Critical proporciona hasta 4 TB de almacenamiento SSD local ultrarrápido.

Memoria

Con solo 5,1 GB de memoria por núcleo virtual, una instancia con menos núcleos virtuales podría tener problemas. Las opciones para las configuraciones de núcleos virtuales son 4, 8, 16, 24, 32, 40, 64 y 80 núcleos virtuales. Si hace los cálculos en cada una de las opciones de núcleos virtuales ((number of vCores) × (5.1 GB) ), obtendrá las siguientes combinaciones de núcleo/memoria:

  4 vCores  =   20.4 GB
  8 vCores  =   40.8 GB
 16 vCores  =   81.6 GB
 24 vCores  =  122.4 GB
 32 vCores  =  163.2 GB
 40 vCores  =  204.0 GB
 64 vCores  =  326.4 GB
 80 vCores  =  408.0 GB

Para muchas organizaciones a las que he ayudado a hacer la transición de las instalaciones a la Instancia administrada, he visto una reducción significativa en la memoria. Las configuraciones locales típicas serían 4 núcleos virtuales y 32 GB de memoria u 8 núcleos virtuales y 64 GB. Ambos representan más de un 30% de reducción en la memoria. Si la instancia ya estaba bajo presión de memoria, esto puede causar problemas. En la mayoría de los casos, pudimos optimizar la instancia local para ayudar a aliviar la presión de la memoria antes de pasar a la Instancia administrada, pero en algunos casos, el cliente tuvo que optar por una instancia de núcleo virtual superior para aliviar la presión de la memoria. .

Almacenamiento

El almacenamiento es un poco más difícil de planificar y considerar, debido a que se tienen que considerar múltiples factores. Para el almacenamiento, debe tener en cuenta el requisito de almacenamiento general tanto para el tamaño de almacenamiento como para las necesidades de E/S. ¿Cuántos GB o TB se necesitan para la instancia de SQL Server y qué tan rápido debe ser el almacenamiento? ¿Cuántas IOPS y cuánto rendimiento usa la instancia local? Para eso, debe establecer una línea de base de su carga de trabajo actual utilizando perfmon para capturar MB/s promedio y máximo y/o tomar instantáneas de sys.dm_io_virtual_file_stats para capturar la utilización del rendimiento. Esto le dará una idea de qué tipo de E/S y rendimiento necesita en el nuevo entorno. Varios clientes con los que he trabajado se han perdido esta parte vital de la planificación de la migración y se han encontrado con problemas de rendimiento debido a que seleccionaron un nivel de instancia que no admitía su carga de trabajo.

Esto es fundamental para la línea de base porque con los servidores locales, es común tener almacenamiento provisto desde una SAN súper rápida con capacidades de alto rendimiento para máquinas virtuales de menor tamaño. En Azure, sus límites de rendimiento e IOPS están determinados por el tamaño del nodo de proceso y, en el caso de Administrar instancia, está determinado por la cantidad de núcleos virtuales asignados. Para fines generales, existe un límite de 30 a 40 000 IOPS por instancia o de 500 a 12 500 IOPS por archivo, según el tamaño del archivo. El rendimiento por archivo también se basa en el rango de tamaño desde 100 MiB/s para archivos de hasta 128 GB y hasta 480 MiB/s para archivos de 4 TB y más grandes. En Business Critical, las IOPS oscilan entre 5500 y 110000 por instancia o 1375 IOPS por núcleo virtual.

Los consumidores también deben tener en cuenta el rendimiento de escritura de registros para la instancia. El uso general es de 3 MB/s por núcleo virtual con un máximo de 22 MB/s para la instancia y Business Critical es de 4 MB/s por núcleo virtual con un máximo de 48 MB/s para toda la instancia. En mi experiencia trabajando con clientes, muchos han superado con creces estos límites de rendimiento de escritura. Para algunos ha sido espectacular, y para otros, han podido optimizar y modificar su sistema para disminuir la carga.

Además de la necesidad de conocer el rendimiento general y los requisitos de E/S, el tamaño del almacenamiento también está vinculado a la cantidad de núcleos virtuales elegidos. Para uso general:

        4 vCores  =  2 TB max
   8 - 80 vCores  =  8 TB max

Para negocio crítico:

    4 – 16 vCores  =  1 TB
        24 vCores  =  2 TB
   32 - 80 vCores  =  4 TB

Para uso general, una vez que llegue a 8 núcleos virtuales, puede maximizar el almacenamiento disponible, lo que funciona bien para aquellos que solo necesitan uso general. Pero cuando necesita Business Critical, las cosas pueden ser más desafiantes. He trabajado con muchos clientes que tienen varios TB asignados a máquinas virtuales con 4, 8, 16 y 24 procesadores lógicos. Para cualquiera de estos clientes, tendrían que subir al menos 32 núcleos virtuales solo para cumplir con su requisito de almacenamiento, una opción costosa. Azure SQL Database tiene un problema similar con el tamaño máximo de la base de datos y a Microsoft se le ocurrió una opción de Hiperescala. Esperamos que esto se convierta en una opción para la Instancia administrada en algún momento para abordar los límites de almacenamiento de manera similar.

El tamaño de tempdb también se correlaciona con la cantidad de núcleos virtuales. En el nivel de uso general, obtiene 24 GB por núcleo virtual (hasta 1920 GB) para los archivos de datos, con un límite de tamaño de archivo de registro tempdb de 120 GB. Para el nivel Business Critical, tempdb puede crecer hasta el tamaño de almacenamiento de la instancia actualmente disponible.

OLTP en memoria

Para aquellos que actualmente aprovechan In-Memory OLTP (o planean hacerlo), tenga en cuenta que solo se admite en el nivel de servicio Business Critical. La cantidad de espacio disponible para las tablas en memoria también está limitada por núcleos virtuales:

    4 vCores  =    3.14 GB
    8 vCores  =    6.28 GB
   16 vCores  =   15.77 GB
   24 vCores  =   25.25 GB
   32 vCores  =   37.94 GB
   40 vCores  =   52.23 GB
   64 vCores  =   99.90 GB
   80 vCores  =  131.86 GB

Conclusión

Al planificar una migración a Instancia administrada de Azure SQL, hay varias consideraciones que se deben tener en cuenta antes de decidir migrar. Primero, debe comprender completamente sus requisitos de memoria, CPU y almacenamiento, ya que esto determinará el tamaño de la instancia. Igual de importante es saber cuáles son sus requisitos de E/S de almacenamiento. Las IOPS y el rendimiento para el nivel de uso general están directamente relacionados con los núcleos virtuales y el tamaño de los archivos de la base de datos. Para Business Critical, está vinculado a la cantidad de núcleos virtuales. Si tiene una carga de trabajo muy intensiva de E/S, Business Critical es el nivel de servicio más atractivo debido a que proporciona mayores números de rendimiento e IOPS. El desafío con Business Critical es la menor capacidad de almacenamiento y solo admite 1 TB para toda la instancia hasta 16 vCores.

Con una planificación adecuada y la posible desconsolidación de instancias más grandes a Instancias administradas más pequeñas, esta oferta puede ser una opción de migración muy viable para muchas organizaciones. El atractivo son los beneficios de tener copias de seguridad administradas, alta disponibilidad integrada con un acuerdo de nivel de servicio del 99,99 %, características y opciones de seguridad adicionales y no tener que preocuparse por parchear un sistema operativo o una instancia de SQL Server.