Almacenamiento: procedimientos recomendados de rendimiento de SQL Server en VM de Azure

  • Artículo

Se aplica a:SQL Server en VM de Azure

En este artículo se proporcionan los procedimientos recomendados y guías de almacenamiento para optimizar el rendimiento de su SQL Server en las máquinas virtuales (VM) de Azure.

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 Azure Virtual Machines. 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.

Para obtener más información, consulte otros artículos de esta serie: Lista de comprobación, Tamaño de VM, Seguridad, Configuración de HADR y Recopilación de la base de referencia.

Lista de comprobación

Revise la siguiente lista de comprobación para obtener una breve descripción de los procedimientos recomendados de almacenamiento que se describen en el resto del artículo con mayor detalle:

  • Supervise la aplicación y determine los requisitos de ancho de banda y latencia de almacenamiento para los archivos de datos, registros y tempdb de SQL Server antes de elegir el tipo de disco.
  • Si está disponible, configure los tempdbarchivos de datos y de registro en el volumenD: SSD local. La extensión agente de IaaS de SQL controla la carpeta y los permisos necesarios al volver a aprovisionar.
  • 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 una característica de rendimiento para realizar lecturas de datos al tiempo que evita el límite de máquinas virtuales y discos.
  • Al usar las máquinas virtuales de SQL Server de la serie Ebdsv5 o Ebsv5, use SSD Prémium v2 para obtener el mejor rendimiento de precio. Puede implementar las máquinas virtuales de SQL Server con SSD Prémium v2 mediante Azure Portal (actualmente en versión preliminar).
  • Considere la posibilidad de usar Azure Elastic SAN para cargas de trabajo de SQL Server para mejorar la rentabilidad debido a la consolidación del almacenamiento, el rendimiento dinámico compartido y la capacidad de impulsar una mayor capacidad de proceso de almacenamiento sin necesidad de actualizar una máquina virtual.
  • Colocar archivos de datos, registros y tempdb en unidades independientes.
    • En el caso de la unidad de datos, use discos prémium P30 y P40, o más pequeños, para garantizar la disponibilidad del soporte técnico de la caché. Si utiliza la serie de máquinas virtuales Ebdsv5, use SSD prémium v2, ya que ofrece una mejor relación entre rendimiento y precio para aquellas cargas de trabajo que requieren un alto rendimiento de E/S e IOPS.
    • En cuanto a la unidad de registro, planee la capacidad y el rendimiento de prueba frente al costo al evaluar los discos P30 - P80 con SSD prémium v2 o SSD prémium.
      • Si se requiere una latencia de almacenamiento inferior a un milisegundos, use los discos ultra de Azure o SSD prémium v2 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 discos Ultra de Azure.
    • Coloque tempdb en el disco temporal (el disco temporal es efímero y el valor predeterminado es D:\) 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.
      • Si la capacidad de la unidad local no es suficiente para tempdb, considere la posibilidad de cambiar el tamaño de la VM. Consulte las directivas de caché de archivos de datos para obtener más información.
    • En el caso de las instancias de clúster de conmutación por error (FCI) coloque tempdb 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 necesita 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 registro.
    • 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 el caso de cargas de trabajo de desarrollo y pruebas y el archivo de copia de seguridad a largo plazo, considere la posibilidad de usar el almacenamiento estándar. No se recomienda usar HDD o SDD estándar con 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.
  • 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.
  • 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.
  • Configure 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.
  • Habilite la valoración de procedimientos recomendados de SQL para identificar posibles incidencias de rendimiento y evaluar que la VM con SQL Server está configurada para seguir los procedimientos recomendados.
  • Revise y supervise los límites de disco y VM mediante métricas de uso de E/S de almacenamiento.
  • Excluya los archivos de SQL Server del examen de software antivirus, incluidos los archivos de datos, los archivos de registro y los archivos de copia de seguridad.

Para comparar la lista de comprobación de almacenamiento con otros procedimientos recomendados, consulte la Lista de comprobación de procedimientos recomendados de rendimiento.

Información general

Para encontrar la configuración más eficaz para las cargas de trabajo de SQL Server en una VM de Azure, empiece por medir el rendimiento de almacenamiento de la aplicación empresarial. Una vez que se conocen los requisitos de almacenamiento, seleccione una máquina virtual que admita el IOPS y el rendimiento necesarios con la relación de memoria a núcleo virtual adecuada.

