Partager via

Stockage : Meilleures pratiques sur les performances de SQL Server sur les machines virtuelles Azure

  • Article

S’applique à : SQL Server sur la machine virtuelle Azure

Cet article fournit les bonnes pratiques et des recommandations relatives au stockage qui vous permettront d’optimiser les performances de votre instance SQL Server sur des machines virtuelles Azure (VM).

Il existe généralement un compromis entre l’optimisation des coûts et l’optimisation des performances. Cette série de bonnes pratiques pour les performances vise à vous aider à obtenir les meilleures performances possibles pour SQL Server sur les machines virtuelles Azure. Si votre charge de travail est moindre, vous n’aurez peut-être pas besoin de toutes les optimisations recommandées. Tenez compte de vos besoins de performances, des coûts et des modèles de charges de travail lors de l’évaluation de ces recommandations.

Pour plus d’informations, consultez les autres articles de cette série : Liste de contrôle, Taille de machine virtuelle, Sécurité, Configuration HADR et Collecter une ligne de base.

Check-list

Consultez la liste de contrôle suivante pour obtenir une vue d’ensemble des meilleures pratiques de stockage présentées plus en détail dans le reste de l’article :

  • Supervisez l’application et déterminez les besoins du stockage en bande passante et en latence pour les fichiers de données, fichiers journaux et fichiers tempdb de SQL Server avant de choisir le type de disque.
  • Si disponible, configurez les tempdb données et les fichiers journaux sur le volume D: SSD local. L’extension SQL IaaS Agent gère le dossier et les autorisations nécessaires lors du réapprovisionnement.
  • Pour optimiser les performances de stockage, planifiez les IOPS non mises en cache les plus élevées disponibles et utilisez la mise en cache des données en tant que fonctionnalité de performances pour les lectures de données tout en évitant l'encapsulation des machines virtuelles et des disques.
  • Lorsque vous utilisez les machines virtuelles SQL Server de la série Ebdsv5 ou Ebsv5 , utilisez ssd Premium v2 pour obtenir les meilleures performances de prix. Vous pouvez déployer votre machine virtuelle SQL Server avec SSD Premium v2 à l’aide du Portail Azure (actuellement en préversion).
  • Placez les fichiers de données, les fichiers journaux et les tempdb fichiers sur des lecteurs distincts.
    • Pour le lecteur de données, utilisez des disques Premium P30 et P40 ou des disques plus petits afin de garantir la disponibilité de la prise en charge du cache. Si vous utilisez la série de machines virtuelles Ebdsv5, optez pour des disques SSD Premium v2 qui sont moins coûteux pour les charges de travail qui nécessitent des IOPS et un débit d’E/S élevés.
    • Pour le lecteur de journaux, prévoyez une capacité suffisante et testez les performances par rapport au coût quand vous faites l’évaluation des disques SSD Premium v2 ou des disques P30 - P80.
    • Placez tempdb sur le disque temporaire (le disque temporaire est éphémère et est configuré par défaut sur D:\) pour la plupart des charges de travail SQL Server qui ne font pas partie de l’instance de cluster de basculement (FCI) après avoir choisi la taille de machine virtuelle optimale.
    • Pour les instances de cluster de basculement (FCI) placent tempdb sur le stockage partagé.
      • Si la charge de travail FCI dépend largement des performances de disque tempdb, en tant que configuration avancée, placez tempdb sur le lecteur SSD éphémère local (D:\ par défaut) qui ne fait pas partie du stockage FCI. Cette configuration nécessite une supervision et une action personnalisées pour garantir que le lecteur SSD éphémère local (D:\ par défaut) est disponible à tout moment, car les échecs de ce lecteur ne vont pas déclencher d’action de FCI.
  • Entrelacez plusieurs disques de données Azure à l’aide d'espaces de stockage pour augmenter la bande passante d’E/S jusqu’aux limites de débit et d’IOPS de la machine virtuelle cible.
  • Réglez host caching (mise en cache de l’hôte) sur read-only (en lecture seule) pour les disques de fichiers de données.
  • Réglez host caching (mise en cache de l’hôte) sur none (aucune) pour les disques de fichiers journaux.
    • N’activez pas la mise en cache en lecture/écriture sur les disques qui contiennent des données ou des fichiers journaux SQL Server.
    • Arrêtez toujours le service SQL Server avant de modifier les paramètres de cache de votre disque.
  • Lors de la migration de plusieurs charges de travail différentes vers le cloud, Azure Elastic SAN peut être une solution de stockage consolidée rentable. Toutefois, lors de l’utilisation d’Azure Elastic SAN, l’obtention d’IOPS/débit souhaités pour les charges de travail SQL Server nécessite souvent une capacité de surapprovisionnement. Bien qu’il ne soit généralement pas approprié pour les charges de travail SQL Server uniques, vous pouvez obtenir une solution rentable lors de la combinaison de charges de travail à faible performance avec SQL Server.
  • Pour les charges de travail de développement et de test, et l’archivage de sauvegarde à long terme, pensez à utiliser le stockage standard. Il est déconseillé d’utiliser des disques SDD/HDD Standard pour les charges de travail de production.
  • Le bursting de disque basé sur les crédits (P1-P20) ne doit être pris en compte que pour les charges de travail de dev/test et les systèmes départementaux plus petits.
  • Pour optimiser les performances du stockage, prévoyez les IOPS non mises en cache les plus élevées disponibles, et utilisez la mise en cache des données comme fonctionnalité de performance pour les lectures de données, tout en évitant les plafonnements/limitations applicables à la machine virtuelle et aux disques.
  • Formatez votre disque de données afin d’utiliser une taille d’unité d’allocation de 64 ko pour tous les fichiers de données placés sur un lecteur autre que le lecteur D:\ temporaire (dont la valeur par défaut est de 4 ko). Les machines virtuelles SQL Server déployées via la Place de marché Azure sont fournies avec des disques de données formatés avec une taille d’unité d’allocation et un entrelacement pour le pool de stockage défini sur 64 Ko.
  • Configurez le compte de stockage dans la même région que la machine virtuelle SQL Server.
  • Désactivez le stockage géoredondant Azure (géoréplication) et utilisez LRS (stockage local redondant) sur le compte de stockage.
  • Activez l’évaluation des bonnes pratiques SQL pour identifier les problèmes de performances possibles et évaluer si votre machine virtuelle SQL Server est configurée pour suivre les bonnes pratiques.
  • Passez en revue et supervisez les limites de disque et de machine virtuelle en utilisant des métriques d’utilisation des E/S de stockage.
  • Excluez les fichiers SQL Server de l’analyse logicielle antivirus, y compris les fichiers de données, les fichiers journaux et les fichiers de sauvegarde.

