Lista de comprobación: Procedimientos recomendados de SQL Server en máquinas virtuales de Azure

  • Artículo
  • Tiempo de lectura: 18 minutos

SE APLICA A: SQL Server en máquinas virtuales de Azure

En este artículo se proporciona una lista de comprobación rápida como una serie de procedimientos recomendados e instrucciones para optimizar el rendimiento de SQL Server en máquinas virtuales (VM) de Azure.

Para obtener detalles completos, consulte otros artículos de esta serie: Tamaño de máquina virtual, Almacenamiento, Seguridad, Configuración de HADR, Recopilación de línea base.

Habilite SQL Assessment para SQL Server en máquinas virtuales de Azure y SQL Server se evaluará con los procedimientos recomendados y los resultados aparecerán en la página de administración de máquinas virtuales de SQL de Azure Portal.

Para ver vídeos sobre las características más recientes para optimizar el rendimiento de las VM con SQL Server y automatizar la administración, vea los siguientes vídeos expuestos a datos:

Información general

Al ejecutar SQL Server en Azure Virtual Machines, siga usando las mismas opciones de ajuste de rendimiento de bases de datos aplicables a SQL Server en los entornos de servidor locales. Sin embargo, el rendimiento de una base de datos relacional en una nube pública depende de muchos factores, como el tamaño de una máquina virtual y la configuración de los discos de datos.

Por lo general, existe un equilibrio entre la optimización de los costos y la optimización del rendimiento. Esta serie de procedimientos recomendados de rendimiento se centra en cómo obtener el mejor rendimiento de SQL Server en las máquinas virtuales de Azure. Si su carga de trabajo es menos exigente, podría no necesitar todas las optimizaciones recomendadas. Tenga en cuenta sus necesidades de rendimiento, costos y patrones de carga de trabajo a medida que evalúa estas recomendaciones.

Tamaño de VM

La siguiente es una lista de comprobación rápida de los procedimientos recomendados de tamaño de máquinas virtuales para ejecutar la instancia de SQL Server en la máquina virtual de Azure:

  • La nueva serie Ebdsv5 proporciona la mayor proporción de rendimiento de E/S a núcleo virtual de Azure junto con una proporción de memoria a núcleo virtual de 8. Esta serie ofrece el rendimiento al mejor precio para cargas de trabajo de SQL Server en máquinas virtuales de Azure. Considere esta serie en primer lugar para la mayoría de cargas de trabajo de SQL Server.
  • Use tamaños de máquina virtual con 4 o más vCPU como E4ds_v5 o superior.
  • Use tamaños de máquinas virtuales optimizados para memoria para obtener el mejor rendimiento de las cargas de trabajo de SQL Server.
  • Las series Edsv5, M- y Mv2- ofrecen la proporción óptima de memoria por núcleo virtual necesaria para las cargas de trabajo de OLTP.
  • Las máquinas virtuales de la serie M ofrecen la relación entre memoria y núcleos virtuales más alta de Azure. Considere estas máquinas virtuales para cargas de trabajo críticas para el objetivo y de almacenamiento de datos.
  • Aproveche las imágenes de Azure Marketplace para implementar máquinas virtuales de SQL Server, ya que la configuración de SQL Server y las opciones de almacenamiento están configuradas para un rendimiento óptimo.
  • Recopile las características de rendimiento de la carga de trabajo de destino y úselas para determinar el tamaño de VM adecuado para el negocio.
  • Use la herramienta de recomendación de SKU de Data Migration Assistant para encontrar el tamaño de máquina virtual adecuado para la carga de trabajo de SQL Server existente.

Para obtener más información, vea los procedimientos recomendados de tamaño de máquinas virtuales generales.

Storage