Elija un tamaño de VM con suficiente escalabilidad de almacenamiento para la carga de trabajo y una mezcla de discos (normalmente en un grupo de almacenamiento) que cumplan los requisitos de capacidad y rendimiento de su negocio.

El tipo de disco depende del tipo de archivo que se hospeda en el disco y de los requisitos de rendimiento máximo.

Sugerencia

El aprovisionamiento de una VM con SQL Server a través de Azure Portal le guiará a través del proceso de configuración del almacenamiento e implementa la mayoría de los procedimientos recomendados de almacenamiento, como la creación de grupos de almacenamiento independientes para los archivos de registro, de datos y de tipo tempdb de destino en la unidad D:\ y la habilitación de la directiva de almacenamiento en caché óptima. Para obtener más información sobre el aprovisionamiento y la configuración del almacenamiento, consulte Configuración del almacenamiento de VM de SQL.

Tipos de disco de máquina virtual

Puede elegir el nivel de rendimiento de los discos. Los tipos de discos administrados disponibles como almacenamiento subyacente (que se enumeran mediante el aumento de las funcionalidades de rendimiento) son las unidades de disco duro (HDD) estándar, las unidad de estado sólido (SSD) estándar, las SSD prémium, las SSD prémium v2 y los discos Ultra.

En el caso de las unidades de disco duro (HDD) estándar, las unidad de estado sólido (SSD) estándar y las SSD prémium, el rendimiento del disco aumenta a la vez que su tamaño, agrupado por etiquetas de disco prémium, que van desde P1, con 4 GiB de espacio y 120 IOPS, hasta P80, con 32 TiB de almacenamiento y 20 000 IOPS. Premium Storage admite una caché de almacenamiento que le permite mejorar el rendimiento de lectura y escritura de algunas cargas de trabajo. Para obtener más información, consulte Introducción a Managed Disks.

El rendimiento tanto de SSD prémium v2 como de los discos Ultra se puede cambiar, independientemente del tamaño del disco. Para más información, consulte Rendimiento de discos Ultra y Rendimiento de SSD prémium v2.

También hay tres roles de discos principales que se deben tener en cuenta para SQL Server en las máquinas virtuales de Azure: un disco del sistema operativo, un disco temporal y los discos de datos. Elija cuidadosamente lo que se almacena en la unidad del sistema operativo (C:\) y en la unidad temporal efímera (D:\).

Disco del sistema operativo

Un disco del sistema operativo es un VHD que se puede arrancar y montar como la versión en ejecución de un sistema operativo y está etiquetado como la unidad C:\. Al crear una máquina virtual de Azure, la plataforma conecta al menos un disco a ella para el disco del sistema operativo. La unidad C:\ es la ubicación predeterminada para las instalaciones de aplicaciones y la configuración de archivos.

En entornos de SQL Server de producción, no use el disco del sistema operativo para los archivos de datos, los archivos de registro y los registros de errores.

Disco temporal

Muchas máquinas virtuales de Azure contienen otro tipo de disco denominado disco temporal (etiquetado como unidad D:\). La capacidad de este disco variará en función de la serie y tamaño de la máquina virtual. El disco temporal es efímero, lo que significa que el almacenamiento en disco se vuelve a crear (es decir, se desasigna y se asigna de nuevo) cuando la máquina virtual se reinicia o se mueve a otro host (por ejemplo, para realizar la recuperación del servicio).

La unidad de almacenamiento temporal no se conserva en el almacenamiento remoto y, por lo tanto, no debe almacenar los archivos de base de datos de usuario, los archivos de registro de transacciones ni cualquier elemento que deba conservarse. Por ejemplo, puede usarlo para las extensiones del grupo de búferes, el archivo de paginación y tempdb.

Coloque el archivo tempdb en la unidad local de SSD D:\ para las cargas de trabajo de SQL Server a menos que el consumo de la memoria caché local sea un problema. Si usa una máquina virtual que no tiene un disco temporal, se recomienda colocar el archivo tempdb en su propio disco aislado o grupo de almacenamiento con la opción de almacenamiento en caché establecida en solo lectura. Para obtener más información, consulte las directivas de almacenamiento en caché de datos del archivo tempdb.

Discos de datos.