Pour comparer la liste de contrôle du stockage avec les autres bonnes pratiques, consultez la Liste complète de contrôle des bonnes pratiques relatives aux performances.

Vue d’ensemble

Pour trouver la configuration la plus efficace pour les charges de travail SQL Server sur une machine virtuelle Azure, commencez par mesurer les performances de stockage de votre application métier. Une fois les exigences de stockage connues, sélectionnez une machine virtuelle qui prend en charge les IOPS et le débit nécessaires avec le ratio mémoire-vCore approprié.

Choisissez une taille de machine virtuelle avec suffisamment d’extensibilité de stockage pour votre charge de travail et un mélange de disques (généralement dans un pool de stockage) qui répondent aux besoins de votre entreprise en matière de capacité et de performances.

Le type de disque dépend à la fois du type de fichier hébergé sur le disque et de vos exigences de performances maximales.

Conseil

Le provisionnement d’une machine virtuelle SQL Server via le Portail Azure vous guide tout au long du processus de configuration du stockage et implémente la plupart des bonnes pratiques de stockage, telles que la création de pools de stockage distincts pour vos fichiers de données et de journaux, le ciblage de tempdb sur le lecteur D:\, et l’activation de la stratégie de mise en cache optimale. Pour plus d’informations sur l’approvisionnement et la configuration du stockage, consultez Configuration du stockage de machines virtuelles SQL.

Type de disque de machine virtuelle

Vous avez le choix entre plusieurs niveaux de performances pour vos disques. Les types de disques managés disponibles comme stockage sous-jacent (listés par capacités d’optimisation des performances) sont les lecteurs de disque dur Standard (HDD), les disques SSD Standard, les disques SSD Premium, les disques SSD Premium v2 et les disques Ultra.

Pour les disques HDD Standard, SSD Standard et SSD Premium, les performances du disque augmentent avec la taille du disque ; leur regroupement s’effectue par étiquettes de disque Premium, par exemple du P1 avec 4 Gio d’espace et 120 IOPS au P80 avec 32 Tio de stockage et 20 000 IOPS. Le stockage Premium prend en charge un cache de stockage qui permet d’améliorer les performances de lecture et d’écriture pour certaines charges de travail. Pour plus d’informations, consultez Vue d’ensemble de la fonctionnalité Disques managés.

Les performances des disques SSD Premium v2 et Ultra peuvent changer indépendamment de la taille du disque. Pour plus d’informations, consultez Performances des disques Ultra et Performances des disques SSD Premium v2.

Il y a également trois principaux rôles de disque à prendre en compte pour votre SQL Server sur une machine virtuelle Azure : un disque de système d’exploitation, un disque temporaire et vos disques de données. Choisissez soigneusement ce qui est stocké sur le lecteur du système d’exploitation (C:\) et le lecteur temporaire éphémère (D:\).

Disque de système d’exploitation

Un disque de système d’exploitation est un disque dur virtuel (VHD) qui peut être amorcé et monté comme version d’exécution d’un système d’exploitation. Il est désigné par la lettre de lecteur C:\. Quand vous créez une machine virtuelle Azure, la plateforme attache au moins un disque à la machine virtuelle pour le disque de système d’exploitation. Le lecteur C:\ est l’emplacement par défaut pour les installations d’applications et la configuration de fichiers.

Pour les environnements SQL Server de production, n’utilisez pas le disque de système d’exploitation pour les fichiers de données, les fichiers journaux et les journaux d’erreurs.

Disque temporaire

