Seleccionar el tamaño de VM correcto es importante para el rendimiento óptimo de una base de datos relacional en una nube pública. Microsoft recomienda que continúe utilizando las mismas opciones de ajuste del rendimiento de la base de datos que se aplican a SQL Server en entornos de servidor locales. Usar "optimizado para memoria" Tamaños de VM para el mejor rendimiento de las cargas de trabajo de SQL Server. Recopile los datos de rendimiento de la implementación existente para identificar la utilización de RAM y CPU mientras elige las instancias correctas. La mayoría de las implementaciones eligen entre las series D, E o M.

Notas:

Para aumentar la redundancia y la alta disponibilidad, las máquinas virtuales de SQL Server deben estar en la misma "conjunto de disponibilidad" o diferente "zonas de disponibilidad" . Al crear máquinas virtuales de Azure, debe elegir entre configurar conjuntos de disponibilidad o zonas de disponibilidad; una máquina virtual de Azure no puede participar en ambos.

Para lograr una alta disponibilidad, la mejor opción es configurar SQL Server AOAG o Always On Failover Cluster Instance (FCI). Para AOAG, esto implica múltiples instancias de SQL Server en máquinas virtuales de Azure en una red virtual. Si se requiere alta disponibilidad a nivel de base de datos, considere configurar grupos de disponibilidad de SQL Server.

Microsoft SQL Server se puede implementar con un recurso compartido de archivos SMB como opción de almacenamiento. A partir de SQL Server 2012, las bases de datos del sistema (master, model, msdb o tempdb) y las bases de datos de usuario se pueden instalar con el servidor de archivos Server Message Block (SMB) como opción de almacenamiento. Esto se aplica tanto a SQL Server independiente como a SQL Server FCI.

Azure NetApp Files proporciona almacenamiento de archivos de alto rendimiento para satisfacer cualquier carga de trabajo exigente y reduce el TCO de SQL Server en comparación con las soluciones de almacenamiento en bloque. Con el almacenamiento en bloque, las máquinas virtuales tienen límites impuestos en la E/S y el ancho de banda para las operaciones de disco; los límites de ancho de banda de red solo se aplican a Azure NetApp Files. En otras palabras, no se aplican límites de E/S a nivel de VM a Azure NetApp Files. Sin estos límites de E/S, SQL Server que se ejecuta en máquinas virtuales más pequeñas conectadas a Azure NetApp Files puede funcionar tan bien como SQL Server que se ejecuta en máquinas virtuales mucho más grandes. Azure NetApp Files reduce los costos de implementación de SQL Server al reducir los costos de procesamiento y licencias de software. Para conocer un análisis detallado de los costos y los beneficios de rendimiento del uso de Azure NetApp Files para la implementación de SQL Server, consulte "Beneficios de usar Azure NetApp Files para la implementación de SQL Server" .

Cree recursos compartidos disponibles de forma continua con el portal de Azure o la CLI de Azure. En el portal, seleccione la opción de propiedad Habilitar disponibilidad continua. Para la CLI de Azure, especifique el recurso compartido como un recurso compartido disponible continuamente mediante el uso de az netappfiles volume create with the smb-continuously-avl opción establecida en $True . Para obtener más información sobre cómo crear un nuevo volumen habilitado con disponibilidad continua, consulte "Creación de un recurso compartido disponible continuamente" .

Notas:

Azure NetApp Files admite tres niveles de servicio: Estándar (16 MBps por terabyte), Premium (64 MBps por terabyte) y Ultra (128 MBps por terabyte). Aprovisionar el tamaño de volumen correcto es importante para un rendimiento óptimo de la carga de trabajo de la base de datos. Con Azure NetApp Files, el rendimiento del volumen y el límite de rendimiento se basan en una combinación de los siguientes factores:

Para obtener más información, consulte "Niveles de servicio para Azure NetApp Files" .

Como ocurre con cualquier implementación, probar la máquina virtual y el almacenamiento es fundamental. Para la validación del almacenamiento, se deben utilizar herramientas como HammerDB, Apploader o cualquier script personalizado o FIO con la combinación de lectura/escritura adecuada. Sin embargo, tenga en cuenta que la mayoría de las cargas de trabajo de SQL Server, incluso las cargas de trabajo OLTP más activas, están más cerca del 80%–90% de lectura y del 10%–20% de escritura.

Para demostrar el rendimiento, se realizó una prueba rápida contra un volumen utilizando niveles de servicio premium. En esta prueba, el tamaño del volumen se incrementó de 100 GB a 2 TB sobre la marcha sin interrumpir el acceso a las aplicaciones y sin migración de datos.

A continuación se muestra otro ejemplo de pruebas de rendimiento en tiempo real con HammerDB realizadas para la implementación cubierta en este documento. Para esta prueba, utilizamos una instancia pequeña con ocho vCPU, un SSD Premium de 500 GB y un volumen SMB de Azure NetApp Files de 500 GB. HammerDB se configuró con 80 almacenes y ocho usuarios.

El siguiente gráfico muestra que Azure NetApp Files pudo ofrecer 2,6 veces la cantidad de transacciones por minuto con una latencia cuatro veces menor al usar un volumen de tamaño comparable (500 GB).

Se realizó una prueba adicional cambiando el tamaño a una instancia más grande con 32x vCPU y un volumen de Azure NetApp Files de 16 TB. Se observó un aumento significativo en las transacciones por minuto con una latencia constante de 1 ms. HammerDB se configuró con 80 almacenes y 64 usuarios para esta prueba.

Azure NetApp Files permite un cambio de tamaño de volumen transparente y sin interrupciones, así como la capacidad de cambiar los niveles de servicio sin tiempo de inactividad y sin efectos en las aplicaciones. Esta es una capacidad única que permite una gestión dinámica de costos que evita la necesidad de dimensionar la base de datos con métricas máximas. En lugar de ello, puede utilizar cargas de trabajo de estado estable, lo que evita costos iniciales. La remodelación del volumen y el cambio dinámico del nivel de servicio le permiten ajustar el ancho de banda y el nivel de servicio de los volúmenes de Azure NetApp Files a pedido casi instantáneamente sin pausar la E/S y conservando el acceso a los datos.

Las ofertas de PaaS de Azure, como LogicApp o Functions, se pueden usar para cambiar fácilmente el tamaño del volumen en función de un webhook específico o un activador de regla de alerta para satisfacer las demandas de carga de trabajo y, al mismo tiempo, controlar el costo de forma dinámica.

Por ejemplo, considere una base de datos que necesita 250 MBps para una operación en estado estable; sin embargo, también requiere un rendimiento máximo de 400 MBps. En este caso, la implementación debe realizarse con un volumen de 4 TB dentro del nivel de servicio Premium para cumplir con los requisitos de rendimiento de estado estable. Para manejar la carga de trabajo máxima, aumente el tamaño del volumen mediante funciones de Azure a 7 TB para ese período específico y luego reduzca el tamaño del volumen para que la implementación sea rentable. Esta configuración evita el sobreaprovisionamiento del almacenamiento.