Los discos de datos son discos de almacenamiento remoto que se suelen crear en grupos de almacenamiento con el fin de superar la capacidad y el rendimiento que puede ofrecer cualquier disco individual a la máquina virtual.

Adjunte el número mínimo de discos que satisface los requisitos de IOPS, de rendimiento y de capacidad de la carga de trabajo. No supere el número máximo de discos de datos de la máquina virtual más pequeña a la que va a cambiar el tamaño.

Coloque los archivos de datos y de registro en los discos de datos aprovisionados para satisfacer mejor los requisitos de rendimiento.

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.

Nota:

También es posible hospedar los archivos de base de datos de SQL Server directamente en Azure Blob Storage o en el almacenamiento SMB, como el recurso compartido de archivos prémium de Azure, pero se recomienda usar discos administrados de Azure, ya que proporcionan el máximo rendimiento, confiabilidad y disponibilidad de características.

SSD prémium v2

Debe usar discos SSD Prémium v2 al ejecutar cargas de trabajo SQL Server en regiones admitidas, siempre que las limitaciones actuales sean adecuadas para su entorno. En función de la configuración, los discos SSD prémium v2 pueden ser más barato que los SSD prémium y, además, proporcionan mejoras de rendimiento. Con SSD prémium v2, se pueden ajustar individualmente el rendimiento o el IOPS, sea cual sea el tamaño del disco. La posibilidad de ajustar individualmente las opciones de rendimiento permite no solo este mayor ahorro de costos, sino también generar scripts de cambios para satisfacer los requisitos de rendimiento durante los períodos de necesidad previstos o conocidos.

Si se usa la serie de máquinas virtuales Ebdsv5 o Ebsv5, es aconsejable utilizar SSD Prémium v2, ya que es una solución más rentable para estas máquinas de alto rendimiento de E/S.

Puede implementar las máquinas virtuales de SQL Server con SSD Prémium v2 mediante Azure Portal (actualmente en versión preliminar).

Si va a implementar la máquina virtual de SQL Server mediante Azure Portal y quiere usar SSD Prémium v2, actualmente está limitado a las máquinas virtuales de la serie Ebdsv5 o Ebsv5. Sin embargo, si crea manualmente la máquina virtual con almacenamiento SSD Prémium v2 y, después, instala SQL Server manualmente en la máquina virtual, puede usar cualquier serie de máquinas virtuales que admita SSD Prémium v2. Asegúrese de registrar la máquina virtual de SQL Server con la extensión agente de IaaS de SQL para que pueda aprovechar todas las ventajas proporcionadas por la extensión.

Azure Elastic SAN

Azure Elastic SAN ofrece una solución de almacenamiento en bloques confiable, rentable y escalable de forma masiva que se conecta a una variedad de servicios de computación de Azure a través del protocolo iSCSI. Elastic SAN permite una transición sin problemas de un patrimonio de almacenamiento SAN existente a la nube sin tener que refactorizar la arquitectura de la aplicación del cliente. Esta solución puede lograr una escala masiva: hasta millones de IOPS, GB/s de doble dígito de capacidad de proceso y latencias de milisegundos de un solo dígito con resistencia integrada para minimizar el tiempo de inactividad. Esto hace que sea una excelente opción para los clientes que buscan consolidar el almacenamiento, los clientes que trabajan con varios servicios de computación o aquellos que tienen cargas de trabajo que requieren niveles de alta capacidad de proceso logrados mediante la conducción del almacenamiento a través del bandwidth de red. 

Nota:

  • El dimensionamiento de la máquina virtual con Elastic SAN debe dar cabida a los requisitos de capacidad de proceso de red de producción (VM a VM) junto con el rendimiento de almacenamiento.