Beaucoup de machines virtuelles Azure contiennent un autre type de disque appelé disque temporaire (portant le nom de lecteur D:\). Selon la série et la taille de la machine virtuelle, la capacité de ce disque varie. Le disque temporaire est éphémère : le stockage sur disque est recréé (il est libéré et réalloué) lorsque la machine virtuelle est redémarrée ou bien déplacée vers un autre hôte (par exemple, pour la réparation de service).

Le lecteur de stockage temporaire n’est pas conservé dans le stockage distant et ne doit donc pas stocker les fichiers de base de données utilisateur, les fichiers journaux des transactions ou ce qui doit être conservé. Par exemple, vous pouvez l’utiliser pour les extensions du pool de mémoires tampons, le fichier de page et tempdb.

Placez tempdb sur le lecteur SSD temporaire local D:\ pour les charges de travail SQL Server, sauf si la consommation du cache local est un problème. Si vous utilisez une machine virtuelle qui n’a pas de disque temporaire, il est recommandé de placer la base de données tempdb sur son propre disque ou pool de stockage isolé dont la mise en cache est définie sur lecture seule. Pour plus d’informations, consultez les stratégies de mise en cache des données tempdb.

Disques de données

Les disques de données sont des disques de stockage à distance qui sont souvent créés dans des pools de stockage, lesquels offrent une capacité et des performances supérieures à ce que peut fournir un disque unique à la machine virtuelle.

Attachez le nombre minimal de disques qui satisfait aux besoins en IOPS, en débit et en capacité de votre charge de travail. Ne dépassez pas le nombre maximal de disques de données de la plus petite machine virtuelle vers laquelle vous prévoyez d’effectuer le redimensionnement.

Placez les fichiers de données et les fichiers journaux sur les disques de données approvisionnés en fonction de vos exigences de performances.

Formatez votre disque de données afin d’utiliser une taille d’unité d’allocation de 64 ko pour tous les fichiers de données placés sur un lecteur autre que le lecteur D:\ temporaire (dont la valeur par défaut est de 4 ko). Les machines virtuelles SQL Server déployées via la Place de marché Azure sont fournies avec des disques de données formatés avec une taille d’unité d’allocation et un entrelacement pour le pool de stockage défini sur 64 Ko.

Notes

Il est également possible d’héberger vos fichiers de base de données SQL Server directement dans le stockage d’objets Blob Azure ou un stockage SMB, par exemple le partage de fichiers Premium Azure. Nous vous recommandons toutefois d’utiliser des disques managés Azure pour optimiser les performances, la fiabilité et la disponibilité des fonctionnalités.

SSD Premium v2

Utilisez des disques SSD Premium v2 quand vous exécutez des charges de travail SQL Server dans des régions prises en charge, si les limitations actuelles sont adaptées pour votre environnement. Selon votre configuration, les disques SSD Premium v2 peuvent avoir un coût inférieur aux disques SSD Premium, tout en offrant de meilleures performances. Avec SSD Premium v2, vous pouvez ajuster individuellement le débit ou les IOPS indépendamment de la taille de votre disque. La possibilité d’ajuster individuellement les options de performances vous permet de réaliser des économies plus importantes, et de scripter des modifications pour répondre aux exigences de performances pendant les périodes de demande prévues ou connues.

Nous vous recommandons d’utiliser SSD Premium v2 avec Ebdsv5 ou la série de machines virtuelles Ebdsv5, car c’est une solution plus économique pour ces machines à débit d’E/S élevé.

Vous pouvez déployer vos machines virtuelles SQL Server avec SSD Premium v2 en utilisant le portail Azure (actuellement en aperçu).

Si vous déployez votre machine virtuelle SQL Server en utilisant le portail Azure et que vous voulez utiliser SSD Premium v2, vous êtes actuellement limité aux machines virtuelles des séries Ebdsv5 ou Ebsv5. Toutefois, si vous créez manuellement votre machine virtuelle avec un stockage SSD Premium v2, puis installez manuellement SQL Server sur la machine virtuelle, vous pouvez utiliser n’importe quelle série de machines virtuelles qui prend en charge ssd Premium v2. Veillez à inscrire votre machine virtuelle SQL Server auprès de l’extension SQL IaaS Agent pour tirer parti de tous les avantages fournis par l’extension.

Azure Elastic SAN

Azure Elastic SAN est une offre de périphérique de stockage NAS qui fournit aux clients une solution flexible et évolutive avec la possibilité de réduire les coûts grâce à la consolidation du stockage. Azure Elastic SAN offre une solution de stockage de blocs rentable, performante et fiable qui se connecte à un large éventail de services de calcul Azure via le protocole iSCSI. Elastic SAN permet une transition transparente d’un patrimoine de stockage SAN existant vers le cloud sans avoir à refactoriser l’architecture de l’application cliente.