La siguiente es una lista de comprobación rápida de los procedimientos recomendados de configuración del almacenamiento para ejecutar la instancia de SQL Server en la máquina virtual de Azure:

  • Supervise la aplicación y determine los requisitos de ancho de banda y latencia de almacenamiento para los archivos de registros, de datos y de tipo tempdb de SQL Server antes de elegir el tipo de disco.
  • Para optimizar el rendimiento del almacenamiento, planee el uso más alto de IOPS disponible sin almacenamiento en caché, y use el almacenamiento en caché de datos como característica de rendimiento para realizar lecturas de datos al tiempo que evita el límite de máquinas virtuales y discos.
  • Coloque los archivos de datos, de registros y de tipo tempdb en unidades independientes.
    • Para la unidad de datos, use discos prémium de P30 y P40 o más pequeños para garantizar la disponibilidad del soporte técnico de la caché.
    • En cuanto a la unidad de registro, planee la capacidad y el rendimiento de prueba frente al costo al evaluar los discos prémium P30-P80.
      • Si se requiere latencia de almacenamiento de submilisegundos, use los discos Ultra de Azure para el registro de transacciones.
      • En el caso de las implementaciones de máquinas virtuales de la serie M, considere la posibilidad de usar el Acelerador de escritura en lugar de discos Ultra de Azure.
    • Coloque tempdb en la unidad SSD efímera local (de manera predeterminada, ) para la mayoría de las cargas de trabajo de SQL Server que no forman parte de la instancia de clúster de conmutación por error (FCI) después de elegir el tamaño de VM óptimo.
    • Para FCI, coloque tempdb en el almacenamiento compartido.
      • Si la carga de trabajo de FCI depende en gran medida del rendimiento del disco tempdb, como configuración avanzada coloque tempdb en la unidad SSD efímera local (de manera predeterminada, D:\), que no forma parte del almacenamiento de FCI. Esta configuración necesitará supervisión personalizada y acciones para garantizar que la unidad SSD efímera local (de manera predeterminada, D:\) esté disponible en todo momento, ya que los errores de esta unidad no desencadenarán acciones de FCI.
  • Divida varios discos de datos de Azure mediante los espacios de almacenamiento para aumentar el ancho de banda de E/S hasta los límites de rendimiento e IOPS de la máquina virtual de destino.
  • Establezca el almacenamiento en caché del host en Solo lectura para los discos de archivos de datos.
  • Establezca el almacenamiento en caché del host en Ninguno para los discos de archivos de datos.
    • No habilite el almacenamiento en caché de lectura y escritura en discos que contengan datos o archivos de registro de SQL Server.
    • Detenga siempre el servicio de SQL Server antes de cambiar la configuración de la memoria caché del disco.
  • En las cargas de trabajo de desarrollo y pruebas, considere la posibilidad de usar almacenamiento estándar. No se recomienda usar HDD o SDD estándar para las cargas de trabajo de producción.
  • La expansión de disco basada en crédito (P1-P20) solo se debe tener en cuenta para cargas de trabajo de desarrollo y pruebas más pequeñas y sistemas departamentales.
  • Aprovisione la cuenta de almacenamiento en la misma región que la VM de SQL Server.
  • Deshabilite el almacenamiento con redundancia geográfica de Azure (replicación geográfica) y use LRS (almacenamiento con redundancia local) en la cuenta de almacenamiento.
  • Formatee el disco de datos para que use un tamaño de unidad de asignación de 64 KB para todos los archivos de datos ubicados en una unidad que no sea la unidad temporal D:\ (que tiene un valor predeterminado de 4 KB). Las VM de SQL Server implementadas a través de Azure Marketplace se ofrecen con discos de datos formateados con el tamaño de la unidad de asignación y la intercalación para el bloque de almacenamiento establecido en 64 KB.

Para obtener más información, vea los procedimientos recomendados de almacenamiento generales.

características de SQL Server

A continuación se muestra una lista de comprobación rápida de los procedimientos recomendados para las opciones de configuración de SQL Server al ejecutar las instancias de SQL Server en una máquina virtual de Azure en producción:

de Windows Azure

La siguiente es una lista de comprobación rápida de los procedimientos recomendados para una guía específica de Azure al ejecutar la instancia de SQL Server en una máquina virtual de Azure:

Configuración de alta disponibilidad y recuperación ante desastres

Las características de alta disponibilidad y recuperación ante desastres (HADR) como, por ejemplo, el grupo de disponibilidad Always On y la instancia de clúster de conmutación por error, se basan en la tecnología subyacente de clúster de conmutación por error de Windows Server. Revise los procedimientos recomendados para modificar la configuración de HADR para admitir mejor el entorno en la nube.

Para el clúster de Windows, tenga en cuenta estos procedimientos recomendados:

  • Implemente las máquinas virtuales con SQL Server en varias subredes siempre que sea posible para evitar la dependencia de un nombre de red distribuida (DNN) o una instancia de Azure Load Balancer para enrutar el tráfico a la solución de alta disponibilidad y recuperación ante desastres.
  • Cambie el clúster a parámetros menos agresivos para evitar interrupciones inesperadas de errores de red transitorios o mantenimiento de la plataforma de Azure. Para más información, consulte la configuración de latidos y umbrales. Para Windows Server 2012 y versiones posteriores, utilice los siguientes valores recomendados:
    • SameSubnetDelay: 1 segundo
    • SameSubnetThreshold: 40 latidos
    • CrossSubnetDelay: 1 segundo
    • CrossSubnetThreshold: 40 latidos
  • Coloque las máquinas virtuales en un conjunto de disponibilidad o en distintas zonas de disponibilidad. Para más información, consulte Configuración de disponibilidad de máquinas virtuales.
  • Use una sola NIC por nodo de clúster y una sola subred.
  • Configure la votación de cuórum de clúster para usar 3 o más números de votos impares. No asigne votos a las regiones de recuperación ante desastres.
  • Supervise detenidamente los límites de recursos para evitar reinicios inesperados o conmutaciones por error debido a restricciones de recursos.
    • Asegúrese de que el sistema operativo, controladores y SQL Server disponen de las versiones más recientes.
    • Optimice el rendimiento de SQL Server en las máquinas virtuales de Azure. Revise las demás secciones de este artículo para obtener más información.
    • Reduzca o extienda la carga de trabajo para evitar límites de recursos.
    • Cambie a una máquina virtual o disco cuyos límites sean más altos para evitar restricciones.