Considere la posibilidad de colocar cargas de trabajo de SQL Server en Elastic SAN para mejorar la eficiencia de costes porque:

  • Consolidación del almacenamiento y uso compartido dinámico del rendimiento: Normalmente, para las cargas de trabajo de máquina virtual de SQL Server en Azure, el almacenamiento en disco se aprovisiona por máquina virtual en función de la capacidad del cliente y los requisitos máximos de rendimiento de esa máquina virtual. Este rendimiento sobreaprovisionado está disponible cuando es necesario, pero el rendimiento no se puede compartir con cargas de trabajo en otras máquinas virtuales. Elastic SAN, similar a la SAN en el entorno local, permite consolidar las necesidades de almacenamiento de varias cargas de trabajo SQL y no SQL para lograr una mejor eficiencia de costes, con la capacidad de compartir dinámicamente el rendimiento aprovisionado entre los volúmenes aprovisionados en estas diferentes cargas de trabajo en función de las demandas de E/S. Por ejemplo, en el este de EE. UU., si tiene 10 cargas de trabajo que requieren 2 TiB y 10 000 IOPS cada una, pero colectivamente no necesitan más de 60 000 IOPS en cualquier momento. Puede configurar una SAN elástica con 12 unidades base (1 unidad base = 0,08 USD por GiB/mes) que le proporcionará una capacidad de 12 TiB y las 60 000 IOPS necesarias y 8 unidades de solo capacidad (1 unidad de solo capacidad = 0,06 USD por GiB/mes) que le proporcionarán la capacidad restante de 8 TiB a un precio más barato. Esta configuración de almacenamiento óptima proporciona una mejor rentabilidad al tiempo que proporciona el rendimiento necesario (IOPS de 10 000) a cada una de estas cargas de trabajo. Para obtener más información sobre las unidades de aprovisionamiento de base y solo capacidad de Elastic SAN, visite Planeamiento de Azure Elastic SAN y para obtener precios, visite Azure Elastic SAN - Precios.
  • Para impulsar un mayor rendimientode almacenamiento: Las implementaciones de SQL Server en máquinas virtuales de Azure requieren ocasionalmente sobreaprovisionamiento de una máquina virtual debido a los límites de capacidad de proceso del disco para esa máquina virtual. Puede evitarlo con Elastic SAN, ya que impulsa una mayor capacidad de proceso de almacenamiento a través del bandwidth de red de proceso con el protocolo iSCSI. Por ejemplo, una máquina virtual de Standard_E32bds_v5 (SCSI) está limitada a 88 000 IOPS y 2500 MBps para la capacidad de proceso de disco/almacenamiento, pero puede alcanzar un máximo de 16 000 MBps de rendimiento de red. Si el requisito de capacidad de proceso de almacenamiento para la carga de trabajo es mayor que 2500 MBps, no tendrá que actualizar la máquina virtual una SKU superior, ya que ahora puede admitir hasta 16 000 MBps mediante Elastic SAN.

SSD Premium

Use discos SSD prémium para los archivos de datos y de registro de las cargas de trabajo de SQL Server de producción. El IOPS y el ancho de banda de los discos SSD prémium varían en función del tamaño y el tipo de disco.

En el caso de las cargas de trabajo de producción, use los discos P30 y P40 para los archivos de datos de SQL Server con el fin de garantizar la compatibilidad con el almacenamiento en caché y usar del tipo P30 hasta el P80 para los archivos de registro de transacciones de SQL Server. Para obtener el mejor costo total de propiedad, empiece con los discos P30 (5000 IOPS y 200 MBPS) para los archivos de datos y de registro, y elija capacidades mayores solo cuando necesite controlar el número de discos de máquinas virtuales. En el caso de los sistemas de desarrollo/pruebas o sistemas pequeños, puede optar por usar tamaños menores que P30, ya que admiten el almacenamiento en caché, pero no ofrecen precios reservados.

En el caso de las cargas de trabajo de OLTP, haga coincidir los IOPS de destino por disco (o por grupo de almacenamiento) con los requisitos de rendimiento mediante las cargas de trabajo de las horas punta y los contadores de rendimiento Disk Reads/sec + Disk Writes/sec. En el caso de las cargas de trabajo de informes y almacenamiento de datos, haga coincidir el rendimiento de destino mediante las cargas de trabajo de las horas punta y Disk Read Bytes/sec + Disk Write Bytes/sec.

Use los espacios de almacenamiento para lograr un rendimiento óptimo y configure dos grupos, uno para los archivos de registro y el otro para los archivos de datos. Si no usa el seccionamiento de discos, utilice dos discos SSD prémium asignados a unidades individuales: uno para el archivo de registro y el otro para guardar los datos.

El IOPS y el rendimiento aprovisionados por disco se usan como parte del bloque de almacenamiento. La combinación de las funcionalidades de IOPS y rendimiento de los discos es la capacidad máxima hasta los límites de rendimiento de la máquina virtual.