Cette solution peut effectuer une mise à l’échelle massive jusqu’à des millions d’IOPS, go/s à deux chiffres de débit et des latences en millisecondes à un chiffre faible avec résilience intégrée pour réduire les temps d’arrêt. Utilisez azure Elastic SAN si vous avez besoin de consolider le stockage, de travailler avec plusieurs services de calcul ou de disposer de charges de travail nécessitant des niveaux de débit élevés lors de la conduite du stockage sur la bande passante réseau. Toutefois, étant donné que l’obtention d’IOPS/débit souhaités pour les charges de travail SQL Server nécessite souvent une capacité de surapprovisionnement, elle n’est généralement pas appropriée pour les charges de travail SQL Server uniques. La combinaison d’autres charges de travail à faible performances avec SQL Server peut être nécessaire pour atteindre la solution la plus rentable.

Lorsque vous envisagez le dimensionnement et les performances des machines virtuelles pour Azure Elastic SAN, il est important de comprendre que la communication de stockage se produit sur le réseau. Par exemple, la taille de machine virtuelle E4d_v5 ne prend pas en charge Azure Stockage Premium, mais fonctionne correctement avec Azure Elastic SAN, car elle prend en charge jusqu’à 12 500 Mbits/s de débit réseau. Lorsque vous utilisez Azure Elastic SAN avec cette taille de machine virtuelle, vous devez vous assurer que les exigences de débit réseau et de stockage de votre charge de travail sont inférieures à la limite de débit réseau de 12 500 Mbits/s.

Déterminez vos besoins en matière de réseau et de stockage avant de déployer votre machine virtuelle SQL Server avec un Azure Elastic SAN, puis surveillez soigneusement l’utilisation du réseau et du stockage pour confirmer que la machine virtuelle choisie peut prendre en charge la charge de travail. Pour en savoir plus, passez en revue les performances des machines virtuelles avec des volumes SAN élastiques et des métriques ELASTIC SAN.

Attention

  • Le dimensionnement des machines virtuelles avec Elastic SAN doit prendre en charge les exigences de débit réseau de production (machine virtuelle à machine virtuelle) en plus du débit de stockage. Lorsque vous utilisez Elastic SAN, les tailles de machine virtuelle qui optimisent le débit d’E/S peuvent ne pas être aussi rentables que les tailles de machine virtuelle qui optimisent la bande passante réseau.

Envisagez de placer des charges de travail SQL Server sur un Elastic SAN pour augmenter la rentabilité, car :

  • Consolidation du stockage et partage de la performance dynamique : normalement pour SQL Server sur les charges de travail de machine virtuelle Azure, le stockage sur disque est approvisionné sur une base de machine virtuelle en fonction de votre capacité et des exigences de performances maximales pour cette machine virtuelle. Ces performances surapprovisionnées sont disponibles si nécessaire, mais les performances inutilisées ne peuvent pas être partagées avec des charges de travail sur d’autres machines virtuelles. Elastic SAN, similaire au SAN localement, permet de consolider les besoins de stockage de plusieurs charges de travail SQL et non SQL afin d’augmenter la rentabilité, avec la possibilité de partager dynamiquement les performances approvisionnées entre les volumes approvisionnés sur ces différentes charges de travail en fonction des demandes d’E/S. Par exemple, dans la région USA Est, vous avez 10 charges de travail qui nécessitent une capacité de 2 Tio et des IOPS de 10 000 chacune, alors qu’ensemble, elles n’ont jamais besoin de plus de 60 000 IOPS. Vous pouvez configurer un Elastic SAN avec 12 unités de base (1 unité de base = 0,08 USD par Gio/mois) qui vous donnera une capacité de 12 Tio et les 60 000 unités d’IOPS nécessaires et 8 unités de capacité uniquement (1 unité de capacité uniquement = 0,06 USD par Gio/mois) qui vous donnera la capacité restante de 8 Tio à un prix moins cher. Cette configuration de stockage optimale offre une meilleure rentabilité tout en fournissant les performances nécessaires (10 000 unités d’IOPS) à chacune de ces charges de travail. Pour plus d’informations sur les unités de provisionnement de base et de capacité seule Elastic SAN, consultez Planification d’une instance Azure Elastic SAN. Pour les tarifs, consultez Tarification Azure Elastic SAN.
  • Pour générer un débit de stockage plus élevé : SQL Server sur les déploiements de machines virtuelles Azure nécessite parfois le surapprovisionnement d’une machine virtuelle en raison de limites de débit de disque pour cette machine virtuelle. Vous pouvez éviter cela avec Elastic SAN, car vous provoquerez un débit de stockage plus élevé sur la bande passante du réseau de calcul avec le protocole iSCSI. Par exemple, une machine virtuelle Standard_E32bds_v5 est limitée à 51 200 IOPS et 865 Mbits/s pour le débit de disque/stockage, mais elle peut atteindre jusqu’à 2 000 Mbits/s de débit réseau. Si le débit de stockage requis pour votre charge de travail est supérieur à 865 Mbits/s, vous n’aurez pas à mettre à niveau la machine virtuelle avec une référence SKU supérieure, car elle peut désormais prendre en charge jusqu’à 2 000 Mbits/s à l’aide de l’Elastic SAN.

SSD Premium

Utilisez des disques SSD Premium pour le stockage des fichiers de données et des fichiers journaux pour les charges de travail de production SQL Server. Les IOPS et la bande passante sur SSD Premium varient selon la taille et le type de disque.