Para el grupo de disponibilidad SQL Server o la instancia de clúster de conmutación por error, tenga en cuenta estos procedimientos recomendados:

  • Si experimenta errores inesperados con frecuencia, siga los procedimientos recomendados de rendimiento descritos en este artículo.
  • Si la optimización del rendimiento de las máquinas virtuales SQL Server no resuelve las conmutaciones por error inesperadas, considere la posibilidad de relajar la supervisión para el grupo de disponibilidad o la instancia de clúster de conmutación por error. Sin embargo, es posible que no se pueda solucionar el origen subyacente de la incidencia y podría enmascarar los síntomas al reducir la probabilidad de error. Es posible que tenga que investigar y abordar la causa principal subyacente. Para Windows Server 2012 y versiones posteriores, utilice los siguientes valores recomendados:
    • Tiempo de espera de concesión: use esta ecuación para calcular el valor máximo de tiempo de espera de concesión:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Comience con 40 segundos. Si usa los valores SameSubnetThreshold y SameSubnetDelay flexibles recomendados anteriormente, no supere los 80 segundos para el valor de tiempo de espera de concesión.
    • Número máximo de errores en un período especificado: puede establecer este valor en 6.
    • Tiempo de espera de comprobación de estado: puede establecer este valor en 60000 inicialmente y luego ajustarlo según sea necesario.
  • Cuando use el nombre de red virtual (VNN) y Azure Load Balancer para conectarse a una solución de alta disponibilidad y recuperación ante desastres, especifique MultiSubnetFailover = true en la cadena de conexión, incluso si el clúster solo abarca una subred.
    • Si el cliente no admite MultiSubnetFailover = True, es posible que deba establecer RegisterAllProvidersIP = 0 y HostRecordTTL = 300 para copiar en caché las credenciales de cliente durante períodos más cortos. Sin embargo, esto puede provocar consultas adicionales en el servidor DNS.
  • Para conectarse a la solución HADR mediante el nombre de red distribuida (DNN), tenga en cuenta lo siguiente:
    • Debe usar un controlador cliente que admita MultiSubnetFailover = True y este parámetro debe estar en la cadena de conexión.
    • Use un puerto DNN único en la cadena de conexión al conectarse al cliente de escucha de DNN para un grupo de disponibilidad.
  • Use una cadena de conexión de creación de reflejo de la base de datos para que un grupo de disponibilidad básico omita la necesidad de un equilibrador de carga o DNN.
  • Valide el tamaño del sector de los discos duros virtuales antes de implementar la solución de alta disponibilidad para evitar tener E/S mal alineadas. Consulte KB3009974 para más información.
  • Si el motor de base de datos de SQL Server, la escucha del grupo de disponibilidad Always On o el sondeo de estado de la instancia de clúster de conmutación por error están configurados para usar un puerto entre 49152 y 65536 (el intervalo de puertos dinámicos predeterminado para TCP/IP), agregue una exclusión para cada puerto. Si lo hace, impedirá que otros sistemas se asignen dinámicamente al mismo puerto. En el ejemplo siguiente se crea una exclusión para el puerto 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Para obtener más información, consulte los procedimientos recomendados de HADR.

Seguridad

La lista de comprobación de esta sección trata los procedimientos recomendados de seguridad para SQL Server en VM de Azure.