El procedimiento recomendado es usar el menor número posible de discos y cumplir los requisitos mínimos de IOPS (y rendimiento) y de capacidad. Sin embargo, el equilibrio entre el precio y el rendimiento tiende a ser mejor con un gran número de discos pequeños en lugar de un número pequeño de discos grandes.

Escalado de discos Premium

El tamaño de la SSD prémium determina el nivel de rendimiento inicial del disco. El nivel de rendimiento se puede designar en la implementación o cambiarlo posteriormente, sin tener que cambiar el tamaño del disco. Si la demanda aumenta, puede aumentar el nivel de rendimiento para satisfacer las necesidades de su empresa.

Cambiar el nivel de rendimiento permite a los administradores prepararse y satisfacer una demanda más alta sin tener que depender de la expansión de disco.

Use el alto rendimiento durante el tiempo que sea necesario, donde la facturación está diseñada para satisfacer el nivel de rendimiento del almacenamiento. Actualice el nivel para que coincida con los requisitos de rendimiento sin aumentar la capacidad. Vuelva al nivel original cuando ya no se necesite el rendimiento adicional.

Esta expansión rentable y temporal del rendimiento es un caso de uso sólido para eventos dirigidos como compras, pruebas de rendimiento, eventos de entrenamiento y otras breves ventanas en las que solo se necesita un rendimiento aún mayor para un breve período.

Para obtener más información, consulte los Niveles de rendimiento de los discos administrados.

Disco Ultra de Azure

Si se necesitan tiempos de respuesta inferiores a un milisegundos con una latencia reducida, considere la posibilidad de usar un disco Ultra de Azure para la unidad de registro de SQL Server, o incluso para la unidad de datos para las aplicaciones que son extremadamente sensibles a la latencia de E/S.

Se puede configurar un disco Ultra en el que la capacidad e IOPS se pueden escalar de manera independiente. Con los administradores de discos Ultra puede aprovisionar un disco con los requisitos de capacidad, IOPS y rendimiento en función de las necesidades de la aplicación.

El disco Ultra no es compatible con todas las series de VM y tiene otras limitaciones, como la disponibilidad de regiones, la redundancia y la compatibilidad con Azure Backup. Para obtener más información, consulte Uso de discos Ultra de Azure para obtener una lista completa de limitaciones.

HDD y SSD estándar

Los HDD estándar y las unidades de estado sólido (SSD) presentan el ancho de banda y las latencias variables, de modo que solo se recomiendan para realizar cargas de trabajo de desarrollo o de prueba. En las cargas de trabajo de producción conviene usar discos SSD prémium o SSD prémium v2. Si no usa las unidades SSD estándar (escenarios de desarrollo y pruebas), es aconsejable que agregue el número máximo de discos de datos que admita el tamaño de la máquina virtual y que use el seccionamiento de discos con los espacios de almacenamiento, ya que así mejorará el rendimiento.

Almacenamiento en memoria caché

Las máquinas virtuales que admiten el almacenamiento prémium en la memoria caché pueden aprovechar las ventajas de una característica adicional denominada Azure BlobCache o el almacenamiento en caché de host para ampliar las capacidades de IOPS y el rendimiento de una máquina virtual. Las máquinas virtuales habilitadas tanto para el almacenamiento prémium como el almacenamiento premium en la caché tienen estos dos límites de ancho de banda de almacenamiento que se pueden usar de forma conjunta para mejorar el rendimiento del almacenamiento.

El IOPS y el rendimiento de MBps sin almacenamiento en caché cuenta con los límites de rendimiento de disco no almacenado en caché de una máquina virtual. Los límites máximos de almacenamiento en caché proporcionan otro búfer para las lecturas que ayuda a hacer frente al crecimiento y a los picos inesperados.

Habilite el almacenamiento en caché prémium, siempre que se admita esa opción, para mejorar considerablemente el rendimiento de las lecturas en la unidad de datos sin costo adicional.

Las operaciones de lectura y escritura en Azure BlobCache (IOPS y rendimiento en caché) no se tienen en cuentan en los límites de rendimiento e IOPS que no estén en el almacenamiento en caché de la máquina virtual.

Nota:

No se admite el almacenamiento en caché de disco para discos de 4 TiB o más (P50 y superiores). Si varios discos están conectados a la máquina virtual, cada disco de menos de 4 TiB será compatible con el almacenamiento en caché. Para obtener más información, consulte el Almacenamiento en caché del disco.

Rendimiento no almacenado en caché