Pour les charges de travail de production, utilisez les disques P30 et/ou P40 pour les fichiers de données SQL Server pour garantir la prise en charge de la mise en cache et utilisez le P30 jusqu’à P80 pour les fichiers journaux des transactions SQL Server. Pour avoir un coût total de possession le plus bas possible, commencez par utiliser des disques P30 (5 000 IOPS/200 Mbits/s) pour les fichiers de données et les fichiers journaux, et choisissez des capacités supérieures uniquement lorsque vous devez contrôler le nombre de disques de la machine virtuelle. Pour les systèmes dev/test ou de petite taille, vous pouvez choisir d’utiliser des tailles inférieures à P30, car elles prennent en charge la mise en cache, mais elles n’offrent pas de tarification réservée.

Pour les charges de travail OLTP, faites correspondre les IOPS cibles par disque (ou pool de stockage) à vos besoins de performances à l’aide des charges de travail aux heures de pointe et des compteurs de performances Disk Reads/sec + Disk Writes/sec. Pour les charges de travail d’entrepôt de données et de création de rapports, faites correspondre le débit cible à l’aide des charges de travail aux heures de pointe et Disk Read Bytes/sec + Disk Write Bytes/sec.

Utilisez les espaces de stockage pour atteindre des performances optimales, configurer deux pools, une pour le ou les fichiers journaux et l’autre pour les fichiers de données. Si vous n’utilisez pas l’entrelacement de disques, utilisez deux disques SSD Premium mappés sur des lecteurs distincts, un pour le fichier journal et l’autre pour les données.

Les IOPS approvisionnées et le débit par disque qui sont utilisés dans le cadre de votre pool de stockage. La combinaison des capacités d’IOPS et de débit des disques correspond à la capacité maximale dans les limites de débit de la machine virtuelle.

La meilleure pratique consiste à utiliser le moins de disques possibles tout en répondant aux conditions minimales requises pour les IOPS (et le débit) et la capacité. Toutefois, l’équilibre entre prix et performances a tendance à être mieux adapté à un grand nombre de petits disques plutôt qu’à un petit nombre de disques de grande taille.

Mettre à l’échelle les disques Premium

La taille de votre disque SSD Premium détermine le niveau de performances initial du disque. Désignez le niveau de performance au moment du déploiement ou modifiez-le ultérieurement, sans changer de taille du disque. Si la demande augmente, vous pouvez augmenter le niveau de performance pour répondre aux besoins de votre entreprise.

La modification du niveau de performance permet aux administrateurs de préparer le disque et de répondre à une demande plus importante sans dépendre du bursting de disque.

Utilisez les performances supérieures aussi longtemps que nécessaire, pour lesquelles la facturation est conçue pour atteindre le niveau de performance de stockage. Mettez à niveau le niveau pour qu’il corresponde aux exigences en matière de performances sans augmenter la capacité. Revenez au niveau d’origine lorsque les performances supplémentaires ne sont plus nécessaires.

Cette expansion économique et temporaire des performances est un cas d’utilisation fort pour les événements ciblés, tels que les achats, les tests de performances, les événements de formation et d’autres fenêtres courtes, où des performances supérieures sont nécessaires uniquement pour une courte période.

Pour plus d’informations, consultez Niveaux de performances pour les disques managés.

Disque Ultra Azure

Si vous avez besoin de temps de réponse inférieurs à la milliseconde et d’une latence réduite, envisagez d’utiliser un disque Azure Ultra pour le lecteur de journaux SQL Server, ou même le lecteur de données pour les applications extrêmement sensibles à la latence des E/S.

Le disque Ultra peut être configuré lorsque la capacité et les IOPS peuvent se mettre à l’échelle de façon indépendante. Avec le disque Ultra, les administrateurs peuvent approvisionner un disque avec les exigences de capacité, d’IOPS et de débit en fonction des besoins de l’application.

Le disque Ultra n’est pas pris en charge sur toutes les séries de machines virtuelles, et a d’autres limitations, comme la disponibilité des régions, la redondance et la prise en charge de Sauvegarde Azure. Pour plus d’informations, consultez Utilisation de disques Ultra Azure pour obtenir une liste complète des limitations.

Disques HDD standard et SSD

Les disques HDD standard et les disques SSD possèdent différents temps de latence et une bande passante variable. Ils sont recommandés uniquement pour les charges de travail de dev/test. Les charges de travail en production doivent utiliser des disques SSD Premium v2 ou SSD Premium. Si vous utilisez un disque SSD Standard (scénarios dev/test), il est recommandé d’ajouter le nombre maximal de disques de données pris en charge par la taille de votre machine virtuelle et d’utiliser l’entrelacement de disques avec les espaces de stockage pour obtenir des performances optimales.

Mise en cache

Les machines virtuelles qui prennent en charge la mise en cache du stockage Premium peuvent bénéficier d’une fonctionnalité supplémentaire appelée Azure BlobCache ou la mise en cache de l’hôte pour étendre les capacités d’IOPS et de débit d’une machine virtuelle. Les machines virtuelles activées pour le stockage Premium et la mise en cache du stockage Premium ont deux limites de bande passante de stockage différentes qui peuvent être combinées pour améliorer les performances de stockage.