Las características y funcionalidades de SQL Server le ofrecen un método de seguridad en el nivel de datos y, gracias a ellas, puede lograr una defensa en profundidad en el nivel de infraestructura para soluciones híbridas y basadas en la nube. Asimismo, con las medidas de seguridad de Azure, es posible cifrar los datos confidenciales, proteger las máquinas virtuales frente a virus y malware, proteger el tráfico, identificar y detectar amenazas, satisfacer los requisitos de cumplimiento y proporcionar un método único de administración y generación de informes para cualquier necesidad de seguridad en la nube híbrida.

  • Use Azure Security Center para evaluar la posición de seguridad del entorno de datos y tomar medidas para mejorarla. Funcionalidades como Azure Advanced Threat Protection (ATP) se pueden aprovechar en las cargas de trabajo híbridas para mejorar la evaluación de la seguridad y ofrecer la capacidad de reaccionar ante los riesgos. El registro de la VM de SQL Server con la extensión del agente de IaaS de SQL muestra las evaluaciones de Azure Security Center en el recurso de máquina virtual de SQL de Azure Portal.
  • Aproveche Microsoft Defender para SQL para detectar y mitigar posibles vulnerabilidades de la base de datos, así como para detectar actividades anómalas que podrían indicar una amenaza para la capa de base de datos y la instancia de SQL Server.
  • La evaluación de vulnerabilidades es una parte de Microsoft Defender para SQL que puede detectar posibles riesgos para el entorno de SQL Server y ayudarlo a corregirlos. Permite ver el estado de la seguridad e incluye los pasos necesarios para resolver problemas de seguridad.
  • Azure Advisor analiza la configuración de recursos y la telemetría de uso y recomienda soluciones que le permiten mejorar la rentabilidad, el rendimiento, la alta disponibilidad y la seguridad de los recursos de Azure. Aproveche Azure Advisor en el nivel de máquina virtual, el grupo de recursos o la suscripción a fin de poder identificar y aplicar procedimientos recomendados para optimizar las implementaciones de Azure.
  • Use Azure Disk Encryption cuando los requisitos de cumplimiento y seguridad exijan que cifre los datos de un extremo a otro con sus claves de cifrado, incluido el cifrado del disco efímero (temporal adjunto localmente).
  • De manera predeterminada, los discos de Managed Disks se cifran en reposo mediante Azure Storage Service Encryption, donde las claves de cifrado son claves administradas por Microsoft en Azure.
  • Para ver una comparación de las opciones de cifrado de disco administrado, revise el gráfico de comparación de cifrado de discos administrados.
  • Los puertos de administración deben estar cerrados en las máquinas virtuales: los puertos de administración remota abiertos exponen la VM a un alto nivel de riesgo de ataques basados en Internet. Estos ataques intentan averiguar las credenciales por medio de fuerza bruta a fin de obtener acceso de administrador a la máquina
  • Active el acceso Just-In-Time (JIT) para máquinas virtuales de Azure.
  • Use Azure Bastion en el protocolo de escritorio remoto (RDP).
  • Bloquee los puertos y permita solo el tráfico de aplicaciones necesario mediante Azure Firewall, que funciona como un firewall como servicio (FaaS) administrado que concede o rechaza el acceso al servidor en función de la dirección IP de origen.
  • Use los grupos de seguridad de red (NSG) para filtrar el tráfico hacia y desde los recursos de Azure en Azure Virtual Networks.
  • Aproveche los grupos de seguridad de aplicaciones para agrupar servidores que tienen requisitos de filtrado de puertos similares, con funciones similares, como servidores web y servidores de bases de datos.
  • En el caso de los servidores web y de aplicaciones, aproveche la protección contra la denegación de servicio distribuido (DDoS) de Azure. Los ataques DDoS están diseñados para sobrecargar y agotar los recursos de red, lo que hace que las aplicaciones funcionen lentamente o no respondan. Es habitual que los ataques DDoS se dirijan a las interfaces de usuario. La protección contra DDoS de Azure sanea el tráfico no deseado antes de que afecte a la disponibilidad del servicio.
  • Aproveche las extensiones de VM para administrar el antimalware, el estado deseado, la detección de amenazas, la prevención y la corrección a fin de abordar las amenazas en el nivel de sistema operativo, máquina y red:
  • Aproveche Azure Policy para crear reglas de negocio que se puedan aplicar a su entorno. Las directivas de Azure Policy evalúan los recursos de Azure comparando las propiedades de esos recursos con las reglas definidas en formato JSON.
  • Azure Blueprints permite a los arquitectos de nube y grupos de TI central definir un conjunto repetible de recursos de Azure que implementa y cumple los estándares, patrones y requisitos de la organización. Azure Blueprints es diferente de las directivas de Azure Policy.

Pasos siguientes

Para obtener más información, consulte los demás artículos de esta serie:

Considere la posibilidad de habilitar SQL Assessment para SQL Server en máquinas virtuales de Azure

Revise otros artículos sobre la máquina virtual de SQL Server en Introducción a SQL Server en Azure Virtual Machines. Si tiene alguna pregunta sobre las máquinas virtuales de SQL Server, consulte las Preguntas más frecuentes.