El rendimiento y el IOPS de disco máximos sin almacenamiento en caché es el límite máximo de almacenamiento remoto que la máquina virtual puede controlar. Este límite se define en la máquina virtual y no es un límite del almacenamiento en disco subyacente. Este límite se aplica solo a la E/S en las unidades de datos conectadas de forma remota a la VM, no a la E/S local en la unidad temporal (unidad D:\) o la unidad del sistema operativo.

La cantidad de IOPS y el rendimiento sin almacenamiento en caché que están disponibles para una máquina virtual pueden comprobarse en la documentación de la misma.

Por ejemplo, la documentación de la serie M muestra que el rendimiento máximo no almacenado en caché de la VM Standard_M8ms es 5000 IOPS y 125 Mbps de rendimiento de disco sin almacenamiento en caché.

Screenshot showing M-series uncached disk throughput documentation.

Del mismo modo, puede ver que la VM Standard_M32ts admite 20 000 IOPS de disco sin almacenamiento en caché y un rendimiento de disco no almacenado en caché de 500 MBps. Este límite se rige en el nivel de máquina virtual, independientemente del almacenamiento en disco prémium subyacente.

Para obtener más información, consulte los límites almacenados y no almacenados en caché.

Rendimiento de almacenamiento temporal y en caché

El límite de rendimiento máximo de almacenamiento temporal y en caché es independiente del límite de rendimiento sin almacenamiento en caché de la máquina virtual. Azure BlobCache consta de una combinación de la memoria de acceso aleatorio y de la unidad de estado sólido conectada localmente del host de la máquina virtual. La unidad temporal (unidad D:\) dentro de la máquina virtual también se hospeda en esta unidad de estado sólido local.

El límite de rendimiento máximo de almacenamiento temporal y en caché rige la E/S en la unidad temporal local (unidad D:\) y la instancia de Azure BlobCache solo si está habilitado el almacenamiento en caché del host.

Cuando el almacenamiento en caché está habilitado en el almacenamiento prémium, las máquinas virtuales pueden escalar más allá de los límites de rendimiento y IOPS de VM sin almacenamiento en caché de almacenamiento remoto.

No todas las máquinas virtuales admiten tanto el almacenamiento prémium como el almacenamiento prémium en caché (lo que debe verificarse en la documentación de la máquina). Por ejemplo, la documentación de la serie M indica que se admite tanto Premium Storage como el almacenamiento en caché de Premium Storage:

Screenshot showing M-Series Premium Storage support.

Los límites de la memoria caché varían en función del tamaño de la máquina virtual. Por ejemplo, la VM Standard_M8ms admite 10 000 IOPS de disco en caché y un rendimiento de disco en caché de 1000 MBps con un tamaño total de caché de 793 GiB. De forma similar, la VM Standard_M32ts admite 40 000 IOPS de disco en caché y un rendimiento de disco en caché de 400 MBps con un tamaño total de caché de 3174 GiB.

Screenshot showing M-series cached disk throughput documentation.

Puede habilitar manualmente el almacenamiento en caché del host en una VM existente. Detenga todas las cargas de trabajo de la aplicación y los servicios de SQL Server antes de realizar cualquier cambio en la directiva de almacenamiento en caché de la máquina virtual. Si se cambia la configuración de la memoria caché de la máquina virtual, el disco de destino se desasocia y se vuelve a asociar después de aplicar la configuración.

Directivas de almacenamiento en caché de los archivos de datos

La directiva de almacenamiento en caché varía en función del tipo de los archivos de datos de SQL Server que se hospedan en la unidad.

En la tabla siguiente se proporciona un resumen de las directivas de almacenamiento en caché recomendadas según el tipo de datos de SQL Server:

Disco de SQL Server Recomendación
Disco de datos Habilite el almacenamiento en caché Read-only para los discos que hospedan archivos de datos de SQL Server.
Las lecturas de la caché serán más rápidas que las lecturas no almacenadas en caché del disco de datos.
El IOPS y el rendimiento sin almacenamiento en caché, más el rendimiento y el IOPS con almacenamiento en caché, generan el rendimiento total posible disponible desde la máquina virtual dentro de los límites de las máquinas virtuales, pero el rendimiento real varía en función de la capacidad de la carga de trabajo para usar la memoria caché (proporción de aciertos de la caché).
Disco del registro de transacciones Establezca la directiva de almacenamiento en caché en None para los discos que hospedan el registro de transacciones. El rendimiento no mejora por habilitar el almacenamiento en caché para el disco del registro de transacciones y, de hecho, tener el almacenamiento en caché de Read-only o Read/Write habilitado en la unidad de registro puede empeorar el rendimiento de las operaciones de escritura en la unidad y reducir la cantidad de memoria caché disponible para las operaciones de lectura en la unidad de datos.
Disco del SO operativo La directiva de almacenamiento en caché predeterminada es Read/write para la unidad del sistema operativo.
No se recomienda cambiar el nivel de almacenamiento en caché de la unidad del sistema operativo.
tempdb Si tempdb no se puede colocar en la unidad efímera D:\ por motivos de capacidad, cambie el tamaño de la máquina virtual para obtener una unidad efímera mayor o coloque tempdb en una unidad de datos independiente con el almacenamiento en caché de Read-only configurado.
Tanto la memoria caché como la unidad efímera de la máquina virtual utilizan la unidad de estado sólido, así que tenlo en cuenta a la hora de dimensionar, ya que la E/S de tempdb se descontarán de las IOPS en caché y de los límites de rendimiento de la máquina virtual cuando se aloje en la unidad efímera.

Importante

Al cambiar la configuración de caché de un disco de Azure, se desasocia y se vuelve a asociar el disco de destino. Al cambiar la configuración de almacenamiento en caché de un disco que hospeda los datos, registros o archivos de aplicación de SQL Server, asegúrese de detener el servicio SQL Server junto con cualquier otro servicio relacionado para evitar daños en los datos.

Para obtener más información, consulte Almacenamiento en caché de discos.

Seccionamiento del disco

Analice el rendimiento y el ancho de banda necesarios para los archivos de datos de SQL con el fin de determinar el número de discos de datos, incluido el archivo de registro y tempdb. Los límites de rendimiento y ancho de banda varían según el tamaño de la VM. Para obtener más información, consulte el Tamaño de VM.

Para mejorar el rendimiento, agregue más discos de datos y use la segmentación de discos. Por ejemplo, una aplicación que necesita un rendimiento de 12 000 IOPS y 180 MB/s puede usar tres discos P30 segmentados para ofrecer un rendimiento de 15 000 IOPS y 600 MB/s.

Para configurar la segmentación de discos, consulte la segmentación de discos.

Límite del disco

Hay límites de rendimiento tanto en el nivel de disco como en el de máquina virtual. Los límites máximos de IOPS por VM y por disco son diferentes e independientes entre sí.

Las aplicaciones que consumen recursos más allá de estos límites se limitarán. Si selecciona una máquina virtual y un tamaño de disco en una franja de disco que cumpla los requisitos de la aplicación, no tendrá que enfrentarse a ninguna limitación. Para administrar el límite, use el almacenamiento en caché o ajuste la aplicación para que se requiera menos rendimiento.

Por ejemplo, una aplicación que necesita 12 000 IOPS y 180 MB/s puede:

  • Usar el tipo Standard_M32ms que tiene un rendimiento de disco no almacenado en caché máximo de 20 000 IOPS y 500 Mbps.
  • Segmentar tres discos P30 para ofrecer un rendimiento de 15 000 IOPS y 600 MB/s.
  • Use una máquina virtual Standard_M16ms y el almacenamiento en caché de host para utilizar la caché local, en lugar de consumir rendimiento.

Las máquinas virtuales configuradas para realizar escalados verticales en momentos de alta utilización deben aprovisionar almacenamiento con suficientes IOPS y rendimiento para soportar el tamaño máximo de la máquina virtual, manteniendo un número total de discos inferior o igual al número máximo admitido por la SKU de máquina virtual más pequeña que se pretende utilizar.

Para obtener más información sobre las limitaciones del disco y el uso del almacenamiento en caché para evitar el límite, consulte Limitación de E/S del disco.

Nota:

Algunos límites de disco pueden dar lugar a un rendimiento satisfactorio para los usuarios; ajuste y mantenga las cargas de trabajo en lugar de cambiar su tamaño a una VM más grande para equilibrar la administración del costo y el rendimiento de la empresa.

Aceleración de escritura