Les IOPS et le débit Mbits/s sans mise en cache sont comptabilisés dans les limites de débit de disque non mis en cache d’une machine virtuelle. Les limites maximales mises en cache fournissent une autre mémoire tampon pour les lectures, ce qui permet de mieux gérer la croissance et les pics de demande inattendus.

Activez la mise en cache Premium quand cette option est prise en charge pour améliorer de manière significative les performances des lectures sur le lecteur de données, sans aucun coût supplémentaire.

Les lectures et les écritures dans le BlobCache Azure (IOPS et débit mis en cache) ne sont pas comptabilisées dans les limites d’IOPS et de débit sans mise en cache de la machine virtuelle.

Notes

La mise en cache du disque n’est pas prise en charge pour les disques de 4 Tio et supérieurs (P50 et supérieur). Si plusieurs disques sont attachés à votre machine virtuelle, chaque disque d’une taille inférieure à 4 Tio prend en charge la mise en cache. Pour plus d'informations, consultez Mise en cache du disque.

Débit non mis en cache

Les IOPS et le débit de disque maximum sans mise en cache sont la limite maximale de stockage à distance que la machine virtuelle est en mesure de gérer. Cette limite est définie sur la machine virtuelle et n’est pas une limite du stockage sur disque sous-jacent. Cette limite s’applique uniquement à l’E/S sur les lecteurs de données attachés à distance à la machine virtuelle, et non à l’E/S locale sur le lecteur temporaire (lecteur D:\) ou le lecteur de système d’exploitation.

La quantité d’IOPS et de débit non mis en cache qui est disponible pour une machine virtuelle peut être vérifiée dans la documentation de votre machine virtuelle.

Par exemple, la documentation de la série M indique que le débit maximal non mis en cache pour la machine virtuelle Standard_M8ms est de 5 000 IOPS et de 125 Mbits/s de débit de disque non mis en cache.

Capture d’écran montrant la documentation sur le débit de disque non mis en cache de la série M.

De même, vous pouvez voir que la machine virtuelle Standard_M32ts prend en charge 20 000 IOPS de disque sans mise en cache et un débit de disque de 500 Mbits/s sans mise en cache. Cette limite est déterminée par le niveau de la machine virtuelle, indépendamment du stockage sur disque Premium sous-jacent.

Pour plus d’informations, consultez les limitations avec et sans mise en cache.

Débit de stockage temporaire et mis en cache max

La limite du débit maximal de stockage mis en cache et temporaire est une limite distincte de la limite du débit non mis en cache sur la machine virtuelle. Le BlobCache Azure est une combinaison de la mémoire d’accès aléatoire de l’hôte de machine virtuelle et du disque SSD attaché localement. Le lecteur temporaire (lecteur D:\) de la machine virtuelle est également hébergé sur ce disque SSD local.

La limite du débit maximal de stockage mis en cache et temporaire régit les E/S sur le lecteur local temporaire (lecteur D:\) et Azure BlobCache uniquement si la mise en cache de l’hôte est activée.

Lorsque la mise en cache est activée sur le stockage Premium, les machines virtuelles peuvent être dimensionnées au-delà des limites d’IOPS et de débit des machines virtuelles sans mise en cache du stockage à distance.

Seules certaines machines virtuelles prennent en charge à la fois le stockage Premium et la mise en cache du stockage Premium (ceci est à vérifier dans la documentation de la machine virtuelle). Par exemple, la documentation de la série M indique que le stockage Premium et la mise en cache du stockage Premium sont pris en charge :

Capture d’écran montrant la prise en charge du stockage Premium de la série M.

Les limites du cache varient selon la taille de machine virtuelle. Par exemple, la machine virtuelle Standard_M8ms prend en charge 10 000 IOPS disque avec mise en cache et 1 000 Mbits/s de débit disque avec mise en cache, avec une taille de cache totale de 793 Gio. De même, la machine virtuelle Standard_M32ts prend en charge 40000 IOPS disque avec mise en cache et 400 Mbits/s de débit disque avec mise en cache, avec une taille de cache totale de 3 174 Gio.

Capture d’écran montrant la documentation sur le débit de disque mis en cache de la série M.

Vous pouvez activer manuellement la mise en cache de l’hôte sur une machine virtuelle existante. Arrêtez toutes les charges de travail d’application et les services SQL Server avant d’apporter des modifications à la stratégie de mise en cache de votre machine virtuelle. La modification des paramètres du cache de la machine virtuelle entraîne le détachement et le nouveau rattachement du disque cible après l’application des paramètres.

Stratégies de mise en cache des fichiers de données

Votre stratégie de mise en cache de stockage varie selon le type de fichiers de données SQL Server hébergés sur le lecteur.

Le tableau suivant fournit un résumé des stratégies de mise en cache recommandées en fonction du type de données SQL Server :

Disque SQL Server Recommandation
Disque de données Activez la mise en cache Read-only pour les disques qui hébergent des fichiers de données SQL Server.
Les lectures à partir du cache sont plus rapides que les lectures non mises en cache du disque de données.
Les IOPS et le débit non mis en cache, plus les IOPS et le débit mis en cache, donnent les performances totales disponibles sur la machine virtuelle dans les limites des machines virtuelles, mais les performances réelles varient en fonction de la capacité de la charge de travail à utiliser le cache (taux d’accès au cache).
Disque du journal des transactions Définissez la stratégie de mise en cache sur None pour les disques qui hébergent le journal des transactions. Il n’y a aucun avantage en matière de performances à activer la mise en cache pour le disque du journal des transactions. En effet, quand la mise en cache Read-only ou Read/Write est activée sur le lecteur de journaux, cela peut diminuer les performances des écritures sur le lecteur et réduire la quantité de cache disponible pour les lectures sur le lecteur de données.
Disque du système d’exploitation La stratégie de mise en cache par défaut est Read/write pour le lecteur du système d’exploitation.
Il n’est pas recommandé de modifier le niveau de mise en cache du lecteur de système d’exploitation.
tempdb Si tempdb ne peut pas être placée sur le lecteur éphémère D:\ pour des raisons de capacité, vous pouvez soit redimensionner la machine virtuelle pour obtenir un lecteur éphémère plus grand, soit placer tempdb sur un lecteur de données distinct avec la mise en cache Read-only configurée.
Le cache de la machine virtuelle et le lecteur éphémère utilisent tous deux le disque SSD local. Gardez cela à l’esprit pour le dimensionnement, car les E/S de tempdb sont comptabilisées dans les limites d’IOPS et de débit mis en cache des machines virtuelles en cas d’hébergement sur le lecteur éphémère.

Important

La modification du paramètre de cache d’un disque Azure détache et rattache le disque cible. Quand vous modifiez le paramètre de cache d’un disque hébergeant des fichiers de données, de journaux ou d’application SQL Server, veillez à arrêter le service SQL Server et tous les autres services associés pour éviter toute altération des données.

Pour plus d’informations, consultez Mise en cache du disque.

Entrelacement de disques

Analysez le débit et la bande passante nécessaires pour vos fichiers de données SQL afin de déterminer le nombre de disques de données, y compris le fichier journal et tempdb. Les limites de débit et de bande passante varient en fonction de la taille de machine virtuelle. Pour plus d’informations, voir Tailles des machines virtuelles.

Ajoutez des disques de données et utilisez l’entrelacement de disques pour augmenter le débit. Par exemple, une application qui a besoin de 12 000 IOPS et d’un débit de 180 Mo/s peut utiliser trois disques P30 agrégés par bandes pour fournir 15 000 IOPS et un débit de 600 Mo/s.

Pour configurer l’entrelacement de disques, consultez entrelacement de disques.

Encapsulation de disque

Il existe des limites de débit au niveau du disque et au niveau de la machine virtuelle. Les limites d’IOPS par machine virtuelle et par disque sont différentes et indépendantes les unes des autres.

Les applications qui consomment des ressources au-delà de ces limites sont limitées (également appelées « encapsulées »). Sélectionnez une machine virtuelle et une taille de disque dans un agrégat de disques qui remplit les exigences de l’application et qui n’est pas soumis aux limitations. Pour résoudre l’encapsulation, utilisez la mise en cache ou paramétrez l’application afin d’exiger un débit inférieur.

Par exemple, une application qui nécessite 12 000 IOPS et 180 Mo/s peut :

  • Utilisez la machine virtuelle Standard_M32ms dont le débit de disque maximal sans mise en cache est de 20 000 IOPS et 500 Mbits/s.
  • Entrelacez trois disques P30 pour fournir un débit de 15 000 IOPS et 600 Mo/s.
  • Utilisez une machine virtuelle Standard_M16ms et activez la mise en cache de l’hôte pour utiliser le cache local en cas de dépassement du débit consommé.

Les machines virtuelles configurées pour une mise à l’échelle pendant les périodes de forte utilisation doivent provisionner le stockage avec un nombre d’IOPS et un débit suffisants pour prendre en charge la taille de machine virtuelle maximale tout en conservant un nombre total de disques inférieur ou égal au nombre maximal pris en charge par la plus petite référence SKU de machine virtuelle à utiliser.

Pour plus d’informations sur les limitations de l’encapsulation de disque et l’utilisation de la mise en cache pour éviter l’encapsulation, consultez Encapsulation d’E/S des disques.

Notes

L’encapsulation de certains disques peut toujours aboutir à des performances satisfaisantes pour les utilisateurs. Ajustez et gérez les charges de travail plutôt que de les redimensionner sur une machine virtuelle plus grande pour équilibrer la gestion des coûts et des performances de l’entreprise.

Accélération d’écriture

L’Accélérateur d’écriture est une fonctionnalité de disque qui est uniquement disponible pour les machines virtuelles de la série M. L’objectif de l’accélération d’écriture est d’améliorer la latence d’E/S des écritures sur le stockage Premium Azure lorsque vous avez besoin d’une latence d’E/S à un chiffre en raison de charges de travail OLTP critiques ou d’environnements d’entrepôts de données de grande envergure.