La aceleración de escritura es una característica de disco que solo está disponible para las máquinas virtuales de la serie M. El propósito de la Aceleración de escritura es mejorar la latencia de E/S de las operaciones de escritura en Azure Premium Storage cuando se necesita una latencia de E/S de un solo dígito, debido a las grandes cargas de trabajo de OLTP o a los entornos de almacenamiento de datos.

Use la Aceleración de escritura para mejorar la latencia de las operaciones de escritura en la unidad que hospeda los archivos de registro. No use la Aceleración de escritura para archivos de datos de SQL Server.

Los discos del Acelerador de escritura comparten el mismo límite de IOPS que la máquina virtual. En una VM, los discos conectados no pueden superar el límite de IOPS del Acelerador de escritura.

En la tabla siguiente se describe el número de discos de datos e IOPS que se admiten por máquina virtual:

SKU de la máquina virtual Número de discos del Acelerador de escritura IOPS de discos del Acelerador de escritura por VM
M416ms_v2, M416s_v2 16 20000
M128ms, M128s 16 20000
M208ms_v2, M208s_v2 8 10000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5000
M16ms, M16s 2 2.500
M8ms, M8s 1 1250

Hay varias restricciones a la hora de usar la Aceleración de escritura. Para obtener más información, consulte Restricciones al usar el Acelerador de escritura.

Comparación con el disco Ultra de Azure

La mayor diferencia entre la aceleración de escritura y los discos Ultra de Azure es que la primera es una característica de máquina virtual que solo está disponible para la serie M, mientras que la segunda es una opción de almacenamiento. La aceleración de escritura es una caché optimizada para la escritura que cuenta sus propias limitaciones en función del tamaño de la máquina virtual. En cambio, los discos Ultra de Azure son una opción de almacenamiento en disco de latencia baja para máquinas virtuales de Azure.

Si es posible, use la Aceleración de escritura en lugar de los discos Ultra para el disco del registro de transacciones. En el caso de las máquinas virtuales que no admitan la aceleración de escritura, pero que requieran una latencia baja en el registro de transacciones, use los discos Ultra de Azure.

Supervisión del rendimiento del almacenamiento

Para evaluar las necesidades de almacenamiento y determinar cómo funciona el mismo, debe comprender qué se debe medir y qué significan esos indicadores.

IOPS (Entrada/Salida por segundo) es el número de solicitudes que la aplicación realiza en el almacenamiento por segundo. Mida el número IOPS mediante los contadores Disk Reads/sec y Disk Writes/sec del Monitor de rendimiento. Las aplicaciones OLTP (Procesamiento de transacciones en línea) necesitan impulsar más IOPS para lograr un rendimiento óptimo. Asimismo, las aplicaciones como los sistemas de procesamiento de pagos, la compra en línea y los sistemas de punto de venta minorista son ejemplos de aplicaciones OLTP.

El Rendimiento es el volumen de datos que se envía al almacenamiento subyacente, y a menudo se mide en megabytes por segundo. Mida el rendimiento con los contadores Disk Read Bytes/sec y Disk Write Bytes/sec del Monitor de rendimiento. El Almacenamiento de datos está optimizado para maximizar el rendimiento a través de IOPS. Las aplicaciones como los almacenes de datos para el análisis, los informes, las secuencias de trabajo ETL y otros destinos de inteligencia empresarial son ejemplos de aplicaciones de almacenamiento de datos.

Los tamaños de unidad de E/S influyen en el IOPS y en las capacidades de rendimiento, ya que los tamaños de E/S más pequeños producen una mayor velocidad de E/S y un mayor rendimiento. SQL Server elige automáticamente el tamaño de E/S óptimo. Para obtener más información acerca de esto, consulte Optimización de IOPS, el rendimiento y la latencia de las aplicaciones.

Existen métricas de Azure Monitor específicas que son útiles para detectar el límite en el nivel de la máquina virtual y el disco, así como el consumo y el estado de la caché de AzureBlob. Para identificar los contadores clave que se van a agregar a la solución de supervisión y al panel de Azure Portal, consulte Métricas de uso de almacenamiento.

Nota:

Actualmente, Azure Monitor no ofrece métricas de nivel de disco para la unidad temporal efímera (D:\). El porcentaje de uso de IOPS en caché de la VM y el porcentaje de ancho de banda de VM consumido reflejarán los IOPS y el rendimiento de la unidad temporal efímera (D:\) y del almacenamiento en caché de host.

Pasos siguientes

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