Utilisez l’accélération d’écriture pour améliorer la latence d’écriture sur le lecteur qui héberge les fichiers journaux. N’utilisez pas l’accélération d’écriture pour les fichiers de données SQL Server.

Tous les disques avec Accélérateur d’écriture partagent la même limite d’IOPS que la machine virtuelle. Les disques attachés ne peuvent pas dépasser la limite d’IOPS de l’accélérateur d’écriture pour une machine virtuelle.

Le tableau suivant indique le nombre de disques de données et d’IOPS pris en charge par machine virtuelle :

Référence de la machine virtuelle Nombre de disques avec Accélérateur d’écriture IOPS de disque avec Accélérateur d’écriture par machine virtuelle
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 5 000
M16ms, M16s 2 2 500
M8ms, M8s 1 1250

L’utilisation de l’accélération d’écriture est soumise à plusieurs restrictions. Pour plus d’informations, consultez Restrictions lors de l’utilisation de Accélérateur d’écriture.

Comparer au disque Ultra Azure

La différence majeure entre l’Accélérateur d’écriture et les disques Ultra Azure est que l’Accélérateur d’écriture est une fonctionnalité de machine virtuelle qui est disponible uniquement pour la série M et que les disques Ultra Azure sont une option de stockage. L’Accélérateur d’écriture est un cache optimisé en écriture qui a ses propres limitations en fonction de la taille de la machine virtuelle. Les disques Ultra Azure sont une option de stockage sur disque à faible latence pour les machines virtuelles Azure.

Si possible, utilisez l’accélération d’écriture sur les disques Ultra pour le disque du journal des transactions. Pour les machines virtuelles qui ne prennent pas en charge l’Accélérateur d’écriture mais qui ont besoin d’une latence faible pour le journal des transactions, utilisez des disques Ultra Azure.

Surveiller les performances de stockage

Pour évaluer les besoins de stockage et déterminer le bon fonctionnement du stockage, vous devez comprendre ce qu’il faut mesurer, ainsi que la signification de ces indicateurs.

Les IOPS (Entrée/Sortie par seconde) sont le nombre de requêtes que l’application effectue pour le stockage par seconde. Mesurez les IOPS à l’aide des compteurs de l’analyseur de performances Disk Reads/sec et Disk Writes/sec. Les applications OLTP (traitement transactionnel en ligne) doivent effectuer des IOPS supérieures pour obtenir des performances optimales. Les applications telles que les systèmes de traitement des paiements, les achats en ligne et les systèmes de point de vente au détail sont des exemples d’applications OLTP.

Le débit est le volume de données envoyées au stockage sous-jacent, souvent mesuré en mégaoctets par seconde. Mesurez le débit avec les compteurs de l’analyseur de performances Disk Read Bytes/sec et Disk Write Bytes/sec. L'entreposage de données est optimisé pour maximiser le débit sur les IOPS. Les applications telles que les magasins de données pour l’analyse, la création de rapports, les flux de travail ETL et d’autres cibles décisionnelles sont des exemples d’applications d’entreposage de données.

Les tailles des unités d’E/S influencent les IOPS et les capacités de débit, car les tailles d’E/S plus petites fournissent des IOPS supérieures et des tailles d’E/S plus élevées. SQL Server choisit automatiquement la taille optimale des E/S. Pour plus d’informations à ce sujet, consultez Optimiser les IOPS, le débit et la latence de vos applications.

Il existe des métriques Azure Monitor spécifiques qui sont très utiles pour connaître les limitations au niveau de la machine virtuelle et du disque, ainsi que la consommation et l’intégrité du cache AzureBlob. Pour identifier les compteurs de clés à ajouter à votre solution de surveillance et au tableau de bord du Portail Azure, consultez Métriques d’utilisation du stockage.

Notes

Azure Monitor ne fournit pas de métriques au niveau du disque pour le lecteur temporaire éphémère (D:\). Le pourcentage de consommation d’IOPS mis en cache et le pourcentage de bande passante mise en cache pour les machines virtuelles reflètent les IOPS et le débit du lecteur temporaire éphémère (D:\) et de la mise en cache de l’hôte.

Surveiller la croissance du journal des transactions

Étant donné qu’un journal des transactions complet peut entraîner des problèmes de performances et des pannes, il est important de surveiller l’espace disponible dans votre journal des transactions, ainsi que l’espace disque utilisé du lecteur qui contient votre journal des transactions. Résolvez les problèmes de journal des transactions avant qu’ils n’affectent votre charge de travail.

Passez en revue la résolution des problèmes liés à un journal des transactions complet si votre journal devient complet.

Si vous avez besoin d’étendre votre disque, vous pouvez le faire dans le volet Stockage de la ressource de machines virtuelles SQL si vous avez déployé une image SQL Server à partir de Place de marché Azure, ou dans le volet Disques de votre machine virtuelle Azure et de SQL Server auto-installé.

Étapes suivantes

Pour en savoir plus, consultez les autres articles de cette série sur les meilleures pratiques :